データ・フローを同期化する方法
【課題】
【解決手段】第１データ・フローが、受信器でバッファリングされ、バッファ内容が、メタデータについてスキャンされる。まだ到着していない第２データ・フローを示すメタデータが見つかる場合には、システムは、ストール・フェーズに入り、このストール・フェーズ中には、第１データ・フロー内のすべての沈黙時間の長さが延ばされる。第２データ・フローが必要である第１データ・フロー内の点が近くなる時に、沈黙時間がそれによって延ばされる係数が、指数関数的に増やされる。期待される第２データ・フローが実際に到着した後に、この２つのデータ・フローの再生は、ストール・フェーズ中にバッファ内で蓄積された追加データのバックログをクリアするために沈黙時間を圧縮することによって加速される。
【解決手段】第１データ・フローが、受信器でバッファリングされ、バッファ内容が、メタデータについてスキャンされる。まだ到着していない第２データ・フローを示すメタデータが見つかる場合には、システムは、ストール・フェーズに入り、このストール・フェーズ中には、第１データ・フロー内のすべての沈黙時間の長さが延ばされる。第２データ・フローが必要である第１データ・フロー内の点が近くなる時に、沈黙時間がそれによって延ばされる係数が、指数関数的に増やされる。期待される第２データ・フローが実際に到着した後に、この２つのデータ・フローの再生は、ストール・フェーズ中にバッファ内で蓄積された追加データのバックログをクリアするために沈黙時間を圧縮することによって加速される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にはデータ処理に関し、より具体的には、データ・フロー（オーディオ、イメージ、ビデオ、またはコンピュータ・プログラムなど）を同期化するシステムおよび方法に関する。
【背景技術】
【０００２】
増加した帯域幅、ストレージ容量、および計算容量のせいで、コンピュータ・プログラムのユーザは、ますます多くのマルチメディア・コンテンツを制作し、消費する傾向がある。時々リッチ・メディア環境と呼ばれるこれらの環境は、それぞれが異なる性質を有する複数のメディアの使用の特徴がある。これらのコンテンツは、たとえば、プレゼンテーションのスライド、イメージ、ビデオ、アニメーション、グラフィックス、地図、ウェブ・ぺージ、または任意の他のメディア・オブジェクト（アニメーション付きまたはなし）とすることができ、実行可能プログラムおよびその結果のディスプレイさえ含む。したがって、ユーザに表示される最終的な結果のデータ・フローは、複数のメディア・オブジェクトからなる可能性がある。これらのオブジェクトのいずれをも、互いに同期化でき、オブジェクト間の関係を、経時的に変更できることが観察される。
【０００３】
これらのメディア・オブジェクトは、さまざまな手段によって送達される。これらのコンテンツを、ストリーミングすることができ、これらを、しばしば、プログレッシブ・ダウンロード・モードを使用して取り出すことができ、あるいは、前もって完全にダウンロードすることさえできる。実際に、ほとんどの場合に、１つの単一のコンテンツについてさえ、送達のこれらのモードに関して複数のネットワークを使用することができる。制御されないネットワーク遅延は、異なるフローの間の脱同期化（de-synchronization）を意味し、不完全なまたは表示可能ではない最終的なデータ・フローをもたらし得ると思われる。サービス品質に関しては、インターネット上では、経時的なサービスの送達を保証することはできない。状況は、複数のネットワークが使用されるときにさらに悪くなる。その結果、これらすべてのデータ・フローを同期化する手段の必要がある。
【０００４】
技術的現状では、これらの脱同期化を救済する複数の技法が説明されている。
【０００５】
多くの手法は、同期化情報自体を生成する特定の方法に単純に関する。
【０００６】
他の手法は、ネットワーク・トラフィックの不確かさとその輻輳またはボトルネックとを相殺するために、バッファリング機構に焦点を合わせたものである。実際に、古典的手法は、表示に十分なデータを得るためにバッファを使用することである。たとえばストリーミング環境で使用される時に、所定のしきい値は、メディア・プレイヤ内でファイルの再生を開始する前に、絶対的（メガバイト単位）または相対的（ファイル・サイズのパーセンテージ）な量のデータが受信され、蓄積されることを必要とする。これらのしきい値のセットアップは、異なる技法（統計、ルールベースなど）を使用することができる。ネットワーク遅延を動的に予測することを試みる機構およびそれに応じてバッファの深さを適合させることによる機構をも使用することができる。メディア・ストリーミングは、そのようなバッファ機構を利用するが、もう１つの幅広く使用されている手法が、プログレッシブ・ダウンロードとして知られている。ファイルは、古典的にダウンロードされるが、ファイルの再生は、デーが受信されるや否や開始され得、この場合に、古典的な意味でのバッファはもうない。
【０００７】
他の手法は、主にバッファ調整および補償による、オーディオ・データ・フロー（またはストリーム）の、それに関連するビデオ・ストリームとの同期化または再同期化に焦点を合わせたものである。たとえば、Laurence Kelvin Griffitsの出願した米国特許第６２６２７７６号、名称「System and method formaintaining synchronization between audio and video」には、オーディオ・データとビデオ・データとの間の同期化を維持するのを助けるためにビデオ・データのフレームを選択的に捨てるシステムおよび方法が記載されている。この手法に関する主な問題は、オーディオとビデオとの間の同期化にのみ対処し、他の種類のフローに対処しないことである。
【０００８】
同様に、Sirbu,Mihai G.の出願した米国特許出願第２００７００１９９３１Ａ１号、名称「Systemsand methods for re-synchronizing video and audio data」は、ビデオ・データおよびオーディオ・データを再同期化するシステムおよび方法に関する。このシステムおよび方法は、ビデオ・ジッタ・バッファに関連するビデオ・カウントを、事前定義のビデオ・カウントと比較する。オーディオ・ジッタ・バッファに関連するオーディオ・データ内の所与のオーディオ沈黙時間が、ビデオ・カウントが事前定義のビデオ・カウントから所定の量以内になるまで、ビデオ・ジッタ・バッファのビデオ・カウントが事前定義のビデオ・カウントから所定の量の外であることに応答して調整される。主な問題は、前の特許と同一であり、オーディオとビデオとの間の同期化にのみ対処し、他の種類のフローに対処しないことである。
【０００９】
複数のコンテンツおよびネットワークを伴う、上で説明した複雑なメディア環境には、さまざまな着信データ・フローを同期化する手段がない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許第６２６２７７６号
【特許文献２】米国特許出願第２００７００１９９３１Ａ１号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
メディア・プレイヤ・ソフトウェア・プログラムのユーザは、まさに１つの瞬間に多数のビデオを見ることができるが、同等のことは、サウンドに関しては不可能でないとしてもむずかしい。したがって、オーディオは、同期化の鍵であり、同期化は、オーディオ駆動でなければならない。
【課題を解決するための手段】
【００１２】
したがって、人間の知覚機能のこの特定のプロパティを使用する、具体的には、オーディオ沈黙時間の使用を活用する方法の必要がある。
【００１３】
本発明の第１の態様によれば、バッファ内のデータ・フローを同期化する方法が提供される。オーディオ・データを含む第１データ・フローを受信している間に、第１データ・フローの第１データを第２データ・フローの第２データに関連付ける同期化マークが受信されるや否や、少なくとも１つのオーディオ沈黙時間が、第１データ・フロー内で検出される。同期化マークが、第２データ・フローの関連する第２データの受信の前に受信される場合には、第１データ・フローは、少なくとも１つのオーディオ沈黙時間の持続時間を増やすことによって、バッファ内で変更される。
【００１４】
第１の利益は、オーディオ沈黙時間の使用が、本発明の１つの目的である第２データ・フローの取出のために時間を得ることを可能にすることである。この利益は、ひいては、複数のネットワークから来る複数のデータ・フローに対処するときに非常に興味深い。
【００１５】
オーディオ沈黙を変更すること（非沈黙オーディオ時間を変更しないことによって）の間接的な利益は、変更されたデータ・フローを再生する場合に、それがユーザによって感じ取られる可能性が低いことである。
【００１６】
もう１つの利益は、説明される実施態様が、クライアント側のみであることである。前記方法は、メディア・プレイヤ・アプリケーションによって実行されるのみである。これは、この方法が、クライアント・プレイヤ・ソフトウェアに影響するのみである（サーバ・アーキテクチャでの変更なし、メディア・オーサリング・ツールでの変更なし、ネットワーク・アーキテクチャでの変更なしなど）を意味する。
【００１７】
したがって、さらなる利益は、この方法が、未知のエラー（ネットワーク挙動の不確かさに起因する）の影響を最小にする手段を提供するが、従来技術が、既知のエラー（ジッタなど。ジッタは非常に小さくなる可能性が高い）を補正することだけに関することである。
【００１８】
第２の開発では、前記オーディオ沈黙時間の持続時間は、第２データ・フローが取り出される時に減らされる。
【００１９】
本発明の目的は、フロー変更を補償することである。
【００２０】
第１の利益は、第２データ・フローが間に合って（バッファ・ランニング・ポジション（bufferrunning position）内で）受信される場合に、ゼロサム変更が可能であることである。言い換えると、結果の変更は、互いに打ち消し合う。
【００２１】
さらなる利益は、バッファ内のフローがメディア・プレイヤで演奏されている時に、これらのフローに対して行われる変更を最小化できることである。
【００２２】
第３の開発では、第１データ・フローは、複数のオーディオ沈黙時間を含む。最後に受信されたオーディオ沈黙時間の持続時間は、第２データ・フローの前記第２データが受信されるまで増やされる。
【００２３】
この指数関数的変更の利益は、それが最後の瞬間に行われることである。言い換えると、データがバッファリングされるときに同期化マークがバッファ限度に近くなればなるほど（前記限度は、２つのデータ・フローの２つの同期化された特定のデータの再生に対応する）、第１データ・フローはより大きく変更される。その結果、第２データ・フローの取出のための時間が得られ、処理時間が最適化される。
【００２４】
この開発の第２の利益は、オーディオ沈黙の持続時間が乗算されまたは除算される係数に関する可能性の広い範囲に存する。具体的に言うと、この係数の展開を、線形、指数関数、または任意の他の数学的関数に従うものとすることができる。
【００２５】
第４の開発では、第１データ・フローが複数のオーディオ沈黙時間を含む場合に、少なくとも１つのオーディオ沈黙時間の持続時間は、第２データ・フローの第２データが受信されるまで増やされる。
【００２６】
この開発の利益は、実施態様の可能性の広い範囲を提供することである。第１データ・フローに対して行われる変更を、複数のオーディオ沈黙時間にまたがって分散することができ、使用可能コンピューティング・リソースまたはユーザ経験の質などのパラメータのバランスをとることができる。
【００２７】
この可能な分散のもう１つの利益は、人間の可聴品質知覚または可視品質知覚さえあるいはその両方などのパラメータを考慮に入れることができることである。
【００２８】
もう１つの利益は、コンピューティング・リソースを最適化できることである。たとえば、具体的に言うと、複数のうちの唯一の期間を変更することができる。
【００２９】
この開発のもう１つの利益は、送達制御を間接的に可能にすることである。この利益は、図６の説明で詳細に述べる。
【００３０】
第５の開発では、少なくとも１つのオーディオ沈黙時間の持続時間は、タイムアウト期間が満了するまで増やされる。
【００３１】
利益は、タイムアウトの導入が、先行するものと正確に反対の形で２つの同期化されたフローの再生を制御することを可能にすることである。
【００３２】
第６の開発では、第１データ・フローは、オーディオ／ビデオ・データ・フローである。
【００３３】
第７の開発では、ビデオ・データが挿入される。
【００３４】
本発明の目的は、オーディオ／ビデオ・データ・フローを低速化するのにオーディオ沈黙時間を利用することである。
【００３５】
利益は、第１データ・フローがオーディオ・データのみではなく、オーディオ／ビデオ・データである場合であっても、オーディオ沈黙時間を増やすことができることである。
【００３６】
第８の開発では、ビデオ・データが省略される。
【００３７】
本発明の目的は、オーディオ／ビデオ・データ・フローを高速化するのにオーディオ沈黙時間を利用することである。
【００３８】
利益は、第１データ・フローがオーディオ・データのみではなく、オーディオ／ビデオ・データである場合であっても、オーディオ沈黙時間を減らすことができることである。
【００３９】
第９の開発では、挿入されるビデオ・データは、複製されたフレームまたは補間されたフレームである。
【００４０】
利益は、複製されたフレームが、さらなる計算リソースを全く必要としないことである。これらの複製されたフレームは、たとえば変更の視覚的効果を最小にするように選択することができる（ビデオ・フレームの不連続性は、スタッタをもたらすはずである）。補間されたフレームを使用する場合には、広い範囲の方法を選択することができ、ビデオ品質をさらに高めることができる。
【００４１】
第１０の開発では、検討されるオーディオ沈黙時間は、人間の声オーディオ沈黙または合成音声オーディオ沈黙である。
【００４２】
利益は、説明される方法が、変更されてはならない、または少なくともユーザの知覚に対するより少ない影響を有するために、最も重要なプロパティと考えることのできる声（実際の人間の声であれ、シミュレートされた声または合成音声であれ）に焦点を合わせることである。特に口頭の理解のために、これらの特権付きオーディオ沈黙時間を使用することが、安全であると思われる。
【００４３】
第１１の開発では、オーディオ沈黙時間は、バッファのユーザのオーディオ環境に従って検出され、オーディオ環境は、ソフトウェア・データによって判定されまたはシミュレートされ、あるいはマイクロホンを使用することによって測定される。
【００４４】
利益は、ユーザの実際のオーディオ環境を考慮に入れることができることである。
【００４５】
もう１つの利益は、ソフトウェア・データが、簡単にアクセス可能であることと、非常に単純なしきい値を用いて、オーディオ沈黙時間を判定できることである。
【００４６】
上のパラメータ（沈黙の分布、フレーム挿入の分布、挿入されるフレームの性質、声特性、測定の点・・・）を組み合わせることの利益は、ユーザの視覚的知覚または可聴知覚あるいはその両方を最適化することを可能にすることである。
【００４７】
本発明の第２の態様によれば、本発明の第１の態様による方法の各ステップを実行するように適合された手段を含む装置が提供される。
【００４８】
この装置を非常に簡単に入手でき、したがってこの方法を実行しやすくなることが利点である。
【００４９】
本発明の第３の態様によれば、本発明の第１または第２の態様による方法の各ステップを実行する命令を含むコンピュータリンクド可読媒体が提供される。
【００５０】
この媒体を使用して、さまざまな装置でこの方法を簡単にインストールできることが利点である。
【００５１】
本発明のさらなる利益は、図面および詳細な説明を調べた時に、当業者に明瞭になるであろう。すべての利益が本明細書に組み込まれることが意図されている。
【００５２】
本発明の実施形態を、添付図面を参照してこれから説明する。
【図面の簡単な説明】
【００５３】
【図１】本発明の大域的環境を示す図である。
【図２】本発明が動作するレベルで同期化ユニットを説明するブロック図である。
【図３】本方法を説明する流れ図である。
【図４】データ・フロー、オーディオ沈黙時間、バッファ、および同期化マークを示す図である。
【図５】オーディオ沈黙時間の持続時間の増減の結果の動作の補償を示す図である。
【図６】第２データ・フローが絶対に取り出されない場合を示す図である。
【図７】第１データ・フローがオーディオ／ビデオ・データ・フローである、本発明の実施態様を示す図である。
【図８】オーディオ沈黙時間の検出を示す図である。
【図９】オーディオ沈黙時間検出用の測定諸態様を示す図である。
【発明を実施するための形態】
【００５４】
データ・フローは、イメージ（写真、地図、またはグラフィックス・データなどのスチール・イメージ・・・）、テキスト（電子メール、プレゼンテーション・スライド、チャット・セッション、宣誓証言写し、ウェブ・ページ、クイズ・・・）、ビデオ（アニメーション付きイメージ、フレームのシーケンス、ウェブカム・ビデオ、ＴＶ番組・・・）、マルチメディア文書（リッチ・メディア文書、・・・）、またはプログラム・データ（３Ｄアニメーション、ゲーム、・・・）など、ネットワークによって送信されるデータに対応することができる。ほとんどの場合に、表現データ・フローは、データ・ストリームと同等である。
【００５５】
オーディオ沈黙時間は、たとえば穏やか、静か、平和、または無音もしくは無騒音とさえ特徴を表すことができるサウンドラックの部分またはサウンド・システムを指す。沈黙は、客観的測定が当業者に明白である（低域フィルタ、利得・・・）相対的概念である。
【００５６】
同期化は、本願の目的であり、さまざまな状況にあてはまり得る。非網羅的リストは、タイプ（括弧内の例）すなわち、テキストを伴うオーディオ（歌詞の写しを伴うＭＰ３ソング）、オーディオを伴うオーディオ（ＭＰ３ミキシングまたは電話会話多重化）、イメージを伴うオーディオ（ＭＰ３およびアルバム・ジャケット・イメージ）、ビデオを伴うオーディオ（ポッドキャストおよび話者のビデオ）、テキストを伴うオーディオ−ビデオ（音楽クリップおよび歌詞）、オーディオ−ビデオおよびオーディオ（映画および追加の音楽サウンドトラック）、オーディオ−ビデオおよびイメージ（ビデオキャストおよびスライド、グラフィックス、地図、または任意の他の隣接文書）、ビデオを伴うオーディオ−ビデオ（ビデオキャストおよびｆｌａｓｈアニメーション）、プログラムを伴うオーディオ−ビデオ（ビデオキャストおよび対話型アニメーション）、またはオーディオ−ビデオを伴うオーディオ−ビデオ（芸術、ビデオ・ウォール、ビデオ編集のための２つのビデオの同期化・・・）さえ含む。対向する沈黙時間および非沈黙時間を有する２つのビデオを、本発明を用いて同期できることが観察される。ほとんどの場合に、同期化は、リッチ・メディア・オブジェクトに適用される。リッチ・メディアは、ビデオ、オーディオ、およびアニメーションなどの高められた感覚特徴を利用する、ダイナミックな動きを示す広い範囲の対話型ディジタル・メディアを記述するのに使用される用語である。この動きは、経時的に（たとえば継続的に更新する株式相場表示器）またはユーザ対話に直接応答して（ユーザ制御を可能にするスライドショーと同期化されたウェブキャスト）発生し得る。いわゆるリッチ・メディア・ファイルは、同期化されたおよび同期化されていないデータ・フローの集まりと考えることができる。
【００５７】
バッファは、制御できないネットワーク遅延に起因するフリーズを避けるためにデータを蓄積するのに使用される。バッファ深さ（または長さ）は、通常、これらの遅延を予想し、デバイス制約に対処するサイズにされる。ほとんどの場合に、バッファは、予測されたネットワーク遅延に対処するサイズにされる。非常に予測可能な挙動を有するネットワークでは、バッファを小さくすることができる。逆に（たとえば、インターネット上、または疎結合システムの文脈で、またはサービス品質機構（ＱｏＳ）を有しない任意の他のネットワーク）、ネットワーク遅延は、広い範囲で変化する可能性があり、バッファのサイズは、より重要である必要がある。本発明では、バッファのサイズは、問題ではない。バッファが、経時的に可変深さを有する場合であっても、請求される技術的機構の実施態様が変更されないままになると考えることができる。したがって、図面では、バッファが固定サイズを有すると考えられる。さらに重要なことに、このケースは、現在、バッファを組み込んでいる多数のシステムの現実に対応する。バッファは、ハードウェアまたはソフトウェアのいずれかで実施できるが、バッファの大多数が、現在ソフトウェア実施されていることが観察される。バッファは、通常、ＦＩＦＯ（先入れ先出し）法で使用され、入ってきた順番でデータを出力する。最後に、キャッシュまたはデータ・キャッシング機構は、バッファと同一の機能性に到達することができることが観察される（ほとんどの場合に、キャッシュは、ＲＡＭなどのより高速のアクセスを有する位置にデータを格納する）。
【００５８】
説明を容易にするために、ある図面である要素を識別する符号は、すべての他の図面で同一の要素を表す。
【００５９】
図１に、本発明の大域的環境を示す。
【００６０】
諸実施形態の環境を示す図１に示されているように、データのストレージ手段（１００）、データ・フローがそれを介して送信されるネットワーク（１２０）、本発明がそのレベルで動作する同期化ユニット（１４０）、および同期化されたデータ・フローを解釈するのに使用されるメディア・プレイヤ（１６０）が設けられる。
【００６１】
ストレージ手段（１００）は、複数のサーバにデータを格納するのに使用される。これらのコンポーネントは、すべてがまたは部分的に、暗号化されまたはＤＲＭ保護され得る。データ・キャッシング機構を使用して、コンテンツの送達を加速することもできる。具体的に言うと、単一のコンポーネントを、複数のサーバにまたがってフラグメント化するか分散させることができることが観察される。すべてのデータ・フローは、要求され、異なるネットワーク（１２０）を介して同期化ユニット（１４０）に送信される。同期化の後に、データ・フローは、データ・フローを解釈（たとえば、オーディオ再生またはビデオ表示）する手段を含むメディア・プレイヤ（１６０）に送られる。
【００６２】
格納されたデータをストリーミングすることができるが、いくつかの場合に、ＦＴＰ転送またはデータを転送する他の形をも使用できることが観察される。具体的に言うと、データの送信を、ストリーミングまたはプログレッシブ・ダウンロードのいずれかによって行うことができる。両方の形が、バッファリング機構を必要とする。しかし、ストリーミングの形が、表示されるフレームだけを要求する（ビデオの再生カーソルに従って）のに対して、プログレッシブ・ダウンロードの形は、データ・ファイルのダウンロードを開始することおよび既にダウンロードされたデータを見ることを即座に可能にすることからなる。唯一のネットワークを使用することができるが、複数のネットワークが使用される可能性がより高いことも観察される。ネットワークは、異なる性質を有することができ、動的に変更され得る。たとえば、あるコンポーネントを、まずＧＳＭネットワークを介して要求し、部分的に送信し、使用可能な時に、ファイルの残りの部分をＷＩＦＩネットワークを介して要求することができる。したがって、ファイバ（光および他）、ケーブル（ＡＤＳＬおよび他）、無線（Ｗｉｆｉ、Ｗｉｍａｘ、および他）など、すべての種類のネットワークを、さまざまなプロトコル（ＦＴＰ、ＵＤＰストリーミング、および他）と共に使用することができる。
【００６３】
図２に、本発明が動作するレベルで同期化ユニットを説明するブロック図を示す。
【００６４】
ここで図２を参照するが、図２には、同期化ユニット（１４０）の詳細な構造が示されている。同期化ユニット（１４０）は、データ・フロー・バッファ（２００）、オーディオ沈黙時間検出器（２０２）、同期化マーク受信器（２０４）、データ・フロー変更ユニット（２０６）、およびネットワーク・コントローラ（２０８）を含む。
【００６５】
データ・フロー・バッファ（２００）は、ネットワーク（１２０）によって送信されたデータを受信する。データ・フロー・バッファ（２００）は、複数のデータ・フローをバッファリングし、バッファリングされたデータをオーディオ沈黙時間検出器（２０２）に送るように適合される。前記オーディオ沈黙時間検出器（２０２）は、１つまたは複数のデータ・フロー内のオーディオ沈黙時間を検出するように適合される。オーディオ沈黙時間検出器（２０２）は、同期化マーク受信器（２０４）に接続され、データ・フロー変更ユニット（２０６）に結合される。同期化マーク受信器（２０４）は、１つまたは複数の同期化マークを受信するためにネットワーク（１２０）をリスンする。同期化マーク受信器（２０４）は、オーディオ沈黙時間検出器（２０２）に接続される。データ・フロー変更ユニット（２０６）は、オーディオ沈黙時間検出器（２０２）と相互作用し、オプションで、ネットワーク・コントローラ（２０８）にも結合される。データ・フロー変更ユニット（２０６）は、オーディオ沈黙時間を増やすか減らすことによって、受信されたデータ・フローを変更するように適合される。ネットワーク・コントローラ（２０８）は、データ・フロー・バッファ（２００）およびデータ・フロー変更ユニット（２０６）と相互作用する。ネットワーク・コントローラ（２０８）は、データ・フロー・バッファからネットワーク遅延を測定し、データ・フロー変更ユニット（２０６）を制御するように適合される。
【００６６】
好ましい実施形態では、データ・フロー・バッファ（２００）は、第１着信データ・フローをバッファリングする。同期化マーク受信器（２０４）が第１データ・フローに伴う同期化マークを受信するや否や、オーディオ沈黙時間検出器（２０２）は、オーディオ沈黙時間の分析および検出を開始する。その間に、データ・フロー・バッファ（２００）は、同期化マークによって決定されるとおりに、保留中の必要な第２データ・フローをリスンする。バッファリングされたデータは、データ・フロー変更ユニット（２０６）内で変更される。オーディオ沈黙時間持続時間は、ネットワーク・コントローラとの相互作用に従って増やされ、または減らされる。第１データ・フローの第１データと同期化されなければならない第２データ・フローの第２データと、第１データ・フローの前記第１データとの両方が受信される時に、バッファリングされ同期化されたデータが、メディア・プレイヤ（１６０）での再生のためにバッファ・ランニング・ポジションから出る。
【００６７】
ネットワーク・コントローラ（２０８）がオプションである（同期化は、前記ネットワーク・コントローラなしで働くことができ、データ・フロー・バッファ（２００）とデータ・フロー変更ユニット（２０６）との両方とのネットワーク・コントローラ（２０８）の相互作用は、本発明の性能を改善するのを助ける）ことが強調される。ネットワーク・コントローラ（２０８）を、データ・フロー・バッファ（２００）からのみではなく、ネットワーク遅延を測定するように適合された他の手段（この図には図示せず）に接続できることが観察される。最後に、データ・フロー変更ユニット（２０６）は、そのようなコントローラによって制御されるように適合される（たとえば、遅延が重要である場合に、変更が重要になる）。
【００６８】
図３に、本方法を説明する流れ図を示す。
【００６９】
図３に示されているように、
−第２データ・フローの第２データと同期化される第１データを有する第１データ・フローと、
−第１データ・フローの第１データと第２データ・フローの第２データとの間に同期化マークを受信するステップ（３００）と、
−同期化マークが不在の場合に第１データ・フローを普通にバッファリングし、これを再生するステップ（３０２）と、
−１つまたは複数のオーディオ沈黙時間を検出するステップ（３０４）と、
−第２データ・フローの第２データが受信されるかどうかを確立するステップ（３０６）と、
−検出されたオーディオ沈黙時間の持続時間のうちの１つまたは複数を増やすステップ（３０８）と、
−検出されたオーディオ沈黙時間の持続時間のうちの１つまたは複数を減らすステップ（３１０）と
が提供される。
【００７０】
第１データ・フローは、それに対応するファイルが１つまたは複数のストレージ手段（１００）に格納され、１つまたは複数のネットワーク（１２０）を介して送信されるが、メディア・プレイヤ（１６０）の同期化ユニット（１４０）で受信される。第１データ・フロー内の第１データと第２の保留中のデータ・フローの第２データとの間の同期化マークがステップ（３００）で受信されるや否や、オーディオ沈黙時間が、ステップ（３０４）で検出されつつある。そうでない場合には、第１データ・フローは、ステップ（３０２）に対応して普通にバッファリングされ、再生される。沈黙時間の検出は、第２データ・フローの第２データ（第１データ・フローの第１データと同期化されなければならない）がステップ（３０６）でバッファに受信されるまで継続される。前記第２データ・フローが保留中である間には、バッファリングされた第１データ・フローの検出されたオーディオ沈黙時間のうちの１つまたは複数の持続時間が、ステップ（３０８）で増やされる。同期化されなければならない第２データを含む第２データ・フローのデータが同期化ユニット（１４０）で受信される時には、バッファリングされた第１データ・フローの検出されたオーディオ沈黙時間のうちの１つまたは複数の持続時間が、ステップ（３１０）で減らされる。バッファのストレージ限度に達するまで、データ・フローは、バッファリングされ続ける。その後、同期化されたデータ・フローが、メディア・プレイヤ（１６０）での再生のためにバッファ・ランニング・ポジションから出る。
【００７１】
同期化マークを、必須ではないが、第１データ・フローに埋め込む（たとえばメタ・データ内に）ことができることが観察される。実際に、同期化マークを、タイムコードに基づくものとすることができ、１つまたは複数の独立の他のチャネルによって受信することができる。たとえば、第２ソースから来るスライドショーと同期化される第１ソースからストリーミングされる話者のビデオを含むリアルタイム・ウェブキャストの場合に、同期化マークは、第３ソース（またはネットワーク）を利用することができる。これらの同期化マークは、生イベントの場合に、オン・デマンドで要求され（たとえば、話者自身によって送信され）得る。ほとんどの場合に、そのような同期化マークには、ウェブ・ページのＵＲＬおよび時刻値が封入される。これらを、ブラウザ環境内でクッキーに封入することもできる。
【００７２】
第２データ・フローを、単純に受信でき（送信が外部の独立のサーバによって衝撃を与えられるので）、あるいは、埋め込まれたメタデータによって要求できる（たとえば、第１データ・フロー内または同期化マーク自体内にさえのいずれか）ことをも観察することができる。
【００７３】
図４に、データ・フロー、オーディオ沈黙時間、バッファ、および同期化マークを示す。
【００７４】
図４に示されているように、
−データ・フロー（４００）と、
−白でマークされたオーディオ沈黙時間（４０２）と、
−黒でマークされた非沈黙オーディオ時間（４０４）と、
−同期化マーク（４０６）と、
−バッファ（４０８）の表現と
が提供される。
【００７５】
（４０２）のようなオーディオ沈黙時間と（４０４）のような非沈黙オーディオ時間とを含むデータ・フロー（４００）が、受信され、これらの時間の検出は、図８に関してより詳細に説明する。
【００７６】
バッファは、（４０８）の破線のブロックで表される。バッファ（４０８）の左側は、前記バッファのメモリ限度すなわち、データが再生のためにバッファから解放される点に対応する。バッファ（４０８）の右側は、バッファの入口に対応する。データがバッファリングされる時に、バッファ（４０８）ランニング・ポジションは、この図の左から右へ移動する。
【００７７】
同期化マーク（４０６）は、特定の瞬間に受信される。この同期化マークは、データ・フローの特定のデータを別のデータ・フロー（図示せず）の他の特定のデータと同期化しなければならないことを示す。
【００７８】
図５に、オーディオ沈黙時間の持続時間の増減の結果の動作の補償を示す。
【００７９】
図５に示されているように、追加要素すなわち、
−白でマークされたオーディオ沈黙時間（５００）と、
−白でマークされた変更されたオーディオ沈黙時間（５０２）と、
−処理タスクに関する非常に短い時間期間に対応するεと
と共に、図４と同一の表現が提供される。
【００８０】
時刻ｔ１に、同期化マークが受信される。この同期化マークは、第２データ・フローの第２データを現在のデータ・フローの特定のデータと同期化することを要求する。オーディオ沈黙時間（５００）が検出される。時刻ｔ１＋εに、前記オーディオ沈黙時間の持続時間が、第１時間だけ増やされ、変更されたオーディオ沈黙時間（５０２）がもたらされる。時刻ｔ２に、第２データ・フローの必要なデータが受信される。したがって、時刻ｔ２＋εに、変更されたオーディオ沈黙時間（５０２）の持続時間が、減分によって、もう一度変更され、正確に以前のオーディオ沈黙時間（５００）がもたらされる。したがって、結果の説明された動作は、ゼロサム動作である。
【００８１】
この図では、説明を明瞭にするために、唯一のオーディオ沈黙が図示され、変更される。類似する補償を、複数のオーディオ沈黙時間がある場合に、それらを使用して得ることができることが観察される。これらの時間のいくつかの持続時間を増やすことができ、他の持続時間を減らすことができ、その結果、最終結果は、変更されない総持続時間になる。補償は、正確または不正確にすることができる。これは、データ・フローに対して行われる変更を最小にするための本発明のもう１つの態様である。
【００８２】
図６に、第２データ・フローが絶対に取り出されない場合を示す。
【００８３】
前の図は、必要なデータが間に合って受信される場合に対応し、この図は、求められる（必要な）データが絶対に受信されない、反対の状況を示す。図６に示されているように、追加要素すなわち、
−白でマークされたオーディオ沈黙時間（６００）と、
−白でマークされた変更されたオーディオ沈黙時間（６０２）と、
−白でマークされた再変更されたオーディオ沈黙時間（６０４）と、
−処理タスクに関する非常に短い時間期間に対応するεと
と共に、図４と同一の表現が提供される。
【００８４】
前の図と同様に、時刻ｔ１に、同期化マークが受信される。唯一のオーディオ沈黙時間（６００）の持続時間が、時刻ｔ１＋εに増やされ、変更されたオーディオ沈黙時間（６０２）がもたらされる。時刻ｔ２に、必要なデータが受信されなかったので、持続時間がもう一度増やされる。着信第１データ・フローは、バッファリングされ続け、バッファは、図の左から右へ移動する。沈黙が再生されつつある（図示のバッファの左側）。その後、このプロセスは、それ相応に継続する（６０４）。言い換えると、オーディオ沈黙は、指数関数的に増やされる。
【００８５】
最後に、前の図と同様に、説明を明瞭にするために、唯一のオーディオ沈黙が図示され、変更されることが観察される。この方法の実施態様がどの時間を増やすべきかの選択から利益を得ることができることを除いて同一の機構が、複数のオーディオ沈黙時間が存在する場合に観察されるはずである。好ましい実施形態では、最後に受信されたオーディオ沈黙時間（言い換えると、最後にバッファリングされたオーディオ沈黙時間；図４を参照されたく、図示のバッファの左端に関して図示されている）が増やされる。したがって、増加モデルは、任意の数学関数（線形、定数、指数など）に従うことができる。
【００８６】
この開発の利益は、送達制御を間接的に可能にすることである。同期化されたフローの再生は、必要なデータが受信されない場合には可能ではない（１つまたは複数のオーディオ沈黙が、第２データ・フローの第２データが受信されるまで増やされる。第２データ・フローのこの第２データが絶対に受信されない場合には、第１データ・フローは、バッファのサイズにおける制限に起因して、フリーズしているように見える）。そのような制御は、コンテンツの保護に関して非常に貴重でありえる。第２データ・フローの第２データが、ＤＲＭ（ディジタル著作権管理）権利を付加され、バッファ内に受信されない（たとえば、取り出されず、正しく復号されない）場合には、これは、第１データ・フローの回復を妨げる。そのような保護の頑健性は、多数の類似する必要なデータ・フローの使用からも利益を得る。
【００８７】
必要なデータが絶対に受信されない、このシナリオの結果を救済するために、タイムアウト機構を使用することができる。このタイムアウトは、所定の遅延を使用することができ、あるいは、動的にセット・アップされ得る。１つまたは複数のサーバ（データを送信する）、クライアント（対応するルールを有するメディア・プレイヤ）、ユーザ（同期化されたフローの取出のドロップを指示することができる可能性がある）、または第１データ・フロー自体（埋め込まれたデータを伴う）さえのいずれかが、そのようなタイムアウト機構を含むか、これに衝撃を与えることができることが観察される。
【００８８】
図７に、第１データ・フローがオーディオ／ビデオ・データ・フローである、本発明の実施態様を示す。
【００８９】
図７に示されているように、
−非沈黙オーディオ沈黙時間（７００）と、
−オーディオ沈黙時間（７０２）と、
−変更されたオーディオ沈黙時間（７０４）と、
−ビデオ・データのフレーム（７１０）と、
−挿入された追加のビデオ・フレーム（７１２）と
が提供される。
【００９０】
図７に、オーディオ・データおよびビデオ・データを含むデータ・フローを示す。前記オーディオ・データは、（７０２）に似たオーディオ沈黙時間および（７００）に似た非沈黙オーディオ沈黙時間を含む。前記ビデオ・データは、さらに、（７１０）に似た複数の順次ビデオ・フレームを含み、各フレームは、前記第１データ・フローに属する特定のオーディオ・データに関連する。前記データ・フローを、オーディオ／ビデオ・データ・フローと称する。時刻ｔ１＋εに、オーディオ沈黙時間（７０２）の持続時間が増やされ、変更されたオーディオ沈黙時間（７０４）がもたらされる。（この変更されたオーディオ・データに）対応するビデオ・データは、前記オーディオ沈黙時間に属する前記オーディオ・データに関連するすべてのビデオ・フレームの間に（７１２）に似た追加ビデオ・フレームを挿入することによって変更される。
【００９１】
この図は、実際に、オーディオ沈黙時間が増やされる時に何が起きるのかを示す。視覚的効果（変更されたデータ・フローがたまたま再生される場合の）は、そのオーディオ沈黙時間中のビデオの低速化またはフリーズである。
【００９２】
オーディオ沈黙時間が減らされる（たとえば、必要なデータが受信される時または前の変更を補償するため）、反対のステップ（図面には示さず）について、前に挿入されたフレームが、削除または省略され、いくつかの他の場合には、視覚的効果（変更されたデータを再生する時の）は、ビデオ・リプレイの低速化またはフリーズにすらなる。
【００９３】
したがって、前の図に関して説明し、図示した本発明の諸態様に関するすべての所見は、同様にあてはまる（補償、複数のオーディオ沈黙時間の使用、タイムアウト機構など）。具体的に言うと、図５では、バッファ内の挿入されたフレームと削除されたフレームとの間に補償が見られ、リプレイ（再生）中の視覚的影響がない可能性が高い。図６では、ビデオ・リプレイにおけるフリーズが見られる（タイムアウト機構が使用されない限り）。
【００９４】
追加のビデオ・フレームを挿入するための幅広い選択があることが観察される。たとえば、これらのフレームを、複製されたフレーム（たとえば既存のバッファリングされたフレームの中で選択される）または補間されたフレーム（言い換えると、生成されるフレーム）とすることすらできる。最小の視覚的影響を有するために、ビデオの分析は、挿入すべきフレームの性質とこれらのビデオ・フレームを挿入すべき時間との両方に関して、追加フレームの分配を判断するのを助けることができる。この分析は、オンザフライ（たとえば、バッファ内）で処理することができ、あるいは、所定（この判断ステップを助けるためにメタ・データに埋め込まれる）とすることができる。高ビットレートの特徴があるシーン（たとえば、オーディオ沈黙時間がない場合に少数を伴うアクション・シーン）は、より低いビットレートのシーン（たとえば話のオーディオ沈黙時間を伴うテレビジョン・スピーカ）より使用可能である可能性がより低い。したがって、バッファリングされたデータの分析は、ビデオ・フレームを挿入すべき最良の沈黙時間を判断するのを助けることができる。これらの追加フレームを、複数の使用可能なオーディオ沈黙時間にまたがって分散させることができる（１つの唯一のオーディオ沈黙時間にまたがってさえ、均等に分散させまたはさせない）。
【００９５】
本発明の目的は、最終出力に対する影響を最小にするためにバッファ内のデータに対して行われる大域的変更を最小にすることである。無音の複数の期間にわたる分布は、このケースへの関心を表すことができる。オーディオ沈黙中のバッファ・データ変更を多数の他の要因によって駆動できることが観察される。複数のオーディオ沈黙の中に、好ましくはどの沈黙時間を延長しなければならないのかを判断するために考慮に入れるべき他の要因がある可能性がある。そのうちの１つが、対応するビデオ・データ変更の最小化である。たとえば、爆発のようなアクション・シーンから始まるドキュメンタリーを紹介するじっとしている話者を示すビデオ・シーケンスでは、アクション・シーンのオーディオ沈黙がある場合でも、それらよりも、話者部分のオーディオ沈黙を延長することがはるかにより興味深い可能性がある。
【００９６】
多数の実施態様が可能である。第２データ・フローの取出のための時間を得る必要と出力されるデータに対するできる限り少ない影響を有する必要（以前に行われた変更の補償）との間の妥協を得るために、さまざまな異なるアルゴリズムを選択することができる。すべてのアルゴリズムは、残された時間を考慮に入れなければならず、これは、同期化マークの前のバッファ内に残っている時間が、２つの同期化されたデータ・フローが実際に演奏される必要がある瞬間に対応するバッファの最大サイズに達することを意味する。単純な可能性は、再生の前にバッファ内に残っている時間に対応するしきい値をセットアップすることに存する。保留中のオブジェクト（受信されるべき第２データ・フロー）があり、再生の前の残された時間が前記しきい値を超える場合には、ビデオ・データまたはオーディオ・データは、バッファ内で変更されず、次のビデオ・フレームがプレイされる。対照的に、残された時間がしきい値より小さい場合には、別のテストが実行され、残された時間がしきい値を２で割ったものより小さい場合には、ビデオ・リプレイ速度も２で割られ（これは、現在のフレームを１回リプレイすることによって達成される）残された時間がしきい値を２で割ったものを超える場合には、ビデオ・リプレイ速度を４で割る（これは、ビデオ・フレームを３回リプレイすることによって達成される）。フレームのリプレイおよびフレームのコピーの追加が、同一の意味を有することが観察される。
【００９７】
最後に、同一の観察（フレームの性質、分布、視覚的影響、ビットレートなど）を、フレームが削除されまたは省略される反対の動作について行うことができる。やはり、削除されるフレームが、必ずしも以前に挿入されたフレームではないことが強調される。
【００９８】
図８に、オーディオ沈黙時間の検出を示す。
【００９９】
図８に示されているように、
−データ・フロー（４００）と、
−非沈黙オーディオ時間（４０２）および（８００）と、
−オーディオ沈黙時間（４０４）および（８１０）と
が提供される。
【０１００】
説明を明瞭にするために、古典的オーディオ・スペクトルを示す別の表現が使用されている。前に使用された図との対応が、示されている。
【０１０１】
オーディオ沈黙時間は、明らかに相対的であり、測定可能性に依存する。人が、何がオーディオ沈黙時間と考えられるべきかを判断しなければならない。したがって、オーディオ沈黙時間の検出は、前記沈黙を判定するのに当業者によって使用される通常の形を指す。これは、複数の既知の方法によって達成でき、最も単純な解決策は、しきい値が選択され、しきい値未満のオーディオ・シーケンスがオーディオ沈黙と考えられることを特徴とする。しきい値は、デシベル（ｄＢ）単位、ワット単位などとすることができる。
【０１０２】
図８に関して示されているように、データ・フロー（４００）が分析され、所定のしきい値より小さい値を有する非沈黙オーディオ時間（８００）は、オーディオ沈黙時間（４０４または８１０）と考えられる。したがって、ステップ（ａ）での分析の前に、データ・フロー（４００）は、未分析オーディオ・データを含み、ステップ（ｂ）での分析の後に、このデータ・フローは、オーディオ沈黙時間（４０４）を含み、残りのデータは、まだ非沈黙オーディオ時間（４０２）と考えられる。
【０１０３】
大きい値（たとえば、オーディオ信号のピークまたは平均値と比較して）を有するしきい値の使用は、興味深い。というのは、これが、多数のオーディオ・シーケンスがオーディオ沈黙と考えられ、その結果、同期化されたフローの取出のための時間を得るより多くの機会が生じることを暗示するからである。逆に、相対的に少数の沈黙時間が判断される場合には、本発明の説明される機構を使用する、より少数の機会が生じる。
【０１０４】
スプリッタの使用が、本発明の実施態様のために必要になる場合があることが観察される。たとえば、ＭＰＥＧ２またはＭＰＥＧ４データ・フロー（ストリーム）内では、オーディオ・データおよびビデオ・データは、同一ストリームに埋め込まれる。オーディオ沈黙時間を検出しまたは判定することができるために、オーディオ・データをビデオ・データから分離することが必要になる場合がある。
【０１０５】
図９に、オーディオ沈黙時間検出用の測定諸態様を示す。
【０１０６】
図９に示されているように、
−サウンド・カード、スクリーン・ディスプレイ、キーボード、およびポインティング・デバイスを有する中央ユニットを
−メディア・プレイヤ・アプリケーションのディスプレイ（９００）
と共に含むコンピュータと、
−オーディオ・プラグ出力（９１０）と、
−オーディオ・スピーカ（９２０）と、
−マイクロホン・オーディオ入力（９３０）と、
−ユーザ（９４０）と
が提供される。
【０１０７】
コンピュータの中央ユニットは、メディア・プレイヤ（１６０）を実行し、このメディア・プレイヤは、ディスプレイ（９００）に表示される。前記コンピュータ内に組み込まれたオーディオ・カードは、オーディオ信号をオーディオ・プラグ出力（９１０）に送達する。代替案では、オーディオ・カードは、オーディオ・スピーカ（９２０）に接続され、マイクロホン・オーディオ入力（９３０）も、前記オーディオ・カードに接続される。ユーザ（９４０）は、オーディオを聞いているかビデオを見ている。
【０１０８】
この図が、デスクトップ・パーソナル・コンピュータを用いる実施態様の一例を示すのみであることが観察される。諸実施形態を、携帯電話機、ハンドヘルド・オーガナイザ、携帯情報端末（ＰＤＡ）、「パームトップ」デバイス、ラップトップ機、スマートホン、マルチメディア・プレイヤ、ＴＶセットトップ・ボックス、ゲーム機、ウェアラブル・コンピュータなどの他のハイテク・デバイスに簡単に適用しまたは適合させることができる。サウンド回復（すべてのタイプのヘッドホンまたはスピーカ）または視覚的表示（ＬＣＤ、ｏｌｅｄ、レーザ網膜ディスプレイなど）あるいはその両方を含むすべての手段が、本発明を実施することができる。
【０１０９】
本発明のキー・ポイントは、オーディオ沈黙時間を検出するためのオーディオ・レベルをどのようにどこで測定するかの判断である。多数のオーディオ・レベルを、実際に考慮することができる。最初の可能性は、ユーザが実際に知覚するオーディオ・レベルを測定することである（理想的な解決策は、ユーザ（９４０）の耳での測定になるはずである）。さらによい解決策は、ユーザの聴取能力を考慮に入れることに存するはずである。対応するレベルを、できる限りユーザ（９４０）の耳に近いマイクロホン・オーディオ入力（９３０）を用いて測定することができる。第２の可能性は、オーディオ・スピーカ（９２０）でオーディオ・レベルを測定することである。第３の解決策は、オーディオ・プラグ出力（９１０）で基準としてとることである。第４の解決策は、ディスプレイ（９００）に表示されたメディア・プレイヤ・アプリケーション自体から直接にオーディオ・レベルを取り出すことであり（これは、関連する値がソフトウェア・データ内で簡単にアクセス可能なので、より便利な解決策である）、この解決策は、コンピュータに接続されたオーディオ・システムの抽象化を行う。
【０１１０】
オーディオ・レベルを、測定することができるが、シミュレートしまたは予測することもできることが観察される。さらなる開発は、音響環境の予測を考慮に入れることを可能にすることができる（したがって、環境雑音および音響心理学パラメータの測定として）。
【０１１１】
したがって、理想的にはユーザの耳の近くに配置されるマイクロホン・オーディオ入力（９３０）によって実行されるユーザのオーディオ環境の測定および分析は、データの変更に関する最良の時間を判断するのを助けることができる（必要なデータが受信されない場合にデータが解釈され、再生される危険を冒して）。マイクロホンが、特定の重要性を有することが観察され、実際のオーディオ測定またはフィードバックの実行なしにユーザの実際のオーディオ環境を評価する形がないことが既知である。ＤＲＭすなわちディジタル著作権管理は、アナログ信号（スピーカ、ユーザ）を考慮に入れまたは制御することができないことを強調するために「アナログ・ホール（analog hole）」という特定の語彙の下でこの点を指す（チェーンは、ＨＤＭＩのように、正しく制御されるためにフル・ディジタルでなければならない）。実際に、一連の特定のシナリオを想像することができ、スピーカがオフにされている場合に、データ・フロー全体が沈黙であると考えることができる。同一の結論が、スピーカのサウンド・レベルが、ユーザが聞き取ることができないほどに低い場合にも現れる。
【０１１２】
もう１つの実施形態では、本発明は、第２の必要な同期化されたリッチ・メディア・コンポーネントが取り出されるまで第１リッチ・メディア・コンポーネントのオーディオ沈黙中にビデオ再生を低速化することと、前記第２コンポーネントが取り出された時に前記オーディオ沈黙中のビデオ再生を高速化することとによって、同期化されたリッチ・メディア・コンポーネントをメディア・プレイヤ内でバッファリングする方法を開示する。
【０１１３】
さらなる実施形態で、本発明は、データ・フロー、たとえばオーディオ／ビデオ・ストリームを有する隣接文書フレームの同期化に関する。新しいフレームを表示しなければならない瞬間を示すメタデータが、オーディオ／ビデオ・フレームに挿入される。ストリームは、受信器でバッファリングされ、バッファ内容は、メタデータについてスキャンされる。まだ到達していないスライドを示すメタデータが見つかる場合に、システムは、ストール・フェーズに入り、このストール・フェーズ中には、オーディオ／ビデオ・ストリーム内の任意の沈黙時間の長さが延ばされる。オーディオ／ビデオ・ストリーム内で、欠けているスライドにより近くなる点で、沈黙時間が延ばされる係数が、指数関数的に増やされる（すなわち、ビデオ・ストリームは、オーディオ沈黙時間中に複製されたビデオ・フレームを追加することによって低速化される）。期待されるスライドが実際に到着したならば、オーディオ／ビデオ・ストリームの再生は、ストール・フェーズ中にバッファ内に蓄積されたオーディオ／ビデオ・データのバックログをクリアするために、沈黙時間を圧縮することによって高速化される（すなわち、ビデオ・ストリームは、オーディオ沈黙時間中のビデオ・フレームをスキップすることによって高速化される）。言い換えると、本発明は、リッチ・メディア・ファイルの他のメディア要素を取り出している間のオーディオの知覚可能な変更を伴わずにビデオのプレイを低速化または高速化する方法を説明するものである。
【０１１４】
もう１つの実施形態では、本発明は、第２フローの送達レートの変動について補償するためにオーディオ・フローを含む第１フローを加速しまたは減速するためにそのフローの沈黙の時間を延長しまたは圧縮することによる２つのデータ・フローの同期化に関する。本発明は、オーディオ沈黙中にビデオおよびオーディオのフローまたはストリームの両方を低速化し、または高速化する。
【０１１５】
さらなる実施形態で、第１データ・フローは、受信器でバッファリングされ、バッファ内容は、メタデータについてスキャンされる。まだ到着していない第２データ・フローを示すメタデータが見つかる場合には、システムは、ストール・フェーズに入り、このストール・フェーズ中には、第１データ・フロー内のすべての沈黙時間の長さが延ばされる。第２データ・フローが必要である第１データ・フロー内の点が近くなる時に、沈黙時間がそれによって延ばされる係数が、指数関数的に増やされる。期待される第２データ・フローが実際に到着した後に、この２つのデータ・フローの再生は、ストール・フェーズ中にバッファ内で蓄積された追加データのバックログをクリアするために沈黙時間を圧縮することによって加速される。
【技術分野】
【０００１】
本発明は、全般的にはデータ処理に関し、より具体的には、データ・フロー（オーディオ、イメージ、ビデオ、またはコンピュータ・プログラムなど）を同期化するシステムおよび方法に関する。
【背景技術】
【０００２】
増加した帯域幅、ストレージ容量、および計算容量のせいで、コンピュータ・プログラムのユーザは、ますます多くのマルチメディア・コンテンツを制作し、消費する傾向がある。時々リッチ・メディア環境と呼ばれるこれらの環境は、それぞれが異なる性質を有する複数のメディアの使用の特徴がある。これらのコンテンツは、たとえば、プレゼンテーションのスライド、イメージ、ビデオ、アニメーション、グラフィックス、地図、ウェブ・ぺージ、または任意の他のメディア・オブジェクト（アニメーション付きまたはなし）とすることができ、実行可能プログラムおよびその結果のディスプレイさえ含む。したがって、ユーザに表示される最終的な結果のデータ・フローは、複数のメディア・オブジェクトからなる可能性がある。これらのオブジェクトのいずれをも、互いに同期化でき、オブジェクト間の関係を、経時的に変更できることが観察される。
【０００３】
これらのメディア・オブジェクトは、さまざまな手段によって送達される。これらのコンテンツを、ストリーミングすることができ、これらを、しばしば、プログレッシブ・ダウンロード・モードを使用して取り出すことができ、あるいは、前もって完全にダウンロードすることさえできる。実際に、ほとんどの場合に、１つの単一のコンテンツについてさえ、送達のこれらのモードに関して複数のネットワークを使用することができる。制御されないネットワーク遅延は、異なるフローの間の脱同期化（de-synchronization）を意味し、不完全なまたは表示可能ではない最終的なデータ・フローをもたらし得ると思われる。サービス品質に関しては、インターネット上では、経時的なサービスの送達を保証することはできない。状況は、複数のネットワークが使用されるときにさらに悪くなる。その結果、これらすべてのデータ・フローを同期化する手段の必要がある。
【０００４】
技術的現状では、これらの脱同期化を救済する複数の技法が説明されている。
【０００５】
多くの手法は、同期化情報自体を生成する特定の方法に単純に関する。
【０００６】
他の手法は、ネットワーク・トラフィックの不確かさとその輻輳またはボトルネックとを相殺するために、バッファリング機構に焦点を合わせたものである。実際に、古典的手法は、表示に十分なデータを得るためにバッファを使用することである。たとえばストリーミング環境で使用される時に、所定のしきい値は、メディア・プレイヤ内でファイルの再生を開始する前に、絶対的（メガバイト単位）または相対的（ファイル・サイズのパーセンテージ）な量のデータが受信され、蓄積されることを必要とする。これらのしきい値のセットアップは、異なる技法（統計、ルールベースなど）を使用することができる。ネットワーク遅延を動的に予測することを試みる機構およびそれに応じてバッファの深さを適合させることによる機構をも使用することができる。メディア・ストリーミングは、そのようなバッファ機構を利用するが、もう１つの幅広く使用されている手法が、プログレッシブ・ダウンロードとして知られている。ファイルは、古典的にダウンロードされるが、ファイルの再生は、デーが受信されるや否や開始され得、この場合に、古典的な意味でのバッファはもうない。
【０００７】
他の手法は、主にバッファ調整および補償による、オーディオ・データ・フロー（またはストリーム）の、それに関連するビデオ・ストリームとの同期化または再同期化に焦点を合わせたものである。たとえば、Laurence Kelvin Griffitsの出願した米国特許第６２６２７７６号、名称「System and method formaintaining synchronization between audio and video」には、オーディオ・データとビデオ・データとの間の同期化を維持するのを助けるためにビデオ・データのフレームを選択的に捨てるシステムおよび方法が記載されている。この手法に関する主な問題は、オーディオとビデオとの間の同期化にのみ対処し、他の種類のフローに対処しないことである。
【０００８】
同様に、Sirbu,Mihai G.の出願した米国特許出願第２００７００１９９３１Ａ１号、名称「Systemsand methods for re-synchronizing video and audio data」は、ビデオ・データおよびオーディオ・データを再同期化するシステムおよび方法に関する。このシステムおよび方法は、ビデオ・ジッタ・バッファに関連するビデオ・カウントを、事前定義のビデオ・カウントと比較する。オーディオ・ジッタ・バッファに関連するオーディオ・データ内の所与のオーディオ沈黙時間が、ビデオ・カウントが事前定義のビデオ・カウントから所定の量以内になるまで、ビデオ・ジッタ・バッファのビデオ・カウントが事前定義のビデオ・カウントから所定の量の外であることに応答して調整される。主な問題は、前の特許と同一であり、オーディオとビデオとの間の同期化にのみ対処し、他の種類のフローに対処しないことである。
【０００９】
複数のコンテンツおよびネットワークを伴う、上で説明した複雑なメディア環境には、さまざまな着信データ・フローを同期化する手段がない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】米国特許第６２６２７７６号
【特許文献２】米国特許出願第２００７００１９９３１Ａ１号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
メディア・プレイヤ・ソフトウェア・プログラムのユーザは、まさに１つの瞬間に多数のビデオを見ることができるが、同等のことは、サウンドに関しては不可能でないとしてもむずかしい。したがって、オーディオは、同期化の鍵であり、同期化は、オーディオ駆動でなければならない。
【課題を解決するための手段】
【００１２】
したがって、人間の知覚機能のこの特定のプロパティを使用する、具体的には、オーディオ沈黙時間の使用を活用する方法の必要がある。
【００１３】
本発明の第１の態様によれば、バッファ内のデータ・フローを同期化する方法が提供される。オーディオ・データを含む第１データ・フローを受信している間に、第１データ・フローの第１データを第２データ・フローの第２データに関連付ける同期化マークが受信されるや否や、少なくとも１つのオーディオ沈黙時間が、第１データ・フロー内で検出される。同期化マークが、第２データ・フローの関連する第２データの受信の前に受信される場合には、第１データ・フローは、少なくとも１つのオーディオ沈黙時間の持続時間を増やすことによって、バッファ内で変更される。
【００１４】
第１の利益は、オーディオ沈黙時間の使用が、本発明の１つの目的である第２データ・フローの取出のために時間を得ることを可能にすることである。この利益は、ひいては、複数のネットワークから来る複数のデータ・フローに対処するときに非常に興味深い。
【００１５】
オーディオ沈黙を変更すること（非沈黙オーディオ時間を変更しないことによって）の間接的な利益は、変更されたデータ・フローを再生する場合に、それがユーザによって感じ取られる可能性が低いことである。
【００１６】
もう１つの利益は、説明される実施態様が、クライアント側のみであることである。前記方法は、メディア・プレイヤ・アプリケーションによって実行されるのみである。これは、この方法が、クライアント・プレイヤ・ソフトウェアに影響するのみである（サーバ・アーキテクチャでの変更なし、メディア・オーサリング・ツールでの変更なし、ネットワーク・アーキテクチャでの変更なしなど）を意味する。
【００１７】
したがって、さらなる利益は、この方法が、未知のエラー（ネットワーク挙動の不確かさに起因する）の影響を最小にする手段を提供するが、従来技術が、既知のエラー（ジッタなど。ジッタは非常に小さくなる可能性が高い）を補正することだけに関することである。
【００１８】
第２の開発では、前記オーディオ沈黙時間の持続時間は、第２データ・フローが取り出される時に減らされる。
【００１９】
本発明の目的は、フロー変更を補償することである。
【００２０】
第１の利益は、第２データ・フローが間に合って（バッファ・ランニング・ポジション（bufferrunning position）内で）受信される場合に、ゼロサム変更が可能であることである。言い換えると、結果の変更は、互いに打ち消し合う。
【００２１】
さらなる利益は、バッファ内のフローがメディア・プレイヤで演奏されている時に、これらのフローに対して行われる変更を最小化できることである。
【００２２】
第３の開発では、第１データ・フローは、複数のオーディオ沈黙時間を含む。最後に受信されたオーディオ沈黙時間の持続時間は、第２データ・フローの前記第２データが受信されるまで増やされる。
【００２３】
この指数関数的変更の利益は、それが最後の瞬間に行われることである。言い換えると、データがバッファリングされるときに同期化マークがバッファ限度に近くなればなるほど（前記限度は、２つのデータ・フローの２つの同期化された特定のデータの再生に対応する）、第１データ・フローはより大きく変更される。その結果、第２データ・フローの取出のための時間が得られ、処理時間が最適化される。
【００２４】
この開発の第２の利益は、オーディオ沈黙の持続時間が乗算されまたは除算される係数に関する可能性の広い範囲に存する。具体的に言うと、この係数の展開を、線形、指数関数、または任意の他の数学的関数に従うものとすることができる。
【００２５】
第４の開発では、第１データ・フローが複数のオーディオ沈黙時間を含む場合に、少なくとも１つのオーディオ沈黙時間の持続時間は、第２データ・フローの第２データが受信されるまで増やされる。
【００２６】
この開発の利益は、実施態様の可能性の広い範囲を提供することである。第１データ・フローに対して行われる変更を、複数のオーディオ沈黙時間にまたがって分散することができ、使用可能コンピューティング・リソースまたはユーザ経験の質などのパラメータのバランスをとることができる。
【００２７】
この可能な分散のもう１つの利益は、人間の可聴品質知覚または可視品質知覚さえあるいはその両方などのパラメータを考慮に入れることができることである。
【００２８】
もう１つの利益は、コンピューティング・リソースを最適化できることである。たとえば、具体的に言うと、複数のうちの唯一の期間を変更することができる。
【００２９】
この開発のもう１つの利益は、送達制御を間接的に可能にすることである。この利益は、図６の説明で詳細に述べる。
【００３０】
第５の開発では、少なくとも１つのオーディオ沈黙時間の持続時間は、タイムアウト期間が満了するまで増やされる。
【００３１】
利益は、タイムアウトの導入が、先行するものと正確に反対の形で２つの同期化されたフローの再生を制御することを可能にすることである。
【００３２】
第６の開発では、第１データ・フローは、オーディオ／ビデオ・データ・フローである。
【００３３】
第７の開発では、ビデオ・データが挿入される。
【００３４】
本発明の目的は、オーディオ／ビデオ・データ・フローを低速化するのにオーディオ沈黙時間を利用することである。
【００３５】
利益は、第１データ・フローがオーディオ・データのみではなく、オーディオ／ビデオ・データである場合であっても、オーディオ沈黙時間を増やすことができることである。
【００３６】
第８の開発では、ビデオ・データが省略される。
【００３７】
本発明の目的は、オーディオ／ビデオ・データ・フローを高速化するのにオーディオ沈黙時間を利用することである。
【００３８】
利益は、第１データ・フローがオーディオ・データのみではなく、オーディオ／ビデオ・データである場合であっても、オーディオ沈黙時間を減らすことができることである。
【００３９】
第９の開発では、挿入されるビデオ・データは、複製されたフレームまたは補間されたフレームである。
【００４０】
利益は、複製されたフレームが、さらなる計算リソースを全く必要としないことである。これらの複製されたフレームは、たとえば変更の視覚的効果を最小にするように選択することができる（ビデオ・フレームの不連続性は、スタッタをもたらすはずである）。補間されたフレームを使用する場合には、広い範囲の方法を選択することができ、ビデオ品質をさらに高めることができる。
【００４１】
第１０の開発では、検討されるオーディオ沈黙時間は、人間の声オーディオ沈黙または合成音声オーディオ沈黙である。
【００４２】
利益は、説明される方法が、変更されてはならない、または少なくともユーザの知覚に対するより少ない影響を有するために、最も重要なプロパティと考えることのできる声（実際の人間の声であれ、シミュレートされた声または合成音声であれ）に焦点を合わせることである。特に口頭の理解のために、これらの特権付きオーディオ沈黙時間を使用することが、安全であると思われる。
【００４３】
第１１の開発では、オーディオ沈黙時間は、バッファのユーザのオーディオ環境に従って検出され、オーディオ環境は、ソフトウェア・データによって判定されまたはシミュレートされ、あるいはマイクロホンを使用することによって測定される。
【００４４】
利益は、ユーザの実際のオーディオ環境を考慮に入れることができることである。
【００４５】
もう１つの利益は、ソフトウェア・データが、簡単にアクセス可能であることと、非常に単純なしきい値を用いて、オーディオ沈黙時間を判定できることである。
【００４６】
上のパラメータ（沈黙の分布、フレーム挿入の分布、挿入されるフレームの性質、声特性、測定の点・・・）を組み合わせることの利益は、ユーザの視覚的知覚または可聴知覚あるいはその両方を最適化することを可能にすることである。
【００４７】
本発明の第２の態様によれば、本発明の第１の態様による方法の各ステップを実行するように適合された手段を含む装置が提供される。
【００４８】
この装置を非常に簡単に入手でき、したがってこの方法を実行しやすくなることが利点である。
【００４９】
本発明の第３の態様によれば、本発明の第１または第２の態様による方法の各ステップを実行する命令を含むコンピュータリンクド可読媒体が提供される。
【００５０】
この媒体を使用して、さまざまな装置でこの方法を簡単にインストールできることが利点である。
【００５１】
本発明のさらなる利益は、図面および詳細な説明を調べた時に、当業者に明瞭になるであろう。すべての利益が本明細書に組み込まれることが意図されている。
【００５２】
本発明の実施形態を、添付図面を参照してこれから説明する。
【図面の簡単な説明】
【００５３】
【図１】本発明の大域的環境を示す図である。
【図２】本発明が動作するレベルで同期化ユニットを説明するブロック図である。
【図３】本方法を説明する流れ図である。
【図４】データ・フロー、オーディオ沈黙時間、バッファ、および同期化マークを示す図である。
【図５】オーディオ沈黙時間の持続時間の増減の結果の動作の補償を示す図である。
【図６】第２データ・フローが絶対に取り出されない場合を示す図である。
【図７】第１データ・フローがオーディオ／ビデオ・データ・フローである、本発明の実施態様を示す図である。
【図８】オーディオ沈黙時間の検出を示す図である。
【図９】オーディオ沈黙時間検出用の測定諸態様を示す図である。
【発明を実施するための形態】
【００５４】
データ・フローは、イメージ（写真、地図、またはグラフィックス・データなどのスチール・イメージ・・・）、テキスト（電子メール、プレゼンテーション・スライド、チャット・セッション、宣誓証言写し、ウェブ・ページ、クイズ・・・）、ビデオ（アニメーション付きイメージ、フレームのシーケンス、ウェブカム・ビデオ、ＴＶ番組・・・）、マルチメディア文書（リッチ・メディア文書、・・・）、またはプログラム・データ（３Ｄアニメーション、ゲーム、・・・）など、ネットワークによって送信されるデータに対応することができる。ほとんどの場合に、表現データ・フローは、データ・ストリームと同等である。
【００５５】
オーディオ沈黙時間は、たとえば穏やか、静か、平和、または無音もしくは無騒音とさえ特徴を表すことができるサウンドラックの部分またはサウンド・システムを指す。沈黙は、客観的測定が当業者に明白である（低域フィルタ、利得・・・）相対的概念である。
【００５６】
同期化は、本願の目的であり、さまざまな状況にあてはまり得る。非網羅的リストは、タイプ（括弧内の例）すなわち、テキストを伴うオーディオ（歌詞の写しを伴うＭＰ３ソング）、オーディオを伴うオーディオ（ＭＰ３ミキシングまたは電話会話多重化）、イメージを伴うオーディオ（ＭＰ３およびアルバム・ジャケット・イメージ）、ビデオを伴うオーディオ（ポッドキャストおよび話者のビデオ）、テキストを伴うオーディオ−ビデオ（音楽クリップおよび歌詞）、オーディオ−ビデオおよびオーディオ（映画および追加の音楽サウンドトラック）、オーディオ−ビデオおよびイメージ（ビデオキャストおよびスライド、グラフィックス、地図、または任意の他の隣接文書）、ビデオを伴うオーディオ−ビデオ（ビデオキャストおよびｆｌａｓｈアニメーション）、プログラムを伴うオーディオ−ビデオ（ビデオキャストおよび対話型アニメーション）、またはオーディオ−ビデオを伴うオーディオ−ビデオ（芸術、ビデオ・ウォール、ビデオ編集のための２つのビデオの同期化・・・）さえ含む。対向する沈黙時間および非沈黙時間を有する２つのビデオを、本発明を用いて同期できることが観察される。ほとんどの場合に、同期化は、リッチ・メディア・オブジェクトに適用される。リッチ・メディアは、ビデオ、オーディオ、およびアニメーションなどの高められた感覚特徴を利用する、ダイナミックな動きを示す広い範囲の対話型ディジタル・メディアを記述するのに使用される用語である。この動きは、経時的に（たとえば継続的に更新する株式相場表示器）またはユーザ対話に直接応答して（ユーザ制御を可能にするスライドショーと同期化されたウェブキャスト）発生し得る。いわゆるリッチ・メディア・ファイルは、同期化されたおよび同期化されていないデータ・フローの集まりと考えることができる。
【００５７】
バッファは、制御できないネットワーク遅延に起因するフリーズを避けるためにデータを蓄積するのに使用される。バッファ深さ（または長さ）は、通常、これらの遅延を予想し、デバイス制約に対処するサイズにされる。ほとんどの場合に、バッファは、予測されたネットワーク遅延に対処するサイズにされる。非常に予測可能な挙動を有するネットワークでは、バッファを小さくすることができる。逆に（たとえば、インターネット上、または疎結合システムの文脈で、またはサービス品質機構（ＱｏＳ）を有しない任意の他のネットワーク）、ネットワーク遅延は、広い範囲で変化する可能性があり、バッファのサイズは、より重要である必要がある。本発明では、バッファのサイズは、問題ではない。バッファが、経時的に可変深さを有する場合であっても、請求される技術的機構の実施態様が変更されないままになると考えることができる。したがって、図面では、バッファが固定サイズを有すると考えられる。さらに重要なことに、このケースは、現在、バッファを組み込んでいる多数のシステムの現実に対応する。バッファは、ハードウェアまたはソフトウェアのいずれかで実施できるが、バッファの大多数が、現在ソフトウェア実施されていることが観察される。バッファは、通常、ＦＩＦＯ（先入れ先出し）法で使用され、入ってきた順番でデータを出力する。最後に、キャッシュまたはデータ・キャッシング機構は、バッファと同一の機能性に到達することができることが観察される（ほとんどの場合に、キャッシュは、ＲＡＭなどのより高速のアクセスを有する位置にデータを格納する）。
【００５８】
説明を容易にするために、ある図面である要素を識別する符号は、すべての他の図面で同一の要素を表す。
【００５９】
図１に、本発明の大域的環境を示す。
【００６０】
諸実施形態の環境を示す図１に示されているように、データのストレージ手段（１００）、データ・フローがそれを介して送信されるネットワーク（１２０）、本発明がそのレベルで動作する同期化ユニット（１４０）、および同期化されたデータ・フローを解釈するのに使用されるメディア・プレイヤ（１６０）が設けられる。
【００６１】
ストレージ手段（１００）は、複数のサーバにデータを格納するのに使用される。これらのコンポーネントは、すべてがまたは部分的に、暗号化されまたはＤＲＭ保護され得る。データ・キャッシング機構を使用して、コンテンツの送達を加速することもできる。具体的に言うと、単一のコンポーネントを、複数のサーバにまたがってフラグメント化するか分散させることができることが観察される。すべてのデータ・フローは、要求され、異なるネットワーク（１２０）を介して同期化ユニット（１４０）に送信される。同期化の後に、データ・フローは、データ・フローを解釈（たとえば、オーディオ再生またはビデオ表示）する手段を含むメディア・プレイヤ（１６０）に送られる。
【００６２】
格納されたデータをストリーミングすることができるが、いくつかの場合に、ＦＴＰ転送またはデータを転送する他の形をも使用できることが観察される。具体的に言うと、データの送信を、ストリーミングまたはプログレッシブ・ダウンロードのいずれかによって行うことができる。両方の形が、バッファリング機構を必要とする。しかし、ストリーミングの形が、表示されるフレームだけを要求する（ビデオの再生カーソルに従って）のに対して、プログレッシブ・ダウンロードの形は、データ・ファイルのダウンロードを開始することおよび既にダウンロードされたデータを見ることを即座に可能にすることからなる。唯一のネットワークを使用することができるが、複数のネットワークが使用される可能性がより高いことも観察される。ネットワークは、異なる性質を有することができ、動的に変更され得る。たとえば、あるコンポーネントを、まずＧＳＭネットワークを介して要求し、部分的に送信し、使用可能な時に、ファイルの残りの部分をＷＩＦＩネットワークを介して要求することができる。したがって、ファイバ（光および他）、ケーブル（ＡＤＳＬおよび他）、無線（Ｗｉｆｉ、Ｗｉｍａｘ、および他）など、すべての種類のネットワークを、さまざまなプロトコル（ＦＴＰ、ＵＤＰストリーミング、および他）と共に使用することができる。
【００６３】
図２に、本発明が動作するレベルで同期化ユニットを説明するブロック図を示す。
【００６４】
ここで図２を参照するが、図２には、同期化ユニット（１４０）の詳細な構造が示されている。同期化ユニット（１４０）は、データ・フロー・バッファ（２００）、オーディオ沈黙時間検出器（２０２）、同期化マーク受信器（２０４）、データ・フロー変更ユニット（２０６）、およびネットワーク・コントローラ（２０８）を含む。
【００６５】
データ・フロー・バッファ（２００）は、ネットワーク（１２０）によって送信されたデータを受信する。データ・フロー・バッファ（２００）は、複数のデータ・フローをバッファリングし、バッファリングされたデータをオーディオ沈黙時間検出器（２０２）に送るように適合される。前記オーディオ沈黙時間検出器（２０２）は、１つまたは複数のデータ・フロー内のオーディオ沈黙時間を検出するように適合される。オーディオ沈黙時間検出器（２０２）は、同期化マーク受信器（２０４）に接続され、データ・フロー変更ユニット（２０６）に結合される。同期化マーク受信器（２０４）は、１つまたは複数の同期化マークを受信するためにネットワーク（１２０）をリスンする。同期化マーク受信器（２０４）は、オーディオ沈黙時間検出器（２０２）に接続される。データ・フロー変更ユニット（２０６）は、オーディオ沈黙時間検出器（２０２）と相互作用し、オプションで、ネットワーク・コントローラ（２０８）にも結合される。データ・フロー変更ユニット（２０６）は、オーディオ沈黙時間を増やすか減らすことによって、受信されたデータ・フローを変更するように適合される。ネットワーク・コントローラ（２０８）は、データ・フロー・バッファ（２００）およびデータ・フロー変更ユニット（２０６）と相互作用する。ネットワーク・コントローラ（２０８）は、データ・フロー・バッファからネットワーク遅延を測定し、データ・フロー変更ユニット（２０６）を制御するように適合される。
【００６６】
好ましい実施形態では、データ・フロー・バッファ（２００）は、第１着信データ・フローをバッファリングする。同期化マーク受信器（２０４）が第１データ・フローに伴う同期化マークを受信するや否や、オーディオ沈黙時間検出器（２０２）は、オーディオ沈黙時間の分析および検出を開始する。その間に、データ・フロー・バッファ（２００）は、同期化マークによって決定されるとおりに、保留中の必要な第２データ・フローをリスンする。バッファリングされたデータは、データ・フロー変更ユニット（２０６）内で変更される。オーディオ沈黙時間持続時間は、ネットワーク・コントローラとの相互作用に従って増やされ、または減らされる。第１データ・フローの第１データと同期化されなければならない第２データ・フローの第２データと、第１データ・フローの前記第１データとの両方が受信される時に、バッファリングされ同期化されたデータが、メディア・プレイヤ（１６０）での再生のためにバッファ・ランニング・ポジションから出る。
【００６７】
ネットワーク・コントローラ（２０８）がオプションである（同期化は、前記ネットワーク・コントローラなしで働くことができ、データ・フロー・バッファ（２００）とデータ・フロー変更ユニット（２０６）との両方とのネットワーク・コントローラ（２０８）の相互作用は、本発明の性能を改善するのを助ける）ことが強調される。ネットワーク・コントローラ（２０８）を、データ・フロー・バッファ（２００）からのみではなく、ネットワーク遅延を測定するように適合された他の手段（この図には図示せず）に接続できることが観察される。最後に、データ・フロー変更ユニット（２０６）は、そのようなコントローラによって制御されるように適合される（たとえば、遅延が重要である場合に、変更が重要になる）。
【００６８】
図３に、本方法を説明する流れ図を示す。
【００６９】
図３に示されているように、
−第２データ・フローの第２データと同期化される第１データを有する第１データ・フローと、
−第１データ・フローの第１データと第２データ・フローの第２データとの間に同期化マークを受信するステップ（３００）と、
−同期化マークが不在の場合に第１データ・フローを普通にバッファリングし、これを再生するステップ（３０２）と、
−１つまたは複数のオーディオ沈黙時間を検出するステップ（３０４）と、
−第２データ・フローの第２データが受信されるかどうかを確立するステップ（３０６）と、
−検出されたオーディオ沈黙時間の持続時間のうちの１つまたは複数を増やすステップ（３０８）と、
−検出されたオーディオ沈黙時間の持続時間のうちの１つまたは複数を減らすステップ（３１０）と
が提供される。
【００７０】
第１データ・フローは、それに対応するファイルが１つまたは複数のストレージ手段（１００）に格納され、１つまたは複数のネットワーク（１２０）を介して送信されるが、メディア・プレイヤ（１６０）の同期化ユニット（１４０）で受信される。第１データ・フロー内の第１データと第２の保留中のデータ・フローの第２データとの間の同期化マークがステップ（３００）で受信されるや否や、オーディオ沈黙時間が、ステップ（３０４）で検出されつつある。そうでない場合には、第１データ・フローは、ステップ（３０２）に対応して普通にバッファリングされ、再生される。沈黙時間の検出は、第２データ・フローの第２データ（第１データ・フローの第１データと同期化されなければならない）がステップ（３０６）でバッファに受信されるまで継続される。前記第２データ・フローが保留中である間には、バッファリングされた第１データ・フローの検出されたオーディオ沈黙時間のうちの１つまたは複数の持続時間が、ステップ（３０８）で増やされる。同期化されなければならない第２データを含む第２データ・フローのデータが同期化ユニット（１４０）で受信される時には、バッファリングされた第１データ・フローの検出されたオーディオ沈黙時間のうちの１つまたは複数の持続時間が、ステップ（３１０）で減らされる。バッファのストレージ限度に達するまで、データ・フローは、バッファリングされ続ける。その後、同期化されたデータ・フローが、メディア・プレイヤ（１６０）での再生のためにバッファ・ランニング・ポジションから出る。
【００７１】
同期化マークを、必須ではないが、第１データ・フローに埋め込む（たとえばメタ・データ内に）ことができることが観察される。実際に、同期化マークを、タイムコードに基づくものとすることができ、１つまたは複数の独立の他のチャネルによって受信することができる。たとえば、第２ソースから来るスライドショーと同期化される第１ソースからストリーミングされる話者のビデオを含むリアルタイム・ウェブキャストの場合に、同期化マークは、第３ソース（またはネットワーク）を利用することができる。これらの同期化マークは、生イベントの場合に、オン・デマンドで要求され（たとえば、話者自身によって送信され）得る。ほとんどの場合に、そのような同期化マークには、ウェブ・ページのＵＲＬおよび時刻値が封入される。これらを、ブラウザ環境内でクッキーに封入することもできる。
【００７２】
第２データ・フローを、単純に受信でき（送信が外部の独立のサーバによって衝撃を与えられるので）、あるいは、埋め込まれたメタデータによって要求できる（たとえば、第１データ・フロー内または同期化マーク自体内にさえのいずれか）ことをも観察することができる。
【００７３】
図４に、データ・フロー、オーディオ沈黙時間、バッファ、および同期化マークを示す。
【００７４】
図４に示されているように、
−データ・フロー（４００）と、
−白でマークされたオーディオ沈黙時間（４０２）と、
−黒でマークされた非沈黙オーディオ時間（４０４）と、
−同期化マーク（４０６）と、
−バッファ（４０８）の表現と
が提供される。
【００７５】
（４０２）のようなオーディオ沈黙時間と（４０４）のような非沈黙オーディオ時間とを含むデータ・フロー（４００）が、受信され、これらの時間の検出は、図８に関してより詳細に説明する。
【００７６】
バッファは、（４０８）の破線のブロックで表される。バッファ（４０８）の左側は、前記バッファのメモリ限度すなわち、データが再生のためにバッファから解放される点に対応する。バッファ（４０８）の右側は、バッファの入口に対応する。データがバッファリングされる時に、バッファ（４０８）ランニング・ポジションは、この図の左から右へ移動する。
【００７７】
同期化マーク（４０６）は、特定の瞬間に受信される。この同期化マークは、データ・フローの特定のデータを別のデータ・フロー（図示せず）の他の特定のデータと同期化しなければならないことを示す。
【００７８】
図５に、オーディオ沈黙時間の持続時間の増減の結果の動作の補償を示す。
【００７９】
図５に示されているように、追加要素すなわち、
−白でマークされたオーディオ沈黙時間（５００）と、
−白でマークされた変更されたオーディオ沈黙時間（５０２）と、
−処理タスクに関する非常に短い時間期間に対応するεと
と共に、図４と同一の表現が提供される。
【００８０】
時刻ｔ１に、同期化マークが受信される。この同期化マークは、第２データ・フローの第２データを現在のデータ・フローの特定のデータと同期化することを要求する。オーディオ沈黙時間（５００）が検出される。時刻ｔ１＋εに、前記オーディオ沈黙時間の持続時間が、第１時間だけ増やされ、変更されたオーディオ沈黙時間（５０２）がもたらされる。時刻ｔ２に、第２データ・フローの必要なデータが受信される。したがって、時刻ｔ２＋εに、変更されたオーディオ沈黙時間（５０２）の持続時間が、減分によって、もう一度変更され、正確に以前のオーディオ沈黙時間（５００）がもたらされる。したがって、結果の説明された動作は、ゼロサム動作である。
【００８１】
この図では、説明を明瞭にするために、唯一のオーディオ沈黙が図示され、変更される。類似する補償を、複数のオーディオ沈黙時間がある場合に、それらを使用して得ることができることが観察される。これらの時間のいくつかの持続時間を増やすことができ、他の持続時間を減らすことができ、その結果、最終結果は、変更されない総持続時間になる。補償は、正確または不正確にすることができる。これは、データ・フローに対して行われる変更を最小にするための本発明のもう１つの態様である。
【００８２】
図６に、第２データ・フローが絶対に取り出されない場合を示す。
【００８３】
前の図は、必要なデータが間に合って受信される場合に対応し、この図は、求められる（必要な）データが絶対に受信されない、反対の状況を示す。図６に示されているように、追加要素すなわち、
−白でマークされたオーディオ沈黙時間（６００）と、
−白でマークされた変更されたオーディオ沈黙時間（６０２）と、
−白でマークされた再変更されたオーディオ沈黙時間（６０４）と、
−処理タスクに関する非常に短い時間期間に対応するεと
と共に、図４と同一の表現が提供される。
【００８４】
前の図と同様に、時刻ｔ１に、同期化マークが受信される。唯一のオーディオ沈黙時間（６００）の持続時間が、時刻ｔ１＋εに増やされ、変更されたオーディオ沈黙時間（６０２）がもたらされる。時刻ｔ２に、必要なデータが受信されなかったので、持続時間がもう一度増やされる。着信第１データ・フローは、バッファリングされ続け、バッファは、図の左から右へ移動する。沈黙が再生されつつある（図示のバッファの左側）。その後、このプロセスは、それ相応に継続する（６０４）。言い換えると、オーディオ沈黙は、指数関数的に増やされる。
【００８５】
最後に、前の図と同様に、説明を明瞭にするために、唯一のオーディオ沈黙が図示され、変更されることが観察される。この方法の実施態様がどの時間を増やすべきかの選択から利益を得ることができることを除いて同一の機構が、複数のオーディオ沈黙時間が存在する場合に観察されるはずである。好ましい実施形態では、最後に受信されたオーディオ沈黙時間（言い換えると、最後にバッファリングされたオーディオ沈黙時間；図４を参照されたく、図示のバッファの左端に関して図示されている）が増やされる。したがって、増加モデルは、任意の数学関数（線形、定数、指数など）に従うことができる。
【００８６】
この開発の利益は、送達制御を間接的に可能にすることである。同期化されたフローの再生は、必要なデータが受信されない場合には可能ではない（１つまたは複数のオーディオ沈黙が、第２データ・フローの第２データが受信されるまで増やされる。第２データ・フローのこの第２データが絶対に受信されない場合には、第１データ・フローは、バッファのサイズにおける制限に起因して、フリーズしているように見える）。そのような制御は、コンテンツの保護に関して非常に貴重でありえる。第２データ・フローの第２データが、ＤＲＭ（ディジタル著作権管理）権利を付加され、バッファ内に受信されない（たとえば、取り出されず、正しく復号されない）場合には、これは、第１データ・フローの回復を妨げる。そのような保護の頑健性は、多数の類似する必要なデータ・フローの使用からも利益を得る。
【００８７】
必要なデータが絶対に受信されない、このシナリオの結果を救済するために、タイムアウト機構を使用することができる。このタイムアウトは、所定の遅延を使用することができ、あるいは、動的にセット・アップされ得る。１つまたは複数のサーバ（データを送信する）、クライアント（対応するルールを有するメディア・プレイヤ）、ユーザ（同期化されたフローの取出のドロップを指示することができる可能性がある）、または第１データ・フロー自体（埋め込まれたデータを伴う）さえのいずれかが、そのようなタイムアウト機構を含むか、これに衝撃を与えることができることが観察される。
【００８８】
図７に、第１データ・フローがオーディオ／ビデオ・データ・フローである、本発明の実施態様を示す。
【００８９】
図７に示されているように、
−非沈黙オーディオ沈黙時間（７００）と、
−オーディオ沈黙時間（７０２）と、
−変更されたオーディオ沈黙時間（７０４）と、
−ビデオ・データのフレーム（７１０）と、
−挿入された追加のビデオ・フレーム（７１２）と
が提供される。
【００９０】
図７に、オーディオ・データおよびビデオ・データを含むデータ・フローを示す。前記オーディオ・データは、（７０２）に似たオーディオ沈黙時間および（７００）に似た非沈黙オーディオ沈黙時間を含む。前記ビデオ・データは、さらに、（７１０）に似た複数の順次ビデオ・フレームを含み、各フレームは、前記第１データ・フローに属する特定のオーディオ・データに関連する。前記データ・フローを、オーディオ／ビデオ・データ・フローと称する。時刻ｔ１＋εに、オーディオ沈黙時間（７０２）の持続時間が増やされ、変更されたオーディオ沈黙時間（７０４）がもたらされる。（この変更されたオーディオ・データに）対応するビデオ・データは、前記オーディオ沈黙時間に属する前記オーディオ・データに関連するすべてのビデオ・フレームの間に（７１２）に似た追加ビデオ・フレームを挿入することによって変更される。
【００９１】
この図は、実際に、オーディオ沈黙時間が増やされる時に何が起きるのかを示す。視覚的効果（変更されたデータ・フローがたまたま再生される場合の）は、そのオーディオ沈黙時間中のビデオの低速化またはフリーズである。
【００９２】
オーディオ沈黙時間が減らされる（たとえば、必要なデータが受信される時または前の変更を補償するため）、反対のステップ（図面には示さず）について、前に挿入されたフレームが、削除または省略され、いくつかの他の場合には、視覚的効果（変更されたデータを再生する時の）は、ビデオ・リプレイの低速化またはフリーズにすらなる。
【００９３】
したがって、前の図に関して説明し、図示した本発明の諸態様に関するすべての所見は、同様にあてはまる（補償、複数のオーディオ沈黙時間の使用、タイムアウト機構など）。具体的に言うと、図５では、バッファ内の挿入されたフレームと削除されたフレームとの間に補償が見られ、リプレイ（再生）中の視覚的影響がない可能性が高い。図６では、ビデオ・リプレイにおけるフリーズが見られる（タイムアウト機構が使用されない限り）。
【００９４】
追加のビデオ・フレームを挿入するための幅広い選択があることが観察される。たとえば、これらのフレームを、複製されたフレーム（たとえば既存のバッファリングされたフレームの中で選択される）または補間されたフレーム（言い換えると、生成されるフレーム）とすることすらできる。最小の視覚的影響を有するために、ビデオの分析は、挿入すべきフレームの性質とこれらのビデオ・フレームを挿入すべき時間との両方に関して、追加フレームの分配を判断するのを助けることができる。この分析は、オンザフライ（たとえば、バッファ内）で処理することができ、あるいは、所定（この判断ステップを助けるためにメタ・データに埋め込まれる）とすることができる。高ビットレートの特徴があるシーン（たとえば、オーディオ沈黙時間がない場合に少数を伴うアクション・シーン）は、より低いビットレートのシーン（たとえば話のオーディオ沈黙時間を伴うテレビジョン・スピーカ）より使用可能である可能性がより低い。したがって、バッファリングされたデータの分析は、ビデオ・フレームを挿入すべき最良の沈黙時間を判断するのを助けることができる。これらの追加フレームを、複数の使用可能なオーディオ沈黙時間にまたがって分散させることができる（１つの唯一のオーディオ沈黙時間にまたがってさえ、均等に分散させまたはさせない）。
【００９５】
本発明の目的は、最終出力に対する影響を最小にするためにバッファ内のデータに対して行われる大域的変更を最小にすることである。無音の複数の期間にわたる分布は、このケースへの関心を表すことができる。オーディオ沈黙中のバッファ・データ変更を多数の他の要因によって駆動できることが観察される。複数のオーディオ沈黙の中に、好ましくはどの沈黙時間を延長しなければならないのかを判断するために考慮に入れるべき他の要因がある可能性がある。そのうちの１つが、対応するビデオ・データ変更の最小化である。たとえば、爆発のようなアクション・シーンから始まるドキュメンタリーを紹介するじっとしている話者を示すビデオ・シーケンスでは、アクション・シーンのオーディオ沈黙がある場合でも、それらよりも、話者部分のオーディオ沈黙を延長することがはるかにより興味深い可能性がある。
【００９６】
多数の実施態様が可能である。第２データ・フローの取出のための時間を得る必要と出力されるデータに対するできる限り少ない影響を有する必要（以前に行われた変更の補償）との間の妥協を得るために、さまざまな異なるアルゴリズムを選択することができる。すべてのアルゴリズムは、残された時間を考慮に入れなければならず、これは、同期化マークの前のバッファ内に残っている時間が、２つの同期化されたデータ・フローが実際に演奏される必要がある瞬間に対応するバッファの最大サイズに達することを意味する。単純な可能性は、再生の前にバッファ内に残っている時間に対応するしきい値をセットアップすることに存する。保留中のオブジェクト（受信されるべき第２データ・フロー）があり、再生の前の残された時間が前記しきい値を超える場合には、ビデオ・データまたはオーディオ・データは、バッファ内で変更されず、次のビデオ・フレームがプレイされる。対照的に、残された時間がしきい値より小さい場合には、別のテストが実行され、残された時間がしきい値を２で割ったものより小さい場合には、ビデオ・リプレイ速度も２で割られ（これは、現在のフレームを１回リプレイすることによって達成される）残された時間がしきい値を２で割ったものを超える場合には、ビデオ・リプレイ速度を４で割る（これは、ビデオ・フレームを３回リプレイすることによって達成される）。フレームのリプレイおよびフレームのコピーの追加が、同一の意味を有することが観察される。
【００９７】
最後に、同一の観察（フレームの性質、分布、視覚的影響、ビットレートなど）を、フレームが削除されまたは省略される反対の動作について行うことができる。やはり、削除されるフレームが、必ずしも以前に挿入されたフレームではないことが強調される。
【００９８】
図８に、オーディオ沈黙時間の検出を示す。
【００９９】
図８に示されているように、
−データ・フロー（４００）と、
−非沈黙オーディオ時間（４０２）および（８００）と、
−オーディオ沈黙時間（４０４）および（８１０）と
が提供される。
【０１００】
説明を明瞭にするために、古典的オーディオ・スペクトルを示す別の表現が使用されている。前に使用された図との対応が、示されている。
【０１０１】
オーディオ沈黙時間は、明らかに相対的であり、測定可能性に依存する。人が、何がオーディオ沈黙時間と考えられるべきかを判断しなければならない。したがって、オーディオ沈黙時間の検出は、前記沈黙を判定するのに当業者によって使用される通常の形を指す。これは、複数の既知の方法によって達成でき、最も単純な解決策は、しきい値が選択され、しきい値未満のオーディオ・シーケンスがオーディオ沈黙と考えられることを特徴とする。しきい値は、デシベル（ｄＢ）単位、ワット単位などとすることができる。
【０１０２】
図８に関して示されているように、データ・フロー（４００）が分析され、所定のしきい値より小さい値を有する非沈黙オーディオ時間（８００）は、オーディオ沈黙時間（４０４または８１０）と考えられる。したがって、ステップ（ａ）での分析の前に、データ・フロー（４００）は、未分析オーディオ・データを含み、ステップ（ｂ）での分析の後に、このデータ・フローは、オーディオ沈黙時間（４０４）を含み、残りのデータは、まだ非沈黙オーディオ時間（４０２）と考えられる。
【０１０３】
大きい値（たとえば、オーディオ信号のピークまたは平均値と比較して）を有するしきい値の使用は、興味深い。というのは、これが、多数のオーディオ・シーケンスがオーディオ沈黙と考えられ、その結果、同期化されたフローの取出のための時間を得るより多くの機会が生じることを暗示するからである。逆に、相対的に少数の沈黙時間が判断される場合には、本発明の説明される機構を使用する、より少数の機会が生じる。
【０１０４】
スプリッタの使用が、本発明の実施態様のために必要になる場合があることが観察される。たとえば、ＭＰＥＧ２またはＭＰＥＧ４データ・フロー（ストリーム）内では、オーディオ・データおよびビデオ・データは、同一ストリームに埋め込まれる。オーディオ沈黙時間を検出しまたは判定することができるために、オーディオ・データをビデオ・データから分離することが必要になる場合がある。
【０１０５】
図９に、オーディオ沈黙時間検出用の測定諸態様を示す。
【０１０６】
図９に示されているように、
−サウンド・カード、スクリーン・ディスプレイ、キーボード、およびポインティング・デバイスを有する中央ユニットを
−メディア・プレイヤ・アプリケーションのディスプレイ（９００）
と共に含むコンピュータと、
−オーディオ・プラグ出力（９１０）と、
−オーディオ・スピーカ（９２０）と、
−マイクロホン・オーディオ入力（９３０）と、
−ユーザ（９４０）と
が提供される。
【０１０７】
コンピュータの中央ユニットは、メディア・プレイヤ（１６０）を実行し、このメディア・プレイヤは、ディスプレイ（９００）に表示される。前記コンピュータ内に組み込まれたオーディオ・カードは、オーディオ信号をオーディオ・プラグ出力（９１０）に送達する。代替案では、オーディオ・カードは、オーディオ・スピーカ（９２０）に接続され、マイクロホン・オーディオ入力（９３０）も、前記オーディオ・カードに接続される。ユーザ（９４０）は、オーディオを聞いているかビデオを見ている。
【０１０８】
この図が、デスクトップ・パーソナル・コンピュータを用いる実施態様の一例を示すのみであることが観察される。諸実施形態を、携帯電話機、ハンドヘルド・オーガナイザ、携帯情報端末（ＰＤＡ）、「パームトップ」デバイス、ラップトップ機、スマートホン、マルチメディア・プレイヤ、ＴＶセットトップ・ボックス、ゲーム機、ウェアラブル・コンピュータなどの他のハイテク・デバイスに簡単に適用しまたは適合させることができる。サウンド回復（すべてのタイプのヘッドホンまたはスピーカ）または視覚的表示（ＬＣＤ、ｏｌｅｄ、レーザ網膜ディスプレイなど）あるいはその両方を含むすべての手段が、本発明を実施することができる。
【０１０９】
本発明のキー・ポイントは、オーディオ沈黙時間を検出するためのオーディオ・レベルをどのようにどこで測定するかの判断である。多数のオーディオ・レベルを、実際に考慮することができる。最初の可能性は、ユーザが実際に知覚するオーディオ・レベルを測定することである（理想的な解決策は、ユーザ（９４０）の耳での測定になるはずである）。さらによい解決策は、ユーザの聴取能力を考慮に入れることに存するはずである。対応するレベルを、できる限りユーザ（９４０）の耳に近いマイクロホン・オーディオ入力（９３０）を用いて測定することができる。第２の可能性は、オーディオ・スピーカ（９２０）でオーディオ・レベルを測定することである。第３の解決策は、オーディオ・プラグ出力（９１０）で基準としてとることである。第４の解決策は、ディスプレイ（９００）に表示されたメディア・プレイヤ・アプリケーション自体から直接にオーディオ・レベルを取り出すことであり（これは、関連する値がソフトウェア・データ内で簡単にアクセス可能なので、より便利な解決策である）、この解決策は、コンピュータに接続されたオーディオ・システムの抽象化を行う。
【０１１０】
オーディオ・レベルを、測定することができるが、シミュレートしまたは予測することもできることが観察される。さらなる開発は、音響環境の予測を考慮に入れることを可能にすることができる（したがって、環境雑音および音響心理学パラメータの測定として）。
【０１１１】
したがって、理想的にはユーザの耳の近くに配置されるマイクロホン・オーディオ入力（９３０）によって実行されるユーザのオーディオ環境の測定および分析は、データの変更に関する最良の時間を判断するのを助けることができる（必要なデータが受信されない場合にデータが解釈され、再生される危険を冒して）。マイクロホンが、特定の重要性を有することが観察され、実際のオーディオ測定またはフィードバックの実行なしにユーザの実際のオーディオ環境を評価する形がないことが既知である。ＤＲＭすなわちディジタル著作権管理は、アナログ信号（スピーカ、ユーザ）を考慮に入れまたは制御することができないことを強調するために「アナログ・ホール（analog hole）」という特定の語彙の下でこの点を指す（チェーンは、ＨＤＭＩのように、正しく制御されるためにフル・ディジタルでなければならない）。実際に、一連の特定のシナリオを想像することができ、スピーカがオフにされている場合に、データ・フロー全体が沈黙であると考えることができる。同一の結論が、スピーカのサウンド・レベルが、ユーザが聞き取ることができないほどに低い場合にも現れる。
【０１１２】
もう１つの実施形態では、本発明は、第２の必要な同期化されたリッチ・メディア・コンポーネントが取り出されるまで第１リッチ・メディア・コンポーネントのオーディオ沈黙中にビデオ再生を低速化することと、前記第２コンポーネントが取り出された時に前記オーディオ沈黙中のビデオ再生を高速化することとによって、同期化されたリッチ・メディア・コンポーネントをメディア・プレイヤ内でバッファリングする方法を開示する。
【０１１３】
さらなる実施形態で、本発明は、データ・フロー、たとえばオーディオ／ビデオ・ストリームを有する隣接文書フレームの同期化に関する。新しいフレームを表示しなければならない瞬間を示すメタデータが、オーディオ／ビデオ・フレームに挿入される。ストリームは、受信器でバッファリングされ、バッファ内容は、メタデータについてスキャンされる。まだ到達していないスライドを示すメタデータが見つかる場合に、システムは、ストール・フェーズに入り、このストール・フェーズ中には、オーディオ／ビデオ・ストリーム内の任意の沈黙時間の長さが延ばされる。オーディオ／ビデオ・ストリーム内で、欠けているスライドにより近くなる点で、沈黙時間が延ばされる係数が、指数関数的に増やされる（すなわち、ビデオ・ストリームは、オーディオ沈黙時間中に複製されたビデオ・フレームを追加することによって低速化される）。期待されるスライドが実際に到着したならば、オーディオ／ビデオ・ストリームの再生は、ストール・フェーズ中にバッファ内に蓄積されたオーディオ／ビデオ・データのバックログをクリアするために、沈黙時間を圧縮することによって高速化される（すなわち、ビデオ・ストリームは、オーディオ沈黙時間中のビデオ・フレームをスキップすることによって高速化される）。言い換えると、本発明は、リッチ・メディア・ファイルの他のメディア要素を取り出している間のオーディオの知覚可能な変更を伴わずにビデオのプレイを低速化または高速化する方法を説明するものである。
【０１１４】
もう１つの実施形態では、本発明は、第２フローの送達レートの変動について補償するためにオーディオ・フローを含む第１フローを加速しまたは減速するためにそのフローの沈黙の時間を延長しまたは圧縮することによる２つのデータ・フローの同期化に関する。本発明は、オーディオ沈黙中にビデオおよびオーディオのフローまたはストリームの両方を低速化し、または高速化する。
【０１１５】
さらなる実施形態で、第１データ・フローは、受信器でバッファリングされ、バッファ内容は、メタデータについてスキャンされる。まだ到着していない第２データ・フローを示すメタデータが見つかる場合には、システムは、ストール・フェーズに入り、このストール・フェーズ中には、第１データ・フロー内のすべての沈黙時間の長さが延ばされる。第２データ・フローが必要である第１データ・フロー内の点が近くなる時に、沈黙時間がそれによって延ばされる係数が、指数関数的に増やされる。期待される第２データ・フローが実際に到着した後に、この２つのデータ・フローの再生は、ストール・フェーズ中にバッファ内で蓄積された追加データのバックログをクリアするために沈黙時間を圧縮することによって加速される。
【特許請求の範囲】
【請求項１】
第１データ・フローを受信するステップであって、前記第１データ・フローは、オーディオ・データを含む、ステップと、
同期化マークを受信するステップであって、前記同期化マークは、前記第１データ・フローの第１データを第２データ・フローの第２データに関連付ける、ステップと、
前記第１データ・フロー内の少なくとも１つのオーディオ沈黙時間を検出するステップと、
前記同期化マークが前記第２データ・フローの前記第２データの受信の前に受信される時に前記少なくとも１つのオーディオ沈黙時間の持続時間を増やすステップと
を含む、データ・フローを同期化する方法。
【請求項２】
少なくとも１つの前記オーディオ沈黙時間の持続時間を減らすステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１データ・フローが、複数のオーディオ沈黙時間を含み、最後に受信されたオーディオ沈黙時間の持続時間が、前記第２データ・フローの前記第２データが受信されるまで増やされる、請求項１ないし２のいずれかに記載の方法。
【請求項４】
前記少なくとも１つのオーディオ沈黙時間の持続時間が、前記第２データ・フローの前記第２データが受信されるまで増やされる、請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記少なくとも１つのオーディオ沈黙時間の持続時間が、タイムアウト期間が満了するまで増やされる、請求項１ないし４のいずれかに記載の方法。
【請求項６】
前記第１データ・フローが、オーディオ／ビデオ・データ・フローである、請求項１ないし５のいずれかに記載の方法。
【請求項７】
ビデオ・データを挿入するステップをさらに含む、請求項６に記載の方法。
【請求項８】
ビデオ・データを省略するステップをさらに含む、請求項６に記載の方法。
【請求項９】
追加されるビデオ・データが、複製されたフレームまたは補間されたフレームである、請求項７に記載の方法。
【請求項１０】
前記オーディオ沈黙時間が、人間の声オーディオ沈黙または合成音声オーディオ沈黙である、請求項１ないし９のいずれかに記載の方法。
【請求項１１】
前記オーディオ沈黙時間が、バッファのユーザのオーディオ環境に従って検出され、前記環境が、ソフトウェア・データによって判定されまたはシミュレートされ、あるいはマイクロホンを使用して測定される、請求項１ないし１０のいずれかに記載の方法。
【請求項１２】
請求項１ないし１１のいずれか一項に記載の方法の各ステップを実行するように適合された手段を含む装置。
【請求項１３】
前記手段が、バッファをさらに含み、前記第１データ・フローが、前記バッファによって受信され、少なくとも１つの前記オーディオ沈黙時間が、前記バッファ内に受信された前記第１データ・フロー内で検出され、前記同期化マークが前記第２データ・フローの前記第２データの受信の前に受信される時に前記少なくとも１つのオーディオ沈黙時間の持続時間を増やす前記ステップが、前記バッファ内で実施される、請求項１２に記載の装置。
【請求項１４】
前記手段が、ネットワーク・コントローラをさらに含み、前記ネットワーク・コントローラが、ネットワーク遅延を測定し、１つまたは複数の前記オーディオ沈黙時間の持続時間の増加または減少を制御する、請求項１３に記載の装置。
【請求項１５】
コンピュータ上で実行される時に請求項１ないし１１のいずれか一項に記載の方法のステップを実行する命令を含むコンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行される時の、コンピュータ・プログラム。
【請求項１６】
請求項１５に記載のコンピュータ・プログラムをその上に符号化されたコンピュータ可読媒体。
【請求項１】
第１データ・フローを受信するステップであって、前記第１データ・フローは、オーディオ・データを含む、ステップと、
同期化マークを受信するステップであって、前記同期化マークは、前記第１データ・フローの第１データを第２データ・フローの第２データに関連付ける、ステップと、
前記第１データ・フロー内の少なくとも１つのオーディオ沈黙時間を検出するステップと、
前記同期化マークが前記第２データ・フローの前記第２データの受信の前に受信される時に前記少なくとも１つのオーディオ沈黙時間の持続時間を増やすステップと
を含む、データ・フローを同期化する方法。
【請求項２】
少なくとも１つの前記オーディオ沈黙時間の持続時間を減らすステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記第１データ・フローが、複数のオーディオ沈黙時間を含み、最後に受信されたオーディオ沈黙時間の持続時間が、前記第２データ・フローの前記第２データが受信されるまで増やされる、請求項１ないし２のいずれかに記載の方法。
【請求項４】
前記少なくとも１つのオーディオ沈黙時間の持続時間が、前記第２データ・フローの前記第２データが受信されるまで増やされる、請求項１ないし３のいずれかに記載の方法。
【請求項５】
前記少なくとも１つのオーディオ沈黙時間の持続時間が、タイムアウト期間が満了するまで増やされる、請求項１ないし４のいずれかに記載の方法。
【請求項６】
前記第１データ・フローが、オーディオ／ビデオ・データ・フローである、請求項１ないし５のいずれかに記載の方法。
【請求項７】
ビデオ・データを挿入するステップをさらに含む、請求項６に記載の方法。
【請求項８】
ビデオ・データを省略するステップをさらに含む、請求項６に記載の方法。
【請求項９】
追加されるビデオ・データが、複製されたフレームまたは補間されたフレームである、請求項７に記載の方法。
【請求項１０】
前記オーディオ沈黙時間が、人間の声オーディオ沈黙または合成音声オーディオ沈黙である、請求項１ないし９のいずれかに記載の方法。
【請求項１１】
前記オーディオ沈黙時間が、バッファのユーザのオーディオ環境に従って検出され、前記環境が、ソフトウェア・データによって判定されまたはシミュレートされ、あるいはマイクロホンを使用して測定される、請求項１ないし１０のいずれかに記載の方法。
【請求項１２】
請求項１ないし１１のいずれか一項に記載の方法の各ステップを実行するように適合された手段を含む装置。
【請求項１３】
前記手段が、バッファをさらに含み、前記第１データ・フローが、前記バッファによって受信され、少なくとも１つの前記オーディオ沈黙時間が、前記バッファ内に受信された前記第１データ・フロー内で検出され、前記同期化マークが前記第２データ・フローの前記第２データの受信の前に受信される時に前記少なくとも１つのオーディオ沈黙時間の持続時間を増やす前記ステップが、前記バッファ内で実施される、請求項１２に記載の装置。
【請求項１４】
前記手段が、ネットワーク・コントローラをさらに含み、前記ネットワーク・コントローラが、ネットワーク遅延を測定し、１つまたは複数の前記オーディオ沈黙時間の持続時間の増加または減少を制御する、請求項１３に記載の装置。
【請求項１５】
コンピュータ上で実行される時に請求項１ないし１１のいずれか一項に記載の方法のステップを実行する命令を含むコンピュータ・プログラムであって、前記コンピュータ・プログラムがコンピュータ上で実行される時の、コンピュータ・プログラム。
【請求項１６】
請求項１５に記載のコンピュータ・プログラムをその上に符号化されたコンピュータ可読媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２０１０−５３９７３９（Ｐ２０１０−５３９７３９Ａ）
【公表日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願番号】特願２０１０−５２２２７４（Ｐ２０１０−５２２２７４）
【出願日】平成２０年６月１７日（２００８．６．１７）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５７５９３
【国際公開番号】ＷＯ２００９／０２７１２８
【国際公開日】平成２１年３月５日（２００９．３．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
２．ＧＳＭ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２２年１２月１６日（２０１０．１２．１６）
【国際特許分類】
【出願日】平成２０年６月１７日（２００８．６．１７）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０５７５９３
【国際公開番号】ＷＯ２００９／０２７１２８
【国際公開日】平成２１年３月５日（２００９．３．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
２．ＧＳＭ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]