JP2014529812A - マルチメディア・ストリームの適応トランスコーディングの方法及び装置 - Google Patents

Abstract

クライアント機器による選択用に、出力コンテンツ・ストリームの多数の代替バージョンをクライアント機器に提示することと、入力コンテンツ・ストリームを２つ以上のセグメントに分割することとを含む、対応する入力コンテンツ・ストリームから適応的にトランスコーディングされた出力コンテンツ・ストリームをストリーミングする方法。上記提示するステップの前に、入力コンテンツ・ストリームの少なくとも第１のセグメントが、クライアント機器に提示される多数の代替バージョンのうちの少なくとも１つのバージョンに対応する出力コンテンツ・ストリームの少なくとも１つの対応するセグメントにトランスコーディングされる。出力コンテンツ・ストリームの選択されたバージョンについてクライアント機器から要求を受信すると、上記提示するステップの前に、トランスコーディングされて記憶された、クライアント機器に提示される多数の代替バージョンのうちの少なくとも１つのバージョンに対応する出力コンテンツ・ストリームの少なくとも１つの対応するセグメントのうちの最初のものを用いてストリーミングを開始する。入力コンテンツ・ストリームの次のセグメントの、クライアント機器によって選択されたバージョンへのトランスコーディングを制御するトランスコーディング・パラメータを上記要求から抽出して、要求されたバージョンにトランスコーディングされた上記次のセグメントをクライアントにストリーミングする。

Description

本発明は、マルチメディア・ストリーム、特にオーディオ・ストリーム及び／又はビデオ・ストリームの適応トランスコーディングの方法及び装置に関する。

オーディオ・ストリーム及び／又はビデオ・ストリームは、ユーザにより、様々な異なる機器の使用によって消費されうる。特にビデオ・ストリームは、再生機器のスクリーンのサイズに適応化されたフォーマット又は表現を必要とすることがある。オーディオ・ストリームも、同様に、再生機器によって設定された諸制限の適用を受けることがある。しかしながら、以下では、ビデオ・ストリームに焦点を合わせて本発明を提示する。

コンテンツがストリーミングされる接続のバリエーションにより、任意の種類のコンテンツのストリーミングの適応化が必要とされることもある。例えば、無線接続の場合、スループットが輻輳によって変動したり、受信状態が受信機器のローミングによって変動したりすることがある。

コンテンツの適応ストリーミングについての様々な実装が提案されている。例えば、米国カリフォルニア州のアップル社の実装は、「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」又は「ＨＬＳ」としても知られている。この実装は、Ｒ．Ｐａｎｔｏｓ氏によって解説されている（“ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ，”ＩＥＴＦ， Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ Ｖｅｒｓｉｏｎ ５ （ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０５）， Ｎｏｖｅｍｂｅｒ ２０１０）。

他の実装が、マイクロソフト（登録商標）によって提示され、「Ｓｉｌｖｅｒｌｉｇｈｔ Ｓｍｏｏｔｈ ｓｔｒｅａｍｉｎｇ」として知られている。この実装は、「ＩＩＳ ｓｍｏｏｔｈ ｓｔｒｅａｍｉｎｇ ｔｅｃｈｎｉｃａｌ ｏｖｅｒｖｉｅｗ」において解説されている。詳細は、ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｄｏｗｎｌｏａｄｓ／ｄｅｔａｉｌｓ．ａｓｐｘ？ｄｉｓｐｌａｙｌａｎｇ＝ｅｎ＆ＦａｍｉｌｙＩＤ＝０３ｄ２２５８３−３ｅｄ６−４４ｄａ−８４６４−ｂ１ｂ４ｂ５ｃａ７５２０からオンラインで入手できる。

更に他の実装が、アドビ・システムズ社よって提示され、「Ａｄｏｂｅ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ」という名称で知られている。詳細は、「ＨＴＴＰ ｄｙｎａｍｉｃ ｓｔｒｅａｍｉｎｇ ｏｎ ｔｈｅ Ａｄｏｂｅ Ｆｌａｓｈ ｐｌａｔｆｏｒｍ」という文献において解説されており、これは、ｈｔｔｐ：／／ｗｗｗ．ａｄｏｂｅ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｈｔｔｐｄｙｎａｍｉｃｓｔｒｅａｍｉｎｇ／ｐｄｆｓ／ｈｔｔｐｄｙｎａｍｉｃｓｔｒｅａｍｉｎｇ ｗｐ ｕｅ．ｐｄｆからオンラインで入手できる。

規格化の作業が、ＳＡ４の部会内の３ＧＰＰによって、及び、ＭＰＥＧ内の「Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ」（ＤＡＳＨ） の部会によって、現在も行われている。この作業についての詳細は、Ｔ． Ｓｔｏｃｋｈａｍｍｅｒ氏によって公開されている（“Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ −ｓｔａｎｄａｒｄｓ ａｎｄ ｄｅｓｉｇｎ ｐｒｉｎｃｉｐｌｅｓ”， ｉｎ Ｐｒｏｃ． ｏｆ ｔｈｅ ２０１１ ＡＣＭ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｓｙｓｔｅｍｓ （ＭＭＳｙｓＥ ２０１１）， Ｆｅｂｒｕａｒｙ ２０１１， ｐｐ．１５７−１６８）。

既知の実装の全てにおいて、サーバは、ストリーミング対象のコンテンツを、予めコード化された状態で、かつ、より大きいコンテナ・ファイルから抽出できる個別のチャンクとして又はセグメントとして配信される準備ができている状態で、記憶している必要がある。

Ｋｅｖｉｎ Ｊ． Ｍａ氏、Ｒａｄｉｍ Ｂａｒｔｏｓ氏、Ｓｗａｐｎｉｌ Ｂｈａｔｉａ氏、及び、Ｒａｊ Ｎａｉｒ氏が、トランスコーディングを用いたコンテンツの適応ストリーミングを開示している（“Ｍｏｂｉｌｅ ｖｉｄｅｏ ｄｅｌｉｖｅｒｙ ｗｉｔｈ ＨＴＴＰ”， ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ， Ａｐｒｉｌ ２０１１， ｐｐ．１６６−１７４）。トランスコーディングは、マルチメディア・コンテンツを１つのフォーマットから別のフォーマットに変換するという意味で使用される。

また、Ｋｕｅｉ−Ｃｈｕｎｇ Ｃｈａｎｇ氏、Ｒｅｎ−Ｙｏ Ｗｕ氏、及び、Ｔｉｅｎ−Ｆｕ Ｃｈｅｎ氏が、ストリーミング・ビデオのトランスコーディングについて論述している（“Ｅｆｆｉｃｉｅｎｔ ｓｅｇｍｅｎｔ−ｂａｓｅｄ ｖｉｄｅｏ ｔｒａｎｓｃｏｄｉｎｇ ｐｒｏｘｙ ｆｏｒ ｍｏｂｉｌｅ ｍｕｌｔｉｍｅｄｉａ ｓｅｒｖｉｃｅｓ”， ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｕｌｔｉｍｅｄｉａ ａｎｄ Ｅｘｐｏ， （ＩＣＭＥ） ２００５， ｐｐ．７５５−７５８）。

本発明の１つの目的は、トランスコーディングされたストリーミング・コンテンツについてのユーザ・エクスペリエンス（ユーザ体験）を改善し、同時に、サーバ及び／又はシステムの要件を減らすことである。

この目的は、添付の特許請求の範囲に記載の方法及び装置によって達成される。各従属請求項には、これらの方法及び装置の実施態様及び発展態様が記載されている。

ストリーミングされたコンテンツの各々のアイテムについて、できるだけ良好なユーザ体験を得るために、ユーザは、使用したい再生機器にとって適切なコンテンツ・フォーマットを選択することが可能である。この選択は、送信、特に同一送信チャネルを介する同時実行の複数の送信に必要な帯域幅や、この送信帯域幅に関連したコストを含む（ただし、これらには限定されない）、その他の検討事項に基づくこともある。更に、ペイ・コンテンツが、表現の品質によって決まる料金体系を有することがある。

上述のように、コンテンツ・ストリームは、通常、様々なフォーマットと品質でサーバ、例えば、ＨＴＴＰサーバに記憶されている。最も高い品質は大抵ビットレートが高く、最も低い品質は大抵ビットレートが低い。これによって、多数の異なる端末、すなわち、クライアント機器へのコンテンツの配信が可能になるが、クライアント機器は、これに加えて、変動の激しいネットワーク状態の影響下にある。１つのコンテンツ・ストリーム全体は、複数のチャンクに分割され、これらのチャンクは、クライアント機器、例えばビデオ・プレーヤ又は端末が２つのチャンク間で品質レベルを円滑に切り替えることができるように選択される。このような切り換えは、ネットワーク接続の状態が変動する場合、また、ユーザが、コンテンツを消費し続けている間に、再生機器の変更を望む場合に行われることがある。その結果、ビデオ品質が再生中に変わり、稀にフリーズすることがある。

サーバ上で使用不可の品質でのコンテンツがユーザによって要求されると、コンテンツ・ストリーム、すなわち、そのチャンクは、要求されたフォーマット及び品質にトランスコーディングされて、ユーザに送信される。しかしながら、コンテンツのトランスコーディングは時間を必要とし、その結果、ユーザによって要求されたコンテンツの再生が遅延することになる。たとえ最初の僅かのビデオ・チャンクをトランスコーディングして直ぐに送信でき、更に、それ以降のビデオ・チャンクのトランスコーディングをバックグラウンドで続けることができても、そのような遅延は、サービスについてのユーザ体験の知覚品質を低減するので、一般的に望ましくない。

この遅延は、サーバと再生機器との間、又は、トランスコーディング・ゲートウェイと再生機器との間のネットワーク接続が変動することによって、サーバ又はゲートウェイが再生機器への接続上でコンテンツのデータ・レートを低減することを強いられる場合に、特に顕著になる。この遅延は、同様に、特に、コンテンツ・プロバイダの有料プレミアム・サービスであるかもしれない、シームレスのプレーバック・エクスペリエンス（再生体験）のために、ユーザが、コンテンツを消費し続けている間に再生機器を変更する場合に顕著になる。例えば、ユーザが、自宅で大きいスクリーンでビデオを見始めて、そのビデオが終了していないのに、別の場所に移動することを決めるかもしれない。そのビデオの残りの部分は、異なるスクリーン・サイズと再生機能を有するモバイル機器で再生することも可能である。その場合、ストリームをその新たな再生機器に転送することが必要であるのみならず、トランスコーディングのパラメータを変更することも必要になる。この変更は、もし新たなフォーマットでのビデオのコピー、又は、そのチャンクが、即座の切り替えに直ちに供されなければ、ストリームに別の遅延をもたらすことになる。

一般的に、コンテンツ・ストリームは、クライアント機器、すなわち、再生機器に対して、とりわけ、各々がそれぞれ品質レベル、ビットレート、フォーマット等に関する、いわゆる「表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）」のセットを提供するストリーム記述子として告知される。各々の完全な表現は、望ましくは互いに等しい時間（ｄｕｒａｔｉｏｎ）の一連のチャンクを含み、そしてクライアントによる選択用に添付された一組の記述要素を有する。各々のチャンクは、個別のＵＲＬによってアクセス可能である。

ライブ・ストリーミングをサポートするために、告知は、対応するコンテンツ・ストリームの一部分だけを記述してもよい。この場合、告知される一部分は、定期的に更新する必要がある。

遅延は、前述のように、サーバ上のコンテンツのコピーを全ての予想されるフォーマットに保持することによって回避してもよい。しかしながら、この手法は、極めて大きい記憶装置を必要とし、特に、たまにしか要求されないフォーマットについては非効率的であり、それため望ましくない。

最も高い品質でのコンテンツのコピーが１つだけ利用可能である場合、遅延を回避するもう１つの方法は、要求されたコンテンツを予想可能な全てのフォーマットに同時にトランスコーディングできるトランスコーダを使用することである（上述の説明を参照）。しかしながら、そのようなトランスコーダは、極めて高い処理能力を必要とし、ほぼ間違なく非常に高いコストがかかり、そのため、これも望ましくない。

本発明の一態様によれば、クライアント機器が、所望のコンテンツについての要求をサーバに送る。この要求には、クライアント機器が再生のために取り扱うことができるフォーマット、品質、帯域幅、データ・レート等の指標が含まれており、また、好ましいフォーマットの指標も含まれることもある。この要求は、各々が１つのフォーマット、データ・レート又は品質、あるいは、それらの組み合わせを表している複数のＨＴＴＰリンクのうちの１つを選択する形態で作成することができる。各々のリンクは、トランスコーダに対して、所望の選択されたプロパティを有するコンテンツ・ストリームを生成するのに適切なトランスコーダ・パラメータを設定できるようにする情報を伝える。換言すれば、サーバによって提供される選択ページは、ストリーミング・コンテンツをどのように受信できるかの記述を、例えば、選ぶべき利用可能なオプションのリストとして、クライアント機器に提供する。

ストリーミング・コンテンツは、チャンクのシーケンスの形態で、クライアントに提供される。各々のチャンクは、個別の要求、例えばＨＴＴＰ要求によって、あたかも小さいファイルであるかのように取り出される。各々のチャンクについて、クライアント機器は、どのビットレート、品質、解像度、フォーマット等が適切であるかを、特にネットワーク接続のプロパティに関して決定し、それに応じて、チャンクを、特定のリンク・アドレス、すなわちＵＲＬによって要求する。したがって、様々なビットレート、フォーマット、品質等の各々についてのストリーミング・コンテンツのそれぞれのチャンクについて、固有のＵＲＬが存在する。個別に要求されたチャンクは、コンテンツ・ストリームが形成されるように、次々と再生される。

上述のように、特にライブのストリーミング・コンテンツについて、また、その他のタイプのオン・デマンドのコンテンツについても、ライブ・サーバは、全ての予想可能な品質、フォーマット、データ・レート等でのチャンクをリアルタイムで準備する必要がある。一般的に、結果的に得られた様々なチャンクは、少なくとも一時的に記憶され、要求に応じて、例えばウェブ・サーバを介して配信される。サーバにおけるトランスコーディング及び／又は記憶のリソース（資源）は限られており、このことがそのような手法についての障害になる。単に次のチャンクについての要求に応答してトランスコーディング・パラメータを変更すると、遅延が生じて、コンテンツの円滑で切れ目のない再生を妨げることになる。

本発明によれば、要求されたプロパティを有するチャンクが、クライアント機器に利用可能であると告知されているにも拘わらず、利用不可能である場合、そのような利用不可能なチャンクを示しているリンクへの要求に対しては、利用可能なチャンクを使用して、望ましくは、要求されたプロパティに可能な限り近いプロパティを有する利用可能なチャンクを使用して応じる。そのようなチャンクは、例えば、事前に算出されて記憶された同一コンテンツの複数のバージョンの限られた選択肢から選択できる。事前に算出されたチャンクが配信されて、円滑なコンテンツ・ストリームが提供されている間に、オリジナルの要求のパラメータを用いて、トランスコーダ・パラメータをそれに応じて変更する。そして、送信される次のチャンクは、実際に要求されたフォーマット、品質、ビットレート等で利用可能になる。この手法は、接続プロパティの変化がチャンクの再生期間に比べて遅いことに、ある程度、依存している。

本発明による適応ストリーミングは、任意の入来ブロードキャスト・プログラム又は従来型ＩＰＴＶプログラム（これらを含むがこれらには限定されない）から、ＨＴＴＰ適応ストリーミング準拠コンテンツ・ストリームをオンザフライで生成することを可能にする。１つの実行可能な出力は、適応クライアントへの配信に適したフォーマット、例えば、米国カリフォルニア州のアップル社製のクライアント機器への配信に適したＭＰＥＧ−ＴＳで多重化されたＨ.２６４ビデオ及びＡＡＣオーディオである。

Ｈ.２６４エンコーディングは、多数の演算処理と、リソース制限型トランスコーディング装置、例えば、内蔵型装置用に設計されており、かつトランスコーディングについてのリソースが制限されたインテルＣＥ４２００プロセッサを使用する装置とを必要とする。このプロセッサは、標準的な解像度、例えばＮＴＳＣフォーマット又はＰＡＬフォーマットで同時に数個のビデオを生成できるが、一度に１つのＨＤビデオしか出力できない。

そのため、同時に出力できる種々のビデオ品質の数は、インテルＣＥ４２００の演算能力によって制限される。例えば、目的とする解像度がＨＤ、例えば１９２０×１０８０ｉ/ｐ又は７２０×１２８０ｉ/ｐに近いならば、単一のストリームだけしか出力できないので、多品質の適応ストリームの生成は不可能である。

本発明は、実施可能な全ての代替ストリームを生成するのに必要とされる高処理能力を必要とせずに、入力ビデオ・ストリームを適応ＨＴＴＰストリームに変換することを可能にする。

本発明によれば、数個の実施可能な表現、例えばビットレート、フォーマット等がクライアント機器に提示されるが、実際は、もし処理能力が本当に低くければ、一部の選択肢又は１つの選択肢だけが、クライアント機器によってなされた要求に従って調節されるビットレートでトランスコーディングされる。

本発明が取り組む１つの態様は、適応コンテンツ・ストリーミングにおいて、コンテンツ・ストリームのチャンクを告知した場合に、これらのチャンクを容易に利用可能にすることである。そのため、オンザフライでのトランスコーディングの手法において通常なされていることとは対照的に、クライアント要求を予測する必要がある。さもなければ、要求に対する応答が遅すぎることになる。この予測は、２つの理由で可能である。まず、要求されるチャンクがストリーム全体の構成部分であるということである。換言すれば、それらのチャンクは、ユーザが正しいコンテンツ・ストリームを見るように、生成された順序で再生する必要がある。そのため、１つのチャンクがトランスコーディングされるときには、どのチャンクが次に生成されるべきかが既に判っている。次に、クライアント機器によって要求されたビットレートではないビットレートで少数のチャンクを生成して、これらのチャンクを要求されたチャンクの代わりに配信することが、任意のＨＴＴＰ適応ストリーミング・クライアント機器の実装に固有のバッファリング機能のおかげで可能であるということである。もちろん、予測アルゴリズムについては注意を払うべきであり、クライアント・バッファのオーバフローを回避する必要がある。

本発明による方法は、事前に、ストリーミング・コンテンツの始まりの１つ又は複数の連続したチャンクを生成することを含む。例えば、アップルの実装では、ストリーミング・セッションの開始時にプレーヤのバッファを満たすのに少なくとも３つのチャンクを必要とする。その他の実装では、これとは異なる個数のチャンクを予めトランスコーディングする必要があることもある。これらのいわゆるスタートアップ・チャンクが生成される時点では、クライアントが所望するビットレートは、まだ判っていない。そのため、ビットレートが、適応プラットホームによって予め選択される。この選択は、以前のストリーミング・セッションの統計的分析に基づくものでも、又は、単に任意のものでもよい。そして、次のステップにおいて、複数の代替の表現、すなわち、バリアント（異種）をリストアップしたマニフェストが、例えばＨＴＴＰサーバによって、クライアントに利用可能になる。アップルの実装では、このマニフェストは、Ｍ３Ｕ８プレイリストの形態を取る。これらのバリアントによって、とりわけ、ストリーミング・コンテンツの異なる空間又は時間解像度、異なるフォーマット、異なるビットレート、又は、異なる品質が提供されうる。例えば、クライアント機器がＭ３Ｕ８プレイリストの形態でビデオ・ストリームを要求すると、ＨＴＴＰサーバが、利用可能なバリアント・プレイリストをリストアップした、そのため利用可能なビットレートを明確にした、マスタのＭ３Ｕ８プレイリストを配信する。この利用可能なビットレートのリストは、端末のユーザ・エージェント、例えばコンテンツ・プレーヤに依存して調節される。各々の代替バリアントのマニフェスト項目には、クライアントによるダウンロードについて準備ができているチャンクのリストが含まれている。このバリアント記述は、クライアントによってダウンロードされる。本発明によれば、マニフェストの全ての選択可能なバリアントは、同一の予めトランスコーディングされたチャンクをポインティングしている。アップルの実装について上述したように、このバリアント・マニフェストは、Ｍ３Ｕ８プレイリストとして表現され、各々のバリアントが固有のリンクによって選択可能である。クライアントは、コンテンツの１つのバリアントのストリーミング、従ってそのバリアントからのチャンクの供給を要求する。このバリアント・プレイリストは、利用可能なチャンクを示しているリンクをリストアップしており、より正確には、利用可能なチャンクに関するシンボリック（記号）リンクを含んでいる。コンテンツ・サーバは、クライアントからの要求に応じて、予めトランスコーディングされている既に利用可能なバリアントからのみ、対応するチャンクを配信し、要求リンクから所望のビットレートを特定する。この所望のビットレートは、次以降のチャンクについてのコード化用ビットレートを調節するトランスコーダにフィードバックされる。なお、ビットレートは、フォーマット、空間及び時間解像度、品質等によって置き換えることができる。トランスコーダは、入来するコンテンツ・ストリームの部分を連続的に取り込み、所望のビットレートにトランスコーディングし、適応ストリーミングに適したフォーマットにカプセル化（ｅｎｃｕｐｓｕｌａｔｅ）する。新しいチャンクがトランスコーダによって生成されて、供給の準備ができる度に、クライアントに提供されるマニフェストとバリアントの定義が更新され、それによって、クライアントは新たに利用可能なチャンクについて知らされる。クライアントから見れば、ストリームは、あたかも、トランスコーダが、幾つかの代替のバリアントで作成された従来の適応ストリームを実際に提示しているかのように見え、ストリームは、利用可能な帯域幅、あるいはクライアントの性能に適応的に調節されている。

例えば、バリアント・プレイリストの数をＭとし、ｋ番目のバリアント・プレイリストをＰ_ｋとし、ｋ番目のバリアント・プレイリストのビットレートをＢ_ｋとし、現在利用可能なチャンクの数をＮとし、ｉ番目の繰り返しに対応するチャンクをＣ_ｉと仮定する。そうすると、基本的に、チャンクＣ_１、Ｃ_２、Ｃ_３が利用可能である場合、プレイリストＰ_ｋは、それぞれＣ_１、Ｃ_２、Ｃ_３に関するシンボリック・リンクであるチャンクＣ_ｋ,１、Ｃ_ｋ,２、Ｃ_ｋ,３のＵＲＬをリストアップする。これらのシンボリック・リンクは、そのＵＲＬからビットレートを取得することが容易であるように作成される。クライアントがビデオ・チャンクＣ_ｋ,１を要求すると、ウェブ・サーバは、要求されたチャンクの配信だけではなく、要求ＵＲＬのパース（解析）も行う。サーバは、このＵＲＬから、クライアントがｋ番目のバリアント・プレイリストによって示されたビットレートＢ_ｋでの１番目のチャンクを受信する所望を示したという事実を抽出する。この情報は、次のチャンクをコード化するのに適しているビットレート値を計算する帯域幅推定モジュールに入力される。本発明によれば、単純な低域通過フィルタを用いて、過渡的な帯域幅変動を平滑化してもよい。帯域幅推定モジュールの出力値Ｂ’_ｋを用いてトランスコーダをその場で再設定することによって、トランスコーダが次のチャンク（この例では、チャンク番号４）をビットレートＢ’_ｋで生成するようにする。更に、トランスコーダは、チャンク＃１が今しがた消費されたことを通知され、それにより、チャンク＃４の生成についての「ＧＯ（許可）」が示される。トランスコーダは、チャンクをその消費よりも進み過ぎてコード化することを避けるような起動及び停止の形態で動作する。アップルのストリーミングの実装では、Ｎ＝３個のチャンクの存在を義務付けているので、トランスコーダは、３個のチャンクが準備できるまで稼働し、最も古いチャンクが消費されるまで停止する。このメカニズムは、クライアントが要求するビットレートへの収束を促進するのに役立つ。チャンクが利用可能になると直ぐに、対応するシンボリック・リンクＣ_４,ｋが、１からＭに至るｋについて作成され、全てのプレイリストＰ_ｋが更新されて、チャンクＣ_４,ｋの存在をクライアントに通知する。クライアントは、周期的にプレイリストＰ_ｋのコンテンツを要求するので、直ぐに新たなチャンクの存在を知り、それが自己のプレイアウト（再生）バッファを再び満たすように要求する。

本発明による装置は、入来コンテンツ・ストリームを、異なるフォーマット、データ・レート、品質等を有する少なくとも１つの出力コンテンツ・ストリームに、リアルタイムでトランスコーディングできる。例えば、そのような装置は、少なくとも１つのＨ.２６４準拠出力ビデオ・ストリームである入来ビデオ・ストリームをトランスコーディングできる。この出力ビデオ・ストリームは、ＨＴＴＰ適応ストリーミングに適した送信フォーマットにカプセル化されてもよい。ＨＴＴＰサーバが、トランスコーディングされたビデオ・ストリームのチャンクをクライアント機器に配信する。このサーバは、所望のビットレート、フォーマット、品質等をトランスコーダに通知する。トランスコーダに通知されるこれらのパラメータについての情報は、クライアントの要求から得られるが、例えば、クライアント機器との無線接続のスループットが変動する場合における接続の状態をモニタすることからも入手してもよい。実際に、ホストとしてストリーミング・コンテンツを処理するサーバとクライアントとの間の接続におけるスループットの任意の変動によって、トランスコーディング・パラメータが変更されることがある。このことは、トランスコーダが配置されている、上記接続における位置に大きく依存する。仮に、トランスコーダが、どちら側からも、すなわち、トランスコーダの入力側からとトランスコーダの出力側とから一致した情報を提供されたとすれば、ホスティング・サーバとクライアント機器との間の接続におけるトランスコーダの位置はほとんど無関係である。

本発明による装置の例示的な態様では、前述のように、インテルＣＥ４２００ベースのプラットホームが使用される。このプロセッサには、ハードウェアで実施される基本的なビデオのデコーディング機能とエンコーディング機能が含まれている。カプセル化タスク及びウェブ・サービング・タスクは、ソフトウェアで実施される。以下の説明では、このプラットホームを「適応プラットホーム」と呼ぶ。

本発明に関係する構成要素の概要を示す図である。

以下の説明では、本発明を、これに関係する構成要素の概要を示す唯一の図を参照して、説明する。

本発明が実施される環境には、３つの一般的な構成要素、すなわち、ソース、プレーヤ、及び、適応プラットホームが含まれている。

ソースは、ストリーミング・コンテンツ、例えばビデオの供給源である。換言すれば、ソースは、ストリーミング・コンテンツのプロバイダである。これは、例えば、任意の種類のホーム・ビデオ又はプリペイド・ビデオを配信するホーム・デバイス（家庭用機器）、ブロードキャスト・ビデオ又はマルチキャスト・ビデオを配信する外部コンテンツ・プロバイダ（ＤＶＢ−Ｔ、ＤＶＢ−ＩＰＴＶ等）、あるいは、ファイルとして表し得る、又は、ネットワークからストリーミングし得るビデオ・オン・デマンド・サービス（ＶｏＤサービス）であってもよい。図面では、ソースは、ＤＶＢ／ＩＰＴＶとして示されている。

プレーヤは、自己の性能とネットワーク状態とに従って異なる品質でビデオを再生できる民生用端末、すなわちクライアント機器である。ＨＴＴＰ適応ストリーミングのようなプロトコルは、クライアントがそれを再生する直前に適切な品質を要求できるので、好ましい。プレーヤは、図面では「クライアント」として示されている。

適応プラットホームは、図面の大部分を占めている。適用可能な場合に、入来コンテンツ・ストリームを個別のオーディオ成分とビデオ成分とに多重分離するデマルチプレクサ「ｄｅｍｕｘ」が設けられている。ビデオ成分は、デコーダ「デコード」においてデコードされ、セグメント化ユニット「セグメント」においてセグメント化される。そして、これらのセグメントは、エンコーダ「エンコード」において、元のパラメータとは異なるパラメータを用いて、トランスコーディング、すなわち再コード化される。このエンコーダは、Ｈ.２６４エンコーダでもよいが、その他のフォーマットでも同様に可能である。オーディオ成分は、セグメント化ユニット「セグメント」において複数のセグメントに分割され、その後、同じくトランスコーディングされてもよい（図示せず）。そして、トランスコーディングされたオーディオ・セグメント及びビデオ・セグメントは、マルチプレクサ「ＴＳ ｍｕｘ」に供給される。マルチプレクサ「ＴＳ ｍｕｘ」は、トランスコーディングされ多重化されたセグメントを記憶装置「ファイル」に書き込み、サーバ「ウェブ・サーバ」、例えばＨＴＴＰサーバが、セグメントを記憶装置「ファイル」からクライアントに転送する。

前述したように、本発明は、処理能力が限られたトランスコーディング装置において、例えば、インテルＣＥ４２００プロセッサに基づく基本的なメディア処理機能を有するインターネット・ゲートウェイにおいて実施される場合に、特に有効である。

当業者であれば、上述の実施形態において使用されるＨ.２６４コーデックとＭ３Ｕ８マニフェスト・フォーマットとの選択が、本発明がアップルのクライアント機器に適用される場合の本発明の説明にのみ必要であることを理解できるであろう。ＶＣ１、ＷｅｂＭのようなその他のコーデックを必要とするその他の適応ストリーミングの実施形態も、エンコーディング・リソースが乏し過ぎて全ての必要な代替のストリームを同時に生成できない場合に、上述の本発明の恩恵を同様に受けることができる。

ライブ・ビデオのストリーミングの場合、マニフェストは、時間と共に変化する複数組のチャンクを告知する。告知される一組のバリアントも変動することがある。これは、一組の提案されるバリアントが動的に修正される本発明の発展形態に使用できる。例えば、マニフェストが５つのバリアントを提案する場合、そのうちの３つのものは、最後に要求されたビットレートに近い、例えば、それよりも少し低い、及び、少し高いビットレートを有し、もう１つのものは、それよりもずっと高いビットレートを有し、５番目のものは、それよりもずっと低いビットレートを有する。マニフェストにおいて提示されるバージョンは、接続のスループットの過去の変動に従って更新してもよい。

トランスコーダが複数のＨ.２６４出力ストリームを生成できる場合に備えて、ユーザ体験を更に改善する適応化を前もって考慮しておくことが望ましい。本発明の発展形態によれば、トラッカ・モジュールが、現在の要求に加えて、以前に要求されたビットレートの記録を取る。現在の要求されたビットレートが前のビットレートよりも低いとき、予測モジュールは、クライアントが将来の要求においてビットレートを更に低減するかもしれないと想定する。したがって、そのような場合、トランスコーダの２つのインスタンスが実行されて、次のチャンクを、要求されたビットレートＣ_ｉ,ｋと、その次に低いビットレートＣ_{ｉ,ｋ−１}との両方で生成する。提示モジュールが、Ｃ_ｉ,ｋをポインティングするＣ_ｉ,ｊ（ｊは［ｋ；Ｍ］の範囲内）についてのシンボリック・リンクと、Ｃ_{ｊ,ｋ−１}をポインティングするＣ_ｉ,ｊ（ｊは［０；ｋ−１］の範囲内）についてのシンボリック・リンクと、を全て作成する。

現在の要求が前のビットレートよりも高いものである場合、予測モジュールは、ビットレートが将来の要求において更に増大すると想定して、より高いビットレートでチャンクの追加バージョンを同様の方法で生成させる。

上記のトラッカ・モジュール、予測モジュール、及び、提示モジュールは、汎用マイクロプロセッサにソフトウェア・モジュールとして組み込まれてもよいし、あるいは、専用回路であってもよい。

本発明は、モバイル機器を含む多種多様な機器に利用可能な任意の入力ストリームの再配信を可能にし、送信品質の変動に対処することを可能にする。この適応化は、ストリームを適応ストリーミング用に予め準備しておく必要がなく、住宅用ゲートウェイのようなローエンド（下位機種）の機器でも実施できるので、費用対効果が非常に高い。

ストリーミング・コンテンツのチャンクを予め準備しないので、理論上、無制限の数のバリアントを有するストリーミング・コンテンツを告知することが可能である。

適応化を、ユーザに可能な限り近い所で、例えば住宅用ゲートウェイで実現できるので、本発明は、個々のユーザの可能な限り最良のエクスペリエンス（体験）を維持しつつ、広範な配信を行うことについて、低コストのソリューションを提案する。ビデオは、高品質で広範に配信され、例えば、住宅用ゲートウェイにマルチキャストされ、そのゲートウェイのみにおいて適応化される。

ストリーミング・コンテンツを、後で使用するために、保存する意図がなければ、それを適応プラットホーム上に記憶する必要はない。その一部分を、一時的に使用するために、かつ、実施の都合のために、プラットホーム上に記憶することが必要なだけである。

Claims (8)

1. 対応する入力コンテンツ・ストリームから適応的にトランスコーディングされた出力コンテンツ・ストリームをストリーミングする方法であって、
   クライアント機器による選択用に、前記出力コンテンツ・ストリームの多数の代替バージョンを前記クライアント機器に提示するステップと、
   前記入力コンテンツ・ストリームを２つ以上のセグメントに分割するステップと、
   前記提示するステップの前に、前記入力コンテンツ・ストリームの少なくとも第１のセグメントを、前記クライアント機器に提示される前記多数の代替バージョンのうちの少なくとも１つのバージョンに対応する出力コンテンツ・ストリームの少なくとも１つの対応するセグメントに、トランスコーディングして記憶するステップと、
   前記出力コンテンツ・ストリームの選択されたバージョンのチャンクをストリーミングする要求を、前記クライアント機器から受信するステップと、
   前記提示するステップの前にトランスコーディングされた、前記クライアント機器に提示される前記多数の代替バージョンのうちの少なくとも１つのバージョンに対応する出力コンテンツ・ストリームの前記少なくとも１つの対応するセグメントのうちの最初のものを用いてストリーミングを開始するステップと、
   前記入力コンテンツ・ストリームの次のセグメントの、前記クライアント機器によって選択されたバージョンへのトランスコーディングを制御するトランスコーディング・パラメータを前記要求から抽出するステップと、
   要求されたバージョンにトランスコーディングされた前記次のセグメントをストリーミングするステップと、
   を含む前記方法。
2. 前記入力コンテンツ・ストリームの前記少なくとも第１のセグメントが、前記クライアント機器に提示される前記多数の代替バージョンのうちの複数のバージョンの対応するセグメントに予めトランスコーディングされる、請求項１に記載の方法。
3. 前記要求に応答して直ちにストリーミングされる前記少なくとも第１のセグメントに対応するセグメントが、クライアントの再生能力に適合するバージョンから選択される、請求項２に記載の方法。
4. 前記要求に応答して直ちにストリーミングされる前記少なくとも第１のセグメントに対応するセグメントが、前記クライアント機器から受信された前記要求から抽出されたトランスコーディング・パラメータに可能な限り近似して適合するトランスコーディング・パラメータを有するバージョンから選択される、請求項２に記載の方法。
5. トランスコーディングは、フォーマット、空間又は時間解像度、データ・レート、及び、品質のうちの少なくとも１つが、それぞれの入力のフォーマット、空間又は時間解像度、データ・レート、及び、品質と異なる出力コンテンツ・ストリームを生成することを含む、請求項１に記載の方法。
6. 前記入力コンテンツ・ストリームの次のセグメントのトランスコーディングを制御する前記トランスコーディング・パラメータは、前記入力コンテンツ・ストリームを提供するサーバと前記クライアント機器との間の接続のセグメントの容量についての情報に基づいて変更される、請求項１に記載の方法。
7. 前記提示するステップは次のセグメント毎に繰り返され、提示されるセグメントの少なくとも１つのバリアントが、現在供給されているセグメントを対象にする要求から抽出されるパラメータに従ってトランスコーディングされる、請求項１に記載の方法。
8. 請求項１〜７のいずれか１項に従う方法を行うように構成された装置。
   

Images