JP2016506682A - デバイスのタイミング調整およびブロードキャストを通じてｄａｓｈをサポートするための方法 - Google Patents

Abstract

様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが、セグメントが受信機デバイス上で利用可能になる実際の時間に基づいて、セグメントに対する要求のタイミングを調整することを可能にする。様々な実施形態において、受信機デバイスは、セグメント利用可能性タイムラインを調整することが可能にされてよく、セグメント利用可能性タイムラインにおいて、セグメントが受信機デバイス上で利用可能になる実際の時間を与えるようにセグメントの利用可能時間が調整される。

Description

関連出願
本出願は、2012年12月28日に出願された「Device Timing Adjustments and Method for Supporting DASH Over Broadcast」という表題の米国仮特許出願第61/747,188号の優先権の利益を主張し、この仮特許出願の内容全体が参照によって本明細書に組み込まれる。

ハイパーテキスト転送プロトコル(HTTP)ストリーミングは現在、インターネットを通じてコンテンツを配信する最も一般的な方法である。生放送のイベントでは、コンテンツは、不変の期間のセグメントを通じて徐々に利用可能にされる。セグメントの利用可能性(segment availability)は、各々の連続するセグメントがHTTPサーバにおいていつ利用可能になるかを示す、タイムラインに従う。

Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)は、HTTPストリーミングを実装する規格である。DASHは、Media Presentation Description(MPD)においてセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。

現在のシステムでは、MPDは、Over-the-Air(OTA)配信を介して受信機デバイスに提供される。提供されたMPDにおいて、セグメント利用可能時間は、セグメントを生成するネットワーク側エンコーダのエンコーダ出力時間に対応し得る。セグメント利用可能時間はエンコーダ出力時間に対応し得るので、利用可能時間は、配信経路の遅延、受信機デバイスの処理遅延、または受信機デバイスの時計のずれのような、受信機デバイス上で実行されるDASHクライアントに対する、実際のセグメントの利用可能性の差を考慮しない可能性がある。したがって、現在のMPDにおいて告知される利用可能時間は、セグメントがDASHクライアントに対して利用可能となる実際の時間に対応しないことがある。

様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが修正されたセグメント利用可能時間を使用することを可能にする。様々な実施形態において、受信機デバイスは、セグメントが受信機デバイス上で利用可能になる実際の時間に基づいて、セグメントに対する要求のタイミングを調整することが可能にされ得る。様々な実施形態において、受信機デバイスは、セグメント利用可能性タイムラインを調整することが可能にされてよく、セグメント利用可能性タイムラインにおいて、セグメントが受信機デバイス上で利用可能になる実際の時間を与えるようにセグメントの利用可能時間が調整される。様々な実施形態において、セグメント利用可能時間の調整は、受信機デバイスのサービスレイヤにおいて行われ得る。様々な実施形態において、セグメント利用可能時間の調整は、受信機デバイス上のクライアントアプリケーションによって行われ得る。様々な実施形態において、ネットワーク遅延ジッタの推定が提供され得る。ある実施形態では、ネットワーク遅延ジッタの推定は、セグメント利用可能性タイムラインにおいて提供され得る。

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

様々な実施形態とともに使用するのに適したネットワークの通信システムブロック図である。 ある実施形態による、受信機デバイスのアーキテクチャを示すブロック図である。 ある実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。 別の実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。 ある実施形態による、セグメント利用可能時間を示す図である。 セグメント利用可能性タイムラインを修正するためのある実施形態の方法を示すプロセスフロー図である。 遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 セグメント利用可能性タイムラインを修正するための別の実施形態の方法を示すプロセスフロー図である。 遅延調整メッセージを生成するための別の実施形態の方法を示すプロセスフロー図である。 セグメント利用可能性タイムラインを修正するための別の実施形態の方法を示すプロセスフロー図である。 遅延調整メッセージを生成するための別の実施形態の方法を示すプロセスフロー図である。 セグメント利用可能性タイムラインを修正するための別の実施形態の方法を示すプロセスフロー図である。 遅延調整メッセージを生成するための別の実施形態の方法を示すプロセスフロー図である。 ある実施形態による、試験システム中の第1のセグメントの到達時間の、最悪の場合の遅延および変動性のグラフである。 第1のセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 第1のセグメントの復号時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 ビデオセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 ビデオセグメントの復号時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 セグメント受信時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 セグメント受信時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 セグメント復号完了時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 セグメント復号完了時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 オーディオセグメントおよびビデオセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 オーディオセグメントおよびビデオセグメントの復号時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 別の実施形態による、試験システム中の第1のセグメントの到達時間の、最悪の場合の遅延および変動性のグラフである。 FDT受信時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法を示すプロセスフロー図である。 FDT受信時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法を示すプロセスフロー図である。 MPDにネットワークジッタの推定を含めるためのある実施形態の方法を示すプロセスフロー図である。 MPDとは独立にネットワークジッタの推定を提供するためのある実施形態の方法を示すプロセスフロー図である。 遅延調整メッセージに基づいて利用可能時間を調整するためのある実施形態の方法を示すプロセスフロー図である。 ある実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。 別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。 第3の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。 様々な実施形態とともに使用するのに適した例示的なモバイルデバイスのコンポーネント図である。 様々な実施形態とともに使用するのに適した例示的なサーバのコンポーネント図である。

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

「例示的」という用語は、「例、事例、または例示として機能する」ことを意味するように本明細書において使用される。本明細書で「例示的」として説明されるいずれの実装形態も、他の実装形態より好ましい、または有利であると、必ずしも解釈されるべきではない。

本明細書で使用される場合、「モバイルデバイス」および「受信機デバイス」という用語は、携帯電話、スマートフォン、個人用マルチメディアプレーヤーまたはモバイルマルチメディアプレーヤー、携帯情報端末(PDA)、ラップトップコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応携帯電話、ワイヤレスゲームコントローラ、および、MPDを受信しMPDをDASHクライアントに対して利用可能にするためのプログラム可能プロセッサとメモリと回路とを含む同様の個人用電子デバイスの、いずれか1つまたはすべてを指すように、本明細書において交換可能に使用される。

Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)は、HTTPストリーミングを実装する規格である。DASHは、Media Presentation Description(MPD)においてセグメントの利用可能性(segment availability)を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。現在のシステムでは、MPDは、Over-the-Air(OTA)配信を介して受信機デバイスに提供される。第3世代パートナーシッププロジェクト(3GPP)は、Long Term Evolution(LTE)(すなわち、evolved Multimedia Broadcast Multicast Services(eMBMS))を通じたブロードキャスト使用してHTTPストリーミングを提供するために使用されるべき方法として、ダウンロード配信を通じたDASHを標準化した。

異なるアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルの様々な例、特に、DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPが本明細書で論じられる。DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPの議論は、様々な実施形態の態様をより良好に示すための例としてのみ与えられ、いかなる方法でも様々な実施形態を限定することは意図されない。他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、様々な実施形態とともに使用されてよく、他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、本発明の趣旨または範囲から逸脱することなく、様々な例において置換されてよい。

様々な実施形態は、受信機デバイス上での使用のために、データストリーム中のデータセグメントの利用可能性(「セグメント利用可能性(segment availability)」)の遅延を、受信機デバイスが考慮することを可能にする。ある実施形態では、受信機デバイスは、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDのリストを生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)サーバからOTAで受信されるMPD)中の利用可能時間を調整することができる。様々な実施形態は、ネットワークおよび受信機デバイスの時計が同期されているときまたは同期されていないときに、修正されたMPDが生成されることを可能にし得る。

ある実施形態では、受信機デバイスは、受信機デバイス上のクライアントアプリケーションに対するセグメントの利用可能性の遅延を考慮するように、遅延調整を決定することができる。ある実施形態では、遅延調整は遅延調整メッセージにおいて提供され得る。遅延調整メッセージは、遅延調整を含むファイルのような、遅延調整のパラメータおよび/または指示であり得る。ある実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDのリストを生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)サーバからOTAで受信されるMPD)中の利用可能時間を調整することを可能にし得る。様々な実施形態は、ネットワークおよび受信機デバイスの時計が同期されているときまたは同期されていないときに、遅延調整メッセージおよび修正されたMPDが生成されることを可能にし得る。別の実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、セグメント利用可能性タイムライン自体を修正することなく、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤーアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて、セグメントに対する要求のタイミングを調整することを可能にし得る。

ある実施形態では、ネットワークジッタの推定(たとえば、ネットワークジッタ値)は、受信機デバイスに送信されるセグメント利用可能性タイムライン(たとえば、MPD)を記述するマニフェストファイル中で提供され得る。別の実施形態では、ネットワークジッタは、受信機デバイス上で事前に準備され得る(たとえば、製造の時点で受信機デバイスの非揮発性メモリに記憶され得る)。他の実施形態では、ネットワークジッタの推定は、任意のメッセージ中で、たとえばサービス告知の中で、受信機デバイスに配信され得る。ある実施形態では、ネットワークジッタの推定は、その中でMPDが配信され得るメッセージとは無関係なメッセージで受信機デバイスに配信され得る。本明細書で使用される場合、「ジッタ」は、セグメントの利用可能性タイムラインからの差として、セグメントの最早の可能な到達時間と最遅の可能な到達時間との差を指す。

本明細書で使用される場合、「ネットワークジッタ」は、受信機デバイスにおけるセグメントの最早の相対到達時間と最遅の相対到達時間との最大の差を指す。相対到達時間は、配信タイムラインに従った、絶対到達時間と予想される到達時間との差を指す。ある実施形態では、配信タイムラインは、サービスのメディアを搬送するセグメントのリスト中の、すべてのセグメントの予想される到達時間を提供することができ、配信タイムラインは、次のセグメントの利用可能性が、先行するセグメントの利用可能性に、第1のセグメントの提供された絶対利用可能時間に基づく先行するセグメントの期間を足したものとなり得るように、定義され得る。別の実施形態では、利用可能時間は、連続するセグメントに対する絶対値として提供され得る。さらに別の実施形態では、利用可能時間は、周期内での周期的な利用可能性として提供され得る。さらなる実施形態では、利用可能時間は、絶対値と周期利用可能性の組合せのような、仕組みの組合せとして提供され得る。ネットワークジッタは、セグメントサイズの変動性、スケジューリング期間の粒度の変動性(たとえば、セグメントの到達の1秒の周期性を中心とする、320msというマルチキャストチャネル(MCH)スケジューリング周期の変動性)、ネットワーク装置の遅延(たとえば、帯域幅、送信遅延、処理遅延、バッファ遅延など)の変動性に関連し得る。ネットワークジッタは、状況に依存し得る。たとえば、ビデオセグメントサイズの変動性は、ビデオセグメントの平均サイズの70%から130%の間で、ネットワークジッタの推定を変動させ得る。

本明細書で使用される場合、「受信機デバイスのジッタ」は、受信機デバイス上で実行される要求側のアプリケーション/クライアントに対する、セグメントの到達時間とセグメントの利用可能性との最大の差を指す。受信機デバイスのジッタは、セグメントサイズの変動性、スケジューリング期間の粒度の変動性(たとえば、セグメントの到達の1秒の周期性を中心とする、320msというMCHスケジューリング周期の変動性)、受信機デバイス上での処理遅延(たとえば、前方誤り訂正(FEC)処理、復号時間など)の変動性、および受信機デバイスの時計のずれの変動性に関連し得る。

セグメント利用可能性タイムライン(たとえば、MPD)でのネットワークジッタの推定の配信は、受信機デバイスのサーバ(たとえば、受信機デバイス上のローカルHTTPサーバ)におけるバッファリング要件のより良好な推定、および/または、受信機デバイスの時計がサーバの時計に同期されていないときのタイムライン調整に対する改善を、可能にし得る。

図1は、様々な実施形態とともに使用するのに適したセルラーネットワークシステム100を示す。セルラーネットワークシステム100は、受信機デバイス102、1つまたは複数のセルラータワーまたは基地局104、ならびに、インターネット110に接続されたサーバ108および112のような、複数のデバイスを含み得る。受信機デバイス102は、CDMA、TDMA、GSM（登録商標）、PCS、3G、4G、LTE、または任意の他のタイプの接続を含む、1つまたは複数のセルラー接続106を介して、セルラータワーまたは基地局104とデータを交換することができる。セルラータワーまたは基地局104は、インターネット110に接続し得るルータと通信していてよい。このようにして、セルラータワーまたは基地局104への接続、および/またはインターネット110を介して、受信機デバイス102とサーバ108および112との間でデータが交換され得る。ある実施形態では、サーバ108は、DASHクライアントを介した出力のためにMPDおよびセグメントを提供する、コンテンツプロバイダサーバまたはエンコーダであり得る。ある実施形態では、サーバ112は、エンコーダからMPDおよびセグメントの出力を受信し、受信機デバイス102へのMPDおよびセグメントのOTA送信を制御できる、ブロードキャストマルチメディアサービスセンター(BMSC)サーバであり得る。当然、本明細書で説明される受信機デバイスの特徴は、OTA送信を参照して説明され得るが、これらの特徴は、有線送信、ワイヤレス送信、または有線送信とワイヤレス送信の組合せとの接続において使用され得る。したがって、OTA送信は必須ではない。

図2は、ある実施形態による、簡略化された受信機デバイス202のアーキテクチャを示す。受信機デバイス202は、取得、ハンドオフ、リンク維持などのような、受信機デバイス202のすべての無線の態様を管理する、モデムレイヤ208を含み得る。モデムレイヤ208は、受信されたeMBMSベアラ信号を復号し、インターネットプロトコル(IP)パケットをマルチキャストサービスデバイスクライアント(MSDC)206に配信することができる。マルチキャストサービスデバイスクライアント206は、配信されたIPパケットからセグメントを復元し、アプリケーション/DASHクライアント204のようなアプリケーション/クライアントに対してセグメントを利用可能にする、受信機デバイス202のサービスレイヤであり得る。例として、マルチキャストサービスデバイスクライアント206は、受信機デバイス202のオペレーティングシステムの一部であるサービスレイヤであり得る。マルチキャストサービスデバイスクライアント206はまた、配信されたIPパケットからMPDを復元することができる。マルチキャストサービスデバイスクライアント206は、受信機デバイスのメモリに受信されたセグメントを記憶することができる。ある実施形態では、マルチキャストサービスデバイスクライアント206は、MPDを調整して、修正されたMPDを生成し、受信機デバイスのメモリに修正されたMPDを記憶することができ、修正されたMPDをアプリケーション/DASHクライアント204に配信することができる。別の実施形態では、マルチキャストサービスデバイスクライアント206は、MPDに対する遅延調整を決定し、受信機デバイスのメモリに(たとえば、遅延調整メッセージに)MPDに対する遅延調整を記憶し、受信機デバイスのメモリにMPDを記憶することができ、MPDとMPDに対する遅延調整とをアプリケーション/DASHクライアント204に配信することができる。アプリケーション/DASHクライアント204は、DASH対応アプリケーション、および/または、(直接、かつ/または、メディアプレーヤーのような別のアプリケーションを介して)メディアを表示するためにDASHクライアントを起動するアプリケーションであり得る。ある実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から修正されたMPDの位置(たとえば、Uniform Resource Locator(URL))を取得し、マルチキャストサービスデバイスクライアント206から修正されたMPDを要求し受信することができ、修正されたMPD中の利用可能性タイムラインごとに、マルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。別の実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206からMPDの位置(たとえば、Uniform Resource Locator(URL))とMPDの位置(たとえば、URL)に対する遅延調整とを取得し、マルチキャストサービスデバイスクライアント206からMPDとMPDに対する遅延調整とを要求して受信し、MPDに対する遅延調整に従ってMPDを修正して修正されたMPDを生成することができ、修正されたMPD中の利用可能性タイムラインごとにマルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から要求されたセグメントを受信することができ、セグメントのコンテンツを(直接、かつ/または、メディアプレーヤーのような別のアプリケーションを介して)レンダリングすることができる。さらなる実施形態では、MPDに対する遅延調整を決定するために使用されるマルチキャストサービスデバイスクライアント206の機能は、クライアント206に統合されてよく、クライアント206は、遅延調整を決定し、かつ/または、MPD自体を修正することができる。

図3Aは、ある実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。セグメント配信経路は、エンコーダ302、BMSC 304、受信機デバイスのマルチキャストサービスデバイスクライアント306、および受信機デバイスのDASHクライアント308を含み得る。エンコーダ302は、メディアコンテンツをセグメントへと符号化し、セグメントを定期的にBMSC 304に配信することができる。たとえば、セグメントは、eMBMSゲートウェイを介して、エンコーダ302からBMSC 304に定期的に配信され得る。BMSC 304は、ベアラを通じて(たとえば、OTAブロードキャストを介して)セグメントを受信し、セグメントをブロードキャストすることができる。ある実施形態では、ヘッドエンドのレイテンシおよびジッタは知られていることがある。受信機デバイスは、モデムを介してセグメントを受信することができ、マルチキャストサービスデバイスクライアント306は、モデムを介してセグメントを受信し、セグメントを処理して(たとえば、セグメントを復号して、FECを適用して、など)受信機デバイスのDASHクライアント308に対してセグメントを利用可能にすることができる。DASHクライアント308は、セグメントを受信機デバイスのアプリケーション(たとえば、メディアプレーヤー)またはコーデックに提供して、受信機デバイスによるメディアコンテンツの出力を可能にし得る。

セグメントを生成することに加えて、エンコーダ302は、MPD 310を生成することができる。エンコーダにより生成されたMPD 310は、エンコーダ302によって生成された、かつ/または生成されることになるセグメント、セグメントの長さ(たとえば、サイズ)、およびセグメントの利用可能時間を記載してよい。ある実施形態では、エンコーダにより生成されるMPD 310の中の利用可能時間は、エンコーダ302により生成されるセグメントの出力時間に対応し得る。エンコーダ302は、生成されたMPD 310をBMSC 304に提供することができる。ある実施形態では、BMSC 304は、生成されたMPD 310を受信し、あらゆるOTA配信遅延(たとえば、ネットワークジッタ)を考慮するようにセグメント利用可能性タイムラインを調整して、MPD 312を生成することができる。BMSC 312は、MPD 312を受信機デバイスに送信することができる。MPD 312は、セグメントのOTA利用可能時間に対応するセグメント利用可能時間を記載してよい。ある実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、受信機デバイスの時計のずれのマージンなど)に基づいて、ローカル受信機デバイスの時計ごとに利用可能時間を調整して、受信機デバイスにおけるセグメントに対する実際の推定される利用可能時間を記載する修正されたMPD 314を生成することができる。マルチキャストサービスデバイスクライアント306は、修正されたMPD 314をDASHクライアント308に提供することができ、DASHクライアントは、MPD中のセグメント利用可能時間を使用して、受信機デバイスの時計を使用して受信機デバイスのローカルHTTPサーバからのセグメントを要求することができる。別の実施形態では、受信機デバイスのマルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、時計のずれなど)に基づいて、ローカル受信機デバイスの時計ごとにMPD 312中の利用可能時間を調整し、DASHクライアント308に送信されるあらゆるMPDとは別個に、利用可能時間に対する調整をDASHクライアント308に通信する。さらなる実施形態では、マルチキャストサービスデバイスクライアント306によって行われる調整は、表示がユニキャスト送信を介して受信されたかブロードキャスト送信を介して受信されたか、および/または、各表示のセグメントサイズに基づいて変化し得る。

図3Bは、別の実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。図3Bに示される配信調整は、図3Bではマルチキャストサービスデバイスクライアント306がMPDをDASHクライアント308に送信する前にMPDを修正できないことを除き、図3Aに関して上で説明されたものと同様である。ある実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306はセグメント利用可能時間を修正することなくMPD 312をDASHクライアント308に提供することができる。ある実施形態では、マルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、時計のずれなど)に基づいてローカル受信機のデバイスの時計ごとに利用可能時間を調整し遅延調整を記載する遅延調整メッセージ316を生成するために使用され得る、遅延調整を決定することができる。マルチキャストサービスデバイスクライアント306は、遅延調整メッセージをDASHクライアント308に提供することができる。ある実施形態では、DASHクライアント308は、遅延調整メッセージ316中の遅延調整の指示を使用して、MPD 312中のセグメント利用可能時間を修正して、修正されたMPD 314を生成することができる。DASHクライアント308は、受信機デバイスの時計を使用して、受信機デバイスのローカルHTTPサーバからセグメントを要求することができる。別の実施形態では、DASHクライアント308は、遅延調整メッセージ316を受信し、遅延調整メッセージ316を使用して、修正されたMPD 314を生成することなく受信機デバイスのローカルHTTPサーバからのセグメントに対する要求を修正することができる。

図4は、ストリーミング経路上の様々な遅延と、受信機デバイスが受け得る、セグメント利用可能性に対するそれらの遅延の経時的な影響とを示す。ある実施形態では、生で記録された生のメディアソースは、エンコーダによってセグメント(たとえば、図4に示される0、1、2、3、4、5、6)へと分割され得る。エンコーダは、ネットワーク時間プロトコル(NTP)時間に従ってセグメントの境界を同期することができ、セグメント0、1、2、3、4、5、6は、符号化遅延に従ってエンコーダから出力され得る。ある実施形態では、エンコーダは、セグメント0、1、2、3、4、5、6の利用時間をエンコーダ出力時間として記載する、利用可能性タイムライン(たとえば、エンコーダにより生成されるMPD)を生成することができる。エンコーダは、セグメント0、1、2、3、4、5、6およびMPDをBMSCに送信することができ、セグメント0、1、2、3、4、5、6のBMSCへの転送はさらに、セグメント0、1、2、3、4、5、6を遅らせ得る。BMSCは、セグメントを処理して、セグメントをメディアセグメントパケット(MSP)へと分割し、MSPを同期し、OTA送信のためにMSPをスケジューリングすることができる。各MSPは、ある設定されたMSP期間、たとえば1秒を割り当てられ得る。MSPは、受信機デバイスにOTAでブロードキャストされてよく、受信機デバイスにおいてセグメントに対するMSPが受信されると、セグメントはデバイスにおいて受信され得る。ある実施形態では、生のメディアソースセグメントの記録と、受信機デバイスにおけるそのセグメントに対応するMSPの受信との間の時間が、ネットワークジッタであり得る。ある実施形態では、BMSCはまた、MPDを受信機デバイスに送信することができる。セグメントに対応するMSPは受信機デバイスにおいて受信され得るが、セグメントが受信機デバイスにおいて利用可能になる前に追加の処理が必要とされ得る。追加の処理は、セグメント0、1、2、3、4、5、6をそれらのそれぞれのMSPから取り出し再構成すること、FECを適用すること、セグメントを復号することなどを含み得る。受信機デバイスにおける最悪の場合の処理遅延はさらに、セグメント0、1、2、3、4、5、6の利用可能性を遅らせ得る。最悪の場合の処理遅延に加えて、受信機の時計のずれがさらに、受信機デバイスにおけるセグメント0、1、2、3、4、5、6の利用可能時間に影響を与え得る。

ある実施形態では、受信機デバイスは、受信機の時計のずれを考慮するためにセグメント利用可能時間を告知することができる。ある実施形態では、受信機デバイスは、受信機デバイスの処理遅延および受信機デバイスの時計のずれを考慮した修正されたMPDを生成するように、受信されたMPD中の利用可能時間を調整することができる。図4に示されるように、修正されたMPD中のセグメント(たとえば、セグメント0)の利用可能時間は、エンコーダにより生成されたMPD中の同じセグメントの利用可能時間より遅れ得る。ある実施形態では、受信機デバイスにおける最悪の場合のセグメント利用可能時間は、プラス/マイナスである受信機の時計のずれの不確実性により、セグメントに対する実際の要求時間(たとえば、DASHクライアントがローカルHTTPサーバからのセグメントを要求する受信機の時計の時間)に依存することがあり、セグメントは、修正されたMPDに記載された時間の後でも実際には利用可能ではないことがある。

図5Aは、MPDのようなセグメント利用可能性タイムラインを受信機デバイス上で提供するためのある実施形態の方法500Aを示し、この方法において、受信機デバイスの時計は、OTA送信を介してセグメントを提供するブロードキャストネットワークの時計と同期され得る。ある実施形態では、方法500Aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500Aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ある実施形態では、受信機デバイスは、OTA送信を介してMPDを受信することができる。ある実施形態では、MPDは、ネットワークから受信されてよく、ヘッドエンドは、MPD中のセグメントの利用可能時間を設定することができる。ある実施形態では、MPD中の利用可能時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延(たとえば、ネットワークジッタ)を考慮し得る。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPDを受信することができる。ある実施形態では、受信機デバイスは、User Service Descriptionにおいてネットワークジッタの値を受信することができる。ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、基本処理遅延(T_{Processing_Base})を決定することができる。ある実施形態では、基本処理遅延は、受信されたセグメントを受信機デバイス上のアプリケーション/クライアントに対して利用可能にするために、受信機デバイスによって受信されたあらゆるセグメントを処理することに適用可能な、遅延時間であり得る。基本処理遅延の値は、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して事前に準備されてよく、マルチキャストサービスデバイスクライアントま
たはクライアントアプリケーションが利用可能なメモリに記憶されてよい。ある実施形態では、基本処理遅延は、セグメントのタイプに関連してよく、基本処理遅延を決定するステップは、MPDにおいて特定されるセグメントのタイプに基づいて基本処理遅延を選択するステップを含み得る。たとえば、ビデオセグメントは、オーディオセグメントとは異なる基本処理遅延を有し得る。

ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメント期間を決定することができる。ある実施形態では、MPDは、セグメント期間を記載してよく、マルチキャストサービスデバイスクライアント、またはクライアントアプリケーションは、MPDから現在のセグメントのセグメント期間を決定することができる。ブロック508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメント処理係数(T_{Processing_Factor})を決定することができる。ある実施形態では、セグメント処理係数は、セグメントサイズに基づいてセグメントの処理時間の差を考慮した係数であり得る。処理係数は、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して事前に準備されてよく、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが利用可能なメモリに記憶されてよい。ある実施形態では、処理係数は、セグメントのタイプに関連してよく、処理係数を決定するステップは、MPDにおいて特定されるセグメントのタイプに基づいて処理係数を選択するステップを含み得る。たとえば、ビデオセグメントは、オーディオセグメントとは異なる処理係数を有し得る。

ブロック510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメント期間に処理係数(T_{Processing_Factor})を掛けた結果を、基本処理遅延(T_{Processing_Base})と足し合わせた結果として、処理遅延調整(M)を決定することができる。他の実施形態では、処理遅延調整(M)は、基本処理遅延、セグメント期間、および/または処理係数を他の方式で組み合わせることによって決定され得る。ブロック512において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、決定された処理遅延調整(M)の分だけ、MPD中のセグメントの利用可能時間を移すことができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD中の利用可能時間に遅延マージンを加算して、セグメント処理遅延をカバーすることができる。判定ブロック514において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPD中に修正されていない可能性がある残りのセグメントがあるかどうかを判定することができる。残りのセグメントがある場合(すなわち、判定ブロック514=「Yes」)、ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のセグメントのセグメント期間を決定し、ブロック508、510、および512において、処理遅延を決定し、それに従ってMPD中のセグメントの時間を移すことができる。このようにして、MPD中のいくつかまたはすべてのセグメントが、それぞれの処理遅延を考慮するように移され得る。残りのセグメントがない場合(すなわち、判定ブロック514=「No」)、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能なメモリに、修正されたMPDを記憶することができる。ある実施形態では、修正されたMPDを記憶するステップは、いくつかまたはすべてのMPDが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置に、修正されたMPDを記憶するステップを含み得る。別の実施形態では、クライアントアプリケーションは、修正されたMPDを別個のメモリ位置に特に記憶しなくてよい。むしろ、任意選択のブロック518において、クライアントアプリケーションは、修正されたMPDを使用して、移された利用可能時間においてセグメントを要求するだけであってよい。

図5Bは、遅延調整メッセージを生成するためのある実施形態の方法500Bを示す。実施形態の方法500Bは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図5Aを参照して上で説明された方法500Aと同様である。ある実施形態では、方法500Bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500Bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、506、508、および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行して、処理遅延調整(M)を決定することができる。ブロック517において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに遅延調整(M)の指示を記憶することができる。ある実施形態では、遅延調整メッセージは、クライアントアプリケーションが、受信機デバイスにおけるセグメント利用可能性の遅延を考慮するように、1つまたは複数のセグメントの利用可能時間を移すために使用され得る遅延調整を決定するのに使用できる、データファイルであり得る。ある実施形態では、遅延調整メッセージは、いくつかまたはすべての遅延調整メッセージが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置に、記憶され得る。ブロック519において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD中に遅延調整が決定されていない残りのセグメントがあるかどうかを判定することができる。残りのセグメントがある場合(すなわち、判定ブロック519=「Yes」)、ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のセグメントのセグメント期間を決定し、ブロック508、510、および517において、処理遅延を決定し、それに従って遅延調整の指示を
記憶することができる。このようにして、MPD中のいくつかまたはすべてのセグメントに対する遅延調整の指示が、それぞれの処理遅延を考慮するために、遅延調整メッセージ中で提供され得る。残りのセグメントがない場合(すなわち、判定ブロック519=「No」)、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図5Cは、MPDのようなセグメント利用可能性タイムラインを受信機デバイス上で提供するためのある実施形態の方法500Cを示し、この方法において、受信機デバイスの時計は、OTA送信を介してセグメントを提供するブロードキャストネットワークの時計と同期され得る。実施形態の方法500Cは、セグメント処理係数(T_{Processing_Factor})が少なくとも1つのセグメントに対して決定され得るとともに、すべてのセグメントがその少なくとも1つのセグメントに基づいて移され得ることを除き、図5Aを参照して上で説明された方法500Aと同様である。ある実施形態では、方法500Cの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500Cの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、506、508、および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行して、処理遅延調整(M)を決定することができる。ブロック526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、決定された処理遅延調整(M)の分だけ、MPD中の少なくとも1つのセグメントの利用可能時間を移すことができる。ある実施形態では、MPD中の第1のセグメントの利用可能時間は、処理遅延調整(M)の分だけ移され得る。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントに対するMPD中の利用可能時間に遅延マージンを加算して、セグメント処理遅延をカバーすることができる。ある実施形態では、第1のセグメントの利用可能時間を移すことによって、すべてのセグメントが、決定された遅延調整を考慮するように移されてよく、その理由は、各々の後続のセグメントの利用可能性は、前のセグメントの利用可能時間にに、前のセグメントのそれぞれのセグメント継続期間を足すことに基づいて決定され得るからである。したがって、第1のセグメン
トを移すことによって、すべてのセグメントが移され得る。任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能なメモリに、修正されたMPDを記憶することができる。別の実施形態では、クライアントアプリケーションは、修正されたMPDを別個のメモリ位置に特に記憶しなくてよい。むしろ、任意選択のブロック518において、クライアントアプリケーションは、修正されたMPDを使用して、移された利用可能時間においてセグメントを要求するだけであってよい。さらなる実施形態では、方法500Cの動作は、異なるリプリゼンテーション(Representation)中のセグメントが独立に移されることを可能にするために、リプリゼンテーションごとに繰り返され得る。

図5Dは、遅延調整メッセージを生成するためのある実施形態の方法500Dを示す。実施形態の方法500Dは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図5Cを参照して上で説明された方法500Cと同様である。ある実施形態では、方法500Dの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500Dの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、506、508、および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行して、処理遅延調整(M)を決定することができる。ブロック527において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに少なくとも1つのセグメントに対する処理遅延調整(M)の指示を記憶することができる。ある実施形態では、処理遅延調整(M)は、第1のセグメントに対する処理遅延調整(M)であり得る。上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図6Aは、MPDのような、セグメント利用可能性タイムラインを提供するための別の実施形態の方法600Aを示す。実施形態の方法600Aは、受信機デバイス上の時計のずれもセグメント利用可能時間を調整する際に考慮され得ることを除き、図5Aを参照して上で説明された方法500Aと同様である。ある実施形態では、方法600Aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック602において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、NTP時計サーバと自身の時計を同期することができる。ブロック604において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、受信機の時計のずれ(REC_DRIFT)を決定することができる。ある実施形態では、受信機の時計のずれは、受信機デバイスに対して準備され、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能なメモリに記憶された、値であってよい。

ブロック502、504、506、508、および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行して、処理遅延調整(M)を決定することができる。ブロック606において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、決定された処理遅延調整(M)および受信機の時計のずれ(REC_DRIFT)の分だけ、MPD中のセグメントの利用可能時間を移すことができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、データ経路上で受け得る最大の遅延に受信機のずれを加算して、セグメント処理遅延と時計のずれとをカバーするようにMPD中の利用可能時間を修正することができる。ブロック514と任意選択のブロック516および518において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行することができる。

図6Bは、遅延調整メッセージを生成するための別の実施形態の方法600Bを示す。実施形態の方法600Bは、受信機デバイス上の時計のずれがセグメント利用可能性時間を必ずしも調整することなく遅延調整メッセージ中の遅延調整指示を生成するために使用され得ることを除き、図6Aを参照して上で説明された方法600Aと同様である。ある実施形態では、方法600Bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。

ブロック602、604、502、504、506、508、および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上で説明された方法600Aの同様に番号が付けられたブロックの動作を実行して、処理遅延調整(M)を決定することができる。ブロック607において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された処理遅延調整(M)および受信機の時計のずれ(REC_DRIFT)の指示を記憶することができる。このようにして、クライアントアプリケーションは、遅延調整メッセージを使用して、データ経路上で受け得る最大の遅延に受信機のずれを加算して、セグメント処理遅延と時計のずれとをカバーするようにMPD中の利用可能時間を調整することができる。ブロック519および任意選択のブロック521において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Bを参照して上で説明された方法500Bの同様に番号が付けられたブロックの動作を実行することができる。

図6Cは、MPDのような、セグメント利用可能性タイムラインを提供するための別の実施形態の方法600Cを示す。実施形態の方法600Cは、遅延調整(M)および受信機のずれ(REC_DRIFT)がMPD中の少なくとも1つのセグメントを移すために使用され得るとともに、すべてのセグメントがその少なくとも1つのセグメントに基づいて移され得ることを除き、図6Aを参照して上で説明された方法600Aと同様である。ある実施形態では、方法600Cの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Cの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック602、604、502、504、506、508および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上で説明された方法600Aの同様に番号が付けられたブロックの動作を実行することができる。ブロック610において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、処理遅延調整(M)および受信機のずれ(REC_DRIFT)の分だけ、MPD中の少なくとも1つのセグメントの利用可能時間を移すことができる。ある実施形態では、MPD中の第1のセグメントの利用可能時間は、処理遅延調整(M)および受信機のずれ(REC_DRIFT)の分だけ移され得る。ある実施形態では、第1のセグメントの利用可能時間を移すことによって、すべてのセグメントが、決定された遅延調整を考慮するように移されてよく、その理由は、各々の後続のセグメントの利用可能性は、前のセグメントの利用可能時間に、前のセグメントのそれぞれのセグメント継続期間を足すことに基づいて決定され得るからである。したがって、第1のセグメントを移すことによって、すべてのセグメントが移され得る。ブロック514と任意選択のブロック516および518において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明された方法500Aの同様に番号が付けられたブロックの動作を実行することができる。

図6Dは、遅延調整メッセージを生成するための別の実施形態の方法600Dを示す。実施形態の方法600Dは、受信機デバイス上の時計のずれがセグメント利用可能性時間を必ずしも調整することなく遅延調整メッセージ中の遅延調整指示を生成するために使用され得ることを除き、図6Cを参照して上で説明された方法600Cと同様である。ある実施形態では、方法600Dの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600Dの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック602、604、502、504、506、508および510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上で説明された方法600Aの同様に番号が付けられたブロックの動作を実行することができる。ブロック611において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに少なくとも1つのセグメントに対する処理遅延調整(M)および受信機のずれ(REC_DRIFT)の指示を記憶することができる。ある実施形態では、処理遅延調整(M)および受信機のずれ(REC_DRIFT)は、第1のセグメントに対する処理遅延調整(M)および受信機のずれ(REC_DRIFT)であり得る。上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

様々な実施形態において、受信機デバイスの時計は、ネットワークの時計と常に同期されてはいないことがある。受信機デバイスの時計が同期されていない実施形態では、全地球測位システム(「GPS」)タイミング信号のような別の高精度のタイミング信号が、受信機デバイスの時計を同期するために使用され得る。このようにして、高精度のタイミング信号に基づく正確な時間基準が、受信機デバイスにおけるセグメントおよび/または他のデータの対応する利用可能時間を決定するために使用され得る。ある実施形態では、ネットワークの時計と受信機デバイスの時計の両方が、GPSタイミング信号に同期され得る。受信機デバイスのプロセッサは、受信機デバイスによって受信されるGPSタイミング信号を使用して、ネットワークとのあらゆる同期とは独立に、受信機デバイスの時計をネットワークの時計と同期することができる。

様々な実施形態において、受信機デバイスの時計は、ネットワークの時計と常に同期されてはいないことがある。受信機デバイスの時計が同期されていない実施形態において、利用可能時間は、第1のセグメントが受信される時間に基づいて決定され得る。図7は、ある実施形態を実装する試験システムにおける第1のセグメントの到達時間のグラフである。図7は、最早のセグメントが150ミリ秒の間に復号され、最遅のセグメントが900ミリ秒の間に復号されたので、セグメントの遅延マージンが0.75秒でなければならないことを示す。したがって、0.75秒という遅延マージンは、セグメントサイズの変動性によって引き起こされ得るセグメントの配信ジッタ、セグメント生成およびチャネルのスケジューリングの異なる周期性(たとえば、1MSP=0.32秒)、および時計のずれ(長い再生の場合に考慮される)を考慮し得る。ある実施形態では、遅延マージン(たとえば、0.75秒)が、1.75秒という最悪の場合の遅延時間を生成するために、最長の送信時間(たとえば、0.9秒)に加算され得る。このように、長く受信されたセグメントは、最も緩い利用可能時間の推定につながり、要求側のアプリケーション/クライアント(たとえば、DASHクライアント)へのセグメントの配信を遅らせ得る。ある実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1の受信されたセグメントのセグメント利用可能時間が、セグメントがFile Delivery Over Unidirectional Transport(「FLUTE」)を介して配信される時刻と遅延マージンを足したものとなるように、MPD中の利用可能性タイムラインを調整することができる。別の実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1の受信されたセグメントのセグメント利用可能時間が、セグメントがFile Delivery Over Unidirectional Transport(「FLUTE」)を介して配信される時刻と遅延マージンを足したものとなるように、セグメントの利用可能時間を調整するために用いる遅延調整を示す、遅延調整メッセージを生成することができる。

ある実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最悪の場合の遅延マージンからセグメントの復号時間を引いたものとして、セグメントの調整された利用可能時間を決定することができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの調整された利用可能時間とMPD中の第1のセグメントの利用可能時間との差を決定することができる。ある実施形態では、遅延マージンは、正確な時間基準、たとえばGPSに同期された基準時計に基づく、セグメントの利用可能時間の最大の変動(すなわち、最大の利用可能時間から最小の利用可能時間を引いたもの)であり得る。ある実施形態では、最大の変動は、エンドツーエンドシステムを試験することに基づいて決定され得る。ある実施形態では、最大の変動は、解析的な分析に基づいて決定され得る。

図8Aは、第1のセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Aを示す。ある実施形態では、方法800Aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。ある実施形態では、方法800Aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ブロック802において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、第1のセグメントを受信することができる。ある実施形態では、第1のセグメントは、受信機デバイスのモデムにおいてFLUTEプロトコルを介してOTAブロードキャスト送信を介して受信されてよく、マルチキャストサービスデバイスクライアントに渡されてよい。別の実施形態では、第1のセグメントは、受信機デバイスのモデムにおいてFLUTEプロトコルを介してOTAブロードキャスト送信を介して受信されてよく、第1のセグメントが受信されたという指示または第1のセグメントがクライアントアプリケーションに渡され得る。ブロック804において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、クロックを開始することができる。ブロック806において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、第1のセグメントを復号することができる。ある実施形態では、第1のセグメントを復号するステップは、受信機デバイス上で実行されるアプリケーション/クライアント(たとえば、DASHクライアント)に対してセグメントを利用可能にするのに必要な、受信されたセグメントに対してマルチキャストサービスデバイスクライアントによって適用されるすべての処理を含み得る。別の実施形態では、第1のセグメントを復号するステップは、クライアントアプリケーションに対してセグメントを利用可能にするのに必要な、受信されたセグメントに対してクライアントアプリケーションによって適用されるすべての
処理を含み得る。判定ブロック808において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、第1のセグメントの復号が完了したかどうかを判定することができる。復号が完了していない場合(すなわち、判定ブロック808=「No」)、ブロック806において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントを復号し続けることができる。

復号が完了しているとき(すなわち、判定ブロック808=「Yes」)、ブロック810において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、時計を停止することができる。ブロック812において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、復号時間を決定することができる。ある実施形態では、復号時間は、時計が停止された時計の時刻として決定され得る。ブロック813において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延マージンから復号時間を引いたものとして、第1のセグメントの調整された利用可能時間を決定することができる。ある実施形態では、遅延マージンは、図7を参照して上で論じられたように、第1のセグメントの到達時間の変動性の尺度であり得る。ある実施形態では、遅延マージンは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能な受信機デバイスのメモリにおいて準備され得る。ブロック814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントの調整された利用可能時間とMPD中の第1のセグメントの利用可能時間との差として、遅延調整を決定することができる。ブロック816において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のいくつかまたはすべてのセグメントの利用可能時間を移すことができる。このようにして、いくつかまたはすべての利用可能時間が、第1のセグメントの復号時間を考慮するように調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図8Bは、遅延調整メッセージを生成するためのある実施形態の方法800Bを示す。実施形態の方法800Bは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図8Aを参照して上で説明された方法800Aと同様である。ある実施形態では、方法800Bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800Bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、802、804、806、808、810、812、813、および814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Aを参照して上で説明された方法800Aの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。ブロック817において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。このようにして、クライアントアプリケーションは、遅延調整メッセージを使用して、復号時間に遅延マージンを足した分だけMPD中の利用可能時間を調整することができる。上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図8Cは、ビデオセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Cを示す。実施形態の方法800Cは、復号すべきビデオセグメントを具体的に特定することに基づいて遅延調整が決定され得ることを除き、図8Aを参照して上で説明された方法800Aと同様である。ある実施形態では、方法800Cの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。ある実施形態では、方法800Cの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ある実施形態では、受信機デバイスは、2つ以上のタイプのセグメントを受信することができる。たとえば、受信機デバイスは、ビデオセグメントとオーディオセグメントの両方を受信することができる。ビデオセグメントを復号するのに必要な時間は、オーディオセグメントを復号するのに必要な時間よりも長いことがある。したがって、第1の受信されたセグメントの復号時間を単に使用だけでは、より小さなオーディオセグメントの復号時間がビデオセグメントを復号するのに必要な時間を反映できないので、セグメント利用可能時間を正確に移せない。方法800Cは、復号時間を決定し、それに従って遅延調整を決定するために、ビデオセグメントが受信されるまで待機することによって、ビデオセグメントとオーディオセグメントの復号時間の差に対処する。

上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ブロック821において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントを受信することができる。セグメントは、ビデオセグメントまたはオーディオセグメントのような、任意のタイプのセグメントであり得る。ある実施形態では、セグメントは、受信機デバイスのモデムにおいてFLUTEプロトコルを介してOTAブロードキャスト送信を介して受信されてよく、マルチキャストサービスデバイスクライアントに渡されてよい。別の実施形態では、セグメントは、受信機デバイスのモデムにおいてFLUTEプロトコルを介してOTAブロードキャスト送信を介して受信されてよく、セグメントが受信されたという指示またはセグメントがクライアントアプリケーションに渡され得る。判定ブロック823において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントがビデオセグメントかどうかを判定することができる。例として、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、対応するタイプのセグメントを特定する、受信されたセグメントのヘッダを調査することができる。セグメントがビデオセグメントではない場合(すなわち、判定ブロック823=「No」)、ブロック821において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のセグメントを受信することができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ビデオセグメントを探索することができる。

ビデオセグメントが受信されている場合(すなわち、判定ブロック823=「Yes」)、上で論じられたように、ブロック804において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、時計を始動することができる。ブロック825において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントを復号することができる。ある実施形態では、セグメントを復号するステップは、受信機デバイス上で実行されるアプリケーション/クライアント(たとえば、DASHクライアント)に対してセグメントを利用可能にするのに必要な、受信されたセグメントに対してマルチキャストサービスデバイスクライアントによって適用されるすべての処理を含み得る。別の実施形態では、セグメントを復号するステップは、クライアントアプリケーションに対してセグメントを利用可能にするのに必要な、受信されたセグメントに対してクライアントアプリケーションによって適用されるすべての処理を含み得る。判定ブロック827において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントの復号が完了したかどうかを判定することができる。復号が完了していない場合(すなわち、判定ブロック827=「No」)、ブロック825において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントを復号し続けることができる。

復号が完了しているとき(すなわち、判定ブロック827=「Yes」)、ブロック810において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、時計を停止することができる。ブロック812において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、復号時間を決定することができる。ある実施形態では、復号時間は、時計が停止された時計の時刻として決定され得る。ブロック829において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延マージンから復号時間を引いたものとして、セグメントの調整された利用可能時間を決定することができる。ある実施形態では、遅延マージンは、図7を参照して上で論じられたように、セグメントの到達時間の変動性の尺度であり得る。ある実施形態では、遅延マージンは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能な受信機デバイスのメモリにおいて準備され得る。

ブロック831において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの調整された利用可能時間とMPD中のセグメントの利用可能時間との差として、遅延調整を決定することができる。上で論じられたように、ブロック816において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のいくつかまたはすべてのセグメントの利用可能時間を移すことができる。このようにして、いくつかまたはすべての利用可能時間が、ビデオセグメントの復号時間を考慮するように調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図8Dは、ビデオセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Dを示す。実施形態の方法800Dは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図8Cを参照して上で説明された方法800Cと同様である。ある実施形態では、方法800Dの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800Dの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、821、823、804、825、827、810、829、および831において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Cを参照して上で説明された方法800Cの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。図8Bを参照して上で論じられたように、ブロック817において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。図8Bを参照して上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図8Eは、セグメント受信時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Eを示す。実施形態の方法800Eは、遅延調整が受信機デバイスにおける実際のセグメントの受信時間に基づいて決定され得ることを除き、図8Aを参照して上で説明された方法800Aと同様である。ある実施形態では、方法800Eの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。ある実施形態では、方法800Eの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションがMPDを受信することができ、ブロック802において、第1のセグメントを受信することができる。ブロック833において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、第1のセグメント受信時間を決定することができる。ある実施形態では、第1のセグメントの受信時間は、第1のセグメントが受信機デバイスにおいて受信された実際の時間であり得る。ある実施形態では、第1のセグメントの受信時間は、GPS基準時間のような、正確な時間基準に基づき得る。ある例として、第1のセグメントの受信時間は、GPS基準時間を使用して決定されるような、受信機デバイスのFLUTEレイヤにおいて第1のセグメントの第1のパケットが受信された時間であり得る。ブロック835において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントの受信時間として、第1のセグメントの調整された利用可能時間を決定することができる。別の実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントの第1のセグメントの受信時間に遅延マージンを足したものとして、第1のセグメントの調整された利用可能時間を決定することができる。ある実施形態では、遅延マージンは、第1のセグメント利用可能時間を第1のパケットの受信時間に設定し、すべての後続のセグメントの利用可能時間を、先行するセグメントの利用可能時
間とセグメント期間との和に設定することによって構築される利用可能性タイムラインを、セグメントの復号時間の差の最大の変動から引いたものであり得る。ある実施形態では、遅延マージンは、受信機デバイスで事前に準備され得る。上で論じられたように、ブロック814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントの調整された利用可能時間とMPD中の第1のセグメントの利用可能時間との差として、遅延調整を決定することができる。このようにして、第1のセグメントの実際の受信時間は、それ自体が、MPD中の利用可能時間を実際の到達時間と揃えるために使用され得る遅延調整を決定し得る。上で論じられたように、ブロック816において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のすべてのセグメントの利用可能時間を移すことができる。このようにして、第1のセグメントの利用可能時間が第1の受信されたセグメントの第1のパケットの受信時間に設定され、すべての後続のセグメントの利用可能時間が先行するセグメントの利用可能時間と先行するセグメントの期間との和となり得る、移された利用可能性タイムラインが構築され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図8Fは、セグメント受信時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法800Fを示す。実施形態の方法800Fは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図8Eを参照して上で説明された方法800Eと同様である。ある実施形態では、方法800Fの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800Fの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、802、833、835、および814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Fを参照して上で説明された方法800Fの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。図8Bを参照して上で論じられたように、ブロック817において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。図8Bを参照して上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図8Gは、セグメント復号完了時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Gを示す。実施形態の方法800Gは、第1のセグメントの復号が受信機デバイスにおいて完了された実際の時間に基づいて遅延調整が決定され得ることを除き、図8Aを参照して上で説明された方法800Aと同様である。ある実施形態では、方法800Gの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。ある実施形態では、方法800Gの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、802、806および808において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、方法800Aの同様に番号が付けられたブロックの動作を実行することができる。第1のセグメントの復号が完了している場合(すなわち、判定ブロック808=「Yes」)、ブロック836において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメント復号完了時間を決定することができる。ある実施形態では、第1のセグメントの復号完了時間は、セグメントが受信機デバイス上でアプリケーションに対して利用可能となるように第1のセグメントが完全に復号および/または処理された実際の時間であり得る。ある実施形態では、第1のセグメントの復号完了時間は、GPS基準時間のような、正確な時間基準に基づき得る。ブロック837において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延マージンに復号完了時間を足したものとして、第1のセグメントの調整された利用可能時間を決定することができる。このようにして、調整された利用可能時間は、セグメントの復号時間と同じセグメントの利用可能時間との差の最大値と最小値の間の、最大の変動性を考慮し得る。ある実施形態では、遅延マージンは、第1のセグメント利用可能時間を第1のセグメントの復号完了時間に設定し、すべての後続のセグメントの利用可能時間を、先行するセグメントの利用可能時間とセグメント期間との和に設定することによって構築される利用可能性タイムラインを
、セグメントの到達時間の差の最大の変動から引いたものであり得る。ある実施形態では、遅延マージンは、受信機デバイスに対して事前に準備され得る。上で論じられたように、ブロック814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のセグメントの調整された利用可能時間とMPD中の第1のセグメントの利用可能時間との差として、遅延調整を決定することができる。このようにして、第1のセグメントが復号された実際の時間は、それ自体が、MPD中の利用可能時間を実際の利用可能時間と揃えるために使用され得る遅延調整を決定し得る。上で論じられたように、ブロック816において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のすべてのセグメントの利用可能時間を移すことができる。このようにして、第1のセグメントの利用可能時間が遅延マージンと第1のセグメントの復号時間との和に設定され、すべての後続のセグメントの利用可能時間が先行するセグメントの利用可能時間と先行するセグメントの期間との和となり得る、移された利用可能性タイムラインが構築され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図8Hは、セグメント復号完了時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法800Hを示す。実施形態の方法800Hは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図8Gを参照して上で説明された方法800Gと同様である。ある実施形態では、方法800Gの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800Gの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、802、806、836、837、および814において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Gを参照して上で説明された方法800Gの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。図8Bを参照して上で論じられたように、ブロック817において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。図8Bを参照して上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

図8Iは、オーディオセグメントおよびビデオセグメントの復号時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法800Iを示す。実施形態の方法800Iは、オーディオセグメントとビデオセグメントの両方を復号することに基づいて遅延調整が決定され得ることを除き、図8Cを参照して上で説明された方法800Cと同様である。ある実施形態では、方法800Iの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。ある実施形態では、方法800Iの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ある実施形態では、受信機デバイスは、2つ以上のタイプのセグメントを受信することができる。たとえば、受信機デバイスは、ビデオセグメントとオーディオセグメントの両方を受信することができる。方法800Iは、オーディオセグメントとビデオセグメントの両方の復号時間を使用して遅延調整を決定することによって、オーディオセグメントとビデオセグメントの両方を復号するのに必要な時間を考慮することができる。

上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションがMPDを受信することができ、ブロック821において、セグメントを受信することができる。判定ブロック839において、マルチキャストサービスデバイスクライアントまたはクライアントが、受信されたセグメントが第1のビデオセグメントかどうかを判定することができる。セグメントが第1の受信されたセグメントである場合(すなわち、判定ブロック839=「Yes」)、上で論じられたように、ブロック804において、マルチキャストサービスデバイスクライアントまたはクライアントは、時計を始動することができる。ブロック840において、マルチキャストサービスデバイスクライアントまたはクライアントが、ビデオセグメントを復号することができる。判定ブロック842において、マルチキャストサービスデバイスクライアントまたはクライアントが、ビデオセグメントの復号が完了したかどうかを判定することができる。復号が完了していない場合(すなわち、判定ブロック842=「No」)、ブロック840において、マルチキャストサービスデバイスクライアントまたはクライアントは、ビデオセグメントを復号し続けることができる。復号が完了している場合(すなわち、判定ブロック842=「Yes」)、ブロック810において上で論じられたように、マルチキャストサービスデバイスクライアントまたはクライアントは、時計を停止することができる。ブロック844において、マルチキャストサービスデバイスクライアントまたはクライアントは、第1のビデオセグメントの復号時間に対応する時計の値として、ビデオ復号時間を決定することができる。

セグメントが第1の受信されたビデオセグメントではない場合(すなわち、判定ブロック839=「No」)、判定ブロック841において、マルチキャストサービスデバイスクライアントまたはクライアントは、セグメントが第1のオーディオセグメントかどうかを判定することができる。セグメントが第1のオーディオセグメントではない場合(すなわち、判定ブロック841=「No」)、マルチキャストサービスデバイスクライアントまたはクライアントは、ブロック821に進み、次のセグメントを待機することができる。セグメントが第1のオーディオセグメントである場合(すなわち、判定ブロック841=「Yes」)、上で論じられたように、ブロック804において、マルチキャストサービスデバイスクライアントまたはクライアントは、時計を始動することができる。ブロック846において、マルチキャストサービスデバイスクライアントまたはクライアントが、オーディオセグメントを復号することができる。判定ブロック847において、マルチキャストサービスデバイスクライアントまたはクライアントが、オーディオセグメントの復号が完了したかどうかを判定することができる。復号が完了していない場合(すなわち、判定ブロック847=「No」)、ブロック846において、マルチキャストサービスデバイスクライアントまたはクライアントは、オーディオセグメントを復号し続けることができる。復号が完了している場合(すなわち、判定ブロック847=「Yes」)、ブロック810において上で論じられたように、マルチキャストサービスデバイスクライアントまたはクライアントは、時計を停止することができる。ブロック848において、マルチキャストサービスデバイスクライアントまたはクライアントは、第1のオーディオセグメントの復号時間に対応する時計の値として、オーディオ復号時間を決定することができる。

判定ブロック850において、マルチキャストサービスデバイスクライアントまたはクライアントが、ビデオ復号時間とオーディオ復号時間の両方が決定されたかどうかを判定することができる。ビデオセグメントの復号時間とオーディオセグメントの復号時間の両方が決定されていない場合(すなわち、判定ブロック850=「No」)、ブロック821において、マルチキャストサービスデバイスクライアントまたはクライアントは、次のセグメントの受信を待機することができ、上で説明されたようにビデオセグメントおよび/またはオーディオセグメントの両方の復号時間を決定することに進むことができる。ビデオ復号時間とオーディオ復号時間の両方が決定されている場合(すなわち、判定ブロック850=「Yes」)、ブロック852において、マルチキャストサービスデバイスクライアントまたはクライアントは、遅延マージンからビデオ復号時間とオーディオ復号時間を引いたもの(すなわち、[遅延マージン]-([ビデオ復号時間]+[オーディオ復号時間]))として遅延調整を決定することができる。このようにして、遅延調整は、オーディオセグメントを復号するのにかかる時間と、ビデオセグメントを復号するのにかかる時間の両方を考慮することができる。上で論じられたように、ブロック816において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のいくつかまたはすべてのセグメントの利用可能時間を移すことができる。このようにして、いくつかまたはすべての利用可能時間が、オーディオセグメントおよびビデオセグメントの復号時間を考慮するように調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図8Jは、オーディオセグメントおよびビデオセグメントの復号時間に基づいて遅延調整メッセージを生成するためのある実施形態の方法800Jを示す。実施形態の方法800Jは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図8Iを参照して上で説明された方法800Iと同様である。ある実施形態では、方法800Jの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800Jの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、821、839、804、840、842、810、844、841、846、847、848、850、および852において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Iを参照して上で説明された方法800Iの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。図8Bを参照して上で論じられたように、ブロック817において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。図8Bを参照して上で論じられたように、任意選択のブロック521において、たとえば、図12のブロック1206を参照して以下で論じられるように、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能時間を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

受信機デバイスの時計が同期されていない実施形態では、利用可能時間は、受信されたセグメントのパケットの第1のバーストを告知する第1のファイル配信テーブル(FDT)のタイムスタンプに基づいて決定され得る。第1のバーストとより後のバースト内で受信されるパケットが、セグメントを構築するために使用され得る。図9は、ある実施形態を実装する試験システムにおける第1のセグメントの到達時間のグラフである。図9は、最遅のセグメントが受信から900ミリ秒の間に復号されたので、セグメントの遅延マージンが0.9秒でなければならないことを示す。図7を参照して上で論じられたセグメント期間によりタイミング誤差を除去するセグメントの送信の始めにおいて、FLUTE FDTが送信され得るので、図9は、FDTのタイムスタンプからの遅延マージン(たとえば、0.9秒)が最悪の場合の遅延(たとえば、0.9秒)に等しいくてよいことを示す。したがって、0.9秒という遅延マージンは、セグメント期間に等しいくてよいセグメントの配信ジッタ、セグメント生成およびチャネルのスケジューリングの異なる周期性(たとえば、1MSP=0.32秒)、および時計のずれ(長い再生の場合に考慮される)を考慮し得る。ある実施形態では、タイミングの精度は、どのセグメントが最初に受信されたかとは無関係である。ある実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメント利用可能時間が、セグメントが最初に告知される時間となるように、FLUTE FETと遅延マージンの和の分だけ、MPD中の利用可能性タイムラインを調整することができる。別の実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメント利用可能時間が、セグメントが最初に告知される時間となるように、FLUTE FETと遅延マージンの和の分だけセグメントの利用可能時間を調整するために用いる遅延調整を示す、遅延調整メッセージを生成することができる。

図10Aは、FDT受信時間に基づいてセグメント利用可能時間を修正するためのある実施形態の方法1000Aを示す。ある実施形態では、方法1000Aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1000Aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ブロック1002において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、第1のセグメントを告知するFLUTEファイル配信テーブル(FDT)を受信することができる。ある実施形態では、クライアントアプリケーションは、第1のセグメントを告知する受信機デバイスにおいてFDTが受信されたことの指示を受信することができる。ブロック1004において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、基準時間(すなわち、Time_Reference)としてFDT受信時間を決定することができる。ブロック1006において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、基準時間(すなわち、Time_Reference)と遅延マージンとの和として、調整された利用可能時間を決定することができる。ある実施形態では、遅延マージンは、図9を参照して上で論じられたように、試験システムにおける到達時間の変動性の尺度であり得る。ブロック1008において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、調整された利用可能時間とMPD中の第1のセグメントの利用可能時間との差として、遅延調整を決定することができる。ブロック1010において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整の分だけ、MPD中のいくつかまたはすべてのセグメントの利用可能時間を移すことができる。このようにして、いくつかまたはすべての利用可能時間が、FDTの受信時間を考慮するよう
に調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。上で論じられたように、任意選択のブロック518において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図10Bは、遅延調整メッセージを生成するためのある実施形態の方法1000Bを示す。実施形態の方法1000Bは、セグメント利用可能性タイムラインの移動を示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしも移すことなく生成され得ることを除き、図10Aを参照して上で説明された方法1000Aと同様である。ある実施形態では、方法1000Bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1000Bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、1002、1004、1006、および1008において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図10Aを参照して上で説明された方法1000Aの同様に番号が付けられたブロックの動作を実行して、遅延調整を決定することができる。ブロック1011において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージに決定された遅延調整の指示を記憶することができる。このようにして、クライアントアプリケーションは、遅延調整メッセージを使用して、MPD中の利用可能時間を調整することができる。上で論じられたように、任意選択のブロック521において、マルチキャストサービスデバイスクライアントは、セグメントの利用可能性を移す際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送信することができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。

ある実施形態では、MPD中の利用可能時間の調整は、リプリゼンテーションの数に基づいて増強され得る。ビデオおよびオーディオを搬送する単一のリプリゼンテーションでは、単一のセグメントが受信されてよく、単一のセグメントは、第1の受信されたセグメントの利用可能時間が、第1のセグメントの受信時間と、遅延ジッタと、OTAによる周期的なスケジューリングを考慮するための0.32秒と、処理遅延と、デバイスの時計のずれとの和と等しくなるように、MPDが調整され得る。二重のリプリゼンテーションでは、一方はオーディオであり他方はビデオである、同じインデックスを伴う2つのセグメントが受信されてよく、2つのセグメントは、受信されたオーディオセグメントとビデオセグメントの利用可能時間が、2つのセグメントの受信時間のうちの後の受信時間と、遅延ジッタと、0.32秒と、処理遅延と、デバイスの時計のずれとの和に等しくなるように、MPDが調整され得る。

別の実施形態では、MPD中の利用可能時間の調整は、リプリゼンテーションの数に基づいて増強され得る。ビデオおよびオーディオを搬送する単一のリプリゼンテーションでは、単一のセグメントが受信され、単一のセグメントは、第1のセグメントの利用可能性が、セグメントを記述する第1のFDT受信時間と、セグメント期間と、処理遅延と、デバイスの時計のずれとの和と等しくなるように、MPDが調整され得る。二重のリプリゼンテーションでは、一方はオーディオであり他方はビデオである、同じインデックスを伴う2つのセグメントが受信されてよく、2つのセグメントは、第1のセグメントの利用可能性が、セグメントのいずれかを記述する第1のFDT受信時間と、セグメント期間と、処理遅延と、デバイスの時計のずれとの和と等しくなるように、MPDが調整され得る。

様々な実施形態において、ネットワークと受信機デバイスとの間で同期されたタイミングは、SNTPが受信機デバイスにおいて利用可能であり、時計のずれが受信機デバイスにおいて有限であり、利用可能時間に対するネットワークの設定が正確であるとき、有利であり得る。様々な実施形態において、ネットワークと受信機デバイスとの間の同期されていないタイミングは、ループバック試験モードで、およびネットワークジッタが低い条件において有利であり得る。

図11Aは、MPDにネットワークジッタの推定を含めるためのある実施形態の方法1100Aを示す。方法1100Aの動作は、上で説明された実施形態の方法500A、500B、600A、600B、800A、800B、1000A、および1000Bのいずれかの動作とともに実行され得る。ある実施形態では、ネットワークジッタの推定(すなわち、ブロードキャストされるリプリゼンテーションに対する配信経路上の遅延ジッタ)が、BMSCによってMPDにおいて告知され得る。MPDの告知は、受信機デバイスによるマージンおよび利用可能性タイムラインの設定を可能にし、バッファリングの決定を支援することができる。たとえば、BMSCが利用可能性タイムラインを計算しないとすると、受信時間とジッタは、利用可能時間の上限であることが保証され得るとともに、バッファ中にセグメントをどの程度の長さの時間保持するかを計算する際に、それを置き換えることができる。代替的な実施形態では、ネットワークジッタは、受信機デバイスで事前に準備され得る。さらに別の実施形態では、受信機デバイスは、サービスおよび/または配信技術に対して、以前に受信されたセグメントに基づいてネットワークジッタの推定を計算することができる。例として、受信機デバイスは、ネットワークジッタの値を計算し、計算されたネットワークジッタの値に少なくとも一部基づいて遅延調整を決定することができる。ブロック1102において、BMSCは、ネットワーク遅延(Network_Jitter)を決定することができる。ある実施形態では、ネットワーク遅延は、BMSCを介してエンコーダから受信機デバイスにセグメントを提供する際の配信経路上の遅延であり得る。ブロック1104において、BMSCは、Network_Jitterを含むMPDを生成し、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに送信することができる。上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ブロック1106において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDにおいて受信されるNetwork_Jitterに基づいて、MPD中のすべてのセグメントの利用可能時間を移すことができる。このようにして、MPD中のすべての利用可能時間は、Network_Jitterのために調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。

図11Bは、MPDにネットワークジッタの推定を含めるためのある実施形態の方法1100Bを示す。実施形態の方法1100Bは、方法1100Bではネットワークジッタの推定(すなわち、ブロードキャストされるリプリゼンテーションに対する配信経路上の遅延ジッタ)がBMSCによってMPDとは独立に告知され得ることを除き、図11Aを参照して上で説明された実施形態の方法1100Aと同様である。方法1100Bの動作は、上で説明された実施形態の方法500A、500B、600A、600B、800A、800B、1000A、および1000Bのいずれかの動作とともに実行され得る。上で論じられたように、ブロック1102において、BMSCは、ネットワーク遅延(Network_Jitter)を決定することができる。ブロック1107において、BMSCは、MPDを生成し、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに送信することができる。ブロック1109において、BMSCは、Network_Jitterの指示を生成し、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに送信することができる。例として、この指示は、Network_Jitter値を含むオーバーヘッドシグナリングの一部として送信されるメッセージであり得る。上で論じられたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、MPDを受信することができる。ブロック1111において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、Network_Jitterの指示を受信することができる。上で論じられたように、ブロック1106において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDにおいて受信されるNetwork_Jitterに基づいて、MPD中のすべてのセグメントの利用可能時間を移すことができる。このようにして、MPD中のすべての利用可能時間は、Network_Jitterのために調整され得る。上で論じられたように、任意選択のブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、修正されたMPDを記憶することができる。

図12は、遅延調整メッセージ中の指示に基づいて利用可能時間を調整するためのある実施形態の方法を示す。ある実施形態では、方法1200の動作は、DASHクライアントのような、スマートフォンなどの受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック1202において、クライアントアプリケーションは、MPDを受信することができる。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介してMPDを受信することができる。ブロック1204において、クライアントアプリケーションは、遅延調整メッセージを受信することができる。ある実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介して遅延調整メッセージを受信することができる。ブロック1206において、クライアントアプリケーションは、遅延調整メッセージに基づいて、MPD中のいくつかまたはすべてのセグメントの利用可能時間を移すことができる。ある実施形態では、遅延調整メッセージに基づいて利用可能時間を移すステップは、遅延調整、処理遅延、受信機の時計のずれ、ネットワークジッタ、および/または、各セグメントが受信機デバイス上で利用可能になる時間を調整するための他の値の指示を使用するステップを含み得る。ある実施形態では、利用可能時間を移すステップは、MPD自体を修正して修正されたMPDを生成するステップを含み得る。別の実施形態では、利用可能時間を移すステップは、MPD自体を修正することなく、セグメントが受信機デバイス上で利用可能になるときの指示を変更するステップを伴い得る。MPDが修正される実施形態では、任意選択のブロック1208において、クライアントアプリケーションは、クライアントアプリケーションに対して利用可能なメモリに、修正されたMPDを記憶することができる。ブロック1210において、クライアントアプリケーションが、移された利用可能時間においてセグメントを要求することができる。

図13は、ある実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。アプリケーション/DASHクライアントは、マルチキャストサービスデバイスクライアントのサービス発見機能に対する要求を送信することによって、サービスがアクティブ化されることを要求することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、サービス要求を受信し、サービスが有効であると判定し、サービス情報をマルチキャストサービスデバイスクライアントのストリーミング機能に送信してサービスをアクティブ化することができる。マルチキャストサービスデバイスのストリーミング機能は、サービスが有効であると判定し、サービスの一時モバイルグループ識別子(TMGI)をアクティブ化するための要求をマルチキャストサービスデバイスクライアントのモデムインターフェースに送信することができる。マルチキャストサービスデバイスクライアントのストリーミング機能はまた、マルチキャストサービスデバイスクライアントのデータ配信機能がFLUTEセッションをアクティブ化することと、マルチキャストサービスデバイスクライアントのデータ配信機能がセグメントURLを獲得することとを要求することができる。

一時モバイルグループ識別子がモバイル制御チャネル(MCCH)においてアクティブになり、デバイスがメディア転送チャネル(MTCH)を復号できるようになると、モデムによって受信されるIPパケットは、マルチキャストサービスデバイスクライアントのモデムインターフェースからマルチキャストサービスデバイスクライアントのデータ配信機能に配信され得る。マルチキャストサービスデバイスクライアントのデータ配信機能は、セグメントNを、それが復号されるとマルチキャストサービスデバイスクライアントのDashゲートウェイに送信し、ファイル利用可能通知をマルチキャストサービスデバイスクライアントのストリーミング機能に送信することができる。セグメントN+1、N+2などが受信され復号されるにつれて、それらは、マルチキャストサービスデバイスクライアントのDashゲートウェイにも送信され得る。

マルチキャストサービスデバイスクライアントのストリーミング機能は、少なくとも1つのセグメントが受信されると、セグメント受信時間の指示をマルチキャストサービスデバイスクライアントのサービス発見機能に送信することができ、マルチキャストサービスデバイスクライアントのサービス発見機能は、調整された利用可能時間によってMPDを調整することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、修正されたMPDをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送信することができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。

アプリケーション/DASHクライアントは、メディアプレーヤーを起動し、メディアプレーヤーを修正されたMPDのURLに向けることができる。アプリケーション/DASHクライアントは、修正されたMPD URLにおいて修正されたMPDに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、修正されたMPDによって応答することができる。アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。アプリケーション/DASHクライアントは、セグメントN-1に対するHTTP GET()要求を送信することができる。セグメントN-1は利用可能ではないことがあり、マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントが見つからなかったと応答し得る(たとえば、404 Not Found)。アプリケーション/DASHクライアントは、セグメントN+1に対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントN+1によって応答することができる。

図14は、別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。図14に示される対話は、図14ではマルチキャストサービスデバイスクライアントがMPDを修正できないことを除き、図13に関して上で説明されたものと同様である。むしろ、マルチキャストサービスデバイスクライアントは、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに対して実際に利用可能になる時間ように、MPD中の利用可能時間を移すために使用され得る遅延調整の指示を含む、遅延調整メッセージを生成することができる。

図14に示される実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能は、少なくとも1つのセグメントが受信されると、セグメント受信時間の指示をマルチキャストサービスデバイスクライアントのサービス発見機能に送信することができ、マルチキャストサービスデバイスクライアントのサービス発見機能は、遅延調整の指示を含む遅延調整メッセージを生成することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、MPDおよび遅延調整メッセージをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送信することができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。

アプリケーション/DASHクライアントは、メディアプレーヤーを起動し、メディアプレーヤーをMPDのURLおよび遅延調整メッセージのURLに向けることができる。アプリケーション/DASHクライアントは、MPD URLにおいてMPDに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、MPDによって応答することができる。アプリケーション/DASHクライアントは、遅延調整URLにおいて遅延調整メッセージに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、遅延調整によって応答することができる。アプリケーション/DASHクライアントは、遅延調整メッセージを使用して、MPD中のセグメントの利用可能時間を移すことができる。移されたセグメント利用可能時間に基づいて、アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。移された利用可能時間に基づいて、アプリケーション/DASHクライアントは、セグメントN-1に対するHTTP GET()要求を送信することができる。セグメントN-1は利用可能ではないことがあり、マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントが見つからなかったと応答し得る(たとえば、404 Not Found)。移された利用可能時間に基づいて、アプリケーション/DASHクライアントは、セグメントN+1に対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントN+1によって応答することができる。

図15は、マルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの間の対話を示すメッセージフロー図である。図15に示される対話は、図15ではマルチキャストサービスデバイスクライアントがMPDを修正できないことを除き、図13に関して上で説明されたものと同様である。むしろ、マルチキャストサービスデバイスクライアントは、第1のセグメントの受信時間をアプリケーション/DASHクライアントに示すことができ、アプリケーション/DASHクライアントは、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに対して実際に利用可能になる時間ように、MPD中の利用可能時間を移すために使用され得る遅延調整を決定することができる。

図15に示される実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能は、少なくとも1つのセグメントが受信されると、セグメント受信時間の指示をアプリケーション/DASHクライアントに送信することができ、アプリケーション/DASHクライアントは、受信機デバイス上で受信されるセグメントの利用可能時間に対する遅延調整を決定することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、MPDをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送信することができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。

アプリケーション/DASHクライアントは、メディアプレーヤーを起動し、メディアプレーヤーをMPDのURLに向けることができる。アプリケーション/DASHクライアントは、MPD URLにおいてMPDに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、MPDによって応答することができる。アプリケーション/DASHクライアントは、決定された遅延調整を使用して、MPD中のセグメントの利用可能時間を移すことができる。移された利用可能時間に基づいて、アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。移された利用可能時間に基づいて、アプリケーション/DASHクライアントは、セグメントN-1に対するHTTP GET()要求を送信することができる。セグメントN-1は利用可能ではないことがあり、マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントが見つからなかったと応答し得る(たとえば、404 Not Found)。移された利用可能時間に基づいて、アプリケーション/DASHクライアントは、セグメントN+1に対するHTTP GET()要求を送信することができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントN+1によって応答することができる。

様々な実施形態は、種々のモバイルデバイス(すなわち、受信機デバイス)のいずれでも実装されてよく、その一例が図16に示される。たとえば、モバイルデバイス1600は、内部メモリ1604および1610に結合されたプロセッサ1602を含み得る。内部メモリ1604および1610は、揮発性メモリまたは不揮発性メモリであってよく、また、セキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、またはそれらの任意の組合せであってよい。また、プロセッサ1602は、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンディスプレイ1606に結合され得る。加えて、モバイルデバイス1600のディスプレイは、タッチスクリーン機能を有する必要はない。加えて、モバイルデバイス1600は、プロセッサ1602に結合されたワイヤレスデータリンクおよび/またはセルラー(たとえば、CDMA、TDMA、GSM、PCS、3G、4G、LTE、または任意の他のタイプの)送受信機のような、1つまたは複数のネットワーク送受信機1616に接続され得る電磁放射を送信し受信するための1つまたは複数のアンテナ1608を有し得る。モバイルデバイス1600はまた、ユーザ入力を受け取るための物理ボタン1612aおよび1612bを含み得る。モバイルデバイス1600はまた、モバイルデバイス1600をオンオフするための電源ボタン1618を含み得る。

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

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

上述の方法の説明およびプロセスフロー図は、単に説明のための例として提供されており、様々な実施形態のステップが提示された順序で実行されなければならないことを要求または暗示することは意図されない。当業者によって諒解されるように、上記の実施形態におけるステップの順序は、任意の順序で実行され得る。「その後」、「次いで」、「次に」などの言葉は、ステップの順序を限定するものではなく、これらの言葉は単に、本方法の説明全体で読者を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する単数形での請求要素への任意の言及は、その要素を単数に限定するものとして解釈されるべきではない。

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

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

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

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

100 セルラーネットワークシステム
102 受信機デバイス
104 基地局
106 セルラー接続
108 コンテンツプロバイダ
110 インターネット
112 BMSC
202 受信機デバイス
204 アプリケーション/DASHクライアント
206 マルチキャストサービスデバイスクライアント(MSDC)
208 モデム
302 エンコーダ
304 BMSC
306 MSDC
308 DASHクライアント
310 エンコーダ利用可能時間を伴うMPD
312 OTA利用可能性を伴うMPD
314 デバイス利用可能性を伴うMPD
316 遅延調整メッセージ
1600 モバイルデバイス
1602 プロセッサ
1604 内部メモリ
1606 タッチスクリーンディスプレイ
1608 アンテナ
1610 内部メモリ
1612a 物理ボタン
1612b 物理ボタン
1616 ネットワーク送受信機
1618 電源ボタン
1700 サーバ
1701 プロセッサ
1702 揮発性メモリ
1703 ネットワーク送受信機
1704 ディスクドライブ
1706 CDまたはDVDディスクドライブ
1707 通信ネットワーク

Claims (36)

1. 受信機デバイス上でのデータセグメントの利用可能性の変動性に対応するための方法であって、
   前記受信機デバイスにおいてセグメント利用可能性タイムラインを受信するステップであって、前記受信されたセグメント利用可能性タイムラインが利用可能時間を含む、ステップと、
   前記受信機デバイスにおいて遅延調整を決定するステップと、
   前記受信機デバイスのメモリに前記遅延調整を記憶するステップとを含む、方法。
2. 前記受信機デバイスにおいて、前記遅延調整の分だけ前記利用可能時間を移すステップをさらに含む、請求項1に記載の方法。
3. 前記受信機デバイスにおいて前記遅延調整の分だけ前記利用可能時間を移すステップが、前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、前記受信機デバイスにおいて修正されたセグメント利用可能性タイムラインを生成するステップを含み、前記方法が、
   前記受信機デバイスのメモリに前記修正されたセグメント利用可能性タイムラインを記憶するステップをさらに含む、請求項2に記載の方法。
4. 前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、前記受信機デバイスにおいて修正されたセグメント利用可能性タイムラインを生成するステップが、前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、前記受信機デバイスのサービスレイヤにおいて修正されたセグメント利用可能性タイムラインを生成するステップを含む、請求項3に記載の方法。
5. 前記受信機デバイスの前記サービスレイヤがマルチキャストサービスデバイスクライアントである、請求項4に記載の方法。
6. 前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、前記受信機デバイスにおいて修正されたセグメント利用可能性タイムラインを生成するステップが、前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、前記受信機デバイスのDynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)クライアントにおいて修正されたセグメント利用可能性タイムラインを生成するステップを含む、請求項3に記載の方法。
7. 前記受信機デバイスにおいて前記遅延調整の分だけ前記利用可能時間を移すステップが、前記受信機デバイスのクライアントアプリケーションにおいて、前記遅延調整の分だけ前記利用可能時間を移すステップを含む、請求項2に記載の方法。
8. 前記受信機デバイスの前記クライアントアプリケーションにおいて前記遅延調整の分だけ前記利用可能時間を移すステップが、前記受信機デバイスの前記クライアントアプリケーションにおいて、前記遅延調整の分だけ前記セグメント利用可能性タイムラインの外側に前記利用可能時間を移すステップを含む、請求項7に記載の方法。
9. 前記受信機デバイスの前記クライアントアプリケーションにおいて前記遅延調整の分だけ前記利用可能時間を移すステップが、前記受信機デバイスの前記クライアントアプリケーションにおいて、前記遅延調整の分だけ前記セグメント利用可能性タイムラインの中に前記利用可能時間を移して、修正されたセグメント利用可能性タイムラインを生成するステップを含む、請求項7に記載の方法。
10. 前記クライアントアプリケーションが、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH)クライアントアプリケーションである、請求項7に記載の方法。
11. 前記受信機デバイスにおいて遅延調整を決定するステップが、前記受信機デバイスによって受信されるセグメントを前記受信機デバイス上でサーバに対して利用可能にする際の処理遅延に少なくとも一部基づく、請求項1に記載の方法。
12. 前記受信機デバイスにおいて遅延調整を決定するステップが、前記受信機デバイスによって受信されるセグメントを前記受信機デバイス上でサーバに対して利用可能にする際の処理遅延と、受信機デバイスの時計のずれのマージンとに少なくとも一部基づく、請求項1に記載の方法。
13. 前記受信機デバイスにおいて遅延調整を決定するステップが、
    前記受信機デバイスに対する基本処理遅延を決定するステップと、
    前記受信機デバイスに対するセグメント処理係数を決定するステップと、
    前記セグメント利用可能性タイムラインに記載されたセグメントのセグメント期間を決定するステップと、
    前記受信機デバイスの前記基本処理遅延と、前記セグメント処理係数を乗算した前記セグメント期間との和として、前記遅延調整を決定するステップとを含む、請求項1に記載の方法。
14. 前記受信機デバイスにおいて遅延調整を決定するステップが、
    第1のセグメントの復号完了時間を決定するステップと、
    遅延マージンと前記第1のセグメントの前記復号完了時間との和として、前記第1のセグメントの調整された利用可能時間を決定するステップと、
    前記第1のセグメントの前記調整された利用可能時間と、前記セグメント利用可能性タイムライン中の前記第1のセグメントの利用可能時間との差として、前記遅延調整を決定するステップとを含む、請求項1に記載の方法。
15. 前記遅延マージンが、第1のセグメント利用可能時間を、前記第1のセグメントの前記復号完了時間に設定し、すべての後続のセグメントの利用可能時間を、先行するセグメントの前記利用可能時間とセグメント期間との和に設定することによって構築される利用可能性タイムラインを、セグメントの到達時間の差の最大の変動から引いたものであり、
    前記遅延マージンが、前記受信機デバイスに対して事前に準備される、請求項14に記載の方法。
16. 前記遅延マージンが、エンドツーエンドのシステム試験に基づいて決定されるか、または、解析的な分析に基づいて決定される、請求項15に記載の方法。
17. 前記受信機デバイスにおいて遅延調整を決定するステップが、
    前記受信機デバイスにおいてセグメントの第1のパケットの受信時間を決定するステップと、
    前記第1のパケットの前記受信時間として基準時間を決定するステップと、
    前記基準時間と遅延マージンとの和として、第1のセグメントの調整された利用可能時間を決定するステップと、
    前記第1のセグメントの前記調整された利用可能時間と、前記セグメント利用可能性タイムライン中の前記第1のセグメントの利用可能時間との差として、前記遅延調整を決定するステップとを含む、請求項1に記載の方法。
18. 前記受信機デバイスにおけるセグメントの第1のパケットの受信時間を決定するステップが、第1のセグメントが記載されている第1のFile Delivery Over Unidirectional Transport(「FLUTE」)ファイル配信テーブルの受信時間を決定するステップを含む、請求項17に記載の方法。
19. 前記遅延マージンが、第1のセグメント利用可能時間を前記第1のパケットの前記受信時間に設定し、すべての後続のセグメントの利用可能時間を先行するセグメントの前記利用可能時間とセグメント期間との和に設定することによって構築される利用可能性タイムラインを、セグメントの復号時間の差の最大の変動から引いたものであり、
    前記遅延マージンが、前記受信機デバイスに対して事前に準備される、請求項17に記載の方法。
20. 前記遅延マージンが、エンドツーエンドのシステム試験に基づいて決定されるか、または、解析的な分析に基づいて決定される、請求項19に記載の方法。
21. 前記受信機デバイスにおいて遅延調整を決定するステップがビデオセグメントのみに基づく、請求項1に記載の方法。
22. 前記セグメント利用可能性タイムラインがネットワークジッタの値を含み、
    前記受信機デバイスにおいて遅延調整を決定するステップが、前記含まれるネットワークジッタの値に少なくとも一部基づいて遅延調整を決定するステップを含む、請求項1に記載の方法。
23. 前記受信機デバイスにおいて遅延調整を決定するステップが、前記受信機デバイスのメモリに記憶されるネットワークジッタの値に少なくとも一部基づいて遅延調整を決定するステップを含む、請求項1に記載の方法。
24. 前記受信機デバイスにおいてネットワークジッタの値を受信するステップをさらに含み、
    前記受信機デバイスにおいて遅延調整を決定するステップが、前記受信されたネットワークジッタの値に少なくとも一部基づいて遅延調整を決定するステップを含む、請求項1に記載の方法。
25. 前記受信機デバイスにおいてネットワークジッタの値を受信するステップが、User Service Description中で前記受信機デバイスにおいてネットワークジッタの値を受信するステップを含む、請求項24に記載の方法。
26. ネットワークジッタの値を計算するステップをさらに含み、
    前記受信機デバイスにおいて遅延調整を決定するステップが、前記計算されたネットワークジッタの値に少なくとも一部基づいて遅延調整を決定するステップを含む、請求項1に記載の方法。
27. 前記受信されたセグメント利用可能性タイムラインが、Dynamic Adaptive Streaming Over Hypertext Transfer Protocol(DASH) Media Presentation Description(MPD)である、請求項1に記載の方法。
28. メモリと、
    前記メモリに結合され、請求項1から27のいずれか一項に記載の方法を実行するためのプロセッサ実行可能命令によって構成される、プロセッサとを含む、受信機デバイス。
29. 受信機デバイスのプロセッサに、請求項1から27のいずれか一項に記載の方法を実行させるためのプロセッサ実行可能命令によって構成される、非一時的プロセッサ可読媒体。
30. セグメント利用可能性タイムラインを受信するための手段であって、前記受信されたセグメント利用可能性タイムラインが利用可能時間を含む、手段と、
    遅延調整を決定するための手段と、
    前記遅延調整を記憶するための手段と、
    前記遅延調整の分だけ前記利用可能時間を移すための手段とを含む、受信機デバイス。
31. 前記遅延調整の分だけ前記利用可能時間を移すための手段が、前記セグメント利用可能性タイムライン内の前記利用可能時間を前記遅延調整の分だけ移して、修正されたセグメント利用可能性タイムラインを生成するための手段を含み、前記受信機デバイスが、
    前記修正されたセグメント利用可能性タイムラインを記憶するための手段をさらに含む、請求項30に記載の受信機デバイス。
32. 前記遅延調整の分だけ前記利用可能時間を移すための手段が、クライアントアプリケーションにおいて前記遅延調整の分だけ前記利用可能時間を移すための手段を含む、請求項30に記載の受信機デバイス。
33. 遅延調整を決定するための手段が、
    前記受信機デバイスに対する基本処理遅延を決定するための手段と、
    前記受信機デバイスに対するセグメント処理係数を決定するための手段と、
    前記セグメント利用可能性タイムラインに記載されたセグメントのセグメント期間を決定するための手段と、
    前記受信機デバイスの前記基本処理遅延と、前記セグメント処理係数を乗算した前記セグメント期間との和として、前記遅延調整を決定するための手段とを含む、請求項30に記載の受信機デバイス。
34. 遅延調整を決定するための手段が、
    第1のセグメントの復号完了時間を決定するための手段と、
    遅延マージンと前記第1のセグメントの前記復号完了時間との和として、前記第1のセグメントの調整された利用可能時間を決定するための手段と、
    前記第1のセグメントの前記調整された利用可能時間と、前記セグメント利用可能性タイムライン中の前記第1のセグメントの利用可能時間との差として、前記遅延調整を決定するための手段とを含む、請求項30に記載の受信機デバイス。
35. 遅延調整を決定するための手段が、
    前記受信機デバイスにおいてセグメントの第1のパケットの受信時間を決定するための手段と、
    前記第1のパケットの前記受信時間として基準時間を決定するための手段と、
    前記基準時間と遅延マージンとの和として、第1のセグメントの調整された利用可能時間を決定するための手段と、
    前記第1のセグメントの前記調整された利用可能時間と、前記セグメント利用可能性タイムライン中の前記第1のセグメントの利用可能時間との差として、前記遅延調整を決定するための手段とを含む、請求項30に記載の受信機デバイス。
36. 前記セグメント利用可能性タイムラインがネットワークジッタの値を含み、
    遅延調整を決定するための手段が、前記含まれるネットワークジッタの値に少なくとも一部基づいて遅延調整を決定するための手段を含む、請求項30に記載の受信機デバイス。