図面 (/)

技術 メディアデータの提供方法、メディアデータの受信方法、及びプログラム

出願人 キヤノン株式会社
発明者 ユアンファブレロマンベルソールフレデリックマゼナエルウエドラオゴフランクドゥヌアルエルヴェルーラン
出願日 2019年12月11日 (11ヶ月経過) 出願番号 2019-223944
公開日 2020年3月26日 (8ヶ月経過) 公開番号 2020-047303
状態 未査定
技術分野 計算機間の情報転送 双方向TV,動画像配信等
主要キーワード テンプレートパラメータ 各時間セグメント 基準セグメント 画面停止 プッシング セグメント属性 ストリームフロー コード化形式
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年3月26日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

DASHベース通信との関連においてデータストリーミング強化する。

解決手段

サーバは、クライアントとの間で共有された情報に基づいて、クライアントへプッシュすべき1つ以上のメディアデータセグメント識別し、該データをクライアントへプッシュする意図があることを通知する。サーバがクライアントからキャンセルリクエストを受信すると、前記識別されたデータのクライアントへのプッシュをキャンセルする。

概要

背景

HTTPメディアストリーミングの一般的原理は、図3に示される。適応型HTTPメディアストリーミングのための新たなプロトコルおよび標準のほとんどは、この原理に基づく。

メディアサーバ300は、クライアント310に対してデータをストリーミングする。メディアサーバは、メディアプレゼンテーションを保存する。例えば、メディアプレゼンテーション301は、オーディオデータおよびビデオデータを含む。オーディオおよびビデオは、同じファイル内でインターリーブされてもよい。メディアプレゼンテーションが構築される方法は、図4aを参照しながら以下に記載される。メディアプレゼンテーションは、独立してアドレス指定されてダウンロードされることができるMP4セグメントなどの、小さな独立した連続する時間セグメント302a、302bおよび302cに一時的に分割される。これらの時間セグメントの各々のためのメディアコンテンツダウンロードアドレス(HTTPURL)は、クライアントに対してサーバによって設定される。オーディオ/ビデオメディアコンテンツ各時間セグメントは、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/AVCSVC、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」。

ビデオに関連するアダプテーションセット503は、6つのリプレゼンテーションを含む。これらのリプレゼンテーションは、異なる空間解像度(320×240、640×480、1280×720)、および異なるビットレート(256000〜2048000ビット/秒)のビデオを含む。これらのリプレゼンテーションの各々に対して、それぞれのURLは、BaseURL要素を通じて関連づけられる。そのため、クライアントは、推定された帯域幅スクリーン解像度などの異なる基準にしたがって同じビデオのこれらの代替リプレゼンテーションの間で選択することができる。(図5において、時間セグメントへのRepresentationの分解は、明瞭にするために図示されていない、ということに留意されたい。)
図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」は、HTTPGET要求を実行するためにクライアントが用いることができる完全な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に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク(モバイルネットワーク)上の、ウェブページの低速表示をもたらすであろう。

所定のウェブページに対する要求を受信するとき、サーバは、他のどのリソースが要求されたリソースの完全な処理のために必要とされるのかを知っているであろう。要求されたリソースおよびリンクされたリソースを同時に送信することによって、サーバは、ウェブページのロード時間を減少させることを可能にする。このように、プッシュ機能を用いて、サーバは、所定のリソースが要求されたときに、追加リソースリプレゼンテーションを送信してもよい。

図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は、クライアントがストリーミングをリードするという前提に基づくように思われる。例えば、クライアントは、そのフォームファクタおよびスクリーン解像度に基づいて高解像度または小解像度のコンテンツを要求するべきかどうかを認識していてもよい。

概要

DASHベースの通信との関連においてデータストリーミング強化する。サーバは、クライアントとの間で共有された情報に基づいて、クライアントへプッシュすべき1つ以上のメディアデータセグメントを識別し、該データをクライアントへプッシュする意があることを通知する。サーバがクライアントからキャンセルリクエストを受信すると、前記識別されたデータのクライアントへのプッシュをキャンセルする。 e

目的

MPDファイルは、クライアント装置がメディアコンテンツの配信を要求し制御することを可能にする情報を、クライアント装置に提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

サーバによるクライアントへのメディアデータの提供方法であって、前記サーバにおいて、前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき1つ以上のメディアデータセグメント識別する識別工程と、前記サーバによって、前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知工程と、前記サーバにおいて、前記クライアントからのキャンセルリクエストの受信に応答して、前記識別工程において識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル工程と、を有することを特徴とする提供方法。

請求項2

前記通知工程における通知は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項1記載の提供方法。

請求項3

前記通知工程における通知は、HTTP/2によって定義されたPUSH_PROMISEフレームであることを特徴とする請求項1記載の提供方法。

請求項4

前記通知工程における通知は、ウェブソケットによって定義されたメッセージであることを特徴とする請求項1記載の提供方法。

請求項5

前記識別工程は、前記クライアントからの所定のリクエストを受信したことに応じて実行されることを特徴とする請求項1乃至4の何れか一項に記載の提供方法。

請求項6

前記所定のリクエストは、MPD(MediaPresentationDescription)を要求するリクエストであることを特徴とする請求項5記載の提供方法。

請求項7

前記所定のリクエストは、所定の期間のメディアデータに対応するメディアセグメントを要求するリクエストであることを特徴とする請求項5記載の提供方法。

請求項8

前記識別工程によって識別された一つ以上のメディアデータセグメントは、前記通知工程において前記クライアントに通知されることを特徴とする請求項1乃至7の何れか一項に記載の提供方法。

請求項9

前記キャンセルリクエストは、HTTP/2によって定義されたRSTSTREAMフレームであることを特徴とする請求項1乃至8の何れか一項に記載の提供方法。

請求項10

前記キャンセルリクエストは、前記識別工程において識別されたデータをプッシュするために確立されたストリーム識別情報を含むことを特徴とする請求項1乃至9の何れか一項に記載の提供方法。

請求項11

クライアントによるサーバからのメディアデータの受信方法であって、前記サーバからクライアントへプッシュすべきデータを決定するための情報を、前記サーバとクライアントとの間で共有する共有工程と、前記クライアントにおいて、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを示す通知を受信する受信工程と、前記クライアントにおいて、前記サーバからクライアントへのデータのプッシュをキャンセルするかどうか判定する判定工程と、前記判定工程における判定結果に従って、前記データのプッシュのキャンセルを要求するキャンセルリクエストを、前記クライアントからサーバへ送信する送信工程と、を有することを特徴とする受信方法。

請求項12

前記受信工程によって受信される通知は、確認応答メッセージであることを特徴とする請求項11記載の受信方法。

請求項13

前記受信工程によって受信される通知は、HTTP/2によって定義されたPUSH_PROMISEフレームであることを特徴とする請求項11記載の受信方法。

請求項14

一つ以上のメディアデータセグメントが前記受信工程によって受信される通知によって通知されることを特徴とする請求項11記載の受信方法。

請求項15

前記キャンセルリクエストは、HTTP/2によって定義されたRST_STREAMフレームであることを特徴とする請求項11乃至14の何れか一項に記載の受信方法。

請求項16

クライアントへのメディアデータを提供するサーバであって、前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき1つ以上のメディアデータセグメントを識別する識別手段と、前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知手段と、前記クライアントからのキャンセルリクエストの受信に応答して、前記識別手段によって識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル手段と、を有することを特徴とするサーバ。

請求項17

前記通知手段による通知は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項16記載のサーバ。

請求項18

前記通知手段による通知は、HTTP/2によって定義されたPUSH_PROMISEフレームであることを特徴とする請求項16記載のサーバ。

請求項19

サーバからメディアデータを受信するクライアントであって、前記サーバからクライアントへプッシュすべきデータを決定するための情報を、前記サーバとクライアントとの間で共有する共有手段と、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを示す通知を受信する受信手段と、前記サーバからクライアントへのデータのプッシュをキャンセルするかどうか判定する判定手段と、前記判定手段による判定結果に従って、前記データのプッシュのキャンセルを要求するキャンセルリクエストを、前記サーバへ送信する送信手段と、を有することを特徴とするクライアント。

請求項20

前記受信手段によって受信される通知は、確認応答メッセージであることを特徴とする請求項19記載のクライアント。

請求項21

前記受信手段によって受信される通知は、HTTP/2によって定義されたPUSH_PROMISEフレームであることを特徴とする請求項19記載のクライアント。

請求項22

コンピュータに、請求項16乃至21の何れか一項に記載の各手段を実行させるためのプログラム

関連出願の相互参照

0001

本出願は、英国特許出願第1312547.1号および第1312561.2号(ともに2013年7月12日)、並びに第1410540.7号(2014年6月12日)からの優先権を主張し、それらは参考文献としてすべて本明細書に援用される。

技術分野

0003

特に、本発明はネットワーク制約を満たすための適応型データストリーミングに関する。本発明は、DASHネットワークにおけるアプリケーションを有してもよい。

0004

DASH(Dynamic Adaptive Streaming overHTTP(動的適応型HTTPストリーミング)の頭文字)は、HTTP上のメディアコンテンツストリーミング(通常はオーディオビデオコンテンツ)を可能にする通信規格である。DASHによれば、メディアプレゼンテーションは、「メディアプレゼンテーション記述ファイル(以下において、MPD)と呼ばれるXMLファイルとして記載される。MPDファイルは、クライアント装置がメディアコンテンツの配信を要求し制御することを可能にする情報を、クライアント装置に提供する。

背景技術

0005

HTTPメディアストリーミングの一般的原理は、図3に示される。適応型HTTPメディアストリーミングのための新たなプロトコルおよび標準のほとんどは、この原理に基づく。

0006

メディアサーバ300は、クライアント310に対してデータをストリーミングする。メディアサーバは、メディアプレゼンテーションを保存する。例えば、メディアプレゼンテーション301は、オーディオデータおよびビデオデータを含む。オーディオおよびビデオは、同じファイル内でインターリーブされてもよい。メディアプレゼンテーションが構築される方法は、図4aを参照しながら以下に記載される。メディアプレゼンテーションは、独立してアドレス指定されてダウンロードされることができるMP4セグメントなどの、小さな独立した連続する時間セグメント302a、302bおよび302cに一時的に分割される。これらの時間セグメントの各々のためのメディアコンテンツのダウンロードアドレス(HTTPURL)は、クライアントに対してサーバによって設定される。オーディオ/ビデオメディアコンテンツ各時間セグメントは、1つのHTTPアドレスに関連づけられている。

0007

メディアサーバは、また、メディアコンテンツ特性(例えば、メディアのタイプ:オーディオ、ビデオ、オーディオビデオ、テキストなど)、コード化形式(例えば、ビットレートタイミング情報など)、時間メディアセグメントと関連するURLとのリストを含むメディアプレゼンテーションのコンテンツを記述する(図5を参照ながら以下に記載される)マニフェストファイルドキュメント304を保存する。または、ドキュメントは、時間メディアセグメント及び関連するURLとの明示的なリストを再構築可能にするテンプレート情報を含む。このドキュメントは、エクステンブルマークアップランゲージ(XML)を用いて記載されてもよい。

0008

マニフェストファイルは、クライアントに対して送信される。ステップ305の間にマニフェストファイルの受信をすると、クライアントには、メディアコンテンツの時間セグメントとHTTPアドレスとの間の関連づけが通知される。また、マニフェストファイルは、メディアプレゼンテーションのコンテンツに関する情報(本例にではインターリーブされたオーディオ/ビデオ)をクライアントに提供する。情報は、解像度、ビットレートなどを含んでもよい。

0009

受信された情報に基づいて、クライアントのHTTPクライアントモジュール311は、マニフェストファイル内に記載されたメディアコンテンツの時間セグメントのダウンロードのためにHTTP要求306を発行することができる。サーバのHTTP応答307は、要求された時間セグメントを伝達する。HTTPクライアントモジュール311は、応答から時間メディアセグメントを抽出し、メディアエンジン312の入力バッファ307に対してそれらを提供する。最終的に、メディアセグメントは、ステップ308および309のそれぞれの間に復号されて表示されることができる。

0010

メディアエンジン312は、次の時間セグメントが適切な時期に発行されるように要求するために、DASH制御エンジン313と情報のやりとりをする。次のセグメントは、マニフェストファイルから識別される。要求が発行される時期は、受信バッファ307が満杯であるか否かに依存する。DASH制御エンジン313は、バッファ過負荷になるかまたは完全に空になるのを防ぐようにバッファを制御する。

0011

メディアプレゼンテーションおよびマニフェストファイルの生成を、図4aを参照して説明する。ステップ400および401の間に、オーディオデータおよびビデオデータが取得される。次に、オーディオデータは、402の間に圧縮される。例えば、MP3規格を用いることができる。また、ビデオデータは、ステップ403の間に並行して圧縮される。MPEG4、MPEG/AVCSVC、HEVC、またはスケーラブルHEVCなどのビデオ圧縮アルゴリズムを用いることができる。オーディオデータおよびビデオデータの圧縮が一旦実行されれば、オーディオビデオエレメンタリーストリーム404およびビデオエレメンタリーストリーム405は、利用可能になる。エレメンタリストリームは、ステップ406の間に、グローバルメディアプレゼンテーションにカプセル化される。例えば、ISO BMFF規格(またはISO BMFF規格をAVC、SVC、HEVC、HEVCのスケーラブル拡張などに拡張する)は、符号化されたオーディオエレメンタリーストリームおよびビデオエレメンタリーストリームのコンテンツをグローバルメディアプレゼンテーションとして記述するために使用することができる。それによって取得されたカプセル化されたメディアプレゼンテーション407は、ステップ408の間に、XMLマニフェストファイル409を生成するために用いられる。ビデオデータ401およびオーディオデータ400のいくつかのリプレゼンテーションは、取得され、圧縮され、カプセル化され、メディアプレゼンテーション407内に記載することができる。

0012

図4bに示されたMPEG/DASHストリーミングプロトコルの特定のケースに関して、マニフェストファイルは、「メディアプレゼンテーション記述」(または「MPD」ファイル)と呼ばれる。ファイルのルート要素は、プロファイルまたはスキーマのようなDASH情報を加えたすべてのプレゼンテーションに適用する属性を含むMPD要素である。メディアプレゼンテーションは、Period要素によって表される時間的期間に分割される。MPDファイル410は、各時間的期間に関連するデータをすべて含む。この情報を受信することによって、クライアントは、各々の期間ごとのコンテンツを認識する。Period411ごとに、AdaptationSet(アダプテーションセット)要素が定義される。

0013

可能な構成は、プレゼンテーション内に含まれるメディアタイプ当たり1つ以上のAdaptationSetを有することである。ビデオに関連するAdaptationSet412は、サーバにおいて利用可能な符号化されたビデオの異なる可能的なリプレゼンテーションに関する情報を含む。各リプレゼンテーションは、Representation要素内に記述される。例えば、第1のリプレゼンテーションは、640×480の空間解像度で符号化され、且つ500kビット/秒のビットレートで圧縮されたビデオになり得る。第2のリプレゼンテーションは、同じビデオになり得るが、250kビット/秒のビットレートで圧縮され得る。

0014

クライアントが各ビデオに関するHTTPアドレスを知っている場合、各ビデオは、その後、HTTP要求によってダウンロードすることができる。各リプレゼンテーションのコンテンツとHTTPアドレスとの間の関連づけは、付加的なレベルの記述:時間セグメントを用いることによって行われる。各ビデオリプレゼンテーションは、時間セグメント413(通常は数秒)に分割される。各時間セグメントは、HTTPアドレス(URLまたは1バイトレンジのURL)を介してアクセス可能なサーバに保存されたコンテンツを備える。いくつかの要素は、MPDファイル:SegmentList(セグメントリスト)、SegmentBase(セグメントベース)またはSegmentTemplate(セグメントテンプレート)内に時間セグメントを記述するために用いることができる。

0015

さらに、特定のセグメント:イニシャライゼーションセグメントが利用可能である。イニシャライゼーションセグメントは、(ISO BMFFまたはその拡張を用いてビデオがカプセル化されているならば)カプセル化されたビデオストリームを記述するMP4イニシャライゼーション情報を含む。例えば、それは、クライアントがビデオに関する復号アルゴリズムインスタンス化するのを支援する。

0016

イニシャライゼーションセグメントおよびメディアセグメントのHTTPアドレスは、MPDファイル内に示される。

0017

図5に、例示的なMPDファイルが示される。2つのメディアが、図示されたMPDファイル内に記述される。第1のものは英語オーディオストリームであり、第2のものはビデオストリームである。英語のオーディオストリームは、AdaptationSetタグ500を用いて導入される。2つの代替的リプレゼンテーションが、このオーディオストリームのために利用可能である。

0018

・第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」に対して、英語のオーディオストリームを要求することができる。

0019

・第2のリプレゼンテーション502は、32000ビット/秒のビットレートでMP4にカプセル化されたエレメンタリオーディオストリームである。第1のリプレゼンテーション501と同じような説明を行うことができ、クライアント装置は、したがって、以下のアドレスのいずれか1つにおける要求によって、この第2のリプレゼンテーション502を要求することができる。

0020

「http://cdn1.example.com/3463646346.mp4」または
「http://cdn2.example.com/3463646346.mp4」。

0021

ビデオに関連するアダプテーションセット503は、6つのリプレゼンテーションを含む。これらのリプレゼンテーションは、異なる空間解像度(320×240、640×480、1280×720)、および異なるビットレート(256000〜2048000ビット/秒)のビデオを含む。これらのリプレゼンテーションの各々に対して、それぞれのURLは、BaseURL要素を通じて関連づけられる。そのため、クライアントは、推定された帯域幅スクリーン解像度などの異なる基準にしたがって同じビデオのこれらの代替リプレゼンテーションの間で選択することができる。(図5において、時間セグメントへのRepresentationの分解は、明瞭にするために図示されていない、ということに留意されたい。)
図5aは、DASHクライアントの標準的挙動(standard behavior)を示す。図5bは、図4aに示された方法において用いられる、例示的なマニフェストファイル(記述ファイルまたはMPD)のツリー表現を示す。

0022

ストリーミングセッションを開始する場合、DASHクライアントは、マニフェストファイルを要求することによって開始する(ステップ550)。サーバの応答を待ってマニフェストファイルを受信した後(ステップ551)、クライアントは、マニフェストファイルを解析し(ステップ552)、その環境に適したAdaptationSetsのセットASijを選択し(ステップ553)、それから、例えば、その帯域幅、復号化、およびレンダリング機能に適したMPD内のRepresentationを各AdaptationSet ASij内で選択する(ステップ554)。

0023

そして、DASHクライアントは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求するセグメントのリストを予め構築することができる。このイニシャライゼーションセグメントは、それが複数のリプレゼンテーション、アダプテーションセットおよび期間に共通になり得るか、または各Representationに特有になり得るか、または第1のメディアセグメント内にも含まれ得るので、このMPD(ステップ555)内で、識別されなければならない。

0024

そして、クライアントは、イニシャライゼーションセグメントを要求する(ステップ556)。一旦イニシャライゼーションセグメントが受信されると(ステップ557)、復号器が起動される(ステップ558)。

0025

そして、クライアントはセグメント単位で第1のメディアデータを要求し(ステップ560)、復号化を実際に開始して表示する(ステップ563)前に、(ステップ559の条件のために)最小データ量をバッファする。MPDダウンロードと最初に表示されたフレームとの間のこれら複数の要求/応答は、ストリーミングセッションにおける起動遅延(startup delay)を招く。これらの初期ステップの後、DASHストリーミングセッションは、標準的方法で継続する、すなわち、DASHクライアントは、メディアセグメントを順々に適応させてリクエストする。

0026

現在のDASHバージョンは、マニフェストファイル内部の関心領域の記述を提供しない。いくつかのアプローチが、このような記述のために、提案されてきた。

0027

特に、メディアコンテンツのコンポーネントは、SubRepresentation(サブリプレゼンテーション)要素を用いて記載することができる。これらの要素は、リプレゼンテーション内に埋め込まれる1つまたはいくつかのコンポーネントのプロパティを記述する。図6に、タイルトラック(tile tracks)をビデオのコンポーネントとして記述するDASHマニフェストファイルの例が示される。簡明に且つおよび明瞭にするために、1つのPeriod600のみを示す。しかしながら、後続期間要素は、同じ方式で編成されるだろう。部分601において、第1のアダプテーションセット要素は、スケーラブルビデオベース層を記述するために用いられる。例えば、ビデオは、SVCまたはスケーラブルなHEVCにしたがって符号化される。部分602において、第2のアダプテーションセットはスケーラブルビデオの最高解像度層を記述するために用いられる。非スケーラブルビデオに対して、第2のアダプテーションセット602のみが、ベース層に依存することなく(すなわちdependencyld属性)、存在するだろう。この第2のアダプテーションセット602において、単一のリプレゼンテーション603、すなわち表示することができるビデオに対応するもの、が記述される。そのリプレゼンテーションは、クライアント要求のためのそれぞれのURLとともにセグメント610のリストとして記載される。

0028

このように、リプレゼンテーションは、「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」は、HTTPGET要求を実行するためにクライアントが用いることができる完全なURLを提供する。この要求により、クライアントは、複合トラックのためのデータと、すべてのタイルトラックのためのすべてのデータとを得るだろう。要求の代わりに、伝送を最適化するために、クライアントは、index_range属性620からの利用可能なデータを用いて、セグメントインデックス情報(通常は、当業者により周知のISO BMFF内の「sidx」情報および/または「ssix」)を第1に要求することができる。このインデックス情報は、コンポーネントの各々のためのバイト単位の範囲を決定することを可能にする。そして、DASHクライアントは、適切なバイト単位の範囲で、(要求された複合トラックを含む)選択されたトラックと同数のHTTP GET要求を送信することができる。

0029

ストリーミングセッションを開始するとき、DASHクライアントは、マニフェストファイルを要求する。一旦受信されれば、クライアントは、マニフェストファイルを解析し、その環境に適した1セットのAdaptationSetを選択する。次に、クライアントは、各AdaptationSet内部のMPDにおいて、その帯域幅と互換性をもつRepresentation、復号化およびレンダリング機能を選択する。次に、それは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求されるセグメントのリストを予め構築する。イニシャライゼーション情報が復号器によって受信されると、それらはイニシャライズされ、クライアントは、第1のメディアデータを要求し、ディスプレイを実際に開始する前に最小データ量をバッファする。

0030

これらの複数の要求/応答は、ストリーミングセッションの起動における遅延を招くかもしれない。サービスプロバイダにとってのリスクは、ビデオを見始めることなくサービスを離れるクライアント見ることである。クライアントによって実行される第1のメディアデータチャンクのための初期のHTTP要求とメディアデータチャンクが実際に再生し始める時間との間の時間を、スタートアップ遅れとよぶことが一般的である。それは、ネットワークラウンドトリップ時間だけでなく、メディアセグメントのサイズにも依存する。

0031

サーバプッシュは、ウェブリソースローディング時間を減少させるために有用な機能である。このようなサーバは、図1a図1eを参照しながら論じる。

0032

図1bでは、HTTP/2交換(HTTP/2 exchanges)において、要求は、必要とされるリソース:(図1aに示されるように)リソースR1〜R4およびサブリソースA〜Iごとに送信されなければならない、ということが図示される。しかしながら、サーバによるプッシュ機能を用いるとき、図1cに図示されるように、要求の数は、要素R1〜R4に制限される。要素A〜Iは、図1aに示される依存性に基づいてサーバによってクライアントに対して「プッシュされ」、それによって、不必要な関連する要求が生じる。

0033

このように、サーバがプッシュ機能を用いる場合、図1bおよび図1cに図示されるように、そのサブリソースと共にリソースをロードするために必要なHTTPラウンドトリップ(要求+応答)の数が減少される。これは、モバイルネットワークなどの高待ち時間のネットワークにとって、とりわけ興味深い。

0034

HTTPは、ウェブリソース、通常はウェブページ、を送信するために用いられるプロトコルである。HTTPは、クライアントとサーバとを暗に含む。

0035

・クライアントは、サーバに対して要求を送信する。

0036

・サーバは、クライアントの要求に対して、ウェブリソースのリプレゼンテーションを含む応答により返答する。

0037

要求および応答は、様々な部分、特にHTTPヘッダ、を含むメッセージである。HTTPヘッダは、値と共に名称を備える。例えば「Host: en.wikipedia.org」は「Host(ホスト)」ヘッダであり、その値は「en.wikipedia.org」である。それは、問い合わされたリソースのホストを示すために用いられる(例えばHTTPを記述するウィキディページは、http://en.wikipedia.org/wiki/HTTPにおいて利用可能である)。HTTPヘッダは、クライアント要求およびサーバ応答上に出現する。

0038

HTTP/2は、ストリームを通じて要求/応答を交換することを可能にする。ストリームは、HTTP要求および応答ごとにHTTP/2接続の内部で生成される。フレームは、要求および応答のコンテンツおよびヘッダを伝達するために、ストリーム内で交換される。

0039

HTTP/2は、以下のような、個別の意味をもつフレームの制限されたセットを定義する。
HEADERS:HTTPヘッダの伝送のために提供される
DATA:HTTPメッセージコンテンツの伝送のために提供される
・PUSH_PROMISE:プッシュされたコンテンツのアナウンスのために提供される
・PRIORITY:ストリームのプライオリティを設定するために提供される
・WINDOW UPDATE:制御フローウィンドウの値を更新するために提供される・SETTINGS:設定パラメータを伝達するために提供される
・CONTINUATION:ヘッダブロックフラグメントシーケンスを継続するために提供される
・RST STREAM:ストリームの終了またはキャンセルのために提供される
サーバによるプッシュは、サーバがクライアントに対して自発的なウェブリソースリプレゼンテーションを送信することを可能にするために、HTTP/2に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク(モバイルネットワーク)上の、ウェブページの低速表示をもたらすであろう。

0040

所定のウェブページに対する要求を受信するとき、サーバは、他のどのリソースが要求されたリソースの完全な処理のために必要とされるのかを知っているであろう。要求されたリソースおよびリンクされたリソースを同時に送信することによって、サーバは、ウェブページのロード時間を減少させることを可能にする。このように、プッシュ機能を用いて、サーバは、所定のリソースが要求されたときに、追加リソースリプレゼンテーションを送信してもよい。

0041

図1eフローチャートを参照して、プッシュ機能を実行するサーバの例示的なオペレーションモードを記述する。

0042

ステップ100の間、サーバは、初期要求を受信する。次に、サーバは、ステップ101の間に応答の一部としてプッシュするリソースを識別し、ステップ102の間にコンテンツ応答を送信し始める。並行して、サーバは、ステップ103の間にクライアントに対してプッシュプロミスメッセージを送信する。これらのメッセージは、例えば図1aに示される依存性に基づいて、サーバがプッシュすることを意図している他のリソースを識別する。これらのメッセージは、どのプッシュされたリソースが送信されることになるのかをクライアントに予め知らせるために送信される。特に、これは、同時にプッシュされた、またはプッシュされようとしている、リソースに対して、クライアントが要求を送信する、というリスクを低減する。このリスクをさらに低減するために、サーバは、プッシュプロミス内に記述されるリソースを参照する応答のあらゆる部分を送信する前に、プッシュプロミスメッセージを送信するべきである。これは、また、クライアントがそれらのリソースを望まないならば、クライアントがプロミスされたリソース(promised resources)のプッシュのキャンセルを要求することを可能にする。次に、サーバは、ステップ104の間に、応答およびすべてのプロミスされたリソースを送信する。プロセスは、ステップ105の間に終了する。

0043

図1dのフローチャートは、クライアント側の処理を示す。

0044

クライアントがサーバから取り出すリソースを識別すると、対応するデータが既にそのキャッシュメモリ内にあるか否かを、ステップ106の間にまずチェックする。リソースが既にキャッシュメモリ内にある場合(はい(Yes))、ステップ107の間に、そこから取り出される。キャッシュされたデータは、先の要求から取りだされたデータ、またはサーバによって予めプッシュされたデータのいずれかであろう。それがキャッシュメモリ内になかった場合(いいえ(No))、クライアントは、ステップ108の間に、要求を送信し、サーバの応答を待つ。サーバからのフレームを受信すると、クライアントは、フレームがプッシュプロミスに対応するか否かを、ステップ109の間にチェックする。データフレームがプッシュプロミスに対応するならば(はい(Yes))、ステップ110の間、クライアントは、プッシュプロミスを処理する。クライアントは、プッシュされるリソースを識別する。クライアントがリソースを受信したくなければ、クライアントは、エラーメッセージをサーバに対して送信してもよく、そうすれば、サーバは、そのリソースをプッシュしない。そうでなければ、クライアントは、対応するプッシュコンテンツを受信するまでプッシュプロミスを保存する。サーバがそれをプッシュしている間に、クライアントがプロミスされたリソースを要求しないように、プッシュプロミスが用いられる。データフレームがプッシュプロミスに対応しない場合(いいえ(No))、ステップ111の間に、フレームがプッシュデータに関連するデータフレームであるか否かがチェックされる。それがプッシュデータに関する場合(はい(Yes))、クライアントは、ステップ112の間に、プッシュされたデータを処理する。プッシュされたデータは、クライアントのキャッシュ内に保存される。フレームがプッシュデータに関するデータフレームではない場合(いいえ(No))、ステップ113の間に、サーバから受信された応答にそれが対応するか否かがチェックされる。フレームがサーバからの応答に対応する場合(はい(Yes))、応答は、ステップ114の間に処理される(例えば、アプリケーションに対して送信される)。そうでなければ(いいえ(No))、フレームが応答の終了を識別するか否か(はい(Yes))が、ステップ115の間にチェックされる。この場合、処理は、ステップ116の間に終了する。そうでなければ、処理は、ステップ109に戻る。

0045

このように、クライアントが応答およびプロミスされたリソースを受信する、ということが思われる。そのため、取りだされたウェブページを表示するブラウザなどのアプリケーションによって応答が用いられる間に、プロミスされたリソースは、一般的には、クライアントのキャッシュ内に保存される。クライアントアプリケーションがプッシュされたリソースの1つを要求するとき、リソースは、いかなるネットワーク遅延も引き起こさずに、クライアントのキャッシュから直ちに取りだされる。

0046

キャッシュ内のプッシュされたリソースの保存は、キャッシュ制御指示を用いて制御される。キャッシュ制御指示は、また、応答の制御のために用いられる。これらの指示は、特に、プロキシに対して適用可能であり、プッシュされた若しくはプッシュされない任意のリソースは、プロキシ若しくはクライアントのみによって保存されてもよい。

0047

図1aは、それらの関連性とともにサーバによって所有された1セットのリソースのグラフである。リソースのセットは、以下のように関連し合う。すなわち、R1、R2、R3、およびR4は、クライアントによって適切に処理されるために一緒にダウンロードされる必要のあるリソースである。さらに、サブリソースA〜Hが定義される。これらのサブリソースは、1つ、2つ、または3つのリソースに関連する。例えば、Aは、R1に対してリンクされ、Cは、R1、R2、およびR4に対してリンクされる。

0048

既に上述した図1bは、サーバPUSH機能を用いないHTTP交換を示しており、クライアントは、R1を要求し、次にR2、A、B、C、およびDを発見し、それらを要求する。それらを受信した後、クライアントは、R3、R4、F、およびGを要求する。最終的に、クライアントは、HおよびIのサブリソースを要求する。これは、リソースの全体のセットを検索するために4つのラウンドトリップを必要とする。

0049

既に上述した図1cは、サーバによって直接的に接続されるサブリソースをプッシュする機能を用いたHTTP交換を示す。R1を要求した後、サーバは、R1を送信し、A、B、C、およびDをプッシュする。クライアントは、R2を識別し、それを要求する。サーバは、R2を送信し、FおよびGをプッシュする。最終的に、クライアントは、R3、R4を識別し、これらのリソースを要求する。サーバは、R3、R4を送信し、HおよびIをプッシュする。これは、リソースの全体のセットを取りだすために3つのラウンドトリップを必要とする。

0050

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に対する要求を受信し、その順序に従ってこれらの要求を処理する。そして、クライアントは、その順序で、これらのリソースを取りだす。

0051

HTTPプライオリティは、どの要求がより重要であり且つ他の要求より早く処理されるべきであるかを、クライアントに明示することを可能にする。特定のプライオリティの使用を、交換202に示す。Java(登録商標)Scriptファイルは、最も高いプライオリティを割り当てられる。CSSおよびHTMLファイルは、中プライオリティを割り当てられ、画像は、低プライオリティを割り当てられる。このアプローチにより、ブロッキングファイル、または他のファイルより早く他のリソースに対する参照を含むことができるファイルを受信することができる。これを受けて、交換202に記述されるように、サーバは、まずJava(登録商標)Scriptファイル、その後CSSおよびHTMLファイル、最後には画像を、送信することを試みることが期待される。サーバは、クライアントプライオリティに従うようには義務付けられていない。

0052

プライオリティに加えて、HTTP/2は、同時に交換されるデータ量を制御することができる、ということを提供する。クライアントおよびサーバは、接続ベース当たりおよびストリームベース当たりのバッファリングすることができるデータ量を指定することができる。これは、TCP輻輳制御と同様であり、利用可能なバッファサイズを指定するウィンドウサイズは、所定の値にイニシャライズされ、エミッタがデータを送信するたびに、ウィンドウサイズは減少し、エミッタは、ウィンドウサイズが0より下にならないようにデータの送信を停止しなければならない。受信器は、データを受信し、データがバッファから受信され取り出されたということを通知するメッセージを送信し、メッセージは、バッファから取り出されたデータ量を含んでおり、そして、ウィンドウサイズが所定の値から増加され、エミッタは、データを送信することを再開することができる。

0053

上記を考慮すると、クライアントは実行しているアプリケーションの目的のためにコンテンツのベストのリプレゼンテーションを一般的には選択することができるので、DASHは、クライアントがストリーミングをリードするという前提に基づくように思われる。例えば、クライアントは、そのフォームファクタおよびスクリーン解像度に基づいて高解像度または小解像度のコンテンツを要求するべきかどうかを認識していてもよい。

発明が解決しようとする課題

0054

サーバベースのストリーミングは、通常は、RTPを用いて実行される。DASHとは対照的に、RTPは、HTTPを用いず、ウェブインフラストラクチャ、特にプロキシ、キャッシュから直接的に恩恵を受けることができない。ウェブソケットベースのメディアストリーミングは、同じ短所を持つ。HTTP/1.1では、サーバがクライアント要求に対して一般的には答えることしかできないので、サーバベースのストリーミングは、容易に実行することができない。HTTP/2では、特にプッシュ機能の導入では、DASHベースのサーバは、ストリーミングを通すことができる。このように、サーバは、ユーザエクスペリエンスを最適化するために、ストリーミングしているコンテンツの特性のサーバの知識を用いることができる。例えば、サーバは、広告は付加的な限定的な量の帯域幅を利用するのでアドバーティスメントをHDとしてプッシュすることを除けばフィルムをSDとして(制限された帯域幅のために)プッシュするかもしれない。別の例は、低解像度ビデオでの高速起動を実行し始め、且つ一旦帯域幅が十分に推定されれば可能な限りベストのリプレゼンテーションに切り替える、サーバのケースである。

0055

サーバがストリーミングを通すことを可能にするために、1つのアプローチは、サーバに好ましくはデータ(特にDASHデータ)をプッシュさせることである。そして、クライアントは、ビデオを表示するのに利用することができるいかなるデータも用いる。サーバは、通常は、一度にいくつかのセグメントのプッシュをアナウンスする。そして、サーバは、並行してまたは連続的にセグメントを送信する。

0056

発生する問題は、クライアントとサーバはプロミスされたデータが望まれる時間に送られ、受信されるかどうか、わからないかもしれないことである:クライアントは、ビデオセグメントが、いつ、どの順序で送信されることになるのかをわからないかもしれない。

0057

また、サーバによってプッシュまたはアナウンスされた、プロミスされたデータは、クライアントのニーズミスマッチするかもしれず、それにより、サーバエンドにおいて特にリソースを無駄にすることになる。

0058

このように、特に、DASHベースの通信との関連においてデータストリーミングを強化する必要性がある。

課題を解決するための手段

0059

上記の課題を解決するために、本発明のメディアデータの提供方法は、例えば、以下の構成を有する。すなわち、サーバによるクライアントへのメディアデータの提供方法であって、前記サーバにおいて、前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき1つ以上のメディアデータセグメントを識別する識別工程と、前記サーバによって、前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知工程と、前記サーバにおいて、前記クライアントからのキャンセルリクエストの受信に応答して、前記識別工程において識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル工程と、を有する。

0060

本発明の他の機能および効果は、図1〜図6に加えて、添付された以下の図面を参照しながら、非限定的な好ましい実施形態の以下の記述から明らかになる。

図面の簡単な説明

0061

サーバによってプッシュされる要素の依存性を図示する。
プッシュ機能HTTP/2交換の例を図示する。
プッシュ機能を用いたHTTP交換の例を図示する。
クライアント側の処理のフローチャートを図示する。
サーバ側の処理のフローチャートを図示する。
サーバ・クライアント間のHTTP/2交換の例を図示する。
HTTPメディアストリーミングの概略的原理を図示する。
メディアプレゼンテーションおよびマニフェストファイルの生成例を図示する。
マニフェストファイル例を図示する。
MPDファイル例を図示する。
DASHクライアントの標準的挙動例を図示する。
マニフェストファイルのツリー表現例を図示する。
DASHマニフェストファイル例を図示する
実施形態にかかる、順序付けされたメディアセグメントを図示する。
実施形態にかかる、順序付けされたメディアセグメントを図示する。
実施形態にかかる、サーバによって実行される例示的なステップのフローチャートである。
実施形態にかかる、クライアントによって実行される例示的なステップのフローチャートである。
実施形態にかかる、プロキシによって実行される例示的なステップのフローチャートである。
実施形態にかかる帯域幅測定を図示する。
実施形態にかかるビデオ再生のイニシャライゼーションを図示する。
実施形態にかかる装置の概略図である。
クライアント側における本発明の一般的なステップを、フローチャートを用いて図示する。
サーバ側における本発明の一般的なステップを、フローチャートを用いて図示する。
明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップを、フローチャートを用いて図示する。
明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップを、フローチャートを用いて図示する。
サーバによって適用されるプッシュポリシーを指定するためにPushPolicyノードが用いられるMPDドキュメントを示す。
共有されたプッシュポリシー「PushPolicy」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて図示する。
HTTP「プッシュポリシー」ヘッダ内で送信されるプッシュポリシーによるサーバとクライアントとの間の通信の例を図示する。
プッシュポリシーを変更するクライアントの要求と同じ例を図示する。
メディアプレゼンテーション記述(MPD)ファイルの例を図示する。
アナウンスメッセージマージする、実施形態によるサーバ側における処理のステップを、フローチャートを用いて図示する。
プッシュポリシーを宣言するためにHTTPヘッダを用いる場合のサーバ側における処理のステップを、フローチャートを用いて図示する。
プッシュポリシーを宣言して共有するためにHTTP要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて図示する。
ドキュメントの階層レベルにおいてサーバによって適用されるプッシュポリシーを指定するためにSupplementalProperty要素が用いられるMPDドキュメントを示す。
XPathベースのプッシュポリシーのために例として用いられるMPDドキュメントを示す。
プッシュポリシーを適用する前の、例えばウェブページ内のプライオリティツリー内の要素の順序付けを図示する。
本発明の実施形態による、DASH高速起動を取得するために、サーバによって、およびクライアント装置によって、それぞれ実施された例示的な方法を示す。
DASH高速起動のためのサーバによって実施される例示的な方法を記述する。
DASH高速起動のためのクライアント装置によって実施された可能な方法を記述する。

実施例

0062

以下において、本発明の実施形態は、HTTP2.0プロトコルを実施するDASHに基づくネットワークとの関連で記述される。ストリーミングされるデータは、例えばビデオデータである。本発明の実施形態は、DASHネットワークに限定されない。

0063

クライアント装置に対してデータをストリーミングする通信ネットワークサーバ装置は、送信されるデータ要素に対するクライアントからの明示的リクエストを伴わずに、クライアントに対してデータ要素を送信することができることによる、プッシュ機能を実施する。

0064

サーバおよびクライアントは、プッシュプロミスを決定し、且つ対応するデータを実際に送信するように、サーバを駆動するプッシュポリシーを共有してもよい。この共有により、クライアントは、そのようなプッシュをキャンセルするために、いくつかの無用データのプッシュを予期することができる。PUSH_PROMISEフレームは、送信される前にキャンセルされてもよいので、これは、ネットワーク使用と同様に、サーバの処理も減少させることになる。

0065

具体的なの実施形態において、サーバは、明確に要求されていないデータ要素の送信をアナウンスする、そのプッシュプロミスにおいて、データ要素を送信するように意図するサーバの順序に関係する順序付け情報を示すことができる。データ要素の順序は、プライオリティ値、例えばHTTP/2によるプライオリティ値、を用いて定義されてもよい。

0066

プッシュプロミスを受信すると、クライアント装置は、サーバによって意図された送信の順序を予め決定することができ、それによって、クライアントは、自身の所望の順序と一致しなかった場合に、提案された順序付けに対応できる。例えば、クライアント装置は、プライオリティ値を更新し、更新されたプライオリティ値をサーバに対して送信することができる。サーバは、したがって、クライアントのニーズと適切に一致させるために、新たなプライオリティ値に基づいて送信順序付けを変更することができる。サーバは、将来のデータ送信を考慮して、更新されたプライオリティを用いることができる。

0067

実施形態によれば、クライアントは、サーバに対するデータ要素の送信の全面的な順序付けまたは部分的な順序付けを要求しても良い。

0068

図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」を識別し、そのプライオリティを減じる。

0069

図7bを参照して、部分的な順序付けを説明する。図7bのステップ710〜714は、図7aのステップ700〜704と実質的に同じである。プライオリティ更新フレームの受信の後、サーバの挙動は、先に記載されたステップ705と比べて異なる。ステップ715の間、サーバは、既に「データ1.2」の送信を開始しており、送信をさらに進める。そのセグメントに関して、プライオリティに変更はない。サーバは、それにもかかわらず、連結されたセグメント、すなわち本例における「データ2.2」)のプライオリティを更新する。プライオリティ変更が考慮さられた、という事実をアナウンスするために、サーバは「データ2.2」のためのプライオリティ更新マッサージ(priorityupdate massage)を送信してもよい。クライアントは、したがって、変更を通知されることができる。

0070

本発明の実施形態は、ビデオのすべての部分を高品質に再生することができるように、サーバが予め十分に良い高品質のビデオ部分をプッシュすることができる使用事例において実施されてもよい。例えば、ビデオは、低品質として再生される部分1、高品質として再生される部分2、および低品質として再生される部分3に分割されることができる。クライアントとサーバとの間の帯域幅は、高品質ではなく低品質のリアルタイムストリーミングを可能にする。その場合、サーバは、部分2を強化し、部分1をインターリーブしてもよい。一旦部分1が再生されれば、強化された部分2は、また、利用可能であり、サーバは、同じ部分2の強化と共同して高品質として再生される部分2のベース層を送信する。このように、サーバは、すべての部分2が高品質として再生されることを確実にする。部分3は、その後に送信される。ユーザエクスペリエンスを妨害する品質のちらつき(quality flickering)を軽減することができ、品質の切り換え(quality switching)のみが、限られた数のモーメントにおいて行われる。サーバは、ビデオコンテンツを認識して以後、異なる品質レベルにいつ切り替えるべきであるかを認識するために最善位置にある。

0071

図8は、実施形態にかかる、プッシュベースのDASHメディアストリーミングを実施するサーバによって実行されたステップのフローチャートである。ステップ800〜812は、一般的な原理を記述する。ステップ820〜827は、より具体的には、クライアントからのプライオリティのフィードバックの管理に対処する。

0072

ステップ800の間、サーバは、クライアントから要求Rを受信する。この要求は、通常はMPDファイルを参照することによって特定のメディアを識別する。次に、サーバは、ステップ801〜810を含む反復処理を実行する。その処理は、定義された順序にしたがってデータを送信することを有する。送信の順序は、クライアントのフィードバックにしたがって更新される。一旦データが送信されれば、それらはクライアントによって受信され再生される。次に、サーバは、送信するべき新たなデータを識別し、処理は、そのように継続し続ける。

0073

第1の反復は、送信されるデータが識別される間のステップ801で始まる。反復処理の第1の実行の場合、クライアントがビデオ再生を可能な限り迅速に開始することを可能にするために、高速起動アプローチが用いられてもよい。さらに、サーバは、また、チャプターへのメディアの細区分を識別しても良い。クライアントが一般的にはチャプターを用いてナビゲートする、ということをサーバが認識する場合、サーバは、メディアの先頭に対して対応するセグメントだけでなくメディア内の第1のチャプターの開始に対応するセグメントも実際に選択してもよい。反復の第1の実行の後、サーバは、また、接続がメディアの高品質のリプレゼンテーションの送信をサポートすることができる、ということを検出しても良い。このように、サーバは、解像度または品質の切り換えをいつ行うべきであるのかを識別しても良い。

0074

一旦サーバがプッシュするセグメントのリストを識別すれば、サーバは、これらのセグメントのための送信順序を定義する。送信順序は、1ステップ802の間に各々のプッシュされたセグメントに対する初期のプライオリティ値を算出するために用いられる。順序付けは、いくつかのパラメータに基づいてもよい。

0075

第1のパラメータは、異なるセグメント間の関連性であってもよく、例えば、いくつかのセグメントは、他のセグメントを正確に復号するために利用可能でなければならない。利用可能でなければならないセグメントは、したがって、前記他のセグメントよりも高いプライオリティを割り当てられる。

0076

第2のパラメータは、過去統計値から採集することができる、ビデオセグメントの人気度であってもよい。例として、YouTube(登録商標)のURLにより、ビデオ内の特定の期間をアドレス指定しても良い。これらのURLSに関連するリンク上をクリックすると、特定の時刻にビデオ再生をスタートするために必要とされるビデオのみが取りだされる。さらに、ビデオがチャプター化されている場合、各々のチャプターの先頭は、一般的には多くの場合、チャプター開始の間のセグメントよりもユーザから取りだされる。チャプターの先頭のSegmentsは、したがって、中間のチャプターセグメントインよりも高いプライオリティを割り当てられる。

0077

第3のパラメータは、タイムラインであってもよく、再生されているビデオセグメントにより近いビデオセグメントのプライオリティは、後で再生されることになるビデオセグメントのプライオリティより高い。

0078

第4のパラメータは、セグメントを実際に送信するために費やされる推定時間であってもよい。ビデオセグメントが大きい場合、送信するのに長い時間がかかり、そのため、できるだけ早く、すなわち高プライオリティで、送信を開始するべきである。

0079

2つのセグメントが同一のプライオリティを有する場合、対応するデータフレームは、送信の間にインターリーブすることができる。関心領域がメディアコンテンツ内で識別された場合、帯域幅が高品質のリプレゼンテーションには十分に大きくはないが、低品質のリプレゼンテーションには十分に大きければ、サーバは、関心領域のためにのみエンハンスメント層を選択してもよい。

0080

一旦プライオリティが算出されれば、サーバは、ステップ803の間に、プライオリティ値を含むPUSH_PROMISEフレームを送信する。すべてのセグメントの識別は、PUSH_PROMISEフレームの送信を開始するためには必要でない。MPDがプッシュされるセグメントのために送信される場合(ステップ804)、MPDが送信される(ステップ805)。セグメント送信は、ステップ806の間に、並列的に開始する。

0081

一旦PUSH_PROMISEフレームがクライアントによって受信されれば、サーバは、プライオリティ更新変更を受信し、その後、それに応じて、その送信スケジュールを変更してもよい(ステップ807〜808およびステップ820〜828)。セグメントを送信する一方で、サーバは、プライオリティ変更メッセージの受信を待つ。プライオリティ変更メッセージが受信された場合(ステップ807)、サーバは、それに応じてセグメントを再順序付けて、セグメント送信を継続する(ステップ808)。一旦すべてのセグメントが送信されると(ステップ809−1)、サーバは、メディアの端部までメディアをストリーミングし続けるために反復処理を再開する。メディアの端部に到達すると(ステップ809−2)、サーバは、別のメディアを自動的にストリーミングし始めるべきか否かをチェックする(ステップ810)。別のメディアがストリーミングされるべきである場合(はい(Yes))、サーバは、ストリーミングする新たなメディアを識別し(ステップ811)、ステップ801から処理を再開する。新たなデータがストリーミングされるべきでない場合、処理は停止される(ステップ812)。

0082

クライアントからのプライオリティのフィードバックの、すなわちステップ808の管理は、ステップ820の間に、プライオリティ更新変更メッセージの受信とともに始まる。クライアントがセグメントプッシュをキャンセルした場合、以下のステップが実行されてもよく、このケースは、そのセグメントに対して最も低いプライオリティを割り当てることと実際には同等であると、理解してもよい。

0083

プライオリティ更新変更メッセージを受信すると、サーバは、ステップ821の間に、関連セグメントを識別する。そして、サーバは、セグメント送信の再順序付けを進める(ステップ822および823)。セグメントが既に送信されていれば、処理は終了する。セグメントが送信されているならば、サーバの実装に応じて、送信を変更することを拒絶してもよいし(例えば複雑すぎるので)、または、送信される残りのデータを実際にスケジュール変更してもよい。

0084

データのスケジュール変更は、以下のように実行されてもよい。サーバは、プッシュするビデオセグメント(および/またはプッシュされるビデオセグメント)のリストを保存する。このリストは、サーバによって設定されたプライオリティにしたがって順序付けられる。そして、サーバは、セグメントに新たなプライオリティ値を設定する。そして、リストが再順序付けられ、対応するビデオセグメントの送信は、それに応じて、早くなったり遅くなったりする。

0085

一旦ビデオセグメントが再順序付けられれば、サーバは、他の関連するビデオセグメントに対して、このプライオリティ変更を適用することを実際に決定してもよい。クライアントがエンハンスメント層の一部であるビデオセグメントのプライオリティを引き上げれば、サーバは、このエンハンスメント層のすべてのセグメントのプライオリティを引き上げてもよい。逆に、クライアントがベースビデオセグメント層のプライオリティを引き下げる場合、このセグメントに一時的に関連するすべてのセグメントのプライオリティが引き下げられてもよい。この処理は、ステップ824〜827に記述される。MPDおよびスケジュール変更されたビデオセグメントに基づいて、サーバは、関連セグメントのリストを識別する(ステップ824)。関連性は、時間、空間、品質ベースなどであってもよい。MPDは、潜在的な関連性をより適切に示すために強化されてもよい。特に、(1つ以上のビデオセグメントを再生するのに必要である)イニシャライゼーションセグメントのプライオリティが引き下げられるかまたは引き上げられると、すべての関連セグメントがスケジュール変更されてもよい。これは、ベース層セグメントおよび強化セグメントの同様のケースになり得る。各々の識別された関連セグメントに対して、サーバは、関連セグメントの送信が変更されるべきであるか否かテストする(ステップ825)。変更されるべきである場合、サーバは、各セグメントに対して新たなプライオリティ値を算出し(ステップ826)、それに応じて、セグメント送信をスケジュール変更する(ステップ827)。新たなプライオリティ値は、ステップ820の間に受信された新たなプライオリティ値とステップ821の間に識別されたセグメントの初期のプライオリティ値との間の差分を古い値に対して加えることによって算出されてもよい。各関連セグメントがテストされると、処理は停止する(ステップ828)。

0086

サーバは、また、WINDOW SIZEフレームなどの制御フローメッセージを受信してもよい。これらのメッセージによって、サーバは、クライアントが現在何を再生しているのかを、識別することが出来るであろう。いくつかの追加的バッファスペースがクライアントの端上で利用可能な場合、いくつかのデータ、通常は最も古いデータ、がバッファから取り出された、ということが推測され得る。サーバが送信されたデータの履歴を保持すれば、サーバは、どのデータが取り出されたのかを識別することができる。このように、もしサーバが、クライアントのキャッシュの順序付けを認識しているならば、サーバは、クライアントが現在どのビデオセグメントを再生しているかを知ることができる。この順序付けは、タイムラインにしたがってキャッシュされたデータを、順序付けることを可能的にするMPDに基づいてもよい。そして、サーバは、例えばクライアントの時間スキップを検出することができる。サーバは、クライアントがビデオチャプターをスキップし続けることができるように、予め次のチャプターの開始を迅速に送信することによって対応してもよい。

0087

プライオリティをもつPUSH_PROMISEフレームの送信が様々な方法で行われてもよい、ということを留意するべきである。PUSH_PROMISEフレームは、クライアントによって起動される開かれたストリーム(opened stream)に関連しなければならない。実施形態によれば、ステップ800の間にクライアントによって行われた初期のストリームは、常に開かれたままであってもよい。他の実施形態によれば、PUSH_PROMISEフレームは、サーバによって開かれたストリーム内で送信される。この場合、それが親クライアントに起動されたストリームによって送信されるように、クライアントは、PUSH_PROMISEフレームを考慮する。このように、個々のPUSH_PROMISEフレームに対応する仮想要求の正しいヘッダを算出することができる。

0088

他の実施形態によれば、プライオリティメッセージは、PUSH_PROMISEと共同で送信される。第1の可能性は、PUSH_PROMISEフレーム内部のヘッダとしてそれを送信することである。もう1つの可能性は、対応するPUSH_PROMISEフレームによって保存されたストリームIDを持つPRIORITYフレームを送信することである。第3の可能性は、このPUSH_PROMISEフレーム、その後、(ストリームを開くために)対応するHEADERSフレーム、および新しく開かれたストリーム上のPRIORITYフレームを送信することである。

0089

さらにクライアントのバッファを制御するために、サーバは、クライアントによってキャッシュされたセグメントの新たなリプレゼンテーションを送信してもよい。この新たなリプレゼンテーションの一部として送信されたヘッダ内で、HTTPキャッシュ指示は、例えばキャッシュすることができるものとしてそれをマークすることによって実際にセグメントを取り出すことをクライアントに要求するために用いられてもよい。これにより、クライアントの端上のバッファスペースを回復することが可能となる。HTTP/2制御フローが用いられてもよい。そして、サーバは、付加データをプッシュすることができる。

0090

サーバは、各ビデオセグメントのプライオリティ値を送信してもよい。サーバは、また、特定セグメントのためのプライオリティ値を送信してもよい。サーバが、現在のPUSH_PROMISEフレームのプライオリティ値を送信しなかった場合、クライアントは、サーバから送信された最後のプライオリティ値からプライオリティ値を算出することができる。例えば、クライアントは、関連付けられたプライオリティ値がない新たなPUSH_PROMISEフレームが受信されるたびにプライオリティ値を増加させてもよい。従って、特定セグメントのプライオリティの更新をするとまたグループのすべてのセグメントのプライオリティを更新するように、PUSH_PROMISEフレームは、グループ化することができる。

0091

図9を参照してクライアント側の処理を説明する。

0092

クライアントは、所定の時間に利用可能なコンテンツを再生可能であるべきである。しかしながら、クライアントは、潜在的なバッファ制限および処理時間に対処しなければならない。クライアントは、サーバによって提案された送信順序付けがクライアントのバッファにおいて利用可能なメモリスペースと一致し、且つクライアントによって現在再生されているコンテンツと一致するか否かを、チェックしなければならない。

0093

最初のステップ900の間に、クライアントは、サーバに接続して、MPDファイルを要求する。そして、クライアントは、ステップ901の間にMPDファイルを取り出し、データの受信を待つ(ステップ902)。データが受信されると、クライアントは、データがプッシュプロミスであるか否かをチェックする(ステップ903)。プッシュプロミスが受信された場合、これは、新たなビデオセグメントがサーバによって送信されている、ということを意味する。クライアントは、プッシュプロミスを処理する。特に、クライアントは、ステップ904の間にサーバによって提案されたプライオリティ値を認証してもよい。クライアントが現在のセグメントまたは別のプロミスされたセグメントのプライオリティ値を変更したい場合(ステップ905)、クライアントは、新たなプライオリティ値を算出して、それをサーバに対して送信する(ステップ906)。

0094

クライアントがビデオデータを受信すると(ステップ907)、クライアントは、ビデオセグメントをMPDファイルにリンクし(ステップ908)、ビデオデータ(ステップ909)を保存する。ビデオデータをMPDファイルにリンクすると、ビデオの復号のためにさらに用いられる場合にクライアントがビデオセグメントを取りだすことが可能になる(ステップ911)。例えば連続したビデオセグメントがグループ化されると、これは、また、ビデオデータの効率的な保存を提供することができる(ステップ909)。

0095

バッファ保存制約は、さらにプライオリティを変更することができる。このように、クライアントは、プライオリティ値を変更しなければならないかどうかを再びチェックすることができ、もし必要ならばサーバと通信してもよい(ステップ905および906)。

0096

一旦クライアントがビデオを再生し始める、または再生し続ける準備ができれば(ステップ910)、クライアントは、そのキャッシュから次のタイムスロットのビデオセグメントを取り出し(ステップ911)、ビデオを復号して再生する(ステップ912)。ステップ911の一部として、クライアントは、どのビデオセグメントが利用可能であるのかを認識するためにそのキャッシュを問い合わせることができる。デフォルトでは、クライアントは、利用可能なすべてのビデオセグメント、もしあれば特にすべての強化セグメント、を用いてもよい。クライアントは、サーバにコンテンツを選択させることができ、一般的には言えば、すべてのセグメントは、クライアントによって用いられるべきである。(オーディオの英語トラックおよびフランス語トラックのような)いくつかのセグメントを共同で用いることができなければ、クライアントは、まず第1に未使用のセグメントを捨てるべきである。すべてのクライアントがキャッシュ状態に対してアクセスするとは限らないかもしれない、ということに留意するべきであり、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。例えば、この情報は、ウェブソケット接続を用いて、サーバからクライアントに交換されてもよい。

0097

ビデオが再生されて復号されるとともに、対応するビデオセグメントは、バッファから取り出されるであろう。従って、クライアントは、WINDOW SIZEフレームを用いて、その利用可能なバッファサイズを更新する。クライアントは、ユーザが限られた期間の間にビデオを巻き戻すことを可能にするために、最近再生されたビデオセグメントを保持してもよい。ユーザが早送りタイムスキップを行う場合、フロー制御更新メカニズムも用いられてもよい。クライアントは、新たなコンテンツのために場所を空けるために、前から保存されたビデオコンテンツを取り出してもよく、WINDOW SIZEフレームを用いて、サーバに対してこの変更をアナウンスする。サーバがWINDOW SIZEフレームを受信すると、サーバは、前述のように、どのビデオセグメントが取り出されたのかを算出し、その後、クライアントが実際に何を再生しているのかを識別することができるであろう。

0098

以下において、ステップ904をさらに詳細に説明する。

0099

クライアントは、すべてのプッシュプロミスビデオセグメントのリストを保持する。このリストは、プッシュプロミスフレームにおいて見つかったプライオリティ情報にしたがって順序付けられる。第1に、それは潜在的な凍結されたビデオ問題のためにチェックされる。利用可能な帯域幅の推定および順序付けられたビデオセグメントリストに基づいて、各セグメントの送信の始まりおよび終わりの時刻を推測することができる。これらの時刻に基づいて、各ビデオセグメントはビデオ再生のために用いられる時刻に利用可能であるか否か、をテストされることができる。プロミスされたビデオセグメントがその対応するビデオ再生の使用の後に配送されることが予定される場合、そのプライオリティを上げるべきである。このように、このビデオセグメントは、プッシュプロミスビデオセグメントリスト内の順序が繰り上げられる。正確なプライオリティ値を算出するために、ビデオセグメントを時間通りに配送することを可能にするとともに、現在のビデオセグメントの位置に最も近い、ビデオセグメントリスト内における位置を検索する。そして、プライオリティは、ビデオセグメントの新たな位置の前後にあるリスト内のビデオセグメントのプライオリティ間の値に設定される。

0100

他のファクタも、また、ビデオセグメントのプライオリティの変更のために、クライアントによって用いられてもよい。例えば、クライアントがいくつかのチャプター切換を行うことを予定していれば、クライアントは、チャプターを開始するすべてのビデオセグメント、特に対応するイニシャライゼーションセグメント、のプライオリティを実際に拡大してもよい。

0101

実施形態によれば、クライアント側フロー制御は、ストリームごとのフロー制御を停止させて接続ごとのフロー制御のみを保持することを有する。接続ごとのウィンドウサイズは、クライアントが実際にいかなるときにも保存してもよいビデオの最大量を定義する。クライアントおよびサーバは、このウィンドウサイズを減少または拡大するためにイニシャライゼーション時や接続中にネゴシエイトしてもよい。サーバがいくつかのHDコンテンツをプッシュしたければ、サーバは、ウィンドウサイズを拡大することをクライアントに要求してもよい。接続帯域幅が低いならば、サーバは、ビデオの特定の部分のためのHDコンテンツを送り出すことを予め十分に予期する必要があるかもしれず、その場合には、バッファサイズは、より大きくされる。

0102

バッファが単一のサイズを有する場合、送信の順序は、重要な問題であるであろう。特に、バッファがデータでいっぱいになった時に、プライオリティ順序付けは、より一層重要になる。重要な制約は、ビデオがフリーズしないということである。バッファが大きく空いている限り、サーバは、効率的な早送りまたはチャプタースキップを提供するために、かなり先行したセグメントのような様々なビデオセグメントを予めプッシュしてもよい。一旦バッファがほぼ満タンになれば、プッシュするビデオセグメントは再生されるビデオセグメントになるべく近いるべきである。サーバがクライアントバッファに関係する正確な情報を有していれば、このプッシュ挙動は、サーバによって行われてもよい。また、それは、プライオリティ更新メカニズムを用いて、クライアントによって実施されてもよい。

0103

自動化されたビデオ切換の場合には、図9のフローチャートは、プッシュプロミスチェックの一部として新たなMPDのプッシュを検出することによって拡張されてもよい(ステップ903)。MPDプッシュが検出されると、クライアントは、ステップ908の一部として新たなビデオのセグメントを受信し始めてもよい。そのため、クライアントは、ビデオデータに関連するMPDを識別しなければならない。一旦ビデオ再生が所定のMPD(ステップ902)のために終了されると、新たなMPDは、ビデオ再生の継続のために用いられる。クライアントは、先のMPDにリンクされたビデオセグメントをすべて実際に消去することができる。

0104

図10を参照して、DASH認識プロキシの挙動を説明する。サーバからプッシュされたセグメントを受信すると、プロキシは、エンドクライアントに対してそれをプッシュするようには要求されない。しかしながらDASHストリーミングの場合には、それは優れた方式(またはデフォルトの挙動)と考えられる。

0105

プロキシは、送信されるプッシュされたデータだけでなくプライオリティ処理に関して、サーバおよびクライアントの挙動を調整することができてもよい。プロキシは、実際、クライアントによるプライオリティを、サーバによるプライオリティから独立して取り扱ってもよい。さらに、サーバは所定のクライアントのために必要とされる以上のデータをプッシュしてもよく、プロキシは、他のクライアントからの要求を実現するために付加的なプッシュされたデータを取り込んでもよい。

0106

サーバは、いくつかの理由によりビデオセグメントをプッシュしてもよい。例えば、それがエンドクライアントのために有用であると考えられた場合、ビデオセグメントがプッシュされてもよい。ビデオセグメントは数回使用することが可能で、且つプロキシに対してそれをプッシュする価値があると考えられる場合、ビデオセグメントもプッシュされてもよい。

0107

第1のケースにおいて、プロキシは、一般的には、クライアントに対してビデオセグメントを送信する。プロキシは、クライアントまたはプロキシのネットワーク状態(例えばクライアント無線状態)を最適化するためにその送信を先延ばししてもよい。例示的なケースは、高速起動ビデオ再生および帯域幅推定のためのセグメントプッシュであり、その場合には、データはクライアントに対して可能な限り高速に送信されるべきである。サーバがプロキシに対するデータのプッシュに関心がある場合、プロキシは、ビデオセグメントがクライアントに対して有用になることを認識する手段を有する場合以外は、クライアントに対してビデオセグメントを自動的に送信しなくてもよい。クライアントに対して送信されなくてもよいビデオセグメントの識別を可能にするために、特定のプライオリティ値を用いてもよい。プライオリティ値を用いると、到達する様々なフレームの処理を最適化するためにプロキシが常にプライオリティ値をチェックすることができる。
図10は、3つのフローチャートを含む。1つのフローチャートは、プッシュされたセグメントをフィルタリングする処理に関する(ステップ1000〜1008)。もう1つのフローチャートは、セグメントが別のクライアントに対して既にプロミスされている一方で、セグメントがクライアントによって要求された場合に実行される処理に関する(ステップ1010〜1015)。もう1つのフローチャートは、プライオリティ変更の管理に関する(ステップ1020〜1026)。

0108

プッシュされたセグメントをフィルタリングする処理は、プッシュされたデータイベントの受信(ステップ1000)とともに、通常はPUSH_PROMISEフレームまたは関連するDATAフレームを受信したときに、始まる。プロキシは、データが高プライオリティであるか否かをチェックする(ステップ1001)。データは、それらのプライオリティ値が送信されている他のセグメントのプライオリティ値よりはるかに大きい場合、高プライオリティであると考えられる。データは、また、そのプライオリティ値が高速起動または帯域幅推定などの特別の意味を有するならば、高プライオリティであるとして考えられる。データが高プライオリティである場合、それらはクライアントに対して可能な限り迅速に送信される(ステップ1002)。そして、プロキシは、データを保存するべきであるか否かを決定する(ステップ1003および1004)。プッシュされたデータストリームを開く対応するPUSH_PROMISEフレームまたは対応するHEADERSフレームを受信すると、この判定は、一回行われてもよい。この判定は、また、プロキシのキャッシュ状態、ビデオの予見された使用、ビデオソースの人気度、または他の基準に基づいてもよい。セグメントが1つ以上のクライアントによって同時に要求される間にプッシュされれば、プロキシは、ビデオセグメントを保存する。セグメントが高速起動として識別されれば、ビデオセグメントもまた保存されてもよい。

0109

データが高プライオリティでないならば、プロキシは、それが低プライオリティであるか否かをチェックする(ステップ1005)。低プライオリティのデータは、クライアントに対する送信がスキップされてもよいが、プロキシのようなネットワーク媒介に対して興味深いものとしてサーバによって考慮されるデータかもしれない。プロキシは、まず、クライアントに対してデータを送信するべきか否かを決定する(ステップ1006)。プッシュされたデータストリームを開く対応するPUSH_PROMISEフレームまたは対応するHEADERSフレームを受信すると、この判定は、一回行われてもよい。そのように決定されれば、プロキシは、クライアントに対して、対応するフレームを送信する(ステップ1002)。そして、処理は、データを保存するべきか否かを決定した後に停止する。

0110

サーバとプロキシとの間でネゴシエイトされたプライオリティ値は、また、クライアントとプロキシとの間でネゴシエイトされたプライオリティ値とは異なってもよい。そのため、データが通常のプライオリティである(すなわち、低プライオリティでもなく、高プライオリティでもない)場合、プロキシは、セグメントのプライオリティ値がプロキシによって管理されるか否かをチェックする。図10に図示されるように(ステップ1020〜1026)、プロキシは、データが送信されるべき時刻をスケジューリングするためにクライアント〜プロキシ間の値を用い、プロキシは、送信されるべきすべてのビデオ関連のフレームのリストを保持する。これらのフレームは、その順序にしたがって送信される前に、プライオリティ値にしたがって順序付けられる。

0111

プロキシは、プライオリティ更新フレームを受信している場合に(ステップ1010)、プロキシは、関連するビデオセグメントを識別する(ステップ1011)。そのプライオリティ値がプロキシによって管理されていなければ(ステップ1012)、プロキシは、サーバに対してプライオリティ更新フレームを転送する(ステップ1013)。さもなければ、プロキシは、この新たなプライオリティ値を保存し、それに応じて、ビデオセグメントの送信を再順序付ける(ステップ1014)。潜在的な競合が出現した場合、特にサーバからのビデオセグメントの配信がクライアントのニーズに対して遅れすぎると予想される場合、プロキシは、サーバに対してプライオリティ値を転送することができる。

0112

ステップ1020〜1026は、サーバによって既にプロミスされているビデオセグメント(ステップ1020)のクライアントから別のクライアントに対する要求を受信するプロキシのケース(ステップ1021)に関連する。その要求に対して与えられるプライオリティに応じて、プロキシは、クライアントの要求を満たす、プロキシ〜サーバ間の最小のプライオリティを算出する(ステップ1022)。この計算は、サーバ〜プロキシ間の配信時刻がプロキシ〜クライアント間の予定した配信時刻よりも早いということを保証する、プロキシ〜サーバ間のプライオリティ値を算出することによって行われる。プライオリティは、算出されたプライオリティが現在設定されているプライオリティを下回る場合に、変更され(ステップ1023)、その場合には、プロキシは、プライオリティ更新メッセージをサーバに対して送信することになり(ステップ1024)、プロキシは、プロキシがそれらのニーズに対して最良の時刻にその2つのクライアントに対してビデオセグメントを送信するように、プロキシによって管理されるようなこのビデオセグメントプライオリティをマークすることになる。この処理と同様に、プロキシは、いくつかのクライアントから同じセグメントに対する、いくつかのプライオリティ更新を受信してもよく、その場合には、プロキシは、すべてのクライアントを満たす最も低いプライオリティ値を実際に送信してもよい。

0113

図11を参照して、プッシュされたデータイベントをクライアントが受信することによる実施形態が説明され、そのデータイベントのプライオリティ値は、サーバが帯域幅の測定のためにそれを用いたいということを示す。帯域幅の測定は、ラウンドトリップ時間を算出するための能動的または受動的な測定を通じてTCP/IPパケットを用いて行われてもよい。ラウンドトリップ時間に基づいて、利用可能な帯域幅は、Saubhasik他の文献「BitVampireにおける帯域幅推定および速度制御(BandwidthEstimation and Rate Control in BitVampire)」に見出されるように、算出されてもよい。この計算は、場合によっては、HTTP/2制御フローの影響を考慮に入れてもよい。いくつかのデータフレームが可能な帯域幅推定のために用いられる、という通知を行うことによって、HTTP/2制御フローなしで、利用可能な帯域幅を推定することができる。

0114

処理は、プッシュされたデータフレームがサーバから受信される間のステップ1100にて始まる。次に、ストリームの関連付けられたプライオリティが、サーバが帯域幅を測定しているということを示すか否かがチェックされる(ステップ1101)。その場合、専用のバッファは最大化される(ステップ1102)。または、ストリームフロー制御を無効にすることもできる。受信ノードがプロキシであるならば(ステップ1103)、セグメントデータを転送してもよい。さもなければ、クライアントは、セグメントを保存するべきか否かを決定する(ステップ1104)。クライアントは、プッシュされたセグメントを保存する(ステップ1105)。いずれにしても、クライアントは、接続ごとのウィンドウのための肯定応答をWINDOWS(登録商標)_UPDATEの形式でサーバに対して送信する(ステップ1106)。そして、この肯定応答は、接続帯域幅を推定するためにサーバによって用いられることになる。クライアントがプロキシで有る場合、プッシュされたデータを可能な限り迅速に転送する(ステップ1108)。エンドクライアントから肯定応答を受信すると、プロキシは、同様にそれをサーバに返送する(ステップ1109および1110)。

0115

利用可能な帯域幅を推定するために、サーバは、データフレームの送信時刻肯定応答メッセージ受信時刻との間の差分として算出される、送信されたデータフレームのラウンドトリップ時間を用いてもよく、2者間のペアリングは、例えばウィンドウサイズ更新に等しくなるべきデータフレームサイズに基づく。ラウンドトリップ時間は、1つ以上のビデオセグメントの様々なデータフレームから算出される。正確さを増すために、データフレームは、様々なサイズを有してもよい。異なるサイズのいくつかのDATAフレームにビデオセグメントを分割することは、サーバによって実行できる。サーバは、ネットワーク層が、DATAフレームを、いくつかのTCP/IPパケット(したがって小型のDATAフレーム)に分割しない、または送信されるコンテンツをバッファリングして、いくつかのDATAフレームをTCP/IPパケットにマージしない、ということを保証することのみ必要とされる。それらの測定値に基づいて、規格技術は、どのビデオリプレゼンテーションを用いるかを実際に判断するために、サーバが用いてもよい利用可能な帯域幅を算出するために用いることができる(例は上記の文献内で見出すことができる)。

0116

図12を参照して、初期のビデオ再生のケースを説明する。サーバは、高速起動プライオリティを用いて、データをプッシュする。データは、通常低ビットレートを有しており、クライアントは、サーバが帯域幅を推定することができ、且つ最適なリプレゼンテーションに切り替えることができるように、それらのデータを受信して肯定応答をサーバに対して送信することになる、と考えられる。クライアント側の処理はステップ1200〜1207に記載される。サーバ側の処理は、ステップ1210〜1215に記載される。

0117

クライアント処理は、プッシュされたデータの受信のステップ1200から始まる。そして、クライアントは、プライオリティが高速起動の値を有するか否かをチェックする(ステップ1201)。その場合、クライアントは、通常は、専用のバッファを最大化する(ステップ1202)。プッシュされたデータのPUSH_PROMISEを受信すると、この最大化が実行される。そして、データが保存され(ステップ1203)、クライアントは、WINDOW UPDATEフレームを用いて、肯定応答をサーバに送信する(ステップ1204)。そして、クライアントは、ビデオを再生し始めるために十分なデータが利用可能であるか否かをチェックする(ステップ1205)。そうであるならば、ビデオ再生が始まる(ステップ1206)。そうでなければ、データを再生し始めるために十分なデータが利用可能になるまで、クライアントは、さらなるデータを待つ(ステップ1207)。

0118

サーバ処理は、高速起動プライオリティでセグメントデータフレームを送信するステップ1211から始まる(ステップ1210)。そして、サーバは、利用可能な帯域幅を算出すること(ステップ1212)を可能にする肯定応答を受信する(ステップ1211)。一旦十分な測定値が取得されれば、サーバは、最適なリプレゼンテーションを選択し(ステップ1213)、最適なリプレゼンテーションセグメントをプッシュし始める(ステップ1214)。サーバは、リプレゼンテーションをいつ切り替えるのかを決定する。これには少なくとも2つの利点がある。第1に、クライアントが多少の遅延に対処する必要がある一方で、サーバは、いつ測定値が十分に正確になるのかを認識することができ、このケースであれば直ちに1つの解像度から別の解像度に切り替えることができる。第2に、サーバは、ユーザエクスペリエンスをあまり妨害しない時刻に1つの解像度から別の解像度に切り替えることを決定することができる。実際には、サーバは、ビデオコンテンツの認識を有する。特に、MPDは、解像度の切り換えを最良に予見することができる時刻の情報により強化されてもよい。

0119

本発明は、強化されたストリーミング方法に関し、サーバ側において、第1のメディアデータに関連する要求がクライアント装置から受信され、要求されていなくともクライアント装置に対して送信される第2のメディアデータが識別され、そして、前記第1のメディアデータに関連する情報が前記要求に応答して前記クライアント装置に対して送信され、クライアント装置に対してアナウンスメッセージ(単数または複数)を送信するために前記第2のメディアデータをそれぞれ識別する少なくとも1つのアナウンスメッセージが準備される。

0120

クライアント側において、第1のメディアデータに関連する要求は、サーバ装置に対して送信され、前記第1のメディアデータに関連する情報は、前記要求に応答して前記サーバ装置から受信される。

0121

強化されたストリーミング方法は、いくつかのメディアデータをプッシュするサーバの判定と、このようなデータのためのクライアントのニーズとの間のミスマッチを減少させる。以下から明らかになるように、サーバおよびクライアントは、サーバおよびクライアントが両方ともクライアントによって要求されたいずれかのメディアデータからプッシュされる同じメディアデータを決定するように、プッシュポリシーを共有する。プッシュポリシーは、プッシュするデータを決定する方法を定義しており、要求されたデータが処理された(GET要求の後に)後に、要求されたデータに対してリンクされたどのリソースがプッシュされるのか、および場合によってどのようにプッシュされるか(例えば、どの順序で)を判定するための規則として理解されてもよい。通常、リンクされたリソースは、1つのドキュメント、例えば、(マルチメディアデータのためのDASHコンテキストにおける)MPDファイルなどのマニフェストファイル、またはHTMLドキュメント、を用いて決定される。

0122

結果として、共有されたプッシュポリシーに基づいて、クライアントはサーバの挙動を予期し、サーバからの無用のメディアデータの送信を、回避する、そしてより正確にはキャンセルすることができる。クライアントとサーバとの間の通信ネットワーク内の帯域幅の使用が、このようにして減少する。さらに、HTTP要求およびPUSH_PROMISEキャンセルの数が減少し、その結果、特に低遅延のライブビデオストリーミング用のアプリケーションの待ち時間が下がる。

0123

本発明によれば、サーバは、サーバ装置がクライアント装置に対する第2の非要求メディアデータの識別および送信を駆動するためにクライアント装置と共有されるプッシュポリシーを、用いることができる。特に、クライアント装置に対して送信される第2の非要求メディアデータサーバ装置が決定するために、クライアント装置と共有されるとともに第2のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。それに対応して、クライアント装置によって要求されていなくともサーバ装置によって送信される第2のメディアデータをクライアント装置が決定するために、クライアントは、サーバ装置と共有されるとともに第2のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。

0124

図14aは、クライアント側における本発明の一般的なステップを、フローチャートを用いて示し、その一方で、図14bは、サーバ側における本発明の一般的なステップを、フローチャートを用いて示す。

0125

図1dおよび図1eを参照して説明された処理との比較において、付加的なステージ1400および1402は、サーバおよびクライアントが、他方と共有されて、それにより用いられるプッシュストラテジをそれぞれ決定することを可能にする。

0126

第1の実施形態によれば、共有されたプッシュポリシーは、共有されるプッシュポリシーが何であるのかを他方に知らせるためにクライアントおよびサーバがポリシーデータを交換しない(明示的でない)ということを意味する、暗示的なプッシュポリシーである。共有されたプッシュポリシーの暗示的アプローチの実施は、サーバ装置およびクライアント装置の両方において、「第2のメディアデータを決定するアルゴリズム」として呼ばれる同じアルゴリズムを用いることを含み、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第1のメディアデータから同じ第2のメディアデータを決定することを可能にする。

0127

例えば、アルゴリズムは、クライアントおよびサーバのセットアップの間に、または特定の規格に関連して、予め決定される。アルゴリズムの代表例は、マニフェストファイルの構文解析順序における要求されたリソースに追続くN個のリソースのプッシュする場合であり、ここで、Nは所定数(例えば4)である。

0128

図を参照して、ステップ1400および1402は、暗示的なプッシュポリシーのケースでは、プッシュされるリソースを識別する(サーバ側におけるステップ1403)ためにメモリ内の所定のアルゴリズムをロードすることにある。

0129

クライアントは、例えばステップ1401において、期待されるPUSH_PROMISEの数を推定し、且つ不要なプッシュデータのためにキャンセルメッセージを準備するように決定されたプッシュポリシーを効率的に用いてもよい。

0130

例えば、サーバ装置が対応する用意されたアナウンスメッセージを送信しないように、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバがクライアント装置から受信することになる。一方で、クライアントは、第2の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第2の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバ装置に対して送信するであろう。アナウンスメッセージがサーバ装置から送信されるか、またはクライアント装置によって受信される前に、このようなキャンセルが行われることができる、ということをわかるであろう。このアプローチは、例えば、別のバージョンのメディアに切り替えることをクライアントが決定するときに、有用かもしれない。このような状況において、前バージョンのためにプッシュされたセグメントをキャンセルすることを決定することができる。

0131

アルゴリズムを用いてプッシュされるリソースの認識のために、クライアントは、サーバから対応するPUSH_PROMISEを待つ必要なく後続のリソースを取りだすために、サーバに対して第2の要求を並列に行うことができる、ということにも留意するべきであろう。DASHの場合には、クライアントのためのこの可能性は、第2の要求が後で受信するPUSH_PROMISEに干渉しないことを保証しながら、クライアントの待ち時間を減少させることを可能にする。

0132

これらの他の必要とされるリソースがプッシュされようとしている、ということをアルゴリズムの結果から判定すれば、クライアントは、また、必要とする他のリソースを要求してもよい。

0133

第2の実施形態によれば、共有されたプッシュポリシーは、全体の規則(すなわちアルゴリズムまたはアルゴリズムのパラメータ)を明確に定義するか、または両方の側で事前に定義されたプッシュポリシーを参照することによって、クライアントとサーバとの間の交換において定義される。これは、サーバのプッシュポリシーを記述するプッシュポリシー情報をサーバがまず決定することが必要となる。そして、プッシュポリシー情報は、プッシュポリシーをクライアントと共有するために、クライアントに対して送信される。それに対応して、クライアントは、それにより、共有されたプッシュポリシーを記述するプッシュポリシー情報をサーバ装置から受信する。

0134

明示的アプローチの1つの効果は、それらの処理特性をより適切に満たすために異なるプッシュポリシーを、各クライアントまたは各マルチメディアプレゼンテーション(例えば各MPD)のためにサーバが用いることができるという事実に依存する。図15aは、明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップ1400を、フローチャートを用いて示し、その一方で、図15bは、明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップ1402を、フローチャートを用いて示す。

0135

図15bに示されるように、サーバは、ステップ1504において、プッシュポリシーを宣言するメッセージを生成し、その後、それを共有するために、ステップ1505においてクライアントに対してそれを送信する。宣言メッセージ内のプッシュポリシーを記述する情報は、プッシュポリシー情報と称される。

0136

以下に記載される図16〜図18は、プッシュポリシーがどのように宣言され、クライアントに対して送信されるのかについて例示的な詳細を示す。

0137

ステップ1402において決定されるようなプッシュポリシーを用いてプッシュされるリソースは、ステップ1504において生成されるプッシュポリシー宣言メッセージ内に定義されたセレクションアルゴリズム(または第2のメディアデータを決定するアルゴリズム)により、ステップ1403において識別される。

0138

クライアント側では、図15aに示されるように、クライアントは、同じ選択アルゴリズムを適用することによって、所定のリソース要求のためにプッシュされるリソースを、事前に識別することができる。これは、サーバによってプッシュされるデータをクライアントが予め決定することを可能にし、したがって、プッシュデータの効率的な管理と、必要であればGET要求の数の削減とを保証することを可能にする。

0139

同じ選択アルゴリズムを適用するために、クライアントは、サーバによって適用されたプッシュポリシーを記述するプッシュポリシー情報を受信する。

0140

様々なプッシュポリシーの宣言方法が用いられてもよい。

0141

1つの実施形態において、プッシュポリシー宣言は、要求Rと、プッシュされるリソースを含むドキュメント(通常はDASHのためのマニフェストファイル)に対応するDOMツリーとを入力パラメータとして利用して、プッシュされるリソースの順序付きリストを出力するJava(登録商標)Scriptプログラムおかげで共有される。この実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されるウェブページ内に埋め込まれるJava(登録商標)Scriptプログラムを含む。

0142

他の実施形態において、プッシュポリシーは、マニフェストファイル内に記述される。それは、共有されたプッシュポリシーを用いて、サーバ装置からクライアント装置に対して送信される記述ファイル内の共有されたプッシュポリシーが挿入されることを記述するプッシュポリシー情報である。記述ファイルは、第1のメディアデータを含むメディアデータに関係し、プッシュされる第2の非要求メディアデータを決定するために両方の側によって用いられる記述情報を含む。

0143

DASHにおいて、記述ファイルは、例えばMPDファイルである。以下の記述は、主として、DASHおよびMPDファイルに基づく。しかしながら、同じアプローチは、スムーズなストリーミングまたはHTTPライブストリーミングのような他のマニフェストベースのストリーミング方法に適用できる。

0144

具体的な定の実施形態によれば、プッシュポリシー情報は、識別される第2の非要求メディアデータの量を定義する第1のプッシュ属性を記述ファイル内に含む。これは、1つの要求Rがクライアントから受信された後、プッシュされるセグメントの数を指定することを可能にする。

0145

これは、サーバによって適用されるプッシュポリシーを指定するためにPushPolicyノード1600が用いられるMPDドキュメントを示す図16によって示される。

0146

この例において、PushPolicyノード1600は、GET要求が受信された後にプッシュされるセグメントの数を宣言するために、プッシュ属性(すなわち「Segmentldx」)を含む。例えば、クライアントがそのGET要求内のセグメント1601を必要とするならば、MPDドキュメントの順序を解析する際に、次の2つのセグメントのためのPUSH_PROMISEフレームを応答として、受信することになる。この例において、第1のプッシュ属性は、記述ファイル内の要求された第1のメディアデータに対して第2の非要求メディアデータを識別する。さらに一般的には、プッシュされるK個のセグメントの所定数は、プッシュポリシー値を定義するために用いられる。結果的に、クライアントによって要求される各セグメントに対して、サーバは、Kの次のセグメントをプッシュすることになる。

0147

図16の例1600は、単一のプッシュ属性を示すが、複数のプッシュ属性があってもよい。各プッシュ属性は、プッシュされるセグメントを選択するために、マニフェストを表現するDOM(ドキュメントオブジェクトモデル(Document Object Model))ツリーのノード上の制約を表現してもよい。図4bの先の例を参照すると、プッシュポリシーノード1600は、メディアデータが属するPeriod要素を参照する期間属性「Periodldx」と、メディアデータのAdaptationSet要素を参照するアダプテーション属性「AdaptationSetldx」と、Representation要素を参照するリプレゼンテーション属性「Representationldx」、すなわちメディアデータの符号化バージョン(特定のコーデック、解像度、またはビットレート…)と、所定のリプレゼンテーション内のセグメントを参照するセグメント属性「Segmentldx」と、を含むメディアデータ属性(MPD要素および/または属性)を用いて、記述ファイル(MPDファイル)内に記述されるメディアデータを参照することができる。

0148

これらの既存のメディアデータ属性に基づいて、プッシュポリシー情報は、第2の非要求メディアデータを識別するために、メディアデータ属性(単数または複数)上の制約を定義する少なくとも第2のプッシュ属性を含んでもよい。

0149

例えば、Segmentldx属性に関連する上記の第1のプッシュ属性に加えて、プッシュするセグメントを選択するための期間上の制約を指定するために、プッシュ属性は、Periodldx属性に関連付けられてもよく、別の1つは、適応上の制約を指定するためにAdaptationSetldx属性に関連付けられてもよく、別の1つは、リプレゼンテーション上の制約を指定するためにRepresentationldx属性に関連付けられてもよい。

0150

プッシュ属性が存在しないかまたは無効のとき、関連するメディアデータ属性は、非制約として考えられねばならない。

0151

プッシュ属性の値は、以下の構文を用いてもよい。

0152

プッシュ属性=[オペレータオペランド(push attribute=[operator] operand)
ここで、「オペレータ」は、オプションであり、要求されたセグメントに対して相対的にプッシュされるセグメントを定義するために、値「+」または「−」をとり(「+」は後を意味し「−」は先を意味する)、ここで、「オペランド」は、ワイルドカードパラメータとして0または「<*>」よりも上位の整数値若しくは等しい整数値のいずれかである。

0153

図17は、共有されたプッシュポリシー「PushPolicy」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて示す。このフローチャートは、ステップ1403を示す。

0154

まず、サーバは、ステップ1700において、マニフェストファイル内の要求されたセグメントを識別する。要求は、このセグメントの識別された「reqSegldx」を含む。

0155

マニフェストファイルMPD内の各々のノード種別に対して、指標値が、各ノードに対して属性付けられる。値は、マニフェストファイル内での出現順において各々のノードごとに増加される。

0156

次に、要求されたセグメント(すなわちGET要求において指定されたセグメント)に対応するPeriod、AdaptationSet、Representation、およびSegmentURLのインデックスは、要求されたセグメントに到達されるまで、全体のMPDを解析することによって取りだされる。

0157

プッシュポリシー内に定義されたプッシュ属性のオペレータおよびオペランドの値は、(「+」または「−」オペレータに関連付けられている場合に、プッシュされるセグメントの量を定義するSegmentldx属性を除いて)プッシュされるセグメントがどのノード内で定義されるのかを識別するために用いられる。

0158

オペレータが指定されない場合は、オペランド値は、プッシュされるデータを検索しなければならないNodeのインデックスを識別する。例えば、第1のプッシュ属性「Segmentldx」がオペレータを有しない場合には、それは、プッシュされる特定セグメントの、記述ファイル内部の、識別子である。1つの代替案において、オペレータが指定されないと、オペランド値は、範囲値を識別してもよく、例えば、「Segmentldx=2−5」は、2、3、4および5に等しいインデックスでセグメントを返すだろう。

0159

そうでなければ(オペレータが指定されている)、オペランド値は、要求されたセグメント(ステップ1700において取得された「reqSegldx」)のインデックスに対して適用するために(「idxOffset」と命名される)オフセット値を表現する。そのような場合、プッシュされるセグメントは、もしオペレータが「+」ならば[reqSegldx,reqSegldx+idxOffset]範囲、そしてもしオペレータが「−」ならば[regSegldx−idxOffset,regSegldx]内に備えられたインデックスとともにノード内にあるはずである。オペレータの使用は、記述ファイル内部の第1のメディアデータの対応するメディアデータ属性(単数または複数)に対する第2の非要求メディアデータのメディアデータ属性(単数または複数)を定義することを可能にする。

0160

例えば、以下のプッシュポリシーを考えてみよう。
1.<PushPolicy Representationldx=“−1” Segmentldx=“2”/>
2.<PushPolicy Periodldx=“+1” Segmentldx=”+2/>
3.<PushPolicy Periodldx=“+0” Segmentldx=”+2/>
PushPolicy#1は、要求されたセグメントのリプレゼンテーションノードに先行するリプレゼンテーションノード内のインデックス2のセグメントをサーバがプッシュすることになる、ということを指定する。

0161

PushPolicy#2により、サーバは、現在の期間または以降において、要求されたセグメントに続く2つのセグメントをプッシュすることになる。例えば、図24のセグメント2401を要求すると、セグメント2405および2402がプッシュされることになる。

0162

PushPolicy#3は、PushPolicy#2に対して非常に類似し、主な差は、要求されたセグメントがPeriodの最後から2番目の時のものである。例えば、2401を要求する場合、現在の期間における最後セグメント2405のみが(2つのセグメントの代わりに)プッシュされることになる。PushPolicy#3により、Periodldxは、要求されたセグメントのPeriodノードに対してセグメント検索を制限しており、したがって、(要求されたセグメントがPeriod内の最後から2番目のセグメントであるので)Periodの最後のセグメントのみがプッシュされる。それどころか、PushPolicy#2により、セグメントは、次の期間から取りだすことができる。

0163

代替案において、またはオプションの値として、オペランドの値は、また、あらゆるセグメントがプッシュされるべきであるということを意味する「<*>」(ワイルドカードを意味する)であってもよい。オペレータ「+」(それぞれ「−」)に関連付けられていると、それは、要求されたものに対して後続する(各々が先行する)すべてのセグメントがプッシュされるべきであるということを意味する。

0164

この代替案は、クライアントがPushPolicy:<PushPolicy Periodldx=“+0”Segmentldx=“+<*>”>により、例えば1つのPeriodのセグメントをすべて取りだす、単一のHTTP要求のみを送信することを可能にする。

0165

これらの例において、要求された第1のメディアデータに対する(プッシュされる)第2のメディアデータを識別するSegmentldx属性の使用は、第2のメディアデータが第1のメディアデータに隣接することを必要とする。実施形態において、Segmentldx属性は、要求されたセグメントのインデックスに適用するために(オペランドに加えて)オフセットを含んでもよい。これは、所定量のセグメントをプッシュしなければならない基準セグメントのインデックスをシフトする。例として、Segmentldx属性の構文は、次のとおりであっても良い。

0166

プッシュ属性:[オペレータ]オペランド[,オフセット](push attribute:[operator]operand[,offset])
ここで「オフセット」は、要求されたセグメントインデックスに適応するために0とは異なる正または負の整数である。そのような場合、サーチ範囲は、オペレータが「+」であれば[reqSegldx+offset,reqSegldx+idxOffset+offset]、およびオペレータが「−」であれば[reqSegldx−idxOffset+offset,reqSegldx+offset]である。

0167

プッシュポリシーの構文は、また、プッシュされているプレゼンテーション内に最大サイズのデータまたは時間のような(非制限的な)条件をそれぞれ含むことができる。例えば、
<PushPolicy Segmentldx=’+<*>[size<500000]’>は、多くとも500キロバイトのセグメントデータをプッシュするプッシュポリシーを定義する。

0168

<PushPolicy Segmentldx=’+<*>[time<0:01:30]’>は、多くとも1分30秒の次のセグメントデータを転送するプッシュポリシーを定義する。

0169

上記の例が、どのセグメントをプッシュしなければならないのかを判定するプッシュポリシーを宣言する方法を示している一方で、セグメントがプッシュされることになる好ましい順序を指定する必要もあるかもしれない。この情報も、クライアントとサーバとの間で共有されるべきである。

0170

例として、図7〜図12を参照して上記したプッシュされたセグメントの送信の順序の宣言を、適用することができる。

0171

プッシュされたセグメントの送信の順序の1つの代替の実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに1つのプライオリティ属性(例えば「priorityldx」)があり、第2のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。記述ファイルの送信のおかげで、クライアントは、また、これらのプライオリティ属性によって得られた値に気づいており、したがって、意図された送信の順序を決定することができる。

0172

図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のビット値バイナリ型)により与えるだろう。

0173

priorityldx=’00010001000000100000000000000001’
priorityldx値を用いる主な効果は、個別のRepresentation(通常は、ビデオの代替ビューなどの関連リプレゼンテーション)からセグメント間のプライオリティ順を定義することを可能にすることである。プッシュポリシーが個別のRepresentationセットのセグメントの送信にあると有用である。1つの層からのセグメントが1つ以上の他の層をもつセグメントによりインターリーブされる場合、通常の使用事例は、層状ビデオ(マルチビューにおけるビューである層またはスケーラブルビデオにおけるスケーラビリティ層)のストリームのためのものである。

0174

図17戻り、サーバは、MPDファイル内に定義されるようなプッシュポリシーに基づいて、ステップ1701において、プッシュされるセグメントの数を決定する。この数は、Segmentldx属性値から直接推測される。すなわち、オペレータが属性値内で用いられなければ、この数は1に等しく、そうでなければ(オペレータは「−」または「+」である)、数は、オペランド値に等しく、オペランドが「<*>」であれば無限である(但し他の制約によって、および既存のセグメントの数によって、限定される)、と想定される。

0175

次に、プッシュするセグメントの数がプッシュされるセグメントの各々をマークするところに達する(テスト1702)まで、ステップ1702〜1705から構成される反復処理は、ストリーミングサーバによって適用される。
各々の反復に対して、サーバは、ステップ1703において、PushPolicy制約(Adaptation Set、Representation、Period、およびSegment制約およびオプションの条件)に関する、MPDファイル内に定義されたセグメントのリストを取りだす。

0176

セグメントのリストが空であるか、またはすべてのセグメントが既にマークされていれば(テスト1704)、処理は終了し、サーバはクライアントの要求に対して応答を送信し始める(上記のステップ102)。

0177

そうでなければ、リストの第1のセグメントは、ステップ103(PUSH_PROMISE)および104(プロミスされたセグメント)の間にプッシュされるのと同様に、ステップ1705においてマークされる。

0178

プッシュポリシーを宣言する、これらのMPDに基づく例において、1つのプッシュポリシーは、PushPolicy要素を用いて定義される(図16の1600を参照)。

0179

記述ファイルが、複数のメディアデータ属性レベル(すなわち、以上で定義されたPeriod、AdaptationSet、Representation要素)を用いて、メディアデータを記述することが、ここで想起される。

0180

上記のものに対するわずかな変形として、様々な共有されたプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義されてもよい。これは、メディアストリームのコンテンツに対してプッシュ戦略を適応するために、関係するレベル(Adaptation Set、Representation、Period)に依存する様々なプッシュポリシーを定義することができる、ということである。

0181

これは図23を通じて示され、ここで、Representationレベルにおいて、プッシュポリシーが、所望のレベルにて、例えば「SupplementalProperty」記述子を用いて定義される。

0182

<MPD>レベルごとにプッシュポリシーを用いることは、メディアにわたって定数および同じプッシュ戦略を有することを可能にする。

0183

<Period>レベルごとにプッシュポリシーを用いることは、時間に沿って変化できるプッシュ戦略を有することを可能にする。

0184

<AdaptationSet>レベルごとにプッシュポリシーを用いることは、メディアに適したプッシュ戦略を有することを可能にする。

0185

<Representation>レベルごとにプッシュポリシーを用いることは、メディア特性(帯域幅…)に適することができるプッシュ戦略を有することを可能にする。

0186

図23の例において、Representationレベルにおいて指定されるプッシュポリシーは、プッシュデータとともにあまりにも多くの帯域幅を用いないようにするために、高いビットレートのビデオ(2301)よりも低ビットレートビデオセグメント(2300)のために、よりさらにセグメントをプッシュするように構成される。

0187

プッシュ属性の構文に関しての上記の説明も、また、このわずかな変形に適用されてもよい、ということに留意されたい。特に、プッシュポリシーは、新たな要素(図16のように)としてマニフェストにおいて、または(図23のように)新たなschemeldUriにより既存の記述子を用いて、または(表現されていない)新たな記述子として、またはMPDスキーマ若しくはMPDスキーマの拡張ポイント適合するいずれかの手段として、信号で送ることができる。

0188

MPDは、また、各自が一意の識別子を有する、代替的なPUSHポリシーのリストを含むこともできる(以下のリストに関するさらなる説明を参照)。

0189

他の代替の実施形態において、プッシュポリシーは、相補的なRepresentationのためのセグメントが系統的にプッシュされる、ということを、例えば以下の構文を用いて定義してもよい。

0190

<push_policy Segments=’+complementary’>または、DASH記述子を用いる場合は、value=’complementary’層状ビデオの場合には、これは、要求されたビデオセグメントに対して、相補的なRepresentationとして宣言されるすべてのRepresentationから同時に各セグメントも(通常は、異なるRepresentation間の依存性を信号で送るMPD内のdependencyld属性を通じて)プッシュされるだろう、ということを意味する。

0191

別のプッシュポリシーは、また、@associationld属性またはrole=’supplementary’により信号で送られる、関連するRepresentationからのセグメントのプッシュにある。

0192

完全にサーバで駆動されるストリーミングの場合には、プッシュポリシーは、サーバ挙動が「積極的」(若しくは「楽観的」)または「保守的」でなければならないか否かの情報、すなわち、それぞれ高品質のセグメントをプッシュしようとする、または同じ品質レベル(帯域幅を維持する)でプッシュしようとするか否かの情報を提供することができるであろう。

0193

他の実施形態において、プッシュポリシーは、専用のHTTPヘッダとして見なされる「プッシュポリシー」ヘッダ内で送信される。すなわち、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたHTTPフレームのヘッダ内に埋め込まれる。

0194

これらの実施形態は、上記のように、それらがもはやMPDファイルの送信に依存せず、クライアントおよびサーバがHTTP/2プロトコルを用いて交換するので、プッシュポリシーを経時的に変化させることを可能にする。

0195

図18は、HTTP「プッシュポリシー」ヘッダ(ヘッダ名「プッシュポリシー」は、単なる例である)内で送信されるプッシュポリシーでの、サーバとクライアントとの間の通信の例である。

0196

プッシュポリシーヘッダは、プッシュ属性のリスト(プッシュされるデータ上の制約を各々定義する)を含む。特に、先に記述されたPushPolicyの構文は、HTTPヘッダ構文に書き換えられてもよい。

0197

図18aにおいて、クライアント(矢印1800)からのMPD要求に応答してサーバは、プッシュポリシーを共有するために、送信されたMPDに伴うHTTPヘッダ内のプッシュポリシーを送信する(ステップ1801)。

0198

例えば、プッシュポリシーは、要求されたセグメントを追従するセグメントがプッシュされることになる、ということを指定する。結果として、クライアントがセグメントデータ1.1を要求する(矢印1802)と、サーバは、セグメントデータ2.1のためのPUSH_PROMISEと(矢印1803)、そしてセグメントデータ1.1(矢印1804)のデータを送信する。

0199

後続のセグメント要求のためにどのデータが送信されようとするのかを定義するために、任意の構文:MPD特有のものまたはDOMツリーノードトラバースに基づいたより抽象的なものを用いることができる。

0200

動的に共有されたプッシュポリシーに専用の特定の実施形態において、クライアントは、特定のプッシュポリシーを要求してもよい。すなわち、例えば現在共有されたプッシュポリシーがそのニーズに適していなければ、共有されたプッシュポリシーを更新してもよいし、または改善してもよい。

0201

それは、クライアント装置がHTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をサーバ装置に対して送信する、ということを意味する。それに対応して、サーバ装置は、HTTPフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をクライアント装置から受信する。サーバ装置は、したがって、クライアント装置(例えば次の要求のための)によって要求された他のメディアデータから非要求メディアデータを決定する前に、共有されたプッシュポリシーをそれに応じて更新してもよい。

0202

実施形態において、クライアントからのプッシュポリシー要求は、「プッシュポリシー要求」という名の(ここでの名称は単なる例である)HTTPヘッダまたは要求内で伝達される。

0203

図18bは、クライアントが新たなプッシュポリシーを要求した場合のクライアント・サーバ間の例示的な交換を示す。

0204

交換の始まりは、図18aと同じである。

0205

セグメントデータ2.1を受信した後、クライアントは、例えば利用可能な帯域幅が、セグメント要求に応答してさらなるセグメントをサーバにプッシュさせるのに十分に安定しているので、現在のプッシュポリシーが修正されるべきである、ということを識別する。

0206

結果として、クライアントは、ステップ1805において、各々の新たな要求毎に、さらなるセグメント(1の代わりに3)をプッシュするようにサーバに依頼するプッシュポリシー要求を送信する。

0207

サーバは、ステップ1806において、OK200によりこのプッシュポリシー要求に肯定的に回答する。この肯定的な回答は、同じクライアントからいずれかの新たな要求に対するプッシュポリシー要求内に記述された新たなプッシュポリシーをサーバが用いることになる、ということを意味する。

0208

サーバがそのプッシュポリシーを変更したくないならば、それはプッシュポリシー要求が拒否されている、ということをクライアントに通知するためのエラーコード回答を返す。

0209

次に、クライアントが、ステップ1807において、次のセグメントデータ3.1を要求すると、サーバは、ステップ1808において、次の3つのセグメントデータ4.1、データ5.1、およびデータ6.1に対してPUSH_PROMISEにより回答する。

0210

図21は、プッシュポリシーの共有のためにHTTP要求を用いる場合のサーバ側における処理のステップを、フローチャート用いて示し、その一方で、図22は、プッシュポリシーを共有するためにHTTP要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて示す。

0211

図14の処理との比較において、サーバは、クライアントからのプッシュポリシー要求を取り扱い、かつまた初期のプッシュポリシーを送信してそれを更新する、新たな処理ステップ(2100〜2105)を含む。

0212

サーバによって受信された要求がクライアントからのプッシュポリシー要求であるならば(テスト2100)、サーバは、まず、クライアントによって提案されたデータプッシュの制約を抽出するために、ステップ2101において、プッシュポリシー要求を解析する。

0213

このステップの間、サーバは、クライアントによって要求されたプッシュポリシーに従うことを決定してもよい。そのような場合、サーバは、その内部のプッシュポリシーを更新し(ステップ2102)、提案されたプッシュポリシーを検証するために、ステップ2103において、クライアントに対してOK200の応答を送信する。

0214

そうでなければ、サーバがプッシュポリシーを廃棄すると(例えば提案されたポリシーがリソースの観点からコストのかかりすぎる、または適用することができないので)、ステップ2102ではサーバにおいて内部プッシュポリシーを修正しない。また、エラーコードが、ステップ2103において、クライアントに対して送信される。

0215

具体的な実施形態によれば、サーバは、クライアントの要求とは無関係に、そのプッシュポリシーをさらに更新してもよい。そのような場合、サーバは、ステップ1402の間に、プッシュポリシーを決定し、その特性(例えばクライアントおよびネットワークの特性によって実行された要求の解析による)を変更することを決定しても良いし、または、決定されたプッシュポリシーが現在のものとは異なるということを理解しても良い。このような状況において、サーバは、後者がそれにまだ気づいていなければ(テスト2104)、クライアントと新たなプッシュポリシーを共有しなければならず、その場合には、新たなプッシュポリシーは、ステップ2105において、HTTPヘッダ内で送信される。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ