(57)【要約】本発明は、DASHプレーヤーのようなストリーミングプレーヤーにブロードキャストのシナリオでメディアコンテンツを提供するための技術に関する。変動するセグメントサイズの問題（それはメディアセグメントの受信間隔における変動をもたらす）を補償するために、その後のメディアセグメントを要求するためのセグメント入手可能時間の推定が提示される。この推定は、ストリーミングプレーヤーが一定の時間間隔すなわちセグメント存続期間でメディアセグメントを受信するように、メディアセグメントの受信間隔における変化を補償する補正値を考慮する。一実施形態において、MPDファイルの中のminBufferTime値を使うことが提示され、このminBufferTimeはすなわちメディアコンテンツの変動するセグメントサイズの表示である。minBufferTimeは、前記メディアコンテンツを再生し始める前にメディアコンテンツをバッファリングするために必要な時間を示す。この推定は、クライアント、ユーザ機器(UE)またはサーバデバイス側でされてよい。UEがセグメント入手可能性を補正しているならば、UEはベースとして最初のセグメントの受信時間を使う。サーバがセグメント入手可能性を補正しているならば、ベースプラスエンドツーエンド遅延としてサーバにおけるオリジナルのセグメント入手可能時間を使う。
2016504797.tif 000002
【特許請求の範囲】
【請求項１】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーに送信され、前記方法は、
−最初のメディアセグメントを受信するステップ(S21)と、
−前記最初のメディアセグメントの受信時間を決定するステップ(S22)と、
−ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により決定された前記最初のメディアセグメントの前記受信時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S23)と、
−前記ストリーミングプレーヤーに、推定した入手可能時間を伝達するステップ(S24)と
を有することを特徴とする方法。
【請求項２】
前記最初のメディアセグメントの前記受信時間を決定するステップ(S22)が、前記最初のメディアセグメントの完全な受信におけるユーザ機器でのローカル時間を決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記最初のメディアセグメントの受信時間を決定するステップ(S22)が、受信した前記最初のセグメントのセグメント番号の推定を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記セグメント番号がテンプレート形式からまたは受信したマニフェストファイルに含まれているプレイリストから決定されることを特徴とする請求項１１乃至１３のいずれか一項に記載の方法。
【請求項５】
前記一定の時間間隔がセグメント存続期間であることを特徴とする請求項１に記載の方法。
【請求項６】
前記補正値が、前記メディアセグメントの変動するセグメントサイズを考慮しており、前記変動するセグメントサイズにより前記メディアセグメントの受信間隔における変動がもたらされることを特徴とする請求項１に記載の方法。
【請求項７】
前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記minBufferTimeは、前記サーバデバイスから受信したマニフェストファイルの中で受信することを特徴とする請求項５または６に記載の方法。
【請求項９】
前記メディアセグメント入手可能時間(Avst)を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定に基づいており、前記最初のメディアセグメントは前記メディアコンテンツの現在のメディアセグメントであることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記補正値が、前記セグメント存続期間を前記minBufferTimeから差し引くことで更新される（NewAvst=time_of_first_seg_received + minbufferTime - segment_duration）ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の現在のメディアセグメントのセグメント番号に設定されることを特徴とする請求項３または４または７乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記メディアセグメント入手可能時間を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定と、前記メディアコンテンツ中の前記最初のメディアセグメント(startNumber)とに基づくことを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１３】
前記補正値が、前記メディアコンテンツの中の前記最初のメディアセグメントと前記メディアコンテンツの中の現在のメディアセグメント(SegmentIndex)との間で経過する前記セグメント存続期間を前記minBufferTimeから差し引くことで更新される（NewAvst = time_of_first_seg_received + minbufferTime - ((SegmentIndex-startNumber) * segment duration)）ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の前記最初のセグメントのセグメント番号に設定されることを特徴とする請求項３または４または１２または１３に記載の方法。
【請求項１５】
前記補正値が、前記メディアセグメントの変動するセグメントサイズを補償する明示的な可変セグメントサイズ値であることを特徴とする請求項５に記載の方法。
【請求項１６】
前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、前記推定した入手可能時間によって前記マニフェストファイルを更新するステップと、前記ストリーミングプレーヤーに前記マニフェストを提供するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、HTTPヘッダーを修正するか、または新しいHTTPヘッダーをHTTPレスポンスに追加するステップと、それをストリーミングプレーヤーに送信するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
ストリーミングプレーヤーに推定した前記入手可能時間を伝達するステップ(S24)が、修正された前記minBufferTimeと前記セグメント番号とをさらに伝達するステップを含むことを特徴とする請求項１または１１または１４または１６または１７に記載の方法。
【請求項１９】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーに送信され、前記方法は、
−前記メディアセグメントが前記サーバデバイスにおいて送信のために入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するステップ(S31)と、
−メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S32)と、
−前記ストリーミングプレーヤーに前記推定したメディアセグメント入手可能時間を伝達するステップ(S33)と
を有することを特徴とする方法。
【請求項２０】
前記補正値は、前記メディアセグメントの変動するセグメントサイズを考慮することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項１９または２０に記載の方法。
【請求項２２】
前記補正値が、エンドツーエンドシステム遅延(max_offset)を含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２３】
前記補正値が、クロックドリフトの上限を示すドリフトアヘッド値（maxdriftahead）を含むことを特徴とする請求項１９乃至２２のいずれか一項に記載の方法。
【請求項２４】
前記補正値が、ライブエンコーダの実装および遅延プロファイルに依存することを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２５】
前記推定した入手可能時間をストリーミングプレーヤーに伝達するステップ(S33)が、前記推定したメディアセグメント入手可能時間によりマニフェストファイルの中の前記オリジナルのメディアセグメント入手可能時間（availibilityStartTime）を置換するステップと、前記ストリーミングプレーヤーへ前記マニフェストファイルを送信するステップとを含むことを特徴とする請求項１９に記載の方法。
【請求項２６】
さらに、前記minBufferTimeが、それを0に設定することによって修正され、修正された前記minBufferTimeが前記マニフェストファイルとともに前記ストリーミングプレーヤーに提供されることを特徴とする請求項２４に記載の方法。
【請求項２７】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたユーザ機器デバイス(41)であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーに送信され、前記ユーザ機器デバイスは、
−最初のメディアセグメントを受信するよう構成された受信機 (42)と、
−前記最初のメディアセグメントの受信時間を決定するよう構成された決定ロジック部(44)と、
−前記ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により、決定された前記最初のメディアセグメントの受信時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成された推定ロジック部(45)と、
−前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(46)と
を有することを特徴するユーザ機器デバイス。
【請求項２８】
前記推定したメディアセグメント入手可能時間によってマニフェストファイルを修正するための修正ロジック部を更に有することを特徴とする請求項２７に記載のユーザ機器デバイス。
【請求項２９】
前記修正ロジック部が、HTTPヘッダーをストリーミングプレーヤーに送信するために、HTTPヘッダーを修正するよう、または新しいHTTPヘッダーを追加するよう構成されることを特徴とする請求項２８に記載のユーザ機器デバイス。
【請求項３０】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたサーバデバイス(51)であって、前記メディアセグメントが前記サーバデバイスからストリーミングプレーヤーに送信され、前記サーバデバイスは、
−前記サーバデバイスにおいてメディアセグメントが入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するよう構成された受信機(54)と、
−前記メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成されたプロセッサ(53)と、
−前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(52)と
を有することを特徴とするサーバデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
この開示は、伝送遅延が変動する伝送リンク上で送信されているメディアデータをユーザに提供するための技術に関連している。
【０００２】
この開示は、メディアセグメントの伝送を提供しているブロードキャスト技術を用いるネットワークソリューションの中で実行できる。特に、ここに議論された実施形態は、MBMS、メディアセグメントのeMBMS伝送、またはDSLアクセスシステムにおけるIPマルチキャスト(IPTV)またはDVB-Sのような他のブロードキャストの技術を使用するシナリオの中で使うことができる。
【背景技術】
【０００３】
アダプティブHTTPストリーミング技術はメディア品質を選択するクライアントに依存している。サーバまたはコンテンツプロバイダは、すべての入手可能な品質のレプリゼンテーション、及び、それらを取り出す方法、例えばメディアコンテンツのレプリゼンテーションが異なるメディアビットレートについて異なる可能性があること、及び、サーバからそのレプリゼンテーションにアクセスする方法をいわゆるマニフェストファイル中に記述する。マニフェストファイルはストリーミングセッションの最初に少なくとも１回取り出されて、セッションの間にアップデートされることがある。ダイイナミックアダプティブストリーミングオーバーHTTP(DASH)は、動的なストリーミング技術であり、それによって"Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2012(E), Version 2.1c2 で説明されているように、現在入手可能なリンクビットレートへとメディアストリームを調整する。
【０００４】
DASHは、クライアントが制御するアダプティブHTTPストリーミングプロトコルとして設計されている。すなわち、サーバは、例えばマニフェストファイルに入手可能なメディア品質のセットを記述し、クライアントは、リンクビットレートに応じてそのリンクビットレートにマッチしているメディアレプリゼンテーション（すなわちメディアビットレート）を選択する。一般に、DASHソリューションは、様々なメディア品質いわゆるレプリゼンテーションを持つコンテンツを提供するように構成されたDASHサーバを備えており、クライアント側では、DASHクライアントは様々な品質を持つメディアコンテンツを要求するよう構成されている。
【０００５】
アダプティブHTTPストリーミング技術のほとんどは、サーバから存続的にメディアセグメントを取り出すことをクライアントに要求する。一定のメディア時間（例えば１０秒のメディアデータ）がメディアセグメントの中に含まれている。特定のメディアレプリゼンテーションの各セグメントはマニフェストの中で示された特定の時間にサーバで入手可能にされる。異なる品質のレプリゼンテーションのセグメントをダウンロードするためのクライアント側でのURLの作成方法はマニフェストの中でも記述される。
【０００６】
図１はDASH環境においてセグメントの取り出しの原則を示す。クライアント（DASHクライアント）はサーバ（DASHサーバ）と通信する。
【０００７】
マニフェストファイルは、HTTP GETマニフェストファイルメッセージ10の応答として受信され、最善の品質を決定するために処理される（11）。次のステップ12において、クライアントは最低品質でデータを要求し（HTTP GET Segment#1 from Lowest Quality）、ダウンロードレートの測定が実行される（13）。クライアントは、コンテンツデータの受信のための適切な品質を決定するために、メディアセグメント14を受信する間、存続的にリンクビットレートを測定する。レプリゼンテーションを変更する決定がされるならば、クライアントはいつでも別の品質のレプリゼンテーションに変更することができる（15）。図１に応じた実施形態において、中間品質を持つメディアデータを要求すること（HTTP GET Segment#2 from Medium Quality 16）と、ダウンロードレートの測定を続けることが決定される（17）。
【０００８】
メディアセグメントに分割されているメディアコンテンツを処理するために、マニフェストファイルは入手可能である必要がある。マニフェストファイルは、オプションによりストリームと同じ帯域で、または別個のサービス告知方法経由で独立して配布することができる。アップルのHLSの場合には、マニフェストはm3u8フォーマットのプレイリストファイルとしてフォーマットされる。3GPP/MPEG DASH場合には、マニフェストはメディアプレゼンテーション記述（MPD）ファイルと呼ばれるXML構造である。MPDはリスト又はすべてのメディアセグメントのURLの前記リストを生成する方法を含んでおり、それはメディアセッションに属していて、次のメディアセグメントを取り出すために使われる。
【０００９】
DASHメディアセグメントを、eMBMS（LTEマルチメディアブロードキャストマルチキャストサービス）などのブロードキャストシステム上で配信する可能性もある。セルまたは任意のブロードキャストエリアの中の多くのユーザが同じビットストリーム品質を利用する場合に、ブロードキャストは効率的である。従って、同じサービスを、例えば都市地域ではより高いビットレートで、郊外地域ではより低いビットレートで、多くのユーザに対して同時にブロードキャストすることが可能である。
【００１０】
従って、DASHプレーヤーはブロードキャストまたはユニキャスト経由でコンテンツを受信できる。しかし、DASHプレーヤーは、電話がブロードキャストまたはユニキャストまたはその両方のサービスアリア内にあるかの情報を全く持っていない。サーバ側のライブエンコーダ（LE）は、MPDを生成し、また、このファイルが、ユニキャストまたはブロードキャストのどちらによって利用されるか知らず、そして多くの場合同一のコンテンツがブロードキャスト及びユニキャストの両方で配布されるであろう。
【００１１】
さらに、連続的なメディアコンテンツストリームをメディアセグメントのシーケンスに分割することによってDASHは動作する。DASHセグメントは一般に、ライブエンコーダ（LE）またはセグメンタによってTCPまたはUDPセグメントのような複数のトランスポートプロトコルセグメントに再分割され、そこにおいてはセグメントはおおよそ一定の時間的存続期間（いわゆるセグメント存続期間）を有する。
【００１２】
現在の再生時間がMPDに記述されたメディアの終端に近づくか、または、最後のチェック以来、MPDに示された最小更新時間よりも長い時間に達するときに、新しいMPDがサーバから取り出される。
【００１３】
メディアセグメントは、平均100kByteサイズであるが、しかし例えば130kByteまでの、より大きいものもあり、また例えば70kByteまでの、より小さいものもあり、そして、メディアセグメントを生成するときに、或るセグメント存続期間を有する各セグメントが、異なる数のTCPまたはUDPセグメントをそれぞれ持つかもしれない。セグメントサイズは選択されたレプリゼンテーションにも依存する。クライアントは、ビットレートを適応させるためにレプリゼンテーションを切り替えることを選択できる。最終的に、クライアントはファイルのソート済みシーケンスを取り出し、ファイルを連続的なメディアストリームに連結し直し、コンテンツは再生されて、セグメントは存続して要求される。
【００１４】
LTEブロードキャスト(eMBMS)上でDASHを実行するときに、ライブエンコーダはブロードキャストマルチキャストサーバ(BM-SC)中にメディアセグメントをアップロードする。BM-SC中のFLUTEプロトコルは、メディアファイルをメディアセグメントのシーケンス（ここではUDPパケットまたはセグメント）に区切ることについて関心がある。各UDPパケットには固有にシーケンス番号がつけられ、その結果クライアントがファイルを再組み立てすることができる。
【００１５】
IETF FLUTEプロトコル(RFC3926)はブロードキャスト送信上でのファイル配信のために使われる。FLUTE配信セッションは、SDP（セッション記述プロトコル）ファイルにより定義され、そのファイルは、IPマルチキャストアドレスやUDPポート、またクライアントにモバイルファイルのブロードキャスト配信を受信できるようにするためにMBMSのためのTMGI（一時モバイルグループID）などのすべてのパラメータを含んでいる。従って、FLUTEは、トランスポートプロトコルとしてUDPを用いてブロードキャストリンク上でファイルの配信を許すプロトコルである。
【００１６】
マニフェスト（DASH場合にはMPDと呼ばれる）中で提供されるように、DASHプレーヤーは、URLを使って、独立したファイルとしてメディアセグメントのシーケンスを取り出す。DASHをMBMS上に送信するときには、セグメントはリモートサーバーからクライアントによって取り出されない。代わりに、セグメントは、ブロードキャスト上のFLUTEを使ってプッシュ配信される。
【００１７】
ブロードキャストのシナリオにおいて、ひとつのメディアセグメントが、それがDASHプレーヤーにより入手可能となり得る前に、最初にeMBMSクライアントによって受信されなければならない。これは、ユニキャストされたレプリゼンテーションと比較してブロードキャストされたレプリゼンテーションのためのペナルティである。UE（ユーザ機器）がブロードキャストのサービスエリア内にあるか否かをDASHプレーヤーは知らない。MPDファイルの中で記述される時間に、DASHプレーヤーは続きのデータセグメントを注文する。しかし、要求された時間におけるブロードキャストの場合には、メディアセグメントはサーバで入手可能でないかもしれず、UEのローカルキャッシュにはないかもしれない。この結果、DASHプレーヤーは、まだ受信していないセグメントを要求する。
【００１８】
ブロードキャストの場合にも、セグメントは平均100kByteサイズであり、例えば130kByteまでの、より大きいものや、例えば70kByteまでの、より小さいものもあり、セグメントを生成するときに、各セグメントは様々な数のUDPセグメントを持つことがある。ブロードキャストの場合には、ブロードキャスト送信に割り当てられた一定のビットレートのベアラがある。例えば割り当てられたビットレートが1Mbpsであれば、送信されるサイズ500kbのセグメントについては0.5秒、サイズ1500kbのセグメントは1.5秒を必要とする。メディアセグメントのサイズが異なることにより、セグメントの送信の間のセグメント存続期間が変わり、その結果、メディアセグメントの完全な受信のための受信時間間隔は変わる。しかし、DASHプレーヤーは、メディアセグメントが固定間隔、すなわちセグメント存続期間で入手可能になると仮定している。さらに、BM-SCからUEに至るまでの間のエンドツーエンド遅延は、ほかに対するシステムと異なる。それは、eNodeBの上で、さらにまたネットワーク展開においてもどのように一定のパラメータが設定されているかによる。BM-SCハードウェアの速度はまた、エンドツーエンドシステムへも影響を及ぼす。この理由により、エンドツーエンド遅延は、主として異なるベンダ間で、また、メディアセグメントを提供するときに異なるBM-SCによって提供された２つのシステムの間でさえ異なることがある。
【００１９】
しかし、これらのさまざまなシステムは、システム展開が完全に透過的な１つのライブエンコーダによって提供される。従って、LEは、一方で、ネットワーク経由の送信のために異なる時間的期間がかかるさまざまなセグメントサイズを発生させ、他方で、ネットワーク内のエンドツーエンド遅延の変動により、メディアセグメントの送信時間の変動が増大する。
【００２０】
さらに、UEはいつも時間がシステムと同期されているわけではない。ある種のモバイル機器のクロックの時間の同期は必要である。なぜなら、様々なプラットフォームが提供している、デバイスの特性及び温度、振動、湿度の変化における外部の影響に依存して異なるドリフト率を持つ様々なクロックのせいで、ハードウェアクロックは時間的に互いからドリフトしていくためである。様々なオペレータからの様々なデバイスが時間の正確性の問題を持つという公知の問題がある。いくつかはほんの数秒、いくつかは数分以上である。その結果、クロックのドリフト率はさらに、メディアセグメントの様々なセグメント受信時間に影響する。
【００２１】
さらに、サーバ上でのセグメントの入手可能性を計算するために、MPEG DASHは実時間を用いる。それにより、UEが最も新しいメディアの受信を正確に計算できるよう、UEはシステムと適切に時間同期させられることが必要となる。そのため、上述した特徴により、一定のビットレートのベアラ上のメディアセグメントの送信期間の変動の増大を招き、その結果、メディアセグメントの受信における時間間隔の変動は、メディアセグメントが要求された時間に入手可能でないならば、続きのセグメントを注文する際にDASHプレーヤーが規則的にエラーメッセージを受けることがあり得るという状況をもたらす。
【発明の概要】
【００２２】
ユーザへのメディアデータの効率的な提供のための技術への要求がある。特に、示されたデータの経験レベルを増大させる要求がある。
【００２３】
本発明は独立クレームに具現化される。有利な実施形態は従属クレームの中で記載される。
【００２４】
この要求は、メディアセグメントを含むメディアコンテンツをストリーミングプレーヤーに提供する方法により満たされる。ここでメディアセグメントはサーバデバイスからストリーミングプレーヤーに送信される。できれば、送信はブロードキャスト送信上で行われる。この方法は、最初のメディアセグメントを受信するステップと、次のステップにおいてその最初のメディアセグメントの受信時間を決定するステップとを含む。さらに、その後のメディアセグメントを要求するためのメディアセグメントの入手可能時間を、ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するよう、決定された最初のメディアセグメントの受信時間をメディアセグメントの受信間隔の変動を補償する補正値により修正することによって推定する。最終的に、推定された入手可能時間はストリーミングプレーヤーに伝達される。
【００２５】
さらに、この要求は、メディアセグメントを含むメディアコンテンツをストリーミングプレーヤーに提供する方法によって満たされる。ここで、メディアセグメントはサーバデバイスからストリーミングプレーヤーに送信される。できれば、送信はブロードキャストの送信上で行われる。この方法の第１のステップにおいて、メディアセグメントがサーバデバイスで送信のために入手可能にされる時間を示すオリジナルメディアセグメント入手可能時間を推定する。次に、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を、メディアセグメントがストリーミングプレーヤーで一定の時間間隔で入手可能にされるよう、オリジナルメディアセグメント利用時間をメディアセグメントの受信間隔の変動を補償する補正値により修正することによって推定し、推定された入手可能時間はストリーミングプレーヤーに伝達される。
【００２６】
さらに、この要求は、メディアセグメントを含むメディアコンテンツをストリーミングプレーヤーに提供するよう構成されたユーザ装置（UE）によって満たされる。ここで、メディアセグメントはサーバデバイスからストリーミングプレーヤーに、できればブロードキャスト送信で送信される。このUEは、最初のメディアセグメントを受信するよう構成されたレシーバを含む。さらに、UEは、最初のメディアセグメントの受信時間を決定するよう構成された決定ロジック部を含む。さらにUEは、その後のメディアセグメントを要求するためのメディアセグメントの入手可能時間を、ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するよう、決定された第一のメディアセグメントの受信時間をメディアセグメントの受信間隔の変動を補償する補正値により修正することによって推定するよう構成された推定ロジック部を含む。さらに、ストリーミングプレーヤーに推定した入手可能時間を伝達するよう構成されたセンダがある。
【００２７】
さらに、この要求は、メディアセグメントを含むメディアコンテンツをストリーミングプレーヤーに提供するサーバデバイスによって満たされる。ここで、メディアセグメントはサーバデバイスからストリーミングプレーヤーに送信される。できれば、送信はブロードキャスト送信上で行われる。このサーバデバイスは、メディアセグメントがサーバデバイスで送信のために入手可能にされる時間を示すオリジナルメディアセグメント入手可能時間を推定するよう構成された受信機を含む。また、その後のメディアセグメントを要求するためのメディアセグメントの入手可能時間を、メディアセグメントがストリーミングプレーヤーで一定の時間間隔で入手可能にされるよう、オリジナルメディアセグメント利用時間をメディアセグメントの受信間隔の変動を補償する補正値により修正することによって推定するよう構成されたプロセッサをサーバデバイスは含む。また推定された入手可能時間をストリーミングプレーヤーに伝達するよう構成されたセンダ送信機がある。
【図面の簡単な説明】
【００２８】
以下において、本発明はさらに図に示した模範的な実施形態に関して説明されるであろう。
【図１】図１は、アダプティブHTTPストリーミングクライアントの上でセグメントを取り出すための実施形態を示す。
【図２】図２は、MPDファイルを使うための実施形態を示す。
【図３】図３は、一実施形態に従うユーザデバイスにおける方法のフローチャートを示す。
【図４】図４は、一実施形態に従うサーバデバイスにおける方法のフローチャートを示す。
【図５】図５は、一実施形態に従うユーザデバイスを図式的に示す。
【図６】図６は一実施形態に従うサーバデバイスを図式的に示す。
【発明を実施するための形態】
【００２９】
以下の説明においては、制限ではなく説明の目的のために、本発明についての完全な理解を提供するために特定のネットワーク環境及び通信標準などの具体的な詳細が記述される。本発明が、これらの特定の詳細を逸脱する他の実施形態の中で行われ得ることは当業者に明白になるであろう。例えば、当業者は、本発明が例えばUMTS、GSM、またはLTEネットワークのようなどのようなワイヤレスネットワークによってでも実施されてもよいと理解するであろう。別の例として、この発明はまたWLANまたはブルートゥースシステムなどの短距離のワイヤレスネットワークにおいて、またはワイヤラインネットワーク、例えばIMSネットワークのような任意のIPベースのネットワークにおいて実装されてもよい。
【００３０】
この発明は一定のブロードキャストネットワーク、例えばテレビによって、またはブロードキャストネットワークと移動通信ネットワーク（例えばDVB-H（デジタルビデオブロードキャストハンドヘルド）と3GPP移動通信ネットワーク）とを含むハイブリッドネットワークによって実施されてもよい。基本的に、この発明は、ビデオコンテンツを配布できるどのようなネットワーク環境の中ででも実施できる。
【００３１】
メディアコンテンツはビデオデータ、音声データ、または例えばビデオと音声データの組み合わせなどの任意の他の種類の（マルチ）メディアデータを含んでよい。コンテンツは、テレビ、携帯テレビ、またはIPTVサービスなどのマルチメディアサービスのフレームワークの中で提供され得る。以下において、用語「メディアデータ」、「メディアコンテンツ」、「コンテンツデータ」は同義語として使われる。
【００３２】
メディアセグメントは、例えばビデオクリップのような連続的なメディアデータの形式で生成され、一定量のメディアコンテンツを含んでいる。セグメントは例えばDASHセグメントであってよい。
【００３３】
用語「ライブエンコーダ（LE）」、「ライブセグメンタ」、「ライブトランスコーダ」は同義で用いられ、DASHライブコンテンツを作成するために必要な任意のビデオ前処理機器を含むデバイスを表す。特にLEは、連続的なメディアコンテンツからメディアセグメントを生成するよう構成されている。
【００３４】
新しいサービスまたはアプリケーションまたはメディアコンテンツが提供される場合、入手可能なメディアコンテンツを要求するために情報を提供しているユーザサービス記述(USD)、または対応するセッション記述プロトコル(SDP)または対応するメディアプレゼンテーション記述(MPD)のような、対応するサービス告知(SA)属性と記述ファイルとが生成される。USDファイルはSDPとMPDのための親フラグメントであり、それはMBMSユーザサービス(3GPP TS 26.346 rel11)のための追加的サービスパラメータを含んでいる。以下において、MPDマニフェストファイルが使われるが、それが、本発明についての制限としてはみなされない。
【００３５】
ダイナミックアダプティブストリーミングオーバーHTTP（DASH）は、メディアコンテンツの提供のために使われるプロトコルである。前記コンテンツはブロードキャスト送信の場合にはFLUTEプロトコル上で提供するこができる。すでに説明したように、DASHプロトコルが、どのように後に続くメディアセグメントを要求するかについての情報を含むMPDファイルをセッションの最初に提供する。その他の情報の中で、次に要求されるはずのメディアコンテンツのURLが提供される。
【００３６】
ストリーミングプレーヤーは、受信されたストリーミングデータをユーザに提供するよう構成されたクライアント側のプレーヤーである。好適には、ストリーミングプレーヤーは、メディアデータまたはメディアコンテンツの受信レートを入手可能な無線リンクレートに適応させるように設定されているアダプティブHTTPストリーミングプレーヤーである。さらに、ストリーミングプレーヤーは、サーバにメディアセグメントを要求するように構成される。一実施形態において、ストリーミングプレーヤーがDASHプレーヤー、特にMPEG-DASHプレーヤーであることが提示される。それに加えてアップルHTTPライブストリーミングなどの他のアダプティブHTTPストリーミング方式がサポートされてもよい。
【００３７】
クライアントは端末装置またはユーザ機器(UE)のようなどのようなクライアントデバイスであってもよい。一実施形態において、クライアントは、DASHプレーヤーのようなストリーミングプレーヤーと本発明を実行するためのプロセッサとを備えている。しかしながら、ストリーミングプレーヤーはユーザ機器の一部でなくともよい。以下において、用語「クライアント」と「ユーザ機器」（UE）は同義語として使われる。明示的に言及されないならば、用語「クライアント」または「UE」は本発明を実行し、ストリーミングプレーヤーに結果を提供しているプロセッサの意味で使われる。
【００３８】
サーバデバイスは、システムにおいてサーバ機能性を提供し、例えばMPDを修正することによってセグメント入手可能時間の修正を実行するよう構成されているどのようなデバイスであってもよい。一実施形態において、MPDは、LEとUEとの間のインタフェースとして作動しているエンティティによって修正されてよい。この目的のためのエンティティをセットアップしている専用サービスもあってよい。さらなる実施形態においては、各BM-SCが、それが管理しているシステムのエンドツーエンド遅延を知るので、MPDは直接BM-SCによって修正される。
【００３９】
BM-SCは、ブロードキャストに適したフォーマットの中にDASHメディアセグメントを包むことに関与するブロードキャストサーバである。DASHメディアセグメントは一般に１つのIPパケットより大きい。ユニキャストの場合には、すでに述べたように、セグメントは、複数のTCPセグメントを使って送信される必要がある。ブロードキャストの場合には、セグメントは複数のFLUTE/UDPパケットに分割される。オプションで、FEC冗長量が計算されて、セグメントの送信にオーバーヘッドとして追加される。BM-SCは各セグメントのための手続きを繰り返している。LTEブロードキャスト(eMBMS)上でDASHを実行するときに、ライブエンコーダは、BM-SCの中に例えばWebDAVを使ってメディアセグメントをアップロードする。WebDAVは、HTTPサーバにファイルをアップロードするためのRFCで定義されたプロトコルである。
【００４０】
セグメント入手可能性は、ストリーミングプレーヤーに提供される、「セグメントは現在用意できている」こととしてここでは定義される。別の定義は、メディアセグメントのためのメディアコンテンツがライブエンコーダに現在手可能で、セグメントが「セグメント入手可能時間プラスセグメント存続期間」で配布のために入手可能になることである。
【００４１】
補正値は、メディアセグメントのセグメントサイズ変動性に依存してもよい。
【００４２】
セグメントサイズ変動性はすでにライブエンコーダLEによってもたらされている。LEによって生成されるようなメディアセグメントは、それらがUDPまたはTCPデータパケットのような様々な数のデータパケットを含むという意味において、さまざまなサイズを持っている。LEはベンダ固有である。エンドツーエンド遅延を小さく保ちつつ圧縮効率を上げるために、各ライブエンコーダベンダはそれ自身のアルゴリズムを持っている。さらに、使用されたプロファイルは、例えば除外されたか、または設定された低いエンドツーエンド遅延のようにみなされる。これは変動するセグメントサイズを提供するライブエンコーダを結果として生じている。また、ブロードキャストの場合には、伝送リンク上の一定ビットレートのベアラは、ブロードキャストされたデータを送信するために提供される。様々なセグメントサイズを持つデータセグメントは、伝送リンク上の送信のために様々な時間を要し、それによりメディアセグメントの受信間隔の変動がもたらされる。LEは、メディアビットレートおよび符号化ピクチャバッファに基づいて、アンダランを避けるため、再生を開始する前にどのくらいの時間UEがコンテンツをバッファすべきであるかがわかる。従って、クライアント側でのデータの追加のバッファリングは、可変セグメントサイズの影響を補償するために利用される。
【００４３】
さらに、補正値はまた、エンドツーエンドシステム遅延およびドリフトアヘッド時間（drift ahead time）を考慮してもよい。
【００４４】
一般に、一定の受信間隔で、例えばセグメント存続期間でセグメントが入手可能であるとストリーミングプレーヤーがわかるような方法で補正値を提供することが提示されている。通常、一定の受信間隔で、例えばセグメント存続期間でメディアセグメントを受信することが期待されている。しかしながら、変動するメディアセグメント送信の存続期間によって、例えば変動するセグメントサイズによって、連続的なセグメントの受信の間のクロック差として定義される受信間隔は一定でなく、変動する。補正値の役割は、メディアセグメントの受信における変動を補償することである。
【００４５】
以下において、ユニキャストUCおよびブロードキャストBCの場合に、コンテンツをダウンロードしている間のふるまいのいくつかの観察が示される。
【００４６】
以下において、図２に従ってMPDのレイアウトが示される。MPDは3つの主要な成分、すなわちピリオド、レプリゼンテーション、およびセグメントを含む。図２に描かれるように、ピリオド成分はMPDの最も外側の部分である。ピリオドは一般に、逐次再生されるメディアのより大きな部品である。ピリオドの内部で、コンテンツに複数の異なる符号化がされることがあり得る。代替たり得るものの一つ一つがレプリゼンテーションと呼ばれる。これらの代替のレプリゼンテーションは、例えば異なるビットレート、フレームレート、またはビデオ解像度を持つことができる。最終的に、各レプリゼンテーションはHTTP URLによって一連のセグメントを記述する。それらのURLは例えばプレイリストの形でレプリゼンテーションの中に明示的に記述されるか、或いは、クライアントがレプリゼンテーションの各セグメントのための有効なURLを導くことのできるテンプレート構造を通して記述される。MPDフォーマットは柔軟で、MPEG-2 TSなどの他のメディアコンテナフォーマットをサポートすることができる。
【００４７】
テンプレート形式において、図２の３番目のボックスに例示するように、URLは、テンプレートの一定の部分をインデックスｉにより置換することによって構成される。テンプレート形式はC printfフォーマットの中の以下の形式を持ってもよい。
http://ex.com/path/media-segment-%d.3gs
ここで%dが、その後のメディアセグメントを要求するために使われるURLを結果として生じるためにｉの値によって置換される。
【００４８】
インデックス10を持つセグメントが要求されるのであれば、つまりi==10ならURLは、http://ex.com/path/media-segment-10.3gsの形式を持ち、i==11であるならば、http://ex.com/path/media-segment-11.3gsである。
【００４９】
URLがプレイリストの形で提供される場合には、レシーバは、URLのリストを配列とみなし、iを関連するメディアセグメントを示している配列の中のインデックスとみなすことができ、ここで配列は通常、値１で始まる。
【００５０】
MPDはUE側でのバッファリングについての情報をさらに含むことができる。LEは、メディアビットレートおよび符号化ピクチャバッファに基づいて、アンダーランを避けるために、UEが再生を開始する前に、どのくらいの時間、コンテンツをバッファリングすべきであるかを知っているので、LEはいわゆるminBufferTimeを決定する。minBufferTimeは、UEに、該UEが、メディアセグメントの受信間隔の変動を補償するために、最初のビットの受信の後にminBufferTime期間の間、コンテンツをバッファリングすると思われていることを知らせる。レプリゼンテーションのセグメントが、仮定した一定のビット／秒（bps）単位のビットレートで連続的に配信されると仮定し、そのレプリゼンテーションがこのビットレートで連続的に配信されるならば、MPD属性である@startWithSApまたは任意のセグメントインデックスボックス（'sidx'ボックス）のいずれかにより示される任意のサービスアクセスポイント（SAP）（SAPはそこからのコンテンツのレンダリングをUEが開始できるポイントである）から開始すると、クライアントは、minBufferTime * バンド幅ビットが受信された後に開始される再生を提供する連続的な再生のための十分なデータを持つことが保証できる。
【００５１】
MPDはまた、ストリームの最初のセグメントがサーバ上でダウンロード可能になる時間であるavailabilityStartTimeを含んでもよい。クライアントは、マニフェストファイルから、ライブストリームの開始時間、特にavailabilityStartTimeを読む。クライアントが適切に時間的に同期されているならば、それはサーバ上の最新の入手可能なメディアセグメント、すなわちメディアセグメントのどの存続時間も計算することができる。すなわち、クライアントは、受信する場合には、MPD内で送信されるavailabilityStartTime及びセグメント存続期間(segment duration)から計算されるメディアセグメントiを要求でき、従って、availabilityStartTime + i * segment durationは、次のメディアセグメントを要求するための時間である。
【００５２】
ユニキャストの場合には、簡素化したシナリオの中に要約すれば、サーバは最初のメディアセグメントNを時間tに入手可能にし、前記セグメントのavailabilityStartTimeを記述しているMPDファイルをクライアントに提供する。時間tから進むと、UEは、その後のセグメントを要求することによってセグメントをダウンロードし始めることができ、ここでクライアントが１つの（またはより多くの）適したレプリゼンテーションを選び、クライアント側の現在のローカル時間と一致しているセグメントを要求する。時間tの前に要求する場合、サーバはエラーメッセージ（404 - file not found HTTPステータスメッセージ）を応答する。セグメントのダウンロードはしばらくの時間、少なくともセグメント存続期間かかる。従って、プレゼンテーションを開始する前に、クライアントは少なくともminBufferTimeの受信したコンテンツをバッファリングする。minBufferTimeはすなわちダウンロードを終了するために、クライアントに必要なヘッドルームを与える。それは、例えば可変セグメントサイズに起因するダウンロード期間及びその変動を補償する。
【００５３】
ブロードキャストの場合には、サーバは最初のメディアセグメントNを時間tにBM_SCにより入手可能にする。時間tから進むと、いかなる要求も待つことなく、BM_SCはクライアントにセグメントをプッシュする。いくらかの時間の後に、セグメントNはUEで、特にクライアントキャッシュ内で入手可能になる。セグメントのダウンロードの間、セグメントが今回キャッシュの中で完全に入手可能なわけではないので、DASHプレーヤーはそのセグメントを要求するときにクライアントからエラーメッセージを得るであろう。MPDファイルの中で記述され、DASHプレーヤーに提供されるようなavailabilityStartTimeは、すなわち、最初のセグメントがBM-SCの上で入手可能な時間を記述する。
【００５４】
本発明の実施形態によると、セグメント入手可能時間の修正が提示される。本実施形態は、MPDにおけるavailabilityStartTimeの値がユニキャストとブロードキャストについては相違するととみなす。
【００５５】
セグメント入手可能時間に基づいて、DASHプレーヤーがそのセグメントの取り出しプロセスを調整することが提示される。ユニキャスト上のDASHのために、このセグメント入手可能性は、セグメントが送信のためにサーバの上で入手可能にされる時間に等しい。ブロードキャスト上のDASHの場合に、セグメント入手可能性は、セグメントがDASHプレーヤーのためにUEの上で入手可能にされる時間に等しい。
【００５６】
従って、可変セグメントサイズの問題（それはメディアセグメントの受信間隔の変動をもたらしている）を補償するために、その後のメディアセグメントを要求するためのセグメント入手可能時間を推定することが提示される。この推定は、ストリーミングプレーヤーが一定時間間隔で、すなわちセグメント存続期間にメディアセグメントを受信するように、メディアセグメントの受信間隔の変動を補償する補正値を考慮する。
【００５７】
一実施形態において、MPDファイルからminBufferTimeの値を用いることが提示される。minBufferTimeはすなわちメディアコンテンツの変動するセグメントサイズの表示である。minBufferTimeは、前記メディアコンテンツを再生し始める前にメディアコンテンツをバッファリングするために必要とされる時間を示す。UEがセグメント入手可能性を補正しているならば、UEはベースとして最初のセグメント受信の時間を用いる。サーバデバイスがセグメント入手可能性を補正しているならば、サーバデバイスはベースとしてサーバでのオリジナルのセグメント入手可能時間を用いる。
【００５８】
以下において、ユーザ側で実行される実施形態に従って、現在開示する実施形態は複数のステップを持つフローチャートを示している図３に関連して示される。
【００５９】
ステップS21において、UEは、最初のメディアセグメントを受信する。最初のセグメントの受信は、UEが進行中のブロードキャストストリームを受信する(tune in)ことを意味している。ブロードキャストストリーム上のライブDASHの受信において、クライアントは最初の完全なセグメントの受信を待つ。その結果、受信したメディアセグメントは、前記セグメントを再生する前にUE側で記憶される。それはすなわち、それらをDASHプレーヤーに提供することによって、ということを意味している。
【００６０】
次のステップにおいて、UEは最初のメディアセグメント2の完全な受信の時間を決定する（S22）。
【００６１】
ステップS23において、次のメディアセグメントのためのセグメント入手可能時間は、ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、メディアの受信間隔における変動を補償している補正値によって最初のメディアセグメントの完全な受信の時間を修正することによって決定される。
【００６２】
次のステップ（S24）において、推定入手可能時間は、例えば、直接MPDファイルをアップデートするか、或いはHTTPレスポンスに新しいHTTPヘッダーによって追加し、MPDファイルをアップデートするためにサーバにそれを返送することにより、DASHプレーヤーのようなプレーヤーに伝達する。
【００６３】
以下において、図３のいくつかのステップはより詳細に説明される。
【００６４】
図３によれば、時間を決定するステップ（S22）は、メディアセグメント全部の受信のときにユーザ機器においてローカル時間を決定することを含む。UEはメディアセグメントの完全な受信の時間を測定する。UEは、それ自身のデバイス時間を使って、受信イベントの時間を捕捉する。その結果、UEは、信号、例えば、セグメントを受信した13.05を受信する。
【００６５】
時間を決定するステップ（S22）はまた受信した最初のセグメントのセグメント番号の推定を含む。セグメント番号はテンプレート形式から、または受信したマニフェストファイルに含まれているプレイリストから決定される。
【００６６】
従って、各セグメントは例えばセグメントURLによって固有に識別される。MPDファイルとともに、クライアントはセグメント番号を見つける。テンプレートベースのURLが用いられる場合には、図２について説明されるように、セグメント番号はURL内で符号化される。プレイリストベースのURLが用いられる場合には、クライアントは、MPD内で一致するURLエントリを発見する必要があり、受信したセグメントの番号を見つけるために、プレイリストテーブルのURLエントリインデックスを利用する。
【００６７】
次のステップ（S23）において、次のセグメントのセグメント入手可能時間が決定される。これは、ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、メディアセグメントの受信間隔における変動を補償する補正値とともに最初のメディアセグメントの受信の測定時間を得ることによって新しいavailabilityStartTimeを推定することで行われる。
【００６８】
一実施形態において、少なくともセグメント存続期間が次のメディアセグメントを要求するために必要なので、一定の時間間隔がセグメント存続期間であることが提示される。
【００６９】
一実施形態において、補正値が、メディアセグメントの変動するセグメントサイズを補償することが提示され、ここで変動するセグメントサイズがメディアセグメントの受信間隔における変動をもたらしている。
【００７０】
好適な実施例において、minBufferTimeが、次のセグメントの入手可能時間の補正のためのベースとされる。従って補正値は、アンダーランを避けるため、再生を開始する前にメディアコンテンツをバッファリングするための時間を示すことによって変動するセグメントサイズの表示となっているminBufferTimeを含む。ここでminBufferTimeはマニフェストファイル中で受信される。
【００７１】
minBufferTimeはDASHMPDファイルから読み出される。minBufferTimeを生成するときには、可変セグメントサイズが考慮される。従って、minBufferTimeを設定するとき、LEは生成されたメディアセグメントの変動性についての情報を持っている。minBufferTimeは、バッファアンダーフローを防止する値に設定されるので、コンテンツを再生する前にバッファの中では十分なデータが入手可能であることが保証される。さらに、MPDファイルを生成するときには、セグメントの存続期間も知られている。存続期間はminBufferTimeを生成するときにも考慮され、そして、DASHプレーヤーは、セグメントを再生する前に少なくともセグメントの存続期間の間待つ必要がある。従って、一実施形態において、minBufferTimeにセグメント存続期間が含まれている場合にはminBufferTimeからセグメント存続期間を差し引くことが提示される。さらに、minBufferTimeを0にセットすることで修正し、そして修正されたminBufferTimeをストリーミングプレーヤーに提供することが提示される。
【００７２】
しかし、minBufferTimeの使用は限定と考えられるべきでない。代わりに、メディアセグメントの変動するセグメントサイズを補償している明示的な可変セグメントサイズ補正値があってもよい。この値は、例えばDASH MPDによって、またはユーザサービス記述(USD)フラグメントの中でさえ提供されてもよい。ここで、次のセグメント時間のためのセグメント入手可能性は、明示的に提供された補正値によって最初のセグメントの完全な受信の時間を補正することによって推定される。
【００７３】
以下に一つの例を示す。この例において、メディアコンテンツ中の現在のメディアセグメントである最初のセグメントの受信の測定時間にminBufferTimeを加算し、その値からセグメント存続期間を減算することによって新たな入手可能開始時間(NewAvst)を推定することが提示される。この例は制限ではなく例として考えられるべきである。minBufferTimeとsegment durationは、データ受信によってアンダーランが全くないという必要条件をやはり満たしつつ、エンドツーエンド遅延を縮小するために係数（α，β）によって縮小／拡大されてもよい。
【００７４】
この実施形態は、メディアコンテンツの送信において現在のセグメントである、受信した最初のセグメントの入手可能時間の推定に基づく。推定はメディアセグメントのセグメント番号の決定に基づく。セグメント番号はテンプレート形式から、または受信したマニフェストファイルに含まれているプレイリストから決定される。
【００７５】
従って、以下の実施形態において、計算は以下の通りである。
NewAvst =time_of_first_seg_received + minbufferTime - segment_duration
minbuffertime=0にセット
startNumber=current_index 
従って、クライアントはminBufferTime値を加算し、セグメント存続期間がMinBufferTimeに含まれている場合には、セグメント存続期間をMinBufferTimeから減算する。
【００７６】
さらに、minBufferTimeを0に設定することによってminBufferTimeを修正すること、及びセグメント番号をメディアコンテンツ中の現在のメディアセグメントのセグメント番号に設定することによってセグメント番号を修正することが提示される。ブロードキャストの場合にはセグメントがUE側ですでに受信されているときにのみセグメントが最後まで再生されるので、minBufferTimeは0に設定でき、そして、セグメントがすでにそこにあるのでセグメントを最後まで再生するときにブロードキャストの場合にはセグメントの完全な受信を待つ必要はない。current_indexは、テンプレート形式から、または代わりにマニフェストファイルとともに受信したプレイリストから取り出すことができる現在のセグメント番号である。プレイリストの場合には、現在の番号に先行しているリストのすべてのアイテムは削除されることになっている。
【００７７】
以下において、測定された時間の補正は例に従ってより詳細に説明される。
【００７８】
オリジナルMPDが以下の値を含んでいるとする（ここではMPDファイルの関連するパラメータだけが示される。）
availabilityStartTime = 1300h
startNumber = 1
Duration = 10秒
minBufferTime = 15秒
従って、セグメントがサーバで入手可能であった時間は1300h（availabilityStartTime）である。このとき、最初のセグメント（startNumber 1）が入手可能であったことが通知されるはずである。次のセグメントは10秒ごとに生成されて、そして、セグメント存続期間（Duration）は10秒である。さらに、minBufferTimeは15秒に設定される。
【００７９】
クライアントは特定の時間に受信(tune in)し、クライアントが13:01:10であるときにすなわち送信開始から70秒後に、最初のセグメントの受信時間を測定するとする。
【００８０】
クライアントは、受信したセグメントがセグメントインデックス8を有すると、受信したURL（http//hhhh/seg-8.3gs）から決定する。プレイリストの場合には、セグメントURLのインデックスはそれに応じて決定される。
【００８１】
次のステップにおいて、クライアントは以下の値を有する新しいMPDを作成する。
availabilityStartTime:13:01:10 + 15sec - 10sec = 13:01:15
startNumber = 8
Duration = 10秒
minBufferTime = 0秒
従って、最初のセグメントすなわちセグメント番号8の完全な受信の時間は13:01:10であり、それに対して、セグメントの変動性を補償するためにオリジナルのMPDメッセージから取り出されたminBufferTimeが加算され、さらに、セグメントがクライアントキャッシュですでに入手可能であり、それゆえセグメントの送信の存続期間を考慮する必要が全くないので、存続期間が減算される。セグメントの存続期間は10秒にとどまり、minBufferTimeは、その値がavailabilityStartTimeにおいてすでに考慮されているので0に設定される。
【００８２】
次のステップにおいて、DASHプレーヤーが、次のセグメントを注文するために修正されたMPDファイルを得ることができるように、新たに生成された入手可能時間がDASHプレーヤーに提供される。
【００８３】
この例において、次のセグメントが、仮定した10秒のセグメント存続期間の後、従って13:01:25に注文されるはずである。今回、次のセグメントが入手可能で、バッファの中に記憶されており、そして、それらがユーザ側で入手可能な方法で、例えばminBufferTimeを考慮することによってデータを提供することはLEの役割である。
【００８４】
さらなる例において、受信するDASHストリームの中の最初のセグメントのような、メディアコンテンツの中の最初のセグメントのavailabilityStartTimeに、推定したセグメント入手可能時間を補正することが提示される。この推定は、メディアコンテンツの中の最初のセグメント番号（通常は１がつけられる）の決定に基づく。
【００８５】
従って、完全なメディアストリームの最初のセグメントの受信は、実際のDASHストリームの最初のセグメントの入手可能性の補正のために使われる。MPDファイルの中のstartNumberの修正を妨げるpresentationTimeOffset値をMPDが含んでいる場合に、このソリューションは有利である。presentationTimeOffsetはメディアタイムラインにおけるセグメントのポジションを表わす。
【００８６】
この場合に、補正値は、メディアコンテンツの中の最初のメディアセグメントとメディアコンテンツの中の現在のメディアセグメント(SegmentIndex)との間で経過しているセグメント存続期間をminBufferTimeから減算することによってアップデートされる。この例は制限ではなく例として考えられるべきである。minBufferTimeとsegment durationは、データの受信によってアンダーランが全くないという必要条件をやはり満たしつつ、エンドツーエンド遅延を縮小するために係数（α，β）によって縮小／拡大されてもよい。
【００８７】
従って、UEは受信する(tune in)ときに最初のセグメントを受信する。さらに、UEは入手可能なMPDファイルを有する。UEは、受信したセグメントのセグメント番号を読み、以下の計算を実行する。
NewAvst = time_of_first_seg_received + min_buffer - ((SegmentIndex - startNumber) * SegDuration)
minbuffertime = 0をセット
ここに、NewAvstは新たに計算された入手可能時間であり、time_of_first_seg_receivedは最初のセグメントの受信時間であり、SegmentIndexは最初に受信したセグメントの数、すなわち換言すれば現在のセグメントの番号であり、startNumberはメディアコンテンツセッションの中で最初のセグメント番号である（それは好ましくは１に設定される）。従って、決定されたセグメントインデックスが８であり、最初のセグメントが索引を１に付けられたならば、現在の受信したメディアセグメントは７である。
【００８８】
前記計算は例に基づいて以下において説明される。オリジナルMPDが以下の情報を含んでいるとする。
avaliabilityStartTime = 1300h
startNumber = 1
Duration = 10秒
minBufferTime = 15秒
そして、最初のセグメント受信の時間は13:01:10であり、従ってDASHセッションのようなメディアコンテンツセッション全体の開始後70秒である。さらに、UEは、例えば受信したURL要求メッセージから受信したセグメントの数を読み出すよう構成される。
【００８９】
最初の受信したセグメントの受信したHTTP要求は以下のフォーマットを持ってもよい。
http//hhhh/seg-8.3gs
従って、上述したように、決定されたセグメント番号はしたがって８である。セグメント番号の決定に基づいて、クライアントは以下の方法で新しいMPD値を計算する。
avaliabilityStartTime 13:01:10 + 15sec - ((8-1) * 10) = 13:00:15
startNumber = 1
Duration = 10秒
minBufferTime = 0秒
minBufferTimeを0に設定することによってminBufferTimeを修正すること、及びセグメント番号startNumberをメディアコンテンツの中の最初のセグメントのセグメント番号に設定することが提示される。
【００９０】
最初のセグメントのためのセグメント入手可能時間の決定の目的は、この例ではまた、その後のすべてのセグメントのためのセグメント入手可能時間を決定することである。補正により、クライアントは、その後のすべてのセグメントのためにセグメント入手可能時間を決定するために最初の受信したセグメントのこのセグメント入手可能時間を使うことができる。
【００９１】
図３まで戻って、ステップS23において、次のメディアセグメントのためのセグメント入手可能時間は、最初のメディアセグメントの完全な受信時間を補正値により修正することによって決定される。ここで次のメディアセグメントのためのセグメント入手可能時間は、最初の受信したセグメント（現在のメディアセグメント）の入手可能時間の推定、またはDASHストリームの中の最初のセグメントのために推定された入手可能時間に基づいてよい。一般的に、セグメントインデックスの推定とは独立に、最初のメディアセグメントの完全な受信時間の値は、例えば変動するセグメントサイズによるメディアセグメントの受信間隔の変動を補償している補正値によって修正される。
【００９２】
図３の次のステップ（S24）において、推定されている入手可能時間は、直接MPDファイルをアップデートするか、HTTPレスポンスに新しいHTTPヘッダーを追加し、MPDファイルをアップデートするためにサーバにそれを返送することにより、例えばDASHプレーヤーのようなプレーヤーに伝達される。
【００９３】
従って、ストリーミングプレーヤーに推定されている入手可能時間を伝達するステップ（S24）が、推定されている入手可能時間によってマニフェストファイルを更新すること、およびストリーミングプレーヤーにマニフェストを提供することを含むことが提示される。
【００９４】
代わりに、ストリーミングプレーヤーに推定されている入手可能時間を伝達するステップ（S24）が、新しいHTTPヘッダーをHTTPレスポンスに追加し、マニフェストファイルを更新してサーバデバイスにそれを返送すること、およびストリーミングプレーヤーに前記マニフェストファイルを提供することを含むことが提示される。
【００９５】
MPDは、それがどのように修正されているかと無関係に、ユニキャストを用いて取り出すことができるか、或いは、サービス告知チャネル、例えば任意の適当なブロードキャストチャネル上で送信することができる。さらに、MPDを事前に生成できることはわかるはずである。
【００９６】
さらに、ストリーミングプレーヤーに推定されている入手可能時間を伝達するステップ（S24）が、例えば、MPDファイルを修正することによって修正されたminBufferTime及びセグメント番号を伝達することを含むことが提示される。
【００９７】
さらなる実施形態において、それは、サーバ側の上のセグメントの入手可能性を修正することが提示される。
【００９８】
以下において、図４に従う実施形態が示される。
【００９９】
最初のステップ（S31）において、サーバはDASHストリームのような特定のメディアコンテンツセッションのためにオリジナルのavailabilityStartTimeを得る。オリジナルのavailabilityStartTimeは、セグメントをサーバで送信のために入手可能な時間であり、かつサーバデバイスによって計算されたような時間を意味している。
【０１００】
次のステップ（S32）において、規則「新しいセグメントはUE側でセグメント存続期間ごとに入手可能になる」に従うように、サーバ側のエンティティがavailabilityStartTimeを修正することが提示される。従って、メディアセグメントが一定の時間間隔でストリーミングプレーヤーにおいて入手可能になるように、メディアセグメントの受信間隔における変動を補償する補正値を用いることが提示される。
【０１０１】
一実施形態において、補正値が、メディアセグメントの変動するセグメントサイズとエンドツーエンドシステム遅延を考慮することが提示される。ここでエンドツーエンドシステム遅延は、伝送リンクの上でサーバデバイスからユーザ機器にメディアセグメントを転送するために必要な時間である
一実施形態において、補正値が、メディアセグメントの変動するセグメントサイズを考慮することが提示される。好適には補正値は、前記メディアコンテンツを再生し始める前にメディアコンテンツをバッファリングする時間を示すことにより変動するセグメントサイズの表示となっているminBufferTimeを含む。
【０１０２】
セグメントが様々なサイズをもっているかもしれないので、minBufferTimeの値は、UEが存在しないセグメントを要求することを防止するためにavailabilityStartTimeに含められている。すでに述べたように、minBufferTimeの生成によって、ライブエンコーダはセグメントサイズの変動を考慮し、その値をavailabilityStartTimeに加算する。その結果、minBufferTimeのサイズは、少なくとも、ライブエンコーダに知られているセグメントサイズの変動を補償する。従って、その後のメディアセグメントがUE側でセグメント存続期間ごとに入手可能になることを保証するためにminBufferTimeを利用することが提示される。
【０１０３】
さらに、補正値がエンドツーエンドシステム遅延（max_offset）を含むことが提示される。
【０１０４】
その結果、サーバが、エンドツーエンドシステム遅延およびセグメントサイズの変動を考慮する補正値をavailabilityStartTimeに加算することが提示される。エンドツーエンド遅延時間は、BM-SCからUEまでセグメントを転送するために必要な時間であり、それはサーバに知られている。しかし、各ライブエンコーダはそれ自身の「ターゲットビットレート」規則を持っており、それはさまざまなセグメントサイズとそれらの変動性を促進する。従って、加算された値はできればライブエンコーダの実装および用いられた遅延プロファイル、例えば除外されたか、或いは設定された低いエンドツーエンド遅延に依存する。
【０１０５】
さらに、先に補正値が、クロックのドリフトアヘッド（clock drift ahead）の上限を示すドリフトアヘッド値（maxdriftahead）を含むことが提示される。maxdriftahead値は、受入れ可能なクロックドリフトの上限を表している。換言すれば、UEのクロックがこの上限値よりも大きくドリフトするのであれば、UEは、メディアコンテンツを再生することができないであろうし、UEのクロックの同期が必要とされるであろう。
【０１０６】
従って、新しい入手可能開始時間New Avstは、サーバによって決定されるようにオリジナルの入手可能開始時間avst_orgをとり、現存していないセグメントの要求を防止すべくminBufferTimeを含めるために、MinBufferTime（min_buffer）を加算することによって計算される。さらに、また、max_offsetの値が加算され、それはエンドツーエンド遅延の上限である。前記値はサーバデバイスによっても知られている。LEは、様々なエンドツーエンド遅延を持つ様々なシステムのために働き、max_offset値はセグメントの受渡しにおいて起こり得る遅延の上限を与える。さらに、maxdriftahead値が加算される。
New Avst = avst_org+min_buffer+max_offset+maxdriftahead
さらに、補正値がライブエンコーダの実装と遅延プロファイルに依存することに気づくはずである。
【０１０７】
次のステップ（S33）において、修正されたavailibilityStartTimeをストリーミングプレーヤーに送信することが提示される。特に、ストリーミングプレーヤーに推定した入手可能時間を伝達するステップが、推定したメディアセグメント入手可能時間でマニフェストファイル中のオリジナルのメディアセグメント入手可能時間（availibilityStartTime）を置換すること、および前記マニフェストファイルをストリーミングプレーヤーに送信することを含むことが提示される。
【０１０８】
一実施形態において、サーバ側のMPDファイルの中のavailibilityStartTimeを修正することが提示される。ここで新しく作成されたMPDは修正されたAvst値を含んでいる。一実施形態において、minBufferTimeを、特にクライアントが前記タイマを変更することが許されない場合に、0にセット（minbuffertime=0）してもよいことが提示される。好適な実施例において、修正されたminBufferTimeはマニフェストファイルとともにストリーミングプレーヤーに提供される。
【０１０９】
図５は、メディアセグメントを含むメディアコンテンツをストリーミングプレーヤーに提供するように構成されるユーザ機器UE41において上記で説明された概念を実施するための模範的な構造を図式的に説明する。ここでメディアセグメントはブロードキャスト送信でサーバデバイスからストリーミングプレーヤーに送信される。
【０１１０】
UEは、最初のメディアセグメントを受信するよう構成されたレシーバ42を含む。さらに、UE41は、最初のメディアセグメントの受信時間を決定するよう構成された決定ロジック部44を含む。さらにUEは、ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、メディアセグメントの受信間隔における変動を補償する補正値により最初のメディアセグメントの受信時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成された推定ロジック部45を含む。さらに、ストリーミングプレーヤーに推定した入手可能時間を伝達するよう構成された送信機46がある。
【０１１１】
さらに、UEは、マニフェストファイルを修正するための修正ロジック部（図示されない）を含んでもよい。修正は、任意の望ましい方法で、例えば、HTTPヘッダーを修正するか、それをストリーミングプレーヤーに送信するために新しいHTTPヘッダーを追加することによって成されてもよい。好適なソリューションにおいては、MPDファイルのようなマニフェストファイルが直接修正され、ストリーミングプレーヤーに提供される。
【０１１２】
図５がユーザ機器41中の様々な機能ユニットを説明し、当業者が、適当なソフトウェアとハードウェアを使って、実際にこれらの機能ユニットを実装することができることに注意すべきである。従って、このソリューションは一般にユーザ機器の示された構造に制限されることはなく、機能ユニット42-46は、この開示において説明された任意の機能に従って動作するよう適切に構成できる。
【０１１３】
上に説明された機能ユニット42-46は、UE41において、プロセッサで実行することによりUE41に上述した動作及び手順を実行させるコード手段を含むそれぞれのコンピュータプログラムのプログラムモジュールによって実装できる。プロセッサは１つの中央処理ユニット(CPU)を含むか、２つ以上の処理ユニットを含むことがある。例えば、プロセッサは汎用のマイクロプロセッサ、命令セットプロセッサ、および／または関連したチップセット、および／または特定用途向け集積回路(ASIC)などの専用マイクロプロセッサを含んでもよい。プロセッサはキャッシングのための記憶部も含んでもよい。
【０１１４】
各コンピュータプログラムは、コンピュータ読取り可能媒体を持ち、プロセッサに接続しているメモリという形でUE41におけるコンピュータプログラム製品によって搬送できる。従って、コンピュータプログラム製品またはメモリは、コンピュータプログラムが例えばコンピュータプログラムモジュールという形で記憶されるコンピュータ読取り可能媒体を含む。例えば、メモリはフラッシュメモリ、ランダムアクセスメモリ(RAM)、読出し専用メモリ(ROM)、または電気的消去可能プログラマブルROM(EEPROM)であってもよく、プログラムモジュールは代替の実施形態においてはUE41の中のメモリという形で別のコンピュータプログラム製品に分配できる。
【０１１５】
図６は、ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたサーバデバイス51上で、上記で説明された概念を実施するための図式的に模範的な構造を説明する。ここでメディアセグメントがブロードキャストで送信される。サーバデバイス51は、メディアセグメントがサーバデバイス受信においてダウンロード可能にされる時間を示す、オリジナルのメディアセグメント入手可能時間、従ってオリジナルのavailibilityStartTimeを推定するよう構成されたレシーバ54を含む。さらにサーバデバイス51は、メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、メディアセグメントの受信間隔における変動を補償する補正値によりオリジナルのメディアセグメント入手可能時間（オリジナルのavailibilityStartTime）を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成されたプロセッサ53を含む。さらに、ストリーミングプレーヤーに推定した入手可能時間を伝達するよう構成された送信機52がある。
【０１１６】
図６は、サーバデバイス51中の様々な機能ユニットを説明し、当業者が、適当なソフトウェアとハードウェアを使って、実際にこれらの機能ユニットを実装することができることに注意すべきである。従って、このソリューションは一般にユーザ機器の示された構造に制限されず、機能ユニット52-54は、この開示において説明された任意の機能に従って動作するよう適切に構成されてもよい。
【０１１７】
上に説明された機能ユニット52-54は、サーバデバイス51において、プロセッサで実行することによりサーバデバイス51に上述した動作及び手順を実行させるコード手段を含むそれぞれのコンピュータプログラムのプログラムモジュールによって実装できる。プロセッサは１つの中央処理ユニット(CPU)を含むか、２つ以上の処理ユニットを含むことがある。例えば、プロセッサは汎用のマイクロプロセッサ、命令セットプロセッサ、および／または関連したチップセット、および／または特定用途向け集積回路(ASIC)などの専用マイクロプロセッサを含んでもよい。プロセッサはキャッシングのための記憶部を含んでもよい。
【０１１８】
各コンピュータプログラムは、コンピュータ読取り可能媒体を持ち、プロセッサに接続しているメモリという形のサーバデバイス51におけるコンピュータプログラム製品によって搬送できる。従って、コンピュータプログラム製品またはメモリは、コンピュータプログラムが例えばコンピュータプログラムモジュールという形で記憶されるコンピュータ読取り可能媒体を含む。例えば、メモリはフラッシュメモリ、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、または電気的消去可能プログラマブルROM(EEPROM)であってもよく、プログラムモジュールは代替の実施形態においてはサーバデバイス51中のメモリという形で別のコンピュータプログラム製品に分配できる。
【０１１９】
上記説明した例および実施形態は単に説明のためであり、様々な修正の余地があることは、理解されるはずである。例えば、この概念は、これまで明示的に言及されていないが、他のタイプのモバイル通信ネットワークの中で使われることができる。さらに、上記の概念が、既存のノードの中で対応してデザインされたソフトウェアを使って、またはそれぞれのノードの中で専用のハードウェアを使って実装されてもよいことが理解されるはずである。
【図１】
2016504797.tif 000003
【図２】
2016504797.tif 000004
【図３】
2016504797.tif 000005
【図４】
2016504797.tif 000006
【図５】
2016504797.tif 000007
【図６】
2016504797.tif 000008
【手続補正書】
【提出日】平成27年1月15日(2015.1.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記方法は、ユーザ機器において実行可能である、
−最初のメディアセグメントを受信するステップ(S21)と、
−前記最初のメディアセグメントの受信時間を決定するステップ(S22)と、
−ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により決定された前記最初のメディアセグメントの前記受信時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S23)と、
−前記サーバデバイスにメディアセグメントを要求するよう構成されている前記ストリーミングプレーヤーに、推定した入手可能時間を伝達するステップ(S24)と
を有することを特徴とする方法。
【請求項２】
前記最初のメディアセグメントの前記受信時間を決定するステップ(S22)が、前記最初のメディアセグメントの完全な受信におけるユーザ機器でのローカル時間を決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記最初のメディアセグメントの受信時間を決定するステップ(S22)が、受信した前記最初のセグメントのセグメント番号の推定を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記セグメント番号がテンプレート形式からまたは受信したマニフェストファイルに含まれているプレイリストから決定されることを特徴とする請求項３に記載の方法。
【請求項５】
前記一定の時間間隔がセグメント存続期間であることを特徴とする請求項１に記載の方法。
【請求項６】
前記補正値が、前記メディアセグメントの変動するセグメントサイズを考慮しており、前記変動するセグメントサイズにより前記メディアセグメントの受信間隔における変動がもたらされることを特徴とする請求項１に記載の方法。
【請求項７】
前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記minBufferTimeは、前記サーバデバイスから受信したマニフェストファイルの中で受信することを特徴とする請求項５または６に記載の方法。
【請求項９】
前記メディアセグメント入手可能時間(Avst)を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定に基づいており、前記最初のメディアセグメントは前記メディアコンテンツの現在のメディアセグメントであることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記補正値が、前記セグメント存続期間を前記minBufferTimeから差し引くことで更新される（NewAvst=time_of_first_seg_received + minbufferTime - segment_duration）ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の現在のメディアセグメントのセグメント番号に設定されることを特徴とする請求項７乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記メディアセグメント入手可能時間を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定と、前記メディアコンテンツ中の前記最初のメディアセグメント(startNumber)とに基づくことを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１３】
前記補正値が、前記メディアコンテンツの中の前記最初のメディアセグメントと前記メディアコンテンツの中の現在のメディアセグメント(SegmentIndex)との間で経過する前記セグメント存続期間を前記minBufferTimeから差し引くことで更新される（NewAvst = time_of_first_seg_received + minbufferTime - ((SegmentIndex-startNumber) * segment duration)）ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の前記最初のセグメントのセグメント番号に設定されることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記補正値が、前記メディアセグメントの変動するセグメントサイズを補償する明示的な可変セグメントサイズ値であることを特徴とする請求項５に記載の方法。
【請求項１６】
前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、前記推定した入手可能時間によって前記マニフェストファイルを更新するステップと、前記ストリーミングプレーヤーに前記マニフェストを提供するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、HTTPヘッダーを修正するか、または新しいHTTPヘッダーをHTTPレスポンスに追加するステップと、それをストリーミングプレーヤーに送信するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
ストリーミングプレーヤーに推定した前記入手可能時間を伝達するステップ(S24)が、修正された前記minBufferTimeと前記セグメント番号とをさらに伝達するステップを含むことを特徴とする請求項１または１１または１４に記載の方法。
【請求項１９】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記方法は、サーバにおいて実行可能であり、
−前記メディアセグメントが前記サーバデバイスにおいて送信のために入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するステップ(S31)と、
−メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S32)と、
−前記ストリーミングプレーヤーに前記推定したメディアセグメント入手可能時間を伝達するステップ(S33)と
を有することを特徴とする方法。
【請求項２０】
前記補正値は、前記メディアセグメントの変動するセグメントサイズを考慮することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項１９または２０に記載の方法。
【請求項２２】
前記補正値が、エンドツーエンドシステム遅延(max_offset)を含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２３】
前記補正値が、クロックドリフトの上限を示すドリフトアヘッド値（maxdriftahead）を含むことを特徴とする請求項１９乃至２２のいずれか一項に記載の方法。
【請求項２４】
前記補正値が、ライブエンコーダの実装および遅延プロファイルに依存することを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２５】
前記推定した入手可能時間をストリーミングプレーヤーに伝達するステップ(S33)が、前記推定したメディアセグメント入手可能時間によりマニフェストファイルの中の前記オリジナルのメディアセグメント入手可能時間（availibilityStartTime）を置換するステップと、前記ストリーミングプレーヤーへ前記マニフェストファイルを送信するステップとを含むことを特徴とする請求項１９に記載の方法。
【請求項２６】
さらに、前記minBufferTimeが、それを0に設定することによって修正され、修正された前記minBufferTimeが前記マニフェストファイルとともに前記ストリーミングプレーヤーに提供されることを特徴とする請求項２４に記載の方法。
【請求項２７】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたユーザ機器デバイス(41)であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記ユーザ機器デバイスは、
−最初のメディアセグメントを受信するよう構成された受信機 (42)と、
−前記最初のメディアセグメントの受信時間を決定するよう構成された決定ロジック部(44)と、
−前記ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により、決定された前記最初のメディアセグメントの受信時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成された推定ロジック部(45)と、
−前記サーバデバイスにメディアセグメントを要求するよう構成されている前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(46)と
を有することを特徴するユーザ機器デバイス。
【請求項２８】
前記推定したメディアセグメント入手可能時間によってマニフェストファイルを修正するための修正ロジック部を更に有することを特徴とする請求項２７に記載のユーザ機器デバイス。
【請求項２９】
前記修正ロジック部が、HTTPヘッダーをストリーミングプレーヤーに送信するために、HTTPヘッダーを修正するよう、または新しいHTTPヘッダーを追加するよう構成されることを特徴とする請求項２８に記載のユーザ機器デバイス。
【請求項３０】
ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたサーバデバイス(51)であって、前記メディアセグメントが前記サーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記サーバデバイスは、
−前記サーバデバイスにおいてメディアセグメントが入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するよう構成された受信機(54)と、
−前記メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成されたプロセッサ(53)と、
−前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(52)と
を有することを特徴とするサーバデバイス。
【国際調査報告】
2016504797.tif 000009
2016504797.tif 000010