JP2010503266A - 喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置 - Google Patents

Abstract

喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置が提供される。この装置は、レシーバ（１４０）及びファイルパッチャ（１５０）を含む。レシーバ（１４０）は、コンテナファイルを含むパケットを受信し、パケットロスが発生したパケットのいずれかを識別し、パケットロスによって影響を受けた識別されたパケットに含まれるデータを有する少なくとも１個のサンプルを識別するためのものである。少なくとも１個のサンプルは、特定のコンテナファイルにそれぞれ対応する。ファイルパッチャ（１５０）は、少なくとも１個のサンプルに関して特定のコンテナファイルを修復するためのものである。

Description

本発明の原理は、概してビデオエンコーディングに関し、特に喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置に関する。

コンテナフォーマットは、規格化されたエンコーダ及びコーデックの手段によって圧縮された様々なタイプのデータを含むことができるコンピュータファイルフォーマットである。コンテナファイルは、異なったデータタイプを識別し、インターリーブするために使用される。比較的単純なコンテナフォーマットは、異なったタイプのオーディオコーデックを含むことができ、より高度なコンテナフォーマットは、様々なストリームを同時に再生するために必要とされる同期化情報と共に、オーディオ、ビデオ、サブタイトル、チャプタ及びメタデータ（タグ）をサポートすることができる。

コンテナファイルがロスの多いネットワークで放送またはマルチキャストされるとき、ファイル受信においてパケットエラーが発生することがある。いくつかのビデオデコーダは、チャンネルエラーに関してロバストではない。ビデオデコーダまたはプレイヤーにとって、部分的に喪失したスライスまたはピクチャを伴った圧縮されたビデオファイルを処理することができるよりも、完全に喪失したスライスまたはピクチャを伴う圧縮されたビデオファイルを処理することができることの方がしばしば容易である。可変長コーディングのために、ビデオデコーダが喪失または破損データを検出するのは難しい。なぜなら、どのビットも、間違いではなく許容可能なシンボルとして解釈され得るからである。さらに、国際標準化機構／国際電気標準会議（ＩＳＯ／ＩＥＣ）ＭＰＥＧ−４（Moving Picture Experts Group-4）第１０部ＡＶＣ（Advanced Video Cording）国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）Ｈ．２６４勧告（以下、「ＭＰＥＧ−４ ＡＶＣ規格」）の様ないくつかのコンテナファイルフォーマットは、オフセットのテーブルに依存してファイル内のすべてのスライスまたはピクチャの位置を識別する。データが喪失したとき、これらのオフセットは間違いになり、適切なビデオデコーダの動作を阻害することになるであろう。

パケットネットワーク上でビデオがストリーミングされるとき、通常はＲＴＰ（Real-time Transport Protocol）が使用される。ＲＴＰパケットヘッダは、喪失したパケットを識別するために使用することができるシーケンス番号を含む。ＲＴＰデータパケットは、可変長とすることができる。一般に、圧縮されたビデオのスライスがパケットと整列されることが推奨される。パケットが１または複数の完全なスライスを含み、パケットが失われているとき、デコーダは断片スライスを処理する能力を有しないであろう。

ＭＰＥＧ−４ ＡＶＣ規格は、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットを指定し、それにはコード化されたスライスが含まれなければならない。コード化されたピクチャのマクロブロックは、１または複数のスライスに配される。ネットワーク抽象化レイヤユニットは、シーケンスもしくはピクチャパラメータセット、ＳＥＩ（Supplemental Enhancement Information）メッセージ等の他のタイプのデータも含み得る。ＭＰＥＧ−４ ＡＶＣ規格準拠ビットストリームが、インターネットプロトコル（ＩＰ）ネットワーク上でストリーミングされるとき、通常は、ＲＴＰを使用したＭＰＥＧ−４ ＡＶＣ規格準拠ビットストリームを送信するための構文を指定するスキームが使用される。ある従来技術のアプローチにおいては、フラグメンテーションまたはアグリゲーションユニットのどちらもが使用されていない場合、単一のネットワーク抽象化レイヤユニット全体が送信のためにインターネットプロトコルパケットに配されている。このパケットが伝送エラーに起因して喪失された場合、単一のネットワーク抽象化レイヤユニット全体が喪失される。アグリゲーションユニットが使用される場合、いくつかのネットワーク抽象化レイヤユニット全体が単一のパケットに配される。このパケットが伝送エラーに起因して喪失された場合、これらいくつかのネットワーク抽象化レイヤユニット全体が喪失される。これらの場合において、ネットワーク抽象化レイヤユニットの一部は、対応するレシーバに到達しないだろう。フラグメンテーションユニットが使用される場合、単一の大きなネットワーク抽象化レイヤユニットは、複数のパケットに亘って分割される。レシーバはＲＴＰパケットに含まれるシーケンス番号を使用することにより、１または複数のこれらのパケットが伝送エラーによって喪失されたかどうかを検出することができる。

フラグメンテーションユニットが喪失された場合、レシーバは、分割された同じネットワークの抽象化レイヤユニットに対応するすべての後続のフラグメンテーションユニットを伝送順で放棄すべきである。終点またはＭＡＮＥ（Media Aware Network Element）内のレシーバは、ネットワーク抽象化レイヤユニットの断片ｎが受信されなくとも、ネットワーク抽象化レイヤユニットの最初のｎ−１個の断片を（不完全な）ネットワーク抽象化レイヤユニットに統合することができる。この場合、ネットワーク抽象化レイヤユニットのforbidden_zero_bitは１に設定され、構文違反を示す。ＭＰＥＧ−４ ＡＶＣ規格によれば、ネットワーク抽象化レイヤユニットヘッダは、forbidden_zero_bitと称される１ビットの構文領域を含む。ＭＰＥＧ−４ ＡＶＣ規格準拠ビットストリームにおいて、このforbidden_zero_bitは、通常０に等しい。ビットストリーム構文においてエラーが検出されるとき、デコーダは、この検出条件を、バイトアラインメントが失われた可能性があることを示すものとして考慮することができ、ビットストリームにおけるその後の位置でのバイトアラインメントの検出まで全てのビットストリームデータを放棄することができる。
ＭＰＥＧ−４ ＡＶＣ規格は、フィラーデータネットワーク抽象化レイヤユニットタイプを定義する。デコーダは、フィラーデータを含むネットワーク抽象化レイヤユニットを無視することを期待されている。

双方向ネットワーク上のファイル転送は、ＴＣＰ（Transmission Control Protocol）の様な信頼性のあるプロトコルをしばしば使用する。パケットロスが発生した場合、再送信が用いられて、最終的にファイル内のすべてのデータが受信される。ファイルが、信頼性の無いプロトコルを使用して端方向ネットワークまたは双方向ネットワーク上で転送される場合、再送信は使用されない。

圧縮されたビデオ及びオーディオは、例えば、ＭＰＥＧ−４ ＡＶＣ規格、ＡＶＩ（Audio Video Interleaved）フォーマット、３ＧＰＰ（the 3^rd Generation Partnership Project）及びＩＳＯ／ＩＥＣ ＭＰＥＧ２規格に従って、マルチメディアコンテナフォーマットで一緒に保存することができる。ＭＰＥＧ−４ ＡＶＣ規格は、いくつかの異なったビデオ（ＭＰＥＧ−２ビデオ、ＭＰＥＧ−４ パート２ ビデオ、もしくはＭＰＥＧ−４ ＡＶＣ ビデオ）またはオーディオ（ＭＰＥＧ−２ レイヤ３、ＡＡＣ（Advanced Audio Cording））フォーマットを保存するために使用することができるコンテナファイルフォーマットを含む。ＭＰＥＧ−４ ＡＶＣ規格ファイルフォーマットは、ＩＳＯメディアファイルフォーマットに基づいている。

ＭＰＥＧ−４ ＡＶＣファイルの基本ユニットはサンプルであり、ビデオの場合、通常はコード化されたピクチャ全体である。非ヒントトラックにおいて、サンプルは個別のビデオのフレーム、時間的に連続な一連のビデオのフレーム、または時間的に連続な圧縮されたオーディオのセクションである。ヒントトラックにおいて、サンプルは、１または複数のストリーミングパケットのフォーメーションを定義する。トラック内の２つのサンプルが同一のタイムスタンプを共有することはない。

ＭＰＥＧ−４ ＡＶＣファイルは、サンプルテーブルを含む。このサンプルテーブルは、各サンプル（通常はコード化されたピクチャ）に関する情報を提供し、それらはサンプルが位置付けされているファイル内のオフセット及びサンプルのサイズを示す。

サンプルテーブルは、トラック内のメディアサンプルのすべての時間及びデータインデックスを含む。このテーブルを使用して、時間でサンプルを特定し、それらのタイプ（例えばｌフレームまたはそれ以外）を判定し、それらのサイズ、コンテナ及びそのコンテナへのオフセットを判定することが可能である。

サンプルテーブルボックスが含まれるトラックがデータを参照する場合、次のサブボックスが必要とされ得る。すなわち、サンプル説明、サンプルサイズ、チャンクすべきサンプル及びチャンクオフセットである。

ＭＰＥＧ−４ ＡＶＣファイルフォーマットは、含まれているＭＰＥＧ−４ ＡＶＣビデオに拡張されている。ＭＰＥＧ−４ ＡＶＣビデオがＭＰＥＧ−４ ＡＶＣファイルフォーマットに含まれる場合、スタートコードはこのファイルに含まれない。

ＦＬＵＴＥ（File Delivery over Unidirectional Transport）と称されるファイル配信プロトコルは、単方向ネットワーク上のマルチキャスト配信を目的としている。ＦＬＵＴＥは、ＭＰＥＧ−４ ＡＶＣファイルを配信するために使用することができる。特定のＦＬＵＴＥセッションにおけるすべてのＦＬＵＴＥ送信パケットは、同一の長さになり、それゆえ、ＭＰＥＧ−４ ＡＶＣファイルの可変長コード化されたスライスまたはピクチャと整列されないことになる。ＭＰＥＧ−４ ＡＶＣファイルの配信中にパケットロスが発生した場合、受信された部分的なＭＰＥＧ−４ ＡＶＣファイルは無効である。サンプルテーブルにおけるオフセットは、間違った位置を指し示すであろう。可変長コード化されたピクチャに起因して、無効なＭＰＥＧ−４ ＡＶＣファイルにおいて、特定のコード化されたフレームのスタートを示すＭＰＥＧ−４ ＡＶＣサンプルテーブルにおけるオフセットは代わりに、ビットストリームデータの不明な位置を指し示すことになり、これはコード化されたフレームの中央になり得るだろう。各ＦＬＵＴＥパケットは、送信されたパケットごとにインクリメントするソースブロックナンバ領域を含む。ＦＬＵＴＥプロトコルは、ファイル説明テーブル（ＦＤＴ）を含み、これは配信されるべきファイルのサイズを示す領域を含む。

従来技術のこれら及び他の欠点及び不利な点は、本発明の原理によって対処され、この原理は喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置に関する。

本発明の原理のある態様によれば、装置が提供される。この装置は、レシーバ及びファイルパッチャを含む。レシーバは、コンテナファイルをその中に含むパケットを受信して、パケットロスが発生したパケットのいずれかを識別し、パケットロスにより影響を受けた識別されたパケットに含まれるデータを有する少なくとも１個のサンプルを識別するためのものである。この少なくとも１個のサンプルは、特定のコンテナファイルにそれぞれ対応している。ファイルパッチャは、この少なくとも１個のサンプルに関する特定のコンテナファイルを修復するためのものである。

本発明の原理の別の態様によれば、方法が提供される。この方法は、コンテナファイルをその中に含むパケットを受信するステップと；パケットロスが発生したパケットのいずれかを識別するステップと；パケットロスにより影響を受けた識別されたパケットに含まれるデータを有する少なくとも１個のサンプルであって、特定のコンテナファイルにそれぞれ対応する少なくとも１個のサンプルを識別するステップと；少なくとも１個のサンプルに関して特定のコンテナファイルを修復するステップとを含む。

本発明の原理のこれら及び他の態様、特徴及び利点は、添付の図面と関連付けて読まれるべき以下の例示的実施形態の詳細な説明から明らかになるであろう。

本発明の原理は、以下の例示の図に従ってさらに理解されるであろう。

本発明の原理の実施形態に従って本発明の原理が適用され得る単方向ビデオファイル転送システムのブロック図である。 本発明の原理の実施形態に従って本発明の原理が適用され得る例示的コンテナファイルのブロック図である。 本発明の原理の実施形態に従って本発明の原理が適用され得る送信パケット化を伴った例示的なコンテナファイルの図である。 本発明の原理の実施形態に従って本発明の原理が適用され得る送信パケット化及びパケットロスを伴った例示的なコンテナファイルの図である。 本発明の原理の実施形態に従って第１の例示的な更新オプションにより更新されたサンプルテーブルでのファイルパッチング後の送信パケット化及びパケットロスを伴った例示的なコンテナファイルの図である。 本発明の原理の実施形態に従って第２の例示的な更新オプションによりフィラーデータを使用したファイルパッチング後の送信パケット化及びパケットロスを伴った例示的なコンテナファイルの図である。 本発明の原理の実施形態に従って喪失したパケットにより影響を受けたサンプルを判定する例示的方法のフロー図である。 本発明の原理の実施形態に従って喪失したパケットにより影響を受けたサンプルを置換する例示的方法のフロー図である。

本発明の原理は、喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置に関する。

本説明は、本発明の原理を示す。従って、当業者は、本明細書に明示的に記載または図示されていなくとも、本発明の原理を具体化し、本発明の原理の趣旨及び範囲内に含まれる様々な機械を考案することができるであろうことが理解されよう。

本明細書で言及される全ての例示及び条件付き言語は、発明者（達）によって寄与された本発明の原理及び概念を理解するにあたって読者を助けて、技術を促進するために教育的な目的を意図しており、この様な具体的に言及された例示及び条件に限定されないものとして解釈されるべきである。

さらに、本発明の原理、側面及び実施形態に言及している本明細書の全ての記述並びにそれらの具体的な例は、それらの構造的及び機能的均等物の両方を包含することが意図されている。さらに、このような均等物は、現在周知の均等物だけではなく将来開発される均等物、すなわち、構造に関わらず、同一の機能を発揮するよう開発された任意の要素も含むことが意図されている。

従って、例えば、当業者により、本明細書で示されたブロック図が、本発明の原理を具体化する実例回路の概念的図を表していることが認識されるであろう。同様に、任意のフローチャート、フロー図、状態遷移図、疑似コード及びそれらに類したものが様々な処理を表し、それらは、実質的にコンピュータ可読媒体内で表すことができ、コンピュータまたはプロセッサが明示的に図示されていなくとも、コンピュータまたはプロセッサによってそのように実行され得ることが理解されるであろう。

図に示された様々な要素の機能を、専用のハードウェア及び適切なソフトウェアと共同してソフトウェアを実行可能なハードウェアの使用を介して提供することができる。プロセッサによって提供された場合、これらの機能を、単一の専用プロセッサによって、単一の共有プロセッサによって、または複数の個別のプロセッサ、共有することができるこれらのいくつかによって、提供することができる。さらに、用語「プロセッサ」または「コントローラ」の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に参照すると解釈されるべきではなく、限定するわけではないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ソフトウェアを保存するＲＯＭ（read-only memory）、ＲＡＭ（random access memory）及び不揮発性記憶装置を暗示的に含むことが可能である。

他の通常及び／またはカスタムハードウェアもまた含まれ得る。同様に、図に示される任意のスイッチは、単に概念的なものである。それらの機能は、プログラムロジックの動作を介して、専用のロジックを介して、プログラム制御と専用ロジックとの相互作用を介して、または手動的にさえも実行されること可能であり、これらの特定の技術は、文脈からさらに具体的に理解されるように実施者によって選択可能である。

本願の請求項において、指定された機能を発揮する手段として表現される任意の要素は、例えば、ａ）その機能を発揮する回路要素の組み合わせ、またはｂ）そのソフトウェアを実行するために適切な回路と組み合わされて当該機能を発揮するファームウェア、マイクロコードまたはそれらに類したものを含む任意の形式のソフトウェアを含むその機能を発揮する任意の方法を包含することを意図している。そのような請求項により画定される本発明の原理は、言及された様々な手段によって提供される機能が、請求項が要求する態様において組み合わされ、まとめられるという事実に属する。従って、これらの機能を提供することができる任意の手段が本明細書で示されるものと均等とみなされる。

本明細書における本発明の原理の「１つの実施形態」または「ある実施形態」への言及とは、実施形態に関連して説明される特定の特徴、構造、特性等が、本発明の原理の少なくとも１つの実施形態に含まれていることを意味する。従って、本明細書を通して様々な場所に出現する「１つの実施形態において」または「ある実施形態において」という表現の出現は、必ずしも全て同一の実施形態を参照しない。

さらに、本発明の原理の１または複数の実施形態が、本明細書内でＭＰＥＧ−４ ＡＶＣ規格及び／またはＡＶＩ（Audio Video Interleaved）フォーマットに関連して説明されているが、本発明の原理は、この規格及び／またはフォーマットのみに限定されず、従って、本発明の原理の趣旨を維持しつつ、他のビデオコーディング規格、勧告、ＭＰＥＧ−４ ＡＶＣ規格の拡張を含む拡張、及び他のジョイントオーディオビデオフォーマットに使用することができる。

また、本発明の原理の１または複数の実施形態は、ＦＬＵＴＥ（File Delivery over Unidirectional Transport）について本明細書に記載されているが、本発明の原理はこのプロトコルだけに限定されないことが理解されるべきであり、従って、本発明の原理の趣旨を維持しながら他のファイル転送プロトコルに使用されることが可能である。

さらに、本明細書で使われるように「修復」の用語は「パッチング」を参照しそれと同義語である。すなわち、喪失パケットまたはパケット群に起因して影響を受けるサンプル（少なくとも部分的に喪失した）は、コンテナファイルから除去され（対応するサンプルテーブルが適切に更新され）または影響を受けたサンプル（少なくとも部分的に喪失した）は、代わりにフィラービットで埋められる。フィラービットは、デコーダによって廃棄されてデコードされないことを意図されているデータである。

上述したように、本発明の原理は喪失パケットを有するコンテナファイルに含まれるサンプルを修復するための方法及び装置に向けられている。

ある実施形態において、本発明の原理はパケットロスを有する受信したコンテナファイルを修復するための方法及び装置を提供するので、オーディオ／ビデオデコーダで再生することができる。修復／パッチングプロセスは、コンテナファイルからスライスまたはピクチャに相当する部分的に受信されたサンプルを除去する。これにより、破損したスライスまたはピクチャに関してロバストではないデコーダがそのファイルを処理できるようになる。デコーダは依然として、エラー隠ぺいを実行して失われたスライスまたはピクチャを隠ぺいすることが可能である。

図１を参照すると、単方向ビデオファイル転送システムが全体として参照番号１００で示されている。

システム１００は、ファイルトランスミッタ１２０の入力と信号通信で接続された出力を有する記憶デバイス１１０を含む。ファイルトランスミッタ１２０の出力は、信号通信でパケットネットワーク１３０の入力と接続されている。パケットネットワーク１３０の出力は、信号通信でファイルレシーバ１４０の入力と接続されている。ファイルレシーバ１４０の第１の出力は、信号通信でファイルパッチャ１５０の入力と接続されている。ファイルレシーバ１４０の第２の出力は、信号通信で記憶デバイス１６０の入力と接続されている。記憶デバイス１６０の双方向入力／出力は、信号通信でファイルパッチャ１５０の双方向入力／出力と接続されている。ファイルパッチャ１５０の出力は信号通信でビデオデコーダ１７０の入力と接続されている。

圧縮されたビデオ及びオプションのオーディオデータは、ＭＰＥＧ−４またはＡＶＩ（Audio Video Interleaved）の様なコンテナファイルフォーマットに保存される。このコンテナファイルは、ネットワークを介して、ファイルがローカルに保存されるファイルレシーバに送信される。このファイル転送プロトコルは、任意のパケットロスが発生したかどうかを示すことが可能であるべきである。ＦＬＵＴＥ（File Delivery over Unidirectional Transport）がファイル転送プロトコルとして使用された場合、次いで、ファイルレシーバは受信したソースブロックナンバ領域のギャップを検出することができる。受信されたパケットのソースブロックナンバが、直前に受信されたパケットのソースブロックナンバよりも１大きくない場合、次いで、パケットロスが検出されることが可能である。ファイルレシーバ１４０は、ファイルパッチャ１５０に失われたソースブロックナンバを示すべきである。ＦＬＵＴＥファイルレシーバは、受信したファイルのサイズをファイル記述テーブル（ＦＤＴ）に示されているファイルのサイズと比べることで送信ロスが発生したかどうかを判定することができる。受信したファイルのサイズがＦＤＴのファイルサイズと同一でない場合、次いで、送信ロスが発生したことは分かるが、どのデータが喪失されたかは判定されない。すべてのデータが適切に受信された場合、ファイルパッチングプロセスを実行する必要がない。

図２を参照すると、例示的なコンテナファイルが全体として参照番号２００で示されている。コンテナファイル２００は、サンプルテーブル２１０及び可変サイズのコード化されたピクチャ２２０を含む。

サンプルテーブル２１０は、例えばファイルのオフセット及びサイズの様な各サンプルに関する情報を含む。もちろん、この情報は上記タイプの情報のみに限定されず、従って、本発明の原理の趣旨を維持しながら、サンプルに関連する他のタイプの情報も使用することができる。表１は、コンテナファイルサンプルテーブルに関する例示的な内容を示しており、ここでは各サンプルはコード化されたピクチャを表している。

図３を参照すると、送信パケット化を伴う例示的なコンテナファイルが、全体として参照番号３００で示されている。コンテナファイル３００は、この例示のコンテナが、送信のために、長さ１０００の固定のサイズパケットにどのように分割されるかを示している。この例において、パケット２は、ピクチャ１の最後の部分、ピクチャ２の全て及びピクチャ３の最初の部分を含む。

パケット２が送信中に喪失された場合、パケット２に含まれたデータは喪失されるだろう。デコーダが、ファイルパッチングプロセスが使用されることなしに当該ファイルをデコードしようとした場合、ピクチャ１をデコードしようとすると、間違ったデータ上で行われることになるであろう。図４は、この例を示している。

図４を参照すると、送信パケット化及びパケットロスを伴う例示的なコンテナファイルが全体として参照番号４００で示されている。デコーダ１７０が、サンプルテーブルにおいて示されている３８０バイトと予想されたピクチャ１にアクセスする試行をした場合、図４において１ａと示されたピクチャ１の正しい最初の部分、３ｂと示されたピクチャ３の最後の部分、及びピクチャ４の一部を取得するであろう。可変長コーディングに起因して、デコーダは、無効なデータを処理していることを検出できそうにないと思われるので、データを間違って解釈するだろう。このことは、例えば、変換係数が動きベクトルとして解釈された場合、非常に奇妙に見えるビデオを引き起こす可能性がある。さらに、不適切なメモリ位置にアクセスする試行のため、デコーダが壊れてしまう可能性があるだろう。

本発明の原理の１または複数の実施形態に従ったパッチングは、デコーダに無効なデータを送信する問題を解決する。ある実施形態において、ファイルパッチングプロセスは、ファイル受信中または受信後であり、デコード前にコンテナファイルに適用されるだろう。パッチングプロセスにおいて、各喪失パケットに対して、サンプルの少なくとも一部が喪失しているためにどのサンプルが喪失パケットによって影響を受けたかの判定がなされるだろう。その後、コンテナファイルは、これらの影響を受けたサンプルの各々に関して更新され、破損したファイルが除去される。デコーダが、有効なコード化されたピクチャまたはスライスだけを受信することを保証できるようにするために、いくつかの正しく受信されたデータは、除去されるかまたは置換される。

ある実施形態において、どのサンプルが喪失パケットによって影響を受けたのかを判定するプロセスは、例えばＦＬＵＴＥといったファイル送信プロトコルからの情報を使用し、この情報は、喪失パケットに応じてファイルレシーバによって判定されたパケット長pkt_length及びソースブロックナンバを含む。プロセスは、コンテナファイルフォーマットのサンプルテーブルからの情報も使用することができ、それはサンプルオフセット（またはチャンクオフセット）及びサンプルサイズを含む。これらのパラメータは、コンテナファイル内の喪失パケット及び対応するコード化されたサンプル内にあったバイト間の任意のオーバーラップを判定するために使用される。特定のサンプルに関して、サンプルの少なくとも一部が喪失しており、サンプルと喪失パケットとの間に任意のオーバーラップが存在している場合、サンプルはパケットロスによって影響を受けたとしてマーキングされる。

どのサンプルが喪失パケットにより影響を受けたかを判定するためにＦＬＵＴＥを使用することは、本明細書において説明の目的のために記載されており、本発明の原理は、そのような判定に関してＦＬＵＴＥを使用することだけに限定されないことが理解されるべきである。すなわち、本明細書で提供される本発明の原理の教示に鑑みて、当技術分野及び関連する技術分野の当業者は、本発明の原理に従って修復を行う際の使用に関して、本発明の原理の趣旨を維持しながら、ＦＬＵＴＥ及び他のプロトコルの使用を企図し、どのサンプルが喪失パケットによって影響を受けているかを判断するようアプローチをするだろう。

図７を参照すると、喪失パケットによって影響をうけたサンプルを判定するための例示的な方法が、全体として参照番号７００によって示されている。

方法７００は、制御を機能ブロック７１０に渡すスタートブロック７０５を含む。機能ブロック７１０は、変数ｓによって表される現在のサンプルを０に等しく設定し、制御をループ制限ブロック７１５に渡す。ループ制限ブロック７１５は、ソースブロックナンバを表す変数ｍによって表わされる各喪失したソースブロックに関するループを実行し、制御を機能ブロック７２０に渡す。機能ブロック７２０は、lost_pkt_offset[m]をpkt_length*mに等しく設定して、制御を判断ブロック７２５に渡す。判断ブロック７２５は、offset[s]+size[s]がlost_pkt_offset[m]よりも大きいかまたはそうでないかを判定する。もし大きいならば、次いで、制御は機能ブロック７３０へ渡される。さもなければ、制御は機能ブロック７４５へ渡される。

機能ブロック７３０は、サンプルｓをパケットロスによって影響を受けたとしてマーキングし、制御を判断ブロック７３５に渡す。判断ブロック７３５は、offset[s]+size[s]＜lost_pkt_offset[m]+pkt_lengthであるかまたはそうでないかを判定する。もしそうであるならば、制御は機能ブロック７４０へ渡される。さもなければ、制御はループ制限ブロック７５０へ渡される。

機能ブロック７４０は、変数ｓをインクリメントし、制御を機能ブロック７３０へ戻す。

ループ制限ブロック７５０は、変数ｍによって表された各喪失ソースブロック上でループを終了し、制御をエンドブロック７９９に渡す。

機能ブロック７４５は、ｓをインクリメントし、制御を判断ブロック７２５に渡す。

方法７００が本明細書に説明された例に適用されると、ピクチャ１、２及び３に対応するサンプルは、パケットロスによって影響を受けているとしてマーキングされるだろう。

影響を受けたサンプルが判定された後、コンテナファイルは更新されて、本明細書に記載された２つの例示的オプションのうちの１を使用して、これらの影響を受けたサンプルがパッチングされる。もちろん、上述の例示的オプションは説明の目的であって、本発明の原理はこれらのオプションだけに限定されるものではないことが理解されるべきであり、当技術分野及び関連する技術分野の当業者は、本発明の原理の趣旨を維持しつつ、本明細書で提供される本発明の原理の教示を鑑みて、コンテナファイルの更新に関して、これらまたは他のオプションを企図するであろう。

第１の例示的オプションによれば、影響を受けたサンプルに対応する全てのデータはファイルから除去され、サンプルテーブルは更新されて、パケットロスによって影響を受けた全てのサンプルが除去される。その後、サンプルテーブル内の他のサンプルの全てのオフセットは、除去されたサンプルを計上すべく調整される。除去された各サンプルに対して、除去されたサンプルのサイズは、サンプルテーブル内の後に続く全てのサンプルのオフセット値から減算される。このオプションに従えば、パッチング後の当該コンテナファイルの全体のサイズは減少する。図５を参照すると、送信パケット化及びパケットロスを伴い、第１の例示的更新オプションに従って更新されたサンプルテーブルでファイルパッチング後の例示的なコンテナファイルが、全体として参照番号５００で示されている。

第２の例示的なオプションによれば、サンプルテーブルは変更されない。その代わりに、フィラーデータが影響を受けた全てのサンプルの場所に配される。このオプションに従えば、パッチング後の当該コンテナファイルの全体のサイズは、オリジナルのファイルのサイズと同一になる。図６を参照すると、送信パケット化及びパケットロスを伴う第２の例示的更新オプションに従ってフィラーデータを使用したファイルパッチング後の例示的コンテナファイルが、全体として参照番号６００で示されている。

使用されるビデオ圧縮規格がＭＰＥＧ−４ ＡＶＣ規格である場合、フィラーデータを含むネットワーク抽象化レイヤユニットは、当該コンテナファイル内に配され得、影響を受けたサンプルと置換される。他のオプションは、ネットワーク抽象化レイヤユニットヘッダ内のforbidden_zero_bitを１に設定して、これが壊れたネットワーク抽象化レイヤユニットであることをデコーダに示すことであろう。いくつかのコンテナファイルフォーマット（例えば、ＭＰＥＧ−４ ＡＶＣ規格エンコード化ビデオに適用されるようなＭＰＥＧ−４ ＡＶＣ規格ファイルフォーマットなど）は、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのシーケンスを、当該ユニットのサイズ（NALUnitLength）で各ネットワーク抽象化レイヤユニットをプリペンドすることによって単一のサンプル内に保存し得ることに留意されたい。Forbidden_zero_bit法が破損を示すために使用された場合であって、複数のネットワーク抽象化レイヤユニットが、影響を受けたサンプル内に存在する場合、NALUnitLengthは、影響を受けたサンプルのフルサイズを反映するように調整されなければならない（NALUnitLength領域のサイズを減算する）。

当該コンテナファイル内のサンプルの基本的なユニットは、通常はコード化されたピクチャ全体である。しかし、この概念は個々のスライスにも適用可能である。コード化されたピクチャまたはコード化されたスライスは、送信中にそれらのデータの少なくとも一部が喪失された場合に除去される。

図８を参照すると、喪失パケットによって影響を受けたサンプルを置換するための例示的方法が全体として参照番号８００で示されている。

方法８００は、機能ブロック８１０に制御を渡すスタートブロック８０５を含む。機能ブロック８１０は、現在のサンプルｓを０に等しく設定して制御をループ制限ブロックへ渡す。機能ブロック８１５は、各サンプルｓに亘ってループを実行して判断ブロック８２０へ制御を渡す。

判断ブロック８２０は、ｓがパケットロスによって影響を受けているとしてマーキングされているかまたはされていないかを判定する。もしもそうならば、次いで制御は判断ブロック８２５へ渡される。さもなければ、制御は機能ブロック８５０へ渡される。

判断ブロック８２５は、forbidden_zero_bit法を使用するか否かを判定する。使用するならば、次いで制御は機能ブロック８３０へ渡される。さもなければ、制御は判断ブロック８５５へ渡される。

機能ブロック８３０は、現在のサンプルの先頭におけるNALUnitLength領域を、サンプルｓの長さから長さ領域のサイズを引いたものに設定して、制御を機能ブロック８３５へ渡す。機能ブロック８３５は、現在のサンプルｓの第１のＮＡＬヘッダのforbidden_zero_bitを１に等しく設定して、制御を判断ブロック８４０へ渡す。

判断ブロック８４０は、現在のサンプルｓが最後のサンプルかどうかを判定する。最後のサンプルならば、次いで制御はループ制御ブロック８４５に渡される。さもなければ、制御は機能ブロック８５０へ渡される。

機能ブロック８４５は、各サンプルｓに亘るループを終了し、制御をエンドブロック８９９へ渡す。

機能ブロック８５０は、ｓをインクリメントし、制御を判断ブロック８２０へ戻す。

判断ブロック８５５は、フィラーＮＡＬ法を使用するか否かを判定する。使用するならば、次いで制御は機能ブロック８６０へ渡される。さもなければ、制御は機能ブロック８７０へ渡される。

機能ブロック８６０は、現在のサンプルの先頭におけるNALUnitLength領域を、サンプルｓの長さから長さ領域のサイズを減算したものに設定し、制御を機能ブロック８６５へ渡す。機能ブロック８６５は、サンプルコンテンツをフィラービットコンテンツを含むＮＡＬに置換して、制御を判断ブロック８４０へ渡す。

機能ブロック８７０は、サンプル除去法が使用されるべきことを指定し、制御を機能ブロック８７５へ渡す。機能ブロック８７５は、ファイルからサンプルを除去し、制御を機能ブロック８８０へ渡す。機能ブロック８８０は、サンプルテーブルを更新して、除去されたサンプルを示し、制御を判断ブロック８４０へ渡す。

これから、本発明の多くの付随する利点／特徴のいくつかについての説明が与えられ、それらのうちのいくつかは、既に上述されている。例えば、１つの利点／特徴は、レシーバ及びファイルパッチャを含む装置である。レシーバは、コンテナファイルを含むパケットを受信し、パケットロスが発生したパケットのいずれかを識別し、パケットロスによって影響を受けた識別されたパケットに含まれるデータを有する少なくとも１個のサンプルを識別するためのものである。この少なくとも１個のサンプルは、特定のコンテナファイルにそれぞれ対応する。ファイルパッチャは、この少なくとも１個のサンプルについて特定のコンテナファイルを修復するためのものである。

他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、ファイルパッチャが特定のコンテナファイルから少なくとも１個のサンプルを除去することによって特定のコンテナファイルを修復し、特定のコンテナファイルのサンプルテーブルを更新して少なくとも１個のサンプルの除去を示す装置である。

更に他の利点／特徴は、レシーバ及びファイルパッチャを有する装置であって、上述のように、ファイルパッチャが特定のコンテナファイルから少なくとも１個のサンプルを除去することによって特定のコンテナファイルを修復し、特定のコンテナファイルのサンプルテーブルを更新して少なくとも１個のサンプルの除去を示し、ファイルパッチャがサンプルテーブル内の後に続くサンプルのオフセットを更新して少なくとも１個のサンプルの除去を計上する装置である。

更に、他の利点／特徴は、レシーバ及びファイルパッチャを有する装置であって、上述のように、ファイルパッチャがサンプルテーブルの後に続くサンプルのオフセットを更新して少なくとも１個のサンプルの除去を計上し、ファイルパッチャが、後に続くサンプルのオフセットから少なくとも１個のサンプルのサイズを減算する装置である。

更に、他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、ファイルパッチャが、少なくとも１個のサンプルをフィラービットコンテンツで置換することで特定のコンテナファイルを修復する装置である。

また、他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、レシーバが、パケットロスが発生したパケット群のいずれかを、パケット長さ、ソースブロックナンバ、コンテナファイルサンプルテーブルのサンプルオフセット値及びコンテナファイルサンプルテーブルのサンプルサイズの少なくとも１つに基づいて識別する装置である。

更に、他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、レシーバが、パケットの各々およびコンテナファイルのそれぞれ１個の対応するサンプルに含まれるバイト間に任意のオーバーラップが存在するか否かをパケットパラメータ及びコンテナファイルフォーマットサンプルテーブルパラメータの少なくとも１つを使用してそれぞれ判定することによってパケットロスが発生したパケットのいずれかを識別し、オーバーラップが存在した場合にはパケットのいずれかをパケットロスを被ったとして識別する装置である。

更に、他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、少なくとも１個のサンプルが部分的に受信されたサンプル及び完全に失われたサンプルのいずれかを含み、ファイルパッチャが、少なくとも１個のサンプルに対応するネットワーク抽象化レイヤユニットヘッダのビットを設定して少なくとも１個のサンプルが破壊されていることを示す装置である。

更に他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、ファイルパッチャが、少なくとも１個のサンプルに対応する少なくとも１個のネットワーク抽象化レイヤユニットでforbidden_zero_bitを１に設定して少なくとも１個のサンプルが破壊されていることを示す装置である。

また、他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、ファイルパッチャが特定のコンテナファイルを、それらをデコードする前に修復する装置である。

更に他の利点／特徴は、上述のようにレシーバ及びファイルパッチャを有する装置であって、少なくとも１個のサンプルが部分的に受信されたサンプル及び完全に失われたサンプルのいずれかを含む装置である。

本発明の原理のこれらの及び他の特徴および利点は、関連技術分野の当業者によって本明細書の教示に基づいて容易に解明されうる。本発明の原理の教示は、ハードウェア、ソフトウェア、ファームウェア、特定目的プロセッサまたはそれらの組み合わせといった様々な形式において実施され得ることが理解されるべきである。

最も好ましくは、本発明の原理の教示は、ハードウェアとソフトウェアとの組み合わせとして実施される。さらに、ソフトウェアを、プログラム記憶ユニット上で実体的に具体化されるアプリケーションプログラムとして実施することができる。アプリケーションプログラムを、任意の適切なアーキテクチャを含むマシンにアップロードし、実行することができる。好ましくは、マシンは、１または複数の中央処理装置（ＣＰＵ）、ＲＡＭ（random access memory）、及び入力／出力（Ｉ／Ｏ）インタフェースの様なハードウェアを有するコンピュータプラットフォーム上で実施される。コンピュータプラットフォームは、オペレーティングシステム及びマイクロインストラクションコードも含むことができる。本明細書において説明される様々なプロセス及び機能は、ＣＰＵによって実行され得るマイクロインストラクションコードの部分、またはアプリケーションプログラムの部分、またはそれらの任意の組み合わせのいずれかであり得る。さらに、追加データ記憶装置ユニット及び印刷ユニットの様な他の様々な周辺ユニットを、コンピュータプラットフォームに接続することができる。

添付の図で示された構成要素であるシステムコンポーネント及び方法のいくつかは、ソフトウェアにおいて実施されるのが好ましいので、システムコンポーネント間の実際の接続またはプロセス機能ブロックは、本発明の原理がプログラムされた態様に依存して異なり得ることがさらに理解されるべきである。本明細書の当該教示に鑑みれば、関連技術分野の当業者は、本発明の原理のこれら及び類似の実施または構成を企図することが可能であるだろう。

本明細書において、説明的な実施形態は添付の図面を参照して説明されてきたが、本発明の原理はこれらの実施形態そのものに限定されないこと、及び本発明の原理の範囲または趣旨から離れることなく様々な変化及び変更が関連技術分野の当業者によってもたらされ得ることが理解されるべきである。全てのこのような変化及び変更は、添付の特許請求の範囲内に示すような本発明の原理の範囲内に含まれることが意図されている。

Claims (22)

1. コンテナファイルを含むパケットを受信し、パケットロスが発生したパケットのいずれかを識別し、前記パケットロスによって影響を受ける前記識別されたパケットに含まれるデータを有する少なくとも１個のサンプルであって、特定のコンテナファイルとそれぞれ対応する前記少なくとも１個のサンプルを識別するためのレシーバ（１４０）と
   前記少なくとも１個のサンプルに関して前記特定のコンテナファイルを修復するためのファイルパッチャ（１５０）と
   を備えることを特徴とする装置。
2. 請求項１に記載の装置において、前記ファイルパッチャ（１５０）は、前記特定のコンテナファイルから前記少なくとも１個のサンプルを除去し、前記特定のコンテナファイルのサンプルテーブルを更新して前記少なくとも１個のサンプルの除去を示すことによって、前記特定のコンテナファイルを修復することを特徴とする装置。
3. 請求項２に記載の装置において、前記ファイルパッチャ（１５０）は、前記サンプルテーブル内の後に続くサンプルのオフセットを更新して前記少なくとも１個のサンプルの除去を計上することを特徴とする装置。
4. 請求項３に記載の装置において、前記ファイルパッチャ（１５０）は、前記後に続くサンプルのオフセットから前記少なくとも１個のサンプルのサイズを減算することを特徴とする装置。
5. 請求項１に記載の装置において、前記ファイルパッチャ（１５０）は、前記少なくとも１個のサンプルをフィラービットコンテンツで置換することによって前記特定のコンテナファイルを修復することを特徴とする装置。
6. 請求項１に記載の装置において、前記レシーバ（１４０）は、前記パケットロスが発生したパケットのいずれかをパケット長さ、ソースブロックナンバ、コンテナファイルサンプルテーブルのサンプルオフセット値及びコンテナファイルサンプルテーブルのサンプルサイズの少なくとも１つに基づいて識別することを特徴とする装置。
7. 請求項１に記載の装置において、前記レシーバ（１４０）は、前記パケットの各々および前記コンテナファイルのそれぞれの対応するサンプルに含まれるバイト間に任意のオーバーラップが存在するかどうかをパケットパラメータ及びコンテナファイルフォーマットサンプルテーブルパラメータの少なくとも１つを使用して各々判定することによって前記パケットロスが発生したパケットのいずれかを識別し、前記オーバーラップが存在した場合には前記パケットのいずれかをパケットロスを被ったとして識別することを特徴とする装置。
8. 請求項１に記載の装置において、前記少なくとも１個のサンプルは、部分的に受信されたサンプル及び完全に失われたサンプルのいずれかを含み、前記ファイルパッチャ（１５０）は、前記少なくとも１個のサンプルに対応するネットワーク抽象化レイヤユニットヘッダ内のビットを設定して前記少なくとも１個のサンプルが破壊されていることを示すことを特徴とする装置。
9. 請求項１に記載の装置において、前記ファイルパッチャ（１５０）は、前記少なくとも１個のサンプルに対応する少なくとも１個のネットワーク抽象化レイヤユニット内でforbidden_zero_bitを１に設定して前記少なくとも１個のサンプルが破壊されていることを示すことを特徴とする装置。
10. 請求項１に記載の装置において、前記ファイルパッチャ（１５０）は、前記特定のコンテナファイルを、それをデコードする前に修復することを特徴とする装置。
11. 請求項１に記載の装置において、前記少なくとも１個のサンプルは、部分的に受信されたサンプル及び完全に失われたサンプルのいずれかを含むことを特徴とする装置。
12. コンテナファイルを含むパケットを受信する受信するステップと
    パケットロスが発生した前記パケットのいずれかを識別するステップ（７２５）と
    前記パケットロスによって影響を受ける前記識別されたパケットに含まれるデータを有する少なくとも１個のサンプルであって特定のコンテナファイルとそれぞれ対応する少なくとも１個のサンプルを識別するステップ（７３０）と
    前記少なくとも１個のサンプルに関して前記特定のコンテナファイルを修復するステップ（８００）と
    を備えることを特徴とする方法。
13. 請求項１２に記載の方法において、前記修復するステップは、前記少なくとも１個のサンプルを除去するステップ（８７５）と、前記特定のコンテナファイルのサンプルテーブルを更新して前記少なくとも１個のサンプルの除去を示すステップ（８８０）とを備えることを特徴とする方法。
14. 請求項１３に記載の方法において、前記修復するステップは、前記サンプルテーブル内の後に続くサンプルのオフセットを更新して前記少なくとも１個のサンプルの除去を計上するステップ（８８０）を備えることを特徴とする方法。
15. 請求項１４に記載の方法において、前記修復するステップは、前記後に続くサンプルのオフセットから前記少なくとも１個のサンプルのサイズを減算するステップ（８８０）を備えることを特徴とする方法。
16. 請求項１２に記載の方法において、前記修復するステップは、前記少なくとも１個のサンプルをフィラービットコンテンツと置換するステップ（８６５）を備えることを特徴とする方法。
17. 請求項１２に記載の方法において、パケットロスが発生した前記パケットのいずれかを識別する前記ステップは、パケット長さ、ソースブロックナンバ、コンテナファイルサンプルテーブルのサンプルオフセット値及びコンテナファイルサンプルテーブルのサンプルサイズの少なくとも１つを使用する（７２５）ことを特徴とする方法。
18. 請求項１２に記載の方法において、パケットロスが発生した前記パケットのいずれかを識別する前記ステップは、前記パケットの各々および前記コンテナファイルのそれぞれの対応するサンプルに含まれるバイト間に任意のオーバーラップが存在するかどうかをパケットパラメータ及びコンテナファイルフォーマットサンプルテーブルパラメータの少なくとも１つを使用してそれぞれ判定するステップを備え、前記オーバーラップが存在した場合には前記パケットのいずれかをパケットロスを被ったとして識別することを特徴とする方法。
19. 請求項１２に記載の方法において、前記修復するステップは、前記少なくとも１個のサンプルに対応するネットワーク抽象化レイヤユニットヘッダ内のビットを設定して前記少なくとも１個のサンプルが破壊されていることを示すステップ（８３５）を備えることを特徴とする方法。
20. 請求項１２に記載の方法において、前記修復するステップは、前記少なくとも１個のサンプルに対応する少なくとも１個のネットワーク抽象化レイヤユニット内でforbidden_zero_bitを１に設定して前記少なくとも１個のサンプルが破壊されていることを示すステップ（８３５）を備えることを特徴とする方法。
21. 請求項１２に記載の方法において、前記修復するステップは、前記特定のコンテナファイルのデコード前に実行されることを特徴とする方法。
22. 請求項１２に記載の方法において、前記少なくとも１個のサンプルは、部分的に受信されたサンプル及び完全に失われたサンプルのいずれかを含むことを特徴とする方法。

Images