JP5112333B2

JP5112333B2 - メディアコンテナファイルの管理

Info

Publication number: JP5112333B2
Application number: JP2008549453A
Authority: JP
Inventors: ペルフレイェー，; トルステンローマル，; マグヌスウェステルルンド，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2006-01-05
Filing date: 2007-01-04
Publication date: 2013-01-09
Anticipated expiration: 2027-01-04
Also published as: CN101366287A; ATE551787T1; PL1969857T3; JP5542872B2; ES2392461T3; EP2421265B1; US8185794B2; WO2007078252A3; JP2012199974A; EP1969856A2; US20090089535A1; KR20080081954A; EP1969857A2; WO2007078252A2; KR101274422B1; CN101416526A; EP1969856B1; CN101416526B; EP2421265A1; KR20080083299A

Description

本発明は、一般に、メディア及びマルチメディアの管理に関し、特に、そのようなメディア及びマルチメディアコンテンツを含むメディアコンテナファイルの作成及び使用に関する。

メディア及びマルチメディアを種々のネットワークを介してクライアントへ提供することが過去数年で急増している。今日、例えば映像及び音声ストリーム又は映像及び音声ファイルの形式のメディアにアクセスするために及びそれらメディアをメディアサーバからダウンロードするために、多くのユーザがインターネットを採用している。このメディアの提供は、無線を使用するモバイル通信ネットワークにおいて開始された。現在、マルチメディア又はＴＶコンテンツに対してモバイルネットワークを使用することに非常に大きな関心がある。これは、多くの場合、従来技術においてモバイルＴＶと呼ばれる。今日、モバイルネットワークにおけるこのメディアの提供は、主にユニキャスト転送を介して利用可能である。しかし、現在、モバイルＴＶのブロードキャスト／マルチキャスト配信方法は開発中である。そのような標準化の取り組みの例は、３ＧＰＰのマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）及びヨーロッパ電気通信標準化協会（ＥＴＳＩ）のデジタルビデオブロードキャスト−ハンドヘルド（ＤＶＢ−Ｈ）である。

種々の有線及び無線通信ネットワークにおけるメディア提供に対する増加する要求に応じて、要求クライアントにメディアコンテンツを提供するために無線ネットワークにおいて利用可能なストリーミングサーバ及びダウンロードサーバの開発において進行中の作業がある。透過的で柔軟性のあるストリーミング／ダウンロードサーバに向かう一般的な傾向があり、それは、基本的にはサーバが種々のメディア管理機能を実行する複数の「標準」モジュール又はプログラムから構成されるべきであることを示す。それら機能に対する入力メディアコンテンツは、モジュール／プログラムがコンテンツを処理する方法に関する命令と共に提供される。これにより、サーバにおいて固定の定義済みメディア処理を使用することと比較してより柔軟性のあるメディア提供が提供される。

柔軟性のあるストリーミング／ダウンロードサーバの開発とともに、誤り訂正をどのようにメディアストリームに導入するかという分野で開発が行われている。マルチキャスト／ブロードキャスト送信は、一方向ではなく同時に多数の受信クライアントを対象とする。自動再送要求（ＡＲＱ：Auto Repeat reQuest）等の従来のユニキャストの信頼性手法は拡張可能ではなく、マルチキャスト／ブロードキャスト送信の多数の受信者にサービスすることはできない。

したがって、マルチキャスト／ブロードキャストのメディア送信の接続における信頼性手法の導入が必要である。このような信頼性手法は、柔軟なストリーミングサーバとダウンロードサーバのソリューションの流行においても導入すべきである。

本発明は、従来の構成のそれら欠点及び他の欠点を克服する。

本発明の一般的な目的は、マルチメディアセッションにおいて使用されるメディアコンテナファイルを提供することである。

本発明の別の目的は、セッション後の修理手順においても使用されるメディアコンテナファイルを提供することである。

それら目的及び他の目的は、添付の請求の範囲により規定される本発明により達成される。

簡単に説明すると、本発明は、メディアコンテナファイルの生成及び使用を含み、そのようなコンテナファイルを生成及び使用する装置を含む。

メディアコンテナファイルを生成することは、要求クライアントに送信され且つクライアントでレンダリングされるメディアデータ又はマルチメディアデータを含む少なくとも１つのメディアソースファイルを提供することを含む。このコンテナファイルは、ソースファイルのサイズに依存して、１つ以上のメディアソースブロックから構成されると考えられる。少なくとも１つのそのようなメディアソースブロックは、ソースブロックに基づいてＦＥＣ冗長データ又は記号を計算する目的で本発明に従って処理される。従って、ソースブロックのメディアデータは、少なくとも１つのＦＥＣ記号を計算するためにＦＥＣアルゴリズムに入力される。このＦＥＣ記号の計算は、ソースファイルのメディアソースブロック毎に実行されるのが好ましい。少なくとも１つのメディアソースブロックは、メディアコンテナファイルに編成される。同様に、計算されたＦＥＣデータは、メディアコンテナファイルにおいて１つ以上のＦＥＣリザーバに編成される。そのような各ＦＥＣリザーバは、特定のメディアソースブロックに対して計算されたＦＥＣデータを含む。メタデータは、メディアソースブロックとそのＦＥＣリザーバとの関係を提供するためにコンテナファイルに提供され且つ含まれる。

結果として得られるコンテナファイルは、コンテナファイル中のメタデータを使用してメディアデータ及びＦＥＣデータを含むデータパケットをコンパイルするために、メディアセッション中にメディアサーバにより採用される。ＦＥＣデータの事前計算、並びに本発明のコンテナファイルへのメディアデータ及びＦＥＣデータの編成により、メディアサーバは、広範囲にわたるデータ処理及び計算量の多いＦＥＣ計算なしで要求クライアントに送信されるデータパケットにメディアデータ及びＦＥＣデータを単純な計算コストの安価な方法で挿入できる。

好適な一実施形態において、コンテナファイルは、コンテナファイルのメディアデータ及びＦＥＣデータを含むデータパケットをコンパイルする場合にメディアサーバが使用し且つ従うコンパイル命令を更に含む。そのような場合、コンテナファイルは、メディアデータが確実にクライアントに正常に転送されるのに必要とされる全てのメディアコンテンツ、保護データ及び命令を含む。

本発明のコンテナファイルは、セッション後の修理手順において使用される。セッション後の修理手順において、ＦＥＣ冗長保護が送信されたデータパケットに含まれるにも関わらず、クライアントはメディアセッション中に全てのメディアデータを正常に受信できなかった。そのような場合、先行するメディアセッション中に使用された同一のコンテナファイルのコピーが修理サーバにより使用される。サーバは、クライアントからの要求に基づいてコンテナファイルの１つのＦＥＣリザーバからＦＥＣ冗長データを検索できる。このＦＥＣデータはクライアントに戻され、クライアントが全てのメディアデータを正常にレンダリングすることを可能にする。

添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。

図中、同一の図中符号は対応する要素又は類似する要素に対して使用される。

本発明は、一般に、メディア及びマルチメディアデータの管理に関し、特に、無線を使用する通信ネットワークにおけるストリーミングサーバ又はダウンロードサーバ等のメディアサーバと関連してコンテナファイルを作成及び利用することに関する。本発明のそれらメディアコンテナファイルは、要求クライアントに送信するメディアコンテンツと、メディアサーバにおいてメディア処理及び送信を実行するのに使用される命令とに加えて、メディアセッションに信頼性保護を提供するデータを有する。この信頼性保護は、コンテナファイルに含まれる予め生成された順方向誤り訂正（ＦＥＣ）冗長データの存在によって実現可能である。

この分野で周知のように、ＦＥＣは送信されたペイロードデータに冗長データを追加することを含み、それにより受信機は追加のデータを送信機に要求する必要なく誤りを検出及び訂正できる。ＦＥＣの利点は、平均して必要とされる帯域幅が大きくなるが、データの再送信が回避されることが多いことである。従って、ＦＥＣがメディアコンテンツのマルチキャスト／ブロードキャストによる配信に関連して使用されるのが有利であり、この場合、再送信が行なわれにくくなる。

ＦＥＣは、従来技術においては通常ＦＥＣコーデックである所定のアルゴリズム又は方式を使用して送信される情報に冗長性を追加することにより達成される。そのような各冗長ビットは、常に多くの元の情報又はペイロードビットの複素関数である。出力に未変更の入力を含むＦＥＣコーデックは、システムコーデックと呼ばれる。換言すると、（Ｎ，Ｋ）システムＦＥＣコーデックは、Ｋ個のソース記号又はペイロード記号を保存し、（Ｎ−Ｋ）個のＦＥＣ記号を付加する。同様に、（Ｎ，Ｋ）非システムＦＥＣコーデックは、必ずしも全てを保存されているわけではないＫ個のソース記号からＮ個の（ＦＥＣ又はソース）記号を作成する。

ＦＥＣコーデックには、ブロックコード及び冗長コードの２つの主な分類がある。ＦＥＣブロックコーデックは、所定サイズのビット又は記号の固定サイズブロック（パケット）に対して動作し、重畳コーデックは、任意の長さのビットストリーム又は記号ストリームに対して動作する。Digital FountainのRaptor符号は、単一のソースブロックから任意の数のＦＥＣ冗長記号を作成できるＦＥＣブロックコーデックである。ソースブロックの構成を全く変更しないで様々な保護オーバヘッドの構成を生成することができるため、このことは、このＦＥＣコーデックの有利な特性である。しかし、リードソロモンは、保護オーバヘッドの種々の大きさに対してソースブロックの区分の変更を必要とする別のＦＥＣブロックコーデックである。ＦＥＣブロックコーデックの他の例には、ゴレイ、ＢＣＨ（Bose, Ray-Chaudhuri, Hocquenghem）及びハミングがある。本発明に関連して使用する好適なＦＥＣコーデックは、Digital Raptorコーデックである。

本発明によると、メディアデータ又はメディアコンテンツ、あるいはマルチメディアデータ又はマルチメディアコンテンツは、データのレンダリングのためにコンテンツ提供器又はサーバがクライアントに提供できる任意のデータを示す。一般的な好適な例は、映像データ及び音声データを含む。データは、事前に符号化された固定レートの音声又は映像コンテンツバージョンの形式でもよく、スケーラブルな音声又は映像コンテンツの形式でもよい。他のメディアの例としては、静止画（ＪＰＥＧ）、ビットマップ画像（ＧＩＦ及びＰＮＧ）、ベクターグラフィックス（ＳＶＧ）、並びに合成音声（ＳＰ−ＭＩＤＩ）及びテキスト（ＸＨＴＭＬ及びＳＭＩＬ）がある。

図１は、本発明に従ってメディアコンテナファイルを生成する方法を示すフローチャートである。このメディアコンテナファイルは、メディアコンテンツを提供し、メディアデータを送信可能なデータパケットに形成するために、メディアセッション中にメディアサーバにより使用される完全な入力パッケージと考えられる。従ってコンテナファイルは、メディアコンテンツ自体に加え、処理を実行し、メディアセッション中にメディアコンテンツの送信を可能にするためにメディアサーバにより必要とされる情報及び命令を含むのが好ましい。

方法はステップＳ１で開始する。Ｓ１では、少なくとも１つのメディアソースブロックが編成されコンテナファイルに格納される。コンテナファイルに３つ以上のメディアソースブロックが存在する場合、それらブロックは、映像ストリーム等の同一のメディアコンテンツファイル又はストリーム、並びに／あるいは異なるメディアファイル又はストリームの個別のメディアブロックと考えられてもよい。例えば、映像ストリームのいくつかのメディアソースブロック及び対応する関連する音声ストリームのいくつかのメディアブロックと考えられてもよい。少なくとも１つのメディアソースブロックは、クライアントに送出されることが意図されるメディアデータ又は記号を含み、それらはメディアコンテンツをユーザに提示するためにレンダリングされる。メディアブロックは固定の同一サイズであってもよく、あるいは２つ以上の多い場合は、少なくともその一部分が異なるビット／記号サイズであってもよい。

ステップＳ１においてコンテナファイルに編成された少なくとも１つのメディアブロックは、メディアセッション中にクライアントに送信される全てのメディアコンテンツデータを一括して含むのが好ましい。換言すると、コンテナファイルはマルチメディア表現全体に対するメディアデータを含む。従って、メディアコンテンツが音楽映像を含む場合、コンテナファイルは映像データを有するメディアソースブロック及び対応する音声データを有するメディアブロックを含むのが好ましい。しかし、１つの同一のメディアコンテンツが複数の潜在的なメディアバージョンで提供されてもよいことが本発明により理解される。例えば、音楽映像の映像部分は複数の事前符号化された映像バージョンで提供され、そのような各映像バージョンは、所定の帯域幅又はビットレートレベル又は間隔に関連して使用できるように適応される。従って、所定のメディアコンテンツの複数のバージョンがコンテナファイルに存在してもよい。そのような場合、そのような各メディアバージョンは１つ以上のメディアソースブロックから構成されると考えられる。複数のメディアバージョンがコンテナファイルにおいて入手可能であってもよいが、通常は、メディアセッション中の所定の時間においてそのようなバージョンは１つのみ使用され、例えば利用可能な帯域幅のレベルの変化に基づいてセッション中にメディアバージョンの切り替えが行なわれてもよい。

コンテナファイルのメディアコンテンツに信頼性保護を提供するために、次のステップＳ２は、ステップＳ１でコンテナファイルに編成されたメディアブロックのうち少なくとも１つのメディアソースブロックに基づいてＦＥＣ冗長データを事前計算する。この計算ステップＳ２において、digital fountain raptorコーデック等のＦＥＣブロックコーデックが採用されるのが好ましく、それはメディアブロック毎に動作する。しかし、重畳ＦＥＣコーデックが採用されてもよく、それは本発明の範囲内である。好適な一実現例において、ＦＥＣ冗長記号のセットは、少なくとも１つのメディアソースブロックに対して生成される。このＦＥＣ記号セットは、メディアソースブロックのソース記号に基づいて計算された１つのＦＥＣ記号、好ましくは複数のＦＥＣ記号を含むことができる。メディアソースブロックに対して計算するＦＥＣ記号の数は、採用されるＦＥＣコーデックの制限によって規定されるか、メディアソースブロックのメディアソース記号の数の関数であるか、あるいはコンテナファイルのサイズ制限等の他の基準により制限されてもよい。それら事前計算されたＦＥＣ冗長記号の一般的な概念は、信頼性保護をメディアセッションに提供するためにメディアセッション中に入手可能であり且つメディアサーバにより使用されるＦＥＣ記号のリザーバをコンテナファイルに提供することである。従って、メディアソースブロック毎のＦＥＣ記号の数はこの基準に基づいて判定されるのが好ましい。すなわち、信頼性保護を提供できる。

ステップＳ２で計算されたＦＥＣ冗長記号は、信頼性保護を提供するためにメディアセッション中に有用であることに加え、セッション後の修理手順又は修理セッションにおいて使用される。あるいは、ＦＥＣ冗長記号の専用のサブセットは、信頼性保護のためにメディアセッション中に利用可能であり、冗長記号の別のサブセットは、本明細書において更に詳細に説明されるセッション後の修理に専用である。従って、本発明は、同一のコンテナファイル（又はそのコピー）がメディアセッション中にメディアサーバにより使用され且つ修理セッション中に修理サーバにより使用されるという利点を有する。これは、メディア管理に関して高い柔軟性を与える。ＦＥＣコーデックの更なる情報に関しては文献［１］の付録Ｂを参照。その付録Ｂの教示は参考として本明細書に取り入れられている。

次のステップＳ３は、ステップＳ２で計算されたＦＥＣ冗長データをメディアソースブロックと共にコンテナファイルに編成する。このステップＳ３は、メディアソースブロックのＦＥＣ冗長記号をリザーバとしてコンテナファイルに格納するのが好ましい。ＦＥＣ冗長記号が信頼性保護及び修理後の目的のために生成された場合、それら記号は同一のＦＥＣリザーバに提供される。あるいは、第１のリザーバは信頼性の目的でＦＥＣ記号を含み、第２のリザーバは修理後のＦＥＣ記号を含む。

次のステップＳ４は、コンテナファイルに含まれるメタデータを提供する。このメタデータは、ステップＳ１でコンテナファイルに追加されたメディアソースブロックとステップＳ３でファイルに格納されたＦＥＣ冗長データとの関係を提供する。この関係は、ファイル内のメディアソースブロックの記憶場所からＦＥＣリザーバの記憶場所へのポインタ又はＦＥＣリザーバの記憶場所からメディアソースブロックの記憶場所へのポインタの形式である。従って、特定のメディアソースブロック又はコンテナファイル内のそのブロックの場所が与えられると、このメタデータはメディアソースブロックに基づいて計算された関連するＦＥＣ冗長データ又はファイル内のそのＦＥＣ冗長データの記憶場所の識別を可能にする。メディアソースブロックの識別子及び／又は関連するＦＥＣリザーバがコンテナファイルの事前定義済みの「標準」の場所に格納される場合、ポインタを採用する代わりに、メタデータはそれらメディアソースブロックの識別子及び／又は関連するＦＥＣリザーバを含むことができる。メタデータは、ファイルのメディアソースブロック及びＦＥＣリザーバの一方を識別するために使用され、その識別した場所に基づいて、メディアソースブロック及びＦＥＣリザーバのうちのもう一方が識別される。

メディアソースブロック毎の最後の２つのＦＥＣリザーバ（セッション中及びセッション後に使用するための）の場合、メタデータはメディアソースブロックと双方のＦＥＣリザーバとの関係を提供する情報を含むのが好ましい。これは、例えばセッション中のメタデータ及びセッション後のメタデータをメディアソースブロックに対するコンテナファイルにそれぞれ含むことにより実現される。

本発明の一般的な実現例において、ステップＳ１において、複数のメディアソースブロックがコンテナファイルに編成される。この場合、ステップＳ２〜ステップＳ４がそのような各メディアソースブロック又は少なくともメディアソースブロックの複数のグループに対して繰り返されるのが好ましい。これを線Ｌ１により概略的に示す。したがって、ステップＳ１においてＮ個のメディアソースブロックがコンテナファイルに編成される場合、ステップＳ２〜ステップＳ４はＮ回繰り返されるのが好ましく、これは、ソースブロックに加え、少なくともＮ個のＦＥＣリザーバとＮ個のメタデータのバージョンをコンテナファイルに編成することを示す。

本発明においては、メディアセッション全体に必要な全てのメディアデータ及びＦＥＣデータを生成されたメディアコンテナファイルが含んでもよいことが示される。しかし、メディアデータとＦＥＣデータは、実際には、複数の様々なセッションで適用してもよい。例えば、コンテナファイルは、音楽のビデオやフットボールの試合のようなメディアデータを含むことができる。このような場合、メディアデータは、必ずしも、ＦＥＣリザーバに含まれる全てのメディアデータを送信する必要はなく、クライアントが要求した特定のデータだけを送信すればよい。しかし、他のメディアサーバが同じコンテナファイルのコピーを受信して、代わりに、ファイル内の他のメディアデータをクライアントに提供してもよい。

その後、方法は終了する。

図１と関連して上述したコンテナファイルの生成は、内部又は外部メディアコンテンツソースへのアクセス権を有するコンテンツ作成器又はサーバにおいて実行されるのが好ましい。生成されたコンテナファイルは、例えばローカルシステム内の転送、あるいはローカル又はグローバルネットワークを介する送信のために、コンピュータメモリ等の記憶媒体、あるいは電子信号又は無線信号等の物理信号で表されてもよい。一般的な一実施形態において、コンテナファイルは、種々のクライアントとのメディアセッションにおいて使用するためにメディアサーバに無線信号として提供される。また必要ならば、これに代えて、または、これに加えて、メディアサーバとのメディアセッションの後に、受信したメディアコンテンツをセッション後に修理するために、クライアントがアクセス可能な、修理サーバにコンテナファイルを提供することができる。

以下において、メディアコンテナファイルという用語は、本開示において、記憶媒体に格納するためのデータファイル及び転送又は配信するための信号を含むという意味を含んで使用される。

図２は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、少なくとも１つのメディアソースファイルが提供されるステップＳ１０において開始する。図示される本実施形態において、メディアコンテンツは、メディアデータを含むソースファイル又はストリームの形式でコンテナファイル作成器において入手可能である。このステップＳ１０において、１つ以上のメディアソースファイルはコンテナファイルに含むために提供される。例えば、第１のメディアファイルは映像データを含むことができ、第２の関連するファイルは音声データを含む。ＦＥＣ冗長データの効率的な計算及びその後のそのようなＦＥＣデータの使用を可能にするために、次のステップＳ１１において、ステップＳ１０で提供されるメディアソースファイルは複数のメディアブロックに分割される。このメディアソースブロックは、メディアソースファイルのセグメントとして考えられ、ＦＥＣコードはそのセグメントに対して適用される。ソース記号又はデータビットでのメディアブロックのサイズは、分割に関連して事前定義されるか又は選択される。前者の場合、サイズはＦＥＣ冗長データの計算に採用される所期のＦＥＣ方式又はコードにより規定される。従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアファイル分割及びメディアブロックサイズに影響を与える可能性がある。

入力メディアソースファイルがＦＥＣコーデックにより効果的に処理される最大サイズより小さなサイズのビットサイズ又は記号サイズを有する場合、ソースファイルのメディアソースブロックへの分割は当然必要とされず、ステップＳ１１は省略される。入力メディアソースファイルは、本発明に係るメディアソースブロックとして考えられる。

尚、好適なブロックサイズがあるが、メディアソースファイルから生成される全てのメディアソースブロックがその好適なサイズである必要はない。例えば、メディアファイルの残りの部分が好適なブロックサイズに達する程の十分なメディアデータを含まないために、最後のメディアソースブロックは、他の同一サイズのブロックと比較して小さなサイズであってもよい。

この分割ステップＳ１１は、メディアソースファイルがコンテナファイルの別個の場所に格納される別個のメディアソースブロックに物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割される。例えば、ソース記号[0, N-1]が第１のソースブロックに属し、記号[N, 2N-1]が第２のソースブロックに属するように、２Ｎ個のソース記号を含むメディアソースファイルが分割される。

次に、方法は図１のステップＳ１に継続し、メディアソースブロックがコンテナファイルに編成される。

図３は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、ステップＳ２０において開始する。ステップＳ２０において、メディアソースブロックはソース記号、すなわちいわゆるチャンクに区分される。一般に、それら記号は数百バイトで構成される。このブロックの区分は、現在のメディアソースブロックに対するＦＥＣ記号を計算するために使用されるＦＥＣコーデック／アルゴリズムの情報に少なくとも部分的に基づいて実行されるのが好ましい。上述したように、リードソロモンを使用するＦＥＣコードは、所望の保護オーバヘッドの大きさ、すなわちＦＥＣ冗長記号の数に基づいてソースブロック区分の変更を必要とする。

従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアソース区分及びメディア記号サイズに影響を与える可能性がある。更に、メディアコンテンツを送信するためにメディアサーバにより使用されるユーザデータグラムプロトコル（ＵＤＰ）パケット等のデータパケットのサイズ等の他のパラメータは、このステップＳ２０のソースブロック区分において使用される。そのような場合、少なくとも１つの完全なソース記号がＵＤＰパケットに収まるように、ソース記号のサイズは制限される。

この区分ステップＳ２０は、メディアソースブロックがコンテナファイルの別個の場所に格納される別個のソース記号に物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割され、その結果、実質的にソース記号に区分される。

次のステップＳ２１において、区分の情報が生成される。基本的にこの情報は、データシーケンスのどの部分がメディアソースブロックのどのソース記号に属するかを特定する。区分情報は、メディアソースブロックＺのビットＸ〜ビットＹがソース記号を構成することを特定するテーブルに編成されてもよい。あるいは、情報は各ソース記号のバイトサイズを含むことができる。メディアファイルのメディアソースブロックの開始場所が分かると、種々のソース記号に属するデータ部分を判定できる。

方法は、ステップＳ２に継続する。ステップＳ２において、区分記号はＦＥＣデータを計算するためにメディアソースブロックと共に使用される。従って、区分情報により、ＦＥＣ記号を生成するためにＦＥＣコーデックに入力されるべきメディアソースブロックのデータ部分の識別が可能になる。

上述したように、本発明の目的は、実際のメディアデータに加えて信頼性保護（事前計算されたＦＥＣデータ）を含むメディアコンテナファイルを提供することである。これは、ファイルからソースブロックへの分割、ブロック区分及びＦＥＣ保護の計算が「オフライン」で行なわれ且つメディアサーバにおける実際のメディア送信処理とは無関係であることを意味する。この前処理は、サーバのタスクを簡単化し、性能要求及びサーバの複雑さを軽減する。更にコンテナファイルは、メディアデータ及びＦＥＣデータを識別し且つ要求クライアントに送信されるメディアストリームに構成するためにメディアサーバにより必要とされる情報及び命令を更に含むのが好ましい。更にコンテナファイルは、メディアセッション完了後の修理後の処理において有用なＦＥＣデータを識別及び構成するために修理サーバにより必要とされる情報及び命令を含むのが好ましい。従って、コンテナファイルは、データのコンパイル及び送信のために透過的で柔軟性のあるサーバにより使用されるデータ、情報及び命令の完全なパッケージとして考えられる。

図４は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、図１のステップＳ４から継続する。次のステップＳ３０において、ＦＥＣ冗長データの計算に採用される方式のＦＥＣアルゴリズムの情報が提供される。この情報は、特定のアルゴリズムの名前又は他の記述情報の形式である。別の方法において、利用可能な各ＦＥＣアルゴリズムは事前定義済み識別子を有する。従って、このＦＥＣ識別子のみがステップＳ３０において提供されてもよい。一般的な実現例において、同一のＦＥＣコーデックが、メディアソースファイルの全てのメディアソースブロックに対する冗長データを判定するのに採用された。しかし、所定のメディアソースファイルの種々のメディアソースブロック又は種々のソースファイルのメディアソースブロックに対して種々のＦＥＣコーデックを使用することが実際に可能である。従って、ＦＥＣ情報は、単一のＦＥＣコーデックによりＦＥＣ記号を生成するため、あるいは種々のＦＥＣコーデックが使用されたソースブロック又はソースブロックのグループを識別するためにコンテナファイルの全てのブロックが処理されたことを特定できる。

次のステップＳ３１において、特定のメディアソースファイル分割の情報が提供される。メディアデータパケットストリーム又はＦＥＣデータを要求クライアントに提供する場合、その情報はメディアサーバ又は修理サーバに対する関連性の情報である。

次のステップＳ３２において、プロパティテーブルが提供されるのが好ましい。このプロパティテーブルは、２つ以上のメディアソースファイル／ストリームがコンテナファイルに含まれる場合に特に有用であるが、単一のメディアソースファイルを含む時にも有利に使用される。通常、ファイルプロパティテーブルは、好ましくはメディアの多目的インターネットメール拡張仕様（ＭＩＭＥ）タイプであるメディアソースファイルのメディアタイプの情報を含む。従って、このＭＩＭＥ情報は、メディアが同期マルチメディア統合言語（ＳＭＩＬ）を含む音声メディア、映像メディア又は他のメディアタイプであることを特定できる。このＭＩＭＥタイプは、コンテナファイルに実際に含まれるデータタイプの情報をメディアサーバに提供する。プロパティテーブルは、gzipを含むメディアデータに対して採用される任意の符号化方式の情報を更に含むことができる。また、サイズ情報がプロパティテーブルに含まれる。このサイズ情報は、バイト数又は記号数に関する各メディアソースファイルの合計サイズ、ソースファイルのメディアソースブロックの各サイズ（基本的に、ステップＳ３１で提供される分割情報に対応する）、データを送信する際に使用されるデータパケットに対する最大ペイロードサイズ又は対象ペイロードサイズ、メディアソース記号のサイズ（バイト）（基本的に、図３のステップＳ２１で生成される区分情報に対応する）及び／又はＦＥＣ記号等を指定できる。ファイル名又はファイル識別子は、コンテナファイルに含まれる各メディアソースファイルに対するプロパティテーブルに含まれるのが好ましい。

コンテナファイルの各メディアソースファイルの実際の記憶場所の情報は、プロパティテーブルにおいて見つけられるのが好ましい。この場所情報は、ソースファイルの第１のメディアソースブロックの開始位置を特定でき、残りのメディアブロックはコンテナファイルのその位置以降に見つけられる。図１のステップＳ４で生成され且つコンテナファイルのＦＥＣリザーバとメディアソースブロックとの関係を提供するメタデータは、プロパティテーブルに更に含まれる。同様に、採用されるブロック区分の情報及びＦＥＣ冗長データ計算に採用されるＦＥＣコードは、テーブルに含まれるのが好ましい。

従って、コンテナファイルのプロパティテーブルは、メディアソースに対する単一の情報ソースとして使用され、関連するメディアソースファイル／ブロックの位置を特定し、そのソースブロックに対するＦＥＣ冗長データ及びメディアセッション中のメディアパケットのコンパイルにおいて有用な他の情報を提供する。

次のステップＳ３３は、メディアサーバにより使用されるコンパイル命令を生成する。それら命令は、データパケットのメディアストリームを形成するために、関係するＦＥＣリザーバのＦＥＣ冗長データと、メディアソースブロックのメディアデータとのコンパイルを、ＦＥＣブロックの関係を提供するメタデータに基づいて規定するのに使用される。従って、それら命令は、信頼性保護を有する送信可能なメディアパケットストリームを構成するためにコンテナファイルに含まれる（メディアおよびＦＥＣ）データを使用する方法に関する命令を提供するヒント又はメタデータとして考えられる。それら命令は、メディアセッション中に要求クライアントに送信するのに適切なパケットにメディアデータ及びＦＥＣデータをコンパイルするために関係メタデータと共に使用される。従って、命令はメディアソースデータ及びＦＥＣデータのサーバ側の送信順を記述する。しかし、通常、命令はタイムスケジュール情報、対象／ソースアドレス又はポートの情報、あるいは他のセッション特有の情報を含まない。これは、コンテナファイル及びその中のコンパイル命令は特定のセッションに透過的であり、種々の受信クライアントとの複数の種々のセッションに対する１つのメディアサーバだけでなく、種々のメディアサーバによっても実際に使用される。

コンパイル命令はメディアソースブロックとＦＥＣリザーバのサブセットに適用でき、それは、そのような複数の命令がセッション中にメディアサーバにより読み出されて使用される必要があることを示す。あるいは、コンパイル命令は、単一のメディアソースファイル又は実際にはコンテナファイルの全てのメディアソースファイルに必要とされる全ての情報を含む。

ステップＳ３３において、コンパイル命令の２つ以上のセットが実際に生成されてもよい。そのような場合、種々の別の命令が提供されるため、メディアサーバは特定のメディアセッションに採用する特定の命令セットを判定する選択肢を有する。例えば、データ送信のために単一の送信チャネルを採用する場合、第１のコンパイル命令はメディアソースブロック及びＦＥＣデータの送信順を記述するのに使用される。第２の命令は、同一のメディアソースブロック及びＦＥＣデータに適用されるが、複数のチャネルが利用可能な場合にはコンパイル／送信順情報を提供し、これは、データが順次送信されるのではなく並列的に送信されることを示す。従って、いくつかのコンパイル命令は、種々の転送チャネル状態用の別の送信セッションを提供するために使用される。

同様に、別のコンパイル命令は、種々の信頼性保護オーバヘッドのために含まれる。例えば、第１のコンパイル命令は第１の最大保護オーバヘッドレベルに対するメディアソースブロック及びＦＥＣデータのコンパイル／送信順を記述するのに使用され、第２の命令は第２の異なるＦＥＣオーバヘッドレベルの同一のメディアソースブロックに対して使用される。この第２のＦＥＣオーバヘッドレベルが第１のレベルより高い（低い）場合、従来技術においても示されるようなより多くのＦＥＣ記号又はパリティ記号が所定の量のメディアソース記号に追加される。

ステップＳ３３では、メディアサーバが使用するコンパイル命令に加えて、修理サーバに適用可能なコンパイル命令を生成することができる。次に、これらの修理専用命令は、ＦＥＣ冗長データと可能な専用セッション後ＦＥＣ冗長データとの識別を可能にするセッション後修理サーバが主に採用し、以前のメディアセッション中に受信メディアデータを正しく受信できずに全てを復号できなかった要求クライアントに送信される。

次のステップＳ３４は、先のステップＳ３０〜ステップＳ３３及び好ましくは図３のステップＳ２１において提供及び生成される情報、テーブル及び命令をコンテナファイルに編成する。コンテナファイルは、要求クライアントへの送信のためにデータを識別及び構成するために、メディアサーバまたは修理サーバが必要とする「生」メディアデータ、ＦＥＣデータ及びメタデータの完全なセットを含む。その後、方法は終了する。

図１１は、本発明に係るメディアコンテナファイル１を示す概略図である。上述したように、コンテナファイル１は、複数のメディアソースファイル１０、１２、１４のメタデータを含み、そのようなＭ個のファイルを図示する。ここで、Ｍ≧１である。各ファイル１０、１２、１４のメディアデータは、複数のメディアソースブロック２０、２２、２４に分割されると考えられる。図中では、そのようなＱ₁個のブロック２０、２２、２４は、第１のメディアソースファイル１０に対して示されている。ここでＱ₁≧１である。そのような各メディアソースブロック２０、２２、２４は、ソース記号に分割されると考えられる。

コンテナファイル１は、メディアデータを含むメディアソースブロック２０、２２、２４に加え、信頼性保護を提供するためにメディアデータと関連して使用される予め計算されたＦＥＣ冗長データを含むＦＥＣリザーバ３０、３２、３４を含む。好適な一実現例において、各メディアソースブロックは、少なくとも一つの専用のＦＥＣリザーバ３０、３２、３４を含む。そのような場合、図中のＦＥＣリザーバ３０、３２、３４の数Ｎは、

である。これに代わる手法においては、各メディアソースファイル１０，１２，１４は、少なくとも一つの専用ＦＥＣリザーバを有しており、すなわちＮ≧Ｍである。このような場合、リザーバ３０，３２，３４の個々の部分または領域は、異なるメディアソースブロック２０，２２，２４が採用することができる。

ＦＥＣリザーバ３０、３２、３４内のＦＥＣデータを計算するときに基礎とする、メディアソースブロック２０、２２、２４とＦＥＣリザーバ３０、３２、３４との関係を提供する、本発明に係る関係メタデータ４０は、コンテナファイル１に更に提供される。図１１は、ファイル１におけるメタデータ４０の複数の異なる可能な場所を示す。第１の実施形態において、メタデータは関連するメディアソースブロック２０、２２、２４と関連して格納される。従って、ファイル中のメディアソースブロック２０、２２、２４の識別により、ソースブロック２０、２２、２４の各メタデータ４０の識別も可能になる。あるいは又はそれに加えて、メタデータ４０は各ＦＥＣリザーバ３０、３２、３４と共に格納される。したがって、各ＦＥＣリザーバ３０、３２、３４は、特定のＦＥＣリザーバ３０、３２、３４が適用される関連するメディアソースブロック２０、２２、２４の識別を可能にする結び付けられた関係メタデータ４０を有する。コンテナファイル１が好適なファイルプロパティテーブル６０を含む場合、関係メタデータ４０はそのテーブルに提供される。そのような場合、メディアサーバは、ファイルプロパティテーブル６０のみを調査して、メディアセッション中に使用する関連するメディアデータ及びＦＥＣデータの場所を識別してもよい。更なる可能な一実現例において、関係メタデータ４０は、図中でヒントトラックと示されている、コンテナファイル１の種々のコンパイル命令５０、５２、５４と関連して格納される。そのような場合、各ヒントトラック５０、５２、５４は、そのヒントトラック５０、５２、５４の命令により実現可能なメディアセッションに必要とされるメタデータ４０のみを含む必要がある。それら複数の可能な記憶場所の組合せが更に可能であり、本発明の範囲内である。

本発明のオプション的だが好適な実装においては、コンテナファイル１は、修理手順の間の使用に専用のコンパイル命令７０も備えており、これは図中で修理ヒントトラック７０と示されている。さらに、好適には、修理手順内で使用可能なセッション後ＦＥＣデータを備えるＦＥＣリザーバ３０，３２，３４を識別するのに有用な関連メタデータ４５をこのヒントトラック７０は備えており、ここでさらに説明する。

本発明の特定の一実施形態によると、メディアコンテナファイル１は、インタリーブユニットであり、漸進的なダウンロード又はストリーミングに対して最適化される。それにより、マルチメディア表現全体は、いわゆる漸進的なダウンロード又はストリーミングにより要求クライアントに送信及びダウンロードされる。

ＩＳＯに基づくメディアファイル形式［２］［３］［４］は、本発明のメディアコンテナファイルのファイル形式として採用されるのが有利である。別のコンテナファイル形式は、ＭＰ４ファイル形式、３ＧＰファイル形式及びＱｕｉｃｋＴｉｍｅ形式を含む。

ＡＬＣ（Asynchronous Layered Coding）は、大規模スケーラブル高信頼コンテンツ配信プロトコルである。これは、任意のバイナリオブジェクトの高信頼マルチキャスト配信のための基本プロトコルであり、３ＧＰＰ２のＢＣＭＣＳ（ブロードキャスト／マルチキャストサービス）及びＯＭＡ（Open Mobile Alliance）のＢＡＣ（Browser and Content）Ｂｒｏａｄｃａｓｔ（ＢＣＡＳＴ）ワーキンググループにおいてブロードキャスト／マルチキャストファイル配信のための必須のプロトコルとして採用された。

ＦＬＵＴＥ（File Delivery over Unidirectional Transport）は、ファイルの単一方向配信のためのプロトコルをＡＬＣに加えて構築及び規定し、３ＧＰＰのＭＢＭＳ及びＤＶＢ−ＨのＩＰデータキャスト（ＩＰＤＣ）においてブロードキャスト／マルチキャストファイル配信のための必須のプロトコルとして最近採用された。ＡＬＣ及びＦＬＵＴＥの双方は、インターネット技術標準化委員会（ＩＥＴＦ）により規定される。

ＦＬＵＴＥは、ＡＬＣセッションにおいて配信されるファイルと関連付けられるメタデータを保持するＦＤＴ（File Delivery Table）を規定し、ＦＤＴの帯域内の配信及び更新に対する機構を提供する。これに対して、ＡＬＣはファイルメタデータの帯域外の配信に対する他の手段に依存する。ＯＭＡのＢＣＡＳＴは、通常ＡＬＣセッションの十分前にクライアントに配信される電子サービスガイド（ＥＳＧ）を規定する。ファイルメタデータがＡＣＬセッション中に更新される必要がある場合、ＥＳＧのフラグメントはＥＳＧ配信／更新チャネルを使用することにより更新される。

ＡＬＣ又はＦＬＵＴＥを介して配信されるファイルは、ＩＳＯコンテナファイルに項目として格納される。Metaボックス及びその子ボックスにより、静的メディア（画像）及びＳＭＩＬ表現等の種々のデータ項目をＩＳＯに基づくメディアファイルに格納できる。それらボックスにより、ファイル名及びパスを項目に関連付けることが可能になり、ＩＳＯに基づくメディアファイルのファイルディレクトリ構造を信号で知らせることができる。

一般に、ファイルがＡＬＣ／ＦＬＵＴＥを介して送出される前の第１のステップは、それらファイルをソースブロック及びソース記号に区分することである。また、本発明に従ってＦＥＣ符号化パリティ記号が計算される。区分は、ＦＥＣ方式、対象パケットサイズ及び所望のＦＥＣオーバヘッドに依存してもよい。ＦＥＣ符号化を行うソースブロック毎に、パリティ記号のリザーバが事前に計算され、ＦＥＣ方式に関する情報及びソースファイル区分情報と共にＩＳＯに基づくメディアファイルに格納される。

ファイルの送信を容易にする次のステップは、ＡＬＣ／ＦＬＵＴＥセッション（セッション記述プロトコルを使用する）及び項目をＡＬＣ又はＦＬＵＴＥパケットに埋め込む方法を記述するマルチキャスト／ブロードキャストサーバに対する命令をＩＳＯに基づくメディアファイルが含むようにすることである。

一方ではファイル区分及びＦＥＣリザーバ、他方ではファイルの配信に対するヒントトラックが互いに無関係に使用される。前者は、ヒントトラックの設計を助長し、例えば種々のＦＥＣオーバヘッドを有する別のヒントトラックが同一のＦＥＣ記号を再利用することを可能にする。それらは、配信後の修理のためにソース記号と追加のＦＥＣ記号に別個にアクセスする手段を更に提供し、この修理はＡＬＣ／ＦＬＵＴＥまたは他のプロトコルを介した帯域外で実行してもよい。しかし、サーバがヒントトラック命令に従う場合の複雑さを軽減するために、ヒントトラックは、項目のデータ範囲又はヒントサンプルにコピーされたデータを直接参照する。

以下において、ＩＳＯに基づくメディアファイル形式の形態であり、ＡＬＣ／ＦＬＵＴＥを介する送信に適応された本発明に係るコンテナファイルの更に詳細な実現例を提供する。しかし、これは本発明の単なる例示として考えられるべきであり、この例に対する明らかな変形例及び変更例は本発明の範囲内である。

（ソースファイルとＦＥＣリザーバの格納）
ＡＬＣ／ＦＬＵＴＥを介する送信用のファイルは、コンテナファイルとして動作するＩＳＯに基づくメディアファイルの最上位のMetaボックス（「meta」）に項目として格納される。Item Locationボックス（「iloc」）は、各項目のファイルサイズと共にコンテナファイル内の各項目（メディアソースファイル）の実際の記憶場所を特定する。各項目のファイル名、コンテンツタイプ（ＭＩＭＥタイプ）等は、Item Informationボックス（「iinf」）により提供される。

同様に、計算前のＦＥＣリザーバが追加項目としてメタボックスに格納される。ソースファイルが複数のソースブロックに分割された場合、好適には、各ソースブロックのＦＥＣリザーバは別個の項目として格納される。ＦＥＣリザーバとオリジナルのソース項目との関係は、以下のセクションで説明するファイル配信（ＦＤ：File Delivery）Item Informationボックスに記録される。

（FD Item Informationボックス）
ソースファイルとＦＥＣリザーバの区分に関する詳細は、FD Item Informationボックス（「fiin」）において提供される。そのボックスは、ＦＤヒントトラックを採用するファイルに使用されるのが好ましく、また１つのみがMetaボックス（「meta」）に位置付けられるのが好ましい。これは以下のように定義される：
aligned(8) class FDItemInformationBox extends FullBox('fiin', version = 0, 0)
{
unsigned int(16) entry_count;
PartitionEntry[entry_count]partition_entries;
SessionGroupBox session_info;
GroupIdToNameBox group_id_to_name;
}
FD Item Informationボックスの各PartitionEntryは、特定のメディアソースファイルに対する特定のファイル区分と、ＦＥＣ符号化と、関係するＦＥＣリザーバと、メタデータとに関する詳細を提供する。別のＦＥＣリザーバ方式または区分がＩＳＯファイルにおいて使用される場合、１つのソースファイルに対して複数のエントリを提供できる。全ての区分エントリは黙示的に番号を付けられ、通常、第１のエントリは番号１を有する。

（区分エントリ）
ソースのPartition Entry（「paen」）は以下のように定義される：
aligned(8) class PartitionEntry extends Box('paen')
{
FilePartitionBox blocks_and_symbols;
FECReservoirBos FEC_symbol_locations;
}
これは、メディアソースファイルがどのようにＦＥＣ符号化されるかの全ての詳細をともに提供する２つのボックスを含むことができる。

（File Partitionボックス）
File Partitionボックス（「fpar」）は、ソースファイルを識別し、そのファイルのソースブロック及び記号への区分を提供する。定義は以下の通りである：
aligned(8) class FilePartitionBox extends FullBox('fpar', version = 0, 0)
{
unsigned int(16) item_ID;
unsigned int(16) packet_payload_size;
unsigned int(16) FEC_encoding_ID;
unsigned int(16) FEC_instance_ID;
usingned int(16) max_source_block_length;
unsigned int(16) encoding_symbol_length;
unsigned int(16) max_number_of_encoding_symbols;
string scheme_specific_info;
unsigned int(16) entry_count;
for (i=1; i ＜= entry_count; i++)
{
unsigned int(16) block_count;
unsigned int(32) block_size;
}
}

セマンティックス：
item_IDは、ソースファイルのitem_IDを示す。２つ以上のFile InformationエントリのFile Partitionボックスの同一のitem_IDを使用することにより、ソースファイルの別の区分とＦＥＣ符号化との少なくともいずれかを提供できる。

packet_payload_sizeは、区分アルゴリズムの対象ＦＬＵＴＥ又はＡＬＣパケットペイロードサイズを与える。尚、ＵＤＰパケットペイロードはＦＬＵＴＥ又はＡＬＣヘッダを更に含むためより大きい。

FEC_encoding_IDは、ＦＥＣ符号化方式を識別する。ゼロ値は、「Null-FEC」［５］としても周知の「Compact No-Code FEC方式」等のデフォルト方式に対応する。値１は、「MBMS FEC」［１］に対応するのが好ましい。

FEC_instance_IDは、Under-Specified FEC方式に使用されるＦＥＣ符号器のより特定的な識別を提供する。通常、この値はFully-Specified FEC方式に使用されない。Under-Specified FEC方式の更なる詳細は文献［５］を参照。

max_source_block_lengthは、メディアソースブロック毎のソース記号の最大数を与える。

encoding_symbol_lengthは、１つの符号化記号（ソース記号及びＦＥＣパリティ記号）のサイズ（バイト）を与える。１つの項目の全ての符号化記号は、長さが短い可能性のある最後の記号を除いて全て同一の長さを有するのが好ましい。

max_number_of_encoding_symbolsは、文献［５］に規定されるＦＥＣ符号化ＩＤ１２９のソースブロックに対して生成される符号化記号の最大数を与える。

scheme_specific_infoは、「FLUTEbis」における方式特有のオブジェクト転送情報（ＦＥＣ−ＯＴＩ方式特有の情報）のBase64で符号化されたヌルで終了する文字列である。情報の定義は、ＦＥＣ符号化ＩＤに依存する。

entry_countは、ソースファイルの区分を提供する(block_count, block_size)の対のリストのエントリ数を提供する。ファイルの先頭から開始し、各エントリは、ファイルの次のセグメントがソースブロック及びソース記号に分割される方法を示す。

block_countは、サイズblock_size（バイト）の連続するソースブロックの数を示す。記号サイズ（FEC Informationボックスで提供される）の倍数でないblock_sizeは、最後のソース記号がファイル項目に格納されていないパディングを含むことを示す。

（ＦＥＣリザーバボックス）
ＦＥＣリザーバボックス（「fecr」）は、メディアソースファイルと追加項目として格納されているＦＥＣリザーバとを関連づける。

aligned(8) class FECReservoirBox extends FullBox('fecr', version = 0, 0)
{
unsigned int(16) entry_count;
for (i=1; i ＜= entry_count; i++)
{
unsigned int(16) item_ID;
unsigned int(32) symbol_count;
}
}

セマンティクス：
entry_countは、各ＦＥＣリザーバのitem_IDを提供する（item_ID, symbol_count）の組のリストのエントリ数と、それが有するソース記号の数を与える。このリストはメディアソースファイルの最初のソースブロックに関連づけられたＦＥＣリザーバから始まって、ファイルを通して連続的に継続する。

（項目情報ボックス）
ブロードキャスト／マルチキャストファイルダウンロードプロトコル（ＡＬＣ／ＦＬＵＴＥ）を使用して内部に埋め込まれた個別のメディアを送信するために、サーバはその個別のメディアに対応するメタデータを更に送信するのが好ましい。メタデータは、ＦＬＵＴＥがブロードキャストプロトコルとして使用される場合はＦＤＴの一部として送出され、ＡＬＣがＯＭＡのＢＣＡＳＴのＥＳＧと共に使用される場合はＯＭＡのＢＣＡＳＴのＥＳＧの一部として送出される。

メタデータ情報の一部は実行中に作成されてもよいため、ＦＬＵＴＥ及びＡＬＣの双方に共通で固定のメタデータの一部に対するテンプレート構造は、項目情報エントリの第２のバージョンとして規定される。項目情報エントリのこのバージョンは、ソースファイル区分を有する項目に対する項目情報ボックスにおいて使用される。

aligned(8) class ItemInfoEntry extends FullBox('infe', version = 1, 0)
{
unsigned int(16) item_ID;
unsigned int(16) item_protection_index;
unsigned int(32) content_length;
unsigned int(32) transfer_length;
string item_name;
string content_type;
string content_location;
string content_encoding;
string content_MD5;
unsigned int(8) entry_count;
for (i=1; i ＜= entry_count; i++)
{
unsigned int(32) group_id;
}
}

セマンティックス：
item_idは、プライマリリソース（例えば、「xml」ボックスに含まれる拡張マークアップ言語（ＸＭＬ））に対して０又は以下の情報が規定される項目のＩＤを含む。

item_protection_indexは、非保護項目に対して０又はこの項目に適用される保護を規定する項目保護ボックスへの１で開始する指標（項目保護ボックスの第１のボックスは指標１を有する）を含む。

content_lengthは、（非符号化）ファイルの全体の長さ（バイト）を与える。

transfer_lengthは、（符号化）ファイルの全体の長さ（バイト）を与える。尚、コンテンツ符号化が適用されていない場合、転送の長さはコンテンツの長さと等しい（以下を参照）。

item_nameは、項目の記号名、すなわち項目（ソースファイル）のファイル名を含むＵＴＦ−８の文字で書かれたヌルで終了する文字列である。

content_typeは、ＭＩＭＥタイプの項目を有するＵＴＦ−８の文字で書かれたヌルで終了する文字列である。項目がコンテンツ符号化される場合（以下を参照）、ＭＩＭＥタイプはコンテンツ復号化後の項目を参照する。

content_locationは、HTTP/1.1［６］に規定されるようにファイルのＵＲＩを含むＵＴＦ−８の文字で書かれたヌルで終了する文字列である。

content_encodingは、バイナリファイルが符号化され、解釈される前に復号化される必要があることを示すために使用されるＵＴＦ−８の文字で書かれたヌルで終了する文字列である。値は、HTTP/1.1のコンテンツ符号化に対して規定される通りである。いくつかの可能な値は、「gzip」、「compress」及び「deflate」である。空文字列は、コンテンツ符号化がないことを示す。尚、項目は、コンテンツ符号化が適用された後に格納される。

content_MD5は、ファイルのＭＤ５ダイジェスト［６］［７］を含むＵＴＦ−８の文字で書かれたヌルで終了する文字列である。

entry_countは、以下のリストのエントリの数を与える。

group_IDは、ファイル項目が属するファイルグループを示す。

全てのフィールドが採用されるのが好ましい。しかし、フィールドの対応する値が提供されていないことを示すために、ヌルで終了する文字列がヌルのみを含むことが可能である。ボックスへの今後の拡張により、追加のフィールドが最後に追加されてもよい。

各項目に対するFile Informationボックスで提供される情報及びヒントトラックにより使用される項目のリストを考慮することにより、ＦＤＴ又はＥＳＧに必要とされるファイルエントリが構成される。

埋め込みメディアリソースのcontent_locationは、ＩＳＯに基づくメディアファイル形式［２］［３］の第８．４４．７節において規定されるＵＲＬ（ユニバーサルリソースロケータ）形式を使用することにより参照されてもよい。

（Session Groupボックス）
ＦＤセッションは、各々がＦＤヒントトラックにより記述されるいくつかのＦＤチャネルを介して同時に送出できる。Session Groupボックスは、セッションのリスト、並びに各セッションに属する全てのメディアファイルグループ及びヒントトラックを含む。コンテナファイルに２つ以上のＦＤヒントトラックが存在する場合、１つのSession GroupボックスがFD Item Informationボックスに存在するのが好ましい。

１つのセッショングループのみが随時処理されるべきである。セッショングループのリストされた第１のヒントトラックは、基本チャネルを特定する。メディアサーバがセッショングループ間の参照を有さない場合、通常、デフォルトの選択肢は第１のセッショングループである。ヒントトラックにより参照されるファイルを含む全てのファイルグループのグループＩＤは、ファイルグループのリストに含まれる。ファイルグループＩＤは、サーバによりＦＤＴに含まれるファイルグループ名に変換される（Group ID To Nameボックスを使用して）。

aligned(8) class SessionGroupBox extends Box('segr')
{
unsigned int(16) num_session_groups;
for(i=0; i ＜ num_session_groups; i++)
{
unsigned int(8) entry_count;
for (j=0; j ＜ entry_count; j++)
{
unsigned int(32) group_ID;
}
unsigned int(16) num_channels_in_session_group;
for(k=0; k ＜ num_channels_in_session_group; k++)
{
unsigned int(32) hint_track_id;
}
}
}

セマンティックス：
num_session_goupsは、セッショングループの数を特定する。

entry_countは、セッショングループが準拠する全てのファイルグループを含む以下のリスト中のエントリの数を与える。セッショングループは、各ソースファイルの項目情報エントリにより特定されるようなリストされたファイルグループに含まれる全てのファイルを含む。セッショングループに対するＦＤＴは、この構造でリストされるそれらグループのみを含むのが好ましい。

group_IDは、セッショングループが準拠するファイルグループを示す。

num_channels_in_session_groupsは、セッショングループのチャネルの数を特定する。num_channels_in_session_groupsの値は正数である。

hint_track_IDは、特定のセッショングループに属するＦＤヒントトラックのトラックＩＤを特定する。１つのＦＤヒントトラックは、１つのＬＣＴ（Layered Coding Transport）チャネルに対応する。

（Group ID To Nameボックス）
Group ID To Nameボックスは、ファイルグループ名を項目情報エントリにおいて使用されるファイルグループＩＤに関連付ける。

aligned(8) class GroupIdToNameBox extends FullBox('gitn', version = 0, 0)
{
unsigned int(32) entry_count;
for (i=1; i＜=entry_count; i++)
{
unsigned int(32) group_ID;
string group_name;
}
}

セマンティックス：
entry_countは、以下のリストのエントリの数を与える。

group_IDは、ファイルグループを示す。

group_nameは、対応するファイルグループ名を含むＵＴＦ−８の文字で書かれたヌルで終了する文字列である。

（ヒントトラックの形式）
ヒントトラック構造は、複数のデータ形式のヒントサンプルをサポートするために一般化される。ヒントトラックサンプルは、適切なタイプのパケットヘッダを構築するのに必要な任意のデータを含み、更にパケットに属するデータのメディアソースブロックへのポインタを含む。

（サンプルエントリの形式）
ＦＤヒントトラックは、「fdp」のサンプル記述におけるエントリ形式を有するヒントトラック（メディアハンドラ「hint」）である。「fdp」は、File Delivery Protocolの省略形である。FDHintSampleEntryは、SampleDescriptionBox（「stsd」）に含まれ、以下の構文を有する。

class FDHintSampleEntry() extends SampleEntry('fdp')
{
uint(16) hinttrackversion = 1;
uint(16) highestcompatibleversion = 1;
uint(16) partition_entry_ID;
uint(16) FEC_overhead;
box additionaldata[];
}

セマンティックス：
partition_entry_IDは、ＦＤ項目情報ボックスの区分エントリを示す。ゼロ値は、例えばＦＤＴに対するこのサンプルエントリと関連付けられる区分エントリが存在しないことを示す。

FEC_overheadは、ヒントサンプルにより使用される保護オーバヘッドの比率を示す固定の値８．８である。FEC_overheadを提供する目的は、メディアサーバがセッショングループ（及び対応するＦＤヒントトラック）を選択するのを助長するための特性を提供することである。

フィールド「hinttrackversion」及び「highestcompatibleversion」は、ＩＳＯに基づくメディアファイル形式［２］［３］の第１０．２節に説明される「RtpHintSampleEntry」と同様の解釈を有する。time_scale_entryボックスが追加のデータとして提供されてもよい。提供されない場合、パケットのタイミングに対して指示が与えられない。

ＦＤＴ又はＥＳＧに必要とされるファイルエントリは、ヒントトラックの全てのサンプルエントリ及び上記item_IDにより参照される項目の対応するFile Metadata Informationボックスを確認することにより作成される。サンプルエントリがいずれのサンプルによっても参照されない場合、それらはヒントトラックに含まれない。

なお、メディアサーバは、ファイルの各再送について、さまざまなＦＥＣ記号のセットを送信することが望ましい。

（サンプルの形式）
ヒントトラックの各ＦＤサンプルは１つ以上のＦＤパケットを生成する。各サンプルは、パケットを構成するための命令及びそれらパケットを送出する場合に必要とされる任意の追加のデータ（例えば、ソースファイル又はＦＥＣに対する項目に常駐するのではなく、サンプルにコピーされる符号化記号）の２つの領域を含む。尚、サンプルのサイズは、サンプルサイズテーブルから周知である。

aligned(8) class FDsample extends Box('fdsa')
{
FDPacketBox packetbox[]
ExtraDataBox extradata;
}
ＦＤサンプルのサンプル番号は、メディアサーバにより処理される順番を規定する。同様に、各ＦＤサンプルのＦＤパケットボックスは、処理される順番で現れる。Time Scale EntryボックスがFD Hint Sample Entryに存在する場合、サンプル時間は規定され、デフォルトビットレートに対するパケットの相対的な送出時間を提供する。実際の送信ビットレートに依存して、サーバは線形時間スケーリングを適用してもよい。サンプル時間は、スケジューリング処理を簡単化する可能性があるが、それはメディアサーバが時宜を得てパケットを送出することに依存する。

（パケットエントリの形式）
ＦＤサンプルの各パケットは、以下の構造［８］〜［１０］を有する：
aligned(8) class FDpacketBox extends Box('fdpa')
{
header_template LCT_header_info;
unsigned int(16) entrycount1;
dataentry header_extension_constructors[entrycount1];
unsigned int(16) entrycount2;
dataentry packet_constructors[entrycount2];
}
LCT_header_infoは、現在のＦＤパケットに対するＬＣＴヘッダテンプレートを含む。

entry_count1：以下のコンストラクタの数
header_extension_constructors：ＬＣＴヘッダ拡張を構成するために使用される構造体
entry_count2：以下のコンストラクタの数
packet_constructors：ＦＥＣペイロードＩＤ及びソース記号をＦＤパケットに構成するために使用される構造体。

（ＬＣＴヘッダテンプレートの形式）
class header_template
{
unsigned int(1) sender_current_time_present;
unsigned int(1) expected_residual_time_present;
unsigned int(1) session_close_bit;
unsigned int(1) object_close_bit;
unsigned int(4) reserved;
unsigned int(16) transport_object_identifier;
}
ＬＣＴヘッダテンプレートは、パケットのＬＣＴヘッダを形成するためにメディアサーバにより使用される。尚、ヘッダの一部分はサーバポリシーに依存し、テンプレートに含まれない。更に、いくつかのフィールドの長さは、サーバにより割り当てられたＬＣＴヘッダビットに依存する。サーバは、ＴＯＩの値を変更する必要がある可能性がある。

（ＬＣＴヘッダ拡張コンストラクタの形式）
尚、メディアサーバはEXT_FDTが存在するかを確認することによりＦＤＴを含むパケットを識別できる。

aligned(8) class LCTheaderextension
{
unsigned int(8) header_extension_type;
unsigned int(8) header_extension_length;
unsigned int(8) header_extension_content[];
}
header_extension_lengthは、３２ビットワードの倍数で表される。ゼロ値は、ヘッダがサーバにより生成されることを意味する。

header_extension_contentは、header_extension_lengthと等しい項目数である。

（パケットコンストラクタの形式）
種々のコンストラクタの形式が存在する。各コンストラクタは、繰り返しを容易にするために１６バイトである。最初の１バイトは、結合を区別するためのものである。この構造体は、ＩＳＯに基づくメディアファイル形式［２］［３］の第１０．３．２節に基づく。パケットコンストラクタは、ＦＤパケット内のソース記号とともにＦＥＣペイロードＩＤを含むように使用される。

aligned(8) class FDconstructor(type)
{
unsigned int(8) constructor_type = type;
}
aligned(8) class FDnoopconstructor extends FDconstructor(0)
{
unsigned int(8) pad[15];
}
aligned(8) class FDimmediateconstructor extends FDconstructor(1)
{
unsigned int(8) count;
unsigned int(8) data[count];
unsigned int(8) pad[14 - count];
}
aligned(8) class FDsampleconstructor extends FDconstructor(2)
{
signed int(8) trackrefindex;
unsigned int(16) length;
unsigned int(32) samplenumber;
unsigned int(32) sampleoffset;
unsigned int(16) bytesperblock = 1;
unsigned int(16) samplesperblock = 1;
}
aligned(8) class FDitemconstructor extends FDconstructor(3)
{
unsigned int(16) item_ID;
unsigned int(16) extent_index;
unsigned int(64) data_offset;
unsigned int(24) data_length;
}
aligned(8) class FDxmlboxconstructor extends FDconstructor(4)
{
unsigned int(64) data_offset;
unsigned int(32) data_length;
unsigned int(24) reserved;
}

（Extra Dataボックス）
ＦＤヒントトラックの各サンプルは、Extra Dataボックスに格納された追加のデータを含んでもよい。

aligned(8) class ExtraDataBox extends Box('extr')
{
bit(8) extradata[];
}
図５は、本発明に係るメディアセッション管理方法を示すフローチャートである。このメディアセッション管理は、ストリーミングサーバ又はダウンロードサーバ等のメディアサーバにおいて実行され、本発明のメディアコンテナファイルを使用する。方法は、メディアコンテナファイルが提供されるステップＳ４０において開始する。このファイルの提供は、メディアサーバの記憶場所からコンテナファイルを取り出すことにより実現されるが、これは、サーバがコンテンツ提供器又は作成器からファイルを事前に受信していることを示す。あるいは、メディアサーバは、メディアデータに対する要求と関連してコンテンツ提供器からのコンテナファイルを命令又は受信できる。

次のステップＳ４１において、メディアデータパケットは、コンテナファイルのメディアソースブロックからメディアデータを抽出し、ＦＥＣ冗長データをＦＥＣリザーバから抽出することによりコンパイルされる。このデータ抽出は、メディアソースブロックとＦＥＣリザーバとの関係を提供するコンテナファイル内のメタデータに基づいて実行される。したがって、メディアサーバは、メディアセッション中に送信するためにメディアデータの識別子を受信するのが好ましい。あるいは、コンテナファイルは、メディアソースの選択が必要ないように単一のメディアデータファイルのメディアデータのみを含んでもよい。いずれの場合においても、ファイルプロパティテーブル等のコンテナファイルに含まれる上述の情報は、メディアファイルの開始、すなわち送信が開始されるべき第１のメディアソースブロックを識別するために使用される。更に、コンテナファイルに含まれる更なる情報は、メディアデータ及びＦＥＣデータを組み合わせて、種々のクライアントに対する１つの無線チャネル又は複数のチャネルを介する無線送信に適応されたデータパケットに含める方法に関する命令として使用される。本発明のメタデータによれば、メディアデータが現に抽出されたメディアソースブロックが与えられた場合、パケットコンパイルステップＳ４１でそれからＦＥＣデータを抽出すべき関連づけられたＦＥＣリザーバを識別することが可能になる。

次のステップＳ４２において、ＦＥＣ信頼性保護を有するコンパイルされたメディアデータパケットは、好ましくはブロードキャスト又はマルチキャスト技術によりクライアントに送信され、クライアントにおいてメディアデータがレンダリングされる。メディアサーバの送信バッファが所定のレベルに到達すると、通常、パケット送信は開始される。しかし、メディアセッション中、他のパケットが送信される間、新しいデータパケットがコンパイルされて送信バッファに入力される。これを線Ｌ２により概略的に示す。

メディアデータの編成及び生成されたコンテナファイル、並びに事前に計算されたＦＥＣデータの提供により、メディアセッション中のメディアサーバの処理要求が低減される。従って、これにより、サーバが実行中にソースブロック構成及びＦＥＣ符号化を高速に実行する必要がないため、サーバの複雑さが軽減され、サーバに柔軟性が与えられる。これに対して、サーバは、計算前のソースとＦＥＣ記号を抽出するためにコンテナファイル内のメタデータと命令を使用し、ヘッダ情報を追加し、得られたデータパケットをクライアントに送信する。

その後、方法は終了する。

図６は、図４のセッション管理方法の追加のステップを示すフローチャートである。方法は、図５のステップＳ４０から継続する。次のステップＳ５０において、メディアセッションにおいてデータを送信するために現在採用できるＦＥＣオーバヘッド容量が判定される。この容量は、メディア送信のためにサーバに割り当て可能な帯域幅レベル、このメディア送信のために採用される無線記憶媒体に対する最小及び最大のビットレートレベル等に基づいて判定又は少なくとも推定される。実際には、従来技術において周知のデータ送信と関連してそのようなオーバヘッド容量を判定する任意の技術が、ステップＳ５０において採用されてもよい。

ＦＥＣオーバヘッド容量が判定されると、次のステップＳ５１は、判定されたオーバヘッド容量に基づいてコンパイル命令セットを選択する。メディアコンテナファイルは、所定のメディアコンテンツに使用されるコンパイル命令の複数の別のセットを含むが、種々のレベルのＦＥＣオーバヘッドを提供する。換言すると、基本的にそれら別のコンパイル命令は、メディアデータパケットをコンパイルする時にメディアデータに追加するＦＥＣ冗長データの量を規定する。許容されるＦＥＣオーバヘッドが大きくなると、より多くのＦＥＣデータが追加される。種々の別のコンパイル命令を有することにより、メディアサーバは、現在のオーバヘッドの制限を与えられる許容される最大のＦＥＣ保護を可能にするそれら命令を使用でき、それにより、単一のコンパイル命令のセットを使用する場合と比較して種々のクライアントでメディアデータを正常に受信及び復号化する機会が増加する。

方法は、図５のステップＳ４１に継続する。ステップＳ３２において、メディアデータパケットは、ステップＳ５１で選択されたコンパイル命令に基づいてメディアコンテンツデータ及び関連するＦＥＣデータからコンパイルされる。

図１２は、本発明の一実施形態に従って別のコンパイル命令の使用を示すために使用される本発明に係るメディアコンテナファイル１を示す概略図である。コンテナファイル１は、好ましくは複数（例えば２つ）のメディアソースブロックを含むメディアソースファイル１０を含む。本実施形態において、ソースファイル１０の各メディアソースブロックは、個々のソースブロックについて事前に計算されたＦＥＣ冗長データを有する関連するＦＥＣリザーバ３０，３２を有する。この図示される例において、コンテナファイル１は、種々のＦＥＣオーバヘッドのコンパイル命令を含む３つのヒントトラック５０、５２、５４を更に含む。例えば、１０％の冗長オーバヘッドが望ましい場合に第１のヒントトラック５０が使用され、第２のヒントトラック５２は約１２％のＦＥＣオーバヘッドを与え、第３のヒントトラック５４は１４％のＦＥＣオーバヘッドを与える。図中、文献［１］の付録Ｂにおいて提案されるソースブロック構成アルゴリズムが採用されている。第１のヒントトラック５０が選択される場合、データパケット８１、８２、８３、８４の第１のストリーム（図中、メディアソースブロック毎及びＦＥＣブロック毎に１つのデータパケットのみが示される）が生成される。しかし、第２のヒントトラック５２が使用される場合、データパケット９１、９２、９３、９４の第２のストリームが生成される。第１のストリーム８０と比較して、第２のストリーム９０はメディアソースブロック毎により大きなＦＥＣブロック、すなわちより多くのＦＥＣ冗長データを含む。しかし、各ソースブロックは２つのストリーム８０、９０に同一量のメディアデータを含む。

上述したように、メディアコンテナファイルは、複数のメディアソースファイル又は種々のメディアコンテンツを保持するファイルを含むことができる。図７は、そのような複数ファイルの解決策を使用する図５のコンパイルステップ及び送信ステップの一実施形態を示すフローチャートである。方法は、図５のステップＳ４０から継続する。次のステップＳ６０において、第１のメディアコンテンツファイル及び第１のＦＥＣリザーバのメディアデータパケットは、メタデータ及びその特定のメディアコンテンツに専用のコンパイル命令に基づいて生成される。パケット生成の結果は、第１のＦＥＣリザーバのＦＥＣデータ及び第１のセットのメディアコンテンツを含むデータパケットのストリームとして考えられる。このデータパケットの第１のセットは、ステップＳ６１において無線通信チャネル、好ましくはブロードキャスト又はマルチキャストチャネルを使用して要求クライアントに送信される。

しかし、現在のメディアセッションにおいて、コンテナファイルのセット又は第２のメディアソースファイルのメディアコンテンツがクライアントに送信されるべきである。その結果、第２のメディアソースファイルのメディアコンテンツデータ及び第２の関連するＦＥＣリザーバのＦＥＣ冗長データを含むデータパケットは、ステップＳ６２でそのコンテンツと関連付けられたメタデータ及びコンパイル命令に基づいて生成される。ステップＳ６３において、結果として得られるデータパケットは、上述のステップＳ６１でサーバにより採用された同一の無線通信チャネルを使用して送信される。従って、２つのデータパケットセットはデータパケットの連続ストリームとして送出される。

図８は、複数ファイルの解決策を使用する図５のコンパイルステップ及び送信ステップの追加の実施形態を示すフローチャートである。方法は、図５のステップＳ４０から継続する。次のステップＳ７０において、メディアデータパケットは、第１のメディアソースファイルのメディアコンテンツデータ及び第１のＦＥＣリザーバのＦＥＣデータを含むように生成される。このステップＳ７０は基本的に図７のステップＳ６０に対応し、本明細書において更なる説明は行なわない。次のステップＳ７１は図６のステップＳ６１に対応し、メディアコンテンツを含むデータパケットがコンテナファイルの第２のメディアソースファイル及び第２のＦＥＣリザーバから導出される。本実施形態において、メディアサーバは、２つのクライアントグループ（ＩＰマルチキャストグループ）を同時に管理できる。従って次のステップＳ７２において、メディアサーバは、第１の無線通信チャネルを使用して第１のメディアグループのクライアントメンバにステップＳ７０で生成されたデータパケットの第１のセット又はストリームを送信し、同時に又は少なくとも一部同時に第２の無線通信チャネルを使用して第２のメディアグループのクライアントメンバに第２のメディアデータパケットストリームを送信する。本実施形態において、２つのデータパケットセットは並列メディアストリームとして送出される。その後、方法は終了する。

本発明は、複数のメディアファイルのメディアデータが一括してコンパイルされ且つクライアントのグループに送信される状況を更に含む。そのような場合、複数のソースファイルのメディアデータは、メディアセッション中にメディアサーバにより共に管理される。これは特に、１つのメディアファイルが映像データを含み且つ第２のメディアファイルが関連する音声データを含む場合である。２つのファイルのメディアデータは、同一の無線通信チャネル又は異なるそのようなチャネルを使用して送信される。

図７及び図８に関連して上述した教示は、３つ以上のメディアソースファイル及びＦＥＣリザーバがコンテナファイルに含まれる場合に対処するように拡張できることが本発明により理解される。

図１３は、複数のメディアソースファイル１０、１２、１４及び複数のＦＥＣリザーバ３０、３２、３４を有するメディアコンテナファイル１を示す概略図である。コンテナファイル１は、ソースファイル１０、１２、１４からメディアコンテンツデータ及びリザーバ３０、３２、３４からＦＥＣデータを抽出するのに必要とされるコンパイル命令及びメタデータを有する２つのヒントトラック５０、５２を更に含む。

第１のヒントトラック５０は、複数のソースファイル１０、１２、１４及びＦＥＣリザーバ３０、３２、３４のメディアデータ及びＦＥＣデータを含むデータパケット８１、８２、９１、９２のストリームを構成する時にメディアサーバにより採用される。生成されたストリームは、無線チャネルを使用して要求クライアントに送信される（図７と比較する）。第２のヒントトラック５２は、複数のメディアグループが同時に管理されるべきである場合に採用される。従って、データパケット８１、８２、９１、９２の複数の並列ストリームは、ヒントトラック５２、ソースファイル１０、１２、１４及びＦＥＣリザーバ３０、３２、３４に基づいてメディアサーバにより生成される。

メディアコンテナファイルがファイルからブロックへの分割の情報、ブロック区分、ＦＥＣアルゴリズムの情報及び／又はファイルプロパティテーブル等の追加の情報を更に含む場合、メディアサーバはデータパケットの生成及び送信の際にその追加の情報を使用できる。

例えば、ブロック区分の情報は、コンテナファイルのメディアソースファイル及びブロックからメディアデータを抽出するためにメディアサーバによりメタデータと共に使用される。このように区分情報は、サーバがコンテナファイルの所望のメディアデータの正確な記憶場所を正確に識別するのを助長する。同様に、コンテナファイルからメディアデータ及びＦＥＣデータを抽出する時、ＦＥＣアルゴリズム情報はメディアサーバにとってメタデータと共に有用である。種々のＦＥＣアルゴリズムはメディアコンテンツのソース記号及びブロックへの種々の区分を必要とし、更に区分は保護オーバヘッドに依存する。従って、ＦＥＣアルゴリズムの情報及びＦＥＣデータを事前計算する時に採用される他のＦＥＣパラメータはメディアサーバにより使用可能である。

追加のデータ及び好ましくはメディアサーバにとって有用なＭＩＭＥタイプの情報、任意の符号化情報、サイズ情報等は、ファイルプロパティテーブルに含まれるか又は少なくとも公表される。好適な一実現例において、このプロパティテーブルは、メディアの抽出、データパケットのコンパイル及び送信と関連して有利な又は必要とされる情報を取得するためにメディアサーバによりアクセスされる単一情報又はルックアップソースを構成する。

本発明のメディアサーバは、修理後の処理に更に採用される。そのような場合、メディアコンテンツデータ及びＦＥＣデータがクライアントに送信（マルチキャスト）された後、ＦＥＣ冗長データがメディアストリームに含まれてるにも関わらず、クライアントは受信したメディア記号を正確に復号化できない可能性がある。図９は、そのような修理後の手順を規定する追加のステップを示すフローチャートである。一般にこの手順は、メディアセッション中のメディア送信が終了した後又は少なくともクライアントへのメディアデータの送信後に開始される。従って、方法は図５のステップＳ４２から継続する。次のステップＳ８０において、メディアサーバは、以前にサーバとのメディアセッションに関わっていたクライアントから発信されたセッション後の修理手順に対する要求を受信する。一般に、修理要求は正確に受信されたメディアデータの識別子を含む。この識別は、特定のメディアコンテンツの名前であってもよく且つ可能性としてコンテンツサーバがクライアントにより正常に受信されなかったコンテンツの部分をより詳細に識別するのを可能にする情報であってもよい。次のステップＳ８１において、サーバは、情報に基づいて識別されたＦＥＣリザーバからＦＥＣ冗長データを抽出するためにその情報を使用する。この抽出ステップＳ８１において、デフォルトでは、サーバは好ましくはユニキャストによるデータ送信を使用してステップＳ８２で要求クライアントに送信される所定の数のＦＥＣ記号を抽出できる。提供されたＦＥＣ記号がメディアコンテンツを正常に復号化するのに不十分である場合、クライアントはサーバのより多くのＦＥＣ記号を要求できる。あるいは、クライアントは、クライアントにおいてメディアコンテンツを正常に復号化するのに必要とされるＦＥＣ記号の数をサーバが少なくとも推定できるようにする情報をサーバに提供する。そのような場合、サーバは抽出ステップＳ８１でこの情報を使用するのが好ましく、抽出されたＦＥＣ記号はステップＳ８２でクライアントに送信される。

本発明のメディアコンテナファイルは、メディアセッションにおける使用後、専用のセッション後の修理手順においても採用される。図１０は、本発明のセッション後の修理方法を示すフローチャートである。方法はステップＳ９０において開始する。ステップＳ９０において、修理サーバは、以前にメディアセッションに関わっており且つメディアサーバからメディアデータを受信したクライアントからＦＥＣ冗長データに対する要求を受信する。ステップＳ９０で受信された要求は、修理サーバがメディアコンテナファイルを識別するのを可能にする識別子を含む。従って、次のステップＳ９１において、サーバは要求に基づいて関連するメディアコンテナファイル、一般には要求中の識別子を提供する。このコンテナファイルは、一般に先行するメディアセッションにおいてメディアサーバにより使用されたコンテナファイルのコピーであるため、送信されるが要求クライアントにおいて全てが正常に受信されるわけではないメディアデータ及びＦＥＣデータをそれぞれ含むメディアソースブロック及びＦＥＣリザーバを含む。コンテナファイルは、コンテンツ提供器／作成器から、あるいは先行するメディアセッションを実行するメディアサーバから実際に命令又は要求される。

修理サーバは、メタデータに基づいてステップＳ９２においてメディアコンテナファイルからＦＥＣ冗長データを抽出するために修理要求における識別子を使用する。好適な一実現例において、識別子は正確に受信されなかったメディアコンテンツ又は更に詳細な情報を含むメディアソースファイルの名前であってもよく、失われたメディアデータを含んでいた特定のメディアソースブロックの識別を含む。コンテナファイルのメタデータは、ＦＥＣデータが抽出されるべきであるコンテナファイルの少なくとも１つのＦＥＣリザーバを識別するために識別子と共に使用される。図９のステップＳ８１と関連して上述したように、修理サーバは、正常なデータ復号化のために必要とされるＦＥＣデータ量の推定値を通知される。あるいは、修理サーバは、デフォルト数のＦＥＣ記号を抽出及び送出し、それらデフォルト数の記号が十分でない場合にクライアントがより多くのＦＥＣデータを要求することを必要とする。

好適な一実現例において、コンテナファイルはセッション後の修理命令７０を含む。図１１を参照。それら命令は、ＦＥＣリザーバ３０、３２、３４から抽出されたＦＥＣデータを含むデータパケットをコンパイルするために修理サーバにより使用される。図示されるように、この抽出手順においてサーバにより使用されるメタデータ４５が含まれるか又はコンパイル命令７０の一部を構成できる。あるいは、メタデータ４５は、関連するメディアソースファイル１０、１２、１４、ＦＥＣリザーバ３０、３２、３４と関連して提供されるか、あるいはコンテナファイル１に含まれるファイルプロパティテーブル６０に提供される。

図１４は、本発明のメディアコンテナファイル１を生成又は使用する要素を示す通信ネットワークの概略図である。コンテンツサーバ１００は、メディアソースデータを受信するか又はメディアソースデータへのアクセス権を有し、メディアコンテナファイル１を構成するコンテンツ提供器又は作成器を表す。このコンテナファイル１のコピーは、図において移動端末により表される種々のクライアント４００、４１０、４２０に送信（マルチキャスト）されるＦＥＣデータ及びメディアを含むデータパケットをコンパイルするためにメディアセッションにおいてコンテナファイル１を使用するメディアサーバ２００に送出される。修理サーバ３００は、メディアサーバ２００とのメディアセッションの後に、モバイル端末４００の一つが接続することができる。このような場合、修理サーバ３００は、コンテナサーバ１００からのメディアコンテナファイル１のコピーを要求し、セッション後の修理手順にそれを使用する。

図１５は、本発明に係るメディアコンテンツサーバ１００を示す概略ブロック図である。コンテンツサーバ１００は、外部ユニットと通信するための機能性（送信機／受信機、変調器／復調器、符号器／復号器）を含むように構成される一般的な入出力（Ｉ／Ｏ）ユニット１１０を具備する。このＩ／Ｏユニット１１０は、特に入力メディアコンテンツを受信及びメディアコンテナファイルに対する要求を受信するように構成される。Ｉ／Ｏユニット１１０は、通信ネットワークにおいてそのようなコンテナファイルを他のサーバに送信する時にサーバ１００により採用される。

コンテンツサーバ１００は、本発明のメディアコンテナファイルを作成するように構成されるコンテナファイル作成器１２０を更に具備する。作成器１２０は、少なくとも１つのメディアソースブロックをメディアコンテナファイルに入力及び編成するように構成されるメディアブロックマネージャ１３０を含む。この少なくとも１つの入力ソースブロックは、コンテンツサーバ１００のファイル分割器１９０から提供されるのが好ましい。あるいは、少なくとも１つのソースブロックは、内部データ記憶装置１１５から検索され、Ｉ／Ｏユニット１１０を使用して外部メディアソース５００、５１０から提供される。

コンテンツサーバ１００のＦＥＣコーデック１６０は、ブロックマネージャ１３０によりコンテナファイルに入力されたメディアソースブロックに対するＦＥＣ冗長データを計算する。このＦＥＣコーデック１６０は、この計算手順において上述のＦＥＣアルゴリズムのうち任意のアルゴリズムを使用できる。コーデック１６０は、全ての冗長データの計算に対して所定のＦＥＣアルゴリズムを使用するように設定される。あるいは、コーデック１６０は、複数の種々のアルゴリズムに対するアクセス権を有することができるため、実際のアルゴリズムの選択肢を有する。アルゴリズムの選択は、ファイル分割器１９０により行なわれる特定のブロック分割、メディアソースブロックのデータのタイプ又は他のパラメータ等の種々のパラメータに基づいて実行される。コーデック１６０により計算されるＦＥＣデータは、メディアセッションにおける冗長データ及びセッション後の修正手順における修正データの双方として採用される。

結果として得られる計算されたＦＥＣデータ（記号）は、ファイル作成器１２０のＦＥＣデータマネージャ１４０に入力される。このＦＥＣマネージャ１４０は、メディアコンテナファイルの少なくとも１つのＦＥＣリザーバに入力ＦＥＣデータを編成する。好適な一実現例において、ＦＥＣコーデック１６０及びＦＥＣマネージャ１４０は、ブロックマネージャ１３０によりファイルに編成されたソースブロック毎にＦＥＣ記号を生成し、コンテナファイルのソースブロック毎に少なくとも１つのＦＥＣリザーバを提供する。

ファイルマネージャ１２０のメタデータマネージャ１５０は、メタデータをコンテナファイルに提供する。このメタデータは、ブロックマネージャ１３０により編成されたメディアソースブロックとＦＥＣマネージャ１４０により編成されたＦＥＣリザーバとの関係を提供する。

結果として得られるメディアコンテナファイルは、データ記憶装置１１５に少なくとも一時的に格納されるか、あるいはＩ／Ｏユニット１１０によりメディアサーバ又は修正サーバに送信される。

好適な一実現例において、入力メディアコンテンツは、ファイル分割器１９０に提供されるメディアソースファイルの形式である。この分割器１９０は、ソースファイルを１つ以上のソースブロックに分割する。分割器１９０は、種々の情報又はパラメータに基づいてそのファイル分割を行なう。例えばファイル分割は、ＦＥＣコーデック１６０により採用されるＦＥＣアルゴリズムに基づいて少なくとも部分的に判定される。そのような場合、ファイル分割器１９０は、そのようなＦＥＣアルゴリズムの情報へのアクセス権を有するのが好ましい。分割器１９０は、メディアソースファイルをＮ−１個のサイズが等しいメディアソースブロック及びＮ−１個のブロックより小さなサイズを有する可能性のある１つのメディアソースブロックに分割できる。

メディアファイルは、好ましくはファイル分割器によるデータの処理後にメディアデータに対して動作可能なブロック区分器１９５に更に入力される。この区分器１９５は、遅延せずに１つのメディアソースブロックに対して動作し、ブロックを所定のサイズのソース記号に区分する。このブロック区分は、ＦＥＣコーデック１６０により採用される特定のＦＥＣアルゴリズム又は方式に基づくのが好ましい。ブロック区分器１９５は、メディアセッション中にメディアサーバにより採用されるデータパケットにソース記号を収めるように適応された区分を実行するように更に動作可能である。従って、ＵＤＰパケットサイズ等のパケットサイズの情報は区分器１９５により採用される。

更に区分器１９５は、結果として得られるブロック区分の情報を生成する。この情報は、ＦＥＣ冗長データを生成する時に使用するためにＦＥＣコーデック１６０に転送される。

コンテンツサーバ１００のユニット１１０、１２０、１３０、１４０、１５０、１６０、１９０及び１９５は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１１０〜１９５が全て、通信システムの１つのネットワークノードのコンテンツサーバ１００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテンツサーバ１００の種々のユニット１１０〜１９５が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。

図１６は、図１５のコンテナファイル作成器１２０の一実施形態を更に詳細に示す概略ブロック図である。このファイル作成器１２０は、種々の情報データをコンテナファイルに含み且つ編成するための情報マネージャ１７０を更に含む。マネージャ１７０は、ＦＥＣコーデック１６０により使用されるＦＥＣアルゴリズムの情報、ファイル分割器１９０により使用されるファイル分割及び／又はファイルにおけるブロック区分器１９５のブロック区分を提供するのが好ましい。他の情報は、メディアタイプ、（ブロック及び／又は記号）サイズ情報、コンテンツ名又は識別子、場所情報、オプションの符号化情報等のメディアデータを記述するデータであってもよい。好適な一実施形態において、この情報は、可能性としてメタデータマネージャ１５０のメタデータと共にコンテナファイルに含まれるファイルプロパティテーブルに編成される。

ファイル作成器１２０の命令マネージャ１８０は、コンパイル命令を生成してコンテナファイルに挿入する。それら命令は、メタデータマネージャ１５０のメタデータに基づいて、メディアソースブロックのメディアデータ及びＦＥＣリザーバのＦＥＣデータをコンパイルするためにメディアサーバにより使用される情報を含む。マネージャ１８０は、ファイルのメディアコンテンツ毎に単一の命令又は命令セットを生成できる。あるいは、種々のＦＥＣオーバヘッドに適応された種々のそのような命令、種々のＦＥＣデータタイプ及び／又はメディアセッションにおいて採用される異なる数の無線通信チャネルが、マネージャ１８０により提供され且つコンテナファイルに編成される。

コンテナファイル作成器１２０のユニット１３０〜１８０は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１３０〜１８０が全て、コンテナファイル作成器１２０において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテナファイル作成器１２０の種々のユニット１２０〜１８０がコンテンツサーバ１００の他の場所に配置されてもよい。

図１７は、本発明に係るメディアセッションサーバ２００を示す概略ブロック図である。このメディアサーバ２００は、外部ユニットとの通信を実行するＩ／Ｏユニット２１０を具備する。このＩ／Ｏユニット２１０は、特にコンテンツサーバからのメディアファイルコンテナを要求及び受信するように構成される。更にＩ／Ｏユニット２１０は、種々のユーザクライアントからのメディアコンテンツに対する要求又は少なくともメディアコンテンツが送信されるべきクライアントの情報に対する要求を受信する。メディアサーバ２００によりコンパイルされるデータパケットは、Ｉ／Ｏユニット２１０によりそれらクライアントに送信される。

サーバ２００は、現在のセッションで使用するメディアコンテンツファイルを提供するメディアファイル提供器２２０を具備する。このファイル提供器２２０は、Ｉ／Ｏユニット２１０によりコンテンツ作成器に送信される特定のコンテナファイルに対する要求を生成してもよい。あるいは、提供器２２０は、メディアサーバ２２０に提供されたデータ記憶装置２６０から事前に受信したコンテナファイルを取り出す。

データパケットコンパイラ２３０は、メタデータと、好適には、提供器２２０からのコンテナファイルに含まれるコンパイル命令を使用して、ファイルからメディアデータ及びＦＥＣデータを抽出し、その抽出データを含むデータパケットを生成する。そのように生成されたデータパケットは、Ｉ／Ｏユニット２１０により送信される（Ｉ／Ｏユニット２１０からストリーム又はダウンロードされる）。

データパケットコンパイラ２３０は、このコンパイル処理中にファイルに含まれる他の情報（ＦＥＣアルゴリズム情報、分割／区分情報、サイズ情報、コンテンツ名、コンテンツ記憶情報）も使用することが好ましい。したがって、実際には、メディアデータおよびＦＥＣデータとともにデータパケットを生成するのに必要な全ての命令およびデータはコンテナファイル内で提供され、これにより柔軟で効率的なメディアセッション管理が可能になる。

種々のコンパイル命令は、所定のメディアコンテンツに対するファイルに含まれる。例えば、命令はチャネルに依存するか又は容量に依存する。前者の場合、利用可能な無線チャネルの数及び送信されるべき並列メディアストリームの数により、コンパイラ２３０が使用する実際のコンパイル命令が判定される。後者の場合、ＦＥＣ容量推定器２４０は、セッション中に採用されるＦＥＣオーバヘッドの最大量を推定するためにサーバ２００に含まれるのが好ましい。オーバヘッド容量がセッションにわたり変化するため、推定器２４０により実行されるオーバヘッドの推定はセッション中に動的に更新されるのが好ましい。セット選択器２５０は、使用するファイルにおいて利用可能な特定のコンパイル命令又はコンパイル命令の命令セットを選択するために推定器２４０からの容量推定値を使用する。パケットコンパイラ２３０は、メタデータ及びＦＥＣデータをデータパケットにコンパイルするためにこの命令（セット）を使用する。

メディアサーバ２００は、セッション後の修理手順でメディアサーバ２００が使用可能なＦＥＣマネージャ２７０を任意に備えてもよい。このような場合、Ｉ／Ｏユニット２１０は、サーバ２００が以前メディアとＦＥＣデータを送信したクライアントから発せられた修理要求を受信する。この要求は、Ｉ／Ｏユニット２１０からＦＥＣマネージャ２７０に転送される。マネージャ２７０は、例えば、データ記憶装置２６０に記憶されている、メディアコンテナファイルからのＦＥＣ冗長データ（記号）の識別及び抽出を行う要求を使用する。このセッション後のＦＥＣ抽出において、ＦＥＣマネージャ２７０は、正しいＦＥＣデータを識別することと、抽出されたＦＥＣデータをデータパケットにコンパイルすることとの少なくともいずれかを行うために、コンテナファイルに含まれるセッション後修理命令を採用することができる。次に、このようにして得られたデータパケットは、Ｉ／Ｏユニット２１０によって、要求クライアントに送信される。

メディアサーバ２００のユニット２１０、２２０、２３０、２４０、２５０及び２７０は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット２１０〜２７０が全て、通信システムの１つのネットワークノードのメディアサーバ２００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、メディアサーバ２００の種々のユニット２１０〜２７０が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。

図１８は、本発明に係る修理サーバ３００を模式的に示すブロック図である。サーバ３００は、外部のユニットとの通信を行うように構成されたＩ／Ｏユニット３１０を有している。このＩ／Ｏユニット３１０は、クライアントからセッション後修理要求を受信し、コンテンツ生成器またはメディアセッションサーバからのメディアコンテナファイルを要求するために、特に提供される。ＦＥＣ冗長データを含むデータパケットの送信も、Ｉ／Ｏユニット３１０が実行する。

修理サーバ３００は、クライアントからの修理要求の受信に応じてコンテナファイルを提供するメディアファイル提供器３２０を備えている。この提供器３２０は、Ｉ／Ｏユニット３１０がファイルを提供するコンテンツ生成器に送信したコンテナ要求を作成することができる。あるいは、修理サーバ３００は、以前受信したコンテナファイルを有しており、これによりファイル提供器３２０はデータ記憶装置３４０からそれを取り出す。

ＦＥＣデータ抽出器３３０は、ファイル提供器３２０が提供するコンテナファイルから、修理要求に含まれる識別子に基づいてＦＥＣ冗長データを抽出するように、サーバ３００の中に構成されている。この識別子は、クライアントが受信に成功しなかったメディアコンテンツの名前または他の識別子とすることができる。メディアセッションサーバの識別子とメディアコンテンツの配信時間との少なくともいずれか等の他の識別子は、修理サーバ３００が、おそらくはメディアサーバに要求することによって、正しいメディアコンテンツを識別することを可能にするために使用することができる。メディアコンテンツの特定部分などより詳細な情報（誤って受信したメディアソースブロックの識別を可能にする）は、これに代えて、または、これとともに使用することができるだろう。

データ抽出器３３０が抽出したＦＥＣデータの量は事前に規定することができる。この事前に規定されたデフォルトのレベルよりも大きなＦＥＣ記号が要求される場合、クライアントはこれに従ってサーバ３００に特に通知しなければならないか、あるいは、クライアントは、さらなるＦＥＣデータの要求を送信する必要がある。あるいは、抽出器３３０は、全てのメディアコンテンツの復号に成功するために必要であろうＦＥＣ記号がどのくらいの量かの見積もりをクライアントから受信する。次に、抽出器３３０は、この見積もりをＦＥＣデータの抽出に使用するだろう。

好適な実装において、コンテナファイルは、コンテナファイル内のＦＥＣリザーバからのＦＥＣデータの、クライアントに送信可能なデータパケットへのコンパイルを規定するセッション後修理命令を有する。このような場合、抽出器は、これらの命令を抽出及びコンパイル処理で使用する。

修理サーバ３００のユニット３１０〜３３０は、ソフトウェア、ハードウェア、またはこれらの組み合わせとして実装または提供してもよい。ユニット３１０〜３４０は全て、通信システム内の単一ネットワークノードの修理サーバ３００内に実装してもよい。あるいは、分散した実装も可能であり、これも本発明の技術的範囲に含まれる。このような場合、修理サーバ３００の種々のユニット３１０〜３４０は種々のネットワークノード内に配置されてもよく、それでもなお、上述のように意図した動作を実行するだろう。

添付の請求の範囲に規定される本発明の範囲から逸脱せずに、本発明に対して種々の変形及び変更が行なわれてもよいことが当業者には理解されるだろう。

（参考文献）
［１］3GPP TS 26.346 V7.0.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs、２００６年６月
［２］ISO/IEC 14496-12:2005: "ISO base media file format"
［３］ISO/IEC 15444-12:2005: "ISO base media file format"
［４］国際公開第ＷＯ２００５／０３９１３１号
［５］RFC 3695; Compact Forward Error Correction (FEC) Schemes、２００４年２月
［６］RFC 2616; Hypertext Transfer Protocol - HTTP/1.1、１９９９年６月
［７］RFC 1864; The Content-MDS Header Field、１９９５年１０月
［８］RFC 3926; FLUTE - File Delivery over Unidirectional Transport、２００４年１０月
［９］RFC 3450; Asynchrononous Layered Coding (ALC) Protocol Instantiation、２００２年１２月
［１０］REC 3451; Layered Coding Transport (LCT) Building Block、２００２年１２月

本発明の一面に従って、メディアコンテナファイルを生成する方法を示すフローチャートである。図１のファイル生成方法のさらなるステップを示すフローチャートである。図１のファイル生成方法のさらなるステップを示すフローチャートである。図１のファイル生成方法のさらなるステップを示すフローチャートである。本発明の他の面に係るメディアセッション管理方法を示すフローチャートである。図５のセッション管理方法のさらなるステップを示すフローチャートである。図５のコンパイルのステップ及び送信のステップの実施形態をより詳細に示すフローチャートである。図５のコンパイルのステップ及び送信のステップの他の実施形態をより詳細に示すフローチャートである。図５のセッション管理方法のさらなるステップを示すフローチャートである。本発明のさらなる面に係るセッション後の修理方法を示すフローチャートである。本発明のさらなる他の面に係るメディアコンテナファイルの概要を模式的に示す図である。本発明に係るメディアコンテナファイルを使用する様々なメディアストリームのコンパイルを示す模式図である。本発明に係るメディアコンテナファイルを使用する様々なメディアストリームのコンパイルを示す他の模式図である。本発明に係るメディアコンテナファイルを管理するサーバを有する通信ネットワークの概略図である。本発明のさらなる他の面に係るコンテンツサーバの模式的ブロック図である。図１５のコンテナファイル生成器の一実施形態をより詳細に示す模式的ブロック図である。本発明のさらなる他の面に係るメディアセッションサーバの模式的ブロック図である。本発明のさらなる他の面に係る修理サーバの模式的ブロック図である。

Claims

メディアコンテナファイルを生成する方法であって、
−少なくとも１つのメディアソースブロックを前記メディアコンテナファイルに編成するステップと、
−前記少なくとも１つのメディアソースブロックに基づいて順方向誤り訂正（ＦＥＣ）冗長データを予め計算するステップと、
−前記ＦＥＣ冗長データを前記メディアコンテナファイルの少なくとも１つのＦＥＣリザーバに編成するステップと、
−前記少なくとも１つのメディアソースブロックと前記少なくとも１つのＦＥＣリザーバとの関係を提供するメタデータを前記メディアコンテナファイルに提供するステップと、
−第１のレベルのＦＥＣリザーバ・オーバヘッドを有するファイルの単一方向配信のためのプロトコル（ＦＬＵＴＥ）データパケットの第１の単一のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのそれぞれからのメディアデータ、及び、関連するＦＥＣリザーバのそれぞれからのＦＥＣ冗長データ、のコンパイルを規定するコンパイル命令の第１セットを第１のヒントトラックとして前記メタデータに基づいて生成するステップと、
−前記第１レベルのＦＥＣリザーバ・オーバヘッドとは異なる第２レベルのＦＥＣリザーバ・オーバヘッドを有するＦＬＵＴＥデータパケットの第２の単一のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのそれぞれからのメディアデータ、及び、前記第１の単一のメディアストリームを形成するために使用される関連するＦＥＣリザーバのＦＥＣ冗長データと同一のＦＥＣ記号を再使用する、関連するＦＥＣリザーバのそれぞれからのＦＥＣ冗長データ、のコンパイルを規定する、コンパイル命令の前記第１セットとは異なるコンパイル命令の第２セットを、前記第１のヒントトラックとは異なる第２のヒントトラックとして、前記メタデータに基づいて生成するステップと、
前記第１のヒントトラックと、前記第２のヒントトラックとを、前記メディアコンテナファイルに編成するステップと、
を有する方法。
−メディアソースファイルを提供するステップと、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するステップと、
を更に有する請求項１記載の方法。
前記分割ステップは、前記ＦＥＣ冗長データを予め計算するのに使用されるＦＥＣアルゴリズムに基づいて前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割することを含む請求項２記載の方法。
前記計算ステップは、
−前記ＦＥＣ冗長データを予め計算するのに使用するＦＥＣアルゴリズムに基づいて前記少なくとも１つのメディアソースブロックを複数のメディア記号に区分するステップと、
−前記少なくとも１つのメディアソースブロックの何れの部分に、前記複数のメディア記号うちの所定のメディア記号が属するかを規定する、前記メディアソースブロック区分の区分情報を生成するステップと、
−前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいて前記ＦＥＣ冗長データを予め計算するステップと、
を有する請求項１から３のいずれか１項に記載の方法。
−前記ＦＥＣアルゴリズムの情報及び前記区分情報を前記メディアコンテナファイルに提供するステップを更に有する請求項４記載の方法。
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するステップを更に有する請求項１から５のいずれか１項に記載の方法。
前記ＦＥＣ冗長データはメディアセッション中に使用されるＦＥＣ冗長データであり、
−前記少なくとも１つのメディアソースブロックに基づいてセッション後の修理手順において有用なセッション後のＦＥＣ冗長データを計算するステップと、
−前記セッション後のＦＥＣ冗長データを前記メディアコンテナファイルの少なくとも１つのＦＥＣリザーバに編成するステップと、
−前記少なくとも１つのメディアソースブロックと関連付けられる識別子に基づいて前記少なくとも１つのＦＥＣリザーバの識別を可能にするメタデータを前記メディアコンテナファイルに提供するステップと、
を更に有する請求項１から６のいずれか１項に記載の方法。
−少なくとも１つのメディアソースブロックをメディアコンテナファイルに編成するように構成されるメディアブロックマネージャと、
−前記少なくとも１つのメディアソースブロックに基づいて順方向誤り訂正（ＦＥＣ）冗長データを予め計算するように構成されるＦＥＣコーデックと、
−前記ＦＥＣ冗長データを前記メディアコンテナファイルの少なくとも１つのＦＥＣリザーバに編成するために前記ＦＥＣコーデックに接続されて構成されるＦＥＣデータマネージャと、
−前記少なくとも１つのメディアソースブロックと前記少なくとも１つのＦＥＣリザーバとの関係を提供するメタデータを前記メディアコンテナファイルに提供するように構成されるメタデータマネージャと、
−ｉ）第１レベルのＦＥＣリザーバ・オーバヘッドを有するファイルの単一方向配信のためのプロトコル（ＦＬＵＴＥ）データパケットの第１の単一のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのそれぞれからのメディアデータ、及び、関連するＦＥＣリザーバのそれぞれからのＦＥＣ冗長データ、のコンパイルを規定するコンパイル命令の第１セットを第１のヒントトラックとして前記メタデータマネージャによって提供される前記メタデータに基づいて生成し、ii）前記第１レベルのＦＥＣリザーバ・オーバヘッドとは異なる第２レベルのＦＥＣリザーバ・オーバヘッドを有するＦＬＵＴＥデータパケットの第２の単一のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのそれぞれからのメディアデータ、及び、前記第１の単一のメディアストリームを形成するために使用される関連するＦＥＣリザーバのＦＥＣ冗長データと同一のＦＥＣ記号を再使用する、関連するＦＥＣリザーバのそれぞれからのＦＥＣ冗長データ、のコンパイルを規定する、コンパイル命令の前記第１セットとは異なるコンパイル命令の第２セットを、前記第１のヒントトラックとは異なる第２のヒントトラックとして、前記メタデータマネージャによって提供される前記メタデータに基づいて生成し、iii）前記第１のヒントトラックと、前記第２のヒントトラックとを、前記メディアコンテナファイルに編成する、ように構成される命令マネージャと、
を備えるメディアコンテンツサーバ。
−メディアソースファイルを提供するように構成されるメディアソースと、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するために前記メディアソースに接続されて構成されるファイル分割器と、
を更に備える請求項８記載のメディアコンテンツサーバ。
前記ファイル分割器は、前記ＦＥＣ冗長データを予め計算するために前記ＦＥＣコーデックにより使用されるＦＥＣアルゴリズムに少なくとも部分的に基づいて前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに区分するように構成される請求項９記載のメディアコンテンツサーバ。
−前記ＦＥＣコーデックにより使用されるＦＥＣアルゴリズムに基づいて前記少なくとも１つのメディアソースブロックを複数のメディア記号に区分し、前記少なくとも１つのメディアソースブロックの何れの部分に、前記複数のメディア記号うちの所定のメディア記号が属するかを規定する、前記メディアソースブロック区分の区分情報を生成するためのブロック区分器を更に具備し、前記ＦＥＣコーデックは、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいてＦＥＣ冗長データを予め計算するように構成される請求項８から１０のいずれか１項に記載のメディアコンテンツサーバ。
−前記ＦＥＣコーデックにより使用される前記ＦＥＣアルゴリズムの情報及び前記区分情報を前記メディアコンテナファイルに提供するように構成される情報マネージャを更に備える請求項１１記載のメディアコンテンツサーバ。
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するように構成される情報マネージャを更に備える請求項８から１２のいずれか１項に記載のメディアコンテンツサーバ。
ＦＥＣコーデックにより生成される前記ＦＥＣ冗長データはメディアセッション中に使用するためのＦＥＣ冗長データであり、前記ＦＥＣコーデックは前記少なくとも１つのメディアソースブロックに基づいてセッション後の修理手順において有用なセッション後のＦＥＣ冗長データを計算するように構成され、前記ＦＥＣデータマネージャは前記ＦＥＣコーデックにより計算される前記セッション後のＦＥＣ冗長データを前記メディアコンテナファイルの少なくとも１つのＦＥＣリザーバに編成するように構成され、前記メタデータマネージャは前記少なくとも１つのメディアソースブロックと関連付けられる識別子に基づいて前記少なくとも１つのＦＥＣリザーバの識別を可能にするメタデータを前記メディアコンテナファイルに提供する
ように構成される請求項８から１３のいずれか１項に記載のメディアコンテンツサーバ。