特許 7420796 ビデオ品質を維持しつつ、ビデオのビットレートを上げること

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-01-15

(45)【発行日】2024-01-23

(54)【発明の名称】ビデオ品質を維持しつつ、ビデオのビットレートを上げること

(51)【国際特許分類】

   H04N 21/2385 20110101AFI20240116BHJP

【ＦＩ】

H04N21/2385

【請求項の数】 23

(21)【出願番号】P 2021516929

(86)(22)【出願日】2019-06-26

(65)【公表番号】

(43)【公表日】2022-01-06

(86)【国際出願番号】 US2019039121

(87)【国際公開番号】W WO2020068218

(87)【国際公開日】2020-04-02

【審査請求日】2022-06-20

(31)【優先権主張番号】16/141,653

(32)【優先日】2018-09-25

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【氏名又は名称】上田 忠

(72)【発明者】

【氏名】ジェローザ，リカルド

(72)【発明者】

【氏名】グラウンズ，ブライアン

(72)【発明者】

【氏名】スリヴィンスキー，ステファン・フランシス

(72)【発明者】

【氏名】ダメレル，クイン

【審査官】大西 宏

(56)【参考文献】

【文献】特開２０１１－０５５２８６（ＪＰ，Ａ）

【文献】特表２０１２－５１７１３０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／０１２１９７４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１０／０２３５５２４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１４／０３５１６３８（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１５／０１２１４３７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１６／００２１３７７（ＵＳ，Ａ１）

【文献】Fakher Oueslati et al.，Network Quality Adaptive Video Transmission，2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing，米国，IEEE ，2015年10月，pp.469-476，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7363108

【文献】bdelhak Bentaleb et al.，Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP，IEEE Communications Surveys & Tutorials，米国，IEEE，2018年08月03日，Volume: 21, Issue: 1，pp.562-585，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8424813

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００ －２１／８５８

(57)【特許請求の範囲】

【請求項1】

ストリーミングサービスを動作させる方法であって、
エンコーダにおいて、
初期ビットレートでビデオデータのソースによってエンコードされた前記ビデオデータを受信するステップであって、前記ソースは、前記ビデオデータを他のエンドポイントにライブストリーミングするエンドポイントを含む、ステップと、
前記初期ビットレートと該初期ビットレートより低いビットレートとを含む複数のビットレートで前記ビデオデータを再エンコードするステップと、
前記複数のビットレートの前記ビデオデータを同時にリレーサーバに送信するステップと、
前記リレーサーバにおいて、前記複数のビットレートの前記ビデオデータを同時にエッジサーバに送信するステップと、
前記エッジサーバにおいて、
所与のビットレートで前記ビデオデータを前記他のエンドポイントのうちの第１のエンドポイントにストリーミングするステップであって、前記所与のビットレートは前記複数のビットレートのうちの１つを含む、ステップと、
前記所与のビットレートで前記ビデオデータをストリーミングしつつ、追加のビットレートで検査データを前記第１のエンドポイントに送信するステップであって、前記検査データは前記ビデオデータの少なくとも一部の複製を含む、ステップと、
前記ビデオデータと前記検査データとの総ビットレートが前記複数のビットレートのうちの次に利用可能なビットレートに達するまで、または、前記ビデオデータの品質が品質尺度を満たさなくなるまで、前記検査データの前記追加のビットレートを増加させるステップと、
前記総ビットレートが前記次に利用可能なビットレートに達したとき、前記所与のビットレートでの前記ビデオデータの前記第１のエンドポイントへのストリーミングから、前記次に利用可能なビットレートでの前記ビデオデータのストリーミングに条件付きでスイッチするステップと
を含む方法。

【請求項2】

請求項１に記載の方法であって、
前記検査データの前記追加のビットレートを増加させるステップは、前記総ビットレートが前記次に利用可能なビットレートに達するまでに、前記検査データの前記追加のビットレートの２回以上の増加が実行されるように、前記検査データの前記追加のビットレートを増加させるステップを含み、
前記方法は、
前記エッジサーバにおいて、前記２回以上の増加のうちの何れかにおいて、前記ビデオデータの前記品質が前記品質尺度を満たさないとき、前記所与のビットレートでの前記ビデオデータの前記第１のエンドポイントへのストリーミングを続けるステップ
を更に含む、
方法。

【請求項3】

請求項１又は２に記載の方法であって、前記ビデオデータの前記品質は、前記ビデオデータの前記ストリーミングと関連付けられた１つまたは複数のパフォーマンス測定基準の観点から定義され、前記方法は、
前記品質が前記品質尺度を満たさない場合、前記検査データをそれ以上送信するのを控えるステップ
をさらに含む、方法。

【請求項4】

請求項１又は２に記載の方法であって、複数のビットレートで前記ビデオデータを再エンコードするステップは、前記ビデオデータの複数のバージョンを生成するステップであって、前記ビデオデータの前記複数のバージョンのそれぞれは、前記ビデオデータの前記複数のバージョンの互いに対して異なるビットレートでエンコードされる、ステップをさらに含む、方法。

【請求項5】

請求項４に記載の方法であって、前記次に利用可能なビットレートでの前記ビデオデータのストリーミングは、前記次に利用可能なビットレートでエンコードされた前記ビデオデータの前記複数のバージョンのうちの異なる１つのストリーミングを含む、方法。

【請求項6】

請求項５に記載の方法であって、前記ビデオデータの前記ストリーミングと関連付けられた前記１つまたは複数のパフォーマンス測定基準は、レイテンシ、ジッタおよびパケット損失を含む、方法。

【請求項7】

請求項１又は２に記載の方法であって、前記検査データの前記送信に関係なく前記品質が低下することに応答して、前記所与のビットレートでの前記ビデオデータのストリーミングから、より低いビットレートでの前記ビデオデータのストリーミングにスイッチするステップをさらに含む方法。

【請求項8】

請求項１又は２に記載の方法であって、前記所与のビットレートでおよび前記次に利用可能なビットレートでの前記ビデオデータのストリーミングは、コネクションレスおよび低信頼トランスポートプロトコルに従う前記ビデオデータのストリーミングを含む、方法。

【請求項9】

請求項１又は２に記載の方法であって、前記ビデオデータは、発信元エンドポイントによって前記他のエンドポイントへのブロードキャストのためにキャプチャされた、ゲーミングセッションのビデオを含む、方法。

【請求項10】

１つまたは複数のコンピュータ可読記憶媒体と、
前記１つまたは複数のコンピュータ可読記憶媒体に動作可能に結合された処理システムと、
ストリーミングサービスを動作させるために前記１つまたは複数のコンピュータ可読記憶媒体に格納されたプログラム命令と
を含む計算装置であって、前記プログラム命令は、前記処理システムによって実行されると、前記計算装置に、
エンコーダにおいて、
初期ビットレートでビデオデータのソースによってエンコードされた前記ビデオデータを受信することであって、前記ソースは、前記ビデオデータを他のエンドポイントにライブストリーミングするエンドポイントを含む、前記ビデオデータを受信することと、
前記初期ビットレートと該初期ビットレートより低いビットレートとを含む複数のビットレートで前記ビデオデータを再エンコードすることと、
前記複数のビットレートの前記ビデオデータを同時にリレーサーバに送信することと、
前記リレーサーバにおいて、前記複数のビットレートの前記ビデオデータを同時にエッジサーバに送信することと
前記エッジサーバにおいて、
所与のビットレートで前記ビデオデータを前記他のエンドポイントのうちの第１のエンドポイントにストリーミングすることであって、前記所与のビットレートは前記複数のビットレートのうちの１つを含む、前記ビデオデータをストリーミングすることと、
前記所与のビットレートで前記ビデオデータをストリーミングしつつ、追加のビットレートで検査データを前記第１のエンドポイントに送信することであって、前記検査データは前記ビデオデータの少なくとも一部の複製を含む、検査データを送信することと、
前記ビデオデータと前記検査データとの総ビットレートが前記複数のビットレートのうちの次に利用可能なビットレートに達するまで、または、前記ビデオデータの品質が品質尺度を満たさなくなるまで、前記検査データの前記追加のビットレートを増加させることと、
前記総ビットレートが前記次に利用可能なビットレートに達したとき、前記所与のビットレートでの前記ビデオデータの前記第１のエンドポイントへのストリーミングから、前記次に利用可能なビットレートでの前記ビデオデータのストリーミングに条件付きでスイッチすることと
を少なくとも行うように指示する、
計算装置。

【請求項11】

請求項１０に記載の計算装置であって、
前記検査データの前記追加のビットレートを増加させることは、前記総ビットレートが前記次に利用可能なビットレートに達するまでに、前記検査データの前記追加のビットレートの２回以上の増加が実行されるように、前記検査データの前記追加のビットレートを増加させることを含み、
前記プログラム命令は、前記処理システムによって実行されると、前記計算装置に、
前記エッジサーバにおいて、前記２回以上の増加のうちの何れかにおいて、前記ビデオデータの前記品質が前記品質尺度を満たさないとき、前記所与のビットレートでの前記ビデオデータの前記第１のエンドポイントへのストリーミングを続けること
を少なくとも行うように更に指示する、
計算装置。

【請求項12】

請求項１０又は１１に記載の計算装置であって、前記プログラム命令は、前記計算装置に、
前記品質が前記品質尺度を満たさない場合、前記検査データをそれ以上送信するのを控えること
を行うようにさらに指示する、計算装置。

【請求項13】

請求項１０又は１１に記載の計算装置であって、複数のビットレートで前記ビデオデータを再エンコードするために、前記プログラム命令は、前記計算装置に、前記ビデオデータの複数のバージョンを生成するようにさらに指示し、前記ビデオデータの前記複数のバージョンのそれぞれは、前記ビデオデータの前記複数のバージョンの互いに対して異なるビットレートでエンコードされる、計算装置。

【請求項14】

請求項１３に記載の計算装置であって、前記次に利用可能なビットレートで前記ビデオデータをストリーミングするために、前記プログラム命令は、前記計算装置に、前記次に利用可能なビットレートでエンコードされた前記ビデオデータの前記複数のバージョンのうちの異なる１つをストリーミングするように指示する、計算装置。

【請求項15】

請求項１０又は１１に記載の計算装置であって、前記プログラム命令は、前記計算装置に、前記検査データの前記送信に関係なく前記品質が低下することに応答して、前記所与のビットレートでの前記ビデオデータのストリーミングから、より低いビットレートでの前記ビデオデータのストリーミングにスイッチするようにさらに指示する、計算装置。

【請求項16】

請求項１０又は１１に記載の計算装置であって、前記プログラム命令は、前記計算装置に、コネクションレスおよび低信頼トランスポートプロトコルに従って前記ビデオデータをストリーミングするように指示する、計算装置。

【請求項17】

請求項１０又は１１に記載の計算装置であって、前記ビデオデータの前記品質は、前記ビデオデータの前記ストリーミングと関連付けられた１つまたは複数のパフォーマンス測定基準の観点から定義され、前記１つまたは複数のパフォーマンス測定基準は、レイテンシ、ジッタおよびパケット損失を含む、計算装置。

【請求項18】

１つまたは複数のコンピュータ可読記憶媒体と、
前記１つまたは複数のコンピュータ可読記憶媒体に動作可能に結合された処理システムと、
ストリーミングクライアントを動作させるために前記１つまたは複数のコンピュータ可読記憶媒体に格納されたプログラム命令と
を含む計算装置であって、前記プログラム命令は、前記処理システムによって実行されると、前記計算装置に、
複数のビットレートのうちの所与のビットレートでビデオデータのストリームを受信することであって、前記複数のビットレートは、前記ビデオデータのソースで該ビデオデータがエンコードされた初期ビットレートと、前記初期ビットレートの前記ビデオデータが再エンコードされた該初期ビットレートより低いビットレートとを含む、ビデオデータのストリームを受信することと、
前記所与のビットレートでのビデオデータの前記ストリームを受信すると同時に、ビットレートが増加する追加のデータを受信することであって、前記追加のデータは、前記ビデオデータの少なくとも一部の複製を含む、追加のデータを受信することと、
前記ビデオデータと前記追加のデータとの総ビットレートが次に利用可能なビットレートに達する前に、前記ビデオデータの品質の低下が発生することを監視することと、
前記総ビットレートが前記次に利用可能なビットレートに達することに応答して前記次に利用可能なビットレートでの前記ビデオデータのストリームに条件付きでスイッチすることと
を少なくとも行うように指示する、
計算装置。

【請求項19】

請求項１８に記載の計算装置であって、
前記追加のデータのビットレートの増加は、前記総ビットレートが前記次に利用可能なビットレートに達するまでに、前記追加のデータのビットレートの２回以上の増加が発生するように構成され、
前記プログラム命令は、前記処理システムによって実行されると、前記計算装置に、
前記２回以上の増加のうちの何れかにおいて、前記ビデオデータの前記品質の前記低下が品質尺度を満たさないとき、前記所与のビットレートでの前記ビデオデータのストリームの受信を続けること
を少なくとも行うように更に指示する、
計算装置。

【請求項20】

請求項１８又は１９に記載の計算装置であって、前記ビデオデータの前記品質の前記低下を監視するために、前記プログラム命令は、前記計算装置に、前記所与のビットレートでの前記ビデオデータの前記ストリームと関連付けられた１つまたは複数のパフォーマンス測定基準を監視するように指示する、計算装置。

【請求項21】

請求項２０に記載の計算装置であって、前記所与のビットレートでの前記ビデオデータの前記ストリームと関連付けられた前記１つまたは複数のパフォーマンス測定基準は、レイテンシ、ジッタおよびパケット損失を含む、計算装置。

【請求項22】

請求項１８又は１９に記載の計算装置であって、前記プログラム命令は、前記計算装置に、前記所与のビットレートでの前記ビデオデータのストリーミングから、より低いビットレートでの前記ビデオデータのストリーミングに、前記品質の低下に応答してスイッチするように指示する、計算装置。

【請求項23】

請求項１８又は１９に記載の装置であって、前記ビデオデータは、発信元エンドポイントによってキャプチャされた、ゲーミングセッションのビデオを含む、計算装置。

【発明の詳細な説明】

【技術分野】

【0001】

[0001]ビデオストリーミングサービスにより、ユーザは、ソーシャルネットワーク、ゲームプラットフォーム、企業環境などの背景で、他のユーザにライブビデオをストリーミングすることができる。

【背景技術】

【0002】

場合によっては、双方向通信のサポートにより、ビデオの利用者は、コンテンツの創作者とチャットしたり、または、他の方法で対話したりすることができる。したがって、低レイテンシにより、ユーザは、ほぼリアルタイムに通信できるが、逆の場合、遅延が大きくなりすぎて通信が実用的ではなくなることがあるので、レイテンシは、このようなサービスを享受する際の重要な要素である。

【発明の概要】

【発明が解決しようとする課題】

【0003】

[0002]レイテンシは、ストリーミングサービスとそのエンドユーザとの間のネットワークの帯域幅から、エンドユーザにローカルな機器の容量に及ぶ多くの要因の影響を受ける。これらの要因のいずれかに対処しないと、ストリーミングされているビデオのビットレートは、レイテンシの影響を受ける恐れがある。一般に、ビデオのビットレートを上げると、そのレイテンシを増加させることがあり、一方で、ビデオのビットレートを下げると、そのレイテンシを減少させることができる。それでも、ビットレートが高くなると、（ユーザが享受する）ビデオが高解像度になるのと全く同じように、ビットレートが低くなると、フィードの解像度が低くなることがある。

【0004】

[0003]したがって、高解像度ビデオを低レイテンシで提供することの間にトレードオフが存在してきた。ストリーミング技術の中には、レイテンシを維持するために、ビデオのビットレートを動的に上げる、または下げることができるものもある。例えば、ＨＴＴＰライブストリーミング（ＨＬＳ）は、ビデオのショートクリップをクライアントにダウンロードする。クリップを受信するクライアントは、より高いビットレートバージョンのセグメントをダウンロードしようとするための時間を与えるバッファを維持する。成功した場合、クライアントは、より高いビットレートのビデオを再生するが、成功しなかった場合、より低いビットレートのセグメントを選択してダウンロードをキャンセルする。残念ながら、必要なバッファリングを行うと、リアルタイムストリーミングおよび双方向通信のために、非常に多くの遅延を作り出す。

【0005】

[0004]音声およびビデオ通話サービスなど、いくつかのはっきりとしたリアルタイムのサービスは、コネクションレスおよび低信頼（ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ ａｎｄ ｕｎｒｅｌｉａｂｌｅ）プロトコルを利用して、データを送受信する。例は、ユーザデータグラムプロトコル（ＵＤＰ：ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）であり、ＵＤＰにより、パケットの宛先にパケットが到着するかどうか、または、どの順序で到着するかに関わらず、送信者は受信者にパケットを伝送することができる。このようなプロトコルは、低レイテンシ体験を提供することができるが、ジッタおよびパケット損失が発生することがある。

【0006】

[0005]ＵＤＰでビデオを受信するクライアントは、確実に再生が平滑化するように、フィードバックを送信者に提供することができる。次に、送信クライアントは、このようなストリーミングの悪影響のいずれかに立ち向かうために、ビットレートを上下させて調節することができる。これらのストリーマのいくつかは、複数のクライアントに同時に送信することができるが、限られた数のクライアントを超えて拡大させることはできない。

【課題を解決するための手段】

【0007】

[0006]低レイテンシを維持しつつ、エンドポイントへのビデオのストリーミングを最適化するための技術を本明細書で開示する。１つの実装形態では、ストリーミングサービスは、複数のエンドポイントに配信するためのビデオデータを受信する。各エンドポイントに対して、サービスは、所与のビットレートでビデオデータをエンドポイントにストリーミングする。ビデオがストリーミングされている間、サービスは、追加のビットレートで検査データをエンドポイントに送信する。サービスは、ビデオデータの品質の閾値低下が発生するまで、または、ビデオデータと検査データとの総ビットレートが、ビデオデータの、次に利用可能なビットレートに達するまで、検査データの追加のビットレートも上げる。サービスは、総ビットレートが次に利用可能なビットレートに達すると、所与のビットレートでビデオデータをストリーミングすることから、次に利用可能なビットレートでビデオをストリーミングすることに、条件付きでスイッチする。このように、ビデオのビットレートは、低遅延体験を脅かすことなく、安全に上げることができる。

【0008】

[0007]この「課題を解決するための手段」は、「発明を実施するための形態」において下記でさらに説明される概念の選択を単純な形で紹介するために提供する。この「課題を解決するための手段」は、特許請求される主題の主要な特徴または本質的な特徴を識別することを意図するものではなく、特許請求される主題の範囲を限定するために使用されることを意図するものでもないことが理解されよう。

【0009】

[0008]以下の図面を参照すると、本開示の多くの態様をより良く理解することができる。これらの図面と共に、いくつかの実装形態を説明するが、本開示は、本明細書で開示された実装形態に限定されない。逆に、意図は、全ての代替物、変更形態、および均等物を含むことである。

【図面の簡単な説明】

【0010】

【図1】[0009]１つの実装形態における動作環境を示す図である。

【図2】[0010]１つの実装形態におけるストリーミング処理を示す図である。

【図3】[0011]１つの実装形態における動作環境を示す図である。

【図4】[0012]１つの実装形態における動作シナリオを示す図である。

【図5】[0013]１つの実装形態における動作シナリオを示す図である。

【図6】[0014]１つの実装形態におけるシナリオの視覚表現を示す図である。

【図7】[0015]１つの実装形態におけるシナリオの視覚表現を示す図である。

【図8】[0016]１つの実装形態におけるシナリオの視覚表現を示す図である。

【図9】[0017]本明細書で開示される番号提供技術（ｎｕｍｂｅｒ ｐｒｏｖｉｓｉｏｎｉｎｇ ｔｅｃｈｎｏｌｏｇｙ）を実装するのに適したコンピューティングシステムを示す図であり、図面に示され、「発明を実施するための形態」において下記で論じられるアーキテクチャ、環境、要素、処理、ならびに、動作シナリオおよびシーケンスのいずれかを含む図である。

【発明を実施するための形態】

【0011】

[0018]ビデオストリーミングを強化するための技術を本明細書で開示する。様々な実装形態では、ストリーミングサービスは、複数のエンドポイントにストリーミングされることになるビデオデータを受信する。サービスは、最適なストリーミング体験を提供するために、必要に応じてストリーム間でスイッチできるように、異なるビットレートでビデオをエンコードする。それでも、特定のビットレートがサポートされるかどうかを確かめるために、サービスは、初期ビットレートでビデオをエンドポイントに同様にストリーミングしつつ、検査データを所与のエンドポイントに最初に送信する。

【0012】

[0019]ビデオがストリーミングされると、サービスは、検査データのビットレートおよび本来のストリームのビットレートが、ビデオの他のバージョンの次に利用可能なビットレートを満たすか、超えるポイントまで、検査データを漸増的に増加させる。本来のストリームの品質がこの時点で劣化していない（または、過度に劣化していない）場合、ストリーミングサービスは、次に利用可能なビットレートでエンコードされたビデオストリームにスイッチする。品質が閾値量を低下させたが、検査データが増加しつつある場合、サービスは、ビデオがストリーミングされている現在のビットレートを維持する。

【0013】

[0020]ストリーミング品質は、レイテンシ、パケット損失、およびジッタなどの、いくつかの基準値の１つまたは複数を使用して、評価することができる。例えば、エッジサーバまたは同様のものといった、ストリーミングサービス内の要素は、ビデオストリームの受信エンドにあるクライアントによって要素にフィードバックされた基準値に基づいて、このような判定を行うことができる。それでも、ストリーミング品質は、クライアントアプリケーションによって同様に評価することができる。したがって、クライアントは、品質が維持されていること、もしくは劣化してきたことをサービスにレポートすることができ、または、任意選択として、クライアントは、（検査データを増加させても品質が十分であったと仮定して）より高いビットレートのストリームをリクエストすることさえもできる。

【0014】

[0021]ビデオのビットレートを下げることも可能である。ストリーミングサービスは、例えば、ネットワーク条件（レイテンシ、ビットレート、ジッタ等）が、どの検査データにも関係なく、品質の低下を示す場合、より低いビットレートでエンコードされたビデオのバージョンにスイッチすることができる。すなわち、ストリーミング品質は、どの検査データもセットされていなくても、低下することがある。サービスは、送信されている現在のバージョンより低いビットレートでエンコードされたビデオのバージョンのうちの１つに応答的にスイッチすることができる。

【0015】

[0022]いくつかの実装形態では、ストリーミングサービスは、様々なビットレートで一度だけ、ビデオをエンコードすることが必要である。次に、ビデオをエンドポイントに最終的に伝送するサーバに、異なるビットレートの異なるバージョンのビデオをサービス内で配信する。このように、エンドポイントへのビデオの送信を担当するサーバは、様々なビットレートでビデオをエンコードするのに必要な処理オーバヘッドを負担する必要がない。

【0016】

[0023]レイテンシへの有害な影響を軽減しつつ、ビデオのビットレートを上げる能力を含む様々な技術的効果を、前述および以下の議論から認識することができる。これは、ゲーマとそのファンとの間の双方向対話を伴う「ライブ」ゲーム体験など、遅延の影響を受けやすい体験の背景で特に有益になり得る。別の例では、ユーザは、ソーシャルネットワークを介して多くのユーザにビデオを伝送することを望むことがある。両方のケースにおいて、低レイテンシにより、ユーザは、高解像度のビデオストリームの恩恵を依然として享受しつつ、リアルタイムに、または、ほぼリアルタイムに、双方向に通信することができる。

【0017】

[0024]図１は、１つの実装形態における動作環境１００を示す。動作環境１００は、ストリーミングサービス１０１、ならびに、エンドポイント１０５、１１１、１１２、および１１３を含む。ストリーミングサービス１０１は、データセンタ１０３で表された１つまたは複数のデータセンタ（物理または仮想）に、および、図９のコンピューティングシステム９０１が代表的な１つまたは複数のコンピューティングシステム上に、実装することができる。

【0018】

[0025]ストリーミングサービス１０１は、１つまたは複数のエンドポイントからビデオ（および任意選択として他のコンテンツ）を受信し、ユーザ利用のために、ビデオ（および任意選択として他のコンテンツ）を１つまたは複数の他のエンドポイントに伝送する。エンドポイント１０５は、ストリーミングサービス１０１にビデオをストリーミングすることができる様々なコンピューティングデバイスの代表的なものであり、一方、エンドポイント１１１、１１２、および１１３は、ストリーミングサービス１０１がビデオデータをストリーミングし得るコンピューティングデバイスの代表的なものである。例は、ラップトップおよびデスクトップコンピュータ、タブレット、携帯電話、ウェアラブルデバイス、エンターテイメントデバイス、ゲーム機、他のサーバコンピュータ、モノのインターネット（ＩｏＴ）デバイス、または他の任意のタイプのデバイスを含むがこれらに限定されない。ストリーミングサービス１０１は、１つもしくは複数の通信ネットワーク（例えばインターネット）、ネットワークの組合せ、またはその変形形態で、エンドポイント１０５、１１１、１１２、および１１３と通信する。

【0019】

[0026]ストリーミングサービス１０１は、ビデオストリームの受信、エンコード、送信、およびビデオストリーム間のスイッチを行うとき、ストリーミング処理２００を用いる。図２を参照すると、ストリーミング処理２００は、サーバ、スイッチ、およびルータなど、ストリーミングサービス１０１の様々な要素の中で配布されるソフトウェアアプリケーション、モジュール、構成要素、または他のこのようなプログラミング要素のいずれかの背景で、プログラム命令に実装することができる。プログラム命令は、以下のように動作するように、基礎をなす１つまたは複数の物理または仮想コンピューティングシステムに指図し、図１の動作環境１００の背景における図２のステップをついでに参照する。

【0020】

[0027]初めに、エンドポイント１０５は、ストリーミングサービス１０１にビデオデータ１３１を伝送する。ストリーミングサービス１０１は、ビデオストリームを受信し、それぞれ異なるビットレートで複数のストリーム内のビデオデータをエンコードする（ステップ２０１）。すなわち、エンドポイント１０５から所与のビットレートで１つのビデオフィードを受信し、ストリーミングされているビデオデータを抽出するためにデコードする。次に、ビデオデータは、本来のビデオストリームの複数のバージョンを生み出すために、複数回、再エンコードされる。複数のバージョンのそれぞれは、ビデオストリームの複数のバージョンの互いに対して異なるビットレートでエンコードされる。

【0021】

[0028]次に、ストリーミングサービス１０１は、エンドポイント１１１、エンドポイント１１２、およびエンドポイント１１３にビデオストリームの１つまたは複数を送信する（ステップ２０３）。１つまたは複数のビデオストリームは、ＵＤＰなどのコネクションレスおよび低信頼トランスポートプロトコル、カスタムもしくは独自のプロトコル、または同様のものを介して送信される。

【0022】

[0029]所与のエンドポイントの観点からすると、ただ１つのストリームがそのエンドポイントに送信されるが、同じストリームが、エンドポイントの２つ以上に送信されてもよい。エンドポイント１１１、１１２、および１１３は、ビデオストリームを受信し、ユーザ１２１、１２２、および１２３のためにビデオストリームをそれぞれ再生する。エンドユーザは、任意選択として、ユーザ１２５とチャットすること、またはそうでなければ、参加することを要望することができる。したがって、エンドポイント１０５に転送されるように、ストリーミングサービス１０１にリターンコンテンツ１３５を送信することができるが、ストリーミングサービス１０１を全面的に迂回してもよい。これは、例えば、エンドポイント１１１、１１２、および１１３といった他の参加しているエンドポイントにエンドポイント１０５から「ブロードキャスト」された、例えばユーザ１２５によってホストされたゲームセッションの背景で発生し得る。

【0023】

[0030]所与のエンドポイントに送信された各ストリームは、ストリーミングサービス１０１からエンドポイントに、初期ビットレートでストリーミングされる（ステップ２０３）。これは、エンドポイント１０５からビデオを受信したときの同じビットレートであってもよい。それでも、これは、他のエンコードされたストリームのうちの異なる１つ、およびしたがって、他のビットレートのうちの１つであってもよい。ビデオは、エンドポイントにストリーミングされ、各エンドポイントは、ビデオをデコードし、再生する。

【0024】

[0031]所与のビデオストリームおよびエンドポイントについて、ストリーミングサービス１０１は、ビデオストリームと実質的に同時に、追加のビットレートで検査データをエンドポイントに送信し始める（ステップ２０５）。検査データは、エンドポイントによって無視され、放棄されてもよい「ノイズ」であってもよい。場合によっては、検査データは、ビデオストリームの複製であってもよく、これにより、ビデオストリームのパケットのいくつかが失われても、伝送の堅牢性を向上させることさえもある。いくつかの実装形態では、複製データは、ビデオストリームの複製であることを示すためにセットされたフラグを付けて送信することができる。フラグは、例えば、ビデオストリームを含むパケットのヘッダ部分にセットすることができる。このようなフラグまたは他のこのような指示により、ビデオを再生するクライアントは、複製を放棄するか、そうでなければ無視することが可能になり得る。

【0025】

[0032]ストリーミングサービス１０１は、より高い帯域幅のバージョンのビデオがサポートされ得るかどうかを確かめるために、検査データが送信されている間（またはその後）、ビデオストリーム品質を監視する。サービスは、検査データに応答して、品質の閾値低下が発生したかどうかを確かめる（ステップ２０９）。閾値低下は、レイテンシの増加、パケット損失の増加、ジッタの増加、または同様のものなど、１つまたは複数の品質基準値の観点から定義することができる。ストリーミングサービス１０１は、エンドポイントにあるクライアントからこのような基準値を取得するので、基準値を追跡し、レポートすることができる。いくつかの実装形態では、クライアントは、品質の閾値低下を監視し、個々の基準値をレポートするのではなく（または個々の基準値をレポートすることに加えて）、ストリーミングサービス１０１に低下をレポートする。

【0026】

[0033]閾値品質低下が発生した場合、ストリーミングサービス１０１は、現在のビットレートでビデオをストリーミングし続けることを決定する。サービスは、任意選択として、帯域幅を検査し続けてもよいが、少なくとも一定期間、さらなるデータを中止してもよい。それでも、ビデオストリーム品質が閾値低下を受けなかった場合、ストリーミングサービス１０１は、総ビットレート（追加のビットレートと現在のビットレートの合計）が、ビデオデータをエンコードした次に利用可能なビットレートに等しいか、これを超えたか、またはそうでなければ、これに近いかを判定する（ステップ２１１）。例えば、１ｍｂ／ｓ、３ｍｂ／ｓ、および５ｍｂ／ｓでビデオがエンコードされており、現時点で、１ｍｂ／ｓでストリーミングされていると仮定する。この場合、ストリーミングサービス１０１は、検査データのビットレートと現在のビットレート（１ｍｂ／ｓ）の合計が、３ｍｂ／ｓを満たすか、超えるか、またはそうでなければ、これに近いかを判定する。

【0027】

[0034]そうである場合、ストリーミングサービス１０１は、次に利用可能なビットレートでエンコードされたビデオデータにストリームをスイッチする（ステップ２１３）。それでも、現在のビットレートと次に利用可能なビットレートとの間に余地がある場合、ストリーミングサービスは、検査データのビットレートを上げ（ステップ２０７）、ストリームの品質を評価し続ける。したがって、検査データのビットレートは、品質が急激に低下するか、次に利用可能なビットレートに達するポイントまで漸増的に上げることができ、このポイントで、ストリームは、次に利用可能なビットレートでエンコードされたストリームにスイッチすることができる。

【0028】

[0035]図３は、別の実装形態における動作環境３００を示す。動作環境３００は、ストリーミングサービス３０１を含み、ストリーミングサービス３０１は、ゲームセッション、ソーシャルネットワーク活動、ビデオ会議などの背景にあるエンドポイントに、ビデオストリーミングサービスを提供する。一般に、エンドポイントは、ストリーミングサービス３０１にビデオストリームを送信し、次に、ビデオストリームはデコードされ、異なるビットレートを有する複数のビデオストリームにエンコードされる。ストリーミングサービス３０１は、様々なビデオストリームをエンドポイントに送信し、送信しているときに、より低いビットレートとより高いビットレートとの間でスイッチして、ユーザの体感を最適化する。

【0029】

[0036]より具体的には、ストリーミングサービス３０１は、ストリーミングサービスをエンドポイントに提供するように互いに機能する様々な要素を含む。エンコーダ３０２は、エンドポイントからビデオストリームを受信し、ビデオストリームをデコードし、ビデオストリームを再エンコードして、互いに対して異なるビットレートを有する複数のストリームにする。中継サーバ３０４および３０５はそれぞれ、ストリームのコピーを受信し、ストリームのコピーをエッジサーバ３０６、３０７、３０８、および３０９に送信する。この実装形態では、エッジサーバ３０６は、エンドポイント３１１にビデオトラフィックを送信し、エッジサーバ３０７は、エンドポイント３１３にビデオトラフィックを送信し、エッジサーバ３０８は、エンドポイント３１７にビデオトラフィックを送信し、エッジサーバ３０９は、エンドポイント３１７にトラフィックを送信する。

【0030】

[0037]各エッジサーバは、複数のストリームのどれが、いずれか１つのエンドポイントに送信されるかを決定するストリーミング処理（例えばストリーミング処理２００）を実装する。ストリーミング処理は、図９のコンピューティングシステム９０１が代表的な各エッジサーバの様々な要素に配置されるソフトウェアアプリケーション、モジュール、コンポーネント、または他のこのようなプログラミング要素のいずれかの背景でプログラム命令に実装することができる。

【0031】

[0038]図示のように、各エッジサーバは、凡例３１０で示したような、互いに対して異なるビットレートでそれぞれエンコードされた、ストリーミングされることになるビデオの複数のバージョンを受信する。次に、１度に１つのバージョンが、個々のいずれかのエンドポイントにストリーミングされる。検査データも、エンドポイントに伝送され、より高いビットレートバージョンのビデオストリームをサポートできるかどうかについてエッジサーバが確かめることを可能にする。サポートできる場合、エッジサーバは、より高いビットレートバージョンにスイッチするが、サポートできない場合、エッジサーバは、現在のビットレートでストリーミングし続ける。場合によっては、エッジサーバは、ストリーミング品質が落ちた場合、ビットレートを下げることができ、これにより、検査データの送信とは別々にかつ独立して発生させることができる。

【0032】

[0039]図４は、図３の動作環境３００についての実装形態における動作シナリオを示す。動作中、エンドポイント３２１は、ローカル体験のビデオをエンコーダ３０２にストリーミングする。ローカル体験は、例えば、エンドポイント３２１で再生されるゲーム体験、エンドポイント３２１もしくは周辺デバイスによってキャプチャされたシーンのライブビデオフィード、ビデオ会議、または、ビデオでキャプチャされ得る他の任意のコンテンツであってもよい。

【0033】

[0040]エンドポイント３２１がビデオをエンコードしたと仮定すると、エンコーダ３０２は、ビデオをデコードし始め、次に、複数のビットレートでビデオを再エンコードする。エンコーダ３０２は、ビデオの複数のバージョンを中継サーバ３０４に送信し、中継サーバ３０４は、次に、この実例のシナリオではエッジサーバ３０６を含む、１つまたは複数のエッジサーバにビデオを中継する。

【0034】

[0041]エッジサーバ３０６は、ビットレートのうちの１つでエンドポイント３１１Ａにビデオをストリーミングし、同様に、同じまたは異なるビットレートでエンドポイント３１１Ｂにビデオをストリーミングする。例示のために、当初、ビデオが１ｍｂ／ｓでストリーミングされると仮定する。エンドポイント３１１Ａおよび３１１Ｂは、エンドポイントのそれぞれのビデオストリームを受信し、ビデオストリームをエンドポイントのユーザに対して再生する。ユーザの１人または複数は、任意選択として、ゲーム、ソーシャルネットワーク、または他のこのような体験の増進のために、エンドポイント３２１と直接的または間接的に交換することができる、例えばチャットメッセージといった、ユーザ入力によってエンドポイント３２１に関連付けられたユーザと関わり合うことができる。

【0035】

[0042]エッジサーバ３０６は、実現可能であれば、それぞれのビデオストリームのビットレートを上げるために、ストリーミング処理２００を用いて、エッジサーバ３０６とエンドポイントの間のネットワークリンクの堅牢性を測る。この目標の増進のために、エッジサーバ３０６は、増分を増やしながら、検査データをエンドポイント３１１Ａに送信する。エンドポイント３１１Ａは、検査データを受信するとビデオストリームのパフォーマンスを測定し、エッジサーバ３０６にフィードバックを送る。フィードバックは、例えば、ビデオのレイテンシ、パケット損失、および／またはジッタを示すことができる。これらの基準値の代わりに（または、これらの基準値に加えて）、キーフレーム損失の指示、ビデオの知覚品質等などの他の基準値も、フィードバックに含めることができる。

【0036】

[0043]エッジサーバ３０６は、フィードバックを受信し、ビデオストリーム品質が品質尺度を満たしているかどうかを判定する。品質尺度は、フィードバック内のパフォーマンス測定基準値のいずれかの１つまたは複数に関するものであってもよい。例えば、品質尺度は、最低限受入れ可能な量のレイテンシ、パケット損失、もしくはジッタ、または、基準値のいずれか２つ以上から導出された合成値であってもよい。検査データは、フィードバックの各セットを受信した後、品質が最小値を満たさなくなるまで、または、現在のビットレートおよび検査のビットレートがともに、次に利用可能なビットレートに達するまで、増分される。例示のために、次に利用可能なビットレートに達し、したがって、３ｍｂ／ｓのビデオフィードが、エンドポイント３１１Ａにストリーミングされると仮定する。

【0037】

[0044]エンドポイント３１１Ｂについて、同じ処理がエッジサーバ３０６によって行われる。処理は、順次起こるものとして図４に示されていても、エンドポイント３１１Ａと実質的に同時にエンドポイント３１１Ｂに対して発生してもよい。

【0038】

[0045]エッジサーバ３０６は、増分を増やしながら、検査データをエンドポイント３１１Ｂに送信する。エンドポイント３１１Ｂは、検査データを受信すると、ビデオストリームのパフォーマンスを測定し、エッジサーバ３０６にフィードバックを送る。エッジサーバ３０６は、フィードバックを受信し、ビデオストリーム品質が品質尺度を満たしているかどうかを判定する。検査データは、フィードバックの各セットを受信した後、品質が最小値を満たさなくなるまで、または、現在のビットレートおよび検査のビットレートがともに、次に利用可能なビットレートに達するまで、増分される。例示のために、次に利用可能なビットレートに達し、したがって、３ｍｂ／ｓのビデオフィードが、エンドポイント３１１Ｂにストリーミングされると仮定する。

【0039】

[0046]エッジサーバ３０６は、５ｍｂ／ｓのビットレートバージョンのビデオが残っているので、エンドポイント３１１Ａおよび３１１Ｂの１つまたは両方に対してストリーミング処理２００を用い続けることができる。したがって、エッジサーバ３０６は、漸増的に上げたレートで検査データを送信し続け、フィードバックを受信し、増加させた量の検査データに対する３ｍｂ／ｓのビデオフィードの品質レスポンスに基づいて、可能であれば、５ｍｂ／ｓのフィードにスイッチすることができる。

【0040】

[0047]図５は、図４と同じシナリオを示すが、エンドポイント３１１Ａは、より高いビットレートのビデオフィードにアップグレードするべきかどうかを判定する。動作中、エンドポイント３２１は、ローカル体験のビデオをエンコーダ３０２にストリーミングする。ローカル体験は、例えば、エンドポイント３２１で再生されるゲーム体験、エンドポイント３２１もしくは周辺デバイスによってキャプチャされたシーンのライブビデオフィード、ビデオ会議、または、ビデオでキャプチャされ得る他の任意のコンテンツであってもよい。

【0041】

[0048]エンコーダ３０２は、ビデオをデコードし始め、次に、複数のビットレートでビデオを再エンコードする。エンコーダ３０２は、ビデオの複数のバージョンを中継サーバ３０４に送信し、中継サーバ３０４は、次に、この実例のシナリオではエッジサーバ３０６を含む、１つまたは複数のエッジサーバにビデオを中継する。

【0042】

[0049]エッジサーバ３０６は、ビットレートのうちの１つでエンドポイント３１１Ａにビデオをストリーミングし、同様に、同じまたは異なるビットレートでエンドポイント３１１Ｂにビデオをストリーミングする。例示のために、当初、ビデオが１ｍｂ／ｓでストリーミングされると仮定する。エンドポイント３１１Ａおよび３１１Ｂは、エンドポイントのそれぞれのビデオストリームを受信し、ビデオストリームをエンドポイントのユーザに対して再生する。ユーザの１人または複数は、任意選択として、ゲーム、ソーシャルネットワーク、または他のこのような体験の増進のために、エンドポイント３２１と直接的または間接的に交換することができる、例えばチャットメッセージといった、ユーザ入力によってエンドポイント３２１に関連付けられたユーザと関わり合うことができる。

【0043】

[0050]次に、エンドポイント３１１Ａは、エッジサーバ３０６から検査データをリクエストする。代替として、エッジサーバ３０６は、エンドポイント３１１Ａに検査データを自動的および／または定期的に送信するようにプログラムすることができる。エンドポイント３１１Ａは、検査データを受信し、検査データに対する初期ビデオフィードの品質レスポンスを評価する。ビデオフィードの品質が十分なままである場合、エンドポイント３１１Ａは、検査データのビットレートを上げるために、エッジサーバ３０６にリクエストを送信する。

【0044】

[0051]エッジサーバ３０６は、リクエストに従って、増加させた量の検査データをエンドポイント３１１Ａに送信する。エンドポイント３１１Ａは、検査データを再び受信し、初期ビデオフィードの品質レスポンスを評価する。品質が高いままであり、エンドポイント３１１Ａが、検査データの増分の増加を再びリクエストすると仮定する。

【0045】

[0052]エッジサーバ３０６は、さらに上げたビットレートで、より多くの検査データを送信する。エンドポイント３１１Ａは、増加させた検査データを受信し、ビデオフィードの品質が十分であり続けることに応答して、次に利用可能なビットレートにスイッチすることをエッジサーバ３０６にリクエストする。したがって、エッジサーバ３０６は、３ｍｂ／ｓのバージョンのビデオをエンドポイント３１１Ａに送信する。

【0046】

[0053]５ｍｂ／ｓのバージョンのビデオが残っているので、エンドポイント３１１Ａがこのような処理を続けることができることを認識することができる。さらに、エンドポイント３１１Ｂも、受信するビデオフィードに対して、同じ処理をローカルに用いることができる。

【0047】

[0054]図６～図８は、本明細書で開示したビデオストリーミング技術のいくつかの態様をより良く説明するための様々な動作シナリオを示す。図６では、グラフ６００は、Ｘ軸（時間）に対して示された２つのｙ軸（ビットレートおよび品質）を含む。左のＹ軸上には、動作環境３００においてエンコーダからエンドポイントに送信したビデオストリームのエンコードしたビットレートを示す。右のＹ軸上には、品質の向上、および品質の低下の観点から、ビデオストリーム品質を示す。最終的に、メインビデオストリームのビットレート、送信されている検査データのビットレート、および、（品質が向上しているか、低下しているか、同じままであるかを示す）メインビデオストリームの相対的な品質、という３つの線をグラフ化する。

【0048】

[0055]図示のように、ビデオストリームのビットレートは、当初、３ｍｂ／ｓであり、その品質は、高いと考えられる。時間が進むと、検査データが１ｍｂ／ｓで導入される。ビデオをストリーミングし、データを送信するエッジサーバは、ストリーミング品質が検査データにどのように反応するかを監視する。ここで、品質は維持され、エッジサーバは、ストリームの追加のビットレートと現在のビットレートを合計する。合計は４ｍｂ／ｓであり、次に利用可能なビットレート（５ｍｂ／ｓ）より低いので、エッジサーバは、この例では検査データのビットレートを１．５ｍｂ／ｓまで増分させるが、増分は、これより小さくても、大きくてもよい。

【0049】

[0056]検査データが増加されると、エッジサーバは、追加されたトラフィックに対する品質レスポンスを測る。ここで、品質は強固なままである。さらに、追加のビットレートと現在のビットレートの合計は、まだ、次に利用可能なビットレートより低い。したがって、エッジサーバは、追加のビットレートを２ｍｂ／ｓまで増分させる。この時点で、品質はまだ低下しておらず、現在のビットレートと追加のビットレートの和が、次に利用可能なビットレート（５ｍｂ／ｓ）に等しいので、エッジサーバは、５ｍｂ／ｓでエンコードされたバージョンにストリームをスイッチする。したがって、より高いビットレートのビデオは、より低いビットレートに下げることをトリガするポイントまでビデオの品質が低下している間、または任意選択として、ビデオの品質が低下するまで、エンドポイントにストリーミングされる。

【0050】

[0057]図７では、グラフ７００は、同じｘ軸およびｙ軸を含む。ビデオストリームのビットレートは、当初、３ｍｂ／ｓであり、その品質は高い。時間が進むと、検査データが１ｍｂ／ｓで導入される。ビデオをストリーミングし、データを送信するエッジサーバは、ストリーミング品質が検査データにどのように反応するかを監視する。この例では、品質は維持され、エッジサーバは、ストリームの追加のビットレートと現在のビットレートを合計する。合計は４ｍｂ／ｓであり、次に利用可能なビットレート（５ｍｂ／ｓ）より低いので、エッジサーバは、この例では検査データのビットレートを１．５ｍｂ／ｓまで増分させるが、増分は、これより小さくても、大きくてもよい。

【0051】

[0058]検査データを増加させると、エッジサーバは、増加に対するビデオストリーム品質を監視する。例示のために、品質が閾値量を超えて低下すると仮定する。品質低下は、より高いビットレートをサポートできないことを示す。検査データは停止され、別の品質低下が、そのビットレートの低下を引き起こす間、または任意選択として、引き起こすまで、ビデオストリームはその初期ビットレートで維持される。エッジサーバをエンドポイントに接続するネットワークの、より高いビットレートをサポートする能力を測るために、検査データを後で再び再導入することができる。

【0052】

[0059]図８のグラフ８００も、時間、ビットレート、および品質について、図６～図７と同じｘ軸およびｙ軸を含む。動作中、エッジサーバは、第１のビットレート（１ｍｂ／ｓ）でエンドポイントにビデオストリームを伝送する。エッジサーバは、本来のビデオストリームの品質を監視しつつ、０．５ｍｂ／ｓでエンドポイントに検査データを送信し始める。品質の低下が発生せず、初期ビットレートと追加のビットレートの合計（１．５ｍｂ／ｓ）が、次に利用可能なビットレート（３ｍｂ／ｓ）に達していないので、エッジサーバは、検査データを増加させる。

【0053】

[0060]検査データが１．５ｍｂ／ｓまで上がると、本来のビデオ信号の品質は低下する。それでも、低下は、検査データへの増分の増加を停止するのに足りるほど十分ではない。むしろ、品質は、受入れ可能であると判断される。したがって、検査データのビットレートは、２ｍｂ／ｓまで再び上げられ、３ｍｂ／ｓまでの総ビットレートをもたらす。

【0054】

[0061]この時点で、ビットレートの合計は、次に利用可能なビットレートに達しており、エッジサーバは、３ｍｂ／ｓのフィードにストリームを、応答してスイッチする。エッジサーバも、エンドポイントおよび／またはその間のネットワークリンクが、５ｍｂ／ｓという次に利用可能なビットレートに対応できるかどうかを確かめるために、検査データを送信し続ける。例示のために、追加のビットレートを１ｍｂ／ｓから、エッジサーバが５ｍｂ／ｓでエンコードされたデータにビデオストリームをスイッチするポイントである２ｍｂ／ｓに上げたので、品質は十分なままであると仮定する。

【0055】

[0062]図９は、コンピューティングシステム９０１を示し、コンピューティングシステム９０１は、本明細書で開示した様々なアプリケーション、サービス、シナリオ、および処理が実装され得る任意のシステム、またはシステムの集合体の代表的なものである。コンピューティングシステム９０１の例は、サーバコンピュータ、ラックサーバ、ウェブサーバ、クラウドコンピューティングプラットフォーム、およびデータセンタ機器、ならびに、他の任意のタイプの物理または仮想サーバマシン、コンテナ、および、その任意の変形形態または組合せを含むがこれらに限定されない。他の例は、スマートフォン、ラップトップコンピュータ、タブレット型コンピュータ、デスクトップコンピュータ、ハイブリッドコンピュータ、ゲームマシン、仮想現実デバイス、スマートテレビ、スマートウォッチ、および他のウェアラブルデバイス、ならびに、その任意の変形形態または組合せを含むことができる。

【0056】

[0063]コンピューティングシステム９０１は、単一の装置、システム、もしくはデバイスとして実装することができ、または、複数の装置、システム、もしくはデバイスとして分散させて実装することができる。コンピューティングシステム９０１は、処理システム９０２、記憶システム９０３、ソフトウェア９０５、通信インターフェースシステム９０７、およびユーザインターフェースシステム９０９を含むがこれらに限定されない。処理システム９０２は、記憶システム９０３、通信インターフェースシステム９０７、およびユーザインターフェースシステム９０９と動作可能に結合される。

【0057】

[0064]処理システム９０２は、記憶システム９０３からソフトウェア９０５をロードし、実行する。ソフトウェア９０５は、ストリーミング処理９０６を含み、ストリーミング処理９０６は、ストリーミング処理２００を含む、先行する図１～図８について論じた処理の代表的なものである。ビデオストリーミングを強化するために処理システム９０２によって実行されると、ソフトウェア９０５は、前述の実装形態で論じた少なくとも様々な処理、動作シナリオ、およびシーケンスについて、本明細書で説明したように動作することを処理システム９０２に指示する。コンピューティングシステム９０１は、任意選択として、簡潔さのために論じていない追加のデバイス、特徴、または機能を含むことができる。

【0058】

[0065]まだ図９を参照すると、処理システム９０２は、記憶システム９０３からソフトウェア９０５を検索し、実行するマイクロプロセッサおよび他の回路機器を備えることができる。処理システム９０２は、単一の処理デバイス内に実装してもよいが、プログラム命令を実行しながら協働する複数の処理デバイスまたはサブシステムにわたって分散させてもよい。処理システム９０２の例は、汎用中央処理装置、特定用途向けプロセッサ、および論理デバイス、ならびに、他の任意のタイプの処理デバイス、組合せ、またはその変形形態を含む。

【0059】

[0066]記憶システム９０３は、処理システム９０２によって読むことができ、ソフトウェア９０５を格納することができる任意のコンピュータ可読記憶媒体を備えることができる。記憶システム９０３は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の格納のための任意の方法または技術で実装された、揮発性および不揮発性の、取外し可能および取外し不能な媒体を含むことができる。記憶媒体の例は、ランダムアクセスメモリ、リードオンリメモリ、磁気ディスク、光ディスク、フラッシュメモリ、仮想メモリおよび非仮想メモリ、磁気カセット、磁気テープ、磁気ディスク記憶デバイスもしくは他の磁気記憶デバイス、または他の適切な記憶媒体を含むが、伝搬信号を除く。コンピュータ可読記憶媒体が、伝搬信号であることは決してない。

【0060】

[0067]コンピュータ可読記憶媒体に加えて、いくつかの実装形態では、記憶システム９０３は、ソフトウェア９０５のうちの少なくともいくつかを内部または外部で通信することができるコンピュータ可読通信媒体も含むことができる。記憶システム９０３は、単一の記憶デバイスとして実装してもよいが、互いに対して同じ場所に配置されるか、分散された複数の記憶デバイスまたはサブシステムにわたって実装してもよい。記憶システム９０３は、処理システム９０２または場合によっては他のシステムと通信することができる、コントローラなどの追加の要素を備えることができる。

【0061】

[0068]ソフトウェア９０５は、プログラム命令に実装することができ、数ある機能の中でも、処理システム９０２によって実行されると、本明細書で示した様々な動作シナリオ、シーケンス、および処理について説明したように動作することを処理システム９０２に指示することができる。例えば、ソフトウェア９０５は、ストリーミング処理２００を実装するためのプログラム命令を含むことができる。

【0062】

[0069]具体的には、プログラム命令は、本明細書で説明した様々な処理および動作シナリオを実行するために協働するか、そうでなければ対話する、様々なコンポーネントまたはモジュールを含むことができる。様々なコンポーネントまたはモジュールは、コンパイルされるか、翻訳された命令に、または、命令の他のいくつかの変形形態もしくは組合せに含めることができる。様々なコンポーネントまたはモジュールは、同期式もしくは非同期式に、連続的もしくは並行に、シングルスレッド環境もしくはマルチスレッド環境で、または、他の任意の適切な実行パラダイム、変形形態、もしくはその組合せに従って実行することができる。ソフトウェア９０５は、ストリーミング処理９０６に加えて、またはストリーミング処理９０６を含む、オペレーティングシステムソフトウェア、仮想マシンソフトウェア、または他のアプリケーションソフトウェアなど、追加の処理、プログラム、またはコンポーネントを含むことができる。ソフトウェア９０５は、処理システム９０２によって実行可能なファームウェア、または機械可読処理命令のいくつかの他の形式も含むことができる。

【0063】

[0070]一般に、ソフトウェア９０５は、処理システム９０２にロードされ、実行されると、（コンピューティングシステム９０１が代表的な）適切な装置、システム、またはデバイスを、汎用コンピューティングシステムから、ビデオをストリーミングするようにカスタマイズされた専用コンピューティングシステムに全体的に変換することができる。実際は、記憶システム９０３上でソフトウェア９０５をエンコードすると、記憶システム９０３の物理構造を変換することがある。物理構造の特定の変換は、この説明の異なる実装形態における様々な要因に依存し得る。このような要因の例は、記憶システム９０３の記憶媒体を実装するために使用される技術、コンピュータ記憶媒体が１次記憶とみなされるか、２次記憶とみなされるか、ならびに他の要因を含むことができるがこれらに限定されない。

【0064】

[0071]例えば、コンピュータ可読記憶媒体が半導体ベースのメモリとして実装される場合、ソフトウェア９０５は、プログラム命令が半導体メモリの中でエンコードされるとき、半導体メモリの構成要素となるトランジスタ、キャパシタ、または他のディスクリート回路素子の状態を変換することなどによって、半導体メモリの物理状態を変換することがある。類似の変換は、磁気媒体または光媒体に対して発生し得る。本説明の範囲から逸脱することなく、物理媒体の他の変換が可能であり、前述の例は、本議論を容易にするためだけに提供される。

【0065】

[0072]通信インターフェースシステム９０７は、他のコンピューティングシステム（図示せず）と通信ネットワーク（図示せず）で通信することを可能にする通信接続およびデバイスを含むことができる。相互システム通信をともに可能にする接続およびデバイスの例は、ネットワークインターフェースカード、アンテナ、電力増幅器、ＲＦ回路機器、トランシーバ、および他の通信回路機器を含むことができる。接続およびデバイスは、金属、ガラス、空気、または他の任意の適切な通信媒体など、他のコンピューティングシステムまたはシステムのネットワークと通信を交換するための通信媒体で通信することができる。前述の媒体、接続、およびデバイスは、よく知られており、ここで詳細に論じる必要はない。

【0066】

[0073]ユーザインターフェースシステム９０９は任意選択であり、キーボード、マウス、音声入力デバイス、ユーザからのタッチジェスチャを受信するためのタッチ入力デバイス、ユーザによる非タッチジェスチャおよび他の動きを検出するための運動入力デバイス、ならびに、ユーザからユーザ入力を受信することができる他の同等の入力デバイスおよび関連付けられた処理要素を含むことができる。ディスプレイ、スピーカ、触感デバイス、および他のタイプの出力デバイスなどの出力デバイスも、ユーザインターフェースシステム９０９に含めることができる。場合によっては、入出力デバイスは、画像を表示し、タッチジェスチャを受信することができるディスプレイなどの単一のデバイスに組み合わせることができる。前述のユーザ入出力デバイスは、当技術分野でよく知られており、ここで詳細に論じる必要はない。

【0067】

[0074]ユーザインターフェースシステム９０９は、上記で論じた様々なユーザ入出力デバイスをサポートした、処理システム９０２によって実行可能な、関連付けられたユーザインターフェースソフトウェアも含むことができる。別々に、または、互いに、ならびに他のハードウェアおよびソフトウェア要素と共に、ユーザインターフェースソフトウェアおよびユーザインターフェースデバイスは、グラフィカルユーザインターフェース、自然のユーザインターフェース、または他の任意のタイプのユーザインターフェースをサポートすることができる。

【0068】

[0075]コンピューティングシステム９０１と他のコンピューティングシステム（図示せず）との間の通信は、１つまたは複数の通信ネットワークで、また、様々な通信プロトコル、プロトコルの組合せ、またはその変形形態に従って発生し得る。例は、イントラネット、インターネット（ｉｎｔｅｒｎｅｔ）、インターネット（ｔｈｅ Ｉｎｔｅｒｎｅｔ）、ローカルエリアネットワーク、広域ネットワーク、ワイヤレスネットワーク、有線ネットワーク、仮想ネットワーク、ソフトウェア定義ネットワーク、データセンタバス、コンピューティングバックプレーン、または他の任意のタイプのネットワーク、ネットワークの組合せ、もしくはその変形形態を含む。前述の通信ネットワークおよびプロトコルは、よく知られており、ここで詳細に論じる必要はない。

【0069】

[0076]図に示された機能ブロック図、動作シナリオおよびシーケンス、ならびに流れ図は、本開示の斬新な態様を実施するための例示的なシステム、環境、および方法の代表的なものである。説明の簡潔さのために、本明細書に含まれる方法は、機能図、動作シナリオもしくはシーケンス、または流れ図の形であることがあり、一連の行為として説明されることもあるが、方法は、本明細書で示され、説明された他の行為とは異なる順序で、および／または同時に、いくつかの行為が行為に従って発生してもよいので、行為の順序によって限定されないことを理解し、認識されたい。例えば、方法は、代替として、状態図などにおける一連の相関状態またはイベントとして表すことができることを当業者は、理解し、認識するであろう。その上、方法に示された全ての行為が、斬新な実装形態に必要とされ得るわけではない。

【0070】

[0077]本明細書に含まれる説明および図は、最善のオプションをどのように作り、使用するかを当業者に教示するための特定の実装形態を描写する。発明の原理を教示するために、いくつかの従来の態様を簡素化するか、省略した。当業者は、本発明の範囲に含まれるこれらの実装形態から変形形態を理解するであろう。上記で説明した特徴は、複数の実装形態を形成するために様々に組み合わせることができることも当業者は認識するであろう。結果として、本発明は、上記で説明された特定の実装形態ではなく、特許請求の範囲およびその均等物によってのみ限定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】