JP2016531466A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2016531466A5 JP2016531466A5 JP2016524842A JP2016524842A JP2016531466A5 JP 2016531466 A5 JP2016531466 A5 JP 2016531466A5 JP 2016524842 A JP2016524842 A JP 2016524842A JP 2016524842 A JP2016524842 A JP 2016524842A JP 2016531466 A5 JP2016531466 A5 JP 2016531466A5
- Authority
- JP
- Japan
- Prior art keywords
- server
- client
- push
- data
- media data
- 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.)
- Granted
Links
- 230000005540 biological transmission Effects 0.000 claims description 111
- 230000004044 response Effects 0.000 claims description 55
- 238000000034 method Methods 0.000 claims description 33
- 238000004891 communication Methods 0.000 claims description 18
- 230000000875 corresponding Effects 0.000 description 48
- UIIMBOGNXHQVGW-UHFFFAOYSA-M buffer Substances [Na+].OC([O-])=O UIIMBOGNXHQVGW-UHFFFAOYSA-M 0.000 description 39
- 238000004422 calculation algorithm Methods 0.000 description 17
- 230000006399 behavior Effects 0.000 description 15
- 230000004301 light adaptation Effects 0.000 description 14
- 230000003044 adaptive Effects 0.000 description 9
- 239000002131 composite material Substances 0.000 description 7
- 230000014509 gene expression Effects 0.000 description 7
- 238000005259 measurement Methods 0.000 description 7
- 238000004458 analytical method Methods 0.000 description 6
- 230000001419 dependent Effects 0.000 description 6
- 235000010384 tocopherol Nutrition 0.000 description 6
- 235000019731 tricalcium phosphate Nutrition 0.000 description 6
- 230000000295 complement Effects 0.000 description 5
- 238000011068 load Methods 0.000 description 5
- 230000002123 temporal effect Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 241000036569 Carp sprivivirus Species 0.000 description 3
- 230000004913 activation Effects 0.000 description 3
- 230000003139 buffering Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000002708 enhancing Effects 0.000 description 3
- 238000009877 rendering Methods 0.000 description 3
- 229920004880 RTP PEK Polymers 0.000 description 2
- 206010046306 Upper respiratory tract infection Diseases 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 101700070114 img1 Proteins 0.000 description 2
- 101700066110 img2 Proteins 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006011 modification reaction Methods 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000000153 supplemental Effects 0.000 description 2
- 230000001702 transmitter Effects 0.000 description 2
- 230000000903 blocking Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000000977 initiatory Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000002787 reinforcement Effects 0.000 description 1
- 230000000576 supplementary Effects 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
Description
本出願は、英国特許出願第1312547.1号および第1312561.2号(ともに2013年7月12日)、並びに第1410540.7号(2014年6月12日)からの優先権を主張し、それらは参考文献としてすべて本明細書に援用される。
本発明は、HTTP通信ネットワーク上のデータストリーミングに関する。
特に、本発明はネットワーク制約を満たすための適応型データストリーミングに関する。本発明は、DASHネットワークにおけるアプリケーションを有してもよい。
DASH(Dynamic Adaptive Streaming over HTTP(動的適応型HTTPストリーミング)の頭文字)は、HTTP上のメディアコンテンツストリーミング(通常はオーディオ/ビデオコンテンツ)を可能にする通信規格である。DASHによれば、メディアプレゼンテーションは、「メディアプレゼンテーション記述」ファイル(以下において、MPD)と呼ばれるXMLファイルとして記載される。MPDファイルは、クライアント装置がメディアコンテンツの配信を要求し制御することを可能にする情報を、クライアント装置に提供する。
HTTPメディアストリーミングの一般的原理は、図3に示される。適応型HTTPメディアストリーミングのための新たなプロトコルおよび標準のほとんどは、この原理に基づく。
メディアサーバ300は、クライアント310に対してデータをストリーミングする。メディアサーバは、メディアプレゼンテーションを保存する。例えば、メディアプレゼンテーション301は、オーディオデータおよびビデオデータを含む。オーディオおよびビデオは、同じファイル内でインターリーブされてもよい。メディアプレゼンテーションが構築される方法は、図4aを参照しながら以下に記載される。メディアプレゼンテーションは、独立してアドレス指定されてダウンロードされることができるMP4セグメントなどの、小さな独立した連続する時間セグメント302a、302bおよび302cに一時的に分割される。これらの時間セグメントの各々のためのメディアコンテンツのダウンロードアドレス(HTTP URL)は、クライアントに対してサーバによって設定される。オーディオ/ビデオメディアコンテンツの各時間セグメントは、1つのHTTPアドレスに関連づけられている。
メディアサーバは、また、メディアコンテンツ特性(例えば、メディアのタイプ:オーディオ、ビデオ、オーディオビデオ、テキストなど)、コード化形式(例えば、ビットレート、タイミング情報など)、時間メディアセグメントと関連するURLとのリストを含むメディアプレゼンテーションのコンテンツを記述する(図5を参照ながら以下に記載される)マニフェストファイルドキュメント304を保存する。または、ドキュメントは、時間メディアセグメント及び関連するURLとの明示的なリストを再構築可能にするテンプレート情報を含む。このドキュメントは、エクステンシブルマークアップランゲージ(XML)を用いて記載されてもよい。
マニフェストファイルは、クライアントに対して送信される。ステップ305の間にマニフェストファイルの受信をすると、クライアントには、メディアコンテンツの時間セグメントとHTTPアドレスとの間の関連づけが通知される。また、マニフェストファイルは、メディアプレゼンテーションのコンテンツに関する情報(本例にではインターリーブされたオーディオ/ビデオ)をクライアントに提供する。情報は、解像度、ビットレートなどを含んでもよい。
受信された情報に基づいて、クライアントのHTTPクライアントモジュール311は、マニフェストファイル内に記載されたメディアコンテンツの時間セグメントのダウンロードのためにHTTP要求306を発行することができる。サーバのHTTP応答307は、要求された時間セグメントを伝達する。HTTPクライアントモジュール311は、応答から時間メディアセグメントを抽出し、メディアエンジン312の入力バッファ307に対してそれらを提供する。最終的に、メディアセグメントは、ステップ308および309のそれぞれの間に復号されて表示されることができる。
メディアエンジン312は、次の時間セグメントが適切な時期に発行されるように要求するために、DASH制御エンジン313と情報のやりとりをする。次のセグメントは、マニフェストファイルから識別される。要求が発行される時期は、受信バッファ307が満杯であるか否かに依存する。DASH制御エンジン313は、バッファが過負荷になるかまたは完全に空になるのを防ぐようにバッファを制御する。
メディアプレゼンテーションおよびマニフェストファイルの生成を、図4aを参照して説明する。ステップ400および401の間に、オーディオデータおよびビデオデータが取得される。次に、オーディオデータは、402の間に圧縮される。例えば、MP3規格を用いることができる。また、ビデオデータは、ステップ403の間に並行して圧縮される。MPEG4、MPEG/AVC、SVC、HEVC、またはスケーラブルHEVCなどのビデオ圧縮アルゴリズムを用いることができる。オーディオデータおよびビデオデータの圧縮が一旦実行されれば、オーディオビデオエレメンタリーストリーム404およびビデオエレメンタリーストリーム405は、利用可能になる。エレメンタリストリームは、ステップ406の間に、グローバルメディアプレゼンテーションにカプセル化される。例えば、ISO BMFF規格(またはISO BMFF規格をAVC、SVC、HEVC、HEVCのスケーラブル拡張などに拡張する)は、符号化されたオーディオエレメンタリーストリームおよびビデオエレメンタリーストリームのコンテンツをグローバルメディアプレゼンテーションとして記述するために使用することができる。それによって取得されたカプセル化されたメディアプレゼンテーション407は、ステップ408の間に、XMLマニフェストファイル409を生成するために用いられる。ビデオデータ401およびオーディオデータ400のいくつかのリプレゼンテーションは、取得され、圧縮され、カプセル化され、メディアプレゼンテーション407内に記載することができる。
図4bに示されたMPEG/DASHストリーミングプロトコルの特定のケースに関して、マニフェストファイルは、「メディアプレゼンテーション記述」(または「MPD」ファイル)と呼ばれる。ファイルのルート要素は、プロファイルまたはスキーマのようなDASH情報を加えたすべてのプレゼンテーションに適用する属性を含むMPD要素である。メディアプレゼンテーションは、Period要素によって表される時間的期間に分割される。MPDファイル410は、各時間的期間に関連するデータをすべて含む。この情報を受信することによって、クライアントは、各々の期間ごとのコンテンツを認識する。Period411ごとに、AdaptationSet(アダプテーションセット)要素が定義される。
可能な構成は、プレゼンテーション内に含まれるメディアタイプ当たり1つ以上のAdaptationSetを有することである。ビデオに関連するAdaptationSet412は、サーバにおいて利用可能な符号化されたビデオの異なる可能的なリプレゼンテーションに関する情報を含む。各リプレゼンテーションは、Representation要素内に記述される。例えば、第1のリプレゼンテーションは、640×480の空間解像度で符号化され、且つ500kビット/秒のビットレートで圧縮されたビデオになり得る。第2のリプレゼンテーションは、同じビデオになり得るが、250kビット/秒のビットレートで圧縮され得る。
クライアントが各ビデオに関するHTTPアドレスを知っている場合、各ビデオは、その後、HTTP要求によってダウンロードすることができる。各リプレゼンテーションのコンテンツとHTTPアドレスとの間の関連づけは、付加的なレベルの記述:時間セグメントを用いることによって行われる。各ビデオリプレゼンテーションは、時間セグメント413(通常は数秒)に分割される。各時間セグメントは、HTTPアドレス(URLまたは1バイトレンジのURL)を介してアクセス可能なサーバに保存されたコンテンツを備える。いくつかの要素は、MPDファイル:SegmentList(セグメントリスト)、SegmentBase(セグメントベース)またはSegmentTemplate(セグメントテンプレート)内に時間セグメントを記述するために用いることができる。
さらに、特定のセグメント:イニシャライゼーションセグメントが利用可能である。イニシャライゼーションセグメントは、(ISO BMFFまたはその拡張を用いてビデオがカプセル化されているならば)カプセル化されたビデオストリームを記述するMP4イニシャライゼーション情報を含む。例えば、それは、クライアントがビデオに関する復号アルゴリズムをインスタンス化するのを支援する。
イニシャライゼーションセグメントおよびメディアセグメントのHTTPアドレスは、MPDファイル内に示される。
図5に、例示的なMPDファイルが示される。2つのメディアが、図示されたMPDファイル内に記述される。第1のものは英語のオーディオストリームであり、第2のものはビデオストリームである。英語のオーディオストリームは、AdaptationSetタグ500を用いて導入される。2つの代替的リプレゼンテーションが、このオーディオストリームのために利用可能である。
・第1のリプレゼンテーション501は、64000ビット/秒のビットレートでMP4にカプセル化されたエレメンタリオーディオストリームである。この(MP4構文解析後の)エレメンタリストリームを取り扱うために用いられるコーデックは、値「mp4a.0x40」を有する属性コーデックによって規格内に定義されている。それは、セグメント階層内のBaseURL(ベースURL)要素:相対的なURIである<BaseURL>7657412348.mp4</BaseURL>の連結によって形成されたアドレスにおける要求を介してアクセス可能である。「http://cdn1.example.com/」によって、または「http://cdn2.example.com/」によってMPD要素内のトップレベルにおいて定義される〈BaseURL〉(2つのサーバが同じコンテンツのストリーミングのために利用可能である)は、絶対URIである。そして、クライアントは、その要求から、アドレス「http://cdn1.example.com/7657412348.mp4」またはアドレス「http://cdn2.example.com/7657412348.mp4」に対して、英語のオーディオストリームを要求することができる。
・第2のリプレゼンテーション502は、32000ビット/秒のビットレートでMP4にカプセル化されたエレメンタリオーディオストリームである。第1のリプレゼンテーション501と同じような説明を行うことができ、クライアント装置は、したがって、以下のアドレスのいずれか1つにおける要求によって、この第2のリプレゼンテーション502を要求することができる。
「http://cdn1.example.com/3463646346.mp4」または
「http://cdn2.example.com/3463646346.mp4」。
「http://cdn2.example.com/3463646346.mp4」。
ビデオに関連するアダプテーションセット503は、6つのリプレゼンテーションを含む。これらのリプレゼンテーションは、異なる空間解像度(320×240、640×480、1280×720)、および異なるビットレート(256000〜2048000ビット/秒)のビデオを含む。これらのリプレゼンテーションの各々に対して、それぞれのURLは、BaseURL要素を通じて関連づけられる。そのため、クライアントは、推定された帯域幅、スクリーン解像度などの異なる基準にしたがって同じビデオのこれらの代替リプレゼンテーションの間で選択することができる。(図5において、時間セグメントへのRepresentationの分解は、明瞭にするために図示されていない、ということに留意されたい。)
図5aは、DASHクライアントの標準的挙動(standard behavior)を示す。図5bは、図4aに示された方法において用いられる、例示的なマニフェストファイル(記述ファイルまたはMPD)のツリー表現を示す。
図5aは、DASHクライアントの標準的挙動(standard behavior)を示す。図5bは、図4aに示された方法において用いられる、例示的なマニフェストファイル(記述ファイルまたはMPD)のツリー表現を示す。
ストリーミングセッションを開始する場合、DASHクライアントは、マニフェストファイルを要求することによって開始する(ステップ550)。サーバの応答を待ってマニフェストファイルを受信した後(ステップ551)、クライアントは、マニフェストファイルを解析し(ステップ552)、その環境に適したAdaptationSetsのセットASijを選択し(ステップ553)、それから、例えば、その帯域幅、復号化、およびレンダリング機能に適したMPD内のRepresentationを各AdaptationSet ASij内で選択する(ステップ554)。
そして、DASHクライアントは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求するセグメントのリストを予め構築することができる。このイニシャライゼーションセグメントは、それが複数のリプレゼンテーション、アダプテーションセットおよび期間に共通になり得るか、または各Representationに特有になり得るか、または第1のメディアセグメント内にも含まれ得るので、このMPD(ステップ555)内で、識別されなければならない。
そして、クライアントは、イニシャライゼーションセグメントを要求する(ステップ556)。一旦イニシャライゼーションセグメントが受信されると(ステップ557)、復号器が起動される(ステップ558)。
そして、クライアントはセグメント単位で第1のメディアデータを要求し(ステップ560)、復号化を実際に開始して表示する(ステップ563)前に、(ステップ559の条件のために)最小データ量をバッファする。MPDダウンロードと最初に表示されたフレームとの間のこれら複数の要求/応答は、ストリーミングセッションにおける起動遅延(startup delay)を招く。これらの初期ステップの後、DASHストリーミングセッションは、標準的方法で継続する、すなわち、DASHクライアントは、メディアセグメントを順々に適応させてリクエストする。
現在のDASHバージョンは、マニフェストファイル内部の関心領域の記述を提供しない。いくつかのアプローチが、このような記述のために、提案されてきた。
特に、メディアコンテンツのコンポーネントは、SubRepresentation(サブリプレゼンテーション)要素を用いて記載することができる。これらの要素は、リプレゼンテーション内に埋め込まれる1つまたはいくつかのコンポーネントのプロパティを記述する。図6に、タイルトラック(tile tracks)をビデオのコンポーネントとして記述するDASHマニフェストファイルの例が示される。簡明に且つおよび明瞭にするために、1つのPeriod600のみを示す。しかしながら、後続の期間要素は、同じ方式で編成されるだろう。部分601において、第1のアダプテーションセット要素は、スケーラブルビデオのベース層を記述するために用いられる。例えば、ビデオは、SVCまたはスケーラブルなHEVCにしたがって符号化される。部分602において、第2のアダプテーションセットはスケーラブルビデオの最高解像度層を記述するために用いられる。非スケーラブルビデオに対して、第2のアダプテーションセット602のみが、ベース層に依存することなく(すなわちdependencyld属性)、存在するだろう。この第2のアダプテーションセット602において、単一のリプレゼンテーション603、すなわち表示することができるビデオに対応するもの、が記述される。そのリプレゼンテーションは、クライアント要求のためのそれぞれのURLとともにセグメント610のリストとして記載される。
このように、リプレゼンテーションは、「R1」(dependencyld属性)によって識別された別のリプレゼンテーション、実際には第1のアダプテーションセット601からのベース層リプレゼンテーション、に依存する。依存性は、エンハンスメント層のために現在のセグメントを得る前にベース層のための現在のセグメントを最初に要求することをストリーミングクライアントに強制する。このように参照されるトラックがクライアントによって自動的にロードされるので、これをタイルトラックに対する依存性を表現するためには用いることができない。メディアプレゼンテーションの間にユーザにとって興味のあるタイル(tiles)をいつでも選択することはユーザ次第であるので、これは回避されるべきである。そのため、複合トラックとタイルトラックとの間の依存性を示すために、SubRepresentation要素が用いられる。表示可能なビデオは、サブリプレゼンテーション604〜608のリストとして記載される。各サブリプレゼンテーションは、カプセル化されたMP4ファイル内のトラックを実際に表わす。このように、複合トラック608に対して1つのタイルを加えた(本例においては4つのタイル)サブリプレゼンテーション当たり1つのサブリプレゼンテーションがある。各サブリプレゼンテーションは、タイルトラック614、615、616、および617、または複合トラック618に対応するか否かを示すために、コンテンツコンポーネント要素614〜618によって記述される。DASH/MPDにおいて利用可能なロール記述子型は、特定のスキームによるタイリングのために用いられる。ロール記述子は、また、フルフレームビデオ内のタイルの位置を示す。例えば、コンポーネント614は、ビデオの左上(先頭行および先頭列の1:1)に位置するタイルを記述する。タイルの寸法、幅および高さは、MPDによって可能になるようなサブリプレゼンテーションの属性として指定される。帯域幅情報も、また、その帯域幅にしたがって、タイルの数およびタイルの選択の決定においてDASHクライアントを支援するためにここに設けることができる。複合トラックに関して、ダウンロードの終わりに、復号することができるビデオストリームを構築することができることが義務的であるので、タイルトラックとは異なる方法で、信号で送らなければならない。その目的のために、2つの要素が記述に加えられる。第1に、関連コンテンツコンポーネント618内の記述子は、それがすべてのコンポーネントの中の主要なコンポーネントであることを示す。第2に、対応するデータが要求されるべきであることをクライアントに対して示すために、サブリプレゼンテーション内に、新たな「required(必須)」属性が加えられる。複合トラック、またはタイルトラックの1つ以上に対する要求はすべて、セグメントリスト610内に提供されるURLから計算される(1時間間隔当たり1つ)。例では、MPDの先頭において「BaseURL」と組み合わされた「URL_X」は、HTTP GET要求を実行するためにクライアントが用いることができる完全なURLを提供する。この要求により、クライアントは、複合トラックのためのデータと、すべてのタイルトラックのためのすべてのデータとを得るだろう。要求の代わりに、伝送を最適化するために、クライアントは、index_range属性620からの利用可能なデータを用いて、セグメントインデックス情報(通常は、当業者により周知のISO BMFF内の「sidx」情報および/または「ssix」)を第1に要求することができる。このインデックス情報は、コンポーネントの各々のためのバイト単位の範囲を決定することを可能にする。そして、DASHクライアントは、適切なバイト単位の範囲で、(要求された複合トラックを含む)選択されたトラックと同数のHTTP GET要求を送信することができる。
ストリーミングセッションを開始するとき、DASHクライアントは、マニフェストファイルを要求する。一旦受信されれば、クライアントは、マニフェストファイルを解析し、その環境に適した1セットのAdaptationSetを選択する。次に、クライアントは、各AdaptationSet内部のMPDにおいて、その帯域幅と互換性をもつRepresentation、復号化およびレンダリング機能を選択する。次に、それは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求されるセグメントのリストを予め構築する。イニシャライゼーション情報が復号器によって受信されると、それらはイニシャライズされ、クライアントは、第1のメディアデータを要求し、ディスプレイを実際に開始する前に最小データ量をバッファする。
これらの複数の要求/応答は、ストリーミングセッションの起動における遅延を招くかもしれない。サービスプロバイダにとってのリスクは、ビデオを見始めることなくサービスを離れるクライアント見ることである。クライアントによって実行される第1のメディアデータチャンクのための初期のHTTP要求とメディアデータチャンクが実際に再生し始める時間との間の時間を、スタートアップ遅れとよぶことが一般的である。それは、ネットワークラウンドトリップ時間だけでなく、メディアセグメントのサイズにも依存する。
サーバプッシュは、ウェブリソースのローディング時間を減少させるために有用な機能である。このようなサーバは、図1a〜図1eを参照しながら論じる。
図1bでは、HTTP/2交換(HTTP/2 exchanges)において、要求は、必要とされるリソース:(図1aに示されるように)リソースR1〜R4およびサブリソースA〜Iごとに送信されなければならない、ということが図示される。しかしながら、サーバによるプッシュ機能を用いるとき、図1cに図示されるように、要求の数は、要素R1〜R4に制限される。要素A〜Iは、図1aに示される依存性に基づいてサーバによってクライアントに対して「プッシュされ」、それによって、不必要な関連する要求が生じる。
このように、サーバがプッシュ機能を用いる場合、図1bおよび図1cに図示されるように、そのサブリソースと共にリソースをロードするために必要なHTTPラウンドトリップ(要求+応答)の数が減少される。これは、モバイルネットワークなどの高待ち時間のネットワークにとって、とりわけ興味深い。
HTTPは、ウェブリソース、通常はウェブページ、を送信するために用いられるプロトコルである。HTTPは、クライアントとサーバとを暗に含む。
・クライアントは、サーバに対して要求を送信する。
・サーバは、クライアントの要求に対して、ウェブリソースのリプレゼンテーションを含む応答により返答する。
要求および応答は、様々な部分、特にHTTPヘッダ、を含むメッセージである。HTTPヘッダは、値と共に名称を備える。例えば「Host: en.wikipedia.org」は「Host(ホスト)」ヘッダであり、その値は「en.wikipedia.org」である。それは、問い合わされたリソースのホストを示すために用いられる(例えばHTTPを記述するウィキペディアページは、http://en.wikipedia.org/wiki/HTTPにおいて利用可能である)。HTTPヘッダは、クライアント要求およびサーバ応答上に出現する。
HTTP/2は、ストリームを通じて要求/応答を交換することを可能にする。ストリームは、HTTP要求および応答ごとにHTTP/2接続の内部で生成される。フレームは、要求および応答のコンテンツおよびヘッダを伝達するために、ストリーム内で交換される。
HTTP/2は、以下のような、個別の意味をもつフレームの制限されたセットを定義する。
・HEADERS:HTTPヘッダの伝送のために提供される
・DATA:HTTPメッセージコンテンツの伝送のために提供される
・PUSH_PROMISE:プッシュされたコンテンツのアナウンスのために提供される
・PRIORITY:ストリームのプライオリティを設定するために提供される
・WINDOW UPDATE:制御フローウィンドウの値を更新するために提供される
・SETTINGS:設定パラメータを伝達するために提供される
・CONTINUATION:ヘッダブロックフラグメントのシーケンスを継続するために提供される
・RST STREAM:ストリームの終了またはキャンセルのために提供される
サーバによるプッシュは、サーバがクライアントに対して自発的なウェブリソースリプレゼンテーションを送信することを可能にするために、HTTP/2に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク(モバイルネットワーク)上の、ウェブページの低速表示をもたらすであろう。
・DATA:HTTPメッセージコンテンツの伝送のために提供される
・PUSH_PROMISE:プッシュされたコンテンツのアナウンスのために提供される
・PRIORITY:ストリームのプライオリティを設定するために提供される
・WINDOW UPDATE:制御フローウィンドウの値を更新するために提供される
・SETTINGS:設定パラメータを伝達するために提供される
・CONTINUATION:ヘッダブロックフラグメントのシーケンスを継続するために提供される
・RST STREAM:ストリームの終了またはキャンセルのために提供される
サーバによるプッシュは、サーバがクライアントに対して自発的なウェブリソースリプレゼンテーションを送信することを可能にするために、HTTP/2に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク(モバイルネットワーク)上の、ウェブページの低速表示をもたらすであろう。
所定のウェブページに対する要求を受信するとき、サーバは、他のどのリソースが要求されたリソースの完全な処理のために必要とされるのかを知っているであろう。要求されたリソースおよびリンクされたリソースを同時に送信することによって、サーバは、ウェブページのロード時間を減少させることを可能にする。このように、プッシュ機能を用いて、サーバは、所定のリソースが要求されたときに、追加リソースリプレゼンテーションを送信してもよい。
図1eのフローチャートを参照して、プッシュ機能を実行するサーバの例示的なオペレーションモードを記述する。
ステップ100の間、サーバは、初期要求を受信する。次に、サーバは、ステップ101の間に応答の一部としてプッシュするリソースを識別し、ステップ102の間にコンテンツ応答を送信し始める。並行して、サーバは、ステップ103の間にクライアントに対してプッシュプロミスメッセージを送信する。これらのメッセージは、例えば図1aに示される依存性に基づいて、サーバがプッシュすることを意図している他のリソースを識別する。これらのメッセージは、どのプッシュされたリソースが送信されることになるのかをクライアントに予め知らせるために送信される。特に、これは、同時にプッシュされた、またはプッシュされようとしている、リソースに対して、クライアントが要求を送信する、というリスクを低減する。このリスクをさらに低減するために、サーバは、プッシュプロミス内に記述されるリソースを参照する応答のあらゆる部分を送信する前に、プッシュプロミスメッセージを送信するべきである。これは、また、クライアントがそれらのリソースを望まないならば、クライアントがプロミスされたリソース(promised resources)のプッシュのキャンセルを要求することを可能にする。次に、サーバは、ステップ104の間に、応答およびすべてのプロミスされたリソースを送信する。プロセスは、ステップ105の間に終了する。
図1dのフローチャートは、クライアント側の処理を示す。
クライアントがサーバから取り出すリソースを識別すると、対応するデータが既にそのキャッシュメモリ内にあるか否かを、ステップ106の間にまずチェックする。リソースが既にキャッシュメモリ内にある場合(はい(Yes))、ステップ107の間に、そこから取り出される。キャッシュされたデータは、先の要求から取りだされたデータ、またはサーバによって予めプッシュされたデータのいずれかであろう。それがキャッシュメモリ内になかった場合(いいえ(No))、クライアントは、ステップ108の間に、要求を送信し、サーバの応答を待つ。サーバからのフレームを受信すると、クライアントは、フレームがプッシュプロミスに対応するか否かを、ステップ109の間にチェックする。データフレームがプッシュプロミスに対応するならば(はい(Yes))、ステップ110の間、クライアントは、プッシュプロミスを処理する。クライアントは、プッシュされるリソースを識別する。クライアントがリソースを受信したくなければ、クライアントは、エラーメッセージをサーバに対して送信してもよく、そうすれば、サーバは、そのリソースをプッシュしない。そうでなければ、クライアントは、対応するプッシュコンテンツを受信するまでプッシュプロミスを保存する。サーバがそれをプッシュしている間に、クライアントがプロミスされたリソースを要求しないように、プッシュプロミスが用いられる。データフレームがプッシュプロミスに対応しない場合(いいえ(No))、ステップ111の間に、フレームがプッシュデータに関連するデータフレームであるか否かがチェックされる。それがプッシュデータに関する場合(はい(Yes))、クライアントは、ステップ112の間に、プッシュされたデータを処理する。プッシュされたデータは、クライアントのキャッシュ内に保存される。フレームがプッシュデータに関するデータフレームではない場合(いいえ(No))、ステップ113の間に、サーバから受信された応答にそれが対応するか否かがチェックされる。フレームがサーバからの応答に対応する場合(はい(Yes))、応答は、ステップ114の間に処理される(例えば、アプリケーションに対して送信される)。そうでなければ(いいえ(No))、フレームが応答の終了を識別するか否か(はい(Yes))が、ステップ115の間にチェックされる。この場合、処理は、ステップ116の間に終了する。そうでなければ、処理は、ステップ109に戻る。
このように、クライアントが応答およびプロミスされたリソースを受信する、ということが思われる。そのため、取りだされたウェブページを表示するブラウザなどのアプリケーションによって応答が用いられる間に、プロミスされたリソースは、一般的には、クライアントのキャッシュ内に保存される。クライアントアプリケーションがプッシュされたリソースの1つを要求するとき、リソースは、いかなるネットワーク遅延も引き起こさずに、クライアントのキャッシュから直ちに取りだされる。
キャッシュ内のプッシュされたリソースの保存は、キャッシュ制御指示を用いて制御される。キャッシュ制御指示は、また、応答の制御のために用いられる。これらの指示は、特に、プロキシに対して適用可能であり、プッシュされた若しくはプッシュされない任意のリソースは、プロキシ若しくはクライアントのみによって保存されてもよい。
図1aは、それらの関連性とともにサーバによって所有された1セットのリソースのグラフである。リソースのセットは、以下のように関連し合う。すなわち、R1、R2、R3、およびR4は、クライアントによって適切に処理されるために一緒にダウンロードされる必要のあるリソースである。さらに、サブリソースA〜Hが定義される。これらのサブリソースは、1つ、2つ、または3つのリソースに関連する。例えば、Aは、R1に対してリンクされ、Cは、R1、R2、およびR4に対してリンクされる。
既に上述した図1bは、サーバPUSH機能を用いないHTTP交換を示しており、クライアントは、R1を要求し、次にR2、A、B、C、およびDを発見し、それらを要求する。それらを受信した後、クライアントは、R3、R4、F、およびGを要求する。最終的に、クライアントは、HおよびIのサブリソースを要求する。これは、リソースの全体のセットを検索するために4つのラウンドトリップを必要とする。
既に上述した図1cは、サーバによって直接的に接続されるサブリソースをプッシュする機能を用いたHTTP交換を示す。R1を要求した後、サーバは、R1を送信し、A、B、C、およびDをプッシュする。クライアントは、R2を識別し、それを要求する。サーバは、R2を送信し、FおよびGをプッシュする。最終的に、クライアントは、R3、R4を識別し、これらのリソースを要求する。サーバは、R3、R4を送信し、HおよびIをプッシュする。これは、リソースの全体のセットを取りだすために3つのラウンドトリップを必要とする。
1セットのリソース、通常はウェブページおよびそのサブリソース、のローディング時間を減少させるために、HTTP/2は、複数の要求および応答のプライオリティを並列に交換することを可能にする。図2に図示されるように、ウェブページは、Java(登録商標)Script、画像などのような、いくつかのリソースのダウンロードを要求してもよい。初期のHTTP交換200の間に、クライアントは、HTMLファイルを検索する。このHTMLファイルは、2つのJava(登録商標)Scriptファイル(JS1、JS2)、2つの画像(IMG1、IMG2)、1つのCSSファイル、および1つのHTMLファイルに対するリンクを含む。交換201の間に、クライアントは、各ファイルに対する要求を送信する。図2の交換201において与えられる順序は、ウェブページの順序に基づき、クライアントは、リンクが見つかるとすぐに、要求を送信する。そして、サーバは、JS1、CSS、IMG1、HTML、IMG2、およびJS2に対する要求を受信し、その順序に従ってこれらの要求を処理する。そして、クライアントは、その順序で、これらのリソースを取りだす。
HTTPプライオリティは、どの要求がより重要であり且つ他の要求より早く処理されるべきであるかを、クライアントに明示することを可能にする。特定のプライオリティの使用を、交換202に示す。Java(登録商標)Scriptファイルは、最も高いプライオリティを割り当てられる。CSSおよびHTMLファイルは、中プライオリティを割り当てられ、画像は、低プライオリティを割り当てられる。このアプローチにより、ブロッキングファイル、または他のファイルより早く他のリソースに対する参照を含むことができるファイルを受信することができる。これを受けて、交換202に記述されるように、サーバは、まずJava(登録商標)Scriptファイル、その後CSSおよびHTMLファイル、最後には画像を、送信することを試みることが期待される。サーバは、クライアントプライオリティに従うようには義務付けられていない。
プライオリティに加えて、HTTP/2は、同時に交換されるデータ量を制御することができる、ということを提供する。クライアントおよびサーバは、接続ベース当たりおよびストリームベース当たりのバッファリングすることができるデータ量を指定することができる。これは、TCP輻輳制御と同様であり、利用可能なバッファサイズを指定するウィンドウサイズは、所定の値にイニシャライズされ、エミッタがデータを送信するたびに、ウィンドウサイズは減少し、エミッタは、ウィンドウサイズが0より下にならないようにデータの送信を停止しなければならない。受信器は、データを受信し、データがバッファから受信され取り出されたということを通知するメッセージを送信し、メッセージは、バッファから取り出されたデータ量を含んでおり、そして、ウィンドウサイズが所定の値から増加され、エミッタは、データを送信することを再開することができる。
上記を考慮すると、クライアントは実行しているアプリケーションの目的のためにコンテンツのベストのリプレゼンテーションを一般的には選択することができるので、DASHは、クライアントがストリーミングをリードするという前提に基づくように思われる。例えば、クライアントは、そのフォームファクタおよびスクリーン解像度に基づいて高解像度または小解像度のコンテンツを要求するべきかどうかを認識していてもよい。
サーバベースのストリーミングは、通常は、RTPを用いて実行される。DASHとは対照的に、RTPは、HTTPを用いず、ウェブインフラストラクチャ、特にプロキシ、キャッシュから直接的に恩恵を受けることができない。ウェブソケットベースのメディアストリーミングは、同じ短所を持つ。HTTP/1.1では、サーバがクライアント要求に対して一般的には答えることしかできないので、サーバベースのストリーミングは、容易に実行することができない。HTTP/2では、特にプッシュ機能の導入では、DASHベースのサーバは、ストリーミングを通すことができる。このように、サーバは、ユーザエクスペリエンスを最適化するために、ストリーミングしているコンテンツの特性のサーバの知識を用いることができる。例えば、サーバは、広告は付加的な限定的な量の帯域幅を利用するのでアドバーティスメントをHDとしてプッシュすることを除けばフィルムをSDとして(制限された帯域幅のために)プッシュするかもしれない。別の例は、低解像度ビデオでの高速起動を実行し始め、且つ一旦帯域幅が十分に推定されれば可能な限りベストのリプレゼンテーションに切り替える、サーバのケースである。
サーバがストリーミングを通すことを可能にするために、1つのアプローチは、サーバに好ましくはデータ(特にDASHデータ)をプッシュさせることである。そして、クライアントは、ビデオを表示するのに利用することができるいかなるデータも用いる。サーバは、通常は、一度にいくつかのセグメントのプッシュをアナウンスする。そして、サーバは、並行してまたは連続的にセグメントを送信する。
発生する問題は、クライアントとサーバはプロミスされたデータが望まれる時間に送られ、受信されるかどうか、わからないかもしれないことである:クライアントは、ビデオセグメントが、いつ、どの順序で送信されることになるのかをわからないかもしれない。
また、サーバによってプッシュまたはアナウンスされた、プロミスされたデータは、クライアントのニーズにミスマッチするかもしれず、それにより、サーバエンドにおいて特にリソースを無駄にすることになる。
このように、特に、DASHベースの通信との関連においてデータストリーミングを強化する必要性がある。
上記の課題を解決するために、本発明のサーバは、例えば、以下の構成を有する。すなわち、メディアデータをクライアントへ送信するサーバであって、前記クライアントから第1メディアデータのリクエストを受信する受信手段と、前記受信手段によるリクエストの受信に応じて、前記クライアントに対して前記第1メディアデータを送信する送信手段と、前記第1メディアデータのリクエストを送信した前記クライアントに対してプッシュすべき第2メディアデータを、前記クライアントとの間で共有されたプッシュストラテジーを用いることによって特定する特定手段と、前記特定手段により特定された前記第2メディアデータを前記クライアントに対してプッシュするプッシュ手段とを有する。
本発明の他の機能および効果は、図1〜図6に加えて、添付された以下の図面を参照しながら、非限定的な好ましい実施形態の以下の記述から明らかになる。
以下において、本発明の実施形態は、HTTP2.0プロトコルを実施するDASHに基づくネットワークとの関連で記述される。ストリーミングされるデータは、例えばビデオデータである。本発明の実施形態は、DASHネットワークに限定されない。
クライアント装置に対してデータをストリーミングする通信ネットワークのサーバ装置は、送信されるデータ要素に対するクライアントからの明示的リクエストを伴わずに、クライアントに対してデータ要素を送信することができることによる、プッシュ機能を実施する。
サーバおよびクライアントは、プッシュプロミスを決定し、且つ対応するデータを実際に送信するように、サーバを駆動するプッシュポリシーを共有してもよい。この共有により、クライアントは、そのようなプッシュをキャンセルするために、いくつかの無用データのプッシュを予期することができる。PUSH_PROMISEフレームは、送信される前にキャンセルされてもよいので、これは、ネットワーク使用と同様に、サーバの処理も減少させることになる。
具体的なの実施形態において、サーバは、明確に要求されていないデータ要素の送信をアナウンスする、そのプッシュプロミスにおいて、データ要素を送信するように意図するサーバの順序に関係する順序付け情報を示すことができる。データ要素の順序は、プライオリティ値、例えばHTTP/2によるプライオリティ値、を用いて定義されてもよい。
プッシュプロミスを受信すると、クライアント装置は、サーバによって意図された送信の順序を予め決定することができ、それによって、クライアントは、自身の所望の順序と一致しなかった場合に、提案された順序付けに対応できる。例えば、クライアント装置は、プライオリティ値を更新し、更新されたプライオリティ値をサーバに対して送信することができる。サーバは、したがって、クライアントのニーズと適切に一致させるために、新たなプライオリティ値に基づいて送信順序付けを変更することができる。サーバは、将来のデータ送信を考慮して、更新されたプライオリティを用いることができる。
実施形態によれば、クライアントは、サーバに対するデータ要素の送信の全面的な順序付けまたは部分的な順序付けを要求しても良い。
図7aを参照して、全面的な順序付けを説明する。クライアントは、ステップ700の間に、メディアプレゼンテーション記述(以降、MPD)をサーバに対して要求する。サーバは、ステップ701の間に、クライアントに対して返送するMPDを取得し、プッシュするべき対応するデータ要素を識別する。図7aの例において、サーバは、「データ1.1」、「データ1.2」および「データ1.3」をプッシュするデータ要素として識別する。これらの要素は、例えばデータセグメントである。要素「データX.1」は、データXのためのベース層を表現し、要素「データX.2」は、データXのためのエンハンスメント層を表現し、「データX.3」は、データXのための付加的なエンハンスメント層を表現する。サーバは、データ要素のための具体的な送信の順序を定義する。サーバは、来たるプッシュデータ要素のアナウンスのためにクライアントに対して送信される、PUSH_PROMISEフレームに、それぞれのプライオリティ値を関連づける。そして、サーバは、ステップ702の間に、関連するプライオリティおよびMPDにより、PUSH_PROMISEフレーム「P1.1」、「P1.2」および「P1.3」を送信する。次に、MPDおよびプッシュプロミスを送信した直後、ステップ703の間に、サーバは、クライアントに対して、定義された送信順序における「データ1.1」、「データ1.2」および「データ1.3」に続くセグメントである、「データ1.1」要素に対応するデータフレームと要素「データ2.1」、「データ2.2」および「データ2.3」にそれぞれ対応するPUSH_PROMISEメッセージ「P2.1」、「P2.2」および「P2.3」とを送信する。データフレームの受信およびステップ703のプッシュプロミスと並行して、クライアントは、MPDおよび「P1.1」、「P1.2」および「P1.3」PUSH_PROMISEフレームの受信後に、エンハンスメント層「データ1.2」は付加的なエンハンスメント層「データ1.3」に比較して低いプライオリティである、と判断する。したがって、クライアントは、ステップ704の間に、低い「データ1.2」プライオリティに対してプライオリティ更新フレームを送信する。プライオリティ更新要求を受信すると、サーバは、ステップ705の間に、送信のスケジュールを変更する。その結果、「データ1.3」が送信された後、「データ1.2」の送信は先延ばしされる。さらに、サーバは、「データ1.2」に関連付けられたセグメントをリンクするためにMPDを用いる。サーバは「データ2.2」を識別し、そのプライオリティを減じる。
図7bを参照して、部分的な順序付けを説明する。図7bのステップ710〜714は、図7aのステップ700〜704と実質的に同じである。プライオリティ更新フレームの受信の後、サーバの挙動は、先に記載されたステップ705と比べて異なる。ステップ715の間、サーバは、既に「データ1.2」の送信を開始しており、送信をさらに進める。そのセグメントに関して、プライオリティに変更はない。サーバは、それにもかかわらず、連結されたセグメント、すなわち本例における「データ2.2」)のプライオリティを更新する。プライオリティ変更が考慮さられた、という事実をアナウンスするために、サーバは「データ2.2」のためのプライオリティ更新マッサージ(priorityupdate massage)を送信してもよい。クライアントは、したがって、変更を通知されることができる。
本発明の実施形態は、ビデオのすべての部分を高品質に再生することができるように、サーバが予め十分に良い高品質のビデオ部分をプッシュすることができる使用事例において実施されてもよい。例えば、ビデオは、低品質として再生される部分1、高品質として再生される部分2、および低品質として再生される部分3に分割されることができる。クライアントとサーバとの間の帯域幅は、高品質ではなく低品質のリアルタイムストリーミングを可能にする。その場合、サーバは、部分2を強化し、部分1をインターリーブしてもよい。一旦部分1が再生されれば、強化された部分2は、また、利用可能であり、サーバは、同じ部分2の強化と共同して高品質として再生される部分2のベース層を送信する。このように、サーバは、すべての部分2が高品質として再生されることを確実にする。部分3は、その後に送信される。ユーザエクスペリエンスを妨害する品質のちらつき(quality flickering)を軽減することができ、品質の切り換え(quality switching)のみが、限られた数のモーメントにおいて行われる。サーバは、ビデオコンテンツを認識して以後、異なる品質レベルにいつ切り替えるべきであるかを認識するために最善位置にある。
図8は、実施形態にかかる、プッシュベースのDASHメディアストリーミングを実施するサーバによって実行されたステップのフローチャートである。ステップ800〜812は、一般的な原理を記述する。ステップ820〜827は、より具体的には、クライアントからのプライオリティのフィードバックの管理に対処する。
ステップ800の間、サーバは、クライアントから要求Rを受信する。この要求は、通常はMPDファイルを参照することによって特定のメディアを識別する。次に、サーバは、ステップ801〜810を含む反復処理を実行する。その処理は、定義された順序にしたがってデータを送信することを有する。送信の順序は、クライアントのフィードバックにしたがって更新される。一旦データが送信されれば、それらはクライアントによって受信され再生される。次に、サーバは、送信するべき新たなデータを識別し、処理は、そのように継続し続ける。
第1の反復は、送信されるデータが識別される間のステップ801で始まる。反復処理の第1の実行の場合、クライアントがビデオ再生を可能な限り迅速に開始することを可能にするために、高速起動アプローチが用いられてもよい。さらに、サーバは、また、チャプターへのメディアの細区分を識別しても良い。クライアントが一般的にはチャプターを用いてナビゲートする、ということをサーバが認識する場合、サーバは、メディアの先頭に対して対応するセグメントだけでなくメディア内の第1のチャプターの開始に対応するセグメントも実際に選択してもよい。反復の第1の実行の後、サーバは、また、接続がメディアの高品質のリプレゼンテーションの送信をサポートすることができる、ということを検出しても良い。このように、サーバは、解像度または品質の切り換えをいつ行うべきであるのかを識別しても良い。
一旦サーバがプッシュするセグメントのリストを識別すれば、サーバは、これらのセグメントのための送信順序を定義する。送信順序は、1ステップ802の間に各々のプッシュされたセグメントに対する初期のプライオリティ値を算出するために用いられる。順序付けは、いくつかのパラメータに基づいてもよい。
第1のパラメータは、異なるセグメント間の関連性であってもよく、例えば、いくつかのセグメントは、他のセグメントを正確に復号するために利用可能でなければならない。利用可能でなければならないセグメントは、したがって、前記他のセグメントよりも高いプライオリティを割り当てられる。
第2のパラメータは、過去統計値から採集することができる、ビデオセグメントの人気度であってもよい。例として、YouTube(登録商標)のURLにより、ビデオ内の特定の期間をアドレス指定しても良い。これらのURLSに関連するリンク上をクリックすると、特定の時刻にビデオ再生をスタートするために必要とされるビデオのみが取りだされる。さらに、ビデオがチャプター化されている場合、各々のチャプターの先頭は、一般的には多くの場合、チャプター開始の間のセグメントよりもユーザから取りだされる。チャプターの先頭のSegmentsは、したがって、中間のチャプターセグメントインよりも高いプライオリティを割り当てられる。
第3のパラメータは、タイムラインであってもよく、再生されているビデオセグメントにより近いビデオセグメントのプライオリティは、後で再生されることになるビデオセグメントのプライオリティより高い。
第4のパラメータは、セグメントを実際に送信するために費やされる推定時間であってもよい。ビデオセグメントが大きい場合、送信するのに長い時間がかかり、そのため、できるだけ早く、すなわち高プライオリティで、送信を開始するべきである。
2つのセグメントが同一のプライオリティを有する場合、対応するデータフレームは、送信の間にインターリーブすることができる。関心領域がメディアコンテンツ内で識別された場合、帯域幅が高品質のリプレゼンテーションには十分に大きくはないが、低品質のリプレゼンテーションには十分に大きければ、サーバは、関心領域のためにのみエンハンスメント層を選択してもよい。
一旦プライオリティが算出されれば、サーバは、ステップ803の間に、プライオリティ値を含むPUSH_PROMISEフレームを送信する。すべてのセグメントの識別は、PUSH_PROMISEフレームの送信を開始するためには必要でない。MPDがプッシュされるセグメントのために送信される場合(ステップ804)、MPDが送信される(ステップ805)。セグメント送信は、ステップ806の間に、並列的に開始する。
一旦PUSH_PROMISEフレームがクライアントによって受信されれば、サーバは、プライオリティ更新変更を受信し、その後、それに応じて、その送信スケジュールを変更してもよい(ステップ807〜808およびステップ820〜828)。セグメントを送信する一方で、サーバは、プライオリティ変更メッセージの受信を待つ。プライオリティ変更メッセージが受信された場合(ステップ807)、サーバは、それに応じてセグメントを再順序付けて、セグメント送信を継続する(ステップ808)。一旦すべてのセグメントが送信されると(ステップ809−1)、サーバは、メディアの端部までメディアをストリーミングし続けるために反復処理を再開する。メディアの端部に到達すると(ステップ809−2)、サーバは、別のメディアを自動的にストリーミングし始めるべきか否かをチェックする(ステップ810)。別のメディアがストリーミングされるべきである場合(はい(Yes))、サーバは、ストリーミングする新たなメディアを識別し(ステップ811)、ステップ801から処理を再開する。新たなデータがストリーミングされるべきでない場合、処理は停止される(ステップ812)。
クライアントからのプライオリティのフィードバックの、すなわちステップ808の管理は、ステップ820の間に、プライオリティ更新変更メッセージの受信とともに始まる。クライアントがセグメントプッシュをキャンセルした場合、以下のステップが実行されてもよく、このケースは、そのセグメントに対して最も低いプライオリティを割り当てることと実際には同等であると、理解してもよい。
プライオリティ更新変更メッセージを受信すると、サーバは、ステップ821の間に、関連セグメントを識別する。そして、サーバは、セグメント送信の再順序付けを進める(ステップ822および823)。セグメントが既に送信されていれば、処理は終了する。セグメントが送信されているならば、サーバの実装に応じて、送信を変更することを拒絶してもよいし(例えば複雑すぎるので)、または、送信される残りのデータを実際にスケジュール変更してもよい。
データのスケジュール変更は、以下のように実行されてもよい。サーバは、プッシュするビデオセグメント(および/またはプッシュされるビデオセグメント)のリストを保存する。このリストは、サーバによって設定されたプライオリティにしたがって順序付けられる。そして、サーバは、セグメントに新たなプライオリティ値を設定する。そして、リストが再順序付けられ、対応するビデオセグメントの送信は、それに応じて、早くなったり遅くなったりする。
一旦ビデオセグメントが再順序付けられれば、サーバは、他の関連するビデオセグメントに対して、このプライオリティ変更を適用することを実際に決定してもよい。クライアントがエンハンスメント層の一部であるビデオセグメントのプライオリティを引き上げれば、サーバは、このエンハンスメント層のすべてのセグメントのプライオリティを引き上げてもよい。逆に、クライアントがベースビデオセグメント層のプライオリティを引き下げる場合、このセグメントに一時的に関連するすべてのセグメントのプライオリティが引き下げられてもよい。この処理は、ステップ824〜827に記述される。MPDおよびスケジュール変更されたビデオセグメントに基づいて、サーバは、関連セグメントのリストを識別する(ステップ824)。関連性は、時間、空間、品質ベースなどであってもよい。MPDは、潜在的な関連性をより適切に示すために強化されてもよい。特に、(1つ以上のビデオセグメントを再生するのに必要である)イニシャライゼーションセグメントのプライオリティが引き下げられるかまたは引き上げられると、すべての関連セグメントがスケジュール変更されてもよい。これは、ベース層セグメントおよび強化セグメントの同様のケースになり得る。各々の識別された関連セグメントに対して、サーバは、関連セグメントの送信が変更されるべきであるか否かテストする(ステップ825)。変更されるべきである場合、サーバは、各セグメントに対して新たなプライオリティ値を算出し(ステップ826)、それに応じて、セグメント送信をスケジュール変更する(ステップ827)。新たなプライオリティ値は、ステップ820の間に受信された新たなプライオリティ値とステップ821の間に識別されたセグメントの初期のプライオリティ値との間の差分を古い値に対して加えることによって算出されてもよい。各関連セグメントがテストされると、処理は停止する(ステップ828)。
サーバは、また、WINDOW SIZEフレームなどの制御フローメッセージを受信してもよい。これらのメッセージによって、サーバは、クライアントが現在何を再生しているのかを、識別することが出来るであろう。いくつかの追加的バッファスペースがクライアントの端上で利用可能な場合、いくつかのデータ、通常は最も古いデータ、がバッファから取り出された、ということが推測され得る。サーバが送信されたデータの履歴を保持すれば、サーバは、どのデータが取り出されたのかを識別することができる。このように、もしサーバが、クライアントのキャッシュの順序付けを認識しているならば、サーバは、クライアントが現在どのビデオセグメントを再生しているかを知ることができる。この順序付けは、タイムラインにしたがってキャッシュされたデータを、順序付けることを可能的にするMPDに基づいてもよい。そして、サーバは、例えばクライアントの時間スキップを検出することができる。サーバは、クライアントがビデオチャプターをスキップし続けることができるように、予め次のチャプターの開始を迅速に送信することによって対応してもよい。
プライオリティをもつPUSH_PROMISEフレームの送信が様々な方法で行われてもよい、ということを留意するべきである。PUSH_PROMISEフレームは、クライアントによって起動される開かれたストリーム(opened stream)に関連しなければならない。実施形態によれば、ステップ800の間にクライアントによって行われた初期のストリームは、常に開かれたままであってもよい。他の実施形態によれば、PUSH_PROMISEフレームは、サーバによって開かれたストリーム内で送信される。この場合、それが親クライアントに起動されたストリームによって送信されるように、クライアントは、PUSH_PROMISEフレームを考慮する。このように、個々のPUSH_PROMISEフレームに対応する仮想要求の正しいヘッダを算出することができる。
他の実施形態によれば、プライオリティメッセージは、PUSH_PROMISEと共同で送信される。第1の可能性は、PUSH_PROMISEフレーム内部のヘッダとしてそれを送信することである。もう1つの可能性は、対応するPUSH_PROMISEフレームによって保存されたストリームIDを持つPRIORITYフレームを送信することである。第3の可能性は、このPUSH_PROMISEフレーム、その後、(ストリームを開くために)対応するHEADERSフレーム、および新しく開かれたストリーム上のPRIORITYフレームを送信することである。
さらにクライアントのバッファを制御するために、サーバは、クライアントによってキャッシュされたセグメントの新たなリプレゼンテーションを送信してもよい。この新たなリプレゼンテーションの一部として送信されたヘッダ内で、HTTPキャッシュ指示は、例えばキャッシュすることができるものとしてそれをマークすることによって実際にセグメントを取り出すことをクライアントに要求するために用いられてもよい。これにより、クライアントの端上のバッファスペースを回復することが可能となる。HTTP/2制御フローが用いられてもよい。そして、サーバは、付加データをプッシュすることができる。
サーバは、各ビデオセグメントのプライオリティ値を送信してもよい。サーバは、また、特定セグメントのためのプライオリティ値を送信してもよい。サーバが、現在のPUSH_PROMISEフレームのプライオリティ値を送信しなかった場合、クライアントは、サーバから送信された最後のプライオリティ値からプライオリティ値を算出することができる。例えば、クライアントは、関連付けられたプライオリティ値がない新たなPUSH_PROMISEフレームが受信されるたびにプライオリティ値を増加させてもよい。従って、特定セグメントのプライオリティの更新をするとまたグループのすべてのセグメントのプライオリティを更新するように、PUSH_PROMISEフレームは、グループ化することができる。
図9を参照してクライアント側の処理を説明する。
クライアントは、所定の時間に利用可能なコンテンツを再生可能であるべきである。しかしながら、クライアントは、潜在的なバッファ制限および処理時間に対処しなければならない。クライアントは、サーバによって提案された送信順序付けがクライアントのバッファにおいて利用可能なメモリスペースと一致し、且つクライアントによって現在再生されているコンテンツと一致するか否かを、チェックしなければならない。
最初のステップ900の間に、クライアントは、サーバに接続して、MPDファイルを要求する。そして、クライアントは、ステップ901の間にMPDファイルを取り出し、データの受信を待つ(ステップ902)。データが受信されると、クライアントは、データがプッシュプロミスであるか否かをチェックする(ステップ903)。プッシュプロミスが受信された場合、これは、新たなビデオセグメントがサーバによって送信されている、ということを意味する。クライアントは、プッシュプロミスを処理する。特に、クライアントは、ステップ904の間にサーバによって提案されたプライオリティ値を認証してもよい。クライアントが現在のセグメントまたは別のプロミスされたセグメントのプライオリティ値を変更したい場合(ステップ905)、クライアントは、新たなプライオリティ値を算出して、それをサーバに対して送信する(ステップ906)。
クライアントがビデオデータを受信すると(ステップ907)、クライアントは、ビデオセグメントをMPDファイルにリンクし(ステップ908)、ビデオデータ(ステップ909)を保存する。ビデオデータをMPDファイルにリンクすると、ビデオの復号のためにさらに用いられる場合にクライアントがビデオセグメントを取りだすことが可能になる(ステップ911)。例えば連続したビデオセグメントがグループ化されると、これは、また、ビデオデータの効率的な保存を提供することができる(ステップ909)。
バッファ保存制約は、さらにプライオリティを変更することができる。このように、クライアントは、プライオリティ値を変更しなければならないかどうかを再びチェックすることができ、もし必要ならばサーバと通信してもよい(ステップ905および906)。
一旦クライアントがビデオを再生し始める、または再生し続ける準備ができれば(ステップ910)、クライアントは、そのキャッシュから次のタイムスロットのビデオセグメントを取り出し(ステップ911)、ビデオを復号して再生する(ステップ912)。ステップ911の一部として、クライアントは、どのビデオセグメントが利用可能であるのかを認識するためにそのキャッシュを問い合わせることができる。デフォルトでは、クライアントは、利用可能なすべてのビデオセグメント、もしあれば特にすべての強化セグメント、を用いてもよい。クライアントは、サーバにコンテンツを選択させることができ、一般的には言えば、すべてのセグメントは、クライアントによって用いられるべきである。(オーディオの英語トラックおよびフランス語トラックのような)いくつかのセグメントを共同で用いることができなければ、クライアントは、まず第1に未使用のセグメントを捨てるべきである。すべてのクライアントがキャッシュ状態に対してアクセスするとは限らないかもしれない、ということに留意するべきであり、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。例えば、この情報は、ウェブソケット接続を用いて、サーバからクライアントに交換されてもよい。
ビデオが再生されて復号されるとともに、対応するビデオセグメントは、バッファから取り出されるであろう。従って、クライアントは、WINDOW SIZEフレームを用いて、その利用可能なバッファサイズを更新する。クライアントは、ユーザが限られた期間の間にビデオを巻き戻すことを可能にするために、最近再生されたビデオセグメントを保持してもよい。ユーザが早送り/タイムスキップを行う場合、フロー制御更新メカニズムも用いられてもよい。クライアントは、新たなコンテンツのために場所を空けるために、前から保存されたビデオコンテンツを取り出してもよく、WINDOW SIZEフレームを用いて、サーバに対してこの変更をアナウンスする。サーバがWINDOW SIZEフレームを受信すると、サーバは、前述のように、どのビデオセグメントが取り出されたのかを算出し、その後、クライアントが実際に何を再生しているのかを識別することができるであろう。
以下において、ステップ904をさらに詳細に説明する。
クライアントは、すべてのプッシュプロミスビデオセグメントのリストを保持する。このリストは、プッシュプロミスフレームにおいて見つかったプライオリティ情報にしたがって順序付けられる。第1に、それは潜在的な凍結されたビデオ問題のためにチェックされる。利用可能な帯域幅の推定および順序付けられたビデオセグメントリストに基づいて、各セグメントの送信の始まりおよび終わりの時刻を推測することができる。これらの時刻に基づいて、各ビデオセグメントはビデオ再生のために用いられる時刻に利用可能であるか否か、をテストされることができる。プロミスされたビデオセグメントがその対応するビデオ再生の使用の後に配送されることが予定される場合、そのプライオリティを上げるべきである。このように、このビデオセグメントは、プッシュプロミスビデオセグメントリスト内の順序が繰り上げられる。正確なプライオリティ値を算出するために、ビデオセグメントを時間通りに配送することを可能にするとともに、現在のビデオセグメントの位置に最も近い、ビデオセグメントリスト内における位置を検索する。そして、プライオリティは、ビデオセグメントの新たな位置の前後にあるリスト内のビデオセグメントのプライオリティ間の値に設定される。
他のファクタも、また、ビデオセグメントのプライオリティの変更のために、クライアントによって用いられてもよい。例えば、クライアントがいくつかのチャプター切換を行うことを予定していれば、クライアントは、チャプターを開始するすべてのビデオセグメント、特に対応するイニシャライゼーションセグメント、のプライオリティを実際に拡大してもよい。
実施形態によれば、クライアント側フロー制御は、ストリームごとのフロー制御を停止させて接続ごとのフロー制御のみを保持することを有する。接続ごとのウィンドウサイズは、クライアントが実際にいかなるときにも保存してもよいビデオの最大量を定義する。クライアントおよびサーバは、このウィンドウサイズを減少または拡大するためにイニシャライゼーション時や接続中にネゴシエイトしてもよい。サーバがいくつかのHDコンテンツをプッシュしたければ、サーバは、ウィンドウサイズを拡大することをクライアントに要求してもよい。接続帯域幅が低いならば、サーバは、ビデオの特定の部分のためのHDコンテンツを送り出すことを予め十分に予期する必要があるかもしれず、その場合には、バッファサイズは、より大きくされる。
バッファが単一のサイズを有する場合、送信の順序は、重要な問題であるであろう。特に、バッファがデータでいっぱいになった時に、プライオリティ順序付けは、より一層重要になる。重要な制約は、ビデオがフリーズしないということである。バッファが大きく空いている限り、サーバは、効率的な早送りまたはチャプタースキップを提供するために、かなり先行したセグメントのような様々なビデオセグメントを予めプッシュしてもよい。一旦バッファがほぼ満タンになれば、プッシュするビデオセグメントは再生されるビデオセグメントになるべく近いるべきである。サーバがクライアントバッファに関係する正確な情報を有していれば、このプッシュ挙動は、サーバによって行われてもよい。また、それは、プライオリティ更新メカニズムを用いて、クライアントによって実施されてもよい。
自動化されたビデオ切換の場合には、図9のフローチャートは、プッシュプロミスチェックの一部として新たなMPDのプッシュを検出することによって拡張されてもよい(ステップ903)。MPDプッシュが検出されると、クライアントは、ステップ908の一部として新たなビデオのセグメントを受信し始めてもよい。そのため、クライアントは、ビデオデータに関連するMPDを識別しなければならない。一旦ビデオ再生が所定のMPD(ステップ902)のために終了されると、新たなMPDは、ビデオ再生の継続のために用いられる。クライアントは、先のMPDにリンクされたビデオセグメントをすべて実際に消去することができる。
図10を参照して、DASH認識プロキシの挙動を説明する。サーバからプッシュされたセグメントを受信すると、プロキシは、エンドクライアントに対してそれをプッシュするようには要求されない。しかしながらDASHストリーミングの場合には、それは優れた方式(またはデフォルトの挙動)と考えられる。
プロキシは、送信されるプッシュされたデータだけでなくプライオリティ処理に関して、サーバおよびクライアントの挙動を調整することができてもよい。プロキシは、実際、クライアントによるプライオリティを、サーバによるプライオリティから独立して取り扱ってもよい。さらに、サーバは所定のクライアントのために必要とされる以上のデータをプッシュしてもよく、プロキシは、他のクライアントからの要求を実現するために付加的なプッシュされたデータを取り込んでもよい。
サーバは、いくつかの理由によりビデオセグメントをプッシュしてもよい。例えば、それがエンドクライアントのために有用であると考えられた場合、ビデオセグメントがプッシュされてもよい。ビデオセグメントは数回使用することが可能で、且つプロキシに対してそれをプッシュする価値があると考えられる場合、ビデオセグメントもプッシュされてもよい。
第1のケースにおいて、プロキシは、一般的には、クライアントに対してビデオセグメントを送信する。プロキシは、クライアントまたはプロキシのネットワーク状態(例えばクライアント無線状態)を最適化するためにその送信を先延ばししてもよい。例示的なケースは、高速起動ビデオ再生および帯域幅推定のためのセグメントプッシュであり、その場合には、データはクライアントに対して可能な限り高速に送信されるべきである。サーバがプロキシに対するデータのプッシュに関心がある場合、プロキシは、ビデオセグメントがクライアントに対して有用になることを認識する手段を有する場合以外は、クライアントに対してビデオセグメントを自動的に送信しなくてもよい。クライアントに対して送信されなくてもよいビデオセグメントの識別を可能にするために、特定のプライオリティ値を用いてもよい。プライオリティ値を用いると、到達する様々なフレームの処理を最適化するためにプロキシが常にプライオリティ値をチェックすることができる。
図10は、3つのフローチャートを含む。1つのフローチャートは、プッシュされたセグメントをフィルタリングする処理に関する(ステップ1000〜1008)。もう1つのフローチャートは、セグメントが別のクライアントに対して既にプロミスされている一方で、セグメントがクライアントによって要求された場合に実行される処理に関する(ステップ1010〜1015)。もう1つのフローチャートは、プライオリティ変更の管理に関する(ステップ1020〜1026)。
プッシュされたセグメントをフィルタリングする処理は、プッシュされたデータイベントの受信(ステップ1000)とともに、通常はPUSH_PROMISEフレームまたは関連するDATAフレームを受信したときに、始まる。プロキシは、データが高プライオリティであるか否かをチェックする(ステップ1001)。データは、それらのプライオリティ値が送信されている他のセグメントのプライオリティ値よりはるかに大きい場合、高プライオリティであると考えられる。データは、また、そのプライオリティ値が高速起動または帯域幅推定などの特別の意味を有するならば、高プライオリティであるとして考えられる。データが高プライオリティである場合、それらはクライアントに対して可能な限り迅速に送信される(ステップ1002)。そして、プロキシは、データを保存するべきであるか否かを決定する(ステップ1003および1004)。プッシュされたデータストリームを開く対応するPUSH_PROMISEフレームまたは対応するHEADERSフレームを受信すると、この判定は、一回行われてもよい。この判定は、また、プロキシのキャッシュ状態、ビデオの予見された使用、ビデオソースの人気度、または他の基準に基づいてもよい。セグメントが1つ以上のクライアントによって同時に要求される間にプッシュされれば、プロキシは、ビデオセグメントを保存する。セグメントが高速起動として識別されれば、ビデオセグメントもまた保存されてもよい。
データが高プライオリティでないならば、プロキシは、それが低プライオリティであるか否かをチェックする(ステップ1005)。低プライオリティのデータは、クライアントに対する送信がスキップされてもよいが、プロキシのようなネットワーク媒介に対して興味深いものとしてサーバによって考慮されるデータかもしれない。プロキシは、まず、クライアントに対してデータを送信するべきか否かを決定する(ステップ1006)。プッシュされたデータストリームを開く対応するPUSH_PROMISEフレームまたは対応するHEADERSフレームを受信すると、この判定は、一回行われてもよい。そのように決定されれば、プロキシは、クライアントに対して、対応するフレームを送信する(ステップ1002)。そして、処理は、データを保存するべきか否かを決定した後に停止する。
サーバとプロキシとの間でネゴシエイトされたプライオリティ値は、また、クライアントとプロキシとの間でネゴシエイトされたプライオリティ値とは異なってもよい。そのため、データが通常のプライオリティである(すなわち、低プライオリティでもなく、高プライオリティでもない)場合、プロキシは、セグメントのプライオリティ値がプロキシによって管理されるか否かをチェックする。図10に図示されるように(ステップ1020〜1026)、プロキシは、データが送信されるべき時刻をスケジューリングするためにクライアント〜プロキシ間の値を用い、プロキシは、送信されるべきすべてのビデオ関連のフレームのリストを保持する。これらのフレームは、その順序にしたがって送信される前に、プライオリティ値にしたがって順序付けられる。
プロキシは、プライオリティ更新フレームを受信している場合に(ステップ1010)、プロキシは、関連するビデオセグメントを識別する(ステップ1011)。そのプライオリティ値がプロキシによって管理されていなければ(ステップ1012)、プロキシは、サーバに対してプライオリティ更新フレームを転送する(ステップ1013)。さもなければ、プロキシは、この新たなプライオリティ値を保存し、それに応じて、ビデオセグメントの送信を再順序付ける(ステップ1014)。潜在的な競合が出現した場合、特にサーバからのビデオセグメントの配信がクライアントのニーズに対して遅れすぎると予想される場合、プロキシは、サーバに対してプライオリティ値を転送することができる。
ステップ1020〜1026は、サーバによって既にプロミスされているビデオセグメント(ステップ1020)のクライアントから別のクライアントに対する要求を受信するプロキシのケース(ステップ1021)に関連する。その要求に対して与えられるプライオリティに応じて、プロキシは、クライアントの要求を満たす、プロキシ〜サーバ間の最小のプライオリティを算出する(ステップ1022)。この計算は、サーバ〜プロキシ間の配信時刻がプロキシ〜クライアント間の予定した配信時刻よりも早いということを保証する、プロキシ〜サーバ間のプライオリティ値を算出することによって行われる。プライオリティは、算出されたプライオリティが現在設定されているプライオリティを下回る場合に、変更され(ステップ1023)、その場合には、プロキシは、プライオリティ更新メッセージをサーバに対して送信することになり(ステップ1024)、プロキシは、プロキシがそれらのニーズに対して最良の時刻にその2つのクライアントに対してビデオセグメントを送信するように、プロキシによって管理されるようなこのビデオセグメントプライオリティをマークすることになる。この処理と同様に、プロキシは、いくつかのクライアントから同じセグメントに対する、いくつかのプライオリティ更新を受信してもよく、その場合には、プロキシは、すべてのクライアントを満たす最も低いプライオリティ値を実際に送信してもよい。
図11を参照して、プッシュされたデータイベントをクライアントが受信することによる実施形態が説明され、そのデータイベントのプライオリティ値は、サーバが帯域幅の測定のためにそれを用いたいということを示す。帯域幅の測定は、ラウンドトリップ時間を算出するための能動的または受動的な測定を通じてTCP/IPパケットを用いて行われてもよい。ラウンドトリップ時間に基づいて、利用可能な帯域幅は、Saubhasik他の文献「BitVampireにおける帯域幅推定および速度制御(Bandwidth Estimation and Rate Control in BitVampire)」に見出されるように、算出されてもよい。この計算は、場合によっては、HTTP/2制御フローの影響を考慮に入れてもよい。いくつかのデータフレームが可能な帯域幅推定のために用いられる、という通知を行うことによって、HTTP/2制御フローなしで、利用可能な帯域幅を推定することができる。
処理は、プッシュされたデータフレームがサーバから受信される間のステップ1100にて始まる。次に、ストリームの関連付けられたプライオリティが、サーバが帯域幅を測定しているということを示すか否かがチェックされる(ステップ1101)。その場合、専用のバッファは最大化される(ステップ1102)。または、ストリームフロー制御を無効にすることもできる。受信ノードがプロキシであるならば(ステップ1103)、セグメントデータを転送してもよい。さもなければ、クライアントは、セグメントを保存するべきか否かを決定する(ステップ1104)。クライアントは、プッシュされたセグメントを保存する(ステップ1105)。いずれにしても、クライアントは、接続ごとのウィンドウのための肯定応答をWINDOWS(登録商標)_UPDATEの形式でサーバに対して送信する(ステップ1106)。そして、この肯定応答は、接続帯域幅を推定するためにサーバによって用いられることになる。クライアントがプロキシで有る場合、プッシュされたデータを可能な限り迅速に転送する(ステップ1108)。エンドクライアントから肯定応答を受信すると、プロキシは、同様にそれをサーバに返送する(ステップ1109および1110)。
利用可能な帯域幅を推定するために、サーバは、データフレームの送信時刻と肯定応答メッセージの受信時刻との間の差分として算出される、送信されたデータフレームのラウンドトリップ時間を用いてもよく、2者間のペアリングは、例えばウィンドウサイズ更新に等しくなるべきデータフレームサイズに基づく。ラウンドトリップ時間は、1つ以上のビデオセグメントの様々なデータフレームから算出される。正確さを増すために、データフレームは、様々なサイズを有してもよい。異なるサイズのいくつかのDATAフレームにビデオセグメントを分割することは、サーバによって実行できる。サーバは、ネットワーク層が、DATAフレームを、いくつかのTCP/IPパケット(したがって小型のDATAフレーム)に分割しない、または送信されるコンテンツをバッファリングして、いくつかのDATAフレームをTCP/IPパケットにマージしない、ということを保証することのみ必要とされる。それらの測定値に基づいて、規格技術は、どのビデオリプレゼンテーションを用いるかを実際に判断するために、サーバが用いてもよい利用可能な帯域幅を算出するために用いることができる(例は上記の文献内で見出すことができる)。
図12を参照して、初期のビデオ再生のケースを説明する。サーバは、高速起動プライオリティを用いて、データをプッシュする。データは、通常低ビットレートを有しており、クライアントは、サーバが帯域幅を推定することができ、且つ最適なリプレゼンテーションに切り替えることができるように、それらのデータを受信して肯定応答をサーバに対して送信することになる、と考えられる。クライアント側の処理はステップ1200〜1207に記載される。サーバ側の処理は、ステップ1210〜1215に記載される。
クライアント処理は、プッシュされたデータの受信のステップ1200から始まる。そして、クライアントは、プライオリティが高速起動の値を有するか否かをチェックする(ステップ1201)。その場合、クライアントは、通常は、専用のバッファを最大化する(ステップ1202)。プッシュされたデータのPUSH_PROMISEを受信すると、この最大化が実行される。そして、データが保存され(ステップ1203)、クライアントは、WINDOW UPDATEフレームを用いて、肯定応答をサーバに送信する(ステップ1204)。そして、クライアントは、ビデオを再生し始めるために十分なデータが利用可能であるか否かをチェックする(ステップ1205)。そうであるならば、ビデオ再生が始まる(ステップ1206)。そうでなければ、データを再生し始めるために十分なデータが利用可能になるまで、クライアントは、さらなるデータを待つ(ステップ1207)。
サーバ処理は、高速起動プライオリティでセグメントデータフレームを送信するステップ1211から始まる(ステップ1210)。そして、サーバは、利用可能な帯域幅を算出すること(ステップ1212)を可能にする肯定応答を受信する(ステップ1211)。一旦十分な測定値が取得されれば、サーバは、最適なリプレゼンテーションを選択し(ステップ1213)、最適なリプレゼンテーションセグメントをプッシュし始める(ステップ1214)。サーバは、リプレゼンテーションをいつ切り替えるのかを決定する。これには少なくとも2つの利点がある。第1に、クライアントが多少の遅延に対処する必要がある一方で、サーバは、いつ測定値が十分に正確になるのかを認識することができ、このケースであれば直ちに1つの解像度から別の解像度に切り替えることができる。第2に、サーバは、ユーザエクスペリエンスをあまり妨害しない時刻に1つの解像度から別の解像度に切り替えることを決定することができる。実際には、サーバは、ビデオコンテンツの認識を有する。特に、MPDは、解像度の切り換えを最良に予見することができる時刻の情報により強化されてもよい。
本発明は、強化されたストリーミング方法に関し、サーバ側において、第1のメディアデータに関連する要求がクライアント装置から受信され、要求されていなくともクライアント装置に対して送信される第2のメディアデータが識別され、そして、前記第1のメディアデータに関連する情報が前記要求に応答して前記クライアント装置に対して送信され、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージが準備される。
クライアント側において、第1のメディアデータに関連する要求は、サーバ装置に対して送信され、前記第1のメディアデータに関連する情報は、前記要求に応答して前記サーバ装置から受信される。
強化されたストリーミング方法は、いくつかのメディアデータをプッシュするサーバの判定と、このようなデータのためのクライアントのニーズとの間のミスマッチを減少させる。以下から明らかになるように、サーバおよびクライアントは、サーバおよびクライアントが両方ともクライアントによって要求されたいずれかのメディアデータからプッシュされる同じメディアデータを決定するように、プッシュポリシーを共有する。プッシュポリシーは、プッシュするデータを決定する方法を定義しており、要求されたデータが処理された(GET要求の後に)後に、要求されたデータに対してリンクされたどのリソースがプッシュされるのか、および場合によってどのようにプッシュされるか(例えば、どの順序で)を判定するための規則として理解されてもよい。通常、リンクされたリソースは、1つのドキュメント、例えば、(マルチメディアデータのためのDASHコンテキストにおける)MPDファイルなどのマニフェストファイル、またはHTMLドキュメント、を用いて決定される。
結果として、共有されたプッシュポリシーに基づいて、クライアントはサーバの挙動を予期し、サーバからの無用のメディアデータの送信を、回避する、そしてより正確にはキャンセルすることができる。クライアントとサーバとの間の通信ネットワーク内の帯域幅の使用が、このようにして減少する。さらに、HTTP要求およびPUSH_PROMISEキャンセルの数が減少し、その結果、特に低遅延のライブビデオストリーミング用のアプリケーションの待ち時間が下がる。
本発明によれば、サーバは、サーバ装置がクライアント装置に対する第2の非要求メディアデータの識別および送信を駆動するためにクライアント装置と共有されるプッシュポリシーを、用いることができる。特に、クライアント装置に対して送信される第2の非要求メディアデータサーバ装置が決定するために、クライアント装置と共有されるとともに第2のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。それに対応して、クライアント装置によって要求されていなくともサーバ装置によって送信される第2のメディアデータをクライアント装置が決定するために、クライアントは、サーバ装置と共有されるとともに第2のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。
図14aは、クライアント側における本発明の一般的なステップを、フローチャートを用いて示し、その一方で、図14bは、サーバ側における本発明の一般的なステップを、フローチャートを用いて示す。
図1dおよび図1eを参照して説明された処理との比較において、付加的なステージ1400および1402は、サーバおよびクライアントが、他方と共有されて、それにより用いられるプッシュストラテジをそれぞれ決定することを可能にする。
第1の実施形態によれば、共有されたプッシュポリシーは、共有されるプッシュポリシーが何であるのかを他方に知らせるためにクライアントおよびサーバがポリシーデータを交換しない(明示的でない)ということを意味する、暗示的なプッシュポリシーである。共有されたプッシュポリシーの暗示的アプローチの実施は、サーバ装置およびクライアント装置の両方において、「第2のメディアデータを決定するアルゴリズム」として呼ばれる同じアルゴリズムを用いることを含み、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第1のメディアデータから同じ第2のメディアデータを決定することを可能にする。
例えば、アルゴリズムは、クライアントおよびサーバのセットアップの間に、または特定の規格に関連して、予め決定される。アルゴリズムの代表例は、マニフェストファイルの構文解析順序における要求されたリソースに追続くN個のリソースのプッシュする場合であり、ここで、Nは所定数(例えば4)である。
図を参照して、ステップ1400および1402は、暗示的なプッシュポリシーのケースでは、プッシュされるリソースを識別する(サーバ側におけるステップ1403)ためにメモリ内の所定のアルゴリズムをロードすることにある。
クライアントは、例えばステップ1401において、期待されるPUSH_PROMISEの数を推定し、且つ不要なプッシュデータのためにキャンセルメッセージを準備するように決定されたプッシュポリシーを効率的に用いてもよい。
例えば、サーバ装置が対応する用意されたアナウンスメッセージを送信しないように、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバがクライアント装置から受信することになる。一方で、クライアントは、第2の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバ装置に対して送信するであろう。アナウンスメッセージがサーバ装置から送信されるか、またはクライアント装置によって受信される前に、このようなキャンセルが行われることができる、ということをわかるであろう。このアプローチは、例えば、別のバージョンのメディアに切り替えることをクライアントが決定するときに、有用かもしれない。このような状況において、前バージョンのためにプッシュされたセグメントをキャンセルすることを決定することができる。
アルゴリズムを用いてプッシュされるリソースの認識のために、クライアントは、サーバから対応するPUSH_PROMISEを待つ必要なく後続のリソースを取りだすために、サーバに対して第2の要求を並列に行うことができる、ということにも留意するべきであろう。DASHの場合には、クライアントのためのこの可能性は、第2の要求が後で受信するPUSH_PROMISEに干渉しないことを保証しながら、クライアントの待ち時間を減少させることを可能にする。
これらの他の必要とされるリソースがプッシュされようとしている、ということをアルゴリズムの結果から判定すれば、クライアントは、また、必要とする他のリソースを要求してもよい。
第2の実施形態によれば、共有されたプッシュポリシーは、全体の規則(すなわちアルゴリズムまたはアルゴリズムのパラメータ)を明確に定義するか、または両方の側で事前に定義されたプッシュポリシーを参照することによって、クライアントとサーバとの間の交換において定義される。これは、サーバのプッシュポリシーを記述するプッシュポリシー情報をサーバがまず決定することが必要となる。そして、プッシュポリシー情報は、プッシュポリシーをクライアントと共有するために、クライアントに対して送信される。それに対応して、クライアントは、それにより、共有されたプッシュポリシーを記述するプッシュポリシー情報をサーバ装置から受信する。
明示的アプローチの1つの効果は、それらの処理特性をより適切に満たすために異なるプッシュポリシーを、各クライアントまたは各マルチメディアプレゼンテーション(例えば各MPD)のためにサーバが用いることができるという事実に依存する。図15aは、明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップ1400を、フローチャートを用いて示し、その一方で、図15bは、明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップ1402を、フローチャートを用いて示す。
図15bに示されるように、サーバは、ステップ1504において、プッシュポリシーを宣言するメッセージを生成し、その後、それを共有するために、ステップ1505においてクライアントに対してそれを送信する。宣言メッセージ内のプッシュポリシーを記述する情報は、プッシュポリシー情報と称される。
以下に記載される図16〜図18は、プッシュポリシーがどのように宣言され、クライアントに対して送信されるのかについて例示的な詳細を示す。
ステップ1402において決定されるようなプッシュポリシーを用いてプッシュされるリソースは、ステップ1504において生成されるプッシュポリシー宣言メッセージ内に定義されたセレクションアルゴリズム(または第2のメディアデータを決定するアルゴリズム)により、ステップ1403において識別される。
クライアント側では、図15aに示されるように、クライアントは、同じ選択アルゴリズムを適用することによって、所定のリソース要求のためにプッシュされるリソースを、事前に識別することができる。これは、サーバによってプッシュされるデータをクライアントが予め決定することを可能にし、したがって、プッシュデータの効率的な管理と、必要であればGET要求の数の削減とを保証することを可能にする。
同じ選択アルゴリズムを適用するために、クライアントは、サーバによって適用されたプッシュポリシーを記述するプッシュポリシー情報を受信する。
様々なプッシュポリシーの宣言方法が用いられてもよい。
1つの実施形態において、プッシュポリシー宣言は、要求Rと、プッシュされるリソースを含むドキュメント(通常はDASHのためのマニフェストファイル)に対応するDOMツリーとを入力パラメータとして利用して、プッシュされるリソースの順序付きリストを出力するJava(登録商標)Scriptプログラムのおかげで共有される。この実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されるウェブページ内に埋め込まれるJava(登録商標)Scriptプログラムを含む。
他の実施形態において、プッシュポリシーは、マニフェストファイル内に記述される。それは、共有されたプッシュポリシーを用いて、サーバ装置からクライアント装置に対して送信される記述ファイル内の共有されたプッシュポリシーが挿入されることを記述するプッシュポリシー情報である。記述ファイルは、第1のメディアデータを含むメディアデータに関係し、プッシュされる第2の非要求メディアデータを決定するために両方の側によって用いられる記述情報を含む。
DASHにおいて、記述ファイルは、例えばMPDファイルである。以下の記述は、主として、DASHおよびMPDファイルに基づく。しかしながら、同じアプローチは、スムーズなストリーミングまたはHTTPライブストリーミングのような他のマニフェストベースのストリーミング方法に適用できる。
具体的な定の実施形態によれば、プッシュポリシー情報は、識別される第2の非要求メディアデータの量を定義する第1のプッシュ属性を記述ファイル内に含む。これは、1つの要求Rがクライアントから受信された後、プッシュされるセグメントの数を指定することを可能にする。
これは、サーバによって適用されるプッシュポリシーを指定するためにPushPolicyノード1600が用いられるMPDドキュメントを示す図16によって示される。
この例において、PushPolicyノード1600は、GET要求が受信された後にプッシュされるセグメントの数を宣言するために、プッシュ属性(すなわち「Segmentldx」)を含む。例えば、クライアントがそのGET要求内のセグメント1601を必要とするならば、MPDドキュメントの順序を解析する際に、次の2つのセグメントのためのPUSH_PROMISEフレームを応答として、受信することになる。この例において、第1のプッシュ属性は、記述ファイル内の要求された第1のメディアデータに対して第2の非要求メディアデータを識別する。さらに一般的には、プッシュされるK個のセグメントの所定数は、プッシュポリシー値を定義するために用いられる。結果的に、クライアントによって要求される各セグメントに対して、サーバは、Kの次のセグメントをプッシュすることになる。
図16の例1600は、単一のプッシュ属性を示すが、複数のプッシュ属性があってもよい。各プッシュ属性は、プッシュされるセグメントを選択するために、マニフェストを表現するDOM(ドキュメントオブジェクトモデル(Document Object Model))ツリーのノード上の制約を表現してもよい。図4bの先の例を参照すると、プッシュポリシーノード1600は、メディアデータが属するPeriod要素を参照する期間属性「Periodldx」と、メディアデータのAdaptationSet要素を参照するアダプテーション属性「AdaptationSetldx」と、Representation要素を参照するリプレゼンテーション属性「Representationldx」、すなわちメディアデータの符号化バージョン(特定のコーデック、解像度、またはビットレート…)と、所定のリプレゼンテーション内のセグメントを参照するセグメント属性「Segmentldx」と、を含むメディアデータ属性(MPD要素および/または属性)を用いて、記述ファイル(MPDファイル)内に記述されるメディアデータを参照することができる。
これらの既存のメディアデータ属性に基づいて、プッシュポリシー情報は、第2の非要求メディアデータを識別するために、メディアデータ属性(単数または複数)上の制約を定義する少なくとも第2のプッシュ属性を含んでもよい。
例えば、Segmentldx属性に関連する上記の第1のプッシュ属性に加えて、プッシュするセグメントを選択するための期間上の制約を指定するために、プッシュ属性は、Periodldx属性に関連付けられてもよく、別の1つは、適応上の制約を指定するためにAdaptationSetldx属性に関連付けられてもよく、別の1つは、リプレゼンテーション上の制約を指定するためにRepresentationldx属性に関連付けられてもよい。
プッシュ属性が存在しないかまたは無効のとき、関連するメディアデータ属性は、非制約として考えられねばならない。
プッシュ属性の値は、以下の構文を用いてもよい。
プッシュ属性=[オペレータ]オペランド(push attribute= [operator] operand)
ここで、「オペレータ」は、オプションであり、要求されたセグメントに対して相対的にプッシュされるセグメントを定義するために、値「+」または「−」をとり(「+」は後を意味し「−」は先を意味する)、ここで、「オペランド」は、ワイルドカードパラメータとして0または「<*>」よりも上位の整数値若しくは等しい整数値のいずれかである。
ここで、「オペレータ」は、オプションであり、要求されたセグメントに対して相対的にプッシュされるセグメントを定義するために、値「+」または「−」をとり(「+」は後を意味し「−」は先を意味する)、ここで、「オペランド」は、ワイルドカードパラメータとして0または「<*>」よりも上位の整数値若しくは等しい整数値のいずれかである。
図17は、共有されたプッシュポリシー「PushPolicy」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて示す。このフローチャートは、ステップ1403を示す。
まず、サーバは、ステップ1700において、マニフェストファイル内の要求されたセグメントを識別する。要求は、このセグメントの識別された「reqSegldx」を含む。
マニフェストファイルMPD内の各々のノード種別に対して、指標値が、各ノードに対して属性付けられる。値は、マニフェストファイル内での出現順において各々のノードごとに増加される。
次に、要求されたセグメント(すなわちGET要求において指定されたセグメント)に対応するPeriod、AdaptationSet、Representation、およびSegmentURLのインデックスは、要求されたセグメントに到達されるまで、全体のMPDを解析することによって取りだされる。
プッシュポリシー内に定義されたプッシュ属性のオペレータおよびオペランドの値は、(「+」または「−」オペレータに関連付けられている場合に、プッシュされるセグメントの量を定義するSegmentldx属性を除いて)プッシュされるセグメントがどのノード内で定義されるのかを識別するために用いられる。
オペレータが指定されない場合は、オペランド値は、プッシュされるデータを検索しなければならないNodeのインデックスを識別する。例えば、第1のプッシュ属性「Segmentldx」がオペレータを有しない場合には、それは、プッシュされる特定セグメントの、記述ファイル内部の、識別子である。1つの代替案において、オペレータが指定されないと、オペランド値は、範囲値を識別してもよく、例えば、「Segmentldx=2−5」は、2、3、4および5に等しいインデックスでセグメントを返すだろう。
そうでなければ(オペレータが指定されている)、オペランド値は、要求されたセグメント(ステップ1700において取得された「reqSegldx」)のインデックスに対して適用するために(「idxOffset」と命名される)オフセット値を表現する。そのような場合、プッシュされるセグメントは、もしオペレータが「+」ならば[reqSegldx,reqSegldx+idxOffset]範囲、そしてもしオペレータが「−」ならば[regSegldx−idxOffset,regSegldx]内に備えられたインデックスとともにノード内にあるはずである。オペレータの使用は、記述ファイル内部の第1のメディアデータの対応するメディアデータ属性(単数または複数)に対する第2の非要求メディアデータのメディアデータ属性(単数または複数)を定義することを可能にする。
例えば、以下のプッシュポリシーを考えてみよう。
1.<PushPolicy Representationldx=“−1” Segmentldx=“2”/>
2.<PushPolicy Periodldx=“+1” Segmentldx=”+2/>
3.<PushPolicy Periodldx=“+0” Segmentldx=”+2/>
PushPolicy#1は、要求されたセグメントのリプレゼンテーションノードに先行するリプレゼンテーションノード内のインデックス2のセグメントをサーバがプッシュすることになる、ということを指定する。
2.<PushPolicy Periodldx=“+1” Segmentldx=”+2/>
3.<PushPolicy Periodldx=“+0” Segmentldx=”+2/>
PushPolicy#1は、要求されたセグメントのリプレゼンテーションノードに先行するリプレゼンテーションノード内のインデックス2のセグメントをサーバがプッシュすることになる、ということを指定する。
PushPolicy#2により、サーバは、現在の期間または以降において、要求されたセグメントに続く2つのセグメントをプッシュすることになる。例えば、図24のセグメント2401を要求すると、セグメント2405および2402がプッシュされることになる。
PushPolicy#3は、PushPolicy#2に対して非常に類似し、主な差は、要求されたセグメントがPeriodの最後から2番目の時のものである。例えば、2401を要求する場合、現在の期間における最後セグメント2405のみが(2つのセグメントの代わりに)プッシュされることになる。PushPolicy#3により、Periodldxは、要求されたセグメントのPeriodノードに対してセグメント検索を制限しており、したがって、(要求されたセグメントがPeriod内の最後から2番目のセグメントであるので)Periodの最後のセグメントのみがプッシュされる。それどころか、PushPolicy#2により、セグメントは、次の期間から取りだすことができる。
代替案において、またはオプションの値として、オペランドの値は、また、あらゆるセグメントがプッシュされるべきであるということを意味する「<*>」(ワイルドカードを意味する)であってもよい。オペレータ「+」(それぞれ「−」)に関連付けられていると、それは、要求されたものに対して後続する(各々が先行する)すべてのセグメントがプッシュされるべきであるということを意味する。
この代替案は、クライアントがPushPolicy:<PushPolicy Periodldx=“+0”Segmentldx=“+<*>”>により、例えば1つのPeriodのセグメントをすべて取りだす、単一のHTTP要求のみを送信することを可能にする。
これらの例において、要求された第1のメディアデータに対する(プッシュされる)第2のメディアデータを識別するSegmentldx属性の使用は、第2のメディアデータが第1のメディアデータに隣接することを必要とする。実施形態において、Segmentldx属性は、要求されたセグメントのインデックスに適用するために(オペランドに加えて)オフセットを含んでもよい。これは、所定量のセグメントをプッシュしなければならない基準セグメントのインデックスをシフトする。例として、Segmentldx属性の構文は、次のとおりであっても良い。
プッシュ属性:[オペレータ]オペランド[,オフセット](push attribute:[operator]operand[,offset])
ここで「オフセット」は、要求されたセグメントインデックスに適応するために0とは異なる正または負の整数である。そのような場合、サーチ範囲は、オペレータが「+」であれば[reqSegldx+offset,reqSegldx+idxOffset+offset]、およびオペレータが「−」であれば[reqSegldx−idxOffset+offset,reqSegldx+offset]である。
ここで「オフセット」は、要求されたセグメントインデックスに適応するために0とは異なる正または負の整数である。そのような場合、サーチ範囲は、オペレータが「+」であれば[reqSegldx+offset,reqSegldx+idxOffset+offset]、およびオペレータが「−」であれば[reqSegldx−idxOffset+offset,reqSegldx+offset]である。
プッシュポリシーの構文は、また、プッシュされているプレゼンテーション内に最大サイズのデータまたは時間のような(非制限的な)条件をそれぞれ含むことができる。例えば、
<PushPolicy Segmentldx=’+<*>[size<500000]’>は、多くとも500キロバイトのセグメントデータをプッシュするプッシュポリシーを定義する。
<PushPolicy Segmentldx=’+<*>[size<500000]’>は、多くとも500キロバイトのセグメントデータをプッシュするプッシュポリシーを定義する。
<PushPolicy Segmentldx=’+<*>[time<0:01:30]’>は、多くとも1分30秒の次のセグメントデータを転送するプッシュポリシーを定義する。
上記の例が、どのセグメントをプッシュしなければならないのかを判定するプッシュポリシーを宣言する方法を示している一方で、セグメントがプッシュされることになる好ましい順序を指定する必要もあるかもしれない。この情報も、クライアントとサーバとの間で共有されるべきである。
例として、図7〜図12を参照して上記したプッシュされたセグメントの送信の順序の宣言を、適用することができる。
プッシュされたセグメントの送信の順序の1つの代替の実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに1つのプライオリティ属性(例えば「priorityldx」)があり、第2のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。記述ファイルの送信のおかげで、クライアントは、また、これらのプライオリティ属性によって得られた値に気づいており、したがって、意図された送信の順序を決定することができる。
図16の例に示されるように、マニフェストファイル内に記述される各セグメント(例えば、1つのSegmentURLノードによって識別される)は、セグメントのプッシュ順序を指定するpriorityldx属性(1604)を含む。図16の例において、セグメント1603は、セグメント1602の前にプッシュされる。これらのプライオリティは、サーバ側においてメディアセグメントの準備の間に算出される。異なるプライオリティ値が使用出来る:32ビット数として、Periodプライオリティのための4最上位ビット、AdaptationSetプライオリティ値のための次の4MSB、リプレゼンテーションプライオリティ値のための次の8ビット、およびセグメントプライオリティのための最下位16有効ビットをもつ(図16のような)所定のRepresentation内の相対プライオリティ値または絶対プライオリティ値のいずれかを用いることができる。絶対プライオリティ値を示す別な方法は、プライオリティ値のコンマ区切りリストを用いることであり、上記の引用されたレベルの各々の1つは、例えば、Periodプライオリティ、AdaptationSetプライオリティ、Representationプライオリティ、そしてセグメントプライオリティを連続的に定義するpriorityldx=’1,1,2,1’である。第1の実施形態は、以下の32のビット値(バイナリ型)により与えるだろう。
priorityldx=’00010001000000100000000000000001’
priorityldx値を用いる主な効果は、個別のRepresentation(通常は、ビデオの代替ビューなどの関連リプレゼンテーション)からセグメント間のプライオリティ順を定義することを可能にすることである。プッシュポリシーが個別のRepresentationセットのセグメントの送信にあると有用である。1つの層からのセグメントが1つ以上の他の層をもつセグメントによりインターリーブされる場合、通常の使用事例は、層状ビデオ(マルチビューにおけるビューである層またはスケーラブルビデオにおけるスケーラビリティ層)のストリームのためのものである。
priorityldx値を用いる主な効果は、個別のRepresentation(通常は、ビデオの代替ビューなどの関連リプレゼンテーション)からセグメント間のプライオリティ順を定義することを可能にすることである。プッシュポリシーが個別のRepresentationセットのセグメントの送信にあると有用である。1つの層からのセグメントが1つ以上の他の層をもつセグメントによりインターリーブされる場合、通常の使用事例は、層状ビデオ(マルチビューにおけるビューである層またはスケーラブルビデオにおけるスケーラビリティ層)のストリームのためのものである。
図17に戻り、サーバは、MPDファイル内に定義されるようなプッシュポリシーに基づいて、ステップ1701において、プッシュされるセグメントの数を決定する。この数は、Segmentldx属性値から直接推測される。すなわち、オペレータが属性値内で用いられなければ、この数は1に等しく、そうでなければ(オペレータは「−」または「+」である)、数は、オペランド値に等しく、オペランドが「<*>」であれば無限である(但し他の制約によって、および既存のセグメントの数によって、限定される)、と想定される。
次に、プッシュするセグメントの数がプッシュされるセグメントの各々をマークするところに達する(テスト1702)まで、ステップ1702〜1705から構成される反復処理は、ストリーミングサーバによって適用される。
各々の反復に対して、サーバは、ステップ1703において、PushPolicy制約(Adaptation Set、Representation、Period、およびSegment制約およびオプションの条件)に関する、MPDファイル内に定義されたセグメントのリストを取りだす。
各々の反復に対して、サーバは、ステップ1703において、PushPolicy制約(Adaptation Set、Representation、Period、およびSegment制約およびオプションの条件)に関する、MPDファイル内に定義されたセグメントのリストを取りだす。
セグメントのリストが空であるか、またはすべてのセグメントが既にマークされていれば(テスト1704)、処理は終了し、サーバはクライアントの要求に対して応答を送信し始める(上記のステップ102)。
そうでなければ、リストの第1のセグメントは、ステップ103(PUSH_PROMISE)および104(プロミスされたセグメント)の間にプッシュされるのと同様に、ステップ1705においてマークされる。
プッシュポリシーを宣言する、これらのMPDに基づく例において、1つのプッシュポリシーは、PushPolicy要素を用いて定義される(図16の1600を参照)。
記述ファイルが、複数のメディアデータ属性レベル(すなわち、以上で定義されたPeriod、AdaptationSet、Representation要素)を用いて、メディアデータを記述することが、ここで想起される。
上記のものに対するわずかな変形として、様々な共有されたプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義されてもよい。 これは、メディアストリームのコンテンツに対してプッシュ戦略を適応するために、関係するレベル(Adaptation Set、Representation、Period)に依存する様々なプッシュポリシーを定義することができる、ということである。
これは図23を通じて示され、ここで、Representationレベルにおいて、プッシュポリシーが、所望のレベルにて、例えば「SupplementalProperty」記述子を用いて定義される。
<MPD>レベルごとにプッシュポリシーを用いることは、メディアにわたって定数および同じプッシュ戦略を有することを可能にする。
<Period>レベルごとにプッシュポリシーを用いることは、時間に沿って変化できるプッシュ戦略を有することを可能にする。
<AdaptationSet>レベルごとにプッシュポリシーを用いることは、メディアに適したプッシュ戦略を有することを可能にする。
<Representation>レベルごとにプッシュポリシーを用いることは、メディア特性(帯域幅…)に適することができるプッシュ戦略を有することを可能にする。
図23の例において、Representationレベルにおいて指定されるプッシュポリシーは、プッシュデータとともにあまりにも多くの帯域幅を用いないようにするために、高いビットレートのビデオ(2301)よりも低ビットレートビデオセグメント(2300)のために、よりさらにセグメントをプッシュするように構成される。
プッシュ属性の構文に関しての上記の説明も、また、このわずかな変形に適用されてもよい、ということに留意されたい。特に、プッシュポリシーは、新たな要素(図16のように)としてマニフェストにおいて、または(図23のように)新たなschemeldUriにより既存の記述子を用いて、または(表現されていない)新たな記述子として、またはMPDスキーマ若しくはMPDスキーマの拡張ポイントに適合するいずれかの手段として、信号で送ることができる。
MPDは、また、各自が一意の識別子を有する、代替的なPUSHポリシーのリストを含むこともできる(以下のリストに関するさらなる説明を参照)。
他の代替の実施形態において、プッシュポリシーは、相補的なRepresentationのためのセグメントが系統的にプッシュされる、ということを、例えば以下の構文を用いて定義してもよい。
<push_policy Segments=’+complementary’>または、DASH記述子を用いる場合は、value=’complementary’
層状ビデオの場合には、これは、要求されたビデオセグメントに対して、相補的なRepresentationとして宣言されるすべてのRepresentationから同時に各セグメントも(通常は、異なるRepresentation間の依存性を信号で送るMPD内のdependencyld属性を通じて)プッシュされるだろう、ということを意味する。
層状ビデオの場合には、これは、要求されたビデオセグメントに対して、相補的なRepresentationとして宣言されるすべてのRepresentationから同時に各セグメントも(通常は、異なるRepresentation間の依存性を信号で送るMPD内のdependencyld属性を通じて)プッシュされるだろう、ということを意味する。
別のプッシュポリシーは、また、@associationld属性またはrole=’supplementary’により信号で送られる、関連するRepresentationからのセグメントのプッシュにある。
完全にサーバで駆動されるストリーミングの場合には、プッシュポリシーは、サーバ挙動が「積極的」(若しくは「楽観的」)または「保守的」でなければならないか否かの情報、すなわち、それぞれ高品質のセグメントをプッシュしようとする、または同じ品質レベル(帯域幅を維持する)でプッシュしようとするか否かの情報を提供することができるであろう。
他の実施形態において、プッシュポリシーは、専用のHTTPヘッダとして見なされる「プッシュポリシー」ヘッダ内で送信される。すなわち、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたHTTPフレームのヘッダ内に埋め込まれる。
これらの実施形態は、上記のように、それらがもはやMPDファイルの送信に依存せず、クライアントおよびサーバがHTTP/2プロトコルを用いて交換するので、プッシュポリシーを経時的に変化させることを可能にする。
図18は、HTTP「プッシュポリシー」ヘッダ(ヘッダ名「プッシュポリシー」は、単なる例である)内で送信されるプッシュポリシーでの、サーバとクライアントとの間の通信の例である。
プッシュポリシーヘッダは、プッシュ属性のリスト(プッシュされるデータ上の制約を各々定義する)を含む。特に、先に記述されたPushPolicyの構文は、HTTPヘッダ構文に書き換えられてもよい。
図18aにおいて、クライアント(矢印1800)からのMPD要求に応答してサーバは、プッシュポリシーを共有するために、送信されたMPDに伴うHTTPヘッダ内のプッシュポリシーを送信する(ステップ1801)。
例えば、プッシュポリシーは、要求されたセグメントを追従するセグメントがプッシュされることになる、ということを指定する。結果として、クライアントがセグメントデータ1.1を要求する(矢印1802)と、サーバは、セグメントデータ2.1のためのPUSH_PROMISEと(矢印1803)、そしてセグメントデータ1.1(矢印1804)のデータを送信する。
後続のセグメント要求のためにどのデータが送信されようとするのかを定義するために、任意の構文:MPD特有のものまたはDOMツリーノードトラバースに基づいたより抽象的なものを用いることができる。
動的に共有されたプッシュポリシーに専用の特定の実施形態において、クライアントは、特定のプッシュポリシーを要求してもよい。すなわち、例えば現在共有されたプッシュポリシーがそのニーズに適していなければ、共有されたプッシュポリシーを更新してもよいし、または改善してもよい。
それは、クライアント装置がHTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をサーバ装置に対して送信する、ということを意味する。それに対応して、サーバ装置は、HTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をクライアント装置から受信する。サーバ装置は、したがって、クライアント装置(例えば次の要求のための)によって要求された他のメディアデータから非要求メディアデータを決定する前に、共有されたプッシュポリシーをそれに応じて更新してもよい。
実施形態において、クライアントからのプッシュポリシー要求は、「プッシュポリシー要求」という名の(ここでの名称は単なる例である)HTTPヘッダまたは要求内で伝達される。
図18bは、クライアントが新たなプッシュポリシーを要求した場合のクライアント・サーバ間の例示的な交換を示す。
交換の始まりは、図18aと同じである。
セグメントデータ2.1を受信した後、クライアントは、例えば利用可能な帯域幅が、セグメント要求に応答してさらなるセグメントをサーバにプッシュさせるのに十分に安定しているので、現在のプッシュポリシーが修正されるべきである、ということを識別する。
結果として、クライアントは、ステップ1805において、各々の新たな要求毎に、さらなるセグメント(1の代わりに3)をプッシュするようにサーバに依頼するプッシュポリシー要求を送信する。
サーバは、ステップ1806において、OK200によりこのプッシュポリシー要求に肯定的に回答する。この肯定的な回答は、同じクライアントからいずれかの新たな要求に対するプッシュポリシー要求内に記述された新たなプッシュポリシーをサーバが用いることになる、ということを意味する。
サーバがそのプッシュポリシーを変更したくないならば、それはプッシュポリシー要求が拒否されている、ということをクライアントに通知するためのエラーコード回答を返す。
次に、クライアントが、ステップ1807において、次のセグメントデータ3.1を要求すると、サーバは、ステップ1808において、次の3つのセグメントデータ4.1、データ5.1、およびデータ6.1に対してPUSH_PROMISEにより回答する。
図21は、プッシュポリシーの共有のためにHTTP要求を用いる場合のサーバ側における処理のステップを、フローチャート用いて示し、その一方で、図22は、プッシュポリシーを共有するためにHTTP要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて示す。
図14の処理との比較において、サーバは、クライアントからのプッシュポリシー要求を取り扱い、かつまた初期のプッシュポリシーを送信してそれを更新する、新たな処理ステップ(2100〜2105)を含む。
サーバによって受信された要求がクライアントからのプッシュポリシー要求であるならば(テスト2100)、サーバは、まず、クライアントによって提案されたデータプッシュの制約を抽出するために、ステップ2101において、プッシュポリシー要求を解析する。
このステップの間、サーバは、クライアントによって要求されたプッシュポリシーに従うことを決定してもよい。そのような場合、サーバは、その内部のプッシュポリシーを更新し(ステップ2102)、提案されたプッシュポリシーを検証するために、ステップ2103において、クライアントに対してOK200の応答を送信する。
そうでなければ、サーバがプッシュポリシーを廃棄すると(例えば提案されたポリシーがリソースの観点からコストのかかりすぎる、または適用することができないので)、ステップ2102ではサーバにおいて内部プッシュポリシーを修正しない。また、エラーコードが、ステップ2103において、クライアントに対して送信される。
具体的な実施形態によれば、サーバは、クライアントの要求とは無関係に、そのプッシュポリシーをさらに更新してもよい。そのような場合、サーバは、ステップ1402の間に、プッシュポリシーを決定し、その特性(例えばクライアントおよびネットワークの特性によって実行された要求の解析による)を変更することを決定しても良いし、または、決定されたプッシュポリシーが現在のものとは異なるということを理解しても良い。このような状況において、サーバは、後者がそれにまだ気づいていなければ(テスト2104)、クライアントと新たなプッシュポリシーを共有しなければならず、その場合には、新たなプッシュポリシーは、ステップ2105において、HTTPヘッダ内で送信される。
クライアント側の対応する処理は、図22を参照して説明される。サーバ処理に関して、新たな処理ステップ(2200〜2204)は、図14の処理との比較において、プッシュポリシーメッセージを処理し、且つプッシュポリシー要求を実行するために追加される。
ステップ1400において、現在の共有されたプッシュポリシー(すなわちサーバのプッシュポリシー)を決定した後に、クライアントは、例えば、メディアストリームのセグメントを取りだすために送信するHTTP要求の数を低減するために、新たなプッシュポリシーを要望してもよい。したがって、新たなプッシュポリシーがクライアントによって要求されると(テスト2200)、クライアントは、ステップ2201において、先に記述されたような「プッシュポリシー要求」によりHTTP要求を送信する。
この要求に対する応答は、OK200の応答またはそうでなければエラーコードを返すことによって、サーバが要求を有効にするか否かをクライアントがチェックするステップ2204において処理される。
サーバがOK200の応答を返せば、ステップ1400において、決定された現在のプッシュポリシーが、要求されたポリシーと置き換えられる。そうでなければ、それはそのまま変更されない。
図14の処理に加えて、クライアントがサーバから新たなプッシュポリシーでフレームを受信すると(テスト2202)、プッシュポリシーは、ステップ1400の次のオカランスで取りだされるために解析され、メモリ内に保存される(ステップ2203)。
プッシュポリシー要求がまた他のデータ(例えばメディアデータ)も含むフレーム内にあると、他のデータが、ステップ109〜111〜113〜115を通じて処理される、ということに留意すべきである。
上記のHTTPに基づいた例は、適用されるプッシュポリシーを完全に定義するためにHTTP要求を用いるが、1つの具体的な実施形態は、クライアントとサーバ側の両方において1セットの予め定義された同じプッシュポリシーを有し、各々が一意の識別子を有することを定義することに依存してもよい。この場合、HTTP要求は、セットの中から用いられるプッシュポリシーの識別子を指定するためにのみ用いられる。この具体的な実施形態は、HTTP要求のサイズを減少させる。
1つの実施形態において、プッシュポリシー要求は、サーバリソースの1つを要求するために用いられるHTTP要求の1つの付加的なHEADERとして送信され、通常は、プッシュポリシー要求は、MPDファイルに対するGET要求における「受理プッシュポリシー」HTTPヘッダ内で送信される。
別の実施形態において、クライアントは、クライアントによって支持される(または必要とされる)プッシュポリシーのリストを示すために1つのHTTP要求においていくつかの「Accept−Push−Policy」を指定する。HTTP要求に応答して、サーバは、提案されたリスト内のプッシュポリシーの1つを選択し、そして、HTTP応答内のプッシュポリシーを指定してもよいし、または、どれもサッポートされなければ、新たなプッシュポリシーによって応答してもよい。
さらに別の実施形態において、プッシュポリシー要求は、サーバによって認識されるあらゆるリソースの独立した専用のHTTP要求において送信される。例えば、GET(またはPOST)要求は、ウェブページのリソースのどれにも対応しないURL、例えばhttp://server/push_policyと、さらに少なくとも1つのAccept−Push−Policyヘッダとにより形成される。
さらに別の具体的な実施形態において、代替的なプッシュポリシーのセットは、各々が一意の識別子を有する、サーバとクライアントとの間で交換されたMPDファイル内で定義されてもよい。プッシュポリシーの1つは、サーバによって選択されるデフォルトプッシュポリシーとしてマークされてもよい。クライアントは、デフォルトプッシュポリシーの交換に用いられるプッシュポリシーの識別子を含む新たなプッシュポリシー要求を送信することによって、どのプッシュポリシーが用いられるべきであるのかを指定してもよい。
1つの実施形態において、特定のプッシュポリシーは、高速起動のためにMPDドキュメントに対する要求直後に、どのセグメントがプッシュされるのかを示すために定義される。
ハイブリッドアプローチにおいて、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第1のプッシュポリシー部および第2のプッシュポリシー部によって定義され、第1のプッシュポリシー部は、記述ファイル(MPD)内に挿入され、第2のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるHTTPフレームのヘッダ内に埋め込まれる。
例えば、MPDは、プッシュポリシーHTTP要求のおかげでサーバによってその後定義される(またはさらにオーバーロードされる)テンプレート引数によりプッシュポリシーを定義してもよい。例として、MPDファイル内に定義されたプッシュポリシーは、<PushPolicy Segmentldx=”parameter7>であってもよく、変数「パラメータ」の値は、プッシュポリシーHTTP要求において定義されてもよい。この例において、第2のプッシュポリシー部は、第1のプッシュポリシー部内に定義された1つ以上の関連変数に対する1つ以上の値(のみ)を有する。
上記のプッシュポリシー識別子ベースのアプローチを用いて、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第2のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第1のプッシュポリシー部を形成する。
クライアントに対してプッシュポリシーを宣言するための別の実施形態において、プッシュポリシーは、プッシュデータが選択されることになるリプレゼンテーションを示すMPD内に定義された〈Role〉記述子に依存する。通常は、プッシュポリシーは、プッシュ戦略が「代替」または「追加」のロール値をもつRepresentation内のセグメントを用いることになる、ということを指定してもよい。
別の実施形態において、例えばストリーミングマニフェスト、HTMLページなどのリソースのドキュメントは、GET要求が受信された後にプッシュされるリソースを決定するために閲覧されるプライオリティツリーに変換される。プライオリティツリー内部のナビゲーションは、XPath要求のおかげで実行することができる。このアプローチにおいて、プッシュポリシー情報は、第2の非要求メディアデータを識別するリソースのドキュメントのツリー表現上で評価される、XPath式を含む。
例えば、ストリーミングマニフェストにおいて、「following[name()=“SegmentURL”][2]」のXPath式は、プッシュされるセグメントとして、GET要求内のクライアントによって要求されたセグメントに続く2つのセグメントを選択するために用いることができる。また、チャプターを切り替える使用事例に関して、「((following[name()=“Period”]//SegmentURL)[2])」のXPath式は、各チャプターの最初の2つのセグメントを予めローディングするために後続のPeriodの最初の2つのセグメントを選択することを可能にする。例えば、クライアントが図24のMPDファイル内のセグメント2401を要求すると、後続のPeriodのセグメント2402および2403も、プッシュされたデータとしてサーバによって送信される。
さらに、高度なプッシュポリシールールのために書くXPath式を単純化するために、例えばXSLT命令を用いて、プライオリティツリーをまず再順序付けることができるかもしれない。XSLT命令は、プッシュポリシーを適用する前にツリーを再編成することを可能にする。XPath式は、好ましくは、クライアントに対して、例えば1つのHTTPヘッダ内で送信され、XSLTスタイルシートは、ウェブページ内で定義される。これは、例えばドキュメント内の宣言するすべての画像、DOMツリーの同じレベルにおける連続するノードのようなすべてのCSSリソース、をグループ化するために、特にHTMLドキュメントに適用する。
例えば、図25のツリー2501は異なるタイプの異なるリソースも持つHTTP頁を表し、ハッシュされたノード(2511〜2514)は、画像リソースに対応し、単色のノード(2521−2524)は、スクリプトリソース(CSSまたはJava(登録商標)script)である。ツリー2502は、タイプによってリソースをグループ化するXSLT変換結果の例である(2530における画像および2540におけるスクリプトリソース)。簡単なXPath式は、したがって、一旦この所定のタイプの第1のリソースが要求されれば、所定のタイプのためのいくつかのリソースがプッシュされることになる、ということを示すために、定義することができるかもしれない。
以上に記述されたすべての実施形態において、いくつかのセグメントがプッシュされることをプッシュポリシーが要求するならば、各々のクライアントに対していくつかのPUSH_PROMISEでのサーバ返信を要求する、という可能性が非常に高い。
例えば、図19のMPD1900は、要求されたセグメントに追従する3つのセグメントがプッシュされることになるということを示すプッシュポリシーを有する(<PushPolicy>要素を参照)。従って、クライアントが0〜999に等しいバイト単位の範囲でメディア1901に対するGET要求によりイニシャライゼーションセグメントを要求すれば、サーバは、ステップ103の間に、3つのPUSH_PROMISEメッセージに1902を送信することになる。
1つの実施形態において、識別された第2のメディアデータの各々がアナウンスメッセージ(すなわちPUSH_PROMISE)を要求する複数のメディアセグメントを備える場合、対応する複数のアナウンスメッセージは、クライアント装置に対して送信される単一のアナウンスメッセージにマージされてもよい。
図20に示されるように、この状況を実現するために、サーバにおける処理は、好ましくは、図14の一般的な処理と比較して、ステップ103においてプッシュプロミスを送信する直前に前処理ステップ2000を含む。前処理ステップは、アナウンスメッセージの上記のマージを実行しようと努める。
プッシュプロミスが1902のようにバイト単位の範囲の要求を含むと、プッシュプロミスのリスト1902は、連続するバイト単位の範囲のアドレスを含むプッシュプロミス1903の減少されたセットを生成するために閲覧される。次に、プッシュプロミス1902の各セットは、プッシュプロミスセット内のバイト単位の範囲の連結に等しい連続したバイト単位の範囲でプッシュプロミスの減少されたセットと、または例えば1905の不連続のバイト単位の範囲のリストでの単一のプッシュプロミスと置き換えられる。
例えば、3つのプッシュプロミス1902は、図19に示される単一のプッシュプロミス1903と置き換えられる。
プッシュプロミスをマージするこのアプローチは、クライアントがより簡単な方法で、およびより低い帯域幅および処理コストで、プッシュデータの送信をキャンセルすることを可能にする。これは、マージされていない各々のプッシュプロミスの幾つかのストリームを閉じる代わりに、クライアントが単一のプッシュプロミスのための単一のストリームを閉じるだけで良いからである。
代替案において、プッシュプロミスが別々なバイト単位の範囲の間隔を有したとしても、プッシュプロミスは、すべて、バイト単位の範囲のリストと置き換えられてもよい(ここで連続するバイト単位の範囲の間隔は連鎖される)。
さらに、プッシュプロミスがバイト単位の範囲の間隔ではなく、異なるSegmentURL値を含む場合、プッシュプロミスも、また、以下の通り単一のプッシュプロミスメッセージを生成するために連鎖されてもよく、生成されたプッシュプロミスメッセージの方法はMGET(複数のGETのための)として定義される。また、パスフィールドは、1904に表現されるようなセグメントURLのリストである。 先の実施形態と同様に、クライアントは、すべてのセグメントのプッシュをキャンセルするために生成されたプッシュプロミスに対応する単一のストリームを閉じなければならない。
クライアントが各プッシュされたセグメントを解析し識別することができることを保証するために、サーバは、その後に送信されるデータ内の各々のセグメントの端部においてEND SEGMENTフラグを含んでもよい、ということに留意されたい。
さらに、HTTP/2のSETTINGSフレームは、プッシュプロミスのグループ化がストリーミングセッションのために許可されるか否かを示すことを可能にする、新たなSETTINGS_ENABLE_GROUP_PUSH_PROMISEパラメータを含むために拡張される。
本発明の実施形態は、1回または複数回のラウンドトリップを回避することができるので、DASH高速起動を有することを可能することができる。ここで、図26〜図28を参照して、本発明のこの態様を、説明する。
DASH高速起動機能は、図7〜図12および図14〜図25のすべてまたは一部を参照して、上記された何れの通信アプローチとともに用いられてもよい。
図26は、DASH高速起動を取得するために、本発明の教示によるサーバによって、およびクライアント装置によって、それぞれ実施される例示的な方法を示す。
まさに記載された標準プロセスに関して、第1のステップは、クライアントが記述ファイル、ここではMPDファイル、を要求するためにある(ステップ2650)。そして、クライアントは、サーバの応答を待つ(ステップ2651)。
その間に、サーバは、以下に説明されるように、特にクライアントがより高速に開始するのを支援するイニシャライゼーションデータを識別するために(ステップ2653)MPDファイルを解析する(ステップ2652)。ステップ2653の例示的な実施形態は、図27を参照して、以下に説明する。
一旦イニシャライゼーションデータがサーバによって識別されれば、クライアントの要求を待たずに、イニシャライゼーションデータをプッシュするその意図を示すために、ステップ2654において、クライアントに対してPUSH_PROMISEフレームを送信する。
場合によっては、それは、また、クライアントが関係するリソース、すなわち、:scheme、:host、および:pathなどの関係する初期のメディアデータ、を識別することを可能にするヘッダ部を含む別のPUSH_PROMISEフレームを送信することによって、初期のメディアデータ(ステップ2656)をプッシュすることになる、ということをさらに示す。
イニシャライゼーションデータのためのPUSH_PROMISEフレーム、および初期のメディアデータのためのPUSH_PROMISEフレームの場合、他のヘッダ部も、また、プッシュすることを決定したデータにおいてサーバがどれほど確信しているのかを示すために、サーバによって追加され、本実施形態において、confidence_levelパラメータはPUSH_PROMISEフレームに関連付けられる(すなわち、ヘッダ内に含まれる)。図27を参照して、confidence_levelパラメータの決定を以下に説明する。サーバは、また、プッシュするつもりのセグメントを明白に示すために特定のDASHヘッダを挿入することができる。
プッシュされるべきイニシャライゼーションデータおよび第1のメディアデータのためにクライアントが要求することのリスクを最小化するために、PUSH_PROMISEフレームは、応答において、いずれかのコンテンツに先立って送信されるべきである。すなわち、ステップ2654およびステップ2656は、サーバからクライアント装置までMPDファイルを送信するステップ2655の前に行われるべきである。
したがって、PUSH_PROMISEフレームがクライアント装置に対して送信されると、サーバは、ステップ2655において、クライアント装置に対してMPDファイルを送信する。
その間にサーバがクライアント装置からCANCELまたはERRORのメッセージを受信していなければ、イニシャライゼーションデータ(ステップ2657)および第1のメディアデータ(ステップ2658)をプッシュし始める。
PUSH_PROMISEフレームおよびサーバからクライアント装置へのデータのプッシュは、例えばドキュメント「ハイパーテキスト転送プロトコルバージョン2.0(Hypertext Transfer Protocol version 2.0)、draft−ietf−httpbis−http2−latesf、HTTPbis作業部会、インターネットドラフト、2013年6月24日(例えばhttp://http2.github.io/http2−spec/において利用可能)内に記述されるような、例えばHTTP2.0のフレームにおいて展開される、対応する機能にしたがって実行される。
クライアント装置が受信すると、イニシャライゼーションデータは、復号器を設定する(ステップ2659)ためにクライアントによって用いることができ、画面停止なしで十分なデータ量が復号化およびレンダリング(例えば、表示)のために利用可能になるまで、第1のメディアデータは、バッファリングされる(ステップ2660)。
クライアントがMPDファイルを完全に受信し、完全にデータをバッファリングすると(ステップ2661)、それを解析して(ステップ2662)復号化し表示し始め(ステップ2663)。そうでない場合は、クライアント装置が、さらなるセグメントが送信されることを、サーバによって送信されたPUSH_PROMISEフレーム(ステップ2656を参照)から認識するならば、ステップ2664において、サーバからの第1のメディアデータのプッシュの完了を待つ。このアイドルステップ2664の間、クライアント装置は、既に上で説明されたように、標準的なクライアント制御のDASH(ステップ2665)において発行される後続のセグメントのために次の要求を準備してもよい。対応するPUSH_PROMISEフレーム(上記ステップ2656を参照)内のプッシュされる(またはプッシュされている)初期のメディアデータの受信情報をクライアント装置が有するので、これは可能であり、したがって、サーバによってプッシュされると意図された最後の時間セグメントを直後に続く時間セグメントのための要求を準備することができる。
クライアント装置は、MPDを全て受信すると、この初期のメディアデータがバッファを満たすか否かをチェックするために、そうでなければ、ステップ2661の前の標準的なクライアント制御のDASH処理にしたがって後続のメディアデータ(例えば初期のメディアデータによって表現される時間セグメントに続く時間セグメントに対応するメディアデータ)に対する要求を送信するために、ステップ2656において受信された初期のメディアデータの情報を用いてもよい(プッシュされた初期のメディアデータがバッファを満たすケースを示す図26に示されるものとは逆に)。これは、クライアントが、プッシュする大量の第1のメディアデータの上のサーバから不良な推定を訂正することを可能にする。
この処理は、ストリーミングクライアントが、標準的マニフェストベースのストリーミングよりも早くメディアを表示し始めることを可能にする。実際は、ネットワーク上のHTTPラウンドトリップの数がイニシャライゼーションデータおよび/または初期のメディアデータを得るために減少されるので、起動遅延は減少する。
但し、この処理は、以下の理由から、現在のDASH規格に準拠したままである。
・MPDファイルの修正がない。その送信は軽量で高速のままである。
・標準DASHクライアントの挙動は不変のままである(すなわち、本発明の教示から恩恵を受けない)。このようなクライアント装置は、認識されないHTTPヘッダを無視するだろう。そして、プッシュ機能を受け入れなければ、さらなる要求/応答を単純に実行しなければならないだろう。したがって、表示を開始するために多くの時間を費やすだろう。
図27は、クライアント装置からのマニフェスト(または記述ファイル)に対する要求に追従するサーバ側において実施される例示的な方法説明する。
この方法は、クライアントがメディアプレゼンテーションの表示を急速に開始することができるように、予めプッシュする最も関連する初期データを識別しようと努める。
ステップ2700において、マニフェストに対する要求が受信される。そして、サーバは、クライアント装置が要求内にいくつかのプレファレンスを挿入したか否かを、ステップ2701において、チェックする。例えばメディアプレゼンテーションのための送信速度およびオーディオストリームのための好適な言語を表現するためになど、これは、以下の専用のHTTPヘッダなどを介して行われてもよい。
GET http://myserver.com/presentation/pres1.mpd \r\n
Prefered−MediaRange: bw=2000:lang=FR\r\n\r\n
要求がプレファレンスを含むならば(テスト2701で真)、サーバは、クライアントのプレファレンスを解析し(ステップ2703)、そのconfidence_levelパラメータを値「高」に設定する(ステップ2704)。
Prefered−MediaRange: bw=2000:lang=FR\r\n\r\n
要求がプレファレンスを含むならば(テスト2701で真)、サーバは、クライアントのプレファレンスを解析し(ステップ2703)、そのconfidence_levelパラメータを値「高」に設定する(ステップ2704)。
表示が要求において提供されないならば(テスト2701で偽)、サーバは、このクライアントのサービス利用情報(ログ)(すなわちユーザまたはクライアント装置とサーバとの間の従来の交換に基づく統計値または使用データ)またはUser−Agentヘッダからの情報を既に示しているか否かを、ステップ2702において。チェックする。実際は、User−Agentヘッダは、RFC2616(例えばhttp://www.ietf.org/rfc/rfc2616.txtを参照)内のHTTPヘッダとして定義され、例えばオペレーティングシステム、ブラウザタイプ、アプリケーション名などの情報を交換するアプリケーションのための手段を提供する。例えば、DASHサーバは、サービスを用いることができるようになる前にクライアントに対する認証スキームを有してもよく、変形物において、それは、サービスに対してアクセスする前にロギングするユーザであり得る。このような手段により、サーバは、メディアパラメータを、接続されたユーザまたは装置に対してリンクすることができる。
前の利用情報(ログ)が、関係するクライアント装置またはユーザが利用可能であると(テスト2702で真)、ステップ2705においてログを解析することによって、サーバは、所定のクライアントまたはユーザにとっての最も頻度の高い利用方法を推定することができる。例えば、ユーザまたはクライアント装置がHD(高解像度)のフランス語によるオーディオストリームおよびビデオストリームを常に選択する、ということを推定することができる。さらに、サーバは、これがオープンTCP接続における第1の要求であるか否か(サービスに対して接続され、且つ第2のメディアプレゼンテーションを要求するクライアント)を知ることができる。この場合、帯域幅推定は、さらに正確で且つさらに確実になり得るし、TCP輻輳ウィンドウは、第1の要求に対するものよりも大きくなるであろう。これは、適したRepresentationの観点から、サーバによって行われる選択に影響を与えることができる。
DASH品質メトリックを登録することによって、サーバは、そのログ内にユーザ/クライアントが通常実行する様々なリプレゼンテーションの中の変更を持つことができる。このことから、サーバは、通常の挙動を、「積極的(aggressive)」または変更の頻度に依存する定数(constant depending on the frequency of changes)の間で決定する(いかなる基準:帯域幅、解像度、フレームレート等でも、変更によって、我々は他のRepresentationに切り換えることを意味する。)。積極的なクライアント(aggressive client)は、そのコンテキストが変化すると、異なるリプレゼンテーションに自動的に切り替えるDASHクライアントである。例として、帯域幅またはバッファ占有期間を監視すると、積極的なクライアントは、現在のRepresentationと比較して、新たなRepresentationがクライアントのコンテキストに近い特性を有すると直ちに、異なる帯域幅でRepresentationを要求することになる。反対に、一定のクライアントは、安定した品質および表示速度を維持するために、頻繁なRepresentationの切り換えを回避しようとするだろう。ユーザ/クライアント装置挙動が適応の観点からいくぶん積極的であると、サーバは、それがストリーミングを開始するために初期のリプレゼンテーションとして何を選択ようとも、クライアントは、続く最初の数秒または数分間のストリーミングにおいて適応しようとする、ということを知る。
プレファレンスがログから推定されると、サーバは、ステップ2706において、そのconfidence_levelパラメータを値「中」に設定する。実際は、この情報は、クライアントそれ自体によって信号で送る明示的なプレファレンスよりも関連性が低いかもしれない(テスト2701で真)。
利用可能なログ情報がない場合(テスト2702で偽)、サーバは、その時、ステップ2707において、そのconfidence_levelパラメータを最低値「低」にする。これは、決定するべき演繹的な情報がないので、サーバが、プッシュする情報上でベストの推測を実行していることを示す。この場合のさらなる処理を、以下に説明する記載する(ステップ2711を参照)。
このconfidence_levelパラメータ計算と並行して、サーバは、ステップ2708において、マニフェストを解析してもよい。マニフェストが頻繁に変更しがちではない(ライブサービスとは逆に、特にオンデマンドのサービスに対して)場合において、マニフェストの解析は、ルックアップテーブル内の様々なRepresentationの記述を登録することによって、今回限りで、オフラインで実行することができる。このルックアップテーブルは、また、クライアントのログをメディアプレゼンテーションのいくつかの部分に対してリンクするために、サーバによって用いられてもよい。これによって、いくつかのクライアントのプレファレンスを推定するために、より高速のログ処理(上記のステップ2705を参照)を行うことが出来る。
マニフェストの解析(ステップ2708)は、ストリーミングを開始するために初期のRepresentation(すなわち初期のメディアデータ)として適したRepresentationを(ステップ2709において)選択するときに、サーバに対して情報を提供する。
(要求においてプレファレンスをそれぞれ取得する、または、先の交換からの使用データに基づく)両方のステップ2703および2705は、クライアント装置/ユーザからプレファレンスまたは利用をMPD属性と一致する具体的なパラメータ内に変換することにある。例えば、それは、帯域幅、ビデオの幅および高さ、使用中のコーデックの種類、字幕のための言語、またはオーディオストリームであり得る。そして、これらのパラメータのために取得された値から、サーバは、クライアントに対してプッシュするべき最も都合のよいRepresentationを、ステップ2709において識別するために、マニフェスト内の値と比較する。
このステップ2709は、通常は、クライアント装置がDASHのような動的および適応型ストリーミングプロトコルで継続的に実行するものである、ということに留意されたい。ここで、同じステップは、MPD構文解析手段により、ストリーミングセッションの先頭において、サーバによって実行される。
適したRepresentationを2709において推定することができない場合、テスト2710は偽であり、サーバは、そのconfidence_levelパラメータを(前述のステップ2707において)「低」値にする。
confidence_valueパラメータが「低」値を有する場合(プレファレンスを決定することができなかったので、または適したRepresentationがプレファレンスに基づいて見つからないので)、サーバは、最も簡単なRepresentationを選択することをステップ2711において判断する。ビデオに関して、例えば、最も簡単なRepresentationは、最低の空間解像度によるRepresentationであってもよいし、最低の帯域幅用に設計されてもよい。
(図27には表現されない)可能な補完的な特徴によれば、コーデック上にアンビギュイティがない場合(すなわち、ビデオRepresentationは、すべてコーデック属性と同じ値を有し、すなわち、同じコーデック、例えばHEVCは、ビデオRepresentationをすべて符号化するために用いられている)、confidence_levelパラメータは、値「中」に引き上げられてもよい。
ステップ2711の次のステップは、または適したRepresentationが見出された場合(テスト2710で真)は、イニシャライゼーションデータを識別することにある(ステップ2712)。実際に、DASHマニフェスト(または記述ファイル)において、イニシャライゼーション情報は、異なる方法で、信号で送ることができ、それは、イニシャライゼーションデータに対して直接的なURLを提供するSegmentBase、SegmentListまたはSegmentTemplate要素のイニシャライゼーション要素内に明示的に加えることができる。
この場合、このURLは、(変数:scheme、:host、:path、および最終的に:Rangeを指定することによって)プッシュされることをプロミスされたリソースをクライアントが識別することを可能にするPUSH_PROMISEフレームのヘッダ部内に加えられる(図26を参照しながら上記されたステップ2654を参照)。
イニシャライゼーションデータが明示的に記述されない場合、これは、メディアセグメントがセルフイニシャライズされる、ということを意味する。そのような場合、サーバは、セグメントの最初(例えばmp4形式のセグメントのためのセグメントインデックス情報ボックス)を解析しなければならない。この解析に基づいて、PUSH_PROMISEフレーム内にヘッダとして加えられる対応するURLを適切なバイト単位の範囲で構築することができる。
一旦識別されれば、イニシャライゼーションデータのためのPUSH_PROMISEフレームは、クライアントに対して直ちに送信され(図26におけるステップ2654に対応するステップ2713)、その直後にイニシャライゼーションデータのプッシュにより送信される(図26におけるステップ2657に対応するステップ2717a)。イニシャライゼーションデータが受信されると、クライアントは、その後、そのメディア復号器をイニシャライズすることができる(ステップ2717b)。
随意に、PUSH_PROMISEフレームを処理するときにクライアント装置によってセグメント信号送信およびその後の識別を向上させるために(以下に記載のステップ2806を参照)、サーバは、ステップ2713において、プッシュされたデータの性質と、イニシャライゼーションまたはメディア若しくは両方(自分でイニシャライズするセグメントの場合)と、URLテンプレートのパラメータまたは図5bのMPDリプレゼンテーションツリーにおけるパスのようなセグメントの表示(例えば:P2AS21R211S1、すなわち、識別子に続く要素型の連結)を示すことができる。これは、MPDを受信するようにクライアント装置に要求する、ということに留意されたい。そして、サーバは、クライアント装置によってMPD受信の後に処理されることになると考えるPUSH_PROMISEメッセージ内にのみ、この特定情報を追加することを決定することができる。MPDの受信および解析の前にPUSH_PROMISEを受け入れるかまたは受け入れないかをクライアント装置で決定することを支援するために、サーバは、MPD内のセグメントパスの代わりに、プッシュされたセグメントの定性的情報(例えばそれがベース層またはエンハンスメント層からのセグメントであるか否かなど)を示すことができ、また、別の例によれば、サーバは、それらの値で選択されたRepresentationの属性をヘッダ内に配置することができる。
(図27には表現されない)可能な実施形態によれば、ステップ2708においてマニフェストの解析が、イニシャライゼーションデータがマニフェストのトップレベル要素内にあることを判定するときに、(すなわち、例えば依存するRepresentationの場合には、いかなるRepresentationでも、イニシャライゼーションデータは、すべてのリプレゼンテーションに共通である)、サーバは、プッシュされたデータとクライアントが選択したであろうものとの間のミスマッチのリスクがないので、「高」値に設定されたconfidence_levelパラメータセットによりイニシャライゼーションデータを指定するPUSH_PROMISEフレームを直ちに(すなわちステップ2708と同時に)送信することができる。例えばHTTPヘッダとしてPUSH_PROMISEフレームとともにconfidence_levelパラメータを送信する利点は、プッシュプロミスを受け入れるかまたはキャンセルする際に、それがクライアント装置を支援することができるということである(以下に説明する図28の記述を参照)。
この機能のおかげで、クライアントは、(PUSH_PROMISEフレームが初期に送信されるので)その復号器を設定するのに必要なイニシャライゼーションデータを一層早く受信することになる。イニシャライゼーションデータが所定のメディアタイプごとにユニークであるときに(例えば、このAdaptationSet内のリプレゼンテーションの数はいくつであってもAdaptationSet当たり1つの単一のInitializationSegmentである)、これもまた動作する。この一層高速のプッシュは、マニフェストの解析(上記のステップ2708)の直後に行われることになり、従ってログまたはプレファレンスを処理する(上記のステップ2701、2703、および2705)前に行われる。
そして、先にサーバによって決定されたconfidence_levelパラメータが、値「中」以上であれば(テスト2714)、サーバは、クライアントのために適しているものとして考えられる第1のメディアデータをプッシュするイニシアチブをとる。
これは、2つステップにおいて反復して行われ、最初にPUSH_PROMISEフレームが送信され(図26のステップ2656に対応するステップ2715)、そして、第1のメディアデータのプッシュがステップ2719において開始する。これは、ステップ2709においてプッシュされるように選択された各第1のメディアデータセグメントに対して繰り返される。
可能な実施形態によれば、連続するメディアセグメントがプッシュされることがプロミスされるときに(すなわち、複数のPUSH_PROMISEがそれぞれのメディアセグメントのために送信される)、現在のメディアセグメントに関連付けられたPUSH_PROMISEは、先のPUSH_PROMISEのチャイルドまたはフォロアとしてマークされる(ステップ2716)。サーバがステートレスである場合、これは、PUSH_PROMISEフレーム内に新たなHTTPヘッダとして加えることができ、また、サーバがステートフルである場合テーブル内に保持されることができる。この関連性の保持は、プッシュプロミスに対して階層的なキャンセルを実行するのに有用かもしれない(図28を参照して以下で説明するように)。
データの様々な送信が可能なスケジュールは、以下の通りである。すなわち、実際に第1のメディアデータをプッシュする前に、サーバは上記のステップ2717aにおいてイニシャライゼーションデータをプッシュし始める。第1のメディアデータおよびイニシャライゼーションデータに関連するPUSH_PROMISEフレームの送信と並行して、サーバは、また、ステップ2718において、MPDファイル(マニフェスト)を送信し、プッシュされたデータが完全に送信されるまで、ストリームのオープンを保持する。
別の実施形態において、テスト2714は、いかなる信頼度であっても、第1のメディアデータをプッシュするために回避されることができる。 但し、confidence_levelパラメータが「低」に設定されている場合、サーバは、第1の(または初期の)メディアデータを実際にプッシュする前に、クライアントからの可能性のあるCANCELを待ってもよい。
第1のメディアデータをプッシュすると、サーバは、プッシュするデータの全体的な量を決定し、使用する速度を決定する(フロー制御)。
第1の態様に関して、サーバは、例えばマニフェストの先頭における前述のminBufferTime属性などのマニフェストからの情報を活用することができる。この属性を用い、ステップ2709または2711において選択されたRepresentation考慮し、所定のセグメント期間属性がマニフェスト内にあるとすると、サーバは、minBufferTime制約を実現するためにプッシュするセグメントの数(すなわち、セグメントの量、したがってプッシュされる初期のメディアデータを形成するデータの量)を容易に決定できる。有なことに、マニフェストの解析をオフラインで実行する場合(ステップ2708)、第1のメディアセグメントのこの数を、サーバのメモリ内のテーブル内に記録することができる。
第2の態様に関して、セグメントの期間および選択されたRepresentationの帯域幅を与えられると、必要なビットレートの推定は、サーバによって取得されるであろう。これは、主としてビデオセグメントのために、用いる送信速度を提供する。例えば、5秒の期間のセグメントを有する、1.6メガビット/秒に等しい帯域幅により圧縮されたビデオリプレゼンテーションに対して、各セグメントは、送信する1メガバイトのデータを表現するだろう。デフォルトでは、HTTPv2.0におけるフロー制御は、65535バイトにほぼ等しいストリームウィンドウサイズを提供する。したがって、我々の例において、これは、プッシュされた65536バイトの各パケットに対して、クライアントは、サーバに戻す肯定応答を送信しなければならず、そのため、我々の例においては、1セグメント当たり15回を超える!ということを意味する。開発中のHTTP2.0下でプッシュ機能を用いる場合にネットワークラウンドトリップおよびトラフィックを減少させることを目指すので、我々は、(ネットワークトラフィックを減少させることによって)DASH高速起動を可能にするためにデフォルト挙動(実際にはデフォルトの輻輳ウィンドウサイズ)を改善する必要がここにある、ということを明確に認識する。
クライアント装置が、マニフェストに対する要求内に含まれたプレファレンスを送信する場合、要求の直後にSETTINGSフレームが送信されるべきである、ということを、また、示すことができ、このSETTINGSフレームは、そのバッファリング容量にしたがって、例えば初期ウィンドウサイズ(SETTINGS_INITIAL_WINDOW_SIZE)を指定する。可能な変形物によれば、このSETTINGSフレームは、接続設定時間に送信することができる。別な可能性は、クライアント装置が、第1のプッシュデータを通知する場合に適切なサイズのWINDOW_UPDATEを送信することである。
図28は、本発明の教示による、例えば図27に記載されたような方法を実行するサーバとデータを交換する場合に、クライアント装置によって実施される可能な方法を記述する。
この方法の可能なアプリケーションによれば、クライアント装置は、ビデオ・オン・デマンドサービスから恩恵を得るために、サーバに対して接続する。クライアントとサーバとの間の接続確立は、従来のものである。本例において、クライアント装置およびサーバの両方は、例えば既に前述したドキュメント「ハイパーテキスト転送プロトコルバージョン2.0(Hypertext Transfer Protocol version2.0)、draft−ietf−httpbis−http2−latesf」に記述されたHTTP/2.0プロトコルを用いてメッセージを交換することができる。
ある時に(例えばクライアント装置におけるユーザが所定のビデオを選択するときに)、クライアント装置は、メディアプレゼンテーション(ここではユーザが見たいビデオ)を記述するマニフェストのアドレス(例えばURL)上のサーバから情報を得る。
そして、クライアント装置は、マニフェストをダウンロードする要求を準備する(ステップ2800)。好ましい実施形態において、クライアントは、HTTPヘッダを通じてビデオ解像度、コーデック、それを支援する帯域幅に、いくつかのプレファレンスを追加する(ステップ2801)。そして、クライアント装置は、サーバに対してその要求を送信する(ステップ2802)。
本実施形態において、クライアント装置は、そして、そのバッファリング容量に従って初期ウィンドウサイズ(SETTINGS_INITIAL_WINDOW_SIZE)を示すために、ステップ2803において、HTTP/2.0 SETTINGSフレームを送信する(上記のドキュメント「ハイパーテキスト転送プロトコルバージョン2.0(Hypertext Transfer Protocol version 2.0)、draft−ietf−httpbis−http2−latesf」のセクション3.8.5を参照)。
ステップ2804において、クライアント装置は、様々なサーバ応答を処理し始める。すなわち、マニフェストを形成するデータを受信し、そのマニフェストを解析する(ステップ2805)だけでなく、サーバによって送信されるPUSH_PROMISEフレームも受信し、解析する(ステップ2806)。
PUSH_PROMISEフレーム(単数または複数)内の指定されたプッシュ(単数または複数)を受け入れるかキャンセルするかを決定する前に、クライアントは、サーバがプッシュするように意図するリソースのURLを構築し(ステップ2806)、サーバによってPUSH_PROMISEフレーム内に含まれているconfidence_levelパラメータをチェックする(ステップ2807)。
並行して、そしてマニュフェスト(記述ファイル)が完全に受信されると、クライアント装置は、入手したい所望のメディアセグメントのリスト(すなわちそのニーズに最良に適する各セグメントのバージョンのリスト)を構築し(ステップ2808)、現在のsegment_index変数を0にイニシャライズする(ステップ2809)。PUSH_PROMISEの処理において第1のステップは、confidence_levelパラメータをチェックすることにある(ステップ2810a)。そして、例えば(事前に定義された)クライアントセッティングまたはユーザのプレファレンスに依存して、クライアントは、例えば、PUSH_PROMISEフレームが「低」値のconfidence_levelパラメータを含むPUSH_PROMISEなどの、一定レベルの信頼度下のPUSH_PROMISEを拒否することを決定することができる。
クライアントが(前述のステップ2808においてマニフェストから導き出されたような)所望のセグメントのURLとPUSH_PROMISEフレーム内の前述のURLとをマッチさせることができる(ステップ2810b)ならば、それらの送信状態により送信されている保留中のセグメントのリストのためのテーブルをイニシャライズする(ステップ2811)。ステップ2810bにおいて、所望のメディアセグメントのリスト内のサーバによってプッシュされるように意図されたセグメントをクライアントが識別することができなければ、サーバに対して適切なCANCEL命令を送信することによってプッシュをキャンセルする(ステップ2812)。
ステップ2810bにおけるセグメント識別を容易にするために、クライアントは、例えば、MPDツリー表現内のパス(図5bを参照)として、プッシュされたセグメントのインデックス、または記述ファイル(すなわちMPDファイルまたはマニフェスト)がSegmentTemplateに依存する場合にはURLテンプレートパラメータのような、付加的なヘッダ情報を活用することができる。
ステップ2810bにおけるセグメント識別を容易にするために、クライアントは、例えば、MPDツリー表現内のパス(図5bを参照)として、プッシュされたセグメントのインデックス、または記述ファイル(すなわちMPDファイルまたはマニフェスト)がSegmentTemplateに依存する場合にはURLテンプレートパラメータのような、付加的なヘッダ情報を活用することができる。
これは、PUSH_PROMISEを構築する際にサーバによって挿入された階層関係を用いるので(上記図27の記述を参照)、ここでは特定のCANCELメッセージであり(ステップ2812)、クライアントは、後続の1つを加えた現在のPUSH_PROMISEのキャンセルをもたらす再帰的なCANCELを送信することができる。
可能な実施形態によれば、クライアント装置がプッシュプロミスを解釈することができない場合、メディアのリソースの次の時間セグメントに対応するメディアデータのすべてのプッシュを、デフォルトによって停止する。
CANCEL命令のこの新たな利用により、メディアセグメント識別の観点から、一旦それがサーバと非同期にされると、クライアントがCANCELメッセージを繰り返すことを回避する。そのような場合、クライアントは、プルモードに戻ることになる。
そして、プッシュによってサーバから受信されるセグメントが所望のセグメントに対応する場合(テスト2810bで真)、クライアントは、PUSH_PROMISEフレームの処理を継続する(テスト2813およびステップ2806上でのループ)。
PUSH_PROMISEフレームがすべて処理されると、クライアント装置は、受理したPUSH_PROMISEに対応するデータを受信してバッファリングすることを(ステップ2814)予期し、開始する。
PUSH_PROMISEフレームがすべて処理されると、クライアント装置は、受理したPUSH_PROMISEに対応するデータを受信してバッファリングすることを(ステップ2814)予期し、開始する。
十分なメディアセグメントがクライアントの受信バッファ内に受信されると(テスト2815)、それらはクライアントによって処理される(2816)。そして、現在のsegment_index変数は、リスト内の第1のセグメントの順序付け数で更新される(ステップ2817)。すべてのクライアントがクライアントのバッファに対してアクセスするとは限らないかもしれない、ということに留意するべきである。例えば、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。この情報は、例えばウェブソケット接続を用いて、サーバからクライアントまで交換されることができる。
プッシュされたメディアセグメントがすべて処理されると、クライアントは、次に、標準的なプルベースのDASH(ステップ2818)に戻り、変数segment_index+1によって指定された、次のセグメントに対応するデータの要求を開始する。並行して、プッシュされたセグメントデータは、選択されたビデオの復号化および表示を開始するために用いられる。
図13は、実施形態に従う装置の概略図である。装置は、サーバ、クライアント、またはプロキシであってもよい。装置は、実施形態による方法を実施するように構成された制御部1301のためにワークメモリとして用いられるRAMメモリ1302を備える。例えば、制御部は、ROMメモリ1303からロードされたコンピュータプログラムの命令を実行するように構成されるであろう。プログラムは、また、ハードドライブ1306からロードしても良い。例えば、コンピュータプログラムは、図8〜図12、図14、図15、図17、図20〜図22、および図26〜図28のフローチャートおよび上記の記述に基づいて設計される。
装置は、また、単一のネットワークインタフェースであってもよいネットワークインタフェース1304を備えるか、または、1セットのネットワークインタフェース(例えば、いくつかの無線インタフェース、またはいくつかのタイプの有線若しくは無線インタフェース)を備える。装置は、ユーザに対する情報を表示するための、およびユーザから入力を受信するための、ユーザインタフェース1305を備えてもよい。
装置は、また、外部装置から/外部装置に、データを受信および/または送信するための入出力モジュール1307を備えてもよい。
本発明が図面および前述の記述に詳細に図示され記述されたが、このような例証および記述は、例証または例示的であって限定的ではなく、本発明が、開示された実施形態に限定されない、ということを考慮すべきである。開示された実施形態にする他の変形物は、図面、開示物、および添付の請求項に関する研究から、特許請求された発明を実施する際に、当業者によって理解され、達成され得る。
なお、本実施形態は以下のように捉えることもできる。
すなわち、サーバの観点に対応する本発明の第1の態様によれば、サーバ装置によってメディアデータをクライアント装置に対してストリーミングする方法は、
・クライアント装置から第1のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第2のメディアデータを識別するステップと、
・前記要求に応答して、前記クライアント装置に対して前記第1のメディアデータに関連する情報を送信し、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージを準備するステップと
を備え、
前記方法は、サーバ装置がクライアント装置に対する第2の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるステップをさらに備える。
クライアントの観点に対応する本発明の第2の態様によれば、サーバ装置によってストリーミングされたメディアデータにクライアント装置によってアクセスする方法は、
・第1のメディアデータに関連する要求をサーバ装置に対して送信するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報を前記サーバ装置から受信するステップと
を備え、
前記方法は、クライアント装置が、クライアント装置によって要求されることなくサーバ装置によって送信される第2のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるステップをさらに備える。
特に、共有されるプッシュポリシーは、クライアント装置に対してサーバ装置によって送信される第2の非要求メディアデータを決定する装置のために、第2のメディアデータを決定する方法を定義してもよい。
このアプローチにより、サーバのプッシュされるメディアデータに関する判定とクライアントのニーズとの間のミスマッチを減少させることができ、それにより、リソースを節約することができる。
これは、クライアントが、サーバの挙動と、それによりこれからプッシュされる第2のメディアデータを予期することを可能にする共有されるプッシュポリシーを用いることによって、実現される。いくつかのクライアントの後続の要求のために用いられる共有されるプッシュポリシーにより、クライアントは、要求がサーバに対して送信される前でさえも、サーバの挙動を予期することができる。
予期の結果として、クライアントは、サーバによるアナウンスに関して予期される方式で、必要でないこのような第2のメディアデータのキャンセルを準備し要求することができる。
第1のメディアデータに関連する要求は、第1のメディアデータおよび/またはこの第1のメディアデータに関連する他のデータに関係してもよい。
第2のメディアデータは、例えばサーバ装置によって、前記第1のメディアデータに関連づけられてもよい。
本発明の実施形態は、サーバ誘導(server−guided)ストリーミングのための軽量のメカニズムを提供する。実施形態は、DASHネットワークとの関連で実施されてもよい。
サーバ装置は、クライアント装置に対してコンテンツ推薦を行うことができる。また、それらはネットワーク利用を最適化することができる。
本発明の実施形態は、既存のHTTP/2機能との互換性をもつ。これらの機能は、本発明の実現実施形態のために有利に用いることができる。
ネットワークの性能は、一般的には増加する。
それに対応して、本発明は、また、クライアント装置に対してメディアデータをストリーミングするためのサーバ装置に関係し、サーバ装置は、
・クライアント装置から第1のメディアデータに関連する要求を受信するように構成された受信器と、
・要求されることなくクライアント装置に対して送信される第2のメディアデータを識別するように構成された制御部と、
・前記要求に応答して、前記第1のメディアデータに関連する情報を前記クライアント装置に対して送信し、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージを準備するように構成された送信器と
を備え、
前記制御部は、クライアント装置に対する第2の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるようにさらに構成される。
本発明は、また、サーバ装置によってストリーミングされたメディアデータへのアクセスのためのクライアント装置に関係し、前記装置は、
・サーバ装置に対して第1のメディアデータに関連する要求を送信するように構成された送信器と、
・前記要求に応答して、前記サーバ装置から前記第1のメディアデータに関連する情報を受信するように構成された受信器と
を備え、
クライアント装置は、クライアント装置によって要求されることなくサーバ装置によって送信される第2のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるように構成される。
サーバおよびクライアント装置は、上記の対応する方法と同じ利点を有する。
方法および装置のオプション機能は、従属請求項において定義される。それらのいくつかは、方法に関して以下に説明される。しかしながら、それらは、また、対応する装置に対して適応することができる。
明示的なアプローチに関して以下に参照された、いくつかの実施形態において、サーバの観点からの方法は、
サーバ装置によってプッシュポリシーを決定するステップと、
クライアント装置とプッシュポリシーを共有するために決定されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置からクライアント装置に対して送信するステップと
をさらに備える。
それに対応して、クライアント側において、前記方法は、共有されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置から受信するステップをさらに備えてもよい。
以下のいくつかの例に記述されるように、共有されたプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
具体的な実施形態において、記述ファイルは、複数のメディアデータ属性レベルを用いてメディアデータを記述し、様々な共有されるプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義される。
他の例において、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたHTTPフレームのヘッダ内に埋め込まれる。
具体的な機能によれば、前記方法は、サーバ装置において、クライアント装置からHTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を受信し、それに応じて、クライアント装置によって要求された他のメディアデータから非要求メディアデータを決定する前に共有されるプッシュポリシーを更新するステップをさらに備えてもよい。
それに対応して、前記方法は、クライアント装置において、HTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を、サーバ装置に対して送信するステップをさらに備えてもよい。
複合型アプローチによれば、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第1のプッシュポリシー部および第2のプッシュポリシー部によって定義され、第1のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備え、
第2のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるHTTPフレームのヘッダ内に埋め込まれる。
例えば、第2のプッシュポリシー部は、第1のプッシュポリシー部内に定義された1つ以上の関連変数に対する1つ以上の値を備えてもよい。
また、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第2のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第1のプッシュポリシー部を形成する。
他の実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたウェブページ内に埋め込まれたJava(登録商標)Scriptプログラムを含む。
さらに他の実施形態において、前記方法は、構造化ドキュメント(上記の記述ファイルまたは以下の例に導入されるHTMLページなど)に基づいて第2の非要求メディアデータを決定するステップをさらに備え、構造化ドキュメントは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、
プッシュポリシー情報は、第2の非要求メディアデータを識別する構造化ドキュメントのツリー表現上で評価される、XPath式を含む。
前記プッシュポリシー情報の構文に関して、実施形態は、プッシュポリシー情報が記述ファイル内に識別された第2の非要求メディアデータの量を定義する第1のプッシュ属性を含む、ということを提供し、
前記記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
具体的な機能によれば、第1のプッシュ属性は、記述ファイル内の要求された第1のメディアデータに相対する第2の非要求メディアデータを識別する。これは、以下に記載されるようなオペレータを用いて行われてもよい。
変形において、第1のプッシュ属性は、記述ファイル内部の具体的なメディアデータの識別子である。
具体的な機能によれば、記述ファイル内の記述情報は、メディアデータが属する期間を定義する期間属性と、メディアデータのメディアタイプを定義するアダプテーション属性と、メディアデータの符号化バージョン(例えば、ビットレート、フレームレート、フレーム解像度、タイミング情報、など)を定義するリプレゼンテーション属性と、定義するセグメント属性との中の少なくとも1つのメディアデータ属性にしたがってメディアデータを記述し、
前記プッシュポリシー情報は、第2の非要求メディアデータを識別するために、メディアデータ属性(単数または複数)上の制約を定義する少なくとも第2のプッシュ属性を含む。
これは、記述ファイルを通じて非常に選択的なプッシュポリシーを有することを可能にする。
特に、プッシュ属性(単数または複数)は、記述ファイル内部の第1のメディアデータの対応するメディアデータ属性(単数または複数)に相対する第2の非要求メディアデータのメディアデータ属性(単数または複数)を定義してもよい。
または、プッシュ属性(単数または複数)は、第2の非要求のメディアデータが検索されなければならない記述ファイル内のノードを識別してもよい。
いくつかの実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに1つのプライオリティ属性があり、第2のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。これは、プッシュデータの送信の順序を定義するためである。
実施形態において、共有されるプッシュポリシーは、要求された第1のメディアデータから第2のメディアデータを識別する。
暗示的アプローチに関して以下に参照された実施形態において、共有のプッシュポリシーは、サーバ装置およびクライアント装置の両方において同じ第2のメディアデータを決定するアルゴリズムを用いて実施され、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第1のメディアデータから同じ第2のメディアデータを決定することを可能にする。
暗示的アプローチおよび明示的アプローチの双方に適応した、いくつかの実施形態において、識別された第2のメディアデータが、各々がアナウンスメッセージを要求する複数のメディアセグメントを備えるならば、前記方法は、クライアント装置に対して送信される単一のアナウンスメッセージに、対応する複数のアナウンスメッセージをマージするステップをさらに備えてもよい。これは、より少量のアナウンスメッセージが送信されるので、帯域幅の消費量を低減するためである。
共有されたプッシュポリシーおよびクライアント装置によるプッシュの結果として生ずる予期を実際に活用するために、前記方法は、サーバ装置が対応する準備したアナウンスメッセージを送信しないように、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、クライアント装置から受信するステップをさらに備えてもよい。
それに対応して、クライアントにおいて、前記方法は、第2の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、サーバ装置に対して送信するステップをさらに備えてもよい。
本発明の実施形態において、第2の非要求メディアデータは、サーバ装置によって準備され(および多分受信され)、少なくとも1つのアナウンスメッセージから独立してクライアント装置によって決定され、要求されることなくサーバ装置がクライアント装置に対して送信する予定である第2の非要求メディアデータを識別する。ここで「独立して(independently)」は、このような非要請データの今後の送信のクライアント装置に通知する専用のこのようなアナウンスメッセージ(すなわち、PUSH_PROMISE)を認識することなく、クライアント装置が第2の非要請データの決定を行うことができる、ということを意味する。
本発明の他の実施形態において、同じ共有されたプッシュポリシーは、それぞれの第1のメディアデータに関連する複数の要求からそれぞれの非要求メディアデータを決定するために用いられる。経時的に同じプッシュポリシーと連続的な要求とを用いることによって、クライアントは、サーバによる無用データの送信をさらに一層効率的に予期しやすいポジションにあり、それにより、それらの送信および対応するアナウンスメッセージの送信を効率的にキャンセルしやすいポジションにある。
サーバからクライアントに対するプッシュデータの送信の順序の通知に関して、サーバ装置によってクライアント装置に対してメディアデータをストリーミングする方法は、
・クライアント装置から第1のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第2のメディアデータを識別するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報と前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージとを前記クライアント装置に送信するステップと
を備えてもよく、
前記方法は、
・サーバ装置によって第2のメディアデータ(これは、共有されたプッシュポリシーの一部またはすべてを形成する)の送信の順序を定義するステップと、
・送信の順序に関する情報であってクライアント装置がサーバによって定義された送信の順序を決定することを可能にする前記情報を、前記アナウンスメッセージとともに送信するステップと
をさらに備える。
例えば、前記第2のメディアの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
前記プライオリティ値は、HTTP/2プロトコルにしたがって定義されてもよい。
実施形態によれば、少なくとも1つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第2のメディアデータをクライアント装置に対して送信するステップと、
・前記第2のメディアデータに応答して、クライアント装置から少なくとも1つの制御フローメッセージを受信するステップと、
・受信された前記少なくとも1つの制御フローメッセージに基づいて、利用可能な帯域幅を推定するステップと
をさらに備える。
例えば、サーバ装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第2のメディアデータを送信する。
前記方法は、前記帯域幅推定に基づいて、第2のメディアデータの送信の更新された順序をサーバ装置によって定義するステップをさらに備えてもよい。
実施形態によれば、クライアント装置からの前記要求は、前記第1のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第1のメディアデータに関係する記述情報を含み、方法は、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第1のメディアデータは、ビデオセグメントである。
ストリーミングは、DASH規格にしたがって実行されてもよい。
例えば、前記方法は、
・クライアント装置から順序更新要求を受信するステップと
・前記順序更新要求に基づいて、第2のメディアデータの送信の新たな順序を定義し、第2のメディアデータの送信の前記新たな順序に関する情報を更新するステップと、
・送信の順序に関連する前記更新通知にしたがってクライアントに対して前記第2のメディアデータを送信するステップと
をさらに備える。
前記方法は、クライアント装置に対して順序更新確認メッセージを送信するステップをさらに備えてもよい。
例えば、前記更新された順序は、前記順序更新要求の受信時刻にクライアント装置に対する送信が始まっていない、第2のメディアデータのために定義される。
例えば、前記順序更新要求は、少なくとも第2のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第2のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第1のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第2のメディアデータの一部のためのおよび少なくとも前記第1のメディアデータの一部に関連するプライオリティ値は、それに応じて更新される。
例えば、前記第1のメディアおよび第2のメディアは、時間的関係、空間的関係、および品質関係の少なくとも1つにしたがって関連付けられる。
実施形態によれば、
・前記第2のメディアデータは、第1のメディアデータの品質を強化するためのエンハンスメントデータを備え、
・プライオリティ値が前記エンハンスメント層のメディアデータのために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第1のメディアデータおよび第2のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第1のメディアデータのビデオコンテンツに関連する情報に基づく。
例えば、第1のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
例えば、前記送信の順序は、少なくとも第1のメディアデータと第2のメディアデータとの間の復号化関連性に基づく。
例えば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
例えば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
例えば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
例えば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをクライアント装置から受信するステップと、
・第2のメディアデータの更新される送信の順序を、前記制御メッセージに基づいて、サーバによって定義するステップと、
・前記更新された送信の順序にしたがってクライアントに対して前記第2のメディアデータを送信するステップと
をさらに備えてもよい。
前記方法は、順序更新確認メッセージをクライアント装置に対して送信するステップをさらに備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアントによって再生されるそれらのメディアデータを保存する。
例えば、サーバ装置は、送信された第1の要求メディアデータの記録を保持し、第2のメディアデータの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で送信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で送信される。
クライアントの観点から、サーバ装置によってストリーミングされたメディアデータをクライアント装置によってアクセスする方法は、
・第1のメディアデータに関連する要求をサーバ装置に対して送信するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報と、要求されていなくともクライアント装置に対して送信される第2のメディアそれぞれ識別する少なくとも1つのアナウンスメッセージとを、前記サーバ装置から受信するステップと
を備えてもよく、
前記方法は、前記アナウンスメッセージとともに第2のメディアデータの送信の順序に関連する情報を受信するステップをさらに備え、前記情報(すなわち共有されたプッシュポリシー)は、サーバによって定義された第2のメディアデータの送信の順序を決定することをクライアント装置が可能にする。
前記方法は、サーバ装置によって定義された第2のメディアデータの送信の順序がクライアント装置の端部におけるストリーミング制約を満たすか否かをクライアント装置によって判定し、前記制約が満たされなければ、順序更新要求をサーバ装置に対して送信するステップをさらに備えてもよい。
例えば、前記第2のメディアデータの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
例えば、前記プライオリティ値は、HTTP/2プロトコルにしたがって定義される。
実施形態によれば、少なくとも1つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、前記方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第2のメディアデータをサーバ装置から受信するステップと、
・前記第2のメディアデータに応答して、少なくとも1つの制御フローメッセージを前記サーバ装置に対して送信し、それによって、送信された前記少なくとも1つの制御フローメッセージに基づいてサーバ装置が利用可能な帯域幅を推定することを可能にするステップと
をさらに備える。
例えば、クライアント装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第2のメディアデータを受信する。
例えば、第2のメディアデータの更新される送信の順序は、前記帯域幅推定に基づいて、サーバ装置によって定義される。
例えば、クライアント装置からの前記要求は、前記第1のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第1のメディアデータに関係する記述情報を含み、前記方法は、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第1のメディアデータは、ビデオセグメントである。
例えば、前記ストリーミングは、DASH規格にしたがって実行される。
方法は、サーバ装置によって定義された第2のメディアデータの新たな送信の順序に関連する更新情報にしたがってサーバ装置から前記第2のメディアデータを受信するステップをさらに備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップをさらに備えてもよい。
実施形態によれば、前記更新された順序は、前記順序更新要求の受信時刻に送信が始まっていない、第2のメディアデータのためにサーバ装置によって定義される。
実施形態によれば、前記順序更新要求は、少なくとも第2のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第2のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第1のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第2のメディアデータの一部のための且つ少なくとも前記第1のメディアデータの一部に関連付けられたプライオリティ値は、それに応じて更新される。
例えば、前記第1のメディアおよび第2のメディアデータは、時間的関係、空間的関係、および品質関係の少なくとも1つにしたがって関連づけられる。
実施形態によれば、
・前記第2のメディアデータは、第1のメディアデータの品質の強化するためのエンハンスメントデータを備え、
・プライオリティ値がエンハンスメント層の第1のメディアデータの少なくとも一部のために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第1のメディアデータおよび第2のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第1のメディアデータのビデオコンテンツに関連する情報に基づく。
実施形態によれば、第1のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
実施形態によれば、前記送信の順序は、少なくとも第1のメディアデータと第2のメディアデータとの間の復号化関連性に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
実施形態によれば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをサーバ装置に送信するステップと、
・前記制御メッセージに基づいて、サーバ装置によって、定義された更新された送信の順序にしたがってサーバ装置から前記第2のメディアデータを受信するステップと
を備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップを備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアント装置によって再生されるそれらのメディアデータを保存する。
実施形態によれば、サーバ装置は、送信された第1の要求メディアデータの記録を保持し、現在再生されているメディアの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で受信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で受信される。
さらに送信の順序を参照して、プロキシサーバによる、クライアント装置とサーバ装置との間のデータ交換を管理する方法は、
・送信の順序の通知に関して以上に定義されるような方法を実行するサーバから、クライアント装置に対して再送信されるメディアデータを受信するステップと
・メディアデータの送信の順序に基づいて、メディアデータのための再送信プライオリティを決定するステップと、
・決定された前記送信プライオリティに基づいて、クライアント装置に対する受信されたメディアデータの再送信を実行するステップと
を備えてもよい。
前記方法は、決定された前記再送信プライオリティに基づいて、受信された前記メディアデータを保存するステップをさらに備えてもよい。
前記方法は、
・第2の態様による方法を実施するクライアント装置から順序更新要求を受信するステップと、
・前記要求が再送信されるメディアデータに関連する場合、前記順序更新要求にしたがって前記再送信プライオリティを更新するステップと、
・更新された再送信プライオリティにしたがってメディアデータの再送信を実行するステップと
をさらに備えてもよい。
前記方法は、
・メディアデータのための、第1のサーバ装置に対する要求を、第1のクライアント装置から受信するステップであって、前記メディアデータは、第2のサーバ装置から第2のクライアント装置に対する再送信のためにプロキシサーバによって保存されるステップと、
・第1のサーバ装置および第2のサーバ装置によって前記メディアデータにそれぞれ関連付けられたプライオリティ値を決定するステップと、
・第1のクライアント装置および第2のクライアント装置に対するそれぞれのストリーミング制約にしたがって前記プライオリティ値を更新するステップと、
・前記更新されたプライオリティ値にしたがって、前記第1のクライアント装置および第2のクライアント装置に対して前記メディアデータを再送信するステップと
をさらに備えてもよく、
前記第1のサーバ装置および第2のサーバ装置は、第1の態様による方法を実施し、前記第1のクライアント装置および第2のクライアント装置は、第2の態様による方法を実施する。
前記方法は、更新されたプライオリティ値に関連する更新通知を第1のサーバ装置および第2のサーバ装置に対して送信するステップをさらに備えてもよい。
本発明の別の態様によれば、サーバ装置とクライアント装置との間でデータをストリーミングする方法であって、
・サーバ装置によって第1の態様による方法を実行するステップと、
・クライアント装置によって第2の態様による方法を実行するステップと
を備える方法が提供される。
本発明のさらに別の態様によれば、プログラミング可能な装置のコンピュータ手段にロードされ実行されたときに、以上に定義されるような方法を実施するための命令を備えるコンピュータプログラムおよびコンピュータプログラムプロダクトが提供される。
本発明のさらに別の態様によれば、第1の態様による方法を実施するように構成されたサーバ装置が提供される。
本発明のさらに別の態様によれば、第2の態様による方法を実施するように構成されたクライアント装置が提供される。
サーバからクライアント装置に対するメディアデータの適応型ストリーミングにための解決手段は、関係のあるクライアント装置の機能に対して、およびサーバとクライアント装置との間の接続を提供するネットワークの特性に対して、クライアント装置に送信されるデータのタイプおよび量を特に適応するために提案されてきた。
これに関連して、DASH(動的適応型HTTPストリーミング)規格などのいくつかの解決手段は、配信されるリソース(またはコンテンツ)の複数のバージョンを保存し、且つこれらのバージョンに対してリソースおよびそれぞれのポインタ(例えばURL)を表現する様々なバージョンの記述を含む記述ファイルを、リソースを要求するクライアント装置に対して送信することを提案する。
そして、記述ファイルに基づいて、クライアント装置は、対応するポインタを用いて、このバージョンのニーズおよび要求にベストマッチするリソースのバージョンを選択することができる。
この解決手段は、記述ファイルがメディアデータを含まない(但しメディアデータに対するポインタのみ含む)光である、という点で有利である。その利用のために関連するバージョンをクライアントに選択させることによって、クライアント装置に適さないメディアデータの交換を回避する。さらに、それはHTTPに基づく現在のウェブアーキテクチャに適合し、既に配備されたキャッシュメカニズムを利用することができる。
その代わりに、しかしながら、メディアデータがクライアント装置において受信されて、その後、復号され表示され得る前に、この解決手段は、クライアント装置とサーバとの間のいくつかの交換(またはラウンドトリップ)を必要とし、それは開始遅延をもたらす。
実施形態において、本発明は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを提供する方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、サーバによって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するステップと、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・クライアント装置に対して記述ファイルを送信するステップと、
・クライアント装置に対して選択されたデータをプッシュするステップと
を備える。
適切な方式において選択されたデータをプッシュ(すなわち、クライアント装置によって請求されないが、以下にさらに説明するようにサーバによって選択されたデータの送信)することによって、1つまたは複数のラウンドトリップを回避することができ、それにより、メディアデータの復号化および表示をさらに高速に開始することができる。
メディアアイテムは、例えば、ビデオ、または例えばオーディオトラックなどのオーディオアイテムであってもよい。
上述のデータのセットは、時間セグメントを表現するバージョンを含むが、以下に説明されるようにイニシャライゼーションデータなどの他のデータを含んでもまたよい、ということに注目されたい。
まさに述べた如く、選択されたデータは、クライアント装置の復号器のためのイニシャライゼーションデータを含んでもよい。したがって、復号器は、クライアント装置がイニシャライゼーションデータを特に、要求する必要なしに、イニシャライズでき、従ってより高速にイニシャライズできる。
上述のように、選択されたデータは、また、時間セグメントを表現する前記バージョンの1つの少なくとも一部を含んでもよい。
データを選択するステップは、プッシュされるデータ(例えばビデオデータ)の量を推定するステップを含んでもよく、それは、どのデータが選択されるのかを決定するときに用いられてもよい。量は、記述ファイル内に定義されたバッファ時間に基づいて、および/または、サーバによって決定された帯域幅推定に基づいて推定されてもよい。
データを選択するステップは、要求に含まれる少なくとも1つのプレファレンスに基づいて、および/またはサーバとクライアント装置との間の従来の交換から導き出される使用データに基づいて、および/またはサーバによる記述ファイルの解析に基づいて、および/またはサーバ内に保存され、記述ファイルに関連するテーブルに基づいて、実行されてもよい。
可能な実施形態によれば、選択されたデータをプッシュするステップに関連するとともに、そのステップに先立って、プッシュプロミスを送信するステップを備えてもよい。したがって、これらのデータを実際に受信する前に、プッシュされるデータがクライアント装置に通知されてもよい。
プッシュプロミスを送信するステップは、記述ファイルを送信するステップの前に実行されてもよく、それは、初期のステージにおいてクライアント装置に通知することを可能にする。
プッシュプロミスは、例えば選択されたデータの識別を含む。
提案された実施形態によれば、サーバは、選択されたデータに関連する信頼水準を決定し、プッシュプロミスは、決定された信頼水準を含む。
以下に述べる詳細説明において説明する可能なインプランテーションによれば、サーバは、選択されたデータを形成するデータのブロックの階層的リプレゼンテーションを保存してもよい。
このようなケースにおいて、
・データのブロックをプッシュしないための命令をクライアント装置から受信するステップと、
・前記データのブロック、および階層的リプレゼンテーションにおける前記データのブロックに連結されたデータのブロックのプッシングをキャンセルするステップと
が備えられていてもよい。
提案された方法は、選択されたデータに関連した信頼度を決定するステップを含んでもよく、そして、
・決定された信頼度が所定の閾値未満であれば、選択されたデータをプッシュするステップは、クライアント装置の復号器のイニシャライゼーションデータのみをプッシュするステップを含み、
・決定された信頼度が所定の閾値を上回れば、選択されたデータをプッシュするステップは、クライアント装置の復号器のためのイニシャライゼーションデータと、時間セグメントを表現する前記バージョンの1つの少なくとも一部をプッシュするステップを含む。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを受信するための方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、クライアント装置によって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・記述ファイルをサーバから受信するステップであって、前記記述ファイルはデータのセットに対するポインタを含むステップと、
・サーバから、非要請データを受信するステップであって、前記非要請データは前記データのセットに属するステップと
を有する。
上述のように、非要請データは、クライアント装置の復号器のためのイニシャライゼーションデータ(その場合には前記非要請データにより復号器をイニシャライズするステップが提供されてもよい)、および/または、少なくとも時間セグメントを表現する前記バージョンの1つの一部(その場合には非要請データの少なくとも一部を復号するステップが提供されてもよい)を含んでもよい。
前記要求は、プッシュされるメディアデータを決定する際にサーバを支援することができる、クライアント装置における復号化を定義する少なくとも1つのプレファレンスを含んでもよい。
前記要求は、また、クライアント装置がプッシュされたデータを受け入れるというインディケータを含んでもよく、それに基づいて、サーバは、データをプッシュすることを効率的に決定することができる。
上記したように、非要請データを受信するステップに関連するとともに、そのステップに先立って、プッシュプロミスを受信するステップを備えてもよい。このプッシュプロミスを受信するステップは、記述ファイルを受信するステップに先立って行われてもよい。
プッシュプロミスは、非要請データおよび/または非要請データに関連付けられた信頼度の識別を含んでもよい。
クライアント装置において、以下のステップ、
・プッシュプロミス内に含まれるデータに基づいてプッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが有していてもよい。
以下のステップ、
・非要請データに関連付けられ且つプッシュプロミス内に含まれた信頼度に基づいて、プッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが用いられてもよい。
受信に際して前記非要請データをバッファするステップは、これらのデータを復号する前に用いられてもよい。
プッシュされたデータがイニシャライゼーションデータおよび/または初期のメディアデータに対してのみ対応するように意図されるように以下のステップ、
・記述ファイルに、およびプッシュプロミス内に含まれるデータに基づいて要求される(すなわち、プッシュされるようには計画されない)データ(例えばビデオデータ)を決定するステップと、
・決定されたデータに対する要求を、サーバに対して送信するステップと
が実施されてもよい。
本発明の実施形態は、また、クライアント装置に対して、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータをストリーミングする方法を提案し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、前記方法は、
・前記クライアント装置が、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・サーバが、クライアント装置から要求を受信するステップと、
・サーバが、記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・サーバが、クライアント装置に対して記述ファイルを送信するステップと、
・サーバが、クライアント装置に対して選択されたデータをプッシュするステップと、・クライアント装置が、サーバから記述ファイルを受信するステップと、
・クライアント装置が、サーバから選択されたデータを受信するステップと
を有する。
本発明の実施形態は、また、サーバからメディアアイテム(例えばビデオ)を表現するメディアデータを提供するための装置を提供するのであって、サーバは、メディアアイテムを表現するデータを保存し、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するように構成された受信器と、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、
・クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、・クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと
を有する。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを受信するための装置を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールと、
・サーバから記述ファイルを受信するように構成されたモジュールであって、前記記述ファイルがデータのセットに対するポインタを含むモジュールと、
・サーバから非要請データを受信するように構成されたモジュールであって、前記非要請データは前記データのセットに属するモジュールと
を有する。
最後に、本発明の実施形態は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータをクライアント装置に対してストリーミングするためのサーバおよびクライアント装置を有するシステムを提供し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、
・前記クライアント装置は、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールを有し、
・前記サーバは、クライアント装置から要求を受信するように構成されたモジュールと、記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと、を有し、
・クライアント装置は、サーバから記述ファイルを受信するように構成されたモジュールと、サーバから選択されたデータを受信するように構成されたモジュールと、を有する、を前記システムは有する。
メディアデータを提供する方法、およびメディアデータを受信する方法のために以上に提案されたオプション機能は、また、メディアデータをストリーミングする方法に対して、および前述の各種装置およびシステムに対して適用する。
なお、本実施形態は以下のように捉えることもできる。
すなわち、サーバの観点に対応する本発明の第1の態様によれば、サーバ装置によってメディアデータをクライアント装置に対してストリーミングする方法は、
・クライアント装置から第1のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第2のメディアデータを識別するステップと、
・前記要求に応答して、前記クライアント装置に対して前記第1のメディアデータに関連する情報を送信し、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージを準備するステップと
を備え、
前記方法は、サーバ装置がクライアント装置に対する第2の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるステップをさらに備える。
クライアントの観点に対応する本発明の第2の態様によれば、サーバ装置によってストリーミングされたメディアデータにクライアント装置によってアクセスする方法は、
・第1のメディアデータに関連する要求をサーバ装置に対して送信するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報を前記サーバ装置から受信するステップと
を備え、
前記方法は、クライアント装置が、クライアント装置によって要求されることなくサーバ装置によって送信される第2のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるステップをさらに備える。
特に、共有されるプッシュポリシーは、クライアント装置に対してサーバ装置によって送信される第2の非要求メディアデータを決定する装置のために、第2のメディアデータを決定する方法を定義してもよい。
このアプローチにより、サーバのプッシュされるメディアデータに関する判定とクライアントのニーズとの間のミスマッチを減少させることができ、それにより、リソースを節約することができる。
これは、クライアントが、サーバの挙動と、それによりこれからプッシュされる第2のメディアデータを予期することを可能にする共有されるプッシュポリシーを用いることによって、実現される。いくつかのクライアントの後続の要求のために用いられる共有されるプッシュポリシーにより、クライアントは、要求がサーバに対して送信される前でさえも、サーバの挙動を予期することができる。
予期の結果として、クライアントは、サーバによるアナウンスに関して予期される方式で、必要でないこのような第2のメディアデータのキャンセルを準備し要求することができる。
第1のメディアデータに関連する要求は、第1のメディアデータおよび/またはこの第1のメディアデータに関連する他のデータに関係してもよい。
第2のメディアデータは、例えばサーバ装置によって、前記第1のメディアデータに関連づけられてもよい。
本発明の実施形態は、サーバ誘導(server−guided)ストリーミングのための軽量のメカニズムを提供する。実施形態は、DASHネットワークとの関連で実施されてもよい。
サーバ装置は、クライアント装置に対してコンテンツ推薦を行うことができる。また、それらはネットワーク利用を最適化することができる。
本発明の実施形態は、既存のHTTP/2機能との互換性をもつ。これらの機能は、本発明の実現実施形態のために有利に用いることができる。
ネットワークの性能は、一般的には増加する。
それに対応して、本発明は、また、クライアント装置に対してメディアデータをストリーミングするためのサーバ装置に関係し、サーバ装置は、
・クライアント装置から第1のメディアデータに関連する要求を受信するように構成された受信器と、
・要求されることなくクライアント装置に対して送信される第2のメディアデータを識別するように構成された制御部と、
・前記要求に応答して、前記第1のメディアデータに関連する情報を前記クライアント装置に対して送信し、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージを準備するように構成された送信器と
を備え、
前記制御部は、クライアント装置に対する第2の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるようにさらに構成される。
本発明は、また、サーバ装置によってストリーミングされたメディアデータへのアクセスのためのクライアント装置に関係し、前記装置は、
・サーバ装置に対して第1のメディアデータに関連する要求を送信するように構成された送信器と、
・前記要求に応答して、前記サーバ装置から前記第1のメディアデータに関連する情報を受信するように構成された受信器と
を備え、
クライアント装置は、クライアント装置によって要求されることなくサーバ装置によって送信される第2のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるように構成される。
サーバおよびクライアント装置は、上記の対応する方法と同じ利点を有する。
方法および装置のオプション機能は、従属請求項において定義される。それらのいくつかは、方法に関して以下に説明される。しかしながら、それらは、また、対応する装置に対して適応することができる。
明示的なアプローチに関して以下に参照された、いくつかの実施形態において、サーバの観点からの方法は、
サーバ装置によってプッシュポリシーを決定するステップと、
クライアント装置とプッシュポリシーを共有するために決定されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置からクライアント装置に対して送信するステップと
をさらに備える。
それに対応して、クライアント側において、前記方法は、共有されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置から受信するステップをさらに備えてもよい。
以下のいくつかの例に記述されるように、共有されたプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
具体的な実施形態において、記述ファイルは、複数のメディアデータ属性レベルを用いてメディアデータを記述し、様々な共有されるプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義される。
他の例において、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたHTTPフレームのヘッダ内に埋め込まれる。
具体的な機能によれば、前記方法は、サーバ装置において、クライアント装置からHTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を受信し、それに応じて、クライアント装置によって要求された他のメディアデータから非要求メディアデータを決定する前に共有されるプッシュポリシーを更新するステップをさらに備えてもよい。
それに対応して、前記方法は、クライアント装置において、HTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を、サーバ装置に対して送信するステップをさらに備えてもよい。
複合型アプローチによれば、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第1のプッシュポリシー部および第2のプッシュポリシー部によって定義され、第1のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備え、
第2のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるHTTPフレームのヘッダ内に埋め込まれる。
例えば、第2のプッシュポリシー部は、第1のプッシュポリシー部内に定義された1つ以上の関連変数に対する1つ以上の値を備えてもよい。
また、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第2のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第1のプッシュポリシー部を形成する。
他の実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたウェブページ内に埋め込まれたJava(登録商標)Scriptプログラムを含む。
さらに他の実施形態において、前記方法は、構造化ドキュメント(上記の記述ファイルまたは以下の例に導入されるHTMLページなど)に基づいて第2の非要求メディアデータを決定するステップをさらに備え、構造化ドキュメントは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、
プッシュポリシー情報は、第2の非要求メディアデータを識別する構造化ドキュメントのツリー表現上で評価される、XPath式を含む。
前記プッシュポリシー情報の構文に関して、実施形態は、プッシュポリシー情報が記述ファイル内に識別された第2の非要求メディアデータの量を定義する第1のプッシュ属性を含む、ということを提供し、
前記記述ファイルは、第1のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
具体的な機能によれば、第1のプッシュ属性は、記述ファイル内の要求された第1のメディアデータに相対する第2の非要求メディアデータを識別する。これは、以下に記載されるようなオペレータを用いて行われてもよい。
変形において、第1のプッシュ属性は、記述ファイル内部の具体的なメディアデータの識別子である。
具体的な機能によれば、記述ファイル内の記述情報は、メディアデータが属する期間を定義する期間属性と、メディアデータのメディアタイプを定義するアダプテーション属性と、メディアデータの符号化バージョン(例えば、ビットレート、フレームレート、フレーム解像度、タイミング情報、など)を定義するリプレゼンテーション属性と、定義するセグメント属性との中の少なくとも1つのメディアデータ属性にしたがってメディアデータを記述し、
前記プッシュポリシー情報は、第2の非要求メディアデータを識別するために、メディアデータ属性(単数または複数)上の制約を定義する少なくとも第2のプッシュ属性を含む。
これは、記述ファイルを通じて非常に選択的なプッシュポリシーを有することを可能にする。
特に、プッシュ属性(単数または複数)は、記述ファイル内部の第1のメディアデータの対応するメディアデータ属性(単数または複数)に相対する第2の非要求メディアデータのメディアデータ属性(単数または複数)を定義してもよい。
または、プッシュ属性(単数または複数)は、第2の非要求のメディアデータが検索されなければならない記述ファイル内のノードを識別してもよい。
いくつかの実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに1つのプライオリティ属性があり、第2のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。これは、プッシュデータの送信の順序を定義するためである。
実施形態において、共有されるプッシュポリシーは、要求された第1のメディアデータから第2のメディアデータを識別する。
暗示的アプローチに関して以下に参照された実施形態において、共有のプッシュポリシーは、サーバ装置およびクライアント装置の両方において同じ第2のメディアデータを決定するアルゴリズムを用いて実施され、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第1のメディアデータから同じ第2のメディアデータを決定することを可能にする。
暗示的アプローチおよび明示的アプローチの双方に適応した、いくつかの実施形態において、識別された第2のメディアデータが、各々がアナウンスメッセージを要求する複数のメディアセグメントを備えるならば、前記方法は、クライアント装置に対して送信される単一のアナウンスメッセージに、対応する複数のアナウンスメッセージをマージするステップをさらに備えてもよい。これは、より少量のアナウンスメッセージが送信されるので、帯域幅の消費量を低減するためである。
共有されたプッシュポリシーおよびクライアント装置によるプッシュの結果として生ずる予期を実際に活用するために、前記方法は、サーバ装置が対応する準備したアナウンスメッセージを送信しないように、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、クライアント装置から受信するステップをさらに備えてもよい。
それに対応して、クライアントにおいて、前記方法は、第2の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、サーバ装置に対して送信するステップをさらに備えてもよい。
本発明の実施形態において、第2の非要求メディアデータは、サーバ装置によって準備され(および多分受信され)、少なくとも1つのアナウンスメッセージから独立してクライアント装置によって決定され、要求されることなくサーバ装置がクライアント装置に対して送信する予定である第2の非要求メディアデータを識別する。ここで「独立して(independently)」は、このような非要請データの今後の送信のクライアント装置に通知する専用のこのようなアナウンスメッセージ(すなわち、PUSH_PROMISE)を認識することなく、クライアント装置が第2の非要請データの決定を行うことができる、ということを意味する。
本発明の他の実施形態において、同じ共有されたプッシュポリシーは、それぞれの第1のメディアデータに関連する複数の要求からそれぞれの非要求メディアデータを決定するために用いられる。経時的に同じプッシュポリシーと連続的な要求とを用いることによって、クライアントは、サーバによる無用データの送信をさらに一層効率的に予期しやすいポジションにあり、それにより、それらの送信および対応するアナウンスメッセージの送信を効率的にキャンセルしやすいポジションにある。
サーバからクライアントに対するプッシュデータの送信の順序の通知に関して、サーバ装置によってクライアント装置に対してメディアデータをストリーミングする方法は、
・クライアント装置から第1のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第2のメディアデータを識別するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報と前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージとを前記クライアント装置に送信するステップと
を備えてもよく、
前記方法は、
・サーバ装置によって第2のメディアデータ(これは、共有されたプッシュポリシーの一部またはすべてを形成する)の送信の順序を定義するステップと、
・送信の順序に関する情報であってクライアント装置がサーバによって定義された送信の順序を決定することを可能にする前記情報を、前記アナウンスメッセージとともに送信するステップと
をさらに備える。
例えば、前記第2のメディアの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
前記プライオリティ値は、HTTP/2プロトコルにしたがって定義されてもよい。
実施形態によれば、少なくとも1つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第2のメディアデータをクライアント装置に対して送信するステップと、
・前記第2のメディアデータに応答して、クライアント装置から少なくとも1つの制御フローメッセージを受信するステップと、
・受信された前記少なくとも1つの制御フローメッセージに基づいて、利用可能な帯域幅を推定するステップと
をさらに備える。
例えば、サーバ装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第2のメディアデータを送信する。
前記方法は、前記帯域幅推定に基づいて、第2のメディアデータの送信の更新された順序をサーバ装置によって定義するステップをさらに備えてもよい。
実施形態によれば、クライアント装置からの前記要求は、前記第1のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第1のメディアデータに関係する記述情報を含み、方法は、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第1のメディアデータは、ビデオセグメントである。
ストリーミングは、DASH規格にしたがって実行されてもよい。
例えば、前記方法は、
・クライアント装置から順序更新要求を受信するステップと
・前記順序更新要求に基づいて、第2のメディアデータの送信の新たな順序を定義し、第2のメディアデータの送信の前記新たな順序に関する情報を更新するステップと、
・送信の順序に関連する前記更新通知にしたがってクライアントに対して前記第2のメディアデータを送信するステップと
をさらに備える。
前記方法は、クライアント装置に対して順序更新確認メッセージを送信するステップをさらに備えてもよい。
例えば、前記更新された順序は、前記順序更新要求の受信時刻にクライアント装置に対する送信が始まっていない、第2のメディアデータのために定義される。
例えば、前記順序更新要求は、少なくとも第2のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第2のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第1のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第2のメディアデータの一部のためのおよび少なくとも前記第1のメディアデータの一部に関連するプライオリティ値は、それに応じて更新される。
例えば、前記第1のメディアおよび第2のメディアは、時間的関係、空間的関係、および品質関係の少なくとも1つにしたがって関連付けられる。
実施形態によれば、
・前記第2のメディアデータは、第1のメディアデータの品質を強化するためのエンハンスメントデータを備え、
・プライオリティ値が前記エンハンスメント層のメディアデータのために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第1のメディアデータおよび第2のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第1のメディアデータのビデオコンテンツに関連する情報に基づく。
例えば、第1のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
例えば、前記送信の順序は、少なくとも第1のメディアデータと第2のメディアデータとの間の復号化関連性に基づく。
例えば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
例えば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
例えば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
例えば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをクライアント装置から受信するステップと、
・第2のメディアデータの更新される送信の順序を、前記制御メッセージに基づいて、サーバによって定義するステップと、
・前記更新された送信の順序にしたがってクライアントに対して前記第2のメディアデータを送信するステップと
をさらに備えてもよい。
前記方法は、順序更新確認メッセージをクライアント装置に対して送信するステップをさらに備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアントによって再生されるそれらのメディアデータを保存する。
例えば、サーバ装置は、送信された第1の要求メディアデータの記録を保持し、第2のメディアデータの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で送信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で送信される。
クライアントの観点から、サーバ装置によってストリーミングされたメディアデータをクライアント装置によってアクセスする方法は、
・第1のメディアデータに関連する要求をサーバ装置に対して送信するステップと、
・前記要求に応答して、前記第1のメディアデータに関連する情報と、要求されていなくともクライアント装置に対して送信される第2のメディアそれぞれ識別する少なくとも1つのアナウンスメッセージとを、前記サーバ装置から受信するステップと
を備えてもよく、
前記方法は、前記アナウンスメッセージとともに第2のメディアデータの送信の順序に関連する情報を受信するステップをさらに備え、前記情報(すなわち共有されたプッシュポリシー)は、サーバによって定義された第2のメディアデータの送信の順序を決定することをクライアント装置が可能にする。
前記方法は、サーバ装置によって定義された第2のメディアデータの送信の順序がクライアント装置の端部におけるストリーミング制約を満たすか否かをクライアント装置によって判定し、前記制約が満たされなければ、順序更新要求をサーバ装置に対して送信するステップをさらに備えてもよい。
例えば、前記第2のメディアデータの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
例えば、前記プライオリティ値は、HTTP/2プロトコルにしたがって定義される。
実施形態によれば、少なくとも1つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、前記方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第2のメディアデータをサーバ装置から受信するステップと、
・前記第2のメディアデータに応答して、少なくとも1つの制御フローメッセージを前記サーバ装置に対して送信し、それによって、送信された前記少なくとも1つの制御フローメッセージに基づいてサーバ装置が利用可能な帯域幅を推定することを可能にするステップと
をさらに備える。
例えば、クライアント装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第2のメディアデータを受信する。
例えば、第2のメディアデータの更新される送信の順序は、前記帯域幅推定に基づいて、サーバ装置によって定義される。
例えば、クライアント装置からの前記要求は、前記第1のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第1のメディアデータに関係する記述情報を含み、前記方法は、前記記述ファイルに基づいて第2の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第1のメディアデータは、ビデオセグメントである。
例えば、前記ストリーミングは、DASH規格にしたがって実行される。
方法は、サーバ装置によって定義された第2のメディアデータの新たな送信の順序に関連する更新情報にしたがってサーバ装置から前記第2のメディアデータを受信するステップをさらに備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップをさらに備えてもよい。
実施形態によれば、前記更新された順序は、前記順序更新要求の受信時刻に送信が始まっていない、第2のメディアデータのためにサーバ装置によって定義される。
実施形態によれば、前記順序更新要求は、少なくとも第2のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第2のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第1のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第2のメディアデータの一部のための且つ少なくとも前記第1のメディアデータの一部に関連付けられたプライオリティ値は、それに応じて更新される。
例えば、前記第1のメディアおよび第2のメディアデータは、時間的関係、空間的関係、および品質関係の少なくとも1つにしたがって関連づけられる。
実施形態によれば、
・前記第2のメディアデータは、第1のメディアデータの品質の強化するためのエンハンスメントデータを備え、
・プライオリティ値がエンハンスメント層の第1のメディアデータの少なくとも一部のために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第1のメディアデータおよび第2のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第1のメディアデータのビデオコンテンツに関連する情報に基づく。
実施形態によれば、第1のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
実施形態によれば、前記送信の順序は、少なくとも第1のメディアデータと第2のメディアデータとの間の復号化関連性に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
実施形態によれば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをサーバ装置に送信するステップと、
・前記制御メッセージに基づいて、サーバ装置によって、定義された更新された送信の順序にしたがってサーバ装置から前記第2のメディアデータを受信するステップと
を備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップを備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアント装置によって再生されるそれらのメディアデータを保存する。
実施形態によれば、サーバ装置は、送信された第1の要求メディアデータの記録を保持し、現在再生されているメディアの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で受信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で受信される。
さらに送信の順序を参照して、プロキシサーバによる、クライアント装置とサーバ装置との間のデータ交換を管理する方法は、
・送信の順序の通知に関して以上に定義されるような方法を実行するサーバから、クライアント装置に対して再送信されるメディアデータを受信するステップと
・メディアデータの送信の順序に基づいて、メディアデータのための再送信プライオリティを決定するステップと、
・決定された前記送信プライオリティに基づいて、クライアント装置に対する受信されたメディアデータの再送信を実行するステップと
を備えてもよい。
前記方法は、決定された前記再送信プライオリティに基づいて、受信された前記メディアデータを保存するステップをさらに備えてもよい。
前記方法は、
・第2の態様による方法を実施するクライアント装置から順序更新要求を受信するステップと、
・前記要求が再送信されるメディアデータに関連する場合、前記順序更新要求にしたがって前記再送信プライオリティを更新するステップと、
・更新された再送信プライオリティにしたがってメディアデータの再送信を実行するステップと
をさらに備えてもよい。
前記方法は、
・メディアデータのための、第1のサーバ装置に対する要求を、第1のクライアント装置から受信するステップであって、前記メディアデータは、第2のサーバ装置から第2のクライアント装置に対する再送信のためにプロキシサーバによって保存されるステップと、
・第1のサーバ装置および第2のサーバ装置によって前記メディアデータにそれぞれ関連付けられたプライオリティ値を決定するステップと、
・第1のクライアント装置および第2のクライアント装置に対するそれぞれのストリーミング制約にしたがって前記プライオリティ値を更新するステップと、
・前記更新されたプライオリティ値にしたがって、前記第1のクライアント装置および第2のクライアント装置に対して前記メディアデータを再送信するステップと
をさらに備えてもよく、
前記第1のサーバ装置および第2のサーバ装置は、第1の態様による方法を実施し、前記第1のクライアント装置および第2のクライアント装置は、第2の態様による方法を実施する。
前記方法は、更新されたプライオリティ値に関連する更新通知を第1のサーバ装置および第2のサーバ装置に対して送信するステップをさらに備えてもよい。
本発明の別の態様によれば、サーバ装置とクライアント装置との間でデータをストリーミングする方法であって、
・サーバ装置によって第1の態様による方法を実行するステップと、
・クライアント装置によって第2の態様による方法を実行するステップと
を備える方法が提供される。
本発明のさらに別の態様によれば、プログラミング可能な装置のコンピュータ手段にロードされ実行されたときに、以上に定義されるような方法を実施するための命令を備えるコンピュータプログラムおよびコンピュータプログラムプロダクトが提供される。
本発明のさらに別の態様によれば、第1の態様による方法を実施するように構成されたサーバ装置が提供される。
本発明のさらに別の態様によれば、第2の態様による方法を実施するように構成されたクライアント装置が提供される。
サーバからクライアント装置に対するメディアデータの適応型ストリーミングにための解決手段は、関係のあるクライアント装置の機能に対して、およびサーバとクライアント装置との間の接続を提供するネットワークの特性に対して、クライアント装置に送信されるデータのタイプおよび量を特に適応するために提案されてきた。
これに関連して、DASH(動的適応型HTTPストリーミング)規格などのいくつかの解決手段は、配信されるリソース(またはコンテンツ)の複数のバージョンを保存し、且つこれらのバージョンに対してリソースおよびそれぞれのポインタ(例えばURL)を表現する様々なバージョンの記述を含む記述ファイルを、リソースを要求するクライアント装置に対して送信することを提案する。
そして、記述ファイルに基づいて、クライアント装置は、対応するポインタを用いて、このバージョンのニーズおよび要求にベストマッチするリソースのバージョンを選択することができる。
この解決手段は、記述ファイルがメディアデータを含まない(但しメディアデータに対するポインタのみ含む)光である、という点で有利である。その利用のために関連するバージョンをクライアントに選択させることによって、クライアント装置に適さないメディアデータの交換を回避する。さらに、それはHTTPに基づく現在のウェブアーキテクチャに適合し、既に配備されたキャッシュメカニズムを利用することができる。
その代わりに、しかしながら、メディアデータがクライアント装置において受信されて、その後、復号され表示され得る前に、この解決手段は、クライアント装置とサーバとの間のいくつかの交換(またはラウンドトリップ)を必要とし、それは開始遅延をもたらす。
実施形態において、本発明は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを提供する方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、サーバによって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するステップと、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・クライアント装置に対して記述ファイルを送信するステップと、
・クライアント装置に対して選択されたデータをプッシュするステップと
を備える。
適切な方式において選択されたデータをプッシュ(すなわち、クライアント装置によって請求されないが、以下にさらに説明するようにサーバによって選択されたデータの送信)することによって、1つまたは複数のラウンドトリップを回避することができ、それにより、メディアデータの復号化および表示をさらに高速に開始することができる。
メディアアイテムは、例えば、ビデオ、または例えばオーディオトラックなどのオーディオアイテムであってもよい。
上述のデータのセットは、時間セグメントを表現するバージョンを含むが、以下に説明されるようにイニシャライゼーションデータなどの他のデータを含んでもまたよい、ということに注目されたい。
まさに述べた如く、選択されたデータは、クライアント装置の復号器のためのイニシャライゼーションデータを含んでもよい。したがって、復号器は、クライアント装置がイニシャライゼーションデータを特に、要求する必要なしに、イニシャライズでき、従ってより高速にイニシャライズできる。
上述のように、選択されたデータは、また、時間セグメントを表現する前記バージョンの1つの少なくとも一部を含んでもよい。
データを選択するステップは、プッシュされるデータ(例えばビデオデータ)の量を推定するステップを含んでもよく、それは、どのデータが選択されるのかを決定するときに用いられてもよい。量は、記述ファイル内に定義されたバッファ時間に基づいて、および/または、サーバによって決定された帯域幅推定に基づいて推定されてもよい。
データを選択するステップは、要求に含まれる少なくとも1つのプレファレンスに基づいて、および/またはサーバとクライアント装置との間の従来の交換から導き出される使用データに基づいて、および/またはサーバによる記述ファイルの解析に基づいて、および/またはサーバ内に保存され、記述ファイルに関連するテーブルに基づいて、実行されてもよい。
可能な実施形態によれば、選択されたデータをプッシュするステップに関連するとともに、そのステップに先立って、プッシュプロミスを送信するステップを備えてもよい。したがって、これらのデータを実際に受信する前に、プッシュされるデータがクライアント装置に通知されてもよい。
プッシュプロミスを送信するステップは、記述ファイルを送信するステップの前に実行されてもよく、それは、初期のステージにおいてクライアント装置に通知することを可能にする。
プッシュプロミスは、例えば選択されたデータの識別を含む。
提案された実施形態によれば、サーバは、選択されたデータに関連する信頼水準を決定し、プッシュプロミスは、決定された信頼水準を含む。
以下に述べる詳細説明において説明する可能なインプランテーションによれば、サーバは、選択されたデータを形成するデータのブロックの階層的リプレゼンテーションを保存してもよい。
このようなケースにおいて、
・データのブロックをプッシュしないための命令をクライアント装置から受信するステップと、
・前記データのブロック、および階層的リプレゼンテーションにおける前記データのブロックに連結されたデータのブロックのプッシングをキャンセルするステップと
が備えられていてもよい。
提案された方法は、選択されたデータに関連した信頼度を決定するステップを含んでもよく、そして、
・決定された信頼度が所定の閾値未満であれば、選択されたデータをプッシュするステップは、クライアント装置の復号器のイニシャライゼーションデータのみをプッシュするステップを含み、
・決定された信頼度が所定の閾値を上回れば、選択されたデータをプッシュするステップは、クライアント装置の復号器のためのイニシャライゼーションデータと、時間セグメントを表現する前記バージョンの1つの少なくとも一部をプッシュするステップを含む。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを受信するための方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、クライアント装置によって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・記述ファイルをサーバから受信するステップであって、前記記述ファイルはデータのセットに対するポインタを含むステップと、
・サーバから、非要請データを受信するステップであって、前記非要請データは前記データのセットに属するステップと
を有する。
上述のように、非要請データは、クライアント装置の復号器のためのイニシャライゼーションデータ(その場合には前記非要請データにより復号器をイニシャライズするステップが提供されてもよい)、および/または、少なくとも時間セグメントを表現する前記バージョンの1つの一部(その場合には非要請データの少なくとも一部を復号するステップが提供されてもよい)を含んでもよい。
前記要求は、プッシュされるメディアデータを決定する際にサーバを支援することができる、クライアント装置における復号化を定義する少なくとも1つのプレファレンスを含んでもよい。
前記要求は、また、クライアント装置がプッシュされたデータを受け入れるというインディケータを含んでもよく、それに基づいて、サーバは、データをプッシュすることを効率的に決定することができる。
上記したように、非要請データを受信するステップに関連するとともに、そのステップに先立って、プッシュプロミスを受信するステップを備えてもよい。このプッシュプロミスを受信するステップは、記述ファイルを受信するステップに先立って行われてもよい。
プッシュプロミスは、非要請データおよび/または非要請データに関連付けられた信頼度の識別を含んでもよい。
クライアント装置において、以下のステップ、
・プッシュプロミス内に含まれるデータに基づいてプッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが有していてもよい。
以下のステップ、
・非要請データに関連付けられ且つプッシュプロミス内に含まれた信頼度に基づいて、プッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが用いられてもよい。
受信に際して前記非要請データをバッファするステップは、これらのデータを復号する前に用いられてもよい。
プッシュされたデータがイニシャライゼーションデータおよび/または初期のメディアデータに対してのみ対応するように意図されるように以下のステップ、
・記述ファイルに、およびプッシュプロミス内に含まれるデータに基づいて要求される(すなわち、プッシュされるようには計画されない)データ(例えばビデオデータ)を決定するステップと、
・決定されたデータに対する要求を、サーバに対して送信するステップと
が実施されてもよい。
本発明の実施形態は、また、クライアント装置に対して、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータをストリーミングする方法を提案し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、前記方法は、
・前記クライアント装置が、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・サーバが、クライアント装置から要求を受信するステップと、
・サーバが、記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・サーバが、クライアント装置に対して記述ファイルを送信するステップと、
・サーバが、クライアント装置に対して選択されたデータをプッシュするステップと、・クライアント装置が、サーバから記述ファイルを受信するステップと、
・クライアント装置が、サーバから選択されたデータを受信するステップと
を有する。
本発明の実施形態は、また、サーバからメディアアイテム(例えばビデオ)を表現するメディアデータを提供するための装置を提供するのであって、サーバは、メディアアイテムを表現するデータを保存し、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するように構成された受信器と、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、
・クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、・クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと
を有する。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータを受信するための装置を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールと、
・サーバから記述ファイルを受信するように構成されたモジュールであって、前記記述ファイルがデータのセットに対するポインタを含むモジュールと、
・サーバから非要請データを受信するように構成されたモジュールであって、前記非要請データは前記データのセットに属するモジュールと
を有する。
最後に、本発明の実施形態は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム(例えばビデオ)を表現するメディアデータをクライアント装置に対してストリーミングするためのサーバおよびクライアント装置を有するシステムを提供し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、
・前記クライアント装置は、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールを有し、
・前記サーバは、クライアント装置から要求を受信するように構成されたモジュールと、記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと、を有し、
・クライアント装置は、サーバから記述ファイルを受信するように構成されたモジュールと、サーバから選択されたデータを受信するように構成されたモジュールと、を有する、を前記システムは有する。
メディアデータを提供する方法、およびメディアデータを受信する方法のために以上に提案されたオプション機能は、また、メディアデータをストリーミングする方法に対して、および前述の各種装置およびシステムに対して適用する。
特許請求の範囲の単語「備える(comprising)」は、他の要素またはステップを除外せず、また、不定冠詞「a」または「an」は、複数のものを除外しない。単一のプロセッサまたは他のユニットは、特許請求の範囲内の列挙された、いくつかのアイテムの機能を実現してもよい。個別の機能が個別の従属請求項内に相互に列挙されるという単なる事実は、これらの機能の組み合わせを有利に用いることができない、ということを示すものではない。特許請求の範囲内の任意の参照符号も、また、本発明の範囲を制限するものとして解釈するべきでない。
Claims (17)
- メディアデータをクライアントへ送信するサーバであって、
前記クライアントから第1メディアデータのリクエストを受信する受信手段と、
前記受信手段によるリクエストの受信に応じて、前記クライアントに対して前記第1メディアデータを送信する送信手段と、
前記第1メディアデータのリクエストを送信した前記クライアントに対してプッシュすべき第2メディアデータを、前記クライアントとの間で共有されたプッシュストラテジーを用いることによって特定する特定手段と、
前記特定手段により特定された前記第2メディアデータを前記クライアントに対してプッシュするプッシュ手段とを有するサーバ。 - 前記送信手段は、前記特定手段により特定された前記第2メディアデータを識別するための1又は複数のメッセージを前記クライアントに対してさらに送信する請求項1に記載のサーバ。
- 前記クライアントとの間で共有される前記プッシュストラテジーは、前記サーバによる前記第2メディアデータの送信順序を規定し、前記送信手段は、前記送信順序に関する情報を前記クライアントに対してさらに送信する請求項1又は2に記載のサーバ。
- 前記プッシュストラテジーの共有は前記クライアントから前記サーバに対する情報の送信によりなされる請求項1乃至3のうち何れか1項に記載のサーバ。
- 前記プッシュストラテジーの共有は前記サーバから前記クライアントに対する情報の送信によりなされる請求項1乃至3のうち何れか1項に記載のサーバ。
- 前記情報は、HTTPフレームのヘッダに格納される請求項4又は5に記載のサーバ。
- サーバからメディアデータを受信するクライアントであって、
前記サーバに対して第1メディアデータのリクエストを送信する送信手段と、
前記送信手段により送信されたリクエストに応答して前記サーバから送信される前記第1メディアデータを受信する受信手段と、
前記サーバとの間で共有されたプッシュストラテジーを用いることによって、前記サーバが前記第1メディアデータをリクエストした前記クライアントに対してプッシュすべき第2メディアデータを決定する決定手段とを有するクライアント。 - 前記プッシュストラテジーを決定する決定手段と、
前記決定手段により決定されたプッシュストラテジーを示す情報を前記共有のために前記サーバへ通知する通知手段とを有する請求項7に記載のクライアント。 - 前記プッシュストラテジーの共有は前記サーバから前記クライアントに対する情報の送信によりなされる請求項7又は8に記載のクライアント。
- 前記情報は、HTTPフレームのヘッダに格納される請求項8又は9に記載のクライアント。
- 前記決定手段は、前記第1メディアデータと、前記プッシュストラテジーとに基づいて前記第2メディアデータを決定する請求項7乃至10のうち何れか1項に記載のクライアント。
- 前記第2メディアデータを識別するための識別情報と、前記第2メディアデータの送信順序に関する順序情報とを前記サーバから受信する情報受信手段と、
前記情報受信手段により受信された順序情報に応じた送信順序を変更すべきか否かを判定する判定手段と、
前記判定手段による判定結果に応じて前記サーバに対して変更要求を送信する要求手段とを有する請求項7乃至11のうち何れか1項に記載のクライアント。 - 通信装置から他の通信装置に対するメディアデータの送信方法であって、
前記他の通信装置から第1メディアデータのリクエストを受信する受信工程と、
前記リクエストの受信に応じて、前記他の通信装置に対して前記第1メディアデータを送信する送信工程と、
前記第1メディアデータのリクエストを送信した前記他の通信装置に対してプッシュすべき第2メディアデータを、前記通信装置と前記他の通信装置との間で共有されたプッシュストラテジーを用いることによって特定する特定工程と、
前記特定された前記第2メディアデータを前記他の通信装置に対してプッシュするプッシュ工程とを有する送信方法。 - 前記特定された前記第2メディアデータを識別するための1又は複数のメッセージを、前記プッシュ工程におけるプッシュ前に前記他の通信装置に対して送信する第2送信工程をさらに有する請求項13に記載の送信方法。
- 前記プッシュストラテジーは、前記通信装置から前記他の通信装置に対する情報の通知により共有される請求項13又は14に記載の送信方法。
- コンピュータを請求項1乃至6のうち何れか1項に記載のサーバの各手段として動作させるためのプログラム。
- コンピュータを請求項7乃至12のうち何れか1項に記載のクライアントの各手段として動作させるためのプログラム。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1312561.2 | 2013-07-12 | ||
GB1312561.2A GB2516116B (en) | 2013-07-12 | 2013-07-12 | Adaptive data streaming method with push messages control |
GB1312547.1A GB2516112B (en) | 2013-07-12 | 2013-07-12 | Methods for providing media data, method for receiving media data and corresponding devices |
GB1312547.1 | 2013-07-12 | ||
GB1410540.7A GB2517060B (en) | 2013-07-12 | 2014-06-12 | Adaptive data streaming method with push messages control |
GB1410540.7 | 2014-06-12 | ||
PCT/EP2014/064949 WO2015004276A2 (en) | 2013-07-12 | 2014-07-11 | Adaptive data streaming method with push messages control |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018192305A Division JP6632682B2 (ja) | 2013-07-12 | 2018-10-11 | メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2016531466A JP2016531466A (ja) | 2016-10-06 |
JP2016531466A5 true JP2016531466A5 (ja) | 2017-08-17 |
JP6419173B2 JP6419173B2 (ja) | 2018-11-07 |
Family
ID=52280671
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016524842A Active JP6419173B2 (ja) | 2013-07-12 | 2014-07-11 | プッシュメッセージ制御による適応型データストリーミング方法 |
JP2018192305A Active JP6632682B2 (ja) | 2013-07-12 | 2018-10-11 | メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム |
JP2019223944A Active JP6918910B2 (ja) | 2013-07-12 | 2019-12-11 | メディアデータの提供方法、メディアデータの受信方法、及びプログラム |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018192305A Active JP6632682B2 (ja) | 2013-07-12 | 2018-10-11 | メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム |
JP2019223944A Active JP6918910B2 (ja) | 2013-07-12 | 2019-12-11 | メディアデータの提供方法、メディアデータの受信方法、及びプログラム |
Country Status (7)
Country | Link |
---|---|
US (3) | US10104190B2 (ja) |
EP (1) | EP3020208B1 (ja) |
JP (3) | JP6419173B2 (ja) |
KR (3) | KR101909160B1 (ja) |
CN (2) | CN109842613B (ja) |
RU (3) | RU2625328C1 (ja) |
WO (1) | WO2015004276A2 (ja) |
Families Citing this family (91)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9077784B2 (en) * | 2009-02-06 | 2015-07-07 | Empire Technology Development Llc | Media file synchronization |
US10306273B2 (en) | 2013-07-19 | 2019-05-28 | Sony Corporation | Information processing device and method for generating partial image information including group identification information |
WO2015014773A1 (en) | 2013-07-29 | 2015-02-05 | Koninklijke Kpn N.V. | Providing tile video streams to a client |
EP3075110B1 (en) * | 2013-11-27 | 2018-01-10 | Telefonaktiebolaget LM Ericsson (publ) | Controlling a transmission control protocol window size |
WO2015137702A1 (en) * | 2014-03-10 | 2015-09-17 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting messages to a dash client |
WO2015197815A1 (en) | 2014-06-27 | 2015-12-30 | Koninklijke Kpn N.V. | Determining a region of interest on the basis of a hevc-tiled video stream |
WO2015197818A1 (en) | 2014-06-27 | 2015-12-30 | Koninklijke Kpn N.V. | Hevc-tiled video streaming |
US11943289B2 (en) | 2014-10-14 | 2024-03-26 | Comcast Cable Communications, Llc | Manipulation of content transmissions |
US11917002B2 (en) | 2014-10-14 | 2024-02-27 | Comcast Cable Communications, Llc | Manipulation and recording of content transmissions |
US20170272691A1 (en) * | 2014-12-22 | 2017-09-21 | Lg Electronics Inc. | Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method |
US10880357B2 (en) * | 2014-12-23 | 2020-12-29 | Adobe Inc. | Reducing requests for media segments in streaming of multimedia content |
GB2534849A (en) * | 2015-01-28 | 2016-08-10 | Canon Kk | Client-driven push of resources by a server device |
KR101919726B1 (ko) * | 2015-02-15 | 2018-11-16 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 하이퍼텍스트 전송 프로토콜 미디어 스트림에 기초한 미디어 프레젠테이션 가이드 방법 및 관련 장치 |
US10412132B2 (en) * | 2015-02-16 | 2019-09-10 | Lg Electronics Inc. | Broadcasting signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method |
JP6482330B2 (ja) * | 2015-03-09 | 2019-03-13 | キヤノン株式会社 | 通信装置、通信方法、及びプログラム |
US9772813B2 (en) * | 2015-03-31 | 2017-09-26 | Facebook, Inc. | Multi-user media presentation system |
GB2575189B (en) * | 2015-05-27 | 2020-06-17 | Canon Kk | Adaptive client-driven push of resources by a server device |
US10412461B2 (en) | 2015-06-12 | 2019-09-10 | Cable Television Laboratories, Inc. | Media streaming with latency minimization |
WO2016204712A1 (en) * | 2015-06-16 | 2016-12-22 | Intel IP Corporation | Adaptive video content for cellular communication |
WO2017007376A1 (en) * | 2015-07-03 | 2017-01-12 | Telefonaktiebolaget Lm Ericsson (Publ) | 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 |
GB2540632B (en) * | 2015-07-24 | 2018-05-16 | Canon Kk | Methods, devices and computer programs for pushing data in a network environment comprising cache servers |
GB2540633B (en) | 2015-07-24 | 2018-07-25 | Canon Kk | Methods, devices and computer programs enabling data to be pushed in a network environment comprising proxies |
US20170041422A1 (en) * | 2015-08-07 | 2017-02-09 | Futurewei Technologies, Inc. | Method and system for retrieving a content manifest in a network |
JP6495777B2 (ja) * | 2015-08-07 | 2019-04-03 | Kddi株式会社 | コンテンツ配信ネットワークの転送装置、サーバ装置及びプログラム |
JP2017038297A (ja) * | 2015-08-12 | 2017-02-16 | キヤノン株式会社 | 通信装置、通信方法、及び通信システム |
US10715843B2 (en) | 2015-08-20 | 2020-07-14 | Koninklijke Kpn N.V. | Forming one or more tile streams on the basis of one or more video streams |
CN108476327B (zh) * | 2015-08-20 | 2021-03-19 | 皇家Kpn公司 | 基于媒体流来形成拼块化视频 |
US10152080B2 (en) * | 2015-09-23 | 2018-12-11 | Adobe Systems Incorporated | Power efficient multimedia content streaming based on media segment duration |
US10158682B2 (en) | 2015-09-23 | 2018-12-18 | Adobe Systems Incorporated | Power efficient multimedia content streaming based on a server push |
EP3360330B1 (en) | 2015-10-08 | 2021-03-24 | Koninklijke KPN N.V. | Enhancing a region of interest in video frames of a video stream |
CN106604077B (zh) * | 2015-10-14 | 2020-09-29 | 中兴通讯股份有限公司 | 自适应流媒体传输方法及装置 |
EP3384674A1 (en) | 2015-12-04 | 2018-10-10 | Telefonaktiebolaget LM Ericsson (publ) | Technique for adaptive streaming of temporally scaling media segment levels |
CN107925669B (zh) | 2016-01-28 | 2021-01-26 | 联发科技股份有限公司 | 一种消息交互的方法和提供媒体服务的*** |
US10230812B1 (en) * | 2016-01-29 | 2019-03-12 | Amazon Technologies, Inc. | Dynamic allocation of subtitle packaging |
EP4398585A2 (en) * | 2016-02-01 | 2024-07-10 | Panasonic Intellectual Property Corporation of America | Client, server, reception method and transmission method |
CN108605154B (zh) * | 2016-02-03 | 2022-02-25 | 联发科技股份有限公司 | 一种消息交互的方法和客户端设备 |
CN107040505B (zh) * | 2016-02-04 | 2021-01-26 | 中兴通讯股份有限公司 | 媒体数据传输方法及装置 |
RU2728534C2 (ru) * | 2016-02-12 | 2020-07-30 | Сони Корпорейшн | Устройство обработки информации и способ обработки информации |
CN117596232A (zh) * | 2016-05-25 | 2024-02-23 | 中兴通讯股份有限公司 | 流媒体快速启动方法、装置和*** |
US10432690B1 (en) * | 2016-06-03 | 2019-10-01 | Amazon Technologies, Inc. | Manifest partitioning |
US11089329B1 (en) * | 2016-06-28 | 2021-08-10 | Amazon Technologies, Inc | Content adaptive encoding |
JP6861484B2 (ja) * | 2016-07-25 | 2021-04-21 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム |
US11617019B2 (en) * | 2016-07-28 | 2023-03-28 | Qualcomm Incorporated | Retrieving and accessing segment chunks for media streaming |
US10567461B2 (en) * | 2016-08-04 | 2020-02-18 | Twitter, Inc. | Low-latency HTTP live streaming |
JP6752080B2 (ja) * | 2016-08-10 | 2020-09-09 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム |
US20180063220A1 (en) * | 2016-08-30 | 2018-03-01 | Citrix Systems, Inc. | Systems and methods to provide hypertext transfer protocol 2.0 optimization through multiple links |
JP2018045674A (ja) * | 2016-09-07 | 2018-03-22 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム |
WO2018047512A1 (ja) * | 2016-09-07 | 2018-03-15 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム |
JP6735644B2 (ja) * | 2016-09-20 | 2020-08-05 | キヤノン株式会社 | 情報処理装置及びその制御方法、コンピュータプログラム |
US10291682B1 (en) * | 2016-09-22 | 2019-05-14 | Juniper Networks, Inc. | Efficient transmission control protocol (TCP) reassembly for HTTP/2 streams |
KR102610480B1 (ko) * | 2016-09-26 | 2023-12-06 | 삼성전자 주식회사 | 스트리밍 서비스를 제공하는 방법 및 장치 |
KR102454470B1 (ko) * | 2016-10-06 | 2022-10-14 | 삼성전자주식회사 | 스트리밍 서비스를 지원하는 방법 및 장치 |
CN107959667B (zh) * | 2016-10-18 | 2020-10-09 | 华为技术有限公司 | 一种媒体分片的推送方法、服务器及客户端 |
WO2018129187A2 (en) * | 2017-01-05 | 2018-07-12 | Eye IO, LLC | Method, apparatus and system of http/2 media content delivery |
US11122013B2 (en) * | 2017-02-16 | 2021-09-14 | Emerald Cactus Ventures, Inc. | System and method for encrypting data interactions delineated by zones |
US11165751B2 (en) * | 2017-02-16 | 2021-11-02 | Emerald Cactus Ventures, Inc. | System and method for establishing simultaneous encrypted virtual private networks from a single computing device |
US10382313B2 (en) | 2017-02-16 | 2019-08-13 | International Business Machines Corporation | Test building for testing server operation |
US11165825B2 (en) * | 2017-02-16 | 2021-11-02 | Emerald Cactus Ventures, Inc. | System and method for creating encrypted virtual private network hotspot |
US10893315B2 (en) * | 2017-03-24 | 2021-01-12 | Sony Corporation | Content presentation system and content presentation method, and program |
US11659057B2 (en) * | 2017-04-19 | 2023-05-23 | Comcast Cable Communications, Llc | Methods and systems for content delivery using server push |
KR102307447B1 (ko) * | 2017-05-02 | 2021-09-30 | 삼성전자주식회사 | 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말 |
US11477305B2 (en) * | 2017-05-03 | 2022-10-18 | Comcast Cable Communications, Llc | Local cache bandwidth matching |
US10210648B2 (en) | 2017-05-16 | 2019-02-19 | Apple Inc. | Emojicon puppeting |
EP3896979A1 (en) * | 2017-06-02 | 2021-10-20 | Vid Scale, Inc. | 360-degree video delivery over next generation network |
CN107277558B (zh) * | 2017-06-19 | 2020-03-31 | 网宿科技股份有限公司 | 一种实现直播视频同步的播放器客户端、***及方法 |
JP6797755B2 (ja) | 2017-06-20 | 2020-12-09 | キヤノン株式会社 | 撮像装置、撮像装置の処理方法およびプログラム |
US10652166B2 (en) * | 2017-06-27 | 2020-05-12 | Cisco Technology, Inc. | Non-real time adaptive bitrate recording scheduler |
US11622020B2 (en) | 2017-08-31 | 2023-04-04 | Micro Focus Llc | Push control |
CN107656825A (zh) * | 2017-09-01 | 2018-02-02 | 上海艾融软件股份有限公司 | 消息处理方法、装置及*** |
US10461884B2 (en) | 2017-10-05 | 2019-10-29 | Comcast Cable Communications, Llc | Server selected variable bitrate streaming |
CN109756755A (zh) * | 2017-11-02 | 2019-05-14 | 华为技术有限公司 | 一种媒体播放方法,装置和*** |
KR102010414B1 (ko) * | 2017-12-13 | 2019-08-14 | 한국과학기술원 | 라이브 스트리밍을 위한 프리패칭 기반 클라우드 중계 장치 및 방법 |
JP6500132B1 (ja) * | 2018-01-15 | 2019-04-10 | ヤフー株式会社 | 情報処理装置、情報処理方法、及び情報処理プログラム |
US11321516B2 (en) * | 2018-01-19 | 2022-05-03 | Qualcomm Incorporated | Processing dynamic web content of an ISO BMFF web resource track |
CN112106335B (zh) * | 2018-04-30 | 2021-11-09 | 杜比国际公司 | 用于经由内容分发网络流式传输媒体数据的方法及*** |
US11184665B2 (en) * | 2018-10-03 | 2021-11-23 | Qualcomm Incorporated | Initialization set for network streaming of media data |
CN111193684B (zh) * | 2018-11-14 | 2021-12-21 | 北京开广信息技术有限公司 | 媒体流的实时递送方法及服务器 |
CN111371825A (zh) * | 2018-12-26 | 2020-07-03 | 深圳市优必选科技有限公司 | 一种基于http2.0协议的负载均衡方法、装置及设备 |
CN111669665B (zh) * | 2019-03-05 | 2021-12-21 | 北京开广信息技术有限公司 | 媒体流的实时推送方法及服务器 |
US11159635B2 (en) * | 2019-05-07 | 2021-10-26 | Hulu, LLC | Soft server push in video streaming |
US11523185B2 (en) | 2019-06-19 | 2022-12-06 | Koninklijke Kpn N.V. | Rendering video stream in sub-area of visible display area |
CN112148833B (zh) * | 2019-06-27 | 2023-08-08 | 百度在线网络技术(北京)有限公司 | 一种信息推送方法、服务器、终端及电子设备 |
US11343551B1 (en) * | 2019-07-23 | 2022-05-24 | Amazon Technologies, Inc. | Bandwidth estimation for video streams |
US11228626B1 (en) * | 2019-09-09 | 2022-01-18 | Facebook, Inc. | Request stream |
US11146667B2 (en) * | 2019-11-15 | 2021-10-12 | Cisco Technology, Inc. | Configurable segmentation offload |
US11444863B2 (en) | 2020-03-20 | 2022-09-13 | Harmonic, Inc. | Leveraging actual cable network usage |
CN112565464A (zh) * | 2021-01-22 | 2021-03-26 | 杭州米络星科技(集团)有限公司 | 一种文件自定义位序上传的方法 |
CN114553947B (zh) * | 2022-01-29 | 2024-01-19 | 北京金堤科技有限公司 | 一种对消息进行处理的方法及装置 |
US20230370665A1 (en) * | 2022-05-12 | 2023-11-16 | Turner Broadcasting System, Inc. | System and method for generating a live output stream manifest based on an event |
US20240020330A1 (en) * | 2022-07-18 | 2024-01-18 | Providence St. Joseph Health | Searching against attribute values of documents that are explicitly specified as part of the process of publishing the documents |
CN116684481B (zh) * | 2023-08-01 | 2023-11-21 | 国家计算机网络与信息安全管理中心 | 推送信息同质化的处理方法、装置、电子设备及存储介质 |
Family Cites Families (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7287087B1 (en) * | 1999-11-01 | 2007-10-23 | General Electric Company | Communications network for dynamic reprioritization |
EP1523154A1 (en) | 2003-10-08 | 2005-04-13 | France Telecom | System and method for offering push services to a mobile user using a push proxy which monitors the state of the mobile user equipment |
US8868772B2 (en) | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7720983B2 (en) | 2004-05-03 | 2010-05-18 | Microsoft Corporation | Fast startup for streaming media |
CN100388666C (zh) * | 2004-12-09 | 2008-05-14 | 腾讯科技(深圳)有限公司 | 一种数据传输过程的控制方法及*** |
US7607582B2 (en) | 2005-04-22 | 2009-10-27 | Microsoft Corporation | Aggregation and synchronization of nearby media |
KR101299038B1 (ko) * | 2006-01-09 | 2013-08-27 | 톰슨 라이센싱 | 멀티미디어 콘텐츠 전달 방법 및 시스템 |
US9432433B2 (en) * | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
US9380096B2 (en) | 2006-06-09 | 2016-06-28 | Qualcomm Incorporated | Enhanced block-request streaming system for handling low-latency streaming |
US8244883B2 (en) * | 2006-08-03 | 2012-08-14 | Citrix Systems, Inc. | Systems and methods of for providing multi-mode transport layer compression |
CN101179480B (zh) * | 2006-11-07 | 2010-05-12 | 中兴通讯股份有限公司 | 一种转发流媒体的方法 |
CN100492972C (zh) * | 2007-02-16 | 2009-05-27 | 陈勇 | 网络资源下载方法和装置 |
JP2009060425A (ja) * | 2007-08-31 | 2009-03-19 | Hitachi Ltd | トラフィック制御システムおよびトラフィック制御方法 |
CN101854332B (zh) * | 2009-03-30 | 2013-04-24 | 华为软件技术有限公司 | 流媒体业务的处理方法、装置及*** |
WO2010142902A1 (fr) * | 2009-06-11 | 2010-12-16 | France Telecom | Optimisation d'une communication de données, notamment pour des applications de transmission en continu de données vidéo |
US9203816B2 (en) | 2009-09-04 | 2015-12-01 | Echostar Technologies L.L.C. | Controlling access to copies of media content by a client device |
KR101750049B1 (ko) * | 2009-11-13 | 2017-06-22 | 삼성전자주식회사 | 적응적인 스트리밍 방법 및 장치 |
WO2011108893A2 (en) | 2010-03-05 | 2011-09-09 | Samsung Electronics Co., Ltd. | Method and apparatus for generating and reproducing adaptive stream based on file format, and recording medium thereof |
US9497290B2 (en) * | 2010-06-14 | 2016-11-15 | Blackberry Limited | Media presentation description delta file for HTTP streaming |
US8782268B2 (en) * | 2010-07-20 | 2014-07-15 | Microsoft Corporation | Dynamic composition of media |
KR20120010089A (ko) * | 2010-07-20 | 2012-02-02 | 삼성전자주식회사 | Http 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치 |
US9456015B2 (en) * | 2010-08-10 | 2016-09-27 | Qualcomm Incorporated | Representation groups for network streaming of coded multimedia data |
US8677428B2 (en) * | 2010-08-20 | 2014-03-18 | Disney Enterprises, Inc. | System and method for rule based dynamic server side streaming manifest files |
EP2487609A1 (en) * | 2011-02-07 | 2012-08-15 | Alcatel Lucent | A cache manager for segmented multimedia and corresponding method for cache management |
KR101617929B1 (ko) * | 2011-06-08 | 2016-05-03 | 코닌클리즈케 케이피엔 엔.브이. | 세그먼트된 콘텐츠를 위치시키고 검색하는 방법 및 시스템 |
US10320869B2 (en) | 2011-07-07 | 2019-06-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Network-capacity optimized adaptive HTTP streaming |
CN103858457B (zh) * | 2011-08-01 | 2018-11-13 | 英特尔公司 | 用于身份提供商(IdP)漫游/代理的多跳单点登录(SSO) |
US8924580B2 (en) | 2011-08-12 | 2014-12-30 | Cisco Technology, Inc. | Constant-quality rate-adaptive streaming |
EP2769578B8 (en) * | 2011-10-21 | 2023-07-12 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Radio resource management concept for transferring media content from a server to a client |
US9042247B2 (en) * | 2011-12-06 | 2015-05-26 | Wi-Lan Labs, Inc. | Systems and methods for preserving application identification information on handover in a communication network |
EP2798854B1 (en) * | 2011-12-29 | 2019-08-07 | Koninklijke KPN N.V. | Controlled streaming of segmented content |
ES2586818T3 (es) * | 2011-12-29 | 2016-10-19 | Koninklijke Kpn N.V. | Control de flujo de contenido tratado inicialmente en red |
US8874634B2 (en) | 2012-03-01 | 2014-10-28 | Motorola Mobility Llc | Managing adaptive streaming of data via a communication connection |
AU2013288859B2 (en) | 2012-07-09 | 2016-05-19 | Vid Scale, Inc. | Power aware video decoding and streaming |
WO2014117408A1 (zh) | 2013-02-04 | 2014-08-07 | 华为技术有限公司 | 流媒体数据传输的方法及装置 |
EP2999187B1 (en) | 2014-09-18 | 2017-11-15 | Alcatel Lucent | Method, computer program product and server for streaming media content from a server to a client |
-
2014
- 2014-07-11 WO PCT/EP2014/064949 patent/WO2015004276A2/en active Application Filing
- 2014-07-11 KR KR1020167003172A patent/KR101909160B1/ko active IP Right Grant
- 2014-07-11 US US14/903,989 patent/US10104190B2/en active Active
- 2014-07-11 KR KR1020187029384A patent/KR102024311B1/ko active IP Right Grant
- 2014-07-11 CN CN201811637213.XA patent/CN109842613B/zh active Active
- 2014-07-11 EP EP14737279.1A patent/EP3020208B1/en active Active
- 2014-07-11 KR KR1020197027171A patent/KR102264477B1/ko active IP Right Grant
- 2014-07-11 JP JP2016524842A patent/JP6419173B2/ja active Active
- 2014-07-11 CN CN201480050434.0A patent/CN105532013B/zh active Active
- 2014-07-11 RU RU2016104523A patent/RU2625328C1/ru active
-
2017
- 2017-07-03 RU RU2017123329A patent/RU2659041C1/ru active
-
2018
- 2018-05-29 RU RU2018119682A patent/RU2683595C1/ru active
- 2018-08-21 US US16/107,093 patent/US10728353B2/en active Active
- 2018-10-11 JP JP2018192305A patent/JP6632682B2/ja active Active
-
2019
- 2019-12-11 JP JP2019223944A patent/JP6918910B2/ja active Active
-
2020
- 2020-06-22 US US16/908,418 patent/US11375031B2/en active Active
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6632682B2 (ja) | メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム | |
JP2016531466A5 (ja) | ||
CN107211022B (zh) | 利用服务器装置的改进的客户端驱动资源推送 | |
CN112106375B (zh) | 用于视频流式传输的差异媒体呈现描述 | |
KR102262982B1 (ko) | 라이브 스트림 슬라이싱 방법, 장치 및 시스템 | |
US11477262B2 (en) | Requesting multiple chunks from a network node on the basis of a single request message | |
GB2517060A (en) | Adaptive data streaming method with push messages control | |
US10110507B2 (en) | Push-based transmission of resources and correlated network quality estimation | |
GB2516112A (en) | Methods for providing media data, method for receiving media data and corresponding devices | |
GB2575189A (en) | Adaptive client-driven push of resources by a server device | |
GB2551674A (en) | Adaptive data streaming method with push messages control |