(57)【要約】本発明は、メタデータ及びメディアデータを含むマルチメディアファイルを作成する方法に関する。マルチメディアファイルは、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むように、作成される。
2005504480.tif 000002
【特許請求の範囲】
【請求項１】
メタデータ及びメディアデータを含むマルチメディアファイルを作成する方法であって、
そのファイルが、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むように、マルチメディアファイルを作成することを特徴とする方法。
【請求項２】
マルチメディアファイルをパージングする方法であって、
そのマルチメディアファイルは、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含み、
個別の各セグメントは、前記のファイルレベルのメタデータを利用して１つずつパージングされることを特徴とする方法。
【請求項３】
前記マルチメディアファイルは、ＴＣＰ（転送制御プロトコル）のような信頼性のある転送プロトコルを利用して、ストリーミングサーバからストリーミングクライアントへとプログレッシブにダウンロードされ、
前記クライアントは、パージング及び多重分離後にトラックを伸張し、非圧縮トラックを再生することを特徴とする請求項１及び２のいずれか一項に記載の方法。
【請求項４】
ストリーミング用のマルチメディアファイルを作成するように構成された第１の装置と、ストリーミングファイルを受信して該ストリーミングファイルを使用するように構成された第２の装置とを備えたマルチメディアストリーミングシステムにおいて、
前記第１の装置は、マルチメディアファイルが、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むように、該マルチメディアファイルを作成するようになっており、
当該システムは、前記マルチメディアファイルを前記第１の装置から前記第２の装置へと転送するようになっており、
前記第２の装置は、個別の各セグメントを、前記のファイルレベルのメタデータを利用して１つずつパージングするようになっていることを特徴とする装置。
【請求項５】
前記第１の装置は、前記マルチメディアファイルをストリーミングサーバへと送信するようになっており、
前記ストリーミングサーバは、前記マルチメディアファイルを前記第２の装置へと送信するようになっていることを特徴とする請求項４記載のシステム。
【請求項６】
マルチメディアファイルを作成する手段であって、そのファイルが、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むようにしたものを、備えたことを特徴とするデータ処理装置。
【請求項７】
マルチメディアファイルを受信する手段であって、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプルのメディアデータ及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むものと、
個別の各セグメントを、前記のファイルレベルのメタデータを利用して１つずつパージングする手段とを、備えたことを特徴とするデータ処理装置。
【請求項８】
当該装置は、前記マルチメディアファイルのプログレッシブ・ダウンローディングを提供するサーバ用のクライアント又はゲートウェイ装置であることを特徴とする請求項７記載のデータ処理装置。
【請求項９】
コンピュータ可読媒体内に格納されたコンピュータプログラムプロダクトであって、コンピュータ内で実行された場合、コンピュータに、請求項１記載のステップを実行させることを特徴とするコンピュータプログラムプロダクト。
【請求項１０】
コンピュータ可読媒体内に格納されたコンピュータプログラムプロダクトであって、コンピュータ内で実行された場合、コンピュータに、請求項２記載のステップを実行させることを特徴とするコンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアデータを処理する方法及び装置に関し、特に、ストリーミング用のマルチメディアファイルの構造に関する。
【背景技術】
【０００２】
ストリーミングとは、オーディオ及びビデオストリーム等の同期したメディアストリームを、それらのストリームがデータネットワークを介してクライアントへと送信されている間は連続して再生するアプリケーションの能力を意味する。マルチメディアストリーミングシステムは、ストリーミングサーバ、及びいくつものクライアント（プレイヤ）により構成される。クライアントは、接続媒体（ネットワーク接続でもよい）を介してサーバにアクセスする。クライアントは、予め格納されたコンテンツか、あるいは、生のコンテンツをサーバから取得して、コンテンツがダウンロードされている間、それを実質的にリアルタイムで再生する。マルチメディアのプレゼンテーション全体は、ムービーと称されてもよく、論理的に複数のトラックへと分割されうる。各トラックは、単一のメディア型のタイミングの取れたシーケンス（例えば一連のビデオフレーム）を表している。各トラック内にて、タイミングの取れた各ユニットが、メディアサンプルと称される。
【０００３】
ストリーミングシステムは、サーバーサイド技術に基づいて２種類に分けられる。これらの種類は、ここで、ノーマルストリーミング（normal streaming）及びプログレッシブ・ダウンローディング（progressive downloading）と称される。ノーマルストリーミングでは、サーバは、伝送ストリームのビット転送速度を制御するために、アプリケーションレベルの手段を用いる。その目標は、ストリームを、その再生速度にほぼ等しい速度で送信することにある。ある種のサーバは、実行中に、利用可能なネットワーク帯域幅に合わせるとともにネットワークの輻輳を避けるため、マルチメディアファイルのコンテンツを調整することもある。転送プロトコル及びネットワークとして、信頼性のあるものが使用されてもよく、信頼性のないものが使用されてもよい。信頼性のない転送プロトコルが使用されている場合、ノーマルストリーミングサーバは、通例、マルチメディアファイル中にある情報を、ネットワーク転送パケットへとカプセル化する。このことは、通例、ＲＴＰ／ＵＤＰ（リアルタイム転送プロトコル／ユーザデータグラムプロトコル）プロトコル及びＲＴＰペイロードフォーマットを用いて、特定のプロトコル及びフォーマットに従ってなされる。
【０００４】
プログレッシブ・ダウンローディングは、ＨＴＴＰ（ハイパーテキスト転送プロトコル）ストリーミング、ＨＴＴＰファーストスタート（HTTP fast-start）、又は擬似ストリーミング（pseudo-streaming）とも称されうるものであり、信頼性のある転送プロトコルの上部で実行される。サーバは、伝送ストリームのビット転送速度を制御するために、アプリケーションレベルの手段を使用することはない。その代わりに、サーバは、基礎となる信頼性のある転送プロトコルにより提供されたフロー制御機構に依存しうる。信頼性のある転送プロトコルは、通例、接続指向型である。例えば、ＴＣＰ（転送制御プロトコル）が、伝送されるビット転送速度を制御するために、フィードバックベースのアルゴリズムとともに用いられる。その結果、アプリケーションは、データを転送パケットへとカプセル化する必要はなく、マルチメディアファイルは、プログレッシブ・ダウンローディング・システムにてそのように転送される。従って、クライアントは、サーバサイドにあるファイルの正確な複製を受信する。このことにより、データを再度ストリーミングする必要なく、ファイルを複数回再生可能となる。
【０００５】
マルチメディアストリーミング用のコンテンツを作成するときには、各メディアサンプルが、特定の圧縮方法を用いて圧縮され、その結果、特定のフォーマットに準拠したビットストリームとなる。メディア圧縮フォーマットに加えて、コンテナフォーマットがなければならない。なお、コンテナフォーマットとは、特に、圧縮された複数のメディアサンプルを相互に関連づけるファイルフォーマットである。さらに、ファイルフォーマットには、例えば、ファイルをインデックスする情報、メディアを転送パケットへとカプセル化するための手掛り、及びメディアトラックをどのように同期させるかについてのデータが、含まれてもよい。また、メディアのビットストリームは、メディアデータとも称されうる。一方、マルチメディア・コンテナファイルは、メタデータと称されうる。ファイルフォーマットは、サーバからクライアントへのデータパイプの上部にてそのようにストリーミング可能な場合、ストリーミングフォーマットと称される。従って、ストリーミングフォーマットは、メディアトラックを単一のファイルへとインターリービングし、メディアデータは、復号又は再生順で現れる。基礎となるネットワークサービスが各メディア型に対して個別の転送チャネルを提供しない場合には、ストリーミングフォーマットが使用されねばならない。ストリーミング可能なファイルフォーマットには、データをストリーミングするときにストリーミングサーバが容易に利用可能な情報が、含まれている。例えば、そのフォーマットにより、それぞれのネットワーク帯域幅を対象とするメディアのビット転送速度の複数のバージョンを格納可能となり、ストリーミグサーバは、クライアントとサーバとの接続に応じてどのビット転送速度を用いるかについて、判別可能である。ストリーミング可能なフォーマットは、そのようにストリーミングされることはめったにないので、インターリービングされるか、あるいは、個別のメディアトラックへのリンクを含みうる。
【０００６】
ＭＰＥＧ（Moving Picture Expert Group）は、動画及び音声を含むマルテチメディアの実行を取り決めるためのマルチメディア圧縮規格であるＭＰＥＧ−４を開発した。ＭＰＥＧ−４規格書では、オーディオ・ビジュアル・オブジェクト用の符号化ツール一式、及び、符号化されたオーディオ・ビジュアル・オブジェクトの文法解説が、定められている。図１に、ＭＰＥＧ−４用に指定されたファイルフォーマット（ＭＰ４と称される）を示す。ＭＰ４は、オブジェクト指向ファイルフォーマットであり、そこでデータは、「アトム」と称される構造へとカプセル化される。ＭＰ４フォーマットは、全てのプレゼンテーションレベル情報を、実際のマルチメディアデータサンプル（メディアデータと称される）から分離し、それをファイル内部の一体構造内へ入れる。これは「ムービーアトム」と称される。この種のファイル構造は、一般に、「トラック指向」構造と称される。メタデータがメディアデータから分離されているためである。メディアデータは、メタデータアトムにより参照及び解釈可能である。ムービーアトムとともにインターリービング可能なメディアデータは存在しない。ＭＰ４ファイルフォーマットは、ストリーミングフォーマットではなく、ストリーミング可能フォーマットである。ＭＰ４は、プログレッシブ・ダウンローディング型のストリーミングシナリオ用に特に設計されたものではない。しかしながら、それは、ＭＰ４ファイルが注意深く配列されている場合（すなわち、ファイルの最初にメタデータ、そして、再生又は復号順でインターリービングされたメディアデータ）、通常のトラック指向ストリーミングフォーマットとみなされうる。メタデータの割合は、通常、ＭＰ４ファイルサイズ全体の５％〜２０％で様々である。ＭＰ４ファイルのような通常のトラック指向ストリーミングファイルをプログレッシブにダウンロードする場合、メタデータの全てが、あらゆるメディアデータよりも前に送信されるべきである。従って、メタデータの取得には、実際の再生開始前に長時間のバッファリングが必要となることもあり、それによりユーザはじらされてしまう。また、このことは、クライアントがメタデータ格納用に大規模な記憶域を必要とすることを意味しうる。特に、受信されるプレゼンテーションが長い場合には、そのようになる。メタデータが記憶域に適合しない場合、クライアントは、プレゼンテーションを再生することすらできない。記録におけるその他の問題は、記録アプリケーションが、メディアのかなりの部分をディスクへと書き込んだ後であるが、ムービーアトムを書き込む前に、障害を起こしたり、ディスクがなくなったり、あるいは、他の何かが起こった場合、記録されたデータが使用不能となることである。
【０００７】
通例の生のプログレッシブ・ダウンローディング・システムは、リアルタイムメディアエンコーダ、サーバ、及びいくつものクライアントからなる。リアルタイムメディアエンコーダは、メディアトラックを符号化して、ストリーミングファイルへとカプセル化する。ストリーミングファイルは、サーバへとリアルタイムで送信される。サーバは、ファイルを各クライアントへとコピーする。サーバでは、ファイルに対する変更がなされないことが望ましい。ＭＰ４ファイルフォーマットは、プログレッシブ・ダウンローディング・システムには充分には適合せず、上述の生のプログレッシブ・ダウンローディング・システムには全く適合しない。ＭＰ４ファイルがプログレッシブにダウンロードされるとき、全てのメタデータがメディアデータに先行することが、必要とされる。しかしながら、生のソースを符号化するときには、コンテンツを取り込む前に符号化されたソースにおける来るべきコンテンツに関連したメタデータを入手することは不可能である。
【０００８】
これらの問題を解決するための一手法として、メタデータ及びメディアデータの「サンプル」レベルのインターリービングがある。Microsoft（商標）のアドバンスド・システムズ・フォーマット（ＡＳＦ：Advanced Systems Format）は、このような手法の例である。ＡＳＦファイルレベル情報は、ファイルの最初に、ファイルヘッダ部として格納される。各メディアサンプル（すなわち、メディアデータの最小のアクセスユニット）は、添付のサンプルの解説とともにカプセル化される。しかしながら、ＡＳＦの手法には、いくつかの欠点がある。すなわち、各メディアサンプルは、それに伴ってともにカプセル化されたメタデータを有し、トラックについての単独のメタデータが存在しないので、トラックベースのファイル構造が放棄されるということがある。
【０００９】
メタデータとメディアデータとの区別が失われている。メディアデータが既にパケット化された構造になっていると、必要に応じて、実際のメディアデータを抽出して、それを他の転送プロトコル（例えばＲＴＰ）のペイロードフォーマットへと再パケット化することは、困難である。ストリーミングサーバが、ファイルを、プログレッシブ・ダウンローディングを通じて送信するのではなく、コネクションレス転送プロトコル（ＵＤＰ等）を通じてクライアントへとストリーミングするときに、このことが必要となる。メタデータ及びメディアデータをサンプルレベルにインターリービングすると、格納されるファイルは大きくなり、同様の情報の多くの繰り返しが導入される。従って、ファイルの記憶の冗長性により、長いプレゼンテーションについて、かなりの不必要な空間が消費されうる。
【００１０】
これらの問題を解決するためにＭＰＥＧグループにより導入された他の手法は、フラグメンテッド・ムービーファイル（fragmented movie file）と称される。この手法では、メタデータは、１つのアトム内にあるように限定されることはなく、ある程度インターリービングされた様式でファイル全体に拡がる。ファイルの基本的メタデータは、それでもなおムービーアトム内にあり、それによりプレゼンテーションの構造が設定される。ムービーアトム及びメディアデータアトムの他に、ムービーフラグメントがファイルへと追加される。ムービーフラグメントは、ムービーを時間通りに伸張する。ムービーフラグメントは、従来はムービーアトム内にあった情報のいくらかを提供する。それでもなお、実際のメディアサンプルは、メディアデータアトム内にある。
【００１１】
ＭＰ４ファイルのフラグメント化により、フラグメント間に完全な独立がもたらされるわけではない。メタデータの各フラグメントは、その後到来するＭＰ４ファイル全体に有効である。従って、ＭＰ４プレイヤは、フラグメントで到来したメタデータ部分の全てを、メタデータの当該部分が使用された後であっても、格納しておかなければならない（再生及び廃棄手法をとることはできない。すなわち、フラグメントは再生後にも保存されねばならない）。また、フラグメントにより、上述の生のストリーミング手法に関連した問題が解決されるわけではない。このことは、フラグメントが相互に独立しているわけではないことによる。
【発明の開示】
【００１２】
〔発明の概要〕
本発明の目的は、上述の問題を改善することにある。本発明の目的は、特許請求の範囲における独立項に開示されるものにより特徴づけられる方法、マルチメディアストリーミングシステム、データ処理装置、及びコンピュータプログラムプロダクトにて、達成される。本発明の好適な実施形態は、添付の特許請求の範囲にて示される。
【００１３】
本発明の第１の側面によると、マルチメディアファイルは、そのファイルの全てのメディアサンプルに共通のファイルレベルのメタデータの少なくとも一部と、複数のメディアサンプル及び前記メディアサンプルのメタデータを含む個別のセグメントとを含むように、作成される。
【００１４】
本発明の第２の側面によると、個別の各セグメントは、受信装置にて、ファイルレベルのメタデータを利用して１つずつパージングされる。マルチメディアファイルとは、場合によっては複数のメディアソースからの、メタデータ及びメディアデータの双方を含むデータの任意のグループのことを意味している。パージングとは、一般に、マルチメディアファイルを、特に、ファイルレベルのメタデータと個別のセグメントとに分離するために、マルチメディアファイルを解釈することを意味している。セグメントなる用語は、通例、何らかの圧縮方法により圧縮された、複数のメディアサンプルのタイミングのとれたシーケンスのことを意味している。セグメントには、１つ又はそれ以上のメディア型が含まれてもよい。セグメントは、そのセグメントに対応した特定の時間に亘りファイル内にある全てのメディア型を含む必要はない。セグメントにおけるあるメディア型のメディアサンプルは、時間内に一体のブロックを形成することになる。セグメント内にあるマルチメディアデータの複数のコンポーネントは、同一の継続時間又はバイト長である必要はない。
【００１５】
本発明の側面により、特に、マルチメディアコンテンツのストリーミングのための利点が提供される。既に使用されたメディアセグメントを保持する必要がないので、トラック指向ストリーミングファイルの従来のストリーミングよりも、必要となる一時記憶域がより少なくなる。これは、マルチメディアファイルを含む装置、及び受信したマルチメディアファイルをパージングする装置の双方に、当てはまる。各サンプルについてインターリービングされたメタデータ及びメディアデータを有する必要はない。また、本発明は、ファイルからの情報を編集して取得する手段に、柔軟性を提供する。メディアセグメントは、ファイルレベルのメタデータ及びセグメントのメタデータが取得されるとすぐに、他のものから独立して再生されてもよい。それにより、再生が、従来のＭＰ４ストリーミングよりも早く開始できるようになる。本発明のさらなる利点として、ファイルレベルメタデータが受信済であれば、受信済のどのメディアセグメントからでも再生を開始できるということがある。ＡＳＦフォーマットと比較すると、本発明によるメディアサンプルのセグメント化されたトラック指向のグループ化により、例えば、ＴＣＰではなくＵＤＰによりメタデータをストリーミングする場合、メディアデータを他の転送プロトコルのペイロードフォーマットへと再パケット化することがより効率的かつ容易という、さらなる利点が提供される。本発明は、非ストリーミングアプリケーションに対しても、利点を提供する。例えば、生で記録されているマルチメディアファイルがアップロードされる場合、必要なメディアデータが取り込まれて復号された直後に、セグメントがアップロードされてもよい。
【００１６】
本発明の一実施形態では、マルチメディアファイルは、ストリーミングサーバからストリーミングクライアントへと、ＴＣＰ（転送制御プロトコル）のような信頼性のある転送プロトコルを利用して、プログレッシブにダウンロードされる。さらに別の実施形態によると、ファイルレベルのメタデータは、新規のクライアントを、生のプログレッシブ・ダウンローディング・セッションに参加させるために、マルチメディアファイル内で繰り返されてもよい。ファイルレベルのメタデータ部分を受信した後、新規のクライアントは、受信しているマルチメディアファイルのパージング、復号、及び再生を開始可能である。従来、このことは可能ではなかった。その代わりに、ファイルレベルのメタデータは、例えば、別個のファイルとしてクライアントへと送信されていた。生のプログレッシブ・ダウンローディングを開始するためのこのような従来の方法では、クライアント及びサーバの実装が複雑となっている。
【００１７】
以下、好適な実施形態について添付の図面を参照することにより、本発明を詳細に説明する。
〔発明の詳細な説明〕
本発明の好適な実施形態について、改良型ＭＰＥＧ−４ファイルフォーマットにより説明する。但し、本発明は、QuickTimeフォーマット等の他のストリーミングアプリケーション及びフォーマットにおいて実装されてもよい。
【００１８】
図２に、マルチメディアコンテンツをストリーミングする伝送システムを示す。本システムは、エンコーダＥＣ（エディタとも称され、通例は複数のメディアソースＭＳから送信されるメディアコンテンツデータを作成）、ネットワークＮＷを介して符号化マルチメディアファイルを送信するストリーミングサーバＳＳ、及びファイルを受信する複数のクライアントＣを、備えている。コンテンツは、生のプレゼンテーションを記録するレコーダ（例えばビデオカメラ）からのものであってもよく、あるいは、予め記憶装置（ビデオテープ、ＣＤ、ＤＶＤ、ハードディスク等）に格納されたものであってもよい。コンテンツは、例えば、ビデオ、オーディオでもよく、さらに画像でもよく、データファイルを含んでいてもよい。エンコーダＥＣからのマルチメディアファイルは、サーバＳＳへと転送される。サーバＳＳは、複数のクライアントＣにサービスを提供することができ、マルチメディアファイルをサーバのデータベースから、あるいは、ユニキャスト又はマルチキャスト経路を用いてエンコーダＥＣからすぐに送信することにより、クライアントの要求に応答することができる。ネットワークＮＷは、例えば、移動通信ネットワーク、ローカルエリアネットワーク、放送ネットワーク、又は、ゲートウェイにより区分された複数の異なるネットワークであってもよい。
【００１９】
図３に、エンコーダユニットＥＮＣにおけるコンテンツ作成段階中の機能をより詳細に説明する。未処理のメディアデータが、１つ又はそれ以上のメディアソースから取り込まれる。取込段階からの出力は、通常は、圧縮データか、あるいはわずかに圧縮されたデータである。例えば、ビデオ取込カードからの出力は、非圧縮ＹＵＶ４：２：０フォーマットでもよく、モーションＪＰＥＧフォーマットでもよい。メディアストリームは編集されて、１つ又はそれ以上の非圧縮メディアトラックが生成される。メディアトラックを様々な方法で（例えば、ビデオフレーム速度を低下させるように）、編集することが可能である。そして、メディアトラックは圧縮可能となる。そして、圧縮されたメディアトラックは、多重化されて、単一のビットストリームが形成される。この段階にて、メディアデータ及びメタデータは、選択されたファイルフォーマットへと配列可能である。ファイルは、作成された後、ストリーミングサーバＳＳへと送信可能となる。なお、通例、多重化はプログレッシブ・ダウンローディング・システムにて重要であるが、通常のストリーミングシステムでは、メディアトラックが個別のストリームとして伝送されるので、必須でないこともある。
【００２０】
なお、図２及び図３では、コンテンツ作成機能（ＥＮＣによる）とストリーミング機能（ＳＳによる）とは独立しており、それらは、同一の装置により実行されてもよく、２つより多くの装置により実行されてもよい。図４に、マルチメディア取得クライアントの機能を示す。クライアントＣは、圧縮されて多重化されたマルチメディアファイルをサーバＳＳから取得する。クライアントＣは、個別のメディアトラックを得るために、ファイルをパージングして多重分離する。そして、これらのメディアトラックが伸張されて、再構成されたメディアトラックが得られる。なお、該メディアトラックは、その後、ユーザインタフェースＵＩの出力装置を用いて再生可能である。これらの機能に加えて、エンドユーザの動作を反映させる制御ユニットが、提供されている。エンドユーザの動作を反映させるということは、すなわち、エンドユーザの入力に応じて再生を制御するとともにクライアントのサーバ制御を処理することである。再生は、独立したメディアプレイヤ・アプリケーション又はブラウザのプラグインにより、提供されてもよい。
【００２１】
ここで、メディアサンプルは、圧縮メディアデータにおける非圧縮サンプルとなるべき最小の復号可能ユニットとして定義される。例えば、圧縮ビデオフレームがメディアサンプルであってもよく、それが復号されると非圧縮画像が取得される。これに対して、圧縮ビデオの一部は、一部を復号すると非圧縮サンプル（画像）の空間部分となるため、メディアサンプルではない。単一のメディア型のメディアサンプルは、トラックへとグループ化されてもよい。通例、マルチメディアファイルは、ストリーミングされたプレゼンテーション（例えばムービー）に関連した全てのメディアデータ及びメタデータを含むものとみなされる。
【００２２】
マルチメディアファイルに担持されているメタデータは、以下のように分類されうる。通例、メタデータの一部の範囲は、ファイル全体である。このようなメタデータには、使用されているメディアコーデックの識別情報、又は、正確な表示矩形サイズの指示が、含まれてもよい。この種のメタデータは、ファイルレベルのメタデータ（又はプレゼンテーションレベルメタデータ）と称されうる。メタデータの他の部分は、特定のメディアサンプルに関するものである。このようなメタデータには、サンプルの型と、バイトでのサイズとが、含まれてもよい。このようなメタデータは、サンプル専用メタデータと称されうる。
【００２３】
メディアの復号及び再生は、通例、ファイルレベルのメタデータなしには不可能であるため、このようなメタデータは、通例、ストリーミングファイルの先頭にてヘッダ部となっている。サンプル専用メタデータは、従来、メディアデータとインターリービングされるか、あるいは、ファイルレベルのメタデータの直後のファイルの先頭部分又はファイルレベルのメタデータとインターリービングされたファイルの先頭部分となりうる。これにより、プログレッシブ・ダウンローディングの問題が発生し、ある種のファイルフォーマットでは、プログレッシブ・ダウンローディングが全く不可能である。
【００２４】
図５ａに、本発明の好適な一実施形態による改良型ファイルフォーマットを示す。その意図するところは、「メタデータ」と「メディアデータ」との対を作成することにある。この対は、他の「メタデータ」と「メディアデータ」との対からは独立して、解釈及び再生可能である。このような対は、ここでセグメントと称される。これらのセグメントにおけるメタデータは、ファイルレベルでグローバルなメタデータ記述部に依存している。プログレッシブ・ダウンローディングについて、ファイルは、自己完結型である。すなわち、ファイルは、他のファイルへのリンクを含まず、メタデータ部の数の制約は、解除及び／又は再解釈される。従って、メディアデータサンプルオフセットのようなセグメントレベルメタデータ内のメディア専用情報は、対応するセグメントにのみ関係している。すなわち、他のセグメントに関係した情報は存在しない。各セグメントは、それ自身又はファイルレベルのメタデータ部にのみ依存しているように見える。これにより、受信装置（ＴＥ）は、ファイルレベルのメタデータ記述部と、セグメントのメタデータと、そのメディアデータの部分とを受信するとすぐに、再生を開始できるようになる。本発明の好適な実施形態によると、セグメントは、受信装置Ｃにてパージングされた後に、削除（一次記憶域から除去）可能である。従って、ファイルの最後のセグメントがパージングされるまで、ファイルレベルのメタデータのみが保持されればよいので、一時記憶域が少なくてすむ。ファイルをパージングする装置がマルチメディアファイルの再生も行う場合、セグメントは、再生後、永久に削除されてもよい。さらに、このことにより、必要な記憶リソース量が少なくなる。パージング／多重分離機能は、まず、ファイルレベルのメタデータを読み込んで、ファイルレベルのメタデータに基づいてセグメントを分離する。この後、メディアトラックが、１回に１セグメントずつセグメント内のデータから分離される。
【００２５】
図５ｂに、図５ａに示したセグメント化ファイルフォーマット原理による改良型ＭＰ４ファイルフォーマット（プログレッシブＭＰ４ファイルと称される）を示す。ＭＰ４では、２つの新規のアトム型が定義されている。ＭＰ４記述アトムｍｐ４ｄは、ＭＰ４ファイルに関連した必要な情報を全体として保持している。なお、ある種のＭＰＥＧ−４規格書にて用いられている「ボックス」なる用語が、アトムの代わりに用いられることがある。必要な情報が「ＭＰ４セグメントアトム」ｓｍｐ４内に存在しない場合、その情報は、ＭＰ４記述アトムｍｐ４ｄ内に存在するはずである。従って、ＭＰ４記述アトムｍｐ４ｄ内部の全情報は、全てのＭＰ４セグメントアトムｓｍｐ４について有効であるという意味で、グローバルである。ＭＰ４記述アトム、及びＭＰ４セグメントアトムｓｍｐ４のムービーアトムｍｏｏｖの双方内に、アトムが存在する場合、ムービーアトムｍｏｏｖ内の情報が参照として取り出され、それが、ＭＰ４記述アトムｍｐ４ｄに優先する。記述アトムｍｐ４ｄは、従来のＭＰ４ファイルの「ｍｏｏｖ」アトムにおける任意の情報を含んでもよい。これには、例えばメディアトラック数及び使用されているコーデックについての情報が、含まれる。
【００２６】
ＭＰ４セグメントアトムｓｍｐ４は、プログレッシブＭＰ４ファイル内にある各メタデータ−メディアデータ対を、カプセル化する。セグメントアトムｓｍｐ４は、ムービーアトムｍｏｏｖ及びメディアコンテナアトムｍｄａｔを含む。各ｓｍｐ４内のムービーアトムは、同一のＭＰ４セグメントアトムｓｍｐ４のメディアデータアトムｍｄａｔ内のメディアデータに関連したメタデータの全てをカプセル化する。好適な実施形態では、ＭＰ４セグメントアトムは、メタデータ及び１つ又はそれ以上のメディア型のメディアデータを含む。これにより、トラック指向原理が保たれ、メディアトラックが容易に分離されるようになる。ファイル内のセグメント及びファイルレベルのメタデータには、規定の順番があるわけではない。実用上、ファイルレベルのメタデータ（ｍｐ４ｄ）をファイルの先頭に配置し、セグメントアトムｓｍｐ４を再生順に配置するとよい。生のストリーミング、早送り若しくは巻戻し動作、ランダムアクセス、又は他の目的のために、ファイルレベルのメタデータ（ｍｐ４ｄ）が、ファイル内で繰り返されてもよい。補遺１に、改良型ＭＰ４アトムのより詳細なリストを示す。
【００２７】
上述のファイルフォーマットは、様々な方法で使用されるいくつもの動作のために役立つ。例えば、交換フォーマットとして、コンテンツ作成中、ストリーミングにて、あるいは、ローカルプレゼンテーションにて等である。プログレッシブＭＰ４ファイルは、生のコンテンツダウンロード等のプログレッシブ・ダウンローディング動作に非常に適している。さらに、そのファイルフォーマットにより、効率的な作成が可能となり、プレゼンテーション（セグメント）の一部分の編集及び再生が可能となり、その一部分は、先行するセグメントや後続のセグメントから独立している。
【００２８】
図６に、プログレッシブ・ダウンローディングの一例を示す。ＷＷＷページには、プレゼンテーション記述ファイルへのリンクが、含まれている。そのファイルには、同一のコンテンツの複数のバージョンの記述が含まれてもよく、その各々が、例えば異なったビット転送速度を対象としている。クライアント装置Ｃのユーザがリンクを選択して、要求がサーバＳＳへと配信される６１。ＨＴＴＰが用いられている場合、ファイルのＵＲＩ（Uniform Resource Identifier）を含む通常のＧＥＴコマンドが、使用されてもよい。ファイルがダウンロードされ６２、受信したプレゼンテーション記述ファイルを処理するように、クライアントＣが呼び出される。最も適切なプレゼンテーションが選択可能である。クライアントＣは、選択されたプレゼンテーションに対応したファイルをウェブサーバに対して要求する６３。要求６３に対する応答として、サーバＳＳは、使用されている転送プロトコルに従ってファイルを転送し始める６４。
【００２９】
プログレッシブＭＰ４ファイルの受信（ストリーミングサーバＳＳ又はローカル記憶媒体から）が開始されると、クライアントＣは、ＭＰ４記述アトムｍｐ４ｄを格納する。再生前に、少なくとも２つのＭＰ４セグメントアトムを読み込んで、再生中に、３番目をバッファに入れることが、推奨されている。これにより、途切れのない再生が可能となる。適度に小さなサイズのＭＰ４セグメントを作成することにより、再生開始が早くなる。既に再生されたセグメントを保持する必要がなく、ファイルレベルのメタデータ部分（ｍｐ４ｄ）のみが、最後のセグメントが再生されるまで保存されればよいので、クライアントＣにおける記憶域の必要性はさらに減少する。また、ファイルレベルのメタデータが既に受信されていれば、再生は、受信されたどのセグメントから開始されてもよく、ファイルの一部（あるトラック／ＭＰ４セグメントアトムｓｍｐ４）のみが再生されてもよい。
【００３０】
上述の本発明の好適な実施形態は、任意の通信システムにて使用されうる。基礎となる伝送レイヤは、回線交換又はパケット交換データ接続を利用してもよい。このような通信ネットワークの一例として、３ＧＰＰ（第３世代パートナーシップ・プロジェクト）により開発されている第３世代移動通信システムがある。ＨＴＴＰ／ＴＣＰの他に、別の転送レイヤが用いられてもよい。例えば、ＷＡＰ（ワイヤレス・アプリケーション・プロトコル）のＷＴＰ（ワイヤレス・トランザクション・プロトコル）の一式により、転送機能が提供されてもよい。
【００３１】
一実施形態では、サーバＳＳとクライアントＣとの間の伝送経路には、プロトコル変換が必要になることもある。この場合、マルチメディアファイルを、新規の転送プロトコルに従って再パケット化するためにパージングするのに、ゲートウェイ装置が必要となることもある。例えば、ＴＣＰのペイロードをＵＤＰのペイロードへと変換するときに、このようなパージングが必要となる。起こりうるファイル変換は、従来のトラック指向フォーマット又はサンプル指向フォーマットから、図５ａを参照して説明したフォーマットへのものとなる。例えば、従来のＭＰ４ファイルは、図５ｂで説明したセグメント化ＭＰ４ファイルへと変換されてもよい。プログレッシブ・ダウンローディング対応に改良されたマルチメディア・メッセ−ジング・サービス（ＭＭＳ）にて、このような変換が必要となりうる。多くの場合、ある種のＭＭＳ対応の端末は、図１に示した従来のＭＰ４バージョン１に従ってファイルを作成する。このフォーマットが、３ＧＰＰ・ＭＭＳ規格書にて選択されているためである。これらのファイルは、プログレッシブ・ダウンローディングができるように、セグメント化されたＭＰ４ファイルへと変換可能である。
【００３２】
セグメント化ファイルフォーマットにより、マルチメディアコンテンツ作成時にも、いくつもの利点が提供される。上述のように、セグメントは、相互に独立しているので、必要なメディアデータが取り込まれて符号化された直後に、作成されて格納されてもよい。装置の記憶域がなくなったとしても、既に作成されたメディアサンプルを解放することなく、既に格納されたセグメントを用いることが可能である。そのセグメントは、従来のＭＰ４生成とは異なり、引き続き再生可能である。生の記録では、セグメントは、必要なメディアデータが取り込まれて符号化された直後に、アップロード可能である。エンコーダＥＮＣが、セグメントを作成してサーバＳＳへと送信するか、あるいは、メモリカード又はディスク等のデータ記憶媒体に格納した後に、それを記憶域から削除することにより、必要とされる記憶域のリソースが少なくてすむようになる。ファイル作成中は、ファイルレベルのメタデータ部分を保存するだけでよい。アップロード処理は、リアルタイムでなされる。すなわち、ファイル伝送のビット転送速度は、アップロードに用いられるチャネルの処理能力に従って、調整されうる。その代わりに、メディアのビット転送速度は、チャネルの処理能力から独立していてもよい。リアルタイムのプログレッシブ・アップローディングは、例えば、生のプログレッシブ・ダウンローディング・システムの一部として使用可能である。プログレッシブ・アップローディングは、マルチメディア・メッセ−ジング・サービスの将来の改定に用いられるべき代替案である。
【００３３】
一実施形態によると、マルチメディアファイルの従来のダウンローディングに基づいて、旧版互換にシステムを拡張することが可能である。すなわち、ダウンロードされるべきファイルが本発明に従って構成されている場合、プログレッシブ・ダウンローディング不能な端末は、まずファイルをダウンロードして、オフラインで再生することが可能である。一方、他の端末は、プログレッシブ・ダウンローディング可能である。これらの代替案の双方に対応するために、サーバーサイドの変更は不要である。このような機能は、マルチメディア・メッセ−ジング・サービスにおいて望ましいものである。マルチメディアメッセージの少なくとも一部は、本発明に従って作成される場合、ＭＭＳシステム内の適切な要素から、従来通りダウンロードされるか、あるいは、プログレッシブ・ダウンローディングされうる。その技術により変更されるのは、マルチメディアメッセージファイルの作成方法だけであるため、ＭＭＳシステム内の要素に対する変更は不要である。
【００３４】
また、セグメント化ファイルフォーマットにより、ビデオ編集動作は単純化されうる。セグメントは、マルチメディア・プレゼンテーションにおける論理ユニットを表してもよい。このような論理ユニットは、例えば、単一のイベントからのニュースフラッシュであってもよい。セグメントがプレゼンテーションに対して挿入又は削除された場合、変更される必要があるのは、ファイルレベルのメタデータにおけるいくつかのパラメータのみである。セグメントレベルのメタデータの全てが、それらが配置されたセグメントに関するものであるためである。従来のトラック指向ファイルフォーマットでは、データの挿入又は削除により、多数のパラメータ値が再計算されることになる。特に、メディアデータが再生又は復号順に配列されている場合には、そのようになる。
【００３５】
本発明は、現行の通信装置へと実装可能である。それらは全て、上述の発明の機能が実行されうるプロセッサ及びメモリを有する。プログラムコードは、プロセッサ内で実行された場合に本発明の機能を提供するものであり、装置内に組み込まれるか、あるいは外部記憶装置から装置へと読み込まれる。また、独立した論理コンポーネント又は１つ若しくはそれ以上の特定用途向けＩＣ（ＡＳＩＣ）によりなる回路等、他のハードウェア実装も可能である。これらの技術の組み合わせも可能である。
【００３６】
技術の進歩に伴い、本発明の概念がいくつもの異なる方法で実行可能となることが、当業者には明らかである。本発明は、図２におけるシステムに限定されるものではなく、非ストリーミングアプリケーションにて使用されてもよい。従って、本発明及びその実施形態は、上述の実施例に限定されるものではなく、添付の特許請求の範囲及び真意内で、様々であってもよい。
【００３７】
補遺１
ムービーアトム（‘ｍｏｏｖ’）
各ｍｐ４セグメントアトム（‘ｓｍｐ４’）内には正確に１つのムービーアトムがあり、それにより、同ｍｐ４セグメントアトムにおけるメディアデータアトム（‘ｍｄａｔ’）内部のメディアデータに関連した全てのメディアデータがカプセル化されることになる。ＭＰ４記述アトムについて、ムービーアトムは、共通のメタデータを含まねばならず、それは、プログレッシブｍｐ４ファイルのプレゼンテーション全体に亘る。このことにより、各ｍｐ４セグメントアトム内で同一の情報が送信されないようにする手段における効率化が可能となる。
【００３８】
ムービーヘッダアトム（‘ｍｖｈｄ’）
ＭＰ４記述アトム内部のムービーヘッダアトムには、プレゼンテーション全体を管理する情報が、含まれている。このアトム用の全てのフィールドシンタックスは同一である。各ｍｐ４セグメントアトムには、ムービーヘッダアトムがなければならない。このムービーヘッダアトムには、そのセグメントのみに関係する情報が、含まれている。従って、全てのフィールドシンタックスは、ｍｐ４セグメントアトムのみに関係している（例えば、その継続時間は、ｍｐ４セグメントアトムの継続時間を与えるだけである）。
【００３９】
オブジェクトディスクリプタアトム（‘ｉｏｄｓ’）
ＭＰ４記述アトム内にはオブジェクトディスクリプタアトムがなければならない。ｍｐ４セグメントアトム内にも、オブジェクトディスクリプタアトムがあってもよい。ｍｐ４記述アトム内にのみ存在する場合、その情報は、ｍｐ４セグメントアトムの全てに及んでもよい。いずれかのｍｐ４セグメントアトムがオブジェクトディスクリプタアトムを有する場合、該オブジェクトディスクリプタアトムが、ｍｐ４記述アトム内のものよりも優先する。このアトムの全てのフィールドシンタックスは、通常のｍｐ４ファイルのオブジェクトディスクリプタアトムと同じになる。
【００４０】
トラックアトム（‘ｔｒａｋ’）
ｍｐ４セグメントアトムのムービーアトム内部に、１つ又はそれ以上のトラックアトムがあってもよい。トラックアトムには、現在のセグメントアトムのトラック情報が、含まれている。また、プレゼンテーションレベルのトラック情報も、ｍｐ４記述アトム内になければならない。
【００４１】
トラックヘッダアトム（‘ｔｋｈｄ’）
各ｍｐ４セグメントアトム及びｍｐ４記述アトムには、トラックヘッダアトムがなければならない。同一のトラックについて、トラックＩＤは、全てのｍｐ４セグメントアトム及びｍｐ４記述アトム内で、同一でなければならない。ｍｐ４記述アトムについて、トラックヘッダアトムは、プレゼンテーション全体を管理する情報を保持する。ｍｐ４セグメントアトムのトラックヘッダアトムは、現在のセグメントアトムに関連する情報を保持する。
【００４２】
トラック参照アトム（‘ｔｒｅｆ’）
トラック参照アトムは、プレゼンテーション内で、格納ストリームから他のストリームへの参照を提供する。これは、必須のアトムではない。トラックの参照がプレゼンテーション全体に亘って有効である場合、このアトムをｍｐ４記述アトム内に入れることは、全てのｍｐ４セグメントアトムにおける同一情報の繰り返しを避けるのに有利である。このアトムの全てのフィールドシンタックスは、通常のｍｐ４ファイルのトラック参照アトムと同一となる。
【００４３】
編集アトム（‘ｅｄｔｓ’）
編集アトムは、プレゼンテーションの時系列をメディアの時系列に対してマッピングする。編集アトムは、編集リストのコンテナである。それは、必須のアトムではない。なお、編集アトムはオプションである。このアトムがないと、これらの時系列の一対一のマッピングが暗黙のうちに想定される。編集リストがなければ、トラックのプレゼンテーションが即座に開始される。トラックの開始時をオフセットさせるために、空の編集が用いられる。トラック全体について正確に１つの編集アトムをとることができ、それは、ｍｐ４記述アトム中になければならない。
【００４４】
編集リストアトム（‘ｅｌｓｔ’）
編集リストアトムには、明示の時系列マップが含まれている。時系列であれば、「空」の部分を表すことが可能である。そこでは、メディアが提示されていない「ドエル」、メディア内の単一の時点がある時間に亘り保持されること、及び、通常のマッピングがある。編集リストにより、相対時間（サンプルテーブル中のデルタ）から絶対時間（プレゼンテーションの時系列）へのマッピングが提供される。「無音」間隔又はメディアにおけるある部分の繰り返しが導入されることもある。編集リストアトムは、必須のアトムではない。それがトラックについて与えられている場合、ｍｐ４記述アトム内部に、編集アトムにより格納された正確に１つの編集リストアトムがなければならない。このアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルの編集リストアトムと同一となる。
【００４５】
メディアアトム（‘ｍｄｉａ’）
メディアアトムコンテナは、ストリーム内のメディアデータについての情報を宣言する全てのオブジェクトが、格納される。それは、ｍｐ４記述アトム内、及び各ｍｐ４セグメントアトム内になければならない。
【００４６】
メディアヘッダアトム（‘ｍｄｈｄ’）
メディアヘッダは、ストリーム内のメディアの特性に関連したメディアに依存しない情報の全体を宣言する。ｍｐ４記述アトム及び各ｍｐ４セグメントアトム内のトラックにおいて、メディア毎に正確に１つのメディアヘッダアトムがなければならない。ｍｐ４記述アトムについてこのアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルのメディアヘッダアトムと同一である。ｍｐ４セグメントアトムについて、継続時間フィールドには、セグメントレベルの継続時間情報が含まれる。
【００４７】
ハンドラ参照アトム（‘ｈｄｌｒ’）
メディアアトム内のハンドラアトムは、ストリーム内のメディアデータを提示することにより、ストリーム内のメディアの性質を提示する処理を宣言する。例えば、ビデオハンドラは、ビデオトラックを処理することになる。このアトムは、別々のｍ４セグメントアトムへと分割された同一のトラックメディアの各部分全体に関する情報に亘るので、ｍｐ４記述アトムのメディアアトム内にのみ存在しなければならず、他のｍｐ４セグメントアトム内の同一のトラックについて有効とみなされる。このアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルのハンドラ参照アトムと同一となる。
【００４８】
メディア情報アトム（‘ｍｉｎｆ’）
メディア情報アトムには、ストリーム内のメディアの特性を宣言する全てのオブジェクトが含まれる。各トラック内には、正確に１つのメディア情報アトムがなければならない。メディア情報ヘッダアトムは、ｍｐ４記述アトム内にのみ存在しなければならない。ｍｐ４ファイル全体に亘るメディア的にグローバルな情報を含むためである。データ情報アトム（‘ｄｉｎｆ’）及びそのサブアトムのデータ参照アトム（‘ｄｒｅｆ’）は、ｍｐ４記述ファイル内にのみ存在しなければならない。プログレッシブｍｐ４ファイル全体に亘るメディア的にグローバルな情報を含むためである。
【００４９】
サンプルテーブルアトム（‘ｓｔｂｌ’）
サンプルテーブルアトムは、各ｍｐ４セグメントアトム又はｍｐ４記述アトム内のトラックにおける全てのメディア情報アトム内に存在しなければならない。サンプルテーブルには、トラック内のメディアサンプルの全ての時間及びデータインデックスが、含まれている。ここでテーブルを用いると、サンプルを時間通りに配置し、その型を特定し（例えば、Ｉフレームであるかどうか）、そのサイズ、コンテナ、そのコンテナへのオフセットを特定することが、可能となる。
【００５０】
サンプル復号時間アトム（‘ｓｔｔｓ’）
このアトムには、復号時間をサンプル数に対してインデックス可能とするテーブルがコンパクトになったものが、含まれている。ｍｐ４セグメントアトムの各トラックについて必須のアトムである。このアトムのフィールドは、現在のｍｐ４セグメントアトム内のメディアサンプルを、表さねばならない。従って、ｍｐ４セグメントアトムの各トラックには、そのｍｐ４セグメントアトム内にあるメディアサンプルのサンプル時間情報を与えるために、サンプルアトムへの復号時間がなければならない。なお、現在の‘ｓｔｔｓ’アトムにより参照される第１のサンプルは、現在のｍｐ４セグメントアトム内の第１のサンプルである。このアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルのサンプルアトムへの復号時間と同じである。
【００５１】
サンプル作成時間アトム（‘ｃｔｔｓ’）
このアトムは、復号時間と作成時間との間のオフセットを提供する。このアトムは、必須のアトムではない。それは、第１のｍｐ４セグメントアトムのトラックアトム内にある場合、他のｍｐ４セグメント内の同一のトラックＩＤの他の全てのトラック内になければならない。このアトムのフィールドは、現在のｍｐ４セグメントアトム内のメディアサンプルを、表さねばならない。このアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルのサンプルアトムの作成時間におけるものと同じである。
【００５２】
同期サンプルアトム（‘ｓｔｓｓ’）
同期サンプルアトムは、ストリーム内のランダムアクセスポイントのコンパクトな作成を提供する。このアトムは、必須のアトムではない。それが、第１のｍｐ４セグメントアトムのトラックアトム内にある場合、他のｍｐ４アトム内の同一のトラックＩＤの他の全てのトラック内になければならない。このアトムのフィールドは、現在のｍｐ４セグメントアトム内のメディアサンプルを、表さねばならない。従って、サンプル番号パラメータにより規定される各同期サンプルには、現在のｍｐ４セグメントアトム内部のメディアデータの第１のサンプル（サンプル番号＝１）を参照するインデックスが付されねばならない。例として、同期サンプルが、ｍｐ４ファイルの先頭から２５番目のサンプルであって、ｍｐ４セグメントアトムの４番目のサンプルである場合、このサンプルを保持しているｍｐ４セグメントアトムの同期サンプルには、このサンプルを表す４のインデックスが付されていなければならない。
【００５３】
サンプル記述アトム
サンプル記述アトムは、使用されている符号化型についての詳細情報、及びその符号化に必要な初期化情報を提供する。ｍｐ４記述アトムのトラックアトムには、正確に１つのサンプル記述アトムがなければならない。それにより、後続のｍｐ４セグメントアトム内の同一のトラックＩＤのトラックに有効な情報が、提供される。このアトムの全てのフィールドシンタックスは、従来のＭＰ４ファイルのメディアヘッダアトムにおけるものと同じとなる。
【００５４】
サンプルサイズアトム（‘ｓｔｓｚ’）
サンプルサイズアトムには、サンプル数、及び、現在のトラックにより参照される現在のｍｐ４セグメントアトムのメディアデータ内の各サンプルのサイズを提供するテーブルが、含まれている。このアトムは、同一のトラックＩＤにより参照される同一のトラックについての各ｍｐ４セグメントアトム内にあるべき、必須のアトムである。このアトム内の情報は、現在のｍｐ４セグメントアトム内にあるメディアサンプルを表すだけでなければならない。そのため、このアトム内の第１のエントリは、現在のｍｐ４セグメントのメディアデータ内の第１のメディアサンプルのサイズを表している。このアトムの他の全てのフィールドシンタックスは、従来のＭＰ４ファイルのサンプルサイズアトム内のものと同じである。
【００５５】
サンプル−チャンクアトム（‘ｓｔｓｃ’）
メディアデータ内のサンプルは、グループ化されてチャンクとなる。チャンクは、それぞれサイズが異なっていてもよく、チャンク内のサンプルは、それぞれサイズが異なっていてもよい。このアトムを用いることにより、サンプル、その位置、及び対応したサンプルの説明を含んだチャンクが見出されうる。このアトムは、同一のトラックＩＤにより参照される同一のトラックについて各ｍｐ４セグメントアトム内にあるべき必須のアトムである。このアトム内部の情報は、現在のｍｐ４セグメントアトム内にあるメディアサンプル及びチャンクを表すだけでなければならない。そのため、第１のチャンクフィールドは、常に、現在のｍｐ４セグメントアトム内の第１のチャンク（インデックス＝１）に関するインデックスを有する。このアトムの他の全てのフィールドシンタックスは、従来のＭＰ４ファイルのサンプル−チャンクアトム内のものと同じとなる。
【００５６】
チャンクオフセットアトム（‘ｓｔｃｏ’）
チャンクオフセットテーブルは、各チャンクから、格納プログレッシブｍｐ４ファイルへのインデックスを提供する。全てのインデックス値は、ｍｐ４セグメントアトム（ｍｐ４セグメントアトムのベースアドレスは０）の先頭から開始する相対アドレスである。このアトムは、同一のトラックＩＤにより参照される同一のトラックについて各ｍｐ４セグメントアトム内にあるべき必須のアトムである。このアトム内の情報は、現在のｍｐ４セグメントアトム内にあるメディアサンプル及びチャンクのみを表さねばならない。このアトムの全てのフィールドシンタックスは、ｍｐ４セグメントアトムの先頭をベースオフセットにとるチャンクオフセット以外は、通常のｍｐ４ファイルのチャンクオフセットアトムと同じになる。
【００５７】
シャドー同期サンプルアトム（‘ｓｔｓｈ’）
シャドー同期テーブルは、検索又は同様の目的で使用可能な同期サンプルのオプションの組を提供する。通常の順方向再生では無視される。このアトムは必須ではない。それは、全てのｍｐ４セグメントアトム内にあるわけではない。フィールドのシャドーサンプル番号及び同期サンプル番号における全てのサンプルのインデックスは、コンテナｍｐ４セグメントアトム内にあるトラックの第１のメディアサンプルに対して参照される。このアトムの他の全てのフィールドシンタックスは、従来のｍｐ４ファイルのシャドー同期サンプルアトムにおけるものと同じである。
空き空間アトム（‘ｆｒｅｅ’又は‘ｓｋｉｐ’）
空き空間アトムのコンテンツは、無関係であり、無視されてもよい。このアトムは、必須ではなく、プログレッシブｍｐ４ファイル内のどこにあってもよい。このアトムの全てのフィールドシンタックスは、従来のｍｐ４ファイルの空き空間アトムにおけるものと同じとある。
【図面の簡単な説明】
【００５８】
【図１】従来のＭＰ４ファイルフォーマットの説明図。
【図２】マルチメディアコンテンツをストリーミングする伝送システムを示すブロック図。
【図３】エンコーダの機能の説明図。
【図４】マルチメディア取得クライアントの機能の説明図。
【図５ａ】本発明の好適な実施形態によるファイルフォーマットの説明図。
【図５ｂ】本発明の好適な実施形態によるファイルフォーマットの説明図。
【図６】プログレッシブ・ダウンローディングを示す信号伝送図。
【図１】
2005504480.tif 000003
【図３】
2005504480.tif 000004
【図４】
2005504480.tif 000005
【図５ａ】
2005504480.tif 000006
【図６】
2005504480.tif 000007
【国際公開パンフレット】
2005504480.tif 000008
2005504480.tif 000009
2005504480.tif 000010
2005504480.tif 000011
2005504480.tif 000012
2005504480.tif 000013
2005504480.tif 000014
2005504480.tif 000015
2005504480.tif 000016
2005504480.tif 000017
2005504480.tif 000018
2005504480.tif 000019
2005504480.tif 000020
2005504480.tif 000021
2005504480.tif 000022
2005504480.tif 000023
2005504480.tif 000024
2005504480.tif 000025
2005504480.tif 000026
2005504480.tif 000027
2005504480.tif 000028
2005504480.tif 000029
2005504480.tif 000030
2005504480.tif 000031
2005504480.tif 000032
2005504480.tif 000033
【国際調査報告】
2005504480.tif 000034
2005504480.tif 000035
2005504480.tif 000036