JP6903172B2 - ライブアップリンク適応ストリーミングのための装置および方法 - Google Patents

Description

開示される実施形態は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用するライブアップリンク適応ストリーミングに関連するものである。

アップリンクストリーミング（すなわちクライアントからサーバへのストリーミング）のための最も一般的なストリーミングプロトコルは、Ａｄｏｂｅ社に権利があるリアルタイムメッセージ通信プロトコル（ＲＴＭＰ）である（ｗｗｗ．ａｄｏｂｅ．ｃｏｍ／ｄｅｖｎｅｔ／ｒｔｍｐ．ｈｔｍｌを参照されたい）。最初に、ＲＴＭＰはサーバからクライアントへのフラッシュビデオのストリーミング用に開発された。しかし、今日、ＲＴＭＰはアップリンクストリーミング用に主として使用されている。ＲＴＭＰは、信頼できるアップリンクストリーミング用に送信制御プロトコル（ＴＣＰ）を使用する。ＲＴＭＰはＨＴＴＰと比較して完全な代替案の実現である。ＲＴＭＰストリームはＲＴＭＰプロトコルハンドラ方式（ｒｔｍｐ：／／）によって識別され得、そこで、ｒｔｍｐ：／／ｅｘ．ｃｏｍ／ｌｉｖｅ．ｓｗｆの形式のＵＲＬはアプリケーションによって解釈され得る。

ＲＴＭＰにはいくつかの短所がある。たとえば、規格が、開かれた標準化の団体または共同体によって管理されていないので、ビデオ、オーディオ、またはクローズドキャプション解決策を付加するためのルールもやり方もない。

ＲＴＭＰの別の短所は、ＨＴＴＰほど広範囲に使用されていないことである。それゆえに、ＨＴＴＰを使用してライブアップリンクストリーミングを実施するのが有利であろう。ＨＴＴＰのさらなる利益には、ＨＴＴＰＳのようなすべてのＨＴＴＰ特有のセキュリティ機能またはソース認証が再利用され得ることがある。

２０１５年の通信に関するＩＥＥＥ国際会議（ＩＣＣ）の、Ｃ．Ｌｏｔｔｅｒｍａｎｎら、「Ｎｅｔｗｏｒｋ−Ａｗａｒｅ Ｖｉｄｅｏ Ｌｅｖｅｌ Ｅｎｃｏｄｉｎｇ ｆｏｒ Ｕｐｌｉｎｋ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ」（「Ｌｏｔｔｅｒｍａｎｎ」）は、ＨＴＴＰを使用するアップリンクストリーミングを説明している。しかしながら、Ｌｏｔｔｅｒｍａｎｎにおいて開示されたシステムでは、ビデオパッケージャは、リモートＨＴＴＰクライアントからの要求を受信し、要求に応答してリモートＨＴＴＰクライアントにビデオをストリーミングするように機能するＨＴＴＰサーバと同一場所に配置されている。この実現では、ＨＴＴＰクライアントがインフラストラクチュアに配置され、ＨＴＴＰサーバがクライアントデバイス側（すなわちカメラ側）に据えられる。

Ｌｏｔｔｅｒｍａｎｎにおいて開示されたシステムに関する問題には、アップリンクビデオストリームを生成しようとするユーザの多くが、ファイアウォールまたはたとえば動的ホスト設定プロトコル（ＤＨＣＰ）を使用する動的ＩＰアドレス割り当てと組み合わせて利用ネットワークのアドレス変換機構（ＮＡＴ）など他のセキュリティ機能によって遮蔽して保護されることがある。たとえば、一般的にホームネットワークにおけるデバイスを遮蔽するファイアウォールは、ホームネットワークの外のクライアントが同デバイスに対するＴＣＰ接続を確立することを許容しない（すなわち、外部デバイスから、たとえばＴＣＰまたはＨＴＴＰの接続を使用して住宅内のデバイスに到達することは禁止される）。これはホームネットワークの外部のハッカーからデバイスを保護する。この不利益はモバイル環境にも存在する。一般的には、オペレータは、モバイルデバイス（たとえばスマートフォン）を、ハッキング、サービスの拒否、およびスパム攻撃から保護するために、モバイルデバイスをインターネット方向のトラフィックから遮蔽して保護する。サーバとのセッションを開始または確立することができるのはユーザ（すなわちモバイルデバイス）のみである（その逆ではない）。

本開示は、この不利益を克服する実施形態を説明するものである。実施形態が提供する新規のライブアップリンクビデオの解決策では、提案されたようにＨＴＴＰサーバをクライアントデバイス側（すなわちカメラ側）に配置するのとは反対に、ＨＴＴＰクライアントがカメラ側に配置される。これは、前述のファイアウォール問題を克服する一方で、既存の広く利用可能なＨＴＴＰライブラリおよびインフラストラクチュアを依然として利用可能にするものである。ＴＣＰ上のＨＴＴＰは確実で融通のきくトランスポート機構をもたらす。この融通性は、セッションのスループットが、利用可能なリンクビットレートに、できるだけ迅速に調節されることを保証する。ライブソースが連続的に生成するメディアフレームは、できるだけ迅速にアップロードされるべきである。

本明細書で説明される実施形態では、クライアントデバイス上で作動する（またはクライアントデバイスの比較的近くに配置された）ＨＴＴＰクライアントが、ＨＴＴＰ要求を使用してＨＴＴＰインジェストサーバに対する接続（たとえばＨＴＴＰＳ接続）を確立する。次いで、ＨＴＴＰ要求のＨＴＴＰボディの内部にライブアップリンクメディア（オーディオおよび／またはビデオ）が用意される。ＨＴＴＰクライアントは、ＨＴＴＰボディにメディアコンテンツを直接パイピングするために、ＨＴＴＰ １．０原理またはＨＴＴＰ １．１チャンク転送符号化（Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ Ｅｎｃｏｄｉｎｇ）を使用してよい。ＨＴＴＰチャンク転送符号化は、クライアントが、確立したＴＣＰ接続を後続のＨＴＴＰトランザクションのために再利用することを可能にする（持続性のＴＣＰ接続）。そのゆえに、本明細書では、ＨＴＴＰクライアントからＨＴＴＰサーバへのライブアップリンクストリームのためのＨＴＴＰ要求ボディの使用に関連した実施形態が開示される。とりわけ、これによって、送信ビットレートを利用可能なリンクビットレートに調節するためにＨＴＴＰセッションの信頼性および融通性を導入することが可能になる。

実施形態が提供する新規のレート整合方式は、融通のきくレート整合方式の進行を監視して、クライアントの送信バッファが遅延制約の範囲内でライブビデオフィードをアップロードすることおよび／または過剰なジッタを付加しないことを保証するものである。

実施形態は、新規のライブビデオの解決策を受け入れることができる新規のＨＴＴＰサーバ機能を提供するものである。実施形態では、クライアントは、ＨＴＴＰ要求の範囲内でライブアップリンクビデオを起動し得る。次いで、ＨＴＴＰサーバは、受信したデータチャンクを（たとえば受信したとき、すべてのチャンクを受信する前に）後処理機能に渡してよい。

以下で説明される実施形態は、ライブアップリンクストリーミングを行うために、ＨＴＴＰを、断片化されたＭＰ４（ｆＭＰ４）およびＨＴＴＰチャンク転送符号化と組み合わせて使用するやり方を明示するものである。実施形態が提供するビットレート適応のライブアップリンク解決策は、ＴＣＰレベル再送信、レート制御、および輻輳回避原理を導入することができる（すなわち別個のＵＤＰ再送信サーバは不要である）が、メディアビットレート適応は依然として可能である。

実施形態は、ＭＰＥＧトランスポートストリーム（ＭＰＥＧ２−ＴＳ）、ＭＰＥＧメディアトランスポート（ＭＭＴ）、またはプロプライエタリなＲＴＭＰなどの手法に対する代替形態としてサーブすることができる。

要求から受信したあらゆるデータチャンクを（すなわち、要求からすべてのデータチャンクを受信する前に）デジッタバッファおよびＡＢＲトランスコーダ／パッケージャのような任意の後処理機能へパイピングし始めるように、既存のＨＴＴＰサーバを拡張することに関連した実施形態も開示される。

それゆえに、一態様では、メディアソース（たとえばカメラ）によって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングするためにクライアント装置（「クライアント」）によって実施される方法が提供される。一実施形態では、この方法は、クライアントがサーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することを含む。この方法は、クライアントが、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信することも含み、ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない。この方法は、メディアデータが生成されたとき、クライアントが、ライブメディアフィードに対応するメディアデータを送信バッファに記憶することも含み、メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信することと、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去することと、３）クライアントが、ライブメディアフィードに対応するメディアデータを生成するために使用される品質セッティングを変更するべきかどうかを判定することと、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこととを含む。

いくつかの実施形態ではメディアソースはカメラである。いくつかの実施形態では、カメラはクライアントの一体部品であり、他の実施形態では、カメラは、クライアントから遠隔である（たとえばＢｌｕｅｔｏｏｔｈ接続などのリンクを介してクライアントに接続されたドローン上のカメラ）。実施形態では、トリガは持続時間を指定するスケジュールに基づき、クライアントは、持続時間が過ぎたことを検知した結果としてトリガを検知する。

いくつかの実施形態では、この方法は、クライアントが、第１の品質セッティングを使用して、メディアソースによって生成されたメディアフレームの第１のセットを符号化し、符号化されたメディアフレームの第１のセットを生成することをさらに含む。送信バッファに記憶されたメディアデータは、符号化されたメディアフレームの第１のセットを含み、ＨＴＴＰ要求メッセージのボディを送信するステップは、クライアントが、第１のコーデック設定情報を送信することをさらに含み、第１のコーデック設定情報は第１の品質セッティングを示す情報を含む。この方法は、クライアントが、送信バッファに記憶されたデータ量を監視することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定した結果として、第２の品質セッティングを使用して、メディアソースによって生成されたメディアフレームの第２のセットを符号化し、符号化されたメディアフレームの第２のセットを生成することとをさらに含む。この方法は、クライアントが、ライブメディアフィードに対応するさらなるメディアデータを送信バッファに記憶することをさらに含み、さらなるメディアデータは、符号化されたメディアフレームの第２のセットを含む。ＨＴＴＰ要求メッセージのボディを送信するステップは、クライアントが、第２のコーデック設定情報を送信することをさらに含み、第２のコーデック設定情報は第２の品質セッティングを示す情報を含む。

いくつかの実施形態では、この方法は、クライアントが、メディアソースによって生成されたメディアフレームの第１のセットを符号化して、符号化されたメディアフレームの第１のセットを生成することであって、送信バッファに記憶されたメディアデータが、符号化されたメディアフレームの第１のセットを含む、符号化されたメディアフレームの第１のセットを生成することと、クライアントが、送信バッファに記憶されたデータ量を監視することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定したことの結果として、少なくともメディアフレームの第１のセットのサブセットを、サーバに送信しないように、送信バッファからドロップすることとをさらに含む。いくつかの実施形態では、前記送信バッファが記憶するメディアフラグメントは、メディアフレームの前記サブセットを含み、またメディアフレームのサブセットに関するメタデータをさらに含み、送信バッファからメディアフレームの前記サブセットをドロップするステップは、メディアフラグメントがサーバに送信されないように、送信バッファからメディアフラグメントをドロップすることを含む。

いくつかの実施形態では、この方法は、クライアントが、メディアソースによって生成された非圧縮ビデオフレームを取得することと、クライアントが、非圧縮ビデオフレームを符号化して、符号化されたビデオフレームを生成することと、クライアントが、ｉ）符号化されたビデオフレームおよびｉｉ）符号化されたビデオフレームに関係するメタデータを含むビデオフラグメントを生成することと、クライアントが、このビデオフラグメントを送信バッファに記憶することとをさらに含む。実施形態では、ビデオフラグメントは、ｉ）ＩＳＯ−ＢＭＦＦのビデオフラグメントおよびｉｉ）一般的なメディアアプリケーションフォーマット（ＣＭＡＦ）のビデオフラグメントのうち１つである。

いくつかの実施形態では、ライブフィードは、ライブ配信のために受信エンティティ（サーバ）によってさらに処理され得る。実施形態では、クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤを通じてサーバに送信することは、送信バッファに現在記憶されているメディアデータの少なくとも一部分を含むデータチャンクを送信することを含む。実施形態では、クライアントが、ライブメディアフィードに対応するメディアデータを生成するのに使用される品質セッティングを変更するべきかどうかを前記判定することは、送信バッファレベルおよび／または送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に行われる。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受け取るためにサーバによって実施される方法が提供される。この方法は、クライアントとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信することを含む。ＨＴＴＰヘッダは、ＨＴＴＰ要求メッセージのボディのサイズを示さない。この方法は、ＨＴＴＰヘッダを受信した後にＨＴＴＰ要求メッセージのボディを受信することをさらに含む。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信することと、ＨＴＴＰクライアントから第２のデータチャンクを受信することと、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに第１のデータチャンクを発送することとを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングするための（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアントが提供される。ＨＴＴＰクライアントは、サーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することと、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信することであって、ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない、ＨＴＴＰ要求メッセージをサーバに送信することと、メディアデータが生成されたとき、ライブメディアフィードに対応するメディアデータを送信バッファに記憶することとを行うように適合されている。メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信することと、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去することと、３）クライアントが、ライブメディアフィードに対応するメディアデータを生成するために使用される品質セッティングを変更するべきかどうかを判定することと、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこととを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングするための（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアントが提供される。ＨＴＴＰクライアントは、サーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立するように設定されたトランスポートモジュールと、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信するように設定された送信モジュールであって、ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない、送信モジュールと、メディアデータが生成されたとき、ライブメディアフィードに対応するメディアデータを送信バッファに記憶するように設定されたデータ記憶モジュールとを含む。メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信することと、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去することと、３）クライアントが、送信バッファレベルおよび／または送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に、ライブメディアフィードに対応するメディアデータを生成するために使用される品質セッティングを変更するべきかどうかを判定することと、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこととを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングするための（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアントが提供される。ＨＴＴＰクライアントは、受信器と、送信器と、データ記憶システムと、プロセッサを備えるデータ処理装置とを含む。データ処理装置は、データ記憶システム、送信器、および受信器に結合されており、データ処理装置は、サーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することと、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信することであって、ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない、ＨＴＴＰ要求メッセージをサーバに送信することと、メディアデータが生成されたとき、ライブメディアフィードに対応するメディアデータを、送信バッファに記憶することとを行うように設定されている。メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信することと、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去することと、３）クライアントが、ライブメディアフィードに対応するメディアデータを生成するために使用される品質セッティングを変更するべきかどうかを判定することと、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこととを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信するＨＴＴＰサーバが提供される。ＨＴＴＰサーバは、クライアントとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信するように適合されている。ＨＴＴＰヘッダは、ＨＴＴＰ要求メッセージのボディのサイズを示さない。ＨＴＴＰサーバは、ＨＴＴＰヘッダを受信した後にＨＴＴＰ要求メッセージのボディを受信するようにさらに適合されている。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信することと、ＨＴＴＰクライアントから第２のデータチャンクを受信することと、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに第１のデータチャンクを発送することとを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信するためのＨＴＴＰサーバが提供される。ＨＴＴＰサーバは、クライアントとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信するように設定された第１の受信モジュールであって、ＨＴＴＰヘッダがＨＴＴＰ要求メッセージのボディのサイズを示さない第１の受信モジュールと、第１の受信モジュールによってＨＴＴＰヘッダを受信した後に、ＨＴＴＰ要求メッセージのボディを受信するように設定された第２の受信モジュールとを含む。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信することと、ＨＴＴＰクライアントから第２のデータチャンクを受信することと、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、発送モジュールによって配信システムに第１のデータチャンクを発送することとを含む。

別の態様では、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信するためのＨＴＴＰサーバが提供される。ＨＴＴＰサーバは、受信器と、送信器と、データ記憶システムと、データ記憶システムに結合されたプロセッサを備えるデータ処理装置とを含む。送信器、受信器、およびデータ処理装置は、クライアント（１０２）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのための、ＨＴＴＰ要求メッセージのボディのサイズを示さないハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信することと、ＨＴＴＰヘッダを受信した後にＨＴＴＰ要求メッセージのボディを受信することとを行うように設定されている。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信することと、ＨＴＴＰクライアントから第２のデータチャンクを受信することと、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに第１のデータチャンクを発送することとを含む。

上記の実施形態および他の実施形態が以下で説明される。

添付の図面は本明細書に組み込まれて本明細書の一部分を形成し、様々な実施形態を図示するものである。

いくつかの実施形態によるネットワークアーキテクチャの図示である。 いくつかの実施形態によってフラグメントに分解されたメディアストリームの図示である。 いくつかの実施形態によるネットワークアーキテクチャの図示である。 いくつかの実施形態によるバッファサイズと符号化品質の間の関係を示すグラフである。 いくつかの実施形態による処理の流れ図である。 いくつかの実施形態による処理の流れ図である。 いくつかの実施形態による処理の流れ図である。 いくつかの実施形態によるＨＴＴＰクライアントの機能モジュールを示す図である。 いくつかの実施形態によるＨＴＴＰサーバの機能モジュールを示す図である。 いくつかの実施形態によるＨＴＴＰクライアントのブロック図である。 いくつかの実施形態によるＨＴＴＰサーバのブロック図である。

図１は例示的実施形態のエンドツーエンドアーキテクチャを図示するものである。示されるように、クライアント装置１０２（略して「クライアント１０２」）は、ＨＴＴＰサーバ１０６（インジェストサーバとも呼ばれる）を備えるメディア処理ユニット１０４と通信している。これは、寄与リンクすなわちクライアント１０２（すなわちメディアソース）からメディア処理ユニット１０４（すなわちメディアシンク）へのリンク（別名「インジェストリンク」）を形成する。メディア処理ユニット１０４はトランスコーダパッケージャ１０８（たとえば適応ビットレート（ＡＢＲ）トランスコーダ）をさらに含み得る。ライン１０７によって示されるように、ＨＴＴＰサーバ１０６（入口）はトランスコーダパッケージャ１０８（出口）から切り離されてよく、すなわち、メディア処理ユニット１０４は、いくつかの実施形態では単一の物理ユニットでよく、いくつかの実施形態では、別個の物理デバイス上に存在するサーバ機能およびトランスコーダパッケージャ機能を備え得る。トランスコーダパッケージャ１０８はコンテンツ配信ネットワーク（ＣＤＮ）１１０と通信してよく、ＣＤＮ １１０は、エンドユーザ受信器１１２に、パッケージ化されたメディアをさらに発送する。トランスコーダパッケージャ１０８、ＣＤＮ １１０、および受信器１１２は配送システムを備える。

全体にわたってカメラという用語が使用されているが、任意のメディアソース（たとえばマイクロフォン）が使用され得ることを理解されたい。

実施形態は、カメラ（たとえばモバイルカメラ）からインジェストサーバへの寄与リンクに対する改善を提供するものである。寄与リンクはコンテンツ準備パイプへのアップリンクである。概念的に、これは、たとえばＣＤＮを通じたＤＡＳＨを使用する配信準備のためのスクリーニング機能、ＡＢＲをコード変換してパッケージ化する機能を含んでよく、あるいは、それらの機能のいくつかまたはすべてが寄与リンクから切り離されてよく、配送システムの一部分と見なされ得る。

インジェストのために、ＨＴＴＰインジェストサーバの解決策が提案される。ＨＴＴＰインジェストサーバ１０６は、（任意の他のウェブサーバのように）入力を求めてリッスンする。一般的には、ＨＴＴＰトラフィック用にはＴＣＰポート８０または４４３が使用されるが、他のポートも可能である。ＨＴＴＰインジェストサーバ１０６は、安全なＨＴＴＰＳ接続が確立される前に、クライアントの認可と認証のためのセキュリティ機能をサポートし得る。ここで、ＨＴＴＰという用語は、すべてのＨＴＴＰトランザクションが安全にされ得るので、ＨＴＴＰＳと同義的に使用される。

ＨＴＴＰインジェストサーバ１０６は、全部のＨＴＴＰ要求を受信する前に、後続の処理機能（たとえばＡＢＲコード変換およびパッケージング）に、データを（受信したとき）直ちに発送するように実施され得る。この挙動は、ＨＴＴＰサーバが、要求の処理が起動される前にＨＴＴＰ要求のすべてのデータを最初に受信する必要があり得る従来技術の解決策とは対照的である。現在説明されている実施形態では、ＨＴＴＰ入口サーバ１０６は、ＡＢＲトランスコーダパッケージャ１０８のように、あらゆる受信されたＨＴＴＰチャンクを後続の機能にパイピングする。このパイプラインには他の処理機能も採用され得る。たとえば、ＡＢＲトランスコーダ（図３のデジッタバッファ３１４など）への連続入力を保証するために、ＡＢＲトランスコーダの前にデジッタバッファも配置され得る。後処理機能は、ＨＴＴＰインジェストサーバ１０６と同一の場所に配置されてよく、または分散されてよい。分散される場合には、ＨＴＴＰインジェストサーバ１０６は、たとえばＨＴＴＰまたは他のプロトコルを使用して、ネットワークを通じて後処理機能にデータをパイピングしてよい。

次いで、ＡＢＲトランスコーダおよびパッケージャ機能は、インジェストの後に、配信するためのコンテンツを準備する。コード変換パラメータは、クライアント１０２による影響を受ける可能性があり、クライアントからインジェストへのアップリンク品質に依拠し得る。

ＨＴＴＰインジェストサーバ１０６は、受信されたＨＴＴＰ要求のボディ部分を（たとえばチャンク配送または無制約のボディサイズを使用して）処理することにより、ビデオをインジェストしてよい。無制約のボディサイズを使用する場合、クライアント１０２は、ＴＣＰ接続を終了してアップロードを終了し得る。チャンク配送を使用する場合、クライアント１０２は、アップロードを停止して、後続のトランザクション（たとえばビデオの解像度の変更）のためにＴＣＰ接続を再利用することができる。

図２は、ＨＴＴＰインジェストサーバ１０６によるインジェストを容易にするためにビデオが分割される様子を図示するものである。示された例では、クライアント１０２は、符号化されたビデオフレームの連続したストリームを生成する。１つまたは複数のそのようなフレームが単一のフラグメント（たとえば一般的なメディアアプリケーションフォーマット（ＣＭＡＦ）のチャンク）（たとえばフラグメント２１０、２１２、２１４、２１６）へと収集され得る。ＣＭＡＦチャンクがイントラフレームを含む必要はない。ＣＭＡＦチャンクは、示されたように、少なくともｍｏｏｆボックスおよびｍｄａｔボックスを含む。コーデック設定のために、先頭に初期化セグメント２０２（ｍｏｏｖボックスを含む）が追加される。

図２に示されるように、長さが未定義のＨＴＴＰボディを有するＨＴＴＰ １．０タイプの実現が使用される。別の実現は、ＨＴＴＰチャンク転送符号化を使用するものであろう。（たとえばＨＴＴＰ １．１規格によって規定されるような）ＨＴＴＰチャンクは、１つまたは複数のフラグメント（またはＣＭＡＦチャンク）を含み得ることに留意されたい。さらに、フラグメントは１つまたは複数のＨＴＴＰチャンクに区分され得る。ＨＴＴＰチャンクとフラグメントの間に従属性はないが、いくつかの実施形態では単一のフラグメントは単一のＨＴＴＰチャンクに含まれる。

図３は、いくつかの実施形態によるクライアント１０２およびＨＴＴＰインジェストサーバ１０６を図示するものである。

クライアント１０２は、非圧縮フレームの連続シーケンスを所与のフレームレートで供給するカメラ３０２を含む。次いで、エンコーダ３０４は、入力として一連の非圧縮フレームを取得し、出力として一連の圧縮フレームを生成する。圧縮フレームは、ピクチャのグループ（ＧＯＰ）構造の内部に構築される。次いで、パッケージャ３０６は１つまたは複数のフレーム（ＧＯＰ構造を有する）を収集してフラグメントへとパッケージ化する。フラグメントは、ＣＭＡＦチャンク（たとえば少なくとも１つのムービーフラグメントボックス（ｍｏｏｆ）区分および１つのメディアデータボックス（ｍｄａｔ）区分（任意選択の他のＩＳＯ−ＢＭＦＦボックスを有する））、ＩＳＯ−ＢＭＦＦフラグメントまたは他の適切な構造であり得る。結果として、各フラグメント（一定の秒数の圧縮メディアデータを含む）は、一定のサイズを有する。次いで、パッケージャ３０６は、フラグメントの内部の圧縮メディアデータの量に応じて一定間隔でフラグメントを出力する。

パッケージャ３０６はバッファ３０８にフラグメント（たとえばＣＭＡＦチャンク）を書き込み、これはバッファモニタ３０９によって監視される。ＨＴＴＰ要求によりＨＴＴＰ接続を開始したＨＴＴＰクライアント３１０は、ＨＴＴＰ要求のボディを作成するためにバッファ３０８からフラグメントのバイト（たとえばＣＭＡＦチャンク）を受信する。バッファモニタ３０９は、バッファ３０８の排出を含むアップロード処理を監視する。バッファレベル（またはサイズ）が上昇したとき（すなわちバッファにおけるデータ量が閾値に達したとき）、モニタ３０９は、制御指令を起動して符号化処理を修正するかまたは他の方策を採用する。示されるように、これは、エンコーダ３０４とパッケージャ３０６とモニタ３０９の間のフィードバックループの形をとり得る。ＨＴＴＰクライアント３１０はＨＴＴＰインジェストサーバ１０６にデータ（たとえばバイトまたはＨＴＴＰチャンク）を送る。

クライアント１０２はトリガソース３１１も含み得る。いくつかの実施形態では、トリガソースはスケジューラでよい（たとえば指定された時間および／または時間間隔において、メディアフィードの始動や停止をトリガする、またはメディアフィードの始動をトリガする）。いくつかの実施形態では、トリガソース３１１はバッファモニタ３０９（たとえば解像度が変化した、または解像度の変化が予期される、という指示）に由来し得る。トリガソース３１１はクライアント１０２の一部分として表現されているが、いくつかの実施形態では、トリガソース３１１はクライアント１０２の外部にもあり得る。

クライアント１０２のモジュール３０２〜３１１はすべて同一ハウジングの内部に収容されてよく、別個のハウジングに収容されてもよい。たとえば、モジュール３０２〜３１１は、すべて移動体通信デバイス（ＭＣＤ）（たとえばスマートフォン、タブレット、ラップトップコンピュータ）の構成要素であり、ＭＣＤのハウジングの内部に収容されている。別の例として、カメラ３０２は第１のデバイス（たとえばドローン）の一部分でよく、他の構成要素３０４〜３１１は分離したデバイス（たとえばスマートフォン、ラップトップ、タブレット）の一部分でよい。そのような実施形態では、カメラ３０２とエンコーダ３０４は無線リンクによって通信可能に接続され得る。いくつかの実施形態では、クライアント１０２はパッケージャ３０６を含まない。

示された実施形態では、ＨＴＴＰインジェストサーバ１０６はＨＴＴＰサーバ３１２およびデジッタバッファ３１４を含む。

図４は、いくつかの実施形態においてバッファモニタ３０９が機能し得る様子の例示的説明を図示するものである。縦軸に沿って、符号化品質は、「フレームドロッピング」から、「低品質」（ＬＱ）、「中品質」（ＭＱ）、および「高品質」（ＨＱ）へと向上する。バッファサイズ（バッファ３０８に記憶されるメディア時間がミリ秒で表現されている）は、横軸に沿って０ｍｓから８００ｍｓに及ぶ。示されるように、バッファ３０８のサイズが第１の閾値（ここでは２００ｍｓ）未満であれば、符号化品質はＨＱである。バッファ３０８のサイズが第１の閾値を上回って第２の閾値（ここでは４００ｍｓ）未満であると、符号化品質はＭＱに劣化され得る。バッファ３０８のサイズが第２の閾値を上回って第３の閾値（ここでは６００ｍｓ）未満であると、符号化品質はＬＱにさらに劣化され得る。バッファ３０８のサイズが第３の閾値を上回ると、符号化品質は、フレームドロッピングを採用することによってさらに劣化され得る。バッファモニタ３０９は、バッファ３０８のサイズを監視して、満足すべきライブストリーミングＱｏＳパラメータを維持するために特定の符号化方策を採用する。バッファ３０８が満たされるにつれて符号化の品質を劣化させることに加えて、反対の処理（すなわちバッファサイズが縮小するとき符号化の品質を改善すること）も採用されてよい。バッファモニタ３０９は、バッファ３０８の現行のサイズのみを検討すればよく、またはバッファサイズを時間の関数と見なして、適切な符号化パラメータを判定するとき、過去のバッファサイズ（または予測される将来のサイズ）を考慮に入れてよい。

このように、高品質（ＨＱ）、中品質（ＭＱ）、および低品質（ＬＱ）の符号化は異なるコーデック設定を指し、異なる視覚品質をもたらし得る。いくつかの実施形態では、バッファモニタ３０９は、エンコーダの量子化パラメータを変更して、符号化されたビデオのビットレートを変化させてよい。

バッファモニタ３０９は、いくつかの実施形態では、バッファ３０８のバッファレベルを連続的に検査する。バッファに新規のＣＭＡＦチャンクを追加するときバッファ３０８が空であれば、バッファモニタ３０９は行動しない。バッファレベルが上昇するとき（メディア時間が圧縮されることで示される）、バッファモニタ３０９は制御動作を採用する。最初のアクションはビデオ品質（たとえばビットレート）を低下させるものであり得る。バッファレベルが依然として低下しなければ、バッファモニタ３０９は、バッファ３０８からフレーム、ＣＭＡＦチャンク、またはフラグメントをドロップし始めてよい。個々のフレームをドロップするときには、ＧＯＰの端からのフレームのみをドロップするべきである。ＧＯＰはピクチャのグループであり、従属するピクチャのセットは、独立して復号することができるフレームと一緒にグループ化されている。

各フラグメントが、単一のビデオフレーム（またはＩＳＯ−ＢＭＦＦ用語のサンプル）までの少数のフレームなどＧＯＰの一部分しか含まないとき、バッファモニタ３０９は十分なフラグメントをドロップすることができる。その際、バッファモニタ３０９は、フレーム間の符号化の従属性も考慮に入れてよい（その結果、フレームのドロップは、品質の低下を最小限にするために、ランダムではなく、選択的かつインテリジェントに実施される）。バッファモニタ３０９は、（たとえばフラグメントが全体のＧＯＰを含む場合）フラグメントを編集する（または書き換える）ことによってデータを除去してもよい。たとえば、バッファモニタ３０９は、メディアデータボックス（ｍｄａｔ）から一定のビデオフレームのデータを除去し、それに応じてボックスを縮小してよい。トラックフラグメントランボックス（ｔｒｕｎ）は、メディアデータボックス（ｍｄａｔ）のあらゆるサンプル（またはビデオフレーム）のエントリを、サンプルタイミングおよびサンプルサイズとともに含む。フラグメントからサンプルを除去するとき、ｔｒｕｎボックスから対応するサンプルエントリを除去して相当する量だけｔｒｕｎボックスのサイズを縮小することなどにより、ｔｒｕｎボックスを調節する必要がある。いくつかの実施形態では、バッファモニタ３０９が完結したフレームを容易にドロップし得るように、フラグメントは、ＧＯＰの（全体ではなく）一部分のみを搬送するように構築される。各フラグメントが含むフレームが１つだけのとき、バッファモニタ３０９は、いかなるフラグメントボックスも書き換えることなく個別のフレームをドロップすることができる。

ＧＯＰ構造がＩ１、Ｂ１、Ｐ１、Ｂ２、Ｐ２、Ｂ３、Ｐ３、Ｂ４を有する（ＧＯＰサイズ＝８フレーム）と想定する。この表記法では、Ｉ１は独立して復号され得るピクチャであり、一般的にはＩフレーム、イントラフレーム、キーフレーム、ストリームへのランダムアクセスポイント、またはストリームへのサービスアクセスポイントと称され、ＰピクチャはＩフレームまたは他のＰフレームに依拠する予測されたピクチャであり、またＢフレームは、少なくとも２つの他のフレーム（Ｉ、ＰまたはＢ）に依拠する双方向の予測されたフレームである。他のフレームおよび従属フレームのフレーム構築が可能である。

フラグメントが単一のフレーム（またはピクチャ）を含んでいるとき、各フレームはフラグメントにパックされる。この例では、バッファモニタ３０９がフレームをドロップするなら、最初にフレームＢ４、続けてそれぞれフレームＢ３、Ｂ２、Ｂ１、Ｐ３、Ｐ２、Ｐ１をドロップすることになる。

ＧＯＰ構造がＩ１、Ｐ１、Ｐ２、Ｐ３、Ｐ４、Ｐ５、Ｐ６、Ｐ７を有する（ＧＯＰサイズ＝８フレーム）と想定する。

この例では、バッファモニタ３０９は、フレームを、Ｐ７に続けてＰ６、Ｐ５、Ｐ４、Ｐ３、Ｐ２、Ｐ１とドロップするべきである。

いくつかの実施形態では、フレームドロッピングは、フレーム従属性を考慮に入れて、左から始めて右へ行われる。

制御機能が解像度または他の符号化構造パラメータを変更するとき（たとえばシーケンスパラメータのセット（ＳＰＳ）またはピクチャパラメータのセット（ＰＰＳ）が変更される場合）、ＨＴＴＰクライアント３１０は、アップロードを停止して新規の初期化セグメントから開始する必要がある。

図５は、ＨＴＴＰチャンク転送符号化を使用する連続したアップロードのための例示的コールフローを図示するものである。

ＨＴＴＰクライアント３１０は、要求および要求ヘッダを用いてＨＴＴＰセッションを開始する。ＨＴＴＰクライアント３１０は、要求ボディのために、ＨＴＴＰチャンクをアップロードするためにバッファ３０８から読み取る。各ＨＴＴＰチャンクはチャンクサイズから始まり、チャンクが続く。いくつかの実施形態では、各ＨＴＴＰチャンクはＣＭＡＦチャンクに対応するが、技術的には整列要求はない。

ＨＴＴＰ要求が進行中のため、ＨＴＴＰサーバ３１２からのＨＴＴＰ応答はない。ＨＴＴＰクライアント３１０がゼロサイズのＨＴＴＰチャンクを用いてＨＴＴＰボディを終了しているときに限り、サーバは「２００ ＯＫ」または「２０１ Ｃｒｅａｔｅｄ」のようなＨＴＴＰ応答コードを用いて応答する。

チャンク転送符号化を使用しない実施形態（たとえば転送符号化が利用不可能なＨＴＴＰ １．０トランザクション）では、ＨＴＴＰクライアント３１０がＴＣＰ接続を終了する必要がある。

チャンク転送符号化を使用する実施形態では、（表現されたように）後続のＨＴＴＰトランザクションのために既存のＴＣＰ接続を再利用することが可能である。ＨＴＴＰチャンク転送符号化の利益は、ＨＴＴＰボディがＨＴＴＰトランザクションの開始において未知のサイズを有することができ、確立されたＴＣＰ接続を再利用することが可能なことである（持続性のＴＣＰ接続）。

この実施形態では、ＨＴＴＰクライアント３１０が、（「無限に」データを生成している）ライブソースから入力データを受信するので、ＨＴＴＰトランザクションの終了をトリガするには外部イベントが必要である。外部イベントは、ライブフィードの最後またはライブフィードの解像度変更（たとえばバッファサイズが大きすぎるときバッファモニタ３０９によって起動される）であり得る。解像度変更の場合には、ＨＴＴＰクライアント３１０は新規のコーデック設定および初期化パラメータ（たとえば新規のｍｏｏｖボックス）を送る必要がある。この場合、バッファモニタ３０９（外部トリガとして働いている）は、コーデック設定（たとえばビデオ解像度）を変更する必要性を検知して、符号化処理を停止し、ＨＴＴＰクライアント３１０による、ＨＴＴＰチャンクのアップリンクトラフィックの停止をトリガする（しかしＴＣＰ接続は確立したままである）。次いで、エンコーダ処理は、異なる解像度（または異なるコーデック設定またはそうでなければ異なる符号化パラメータ）を用いて再開するべきである（すなわち、エンコーダ３０４はビデオフレームの生成を再開するべきである）。エンコーダ３０４はまず、コーデック設定を含む初期化セグメント（たとえばＩＳＯ ＢＭＦＦ ｍｏｏｖボックス）を吐き出す。次いで、エンコーダ３０４は、パッケージャ３０６によって、バッファモニタ３０９のアップロードバッファに、圧縮されたビデオフレームを供給する。

一実施形態では、ＨＴＴＰクライアント３１０またはバッファモニタ３０９は、新規のコーデック設定を用いてエンコーダ３０４を再始動する前に、バッファ３０８からすべてのデータを棄却する。別の実施形態では、バッファ３０８からの古いデータは、ビデオタイムラインにおけるギャップを回避するために維持される。たとえば、アップロードされていない、バッファ３０８におけるあらゆるデータが、ビデオシーケンスにおけるフレームに対応する。

いくつかのエンコーダは、目標ビットレートのような符号化設定に対する（たとえば量子化パラメータ（ＱＰ）を変更することによる）変更を許容しない可能性がある。その場合、クライアントは、変更されたコーデック設定パラメータを用いてエンコーダ３０４を再始動するが、新規の初期化セグメント（たとえばｍｏｏｖボックス）は生成しない。

実施形態は、使用事例に依拠して、外部トリガのそれ以上の実現をサポートする。自動操縦のドローンまたはボディカメラもしくは監視カメラのようないくつかの使用事例では、遠隔オペレータは、（たとえば品質向上またはバッファ遅延短縮のために）解像度変更を起動することができる。別の外部トリガにはプログラムドスケジュールがあり得、カメラは、一定時間の間のみ記録するように（すなわち開始時間および停止時間のトリガに）、または一定の期間にわたってのみ記録するように（すなわち停止時間のみのトリガに）プログラムされる。

たとえば輻輳制御および再送信のために、サーバからのＴＣＰレベルトランザクションがある。

ＨＴＴＰチャンク配送を使用するアップリンクライブストリームのための例示のＨＴＴＰ要求は以下の通りである。

この例では、ここで、アップリンクストリームを示すためのＨＴＴＰの方法としてＨＴＴＰ ＰＯＳＴが使用される。別の解決策にはＨＴＴＰ ＰＵＴを使用するものがあり得る。ＨＴＴＰ要求におけるＨＴＴＰのＵＲＬ（ここでは／ｕｐｌｏａｄ／ｘｙｚ／ｌｉｖｅ−ｓｅｓｓｉｏｎ１．ｍｐ４）は、アップリンクストリーミングセッションの目標チャネルを示す。ＵＲＬはアカウントに特化された保証付きのものであり、そのため、アップロードすることができるのは認可された送り手のみである。アカウント所有者は、データを送ることを許容された送り手を認可する。

この例では、未知のＨＴＴＰボディサイズを示すコンテンツ長ＨＴＴＰヘッダはない。ＨＴＴＰチャンク転送符号化はヘッダの中に示されており、（すなわち「Ｔｒａｎｓｆｅｒ−Ｅｎｃｏｄｉｎｇ： ｃｈｕｎｋｅｄ」）ＨＴＴＰボディが一連のＨＴＴＰチャンクであると示す。

図６は処理６００を図示するものである。処理６００は、たとえばクライアント（たとえばクライアント装置１０２）によって実施され得る。クライアントは、サーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立する（ステップ６０２）。クライアントは、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信する（ステップ６０４）。ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない。クライアントは、メディアデータが生成されたとき、ライブメディアフィードに対応するメディアデータを送信バッファに記憶する（ステップ６０６）。メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信すること（ステップ６０８）と、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去すること（ステップ６１０）と、３）クライアントが、送信バッファレベルおよび／または送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に、ライブメディアフィードに対応するメディアデータを生成するのに使用される品質セッティングを変更するべきかどうかを判定すること（ステップ６１２）と、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこと（ステップ６１４）とを含む。

いくつかの実施形態では、メディアソースはカメラであり、実施形態ではカメラはクライアントの一体部品でよく、またはクライアントから遠隔でよい（たとえばＢｌｕｅｔｏｏｔｈ接続などのリンクを通じてクライアントに接続されたドローン上のカメラ）。いくつかの実施形態では、トリガは持続時間を指定するスケジュールに基づき、クライアントは、持続時間が過ぎたことを検知した結果としてトリガを検知する。

いくつかの実施形態では、この処理は、クライアントが、第１の品質セッティングを使用して、メディアソースによって生成されたメディアフレームの第１のセットを符号化し、符号化されたメディアフレームの第１のセットを生成することをさらに含む。送信バッファに記憶されたメディアデータが、符号化されたメディアフレームの第１のセットを含む。ＨＴＴＰ要求メッセージのボディを送信するステップは、クライアントが第１のコーデック設定情報を送信することをさらに含む。第１のコーデック設定情報は、第１の品質セッティングを示す情報を含む。この処理は、クライアントが、送信バッファに記憶されたデータ量を監視することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定することとをさらに含む。この処理は、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定した結果として、第２の品質セッティングを使用して、メディアソースによって生成されたメディアフレームの第２のセットを符号化し、符号化されたメディアフレームの第２のセットを生成することをさらに含む。この処理は、クライアントが、ライブメディアフィードに対応するさらなるメディアデータを送信バッファに記憶することをさらに含む。さらなるメディアデータは、符号化されたメディアフレームの第２のセットを含む。ＨＴＴＰ要求メッセージのボディを送信するステップは、クライアントが第２のコーデック設定情報を送信することをさらに含む。第２のコーデック設定情報は、第２の品質セッティングを示す情報を含む。

いくつかの実施形態では、この処理は、クライアントが、メディアソースによって生成されたメディアフレームの第１のセットを符号化して、符号化されたメディアフレームの第１のセットを生成することをさらに含む。送信バッファに記憶されたメディアデータが、符号化されたメディアフレームの第１のセットを含む。この処理は、クライアントが、送信バッファに記憶されたデータ量を監視することと、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定することとをさらに含む。この処理は、クライアントが、送信バッファに記憶されたデータ量が閾値を超えたと判定したことの結果として、少なくともメディアフレームの第１のセットのサブセットを、サーバに送信しないように、送信バッファからドロップすることをさらに含む。

いくつかの実施形態では、送信バッファが記憶するメディアフラグメントは、メディアフレームのサブセットを含み、またメディアフレームのサブセットに関するメタデータをさらに含み、送信バッファからメディアフレームのサブセットをドロップするステップは、メディアフラグメントがサーバに送信されないように、送信バッファからメディアフラグメントをドロップすることを含む。いくつかの実施形態では、この処理は、クライアントが、メディアソースによって生成された非圧縮ビデオフレームを取得することと、クライアントが、非圧縮ビデオフレームを符号化して、符号化されたビデオフレームを生成することと、クライアントが、ｉ）符号化されたビデオフレームおよびｉｉ）符号化されたビデオフレームに関係するメタデータを含むビデオフラグメントを生成することと、クライアントが、このビデオフラグメントを送信バッファに記憶することとをさらに含む。

いくつかの実施形態では、ビデオフラグメントは、ｉ）ＩＳＯ−ＢＭＦＦのビデオフラグメントおよびｉｉ）一般的なメディアアプリケーションフォーマット（ＣＭＡＦ）のビデオフラグメントのうち１つである。いくつかの実施形態では、ライブフィードは、ライブ配信のために受信エンティティ（サーバ）によってさらに処理され得る。

いくつかの実施形態によれば、（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアントは、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングする処理６００を実施するように適合されている。いくつかの実施形態によれば、ＨＴＴＰクライアントは、受信器と、送信器と、データ記憶システムと、プロセッサを備えるデータ処理装置とを含み、データ処理装置は、処理６００を実施するように設定されて、データ記憶システム、送信器、および受信器に結合されている。

図７は処理７００を図示するものである。処理７００は、ＨＴＴＰサーバ（たとえばＨＴＴＰインジェストサーバ１０６）によって、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信するために実施され得る。ＨＴＴＰサーバ１０６は、クライアントとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信する（ステップ７０２）。ＨＴＴＰヘッダは、ＨＴＴＰ要求メッセージのボディのサイズを示さない。ＨＴＴＰサーバ１０６は、ＨＴＴＰヘッダを受信した後にＨＴＴＰ要求メッセージのボディを受信する（ステップ７０４）。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信すること（ステップ７０６）と、ＨＴＴＰクライアントから第２のデータチャンクを受信すること（ステップ７０８）と、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに第１のデータチャンクを発送すること（ステップ７１０）とを含む。

いくつかの実施形態によれば、ＨＴＴＰサーバは、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信する処理７００を実施するように適合されている。いくつかの実施形態によれば、ＨＴＴＰサーバは、受信器と、送信器と、データ記憶システムと、プロセッサを備えるデータ処理装置とを含み、データ処理装置は、処理７００を実施するように設定されて、データ記憶システム、送信器、および受信器に結合されている。

図８は、いくつかの実施形態によるＨＴＴＰクライアント８００の機能モジュールを示す図である。図８に示されるように、ＨＴＴＰクライアント８００は、トランスポートモジュール８０２、送信モジュール８０４、およびデータ記憶モジュール８０６を含む。ＨＴＴＰクライアント８００は、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバにアップストリーミングするために使用され得る。トランスポートモジュール８０２は、サーバとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立するように設定されている。送信モジュール８０４は、トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージをサーバに送信するように設定されている。ＨＴＴＰ要求メッセージのヘッダはＨＴＴＰ要求メッセージのボディのサイズを示さない。データ記憶モジュール８０６は、メディアデータが生成されたとき、ライブメディアフィードに対応するメディアデータを、送信バッファに記憶するように設定されている。メディアデータを生成するために品質セッティングが使用される。トランスポートレイヤ接続を通じてサーバにＨＴＴＰ要求メッセージのボディを送信することは、１）クライアントが、送信バッファに現在記憶されているメディアデータの少なくとも一部分を、トランスポートレイヤ接続を通じてサーバに送信することと、２）クライアントが、メディアデータの前記少なくとも一部分を送信バッファから除去することと、３）クライアントが、送信バッファレベルおよび／または送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に、ライブメディアフィードに対応するメディアデータを生成するために使用される品質セッティングを変更するべきかどうかを判定することと、４）クライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すこととを含む。

図９は、いくつかの実施形態によるＨＴＴＰサーバ９００の機能モジュールを示す図である。図９に示されるように、ＨＴＴＰサーバ９００は、第１の受信モジュール９０２、第２の受信モジュール９０４、および発送モジュール９０６を含む。ＨＴＴＰサーバ９００は、メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアントから受信するために使用され得る。第１の受信モジュール９０２は、クライアントとのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信するように設定されている。ＨＴＴＰヘッダは、ＨＴＴＰ要求メッセージのボディのサイズを示さない。第２の受信モジュール９０４は、第１の受信モジュールによってＨＴＴＰヘッダを受信した後に、ＨＴＴＰ要求メッセージのボディを受信するように設定されている。ＨＴＴＰ要求メッセージのボディを受信することは、ＨＴＴＰクライアントから第１のデータチャンクを受信することと、ＨＴＴＰクライアントから第２のデータチャンクを受信することと、第１のデータチャンクを受信した後、第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、発送モジュール９０６によって配信システムに第１のデータチャンクを発送することとを含む。

図１０は、いくつかの実施形態によるＨＴＴＰクライアント１０２のブロック図である。図１０に示されるように、ＨＴＴＰクライアント１０２は、１つまたは複数のプロセッサ（Ｐ）１０５５（たとえば汎用マイクロプロセッサ、および／または、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つもしくは複数の他のプロセッサ）を含み得るデータ処理装置（ＤＰＡ）１００２と、ＨＴＴＰクライアント１０２が、ＡＮノード（たとえば基地局）にデータを送信することを可能にするための送信器１００５、およびＡＮノードからデータを受信することを可能にするための受信器１００４（どちらもアンテナ１０２２に結合されている）と、１つもしくは複数の不揮発性記憶デバイスおよび／または１つもしくは複数の揮発性記憶デバイス（たとえばランダムアクセスメモリ（ＲＡＭ））を含み得るローカル記憶ユニット（別名「データ記憶システム」）１００８とを備え得る。ＨＴＴＰクライアント１０２が汎用マイクロプロセッサを含む実施形態では、コンピュータプログラム製品（ＣＰＰ）１０４１が提供され得る。ＣＰＰ １０４１は、コンピュータ可読命令（ＣＲＩ）１０４４を含むコンピュータプログラム（ＣＰ）１０４３を記憶しているコンピュータ可読媒体（ＣＲＭ）１０４２を含む。ＣＲＭ １０４２は、それだけではないが、磁気媒体（たとえばハードディスク）、光媒体、メモリデバイス（たとえばランダムアクセスメモリ）などの非一時的コンピュータ可読媒体でよい。いくつかの実施形態では、コンピュータプログラム１０４３のＣＲＩ １０４４は、データ処理装置１００２によって実行されたとき、ＨＴＴＰクライアント１０２に、上記で説明されたステップ（たとえば流れ図を参照しながら上記で説明されたステップ）を実施させるように設定されている。他の実施形態では、ＨＴＴＰクライアント１０２は、コードを必要とすることなく本明細書で説明されたステップを実施するように設定され得る。すなわち、たとえば、データ処理装置１００２は、単に１つまたは複数のＡＳＩＣから成るものでよい。よって、本明細書で説明された実施形態の機能はハードウェアおよび／またはソフトウェアで実施され得る。

図１１は、いくつかの実施形態によるＨＴＴＰサーバ１０６のブロック図である。図１１に示されるように、ＨＴＴＰサーバ１０６は、１つまたは複数のプロセッサ（Ｐ）１１５５（たとえば汎用マイクロプロセッサ、および／または、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つもしくは複数の他のプロセッサ）を含み得るデータ処理装置（ＤＰＡ）１１０２と、ＨＴＴＰサーバ１０６が、ネットワーク１１０に接続された他のノードにデータを送信することを可能にするための送信器（Ｔｘ）１１４５、および同ノードからデータを受信することを可能にするための受信器（Ｒｘ）１１４７を備えるネットワークインターフェース１１４８（たとえばインターネットプロトコル（ＩＰ）ネットワーク）であって、ネットワーク１１０に接続されているネットワークインターフェース１１４８と、ＵＥとの無線通信のためにアンテナシステム１１０４に結合されたサーキットリ１１０３（たとえば無線トランシーバサーキットリ）と、１つもしくは複数の不揮発性記憶デバイスおよび／または１つもしくは複数の揮発性記憶デバイス（たとえばランダムアクセスメモリ（ＲＡＭ））を含み得るローカル記憶ユニット（別名「データ記憶システム」）１１０８とを備え得る。ＨＴＴＰサーバ１０６が汎用マイクロプロセッサを含む実施形態では、コンピュータプログラム製品（ＣＰＰ）１１４１が提供され得る。ＣＰＰ １１４１は、コンピュータ可読命令（ＣＲＩ）１１４４を含むコンピュータプログラム（ＣＰ）１１４３を記憶しているコンピュータ可読媒体（ＣＲＭ）１１４２を含む。ＣＲＭ １１４２は、それだけではないが、磁気媒体（たとえばハードディスク）、光媒体、メモリデバイス（たとえばランダムアクセスメモリ）などの非一時的コンピュータ可読媒体でよい。いくつかの実施形態では、コンピュータプログラム１１４３のＣＲＩ １１４４は、データ処理装置１１０２によって実行されたとき、ＨＴＴＰサーバ１０６に、上記で説明されたステップ（たとえば流れ図を参照しながら上記で説明されたステップ）を実施させるように設定されている。他の実施形態では、ＨＴＴＰサーバ１０６は、コードを必要とすることなく本明細書で説明されたステップを実施するように設定され得る。すなわち、たとえば、データ処理装置１１０２は、単に１つまたは複数のＡＳＩＣから成るものでよい。よって、本明細書で説明された実施形態の機能はハードウェアおよび／またはソフトウェアで実施され得る。

使用事例
スマートフォンおよびドローンのような他のデバイスの進化によってアップリンク方向が強調されており、そのようなデバイスはハイエンドカメラ（ブロードキャスト品質のビデオストリームを生成することができる）を装備している。前述の実施形態は、これらの傾向を利用するように独自に適合されているものである。例示の使用事例が以下で説明される。

使用事例の一例には、ドローンを使用してたとえば上空の視点からライブイベントを取り込むものがあり、ドローンは、イベントの上空を飛行して、ネットワーク（たとえばブロードバンドネットワーク）を介して放送局（または他のサードパーティ）にコンテンツを直接送ることができる。そのような使用事例では、ドローンは高品質カメラ３０２のみを装備すればよく、一定の目標を追うために、視線を用いる手動またはフォローミーモードで運転され得る。ドローンはモデム（たとえば５Ｇモデム）を有し、ＨＴＴＰクライアント３１０が作動する任意のオペレーティングシステムを作動させてよい。すなわち、ドローンはクライアント１０２のインスタンスであり得る。または、他の実施形態では、ドローンのカメラ３０２は、ドローンの近くの、モジュール３０４〜３１０を含むデバイスにリンク（Ｂｌｕｅｔｏｏｔｈリンクなど）を通じて接続してよい。上記で説明されたように、そのようなデバイスは、即時処理のためにライブビデオを遠隔サーバ１０６にストリーミングするように動作可能である。この使用事例は、スキーおよびラリーレースのようなイベントを取り込むためにスポーツイベントにおいて使用され得、またオリンピックなどのスポーツイベントに使用され得る（たとえば２０１８年のオリンピックでは、５Ｇネットワークが、別々のオリンピック競技をブロードキャストしたり取り込んだりするのを支援し得る）。

別の例示の使用事例には、カメラ３０２を有するスマートフォンからニュースをブロードキャストするものがある。すなわち、スマートフォンはクライアント１０２のインスタンスであり得る。スマートフォン技術は改善されており、ハイエンドスマートフォンのビデオ品質は、既に、プロのテレビプロダクション（ニュース速報など）において使用するのに十分に適している。スマートフォンがカメラをホスティングすることができる場合には、記者は、実施形態により、任意の位置から、広帯域アクセスを用いてニュースを直ちに報道することができる。

別の使用事例では、カメラ３０２はヘルメットカメラ（たとえばスポーツ選手が着用したカメラ）またはボディカメラ（たとえば警察官が着用したボディカメラ）である。カメラは、モジュール３０４〜３１０を含むデバイスにライブ映像をストリーミングすることができ、このデバイスは、上記で説明されたように、即時処理のためにライブビデオを遠隔サーバ１０６にストリーミングするように動作可能である。カメラは、たとえば取り込みレイテンシを短縮するため、ビデオ品質を向上するため、または録画のスタート／ストップのために、遠隔で動作してよい。実施形態は、そのようなカメラフィードのライブアップリンクストリーミングをサポートする。

携帯電話またはボディカメラを有するユーザがソーシャルメディアプラットフォームによってライブストリームを自分のウェブサイトにインジェストすることができる場合には、実施形態は、ユーザ作成コンテンツ（ＵＧＣ）の傾向をサポートするうえでも大いに役立つものである。

ＩＳＯベースメディアファイルフォーマット（ＢＭＦＦ）を使用する断片化されたＭＰ４ファイルの使用
ＩＳＯベースメディアファイルフォーマット（ＢＭＦＦ）を使用する断片化されたＭＰ４ファイル（ｆＭＰ４）は、本明細書で開示された実施形態に適用可能である。ＩＳＯ ＢＭＦＦはＩＳＯ／ＥＣ １４９９６−１２に規定されている。ＩＳＯ ＢＭＦＦはボックス構造上に構築される。各ボックスは、ボックスサイズ情報（４バイト）から始まり、一般的には４文字（たとえばファイルタイプとしてのｆｔｙｐ）として表現されるボックスタイプ情報（これも４バイト）が続く。ボックスは、複合ボックスであり得、ボックスが他の子ボックスを含むことを意味する。断片化されたＭＰ４ファイル（またはＩＳＯ−ＢＭＦＦファイル）は、通常のＭＰ４ファイルとは異なる構造である。通常のＭＰ４ファイルはファイルタイプ（ｆｔｙｐ）から始まり、１つだけのムービーボックスおよび他のボックスが続く。メディアデータは、ムービーフラグメントボックス（ｍｏｏｆ）と関連するメディアデータボックス（ｍｄａｔ）の組合せであるフラグメントによって記述される。

ｆｔｙｐボックスは、ファイルおよび使用されるコーデックの互換性情報を含む。

ムービーボックス（ｍｏｏｖ）はコーデック設定情報を含む。ＤＲＭで保護されたコンテンツについては、追加のＤＲＭ情報が含まれている。通常のＭＰ４ファイルとは異なり、時間対サンプル表は空にしておかれる。時間対サンプル表は、サンプル期間、サンプル組成、および復号時間、ならびにメディアデータボックスにおけるサンプルの正確なバイトオフセットおよび長さを記述する。

断片化されたＭＰ４ファイルは多くのメディアデータボックス（ｍｄａｔ）を含む。ｍｄａｔボックスは、ボックスへと連結された個々のサンプルの実メディアデータを含む。断片化されたＭＰ４ファイルにおける各メディアデータボックスについて、個別のメディアデータボックスに関するタイミングおよびバイトオフセット情報を含む専用のムービーフラグメントボックスがある。

例示の断片化されたＭＰ４ファイルが含み得る所与のボックス階層構造がここで説明される。このファイルは、最上位に単一のｆｔｙｐボックスおよび単一のｍｏｏｖボックスを含む。次いで、多くのムービーフラグメントボックス（ｍｏｏｆ）およびメディアデータボックス（ｍｄａｔ）がある。ｍｄａｔボックスと同数のｍｏｏｆボックスがある。（たとえばＤＲＭ記述のための）他のボックスも含まれ得る。

関連するメディアデータボックスとのムービーフラグメントの組合せは、フラグメントと見なされてよい。いくつかの実施形態では、このフラグメントはＨＴＴＰクライアントおよびサーバが連携する粒度の細かいオブジェクトでよい。ＩＳＯ／ＩＥＣ ２３０００−１９（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ ＦｏｒｍａｔすなわちＣＭＡＦ）では、ムービーフラグメントボックスとメディアデータボックスの組合せはＣＭＡＦチャンクと呼ばれる。

断片化されたＭＰ４ファイルのｍｏｏｖボックスは、コーデック設定を含むので初期化セグメントまたは初期化部とも呼ばれる。説明されている例では、断片化されたＭＰ４ファイルは、Ｈ．２６４コーデック（ａｖｃ１ボックスおよび関連する属性−値エントリによって表現される）を使用する単一のビデオトラック（ｔｒａｋボックス）を含み得る。

フラグメントには追加のボックス（ｍｏｏｆボックスとｍｄａｔボックスの組合せ）が含まれ得る。ｍｏｏｆボックスは他のいくつかの子ボックスを含む複合ボックスである。ここで最も重要な子ボックスは、トラックフラグメントヘッダボックス（ｔｆｈｄ）およびトラックフラグメントランボックス（ｔｒｕｎ）である。フラグメントが（オーディオおよびビデオのような）複数のトラックからのメディアを含むとき、フラグメントには複数のトラックフラグメント（ｔｒａｆ）ボックスがある。

例示のトラックフラグメントランボックス（ｔｒｕｎ）は、フラグメントのｍｄａｔ区分が単一のサンプル（またはビデオフレーム）のみを含むことを示し得る。（ｔｒｕｎボックスの）ｄａｔａ＿ｏｆｆｓｅｔフィールドは、サンプルの開始バイトのオフセットを示すｍｄａｔ区分へのポインタである。

（現在説明された例では）フラグメントに単一のサンプルしかないので、トラックフラグメントランボックスにはサンプル長情報がない。この例におけるサンプルサイズは、ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｓｉｚｅとしてトラックフラグメントヘッダボックス（ｔｆｈｄ）に含まれている。

トラックフラグメントヘッダボックスは、ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎ（たとえば１００）、ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｓｉｚｅ（たとえば４３１８）およびｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｆｌａｇ（たとえば０ｘ１００ｃ０）を含み得る。ここのｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｆｌａｇは、これがｓｙｎｃサンプルであること、すなわち復号を開始するために使用され得ることを記述する。

（ｔｆｈｄボックスの）ｄｅｆａｕｌｔ＿ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎは、サンプル期間を（時間スケール目盛で）示す。（メディアヘッダボックスまたはｍｄｈｄにおける）初期化セグメントからのトラック時間スケールを用いて、サンプル期間を秒で計算することができる（たとえば１００／３０００秒）。ビデオは３０フレーム／秒のフレームレートで記録される。

フラグメントに複数のサンプルがあるとき、各サンプルがそれ自体のサイズを有するので、ｔｒｕｎボックスには少なくとも各サンプルのセグメントサイズが含まれている。

次にｔｒｕｎボックスの別の例を説明する。フラグメントは３０フレームを含み得、フラグはフレームの符号化従属性を表現し得る。この例は、セグメント化されたメディアファイルからのものであり得、フラグメント情報が、ｓｔｙｐ（セグメントタイプ）および任意選択のｓｉｄｘボックスのような付加情報と、別個のファイルへと組み合わされ得ることを意味することに留意されたい。

この出願が優先権を主張する米国仮出願は、規格の変更のための提案を含む付録を含むものであった。この提案（別名「寄書」）の関連する部分を以下で再現する。

２ 一般的な使用事例説明および一般的な考察
２．１ 一般的な使用事例およびアーキテクチャの考察
作業項目は、ライブアップリンクビデオストリーミングのための枠組みを規格化することを目的とするものである。考察の１つは、様々な３ＧＰＰアクセスシステムの手段および能力、具体的には新規のＮＲアクセス技術の新規の能力および機能を使用するものである。様々な３ＧＰＰアクセスシステム（たとえばＬＴＥまたはＮＲ）が有する異なる能力は、デバイス実現（およびデバイスカテゴリ）およびシステム配備に依拠するものである。

ライブアップリンクビデオは、一般的にはライブビデオ配信サービスのための寄与またはインジェストとして使用される。「寄与」という用語は、プロのテレビプロダクションでは、多くの場合メディアのライブインジェストに関して使用されている。そのようなビデオシステムの主な特徴は、ビデオフローが、ビデオソースからいくつかの仲介ノード経由で一般的には多くの受信器へと一方向であることである。インジェストリンクと可能な配信システムの関係が図１に表現されている。インジェストリンクは配信システムから切り離され得る。または、インジェストサーバは、後の使用のためにビデオデータのみ記憶すればよく、または監視画面にビデオストリームを発送してよい。たとえば、ソースのライブビデオは後の使用のためにファイルシステムに記憶されてよく、またはライブビデオソースからのビデオ資料は最初にスクリーニングされ、番組ディレクタが特定のライブソースを使用すると判断したときに限って使用されてよい。

配信側では、今日（ＤＡＳＨのような）適応ビットレートストリーミングが一般に使用されている。適応ビットレートのために、コンテンツは、たとえば数百ｋｂｐｓから数百Ｍｂｐｓまでの範囲の複数の品質表示（ビデオプロファイルと呼ばれる）で供給される必要がある。使用法に依拠して、配信のためにＤＲＭ保護が付加される。ＩＰベースのシステムのための配信システムは、一般的にはコンテンツ配送ネットワーク（ＣＤＮ）である。もちろん他の配信システム（ＩＰおよび従来のブロードキャストシステム）も可能である。

ライブのインジェスト側（作業項目の範囲である）では、ライブメディアソースはフレームを取り込み、次いで、インジェストサーバ（すなわちメディアシンク）にフレームを送信する。ビデオコンテンツは、一般にオーディオまたは他のメディアよりもはるかに高いデータレートを必要とするので、この文献ではビデオコンテンツに的を絞る。しかしながら、オーディオまたは他のメディアも本開示に適用可能である。

取り込まれたビデオフレームは、インジェストリンクを通じて送信する前に、ビットレート低減のために圧縮されてよい。いくつかの実施形態における寄与リンクは、アップリンク方向に使用される３ＧＰＰアクセスシステムである。

ＮＡＴおよびファイアウォールが、デバイス側のインジェストリンク経路（たとえばパーソナルファイアウォール）および３ＧＰＰシステムにわたって存在する（これらの機能は規格化されていないが依然として存在する）せいで、通信のメディアソース（たとえばカメラ）は、インジェストサーバ（たとえばメディアシンク）への通信セッションを活性化するべきである。この理由は、ファイアウォールにおける「開放ポート」がセキュリティの理由または（会社の）セキュリティのルールのために多くの場合禁止されているためである。さらに、経路にネットワークアドレス変換機構（ＮＡＴ）があるとき、専用のＮＡＴが目標デバイスにルールを発送しているはずである。

クライアントデバイスは、多くの場合動的ＩＰアドレスを用いて設定される。ファイアウォールおよびＮＡＴ発送ルールは、一般的にはデバイスＩＰアドレスに依拠し、したがってすべてのＩＰアドレス変更に対して調節される必要がある。

インジェストサーバは、クライアントデバイスとは対照的に、入接続を安全に受信するように（たとえば到達可能なように）適切に設定される。インジェストサーバがＮＡＴの後にあるときには、対応するＮＡＴを発送するルールが設定される。

したがって、３ＧＰＰのＵＥ側でサーバを作動させることは技術的に可能であるが、この提案はＵＥ側から分離したサーバに的を絞る。

２．２ ビデオ圧縮の考察
プロのブロードキャスト作業では、ライブビデオハンドリングおよび外部イベントから放送スタジオへライブビデオを送ることのために、一般に、シリアルデジタルインターフェース（ＳＤＩ）が使用される。ＳＭＰＴＥは、ＲＴＰによってＳＤＩ信号を搬送するために２０２２においてＲＴＰペイロードフォーマット（ＩＥＴＦ ＲＦＣ ４１７５）を規定した（ＲＴＰセッションは様々な手段によって確立され得ることに留意されたい）。ＳＤＩは非圧縮ビデオフレームまたは軽く圧縮されたビデオフレーム（たとえばＪＰＥＧ２０００を使用するもの）のいずれかを搬送するので、高解像度ビデオの一般的なＳＤＩビットレートはギガビット域にある。ＳＤＩの重要な利益は、すべてのフレームをオンにする能力（ＧｏＰタイプの依存構造がない）および低レイテンシ（すべてのフレームが直ちに送られる）である。

３ＧＰＰは、ビデオビットレートを低減するために、ＶｏＬＴＥ−ビデオ（ＶｉＬＴＥ）の低レイテンシの対話形ビデオ用にさえ、（Ｈ．２６４またはＨＥＶＣを使用する）圧縮ビデオを使用する。低レイテンシのビデオ圧縮のために、もたらされるビデオビットレートに対してレイテンシに優先権が与えられ、Ｂフレームのようないくつかの圧縮ツールが回避される。あらゆる詳細な標準化作業を始める前に、３ＧＰＰライブアップリンクビデオの解決策について目標のビットレート／ビットレート範囲およびレイテンシ制限について論じて合意することが推奨される。

２．３ 適応ビットレートおよびＱｏＳ
３ＧＰＰシステムは、ＬＴＥまたはＮＲのようなアクセスシステムの異なるセットをサポートする。アクセスシステムは、サポートされるリンクのビットレートまたはＱｏＳなど異なる能力を有する。これらの能力は、たとえば割り当てられたキャリア帯域幅といった配備実現にある程度依拠する（たとえばＬＴＥキャリーは２０ＭＨｚ、１０ＭＨｚのような異なる帯域幅をサポートすることができる）。アクセスシステムは、複数の無線キャリアのアップリンク能力を単一のアップリンクへと組み合わせることを意味するキャリアアグリゲーションをサポートし得る。

３ＧＰＰのＵＥは、デバイス実現およびデバイス製造業者に依拠して、異なる能力を有し得る。

システム特性はデバイスの運動パターンに依拠し得る。たとえば、チャネル特性は、デバイスが静止しているかそれとも動いているかということに依拠し得る。デバイスは、動いているとき、ある基地局から他の基地局に、またはあるアクセスネットワークから別のアクセスネットワークにさえ、ハンドオーバを実施する可能性がある。これはストリームを一時的に混乱させる可能性があり、このような混乱は、インジェストサーバの前にたとえばさらなるバッファリング（およびレイテンシ）を導入することによって緩和され得る。

リンクインジェストの一定の最小ビットレートの利用可能性の確率を増加するために、サービス品質（ＱｏＳ）および他の技法が使用され得る。

目標の解決策が、ネットワークのサービス品質（ＱｏＳ）機構から利益を得ることが推奨される。しかしながら、３ＧＰＰアクセスシステム、モビリティおよび配備における相違のために、アップリンクストリーミングの解決策は、異なるビットレートで正しく動くことができ、適応ビットレート変更さえサポートすることが推奨される。

２．４ セキュリティの考察
ライブインジェストの解決策は誤用に対して適切に保護されなければならない。少なくとも以下の誤用の注意事項がある。

ライブインジェストの解決策は、複数の独立したメディアソースとともに、順次にまたは同時に使用可能であるものとする。この解決策は、各メディアソースについて別個のアカウントの使用を考慮に入れるかまたはサポートするべきである。ここでのアカウントは、（ＡＢＲトランスコーダのような）インジェストおよび後処理の機能の系統であり、また場合によっては（ライブフィードが受信器に提供される様子は）配信システムでもあり得る。認可されたクライアントのみがそのようなアカウントに対するアクセスや制御が可能であること、および各アカウントが固有のインジェストポイント記述を有することが保証されなければならない。

さらに、インジェストサーバが着信データを求めて一定のインジェストポイント（たとえばポートまたはＵＲＬ）においてリッスンしているとき、後処理および配信系統にメディアデータをインジェストすることができるのは認可されたソースのみとすることが保証されるべきである。そうでなければ、ライブサービスは、代替ビデオまたは単なる不要データを挿入することによってハイジャックされるかまたはスパムを送られてしまう。そのため、ユーザプレーンは、インジェストサーバが認可されたコンテンツデータと無認可のデータを区別することができるように保護されるべきである。

２．５ 能力交換
図１に示されるように、インジェストサーバ（メディアシンク）は、後続の機能リンクＡＢＲトランスコーダにデータを発送する。システムは、あらゆるトランスコーディングまたはあらゆるビデオレンダリングについて、最初に入来ストリームを復号する必要がある。広範な異なるコーデックおよびコーデックプロファイルが利用可能である。

インジェストサーバは、受信したストリームを後処理し得ることを保証するために、能力交換および可能性としてコーデック交渉が必要とされる。最も簡単な形態は、インジェストサーバが（サブタイトルサポートまたはサポートされるコーデックのような）それ自体の能力を通知するかまたはあらわにし、その結果クライアント（メディアソース）がライブインジェスト用に適切なサブセットを選択することができるものである。セッティングをあらわにするかまたは交渉するための別の手段がある。

一般的なインジェストサーバの能力は、コーデックおよびコーデックプロファイルがサポートされることである。サブタイトルストリームまたは広告機会マーカ挿入の配置をサポートすることのような追加機能がある。

あらわにすること／交渉枠組みの能力は、拡張可能であるべきであり、製造業者の特定の能力を許容するべきである。

３ 実現の選択肢
利用可能な技術的解決策のセットがあり、実現のために考慮に入れることができる。以下で、利用可能な実現の選択肢のうち少なくともいくつかを簡単に導入する。他の実現の選択肢が利用可能であることに留意されたい。

３．１ ＲＴＰベースの方式
３．１．１ 一般原理
ＲＴＰは様々な環境においてビデオ送信のために一般に使用されているプロトコルである。Ｈ．２６４（ＲＦＣ ６１８４）ビデオまたはＨＥＶＣ（ＲＦＣ ７７９８）ビデオなど、様々なＲＴＰペイロードフォーマットが利用可能である。ＲＴＰ（ＲＦＣ ２２５０）内のＭＰＥＧ２トランスポートストリーム多重データまたはシリアルデジタルインターフェース（ＳＤＩ（ＳＭＰＴＥ ２０２２−６））（ＲＦＣ ４１７５）の非圧縮ビデオさえ搬送するために利用可能なフォーマットもある。ＳＤＩはプロのテレビプロダクションシステムにおいて広く使用されていることに留意されたい。

ＲＴＰはＵＤＰトランスポートを使用し、ＵＤＰトランスポートを確立したり設定したりするのに専用プロトコルが必要とされる。ＳＲＴＰとともに、セキュリティの枠組みがＲＴＰ用に利用可能である。代替として、または補足として、ＤＴＬＳが使用され得る。

３．１．２ ＩＭＳベースのライブインジェストセッション確立
３ＧＰＰ会話サービスはＩＭＳを使用して構築され、ＩＭＳはアップリンクライブビデオ（３ＧＰＰ ＴＳ ２６．１１４）を供給するために必要とされるＲＴＰユーザプレーンを確立するのによく適している。ライブアップリンクの場合には、通信チャネルは一方向のビデオ用にのみ使用され、ＩＭＳシステムの、この使用事例のために可能な改善が検討されるべきである。

３ＧＰＰは、既に、様々なＲＴＰビデオペイロードフォーマット、とりわけＨ．２６４およびＨＥＶＣビデオに対するサポートを有する。必要なとき、他のペイロードフォーマットが付加され得る。

ＩＭＳは、ユニキャストトランスポートセッションを確立するため、ならびにまたコーデックの交渉および選択のためにＳＩＰ／ＳＤＰを使用する。ＩＭＳは認可および認証のための枠組みを提供する。誤用に対してユーザプレーンインジェストを保護するためにＳＲＴＰおよび／またはＤＴＬＳが使用され得る。

ＩＭＳに対してセッションが確立され得る。メディアソースはＩＭＳクライアントである。メディアシンクは（ここでは）ＭＲＦである。別の例には、自動応答するＩＭＳクライアントがメディアシンクとして使用されるものがあり得る。

３ＧＰＰのＴＳ ２６．１１４はビデオレート制御を規定している。ＳＣＲｅＡＭのような他のＲＴＰビデオレート制御方式がある。１つの選択肢は、ＩＥＴの標準化の下のＳＣＲｅＡＭ（マルチメディアのための自己計測されたレート整合）である。ＳＣＲｅＡＭはネットワーク輻輳制御を扱い、また各メディアソース（複数可）向けに推奨されるビットレートを提供する。ＳＣＲｅＡＭの実装形態が利用可能である。

３．１．３ ＲＴＳＰベースのライブインジェストセッション確立
３ＧＰＰのパケット交換ストリーミングサービス（ＰＳＳ）（３ＧＰＰのＴＳ ２６．２３４）は、ダウンリンクストリーミングセッションを確立するためにＲＴＳＰを使用する。インフラストラクチュアにＲＴＳＰサーバ（メディアシンク）が配置されている場合には、ＲＴＳＰ上にライブアップリンクビデオストリーミングの解決策を構築するのが当然のように思われる。

ＵＥ側にＲＴＳＰサーバを配置することは、技術的に可能であるが非実用的である。詳細には、消費者デバイスはファイアウォールを使用して遮蔽されている。いくつかのＭＮＯは、ネットワークアドレス変換さえ使用してＩＰアドレスを動的に割り当てる。

ＲＴＳＰクライアントはメディアソースとして働くべきであり、ＲＴＳＰサーバはメディアシンクとして働くべきである。ＲＴＳＰクライアントは、ＲＴＳＰサーバに向けたＲＴＰアップリンクストリーミングセッションを確立するものとする。インジェストリンクのためのＵＤＰトランスポートを確立するために、既存のＲＴＳＰ設定プロシージャが使用され得る。次いで、アップリンクライブストリーミングセッションが、「ＲＴＳＰ記録」方法を使用して始動され、可能性としてＲＴＳＰセットパラメータを使用して変更される。

選択されたコーデックおよびコーデック設定を通知するために、ＲＴＳＰが記述する方法が使用される。ＲＴＳＰインジェストサーバによってサポートされるコーデックを照会するには別個のプロシージャが使用されるべきである。

ＲＴＳＰクライアントおよびＵＤＰユーザプレーンデータを認可して認証するためのセキュリティプロシージャをさらに研究して論じる必要がある。誤用に対してユーザプレーンインジェストを保護するためにＳＲＴＰまたはＤＴＬＳが使用され得る。

たとえばカバレッジの劣化のためにスループットが低下した場合の遅延要求を満たすために、既存のＲＴＰストリーム用の様々なビデオレート制御方式が実施されるべきである。段落３．１．２で導入されたようなＳＣＲｅＡＭは実現の選択肢の１つである。

３．１．４ ＷｅｂＲＴＣベースのライブインジェストセッション確立
ＷｅｂＲＴＣは、今日、サービスのような通信のために、ブラウザにおいて広くサポートされている。ＷｅｂＲＴＣは双方向通信サービス用に設計されているが、一方向ストリーミングサービス向けに成功裡に試験され、かつ使用されている。ＷｅｂＲＴＣゲートウェイがインジェストサーバとして使用され得る。

ＷｅｂＲＴＣはＳＲＴＰ／ＵＤＰを通信トランスポートとして使用する。ＳＲＴＰとＤＴＬＳの組合せを使用するセキュリティが内蔵されている。

３．２ ＴＣＰ上のＲＴＭＰ
アップリンクストリーミングのための最も一般的なストリーミングプロトコルはＡｄｏｂｅ社のリアルタイムメッセージ通信プロトコル（ＲＴＭＰ）である。ＲＴＭＰは明確なポート（すなわちポート１９３５）上での確実なアップリンクストリーミングのためにＴＣＰを使用する。インフラストラクチュア側のサーバ構成要素を用いるＴＣＰおよびＨＴＴＰのベースのアップリンクストリーミングフォーマットの利益には、ファイアウォール問題およびＮＡＴ問題の予防がある。ＴＣＰを使用すると低レイテンシを保証するＴＣＰ設定が必要となり、これは、ＴＣＰ送信バッファの適切なセッティングならびに低レイテンシを保証する輻輳制御アルゴリズム（詳細はｔｂｄである）の使用を包含する。

ＲＴＭＰストリームはＲＴＭＰプロトコルハンドラ方式（ｒｔｍｐ：／／）によって識別され得、そこで、ｒｔｍｐ：／／ｅｘ．ｃｏｍ／ｌｉｖｅ．ｓｗｆの形式のＵＲＬはアプリケーションによって解釈され得る。ＲＴＭＰ方式のために別個の周知のポート（ポート１９３５）が規定されており、そのためポートを供給する必要はない。もちろん、ＲＴＭＰのＵＲＬは他のポートを許容する。

ＲＴＭＰはそれ自体のメッセージフォーマットおよび多重化機構を規定する。ＲＴＭＰをサポートするために、送り側と受け側の両方がＲＴＭＰメッセージタイプおよびメッセージハンドリングプロシージャの必要な範囲をサポートする必要がある。

ＲＴＭＰはメッセージベースのプロトコルである。各メッセージが長さを含み、多くの場合タイムスタンプおよびいくつかのタイプ情報を含む。メッセージは、多重化および交互配置のために、より小さいＲＴＭＰチャンクへと細分され得る。ＲＴＭＰは多重化され得る「チャンクストリーム」を規定する。ＲＴＭＰチャンクとＨＴＴＰチャンクの間には明瞭な相違があることに留意されたい。

ＲＴＭＰは、すべてのビデオコーデック、オーディオコーデックおよびクローズドキャプション解決策をサポートするわけではない。たとえば、ＨＥＶＣは現在サポートされていないように思われる。

ウィキペディアによれば、（ＲＴＭＰＴを使用して）ＨＴＴＰを通じてＲＴＭＰをトンネルすることが可能である。しかしながら、ＲＴＭＰ規格にはこの機能の説明がない。従来、ＲＴＭＰは、サーバからクライアントへのダウンリンクストリーミング用に主として使用されてきた。

３．３ ＭＰＥＧ２−ＴＳまたは断片化されたＭＰ４を用いるＨＴＴＰ
ＨＴＴＰはライブアップリンクビデオストリーミング用にも使用され得る。ＨＴＴＰの利益には、ＨＴＴＰＳのようなすべてのＨＴＴＰ特有のセキュリティ機能またはソース認証が再利用され得ることがある。ここで、アップリンクストリーミング用に適切なフォーマットは、ＭＰＥＧ２−ＴＳ［ＩＳＯ／ＩＥＣ １３８１８−１］または断片化されたＭＰ４［ＩＳＯ／ＩＥＣ １４９９６−１２］のいずれかである。さらに、インフラストラクチュアは、ポート８０または４４３上のＨＴＴＰトラフィックまたはＨＴＴＰＳトラフィックが、任意の中間ファイアウォールをあちこち移動することを許容するように設定されている。

どちらの場合も、モバイル３ＧＰＰデバイス上のＨＴＴＰクライアントは、ＨＴＴＰ要求を使用して、ＨＴＴＰインジェストサーバに対するＨＴＴＰＳ接続を開始する。次いで、ライブアップリンクビデオは要求のＨＴＴＰボディを与えられる。ＨＴＴＰクライアントは、ＨＴＴＰボディにビデオコンテンツを直接パイピングするために、ＨＴＴＰ １．０原理またはＨＴＴＰ １．１チャンク転送符号化を使用してよい。ＨＴＴＰチャンク転送符号化は、クライアントが、確立したＴＣＰ接続を後続のＨＴＴＰトランザクションのために再利用することを可能にする（持続性のＴＣＰ接続）。ＴＣＰを通じてのＲＴＭＰの場合と同様に、ＴＣＰの正確な設定を保証することが重要である。

図５は、ＨＴＴＰ上のライブインジェストフォーマットを有する断片化されたＭＰ４を使用するコールフローを図示するものである。メディアソースは、ここではＨＴＴＰクライアントである。メディアシンクは、ここではＨＴＴＰサーバであり、受信したストリームチャンクを、ここではデジッタバッファとして図示されている後処理チェーンへ直ちに発送する。

クライアントは、ライブアップリンクストリームが始動される前に、最初にＨＴＴＰインジェストサーバの能力を照会して検査する。ＨＴＴＰは能力を照会するために使用され得る。

次いで、ＨＴＴＰクライアントは、ＨＴＴＰ要求のボディの内部のＨＴＴＰチャンク配送を使用してライブストリームをアップロードする。ＨＴＴＰチャンクとして搬送されるフラグメントは、ＩＳＯ／ＩＥＦ １４９９６−１２に従ってフォーマットされている。ムービーボックス（「ｍｏｏｖ」）は、コーデックと、コーデック設定と、可能性として他の情報とを含む。クライアントがライブインジェストを終了したとき、次いで、サーバがＨＴＴＰ応答を供給する（この場合２０１が作成される）。

ＭＰＥＧ２＿ＴＳ［ＩＳＯ／ＥＣ １３８１８−１］がインジェストフォーマットとして使用されるとき、フラグメントはＭＰＥＧ２−ＴＳに従ってフォーマットされる。

この解決策ではレート制御が実施されるべきであり、これは、好ましくはＴＸバッファを監視し、それに応じてメディアソースを調節することができる。

４ 解決策の必要条件
ライブアップリンクストリーミングの枠組みにおける標準化の研究のために、以下の解決策の機能（排他的リストではない）が提案される。

ＮＡＴおよびファイアウォールの存在を考慮に入れるものとする。インジェストサーバは、インフラストラクチュア側に配置されるものとし、その結果、メディアソースは常に３ＧＰＰのＵＥ側の通信イニシエータに配置される。

解決策はライブインジェストのみに的を絞るものとする。メディア配信またはメディア記憶の実現はインジェストから独立したものとする。

解決策は認可および認証をサポートするものとする。ライブインジェストトラフィックは、ユーザのアカウントまたはチャネルに対して分離可能にするべきである。

インジェストサーバにビデオトラフィックをインジェストすることができるのは、認証されたトラフィックソースのみとする。

解決策は３ＧＰＰ ＱｏＳの枠組みを導入することができるべきである。

解決策は、（ＮＲまたはＬＴＥのような）利用可能なアクセスネットワークに依拠して、異なるビットレートをサポートするべきである。

解決策は、少なくともＨ．２６４ビデオコーデックおよびＨＥＶＣビデオコーデックをサポートするものとする。

解決策は、たとえばモビリティといったリンク条件の変化に応じてビットレートを適合させることができるべきである。

解決策は、（低レイテンシのライブインジェストが必要なとき）品質／もたらされるビットレートよりもレイテンシを優先させること、または（より優れた圧縮効率もしくは再送信のための時間があるとき）レイテンシよりも品質／もたらされるビットレートを優先させることができるべきである。

解決策は能力検索または能力交渉をサポートするべきである。

５ 提案
上記で与えられた情報を考慮に入れることを提案する。（たとえば段落２、３および４で示されたような）解決策の設計要件および注意事項を収集するために、永続ドキュメントまたは技術報告書を作成することを提案する。

ライブアップリンクビデオストリーミングの枠組みに関する技術仕様に（段落３．３で説明されたような）ＨＴＴＰベースの解決策を含めることをさらに提案する。

本明細書では本開示の様々な実施形態が説明されているが、例としてのみ提示されており、限定するものではないことを理解されたい。したがって、本開示の広さおよび範囲は前述の例示的実施形態のいかなるものによっても制限されるべきではない。その上に、前述の要素のあらゆる組合せが、すべての可能な変形形態において、本明細書で別様に示されることまたは文脈によって別途明らかに否定されることがなければ本開示によって包含される。

加えて、上記で説明されて図面に図示された処理は一連のステップとして示されているが、これは単なる具体例のためのものである。それゆえに、いくつかのステップを付加すること、いくつかのステップを省略すること、ステップの順番を再構成すること、およびいくつかのステップを並行させることが企図される。

Claims (20)

1. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバ（１０６）にアップストリーミングするためにクライアント装置（「クライアント」）（１０２）によって実施される方法であって、
   前記クライアント（１０２）が前記サーバ（１０６）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することと、
   前記クライアント（１０２）が、前記トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを前記サーバ（１０６）に送信することであって、前記ＨＴＴＰ要求メッセージの前記ヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰ要求メッセージを前記サーバ（１０６）に送信することと、
   メディアデータが生成されたとき、前記クライアント（１０２）が、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することであって、前記メディアデータを生成するために品質セッティングが使用される、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することと
   を含み、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に前記ＨＴＴＰ要求メッセージの前記ボディを送信することが、
   １）前記クライアント（１０２）が、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に送信することと、
   ２）前記クライアント（１０２）が、前記メディアデータの前記少なくとも一部分を前記送信バッファ（３０８）から除去することと、
   ３）前記クライアント（１０２）が、前記ライブメディアフィードに対応する前記メディアデータを発生するために使用される前記品質セッティングを変更するべきかどうかを判定することと、
   ４）前記クライアント（１０２）が、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すことと、
   を含む、方法。
2. 前記メディアソースがカメラ（３０２）である、請求項１に記載の方法。
3. 前記カメラ（３０２）が前記クライアント（１０２）と一体となる部品である、請求項２に記載の方法。
4. 前記カメラ（３０２）が前記クライアント（１０２）から遠隔である、請求項２に記載の方法。
5. 前記送信終了トリガは持続時間を指定するスケジュールに基づくものであり、前記クライアント（１０２）は前記持続時間が過ぎたことを検知した結果として前記送信終了トリガを検知する、請求項１から４のいずれか一項に記載の方法。
6. 前記クライアント（１０２）が、第１の品質セッティングを使用して、前記メディアソースによって生成されたメディアフレームの第１のセットを符号化し、符号化されたメディアフレームの第１のセットを生成することであって、前記送信バッファ（３０８）に記憶された前記メディアデータが、前記符号化されたメディアフレームの第１のセットを含み、
   前記ＨＴＴＰ要求メッセージの前記ボディを送信する前記ステップが、前記クライアント（１０２）が第１のコーデック設定情報を送信することをさらに含み、前記第１のコーデック設定情報が前記第１の品質セッティングを示す情報を含む、第１の品質セッティングを使用して符号化されたメディアフレームの第１のセットを生成することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶されたデータ量を監視することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶された前記データ量が閾値を超えたと判定することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶された前記データ量が前記閾値を超えたと判定した結果として、第２の品質セッティングを使用して、前記メディアソースによって生成されたメディアフレームの第２のセットを符号化し、符号化されたメディアフレームの第２のセットを生成することと、
   前記クライアント（１０２）が、前記ライブメディアフィードに対応するさらなるメディアデータを前記送信バッファ（３０８）に記憶することであって、前記さらなるメディアデータが前記符号化されたメディアフレームの第２のセットを含む、前記ライブメディアフィードに対応するさらなるメディアデータを前記送信バッファ（３０８）に記憶することと
   をさらに含み、
   前記ＨＴＴＰ要求メッセージの前記ボディを送信する前記ステップが、前記クライアント（１０２）が第２のコーデック設定情報を送信することをさらに含み、前記第２のコーデック設定情報が前記第２の品質セッティングを示す情報を含む、請求項１から５のいずれか一項に記載の方法。
7. 前記クライアント（１０２）が、前記メディアソースによって生成されたメディアフレームの第１のセットを符号化して、符号化されたメディアフレームの第１のセットを生成することであって、前記送信バッファ（３０８）に記憶された前記メディアデータが、前記符号化されたメディアフレームの第１のセットを含む、メディアフレームの第１のセットを符号化して符号化されたメディアフレームの第１のセットを生成することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶されたデータ量を監視することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶された前記データ量が閾値を超えたと判定することと、
   前記クライアント（１０２）が、前記送信バッファ（３０８）に記憶された前記データ量が前記閾値を超えたと判定したことの結果として、少なくとも前記メディアフレームの第１のセットのサブセットを、前記サーバ（１０６）に送信しないように、前記送信バッファ（３０８）からドロップすることと
   をさらに含む、請求項１から５のいずれか一項に記載の方法。
8. 前記送信バッファ（３０８）が記憶するメディアフラグメントが、前記メディアフレームの第１のセットの前記サブセットを含み、またメディアフレームの前記サブセットに関するメタデータをさらに含み、
   前記送信バッファ（３０８）から前記メディアフレームの第１のセットの前記サブセットをドロップする前記ステップが、前記メディアフラグメントが前記サーバ（１０６）に送信されないように、前記送信バッファ（３０８）から前記メディアフラグメントをドロップすることを含む、請求項７に記載の方法。
9. 前記クライアント（１０２）が、前記メディアソースによって生成された非圧縮ビデオフレームを取得することと、
   前記クライアント（１０２）が、前記非圧縮ビデオフレームを符号化して、符号化されたビデオフレームを生成することと、
   前記クライアント（１０２）が、ｉ）前記符号化されたビデオフレームおよびｉｉ）前記符号化されたビデオフレームに関係するメタデータを含むビデオフラグメントを発生することと、
   前記クライアント（１０２）が、前記フラグメントを前記送信バッファ（３０８）に記憶することと
   をさらに含む、請求項１から８のいずれか一項に記載の方法。
10. 前記ビデオフラグメントが、ｉ）ＩＳＯ−ＢＭＦＦビデオフラグメントおよびｉｉ）一般的なメディアアプリケーションフォーマット（ＣＭＡＦ）ビデオフラグメントのうちの１つである、請求項９に記載の方法。
11. 前記ライブメディアフィードが、ライブ配信のために、前記受信サーバ（１０６）によってさらに処理され得る、請求項１から１０のいずれか一項に記載の方法。
12. 前記クライアント（１０２）が、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に送信することが、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を含むデータチャンクを送信することを含む、請求項１から１１のいずれか一項に記載の方法。
13. 前記クライアント（１０２）が、前記ライブメディアフィードに対応する前記メディアデータを生成するのに使用される前記品質セッティングを変更するべきかどうかを前記判定することが、送信バッファレベルおよび／または前記送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に行われる、請求項１から１２のいずれか一項に記載の方法。
14. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをクライアント（１０２）から受信するためにサーバ（１０６）によって実施される方法であって、
    前記クライアント（１０２）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信することであって、前記ＨＴＴＰヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰヘッダを受信することと、
    前記ＨＴＴＰヘッダを受信した後に前記ＨＴＴＰ要求メッセージの前記ボディを受信することであって、
    前記クライアント（１０２）から第１のデータチャンクを受信することと、
    前記クライアント（１０２）から第２のデータチャンクを受信することと、
    前記第１のデータチャンクを受信した後、前記第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに前記第１のデータチャンクを発送することと
    を含む、前記ＨＴＴＰ要求メッセージの前記ボディを受信することと
    を含む方法。
15. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバ（１０６）にアップストリーミングするための、（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアント（１０２）であって、
    前記サーバ（１０６）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することと、
    前記トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを前記サーバ（１０６）に送信することであって、前記ＨＴＴＰ要求メッセージの前記ヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰ要求メッセージを前記サーバ（１０６）に送信することと、
    メディアデータが生成されたとき、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することであって、前記メディアデータを生成するために品質セッティングが使用される、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することと
    を行うように適合され、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に前記ＨＴＴＰ要求メッセージの前記ボディを送信することが、
    １）前記ＨＴＴＰクライアント（１０２）が、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に送信することと、
    ２）前記ＨＴＴＰクライアント（１０２）が、前記メディアデータの前記少なくとも一部分を前記送信バッファ（３０８）から除去することと、
    ３）前記ＨＴＴＰクライアント（１０２）が、前記ライブメディアフィードに対応する前記メディアデータを生成するために使用される前記品質セッティングを変更するべきかどうかを判定することと、
    ４）前記ＨＴＴＰクライアント（１０２）が、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すことと、
    を含む、ＨＴＴＰクライアント（１０２）。
16. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバ（１０６）にアップストリーミングするための、（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアント（１０２）であって、
    前記サーバ（１０６）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立するように設定されたトランスポートモジュールと、
    前記トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを前記サーバ（１０６）に送信するように設定された送信モジュールであって、前記ＨＴＴＰ要求メッセージの前記ヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、送信モジュールと、
    メディアデータが生成されたとき、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶するように設定されたデータ記憶モジュールであって、前記メディアデータを生成するために品質セッティングが使用され、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に前記ＨＴＴＰ要求メッセージの前記ボディを送信することが、
    １）前記ＨＴＴＰクライアント（１０２）が、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に送信することと、
    ２）前記ＨＴＴＰクライアント（１０２）が、前記メディアデータの前記少なくとも一部分を前記送信バッファ（３０８）から除去することと、
    ３）前記ＨＴＴＰクライアント（１０２）が、送信バッファレベルおよび／または前記送信バッファレベルの経時変化（たとえばバッファレベル勾配）を基に、前記ライブメディアフィードに対応する前記メディアデータを生成するために使用される前記品質セッティングを変更するべきかどうかを判定することと、
    ４）前記ＨＴＴＰクライアントが、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すことと
    を含む、データ記憶モジュールと
    を備えるＨＴＴＰクライアント（１０２）。
17. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをサーバ（１０６）にアップストリーミングするための、（たとえばモバイルデバイスまたはユーザ機器（ＵＥ）上の）ＨＴＴＰクライアント（１０２）であって、
    受信器と、
    送信器と、
    データ記憶システムと、
    プロセッサを備え、前記データ記憶システム、前記送信器、および前記受信器に結合されたデータ処理装置であって、
    前記サーバ（１０６）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を確立することと、
    前記トランスポートレイヤ接続を通じて、ヘッダおよびボディを含むハイパーテキスト転送プロトコル（ＨＴＴＰ）要求メッセージを前記サーバ（１０６）に送信することであって、前記ＨＴＴＰ要求メッセージの前記ヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰ要求メッセージを前記サーバ（１０６）に送信することと、
    メディアデータが生成されたとき、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することであって、前記メディアデータを生成するために品質セッティングが使用される、前記ライブメディアフィードに対応する前記メディアデータを送信バッファ（３０８）に記憶することと
    を行うように設定され、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に前記ＨＴＴＰ要求メッセージの前記ボディを送信することが、
    １）前記ＨＴＴＰクライアント（１０２）が、前記送信バッファ（３０８）に現在記憶されている前記メディアデータの少なくとも一部分を、前記トランスポートレイヤ接続を通じて前記サーバ（１０６）に送信することと、
    ２）前記ＨＴＴＰクライアント（１０２）が、前記メディアデータの前記少なくとも一部分を前記送信バッファ（３０８）から除去することと、
    ３）前記ＨＴＴＰクライアント（１０２）が、前記ライブメディアフィードに対応する前記メディアデータを生成するために使用される前記品質セッティングを変更するべきかどうかを判定することと、
    ４）前記ＨＴＴＰクライアント（１０２）が、送信終了トリガが検知されるまでステップ（１）、（２）および（３）を繰り返すことと、
    を含む、データ処理装置と
    を備えるＨＴＴＰクライアント（１０２）。
18. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをＨＴＴＰクライアント（１０２）から受信するためのＨＴＴＰサーバ（１０６）であって、
    前記ＨＴＴＰクライアント（１０２）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信することであって、前記ＨＴＴＰヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰヘッダを受信することと、
    前記ＨＴＴＰヘッダを受信した後に前記ＨＴＴＰ要求メッセージの前記ボディを受信することであって、
    前記ＨＴＴＰクライアント（１０２）から第１のデータチャンクを受信することと、
    前記ＨＴＴＰクライアント（１０２）から第２のデータチャンクを受信することと、
    前記第１のデータチャンクを受信した後、前記第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに前記第１のデータチャンクを発送することとを含む、ＨＴＴＰ要求メッセージのボディを受信することと
    を行うように適合されているＨＴＴＰサーバ（１０６）。
19. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをＨＴＴＰクライアント（１０２）から受信するためのＨＴＴＰサーバ（１０６）であって、
    前記ＨＴＴＰクライアント（１０２）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信するように設定された第１の受信モジュールであって、前記ＨＴＴＰヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、第１の受信モジュールと、
    前記第１の受信モジュールによって前記ＨＴＴＰヘッダを受信した後に、前記ＨＴＴＰ要求メッセージの前記ボディを受信するように設定された第２の受信モジュールであって、前記ＨＴＴＰ要求メッセージの前記ボディを受信することが、
    前記ＨＴＴＰクライアント（１０２）から第１のデータチャンクを受信することと、
    前記ＨＴＴＰクライアント（１０２）から第２のデータチャンクを受信することと、
    前記第１のデータチャンクを受信した後、前記第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、発送モジュールによって配信システムに前記第１のデータチャンクを発送することと
    を含む、第２の受信モジュールと
    を備えるＨＴＴＰサーバ（１０６）。
20. メディアソースによって生成されたライブメディア（オーディオおよび／またはビデオ）フィードをＨＴＴＰクライアント（１０２）から受信するためのＨＴＴＰサーバ（１０６）であって、
    受信器と、
    送信器と、
    データ記憶システムと、
    プロセッサを備え、前記データ記憶システム、前記送信器、および前記受信器に結合されたデータ処理装置であって、
    前記ＨＴＴＰクライアント（１０２）とのトランスポートレイヤ接続（たとえばＴＣＰ接続）を通じて、ボディを含むＨＴＴＰ要求メッセージのためのハイパーテキスト転送プロトコル（ＨＴＴＰ）ヘッダを受信することであって、前記ＨＴＴＰヘッダが前記ＨＴＴＰ要求メッセージの前記ボディのサイズを示さない、ＨＴＴＰヘッダを受信することと、
    前記ＨＴＴＰヘッダを受信した後に前記ＨＴＴＰ要求メッセージの前記ボディを受信することであって、
    前記ＨＴＴＰクライアント（１０２）から第１のデータチャンクを受信することと、
    前記ＨＴＴＰクライアント（１０２）から第２のデータチャンクを受信することと、
    前記第１のデータチャンクを受信した後、前記第２のデータチャンクを受信する前に、ストリーミングビデオを配信するために、配信システムに前記第１のデータチャンクを発送することと
    を含む、前記ＨＴＴＰ要求メッセージの前記ボディを受信することを行うように設定されているデータ処理装置と
    を備えるＨＴＴＰサーバ（１０６）。

Images