(57)【特許請求の範囲】
【請求項１】
受信機デバイスにおいてメディアコンテンツの開始時間を管理するための方法であって、
前記受信機デバイスのプロセッサによって、送出デバイスからの送信時間でラベル付けされたメディアコンテンツを受信するステップと、
前記メディアコンテンツのバイト範囲の要求を、前記プロセッサによって受信するステップと、
前記プロセッサによって、前記送出デバイスからの前記送信時間と前記バイト範囲に固有のサービス関連遅延とに基づいて、前記要求されたバイト範囲のためのサービス構築遅延を決定するステップと、
前記プロセッサによって、前記受信機デバイスのローカル時間を決定するとともに、
前記プロセッサによって、前記受信機デバイスの前記ローカル時間と前記送信時間を比較すること
によって前記バイト範囲のプロトコルスタック遅延を、前記プロセッサによって決定するステップと、
前記プロセッサによって、前記サービス構築遅延および前記プロトコルスタック遅延に基づいて前記バイト範囲の時間オフセットを決定するステップと、
前記プロセッサによって、前記時間オフセットを使用してストリーミングメディアクライアントに前記バイト範囲を配信するステップと
を含む、方法。
【請求項２】
前記プロセッサによって、前記決定された時間オフセットに基づいて前記メディアコンテンツの開始時間を決定するステップ
をさらに含み、
前記プロセッサによって、前記時間オフセットを使用してストリーミングメディアクライアントに前記バイト範囲を配信するステップが、
前記プロセッサによって、前記開始時間に基づいて前記ストリーミングメディアクライアントに前記メディアコンテンツを配信するステップ
を含む、請求項1に記載の方法。
【請求項３】
クライアントアプリケーションからプロトコルスタックのトランスポート層へのメディアコンテンツを求める要求が、前記要求されるメディアコンテンツがトランスポートバッファに完全に存在しないうちに到着することに応答して、前記プロトコルスタックの前記トランスポート層が、前記要求を前記要求されるメディアコンテンツのバイト範囲配信の要求として解釈する、請求項1に記載の方法。
【請求項４】
前記プロトコルスタック遅延が、前記受信機デバイスのプロトコルスタックによる前記メディアコンテンツの処理に起因する遅延時間を含む、請求項1に記載の方法。
【請求項５】
前記プロトコルスタック遅延を決定するステップが、前記メディアコンテンツのメディアコンテンツ部分が前記受信機デバイスのプロトコルスタックのトランスポート層によって処理された後に、前記プロトコルスタック遅延を決定するステップを含む、請求項1に記載の方法。
【請求項６】
前記プロトコルスタック遅延を決定するステップが、前記受信機デバイスのメモリから、所定のプロトコルスタック遅延値を検索するステップを含む、請求項1に記載の方法。
【請求項７】
前記メディアコンテンツの開始時間を決定するステップが、
前記プロセッサによって、前記時間オフセットに基づいて前記メディアコンテンツのメディアプレゼンテーション記述を変更するステップと、
前記プロセッサによって、前記変更されたメディアプレゼンテーション記述に基づいて前記メディアコンテンツの開始時間を決定するステップと
を含む、請求項2に記載の方法。
【請求項８】
前記メディアコンテンツの開始時間を決定するステップが、
前記プロセッサによって、前記時間オフセットに基づいて前記受信機デバイスのローカル時間を変更するステップと、
前記プロセッサによって、前記変更されたローカル時間に基づいて前記メディアコンテンツの開始時間を決定するステップと
を含む、請求項2に記載の方法。
【請求項９】
前記プロセッサによって、前記決定された時間オフセットに基づいてタイマーを生成するステップ
をさらに含み、
前記プロセッサによって、前記時間オフセットを使用してストリーミングメディアクライアントに前記バイト範囲を配信するステップが、前記プロセッサによって、前記タイマーの満了に応答して前記ストリーミングメディアクライアントに前記メディアコンテンツを配信するステップを含む、
請求項1に記載の方法。
【請求項１０】
受信機デバイスのプロセッサに動作を実行させるように構成されたプロセッサ実行可能命令を記憶した非一時的プロセッサ可読記憶媒体であって、前記動作が、
送出デバイスからの送信時間でラベル付けされたメディアコンテンツを受信することと、
前記メディアコンテンツのバイト範囲の要求を受信することと、
前記送出デバイスからの前記送信時間と前記バイト範囲に固有のサービス関連遅延とに基づいて、前記要求されたバイト範囲のためのサービス構築遅延を決定することと、
前記受信機デバイスのローカル時間を決定するとともに、
前記受信機デバイスの前記ローカル時間と前記送信時間を比較すること
によって前記バイト範囲のプロトコルスタック遅延を決定することと、
前記サービス構築遅延および前記プロトコルスタック遅延に基づいて前記バイト範囲の時間オフセットを決定することと、
前記時間オフセットを使用してストリーミングメディアクライアントに前記バイト範囲を配信することと
を含む、非一時的プロセッサ可読記憶媒体。
【請求項１１】
送出デバイスからの送信時間でラベル付けされたメディアコンテンツを受信するための手段と、
前記メディアコンテンツのバイト範囲の要求を受信するための手段と、
前記送出デバイスからの前記送信時間と前記バイト範囲に固有のサービス関連遅延とに基づいて、前記要求されたバイト範囲のためのサービス構築遅延を決定するための手段と、
プロセッサによって、受信機デバイスのローカル時間を決定するとともに、
前記プロセッサによって、前記受信機デバイスの前記ローカル時間と前記送信時間を比較すること
によって前記バイト範囲のプロトコルスタック遅延を決定するための手段と、
前記サービス構築遅延および前記プロトコルスタック遅延に基づいて前記バイト範囲の時間オフセットを決定するための手段と、
前記時間オフセットを使用してストリーミングメディアクライアントに前記バイト範囲を配信するための手段と
を備える、受信機デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、2015年2月26日に出願された「Delay Compensation For Broadcast Adaptive Bitrate Streaming」という名称の米国仮特許出願第62/121,303号、および2015年2月27日に出願された「Delay Compensation For Broadcast Adaptive Bitrate Streaming」という名称の米国仮特許出願第62/126,089号の優先権の利益を主張し、上記の仮出願の両方の内容全体が参照によって本明細書に組み込まれる。
【背景技術】
【０００２】
適応ビットレートストリーミングは、通信ネットワークを通じてメディアデータ(ビデオ、オーディオ、その他のマルチメディアデータなど)をストリーミングする際に使用される技法である。適応ビットレートストリーミング技法の例には、ハイパーテキスト転送プロトコル(HTTP)による動的適応ストリーミング(DASH:Dynamic Adaptive Streaming over Hypertext Transfer Protocol)、Flash用のAdobe Dynamic Streaming、AppleのHTTP Live Streaming(「HLS」)、およびMicrosoftのSmooth Streamingが含まれる。DASHは、HTTPプロトコルを使用する適応ストリーミングをサポートするストリーミング規格である。DASHの一変形態では、メディアインターバルが、1つまたは複数の階層化されたチャンクから構成される場合があり、基本層チャンクにさらなる階層化されたチャンクが追加されるたびに、そのメディアインターバルのメディアプレゼンテーションの品質が上がる場合がある。各メディアインターバルが基本層チャンクと、1つまたは複数の拡張層チャンクとを含むように、各メディアプレゼンテーションは、スケーラブルエンコーダを使用して符号化されてもよい。
【０００３】
ストリーミングされたコンテンツデータ(たとえば、メディアコンテンツ)は、ストリーミングメディアクライアントなどのクライアントアプリケーションによって受信機デバイスにおいて受信およびレンダリングされる。遅延の中でも、受信コンテンツデータは、受信機デバイスのプロトコルスタックによるコンテンツデータの処理に起因する遅延が生じる場合がある。受信機デバイスは、あるレベルの遅延を予期するように構成されてもよいが、予期されるよりも多いまたは少ない遅延がある場合、ストリーミングメディアクライアントのパフォーマンスは悪影響を受ける場合がある。たとえば、ストリーミングメディアクライアントがコンテンツデータの提示を始めるのが、またはストリーミングメディアクライアントが起動するのが、早すぎる、または遅すぎる場合がある。ストリーミングメディアクライアントがコンテンツデータを提示し始めるのが早すぎるとき、コンテンツの滑らかなプレゼンテーションのための十分なデータがないために、プレゼンテーション停止(presentation stall)になる場合がある。ストリーミングメディアクライアントがコンテンツデータを提示し始めるのが遅すぎるとき、ストリーミングメディアクライアントは、厳密に必要であるよりも長くコンテンツデータのプレゼンテーションを遅らせ、チャネル変更パフォーマンス(channel change performance)を低下させ、全体的な待ち時間を不必要に増やす場合がある。
【発明の概要】
【課題を解決するための手段】
【０００４】
様々な実施形態は、メディアコンテンツの開始時間を管理するための、受信機デバイスで実施され得る方法を含む。様々な実施形態は、受信機デバイスのプロセッサによって、送出デバイスからの送信時間でラベル付けされたメディアコンテンツを受信することと、プロセッサによって、メディアコンテンツのサービス構築遅延を決定することと、プロセッサによって、サービス構築遅延に基づいてメディアコンテンツの時間オフセットを決定することと、プロセッサによって、時間オフセットを使用してストリーミングメディアクライアントにメディアコンテンツを配信することとを含んでもよい。
【０００５】
いくつかの実施形態は、プロセッサによって、決定された時間オフセットに基づいてメディアコンテンツの開始時間を決定することをさらに含んでもよく、プロセッサによって、時間オフセットを使用してストリーミングメディアクライアントにメディアコンテンツを配信することが、プロセッサによって、開始時間に基づいてストリーミングメディアクライアントにメディアコンテンツを配信することを含む。いくつかの実施形態は、プロセッサによって、メディアコンテンツのプロトコルスタック遅延を決定することをさらに含んでもよい。
【０００６】
いくつかの実施形態では、メディアコンテンツのプロトコルスタック遅延を決定することは、プロセッサによって、受信機デバイスのローカル時間を決定することと、プロセッサによって、送信時間を受信機デバイスのローカル時間と比較することとを含んでもよい。そのような実施形態では、メディアコンテンツの時間オフセットを決定することは、プロトコルスタック遅延に基づいて時間オフセットを決定することを含んでもよい。
【０００７】
いくつかの実施形態では、プロセッサによって、メディアコンテンツのサービス構築遅延を決定することは、メディアコンテンツのトランスポート層プレゼンテーション時間に基づいてサービス構築遅延を決定することを含んでもよい。いくつかの実施形態は、プロセッサによって、メディアコンテンツのバイト範囲の要求を受信することをさらに含んでもよく、メディアコンテンツのサービス構築遅延を決定することは、メディアコンテンツの要求されるバイト範囲に対するサービス構築遅延に基づいてサービス構築遅延を決定することを含んでもよい。
【０００８】
いくつかの実施形態では、クライアントアプリケーションからプロトコルスタックのトランスポート層へのメディアコンテンツの要求が、要求されるメディアコンテンツがトランスポートバッファに完全に存在しないうちに到着することに応答して、プロトコルスタックのトランスポート層はその要求を、要求されるメディアコンテンツのバイト範囲配信の要求として解釈してもよい。いくつかの実施形態では、決定された時間オフセットに基づいてメディアコンテンツの開始時間を決定することは、メディアコンテンツの決定されたプロトコルスタック遅延とトランスポート層プレゼンテーション時間の和を決定することを含んでもよい。いくつかの実施形態では、メディアコンテンツのプロトコルスタック遅延は、受信機デバイスのプロトコルスタックによるメディアコンテンツの処理に起因する遅延時間を含んでもよい。
【０００９】
いくつかの実施形態では、メディアコンテンツのプロトコルスタック遅延を決定することは、メディアコンテンツのメディアコンテンツ部分が、受信機デバイスのプロトコルスタックのトランスポート層によって処理された後にプロトコルスタック遅延を決定することを含んでもよい。いくつかの実施形態では、メディアコンテンツのプロトコルスタック遅延を決定することは、受信機デバイスのメモリから、所定のプロトコルスタック遅延値を検索することを含んでもよい。いくつかの実施形態では、メディアコンテンツの開始時間を決定することは、プロセッサによって、時間オフセットに基づいてメディアコンテンツのメディアプレゼンテーション記述を変更することと、プロセッサによって、変更されたメディアプレゼンテーション記述に基づいてメディアコンテンツの開始時間を決定することとを含んでもよい。
【００１０】
いくつかの実施形態では、メディアコンテンツの開始時間を決定することは、プロセッサによって、時間オフセットに基づいて受信機デバイスのローカル時間を変更することと、プロセッサによって、変更されたローカル時間に基づいてメディアコンテンツの開始時間を決定することとを含んでもよい。いくつかの実施形態では、メディアコンテンツは、送出デバイスからの送信時間でラベル付けされたヘッダ部分を含んでもよい。いくつかの実施形態は、プロセッサによって、決定された時間オフセットに基づいてタイマーを生成することをさらに含んでもよく、プロセッサによって、時間オフセットを使用してストリーミングメディアクライアントにメディアコンテンツを配信することが、プロセッサによって、タイマーの満了に応答してストリーミングメディアクライアントにメディアコンテンツを配信することを含んでもよい。
【００１１】
さらなる実施形態は、メモリと、受信機回路と、メモリおよび受信機回路に結合され、上記で説明した方法の動作を実行するプロセッサ実行可能命令で構成されたプロセッサとを含む受信機デバイスを含んでもよい。さらなる実施形態は、上記で説明した方法の機能を実施するための手段を含む受信機デバイスを含んでもよい。さらなる実施形態様は、受信機デバイスのプロセッサに上記で説明した方法の動作を実行させるように構成されたプロセッサ実行可能命令が記憶されたプロセッサ可読記憶媒体を含んでもよい。
【００１２】
本明細書に組み込まれ、本明細書の一部の構成する添付図面は、様々な実施形態の例を示し、上記の全体的な説明および以下の詳細な説明とともに、様々な実施形態の特徴を説明するのに役立つ。
【図面の簡単な説明】
【００１３】
【図１Ａ】様々な実施形態とともに使用するのに適した通信システムのブロック図である。
【図１Ｂ】様々な実施形態とともに使用するのに適した通信システムのブロック図である。
【図２】様々な実施形態とともに使用するのに適したストリーミングメディアクライアントのプロトコルスタックのブロック図である。
【図３】様々な実施形態とともに使用するのに適した通信システムのブロック図である。
【図４Ａ】様々な実施形態による、コンテンツ利用可能開始時間を決定するために使用される場合がある値の関係を示す図である。
【図４Ｂ】受信機デバイスにおけるメディアコンテンツの開始時間を管理するための方法を示すコールフロー図である。
【図５】様々な実施形態による受信機デバイスにおけるメディアコンテンツの開始時間を管理するための方法を示すプロセスフロー図である。
【図６】様々な実施形態とともに使用するのに適した例示的な受信機デバイスの構成要素図である。
【図７】様々な実施形態とともに使用するのに適した例示的なサーバの構成要素図である。
【発明を実施するための形態】
【００１４】
添付の図面を参照しながら、様々な実施形態について詳細に説明する。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。特定の例および実装形態への言及は説明を目的とし、様々な実施形態の範囲または特許請求の範囲を限定するものではない。
【００１５】
本明細書で使用する「受信デバイス」、および「受信機デバイス」という用語は、携帯電話、スマートフォン、個人用マルチメディアプレーヤーまたはモバイルマルチメディアプレーヤー、携帯情報端末(PDA)、ラップトップコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応携帯電話、ワイヤレスゲームコントローラ、パーソナルコンピュータ、テレビジョンセットトップボックス、テレビジョン、ケーブルテレビジョン受像機、ならびにメディアコンテンツを受信し、提示するためのプログラム可能なプロセッサおよびメモリおよび回路を含む同様の個人用電子デバイスのうちのいずれか1つまたはすべてを指すように、本明細書では互換的に使用される。
【００１６】
本明細書では、マスタ交換サーバ、ウェブサーバ、メールサーバ、ドキュメントサーバ、または任意の他のタイプのサーバなど、コンテンツデータのプロバイダとして機能することが可能な任意のコンピューティングデバイスを指す「コンテンツサーバ」という用語を使用して、様々な実施形態について説明する。コンテンツサーバは、専用コンピューティングデバイスであっても、または(たとえば、コンピューティングデバイスをサーバとして動作させることができるアプリケーションを動作させる)サーバ構成要素を含むコンピューティングデバイスであってもよい。サーバ構成要素(たとえば、サーバアプリケーション)は、全機能を搭載したサーバ構成要素、または、モバイルデバイス上の動的データベースの間で同期サービスを提供するように構成されたライトサーバもしくは2次サーバ構成要素(たとえば、ライトサーバアプリケーションまたは2次サーバアプリケーション)であってもよい。ライトサーバまたは2次サーバは、受信機デバイス上に実装することができ、それによって、本明細書で説明する機能性を提供するのに必要な範囲でのみインターネットサーバとして受信機デバイスが機能することを可能にする、サーバタイプ機能のスリムダウンバージョンであってもよい。
【００１７】
一般的なコンテンツブロードキャスト配布方式では、受信デバイスのクライアントアプリケーションは、一般に、予想到着時間にメディアオブジェクト、バイト範囲、またはデータパケットを受信することを予期する。予想到着時間は、一般に、コンテンツデータに含まれる、もしくはコンテンツデータとともに送信されるメディアプレゼンテーション記述(MPD)または他のデータ記述に、または別個のシグナリングに反映され、コンテンツの適応ストリーミングのためにストリーミングメディアクライアントに情報を提供する。とりわけ、MPDは、プレゼンテーションタイムラインと「壁時計」(すなわち、ブロードキャスト手段またはユニキャスト手段によってストリーミングメディアクライアントにおいて確立される場合がある時間)の関係を記述してもよい。プレゼンテーションタイムラインと時間の関係は、同様に他の方法により確立されてもよい。
【００１８】
MPD(または、他の配信方法)で提供される予想到着時間とプレゼンテーションタイムラインの時間関係は、プレゼンテーションタイムラインを計算するために使用されてもよい。MPDで提供される時間関係は、とりわけ、受信デバイス内部の配布システムにおける遅延に関する1つまたは複数の仮定を反映してもよい。何らかの理由で、ブロードキャストシステムおよび受信機デバイスの予想された挙動よりも遅延が多いまたは少ない場合、受信デバイスのストリーミングメディアクライアントは、コンテンツデータのプレゼンテーションを起動または開始するのが早すぎるまたは遅すぎる場合がある。ストリーミングメディアクライアントがコンテンツを提示し始めるのが早すぎるとき、プレゼンテーション停止が生じる場合があり、コンテンツデータの提示が遅すぎると、コンテンツのプレゼンテーションを厳密に必要とされるよりも長く遅らせ、チャネル変更パフォーマンスを低下させる。
【００１９】
従来のコンテンツブロードキャスト配布方式におけるこれらの限界に対処するために、様々な実施形態のシステム、方法、およびデバイスが、受信機デバイスにおいて発生する場合があるプロトコルスタック遅延を決定し、これを補正することによって、受信機デバイスに対するメディアコンテンツの送信遅延を管理する。受信機デバイスは、送出デバイスからのコンテンツデータまたはコンテンツデータの部分の送信時間(放射時間)と、コンテンツデータが受信機デバイスのプロトコルスタックの部分から出てくる時間(「出現時間」)との間の時間オフセットを計算してもよい。計算された時間オフセットに基づいて、受信機デバイスは、コンテンツデータまたはコンテンツデータ部分の利用可能開始時間を決定してもよい。この計算された利用可能開始時間は、DASHクライアントアプリケーションがセグメントをレンダリングするためにDASHで使用される場合がある「セグメント利用可能開始時間」と近似している場合がある。いくつかの実施形態では、送信インフラストラクチャ(たとえば、コンテンツサーバ)は、決定された放射時間(すなわち、コンテンツデータ部分がコンテンツサーバによって送信される時間)をコンテンツデータまたはコンテンツデータ部分にラベル付けしてもよい。いくつかの実施形態では、放射時間は、提案される規格、Layered Coding Transport (LCT) Building Block、Request for Comments(RFC) 5651、<http://tools.ietf.org/html/rfc5651>、2009年10月に記載されているように、送出機現在時間(SCT:Sender Current Time)であってもよい。
【００２０】
様々な実施形態は、様々な通信システム100Aおよび100B内で動作する場合があるメディア受信機デバイスに実装されてもよく、その2つの例が図1Aおよび図1Bに示されている。図1Aを参照すると、受信機デバイス102は、基地局104と、アクセスポイント106と、コンテンツサーバ110とを含む場合がある通信ネットワーク108と通信する場合がある。基地局104は、ワイヤードまたはワイヤレス通信リンク114を通じて通信ネットワーク108と通信する場合があり、アクセスポイント106は、ワイヤードまたはワイヤレス通信リンク118を通じて通信ネットワーク108と通信する場合がある。通信リンク114および118は、光ファイバーバックホールリンク、マイクロ波バックホールリンク、および他の通信リンクを含む場合がある。いくつかの実施形態では、通信ネットワーク108は、携帯電話通信ネットワークを含む場合がある。
【００２１】
受信機デバイス102は、ワイヤレス通信リンク112を通じて基地局104と、ワイヤレス通信リンク116を通じてアクセスポイント106と通信する場合がある。いくつかの実施形態では、ワイヤレス通信リンク112は、ブロードキャスト送信またはマルチキャスト送信を含む場合があり、ワイヤレス通信リンク116は、ユニキャスト送信を含む場合がある。いくつかの実施形態では、ユニキャスト送信は、オプションであってもよい。コンテンツサーバ110は、アプリケーションサーバ、メディアサーバ、または、たとえば受信機デバイス102上のクライアントアプリケーション102aにコンテンツデータを提供するように構成された別のネットワークノードもしくはネットワーク要素であってもよい。コンテンツサーバ110は、ワイヤードまたはワイヤレス通信リンク120を通じて通信ネットワークと通信してもよい。受信機デバイス102は、通信ネットワーク108を通じてコンテンツサーバ110に、ビデオ、オーディオ、またはマルチメディアコンテンツなどのコンテンツデータの要求を送り、クライアントアプリケーション102aにコンテンツデータの配信を要求してもよい。応答して、コンテンツサーバ110は、1つまたは複数のワイヤードまたはワイヤレス通信リンク120を通じて、要求されたコンテンツデータを受信機デバイス102にストリーミングしてもよい。いくつかの実施形態では、受信機デバイス102は、単一のインターフェースを通じて(たとえば、セルラー通信インターフェースを通じて、またはWi-Fi通信インターフェースを通じて)、要求されたコンテンツデータを受信してもよい。いくつかの実施形態では、受信機デバイス102は、複数のインターフェースを通じて(たとえば、Wi-Fi通信インターフェースおよびセルラー通信インターフェースを通じて)コンテンツデータを受信してもよく、受信機デバイス102は、複数のネットワークインターフェースを通じて複数の並列ストリームを受信してもよい。
【００２２】
通信ネットワーク108は、1つまたは複数の無線アクセス技術を使用する通信をサポートしてもよく、ワイヤレス通信リンク112および116の各々は、1つまたは複数の無線アクセス技術を使用して双方向ワイヤレス通信リンクを介して行われる場合があるセルラー接続を含んでもよい。無線アクセス技術の例は、3GPPロングタームエボリューション(LTE)、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス(WiMAX)、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、広帯域CDMA(WCDMA(登録商標))、グローバルシステムフォーモビリティ(GSM(登録商標))、米国電気電子学会(IEEE)802.11プロトコルファミリ中の無線アクセスプロトコル(たとえば、Wi-Fi)、高度テレビジョンシステム委員会(ATSC:Advanced Television System Committee) 3.0、デジタルビデオ放送(DVB)-T2、および他の無線アクセス技術を含んでもよい。通信リンク112および116は、単一のリンクとして示しているが、通信リンクの各々は、複数の周波数または周波数帯域を含む場合があり、それらの各々が複数の論理チャネルを含む場合がある。
【００２３】
図1Bを参照すると、代替ネットワーク構成において、基地局104は、通信リンク112を通じて受信機デバイス122と通信してもよく、アクセスポイント124が、ワイヤードまたはワイヤレス通信リンク126を通じて受信機デバイス122と通信してもよい。受信機デバイス102は、ワイヤレス通信リンク128を通じてアクセスポイント124と通信してもよく、ワイヤレス通信リンク128は、マルチキャスト送信および/またはユニキャスト送信を含む場合がある。受信機デバイス122は、たとえば、基地局104を介してコンテンツサーバ110から、コンテンツデータを受信するように構成されてもよく、アクセスポイント124は、受信機デバイス122を介して受信されたコンテンツデータを受信機デバイスに送信するように構成されてもよい。したがって、コンテンツデータは、受信機デバイス122およびアクセスポイント124を介して、たとえば、Wi-Fiなどの近距離送信により、中間ホップ(intermediate hop)を通過する場合がある。そのような中間ホップをコンテンツデータが通過することは、「再配布」と呼ばれることがある。
【００２４】
図2は、様々な実施形態を実施するのに適した、ストリーミングメディアクライアント(たとえば、図1Aおよび図1Bのクライアントアプリケーション102a)のプロトコルスタック200を示す。図1A〜図2に関して、受信機デバイス(たとえば、受信機デバイス102)が、物理層(「PHY層」)204のコンテンツデータ202を受信する場合がある。PHY層は、受信機ローカル時間204a(たとえば、受信機「壁時計」時間)を確立してもよい。PHY層は、プロトコルスタック200の上位層に、「ティック」または他の情報マーケティングなど、ローカル時間の表示220を提供してもよい。受信機デバイスのプロセッサが、PHY層ティックから時間(たとえば、協定世界時(UTC))を導出してもよい。物理層は、時間表示(たとえば、UTC)で直接ラベル付けされてもよい。
【００２５】
コンテンツデータ202は、メディアプレゼンテーション記述(MPD)または他のメディア記述を含んでもよく、これは、コンテンツデータのヘッダ部分またはコンテンツデータの何らかの他の部分などにおいて、コンテンツデータに含まれてもよい。MPDは、クライアントアプリケーション(たとえば、クライアントアプリケーション102a)を実行している受信機デバイスのプロセッサが、コンテンツデータを処理し、レンダリングできるように、コンテンツデータに関する情報を記述してもよい。とりわけ、MPDは、プレゼンテーションタイムラインと壁時計(たとえば、PHY層204によって確立される場合がある時間)の関係を記述してもよい。MPDはまた、送出機によって仮定され、MPDに書き込まれる1つまたは複数の遅延時間などの、タイミング情報を含んでもよい。MPDはさらに、コンテンツデータの送出機からの送信時間または放射時間を含んでもよい。タイミング情報はまた、File Delivery over Unidirectional Transport(FLUTE)またはReal-Time Object over Unidirectional Transport(ROUTE)などのトランスポートプロトコルの拡張ヘッダに組み込まれてもよい。
【００２６】
物理層204は、媒体アクセス制御(MAC)層などのマシンアクセス制御層206にコンテンツデータを提供してもよい。MAC層206は、ネットワークトランスポートプロトコル(たとえば、インターネットプロトコル(IP)、ユーザデータグラムプロトコル(UDP)、または別の同様のネットワークトランスポートプロトコル)からのコンテンツデータを復号するために、IP/UDPスタックなどの、ネットワーキングプロトコル層208にコンテンツデータを提供してもよい。ネットワーキングプロトコル層208は、コンテンツデータをトランスポート層210(たとえば、前方誤り訂正(FEC)(たとえば、アプリケーション層(AL)-FEC)を含む場合があるファイル配信プロトコル層)に提供してもよい。トランスポート層210は、コンテンツデータをクライアントアプリケーション212に提供してもよく、クライアントアプリケーション212は、たとえば、国際標準化機構(ISO)ベースメディアファイルフォーマット(たとえば、BMFF)、またはムービングピクチャエキスパートグループ(MPEG)メディアトランスポート(MMT)フォーマットに従って、コンテンツデータの符号化を解釈してもよい。クライアントアプリケーション212は、復号およびレンダリングのためにコンテンツデータをコーディング/復号回路(CODEC)214に提供してもよい。
【００２７】
コンテンツデータは、たとえば、MAC層206および/または物理(PHY)層204内の遅延(たとえば、バッファ遅延または同様のデータ処理遅延)から生じる遅延218を伴ってトランスポート層210から出てくる。いくつかの実施形態では、遅延218はまた、クライアントデバイスが、コンテンツデータの何らかの不明の配布遅延をもたらす場合があるネットワークアダプタ(たとえば、受信機デバイス122)からデータを受信する(またはフェッチする)ときなどに、中間配布または再配布によってもたらされる遅延を含む場合がある。
【００２８】
遅延により、コンテンツデータの到着時間がMPD内のタイミング情報(たとえば、遅延時間)とは異なる場合がある。さらに、受信機デバイスによって物理層(PHY層204)から導出される時間は、比較的正確であり得るが、コンテンツデータがプロトコルスタックを通過するときもたらされるいかなる遅延も反映しない場合がある。遅延218は、コンテンツデータがプロトコルスタック200を通って移動するにつれて増殖する場合があり、コンテンツデータは、たとえば、MPD内の情報に基づいてクライアントアプリケーション212が予想し得るものとは異なる時間(すなわち、より遅い時間)にクライアントアプリケーション212に配信される結果となる場合がある。
【００２９】
プロトコルスタック遅延を決定するために、PHY層204は、ローカル時間(たとえば、受信機デバイスのローカル時間/壁時計時間204a)の表示220を提供してもよく、受信機デバイスのプロセッサはこれを、コンテンツデータの放射時間(すなわち、送信時間)と比較してもよい。データフィーチャ(たとえば、バイト範囲の最後のバイト)の放射時間と(物理層により確立される場合がある)受信機デバイスの壁時計時間との差が、プロトコルスタック200によってコンテンツデータを処理することによって引き起こされるプロトコルスタック遅延の量を示す可能性がある。したがって、受信機デバイスは、プロトコルスタック遅延を自己決定してもよい。
【００３０】
追加または代替として、受信機デバイスのプロセッサは、受信機デバイスのメモリに記憶される場合があるプロトコルスタック遅延値を再呼出し(recall)してもよい。たとえば、受信機デバイスは、受信機デバイスにおけるプロトコルスタックの特定の実装形態に対して決定されたプロトコルスタック遅延の所定の値で構成されてもよい。いくつかの実施形態では、所定のプロトコルスタック遅延値は、特定の受信機デバイスに実装された特定のプロトコルスタックのテストから導出されてもよい。所定のプロトコルスタック遅延値は、受信機デバイスのメモリに記憶されてもよく、受信機デバイスのプロセッサによって問合せおよび検索されてもよい。所定のプロトコルスタック遅延値は、たとえば、受信機デバイスに提供されてもよい、プロトコルスタックの改訂ビルドにおいて、更新されてもよい。
【００３１】
図3は、様々な実施形態とともに使用するのに適した通信システム300のブロック図である。様々な実施形態では、図3の要素は、図1A、図1B、および図2に関して説明したように、サーバ110または受信機デバイス102の要素と同様であってもよい。
【００３２】
図1A〜図3に関して、メディアエンコーダ302は、受信機デバイス(たとえば、受信機デバイス102)によって、または受信機デバイス上のクライアントアプリケーション(たとえば、クライアントアプリケーション102a)によって、要求された、または要求されることになるコンテンツデータ350を受信してもよい。メディアエンコーダ302は、コンテンツデータを符号化し、符号化したコンテンツデータ352をセグメンタ304に提供してもよい。セグメンタは、符号化されたコンテンツデータを1つまたは複数のセグメントに分割してもよい。セグメンタはまた、送出機現在時間(SCT)により、またはこれに従って、MPDを書き込んでもよい。MDPおよびコンテンツデータは、共通のセッション(たとえば、ROUTEセッション)により受信機デバイスに配信されてもよく、かつ/または共通のバイト範囲で配信されてもよいが、一般的には、MPDは、コンテンツデータに由来する一般的な別個のオブジェクト(たとえば、セグメント)にあってもよい。
【００３３】
セグメンタ304は、メディア認識バイト範囲356、および時間サービス品質(QoS)宛先IPを含む場合がある他の情報354を、送出機ネットワークプロトコル層306(たとえば、送出機IP/UDP)に提供してもよい。送出機ネットワークプロトコル層306は、ネットワークトランスポートプロトコル360を使用して符号化された(たとえば、IP、UDP、およびROUTEまたはFLUTEなどの別のネットワークトランスポートプロトコルを使用して符号化された)メディア認識バイト範囲、ならびに前方誤り訂正(FEC)フレームティック362を含む他の情報358を、カプセル化器(encapsulator)308に提供してもよい。カプセル化器308は、FECフレームティック362をスケジューラ310に提供してもよく、たとえば、汎用ストリームカプセル化器(GSE:generic stream encapsulator)プロトコルを使用してネットワークトランスポートのためにカプセル化されたメディア認識バイト範囲364を、ベースバンドコンポーザ312に提供してもよい。
【００３４】
スケジューラ310は、物理層割当て368をベースバンドコンポーザ312に提供してもよい。スケジューラはまた、コンテンツデータの送信時間(すなわち、放射時間)を決定してもよい。いくつかの実施形態では、送信時間は、コンテンツデータの最初のバイト、またはコンテンツデータの最後のバイトのいずれかにおいて定義されてもよい。送信時間は、送出機現在時間(SCT)であってもよい。いくつかの実施形態では、コンテンツデータの送信時間は、時間QoS情報354において与えられる最新の時間と一致してもよい。スケジューラ310はまた、レート適応情報366(たとえば、フィードバック情報)をメディアエンコーダ302に提供してもよい。いくつかの実施形態では、スケジューラ310は、送信の前にコンテンツデータをラベル付けするために使用される送信時間を決定してもよい。
【００３５】
ベースバンドコンポーザ312は、トランスポート370の準備ができているコンテンツデータ、ならびにコンテンツデータのベースバンド記述を送信機314に提供してもよい。送信機314は、コンテンツデータ372を受信機デバイスに送信してもよい。コンテンツデータ372の送信の直前に、または送信時に、送信機314は、コンテンツデータの一部分を送信時間(たとえば、送出機現在時間(SCT))でラベル付け(たとえば、符号化)してもよい。送信時間の値は、スケジューラ310によって与えられてもよく、スケジューラ310によって、または送出機306によって、符号化されてもよい。いくつかの実施形態では、送出機は、送信されるコンテンツデータのサイズがラベルの適用によって変えられないように、トランスポートを生成するとき、これらのフィールドを確立してもよい。
【００３６】
いくつかの実施形態では、送信時間は、コンテンツデータのヘッダに(または、セグメントなど、コンテンツデータの一部分のヘッダに)符号化されてもよい。いくつかの実施形態では、送信時間は、ROUTE EXT_TIMEヘッダ部分に符号化されてもよい。いくつかの実施形態では、ヘッダ時間が、コンテンツデータの一部分の(たとえば、セグメントの)最初のバイトとして定義されてもよい。いくつかの実施形態では、ヘッダ時間は、コンテンツデータの一部分の(たとえば、セグメントの)最後のバイトにおいて定義されてもよい。たとえば、セグメントの最後のバイトが、セグメントまたはバイト範囲(MDE)の放射時間に対応するSCTでラベル付け(たとえば、符号化)されてもよい。
【００３７】
受信機デバイスでは、プロトコルスタックの受信要素が、受信機デバイスでコンテンツデータを受信してもよい。受信要素は、物理層およびMAC層(たとえば、図2に関して説明したPHY層204およびMAC層206と同様であってもよい受信機PHY/MAC316)を含んでもよい。受信機PHY/MAC316は、送信時間でラベル付けされたメディア認識バイト範囲またはオブジェクト374を、受信機ネットワークプロトコル層318(たとえば、受信機IP/UDP)に提供してもよい。受信機ネットワークプロトコル層318は、コンテンツデータ378を、受信機デバイスプロトコルスタックにおける上位層に、および最終的にはクライアントアプリケーション(たとえば、クライアントアプリケーション102a)に提供してもよい。
【００３８】
受信機PHY/MAC316はまた、ローカルで導出される時間(たとえば、壁時計時間)376の表示を比較器380に提供してもよく、比較器380は、受信機デバイスのプロセッサによって実行される比較演算であってもよい。受信機ネットワークプロトコル層318は、コンテンツデータ放射時間384の表示(たとえば、EXT_TIMEラベル)を比較器380に提供してもよい。比較器380は、ローカルで導出される時間(たとえば、壁時計時間)およびコンテンツデータの放射時間を比較して、受信機デバイスのプロトコルスタックのプロトコルスタック遅延382を決定してもよい。たとえば、比較器380は、ローカルで導出される時間376がコンテンツデータ放射時間384の表示よりも大きいとき、プロトコルスタック遅延を決定してもよい。プロトコルスタック遅延382を使用して、受信機デバイスのプロセッサは、オフセット時間を決定してもよく、受信機デバイスのプロセッサはこれを使用して、決定されたプロトコルスタック遅延を補正してもよい。いくつかの実施形態では、受信デバイスのプロセッサは、受信機デバイスのローカル壁時計時間を調整してもよい。いくつかの実施形態では、受信デバイスのプロセッサは、決定されたオフセット時間に従って1つまたは複数のMPDパラメータを調整かつ/または書換えしてもよい。
【００３９】
追加または代替として、受信機デバイスのプロセッサは、受信機デバイスのメモリに記憶される場合があるプロトコルスタック遅延値を再呼出し(recall)してもよい。たとえば、受信機デバイスは、受信機デバイスにおけるプロトコルスタックの特定の実装形態に対して決定されたプロトコルスタック遅延の所定の値で構成されてもよい。いくつかの実施形態では、所定のプロトコルスタック遅延値は、特定の受信機デバイスに実装された特定のプロトコルスタックのテストから導出されてもよい。所定のプロトコルスタック遅延値は、受信機デバイスのメモリに記憶されてもよく、受信機デバイスのプロセッサによって問合せされてもよい。
【００４０】
図4Aは、様々な実施形態による、コンテンツデータの利用可能開始時間(たとえば、セグメント利用可能開始時間)を決定するために使用される場合がある値の間の関係400を示す。
【００４１】
図1A〜図4Aに関して、受信機デバイス(たとえば、受信機デバイス102)のプロセッサは、様々な時間値の間の関係に従ってコンテンツ利用可能開始時間408(たとえば、セグメント利用可能開始時間)を決定してもよい。様々な時間値の関係は、たとえば、コンテンツデータに含まれる、もしくはコンテンツデータとともに送信されるMPD、または別の同様のもしくは関係する記述において、定義されてもよい。
【００４２】
上記で説明したように、送出デバイスが、受信機デバイスに送られるコンテンツデータを、放射時間402(すなわち、送信時間)でラベル付けしてもよい。伝搬時間(flight time)412は、送出デバイスから受信デバイスまでのコンテンツデータの移動時間を表す。受信機デバイスは、たとえば、受信機デバイスにおけるプロトコルスタックの物理層(たとえば、PHY層204)から、受信機デバイスのローカル時間404(たとえば、壁時計時間)を決定してもよい。
【００４３】
コンテンツデータが受信機デバイスのプロトコルスタックによって処理されるにつれて、コンテンツデータは、受信機PHY/MAC遅延414、および/またはプロトコルスタックの最上部におけるコンテンツデータの到着時間406より前のプロトコルスタックの他の部分(たとえば、ROUTEもしくはFLUTEなど、トランスポート層210)による遅延416など、一定の遅延を受ける場合がある。受信機PHY/MAC遅延414およびプロトコルスタックの他の部分の遅延416の組合せは、実装形態固有の遅延418として表されてもよい。プロトコルスタックの最上部におけるコンテンツデータの到着時間406に続いて、サービス構築関係の遅延420が、コンテンツデータに課される場合もある。サービス構築関係の遅延420は、コンテンツデータの滑らかな再生を可能にするために、十分な量のコンテンツデータが受信機デバイスに到着し、バッファリングされることを可能にするための待ち時間を含んでもよい。コンテンツ利用可能開始時間408は、受信機壁時計時間404の後の静的時間量として決定されてもよい。受信機壁時計とコンテンツ利用可能開始時間との静的差422は、実装形態固有の遅延418とサービス構築関係の遅延420の和として決定されてもよい。
【００４４】
いくつかの実施形態では、実装形態固有の遅延418は、コンテンツデータの放射時間および受信機壁時計時間404を比較することによって、受信機デバイスのプロセッサによって決定されてもよい。追加または代替として、受信機デバイスのプロセッサは、受信機デバイスのメモリに記憶される場合がある所定のプロトコルスタック遅延値を再呼出ししてもよく、所定のプロトコルスタック遅延値を実装形態固有の遅延418として使用してもよい。
【００４５】
コンテンツ利用可能開始時間408を決定するには、受信機デバイスのプロセッサは、実施形態固有の遅延418、サービス構築関係の遅延420、および受信機壁時計とコンテンツ利用可能開始時間との静的差422のうちの少なくとも2つを、直接的または間接的に、受信してもよい。サービス構築関係の遅延420および/または受信機壁時計とコンテンツ利用可能開始時間との静的差422は、たとえば、コンテンツデータのMPDに含まれてもよい。実装形態固有の遅延418は、たとえば、コンテンツデータの放射時間と受信機壁時計時間404を比較することによって、または所定のプロトコルスタック遅延値を使用することによって、受信機デバイスのプロセッサによって決定されてもよい。
【００４６】
コンテンツ利用可能開始時間408に基づいて、コンテンツデータの配信またはフェッチ時間426が、受信機デバイスプロセッサによって決定されてもよい。コンテンツデータの配信またはフェッチ時間426は、コンテンツデータのレンダリング/再生モードに基づくものであってもよい。たとえば、プロトコルスタックのトランスポート層(たとえば、トランスポート層210)が、コンテンツデータのバイト範囲またはメディア配信イベント(MDE)をクライアントアプリケーション(たとえば、クライアントアプリケーション212)に提供している(すなわち、配信している)場合、クライアントアプリケーションは、一般的に、コンテンツデータのバイト範囲をレンダリングし始めるのに、コンテンツ利用可能開始時間を待つ必要がない。受信機デバイスのプロセッサは、@tbdByteRangeOffsetTime430などの、バイト範囲オフセット値を適用することによって、バイト範囲配信時間424を決定してもよい。プロトコルスタックのトランスポート層がコンテンツデータのセグメントをクライアントアプリケーションに配信している場合、受信機デバイスのプロセッサは、クライアントアプリケーションがコンテンツ部分(たとえば、セグメント)をフェッチする(たとえば、バッファからの要求)ためのコンテンツ部分配信/フェッチ時間426として、コンテンツ利用可能開始時間408を使用してもよい。
【００４７】
いくつかの実施形態では、複数のクライアントアプリケーション/受信デバイスがコンテンツデータを実質的に同時にレンダリングするように、複数のクライアントアプリケーションまたは複数の受信デバイスが、同期を必要とする場合、受信機デバイスのプロセッサは、ストリーミングメディアクライアントごとにマルチデバイス同期セグメントレベルフェッチ時間428を決定するために、@suggestedPresentationDelay433などの、さらなる遅延を追加してもよい。
【００４８】
代替的に、バイト範囲配信時間424は、トランスポート層(たとえば、トランスポート層210)がMDEまたはバイト範囲をストリーミングメディアクライアント(たとえば、クライアントアプリケーション212)に配信し得る時間を含んでもよい。
【００４９】
バイト範囲配信時間424を決定するために、プロセッサは、MDE表現アクセスポイント(RAP:representation access point)配信のためのサービス構築関係の遅延などの、サービス構築遅延432を決定してもよい。いくつかの実施形態では、トランスポート層は、RAPをマーク付けされたMDEまたはバイト範囲を送るだけでよく、これは、バイト範囲またはMDEがストリーミングメディアクライアントによって生産的に処理され得る構文表示であってもよい。
【００５０】
図4Bは、様々な実施形態による受信機デバイスにおけるメディアコンテンツの開始時間を管理するための方法400Aにおける通信を示すコールフロー図である。方法400Aのコールフローは、ワイヤレス受信機デバイス(たとえば、図1のワイヤレス受信機デバイス102)のプロセッサによって実施されてもよい。
【００５１】
アプリケーション448が、コンテンツデータのサービス要求460をサービス層446に送ってもよく、サービス層446は、IPフローの要求462を、受信機デバイスのプロトコルスタックの物理層およびMAC層(たとえば、PHY/MAC440)に送ってもよい。物理層およびMAC層440は、コンテンツデータの受信を開始してもよく、IPデータグラム464などのコンテンツデータを、プロトコルスタックを上ってトランスポート層442に配信してもよい。トランスポート層442は、コンテンツデータに関連する1つまたは複数の初期化セグメント(IS)およびMPD(たとえば、ISおよびMPD466)をポスティングする(たとえば、利用可能にする)場合がある。ストリーミングメディアクライアント(たとえば、メディアデータイベント(MDE)クライアント444)が、トランスポート層によって利用可能にされる初期化セグメントおよびMPDをフェッチ468してもよい。
【００５２】
トランスポート層442は、コンテンツデータの要求(たとえば、第1のメディアセグメントの要求470)を受信してもよく、コンテンツデータの要求470を、できる限り早い時間にバイト範囲またはMDE(メディア配信イベント)を送る要求として解釈してもよく、その決定について以下で説明する。コンテンツデータ470の要求に応答して、トランスポート層442は、要求の肯定応答(たとえば、OK(200)応答472)をストリーミングメディアクライアント444に送ってもよい。トランスポート層442は、次いで、決定された配信時間(たとえば、バイト範囲配信時間424)に、ストリーミングメディアクライアント444にバイト範囲またはMDEを送ってもよい。
【００５３】
バイト範囲またはMDEがトランスポート層442からストリーミングメディアクライアント444に送られてもよい時間を決定するために、受信機デバイスのプロセッサが、メディアのバイト範囲またはMDEごとのサービス構築関係の遅延(たとえば、MDE RAP配信に対するサービス構築関係の遅延432)を計算してもよい。たとえば、コンテンツデータは、2つの時間表示を含んでもよい。第1の時間表示は、バイト範囲またはMDEの送信時間(すなわち、放射時間)の表示であってもよく、これはROUTE EXT_TIMEヘッダ部分に符号化されてもよい。第2の時間表示は、トランスポート層プレゼンテーション時間であってもよく、これは、ROUTE EXT_ROUTE_PRESENTATION_TIMEヘッダ部分に符号化されてもよい、コンテンツデータの送信時間と、バイト範囲またはMDEに固有のサービス関係の遅延の表示である。
【００５４】
いくつかの実施形態では、プロセッサは、バイト範囲またはMDEに固有のサービス関係の遅延(たとえば、MDE RAP配信に対するサービス構築関係の遅延432)を決定するために、第2の時間表示から第1の時間表示を減算してもよい(たとえば、プロセッサは、トランスポート層プレゼンテーション時間(EXT_ROUTE_PRESENTATION_TIME)値からEXT_TIME値を減算してもよい)。
【００５５】
トランスポート層がバイト範囲またはMDEをストリーミングメディアクライアントに送ってもよい時間(たとえば、バイト範囲またはMDEに固有のバイト範囲配信時間424)を決定するために、プロセッサは、実装形態固有の遅延(実装形態固有の遅延418、たとえば、総合的なプロトコルスタック遅延など)、およびバイト範囲またはMDEに固有のサービス関係の遅延を加えてもよい。このようにして、プロセッサは、トランスポート層がMDEまたはバイト範囲をストリーミングメディアクライアントに配信してもよい時間を決定してもよく、時間は、特定のMDEまたはバイト範囲のEXT_TIMEに比例してもよい。
【００５６】
代替または追加として、プロセッサは、バイト範囲/MDE配信時間を計算するために、実装形態固有の遅延(たとえば、実装形態固有の遅延418または総合的なプロトコルスタック遅延)およびトランスポート層プレゼンテーション時間(EXT_ROUTE_PRESENTATION_TIME)値を追加してもよい。
【００５７】
決定されたバイト範囲配信時間を使用して、トランスポート層442は、バイト範囲またはMDE474をストリーミングメディアクライアントに送ってもよい。ストリーミングメディアクライアントは、初期同期圧縮メディア476として、バイト範囲/MDE474をCODEC450(たとえば、CODEC214)に提供してもよい。CODEC450は、初期同期圧縮メディア476(たとえば、バイト範囲またはMDE)を処理してもよく、そのように処理されたコンテンツデータ(たとえば、初期同期非圧縮メディア478)をプレゼンテーション層452に提供してもよい。
【００５８】
図5は、様々な実施形態による受信機デバイスに対するメディアコンテンツの送信遅延を管理するための方法500を示す。方法500は、受信機デバイス(たとえば、図1のワイヤレス受信機デバイス102)のプロセッサによって実施されてもよい。
【００５９】
ブロック502において、送出デバイス(たとえば、コンテンツサーバ110)が、放射(たとえば、送信)時間でコンテンツデータをラベル付けしてもよく、ブロック504において、送出デバイスは、時間表示で物理デバイスをマーク付けしてもよい(たとえば、受信機デバイスがローカル時間/壁時計時間を確立できるように物理層ティックまたは他の時間表示を提供してもよい)。放射時間でのコンテンツデータのラベル付けは、送出デバイスのプロトコルスタックのトランスポート層によって実行されてもよく、時間表示での物理層のマーク付けは、送出デバイスまたは送出機のプロトコルスタックの物理層によって実行されてもよい。送出デバイスは、次いで、受信機デバイスの定義された送信および受信スタックを介して、ラベル付けされたコンテンツデータを受信デバイス(たとえば、受信機デバイス102)に送ってもよい。
【００６０】
ブロック506において、受信機デバイスは、たとえば、受信機デバイスのプロトコルスタックの物理層(たとえば、PHY層204)において、放射時間でラベル付けされたコンテンツデータを受信してもよい。ブロック508において、受信機デバイスは、プロトコルスタックの物理層によって時間の表示を受信してもよい。
【００６１】
ブロック510において、受信機デバイスのプロセッサが、プロトコルスタック受信機デバイスにおいて、受信されたコンテンツデータを処理してもよい。ブロック512において、受信表示デバイスのプロセッサは、たとえば、プロトコルスタックの物理層によって提供される情報から、受信機デバイスのローカル時間(たとえば、ローカル壁時計または受信機壁時計)を確立してもよい。いくつかの実施形態では、受信機デバイスのプロトコルスタックの物理層は、送出デバイスからの時間表示の物理層マーク付けに基づいて、受信機デバイスのローカル時間を確立してもよい。
【００６２】
ブロック514において、受信機デバイスのプロセッサは、コンテンツデータラベルから放射時間を検索してもよい。
【００６３】
ブロック516において、プロセッサは、検索された放射時間を、受信機デバイスの確立されたローカル時間と比較してもよく、比較に基づいてプロトコルスタック遅延を決定してもよい。
【００６４】
ブロック518において、プロセッサは、検索された放射時間を受信機デバイスの確立されたローカル時間と比較することに基づいて、時間オフセットを決定してもよい。いくつかの実施形態では、プロセッサは、決定された時間オフセットに基づいてタイマーを生成してもよい。プロセッサは、ストリーミングメディアクライアントにメディアコンテンツを配信するための時間を決定するために、決定されたタイマーを使用してもよい。
【００６５】
オプションのブロック520において、プロセッサは、決定された時間オフセットを使用して、コンテンツデータのMPDの1つまたは複数の値を変更してもよい。オプションのブロック522において、プロセッサは、決定された時間オフセットを使用して、受信機デバイスのローカル時間を調整してもよい。
【００６６】
ブロック524において、プロセッサは、ストリーミングメディアクライアント(たとえば、クライアントアプリケーション212およびストリーミングメディアクライアント444)がバイト範囲またはMDEを要求していると決定する場合がある。たとえば、プロトコルスタックのトランスポート層(たとえば、トランスポート層210およびトランスポート層442)が、コンテンツデータの要求を、できる限り早い時間にバイト範囲またはMDEを送る要求として解釈する場合がある。
【００６７】
ブロック526において、プロセッサは、トランスポート層がストリーミングメディアクライアントにMDEまたはバイト範囲を配信してもよい時間などの、バイト範囲配信時間(たとえば、バイト範囲配信時間424)を決定してもよい。いくつかの実施形態では、プロセッサは、実装形態固有の遅延(たとえば、総合的なプロトコルスタック遅延である場合がある、実装形態固有の遅延418)、およびバイト範囲またはMDEに固有のサービス関係の遅延(たとえば、MDE RAP配信に対するサービス構築関係の遅延432)を加算することによって、バイト範囲配信時間を決定してもよい。代替または追加として、プロセッサは、実装形態固有の遅延(すなわち、実装形態固有の遅延418)およびトランスポート層プレゼンテーション時間(EXT_ROUTE_PRESENTATION_TIME)値を加算することによって、バイト範囲/MDE配信時間を計算してもよい。
【００６８】
ブロック528において、プロセッサは、バイト範囲配信時間を使用して、バイト範囲またはMDEをストリーミングメディアクライアントに配信してもよい。たとえば、バイト範囲配信時間を使用して、プロセッサは、コンテンツデータ(たとえば、バイト範囲またはMDE)を、バイト範囲/MDEをストリーミングする、クライアントアプリケーションのインターフェース(たとえば、ROUTE/DASHインターフェース)に配信してもよい。いくつかの実施形態では、プロセッサは、決定された時間オフセットに基づいて生成されたタイマーが満了したと決定してもよい。そのような実施形態では、プロセッサは、タイマーの満了に応答して(たとえば、タイマーが満了したと決定することに応答して)メディアコンテンツをストリーミングメディアクライアントに配信してもよい。
【００６９】
様々な実施形態は、様々な受信機デバイスのいずれにも実装される場合があり、その一例が図6に示される。たとえば、受信機デバイス600は、内部メモリ604および606に結合されたプロセッサ602を含む場合がある。内部メモリ604および606は、揮発性メモリまたは不揮発性メモリであってもよく、また、セキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、またはそれらの任意の組合せであってもよい。プロセッサ602はまた、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンディスプレイ612に結合される場合もある。加えて、受信機デバイス600のディスプレイは、タッチスクリーン機能を有する必要はない。受信機デバイス600は、互いに結合され、かつ/またはプロセッサ602に結合された、送受信のための、1つまたは複数の無線信号トランシーバ608(たとえば、Peanut(登録商標)、Bluetooth(登録商標)、Zigbee(登録商標)、Wi-Fi、無線周波数(RF)無線)、およびアンテナ610を有する場合がある。受信機デバイス600は、セルラーデータネットワーク(たとえば、CDMA、TDMA、GSM(登録商標)、PCS、3G、4G、LTE、ATSC 3.0、DVB-T2、または任意の他のタイプのセルラーもしくはブロードキャストデータネットワーク)を介した通信を可能にし、かつプロセッサ602に結合された、ワイヤレスモデムチップ616などのセルラーネットワークインターフェースを含む場合がある。受信機デバイス600は、プロセッサ602に結合された周辺デバイス接続インターフェース618を含む場合がある。周辺デバイス接続インターフェース618は、1つのタイプの接続を受け入れるように単独で構成される場合があり、またはUSB、FireWire、ThunderboltもしくはPCIeなどの様々なタイプの物理接続および通信接続を一般的な接続もしくは専用の接続として受け入れるように複合的に構成される場合がある。周辺デバイス接続インターフェース618は、同様に構成された周辺デバイス接続ポートに結合される場合もある。受信機デバイス600は、オーディオ出力を提供するためのスピーカ614を含む場合もある。受信機デバイス600は、プラスチック、金属または材料の組合せで構築された、本明細書において説明する構成要素のすべて、またはいくつかを収容するためのハウジング620を含む場合もある。受信機デバイス600は、使い捨てまたは充電可能なバッテリなどの、プロセッサ602に結合された電源622を含む場合がある。充電可能なバッテリは、受信機デバイス600の外部にある電源から充電電流を受けるために、周辺デバイス接続ポートに結合される場合もある。受信機デバイス600はまた、ユーザ入力を受信するための物理ボタン624と、受信機デバイス600をオンおよびオフにするための電源ボタン626とを含む場合もある。
【００７０】
様々な実施形態はまた、図7に示すサーバ700などの、様々な市販のサーバデバイスのいずれにも実装される場合がある。そのようなサーバ700は通常、揮発性メモリ702と、ディスクドライブ704のような大容量の不揮発性メモリとに結合された、プロセッサ701を含む。サーバ700はまた、プロセッサ701に結合された、フロッピー(登録商標)ディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ706を含む場合がある。サーバ700はまた、他のブロードキャストシステムコンピュータおよびサーバに結合されたローカルエリアネットワーク、インターネット、公衆交換電話網、ならびに/またはセルラーデータネットワーク(たとえば、CDMA、TDMA、GSM(登録商標)、PCS、3G、4G、LTE、もしくは任意の他のタイプのセルラーデータネットワーク)など、ネットワーク707とのネットワークインターフェース接続を確立するための、プロセッサ701に結合されたネットワークアクセスポート703を含む場合がある。
【００７１】
プロセッサ602および701は、上記で説明した様々な実施形態の機能を含む、様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成される場合がある、任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであってもよい。いくつかのデバイスでは、ワイヤレス通信機能専用の1つのプロセッサ、および他のアプリケーションの実行専用の1つのプロセッサなどの複数のプロセッサが設けられてもよい。一般的には、ソフトウェアアプリケーションは、それらがアクセスされ、プロセッサ602および701にロードされる前に、内部メモリ604、606、702、704に記憶される場合がある。プロセッサ602および701は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含んでもよい。多くのデバイスにおいて、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、または両方の混合物であってもよい。本明細書では、メモリへの一般的な言及は、内部メモリまたはデバイスに差し込まれるリムーバブルメモリと、プロセッサ602および701自体の中のメモリとを含む、プロセッサ602および701によってアクセス可能なメモリを指す。
【００７２】
上記の方法の説明およびプロセスフロー図は、単に説明のための例として提供され、様々な実施形態の動作が提示された順序で実施されなければならないことを要求または暗示することを意図しない。当業者によって諒解されるように、上記の実施形態における動作の順序は、任意の順序で実施されてもよい。「その後」、「次いで」、「次に」などの言葉は、動作の順序を限定するものではなく、これらの言葉は単に、読者に本方法の説明を案内するために使用される。さらに、たとえば冠詞「a」、「an」、または「the」を使用する、請求項の要素に対する単数形でのいかなる参照も、要素を単数形に限定すると解釈されるべきではない。
【００７３】
本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、構成要素、回路、およびアルゴリズム動作は、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装される場合がある。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的なコンポーネント、ブロック、構成要素、回路、および動作について、上記では概してそれらの機能に関して説明した。そのような機能がハードウェアとして実装されるか、ソフトウェアとして実装されるかは、特定の用途およびシステム全体に課される設計制約によって決まる。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装する場合があるが、そのような実装決定は、特許請求の範囲からの逸脱を引き起こすものとして解釈されるべきではない。
【００７４】
本明細書で開示した実施形態に関して説明した様々な例示的な論理、論理ブロック、構成要素、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行されてもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ(たとえば、DSPとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成)として実装される場合もある。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実施されてもよい。
【００７５】
1つまたは複数の実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装されてもよい。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読記憶媒体または非一時的プロセッサ可読記憶媒体上に1つまたは複数の命令またはコードとして記憶されてもよい。本明細書で開示する方法またはアルゴリズムのステップは、非一時的コンピュータ可読記憶媒体または非一時的プロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェア構成要素において具現化されてもよい。非一時的コンピュータ可読またはプロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされる場合がある任意の記憶媒体であってよい。限定ではなく例として、そのような非一時的コンピュータ可読またはプロセッサ可読媒体は、RAM、ROM、EEPROM、FLASHメモリ、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用される場合があり、コンピュータによってアクセスされる場合がある任意の他の媒体を含んでもよい。本明細書で使用される時に、ディスク(diskおよびdisc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)、およびブルーレイディスク(disc)を含み、diskは、通常、データを磁気的に再生するが、discは、レーザを用いて光学的にデータを再生する。上記の組合せも、非一時的コンピュータ可読およびプロセッサ可読媒体の範囲内に含まれる。加えて、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれる場合がある、非一時的プロセッサ可読媒体および/または非一時的コンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せまたはセットとして存在する場合がある。
【００７６】
開示された実施形態の先行する説明は、当業者が特許請求の範囲を製作または使用することを可能にするために提供される。これらの実施形態への様々な修正は当業者には容易に明らかになり、本明細書で定義する一般原理は、特許請求の範囲から逸脱することなく他の実施形態に適用されてよい。したがって、特許請求の範囲は、本明細書に示す実施形態に限定されることを意図しておらず、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。
【符号の説明】
【００７７】
100  通信システム
102  受信機デバイス
102a  クライアントアプリケーション
104  基地局
106  アクセスポイント
108  通信ネットワーク
110  コンテンツサーバ
112  ワイヤレス通信リンク
114  ワイヤードまたはワイヤレス通信リンク
116  ワイヤレス通信リンク
118  ワイヤードまたはワイヤレス通信リンク
120  ワイヤードまたはワイヤレス通信リンク
122  受信機デバイス
124  アクセスポイント
126  ワイヤードまたはワイヤレス通信リンク
128  ワイヤレス通信リンク
200  プロトコルスタック
202  コンテンツデータ
204  物理(PHY)層
204a  受信機ローカル時間
206  マシンアクセス制御層、媒体アクセス制御(MAC)層
208  ネットワーキングプロトコル層
210  トランスポート層
212  クライアントアプリケーション
214  コーディング/復号回路(CODEC)
218  遅延
220  ローカル時間の表示、表示
300  通信システム
302  メディアエンコーダ
304  セグメンタ
306  送出機ネットワークプロトコル層
308  カプセル化器
310  スケジューラ
312  ベースバンドコンポーザ
314  送信機
316  受信機PHY/MAC
318  受信機ネットワークプロトコル層
350  コンテンツデータ
352  符号化したコンテンツデータ
354  他の情報
356  メディア認識バイト範囲
358  他の情報
360  ネットワークトランスポートプロトコル
362  前方誤り訂正(FEC)フレームティック
364  メディア認識バイト範囲
366  レート適応情報
368  物理層割当て
370  トランスポート
372  コンテンツデータ
374  メディア認識バイト範囲またはオブジェクト
376  ローカルで導出される時間
378  コンテンツデータ
380  比較器
382  プロトコルスタック遅延
384  コンテンツデータ放射時間
400  関係
400A  方法
402  放射時間
404  ローカル時間、受信機壁時計時間
406  到着時間
408  コンテンツ利用可能開始時間
412  伝播時間
414  受信機PHY/MAC遅延
416  プロトコルスタックの他の部分による遅延
418  実装形態固有の遅延
420  サービス構築関係の遅延
422  受信機壁時計時間とコンテンツ利用可能開始時間との静的差
424  バイト範囲配信時間
426  フェッチ時間
428  マルチデバイス同期セグメントレベルフェッチ時間
430  @tbdByteRangeOffsetTime.
432  サービス構築遅延
433  @suggestedPresentationDelay
440  物理層およびMAC層
442  トランスポート層
444  ストリーミングメディアクライアント
446  サービス層
448  アプリケーション
450  CODEC
460  サービス要求
462  要求
464  IPデータグラム
466  初期化セグメント(IS)およびMPD
468  フェッチ
470  コンテンツデータの要求
472  OK(200)応答
474  バイト範囲またはMDE
476  初期同期圧縮メディア
478  初期同期非圧縮メディア
500  方法
600  受信機デバイス
602  プロセッサ
604  内部メモリ
606  内部メモリ
608  無線信号トランシーバ
610  アンテナ
612  タッチスクリーンディスプレイ
614  スピーカ
616  ワイヤレスモデムチップ
618  周辺デバイス接続インターフェース
620  ハウジング
622  電源
624  物理ボタン
626  電源ボタン
700  サーバ
701  プロセッサ
702  内部メモリ
703  ネットワークアクセスポート
704  内部メモリ
706  DVDディスクドライブ
707  ネットワーク
【図１Ａ】
0006731937.tif 000002
【図１Ｂ】
0006731937.tif 000003
【図２】
0006731937.tif 000004
【図３】
0006731937.tif 000005
【図４Ａ】
0006731937.tif 000006
【図４Ｂ】
0006731937.tif 000007
【図５】
0006731937.tif 000008
【図６】
0006731937.tif 000009
【図７】
0006731937.tif 000010