メディアコンテナファイルの管理
【課題】メディアソースブロックに編成されたメディアデータを含むメディアコンテナファイルを提供する。
【解決手段】メディアソースブロックは、ＦＥＣ冗長データを生成するために順方向誤り訂正（ＦＥＣ）アルゴリズムにより処理されるソース記号に区分される。ソースブロックに加え、このソースブロック区分の情報がコンテナファイルに含まれる。コンテナファイルは、メディアソースブロックと区分情報との関係を提供するメタデータを更に含む。コンテナファイルは、ＦＥＣデータを計算する前の広範囲にわたるデータ処理の必要なく要求クライアントに送信されるメディアデータパケットをコンパイルするために、メディアセッションにおいてメディアサーバにより採用される。
【解決手段】メディアソースブロックは、ＦＥＣ冗長データを生成するために順方向誤り訂正（ＦＥＣ）アルゴリズムにより処理されるソース記号に区分される。ソースブロックに加え、このソースブロック区分の情報がコンテナファイルに含まれる。コンテナファイルは、メディアソースブロックと区分情報との関係を提供するメタデータを更に含む。コンテナファイルは、ＦＥＣデータを計算する前の広範囲にわたるデータ処理の必要なく要求クライアントに送信されるメディアデータパケットをコンパイルするために、メディアセッションにおいてメディアサーバにより採用される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、メディア及びマルチメディアの管理に関し、特に、そのようなメディア及びマルチメディアコンテンツを含むメディアコンテナファイルの作成及び使用に関する。
【背景技術】
【０００２】
メディア及びマルチメディアを種々のネットワークを介してクライアントへ提供することが過去数年で急増している。今日、例えば映像及び音声ストリーム又は映像及び音声ファイルの形式のメディアにアクセスするために及びそれらメディアをメディアサーバからダウンロードするために、多くのユーザがインターネットを採用している。このメディアの提供は、無線を使用するモバイル通信ネットワークにおいて開始された。現在、マルチメディア又はＴＶコンテンツに対してモバイルネットワークを使用することに非常に大きな関心がある。これは、多くの場合、従来技術においてモバイルＴＶと呼ばれる。今日、モバイルネットワークにおけるこのメディアの提供は、主にユニキャスト転送を介して利用可能である。しかし、現在、モバイルＴＶのブロードキャスト／マルチキャスト配信方法は開発中である。そのような標準化の取り組みの例は、３ＧＰＰのマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）及びヨーロッパ電気通信標準化協会（ＥＴＳＩ）のデジタルビデオブロードキャスト−ハンドヘルド（ＤＶＢ−Ｈ）である。
【０００３】
種々の有線及び無線通信ネットワークにおけるメディア提供に対する増加する要求に応じて、要求クライアントにメディアコンテンツを提供するために無線ネットワークにおいて利用可能なストリーミングサーバ及びダウンロードサーバの開発において進行中の作業がある。透過的で柔軟性のあるストリーミング／ダウンロードサーバに向かう一般的な傾向があり、それは、基本的にはサーバが種々のメディア管理機能を実行する複数の「標準」モジュール又はプログラムから構成されるべきであることを示す。それら機能に対する入力メディアコンテンツは、モジュール／プログラムがコンテンツを処理する方法に関する命令と共に提供される。これにより、サーバにおいて固定の定義済みメディア処理を使用することと比較してより柔軟性のあるメディア提供が提供される。
【０００４】
従って、透過的で柔軟性のあるストリーミング／ダウンロードサーバを有するという傾向に合わせて使用されるメディアコンテナ形式が必要とされている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、従来の構成のそれら欠点及び他の欠点を克服する。
【０００６】
本発明の一般的な目的は、マルチメディアセッションにおいて使用されるメディアコンテナファイルを提供することである。
【課題を解決するための手段】
【０００７】
本目的及び他の目的は、添付の請求の範囲により規定される本発明により達成される。
【０００８】
簡単に説明すると、本発明は、メディアコンテナファイルの生成及びその使用を含み、そのようなコンテナファイルを生成及び使用する装置を含む。
【０００９】
メディアコンテナファイルを生成することは、要求クライアントに送信され、クライアントでレンダリングされるメディアデータ又はマルチメディアデータを含む少なくとも１つのメディアソースファイルを提供することを含む。このコンテナファイルは、コンテナファイルのサイズに依存して、１つ以上のメディアソースブロックから構成されると考えられる。少なくとも１つのそのようなメディアソースブロックは、ソースブロックに基づいてＦＥＣ冗長データ又は記号を計算する目的で、ＦＥＣコーデックが処理するのを可能にするサイズを有するソース記号又は部分にソースブロックを区分することにより本発明に従って処理される。メディアソースブロックに対して使用する選択されたブロック区分の情報は、生成され、ソースブロックの実際のメディアコンテンツと共にコンテナファイルに格納される。メタデータは、メディアソースブロックとその区分情報との関係を提供するために提供され、コンテナファイルに含まれる。
【００１０】
結果として得られるコンテナファイルは、コンテナファイル中の区分情報を使用してＦＥＣデータを計算し、ファイルのメディアデータ及び計算したＦＥＣデータを含むデータパケットをコンパイルするために、メディアセッション中にメディアサーバにより採用される。種々のＦＥＣアルゴリズムに基づいてメディアソースブロックを区分し、本発明のコンテナファイルに含まれるＦＥＣ情報を生成することに関するメディアソースブロックの前処理により、メディアサーバは、単純で計算コストの安価な方法でＦＥＣデータを計算でき、広範囲にわたるデータ処理及び計算量の多いブロック区分なしで要求クライアントに送信されるデータパケットにメディアデータ及びＦＥＣデータを挿入できる。
【００１１】
好適な一実施形態において、コンテナファイルは、ＦＥＣデータを計算する場合、並びにコンテナファイルのメディアデータ及びＦＥＣデータを含むデータパケットをコンパイルする場合にメディアサーバが使用し、従う命令を更に含む。そのような場合、コンテナファイルは、メディアデータが確実にクライアントに正常に転送されるのに必要とされる全てのメディアコンテンツ及び命令を含む。
【図面の簡単な説明】
【００１２】
【図１】本発明の１つの面に従ってメディアコンテナファイルを生成する方法を示すフローチャートである。
【図２】図１のメディアブロック提供ステップを更に詳細に示すフローチャートである。
【図３】図１のファイル生成方法の追加のステップを示すフローチャートである。
【図４】本発明の別の面に係るメディアコンテナファイルを示す概略図である。
【図５】本発明の更なる面に係るメディアセッション管理方法を示すフローチャートである。
【図６】図５のセッション管理方法の追加のステップを示すフローチャートである。
【図７】図５のセッション管理方法の追加のステップを示すフローチャートである。
【図８】本発明に従ってメディアコンテナファイルを採用する種々のメディアストリームのコンパイルを示す概略図である。
【図９】本発明に従ってメディアコンテナファイルを管理するメディアサーバを含む通信ネットワークを示す概略図である。
【図１０】本発明の更に別の面に係るコンテンツサーバを示す概略ブロック図である。
【図１１】図１０のメディアブロック提供器の一実施形態を更に詳細に示す概略ブロック図である。
【図１２】図１０のコンテナファイル作成器の一実施形態を更に詳細に示す概略ブロック図である。
【図１３】本発明の更に別の面に係るメディアセッションサーバを示す概略ブロック図である。
【発明を実施するための形態】
【００１３】
添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。
【００１４】
図中、同一の図中符号は対応する要素又は類似する要素に対して使用される。
【００１５】
本発明は、一般に、メディア及びマルチメディアデータの管理に関し、特に、無線を使用する通信ネットワークにおけるストリーミングサーバ又はダウンロードサーバ等のメディアサーバと関連してコンテナファイルを作成及び利用することに関する。本発明のそれらメディアコンテナファイルは、要求クライアントに送信するメディアコンテンツとメディアサーバにおいてメディア処理及び送信を実行するのに使用される命令とを含む。本発明によると、メディアコンテンツは前処理されており、メディアセッション中にメディアサーバによる効率的な管理を可能にする形式で存在する。本発明の特定の面において、元のメディアコンテンツは、メディアセッションに対する信頼性保護の提供をメディアサーバにおいて簡単化するために前処理されている。従って、コンテンツは、要求クライアントへの正常な配信の確率を増加するためにメディアセッションにおいて使用されるメディアコンテンツからの信頼性保護データの計算を可能にする形式である。
【００１６】
本発明の好適な一実施形態によると、メディアコンテンツの前処理は、メディアサーバにおいて、送信されたメディアストリームに含まれる順方向誤り訂正（ＦＥＣ）冗長データを計算するために実行及び適応される。
【００１７】
この分野で周知のように、ＦＥＣは送信されたペイロードデータに冗長データを追加することを含み、それにより受信機は追加のデータを送信機に要求する必要なく誤りを検出及び訂正できる。ＦＥＣの利点は、平均して必要とされる帯域幅が大きくなるが、データの再送信が回避されることが多いことである。従って、ＦＥＣがメディアコンテンツのマルチキャスト／ブロードキャストによる配信に関連して使用されるのが有利であり、この場合、再送信が行なわれにくくなる。
【００１８】
ＦＥＣは、従来技術においては通常ＦＥＣコーデックである選択されたアルゴリズム又は方式を使用して送信される情報に冗長性を追加することにより達成される。そのような各冗長ビットは、常に多くの元の情報又はペイロードビットの複素関数である。出力に未変更の入力を含むＦＥＣコーデックは、システムコーデックと呼ばれる。換言すると、（Ｎ，Ｋ）システムＦＥＣコーデックは、Ｋ個のソース記号又はペイロード記号を保存し、（Ｎ−Ｋ）個のＦＥＣ記号を付加する。同様に、（Ｎ，Ｋ）非システムＦＥＣコーデックは、必ずしも全てを保存されているわけではないＫ個のソース記号からＮ個の（ＦＥＣ又はソース）記号を作成する。
【００１９】
ＦＥＣコーデックには、ブロックコード及び冗長コードの２つの主な分類がある。ＦＥＣブロックコーデックは、所定サイズのビット又は記号の固定サイズブロック（パケット）に対して動作し、重畳コーデックは、任意の長さのビットストリーム又は記号ストリームに対して動作する。Digital FountainのRaptor符号は、単一のソースブロックから任意の数のＦＥＣ冗長記号を作成できるＦＥＣブロックコーデックである。これは、種々の保護オーバヘッドの構成がソースブロックの構成の変更を必要としないことを意味するため、このＦＥＣコーデックの有利な特性である。しかし、リードソロモンは、保護オーバヘッドの種々の大きさに対してソースブロックの区分の変更を必要とする別のＦＥＣブロックコーデックである。ＦＥＣブロックコーデックの他の例には、ゴレイ、ＢＣＨ（Bose, Ray-Chaudhuri, Hocquenghem）及びハミングがある。本発明に関連して使用する好適なＦＥＣコーデックは、Digital Raptorコーデックである。
【００２０】
本発明によると、メディアデータ又はメディアコンテンツ、あるいはマルチメディアデータ又はマルチメディアコンテンツは、データのレンダリングのためにコンテンツ提供器又はサーバがクライアントに提供できる任意のデータを示す。一般的な好適な例は、映像データ及び音声データを含む。データは、事前に符号化された固定レートの音声又は映像コンテンツバージョンの形式でもよく、スケーラブルな音声又は映像コンテンツの形式でもよい。他のメディアの例としては、静止画（ＪＰＥＧ）、ビットマップ画像（ＧＩＦ及びＰＮＧ）、ベクターグラフィックス（ＳＶＧ）、並びに合成音声（ＳＰ−ＭＩＤＩ）及びテキスト（ＸＨＴＭＬ及びＳＭＩＬ）がある。
【００２１】
図１は、本発明に従ってメディアコンテナファイルを生成する方法を示すフローチャートである。このメディアコンテナファイルは、メディアコンテンツを提供し、メディアデータを送信可能なデータパケットに形成するために、メディアセッション中にメディアサーバにより使用される完全な入力パッケージと考えられる。従ってコンテナファイルは、メディアコンテンツ自体に加え、処理を実行し、メディアセッション中にメディアコンテンツの送信を可能にするためにメディアサーバにより必要とされる情報及び命令を含むのが好ましい。
【００２２】
方法は、少なくとも１つのメディアソースブロックが提供されるステップＳ１において開始する。少なくとも１つのメディアソースブロックは、クライアントに送出されることが意図されるメディアデータ又は記号を含み、それらはメディアコンテンツをユーザに提示するためにレンダリングされる。メディアブロックは固定の同一サイズであってもよく、あるいは２つ以上の多い場合は、少なくともその一部分が異なるビット／記号サイズであってもよい。ステップＳ１において３つ以上のメディアソースブロックが提供される場合、それらブロックは、映像ストリーム等の同一のメディアコンテンツファイル又はストリーム、並びに／あるいは異なるメディアファイル又はストリームの個別のメディアブロックと考えられてもよい。例えば、映像ストリームのいくつかのメディアソースブロック及び対応する関連する音声ストリームのいくつかのメディアブロックと考えられてもよい。
【００２３】
このステップＳ１において、関連するメディアコンテンツが提供される。例えば、メディアコンテンツが音楽映像を含む場合、少なくとも１つの提供されたメディアブロックは映像データを含むのが好ましく、少なくとも１つのメディアブロックは対応する音声データを含む。しかし、１つの同一のメディアコンテンツが複数の潜在的なメディアバージョンで提供されてもよいことが本発明により理解される。例えば、音楽映像の映像部分は複数の事前符号化された映像バージョンで提供され、そのような各映像バージョンは、所定の帯域幅又はビットレートレベル又は間隔に関連して使用できるように適応される。従ってステップＳ１において、所定のメディアコンテンツの複数のバージョンが提供されてもよい。そのような場合、そのような各メディアバージョンは、１つ以上のメディアソースブロックから構成されると考えられる。複数のメディアバージョンが提供され、コンテナファイルに編成されてもよいが、通常は、メディアセッション中の所定の時間においてそのようなバージョンは１つのみ使用され、例えば利用可能な帯域幅のレベルの変化に基づいてセッション中にメディアバージョンの切り替えが行なわれてもよい。
【００２４】
次のステップＳ２において、提供されたメディアソースブロックはソース記号、すなわちいわゆるチャンクに区分される。一般に、それら記号は数百バイトで構成される。このブロックの区分は、現在のメディアソースブロックに対するＦＥＣ記号を計算するためにメディアサーバにより使用されるＦＥＣコーデック／アルゴリズムの情報に少なくとも部分的に基づいて実行される。上述したように、リードソロモンを使用するＦＥＣコードは、所望の保護オーバヘッドの大きさ、すなわちＦＥＣ冗長記号の数に基づいてソースブロック区分の変更を必要とする。従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアソース区分及びメディア記号サイズに影響を与える可能性がある。更に、メディアコンテンツを送信するためにメディアサーバにより使用されるユーザデータグラムプロトコル（ＵＤＰ）パケット等のデータパケットのサイズ等の他のパラメータは、このステップＳ２のソースブロック区分において使用される。そのような場合、少なくとも１つの完全なソース記号がＵＤＰパケットに収まるように、ソース記号のサイズは制限される。
【００２５】
この区分ステップＳ２は、メディアソースブロックがコンテナファイルの別個の場所に格納される別個のソース記号に物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割され、その結果、実質的にソース記号に区分される。
【００２６】
次のステップＳ３において、区分の情報が生成される。基本的にこの情報は、データシーケンスのどの部分がメディアソースブロックのどのソース記号に属するかを特定する。区分情報は、メディアソースブロックＺのビットＸ〜ビットＹがソース記号を構成することを特定するテーブルに編成されてもよい。あるいは、情報は、各ソース記号のバイトサイズを含むことができる。メディアファイルのメディアソースブロックの開始場所が分かると、種々のソース記号に属するデータ部分を判定できる。
【００２７】
所定のメディアソースブロックは、少なくとも２つの異なる区分動作に従って区分されることが本発明により理解される。例えば、第１のそのようなブロック区分は第１のＦＥＣアルゴリズムに適応され、第２の区分は第２のＦＥＣアルゴリズムに対して適応されて採用される。更にブロック区分は、メディアサーバにおける実際の所望のＦＥＣオーバヘッドに依存する可能性がある。そのような場合、種々のＦＥＣオーバヘッドに対して設計される種々のブロック区分は、ファイル作成時に判定される。区分情報は、所定のメディアソースブロックに適用可能なそれら別の区分の情報を含む。
【００２８】
ステップＳ４において、区分されたメディアブロック及び生成された区分情報は、メディアコンテナファイルに編成される。メディアコンテンツ及び情報は、コンテナファイルの部分として挿入される。更に、コンテナファイルに編成された少なくとも１つのメディアブロックは、メディアセッション中にクライアントに送信される全てのメディアコンテンツデータを一括して含むのが好ましい。換言すると、コンテナファイルはマルチメディア表現全体に対するメディアデータを含む。
【００２９】
次のステップＳ５は、コンテナファイルに含まれるメタデータを提供する。このメタデータは、ステップＳ４でコンテナファイルに追加されたメディアソースブロックとステップＳ４でファイルに格納された区分との関係を提供する。この関係は、ファイル内のメディアソースブロックの記憶場所から区分情報の記憶場所へのポインタ又は区分情報の記憶場所からメディアソースブロックの記憶場所へのポインタの形式である。従って、特定のメディアソースブロック又はコンテナファイル内のそのブロックの場所が与えられると、このメタデータは関連する区分情報又はファイル内のその情報の記憶場所の識別を可能にする。メディアソースブロックの識別子及び／又は関連する情報がコンテナファイルの事前定義済みの「標準」又は「デフォルト」の場所に格納される場合、ポインタを採用する代わりに、メタデータはそれらメディアソースブロックの識別子及び／又は関連する情報を含むことができる。メタデータは、ファイルのメディアソースブロック及び区分の一方を識別するために使用され、その識別した場所に基づいて、メディアソースブロック及び情報のうちのもう一方が識別される。
【００３０】
本発明の一般的な実現例において、複数のメディアソースブロックがステップＳ１において提供される。この場合、ステップＳ２〜ステップＳ５がそのような各メディアソースブロック又は少なくともメディアソースブロックの複数のグループに対して繰り返されるのが好ましい。これを線Ｌ１により概略的に示す。ステップＳ１においてＮ個のメディアソースブロックがコンテナファイルに編成される場合、ステップＳ２〜ステップＳ５はＮ回繰り返されるのが好ましく、これは、ソースブロックに加え、区分情報及びメタデータの、Ｎ個のバージョンをコンテナファイルに編成することを示す。
【００３１】
その後、方法は終了する。
【００３２】
上述したように、本発明の目的は、実際のメディアデータに加え、ＦＥＣデータを計算する時に使用されるＦＥＣに依存する区分情報を更に含むメディアコンテナファイルを提供することである。これは、ファイルからソースブロックへの分割及びブロック区分が「オフライン」で行なわれ、メディアサーバにおける実際のメディア送信処理とは無関係であることを意味する。この前処理は、サーバのタスクを簡単化し、性能要求及びサーバの複雑さを軽減する。更に、コンテナファイルは、メディアデータ及び計算されたＦＥＣデータを識別し、要求クライアントに送信されるメディアストリームに構成するためにメディアサーバにより必要とされる情報及び命令を更に含むのが好ましい。従って、コンテナファイルは、データのコンパイル及び送信のために透過的で柔軟性のあるサーバにより使用されるデータ、情報及び命令の完全なパッケージとして考えられる。
【００３３】
図１と関連して上述したコンテナファイルの生成は、内部又は外部メディアコンテンツソースへのアクセス権を有するコンテンツ作成器又はサーバにおいて実行されるのが好ましい。生成されたコンテナファイルは、例えばローカルシステム内の転送、あるいはローカル又はグローバルネットワークを介する送信のために、コンピュータメモリ等の記憶媒体、あるいは電子信号又は無線信号等の物理信号で表されてもよい。一般的な一実施形態において、コンテナファイルは、種々のクライアントとのメディアセッションにおいて使用するためにメディアサーバに無線信号として提供される。
【００３４】
以下において、メディアコンテナファイルという用語は、本開示において、記憶媒体に格納するためのデータファイル及び転送又は配信するための信号を含むという意味を含んで使用される。
【００３５】
図２は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、少なくとも１つのメディアソースファイルが提供されるステップＳ１０において開始する。図示される本実施形態において、メディアコンテンツは、メディアデータを含むソースファイル又はストリームの形式でコンテナファイル作成器において入手可能である。このステップＳ１０において、１つ以上のメディアソースファイルはコンテナファイルに含むために提供される。例えば、第１のメディアファイルは映像データを含むことができ、第２の関連するファイルは音声データを含む。メディアサーバにおいてＦＥＣ冗長データの効率的な計算及びその後のそのようなＦＥＣデータの使用を可能にするために、次のステップＳ１１において、ステップＳ１０で提供されるメディアソースファイルは複数のメディアブロックに分割される。このメディアソースブロックは、メディアソースファイルのセグメントとして考えられ、ＦＥＣコードはそのセグメントに対して適用されるか又は動作する。ソース記号又はデータビットでのメディアブロックのサイズは、分割に関連して事前定義されるか又は選択される。前者の場合、サイズはＦＥＣ冗長データの計算に採用される所期のＦＥＣ方式又はコードにより規定される。従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアファイル分割及びメディアブロックサイズに影響を与える可能性がある。
【００３６】
入力メディアソースファイルがＦＥＣコーデックにより効果的に処理される最大サイズより小さなサイズのビットサイズ又は記号サイズを有する場合、ソースファイルのメディアソースブロックへの分割は当然必要とされず、ステップＳ１１は省略される。入力メディアソースファイルは、本発明に係るメディアソースブロックとして考えられる。
【００３７】
尚、好適なブロックサイズがあるが、メディアソースファイルから生成される全てのメディアソースブロックがその好適なサイズである必要はない。例えば、メディアファイルの残りの部分が好適なブロックサイズに達する程の十分なメディアデータを含まないために、最後のメディアソースブロックは、他の同一サイズのブロックと比較して小さなサイズであってもよい。
【００３８】
この分割ステップＳ１１は、メディアソースファイルがコンテナファイルの別個の場所に格納される別個のメディアソースブロックに物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割される。例えば、ソース記号[0, N-1]が第１のソースブロックに属し、記号[N, 2N-1]が第２のソースブロックに属するように、２Ｎ個のソース記号を含むメディアソースファイルが分割される。
【００３９】
次のステップＳ１２において、特定のメディアソースファイル分割の情報が提供される。この情報は、メディアデータパケットストリームを提供し且つ／又はＦＥＣデータを計算する場合、メディアサーバに対する関連性の情報である。
【００４０】
方法は図１のステップＳ２に継続し、メディアソースブロックがメディアソースブロックに区分される。
【００４１】
図３は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、図１のステップ５から継続する。次のステップＳ２０において、ブロック区分が計算される際に基づく方式のＦＥＣアルゴリズムの情報が提供される。この情報は、特定のアルゴリズムの名前又は他の記述情報の形式である。別の方法において、利用可能な各ＦＥＣアルゴリズムは事前定義済み識別子を有する。従って、このＦＥＣ識別子のみがステップＳ２０において提供されてもよい。一般的な実現例において、単一のＦＥＣコーデックの情報が、メディアソースファイルの全てのメディアソースブロックを区分するのに採用された。しかし、所定のメディアソースファイルの種々のメディアソースブロック又は種々のソースファイルのメディアソースブロックに対して区分を行なう際に種々のＦＥＣコーデック情報を使用することが実際に可能である。従って、ＦＥＣ情報は、単一のＦＥＣコーデックによるＦＥＣ記号の計算を可能にするため、あるいは種々のＦＥＣコーデックが使用されたソースブロック又はソースブロックのグループを識別するためにコンテナファイルの全てのブロックが区分されたことを特定できる。この状況において、種々の潜在的な対象ＦＥＣコーデック及び／又はＦＥＣオーバヘッドに基づいて所定のソースブロックを実際に区分できる。そのような場合、ステップＳ２０において、それら種々のＦＥＣコーデックの情報が提供されるのが好ましい。
【００４２】
次のステップＳ２１において、プロパティテーブルが提供されるのが好ましい。このプロパティテーブルは、２つ以上のメディアソースファイル／ストリームがコンテナファイルに含まれる場合に特に有用であるが、単一のメディアソースファイルを含む時にも有利に使用される。通常、ファイルプロパティテーブルは、好ましくはメディアの多目的インターネットメール拡張仕様（ＭＩＭＥ）タイプであるメディアソースファイルのメディアタイプの情報を含む。従って、このＭＩＭＥ情報は、メディアが同期マルチメディア統合言語（ＳＭＩＬ）を含む音声メディア、映像メディア又は他のメディアタイプであることを特定できる。このＭＩＭＥタイプは、コンテナファイルに実際に含まれるデータタイプの情報をメディアサーバに提供する。プロパティテーブルは、gzipを含むメディアデータに対して採用される任意の符号化方式の情報を更に含むことができる。また、サイズ情報がプロパティテーブルに含まれる。このサイズ情報は、バイト数又は記号数に関する各メディアソースファイルの合計サイズ、ソースファイルのメディアソースブロックの各サイズ（基本的に、図２のステップＳ１２で提供される分割情報に対応する）、データを送信する際に使用されるデータパケットに対する最大ペイロードサイズ又は対象ペイロードサイズ、メディアソース記号のサイズ（バイト）（基本的に、図１のステップＳ３で生成される区分情報に対応する）及び／又はＦＥＣ記号等を指定できる。ファイル名又はファイル識別子は、コンテナファイルに含まれる各メディアソースファイルに対するプロパティテーブルに含まれるのが好ましい。
【００４３】
コンテナファイルの各メディアソースファイルの実際の記憶場所の情報は、プロパティテーブルにおいて見つけられるのが好ましい。この場所情報は、ソースファイルの第１のメディアソースブロックの開始位置を特定でき、残りのメディアブロックはコンテナファイルのその位置以降に見つけられる。図１のステップＳ５で生成され、コンテナファイルの区分情報とメディアソースブロックとの関係を提供するメタデータは、プロパティテーブルに更に含まれる。同様に、採用されるブロック区分の情報及び冗長データ計算用のＦＥＣコーデックは、テーブルに含まれるのが好ましい。
【００４４】
従って、コンテナファイルのプロパティテーブルは、メディアソースに対する単一の情報ソースとして使用され、メディアセッション中のメディアパケットのコンパイルにおいて有用な関連するメディアソースファイル／ブロック及び他の情報の位置を特定する。
【００４５】
ＦＥＣ計算命令は、次のステップＳ２２において生成される。それら命令は、ソースブロックの区分データ及びメタデータに基づいてメディアソースブロックに対するＦＥＣデータを計算するためにメディアサーバにより使用される。従って、それら命令は、メディアセッション中にメディアコンテンツと共に使用されるＦＥＣ記号を生成して信頼性保護を提供するために、種々のソースブロックのメディアソース記号が好ましくはＦＥＣ情報に基づいて規定されるＦＥＣコーデックに入力される方法の命令を提供するヒント又はメタデータとして考えられる。命令は、少なくとも１つのメディアソースブロックに対するＦＥＣ記号のリザーバを計算するために区分情報及びメタデータ（区分情報の識別を可能にする）と共に使用されるのが好ましい。
【００４６】
好適な一実現例において、ＦＥＣ計算命令は、少なくとも１つのメディアソースブロックに対するＦＥＣ冗長記号のセットの計算を規定する。このＦＥＣ記号のセットは、メディアソースブロックのソース記号に基づいて計算された１つのＦＥＣ記号、好ましくは複数のＦＥＣ記号を含むことができる。
【００４７】
ＦＥＣ計算命令は、所定のメディアソースブロックに対する複数の別の命令を含むことができる。例えば、第１のＦＥＣコーデックがＦＥＣアルゴリズム情報に基づいて判定されるようにＦＥＣデータ計算に使用される場合、第１の別のＦＥＣ命令が採用される。同様に、第２の別のＦＥＣ命令は、第２のＦＥＣコーデックによるＦＥＣデータの計算を規定する。あるいは又はそれに加えて、別のＦＥＣ命令は種々のＦＥＣオーバヘッドに適応され、それにより許容される最大（又は最小）のＦＥＣオーバヘッドに依存して異なる数のＦＥＣ記号の計算を基本的に特定できる。
【００４８】
次のステップＳ２３は、メディアサーバにより使用されるコンパイル命令を生成する。それら命令は、データパケットのメディアストリームを形成するために、ＦＥＣ計算命令に基づいて計算されたＦＥＣ冗長データ及びメディアソースブロックのメディアデータのコンパイルを規定するのに使用される。従って、それら命令は、信頼性保護を有する送信可能なメディアパケットストリームを構成するためにコンテナファイルに含まれ、それから計算されるデータを使用する方法に関する命令を提供するヒント又はメタデータとして考えられる。それら命令は、メディアセッション中に要求クライアントに送信するのに適切なパケットにメディアデータ及びＦＥＣデータをコンパイルするために使用される。従って、命令はメディアソースデータ及びＦＥＣデータのサーバ側の送信順を記述する。しかし、通常、命令はタイムスケジュール情報、対象／ソースアドレス又はポートの情報、あるいは他のセッション特有の情報を含まない。これは、コンテナファイル及びその中のコンパイル命令は特定のセッションに透過的であり、種々の受信クライアントとの複数の種々のセッションに対する１つのメディアサーバだけでなく、種々のメディアサーバによっても実際に使用される。
【００４９】
コンパイル命令はメディアソースブロックのサブセットに適用でき、それは、そのような複数の命令がセッション中にメディアサーバにより読み出されて使用される必要があることを示す。あるいは、コンパイル命令は、単一のメディアソースファイル又は実際にはコンテナファイルの全てのメディアソースファイルに必要とされる全ての情報を含む。
【００５０】
ステップＳ２３において、コンパイル命令の２つ以上のセットが実際に生成されてもよい。そのような場合、種々の別の命令が提供されるため、メディアサーバは特定のメディアセッションに採用する特定の命令セットを判定する選択肢を有する。例えば、データ送信のために単一の送信チャネルを採用する場合、第１のコンパイル命令はメディアソースブロック及びＦＥＣデータの送信順を記述するのに使用される。第２の命令は、同一のメディアソースブロック及びＦＥＣデータに適用されるが、複数のチャネルが利用可能な場合にはコンパイル／送信順情報を提供し、これは、データが順次送信されるのではなく並列的に送信されることを示す。従って、いくつかのコンパイル命令は、種々の転送チャネル状態用の別の送信セッションを提供するために使用される。
【００５１】
同様に、別のコンパイル命令は、種々の信頼性保護オーバヘッドのために含まれる。例えば、第１のコンパイル命令は第１の最大保護オーバヘッドレベルに対するメディアソースブロック及びＦＥＣデータのコンパイル／送信順を記述するのに使用され、第２の命令は第２の異なるＦＥＣオーバヘッドレベルの同一のメディアソースブロックに対して使用される。この第２のＦＥＣオーバヘッドレベルが第１のレベルより高い（低い）場合、従来技術においても示されるようなより多くのＦＥＣ記号又はパリティ記号が所定の量のメディアソース記号に追加される。
【００５２】
次のステップＳ２４は、先のステップＳ２０〜ステップＳ２３及び好ましくは図２のステップＳ１２において提供及び生成される情報、テーブル及び命令をコンテナファイルに編成する。コンテナファイルは、要求クライアントへの送信のためにデータを識別、計算及び構成するために、メディアサーバにより必要とされる「生」メディアデータ、情報、命令及びメタデータの完全なセットを含む。その後、方法は終了する。
【００５３】
図４は、本発明に係るメディアコンテナファイル１を示す概略図である。上述したように、コンテナファイル１は、複数のメディアソースファイル１０、１２、１４のメタデータを含み、そのようなＭ個のファイルを図示する。ここで、Ｍ≧１である。各ファイル１０、１２、１４のメディアデータは、複数のメディアソースブロック２０、２２、２４に分割されると考えられる。図中では、そのようなＱ1個のブロック２０、２２、２４は、第１のメディアソースファイル１０に対して示されている。ここでＱ1≧１である。そのような各メディアソースブロック２０、２２、２４は、ソース記号に分割されると考えられる。
【００５４】
コンテナファイル１は、メディアデータを含むメディアソースブロック２０、２２、２４に加え、信頼性保護を提供するためにメディアデータと関連して使用されるＦＥＣ冗長データの計算を簡単化する目的でメディアソースブロック２０、２２、２４に適用されたソース記号区分の事前に生成された情報を含む区分情報セット３０、３２、３４を含む。好適な一実現例において、各メディアソースブロックは、専用の区分情報セット３０、３２、３４を含む。そのような場合、図中の情報セット３０、３２、３４の数Ｎは、
である。
【００５５】
区分情報３０、３２、３４が適用可能なメディアソースブロック２０、２２、２４と区分情報３０、３２、３４との関係を提供する本発明の関係メタデータ４０は、コンテナファイル１に更に提供される。図４は、ファイル１におけるメタデータ４０の複数の異なる可能な場所を示す。第１の実施形態において、メタデータは関連するメディアソースブロック２０、２２、２４と関連して格納される。従って、ファイル中のメディアソースブロック２０、２２、２４の識別により、ソースブロック２０、２２、２４の各メタデータ４０の識別も可能になる。あるいは又はそれに加えて、メタデータ４０は各区分情報３０、３２、３４と共に格納される。各情報セット３０、３２、３４は、特定の区分情報３０、３２、３４が適用される関連するメディアソースブロック２０、２２、２４の識別を可能にする結び付けられた関係メタデータ４０を有する。コンテナファイル１が好適なファイルプロパティテーブル６０を含む場合、関係メタデータ４０はそのテーブルに提供される。そのような場合、メディアサーバは、ファイルプロパティテーブル６０のみを調査して、メディアセッション中に使用する関連するメディアデータ及び区分データの場所を識別してもよい。更なる可能な一実現例において、関係メタデータ４０は、コンテナファイル１の種々のヒントトラック５０、５２、５４と関連して格納される。それらヒントトラックは、メディアセッションと関連してメディアサーバにより使用されるＦＥＣ計算及び／又はコンパイル命令を含む。そのような場合、各ヒントトラック５０、５２、５４は、そのヒントトラック５０、５２、５４の命令により実現可能なメディアセッションに必要とされるメタデータ４０のみを含む必要がある。それら複数の可能な記憶場所の組合せが更に可能であり、本発明の範囲内である。
【００５６】
本発明の特定の一実施形態によると、メディアコンテナファイル１は、インタリーブユニットであり、漸進的なダウンロード又はストリーミングに対して最適化される。それにより、マルチメディア表現全体は、いわゆる漸進的なダウンロード又はストリーミングにより要求クライアントに送信及びダウンロードされる。
【００５７】
ＩＳＯに基づくメディアファイル形式［１］［２］［３］は、本発明のメディアコンテナファイルのファイル形式として採用されるのが有利である。別のコンテナファイル形式は、ＭＰ４ファイル形式、３ＧＰファイル形式及びＱｕｉｃｋＴｉｍｅ形式を含む。
【００５８】
ＡＬＣ（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」）により提供される。
【００６７】
（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;
}
これは、メディアソース区分を規定する１つのボックスを含むことができる。
【００６９】
（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は、最後のソース記号がファイル項目に格納されていないパディングを含むことを示す。
【００７９】
（項目情報ボックス）
ブロードキャスト／マルチキャストファイルダウンロードプロトコル（ＡＬＣ／ＦＬＵＴＥ）を使用して内部に埋め込まれた個別のメディアを送信するために、サーバはその個別のメディアに対応するメタデータを更に送信するのが好ましい。メタデータは、ＦＬＵＴＥがブロードキャストプロトコルとして使用される場合はＦＤＴの一部として送出され、ＡＬＣがＯＭＡのＢＣＡＳＴのＥＳＧと共に使用される場合はＯＭＡのＢＣＡＳＴのＥＳＧの一部として送出される。
【００８０】
メタデータ情報の一部は実行中に作成されてもよいため、ＦＬＵＴＥ及びＡＬＣの双方に共通で固定のメタデータの一部に対するテンプレート構造は、項目情報エントリの第２のバージョンとして規定される。項目情報エントリのこのバージョンは、ソースファイル区分を有する項目に対する項目情報ボックスにおいて使用される。
【００８１】
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[];
}
図５は、本発明に係るメディアセッション管理方法を示すフローチャートである。このメディアセッション管理は、ストリーミングサーバ又はダウンロードサーバ等のメディアサーバにおいて実行され、本発明のメディアコンテナファイルを使用する。方法は、メディアコンテナファイルが提供されるステップＳ３０において開始する。このファイルの提供は、メディアサーバの記憶場所からコンテナファイルを取り出すことにより実現されるが、これは、サーバがコンテンツ提供器又は作成器からファイルを事前に受信していることを示す。あるいは、メディアサーバは、メディアデータに対する要求と関連してコンテンツ提供器からのコンテナファイルを命令又は受信できる。
【０１２３】
次のステップＳ３１において、ＦＥＣ冗長データは、少なくとも１つのメディアソースブロックを使用し、少なくとも１つのソースブロックと関連付けられる区分情報及びメタデータに基づいて計算される。この計算ステップＳ３１において、Digital FountainのRaptorコーデック等のＦＥＣブロックコーデックが採用されるのが好ましく、それはメディアブロック毎に動作する。しかし、重畳ＦＥＣコーデックが採用されてもよく、それは本発明の範囲内である。好適な一実現例において、ＦＥＣ冗長記号のセットは、少なくとも１つのメディアソースブロックに対して生成されてもよい。このＦＥＣ記号セットは、メディアソースブロックのソース記号に基づいて計算された１つのＦＥＣ記号、好ましくは複数のＦＥＣ記号を含むことができる。メディアソースブロックに対して計算するＦＥＣ記号の数は、採用されるＦＥＣコーデックの制限によって規定されるか、メディアソースブロックのメディアソース記号の数の関数であるか、あるいはＦＥＣオーバヘッド等の他の基準により制限されてもよい。更に、メディアコンテナファイルに含まれる情報は、計算するＦＥＣ冗長データの量を特定できる。
【０１２４】
好適な一実現例において、メディアコンテナファイルは、このステップＳ３１において使用されるＦＥＣ計算命令を更に含む。ＦＥＣ記号の生成のためにＦＥＣコーデックに入力されるソース記号を選択する時に、それら命令は区分情報（及び区分情報を識別するのに使用されるメタ情報）と共に使用される。
【０１２５】
コンテナファイルがメディアソースファイルのメディアソースブロックへの分割の情報を更に含む場合、この分割情報は、ＦＥＣデータ計算に使用される適正なソース記号を識別するために使用される。
【０１２６】
ステップＳ３１で計算されるＦＥＣ記号の数は、メディアセッション中のその時点で許容される最大／最小のＦＥＣオーバヘッド等のローカル基準に基づいてメディアサーバにより判定される。あるいは、上述のように、ＦＥＣ計算命令等のコンテナファイルに提供される情報は、所定のメディアソースブロックに対して計算されるＦＥＣ冗長データの量を特定する。
【０１２７】
ステップＳ３１のＦＥＣデータの計算は、進行中のメディアセッション中リアルタイムで実行される。あるいは、メディアサーバは、実際のセッションの前にＦＥＣデータのリザーバを生成し、ＦＥＣリザーバをコンテナファイル又はメモリに格納できる。事前に計算されたＦＥＣデータは、後続のメディアセッションにおいてコンテナファイルのメディアコンテンツと共に使用される。
【０１２８】
次のステップＳ３２において、メディアデータパケットは、コンテナファイルのメディアソースブロックからメディアデータを抽出し、ステップＳ３１で計算されるようなＦＥＣ冗長データを提供することによりコンパイルされる。メディアサーバは、メディアセッション中に送信するためにメディアデータの識別子を受信するのが好ましい。あるいは、コンテナファイルは、メディアソースの選択が必要ないように単一のメディアデータファイルのメディアデータのみを含んでもよい。いずれの場合においても、ファイルプロパティテーブル等のコンテナファイルに含まれる上述の情報は、メディアファイルの開始、すなわち送信が開始されるべき第１のメディアソースブロックを識別するために使用される。更に、コンテナファイルに含まれる更なる情報は、メディアデータ及びＦＥＣデータを組み合わせて、種々のクライアントに対する１つの無線チャネル又は複数のチャネルを介する無線送信に適応されたデータパケットに含める方法に関する命令として使用される。
【０１２９】
次のステップＳ３３において、ＦＥＣ信頼性保護を有するコンパイルされたメディアデータパケットは、好ましくはブロードキャスト又はマルチキャスト技術によりクライアントに送信され、クライアントにおいてメディアデータがレンダリングされる。メディアサーバの送信バッファが所定のレベルに到達すると、通常、パケット送信は開始される。しかし、メディアセッション中、他のパケットが送信される間、新しいデータパケットがコンパイルされて送信バッファに入力される。これを線Ｌ２により概略的に示す。
【０１３０】
メディアデータの編成及び生成されたコンテナファイル、並びに事前に計算された区分データの提供により、メディアセッション中のメディアサーバの処理要求が低減される。従って、これにより、サーバが実行中にソースブロック構成及び区分を実行する必要がないため、サーバの複雑さが軽減され、サーバに柔軟性が与えられる。
【０１３１】
その後、方法は終了する。
【０１３２】
図６は、図５のメディアセッション管理方法の追加のステップを示すフローチャートである。方法は、図５のステップＳ３０から継続する。次のステップＳ４０において、メディアサーバは、ＦＥＣデータ計算のために採用するＦＥＣアルゴリズム又はコーデックを選択する。このＦＥＣアルゴリズムは、ＦＥＣデータが計算される際に基づくメディアソースブロックを区分する時に使用されるＦＥＣアルゴリズムであるのが好ましい。従って、メディアコンテナファイルはこのＦＥＣアルゴリズム／コーデックの情報を含むの好ましく、これは選択ステップＳ４０においてメディアサーバにより採用される情報である。
【０１３３】
ＦＥＣ情報が複数の利用可能なＦＥＣアルゴリズムの識別子を含み、所定のメディアソースブロックが複数の種々の区分において利用可能である場合、メディアサーバは、ＦＥＣデータを計算する時に使用するＦＥＣアルゴリズム及びブロック区分情報を選択するために、ＦＥＣオーバヘッド容量及び／又はＦＥＣ計算命令を含む他の入力情報を使用するのが好ましい。
【０１３４】
その後、方法は図５のステップＳ３１に継続し、選択されたＦＥＣアルゴリズムはＦＥＣデータを計算するために使用される。
【０１３５】
図７は、図４のセッション管理方法の追加のステップを示すフローチャートである。方法は、図５のステップＳ３１から継続する。次のステップＳ５０において、メディアセッションにおいてデータを送信するために現在採用できるＦＥＣオーバヘッド容量が判定される。この容量は、メディア送信のためにサーバに割り当て可能な帯域幅レベル、このメディア送信のために採用される無線記憶媒体に対する最小及び最大のビットレートレベル等に基づいて判定又は少なくとも推定される。実際には、従来技術において周知のデータ送信と関連してそのようなオーバヘッド容量を判定する任意の技術が、ステップＳ５０において採用されてもよい。
【０１３６】
ＦＥＣオーバヘッド容量が判定されると、次のステップＳ５１は、判定されたオーバヘッド容量に基づいてコンパイル命令セットを選択する。メディアコンテナファイルは、所定のメディアコンテンツに使用されるコンパイル命令の複数の別のセットを含むが、種々のレベルのＦＥＣオーバヘッドを提供する。換言すると、基本的にそれら別のコンパイル命令は、メディアデータパケットをコンパイルする時にメディアデータに追加するＦＥＣ冗長データの量を規定する。許容されるＦＥＣオーバヘッドが大きくなると、より多くのＦＥＣデータが追加される。種々の別のコンパイル命令を有することにより、メディアサーバは、現在のオーバヘッドの制限を与えられる許容される最大のＦＥＣ保護を可能にするそれら命令を使用でき、それにより、単一のコンパイル命令のセットを使用する場合と比較して種々のクライアントでメディアデータを正常に受信及び復号化する機会が増加する。
【０１３７】
方法は、図５のステップＳ３２に継続する。ステップＳ３２において、メディアデータパケットは、ステップＳ５１で選択されたコンパイル命令に基づいてメディアコンテンツデータ及び関連するＦＥＣデータからコンパイルされる。
【０１３８】
メディアコンテナファイルがファイルからブロックへの分割の情報、ＦＥＣアルゴリズムの情報及び／又はファイルプロパティテーブル等の追加の情報を更に含む場合、メディアサーバは、データパケットの生成及び送信の際にその追加の情報を使用できる。
【０１３９】
例えば、メディアサーバにとって有用な追加のデータ、好ましくはＭＩＭＥタイプの情報、任意の符号化情報、サイズ情報等は、ファイルプロパティテーブルに含まれるか又は少なくとも公表される。好適な一実現例において、このプロパティテーブルは、メディアの抽出、データパケットのコンパイル及び送信と関連して有利な又は必要とされる情報を取得するためにメディアサーバによりアクセスされる単一情報又はルックアップソースを構成する。
【０１４０】
図８は、本発明の一実施形態に従って別のコンパイル命令の使用を示すために使用される本発明に係るメディアコンテナファイル１を示す概略図である。コンテナファイル１は、好ましくは複数のメディアソースブロックを含むメディアソースファイル１０を含む。本実施形態において、ソースファイル１０の各メディアソースブロックは関連する区分情報３０を有する。この図示される例において、コンテナファイル１は、種々のＦＥＣオーバヘッドのコンパイル命令を含む３つのヒントトラック５０、５２、５４を更に含む。例えば、１０％の冗長オーバヘッドが望ましい場合に第１のヒントトラック５０が使用され、第２のヒントトラック５２は約１２％のＦＥＣオーバヘッドを与え、第３のヒントトラック５４は１４％のＦＥＣオーバヘッドを与える。図中、文献［５］の付録Ｂにおいて提案されるソースブロック構成アルゴリズムが採用されている。
【０１４１】
区分情報３０は、ソースファイル１０のメディアソースブロックに基づいてＦＥＣデータ７０を計算するためにＦＥＣコーデックにより採用される。ソースファイル１０が複数のメディアソースブロックを含む場合、複数のＦＥＣデータセット又はリザーバ７０、すなわち好ましくはメディアソースブロック毎にＦＥＣデータの１つのセットが計算される。
【０１４２】
第１のヒントトラック５０が選択される場合、データパケット８１、８２、８３、８４の第１のストリーム（図中、メディアソースブロック毎及びＦＥＣブロック毎に１つのデータパケットのみが示される）が生成される。しかし、第２のヒントトラック５２が使用される場合、データパケット９１、９２、９３、９４の第２のストリームが生成される。第１のストリーム８０と比較して、第２のストリーム９０はメディアソースブロック毎により大きなＦＥＣブロック、すなわちより多くのＦＥＣ冗長データを含む。しかし、各ソースブロックは２つのストリーム８０、９０に同一量のメディアデータを含む。
【０１４３】
図９は、本発明のメディアコンテナファイル１を生成又は使用する要素を示す通信ネットワークの概略図である。コンテンツサーバ１００は、メディアソースデータを受信するか又はメディアソースデータへのアクセス権を有し、メディアコンテナファイル１を構成するコンテンツ提供器又は作成器を表す。このコンテナファイル１のコピーは、図において移動端末により表される種々のクライアント３００、３１０、３２０に送信（マルチキャスト）されるＦＥＣデータ及びメディアを含むデータパケットをコンパイルするためにメディアセッションにおいてコンテナファイル１を使用するメディアサーバ２００に送出される。
【０１４４】
図１０は、本発明に係るメディアコンテンツサーバ１００を示す概略ブロック図である。コンテンツサーバ１００は、外部ユニットと通信するための機能性（送信機／受信機、変調器／復調器、符号器／復号器）を含むように構成される一般的な入出力（Ｉ／Ｏ）ユニット１１０を具備する。このＩ／Ｏユニット１１０は、特に入力メディアコンテンツを受信及びメディアコンテナファイルに対する要求を受信するように構成される。Ｉ／Ｏユニット１１０は、通信ネットワークにおいてそのようなコンテナファイルを他のサーバに送信する時にサーバ１００により採用される。
【０１４５】
コンテンツサーバ１００は、本発明のメディアコンテナファイルを作成するように構成されるコンテナファイル作成器１６０を更に具備する。サーバ１００は、ファイル作成器１６０のメディアブロックマネージャ１６１によりメディアコンテナファイルに入力される少なくとも１つのメディアソースブロックを提供するように構成されるメディアブロック提供器１３０を更に具備する。メディアブロック提供器１３０は、外部メディアソース４００、４１０からメディアコンテンツを受信するＩ／Ｏユニット１１０又は内部データ記憶装置１２０から少なくとも１つの入力ソースブロックを提供する。
【０１４６】
メディアソースブロックは、コンテンツサーバ１００のブロック区分器１４０に転送される。この区分器１４０は、ＦＥＣデータを計算する目的でソースブロックに適用されるＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、入力メディアソースブロックを通常は複数のそのようなソース記号である多数のソース記号に区分する。区分動作は、ソースブロックをソース記号に物理的に分割する必要があるとは限らない。それとは非常に対照的に、区分は、ソースブロックの種々の部分を種々のソース記号に割り当てることによる実質的な分割であってもよい。
【０１４７】
ソースブロックに適用され、ブロック区分に影響を与えるＦＥＣアルゴリズムは、メディアソースブロックに対して常に採用される事前定義済みの標準ＦＥＣアルゴリズムであってもよい。あるいは、コンテンツサーバ１００のブロック区分器１４０又は他のユニットは、複数の利用可能なそのようなアルゴリズムから使用する特定のＦＥＣアルゴリズムを選択する。この選択において、予想される最大のＦＥＣオーバヘッド等の種々の入力データが使用される。更なる一実施形態において、ブロック区分器１４０は、種々の別の利用可能なＦＥＣアルゴリズムの情報に基づいて所定のメディアソースブロックの複数の別の区分を実行する。例えば、コンテンツサーバ１００がメディアサーバにおいて利用可能なＦＥＣアルゴリズムに関する知識を有する場合、ブロック区分器１４０は、ＦＥＣアルゴリズム毎に別個のブロック区分を実行できる。
【０１４８】
ブロック区分器１４０は、メディアソースブロックに適用される特定のＦＥＣアルゴリズム又は方式に基づいてブロック区分を実行することに加え、メディアセッション中にメディアサーバにより採用されるデータパケットにソース記号を収めるように適応された区分を実行するように更に動作可能である。従って、ＵＤＰパケットサイズ等のパケットサイズの情報は、区分器１４０により採用可能である。
【０１４９】
区分器１４０により実行される特定のソースブロック区分の情報は、情報生成器１５０により生成される。上述したように、この情報は、メディアソースブロックのどのビットがどのソース記号に属するかを特定できるか、あるいはより小さいサイズのソース記号である最後のソース記号を除いて、ソースブロックの全てのソース記号に適用される記号サイズを規定できる。
【０１５０】
この場合、ブロック区分器１４０はメディアソースブロックの複数の別の区分を実行し、生成器１５０により生成される情報はそれら別のブロック区分に関するデータを含む。
【０１５１】
区分情報は、情報をメディアコンテナファイルに挿入するコンテナファイル作成器１６０の情報マネージャ１６２に生成器から転送される。
【０１５２】
ファイル作成器１６０のメタデータマネージャ１６３は、メタデータをコンテナファイルに提供する。このメタデータは、ブロックマネージャ１６１により編成されるメディアソースブロックと区分情報マネージャ１６２により編成される区分情報との関係を提供する。
【０１５３】
結果として得られるメディアコンテナファイルは、データ記憶装置１２０に少なくとも一時的に格納されるか、あるいはＩ／Ｏユニット１１０によりメディアサーバに送信される。
【０１５４】
コンテンツサーバ１００のユニット１１０、１３０、１４０、１５０、１６０、１６１、１６２及び１６３は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１１０〜１６３が全て、通信システムの１つのネットワークノードのコンテンツサーバ１００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテンツサーバ１００の種々のユニット１１０〜１６３が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。
【０１５５】
図１１は、図１０のメディアブロック提供器１３０の一実施形態を更に詳細に示す概略ブロック図である。好適な一実現例において、入力メディアコンテンツは、例えばコンテンツサーバのデータ記憶装置又はＩ／Ｏユニットからメディアファイル提供器１３２により提供されるメディアソースファイルの形式である。メディアソースファイルは、ファイル提供器１３２によりメディアファイル分割器１３４に転送される。分割器１３４は、ソースファイルを１つ以上のソースブロックに分割する。分割器１３４は、このファイル分割を種々の情報又はパラメータに基づいて行なう。例えばファイル分割は、ＦＥＣ冗長データの計算に適用されるＦＥＣアルゴリズムに基づいて少なくとも部分的に判定される。そのような場合、ファイル分割１３４は、そのようなＦＥＣアルゴリズムの情報へのアクセス権を有するのが好ましい。分割器１３４は、メディアソースファイルをＮ−１個のサイズが等しいメディアソースブロック及びＮ−１個のブロックより小さなサイズを有する可能性のある１つのメディアソースブロックに分割できる。
【０１５６】
分割情報生成器１３６は、ファイル分割器１３４に接続されて構成される。生成器１３６は、ファイル分割器１３４により判定され、可能性として実行されるファイル分割の情報を生成する。第１の実現例において、生成された情報は、異なるメディアソースブロックに属するメディアソースファイルのビットを特定できる。第２の実現例において、情報は、可能性としてより小さなサイズを有する最後のソースブロックを除くメディアソースブロックのサイズ（ビット又は記号サイズ）を特定する。そのような場合、メディアソースファイルの開始場所を認識すると、種々のメディアソースブロックはその（サイズ）分割情報を使用して識別される。
【０１５７】
分割情報マネージャ１３８は、情報生成器１３６からの分割情報をメディアコンテナファイルに編成するためにブロック提供器１３０において実現される。
【０１５８】
メディアブロック提供器１３０のユニット１３２〜１３８は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１３２〜１３８が全て、メディアブロック提供器１３０において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、メディアブロック提供器１３０の種々のユニット１３２〜１３８がコンテンツサーバの他の場所に配置されてもよい。
【０１５９】
図１２は、図１０のコンテナファイル作成器１６０の一実施形態を更に詳細に示す概略ブロック図である。このファイル作成器１６０は、上述のメディアブロックマネージャ１６１、区分情報マネージャ１６２及びメタデータマネージャ１６３に加え、ＦＥＣ情報マネージャ１６４を含む。このＦＥＣ情報マネージャ１６４は、コンテナファイルのメディアソースブロックに適用されるＦＥＣアルゴリズムの情報を生成し、コンテナファイルに編成する。コンテンツサーバのブロック区分器により実行されるブロック区分は、ブロック区分を実行する時にもそのようなＦＥＣアルゴリズム情報を使用する。従って、ブロック区分が実行された時に基づいたＦＥＣアルゴイズムの情報は、マネージャ１６４により生成され、コンテナファイルに含まれるのが好ましい。
【０１６０】
テーブルマネージャ１６５は、プロパティテーブルを生成し、コンテナファイルに含めるためにファイル作成器１６０に含まれてもよい。このプロパティテーブルは、ファイルタイプ、ファイルサイズ、ファイル記憶場所、ファイル暗号化、ファイル名／識別子等のメディアソースファイルの情報をコンテナファイルに含むことができる。更に、本発明の区分情報、ファイル分割情報及びメタデータは、テーブルマネージャ１６５により生成されたプロパティテーブルに含まれる。
【０１６１】
ＦＥＣ命令マネージャ１６６は、コンテナファイルのメディアソースブロックに基づいてＦＥＣデータを生成する時にメディアサーバが従うＦＥＣ命令を生成するためにファイル作成器１６０に含まれる。それら命令は、特定のメディアソースブロックと関連付けられる区分情報と共に、ＦＥＣ記号を計算するためにＦＥＣコーデックに入力されるソース記号を特定する。種々の別のＦＥＣ命令がマネージャ１６６により所定のソースブロックに対して提供される。ここで、ＦＥＣ命令は異なるＦＥＣコーデック及び／又はＦＥＣオーバヘッドと関連して使用されるように適応される。
【０１６２】
ファイル作成器１６０のコンパイル命令マネージャ１６７は、コンパイル命令を生成し、コンテナファイルに挿入する。それら命令は、メディアソースブロックのメディアデータとソースブロック及び区分情報を使用して計算されるＦＥＣデータとをコンパイルするためにメディアサーバにより使用される情報を含む。マネージャ１６７は、ファイルのメディアコンテンツ毎に単一の命令又は命令のセットを生成できる。あるいは、種々のＦＥＣオーバヘッドに適応された種々のそのような命令、種々のＦＥＣデータタイプ及び／又はメディアセッションで採用される異なる数の無線通信チャネルがマネージャ１６７により提供され、コンテナファイルに編成される。
【０１６３】
コンテナファイル作成器１６０のユニット１６１〜１６７は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１６１〜１６７が全て、コンテナファイル作成器１６０において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテナファイル作成器１６０の種々のユニット１６１〜１６７がコンテンツサーバの他の場所に配置されてもよい。
【０１６４】
図１３は、本発明に係るメディアセッションサーバ２００を示す概略ブロック図である。このメディアサーバ２００は、外部ユニットとの通信を実行するＩ／Ｏユニット２１０を具備する。このＩ／Ｏユニット２１０は、特にコンテンツサーバからのメディアファイルコンテナを要求及び受信するように構成される。更にＩ／Ｏユニット２１０は、種々のユーザクライアントからのメディアコンテンツに対する要求又は少なくともメディアコンテンツが送信されるべきクライアントの情報に対する要求を受信する。メディアサーバ２００によりコンパイルされるデータパケットは、Ｉ／Ｏユニット２１０によりそれらクライアントに送信される。
【０１６５】
サーバ２００は、現在のセッションで使用するメディアコンテンツファイルを提供するメディアファイル提供器２２０を具備する。このファイル提供器２２０は、Ｉ／Ｏユニット２１０によりコンテンツ作成器に送信される特定のコンテナファイルに対する要求を生成してもよい。あるいは、提供器２２０は、メディアサーバ２２０に提供されたデータ記憶装置２５０から事前に受信したコンテナファイルを取り出す。
【０１６６】
メディアサーバ２００のＦＥＣ計算器又はコーデック２４０は、コンテナファイルに格納される少なくとも１つのメディアソースブロックに対するＦＥＣ冗長データを計算する。この計算手順において、ＦＥＣ計算器２４０は、上述のＦＥＣアルゴリズムのうち任意のアルゴリズムを使用できる。好適な一実現例において、コンテナファイルは、選択肢がある場合に採用するＦＥＣアルゴリズムを計算器２４０に指示する。まずＦＥＣ計算器２４０は、入力メディアソースブロックに対する関連する区分情報を識別する。この識別手順において、ソースブロックに関連付けられ、コンテナファイルに提供されるメタデータは、計算器２４０により使用される。その後、計算器２４０は、ＦＥＣデータを生成するためにＦＥＣアルゴリズム（コンテナファイルのＦＥＣ情報に基づいて選択される）が適用されるべきメディアソースブロックのそれら部分を識別するための区分情報を使用する。
【０１６７】
好適な一実施形態において、適正な入力ソース記号を識別し、実際のＦＥＣデータ計算を実行する場合、メディアコンテナファイルは、区分情報に加え計算器２４０により使用されるＦＥＣ計算命令を更に含む。更なる入力情報は、上述のＦＥＣアルゴリズム情報（使用する適正なＦＥＣアルゴリズムの選択を可能にする）及びファイル分割情報（適正なメディアソースブロックの識別を可能にする）であってもよい。
【０１６８】
データパケットコンパイラ２３０は、提供器２２０からのコンテナファイルに含まれるコンパイル命令を使用して、ファイルからメディアデータ及びＦＥＣ計算器からＦＥＣデータを抽出し、その抽出データを含むデータパケットを生成するのが好ましい。そのように生成されたデータパケットは、Ｉ／Ｏユニット２１０により送信される（Ｉ／Ｏユニット２１０からストリーム又はダウンロードされる）。
【０１６９】
種々のコンパイル命令は、所定のメディアコンテンツに対するファイルに含まれる。例えば、命令はチャネルに依存するか又は容量に依存する。前者の場合、利用可能な無線チャネルの数及び送信されるべき並列メディアストリームの数により、コンパイラ２３０が使用する実際のコンパイル命令が判定される。後者の場合、ＦＥＣ容量推定器２６０は、セッション中に採用されるＦＥＣオーバヘッドの最大量を推定するためにサーバ２００に含まれるのが好ましい。オーバヘッド容量がセッションにわたり変化するため、推定器２６０により実行されるオーバヘッドの推定はセッション中に動的に更新されるのが好ましい。セット選択器２７０は、使用するファイルにおいて利用可能な特定のコンパイル命令又はコンパイル命令の命令セットを選択するために推定器２６０からの容量推定値を使用する。パケットコンパイラ２３０は、メタデータ及びＦＥＣデータをデータパケットにコンパイルするためにこの命令（セット）を使用する。
【０１７０】
メディアサーバ２００のユニット２１０、２２０、２３０、２４０、２６０及び２７０は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット２１０〜２７０が全て、通信システムの１つのネットワークノードのメディアサーバ２００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、メディアサーバ２００の種々のユニット２１０〜２７０が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。
【０１７１】
添付の請求の範囲に規定される本発明の範囲から逸脱せずに、本発明に対して種々の変形及び変更が行なわれてもよいことが当業者には理解されるだろう。
【０１７２】
（参考文献）
［１］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、２００４年２月
［５］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、２００６年６月
［６］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、２００２年１２月
【技術分野】
【０００１】
本発明は、一般に、メディア及びマルチメディアの管理に関し、特に、そのようなメディア及びマルチメディアコンテンツを含むメディアコンテナファイルの作成及び使用に関する。
【背景技術】
【０００２】
メディア及びマルチメディアを種々のネットワークを介してクライアントへ提供することが過去数年で急増している。今日、例えば映像及び音声ストリーム又は映像及び音声ファイルの形式のメディアにアクセスするために及びそれらメディアをメディアサーバからダウンロードするために、多くのユーザがインターネットを採用している。このメディアの提供は、無線を使用するモバイル通信ネットワークにおいて開始された。現在、マルチメディア又はＴＶコンテンツに対してモバイルネットワークを使用することに非常に大きな関心がある。これは、多くの場合、従来技術においてモバイルＴＶと呼ばれる。今日、モバイルネットワークにおけるこのメディアの提供は、主にユニキャスト転送を介して利用可能である。しかし、現在、モバイルＴＶのブロードキャスト／マルチキャスト配信方法は開発中である。そのような標準化の取り組みの例は、３ＧＰＰのマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）及びヨーロッパ電気通信標準化協会（ＥＴＳＩ）のデジタルビデオブロードキャスト−ハンドヘルド（ＤＶＢ−Ｈ）である。
【０００３】
種々の有線及び無線通信ネットワークにおけるメディア提供に対する増加する要求に応じて、要求クライアントにメディアコンテンツを提供するために無線ネットワークにおいて利用可能なストリーミングサーバ及びダウンロードサーバの開発において進行中の作業がある。透過的で柔軟性のあるストリーミング／ダウンロードサーバに向かう一般的な傾向があり、それは、基本的にはサーバが種々のメディア管理機能を実行する複数の「標準」モジュール又はプログラムから構成されるべきであることを示す。それら機能に対する入力メディアコンテンツは、モジュール／プログラムがコンテンツを処理する方法に関する命令と共に提供される。これにより、サーバにおいて固定の定義済みメディア処理を使用することと比較してより柔軟性のあるメディア提供が提供される。
【０００４】
従って、透過的で柔軟性のあるストリーミング／ダウンロードサーバを有するという傾向に合わせて使用されるメディアコンテナ形式が必要とされている。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、従来の構成のそれら欠点及び他の欠点を克服する。
【０００６】
本発明の一般的な目的は、マルチメディアセッションにおいて使用されるメディアコンテナファイルを提供することである。
【課題を解決するための手段】
【０００７】
本目的及び他の目的は、添付の請求の範囲により規定される本発明により達成される。
【０００８】
簡単に説明すると、本発明は、メディアコンテナファイルの生成及びその使用を含み、そのようなコンテナファイルを生成及び使用する装置を含む。
【０００９】
メディアコンテナファイルを生成することは、要求クライアントに送信され、クライアントでレンダリングされるメディアデータ又はマルチメディアデータを含む少なくとも１つのメディアソースファイルを提供することを含む。このコンテナファイルは、コンテナファイルのサイズに依存して、１つ以上のメディアソースブロックから構成されると考えられる。少なくとも１つのそのようなメディアソースブロックは、ソースブロックに基づいてＦＥＣ冗長データ又は記号を計算する目的で、ＦＥＣコーデックが処理するのを可能にするサイズを有するソース記号又は部分にソースブロックを区分することにより本発明に従って処理される。メディアソースブロックに対して使用する選択されたブロック区分の情報は、生成され、ソースブロックの実際のメディアコンテンツと共にコンテナファイルに格納される。メタデータは、メディアソースブロックとその区分情報との関係を提供するために提供され、コンテナファイルに含まれる。
【００１０】
結果として得られるコンテナファイルは、コンテナファイル中の区分情報を使用してＦＥＣデータを計算し、ファイルのメディアデータ及び計算したＦＥＣデータを含むデータパケットをコンパイルするために、メディアセッション中にメディアサーバにより採用される。種々のＦＥＣアルゴリズムに基づいてメディアソースブロックを区分し、本発明のコンテナファイルに含まれるＦＥＣ情報を生成することに関するメディアソースブロックの前処理により、メディアサーバは、単純で計算コストの安価な方法でＦＥＣデータを計算でき、広範囲にわたるデータ処理及び計算量の多いブロック区分なしで要求クライアントに送信されるデータパケットにメディアデータ及びＦＥＣデータを挿入できる。
【００１１】
好適な一実施形態において、コンテナファイルは、ＦＥＣデータを計算する場合、並びにコンテナファイルのメディアデータ及びＦＥＣデータを含むデータパケットをコンパイルする場合にメディアサーバが使用し、従う命令を更に含む。そのような場合、コンテナファイルは、メディアデータが確実にクライアントに正常に転送されるのに必要とされる全てのメディアコンテンツ及び命令を含む。
【図面の簡単な説明】
【００１２】
【図１】本発明の１つの面に従ってメディアコンテナファイルを生成する方法を示すフローチャートである。
【図２】図１のメディアブロック提供ステップを更に詳細に示すフローチャートである。
【図３】図１のファイル生成方法の追加のステップを示すフローチャートである。
【図４】本発明の別の面に係るメディアコンテナファイルを示す概略図である。
【図５】本発明の更なる面に係るメディアセッション管理方法を示すフローチャートである。
【図６】図５のセッション管理方法の追加のステップを示すフローチャートである。
【図７】図５のセッション管理方法の追加のステップを示すフローチャートである。
【図８】本発明に従ってメディアコンテナファイルを採用する種々のメディアストリームのコンパイルを示す概略図である。
【図９】本発明に従ってメディアコンテナファイルを管理するメディアサーバを含む通信ネットワークを示す概略図である。
【図１０】本発明の更に別の面に係るコンテンツサーバを示す概略ブロック図である。
【図１１】図１０のメディアブロック提供器の一実施形態を更に詳細に示す概略ブロック図である。
【図１２】図１０のコンテナファイル作成器の一実施形態を更に詳細に示す概略ブロック図である。
【図１３】本発明の更に別の面に係るメディアセッションサーバを示す概略ブロック図である。
【発明を実施するための形態】
【００１３】
添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。
【００１４】
図中、同一の図中符号は対応する要素又は類似する要素に対して使用される。
【００１５】
本発明は、一般に、メディア及びマルチメディアデータの管理に関し、特に、無線を使用する通信ネットワークにおけるストリーミングサーバ又はダウンロードサーバ等のメディアサーバと関連してコンテナファイルを作成及び利用することに関する。本発明のそれらメディアコンテナファイルは、要求クライアントに送信するメディアコンテンツとメディアサーバにおいてメディア処理及び送信を実行するのに使用される命令とを含む。本発明によると、メディアコンテンツは前処理されており、メディアセッション中にメディアサーバによる効率的な管理を可能にする形式で存在する。本発明の特定の面において、元のメディアコンテンツは、メディアセッションに対する信頼性保護の提供をメディアサーバにおいて簡単化するために前処理されている。従って、コンテンツは、要求クライアントへの正常な配信の確率を増加するためにメディアセッションにおいて使用されるメディアコンテンツからの信頼性保護データの計算を可能にする形式である。
【００１６】
本発明の好適な一実施形態によると、メディアコンテンツの前処理は、メディアサーバにおいて、送信されたメディアストリームに含まれる順方向誤り訂正（ＦＥＣ）冗長データを計算するために実行及び適応される。
【００１７】
この分野で周知のように、ＦＥＣは送信されたペイロードデータに冗長データを追加することを含み、それにより受信機は追加のデータを送信機に要求する必要なく誤りを検出及び訂正できる。ＦＥＣの利点は、平均して必要とされる帯域幅が大きくなるが、データの再送信が回避されることが多いことである。従って、ＦＥＣがメディアコンテンツのマルチキャスト／ブロードキャストによる配信に関連して使用されるのが有利であり、この場合、再送信が行なわれにくくなる。
【００１８】
ＦＥＣは、従来技術においては通常ＦＥＣコーデックである選択されたアルゴリズム又は方式を使用して送信される情報に冗長性を追加することにより達成される。そのような各冗長ビットは、常に多くの元の情報又はペイロードビットの複素関数である。出力に未変更の入力を含むＦＥＣコーデックは、システムコーデックと呼ばれる。換言すると、（Ｎ，Ｋ）システムＦＥＣコーデックは、Ｋ個のソース記号又はペイロード記号を保存し、（Ｎ−Ｋ）個のＦＥＣ記号を付加する。同様に、（Ｎ，Ｋ）非システムＦＥＣコーデックは、必ずしも全てを保存されているわけではないＫ個のソース記号からＮ個の（ＦＥＣ又はソース）記号を作成する。
【００１９】
ＦＥＣコーデックには、ブロックコード及び冗長コードの２つの主な分類がある。ＦＥＣブロックコーデックは、所定サイズのビット又は記号の固定サイズブロック（パケット）に対して動作し、重畳コーデックは、任意の長さのビットストリーム又は記号ストリームに対して動作する。Digital FountainのRaptor符号は、単一のソースブロックから任意の数のＦＥＣ冗長記号を作成できるＦＥＣブロックコーデックである。これは、種々の保護オーバヘッドの構成がソースブロックの構成の変更を必要としないことを意味するため、このＦＥＣコーデックの有利な特性である。しかし、リードソロモンは、保護オーバヘッドの種々の大きさに対してソースブロックの区分の変更を必要とする別のＦＥＣブロックコーデックである。ＦＥＣブロックコーデックの他の例には、ゴレイ、ＢＣＨ（Bose, Ray-Chaudhuri, Hocquenghem）及びハミングがある。本発明に関連して使用する好適なＦＥＣコーデックは、Digital Raptorコーデックである。
【００２０】
本発明によると、メディアデータ又はメディアコンテンツ、あるいはマルチメディアデータ又はマルチメディアコンテンツは、データのレンダリングのためにコンテンツ提供器又はサーバがクライアントに提供できる任意のデータを示す。一般的な好適な例は、映像データ及び音声データを含む。データは、事前に符号化された固定レートの音声又は映像コンテンツバージョンの形式でもよく、スケーラブルな音声又は映像コンテンツの形式でもよい。他のメディアの例としては、静止画（ＪＰＥＧ）、ビットマップ画像（ＧＩＦ及びＰＮＧ）、ベクターグラフィックス（ＳＶＧ）、並びに合成音声（ＳＰ−ＭＩＤＩ）及びテキスト（ＸＨＴＭＬ及びＳＭＩＬ）がある。
【００２１】
図１は、本発明に従ってメディアコンテナファイルを生成する方法を示すフローチャートである。このメディアコンテナファイルは、メディアコンテンツを提供し、メディアデータを送信可能なデータパケットに形成するために、メディアセッション中にメディアサーバにより使用される完全な入力パッケージと考えられる。従ってコンテナファイルは、メディアコンテンツ自体に加え、処理を実行し、メディアセッション中にメディアコンテンツの送信を可能にするためにメディアサーバにより必要とされる情報及び命令を含むのが好ましい。
【００２２】
方法は、少なくとも１つのメディアソースブロックが提供されるステップＳ１において開始する。少なくとも１つのメディアソースブロックは、クライアントに送出されることが意図されるメディアデータ又は記号を含み、それらはメディアコンテンツをユーザに提示するためにレンダリングされる。メディアブロックは固定の同一サイズであってもよく、あるいは２つ以上の多い場合は、少なくともその一部分が異なるビット／記号サイズであってもよい。ステップＳ１において３つ以上のメディアソースブロックが提供される場合、それらブロックは、映像ストリーム等の同一のメディアコンテンツファイル又はストリーム、並びに／あるいは異なるメディアファイル又はストリームの個別のメディアブロックと考えられてもよい。例えば、映像ストリームのいくつかのメディアソースブロック及び対応する関連する音声ストリームのいくつかのメディアブロックと考えられてもよい。
【００２３】
このステップＳ１において、関連するメディアコンテンツが提供される。例えば、メディアコンテンツが音楽映像を含む場合、少なくとも１つの提供されたメディアブロックは映像データを含むのが好ましく、少なくとも１つのメディアブロックは対応する音声データを含む。しかし、１つの同一のメディアコンテンツが複数の潜在的なメディアバージョンで提供されてもよいことが本発明により理解される。例えば、音楽映像の映像部分は複数の事前符号化された映像バージョンで提供され、そのような各映像バージョンは、所定の帯域幅又はビットレートレベル又は間隔に関連して使用できるように適応される。従ってステップＳ１において、所定のメディアコンテンツの複数のバージョンが提供されてもよい。そのような場合、そのような各メディアバージョンは、１つ以上のメディアソースブロックから構成されると考えられる。複数のメディアバージョンが提供され、コンテナファイルに編成されてもよいが、通常は、メディアセッション中の所定の時間においてそのようなバージョンは１つのみ使用され、例えば利用可能な帯域幅のレベルの変化に基づいてセッション中にメディアバージョンの切り替えが行なわれてもよい。
【００２４】
次のステップＳ２において、提供されたメディアソースブロックはソース記号、すなわちいわゆるチャンクに区分される。一般に、それら記号は数百バイトで構成される。このブロックの区分は、現在のメディアソースブロックに対するＦＥＣ記号を計算するためにメディアサーバにより使用されるＦＥＣコーデック／アルゴリズムの情報に少なくとも部分的に基づいて実行される。上述したように、リードソロモンを使用するＦＥＣコードは、所望の保護オーバヘッドの大きさ、すなわちＦＥＣ冗長記号の数に基づいてソースブロック区分の変更を必要とする。従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアソース区分及びメディア記号サイズに影響を与える可能性がある。更に、メディアコンテンツを送信するためにメディアサーバにより使用されるユーザデータグラムプロトコル（ＵＤＰ）パケット等のデータパケットのサイズ等の他のパラメータは、このステップＳ２のソースブロック区分において使用される。そのような場合、少なくとも１つの完全なソース記号がＵＤＰパケットに収まるように、ソース記号のサイズは制限される。
【００２５】
この区分ステップＳ２は、メディアソースブロックがコンテナファイルの別個の場所に格納される別個のソース記号に物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割され、その結果、実質的にソース記号に区分される。
【００２６】
次のステップＳ３において、区分の情報が生成される。基本的にこの情報は、データシーケンスのどの部分がメディアソースブロックのどのソース記号に属するかを特定する。区分情報は、メディアソースブロックＺのビットＸ〜ビットＹがソース記号を構成することを特定するテーブルに編成されてもよい。あるいは、情報は、各ソース記号のバイトサイズを含むことができる。メディアファイルのメディアソースブロックの開始場所が分かると、種々のソース記号に属するデータ部分を判定できる。
【００２７】
所定のメディアソースブロックは、少なくとも２つの異なる区分動作に従って区分されることが本発明により理解される。例えば、第１のそのようなブロック区分は第１のＦＥＣアルゴリズムに適応され、第２の区分は第２のＦＥＣアルゴリズムに対して適応されて採用される。更にブロック区分は、メディアサーバにおける実際の所望のＦＥＣオーバヘッドに依存する可能性がある。そのような場合、種々のＦＥＣオーバヘッドに対して設計される種々のブロック区分は、ファイル作成時に判定される。区分情報は、所定のメディアソースブロックに適用可能なそれら別の区分の情報を含む。
【００２８】
ステップＳ４において、区分されたメディアブロック及び生成された区分情報は、メディアコンテナファイルに編成される。メディアコンテンツ及び情報は、コンテナファイルの部分として挿入される。更に、コンテナファイルに編成された少なくとも１つのメディアブロックは、メディアセッション中にクライアントに送信される全てのメディアコンテンツデータを一括して含むのが好ましい。換言すると、コンテナファイルはマルチメディア表現全体に対するメディアデータを含む。
【００２９】
次のステップＳ５は、コンテナファイルに含まれるメタデータを提供する。このメタデータは、ステップＳ４でコンテナファイルに追加されたメディアソースブロックとステップＳ４でファイルに格納された区分との関係を提供する。この関係は、ファイル内のメディアソースブロックの記憶場所から区分情報の記憶場所へのポインタ又は区分情報の記憶場所からメディアソースブロックの記憶場所へのポインタの形式である。従って、特定のメディアソースブロック又はコンテナファイル内のそのブロックの場所が与えられると、このメタデータは関連する区分情報又はファイル内のその情報の記憶場所の識別を可能にする。メディアソースブロックの識別子及び／又は関連する情報がコンテナファイルの事前定義済みの「標準」又は「デフォルト」の場所に格納される場合、ポインタを採用する代わりに、メタデータはそれらメディアソースブロックの識別子及び／又は関連する情報を含むことができる。メタデータは、ファイルのメディアソースブロック及び区分の一方を識別するために使用され、その識別した場所に基づいて、メディアソースブロック及び情報のうちのもう一方が識別される。
【００３０】
本発明の一般的な実現例において、複数のメディアソースブロックがステップＳ１において提供される。この場合、ステップＳ２〜ステップＳ５がそのような各メディアソースブロック又は少なくともメディアソースブロックの複数のグループに対して繰り返されるのが好ましい。これを線Ｌ１により概略的に示す。ステップＳ１においてＮ個のメディアソースブロックがコンテナファイルに編成される場合、ステップＳ２〜ステップＳ５はＮ回繰り返されるのが好ましく、これは、ソースブロックに加え、区分情報及びメタデータの、Ｎ個のバージョンをコンテナファイルに編成することを示す。
【００３１】
その後、方法は終了する。
【００３２】
上述したように、本発明の目的は、実際のメディアデータに加え、ＦＥＣデータを計算する時に使用されるＦＥＣに依存する区分情報を更に含むメディアコンテナファイルを提供することである。これは、ファイルからソースブロックへの分割及びブロック区分が「オフライン」で行なわれ、メディアサーバにおける実際のメディア送信処理とは無関係であることを意味する。この前処理は、サーバのタスクを簡単化し、性能要求及びサーバの複雑さを軽減する。更に、コンテナファイルは、メディアデータ及び計算されたＦＥＣデータを識別し、要求クライアントに送信されるメディアストリームに構成するためにメディアサーバにより必要とされる情報及び命令を更に含むのが好ましい。従って、コンテナファイルは、データのコンパイル及び送信のために透過的で柔軟性のあるサーバにより使用されるデータ、情報及び命令の完全なパッケージとして考えられる。
【００３３】
図１と関連して上述したコンテナファイルの生成は、内部又は外部メディアコンテンツソースへのアクセス権を有するコンテンツ作成器又はサーバにおいて実行されるのが好ましい。生成されたコンテナファイルは、例えばローカルシステム内の転送、あるいはローカル又はグローバルネットワークを介する送信のために、コンピュータメモリ等の記憶媒体、あるいは電子信号又は無線信号等の物理信号で表されてもよい。一般的な一実施形態において、コンテナファイルは、種々のクライアントとのメディアセッションにおいて使用するためにメディアサーバに無線信号として提供される。
【００３４】
以下において、メディアコンテナファイルという用語は、本開示において、記憶媒体に格納するためのデータファイル及び転送又は配信するための信号を含むという意味を含んで使用される。
【００３５】
図２は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、少なくとも１つのメディアソースファイルが提供されるステップＳ１０において開始する。図示される本実施形態において、メディアコンテンツは、メディアデータを含むソースファイル又はストリームの形式でコンテナファイル作成器において入手可能である。このステップＳ１０において、１つ以上のメディアソースファイルはコンテナファイルに含むために提供される。例えば、第１のメディアファイルは映像データを含むことができ、第２の関連するファイルは音声データを含む。メディアサーバにおいてＦＥＣ冗長データの効率的な計算及びその後のそのようなＦＥＣデータの使用を可能にするために、次のステップＳ１１において、ステップＳ１０で提供されるメディアソースファイルは複数のメディアブロックに分割される。このメディアソースブロックは、メディアソースファイルのセグメントとして考えられ、ＦＥＣコードはそのセグメントに対して適用されるか又は動作する。ソース記号又はデータビットでのメディアブロックのサイズは、分割に関連して事前定義されるか又は選択される。前者の場合、サイズはＦＥＣ冗長データの計算に採用される所期のＦＥＣ方式又はコードにより規定される。従って、実際のＦＥＣコーデック又はアルゴリズム、並びに／あるいは要求されるＦＥＣ保護オーバヘッドは、メディアファイル分割及びメディアブロックサイズに影響を与える可能性がある。
【００３６】
入力メディアソースファイルがＦＥＣコーデックにより効果的に処理される最大サイズより小さなサイズのビットサイズ又は記号サイズを有する場合、ソースファイルのメディアソースブロックへの分割は当然必要とされず、ステップＳ１１は省略される。入力メディアソースファイルは、本発明に係るメディアソースブロックとして考えられる。
【００３７】
尚、好適なブロックサイズがあるが、メディアソースファイルから生成される全てのメディアソースブロックがその好適なサイズである必要はない。例えば、メディアファイルの残りの部分が好適なブロックサイズに達する程の十分なメディアデータを含まないために、最後のメディアソースブロックは、他の同一サイズのブロックと比較して小さなサイズであってもよい。
【００３８】
この分割ステップＳ１１は、メディアソースファイルがコンテナファイルの別個の場所に格納される別個のメディアソースブロックに物理的に分割されることを必ずしも示さない。それとは非常に対照的に、殆どの実際的な実現例においては、メディアソースファイルは１つの連続したデータシーケンスとしてコンテナファイルに格納されるが、複数のメディアソースブロックとして考えられるか又は実質的にメディアソースブロックに分割される。例えば、ソース記号[0, N-1]が第１のソースブロックに属し、記号[N, 2N-1]が第２のソースブロックに属するように、２Ｎ個のソース記号を含むメディアソースファイルが分割される。
【００３９】
次のステップＳ１２において、特定のメディアソースファイル分割の情報が提供される。この情報は、メディアデータパケットストリームを提供し且つ／又はＦＥＣデータを計算する場合、メディアサーバに対する関連性の情報である。
【００４０】
方法は図１のステップＳ２に継続し、メディアソースブロックがメディアソースブロックに区分される。
【００４１】
図３は、図１のコンテナファイル生成方法の追加のステップを示すフローチャートである。方法は、図１のステップ５から継続する。次のステップＳ２０において、ブロック区分が計算される際に基づく方式のＦＥＣアルゴリズムの情報が提供される。この情報は、特定のアルゴリズムの名前又は他の記述情報の形式である。別の方法において、利用可能な各ＦＥＣアルゴリズムは事前定義済み識別子を有する。従って、このＦＥＣ識別子のみがステップＳ２０において提供されてもよい。一般的な実現例において、単一のＦＥＣコーデックの情報が、メディアソースファイルの全てのメディアソースブロックを区分するのに採用された。しかし、所定のメディアソースファイルの種々のメディアソースブロック又は種々のソースファイルのメディアソースブロックに対して区分を行なう際に種々のＦＥＣコーデック情報を使用することが実際に可能である。従って、ＦＥＣ情報は、単一のＦＥＣコーデックによるＦＥＣ記号の計算を可能にするため、あるいは種々のＦＥＣコーデックが使用されたソースブロック又はソースブロックのグループを識別するためにコンテナファイルの全てのブロックが区分されたことを特定できる。この状況において、種々の潜在的な対象ＦＥＣコーデック及び／又はＦＥＣオーバヘッドに基づいて所定のソースブロックを実際に区分できる。そのような場合、ステップＳ２０において、それら種々のＦＥＣコーデックの情報が提供されるのが好ましい。
【００４２】
次のステップＳ２１において、プロパティテーブルが提供されるのが好ましい。このプロパティテーブルは、２つ以上のメディアソースファイル／ストリームがコンテナファイルに含まれる場合に特に有用であるが、単一のメディアソースファイルを含む時にも有利に使用される。通常、ファイルプロパティテーブルは、好ましくはメディアの多目的インターネットメール拡張仕様（ＭＩＭＥ）タイプであるメディアソースファイルのメディアタイプの情報を含む。従って、このＭＩＭＥ情報は、メディアが同期マルチメディア統合言語（ＳＭＩＬ）を含む音声メディア、映像メディア又は他のメディアタイプであることを特定できる。このＭＩＭＥタイプは、コンテナファイルに実際に含まれるデータタイプの情報をメディアサーバに提供する。プロパティテーブルは、gzipを含むメディアデータに対して採用される任意の符号化方式の情報を更に含むことができる。また、サイズ情報がプロパティテーブルに含まれる。このサイズ情報は、バイト数又は記号数に関する各メディアソースファイルの合計サイズ、ソースファイルのメディアソースブロックの各サイズ（基本的に、図２のステップＳ１２で提供される分割情報に対応する）、データを送信する際に使用されるデータパケットに対する最大ペイロードサイズ又は対象ペイロードサイズ、メディアソース記号のサイズ（バイト）（基本的に、図１のステップＳ３で生成される区分情報に対応する）及び／又はＦＥＣ記号等を指定できる。ファイル名又はファイル識別子は、コンテナファイルに含まれる各メディアソースファイルに対するプロパティテーブルに含まれるのが好ましい。
【００４３】
コンテナファイルの各メディアソースファイルの実際の記憶場所の情報は、プロパティテーブルにおいて見つけられるのが好ましい。この場所情報は、ソースファイルの第１のメディアソースブロックの開始位置を特定でき、残りのメディアブロックはコンテナファイルのその位置以降に見つけられる。図１のステップＳ５で生成され、コンテナファイルの区分情報とメディアソースブロックとの関係を提供するメタデータは、プロパティテーブルに更に含まれる。同様に、採用されるブロック区分の情報及び冗長データ計算用のＦＥＣコーデックは、テーブルに含まれるのが好ましい。
【００４４】
従って、コンテナファイルのプロパティテーブルは、メディアソースに対する単一の情報ソースとして使用され、メディアセッション中のメディアパケットのコンパイルにおいて有用な関連するメディアソースファイル／ブロック及び他の情報の位置を特定する。
【００４５】
ＦＥＣ計算命令は、次のステップＳ２２において生成される。それら命令は、ソースブロックの区分データ及びメタデータに基づいてメディアソースブロックに対するＦＥＣデータを計算するためにメディアサーバにより使用される。従って、それら命令は、メディアセッション中にメディアコンテンツと共に使用されるＦＥＣ記号を生成して信頼性保護を提供するために、種々のソースブロックのメディアソース記号が好ましくはＦＥＣ情報に基づいて規定されるＦＥＣコーデックに入力される方法の命令を提供するヒント又はメタデータとして考えられる。命令は、少なくとも１つのメディアソースブロックに対するＦＥＣ記号のリザーバを計算するために区分情報及びメタデータ（区分情報の識別を可能にする）と共に使用されるのが好ましい。
【００４６】
好適な一実現例において、ＦＥＣ計算命令は、少なくとも１つのメディアソースブロックに対するＦＥＣ冗長記号のセットの計算を規定する。このＦＥＣ記号のセットは、メディアソースブロックのソース記号に基づいて計算された１つのＦＥＣ記号、好ましくは複数のＦＥＣ記号を含むことができる。
【００４７】
ＦＥＣ計算命令は、所定のメディアソースブロックに対する複数の別の命令を含むことができる。例えば、第１のＦＥＣコーデックがＦＥＣアルゴリズム情報に基づいて判定されるようにＦＥＣデータ計算に使用される場合、第１の別のＦＥＣ命令が採用される。同様に、第２の別のＦＥＣ命令は、第２のＦＥＣコーデックによるＦＥＣデータの計算を規定する。あるいは又はそれに加えて、別のＦＥＣ命令は種々のＦＥＣオーバヘッドに適応され、それにより許容される最大（又は最小）のＦＥＣオーバヘッドに依存して異なる数のＦＥＣ記号の計算を基本的に特定できる。
【００４８】
次のステップＳ２３は、メディアサーバにより使用されるコンパイル命令を生成する。それら命令は、データパケットのメディアストリームを形成するために、ＦＥＣ計算命令に基づいて計算されたＦＥＣ冗長データ及びメディアソースブロックのメディアデータのコンパイルを規定するのに使用される。従って、それら命令は、信頼性保護を有する送信可能なメディアパケットストリームを構成するためにコンテナファイルに含まれ、それから計算されるデータを使用する方法に関する命令を提供するヒント又はメタデータとして考えられる。それら命令は、メディアセッション中に要求クライアントに送信するのに適切なパケットにメディアデータ及びＦＥＣデータをコンパイルするために使用される。従って、命令はメディアソースデータ及びＦＥＣデータのサーバ側の送信順を記述する。しかし、通常、命令はタイムスケジュール情報、対象／ソースアドレス又はポートの情報、あるいは他のセッション特有の情報を含まない。これは、コンテナファイル及びその中のコンパイル命令は特定のセッションに透過的であり、種々の受信クライアントとの複数の種々のセッションに対する１つのメディアサーバだけでなく、種々のメディアサーバによっても実際に使用される。
【００４９】
コンパイル命令はメディアソースブロックのサブセットに適用でき、それは、そのような複数の命令がセッション中にメディアサーバにより読み出されて使用される必要があることを示す。あるいは、コンパイル命令は、単一のメディアソースファイル又は実際にはコンテナファイルの全てのメディアソースファイルに必要とされる全ての情報を含む。
【００５０】
ステップＳ２３において、コンパイル命令の２つ以上のセットが実際に生成されてもよい。そのような場合、種々の別の命令が提供されるため、メディアサーバは特定のメディアセッションに採用する特定の命令セットを判定する選択肢を有する。例えば、データ送信のために単一の送信チャネルを採用する場合、第１のコンパイル命令はメディアソースブロック及びＦＥＣデータの送信順を記述するのに使用される。第２の命令は、同一のメディアソースブロック及びＦＥＣデータに適用されるが、複数のチャネルが利用可能な場合にはコンパイル／送信順情報を提供し、これは、データが順次送信されるのではなく並列的に送信されることを示す。従って、いくつかのコンパイル命令は、種々の転送チャネル状態用の別の送信セッションを提供するために使用される。
【００５１】
同様に、別のコンパイル命令は、種々の信頼性保護オーバヘッドのために含まれる。例えば、第１のコンパイル命令は第１の最大保護オーバヘッドレベルに対するメディアソースブロック及びＦＥＣデータのコンパイル／送信順を記述するのに使用され、第２の命令は第２の異なるＦＥＣオーバヘッドレベルの同一のメディアソースブロックに対して使用される。この第２のＦＥＣオーバヘッドレベルが第１のレベルより高い（低い）場合、従来技術においても示されるようなより多くのＦＥＣ記号又はパリティ記号が所定の量のメディアソース記号に追加される。
【００５２】
次のステップＳ２４は、先のステップＳ２０〜ステップＳ２３及び好ましくは図２のステップＳ１２において提供及び生成される情報、テーブル及び命令をコンテナファイルに編成する。コンテナファイルは、要求クライアントへの送信のためにデータを識別、計算及び構成するために、メディアサーバにより必要とされる「生」メディアデータ、情報、命令及びメタデータの完全なセットを含む。その後、方法は終了する。
【００５３】
図４は、本発明に係るメディアコンテナファイル１を示す概略図である。上述したように、コンテナファイル１は、複数のメディアソースファイル１０、１２、１４のメタデータを含み、そのようなＭ個のファイルを図示する。ここで、Ｍ≧１である。各ファイル１０、１２、１４のメディアデータは、複数のメディアソースブロック２０、２２、２４に分割されると考えられる。図中では、そのようなＱ1個のブロック２０、２２、２４は、第１のメディアソースファイル１０に対して示されている。ここでＱ1≧１である。そのような各メディアソースブロック２０、２２、２４は、ソース記号に分割されると考えられる。
【００５４】
コンテナファイル１は、メディアデータを含むメディアソースブロック２０、２２、２４に加え、信頼性保護を提供するためにメディアデータと関連して使用されるＦＥＣ冗長データの計算を簡単化する目的でメディアソースブロック２０、２２、２４に適用されたソース記号区分の事前に生成された情報を含む区分情報セット３０、３２、３４を含む。好適な一実現例において、各メディアソースブロックは、専用の区分情報セット３０、３２、３４を含む。そのような場合、図中の情報セット３０、３２、３４の数Ｎは、
である。
【００５５】
区分情報３０、３２、３４が適用可能なメディアソースブロック２０、２２、２４と区分情報３０、３２、３４との関係を提供する本発明の関係メタデータ４０は、コンテナファイル１に更に提供される。図４は、ファイル１におけるメタデータ４０の複数の異なる可能な場所を示す。第１の実施形態において、メタデータは関連するメディアソースブロック２０、２２、２４と関連して格納される。従って、ファイル中のメディアソースブロック２０、２２、２４の識別により、ソースブロック２０、２２、２４の各メタデータ４０の識別も可能になる。あるいは又はそれに加えて、メタデータ４０は各区分情報３０、３２、３４と共に格納される。各情報セット３０、３２、３４は、特定の区分情報３０、３２、３４が適用される関連するメディアソースブロック２０、２２、２４の識別を可能にする結び付けられた関係メタデータ４０を有する。コンテナファイル１が好適なファイルプロパティテーブル６０を含む場合、関係メタデータ４０はそのテーブルに提供される。そのような場合、メディアサーバは、ファイルプロパティテーブル６０のみを調査して、メディアセッション中に使用する関連するメディアデータ及び区分データの場所を識別してもよい。更なる可能な一実現例において、関係メタデータ４０は、コンテナファイル１の種々のヒントトラック５０、５２、５４と関連して格納される。それらヒントトラックは、メディアセッションと関連してメディアサーバにより使用されるＦＥＣ計算及び／又はコンパイル命令を含む。そのような場合、各ヒントトラック５０、５２、５４は、そのヒントトラック５０、５２、５４の命令により実現可能なメディアセッションに必要とされるメタデータ４０のみを含む必要がある。それら複数の可能な記憶場所の組合せが更に可能であり、本発明の範囲内である。
【００５６】
本発明の特定の一実施形態によると、メディアコンテナファイル１は、インタリーブユニットであり、漸進的なダウンロード又はストリーミングに対して最適化される。それにより、マルチメディア表現全体は、いわゆる漸進的なダウンロード又はストリーミングにより要求クライアントに送信及びダウンロードされる。
【００５７】
ＩＳＯに基づくメディアファイル形式［１］［２］［３］は、本発明のメディアコンテナファイルのファイル形式として採用されるのが有利である。別のコンテナファイル形式は、ＭＰ４ファイル形式、３ＧＰファイル形式及びＱｕｉｃｋＴｉｍｅ形式を含む。
【００５８】
ＡＬＣ（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」）により提供される。
【００６７】
（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;
}
これは、メディアソース区分を規定する１つのボックスを含むことができる。
【００６９】
（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は、最後のソース記号がファイル項目に格納されていないパディングを含むことを示す。
【００７９】
（項目情報ボックス）
ブロードキャスト／マルチキャストファイルダウンロードプロトコル（ＡＬＣ／ＦＬＵＴＥ）を使用して内部に埋め込まれた個別のメディアを送信するために、サーバはその個別のメディアに対応するメタデータを更に送信するのが好ましい。メタデータは、ＦＬＵＴＥがブロードキャストプロトコルとして使用される場合はＦＤＴの一部として送出され、ＡＬＣがＯＭＡのＢＣＡＳＴのＥＳＧと共に使用される場合はＯＭＡのＢＣＡＳＴのＥＳＧの一部として送出される。
【００８０】
メタデータ情報の一部は実行中に作成されてもよいため、ＦＬＵＴＥ及びＡＬＣの双方に共通で固定のメタデータの一部に対するテンプレート構造は、項目情報エントリの第２のバージョンとして規定される。項目情報エントリのこのバージョンは、ソースファイル区分を有する項目に対する項目情報ボックスにおいて使用される。
【００８１】
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[];
}
図５は、本発明に係るメディアセッション管理方法を示すフローチャートである。このメディアセッション管理は、ストリーミングサーバ又はダウンロードサーバ等のメディアサーバにおいて実行され、本発明のメディアコンテナファイルを使用する。方法は、メディアコンテナファイルが提供されるステップＳ３０において開始する。このファイルの提供は、メディアサーバの記憶場所からコンテナファイルを取り出すことにより実現されるが、これは、サーバがコンテンツ提供器又は作成器からファイルを事前に受信していることを示す。あるいは、メディアサーバは、メディアデータに対する要求と関連してコンテンツ提供器からのコンテナファイルを命令又は受信できる。
【０１２３】
次のステップＳ３１において、ＦＥＣ冗長データは、少なくとも１つのメディアソースブロックを使用し、少なくとも１つのソースブロックと関連付けられる区分情報及びメタデータに基づいて計算される。この計算ステップＳ３１において、Digital FountainのRaptorコーデック等のＦＥＣブロックコーデックが採用されるのが好ましく、それはメディアブロック毎に動作する。しかし、重畳ＦＥＣコーデックが採用されてもよく、それは本発明の範囲内である。好適な一実現例において、ＦＥＣ冗長記号のセットは、少なくとも１つのメディアソースブロックに対して生成されてもよい。このＦＥＣ記号セットは、メディアソースブロックのソース記号に基づいて計算された１つのＦＥＣ記号、好ましくは複数のＦＥＣ記号を含むことができる。メディアソースブロックに対して計算するＦＥＣ記号の数は、採用されるＦＥＣコーデックの制限によって規定されるか、メディアソースブロックのメディアソース記号の数の関数であるか、あるいはＦＥＣオーバヘッド等の他の基準により制限されてもよい。更に、メディアコンテナファイルに含まれる情報は、計算するＦＥＣ冗長データの量を特定できる。
【０１２４】
好適な一実現例において、メディアコンテナファイルは、このステップＳ３１において使用されるＦＥＣ計算命令を更に含む。ＦＥＣ記号の生成のためにＦＥＣコーデックに入力されるソース記号を選択する時に、それら命令は区分情報（及び区分情報を識別するのに使用されるメタ情報）と共に使用される。
【０１２５】
コンテナファイルがメディアソースファイルのメディアソースブロックへの分割の情報を更に含む場合、この分割情報は、ＦＥＣデータ計算に使用される適正なソース記号を識別するために使用される。
【０１２６】
ステップＳ３１で計算されるＦＥＣ記号の数は、メディアセッション中のその時点で許容される最大／最小のＦＥＣオーバヘッド等のローカル基準に基づいてメディアサーバにより判定される。あるいは、上述のように、ＦＥＣ計算命令等のコンテナファイルに提供される情報は、所定のメディアソースブロックに対して計算されるＦＥＣ冗長データの量を特定する。
【０１２７】
ステップＳ３１のＦＥＣデータの計算は、進行中のメディアセッション中リアルタイムで実行される。あるいは、メディアサーバは、実際のセッションの前にＦＥＣデータのリザーバを生成し、ＦＥＣリザーバをコンテナファイル又はメモリに格納できる。事前に計算されたＦＥＣデータは、後続のメディアセッションにおいてコンテナファイルのメディアコンテンツと共に使用される。
【０１２８】
次のステップＳ３２において、メディアデータパケットは、コンテナファイルのメディアソースブロックからメディアデータを抽出し、ステップＳ３１で計算されるようなＦＥＣ冗長データを提供することによりコンパイルされる。メディアサーバは、メディアセッション中に送信するためにメディアデータの識別子を受信するのが好ましい。あるいは、コンテナファイルは、メディアソースの選択が必要ないように単一のメディアデータファイルのメディアデータのみを含んでもよい。いずれの場合においても、ファイルプロパティテーブル等のコンテナファイルに含まれる上述の情報は、メディアファイルの開始、すなわち送信が開始されるべき第１のメディアソースブロックを識別するために使用される。更に、コンテナファイルに含まれる更なる情報は、メディアデータ及びＦＥＣデータを組み合わせて、種々のクライアントに対する１つの無線チャネル又は複数のチャネルを介する無線送信に適応されたデータパケットに含める方法に関する命令として使用される。
【０１２９】
次のステップＳ３３において、ＦＥＣ信頼性保護を有するコンパイルされたメディアデータパケットは、好ましくはブロードキャスト又はマルチキャスト技術によりクライアントに送信され、クライアントにおいてメディアデータがレンダリングされる。メディアサーバの送信バッファが所定のレベルに到達すると、通常、パケット送信は開始される。しかし、メディアセッション中、他のパケットが送信される間、新しいデータパケットがコンパイルされて送信バッファに入力される。これを線Ｌ２により概略的に示す。
【０１３０】
メディアデータの編成及び生成されたコンテナファイル、並びに事前に計算された区分データの提供により、メディアセッション中のメディアサーバの処理要求が低減される。従って、これにより、サーバが実行中にソースブロック構成及び区分を実行する必要がないため、サーバの複雑さが軽減され、サーバに柔軟性が与えられる。
【０１３１】
その後、方法は終了する。
【０１３２】
図６は、図５のメディアセッション管理方法の追加のステップを示すフローチャートである。方法は、図５のステップＳ３０から継続する。次のステップＳ４０において、メディアサーバは、ＦＥＣデータ計算のために採用するＦＥＣアルゴリズム又はコーデックを選択する。このＦＥＣアルゴリズムは、ＦＥＣデータが計算される際に基づくメディアソースブロックを区分する時に使用されるＦＥＣアルゴリズムであるのが好ましい。従って、メディアコンテナファイルはこのＦＥＣアルゴリズム／コーデックの情報を含むの好ましく、これは選択ステップＳ４０においてメディアサーバにより採用される情報である。
【０１３３】
ＦＥＣ情報が複数の利用可能なＦＥＣアルゴリズムの識別子を含み、所定のメディアソースブロックが複数の種々の区分において利用可能である場合、メディアサーバは、ＦＥＣデータを計算する時に使用するＦＥＣアルゴリズム及びブロック区分情報を選択するために、ＦＥＣオーバヘッド容量及び／又はＦＥＣ計算命令を含む他の入力情報を使用するのが好ましい。
【０１３４】
その後、方法は図５のステップＳ３１に継続し、選択されたＦＥＣアルゴリズムはＦＥＣデータを計算するために使用される。
【０１３５】
図７は、図４のセッション管理方法の追加のステップを示すフローチャートである。方法は、図５のステップＳ３１から継続する。次のステップＳ５０において、メディアセッションにおいてデータを送信するために現在採用できるＦＥＣオーバヘッド容量が判定される。この容量は、メディア送信のためにサーバに割り当て可能な帯域幅レベル、このメディア送信のために採用される無線記憶媒体に対する最小及び最大のビットレートレベル等に基づいて判定又は少なくとも推定される。実際には、従来技術において周知のデータ送信と関連してそのようなオーバヘッド容量を判定する任意の技術が、ステップＳ５０において採用されてもよい。
【０１３６】
ＦＥＣオーバヘッド容量が判定されると、次のステップＳ５１は、判定されたオーバヘッド容量に基づいてコンパイル命令セットを選択する。メディアコンテナファイルは、所定のメディアコンテンツに使用されるコンパイル命令の複数の別のセットを含むが、種々のレベルのＦＥＣオーバヘッドを提供する。換言すると、基本的にそれら別のコンパイル命令は、メディアデータパケットをコンパイルする時にメディアデータに追加するＦＥＣ冗長データの量を規定する。許容されるＦＥＣオーバヘッドが大きくなると、より多くのＦＥＣデータが追加される。種々の別のコンパイル命令を有することにより、メディアサーバは、現在のオーバヘッドの制限を与えられる許容される最大のＦＥＣ保護を可能にするそれら命令を使用でき、それにより、単一のコンパイル命令のセットを使用する場合と比較して種々のクライアントでメディアデータを正常に受信及び復号化する機会が増加する。
【０１３７】
方法は、図５のステップＳ３２に継続する。ステップＳ３２において、メディアデータパケットは、ステップＳ５１で選択されたコンパイル命令に基づいてメディアコンテンツデータ及び関連するＦＥＣデータからコンパイルされる。
【０１３８】
メディアコンテナファイルがファイルからブロックへの分割の情報、ＦＥＣアルゴリズムの情報及び／又はファイルプロパティテーブル等の追加の情報を更に含む場合、メディアサーバは、データパケットの生成及び送信の際にその追加の情報を使用できる。
【０１３９】
例えば、メディアサーバにとって有用な追加のデータ、好ましくはＭＩＭＥタイプの情報、任意の符号化情報、サイズ情報等は、ファイルプロパティテーブルに含まれるか又は少なくとも公表される。好適な一実現例において、このプロパティテーブルは、メディアの抽出、データパケットのコンパイル及び送信と関連して有利な又は必要とされる情報を取得するためにメディアサーバによりアクセスされる単一情報又はルックアップソースを構成する。
【０１４０】
図８は、本発明の一実施形態に従って別のコンパイル命令の使用を示すために使用される本発明に係るメディアコンテナファイル１を示す概略図である。コンテナファイル１は、好ましくは複数のメディアソースブロックを含むメディアソースファイル１０を含む。本実施形態において、ソースファイル１０の各メディアソースブロックは関連する区分情報３０を有する。この図示される例において、コンテナファイル１は、種々のＦＥＣオーバヘッドのコンパイル命令を含む３つのヒントトラック５０、５２、５４を更に含む。例えば、１０％の冗長オーバヘッドが望ましい場合に第１のヒントトラック５０が使用され、第２のヒントトラック５２は約１２％のＦＥＣオーバヘッドを与え、第３のヒントトラック５４は１４％のＦＥＣオーバヘッドを与える。図中、文献［５］の付録Ｂにおいて提案されるソースブロック構成アルゴリズムが採用されている。
【０１４１】
区分情報３０は、ソースファイル１０のメディアソースブロックに基づいてＦＥＣデータ７０を計算するためにＦＥＣコーデックにより採用される。ソースファイル１０が複数のメディアソースブロックを含む場合、複数のＦＥＣデータセット又はリザーバ７０、すなわち好ましくはメディアソースブロック毎にＦＥＣデータの１つのセットが計算される。
【０１４２】
第１のヒントトラック５０が選択される場合、データパケット８１、８２、８３、８４の第１のストリーム（図中、メディアソースブロック毎及びＦＥＣブロック毎に１つのデータパケットのみが示される）が生成される。しかし、第２のヒントトラック５２が使用される場合、データパケット９１、９２、９３、９４の第２のストリームが生成される。第１のストリーム８０と比較して、第２のストリーム９０はメディアソースブロック毎により大きなＦＥＣブロック、すなわちより多くのＦＥＣ冗長データを含む。しかし、各ソースブロックは２つのストリーム８０、９０に同一量のメディアデータを含む。
【０１４３】
図９は、本発明のメディアコンテナファイル１を生成又は使用する要素を示す通信ネットワークの概略図である。コンテンツサーバ１００は、メディアソースデータを受信するか又はメディアソースデータへのアクセス権を有し、メディアコンテナファイル１を構成するコンテンツ提供器又は作成器を表す。このコンテナファイル１のコピーは、図において移動端末により表される種々のクライアント３００、３１０、３２０に送信（マルチキャスト）されるＦＥＣデータ及びメディアを含むデータパケットをコンパイルするためにメディアセッションにおいてコンテナファイル１を使用するメディアサーバ２００に送出される。
【０１４４】
図１０は、本発明に係るメディアコンテンツサーバ１００を示す概略ブロック図である。コンテンツサーバ１００は、外部ユニットと通信するための機能性（送信機／受信機、変調器／復調器、符号器／復号器）を含むように構成される一般的な入出力（Ｉ／Ｏ）ユニット１１０を具備する。このＩ／Ｏユニット１１０は、特に入力メディアコンテンツを受信及びメディアコンテナファイルに対する要求を受信するように構成される。Ｉ／Ｏユニット１１０は、通信ネットワークにおいてそのようなコンテナファイルを他のサーバに送信する時にサーバ１００により採用される。
【０１４５】
コンテンツサーバ１００は、本発明のメディアコンテナファイルを作成するように構成されるコンテナファイル作成器１６０を更に具備する。サーバ１００は、ファイル作成器１６０のメディアブロックマネージャ１６１によりメディアコンテナファイルに入力される少なくとも１つのメディアソースブロックを提供するように構成されるメディアブロック提供器１３０を更に具備する。メディアブロック提供器１３０は、外部メディアソース４００、４１０からメディアコンテンツを受信するＩ／Ｏユニット１１０又は内部データ記憶装置１２０から少なくとも１つの入力ソースブロックを提供する。
【０１４６】
メディアソースブロックは、コンテンツサーバ１００のブロック区分器１４０に転送される。この区分器１４０は、ＦＥＣデータを計算する目的でソースブロックに適用されるＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、入力メディアソースブロックを通常は複数のそのようなソース記号である多数のソース記号に区分する。区分動作は、ソースブロックをソース記号に物理的に分割する必要があるとは限らない。それとは非常に対照的に、区分は、ソースブロックの種々の部分を種々のソース記号に割り当てることによる実質的な分割であってもよい。
【０１４７】
ソースブロックに適用され、ブロック区分に影響を与えるＦＥＣアルゴリズムは、メディアソースブロックに対して常に採用される事前定義済みの標準ＦＥＣアルゴリズムであってもよい。あるいは、コンテンツサーバ１００のブロック区分器１４０又は他のユニットは、複数の利用可能なそのようなアルゴリズムから使用する特定のＦＥＣアルゴリズムを選択する。この選択において、予想される最大のＦＥＣオーバヘッド等の種々の入力データが使用される。更なる一実施形態において、ブロック区分器１４０は、種々の別の利用可能なＦＥＣアルゴリズムの情報に基づいて所定のメディアソースブロックの複数の別の区分を実行する。例えば、コンテンツサーバ１００がメディアサーバにおいて利用可能なＦＥＣアルゴリズムに関する知識を有する場合、ブロック区分器１４０は、ＦＥＣアルゴリズム毎に別個のブロック区分を実行できる。
【０１４８】
ブロック区分器１４０は、メディアソースブロックに適用される特定のＦＥＣアルゴリズム又は方式に基づいてブロック区分を実行することに加え、メディアセッション中にメディアサーバにより採用されるデータパケットにソース記号を収めるように適応された区分を実行するように更に動作可能である。従って、ＵＤＰパケットサイズ等のパケットサイズの情報は、区分器１４０により採用可能である。
【０１４９】
区分器１４０により実行される特定のソースブロック区分の情報は、情報生成器１５０により生成される。上述したように、この情報は、メディアソースブロックのどのビットがどのソース記号に属するかを特定できるか、あるいはより小さいサイズのソース記号である最後のソース記号を除いて、ソースブロックの全てのソース記号に適用される記号サイズを規定できる。
【０１５０】
この場合、ブロック区分器１４０はメディアソースブロックの複数の別の区分を実行し、生成器１５０により生成される情報はそれら別のブロック区分に関するデータを含む。
【０１５１】
区分情報は、情報をメディアコンテナファイルに挿入するコンテナファイル作成器１６０の情報マネージャ１６２に生成器から転送される。
【０１５２】
ファイル作成器１６０のメタデータマネージャ１６３は、メタデータをコンテナファイルに提供する。このメタデータは、ブロックマネージャ１６１により編成されるメディアソースブロックと区分情報マネージャ１６２により編成される区分情報との関係を提供する。
【０１５３】
結果として得られるメディアコンテナファイルは、データ記憶装置１２０に少なくとも一時的に格納されるか、あるいはＩ／Ｏユニット１１０によりメディアサーバに送信される。
【０１５４】
コンテンツサーバ１００のユニット１１０、１３０、１４０、１５０、１６０、１６１、１６２及び１６３は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１１０〜１６３が全て、通信システムの１つのネットワークノードのコンテンツサーバ１００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテンツサーバ１００の種々のユニット１１０〜１６３が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。
【０１５５】
図１１は、図１０のメディアブロック提供器１３０の一実施形態を更に詳細に示す概略ブロック図である。好適な一実現例において、入力メディアコンテンツは、例えばコンテンツサーバのデータ記憶装置又はＩ／Ｏユニットからメディアファイル提供器１３２により提供されるメディアソースファイルの形式である。メディアソースファイルは、ファイル提供器１３２によりメディアファイル分割器１３４に転送される。分割器１３４は、ソースファイルを１つ以上のソースブロックに分割する。分割器１３４は、このファイル分割を種々の情報又はパラメータに基づいて行なう。例えばファイル分割は、ＦＥＣ冗長データの計算に適用されるＦＥＣアルゴリズムに基づいて少なくとも部分的に判定される。そのような場合、ファイル分割１３４は、そのようなＦＥＣアルゴリズムの情報へのアクセス権を有するのが好ましい。分割器１３４は、メディアソースファイルをＮ−１個のサイズが等しいメディアソースブロック及びＮ−１個のブロックより小さなサイズを有する可能性のある１つのメディアソースブロックに分割できる。
【０１５６】
分割情報生成器１３６は、ファイル分割器１３４に接続されて構成される。生成器１３６は、ファイル分割器１３４により判定され、可能性として実行されるファイル分割の情報を生成する。第１の実現例において、生成された情報は、異なるメディアソースブロックに属するメディアソースファイルのビットを特定できる。第２の実現例において、情報は、可能性としてより小さなサイズを有する最後のソースブロックを除くメディアソースブロックのサイズ（ビット又は記号サイズ）を特定する。そのような場合、メディアソースファイルの開始場所を認識すると、種々のメディアソースブロックはその（サイズ）分割情報を使用して識別される。
【０１５７】
分割情報マネージャ１３８は、情報生成器１３６からの分割情報をメディアコンテナファイルに編成するためにブロック提供器１３０において実現される。
【０１５８】
メディアブロック提供器１３０のユニット１３２〜１３８は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１３２〜１３８が全て、メディアブロック提供器１３０において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、メディアブロック提供器１３０の種々のユニット１３２〜１３８がコンテンツサーバの他の場所に配置されてもよい。
【０１５９】
図１２は、図１０のコンテナファイル作成器１６０の一実施形態を更に詳細に示す概略ブロック図である。このファイル作成器１６０は、上述のメディアブロックマネージャ１６１、区分情報マネージャ１６２及びメタデータマネージャ１６３に加え、ＦＥＣ情報マネージャ１６４を含む。このＦＥＣ情報マネージャ１６４は、コンテナファイルのメディアソースブロックに適用されるＦＥＣアルゴリズムの情報を生成し、コンテナファイルに編成する。コンテンツサーバのブロック区分器により実行されるブロック区分は、ブロック区分を実行する時にもそのようなＦＥＣアルゴリズム情報を使用する。従って、ブロック区分が実行された時に基づいたＦＥＣアルゴイズムの情報は、マネージャ１６４により生成され、コンテナファイルに含まれるのが好ましい。
【０１６０】
テーブルマネージャ１６５は、プロパティテーブルを生成し、コンテナファイルに含めるためにファイル作成器１６０に含まれてもよい。このプロパティテーブルは、ファイルタイプ、ファイルサイズ、ファイル記憶場所、ファイル暗号化、ファイル名／識別子等のメディアソースファイルの情報をコンテナファイルに含むことができる。更に、本発明の区分情報、ファイル分割情報及びメタデータは、テーブルマネージャ１６５により生成されたプロパティテーブルに含まれる。
【０１６１】
ＦＥＣ命令マネージャ１６６は、コンテナファイルのメディアソースブロックに基づいてＦＥＣデータを生成する時にメディアサーバが従うＦＥＣ命令を生成するためにファイル作成器１６０に含まれる。それら命令は、特定のメディアソースブロックと関連付けられる区分情報と共に、ＦＥＣ記号を計算するためにＦＥＣコーデックに入力されるソース記号を特定する。種々の別のＦＥＣ命令がマネージャ１６６により所定のソースブロックに対して提供される。ここで、ＦＥＣ命令は異なるＦＥＣコーデック及び／又はＦＥＣオーバヘッドと関連して使用されるように適応される。
【０１６２】
ファイル作成器１６０のコンパイル命令マネージャ１６７は、コンパイル命令を生成し、コンテナファイルに挿入する。それら命令は、メディアソースブロックのメディアデータとソースブロック及び区分情報を使用して計算されるＦＥＣデータとをコンパイルするためにメディアサーバにより使用される情報を含む。マネージャ１６７は、ファイルのメディアコンテンツ毎に単一の命令又は命令のセットを生成できる。あるいは、種々のＦＥＣオーバヘッドに適応された種々のそのような命令、種々のＦＥＣデータタイプ及び／又はメディアセッションで採用される異なる数の無線通信チャネルがマネージャ１６７により提供され、コンテナファイルに編成される。
【０１６３】
コンテナファイル作成器１６０のユニット１６１〜１６７は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット１６１〜１６７が全て、コンテナファイル作成器１６０において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、コンテナファイル作成器１６０の種々のユニット１６１〜１６７がコンテンツサーバの他の場所に配置されてもよい。
【０１６４】
図１３は、本発明に係るメディアセッションサーバ２００を示す概略ブロック図である。このメディアサーバ２００は、外部ユニットとの通信を実行するＩ／Ｏユニット２１０を具備する。このＩ／Ｏユニット２１０は、特にコンテンツサーバからのメディアファイルコンテナを要求及び受信するように構成される。更にＩ／Ｏユニット２１０は、種々のユーザクライアントからのメディアコンテンツに対する要求又は少なくともメディアコンテンツが送信されるべきクライアントの情報に対する要求を受信する。メディアサーバ２００によりコンパイルされるデータパケットは、Ｉ／Ｏユニット２１０によりそれらクライアントに送信される。
【０１６５】
サーバ２００は、現在のセッションで使用するメディアコンテンツファイルを提供するメディアファイル提供器２２０を具備する。このファイル提供器２２０は、Ｉ／Ｏユニット２１０によりコンテンツ作成器に送信される特定のコンテナファイルに対する要求を生成してもよい。あるいは、提供器２２０は、メディアサーバ２２０に提供されたデータ記憶装置２５０から事前に受信したコンテナファイルを取り出す。
【０１６６】
メディアサーバ２００のＦＥＣ計算器又はコーデック２４０は、コンテナファイルに格納される少なくとも１つのメディアソースブロックに対するＦＥＣ冗長データを計算する。この計算手順において、ＦＥＣ計算器２４０は、上述のＦＥＣアルゴリズムのうち任意のアルゴリズムを使用できる。好適な一実現例において、コンテナファイルは、選択肢がある場合に採用するＦＥＣアルゴリズムを計算器２４０に指示する。まずＦＥＣ計算器２４０は、入力メディアソースブロックに対する関連する区分情報を識別する。この識別手順において、ソースブロックに関連付けられ、コンテナファイルに提供されるメタデータは、計算器２４０により使用される。その後、計算器２４０は、ＦＥＣデータを生成するためにＦＥＣアルゴリズム（コンテナファイルのＦＥＣ情報に基づいて選択される）が適用されるべきメディアソースブロックのそれら部分を識別するための区分情報を使用する。
【０１６７】
好適な一実施形態において、適正な入力ソース記号を識別し、実際のＦＥＣデータ計算を実行する場合、メディアコンテナファイルは、区分情報に加え計算器２４０により使用されるＦＥＣ計算命令を更に含む。更なる入力情報は、上述のＦＥＣアルゴリズム情報（使用する適正なＦＥＣアルゴリズムの選択を可能にする）及びファイル分割情報（適正なメディアソースブロックの識別を可能にする）であってもよい。
【０１６８】
データパケットコンパイラ２３０は、提供器２２０からのコンテナファイルに含まれるコンパイル命令を使用して、ファイルからメディアデータ及びＦＥＣ計算器からＦＥＣデータを抽出し、その抽出データを含むデータパケットを生成するのが好ましい。そのように生成されたデータパケットは、Ｉ／Ｏユニット２１０により送信される（Ｉ／Ｏユニット２１０からストリーム又はダウンロードされる）。
【０１６９】
種々のコンパイル命令は、所定のメディアコンテンツに対するファイルに含まれる。例えば、命令はチャネルに依存するか又は容量に依存する。前者の場合、利用可能な無線チャネルの数及び送信されるべき並列メディアストリームの数により、コンパイラ２３０が使用する実際のコンパイル命令が判定される。後者の場合、ＦＥＣ容量推定器２６０は、セッション中に採用されるＦＥＣオーバヘッドの最大量を推定するためにサーバ２００に含まれるのが好ましい。オーバヘッド容量がセッションにわたり変化するため、推定器２６０により実行されるオーバヘッドの推定はセッション中に動的に更新されるのが好ましい。セット選択器２７０は、使用するファイルにおいて利用可能な特定のコンパイル命令又はコンパイル命令の命令セットを選択するために推定器２６０からの容量推定値を使用する。パケットコンパイラ２３０は、メタデータ及びＦＥＣデータをデータパケットにコンパイルするためにこの命令（セット）を使用する。
【０１７０】
メディアサーバ２００のユニット２１０、２２０、２３０、２４０、２６０及び２７０は、ソフトウェア、ハードウェア又はそれらの組合せとして実現又は提供されてもよい。ユニット２１０〜２７０が全て、通信システムの１つのネットワークノードのメディアサーバ２００において実現されてもよい。あるいは、分散型実施形態も可能であり、本発明の範囲内である。そのような場合、メディアサーバ２００の種々のユニット２１０〜２７０が種々のネットワークノードに配置されてもよいが、上述したような意図された動作を実行する。
【０１７１】
添付の請求の範囲に規定される本発明の範囲から逸脱せずに、本発明に対して種々の変形及び変更が行なわれてもよいことが当業者には理解されるだろう。
【０１７２】
（参考文献）
［１］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、２００４年２月
［５］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、２００６年６月
［６］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、２００２年１２月
【特許請求の範囲】
【請求項１】
メディアコンテナファイルを生成する方法であって、
−メディアデータを含む少なくとも１つのメディアソースブロックを提供するステップと、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて、前記少なくとも１つのメディアソースブロックを複数のソース記号に区分するステップと、
−前記区分を記述する区分情報を生成するステップと、
−前記少なくとも１つのメディアソースブロックを前記メディアコンテナファイルに編成するステップと、
−前記区分情報を前記メディアコンテナファイルに編成するステップと、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを前記メディアコンテナファイルに提供するステップと、
を有することを特徴とする方法。
【請求項２】
前記少なくとも１つのメディアソースブロックを提供する前記ステップは、
−メディアソースファイルを提供するステップと、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するステップと、
−前記分割を記述する分割情報を生成するステップと、
−前記分割情報を前記メディアコンテナファイルに編成するステップと、
を有することを特徴とする請求項１記載の方法。
【請求項３】
前記分割ステップは、前記ＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割することを有することを特徴とする請求項２記載の方法。
【請求項４】
−前記ＦＥＣアルゴリズムの情報を前記メディアコンテナファイルに提供するステップを更に有することを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するステップを更に有することを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
−前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を生成するステップと、
−前記ＦＥＣ計算命令を前記メディアコンテナファイルに編成するステップと、
を更に有することを特徴とする請求項１から５のいずれか１項に記載の方法。
【請求項７】
−データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータと前記ＦＥＣ冗長データとのコンパイルを規定するコンパイル命令を生成するステップと、
−前記コンパイル命令を前記メディアコンテナファイルに編成するステップと、
を更に有することを特徴とする請求項６記載の方法。
【請求項８】
コンパイル命令を生成する前記ステップは、
−第１のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第１のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第１のセットを生成するステップと、
−第２のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第２のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第２のセットを生成するステップと、
を有することを特徴とする請求項７記載の方法。
【請求項９】
−メディアデータを含む少なくとも１つのメディアソースブロックを提供するように構成されるメディアブロック提供器と、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて、前記少なくとも１つのメディアソースブロックを複数のソース記号に区分するように構成されるメディアブロック区分器と、
−前記区分を記述する区分情報を生成するように構成される区分情報生成器と、
−前記少なくとも１つのメディアソースブロックを前記メディアコンテナファイルに編成するように構成されるメディアブロックマネージャと、
−前記区分情報を前記メディアコンテナファイルに編成するように構成される区分情報マネージャと、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを前記メディアコンテナファイルに提供するように構成されるメタデータマネージャと、
を備えることを特徴とするメディアコンテンツサーバ。
【請求項１０】
前記メディアブロック提供器は、
−メディアソースファイルを提供するように構成されるメディアファイル提供器と、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するように構成されるメディアファイル分割器と、
−前記分割を記述する分割情報を生成するように構成される分割情報生成器と、
−前記分割情報を前記メディアコンテナファイルに編成するように構成される分割情報マネージャと、
を備えることを特徴とする請求項９記載のメディアコンテンツサーバ。
【請求項１１】
前記メディアファイル分割器は、前記ＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するように構成される
ことを特徴とする請求項１０記載のメディアコンテンツサーバ。
【請求項１２】
−前記ＦＥＣアルゴリズムの情報を前記メディアコンテナファイルに提供するように構成されるＦＥＣ情報マネージャを更に備える
ことを特徴とする請求項９から１１のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１３】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するように構成されるテーブルマネージャを更に備える
ことを特徴とする請求項９から１２のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１４】
−ｉ）前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を生成し、ii）前記ＦＥＣ計算命令を前記メディアコンテナファイルに編成する
ように構成されるＦＥＣ命令マネージャを更に備えることを特徴とする請求項９から１３のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１５】
−ｉ）データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令を生成し、ii）前記コンパイル命令を前記メディアコンテナファイルに編成する
ように構成されるコンパイル命令マネージャを更に備えることを特徴とする請求項１４記載のメディアコンテンツサーバ。
【請求項１６】
前記コンパイル命令マネージャは、ｉ）第１のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第１のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第１のセットを生成し、ii）第２のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第２のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第２のセットを生成する
ように構成されることを特徴とする請求項１５記載のメディアコンテンツサーバ。
【請求項１７】
−少なくとも１つのメディアソースブロックと、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて実行される前記少なくとも１つのメディアソースブロックの複数のソース記号への区分を記述する区分情報と、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータと、
を含むことを特徴とするメディアコンテナファイル。
【請求項１８】
−メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含む
ことを特徴とする請求項１７記載のメディアコンテナファイル。
【請求項１９】
−前記ＦＥＣアルゴリズムの情報を更に含むことを特徴とする請求項１７又は１８記載のメディアコンテナファイル。
【請求項２０】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを更に含むことを特徴とする請求項１７から１９のいずれか１項に記載のメディアコンテナファイル。
【請求項２１】
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含むことを特徴とする請求項１７から２０のいずれか１項に記載のメディアコンテナファイル。
【請求項２２】
−データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令を更に含むことを特徴とする請求項２１記載のメディアコンテナファイル。
【請求項２３】
−少なくとも１つのメディアソースブロック、区分情報及び前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを含むメディアコンテナファイルを提供するステップと、
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいて順方向誤り訂正（ＦＥＣ）冗長データを計算するステップと、
−前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することによりデータパケットをコンパイルするステップと、
−メディアセッション中に前記データパケットを少なくとも１つのユーザ端末に送信するステップと、
を有することを特徴とするメディアセッション管理方法。
【請求項２４】
前記メディアコンテナファイルは、前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含み、前記計算ステップは、前記メタデータ、前記少なくとも１つのメディアソースブロック、前記区分情報及び前記ＦＥＣ計算命令に基づいて前記ＦＥＣ冗長データを計算することを有することを特徴とする請求項２３記載の方法。
【請求項２５】
前記メディアコンテナファイルは、メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含み、前記計算ステップは、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記分割情報と、に基づいて前記ＦＥＣ冗長データを計算することを含む
ことを特徴とする請求項２３又は２４記載の方法。
【請求項２６】
前記メディアコンテナファイルはＦＥＣアルゴリズム情報を更に含み、前記計算ステップは、
−前記ＦＥＣアルゴリズム情報に基づいて複数の利用可能なＦＥＣアルゴリズムからＦＥＣアルゴリズムを選択するステップと、
−前記選択したＦＥＣアルゴリズムを使用し、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づいて前記ＦＥＣ冗長データを計算するステップと
を有することを特徴とする請求項２３から２５のいずれか１項に記載の方法。
【請求項２７】
前記メディアコンテナファイルは、データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを記述するコンパイル命令を更に含み、前記コンパイルステップは、前記コンパイル命令に基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２３から２６のいずれか１項に記載の方法。
【請求項２８】
前記コンパイル命令は、各々が規定されたＦＥＣ冗長オーバヘッドと関連付けられる複数のコンパイル命令セットを含み、前記方法は、
−前記メディアセッションに対するＦＥＣ冗長オーバヘッド容量を推定するステップと、
−前記推定したＦＥＣ冗長オーバヘッド容量に基づいて前記複数のコンパイル命令セットからコンパイル命令セットを選択するステップとを含み、
前記コンパイルステップは、前記選択したコンパイル命令セットに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２７記載の方法。
【請求項２９】
前記メディアコンテナファイルは、前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶情報を含むプロパティテーブルを更に含み、前記コンパイルステップは、前記プロパティテーブルに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２３から２８のいずれか１項に記載の方法。
【請求項３０】
−少なくとも１つのメディアソースブロック、区分情報及び前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを含むメディアコンテナファイルを提供するためのメディアファイル提供器と、
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいて順方向誤り訂正（ＦＥＣ）冗長データを計算するように構成されるＦＥＣ計算器と、
−前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することによりデータパケットをコンパイルするために、前記メディアファイル提供器及び前記ＦＥＣ計算器に接続されて構成されるデータパケットコンパイラと、
−前記データパケットコンパイラによりコンパイルされた前記データパケットを少なくとも１つのユーザ端末にメディアセッション中に送信するために前記データパケットコンパイラに接続されて構成される送信機と、
を備えることを特徴とするメディアセッションサーバ。
【請求項３１】
前記メディアコンテナファイルは、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づく前記ＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含み、前記ＦＥＣ計算器は、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記ＦＥＣ計算命令とに基づいて前記ＦＥＣ冗長データを計算するように構成される
ことを特徴とする請求項３０記載のメディアセッションサーバ。
【請求項３２】
前記メディアコンテナファイルは、メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含み、前記ＦＥＣ計算器は、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記分割情報とに基づいて前記ＦＥＣ冗長データを計算するように構成される
ことを特徴とする請求項３０又は３１記載のメディアセッションサーバ。
【請求項３３】
前記メディアコンテナファイルはＦＥＣアルゴリズム情報を更に含み、前記ＦＥＣ計算器は、ｉ）前記ＦＥＣアルゴリズム情報に基づいて複数の利用可能なＦＥＣアルゴリズムからＦＥＣアルゴリズムを選択し、ii）前記選択したＦＥＣアルゴリズムを使用し、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づいて前記ＦＥＣ冗長データを計算する
ように構成されることを特徴とする請求項３０から３２のいずれか１項に記載のメディアセッションサーバ。
【請求項３４】
前記メディアコンテナファイルは、データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを記述するコンパイル命令を更に含み、前記データパケットコンパイラは、前記コンパイル命令に基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３０から３３のいずれか１項に記載のメディアセッションサーバ。
【請求項３５】
前記コンパイル命令は、各々が規定されたＦＥＣ冗長オーバヘッドと関連付けられる複数のコンパイル命令セットを含み、
前記メディアセッションサーバは、
−前記メディアセッションに対するＦＥＣ冗長オーバヘッド容量を推定するように構成されるＦＥＣ容量推定器と、
−前記ＦＥＣ容量推定器により推定した前記ＦＥＣ冗長オーバヘッド容量に基づいて前記複数のコンパイル命令セットからコンパイル命令セットを選択するために前記ＦＥＣ容量推定器に接続されて構成されるセット選択器と、
を更に備え、
前記データパケットコンパイラは、前記セット選択器により選択した前記コンパイル命令セットに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３４記載のメディアセッションサーバ。
【請求項３６】
前記メディアコンテナファイルは、前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶情報を含むプロパティテーブルを更に含み、前記データパケットコンパイラは、前記プロパティテーブルに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３０から３５のいずれか１項に記載のメディアセッションサーバ。
【請求項１】
メディアコンテナファイルを生成する方法であって、
−メディアデータを含む少なくとも１つのメディアソースブロックを提供するステップと、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて、前記少なくとも１つのメディアソースブロックを複数のソース記号に区分するステップと、
−前記区分を記述する区分情報を生成するステップと、
−前記少なくとも１つのメディアソースブロックを前記メディアコンテナファイルに編成するステップと、
−前記区分情報を前記メディアコンテナファイルに編成するステップと、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを前記メディアコンテナファイルに提供するステップと、
を有することを特徴とする方法。
【請求項２】
前記少なくとも１つのメディアソースブロックを提供する前記ステップは、
−メディアソースファイルを提供するステップと、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するステップと、
−前記分割を記述する分割情報を生成するステップと、
−前記分割情報を前記メディアコンテナファイルに編成するステップと、
を有することを特徴とする請求項１記載の方法。
【請求項３】
前記分割ステップは、前記ＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割することを有することを特徴とする請求項２記載の方法。
【請求項４】
−前記ＦＥＣアルゴリズムの情報を前記メディアコンテナファイルに提供するステップを更に有することを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するステップを更に有することを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
−前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を生成するステップと、
−前記ＦＥＣ計算命令を前記メディアコンテナファイルに編成するステップと、
を更に有することを特徴とする請求項１から５のいずれか１項に記載の方法。
【請求項７】
−データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータと前記ＦＥＣ冗長データとのコンパイルを規定するコンパイル命令を生成するステップと、
−前記コンパイル命令を前記メディアコンテナファイルに編成するステップと、
を更に有することを特徴とする請求項６記載の方法。
【請求項８】
コンパイル命令を生成する前記ステップは、
−第１のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第１のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第１のセットを生成するステップと、
−第２のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第２のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第２のセットを生成するステップと、
を有することを特徴とする請求項７記載の方法。
【請求項９】
−メディアデータを含む少なくとも１つのメディアソースブロックを提供するように構成されるメディアブロック提供器と、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて、前記少なくとも１つのメディアソースブロックを複数のソース記号に区分するように構成されるメディアブロック区分器と、
−前記区分を記述する区分情報を生成するように構成される区分情報生成器と、
−前記少なくとも１つのメディアソースブロックを前記メディアコンテナファイルに編成するように構成されるメディアブロックマネージャと、
−前記区分情報を前記メディアコンテナファイルに編成するように構成される区分情報マネージャと、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを前記メディアコンテナファイルに提供するように構成されるメタデータマネージャと、
を備えることを特徴とするメディアコンテンツサーバ。
【請求項１０】
前記メディアブロック提供器は、
−メディアソースファイルを提供するように構成されるメディアファイル提供器と、
−前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するように構成されるメディアファイル分割器と、
−前記分割を記述する分割情報を生成するように構成される分割情報生成器と、
−前記分割情報を前記メディアコンテナファイルに編成するように構成される分割情報マネージャと、
を備えることを特徴とする請求項９記載のメディアコンテンツサーバ。
【請求項１１】
前記メディアファイル分割器は、前記ＦＥＣアルゴリズムの情報に少なくとも部分的に基づいて、前記メディアソースファイルを前記少なくとも１つのメディアソースブロックに分割するように構成される
ことを特徴とする請求項１０記載のメディアコンテンツサーバ。
【請求項１２】
−前記ＦＥＣアルゴリズムの情報を前記メディアコンテナファイルに提供するように構成されるＦＥＣ情報マネージャを更に備える
ことを特徴とする請求項９から１１のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１３】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを前記メディアコンテナファイルに提供するように構成されるテーブルマネージャを更に備える
ことを特徴とする請求項９から１２のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１４】
−ｉ）前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を生成し、ii）前記ＦＥＣ計算命令を前記メディアコンテナファイルに編成する
ように構成されるＦＥＣ命令マネージャを更に備えることを特徴とする請求項９から１３のいずれか１項に記載のメディアコンテンツサーバ。
【請求項１５】
−ｉ）データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令を生成し、ii）前記コンパイル命令を前記メディアコンテナファイルに編成する
ように構成されるコンパイル命令マネージャを更に備えることを特徴とする請求項１４記載のメディアコンテンツサーバ。
【請求項１６】
前記コンパイル命令マネージャは、ｉ）第１のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第１のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第１のセットを生成し、ii）第２のレベルのＦＥＣ冗長オーバヘッドを有するデータパケットの第２のメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令の第２のセットを生成する
ように構成されることを特徴とする請求項１５記載のメディアコンテンツサーバ。
【請求項１７】
−少なくとも１つのメディアソースブロックと、
−前記少なくとも１つのメディアソースブロックに適用される順方向誤り訂正（ＦＥＣ）アルゴリズムの情報に少なくとも部分的に基づいて実行される前記少なくとも１つのメディアソースブロックの複数のソース記号への区分を記述する区分情報と、
−前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータと、
を含むことを特徴とするメディアコンテナファイル。
【請求項１８】
−メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含む
ことを特徴とする請求項１７記載のメディアコンテナファイル。
【請求項１９】
−前記ＦＥＣアルゴリズムの情報を更に含むことを特徴とする請求項１７又は１８記載のメディアコンテナファイル。
【請求項２０】
−前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶場所情報を含むプロパティテーブルを更に含むことを特徴とする請求項１７から１９のいずれか１項に記載のメディアコンテナファイル。
【請求項２１】
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含むことを特徴とする請求項１７から２０のいずれか１項に記載のメディアコンテナファイル。
【請求項２２】
−データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを規定するコンパイル命令を更に含むことを特徴とする請求項２１記載のメディアコンテナファイル。
【請求項２３】
−少なくとも１つのメディアソースブロック、区分情報及び前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを含むメディアコンテナファイルを提供するステップと、
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいて順方向誤り訂正（ＦＥＣ）冗長データを計算するステップと、
−前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することによりデータパケットをコンパイルするステップと、
−メディアセッション中に前記データパケットを少なくとも１つのユーザ端末に送信するステップと、
を有することを特徴とするメディアセッション管理方法。
【請求項２４】
前記メディアコンテナファイルは、前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づくＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含み、前記計算ステップは、前記メタデータ、前記少なくとも１つのメディアソースブロック、前記区分情報及び前記ＦＥＣ計算命令に基づいて前記ＦＥＣ冗長データを計算することを有することを特徴とする請求項２３記載の方法。
【請求項２５】
前記メディアコンテナファイルは、メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含み、前記計算ステップは、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記分割情報と、に基づいて前記ＦＥＣ冗長データを計算することを含む
ことを特徴とする請求項２３又は２４記載の方法。
【請求項２６】
前記メディアコンテナファイルはＦＥＣアルゴリズム情報を更に含み、前記計算ステップは、
−前記ＦＥＣアルゴリズム情報に基づいて複数の利用可能なＦＥＣアルゴリズムからＦＥＣアルゴリズムを選択するステップと、
−前記選択したＦＥＣアルゴリズムを使用し、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づいて前記ＦＥＣ冗長データを計算するステップと
を有することを特徴とする請求項２３から２５のいずれか１項に記載の方法。
【請求項２７】
前記メディアコンテナファイルは、データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを記述するコンパイル命令を更に含み、前記コンパイルステップは、前記コンパイル命令に基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２３から２６のいずれか１項に記載の方法。
【請求項２８】
前記コンパイル命令は、各々が規定されたＦＥＣ冗長オーバヘッドと関連付けられる複数のコンパイル命令セットを含み、前記方法は、
−前記メディアセッションに対するＦＥＣ冗長オーバヘッド容量を推定するステップと、
−前記推定したＦＥＣ冗長オーバヘッド容量に基づいて前記複数のコンパイル命令セットからコンパイル命令セットを選択するステップとを含み、
前記コンパイルステップは、前記選択したコンパイル命令セットに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２７記載の方法。
【請求項２９】
前記メディアコンテナファイルは、前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶情報を含むプロパティテーブルを更に含み、前記コンパイルステップは、前記プロパティテーブルに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルすることを含む
ことを特徴とする請求項２３から２８のいずれか１項に記載の方法。
【請求項３０】
−少なくとも１つのメディアソースブロック、区分情報及び前記少なくとも１つのメディアソースブロックと前記区分情報との関係を提供するメタデータを含むメディアコンテナファイルを提供するためのメディアファイル提供器と、
−前記メタデータ、前記少なくとも１つのメディアソースブロック及び前記区分情報に基づいて順方向誤り訂正（ＦＥＣ）冗長データを計算するように構成されるＦＥＣ計算器と、
−前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することによりデータパケットをコンパイルするために、前記メディアファイル提供器及び前記ＦＥＣ計算器に接続されて構成されるデータパケットコンパイラと、
−前記データパケットコンパイラによりコンパイルされた前記データパケットを少なくとも１つのユーザ端末にメディアセッション中に送信するために前記データパケットコンパイラに接続されて構成される送信機と、
を備えることを特徴とするメディアセッションサーバ。
【請求項３１】
前記メディアコンテナファイルは、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づく前記ＦＥＣ冗長データの計算を規定するＦＥＣ計算命令を更に含み、前記ＦＥＣ計算器は、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記ＦＥＣ計算命令とに基づいて前記ＦＥＣ冗長データを計算するように構成される
ことを特徴とする請求項３０記載のメディアセッションサーバ。
【請求項３２】
前記メディアコンテナファイルは、メディアソースファイルの前記少なくとも１つのメディアソースブロックへの分割を記述する分割情報を更に含み、前記ＦＥＣ計算器は、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報と、前記分割情報とに基づいて前記ＦＥＣ冗長データを計算するように構成される
ことを特徴とする請求項３０又は３１記載のメディアセッションサーバ。
【請求項３３】
前記メディアコンテナファイルはＦＥＣアルゴリズム情報を更に含み、前記ＦＥＣ計算器は、ｉ）前記ＦＥＣアルゴリズム情報に基づいて複数の利用可能なＦＥＣアルゴリズムからＦＥＣアルゴリズムを選択し、ii）前記選択したＦＥＣアルゴリズムを使用し、前記メタデータと、前記少なくとも１つのメディアソースブロックと、前記区分情報とに基づいて前記ＦＥＣ冗長データを計算する
ように構成されることを特徴とする請求項３０から３２のいずれか１項に記載のメディアセッションサーバ。
【請求項３４】
前記メディアコンテナファイルは、データパケットのメディアストリームを形成するために、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データのコンパイルを記述するコンパイル命令を更に含み、前記データパケットコンパイラは、前記コンパイル命令に基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３０から３３のいずれか１項に記載のメディアセッションサーバ。
【請求項３５】
前記コンパイル命令は、各々が規定されたＦＥＣ冗長オーバヘッドと関連付けられる複数のコンパイル命令セットを含み、
前記メディアセッションサーバは、
−前記メディアセッションに対するＦＥＣ冗長オーバヘッド容量を推定するように構成されるＦＥＣ容量推定器と、
−前記ＦＥＣ容量推定器により推定した前記ＦＥＣ冗長オーバヘッド容量に基づいて前記複数のコンパイル命令セットからコンパイル命令セットを選択するために前記ＦＥＣ容量推定器に接続されて構成されるセット選択器と、
を更に備え、
前記データパケットコンパイラは、前記セット選択器により選択した前記コンパイル命令セットに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３４記載のメディアセッションサーバ。
【請求項３６】
前記メディアコンテナファイルは、前記メディアコンテナファイル内の前記少なくとも１つのメディアソースブロックの記憶情報を含むプロパティテーブルを更に含み、前記データパケットコンパイラは、前記プロパティテーブルに基づいて、前記少なくとも１つのメディアソースブロックのメディアデータ及び前記ＦＥＣ冗長データを抽出することにより前記データパケットをコンパイルするように構成される
ことを特徴とする請求項３０から３５のいずれか１項に記載のメディアセッションサーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−１９９９７４（Ｐ２０１２−１９９９７４Ａ）
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−１１９０４９（Ｐ２０１２−１１９０４９）
【出願日】平成２４年５月２４日（２０１２．５．２４）
【分割の表示】特願２００８−５４９４５２（Ｐ２００８−５４９４５２）の分割
【原出願日】平成１９年１月４日（２００７．１．４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２４年１０月１８日（２０１２．１０．１８）
【国際特許分類】
【出願番号】特願２０１２−１１９０４９（Ｐ２０１２−１１９０４９）
【出願日】平成２４年５月２４日（２０１２．５．２４）
【分割の表示】特願２００８−５４９４５２（Ｐ２００８−５４９４５２）の分割
【原出願日】平成１９年１月４日（２００７．１．４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]