特開2022-91710ビデオストリーミングにおける複数のプロトコル予測およびセッション内適応
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022091710
(43)【公開日】2022-06-21
(54)【発明の名称】ビデオストリーミングにおける複数のプロトコル予測およびセッション内適応
(51)【国際特許分類】
H04N 21/643 20110101AFI20220614BHJP
H04N 21/462 20110101ALI20220614BHJP
H04N 21/238 20110101ALI20220614BHJP
H04L 67/02 20220101ALI20220614BHJP
H04L 65/1108 20220101ALI20220614BHJP
【ＦＩ】
H04N21/643
H04N21/462
H04N21/238
H04L67/02
H04L65/1108
【審査請求】有
【請求項の数】20
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2021196166
(22)【出願日】2021-12-02
(31)【優先権主張番号】17/116,711
(32)【優先日】2020-12-09
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】512333560
【氏名又は名称】フル・エルエルシー
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100179062
【弁理士】
【氏名又は名称】井上 正
(74)【代理人】
【識別番号】100199565
【弁理士】
【氏名又は名称】飯野 茂
(74)【代理人】
【識別番号】100219542
【弁理士】
【氏名又は名称】大宅 郁治
(74)【代理人】
【識別番号】100153051
【弁理士】
【氏名又は名称】河野 直樹
(74)【代理人】
【識別番号】100162570
【弁理士】
【氏名又は名称】金子 早苗
(72)【発明者】
【氏名】トンギュ・ダイ
(72)【発明者】
【氏名】ラン・シエ
(72)【発明者】
【氏名】ウェンハオ・ジャン
(72)【発明者】
【氏名】ダーリャン・フー
(72)【発明者】
【氏名】チャオ・リー
(72)【発明者】
【氏名】チャン・ショー
(72)【発明者】
【氏名】イーティン・グイ
(72)【発明者】
【氏名】イーチョン・リュー
(72)【発明者】
【氏名】イエンピン・ジョウ
(72)【発明者】
【氏名】シージー・シー
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA06
5C164GA03
5C164MB44S
5C164SB21P
5C164SB41S
5C164SC05S
5C164TB11P
5C164UB21S
5C164UB41S
5C164UC21P
5C164YA21
(57)【要約】 （修正有）
【課題】ビデオデータをクライアントデバイスに送るために異なるプロトコルを使用することによって再生プロセスを改善可能な方法及びプログラムを提供する。
【解決手段】システム１００において、クライアントデバイス１０４は、第１のプロトコルを使用してビデオの要求のセットを送る。第１のプロトコルは、ビデオのための再生セッションにおける使用のために利用可能な複数のプロトコルから選択される。再生セッションにおいて、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較し、比較することに基づいて再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定する。
【選択図】図１
【解決手段】システム１００において、クライアントデバイス１０４は、第１のプロトコルを使用してビデオの要求のセットを送る。第１のプロトコルは、ビデオのための再生セッションにおける使用のために利用可能な複数のプロトコルから選択される。再生セッションにおいて、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較し、比較することに基づいて再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定する。
【選択図】図１
【特許請求の範囲】
【請求項1】
コンピューティングデバイスによって、ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルが、前記ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、
前記コンピューティングデバイスによって、前記第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、
前記コンピューティングデバイスによって、前記比較することに基づいて前記再生セッション内で前記第１のプロトコルを使用することから前記第２のプロトコルを使用することに切り換えるかどうかを決定することと
を備える方法。
前記コンピューティングデバイスによって、前記第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、
前記コンピューティングデバイスによって、前記比較することに基づいて前記再生セッション内で前記第１のプロトコルを使用することから前記第２のプロトコルを使用することに切り換えるかどうかを決定することと
を備える方法。
【請求項2】
前記切り換えが前記第２のプロトコルに対してなされるとき、前記ビデオのセグメントの要求を送ることと、ここにおいて、前記第２のプロトコルが要求される、
前記切り換えが前記第２のプロトコルに対してなされないとき、前記ビデオの前記セグメントの前記要求を送ることと、ここにおいて、前記第２のプロトコルが要求されず、ビデオの前記セグメントが前記第１のプロトコルを使用して受信される、
をさらに備える、請求項１に記載の方法。
前記切り換えが前記第２のプロトコルに対してなされないとき、前記ビデオの前記セグメントの前記要求を送ることと、ここにおいて、前記第２のプロトコルが要求されず、ビデオの前記セグメントが前記第１のプロトコルを使用して受信される、
をさらに備える、請求項１に記載の方法。
【請求項3】
前記ビデオの再生が開始する前に、前記第１のプロトコルが、前記再生セッションの特性に基づいて前記複数のプロトコルから選択される、請求項１に記載の方法。
【請求項4】
前記第１のプロトコルが、前記ビデオの要求を送ったクライアントデバイスの特性に基づいて前記複数のプロトコルから選択される、請求項１に記載の方法。
【請求項5】
前記要求のセットを送る前に、前記第１のプロトコルを使用して前記再生セッションを開くこと
をさらに備える、請求項１に記載の方法。
をさらに備える、請求項１に記載の方法。
【請求項6】
前記第１のプロトコルの前記第１の性能と前記第２のプロトコルの前記第２の性能とを比較することが、
前記第１のプロトコルを使用して受信されるセグメントの第１のセットを使用して、前記第１のプロトコルのための第１の性能メトリックを計算することと、
前記第２のプロトコルを使用して受信されるセグメントの第２のセットを使用して、前記第２のプロトコルのための第２の性能メトリックを計算することと
を備える、請求項１に記載の方法。
前記第１のプロトコルを使用して受信されるセグメントの第１のセットを使用して、前記第１のプロトコルのための第１の性能メトリックを計算することと、
前記第２のプロトコルを使用して受信されるセグメントの第２のセットを使用して、前記第２のプロトコルのための第２の性能メトリックを計算することと
を備える、請求項１に記載の方法。
【請求項7】
前記第１のプロトコルの前記第１の性能と前記第２のプロトコルの前記第２の性能とを比較することが、
前記セグメントの第１のセットを受信した後、前記第１のプロトコルから前記第２のプロトコルに切り換えること、ここにおいて、前記切り換えることの後に、前記第２の性能メトリックが計算される、
を備える、請求項６に記載の方法。
前記セグメントの第１のセットを受信した後、前記第１のプロトコルから前記第２のプロトコルに切り換えること、ここにおいて、前記切り換えることの後に、前記第２の性能メトリックが計算される、
を備える、請求項６に記載の方法。
【請求項8】
前記再生セッション内で前記第１のプロトコルを使用することから前記第２のプロトコルを使用することに切り換えるかどうかを決定することが、
前記第１の性能メトリックを前記第２の性能メトリックと比較することと、
前記第２の性能メトリックと前記第１の性能メトリックとの差が閾値を満たすとき、前記第２のプロトコルに切り換えることと
を備える、請求項６に記載の方法。
前記第１の性能メトリックを前記第２の性能メトリックと比較することと、
前記第２の性能メトリックと前記第１の性能メトリックとの差が閾値を満たすとき、前記第２のプロトコルに切り換えることと
を備える、請求項６に記載の方法。
【請求項9】
前記差が前記閾値を満たさないとき、前記第１のプロトコルに切り換えること
をさらに備える、請求項８に記載の方法。
をさらに備える、請求項８に記載の方法。
【請求項10】
前記比較すること、および切り換えるかどうかを前記決定することを実施する前に、
バッファ長が閾値を満たすかどうかを決定することと、
前記バッファ長が前記閾値を満たすまで、前記比較すること、および切り換えるかどうかを前記決定することを実施するのを待機することと
をさらに備える、請求項１に記載の方法。
バッファ長が閾値を満たすかどうかを決定することと、
前記バッファ長が前記閾値を満たすまで、前記比較すること、および切り換えるかどうかを前記決定することを実施するのを待機することと
をさらに備える、請求項１に記載の方法。
【請求項11】
前記比較すること、および切り換えるかどうかを前記決定することを実施する前に、
プロファイルラダー内のプロファイルが最も高いプロファイルであるかどうかを決定することと、ここにおいて、前記プロファイルラダー内のプロファイルが、前記ビデオの異なる再生特性と関連付けられる、
前記ビデオを要求するために使用されている前記プロファイルが、前記最も高いプロファイルでなくなるまで、前記比較すること、および切り換えるかどうかを前記決定することを実施するのを待機することと
をさらに備える、請求項１に記載の方法。
プロファイルラダー内のプロファイルが最も高いプロファイルであるかどうかを決定することと、ここにおいて、前記プロファイルラダー内のプロファイルが、前記ビデオの異なる再生特性と関連付けられる、
前記ビデオを要求するために使用されている前記プロファイルが、前記最も高いプロファイルでなくなるまで、前記比較すること、および切り換えるかどうかを前記決定することを実施するのを待機することと
をさらに備える、請求項１に記載の方法。
【請求項12】
前記第１のプロトコルの前記第１の性能と前記第２のプロトコルの前記第２の性能とを比較することが、
ビデオのセグメントが成功してダウンロードされるかどうかを決定することと、
前記セグメントが成功してダウンロードされない場合、失敗の数が閾値を満たすかどうかを決定することと、ここにおいて、前記失敗の数が、前記再生セッション内で成功してダウンロードされていないセグメントの数に基づく、
前記失敗の数が閾値を満たすとき、前記第１のプロトコルから前記第２のプロトコルに切り換えることと
を備える、請求項１に記載の方法。
ビデオのセグメントが成功してダウンロードされるかどうかを決定することと、
前記セグメントが成功してダウンロードされない場合、失敗の数が閾値を満たすかどうかを決定することと、ここにおいて、前記失敗の数が、前記再生セッション内で成功してダウンロードされていないセグメントの数に基づく、
前記失敗の数が閾値を満たすとき、前記第１のプロトコルから前記第２のプロトコルに切り換えることと
を備える、請求項１に記載の方法。
【請求項13】
前記第１のプロトコルの前記第１の性能と前記第２のプロトコルの前記第２の性能とを比較することが、
利用可能な帯域幅を決定することと、
前記利用可能な帯域幅が閾値を満たすかどうかを決定することと、
前記利用可能な帯域幅が前記閾値を満たすとき、前記第１のプロトコルから前記第２のプロトコルに切り換えることと
を備える、請求項１に記載の方法。
利用可能な帯域幅を決定することと、
前記利用可能な帯域幅が閾値を満たすかどうかを決定することと、
前記利用可能な帯域幅が前記閾値を満たすとき、前記第１のプロトコルから前記第２のプロトコルに切り換えることと
を備える、請求項１に記載の方法。
【請求項14】
命令を含む非一時的なコンピュータ可読記憶媒体であって、前記命令が、実行されるとき、
ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルが、前記ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、
前記第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、
前記比較することに基づいて前記再生セッション内で前記第１のプロトコルを使用することから前記第２のプロトコルを使用することに切り換えるかどうかを決定することと
のために動作可能であるようにコンピュータシステムを制御する、非一時的なコンピュータ可読記憶媒体。
ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルが、前記ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、
前記第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、
前記比較することに基づいて前記再生セッション内で前記第１のプロトコルを使用することから前記第２のプロトコルを使用することに切り換えるかどうかを決定することと
のために動作可能であるようにコンピュータシステムを制御する、非一時的なコンピュータ可読記憶媒体。
【請求項15】
コンピューティングデバイスによって、ビデオの要求を受信することと、
前記コンピューティングデバイスによって、複数のプロトコルのための性能メトリックを計算することと、ここにおいて、前記複数のプロトコルが、前記ビデオを送るために使用可能である、
前記コンピューティングデバイスによって、前記ビデオのための再生セッション中に使用するように前記複数のプロトコルにおけるプロトコルを予測するために前記複数のプロトコルのための前記性能メトリックを比較することと、
前記コンピューティングデバイスによって、前記再生セッションのための設定として前記プロトコルのための情報を出力することと、ここにおいて、前記再生セッションのためのビデオが、前記プロトコルを使用して送られる、
を備える方法。
前記コンピューティングデバイスによって、複数のプロトコルのための性能メトリックを計算することと、ここにおいて、前記複数のプロトコルが、前記ビデオを送るために使用可能である、
前記コンピューティングデバイスによって、前記ビデオのための再生セッション中に使用するように前記複数のプロトコルにおけるプロトコルを予測するために前記複数のプロトコルのための前記性能メトリックを比較することと、
前記コンピューティングデバイスによって、前記再生セッションのための設定として前記プロトコルのための情報を出力することと、ここにおいて、前記再生セッションのためのビデオが、前記プロトコルを使用して送られる、
を備える方法。
【請求項16】
複数のプロトコルのための前記性能メトリックを計算することが、
第１のプロトコルのための第１の性能メトリックを計算することと、
第２のプロトコルのための第２の性能メトリックを計算することと、ここにおいて、前記第１の性能メトリックおよび前記第２の性能メトリックが、前記ビデオを要求したクライアントデバイスと関連付けられた再生セッションからの履歴データを使用して計算される、
を備える、請求項１５に記載の方法。
第１のプロトコルのための第１の性能メトリックを計算することと、
第２のプロトコルのための第２の性能メトリックを計算することと、ここにおいて、前記第１の性能メトリックおよび前記第２の性能メトリックが、前記ビデオを要求したクライアントデバイスと関連付けられた再生セッションからの履歴データを使用して計算される、
を備える、請求項１５に記載の方法。
【請求項17】
複数のプロトコルのための前記性能メトリックを計算することが、
前記性能メトリックの前記計算において第１のプロトコルが第２のプロトコルよりも少なく選択されていることを補償する関数を使用すること
を備える、請求項１５に記載の方法。
前記性能メトリックの前記計算において第１のプロトコルが第２のプロトコルよりも少なく選択されていることを補償する関数を使用すること
を備える、請求項１５に記載の方法。
【請求項18】
前記複数のプロトコルのための前記性能メトリックを比較することが、
第１のプロトコルのための第１の性能メトリックと第２のプロトコルのための第２の性能メトリックとの差を決定することと、
前記差が閾値を満たすとき、最も高い性能メトリックを有する前記複数のプロトコルのうちの１つを選択することと
を備える、請求項１５に記載の方法。
第１のプロトコルのための第１の性能メトリックと第２のプロトコルのための第２の性能メトリックとの差を決定することと、
前記差が閾値を満たすとき、最も高い性能メトリックを有する前記複数のプロトコルのうちの１つを選択することと
を備える、請求項１５に記載の方法。
【請求項19】
前記差が閾値を満たさないとき、前記複数のプロトコルから前記プロトコルをランダムに選択すること、請求項１８に記載の方法。
【請求項20】
前記プロトコルのための前記情報が前記複数のプロトコルのランキングを備える、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
【背景技術】
【0002】
[0001]ハイパーテキスト転送プロトコル（ＨＴＴＰ）などのプロトコルは、サーバとクライアントとの間でデータを転送するために使用され得る。たとえば、ＨＴＴＰプロトコルファミリは、ビデオデータを転送するために使用されてよい、ＨＴＴＰ１．１、ＨＴＴＰ２．０、およびＨＴＴＰ３．０というプロトコルを含むことがある。各プロトコルは、同じネットワーク状態を通じてデータを転送するとき、異なるように機能し得る。したがって、いくつかのプロトコルは、あるシナリオでは、より良く機能することがあり、いくつかのプロトコルは、別のシナリオで、より良く機能することがある。たとえば、ＨＴＴＰ３．０は、パケット損失に対するより高い抵抗と、より長く、より高い帯域幅を有するネットワーク上でのより高いスループットとを有し得る。また、ＨＴＴＰ１．０およびＨＴＴＰ２．０は、異なるコンテンツ配信ネットワーク上でより良く機能し得る。異なるクライアントデバイスは、異なる再生セッション内で、および同じ再生セッション内でも、異なるネットワーク状態を経験し得る。しかしながら、クライアントデバイスは、プロトコルを使用するように典型的には静的に構成される。
【発明の概要】
【0003】
[0002]後に続く議論および図面を参照すると、図示される事項は、例示的な議論の目的で例を表し、本開示の原理および概念的な側面の説明を提供するために提示されることが強調される。この点に関して、本開示の基本的な理解のために必要とされるものを越えて実装形態の詳細を示す試みはなされない。続く議論は、図面とともに、本開示による実施形態がどのようにして実施され得るかを当業者に明らかにする。類似のまたは同じ参照番号は、さまざまな図面および支援説明内の類似のまたは同じ要素を識別するまたは指すために使用され得る。
【図面の簡単な説明】
【0004】
【図1】[0003]いくつかの実施形態による、再生セッションのためのプロトコルを選択するための簡略化されたシステムを示す図。
【図2】[0004]いくつかの実施形態による、再生構成予測システムのより詳細な例を示す図。
【図3】[0005]いくつかの実施形態による、性能を推定し、プロトコルを選択する例を示す図。
【図4】[0006]いくつかの実施形態による、プロトコルを切り換えるかどうかを決定するための方法の簡略化されたフローチャート。
【図5】[0007]いくつかの実施形態による、受動的トリガベースのプロトコル切り換えを実施するための方法の簡略化されたフローチャート。
【図6】[0008]いくつかの実施形態による、能動的検出ベースのプロトコル切り換えの例を示す図。
【図7】[0009]いくつかの実施形態による、能動的検出ベースのプロトコル切り換え分析を実施するための方法の簡略化されたフローチャート。
【図8】[0010]一実施形態による、１つまたは複数の通信ネットワークを介して複数のクライアントデバイスと通信するビデオストリーミングシステムを示す図。
【図9】[0011]ビデオコンテンツと広告とを視聴するための装置の線図。
【発明を実施するための形態】
【0005】
[0012]本明細書において説明されるのは、ビデオストリーミングシステムのための技法である。以下の説明では、説明の目的で、いくつかの実施形態の完全な理解を提供するために多数の例および具体的な詳細が記載されている。特許請求の範囲によって定義されるいくつかの実施形態は、これらの例のみにおいて、または以下で説明される他の特徴と組み合わせて、いくつかまたはすべての特徴を含んでよく、本明細書において説明される特徴および概念の修正形態と等価物をさらに含んでよい。
【0006】
[0013]システムは、ビデオなどのデータをクライアントデバイスに送るために異なるプロトコルを使用することによって、再生プロセスを改善する。システムは、以下で論じられるように、再生セッションのために使用するプロトコル、またはプロトコルのランキングを予測し得る。予測は、複数のプロトコルからどのプロトコルが、他のプロトコルと比較して最適に機能し得るかを予測し得る。予測は、再生セッションが開始する前になされることがある。次いで、再生セッション中、システムは、別のプロトコルが、再生セッションにおいて使用されている現在のプロトコルよりも良く機能し得るかどうかを決定し得る。
【0007】
[0014]再生セッションの前にどのプロトコルが最適であり得るかを動的に予測することによって、システムは、クライアントデバイスのために同じプロトコルを使用するように制限されない。従来、システムが、複数のプロトコルから１つを選択するように構成される場合でも、システムは、クライアントデバイスによってサポートされる最も高いプロトコル（たとえば、ＨＴＴＰ３．０）を選択するルールなどのルールを使用するプロトコルを選択するように構成されてよい。このタイプの選択は、どのプロトコルが現在の再生セッションにおいて最適に機能し得るかという予測ではない。また、再生中のプロトコル間の切り換えを可能にすることによって、システムは、再生セッションの特性に基づいてより良く機能し得るプロトコルを発見することができる。したがって、クライアントデバイスは、再生セッションが開始する前に予測される最適なプロトコルまたは再生中に発見される最適なプロトコルを使用することによって、再生状態をより良く経験し得る。異なるクライアントデバイスは異なるネットワーク状態を経験するので、プロセスは、クライアントデバイスごとに実施されてもよい。
【0008】
[0015]システム概要
[0016]図１は、いくつかの実施形態による、再生セッションのためのプロトコルを選択するための簡略化されたシステム１００を示す。システム１００は、再生構成システム１０２と、クライアントデバイス１０４と、コンテンツ配信ネットワーク１０６とを含む。システム１００内のエンティティは、１つまたは複数のコンピューティングデバイスを使用して実装されてよく、説明される機能は、コンピューティングデバイスにわたって分散されてよい。いくつかの例では、１つのエンティティとともに説明される機能は、別のエンティティに分散されることがある。たとえば、再生構成システム１０２によって実施される機能は、コンテンツ配信ネットワーク１０６またはクライアントデバイス１０４によって実施されてよく、クライアントデバイス１０４によって実施されると説明される機能は、再生構成システム１０２および／またはコンテンツ配信ネットワーク１０６によって実施されてよく、以下同様である。
[0016]図１は、いくつかの実施形態による、再生セッションのためのプロトコルを選択するための簡略化されたシステム１００を示す。システム１００は、再生構成システム１０２と、クライアントデバイス１０４と、コンテンツ配信ネットワーク１０６とを含む。システム１００内のエンティティは、１つまたは複数のコンピューティングデバイスを使用して実装されてよく、説明される機能は、コンピューティングデバイスにわたって分散されてよい。いくつかの例では、１つのエンティティとともに説明される機能は、別のエンティティに分散されることがある。たとえば、再生構成システム１０２によって実施される機能は、コンテンツ配信ネットワーク１０６またはクライアントデバイス１０４によって実施されてよく、クライアントデバイス１０４によって実施されると説明される機能は、再生構成システム１０２および／またはコンテンツ配信ネットワーク１０６によって実施されてよく、以下同様である。
【0009】
[0017]クライアントデバイス１０４は、スマートフォン、リビングルームデバイス、タブレットデバイス、パーソナルコンピュータ、セットトップボックス、テレビなどの、ビデオを再生することができるコンピューティングデバイスであってよい。クライアントデバイス１０４は、インターフェース１１２を含んでよく、インターフェース１１２は、ビデオを再生するメディアプレーヤを表示してよい。インターフェース１１２は、再生するビデオを閲覧するためのインターフェースなどの他のデータも表示してよい。
【0010】
[0018]コンテンツ配信ネットワーク１０６は、ストリーム、データ（たとえば、ビデオ、オーディオ、または他のデータ）などをクライアントデバイス１０４に配信することができる１つまたは複数のサーバを含んでよい。たとえば、コンテンツ配信ネットワーク１０６は、ビデオをクライアントデバイス１０４に配信するように構成された１つまたは複数のサーバを含んでよいコンテンツ配信サーバシステム１１６を含む。いくつかの実施形態では、コンテンツ配信サーバシステム１１６は、ビデオのセグメントをクライアント１０４に配信する。セグメントは、ビデオの６秒などの、ビデオの一部分であってよい。既知のように、ビデオは、プロファイルラダー内の異なるレベルに対応する複数のプロファイルにおいて符号化され得る。異なるレベルは、異なるビットレートおよび／または品質であってよい。プロファイルラダーは、再生セッションにおいてクライアントデバイス１０４が利用可能であるプロファイルを含む。プロファイルは、異なるレベルで分類されてよく、各レベルは、異なる特性と関連付けられてよい。たとえば、各レベルは、４００キロビット毎秒（Ｋｂｐｓ）、６５０Ｋｂｐｓ、１０００Ｋｂｐｓ、１５００Ｋｂｐｓ、．．．、および１２０００Ｋｂｐｓなどの、異なるビットレートと関連付けられてよい。しかしながら、レベルは、品質特性（たとえば、解像度）などの、ビットレート以外の特性と関連付けられてよい。いくつかの実施形態では、レベルは、４００Ｋｂｐｓ（および解像度）と関連付けられたプロファイルに対してビデオが４００Ｋｂｐｓレベル（および解像度）で符号化されるなど、どのようにビデオがレベルに対して符号化されるかに基づいて決定されてよい。クライアントデバイス１０４は、現在の再生状態に基づいて、プロファイルレベルのうちの１つからビデオのセグメントを要求し得る。たとえば、クライアントデバイス１０４は、適応ビットレートアルゴリズムを使用して、現在の利用可能な帯域幅および他のネットワーク状態に基づいてビデオのためのプロファイルを選択し得る。
【0011】
[0019]再生構成システム１０２は、クライアントデバイス１０４のための再生構成を決定し得る。たとえば、クライアントデバイス１０４がビデオを選択するとき、再生構成システム１０２は、ビデオ再生要求を受信する。次いで、再生構成予測システム１０８は、クライアントデバイス１０４のための再生構成のための設定を決定する。再生構成は、ビデオをダウンロードおよび再生するためにクライアントデバイス１０４が使用する情報を含んでよい。再生構成の設定のうちの１つは、再生セッション中にプロトコルが使用するための情報を含んでよい。プロトコルは、セッション中にどのようにビデオがストリーミングされるかを定義し得る。異なるプロトコルは、異なるように動作し、異なるプロトコル規格を有してよい。ＨＴＴＰプロトコルファミリは、ＨＴＴＰ１．１、ＨＴＴＰ２．０、およびＨＴＴＰ３．０というプロトコルを含んでよいが、他のプロトコルが使用されてもよい。ＨＴＴＰ１．０がＨＴＴＰ２．０の前に来て、ＨＴＴＰ２．０がＨＴＴＰ３．０の前に来るなど、ＨＴＴＰプロトコルは、バージョンによってランク付けされてよい。開発された他のＨＴＴＰバージョンまたはＨＴＴＰ以外のプロトコルもあってよい。より詳細に論じられるように、再生構成予測システム１０８は、再生セッションのために使用するプロトコルを予測し得る。予測は、単一のプロトコルを選択してもよいし、複数のプロトコルをランク付けしてもよい。予測は、ビデオ再生の要求を受信すると再生セッションが開始する前に実施されてよい。
【0012】
[0020]クライアントデバイス１０４は、再生構成を使用して、セグメントの要求と、いくつかのプロファイルとを送る。プロセスでは、クライアントデバイス１０４は、コンテンツ配信ネットワーク１０６から入手可能なセグメントとプロファイルとをリストするマニフェストを受信し得る。クライアントデバイス１０４は、セグメントのためのプロファイルを選択し、セグメントの要求と、プロファイルとを送り得る。いくつかの実施形態では、クライアントデバイス１０４は、再生構成を介してなど、予測から、プロトコルのための情報を備える。代替的に、再生構成システム１０２は、予測をコンテンツ配信ネットワーク１０６に送ってよく、次いで、コンテンツ配信ネットワーク１０６は、クライアントデバイス１０４に予測を送ってもよいし、単にプロトコルを選択してもよい。予測のための情報は、異なる形で提供されてよい。たとえば、情報は、再生セッションのための選択されたプロトコルをリストすることがある。また、情報は、ＨＴＴＰ２．０、ＨＴＴＰ３．０、およびＨＴＴＰ１．１のランキングなどの、使用されてよいプロトコルのランキングをリストし得る。
【0013】
[0021]クライアントデバイス１０４は、異なるやり方でビデオのセグメントを要求し得る。たとえば、クライアントデバイス１０４は、セグメントの要求を送ってよい。要求では、クライアントデバイス１０４は、予測されたプロトコルのための情報を挿入し得る。いくつかの実施形態では、クライアントデバイス１０４は、要求のヘッダ内、または要求の他のエリア内に情報を挿入することがある。また、クライアントデバイス１０４は、使用する単一のプロトコルを指定してもよいし、プロトコルのランキングなどのプロトコルのリストを指定してもよい。コンテンツ配信ネットワーク１０６は、要求されたプロファイルにおいてセグメントを有する要求に応答し得る。コンテンツ配信ネットワーク１０６は、要求に含まれる単一のプロトコルに基づいて、使用するプロトコルを選択し得る。また、コンテンツ配信ネットワーク１０６は、すべてのプロトコルをサポートしてもよいし、しなくてもよい。どちらの場合にも、コンテンツ配信ネットワーク１０６は、サポートされる最も高いランク付けされたプロトコルを選択してよい。
【0014】
[0022]コンテンツ配信ネットワーク１０６内のセグメント／プロトコルセレクタ１１４は、要求を受信し、要求されたプロファイルのためのセグメントを選択することができる。また、セグメント／プロトコルセレクタ１１４は、指定されたプロトコルまたはサポートされる最も高いランク付けされたプロトコルを選択するなど、プロトコルを選択する。次いで、コンテンツ配信ネットワーク１０６は、選択されたプロトコルを使用して、ビデオのセグメントを送る。
【0015】
[0023]いくつかの実施形態では、再生構成予測システム１０８は、再生セッションからの情報または再生セッション履歴からの情報を使用して、再生セッションが開始する前にプロトコルを予測する。予測は、再生セッション中に複数のプロトコルからどのプロトコルが最適な性能を提供し得るかを予測する。
【0016】
[0024]再生セッションが開始すると、再生セッションの特性は、再生セッション中により良い性能を提供するために決定され得る別のプロトコルを選択するために使用されてよい。セッション内プロトコルアダプタ１１０は、再生セッションの特性を分析し、再生セッション中に別のプロトコルがより良い性能を提供し得るかどうかを決定し得る。セッション内プロトコルアダプタ１１０は、クライアントデバイス１０４に含まれると示されているが、セッション内プロトコルアダプタ１１０は、コンテンツ配信ネットワーク１０６または再生構成システム１０２内など、他の場所にあってよい。セッション内プロトコルアダプタ１１０は、セッションが開始する前に予測されたプロトコルを使用する代わりに、現在の再生状態に基づいて、プロトコルに切り換えることができる。これは、再生セッションが開始する前に予測において使用される特性とは異なってよい、再生セッションの状態が変化するとき、より良い再生性能を提供することがある。
【0017】
[0025]再生構成予測システム
[0026]図２は、いくつかの実施形態による、再生構成予測システム１０８のより詳細な例を示す。再生構成システム１０８は、データソース２０２からの情報と、クライアントデバイス１０４についてのクライアント再生情報も受信し得る。
[0026]図２は、いくつかの実施形態による、再生構成予測システム１０８のより詳細な例を示す。再生構成システム１０８は、データソース２０２からの情報と、クライアントデバイス１０４についてのクライアント再生情報も受信し得る。
【0018】
[0027]データソース２０２は、コンテンツ配信ネットワーク（ＣＤＮ）ログ２０４－１と、サービス品質（ＱｏＳ）データ２０４－２と、コンテキスト情報２０４－３とを含んでよい。このタイプの情報が説明されているが、再生の特性を説明する他の情報も使用されてよい。ＣＤＮログ２０４－１は、コンテンツ配信ネットワーク１０６および／またはビデオをクライアントデバイス１０４（これは、このクライアントデバイス１０４または他のクライアントデバイス１０４を含んでよい）にストリーミングした他のコンテンツ配信ネットワーク１０６からの情報を含んでよい。ＣＤＮログは、ビデオがストリーミングされたセッションのための情報を説明する。ＣＤＮログは、異なるコンテンツ配信ネットワーク１０６のプロトコル実装形態が同じでないことがあるので、異なるコンテンツ配信ネットワーク１０６上での異なるプロトコルの性能を分析するために使用され得る。
【0019】
[0028]ＱｏＳデータ２０４－２は、再生セッション中に再生の品質に関連する情報を含み、これは、クライアントデバイス１０４、他のクライアントデバイス、またはコンテンツ配信ネットワーク１０６からであってもよい。コンテキスト情報２０４－３は、クライアントデバイス１０４の特性、ネットワーク、時間などについての情報などの、再生セッションに関連する情報を含んでよい。
【0020】
[0029]表１は、データソース２０２のいくつかの例を説明するが、他の情報が使用されてもよい。
【0021】
【表1】
【0022】
[0030]クライアント再生情報は、リアルタイムでクライアントデバイス１０４から受信されてよい、および／または履歴データであってよい。また、クライアント再生情報は、前の再生セッションからデータソース２０２に統合されてよい。クライアント再生情報の例は、ＱｏＳデータ２０４－２と、コンテキスト情報２０４－３とを含んでよい。たとえば、クライアント再生情報は、再バッファ比と、失敗比と、平均ビットレートとを含んでよい。クライアント再生情報は、セッションが開始する前にプロトコルの予測を実施するために使用されてもよい。このクライアント再生情報は、クライアントデバイス１０４からリアルタイムで受信されてよい。
【0023】
[0031]データソース２０２は、プロトコル性能推定器２０８によって使用されるモデルを訓練するために使用される。モデルは、性能を予測するために訓練されてよい。たとえば、セッション情報履歴を使用して、プロトコル選択エンジン２１０は、特徴を使用して、ユーザアカウントのクラスタを構築することがある。各クラスタに対して、プロトコル選択エンジン２１０は、モデルのパラメータを訓練してよい。来たるべき各セッションに対して、プロトコル性能推定器２０８は、セッション情報履歴に基づいて、各クラスタにおいて異なるプロトコルのための性能を推定し得る。パラメータは、リアルタイム再生セッション情報によって更新されることもできる。また、データソース２０２は、プロトコルを選択するためにプロトコル選択エンジン２１０によって使用されるモデルを訓練するために使用されることがある。
【0024】
[0032]プロトコル性能推定器２０８は、異なるプロトコルを使用するとき、現在の再生セッションの性能を推定し得る。この推定は、現在の再生セッションと呼ばれる、来たるべきセッションのためである。プロトコル性能推定器２０８は、現在の再生セッションがビデオの再生を開始する前に性能推定を計算し得る。また、プロトコル性能推定器２０８は、現在の再生セッション中など、他の時間に推定を実施し得る。
【0025】
[0033]プロトコル性能推定器２０８は、履歴情報および／または現在の再生セッションを使用して、性能を予測し得る。いくつかの実施形態では、特徴抽出２０６は、クライアントデバイス１０４のための再生セッション履歴から特徴を抽出し得る。次いで、特徴抽出２０６は、現在の再生セッションのための特徴を抽出し得る。いくつかの実施形態では、特徴抽出２０６は、類似の性質を含み得るセッションをクラスタ化してよい。たとえば、１つのクラスタは、ネットワーク＃１と、地理的場所＃１と、他の情報とを使用する再生に基づいてよい。別のクラスタは、ネットワーク＃２と、地理的場所＃２とを使用していることがある。クラスタリングが説明されているが、クラスタリングが使用されなくてよい。しかしながら、クラスタリングは、現在の再生セッションに類似してよいセッションを選択してよく、これは、クラスタのための履歴情報が現在の再生セッションの特性に関連がより高いことがあるので、関連のより高い予測を生成し得る。
【0026】
[0034]プロトコル性能推定器２０８は、現在の再生セッションのための各プロトコルのための性能を推定し得る。いくつかの例では、プロトコル性能推定器２０８は、ダウンロード帯域幅などの再生メトリックに基づいて、現在の再生セッションに使用するプロトコルの性能を推定し得る。たとえば、プロトコル性能推定器２０８は、平均ダウンロード帯域幅などの再生メトリックの平均を推定し得る。しかしながら、平均メトリックを使用するときより少ないデータを有するプロトコルのための性能を正確に推定することが困難であることがある。たとえば、プロトコルが、別のプロトコルと比較してあまり選択されていないとき、平均メトリックは、プロトコルのための性能を正確に予測しないことがある。性能分布の分散が大きいとき、少数のサンプルの平均値が、プロトコルの性能を表さないことがあり、これは、誤ったプロトコルを最適なプロトコルとして選択させ得る。たとえば、プロトコルが広範囲のダウンロード帯域幅を経験し得る場合、小さいサンプルサイズは、範囲全体にわたる分布を表さないことがある。これは、そのプロトコルのための平均ダウンロード帯域幅を不正確にし得る。
【0027】
[0035]いくつかの実施形態では、プロトコル性能推定器２０８は、他のプロトコルよりも小さいサンプルサイズを有し得るプロトコルなどの、他のプロトコルよりも少なく選択されたプロトコルを補償し得る性能を推定し得る。いくつかの実施形態では、性能を推定するために、以下の関数が使用されることがある。
【0028】
【数1】
【0029】
ここで、Ｐｉは、プロトコルｉのための推定される性能、
【0030】
【数2】
【0031】
は、プロトコルｉを使用する再生セッション履歴の平均性能、Ｎは再生セッションのクラスタ内の総カウント、ｎｉは、このクラスタ内でプロトコルｉが選択されている回数の数である。変数ａｉ、ｂｉおよびｃｉは重み付け係数であり、平均性能の優先権と、サンプリングバイアスと、初期選択とをそれぞれ表す。重み付け係数は、使用されてもよいし、使用されなくてもよい。上記の関数は、少なく選択されたプロトコルも、現在の再生セッションのために選択される機会を有することを可能にしてよく、これは、それらのサンプルサイズを増加させ、その後の推定をより正確にし得る。
【0032】
[0036]以下の例は、上記の関数がどのように働くかを説明する。プロトコルＸの平均スループットは５メガバイト毎秒（Ｍｂｐｓ）であり、プロトコルＹの平均スループットは４Ｍｂｐｓである。プロトコルＸは４５００回選択されており、プロトコルＹは５００回選択されている。重み付け係数がａｉ＝１、ｂｉ＝１０、およびｃｉ＝０である場合、これらの２つのプロトコルのための推定性能が計算可能である。たとえば、プロトコルＸのための推定性能は、
【0033】
【数3】
【0034】
である。プロトコルＹのための推定性能は、
【0035】
【数4】
【0036】
である。
【0037】
[0037]したがって、プロトコル性能推定器２０８は、５．８４６という推定性能は５．６１５よりも大きいので、プロトコルＹがプロトコルＸよりも良く機能し得ると結論付ける。プロトコル性能推定器２０８は、プロトコルＸの平均帯域幅の方が高い場合であっても、プロトコルＹの性能はプロトコルＸよりも高いと推定する。このようにして、プロトコル性能推定器２０８は、セッション履歴の統計データの信頼度を考慮する。セッションの数が増加するにつれて、統計結果は次第に安定するようになってよく、関数の第２の部分
【0038】
【数5】
【0039】
の効果は次第に弱くなる。したがって、第２の部分は、より少ないサンプリングを有するプロトコルが選択されることを可能にし得る。したがって、５００回選択されたプロトコルＹは、プロトコルＸの方が高い平均帯域幅を有する場合であっても、４５００回選択されたプロトコルＸよりも選択されてよい。プロトコルＹを選択することは、より多くのサンプルをサイズに追加することによって、そのプロトコルのための履歴情報の精度を最終的に増加させてよい。次いで、履歴情報の精度の増加は、性能推定の精度を増加させ得る。
【0040】
[0038]プロトコル選択エンジン２１０は、プロトコル性能推定器２０８から性能推定を受信し、プロトコルを選択する。プロトコル選択エンジン２１０は、異なる方法を使用して、プロトコルを選択してよい。図３は、いくつかの実施形態による、性能を推定し、プロトコルを選択する例を示す。３０２では、プロトコル性能推定器２０８は、現在の再生セッションのための特徴を抽出する。特徴は、ビデオを要求したクライアントデバイス１０４またはユーザアカウントに基づいてよい。
【0041】
[0039]３０４では、プロトコル性能推定器２０８は、特徴のためのクラスタを選択する。クラスタは、現在の再生セッションに類似した特徴を含む再生セッション履歴を含んでよい。また、クラスタは、ランダムに選択された再生セッション履歴を含んでもよいし、クラスタは、ランダムに選択された再生セッション履歴のみを含んでもよい。
【0042】
[0040]３０６では、プロトコル性能推定器２０８は、クラスタのための履歴情報を抽出する。抽出される履歴情報は、プロトコル性能を予測するために使用されているモデルによって必要とされる情報に基づいてよい。３０８では、プロトコル性能推定器２０８は、各プロトコルのための性能Ｐを推定する。
【0043】
[0041]３１０では、プロトコル選択エンジン２１０は、プロトコルのための推定性能間の差を決定し、差が閾値よりも大きいなど、性能差が閾値を満たすかどうかを決定する。推定差は、すべてのプロトコルの性能の比較に基づいてよい。たとえば、３つのプロトコルが使用されている場合、性能差は、プロトコル＃１とプロトコル＃２、プロトコル＃１とプロトコル＃３、およびプロトコル＃２とプロトコル＃３との差に基づいてよい。プロトコル選択エンジン２１０は、最大性能差を決定し得る。次いで、性能のプロトコルを使用する差がある場合、最適な性能を提供するプロトコルを選択することは、現在の再生セッション中のビデオの再生を改善し得るので、プロトコル選択エンジン２１０は、比較の最大差を使用し得る。しかしながら、プロトコルのための性能の差が小さい場合、プロトコルのうちの１つを選択することは、現在の再生セッション中に別のプロトコルよりも実質的な性能改善を提供しない。
【0044】
[0042]３１２では、性能差が閾値よりも大きい場合、プロトコル選択エンジン２１０は、最大性能を有するプロトコルを選択する、またはプロトコルのランキングを選択する。選択されたプロトコルまたはランキングは、現在の再生セッション中に最も良い性能を提供し得るプロトコルを選択するために使用される。
【0045】
[0043]３１４では、性能が閾値よりも大きくない場合、プロトコル選択エンジン２１０は、プロトコルをランダムに選択し得る。ランダムな選択が説明されているが、他の方法も使用されてよい。たとえば、プロトコル選択エンジン２１０は、別のプロトコルよりも少なく使用されているプロトコルを選択し得る。ランダムな選択またはより少なく使用されているプロトコルを選択することは、他のプロトコルほど多く使用されていないプロトコルを再生構成予測システム１０８が使用することを可能にし得る。これは、プロトコルの使用を分散させることがあり、これは、プロトコルのためのより多くの履歴情報が使用されることを可能にする。
【0046】
[0044]３１６では、プロトコル選択エンジン２１０は、上記に基づいてプロトコルのランキングを更新することなど、現在の再生セッション情報を更新する。たとえば、プロトコル選択エンジン２１０が、最大性能を有するプロトコルを選択する場合、プロトコル選択エンジン２１０は、推定性能に基づいてプロトコルのランキングを使用し得る。プロトコル選択エンジン２１０がプロトコルをランダムに選択した場合、プロトコル選択エンジン２１０は、ランキングにランダムな順序を使用してもよいし、性能の順序にプロトコルをランダムに選択した後のプロトコルを含んでもよいし、他の方法を使用してもよい。次いで、３１８では、プロトコル選択エンジン２１０は、選択されたプロトコルを出力する。プロトコル選択エンジン２１０は、プロトコルのランキングが使用されている場合、それも出力してよい。次いで、選択されたプロトコルは、現在の再生セッション中に使用されてよい。
【0047】
[0045]プロトコルを選択するための上記の方法が使用されるが、他の方法が使用されてよい。たとえば、プロトコル選択エンジン２１０は、確率に基づく方法を使用してプロトコルを選択してよい。いくつかの例では、２つのプロトコルＸおよびＹがあり、それらの性能予測はＰｘおよびＰｙである。プロトコル選択エンジン２１０は、
【0048】
【数6】
【0049】
という確率を有するプロトコルＸを選択しながら、
【0050】
【数7】
【0051】
という確率を有するプロトコルＹを選択し得る。このようにして、より良い性能を有するプロトコルは、より多くの、選択される機会を有する。
【0052】
[0046]セッション内プロトコル切り換え
[0047]ビデオの再生中、ネットワーク状態が変化することがある。たとえば、利用可能なネットワーク帯域幅は、現在の再生セッション中に変化することがあり、履歴データに反映されるものとは異なることがある。これが発生するとき、再生セッションが開始する前に選択されたプロトコルは、現在の再生状態に最適なプロトコルでないことがある。したがって、セッション内プロトコルアダプタ１１０は、プロトコルの性能を引き続き分析し、再生セッション中にプロトコルを動的に切り換えることがある。
[0047]ビデオの再生中、ネットワーク状態が変化することがある。たとえば、利用可能なネットワーク帯域幅は、現在の再生セッション中に変化することがあり、履歴データに反映されるものとは異なることがある。これが発生するとき、再生セッションが開始する前に選択されたプロトコルは、現在の再生状態に最適なプロトコルでないことがある。したがって、セッション内プロトコルアダプタ１１０は、プロトコルの性能を引き続き分析し、再生セッション中にプロトコルを動的に切り換えることがある。
【0053】
[0048]いくつかの実施形態では、セッション内プロトコルアダプタ１１０は、異なる方法を使用して、プロトコル切り換えが実施されるべきかどうかを決定することがある。たとえば、セッション内プロトコルアダプタ１１０は、能動的検出ベースのプロトコル切り換えおよび受動的トリガベースのプロトコル切り換えと呼ばれるプロセスを使用してよい。能動的検出ベースのプロトコル切り換えは、再生状態が通常であると考えられるなどのいくつかの状態が経験されているとき、プロトコルを切り換えることが再生を改善し得るかどうかを能動的に決定し得る。この場合、セッション内プロトコルアダプタ１１０は、使用するより良いプロトコルを能動的に検索する。受動的トリガベースのプロトコル切り換えは、再生経験が異常と考えられるなどの他の状態が経験されているとき、プロトコルを切り換え得る。異常な状態は、ダウンロード失敗により、または利用可能な帯域幅が低いとき、生じることがある。この場合、プロトコル切り換えは、ネットワーク状態のために自動的にトリガされ得る。２つの方法を使用して、セッション内プロトコルアダプタ１１０は、異なる状態を使用して、いつプロトコルを切り換えることがより良い再生性能をもたらし得るかを決定し得る。
【0054】
[0049]図４は、いくつかの実施形態による、プロトコルを切り換えるかどうかを決定するための方法の簡略化されたフローチャート４００を示す。４０２では、クライアントデバイス１０４は、ビデオのセグメントをダウンロードする。ビデオのセグメントが説明されているが、ビデオの複数のセグメントがダウンロードされ、分析で使用されてよい。
【0055】
[0050]４０４では、セッション内プロトコルアダプタ１１０は、以下でより詳細に説明される受動的トリガベースのプロトコル切り換え分析を実施する。４０６では、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えるかどうかを決定する。分析が、プロトコルは切り換えられるべきであると示した場合、４０８において、セッション内プロトコルアダプタ１１０は、プロトコルを切り換える。たとえば、セッション内プロトコルアダプタ１１０は、現在の再生セッション中により良く機能することが予測されるプロトコルに自動的に切り換えてよい。また、セッション内プロトコルアダプタ１１０は、プロトコルファミリまたはプロトコルランキング内の次に最も高いプロトコル（たとえば、ＨＴＴＰ３．０が使用されている場合はＨＴＴＰ２．０）、ランダムな選択などの、他の方法を使用して、別のプロトコルに切り換えてよい。セッション内プロトコルアダプタ１１０が、プロトコルを切り換えないことを決定した場合、４１０において、セッション内プロトコルアダプタ１１０は、能動的検出ベースのプロトコル切り換え分析を実施する。能動的検出ベースのプロトコル切り換え分析は、受動的トリガベースのプロトコル切り換え分析の後で実施されると説明されているが、プロセスは、逆にされてよく、順序正しく実施される必要はない。しかしながら、受動的トリガベースのプロトコル切り換え分析は、いつネットワーク状態が悪化するかを検出するために自動的に実施されてよく、ネットワーク状態が再生問題を引き起こす前に検出するために重要であることがある。能動的検出ベースのプロトコル切り換え分析は、いつプロトコルがより良く機能し得るかを検出するために、異なる時間に、またはある一定の間隔で実施されてよく、プロトコルを切り換える緊急性が増加する、ネットワーク状態が悪化しているときと比較して、ネットワーク状態は通常と考えられ得るので、プロトコルの切り換えを実施する緊急性はあまり重要でないことがある。
【0056】
[0051]４１２では、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えるかどうかを決定する。分析が、プロトコルは切り換えられるべきであると示した場合、４１４において、セッション内プロトコルアダプタ１１０は、プロトコルを切り換える。そうでない場合、４１６では、セッション内プロトコルアダプタ１１０は、現在の再生セッションにおいて現在使用されているプロトコルを維持する。
【0057】
[0052]受動的トリガベースのプロトコル切り換えでは、現在の再生セッションの異なる特性が分析され得る。たとえば、セグメントをダウンロードする失敗および利用可能な帯域幅などのリアルタイム性能特性は、プロトコルを切り換えるかどうかを決定するために分析されることがある。
【0058】
[0053]図５は、いくつかの実施形態による、受動的トリガベースのプロトコル切り換えを実施するための方法の簡略化されたフローチャート５００を示す。５０２では、クライアントデバイス１０４は、ビデオのセグメントをダウンロードする。次いで、５０４では、セッション内プロトコルアダプタ１１０は、セグメントが成功してダウンロードされるかどうかを決定する。成功したダウンロードは、セグメント全体が完全にダウンロードされることを意味し得るが、他の状態が適用されてもよい。また、再バッファリングを伴わないセグメントの再生が必要とされることがある。ある一定の時間内にセグメントが成功してダウンロードされるかどうかを決定するために、時間制限も適用されることがある。
【0059】
[0054]セグメントが成功してダウンロードされなかった場合、セッション内プロトコルアダプタ１１０は、失敗履歴を分析する。たとえば、５０６では、セッション内プロトコルアダプタ１１０は、失敗カウントが失敗閾値を満たすかどうか（たとえば、失敗カウントが失敗閾値よりも大きい）を決定する。失敗カウントは、現在の再生セッション中にセグメントのダウンロードのために生じた失敗の数のカウントであり得る。たとえば、３つのセグメントがダウンロードするのに失敗した可能性がある。失敗カウントが失敗閾値よりも大きい場合、５０８において、セッション内プロトコルアダプタ１１０は、プロトコルを切り換え得る。
【0060】
[0055]セグメントが成功してダウンロードされた場合、５１０において、セッション内プロトコルアダプタ１１０は、利用可能な帯域幅を推定する。たとえば、クライアントデバイス１０４は、ダウンロードされるセグメントから利用可能な帯域幅を分析し得る。利用可能な帯域幅は、現在の再生セッション中の時間期間にわたってダウンロードされるデータの量に基づいてよい。
【0061】
[0056]セッション内プロトコルアダプタ１１０は、プロトコルを切り換えるかどうかを決定するために利用可能な帯域幅を分析する。たとえば、５１２では、セッション内プロトコルアダプタ１１０は、帯域幅が帯域幅閾値よりも小さいなど、帯域幅が帯域幅（ＢＷ）閾値を満たすかどうかを決定する。利用可能な帯域幅が帯域幅閾値よりも小さい場合、これは、ネットワーク帯域幅が悪化していることを示し得る。この場合、使用されているプロトコルは、利用可能な帯域幅をサポートしないことがある。たとえば、利用可能な帯域幅が、使用されているプロトコルの最も低いプロファイルのビットレートよりも小さい場合、別のプロトコルが、ネットワーク上でより良く動作することがある。したがって、５１４では、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えることがある。選択されるプロトコルは、経験されているネットワーク状態により良く適し得る特性を有し得るプロトコルであってよく、利用可能な帯域幅が増加し得る。
【0062】
[0057]帯域幅が帯域幅閾値よりも大きい、または失敗カウントが失敗閾値よりも小さい場合、セッション内プロトコルアダプタ１１０は、能動的検出ベースの切り換え分析を実施し得る。能動的検出ベースのプロトコル切り換えの場合、セッション内プロトコルアダプタ１１０は、性能特性に基づいて、別のプロトコルが現在のプロトコルよりも良く機能し得るかどうかを決定する。たとえば、セッション内プロトコルアダプタ１１０は、現在のプロトコルの能力が最大にされているかどうかを考えることがある。すなわち、セッション内プロトコルアダプタ１１０は、現在のプロトコルが最も高い可能な性能レベルで動作しているので、プロトコルを切り換えないことがある。クライアントデバイス１０４が、プロトコルに利用可能な最高ビットレートを有するプロファイルを使用している場合、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えない。
【0063】
[0058]セッション内プロトコルアダプタ１１０はまた、バッファ長を使用して、プロトコルを切り換えるかどうかを決定し得る。バッファ長は、メディアプレーヤが別のプロトコルへの切り換えをサポートすることができるかどうかを決定する。たとえば、別のプロトコルへの切り換えは、新しいプロトコルに切り換える時間を必要とすることがあり、これは、切り換え中にバッファ内の何らかのデータを使用することを必要とする。バッファ内に十分なデータが存在しない場合、メディアプレーヤは、ビデオを再生するのに十分なデータを有さないので、メディアプレーヤは、再バッファリングを経験し得る。バッファ長が十分に長い場合、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えようと試みることがある。セッション内プロトコルアダプタ１１０は、新しいプロトコルがより良くない場合、前のプロトコルに切り換えることがある。新しいプロトコルの性能が前のプロトコルよりも悪い場合、バッファ長は再生をサポートするのに適切であるので、再生は、実際には影響されないことがある。
【0064】
[0059]図６は、いくつかの実施形態による、能動的検出ベースのプロトコル切り換えの例を示す。プロトコル＃１およびプロトコル＃２が示されている。プロトコル＃１は現在のプロトコルであってよく、プロトコル＃２は新しいプロトコルであってよい。クライアントデバイス１０４は、ビデオのセグメントＳをダウンロードしていてよい。たとえば、プロトコルが切り換わる前に、クライアントデバイス１０４は、セグメントＳｉ－３ ６０２－１と、セグメントＳｉ－２ ６０２－２と、セグメントＳｉ－１ ６０２－３と、セグメントＳｉ６０２－４とをダウンロードする。「ｉ」の値は、プロトコル切り換えが発生する時間を表し得る。
【0065】
[0060]セッション内プロトコルアダプタ１１０は、異なるメトリックを使用してプロトコルの性能を評価し得る。たとえば、セッション内プロトコルアダプタ１１０は、バッファ長を使用して、新しいプロトコルがより良く機能しているかどうかを決定することがある。セッション内プロトコルアダプタ１１０は、経時的にダウンロードされるバイトなどの他のメトリックを使用してよい。セッション内プロトコルアダプタ１１０は、異なる期間でバッファ長を決定し得る。たとえば、セッション内プロトコルアダプタ１１０は、６０４において初期バッファ長を記録することがあり、初期バッファ長は、プロトコルが切り換わる前のセグメントの数である。プロトコルが切り換わる前の３つのセグメントは使用されてよいが、プロトコルが切り換わる前の任意の数のセグメントが使用されてよい。また、セッション内プロトコルアダプタ１１０は、プロトコル切り換えがなされたとき、６０６においてバッファ長を記録する。
【0066】
[0061]プロトコル切り換えが発生した後、切り換え時間６０８は、クライアントデバイス１０４によって経験されることがある。切り換え時間６０８は、プロトコル＃２を介してセグメントを受信するために接続を築く時間であってよい。これは、サーバとの新しい接続を開く、接続のパラメータを交渉するなどの、異なるプロセスを関与させることがある。クライアントデバイス１０４が、切り換えの前に接続をすでに開いている場合、切り換え時間６０８は生じなくてよい。いくつかの実施形態では、クライアントデバイス１０４は、ビデオを送るプロトコル＃１が使用されているセッションを分解し得る。他の実施形態では、クライアントデバイス１０４は、プロトコル＃１を介してビデオを送るために使用されている接続を開いたままにすることがある。
【0067】
[0062]切り換え時間６０８の後、クライアントデバイス１０４は、セグメントＳｉ＋１ ６０２－５、セグメントＳｉ＋２ ６０２－６、およびセグメントＳｉ＋３ ６０２－７など、プロトコル＃２を使用してパケットを受信する。セグメントＳｉ＋３ ６０２－７を受信した後、セッション内プロトコルアダプタ１１０は、６１０においてバッファ長を記録する。たとえば、セッション内プロトコルアダプタ１１０は、プロトコル切り換えの前に記録されたセグメントの数と比較して同じ数のセグメントが受信された後、バッファ長を記録する。次いで、セッション内プロトコルアダプタ１１０は、バッファ長を使用して、どのプロトコルがより良く機能しているかを決定し得る。たとえば、新しいプロトコルが使用された後にバッファ長が増加した場合、新しいプロトコルは、古いプロトコルよりも良いことがある。これは、より良い性能によりビデオセグメントがより早く受信され得るからである。しかしながら、プロトコル切り換えの後にバッファ長が減少した場合、前のプロトコルの方が良いことがある。これは、より悪い性能によりビデオセグメントがより遅く受信され得るからである。
【0068】
[0063]バッファ長を分析した後、セッション内プロトコルアダプタ１１０は、プロトコルを切り換えるかどうか決定をなし得る。たとえば、セッション内プロトコルアダプタ１１０は、プロトコル＃２への切り換えを永続的にし、プロトコル＃２を使用してセグメントＳｉ＋４ ６０２－８をダウンロードしてよい。しかしながら、セッション内プロトコルアダプタ１１０は、プロトコル＃１がより良く機能し、プロトコル＃１を使用してセグメントＳｉ＋４ ６０２－９をダウンロードするためにプロトコル＃１に切り換えると決定することがある。いくつかの実施形態では、セッション内プロトコルアダプタ１１０は、プロトコル＃１からプロトコル＃２に、次いでプロトコル＃１に、プロトコルを切り換え得る。クライアントデバイス１０４が、プロトコル＃１を使用してセグメントをダウンロードしていたセッションを開いたままにした場合、プロトコル＃１に切り換える時間が生じないことがある。むしろ、クライアントデバイス１０４は、開いたセッションを使用して、セグメントを要求し、プロトコル＃１を使用してセグメントをダウンロードすることができる。しかしながら、何らかの切り換え時間が、プロトコル＃２からプロトコル＃１に切り換えるために必要とされる場合、セッション内プロトコルアダプタ１１０は、プロトコル＃１に切り換えるかどうかを決定するとき、切り換え時間を考慮し得る。たとえば、プロトコル＃１に切り換える時間が、場合によっては再バッファリングを引き起こし、プロトコル＃２の性能があまり異ならない場合、セッション内プロトコルアダプタ１１０は、プロトコル＃２に進むことがある。セグメントが、異なるプロトコルを使用して受信および再生される場合、プロトコルを切り換えることが説明されているが、他の方法も使用されてよい。たとえば、クライアントデバイス１０４は、複数の接続を開き、第１のプロトコルのためのセグメントをダウンロードすることと平行して、第２の接続を使用して第２のプロトコルのためのセグメントをダウンロードしてよい。クライアントデバイス１０４は、いずれかのセグメントを使用してビデオを再生し得る。したがって、複数のプロトコルの性能を評価することができる異なる方法が使用可能である。
【0069】
[0064]図７は、いくつかの実施形態による、能動的検出ベースのプロトコル切り換え分析を実施するための方法の簡略化されたフローチャート７００を示す。７０２では、セッション内プロトコルアダプタ１１０は、現在のプロトコルのためのバッファ長を決定する。７０４では、セッション内プロトコルアダプタ１１０は、バッファ長がバッファ閾値よりも大きいかどうかなど、バッファ長がバッファ閾値を満たすかどうかを決定する。バッファ長がバッファ閾値よりも大きくない場合、７１２において、セッション内プロトコルアダプタ１１０は、現在のプロトコルを維持してよい。再バッファリングなどの問題を引き起こさずに再生をサポートするのに十分なデータがバッファ内にないことがあるので、現在のプロトコルが維持される。
【0070】
[0065]バッファ長がバッファ閾値よりも大きい場合、７０６において、セッション内プロトコルアダプタ１１０は、最も高いプロファイルが使用されているかどうかを決定する。最も高いプロファイルが使用されている場合、７１２において、セッション内プロトコルアダプタ１１０は、現在のプロトコルを維持する。最も高いビットレートを有する最も高いプロファイルが使用されているので、セッション内プロトコルアダプタ１１０は現在のプロトコルを維持する。したがって、このプロトコルは最適に機能しているので、別のプロトコルへの切り換えは必要とされない。最も高いプロトコルが使用されていない場合、７０８において、セッション内プロトコルアダプタ１１０は、新しいプロトコルに切り換え、新しいプロトコルを用いてビデオセグメントをダウンロードする。
【0071】
[0066]７１０では、セッション内プロトコルアダプタ１１０は、新しいプロトコルを用いた改善が閾値を満たすかどうかを決定する。改善は、バッファ長、ダウンロードされるバイトの数、または利用可能な帯域幅などの、性能特性によって測定され得る。改善が閾値を満たさない場合、７１４において、セッション内プロトコルアダプタ１１０は、新しいプロトコルに切り換える前に使用されていた、前のプロトコルに切り換え得る。しかしながら、７１６では、改善が閾値よりも大きい場合、セッション内プロトコルアダプタ１１０は、新しいプロトコルへの切り換えを永続的にしてよい。切り換えを永続的にすることが論じられるとき、これは、プロトコルが切り換えられるべきかどうかを決定するために次の分析が実施されるまで、切り換えが永続的であってよいことを意味する。すなわち、新しいプロトコルは、ここで、次の分析が実施されるまで、現在のプロトコルである。
【0072】
[0067]いくつかの実施形態では、プロトコルを切り換えることによって得られる改善を決定するために、セッション内プロトコルアダプタ１１０は、異なる方法を使用して改善を測定することがある。上記で論じられたように、メトリックは、バッファ長を使用して、改善を決定し得る。いくつかの実施形態では、以下のメトリックが、新しいプロトコルの改善を推定するために使用されてよい。
【0073】
【数8】
【0074】
[0068]上記では、式の第１の部分（ｂｕｆｆｅｒｉ＋３－ｂｕｆｆｅｒｉ）は、プロトコル切り換え後のバッファ長であり、第２の部分（ｂｕｆｆｅｒｉ－ｂｕｆｆｅｒｉ－３）は、プロトコル切り換え前のバッファ長である。第１の部分は、新しいプロトコルを使用して３つのセグメントをダウンロードした後のバッファ長の変化を表し、第２の部分は、プロトコルを切り換える前に３つのセグメントをダウンロードすることに基づいたバッファ長変化を表す。利得メトリックは、プロトコル切り換え前とプロトコル切り換え後のダウンロード能力を考えてよい。切り換えを実施するために何らかのオーバヘッドを考慮に入れるために、第１の部分は、切り換え時間４０８も含んでよく、第２の部分は、前のプロトコルに切り換える何らかの時間を含んでよい。改善が閾値よりも大きい場合、セッション内プロトコルアダプタ１１０は、新しいプロトコルは前のプロトコルよりも良いと考えてよい。そうでない場合、セッション内プロトコルアダプタ１１０は、前のプロトコルに切り換えてよい。
【0075】
[0069]結論
[0070]したがって、いくつかの実施形態は、再生セッションが開始する前に使用するプロトコルを動的に予測する。使用されるプロトコルは、再生セッションに最適であると考えられてよい。また、セッション中に、状態が変化する、またはプロトコルを予測するために使用された状態とは異なる場合、セッション内プロトコルアダプタ１１０は、プロトコルを別のプロトコルに切り換えてよい。上記のプロトコルの動的な選択は、現在の再生セッションに最適であり得るプロトコルを選択することによって、再生性能を改善し得る。
[0070]したがって、いくつかの実施形態は、再生セッションが開始する前に使用するプロトコルを動的に予測する。使用されるプロトコルは、再生セッションに最適であると考えられてよい。また、セッション中に、状態が変化する、またはプロトコルを予測するために使用された状態とは異なる場合、セッション内プロトコルアダプタ１１０は、プロトコルを別のプロトコルに切り換えてよい。上記のプロトコルの動的な選択は、現在の再生セッションに最適であり得るプロトコルを選択することによって、再生性能を改善し得る。
【0076】
[0071]例示的な実施形態
[0072]いくつかの実施形態では、コンピューティングデバイスによって、ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルが、ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、コンピューティングデバイスによって、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、コンピューティングデバイスによって、比較することに基づいて再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定することとを備える方法。
[0072]いくつかの実施形態では、コンピューティングデバイスによって、ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルが、ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、コンピューティングデバイスによって、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、コンピューティングデバイスによって、比較することに基づいて再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定することとを備える方法。
【0077】
[0073]いくつかの実施形態では、切り換えが第２のプロトコルに対してなされるとき、ビデオのセグメントの要求を送ることと、ここにおいて、第２のプロトコルが要求される、切り換えが第２のプロトコルに対してなされないとき、ビデオのセグメントの要求を送ることと、ここにおいて、第２のプロトコルが要求されず、ビデオのセグメントが第１のプロトコルを使用して受信される、をさらに備える方法。
【0078】
[0074]いくつかの実施形態では、ビデオの再生が開始する前に、第１のプロトコルは、再生セッションの特性に基づいて複数のプロトコルから選択される。
【0079】
[0075]いくつかの実施形態では、第１のプロトコルは、ビデオの要求を送ったクライアントデバイスの特性に基づいて複数のプロトコルから選択される。
【0080】
[0076]いくつかの実施形態では、要求のセットを送る前に、第１のプロトコルを使用して再生セッションを開くことをさらに備える方法。
【0081】
[0077]いくつかの実施形態では、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することは、第１のプロトコルを使用して受信されるセグメントの第１のセットを使用して、第１のプロトコルのための第１の性能メトリックを計算することと、第２のプロトコルを使用して受信されるセグメントの第２のセットを使用して、第２のプロトコルのための第２の性能メトリックを計算することとを備える。
【0082】
[0078]いくつかの実施形態では、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することは、セグメントの第１のセットを受信した後、第１のプロトコルから第２のプロトコルに切り換えること、ここにおいて、切り換えることの後に、第２の性能メトリックが計算される、を備える。
【0083】
[0079]いくつかの実施形態では、再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定することは、第１の性能メトリックを第２の性能メトリックと比較することと、第２の性能メトリックと第１の性能メトリックとの差が閾値を満たすとき、第２のプロトコルに切り換えることとを備える。
【0084】
[0080]いくつかの実施形態では、差が閾値を満たさないとき、第１のプロトコルに切り換えることをさらに備える方法。
【0085】
[0081]いくつかの実施形態では、比較すること、および切り換えるかどうかを決定することを実施する前に、バッファ長が閾値を満たすかどうかを決定することと、バッファ長が閾値を満たすまで、比較すること、および切り換えるかどうかを決定することを実施するのを待機することとをさらに備える方法。
【0086】
[0082]いくつかの実施形態では、比較すること、および切り換えるかどうかを決定することを実施する前に、プロファイルラダー内のプロファイルが最も高いプロファイルであるかどうかを決定することと、ここにおいて、プロファイルラダー内のプロファイルは、ビデオの異なる再生特性と関連付けられる、ビデオを要求するために使用されているプロファイルが最も高いプロファイルでなくなるまで、比較すること、および切り換えるかどうかを決定することを実施するのを待機することとをさらに備える方法。
【0087】
[0083]いくつかの実施形態では、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することは、ビデオのセグメントが成功してダウンロードされるかどうかを決定することと、セグメントが成功してダウンロードされない場合、いくつかの失敗が閾値を満たすかどうかを決定することと、ここにおいて、失敗の数が、再生セッション内で成功してダウンロードされていないセグメントの数に基づく、失敗の数が閾値を満たすとき、第１のプロトコルから第２のプロトコルに切り換えることとを備える。
【0088】
[0084]いくつかの実施形態では、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することは、利用可能な帯域幅を決定することと、この利用可能な帯域幅が閾値を満たすかどうかを決定することと、利用可能な帯域幅が閾値を満たすとき、第１のプロトコルから第２のプロトコルに切り換えることとを備える。
【0089】
[0085]いくつかの実施形態では、命令を含む非一時的なコンピュータ可読記憶媒体であって、命令が、実行されるとき、ビデオの要求のセットを送ることと、ここにおいて、第１のプロトコルは、ビデオのための再生セッション内の使用のために利用可能である複数のプロトコルから使用される、第１のプロトコルの第１の性能と第２のプロトコルの第２の性能とを比較することと、比較することに基づいて再生セッション内で第１のプロトコルを使用することから第２のプロトコルを使用することに切り換えるかどうかを決定することとのために動作可能であるようにコンピュータシステムを制御する、非一時的なコンピュータ可読記憶媒体。
【0090】
[0086]いくつかの実施形態では、コンピューティングデバイスによって、ビデオの要求を受信することと、コンピューティングデバイスによって、複数のプロトコルのための性能メトリックを計算することと、ここにおいて、複数のプロトコルは、ビデオを送るために使用可能である、コンピューティングデバイスによって、ビデオのための再生セッション中に使用するように複数のプロトコルにおけるプロトコルを予測するために複数のプロトコルのための性能メトリックを比較することと、コンピューティングデバイスによって、再生セッションのための設定としてプロトコルのための情報を出力することと、ここにおいて、再生セッションのためのビデオは、プロトコルを使用して送られる、を備える方法。
【0091】
[0087]いくつかの実施形態では、複数のプロトコルのための性能メトリックを計算することは、第１のプロトコルのための第１の性能メトリックを計算することと、第２のプロトコルのための第２の性能メトリックを計算することと、ここにおいて、第１の性能メトリックおよび第２の性能メトリックは、ビデオを要求したクライアントデバイスと関連付けられた再生セッションからの履歴データを使用して計算される、を備える。
【0092】
[0088]いくつかの実施形態では、複数のプロトコルのための性能メトリックを計算することは、性能メトリックの計算において第１のプロトコルが第２のプロトコルよりも少なく選択されていることを補償する関数を使用することを備える。
【0093】
[0089]いくつかの実施形態では、複数のプロトコルのための性能メトリックを比較することは、第１のプロトコルのための第１の性能メトリックと第２のプロトコルのための第２の性能メトリックとの差を決定することと、差が閾値を満たすとき、最も高い性能メトリックを有する複数のプロトコルのうちの１つを選択することとを備える。
【0094】
[0090]いくつかの実施形態では、差が閾値を満たさないとき、複数のプロトコルからプロトコルをランダムに選択すること。
【0095】
[0091]いくつかの実施形態では、プロトコルのための情報が複数のプロトコルのランキングを備える方法。
【0096】
[0092]システム
[0093]本明細書で開示される特徴および態様は、図８に示される１つまたは複数の通信ネットワークを介して複数のクライアントデバイスと通信するビデオストリーミングシステム８００に関連して実装されてよい。ビデオストリーミングシステム８００の態様は、単に、本開示により用意されたコンテンツの分散および配信を可能にする適用例の一例を提供するために説明される。本技術は、ストリーミングビデオアプリケーションに限定されず、他のアプリケーションおよび配信機構に適合されてよいことが理解されるべきである。
[0093]本明細書で開示される特徴および態様は、図８に示される１つまたは複数の通信ネットワークを介して複数のクライアントデバイスと通信するビデオストリーミングシステム８００に関連して実装されてよい。ビデオストリーミングシステム８００の態様は、単に、本開示により用意されたコンテンツの分散および配信を可能にする適用例の一例を提供するために説明される。本技術は、ストリーミングビデオアプリケーションに限定されず、他のアプリケーションおよび配信機構に適合されてよいことが理解されるべきである。
【0097】
[0094]一実施形態では、メディアプログラムプロバイダは、メディアプログラムのライブラリを含んでよい。たとえば、メディアプログラムは、サイト（たとえば、ウェブサイト）、アプリケーション、またはブラウザを通じて集約および提供されてよい。ユーザは、メディアプログラムプロバイダのサイトまたはアプリケーションにアクセスし、メディアプログラムを要求することができる。ユーザは、メディアプログラムプロバイダによって提供されるメディアプログラムのみを要求することに限定されてよい。
【0098】
[0095]システム８００内で、ビデオデータは、ビデオコンテンツサーバ８０２への入力としての使用のために、１つまたは複数のソースから、たとえば、ビデオソース８１０から、取得され得る。入力ビデオデータは、任意の適切なデジタルフォーマット、たとえば、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）－１、ＭＰＥＧ－２、ＭＰＥＧ－４、ＶＣ－１、Ｈ．２６４／Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）、または他のフォーマットで、未加工または編集されたフレームベースのビデオデータを備えてよい。代替形態では、ビデオは、非デジタルフォーマットで提供され、スキャナおよび／またはトランスコーダを使用してデジタルフォーマットに変換されてよい。入力ビデオデータは、ビデオクリップまたはさまざまなタイプのプログラム、たとえば、テレビエピソード、モーションピクチャ、および消費者にとって関心のあるプライマリコンテンツとして作られた他のコンテンツを備えてよい。ビデオデータは、オーディオも含んでよいし、オーディオのみが使用されてよい。
【0099】
[0096]ビデオストリーミングシステム８００は、１つまたは複数のコンピュータ上で分散された１つまたは複数のコンピュータサーバまたはモジュール８０２、８０４、および／または８０７を含んでよい。各サーバ８０２、８０４、８０７は、１つまたは複数のデータストア８０９、たとえば、データベース、インデックス、ファイル、または他のデータ構造を含んでもよいし、これに動作可能に結合されてもよい。ビデオコンテンツサーバ８０２は、さまざまなビデオセグメントのデータストア（図示せず）にアクセスし得る。ビデオコンテンツサーバ８０２は、クライアントデバイスと通信するユーザインターフェースコントローラによって指示されたビデオセグメントにサービスし得る。本明細書で使用されるとき、ビデオセグメントは、テレビエピソード、モーションピクチャ、記録されたライブパフォーマンス、または他のビデオコンテンツを視聴するためにストリーミングビデオセッションにおいて使用され得るなどの、フレームベースのビデオデータの明確な部分を指す。
【0100】
[0097]いくつかの実施形態では、ビデオ広告サーバ８０４は、特定の広告主のための広告またはメッセージとして構成された比較的短いビデオ（たとえば、１０秒、３０秒、または６０秒のビデオ広告）のデータストアにアクセスし得る。広告は、何らかの種類の支払いと引き換えに広告主に提供されてもよいし、システム８００のためのプロモーションメッセージ、パブリックサービスメッセージ、または何らかの他の情報を備えてもよい。ビデオ広告サーバ８０４は、ユーザインターフェースコントローラ（図示せず）によって指示されたビデオ広告セグメントにサービスし得る。
【0101】
[0098]ビデオストリーミングシステム８００は、再生構成システム１０２も含んでよい。
【0102】
[0099]ビデオストリーミングシステム８００は、ビデオコンテンツとビデオ広告とをストリーミングビデオセグメントに統合する統合およびストリーミングコンポーネント８０７をさらに含んでよい。たとえば、ストリーミングコンポーネント８０７は、コンテンツサーバまたはストリーミングメディアサーバであってよい。コントローラ（図示せず）は、任意の適切なアルゴリズムまたはプロセスに基づいて、ストリーミングビデオ内での広告の選択または構成を決定してよい。ビデオストリーミングシステム８００は、図８に示されていない他のモジュールまたはユニット、たとえば、管理サーバ、商業サーバ、ネットワークインフラストラクチャ、広告選択エンジンなどを含んでよい。
【0103】
[00100]ビデオストリーミングシステム８００は、データ通信ネットワーク８１２に接続し得る。データ通信ネットワーク８１２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、たとえば、インターネット、電話網、ワイヤレスセルラー電話通信ネットワーク（ＷＣＳ）８１４、またはこれらもしくは類似のネットワークの何らかの組み合わせを備えてよい。
【0104】
[00101]１つまたは複数のクライアントデバイス８２０は、データ通信ネットワーク８１２、ワイヤレスセルラー電話通信ネットワーク８１４、および／または別のネットワークを介して、ビデオストリーミングシステム８００と通信し得る。そのようなクライアントデバイスは、たとえば、ＬＡＮのためのルータ８１８を介した、ワイヤレスセルラー電話通信ネットワーク８１４のための基地局８１７を介した、または何らかの他の接続を介した、１つまたは複数のラップトップコンピュータ８２０－１、デスクトップコンピュータ８２０－２、「スマート」モバイル電話８２０－３、タブレットデバイス８２０－４、ネットワーク対応テレビ８２０－５、またはそれらの組み合わせを含んでよい。動作中、そのようなクライアントデバイス８２０は、ユーザ入力デバイスから受信されたユーザ入力または他の入力に応答して、データまたは命令をシステム８００に送り、受信してよい。応答して、システム８００は、クライアントデバイス８２０に対するメディアプログラムの選択に応答して、データストア８０９からビデオセグメントとメタデータとにサービスしてよい。クライアントデバイス８２０は、ディスプレイ画面、プロジェクタ、または他のビデオ出力デバイスを使用してメディアプレーヤ内のストリーミングビデオセグメントからビデオコンテンツを出力し、ビデオコンテンツと相互作用するためにユーザ入力を受信し得る。
【0105】
[00102]オーディオビデオデータの分散は、種々の方法、たとえばストリーミングを使用して、コンピュータネットワーク、電気通信ネットワーク、およびそのようなネットワークの組み合わせの上でストリーミングコンポーネント８０７からリモートクライアントデバイスに実装されてよい。ストリーミング時、コンテンツサーバは、クライアントデバイス上で少なくとも部分的に動作するメディアプレーヤコンポーネントにオーディオビデオデータを連続的にストリーミングし、これは、サーバからストリーミングデータを受信するのと同時にオーディオビデオデータを再生し得る。ストリーミングが論じられているが、配信の他の方法も使用されてよい。メディアプレーヤコンポーネントは、コンテンツプロバイダからデータの初期部分を受信した直後にビデオデータの再生を始めてよい。従来のストリーミング技法は、データのストリームをエンドユーザのセットに配信する単一のプロバイダを使用する。高い帯域幅処理電力が、大勢の観客に単一ストリームを配信するために必要とされることがあり、エンドユーザの数が増加するにつれて、必要とされるプロバイダの帯域幅も増加し得る。
【0106】
[00103]ストリーミングメディアは、オンデマンドで、またはライブで、配信可能である。ストリーミングは、ファイル内の任意の箇所での即時再生を可能にする。エンドユーザは、再生を開始するまたは再生をメディアファイル内の任意の箇所に変更するために、メディアファイルをざっと見てよい。したがって、エンドユーザは、ファイルが徐々にダウンロードされるのを待機する必要はない。典型的には、ストリーミングメディアは、ビデオファイルの要求を受け付ける専門デバイスを介して、高い帯域幅能力を有する少数の専用サーバから配信され、フォーマット、帯域幅、およびそれらのファイルの構造についての情報とともに、ビデオを、それを再生するのに必要な速度で再生するのに必要なデータの量だけを配信する。ストリーミングメディアサーバは、送信帯域幅および宛先クライアント上でのメディアプレーヤの能力も説明し得る。ストリーミングコンポーネント８０７は、ビデオが再生されるとネットワーク状態を変更することに調整するために制御メッセージとデータメッセージとを使用して、クライアントデバイス８２０と通信し得る。これらの制御メッセージは、高速フォワーディング、高速リバース、一時停止、またはクライアントにおいてファイルの特定の部分を探すことなどの制御機能を可能にするためのコマンドを含むことができる。
【0107】
[00104]ストリーミングコンポーネント８０７は、必要に応じてのみ、必要とされる速度で、ビデオデータを送信するので、サービスされるストリームの数に対する精密な制御は維持可能である。視聴者は、より低いデータレート送信媒体上で高データレートビデオを視聴することは可能でない。しかしながら、ストリーミングメディアサーバは、（１）ビデオファイルへのランダムアクセスをユーザに提供し、（２）誰がどのビデオプログラムを視聴しているかと、ビデオプログラムがどれくらい長く見られるかの監視を可能にし、（３）視聴経験をサポートするために必要とされるデータの量のみが送信されるので、より効率的に送信帯域幅を使用し、（４）ビデオファイルは、視聴者のコンピュータ内に記憶されず、メディアプレーヤによって破棄され、したがって、コンテンツに対するより多くの制御を可能にする。
【0108】
[00105]ストリーミングコンポーネント８０７は、ＨＴＴＰおよびリアルタイムメッセージングプロトコル（ＲＴＭＰ）などの、ＴＣＰベースのプロトコルを使用してよい。ストリーミングコンポーネント８０７は、ライブウェブキャストも配信することがあり、マルチキャストすることができ、これは、複数のクライアントが単一のストリームに同調し、したがって帯域幅を節約することを可能にする。ストリーミングメディアプレーヤは、メディアプログラム内の任意の箇所へのランダムアクセスを提供するためにビデオ全体をバッファリングすることに依拠しない。代わりに、これは、メディアプレーヤからストリーミングメディアサーバに送信される制御メッセージを使用して達成される。ストリーミングのために使用される他のプロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ライブストリーミング（ＨＬＳ）またはＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）である。ＨＬＳプロトコルおよびＤＡＳＨプロトコルは、典型的には１つまたは複数のコンテンツ配信ネットワーク（ＣＤＮ）からさまざまなビットレートにおいて利用可能にされる小さいセグメントの再生リストを介して、ＨＴＴＰ上でビデオを配信する。これは、メディアプレーヤが、セグメントごとにビットレートとコンテンツソースの両方を切り換えることを可能にする。切り換えは、ビデオの再生中に発生し得るネットワーク帯域幅差異およびインフラストラクチャ障害を補償する助けとなる。
【0109】
[00106]ストリーミングによるビデオコンテンツの配信は、さまざまなモデル下で達成され得る。１つのモデルでは、ユーザは、ビデオプログラムの視聴の代金を支払う、たとえば、メディアプログラムのライブラリもしくは制限されたメディアプログラムの一部分へのアクセスの料金を支払う、または視聴ごとの支払いサービスを使用する。その始まり後まもなくブロードキャストテレビによって広く採用された別のモデルでは、スポンサーは、プログラムの提示中またはこれに隣接して広告を提示する権利と引き換えにメディアプログラムの提示の代金を支払う。いくつかのモデルでは、広告は、ビデオプログラム内に所定の時間に挿入され、この時間は、「広告スロット」または「広告休憩」と呼ばれることがある。ストリーミングビデオとともに、メディアプレーヤは、クライアントデバイスが、指定された広告スロット中に所定の広告も再生することなくビデオを再生することはできないように構成されてよい。
【0110】
[00107]図９を参照すると、ビデオコンテンツと広告とを視聴するための装置９００の線図が示されている。選択された実施形態では、装置９００は、プロセッサメモリ９０４に動作可能に結合されたプロセッサ（ＣＰＵ）９０２を含んでよく、プロセッサメモリ９０４は、プロセッサ９０２による実行のためにバイナリコーディングされた機能モジュールを保持する。そのような機能モジュールは、入力／出力およびメモリアクセスなどのシステム機能を扱うためのオペレーティングシステム９０６と、ウェブページを表示するブラウザ９０８と、ビデオを再生するためのメディアプレーヤ９１０とを含んでよい。モジュールは、セッション内プロトコルアダプタ１１０をさらに含んでよい。メモリ９０４は、図９に図示されない追加のモジュール、たとえば、本明細書の他の箇所で説明される他の動作を実施するためのモジュールを保持し得る。
【0111】
[00108]バス９１４または他の通信コンポーネントは、装置９００内での情報の通信をサポートし得る。プロセッサ９０２は、特定のタスクを定義する機械可読ソフトウェアコードを実行することによって、本明細書で開示される特徴および態様により特定のタスクを実施するように構成されたまたは動作可能である特殊なまたは専用のマイクロプロセッサであってよい。プロセッサメモリ９０４（たとえば、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶デバイス）は、バス９１４に、またはプロセッサ９０２に直接的に接続され、情報と、プロセッサ９０２によって実行されることになる命令とを記憶してよい。メモリ９０４は、そのような命令の実行中に一時変数または他の中間情報も記憶してよい。
【0112】
[00109]記憶デバイス９２４内のコンピュータ可読媒体は、バス９１４に接続され、静的情報と、プロセッサ９０２のための命令とを記憶してよい。たとえば、記憶デバイス（ＣＲＭ）９２４は、装置９００が電源切断されるとき、モジュール９０６と、９０８と、９１０と、９１２とを記憶してよく、装置９００から、モジュールは、装置９００が電源投入されたとき、プロセッサメモリ９０４にロードされ得る。記憶デバイス９２４は、情報、命令、またはそれらの何らかの組み合わせ、たとえば、プロセッサ９０２によって実行されるとき、本明細書で説明される方法の１つまたは複数の動作を実施するように装置９００を構成させるまたは動作可能にする命令を保持する非一時的なコンピュータ可読記憶媒体を含んでよい。
【0113】
[00110]通信インターフェース９１６は、バス９１４にも接続されてよい。通信インターフェース９１６は、任意選択でルータ／モデム９２６およびワイヤード接続またはワイヤレス接続を介して、装置９００と１つまたは複数の外部デバイス、たとえば、ストリーミングシステム８００との間の双方向データ通信を提供またはサポートしてよい。代替として、またはさらに、装置９００は、アンテナ９２９に接続されたトランシーバ９１８を含んでよく、アンテナ９２９を通じて、装置９００は、ワイヤレス通信システムのための基地局と、またはルータ／モデム９２６と、ワイヤレスに通信し得る。代替として、装置９００は、ローカルエリアネットワーク、仮想プライベートネットワーク、または他のネットワークを介して、ビデオストリーミングシステム８００と通信してよい。別の代替形態では、装置９００は、システム８００のモジュールまたはコンポーネントとして組み込まれ、バス９１４を介して、または何らかの他のモダリティによって、他のコンポーネントと通信してよい。
【0114】
[00111]装置９００は、ディスプレイユニット９２８に（たとえば、バス９１４およびグラフィックス処理ユニット９２０を介して）接続されてよい。ディスプレイ９２８は、装置９００のオペレータに情報を表示するための任意の適切な構成を含んでよい。たとえば、ディスプレイ９２８は、視覚的ディスプレイにおいて装置９００のユーザに情報を提示するために、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンＬＣＤ（たとえば、容量性ディスプレイ）、発光ダイオード（ＬＥＤ）ディスプレイ、プロジェクタ、または他のディスプレイデバイスを含んでもよいし、これを利用してもよい。
【0115】
[00112]１つまたは複数の入力デバイス９３０（たとえば、英数字キーボード、マイクロホン、キーパッド、リモートコントローラ、ゲームコントローラ、カメラ、またはカメラアレイ）は、装置９００に情報とコマンドとを通信するために、ユーザ入力ポート９２２を介してバス９１４に接続されてよい。選択された実施形態では、入力デバイス９３０は、カーソルの位置決めに対する制御を提供またはサポートしてよい。ポインティングデバイスとも呼ばれるそのようなカーソル制御デバイスは、マウス、トラックボール、トラックパッド、タッチスクリーン、カーソル方向キー、または物理的動きを受信もしくは追跡し、その動きを、カーソルの動きを示す電気信号に変換するための他のデバイスとして構成されてよい。カーソル制御デバイスは、たとえば、タッチセンシティブスクリーンを使用して、ディスプレイユニット９２８に統合されてよい。カーソル制御デバイスは、プロセッサ９０２に方向情報とコマンド選択を通信し、ディスプレイ９２８上でのカーソルの動きを制御し得る。カーソル制御デバイスは、２つ以上の自由度を有してよく、たとえば、デバイスが、平面または３次元空間内でのカーソル位置を指定することを可能にする。
【0116】
[00113]いくつかの実施形態は、命令実行システム、装置、システム、もしくは機械による使用のために、またはこれとともに、非一時的なコンピュータ可読記憶媒体内で実装され得る。コンピュータ可読記憶媒体は、いくつかの実施形態によって説明される方法を実施するようにコンピュータシステムを制御するための命令を含む。コンピュータシステムは、１つまたは複数のコンピューティングデバイスを含んでよい。１つまたは複数のコンピュータプロセッサによって実行されるとき、命令は、いくつかの実施形態で説明されるものを実施するように構成または動作可能であってよい。
【0117】
[00114]本明細書における説明において、および続く特許請求の範囲全体を通じて、使用されるとき、「１つの（ａ）」、「１つの（ａｎ）」、および「その（ｔｈｅ）」は、文脈が別途明確に示さない限り、複数の参照を含む。また、本明細書における説明において、および続く特許請求の範囲全体を通じて、使用されるとき、文脈が別途明確に示さない限り、「内（ｉｎ）」の意味は、「内（ｉｎ）」と「上（ｏｎ）」とを含む。
【0118】
[00115]上記の説明は、どのようにいくつかの実施形態の態様が実装され得るかの例とともにさまざまな実施形態を示す。上記の例および実施形態は、唯一の実施形態と見なされるべきでなく、以下の特許請求の範囲によって定義されるいくつかの実施形態の柔軟性と利点とを示すために提示される。上記の開示および以下の特許請求の範囲に基づいて、他の配置、実施形態、実装形態、および等価物が、特許請求の範囲によって定義される本発明の範囲から逸脱することなく用いられてよい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【外国語明細書】