(57)【要約】  ファイルシステムは、番組の継続時間を含む番組の詳細を受信する。受信された番組の詳細から、所定のフォーマットにおけるメディアファイルのレイアウトを決定する。レイアウトは、ファイル内のエッセンスデータの位置を含む。ファイルレコードデータベース内において、メディアファイルのファイルレコードが作成される。ファイル内のエッセンスデータの位置を求める要求に応答して、決定されたメディアファイルのレイアウトによって与えられた位置が返送される。さらに、セグメントが番組に含まれるべきであるという命令に応答して、セグメントの内容に対応するエッセンスデータが取得される。次に、番組の時間に対応するメディアファイルのエッセンスデータの一部を求める要求に応答して、決定されたメディアファイルのレイアウトに従って、受信されたエッセンスデータから得られたエッセンスデータが返送される。【選択図】図３
2015510727.tif 000002
【特許請求の範囲】
【請求項１】
ファイルレコードデータベースおよびデータストアを備えるファイルシステムから、所定のフォーマットのメディアファイルのファイルデータを提供する方法であって、前記メディアファイルが、複数のセグメントから成る番組に対応しており、前記番組に含まれる前記セグメントが動的に決定される方法において、
前記番組の継続時間を含む、前記番組の詳細を受信するステップと、
前記受信された番組の詳細から、前記所定のフォーマットにおける前記メディアファイルのレイアウトを決定するステップであって、前記レイアウトが、前記ファイル内のエッセンスデータについての位置を含む、前記メディアファイルのレイアウトを決定するステップと、
前記メディアファイルのファイルレコードを前記ファイルレコードデータベース内に作成するステップと、
前記ファイル内のエッセンスデータの前記位置を求める要求に応答して、前記決定されたメディアファイルのレイアウトによって与えられた位置を返送するステップと、
セグメントが前記番組に含まれるべきであるという命令に応答して、前記セグメントのコンテンツに対応するエッセンスデータを取得するステップと、
前記番組の時間に対応する前記メディアファイルからのエッセンスデータの一部を求める要求に応答して、前記決定されたメディアファイルのレイアウトに従って、前記受信されたエッセンスデータから得られたエッセンスデータを返送するステップと
を含む、方法。
【請求項２】
前記メディアファイルの前記フォーマットが、前記ファイル内の予め宣言された位置にあるエッセンスデータの複数のセグメントを前記メディアファイルが備えていることを必要とし、前記メディアファイルの前記レイアウトを決定する前記ステップが、
前記メディアファイルの必要とされるプロパティに基づき、前記ファイルについての最大セグメント長を決定するステップと、
前記ファイル内のセグメントの位置を求める要求に応答して、前記メディアファイルの各セグメントが前記最大セグメント長を有するようにして計算された位置を返送するステップと、
前記メディアファイルのセグメントからのエッセンスデータを求める要求に応答して、前記セグメントの生成されたエッセンスデータを返送するステップであって、前記生成されたエッセンスデータが、前記受信されたエッセンスデータから得られた前記エッセンスデータと、前記生成されたエッセンスデータに前記最大セグメント長を与えるパディングデータとを備える、生成されたエッセンスデータを返送するステップと
を含む、請求項１に記載の方法。
【請求項３】
前記メディアファイルの前記フォーマットがＭＸＦである、請求項２に記載の方法。
【請求項４】
前記ファイルシステムによってエッセンスデータに提供される速度を変化させるために、要求されたファイルデータの前記返送を遅延させるステップをさらに含む、請求項１から３のいずれかに記載の方法。
【請求項５】
エッセンスデータを求める前記要求が、前記受信されたエッセンスデータから得られたエッセンスデータをシーケンシャルに要求するソフトウェアアプリケーションによって行われる、請求項１から４のいずれかに記載の方法。
【請求項６】
前記ソフトウェアアプリケーションが前記エッセンスデータをシーケンシャルに要求すると判定するために、前記ソフトウェアアプリケーションの挙動を検討するステップをさらに含む、請求項５に記載の方法。
【請求項７】
セグメントが前記番組に含まれるべきであるという前記命令が、前記セグメントの継続時間を含み、前記セグメントの前記生成されたエッセンスデータが、前記受信されたエッセンスデータのフレームを削除、複製、および／または補間することによって、前記受信されたエッセンスデータから得られる、請求項１から６のいずれかに記載の方法。
【請求項８】
所定のフォーマットのメディアファイルのファイルデータを提供するためのファイルシステムであって、前記ファイルシステムが、ファイルレコードデータベースおよびデータストアを備え、前記メディアファイルが、複数のセグメントから成る番組に対応しており、前記番組に含まれる前記セグメントが動的に決定されるファイルシステムにおいて、
前記番組の継続時間を含む、前記番組の詳細を受信することと、
前記受信された番組の詳細から、前記所定のフォーマットにおける前記メディアファイルのレイアウトを決定することであって、前記レイアウトが、前記ファイル内のエッセンスデータについての位置を含む、前記メディアファイルのレイアウトを決定することと、
前記メディアファイルについてのファイル記録を前記ファイル記録データベース内に作成することと、
前記ファイル内のエッセンスデータの前記位置を求める要求に応答して、前記決定されたメディアファイルのレイアウトによって与えられた位置を返送することと、
セグメントが前記番組に含まれるべきであるという命令に応答して、前記セグメントのコンテンツに対応するエッセンスデータを取得することと、
前記番組の時間期間に対応する前記メディアファイルからのエッセンスデータの一部を求める要求に応答して、前記決定されたメディアファイルのレイアウトに従って、前記一部に対応する、前記受信されたエッセンスデータから得られたエッセンスデータを返送することと
を行うように構成された、ファイルシステム。
【請求項９】
前記メディアファイルの前記フォーマットが、前記ファイル内の予め宣言された位置にあるエッセンスデータの複数のセグメントを前記メディアファイルが備えていることを必要とし、前記ファイルシステムが、前記メディアファイルの前記レイアウトを決定するときに、
前記メディアファイルの必要とされるプロパティに基づき、前記ファイルについての最大セグメント長を決定することと、
前記ファイル内のセグメントの位置を求める要求に応答して、前記メディアファイルの各セグメントが前記最大セグメント長を有するようにして計算された位置を返送することと、
前記メディアファイルのセグメントからのエッセンスデータを求める要求に応答して、前記セグメントの生成されたエッセンスデータを返送することであって、前記生成されたエッセンスデータが、前記受信されたエッセンスデータから得られた前記エッセンスデータと、前記生成されたエッセンスデータに前記最大セグメント長を与えるパディングデータとを備える、生成されたエッセンスデータを返送することと
を行うように構成された、請求項８に記載のファイルシステム。
【請求項１０】
前記メディアファイルの前記フォーマットがＭＸＦである、請求項９に記載のファイルシステム。
【請求項１１】
前記ファイルシステムによってエッセンスデータに提供される速度を変化させるために、要求されたファイルデータの前記返送を遅延させるようにさらに構成された、請求項８から１０のいずれかに記載のファイルシステム。
【請求項１２】
セグメントが前記番組に含まれるべきであるという前記命令が、前記セグメントの継続時間を含み、前記セグメントの前記生成されたエッセンスデータが、前記受信されたエッセンスデータのフレームを削除、複製、および／または補間することによって、前記受信されたエッセンスデータから得られる、請求項８から１１のいずれかに記載のファイルシステム。
【請求項１３】
コンピュータネットワークであって、
請求項８から１２のいずれかに記載のファイルシステムと、
前記ファイルシステムに前記メディアファイルを要求するように構成されたコンピュータデバイスと
を備え、
前記コンピュータデバイスが、前記受信されたエッセンスデータから導出されたエッセンスデータをシーケンシャルに要求するように構成された、
コンピュータネットワーク。
【請求項１４】
実行されると、請求項１から７の方法のいずれかの、ステップを実施するように構成された、コンピュータプログラムプロダクト。
【請求項１５】
コンピューティングデバイス上で実行されると、請求項８から１２のいずれかに記載されたファイルシステムを提供するように構成された、コンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアファイル用のファイルデータを提供するための方法およびシステムに関する。より詳細には、それだけには限らないが、本発明は、メディアファイルからのエッセンスデータを番組全体の内容が確定される前に提供できるような方式で、番組用のメディアファイルを生成することに関する。
【背景技術】
【０００２】
従来より、デジタルメディアデータは、ストリームとして配信されている。たとえば、ビデオデータは、データをストリーム配信するためのシリアルデジタルインターフェイス（ＳＤＩ）標準規格を使用して配信される。データのストリームの特徴は、データのストリームが、当該ストリームを構成しているデータへのシーケンシャルなアクセスを提供し、データの断片がストリームによって一旦提供されると、その断片を再度要求することができないことである。すなわち、ストリームは「メモリ」を有さない。メディアデータを送信するためのストリームの使用は、メディアデータがスポーツイベントまたはニュースイベントなどの実況イベントのものである場合に、特に適している。この場合、ストリームを構成するデータは、リアルタイムでの発生時のみ送信に利用することが可能である。
【０００３】
ニュース番組などの番組の内容は、番組が放送されるのに伴って動的に決定されるのが通例である。図１には、ニュース番組を制作するための従来のシステムが示されている。ユーザインターフェイスデバイス１１は、ニュース番組についての放映順序１１ａをユーザが制御することを可能にする。放映順序１１ａは、カメラ１３ａ〜１３ｂによって提供された（たとえばニュースが読まれている）実況映像と、データストア１２ａ〜１２ｃによって提供される録画済のクリップ、広告用中断などを含む、一連のセグメントである。ユーザインターフェイス１１は、（新たに突発したニュース事件やライブ映像に関する問題などの）起こり得るイベントを考慮して、まだ放送されていないセグメントに対し、必要に応じて、たとえば並べ替え、削除、または追加を行うことによって、番組が放送されるのに伴い放映順序を変更させるために使用される。また、ユーザインターフェイス１１は、たとえば、スポーツの試合の重要な部分のスローモーション再生を示すときに使用されるように、ジョグ／シャトルダイヤルを介して映像の表示を直接操作するためにも使用される。ニュース番組用のメディアデータは、ストリーム１４として提供される。
【０００４】
しかしながら、メディアデータは従来よりストリームとして配信されてきたが、（とりわけ）コストおよび便宜上の理由により、それをファイルとして、たとえばＭＸＦ（Ｍａｔｅｒｉａｌ  ｅＸｃｈａｎｇｅ  Ｆｏｒｍａｔ、マテリアルエクスチェンジフォーマット）ファイルとして、提供することが望ましくなっている。ファイルの特徴は、ランダムアクセスを可能にする点である。すなわち、ファイルがファイルシステム内で一旦利用可能になると、ファイル内のあらゆる場所からのデータの、あらゆる任意の断片を求める要求がファイルシステムに対して行われるというものである。
【０００５】
メディアデータを送信するためのファイルの使用の一例が、インターネットを通じたテレビ番組の送信である。このことについて、図２を参照して説明する。まず、セグメントＳ１〜Ｓｎを備える番組に対応するファイルが提供される。次いで、このファイルは、インターネットを通じた送信に好適な形式のファイルである、変換されたセグメントＳ’１〜Ｓ’ｎを備えるファイルに変換される。このことは、たとえば、ファイルを異なるフォーマットおよび／または品質にトランスコードすることを包含している。ファイルの変換は、バーＣによって表示される。
【０００６】
上で述べた通り、ファイルとして番組を提供することは、ファイル内のデータのあらゆる断片へのランダムアクセスが必要とされることを意味する。その結果、変換処理Ｃは、変換処理の開始前に、ファイルの全セグメントＳ１〜Ｓｎをファイルシステム内において利用可能であることを要求する。ファイル全体の利用可能性を必要とするということは、インターネットを通じた送信用に変換されるファイルの利用可能性に対し、多大な時間オーバーヘッドを招く。その理由は、未変換のファイル全体が一旦利用可能になってから、変換が漸く開始するためである。その結果、ファイルが表す番組が完成していなくてはならない。番組が放送されている間に、番組についての放映順序が変動する可能性があり、番組の内容が放送されるまで固定されない。したがって、未変換のファイルを前もって取得することが不可能である。これは、ニュース番組などの番組において、特に問題である。
【０００７】
時間オーバーヘッドを低減するための１つの部分的解決手段は、付加的な演算能力を提供することによって、変換処理Ｃにかかる時間を短縮することである。しかしながら、たとえ無制限の演算能力が利用可能であって、結果的に、変換に要する時間がゼロになるまで効果的に短縮されたとしても、番組が完成するまで待たなければならない必要性が依然として残る。
【０００８】
ファイル内のあらゆる場所からデータへのランダムアクセスが可能になる一方で、ファイルへの書き込みの完了を待つことに伴う遅延を回避するために、ファイルシステムは、一般的には、データの内容が依然としてファイルシステムに書き込まれている間にも、そして、たとえこのことが、ファイル全体がまだ利用可能ではないことを意味するとしても、ファイルからの当該データの読み出しを許容する。しかしながら、これには、２つの問題が存在する。第１には、ファイルシステムにまだ書き込まれていないファイルからのデータに対して要求がされる場合、ファイルシステムは、誤りデータ、たとえば空白パディングデータまたはガーベッジデータを返送する。第２には、ファイルのどのような部分にも書き込みができるということが、ファイルシステム内のファイルへの書き込みの特徴である。このことは、書き込みが進行中である間に、ファイルから以前に読み出されたデータが上書きされることを意味する。その結果として、既存のファイルシステムを用いると、ファイルがファイルシステムに完全に書き込まれる前に、ファイルからの読み出しを開始することは安全ではない。ファイルシステムへの完全な書き込みが終了するまでは、そのファイルから読み出されたいかなるデータも、正しいものであるとは信頼できない。
【０００９】
書き込みがまだ行われている間にも読み出されることが意図された、特化されたファイルフォーマットが知られている。このようなファイルは、データがそのセグメント内のどこにあるのかを表示するインデックスを各々が包含する、一連のセグメントから成る。したがって、データがファイルにシーケンシャルに書き込まれている場合、データは、ファイルのそれ以降の部分が参照される必要なく、シーケンシャルに読み出される。しかしながら、これらの使用は、ファイルの書き込みおよび読み出しの両方が、行儀の良い方法で行われることを必要とする。これは、当てにすることができない。さらに、既存のデバイスと、既存のデバイスが使用する標準規格ファイルフォーマットとの併用が可能な解決手段を提供することが有利であろう。
【００１０】
別の解決手段は、変換処理を履行するデバイスを、ファイルに対して動作するのではなくむしろ、ストリーム配信されるデータを受け入れることができるように変更することである。しかしながら、やはり、既存のデバイスと、既存のデバイスが使用する標準規格ファイルフォーマットとの併用が可能な解決手段を提供することが有利であろう。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】米国特許出願公開第２００５／０２５４６０（Ａ１）
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明は、上述の問題を緩和することを企図する。代替的におよび／または加えて、本発明は、いかなるファイルデータが提供される前にも、ファイル全体の内容が決定されることを必要としない方式で、メディアファイル用のファイルデータを提供する、改善されたファイルシステムを提供することを企図する。
【課題を解決するための手段】
【００１３】
本発明の第１の実施態様によると、ファイル記録データベースおよびデータストアを備えるファイルシステムから、所定のフォーマットのメディアファイル用のファイルデータを提供する方法であって、メディアファイルが、複数のセグメントから成る番組に対応しており、番組に含まれるセグメントが動的に決定される方法において、
番組の継続時間を含む、番組の詳細を受信するステップと、
受信された番組の詳細から、所定のフォーマットにおけるメディアファイルのレイアウトを決定するステップであって、レイアウトが、ファイル内のエッセンスデータについての位置を含む、メディアファイルのレイアウトを決定するステップと、
メディアファイルのファイルレコードをファイルレコードデータベース内に作成するステップと、
ファイル内のエッセンスデータの位置を求める要求に応答して、決定されたメディアファイルのレイアウトによって与えられた位置を返送するステップと、
セグメントが番組に含まれるべきであるという命令に応答して、セグメントのコンテンツに対応するエッセンスデータを取得するステップと、
番組の時間に対応するメディアファイルからのエッセンスデータの一部を求める要求に応答して、決定されたメディアファイルのレイアウトに従って、受信されたエッセンスデータから得られたエッセンスデータを返送するステップと
を含む方法が提供される。
【００１４】
ファイルシステムは、番組の継続時間を使用して、メディアファイルのレイアウト、特に、メディアファイルの長さと、メディアファイルに含めるデータがどのように配列されるのかを決定することができる。これによって、ファイルシステムが、メディアファイルのファイルレコードを作成すること、および、エッセンスデータがファイル内で有することになる位置の詳細を、たとえそのエッセンスデータがまだ受信されていなくても提供できるようになる。（したがって、たとえば、所定のファイルフォーマットがファイル内におけるエッセンスデータの位置を示すインデックスを有する場合、ファイルシステムは、エッセンスデータが利用可能になる前に、ファイルのインデックスを作成することができる。）次いで、番組がどのセグメントを含むべきであるのかを示す命令が受信されると、それ以降のセグメントがまだ未知であるために、それ以降のセグメントについてのエッセンスデータがまだ取得されていない場合でも、ファイルシステムは、必要とされるエッセンスデータを取得し、対応するファイルデータであって、メディアファイルを構成するファイルデータを作成して返送することができる。
【００１５】
注目すべきことに、ファイルシステムがファイルのレイアウトを決定し、次いで、メディアファイルのコンテンツを作成する際に使用するためのエッセンスデータを受信すると、ファイルシステムは、ファイルのコンテンツに対する制御を維持する。このことは、ファイルがファイルシステムに書き込まれ、ファイルシステムが、ファイルの内部構造または受信しているデータが何を表しているか、データが受信される順序、または、何らかのデータが再度書き込まれたかどうか、に対する制御（またはその知識）を何ら有することなく、ファイルを構成するデータを単に受信するだけの従来のファイルシステムとは対照的である。
【００１６】
したがって、ファイルシステムが、あらゆる要求に応答して通常のファイルを提示し、その通常のファイルが（トランスコーダなどの）既存のデバイスと利用できるようにすることがわかる。しかし、ファイルシステムは、後続のコンテンツを生成するためのエッセンスデータを、たとえまだ有していない場合でも、要求されると、メディアファイルのコンテンツを確実に返送することができる。これは、通常のファイルシステムの書き込み動作を介して、すなわちファイルシステムの「外部」からファイルが供給されるのではなく、エッセンスデータからのファイルの作成が、エッセンスデータのストリームを使用して、ファイルシステムの「内部」で行われており、かつ、ファイルを読み出すいかなるデバイスにとってもわからないからである。こののように、従来のファイルシステムとは対照的に、別のデバイスがメディアファイルに含まれるデータの読み出しをできるようになる前に、メディアファイル全体が必ずしも利用可能になっている必要はない。
【００１７】
さらに、たとえ番組の内容が動的に決定される場合でも、番組用のメディアデータは有利にも、ストリームとして提供される必要はなく、より簡単かつ安価になる。また、たとえば、セグメントがライブ映像ではなく、むしろ録画されたクリップに関していると、セグメントについてのエッセンスデータが全面的に利用可能である場合、メディアファイルの対応するファイルデータが直ちに返送され、ストリーム配信されることを待つ必要がないという格別の利点を有する。
【００１８】
番組に含まれるべきセグメントに関する命令は、ユーザインターフェイスデバイスによって提供される。ユーザインターフェイスデバイスは、番組についての放映順序をユーザが操作することを可能にする。ユーザインターフェイスデバイスは、番組にまだ含まれていない、放映順序内のセグメントに対してのみ、ユーザが変更を行うことを許容する。そうでなければ、放映順序は、放送される番組のコンテンツに合致しないことになってしまう。
【００１９】
代替的に、番組に含まれるべきセグメントに関する命令は、たとえばソフトウェアアプリケーションによって、自動的に提供される。たとえば、番組の放送中におけるユーザ入力を用いることなく、番組内の全ての広告を変更または除去することによって、番組のセグメントを変更させてもよい。
【００２０】
番組は、実況イベント、たとえば、スポーツイベントまたはニュースイベントの番組である。番組は、完了した放送イベントの一部のみ（たとえば、サッカーの試合の前半のみ）であってもよく、複数個の放送イベントを含んでもよく、テレビ局コマーシャルおよび広告などを含んでもよい。
【００２１】
好ましくは、メディアファイルのフォーマットは、ファイル内の予め宣言された位置にあるエッセンスデータの複数のセグメントを含んでいることを必要とし、メディアファイルのレイアウトを決定するステップは、
メディアファイルの必要なプロパティに基づいて、メディアファイルの最大セグメント長を決定するステップと、
メディアファイル内のセグメントの位置を求める要求に応答して、メディアファイルの各セグメントが最大セグメント長を有するようにして計算された位置を返送するステップと、
メディアファイルのセグメントからのエッセンスデータを求める要求に応答して、セグメントについて生成されたエッセンスデータを返送するステップであって、生成されたエッセンスデータが、受信されたエッセンスデータから得られたエッセンスデータと、生成されたエッセンスデータを最大セグメント長にするためのパディングデータとを含む、生成されたエッセンスデータを返送するステップと
を含む。
【００２２】
このようなフォーマットを有するメディアファイルのレイアウトは、ファイルを構成するエッセンスデータが利用可能になる前に、したがって、各セグメント内のエッセンスデータのバイト長が既知となる前に、決定することができる。その理由は、各セグメントが、セグメントが含むエッセンスデータに依存しない所定の長さを有するためである。各セグメントは、所定の継続時間のメディアのセクションに対応するものであってもよい。最大セグメント長は、所定の継続時間のメディアのセクションに対応するファイルデータの少なくとも最大可能長さとしてもよい。最大セグメント長は、セグメントを構成するファイルデータの最小可能圧縮を推測することによって計算してもよい。
【００２３】
メディアファイルのフォーマットは、ＭＸＦであることが好ましい。しかし、フォーマットは、他の任意の好適なビデオフォーマットであってもよい。本発明は、ファイルのフォーマットが、圧縮ファイルフォーマット、たとえば、フレーム内圧縮またはＧＯＰ圧縮を用いるＭＰＥＧ−２またはＭＰＥＧ−４、フラグメント化ＭＰＥＧ−４、ＶＣ−１、Ａｐｐｌｅ  ＰｒｏＲｅｓなどであるときに、特に有利であるが、ファイルのフォーマットが、非圧縮ファイルフォーマット、たとえば、Ｑｕｉｃｋｔｉｍｅ、非圧縮ＭＰＥＧ−４、ＡＶＩ、ＷＡＶなどであるときにも、同様に適用可能である。
【００２４】
この方法は、ファイルシステムによってエッセンスデータに提供される速度を変化させるために、要求されたエッセンスデータの返送を遅延させるステップをさらに含む。メディアファイルからのエッセンスデータを求める要求が行われることとエッセンスデータが返送されることの間における過剰な遅延を回避することに役立ち、要求がタイムアウトになる可能性を回避するのに役立つ。
【００２５】
データを求める要求は、受信されたエッセンスデータから得られたエッセンスデータをシーケンシャルに要求するソフトウェアアプリケーションによって行われるのが好ましい。このような態様で作動するソフトウェアアプリケーションは、対応するエッセンスデータがストリームを介して受信されるのに伴い、ファイルシステムがエッセンスデータを返送することを実現し、要求に応答する際における過剰な遅延を防止する。
【００２６】
この方法は、ソフトウェアアプリケーションがエッセンスデータをシーケンシャルに要求すると判定するために、ソフトウェアアプリケーションの挙動を検討するステップをさらに含む。これにより、ファイルシステムと併用するのに好適なソフトウェアアプリケーションを識別できるようになる。
【００２７】
セグメントが番組に含まれるべきであるという命令は、セグメントの継続時間を含み、セグメントについて生成されたエッセンスデータは、受信されたエッセンスデータのフレームを削除、複製、および／または補間することによって、受信されたエッセンスデータから得られるのが好ましい。これは、たとえば、ユーザがジョグ／シャトルダイヤルを使用して映像の表示を操作することによって、セグメントのコンテンツが規定される場合、得られたエッセンスデータは、取得されたエッセンスデータから効率的に生成されることを意味する。たとえば、操作された映像が、一部がスローモーションで繰り返されるか、または再生される（この場合、各フレームは、スローモーション効果を達成するために、１回または複数回繰り返される）ので、同じフレームの複数個のコピーを含む場合、フレームが繰り返されるエッセンスデータのストリームが制作される従来のシステムとは対照的に、エッセンスデータの必要とされるフレームを１度だけ取得する必要がある。
【００２８】
この発明の第２の実施態様によると、所定のフォーマットのメディアファイルのファイルデータを提供するためのファイルシステムであって、ファイルシステムは、ファイルレコードデータベースおよびデータストアを備え、メディアファイルが、複数のセグメントから成る番組に対応しており、番組に含まれるセグメントが動的に決定されるファイルシステムにおいて、
番組の継続時間を含む、番組の詳細を受信することと、
受信された番組の詳細から、所定のフォーマットにおけるメディアファイルのレイアウトを決定することであって、ファイル内のエッセンスデータについての位置を含むメディアファイルのレイアウトを決定することと、
メディアファイルについてのファイルレコードをファイルレコードデータベース内に作成することと、
ファイル内のエッセンスデータの位置を求める要求に応答して、メディアファイルの決定されたレイアウトによって与えられた位置を返送することと、
セグメントが番組に含まれるべきであるという命令に応答して、セグメントのコンテンツに対応するエッセンスデータを取得することと、
番組の時間に対応するメディアファイルからのエッセンスデータの一部を求める要求に応答して、決定されたメディアファイルのレイアウトに従って、当該一部に対応する、受信されたエッセンスデータから得られたエッセンスデータを返送することと
を行うように構成されたファイルシステムが提供される。
【００２９】
また、メディアファイルのフォーマットは、ファイル内の事前に宣言された位置にあるファイルデータの複数のセグメントを含んでいることを必要とし、ファイルシステムは、メディアファイルのレイアウトを決定するときに、
メディアファイルの、必要とされるプロパティに基づき、ファイルについての最大セグメント長を決定することと、
ファイル内のセグメントの位置を求める要求に応答して、メディアファイルの各セグメントが最大セグメント長を有するように考慮して計算された位置を返送することと、
メディアファイルのセグメントからのファイルデータを求める要求に応答して、セグメントについて生成されたファイルデータを返送することであって、生成されたファイルデータが、受信されたエッセンスデータから得られたファイルデータと、生成されたファイルデータを最大セグメント長にするためのパディングデータとを含む、生成されたファイルデータを返送することと
を行うように構成されるのが好ましい。
【００３０】
メディアファイルのフォーマットはＭＰＥＧ−４であるのが好ましい。
【００３１】
ファイルシステムは、ファイルシステムによってエッセンスデータに提供される速度を変化させるために、先に要求されたエッセンスデータの返送を遅延させるように、さらに構成される。
【００３２】
セグメントが番組に含まれるべきであるという命令は、セグメントの継続時間を含み、セグメントについて生成されたエッセンスデータは、受信されたエッセンスデータのフレームを削除、複製、および／または補間することによって、受信されたエッセンスデータから得られるようにするのが有利である。
【００３３】
この発明の第３の実施態様によると、コンピュータネットワークであって、
上記のファイルシステムと、
ファイルシステムにメディアファイルを要求するように構成されたコンピュータデバイスとを備え、
コンピュータデバイスが、受信されたエッセンスデータから得られたエッセンスデータをシーケンシャルに要求するように構成された、
コンピュータネットワークが提供される。
【００３４】
この発明の第４の実施態様によると、実行されると、上記の方法のいずれかのステップを実施するように構成されたコンピュータプログラムプロダクトが提供される。
【００３５】
この発明の第５の実施態様によると、コンピュータデバイス上で実行されると、上記のファイルシステムを提供するように構成されたコンピュータプログラムプロダクトが提供される。
【００３６】
本発明の一実施態様に関連して説明された特徴が、本発明の他の実施態様に組み込まれ得ることを、当然ながら認識されるであろう。たとえば、この発明の方法は、この発明の装置を参照して説明された特徴のうちのどのような特徴をも組み込み得、逆の場合もまた同様である。
【００３７】
本発明の実施形態について、以下の図を含む添付の概略的図面を参照して、例としてのみ、これから説明する。
【図面の簡単な説明】
【００３８】
【図１】番組の内容が放送されるのに伴って番組の内容を決定するための従来のシステムを示す図である。
【図２】インターネットを通じた送信用にメディアファイルを変換する従来の方法を表す図である。
【図３】この発明の第１の実施形態による、放送番組に対応するメディアファイルを生成するためのファイルシステムを含む、番組の内容が放送されるのに伴って番組の内容を決定するためのシステムを示す図である。
【図４】メディアファイルの生成の開始時における、図３のファイルシステムの動作を示すフローチャートである。
【図５】図３のファイルシステムによって生成されたメディアファイルの構造を示す図である。
【図６】メディアファイルの内容の生成時における、図３のファイルシステムの動作を示すフローチャートである。
【図７】メディアファイルを求める要求に応答した、図３のファイルシステムの動作を示すフローチャートである。
【図８】図３のファイルシステムのメディアファイルを変換する方法を表す図である。
【発明を実施するための形態】
【００３９】
この発明の第１の実施形態について、図３を参照してこれから説明する。ファイルシステム３１は、データストア３２、ファイルレコードデータベース３３、およびゲートウェイ３４を備える。ゲートウェイ３４は、ストリーム配信されたエッセンスデータ３７（ビデオおよび／またはオーディオ情報を構成するデータ）を受信するように構成されている。ファイルシステム３１は、以下に説明するように、ニュース番組などの番組用のメディアファイルを生成し、当該メディアファイルが読み出されることを可能にする。ゲートウェイ３４は、番組の放映順序３６ａを制御するために、換言すると、番組が放送されている間に番組の内容を決定するために、ユーザインターフェイスデバイス３６と通信する。
【００４０】
ファイルシステム３１は、ゲートウェイ３４を介してネットワーク３５と通信する。以降において以下に詳細に説明するように、「適任の」ソフトウェアアプリケーションを稼動させるデバイス３８は、ネットワーク３５を介してファイルシステム３１と通信する。
【００４１】
図４は、番組用のメディアファイルの作成の開始時における、ファイルシステム３１の動作を示すフローチャートである。まず最初に、番組の放送が開始する前に、ファイルシステム３１は、たとえば、番組の長さ、ならびに、生成されるファイルの品質およびフォーマットを含む、番組および生成されるファイルに関する詳細を受信する（ステップ４１）。
【００４２】
次いでファイルシステム３１は、この情報を使用して、生成されるファイルの構造を決定する（ステップ４２）。図５に、例としてのファイル構造が示される。ファイル構造５０は、ＭＸＦファイル用のものであり、インデックス５１と、複数のＧＯＰ（「ピクチャの集合」）５２ａ、５２ｂ、５２ｃ、５２ｄとを備える。ＧＯＰは、特定の継続時間のビデオの特定のシーケンスを構成する一連の画像である。受信された詳細は、番組の長さを含み、ＧＯＰの数およびそれらの中のビデオの継続時間とを決定することができる。
【００４３】
ＧＯＰ内の画像は圧縮され、その結果、通常ＧＯＰは異なる長さを有するものとなる（すなわち、異なるバイト数で構成される）。この理由の１つは、ＧＯＰが表すビデオは、ビデオを構成する画像の性質に応じて、異なるサイズに圧縮されるためである。たとえば、圧縮技術が一連の画像間の差異を識別することを含むので、一連の非常に類似した画像は、実質的に互いに異なっている一連の画像よりも一段と小さなサイズに圧縮される。これは一般に、ファイル内のＧＯＰの位置が、先行する各ＧＯＰのサイズによって決まることを意味している。インデックス５１が、ファイル４０内でビデオの時間レンジからバイトレンジへのマッピングを行い、したがって、ビデオの特定の時間レンジに対応する１つのＧＯＰ（または複数のＧＯＰ）を見つけることが可能となる。
【００４４】
しかしながら、図５から、ファイル構造５０において、ＧＯＰ５２ａ〜５２ｄが全て同じサイズであることがわかる。これは、ファイルシステム３１に各ＧＯＰのサイズを事前設定させることによって達成される。（ＧＯＰの内容がまだ未知であり、したがって、各ＧＯＰが含むことになる、圧縮されたエッセンスデータの正確なサイズが特定不能であることに注意することが重要である。）各ＧＯＰのサイズは、ＧＯＰを構成する画像の最小可能圧縮、したがって、最大可能バイトレンジを計算することによって決定される。次いで、構造内の各ＧＯＰの実際のサイズは、少なくともこの最大可能サイズであるものと解釈される。
【００４５】
次いで、ファイルシステム３１は、ファイルについてのファイルレコードを生成し、それをファイルレコードデータベース３３内に格納する（ステップ４３）。ファイルレコードは、以前のステップにおいて決定されたファイルの構造から得られた、そのサイズなどのファイルに関する特定の詳細を含む。次いで、決定されたファイルの構造を使用して、特に、ＧＯＰ５２ａ〜５２ｄの所定のサイズを使用して、ファイルのインデックス５１が作成される（ステップ４４）。
【００４６】
他のファイルフォーマットのファイル構造もまた、同様の態様で決定される。たとえば、ファイル内にデータを位置決めする際に使用するための最初におけるインデックスおよび最後におけるフッタとの両方を備えるフラグメント化ＭＰＥＧ−４フォーマットにおけるファイルもまた決定される。使用され得る他のファイルフォーマットには、フレーム内圧縮またはＧＯＰ圧縮を用いるＭＰＥＧ−２またはＭＰＥＧ−４、ＶＣ−１、Ａｐｐｌｅ  ＰｒｏＲｅｓ、その他などの圧縮ファイルフォーマットと、Ｑｕｉｃｋｔｉｍｅ、非圧縮ＭＰＥＧ−４、ＡＶＩ、ＷＡＶ、その他などの非圧縮ファイルフォーマットとが含まれる。
【００４７】
番組が放送されている間における、メディアファイルを構成するファイルデータの作成、すなわち、ＧＯＰのコンテンツの作成について、図６を参照して説明する。番組のコンテンツは、ユーザインターフェイスデバイス３６を介してユーザによって制御される。番組の全体にわたり、ユーザは、放映順序内のどのセグメントが番組の一部分になるべきであるのかを制御する。たとえば、ユーザは、現在のセグメントがライブ映像であるべきことを命令する。代替的に、ユーザは、現在のセグメントがメディアの事前記録された断片であるべきことを命令する。
【００４８】
いずれの場合においても、このことは、その特定のセグメントが番組内に入るよう確約されるようにせよといった、ユーザインターフェイスデバイス３６からファイルシステム３１への命令が結果として生じる（ステップ６１）。ユーザは当然ながら、放映順序３６ａ内においてさらなる項目を自由に変更することができるが、現在のセグメントを変更すること（別のセグメントの放送が開始し得るように、現在のセグメントが今まで放送されてきた時点で現在のセグメントを停止させることは除く）が不可能であること、または、先行するいかなるセグメントの変更も不可能であることがわかる、その理由は、現在のセグメントおよび先行するセグメントが既に放送番組の一部分になっているためである。
【００４９】
ファイルシステム３１が、確約されたセグメントについての命令を一旦受信すると、ファイルシステム３１は、そのセグメントにとって必要なエッセンスデータを取得する（ステップ６２）。セグメントがライブ映像を含む場合、エッセンスデータは、ストリーム３７を介して取得される。それとは対照的に、セグメントが、メディアの予め記録された断片である場合、必要とされるエッセンスデータは、それがどのような場所に格納されていても取得される。すなわち、エッセンスデータは、たとえば、データストア３２に格納されていることが考えられる、または、ネットワーク３５を介してリモートストレージから取得される。映像の表示を操作するためにジョグ／シャトルダイヤルが使用される場合、エッセンスデータの必要とされるフレームが取得される。たとえば、操作された映像が、一部がスローモーションで繰り返されるか、または再生される（この場合、各フレームは、スローモーション効果を達成するために、１回または複数回繰り返される）ので、同じフレームの複数個のコピーを含む場合、フレームが繰り返されるエッセンスデータのストリームが制作される従来のシステムとは対照的に、いずれの場合も、エッセンスデータのフレームを１度だけ取得する必要があることがわかる。
【００５０】
次いで、ファイルシステム３１は、データがファイルの所定の構造に従って圧縮されてＧＯＰ間で分配される状態において、エッセンスデータを使用してＧＯＰのコンテンツを生成する（ステップ６３）。上で論じたように、いかなるＧＯＰの長さもＧＯＰ内の画像の少なくとも最小可能圧縮となるように決定される。当然ながら、実際には大多数の場合において、画像は、最小可能サイズ未満に圧縮され、この場合、ＧＯＰ内の空きスペースは、空白パディングデータで埋められる。
【００５１】
番組全体が放送されるまで、さらなるセグメントがユーザによって確約されるのに伴い、この処理が繰り返される（ステップ６１〜６３が繰り返される）。
【００５２】
上記の実施形態において、ファイルのインデックスおよびＧＯＰのコンテンツは、生成することが可能になるとすぐに生成される。すなわち、ファイルおよび番組の詳細が受信されるとインデックスが生成され、必要とされるエッセンスデータが取得されるとすぐに、ＧＯＰのコンテンツが生成される。しかし、別の有利な実施形態では、インデックスおよびＧＯＰのコンテンツが必要とされるときにのみ生成される。たとえば、ファイルが実際に要求されたときにのみ、インデックスが生成される。要求されたときにのみ、ＧＯＰのコンテンツが生成される。たとえばストリーム３７によって提供された必要とされるあらゆるエッセンスデータは、その間にデータストア３２に格納される。
【００５３】
デバイス３８からの番組のファイルを求める要求に応答したファイルシステム３１の動作について、説明する。上で述べた通り、デバイス３８は、「適任の」ソフトウェアアプリケーションを稼動させている。適任のソフトウェアアプリケーションとは、以下で説明するように、ファイルを構成するデータに対し、特に予測可能であって行儀の良い態様でアクセスしているものと識別されたソフトウェアアプリケーションである。
【００５４】
上で論じたように、ファイルシステムの特徴は、ファイルへのランダムアクセスを可能にすることである。すなわち、ファイルのあらゆる任意のデータが要求され得る。しかし、発明者（ら）は、あるソフトウェアアプリケーションが、ファイルシステムによって提供されるランダムアクセスを利用せずに、むしろ予測可能な態様でファイルのデータにアクセスしていることを突き止めた。本発明に好適な、行儀の良い態様でファイルからデータを読み出しているものと識別されるソフトウェアアプリケーションは、いずれも「適任」であると考えられる。
【００５５】
本発明では、ソフトウェアアプリケーションがエッセンスデータに対応するファイルからのデータにシーケンシャルにアクセスする場合にのみ、ソフトウェアアプリケーションは適任となる。ソフトウェアアプリケーションが、それ以降のエッセンスデータに対応するファイルからのデータにシーケンスに従わずにアクセスしようと試みないことを意味する。したがって、（たとえば、インターネットを通じた送信に好適なフォーマットおよび品質にファイルを変換するために）、たとえば、最初にファイルのインデックスにアクセスして、その後、ファイルの最初から最後まで順番にＧＯＰのコンテンツを読み出すことによって、ファイルをトランスコードしたソフトウェアアプリケーションは適任となる。（たとえば、インデックスをファイルの最初に置く必要はなく、ファイルの最後に置くこともでき、または、最初と最後の両方にインデックスがあってもよいことに注意されたい。）しかし、ソフトウェアアプリケーションは、適任であるために、それほど行儀の良いものである必要はない。すなわち、アプリケーションは、既に読み出されたインデックス、あるいは任意のＧＯＰの読み出しまたは再読み出しをいつでも行うことができ、また、ＧＯＰデータが、その生成のために対応するエッセンスデータを必要とせずに提供される場合に限り、ＧＯＰデータをファイルの最後から読み出すことさえできる。（したがって、たとえば、ファイルの最後から一般的なパディングデータが提供されることによって満たされたアプリケーションは、適任となり得る。）大切なのは、アプリケーションが、ファイル全体から順番にファイルデータを読み出すことではなく、実際には、ファイルインデックスがファイルの最後に置かれることは普通であり、その場合には、最後に対応するファイルデータが最初に読み出されることが期待される点に留意することが重要である。必要とされるのは、アプリケーションが、ファイルの後ろに格納されたエッセンスデータを順番に従わずに読み出そうと試みることによって、「飛び越し」をしないことである。
【００５６】
トランスコードは、ソフトウェアアプリケーションを結果的に適任とすることができるソフトウェアアプリケーションの機能の一例であり、本発明が、いかなる機能を有する適任のソフトウェアアプリケーションによるアクセスに等しく適用されるものであることを理解されたい。
【００５７】
類似した様式において、あらゆるデバイス、ソフトウェアサービスなどが、適任のデバイス、適任のソフトウェアサービスなどであると考えられることを可能にする行儀の良い態様で、ファイルにアクセスしているものと識別される。
【００５８】
図７を参照して、適任のソフトウェアアプリケーション３７からのデータの要求に応答したファイルシステム３１の動作について説明する。まず最初に、ファイルシステム３１は、ファイルを読み出す要求を受信する（ステップ７１）。これを受けて、ファイルシステム３１は、ファイルレコードデータベース３３に格納されたファイルのファイルレコードにリンクされたファイルハンドルを返送する（ステップ７２）。
【００５９】
次に、デバイス３８上で稼働しているソフトウェアアプリケーションは、上記の行儀の良い態様で振舞い、ファイルシステム３１は、ファイルのインデックスに対応するファイルのデータを求める要求を受信し（ステップ７３）、ファイルシステム３１は、当該データをデバイス３８に返送する（ステップ７４）。このことが、ファイルのいずれかのエッセンスデータが取得される前に行うことができることがわかる。この理由は、ＧＯＰを構成するエッセンスデータが既知になる前に、ＧＯＰの最大可能サイズに基づき、インデックスが生成されることによって、ファイル内のＧＯＰの位置が予め決定されるためである。これは、任意のＧＯＰの位置が先行する任意のＧＯＰに対する可能な圧縮によって決まり、したがって、全ＧＯＰが一旦生成されてからインデックスが漸く生成され、全エッセンスデータが利用可能であることを必要とする従来のシステムとは異なっている。
【００６０】
次に、ファイルシステム３１は、ＧＯＰを構成するデータを求める要求を受信し（ステップ７５）、ファイルシステム３１は、当該データを返送する（ステップ７６）。やはり、デバイス３８上で稼働するソフトウェアアプリケーションが行儀の良い態様で振舞うため、要求されたデータは、ファイル内の最初のＧＯＰに対応していることになる。これは、従来のシステムのように全ＧＯＰのエッセンスデータが利用可能である必要がなく、そのＧＯＰのエッセンスデータのみが取得されると、すぐにデータを返送できることを意味する。
【００６１】
ファイルシステム３１は、関連するエッセンスデータがストリーム３７によって提供されるとすぐに、ＧＯＰのデータを返送することが可能な状態において、次のＧＯＰのデータを求める要求を受信し、関連するデータを返送する（ステップ７５および７６が繰り返される）。
【００６２】
インデックスおよびＧＯＰデータが、要求されたときにのみ生成される代替の実施形態においては、ファイルシステム３１の動作がそれに応じて適応されることが認識されるであろう。
【００６３】
図８は、変換されたファイルを作成するために使用されたときの本発明の効果を示す。従来のシステムとは異なり、ファイルの変換は、ファイル全体が利用可能になるまで変換が待たれなければならないのではなく、ファイル内のＧＯＰのエッセンスデータが利用可能になるとすぐに開始できる。セグメントＳ１がライブ映像から成り、ライブ映像のエッセンスデータがストリーム３７を介して提供されるものと仮定されたい。バーＣ１によって表示される、このセグメントの変換は、ほぼ直ちに開始することが可能であり、セグメントのエッセンスデータが利用可能になるのに伴って「リアルタイム」で進行する。その結果、セグメントの変換は、セグメント自体が完成してからわずか短時間のうちに終了する。
【００６４】
さらに、セグメントＳ２およびＳｎが、録画された映像から成るものと仮定されたい。この場合、セグメントについての全エッセンスデータが既に利用可能であるため、変換は、リアルタイムで実施される必要がない。その結果、（バーＣ２およびＣｎによって表示される）セグメントの変換は、セグメントがまだ放送されている間に完了され（その理由は、変換がリアルタイムで実施される理由がないためである）、または、セグメントの変換に要する時間が短縮されることは、以前のセグメントの変換がまだ処理中である場合、変換処理が「追いつく」ことを可能にする。
【００６５】
この例における変換処理Ｃ１〜Ｃｎの全体長さが、事実上、従来の例における変換処理Ｃよりも、より長い時間を要することがわかる。この理由は、ファイルの内容が利用可能にされるのに伴って、変換が漸く生じ、この変換が、変換開始時にファイル全体が利用可能である従来の例におけるものではなく、ライブ映像が含まれている場合にのみ、リアルタイムであるためである。しかしながら、ファイルがまだ作成されている間に変換が開始するため、変換されたファイルは、それでもなお、元ファイルの完了からわずかすぐ後に、全面的に利用可能な状態となる。したがって、変換の速度は欠点ではなく、事実上有利である。その理由は、変換に要する時間をできるだけ短縮するために、大量の演算能力と、それに付随する費用とを使用する理由がないことを意味するためである。
【００６６】
録画されたセグメントの後ろにライブ映像のセグメントが続く場合、録画されたセグメントの変換が完了したときに、ライブ映像のセグメントのエッセンスデータが利用可能ではないことが考えられることが認識されるであろう。このことは、ファイルシステム１１がＧＯＰを提供することが可能になるのに実質的に先立ち、デバイス３８がＧＯＰを求める要求を行うといったことが結果的に生じる。このことは、ＧＯＰを求める要求がタイムアウトになること、すなわち、ＧＯＰを構成するデータが最大許容時間内に返送されないことが結果的に生じる恐れがある。これを回避するために、ファイルシステム３１は、先のＧＯＰの返送を遅延させることができる。今度は、デバイス３８によって行われた将来的な要求を遅延させ、したがって、このようなタイムアウトが生じないように、要求が行われてから充分に短時間の内に、必要とされるエッセンスデータが受信されることを確保する（または確保しようと試みる）。
【００６７】
特定の実施形態を参照して本発明の説明および例示を行ってきたが、この発明が、本明細書に具体的に例示されていない、多くの異なる変形に向いていることを、当業者は認識するであろう。
【図１】
2015510727.tif 000003
【図２】
2015510727.tif 000004
【図３】
2015510727.tif 000005
【図４】
2015510727.tif 000006
【図５】
2015510727.tif 000007
【図６】
2015510727.tif 000008
【図７】
2015510727.tif 000009
【図８】
2015510727.tif 000010
【国際調査報告】
2015510727.tif 000011
2015510727.tif 000012
2015510727.tif 000013
2015510727.tif 000014
2015510727.tif 000015