特許 7438974 ライブブロードキャスティングに対する適応ビットレート方法

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

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

(11)【特許番号】

(24)【登録日】2024-02-16

(45)【発行日】2024-02-27

(54)【発明の名称】ライブブロードキャスティングに対する適応ビットレート方法

(51)【国際特許分類】

   H04N 21/238 20110101AFI20240219BHJP

   H04L 47/38 20220101ALI20240219BHJP

   H04L 67/10 20220101ALI20240219BHJP

   H04N 21/438 20110101ALI20240219BHJP

【ＦＩ】

H04N21/238

H04L47/38

H04L67/10

H04N21/438

【請求項の数】 19

(21)【出願番号】P 2020559366

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

(65)【公表番号】

(43)【公表日】2021-08-30

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

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

(87)【国際公開日】2019-10-31

【審査請求日】2022-03-04

(31)【優先権主張番号】62/663,182

(32)【優先日】2018-04-26

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

(73)【特許権者】

【識別番号】519379400

【氏名又は名称】フェニックス リアル タイム ソリューションズ， インコーポレイテッド

(74)【代理人】

【識別番号】110000062

【氏名又は名称】弁理士法人第一国際特許事務所

(72)【発明者】

【氏名】ビーラー， ステファン

(72)【発明者】

【氏名】ブスタマンテ， ファビアン

【審査官】鈴木 順三

(56)【参考文献】

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

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

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

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

Ｈ０４Ｌ ４５／００ － ４９／９０５７

Ｈ０４Ｌ ６７／００ － ６７／９５

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

【請求項1】

ライブメディアストリームをレンダリングするために、システムが、連続性を維持するために実行する方法であって、
第１のディストリビューション層を含むライブメディアストリームを取得するステップであって、前記第１のディストリビューション層が、第１の時点での第１のキーフレーム及び前記第１のキーフレームに続くデルタフレームのセットを含む、ステップと、
クライアントデバイスが、前記ライブメディアストリームのレンダリングを変更する指示を受信するステップと、
前記指示の受信に応答して、前記ライブメディアストリームの第２のディストリビューション層を前記クライアントデバイスに通信するステップであって、前記第２のディストリビューション層が、第２の時点にシフトされている第２のキーフレームを含み、前記第２の時点が、時間的に、前記第１の時点より遅く、そして前記クライアントデバイスが、前記第１のディストリビューション層に代えて前記第２のディストリビューション層をレンダリングすることによって、前記ライブメディアストリームをレンダリングすることにより、前記第２のキーフレームが、継続性を可能にする、ステップと、
第１のディストリビューション層の次のキーフレームに関連付けられている第２の時点と第３の時点との間の時間間隔が、閾値時間間隔よりも短いか否かを決定するステップであって、前記第２のディストリビューション層の当該通信が、前記時間間隔が前記閾値時間間隔よりも短いとの決定に基づいている、ステップとを、
備える方法。

【請求項2】

送信元サーバが、前記第１のディストリビューション層を生成するステップと、
前記送信元サーバが、前記クライアントデバイスから、前記ライブメディアストリームのレンダリングを変更する前記指示を受信することに基づいて、前記第２のディストリビューション層を生成するステップとを、
更に、備える、請求項１に記載の方法。

【請求項3】

当該取得するステップが、
中間サーバが、送信元サーバから、前記第１のディストリビューション層を受信するステップであって、前記第１のディストリビューション層が、前記送信元サーバによって生成される、ステップと、
前記中間サーバが、前記クライアントデバイスから、前記ライブメディアストリームの前記レンダリングを変更する前記指示を受信することに基づいて、前記第２のディストリビューション層を生成するステップと、
前記中間サーバが、前記第１のディストリビューション層と前記第２のディストリビューション層の両方を前記クライアントデバイスに通信するステップとを、
備える、請求項１に記載の方法。

【請求項4】

前記第１のディストリビューション層が、第１のビットレートを含み、そして前記第２のディストリビューション層が、前記第１のビットレートとは異なる第２のビットレートを含む、請求項１に記載の方法。

【請求項5】

前記第２のディストリビューション層が、前記第２の時点で前記第２のディストリビューション層の前記第２のキーフレームに続く第２のセットのデルタフレームを含み、前記第２のセットのデルタフレームが、前記第１のキーフレームから、前記第１のディストリビューション層の次のフレームまで拡がっている、請求項１に記載の方法。

【請求項6】

メディアストリームの連続性を維持するために、デバイスが実行する方法であって、
周期的な時点に配置されたキーフレームのシリーズを備えた第１のディストリビューション層を含むメディアストリームを取得するステップであって、キーフレームの前記シリーズが、第１の時点で第１のキーフレームを含み、そして複数のデルタフレームが、キーフレームの前記シリーズの各キーフレームに続く、ステップと、
前記メディアストリームの連続性を維持するために、前記メディアストリームの第２のディストリビューション層を送信する指示を伝送するステップと、
前記第２のディストリビューション層を受信するステップであって、前記第２のディストリビューション層が、前記第１の時点から第２の時点にシフトしている第２のキーフレーム及び前記第２のキーフレームに続く少なくとも１つのデルタフレームを含む、ステップと、
第１のディストリビューション層の次のキーフレームに関連付けられている第２の時点と第３の時点との間の時間間隔が、閾値時間間隔よりも短いか否かを決定するステップであって、前記第２のディストリビューション層の当該受信が、前記時間間隔が前記閾値時間間隔よりも短いとの決定に基づいている、ステップとを、
備える方法。

【請求項7】

前記第１の時点で、前記第１のディストリビューション層の前記第１のキーフレームをレンダリングするステップと、
前記デバイスが、前記第１のディストリビューション層の第１のビットレートよりも大きいビットレートで、前記メディアストリームを処理することができることを決定するステップであって、前記指示が、前記第１のビットレートよりも大きい前記ビットレートで、前記第２のディストリビューション層を送信する指示を含む、ステップと、
前記第２の時点で、前記第１のビットレートよりも大きい前記ビットレートで、前記第２のディストリビューション層の前記第２のキーフレームをレンダリングするステップとを、
更に、備える、請求項６に記載の方法。

【請求項8】

前記第２の時点で、前記第２のディストリビューション層の前記第２のキーフレームをレンダリングするステップと、
第３の時点で、前記第１のディストリビューション層のキーフレームの前記シリーズ内の第３のキーフレームをレンダリングするステップであって、前記デバイスが、前記第３の時点で前記第２のディストリビューション層を放棄する、ステップとを、
更に、備える、請求項６に記載の方法。

【請求項9】

前記デバイスが、前記第１のディストリビューション層に関連付けられている第１のビットレートで、前記第１のディストリビューション層を処理することができないことを指示するネットワーク環境の変化を検出するステップであって、前記指示が、前記第２のディストリビューション層を、前記第１のビットレートよりも低い第２のビットレートで、送信する指示を含む、ステップと、
前記第２の時点で、前記第２のディストリビューション層の前記第２のキーフレームを前記第２のビットレートでレンダリングするステップとを、
更に、備える、請求項６に記載の方法。

【請求項10】

前記第２のディストリビューション層が、前記第１のキーフレームに続く第１の複数のデルタフレームに含まれるデルタフレームの数よりも少ない数のデルタフレームを含む、請求項６に記載の方法。

【請求項11】

前記メディアストリームが、ライブビデオブロードキャスティングコンテンツを含む、請求項６に記載の方法。

【請求項12】

ライブメディアコンテンツをストリーミングするデバイスであって、
ライブメディアストリームの連続性を維持するための命令を含むメモリであって、前記命令が、プロセッサによって実行されると、前記プロセッサに、以下のステップ：
時間領域に対して第１の時刻での少なくとも第１のキーフレームを有する第１のビットレートの第１のディストリビューション層と、前記第１のキーフレームに続く第１のデルタフレームのセットとを、含む前記ライブメディアストリームを取得するステップ；
前記第１のビットレートとは異なる第２のビットレートで、前記ライブメディアストリームの第２のディストリビューション層を通信する指示を、クライアントデバイスから受信するステップ；
前記指示の受信に基づいて、前記第２のビットレートを有する前記第２のディストリビューション層を生成するステップであって、前記第２のディストリビューション層が、前記時間領域で第２の時刻にシフトされた第２のキーフレームと、前記第２のキーフレームに続く少なくとも１つのデルタフレームとを含む、ステップ；
前記第２のビットレートで、前記第２のディストリビューション層を含む前記ライブメディアストリームを前記クライアントデバイスに通信するステップ；および
第１のディストリビューション層の次のキーフレームに関連付けられている第２の時点と第３の時点との間の時間間隔が、閾値時間間隔よりも短いか否かを決定するステップであって、前記第２のディストリビューション層の当該通信が、前記時間間隔が前記閾値時間間隔よりも短いとの決定に基づいている、ステップ、
を実行させる、メモリを
備えるデバイス。

【請求項13】

前記プロセッサに、
発信元のクライアントデバイスからのライブストリーミングデータを受信させ、そして
前記ライブストリーミングデータをエンコードして、前記第１のディストリビューション層及び前記第２のディストリビューション層を含む前記ライブメディアストリームを生成させる、
請求項１２に記載のデバイス。

【請求項14】

前記プロセッサに、送信元デバイスからの前記第１のディストリビューション層を受信させる、請求項１２に記載のデバイス。

【請求項15】

前記第２のキーフレームに続く少なくとも１つのデルタフレームが、前記第２のディストリビューション層の前記第２のキーフレームに続く第２のセットのデルタフレームを含み、前記第２のセットのデルタフレームが、前記第１のキーフレームから前記第１のディストリビューション層の次のキーフレームに拡がっている、請求項１２に記載のデバイス。

【請求項16】

前記第２のキーフレームに続く前記少なくとも１つのデルタフレームが、前記第２のディストリビューション層の前記第２のキーフレームに続く第２のセットのデルタフレームを含み、前記第２のセットのデルタフレーム内のデルタフレームの数が、前記第１のキーフレームに続く前記第１のデルタフレームのセットに含まれるデルタフレームの数よりも少ない、請求項１２に記載のデバイス。

【請求項17】

前記プロセッサに、
第３の時刻に時間領域でシフトされた第３のキーフレームを含む第３のディストリビューション層を生成させ、ここで、前記第３の時刻が、前記第２の時刻と前記第１のディストリビューション層の新しいキーフレームに関連付けられている第４の時刻との間にあり、そして
前記第１のディストリビューション層、前記第２のディストリビューション層、及び前記第３のディストリビューション層を含む前記ライブメディアストリームを、前記クライアントデバイスに通信させる、
請求項１２に記載のデバイス。

【請求項18】

前記プロセッサに、
前記第２の時刻と前記第１のディストリビューション層の新しいキーフレームに関連付けられている第４の時刻との間の時間間隔が、閾値の時間間隔よりも短いことを決定させる、デバイスであって、前記第２のディストリビューション層の当該生成が、前記時間間隔が、閾値の時間間隔より短いとの決定に基づいている、
請求項１２に記載のデバイス。

【請求項19】

前記プロセッサに、
前記第１のディストリビューション層の前記新しいキーフレームに関連付けられている、前記第４の時刻での前記第２のディストリビューション層を放棄させる、
請求項１８に記載のデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

開示された教示は、パケット交換ネットワークを介したライブメディアストリーミング、より具体的には、そのようなネットワークを介したライブストリーミングメディアコンテンツに対する適応レートの選択に関する。

【背景技術】

【0002】

インターネットを介したビデオコンテンツのストリーミングは、ビデオコンテンツを表示する方法として急速に人気を集めている。ストリーミングビデオコンテンツのこのような形式の１つは、ライブアクションスポーツ、デバイス間のビデオコール、ライブニュースレポートのようなライブビデオコンテンツである。電子デバイス（例、スマートフォン、コンピュータ、タブレット）は、インターネットを介してビデオストリームにアクセスする（又はそれを「サブスクライブする」）ことが出来る。

【0003】

インターネットを介してビデオコンテンツをストリーミングするための重要な評価基準は、ストリーミングされたビデオの品質を示す品質レベルである。この品質レベルは、インターネットを介してビデオコンテンツを伝送するために選択されたビットレートによって、決定させることができる。ビットレートが高いことは、ビデオコンテンツ内の情報がより多くエンコードされ、そして元のビデオコンテンツの再生がより正確になることを示す。これに対し、ビットレートが低いと、エンコードされた情報の量が少なくなり、そして元のビデオコンテンツの再現精度が低下する可能性がある。

【0004】

ビデオコンテンツを伝送するためのビットレートは、クライアントデバイスのネットワーク状態、所望の起動レイテンシ（すなわち、ビデオ再生を最初に初期化するときに体験する遅延）、及びグリッチ／再バッファリングに対する耐性（つまり、ビデオコンテンツデータが欠落しているためにビデオ再生が停止した場合の耐性）の様ないくつかの要因に基づいて、クライアントデバイスが選択することができる。多くの場合、ビデオコンテンツのストリーミング中の起動レイテンシ又は再バッファリングは、望ましくない。従って、より高いビットレートのビデオストリームをストリーミングしつつ、ストリーミングビデオコンテンツの起動レイテンシ及び再バッファリングを最小化又は排除することが望ましい。

【発明の概要】

【0005】

本開示は、ライブメディアストリームの連続性を維持するための技術に関する。このメディアストリームは、時間領域に対して第１の時刻で少なくとも１つのキーフレームを有する第１のビットレートの第１のディストリビューション層と、第１のキーフレームに続くデルタフレームのセットとを含むことができる。このメディアストリームは、また、各ディストリビューション層が、キーフレームに続くデルタフレームのセットに、他の層に対して時間的にシフトされた少なくとも１つのキーフレームを含む、多くの追加のディストリビューション層も含むことができる。

【0006】

ストリーミングサーバは、メディアストリームの第１のディストリビューション層を取得することができる。このストリーミングサーバは、第１の時刻から時間的にシフトされたキーフレームを備えたメディアストリームの追加のディストリビューション層を生成することができる。追加のディストリビューション層は、追加のディストリビューション層を生成するリクエストを表す指示を識別することに基づいて、生成させることができる。メディアストリームは、少なくとも１つのクライアントデバイスに送信させることができる。

【0007】

クライアントデバイスは、メディアストリームの第１のディストリビューション層又は追加のディストリビューション層のうちの１つをサブスクライブすることができる。デバイスは、第２の時刻でメディアストリームの追加のディストリビューション層をサブスクライブして、起動時間を最小限に抑え、そしてメディアコンテンツの様々な複雑さと動的なネットワーク条件の中で体験の品質を最適化することができる。

【0008】

技術の他の態様は、添付の図及び詳細な説明から明らかになるであろう。

【0009】

この要約は、以下の詳細な説明でさらに説明される簡略化された形式で概念の選択を紹介するために提供される。この要約は、主張された主題の主要な特徴又は本質的な特徴を特定することを意図しておらず、主張された主題の範囲を制限するために使用されることも意図されていない。

【図面の簡単な説明】

【0010】

【図1】様々な実施形態による、ライブメディアコンテンツを複数のクライアントデバイスにストリーミングするためのシステムを示す。

【図2】様々な実施形態による、ストリーミングサーバのアーキテクチャを示す。

【図3】様々な実施形態による、クライアントデバイスのアーキテクチャを示す。

【図4】様々な実施形態による、エンコードされたメディアストリームを示す。

【図5】様々な実施形態による、ディストリビューション層のセットを備えた、エンコードされたメディアストリームを示す。

【図6】様々な実施形態による、適応ビットレートを有する、エンコードされたメディアストリームを示す。

【図7A】様々な実施形態による、複数のサブスクライバによるライブブロードキャスティングに対する、適応ビットレートストリーミングを示す。

【図7B】様々な実施形態による、動的ネットワーク条件でのライブブロードキャスティングに対する、適応ビットレートストリーミングを示す。

【図8A】様々な実施形態による、シフトされたディストリビューション層を有する、エンコードされたメディアデータのセットを示す。

【図8B】様々な実施形態による、複数のビットレートのシフトされたディストリビューション層を備えた、エンコードされたメディアデータのセットを示す。

【図9】様々な実施形態による、動的に生成されたディストリビューション層及びキーフレームを備えた、エンコードされたストリーミングデータを示す。

【図10】様々な実施形態による、エンコードされたメディアストリームに対する、ディストリビューション層及び動的に生成された層のセットを示す。

【図11】様々な実施形態による、エンコードされたメディアストリームに対する、ディストリビューション層及びブリッジディストリビューション層のセットを示す。

【図12A】様々な実施形態による、送信元ストリーミングサーバでディストリビューション層を動的に生成するためのアーキテクチャを示す。

【図12B】様々な実施形態による、データパスに沿ってディストリビューション層を動的に生成するためのアーキテクチャを示す。

【図13】様々な実施形態による、メディアストリームの連続性を維持するためのシグナリングプロセスを示す。

【図14】本明細書に記載の少なくともいくつかの操作を実施することができる処理システムの例を示すブロック図である。

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

【0011】

図面は、例示のみを目的として様々な実施形態を示す。当業者は、技術の原理から逸脱することなく、代替の実施形態を採用できることを認識するであろう。従って、特定の実施形態が図面に示されているが、技術は様々な修正に適している。

【0012】

以下に記載される実施形態は、当業者が実施形態を実施することを可能にし、かつ実施形態を実施する最良のモードを例示するために必要な情報を表す。添付の図に照らして以下の説明を読むと、当業者は、本開示の概念を理解し、そして本明細書で特に扱われていないこれらの概念の適用を認識するであろう。これらの概念及び適用は、本開示及び付随する特許請求の範囲に含まれる。

【0013】

実施形態は、特定のコンピュータプログラム、システム構成、ネットワークなどを参照して説明することができる。しかし、当業者は、これらの機能が他のコンピュータプログラムタイプ、システム構成、ネットワークタイプ等にも等しく適用可能であることを認識するであろう。例えば、「Ｗｉ‐Ｆｉネットワーク」という用語は、ネットワークを説明するために使用することができるが、関連する実施形態は、別のタイプのネットワークに展開することもできる。

【0014】

さらに、開示された本技術は、特別な目的のハードウェア（例、回路）、ソフトウェア及び／又はファームウェアで適切にプログラムされたプログラム可能な回路、又は特別な目的のハードウェアとプログラム可能な回路の組み合わせを使用して具体化させることができる。従って、実施形態は、電子デバイスによって生成されたビデオコンテンツを検査し、ビデオコンテンツに含まれる要素を識別し、分類モデルを適用して適切なアクションを決定し、そして適切なアクションを実行するために、コンピューティングデバイス（例、基地局又はネットワーク接続されたコンピュータサーバ）をプログラムするために使用することができる命令を有するマシン可読媒体を含むことができる。

【0015】

（用語）
本明細書で使用される用語の目的は、実施形態を説明するためのみであり、本開示の範囲を限定することを意図するものではない。文脈が許す場合、単数形又は複数形を使用する単語は、それぞれ複数形又は単数形も含む。

【0016】

本明細書で使用される場合、特に明記しない限り、「処理」、「演算」、「計算」、「決定」、「表示」、「生成」などの用語は、コンピュータのメモリ又はレジスタ内の物理（電子）量として表されるデータを、操作し、そしてコンピュータのメモリ、レジスタ、又は他のそのような格納媒体、送信、又は表示デバイス内の物理量として同様に表される他のデータに、変換するコンピュータ又は同様の電子コンピューティングデバイスの、アクション及びプロセスを指す。

【0017】

本明細書で使用される場合、「接続された」、「結合された」のような用語は、２つ以上の要素間の直接又は間接の任意の接続又は結合を指す。要素間の結合又は接続は、物理的、論理的、又はそれらの組み合わせとすることが出来る。

【0018】

「一実施形態」又は「１つの実施形態」への言及は、説明されている特定の特徴、機能、構造、又は特性が、少なくとも１つの実施形態に含まれることを意味する。このような句の出現は、必ずしも同じ実施形態を指すわけではなく、また、それらが、必ずしも、互いに相互に排他的である代替の実施形態を指すわけでもない。

【0019】

文脈が明らかに他のことを要求しない限り、「備える」及び「含む」という用語は、排他的又は網羅的な意味ではなく、包括的意味で（すなわち、「それを含むがそれに限定されない」という意味で）解釈されるべきである。

【0020】

「に基づく」という用語は、また、排他的又は網羅的な意味ではなく、包括的意味で解釈されるべきである。従って、特に断りのない限り、「に基づく」という用語は、「少なくとも部分的に基づく」ことを意味することを意図している。

【0021】

「モジュール」という用語は、ソフトウェアコンポーネント、ハードウェアコンポーネント、及び／又はファームウェアコンポーネントを広く指す。モジュールは、通常、指定された入力に基づいて有用なデータ又は他の出力を生成することが出来る機能コンポーネントである。モジュールは、自己完結型とすることができる。コンピュータプログラムは、１つ又は複数のモジュールを含むことができる。従って、コンピュータプログラムは、異なるタスクを完了させことが出来る複数のモジュール、又は複数のタスクを完了させることが出来る単一モジュールを含むことができる。

【0022】

「ライブメディアストリーム」という用語は、広い意味で、イベントが発生している際にネットワーク上でイベントをブロードキャストすることを指す。これは、送信元デバイスによって生成され、ネットワークを介して伝送され、そして受信デバイスのユーザがレイテンシ／遅延を認識することができない（これは、「ほぼリアルタイム」とも呼ばれる）状態で、受信デバイスによってレンダリングされる、コンテンツのブロードキャストを含むことができる。デバイスのユーザが認識できないこのようなレイテンシの例は、１００ミリ秒、３００ミリ秒、５００ミリ秒等を含むことが出来る。従って、ブロードキャストグループ内のクライアントデバイスのユーザは、ライブメディアストリームとほぼリアルタイム（つまり、遅延が、ブロードキャストグループ内のクライアントデバイスのユーザには認識されない状態）で対話又は応答することが出来る。

【0023】

複数のアイテムのリストを参照して使用される場合、単語「又は」は、以下の解釈：リスト内の任意のアイテム、リスト内の全てのアイテム、及びリスト内のアイテムの任意の組み合わせ、の全てを網羅することが意図されている。

【0024】

本明細書に記載のプロセスの何れかで実行されるステップのシリーズは、例示的なものである。しかしながら、物理的可能性に反しない限り、ステップは、様々な順序及び組み合わせで実行させることができる。例えば、ここで説明するプロセスにステップを追加したり、プロセスからステップを削除したりできるであろう。同様に、ステップを置き換えたり、並べ替えたりすることもできるであろう。従って、如何なるプロセスの説明も、制限がないことが意図されている。

【0025】

（概要）
インターネットのようなパケット交換ネットワークを介したストリーミングメディアコンテンツは、様々なメディア（例、ビデオ、オーディオ）を利用する方法として急速に人気を集めている。電子デバイス（例、スマートフォン、コンピュータ、タブレット）は、ネットワーク（例、インターネット）に接続し、そして様々なビデオ及びオーディオデータストリームをサブスクライブすることが出来る。例えば、複数の電子デバイス（又は「クライアントデバイス」）は、発信デバイスによって生成されたビデオ通話のライブストリームをサブスクライブすることができる。別の例では、クライアントデバイスは、スポーツイベントのライブストリームをサブスクライブすることができる。メディアストリームをサブスクライブする全てのクライアントデバイスは、まとめて「ブロードキャストグループ」と呼ぶことができる。

【0026】

ストリーミングメディアコンテンツの人気の増加に伴い、インターネットを介して高品質のビデオ及びオーディオストリーミングを配信するための、帯域幅及び計算リソースに対するユーザからの要求も、増加している。ビデオ再生の初期化時に発生する遅延により、ユーザ体験の品質が低下する可能性があるので、ライブメディアストリームの品質は、少なくとも部分的に、ビデオ再生の起動レイテンシに基づく。さらに、ライブメディアストリームの品質は、ビデオ再生の再バッファリング又はグリッチに基づく可能性があり、これにより、ユーザ体験の品質も低下してしまう可能性がある。

【0027】

ストリーミングメディアコンテンツを様々なクライアントデバイスに提供するために、ストリーミングデバイスは、メディアストリームを生成し、そしてネットワークを介してクライアントデバイスにメディアストリームを伝送することができる。このメディアストリームは、少なくとも１つのキーフレーム（すなわち、クライアントデバイスが、エンコードして、完全なフレームをレンダリングすることが出来るデータ）、及び多くの予測（又は「デルタ」）フレーム（すなわち、キーフレームとの相違を表すデータ）、を含むことができる。このメディアストリームは、ビデオフレームを表すビット数を表すビットレートを含むことができ、ここで、ビットレートの増加は、関連付けられているビデオのより高い画質を表す。

【0028】

いくつかの実施形態では、新しいクライアントデバイスは、ストリーミングメディアコンテンツをサブスクライブすることができる。新しいクライアントデバイスがストリーミングメディアコンテンツをサブスクライブするために、クライアントデバイスは、先ず、キーフレームを処理して、ビデオフレームをレンダリングすることができる。レンダリングされると、新しいクライアントデバイスは、後続の予測フレームを処理して、ビデオを構成するフレームのシリーズをレンダリングし及び出力することが出来る。しかしながら、キーフレームのシリーズは、メディアストリームに沿って様々な時点に配置させることができる。もし、新しいクライアントデバイスが、キーフレーム間の時刻にメディアストリームをサブスクライブする場合、次のキーフレームが到着するまで、新しいクライアントデバイスは、メディアストリームを処理することができずそしてビデオをレンダリングできない場合がある。これにより、新しいクライアントデバイスに対し、起動レイテンシが発生する可能性がある。

【0029】

同様に、いくつかの実施形態では、クライアントデバイスに関連付けられているネットワーク条件が、変化する可能性がある。例えば、クライアントデバイスの帯域幅が低下し、クライアントデバイスが現在のビットレートでメディアストリームを処理できない場合がある。これにより、クライアントデバイスが、ビデオを適切に処理及びレンダリングすることができないため、ビデオのグリッチ／中断が発生する可能性がある。第２の例として、クライアントデバイスが、現在のビットレートよりも高いビットレートでメディアストリームを処理することができる可能性がある。しかしながら、クライアントデバイスは、より大きなビットレートストリームの新しいキーフレームが到着するまで、より大きなビットレートストリームをサブスクライブできない可能性がある（これは、帯域幅が十分に活用されず、そしてビデオ品質が低下することをもたらす）。ネットワーク状態の変化を体験するクライアントデバイスは、異なるビットレートを含むストリーミングメディアコンテンツの代替ストリームをサブスクライブする可能性がある。しかしながら、新しいサブスクライバの場合と同様に、クライアントデバイスは、ストリーミングメディアコンテンツを異なるビットレートでレンダリングするために、新しいキーフレームまで待機する必要がある可能性がある。

【0030】

従って、起動レイテンシ及び再バッファリング／グリッチを最小化又は排除して、ライブメディアストリーミングの品質を最適化するためには、様々なストリーミング技術を使用することができる。さらに、ライブメディアストリーミングの品質を最適化するには、動的又は異種のネットワーク条件のコンテキストにおいてその品質を維持しつつ、メディアコンテンツを中断させずに転送及び再構成することが出来るように、メディアコンテンツをエンコードする品質レベルを、選択することが含まれる。

【0031】

本開示は、ライブメディアストリーミングに対し、適応ビットレート技術を利用すること及びメディアストリームに対するディストリビューション層を動的に生成することに関する。エンコードされたメディアストリームは、クライアントデバイスが、ストリーミングされつつあるメディアを処理及びレンダリングする際の起動レイテンシを短縮させるために、時間に対してシフトされるキーフレームを備えた、１つ以上の代替ストリーム（又は「ディストリビューション層」）により、生成させることができる。エンコードされたメディアストリームのディストリビューション層は、新しいクライアントデバイスがこのメディアストリームをサブスクライブするか否か、又はクライアントデバイスがネットワーク状態の変化を体験するか否かの決定に基づいて、クライアントデバイスに対して動的に生成させることができる。これにより、既存のメディアデータストリームをサブスクライブするクライアントデバイスの起動時間が短縮され、そしてストリーミングメディアコンテンツの品質が向上し、この結果、ブロードキャストグループに含まれる全てのクライアントデバイスのユーザ体験を向上させることができる。

【0032】

図１は、様々な実施形態による、ビデオコンテンツを、複数のクライアントデバイス１１４ａ～ｃにストリーミングするためのシステム１００を示す。システム１００は、インターネットのようなネットワーク１１２を介してメディアコンテンツを、エンコーディング及びストリーミングするように構成された１つ又は複数のストリーミングサーバ１１０を含むことができる。いくつかの実施形態では、ストリーミングサーバ１１０は、「ネットワークアクセス可能なサーバシステム１１０」と呼ぶことができる。ストリーミングサーバ１１０は、外部ノード（例、クライアントデバイス、外部サーバ、ビデオカメラ）からメディアデータを受信することができる。ストリーミングサーバ１１０は、メディアデータをエンコードし、そしてブロードキャストグループ内のクライアントデバイス１１４ａ～ｃに転送することができる。

【0033】

いくつかの実施形態では、メディアデータは、ライブビデオストリームを含むことができる。一例として、ライブビデオストリームは、外部ノードによって生成させ、ストリーミングサーバ１１０によってネットワークを介して転送させ、そしてクライアントデバイス１１４ａ-cのユーザが知覚できない時間間隔内にクライアントデバイス１１４ａ～ｃによってレンダリングさせることができる。いくつかの実施形態では、ライブビデオは、ほぼリアルタイムであるビデオを含むことができる。ライブビデオを視聴しているユーザが、ライブビデオと対話しそしてライブビデオに対応することができるように、ライブビデオは、ブロードキャストグループに含まれるクライアントデバイスに伝送させることができる。

【0034】

一例として、スマートフォン１１４ａは、ライブビデオ（例、ビデオキャプチャゲームプレイ、ユーザの動きをキャプチャするビデオ）を生成し、そしてストリーミングサーバ１１０に伝送することができる。ストリーミングサーバ１１０は、受信したライブビデオをエンコードし、そしてエンコードされたビデオをブロードキャストグループ内の他のクライアントデバイス（例、ラップトップコンピュータ１１４b、コンピュータ１１４c）に伝送することが出来る。この例では、ブロードキャストグループ内の他のクライアントデバイスは、最小限のバッファリングで、ユーザが認識できない時間遅延（例、３００ミリ秒未満）で、エンコードされたライブビデオを受信することができる。

【0035】

上記の例をさらに進めると、ラップトップコンピュータ１１４ｂは、ライブビデオを受信し、そして第２のライブビデオを生成することが出来る。第２のライブビデオは、ストリーミングサーバ１１０に伝送させることができる。このストリーミングサーバ１１０は、第２のライブビデオを、エンコードし、そしてブロードキャストグループ内の他のクライアントデバイス（スマートフォン１１４ａ、コンピュータ１１４ｃ）に伝送する。この例では、ブロードキャストグループに含まれるデバイスは、ライブビデオストリームにより、デバイス１１４ａ～ｃのユーザが知覚できない遅延／レイテンシで、インタラクティブに通信することが出来る。

【0036】

ストリーミングサーバ１１０は、エンコードされたメディアストリーム（例、メディアストリーム１１６）を、（まとめてブロードキャストグループ１１４ａ～ｃと呼ぶことができる）クライアントデバイス１１４ａ～ｃに伝送することができる。いくつかの実施形態では、ストリーミングサーバ１１０は、クライアントデバイス１１４ａ～ｃからストリームリクエスト１１８を受信することに基づいて、エンコードされたメディアストリーム１１６をクライアントデバイス１１４ａ～ｃに伝送することができる。ストリームリクエスト１１８は、クライアントデバイス１１４ａ～ｃのユーザが、エンコードされたメディアストリーム１１６をサブスクライブすることを既にリクエストしていることを示すことができる。

【0037】

例えば、ラップトップコンピュータ１１４ｂのユーザは、ネットワーク１１２を介してストリーミングサーバ１１０にストリームリクエストを伝送することによって、スポーツイベントのライブビデオストリームをサブスクライブすることができる。ストリーミングリクエストを受信すると、ストリーミングサーバ１１０は、エンコードされたビデオコンテンツをラップトップコンピュータ１１４ｂに伝送することが出来る。次に、ラップトップコンピュータ１１４ｂは、エンコードされたビデオデータをデコードし、そしてスポーツイベントのライブビデオストリームをディスプレイに出力することが出来る。

【0038】

図２は、様々な実施形態による、ストリーミングサーバ２１０のアーキテクチャを示す。ストリーミングサーバ２１０は、エンコードされたメディアストリームをエンコードし、そしてネットワークを介して１つ又は複数のクライアントデバイスに伝送するように構成された１つ又は複数の電子デバイスを含むことができる。いくつかの実施形態では、ストリーミングサーバ２１０は、サーバ間でデータを伝送するように構成された、相互接続されたストリーミングサーバのシリーズの一部である。

【0039】

上述したように、ストリーミングサーバ２１０は、外部デバイス（例、ビデオカメラ、外部サーバ）からライブストリーム２１２を受信することができる。ストリーミングサーバ２１０は、ネットワークインターフェース２１６でライブメディアコンテンツを受信することができる。ネットワークインターフェース２１６は、適切な有線及び／又は無線通信プロトコルを介して外部デバイスとインターフェースすることができる。

【0040】

いくつかの実施形態では、ネットワークインターフェース２１６は、第２のストリーミングサーバからメディアコンテンツ２１０のエンコードされたストリームを受信する。以下の図１２に示されているように、データパスに沿って、複数のストリーミングサーバを配置させて、エンコードされたメディアストリームを、生成させ、そしてそれをデータパスに沿ってクライアントデバイス（例、クライアントデバイス１１４ａ～ｃ）に転送させることができる。

【0041】

ネットワークインターフェース２１６でデータが受信されると、ストリーミングサーバ１１０は、受信したデータがエンコードされているか否かを決定することができる。もし、受信データがエンコードされている場合、ストリーミングデータは、デコーダ２１８に転送させることができる。いくつかの実施形態では、受信データが、エンコードされていないライブストリーム２１２である場合がある。この場合、このライブストリームは、トランスコーダ２２０に転送させて、適切なエンコーディングプロトコルを使用して、このライブストリームを、エンコードされたメディアストリームにエンコードさせることができる。

【0042】

デコーダ２１８は、適切なデコーディングプロトコルを使用して、受信された、エンコーされているメディアストリームをデコードするように構成することができる。デコードされたメディアストリームは、トランスコーダ２２０に転送させることができる。トランスコーダ２２０は、適切なエンコーディングプロトコルを使用して、受信されたデータを、エンコードされたメディアストリームにエンコードさせることができる。

【0043】

エンコードされたメディアコンテンツは、ネットワークインターフェース２２２に転送させることができる。ネットワークインターフェース２２２は、適切な有線及び／又は無線通信プロトコルにより、エンコードされたメディアコンテンツ２１４をネットワークを介して様々なクライアントデバイスに転送することができる。

【0044】

いくつかの実施形態では、ネットワークモニタ２２４は、受信されたメディアストリームのデコーディング及びエンコーディングを監視し、そしてメディアストリームのデコーディング及びエンコーディングに関連する情報を受信することができる。受信した情報に基づいて、ネットワークモニタ２２４は、エンコードされたストリームのエラーを識別することができる。

【0045】

ネットワークモニタ２２４は、ストリーミングサーバ２１０内の他の構成要素を修正又は調整するリクエストを調整器２２６に伝送することができる。調整器２２６は、ビデオストリーム及び／又はトランスコーダ２２０の一部を調整／修正することができる。このような調整は、例えば、トランスコーディング技術又はプロトコルの修正を含むことができる。

【0046】

いくつかの実施形態では、広告２２８がビデオストリームに追加される。広告は、ビデオストリームに補足されるように構成されたビデオコンテンツを含むことができる。一例では、ストリーミングサーバ２１０は、様々な時点で、エンコードされたメディアストリームに広告を追加することができる。

【0047】

図３は、様々な実施形態による、クライアントデバイス３１４のアーキテクチャを示す。クライアントデバイス３１４は、スマートフォン、コンピュータ、タブレット、ゲーム機、スマートホームデバイス等のようなネットワークアクセス可能な電子デバイスを含むことができる。

【0048】

上述したように、クライアントデバイス３１４は、インターネットのようなネットワークに接続されたネットワークインターフェース３３０を介して、ストリームリクエスト３１８をストリーミングサーバ（例、図１のストリーミングサーバ１１０）に伝送することができる。ストリームリクエスト３１８は、ライブビデオストリームをサブスクライブし、そしてストリーミングサーバからエンコードされたメディアストリームを受信するためのリクエストを含むことができる。

【0049】

クライアントデバイス３１４のネットワークインターフェース３３０は、ストリーミングサーバからエンコードされたストリーム３１６を受信することができる。エンコードされたメディアストリーム３１６は、デコーダ３３２に転送させることができる。デコーダ３３２は、エンコードされたメディアストリームをデコードし、そしてレンダリングされたビデオ／オーディオコンテンツをディスプレイ３３４のような出力コンポーネントに伝送することができる。他の例示的な出力コンポーネントは、スピーカ、ヘッドセット、タッチスクリーンを含むことができる。ディスプレイ３３４は、関連付けられているビデオストリームを、エンコードされたメディアストリームのビットレートに対応する解像度／画質で表示することができる。

【0050】

サービスモニタ３３６は、エンコードされたストリーム及びストリームのデコーディングを監視することができる。例えば、もし、エンコードされたストリームのデコーディングにエラーがある場合、サービスモニタは、エラーを識別する、又はエラーに基づいてクライアントデバイスを修正することができる。

【0051】

（エンコードされたメディアストリームの概要）
図４は、様々な実施形態による、エンコードされたメディアストリームを示す。エンコードされたメディアストリーム（例、チャンクベースのストリームＳ１、エンコードされたストリームＳ２）は、例えば、ライブビデオストリームのようなメディアコンテンツを表すデータを含むことができる。

【0052】

エンコードされたメディアストリームは、キーフレームのシリーズ（例、キーフレーム４０２-１～４０２-３、４０４-１～４０４-３）及びそれらに続く予測フレーム（例、予測フレームのセット４０６、４０８）を含むことができる。キーフレーム（例、第１のキーフレーム４０２－１）（又は「ｉフレーム」）は、ビデオ内の画像のフルフレームを表すことができる。一例では、キーフレームは、ＶＰ８のイントラフレーム又はＭＰＥＧのキーフレームに類似させることができる。

【0053】

動作中、クライアントデバイス（例、図３のクライアントデバイス３１４）は、第１のキーフレーム４０２－１、４０４－１を処理して、ビデオフレームのような、対応するメディアコンテンツをレンダリングすることができる。キーフレームは、シーケンス内の他のフレームを参照せずにデコードさせることができる。この場合、デコーダは、デコーダの「デフォルト」状態から始まるこのようなフレームを再構成する。いくつかの実施形態では、キーフレームは、ビデオストリーム内のランダムアクセス（又はシーキング）ポイントを提供することができる。

【0054】

エンコードされたメディアストリームは、また、時間に関してキーフレームに続く複数の予測フレーム４０６、４０８（又は「デルタフレーム」）を含むこともできる。予測フレーム４０６、４０８は、キーフレーム間の相違を表すことができる。これは、予測フレームによって表されるフレームのレンダリングに要求されるデータを、低下させることができる。一例では、予測フレーム４０６、４０８は、ＶＰ８のインターフレーム又はＭＰＥＧ用語のＰフレームに類似させることができる。予測フレーム４０６、４０８は、前のフレームを参照してエンコードさせることができ、そしていくつかの実施形態では、全ての前のフレームは、最新のキーフレームまで、そしてそれを含めて、エンコードさせることができる。多くの場合、予測フレーム４０６、４０８の正しいデコーディングは、最新のキーフレーム及びそれに続く全ての予測フレームの正しいデコーディングに依存する。この結果、デコーディングアルゴリズムは、キーフレームのドロップを許容しない。フレームがドロップ又は破損する可能性がある環境では、キーフレームが正しく受信されるまで、正しいデコーディングを行うことができない可能性がある。

【0055】

メディアストリームは、チャンク（すなわち、メディアストリームの分割された重複しない部分）を作成するためのチャンク転送エンコーディングのようなエンコード技術を使用して、エンコードさせることが出来る。図４のチャンクベースのストリームS１は、チャンクベースのストリームの例を表すことができる。エンコードされたメディアストリームのチャンクは、互いに独立させて、伝送させそして受信させることができる。いくつかの実施形態では、チャンクベースのストリームの受信者と送信者の両者は、現在処理されつつあるチャンクの外側のデータストリームを知る必要はない。

【0056】

図５は、様々な実施形態による、ディストリビューション層のセットを備えた、エンコードされたメディアストリームを示す。エンコードされたメディアストリームは、「ディストリビューション層」と呼ばれる複数の代替ストリームＬＤ、ＳＤ、ＨＤを含むことができる。図５に示されるように、エンコードされたメディアストリームは、複数のビットレート５０８－１、５０８－２、５０８－３（又は「マルチビットレート（ＭＢＲ: multi bit-rate）エンコーディング」）によりストリーミングさせることができる。ディストリビューション層のビットレートは、ビデオフレームのビット数を表すことができる。この場合、ビットレートが高いほど、高画質のビデオに相関する。例えば、図５に示されるように、第１のディストリビューション層ＬＤは、低画質ビットレート５０８－１を含むことができ、第２のディストリビューション層ＳＤは、標準画質ビットレート５０８－２を含むことができ、そして第３のディストリビューション層ＨＤは、高画質ビットレート５０８－３を含むことができる。

【0057】

いくつかの実施形態では、エンコードされたメディアコンテンツは、様々なビット（又は「エンコーディング」）レートで、セグメント又はチャンク（例、図４に示されるようなチャンクベースのストリーム）でストリーミングされる。これらの実施形態では、もし、ネットワーク条件が変化する（すなわち、データ送信及び処理能力が増加又は減少する）場合、サブスクライブするデバイスは、異なるチャンク間を切り替えて、異なるビットレートでエンコードされたメディアストリームの代替バージョンを、サブスクライブすることができる。

【0058】

多くの場合、ＭＢＲエンコーディングは、固定ビットレートアプローチを使用して、各メディアストリームをエンコードする。固定ビットレートエンコーディングを使用して代替ストリームをエンコードすると、結果として得られるメディアの出力品質には一貫性がなく、かつ結果が望ましくないものとなる可能性がある。例えば、エンコードされたメディアストリームで表されるビデオには、様々な視覚的複雑さを持つ部分（又は「シーン」）が含まれる。この例では、固定ビットレートのエンコーディングは、様々な品質を含むこれらのビデオセグメントを効率的にエンコードすることはできない。これは、固定ビットレートのエンコーディングの場合、複雑度の低いビデオセグメントをエンコードするにはビットが多すぎ、そして複雑度の高いビデオセグメントをエンコードするにはビットが不足している可能性があるためである。

【0059】

多くの場合、ＭＢＲエンコーディングは、クライアントデバイスの最終的なディスプレイ解像度を固定することを要求する。固定ディスプレイ解像度を使用すると、マルチビットレートのビデオストリームをデコードし、そしてそれを固定ディスプレイ解像度にスケーリングして、表示されるメディアのグリッチを最小限に抑えることが出来る。固定ディスプレイ解像度を使用すると、様々な代替メディアストリームは、例えば、毎秒数メガビットから毎秒数キロビットまで等、幅広いビットレートを持つことが出来る。このような場合、固定ディスプレイ解像度へのストリーミングが直面する問題は、適切なビデオ解像度を、複数のビデオストリームの様々なビットレートに一致させることである。多くのマルチビットレートエンコード技術は、予め定義されているエンコード解像度を利用するが、これは、ビデオシーンの変化する複雑さ、及び様々なネットワーク上のクライアントデバイスについての動的ネットワーク条件に、十分適しているとは言えない。

【0060】

多くの場合、エンコードされるメディアストリームは、メディアコンテンツを複数のビットレートでエンコードするために、適応ビットレートストリーミングを利用することができる。図６は、様々な実施形態による、適応ビットレートでエンコードされたメディアストリームを示す。適応ビットレートでエンコードされたメディアストリームを使用すると、クライアントデバイスは、使用可能なリソースに基づいて、エンコードされたメディアを様々なビットレートでストリーミングすることを切り替えることができる。例えば、もし、クライアントデバイスが、現在ストリーミングされているビットレートよりも高いコーディングレートのビットレートでストリーミングすることができる場合、クライアントデバイスは、より高いコーディングレートの他のビットレートに切り替えることができる。

【0061】

いくつかの実施形態では、送信元メディアコンテンツは、様々なビットレートで、様々なディストリビューション層にエンコードさせ、そしてメディアコンテンツの部分にセグメント化させることができる。ストリーミングクライアントには、様々なビットレートで利用可能なストリームを認識させることができ、そしてストリーミングクライアントは、マニフェストファイルによってストリームをセグメント化することができる。

【0062】

例えば、（時刻Ｔ１で）開始／初期化すると、クライアントデバイスは、より低いビットレート６０８－１の第１のストリームＬＤをサブスクライブする（又はこの第１のストリームＬＤからセグメントをリクエストする）ことができる。もし、クライアントデバイスが、時刻Ｔ２において、より低いビットレートの第１のストリームよりも高いビットレートのストリームを処理できると、クライアントデバイスが決定した場合、クライアントデバイスは、より高いビットレート６０８-２の第２のストリームＳＤをサブスクライブすることができる。同様に、クライアントデバイスは、クライアントデバイスがより高いビットレート６０８－３のストリームを処理することが出来るとの決定に基づいて、時刻Ｔ３で第３のストリームＨＤをサブスクライブすることができる。

【0063】

逆に、もし、クライアントデバイスのダウンロード速度又は処理速度が、現在サブスクライブされつつあるストリームのビットレートよりも低い場合、クライアントデバイスは、より低いビットレートセグメントをサブスクライブすることができる。いくつかの実施形態では、クライアントデバイスは、ネットワークスループットが既に低下している、又はクライアントデバイスの処理能力が既に閾値レベルを下回っているとの決定に基づいて、より低いビットレートセグメントをサブスクライブすることができる。

【0064】

図７Ａは、様々な実施形態による、複数のサブスクライバによるライブブロードキャスティングに対する適応ビットレートストリーミングを示す。図７Ａに示されるように、複数のサブスクライバ（例、サブスクライバＳ１、Ｓ２）が、エンコードされたメディアストリームをサブスクライブすることができる。一例として、サブスクライバ１（Ｓ１）は、エンコードされたメディアストリームを時刻Ｔ０でサブスクライブすることができる。サブスクライバ２（Ｓ２）は、時刻Ｔ１でサブスクライブすることができる。

【0065】

いくつかの実施形態では、もし、エンコードされたメディアストリームが、適応ビットレートストリーミングを利用する場合、ストリームの各ディストリビューション層は、予めエンコードさせておくことができる。しかしながら、ライブブロードキャスティングの場合、既にブロードキャストされている、エンコードされたメディアストリームをサブスクライブする新しいクライアント（例、サブスクライバ２（Ｓ２））は、特定の解像度の新しいキーフレーム（つまり、特定の解像度に関連付けられているストリームのディストリビューション層）をリクエストする。多くの場合、新しいクライアントＳ２は、時間領域に関し、新しいキーフレームが到着する時刻Ｔ２より前のサブスクリプション時刻に、エンコードされたメディアストリームをリクエストすることができる。新しいクライアントのサブスクリプション時刻Ｔ１と第１のフレームがレンダリングされる時刻Ｔ２との間の時間間隔は、起動レイテンシＴ３を含むことができる。

【0066】

図７Ｂは、様々な実施形態による、動的ネットワーク条件でのライブブロードキャスティングに対する適応ビットレートストリーミングを示す。いくつかの実施形態では、ネットワーク条件の変化に応答して、クライアントは、変化するネットワーク条件に適応するために、エンコードされたメディアストリームのビットレートの変更をリクエストすることができる。

【0067】

一例として、図７Ｂに示されるように、クライアントは、第１の時刻Ｔ１でより高い帯域幅が利用可能であると決定することができる。より高い帯域幅が利用可能であると決定することは、利用可能な帯域幅が、より高いビットレートの、エンコードされたメディアストリームの処理に対応できることを、クライアントが識別することを含むことができる。従って、クライアントは、代表的なメディアの品質を向上させるために、より高いビットレートでディストリビューション層をサブスクライブすることをリクエストすることができる。

【0068】

しかしながら、より大きなビットレートでディストリビューション層をサブスクライブするために、クライアントは、リクエストされたディストリビューション層の新しいキーフレームが到着する時刻Ｔ２まで待たなければならない可能性がある。従って、第１の時刻Ｔ１と時刻Ｔ２との間の時間間隔は、帯域幅が十分に活用されない時間Ｔ３を表す。帯域幅が十分に活用されないこの待機時間Ｔ３（つまり、「第１のフレームまでの時間」）は、デコードされたメディアのビットレートが、より高いビットレートストリームから生じる品質よりも低い品質であるため、クライアント体験が低い品質となる結果をもたらす可能性がある。

【0069】

さらに、図７Ｂに示されるように、クライアントは、時刻Ｔ４で帯域幅の低下に遭遇する可能性がある。帯域幅の低下には、クライアントが、現在のビットレートではエンコードされたメディアストリームを処理することができないので、利用可能な帯域幅が低下することが、含まれる。この例では、クライアントは、より低いビットレートのストリームをリクエストすることができ、そしてこのより低いビットレートの新しいキーフレームは、後の時刻（例、第１のキーフレーム時刻Ｔ５）に到着する。ドロップ時刻Ｔ４と新しいキーフレームの時刻Ｔ５との間の帯域幅の持続時間は、レンダリング不連続持続時間Ｔ６とすることができる。このレンダリング不連続時間中には、結果的に得られるメディアが、中断／グリッチされる、又はメディアを表示することができない可能性がある。

【0070】

ブロードキャストグループは、エンコードされたメディアストリームをサブスクライブしたクライアントデバイスのグループを含むことができる。あるケースでは、もし、ブロードキャストグループ内の１つのクライアントが、エンコードされたメディアストリームのビットレートを維持することができない場合、このクライアントは、ストリームから除外される、又はより低いビットレートのストリームをサブスクライブした新しいブロードキャストグループに移動される。第２のケースでは、もし、ブロードキャストグループ内の１つのクライアントが、エンコードされたメディアストリームのビットレートを維持できない場合、ブロードキャストグループ内の全てのクライアントが、より低いビットレートでストリームを処理することができるように、エンコードされたメディアストリームを、より低いビットレートに下げることができる。何れの場合にも、単一のクライアント又はブロードキャストグループの何れかに対し、全体の品質が、低下してしまう可能性がある。

【0071】

いくつかの実施形態では、計算及びネットワークリソースを効率的に利用しつつ、クライアントの体験及び品質を最適化することは、複数のステップに関係する。第１のステップは、コンテンツを、ブロードキャストグループ内の複数のクライアントに、中断することなく転送及び再構成することが出来るように、コンテンツをエンコードする品質レベルを、選択することを含むことができる。第２のステップは、動的ネットワーク条件のコンテキストでその品質を維持しつつ、エンコードされたメディアストリームの新しいサブスクライバが、第１のフレームに至るまでの時間を短縮することを含むことができる。

【0072】

（ライブブロードキャスティングに対するシフトされたディストリビューション層（ＳＤL: shifted distribution layers））
図８Ａは、様々な実施形態による、シフトされたディストリビューション層を有する、エンコードされたメディアデータのセットを示す。エンコードされたメディアストリームのディストリビューション層ＬＤ、ＬＤ＋、ＬＤ＋＋は、様々な時刻位置にキーフレームのセット（これは、「シフトされたディストリビューション層」と呼ぶことができる）を含むことができる。

【0073】

一例として、図８Ａにおいて、第１のディストリビューション層ＬＤは、第１の時刻位置Ｔ１に第１のキーフレーム８０２－１を有するキーフレームのシリーズ８０２－１～８０２－４を含むことができる。第２のディストリビューション層ＬＤ＋は、時間領域に関してシフトされたキーフレームのシリーズ８０４－１～８０４－３を含むことができ、ここで、第１のキーフレーム８０４－１は、第２の時刻位置Ｔ２にある。同様に、第３のディストリビューション層ＬＤ＋＋は、時間領域に関してシフトされたキーフレームのシリーズ８０６－１～８０６－３を含むことができ、ここで、第１のキーフレーム８０６－１は、第２の時刻位置Ｔ３にある。元のストリーム内のキーフレームの位置に応じてキーフレームが時間的にシフトされたストリームの代替バージョンを使用することにより、起動レイテンシは短縮され、ストリーミングの中断が回避され、そしてネットワーク条件の変化の下でのリソース使用率が向上する。

【0074】

図８Ｂは、様々な実施形態による、複数のビットレートのディストリビューション層がシフトされた、エンコードされたメディアデータのセットを示す。図８Ｂに示されるように、エンコードされたメディアデータは、様々なビットレート又はコーディングレートのディストリビューション層（例、ＬＤ、ＳＤ、ＨＤ）を含むことができる。さらに、ディストリビューション層ＬＤ、ＳＤ、ＨＤのエンコードされたメディアデータは、第１の時刻Ｔ１で第１のキーフレームを含むことができる。

【0075】

エンコードされたメディアストリームのディストリビューション層は、シフトされたディストリビューション層を含むことができ、ここで、キーフレームは、時間領域に関してシフトされている。例えば、図８に示されるように、シフトされたディストリビューション層ＬＤ＋、ＳＤ＋、及びＨＤ＋は、時間的に第２の時刻Ｔ２にシフトされた第１のキーフレームを含む。同様に、シフトされたディストリビューション層ＬＤ＋＋、ＳＤ＋＋、及びＨＤ＋＋は、時間的に第３の時刻Ｔ３にシフトされた第１のキーフレームを含む。ディストリビューション層は、時間領域に対して任意の時刻位置に、時間的にシフトされたキーフレームを含むことができる。

【0076】

エンコードされたメディアストリームの新しいサブスクライバは、現在のサブスクリプション時刻に時間的に最も近いキーフレームを有するディストリビューション層をサブスクライブすることができるので、エンコードされたメディアストリームにおいてシフトされたディストリビューション層を利用することは、起動レイテンシを減少させることを可能にする。例えば、新しいクライアントデバイスは、時刻ＴＡで、エンコードされたメディアストリームをサブスクライブして、ＨＤビットレートのディストリビューション層をリクエストすることができる。この例では、時間的に第３の時刻Ｔ３にシフトされた第１のキーフレームが、時間的には現在の時刻ＴＡに最短の距離にあるので、新しいクライアントデバイスは、ディストリビューション層ＨＤ++をサブスクライブすることができる。従って、エンコードされたデータストリームのシフトされたディストリビューション層をサブスクライブすることにより、新しいクライアントが、シフトされていないディストリビューション層（ＨＤ）の次のキーフレームを待機することが無いので、起動レイテンシは短縮させることができる。

【0077】

（シフトされたディストリビューション層及び動的に生成された層（ＤＧＬ; dynamically generated layers））
いくつかの実施形態では、シフトされたディストリビューション層及びキーフレームは、動的に生成させることができる。図９は、様々な実施形態による、動的に生成されたディストリビューション層及びキーフレームを備えた、エンコードされたストリーミングデータを示す。

【0078】

シフトされたディストリビューション層は、動的に生成させることができる。一例では、新しいクライアントは、時刻ＴＡで、標準画質（ＳＤ: standard definition）エンコーディング速度でエンコードされたメディアストリームをサブスクライブすることができる。しかしながら、もし、新しいクライアントが、時刻ＴＡでディストリビューション層ＳＤをサブスクライブすると、時刻ＴＡと次のキーフレーム９０６－２の時刻との間に、起動レイテンシが発生する可能性がある。上述したように、エンコードされたメディアストリームから得られるメディアのクライアント体験と品質は、起動レイテンシにより、低下してしまう可能性がある。

【0079】

上記の例をさらに進めると、新しいクライアントが、エンコードされたメディアストリームを既にサブスクライブしているとの決定に基づいて、新しいディストリビューション層を、動的に生成させることができる。動的に生成された層（ＤＧＬ: dynamically generated layer）は、ＳＤ*によって表すことができる。動的に生成されたＳＤ* ９０８のキーフレームは、サブスクリプション時刻ＴＡとキーフレーム時刻との間の起動レイテンシを短縮する。

【0080】

いくつかの実施形態では、起動レイテンシを短縮するために、エンコードされたメディアストリームをサブスクライブする新しいクライアントに対し、新しいＤＧＬを生成させることができる。もし、現在の時刻（例、ＴＡ）と次のキーフレームとの間の時間間隔が、閾値時間間隔を超えると、新しいＤＧＬを生成させることができる。閾値時間間隔は、次のキーフレームまでの特定の数の予測フレーム、又は次のキーフレームまでの時間間隔を表すことができる。

【0081】

一例として、もし、この閾値時間間隔が、現在の時刻とディストリビューション層（例、ＳＤ）の次のキーフレームとの間の５予測フレームである場合で、もし、現在の時刻とディストリビューション層の次のキーフレームが、７フレームである場合には、ＤＧＬ（例、ＳＤ*）を生成させることができる。逆に、もし、現在の時刻とディストリビューション層の次のキーフレームとの間の時間間隔が、閾値時間間隔（例、３フレーム）より短い場合、ＤＧＬ（例、ＳＤ*）は、生成されない。

【0082】

図１０は、様々な実施形態による、エンコードされたメディアストリームのディストリビューション層及び動的に生成された層のセットを示す。図１０に示される実施形態では、層ＬＤ*、ＳＤ*、及びＨＤ*は、様々なビットレートで動的に生成された層（ＤＧＬ）とすることができる。シフトされたディストリビューション層とＤＧＬを利用することにより、ストリームサブスクライバの体験の品質を向上させ、そしてリソースの要求を減少させることができる。

【0083】

一例として、識別されたビットレートに対する新しいＤＧＬは、エンコードされたメディアストリームをサブスクライブする新しいクライアント、又はネットワーク状態の変化を体験するクライアントの何れかに基づいて、動的に生成させることができる。いくつかの実施形態では、ストリーミングサーバは、クライアントデバイスに対するネットワーク状態の変化を検出すること、又はネットワーク状態の変化を示すメッセージをクライアントデバイスから受信することの何れかに基づいて、動的に生成された層又はシフトされたディストリビューション層を、生成することができる。

【0084】

（ディストリビューション層及び関連付けられているブリッジディストリビューション層（ＢＤＬ: bridge distribution layers））
図１１は、様々な実施形態による、エンコードされたメディアストリームのディストリビューション層及びブリッジディストリビューション層のセットを示す。図１１に示されるように、層ＬＤ、ＳＤ、及びＨＤは、エンコードされたメディアストリームのディストリビューション層を表し、並びに層ＬＤ**、ＳＤ**、及びＨＤ**は、エンコードされたメディアストリームのブリッジディストリビューション層を表す。

【0085】

ブリッジディストリビューション層（ＢＤＬ）は、有限数のフレームを有する、動的に生成されたディストリビューション層を含むことができる。ＢＤＬ（例、ＬＤ**、ＳＤ**、ＨＤ**）には、キーフレーム、及び現在の時刻とディストリビューション層の次のキーフレームとの間の数の予測フレームを含めることができる。一例として、ＳＤ**は、時刻Ｔ３で生成させることができる。ここで、ＢＤＬは、時刻Ｔ３でのキーフレーム１１１０と、対応するディストリビューション層（ＳＤ）のキーフレームから次のキーフレームの時刻までの数の予測フレーム１１１２を含む。

【0086】

もし、クライアントが、ＢＤＬ（例、ＳＤ**）をサブスクライブすると、クライアントは、時間が次のキーフレーム（例、Ｔ４）の時刻に一致するときに、対応するディストリビューション層（例、ＨＤ）に切り替わることができる。いくつかの実施形態では、ＢＤＬ（例、ＨＤ**）は、クライアントデバイスがＢＤＬから切り替わるときに、時刻Ｔ４で放棄させることができる。

【0087】

いくつかの実施形態では、ストリーミングサーバは、トリガーイベントに基づいて、ＢＤＬの予測フレームの生成を停止することができる。このようなトリガーイベントの１つは、到着する、対応するディストリビューション層のキーフレームを含むことができる。この場合、ストリーミングサーバは、この対応するディストリビューション層のキーフレームの時刻に、予測フレームの生成を停止することが出来る。第２のトリガーイベントは、現在の時刻（例、Ｔ３）と次のキーフレームの時刻（例、Ｔ４）との間の持続時間を予測／推定することを含むことができる。この推定された時間間隔に基づいて、ストリーミングサーバは、ＢＤＬのキーフレームの後に、適切な数の予測フレームを生成することができる。

【0088】

図１２Ａは、様々な実施形態による、送信元ストリーミングサーバでディストリビューション層を動的に生成するためのアーキテクチャを示す。このアーキテクチャは、エンコードされたメディアストリームをクライアントデバイスに転送することを支援する１つ以上のサーバを含むことができる。図１２Ａに示されるように、送信元ストリーミングサーバ１２１０は、エンコードされたメディアストリームを、中間ストリーミングサーバ１２１２ａ～ｂにより、ネットワークを介してクライアントデバイスに伝送することができる。

【0089】

図１２Ａに示される実施形態では、送信元ストリーミングサーバ１２１０は、ディストリビューション層ＬＤ、ＳＤ、ＨＤとシフトされたディストリビューション層ＬＤ＋、ＳＤ＋、ＨＤ＋との両方を有する、エンコードされたメディアストリームを、生成することができる。エンコードされたメディアストリームは、様々な中間ストリーミングサーバ１２１２ａ～ｂに伝送させ、そしてブロードキャストグループの一部である様々なクライアントデバイス１２１４ａ～ｂに転送させることができる。この構成により、体験の品質を低下させながら、エンコードされたメディアストリームディストリビューション層を生成する際のリソースに対する要求を減らすことができる。クライアントデバイスが、ディストリビューション層の次のキーフレームまでより長い待機時間待機しなければならないので、体験の品質は、低下してしまう可能性がある。

【0090】

図１２Ｂは、様々な実施形態による、データパスに沿ってディストリビューション層を動的に生成するためのアーキテクチャを示す。図１２Ｂに示されるように、送信元ストリーミングサーバ１２１０は、ディストリビューション層ＬＤ、ＳＤ、ＨＤを有する、エンコードされたメディアストリームを生成することができる。中間ストリーミングサーバ１２１２ａ～ｂは、エンコードされたメディアストリームを受信し、そしてそのストリームをクライアントデバイス１２１４ａ～ｂに転送することができる。いくつかの実施形態では、中間クライアントデバイス１２１２ａ～ｂは、シフトされたディストリビューション層ＬＤ＋、ＳＤ＋、ＨＤ＋を生成し、そしてシフトされたディストリビューション層をクライアントデバイス１２１４ａ～ｂに伝送することができる。中間クライアントデバイス１２１２ａ～ｂは、ネットワーク条件が変化したこと又はクライアントデバイスが新しいサブスクライバであることにより、シフトされたディストリビューション層のリクエストを受信することに基づいて、シフトされたディストリビューション層をクライアントデバイス１２１４ａ～ｂに伝送することができる。

【0091】

複数の中間ストリーミングサーバが、クライアントデバイスに対して、シフトされたディストリビューション層を動的に生成することが出来るので、現在の時刻から第１のフレームまでの、クライアントデバイスに対する時間をより短くすることができる。さらに、送信元ストリーミングサーバに加えて、データパスの両端で、複数のエンコーダを実行させることもできる。

【0092】

図１３は、様々な実施形態による、メディアストリームの連続性を維持するためのシグナリングプロセスを示す。図１３に示されるように、１つ又は複数のサーバ（例、送信元サーバ１３１２及び中間サーバ１３１４）は、データパスに沿って、エンコードされたライブメディアストリームをクライアントデバイス１３１６に伝送することが出来る。

【0093】

クライアントデバイス１３１６は、新しいストリームリクエスト１３０１を、データパスに沿って中間サーバ１３１４に伝送することが出来る。新しいストリームリクエスト１３０１は、ライブメディアストリームをサブスクライブするリクエストを表すことが出来る。新しいストリームリクエスト１３０１を受信すると、中間サーバ１３１４は、リクエスト１３０１を、データパスに沿って送信元サーバ１３１２に転送することが出来る。

【0094】

送信元サーバ１３１２は、ライブメディアストリーム１３０２を生成することができる。いくつかの実施形態では、送信元サーバ１３１２は、新しいストリームリクエスト１３０１に基づいて、１つ又は複数のビットレートでメディアストリームを生成することができる。送信元サーバ１３１２は、メディアストリーム１３０３を、ブロードキャストグループ内の複数のクライアントデバイス（例、クライアントデバイス１３１６）に伝送することができる。いくつかの実施形態では、送信元サーバ１３１２は、データパスに沿ってメディアストリーム１３０３を中間サーバ１３１４に伝送することが出来る。この中間サーバ１３１４は、メディアストリーム１３０３をクライアントデバイス１３１６に転送することができる。メディアストリーム１３０３を受信すると、クライアントデバイス１３１６は、関連付けられているライブメディアコンテンツを処理及びレンダリングすることができる。

【0095】

いくつかの実施形態では、クライアントデバイス１３１６は、リクエスト１３０４を中間サーバ１３１４に伝送しそしてそれを更新することが出来る。更新リクエスト１３０４は、異なるビットレートでの、メディアストリームの新しいディストリビューション層に対するリクエストを表すことが出来る。例えば、クライアントデバイス１３１６は、それが、より高いビットレートでメディアストリームを処理することが出来ると決定することが出来る。別の例として、クライアントデバイス１３１６は、それが、この現在のビットレートでは、もはや、メディアストリームのグリッチ又は中断を体験することなく、メディアストリームを処理することは出来ないと決定することができる。

【0096】

いくつかの実施形態では、中間サーバ１３１４は、クライアントデバイス１３１６から更新リクエスト１３０４を受信すると、第２のディストリビューション層１３０５を生成することが出来る。第２のディストリビューション層１３０５は、クライアントデバイス１３１６に最初に送信されたメディアストリーム１３０３のビットレートとは異なる、更新リクエスト１３０４で指定されたビットレートを含むことができる。第２のディストリビューション層１３０５が生成されると、中間サーバ１３１４は、第２のディストリビューション層１３０６をクライアントデバイス１３１６に伝送することが出来る。第２のディストリビューション層１３０６は、メディアストリームの第１のディストリビューション層のキーフレームに対して、時間的にシフトされているキーフレームを、含むことが出来る。

【0097】

いくつかの実施形態では、クライアントデバイス１３１６は、データパス上の更新リクエスト１３０７を中間サーバ１３１４に送信することができる。中間サーバ１３１４は、このリクエスト１３０７を送信元サーバ１３１２に転送することができる。リクエスト１３０７の受信に応答して、送信元サーバ１３１２は、第２のディストリビューション層１３０８を生成することが出来る。送信元サーバ１３１２は、第２のディストリビューション層１３１０を、データパスに沿って中間サーバ１３１４に伝送することが出来る。中間サーバ１３１４は、第２のディストリビューション層１３１０をクライアントデバイス１３１６に転送することができる。

【0098】

（処理システム）
図１４は、本明細書に記載の少なくともいくつかの動作を実施することができる処理システム１４００の例を示すブロック図である。例えば、処理システム１４００のいくつかのコンポーネントは、ストリーミングサーバ（例、図２のストリーミングサーバ２１０）又はクライアントデバイス（例、図３のクライアントデバイス３１４）上でホストさせることができる。

【0099】

処理システム１４００は、１つ又は複数の中央処理ユニット（「プロセッサ」）１４０２、メインメモリ１４０６、不揮発性メモリ１４１０、ネットワークアダプタ１４１２（例、ネットワークインターフェース）、ビデオディスプレイ１４１８、入力／出力デバイス１４２０、制御デバイス１４２２（例、キーボード及びポインティングデバイス）、格納媒体１４２６を含むドライブユニット１４２４、及びバス１４１６に通信可能に接続されたシグナル生成デバイス１４３０を含むことができる。バス１４１６は、適切なブリッジ、アダプタ、又はコントローラによって接続されている１つ又は複数の物理バス及び／又はポイントツーポイント接続を表す抽象化されたものとして示されている。従って、バス１４１６は、システムバス、ＰＣＩ：Peripheral Component Interconnect バス又はＰＣＩ－Ｅｘｐｒｅｓｓバス、ＨｙｐｅｒＴｒａｎｓｐｏｒｔ又は業界標準アーキテクチャ（ＩＳＡ:industry standard architecture）バス、スモールコンピュータシステムインターフェイス（ＳＣＳＩ: small computer system interface）バス、ユニバーサルシリアルバス（ＵＳＢ: universal serial bus）、ＩＩＣ（Ｉ２Ｃ）バス、又は電気電子技術者協会（ＩＥＥＥ; Institute of Electrical and Electronics Engineers）標準１３９４バス（つまり、「Ｆｉｒｅｗｉｒｅ」）を含むことが出来る。

【0100】

処理システム１４００は、デスクトップコンピュータ、タブレットコンピュータ、携帯情報端末（ＰＤＡ: personal digital assistant）、スマートフォン、ゲームコンソール、音楽プレーヤ、ウェアラブル電子デバイス（例、時計又はフィットネストラッカ）、ネットワーク接続された（「スマート」）デバイス（例、テレビ又はホームアシスタントデバイス）、仮想／拡張現実システム（例、ヘッドマウントディスプレイ）、又は処理システム１４００によって実行されるべきアクションを指定する（順次又は他の）命令のシーケンスを実行することができる別の電子デバイスのような、コンピュータプロセッサアーキテクチャを共有することができる。

【0101】

メインメモリ１４０６、不揮発性メモリ１４１０、及び格納媒体１４２６（「マシン可読媒体」とも呼ばれる）は、単一の媒体として示されているが、「マシン可読媒体」及び「格納媒体」という用語は、１つ又は複数のセットの命令１４２８を格納する単一の媒体又は複数の媒体（例、集中型／分散型データベース及び／又は関連付けられているキャッシュ及びサーバ）を含むと解釈されるべきである。「マシン可読媒体」及び「格納媒体」という用語は、また、処理システム１４００によって実行するための命令のシーケンスを記憶、エンコーディング、又は運ぶことができる任意の媒体を含むと解釈されなければならない。

【0102】

一般に、本開示の実施形態を実施するために実行されるルーチンは、オペレーティングシステム又は特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール、又は命令のシーケンス（総称して「コンピュータプログラム」と呼ばれる）の一部として実施させることができる。コンピュータプログラムは、通常、コンピューティングデバイス内の様々なメモリ及び格納デバイスに、様々な時間に設定された１つ又は複数の命令（例、命令１４０４、１４０８、１４２８）を備える。１つ又は複数のプロセッサ１４０２によって読み取られそして実行されると、命令は、処理システム１４００に、本開示の様々な態様を含む要素を実行するための動作を実行させる。

【0103】

さらに、実施形態は、ここまで、完全に機能するコンピューティングデバイスの文脈で説明されてきたが、当業者は、様々な実施形態が、様々な形態のプログラム製品として流通させることができることを理解するであろう。本開示は、実際に流通させるために使用される特定のタイプのマシン又はコンピュータ可読媒体に関わりなく、適用される。

【0104】

マシン可読格納媒体、マシン可読媒体、又はコンピュータ可読媒体のさらなる例には、揮発性及び不揮発性メモリデバイス１４１０、フロッピ及び他のリムーバブルディスク、ハードディスクドライブ、光ディスク（例、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ））、及びデジタル及びアナログ通信リンクのような伝送型メディアのような記録可能型媒体が含まれる。

【0105】

ネットワークアダプタ１４１２は、処理システム１４００が、処理システム１４００及び外部エンティティによってサポートされる任意の通信プロトコルを介して、処理システム１４００の外部にあるエンティティとのネットワーク１４１４内のデータを仲介することを可能にする。ネットワークアダプタ１４１２は、ネットワークアダプタカード、無線ネットワークインターフェースカード、ルータ、アクセスポイント、無線ルータ、スイッチ、多層スイッチ、プロトコルコンバータ、ゲートウェイ、ブリッジ、ブリッジルータ、ハブ、デジタルメディアレシーバ、及び／又はリピータを含むことが出来る。

【0106】

ネットワークアダプタ１４１２は、コンピュータネットワーク内のデータにアクセス／プロキシする許可を決定及び／又は管理し、そして異なるマシン及び／又はアプリケーション間の様々なレベルの信頼を追跡するファイアウォールを含むことができる。ファイアウォールは、特定のセットの、マシンとアプリケーションの間、マシンとマシンの間、及び／又はアプリケーションとアプリケーションの間で所定のアクセス権のセットを（例、これらのエンティティ間のトラフィックとリソース共有のフローを規制するために）実施することができるハードウェア及び／又はソフトウェアコンポーネントの任意の組み合わせを有する任意の数のモジュールとすることができる。ファイアウォールは、さらに、個人、マシン、及び／又はアプリケーションによるオブジェクトのアクセス権及び操作権、並びに許可権が存在する状況を含む許可を詳述するアクセス制御リストを、管理する及び／又はそれにアクセスすることができる。

【0107】

ここで紹介する技術は、プログラム可能な回路（例、１つ又は複数のマイクロプロセッサ）、ソフトウェア及び／又はファームウェア、専用のハードワイヤード（すなわち、プログラム不可能な）回路、又はそのような形態の組み合わせによって実施させることができる。専用回路は、１つ又は複数の、特定用途向け集積回路（ＡＳＩＣ: application-specific integrated circuits）、プログラマブルロジックデバイス（PＬＤ: programmable logic devices ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ: field-programmable gate arrays）等の形式とすることができる。

【0108】

いくつかの実施形態では、任意の適切なエンコーディングプロトコルを利用することができる。例えば、プロトコルＨ．２６４又はＶＰ９を、利用することができそしてこのようなプロトコルの任意の組み合わせに適用することが出来る。

【0109】

（備考）
請求された主題の様々な実施形態の前述の説明は、例示及び説明の目的で提供されて来ている。制限列挙とすること、又はクレームされた主題を開示された正確な形式に限定することは、意図されていない。多くの修正及び変形は、当業者には明らかであろう。実施形態は、本発明の原理及びその実際の用途を最も良く説明するために、選択及び説明された。これにより、関連技術分野の当業者は、請求項に記載される主題、様々な実施形態、及び特定の用途に適した様々な修正を理解することができる。

【0110】

発明の詳細な説明は、特定の実施形態及び企図される最良のモードを説明しているが、発明の詳細な説明がどれほど詳細に表示されていても、この技術は、多くの方法で実施させることが出来る。実施形態は、明細書に含まれているが、それらの実施の詳細ではかなり異なる場合がある。様々な実施形態の特定の特徴又は側面を説明するときに使用される特定の用語は、その用語が関連する技術の特定の特性、特徴、又は側面に限定されるように本明細書で再定義されていることを意味すると解釈されるべきではない。一般に、以下の特許請求の範囲で使用される用語は、それらの用語が本明細書で明示的に定義されない限り、技術を本明細書に開示される特定の実施形態に限定すると解釈されるべきではない。従って、技術の実際の範囲は、開示された実施形態だけでなく、実施形態を実施又は実施する全ての同等の方法も包含する。

【0111】

本明細書で使用される言語は、主に、読みやすさ及び説明目的のために選択されている。これは、主題を描写又は制限するために選択されていない。従って、技術の範囲は、この発明の詳細な説明ではなく、これに基づくアプリケーションについて発行される請求項によって、制限されることが意図されている。従って、様々な実施形態の開示は、以下の特許請求の範囲に記載される技術の範囲を例示することを意図しているが、限定することを意図されていない。

【0112】

（関連出願の相互参照）
本出願は、２０１８年４月２６日に出願された、「ライブブロードキャスティングのための適応ビットレート法」という発明の名称を有する米国仮特許出願シリアルＮｏ．６２／６６３，１８２の利益を主張し、これは、本引用によりその全体が本明細書に組み込まれている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図13】

【図14】