JP7549581B2 - 最適なマルチコーデックａｂｒラダー設計 - Google Patents

Description

アダプティブビットレート（ＡＢＲ：Ａｄａｐｔｉｖｅ Ｂｉｔ Ｒａｔｅ）ストリーミングは、ストリーミングクライアントに供給されるビデオストリームのビットレートが、利用可能なネットワーク帯域幅の変化に対応するように再生時に調整され得る、ビデオコンテンツをストリーミングする方法である。この機能を可能にするために、ＡＢＲストリーミングシステムが、ソースコンテンツを異なるビットレートの複数のストリームにエンコードし得る。このようにして、ストリーミングクライアントは、ビデオをストリーミングしながら異なるストリームの間の切り替えを行うことができ、利用可能なネットワーク帯域幅に合わせた複合ストリームを効果的に受信することができる。

ソースコンテンツがエンコードされたストリームの構成は、ＡＢＲストリーミングシステムによって決定され得る。従来のＡＢＲストリーミングシステムでは、この決定は、コーデックごとに独立に行われるのが一般的であった。換言すれば、コーデックごとに、ネットワークへの適応に必要なビットレートの範囲をカバーする、全く新しい一式のストリームが生成される。その結果、エンコード及び配信のコストがかなり高くなる。しかしながら、現在では、多くのストリーミングクライアントが異なるコーデックのストリームの間で切り替えを行うことができるため、ＡＢＲ配信に十分なストリームの最適なマルチコーデック構成を見つけることにより、このような非効率性を最小化できる。

本明細書で説明される技法は、ビデオをストリーミングするためにクライアントが利用できるようになったストリームのそれぞれについて品質及びビットレートを定義するマルチコーデックエンコーディングプロファイル（又はエンコーディングラダー）の作成を提供する。特に、エンコーディングラダーを決定するときに、コーデックのそれぞれの品質レート関数を最適化技法が考慮することができる。更なる考慮事項として、ネットワーク帯域幅分布及び／又はクライアントタイプの分布を含むことができる。

本明細書による、マルチコーデックエンコーディングラダーを作成するための例示的な方法は、コンピュータシステムによって、ビデオを含むソースコンテンツを取得するステップと、ソースコンテンツのためのエンコーディングラダーを生成することであって、エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、ソースコンテンツをエンコードするための個々のビットレート及び複数のコーデックの個々のコーデックを含む、ステップとを含む。エンコーディングラダーは、

及び

の個々のビットレート並びに

及び

の個々の品質値を有する、第１のコーデックの第１のビデオストリーム及び第２のビデオストリームと、

のビットレート及び

の品質値を有する、第２のコーデックの第３のビデオストリームとを含み、

且つ

である。

本明細書による、マルチコーデックエンコーディングラダーを作成するための例示的なコンピュータシステムは、メモリと、メモリに通信可能に結合された１つ又は複数の処理ユニットとを備える。１つ又は複数の処理ユニットは、ビデオを含むソースコンテンツを取得し、ソースコンテンツのためのエンコーディングラダーを生成し、エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、ソースコンテンツをエンコードするための個々のビットレート及び複数のコーデックの個々のコーデックを含み、エンコーディングラダーが、

及び

の個々のビットレート並びに

及び

の個々の品質値を有する、第１のコーデックの第１のビデオストリーム及び第２のビデオストリームと、

のビットレート及び

の品質値を有する、第２のコーデックの第３のビデオストリームとを含み、

且つ

である、ように構成される。

本明細書による例示的な非一時的コンピュータ可読媒体は、マルチコーデックエンコーディングラダーを作成するための命令を内部に格納している。命令は、１つ又は複数の処理ユニットによって実行されると、１つ又は複数の処理ユニットに、ビデオを含むソースコンテンツを取得させ、ソースコンテンツのためのエンコーディングラダーを生成させ、エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、ソースコンテンツをエンコードするための個々のビットレート及び複数のコーデックの個々のコーデックを含み、エンコーディングラダーが、

及び

の個々のビットレート並びに

及び

の個々の品質値を有する、第１のコーデックの第１のビデオストリーム及び第２のビデオストリームと、

のビットレート及び

の品質値を有する、第２のコーデックの第３のビデオストリームとを含み、

且つ

である。

一実施形態によるＡＢＲストリーミングシステムである。 利用可能なネットワーク帯域幅及びクライアントのストリーミングレートをプロットしたグラフである。 一実施形態による、ビデオソースと、２種類のエンコーダと、付随するレートセレクタを伴う３種類のデコーダとを備えるＡＢＲストリーミングシステムの概念図である。 一実施形態による、異なるデコーダ（例えば、図３のデコーダ）が様々なビットレートで実現できるビデオの品質を示すグラフである。 例示的な実施形態で使用されるＡＢＲストリーミングシステムの概念図である。 一実施形態による、最適化されたマルチコーデックエンコーディングラダーを決定するための方法の主なステップを示すフロー図である。 コーデック、例示的なソースコンテンツのための取得された品質レート関数の形状を示すグラフである。 本明細書で説明される実験結果を得るために使用した２つのネットワークモデルのネットワークパラメータのグラフである。 本明細書で説明される実験結果を得るために使用したシングルコーデックＡＢＲストリーミングシステムの概念図である。 本明細書で説明される実験結果を得るために使用したデュアルコーデックＡＢＲストリーミングシステムの概念図である。 エンコーディングラダーのポイントと、Ｈ．２６４ベースラインクライアント及びＨ．２６４ベースライン／メイン切り替え可能クライアントによってなされる切り替え決定を示すグラフである。 本明細書で説明される実験結果を得るために使用した、３つのクライアントタイプのデュアルコーデックＡＢＲストリーミングシステムの概念図である。 本明細書で説明される実験結果を得るために使用した、４つのクライアントタイプのマルチコーデックＡＢＲストリーミングシステムの概念図である。 一実施形態による、本明細書で説明される方法を使用してマルチコーデックＡＢＲラダー生成を組み込んだマルチコーデックＡＢＲストリーミングシステムのブロック図である。 レート及び品質の観点から単調増加する一式のポイント（エンコーディングラダーにおけるストリーム）を決定するための方法のフローチャートである。 一実施形態による、マルチコーデックエンコーディングラダーを作成する方法を示すフロー図である。 コンピュータシステムの一実施形態のブロック図である。

各図面における類似の参照符号は、特定の例示的な実装形態による類似の要素を示す。加えて、ある要素の複数の例は、要素の第１の数字に続けて、文字又はハイフン及び第２の数字を用いて示されることがある。例えば、要素１１０の複数の例は、１１０－１、１１０－２、１１０－３などと示されることもあれば、１１０ａ、１１０ｂ、１１０ｃなどと示されることもある。このような要素を第１の数字のみで参照する場合、その要素の任意の例であると理解されたい（例えば、前の例における要素１１０は、要素１１０－１、１１０－２、及び１１０－３、又は要素１１０ａ、１１０ｂ、及び１１０ｃを指す）。

詳細な説明
次に、本明細書の一部をなす添付の図面を参照しながら、いくつかの例示的な実施形態について説明する。本開示の１つ又は複数の態様が実施され得る特定の実施形態が以下に記載されているが、本開示の範囲又は添付の特許請求の範囲の趣旨から逸脱することなく、他の実施形態が使用されてもよく、様々な変更がなされてもよい。

図１は、一実施形態によるＡＢＲストリーミングシステム１００である。ＡＢＲストリーミングシステム１００は、ビデオソース１１０と、エンコーダ１２０と、オリジンサーバ１３０と、コンテンツ配信ネットワーク（ＣＤＮ）＋ネットワークアクセス１４０と、ストリーミングクライアント１５０とを備える。当業者には理解されるように、異なる実施形態は、図示の構成要素のそれぞれの数が異なり得る。例えば、ＣＤＮ＋ネットワークアクセスは、多くの（例えば、数十、数百、数千、又はそれ以上）ストリーミングクライアント１５０にサービスを提供し得る。

ビデオソース１１０に格納されているソースコンテンツ（例えば、１つ又は複数のメディアファイル）を１つ又は複数のストリーミングクライアント１５０に配信できるようにするために、エンコーダ１２０は、ソースコンテンツを異なるビットレートを有する複数のストリームにエンコードし得る。（例えばコールアウト１６０に示すように、エンコーダはソースコンテンツをエンコードして、Ｍ個のビットレート及び別個の記述を提供し得る。）各エンコードされたストリームは、ランダムアクセスポイント（例えば、エンコードされたビデオにおけるイントラフレーム（Ｉ）フレーム又は即時復号リフレッシュ（ＩＤＲ）フレーム）を組み込むことができ、ストリーム間で切り替えを行うことが可能である。このようなストリームは、続いてオリジンサーバ１３０に置かれ、ストリーミングクライアント１５０へのスケーリング配信のためにＣＤＮ＋ネットワークアクセス１４０（ＣＤＮだけではなく、インターネットなどの１つ又は複数のデータ通信ネットワークも含み得る）に更にプッシュされる。

再生時、各ストリーミングクライアント１５０は、エンコードされたコンテンツが到着するレートを監視し得る。（例えばコールアウト１７０に示すように、ストリーミングクライアントは、帯域を推定し、次いで、次のセグメントを取得する前に、帯域幅を考慮して次のセグメントのための適切なレートを選択し得る。）このようなレートが連続再生に不十分になった場合、クライアントはより低いビットレートのストリームに切り替える。これにより、バッファリングを防ぐことができる。一方、そのようなレートが現在のストリームのビットレートよりも大きい場合、クライアントはより高いビットレートのストリームに切り替えて、より良い品質をエンドユーザに提供することができる。このような切り替えメカニズムは、その後広く採用されるようになり、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ライブストリーミング（ＨＬＳ）、ＭＰＥＧダイナミックアダプティブストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）など、すべての最新のストリーミングプロトコルに組み込まれている。

したがって、その結果、ストリーミングクライアント１５０へのビデオのストリーミングビットレートが、利用可能なネットワーク帯域幅の経時的変化に適応する。例えば図２のグラフに示すように、ストリーミングビットレート２１０は、利用可能なネットワーク帯域幅２２０が増加すると増加し、利用可能なネットワーク帯域幅２２０が減少すると同様に減少し得る。ストリーミングビットレート２１０のこれらの変化は、ストリーミングクライアント１５０が第１のビットレートを有するストリームから第２のビットレートを有するストリームに切り替えたことに起因する。よって、所与のソースコンテンツに対してエンコーダ１２０が作成する（異なるビットレートの）ストリームが多いほど、ストリーミングビットレート２１０の変化がより細かく調整され得る。

ビットレート、解像度、コーデックの制約など、ＡＢＲストリーミングに使用されるビデオストリームの特性の構成は、通常、エンコーディングプロファイル又はラダーと呼ばれる。高効率映像符号化（ＨＥＶＣ）及びＨ．２６４／ＭＰＥＧ－４ ＡＶＣ（又は単に「Ｈ．２６４」）コーデックの例示的なエンコーディングラダーは、以下の表１に記載されており、表１はアップル（Ａｐｐｌｅ）（登録商標）ＨＬＳデプロイメントガイドラインズ（ＨＬＳ ｄｅｐｌｏｙｍｅｎｔ ｇｕｉｄｅｌｉｎｅｓ）に記載されている。

近年、コンテンツのレート歪み特性及び／又はストリームの配信に使用されるネットワークの特性を考慮してカスタムエンコーディングラダーを作成するダイナミックラダージェネレータを使用することにより、ＡＢＲストリーミングシステム１００のパフォーマンスが改善され得ることも判明した。このような手法は、「パータイトル（ｐｅｒ－ｔｉｔｌｅ）」、「コンテンツ認識エンコーディング」、及び「コンテキスト認識エンコーディング」技法として知られてきた。ＡＢＲストリーミングのためのラダージェネレータに関する更なる情報は、「オプティマイゼーション・オブ・エンコーディング・プロファイル・フォー・メディア・ストリーミング（Ｏｐｔｉｍｉｚａｔｉｏｎ ｏｆ Ｅｎｃｏｄｉｎｇ Ｐｒｏｆｉｌｅｓ ｆｏｒ Ｍｅｄｉａ Ｓｔｒｅａｍｉｎｇ）」と題する米国特許出願第１５／８２９，７２３号明細書（本明細書では「’７２３出願」と呼ぶ）に記載されており、同出願はあらゆる目的のためにその全体が参照により本明細書に組み込まれる。

つい最近まで、ＡＢＲストリーミングのためのエンコーディングラダーには１つのコーデックしかなかった。（ほとんどの場合、コーデックは、ユビキタスであり、且つ過去１０年にわたって既存のほとんどのデバイスでサポートされたＨ．２６４である。）しかしながら、ＶＰ９、ＨＥＶＣ、及びＡＶ１など、より多くのコーデックが導入されることにより、ＡＢＲストリーミングシステム１００は、一般に、コンテンツが異なるコーデックをサポートする様々なデバイスに確実にストリーミングされ得るのを助けるために、すべての追加的にサポートされるコーデックに対してソースコンテンツ全体を再エンコードして、新しいコーデックを使用してエンコードされたすべてのストリームで新しいＡＢＲラダーを作成しなければならない。現在のバージョンのストリーミングガイドライン（例えば、ＨＬＳガイドライン及びＤＡＳＨ－ＩＦ実装ガイドライン）は、Ｈ．２６４に１つのラダー（一定のビットレート及び解像度を有する一式のストリーム）を定義し、ＨＥＶＣに別のラダーを定義する。

先述のように、ＡＢＲストリーミングのための複数のコーデックのデプロイメントは、現在、各コーデックが個別のＡＢＲエンコーディングラダーと、対応する個別の一式のストリームとを有するという仮定に基づいて行われている。したがって、ＡＢＲストリーミングシステム１００は、ＨＥＶＣのためのエンコーディングラダーとは別に、Ｈ．２６４のためのエンコーディングラダーを生成する。

しかしながら、問題なことに、このようなシングルコーデックエンコーディングラダーを使用することは、少なくとも以下の３つの理由から、根源的に最適ではない。
第１に、ラダーを別々に生成することにより、各コーデックに関連するＡＢＲエンコーディングラダーに割り当てられるレンディションの数の間における適切なバランスを見出すための手段がないことがある。したがって、エンコーダ１２０は、一群の視聴者にわたるこのようなコーデックの使用状況が異なり得るという事実を考慮することなく、各コーデックに必要と思われる数のレンディションを生成し得る。例えば、ＨＥＶＣエンコードされたビデオをサポートするストリーミングクライアント１５０の数は、Ｈ．２６４をサポートするストリーミングクライアント１５０の数よりもはるかに少ない場合がある。また、生成され得るレンディションの数に一定の総予算が設けられているＡＢＲストリーミングシステム１００では、Ｈ．２６４に多く割り当てることは、エンドユーザに配信される総品質により大きな全体的な影響を与える場合がある。

第２に、コンテンツの特性に基づいて、ＨＥＶＣ対Ｈ．２６４のコーディングゲインが著しく異なり得る。このことはひいては、各コーデックに使用されるべきレンディション数のバランスに影響を与え得る。例えば、ある極端なシナリオでは、ＨＥＶＣ対応のストリーミングクライアント１５０はすべてＨ．２６４もデコードできるため、ＨＥＶＣがいかなるゲインももたらさない場合、最適なＡＢＲラダー設計は、ＨＥＶＣにレンディションを割り当てない場合がある。そのため、Ｈ．２６４への切り替えはシステムの到達範囲を減らさない。

第３に、多くの新しいストリーミングクライアント１５０が、Ｈ．２６４とＨＥＶＣとの両方のコーデックを有するストリーム間の切り替えを行うことができる。この切り替え能力を所与として、このようなクライアントは、Ｈ．２６４又はＨＥＶＣのストリームを選択したクライアントよりも、より多くのストリームを利用できるため、より良いパフォーマンスを実現し得るはずである可能性が高い。（ここでも、図２に関して述べたように、より多くのストリームが利用可能である場合、ストリーミングビットレート２１０は、より微調整されたステップを使用して、利用可能なネットワーク帯域幅２２０の変化に合わせることができる。このより高い粒度により、ＡＢＲストリーミングシステム１００をより効率的にすることができる）。

本明細書で説明される実施形態は、複数のコーデックラダーのためのＡＢＲプロファイル／ラダー生成のための最適化された解を提供する。つまり、提供される技法は、ソフトウェア、若しくはハードウェア、又はこれらの組み合わせとして実装された最適なマルチコーデックＡＢＲストリーミングラダージェネレータ、及びそのようなラダージェネレータを組み込んだＡＢＲストリーミングシステムについて説明する。本明細書における技法によって提供される利点の中には、ＡＢＲストリーミングシステムの品質向上及び／又は運用コストの削減がある。

図３は、一実施形態による、ビデオソース１１０と、２種類のエンコーダ（エンコーダ１及びエンコーダ２）と、付随するレートセレクタを伴うデコーダ（デコーダ１、デコーダ２、及びデコーダ３）を備える３種類のクライアントとを備えるＡＢＲストリーミングシステムの概念図である。図３に示すエンコーダは、（これも１つ又は複数のコンピュータを備え得る）ビデオソース１１０からソースコンテンツを取り込む１つ又は複数のコンピュータによって実行され得る図１のエンコーダ１２０の一種に対応し得ることに留意されたい。更に、クライアント３１０のそれぞれは、エンドユーザデバイス（コンピュータ、携帯電話、テレビなど）によって実行され得る、図１の異なる種類のストリーミングクライアント１５０にそれぞれ対応し得る。（本明細書では、後述するＡＢＲストリーミングシステムの数学的記述を言及するとき、「クライアント」及び「デコーダ」という用語がしばしば同義で使用されることに留意されたい。）本実施形態において、且つ一実施形態の数学的記述を確立する目的で、デコーダ１及び２は、エンコーダ１及び２が生成したストリームをそれぞれデコードすることしかできない。デコーダ３はエンコーダ１又はエンコーダ２のいずれかが生成したストリームを選択してデコードし得る。

本明細書で使用される場合、「シングルコーデッククライアント」という用語は、（例えば、エンコーダ１又はエンコーダ２のいずれかからの）単一のコーデックでエンコードされたビデオストリームをデコードすることができるクライアント（デコーダ１又は２を備えるクライアントなど）を指す。同様に、「ダブルコーデッククライアント」という用語は、異なる２つのコーデック（例えば、エンコーダ１又はエンコーダ２のいずれかによりエンコードされたビデオストリーム）でエンコードされたビデオストリーム間の切り替えを行うことができるクライアント（デコーダ３を備えるクライアントなど）を指す。同様に、「切り替えクライアント」という用語は、（２つ以上のエンコーダからの）２つ以上のコーデックでストリームをエンコードしたビデオを復号することができるデコーダを指すために使用され得る。

図３のＡＢＲストリーミングシステムの数学的記述を提供するために、変数Ｒが、ビットレートを表すために使用され、Ｑがビデオコーデックによって実現可能な品質値を表すために使用される。ここで、品質値Ｑは、値Ｑ＝０はあり得る最悪の品質を表し、Ｑ＝１は理想的な再構築を表すように正規化される。このような制約を満たす品質指標の周知の例は、構造的類似性指数尺度（ＳＳＩＭ）指標であるが、原理的には、ピーク信号対雑音比（ＰＳＮＲ）、マルチスケールＳＳＩＭ（ＭＳ－ＳＳＩＭ）、又はビデオマルチメソッドアセスメントフュージョン（ＶＭＡＦ）など、特定の正規化を適用した任意の他の指標であってもよい。

所与のソースコンテンツについて、エンコーダ１及び２は、次のような（品質，レート）特性を有する一式のエンコードされたストリームをそれぞれ生成する。

及び

どちらの場合も下付き添え字１及び２はコーデックの種類を示し、ｎ_１及びｎ_２はそれぞれエンコーダ１及びエンコーダ２によりそれぞれ生成されたストリームの数を示している。

ここで、コーデックのパフォーマンスは、特定の品質レート関数Ｑ_１（Ｒ）及びＱ_２（Ｒ）によりモデリングされる。（異なるストリームに対応する）上記の（品質，レート）ポイントは、次のこれらの関数から得られたサンプルと理解され得る。

及び

集合Ｌ_１及びＬ_２はそれぞれ、タイプ１及び２のコーデックに対するエンコーディングラダーである。両方の集合の和集合Ｌ＝Ｌ_１∪Ｌ_２は「デュアルコーデックラダー」である。

表記の都合上、このようなラダーは、常に、両方のコーデックに対して同じであるゼロ点である、
（Ｒ^０，Ｑ^０）＝（０，０） （５）
により拡張され得る。

実際には、異なるビットレートにおいて同様に変更され得るビデオパラメータの１つは、解像度である。本明細書で説明される実施形態では、解像度は最適になされてもよく、各コーデックの品質レートモデルによって取り込まれると仮定され得る。換言すれば、一式の許容される解像度

及び特定の解像度

ごとに取得される品質レートモデルＱ_１（Ｓ，Ｒ）を所与として、最終的な品質レートモデルＱ_１（Ｒ）は、

であるように定義され得る。

ＨＬＳ又はＤＡＳＨなどの最新のストリーミングプロトコルは、基礎とするトランスポートプロトコルとして伝送制御プロトコル（ＴＣＰ）を用いることに基づいている。それから、ＴＣＰは再送を実施して、パケットロスを排除し、物理ネットワークの種類ごとに固有の多くの自然統計をマスクする。しかしながら、ＴＣＰレベルでは、各時点で利用可能な伝送速度又は帯域幅の変動が依然として観測され得る。

したがって、数学的モデリングの目的で、ネットワークは、特定の所与の確率密度関数ｐ（Ｒ）による連続確率変数Ｒと見なされ得る。
実際には、このような帯域幅密度関数ｐ（Ｒ）は、デバイス又はデバイスのそれぞれのアクセスネットワークが異なれば異なり得る。例えば、４Ｇ／ロングタームエボリューション（ＬＴＥ）ネットワークを介して接続されたモバイルクライアントを考えると、ＬＴＥを介するＴＣＰトラフィックの既知のスループット測定値が使用され得る。より一般的には、このような分布は、各特定のストリーミングデプロイメントを考慮して実験的に測定することができ、そして当然のことながら、デバイス、ＣＤＮ、配信領域などが異なれば異なり得る。

クライアントのモデルは次のように定義され得る。すべての時点において、特定の利用可能なネットワーク帯域幅Ｒを所与として、図３のデコーダ１及び２（シングルコーデッククライアント）はそれぞれラダーＬ_１及びＬ_２から、

及び

にしたがってビットレートを選択する。

換言すれば、デコーダ１及び２は、利用可能なネットワーク帯域幅Ｒ以下の最大ラダーレートＲ^ｉを選ぶ。
したがって、各デコーダがそれぞれ実現する品質は、

及び

となる。

実際には、ストリーミングクライアントにおけるレート選択アルゴリズムはより複雑であり得るが、それにもかかわらず、上述の選択モデルは、ストリーミングシステムの平均的なパフォーマンスを検討するのに適し得る。

（図３の）デコーダ３に関連して、デコーダ３は、各帯域幅の値Ｒについて、次の最高の品質を実現するビットレート及びコーデックの両方を選ぶことができる。

これは、次のレート選択規則を用いることにより実現され得る。

Ｈ．２６４及びＨＥＶＣのコーデックについて、これらの概念を図４Ａ及び図４Ｂに示す。

図４Ａ及び図４Ｂは、異なるクライアント／デコーダが様々なビットレートで実現できるビデオの品質を示すグラフである。図４Ａでは、ＨＥＶＣ品質レート関数３１０（Ｑ_ＨＥＶＣ（Ｒ））とＨ．２６４品質レート関数３２０（Ｑ_{Ｈ．２６４}（Ｒ））がプロットされており、０から３５００ｋｂｐｓまでに及ぶビットレートにわたって、所与のソースコンテンツに対して実現可能な品質（ＳＳＩＭ）を示している。ＨＥＶＣ品質レート関数３１０のプロットがＨ．２６４品質レート関数３２０のプロットを上回っており、所与のソースコンテンツではＨＥＶＣがより効率的であることを示唆していることが分かる。

ビットレートが上がるにつれて、ＨＥＶＣデコーダ３３０による選択された品質及びＨ．２６４デコーダ３４０による選択された品質のそれぞれが、それぞれのデコーダが低いビットレート／品質を有するストリームから高いビットレート／品質を有するストリームに切り替わるところを示す品質が向上するステップを示す。例えば、Ｈ．２６４のエンコーディングラダーは、７１、２６８、５９５、１１０８、及び２１４９ｋｂｐｓの５つのビットレートポイントをそれぞれ含み、その結果、Ｈ．２６４デコーダ３４０による選択された品質によって階段状の関数が示される。ＨＥＶＣのエンコーディングラダーは、９３、４５９、及び１２７５ｋｂｐｓの３つのビットレートポイントをそれぞれ含み、その結果、ＨＥＶＣデコーダ３３０による選択された品質によって階段状の関数が示される。（ＨＥＶＣデコーダは利用可能な３つのＨＥＶＣレートの中からしか選択できない。）
図４Ｂは、デュアルコーデックデコーダ３５０による選択された品質を図４Ａのグラフに重ねて示している。これから分かるように、デュアルコーデックデコーダ３５０による選択された品質は、各レートにおいて利用可能な最高の品質を選ぶＨ．２６４及びＨＥＶＣのデコーダの両方のステップと部分的に一致する。両方のコーデックを交互に用い、合計７つのステップとなる。これにより、デュアルコーデックデコーダ／クライアントは、変化するネットワークの帯域幅に一層正確に適応することができ、よって、デコーダがＨ．２６４又はＨＥＶＣのストリームとのみ連携するよりも、より良好なネットワーク利用率を実現することができる。ただし、重要なことに、デュアルコーデックデコーダはまた、品質が向上しないために切り替える意味がないポイントを省略することもできる。例えば、（４５９ｋｂｐｓのＨＥＶＣよりも低い品質を有する）５９５ｋｂｐｓのＨ．２６４のポイントを使う代わりに、デュアルコーデックデコーダは４５９ｋｂｐｓのＨＥＶＣに留まる。

これに基づいて、デュアルコーデックデコーダ／クライアントがより良好なパフォーマンスを実現した場合の条件が定式化され得る。ここで、第１及び第２のコーデックをそれぞれ用いてエンコードされたストリームのラダーＬ_１（１）及びＬ_２（２）を所与として、

且つ

であるような２つの添え字ｉ及びｊを考える。この条件が満たされると、第２のコーデックラダーからのポイントｊが選択可能となり、デュアルコーデックデコーダ／クライアントで実現され得るステップの総数及び適応の精度が向上する。図４Ｂに示すような特別な場合では、このようなポイントはｉ＝１且つｊ＝１となり得、ラダーの最初の一対のポイントであっても上記の条件が満たされることを示し、つまり、

且つ

であり、

及び

は第１のコーデックを使用してエンコードされた最初の２つのストリームのビットレートであり、

及び

はそれらの個々の品質値であり、

及び

はそれぞれ第２のコーデックを使用してエンコードされた最初のストリームのビットレート及び品質値である。

デュアルコーデックＡＢＲストリーミングシステムによって実現可能な平均品質は、以下のように決定され得る。上述のレート選択規則を所与として、且つネットワーク帯域幅が確率密度関数ｐ（Ｒ）による連続確率変数Ｒとしてモデリングされると仮定することによって、ストリーミングシステムにおいて３種類のデコーダが実現可能な平均品質の表現は次のように記述することができる。

及び

ここで、

は、第１のコーデックしかデコードできないクライアントによって実現可能である平均品質である。同様に、

は、第２のコーデックしかデコードできないクライアントによって実現可能である平均品質である。

は、両方のコーデックをデコードでき、Ｌ_１とＬ_２とのストリーム間で切り替えを行うことができるクライアントによって実現可能である平均品質である。

最後に、π＝｛π_１，π_２，π_３｝、π_１＋π_２＋π_３＝１が、クライアントの全体における各種のクライアントの存在を記述する分布であると仮定することにより、ストリーミングシステムが実現可能な全体の平均品質は次のように表され得る。

式（１６）の最終平均品質の表現に至る上記の定義の全体的な流れを図５に示す。

式（１）～（１６）を考慮し、且つ平均品質値

は、ネットワークの帯域幅密度ｐ（Ｒ）、クライアント分布π、ポイントの数ｎ、及びラダーで使用されるレートのセットの関数として理解できると分かることから、エンコーディングラダー最適化問題は以下のように設定され得る。
・ラダーポイントの総数ｎ、
・すべてのレートポイントの限度：Ｒ_ｍｉｎ、Ｒ_ｍａｘ、
・最初のレートポイントの最大限度：

、
・コーデック及びコンテンツの両方に対する品質レート関数Ｑ_１（Ｒ）、Ｑ_２（Ｒ）、
・ネットワーク帯域幅密度ｐ（Ｒ）、及び
・クライアントの分布π
を所与のものとして、
・

であるような数

、
並びに
・ラダーレート

及び

、
を見つける。ただし、ストリーミングシステムによって与えられる品質全体

が最大である、つまり、

であるように見つける。

容易に気付くように、式（１７）で記述された問題は、非線形制約最適化問題であり、

が（混合したクライアントのための品質決定における最大値演算子の使用に起因して）微分可能ではないという事実と、整数

の選択が離散領域に含まれ、残りは潜在的に連続であるという事実とによって、一定の複雑さが加えられている。

（１７）で導入されたすべての制約は、実用的な設定で使用され得る。例えば、最大レート限度Ｒ_ｍａｘは、物理的に実現可能な割り当てを超えたビットレートの割り当てを防ぐことができる。最小レート限度Ｒ_ｍｉｎは、通常、サービスとしてのストリーミングがまだ実現可能な最小品質レベルに関連している。ラダーにおける最初のレートの最大限度

は、通常、クライアントの起動時間及び／又はバッファリング確率などを制限するために使用される。実際には、いくつかの更なる制約が導入されることもある。

式（１７）で定式化された問題は、ストリーミングシステムでｎ個の全ストリームと共に作動する。しかしながら、ストリームの数を無限に近づけることができる場合、結果として各デコーダの出力における品質限度は次のようになる。

及び

システム全体の全品質限度は、

となる。

理想的な品質値とｎポイントシステムで実現可能な最良の平均品質との間の相対的な距離（「品質ギャップ」と呼ばれる）は、次のように定義され得る。

品質ギャップ指標は、有限数のレートポイントを有するシステムが、無限の場合に対してどのくらい良好な挙動を示すのか、また、いくつのラダーポイントが実用的に十分であるかを理解するのに役立ち得る。例えば、十分なポイントの数ｎを見つけるために、システムは次を確認し得る。

は、（１）を所与のｎに対して解くことで得られるレートポイントであり、ξ_ｍａｘは、システムの最大許容品質ギャップ（つまり、部分最適性）である。例えば、実用的な状況では、ξ_ｍａｘは１又は２％に設定され得る。

平均品質に加えて、各クライアントが消費する平均帯域幅は次のように表され得る。

及び

システム全体で消費される平均帯域幅は、その結果、次のようになる。

無限の場合、これらの式はすべて、ネットワークの平均帯域幅に収束する。

換言すれば、ラダーポイント（ストリーム）の数を増やすことには、平均品質とストリーミングシステムが消費する平均帯域幅との両方を増加させる効果がある。どちらの量にも自然な限度がある。

原理上、上記のすべての定義を所与として、且つ実際には帯域幅が通常ストリーミングシステムの運用コストにおける因子であることを考慮すると、最適ラダー設計の問題はまた、平均帯域幅の最小化の問題として定式化され得る。

Ｑ_ｍｉｎは、システムによって実現される品質に対する一定の限度である。

しかしながら、これらの問題には関連性があり、いくつかの場合、全く同じ解が得られることに留意されたい。よって、所与のｎ及び他のすべての制約について、問題（１７）の解と一致するように品質限度、すなわち、このようなシステムで実現可能な最高の品質である。

が選択される場合、問題（２９）の解は、問題（１７）と全く同じラダー

をもたらす。更に、問題（１７）と問題（２９）との両方がどちらも同じクラスに属し、各コーデックに割り当てられるストリームの数の選択は離散最適化の領域に属し、残りの部分は、一般に、制約付き連続領域最適化問題として理解され得る。

より一般的には、ｋ個のコーデック及びｍ個のクライアントを有するＡＢＲストリーミングシステムが考えられ、この場合、ネットワーク帯域幅の分布ｐとクライアントの種類πが既知であり、最適化基準として特定のフィギュアオブメリット関数（ｆｉｇｕｒｅ ｏｆ ｍｅｒｉｔ ｆｕｎｃｔｉｏｎ）を定義する。

これは、システム全体のパフォーマンスを把握する。特別な場合には、先に説明したように、このようなフィギュアオブメリット関数は、ＡＢＲシステムの平均品質又は平均帯域幅と一致することもあれば、品質及び帯域幅の両方の表現を成分として用いる、より複雑な関数であることもある。

次いで、且つ特定の更なる条件下で、最適化問題は、

であるような数

、
及びストリーミングシステムが提供するパフォーマンス全体が最大になるような、ラダーレート

を見つけることの１つになる。

ポイントの全数ｎはまた、例えば、次のような特定の制約を受けることがある。

は、システムにどれだけのラダーポイントが十分であるかを決定するために使用される追加のパフォーマンス基準であり、各コーデックのラダーポイントのレート値

は、問題（３１）の解となる。

図６は、式（３１）及び式（３２）によって定義された問題が解かれる一実施形態による、最適化されたマルチコーデックエンコーディングラダーを決定するための方法の主なステップを示すフロー図である。以下に、実用的なマルチコーデックシステムの具体例、及び提案される方法を適用することによって見出されたそれぞれの解を示す。図６のブロックに示された関数の一部又は全部は、（上述のように、コンピュータサーバによって実行され得る）エンコーダ１２０によって実行されてもよい。

図６の方法は、ブロック６０５において開始することができ、これは、所与のｋ個のコーデック及びコンテンツに対する品質レート関数のモデルを定義するプロセスを含む。これは、’７２３出願で述べられているように、例えば、各コーデックで１つ又は複数のプローブエンコーディングを行い、次いで、各プローブの後に得られた（品質，レート）ポイントを通るモデル曲線をフィッティングすることで行うことができる。

ブロック６１０、６４０、及び６５０の機能の組み合わせは、エンコーディングラダーのポイント（又はストリームの総数）の十分な値ｎを見つけるループを記述している。ブロックの６１５、６３５、及び６５５の機能の組み合わせは、各コーデックに割り当てられたストリームの数ｎ_１，．．．，ｎ_ｋを見つけるループを記述している。このような数の組み合わせは、ｎ_１＋・・・＋ｎ_ｋ＝ｎを満たさなければならず、この時点でのｎは前のループで与えられる。

ブロック６２０の機能は、範囲又はレートの条件などのいくつかの追加条件に従うフィギュアオブメリット関数

が最大値に到達するように、各コーデックに対するエンコーディングラダーレート

を見つけるプロセスを記述している。この機能は、上記の問題（３１）のうち、数ｎ及びｎ_１，．．．，ｎ_ｋが固定されている部分を効果的に解く。このような最適化問題は、原理的には、連続領域の非線形制約最適化問題であり得、そのためにいくつかの有効な数値的技法が利用可能である。例えば、

が、

に関して連続且つ微分可能である場合、逐次動的計画法を適用することによって解くことができる。

ブロック６２０において使用されるフィギュアオブメリット関数

は、ブロック６０５で得られた品質レート関数Ｑ_１（Ｒ），．．．，Ｑ_ｋ（Ｒ）のモデル、並びにネットワーク帯域幅分布ｐ、クライアント選択ロジックのモデル、及びすべての種類のクライアントの分布πに内部的に依拠し得る。特別な場合には、このようなフィギュアオブメリット関数は、平均品質又は平均帯域幅使用量関数と等価であり得、これらは先に示したように導出され得る。

ブロック６２０及び６２５の機能は、所与のポイントの総数ｎについて、最良の解

の選択プロセスを記述している。この時点で選択された解は、（２）で定義された完全な問題の解となる。

最後に、ブロック６４０に示すように、図６に記載の方法は、所与のストリームの総数ｎがラダーを生成するのに十分であるか否かを確認することであって、十分であれば、次いで、ブロック６４５に示すように、ストリーミングシステムにおいて格納又は使用するためのそのようなラダーのパラメータを出力する、ことを含む。

より一般的に言えば、図６に示すマルチコーデックエンコーディングラダーを決定する方法の機能は、以下のように記述され得る。
１）マルチコーデックＡＢＲラダーで使用されるストリームの総数ｎを選択する。

２）各コーデックに割り当てられるストリームの数ｎ_１，．．．，ｎ_ｋを選択し、
ａ）そのような数がｎ_１＋・・・＋ｎ_ｋ＝ｎを満たし、
ｂ）このような数の一部が、実際には０に設定され得、所与のコンテンツ、コーデック、クライアント、ネットワーク、及び他の制約において、一部のコーデックを使用しても何の利点ももたらさないことを示唆する。

３）各コーデックのレート

を選択し、このような選択はすべて以下の影響を受ける。

ａ）品質レート関数Ｑ_１（Ｒ），．．．，Ｑ_ｋ（Ｒ）によって取得された、コーデック及びコンテンツの特性、
ｂ）ネットワーク帯域幅分布ｐ（Ｒ）によって取得されたネットワークの特性、
ｃ）クライアントのデコード及び切り替えの能力と、クライアントの分布π、並びに
ｄ）ビットレートの範囲に関する制約など、オペレータが定義する更なる制約。

以下の説明では、本明細書で（例えば、図６に示すように）提供されるマルチコーデックＡＢＲエンコーディングラダー決定の技法を用いた実験結果のいくつかの例を提供しており、その中で利点が明らかになる。これらの実験では、ＲＡＷの７２０ｐ５０のビデオクリップの選択的連結により作成した３つのビデオシーケンスを使用した（ＹＵＶビデオシーケンス（ＹＵＶ ｖｉｄｅｏ ｓｅｑｕｅｎｃｅｓ）、ｈｔｔｐｓ：／／ｍｅｄｉａ．ｘｉｐｈ．ｏｒｇ／ｖｉｄｅｏ／ｄｅｒｆ／で入手可能）。これらのシーケンスは、このようなシーケンスがエンコーダに提示する難易度に基づいて、本明細書では「容易」、「普通」、及び「複雑」と呼ばれる。エンコーダは、それぞれＨ．２６４及びエンコーダを実装するオープンソースのｘ２６４及びｘ２６５のプロジェクトを使用した。ストリーミングに適した典型的なコーデックの制約（ＧＯＰ、ＨＲＤ、参照フレーム、及びＢフレーム）を両方の場合に適用した。品質の測定にはＳＳＩＭ指標を用いた。Ｈ．２６４エンコーダを作動させる場合、ベースラインプロファイル及びメインプロファイルにおける作動は、これらのパフォーマンスがかなり異なるため、別々に検討している。

すべてのコーデックのパフォーマンスをモデリングするために、次の品質レートモデル関数を使用した。

表２では、コーデック及びコンテンツについて得られたモデルパラメータα、βの値を示している。図７は、取得された品質レート関数の形状を示したグラフを示している。

図７から明らかなように、Ｈ．２６４と比較してＨＥＶＣコーデックが実現できるゲインは、コンテンツに大きく依存する。そのため、「容易」であるコンテンツではほとんどゲインがなく、「普通」及び「複雑」であるコンテンツではゲインが顕著になる。Ｈ．２６４のベースラインプロファイルとメインプロファイルとの間の差も、コンテンツに依存しているが、その程度はやや低い。よって、「容易」であるコンテンツの場合、図７に示す、対応するプロット間には依然として差がある。

ネットワーク帯域幅モデルを得るために、ＬＴＥネットワークのスループット測定値を使用し、次の解析モデルに当てはめた。
ｐ（Ｒ）＝αｆ（Ｒ，σ_１）＋（１－α）ｆ（Ｒ，σ_２） （３４）

は、レイリー分布の確率密度関数であり、α、σ_１、及びσ_２は、モデルパラメータである。

本明細書においてネットワーク１及びネットワーク２と呼ばれる２つのモデルは、ＬＴＥネットワークのスループットをセル内の２つの可能なユーザ数でスケーリングすることにより得られる。結果として得られたモデルパラメータ及びネットワークモデルのプロットを表３及び図８にそれぞれ示す。

上記の品質レート及びネットワークモデルを所与として、ストリーミングシステムの実際に関連するいくつかの構成に対して最適なエンコーディングラダーが決定され得る。すべての例示的な状況において、以下の制約を用いた。
・最小ビットレートの限度：ｒ_ｍｉｎ＝５０［ｋｂｐｓ］、
・最大ビットレートの限度：ｒ_ｍａｘ＝１００００［ｋｂｐｓ］、及び
・最初のストリームの最大ビットレートの限度：

最適化基準として、平均品質全体

を検討した。結果は、トップレンディションにおいて実現された品質レベルＱ^ｎ、平均品質

、
及びクライアントのすべての種類及び全体で実現可能な品質ギャップξについて報告される。

最初に、ストリーミングシステムが１つのコーデックしか使用していない平凡な例を検討した。このような場合、１つのコーデックと、１つのラダー、例えばＬ_１と、このラダーからストリームをデコードし得る１種類のクライアントしかない。これは、次の最適化問題をもたらす。

この場合に、

の導出を記述するＡＢＲストリーミングシステムが図９に示されている。

本システムはシングルコーデックＡＢＲストリーミングシステムであり、これは、以下に詳述するマルチコーデックＡＢＲストリーミングシステムとの比較のために提供されている。

Ｈ．２６４ベースライン、Ｈ．２６４のメイン、及びＨＥＶＣコーデックをそれぞれ考慮することにより構築された最適なラダーの例を表４～表６に示す。

表４～表６からいくつかのことが分かる。

第１に、異なるネットワークに対して設計された最適なエンコーディングラダーは異なって見える。ネットワークモデル１に対して設計されたエンコーディングラダーは、帯域幅分布のピークに対応する１Ｍｂｐｓ付近にビットレートが集中している。ネットワークモデル２に対して設計されたエンコーディングラダーは、ピーク帯域幅分布に対応する２Ｍｂｐｓ付近にビットレートが集中している。

第２に、異なるコンテンツに対して設計された最適なラダーは異なって見える。複雑であるコンテンツは、一般に、普通及び容易であるコンテンツに比べて、より高いビットレートが割り当てられたストリームを受信する。また、複雑であるコンテンツでは、小さな品質ギャップに到達するために、より多くのラダーポイントが必要となる。例えば、ネットワーク１且つＨ．２６４メインコーデックでは、複雑であるコンテンツは、２％未満のギャップに到達するために８つのストリームを必要とする。それに比べて、普通であるコンテンツでは４つのストリームしか必要ではなく、容易であるコンテンツでは２つのストリームで十分である。

第３に、異なるコーデックに対して設計された最適なラダーも異なって見える。より効率的なコーデックを用いると、必要なエンコーディングラダーストリームの数は少ない。例えば、ネットワーク１、複雑であるコンテンツ、且つ２％の品質ギャップの限度の場合、エンコーディングラダーは、Ｈ．２６４ベースラインでは９つのストリームを有し、Ｈ．２６４メインでは８つのストリームを有し、ＨＥＶＣは７つのストリームを有する。

次に、図１０に示すように、Ｈ．２６４ベースライン及びＨ．２６４メインを有する２コーデックＡＢＲストリーミングシステムを考える。ここで、クライアントは２つの種類であり、すなわち、Ｈ．２６４ベースラインストリームしかデコードできないクライアント（レートセレクタ＋デコーダ１）と、Ｈ．２６４ベースライン及びＨ．２６４メインのコーデックを用いてエンコードされたストリームの間でデコードして切り替えることができるクライアント（レートセレクタ＋デコーダ１）とである。この場合に、

の導出はまた、図１０に示されている。

本システムは、図５に関して以前に説明した問題の変形形態であるが、ただし、第２の種類のコーデック（Ｈ．２６４メイン）しかデコードできないデコーダが存在しない。このようなデコーダは、実際にすべてのＨ．２６４メインプロファイルデコーダがＨ．２６４ベースラインストリームもデコードできる必要があるため、除去されている。

このようなシステムに対して構築された最適なエンコーディングラダーの例を表７及び表８に示す。これらのエンコーディングラダーの設計においては、Ｈ．２６４ベースラインしかデコードできないデバイスがクライアントの総数の１０％を占め、Ｈ．２６４ベースライン及びＨ．２６４メインの両方をデコードできるデバイスが９０％を占めると仮定している。

表７及び表８で提示されている結果は、Ｈ．２６４ベースラインエンコーディングは、常にエンコーディングラダーの最低レート（及び解像度）で行われなければならず、またＨ．２６４メインプロファイルエンコーディングは、常にストリームの最高レート（及び解像度）で行わなければならないという一般的な考えを覆すものである。更に、表７及び表８によれば、最適なラダーはＨ．２６４メインストリームを全く含まない場合がある。これは、例えば、「容易」であるコンテンツの場合、及びレンディションの数が６未満の場合に起こる。また、このことは、「普通」及び「複雑」であるコンテンツでも起こるが、許容されるストリームの数が少ない場合でも起こる。

加えて、表７及び表８によれば、シングルコーデックラダーとデュアルコーデックラダーとの間で切り替わるポイント（ｎ＝４、普通であるコンテンツの場合など）では、シングルＨ．２６４ベースラインストリームは利用可能な最低ビットレートに割り当てられない。その代わり、中間レートに置かれ、Ｈ．２６４ベースラインクライアントに提供され得る総平均品質を最大化する。ｎ≧５とし、２つのストリームをＨ．２６４ベースラインに割り当てた場合、ここでも、そのレートは最低ビットレートに配置されない。その代わり、どちらの種類のクライアントも有意義に使えるように、Ｈ．２６４メインに割り当てられたレートの間にある中間ポイントに配置される。

図１１は、エンコーディングラダーのポイントと、Ｈ．２６４ベースライン及びＨ．２６４ベースライン／メイン切り替え可能クライアントが行う切り替え決定を示すグラフである。この場合のラダーポイントは、「普通」であるコンテンツ、ネットワーク１（表７）のために設計された８つのストリームによるエンコーディングラダーに対応する。このラダーは、Ｈ．２６４ベースラインがエンコードした１７９及び８７４ｋｂｐｓのストリームと、Ｈ．２６４メインがエンコードした６０、２１７、４６５、８２１、１３６２、及び２４６４ｋｂｐｓのストリームとを含む。

更に図１１から分かるように、Ｈ．２６４ベースラインしか使えないクライアントは、このようなコーデックでエンコードされた１７９及び８７４ｋｂｐｓのストリームの両方を使用する。同時に、Ｈ．２６４ベースライン及びＨ．２６４メインの両方をデコードできるクライアントは、Ｈ．２６４メインを用いてエンコードされて６つのレートと、Ｈ．２６４ベースラインによってエンコードされた１７９ｋｂｐｓの１つのレートとを選択する。この７つのレートの構成により、このクライアントはストリーミング時に最高の品質を実現することができる。

ここでも、Ｈ．２６４ベースラインストリームの部分のみを選択し、そのようなストリームのすべてをラダーの最初に配置しないことは新しいことであり、自明ではなく、Ｈ．２６４ベースライン及びＨ．２６４メインのプロファイルにレートを割り当てる既存のプラクティスが最適ではないことを示している。

次に、図１２に示すように、３種類のクライアントを有する２コーデックＡＢＲストリーミングシステムを考える。図示のように、３種類のクライアントは、（ｉ）Ｈ．２６４ストリームしかデコードできないクライアント（レートセレクタ＋デコーダ１）（例えば、ＰＣ上のウェブレイヤ）、（ｉｉ）Ｈ．２６４ストリーム又はＨＥＶＣストリームのいずれかをデコードできるが、それらを切り替えることができないクライアント（レートセレクタ＋デコーダ２）（例えば、アンドロイド（商標）デバイス上のＤＡＳＨプレーヤ、スマートテレビ）、及び（ｉｉｉ）Ｈ．２６４及びＨＥＶＣのストリームをデコードして切り替えることができるクライアント（レートセレクタ＋デコーダ３）（例えば、最近のアップル社のデバイスに搭載されているネイティブＨＬＳプレーヤ）である。

この場合の最適化問題は、デコーダ２の実現可能な品質がここでは次のようになることを除いて、式（１７）で定義された問題と同じである。

この最大値演算によれば、第２のコーデック（ＨＥＶＣ）を使用して実現できる品質が第１のコーデック（Ｈ．２６４）の１つよりも低い場合は、Ｈ．２６４でエンコードされたストリームをそのようなデバイスに送信する。

この場合に、

の導出を説明するシステム図が図１２に示されている。

このようなシステムに対して構築された最適なラダーの例を表９～表１４に示す。コンパクトにするために、ネットワークモデル１の結果のみを掲載している。しかしながら、各種のクライアントのいくつかの異なる分布が考えられる。表９～表１１では、切り替え可能なクライアントがＨＥＶＣ対応クライアントの数の半分を占める場合を考え、表１２～表１４では、切り替え可能なクライアントが存在しない場合を考える。

これらの表に基づいて、いくつかのことが分かる。

第１に、表は、特定の種類のコンテンツでは、ＨＥＶＣを使用しても品質が向上しない場合があり、そのようなコンテンツでは、Ｈ．２６４でエンコードされたコンテンツのみを含むラダーを生成するのが適切であることを示している。

第２に、ＨＥＶＣストリームを含めることは、ＨＥＶＣ対応デバイスの割合が大きい場合にのみ意味があり得る。表９は、全デバイスの約７０％がＨＥＶＣをデコードできるという仮定で始まり、これは、１２以上のストリームが許可されているときに、そのうちのいくつかはＨＥＶＣ専用であり得る境界線のようである。この場合、ＨＥＶＣ対応クライアントの半数が切り替え可能でもある状況を考慮していることに留意されたい。（表１２～表１４に例示するように）切り替えできない場合、システム全体のパフォーマンスを実質的に向上させるためには、ＨＥＶＣ対応デバイスのデプロイメントを更に高める必要があり得る。

第３に、ＨＥＶＣを含める場合、ラダーにおけるストリームの総数が十分に多いことが必要であり得る。７０％のデバイスでＨＥＶＣが利用可能である場合、普通であるコンテンツには少なくとも１０ストリーム、複雑であるコンテンツには少なくとも１２ストリームが必要であることが分かる。デプロイされているＨＥＶＣクライアントの割合が高ければ、そのようなレンディションの数は少なくなり得る。例えば、ＨＥＶＣが９０％のデバイスで利用可能である場合、これを含み始めるのに必要なラダーポイントの数が約６レンディションに減ることが分かる。しかしながら、現在、Ｈ．２６４のみのエンコードでは、通常、約５ストリームを使用すれば十分であることを考えると、ＨＥＶＣのデプロイメントには、デコード可能なデバイスの数が多くても、余分なレンディションというコストがかかることが明らかになった。

次に、以下の表では、Ｈ．２６４／ＨＥＶＣ切り替え可能クライアントが存在しない場合を考える。

表１２～表１４の結果に基づいて、クライアントのＨ２６４／ＨＥＶＣ切り替え能力を使用しないことは、システムパフォーマンスに悪影響を及ぼすことが分かる。第１に、ＨＥＶＣをサポートするためのストリームの数を一層増やす必要がある。例えば、複雑であるコンテンツの場合、ＨＥＶＣの７０％デプロイメントでは１２ストリームではもはや足りず、９０％デプロイメントには少なくとも７ストリームが必要になる。更に、同じ数のストリームでの品質全体及び品質ギャップも若干低い。

上記の差は、切り替えを行うクライアントを実際に使用することが有用であり得る理由を説明しており、またクライアントプール全体におけるそのようなクライアントの数の％、コンテンツの特性、ネットワークなどの因子を考慮して、そのようなクライアントのラダーを生成することが更に有用である理由を説明している。

検討する最後の例示的なＡＢＲストリーミングシステムを図１３に示す。この例では、Ｈ．２６４ベースラインプロファイル及びＨ．２６４メインプロファイルは別々のコーデックとして扱われ、ＨＥＶＣはシステムがサポートしなければならないもう１つのコーデックと見なされる。更に、例示的なＡＢＲストリーミングシステムは、次の４種類のクライアントを含む、すなわち、（ｉ）Ｈ．２６４ベースラインストリームしかデコードできないクライアント（レートセレクタ＋デコーダ１）（例えば、従来のポータブルデバイス）、（ｉｉ）Ｈ．２６４ベースラインストリームとＨ．２６４メインストリームとをデコードして切り替えることしかできないクライアント（レートセレクタ＋デコーダ２）（例えば、ＰＣ上のウェブプレーヤ）、（ｉｉｉ）Ｈ．２６４及びＨＥＶＣのストリームのすべてをデコードでき、Ｈ．２６４ベースラインとＨ．２６４メインとを切り替えることができるが、Ｈ．２６４とＨＥＶＣとを切り替えることはできないクライアント（レートセレクタ＋デコーダ３）（例えば、アンドロイドデバイス上のＤＡＳＨプレーヤ、スマートテレビ）、及び（ｉｖ）すべてのストリームをデコードして切り替えることができるクライアント（レートセレクタ＋デコーダ４）（例えば、最近のアップル社のデバイス上に搭載されているネイティブＨＬＳプレーヤ）を含む。

この場合の最適化問題は、式（１７）において上で定義された問題を一般化したもので、各クライアントにおける最終出力と全体の流れを図１３で説明している。更に、先に述べた最適化問題を解くための方法がこの場合に適用される。

図１３に示すシステムに対して構築された最適なラダーの例を表１５及び表１６に示す。提示をコンパクトにするために、ネットワークモデル１の結果のみを掲載している。

表１５及び表１６から次のことが分かる。

第１に、Ｈ．２６４／ＨＥＶＣシステムに関する先の結果と同様に、ＨＥＶＣ対応デバイスの割合が高くなければならず、しかも一部のコンテンツではＨＥＶＣが依然として使用されない。表１４では、ＨＥＶＣ対応デバイスの全割合は６０％であり、ＨＥＶＣに割り当てられたストリームはなかった。表１５では、ＨＥＶＣ対応デバイスの全割合は７０％であり、ＨＥＶＣストリームを普通及び複雑であるコンテンツのラダーに含めるには十分であった。

加えて、ＨＥＶＣが含まれている場合、それは明らかにＨ．２６４メインレンディションを置き換え、Ｈ．２６４ベースラインレンディションを残すという代償を払っている。したがって、限られた数のレンディションで、ＨＥＶＣ対応クライアントをサポートするために生成され得る最良のラダーは、Ｈ．２６４ベースライン及びＨ．２６４メインのプロファイルレンディション、又はＨ．２６４ベースライン及びＨＥＶＣレンディションのいずれかを含む可能性があると思われる。しかし、３つのコーデックがすべて使用される場合は、この限りではない。

これらの２つのコーデックの混合の間の最適化は、コンテンツに依存しているように見え、また、含むことができるレンディションの総数ｎにも影響される。
ここでもこの最適化技法の威力が実証され、Ｈ．２６４ベースラインプロファイルを別個のコーデックとして扱うことが、マルチコーデックのユースケースにおける最終的なプロファイルの構造及び形状に対して大きな影響を与えることを示している。

当然のことながら、提案された方法はまた、ＶＰ９、ＡＶ１、ＶＶＣなどの異なるコーデックにも適用され得る。
図１４は、一実施形態による、本明細書で説明される方法を用いてマルチコーデックＡＢＲラダー生成を組み込んだマルチコーデックＡＢＲストリーミングシステム１４００のブロック図である。分かるように、図１４に示す構成要素は、図１のＡＢＲストリーミングシステム１００に対応し得る。図１４は、マルチコーデックエンコーディングラダーの決定及びストリーミングに使用される構成要素に関する更なる詳細を含む。更に、図１と同様に、実施形態は、任意の数の個々の構成要素を有していてもよく、これらの構成要素は、様々な地理的位置に分散されてもよく、及び／又は任意の数のコンピュータ（例えば、コンピュータサーバ）によって実行されてもよい。

マルチコーデックＡＢＲストリーミングシステム１４００におけるビデオはビデオソース１４０５から到来する。所望の機能に応じて、このソースは、何らかの中間フォーマットでエンコードされたビデオを格納するオリジンサーバを含むこともできるし、例えばＲＴＭＰプロトコルで配信される、ライブストリームとすることもできる。

次いで、このビデオは、いくつかの追加的な情報と共に、マルチコーデックＡＢＲプロファイルジェネレータ１４１０によって受信され、マルチコーデックＡＢＲプロファイルジェネレータ１４１０は、マニフェスト１４１５として提示されたエンコーディングラダー全体の記述を生成し、具体的なエンコーディング命令がエンコーダ１４２０（エンコーダ１～Ｎ）に配信され、エンコーダ１４２０は、各ストリームをエンコードする役割を与えられる。マニフェスト１４１５及びエンコード命令は、例えば、生成するストリームのコーデックタイプ、目標ビットレート、解像度、フレームレート、及び他のパラメータを含み得る。エンコードされたストリームは、その後、コンテンツオリジンサーバ１４２５に置かれ、クライアント１４３５に配信するためにＣＤＮ＋アクセスネットワーク１４３０にプッシュされる。

マルチコーデックＡＢＲプロファイルジェネレータ１４１０によって生成されたマニフェスト１４１５は、マニフェストフィルタリング／ジェネレーションロジック１４４０によって更に処理されてもよく、マニフェストフィルタリング／ジェネレーションロジック１４４０は、ストリーミングシステムにおけるクライアントの各種類の能力に基づいて、このようなクライアントに関連するレンディションのみを残してもよい。例えば、Ｈ．２６４ベースラインのコンテンツしかデコードできないクライアントのために、Ｈ．２６４ベースラインエンコードされたレンディションだけを残すことができる。或いは、例えばＨ．２６４／ＨＥＶＣ切り替え可能コーデックを考えると、使用されているコーデックに関わらず、次の各レートＲ^ｉ＋１≧Ｒ^ｉについて、前のレートよりも良い品質Ｑ^ｉ＋１≧Ｑ^ｉを提供することが保証されるように、レンディションの順序付けられた部分を残すことができる。当然のことながら、これにより、いくつかのレートポイントが省略されることがあるが、その他の点では、このような切り替え可能なコーデックが使用するための可能な限り最高のラダーを作り出すことができる。このようなフィルタリングロジックは、この場合では５９５ｋｂｐｓのＨ．２６４ストリームが省略されるべきであることを示す図４Ｂを考慮して理解され得る。フィルタリングされると、最終的なエンコーディングラダーは、マニフェストオリジン＋ＣＤＮ１４５０上にＤＡＳＨ又はＨＬＳのマニフェスト１４４５として格納され得る。

再生中に、各種類のクライアント１４３５がコンテンツへのリンクにアクセスを試みた場合、デバイス検出ロジック１４５５がその要求を解析して、コンテンツを求めているクライアント１４３５の種類を特定できる。このような検出は、受信するサーバ、又はウェブページに埋め込まれたＪａｖａｓｃｒｉｐｔ（登録商標）ロジックのいずれかによって行われ得る。このような検出は、ウェブブラウザの種類及びバージョン、ＯＳの種類及びバージョン、デバイスのベンダ及びモデル、チップセットのベンダ及びモデルなど、クライアントシステムの一般に利用可能ないくつかのパラメータに基づき得る。

クライアント１４３５の種類が特定されると、クライアントがサポートし得る一式のストリームを含む、適切にフィルタリングされたマニフェストに向けられ得る。マニフェストが受信されると、各クライアント１４３５はＡＢＲストリーミングシステムにおいて通常期待されるように動作し得る。

従来のＡＢＲストリーミングシステムにはない、このマルチコーデックＡＢＲストリーミングシステム１４００のいくつかの特徴は、以下を含む。
・複数のコーデックでエンコードされたストリームを含む出力マニフェスト１４１５を生成するマルチコーデックＡＢＲプロファイルジェネレータ１４１０、
・マルチコーデックＡＢＲプロファイルジェネレータ１４１０の出力をフィルタリングし、システム内のクライアント１４３５のそれぞれの能力に合わせてラダーをカスタマイズする（具体的には、フィルタリングプロセスは、シングルコーデックを使用してエンコードされたストリームのみを残してもよいし、複数のコーデックでエンコードされたストリームの組み合わせを残してもよく、それらのビットレートソートされたシーケンスも、品質レベルが単調増加するシーケンスを生成する）マニフェストフィルタリング／ジェネレーションロジック１４４０、
・クライアント１４３５の種類を特定し、検出されたクライアント１４３５の種類に対して１４４５がフィルタリング／生成されたマニフェストを選択するデバイス検出１４５５、及び
・その後に、フィルタリングされたマニフェストに記述されているコンテンツを受信して再生するクライアント１４３５。

いくつかの実施形態によれば、マニフェストフィルタリング／ジェネレーションロジック１４４０は、ＡＢＲプロファイルジェネレータ１４１０によって生成された品質アノテーション、又はＤＡＳＨ規格で定義された「ｑｕａｌｉｔｙ＿ｒａｎｋ」識別子に依拠し得る。「ｑｕａｌｉｔｙ＿ｒａｎｋ」識別子が使用される場合は、識別子は、すべてのコーデックへの適応セットにわたって適切に割り当てられていなければならない。ＤＡＳＨマニフェストの場合に適応セット間の切り替えを可能にする追加のアノテーションは、切り替え可能なクライアントの場合にも含めなければならない。

マニフェストフィルタリングアルゴリズムの具体的な例として、レート及び品質の点で単調増加する一式のポイントを残すことが図１５に示されている。２つのコーデックに対するラダーポイントを所与として、ブロック１５１０において、これを単純にマージしてレートに応じてソートすることにより開始する。次いで、選択ループ１５２０～１５６０が続き、各ステップにおいて、品質の点でインクリメントも提供する１５３０レートソートされたリストのポイントのみが、その後に格納される１５４０。ステップ１５７０において、最終的なフィルタリングされたラダーが得られ、出力に送られる。

図１５の例では、例えば、コーデック１はＨ．２６４とすることができ、コーデック２はＨＥＶＣとすることができる。同様のアルゴリズムはまた、複数のコーデックを考えることにより再帰的に適用され得る。この場合、例えば、Ｈ．２６４ベースラインプロファイル及びＨ．２６４メインプロファイルからのレートをマージするためにまず適用され、その後、すべてのＨ．２６４ラダーポイントをＨＥＶＣラダーポイントにマージするために適用され得る。このようにして、すべての３つのコーデック（Ｈ．２６４ベースライン、Ｈ．２６４メイン、及びＨＥＶＣ）を切り替えることができるコーデックのためのラダーが生成され得る。

状況に応じて、ＡＢＲプロファイルの生成及びプロファイルのフィルタリングのための提案された実施形態は、ソフトウェア及び／又はハードウェア（例えば、図１７に示され、後述するようなコンピュータの１つ又は複数のハードウェア又はソフトウェアコンポーネント）で実装され得る、又はコンピュータ命令コードとしてコンピュータ媒体にコンパイルされて格納され得る。次いで、このようなコードは、トランスコードされるメディアを含むローカルコンピュータ上で実行され得る、又は遠隔（例えば、クラウドインスタンス）で実行され得る。また、複数のこのようなクラウドインスタンスで同時に実行され得、異なるメディア又は同じメディアの異なるチャンクを処理することもできる。このような動作の実行は、ウェブＡＰＩを作成して使用することによりオーケストレーションされ得る。

図１６は、上記の最適化技法のうちの１つ又は複数を使用し得る一実施形態による、マルチコーデックエンコーディングラダーを作成する方法１６００を示すフロー図である。図１６に示すブロックで提供される機能は、一例として提供されていることを理解されたい。代替的な実施形態は、示す機能を追加、省略、結合、分離、及び他の変更を行い得る。図１６に示すブロックのうちの１つ又は複数の機能は、例えば、ＡＢＲプロファイルジェネレータ１４１０、エンコーダ１２０、又は本明細書で説明されるマルチコーデックＡＢＲストリーミングシステムの他の構成要素によって実行されてもよい。そのため、これらの機能は、後述する図１７に示すコンピュータシステムなどのコンピュータシステムのソフトウェア及び／又はハードウェアの手段を用いて実装され得る。

ブロック１６１０において、方法１６００は、コンピュータシステムによって、ビデオを含むソースコンテンツを取得することによって開始し得る。ソースコンテンツは、デジタルマスター、メザニンファイル、入力ストリーム（例えば、ライブストリーム）、分離されたビデオ素片ストリームを含む様々なフォーマットのいずれかで提供され得る。上述のように、ソースコンテンツは、オリジンサーバを含み得るビデオソース１１０から取得され得る。

ブロック１６２０において、機能は、ソースコンテンツのためのエンコーディングラダーを生成することであって、エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、ソースコンテンツをエンコードするための個々のビットレート及び複数のコーデックの個々のコーデックを含む、ことを含む。更に、エンコーディングラダーは、

及び

の個々のビットレート並びに

及び

の個々の品質値を有する、第１のコーデックの第１のビデオストリーム及び第２のビデオストリームと、

のビットレート及び

の品質値を有する、第２のコーデックの第３のビデオストリームとを含み、

且つ

である。例えば、図４Ｂ及び図１１のグラフに示すように、本明細書で提供される技法は、異なるコーデックのストリームをストリームの品質及びレートが単調増加し得るようにインターリーブする、エンコーディングラダーの作成を可能にする。つまり、（２つ以上のコーデックを有する）エンコーディングラダーにおける各ステップは、ビットレート及び品質の両方の増加を表し得る。所望の機能に応じて、

、

、
若しくは

、
又はこれらの任意の組み合わせは、それぞれがＳＳＩＭ値、ＰＳＮＲ値、ＭＳ－ＳＳＩＭ値、又はＶＮＡＦ値を含み得る。

先に述べた例及び実施形態で示したように、エンコーディングラダーを作成するプロセスは、様々な因子のいずれかを考慮するように最適化され得る。いくつかの実施形態では、例えば、方法１６００は、複数のコーデックの各コーデックについて、ソースコンテンツのビットレートと品質値との間の関係を示す、ソースコンテンツの個々のコーデックの品質レート関数を取得することであって、ソースコンテンツのためのエンコーディングラダーを生成することが、個々のコーデックの品質レート関数に基づき、

及び

が、第１のコーデックの品質レート関数によって決定され、

が第２のコーデックの品質レート関数によって決定される、ことを更に含み得る。更に、いくつかの実施形態はまた、ソースコンテンツのためのこれらの品質レート関数を決定することを含み得る。つまり、いくつかの実施形態では、複数のコーデックの各コーデックに対する品質レート関数が、複数のコーデックの各コーデックに対するソースコンテンツの１つ又は複数のプロービングコーティングから決定される。

代替的な実施形態は、追加的又は代替的な検討事項及び／又は最適化アルゴリズムを含み得る。例えば、いくつかの実施形態では、エンコーディングラダーは、ネットワーク帯域幅分布と、エンコーディングラダーを用いてソースコンテンツがエンコードされると、ソースコンテンツをストリーミングすることができるクライアントの分布であって、クライアントの分布が、第１のコーデックと第２のコーデックとの間で切り替えを行うことができるクライアントを含む、クライアントの分布とに更に基づく。追加的又は代替的に、エンコーディングラダーを生成することは反復プロセスを用いて複数のビデオストリームを決定することを含むことができ、反復プロセスにおいて、初期の数が選択され、（１）選択された数に対するフィギュアオブメリット関数を決定するステップと、（２）次の繰り返しのために、選択された数の値を増やすステップとが、フィギュアオブメリット関数が最大値に到達するまで、繰り返される。いくつかの実施形態では、フィギュアオブメリット関数は、複数のコーデックの各コーデックに対する品質レート関数、ネットワーク帯域幅分布、若しくはクライアントの分布、又はこれらの任意の組み合わせに基づく。ネットワーク帯域幅分布は、デバイスの種類、ＣＤＮ、若しくは配信領域、又はこれらの任意の組み合わせを考慮して収集された帯域幅統計値に基づいて決定された確率密度関数を含み得る。

最後に、方法１６００のいくつかの実施形態は、エンコーディングラダーに基づいてコンテンツをエンコードすることを更に含み得る。つまり、いくつかの実施形態は、エンコーディングラダーの各ストリームについて、それぞれのストリームのコーデック及びビットレートを用いてソースコンテンツをエンコードすることにより、個々のエンコードするコンテンツを作成するステップと、個々のエンコードされたコンテンツを格納するステップとを更に含み得る。上記の実施形態で述べたように、エンコードされたコンテンツのエンコード及び格納は、１つ又は複数のエンコーダとコンテンツオリジンサーバとによってそれぞれ実行され得る（コンテンツオリジンサーバは、その後、エンコードされたコンテンツをＣＤＮ＋アクセスネットワークに送信し得る）。

図１７は、コンピュータシステム１７００の一実施形態のブロック図であり、これは、全体又は部分的に、図６、図１５、及び図１６に示す方法を含む、本明細書で説明される方法の機能のうちの１つ又は複数を実行するために使用され得る。コンピュータシステム１７００は、ＡＢＲプロファイルジェネレータ及び／又はエンコーダを含むＡＢＲストリーミングシステム（例えば、図１のＡＢＲストリーミングシステム１００及び／又は図１４のマルチコーデックＡＢＲストリーミングシステム１４００）の構成要素のうちの１つ又は複数を実施するものであってもよい。図１７は、様々な構成要素を一般的に説明するためのものに過ぎず、これらの構成要素のいずれか又はすべてが適切に利用され得ることに留意されたい。したがって、図１７は、個々のシステム要素が、どのように相対的に分離されたやり方で又は相対的により統合されたやり方で実施され得るかを広く示している。加えて、図１７に示す構成要素は、単一のデバイスにローカライズされてもよいし、及び／地理的に異なる場所に配置され得る様々なネットワークデバイス中に分散されてもよいことに留意されたい。上述のように、ＡＢＲストリーミングシステムの構成要素は、クラウドで実行されてもよい。よって、コンピュータシステム１７００は、ＡＢＲストリーミングシステムの様々な構成要素を実装するように構成された多数のコンピュータシステム（例えば、コンピュータサーバ）のうちの１つであってもよい。

コンピュータシステム１７００は、バス１７０５を介して電気的に結合され得る（又は別様に適宜通信し得る）、ハードウェア要素を備えるとして示されている。ハードウェア要素は、処理ユニット１７１０を含んでもよく、これは、限定するものではないが、１つ若しくは複数の汎用プロセッサ、１つ若しくは複数の専用プロセッサ（デジタル信号処理チップ、及び／又はグラフィックアクセラレーションプロセッサなど）、及び／又は他の処理構造を含み得、本明細書で説明される方法のうちの１つ又は複数を実行するように構成され得る。コンピュータシステム１７００はまた、限定するものではないが、マウス、キーボード、カメラ、及び／又はマイクロホンなどを含み得る、１つ又は複数の入力デバイス１７１５と、限定するものではないが、ディスプレイデバイス、及び／又はプリンタなどを含み得る、１つ又は複数の出力デバイス１７２０とを備え得る。

コンピュータシステム１７００は、１つ又は複数の非一時的ストレージデバイス１７２５を更に備えてもよく（及び／又はそれと通信してもよく）、これは、限定するものではないが、ローカル及び／若しくはネットワークアクセス可能ストレージを含むことができる、並びに／又は限定するものではないが、ディスクドライブ、ドライブアレイ、光ストレージデバイス、ソリッドステートストレージデバイス、例えばランダムアクセスメモリ（ＲＡＭ）及び／又は読み取り専用メモリ（ＲＯＭ）を含み得、これは、プログラム可能、及び／又はフラッシュ更新可能などであり得る。そのようなストレージデバイスは、限定するものではないが、様々なファイルシステム、及び／又はデータベース構造などを含む、任意の適切なデータストアを実装するように構成され得る。そのようなデータストアは、本明細書で説明されるように、１つ又は複数のデバイスに送信されるメッセージ及び／又は他の情報を記憶及び管理するために使用される、データベース及び／又は他のデータ構造を含み得る。

コンピュータシステム１７００はまた、無線通信インターフェースによって管理及び制御される、無線通信技術、並びに有線技術（イーサネット（登録商標）、同軸通信、及びユニバーサルシリアルバス（ＵＳＢ）など）を含み得る、通信サブシステム１７３０を備え得る。そのため、通信サブシステム１７３０は、モデム、ネットワークカード（無線又は有線）、赤外線通信デバイス、無線通信デバイス、及び／又はチップセットなどを含み得、これは、コンピュータシステム１７００が、１つ又は複数の通信ネットワーク上で、本明細書に説明される他のコンピュータシステム及び／又は任意の他の電子デバイスを含む（その上で実行される動作及び／又はアプリケーションを含む）、それぞれのネットワーク上の任意のデバイスと通信することを可能にし得る。よって、通信サブシステム１７３０は、本明細書の実施形態で説明されるように、データを受信及び送信するために使用され得る。

多くの実施形態では、コンピュータシステム１７００は作業メモリ１７３５を更に備え、これは、上で説明したようにＲＡＭ又はＲＯＭデバイスを含み得る。作業メモリ１７３５内に配置されると示されているソフトウェア要素は、オペレーティングシステム１７４０、デバイスドライバ、実行可能ライブラリ、及び／又は他のコード、例えば、１つ若しくは複数のアプリケーション１７４５を含み得、これは、様々な実施形態によって提供されるコンピュータプログラムを備えてもよく、並びに／又は本明細書で説明されるように、他の実施形態によって提供される方法を実装する、及び／若しくはシステムを構成するように設計されてもよい。単に、一例として、上で議論される方法に関して説明される１つ又は複数のプロシージャは、コンピュータ（及び／又はコンピュータ内の処理ユニット）によって実行可能なコード及び／又は命令として実装され得る。一態様では、次いで、そのようなコード及び／又は命令は、説明される方法に従って、１つ又は複数の動作を実行するように汎用コンピュータ（又は他のデバイス）を構成及び／又は適合するために使用され得る。

一式のこれらの命令及び／又はコードは、上で説明されるストレージデバイス１７２５及び／又は作業メモリ１７３５などの非一時的コンピュータ可読記憶媒体上に格納され得る。いくつかの場合では、記憶媒体は、コンピュータシステム１７００などのコンピュータシステム内に組み込まれ得る。他の実施形態では、記憶媒体は、内部に記憶される命令／コードを用いて、汎用コンピュータをプログラム、構成、及び／又は適合するために使用され得るように、コンピュータシステムと別個（例えば、光ディスクなどのリムーバブルメディア）であり得る、及び／又はインストールパッケージで提供され得る。これらの命令は、コンピュータシステム１７００によって実行可能な実行可能コードの形態をとり得る、並びに／又はコンピュータシステム１７００上へのコンパイル及び／若しくはインストールに応じて、（例えば、様々な概して利用可能なコンパイラ、インストールプログラム、圧縮／解凍ユーティリティなどのいずれかを使用して）実行可能コードの形態をとるソース及び／又はインストール可能コードの形態をとり得る。

実質的変形形態が具体的要件に従って行われ得ることが、当業者には明らかになるはずである。例えば、カスタマイズされたハードウェアもまた使用され得る、及び／又は特定の要素が、ハードウェア、ソフトウェア（アプレットなどのポータブルソフトウェアを含む）、又はこれら両方に実装され得る。更に、ネットワーク入力／出力デバイスなどの他のコンピューティングデバイスへの接続が採用され得る。

添付の図面を参照すると、メモリを備え得る構成要素は非一時的機械可読媒体を含み得る。本明細書で使用される場合、「機械可読媒体」及び「コンピュータ可読媒体」という用語は、機械を特定のやり方で動作させるデータを提供することに関わる、任意の記憶媒体を指す。本明細書において上で提供される実施形態では、様々な機械可読媒体は、実行のために、命令／コードを処理ユニット及び／又は他のデバイスに提供することに関わり得る。追加的又は代替的に、機械可読媒体は、そのような命令／コードを格納及び／又は搬送するために使用され得る。多くの実装形態では、コンピュータ可読媒体は物理的及び／又は有形記憶媒体である。そのような媒体は、限定するものではないが、不揮発性媒体、揮発性媒体、及び伝送媒体を含む多くの形態をとり得る。一般的形態のコンピュータ可読媒体は、例えば、磁気及び／若しくは光学媒体、孔のパターンを伴う任意の他の物理的媒体、ＲＡＭ、プログラマブルＲＯＭ（ＰＲＯＭ）、イレーサブルＰＲＯＭ（ＥＰＲＯＭ）、フラッシュ－ＥＰＲＯＭ、任意の他のメモリチップ若しくはカートリッジ、本明細書で後述されるような搬送波、又はそこからコンピュータが命令及び／若しくはコードを読み取り得る任意の他の媒体を含む。

本明細書で議論される方法、システム、及びデバイスは例である。様々な実施形態は、必要に応じて、様々なプロシージャ又は構成要素を省略、代用、又は追加し得る。例えば、ある実施形態に関して説明される特徴が、様々な他の実施形態において組み合わされてもよい。実施形態の異なる態様及び要素が同様に組み合わされてもよい。本明細書で提供される図面の様々な構成要素は、ハードウェア及び／又はソフトウェアに具現化され得る。また、技術が進化するため、要素の多くは、本開示の範囲をそれらの具体的例に限定しない例である。

本明細書全体を通して、「１つの例」、「一例」、「特定の例」、又は「例示的実装形態」への言及は、特徴及び／又は例に関連して説明される特定の特徴、構造、又は特性が、特許請求の範囲に記載の主題の少なくとも１つの特徴及び／又は例に含まれてもよいことを意味する。したがって、語句「１つの例では」、「一例では」、「特定の例では」、若しくは「特定の実装形態では」など、又は本明細書全体を通して様々な場所における他の同様の語句の表出は、必ずしもすべて、同じ特徴、例、及び／又は限定を指すわけではない。更に、特定の特徴、構造、又は特性は、１つ又は複数の例及び／又は特徴において組み合わされてもよい。

本明細書に含まれる詳細な説明の一部は、具体的装置又は専用コンピューティングデバイス若しくはプラットフォームのメモリ内に格納されるバイナリデジタル信号上の動作のアルゴリズム又は象徴的表現の観点から提示される。本特定の明細書の文脈では、具体的装置などの用語は、プログラムされると、プログラムソフトウェアからの命令に従って特定の動作を実施するための汎用コンピュータを含む。アルゴリズム記述又は象徴的表現は、その研究の内容を他の当業者に伝達するために信号処理又は関連技術における当業者によって使用される技法の例である。アルゴリズムは、ここでは、概して、動作又は所望の結果につながる同様の信号処理のセルフコンシステントシーケンスと見なされる。本文脈では、動作又は処理は、物理的量の物理的操作を伴う。典型的には、必ずしもではないが、そのような量は、格納される、転送される、組み合わせられる、比較される、又は別様に操作されることが可能な電気又は磁気信号の形態をとり得る。これは、折に触れて、主に、一般的使用の理由から、ビット、データ、値、要素、記号、文字、項、数字、又は数値などとしてそのような信号を指すために好都合であると証明されている。しかしながら、これら又は同様の用語のすべてが、適切な物理的量と関連するわけではなく、単に、便宜的標識であることを理解されたい。別段の具体的な指定のない限り、本明細書の議論から明白であるように、本明細書全体を通して、「処理」、「算出」、「計算」、又は「決定」などの用語を利用する議論は、専用コンピュータ、専用コンピューティングデバイス、又は同様の専用電子コンピューティングデバイスなどの具体的装置のアクション又は処理を指すことを理解されたい。本明細書の文脈では、したがって、専用コンピュータ又は同様の専用電子コンピューティングデバイスは、典型的には、メモリ、レジスタ、又は他の情報ストレージデバイス、伝送デバイス、又は専用コンピュータ又は同様の専用電子コンピューティングデバイスのディスプレイデバイス内の物理的電子又は磁気量として表される信号を操作又は変換することができる。

本明細書で使用される場合、「及び」、「又は」、及び「及び／又は」という用語は、少なくとも部分的に、そのような用語が使用される文脈にもまた依存することが予期される、様々な意味を含み得る。典型的には、「又は」は、Ａ、Ｂ、又はＣなどのリストに関連して使用される場合、包含的意味で使用されるとＡ、Ｂ、及びＣ、そして排他的意味で使用されるとＡ、Ｂ、又はＣを意味するように意図される。加えて、本明細書で使用される場合、「１つ又は複数の」という用語は、単数形における任意の特徴、構造、又は特性を説明するために使用され得る、或いは複数の特徴、構造、若しくは特性又は特徴、構造、若しくは特性の何らかの他の組み合わせを説明するために使用され得る。ただし、これは単に例示的例であって、特許請求の範囲に記載の主題はこの例に限定されないことに留意されたい。

例示的特徴であると現在考えられるものを図示及び説明したが、特許請求の範囲に記載の主題から逸脱することなく、様々な他の修正を行うことができ、均等物を代わりに用いることができることが当業者には理解されよう。加えて、本明細書で説明される中心概念から逸脱することなく、特定の状況を特許請求の範囲に記載の主題の教示に適合するように多くの修正を行うことができる。したがって、特許請求の範囲に記載の主題は、開示される特定の例に限定されず、そのような特許請求の範囲に記載の主題はまた、添付の特許請求の範囲及びその均等物の範囲内に含まれるすべての態様を含み得ることが意図される。

Claims (20)

1. マルチコーデックエンコーディングラダーを作成するための方法であって、
   コンピュータシステムによって、ビデオを含むソースコンテンツを取得するステップと、
   前記ソースコンテンツのためのエンコーディングラダーを生成するステップであって、
   前記エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、前記ソースコンテンツをエンコードするための個々のビットレート及び複数の種類のコーデックからの個々のコーデックを含み、
   前記エンコーディングラダーが、
   
   及び
   
   の個々のビットレート並びに
   
   及び
   
   の個々の品質値を有する、第１のコーデックからの第１のビデオストリーム及び第２のビデオストリームと、
   ここで、記号ＲおよびＱの各々に関して、下付き添え字１は、前記第１のコーデックを示し、上付き添え字１は、前記第１のコーデックの最初のストリームを示し、上付き添え字２は、前記第１のコーデックの２番目のストリームを示しており、
   
   のビットレート及び
   
   の品質値を有する、第２のコーデックからの第３のビデオストリームと
   を含み、
   ここで、記号ＲおよびＱの各々に関して、下付き添え字２は、前記第２のコーデックを示し、上付き添え字１は、前記第２のコーデックの最初のストリームを示しており、
   
   且つ
   
   である、前記生成するステップとを含む、方法。
2. 前記複数の種類のコーデックの各コーデックについて、前記ソースコンテンツのビットレートと品質値との間の関係を示す、前記ソースコンテンツのための前記個々のコーデックの品質レート関数を取得することを更に含み、
   前記ソースコンテンツのための前記エンコーディングラダーを生成することが、前記個々のコーデックの前記品質レート関数に基づき、
   
   及び
   
   が前記第１のコーデックの前記品質レート関数を用いて決定され、
   
   が前記第２のコーデックの前記品質レート関数を用いて決定される、請求項１に記載の方法。
3. 前記複数の種類のコーデックの各コーデックの前記品質レート関数が、前記複数の種類のコーデックの各コーデックにおける前記ソースコンテンツの１つ又は複数のプローブエンコーディングから決定される、請求項２に記載の方法。
4. 前記エンコーディングラダーが、
   ネットワーク帯域幅分布と、
   前記エンコーディングラダーを用いて前記ソースコンテンツがエンコードされると、前記ソースコンテンツをストリーミングすることができるクライアントの分布であって、クライアントの前記分布が、前記第１のコーデックと前記第２のコーデックとの間で切り替えを行うことができるクライアントを含む、前記クライアントの分布と
   に更に基づく、請求項２に記載の方法。
5. 前記エンコーディングラダーを生成することが、反復プロセスを用いて前記複数のビデオストリームを決定することを含み、前記反復プロセスにおいて、初期の数が選択され、
   （１）前記選択された数に対するフィギュアオブメリット関数を決定するステップと、
   （２）次の反復のために、前記選択された数の値を増やすステップと
   が、前記フィギュアオブメリット関数が最大値に到達するまで、繰り返される、請求項４に記載の方法。
6. 前記フィギュアオブメリット関数が、
   前記複数の種類のコーデックの各コーデックの前記品質レート関数、
   前記ネットワーク帯域幅分布、若しくは
   クライアントタイプの前記分布、又は
   これらの任意の組み合わせ
   に基づく、請求項５に記載の方法。
7. 前記ネットワーク帯域幅分布が、
   デバイスタイプ、
   コンテンツ配信ネットワーク（ＣＤＮ）、若しくは
   配信領域、又は
   これらの任意の組み合わせ
   に関する収集された帯域幅統計値に基づいて決定された確率密度関数を含む、請求項４に記載の方法。
8. 前記複数のビデオストリームの各ビデオストリームの前記ビットレート及び対応する品質値が、前記エンコーディングラダー内で単調増加する、請求項１に記載の方法。
9. 
   、
   
   、
   若しくは
   
   、
   又はこれらの任意の組み合わせが、
   構造的類似性指数指標（ＳＳＩＭ）値、
   ピーク信号対雑音比（ＰＳＮＲ）値、
   マルチスケールＳＳＩＭ（ＭＳ－ＳＳＩＭ）値、又は
   ビデオマルチメソッドアセスメントフュージョン（ＶＭＡＦ）値
   をそれぞれ含む、請求項１に記載の方法。
10. 前記エンコーディングラダーの各ストリームについて、
    前記それぞれのストリームの前記コーデック及び前記ビットレートを用いて前記ソースコンテンツをエンコードすることにより、それぞれのエンコードされたコンテンツを作成するステップと、
    それぞれのエンコードされたコンテンツを格納するステップと
    を更に含む、請求項１に記載の方法。
11. マルチコーデックエンコーディングラダーを作成するためのコンピュータシステムであって、
    メモリと、
    前記メモリに通信可能に結合された１つ又は複数の処理ユニットとを備え、前記１つ又は複数の処理ユニットが、
    ビデオを含むソースコンテンツを取得し、
    前記ソースコンテンツのためのエンコーディングラダーを生成し、
    前記エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、前記ソースコンテンツをエンコードするための個々のビットレート及び複数の種類のコーデックからの個々のコーデックを含み、
    前記エンコーディングラダーが、
    
    及び
    
    の個々のビットレート並びに
    
    及び
    
    の個々の品質値を有する、第１のコーデックからの第１のビデオストリーム及び第２のビデオストリームと、
    ここで、記号ＲおよびＱの各々に関して、下付き添え字１は、前記第１のコーデックを示し、上付き添え字１は、前記第１のコーデックの最初のストリームを示し、上付き添え字２は、前記第１のコーデックの２番目のストリームを示しており、
    
    のビットレート及び
    
    の品質値を有する、第２のコーデックからの第３のビデオストリームと
    を含み、
    ここで、記号ＲおよびＱの各々に関して、下付き添え字２は、前記第２のコーデックを示し、上付き添え字１は、前記第２のコーデックの最初のストリームを示しており、
    
    且つ
    
    であるように構成される、コンピュータシステム。
12. 前記１つ又は複数の処理ユニットが、
    前記複数の種類のコーデックの各コーデックについて、前記ソースコンテンツのビットレートと品質値との間の関係を示す、前記ソースコンテンツのための前記個々のコーデックの品質レート関数を取得し、
    前記個々のコーデックの前記品質レート関数に基づいて、前記ソースコンテンツのための前記エンコーディングラダーを生成し、
    前記第１のコーデックの前記品質レート関数を用いて
    
    及び
    
    を決定し、
    前記第２のコーデックの前記品質レート関数を用いて
    
    を決定する、
    ように更に構成される、請求項１１に記載のコンピュータシステム。
13. 前記１つ又は複数の処理ユニットが、前記複数の種類のコーデックの各コーデックにおける前記ソースコンテンツの１つ又は複数のプローブエンコーディングから、前記複数の種類のコーデックの各コーデックの前記品質レート関数を決定するように更に構成される、請求項１２に記載のコンピュータシステム。
14. 前記１つ又は複数の処理ユニットが、
    ネットワーク帯域幅分布と、
    前記エンコーディングラダーを用いて前記ソースコンテンツがエンコードされると、前記ソースコンテンツをストリーミングすることができるクライアントの分布であって、クライアントの前記分布が、前記第１のコーデックと前記第２のコーデックとの間で切り替えを行うことができるクライアントを含む、前記クライアントの分布と
    に更に基づいて、ソースのための前記エンコーディングラダーを生成するように更に構成される、請求項１２に記載のコンピュータシステム。
15. 前記エンコーディングラダーを生成するために、前記１つ又は複数の処理ユニットが、反復プロセスを用いて前記複数のビデオストリームを決定するように構成され、前記反復プロセスにおいて、初期の数が選択され、
    （１）前記選択された数に対するフィギュアオブメリット関数を決定するステップと、
    （２）次の反復のために、前記選択された数の値を増やすステップと
    が、前記フィギュアオブメリット関数が最大値に到達するまで、繰り返される、請求項１４に記載のコンピュータシステム。
16. 前記フィギュアオブメリット関数が、
    前記複数の種類のコーデックの各コーデックの前記品質レート関数、
    前記ネットワーク帯域幅分布、若しくは
    クライアントタイプの前記分布、又は
    これらの任意の組み合わせ
    に基づくように前記１つ又は複数の処理ユニットが更に構成される、請求項１５に記載のコンピュータシステム。
17. 前記１つ又は複数の処理ユニットが、
    デバイスタイプ、
    コンテンツ配信ネットワーク（ＣＤＮ）、若しくは
    配信領域、又は
    これらの任意の組み合わせ
    に関する収集された帯域幅統計値に基づいて前記ネットワーク帯域幅分布を決定するように更に構成される、請求項１４に記載のコンピュータシステム。
18. 前記１つ又は複数の処理ユニットが、前記複数のビデオストリームの各ビデオストリームのビットレート及び対応する品質値が前記エンコーディングラダー内で単調増加するように、ソースのための前記エンコーディングラダーを生成するように構成される、請求項１１に記載のコンピュータシステム。
19. 前記１つ又は複数の処理ユニットが、
    構造的類似性指標（ＳＳＩＭ）値、
    ピーク信号対雑音比（ＰＳＮＲ値）、
    マルチスケールＳＳＩＭ（ＭＳ－ＳＳＩＭ）値、又は
    ビデオマルチメソッドアセスメントフュージョン（ＶＭＡＦ）値
    に基づいて、
    
    、
    
    、
    若しくは
    
    、
    又はこれらの任意の組み合わせを決定するように構成される、請求項１１に記載のコンピュータシステム。
20. マルチコーデックエンコーディングラダーを作成するための命令を内部に格納した非一時的コンピュータ可読媒体であって、前記命令が、１つ又は複数の処理ユニットによって実行されると、前記１つ又は複数の処理ユニットに、
    ビデオを含むソースコンテンツを取得させ、
    前記ソースコンテンツのためのエンコーディングラダーを生成させ、
    前記エンコーディングラダーによって定義される複数のビデオストリームの各ビデオストリームが、前記ソースコンテンツをエンコードするための個々のビットレート及び複数の種類のコーデックからの個々のコーデックを含み、
    前記エンコーディングラダーが、
    
    及び
    
    の個々のビットレート並びに
    
    及び
    
    の個々の品質値を有する、第１のコーデックからの第１のビデオストリーム及び第２のビデオストリームと、
    ここで、記号ＲおよびＱの各々に関して、下付き添え字１は、前記第１のコーデックを示し、上付き添え字１は、前記第１のコーデックの最初のストリームを示し、上付き添え字２は、前記第１のコーデックの２番目のストリームを示しており、
    
    のビットレート及び
    
    の品質値を有する、第２のコーデックからの第３のビデオストリームと
    を含み、
    ここで、記号ＲおよびＱの各々に関して、下付き添え字２は、前記第２のコーデックを示し、上付き添え字１は、前記第２のコーデックの最初のストリームを示しており、
    
    且つ
    
    である、非一時的コンピュータ可読媒体。