JP2018514967A - 部分的セグメント用の表示 - Google Patents

Abstract

様々な実施形態のシステム、方法、およびデバイスは、様々な実施形態によるDASHクライアントにセグメントを提供するHTTPサーバなどのHTTPサーバが、DASHクライアントからのセグメント要求に応答して、不完全バージョンのセグメントを伝えることを可能にする。様々な実施形態は、DASHクライアントなどのクライアントが不完全バージョンのセグメントを構文解析することを可能にし得る。

Description

関連出願
本出願は、2015年3月2日に出願された「Indication for Partial Segment」と題する米国仮特許出願第62/126,842号、および2015年8月13日に出願された「Indication for Partial Segment」と題する米国仮特許出願第62/204,505号の優先権を主張する。両出願の内容全体が、参照により本明細書に組み込まれる。

セグメントと称される個別ファイルの中で送られるビデオフラグメントまたはビデオピースなどの、デジタルファイルのネットワークトランスポートの間、部分的なファイルしか受信されない原因となる様々なイベントまたはエラー(たとえば、離調、無線チャネルエラーなど)が発生することがある。たとえば、コンピューティングデバイス上の現在の発展型マルチメディアブロードキャストマルチキャストサービス(eMBMS)ミドルウェアは、セグメント全体ではなく部分的な動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)セグメントしか受信しないことがある。DASHクライアントなどの、コーデックへの入力を提供するアプリケーションおよび/またはクライアントは、ファイルがアプリケーションおよび/またはクライアントによってその全体が受信されないことがあっても、いくつかの条件下ではファイルのいくつかの部分を復元しコーデックに提供できるようにされ得る。現在のアプリケーションおよび/またはクライアント(たとえば、現在のDASHクライアント)は、現在のアプリケーションおよび/またはクライアントの、部分的セグメントを受信するための能力を示すためのメカニズムを有しないので、部分的セグメントは、アプリケーションおよび/またはクライアントに供給されないことがある。たとえば、コンピューティングデバイス上の現在のeMBMSミドルウェアは、部分的セグメントを落とすことがあり、そのことは再生の中断を増大させることがある。

インターネットエンジニアリングタスクフォース、「Hypertext Transfer Protocol - HTTP/1.1」、1999年6月、http://tools.ietf.org/html/rfc2616

様々な実施形態のシステム、方法、およびデバイスは、様々な実施形態によるDASHクライアントにセグメントを提供するHTTPサーバなどのハイパーテキスト転送プロトコル(HTTP)サーバが、DASHクライアントからのセグメント要求に応答して不完全バージョンのセグメントを伝えることを可能にする。様々な実施形態は、DASHクライアントなどのクライアントが不完全バージョンのセグメントを構文解析することを可能にし得る。

様々な実施形態は、セグメント要求をサーバの中でクライアントから受信することを含み得、ここで、セグメント要求は、セグメント要求の受諾ヘッダフィールド表示またはセグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて、クライアントが不完全セグメントを使用できるかどうかを示す。サーバは、セグメント要求に関連する全体的セグメントがサーバにおいて利用可能であるかどうかを決定し得る。セグメント要求に関連する全体的セグメントがサーバにおいて利用可能でないことに応答して、サーバは、クライアントが不完全セグメントを使用できるかどうかを、セグメント要求の受諾ヘッダフィールド表示またはセグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて決定し得る。クライアントが不完全セグメントを使用できるという決定に応答して、サーバは、不完全セグメントをサーバからクライアントへ送り得る。

さらなる実施形態は、上記で要約した方法の動作を実行するようにプロセッサ実行可能命令を用いて構成されたサーバを含む。さらなる実施形態は、上記で要約した方法の機能を実行するための手段を含むサーバを含む。さらなる実施形態は、上記で要約した方法の動作をサーバプロセッサに実行させるように構成されたプロセッサ実行可能命令を記憶した非一時的プロセッサ可読記憶媒体を含む。

本明細書に組み込まれ、本明細書の一部を構成する添付図面は、本発明の例示的な実施形態を示し、上記の一般的な説明および以下の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。

様々な実施形態とともに使用するのに好適なネットワークの通信システムブロック図である。 様々な実施形態によるコンピューティングデバイスにおけるトランスポート層とアプリケーション層および/またはクライアント層との間の関係を示すシステムブロック図である。 様々な実施形態によるネットワーク要素とコンピューティングデバイスのアプリケーション層および/またはクライアント層との間の関係を示すシステムブロック図である。 不完全バージョンのセグメントを求めるクライアント要求のHTTPサーバ処理のための従来技術方法を示すプロセスフロー図である。 不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための具現化方法を示すプロセスフロー図である。 不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための別の具現化方法を示すプロセスフロー図である。 不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための第3の具現化方法を示すプロセスフロー図である。 様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図である。 様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図である。 不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための第4の具現化方法を示すプロセスフロー図である。 様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図である。 様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図である。 不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための第5の具現化方法を示すプロセスフロー図である。 様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図である。 メディアストリームのセグメントのデータブロック図である。 不完全バージョンのセグメントのDASHクライアント処理のための具現化方法を示すプロセスフロー図である。 様々な実施形態とともに使用するのに好適な例示的なコンピューティングデバイスの構成要素図である。 様々な実施形態とともに使用するのに好適な例示的なサーバの構成要素図である。

様々な実施形態が、添付の図面を参照しながら詳細に説明される。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体にわたって同じ参照番号が使用される。特定の例および実装形態へと行われる言及は説明のためであり、本発明の範囲または特許請求の範囲を限定することを意図しない。

様々な実施形態は、様々な実施形態によるDASHクライアントにDASHメディアファイルのセグメントを提供するDASHサーバなどのHTTPサーバが、DASHクライアントなどのクライアントからのセグメント要求に応答して、不完全バージョンのセグメントを伝えることを可能にする。

本明細書で使用する「モバイルデバイス」、「受信機デバイス」、および「コンピューティングデバイス」という用語は、セルラー電話、スマートフォン、個人用マルチメディアプレーヤまたはモバイルマルチメディアプレーヤ、携帯情報端末(PDA)、ラップトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応セルラー電話、ワイヤレスゲームコントローラ、衛星セットトップボックスまたはケーブルセットトップボックス、ストリーミングメディアプレーヤ(ROKU(商標)またはCHROMECAST(商標)またはFIRE TV(商標)などの)、スマートテレビジョン、デジタルビデオレコーダ(DVR)、ならびにプログラム可能なプロセッサおよびメモリとファイルを受信するための回路とを含む類似のパーソナル電子デバイスの、いずれか1つまたはすべてを指すために、本明細書で互換的に使用される。

マスタ交換サーバ、ウェブサーバ、メールサーバ、文書サーバ、コンテンツサーバ、または任意の他のタイプのサーバなどの、サーバとして機能することができる任意のコンピューティングデバイスを指すための「サーバ」という用語を使用して、様々な実施形態が本明細書で説明される。サーバは、専用のコンピューティングデバイス、または(たとえば、コンピューティングデバイスをサーバとして動作させ得るアプリケーションを実行する)サーバモジュールを含むコンピューティングデバイスであってよい。サーバモジュール(たとえば、サーバアプリケーション)は、全機能のサーバモジュール、または受信機デバイス上の動的データベースの間の同期サービスを提供するように構成されている軽量もしくは2次的なサーバモジュール(たとえば、軽量または2次的なサーバアプリケーション)であってよい。軽量サーバまたは2次的サーバは、受信機デバイス上に実装され得るサーバタイプ機能の小型化されたバージョンであってよく、それによって、それが本明細書で説明する機能を必要な程度まで提供するだけのインターネットサーバ(たとえば、企業電子メールサーバ)として機能することを可能にする。

本明細書で使用する「不完全バージョンのセグメント」という用語は、欠落および/または破損したデータ部分を有する不完全バージョンのファイルを指すために使用される。たとえば、セグメントが0〜999によってインデックス付けされた1,000バイトを含む場合、そのセグメントのバイト0〜888がそのセグメントの不完全バージョンであり、バイト500〜999がそのセグメントの別の不完全バージョンであり、バイト300〜999とともにバイト0〜200がそのセグメントの別の不完全バージョンであるのに対して、バイト0〜999は、そのセグメントの不完全バージョンでない。

http://tools.ietf.org/html/rfc2616において入手可能であり1999年6月に発行された「Hypertext Transfer Protocol - HTTP/1.1」と題するインターネットエンジニアリングタスクフォース提案規格、リクエストフォーコメント(RFC:Request for Comments)2616において規定されている現在のハイパーテキスト転送プロトコル(HTTP)1.1では、サーバがファイル要求に応答して不完全バージョンのファイル(たとえば、欠落/破損したデータ部分を有するファイル)をクライアントに提供するためのメカニズムがない。現在のHTTPプロトコルでは、クライアントは、「GET」メソッドなどのファイル要求を生成し得、ファイル要求をサーバへ送り得る。ファイル要求は、URL/URIに関連するファイルを求める要求であってよく、(たとえば、いかなるバイト範囲も規定しない、したがって、完全ファイルを要求するGET要求を使用して)URL/URIに関連するファイルのデータコンテンツ全体を求める要求であってよく、または(たとえば、完全ファイル内でのバイト範囲を規定する部分的GET要求を使用して)URL/URIに関連する特定のバイト範囲のファイルを求める要求であってよい。

現在のHTTPプロトコルでは、サーバは、クライアントのファイル要求に応答して「全体的応答」またはエラーメッセージを提供することができる。HTTPサーバは、HTTPクライアントのファイル要求に応答して不完全バージョンのファイルを提供しない。完全ファイルを要求するGET要求の場合、HTTPサーバからの全体的応答は完全ファイルであり、不完全バージョンのファイル応答は完全ファイルよりも小さい何か(たとえば、不完全バージョンのファイル)である。バイト範囲を規定する部分的GET要求の場合、HTTPサーバからの全体的応答は完全ファイルと要求されたバイト範囲との間の共通部分であり、不完全バージョンのバイト範囲応答は、完全ファイルと要求されたバイト範囲との間の共通部分よりも小さい何か(たとえば、不完全バージョンのバイト範囲)である。

詳細には、現在のHTTPプロトコルでは、サーバがファイル要求を受信すると、サーバは、ファイル要求に対応するファイルが全体的に利用可能であるかどうかを決定し得る。一例として、サーバは、欠落したデータ部分、ならびに/またはファイルが不完全でありかつ/もしくは破損しているという表示を含むことなどの、ファイル要求に対応するファイルが不完全でありかつ/または破損しているかどうかを決定し得る。一例として、サーバは、FEC復号が成功したのかそれとも成功しなかったのかを決定することによって、ファイル要求に対応するファイルが不完全でありかつ/または破損しているかどうかを決定し得る。別の例として、サーバは、MD5ダイジェストなどの受信されたチェックサムの値とFLUTE受信機によって計算されたチェックサムとの差分を検出することによって、ファイル要求に対応するファイルが不完全でありかつ/または破損しているかどうかを決定し得る。不完全でなくかつ/または破損していないファイルは、全体的に利用可能であるものとサーバによって決定され得、要求されたファイルを含む「全体的応答」の中でクライアントへ送られ得る。現在のHTTPプロトコルでは、要求されたファイルが全体的に利用可能であるとは限らない(すなわち、欠落/破損したデータ部分を有する不完全バージョンのファイルだけが利用可能である)ことを識別すると、サーバは、404「Not Found」ステータスコードを有するメッセージなどの、エラーステータスコードを有するメッセージを戻すにすぎない。したがって、現在のHTTPプロトコルでは、不完全バージョンのファイルは、要求しているクライアントへ送られず、すなわち、ファイルを求める要求への「不完全応答」はサポートされない。

上述のように、現在のHTTPプロトコルはまた、要求されたファイルにとってのバイト範囲を規定する部分的GET要求を提供し、部分的GET要求への全体的応答は、完全ファイルと要求されたバイト範囲との間の共通部分である。たとえば、現在のHTTPでは、完全ファイルの末尾を越えて拡張するバイト範囲を求める部分的GET要求をHTTPクライアントが送るとき、HTTPサーバが提供できる全体的応答は、要求されたバイト範囲の中の最初のバイトから完全ファイルの最後のバイトまでの連続した部分のバイトである。したがって、要求されたバイト範囲が0〜100であるが完全ファイルがバイト0〜88しか有しない例では、全体的応答は、要求されたバイト範囲よりも小さいが(具体的には、バイト0〜88)、それでもなお「全体的応答」と見なされ、HTTPサーバによって送られ得る。

しかしながら、現在のHTTPプロトコルでは、HTTPクライアントが部分的GET要求を送り、規定されたバイト範囲内のバイトのうちのいくつかが欠落/破損しているとき(すなわち、不完全バージョンの要求されたバイト範囲だけがHTTPサーバ上で利用可能であるとき)、HTTPサーバは、要求されたバイトのいかなる部分もクライアントに提供しなくてよく、代わりに、エラーステータスコードを有するメッセージをクライアントへ送る。したがって、要求されたバイト範囲が0〜99であるが、バイト75〜125が欠落または破損しているのでバイト0〜74および126〜150だけが利用可能である例では、現在のHTTPサーバは、バイト0〜74からなる不完全バージョンのバイト範囲応答を、要求しているクライアントへ送らない。したがって、現在のHTTPプロトコルでは、不完全バージョンのバイト範囲要求は、要求しているクライアントへ送られない。これは、バイト範囲のファイルを求める要求への「不完全応答」がサポートされないからである。

現在規定されているようなHTTPプロトコルは不完全応答をクライアントに伝えないので、クライアントおよび/またはアプリケーションが全く不完全応答を受信することがないために、不完全応答を復元および使用できるようにされているクライアントおよび/またはアプリケーションの機能は低減されることがある。したがって、サーバにおいて利用可能である、不完全バージョンのファイルまたは不完全バージョンのバイト範囲のファイルの少なくとも一部分を、HTTPサーバがクライアントに配信するのを可能にすることが有用であり得る。不完全バージョンのファイルまたはバイト範囲の少なくとも一部分の配信により、アプリケーションおよび/またはクライアントを実行する(たとえば、DASHクライアントを実行するスマートフォンのような)クライアントデバイスが、不完全バージョンのセグメントまたはバイト範囲のセグメントの中のメディアの少なくとも一部分を再生することなどの、コンテンツをレンダリングすることが可能になり得、そのことは、エンドユーザメディア再生エクスペリエンスを改善し得る。

様々な実施形態は、セグメントをDASHクライアントに提供するDASHサーバなどのHTTPサーバが、DASHクライアントからのセグメント要求に応答して不完全バージョンのセグメントを伝えることを可能にすることによって、現在のHTTPプロトコルにおけるこの欠点に対処する。一実施形態では、DASHクライアントは、不完全バージョンのセグメント可能表示を含むセグメント要求を生成し得る。そのようなセグメント要求は、クライアントが不完全バージョンのセグメント(たとえば、不完全セグメント)を使用できることを示すヘッダフィールドを含む「GET」動作(すなわち、メソッド)などの要求メッセージであってよい。一実施形態では、ヘッダフィールドは、RFC7231に記載される受諾(accept)ヘッダフィールドであってよい。たとえば、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。一実施形態では、ヘッダフィールドは、RFC7240に記載される選好(prefer)ヘッダフィールドであってよい。たとえば、選好ヘッダフィールド表示「return=3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。一実施形態では、クライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを有するセグメント要求は、セグメントを求める初期要求の中で送られ得る。別の実施形態では、クライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを有するセグメント要求は、サーバから戻されステータスコード404「Not Found」を含むエラーメッセージなどの初期エラーメッセージに応答して送られ得る。初期エラーメッセージの受信に応答して、クライアントは、今度はクライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを含めて、前に要求されたセグメントを再要求し得る。さらなる実施形態では、クライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを有するセグメント要求は、メディアサンプルを位置決定することを可能にするセグメントの重要な部分(ISOBMFFにおける「trun」ボックスなどの)を含む、サーバから戻されたバイト範囲表示に応答して送られ得る。初期バイト範囲表示の受信に応答して、クライアントは、今度はクライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを含めて、セグメントの後続のバイト範囲部分を要求し得る。

一実施形態では、DASHサーバは、不完全バージョンの要求されたセグメントが利用可能であるという表示と、利用可能であるセグメントのバイト範囲とを含む初期応答メッセージを生成し得、送り得る。一実施形態では、応答メッセージは、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能なバイト範囲とを示す拡張ヘッダを含むメッセージであってよい。たとえば、初期応答は、ステータスコード404および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d,…」を含むエラーメッセージであってよい。別の例として、初期応答は、ステータスコード206および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d,…」を含む部分的コンテンツメッセージであってよい。一実施形態では、応答メッセージは、「Content-Type= 3gpp-partial-byte-ranges」などの、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示すエンティティボディを含む、300系列メッセージなどのリダイレクトメッセージであってよい。

不完全バージョンの要求されたセグメントが利用可能であるという表示と、利用可能であるセグメントのバイト範囲とを含む初期応答メッセージの、DASHサーバからの受信に応答して、DASHクライアントは、今度はDASHサーバによって利用可能として示された部分に対応する部分的なバイト範囲要求としての表示を含めて、前に要求されたセグメントを再要求し得る。

一実施形態では、DASHサーバは、アクセス位置表示を含む応答メッセージを生成し得、それを不完全バージョンのファイルを使用できるDASHクライアントへ送り得る。アクセス位置表示は、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)、または不完全バージョンのファイルを復号および/もしくはレンダリングするために使用され得る同期サンプルを識別するために、DASHクライアントがそこにおいて不完全バージョンのファイルにアクセスし得るとともに不完全バージョンのファイルの構文解析を開始し得る、要求されたファイルの中でのバイト(または、他のデータサイズ)位置の表示であってよい。アクセス位置表示は、ファイルごとかつ/または利用可能なバイト範囲ごとに決定され得、示され得る。DASHセグメントの場合、たとえば、1つまたは複数のアクセス位置が決定されてよく、DASHメディアストリームのセグメントを記述するファイル配信テーブル(FDT)の中などでDASHセグメントに関連付けられてよい。たとえば、アクセスポイントは、DASHクライアントがそこにおいてセグメントにアクセスし得る、DASHセグメントの中での1つまたは複数のスペース区切りのバイト位置を示すフィールド「IndependentUnitPositions」において、FDTの中で示され得る。

たとえば、不完全バージョンのDASHセグメントを求める要求のDASHクライアントからの受信に応答して、DASHサーバは、不完全バージョンのDASHセグメントを有するDASHセグメント用の1つまたは複数のアクセス位置の表示を送り得る。別の例として、不完全バージョンのファイルがDASHサーバにおいて利用可能であるとき、DASHサーバは、利用可能であるファイルのバイト範囲ごとに1つまたは複数のアクセス位置を決定し得る。このようにして、DASHサーバは、不完全バージョンのDASHセグメントの第1のバイト範囲(たとえば、バイト範囲a〜b)用の1つまたは複数のアクセス位置、および不完全バージョンのDASHセグメントの第2のバイト範囲(たとえば、バイト範囲c〜d)用の1つまたは複数のアクセス位置を示し得る。

様々な実施形態では、アクセス位置は、DASHサーバによって送られる応答メッセージの中の拡張ヘッダの中で示され得る。応答メッセージは、応答が不完全バージョンの要求されたDASHセグメントを含むことを示し得るとともに、不完全バージョン用のアクセス位置を示し得る。たとえば、応答は、DASHクライアントがそこにおいてセグメントにアクセスし得る、DASHセグメントの中での1つまたは複数のバイト位置を示す拡張ヘッダフィールド「3gpp-access-position」を含み得、同様に、応答が不完全バージョンの要求されたDASHセグメントを含むことを示す、コンテンツタイプとしての「application/3gpp-partial」を含み得る。

一実施形態では、不完全バージョンのセグメントおよびアクセス位置表示を含む応答の受信に応答して、DASHクライアントは、セグメントの初期部分が受信されているかどうかを決定し得る。セグメントの初期部分は、セグメントに対する初期化、インデックス付け、タイミング、および/または同期情報を示すのに専用の、セグメントの冒頭におけるバイトの範囲であり得る。セグメントの初期部分が受信されているという決定に応答して、DASHクライアントは、初期部分の中のタイミングおよび/または同期情報を使用して、不完全バージョンのセグメントの他の受信部分を構文解析し得る。セグメントの初期部分が受信されていないという決定に応答して、DASHクライアントは、アクセス位置に対応するバイトが受信されたかどうかを決定し得る。セグメント用のアクセス位置に対応するバイトが受信されたという決定に応答して、DASHクライアントは、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)、または不完全バージョンのセグメントを復号および/もしくはレンダリングするために使用され得る同期サンプルを識別するために、アクセス位置において不完全バージョンのセグメントの構文解析を開始し得る。セグメント用のアクセス位置に対応するバイトが受信されなかったという決定に応答して、DASHクライアントは、描写における次のセグメントを要求してよい。

一実施形態では、不完全バージョンのファイルを使用できるDASHクライアントが、DASHサーバにおいてバイトが全く利用可能でないファイルを要求することに応答して、DASHサーバはエラーメッセージを生成し得、送り得る。たとえば、要求されたDASHセグメントまたは要求されたバイト範囲のDASHセグメントに対するバイトがDASHサーバにおいて全く利用可能でないとき、DASHサーバは、ステータスコード416「Requested Range Not Satisfiable」を含むエラーメッセージを送り得る。エラーメッセージは、DASHセグメント用のFDTインスタンスの中で提供されるコンテンツタイプ、DASHセグメント用のFDTの中で提供されるコンテンツロケーション、およびDASHセグメント用のFDTの中で示されるコンテンツ長に基づいて「bytes */content-length」として示されるコンテンツ範囲をさらに示し得る。ステータスコード416「Requested Range Not Satisfiable」を含むエラーメッセージを受信することによって、DASHクライアントは、無効なセグメントを求める要求(たとえば、ステータスコード404「Not Found」を有するエラーメッセージをもたらす要求)と、送信の際に失われたセグメント(たとえば、ステータスコード416「Requested Range Not Satisfiable」を有するエラーメッセージをもたらす、FDTの中で示されるが受信されたバイトを有しないセグメント)を求める要求との間を区別し得る。一実施形態では、DASHクライアントは、ステータスコード416を有するエラーメッセージによって示される送信セグメントの紛失を隠してよく、描写における次のセグメントを要求することによって通常動作を継続してよい。

異なるアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、およびトランスポートプロトコルの様々な例、特に、DASHクライアント、eMBMS、およびHTTPが、本明細書で説明される。DASHクライアント、eMBMS、およびHTTPの説明は、様々な実施形態の態様をより良く示すための例として提供されるにすぎず、様々な実施形態をいかなる形でも限定することを意図しない。他のアプリケーション/クライアント、ミドルウェア、無線技術、およびトランスポートプロトコルが様々な実施形態とともに使用されてよく、他のアプリケーション/クライアント、ミドルウェア、無線技術、およびトランスポートプロトコルが本発明の趣旨または範囲から逸脱することなく様々な例において置き換えられてよい。

図1は、様々な実施形態とともに使用するのに好適なセルラーネットワークシステム100を示す。セルラーネットワークシステム100は、コンピューティングデバイス102などの複数のデバイス、1つまたは複数のセルラータワーまたは基地局104、ならびにインターネット110に接続されたサーバ108および112を含み得る。コンピューティングデバイス102は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、モバイル通信用グローバルシステム(GSM（登録商標）)、パーソナル通信サービス(PCS)、第3世代(3G)、第4世代(4G)、ロングタームエボリューション(LTE)、または任意の他のタイプの接続を含む1つまたは複数のセルラー接続106を介して、セルラータワーまたは基地局104とデータを交換し得る。セルラータワーまたは基地局104は、インターネット110に接続し得るルータと通信していることがある。このようにして、セルラータワーもしくは基地局104および/またはインターネット110への接続を介して、コンピューティングデバイス102とサーバ108および112との間でデータが交換され得る。一実施形態では、サーバ108は、出力のためにDASHクライアントを介してセグメントを提供するコンテンツプロバイダサーバまたはエンコーダ(たとえば、コンテンツサーバ)であってよい。一実施形態では、サーバ112は、エンコーダからのセグメント出力を受信し得るとともにコンピューティングデバイス102へのセグメントのオーバージエア(OTA:Over-the-Air)送信を制御し得る、ブロードキャストマルチメディアサービスセンター(BMSC:Broadcast Multimedia Service Center)サーバであってよい。もちろん、本明細書で説明する受信機デバイスの機能はOTA送信を参照しながら説明されることがあるが、これらの機能は、有線送信、ワイヤレス送信、または有線送信とワイヤレス送信の組合せとともに使用されてよい。したがって、OTA送信は必須でない。

図2Aは、コンピューティングデバイスにおけるトランスポート層とアプリケーション層および/またはクライアント層との間の具現化関係を示す。一実施形態では、ファイルは、コンピューティングデバイスにおいて、インターネットプロトコル/ユーザデータグラムプロトコル(IP/UDP)トランスポート層202を介して受信され得る。一例として、図1を参照しながら上記で説明したようにインターネット110を介してサーバ112からコンピューティングデバイス102へ送られるブロードキャストファイルは、コンピューティングデバイス102においてIP/UDPトランスポート層202において受信され得る。一実施形態では、ファイルは、インターネットを介して送られるメディアファイルのセグメントであってよい。

IP/UDPトランスポート層202は、受信されたファイルをファイルデリバリオーバーユニディレクショナルトランスポート(FLUTE:File Delivery over Unidirectional Transport)層204に伝え得る。一実施形態では、FLUTE層204は、FLUTEプロトコルを利用してIP/UDPトランスポート層202からDASHクライアント210などのアプリケーションおよび/またはクライアントにファイルを伝えることができるようにされたアプリケーションであってよい。一実施形態では、FLUTE層204は、受信されたファイルに前方誤り訂正(FEC)などの誤り訂正を適用し得る。一実施形態では、FLUTE層204は、アプリケーションおよび/またはクライアントが不完全バージョンのセグメントを利用できるようにされているかどうかを示し得る表示を、DASHクライアント210などのアプリケーションおよび/またはクライアントから受信し得る。一例として、DASHクライアント210からのファイル要求は、DASHクライアント210が不完全バージョンのファイルを利用できるようにされていることを示し得る。FLUTE層204は、受信されたファイルを構文解析し得、ファイルをDASHサーバ206などのデバイス側HTTPサーバに伝え得る。コンピューティングデバイス上で実行するeMBMSミドルウェア207は、デバイス側DASHサーバ206、FLUTE層204、および/またはIP/UDPトランスポート層202のうちの1つまたは複数を含み得る。一実施形態では、デバイス側DASHサーバ206は、それ自体の割り当て済みメモリ空間(たとえば、メモリキャッシュ)をコンピューティングデバイス上に有する、コンピューティングデバイス上に常駐するHTTPサーバアプリケーションであってよい。一実施形態では、DASHクライアント210は、ファイルをデバイス側DASHサーバ206に要求し得、かつ/またはファイルをデバイス側DASHサーバ206から受信し得、コンピューティングデバイスによるコンテンツの最終的なレンダリング(たとえば、コンテンツを再生すること)のためにファイルをコーデック212に伝え得る。一実施形態では、DASHクライアント210は、コンテンツをレンダリングする際に不完全バージョンのファイルを利用できるようにされ得る。別の実施形態では、DASHクライアント210は、コンテンツをレンダリングする前に不完全バージョンのファイルを修復できるようにされ得る。

図2Bは、ネットワーク要素とコンピューティングデバイスのアプリケーション層および/またはクライアント層との間の具現化関係を示す。一例として、ファイル(たとえば、エンコーダによるDASHメディアストリーム出力のセグメント)が、コンテンツサーバ108(たとえば、DASHサーバ)からサーバ112(たとえば、FLUTE送信側を有するBMSCサーバ)に送られ得る。追加として、コンテンツサーバ108は、ファイル(たとえば、DASHメディアストリームのセグメント)用の1つまたは複数のアクセス位置を決定し得、アクセス位置の表示をサーバ112へ送り得る。アクセス位置は、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)、または不完全バージョンのファイルを復号および/もしくはレンダリングするために使用され得る同期サンプルを識別するために、クライアントがそこにおいて不完全バージョンのファイルにアクセスし得るとともに不完全バージョンのファイルの構文解析を開始し得る、要求されたファイルの中でのバイト位置の表示であってよい。図2Bはアクセス位置がサーバ108によって提供されることを示すが、アクセス位置は、サーバ112、eMBMSミドルウェア207などの、通信システムの中の任意の要素によって決定されてよくかつ/または示されてよい。サーバ112は、コンピューティングデバイス102へ送信するためにファイルをパケット化し得、FLUTEプロトコルに従ってファイル配信テーブル(FDT)を準備し得る。一実施形態では、FDTは、アクセス位置の表示を含み得る。たとえば、FDTは、DASHクライアントがそこにおいてセグメントにアクセスし得る、DASHセグメントの中での1つまたは複数のスペース区切りのバイト位置を示す属性「IndependentUnitPositions」を含み得る。

サーバ112は、ファイルアクセス位置の表示を含むFDTおよびパケットをコンピューティングデバイス102へ送信し得る。パケットは、サーバ112からコンピューティングデバイス102のeMBMSミドルウェア207へ送信する際に失われることがあり、または失われないことがある。ファイルのためのパケットが失われないとき、完全バージョンのファイルがeMBMSミドルウェア207によって組み立てられてよく、DASHクライアント210にとって利用可能にされ得る。ファイルのためのすべてのパケットよりも少ないパケットが失われるとき、またはファイルのためのすべてのパケットよりも少ないパケットが失われ、かつ誤り訂正を適用することによって復元可能でないとき、不完全バージョンのファイルがeMBMSミドルウェア207によって組み立てられてよく、DASHクライアント210にとって利用可能にされ得る。ファイルのためのすべてのパケットが失われ、かつ誤り訂正を適用することによって復元可能でないとき、バージョンなしのファイルがeMBMSミドルウェア207によって組み立てられてよい。eMBMSミドルウェア207は、受信されたFDTの中のファイル表示に基づいて、完全バージョン、不完全バージョン、および/またはバージョンなしのファイルが受信されたかどうかを識別し得る。

DASHクライアント210は、DASHクライアント210が不完全バージョンのファイルを利用できるようにされていることを示すファイル要求(たとえば、HTTP GET動作)を送り得る(たとえば、選好ヘッダフィールド表示「return=3gpp-partial」を伴うGET動作、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作など)。eMBMSミドルウェア207は、DASHクライアント210が不完全バージョンのファイルを利用できるようにされていることをファイル要求が示すことに応答して、(たとえば、デバイス側DASHサーバ206を介して)HTTP応答をDASHクライアント210へ送り得る。一例として、DASHサーバ206は、完全バージョンのファイルが利用可能であるとき、要求された完全ファイルを有する200 OK応答を送り得る。別の例として、DASHサーバ206は、不完全バージョンのファイルが利用可能であるとき、不完全バージョンのファイル、および受信されたFDTの中で示されたそのファイルに関連するアクセス位置の表示を有する200 OK応答を送り得る。さらなる例として、DASHサーバ206は、ファイルの部分が全く利用可能でないとき、ペイロードを全く有しない416「Requested Range Not Satisfiable」応答を送り得る。

図2Aおよび図2Bは、コンピューティングデバイスの1つまたは複数のプロセッサ上で実行するDASHクライアント210およびDASHサーバ206の観点から例示し説明されるが、デバイス内部のサーバ/クライアント交換はサーバ/クライアント交換の一例にすぎず、本明細書で説明する様々な実施形態は、任意のタイプのサーバ/クライアント交換に同様に適用可能であり得る。たとえば、DASHクライアント210およびDASHサーバ206は、インターネットなどの外部ネットワークを介して通信する別個のデバイスであってよい。

図3は、不完全バージョンのセグメントを求めるクライアント要求の現在のHTTPサーバ処理によって採用される従来技術方法300を示す。ブロック302において、クライアントは、セグメント要求を生成し得る。セグメント要求は、セグメントを要求する「GET」動作(すなわち、メソッド)などのメッセージである。セグメント要求は、要求されたセグメントのURL/URIを含む。現在のHTTPプロトコルでは、セグメント要求はまた、URL/URIに関連する全部のセグメントのサブセットを表す1つまたは複数のバイト範囲を含めることによって、URL/URIにおけるセグメントの一部分を求める要求を含み得る「部分的GET」動作を使用して実行され得る。しかしながら、現在のHTTPプロトコルでは、セグメント要求は、「GET」を介して要求された全体的リソースまたは「部分的GET」によって示されるような部分的リソースのいずれに関しても、クライアントが不完全バージョンのセグメントを利用できるようにされているという表示を含まない。実際には、現在のHTTPセグメント要求は、要求されているセグメント全体またはセグメントのサブセット全体をクライアントが使用することができることしか示さない、事実上「すべてか無かの」要求である。

ブロック306において、HTTPサーバは、ブロック304においてクライアントによって送られたセグメント要求を受信する。決定ブロック308において、HTTPサーバは、要求された全体的セグメントが利用可能であるかどうかを決定する。HTTPサーバは、セグメント要求に関連するURL/URIに注意すること、ならびにURL/URIにおけるセグメントが欠落したデータであるかどうか、かつ/または破損しているかどうかを何らかの方法で決定することによって、要求された全体的セグメントが利用可能であるのか、それともサブセット全体が利用可能であるのかを決定し得る。現在のHTTPプロトコルでは、セグメントまたはシークされたサブセット全体が欠落したデータでなくかつ/または破損していない場合のみ、セグメントまたはシークされたサブセット全体は、全体的セグメントであると決定され、戻されるのにふさわしいと見なされる。

要求された全体的セグメントが利用可能であるという決定に応答して(すなわち、決定ブロック308=「Yes」)、HTTPサーバは、ブロック310において、要求されたセグメントを含む応答を送り、ブロック312において、クライアントは、セグメントを含む応答を受信する。応答は、200「OK」などの、要求されたセグメント全体が首尾よく取り出されたことを示すステータスコードを含み得る。

要求された全体的セグメントが利用可能でないという決定に応答して(すなわち、決定ブロック308=「No」)、HTTPサーバは、ブロック314において、要求されたセグメントのいかなる部分も有しないエラーメッセージを送り、クライアントは、ブロック316において、エラーメッセージを受信する。エラーメッセージは、404「Not Found」などのステータスコードを含み得る。現在のHTTP方法300に対する欠点は、サーバにおいて利用可能な不完全バージョンのセグメントをクライアントが全く受信しないことである。したがって、現在のHTTPシステムでは、不完全バージョンのセグメントを使用できるようにされているクライアントは、それらがHTTPサーバから不完全バージョンのセグメントを受信しないので、不完全バージョンのセグメントを再生することによってエンドユーザメディア再生エクスペリエンスを改善することができない。

様々な実施形態は、DASHサーバがクライアント要求に応答して不完全バージョンのセグメントを提供することを可能にすることによって、エンドユーザメディア再生エクスペリエンスを改善する。図4〜図15は、不完全バージョンのセグメントを求めるクライアント要求のサーバ処理のための具現化方法を示す。DASHクライアントデバイスおよびDASHサーバの観点から説明されるが、図4〜図15に示す具現化方法の動作は、クライアント/サーバ関係で動作する任意の2つのデバイスおよび/またはアプリケーションによって実行されてよい。

図4は、不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための具現化方法400を示す。一実施形態では、方法400の動作は、メディアファイル要求への不完全応答をDASHサーバからDASHクライアントに配信するために、DASHクライアントと通信しているDASHサーバによって実行され得る。ブロック402において、DASHクライアントは、不完全バージョンのセグメント可能表示を含むセグメント要求を生成し得る。一実施形態では、不完全バージョンのセグメント可能表示を含むセグメント要求は、DASHクライアントが不完全バージョンのセグメント(たとえば、不完全セグメント)を使用できることを示すヘッダフィールドを含む「GET」動作(すなわち、メソッド)であってよい。一実施形態では、ヘッダフィールドは、RFC7231に記載される受諾ヘッダフィールドであってよい。たとえば、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。一実施形態では、ヘッダフィールドは、RFC7240に記載される選好ヘッダフィールドであってよい。たとえば、選好ヘッダフィールド表示「return=3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。

ブロック404において、DASHクライアントは、セグメント要求をDASHサーバへ送り得、ブロック406において、DASHサーバは、セグメント要求を受信し得る。

決定ブロック408において、DASHサーバは、要求された全体的セグメントが利用可能であるかどうかを決定し得る。一実施形態では、DASHサーバは、セグメント要求に関連するURL/URIに注意すること、ならびにURL/URIにおけるセグメントが欠落したデータであるかどうか、かつ/または破損しているかどうかを何らかの方法で決定することによって、要求された全体的ファイルが利用可能であるかどうかを決定し得る。データを欠落していないかつ/または破損したデータを含まないセグメントは、全体的セグメントであると決定されてよい。データを欠落しているかつ/または破損したデータを含むセグメントは、不完全バージョンのセグメントであると決定されてよい。

要求された全体的セグメントが利用可能であるという決定に応答して(すなわち、決定ブロック408=「Yes」)、DASHサーバは、ブロック410において、要求された全体的セグメントを含む応答を送り得、DASHクライアントは、ブロック412において、要求された全体的セグメントを含む応答を受信し得る。応答は、200「OK」などの、要求されたセグメント全体が首尾よく取り出されたことを示すステータスコードを含み得る。

要求された全体的セグメントが利用可能でないという決定に応答して(すなわち、決定ブロック408=「No」)、DASHサーバは、決定ブロック414において、DASHクライアントが不完全バージョンのセグメントを使用できることを示しているかどうかを決定し得る。一実施形態では、DASHサーバは、DASHクライアントが不完全バージョンのセグメントを使用できることをセグメント要求ヘッダフィールドが示すことに少なくとも部分的に基づいて、DASHクライアントが不完全バージョンのセグメントを使用できると決定し得る。

DASHクライアントが不完全バージョンのセグメントを使用できないという決定に応答して(すなわち、決定ブロック414=「No」)、DASHサーバは、ブロック416において、要求されたセグメントのいかなる部分も有しないエラーメッセージをDASHクライアントへ送り得、DASHクライアントは、ブロック424において、エラーメッセージを受信し得る。一実施形態では、エラーメッセージは、「404 Not Found」などのエラーステータスコードを含む、DASHサーバからDASHクライアントへ送られるメッセージであってよい。

DASHクライアントが不完全バージョンのセグメントを使用できるという決定に応答して(すなわち、決定ブロック414=「Yes」)、DASHサーバは、決定ブロック418において、要求されたセグメントが部分的に利用可能であるかどうかを決定し得る。上記で説明したように、要求されたファイルが部分的に利用可能でないという決定に応答して(すなわち、決定ブロック418=「No」)、DASHサーバは、ブロック416において、セグメントを有しないエラーメッセージを送り得、DASHクライアントは、ブロック424において、エラーメッセージを受信し得る。

要求されたセグメントが部分的に利用可能であるという決定に応答して(すなわち、決定ブロック418=「Yes」)、DASHサーバは、ブロック420において、不完全バージョンのセグメントおよびセグメントが部分的セグメントであるという表示を含む応答をDASHサーバからDASHクライアントへ送り得る。たとえば、応答は、セグメントが部分的セグメントであることを示すコンテンツタイプとしての「application/3gpp-partial」を含み得る。ブロック422において、クライアントデバイスは、不完全バージョンのセグメントを含む応答を受信し得る。コンテンツタイプとしての「application/3gpp-partial」によって識別される応答のペイロードは、コンテンツタイプヘッダの中で識別される境界ストリングを有するマルチパート/バイトレンジとしてフォーマットされ得る、HTTPステータスコード200「OK」の中に含まれ得る。DASHサーバが要求を受信する時間において、サイズが8000バイトの要求されたセグメントのバイト範囲0〜1999および7000〜7999のセットをDASHサーバが有すると想定して、DASHクライアントによって受信されることがあるような応答の例示的な擬似コードを以下に示す。
HTTP/1.1 200 OK
Date: Wed, 25 Feb 2015 06:25:24 GMT
Content-Length: 3241
Content-Type: application/3gpp-partial; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: video/mp4
Content-Range: bytes 0-1999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/mp4
Content-Range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES-

図5は、不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための別の具現化方法500を示す。DASHクライアントが部分的セグメント可能であり得るという特別な表示をその中に全く有しない初期セグメント要求がDASHクライアントによって送られた後に方法500の動作が実行され得ることを除いて、方法500の動作は上記で説明した方法400の動作と類似であり得る。一実施形態では、方法500の動作は、メディアファイル要求への不完全応答をDASHサーバからDASHクライアントに配信するために、DASHクライアントと通信しているDASHサーバによって実行され得る。

一実施形態では、DASHクライアントは、DASHクライアントが不完全バージョンのセグメントを使用できるといういかなる特別な表示も有しない初期セグメント要求を送り得る。要求された全体的セグメントの受信に応答して、DASHクライアントによって追加のアクションが全く行われなくてよい。しかしながら、DASHクライアントは、セグメント要求に応答して、受信されるエラーメッセージを求めて監視し得、初期エラーメッセージの受信に応答して、DASHクライアントは、今度はクライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを含めて、前に要求されたセグメントを再要求し得る。したがって、決定ブロック502において、DASHクライアントは、セグメント要求に応答して、エラーメッセージが受信されているかどうかを決定し得る。エラーメッセージが全く受信されていないという決定に応答して(すなわち、決定ブロック502=「No」)、DASHクライアントは、決定ブロック502において、エラーメッセージを求めて監視し続けてよい。

エラーメッセージが受信されているという決定に応答して(すなわち、決定ブロック502=「Yes」)、DASHクライアントおよびDASHサーバは、エラーメッセージに応答して部分的セグメントを受信しようと試みるために、図4を参照しながら上記で説明した方法400の同様の番号付けされたブロックとしてのブロック402〜424において動作を実行し得る。

図6は、不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための別の具現化方法600を示す。DASHクライアントが部分的セグメントを使用できるという特別な表示をその中に全く有しない初期セグメント要求がDASHクライアントによって送られた後に方法600の動作が実行され得ることを除いて、方法600の動作は上記で説明した方法400の動作と類似であり得る。一実施形態では、方法600の動作は、メディアファイル要求への不完全応答をDASHサーバからDASHクライアントに配信するために、DASHクライアントと通信しているDASHサーバによって実行され得る。

一実施形態では、DASHクライアントは、DASHクライアントが不完全バージョンのセグメントを使用できるといういかなる特別な表示も有しない初期セグメント要求を送り得る。要求された全体的セグメントの受信に応答して、DASHクライアントによって追加のアクションが全く行われなくてよい。しかしながら、DASHクライアントは、バイト範囲表示を求めて監視し得、DASHサーバからのバイト範囲表示の受信に応答して、DASHクライアントは、今度はクライアントが不完全バージョンのセグメントを使用できることを示すヘッダフィールドを含めて、他のバイト範囲を使用するセグメントの後続の部分を要求し得る。したがって、決定ブロック602において、DASHクライアントは、セグメント要求に応答して、バイト範囲が受信されているかどうかを決定し得る。たとえば、DASHクライアントは、ステータスコード206を含む部分的コンテンツメッセージ、およびサーバにおいて利用可能なセグメントの部分のバイト範囲表示が受信されているかどうかを決定し得る。バイト範囲が全く受信されていないという決定に応答して(すなわち、決定ブロック602=「No」)、DASHクライアントは、決定ブロック602において、バイト範囲を求めて監視し続けてよい。バイト範囲が受信されているという決定に応答して(すなわち、決定ブロック602=「Yes」)、DASHクライアントおよびDASHサーバは、受信されたバイト範囲に応答して部分的セグメントを受信しようと試みるために、図4を参照しながら上記で説明した方法400の同様の番号付けされたブロックとしてのブロック402〜424において動作を実行し得る。

図7は、様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図であり、ここで、DASHクライアントは、クライアントが不完全バージョンのセグメントを使用できるという表示を含むセグメント要求を、RFC7231に記載される受諾ヘッダフィールドとして生成し得る。たとえば、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。

たとえば、呼出し系列702において、DASHクライアントは、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得、全体的セグメントがDASHサーバにおいて利用可能であるので、全体的セグメントを有する200応答が戻され得る。呼出し系列704において、DASHクライアントは、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得、セグメントの一部分だけがDASHサーバにおいて利用可能であり得る。DASHクライアントが部分的セグメントを使用できることを受諾ヘッダが示すので、DASHサーバは、DASHクライアントが部分的セグメント可能であると決定し得、部分的セグメントを有する200応答が戻され得る。

呼出し系列706において、DASHクライアントは特別なセグメント機能表示を全く有しないGETを最初に送り得、部分的セグメントだけが利用可能であるので、DASHサーバは、404エラーメッセージを戻し得る。応答において、DASHクライアントは、セグメントを再要求するために、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得る。DASHクライアントが部分的セグメント可能であると受諾ヘッダが示すので、DASHサーバは、DASHクライアントが部分的セグメントを使用できると決定し得、部分的セグメントを有する200応答が戻され得る。

呼出し系列708において、DASHクライアントは、バイト範囲表示を有し特別なセグメント機能表示を全く有しない部分的GETを最初に送り得、要求されたバイト範囲が利用可能であるので、DASHサーバは、206部分的コンテンツメッセージを戻し得る。応答において、DASHクライアントは、バイト1000を越えるバイト範囲などのセグメントの後続の部分を要求するために、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得る。DASHサーバは、受諾ヘッダの中の表示に基づいて、DASHクライアントが部分的セグメントを使用できると決定し得、バイト1000を越える任意のコンテンツを有する206部分的コンテンツ応答を戻し得る。

図8は、様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示し、ここで、DASHクライアントは、不完全バージョンのセグメント可能表示を含むセグメント要求を、RFC7240に記載される選好ヘッダフィールドとして生成し得る。たとえば、選好ヘッダフィールド表示「return=3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。

たとえば、呼出し系列802において、DASHクライアントは、選好ヘッダフィールド表示「return=3gpp-partial」を有するGETを送り得、全体的セグメントがDASHサーバにおいて利用可能であるので、全体的セグメントを有する200応答が戻され得る。

呼出し系列804において、DASHクライアントは、選好ヘッダフィールド表示「return=3gpp-partial」を有するGETを送り得るが、セグメントの一部分だけがDASHサーバにおいて利用可能であり得る。DASHクライアントが部分的セグメントを使用できることを選好ヘッダが示すので、DASHサーバは、DASHクライアントが部分的セグメントを使用できると決定し得、部分的セグメントを有する200応答を戻し得る。

呼出し系列806において、DASHクライアントは、特別なセグメント機能表示を全く有しないGETを最初に送り得、DASHサーバは、部分的セグメントだけが利用可能であり得るので、404エラーメッセージを戻し得る。応答において、DASHクライアントは、セグメントを再要求するために、選好ヘッダフィールド表示「return=3gpp-partial」を有するGETを送り得る。DASHサーバは、選好ヘッダ表示に基づいてDASHクライアントが部分的セグメントを使用できると決定し得、部分的セグメントを有する200応答を戻し得る。

呼出し系列808において、DASHクライアントは、バイト範囲表示を有し特別なセグメント機能表示を全く有しない部分的GETを最初に送り得、要求されたバイト範囲が利用可能であるので、DASHサーバは、206部分的コンテンツメッセージを戻し得る。応答において、DASHクライアントは、バイト1000を越えるバイト範囲などのセグメントの後続の部分を要求するために、選好ヘッダフィールド表示「return=3gpp-partial」を有するGETを送り得る。DASHクライアントが部分的セグメントを使用できることを選好ヘッダが示すので、DASHサーバは、DASHクライアントが部分的セグメントを使用できると決定し得、バイト1000を越える任意のコンテンツを有する206部分的コンテンツ応答を戻し得る。

図9は、不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための具現化方法900を示す。一実施形態では、方法900の動作は、メディアファイル要求への不完全応答をDASHサーバからDASHクライアントに配信するために、DASHクライアントと通信しているDASHサーバによって実行され得る。ブロック902において、DASHクライアントは、セグメント要求を生成し得る。セグメント要求は、DASHクライアント機能のいかなる特別な表示も含まなくてよい。ブロック904において、DASHクライアントは、セグメント要求をDASHサーバへ送り得、ブロック906において、DASHサーバは、セグメント要求を受信し得る。

決定ブロック908において、DASHサーバは、要求された全体的セグメントが利用可能であるかどうかを決定し得る。一実施形態では、DASHサーバは、セグメント要求に関連するURL/URIに注意すること、ならびにURL/URIにおけるセグメントが欠落したデータであるかどうか、かつ/または破損しているかどうかを何らかの方法で決定することによって、要求された全体的ファイルが利用可能であるかどうかを決定し得る。データを欠落していないかつ/または破損したデータを含まないセグメントは、全体的セグメントであると決定されてよい。データを欠落しているかつ/または破損したデータを含むセグメントは、不完全バージョンのセグメントであると決定されてよい。

要求された全体的セグメントが利用可能であるという決定に応答して(すなわち、決定ブロック908=「Yes」)、DASHサーバは、ブロック910において、要求された全体的セグメントを含む応答を送り得、DASHクライアントは、ブロック912において、要求された全体的セグメントを含む応答を受信し得る。応答は、200「OK」などの、要求されたセグメント全体が首尾よく取り出されたことを示すステータスコードを含み得る。

要求された全体的セグメントが利用可能でないという決定に応答して(すなわち、決定ブロック908=「No」)、DASHサーバは、決定ブロック914において、要求されたセグメントが部分的に利用可能であるかどうかを決定し得る。要求されたセグメントが部分的に利用可能でないという決定に応答して(すなわち、決定ブロック914=「No」)、DASHサーバは、ブロック916において、要求されたセグメントのいかなる部分も有しないエラーメッセージをDASHクライアントへ送り得、DASHクライアントは、ブロック918において、エラーメッセージを受信し得る。一実施形態では、エラーメッセージは、「404 Not Found」などのエラーステータスコードを含む、DASHサーバからDASHクライアントへ送られるメッセージであってよい。

セグメントが部分的に利用可能であるという決定に応答して(すなわち、決定ブロック914=「Yes」)、DASHサーバは、ブロック920において、不完全バージョンのセグメントがDASHサーバにおいて利用可能であるという表示を含む応答を、DASHサーバからDASHクライアントへ送り得、DASHクライアントは、ブロック922において、応答を受信し得る。一実施形態では、応答メッセージは、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるセグメントのバイト範囲との表示を含み得る。一実施形態では、応答メッセージは、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能なバイト範囲とを示す拡張ヘッダを含むメッセージであってよい。たとえば、初期応答は、ステータスコード404および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d,…」を含むエラーメッセージであってよい。別の例として、初期応答は、ステータスコード206および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d,…」を含む部分的コンテンツメッセージであってよい。一実施形態では、応答メッセージは、「Content-Type= 3gpp-partial-byte-ranges」などの、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示すエンティティボディを含む、300系列メッセージなどのリダイレクトメッセージであってよい。

ブロック924において、DASHクライアントは、セグメント要求を生成し得る。セグメント要求は、不完全バージョンのセグメントを受信するために生成され得る。セグメント要求は、クライアントが不完全バージョンのセグメントを使用できるという表示を含み得る。たとえば、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。一実施形態では、不完全バージョンのセグメントを求めるセグメント要求は、DASHサーバが示したバイト範囲がセグメントにとって利用可能であったという表示を含む、「部分的GET」動作(すなわち、メソッド)であってよい。ブロック926において、DASHクライアントは、セグメント要求をDASHサーバへ送り得、ブロック928において、DASHサーバは、セグメント要求を受信し得る。

示されたバイト範囲を有するセグメント要求の受信に応答して、DASHサーバは、ブロック930において、不完全バージョンのセグメントを含む応答をDASHクライアントへ送り得る。一実施形態では、不完全バージョンのセグメントを含む応答は、セグメントが部分的セグメントであるという表示を含み得る。たとえば、応答は、セグメントが部分的セグメントであることを示す「boundary=THIS_STRING_SEPARATES」などの、関連する境界表示を有するコンテンツタイプとしての「multipart/byteranges」を含み得る。ブロック932において、クライアントは、不完全バージョンのセグメントを含む応答を受信し得る。

図10は、様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示し、ここで、DASHサーバから最初に送られる応答メッセージは、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示す拡張ヘッダを含むメッセージである。

たとえば、呼出し系列1004において、DASHクライアントからのGETへの初期応答は、ステータスコード406および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d,…」を含む、DASHサーバからのエラーメッセージであってよい。部分的セグメント可能DASHクライアントは、部分的セグメントが利用可能であることを拡張ヘッダが示すと解釈し得、DASHサーバが示したバイト範囲がセグメントにとって利用可能であったという表示を含む部分的GET要求を送り得る。GET要求の中で示されたバイト範囲に基づいて、DASHサーバは、要求された利用可能なセグメント範囲を有する206部分的コンテンツ応答を戻し得る。

別の例として、呼出し系列1006において、DASHクライアントからのGETへの初期応答は、ステータスコード206および拡張ヘッダ「X-Available-Ranges: bytes a-b,c-d」を含む部分的コンテンツメッセージであってよい。部分的セグメント可能DASHクライアントは、部分的セグメントが利用可能であることを拡張ヘッダが示すと解釈し得、DASHサーバが示したバイト範囲がセグメントにとって利用可能であったという表示を含む部分的GET要求を送り得る。GET要求の中に含まれるバイト範囲に基づいて、DASHサーバは、要求された利用可能なセグメント範囲を有する206部分的コンテンツ応答を戻し得る。

図11は、様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示し、ここで、DASHサーバからの初期応答メッセージは、「Content-Type= 3gpp-partial-byte-ranges」などの、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示すエンティティボディを含む、300系列メッセージなどのリダイレクトメッセージである。

たとえば、呼出し系列1104において、DASHクライアントからのGETへの初期応答は、「Content-Type= 3gpp-partial-byte-ranges」などの、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示すエンティティボディを含む、300系列メッセージなどのリダイレクトメッセージであってよい。このようにして、DASHサーバは、DASHクライアントをリダイレクトしなくてよく、むしろセグメントが部分的にのみ利用可能であるという表示を単に有する同じセグメントにクライアントを導き戻してよい。部分的セグメント可能DASHクライアントは、部分的セグメントが利用可能であり得ることを、エンティティボディを有する300メッセージが示すと解釈し得、DASHサーバが示したバイト範囲がセグメントにとって利用可能であったという表示を含む部分的GET要求を送り得る。GET要求の中に含まれるバイト範囲に基づいて、DASHサーバは、要求された利用可能なセグメント範囲を有する206部分的コンテンツ応答を戻し得る。

別の例として、呼出し系列1106において、DASHクライアントは、バイト範囲表示を有し特別なセグメント機能表示を全く有しない部分的GETを最初に送り得、DASHサーバは、利用可能である要求されたバイト範囲を有する206部分的コンテンツメッセージを戻し得る。DASHクライアントは、次いで、バイト1000を越えるバイト範囲などのセグメントの後続の部分を要求するために、部分的GET要求を送り得る。バイト1000を越える部分的セグメントが利用可能であるので、DASHサーバからの応答は、「Content-Type= 3gpp-partial-byte-ranges」などの、不完全バージョンの要求されたセグメントが利用可能であることと、利用可能であるバイト範囲とを示すエンティティボディを含む、300系列メッセージなどのリダイレクトメッセージであってよい。このようにして、DASHサーバは、DASHクライアントをリダイレクトしなくてよく、むしろセグメントが部分的にのみ利用可能であるという表示を単に有する同じセグメントにクライアントを導き戻してよい。部分的セグメント可能DASHクライアントは、部分的セグメントが利用可能であることを、エンティティボディを有する300メッセージが示すと解釈し得、DASHサーバが示したバイト範囲がセグメントにとってバイト1000を越えて利用可能であったという表示を含むGET要求を送り得る。GET要求の中に含まれるバイト範囲に基づいて、DASHサーバは、バイト1000を越える要求された利用可能なセグメント範囲を有する206部分的コンテンツ応答を戻し得る。

図12は、不完全バージョンのセグメントを求めるDASHクライアント要求のDASHサーバ処理のための別の具現化方法1200を示す。アクセス位置がセグメントに関連付けられているときに方法1200の動作が実行され得ることを除いて、方法1200の動作は上記で説明した方法400の動作と類似であり得る。一実施形態では、方法1200の動作は、メディアファイル要求への不完全応答をDASHサーバからDASHクライアントに配信するために、DASHクライアントと通信しているDASHサーバによって実行され得る。ブロック402〜424において、DASHクライアントおよびDASHサーバは、クライアントが不完全バージョンのセグメントを使用できないとき、要求された全体的セグメントまたはエラーメッセージを含む応答を提供するために、図4を参照しながら上記で説明した方法400の同様の番号付けされたブロックの動作を実行し得る。

DASHクライアントが不完全バージョンのセグメントを使用できるという決定に応答して(すなわち、決定ブロック414=「Yes」)、DASHサーバは、決定ブロック1202において、DASHクライアントによって要求されたセグメントがDASHサーバへ送られたことを、受信されたFDTが示したかどうかを決定し得る。要求されたセグメントを含むDASH描写用のFDTを検査することによって、DASHサーバは、要求されたセグメントが描写に関連する実際のセグメントであるかどうかを決定し得る。このようにして、DASHサーバは、メディアストリームのセグメントを求める誤った要求を、メディアストリームのセグメントを求める有効な要求から区別し得る。

FDTが要求されたセグメントを列挙していないという決定に応答して(すなわち、決定ブロック1202=「No」)、ブロック416および424において、DASHサーバおよびDASHクライアントは、エラーを示すために、図4を参照しながら上記で説明した方法400の同様の番号付けされたブロックの動作を実行し得る。

FDTが要求されたセグメントを列挙しているという決定に応答して(すなわち、決定ブロック1202=「Yes」)、DASHサーバは、決定ブロック418において、要求されたセグメントが部分的に利用可能であるかどうかを決定し得る。要求されたファイルが部分的に利用可能でないという決定に応答して(すなわち、決定ブロック418=「No」)、DASHサーバは、ブロック1212において、セグメントを有しないエラーメッセージを送り得る。このようにして、不完全バージョンのセグメントを使用できるDASHクライアントが、DASHサーバにおいてバイトが全く利用可能でないセグメントを要求することに応答して、DASHサーバはエラーメッセージを生成し得、送り得る。たとえば、要求されたDASHセグメントまたは要求されたバイト範囲のDASHセグメントのためのバイトがDASHサーバにおいて全く利用可能でないとき、DASHサーバは、ステータスコード416「Requested Range Not Satisfiable」を含むエラーメッセージを送り得る。エラーメッセージは、DASHセグメント用のFDTインスタンスの中で提供されるコンテンツタイプ、DASHセグメント用のFDTの中で提供されるコンテンツロケーション、およびDASHセグメント用のFDTの中で示されるコンテンツ長に基づいて「bytes */content-length」として示されるコンテンツ範囲をさらに示し得る。

ブロック1214において、DASHクライアントは、エラーメッセージを受信し得る。ステータスコード416「Requested Range Not Satisfiable」を含むエラーメッセージを受信することによって、DASHクライアントは、無効なセグメントを求める要求(たとえば、ステータスコード404「Not Found」を有するエラーメッセージをもたらす要求)と、送信の際に失われたセグメント(たとえば、ステータスコード416「Requested Range Not Satisfiable」を有するエラーメッセージをもたらす、FDTの中で示されるが受信されたバイトを有しないセグメント)を求める要求との間を区別し得る。一実施形態では、DASHクライアントは、ステータスコード416を有するエラーメッセージによって示される送信セグメントの紛失を隠してよく、描写における次のセグメントを要求することによって通常動作を継続してよい。

要求されたセグメントが部分的に利用可能であるという決定に応答して(すなわち、決定ブロック418=「Yes」)、DASHサーバは、ブロック1208において、不完全バージョンのセグメント、セグメントが部分的セグメントであるという表示、およびセグメント用の1つまたは複数のアクセス位置の表示を含む応答を、DASHサーバからDASHクライアントへ送り得る。たとえば、応答は、セグメントが部分的セグメントであることを示すコンテンツタイプとしての「application/3gpp-partial」、およびDASHクライアントがそこにおいてセグメントにアクセスし得る、DASHセグメントの中での1つまたは複数のバイト位置を示す拡張ヘッダフィールド「3gpp-access-position」を含み得る。応答は、応答の中に含まれるセグメントの部分の表示をさらに含み得る。たとえば、応答は、応答の中に含まれるセグメントの1つまたは複数のバイト範囲を示す、1つまたは複数のヘッダフィールド(たとえば、コンテンツ範囲ヘッダフィールド)を含み得る。そのような実施形態では、応答の中に含まれるセグメントの1つまたは複数のバイト範囲を示す1つまたは複数のヘッダフィールドを応答が含む場合、1つまたは複数の拡張ヘッダフィールド「3gpp-access-position」は、1つまたは複数の示されたバイト範囲の中にありDASHクライアントがそこにおいてセグメントにアクセスし得る、1つまたは複数のバイト位置を含み得る。様々な実施形態では、セグメント用の1つまたは複数のアクセス位置は、不完全に受信されたバージョンのDASHセグメントのFDTインスタンスのファイルエントリの「mbms2015:IndependentUnitPositions」属性として、DASHサーバに示され得る。不完全に受信されたバージョンのDASHセグメントのすべてのFDTインスタンスのファイルエントリが「mbms2015:IndependentUnitPositions」属性を含まないとき、DASHサーバは、不完全に受信されたバージョンのDASHセグメントを分析して、1つまたは複数のムービーフラグメントヘッダ(moof:movie fragment header)ロケーションを決定して、1つまたは複数のmoofをセグメント用の1つまたは複数のアクセス位置として識別し得る。

ブロック1210において、DASHクライアントは、不完全バージョンのセグメント、応答が部分的セグメントを含むという表示、および1つまたは複数のアクセスポイントの表示を含む応答を受信し得る。受信された応答はまた、応答の中に、たとえば、コンテンツ範囲ヘッダフィールドの中に含まれるセグメントの部分表示を含み得る。コンテンツタイプとしての「application/3gpp-partial」によって識別される応答のペイロードは、HTTPステータスコード200「OK」の中に含まれてよく、コンテンツタイプヘッダの中で識別される境界ストリングを有するマルチパート/バイトレンジ、およびフィールド「3gpp-access-position」の中で示されるセグメント用のアクセスポイントに対応する1つまたは複数のカンマ区切りのバイト位置としてフォーマットされ得る。

一例では、DASHサーバは、DASHサーバが要求を受信する時間において、サイズが256000バイトの要求されたセグメントのバイト範囲0〜19999、50000〜85000、105500〜199888、および201515〜229566としてのセットを有し得、DASHセグメント用のFDTインスタンスのためのファイルエントリは、値「0 60000 80000 110000」としての後続するリストを有する属性「mbms2015:IndependentUnitPositions」を含み得る。そのような例では、DASHサーバは、第1のアクセス位置のバイト範囲を0〜59999として、第2のアクセス位置のバイト範囲を60000〜79999として、第3のアクセス位置のバイト範囲を80000〜109999として、また第4のアクセス位置のバイト範囲を110000〜255999として識別し得る。DASHサーバにとって利用可能な第1のバイト範囲(0〜19999)が第1のアクセス位置の冒頭を含むので、DASHサーバは、応答の中に「3gpp-access-position: 0」を含めてよい。DASHサーバにとって利用可能な第2のバイト範囲(50000〜85000)は、第2のアクセス位置、および第3のアクセス位置の一部を含み得、したがって、DASHサーバは、応答の中に「3gpp-access-positions: 60000, 80000」を含めてよい。同様に、DASHサーバにとって利用可能な第3のバイト範囲(105500〜199888)は、第4のアクセス位置の一部を含み得、したがって、DASHサーバは、応答の中に「3gpp-access-position: 110000」を含めてよい。最後に、DASHサーバにとって利用可能な第4のバイト範囲(201515〜229566)は、いかなるアクセス位置の開始も含み得ず、その結果、DASHサーバは、応答の中に「3gpp-access-position」要素を含めなくてよい。DASHクライアントによって受信されることがあるような応答の擬似コードにおける一例を以下に示す。
HTTP/1.1 200 OK
…
Content-Length: 172441
Content-Type: application/3gpp-partial; boundary=SEPARATION_STRING
Cache-Control: no-cache
-- SEPARATION_STRING
Content-type video/mp4
Content-range: bytes 0-19999/256000
3gpp-access-position: 0
...<the first range>…
-- SEPARATION_STRING
Content-type video/mp4
Content-range: bytes 50000-85000/256000
3gpp-access-position: 60000,80000
...<the second range>…
-- SEPARATION_STRING
Content-type: video/mp4
Content-range: bytes 105500-199888/256000
3gpp-access-position: 110000
...<the third range>…
-- SEPARATION_STRING
Content-type: video/mp4
Content-range: bytes 201515-229566/256000
...<the fourth range>…
-- SEPARATION_STRING

図13は、様々な実施形態によるDASHクライアントとDASHサーバとの間の相互作用を示すコールフロー図であり、ここで、DASHクライアントがセグメント要求を生成し得る。セグメント要求は、クライアントが不完全バージョンのセグメントを使用できるという表示を、RFC7231に記載される受諾ヘッダフィールドとして含み得る。たとえば、受諾ヘッダフィールド表示「application/3gpp-partial」を伴うGET動作は、DASHクライアントがセグメント要求に応答して部分的セグメントを受諾することを示し得る。

たとえば、呼出し系列1302において、DASHクライアントは、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得、全体的セグメントがDASHサーバにおいて利用可能であるので、全体的セグメントを有する200応答が戻され得る。

呼出し系列1304において、DASHクライアントは、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得る。セグメントの一部分だけがDASHサーバにおいて利用可能であり、DASHクライアントが部分的セグメントを使用できることを受諾ヘッダが示す場合、DASHサーバは、DASHクライアントが部分的セグメント可能であると決定し得、部分的セグメント、部分的セグメントコンテンツタイプヘッダフィールド表示「application/3gpp-partial」、およびアクセス位置表示ヘッダフィールド「3gpp-access-position」を有する200応答をDASHクライアントへ送り得る。

呼出し系列1306において、DASHクライアントは、受諾ヘッダフィールド表示「application/3gpp-partial」を有するGETを送り得る。セグメントのバイトがDASHサーバにおいて全く利用可能であり得ず、DASHクライアントが部分的セグメントを使用できることを受諾ヘッダが示す場合、DASHサーバは、DASHクライアントが部分的セグメント可能であると決定し得、コンテンツタイプヘッダフィールド表示「application/3gpp-partial」を有する416「Requested Range Not Satisfiable」エラーメッセージ、およびコンテンツ範囲「bytes */content-length」をDASHクライアントへ送り得る。

図14は、DASHメディアストリームなどのメディアストリームのセグメントのデータブロック図である。メディアストリームは、初期化セグメント、およびメディアセグメント1、メディアセグメント2などの様々なメディアセグメントを含み得る。メディアセグメントは、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)、またはメディアセグメント(たとえば、ビデオ、オーディオなど、データサンプルを含むバイト範囲のメディアセグメント)の1つもしくは複数のメディアデータ部分(mdat)を復号および/もしくはレンダリングするためにDASHクライアントによって使用され得る同期サンプルを示すデータなどのメタデータを含む、1つまたは複数のmoofを含み得る。様々な実施形態では、メディアセグメントの初期部分は、セグメントの最初のmoofに対応するバイト範囲のメディアセグメントであってよい。

メディアセグメントの最初のmoofがないと、セグメントのmdatは構文解析可能であり得ず、moofおよびmdatのサイズがDASHクライアントに知られ得ないので、セグメントの中での任意の追加のmoofの開始位置はDASHクライアントによって位置決定されないことがある。様々な実施形態は、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)、または不完全バージョンのセグメントを復号および/もしくはレンダリングするために使用され得る同期サンプルを識別するために、DASHクライアントがそこにおいてセグメントにアクセスして不完全バージョンのセグメントの構文解析を開始し得る、メディアセグメントの中でのバイト位置を識別し得るアクセス位置表示(たとえば、属性「3gpp-access-position」によって示される)を提供し得る。このようにして、アクセス位置は、セグメントの初期部分(たとえば、セグメントの最初のmoof)が失われることがあるときにDASHクライアントが不完全バージョンのセグメントを構文解析することを可能にし得る、要求されたバイト範囲または要求されたセグメントの中での中間的なバイト位置であってよい。

たとえば、図14に示すように、メディアセグメント1にとってのmoof1およびmdat1の一部分は、送信の際に失われることがあり、その結果、DASHサーバは、要求しているDASHクライアントに不完全バージョンのメディアセグメント1しか提供できないことになる。不完全バージョンのメディアセグメント1が提供されることを示すこと、および要素「3gpp-access-position」の中でアクセスポイントバイト位置を示すことによって、DASHクライアントは、不完全バージョンが初期部分(たとえば、moof1)を含むかどうかを決定し得る。セグメントの初期部分(たとえば、moof1)が失われ不完全バージョンの中にないという決定に応答して、DASHクライアントは、アクセス位置において構文解析を開始し得る。このようにして、ランダムアクセスポイント(たとえば、ストリームアクセスポイント(SAP)タイプ1または2)または同期サンプルを示すデータなどのmoof2の中のメタデータは、DASHクライアントがmdat2と、後でメディアセグメント2などのメディアセグメントとを復号および/またはレンダリングすることを可能にし得る。

図15は、不完全バージョンのセグメントのDASHクライアント処理のための具現化方法1500を示す。一実施形態では、方法1500の動作は、メディアファイル要求への不完全応答を構文解析するために、DASHクライアントによって実行され得る。上記で説明したように、ブロック1210において、DASHクライアントは、不完全バージョンのセグメント、応答が部分的セグメントを含むという表示、および1つまたは複数のアクセスポイントの表示を含む応答を受信し得る。たとえば、応答は、セグメントが部分的セグメントであることを示すコンテンツタイプとしての「application/3gpp-partial」、およびDASHクライアントがそこにおいてセグメントにアクセスし得る、DASHセグメントの中での1つまたは複数のバイト位置を示す拡張ヘッダフィールド「3gpp-access-position」を含み得る。

随意の決定ブロック1501において、DASHクライアントは、セグメントの初期部分が不完全応答の中で受信されたかどうかを決定し得る。様々な実施形態では、メディアセグメントの初期部分は、セグメントの最初のmoofに対応するバイト範囲のメディアセグメントであってよい。セグメントの初期部分が受信されているという決定に応答して(すなわち、決定ブロック1501=「Yes」)、DASHクライアントは、ブロック1503において、不完全バージョンのセグメントを、初期部分の最初のバイトにおいて開始して構文解析し得る。

セグメントの初期部分が受信されていないという決定に応答して(すなわち、決定ブロック1501=「No」)、またはDASHクライアントが初期部分を検査するように構成されないことがある実施形態では、DASHクライアントは、決定ブロック1502において、アクセス位置におけるバイトが不完全バージョンのセグメントの中で受信されているかどうかを決定し得る。アクセス位置に対応するバイトが受信されていないという決定に応答して(すなわち、決定ブロック1502=「No」)、DASHクライアントは、ブロック1504において、描写における次のセグメントを要求してよい。アクセス位置に対応するバイトが受信されているという決定に応答して(すなわち、決定ブロック1502=「Yes」)、DASHクライアントは、ブロック1506において、不完全バージョンのセグメントを、アクセス位置において開始して構文解析し得る。

様々な実施形態(限定はしないが、図4〜図15を参照しながら上記で説明した実施形態を含む)は、様々なモバイルデバイス(すなわち、受信機デバイス)のいずれかにおいて実施されてよく、その一例が図16に示される。たとえば、モバイルコンピューティングデバイス1600は、タッチスクリーンコントローラ1604および内部メモリ1602に結合されたプロセッサ1601を含み得る。プロセッサ1601は、汎用または特定の処理タスクに対して指定された1つまたは複数のマルチコア集積回路(IC)であってよい。内部メモリ1602は、揮発性メモリまたは不揮発性メモリであってよく、またセキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ1604およびプロセッサ1601はまた、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンパネル1612に結合され得る。モバイルコンピューティングデバイス1600は、送受信するために、互いにかつ/またはプロセッサ1601に結合された1つまたは複数の無線信号トランシーバ1608(たとえば、Peanut(登録商標)、Bluetooth(登録商標)、Zigbee(登録商標)、Wi-Fi、セルラーなど)およびアンテナ1610を有し得る。トランシーバ1608およびアンテナ1610は、様々なワイヤレス送信プロトコルスタックおよびインターフェースを実施するために、前述の回路とともに使用され得る。モバイルコンピューティングデバイス1600は、セルラーネットワークを介した通信を可能にするとともにプロセッサに結合されているセルラーネットワークワイヤレスモデムチップ1616を含み得る。モバイルコンピューティングデバイス1600は、プロセッサ1601に結合された周辺デバイス接続インターフェース1618を含み得る。周辺デバイス接続インターフェース1618は、1つのタイプの接続を受け入れるように単独で構成され得るか、あるいはUSB、FireWire、Thunderbolt、またはPCIeなどの、共通またはプロプライエタリの様々なタイプの物理接続および通信接続を受け入れるように複合的に構成され得る。周辺デバイス接続インターフェース1618はまた、同様に構成された周辺デバイス接続ポート(図示せず)に結合され得る。モバイルコンピューティングデバイス1600はまた、オーディオ出力を提供するためのスピーカー1614を含み得る。モバイルコンピューティングデバイス1600はまた、本明細書で説明する構成要素のうちのすべてまたはいくつかを収容するための、プラスチック、金属、または材料の組合せで構成されたハウジング1620を含み得る。モバイルコンピューティングデバイス1600は、使い捨てバッテリーまたは充電式バッテリーなどの、プロセッサ1601に結合された電源1622を含み得る。充電式バッテリーはまた、モバイルコンピューティングデバイス1600の外部にあるソースから充電電流を受けるために周辺デバイス接続ポートに結合され得る。

様々な実施形態(限定はしないが、図4〜図15を参照しながら上記で説明した実施形態を含む)はまた、図17に示すサーバ1700などの様々な市販のサーバデバイスのいずれかで実施されてよい。そのようなサーバ1700は、通常、揮発性メモリ1702、およびディスクドライブ1704などの大容量不揮発性メモリに結合されたプロセッサ1701を含む。サーバ1700はまた、プロセッサ1701に結合された、フロッピーディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ1706を含み得る。サーバ1700はまた、他の告知システムコンピュータおよびサーバに結合されたローカルエリアネットワーク、インターネット、公衆交換電話網、ならびに/またはセルラーネットワーク(たとえば、CDMA、TDMA、GSM（登録商標）、PCS、3G、4G、LTE、または任意の他のタイプのセルラーネットワーク)などの通信ネットワーク1707とのネットワークインターフェース接続を確立するためにプロセッサ1701に結合された、ネットワークアクセスポートなどの1つまたは複数のネットワークトランシーバ1703を含み得る。

プロセッサ1601および1701は、上記で説明した様々な実施形態の機能を含む様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであってよい。いくつかのデバイスでは、ワイヤレス通信機能に専用の1つのプロセッサおよび他のアプリケーションを実行するのに専用の1つのプロセッサのように、複数のプロセッサが設けられてよい。通常、ソフトウェアアプリケーションは、それらがアクセスされプロセッサ1601および1701の中にロードされる前に、内部メモリに記憶され得る。プロセッサ1601および1701は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。多くのデバイスでは、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、またはその両方の混合物であってよい。この説明の目的のために、メモリへの一般的な言及は、内部メモリ、またはデバイスに差し込まれるリムーバブルメモリ、ならびにプロセッサ1601および1701自体の中のメモリを含む、プロセッサ1601および1701によってアクセス可能なメモリを指す。

前述の方法の説明およびプロセスフロー図は、例示的な例として与えられるにすぎず、様々な実施形態のステップが、提示された順序で実行されなければならないことを要求または示唆するものではない。当業者によって諒解されるように、前述の実施形態におけるステップの順序は、任意の順序で実行されてよい。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は単に、方法の説明を通じて読者を案内するために使用される。さらに、たとえば冠詞「a」、「an」、または「the」を使用する、請求項の要素に対する単数形でのいかなる参照も、要素を単数形に限定すると解釈されるべきではない。

本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概してそれらの機能性に関して上記で説明された。そのような機能がハードウェアとして実装されるのか、それともソフトウェアとして実装されるのかは、特定の適用例および全体的なシステムに課された設計制約によって決まる。当業者は説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装決定は本発明の範囲からの逸脱を引き起こすものと解釈されるべきではない。

本明細書で開示する態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行されてもよい。

1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読媒体または非一時的プロセッサ可読媒体上に1つまたは複数の命令またはコードとして記憶され得る。本明細書で開示する方法またはアルゴリズムのステップは、非一時的コンピュータ可読記憶媒体または非一時的プロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェアモジュールおよび/またはプロセッサ実行可能命令で具現化され得る。非一時的サーバ可読記憶媒体、非一時的コンピュータ可読記憶媒体、または非一時的プロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る任意の記憶媒体であってよい。限定ではなく例として、そのような非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、または非一時的プロセッサ可読媒体は、RAM、ROM、EEPROM、フラッシュメモリ、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を含み得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray（登録商標）ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せも、非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、および非一時的プロセッサ可読媒体の範囲内に含まれる。追加として、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、非一時的サーバ可読媒体、非一時的プロセッサ可読媒体、および/または非一時的コンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せまたはセットとして存在してもよい。

開示した実施形態の前述の説明は、いかなる当業者も本発明を作成または使用することができるように提供される。これらの実施形態に対する様々な修正は当業者には容易に明らかとなり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用されてよい。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。

100 セルラーネットワークシステム
102 コンピューティングデバイス
104 セルラータワーまたは基地局
106 セルラー接続
108 サーバ
110 インターネット
112 サーバ
202 IP/UDPトランスポート層
204 FLUTE層
206 DASHサーバ
207 eMBMSミドルウェア
210 DASHクライアント
212 コーデック
1600 モバイルコンピューティングデバイス
1601 プロセッサ
1602 内部メモリ
1604 タッチスクリーンコントローラ
1608 無線信号トランシーバ
1610 アンテナ
1612 タッチスクリーンパネル
1614 スピーカー
1616 セルラーネットワークワイヤレスモデムチップ
1618 周辺デバイス接続インターフェース
1620 ハウジング
1622 電源
1700 サーバ
1701 プロセッサ
1702 揮発性メモリ
1703 ネットワークトランシーバ
1704 ディスクドライブ
1706 フロッピーディスクドライブ、コンパクトディスクドライブ、またはDVDディスクドライブ
1707 通信ネットワーク

Claims (28)

1. メディアファイル要求への不完全応答をサーバからクライアントに配信するための方法であって、
   セグメント要求を前記サーバの中で前記クライアントから受信するステップであって、前記セグメント要求が、前記セグメント要求の受諾ヘッダフィールド表示または前記セグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて、前記クライアントが不完全セグメントを使用できるかどうかを示す、ステップと、
   前記セグメント要求に関連する全体的セグメントが前記サーバにおいて利用可能であるかどうかを、前記サーバの中で決定するステップと、
   前記セグメント要求に関連する前記全体的セグメントが前記サーバにおいて利用可能でないことに応答して、前記クライアントが不完全セグメントを使用できるかどうかを、前記セグメント要求の前記受諾ヘッダフィールド表示または前記セグメント要求の前記選好ヘッダフィールド表示に少なくとも部分的に基づいて、前記サーバの中で決定するステップと、
   前記クライアントが不完全セグメントを使用できるという決定に応答して、不完全セグメントを前記サーバから前記クライアントへ送るステップと
   を備える方法。
2. 前記セグメント要求が、前記サーバによって前に送られたエラーメッセージまたは部分的コンテンツメッセージに応答して、前記クライアントから送られる、請求項1に記載の方法。
3. 前記セグメント要求が、前記全体的セグメントに関連する初期要求として、前記クライアントから送られる、請求項1に記載の方法。
4. 前記セグメント要求が、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの少なくとも1つのバイト範囲とを示す、前記サーバからの初期応答メッセージに応答して、前記クライアントから送られる、請求項1に記載の方法。
5. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示す拡張ヘッダを有するエラーメッセージまたは部分的コンテンツメッセージである、請求項4に記載の方法。
6. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示すエンティティボディを含むリダイレクトメッセージである、請求項4に記載の方法。
7. 前記クライアントがDASHクライアントであり、前記サーバがDASHサーバである、請求項1に記載の方法。
8. サーバであって、
   動作を実行するようにプロセッサ実行可能命令を用いて構成されたプロセッサを備え、前記動作が、
   セグメント要求をクライアントから受信することであって、前記セグメント要求が、前記セグメント要求の受諾ヘッダフィールド表示または前記セグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて、前記クライアントが不完全セグメントを使用できるかどうかを示すことと、
   前記セグメント要求に関連する全体的セグメントが利用可能であるかどうかを決定することと、
   前記セグメント要求に関連する前記全体的セグメントが利用可能でないことに応答して、前記クライアントが不完全セグメントを使用できるかどうかを、前記セグメント要求の前記受諾ヘッダフィールド表示または前記セグメント要求の前記選好ヘッダフィールド表示に少なくとも部分的に基づいて決定することと、
   前記クライアントが不完全セグメントを使用できるという決定に応答して、不完全セグメントを前記クライアントへ送ることと
   を備える、サーバ。
9. 前記セグメント要求が、前に送られたエラーメッセージまたは前に送られた部分的コンテンツメッセージに応答して、前記クライアントから送られる、請求項8に記載のサーバ。
10. 前記セグメント要求が、前記全体的セグメントに関連する初期要求として、前記クライアントから送られる、請求項8に記載のサーバ。
11. 前記セグメント要求が、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの少なくとも1つのバイト範囲とを示す初期応答メッセージに応答して、前記クライアントから送られる、請求項8に記載のサーバ。
12. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示す拡張ヘッダを有するエラーメッセージまたは部分的コンテンツメッセージであるような動作を実行するように、前記プロセッサがプロセッサ実行可能命令を用いて構成される、請求項11に記載のサーバ。
13. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示すエンティティボディを含むリダイレクトメッセージであるような動作を実行するように、前記プロセッサがプロセッサ実行可能命令を用いて構成される、請求項11に記載のサーバ。
14. 前記クライアントがDASHクライアントである、請求項8に記載のサーバ。
15. サーバであって、
    セグメント要求をクライアントから受信するための手段であって、前記セグメント要求が、前記セグメント要求の受諾ヘッダフィールド表示または前記セグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて、前記クライアントが不完全セグメントを使用できるかどうかを示す、手段と、
    前記セグメント要求に関連する全体的セグメントが利用可能であるかどうかを決定するための手段と、
    前記セグメント要求に関連する前記全体的セグメントが利用可能でないことに応答して、前記クライアントが不完全セグメントを使用できるかどうかを、前記セグメント要求の前記受諾ヘッダフィールド表示または前記セグメント要求の前記選好ヘッダフィールド表示に少なくとも部分的に基づいて決定するための手段と、
    前記クライアントが不完全セグメントを使用できるという決定に応答して、不完全セグメントを前記クライアントへ送るための手段と
    を備えるサーバ。
16. 前記セグメント要求が、前に送られたエラーメッセージまたは前に送られた部分的コンテンツメッセージに応答して、前記クライアントから送られる、請求項15に記載のサーバ。
17. 前記セグメント要求が、前記全体的セグメントに関連する初期要求として、前記クライアントから送られる、請求項15に記載のサーバ。
18. 前記セグメント要求が、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの少なくとも1つのバイト範囲とを示す初期応答メッセージに応答して、前記クライアントから送られる、請求項15に記載のサーバ。
19. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示す拡張ヘッダを有するエラーメッセージまたは部分的コンテンツメッセージである、請求項18に記載のサーバ。
20. 前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示すエンティティボディを含むリダイレクトメッセージである、請求項18に記載のサーバ。
21. 前記クライアントがDASHクライアントである、請求項15に記載のサーバ。
22. サーバプロセッサに動作を実行させるように構成されたプロセッサ実行可能命令を記憶した非一時的プロセッサ可読記憶媒体であって、前記動作が、
    セグメント要求をクライアントから受信することであって、前記セグメント要求が、前記セグメント要求の受諾ヘッダフィールド表示または前記セグメント要求の選好ヘッダフィールド表示に少なくとも部分的に基づいて、前記クライアントが不完全セグメントを使用できるかどうかを示すことと、
    前記セグメント要求に関連する全体的セグメントが利用可能であるかどうかを決定することと、
    前記セグメント要求に関連する前記全体的セグメントが利用可能でないことに応答して、前記クライアントが不完全セグメントを使用できるかどうかを、前記セグメント要求の前記受諾ヘッダフィールド表示または前記セグメント要求の前記選好ヘッダフィールド表示に少なくとも部分的に基づいて決定することと、
    前記クライアントが不完全セグメントを使用できるという決定に応答して、不完全セグメントを前記クライアントへ送ることと
    を備える、非一時的プロセッサ可読記憶媒体。
23. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記セグメント要求が、前に送られたエラーメッセージまたは前に送られた部分的コンテンツメッセージに応答して、前記クライアントから送られるような動作を実行させるように構成される、請求項22に記載の非一時的プロセッサ可読記憶媒体。
24. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記セグメント要求が、前記全体的セグメントに関連する初期要求として、前記クライアントから送られるような動作を実行させるように構成される、請求項22に記載の非一時的プロセッサ可読記憶媒体。
25. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記セグメント要求が、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの少なくとも1つのバイト範囲とを示す初期応答メッセージに応答して、前記クライアントから送られるような動作を実行させるように構成される、請求項22に記載の非一時的プロセッサ可読記憶媒体。
26. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示す拡張ヘッダを有するエラーメッセージまたは部分的コンテンツメッセージであるような動作を実行させるように構成される、請求項25に記載の非一時的プロセッサ可読記憶媒体。
27. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記初期応答メッセージが、前記不完全セグメントが利用可能であることと、利用可能である前記不完全セグメントの前記少なくとも1つのバイト範囲とを示すエンティティボディを含むリダイレクトメッセージであるような動作を実行させるように構成される、請求項25に記載の非一時的プロセッサ可読記憶媒体。
28. 前記記憶されたプロセッサ実行可能命令が、前記サーバプロセッサに、前記クライアントがDASHクライアントであるような動作を実行させるように構成される、請求項22に記載の非一時的プロセッサ可読記憶媒体。