JP6072276B2 - マルチメディアデータの処理 - Google Patents

マルチメディアデータの処理 Download PDF

Info

Publication number
JP6072276B2
JP6072276B2 JP2015541178A JP2015541178A JP6072276B2 JP 6072276 B2 JP6072276 B2 JP 6072276B2 JP 2015541178 A JP2015541178 A JP 2015541178A JP 2015541178 A JP2015541178 A JP 2015541178A JP 6072276 B2 JP6072276 B2 JP 6072276B2
Authority
JP
Japan
Prior art keywords
segment
media
time
media segment
streaming player
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015541178A
Other languages
English (en)
Other versions
JP2016504797A (ja
Inventor
トルステン ローマル，
トルステン ローマル，
カヤット， イブティサム エル
カヤット， イブティサム エル
Original Assignee
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エルエム エリクソン（パブル）, テレフオンアクチーボラゲット エルエム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Publication of JP2016504797A publication Critical patent/JP2016504797A/ja
Application granted granted Critical
Publication of JP6072276B2 publication Critical patent/JP6072276B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

この開示は、伝送遅延が変動する伝送リンク上で送信されているメディアデータをユーザに提供するための技術に関連している。
この開示は、メディアセグメントの伝送を提供しているブロードキャスト技術を用いるネットワークソリューションの中で実行できる。特に、ここに議論された実施形態は、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中のメモリという形で別のコンピュータプログラム製品に分配できる。
上記説明した例および実施形態は単に説明のためであり、様々な修正の余地があることは、理解されるはずである。例えば、この概念は、これまで明示的に言及されていないが、他のタイプのモバイル通信ネットワークの中で使われることができる。さらに、上記の概念が、既存のノードの中で対応してデザインされたソフトウェアを使って、またはそれぞれのノードの中で専用のハードウェアを使って実装されてもよいことが理解されるはずである。

Claims (30)

  1. ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記方法は、ユーザ機器において実行可能である、
    −最初のメディアセグメントを受信するステップ(S21)と、
    −前記最初のメディアセグメントの受信時間を決定するステップ(S22)と、
    −ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により決定された前記最初のメディアセグメントの前記受信時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S23)と、
    −前記サーバデバイスにメディアセグメントを要求するよう構成されている前記ストリーミングプレーヤーに、推定した前記入手可能時間を伝達するステップ(S24)と
    を有することを特徴とする方法。
  2. 前記最初のメディアセグメントの前記受信時間を決定するステップ(S22)が、前記最初のメディアセグメントの受信完了時におけるユーザ機器でのローカル時間を決定するステップを含むことを特徴とする請求項１に記載の方法。
  3. 前記最初のメディアセグメントの前記受信時間を決定するステップ(S22)が、受信した前記最初のセグメントのセグメント番号の推定を含むことを特徴とする請求項１に記載の方法。
  4. 前記セグメント番号がテンプレート形式からまたは受信したマニフェストファイルに含まれているプレイリストから決定されることを特徴とする請求項３に記載の方法。
  5. 前記一定の時間間隔がセグメント存続期間であることを特徴とする請求項３に記載の方法。
  6. 前記補正値が、前記メディアセグメントの変動するセグメントサイズを考慮しており、前記変動するセグメントサイズにより前記メディアセグメントの前記受信間隔における変動がもたらされることを特徴とする請求項５に記載の方法。
  7. 前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項６に記載の方法。
  8. 前記minBufferTimeは、前記サーバデバイスから受信したマニフェストファイルの中で受信することを特徴とする請求項７に記載の方法。
  9. 前記メディアセグメント入手可能時間(Avst)を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定に基づいており、前記最初のメディアセグメントは前記メディアコンテンツの現在のメディアセグメントであることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
  10. 前記補正値が、前記セグメント存続期間を前記minBufferTimeから差し引くことで更新されることを特徴とする請求項７または８に記載の方法。
  11. 前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の現在のメディアセグメントのセグメント番号に設定されることを特徴とする請求項７または８または１０に記載の方法。
  12. 前記メディアセグメント入手可能時間を推定するステップが、受信した前記最初のメディアセグメントの入手可能時間(time_of_first_seg_received)の推定と、前記メディアコンテンツ中の前記最初のメディアセグメント(startNumber)とに基づくことを特徴とする請求項１乃至８のいずれか一項に記載の方法。
  13. 前記補正値が、前記メディアコンテンツの中の前記最初のメディアセグメントと前記メディアコンテンツの中の現在のメディアセグメント(SegmentIndex)との間で経過する前記セグメント存続期間を前記minBufferTimeから差し引くことで更新されることを特徴とする請求項７または８に記載の方法。
  14. 前記minBufferTimeが、それを0に設定することによって修正され、前記セグメント番号が前記メディアコンテンツの中の前記最初のセグメントのセグメント番号に設定されることを特徴とする請求項１３に記載の方法。
  15. 前記補正値が、前記メディアセグメントの変動するセグメントサイズを補償する明示的な可変セグメントサイズ値であることを特徴とする請求項５に記載の方法。
  16. 前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、前記推定した入手可能時間によってマニフェストファイルを更新するステップと、前記ストリーミングプレーヤーに前記マニフェストファイルを提供するステップとを含むことを特徴とする請求項１に記載の方法。
  17. 前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するステップ(S24)が、HTTPヘッダーを修正するか、または新しいHTTPヘッダーをHTTPレスポンスに追加することと、それをストリーミングプレーヤーに送信することとを含むことを特徴とする請求項１に記載の方法。
  18. ストリーミングプレーヤーに推定した前記入手可能時間を伝達するステップ(S24)が、修正された前記minBufferTimeと前記セグメント番号とをさらに伝達することを含むことを特徴とする請求項１１または１４に記載の方法。
  19. ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するための方法であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記方法は、サーバにおいて実行可能であり、
    −前記メディアセグメントが前記サーバデバイスにおいて送信のために入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するステップ(S31)と、
    −メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによってその後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するステップ(S32)と、
    −前記ストリーミングプレーヤーに前記推定したメディアセグメント入手可能時間を伝達するステップ(S33)と
    を有することを特徴とする方法。
  20. 前記補正値は、前記メディアセグメントの変動するセグメントサイズを考慮することを特徴とする請求項１９に記載の方法。
  21. 前記補正値は、前記メディアコンテンツを再生し始める前に前記メディアコンテンツをバッファリングする時間を示すことにより前記変動するセグメントサイズの表示となっているminBufferTimeを含むことを特徴とする請求項１９または２０に記載の方法。
  22. 前記補正値が、エンドツーエンドシステム遅延(max_offset)を含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
  23. 前記補正値が、クロックのドリフトアヘッドの上限を示すドリフトアヘッド値（maxdriftahead）を含むことを特徴とする請求項１９乃至２２のいずれか一項に記載の方法。（０１０５）
  24. 前記補正値が、ライブエンコーダの実装および遅延プロファイルに依存することを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
  25. 前記推定した入手可能時間を前記ストリーミングプレーヤーに伝達するステップ(S33)が、前記推定したメディアセグメント入手可能時間によりマニフェストファイルの中の前記オリジナルのメディアセグメント入手可能時間（availibilityStartTime）を置換することと、前記ストリーミングプレーヤーへ前記マニフェストファイルを送信することとを含むことを特徴とする請求項１９に記載の方法。
  26. さらに、前記minBufferTimeが、それを0に設定することによって修正され、修正された前記minBufferTimeがマニフェストファイルとともに前記ストリーミングプレーヤーに提供されることを特徴とする請求項２１に記載の方法。
  27. ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたユーザ機器デバイス(41)であって、前記メディアセグメントがサーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記ユーザ機器デバイスは、
    −最初のメディアセグメントを受信するよう構成された受信機(42)と、
    −前記最初のメディアセグメントの受信時間を決定するよう構成された決定ロジック部(44)と、
    −前記ストリーミングプレーヤーが一定の時間間隔でメディアセグメントを受信するように、前記メディアセグメントの受信間隔における変動を補償する補正値により、決定された前記最初のメディアセグメントの前記受信時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成された推定ロジック部(45)と、
    −前記サーバデバイスにメディアセグメントを要求するよう構成されている前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(46)と
    を有することを特徴するユーザ機器デバイス。
  28. 前記推定したメディアセグメント入手可能時間によってマニフェストファイルを修正するための修正ロジック部を更に有することを特徴とする請求項２７に記載のユーザ機器デバイス。
  29. 前記修正ロジック部が、HTTPヘッダーをストリーミングプレーヤーに送信するために、HTTPヘッダーを修正するよう、または新しいHTTPヘッダーを追加するよう構成されることを特徴とする請求項２８に記載のユーザ機器デバイス。
  30. ストリーミングプレーヤーにメディアセグメントを含むメディアコンテンツを提供するよう構成されたサーバデバイス(51)であって、前記メディアセグメントが前記サーバデバイスからストリーミングプレーヤーにブロードキャスト送信で送信され、前記サーバデバイスは、
    −前記サーバデバイスにおいて送信のためにメディアセグメントが入手可能にされる時間を示すオリジナルのメディアセグメント入手可能時間を推定するよう構成された受信機(54)と、
    −前記メディアセグメントが一定の時間間隔でストリーミングプレーヤーで入手可能にされるように、前記メディアセグメントの受信間隔における変動を補償する補正値により前記オリジナルのメディアセグメント入手可能時間を修正することによって、その後のメディアセグメントを要求するためのメディアセグメント入手可能時間を推定するよう構成されたプロセッサ(53)と、
    −前記ストリーミングプレーヤーに前記推定した入手可能時間を伝達するよう構成された送信機(52)と
    を有することを特徴とするサーバデバイス。
JP2015541178A 2012-11-13 2013-11-12 マルチメディアデータの処理 Active JP6072276B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261725696P 2012-11-13 2012-11-13
US61/725,696 2012-11-13
PCT/EP2013/073559 WO2014076052A1 (en) 2012-11-13 2013-11-12 Processing of multimedia data

Publications (2)

Publication Number Publication Date
JP2016504797A JP2016504797A (ja) 2016-02-12
JP6072276B2 true JP6072276B2 (ja) 2017-02-01

Family

ID=49578294

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015541178A Active JP6072276B2 (ja) 2012-11-13 2013-11-12 マルチメディアデータの処理

Country Status (7)

Country Link
US (2) US9712585B2 (ja)
EP (2) EP2920938B1 (ja)
JP (1) JP6072276B2 (ja)
DK (2) DK3145155T3 (ja)
ES (2) ES2763998T3 (ja)
RU (1) RU2614540C2 (ja)
WO (1) WO2014076052A1 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101629748B1 (ko) 2012-07-09 2016-06-13 후아웨이 테크놀러지 컴퍼니 리미티드 Dash 클라이언트 행위 프레임워크 및 세션 관리의 실현
US9386062B2 (en) * 2012-12-28 2016-07-05 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (HTTP) requests
US9154534B1 (en) * 2013-01-02 2015-10-06 Amazon Technologies, Inc. Multiple media device infrastructure
JP2016522621A (ja) * 2013-07-15 2016-07-28 ホアウェイ・テクノロジーズ・カンパニー・リミテッド ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコルにおけるリモート要素のジャストインタイムデリファレンス
KR102154800B1 (ko) * 2014-01-10 2020-09-10 삼성전자주식회사 전자 장치의 데이터 스트리밍 방법 및 그 전자 장치
US10237628B2 (en) * 2014-02-03 2019-03-19 Oath Inc. Tracking and measurement enhancements in a real-time advertisement bidding system
US10044831B2 (en) * 2014-03-10 2018-08-07 Samsung Electronics Co., Ltd. Method and apparatus for transmitting messages to a dash client
WO2015140064A1 (en) * 2014-03-17 2015-09-24 Bitmovin Gmbh Media streaming
JP6324238B2 (ja) * 2014-06-30 2018-05-16 キヤノン株式会社 動画再生装置、動画再生方法及びそのプログラム、動画配信装置、動画配信方法及びそのプログラム
US9973345B2 (en) * 2014-09-10 2018-05-15 Qualcomm Incorporated Calculating and signaling segment availability times for segments of media data
JP6706784B2 (ja) * 2014-09-12 2020-06-10 パナソニックＩｐマネジメント株式会社 送信装置、受信装置、送信方法及び受信方法
US10050912B2 (en) * 2014-10-27 2018-08-14 At&T Intellectual Property I, L.P. Subscription-based media push service
US20160248829A1 (en) * 2015-02-23 2016-08-25 Qualcomm Incorporated Availability Start Time Adjustment By Device For DASH Over Broadcast
US10298647B2 (en) 2015-02-26 2019-05-21 Qualcomm Incorporated Delay compensation for broadcast adaptive bitrate streaming
US10432688B2 (en) * 2015-03-13 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US20160308927A1 (en) * 2015-04-20 2016-10-20 Qualcomm Incorporated Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
US9787430B2 (en) * 2015-05-01 2017-10-10 Qualcomm Incorporated Dynamic setting of FEC in eMBMS video streaming
US20160337424A1 (en) * 2015-05-13 2016-11-17 Qualcomm Incorporated Transferring media data using a websocket subprotocol
US10412461B2 (en) * 2015-06-12 2019-09-10 Cable Television Laboratories, Inc. Media streaming with latency minimization
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
CN105847787A (zh) * 2016-03-28 2016-08-10 乐视控股（北京）有限公司 媒体播放列表的切片时长的检测方法及装置
US10868848B2 (en) * 2016-07-25 2020-12-15 Peraso Technologies Inc. Wireless multimedia communications system and method
US20180069909A1 (en) * 2016-09-08 2018-03-08 Sonic Ip, Inc. Systems and Methods for Adaptive Buffering for Digital Video Streaming
US10686855B2 (en) * 2016-09-22 2020-06-16 Verizon Patent And Licensing Inc. HLS over multimedia broadcast multicast service (MBMS)
US10999613B1 (en) * 2017-02-19 2021-05-04 Look At Me, Inc System and method for intelligent delivery of segmented media streams
US10839053B2 (en) * 2018-01-12 2020-11-17 Cisco Technology, Inc. Secure watermark for an adaptive bitrate client
US10601886B2 (en) * 2018-02-05 2020-03-24 Telefonaktiebolaget Lm Ericsson (Publ) Method, a user equipment and a computer program product for enabling a dynamic adaptive streaming over HTTP, DASH, player to fetch media segments from a network
US10581707B2 (en) 2018-04-10 2020-03-03 At&T Intellectual Property I, L.P. Method and apparatus for selective segment replacement in HAS video streaming adaptation
US20200112753A1 (en) * 2018-10-03 2020-04-09 Qualcomm Incorporated Service description for streaming media data
US10547915B1 (en) * 2019-07-19 2020-01-28 Look At Me, Inc. System and method for optimizing playlist information for ultra low latency live streaming
US11025987B2 (en) * 2019-08-15 2021-06-01 Hulu, LLC Prediction-based representation selection in video playback
US11277461B2 (en) * 2019-12-18 2022-03-15 The Nielsen Company (Us), Llc Methods and apparatus to monitor streaming media
EP3902276A1 (en) * 2020-04-21 2021-10-27 THEO Technologies Video stream control
EP4218166A1 (en) * 2020-10-16 2023-08-02 Huawei Technologies Co., Ltd. Methods and devices for efficient media streaming

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2864869A1 (fr) 2004-01-06 2005-07-08 Thomson Licensing Sa Methode de transmission de services numeriques sur un reseau et appareil mettant en oeuvre la methode
US9615119B2 (en) * 2010-04-02 2017-04-04 Samsung Electronics Co., Ltd. Method and apparatus for providing timeshift service in digital broadcasting system and system thereof
US9319448B2 (en) * 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
EP2659663B1 (en) * 2010-12-29 2016-04-20 Telecom Italia S.p.A. Method and system for syncronizing electronic program guides
US20130182643A1 (en) * 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast

Also Published As

Publication number Publication date
DK3145155T3 (da) 2019-12-16
US20160277466A1 (en) 2016-09-22
US20170257412A1 (en) 2017-09-07
EP3145155A1 (en) 2017-03-22
WO2014076052A1 (en) 2014-05-22
ES2621240T3 (es) 2017-07-03
DK2920938T3 (en) 2017-04-10
ES2763998T3 (es) 2020-06-01
JP2016504797A (ja) 2016-02-12
US9712585B2 (en) 2017-07-18
RU2614540C2 (ru) 2017-03-28
EP2920938B1 (en) 2017-01-04
RU2015122492A (ru) 2017-01-10
EP3145155B1 (en) 2019-09-25
US10320868B2 (en) 2019-06-11
EP2920938A1 (en) 2015-09-23

Similar Documents

Publication Publication Date Title
JP6072276B2 (ja) マルチメディアデータの処理
JP6337350B2 (ja) ビデオ品質向上
US10547659B2 (en) Signaling and processing content with variable bitrates for adaptive streaming
KR101602525B1 (ko) 데이터 세그먼트의 선택적 방송전달을 가지는 스트리밍
US20180176615A1 (en) A media user client, a media user agent and respective methods performed thereby for providing media from a media server to the media user client
US20150172340A1 (en) Technique for Operating Client and Server Devices in a Broadcast Communication Network
EP2962435A1 (en) Link-aware streaming adaptation
EP3384617B1 (en) Data rate adaptation for multicast delivery of streamed content
JP2007520109A (ja) エンコード特性の適応を伴うコンテンツ送信方法
CN102333083A (zh) 一种传输数据的方法和系统
US20130031580A1 (en) Apparatus and method for inserting advertisement in a broadcasting system
KR20140031916A (ko) 멀티미디어 컨텐츠를 스트리밍하는 방법 및 장치
JP6009501B2 (ja) データセグメントのオプションのブロードキャスト配信によるストリーミング
WO2017063704A1 (en) Synchronization stream for switching to multicast delivery of streamed content

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160616

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160729

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20161031

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161111

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20161205

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161227

R150 Certificate of patent or registration of utility model

Ref document number: 6072276

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250