(57)【要約】受信したリアルタイムメディアストリームをマルチメディアコンテナファイルに格納するためのシステムおよび方法。メディアコンテンツは、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、ファイルに記録される。受信したメディアパケットの少なくとも１つは、メディアパケットを構築するための命令を使用することによってファイル中に表される。また、ファイルにおける受信したメディアパケットの少なくとも１つは、それがエラーを含みうるという標示に関連付けられる。【選択図】図1
2010526468.tif 000002
【特許請求の範囲】
【請求項１】
メディアコンテンツを含むメディアパケットのストリームを受信することと、
メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録することと、
を含み、
前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記メディアパケットを構築するための命令を使用することによって前記ファイル中に表され、前記ファイルにおける前記受信したメディアパケットの少なくとも１つは、前記少なくとも１つの受信したメディアパケットがエラーを含みうるという標示に関連付けられる、
方法。
【請求項２】
前記少なくとも１つの受信したメディアパケットに含まれうる前記エラーは、少なくとも１つのパケットの損失を含む、請求項1に記載の方法。
【請求項３】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項1に記載の方法。
【請求項４】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットから派生し、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項1に記載の方法。
【請求項５】
前記ファイルフォーマットは、メディアフレームのための構造を提供し、少なくとも１つの受信したメディアフレームが、前記メディアフレームのための構造により前記ファイル中に表される、請求項1に記載の方法。
【請求項６】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項5に記載の方法。
【請求項７】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットから派生し、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項5に記載の方法。
【請求項８】
請求項1に記載のプロセスを実行するように構成されるコンピュータコードを含む、コンピュータ可読媒体によって具現化されるコンピュータプログラム製品。
【請求項９】
プロセッサと、前記プロセッサに通信可能に接続されるメモリユニットとを備え、前記メモリユニットが、
メディアコンテンツを含む、受信したメディアパケットのストリームを処理するコンピュータコードと、
メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録するコンピュータコードと、
を有し、
前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記メディアパケットを構築するための命令を使用することによって前記ファイル中に表され、前記ファイルにおける前記受信したメディアパケットの少なくとも１つは、前記少なくとも１つの受信したメディアパケットがエラーを含みうるという標示に関連付けられる、
装置。
【請求項１０】
前記少なくとも１つの受信したメディアパケットに含まれうる前記エラーは、少なくとも１つのパケットの損失を含む、請求項9に記載の装置。
【請求項１１】
ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項9に記載の装置。
【請求項１２】
ファイルフォーマットは、ISOベースのメディアファイルフォーマットから派生し、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項9に記載の装置。
【請求項１３】
前記ファイルフォーマットは、メディアフレームのための構造を提供し、少なくとも１つの受信したメディアフレームが、前記メディアフレームのための構造により前記ファイル中に表される、請求項9に記載の装置。
【請求項１４】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項14に記載の装置。
【請求項１５】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットから派生し、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項14に記載の装置。
【請求項１６】
メディアコンテンツを含む、受信したメディアパケットのストリームを処理するための手段と、
メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録するための手段と、
を備え、
前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記メディアパケットを構築するための命令を使用することによって前記ファイル中に表され、前記ファイルにおける前記受信したメディアパケットの少なくとも１つは、前記少なくとも１つの受信したメディアパケットがエラーを含みうるという標示に関連付けられる、
装置。
【請求項１７】
前記少なくとも１つの受信したメディアパケットに含まれうる前記エラーは、少なくとも１つのパケットの損失を含む、請求項16に記載の装置。
【請求項１８】
コンピュータ可読媒体によって具現化されるマルチメディアコンテナファイルであって、
受信したメディアパケットのストリームからのメディアコンテンツであって、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記マルチメディアコンテナファイルに記録されるメディアコンテンツと、
前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記メディアパケットを構築するための命令を使用することによって前記ファイル中に表され、前記ファイル中に表される前記受信したメディアパケットの少なくとも１つは、前記少なくとも１つの受信したメディアパケットがエラーを含みうるという標示に関連付けられる、
マルチメディアコンテナファイル。
【請求項１９】
前記少なくとも１つの受信したメディアパケットに含まれうる前記エラーは、少なくとも１つのパケットの損失を含む、請求項18に記載のマルチメディアコンテナファイル。
【請求項２０】
ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項18に記載のマルチメディアコンテナファイル。
【請求項２１】
ファイルフォーマットは、ISOベースのメディアファイルフォーマットから派生し、前記前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれる、請求項18に記載のマルチメディアコンテナファイル。
【請求項２２】
前記ファイルフォーマットは、メディアフレームのための構造を提供し、少なくとも１つの受信したメディアフレームが、前記メディアフレームのための構造により前記ファイル中に表される、請求項18に記載のマルチメディアコンテナファイル。
【請求項２３】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットの或るバージョンであり、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項22に記載のマルチメディアコンテナファイル。
【請求項２４】
前記ファイルフォーマットは、前記ISOベースのメディアファイルフォーマットから派生し、前記メディアパケットを構築するための命令は、少なくとも１つのヒントトラックのヒントサンプルに含まれ、前記メディアフレームのための構造は、メディアトラックのメディアサンプルである、請求項22に記載のマルチメディアコンテナファイル。
【請求項２５】
プロセッサと、
前記プロセッサに通信可能に接続され、かつ第1の記述および第2の記述を含むマルチメディアコンテナファイルを含むメモリユニットと、
を備え、
前記第1の記述および前記第2の記述は、前記ファイルを処理する際に使用可能であり、
前記第1の記述は、第1のファイルフォーマットに準拠する前記ファイルの前記処理のためのデフォルト記述として標示され、前記第2の記述は、前記第1のファイルフォーマットに準拠して無視するように特定される構造にカプセル化される、
装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、マルチメディアコンテナファイルフォーマット（Multimedia Container File Format）に関する。より具体的には、本発明は、マルチメディアコンテナファイルフォーマットにおける受信ヒントトラック（Reception Hint Track）の使用および処理に関する。
【発明の背景】
【０００２】
本項は、請求項に列挙される本発明の背景または内容を提供することを意図する。本項における説明は、追求され得る概念を含むかもしれず、必ずしも過去に着想または追求された概念というわけではない。したがって、本明細書において別途明示されない限り、本項に説明される事項は、本出願における説明および請求項に対する従来技術ではなく、本項に含められているからといって直ちに従来技術であると考えてはならない。
【０００３】
マルチメディアコンテナファイルフォーマットは、一連のマルチメディアコンテンツの生成や操作、伝送、消費において重要な要素である。ここで、符号化フォーマット（すなわち、エレメンタリストリームフォーマット（Elementary Stream Format））は、コンテンツ情報をビットストリームに符号化する、符号化アルゴリズムの動作に関するものである。これに対してコンテナファイルフォーマット（Container File Format）は、多種多様なストレージやトランスポートアーキテクチャを利用して、ローカルで復号したり再生したり、ファイルとして転送したり、ストリーミングするべく、生成されたビットストリームがアクセス可能になるように、組織化するためのメカニズムを備えるものである。また、コンテナファイルフォーマットによって、メディアを交換および編集すること、ならびに受信したリアルタイムストリーミングをファイルに記録することが容易になる。したがって、符号化フォーマットとコンテナファイルフォーマットとは大幅に異なる。
【０００４】
マルチメディアファイルフォーマットの一般的階層構造について、図1の1000に示す。エレメンタリストリームフォーマット1100は、独立した単一のストリームを表す。.amrおよび.aacファイル等の音声ファイルは、エレメンタリストリームフォーマットに準拠して構築される。コンテナファイルフォーマット1200は、単一のファイルに音声および映像の両方のストリームを含みうるフォーマットである。コンテナファイルフォーマット1200のファミリの例は、ISOベースのメディアファイルフォーマットに基づく。階層構造1000におけるコンテナファイルフォーマット1200の真下に、多重化フォーマット（Multiplexing Format）1300が存在する。典型的には、多重化フォーマット1300は、コンテナファイルフォーマット1200に準拠して構築される音声/映像（audio/video; AV）ファイルよりも、柔軟性が低く、かつより強く圧縮される。多重化フォーマット1300に準拠して構築されるファイルは、典型的には、再生目的だけに使用される。動画像専門家グループ(Moving Picture Experts Group; MPEG)-2プログラムストリームは、多重化フォーマット1300に準拠して構築されるストリームの例である。プレゼンテーション言語フォーマット1400は、レイアウト、双方向性、AVおよび離散メディアの同期化等の目的で使用される。いずれもワールドワイドウェブコンソーシアム（World Wide Web Consortium; W3C）で定められる同期マメルチメディア統合言語（synchronized multimedia integration language; SMIL）およびスケーラブル映像グラフィックス（scalable video graphics; SVG）は、プレゼンテーション言語フォーマット1400の例である。プレゼンテーションファイルフォーマット1500は、同一のファイルに全ての部分のプレゼンテーションを含むことによって特徴付けられる。プレゼンテーションファイルフォーマットに準拠して構築されるオブジェクトの例として、PowerPointファイルと、3GPファイルフォーマットの拡張プレゼンテーションプロファイルに従うファイルとが挙げられる。
【０００５】
利用可能なメディアおよびコンテナファイルフォーマット規格には、ISOベースのメディアファイルフォーマット（ISO/IEC 14496-12）、MPEG-4ファイルフォーマット（ISO/IEC 14496-14、MP4フォーマットとしても知られている）、高度映像符号化（Advanced Video Coding; AVC）ファイルフォーマット（ISO/IEC 14496-15）、3GPPファイルフォーマット（3GPP TS 26.244、3GPフォーマットとしても知られている）が含まれる。また、MPEGにおいて、スケーラブル映像符号化（scalable video coding; SVC）ファイルフォーマットの開発のためのプロジェクトが存在し、これは、高度映像符号化（advanced video coding; AVC）ファイルフォーマットに対する修正になる。並行して、MPEGは、一方向トランスポート上のファイル配信（file delivery over unidirectional transport; FLUTE）および非同期階層符号化（asynchronous layered coding; ALC）セッションのヒントトラックフォーマットの規定に努めており、これは、ISOベースのメディアファイルフォーマットの修正になる。
【０００６】
デジタル映像ブロードキャスティング（Digital Video Broadcasting; DVB）メカニズムは、現在、DVBファイルフォーマットを規定する過程にある。DVBファイルフォーマットを規定する主な目的は、現在のDVB規格（DVT-T、DVB-C、DVB-S）および今後のDVB規格に準拠するセットアップボックス、インターネットプロトコル（Internet Protocol; IP）テレビジョン受像機、ならびにDVBハンドヘルド（DVB-Handheld; DVB-H）に準拠するモバイルテレビジョン受像機およびその今後の進化等のDVB技術の実装間のコンテンツの相互運用性を容易化することにある。DVBファイルフォーマットによって、異なる製造者による機器間において記録される（読み取りのみ）メディアの交換、USB大容量メモリまたは類似の読み取り/書き込み機器を使用するコンテンツの交換、家庭用ネットワークにおける共有ディスクストレージへの共用アクセス、ならびに他の機能が可能になる。現在、ISOベースのメディアファイルフォーマットは、DVBファイルフォーマットの開発のための基礎として最も強力な候補である。ISOファイルフォーマットは、上記で参照したコンテナファイルフォーマットの全て（ISOファイルフォーマット自体は含まない）の派生の基礎である。これらのファイルフォーマット（ISOファイルフォーマット自体を含む）は、ファイルフォーマットのISO群と呼ばれる。
【０００７】
ISOベースのメディアファイルフォーマットにおける基本構成要素は、ボックス（box）と呼ばれる。各ボックスは、ヘッダおよびペイロードを含む。ボックスヘッダは、ボックスの型と、バイトを単位としたボックスのサイズとを示す。ボックスは、他のボックスを包含してもよく、ISOファイルフォーマットは、特定の型のボックス内においてどのボックス型が許容されるかについて特定する。さらに、各ファイルに強制的に存在するボックスもあれば、一方、単にオプション的であるボックスもある。さらに、ボックス型によっては、ファイルに複数のボックスが存在することが可能である。ゆえに、ISOベースのメディアファイルフォーマットは、ボックスの階層構造を本質的に特定する。
【０００８】
図2は、ISOベースのメディアファイルフォーマットに準拠する簡略化ファイル構造を示す。ファイルフォーマットのISO群によると、ファイル200は、メディアデータおよびメタデータを含み、これらは、別々のボックスに含まれる。すなわち、メディアデータ（mdat）ボックス210、およびムービー（moov）ボックス220である。ファイルが動作可能であるためには、これらのボックスが両方とも存在しなければならない。メディアデータボックス210は、インターリーブされ、かつ時系列順である映像フレームおよび音声フレームを含む。ムービーボックス220は、１つ以上のトラックを含んでもよく、各トラックは、１つのトラックボックス240に存在する。１つのメディアタイプのプレゼンテーションでは、典型的には、１つのトラックが選択される。
【０００９】
ISOベースのメディアファイルフォーマットは、プレゼンテーションがただ１つのファイルに含まれるという形態に制限される訳ではないことに留意されたい。実際は、プレゼンテーションは、いくつかのファイルに含まれうる。そのようなシナリオにおいても、プレゼンテーション全体のメタデータは１つのファイルに含まれる。また、このファイルは、メディアデータの全てを含んでもよく、この場合、プレゼンテーションは、自立型である。他のファイルを使用する場合、ISOベースのメディアファイルフォーマットに準拠して他のファイルをフォーマット化する必要はない。他のファイルは、メディアデータを含むために使用され、また、未使用のメタデータまたは他の情報を含みうる。ISOベースのメディアファイルフォーマットは、メタデータを含むファイルの構造のみに関与する。メディアファイルにおけるそのメディアデータが、ISOベースのメディアファイルフォーマットまたはその派生フォーマットにおいて特定されるようにフォーマット化されなければならないという点においてのみ、メディアデータファイルのフォーマットは、ISOベースのメディアファイルフォーマットまたはその派生フォーマットによって制約される。
【００１０】
時間的トラックに加え、ISOファイルは、メタボックスに非時間的バイナリオブジェクトを含むことが可能である。メタボックスは、ファイルの最上位、ムービーボックス220内、トラックボックス内240に存在することが可能であるが、最大限でも１つのメタボックスが、ファイルレベル、ムービーレベル、トラックレベルの各々において発生し得る。メタボックスは、「hdlr」ボックスを含むことを必要とし、このボックスは、「メタ」ボックスコンテンツの構造またはフォーマットを示す。メタボックスは、参照可能な任意の数のバイナリ項目を含み、バイナリ項目の各１つをファイル名と関連付けることが可能である。
【００１１】
ファイルは、ファイルフォーマットのISO群における複数のフォーマットに適合してもよく、ゆえに、ファイルについて単一の「型（type）」または「ブランド（brand）」の観点から説明することは、必ずしも可能であるとは限らない。全てのISOファイルは、ファイルの「最善の使用（best use）」と、ファイルが従う一連の他の仕様とをどのファイルフォーマットが特定するかを示すファイル型ボックスを含む。ファイルの「最善の使用」であるフォーマットは、ファイルの主要ブランド（major brand）と呼ばれ、他の互換性のあるフォーマットは、互換ブランド（Compatible Brand）と呼ばれる。 
【００１２】
ファイル型ボックスについて、互換ブランドのリストにブランドが存在することは、要求（claim）および許可（permission）の両方を構成する。その存在は、ファイルがそのブランドの全ての必要性に適合するという点において要求であり、また、その存在は、ファイルを読み取るためにそのブランドのみを読み取り器が実装するからもしれないことに対する許可を表す。一般に、読み取り器は、以下のうちの１つに当てはまる場合でない限り、ブランドについて記載される全ての特徴を実装する必要がある。
【００１３】
１．読み取り器が使用するメディアが、特徴を使用または必要としない場合。例えば、Iフレーム映像は、同期サンプルテーブルを必要とせず、また、コンポジション再順序付け（composition reordering）を使用しない場合、コンポジション時間オフセットテーブル（composition time offset table）も必要とされない。同様に、コンテンツ保護が必要とされない場合、コンテンツ保護の構造への対応は必要とされない。
【００１４】
２．ファイルが準拠する別の仕様によって、特徴の使用が妨げられる場合。例えば、いくつかの派生した仕様によって、ムービーフラグメントの使用が明確に妨げられる。
【００１５】
３．製品が動作するコンテクストが、いくつかの構造が関連しないことを意味する場合。例えば、ヒントトラック構造は、ヒントトラックにおけるプロトコルのファイル配信（ストリーミング等）のためのコンテンツを作成するか、そのファイル配信を実行する製品のみに関連する。
【００１６】
特定のブランドを実装するファイル読み取り器は、そのブランドに適合すると表示されるファイルの読み取りを試行するべきである。
【００１７】
ヒントトラック（Hint Track）は、通常はメディアデータを含まない特別なトラックである。代わりに、ヒントトラックは、１つまたはそれ以上のトラックを、特定の通信プロトコルにおいて配信するために、パッケージするための命令を含む。パケットを送信するプロセスは時間ベースであり、また、時間ベースのデータ表示に実質的に等しく、したがって、トラックによって適切に記述されうる。ヒントトラックの存在によって、送信機の動作負荷は低減され、また、送信機の実装は、任意のヒントを含まずにメディアサンプルからプロトコルデータユニット（Protocol Data Unit）を構築する送信機に比べて単純であることが可能である。
【００１８】
ISOベースのメディアファイルフォーマットは、リアルタイムプロトコル（Real-Time Protocol; RTP）およびセキュアリアルタイムトランスポートロトコル（Secure Real-Time Transport Protocol; SRTP）に関するヒントトラック定義を含んでおり、ISOベースのメディアファイルフォーマットに関する将来の修正２（amendment 2）は、FLUTEおよびALCプロトコルに関するヒントトラック定義を含む。MPEG-2トランスポートストリーム（transport stream; TS）のヒントトラックフォーマットも、例えば、DVBファイルフォーマットの一部として特定され得る。
【００１９】
図2に示すmdatボックスは、トラックのサンプルを含む。非ヒントトラックでは、サンプルは、映像の個々のフレーム、時間的に連続した映像フレーム、時間的に連続した音声圧縮部分である。ヒントトラックでは、サンプルは、ヒントトラックのヘッダにおいて識別される通信プロトコルに準拠してフォーマット化される１つ以上のパケットの形成を規定する。
【００２０】
ヒントトラックは、サンプルのタイミングや同期用サンプルの標示等の、通常のメディアトラックの特徴の全てを受け継ぐ。ヒントサンプル（Hint Sample）は、伝送用パケットを送信機が構成することを支援する命令を含む。これらの命令は、送信する直値（immediate data）（例えばヘッダ情報）や、メディアデータの参照セグメントを含みうる。言い換えると、メディアトラックにおけるメディアサンプルを、ヒントトラックのサンプルにコピーする必要はなく、むしろ、ヒントサンプルは、メディアトラックのサンプルを指し示す。ゆえに、メディアデータ自体を再フォーマット化する必要は全くない。この手法は、所定のトランスポートフォーマットやメディアフォーマットについて伝送される実際のデータユニットに、メディア情報を区分する必要がある手法よりも空間効率が良い。このような手法においては、ローカルの再生処理は、メディアをパケットから再構築することか、メディアについて２つのコピー（１つはローカルの再生処理用、もう１つはトランスポート用）を有することを必要とする。同様に、この手法を使用する多くのプロトコルにおけるこのようなメディアの伝送は、配信プロトコル毎にメディアデータの多数のコピーを必要とする。これは、メディアデータがトランスポートのために大幅に変換される場合（例えば、エラー訂正符号化技術や暗号化の適用によって変換される場合）を除き、空間に関して非効率的である。
【００２１】
ISOファイルがヒントトラックを含む場合、ヒントが構成されるメディアデータを参照するメディアトラックは、その中のデータがヒントトラックによって直接参照されなくてもファイルに残る。全ヒントトラックの削除後、非ヒントプレゼンテーション全体は残る。
【００２２】
図3は、一般的な映像通信システムの図である。非圧縮の映像が極めて大きな帯域幅を必要とするという事実により、入力映像300は、ソース符号器305によって所望のビットレートに圧縮される。ソース符号器305は、2つの構成要素（波形符号器310およびエントロピー符号器315）に分けることができる。波形符号器310は、非可逆映像信号圧縮を実行し、一方、エントロピー符号器315は、波形符号器310の出力をバイナリシーケンスに可逆的に変換する。トランスポート符号器320は、例えば、データをインターリーブおよび変調することによって、使用中のトランスポートプロトコルに準拠して、圧縮された映像をカプセル化する。データは、伝送チャネル325を介して受信機側に伝送される。受信機は、逆の動作を実行して、表示のために再構築される映像信号を入手する。逆の動作には、トランスポート復号器330と、エントロピー復号器340および波形復号器345に分けることができるソース復号器335との使用が含まれ、最終的に、出力映像350がもたらされる。
【００２３】
大部分の実チャネルは、伝送エラーの影響を受け易い。伝送エラーは、概略的に2つのカテゴリ（ビットエラーおよび消失エラー）に分類できる。ビットエラーは、雑音や干渉等の、伝送チャネルにおいて発生する物理的事象によって引き起こされる。リアルタイムメディアトランスポートのためのプロトコルスタックは、典型的には、ビットエラーを検出するために、巡回冗長検査（cyclic redundancy check; CRC）コード等のメカニズムを提供する。一般的に、エラーのあるプロトコルペイロードは、トランスポート復号器において破棄される。エラーを含む映像データの復号における課題は、バースト性ビットエラーの可能性、エラーの位置の厳密な検出、エントロピー符号器が使用する可変長符号化（variable length coding; VLC）にある。ビットエラーのバースト性により、大部分のプロトコルペイロードが、いずれにしても検出不可能である可能性があるため、プロトコルペイロード全体を破棄することは、全く不必要なデータ排除を引き起こすわけではない。通信プロトコルにより提供されるエラー検出メカニズムは、典型的には、バイナリ的な結論（パケットが破損しているか、パケットが正確であるか）を提供しうる。このため、エラーの厳密な位置を判断することは、ソース符号化層メカニズムに依存する。エラーの位置を検出するために、構文的、意味的、不自然なテクスチャに基づく様々な方法が存在するが、それでも、ビットエラーの誤検出によって、見て不自然な映像がもたらされることがある。可変長符号化に起因して、たった１つのビットエラーが、それが生成するコードワードの解釈を変更させ、後続のコードワードの同期化の損失を引き起こす可能性がある。コードワード同期化が再確立されたとしても、復号されたデータの空間的または時間的位置を判断することは不可能な場合もある。
【００２４】
消失エラーに関しては、2つの主な原因が存在する。第1に、ルーター等の混雑したネットワーク要素におけるキューのあふれが、パケット損失を引き起こす。第2に、トランスポート復号器が、通常、ビットエラーが発生するパケット全体を除去することによってパケットエラーを処理することに起因する。
【００２５】
一般に、発生した伝送エラーは、まず検出され、次いで、受信機によって訂正または隠蔽されるべきである。上述のように、ビットエラーは、典型的には、CRCまたは類似のコードを使用して検出され、破損したパケットは破棄される。リアルタイムメディアトランスポートの通信プロトコルは、典型的には、伝送されるパケット毎に１ずつ増分するシーケンス番号を付加する、パケット損失は、連続的なパケットのシーケンス番号値における空白から検出可能である。エラー訂正とは、最初からエラーがなかったかのように、エラーデータを完全に復元する機能をいう。エラー隠蔽（Error concealment）とは、再構築された映像において伝送エラーが不可視であるように、伝送エラーの影響を隠蔽する能力をいう。典型的には、ある量の冗長性が、エラーの検出、訂正、隠蔽に役立てるために、ソース符号化またはトランスポート符号化に付加される。
【００２６】
エラー訂正および隠蔽技術は、およそ３つのカテゴリ（順方向エラー隠蔽法、後処理によるエラー隠蔽法、双方向エラー隠蔽法）に分類可能である。順方向エラー隠蔽法（forward error concealment）は、送信機側が伝送データに冗長性を付加して、伝送エラーが存在したとしても、受信機が伝送データを容易に復元可能にする技術である。後処理によるエラー隠蔽法（error concealment by postprocessing）は、完全に受信機指向型である。これらの方法は、誤って受信したデータの正確な表現の推定を試行する。また、送信機および受信機は、伝送エラーの影響を最小限に抑えるために協働し得る。これらの方法は、受信機が提供するフィードバック情報を大いに利用する。後処理によるエラー隠蔽法は、受動的エラー隠蔽法（passive error concealment）とも呼ばれる。一方、他の2つのカテゴリは、能動的エラー隠蔽法に分類される。
【００２７】
エラー訂正および隠蔽アルゴリズムの直交分類（orthogonal classification）は、上述の分類に比べ、該当するアルゴリズムが動作するプロトコルスタック層に基づく。物理層における方法は、例えば、インテリジェントに変調を使用するか、または伝送されるデータビットをインターリーブする。リンク層における方法は、誤って受信したデータブロックを、例えば、選択的に再伝送するかもしれない。一般に、ソース符号器またはソース復号器を伴う方法は、メディアアウェアなエラー訂正および隠蔽アルゴリズム（Media-Aware Error Correction and Concealment Algorithm）と呼ばれ、一方、単に、トランスポート符号器および復号器において動作する方法は、メディアに依存する。いくつかのプロトコルスタック層の相互運用を必要とする方法は、交差層最適化アルゴリズム（Cross-Layer Optimization Algorithm）のカテゴリに入る。用語の「統合ソースチャネル符号化（Joint Source-Channel Coding）」は、ソースおよびトランスポート符号化が協働して伝送エラーにシームレスに対処するように動作する際に、使用される。
【００２８】
多くのリアルタイムマルチメディア通信アプリケーションでは、マルチメディアファイルがファイルとして伝送されるよりも、メディアデータが通信プロトコルのパケットにカプセル化される方が好ましい。さらに、既存のメディアプレーヤが、受信したメディアストリームから生成される如何なるマルチメディアファイルも解析、復号、再生可能であることが望ましい。もしどのようなマルチメディアファイルであっても、既存のメディアプレーヤによって再生可能であるならば、メディアプレーヤを更新・変更する必要はない。
【００２９】
全てではないが、大部分のコンテナファイルフォーマットは、再生デバイスへ確実に転送された、エラーの無いファイルの再生を目標とし、また、ストリーミングサーバや他の送信デバイスから伝送されうるメディアコンテンツを提供することを目標とする。結果的に、コンテナファイルフォーマットは、伝送エラーを標示するメカニズムを提供せず、既存のプレーヤが、エラーのあるメディアストリームに正常に対処可能であることが保証されない。代わりに、このようなプレーヤは、クラッシュする可能性があり、そうでない場合は、予想外の動作となる可能性がある。ゆえに、受信したメディアストリームから生成されたファイルが、既存のメディアプレーヤで再生されること、ならびに、既存のファイルフォーマットと互換性を有することが望ましい。さらに、高性能のプレーヤおよび復号器が、受信したストリームであってファイルに記録されるストリームから伝送エラーを効率的に隠蔽するためのメカニズムを含むことが望ましい。
【００３０】
上述の問題の少なくともいくつかに対処するための従来の手法が多数存在している。第1の手法では、受信したトランスポートストリームをファイル等に含めるか、別のファイルに格納する。そして、その別のファイルはプレゼンテーションファイル（すなわちメタデータを含むファイル）から参照される。この構成では、トランスポートストリームは、アプリケーションに関連すると考えられる最下位プロトコルスタック層を参照する。RTPベースのメディア伝送では、トランスポートストリームは、典型的には、RTPパケットのストリームを参照する。エレメンタリメディアストリームが、（例えばDVB-T、DVB-C、DVB-Sのように）MPEG-2トランスポートストリームにカプセル化される場合、トランスポートストリームは、MPEG-2トランスポートストリームを参照する。ISOベースのメディアファイルフォーマット構造では、トランスポートストリームは、単一のサンプルとしてメディアトラックへ含まれることができる。これは、MPEG-2トランスポートストリームがQuickTimeファイルに含まれる方法である。トランスポートストリームに特有のメタデータは、ファイルフォーマットの新しい構造に格納されてもよく、ISOベースのメディアファイルフォーマットでは、構造は、メタボックスに存在し得る。
【００３１】
第2の手法では、受信したトランスポートストリームは、エレメンタリデータトラックに変換される。トランスポートストリームに特有のメタデータは、ファイルフォーマット中の新しい構造に格納される。ISOベースのメディアファイルフォーマットでは、その構造はメタボックス内に存在する。
【００３２】
第3の手法では、受信したトランスポートパケットのストリームそれ自身が、それが記録されるファイルのヒントトラックに書き込まれる。しかしながら、ヒントトラックが、パケット化命令（packetization instruction）をサーバ、より一般的には、送信機に提供するため、ヒントトラックの使用は、論理的には有効なソリューションではない。さらに、記録されるヒントトラックは、再送信される有効なストリームを提供し得ない。例えば、RTPシーケンス番号は、伝送されるストリームにおいて連続的であることが必要とされるが、記録されるストリームにおいて、欠落パケットにより、RTPシーケンス番号における不連続性が発生する。
【００３３】
メディアデータの全てを受信した後にのみmoovボックスが完成可能であるという事情があるため、上述の第2の手法および第3の手法では、単一ファイルへの連続的な記録はできない。この問題は、2005年12月1日に出願された米国特許出願第11/292,786号において記載するように、ムービーフラグメントという特徴を使用して、記録ファイルを分割することにより、回避することができる。別の方法として、受信したストリームのメディアデータを、メタデータにとは別のファイルに記録することも可能である。しかしながら、記録されるファイルを時間的にシフトさせて同時に再生したい場合、米国特許出願第11/292,786号に記載のムービーフラグメントを使用するべきである。
【特許文献１】米国特許出願第11/292,786号明細書
【発明の概要】
【００３４】
本発明の種々の実施形態は、メディアパケットのストリームを受信し、メディアコンテンツを記録するためのシステムおよび方法を提供する。メディアコンテンツは、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、ファイルに記録される。受信したメディアパケットの少なくとも１つは、メディアパケットを構築するための命令を使用することによってファイル中に表される。また、ファイル中の少なくとも１つの受信したメディアパケットが、それがエラーを含みうるという標示に関連付けられる。
【００３５】
本発明の種々の実施形態は、受信したリアルタイムメディアストリームをマルチメディアコンテナファイルに格納するための、後方互換性のある（backward-compatible）メカニズムを提供する。実際は、これは、既存のプレーヤが、受信したストリームにおける復元可能な部分を正確に再生可能であることを意味する。受信したストリームにおける伝送エラーの識別および位置特定が可能になるため、高性能のプレーヤは、伝送エラーを効率的に隠蔽することが可能である。さらに、本発明の種々の実施形態は、記録されるファイルにおける任意のメディアデータの複製を回避する効果も奏する。本発明の種々の実施形態は、DVBファイルフォーマットに準拠して、事実上全ての受信機と併用して使用可能である。
【００３６】
本発明に関するこれらの利点および特徴ならびにその他の利点および特徴と、その動作のメカニズムおよび方式とは、添付の図面を併用して、以下の説明により、更に明白になるだろう。添付の図面において、同一の要素は同一の符号を有する。
【図面の簡単な説明】
【００３７】
【図１】マルチメディアファイルフォーマットの階層構造の図である。
【００３８】
【図２】ISOファイルの簡略化構造の図である。
【００３９】
【図３】一般的な映像通信システムの図である
【００４０】
【図４】本発明の種々の実施形態と使用するための汎用マルチメディア通信システムの図である。
【００４１】
【図５】本発明の種々の実施形態に従う受信機の簡略化版の動作を示すフローチャートである。
【００４２】
【図６】本発明の種々の実施形態の実装と併用して使用可能である電子デバイスの斜視図である。
【００４３】
【図７】図6の電子デバイスに含まれうる回路の略図である。
【発明を実施するための形態】
【００４４】
本発明の種々の実施形態は、メディアパケットのストリームを受信し、メディアコンテンツを記録するためのシステムおよび方法を提供する。メディアコンテンツは、メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、ファイルに記録される。受信したメディアパケットの少なくとも１つは、メディアパケットを構築するための命令を使用することによってファイル中に表される。また、ファイル中の少なくとも１つの受信したメディアパケットが、それがエラーを含みうるという標示に関連付けられる。
【００４５】
本発明の一実施形態によると、ストリームは、ファイルフォーマットの１つ以上のヒントトラックに記録され、受信したストリームからヒントトラックが生成されたということが、当該ヒントトラックにおいて具体的に示される。ヒントトラックは、受信したストリームに正確に対応するため、可能な限り効率的に伝送エラーに対処するための全てのメカニズムを、メディアプレーヤに提供する。例えば、ヒントトラックのサンプル構造（すなわちパケット構造）は、パケットのシーケンス番号を含み、そのシーケンス番号から、欠落パケットが識別可能になる。ISOベースのメディアファイルフォーマットのRTPヒントトラック構造が、本発明の種々の実施形態の受信ヒントトラックのために再利用される場合、シーケンス番号は、RTPパケットデータ構造のRTPシーケンスの構文要素に存在しうる。
【００４６】
本発明の第2の実施形態によると、受信したストリームを、有効なメディアトラック、すなわち、非標準的な伝送エラー検出メカニズムや対処メカニズムを利用せずに復号可能なメディアトラックに変換する。有効なメディアトラックの形成は、既存のメディアプレーヤが記録されるファイルを再生可能であることを保証する。また、１つ以上の特有のヒントトラックも形成される。可能である場合はいつでも、ヒントサンプルは、パケットペイロードのコピーを含むのではなく、メディアトラックのサンプルへの参照を含み、ファイルのストレージ空間の必要性を低減する。
【００４７】
有効なメディアトラックの形成によって、いくつかのパケットがまとめて省略（omission）される場合がある。例えば、符号化された映像ストリームにおける参照ピクチャが損失する場合、メディアトラックは、損失した参照ピクチャから直接的または間接的に予測される任意の画像をスキップするはずである。そこで、ヒントサンプルは、対応するメディアトラックには存在しないパケットペイロードのコピーを含んでもよい。
【００４８】
図4は、本発明の種々の実施形態が実装され得る汎用マルチメディア通信システムを図示したものである。図4に示すように、データソース100は、アナログフォーマット、非圧縮デジタルフォーマット、圧縮デジタルフォーマット、あるいはこれらのフォーマットの任意の組み合わせでソース信号を提供する。符号器110は、ソース信号を、符号化メディアビットストリームに符号化する。復号されるべきこのビットストリームは、事実上、いかなるタイプのネットワークに位置する遠隔デバイスによっても、直接的または間接的に受信可能であることに留意されたい。さらに、このビットストリームは、ローカルハードウェアまたはソフトウェアから受信可能である。符号器110は、音声および映像等の複数のメディアタイプを符号化可能であってもよく、異なるメディアタイプのソース信号を符号化するために複数の符号器110が必要とされてもよい。また、符号器110は、グラフィックスやテキストを合成して生成された入力を得てもよく、合成メディアの符号化ビットストリームを生成可能であってもよい。以下においては、説明を簡略化するために、１つのメディアタイプの１つの符号化メディアビットストリームの処理のみについて考察する。しかしながら、典型的には、リアルタイムブロードキャストサービスが、いくつかのストリーム（典型的には、少なくとも１つの音声、映像、テキストサブタイトルのストリーム）を含むことに留意されたい。また、システムが、多数の符号器を含んでもよいが、図4において、一般性を欠如することなく説明を簡略化するために、符号器110を１つだけ示すことに留意されたい。さらに、本明細書に含まれるテキストおよび例は、符号化プロセスを具体的に説明し得るが、同一の概念および原理が、対応する復号プロセスにも適用すること、その逆も同様であることを、当業者が理解することを理解されたい。
【００４９】
符号化（された）メディアビットストリームは、ストレージ120に転送される。ストレージ120は、符号化メディアビットストリームを格納するために、任意のタイプの大容量メモリを備えることができる。ストレージ120における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマット（Elementary Self-Contained Bitstream Format）であってもよく、または１つ以上の符号化メディアビットストリームがコンテナファイルにカプセル化されてもよい。いくつかのシステムは、「ライブ」で動作し、すなわち、ストレージを省略して、符号化メディアビットストリームを符号器110から送信機130に直接転送する。次いで、符号化メディアビットストリームは、必要に応じて送信機130（サーバとも呼ばれる）に転送される。伝送に使用するフォーマットは、エレメンタリ自立型ビットストリームフォーマットやパケットストリームフォーマット（Packet Stream Format）であってもよい。または、１つ以上の符号化メディアビットストリームが、コンテナファイルにカプセル化されてもよい。符号器110、ストレージ120、サーバ130は、同一の物理的デバイスに存在してもよく、別々のデバイスに備えられていてもよい。符号器110およびサーバ130は、ライブリアルタイムコンテンツで動作してもよく、この場合、符号化メディアビットストリームは、典型的には、永久的に格納されないが、コンテンツ符号器110および/またはサーバ130において短期間バッファリングされて、処理遅延、転送遅延、符号化メディアビットレートにおける変動を平滑化する。
【００５０】
サーバ130は、通信プロトコルスタックを使用して符号化メディアビットストリームを送信する。スタックには、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol; RTP）、ユーザデータグラムプロトコル（User Datagram Protocol; UDP）、インターネットプロトコル（Internet Protocol; IP）が含まれてもよいが、これらに限定されない。通信プロトコルスタックがパケット指向型である場合、サーバ130は、符号化メディアビットストリームをパケットにカプセル化する。例えば、RTPを使用する場合、サーバ130は、RTFペイロードフォーマットに準拠して、符号化メディアビットストリームをRTPパケットにカプセル化する。典型的には、各メディアタイプは、専用RTPペイロードフォーマットを有する。前述のように、システムが、複数のサーバ130を含んでもよいが、簡略化するために、以下の説明では１つのサーバ130についてのみ考察することに留意されたい。
【００５１】
サーバ130は、通信ネットワークを介してゲートウェイ140に接続されてもよく、または接続されなくてもよい。ゲートウェイ140は、一方の通信プロトコルスタックに準拠するパケットストリームの別の通信プロトコルスタックへの変換、データストリームの統合および分岐、ならびに優勢のダウンリンクネットワーク条件に準拠して転送されるストリームのビットレートの制御等の、ダウンリンク能力および/または受信機能力に従うデータストリームの操作等の、様々なタイプの機能を実行し得る。ゲートウェイ140の例として、マルチポイント会議制御ユニット（multipoint conference control unit; MCU）、回路交換およびパケット交換映像電話間のゲートウェイ、プッシュトゥートークオーバーセルラ（Push-to-talk over Cellular; PoC）サーバ、デジタル映像ブロードキャストハンドヘルド（digital video broadcasting-handheld; DVB-H）システムにおけるIPエンカプスレータ、家庭用無線ネットワームへ局所的にブロードキャスト伝送を転送するセットトップボックスが挙げられる。RTPを使用する際、ゲートウェイ140は、RTP混合器またはRTP変換器と呼ばれ、典型的には、RTP接続の終点としての役割を果たす。
【００５２】
システムは、１つ以上の受信機150を含む。この受信機は、典型的には、伝送された信号を受信し、受信し、復調し、符号化メディアビットストリームに非カプセル化することが可能である。符号化メディアビットストリームは、記録ストレージ155に転送される。記録ストレージは、符号化メディアビットストリームを格納するための大容量メモリを備えてもよい。記録ストレージ155は、代替的にまたは付加的に、ランダムアクセスメモリ等の計算メモリを備えてもよい。記録ストレージ155における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマットであってもよく、１つ以上の符号化メディアビットストリームが、コンテナファイルにカプセル化されてもよい。音声ストリームおよび映像ストリーム等の相互に関連付けられる多数の符号化メディアビットストリームが存在する場合、コンテナファイルは、典型的には使用され、受信機150は、入力ストリームからコンテナファイルを生成するコンテナファイル生成器を備えるか、コンテナファイル生成器に取り付けられる。いくつかのシステムは、「ライブ」で動作し、すなわち、記録ストレージ155を省略して、符号化メディアビットストリームを受信機150から復号器に130に直接転送する。システムによっては、記録されるストリームの直近の部分のみ、例えば、記録されるストリームの直近の10分が抜粋して記録ストレージ155に保持され、一方、それより前に記録される任意のデータは、記録ストレージ155から破棄される。
【００５３】
符号化メディアビットストリームは、記録ストレージ155から復号器160に転送される。音声ストリームおよび映像ストリーム等の、相互に関連付けられ、かつコンテナファイルにカプセル化される多くの符号化メディアビットストリームが存在する場合、ファイルパーサ（図示せず）を使用して、コンテナファイルから各符号化メディアビットストリームを非カプセル化する。記録ストレージ155または復号器160は、ファイルパーサ機能を備えてもよい。または、ファイルパーサは、記録ストレージ155または復号器160のいずれかに付加される。
【００５４】
符号化メディアビットストリームは、通常、復号器160によってさらに処理される。その出力は、１つ以上の非圧縮メディアストリームである。最後に、レンダラ170は、例えば、スピーカやディスプレイで非圧縮メディアストリームを再現してもよい。受信機150、記録ストレージ155、復号器160、レンダラ170は、同一の物理的デバイスに存在してもよく、別々のデバイスに含まれてもよい。
【００５５】
以下は、ISOベースのメディアファイルフォーマットにおいて、記録されるヒントトラックを示す方法に関する実装例である。この実装例では、記録されるヒントトラックは、サーバヒントトラック用の対応するサンプルエントリとは異なるサンプルエントリで示される。例えば、サーバ用のRTPヒントトラックは、サンプル記述"rtp"の中にエントリフォーマットを含むヒントトラック（メディアハンドラ「hint」）である。これに対して記録されるRTPヒントトラックは、サンプル記述"rrtp"の中にエントリフォーマットを含む。両方のサンプルエントリは、以下のように同一に記載される。
class RtpHintSampleEntryO extends SampleEntry ('rtp ') {
uint(16) hinttrackversion = 1 ;
uint(16) highestcompatibleversion = 1 ;
uint(32) maxpacketsize;
box additionaldata[ ];
}
class ReceivedRtpHintSampleEntry() extends SampleEntry ('rrtp') {
uint(16) hinttrackversion = 1 ;
uint(16) highestcompatibleversion = 1;
uint(32) maxpacketsize;
box additional data[ ];
【００５６】
サーバ用サンプルエントリフォーマットおよび記録されるもの用のサンプルエントリフォーマットの対は、SRTPやMPEG-2トランスポートストリーム（transport stream; TS）等のヒント可能なプロトコル毎に特定される。ヒントサンプルは、任意のプロトコルのサーバ用および記録されるもの用のヒントトラックフォーマットの各対について全く同じように特定されてもよい。任意のプロトコルのサーバ用および記録されるもの用のヒントトラックフォーマットの各対におけるヒントサンプルフォーマットの定義が同一であることによって、例えば、プログラミング言語のコードの種類またはマシンにより実行可能な命令の数の観点から、ソフトウェア実装のサイズを小さくしうる。しかしながら、記録されるヒントトラックのサンプルフォーマットを、同じプロトコルのサーバヒントトラックフォーマットとは異なるように設定することも有利であり得る。例えば、サーバは、伝送されるパケット毎に、（モジュロ演算において）値が１しか増えないと仮定している。すると、サーバヒントサンプルフォーマットのMPEG-2 TSパケットヘッダに、連続カウンタ（continuity_counter）フィールドを含むことは合理的ではないかもしれない。しかし、受信した後続パケットのcontinuity_counter値がとびとびになっていると、パケット損失の存在という結論を導き出すことが可能であるため、continuity_counterフィールドは、記録されるヒントサンプルフォーマットには必要とされる。
さらに、サーバヒントトラックにおいて使用する層とは異なるプロトコルスタック層において、記録されるヒントトラックフォーマットを特定することが合理的であるかもしれない。例えば、記録されるヒントサンプルが、インターネットプロトコル（IP）パケットに対応する場合、ファイルパーサは、ユーザデータグラムプトロコル（User Datagram Protocol; UDP）ヘッダのチェックサムを使用して、受信したパケットにおけるビットエラーの存在、すなわち、受信したパケットのインテグリティについて結論を出すことが可能である。代替的または補足的に、記録されるヒントサンプルは、対応するパケットフーマットには存在しないフィールドを含みうる。このようなフィールドは、例えば、下層プロトコルスタック層から情報を伝達するために使用され得る。このようなフィールドの一例は、記録されるRTPヒントサンプルのビットエラー標示フィールドであることができる。受信機は、UDPチェックサムまたは任意の下層プロトコルスタック層に存在する任意のCRCコードもしくはチェックサムに基づいて、ビットエラー標示フィールドを設定することができる。
【００５７】
図5は、本発明の種々の実施形態に従う受信機の簡略化版の動作を示すフローチャートである。しかしながら、受信機が多種多様の形式および構成を取ることが可能であることに留意されたい。図5のプロセスは、510において、受信したトランスポートパケットの受信機のバッファから、トランスポートパケットが取り出されることから開始する。さらに、トランスポートパケットは、第2のバッファに書き込まれる。第2のバッファは、本明細書において短期パケットバッファ（short-term packet buffer）と呼ばれる。トランスポートパケットは、RTPパケット、MPEG-2トランスポートストリームパケット、または任意の他のトランスポートプロトコルのパケットを含みうる。520において、パケットシーケンス番号の連続性が確認され、シーケンス番号の列に間が空いているか否かに関して判断が行なわれる。トランスポートパケットが、RTPに準拠してフォーマットされる場合、シーケンス番号（SN）は、RTPヘッダに存在する。トランスポートパケットがMPEG-2トランスポートストリームに準拠してフォーマットされる場合、シーケンス番号は、continuity_counterと呼ばれ、TSパケットヘッダに存在する。
【００５８】
シーケンス番号の列に間が空いてなく、短期パケットバッファにおけるパケットがビットエラーを含むとは識別されない場合、530において、映像フレームの、またはより一般的には、パケットが短期パケットバッファに現在格納中の映像アクセスユニットの、最終ペイロードバイトを現在のパケットが含むか否かに関して確認する。大部分の映像RTPペイロードにおいて、RTPヘッダのMビットは、符号化された映像フレームの最終ペイロードバイトをパケットが含むことを示すようになっている。映像フレームの最終パケットを検出する別の方式として、次のパケットのRTPタイムスタンプを確認することが挙げられる。次のRTPタイムスタンプが現在のRTPタイムスタンプと異なる場合、現在のパケットは、現在の符号化された映像フレームの最終ペイロードを含む。MPEG-2トランスポートストリームへのカプセル化が使用されている場合、次のトランスポートストリームパケットにおいて、payload_unit_start_indicator値が１に等しいことは、現在のTSパケットが、現在の符号化された映像フレームの最終ペイロードバイトを含むことを示す。現在のパケットが、映像フレームの最終パケットではない場合、プロセスは510に戻る。プロセス520および530が、符号化された映像データの復号順と伝送順が同一である場合にのみ動作することに留意されたい。伝送の順番がインターリーブされている場合、損失の検出や最終フレームの検出は、通常、受信したデータユニットの分析を必要とする。H.264/AVC映像において、伝送がインターリーブされている場合の損失検出の例が、3GPP Technical Recommendation 26.946（Release 6）、「Multimedia Broadcast/Multicast Service, User service guidelines」の第8章に提供されている。フレーム境界の検出については、H.264/AVC（すなわち、ITU-T Recommendation H 264）の第7.4.1.2.4節に明記されている。
【００５９】
さらに、図5に関する上記説明は、映像ストリームの観点から説明されていることに留意されたい。通常、音声は、多数のフレームから時間的に予測されるようにはなっておらず、音声フレーム全体が、１つのトランスポートパケットに含まれる。従って、上に説明した、次のランダムアクセスフレームの検索に対応する処理部分は、音声ストリームにおいては省略可能である。さらに、音声フレームが、常に１つのトランスポートパケットに適応する場合、書き込みプロセス530も省略可能であり、ステップ540は、音声サンプルをファイルに書き込む際に、欠落音声フレームを空きフレームと置換するように修正してもよい。
【００６０】
現在のパケットが、符号化された映像フレームの最終パケットである場合、540において、短期パケットバッファに収集されるパケットペイロードから、映像サンプルが引き出される。この引き出しプロセスは、パケットペイロードの単純な連結（Concatenation）を含むことが可能である。次いで、生成された映像サンプルがファイルに書き込まれる。通常、メタデータ（moovボックスまたはmoofボックス）が、出現の順番においてメディアデータに先行することから、映像サンプルが一時的ファイルにまず書き込まれ、その後、対応する全メタデータが完了すると生成される実際のファイルに、コピーされてもよいことに留意されたい。
【００６１】
550において、短期パケットバッファに格納されるパケットのそれぞれから、ヒントサンプルが生成される。540において生成された映像サンプルが、符号化された映像データを既に含むため、ヒントサンプルは、単に、映像トラック、生成された映像サンプル、映像サンプル内における適切なバイト領域を参照する。ヒントサンプルが、短期パケットバッファにおけるパケットの全てについて生成されると、バッファは空になり、プロセスは510に戻る。
【００６２】
520において、パケットのシーケンス番号に空白が検出されたり、短期パケットバッファにおけるいずれかのパケットにビットエラーが検出されたりする場合も、560において、短期パケットバッファに格納されるパケットの各々から、ヒントサンプルが生成される。しかしながら、短期パケットバッファにおけるパケットペイロードにエラーが存在するため、映像サンプルは、映像トラックへとは生成されない。したがって、パケットペイロードは、直コンストラクタメカニズム（immediate constructor mechanism）または「fat」ヒントトラックメカニズムのいずれかを使用して、ヒントサンプルにどうしても含まれることになる。直コンストラクタを使用する場合、ペイロードデータのコピーは、パケット化命令に含まれる。「fat」ヒントトラックを使用する場合、パケットペイロードは、ヒントトラックのmdat区分に含まれ、ヒントトラックのコンストラクタから参照される。ヒントサンプルが、短期パケットバッファにおける全パケットについて生成されると、バッファは空になる。
【００６３】
560の後、570において、受信したトランスポートパケットの次のパケットが、受信機のバッファから入手される。次いで、そのパケットは、
ランダムアクセスポイントをストリームに提供する、符号化された映像フレームをそのパケットが開始するか否かを判断するべく、調べられる。符号化された映像フレームの開始ポイントは、プロセス530に従って検出することができる。ランダムアクセスポイントの検出は、映像フォーマットおよびそそのペイロードフォーマットに依存する。例えば、H.264/AVCでは、独立復号リフレッシュ（independent decoding refresh; IDR）フレームが、パケットペイロードから容易にアクセス可能であるネットワーク抽象化層（network abstraction layer; NAL）単位ヘッダから識別可能となっている。H.264/AVCにより提供される別のランダムアクセスポイント標示メカニズムは、リカバリポイント補助的拡張情報（supplemental enhancement information; SEI）メッセージであり、これは、様々なタイプの段階的アクセス位置（gradual random access position）を示すことができる。ランダムアクセスポイントの標示に関する別の例が、その目的のための特定のフラグを含む、VC-IコーデックのRTPペイロードフォーマットに含まれている。ランダムアクセスポイントが標示される場合、プロセスは530から継続する。そうでない場合は、プロセスは、560から継続する。
【００６４】
上述のプロセスが、多数の方式で実装され得ることに留意されたい。例えば、受信プロセス中にメディアトラックが形成されず、ヒントトラックだけがファイルに形成される可能性がある。メディアトラックは、ストリームの受信の終了後に、オフラインで形成されることができる。メディアトラックのオフライン生成中、ヒントサンプル（メディアペイロードデータを含む）は、メディアトラックのサンプルにおけるデータを参照するように変化してもよく、変化しなくてもよい。図4を参照すると、メディアトラックのオフライン生成は、その入力を記録ストレージ155から入手し、復号器160に出力する、２つの追加のブロックをもたらしうる。処理順番における第1のブロックは、ファイル再書き込み部と考えることができ、これは、ヒントトラックのみ（メディアトラックは存在せず）を含むファイルを入力し、メディアトラックを含むファイルを出力する。処理順番における第2のブロックは、第2の記録ストレージと考えることができ、これは、記録ストレージ155と類似の特性を有し得る。
【００６５】
別の実装例は、受信中に中間フォーマットに記録することを含む。中間フォーマットは、受信したパケットの単純なストレージフォーマットを含むことが可能である。例えば、MPEG-2トランスポートストリームは、ファイル等に格納可能であり、RTPパケットも、パケットのサイズを示すいくつかのフレームがファイルに含まれる場合に格納可能である。中間フォーマットに準拠するファイルは、その後、ISOベースのメディアファイルフォーマットの或るバージョンまたはその派生等の、さらに構造化されたファイルフォーマットに変換可能である。変換プロセス中、上述の動作に似た動作を使用し得る。図4を参照する。この実装例は、記録ストレージ155からその入力を入手し、復号器160に出力する２つの追加のブロックが必要になり得る。処理順番における第1のブロックは、ファイル再書き込み部と考えることができ、これは、中間フォーマットに準拠してファイルを入力し、より構造化されたファイルフォーマットに準拠してファイルを出力する。処理順番における第2のブロックは、第2の記録ストレージと考えることができ、これは、記録ストレージ155と似た特性を有することができる。
【００６６】
上述のファイル再書き込み部および第2の記録ストレージは、受信機150や、記録ストレージ155、復号器160の中に設けられてもよいし、他のデバイスに存在してもよい。さらに、ファイル再書き込み部および第2の記録ストレージは、同一のデバイス内に設けられていてもよいし、それぞれ異なるデバイスに存在してもよい。
【００６７】
復号器160に含まれるまたは復号器160に付加されるファイルパーサおよび復号器160は、通常のファイルが解析・復号されるように動作しうる。つまり、メディアトラックおよびメディアサンプルのみが解析および復号され、ヒントトラックおよびヒントサンプルは省略されるように動作し得る。代替として、ファイルパーサおよび復号器160は、復号されたメディアビットストリームがリアルタイムで受信されるように動作し得る。言い換えると、ファイルパーサは、ヒントサンプルにおける命令に従ってパケットを構築し、パケットを復号器160に送出することが可能である。さらに、パケットを復号器160に送出する速度は、パケットの受信スケジュールに対応することが可能である。パケットのフォーマットは、送信機130から伝送されたパケットと同一であってもよいし、送信機から伝送されたパケットと同じ情報に加えて、下層プロトコルスタックからのデータを含みうるものであってもよい。復号器160は、図5を参照して上述したように、パケットの欠落や破損を検出する。復号器160は、エラー隠蔽および/またはエラー追跡アルゴリズムを適用することによって、欠落または破損パケットに対応し得る。さらに、復号器は、送信機130からのフィードバックプロトコルにより、欠落または破損パケットの回復または隠蔽を要求し得る。ファイルパーサおよび復号器160に関する他の配置も可能である。例えば、復号器160は、メディアトラックのメディアサンプルまたはヒントサンプルのそれぞれにそのデータが含まれる場合に、パケットが正しくまたは誤って復号可能であるかについて結論を出し得る。
【００６８】
ヒントトラックが１つ以上のメディアストリーム/型を含みうること、関連のメタデータも含みうることに留意されたい。例えば、音声および映像が、MPEG-2トランスポートストリームにおいてエレメンタリストリームとして搬送される場合、音声および映像は、同一のヒントトラックに記録可能である。さらに、MPEG-2特有の信号伝達も、同一のヒントトラックに含まれることが可能である。
【００６９】
さらに、トランスポートドメインにおいて動作する、暗号化/DRMシステムが存在することに留意されたい。このシステムは、パケットまたはパケットペイロードを、独立して、またはパケットのストリームとして暗号化可能である。（つまり、符号化されたメディアフレームとは対照的である。）提供されるDRM利用権利が、暗号化解除されたフォーマットにおいて、コンテンツの格納を拒否する場合、受信機は、メディアトラックを再構築せず、代わりに、受信したパケットを特別なヒントトラックに格納だけする。
【００７０】
本発明の種々の実施形態を組み込むおよび実装する通信デバイスは、種々の伝送技術を使用して通信してもよく、この通信技術には、符号分割多元接続（Code Division Multiple Access; CDMA）、モバイル通信のためのグローバルシステム（Global System for Mobile Communications; GSM）、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System; UMTS）、時分割多元接続（Time Division Multiple Access; TDMA）、周波数分割多元接続（Frequency Division Multiple Access; FDMA）、伝送制御プロトコル／インターネットプロトコル（Transmission Control Protocol/Internet Protocol; TCP/IP）、ショートメッセージサービス（Short Messaging Service; SMS）、マルチメディアメッセージサービス（Multimedia Messaging Service; MMS）、電子メール、インスタントメッセージサービス（Instant Messaging Service; IMS）、Bluetooth、IEEE 802.11等が含まれるが、これらに限定されない。本発明の種々の実施形態の実装に伴う通信デバイスは、無線接続、赤外線接続、レーザ接続、ケーブル接続、その同等物を含むが、これらに限定されない種々の媒体を使用して通信し得る。
【００７１】
図6および図7は、本発明が実装され得る１つの代表的な電子デバイス12を示す。しかしながら、本発明が、１つの特定の型の電子デバイス12に限定されるように意図されないことを理解されたい。図6および図7の電子デバイス12は、ハウジング30、液晶ディスプレイ形式のディスプレイ32、キーパッド34、マイクロホン36、イヤホン38、バッテリ40、赤外線ポート42、アンテナ44、本発明の一実施形態に従うUICC形式のスマートカード46、カード読み取り器48、無線インターフェース回路52、コーデック回路54、制御器56、メモリ58、電池80を含む。個々の回路および要素は、全て、当技術分野において、例えば、ノキアの種類の携帯電話機において周知のタイプである。
【００７２】
本明細書において説明する本発明の種々の実施形態は、方法ステップまたはプロセスの一般的な内容において説明された。これは、ネットワーク環境においてコンピュータにより実行されるプログラムコード等の、コンピュータにより実行可能な命令を含むプログラムであって、コンピュータ可読媒体に内蔵されるコンピュータによって、具現化され得る。概して、プログラムモジュールは、特定のタスクを実行するか、特定の抽象的なデータ型を実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造等を含みうる。コンピュータにより実行可能な命令、関連のデータ構造、プログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表す。特定の一連のこのような実行可能な命令または関連のデータ構造は、このようなステップまたはプロセスにおいて説明する機能を実装するための対応する動作の例を表す。
【００７３】
本発明の種々の実施形態のソフトウェアおよびウェブ実装は、種々のデータベース検索ステップまたはプロセス、相関ステップまたはプロセス、比較ステップまたはプロセス、ならびに決定ステップまたはプロセスを達成するために、法則ベースの論理および他の論理を含む標準的なプログラミング技術により達成することができる。本明細書および以下の請求項で使用する際、単語の「構成要素」および「モジュール」は、１つ以上の種類のソフトウェアコード、および/またはハードウェア実装、および/または手動入力を受信するための設備を使用する実装を包含するように意図されることに留意されたい。
【００７４】
本発明の実施形態に関する前述の説明は、例証目的および説明目的のために提示されている。前述の説明は、包括的であるように、または開示される厳密な形式に本発明の実施形態を限定するように意図されず、また、上記教示を考慮した修正および変形が可能であるか、または、これらの修正および変形は、本発明の実践により入手され得る。本明細書において論じられる実施形態は、本発明の種々の実施形態およびその実用的なアプリケーションに関する原理および性質を説明して、種々の実施形態における本発明および想定される特定の使用に適合する種々の修正を有する本発明を当業者が利用できるように、選択および説明されている。 
【図１】
2010526468.tif 000003
【図２】
2010526468.tif 000004
【図３】
2010526468.tif 000005
【図４】
2010526468.tif 000006
【図５】
2010526468.tif 000007
【図６】
2010526468.tif 000008
【図７】
2010526468.tif 000009
【手続補正書】
【提出日】平成21年11月24日(2009.11.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディアコンテンツを含むメディアパケットのストリームを受信することと、
メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録することと、
を含み、前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記ファイル中に少なくとも１つのヒントトラックのヒントサンプルで表され、前記ヒントサンプルは、メディアパケットがエラーを含むか否かの標示を含む、方法。
【請求項２】
前記ヒントサンプルは、前記ストリーム中の少なくとも１つのパケットの損失に関する標示を含む、請求項１に記載の方法。
【請求項３】
少なくとも１つのパケットの損失の後、前記メディアコンテンツの次のランダムアクセスポイントに達するまで、メディアパケットを表している個々のヒントサンプルが、前記メディアコンテンツがエラーを含むことを示す、請求項２に記載の方法。
【請求項４】
前記エラーは、前記ストリームの通信中のビットエラーかパケット損失の少なくともいずれかを表す、請求項１から３のいずれかに記載の方法。
【請求項５】
請求項１から４のいずれかに記載の方法をプロセッサに実行させる命令を備える、コンピュータプログラム。
【請求項６】
メディアコンテンツを含むメディアパケットのストリームを受信する手段と、
メディアパケットを構築するための命令を提供するファイルフォーマットに準拠して、前記メディアコンテンツをファイルに記録する手段と、
を備え、前記受信したメディアパケットのストリームにおける少なくとも１つのメディアパケットは、前記ファイル中に少なくとも１つのヒントトラックのヒントサンプルで表され、前記ヒントサンプルは、メディアパケットがエラーを含むか否かの標示を含む、装置。
【請求項７】
前記ヒントサンプルは、前記ストリーム中の少なくとも１つのパケットの損失に関する標示を含む、請求項６に記載の装置。
【請求項８】
少なくとも１つのパケットの損失の後、前記メディアコンテンツの次のランダムアクセスポイントに達するまで、メディアパケットを表している個々のヒントサンプルが、前記メディアコンテンツがエラーを含むことを示す、請求項７に記載の装置。
【請求項９】
前記エラーは、前記ストリームの通信中のビットエラーかパケット損失の少なくともいずれかを表す、請求項６から８のいずれかに記載の装置。
【請求項１０】
プロセッサとメモリユニットとを備え、前記メモリユニットが、請求項１から４のいずれかに記載の方法を前記プロセッサに実行させるコンピュータ命令を格納する、装置。
【国際調査報告】
2010526468.tif 000010
2010526468.tif 000011
2010526468.tif 000012