JP2015512188A - メディアファイルのファイルデータを提供する方法とシステム - Google Patents

Abstract

ファイルシステムは、番組の時間長を含む番組の詳細情報を受信する。番組の受信された詳細情報から所定の形式のメディアファイルのレイアウトを決定する。レイアウトはメディアファイル内のエッセンスデータ位置を含む。次に、ファイルレコードデータベース内にメディアファイルのファイルレコードが作成される。メディアファイル内のエッセンスデータの位置を求めるリクエストに応答して、メディアファイルの確定されたレイアウトによって与えられる位置が返される。さらに、番組のコンテンツに対応するエッセンスデータのストリームが受信され、受信されたエッセンスデータがデータストアに保存される。番組の時間に対応する、メディアファイルのエッセンスデータの一部を求めるリクエストに応答して、メディアファイルの確定されたレイアウトにしたがって、受信されたエッセンスデータに由来するエッセンスデータが戻される。【選択図】図３

Description

本発明は、メディアファイルのファイルデータを提供する方法とシステムに関する。本発明は、限定的ではないがより詳細には、ストリームから全エッセンスデータが取得される前にメディアファイルからエッセンスデータを提供できるように、エッセンスデータのストリームからメディアファイルを生成することに関する。

従来より、デジタルメディアデータは、ストリームとして配信されている。たとえば、ビデオデータは、データをストリーム配信するためのシリアルデジタルインターフェイス（ＳＤＩ）標準規格を使用して配信される。データのストリームの特徴は、データのストリームが、当該ストリームを構成しているデータへのシーケンシャルなアクセスを提供し、データの断片がストリームによって一旦提供されると、その断片を再度要求することができないことである。すなわち、ストリームは「メモリ」を有さない。メディアデータを送信するためのストリームの使用は、メディアデータがスポーツイベントまたはニュースイベントなどの実況イベントのものである場合に、特に適している。この場合、ストリームを構成するデータは、リアルタイムでの発生時のみ送信に利用することが可能である。

しかし、（他にもいろいろあるが特に）費用および利便性の理由により、メディアデータを、例えばＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）ファイル等のファイルとして提供することが望ましくなってきている。ファイルの特徴はランダムアクセスが可能なことである。ファイルシステム内でファイルを利用できるようになると、ファイルシステムに対して当該ファイル内のどの場所のどの任意データをもリクエストできる。

メディアデータを送信するためのファイルの用途の一例は、インターネットでのテレビ番組の送信である。これについて、図１を参照して以下に説明する。まず、番組に対応するファイルＴが提供される。次いでファイルＴはファイルＴ’に変換される。ファイルＴ’は、インターネットで送信するのに適したフォーマットのファイルである。この変換は、例えば、ファイルＴを別の形式および／または別の品質にトランスコードすることを伴う場合もある。ファイルの変換はバーＣで示される。

上述のように、番組をファイルＴとして提供するということは、ファイルＴ内のどのデータに対してもランダムアクセスを要求できることを意味する。したがって、変換プロセスＣは、変換プロセス開始前にファイルＴ全体がファイルシステム内で利用できることを期待する。ファイルＴ全体が利用可能であることを要求するということは、ファイルＴ全体が利用可能になったときのみ変換を開始でき、それは結局、そのファイルが表す番組が終了していなくてはならないことを意味するので、インターネットで送信するファイルＴ’の利用可能性に大きな時間オーバーヘッドを持ち込むことになる。これは番組がライブイベントのものであるときに特に問題である。この場合、ファイルＴを前もって入手することが不可能だからである。

時間オーバーヘッドを低減するための１つの部分的解決手段は、付加的な演算能力を提供することによって、変換処理Ｃにかかる時間を短縮することである。しかしながら、たとえ無制限の演算能力が利用可能であって、結果的に、変換に要する時間がゼロになるまで効果的に短縮されたとしても、番組が完成するまで待たなければならない必要性が依然として残る。

ファイル内のあらゆる場所からデータへのランダムアクセスが可能になる一方で、ファイルへの書き込みの完了を待つことに伴う遅延を回避するために、ファイルシステムは、一般的には、データの内容が依然としてファイルシステムに書き込まれている間にも、そして、たとえこのことが、ファイル全体がまだ利用可能ではないことを意味するとしても、ファイルからの当該データの読み出しを許容する。しかしながら、これには、２つの問題が存在する。第１には、ファイルシステムにまだ書き込まれていないファイルからのデータに対して要求がされる場合、ファイルシステムは、誤りデータ、たとえば空白パディングデータまたはガーベッジデータを返送する。第２には、ファイルのどのような部分にも書き込みができるということが、ファイルシステム内のファイルへの書き込みの特徴である。このことは、書き込みが進行中である間に、ファイルから以前に読み出されたデータが上書きされることを意味する。その結果として、既存のファイルシステムを用いると、ファイルがファイルシステムに完全に書き込まれる前に、ファイルからの読み出しを開始することは安全ではない。ファイルシステムへの完全な書き込みが終了するまでは、そのファイルから読み出されたいかなるデータも、正しいものであるとは信頼できない。

書き込みがまだ行われている間にも読み出されることが意図された、特化されたファイルフォーマットが知られている。このようなファイルは、データがそのセグメント内のどこにあるのかを表示するインデックスを各々が包含する、一連のセグメントから成る。したがって、データがファイルにシーケンシャルに書き込まれている場合、データは、ファイルのそれ以降の部分が参照される必要なく、シーケンシャルに読み出される。しかしながら、これらの使用は、ファイルの書き込みおよび読み出しの両方が、行儀の良い方法で行われることを必要とする。これは、当てにすることができない。さらに、既存のデバイスと、既存のデバイスが使用する標準規格ファイルフォーマットとの併用が可能な解決手段を提供することが有利であろう。

別の解決手段は、変換処理を履行するデバイスを、ファイルに対して動作するのではなくむしろ、ストリーム配信されるデータを受け入れることができるように変更することである。しかしながら、やはり、既存のデバイスと、既存のデバイスが使用する標準規格ファイルフォーマットとの併用が可能な解決手段を提供することが有利であろう。

米国特許出願公開第２００５／０２５４６０（Ａ１）

本発明は、上述の問題を軽減しようとするものである。これとは別に、および／または、これに追加して、本発明は、任意のファイルデータが提供可能となる前にファイル全体のコンテンツが利用可能であることを必要としない態様でメディアファイルのエッセンスデータを提供する改良型のファイルシステムを提供しようとするものである。

本発明の第１の実施態様によれば、ファイルレコードデータベースとデータストアとを備えるファイルシステムから、番組に対応しかつ所定のフォーマットのメディアファイルのファイルデータを提供する方法であって、
番組の継続時間を含む、番組の詳細を受信するステップと、
受信された番組の詳細から所定のフォーマットのメディアファイルのレイアウトを決定するステップであって、レイアウトはメディアファイル内のエッセンスデータの位置を含む、ステップと、
ファイルレコードデータベース内にメディアファイルのファイルレコードを作成するステップと、
メディアファイル内のエッセンスデータの位置を求める要求に応答して、決定されたメディアファイルのレイアウトによって与えられる位置を返送するステップと、
番組のコンテンツに対応するエッセンスデータのストリームを受信して、受信されたエッセンスデータをデータストアに保存するステップと、
番組の時間に対応する、メディアファイルのエッセンスデータの一部を求めるリクエストに応答して、決定されたメディアファイルのレイアウトにしたがって、受信されたエッセンスデータから得られるエッセンスデータを返送するステップと
を含む方法が提供される。

このファイルシステムは、番組の継続時間を使用してメディアファイルのレイアウト、特にメディアファイルの長さ、ならびに、メディアファイルに含めるデータをどのように構成するかを決定することができる。これによって、ファイルシステムは、メディアファイルのファイルレコードを作成できるようになる。また、エッセンスデータがまだ受信されていなくとも、エッセンスデータがファイル内で有するであろう位置の詳細を提供できるようになる。（したがって、例えば、所定のファイルフォーマットがファイル内のエッセンスデータの位置を示すインデックスを備えていれば、ファイルシステムは、エッセンスデータが利用可能となる前にファイルのインデックスを作成できる。）続いて、ストリームを介してエッセンスデータが受信されると、ファイルシステムは、それより後のエッセンスデータがまだ受信されていなくても、メディアファイルを構成するエッセンスデータを作成して返すことができる。

注目すべきことに、ファイルシステムがファイルのレイアウトを決定し、次いで、メディアファイルのコンテンツを作成する際に使用するためのエッセンスデータを受信すると、ファイルシステムは、ファイルのコンテンツに対する制御を維持する。このことは、ファイルがファイルシステムに書き込まれ、ファイルシステムが、ファイルの内部構造または受信しているデータが何を表しているか、データが受信される順序、または、何らかのデータが再度書き込まれたかどうか、に対する制御（またはその知識）を何ら有することなく、ファイルを構成するデータを単に受信するだけの従来のファイルシステムとは対照的である。

したがって、ファイルシステムが、あらゆる要求に応答して通常のファイルを提示し、その通常のファイルが（トランスコーダなどの）既存のデバイスと利用できるようにすることがわかる。しかし、ファイルシステムは、後続のコンテンツを生成するためのエッセンスデータを、たとえまだ有していない場合でも、要求されると、メディアファイルのコンテンツを確実に返送することができる。これは、通常のファイルシステムの書き込み動作を介して、すなわちファイルシステムの「外部」からファイルが供給されるのではなく、エッセンスデータからのファイルの作成が、エッセンスデータのストリームを使用して、ファイルシステムの「内部」で行われており、かつ、ファイルを読み出すいかなるデバイスにとってもわからないからである。こののように、従来のファイルシステムとは対照的に、別のデバイスがメディアファイルに含まれるデータの読み出しをできるようになる前に、メディアファイル全体が必ずしも利用可能になっている必要はない。
番組は、実況イベント、たとえば、スポーツイベントまたはニュースイベントの番組である。番組は、完了した放送イベントの一部のみ（たとえば、サッカーの試合の前半のみ）であってもよく、複数個の放送イベントを含んでもよく、テレビ局コマーシャルおよび広告などを含んでもよい。

メディアファイルのフォーマットには、ファイル内の予め宣言された位置にあるエッセンスデータの複数のセグメントが含まれている必要があり、メディアファイルのレイアウトを決定するステップは、
メディアファイルの必要とされるプロパティに基づいてメディアファイルの最大セグメント長を決定するステップと、
メディアファイル内のセグメントの位置を求めるリクエストに応答して、メディアファイルの各セグメントが最大セグメント長を有するように考慮して計算された位置を返送するステップと、
メディアファイルのセグメントのエッセンスデータを求めるリクエストに応答して、セグメントについて生成されたエッセンスデータを返送するステップであって、生成されたエッセンスデータが、受信されたエッセンスデータから得られるエッセンスデータと、生成されたエッセンスデータを最大セグメント長にするためのパディングデータを含む、ステップと
を含むことが好ましい。

これにより、各セグメントが含むことになるエッセンスデータに依存しない所定の長さを各セグメントが備えているので、ファイルを構成するエッセンスデータが利用可能となる前に、すなわち、各セグメント内のエッセンスデータのバイト長を知ることができる前に、そのようなフォーマットを備えたメディアファイルのレイアウトを決定できる。各セグメントは、所定の継続時間のメディアのセクションに対応するものであってもよい。最大セグメント長は、所定の継続時間のメディアのセクションに対応するファイルデータの少なくとも最大可能長としてもよい。最大セグメント長は、セグメントを構成するファイルデータの最小可能圧縮を推測することによって計算してもよい。

メディアファイルのフォーマットは、ＭＸＦであることが好ましい。しかし、フォーマットは、他の任意の好適なビデオフォーマットであってもよい。本発明は、ファイルのフォーマットが、圧縮ファイルフォーマット、たとえば、フレーム内圧縮またはＧＯＰ圧縮を用いるＭＰＥＧ−２またはＭＰＥＧ−４、フラグメント化ＭＰＥＧ−４、ＶＣ−１、Ａｐｐｌｅ ＰｒｏＲｅｓなどであるときに、特に有利であるが、ファイルのフォーマットが、非圧縮ファイルフォーマット、たとえば、Ｑｕｉｃｋｔｉｍｅ、非圧縮ＭＰＥＧ−４、ＡＶＩ、ＷＡＶなどであるときにも、同様に適用可能である。

本方法は、ファイルシステムによってエッセンスデータに提供される速度を変化させるために、要求されたエッセンスデータの返送を遅延させるステップを更に含むことが有利である。これは、構成されるメディアファイルからエッセンスデータを求める要求と、返されるエッセンスデータとの間における過度の遅延を回避することに役立ち、また要求がタイムアウトとなる可能性を回避するのに役立つ。

エッセンスデータの要求は、受信されたエッセンスデータから得られるエッセンスデータを順次要求するソフトウェアアプリケーションによって行われることが好ましい。そのような態様で動作するソフトウェアアプリケーションにより、ファイルシステムは、対応するエッセンスデータがストリームを介して受信されると、エッセンスデータを返すことができ、リクエストへの応答における過度の遅延が防止される。

本方法は、ソフトウェアアプリケーションがエッセンスデータを順次要求することになると判定するために、ソフトウェアアプリケーションの挙動を検討するステップを更に含むことが有利である。これにより、ファイルシステムと併用するのに適したソフトウェアアプリケーションを識別することが可能となる。

本発明の第２の実施態様によれば、ファイルレコードデータベースとデータストアとを備え、番組に対応する所定のフォーマットのメディアファイルのファイルデータを提供するファイルシステムであって、
番組の継続時間を含む番組の詳細報を受信すること、
受信された番組の詳細から所定のフォーマットのメディアファイルのレイアウトを決定することであって、レイアウトはメディアファイル内のエッセンスデータの位置を含む、メディアファイルのレイアウトを決定すること、
ファイルレコードデータベース内にメディアファイルのファイルレコードを作成すること、
メディアファイル内のエッセンスデータの位置を求める要求に応答して、決定されたメディアファイルのレイアウトによって与えられる位置を返送すること、
番組のコンテンツに対応するエッセンスデータのストリームを受信して、受信されたエッセンスデータをデータストアに保存すること、および
番組の時間に対応する、メディアファイルのエッセンスデータの一部を求める要求に応答して、決定されたメディアファイルのレイアウトにしたがって、その一部に対応する受信されたエッセンスデータから得られるエッセンスデータを返送すること、
を実行するように構成されたファイルシステムが提供される。

メディアファイルのフォーマットには、ファイル内の予め宣言された位置にあるエッセンスデータの複数のセグメントが含まれている必要があり、ファイルシステムは、メディアファイルのレイアウトを決定するときに、
メディアファイルの必要なプロパティに基づいてメディアファイルの最大セグメント長を決定すること、
メディアファイル内のセグメントの位置を求める要求に応答して、メディアファイルの各セグメントが最大セグメント長を有するように考慮して計算された位置を返送すること、および
メディアファイルのセグメントのエッセンスデータを求める要求に応答して、セグメントについて生成されたエッセンスデータを返送することであって、生成されたエッセンスデータが、受信されたエッセンスデータから得られるエッセンスデータおよび生成されたエッセンスデータを最大セグメント長にするためのパディングデータを含む、エッセンスデータを返送すること、
を実行するように構成されることが好ましい。

メディアファイルのフォーマットはＭＰＥＧ−４であることが好ましい。
ファイルシステムによってエッセンスデータに提供される速度を変化させるために、要求されたエッセンスデータの返送を遅延させるように更に構成されることが有利である。

本発明の第３の実施態様によれば、
上述のファイルシステムと、
ファイルシステムからメディアファイルを要求するように構成されているコンピュータデバイスであって、受信されたエッセンスデータから得られるエッセンスデータを順次要求するように構成されたコンピュータデバイスと
を備えるコンピュータネットワークが提供される。

本発明の第４の実施態様によれば、実行時に、上述のいずれか１つの方法のステップを実施するように構成されたコンピュータプログラムプロダクトが提供される。

本発明の第５の態様によれば、計算デバイス上で実行されるときに、上述のファイルシステムを提供するように構成されたコンピュータプログラムプロダクトが提供される。

当然のことながら、本発明の１つの実施態様に関連して記載された特徴が本発明の他の実施態様に組み込まれる場合もあることを理解されたい。例えば、本発明の装置を参照して記載されたいずれかの特徴を本発明の方法が組み込むこともできるし、その逆も可能である。

添付の概略図を参照しながら、単なる例として本発明の実施形態を以下に説明する。

インターネットでの送信用のメディアファイルを変換する従来の方法を表す図である。 本発明の第１の実施形態によるファイルシステムを含むネットワークである。 エッセンスデータのストリームからメディアファイルを生成するときの図２のファイルシステムの動作を示すフローチャートである。 図２のファイルシステムによって生成されるメディアファイルの構造を示す。 メディアファイルを求めるリクエストに応答する図２のファイルシステムの動作を示すフローチャートである。 図２のファイルシステムのインターネットでの送信用のメディアファイルを変換する方法を表す図である。

ここで本発明の第１の実施形態を、図２を参照して説明する。ファイルシステム１１は、データストア１２、ファイルレコードデータベース１３、およびゲートウェイ１４を備える。ファイルシステム１１は、ゲートウェイ１４を介してネットワーク１５と通信する。以下に詳述される“適任な” ソフトウェアアプリケーションを実行するデバイス１７は、ネットワーク１５を介してファイルシステム１１と通信する。

ゲートウェイ１４は、テレビ放映されたスポーツイベントなどの番組のエッセンスデータ（ビデオおよび／またはオーディオ情報を構成するデータ）のストリーム１６を受信するように構成されている。ファイルシステム１１は、以下に記載されるように、このエッセンスデータのストリーム１６を使用してメディアファイルを生成するように構成されている。

図３は、エッセンスデータのストリーム１６からメディアファイルを生成するときのファイルシステム１１の動作を示すフローチャートである。
番組の放送が開始する前に、ファイルシステム１１は、たとえば、番組の長さならびに生成されるファイルの品質およびフォーマットを含む、番組および生成されるファイルに関する詳細を受信する（ステップ４１）。
番組の放送が開始する前に、ファイルシステム１１は、たとえば、番組の長さ、ならびに、生成されるファイルの品質およびフォーマットを含む、番組および生成されるファイルに関する詳細を受信する（ステップ３１）。

次いで、ファイルシステム１１は、生成されるファイルの構造を決定するためにこの情報を使用する（ステップ３２）。ファイル構造の例が図４に示されている。ファイル構造４０はＭＸＦファイルのものであり、インデックス４１と複数のＧＯＰ（「ｇｒｏｕｐｓ ｏｆ ｐｉｃｔｕｒｅｓ（ピクチャの集合）」）４２ａ、４２ｂ、４２ｃ、４２ｄを備える。ＧＯＰは、特定の継続時間のビデオの特定のシーケンスを構成する一連の画像である。受信された詳細は、番組の長さを含み、ＧＯＰの数およびそれらの中のビデオの継続時間とを決定することができる。

ＧＯＰ内の画像は圧縮され、その結果、通常ＧＯＰは異なる長さを有するものとなる（すなわち、異なるバイト数で構成される）。この理由の１つは、ＧＯＰが表すビデオは、ビデオを構成する画像の性質に応じて、異なるサイズに圧縮されるためである。たとえば、圧縮技術が一連の画像間の差異を識別することを含むので、一連の非常に類似した画像は、実質的に互いに異なっている一連の画像よりも一段と小さなサイズに圧縮される。これは一般に、ファイル内のＧＯＰの位置が、先行する各ＧＯＰのサイズによって決まることを意味している。インデックス４１が、ファイル４０内でビデオの時間レンジからバイトレンジへのマッピングを行い、したがって、ビデオの特定の時間レンジに対応する１つのＧＯＰ（または複数のＧＯＰ）を見つけることが可能となる。

しかし、図４から、ファイル構造４０では、ＧＯＰ４２ａ〜４２ｄがすべて同サイズであることがわかる。これは、ファイルシステム１１に各ＧＯＰのサイズを予め設定させることによって達成される。（ＧＯＰを構成するエッセンスデータはストリーム１６からまだ受信されておらず、したがって、各ＧＯＰが含むであろう圧縮エッセンスデータの正確なサイズが決定不能であることに注意することが重要である。）各ＧＯＰのサイズは、ＧＯＰを構成する画像の最小可能圧縮、したがって最大可能バイト範囲を計算することによって、決定される。次いで構造内の各ＧＯＰの実際のサイズが、少なくともこの最大可能サイズであるものと解釈される。

次いで、ファイルシステム１１は、ファイルのファイルレコードを生成し、そのファイルレコードをファイルレコードデータベース１３に保存する（ステップ３３）。ファイルレコードは、直前のステップで決定されたファイルの構造から得られた、そのサイズなどのファイルに関する特定の詳細を含む。次に、決定されたファイルの構造を使用して、特に、ＧＯＰ４２ａ〜４２ｄの予め設定されたサイズを使用して、ファイルのインデックス４１が生成される（ステップ３４）。

ステップ３１で番組の詳細とファイルが受信されると、ファイルシステム１１はストリーム１６を介してエッセンスデータの受信を開始する（ステップ３５）。ファイルシステム１１は、エッセンスデータがファイルの予め設定された構造にしたがって圧縮されて各ＧＯＰに分配される状態において、そのデータを使用してＧＯＰのコンテンツを生成する（ステップ３６）。上述のように、いずれのＧＯＰの長さも、ＧＯＰ内の画像の少なくとも最小可能圧縮となるように決定される。当然のことながら、実際には、ほとんどの場合、画像は、最小可能サイズ未満に圧縮され、その場合、ＧＯＰ内の空きスペースは空白文字によるパディングデータで埋められる。

例えば、データがファイル内のどこにあるかを示す最初のインデックスおよび最後のフッターの両方をファイルが備えているフラグメント化ＭＰＥＧ−４形式など、他のファイルフォーマットのファイル構造も同様に決定できる。使用可能な他のファイルフォーマットとして、フレーム内圧縮またはＧＯＰ圧縮を使用するＭＰＥＧ−２またはＭＰＥＧ−４、ＶＣ−１、Ａｐｐｌｅ ＰｒｏＲｅｓなどの圧縮ファイル形式、ならびに、Ｑｕｉｃｋｔｉｍｅ、非圧縮ＭＰＥＧ−４、非圧縮ＡＶＩ、非圧縮ＷＡＶ等の非圧縮ファイル形式が挙げられる。

上記実施形態において、ファイルのインデックスおよびＧＯＰのコンテンツは、生成することが可能になるとすぐに生成される。すなわち、ファイルおよび番組の詳細が受信されると、インデックスが生成され、ストリーム１６内の要求されたエッセンスデータが受け取られると、すぐにＧＯＰのコンテンツが生成される。しかし、別の有利な実施形態において、インデックスおよびＧＯＰのコンテンツは、要求されたときにだけ生成される。例えば、実際にファイルが要求されたときにのみインデックスが生成されてもよく、また対応するファイルデータが要求されたときにのみＧＯＰのコンテンツが生成されてもよい。エッセンスデータは、ストリーム１６によって提供されると、とりあえずデータストア１２に保存される。

デバイス１７からの番組のファイルを求める要求に応答したファイルシステム１１の動作について、説明する。上述の通り、デバイス１７は、「適任の」ソフトウェアアプリケーションを稼動させている。適任のソフトウェアアプリケーションとは、以下で説明するように、ファイルを構成するデータに対し、特に予測可能であって行儀の良い態様でアクセスしているものと識別されたソフトウェアアプリケーションである。

上述のように、ファイルシステムの特徴は、ファイルへのランダムアクセスを可能にすることである。すなわち、ファイルのあらゆる任意のデータが要求され得る。しかし、発明者（ら）は、あるソフトウェアアプリケーションが、ファイルシステムによって提供されるランダムアクセスを利用せずに、むしろ予測可能な態様でファイルのデータにアクセスしていることを突き止めた。本発明に好適な、行儀の良い態様でファイルからデータを読み出しているものと識別されるソフトウェアアプリケーションは、いずれも「適任」であると考えられる。

本発明では、ソフトウェアアプリケーションがストリーム１６によって順次提供されるエッセンスデータに対応するファイルからのデータにアクセスする場合にのみ、ソフトウェアアプリケーションは適任となる。（これは、ソフトウェアアプリケーションが、それ以降のエッセンスデータに対応するファイルのデータにアクセスしないことを意味する。）したがって、たとえば最初にファイルのインデックスにアクセスして、その後、ファイルの最初から最後まで順番にＧＯＰのコンテンツを読み出すことによって、（インターネットを通じた送信に好適なフォーマットおよび品質にファイルを変換するために）、ファイルをトランスコードしたソフトウェアアプリケーションは適任となる。（インデックスをファイルの最初に置く必要はなく、ファイルの最後に置くこともでき、または、最初と最後の両方にインデックスがあってもよいことに注意されたい。）しかし、ソフトウェアアプリケーションは、適任であるために、それほど行儀の良いものである必要はない。すなわち、アプリケーションは、既に読み出されたインデックス、あるいは任意のＧＯＰの読み出しまたは再読み出しをいつでも行うことができ、また、ストリーム１６から対応するエッセンシャルデータを要求せずに、ＧＯＰデータの提供が可能である限り、ＧＯＰデータをファイルの最後から読み出すことさえできる。（したがって、たとえば、ファイルの最後から一般的なパディングデータが提供されることによって満たされたアプリケーションは、適任となり得る。）大切なのは、アプリケーションが、ファイル全体から順番にファイルデータを読み出すことではなく、実際には、ファイルインデックスがファイルの最後に置かれることは普通であり、その場合には、最後に対応するファイルデータが最初に読み出されることが期待される点に留意することが重要である。必要とされるのは、アプリケーションが、ファイルの後ろに格納されたエッセンスデータを順番に従わずに読み出そうと試みることによって、「飛び越し」をしないことである。

トランスコードは、ソフトウェアアプリケーションを結果的に適任とすることができるソフトウェアアプリケーションの機能の一例であり、本発明が、いかなる機能を有する適任のソフトウェアアプリケーションによるアクセスに等しく適用されるものであることを理解されたい。

同様に、あらゆるデバイス、ソフトウェアサービスなどが、適任のデバイス、適任のソフトウェアサービスなどであると考えられることを可能にする行儀の良い態様で、ファイルにアクセスしているものと識別される。

図５を参照して、適任のソフトウェアアプリケーション１７からのデータの要求に応答したファイルシステム１１の動作について説明する。まず最初に、ファイルシステム１１は、ファイルを読み出す要求を受信する（ステップ５１）。これを受けて、ファイルシステム１１は、ファイルレコードデータベース１３に格納されたファイルのファイルレコードにリンクされたファイルハンドルを返送する（ステップ５２）。

次に、デバイス１７上で稼働しているソフトウェアアプリケーションは、上記の行儀の良い態様で振舞い、ファイルシステム１１は、ファイルのインデックスに対応するファイルのデータを求める要求を受信し（ステップ５３）、ファイルシステム１１は、当該データをデバイス１７に返送する（ステップ７４）。このことが、ファイルのいずれかのエッセンスデータがストリーム１６によって提供されるる前に行うことができることがわかる。ファイル内のＧＯＰの位置が、その最大可能サイズに基づいて予め設定されるからであり、これにより、ＧＯＰを構成するエッセンスデータが既知になる前に、インデックスを生成することができる。これは、任意のＧＯＰの位置が先行する任意のＧＯＰに対する可能な圧縮によって決まり、したがって、全ＧＯＰが一旦生成されてからインデックスが漸く生成され、全エッセンスデータが利用可能であることを必要とする従来のシステムとは異なっている。

次に、ファイルシステム１１は、ＧＯＰを構成するデータを求める要求を受信し（ステップ５５）、ファイルシステム１１は、当該データを返送する（ステップ５６）。やはり、デバイス１７上で稼働するソフトウェアアプリケーションが行儀の良い態様で振舞うため、要求されたデータは、ファイル内の最初のＧＯＰに対応していることになる。これは、従来のシステムのように全ＧＯＰのエッセンスデータが利用可能である必要がなく、このＧＯＰのエッセンスデータがストリームによって提供されさえすれば、すぐにデータを返送できることを意味する。

ファイルシステム１１は、関連するエッセンスデータがストリーム１６によって提供されるとすぐに、ＧＯＰのデータを返送することが可能な状態において、次のＧＯＰのデータを求める要求を順に受信し、関連するデータを返送する（ステップ５５および５６が繰り返される）。

インデックスおよびＧＯＰデータが、要求されたときにのみ生成される代替の実施形態においては、ファイルシステム１１の動作がそれに応じて適応されることが認識されるであろう。

図６は、インターネットでテレビ番組を送信するためにファイルを使用する場合の本発明の効果を示す。従来のシステムとは異なり、バーＣで示される、ファイルＴからファイルＴ’への変換は、データが安全に読み出せるようになるのに先立って、ファイルＴ全体が利用可能となるまで変換を待機しなくてはならないのではなく、ファイル内のＧＯＰのエッセンスデータが利用可能になるとすぐに安全に開始できる。

この例の変換プロセスＣは、実際には従来例より時間がかかることがわかる。これはこの変換が、変換開始時にファイルＴ全体が利用可能となっている従来例のものではなく、ファイルＴのコンテンツが利用可能となるのに伴ってリアルタイムでしか行えないからである。しかし、それにもかかわらず、ファイルＴがまだ作成中であるうちに変換が開始するので、ファイルＴ’はファイルＴの完成直後に全体を利用できる。したがって、変換に要する時間を可能な限り短縮するために、付帯費用をかけて大量の計算力を使う理由がないことを意味するので、この変換速度は欠点ではなく、実際には利点となる。

ファイルシステム１１は、対応するエッセンスデータが受信されるとほぼ即座にＧＯＰを返すことができることを理解されたい。特に、エッセンスデータのストリームが均一な速度で受信されない場合、デバイス１７の挙動として、ファイルシステム１１による対応するエッセンスデータの受信に実質的に先立ってＧＯＰのリクエストが行われるようになっている場合がある。これがＧＯＰの要求のタイムアウトを招くことがあり、すなわち、最大許容時間内にＧＯＰを構成するデータが返されないこととなる。これを回避するために、ファイルシステム１１は先行するＧＯＰの返送を遅らせることができる。これにより、デバイス１７によってなされる未来のリクエストを順々に遅らせることになり、したがって、要求がなされてから十分に短い時間内で要求されたエッセンスデータが受信されるようにし、それによって、そのようなタイムアウトが生じないことを保証する（または保証しようとする）。

本発明は特定の実施形態を参照しながら記載され説明されているが、本発明は本明細書に具体的に説明されていない数多くの種々の変更形態に適していることが当業者には理解されよう。

Claims (13)

1. ファイルレコードデータベースとデータストアとを備えるファイルシステムから、番組に対応し且つ所定のフォーマットのメディアファイルのファイルデータを提供する方法であって、
   前記番組の継続時間を含む前記番組の詳細を受信するステップと、
   前記受信された番組の詳細から前記所定のフォーマットの前記メディアファイルのレイアウトを決定するステップであって、前記レイアウトは前記メディアファイル内のエッセンスデータの位置を含む、ステップと、
   前記ファイルレコードデータベース内に前記メディアファイルのファイルレコードを作成するステップと、
   前記メディアファイル内のエッセンスデータの位置を求める要求に応答して、前記決定されたメディアファイルのレイアウトによって与えられる位置を返送するステップと、
   前記番組のコンテンツに対応するエッセンスデータのストリームを受信して、前記受信されたエッセンスデータを前記データストアに保存するステップと、
   前記番組の時間に対応する、前記メディアファイルのエッセンスデータの一部を求める要求に応答して、前記決定されたメディアファイルのレイアウトにしたがって、前記受信されたエッセンスデータから得られるエッセンスデータを返送するステップと
   を含む方法。
2. 前記メディアファイルの前記フォーマットでは、前記メディアファイルが前記メディアファイル内の予め宣言された位置にある複数のエッセンスデータのセグメントを備えている必要があり、
   前記メディアファイルのレイアウトを決定するステップが、
   前記メディアファイルの前記必要なプロパティに基づいて前記メディアファイルの最大セグメント長を決定するステップと、
   前記メディアファイル内のセグメントの位置を求める要求に応答して、前記メディアファイルの各セグメントが前記最大セグメント長を有するようにして計算された位置を返送するステップと、
   前記メディアファイルのセグメントのエッセンスデータを求める要求に応答して、前記セグメントについて生成されたエッセンスデータを返送するステップであって、前記生成されたエッセンスデータが、前記受信されたエッセンスデータから得られる前記エッセンスデータと、前記生成されたエッセンスデータを前記最大セグメント長にするためのパディングデータとを含む、ステップと
   を含む、
   請求項１に記載の方法。
3. 前記メディアファイルの前記形式がＭＸＦである、請求項２に記載の方法。
4. 前記ファイルシステムによってエッセンスデータが提供される速度を変化させるために、前記要求されたエッセンスデータの前記返送を遅らせるステップを更に含む、請求項１から３のいずれか一項に記載の方法。
5. 前記エッセンスデータの要求が、前記受信されたエッセンスデータから得られるエッセンスデータを順次要求するソフトウェアアプリケーションによって行われる、請求項１から４のいずれか一項に記載の方法。
6. 前記ソフトウェアアプリケーションが前記エッセンスデータを順次要求することになると判定するために前記ソフトウェアアプリケーションの挙動を検討するステップを更に含む、請求項５に記載の方法。
7. ファイルレコードデータベースとデータストアとを備え、番組に対応する所定のフォーマットのメディアファイルのファイルデータを提供するファイルシステムであって、
   前記番組の継続時間を含む前記番組の詳細を受信すること、
   前記受信された番組の詳細から前記所定のフォーマットの前記メディアファイルのレイアウトを決定することであって、前記レイアウトは前記メディアファイル内のエッセンスデータの位置を含む、レイアウトを決定すること、
   前記ファイルレコードデータベース内に前記メディアファイルのファイルレコードを作成すること、
   前記メディアファイル内のエッセンスデータの位置を求める要求に応答して、前記決定されたメディアファイルのレイアウトによって与えられる位置を返送すること、
   前記番組のコンテンツに対応するエッセンスデータのストリームを受信して、前記受信されたエッセンスデータを前記データストアに保存すること、および
   前記番組の時間に対応する、前記メディアファイルのエッセンスデータの一部を求める要求に応答して、前記決定されたメディアファイルのレイアウトにしたがって、前記一部に対応する前記受信されたエッセンスデータから得られるエッセンスデータを返送すること、
   を行うように構成されたファイルシステム。
8. 前記メディアファイルの前記フォーマットでは、前記メディアファイルが前記メディアファイル内の予め宣言された位置にある複数のエッセンスデータのセグメントを備えている必要があり、
   前記ファイルシステムは、前記メディアファイルの前記レイアウトが決定されるときに、
   前記メディアファイルの必要なプロパティに基づいて前記メディアファイルの最大セグメント長を決定すること、
   前記メディアファイル内のセグメントの位置を求める要求に応答して、前記メディアファイルの各セグメントが前記最大セグメント長を有するようにして計算された位置を返送すること、および
   前記メディアファイルのセグメントのエッセンスデータを求める要求に応答して、前記セグメントについて生成されたエッセンスデータを返送することであって、前記生成されたエッセンスデータが、前記受信されたエッセンスデータから得られる前記エッセンスデータと、前記生成されたエッセンスデータを前記最大セグメント長にするためのパディングデータを含む、エッセンスデータを返送すること、
   を行うように構成された、
   請求項７に記載のファイルシステム。
9. 前記メディアファイルの前記形式がＭＸＦである、請求項８に記載のファイルシステム。
10. 前記ファイルシステムによってエッセンスデータが提供される速度を変化させるために、前記要求されたエッセンスデータの前記返送を遅らせるように更に構成された、請求項７から９のいずれか一項に記載のファイルシステム。
11. 請求項７から１０のいずれか一項に記載のファイルシステムと、
    前記ファイルシステムからメディアファイルを要求するように構成されたコンピュータデバイスと
    を備え、
    前記コンピュータデバイスは、受信されたエッセンスデータから得られるエッセンスデータを順次要求するように構成された、
    コンピュータネットワーク。
12. 実行時に、請求項１から６記載のいずれか１つの方法のステップを実施するように構成されたコンピュータプログラムプロダクト。
13. デバイス上で実行されるときに、請求項７から１０のいずれか一項に記載のファイルシステムを提供するように構成されたコンピュータプログラムプロダクト。

Images