(57)【要約】  様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが修正されたセグメント利用可能時間を使用することを可能にする。様々な実施形態では、受信機デバイスは、セグメントがDASHクライアントに利用可能になるとき、実際の時間を考慮するために、メディアプレゼンテーション記述(MPD)など、セグメント利用可能性タイムライン内のセグメントに対する利用可能開始時間を修正することが可能にされ得る。
2018519694.tif 000002
【特許請求の範囲】
【請求項１】
受信機デバイスのタイミングドリフトを考慮するための方法であって、
ユニフォームリソース識別子(URL)マッチングによってセグメントのインデックスを決定するステップと、
利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定するステップと、
前記利用可能性タイムラインからセグメント持続時間を決定するステップと、
前記セグメントに関する復号時間を決定するステップと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定するステップと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
を含む、方法。
【請求項２】
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定するステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定するステップを含み、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始開始時間の再計算を前記トリガするステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始開始時間の再計算をトリガするステップを含む
請求項1に記載の方法。
【請求項３】
前記セグメント持続時間の前記比率が2分の1である、請求項2に記載の方法。
【請求項４】
前記受信機デバイスにおいて2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定するステップをさらに含み、
前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定するステップが、前記受信機デバイスにおける前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定するステップを含む
請求項1に記載の方法。
【請求項５】
前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項4に記載の方法。
【請求項６】
受信機デバイスのタイミングドリフトを考慮するための方法であって、
ユニフォームリソース識別子(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定するステップと、
前記受信されたセグメントから生じる利用可能開始時間の変更を決定するステップと、
前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定するステップと、
前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
を含む、方法。
【請求項７】
前記しきい値がセグメント持続時間である、請求項6に記載の方法。
【請求項８】
利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項7に記載の方法。
【請求項９】
受信機デバイスであって、
動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
ユニフォームリソース識別子(URL)マッチングによってセグメントのインデックスを決定することと、
利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定することと、
前記利用可能性タイムラインからセグメント持続時間を決定することと、
前記セグメントに関する復号時間を決定することと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定することと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
を含む、受信機デバイス。
【請求項１０】
前記プロセッサが、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定することが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定することを含み、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算を前記トリガすることが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることを含む
ような動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載の受信機デバイス。
【請求項１１】
前記セグメント持続時間の前記比率が2分の1である、請求項10に記載の受信機デバイス。
【請求項１２】
前記プロセッサが、2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定することをさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
前記プロセッサが、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定することが、前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定することを含むような動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載の受信機デバイス。
【請求項１３】
前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項12に記載の受信機デバイス。
【請求項１４】
受信機デバイスであって、
動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
ユニフォームリソース識別子(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定することと、
前記受信されたセグメントから生じる利用可能開始時間の変更を決定することと、
前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定することと、
前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
を含む、受信機デバイス。
【請求項１５】
前記しきい値がセグメント持続時間である、請求項14に記載の受信機デバイス。
【請求項１６】
利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項15に記載の受信機デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、2015年4月20日に出願した「Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast」という表題の米国仮特許出願第62/149,776号の優先権の利益を主張し、この仮特許出願の内容全体が参照によって本明細書に組み込まれる。
【背景技術】
【０００２】
ハイパーテキスト転送プロトコル(HTTP)ストリーミングは現在、インターネットを通じてコンテンツを配信する最も一般的な方法である。生のイベントでは、コンテンツは、一定の持続時間のセグメントを通じて徐々に利用可能にされる。セグメントの利用可能性は、各々の連続するセグメントがHTTPサーバにおいていつ利用可能になるかを示す、タイムラインに従う。
【０００３】
動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH:Dynamic Adaptive Streaming Over Hypertext Transfer Protocol)は、HTTPストリーミングを実装する規格である。DASHは、メディアプレゼンテーション記述(MPD:Media Presentation Description)内でセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。
【０００４】
現在のシステムでは、MPDは、オーバージエア(OTA)配信を介して受信機デバイスに提供される。提供されたMPD内で、セグメント利用可能開始時間は、セグメントを生成するネットワーク側エンコーダのエンコーダ出力時間に対応し得る。セグメント利用可能開始時間はエンコーダ出力時間に対応し得るので、利用可能開始時間は、配信経路の遅延、受信機デバイスの処理遅延、または受信機デバイスのクロックドリフトのような、受信機デバイス上で実行されるDASHクライアントに対する実際のセグメントの利用可能性の差を考慮しないことがある。したがって、現在のMPD内で告知される利用可能開始時間は、セグメントがDASHクライアントに対して利用可能となる実際の時間に対応しないことがある。
【発明の概要】
【課題を解決するための手段】
【０００５】
様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが修正されたセグメント利用可能時間を使用することを可能にする。様々な実施形態では、受信機デバイスは、セグメントがDASHクライアントに利用可能になるとき、実際の時間を考慮するために、メディアプレゼンテーション記述(MPD)など、セグメント利用可能性タイムライン内のセグメントに対する利用可能開始時間を修正することが可能にされ得る。
【０００６】
いくつかの実施形態では、受信機デバイスのタイミングドリフトを考慮するための方法は、URLマッチングによってセグメントインデックスを決定するステップと、利用可能性タイムライン内のマッチング期間および表現結合に基づいて、セグメントの利用可能開始時間を決定するステップと、利用可能性タイムラインからセグメント持続時間を決定するステップと、セグメントに関する復号時間を決定するステップと、セグメントに関する復号時間からセグメントの利用可能開始時間を減じたものがセグメント持続時間の比率よりも大きいかどうかを決定するステップと、セグメントに関する復号時間からセグメントの利用可能開始時間を減じたものがセグメント持続時間の比率よりも大きいとの決定に応じて、利用可能開始時間の再計算をトリガするステップとを含み得る。
【０００７】
いくつかの実施形態では、受信機デバイスのタイミングドリフトを考慮するための方法は、URLマッチングによって、受信されたセグメントに関するセグメントインデックスを決定するステップと、受信されたセグメントから生じる利用可能開始時間の変更を決定するステップと、利用可能開始時間の変更がしきい値よりも大きいかどうかを決定するステップと、利用可能開始時間の変更がしきい値よりも大きいとの決定に応じて、利用可能開始時間再計算をトリガするステップとを含み得る。
【０００８】
さらなる実施形態は、上記で要約したいずれかの方法の動作を実行するように構成されたプロセッサを備えた受信機デバイスを含み得る。
【０００９】
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の例示的な実施形態を示し、上記の一般的な説明および以下の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。
【図面の簡単な説明】
【００１０】
【図１】様々な実施形態とともに使用するのに好適なネットワークの通信システムブロック図である。
【図２】一実施形態による受信機デバイスのアーキテクチャを示すブロック図である。
【図３Ａ】一実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。
【図３Ｂ】別の実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。
【図４】一実施形態による、ネットワークの種々の部分における配信経路遅延間の関係を示す図である。
【図５Ａ】決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。
【図５Ｂ】決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。
【図６Ａ】決定された第1のFDT受信時間に基づくベースURL変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。
【図６Ｂ】決定された第1のFDT受信時間に基づくベースURL変更に応じて、遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。
【図７】一実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す図である。
【図８Ａ】いずれかの決定されたFDT受信時間に基づいてユニキャストモードでセグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。
【図８Ｂ】いずれかの決定されたFDT受信時間に基づいてユニキャストモードで遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。
【図９Ａ】一実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。
【図９Ｂ】別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。
【図１０】遅延調整メッセージに基づいて利用可能開始時間を調整するための一実施形態の方法を示すプロセスフロー図である。
【図１１Ａ】MPD更新を処理するための一実施形態方法を示すプロセスフロー図である。
【図１１Ｂ】MPD更新を処理するための別の実施形態方法を示すプロセスフロー図である。
【図１２】別の実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す図である。
【図１３】受信機デバイスタイミングドリフトを考慮するための一実施形態の方法を示すプロセスフロー図である。
【図１４】失敗したHTTP記録をマークするための一実施形態の方法を示すプロセスフロー図である。
【図１５Ａ】受信機デバイスタイミングドリフトを考慮するための別の実施形態の方法を示すプロセスフロー図である。
【図１５Ｂ】受信機デバイスタイミングドリフトを考慮するための第3の実施形態の方法を示すプロセスフロー図である。
【図１６】URLマッチングによってセグメントインデックスを決定するための一実施形態の方法を示すプロセスフロー図である。
【図１７Ａ】一実施形態による例示的なMPDの要素のブロック図である。
【図１７Ｂ】一実施形態による例示的なMPDの要素のブロック図である。
【図１７Ｃ】一実施形態による例示的なMPDの要素のブロック図である。
【図１８】一実施形態による例示的なMPDのXMLツリーのブロック図である。
【図１９】一例よるセグメントの利用可能性タイムラインを示す図である。
【図２０】一実施形態による単一のセグメント持続時間MPDの例示的なスキーマ部分を示す図である。
【図２１】一実施形態による、MPDをクロールし、期間および表現結合(period and representation couples)内のURLをマッチさせる様々な結果を示すブロック図である。
【図２２】一実施形態によるセグメントの利用可能性タイムラインを示す図である。
【図２３】一実施形態による2セグメント持続時間MPDの例示的なスキーマ部分を示す図である。
【図２４】別の実施形態による、MPDをクロールし、期間および表現結合内のURLをマッチさせる様々な結果を示すブロック図である。
【図２５】URLマッチングによってセグメントインデックスを決定するための別の実施形態の方法を示すプロセスフロー図である。
【図２６】一実施形態による反復セグメントの利用可能性タイムラインを示す図である。
【図２７】URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための一実施形態の方法を示すプロセスフロー図である。
【図２８】URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための別の実施形態の方法を示すプロセスフロー図である。
【図２９】URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための第3の実施形態の方法を示すプロセスフロー図である。
【図３０】様々な実施形態とともに使用するのに好適な例示的なモバイルデバイスの構成要素図である。
【図３１】様々な実施形態とともに使用するのに好適な例示的なサーバの構成要素図である。
【発明を実施するための形態】
【００１１】
添付の図面を参照して、様々な実施形態が詳細に説明される。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。具体的な例および実装形態への言及は説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。
【００１２】
様々な実施形態は、受信機デバイスが、受信機デバイス上で使用するために、データストリーム中のデータセグメントの利用可能性(「セグメント利用可能性」)の遅延を考慮することを可能にする。一実施形態では、受信機デバイスは、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出す動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)クライアント)に対して利用可能になる実際の時間に基づいて修正されたメディアプレゼンテーション記述(MPD)の列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)サーバからオーバージエア(OTA)で受信されるMPD)中の利用可能開始時間を調整することができる。様々な実施形態は、ネットワークおよび受信機デバイスのクロックが同期されているときまたは同期されていないときに、修正されたMPDが生成されることを可能にし得る。
【００１３】
「例示的な」という単語は、本明細書では、「例、実例、または例証として機能する」を意味するために使用される。「例示的な」として本明細書で説明するいかなる実装形態も、他の実装形態よりも好ましいか、または有利であると必ずしも解釈されるべきでない。
【００１４】
本明細書で使用される場合、「モバイルデバイス」および「受信機デバイス」という用語は、セルラー電話、スマートフォン、個人用マルチメディアプレーヤまたはモバイルマルチメディアプレーヤ、携帯情報端末(PDA)、ラップトップコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応セルラー電話、ワイヤレスゲームコントローラ、スマートテレビジョン、セットトップボックス、デジタルビデオレコーダ(DVR)、および、MPDを受信しMPDをDASHクライアントに対して利用可能にするためのプログラム可能プロセッサとメモリと回路とを含む同様の個人用電子デバイスの、いずれか1つまたはすべてを指すように、本明細書において交換可能に使用される。
【００１５】
DASHはHTTPストリーミングを実装する規格である。DASHは、MPD内でセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。現在のシステムでは、MPDは、OTA配信を介して受信機デバイスに提供される。第3世代パートナーシッププロジェクト(3GPP)は、ロングタームエボリューション(LTE)(すなわち、発展型マルチメディアブロードキャストマルチキャストサービス(eMBMS:evolved Multimedia Broadcast Multicast Services))を通じたブロードキャスト使用してHTTPストリーミングを提供するために使用されるべき方法として、ダウンロード配信を通じたDASHを標準化した。
【００１６】
異なるアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルの様々な例、特に、DASHクライアント、マルチキャストサービスデバイスクライアント(MSDC)、MPD、eMBMS、およびHTTPについて本明細書で論じる。DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPの議論は、様々な実施形態の態様をより良好に示すための例としてのみ与えられ、いかなる方法でも様々な実施形態を限定することは意図されない。他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、様々な実施形態とともに使用されてもよく、他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、本発明の趣旨または範囲から逸脱することなく、様々な例において置換されてもよい。
【００１７】
一実施形態では、受信機デバイスは、受信機デバイス上のクライアントアプリケーションに対するセグメントの利用可能性の遅延を考慮するように、遅延調整値を決定することができる。一実施形態では、遅延調整値は遅延調整メッセージ内で提供され得る。遅延調整メッセージは、遅延調整値を含むファイルのような、遅延調整値のパラメータおよび/または指示であり得る。一実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDの列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、BMSCサーバからOTAで受信されるMPD)など、セグメント利用可能性を記述するマニフェストファイル内の利用可能開始時間を修正することを可能にし得る。様々な実施形態がセグメント利用可能性タイムラインおよび/またはMPDの点で論じられる場合があるが、セグメント利用可能性タイムラインおよび/またはMPDは、セグメント利用可能性を記述するマニフェストファイルの単なる例であり、本明細書で論じるセグメント利用可能性タイムラインおよび/またはMPDに関する様々な例において、セグメント利用可能性を記述するいずれのマニフェストファイルも置換され得る。様々な実施形態は、ネットワークおよび受信機デバイスのクロックが同期されているときまたは同期されていないときに、遅延調整メッセージおよび修正されたMPDが生成されることを可能にし得る。別の実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、セグメント利用可能性タイムライン自体を修正することなく、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいてセグメントに対するその要求のタイミングを調整することを可能にし得る。
【００１８】
様々な実施形態では、受信機デバイスプロセッサは、セグメントフラグメントが受信されるにつれて、セグメントフラグメントのセグメントインデックス番号またはベースユニフォームリソース識別子(URI)を監視し、連続的に受信されたセグメントのセグメントインデックス番号またはベースURIを互いと比較することができる。最近のセグメントフラグメントのセグメントインデックス番号またはベースURLが前のセグメントフラグメントのセグメントインデックス番号またはベースURIと異なる(たとえば、セグメントインデックス番号またはベースURIの変更が検出される)とき、最近のセグメントフラグメントは、タイムライン内の次のセグメントの第1のファイル配信オーバー単方向トランスポート(FLUTE:File Delivery Over Unidirectional Transport)ファイル配信テーブル(FDT)など、タイムライン内の次のセグメントの第1のパケットであり得る。受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、次のセグメントをベースセグメントとして識別することができ、第1のFDTなど、第1のパケットの到着時間を使用して、ライムライン内のベースセグメントの利用可能開始時間を修正し、修正された利用可能開始時間に基づいて、後続のセグメントに関するすべての後続の利用可能開始時間をシフトすることができる。このようにして、受信機デバイスプロセッサは、タイムライン内の利用可能開始時間(たとえば、MPD内のAST)を修正して、セグメントの実際の到着時間を考慮することができる。
【００１９】
様々な実施形態では、受信機デバイスプロセッサは、受信されたMPDをクロールし(たとえば、パースし)、すべての期間および表現ペアに対応するURLフォーマットを決定することができる。たとえば、URLフォーマットはフォーマット「XXX$number$YYY」であってよく、ここで、XXXはプレフィックスであり得、YYYはサフィックスであり得、$number$は、セグメントのインデックス番号(たとえば、DASH内のセグメント番号)であり得る。受信機デバイスプロセッサは、この情報を使用して、まず、受信されたセグメントのURLが特定の期間および表現ペアのセグメントURLフォーマットにマッチするかどうかを決定し、次いで、セグメント番号を決定することができる。受信機デバイスプロセッサは、セグメント番号がその期間および表現ペアに対応するセグメントをもたらすかどうかを決定することもでき、実際のセグメント番号を決定することができる。セグメント番号が決定されると、受信機デバイスプロセッサは、そのセグメント番号を前に検出されたセグメント番号と比較することができる。一実施形態では、URLフォーマットは番号ベースのURL方式であってよい。さらなる実施形態では、ベースURLは常に絶対URLであってよい。一実施形態では、利用可能時間計算に調整を加えることによって、baseURL@availabilityTimeOffsetがサポートされ得る。一実施形態では、URLフォーマットまたはURLテンプレートは、セグメント番号ベースではなく、時間ベースであり得る。たとえば、同じ時間持続時間に対応するオーディオセグメントおよびビデオセグメントは、テンプレート内に同じ$time$タグを有し得る。受信機デバイスプロセッサは、各着信セグメントの利用可能開始時間を決定し、各着信セグメントの利用可能開始時間の変更に基づいてベースセグメントを決定することができる。
【００２０】
様々な実施形態では、ベースセグメントの修正された利用可能開始時間は、第1のFDT到着時間+(セグメントごとのセグメントフラグメント(SF)数×マルチキャストチャネル(MCH)スケジューリング期間(MSP))+マージン(M)、または修正された利用可能開始時間=第1のFDT到着時間+(SF*MSP)+Mとして決定され得る。一実施形態では、MSPの値は、受信機デバイスに対して事前プロビジョニングされたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前プロビジョニングされた値として構成され得る。一実施形態では、SFはセルセグメント持続時間/MSPに等しくてよい。SFは、エンコーダおよびブロードキャストシステムにおけるスケジューリング方法において生成されるセグメントサイズの可変性を考慮するために、乗法係数(たとえば、0.8、0.9、1.1、1.2など、1より小さいかまたは大きいが、値の点で0よりも大きい値)によって調整され得る。
【００２１】
様々な実施形態では、同じベアラ上で同時にブロードキャストされる、オーディオおよびビデオなどの複数の表現は、インデックス変更を識別して、セグメント利用可能開始時間を修正するための受信機デバイスプロセッサの能力に影響を与えない場合がある。いくつかの実施形態では、2つ以上の表現は、同じ開始インデックスおよび同じセグメント持続時間を有し得る。いくつかの実施形態では、2つ以上の表現は、異なる開始インデックスおよび/または異なるセグメント持続時間を有し得る。別個のオーディオ表現およびビデオ表現は、インデックス値を依然として含んでよく、2つのセグメントがオーディオおよび/またはビデオセグメントであるかどうかにかかわらず、受信機デバイスプロセッサは、次のセグメントのFDT到着時間を追跡するための指示として、インデックス値変更を処理することができる。
【００２２】
一実施形態では、受信機デバイスプロセッサは、セグメントフラグメントが受信されるにつれて、セグメントフラグメントのセグメント利用可能時間を監視し、連続的に受信されたセグメントのセグメント利用可能開始時間を互いと比較することができる。最近のセグメントフラグメントのセグメント利用可能開始時間が前のセグメントフラグメントのセグメント利用可能開始時間と異なるとき、最近のセグメントフラグメントは、タイムライン内の次のセグメントの第1のファイル配信オーバー単方向トランスポート(FLUTE)ファイル配信テーブル(FDT)であり得る。受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、次のセグメントをベースセグメントとして識別することができ、その第1のFDTの到着時間を使用して、ライムライン内のベースセグメントの利用可能開始時間を修正し、修正された利用可能開始時間に基づいて、後続のセグメントに関するすべての後続の利用可能開始時間をシフトすることができる。
【００２３】
一実施形態では、異なるブロードキャスト表現(たとえば、2sセグメント持続時間におけるオーディオおよび1sセグメント持続時間におけるビデオ)に対するセグメント持続時間が異なるとき、受信機デバイスプロセッサは、調整値を決定するためにのみビデオ表現を使用することができる。受信機デバイスプロセッサは、表現にわたってより高いセグメント持続時間を使用して、その利用可能性が整合され得、かつ同じ計算を適用することができるスーパーセグメントを決定することもできる。受信機デバイスプロセッサは、セグメント持続時間が互いの倍数であるときに調整値を決定するためのみビデオ表現を使用することができる。受信機デバイスプロセッサは、セグメント持続時間が互いの倍数でないとき、セグメント持続時間の最低共通倍数を使用することができる。
【００２４】
様々な実施形態では、受信機デバイスプロセッサが、ユニキャストフェッチがアクティブであると決定するとき、受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、受信機デバイスにおいて受信されたいずれかのセグメントのいずれかのFDTの受信時間を決定することができ、FDTの受信時間に基づいて、そのセグメントの利用可能開始時間を修正することができる。このようにして、次のセグメントが受信されることまたはセグメントインデックス変更を待たずに、MPD内の利用可能時間を速やかにシフトすることができ、より厳密なタイムラインを活用して、より早期にユニキャストを通してセグメント要求するためにユニキャストフェッチが使用されることを可能にし得る。セグメントを記述する第1のブロードキャストFDTに基づいて利用可能性タイムラインを設定することは、セグメントを記述するいずれかのFDTを使用して決定されたタイムラインよりもより厳密なタイムラインを確実にすることができる。たとえば、セグメントを記述する最後のFDTは、概算的に、そのセグメントを記述する第1のFDTよりも遅いセグメント持続時間であり得、セグメント利用可能開始時間を設定するためにそれを使用することは、同じ持続時間の分だけ、セグメントの利用可能性を遅延させ得る。したがって、FDTに遭遇するとすぐにMPDが利用可能にされ得、次のセグメントが受信されることまたはセグメントインデックス変更を待つよりも早期に開始するようにプレイアウトすることを可能にする。一実施形態では、第1の1つまたは複数のセグメントはユニキャストを通してフェッチされ得る。
【００２５】
DASH規格単位のメディアセグメントの利用可能時間は、MPDの利用可能開始時間(AST)(たとえば、MPD内で記述されるすべてのセグメントの利用可能性に関するアンカータイム(anchor time)を表すMPD要素「MPD@availabilityStartTime」内に示された時間)+含有期間のPeriodStart時間+メディアセグメントのMPD利用可能開始時間(AST)(たとえば、そのセグメント自体のAST)+セグメント持続時間の値として決定され得る。様々な実施形態では、識別されたベースセグメントのURIに基づいて、受信機デバイスプロセッサ(たとえば、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、MPD内のすべての残りのセグメントの対応する利用可能開始時間を決定することができる。一実施形態では、受信機デバイスプロセッサは、第1のFDT到着時間に基づいて決定されたベースセグメントの修正された利用可能開始時間に基づいて、MPDの利用可能開始時間(AST)を修正することができる。たとえば、MPDのASTは、ベースセグメントの期間((セグメント持続時間)×(セグメント数-開始セグメント数))内の修正された利用可能開始時間-PeriodStart時間-利用可能開始時間に等しくなるように修正され得る。様々な実施形態では、前のMPDと同じASTを有するMPD更新を受信するとすぐに、受信機デバイスプロセッサは、前のMPDに関して決定された、修正されたASTにマッチするように、MPD更新のASTを調整することができる。様々な実施形態では、前のMPDとは異なるASTを有するMPD更新を受信するとすぐに、受信機デバイスプロセッサは、第1のFDT到着時間に基づいて決定されたベースセグメントの修正された利用可能開始時間を使用して、MPD更新のASTを調整することができる。様々な実施形態では、異なるASTを有するMPD更新の受信は、新しい利用可能開始時間決定をトリガし得る。
【００２６】
別の実施形態では、受信機デバイスプロセッサは、受信されたセグメントに対応するbaseURL要素のsegmentAvailabilityOffset属性を調整することができる。segmentAvailabilityOffsetパラメータは、計算された利用可能開始時間を修正することができ、利用可能開始時間の代わりに自ら調整され得る。
【００２７】
様々な実施形態では、受信機デバイスプロセッサは、ベースセグメントを2つの異なる期間および表現ペアにマッチさせることができる。正確なマッチはより小さないタイムライン調整をもたらす期間および表現ペアであり得るが、これは、その期間および表現ペアはライブストリーミングシステムにおけるタイムライン調整である可能性が高い場合がある。
【００２８】
様々な実施形態では、受信機デバイスにおけるタイミングドリフトを追跡することができ、タイミングドリフトの検出に応じて、受信機デバイスプロセッサはそのMPDに関する新しい利用可能開始時間を決定することができる。様々な実施形態では、受信機デバイスプロセッサ(たとえば、受信機デバイスプロセッサ上で実行されるマルチキャストサービスデバイスクライアント)によって、DASHクライアントによる失敗したHTTP要求に関連するセグメント番号またはセグメントURIを追跡することができる。セグメント番号またはセグメントURIが追跡されると、受信機デバイスプロセッサは、DASHクライアントによる各後続のHTTP要求が同じセグメント番号またはセグメントURIに関するか、または異なるセグメント番号またはセグメントURIに関するかを決定することができる。
【００２９】
異なるセグメント番号またはセグメントURIに対するHTTP要求を受信するとすぐに、受信機デバイスプロセッサは、失敗したHTTP要求が消去されたか、または依然として未解決であるかどうか、および要求されたセグメントが現在キャッシュ内に存在するかどうかを決定することができる。失敗したHTTP要求が依然として未解決であり、要求されたセグメントがキャッシュ内にあるとき、受信機デバイス上にタイミングドリフトが生じ、DASHクライアントがそのセグメントの要求を断念した可能性がある(すなわち、ドリフト条件が満たされた)後にそのセグメントを到着させる場合がある。タイミングドリフトが検出された(すなわち、ドリフト条件が満たされた)とき、利用可能開始時間を再計算することができ、タイミングドリフトを考慮するために、受信機デバイスはMPDを修正することができる。
【００３０】
一実施形態では、DASHクライアントが多数のHTTP要求を同時に発行するとき(たとえば、メディアストリームのラインエッジを決定するためのスタートアップ時に)セグメントの追跡を回避するために、セグメント持続時間の90%に等しい時間にわたってなど、次のセグメントの追跡を遅延させることができる。さらなる実施形態では、次のセグメント番号が現在の追跡されたセグメントよりも1つ大きいセグメントインデックスであるときのみ、ドリフト条件に対する検査を適用することができる。いくつかの実施形態では、一度に1つのセグメントのみを追跡することができる。他の実施形態では、一度に複数のセグメントを追跡することができる。
【００３１】
様々な実施形態では、MPDにおける対応する期間および表現結合に対するセグメントのURLのURLマッチングを利用して、タイミングドリフトが生じたかどうかを決定することができる。一実施形態では、セグメントに関する復号時間からマッチする期間および表現結合に基づくMPDごとのセグメントの利用可能開始時間を減じたものがセグメント持続時間の半分よりも大きいとの決定に応じて、受信機デバイスプロセッサは、タイミングドリフトが生じたと決定し、利用可能開始時間の再計算をトリガすること(すなわち、利用可能開始時間再計算をトリガすること)ができる。別の実施形態では、URLマッチングに少なくとも部分的に基づいてセグメントインデックス変更が生じたとの決定に応じて、タイミングドリフトが決定され得る。一実施形態では、受信されたセグメントから生じるAST変更は、URLマッチングに少なくとも部分的に基づいて決定され得る。AST変更が、1つのセグメント持続時間など、しきい値より大きいことに応じて、受信機デバイスプロセッサは、タイミングドリフトが生じたと決定し、利用可能開始時間再計算をトリガすることができる。
【００３２】
図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の位置(たとえば、ユニフォームリソースロケータ(URL))を取得し、マルチキャストサービスデバイスクライアント206から修正されたMPDを要求し受信することができ、修正されたMPD内の利用可能性タイムラインごとに、マルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。別の実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206からMPDの位置(たとえば、ユニフォームリソースロケータ(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はモデムを介してセグメントを受信することができ、マルチキャストサービスデバイスクライアント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 304は、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が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は、ネットワーク400の種々の部分における2つの例示的な配信経路遅延Δ1およびΔ2間の関係を示す。エンコーダ402からのコンテンツは、エンコーダ402からセグメンタ404へと流れ、種々のBMSC、すなわちBMSC1およびBMSC2、ならびにそれぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.n、eNB2.1、eNB2.2、eNB2.nなどによってサービスされるネットワーク406、408の2つの異なる部分に提供され得る。eノードBのeNB1.2は、第1の部分406において受信機デバイス1(410)にコンテンツを提供することができ、eノードBのeNB2.2は第2の部分408において受信機デバイス2(412)にコンテンツを提供することができる。ネットワーク400の展開において、ネットワーク部分406および408は、異なるインフラストラクチャベンダーによって管理可能であり、かつ/または異なるマルチキャストブロードキャスト単一周波数ネットワーク(MBSFN:Multicast-broadcast single-frequency network)であり得る。
【００４５】
経路遅延Δ1は、BMSC1に関する処理遅延であり得、BMSC1からそれぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.nを通して受信機デバイス1(410)にセグメントを提供する際にこの遅延を経験し得る。経路遅延Δ2は、BMSC2に関する処理遅延であり得、BMSC2からそれぞれのeノードB、すなわちeNB2.1、eNB2.2、eNB2.nを通して受信機デバイス2(412)にセグメントを提供する際にこの遅延を経験し得る。第1の部分406における経路遅延Δ1は、第2の部分408における経路遅延Δ2とは異なり得る。したがって、コンテンツの同じセグメントは、異なる部分406、408における異なる経路遅延Δ1およびΔ2のために、コンテンツが受信機デバイス2(412)において利用可能となり得るのとは異なる時間に、受信機デバイス1(410)において利用可能となり得る。異なる経路遅延Δ1およびΔ2は、複数のインフラストラクチャベンダーによるネットワーク展開および/または同じコンテンツに関して異なるMSPを使用する異なるMBSFN間の受信機デバイスモビリティを含めて、様々な要因によって引き起こされる可能性がある。
【００４６】
経路遅延がネットワーク400に対する推定最悪状況遅延よりも小さいとき、受信機デバイス1(410)または受信機デバイス2(412)におけるコンテンツのセグメントの実際の利用可能開始時間は、受信機デバイスに提供されるMPDに列挙された利用可能開始時間よりも早いものとなり得る。たとえば、いくつかの同期ネットワーク展開では、経路遅延Δ1は、経路遅延Δ2より短い場合があり、ネットワーク内の最長経路遅延(たとえば、Δ2)を考慮するために、ネットワーク内のMPDは、利用可能開始時間を同期させて、より長い経路遅延Δ2に相当する利用可能開始時間にマッチさせることができる。そのような例では、受信機デバイス2(412)内のセグメント利用可能性タイムラインは、ほぼΔ2〜Δ1によってオフセット可能であり、受信機デバイス1(410)は、再生開始の前に少なくともΔ2〜Δ1に対する第1の受信されたセグメントを不必要に記憶する場合がある。様々な実施形態によって、受信機デバイス1(410)および/または受信機デバイス2(412)は、それらの実際に経験する経路遅延Δ1および/またはΔ2を考慮し、コンテンツのセグメントが実際に利用可能となり得るときにそれらを要求することが可能となり得る。
【００４７】
図5Aは、決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法500aを示す。一実施形態では、方法500aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
【００４８】
ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDを受信することができる。一実施形態では、受信機デバイスは、OTA送信を介してMPDを受信することができる。一実施形態では、MPDは、ネットワークから受信されてよく、ヘッドエンドは、MPD内にセグメントの利用可能開始時間を設定することができる。一実施形態では、MPD内の利用可能開始時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延を考慮し得る。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPDを受信することができる。ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD内で記述される1つまたは複数のセグメントに関する1つまたは複数のセグメントフラグメントを受信することができる。たとえば、セグメントフラグメントは、マルチキャストチャネル(MCH)スケジューリング期間(MSP)中に受信されたOTAであり得る。
【００４９】
決定ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントインデックス変更が生じたかどうかを決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つの連続的に受信されたセグメントフラグメント内に示されたセグメントインデックスを互いに比較することによって、セグメントインデックス変更が生じたかどうかを決定することができ、セグメントインデックス変更は、連続的に受信されたセグメントフラグメントのセグメントインデックス間のミスマッチによって示すことができる。様々な実施形態では、各々が関連付けられるセグメントのタイプ(たとえば、ビデオまたはオーディオ)にかかわらず、受信されたセグメントフラグメントを互いと比較することができる。セグメントインデックス変更が生じていないとの決定(すなわち、決定ブロック506=「No」)に応じて、ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントフラグメントを受信し続けることができる。
【００５０】
セグメントインデックス変更が生じたとの決定(すなわち、決定ブロック506=「Yes」)に応じて、ブロック508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信された最新セグメントをベースセグメントとして設定することができる。一実施形態では、受信された最新セグメントは、最高インデックス番号を有するセグメントであり得る。ブロック510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する第1のFDTを受信することができる。ブロック512において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のFDT受信時間(1stFDTArrivalTimeBaseSegment)を決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のFDT受信時間(1stFDTArrivalTimeBaseSegment)としてベースセグメントに関する第1のFDT内で記述されたように、ベースセグメントに対応するオブジェクトの第1のパケットの受信時間を決定することができる。
【００５１】
ブロック514において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、
AvailabilitySBASE=1stFDTArrivalTimeBaseSegment+(SF*MSP)+M
など、第1のFDT受信時間(たとえば、((1stFDTArrivalTimeBaseSegment)+(セグメントごとのセグメントフラグメント(SF)の数×MSP)+マージン(M)として、ベースセグメントに関して調整された利用可能開始時間(たとえば、AvailabilitySBASE))を決定することができる。一実施形態では、MSPの値は、受信機デバイスに対して事前に準備されたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前に準備され得る。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに対応するオブジェクトの第1のパケットの受信時間に少なくとも部分的に基づいて、ベースセグメントの調整された利用可能開始時間を決定することができる。
【００５２】
ブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する調整された利用可能開始時間(AvailabilitySBASE)と受信されたMPD内のベースセグメントの利用可能開始時間との間の差として遅延調整値を決定することができる。ブロック518において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、処理遅延調整値の分だけ、MPD内のセグメントの利用可能開始時間をシフトすることができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間をシフトして、セグメントが受信機デバイスにおいて実際にいつ利用可能であり得るかを反映することができる。
【００５３】
任意選択のブロック520において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能なメモリ内に、修正されたMPDを記憶することができる。一実施形態では、修正されたMPDを記憶するステップは、いくつかまたはすべてのMPDが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置内に、修正されたMPDを記憶するステップを含み得る。別の実施形態では、クライアントアプリケーションは、修正されたMPDを別個のメモリ位置に特に記憶しなくてよい。むしろ、任意選択のブロック522において、クライアントアプリケーションは、修正されたMPDを使用して、シフトされた利用可能開始時間においてセグメントを要求するだけであってよい。
【００５４】
図5Bは、決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、遅延調整メッセージを生成するための一実施形態の方法500bを示す。方法500bは、セグメント利用可能性タイムラインのシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図5Aを参照して上記で説明した方法500aと同様である。一実施形態では、方法500bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、506、508、510、512、514、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明した方法500aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。
【００５５】
ブロック524において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージ内に遅延調整の指示を記憶することができる。一実施形態では、遅延調整メッセージは、クライアントアプリケーションが、受信機デバイスにおけるセグメント利用可能性を考慮するように、1つまたは複数のセグメントの利用可能開始時間をシフトするために使用され得る遅延調整値を決定するのに使用できる、データファイルであり得る。一実施形態では、遅延調整メッセージは、いくつかまたはすべての遅延調整メッセージが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置内に記憶され得る。任意選択のブロック526において、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能開始時間をシフトする際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送ることができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、その記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。
【００５６】
図6Aは、決定された第1のFDT受信時間に基づくベースURL変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法600aを示す。方法600aは、新しいセグメントからのセグメントフラグメントを示すセグメントインデックス変更が受信されるのではなく、セグメント間のbaseURL変更は、新しいセグメントに関するセグメントフラグメントが受信されていることを示し得ることを除いて、図5Aを参照して上記で説明した方法500aと同様である。一実施形態では、方法600aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502および504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明した方法500aの同様に番号付けされたブロックの動作を実行することができる。
【００５７】
ブロック507において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、baseURL変更が生じたかどうかを決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つの連続的に受信されたセグメントフラグメント内に示されたbaseURLを互いに比較することによって、baseURL変更が生じたかどうかを決定することができ、baseURL変更は、連続的に受信されたセグメントフラグメントのbaseURL間のミスマッチによって示すことができる。たとえば、セグメントの各セグメントフラグメントに関するURL全体は一意であり得るが、URLの初期部分を形成するbaseURLは共通のセグメントの各セグメントフラグメントに関して同じであり得る。したがって、baseURL(たとえば、URLの初期部分)の変更は、新しいセグメントのフラグメントが受信されていることを示し得る。baseURLが変更していないとの決定(すなわち、決定ブロック507=「No」)に応じて、ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントフラグメントを受信し続けることができる。baseURLが変更したとの決定(すなわち、決定ブロック507=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明した方法500aの同様に番号付けされたブロック508、510、512、514、516、518、520、および522の動作を実行することができる。
【００５８】
図6Bは、決定された第1のFDT受信時間に基づくベースURL変更に応じて、遅延調整メッセージを生成するための一実施形態の方法600bを示す。実施形態の方法600bは、セグメント利用可能性タイムライン内のシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図6Aを参照して上記で説明した方法600aと同様である。一実施形態では、方法600bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、507、508、510、512、514、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上記で説明した方法600aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。ブロック524および526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整ファイルを記憶して、送るために、図5Bを参照して上記で説明した方法500bの同様に番号付けされたブロックの動作を実行することができる。一実施形態では、方法600bの動作は、それぞれ、図5Aおよび図5Bを参照して上述した方法500aおよび500bの動作と平行してマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって実行され得る。
【００５９】
図7は、一実施形態による利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す。図7に示すように、セグメント1、2、3、4、および5はソースからBMSCに送られてよく、BMSCはセグメント1、2、3、4、および5を、ブロードキャストされる一連のセグメントフラグメントに分けることができる各MSP持続時間。BMSC処理および同期スケジューリング動作は、受信機デバイスに対するセグメントフラグメントのOTA送信を遅延させる場合があり、2つ以上のセグメントからのフラグメントはMSP持続時間ごとに送られ得る。セグメントは、復号され、BMSCによるそのOTA送信の後の何らかの期間に受信機デバイスにおいて利用可能にされ得る。
【００６０】
図5A、図5B、図6A、および図6Bを参照して上記で論じた様々な実施形態では、獲得開始後、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、新しいセグメントに関するセグメントフラグメントが属性内のミスマッチによって識別されるまで、セグメントフラグメントが受信されるにつれて、セグメントフラグメントの属性(たとえば、セグメントインデックスまたはbaseURL)を比較することができる。図7に示すように、ミスマッチは、セグメント2に関する最後のFDTおよびセグメント3に関する最初のFDTが受信されるときに生じ得る。セグメント3に関する第1のFDTの到着時間に基づいて、図5A、図5B、図6A、および図6Bを参照して上記で説明した方法500a、500b、600a、および600bに従って、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、(FDT到着時間+セグメントごとのセグメントフラグメント(SF)の数)×(MSP+マージン(M)(たとえば、(SF*MSP)+M)))として、セグメント3の利用可能開始時間を示すことができる。修正されたMPDは、それに応じて、セグメント3に関する利用可能開始時間を示すことができ、セグメント4の利用可能開始時間など、各後続のセグメントの利用可能開始時間は、修正されたMPD内のセグメント3に関する示された利用可能開始時間からの連続的なセグメント持続期間であり得る。したがって、ベースセグメントの利用可能開始時間を第1のステップで決定することができ、MPD内のベースセグメントの利用可能開始時間が第1のステップにおいて決定された利用可能開始時間にマッチするように、MPDを第2のステップで調整することができる。
【００６１】
図8Aは、いずれかの決定されたFDT受信時間に基づいてユニキャストモードでセグメント利用可能開始時間を修正するための一実施形態の方法800aを示す。一実施形態では、方法800aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。上記で論じたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDを受信することができる。さらに別の実施形態では、FDTを使用して、セグメントインデックスまたはbaseURL内の変更を決定することができ、実際の到着時間は、ファイルの識別子(たとえば、FLUTEの場合、トランスオートオブジェクト識別子、TOI)を搬送する第1のパケットが受信された時間であり得る。
【００６２】
決定ブロック802において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ユニキャストフェッチがアクティブかどうかを決定することができる。一実施形態では、ユニキャストフェッチは、モード1で(たとえば、起動時にセグメントを要求するためにユニキャストを使用して)またはモード2で(たとえば、いずれかの時点でユニキャストを使用して)アクティブであり得る。モード1またはモード2において、ユニキャストフェッチは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントのブロードキャスト/マルチキャスト受信を待たずに、ユニキャストを介してセグメントを要求することを可能にし得る。アクティブまたは非アクティブであるユニキャストフェッチは、受信機デバイスのメモリ内のユニキャストフェッチに関連するフラグ設定によってなど、任意の方法で示されてよい。ユニキャストフェッチがアクティブでないとの決定(すなわち、決定ブロック802=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aのブロック502に進み、方法500aの動作を実行することができる。
【００６３】
ユニキャストフェッチがアクティブであるとの決定(すなわち、決定ブロック802=「Yes」)に応じて、ブロック806において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロードキャスト送信またはマルチキャスト送信を介してFDTを受信することができる。FDTは、受信されたOTAであってよく、第1のFDT、最後のFDT、または中間FDTなど、セグメントに関するいずれかのFDTであってよい。ブロック808において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたFDTに関連するセグメントをベースセグメントとして設定することができる。ブロック810において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたFDT受信時間(FDTArrivalTimeBaseSegment)を決定することができる。
【００６４】
ブロック812において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、
AvailabilitySBASE=FDTArrivalTimeBaseSegment+(SF*MSP)+M)
など、FDT受信時間(たとえば、FDTArrivalTimeBaseSegment)+(セグメントごとのセグメントフラグメント(SF)の数×MSP)+マージン(M)として、ベースセグメントに関して調整された利用可能開始時間(たとえば、AvailabilitySBASE)を決定することができる。一実施形態では、MSPの値は、受信機デバイスに対して事前に準備されたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前に準備された値として構成され得る。ブロック516、518、520、および522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上記で説明した方法600aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。
【００６５】
図8Bは、いずれかの決定されたFDT受信時間に基づいてユニキャストモードで遅延調整メッセージを生成するための一実施形態の方法800bを示す。方法800bは、セグメント利用可能性タイムライン内のシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図8Aを参照して上記で説明した方法800aと同様である。一実施形態では、方法800bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
【００６６】
ブロック502、802、804、806、808、810、812、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Aを参照して上記で説明した方法800aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。ブロック524および526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整ファイルを記憶して、送るために、図5Bを参照して上記で説明した方法500bの同様に番号付けされたブロックの動作を実行することができる。
【００６７】
図9Aは、一実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。アプリケーション/DASHクライアントは、マルチキャストサービスデバイスクライアントのサービス発見機能に対する要求を送ることによって、サービスがアクティブ化されることを要求することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、サービス要求を受信し、サービスが有効であると決定し、サービス情報をマルチキャストサービスデバイスクライアントのストリーミング機能に送ってサービスをアクティブ化することができる。マルチキャストサービスデバイスのストリーミング機能は、サービスが有効であると決定し、サービスの一時モバイルグループ識別子(TMGI)をアクティブ化するための要求をマルチキャストサービスデバイスクライアントのモデムインターフェースに送ることができる。マルチキャストサービスデバイスクライアントのストリーミング機能はまた、マルチキャストサービスデバイスクライアントのデータ配信機能がFLUTEセッションをアクティブ化することを要求し、マルチキャストサービスデバイスクライアントのデータ配信機能がセグメントURLを獲得することを要求することができる。
【００６８】
一時モバイルグループ識別子がモバイル制御チャネル(MCCH)においてアクティブになり、デバイスがメディア転送チャネル(MTCH)を復号できるようになると、モデムによって受信されるIPパケットは、マルチキャストサービスデバイスクライアントのモデムインターフェースからマルチキャストサービスデバイスクライアントのデータ配信機能に配信され得る。任意選択で、MSDモデムインターフェースは、更新されたベアラ記述をMSPストリーミング機能に配信することができる。マルチキャストサービスデバイスクライアントのデータ配信機能は、ファイル捕捉要求をMSPストリーミング機能に送ることができる。セグメントN、すなわちN+1、N+2などが受信され復号されるにつれて、それらは、マルチキャストサービスデバイスクライアントのDASHゲートウェイに送信され得る。
【００６９】
一実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能が、受信されたセグメントフラグメント間のインデックス変更を決定するとき、マルチキャストサービスデバイスクライアントのサービス発見機能は、ベースセグメントFDTの受信時間およびインデックス番号をマルチキャストサービスデバイスのサービス発見機能に示すことができ、マルチキャストサービスデバイスのサービス発見機能は、上記で論じたように、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によって応答することができる。
【００７１】
図9Bは、別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。図9Bでは、ビデオセグメントおよびオーディオセグメントが独立して捕捉され得ることを除いて、図9Bに示すフローは、図9Aを参照して上記で説明したフローと同様である。マルチキャストサービスデバイスクライアントのデータ配信機能がMとインデックス付けされたビデオセグメントおよびMとインデックス付けされたオーディオセグメントに対する捕捉要求を送るにつれて、マルチキャストサービスデバイスクライアントのデータ配信機能は、M+1とインデックス付けされた次のビデオセグメントに対する捕捉要求も送ることができる。一実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能が、受信されたビデオセグメントMとビデオセグメントM+1との間のインデックス変更を決定するとき、マルチキャストサービスデバイスクライアントのサービス発見機能は、ビデオセグメントM+1がベースセグメントであることを示し、ベースセグメントFDTの受信時間およびインデックス番号をマルチキャストサービスデバイスのサービス発見機能に示すことができ、マルチキャストサービスデバイスのサービス発見機能は、上記で論じたように、MPDを修正して、利用可能開始時間を調整することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、修正されたMPDをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送ることができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。
【００７２】
アプリケーション/DASHクライアントは、メディアプレーヤを起動し、メディアプレーヤを修正されたMPDのURLに向けることができる。アプリケーション/DASHクライアントは、修正されたMPD URLにおいて修正されたMPDに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、修正されたMPDによって応答することができる。アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。アプリケーション/DASHクライアントは、オーディオセグメントMに対するHTTP Get()要求を送り、オーディオセグメントMを受信することができる。一実施形態では、ビデオセグメントMは、アクティブなとき、ユニキャストフェッチを介して受信可能であり、マルチキャストサービスデバイスのストリーミング機能は、ビデオセグメントM+1およびオーディオセグメントM+1がブロードキャストまたはマルチキャストを介して利用可能になるとき、それらの利用可能性について通知され得る。
【００７３】
図9Aおよび図9Bは、マルチキャストサービスデバイスのサービス発見機能がMPDを修正することを示すが、他の実施形態では、マルチキャストサービスデバイスのサービス発見機能は、その時間が、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに対して実際にいつ利用可能になるかを反映するように、MPD内の利用可能開始時間をシフトするために使用され得る遅延調整値の表示を含む遅延調整メッセージまたはファイルを生成することができる。したがって、マルチキャストサービスデバイスクライアントまたはアプリケーション/DASHクライアントは、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに実際に利用可能になるとき、遅延調整メッセージまたはファイルを使用して、MPD内の利用可能開始時間をシフトすること、および/またはセグメントを要求することができる。
【００７４】
図10は、遅延調整メッセージに基づいて利用可能開始時間を調整するための一実施形態の方法を示すプロセスフロー図である。一実施形態では、方法1000の動作は、DASHクライアントのような、スマートフォンのような受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック1002において、クライアントアプリケーションは、MPDを受信することができる。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介してMPDを受信することができる。ブロック1004において、クライアントアプリケーションは、遅延調整メッセージを受信することができる。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介して遅延調整メッセージを受信することができる。
【００７５】
ブロック1006において、クライアントアプリケーションは、遅延調整メッセージに基づいて、MPD内のいくつかまたはすべてのセグメントの利用可能開始時間をシフトすることができる。一実施形態では、遅延調整メッセージに基づいて利用可能開始時間をシフトするステップは、遅延調整値および/または他の値の指示を使用して、各セグメントが受信機デバイス上で利用可能になる時間を調整するステップを含み得る。一実施形態では、利用可能開始時間をシフトするステップは、MPD自体を修正して修正されたMPDを生成するステップを含み得る。別の実施形態では、利用可能開始時間をシフトするステップは、MPD自体を修正することなく、セグメントが受信機デバイス上で利用可能になるときの指示を変更するステップを伴い得る。MPDが修正される実施形態では、任意選択のブロック1008において、クライアントアプリケーションは、クライアントアプリケーションに対して利用可能なメモリ内に、修正されたMPDを記憶することができる。ブロック1010において、クライアントアプリケーションが、シフトされた利用可能開始時間においてセグメントを要求することができる。
【００７６】
図11Aは、MPD更新を処理するための一実施形態方法を示すプロセスフロー図である。一実施形態では、方法1100aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1100aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
【００７７】
ブロック1102において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新を受信することができる。一実施形態では、MPD更新は、ネットワークから受信されてよく、ヘッドエンドは、MPD更新内にセグメントの利用可能開始時間を設定することができる。一実施形態では、MPD更新内の利用可能開始時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延を考慮し得る。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPD更新を受信することができる。
【００７８】
ブロック1104において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新内に設定された利用可能開始時間(AST)を決定することができる。決定ブロック1106において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最初に受信されたMPDとMPD更新との間にAST変更が生じたかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDのいずれかの修正の前に元のMPD内で示されたASTをMPD更新内のASTと比較することができる。
【００７９】
MPD更新内のASTが元のASTと同じであるとの決定(すなわち、決定ブロック1106=「No」)に応じて、ブロック1108において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新内のASTを調整して、前に修正されたMPD内の修正されたASTにマッチさせることができる。ASTがマッチしないとの決定(すなわち、決定ブロック1106=「Yes」)に応じて、ブロック1110において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する決定された、調整された利用可能開始時間(AvailabilitySBase)と修正に先立つ元のASTとの間の差の分だけ、MPD更新内のASTを修正することができる。
【００８０】
図11Bは、MPD更新を処理するための一実施形態の方法1100bを示す。MPD更新内のASTの変更が利用可能開始時間再計算をトリガし得ることを除いて、方法1100bは、図11Aを参照して上記で説明した方法1100aと同様である。一実施形態では、方法1100bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1100bの動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。ブロック1102、1104、1106、および1108において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図11Aを参照して上記で説明した方法1100aの同様に番号付けされたブロックの動作を実行することができる。
【００８１】
ASTがマッチしないとの決定(すなわち、決定ブロック1106=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD更新内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。さらなる例として、利用可能開始時間再計算のトリガは、そのセグメントに関連するサービスをアクティブ化したアプリケーションに対する通知の発行を含み得る。
【００８２】
図12は、別の実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す。図12は、経時的に、セグメント3などのセグメントの利用可能開始時間を決定することができ、(たとえば、その第1のFDTの受信時間に基づいて)セグメントが受信機デバイスにおいて実際にいつ利用可能になり得るかを考慮するために利用可能開始時間がシフトされることを示すが、受信機デバイス上のタイミングドリフトは、修正されたMPD内の利用可能開始時間を無効にする場合がある。
【００８３】
何らかの時間Nの後で、利用可能開始時間、AvailabilitytimeS4+Nを修正されたMPD内で示すことができ、DASHクライアントは、セグメントS4+Nに対するHTTP要求を発行することができる。しかしながら、受信機デバイスのタイミングドリフトにより、HTTP再試行は、セグメントS4+Nを受信せずに、DASHクライアントによって試し尽くされる場合がある。したがって、受信機デバイスのタイミングドリフトにより、DASHクライアントがセグメントS4+N要求の試行を中断した後でセグメントS4+Nは利用可能になり得る。様々な実施形態では、DASHクライアントのHTTP再試行が試し尽くされた後の(たとえば、セグメントS4+N+1が要求されると)セグメントS4+Nの受信は、利用可能開始時間の再計算をトリガし得る。このようにして、利用可能開始時間再計算は受信機デバイスのタイミングドリフトを考慮することができる。
【００８４】
図13は、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1300を示す。一実施形態では、方法1300の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1300の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
【００８５】
ブロック1302において、マルチキャストサービスデバイスクライアントは、セグメントに対するHTTP要求を受信することができるか、またはクライアントアプリケーションはHTTP要求を生成することができる。HTTP要求は、セグメントのURIおよびセグメント番号を示し得る。決定ブロック1304において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントが現在追跡されているかどうかを決定することができる。様々な実施形態では、セグメントに関連するHTTP要求が失敗したとき、そのセグメントを追跡することができる。
【００８６】
何のセグメントも追跡されていないとの決定(すなわち、決定ブロック1304=「No」)に応じて、ブロック1306において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が成功したとの決定(すなわち、決定ブロック1306=「Yes」)に応じて、ブロック1308において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡記録を消去することができ、ブロック1302において、次のセグメントに対する次のHTTP要求を受信または生成することができる。
【００８７】
要求が失敗したとの決定(すなわち、決定ブロック1306=「No」)に応じて、ブロック1310において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求されたセグメントを追跡することができ、ブロック1302において、同じセグメントに対するHTTP要求を再度受信または生成することができる。
【００８８】
セグメントが追跡されているとの決定(すなわち、決定ブロック1304=「Yes」)に応じて、決定ブロック1312において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求されたセグメントが追跡されているかどうかを決定することができる。要求されたセグメントが追跡されているとの決定(すなわち、決定ブロック1312=「Yes」)に応じて、上記で論じたように、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロック1306、1308、および1310において、要求が成功したかどうかを決定し、追跡記録を消去するか、またはセグメントを追跡し続けることができる。
【００８９】
追跡されているセグメントが要求されたセグメントではないとの決定(すなわち、決定ブロック1312=「No」)に応じて、ブロック1314において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡されたセグメントがキャッシュ内(たとえば、受信されたセグメントストレージに割り振られたメモリ位置内)にあるかどうかを決定することができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが前に要求したが、受信に失敗したセグメントがその後受信されたかどうかを検査することができる。
【００９０】
追跡されたセグメントがキャッシュ内にないとの決定(すなわち、決定ブロック1314=「No」)に応じて、ブロック1316において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡記録を消去することができる。任意選択の実施形態で、ブロック1318において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最後の新しいセグメント番号が要求されてから、セグメント持続時間の90%(たとえば、9*SD)が経過したかどうかを決定することができる。このようにして、複数のセグメントが一度に要求され得る起動シナリオを、ほぼすべてのセグメント持続時間に生じる定期的にタイミングがとられた要求と区別することができる。そのような任意選択の実施形態では、セグメント持続時間の90%が経過していないとの決定(すなわち、決定ブロック1318=「No」)に応じて、ブロック1302において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに対するHTTP要求を受信または生成することができる。セグメント持続時間の90%(たとえば、9*SD)として示されているが、任意の割合値のセグメント持続時間を選択することができる。本明細書で説明する例における90%のセグメント持続時間に対して、たとえば、10%、50%、95%、または任意の他の割合値のセグメント持続時間を代用することができる。
【００９１】
ブロック1316において追跡記録を消去するとすぐに、または任意選択の実施形態では、セグメント持続時間の90%が経過したとの決定(すなわち、決定ブロック1318=「Yes」)に応じて、ブロック1306、1308、および1310において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定し、追跡記録を消去するか、またはセグメントを追跡し続けることができる。
【００９２】
追跡されたセグメントがキャッシュ内にあるとの決定(すなわち、決定ブロック1314=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
【００９３】
図14は、失敗したHTTP記録をマークするための一実施形態の方法1400を示す。一実施形態では、方法1400の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1400の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1400の動作は、図15Aおよび図15Bを参照して下記で説明する方法1500aおよび/または1500bの動作とともに実行され得る。
【００９４】
ブロック1402において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントを受信することができる。たとえば、セグメントはブロードキャストOTA送信またはマルチキャストOTA送信を介して受信され得る。決定ブロック1404において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントが追跡されているかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURIおよび/またはセグメントインデックスに関連する、失敗したHTTP記録が存在するかどうかを決定することができる。セグメントが追跡されていないとの決定(すなわち、決定ブロック1404=「No」)に応じて、ブロック1406において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、何の措置も講じなくてよい。セグメントが追跡されているとの決定(すなわち、決定ブロック1408=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、失敗したHTTP記録を「受信されたセグメント」とマークすることができる。このようにして、後に受信されたセグメントに関連する、失敗したHTTP要求を識別し、受信されていないセグメントに関連する、失敗したHTTP要求と区別することができる。
【００９５】
図15Aは、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1500aを示す。一実施形態では、方法1500aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1500aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1500aの動作は、図14を参照して上記で説明した方法1400の動作とともに実行され得る。
【００９６】
ブロック1502において、マルチキャストサービスデバイスクライアントは、セグメントに対するHTTP要求を受信することができるか、またはクライアントアプリケーションはHTTP要求を生成することができる。HTTP要求は、セグメントのURIおよびセグメント番号を示し得る。決定ブロック1504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求内に新しいURIが示されているかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、HTTP要求内のURIを前のHTTP要求内のURIと比較して、URIが新しいかどうかを決定することができる。
【００９７】
URIが新しくないとの決定(すなわち、決定ブロック1504=「No」)に応じて、ブロック1506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が成功したとの決定(すなわち、決定ブロック1506=「Yes」)に応じて、ブロック1508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関するいずれかの失敗したHTTP記録を消去することができる。
【００９８】
URIが新しいとの決定(すなわち、決定ブロック1504=「Yes」)に応じて、ブロック1510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が失敗したとの決定(すなわち、決定ブロック1510=「No」)に応じて、ブロック1512において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関する失敗したHTTP記録を追加し、失敗したURI記録内の最初のタイムスタンプを現在の時間に設定することができる。
【００９９】
要求が成功しなかったとの決定(すなわち、決定ブロック1506=「No」)に応じて、またはブロック1512において、URIに関する失敗したHTTP記録を追加するとすぐに、ブロック1516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関する失敗したHTTP記録内の最後のタイムスタンプを現在の時間に設定することができる。このようにして、URIに関する失敗したHTTP記録内の最初のタイムスタンプから最後のタイムスタンプまでの時間は、その失敗したHTTP記録に関する追跡期間を示し得る。
【０１００】
ブロック1508において、URIに関する失敗したHTTP記録の消去、ブロック1516における、最後のタイムスタンプの設定、または要求が成功したとの決定(すなわち、決定ブロック1510=「Yes」)に応じて、ブロック1520において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最大記録追跡期間よりも長く記録されているいずれの失敗したHTTP記録も消去することができる。たとえば、最大記録追跡期間は、10秒など、FFR_periodの2倍であってよい。最大記録追跡期間よりも長い、失敗したHTTP記録内の最初のタイムスタンプから最後のタイムスタンプまでの失敗したHTTP記録を消去すること(たとえば、削除すること)ができる。
【０１０１】
決定ブロック1522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最後のタイムスタンプを有する「受信されたセグメント」とマークされたいずれかの失敗したHTTP記録が、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに利用可能なメモリ内に存在する現在の時間の前の1つのセグメント持続時間よりも古いかどうかを決定する。「受信されたセグメント」とマークされたいずれの失敗したHTTP記録も1つのセグメント持続時間よりも古くないとの決定(すなわち、決定ブロック1522=「No」)に応じて、ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
【０１０２】
「受信されたセグメント」とマークされた失敗したHTTP記録が1つのセグメント持続時間よりも古いとの決定(すなわち、決定ブロック1522=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
【０１０３】
図15Bは、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1500bを示す。利用可能開始時間再計算をトリガする前に遅延が導入され得ることを除いて、実施形態の方法1500bは、図15Aを参照して上記で説明した方法1500aと同様である。一実施形態では、方法1500bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1500bの動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。ブロック1502、1504、1506、1508、1510、1512、1516、1518、1520、および1522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図15Aを参照して上記で説明した方法1500aの同様に番号が付けられたブロックの動作を実行することができる。
【０１０４】
「受信されたセグメント」とマークされた失敗したHTTP記録が1つのセグメント持続時間よりも古いとの決定(すなわち、決定ブロック1522=「Yes」)に応じて、決定ブロック1524において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延がすでに導入されていると決定することができる。遅延が導入されていないとの決定(すなわち、決定ブロック1524=「No」)に応じて、ブロック1528において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、90%のセグメント持続時間(0.9*SD)の遅延を導入し、すべての失敗したHTTP記録をマーク解除することができる。このようにして、利用可能開始時間再計算が速やかにトリガされなくてよく、失敗したHTTP記録に関するセグメントは、それらのセグメントが「受信されたセグメント」と再度マークされ得る前に2回目に受信されなければならない場合がある。セグメントの強制された再要求は、そのそれぞれの利用可能開始時間の終了に先立ってセグメントが受信され得るとき、利用可能開始時間の再計算が回避されることを可能にし得る。ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
【０１０５】
遅延がすでに導入されているとの決定(すなわち、決定ブロック1524=「Yes」)に応じて、ブロック1526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つのセグメント持続時間より前に遅延が導入されたかどうかを決定することができる。2つのセグメント持続時間より前に遅延が導入されなかったとの決定(すなわち、決定ブロック1526=「No」)に応じて、ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
【０１０６】
2つのセグメント持続時間より前に遅延が導入されたとの決定(すなわち、決定ブロック1526=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
【０１０７】
図16は、URLマッチングによってセグメントインデックスを決定するための一実施形態の方法1600を示す。一実施形態では、方法1600の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1600の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1600の動作は、それぞれ、図5Aおよび図5Bを参照して上記で説明した方法500aまたは500bの動作とともに実行され得る。たとえば、方法1600の動作は、MPDの受信(図5Aまたは図5Bのブロック502)およびセグメントフラグメントの受信(図5Aまたは図5Bのブロック504)の後、かつセグメントインデックス変更が生じたかどうかの決定(図5Aまたは図5Bのブロック506)の前に実行され得る。
【０１０８】
ブロック1602において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURLを決定することができる。たとえば、受信されたセグメントに関するURLは、URLテンプレート「xxx$number$yyy」に続いてよい。別の例では、同じ時間持続時間に対応するオーディオセグメントおよびビデオセグメントは、URLテンプレート内に同じ$time$タグを有し得る。ブロック1604において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の最初の期間および表現結合を見つけ、最初の期間および表現結合を現在の期間および表現結合として設定することができる。様々なMPDにおいて、MPDをクロールすることは、MPDを表す、XMLファイルなどのファイルをパースすることを含み得る。本明細書で論じるように、期間および表現結合は、MPDによって定義される一意表現であり得る。MPD内で定義された各期間は、1つまたは複数の表現に関する属性、たとえば、1つまたは複数の適応セットを含んでよく、期間と1つまたは複数の表現からの個々の表現との組合せは、期間および表現結合を構成し得る。MPD内の期間および表現結合は、期間境界、URLフォーマット、セグメント持続時間、セグメントタイムスケール、開始番号、帯域幅、期間識別子などを含めて、サービスに関する各期間および表現を記述する属性を含み得る。
【０１０９】
ブロック1606において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントの決定されたURLをMPD内の現在の期間および表現結合と比較することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメント内のURLを期間および表現結合内に示されたURLと比較することができる。
【０１１０】
決定ブロック1608において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに関する決定されたURLが現在の期間および表現結合内のURLにマッチするかどうかを決定することができる。URLがマッチしないとの決定(すなわち、決定ブロック1608=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。ブロック1606において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、決定されたURLをMPD内の新しい現在の期間および表現結合と比較することができる。
【０１１１】
URLがマッチするとの決定(すなわち、決定ブロック1608=「Yes」)に応じて、ブロック1610において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、現在の期間および表現結合内のURLと決定されたURLとに少なくとも部分的に基づいて潜在的なセグメント番号マッチを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、少なくとも非数字、および任意選択で、その後にファイル拡張が続く非数字が先行する、セグメントURLの最後におけるセグメントインデックスを識別することによって、URLに少なくとも基づいて潜在的なセグメント番号を決定することができる。
【０１１２】
決定ブロック1612において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、潜在的なセグメント番号が現在の期間および表現結合のセグメント境界に対応するかどうかを決定することができる。期間の境界は、MPDのperiod@start属性またはperiod@duration属性のいずれかに基づいて、または次の期間開始属性と現在の期間開始属性との間の差を決定することによって、決定され得る。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメント番号が現在の期間の境界内のセグメントに対応することを検証することができる。
【０１１３】
セグメント番号が現在の期間の境界内にないとの決定(すなわち、決定ブロック1612=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。何のマッチも見つからない可能性がある場合、手順は失敗し、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、いずれかの調整をMPDに適用しないこと、またはある調整としてマージンMをASTに単に加えることのいずれかが可能である。
【０１１４】
セグメント番号が現在の期間の境界内にあるとの決定(すなわち、決定ブロック1612=「Yes」)に応じて、ブロック1616において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントに関するセグメントインデックスを潜在的なセグメント番号に等しく設定することができる。
【０１１５】
図17A、図17B、および図17Cは、一実施形態による例示的なMPD1700の要素のブロック図である。図17A、図17B、および図17Cに示すように、MPDをクロールして、期間および表現結合を識別するにつれて、MPDの重要な属性はマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって識別され得る。これらの重要な要素は、利用可能開始時間、メディアプレゼンテーション持続時間、期間、期間開始、期間持続時間、期間ベースURL、期間セグメントテンプレート、適応セット、適応セットベースURL、適応セットセグメントテンプレート、表現、表現識別子、表現帯域幅、表現ベースURL、および表現セグメントテンプレートを含み得る。
【０１１６】
図18は、一実施形態による例示的なMPD1800のXMLツリーのブロック図である。図18に示すように、MPD1800は、複数の期間、適応セット、および表現を含み得る。様々な実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、各期間からそのそれぞれの適応セットに、かつそれらの適応の各それぞれの表現にツリーの各リーフに沿って連続的にMPD1800のXMLツリーをクロールすることができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD1800をクロールするにつれて、テンプレート「xxx$number$yyy」にマッチするURLのベース部分など、URLを識別して、受信されたセグメントのURLに対するマッチを決定することができる。
【０１１７】
図19は、一実施形態によるセグメントの利用可能性タイムラインを示す。具体的には、図19は、受信機デバイス上のセグメントの実際の利用可能開始時間にわたる、その関連するMPD内に列挙されたビデオサービス表現(R1)のセグメントの利用可能開始時間を示す。図19に示すように、単一のセグメント持続時間ビデオサービスは、0.5秒の短い持続時間セグメントで終了する第1の期間S36を有し得る。セグメントS1が1秒で期間1に利用可能になると仮定すると、セグメントS36は36秒で期間1に利用可能になり得る。セグメントS36および期間1の利用可能終了時間は、その場合、セグメントS36に対する0.5秒のセグメント持続時間に基づいて、36.5秒であり得る。
【０１１８】
図20は、各々が、各々、その独自の表現1を有する、その独自のそれぞれの適応セット1および2を有する期間1および2を示す一実施形態による単一のセグメント持続時間MPD2000の1つの例示的なスキーマ部分である。MPDは、図19に示すタイムラインごとのセグメントの利用可能開始を示す。
【０１１９】
図21は、一実施形態による、図20に示したMPD2000をクロールし、期間および表現結合内のURLをマッチさせた様々な結果を示すブロック図である。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURL2102が「/video150000/0/chunk_41.mp4」であると決定し、URL2102を期間および表現結合2106にマッチさせて、マッチを見つけることを試行することができる。期間2適応セット1表現1に対する期間および表現結合はURL2102にマッチし得るが、これは帯域幅15000がマッチし得、id 0がURL2102内の要素にマッチし得るためである。セグメントの利用可能開始時間は、利用可能開始時間が、36.5秒から無限大の期間境界内にあり得る37.5秒になり得るように、期間の開始時間35.5秒+1000msのセグメント持続時間+セグメントインデックスN=41-セグメント開始番号40として決定され得る。このようにして、マッチは有効であり得、受信されたセグメントに関するセグメントインデックスは41と確認され得る。
【０１２０】
図22は、複数のセグメント持続時間がMPD内に記述される一実施形態による、セグメントの利用可能性タイムラインを示す。コンテンツは、2つの表現、すなわち、1秒のセグメント持続時間を有する第1の表現(R1)および2秒のセグメント持続時間を有する第2の表現(R2)を有し得る。具体的には、図22は、受信機デバイス上のセグメントの実際の利用可能開始時間にわたる、その関連するMPD内に列挙された、表現R1およびR2のセグメントの利用可能開始時間を示す。図22に示すように、表現R1またはR2の第1のセグメントの利用可能開始時間は、そのセグメントが属し得る表現に関するセグメント持続時間に依存する。これらの表現のうちの1つは、1つのサービスエリア内で任意の所与の時点でブロードキャストされることが予想され得る。
【０１２１】
図23は、期間1および2を示す一実施形態による、各々が、各々、それぞれ異なるセグメント持続時間、すなわち、1秒および2秒を有する2つの表現0および1を有するその独自のそれぞれの適応セット1を有し、2つのセグメント持続時間MPD2300のある例示的なスキーマ部分である。この例示的なMPDは図22に示したタイムラインに対応する。
【０１２２】
図24は、一実施形態による、図23に示したMPD2300をクロールし、期間および表現結合内のURLをマッチさせた様々な結果を示すブロック図である。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURL2402が「/audio30000/1/chunk_6.mp4」であると決定し、URL2402を期間および表現結合2406にマッチさせて、マッチを見つけることを試行することができる。期間2適応セット1表現2に対する期間および表現結合はURL2402をマッチさせることができるが、これは帯域幅30000がマッチすることができ、id 1がURL2402内の要素にマッチし得るためである。セグメントの利用可能開始時間は、利用可能開始時間が、10秒から無限大の期間境界内にあり得る12秒になり得るように、期間の開始時間8秒+2000msのセグメント持続時間+セグメントインデックスN=6-開始セグメント番号5の開始時間として決定され得る。このようにして、マッチは有効であり得、受信されたセグメントに関するセグメントインデックスは6と確認され得る。
【０１２３】
図25は、2つ以上の期間および表現結合がセグメントのURLにマッチし、セグメントに関する有効な境界を有するとき、URLマッチングによってセグメントインデックスを決定するための一実施形態の方法2500を示す。たとえば、図26の利用可能性タイムラインにおいて示すように、いくつかのサービスは、広告など、反復セグメントを含む場合があり、A3などの反復セグメントが受信されるとき、セグメントURLは2つ以上の期間および表現結合のURLを有効な期間にマッチさせることができる。最良の候補マッチング期間および表現結合を選択するために、方法2500の動作は、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、最小AST変更をもたらす期間および表現結合に対応するセグメント番号としてセグメント番号を選択することを可能にし得る。一実施形態では、方法2500の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2500の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法2500の動作は、それぞれ、図5Aおよび図5Bを参照して上記で説明した方法500aまたは500bの動作とともに実行され得る。たとえば、方法2500の動作は、MPDの受信(図5Aまたは図5Bのブロック502)およびセグメントフラグメントの受信(図5Aまたは図5Bのブロック504)の後、かつセグメントインデックス変更が生じたかどうかの決定(図5Aまたは図5Bのブロック506)の前に実行され得る。
【０１２４】
ブロック1602〜1612において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図16を参照して上記で説明した方法1600の同様に番号付けされたブロックの動作を実行することができる。潜在的なセグメント番号が現在の期間および表現結合のセグメント境界内になるとの決定(すなわち、決定ブロック1612=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロック2502において、現在の期間および表現結合および潜在的なセグメント番号を考えられるマッチとして記憶することができる。
【０１２５】
決定ブロック2504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD全体がクロールされているかどうかを決定することができる。MPD全体がクロールされていないとの決定(すなわち、決定ブロック2504=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。
【０１２６】
MPD全体がクロールされているとの決定(すなわち、決定ブロック2504=「Yes」)に応じて、ブロック2506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、すべての考えられる記憶されたマッチから生じるAST変更を決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの受信から生じるASTを計算することができる。セグメントの受信から生じるASTは、図5A〜図15Bのうちのいずれかを参照して上記で説明した方法、または任意の他の方法に基づいてなど、任意の方法で計算され得る。たとえば、セグメントインデックス変更が生じると、方法2500は、ブロック2506の一部として、図5Aまたは図5Bの手順を適用して、MPDタイムライン修正を決定することができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次いで、各考えられる記憶されたマッチに関する元のASTをセグメントの受信から生じた計算されたASTから減じて、各考えられる記憶されたマッチに関して生じるAST変更を決定することができる。
【０１２７】
ブロック2508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントに関するセグメントインデックスをAST内の最小変更を伴う考えられるマッチの潜在的なセグメント番号に等しく設定することができる。たとえば、各個々の考えられる記憶されたマッチに関して決定されたAST変更を一緒に比較することによって、決定された最小AST変更を識別することができ、受信されたセグメントに関するセグメントインデックスは、識別された、決定された最小AST変更を伴う考えられるマッチに関連するセグメントインデックスであり得る。このようにして、ブロック2508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD内の既存のタイムラインに対してより小さい時間修正をもたらすMPDタイムライン調整(たとえば、最小AST変更をもたらすMPDタイムライン調整)を選択することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間内に最小変更(すなわち、最小利用可能開始時間変更)をもたらす遅延調整値を記憶することができる。
【０１２８】
図27は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2700を示す。一実施形態では、方法2700の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2700の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
【０１２９】
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URLマッチングによって受信されたセグメントのセグメントインデックスを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、それぞれ、図16および図25を参照して上記で説明した方法1600または方法2500の動作を実行して、URLマッチングによってセグメントインデックスを決定することができる。
【０１３０】
ブロック2704において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マッチング期間および表現結合に基づいて、決定されたセグメントインデックスを有するセグメントに関するMPDごとの利用可能開始時間(AvailPerMPD)を決定することができる。ブロック2706において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDからセグメント持続時間(SD)を決定することができる。ブロック2708において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに関する復号時間(DT)を決定することができる。復号時間(DT)は、セグメントが受信機デバイス上で実際に利用可能になる時間であり得る。
【０１３１】
決定ブロック2710において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、復号時間(DT)-MPDごとの利用可能開始時間(AvailPerMPD)がセグメント持続時間(SD)の0.5倍よりも大きいかどうかを決定することができる。セグメント持続時間の半分(たとえば、0.5*SD)として示されるが、復号時間(DT)-MPDごとの利用可能開始時間(AvailPerMPD)がセグメント持続時間(SD)の0.5倍よりも大きいかどうかを決定することは、復号時間(DT)とMPDごとの利用可能開始時間(AvailPerMPD)との間の差を比較することができるしきい値の単なる1つの例示的な比較である。本明細書で論じるセグメント持続時間(SD)の0.5倍のしきい値に対して、1*SD、.6*SD、.9*SDなど、セグメント持続時間の比率、またはセグメント持続時間の任意の他の比率としての固定値のしきい値またはしきい値セットを含めて、他のしきい値を代用することができる。DT-AvailPerMPDが0.5*SDより大きくないとの決定(すなわち、決定ブロック2710=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、何のタイミングドリフトも生じなかったと決定することができ、ブロック2712において何の措置も講じなくてよい。係数(0.5など)がデバイス上に準備され得るか、またはネットワークによってブロードキャストされた構成ファイルの一部として受信され得る。
【０１３２】
DT-AvailPerMPDが0.5*SDより大きいとの決定(すなわち、決定ブロック2710=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、タイミングドリフトが生じたと決定し、図11Bを参照して上記で説明したように、ブロック1112において、利用可能開始時間の再計算をトリガすることができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションはまた、MPDが修正されていることをアプリケーションに通知することができる。
【０１３３】
図28は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2800を示す。方法2800は、セグメントインデックス変更に応じて、利用可能開始時間の再計算がトリガされ得ることを除いて、図27を参照して上記で説明した方法2700と同様である。一実施形態では、方法2800の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2800の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
【０１３４】
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロックの動作を実行することができる。決定ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明したように、セグメントインデックス変更が生じたかどうかを決定することができる。セグメントインデックスが変更されていないとの決定(すなわち、決定ブロック506=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック2712において何の措置も講じなくてよい。
【０１３５】
セグメントインデックスが変更されたとの決定(すなわち、決定ブロック506=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロック2704、2706、2708、2710、2712、および1112の動作を実行することができる。
【０１３６】
図29は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2900を示す。AST変更が、1つのセグメント持続時間など、しきい値を超えることになるとの決定に応じて、利用可能開始時間再計算がトリガされ得ることを除いて、方法2900は、図27を参照して上記で説明した方法2700と同様である。一実施形態では、方法2900の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2900の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
【０１３７】
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロックの動作を実行することができる。
【０１３８】
ブロック2902において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントから生じたAST変更を決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの受信から生じるASTを計算することができる。セグメントの受信から生じるASTは、図5A〜図15Bのうちのいずれかを参照して上記で説明した方法、または任意の他の方法に基づいてなど、任意の方法で計算され得る。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次いで、セグメントに関する元のASTをセグメントの受信から生じる計算されたASTから減じて、セグメントから生じるAST変更を決定することができる。
【０１３９】
決定ブロック2904において、プロセッサは、AST変更がしきい値よりも大きいかどうかを決定することができる。しきい値は、受信機デバイスのメモリ内に記憶された値であってよく、セグメント持続時間に等しい、1つのセグメント持続時間に満たない、1つのセグメント持続時間を超えるなど、(事前に準備された、ユーザ定義可能な、MPD内で定義されるなど)任意の値であってよい。AST変更がしきい値以下であるとの決定(すなわち、決定ブロック2904=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック2712において、何の措置も講じなくてよい。AST変更がしきい値より大きいとの決定(すなわち、決定ブロック2904=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック1112において、利用可能開始時間再計算をトリガすることができる。
【０１４０】
様々な実施形態では、図27、図28、および図29を参照して上記で説明した方法2700、2800、および2900の動作は、それぞれ、一定の時間間隔または一定のセグメント計数間隔において周期的に適用され得る。
【０１４１】
様々な実施形態(限定はしないが、図3A〜図29を参照して上記で説明した実施形態を含む)は、様々なモバイルデバイス(すなわち、受信機デバイス)のいずれかにおいて実装されてよく、その一例が図30に示される。たとえば、モバイルデバイス3000は、タッチスクリーンコントローラ3004および内部メモリ3002に結合されたプロセッサ3001を含み得る。プロセッサ3001は、汎用または特定の処理タスクに対して指定された1つまたは複数のマルチコア集積回路(IC)であってよい。内部メモリ3002は、揮発性メモリまたは不揮発性メモリであってよく、またセキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ3004およびプロセッサ3001は、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンパネル3012にも結合され得る。モバイルコンピューティングデバイス3000は、1つまたは複数の無線信号トランシーバ3008(たとえば、Peanut(登録商標)、Bluetooth(登録商標)、Zigbee(登録商標)、Wi-Fi、RF、セルラーなど)と、互いにおよび/またはプロセッサ3001に結合された、送受信するためのアンテナ3010とを有し得る。トランシーバ3008およびアンテナ3010は、様々なワイヤレス送信プロトコルスタックおよびインターフェースを実装するために、上述の回路とともに使用され得る。モバイルコンピューティングデバイス3000は、セルラーネットワークを介した通信を可能にし、プロセッサに結合されたセルラーネットワークワイヤレスモデムチップ3016を含み得る。モバイルコンピューティングデバイス3000は、プロセッサ3001に結合された周辺デバイス接続インターフェース3018を含み得る。周辺デバイス接続インターフェース3018は、1つのタイプの接続を受け入れるように単独で構成され得るか、あるいはUSB、FireWire、Thunderbolt、またはPCIeなどの、共通またはプロプライエタリの様々なタイプの物理接続および通信接続を受け入れるように複合的に構成され得る。周辺デバイス接続インターフェース3018はまた、同様に構成された周辺デバイス接続ポート(図示せず)に結合され得る。モバイルコンピューティングデバイス3000はまた、オーディオ出力を提供するためのスピーカー3014を含み得る。モバイルコンピューティングデバイス3000はまた、本明細書で論じる構成要素のうちのすべてまたはいくつかを収容するための、プラスチック、金属、または材料の組合せで構成されたハウジング3020を含み得る。モバイルコンピューティングデバイス3000は、使い捨てバッテリーまたは充電式バッテリーなどの、プロセッサ3001に結合された電源3022を含み得る。充電式バッテリーはまた、モバイルコンピューティングデバイス3000の外部にあるソースから充電電流を受けるために周辺デバイス接続ポートに結合され得る。
【０１４２】
様々な実施形態(限定はしないが、図3A〜図29を参照しながら上記で説明した実施形態を含む)はまた、図31に示すサーバ3100などの様々な市販のサーバデバイスのいずれかで実装されてよい。そのようなサーバ3100は、通常、揮発性メモリ3102、およびディスクドライブ3104などの大容量の不揮発性メモリに結合されたプロセッサ3101を含む。サーバ3100はまた、プロセッサ3101に結合された、フロッピーディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ3106を含む場合がある。サーバ3100はまた、他の告知システムコンピュータおよびサーバに結合されたローカルエリアネットワーク、インターネット、公衆交換電話網、ならびに/またはセルラーネットワーク(たとえば、CDMA、TDMA、GSM（登録商標）、PCS、3G、4G、LTE、または任意の他のタイプのセルラーネットワーク)などの通信ネットワーク3107とのネットワークインターフェース接続を確立するためにプロセッサ3101に結合された、ネットワークアクセスポートなどの1つまたは複数のネットワークトランシーバ3103を含み得る。
【０１４３】
プロセッサ3001および3101は、上記で説明した様々な実施形態の機能を含む様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであってよい。いくつかのデバイスでは、ワイヤレス通信機能専用の1つのプロセッサ、および他のアプリケーションの実行専用の1つのプロセッサなどの、複数のプロセッサが設けられてもよい。通常、ソフトウェアアプリケーションは、それらがアクセスされプロセッサ3001および3101にロードされる前に、内部メモリ内に記憶され得る。プロセッサ3001および3101は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。多くのデバイスでは、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、またはその両方の混合物であってよい。この説明の目的のために、メモリへの一般的な言及は、内部メモリ、またはデバイスに差し込まれるリムーバブルメモリ、ならびにプロセッサ3001および3101自体の中のメモリを含む、プロセッサ3001および3101によってアクセス可能なメモリを指す。
【０１４４】
前述の方法の説明およびプロセスフロー図は、例示的な例として与えられるにすぎず、様々な実施形態のステップが、提示された順序で実行されなければならないことを要求または示唆するものではない。当業者なら諒解するように、上記の実施形態におけるステップの順序は、任意の順序で実行されてよい。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は単に、方法の説明を通じて読者を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する、単数形での請求項の要素へのいかなる言及も、要素を単数形に限定するものとして解釈されるべきではない。
【０１４５】
本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概してそれらの機能性に関して上記で説明された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例およびシステム全体に課される設計制約に依存する。当業者は、説明した機能を特定のアプリケーションごとに様々な方法で実装し得るが、そのような実装決定は、本発明の範囲からの逸脱を引き起こすものと解釈されるべきではない。
【０１４６】
本明細書で開示された態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実施するように設計されたそれらの組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DPCとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DPCコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装されてよい。代替的に、いくつかのステップまたは方法は、所与の機能に専用の回路構成によって実行されてよい。
【０１４７】
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読媒体上または非一時的プロセッサ可読媒体上の1つまたは複数のプロセッサ実行可能命令またはコードとして記憶されてもよい。本明細書で開示した方法またはアルゴリズムのステップは、非一時的コンピュータ可読またはプロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェアモジュールにおいて具現化され得る。非一時的サーバ可読記憶媒体、非一時的コンピュータ可読記憶媒体、または非一時的プロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る任意の記憶媒体であってよい。限定ではなく例として、そのような非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、または非一時的プロセッサ可読媒体は、RAM、ROM、EEPROM、フラッシュメモリ、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を含み得る。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標）ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、および非一時的プロセッサ可読媒体の範囲内に含まれる。追加として、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、非一時的サーバ可読媒体、非一時的プロセッサ可読媒体、および/または非一時的コンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せまたはセットとして存在してもよい。
【０１４８】
開示された実施形態の前述の説明は、いかなる当業者も本発明を作成または使用することができるように記載されている。これらの実施形態に対する様々な変更は当業者には容易に明らかとなり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく、他の実施形態に適用され得る。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。
【符号の説明】
【０１４９】
100  セルラーネットワークシステム
102  受信機デバイス
104  セルラータワーまたは基地局
106  セルラー接続
108  サーバ
110  インターネット
112  サーバ
202  受信機デバイス
204  アプリケーション/DASHクライアント
206  マルチキャストサービスデバイスクライアント(MSDC)
208  モデムレイヤ
302  エンコーダ
304  BMSC
306  マルチキャストサービスデバイスクライアント
308  DASHクライアント
310  MPD
312  MPD
314  MPD
400  ネットワーク
402  エンコーダ
404  セグメンタ
406  ネットワーク、第1の部分、ネットワーク部分、部分
408  ネットワーク、第2の部分、ネットワーク部分、部分
410  受信機デバイス1
412  受信機デバイス2
500a  方法
500b  方法
600a  方法
600b  方法
800a  方法
800b  方法
1000  方法
1100a  方法
1100b  方法
1300  方法
1400  方法
1500a  方法
1500b  方法
1600  方法
1170  MPD
1180  MPD
2000  MPD
2102  URL
2106  期間および表現結合
2402  URL
2406  期間および表現結合
2300  MPD
2500  方法
2700  方法
2800  方法
2900  方法
3000  モバイルデバイス
3001  プロセッサ
3002  内部メモリ
3004  タッチスクリーンコントローラ
3008  無線信号トランシーバ
3010  アンテナ
3012  タッチスクリーンパネル
3014  スピーカー
3016  セルラーネットワークワイヤレスモデムチップ
3018  周辺デバイス接続インターフェース
3020  ハウジング
3022  電源
3100  サーバ
3101  プロセッサ
3102  揮発性メモリ
3103  ネットワークトランシーバ
3104  ディスクドライブ
3106  フロッピーディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ
【図１】
2018519694.tif 000003
【図２】
2018519694.tif 000004
【図３Ａ】
2018519694.tif 000005
【図３Ｂ】
2018519694.tif 000006
【図４】
2018519694.tif 000007
【図５Ａ】
2018519694.tif 000008
【図５Ｂ】
2018519694.tif 000009
【図６Ａ】
2018519694.tif 000010
【図６Ｂ】
2018519694.tif 000011
【図７】
2018519694.tif 000012
【図８Ａ】
2018519694.tif 000013
【図８Ｂ】
2018519694.tif 000014
【図９Ａ】
2018519694.tif 000015
【図９Ｂ】
2018519694.tif 000016
【図１０】
2018519694.tif 000017
【図１１Ａ】
2018519694.tif 000018
【図１１Ｂ】
2018519694.tif 000019
【図１２】
2018519694.tif 000020
【図１３】
2018519694.tif 000021
【図１４】
2018519694.tif 000022
【図１５Ａ】
2018519694.tif 000023
【図１５Ｂ】
2018519694.tif 000024
【図１６】
2018519694.tif 000025
【図１７Ａ】
2018519694.tif 000026
【図１７Ｂ】
2018519694.tif 000027
【図１７Ｃ】
2018519694.tif 000028
【図１８】
2018519694.tif 000029
【図１９】
2018519694.tif 000030
【図２０】
2018519694.tif 000031
【図２１】
2018519694.tif 000032
【図２２】
2018519694.tif 000033
【図２３】
2018519694.tif 000034
【図２４】
2018519694.tif 000035
【図２５】
2018519694.tif 000036
【図２６】
2018519694.tif 000037
【図２７】
2018519694.tif 000038
【図２８】
2018519694.tif 000039
【図２９】
2018519694.tif 000040
【図３０】
2018519694.tif 000041
【図３１】
2018519694.tif 000042
【手続補正書】
【提出日】平成29年10月23日(2017.10.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信機デバイスのタイミングドリフトを考慮するための方法であって、
ユニフォームリソースロケータ(URL)マッチングによってセグメントのインデックスを決定するステップと、
利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定するステップと、
前記利用可能性タイムラインからセグメント持続時間を決定するステップと、
前記セグメントに関する復号時間を決定するステップであって、前記復号時間が、前記セグメントが前記受信機デバイス上で利用可能になる時間である、決定するステップと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定するステップと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
を含む、方法。
【請求項２】
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定するステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定するステップを含み、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算を前記トリガするステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップを含む
請求項1に記載の方法。
【請求項３】
前記セグメント持続時間の前記比率が2分の1である、請求項2に記載の方法。
【請求項４】
前記受信機デバイスにおいて2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定するステップをさらに含み、
前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定するステップが、前記受信機デバイスにおける前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定するステップを含む
請求項1に記載の方法。
【請求項５】
前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項4に記載の方法。
【請求項６】
受信機デバイスのタイミングドリフトを考慮するための方法であって、
ユニフォームリソースロケータ(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定するステップと、
前記受信されたセグメントから生じる利用可能開始時間の変更を決定するステップと、
前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定するステップであって、前記しきい値がセグメント持続時間である、決定するステップと、
前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
を含む、方法。
【請求項７】
利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項6に記載の方法。
【請求項８】
受信機デバイスであって、
動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
ユニフォームリソースロケータ(URL)マッチングによってセグメントのインデックスを決定することと、
利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定することと、
前記利用可能性タイムラインからセグメント持続時間を決定することと、
前記セグメントに関する復号時間を決定することであって、前記復号時間が、前記セグメントが前記受信機デバイス上で利用可能になる時間である、決定することと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定することと、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
を含む、受信機デバイス。
【請求項９】
前記プロセッサが、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定することが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定することを含み、
前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算を前記トリガすることが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることを含む
ような動作を実行するためのプロセッサ実行可能命令で構成される、請求項8に記載の受信機デバイス。
【請求項１０】
前記セグメント持続時間の前記比率が2分の1である、請求項9に記載の受信機デバイス。
【請求項１１】
前記プロセッサが、2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定することをさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
前記プロセッサが、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定することが、前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定することを含むような動作を実行するためのプロセッサ実行可能命令で構成される、請求項8に記載の受信機デバイス。
【請求項１２】
前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項11に記載の受信機デバイス。
【請求項１３】
受信機デバイスであって、
動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
ユニフォームリソースロケータ(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定することと、
前記受信されたセグメントから生じる利用可能開始時間の変更を決定することと、
前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定することであって、前記しきい値がセグメント持続時間である、決定することと、
前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
を含む、受信機デバイス。
【請求項１４】
利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項13に記載の受信機デバイス。
【国際調査報告】
2018519694.tif 000043
2018519694.tif 000044
2018519694.tif 000045