JP7113116B2 - セグメント品質誘導型適応ストリームの作成 - 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. 前記動作はさらに、
    第１ＭＡＢに対して、複数のセグメントに対応する出力セグメントのシーケンスを選択する工程であって、出力セグメントのシーケンス内の各出力セグメントは第１ＭＡＢ以下のビットレートでエンコードされている工程と、
    第１ＭＡＢでのビデオの要求を受信すると、出力セグメントのシーケンスを出力する工程とを含んでいる、請求項１５に記載のシステム。

Images