(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022008071
(43)【公開日】2022-01-13
(54)【発明の名称】セグメント品質誘導型適応ストリームの作成
(51)【国際特許分類】
H04N 21/845 20110101AFI20220105BHJP
H04N 21/238 20110101ALI20220105BHJP
【FI】
H04N21/845
H04N21/238
【審査請求】有
【請求項の数】20
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2021078889
(22)【出願日】2021-05-07
(31)【優先権主張番号】16/911,641
(32)【優先日】2020-06-25
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
2.SMALLTALK
(71)【出願人】
【識別番号】504399716
【氏名又は名称】ディズニー エンタープライゼス インコーポレイテッド
(74)【代理人】
【識別番号】100101502
【弁理士】
【氏名又は名称】安齋 嘉章
(72)【発明者】
【氏名】スコット シー ラブロッチ
(72)【発明者】
【氏名】チェタン ケー メイサー
(72)【発明者】
【氏名】ユェンイー シュエ
(72)【発明者】
【氏名】マイケル ジェイ ブラッコ
【テーマコード(参考)】
5C164
【Fターム(参考)】
5C164FA06
5C164MB41P
5C164SB26P
5C164SB41S
5C164YA21
(57)【要約】 (修正有)
【課題】改善されたストリームを生成する方法、システム及び非一時的なコンピュータ可読媒体を提供する。
【解決手段】方法は、複数のセグメントと、複数の最大平均ビットレート(MAB)を指定するエンコードラダーとを含むビデオを受信し、複数のMABの間に散在する複数の中間ビットレートを選択する。目標平均ビットレート(TAB)セグメントは、第1MABを使用して第1セグメントをエンコードすることによって生成され、第1中間平均ビットレート(IAB)セグメントは、第1中間ビットレートを使用して第1セグメントをエンコードすることによって生成される。さらに、第1TABセグメント及び第1IABセグメントに対して品質スコアを生成し、品質スコアに基づいて、第1TABセグメント又は第1IABセグメントを、第1出力セグメントとして選択し、第1MABでの第1セグメントの要求を受信すると、第1出力セグメントを出力する。
【選択図】
図8
【特許請求の範囲】
【請求項1】
方法であって、
複数のセグメントを含むビデオを受信する工程と、
複数の最大平均ビットレート(MAB)を指定するエンコードラダーを受信する工程と、
複数のMABの間に散在する複数の中間ビットレートを選択する工程と、
複数のMABの第1MABを使用して複数のセグメントの第1セグメントをエンコードすることによって第1目標平均ビットレート(TAB)セグメントを生成する工程と、
複数の中間ビットレートの第1中間ビットレートを使用して第1セグメントをエンコードすることによって第1中間平均ビットレート(IAB)セグメントを生成する工程と、
第1TABセグメント及び第1IABセグメントのそれぞれの品質スコアを生成する工程と、
それぞれの品質スコアに基づいて、第1MABでの第1セグメントに対して第1出力セグメントを選択する工程であって、第1出力セグメントは(i)第1TABセグメント又は(ii)第1IABセグメントのいずれかである工程と、
第1MABでの第1セグメントの要求を受信すると、第1出力セグメントを出力する工程とを含む方法。
【請求項2】
複数のMABの第2MABでの第1セグメントに対して第1出力セグメントを選択する工程と、
第1出力セグメントが第1MABでの第1セグメント及び第2MABでの第1セグメントの両方に使用されていることを判断すると、第1出力セグメントの共有コピーを保存する工程と、
第1MABでの第1セグメント及び第2MABでの第1セグメントを第1出力セグメントの共有コピーに関連付ける工程とをさらに含む、請求項1に記載の方法。
【請求項3】
第1MABに対して、複数のセグメントに対応する出力セグメントの第1シーケンスを選択する工程と、
複数のMABの第2MABに対して、複数のセグメントに対応する出力セグメントの第2シーケンスを選択する工程と、
出力セグメントの第1シーケンスが出力セグメントの第2シーケンスからの予め定義された閾値差内にあることを判断すると、第1MAB又は第2MABのいずれかを除去する工程とをさらに含む、請求項1に記載の方法。
【請求項4】
第1TABセグメントのそれぞれの品質スコアを生成する工程は、第1TABセグメントの視覚的品質を評価するように構成された1つ以上の客観的品質アルゴリズムを使用して第1TABセグメントを評価する工程を含んでいる、請求項1に記載の方法。
【請求項5】
第1MABでの第1セグメントに対して、潜在的なセグメントのプールを決定する工程をさらに含み、
潜在的なセグメントのプールは、
第1TABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上の追加のTABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上のIABセグメントとを含み、
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプールからセグメントを選択する工程を含んでいる、請求項1に記載の方法。
【請求項6】
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプール内で最低ビットレートのセグメントを特定する工程を含み、
最低ビットレートのセグメントは、第1TABセグメントに関連する品質スコアの予め定義された許容範囲内にある品質スコアに関連している、請求項5に記載の方法。
【請求項7】
第1MABに対して、複数のセグメントに対応する出力セグメントのシーケンスを選択する工程であって、出力セグメントのシーケンス内の各出力セグメントは第1MAB以下のビットレートでエンコードされている工程と、
第1MABでのビデオの要求を受信すると、出力セグメントのシーケンスを出力する工程とをさらに含む、請求項1に記載の方法。
【請求項8】
エンコードラダーは、ビデオのタイプに基づいて選択されたコンテンツ固有のエンコードラダーである、請求項1に記載の方法。
【請求項9】
コンピュータプログラムコードを含む非一時的なコンピュータ可読媒体であって、コンピュータプログラムコードが、1つ以上のコンピュータプロセッサの動作によって実行された時に実行する動作は、
複数のセグメントを含むビデオを受信する工程と、
複数の最大平均ビットレート(MAB)を指定するエンコードラダーを受信する工程と、
複数のMABの間に散在する複数の中間ビットレートを選択する工程と、
複数のMABの第1MABを使用して複数のセグメントの第1セグメントをエンコードすることによって第1目標平均ビットレート(TAB)セグメントを生成する工程と、
複数の中間ビットレートの第1中間ビットレートを使用して第1セグメントをエンコードすることによって第1中間平均ビットレート(IAB)セグメントを生成する工程と、
第1TABセグメント及び第1IABセグメントのそれぞれの品質スコアを生成する工程と、
それぞれの品質スコアに基づいて、第1MABでの第1セグメントに対して第1出力セグメントを選択する工程であって、第1出力セグメントは(i)第1TABセグメント又は(ii)第1IABセグメントのいずれかである工程と、
第1MABでの第1セグメントの要求を受信すると、第1出力セグメントを出力する工程とを含んでいる、非一時的なコンピュータ可読媒体。
【請求項10】
前記動作はさらに、
複数のMABの第2MABでの第1セグメントに対して第1出力セグメントを選択する工程と、
第1出力セグメントが第1MABでの第1セグメント及び第2MABでの第1セグメントの両方に使用されていることを判断すると、第1出力セグメントの共有コピーを保存する工程と、
第1MABでの第1セグメント及び第2MABでの第1セグメントを第1出力セグメントの共有コピーに関連付ける工程とを含んでいる、請求項9に記載のコンピュータ可読媒体。
【請求項11】
前記動作はさらに、
第1MABに対して、複数のセグメントに対応する出力セグメントの第1シーケンスを選択する工程と、
複数のMABの第2MABに対して、複数のセグメントに対応する出力セグメントの第2シーケンスを選択する工程と、
出力セグメントの第1シーケンスが出力セグメントの第2シーケンスからの予め定義された閾値差内にあることを判断すると、第1MAB又は第2MABのいずれかを除去する工程とを含んでいる、請求項9に記載のコンピュータ可読媒体。
【請求項12】
前記動作はさらに、
第1MABでの第1セグメントに対して、潜在的なセグメントのプールを決定する工程を含み、
潜在的なセグメントのプールは、
第1TABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上の追加のTABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上のIABセグメントとを含み、
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプールからセグメントを選択する工程を含んでいる、請求項9に記載のコンピュータ可読媒体。
【請求項13】
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプール内で最低ビットレートのセグメントを特定する工程を含み、
最低ビットレートのセグメントは、第1TABセグメントに関連する品質スコアの予め定義された許容範囲内にある品質スコアに関連している、請求項12に記載のコンピュータ可読媒体。
【請求項14】
前記動作はさらに、
第1MABに対して、複数のセグメントに対応する出力セグメントのシーケンスを選択する工程であって、出力セグメントのシーケンス内の各出力セグメントは第1MAB以下のビットレートでエンコードされている工程と、
第1MABでのビデオの要求を受信すると、出力セグメントのシーケンスを出力する工程とを含んでいる、請求項9に記載のコンピュータ可読媒体。
【請求項15】
システムであって、
1つ以上のコンピュータプロセッサと、
プログラムを含むメモリとを備え、
プログラムが、1つ以上のコンピュータプロセッサによって実行された時に実行する動作は、
複数のセグメントを含むビデオを受信する工程と、
複数の最大平均ビットレート(MAB)を指定するエンコードラダーを受信する工程と、
複数のMABの間に散在する複数の中間ビットレートを選択する工程と、
複数のMABの第1MABを使用して複数のセグメントの第1セグメントをエンコードすることによって第1目標平均ビットレート(TAB)セグメントを生成する工程と、
複数の中間ビットレートの第1中間ビットレートを使用して第1セグメントをエンコードすることによって第1中間平均ビットレート(IAB)セグメントを生成する工程と、
第1TABセグメント及び第1IABセグメントのそれぞれの品質スコアを生成する工程と、
それぞれの品質スコアに基づいて、第1MABでの第1セグメントに対して第1出力セグメントを選択する工程であって、第1出力セグメントは(i)第1TABセグメント又は(ii)第1IABセグメントのいずれかである工程と、
第1MABでの第1セグメントの要求を受信すると、第1出力セグメントを出力する工程とを含んでいる、システム。
【請求項16】
前記動作はさらに、
複数のMABの第2MABでの第1セグメントに対して第1出力セグメントを選択する工程と、
第1出力セグメントが第1MABでの第1セグメント及び第2MABでの第1セグメントの両方に使用されていることを判断すると、第1出力セグメントの共有コピーを保存する工程と、
第1MABでの第1セグメント及び第2MABでの第1セグメントを第1出力セグメントの共有コピーに関連付ける工程とを含んでいる、請求項15に記載のシステム。
【請求項17】
前記動作はさらに、
第1MABに対して、複数のセグメントに対応する出力セグメントの第1シーケンスを選択する工程と、
複数のMABの第2MABに対して、複数のセグメントに対応する出力セグメントの第2シーケンスを選択する工程と、
出力セグメントの第1シーケンスが出力セグメントの第2シーケンスからの予め定義された閾値差内にあることを判断すると、第1MAB又は第2MABのいずれかを除去する工程とを含んでいる、請求項15に記載のシステム。
【請求項18】
前記動作はさらに、
第1MABでの第1セグメントに対して、潜在的なセグメントのプールを決定する工程を含み、
潜在的なセグメントのプールは、
第1TABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上の追加のTABセグメントと、
第1MABより低いビットレートでエンコードされた1つ以上のIABセグメントとを含み、
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプールからセグメントを選択する工程を含んでいる、請求項15に記載のシステム。
【請求項19】
第1MABでの第1セグメントに対して第1出力セグメントを選択する工程は、潜在的なセグメントのプール内で最低ビットレートのセグメントを特定する工程を含み、
最低ビットレートのセグメントは、第1TABセグメントに関連する品質スコアの予め定義された許容範囲内にある品質スコアに関連している、請求項18に記載のシステム。
【請求項20】
前記動作はさらに、
第1MABに対して、複数のセグメントに対応する出力セグメントのシーケンスを選択する工程であって、出力セグメントのシーケンス内の各出力セグメントは第1MAB以下のビットレートでエンコードされている工程と、
第1MABでのビデオの要求を受信すると、出力セグメントのシーケンスを出力する工程とを含んでいる、請求項15に記載のシステム。
【発明の詳細な説明】
【背景】
【0001】
ストリーミングサービス(例えば、ビデオストリーム、オーディオストリーム、又はマルチメディアストリーム)はますます一般的になり、多種多様なユーザーによって望まれている。コンテンツをストリーミングすることで、ユーザーは事前にダウンロードするのではなく、希望する/必要なときに希望するマルチメディアを受信できる。すなわち、大量のダウンロード(例えば、映画全体)のためにユーザーを長時間待たせるのではなく、また大量のデータ保存をユーザーに強制するのでもなく、ストリーミングにより、ユーザーは必要に応じて(例えば、セグメントが開始される直前に)より大きなビデオのより小さなセグメントを取得することができる。
【0002】
ストリーミングサービスを改善するために、適応ビットレートストリーミング(ABR)が開発された。ABRは、様々なビットレートで複数のストリーム(バリアントと呼ばれることが多い)を提供することを前提として、クライアントがネットワークの状態やその他の要因に基づいて動的にバリアントを選択できるようにしている。これらのバリアントは、いくつかのラングを有するエンコードラダーを使用してエンコードされ、各ラングは、所望の出力ビットレートに対応している。多くの場合、1つ以上の連続するラングに所与の解像度を持たせることで、1つのエンコードラダーに複数の解像度(例えば、1920x1080、1280x720など)が共存できる。ABRストリームはセグメント化され(例えば、通常は各々数秒間の長さの個別サブアセットへ分割され)、クライアントは、ネットワーク条件の変化に応じて、セグメント境界でバリアントから別のバリアントへ適応できる。
【図面の簡単な説明】
【0003】
上記の態様を達成し、詳細に理解できるように、上記で簡潔に概要を述べた本明細書に記載の実施形態のより具体的な説明を、添付の図面を参照することによって得ることができる。
【0004】
ただし、他にも等しく効果的な実施形態が考えられるので、添付の図面は典型的な実施形態を示しており、したがって、限定していると見なすべきではないことに留意すべきである。
【
図1】本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリーム作成を実行するように構成されたシステムを示す。
【
図2】本明細書に開示される一実施形態による、セグメント品質誘導型適応ストリームの作成を行うために、様々なエンコード済み出力ストリームを生成するように構成されたシステムを示す。
【
図3】本明細書に開示される一実施形態による、種々の最大平均ビットレートを有する様々な異なるストリームのセグメントプールを示す。
【
図4】本明細書に開示される一実施形態による、セグメント品質誘導型適応ストリーミングを提供するためのセグメント品質分析を示す。
【
図5A】本明細書に開示されるセグメント品質誘導型適応技術を使用して生成された一連の異なるビットレートのストリームを示す。
【
図5B】本明細書に開示されるセグメント品質誘導型適応技術を使用して生成されている、最適化された一連の異なるビットレートのストリームを示す。
【
図6】本明細書に開示されるセグメント品質誘導型適応技術を利用する、使用可能な出力ビットレートの最適化による削減を示す。
【
図7】本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリーム生成のための方法を示す流れ図である。
【
図8】本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリーム生成のための方法を示す流れ図である。
【
図9】本明細書に開示の一実施形態による、セグメント品質誘導型適応ストリームを提供するように構成されたストリーミングシステムを示す。
【詳細な説明】
【0005】
本開示の諸実施形態は、セグメント品質誘導型適応(SQA)ストリーム生成のための技術を提供する。SQAシステムにより、リソース使用量を削減できる。削減されるリソース使用量には、必要なストレージ量の低減とSQAストリームを送信するために必要なネットワーク帯域幅の削減が含まれる。既存のABRアプリケーションでの重要な課題は、適切なABRエンコードラダーの選択である。エンコードスタックすなわちラダーは一連のバリアント/ビットレートのことを指示する。ここで、各ビットレートはラダーの段すなわちラングに対応し、最高のビットレートはラダーの最上部にあり、最低のビットレートは最下部にある。ただし、コンテンツが異なると、エンコードのニーズと複雑さが大幅に異なる可能性がある。
【0006】
ラング(例えば、解像度やビットレート)で定義された所与のエンコードラダー目標出力では、一部のコンテンツに必要なビットよりも多くのビットが容易に生成され得る。例えば、8.5メガビット/秒(Mb/s)のストリームは、実写ビデオには適しているが、単純なアニメーションには過剰である。より限定的なラダー(例えば、ビットレートが低い、解像度が低い、又はその両方)では、このような単純なアニメーションでは十分かもしれないが、一部のコンテンツ(例えば、実写)では十分な品質を実現するには不十分な場合がある。エンコードラダーを選択する際に、多くの場合、既存のシステムでは既存のラダーの中から選択する必要がある。そこには、十分な品質を生み出すが、無駄なビットも生成するものがあれば、より控えめにビットを生成するが、望ましい品質に及ばないものもある。これらの懸念を軽減するいくつかの試みには、タイトルベースのABRエンコードを含むものがある。ここでは、各タイトル(例えば、各ビデオソース)は場合によっては独自のエンコードスタックを持つことができる。
【0007】
しかし、各コンテンツアセット(タイトル)が他のコンテンツアセットと異なることが多いだけでなく、単一のアセット内でバリエーションが発生する場合がある。これにより、予め定義された単一のラダーを選択することの有効性が低下する。適応エンコードラダーがなければ、システムは再び、アセット内で必要なときに望ましい品質を生み出すには十分だが、不要なときに無駄な(不必要な)ビットを生成するラダー、又はアセットの多くには最適だが、一部には不十分な第2ラダーのどちらかを選択しなければならない。高いビデオ品質を確保するために、多くの既存のシステムはより高いビットレートのラダーを選択し、その結果、ビットが過剰に生成される。しかし、この選択により、プロバイダにとっての無駄なコスト(不要なデータの保存と配信を含む)が発生するだけでなく、追加の顧客コストも発生する(データ消費の増加が含まれるため、ユーザーが従量制データプランを使用している場合に特に有害である)。さらに、このアプローチは、より高頻度での再バッファリングや、より長時間のダウンロードを強制することなどにより、エクスペリエンスの質に影響を与える可能性がある。
【0008】
一部のABRフォーマットプロトコルではアセット内でのラダーの動的な変更が可能だが、多くの場合は可能になっていない。本開示の諸実施形態は、プロトコルフォーマットにとらわれない動的なタイトル内ラダーを提供するための技術を提供する。例えば、いくつかの実施形態では、クライアントデバイスに一連のビットレート選択肢(例えば、8.5Mb/sストリーム、7Mb/sストリーム、5.5Mb/sストリームなど)を提示できる。様々な実施形態では、クライアントデバイスが条件の変化に応じてストリームを自動的に選択してもよいし、ユーザーが特定のストリームを手動で選択してもよい。本開示の諸実施形態では、プロバイダシステムがより低いビットレートのストリームへ動的に切り替えることを、そうすることでユーザーエクスペリエンスに悪影響を及ぼさない場合(例えば、セグメント品質が損なわれない場合)に、可能にしている。これにより、ネットワーク負荷と必要なストレージ量が削減される。特に、いくつかの実施形態では、システムは、各解像度の範囲内で異なるビットレートのストリームを動的に選択する。すなわち、より低いビットレートのセグメントを選択する決定は、解像度ごとに実行され得る。そのような実施形態では、システムは、元のセグメント/ストリームと同じ解像度のより低いビットレートのセグメントから選択する(例えば、720pセグメントは1080pストリームには選択されない)。
【0009】
図1は、本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリームの作成を実行するように構成されたシステム100を示す。図示の実施形態では、メディアアセット105が提供され得る。アセット105は、任意のメディア(オーディオ、ビデオ、及びビデオとオーディオの両方を含むマルチメディアなど)を含み得る。図示の実施形態では、アセット105は、セグメント110A~Nのシーケンスへ線引きされている。この分割は、任意の数の技術を使用して実行され得る。一般的に、各セグメント110A~Nは、アセット105の一部又はセクションであり、セグメント110A~Nは、順序すなわちシーケンスに関連付けられている。このように、セグメント110A~Nを順に受信することにより、アセット105全体を受信できる。
【0010】
図示の実施形態には、最初のエンコードラダー115が示されている。エンコードラダー115は、4つのラング120A~Dを含み、各々がそれぞれの目標平均ビットレート(TAB)に関連付けられている。4つのラング120が示されているが、諸実施形態では、エンコードラダー115は、任意の数のラング/ビットレートを含み得る。図示の実施形態では、第1ラング120Aは8.5Mb/sのTABに相当し、ラング120Bは7Mb/sのTABに相当し、ラング120Cは5.5Mb/sのTABに相当し、ラング120Dは4.25Mb/sのTABに相当している。
【0011】
既存のシステムでは、エンコードラダー115を使用してアセット105の各セグメント110をエンコードする。すなわち、各セグメント110は、エンコードラダー115の各ラング120によって指定されたビットレートでエンコードされる。したがって、既存のシステムは、各TABに対して1つずつ、それぞれが対応するTABでエンコードされたセグメントのシーケンスを有している4つの別個の出力シーケンスを生成する。次に、クライアントは最大平均ビットレート(MAB)を示すことができる。これは、4つのストリームのうちの1つを選択するために使用される。例えば、クライアントが8.5Mb/sのMABを要求した場合、既存のシステムは8.5Mb/sでエンコードされたストリームを提供する(すなわち、ストリーム内のすべてのセグメント110は、8.5Mb/sでエンコードされる)。同様に、クライアントが7Mb/sのMABを要求した場合、既存のシステムは、7Mb/sでエンコードされたストリームを提供する。これにより、いくつかのセグメント110が不必要な/余分なビットで送信されることになる。
【0012】
図示の実施形態では、既存のエンコードラダー115には、ラング125A~Cを使用して示されている一連の中間平均ビットレート(IAB)が補われている。図示の実施形態では、新しいラング125A~Cはそれぞれ、既存の2つのラング120A~Dの間に挿入される。様々な実施形態では、IABラング125には任意の数の変種があり得る。例えば、既存のTABラングの間に2つ以上のIABラングがある場合もあれば、所与の2つのTABラングの間にIABラングが存在しない場合もある。さらに、諸実施形態では、システムは、最低ビットレートのTABを下回るゼロ以上のIABラングを利用してもよい。いくつかの実施形態では、IABを選択して既存のTAB間のギャップを均等に分割する。図示のように、既存のエンコードラダー115を追加のIABラング125と組み合わせることにより、拡張エンコードラダー130が得られ、この拡張エンコードラダーはラングを余分に有している。さらに、いくつかの実施形態では、MAB/TAB/IABは解像度ごとに定義される。すなわち、ビデオの使用可能な各解像度は、関連付けられた一連のMAB、TABセグメント、及びIABセグメントを有し得る。例えば、720p解像度に対する最高のTABを超えるIABが1つ以上あってもよい。これらの高いIABは既存の1080p解像度の組の一部だからである。
【0013】
図示のように、この拡張エンコードラダー130を使用してエンコードセグメント140A~Nのシーケンスを含む1つ以上の出力ストリーム135を生成し得る。本開示の諸実施形態では、システム100によって、各出力ストリーム135が、異なるビットレートでエンコードされたエンコードセグメント140A~Nを含むことが可能になっている。すなわち、既存のシステムでは所与のストリーム内の各セグメントは同じビットレートで強制的にエンコードされるのに対して、出力ストリーム135は変化し得る。例えば、エンコードセグメント140Aを8.5のTABを使用してエンコードしてもよく、他方で、エンコードセグメント140Bを6.25のIABを使用してエンコードし、エンコードセグメント140Cを7のTABを使用してエンコードしてもよい。したがって、既存のシステムではクライアントがラダーを上下に移動(例えば、現在又は次のセグメントに対してより高い又はより低いビットレートを選択)してもよいが、本開示の諸実施形態では、異なるビットレートを有し得るエンコードセグメント140から構成される出力ストリーム135が生成される。したがって、本開示の諸実施形態を使用することで、クライアントがより高いビットレートを要求し続けても、可能であればシステムはより低いビットレートを出力/送信できる。
【0014】
本開示の諸実施形態では、システムは品質に誘導されており、使用可能な帯域幅に基づいてビットレートを選択するだけではない。代わりに、システムは、各セグメントの品質レベルを維持しながら、ラダーの各ラングに最適な又は最良なビットレートを適応的に選択する。これにより、コンテンツを提供するために必要なビットの数を最小限に抑えながら、システムは目標ビットレートと同等の、又は合致するメディア品質を維持できる。
【0015】
いくつかの実施形態では、システム100によって提供される各MABに対して、別個の出力ストリーム135が生成される。いくつかの実施形態では、使用可能なMABは、エンコードラダー115で指定されたTABに対応している。所与のMABに対して出力ストリーム135を生成する際に、システム100は、以下でより詳細に説明するように、適切なエンコードセグメント140を動的に選択できる。一実施形態では、これには、より低いビットレートでもセグメントの品質が低下しない場合に、MABでエンコードされたセグメントと、より低いビットレートでエンコードされたセグメントとの間から動的に選択することが含まれる。
【0016】
一実施形態では、そうするために、システム100は、使用可能なビットレート(例えば、各TAB及び各IAB)のそれぞれを使用して、各セグメント110A~Nを繰り返しエンコードすることができる。いくつかの実施形態では、繰り返しエンコードすなわち連続エンコードではなく、各使用可能なビットレートを並列に使用して、システム100は各セグメント100A~Nをエンコードすることができる。続いて、エンコード済みセグメントを評価して組み合わせ、一連のMABストリームを生成し得る。いくつかの実施形態では、この評価は、すべてのセグメントが使用可能なビットレートでエンコードされた後に発生する後処理工程である。一度、MABストリームが生成されると、任意の数のクライアントへストリーミングすなわち送信され得る。有益なことに、より低いビットレートのセグメントを選択することが可能であれば(例えば、クライアントが受信するセグメントの品質が低下しない場合)、そうすることで、本開示の諸実施形態は、ストレージコストを削減する(各MABストリームは少ないリソースで保存され得るため)だけでなく、ネットワークコストも削減する(所与のMABに対して送信されるビット数が少ないため)。
【0017】
図2は、本明細書に開示される一実施形態による、セグメント品質誘導型適応ストリームの作成を行うために、様々なエンコード済み出力ストリームを生成するように構成されたシステム200を示す。図示の実施形態では、ソース205及びエンコードラダー210がトランスコーダ215に提供される。ソース205は一般にコンテンツアセット(ビデオアセット、オーディオアセット、マルチメディアアセットなど)である。上述のように、エンコードラダー210は、一般に、いくつかのビットレートを指定する。いくつかの実施形態では、エンコードラダー210は、ソース205のコンテンツ又はタイプに基づいて選択される。例えば、システム200は異なるラダーを利用してもよいが、その判断は、ソース205が二次元アニメーションコンテンツ、三次元コンピュータレンダリングコンテンツ、又は実写ビデオコンテンツを含むかどうかに基づく。複雑さを増す(したがって、高いビットレート、多数のラング、又は両方を有する、より堅牢なエンコードラダーが推奨される)その他の要因には、フレーム内の大きな動き、広範囲にわたる色の変化などがある。いくつかの実施形態では、1つ以上の既存の技術を使用してソース205を評価してソース205のタイプとコンテンツに適したエンコードラダー210を選択する。
【0018】
図示の実施形態では、トランスコーダ215は、いくつかのエンコーダ220A~Nを利用して、ソース205を一連のエンコード出力225A~Nにエンコードラダー210を使用してエンコードする。具体的には、エンコーダ220Aは、エンコード出力225Aを生成し、エンコーダ220Bは、エンコード出力225Bを生成し、以下同様である。一実施形態では、エンコードラダー210によって指定された各ラング/ビットレートに対して、対応するエンコーダ220を利用する。例えば、エンコードラダー210の最上位ビットレートが8.5Mb/sの場合、エンコーダ220Aを構成して、ソース205を8.5Mb/sでエンコードしてもよい。いくつかの実施形態では、エンコードラダー210には、従来からのTABの間に1つ以上のIABが既に増補されている。他の諸実施形態では、トランスコーダ215は、エンコードラダー210で指定されたTABに基づいて1つ以上のIABを選択し、TAB及びIABに対して対応するエンコーダ220を構成する。
【0019】
一実施形態では、所与のエンコーダ220を使用してソース205をエンコードする工程は、エンコーダ220のビットレートでソース205の各個々のセグメントをエンコードする工程を含むことで、セグメントを対応するビットレートで送信できるようになる(例えば、ネットワークを通じて)。したがって、エンコード出力225は、ソース205のエンコード済みセグメントのシーケンスを含み得る。いくつかの実施形態では、以下でより詳細に説明するように、システム200は、所与のMABに対する出力ストリームを構築するときに、エンコード出力225A~Nからエンコード済みセグメントを選択する。
【0020】
一実施形態では、エンコードラダー210で指定された各TABは、一般に、対応するMABと同等である。すなわち、従来のシステムでは、クライアントが所与のMABでストリームを要求すると、システムは、このビットレートに等しいエンコード済みビデオを選択して出力する。しかしながら、本開示の諸実施形態では、システム200は識別力を有して、より低いビットレート(例えば、1つ以上のIAB又はより低いTAB)を選択して出力することができ、これにより、計算負荷が軽減される。例えば、そのような実施形態は、要求よりも低いビットレートのセグメントを提供することによって、必要なストレージ量及び配信コストを削減することができる。
【0021】
図示の実施形態には含まれていないが、いくつかの実施形態では、システム200はさらに、各エンコード出力225に対して品質アセスメントを実行する。すなわち、システム200は、各エンコード済みセグメントの定量的かつ客観的な品質スコアを生成するために、各エンコード出力225の各個々のセグメントを評価してもよい。これにより、システム200は、あらゆる使用可能なビットレート及び解像度であらゆるセグメントの視覚的品質を知ることができる。様々な実施形態で、品質アセスメントに1つ以上の客観的品質アルゴリズムを利用できる。その例には、ピーク信号対雑音比(PSNR)、構造的類似性(SSIM)、ビデオマルチメソッドアセスメントフュージョン(VMAF)などがある。これにより、各セグメントの品質アセスメントが行われて、単一の値が示されてもよく(例えば、1つ以上の客観的スコアが重み付けされた集計値)、又は一連の値が示されてもよい(例えば、最低スコア、最高スコア、平均スコア、標準偏差、移動平均スコアなど)。
【0022】
図3は、本明細書に開示の一実施形態による、種々の最大ビットレートを有する様々な異なるストリームのセグメントプールを示すチャート300である。図示の実施形態では、使用可能なビットレートが視覚化されるように拡張エンコードラダー130が描写され、一連のプール315A~Cがいくつかの潜在的なMAB305A~Cに対して示されている。いくつかの実施形態では、各エンコード済みセグメントの品質アセスメントが完了した後に、各MABに対するエンコード済みTAB/IABセグメントのプールからセグメントが選択される。すなわち、出力の各セグメントに対して、システムは、各MABに対するエンコード済みIAB又はTABセグメントを選択できる。例えば、元の入力ソースの第1セグメントに対して、システムは、第1MAB305A(8.5Mb/s)に対する第1セグメントの第1エンコード済みバージョン、MAB305B(7Mb/s)に対する第1セグメントの第2エンコード済みバージョン、MAB305C(5.5Mb/s)に対する第1セグメントの第3エンコード済みバージョンなどを選択する。この処理が、入力ソースの各セグメント(及び使用可能な各MAB)に対して繰り返される。
【0023】
上述のように、従来のシステムでは、システムは、要求されたMABと同じビットレートに対応するTABセグメントを選択するだけである。したがって、MAB305Aの場合、既存のシステムは、8.5Mb/sのTABでエンコードされたセグメントを選択するだけである。しかしながら、図示の実施形態では、システムは、各MAB305A~Cに対する潜在的なセグメントのプールを定義する。MAB305に対する潜在的なエンコード済みセグメントのプールは、MAB305の対応するTAB、及び対応するTABの下に含まれる一連の1つ以上のTAB、IAB、又はIABとTABの両方を含む。図示のように、MAB305A(8.5Mb/sに対応する)に対して、プール315Aは8.5Mb/sのTABに対応するセグメントと、7.75Mb/sのIABに対応するセグメントと、7Mb/sのTABに対応するセグメントと、6.25Mb/sのIABに対応するセグメントと、5.5Mb/sのTABに対応するセグメントとを含む。
【0024】
したがって、MAB305Aに対するセグメント選択の間に、システムは、8.5Mb/sから5.5Mb/sの任意のセグメントを選択できる。様々な実施形態では、プール315は、静的でも動的でもよい。一実施形態では、プール315は静的構成(例えば、予め定義された一定の深さ)を利用する。別の一実施形態では、各プール315の深さ(例えば、含まれるラング又はビットレートの数)は、予め定められている。さらに別の一実施形態では、深さは、例えば、コンテンツ特性、機械学習などに基づいて動的に設定される。諸実施形態では、所与のプール315の最低深さ(ビットレート)は、所与のMAB315に対する最良条件(例えば、最低)の平均ビットレート出力を表す。例えば、図示の実施形態では、MAB305Bのプール315b(7Mb/sの最大ビットレート出力)は、最低端に4.8Mb/sのIABを有しており、7Mb/s出力の最終的な平均ビットレートは、4.8Mb/s以上、7Mb/s以下になることを示している。
【0025】
諸実施形態では、これらのプール315を、エンコーダ自体の内部に、又は1つ以上の下流コンポーネント内に定義又は構成してもよい。図示の拡張エンコードラダー130は7つのラングを利用するが、諸実施形態では、当然ながら、上述したように、任意の数の層/ビットレートがあってもよい。さらに、3つのMAB305A~Cが図示の実施形態に含まれているが、当然ながら、システムは任意の数及び変種のMABを提供し得る。さらに、図示の実施形態はそれぞれ深さ5、4、及び3のプール315A~Cを含むが、諸実施形態では、当然ながら、各プール315の深さは任意の値であってもよく、各プールは、任意の数の潜在的なビットレートを含み得る。さらに、図示のように、各プール315は、より低いIABだけでなく、より低いTABも含み得る。
【0026】
図4は、本明細書に開示される一実施形態による、セグメント品質誘導型適応ストリーミングを提供するためのセグメント品質分析を示すグラフ400を示す。いくつかの実施形態では、(上述のプール315からの)所与のMABに対するセグメント選択処理は、品質スコアの評価を含む。この品質スコアは、所与の(元の)セグメントの各エンコード済みバージョンに対して以前に生成されたものである。一実施形態では、所与のMABに対するエンコード済みセグメントを選択するために、対応するプール内の各セグメントの品質を評価する。システムは、最低ビットレートを有するエンコード済みセグメントを選択できる。ただし、そのセグメントの品質スコアは、MABの対応するTABセグメントの品質スコアから予め定義された許容範囲内にある。
【0027】
いくつかの実施形態では、この許容範囲を、最小可知差異(JND)よりも小さくなるように構成することで、一般的なユーザーが、TABセグメントと、選択されたより低いビットレートのセグメントとの間の視覚的品質の違いに気付くことは不可能になる。最終的な出力ビットレートを最小限に抑えながら、これにより、選択されたセグメントの品質が、MABの対応するTABセグメントを選択することで生成されていた品質よりも視覚的に劣らないことが保証される。例えば、8.5Mb/sのMABに対して、システムは、対応するTABセグメント(例えば、8.5Mb/sでエンコードされたセグメント)の品質スコアを判断できる。続いてこのTABセグメントの品質スコアを使用して、MABのプールに含まれるより低いビットレートのセグメントを選択できる。
【0028】
図示のグラフ400では、セグメントの品質スコアが縦軸に、出力の様々なセグメントが横軸にグラフで示されている。ポイント405、410、及び415は、様々なエンコード済みセグメントの品質スコアを表す。例えば、ポイント405A~Dは、Seg1の4つの異なるバリアント(例えば、異なるビットレート)の品質スコアを表す。同様に、ポイント410A~Dは、Seg2の4つの異なるバリアント(例えば、異なるビットレート)の品質スコアを表し、ポイント415A~Dは、SegNの4つの異なるバリアント(例えば、異なるビットレート)の品質スコアを表す。図示の実施形態では、描写されたMABに対するプールの深さは4である。すなわち、所与のMABで出力ストリームを生成する際に、4つのセグメントバリアントが選択可能である。したがって、ストリーム内の各セグメントに対して、システムは、4つの潜在的なエンコード済みセグメント(例えば、4つのビットレート)から選択できる。
【0029】
例えば、描写されたグラフ400が8.5Mb/sのMABに対するものであると仮定する。そのような実施形態では、各エンコード済みセグメントの最高品質のバリアント(最高のポイント405、410、及び415)は、おそらく8.5Mb/sのTABでエンコードされたセグメントである(例えば、ポイント405A、410A、及び415A)。この例を続けて、次に低いポイント(例えば、ポイント405B、410B、及び415B)は、次に低いビットレート(例えば、7.75Mb/sのIAB)に対応し、他方、7.75Mb/sのレートの先にある次に低いポイント(ポイント405C、410C、及び415C)は、7Mb/sのTABに対応する。さらに、プール内の最低品質のセグメント(ポイント405D、410D、及び415Dで示される)は、6.25Mb/sのIABでエンコードされたセグメントに対応する。
【0030】
図示のように、より低い各ビットレートの品質は、所与のセグメントの特定のコンテンツに依って大幅に異なる可能性がある。例えば、第1セグメント(Seg1)の場合、8.5Mb/s、7.75Mb/s、7Mb/sでエンコードされたセグメントの品質スコアは類似している。他方、6.25Mb/sでエンコードされたセグメントは大幅に低くなっている。第2セグメント(Seg2)の場合、4つのすべてのエンコード済みセグメントの品質スコアは類似している。さらに、第Nセグメント(SegN)の場合、8.5Mb/sのエンコード済みセグメントの品質は比較的高く、残りのセグメント(より低いビットレートでエンコードされたセグメント)はどれも視覚的品質が高くない。
【0031】
諸実施形態では、上述のように、システムは品質スコアを1つ以上の閾値と比較して、所与のセグメントに対してどのエンコード済みバリアントを選択すべきかを判断する。図示の実施形態では、これらの閾値は、許容範囲420A~Cによって示されている。少なくとも1つの実施形態では、許容範囲420A~Cは、標準的な人間のユーザーには気付かれない視覚的品質の差に相当する。上述のように、最小許容品質スコアは、最高品質のセグメント(例えば、MABに対応するTABでエンコードされたセグメント)の品質に基づいて定義される。したがって、許容範囲420A~Cは、各セグメントの最高スコアのエンコード済みバリアントの品質より下の許容変動幅を判断するものとして示されている。
【0032】
いくつかの実施形態では、追加的又は代替的に他の技術を利用して、許容変動幅を定義することができる。例えば、そのような一実施形態では、システムは、予め定義された下限をオプションとして利用して、この下限より下のセグメントは、許容範囲内であっても無視することができる。同様に、いくつかの実施形態では、システムは、予め定義された上限を利用して、品質スコアが予め定義された上限を超える場合に、予め定義された許容範囲を無視することができる。
【0033】
第1セグメント(Seg1)の場合、ポイント405Cによって表されるエンコード済みバリアントは許容範囲420Aの範囲内にあるが、他方、次に低いポイント405Dはその範囲内にない。したがって、図示の実施形態では、システムは、ポイント405Cで表されるエンコード済みセグメント(例えば、7Mb/sのTAB)を選択して、8.5Mb/sのMABストリームでの出力の第1セグメントとして使用する。第2セグメント(Seg2)の場合、許容範囲420Bの範囲内にある最低ビットレートのセグメントはプール内の最低のセグメントであり、ポイント410Dで表されている(例えば、6.25Mb/sセグメント)。したがって、第2セグメントでは、システムはこのエンコード済みバリアントを選択する。さらに、第Nセグメント(SegN)の場合、8.5Mb/sのTABセグメントのみが許容範囲420Cの範囲内にある。したがって、このセグメントに対しては、システムは最高ビットレートのバリアントを利用する。
【0034】
有益にも、これにより、ストリームの視覚的品質に影響を与えない場合に、システムは、より低いビットレートでエンコードされたセグメントを動的に選択できるようになる。これにより、ユーザーエクスペリエンスに影響を与えることなく、必要なネットワーク帯域幅を大幅に削減できる。さらに、いくつかの実施形態では、システムは、ストリーム用に選択されたエンコード済みセグメントのみを保存して、他のすべてを破棄できる。例えば、システムは、ポイント405C、410D、及び415Aによって表されるセグメントを保存して、残りのエンコード済みセグメントを破棄してもよい。これにより、MAB出力ストリームの保存に必要なストレージコストが大幅に削減される。同様の評価を、使用可能な各MABに対して実行できる。さらに、以下でより詳細に論じるように、いくつかの実施形態では、システムは、識別力を有して複数のMABストリームで使用されているセグメントを特定して、これらを単一の共有コピーへと統合し、ストレージコストをさらに削減することができる。
【0035】
図5Aは、本明細書に開示されるセグメント品質誘導型適応技術を使用して生成された一連の異なるビットレートのストリーム500Aを示す。図示の実施形態は、8.5Mb/sのMAB出力505Aと、7Mb/sのMAB出力505Bと、5.5Mb/sのMAB出力505Cとを含む。3つのMABが示されているが、諸実施形態では、当然ながら、任意の数の使用可能なMABがあってもよい。上述のように、諸実施形態では、各MABは通常、対応する出力が使用する最高のビットレートに相当する。クライアント又は提供システムは、通常、所与のクライアントに対してネットワーク条件、計算条件、その他の要因に基づいてMABを選択できる。各MAB出力505A~Cは、エンコードセグメント510のシーケンスを含む。
【0036】
上述のように、従来の(非SQA)トランスコードシステムでは、MAB出力には、MABのTABに対応するセグメントのみが含まれる。例えば、8.5Mb/sのMAB出力には、8.5Mb/sのTABエンコーダからのセグメントのみが含まれる。しかしながら、本開示の諸実施形態を利用することで、視覚的品質が低下しない場合には、各MAB出力に様々なセグメントのより低いビットレートを含めることができる。ただし、注目すべきは、各MAB出力505A~Cは、出力の対応するセクションに対する同じ元のセグメントのエンコード済みバリアントを出力することである。例えば、3つのMAB出力505A~Cのすべては、「Seg1」に相当するエンコード済みセグメント(セグメント510A、510G、及び510M)で始まり、「Seg7」へ順次進む。ただし、それぞれのエンコードされたビットレートは異なる。
【0037】
例えば、図示の実施形態では、MAB出力505Aは、5.5Mb/sでエンコードされたセグメント510Aと、8.5Mb/sでエンコードされたセグメント510Bと、8.5Mb/sでエンコードされたセグメント510Cと、6.25Mb/sでエンコードされたセグメント510Dと、6.25Mb/sでエンコードされたセグメント510Eと、8.5Mb/sでエンコードされたセグメント510Fとを含む。MAB出力505Bは、5.5Mb/sでエンコードされたセグメント510Gと、7Mb/sでエンコードされたセグメント510Hと、6.25Mb/sでエンコードされたセグメント510Iと、5.5Mb/sでエンコードされたセグメント510Jと、6.25Mb/sでエンコードされたセグメント510Kと、7Mb/sでエンコードされたセグメント510Lとを含む。さらに、MAB出力505Cは、5.5Mb/sでエンコードされたセグメント510Mと、4.8Mb/sでエンコードされたセグメント510Nと、5.5Mb/sでエンコードされたセグメント510Oと、5.5Mb/sでエンコードされたセグメント510Pと、4.8Mb/sでエンコードされたセグメント510Qと、5.5Mb/sでエンコードされたセグメント510Rとを含む。
【0038】
したがって、図示されるように、本明細書に開示される実施形態を利用することにより、各MAB出力505A~Cは、帯域幅を大幅に削減したセグメントを選択的に利用できる。一実施形態では、このストリーム生成は準備段階の間(例えば、アセットが取り込まれたとき)に実行され、MAB出力505A~Cは1つ以上のストレージ場所に保存される。これには、順次セグメント510A~R自体を保存する工程と、そのセグメントの順次リストを保存する工程(例えば、各セグメントの実際のストレージ場所へのポインタ又はリンクを使用する工程)などが含まれる。その後、クライアントが最大ビットレートのストリームを要求した時に、システムは、一致するMAB出力505を検索して、対応するセグメント510を順次送信し始めることができる。
【0039】
特に、上述のように、MAB出力505は、従来のシステムと比較して、必要なストレージリソースが少なくて済む。例えば、8.5Mb/sのMAB出力505Aでは、実際に8.5Mb/sのセグメントであるのは、セグメント510B、510C、及び510Fの3つのみである。残りのセグメントはより低いビットレートに対してエンコードされているため、ファイルサイズが小さくなり、保存、処理、送信に必要なリソースは少なくなる。いくつかの実施形態では、追加の最適化を適用して、計算リソースをさらに削減できる。
【0040】
図5Bは、本明細書に開示されるセグメント品質誘導型適応技術を使用して生成され、そのように最適化された一連の異なるビットレートのストリーム500Bを示す。上述のように、本明細書に開示されるSQAトランスコード技術を利用することで、各出力内のセグメントはMABのプールから選択されることになる。したがって、所与のMAB出力は、MABよりも低いビットレートに対してエンコードされたセグメントを含み得る。さらに、プールが重複する可能性があるため、同じエンコード済みセグメントが複数の出力内に存在する可能性がある。例えば、
図3に示すように、プール315Aと315Bが重複している(例えば、両方に7Mb/sのTABと6.25Mb/sのIABが含まれている)ので、8.5Mb/sのMAB出力と7Mb/sのMAB出力の両方が同じエンコード済みセグメント(例えば、7Mb/s又は6.25Mb/sでエンコードされたセグメント)を使用する可能性があることが示唆される。
【0041】
本開示のいくつかの実施形態では、エンコード処理は、各エンコード済みセグメント(TABセグメントとIABセグメントの両方を含む)に一意の識別子を添付する工程を含む。そのような一実施形態では、追加の下流処理により、バリアント全体で共通/共有のエンコード済みセグメントを特定でき、共有セグメントの共通の単一コピーを保存・配信する。これにより、同じエンコード済みセグメントを重複して保存する場合と比較して、効率とストレージリソースが改善される。すなわち、システムは、各エンコード済みセグメントのコピーを1つだけ保存すればよく、各MAB出力505は、必要に応じて、コピーへのポインタを含むことができる。
【0042】
さらに、これらの共通セグメントを最適化する工程は、コンテンツ配信ネットワーク(CDN)を介して重複するセグメントを配信することで必要になっていたネットワークリソースを削減できる。いくつかの実施形態では、多くのCDNは比較的ローカルな場所にセグメントをキャッシュする。例えば、受信されたセグメントは、企業内に、その場所に、インターネットサービスプロバイダ(ISP)によって、及びその他により、ローカルにキャッシュされ得る。これらのキャッシュにより、ネットワーク負荷を大幅に削減できる。複数のクライアントが同じMAB出力505をストリーミングしている場合、ローカルキャッシュを使用して、本来のストリームプロバイダに要求せずに次のセグメントを提供できる(使用可能な場合)。
【0043】
共通セグメントの識別子に注目することで、キャッシュは、任意のMAB出力用にもともとダウンロードされ、ローカルにキャッシュされたセグメントを提供できる。例えば、エンコード済みセグメントが第1ストリームの一部として、第1帯域幅で第1クライアントへダウンロードされたとする(例えば、8.5Mb/sのストリーム)。同じMABを使用する別のクライアントがストリームを開始した場合、キャッシュを使用して次のセグメントを提供してもよい。ただし、既存のシステムでは、別のMAB(例えば、7Mb/sのMAB)を使用するクライアントは、対応するバリアントをソースプロバイダからダウンロードする必要がある。ただし、重複するセグメント(例えば、8.5Mb/sと7Mb/sの両方のストリームが、その出力の1つ以上の部分に同じエンコード済みセグメントを使用する場合)に注目することにより、キャッシュは、キャッシュされた共通セグメントのコピーを、(7Mb/s出力をストリーミングしている)第2クライアントに提供できる。これにより、必要な帯域幅が大幅に削減される。
【0044】
図5Aに示すように、3つのMAB出力505A~Cはすべて、Seg1(セグメント510A、510G、及び510M)に5.5Mb/sのビットレートを使用している。したがって、
図5Bに示す実施形態では、システムはこれらの共通セグメントを単一の共有セグメント510Aへ統合して、(MAB出力505B及び505C内の)他のコピーを共有コピーへのポインタに置き換えている。MAB出力505Aと一緒に保存されているように示されているが、いくつかの実施形態では、システムが共有コピーを別の場所に保存し、このコピーへのポインタをすべてのMAB出力505A~Cに含めてもよい。
【0045】
同様の最適化が、このストリームの第4及び第5のセグメントに示されている。すなわち、MAB出力505Bと505CはどちらもSeg4で5.5Mb/sのエンコード済みセグメント510を使用しており、したがって、システムはセグメント510Pの1つのコピーを除去し、それを共有セグメント510Jへのポインタに置き換えている。さらに、MAB出力505Aと505BはSeg5の6.25Mb/sのエンコード済みセグメント510を共有するため、システムは同様に、一方又は両方をこのエンコード済みセグメントの共有コピーへのポインタに置き換えている。
【0046】
図6は、本明細書に開示されるセグメント品質誘導型適応技術を利用する、使用可能な出力ビットレートのさらなる最適化による削減を示すグラフ600を示す。上述のように、所与のMAB出力の平均ビットレートは、MABの最高ビットレート(MAB自体)とプールに含まれる最低ビットレートの間のいかなる値にもなり得る。したがって、(所与の画面解像度では)種々のMABにわたって、多くの場合、平均出力ビットレートは同程度のものになる。さらに、2つ以上のMABプールが同じ最低ビットレートを共有する場合、そのようなMAB出力の平均ビットレートを完全に同一にするか(各MABがプール内の最低ビットレートを使用している場合)、又は互いに非常に近い値にすることが可能である。これにより、さらなる最適化のための様々な機会が得られる。
【0047】
グラフ600は、SQA出力ビットレートの可能な分布の視覚的表現を示す。図示の実施形態では、様々なアセットが横軸に、アセットの各MABの平均ビットレートが縦軸にグラフで示されている。例えば、一番上のライン605A、610A、及び615Aは、使用可能な最高のMAB(例えば、8.5Mb/s)を表し、次のライン605B、610B、及び615Bは、次に低いMAB(例えば、7Mb/s)を表し、最低のライン605C、610C、及び615Cは、最低のMAB(例えば、5.5Mb/s)を表すこととする。3つのMABが示されているが、諸実施形態では、当然ながら、任意の数の使用可能なMABがあってもよい。
【0048】
図示のように、第1メディアソース(アセット1と明示)の場合、平均ビットレートは、選択したMABによって大きく異なる。すなわち、クライアントが選択するMABによっては、クライアントが受信する実際の平均ビットレートには相当なギャップがある。このことが、ライン605A~Cの間が比較的遠く離れていることによって視覚化されている。しかし、アセット3の場合、ライン615A~Cの間のギャップは著しく小さくなっている。これは、選択されたMABに関係なく、平均ビットレートがほとんど変化しないことを示している。最も極端な例では、これらのラインは単一のポイントに収束する(例えば、2つ以上のMAB出力がすべて同じセグメントビットレートを選択した場合)。
【0049】
多くの実施形態では、クライアントに提示されるABRラダーは、レートが近すぎず、遠すぎないラングを有するように設計されている。ラングが離れすぎている場合、システムは、高い方のビットレートに必要な帯域幅を提供するのに苦労するかもしれないが、次に低いビットレートでは低品質のビデオを配信することになるかもしれない。その間に補足的なラングがあれば、システムは釣合いのとれた状態を見つけることができる。ラングが近すぎる場合は、クライアントは、条件の変化に応じて頻繁にラダーを上り下りして隣のレートへ移動することがある。これにより、ローカルなキャッシュの実行によって得られる効率が大幅に低下する。ただし、
図6に示すように、本開示のいくつかの実施形態は、出力ビットレートの最適化を通じて、互いに非常に近いラングを有するラダーを生成することがあり得る。
【0050】
したがって、いくつかの実施形態では、システムはさらなる機能を実行し得る。少なくとも1つの実施形態では、ABRバリアントのマスターリストは、これらのバリアントのそれぞれの実際の平均ビットレートが、宣伝されているレートよりもはるかに低い場合があったとしても、それでもすべてのMABを含み得る。これは、アセットのピークビットレートが平均レートとは大きく異なっている場合に有益である。すなわち、一部のセグメントは元のMABピークレートでエンコードされて、たとえほとんどのセグメントがはるかに低くエンコードされていても、所与のMAB出力に依然として存在することが可能である。すべてのMAB出力を保持することで、コンテンツプロバイダは、出力ストリームにいかなるピークも含有させて、各出力ストリームが高品質のままであることを保証できる。
【0051】
いくつかの実施形態では、結果として得られるMAB出力平均ビットレート、セグメントピークレートなどの分析を実行することができる。この分析に基づいて、システムは、1つ以上のMAB出力バリアントの削除を決定し得る。例えば、すべてのMAB出力が、まったく同じ一連のエンコード済みセグメントを使用するところまで最適化されているとする。そのような場合、すべてのMAB出力は全く同じになる(同じ平均ビットレート及びピークビットレートを有している)。したがって、そのような実装では、すべてのMAB出力を保持したり、クライアントに提示したりする利点はない。
【0052】
したがって、いくつかの実施形態では、システムは、削除すべきMAB出力を評価及び特定できる。図示の実施形態では、アセット1に対して、システムは、平均ビットレートが十分に分散しているので、すべてのMAB選択肢を保持すべきだと判断した。しかし、アセット2の場合、ライン610Bによって表されるバリアントは、ライン610A又は610C(又は両方)によって表されるバリアントから予め定義された閾値距離内にあると、システムは判断している。したがって、破線で示すように、システムは、ライン610Bで示されるバリアントを削除することを決定した。そのような実施形態では、アセット2をストリーミングするとき、クライアントには2つのバリアントが提示され得る。すなわち、ライン610Aによって表されるバリアント(例えば、8.5Mb/s)、又はライン610Cによって表されるバリアント(例えば、5.5Mb/s)である。宣伝されている中間のバリアント(例えば、7Mb/s)の削除に加えて、いくつかの実施形態では、システムは、ストレージの使用量を削減するために、このMAB出力をストレージからさらに消去できる。
【0053】
同様に、アセット3の場合、システムは、最高のバリアント(破線のライン615Aで表される)と最低のバリアント(破線のライン615Cで表される)の両方を間引くことを決定した。その決定は、それらがライン615Bによって表されるバリアントからの予め定義された閾値差内にあるとの判断に基づく。したがって、一実施形態では、システムはこれらのバリアントの除去を決定できる(例えば、これらの宣伝を控える、これらを削除するなどによる)。これにより、ストレージの効率を大幅に向上させ、システムの全体的な動作をさらに改善させ得る。
【0054】
いくつかの実施形態では、MABストリームを除去する工程は、クライアントへのMABの宣伝を控える工程と、クライアントに残りのMABから選択させる工程とを含む。しかしながら、少なくとも1つの実施形態では、ストリーミングシステムは、従来のMABのすべてを引き続き宣伝し得る。間引きされたMABストリームの要求を受信すると、システムは、類似と見なされるMABストリームを代わりに提供してもよい。これにより、システムは、変更やクライアントデバイスへの通知を行うことなく、リソースの最適化を実施できるようになる。
【0055】
図7は、本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリーム生成のための方法700を示す流れ図である。方法700は、ブロック705から始まる。ここでは、ストリーミングシステムがソースアセットを受信する。諸実施形態では、上述のように、このアセットは、オーディオと、ビデオと、ビデオ及びオーディオなどを備えたマルチメディアストリームとを含み得る。一実施形態では、このソースアセットは、任意のビットレートでエンコード/圧縮され得る非圧縮アセットを含むことができる。次に、方法700はブロック710へ続く。
【0056】
ブロック710で、ストリーミングシステムは、ソースアセットのエンコードに使用するエンコードラダーを受信する。いくつかの実施形態では、上述のように、これは予め定義されたラダーである。少なくとも1つの実施形態では、ラダーは、アセットのタイプ又はコンテンツに基づいて選択された、タイプ又はコンテンツに固有のラダーである。いくつかの実施形態では、ラダーには既にIABが組み込まれている。別の一実施形態では、ストリーミングシステムは、ラダーで指定されたTABに基づいて、最初に1つ以上のIABを選択できる。
【0057】
次に、方法700はブロック715へ続く。ここでは、ストリーミングシステムはビデオのセグメントを選択する。いくつかの実施形態では、アセットは前もってセグメントへ線引きされている。別の一実施形態では、ストリーミングシステムは、1つ以上の既知の技術を使用して、アセットを評価してセグメントを定義する。セグメントが選択された後、方法700はブロック720へ進む。ここでは、ストリーミングシステムは、(拡張)エンコードラダーで指定されたエンコードラングの1つを選択する。ブロック725で、ストリーミングシステムは、選択されたセグメントを選択されたビットレートでエンコードする。
【0058】
ブロック730で、続いてストリーミングシステムは、1つ以上の品質アセスメント技術を使用してセグメントを評価し、エンコード済みセグメント(すなわち、選択されたビットレートでエンコードされた、選択されたセグメント)の品質スコアを生成する。次に、方法700はブロック735へ進む。ここでは、ストリーミングシステムは、エンコードラダーで少なくとも1つの追加のラング(ビットレート)が指定されているかどうかを判断する。指定されている場合、方法700はブロック720へ戻って次のラングを選択する。そうでなければ、選択されたセグメントがすべての可能なビットレートでエンコードされている場合、方法700はブロック740へ続く。
【0059】
ブロック740で、ストリーミングシステムは、アセット内にまだエンコードされていない追加のセグメントが少なくとも1つあるかどうかを判断する。ある場合には、方法700はブロック715へ戻って次のセグメントを選択する。そうでなければ、方法700はブロック745へ進む。このように、ストリーミングシステムは、各可能なビットレートで各セグメントのエンコード済みバリアントを生成することができる。これらのエンコード済みセグメントは、一連のMAB出力を生成するために、評価及び分析へ向けて保存される。様々な実施形態では、このストレージには、1つ以上のハードドライブ又はソリッドステートドライブ上、メモリ(例えば、ランダムアクセスメモリ)内などに、任意の数の適切な代替手段を含み得る。
【0060】
ブロック745で、ストリーミングシステムは、使用可能な/潜在的なMAB出力の1つを選択する。上述のように、諸実施形態では、各MABは最大平均ビットレート選択肢を表す。クライアントはMABを選択でき、ストリーミングシステムは、選択されたMABからのセグメントをクライアントへ順次送信する。次に、方法700はブロック750へ続く。ここでは、ストリーミングシステムはベースセグメントの1つを選択する。一実施形態では、ベースセグメントは、選択されたMABのTABでエンコードされたセグメントのことを指示する。例えば、8.5Mb/sのMABの場合、各ベースセグメントは、ソースアセット内のセグメントの1つであり、8.5Mb/sでエンコードされている。別の一実施形態では、ベースセグメントは、ソースアセット内の元の(エンコードされていない)セグメントのことを指示する。
【0061】
次に、方法700はブロック755へ進む。ここでは、ストリーミングシステムは、ベースセグメントに対する潜在的なセグメントのプールを特定する。一実施形態では、これには、上述のように、プールの深さを決定する工程が含まれる。このプールの深さは静的又は動的であってもよく、手動により及び機械学習に基づくなどにより、選択されてもよい。一実施形態では、ベースセグメントがMABに対するTABセグメントである場合、プールを特定する工程は、この選択されたセグメントの潜在的な代替セグメント(例えば、より低いビットレートでエンコードされた同じセグメントのバリアント)を特定する工程を含む。ベースセグメントが元のソース内のセグメントのことを指示する諸実施形態では、プールを特定する工程は、全てのエンコード済みセグメントを(選択されたMABに対するプールの深さ内で)特定する工程を含む。ただし、この全てのエンコード済みセグメントは、選択されたベースセグメントに相当するものである。
【0062】
ブロック760で、ストリーミングシステムはプール内の最小ビットレートセグメントを選択して特定する。一実施形態では、上述のように、この選択は各セグメントの品質スコアに基づいている。例えば、ストリーミングシステムは、最低のビットレートを有する、プール内の潜在的なセグメントを、品質スコアが予め定義された基準(例えば、最高品質のセグメントの許容範囲又は閾値)内である限り、選択してもよい。品質スコアが低すぎる場合、ストリーミングシステムは次に高いビットレートセグメントを選択してもよい。ベースセグメントに対して最小ビットレート許容セグメントを特定したならば、方法700はブロック765へと続く。ここでは、ストリーミングシステムは、選択されたMABに対して、評価される追加のベースセグメントが少なくとも1つあるかどうかを判断する。
【0063】
もし、ある場合には、方法700はブロック750へ戻る。そうでなければ、方法700はブロック770へと続く。こうして、ストリーミングシステムは、ソースアセット内の各セグメントを繰り返し処理し、それぞれのソースセグメントごとに、選択されたMABに対して十分な品質を有する、最低ビットレートでのエンコード済みセグメントを特定することができる。ブロック770で、ストリーミングシステムは、選択されたエンコード済みセグメントのシーケンスを、生成されたMAB出力として保存する。このように、ストリーミングシステムは、選択されたMABに対して、最適化された出力を生成できる。この最適化された出力は、品質を低下させることなく、一部のセグメントのビットレートを低下させている。これにより、計算の使用量が改善される。
【0064】
次に、方法700はブロック775へ進む。ここでは、ストリーミングシステムは、評価/生成されていない追加のMABが少なくとも1つあるかどうかを判断する。もし、ある場合には、方法700はブロック745へ戻る。そうでなければ、すべてのMAB出力が作成されている場合は、方法700はブロック780へと続く。このように、ストリーミングシステムは、使用可能なすべてのMABに対して、最適化されたMAB出力を繰り返し又は並行して生成できる。ブロック780で、ストリーミングシステムは、オプションとして続けて、上述のように、セグメントの保存、出力、又は保存と出力の両方を最適化し得る。
【0065】
例えば、そのような一実施形態では、ストリーミングシステムは、異なるMAB出力にわたって共通のエンコード済みセグメントを特定し、
図5に関して上述したように、これらの共通セグメントを共有コピーへ統合することができる。その後、各MAB出力を修正して、この単一の共有コピーへのリンクすなわちポインタを含めることができる。いくつかの実施形態では、ストリーミングシステムは、各MAB出力全体間の類似性を分析して、
図6を参照して上述したように、十分に類似する出力を特定することができる。十分に類似しているMAB出力をシステムから除去できる。
【0066】
方法700は、概念を明確にするために順次すなわち連続の処理として示されているが、いくつかの実施形態では、方法700の態様を、事実上同時に(例えば、並行して)実行してもよい。例えば、いくつかの実施形態では、システムは、所与のビットレートでセグメントをエンコードし、そのビットレートでのセグメントの品質を判断し、次に、各ビットレート及びセグメントに対してこれらの手順を繰り返すことができる。しかしながら、いくつかの実施形態では、システムは複数のビットレートで並行してセグメントをエンコードできる。これにより、処理の待ち時間を削減できる。
【0067】
図8は、本明細書に開示されるいくつかの実施形態による、セグメント品質誘導型適応ストリーム生成のための方法を示す流れ図である。方法800は、ブロック805から始まる。ここでは、ストリーミングシステムは、複数のセグメントを含むビデオを受信する。ブロック810で、ストリーミングシステムは、複数の最大平均ビットレート(MAB)を指定するエンコードラダーを受信する。さらに、ブロック815で、ストリーミングシステムは、複数のMABの間に散在する複数の中間ビットレートを選択する。次に、方法800はブロック820へ続く。ここでは、ストリーミングシステムは、複数のMABの第1MABを使用して複数のセグメントの第1セグメントをエンコードすることによって、第1目標平均ビットレート(TAB)セグメントを生成する。ブロック825で、ストリーミングシステムは、複数の中間ビットレートの第1中間ビットレートを使用して第1セグメントをエンコードすることによって、第1中間平均ビットレート(IAB)セグメントを生成する。さらに、ブロック830で、ストリーミングシステムは、第1TABセグメント及び第1IABセグメントに対するそれぞれの品質スコアを生成する。次に、方法800はブロック835へ進む。ここでは、ストリーミングシステムは、それぞれの品質スコアに基づいて、第1MABでの第1セグメントに対する第1出力セグメントを選択する。ここで、第1出力セグメントは、(i)第1TABセグメント又は(ii)第1IABセグメントのいずれかである。ブロック840で、第1MABでの第1セグメントの要求を受信すると、ストリーミングシステムは第1出力セグメントを出力する。
【0068】
図9は、本明細書に開示の一実施形態による、セグメント品質誘導型適応ストリームを提供するように構成されたストリーミングシステム905を示す。物理デバイスとして示されているが、諸実施形態では、ストリーミングシステム905は、仮想デバイス若しくはサービスとして、又はいくつかのデバイスにわたって(例えば、クラウド環境で)実装されてもよい。図示のように、ストリーミングシステム905は、プロセッサ910と、メモリ915と、ストレージ920と、ネットワークインターフェース925と、1つ以上のI/Oインターフェース930とを含む。図示の実施形態では、プロセッサ910は、メモリ915に保存されたプログラミング命令を検索して実行すると共に、ストレージ920に存在するアプリケーションデータを保存及び検索する。プロセッサ910は一般に、単一のCPU、GPU、CPU及びGPU、複数のCPU、複数のGPU、複数の処理コアを有する単一のCPU又はGPUなどを代表する。メモリ915は一般に、ランダムアクセスメモリの代表格として含まれている。ストレージ920は、ディスクドライブ、フラッシュベースのストレージデバイスなどの任意の組み合わせであってもよく、固定ストレージデバイス、リムーバブルストレージデバイス、又は両方の組み合わせを含んでも良い。その例には、固定ディスクドライブ、リムーバブルメモリカード、キャッシュ、光ストレージ、ネットワーク接続ストレージ(NAS)、又はストレージエリアネットワーク(SAN)がある。
【0069】
いくつかの実施形態では、入出力デバイス(マウス、キーボード、モニタ、タッチスクリーンなど)は、I/Oインターフェース930を介して接続される。さらに、ネットワークインターフェース925を介して、ストリーミングシステム905は、1つ以上の他のデバイス及びコンポーネントと通信可能に(例えば、直接的に、又はネットワーク980(インターネット、ローカルネットワークなどが含まれ得る)を介して)結合され得る。さらに、ネットワーク980は、有線接続、無線接続、又は有線接続と無線接続の組み合わせを含んでもよい。図示のように、プロセッサ910、メモリ915、ストレージ920、ネットワークインターフェース925、及びI/Oインターフェース930は、1つ以上のバス975によって通信可能に結合されている。諸実施形態では、ストリーミングシステム905を、独立型デバイスとして、クラウド展開の一部として、ユーザーの電話又はコンピュータで実行されるアプリケーションなどとして、実装してもよい。
【0070】
図示の実施形態では、ストレージ920は、1つ以上のソースアセット960と、1つ以上の対応するエンコードストリーム965とを含む。ストレージ920に常駐しているように描かれているが、ソースアセット960及びエンコードストリーム965は、任意の適切な場所に保存されてもよい。一実施形態では、ソースアセット960は、上述のように、エンコード及びストリーミングされ得るビデオ、オーディオ、又はマルチメディアコンテンツである。エンコードストリーム965は、通常、ソースアセット960のエンコード済みバージョンである。いくつかの実施形態では、上述のように、各エンコードストリーム965は、対応するMABに関連付けられる。さらに、いくつかの実施形態では、単一のソースアセット960は、任意の数の(例えば、種々のMABでの)対応するエンコードストリーム965と関連付けられ得る。上述のように、一実施形態では、各エンコードストリーム965は、エンコードストリーム965のMAB以下でエンコードされたセグメントのシーケンスを含むように生成される。いくつかの実施形態では、エンコードストリーム965は、上述のように、共有/重複する共通セグメントへのポインタを利用してもよい。
【0071】
図示の実施形態では、メモリ915は、ストリームアプリケーション935を含む。ストリームアプリケーション935は一般に、本明細書で論じられる1つ以上の実施形態を実行するように構成される。メモリ915に常駐するソフトウェアとして示されているが、諸実施形態では、ストリームアプリケーション935の機能は、ソフトウェア、ハードウェア、又はソフトウェアとハードウェアの組み合わせを使用して実装され得る。図示のように、ストリームアプリケーション935は、エンコードコンポーネント940と、品質コンポーネント945と、選択コンポーネント950と、オプティマイザ955とを含む。概念を明確にするために別個のコンポーネントとして示されているが、諸実施形態では、エンコードコンポーネント940、品質コンポーネント945、選択コンポーネント950、及びオプティマイザ955の動作は、任意の数のコンポーネント及びデバイスにわたって組み合わされたり、分布していてもよい。
【0072】
一実施形態では、エンコードコンポーネント940を構成して、ソースアセット960を受信し、各セグメントを1つ以上のビットレートでエンコードしてソースアセット960に対する一連のエンコード済みセグメントを生成する。上述のように、いくつかの実施形態では、エンコードコンポーネント940は、使用可能な各ビットレートで(例えば、各TAB及びIABで)各ソースセグメントの別個のエンコード済みバリアントを生成する。次に、これらのバリアントを分析して、最適化されたエンコードストリーム965を構築することができる。
【0073】
品質コンポーネント945は一般に、エンコードコンポーネント940によって生成された各エンコード済みセグメントの視覚的品質を評価するように構成される。そうするために、品質コンポーネント945は、任意の数及び組み合わせの視覚的品質アルゴリズムを使用してもよい。一実施形態では、品質コンポーネント945は、この分析に基づいて、各エンコード済みセグメントの品質スコアを生成する。この品質スコアは、単一の値でも、複合的な一連の値でもよい。
【0074】
図示の実施形態では、選択コンポーネント950を構成して、各エンコードストリーム965の各セグメントに対して、最良エンコード済みセグメントを選択する。諸実施形態では、選択コンポーネント950は、生成された品質スコアに部分的に基づいて、そのように実行する。いくつかの実施形態では、上述のように、選択コンポーネント950は、ソースアセット960内の各セグメントに対して、(エンコードストリーム965のMABでの)潜在的なエンコード済みセグメントのプールを特定することによって、そのように実行する。次に、選択コンポーネント950は、このセグメントが十分な品質スコアに関連付けられている限り、最低ビットレートを有するエンコード済みセグメントを選択できる。この処理を、エンコードストリーム965全体が生成されるまで繰り返すことができる。次に、選択コンポーネント950は、ソースアセット960に使用可能な各MABに対して、この処理を反復的に繰り返すことができる。
【0075】
いくつかの実施形態では、オプティマイザ955は一般に、上述のように、エンコードストリーム965間の重複を減らすなどの他の最適化を実行するように構成される。そうするために、オプティマイザ955は、異なるエンコードストリーム965内の共有されたエンコード済みセグメントを特定し、それらの1つ以上を、エンコード済みセグメントの単一の共有コピーへのポインタで置き換えることができる。いくつかの実施形態では、オプティマイザ955はまた、所与のソースアセット960に使用可能なエンコードストリーム965を評価して、十分に類似している(例えば、予め定義された閾値を超える)エンコードストリーム965を特定することができる。類似するストリームを、単一のエンコードストリーム965にまとめてもよい(例えば、1つ以上の類似するエンコードストリーム965を削除することによる)。そうすることで、オプティマイザ955は、ストリーミングシステム905に必要なストレージ及び送信の量を低減することができる。
【0076】
オプティマイザ955はストリームアプリケーション935内のコンポーネントとして示されているが、いくつかの実施形態では、システム内の独立型コンポーネントであってもよく、又はシステム内に分散された一連の1つ以上の機能として動作してもよい。例えば、そのような一実施形態では、ストリームアプリケーション935がTAB及びIABのセグメントを生成して(例えば、ストレージ920又はメモリ915に)保存した後、別個のオプティマイザ955(又は一連のオプティマイザ955)が、これらの保存されたセグメント(例えば、メモリ915内のデータ又はストレージ920内のファイル)にアクセスして評価し、上述のように、重複と共有使用に基づいてそれらを最適化してもよい。
【0077】
図示の実施形態では、ストリーミングシステム905は、ネットワーク980を介してクライアントシステム985と通信することができる。単一のクライアントシステム985が示されているが、当然ながら、任意の数のクライアントシステム985があってもよい。クライアントシステム985は、一般に、ストリーミングシステム905からデータ(例えば、エンコードストリーム965)を受信するように構成された任意の計算デバイスを表す。その例には、スマートフォン、ラップトップコンピュータ、デスクトップコンピュータ、インターネットに接続されたゲームシステム、タブレット、テレビなどが含まれるが、これらに限定されない。クライアントシステム985は、ストリーミングクライアント990を含むものとして示されている。図示の実施形態には含まれていないが、クライアントシステム985は、一般に、プロセッサ、ストレージ、メモリ、インターフェースなど、任意の数及び変種の計算要素を含み得る。
【0078】
様々な実施形態では、ストリーミングクライアント990を、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせを使用して実装してもよい。一実施形態では、ストリーミングクライアント990を使用してストリーミングシステム905によって提供される1つ以上のアセットを選択できる。例えば、ユーザーはストリーミングクライアント990を使用してストリーミングしたい映画や番組を選択してもよい。いくつかの実施形態では、続いてストリームアプリケーション935がアセットに使用可能なMABの組又はリストを提供し、ストリーミングクライアント990がそれらの中から選択し得る。一実施形態では、ストリーミングクライアント990が自動的に(例えば、使用可能な帯域幅、ローカル計算リソースなどに基づいて)MABを選択する。そのような一実施形態では、ストリーミングクライアント990は、選択されたMABを、変化する条件に基づいて(例えば、使用可能な帯域幅が減少したときに、より低いMABを要求するため)、ストリームの間に自動的かつ動的に変更できる。少なくとも1つの実施形態では、ユーザーは手動でMAB又は品質を選択し、ストリームをこの品質に固定できる。
【0079】
上述のように、いくつかの実施形態では、ストリームアプリケーション935は出力セグメントを動的に選択するので、この出力セグメントは、ストリーミングクライアント990が要求したビットレートと一致する場合と一致しない場合がある。例えば、ストリーミングクライアント990が8.5Mb/sのストリームを要求した場合でも、ストリームアプリケーション935はセグメントを動的により低いビットレートで、それでも品質が予め設定した閾値を超えて低下しない場合には、提供し得る。この変更がフォーマット/プロトコルに依存しないことも可能であり、ストリーミングクライアント990が、利用されているビットレートの変化に全く気付かない場合もある。有益にも、それゆえに、本明細書に開示された諸実施形態を適用するために、ストリーミングクライアント990を再プログラムする必要も、再構成する必要もない。
【0080】
本開示では、様々な実施形態が参照されている。ただし、本開示は、記載された特定の実施形態に限定されないことを理解するべきである。その代わりに、種々の諸実施形態に関連するかどうかにかかわらず、以下の構成及び要素のいかなる組み合わせも、本明細書で提供される教示を実行及び実践するために企図されたものである。さらに、実施形態の要素が「A及びBのうちの少なくとも1つ」の形で記載されている場合、要素Aのみを含む、要素Bのみを含む、要素A及びBを含む実施形態がそれぞれ企図されると、理解できる。さらに、いくつかの実施形態は、他の可能な解決策又は先行技術を超える効果を達成し得るが、所与の実施形態によって特定の効果が達成されるかどうかは、本開示を限定するものではない。したがって、本明細書に開示された態様、構成、実施形態、及び効果は、単なる例示であり、特許請求の範囲に明示的に記載されている場合を除き、添付の特許請求の範囲の要素又は制限とは見なされない。同様に、「本発明」という言及は、本明細書に開示される発明の内容の一般化として解釈されるものではなく、又、請求項に明確に記載される場合を除き、添付の特許請求の範囲の要素又は限定と見なされるものではない。
【0081】
当業者には理解されるように、本明細書に記載の実施形態は、システム、方法、又はコンピュータプログラム製品として具現化され得る。したがって、実施形態は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)、又はソフトウェア及びハードウェアの態様を組み合わせた実施形態の形態を取ることができ、本明細書ではそれらすべてを「回路」、「モジュール」、又は「システム」と総称する。さらに、本明細書に記載の実施形態は、コンピュータ可読プログラムコードが具現化された1つ以上のコンピュータ可読媒体内で表現されたコンピュータプログラム製品の形態を取り得る。
【0082】
コンピュータ可読媒体上で具現化されたプログラムコードは、任意の適切な媒体を使用して送信されてもよい。その中には、無線、有線、光ファイバーケーブル、RFなど、又はこれらの任意の適切な組み合わせを含むが、これらに限定されない。
【0083】
本開示の実施形態の動作を実行するためのコンピュータプログラムコードは、1つ以上のプログラミング言語の任意の組み合わせで書かれてもよい。そのプログラミング言語は、Java、Smalltalk、C++などのオブジェクト指向プログラミング言語、「C」プログラミング言語又は同様のプログラミング言語などの従来の手続き型プログラミング言語を含む。プログラムコードを、完全にユーザーのコンピュータ上で、又は部分的にユーザーのコンピュータ上で、スタンドアロンのソフトウェアパッケージとして実行してもよく、一部はユーザーのコンピュータ上かつ一部はリモートコンピュータ上で、又は完全にリモートコンピュータ又はサーバー上で実行してもよい。後者のシナリオでは、リモートコンピュータを、ローカルエリアネットワーク(LAN)又はワイドエリアネットワーク(WAN)を含む任意の種類のネットワークを介してユーザーのコンピュータに接続してもよい。又は、外部コンピュータに(例えば、インターネットサービスプロバイダを使用してインターネットを介して)接続してもよい。
【0084】
本開示の態様は、本開示の実施形態による方法、装置(システム)、及びコンピュータプログラム製品のフローチャート図又はブロック図を参照して本明細書に記載されている。フローチャート図又はブロック図の各ブロック、及びフローチャート図又はブロック図内のブロックの組み合わせは、コンピュータプログラム命令によって実行されることが理解できる。これらのコンピュータプログラム命令は、汎用コンピュータ、特殊用途コンピュータ、又はマシンを形成する他のプログラム可能データ処理装置のプロセッサに提供可能であり、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサを介して実行される命令は、フローチャート図又はブロック図のブロックで指定される機能/動作を実施するための手段を生成する。
【0085】
これらのコンピュータプログラム命令はまた、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイスに、特定の方法で機能するよう指示できるコンピュータ可読媒体に格納可能であり、これにより、コンピュータ可読媒体に格納された命令が、フローチャート図又はブロック図のブロックで指定された機能/動作を実施する命令を含む製品を形成する。
【0086】
また、コンピュータプログラム命令を、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイスにロードし、コンピュータ、他のプログラム可能な装置、又は他のデバイス上で一連の動作ステップを実行させて、コンピュータ実行プロセスを生成してもよく、それにより、コンピュータ、他のプログラム可能なデータ処理装置、又は他のデバイス上で実行される命令が、フローチャート図又はブロック図のブロックで指定された機能/動作を実行するためのプロセスを提供する。
【0087】
図中のフローチャート図とブロック図は、本開示の様々な実施形態によるシステム、方法、及びコンピュータプログラム製品の可能な実施態様のアーキテクチャ、機能、及び動作を説明している。この点で、フローチャート図又はブロック図の各ブロックは、モジュール、セグメント、又はコードの一部を表し、これらが、指定された論理関数を実行するための1つ以上の実行可能命令を含んでもよい。また、いくつかの代替実施態様では、ブロックに記載されている機能が、図に記載されている順序とは異なる順序で生じる場合があることにも留意するべきである。例えば、連続して示されている2つのブロックは、実際には、実質的に同時に実行されてもよく、関連する機能に応じて、逆の順序で実行されても、順不同で実行されてもよい。また、ブロック図又はフローチャート図の各ブロック、及びブロック図又はフローチャート図のブロックの組み合わせを、特定の機能又は動作を実行する特殊用途ハードウェアベースのシステム、又は特殊用途ハードウェアとコンピュータ命令の組み合わせによって実行し得ることにも注意が必要である。
【0088】
上記は本開示の実施形態を対象としているが、本開示の他のさらなる実施形態を、その基本的な範囲から逸脱することなく創作することができ、その範囲は以下の特許請求の範囲によって決定される。
【外国語明細書】