JP6918910B2 - メディアデータの提供方法、メディアデータの受信方法、及びプログラム - Google Patents

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

Info

Publication number
JP6918910B2
JP6918910B2 JP2019223944A JP2019223944A JP6918910B2 JP 6918910 B2 JP6918910 B2 JP 6918910B2 JP 2019223944 A JP2019223944 A JP 2019223944A JP 2019223944 A JP2019223944 A JP 2019223944A JP 6918910 B2 JP6918910 B2 JP 6918910B2
Authority
JP
Japan
Prior art keywords
client
server
push
data
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019223944A
Other languages
English (en)
Other versions
JP2020047303A (ja
Inventor
ファブレ ユアン
ファブレ ユアン
ベルソール ロマン
ベルソール ロマン
マゼ フレデリック
マゼ フレデリック
ウエドラオゴ ナエル
ウエドラオゴ ナエル
ドゥヌアル フランク
ドゥヌアル フランク
ルーラン エルヴェ
ルーラン エルヴェ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB1312547.1A external-priority patent/GB2516112B/en
Priority claimed from GB1312561.2A external-priority patent/GB2516116B/en
Application filed by Canon Inc filed Critical Canon Inc
Publication of JP2020047303A publication Critical patent/JP2020047303A/ja
Application granted granted Critical
Publication of JP6918910B2 publication Critical patent/JP6918910B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

関連出願の相互参照
本出願は、英国特許出願第１３１２５４７．１号および第１３１２５６１．２号（ともに２０１３年７月１２日）、並びに第１４１０５４０．７号（２０１４年６月１２日）からの優先権を主張し、それらは参考文献としてすべて本明細書に援用される。
本発明は、ＨＴＴＰ通信ネットワーク上のデータストリーミングに関する。
特に、本発明はネットワーク制約を満たすための適応型データストリーミングに関する。本発明は、ＤＡＳＨネットワークにおけるアプリケーションを有してもよい。
ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（動的適応型ＨＴＴＰストリーミング）の頭文字）は、ＨＴＴＰ上のメディアコンテンツストリーミング（通常はオーディオ／ビデオコンテンツ）を可能にする通信規格である。ＤＡＳＨによれば、メディアプレゼンテーションは、「メディアプレゼンテーション記述」ファイル（以下において、ＭＰＤ）と呼ばれるＸＭＬファイルとして記載される。ＭＰＤファイルは、クライアント装置がメディアコンテンツの配信を要求し制御することを可能にする情報を、クライアント装置に提供する。
ＨＴＴＰメディアストリーミングの一般的原理は、図３に示される。適応型ＨＴＴＰメディアストリーミングのための新たなプロトコルおよび標準のほとんどは、この原理に基づく。
メディアサーバ３００は、クライアント３１０に対してデータをストリーミングする。メディアサーバは、メディアプレゼンテーションを保存する。例えば、メディアプレゼンテーション３０１は、オーディオデータおよびビデオデータを含む。オーディオおよびビデオは、同じファイル内でインターリーブされてもよい。メディアプレゼンテーションが構築される方法は、図４ａを参照しながら以下に記載される。メディアプレゼンテーションは、独立してアドレス指定されてダウンロードされることができるＭＰ４セグメントなどの、小さな独立した連続する時間セグメント３０２ａ、３０２ｂおよび３０２ｃに一時的に分割される。これらの時間セグメントの各々のためのメディアコンテンツのダウンロードアドレス（ＨＴＴＰ ＵＲＬ）は、クライアントに対してサーバによって設定される。オーディオ／ビデオメディアコンテンツの各時間セグメントは、１つのＨＴＴＰアドレスに関連づけられている。
メディアサーバは、また、メディアコンテンツ特性（例えば、メディアのタイプ：オーディオ、ビデオ、オーディオビデオ、テキストなど）、コード化形式（例えば、ビットレート、タイミング情報など）、時間メディアセグメントと関連するＵＲＬとのリストを含むメディアプレゼンテーションのコンテンツを記述する（図５を参照ながら以下に記載される）マニフェストファイルドキュメント３０４を保存する。または、ドキュメントは、時間メディアセグメント及び関連するＵＲＬとの明示的なリストを再構築可能にするテンプレート情報を含む。このドキュメントは、エクステンシブルマークアップランゲージ（ＸＭＬ）を用いて記載されてもよい。
マニフェストファイルは、クライアントに対して送信される。ステップ３０５の間にマニフェストファイルの受信をすると、クライアントには、メディアコンテンツの時間セグメントとＨＴＴＰアドレスとの間の関連づけが通知される。また、マニフェストファイルは、メディアプレゼンテーションのコンテンツに関する情報（本例にではインターリーブされたオーディオ／ビデオ）をクライアントに提供する。情報は、解像度、ビットレートなどを含んでもよい。
受信された情報に基づいて、クライアントのＨＴＴＰクライアントモジュール３１１は、マニフェストファイル内に記載されたメディアコンテンツの時間セグメントのダウンロードのためにＨＴＴＰ要求３０６を発行することができる。サーバのＨＴＴＰ応答３０７は、要求された時間セグメントを伝達する。ＨＴＴＰクライアントモジュール３１１は、応答から時間メディアセグメントを抽出し、メディアエンジン３１２の入力バッファ３０７に対してそれらを提供する。最終的に、メディアセグメントは、ステップ３０８および３０９のそれぞれの間に復号されて表示されることができる。
メディアエンジン３１２は、次の時間セグメントが適切な時期に発行されるように要求するために、ＤＡＳＨ制御エンジン３１３と情報のやりとりをする。次のセグメントは、マニフェストファイルから識別される。要求が発行される時期は、受信バッファ３０７が満杯であるか否かに依存する。ＤＡＳＨ制御エンジン３１３は、バッファが過負荷になるかまたは完全に空になるのを防ぐようにバッファを制御する。
メディアプレゼンテーションおよびマニフェストファイルの生成を、図４ａを参照して説明する。ステップ４００および４０１の間に、オーディオデータおよびビデオデータが取得される。次に、オーディオデータは、４０２の間に圧縮される。例えば、ＭＰ３規格を用いることができる。また、ビデオデータは、ステップ４０３の間に並行して圧縮される。ＭＰＥＧ４、ＭＰＥＧ／ＡＶＣ、ＳＶＣ、ＨＥＶＣ、またはスケーラブルＨＥＶＣなどのビデオ圧縮アルゴリズムを用いることができる。オーディオデータおよびビデオデータの圧縮が一旦実行されれば、オーディオビデオエレメンタリーストリーム４０４およびビデオエレメンタリーストリーム４０５は、利用可能になる。エレメンタリストリームは、ステップ４０６の間に、グローバルメディアプレゼンテーションにカプセル化される。例えば、ＩＳＯ ＢＭＦＦ規格（またはＩＳＯ ＢＭＦＦ規格をＡＶＣ、ＳＶＣ、ＨＥＶＣ、ＨＥＶＣのスケーラブル拡張などに拡張する）は、符号化されたオーディオエレメンタリーストリームおよびビデオエレメンタリーストリームのコンテンツをグローバルメディアプレゼンテーションとして記述するために使用することができる。それによって取得されたカプセル化されたメディアプレゼンテーション４０７は、ステップ４０８の間に、ＸＭＬマニフェストファイル４０９を生成するために用いられる。ビデオデータ４０１およびオーディオデータ４００のいくつかのリプレゼンテーションは、取得され、圧縮され、カプセル化され、メディアプレゼンテーション４０７内に記載することができる。
図４ｂに示されたＭＰＥＧ／ＤＡＳＨストリーミングプロトコルの特定のケースに関して、マニフェストファイルは、「メディアプレゼンテーション記述」（または「ＭＰＤ」ファイル）と呼ばれる。ファイルのルート要素は、プロファイルまたはスキーマのようなＤＡＳＨ情報を加えたすべてのプレゼンテーションに適用する属性を含むＭＰＤ要素である。メディアプレゼンテーションは、Ｐｅｒｉｏｄ要素によって表される時間的期間に分割される。ＭＰＤファイル４１０は、各時間的期間に関連するデータをすべて含む。この情報を受信することによって、クライアントは、各々の期間ごとのコンテンツを認識する。Ｐｅｒｉｏｄ４１１ごとに、ＡｄａｐｔａｔｉｏｎＳｅｔ（アダプテーションセット）要素が定義される。
可能な構成は、プレゼンテーション内に含まれるメディアタイプ当たり１つ以上のＡｄａｐｔａｔｉｏｎＳｅｔを有することである。ビデオに関連するＡｄａｐｔａｔｉｏｎＳｅｔ４１２は、サーバにおいて利用可能な符号化されたビデオの異なる可能的なリプレゼンテーションに関する情報を含む。各リプレゼンテーションは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素内に記述される。例えば、第１のリプレゼンテーションは、６４０×４８０の空間解像度で符号化され、且つ５００ｋビット／秒のビットレートで圧縮されたビデオになり得る。第２のリプレゼンテーションは、同じビデオになり得るが、２５０ｋビット／秒のビットレートで圧縮され得る。
クライアントが各ビデオに関するＨＴＴＰアドレスを知っている場合、各ビデオは、その後、ＨＴＴＰ要求によってダウンロードすることができる。各リプレゼンテーションのコンテンツとＨＴＴＰアドレスとの間の関連づけは、付加的なレベルの記述：時間セグメントを用いることによって行われる。各ビデオリプレゼンテーションは、時間セグメント４１３（通常は数秒）に分割される。各時間セグメントは、ＨＴＴＰアドレス（ＵＲＬまたは１バイトレンジのＵＲＬ）を介してアクセス可能なサーバに保存されたコンテンツを備える。いくつかの要素は、ＭＰＤファイル：ＳｅｇｍｅｎｔＬｉｓｔ（セグメントリスト）、ＳｅｇｍｅｎｔＢａｓｅ（セグメントベース）またはＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ（セグメントテンプレート）内に時間セグメントを記述するために用いることができる。
さらに、特定のセグメント：イニシャライゼーションセグメントが利用可能である。イニシャライゼーションセグメントは、（ＩＳＯ ＢＭＦＦまたはその拡張を用いてビデオがカプセル化されているならば）カプセル化されたビデオストリームを記述するＭＰ４イニシャライゼーション情報を含む。例えば、それは、クライアントがビデオに関する復号アルゴリズムをインスタンス化するのを支援する。
イニシャライゼーションセグメントおよびメディアセグメントのＨＴＴＰアドレスは、ＭＰＤファイル内に示される。
図５に、例示的なＭＰＤファイルが示される。２つのメディアが、図示されたＭＰＤファイル内に記述される。第１のものは英語のオーディオストリームであり、第２のものはビデオストリームである。英語のオーディオストリームは、ＡｄａｐｔａｔｉｏｎＳｅｔタグ５００を用いて導入される。２つの代替的リプレゼンテーションが、このオーディオストリームのために利用可能である。
・第１のリプレゼンテーション５０１は、６４０００ビット／秒のビットレートでＭＰ４にカプセル化されたエレメンタリオーディオストリームである。この（ＭＰ４構文解析後の）エレメンタリストリームを取り扱うために用いられるコーデックは、値「ｍｐ４ａ．０ｘ４０」を有する属性コーデックによって規格内に定義されている。それは、セグメント階層内のＢａｓｅＵＲＬ（ベースＵＲＬ）要素：相対的なＵＲＩである＜ＢａｓｅＵＲＬ＞７６５７４１２３４８．ｍｐ４＜／ＢａｓｅＵＲＬ＞の連結によって形成されたアドレスにおける要求を介してアクセス可能である。「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／」によって、または「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／」によってＭＰＤ要素内のトップレベルにおいて定義される〈ＢａｓｅＵＲＬ〉（２つのサーバが同じコンテンツのストリーミングのために利用可能である）は、絶対ＵＲＩである。そして、クライアントは、その要求から、アドレス「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／７６５７４１２３４８．ｍｐ４」またはアドレス「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／７６５７４１２３４８．ｍｐ４」に対して、英語のオーディオストリームを要求することができる。
・第２のリプレゼンテーション５０２は、３２０００ビット／秒のビットレートでＭＰ４にカプセル化されたエレメンタリオーディオストリームである。第１のリプレゼンテーション５０１と同じような説明を行うことができ、クライアント装置は、したがって、以下のアドレスのいずれか１つにおける要求によって、この第２のリプレゼンテーション５０２を要求することができる。
「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／３４６３６４６３４６．ｍｐ４」または
「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／３４６３６４６３４６．ｍｐ４」。
ビデオに関連するアダプテーションセット５０３は、６つのリプレゼンテーションを含む。これらのリプレゼンテーションは、異なる空間解像度（３２０×２４０、６４０×４８０、１２８０×７２０）、および異なるビットレート（２５６０００〜２０４８０００ビット／秒）のビデオを含む。これらのリプレゼンテーションの各々に対して、それぞれのＵＲＬは、ＢａｓｅＵＲＬ要素を通じて関連づけられる。そのため、クライアントは、推定された帯域幅、スクリーン解像度などの異なる基準にしたがって同じビデオのこれらの代替リプレゼンテーションの間で選択することができる。（図５において、時間セグメントへのＲｅｐｒｅｓｅｎｔａｔｉｏｎの分解は、明瞭にするために図示されていない、ということに留意されたい。）
図５ａは、ＤＡＳＨクライアントの標準的挙動（ｓｔａｎｄａｒｄ ｂｅｈａｖｉｏｒ）を示す。図５ｂは、図４ａに示された方法において用いられる、例示的なマニフェストファイル（記述ファイルまたはＭＰＤ）のツリー表現を示す。
ストリーミングセッションを開始する場合、ＤＡＳＨクライアントは、マニフェストファイルを要求することによって開始する（ステップ５５０）。サーバの応答を待ってマニフェストファイルを受信した後（ステップ５５１）、クライアントは、マニフェストファイルを解析し（ステップ５５２）、その環境に適したＡｄａｐｔａｔｉｏｎＳｅｔｓのセットＡＳｉｊを選択し（ステップ５５３）、それから、例えば、その帯域幅、復号化、およびレンダリング機能に適したＭＰＤ内のＲｅｐｒｅｓｅｎｔａｔｉｏｎを各ＡｄａｐｔａｔｉｏｎＳｅｔ ＡＳｉｊ内で選択する（ステップ５５４）。
そして、ＤＡＳＨクライアントは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求するセグメントのリストを予め構築することができる。このイニシャライゼーションセグメントは、それが複数のリプレゼンテーション、アダプテーションセットおよび期間に共通になり得るか、または各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに特有になり得るか、または第１のメディアセグメント内にも含まれ得るので、このＭＰＤ（ステップ５５５）内で、識別されなければならない。
そして、クライアントは、イニシャライゼーションセグメントを要求する（ステップ５５６）。一旦イニシャライゼーションセグメントが受信されると（ステップ５５７）、復号器が起動される（ステップ５５８）。
そして、クライアントはセグメント単位で第１のメディアデータを要求し（ステップ５６０）、復号化を実際に開始して表示する（ステップ５６３）前に、（ステップ５５９の条件のために）最小データ量をバッファする。ＭＰＤダウンロードと最初に表示されたフレームとの間のこれら複数の要求／応答は、ストリーミングセッションにおける起動遅延（ｓｔａｒｔｕｐ ｄｅｌａｙ）を招く。これらの初期ステップの後、ＤＡＳＨストリーミングセッションは、標準的方法で継続する、すなわち、ＤＡＳＨクライアントは、メディアセグメントを順々に適応させてリクエストする。
現在のＤＡＳＨバージョンは、マニフェストファイル内部の関心領域の記述を提供しない。いくつかのアプローチが、このような記述のために、提案されてきた。
特に、メディアコンテンツのコンポーネントは、ＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎ（サブリプレゼンテーション）要素を用いて記載することができる。これらの要素は、リプレゼンテーション内に埋め込まれる１つまたはいくつかのコンポーネントのプロパティを記述する。図６に、タイルトラック（ｔｉｌｅ ｔｒａｃｋｓ）をビデオのコンポーネントとして記述するＤＡＳＨマニフェストファイルの例が示される。簡明に且つおよび明瞭にするために、１つのＰｅｒｉｏｄ６００のみを示す。しかしながら、後続の期間要素は、同じ方式で編成されるだろう。部分６０１において、第１のアダプテーションセット要素は、スケーラブルビデオのベース層を記述するために用いられる。例えば、ビデオは、ＳＶＣまたはスケーラブルなＨＥＶＣにしたがって符号化される。部分６０２において、第２のアダプテーションセットはスケーラブルビデオの最高解像度層を記述するために用いられる。非スケーラブルビデオに対して、第２のアダプテーションセット６０２のみが、ベース層に依存することなく（すなわちｄｅｐｅｎｄｅｎｃｙｌｄ属性）、存在するだろう。この第２のアダプテーションセット６０２において、単一のリプレゼンテーション６０３、すなわち表示することができるビデオに対応するもの、が記述される。そのリプレゼンテーションは、クライアント要求のためのそれぞれのＵＲＬとともにセグメント６１０のリストとして記載される。
このように、リプレゼンテーションは、「Ｒ１」（ｄｅｐｅｎｄｅｎｃｙｌｄ属性）によって識別された別のリプレゼンテーション、実際には第１のアダプテーションセット６０１からのベース層リプレゼンテーション、に依存する。依存性は、エンハンスメント層のために現在のセグメントを得る前にベース層のための現在のセグメントを最初に要求することをストリーミングクライアントに強制する。このように参照されるトラックがクライアントによって自動的にロードされるので、これをタイルトラックに対する依存性を表現するためには用いることができない。メディアプレゼンテーションの間にユーザにとって興味のあるタイル（ｔｉｌｅｓ）をいつでも選択することはユーザ次第であるので、これは回避されるべきである。そのため、複合トラックとタイルトラックとの間の依存性を示すために、ＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素が用いられる。表示可能なビデオは、サブリプレゼンテーション６０４〜６０８のリストとして記載される。各サブリプレゼンテーションは、カプセル化されたＭＰ４ファイル内のトラックを実際に表わす。このように、複合トラック６０８に対して１つのタイルを加えた（本例においては４つのタイル）サブリプレゼンテーション当たり１つのサブリプレゼンテーションがある。各サブリプレゼンテーションは、タイルトラック６１４、６１５、６１６、および６１７、または複合トラック６１８に対応するか否かを示すために、コンテンツコンポーネント要素６１４〜６１８によって記述される。ＤＡＳＨ／ＭＰＤにおいて利用可能なロール記述子型は、特定のスキームによるタイリングのために用いられる。ロール記述子は、また、フルフレームビデオ内のタイルの位置を示す。例えば、コンポーネント６１４は、ビデオの左上（先頭行および先頭列の１：１）に位置するタイルを記述する。タイルの寸法、幅および高さは、ＭＰＤによって可能になるようなサブリプレゼンテーションの属性として指定される。帯域幅情報も、また、その帯域幅にしたがって、タイルの数およびタイルの選択の決定においてＤＡＳＨクライアントを支援するためにここに設けることができる。複合トラックに関して、ダウンロードの終わりに、復号することができるビデオストリームを構築することができることが義務的であるので、タイルトラックとは異なる方法で、信号で送らなければならない。その目的のために、２つの要素が記述に加えられる。第１に、関連コンテンツコンポーネント６１８内の記述子は、それがすべてのコンポーネントの中の主要なコンポーネントであることを示す。第２に、対応するデータが要求されるべきであることをクライアントに対して示すために、サブリプレゼンテーション内に、新たな「ｒｅｑｕｉｒｅｄ（必須）」属性が加えられる。複合トラック、またはタイルトラックの１つ以上に対する要求はすべて、セグメントリスト６１０内に提供されるＵＲＬから計算される（１時間間隔当たり１つ）。例では、ＭＰＤの先頭において「ＢａｓｅＵＲＬ」と組み合わされた「ＵＲＬ＿Ｘ」は、ＨＴＴＰ ＧＥＴ要求を実行するためにクライアントが用いることができる完全なＵＲＬを提供する。この要求により、クライアントは、複合トラックのためのデータと、すべてのタイルトラックのためのすべてのデータとを得るだろう。要求の代わりに、伝送を最適化するために、クライアントは、ｉｎｄｅｘ＿ｒａｎｇｅ属性６２０からの利用可能なデータを用いて、セグメントインデックス情報（通常は、当業者により周知のＩＳＯ ＢＭＦＦ内の「ｓｉｄｘ」情報および／または「ｓｓｉｘ」）を第１に要求することができる。このインデックス情報は、コンポーネントの各々のためのバイト単位の範囲を決定することを可能にする。そして、ＤＡＳＨクライアントは、適切なバイト単位の範囲で、（要求された複合トラックを含む）選択されたトラックと同数のＨＴＴＰ ＧＥＴ要求を送信することができる。
ストリーミングセッションを開始するとき、ＤＡＳＨクライアントは、マニフェストファイルを要求する。一旦受信されれば、クライアントは、マニフェストファイルを解析し、その環境に適した１セットのＡｄａｐｔａｔｉｏｎＳｅｔを選択する。次に、クライアントは、各ＡｄａｐｔａｔｉｏｎＳｅｔ内部のＭＰＤにおいて、その帯域幅と互換性をもつＲｅｐｒｅｓｅｎｔａｔｉｏｎ、復号化およびレンダリング機能を選択する。次に、それは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求されるセグメントのリストを予め構築する。イニシャライゼーション情報が復号器によって受信されると、それらはイニシャライズされ、クライアントは、第１のメディアデータを要求し、ディスプレイを実際に開始する前に最小データ量をバッファする。
これらの複数の要求／応答は、ストリーミングセッションの起動における遅延を招くかもしれない。サービスプロバイダにとってのリスクは、ビデオを見始めることなくサービスを離れるクライアント見ることである。クライアントによって実行される第１のメディアデータチャンクのための初期のＨＴＴＰ要求とメディアデータチャンクが実際に再生し始める時間との間の時間を、スタートアップ遅れとよぶことが一般的である。それは、ネットワークラウンドトリップ時間だけでなく、メディアセグメントのサイズにも依存する。
サーバプッシュは、ウェブリソースのローディング時間を減少させるために有用な機能である。このようなサーバは、図１ａ〜図１ｅを参照しながら論じる。
図１ｂでは、ＨＴＴＰ／２交換（ＨＴＴＰ／２ ｅｘｃｈａｎｇｅｓ）において、要求は、必要とされるリソース：（図１ａに示されるように）リソースＲ１〜Ｒ４およびサブリソースＡ〜Ｉごとに送信されなければならない、ということが図示される。しかしながら、サーバによるプッシュ機能を用いるとき、図１ｃに図示されるように、要求の数は、要素Ｒ１〜Ｒ４に制限される。要素Ａ〜Ｉは、図１ａに示される依存性に基づいてサーバによってクライアントに対して「プッシュされ」、それによって、不必要な関連する要求が生じる。
このように、サーバがプッシュ機能を用いる場合、図１ｂおよび図１ｃに図示されるように、そのサブリソースと共にリソースをロードするために必要なＨＴＴＰラウンドトリップ（要求＋応答）の数が減少される。これは、モバイルネットワークなどの高待ち時間のネットワークにとって、とりわけ興味深い。
ＨＴＴＰは、ウェブリソース、通常はウェブページ、を送信するために用いられるプロトコルである。ＨＴＴＰは、クライアントとサーバとを暗に含む。
・クライアントは、サーバに対して要求を送信する。
・サーバは、クライアントの要求に対して、ウェブリソースのリプレゼンテーションを含む応答により返答する。
要求および応答は、様々な部分、特にＨＴＴＰヘッダ、を含むメッセージである。ＨＴＴＰヘッダは、値と共に名称を備える。例えば「Ｈｏｓｔ： ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ」は「Ｈｏｓｔ（ホスト）」ヘッダであり、その値は「ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ」である。それは、問い合わされたリソースのホストを示すために用いられる（例えばＨＴＴＰを記述するウィキペディアページは、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＨＴＴＰにおいて利用可能である）。ＨＴＴＰヘッダは、クライアント要求およびサーバ応答上に出現する。
ＨＴＴＰ／２は、ストリームを通じて要求／応答を交換することを可能にする。ストリームは、ＨＴＴＰ要求および応答ごとにＨＴＴＰ／２接続の内部で生成される。フレームは、要求および応答のコンテンツおよびヘッダを伝達するために、ストリーム内で交換される。
ＨＴＴＰ／２は、以下のような、個別の意味をもつフレームの制限されたセットを定義する。
・ＨＥＡＤＥＲＳ：ＨＴＴＰヘッダの伝送のために提供される
・ＤＡＴＡ：ＨＴＴＰメッセージコンテンツの伝送のために提供される
・ＰＵＳＨ＿ＰＲＯＭＩＳＥ：プッシュされたコンテンツのアナウンスのために提供される
・ＰＲＩＯＲＩＴＹ：ストリームのプライオリティを設定するために提供される
・ＷＩＮＤＯＷ ＵＰＤＡＴＥ：制御フローウィンドウの値を更新するために提供される・ＳＥＴＴＩＮＧＳ：設定パラメータを伝達するために提供される
・ＣＯＮＴＩＮＵＡＴＩＯＮ：ヘッダブロックフラグメントのシーケンスを継続するために提供される
・ＲＳＴ ＳＴＲＥＡＭ：ストリームの終了またはキャンセルのために提供される
サーバによるプッシュは、サーバがクライアントに対して自発的なウェブリソースリプレゼンテーションを送信することを可能にするために、ＨＴＴＰ／２に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク（モバイルネットワーク）上の、ウェブページの低速表示をもたらすであろう。
所定のウェブページに対する要求を受信するとき、サーバは、他のどのリソースが要求されたリソースの完全な処理のために必要とされるのかを知っているであろう。要求されたリソースおよびリンクされたリソースを同時に送信することによって、サーバは、ウェブページのロード時間を減少させることを可能にする。このように、プッシュ機能を用いて、サーバは、所定のリソースが要求されたときに、追加リソースリプレゼンテーションを送信してもよい。
図１ｅのフローチャートを参照して、プッシュ機能を実行するサーバの例示的なオペレーションモードを記述する。
ステップ１００の間、サーバは、初期要求を受信する。次に、サーバは、ステップ１０１の間に応答の一部としてプッシュするリソースを識別し、ステップ１０２の間にコンテンツ応答を送信し始める。並行して、サーバは、ステップ１０３の間にクライアントに対してプッシュプロミスメッセージを送信する。これらのメッセージは、例えば図１ａに示される依存性に基づいて、サーバがプッシュすることを意図している他のリソースを識別する。これらのメッセージは、どのプッシュされたリソースが送信されることになるのかをクライアントに予め知らせるために送信される。特に、これは、同時にプッシュされた、またはプッシュされようとしている、リソースに対して、クライアントが要求を送信する、というリスクを低減する。このリスクをさらに低減するために、サーバは、プッシュプロミス内に記述されるリソースを参照する応答のあらゆる部分を送信する前に、プッシュプロミスメッセージを送信するべきである。これは、また、クライアントがそれらのリソースを望まないならば、クライアントがプロミスされたリソース（ｐｒｏｍｉｓｅｄ ｒｅｓｏｕｒｃｅｓ）のプッシュのキャンセルを要求することを可能にする。次に、サーバは、ステップ１０４の間に、応答およびすべてのプロミスされたリソースを送信する。プロセスは、ステップ１０５の間に終了する。
図１ｄのフローチャートは、クライアント側の処理を示す。
クライアントがサーバから取り出すリソースを識別すると、対応するデータが既にそのキャッシュメモリ内にあるか否かを、ステップ１０６の間にまずチェックする。リソースが既にキャッシュメモリ内にある場合（はい（Ｙｅｓ））、ステップ１０７の間に、そこから取り出される。キャッシュされたデータは、先の要求から取りだされたデータ、またはサーバによって予めプッシュされたデータのいずれかであろう。それがキャッシュメモリ内になかった場合（いいえ（Ｎｏ））、クライアントは、ステップ１０８の間に、要求を送信し、サーバの応答を待つ。サーバからのフレームを受信すると、クライアントは、フレームがプッシュプロミスに対応するか否かを、ステップ１０９の間にチェックする。データフレームがプッシュプロミスに対応するならば（はい（Ｙｅｓ））、ステップ１１０の間、クライアントは、プッシュプロミスを処理する。クライアントは、プッシュされるリソースを識別する。クライアントがリソースを受信したくなければ、クライアントは、エラーメッセージをサーバに対して送信してもよく、そうすれば、サーバは、そのリソースをプッシュしない。そうでなければ、クライアントは、対応するプッシュコンテンツを受信するまでプッシュプロミスを保存する。サーバがそれをプッシュしている間に、クライアントがプロミスされたリソースを要求しないように、プッシュプロミスが用いられる。データフレームがプッシュプロミスに対応しない場合（いいえ（Ｎｏ））、ステップ１１１の間に、フレームがプッシュデータに関連するデータフレームであるか否かがチェックされる。それがプッシュデータに関する場合（はい（Ｙｅｓ））、クライアントは、ステップ１１２の間に、プッシュされたデータを処理する。プッシュされたデータは、クライアントのキャッシュ内に保存される。フレームがプッシュデータに関するデータフレームではない場合（いいえ（Ｎｏ））、ステップ１１３の間に、サーバから受信された応答にそれが対応するか否かがチェックされる。フレームがサーバからの応答に対応する場合（はい（Ｙｅｓ））、応答は、ステップ１１４の間に処理される（例えば、アプリケーションに対して送信される）。そうでなければ（いいえ（Ｎｏ））、フレームが応答の終了を識別するか否か（はい（Ｙｅｓ））が、ステップ１１５の間にチェックされる。この場合、処理は、ステップ１１６の間に終了する。そうでなければ、処理は、ステップ１０９に戻る。
このように、クライアントが応答およびプロミスされたリソースを受信する、ということが思われる。そのため、取りだされたウェブページを表示するブラウザなどのアプリケーションによって応答が用いられる間に、プロミスされたリソースは、一般的には、クライアントのキャッシュ内に保存される。クライアントアプリケーションがプッシュされたリソースの１つを要求するとき、リソースは、いかなるネットワーク遅延も引き起こさずに、クライアントのキャッシュから直ちに取りだされる。
キャッシュ内のプッシュされたリソースの保存は、キャッシュ制御指示を用いて制御される。キャッシュ制御指示は、また、応答の制御のために用いられる。これらの指示は、特に、プロキシに対して適用可能であり、プッシュされた若しくはプッシュされない任意のリソースは、プロキシ若しくはクライアントのみによって保存されてもよい。
図１ａは、それらの関連性とともにサーバによって所有された１セットのリソースのグラフである。リソースのセットは、以下のように関連し合う。すなわち、Ｒ１、Ｒ２、Ｒ３、およびＲ４は、クライアントによって適切に処理されるために一緒にダウンロードされる必要のあるリソースである。さらに、サブリソースＡ〜Ｈが定義される。これらのサブリソースは、１つ、２つ、または３つのリソースに関連する。例えば、Ａは、Ｒ１に対してリンクされ、Ｃは、Ｒ１、Ｒ２、およびＲ４に対してリンクされる。
既に上述した図１ｂは、サーバＰＵＳＨ機能を用いないＨＴＴＰ交換を示しており、クライアントは、Ｒ１を要求し、次にＲ２、Ａ、Ｂ、Ｃ、およびＤを発見し、それらを要求する。それらを受信した後、クライアントは、Ｒ３、Ｒ４、Ｆ、およびＧを要求する。最終的に、クライアントは、ＨおよびＩのサブリソースを要求する。これは、リソースの全体のセットを検索するために４つのラウンドトリップを必要とする。
既に上述した図１ｃは、サーバによって直接的に接続されるサブリソースをプッシュする機能を用いたＨＴＴＰ交換を示す。Ｒ１を要求した後、サーバは、Ｒ１を送信し、Ａ、Ｂ、Ｃ、およびＤをプッシュする。クライアントは、Ｒ２を識別し、それを要求する。サーバは、Ｒ２を送信し、ＦおよびＧをプッシュする。最終的に、クライアントは、Ｒ３、Ｒ４を識別し、これらのリソースを要求する。サーバは、Ｒ３、Ｒ４を送信し、ＨおよびＩをプッシュする。これは、リソースの全体のセットを取りだすために３つのラウンドトリップを必要とする。
１セットのリソース、通常はウェブページおよびそのサブリソース、のローディング時間を減少させるために、ＨＴＴＰ／２は、複数の要求および応答のプライオリティを並列に交換することを可能にする。図２に図示されるように、ウェブページは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、画像などのような、いくつかのリソースのダウンロードを要求してもよい。初期のＨＴＴＰ交換２００の間に、クライアントは、ＨＴＭＬファイルを検索する。このＨＴＭＬファイルは、２つのＪａｖａ（登録商標）Ｓｃｒｉｐｔファイル（ＪＳ１、ＪＳ２）、２つの画像（ＩＭＧ１、ＩＭＧ２）、１つのＣＳＳファイル、および１つのＨＴＭＬファイルに対するリンクを含む。交換２０１の間に、クライアントは、各ファイルに対する要求を送信する。図２の交換２０１において与えられる順序は、ウェブページの順序に基づき、クライアントは、リンクが見つかるとすぐに、要求を送信する。そして、サーバは、ＪＳ１、ＣＳＳ、ＩＭＧ１、ＨＴＭＬ、ＩＭＧ２、およびＪＳ２に対する要求を受信し、その順序に従ってこれらの要求を処理する。そして、クライアントは、その順序で、これらのリソースを取りだす。
ＨＴＴＰプライオリティは、どの要求がより重要であり且つ他の要求より早く処理されるべきであるかを、クライアントに明示することを可能にする。特定のプライオリティの使用を、交換２０２に示す。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイルは、最も高いプライオリティを割り当てられる。ＣＳＳおよびＨＴＭＬファイルは、中プライオリティを割り当てられ、画像は、低プライオリティを割り当てられる。このアプローチにより、ブロッキングファイル、または他のファイルより早く他のリソースに対する参照を含むことができるファイルを受信することができる。これを受けて、交換２０２に記述されるように、サーバは、まずＪａｖａ（登録商標）Ｓｃｒｉｐｔファイル、その後ＣＳＳおよびＨＴＭＬファイル、最後には画像を、送信することを試みることが期待される。サーバは、クライアントプライオリティに従うようには義務付けられていない。
プライオリティに加えて、ＨＴＴＰ／２は、同時に交換されるデータ量を制御することができる、ということを提供する。クライアントおよびサーバは、接続ベース当たりおよびストリームベース当たりのバッファリングすることができるデータ量を指定することができる。これは、ＴＣＰ輻輳制御と同様であり、利用可能なバッファサイズを指定するウィンドウサイズは、所定の値にイニシャライズされ、エミッタがデータを送信するたびに、ウィンドウサイズは減少し、エミッタは、ウィンドウサイズが０より下にならないようにデータの送信を停止しなければならない。受信器は、データを受信し、データがバッファから受信され取り出されたということを通知するメッセージを送信し、メッセージは、バッファから取り出されたデータ量を含んでおり、そして、ウィンドウサイズが所定の値から増加され、エミッタは、データを送信することを再開することができる。
上記を考慮すると、クライアントは実行しているアプリケーションの目的のためにコンテンツのベストのリプレゼンテーションを一般的には選択することができるので、ＤＡＳＨは、クライアントがストリーミングをリードするという前提に基づくように思われる。例えば、クライアントは、そのフォームファクタおよびスクリーン解像度に基づいて高解像度または小解像度のコンテンツを要求するべきかどうかを認識していてもよい。
サーバベースのストリーミングは、通常は、ＲＴＰを用いて実行される。ＤＡＳＨとは対照的に、ＲＴＰは、ＨＴＴＰを用いず、ウェブインフラストラクチャ、特にプロキシ、キャッシュから直接的に恩恵を受けることができない。ウェブソケットベースのメディアストリーミングは、同じ短所を持つ。ＨＴＴＰ／１．１では、サーバがクライアント要求に対して一般的には答えることしかできないので、サーバベースのストリーミングは、容易に実行することができない。ＨＴＴＰ／２では、特にプッシュ機能の導入では、ＤＡＳＨベースのサーバは、ストリーミングを通すことができる。このように、サーバは、ユーザエクスペリエンスを最適化するために、ストリーミングしているコンテンツの特性のサーバの知識を用いることができる。例えば、サーバは、広告は付加的な限定的な量の帯域幅を利用するのでアドバーティスメントをＨＤとしてプッシュすることを除けばフィルムをＳＤとして（制限された帯域幅のために）プッシュするかもしれない。別の例は、低解像度ビデオでの高速起動を実行し始め、且つ一旦帯域幅が十分に推定されれば可能な限りベストのリプレゼンテーションに切り替える、サーバのケースである。
サーバがストリーミングを通すことを可能にするために、１つのアプローチは、サーバに好ましくはデータ（特にＤＡＳＨデータ）をプッシュさせることである。そして、クライアントは、ビデオを表示するのに利用することができるいかなるデータも用いる。サーバは、通常は、一度にいくつかのセグメントのプッシュをアナウンスする。そして、サーバは、並行してまたは連続的にセグメントを送信する。
発生する問題は、クライアントとサーバはプロミスされたデータが望まれる時間に送られ、受信されるかどうか、わからないかもしれないことである：クライアントは、ビデオセグメントが、いつ、どの順序で送信されることになるのかをわからないかもしれない。
また、サーバによってプッシュまたはアナウンスされた、プロミスされたデータは、クライアントのニーズにミスマッチするかもしれず、それにより、サーバエンドにおいて特にリソースを無駄にすることになる。
このように、特に、ＤＡＳＨベースの通信との関連においてデータストリーミングを強化する必要性がある。
上記の課題を解決するために、本発明のメディアデータの提供方法は、例えば、以下の構成を有する。すなわち、サーバによるクライアントへのメディアデータの提供方法であって、前記サーバにおいて、前記サーバから前記クライアントへメディアセグメントがどのようにプッシュされるかを示すプッシュ戦略を有する第１情報を前記クライアントから受信する受信工程と、前記サーバにおいて、前記受信工程により前記第１情報を前記クライアントから受信したことに応じて、前記第１情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアセグメントを識別する識別工程と、前記サーバにおいて、前記クライアントから前記第１情報を受信したことに応じて、前記クライアントに第２情報を通知する通知工程と、前記サーバにおいて、前記クライアントから、前記１つ以上のメディアセグメントのうち少なくとも１つのメディアセグメントに関するキャンセルリクエストを受信したことに応じて、前記識別工程において識別された前記少なくとも１つのメディアセグメントの前記クライアントへのプッシュをキャンセルするキャンセル工程と、を有することを特徴とする。
本発明の他の機能および効果は、図１〜図６に加えて、添付された以下の図面を参照しながら、非限定的な好ましい実施形態の以下の記述から明らかになる。
サーバによってプッシュされる要素の依存性を図示する。 プッシュ機能ＨＴＴＰ／２交換の例を図示する。 プッシュ機能を用いたＨＴＴＰ交換の例を図示する。 クライアント側の処理のフローチャートを図示する。 サーバ側の処理のフローチャートを図示する。 サーバ・クライアント間のＨＴＴＰ／２交換の例を図示する。 ＨＴＴＰメディアストリーミングの概略的原理を図示する。 メディアプレゼンテーションおよびマニフェストファイルの生成例を図示する。 マニフェストファイル例を図示する。 ＭＰＤファイル例を図示する。 ＤＡＳＨクライアントの標準的挙動例を図示する。 マニフェストファイルのツリー表現例を図示する。 ＤＡＳＨマニフェストファイル例を図示する 実施形態にかかる、順序付けされたメディアセグメントを図示する。 実施形態にかかる、順序付けされたメディアセグメントを図示する。 実施形態にかかる、サーバによって実行される例示的なステップのフローチャートである。 実施形態にかかる、クライアントによって実行される例示的なステップのフローチャートである。 実施形態にかかる、プロキシによって実行される例示的なステップのフローチャートである。 実施形態にかかる帯域幅測定を図示する。 実施形態にかかるビデオ再生のイニシャライゼーションを図示する。 実施形態にかかる装置の概略図である。 クライアント側における本発明の一般的なステップを、フローチャートを用いて図示する。 サーバ側における本発明の一般的なステップを、フローチャートを用いて図示する。 明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップを、フローチャートを用いて図示する。 明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップを、フローチャートを用いて図示する。 サーバによって適用されるプッシュポリシーを指定するためにＰｕｓｈＰｏｌｉｃｙノードが用いられるＭＰＤドキュメントを示す。 共有されたプッシュポリシー「ＰｕｓｈＰｏｌｉｃｙ」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて図示する。 ＨＴＴＰ「プッシュポリシー」ヘッダ内で送信されるプッシュポリシーによるサーバとクライアントとの間の通信の例を図示する。 プッシュポリシーを変更するクライアントの要求と同じ例を図示する。 メディアプレゼンテーション記述（ＭＰＤ）ファイルの例を図示する。 アナウンスメッセージをマージする、実施形態によるサーバ側における処理のステップを、フローチャートを用いて図示する。 プッシュポリシーを宣言するためにＨＴＴＰヘッダを用いる場合のサーバ側における処理のステップを、フローチャートを用いて図示する。 プッシュポリシーを宣言して共有するためにＨＴＴＰ要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて図示する。 ドキュメントの階層レベルにおいてサーバによって適用されるプッシュポリシーを指定するためにＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素が用いられるＭＰＤドキュメントを示す。 ＸＰａｔｈベースのプッシュポリシーのために例として用いられるＭＰＤドキュメントを示す。 プッシュポリシーを適用する前の、例えばウェブページ内のプライオリティツリー内の要素の順序付けを図示する。 本発明の実施形態による、ＤＡＳＨ高速起動を取得するために、サーバによって、およびクライアント装置によって、それぞれ実施された例示的な方法を示す。 ＤＡＳＨ高速起動のためのサーバによって実施される例示的な方法を記述する。 ＤＡＳＨ高速起動のためのクライアント装置によって実施された可能な方法を記述する。
以下において、本発明の実施形態は、ＨＴＴＰ２．０プロトコルを実施するＤＡＳＨに基づくネットワークとの関連で記述される。ストリーミングされるデータは、例えばビデオデータである。本発明の実施形態は、ＤＡＳＨネットワークに限定されない。
クライアント装置に対してデータをストリーミングする通信ネットワークのサーバ装置は、送信されるデータ要素に対するクライアントからの明示的リクエストを伴わずに、クライアントに対してデータ要素を送信することができることによる、プッシュ機能を実施する。
サーバおよびクライアントは、プッシュプロミスを決定し、且つ対応するデータを実際に送信するように、サーバを駆動するプッシュポリシーを共有してもよい。この共有により、クライアントは、そのようなプッシュをキャンセルするために、いくつかの無用データのプッシュを予期することができる。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、送信される前にキャンセルされてもよいので、これは、ネットワーク使用と同様に、サーバの処理も減少させることになる。
具体的なの実施形態において、サーバは、明確に要求されていないデータ要素の送信をアナウンスする、そのプッシュプロミスにおいて、データ要素を送信するように意図するサーバの順序に関係する順序付け情報を示すことができる。データ要素の順序は、プライオリティ値、例えばＨＴＴＰ／２によるプライオリティ値、を用いて定義されてもよい。
プッシュプロミスを受信すると、クライアント装置は、サーバによって意図された送信の順序を予め決定することができ、それによって、クライアントは、自身の所望の順序と一致しなかった場合に、提案された順序付けに対応できる。例えば、クライアント装置は、プライオリティ値を更新し、更新されたプライオリティ値をサーバに対して送信することができる。サーバは、したがって、クライアントのニーズと適切に一致させるために、新たなプライオリティ値に基づいて送信順序付けを変更することができる。サーバは、将来のデータ送信を考慮して、更新されたプライオリティを用いることができる。
実施形態によれば、クライアントは、サーバに対するデータ要素の送信の全面的な順序付けまたは部分的な順序付けを要求しても良い。
図７ａを参照して、全面的な順序付けを説明する。クライアントは、ステップ７００の間に、メディアプレゼンテーション記述（以降、ＭＰＤ）をサーバに対して要求する。サーバは、ステップ７０１の間に、クライアントに対して返送するＭＰＤを取得し、プッシュするべき対応するデータ要素を識別する。図７ａの例において、サーバは、「データ１．１」、「データ１．２」および「データ１．３」をプッシュするデータ要素として識別する。これらの要素は、例えばデータセグメントである。要素「データＸ．１」は、データＸのためのベース層を表現し、要素「データＸ．２」は、データＸのためのエンハンスメント層を表現し、「データＸ．３」は、データＸのための付加的なエンハンスメント層を表現する。サーバは、データ要素のための具体的な送信の順序を定義する。サーバは、来たるプッシュデータ要素のアナウンスのためにクライアントに対して送信される、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに、それぞれのプライオリティ値を関連づける。そして、サーバは、ステップ７０２の間に、関連するプライオリティおよびＭＰＤにより、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム「Ｐ１．１」、「Ｐ１．２」および「Ｐ１．３」を送信する。次に、ＭＰＤおよびプッシュプロミスを送信した直後、ステップ７０３の間に、サーバは、クライアントに対して、定義された送信順序における「データ１．１」、「データ１．２」および「データ１．３」に続くセグメントである、「データ１．１」要素に対応するデータフレームと要素「データ２．１」、「データ２．２」および「データ２．３」にそれぞれ対応するＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージ「Ｐ２．１」、「Ｐ２．２」および「Ｐ２．３」とを送信する。データフレームの受信およびステップ７０３のプッシュプロミスと並行して、クライアントは、ＭＰＤおよび「Ｐ１．１」、「Ｐ１．２」および「Ｐ１．３」ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの受信後に、エンハンスメント層「データ１．２」は付加的なエンハンスメント層「データ１．３」に比較して低いプライオリティである、と判断する。したがって、クライアントは、ステップ７０４の間に、低い「データ１．２」プライオリティに対してプライオリティ更新フレームを送信する。プライオリティ更新要求を受信すると、サーバは、ステップ７０５の間に、送信のスケジュールを変更する。その結果、「データ１．３」が送信された後、「データ１．２」の送信は先延ばしされる。さらに、サーバは、「データ１．２」に関連付けられたセグメントをリンクするためにＭＰＤを用いる。サーバは「データ２．２」を識別し、そのプライオリティを減じる。
図７ｂを参照して、部分的な順序付けを説明する。図７ｂのステップ７１０〜７１４は、図７ａのステップ７００〜７０４と実質的に同じである。プライオリティ更新フレームの受信の後、サーバの挙動は、先に記載されたステップ７０５と比べて異なる。ステップ７１５の間、サーバは、既に「データ１．２」の送信を開始しており、送信をさらに進める。そのセグメントに関して、プライオリティに変更はない。サーバは、それにもかかわらず、連結されたセグメント、すなわち本例における「データ２．２」）のプライオリティを更新する。プライオリティ変更が考慮さられた、という事実をアナウンスするために、サーバは「データ２．２」のためのプライオリティ更新マッサージ（ｐｒｉｏｒｉｔｙｕｐｄａｔｅ ｍａｓｓａｇｅ）を送信してもよい。クライアントは、したがって、変更を通知されることができる。
本発明の実施形態は、ビデオのすべての部分を高品質に再生することができるように、サーバが予め十分に良い高品質のビデオ部分をプッシュすることができる使用事例において実施されてもよい。例えば、ビデオは、低品質として再生される部分１、高品質として再生される部分２、および低品質として再生される部分３に分割されることができる。クライアントとサーバとの間の帯域幅は、高品質ではなく低品質のリアルタイムストリーミングを可能にする。その場合、サーバは、部分２を強化し、部分１をインターリーブしてもよい。一旦部分１が再生されれば、強化された部分２は、また、利用可能であり、サーバは、同じ部分２の強化と共同して高品質として再生される部分２のベース層を送信する。このように、サーバは、すべての部分２が高品質として再生されることを確実にする。部分３は、その後に送信される。ユーザエクスペリエンスを妨害する品質のちらつき（ｑｕａｌｉｔｙ ｆｌｉｃｋｅｒｉｎｇ）を軽減することができ、品質の切り換え（ｑｕａｌｉｔｙ ｓｗｉｔｃｈｉｎｇ）のみが、限られた数のモーメントにおいて行われる。サーバは、ビデオコンテンツを認識して以後、異なる品質レベルにいつ切り替えるべきであるかを認識するために最善位置にある。
図８は、実施形態にかかる、プッシュベースのＤＡＳＨメディアストリーミングを実施するサーバによって実行されたステップのフローチャートである。ステップ８００〜８１２は、一般的な原理を記述する。ステップ８２０〜８２７は、より具体的には、クライアントからのプライオリティのフィードバックの管理に対処する。
ステップ８００の間、サーバは、クライアントから要求Ｒを受信する。この要求は、通常はＭＰＤファイルを参照することによって特定のメディアを識別する。次に、サーバは、ステップ８０１〜８１０を含む反復処理を実行する。その処理は、定義された順序にしたがってデータを送信することを有する。送信の順序は、クライアントのフィードバックにしたがって更新される。一旦データが送信されれば、それらはクライアントによって受信され再生される。次に、サーバは、送信するべき新たなデータを識別し、処理は、そのように継続し続ける。
第１の反復は、送信されるデータが識別される間のステップ８０１で始まる。反復処理の第１の実行の場合、クライアントがビデオ再生を可能な限り迅速に開始することを可能にするために、高速起動アプローチが用いられてもよい。さらに、サーバは、また、チャプターへのメディアの細区分を識別しても良い。クライアントが一般的にはチャプターを用いてナビゲートする、ということをサーバが認識する場合、サーバは、メディアの先頭に対して対応するセグメントだけでなくメディア内の第１のチャプターの開始に対応するセグメントも実際に選択してもよい。反復の第１の実行の後、サーバは、また、接続がメディアの高品質のリプレゼンテーションの送信をサポートすることができる、ということを検出しても良い。このように、サーバは、解像度または品質の切り換えをいつ行うべきであるのかを識別しても良い。
一旦サーバがプッシュするセグメントのリストを識別すれば、サーバは、これらのセグメントのための送信順序を定義する。送信順序は、１ステップ８０２の間に各々のプッシュされたセグメントに対する初期のプライオリティ値を算出するために用いられる。順序付けは、いくつかのパラメータに基づいてもよい。
第１のパラメータは、異なるセグメント間の関連性であってもよく、例えば、いくつかのセグメントは、他のセグメントを正確に復号するために利用可能でなければならない。利用可能でなければならないセグメントは、したがって、前記他のセグメントよりも高いプライオリティを割り当てられる。
第２のパラメータは、過去統計値から採集することができる、ビデオセグメントの人気度であってもよい。例として、ＹｏｕＴｕｂｅ（登録商標）のＵＲＬにより、ビデオ内の特定の期間をアドレス指定しても良い。これらのＵＲＬＳに関連するリンク上をクリックすると、特定の時刻にビデオ再生をスタートするために必要とされるビデオのみが取りだされる。さらに、ビデオがチャプター化されている場合、各々のチャプターの先頭は、一般的には多くの場合、チャプター開始の間のセグメントよりもユーザから取りだされる。チャプターの先頭のＳｅｇｍｅｎｔｓは、したがって、中間のチャプターセグメントインよりも高いプライオリティを割り当てられる。
第３のパラメータは、タイムラインであってもよく、再生されているビデオセグメントにより近いビデオセグメントのプライオリティは、後で再生されることになるビデオセグメントのプライオリティより高い。
第４のパラメータは、セグメントを実際に送信するために費やされる推定時間であってもよい。ビデオセグメントが大きい場合、送信するのに長い時間がかかり、そのため、できるだけ早く、すなわち高プライオリティで、送信を開始するべきである。
２つのセグメントが同一のプライオリティを有する場合、対応するデータフレームは、送信の間にインターリーブすることができる。関心領域がメディアコンテンツ内で識別された場合、帯域幅が高品質のリプレゼンテーションには十分に大きくはないが、低品質のリプレゼンテーションには十分に大きければ、サーバは、関心領域のためにのみエンハンスメント層を選択してもよい。
一旦プライオリティが算出されれば、サーバは、ステップ８０３の間に、プライオリティ値を含むＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。すべてのセグメントの識別は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信を開始するためには必要でない。ＭＰＤがプッシュされるセグメントのために送信される場合（ステップ８０４）、ＭＰＤが送信される（ステップ８０５）。セグメント送信は、ステップ８０６の間に、並列的に開始する。
一旦ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがクライアントによって受信されれば、サーバは、プライオリティ更新変更を受信し、その後、それに応じて、その送信スケジュールを変更してもよい（ステップ８０７〜８０８およびステップ８２０〜８２８）。セグメントを送信する一方で、サーバは、プライオリティ変更メッセージの受信を待つ。プライオリティ変更メッセージが受信された場合（ステップ８０７）、サーバは、それに応じてセグメントを再順序付けて、セグメント送信を継続する（ステップ８０８）。一旦すべてのセグメントが送信されると（ステップ８０９−１）、サーバは、メディアの端部までメディアをストリーミングし続けるために反復処理を再開する。メディアの端部に到達すると（ステップ８０９−２）、サーバは、別のメディアを自動的にストリーミングし始めるべきか否かをチェックする（ステップ８１０）。別のメディアがストリーミングされるべきである場合（はい（Ｙｅｓ））、サーバは、ストリーミングする新たなメディアを識別し（ステップ８１１）、ステップ８０１から処理を再開する。新たなデータがストリーミングされるべきでない場合、処理は停止される（ステップ８１２）。
クライアントからのプライオリティのフィードバックの、すなわちステップ８０８の管理は、ステップ８２０の間に、プライオリティ更新変更メッセージの受信とともに始まる。クライアントがセグメントプッシュをキャンセルした場合、以下のステップが実行されてもよく、このケースは、そのセグメントに対して最も低いプライオリティを割り当てることと実際には同等であると、理解してもよい。
プライオリティ更新変更メッセージを受信すると、サーバは、ステップ８２１の間に、関連セグメントを識別する。そして、サーバは、セグメント送信の再順序付けを進める（ステップ８２２および８２３）。セグメントが既に送信されていれば、処理は終了する。セグメントが送信されているならば、サーバの実装に応じて、送信を変更することを拒絶してもよいし（例えば複雑すぎるので）、または、送信される残りのデータを実際にスケジュール変更してもよい。
データのスケジュール変更は、以下のように実行されてもよい。サーバは、プッシュするビデオセグメント（および／またはプッシュされるビデオセグメント）のリストを保存する。このリストは、サーバによって設定されたプライオリティにしたがって順序付けられる。そして、サーバは、セグメントに新たなプライオリティ値を設定する。そして、リストが再順序付けられ、対応するビデオセグメントの送信は、それに応じて、早くなったり遅くなったりする。
一旦ビデオセグメントが再順序付けられれば、サーバは、他の関連するビデオセグメントに対して、このプライオリティ変更を適用することを実際に決定してもよい。クライアントがエンハンスメント層の一部であるビデオセグメントのプライオリティを引き上げれば、サーバは、このエンハンスメント層のすべてのセグメントのプライオリティを引き上げてもよい。逆に、クライアントがベースビデオセグメント層のプライオリティを引き下げる場合、このセグメントに一時的に関連するすべてのセグメントのプライオリティが引き下げられてもよい。この処理は、ステップ８２４〜８２７に記述される。ＭＰＤおよびスケジュール変更されたビデオセグメントに基づいて、サーバは、関連セグメントのリストを識別する（ステップ８２４）。関連性は、時間、空間、品質ベースなどであってもよい。ＭＰＤは、潜在的な関連性をより適切に示すために強化されてもよい。特に、（１つ以上のビデオセグメントを再生するのに必要である）イニシャライゼーションセグメントのプライオリティが引き下げられるかまたは引き上げられると、すべての関連セグメントがスケジュール変更されてもよい。これは、ベース層セグメントおよび強化セグメントの同様のケースになり得る。各々の識別された関連セグメントに対して、サーバは、関連セグメントの送信が変更されるべきであるか否かテストする（ステップ８２５）。変更されるべきである場合、サーバは、各セグメントに対して新たなプライオリティ値を算出し（ステップ８２６）、それに応じて、セグメント送信をスケジュール変更する（ステップ８２７）。新たなプライオリティ値は、ステップ８２０の間に受信された新たなプライオリティ値とステップ８２１の間に識別されたセグメントの初期のプライオリティ値との間の差分を古い値に対して加えることによって算出されてもよい。各関連セグメントがテストされると、処理は停止する（ステップ８２８）。
サーバは、また、ＷＩＮＤＯＷ ＳＩＺＥフレームなどの制御フローメッセージを受信してもよい。これらのメッセージによって、サーバは、クライアントが現在何を再生しているのかを、識別することが出来るであろう。いくつかの追加的バッファスペースがクライアントの端上で利用可能な場合、いくつかのデータ、通常は最も古いデータ、がバッファから取り出された、ということが推測され得る。サーバが送信されたデータの履歴を保持すれば、サーバは、どのデータが取り出されたのかを識別することができる。このように、もしサーバが、クライアントのキャッシュの順序付けを認識しているならば、サーバは、クライアントが現在どのビデオセグメントを再生しているかを知ることができる。この順序付けは、タイムラインにしたがってキャッシュされたデータを、順序付けることを可能的にするＭＰＤに基づいてもよい。そして、サーバは、例えばクライアントの時間スキップを検出することができる。サーバは、クライアントがビデオチャプターをスキップし続けることができるように、予め次のチャプターの開始を迅速に送信することによって対応してもよい。
プライオリティをもつＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信が様々な方法で行われてもよい、ということを留意するべきである。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、クライアントによって起動される開かれたストリーム（ｏｐｅｎｅｄ ｓｔｒｅａｍ）に関連しなければならない。実施形態によれば、ステップ８００の間にクライアントによって行われた初期のストリームは、常に開かれたままであってもよい。他の実施形態によれば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、サーバによって開かれたストリーム内で送信される。この場合、それが親クライアントに起動されたストリームによって送信されるように、クライアントは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを考慮する。このように、個々のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに対応する仮想要求の正しいヘッダを算出することができる。
他の実施形態によれば、プライオリティメッセージは、ＰＵＳＨ＿ＰＲＯＭＩＳＥと共同で送信される。第１の可能性は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内部のヘッダとしてそれを送信することである。もう１つの可能性は、対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームによって保存されたストリームＩＤを持つＰＲＩＯＲＩＴＹフレームを送信することである。第３の可能性は、このＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム、その後、（ストリームを開くために）対応するＨＥＡＤＥＲＳフレーム、および新しく開かれたストリーム上のＰＲＩＯＲＩＴＹフレームを送信することである。
さらにクライアントのバッファを制御するために、サーバは、クライアントによってキャッシュされたセグメントの新たなリプレゼンテーションを送信してもよい。この新たなリプレゼンテーションの一部として送信されたヘッダ内で、ＨＴＴＰキャッシュ指示は、例えばキャッシュすることができるものとしてそれをマークすることによって実際にセグメントを取り出すことをクライアントに要求するために用いられてもよい。これにより、クライアントの端上のバッファスペースを回復することが可能となる。ＨＴＴＰ／２制御フローが用いられてもよい。そして、サーバは、付加データをプッシュすることができる。
サーバは、各ビデオセグメントのプライオリティ値を送信してもよい。サーバは、また、特定セグメントのためのプライオリティ値を送信してもよい。サーバが、現在のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのプライオリティ値を送信しなかった場合、クライアントは、サーバから送信された最後のプライオリティ値からプライオリティ値を算出することができる。例えば、クライアントは、関連付けられたプライオリティ値がない新たなＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが受信されるたびにプライオリティ値を増加させてもよい。従って、特定セグメントのプライオリティの更新をするとまたグループのすべてのセグメントのプライオリティを更新するように、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、グループ化することができる。
図９を参照してクライアント側の処理を説明する。
クライアントは、所定の時間に利用可能なコンテンツを再生可能であるべきである。しかしながら、クライアントは、潜在的なバッファ制限および処理時間に対処しなければならない。クライアントは、サーバによって提案された送信順序付けがクライアントのバッファにおいて利用可能なメモリスペースと一致し、且つクライアントによって現在再生されているコンテンツと一致するか否かを、チェックしなければならない。
最初のステップ９００の間に、クライアントは、サーバに接続して、ＭＰＤファイルを要求する。そして、クライアントは、ステップ９０１の間にＭＰＤファイルを取り出し、データの受信を待つ（ステップ９０２）。データが受信されると、クライアントは、データがプッシュプロミスであるか否かをチェックする（ステップ９０３）。プッシュプロミスが受信された場合、これは、新たなビデオセグメントがサーバによって送信されている、ということを意味する。クライアントは、プッシュプロミスを処理する。特に、クライアントは、ステップ９０４の間にサーバによって提案されたプライオリティ値を認証してもよい。クライアントが現在のセグメントまたは別のプロミスされたセグメントのプライオリティ値を変更したい場合（ステップ９０５）、クライアントは、新たなプライオリティ値を算出して、それをサーバに対して送信する（ステップ９０６）。
クライアントがビデオデータを受信すると（ステップ９０７）、クライアントは、ビデオセグメントをＭＰＤファイルにリンクし（ステップ９０８）、ビデオデータ（ステップ９０９）を保存する。ビデオデータをＭＰＤファイルにリンクすると、ビデオの復号のためにさらに用いられる場合にクライアントがビデオセグメントを取りだすことが可能になる（ステップ９１１）。例えば連続したビデオセグメントがグループ化されると、これは、また、ビデオデータの効率的な保存を提供することができる（ステップ９０９）。
バッファ保存制約は、さらにプライオリティを変更することができる。このように、クライアントは、プライオリティ値を変更しなければならないかどうかを再びチェックすることができ、もし必要ならばサーバと通信してもよい（ステップ９０５および９０６）。
一旦クライアントがビデオを再生し始める、または再生し続ける準備ができれば（ステップ９１０）、クライアントは、そのキャッシュから次のタイムスロットのビデオセグメントを取り出し（ステップ９１１）、ビデオを復号して再生する（ステップ９１２）。ステップ９１１の一部として、クライアントは、どのビデオセグメントが利用可能であるのかを認識するためにそのキャッシュを問い合わせることができる。デフォルトでは、クライアントは、利用可能なすべてのビデオセグメント、もしあれば特にすべての強化セグメント、を用いてもよい。クライアントは、サーバにコンテンツを選択させることができ、一般的には言えば、すべてのセグメントは、クライアントによって用いられるべきである。（オーディオの英語トラックおよびフランス語トラックのような）いくつかのセグメントを共同で用いることができなければ、クライアントは、まず第１に未使用のセグメントを捨てるべきである。すべてのクライアントがキャッシュ状態に対してアクセスするとは限らないかもしれない、ということに留意するべきであり、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。例えば、この情報は、ウェブソケット接続を用いて、サーバからクライアントに交換されてもよい。
ビデオが再生されて復号されるとともに、対応するビデオセグメントは、バッファから取り出されるであろう。従って、クライアントは、ＷＩＮＤＯＷ ＳＩＺＥフレームを用いて、その利用可能なバッファサイズを更新する。クライアントは、ユーザが限られた期間の間にビデオを巻き戻すことを可能にするために、最近再生されたビデオセグメントを保持してもよい。ユーザが早送り／タイムスキップを行う場合、フロー制御更新メカニズムも用いられてもよい。クライアントは、新たなコンテンツのために場所を空けるために、前から保存されたビデオコンテンツを取り出してもよく、ＷＩＮＤＯＷ ＳＩＺＥフレームを用いて、サーバに対してこの変更をアナウンスする。サーバがＷＩＮＤＯＷ ＳＩＺＥフレームを受信すると、サーバは、前述のように、どのビデオセグメントが取り出されたのかを算出し、その後、クライアントが実際に何を再生しているのかを識別することができるであろう。
以下において、ステップ９０４をさらに詳細に説明する。
クライアントは、すべてのプッシュプロミスビデオセグメントのリストを保持する。このリストは、プッシュプロミスフレームにおいて見つかったプライオリティ情報にしたがって順序付けられる。第１に、それは潜在的な凍結されたビデオ問題のためにチェックされる。利用可能な帯域幅の推定および順序付けられたビデオセグメントリストに基づいて、各セグメントの送信の始まりおよび終わりの時刻を推測することができる。これらの時刻に基づいて、各ビデオセグメントはビデオ再生のために用いられる時刻に利用可能であるか否か、をテストされることができる。プロミスされたビデオセグメントがその対応するビデオ再生の使用の後に配送されることが予定される場合、そのプライオリティを上げるべきである。このように、このビデオセグメントは、プッシュプロミスビデオセグメントリスト内の順序が繰り上げられる。正確なプライオリティ値を算出するために、ビデオセグメントを時間通りに配送することを可能にするとともに、現在のビデオセグメントの位置に最も近い、ビデオセグメントリスト内における位置を検索する。そして、プライオリティは、ビデオセグメントの新たな位置の前後にあるリスト内のビデオセグメントのプライオリティ間の値に設定される。
他のファクタも、また、ビデオセグメントのプライオリティの変更のために、クライアントによって用いられてもよい。例えば、クライアントがいくつかのチャプター切換を行うことを予定していれば、クライアントは、チャプターを開始するすべてのビデオセグメント、特に対応するイニシャライゼーションセグメント、のプライオリティを実際に拡大してもよい。
実施形態によれば、クライアント側フロー制御は、ストリームごとのフロー制御を停止させて接続ごとのフロー制御のみを保持することを有する。接続ごとのウィンドウサイズは、クライアントが実際にいかなるときにも保存してもよいビデオの最大量を定義する。クライアントおよびサーバは、このウィンドウサイズを減少または拡大するためにイニシャライゼーション時や接続中にネゴシエイトしてもよい。サーバがいくつかのＨＤコンテンツをプッシュしたければ、サーバは、ウィンドウサイズを拡大することをクライアントに要求してもよい。接続帯域幅が低いならば、サーバは、ビデオの特定の部分のためのＨＤコンテンツを送り出すことを予め十分に予期する必要があるかもしれず、その場合には、バッファサイズは、より大きくされる。
バッファが単一のサイズを有する場合、送信の順序は、重要な問題であるであろう。特に、バッファがデータでいっぱいになった時に、プライオリティ順序付けは、より一層重要になる。重要な制約は、ビデオがフリーズしないということである。バッファが大きく空いている限り、サーバは、効率的な早送りまたはチャプタースキップを提供するために、かなり先行したセグメントのような様々なビデオセグメントを予めプッシュしてもよい。一旦バッファがほぼ満タンになれば、プッシュするビデオセグメントは再生されるビデオセグメントになるべく近いるべきである。サーバがクライアントバッファに関係する正確な情報を有していれば、このプッシュ挙動は、サーバによって行われてもよい。また、それは、プライオリティ更新メカニズムを用いて、クライアントによって実施されてもよい。
自動化されたビデオ切換の場合には、図９のフローチャートは、プッシュプロミスチェックの一部として新たなＭＰＤのプッシュを検出することによって拡張されてもよい（ステップ９０３）。ＭＰＤプッシュが検出されると、クライアントは、ステップ９０８の一部として新たなビデオのセグメントを受信し始めてもよい。そのため、クライアントは、ビデオデータに関連するＭＰＤを識別しなければならない。一旦ビデオ再生が所定のＭＰＤ（ステップ９０２）のために終了されると、新たなＭＰＤは、ビデオ再生の継続のために用いられる。クライアントは、先のＭＰＤにリンクされたビデオセグメントをすべて実際に消去することができる。
図１０を参照して、ＤＡＳＨ認識プロキシの挙動を説明する。サーバからプッシュされたセグメントを受信すると、プロキシは、エンドクライアントに対してそれをプッシュするようには要求されない。しかしながらＤＡＳＨストリーミングの場合には、それは優れた方式（またはデフォルトの挙動）と考えられる。
プロキシは、送信されるプッシュされたデータだけでなくプライオリティ処理に関して、サーバおよびクライアントの挙動を調整することができてもよい。プロキシは、実際、クライアントによるプライオリティを、サーバによるプライオリティから独立して取り扱ってもよい。さらに、サーバは所定のクライアントのために必要とされる以上のデータをプッシュしてもよく、プロキシは、他のクライアントからの要求を実現するために付加的なプッシュされたデータを取り込んでもよい。
サーバは、いくつかの理由によりビデオセグメントをプッシュしてもよい。例えば、それがエンドクライアントのために有用であると考えられた場合、ビデオセグメントがプッシュされてもよい。ビデオセグメントは数回使用することが可能で、且つプロキシに対してそれをプッシュする価値があると考えられる場合、ビデオセグメントもプッシュされてもよい。
第１のケースにおいて、プロキシは、一般的には、クライアントに対してビデオセグメントを送信する。プロキシは、クライアントまたはプロキシのネットワーク状態（例えばクライアント無線状態）を最適化するためにその送信を先延ばししてもよい。例示的なケースは、高速起動ビデオ再生および帯域幅推定のためのセグメントプッシュであり、その場合には、データはクライアントに対して可能な限り高速に送信されるべきである。サーバがプロキシに対するデータのプッシュに関心がある場合、プロキシは、ビデオセグメントがクライアントに対して有用になることを認識する手段を有する場合以外は、クライアントに対してビデオセグメントを自動的に送信しなくてもよい。クライアントに対して送信されなくてもよいビデオセグメントの識別を可能にするために、特定のプライオリティ値を用いてもよい。プライオリティ値を用いると、到達する様々なフレームの処理を最適化するためにプロキシが常にプライオリティ値をチェックすることができる。
図１０は、３つのフローチャートを含む。１つのフローチャートは、プッシュされたセグメントをフィルタリングする処理に関する（ステップ１０００〜１００８）。もう１つのフローチャートは、セグメントが別のクライアントに対して既にプロミスされている一方で、セグメントがクライアントによって要求された場合に実行される処理に関する（ステップ１０１０〜１０１５）。もう１つのフローチャートは、プライオリティ変更の管理に関する（ステップ１０２０〜１０２６）。
プッシュされたセグメントをフィルタリングする処理は、プッシュされたデータイベントの受信（ステップ１０００）とともに、通常はＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは関連するＤＡＴＡフレームを受信したときに、始まる。プロキシは、データが高プライオリティであるか否かをチェックする（ステップ１００１）。データは、それらのプライオリティ値が送信されている他のセグメントのプライオリティ値よりはるかに大きい場合、高プライオリティであると考えられる。データは、また、そのプライオリティ値が高速起動または帯域幅推定などの特別の意味を有するならば、高プライオリティであるとして考えられる。データが高プライオリティである場合、それらはクライアントに対して可能な限り迅速に送信される（ステップ１００２）。そして、プロキシは、データを保存するべきであるか否かを決定する（ステップ１００３および１００４）。プッシュされたデータストリームを開く対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは対応するＨＥＡＤＥＲＳフレームを受信すると、この判定は、一回行われてもよい。この判定は、また、プロキシのキャッシュ状態、ビデオの予見された使用、ビデオソースの人気度、または他の基準に基づいてもよい。セグメントが１つ以上のクライアントによって同時に要求される間にプッシュされれば、プロキシは、ビデオセグメントを保存する。セグメントが高速起動として識別されれば、ビデオセグメントもまた保存されてもよい。
データが高プライオリティでないならば、プロキシは、それが低プライオリティであるか否かをチェックする（ステップ１００５）。低プライオリティのデータは、クライアントに対する送信がスキップされてもよいが、プロキシのようなネットワーク媒介に対して興味深いものとしてサーバによって考慮されるデータかもしれない。プロキシは、まず、クライアントに対してデータを送信するべきか否かを決定する（ステップ１００６）。プッシュされたデータストリームを開く対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは対応するＨＥＡＤＥＲＳフレームを受信すると、この判定は、一回行われてもよい。そのように決定されれば、プロキシは、クライアントに対して、対応するフレームを送信する（ステップ１００２）。そして、処理は、データを保存するべきか否かを決定した後に停止する。
サーバとプロキシとの間でネゴシエイトされたプライオリティ値は、また、クライアントとプロキシとの間でネゴシエイトされたプライオリティ値とは異なってもよい。そのため、データが通常のプライオリティである（すなわち、低プライオリティでもなく、高プライオリティでもない）場合、プロキシは、セグメントのプライオリティ値がプロキシによって管理されるか否かをチェックする。図１０に図示されるように（ステップ１０２０〜１０２６）、プロキシは、データが送信されるべき時刻をスケジューリングするためにクライアント〜プロキシ間の値を用い、プロキシは、送信されるべきすべてのビデオ関連のフレームのリストを保持する。これらのフレームは、その順序にしたがって送信される前に、プライオリティ値にしたがって順序付けられる。
プロキシは、プライオリティ更新フレームを受信している場合に（ステップ１０１０）、プロキシは、関連するビデオセグメントを識別する（ステップ１０１１）。そのプライオリティ値がプロキシによって管理されていなければ（ステップ１０１２）、プロキシは、サーバに対してプライオリティ更新フレームを転送する（ステップ１０１３）。さもなければ、プロキシは、この新たなプライオリティ値を保存し、それに応じて、ビデオセグメントの送信を再順序付ける（ステップ１０１４）。潜在的な競合が出現した場合、特にサーバからのビデオセグメントの配信がクライアントのニーズに対して遅れすぎると予想される場合、プロキシは、サーバに対してプライオリティ値を転送することができる。
ステップ１０２０〜１０２６は、サーバによって既にプロミスされているビデオセグメント（ステップ１０２０）のクライアントから別のクライアントに対する要求を受信するプロキシのケース（ステップ１０２１）に関連する。その要求に対して与えられるプライオリティに応じて、プロキシは、クライアントの要求を満たす、プロキシ〜サーバ間の最小のプライオリティを算出する（ステップ１０２２）。この計算は、サーバ〜プロキシ間の配信時刻がプロキシ〜クライアント間の予定した配信時刻よりも早いということを保証する、プロキシ〜サーバ間のプライオリティ値を算出することによって行われる。プライオリティは、算出されたプライオリティが現在設定されているプライオリティを下回る場合に、変更され（ステップ１０２３）、その場合には、プロキシは、プライオリティ更新メッセージをサーバに対して送信することになり（ステップ１０２４）、プロキシは、プロキシがそれらのニーズに対して最良の時刻にその２つのクライアントに対してビデオセグメントを送信するように、プロキシによって管理されるようなこのビデオセグメントプライオリティをマークすることになる。この処理と同様に、プロキシは、いくつかのクライアントから同じセグメントに対する、いくつかのプライオリティ更新を受信してもよく、その場合には、プロキシは、すべてのクライアントを満たす最も低いプライオリティ値を実際に送信してもよい。
図１１を参照して、プッシュされたデータイベントをクライアントが受信することによる実施形態が説明され、そのデータイベントのプライオリティ値は、サーバが帯域幅の測定のためにそれを用いたいということを示す。帯域幅の測定は、ラウンドトリップ時間を算出するための能動的または受動的な測定を通じてＴＣＰ／ＩＰパケットを用いて行われてもよい。ラウンドトリップ時間に基づいて、利用可能な帯域幅は、Ｓａｕｂｈａｓｉｋ他の文献「ＢｉｔＶａｍｐｉｒｅにおける帯域幅推定および速度制御（ＢａｎｄｗｉｄｔｈＥｓｔｉｍａｔｉｏｎ ａｎｄ Ｒａｔｅ Ｃｏｎｔｒｏｌ ｉｎ ＢｉｔＶａｍｐｉｒｅ）」に見出されるように、算出されてもよい。この計算は、場合によっては、ＨＴＴＰ／２制御フローの影響を考慮に入れてもよい。いくつかのデータフレームが可能な帯域幅推定のために用いられる、という通知を行うことによって、ＨＴＴＰ／２制御フローなしで、利用可能な帯域幅を推定することができる。
処理は、プッシュされたデータフレームがサーバから受信される間のステップ１１００にて始まる。次に、ストリームの関連付けられたプライオリティが、サーバが帯域幅を測定しているということを示すか否かがチェックされる（ステップ１１０１）。その場合、専用のバッファは最大化される（ステップ１１０２）。または、ストリームフロー制御を無効にすることもできる。受信ノードがプロキシであるならば（ステップ１１０３）、セグメントデータを転送してもよい。さもなければ、クライアントは、セグメントを保存するべきか否かを決定する（ステップ１１０４）。クライアントは、プッシュされたセグメントを保存する（ステップ１１０５）。いずれにしても、クライアントは、接続ごとのウィンドウのための肯定応答をＷＩＮＤＯＷＳ（登録商標）＿ＵＰＤＡＴＥの形式でサーバに対して送信する（ステップ１１０６）。そして、この肯定応答は、接続帯域幅を推定するためにサーバによって用いられることになる。クライアントがプロキシで有る場合、プッシュされたデータを可能な限り迅速に転送する（ステップ１１０８）。エンドクライアントから肯定応答を受信すると、プロキシは、同様にそれをサーバに返送する（ステップ１１０９および１１１０）。
利用可能な帯域幅を推定するために、サーバは、データフレームの送信時刻と肯定応答メッセージの受信時刻との間の差分として算出される、送信されたデータフレームのラウンドトリップ時間を用いてもよく、２者間のペアリングは、例えばウィンドウサイズ更新に等しくなるべきデータフレームサイズに基づく。ラウンドトリップ時間は、１つ以上のビデオセグメントの様々なデータフレームから算出される。正確さを増すために、データフレームは、様々なサイズを有してもよい。異なるサイズのいくつかのＤＡＴＡフレームにビデオセグメントを分割することは、サーバによって実行できる。サーバは、ネットワーク層が、ＤＡＴＡフレームを、いくつかのＴＣＰ／ＩＰパケット（したがって小型のＤＡＴＡフレーム）に分割しない、または送信されるコンテンツをバッファリングして、いくつかのＤＡＴＡフレームをＴＣＰ／ＩＰパケットにマージしない、ということを保証することのみ必要とされる。それらの測定値に基づいて、規格技術は、どのビデオリプレゼンテーションを用いるかを実際に判断するために、サーバが用いてもよい利用可能な帯域幅を算出するために用いることができる（例は上記の文献内で見出すことができる）。
図１２を参照して、初期のビデオ再生のケースを説明する。サーバは、高速起動プライオリティを用いて、データをプッシュする。データは、通常低ビットレートを有しており、クライアントは、サーバが帯域幅を推定することができ、且つ最適なリプレゼンテーションに切り替えることができるように、それらのデータを受信して肯定応答をサーバに対して送信することになる、と考えられる。クライアント側の処理はステップ１２００〜１２０７に記載される。サーバ側の処理は、ステップ１２１０〜１２１５に記載される。
クライアント処理は、プッシュされたデータの受信のステップ１２００から始まる。そして、クライアントは、プライオリティが高速起動の値を有するか否かをチェックする（ステップ１２０１）。その場合、クライアントは、通常は、専用のバッファを最大化する（ステップ１２０２）。プッシュされたデータのＰＵＳＨ＿ＰＲＯＭＩＳＥを受信すると、この最大化が実行される。そして、データが保存され（ステップ１２０３）、クライアントは、ＷＩＮＤＯＷ ＵＰＤＡＴＥフレームを用いて、肯定応答をサーバに送信する（ステップ１２０４）。そして、クライアントは、ビデオを再生し始めるために十分なデータが利用可能であるか否かをチェックする（ステップ１２０５）。そうであるならば、ビデオ再生が始まる（ステップ１２０６）。そうでなければ、データを再生し始めるために十分なデータが利用可能になるまで、クライアントは、さらなるデータを待つ（ステップ１２０７）。
サーバ処理は、高速起動プライオリティでセグメントデータフレームを送信するステップ１２１１から始まる（ステップ１２１０）。そして、サーバは、利用可能な帯域幅を算出すること（ステップ１２１２）を可能にする肯定応答を受信する（ステップ１２１１）。一旦十分な測定値が取得されれば、サーバは、最適なリプレゼンテーションを選択し（ステップ１２１３）、最適なリプレゼンテーションセグメントをプッシュし始める（ステップ１２１４）。サーバは、リプレゼンテーションをいつ切り替えるのかを決定する。これには少なくとも２つの利点がある。第１に、クライアントが多少の遅延に対処する必要がある一方で、サーバは、いつ測定値が十分に正確になるのかを認識することができ、このケースであれば直ちに１つの解像度から別の解像度に切り替えることができる。第２に、サーバは、ユーザエクスペリエンスをあまり妨害しない時刻に１つの解像度から別の解像度に切り替えることを決定することができる。実際には、サーバは、ビデオコンテンツの認識を有する。特に、ＭＰＤは、解像度の切り換えを最良に予見することができる時刻の情報により強化されてもよい。
本発明は、強化されたストリーミング方法に関し、サーバ側において、第１のメディアデータに関連する要求がクライアント装置から受信され、要求されていなくともクライアント装置に対して送信される第２のメディアデータが識別され、そして、前記第１のメディアデータに関連する情報が前記要求に応答して前記クライアント装置に対して送信され、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージが準備される。
クライアント側において、第１のメディアデータに関連する要求は、サーバ装置に対して送信され、前記第１のメディアデータに関連する情報は、前記要求に応答して前記サーバ装置から受信される。
強化されたストリーミング方法は、いくつかのメディアデータをプッシュするサーバの判定と、このようなデータのためのクライアントのニーズとの間のミスマッチを減少させる。以下から明らかになるように、サーバおよびクライアントは、サーバおよびクライアントが両方ともクライアントによって要求されたいずれかのメディアデータからプッシュされる同じメディアデータを決定するように、プッシュポリシーを共有する。プッシュポリシーは、プッシュするデータを決定する方法を定義しており、要求されたデータが処理された（ＧＥＴ要求の後に）後に、要求されたデータに対してリンクされたどのリソースがプッシュされるのか、および場合によってどのようにプッシュされるか（例えば、どの順序で）を判定するための規則として理解されてもよい。通常、リンクされたリソースは、１つのドキュメント、例えば、（マルチメディアデータのためのＤＡＳＨコンテキストにおける）ＭＰＤファイルなどのマニフェストファイル、またはＨＴＭＬドキュメント、を用いて決定される。
結果として、共有されたプッシュポリシーに基づいて、クライアントはサーバの挙動を予期し、サーバからの無用のメディアデータの送信を、回避する、そしてより正確にはキャンセルすることができる。クライアントとサーバとの間の通信ネットワーク内の帯域幅の使用が、このようにして減少する。さらに、ＨＴＴＰ要求およびＰＵＳＨ＿ＰＲＯＭＩＳＥキャンセルの数が減少し、その結果、特に低遅延のライブビデオストリーミング用のアプリケーションの待ち時間が下がる。
本発明によれば、サーバは、サーバ装置がクライアント装置に対する第２の非要求メディアデータの識別および送信を駆動するためにクライアント装置と共有されるプッシュポリシーを、用いることができる。特に、クライアント装置に対して送信される第２の非要求メディアデータサーバ装置が決定するために、クライアント装置と共有されるとともに第２のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。それに対応して、クライアント装置によって要求されていなくともサーバ装置によって送信される第２のメディアデータをクライアント装置が決定するために、クライアントは、サーバ装置と共有されるとともに第２のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。
図１４ａは、クライアント側における本発明の一般的なステップを、フローチャートを用いて示し、その一方で、図１４ｂは、サーバ側における本発明の一般的なステップを、フローチャートを用いて示す。
図１ｄおよび図１ｅを参照して説明された処理との比較において、付加的なステージ１４００および１４０２は、サーバおよびクライアントが、他方と共有されて、それにより用いられるプッシュストラテジをそれぞれ決定することを可能にする。
第１の実施形態によれば、共有されたプッシュポリシーは、共有されるプッシュポリシーが何であるのかを他方に知らせるためにクライアントおよびサーバがポリシーデータを交換しない（明示的でない）ということを意味する、暗示的なプッシュポリシーである。共有されたプッシュポリシーの暗示的アプローチの実施は、サーバ装置およびクライアント装置の両方において、「第２のメディアデータを決定するアルゴリズム」として呼ばれる同じアルゴリズムを用いることを含み、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第１のメディアデータから同じ第２のメディアデータを決定することを可能にする。
例えば、アルゴリズムは、クライアントおよびサーバのセットアップの間に、または特定の規格に関連して、予め決定される。アルゴリズムの代表例は、マニフェストファイルの構文解析順序における要求されたリソースに追続くＮ個のリソースのプッシュする場合であり、ここで、Ｎは所定数（例えば４）である。
図を参照して、ステップ１４００および１４０２は、暗示的なプッシュポリシーのケースでは、プッシュされるリソースを識別する（サーバ側におけるステップ１４０３）ためにメモリ内の所定のアルゴリズムをロードすることにある。
クライアントは、例えばステップ１４０１において、期待されるＰＵＳＨ＿ＰＲＯＭＩＳＥの数を推定し、且つ不要なプッシュデータのためにキャンセルメッセージを準備するように決定されたプッシュポリシーを効率的に用いてもよい。
例えば、サーバ装置が対応する用意されたアナウンスメッセージを送信しないように、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバがクライアント装置から受信することになる。一方で、クライアントは、第２の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバ装置に対して送信するであろう。アナウンスメッセージがサーバ装置から送信されるか、またはクライアント装置によって受信される前に、このようなキャンセルが行われることができる、ということをわかるであろう。このアプローチは、例えば、別のバージョンのメディアに切り替えることをクライアントが決定するときに、有用かもしれない。このような状況において、前バージョンのためにプッシュされたセグメントをキャンセルすることを決定することができる。
アルゴリズムを用いてプッシュされるリソースの認識のために、クライアントは、サーバから対応するＰＵＳＨ＿ＰＲＯＭＩＳＥを待つ必要なく後続のリソースを取りだすために、サーバに対して第２の要求を並列に行うことができる、ということにも留意するべきであろう。ＤＡＳＨの場合には、クライアントのためのこの可能性は、第２の要求が後で受信するＰＵＳＨ＿ＰＲＯＭＩＳＥに干渉しないことを保証しながら、クライアントの待ち時間を減少させることを可能にする。
これらの他の必要とされるリソースがプッシュされようとしている、ということをアルゴリズムの結果から判定すれば、クライアントは、また、必要とする他のリソースを要求してもよい。
第２の実施形態によれば、共有されたプッシュポリシーは、全体の規則（すなわちアルゴリズムまたはアルゴリズムのパラメータ）を明確に定義するか、または両方の側で事前に定義されたプッシュポリシーを参照することによって、クライアントとサーバとの間の交換において定義される。これは、サーバのプッシュポリシーを記述するプッシュポリシー情報をサーバがまず決定することが必要となる。そして、プッシュポリシー情報は、プッシュポリシーをクライアントと共有するために、クライアントに対して送信される。それに対応して、クライアントは、それにより、共有されたプッシュポリシーを記述するプッシュポリシー情報をサーバ装置から受信する。
明示的アプローチの１つの効果は、それらの処理特性をより適切に満たすために異なるプッシュポリシーを、各クライアントまたは各マルチメディアプレゼンテーション（例えば各ＭＰＤ）のためにサーバが用いることができるという事実に依存する。図１５ａは、明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップ１４００を、フローチャートを用いて示し、その一方で、図１５ｂは、明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップ１４０２を、フローチャートを用いて示す。
図１５ｂに示されるように、サーバは、ステップ１５０４において、プッシュポリシーを宣言するメッセージを生成し、その後、それを共有するために、ステップ１５０５においてクライアントに対してそれを送信する。宣言メッセージ内のプッシュポリシーを記述する情報は、プッシュポリシー情報と称される。
以下に記載される図１６〜図１８は、プッシュポリシーがどのように宣言され、クライアントに対して送信されるのかについて例示的な詳細を示す。
ステップ１４０２において決定されるようなプッシュポリシーを用いてプッシュされるリソースは、ステップ１５０４において生成されるプッシュポリシー宣言メッセージ内に定義されたセレクションアルゴリズム（または第２のメディアデータを決定するアルゴリズム）により、ステップ１４０３において識別される。
クライアント側では、図１５ａに示されるように、クライアントは、同じ選択アルゴリズムを適用することによって、所定のリソース要求のためにプッシュされるリソースを、事前に識別することができる。これは、サーバによってプッシュされるデータをクライアントが予め決定することを可能にし、したがって、プッシュデータの効率的な管理と、必要であればＧＥＴ要求の数の削減とを保証することを可能にする。
同じ選択アルゴリズムを適用するために、クライアントは、サーバによって適用されたプッシュポリシーを記述するプッシュポリシー情報を受信する。
様々なプッシュポリシーの宣言方法が用いられてもよい。
１つの実施形態において、プッシュポリシー宣言は、要求Ｒと、プッシュされるリソースを含むドキュメント（通常はＤＡＳＨのためのマニフェストファイル）に対応するＤＯＭツリーとを入力パラメータとして利用して、プッシュされるリソースの順序付きリストを出力するＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムのおかげで共有される。この実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されるウェブページ内に埋め込まれるＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含む。
他の実施形態において、プッシュポリシーは、マニフェストファイル内に記述される。それは、共有されたプッシュポリシーを用いて、サーバ装置からクライアント装置に対して送信される記述ファイル内の共有されたプッシュポリシーが挿入されることを記述するプッシュポリシー情報である。記述ファイルは、第１のメディアデータを含むメディアデータに関係し、プッシュされる第２の非要求メディアデータを決定するために両方の側によって用いられる記述情報を含む。
ＤＡＳＨにおいて、記述ファイルは、例えばＭＰＤファイルである。以下の記述は、主として、ＤＡＳＨおよびＭＰＤファイルに基づく。しかしながら、同じアプローチは、スムーズなストリーミングまたはＨＴＴＰライブストリーミングのような他のマニフェストベースのストリーミング方法に適用できる。
具体的な定の実施形態によれば、プッシュポリシー情報は、識別される第２の非要求メディアデータの量を定義する第１のプッシュ属性を記述ファイル内に含む。これは、１つの要求Ｒがクライアントから受信された後、プッシュされるセグメントの数を指定することを可能にする。
これは、サーバによって適用されるプッシュポリシーを指定するためにＰｕｓｈＰｏｌｉｃｙノード１６００が用いられるＭＰＤドキュメントを示す図１６によって示される。
この例において、ＰｕｓｈＰｏｌｉｃｙノード１６００は、ＧＥＴ要求が受信された後にプッシュされるセグメントの数を宣言するために、プッシュ属性（すなわち「Ｓｅｇｍｅｎｔｌｄｘ」）を含む。例えば、クライアントがそのＧＥＴ要求内のセグメント１６０１を必要とするならば、ＭＰＤドキュメントの順序を解析する際に、次の２つのセグメントのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを応答として、受信することになる。この例において、第１のプッシュ属性は、記述ファイル内の要求された第１のメディアデータに対して第２の非要求メディアデータを識別する。さらに一般的には、プッシュされるＫ個のセグメントの所定数は、プッシュポリシー値を定義するために用いられる。結果的に、クライアントによって要求される各セグメントに対して、サーバは、Ｋの次のセグメントをプッシュすることになる。
図１６の例１６００は、単一のプッシュ属性を示すが、複数のプッシュ属性があってもよい。各プッシュ属性は、プッシュされるセグメントを選択するために、マニフェストを表現するＤＯＭ（ドキュメントオブジェクトモデル（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ））ツリーのノード上の制約を表現してもよい。図４ｂの先の例を参照すると、プッシュポリシーノード１６００は、メディアデータが属するＰｅｒｉｏｄ要素を参照する期間属性「Ｐｅｒｉｏｄｌｄｘ」と、メディアデータのＡｄａｐｔａｔｉｏｎＳｅｔ要素を参照するアダプテーション属性「ＡｄａｐｔａｔｉｏｎＳｅｔｌｄｘ」と、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素を参照するリプレゼンテーション属性「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ」、すなわちメディアデータの符号化バージョン（特定のコーデック、解像度、またはビットレート…）と、所定のリプレゼンテーション内のセグメントを参照するセグメント属性「Ｓｅｇｍｅｎｔｌｄｘ」と、を含むメディアデータ属性（ＭＰＤ要素および／または属性）を用いて、記述ファイル（ＭＰＤファイル）内に記述されるメディアデータを参照することができる。
これらの既存のメディアデータ属性に基づいて、プッシュポリシー情報は、第２の非要求メディアデータを識別するために、メディアデータ属性（単数または複数）上の制約を定義する少なくとも第２のプッシュ属性を含んでもよい。
例えば、Ｓｅｇｍｅｎｔｌｄｘ属性に関連する上記の第１のプッシュ属性に加えて、プッシュするセグメントを選択するための期間上の制約を指定するために、プッシュ属性は、Ｐｅｒｉｏｄｌｄｘ属性に関連付けられてもよく、別の１つは、適応上の制約を指定するためにＡｄａｐｔａｔｉｏｎＳｅｔｌｄｘ属性に関連付けられてもよく、別の１つは、リプレゼンテーション上の制約を指定するためにＲｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ属性に関連付けられてもよい。
プッシュ属性が存在しないかまたは無効のとき、関連するメディアデータ属性は、非制約として考えられねばならない。
プッシュ属性の値は、以下の構文を用いてもよい。
プッシュ属性＝［オペレータ］オペランド（ｐｕｓｈ ａｔｔｒｉｂｕｔｅ＝［ｏｐｅｒａｔｏｒ］ ｏｐｅｒａｎｄ）
ここで、「オペレータ」は、オプションであり、要求されたセグメントに対して相対的にプッシュされるセグメントを定義するために、値「＋」または「−」をとり（「＋」は後を意味し「−」は先を意味する）、ここで、「オペランド」は、ワイルドカードパラメータとして０または「＜＊＞」よりも上位の整数値若しくは等しい整数値のいずれかである。
図１７は、共有されたプッシュポリシー「ＰｕｓｈＰｏｌｉｃｙ」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて示す。このフローチャートは、ステップ１４０３を示す。
まず、サーバは、ステップ１７００において、マニフェストファイル内の要求されたセグメントを識別する。要求は、このセグメントの識別された「ｒｅｑＳｅｇｌｄｘ」を含む。
マニフェストファイルＭＰＤ内の各々のノード種別に対して、指標値が、各ノードに対して属性付けられる。値は、マニフェストファイル内での出現順において各々のノードごとに増加される。
次に、要求されたセグメント（すなわちＧＥＴ要求において指定されたセグメント）に対応するＰｅｒｉｏｄ、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、およびＳｅｇｍｅｎｔＵＲＬのインデックスは、要求されたセグメントに到達されるまで、全体のＭＰＤを解析することによって取りだされる。
プッシュポリシー内に定義されたプッシュ属性のオペレータおよびオペランドの値は、（「＋」または「−」オペレータに関連付けられている場合に、プッシュされるセグメントの量を定義するＳｅｇｍｅｎｔｌｄｘ属性を除いて）プッシュされるセグメントがどのノード内で定義されるのかを識別するために用いられる。
オペレータが指定されない場合は、オペランド値は、プッシュされるデータを検索しなければならないＮｏｄｅのインデックスを識別する。例えば、第１のプッシュ属性「Ｓｅｇｍｅｎｔｌｄｘ」がオペレータを有しない場合には、それは、プッシュされる特定セグメントの、記述ファイル内部の、識別子である。１つの代替案において、オペレータが指定されないと、オペランド値は、範囲値を識別してもよく、例えば、「Ｓｅｇｍｅｎｔｌｄｘ＝２−５」は、２、３、４および５に等しいインデックスでセグメントを返すだろう。
そうでなければ（オペレータが指定されている）、オペランド値は、要求されたセグメント（ステップ１７００において取得された「ｒｅｑＳｅｇｌｄｘ」）のインデックスに対して適用するために（「ｉｄｘＯｆｆｓｅｔ」と命名される）オフセット値を表現する。そのような場合、プッシュされるセグメントは、もしオペレータが「＋」ならば［ｒｅｑＳｅｇｌｄｘ，ｒｅｑＳｅｇｌｄｘ＋ｉｄｘＯｆｆｓｅｔ］範囲、そしてもしオペレータが「−」ならば［ｒｅｇＳｅｇｌｄｘ−ｉｄｘＯｆｆｓｅｔ，ｒｅｇＳｅｇｌｄｘ］内に備えられたインデックスとともにノード内にあるはずである。オペレータの使用は、記述ファイル内部の第１のメディアデータの対応するメディアデータ属性（単数または複数）に対する第２の非要求メディアデータのメディアデータ属性（単数または複数）を定義することを可能にする。
例えば、以下のプッシュポリシーを考えてみよう。
１．＜ＰｕｓｈＰｏｌｉｃｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ＝“−１” Ｓｅｇｍｅｎｔｌｄｘ＝“２”／＞
２．＜ＰｕｓｈＰｏｌｉｃｙ Ｐｅｒｉｏｄｌｄｘ＝“＋１” Ｓｅｇｍｅｎｔｌｄｘ＝”＋２／＞
３．＜ＰｕｓｈＰｏｌｉｃｙ Ｐｅｒｉｏｄｌｄｘ＝“＋０” Ｓｅｇｍｅｎｔｌｄｘ＝”＋２／＞
ＰｕｓｈＰｏｌｉｃｙ＃１は、要求されたセグメントのリプレゼンテーションノードに先行するリプレゼンテーションノード内のインデックス２のセグメントをサーバがプッシュすることになる、ということを指定する。
ＰｕｓｈＰｏｌｉｃｙ＃２により、サーバは、現在の期間または以降において、要求されたセグメントに続く２つのセグメントをプッシュすることになる。例えば、図２４のセグメント２４０１を要求すると、セグメント２４０５および２４０２がプッシュされることになる。
ＰｕｓｈＰｏｌｉｃｙ＃３は、ＰｕｓｈＰｏｌｉｃｙ＃２に対して非常に類似し、主な差は、要求されたセグメントがＰｅｒｉｏｄの最後から２番目の時のものである。例えば、２４０１を要求する場合、現在の期間における最後セグメント２４０５のみが（２つのセグメントの代わりに）プッシュされることになる。ＰｕｓｈＰｏｌｉｃｙ＃３により、Ｐｅｒｉｏｄｌｄｘは、要求されたセグメントのＰｅｒｉｏｄノードに対してセグメント検索を制限しており、したがって、（要求されたセグメントがＰｅｒｉｏｄ内の最後から２番目のセグメントであるので）Ｐｅｒｉｏｄの最後のセグメントのみがプッシュされる。それどころか、ＰｕｓｈＰｏｌｉｃｙ＃２により、セグメントは、次の期間から取りだすことができる。
代替案において、またはオプションの値として、オペランドの値は、また、あらゆるセグメントがプッシュされるべきであるということを意味する「＜＊＞」（ワイルドカードを意味する）であってもよい。オペレータ「＋」（それぞれ「−」）に関連付けられていると、それは、要求されたものに対して後続する（各々が先行する）すべてのセグメントがプッシュされるべきであるということを意味する。
この代替案は、クライアントがＰｕｓｈＰｏｌｉｃｙ：＜ＰｕｓｈＰｏｌｉｃｙ Ｐｅｒｉｏｄｌｄｘ＝“＋０”Ｓｅｇｍｅｎｔｌｄｘ＝“＋＜＊＞”＞により、例えば１つのＰｅｒｉｏｄのセグメントをすべて取りだす、単一のＨＴＴＰ要求のみを送信することを可能にする。
これらの例において、要求された第１のメディアデータに対する（プッシュされる）第２のメディアデータを識別するＳｅｇｍｅｎｔｌｄｘ属性の使用は、第２のメディアデータが第１のメディアデータに隣接することを必要とする。実施形態において、Ｓｅｇｍｅｎｔｌｄｘ属性は、要求されたセグメントのインデックスに適用するために（オペランドに加えて）オフセットを含んでもよい。これは、所定量のセグメントをプッシュしなければならない基準セグメントのインデックスをシフトする。例として、Ｓｅｇｍｅｎｔｌｄｘ属性の構文は、次のとおりであっても良い。
プッシュ属性：［オペレータ］オペランド［，オフセット］（ｐｕｓｈ ａｔｔｒｉｂｕｔｅ：［ｏｐｅｒａｔｏｒ］ｏｐｅｒａｎｄ［，ｏｆｆｓｅｔ］）
ここで「オフセット」は、要求されたセグメントインデックスに適応するために０とは異なる正または負の整数である。そのような場合、サーチ範囲は、オペレータが「＋」であれば［ｒｅｑＳｅｇｌｄｘ＋ｏｆｆｓｅｔ，ｒｅｑＳｅｇｌｄｘ＋ｉｄｘＯｆｆｓｅｔ＋ｏｆｆｓｅｔ］、およびオペレータが「−」であれば［ｒｅｑＳｅｇｌｄｘ−ｉｄｘＯｆｆｓｅｔ＋ｏｆｆｓｅｔ，ｒｅｑＳｅｇｌｄｘ＋ｏｆｆｓｅｔ］である。
プッシュポリシーの構文は、また、プッシュされているプレゼンテーション内に最大サイズのデータまたは時間のような（非制限的な）条件をそれぞれ含むことができる。例えば、
＜ＰｕｓｈＰｏｌｉｃｙ Ｓｅｇｍｅｎｔｌｄｘ＝’＋＜＊＞［ｓｉｚｅ＜５０００００］’＞は、多くとも５００キロバイトのセグメントデータをプッシュするプッシュポリシーを定義する。
＜ＰｕｓｈＰｏｌｉｃｙ Ｓｅｇｍｅｎｔｌｄｘ＝’＋＜＊＞［ｔｉｍｅ＜０：０１：３０］’＞は、多くとも１分３０秒の次のセグメントデータを転送するプッシュポリシーを定義する。
上記の例が、どのセグメントをプッシュしなければならないのかを判定するプッシュポリシーを宣言する方法を示している一方で、セグメントがプッシュされることになる好ましい順序を指定する必要もあるかもしれない。この情報も、クライアントとサーバとの間で共有されるべきである。
例として、図７〜図１２を参照して上記したプッシュされたセグメントの送信の順序の宣言を、適用することができる。
プッシュされたセグメントの送信の順序の１つの代替の実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに１つのプライオリティ属性（例えば「ｐｒｉｏｒｉｔｙｌｄｘ」）があり、第２のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。記述ファイルの送信のおかげで、クライアントは、また、これらのプライオリティ属性によって得られた値に気づいており、したがって、意図された送信の順序を決定することができる。
図１６の例に示されるように、マニフェストファイル内に記述される各セグメント（例えば、１つのＳｅｇｍｅｎｔＵＲＬノードによって識別される）は、セグメントのプッシュ順序を指定するｐｒｉｏｒｉｔｙｌｄｘ属性（１６０４）を含む。図１６の例において、セグメント１６０３は、セグメント１６０２の前にプッシュされる。これらのプライオリティは、サーバ側においてメディアセグメントの準備の間に算出される。異なるプライオリティ値が使用出来る：３２ビット数として、Ｐｅｒｉｏｄプライオリティのための４最上位ビット、ＡｄａｐｔａｔｉｏｎＳｅｔプライオリティ値のための次の４ＭＳＢ、リプレゼンテーションプライオリティ値のための次の８ビット、およびセグメントプライオリティのための最下位１６有効ビットをもつ（図１６のような）所定のＲｅｐｒｅｓｅｎｔａｔｉｏｎ内の相対プライオリティ値または絶対プライオリティ値のいずれかを用いることができる。絶対プライオリティ値を示す別な方法は、プライオリティ値のコンマ区切りリストを用いることであり、上記の引用されたレベルの各々の１つは、例えば、Ｐｅｒｉｏｄプライオリティ、ＡｄａｐｔａｔｉｏｎＳｅｔプライオリティ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎプライオリティ、そしてセグメントプライオリティを連続的に定義するｐｒｉｏｒｉｔｙｌｄｘ＝’１，１，２，１’である。第１の実施形態は、以下の３２のビット値（バイナリ型）により与えるだろう。
ｐｒｉｏｒｉｔｙｌｄｘ＝’０００１０００１００００００１００００００００００００００００１’
ｐｒｉｏｒｉｔｙｌｄｘ値を用いる主な効果は、個別のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（通常は、ビデオの代替ビューなどの関連リプレゼンテーション）からセグメント間のプライオリティ順を定義することを可能にすることである。プッシュポリシーが個別のＲｅｐｒｅｓｅｎｔａｔｉｏｎセットのセグメントの送信にあると有用である。１つの層からのセグメントが１つ以上の他の層をもつセグメントによりインターリーブされる場合、通常の使用事例は、層状ビデオ（マルチビューにおけるビューである層またはスケーラブルビデオにおけるスケーラビリティ層）のストリームのためのものである。
図１７に戻り、サーバは、ＭＰＤファイル内に定義されるようなプッシュポリシーに基づいて、ステップ１７０１において、プッシュされるセグメントの数を決定する。この数は、Ｓｅｇｍｅｎｔｌｄｘ属性値から直接推測される。すなわち、オペレータが属性値内で用いられなければ、この数は１に等しく、そうでなければ（オペレータは「−」または「＋」である）、数は、オペランド値に等しく、オペランドが「＜＊＞」であれば無限である（但し他の制約によって、および既存のセグメントの数によって、限定される）、と想定される。
次に、プッシュするセグメントの数がプッシュされるセグメントの各々をマークするところに達する（テスト１７０２）まで、ステップ１７０２〜１７０５から構成される反復処理は、ストリーミングサーバによって適用される。
各々の反復に対して、サーバは、ステップ１７０３において、ＰｕｓｈＰｏｌｉｃｙ制約（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、Ｐｅｒｉｏｄ、およびＳｅｇｍｅｎｔ制約およびオプションの条件）に関する、ＭＰＤファイル内に定義されたセグメントのリストを取りだす。
セグメントのリストが空であるか、またはすべてのセグメントが既にマークされていれば（テスト１７０４）、処理は終了し、サーバはクライアントの要求に対して応答を送信し始める（上記のステップ１０２）。
そうでなければ、リストの第１のセグメントは、ステップ１０３（ＰＵＳＨ＿ＰＲＯＭＩＳＥ）および１０４（プロミスされたセグメント）の間にプッシュされるのと同様に、ステップ１７０５においてマークされる。
プッシュポリシーを宣言する、これらのＭＰＤに基づく例において、１つのプッシュポリシーは、ＰｕｓｈＰｏｌｉｃｙ要素を用いて定義される（図１６の１６００を参照）。

記述ファイルが、複数のメディアデータ属性レベル（すなわち、以上で定義されたＰｅｒｉｏｄ、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素）を用いて、メディアデータを記述することが、ここで想起される。
上記のものに対するわずかな変形として、様々な共有されたプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義されてもよい。これは、メディアストリームのコンテンツに対してプッシュ戦略を適応するために、関係するレベル（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、Ｐｅｒｉｏｄ）に依存する様々なプッシュポリシーを定義することができる、ということである。
これは図２３を通じて示され、ここで、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおいて、プッシュポリシーが、所望のレベルにて、例えば「ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ」記述子を用いて定義される。
＜ＭＰＤ＞レベルごとにプッシュポリシーを用いることは、メディアにわたって定数および同じプッシュ戦略を有することを可能にする。
＜Ｐｅｒｉｏｄ＞レベルごとにプッシュポリシーを用いることは、時間に沿って変化できるプッシュ戦略を有することを可能にする。
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞レベルごとにプッシュポリシーを用いることは、メディアに適したプッシュ戦略を有することを可能にする。
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞レベルごとにプッシュポリシーを用いることは、メディア特性（帯域幅…）に適することができるプッシュ戦略を有することを可能にする。
図２３の例において、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおいて指定されるプッシュポリシーは、プッシュデータとともにあまりにも多くの帯域幅を用いないようにするために、高いビットレートのビデオ（２３０１）よりも低ビットレートビデオセグメント（２３００）のために、よりさらにセグメントをプッシュするように構成される。
プッシュ属性の構文に関しての上記の説明も、また、このわずかな変形に適用されてもよい、ということに留意されたい。特に、プッシュポリシーは、新たな要素（図１６のように）としてマニフェストにおいて、または（図２３のように）新たなｓｃｈｅｍｅｌｄＵｒｉにより既存の記述子を用いて、または（表現されていない）新たな記述子として、またはＭＰＤスキーマ若しくはＭＰＤスキーマの拡張ポイントに適合するいずれかの手段として、信号で送ることができる。
ＭＰＤは、また、各自が一意の識別子を有する、代替的なＰＵＳＨポリシーのリストを含むこともできる（以下のリストに関するさらなる説明を参照）。
他の代替の実施形態において、プッシュポリシーは、相補的なＲｅｐｒｅｓｅｎｔａｔｉｏｎのためのセグメントが系統的にプッシュされる、ということを、例えば以下の構文を用いて定義してもよい。
＜ｐｕｓｈ＿ｐｏｌｉｃｙ Ｓｅｇｍｅｎｔｓ＝’＋ｃｏｍｐｌｅｍｅｎｔａｒｙ’＞または、ＤＡＳＨ記述子を用いる場合は、ｖａｌｕｅ＝’ｃｏｍｐｌｅｍｅｎｔａｒｙ’層状ビデオの場合には、これは、要求されたビデオセグメントに対して、相補的なＲｅｐｒｅｓｅｎｔａｔｉｏｎとして宣言されるすべてのＲｅｐｒｅｓｅｎｔａｔｉｏｎから同時に各セグメントも（通常は、異なるＲｅｐｒｅｓｅｎｔａｔｉｏｎ間の依存性を信号で送るＭＰＤ内のｄｅｐｅｎｄｅｎｃｙｌｄ属性を通じて）プッシュされるだろう、ということを意味する。
別のプッシュポリシーは、また、＠ａｓｓｏｃｉａｔｉｏｎｌｄ属性またはｒｏｌｅ＝’ｓｕｐｐｌｅｍｅｎｔａｒｙ’により信号で送られる、関連するＲｅｐｒｅｓｅｎｔａｔｉｏｎからのセグメントのプッシュにある。
完全にサーバで駆動されるストリーミングの場合には、プッシュポリシーは、サーバ挙動が「積極的」（若しくは「楽観的」）または「保守的」でなければならないか否かの情報、すなわち、それぞれ高品質のセグメントをプッシュしようとする、または同じ品質レベル（帯域幅を維持する）でプッシュしようとするか否かの情報を提供することができるであろう。
他の実施形態において、プッシュポリシーは、専用のＨＴＴＰヘッダとして見なされる「プッシュポリシー」ヘッダ内で送信される。すなわち、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたＨＴＴＰフレームのヘッダ内に埋め込まれる。
これらの実施形態は、上記のように、それらがもはやＭＰＤファイルの送信に依存せず、クライアントおよびサーバがＨＴＴＰ／２プロトコルを用いて交換するので、プッシュポリシーを経時的に変化させることを可能にする。
図１８は、ＨＴＴＰ「プッシュポリシー」ヘッダ（ヘッダ名「プッシュポリシー」は、単なる例である）内で送信されるプッシュポリシーでの、サーバとクライアントとの間の通信の例である。
プッシュポリシーヘッダは、プッシュ属性のリスト（プッシュされるデータ上の制約を各々定義する）を含む。特に、先に記述されたＰｕｓｈＰｏｌｉｃｙの構文は、ＨＴＴＰヘッダ構文に書き換えられてもよい。
図１８ａにおいて、クライアント（矢印１８００）からのＭＰＤ要求に応答してサーバは、プッシュポリシーを共有するために、送信されたＭＰＤに伴うＨＴＴＰヘッダ内のプッシュポリシーを送信する（ステップ１８０１）。
例えば、プッシュポリシーは、要求されたセグメントを追従するセグメントがプッシュされることになる、ということを指定する。結果として、クライアントがセグメントデータ１．１を要求する（矢印１８０２）と、サーバは、セグメントデータ２．１のためのＰＵＳＨ＿ＰＲＯＭＩＳＥと（矢印１８０３）、そしてセグメントデータ１．１（矢印１８０４）のデータを送信する。
後続のセグメント要求のためにどのデータが送信されようとするのかを定義するために、任意の構文：ＭＰＤ特有のものまたはＤＯＭツリーノードトラバースに基づいたより抽象的なものを用いることができる。
動的に共有されたプッシュポリシーに専用の特定の実施形態において、クライアントは、特定のプッシュポリシーを要求してもよい。すなわち、例えば現在共有されたプッシュポリシーがそのニーズに適していなければ、共有されたプッシュポリシーを更新してもよいし、または改善してもよい。
それは、クライアント装置がＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をサーバ装置に対して送信する、ということを意味する。それに対応して、サーバ装置は、ＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をクライアント装置から受信する。サーバ装置は、したがって、クライアント装置（例えば次の要求のための）によって要求された他のメディアデータから非要求メディアデータを決定する前に、共有されたプッシュポリシーをそれに応じて更新してもよい。
実施形態において、クライアントからのプッシュポリシー要求は、「プッシュポリシー要求」という名の（ここでの名称は単なる例である）ＨＴＴＰヘッダまたは要求内で伝達される。
図１８ｂは、クライアントが新たなプッシュポリシーを要求した場合のクライアント・サーバ間の例示的な交換を示す。
交換の始まりは、図１８ａと同じである。
セグメントデータ２．１を受信した後、クライアントは、例えば利用可能な帯域幅が、セグメント要求に応答してさらなるセグメントをサーバにプッシュさせるのに十分に安定しているので、現在のプッシュポリシーが修正されるべきである、ということを識別する。
結果として、クライアントは、ステップ１８０５において、各々の新たな要求毎に、さらなるセグメント（１の代わりに３）をプッシュするようにサーバに依頼するプッシュポリシー要求を送信する。
サーバは、ステップ１８０６において、ＯＫ２００によりこのプッシュポリシー要求に肯定的に回答する。この肯定的な回答は、同じクライアントからいずれかの新たな要求に対するプッシュポリシー要求内に記述された新たなプッシュポリシーをサーバが用いることになる、ということを意味する。
サーバがそのプッシュポリシーを変更したくないならば、それはプッシュポリシー要求が拒否されている、ということをクライアントに通知するためのエラーコード回答を返す。
次に、クライアントが、ステップ１８０７において、次のセグメントデータ３．１を要求すると、サーバは、ステップ１８０８において、次の３つのセグメントデータ４．１、データ５．１、およびデータ６．１に対してＰＵＳＨ＿ＰＲＯＭＩＳＥにより回答する。
図２１は、プッシュポリシーの共有のためにＨＴＴＰ要求を用いる場合のサーバ側における処理のステップを、フローチャート用いて示し、その一方で、図２２は、プッシュポリシーを共有するためにＨＴＴＰ要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて示す。
図１４の処理との比較において、サーバは、クライアントからのプッシュポリシー要求を取り扱い、かつまた初期のプッシュポリシーを送信してそれを更新する、新たな処理ステップ（２１００〜２１０５）を含む。
サーバによって受信された要求がクライアントからのプッシュポリシー要求であるならば（テスト２１００）、サーバは、まず、クライアントによって提案されたデータプッシュの制約を抽出するために、ステップ２１０１において、プッシュポリシー要求を解析する。
このステップの間、サーバは、クライアントによって要求されたプッシュポリシーに従うことを決定してもよい。そのような場合、サーバは、その内部のプッシュポリシーを更新し（ステップ２１０２）、提案されたプッシュポリシーを検証するために、ステップ２１０３において、クライアントに対してＯＫ２００の応答を送信する。
そうでなければ、サーバがプッシュポリシーを廃棄すると（例えば提案されたポリシーがリソースの観点からコストのかかりすぎる、または適用することができないので）、ステップ２１０２ではサーバにおいて内部プッシュポリシーを修正しない。また、エラーコードが、ステップ２１０３において、クライアントに対して送信される。
具体的な実施形態によれば、サーバは、クライアントの要求とは無関係に、そのプッシュポリシーをさらに更新してもよい。そのような場合、サーバは、ステップ１４０２の間に、プッシュポリシーを決定し、その特性（例えばクライアントおよびネットワークの特性によって実行された要求の解析による）を変更することを決定しても良いし、または、決定されたプッシュポリシーが現在のものとは異なるということを理解しても良い。このような状況において、サーバは、後者がそれにまだ気づいていなければ（テスト２１０４）、クライアントと新たなプッシュポリシーを共有しなければならず、その場合には、新たなプッシュポリシーは、ステップ２１０５において、ＨＴＴＰヘッダ内で送信される。
クライアント側の対応する処理は、図２２を参照して説明される。サーバ処理に関して、新たな処理ステップ（２２００〜２２０４）は、図１４の処理との比較において、プッシュポリシーメッセージを処理し、且つプッシュポリシー要求を実行するために追加される。
ステップ１４００において、現在の共有されたプッシュポリシー（すなわちサーバのプッシュポリシー）を決定した後に、クライアントは、例えば、メディアストリームのセグメントを取りだすために送信するＨＴＴＰ要求の数を低減するために、新たなプッシュポリシーを要望してもよい。したがって、新たなプッシュポリシーがクライアントによって要求されると（テスト２２００）、クライアントは、ステップ２２０１において、先に記述されたような「プッシュポリシー要求」によりＨＴＴＰ要求を送信する。
この要求に対する応答は、ＯＫ２００の応答またはそうでなければエラーコードを返すことによって、サーバが要求を有効にするか否かをクライアントがチェックするステップ２２０４において処理される。
サーバがＯＫ２００の応答を返せば、ステップ１４００において、決定された現在のプッシュポリシーが、要求されたポリシーと置き換えられる。そうでなければ、それはそのまま変更されない。
図１４の処理に加えて、クライアントがサーバから新たなプッシュポリシーでフレームを受信すると（テスト２２０２）、プッシュポリシーは、ステップ１４００の次のオカランスで取りだされるために解析され、メモリ内に保存される（ステップ２２０３）。
プッシュポリシー要求がまた他のデータ（例えばメディアデータ）も含むフレーム内にあると、他のデータが、ステップ１０９〜１１１〜１１３〜１１５を通じて処理される、ということに留意すべきである。
上記のＨＴＴＰに基づいた例は、適用されるプッシュポリシーを完全に定義するためにＨＴＴＰ要求を用いるが、１つの具体的な実施形態は、クライアントとサーバ側の両方において１セットの予め定義された同じプッシュポリシーを有し、各々が一意の識別子を有することを定義することに依存してもよい。この場合、ＨＴＴＰ要求は、セットの中から用いられるプッシュポリシーの識別子を指定するためにのみ用いられる。この具体的な実施形態は、ＨＴＴＰ要求のサイズを減少させる。
１つの実施形態において、プッシュポリシー要求は、サーバリソースの１つを要求するために用いられるＨＴＴＰ要求の１つの付加的なＨＥＡＤＥＲとして送信され、通常は、プッシュポリシー要求は、ＭＰＤファイルに対するＧＥＴ要求における「受理プッシュポリシー」ＨＴＴＰヘッダ内で送信される。
別の実施形態において、クライアントは、クライアントによって支持される（または必要とされる）プッシュポリシーのリストを示すために１つのＨＴＴＰ要求においていくつかの「Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ」を指定する。ＨＴＴＰ要求に応答して、サーバは、提案されたリスト内のプッシュポリシーの１つを選択し、そして、ＨＴＴＰ応答内のプッシュポリシーを指定してもよいし、または、どれもサッポートされなければ、新たなプッシュポリシーによって応答してもよい。
さらに別の実施形態において、プッシュポリシー要求は、サーバによって認識されるあらゆるリソースの独立した専用のＨＴＴＰ要求において送信される。例えば、ＧＥＴ（またはＰＯＳＴ）要求は、ウェブページのリソースのどれにも対応しないＵＲＬ、例えばｈｔｔｐ：／／ｓｅｒｖｅｒ／ｐｕｓｈ＿ｐｏｌｉｃｙと、さらに少なくとも１つのＡｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙヘッダとにより形成される。
さらに別の具体的な実施形態において、代替的なプッシュポリシーのセットは、各々が一意の識別子を有する、サーバとクライアントとの間で交換されたＭＰＤファイル内で定義されてもよい。プッシュポリシーの１つは、サーバによって選択されるデフォルトプッシュポリシーとしてマークされてもよい。クライアントは、デフォルトプッシュポリシーの交換に用いられるプッシュポリシーの識別子を含む新たなプッシュポリシー要求を送信することによって、どのプッシュポリシーが用いられるべきであるのかを指定してもよい。
１つの実施形態において、特定のプッシュポリシーは、高速起動のためにＭＰＤドキュメントに対する要求直後に、どのセグメントがプッシュされるのかを示すために定義される。
ハイブリッドアプローチにおいて、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第１のプッシュポリシー部および第２のプッシュポリシー部によって定義され、第１のプッシュポリシー部は、記述ファイル（ＭＰＤ）内に挿入され、第２のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるＨＴＴＰフレームのヘッダ内に埋め込まれる。
例えば、ＭＰＤは、プッシュポリシーＨＴＴＰ要求のおかげでサーバによってその後定義される（またはさらにオーバーロードされる）テンプレート引数によりプッシュポリシーを定義してもよい。例として、ＭＰＤファイル内に定義されたプッシュポリシーは、＜ＰｕｓｈＰｏｌｉｃｙ Ｓｅｇｍｅｎｔｌｄｘ＝”ｐａｒａｍｅｔｅｒ７＞であってもよく、変数「パラメータ」の値は、プッシュポリシーＨＴＴＰ要求において定義されてもよい。この例において、第２のプッシュポリシー部は、第１のプッシュポリシー部内に定義された１つ以上の関連変数に対する１つ以上の値（のみ）を有する。
上記のプッシュポリシー識別子ベースのアプローチを用いて、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第２のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第１のプッシュポリシー部を形成する。
クライアントに対してプッシュポリシーを宣言するための別の実施形態において、プッシュポリシーは、プッシュデータが選択されることになるリプレゼンテーションを示すＭＰＤ内に定義された〈Ｒｏｌｅ〉記述子に依存する。通常は、プッシュポリシーは、プッシュ戦略が「代替」または「追加」のロール値をもつＲｅｐｒｅｓｅｎｔａｔｉｏｎ内のセグメントを用いることになる、ということを指定してもよい。
別の実施形態において、例えばストリーミングマニフェスト、ＨＴＭＬページなどのリソースのドキュメントは、ＧＥＴ要求が受信された後にプッシュされるリソースを決定するために閲覧されるプライオリティツリーに変換される。プライオリティツリー内部のナビゲーションは、ＸＰａｔｈ要求のおかげで実行することができる。このアプローチにおいて、プッシュポリシー情報は、第２の非要求メディアデータを識別するリソースのドキュメントのツリー表現上で評価される、ＸＰａｔｈ式を含む。
例えば、ストリーミングマニフェストにおいて、「ｆｏｌｌｏｗｉｎｇ［ｎａｍｅ（）＝“ＳｅｇｍｅｎｔＵＲＬ”］［２］」のＸＰａｔｈ式は、プッシュされるセグメントとして、ＧＥＴ要求内のクライアントによって要求されたセグメントに続く２つのセグメントを選択するために用いることができる。また、チャプターを切り替える使用事例に関して、「（（ｆｏｌｌｏｗｉｎｇ［ｎａｍｅ（）＝“Ｐｅｒｉｏｄ”］／／ＳｅｇｍｅｎｔＵＲＬ）［２］）」のＸＰａｔｈ式は、各チャプターの最初の２つのセグメントを予めローディングするために後続のＰｅｒｉｏｄの最初の２つのセグメントを選択することを可能にする。例えば、クライアントが図２４のＭＰＤファイル内のセグメント２４０１を要求すると、後続のＰｅｒｉｏｄのセグメント２４０２および２４０３も、プッシュされたデータとしてサーバによって送信される。
さらに、高度なプッシュポリシールールのために書くＸＰａｔｈ式を単純化するために、例えばＸＳＬＴ命令を用いて、プライオリティツリーをまず再順序付けることができるかもしれない。ＸＳＬＴ命令は、プッシュポリシーを適用する前にツリーを再編成することを可能にする。ＸＰａｔｈ式は、好ましくは、クライアントに対して、例えば１つのＨＴＴＰヘッダ内で送信され、ＸＳＬＴスタイルシートは、ウェブページ内で定義される。これは、例えばドキュメント内の宣言するすべての画像、ＤＯＭツリーの同じレベルにおける連続するノードのようなすべてのＣＳＳリソース、をグループ化するために、特にＨＴＭＬドキュメントに適用する。
例えば、図２５のツリー２５０１は異なるタイプの異なるリソースも持つＨＴＴＰ頁を表し、ハッシュされたノード（２５１１〜２５１４）は、画像リソースに対応し、単色のノード（２５２１−２５２４）は、スクリプトリソース（ＣＳＳまたはＪａｖａ（登録商標）ｓｃｒｉｐｔ）である。ツリー２５０２は、タイプによってリソースをグループ化するＸＳＬＴ変換結果の例である（２５３０における画像および２５４０におけるスクリプトリソース）。簡単なＸＰａｔｈ式は、したがって、一旦この所定のタイプの第１のリソースが要求されれば、所定のタイプのためのいくつかのリソースがプッシュされることになる、ということを示すために、定義することができるかもしれない。
以上に記述されたすべての実施形態において、いくつかのセグメントがプッシュされることをプッシュポリシーが要求するならば、各々のクライアントに対していくつかのＰＵＳＨ＿ＰＲＯＭＩＳＥでのサーバ返信を要求する、という可能性が非常に高い。
例えば、図１９のＭＰＤ１９００は、要求されたセグメントに追従する３つのセグメントがプッシュされることになるということを示すプッシュポリシーを有する（＜ＰｕｓｈＰｏｌｉｃｙ＞要素を参照）。従って、クライアントが０〜９９９に等しいバイト単位の範囲でメディア１９０１に対するＧＥＴ要求によりイニシャライゼーションセグメントを要求すれば、サーバは、ステップ１０３の間に、３つのＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージに１９０２を送信することになる。
１つの実施形態において、識別された第２のメディアデータの各々がアナウンスメッセージ（すなわちＰＵＳＨ＿ＰＲＯＭＩＳＥ）を要求する複数のメディアセグメントを備える場合、対応する複数のアナウンスメッセージは、クライアント装置に対して送信される単一のアナウンスメッセージにマージされてもよい。
図２０に示されるように、この状況を実現するために、サーバにおける処理は、好ましくは、図１４の一般的な処理と比較して、ステップ１０３においてプッシュプロミスを送信する直前に前処理ステップ２０００を含む。前処理ステップは、アナウンスメッセージの上記のマージを実行しようと努める。
プッシュプロミスが１９０２のようにバイト単位の範囲の要求を含むと、プッシュプロミスのリスト１９０２は、連続するバイト単位の範囲のアドレスを含むプッシュプロミス１９０３の減少されたセットを生成するために閲覧される。次に、プッシュプロミス１９０２の各セットは、プッシュプロミスセット内のバイト単位の範囲の連結に等しい連続したバイト単位の範囲でプッシュプロミスの減少されたセットと、または例えば１９０５の不連続のバイト単位の範囲のリストでの単一のプッシュプロミスと置き換えられる。
例えば、３つのプッシュプロミス１９０２は、図１９に示される単一のプッシュプロミス１９０３と置き換えられる。
プッシュプロミスをマージするこのアプローチは、クライアントがより簡単な方法で、およびより低い帯域幅および処理コストで、プッシュデータの送信をキャンセルすることを可能にする。これは、マージされていない各々のプッシュプロミスの幾つかのストリームを閉じる代わりに、クライアントが単一のプッシュプロミスのための単一のストリームを閉じるだけで良いからである。
代替案において、プッシュプロミスが別々なバイト単位の範囲の間隔を有したとしても、プッシュプロミスは、すべて、バイト単位の範囲のリストと置き換えられてもよい（ここで連続するバイト単位の範囲の間隔は連鎖される）。
さらに、プッシュプロミスがバイト単位の範囲の間隔ではなく、異なるＳｅｇｍｅｎｔＵＲＬ値を含む場合、プッシュプロミスも、また、以下の通り単一のプッシュプロミスメッセージを生成するために連鎖されてもよく、生成されたプッシュプロミスメッセージの方法はＭＧＥＴ（複数のＧＥＴのための）として定義される。また、パスフィールドは、１９０４に表現されるようなセグメントＵＲＬのリストである。先の実施形態と同様に、クライアントは、すべてのセグメントのプッシュをキャンセルするために生成されたプッシュプロミスに対応する単一のストリームを閉じなければならない。
クライアントが各プッシュされたセグメントを解析し識別することができることを保証するために、サーバは、その後に送信されるデータ内の各々のセグメントの端部においてＥＮＤ ＳＥＧＭＥＮＴフラグを含んでもよい、ということに留意されたい。
さらに、ＨＴＴＰ／２のＳＥＴＴＩＮＧＳフレームは、プッシュプロミスのグループ化がストリーミングセッションのために許可されるか否かを示すことを可能にする、新たなＳＥＴＴＩＮＧＳ＿ＥＮＡＢＬＥ＿ＧＲＯＵＰ＿ＰＵＳＨ＿ＰＲＯＭＩＳＥパラメータを含むために拡張される。
本発明の実施形態は、１回または複数回のラウンドトリップを回避することができるので、ＤＡＳＨ高速起動を有することを可能することができる。ここで、図２６〜図２８を参照して、本発明のこの態様を、説明する。
ＤＡＳＨ高速起動機能は、図７〜図１２および図１４〜図２５のすべてまたは一部を参照して、上記された何れの通信アプローチとともに用いられてもよい。
図２６は、ＤＡＳＨ高速起動を取得するために、本発明の教示によるサーバによって、およびクライアント装置によって、それぞれ実施される例示的な方法を示す。
まさに記載された標準プロセスに関して、第１のステップは、クライアントが記述ファイル、ここではＭＰＤファイル、を要求するためにある（ステップ２６５０）。そして、クライアントは、サーバの応答を待つ（ステップ２６５１）。
その間に、サーバは、以下に説明されるように、特にクライアントがより高速に開始するのを支援するイニシャライゼーションデータを識別するために（ステップ２６５３）ＭＰＤファイルを解析する（ステップ２６５２）。ステップ２６５３の例示的な実施形態は、図２７を参照して、以下に説明する。
一旦イニシャライゼーションデータがサーバによって識別されれば、クライアントの要求を待たずに、イニシャライゼーションデータをプッシュするその意図を示すために、ステップ２６５４において、クライアントに対してＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。
場合によっては、それは、また、クライアントが関係するリソース、すなわち、：ｓｃｈｅｍｅ、：ｈｏｓｔ、および：ｐａｔｈなどの関係する初期のメディアデータ、を識別することを可能にするヘッダ部を含む別のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信することによって、初期のメディアデータ（ステップ２６５６）をプッシュすることになる、ということをさらに示す。
イニシャライゼーションデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム、および初期のメディアデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの場合、他のヘッダ部も、また、プッシュすることを決定したデータにおいてサーバがどれほど確信しているのかを示すために、サーバによって追加され、本実施形態において、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータはＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに関連付けられる（すなわち、ヘッダ内に含まれる）。図２７を参照して、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータの決定を以下に説明する。サーバは、また、プッシュするつもりのセグメントを明白に示すために特定のＤＡＳＨヘッダを挿入することができる。
プッシュされるべきイニシャライゼーションデータおよび第１のメディアデータのためにクライアントが要求することのリスクを最小化するために、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、応答において、いずれかのコンテンツに先立って送信されるべきである。すなわち、ステップ２６５４およびステップ２６５６は、サーバからクライアント装置までＭＰＤファイルを送信するステップ２６５５の前に行われるべきである。
したがって、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがクライアント装置に対して送信されると、サーバは、ステップ２６５５において、クライアント装置に対してＭＰＤファイルを送信する。
その間にサーバがクライアント装置からＣＡＮＣＥＬまたはＥＲＲＯＲのメッセージを受信していなければ、イニシャライゼーションデータ（ステップ２６５７）および第１のメディアデータ（ステップ２６５８）をプッシュし始める。
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームおよびサーバからクライアント装置へのデータのプッシュは、例えばドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ、ＨＴＴＰｂｉｓ作業部会、インターネットドラフト、２０１３年６月２４日（例えばｈｔｔｐ：／／ｈｔｔｐ２．ｇｉｔｈｕｂ．ｉｏ／ｈｔｔｐ２−ｓｐｅｃ／において利用可能）内に記述されるような、例えばＨＴＴＰ２．０のフレームにおいて展開される、対応する機能にしたがって実行される。
クライアント装置が受信すると、イニシャライゼーションデータは、復号器を設定する（ステップ２６５９）ためにクライアントによって用いることができ、画面停止なしで十分なデータ量が復号化およびレンダリング（例えば、表示）のために利用可能になるまで、第１のメディアデータは、バッファリングされる（ステップ２６６０）。
クライアントがＭＰＤファイルを完全に受信し、完全にデータをバッファリングすると（ステップ２６６１）、それを解析して（ステップ２６６２）復号化し表示し始め（ステップ２６６３）。そうでない場合は、クライアント装置が、さらなるセグメントが送信されることを、サーバによって送信されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（ステップ２６５６を参照）から認識するならば、ステップ２６６４において、サーバからの第１のメディアデータのプッシュの完了を待つ。このアイドルステップ２６６４の間、クライアント装置は、既に上で説明されたように、標準的なクライアント制御のＤＡＳＨ（ステップ２６６５）において発行される後続のセグメントのために次の要求を準備してもよい。対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（上記ステップ２６５６を参照）内のプッシュされる（またはプッシュされている）初期のメディアデータの受信情報をクライアント装置が有するので、これは可能であり、したがって、サーバによってプッシュされると意図された最後の時間セグメントを直後に続く時間セグメントのための要求を準備することができる。
クライアント装置は、ＭＰＤを全て受信すると、この初期のメディアデータがバッファを満たすか否かをチェックするために、そうでなければ、ステップ２６６１の前の標準的なクライアント制御のＤＡＳＨ処理にしたがって後続のメディアデータ（例えば初期のメディアデータによって表現される時間セグメントに続く時間セグメントに対応するメディアデータ）に対する要求を送信するために、ステップ２６５６において受信された初期のメディアデータの情報を用いてもよい（プッシュされた初期のメディアデータがバッファを満たすケースを示す図２６に示されるものとは逆に）。これは、クライアントが、プッシュする大量の第１のメディアデータの上のサーバから不良な推定を訂正することを可能にする。
この処理は、ストリーミングクライアントが、標準的マニフェストベースのストリーミングよりも早くメディアを表示し始めることを可能にする。実際は、ネットワーク上のＨＴＴＰラウンドトリップの数がイニシャライゼーションデータおよび／または初期のメディアデータを得るために減少されるので、起動遅延は減少する。
但し、この処理は、以下の理由から、現在のＤＡＳＨ規格に準拠したままである。
・ＭＰＤファイルの修正がない。その送信は軽量で高速のままである。
・標準ＤＡＳＨクライアントの挙動は不変のままである（すなわち、本発明の教示から恩恵を受けない）。このようなクライアント装置は、認識されないＨＴＴＰヘッダを無視するだろう。そして、プッシュ機能を受け入れなければ、さらなる要求／応答を単純に実行しなければならないだろう。したがって、表示を開始するために多くの時間を費やすだろう。
図２７は、クライアント装置からのマニフェスト（または記述ファイル）に対する要求に追従するサーバ側において実施される例示的な方法説明する。
この方法は、クライアントがメディアプレゼンテーションの表示を急速に開始することができるように、予めプッシュする最も関連する初期データを識別しようと努める。
ステップ２７００において、マニフェストに対する要求が受信される。そして、サーバは、クライアント装置が要求内にいくつかのプレファレンスを挿入したか否かを、ステップ２７０１において、チェックする。例えばメディアプレゼンテーションのための送信速度およびオーディオストリームのための好適な言語を表現するためになど、これは、以下の専用のＨＴＴＰヘッダなどを介して行われてもよい。
ＧＥＴ ｈｔｔｐ：／／ｍｙｓｅｒｖｅｒ．ｃｏｍ／ｐｒｅｓｅｎｔａｔｉｏｎ／ｐｒｅｓ１．ｍｐｄ ＼ｒ＼ｎ
Ｐｒｅｆｅｒｅｄ−ＭｅｄｉａＲａｎｇｅ： ｂｗ＝２０００：ｌａｎｇ＝ＦＲ＼ｒ＼ｎ＼ｒ＼ｎ
要求がプレファレンスを含むならば（テスト２７０１で真）、サーバは、クライアントのプレファレンスを解析し（ステップ２７０３）、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを値「高」に設定する（ステップ２７０４）。
表示が要求において提供されないならば（テスト２７０１で偽）、サーバは、このクライアントのサービス利用情報（ログ）（すなわちユーザまたはクライアント装置とサーバとの間の従来の交換に基づく統計値または使用データ）またはＵｓｅｒ−Ａｇｅｎｔヘッダからの情報を既に示しているか否かを、ステップ２７０２において。チェックする。実際は、Ｕｓｅｒ−Ａｇｅｎｔヘッダは、ＲＦＣ２６１６（例えばｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２６１６．ｔｘｔを参照）内のＨＴＴＰヘッダとして定義され、例えばオペレーティングシステム、ブラウザタイプ、アプリケーション名などの情報を交換するアプリケーションのための手段を提供する。例えば、ＤＡＳＨサーバは、サービスを用いることができるようになる前にクライアントに対する認証スキームを有してもよく、変形物において、それは、サービスに対してアクセスする前にロギングするユーザであり得る。このような手段により、サーバは、メディアパラメータを、接続されたユーザまたは装置に対してリンクすることができる。
前の利用情報（ログ）が、関係するクライアント装置またはユーザが利用可能であると（テスト２７０２で真）、ステップ２７０５においてログを解析することによって、サーバは、所定のクライアントまたはユーザにとっての最も頻度の高い利用方法を推定することができる。例えば、ユーザまたはクライアント装置がＨＤ（高解像度）のフランス語によるオーディオストリームおよびビデオストリームを常に選択する、ということを推定することができる。さらに、サーバは、これがオープンＴＣＰ接続における第１の要求であるか否か（サービスに対して接続され、且つ第２のメディアプレゼンテーションを要求するクライアント）を知ることができる。この場合、帯域幅推定は、さらに正確で且つさらに確実になり得るし、ＴＣＰ輻輳ウィンドウは、第１の要求に対するものよりも大きくなるであろう。これは、適したＲｅｐｒｅｓｅｎｔａｔｉｏｎの観点から、サーバによって行われる選択に影響を与えることができる。
ＤＡＳＨ品質メトリックを登録することによって、サーバは、そのログ内にユーザ／クライアントが通常実行する様々なリプレゼンテーションの中の変更を持つことができる。このことから、サーバは、通常の挙動を、「積極的（ａｇｇｒｅｓｓｉｖｅ）」または変更の頻度に依存する定数（ｃｏｎｓｔａｎｔ ｄｅｐｅｎｄｉｎｇ ｏｎ ｔｈｅ ｆｒｅｑｕｅｎｃｙ ｏｆ ｃｈａｎｇｅｓ）の間で決定する（いかなる基準：帯域幅、解像度、フレームレート等でも、変更によって、我々は他のＲｅｐｒｅｓｅｎｔａｔｉｏｎに切り換えることを意味する。）。積極的なクライアント（ａｇｇｒｅｓｓｉｖｅ ｃｌｉｅｎｔ）は、そのコンテキストが変化すると、異なるリプレゼンテーションに自動的に切り替えるＤＡＳＨクライアントである。例として、帯域幅またはバッファ占有期間を監視すると、積極的なクライアントは、現在のＲｅｐｒｅｓｅｎｔａｔｉｏｎと比較して、新たなＲｅｐｒｅｓｅｎｔａｔｉｏｎがクライアントのコンテキストに近い特性を有すると直ちに、異なる帯域幅でＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することになる。反対に、一定のクライアントは、安定した品質および表示速度を維持するために、頻繁なＲｅｐｒｅｓｅｎｔａｔｉｏｎの切り換えを回避しようとするだろう。ユーザ／クライアント装置挙動が適応の観点からいくぶん積極的であると、サーバは、それがストリーミングを開始するために初期のリプレゼンテーションとして何を選択ようとも、クライアントは、続く最初の数秒または数分間のストリーミングにおいて適応しようとする、ということを知る。
プレファレンスがログから推定されると、サーバは、ステップ２７０６において、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを値「中」に設定する。実際は、この情報は、クライアントそれ自体によって信号で送る明示的なプレファレンスよりも関連性が低いかもしれない（テスト２７０１で真）。
利用可能なログ情報がない場合（テスト２７０２で偽）、サーバは、その時、ステップ２７０７において、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを最低値「低」にする。これは、決定するべき演繹的な情報がないので、サーバが、プッシュする情報上でベストの推測を実行していることを示す。この場合のさらなる処理を、以下に説明する記載する（ステップ２７１１を参照）。
このｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータ計算と並行して、サーバは、ステップ２７０８において、マニフェストを解析してもよい。マニフェストが頻繁に変更しがちではない（ライブサービスとは逆に、特にオンデマンドのサービスに対して）場合において、マニフェストの解析は、ルックアップテーブル内の様々なＲｅｐｒｅｓｅｎｔａｔｉｏｎの記述を登録することによって、今回限りで、オフラインで実行することができる。このルックアップテーブルは、また、クライアントのログをメディアプレゼンテーションのいくつかの部分に対してリンクするために、サーバによって用いられてもよい。これによって、いくつかのクライアントのプレファレンスを推定するために、より高速のログ処理（上記のステップ２７０５を参照）を行うことが出来る。
マニフェストの解析（ステップ２７０８）は、ストリーミングを開始するために初期のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（すなわち初期のメディアデータ）として適したＲｅｐｒｅｓｅｎｔａｔｉｏｎを（ステップ２７０９において）選択するときに、サーバに対して情報を提供する。
（要求においてプレファレンスをそれぞれ取得する、または、先の交換からの使用データに基づく）両方のステップ２７０３および２７０５は、クライアント装置／ユーザからプレファレンスまたは利用をＭＰＤ属性と一致する具体的なパラメータ内に変換することにある。例えば、それは、帯域幅、ビデオの幅および高さ、使用中のコーデックの種類、字幕のための言語、またはオーディオストリームであり得る。そして、これらのパラメータのために取得された値から、サーバは、クライアントに対してプッシュするべき最も都合のよいＲｅｐｒｅｓｅｎｔａｔｉｏｎを、ステップ２７０９において識別するために、マニフェスト内の値と比較する。
このステップ２７０９は、通常は、クライアント装置がＤＡＳＨのような動的および適応型ストリーミングプロトコルで継続的に実行するものである、ということに留意されたい。ここで、同じステップは、ＭＰＤ構文解析手段により、ストリーミングセッションの先頭において、サーバによって実行される。
適したＲｅｐｒｅｓｅｎｔａｔｉｏｎを２７０９において推定することができない場合、テスト２７１０は偽であり、サーバは、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを（前述のステップ２７０７において）「低」値にする。
ｃｏｎｆｉｄｅｎｃｅ＿ｖａｌｕｅパラメータが「低」値を有する場合（プレファレンスを決定することができなかったので、または適したＲｅｐｒｅｓｅｎｔａｔｉｏｎがプレファレンスに基づいて見つからないので）、サーバは、最も簡単なＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することをステップ２７１１において判断する。ビデオに関して、例えば、最も簡単なＲｅｐｒｅｓｅｎｔａｔｉｏｎは、最低の空間解像度によるＲｅｐｒｅｓｅｎｔａｔｉｏｎであってもよいし、最低の帯域幅用に設計されてもよい。
（図２７には表現されない）可能な補完的な特徴によれば、コーデック上にアンビギュイティがない場合（すなわち、ビデオＲｅｐｒｅｓｅｎｔａｔｉｏｎは、すべてコーデック属性と同じ値を有し、すなわち、同じコーデック、例えばＨＥＶＣは、ビデオＲｅｐｒｅｓｅｎｔａｔｉｏｎをすべて符号化するために用いられている）、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータは、値「中」に引き上げられてもよい。
ステップ２７１１の次のステップは、または適したＲｅｐｒｅｓｅｎｔａｔｉｏｎが見出された場合（テスト２７１０で真）は、イニシャライゼーションデータを識別することにある（ステップ２７１２）。実際に、ＤＡＳＨマニフェスト（または記述ファイル）において、イニシャライゼーション情報は、異なる方法で、信号で送ることができ、それは、イニシャライゼーションデータに対して直接的なＵＲＬを提供するＳｅｇｍｅｎｔＢａｓｅ、ＳｅｇｍｅｎｔＬｉｓｔまたはＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ要素のイニシャライゼーション要素内に明示的に加えることができる。
この場合、このＵＲＬは、（変数：ｓｃｈｅｍｅ、：ｈｏｓｔ、：ｐａｔｈ、および最終的に：Ｒａｎｇｅを指定することによって）プッシュされることをプロミスされたリソースをクライアントが識別することを可能にするＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのヘッダ部内に加えられる（図２６を参照しながら上記されたステップ２６５４を参照）。
イニシャライゼーションデータが明示的に記述されない場合、これは、メディアセグメントがセルフイニシャライズされる、ということを意味する。そのような場合、サーバは、セグメントの最初（例えばｍｐ４形式のセグメントのためのセグメントインデックス情報ボックス）を解析しなければならない。この解析に基づいて、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内にヘッダとして加えられる対応するＵＲＬを適切なバイト単位の範囲で構築することができる。
一旦識別されれば、イニシャライゼーションデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、クライアントに対して直ちに送信され（図２６におけるステップ２６５４に対応するステップ２７１３）、その直後にイニシャライゼーションデータのプッシュにより送信される（図２６におけるステップ２６５７に対応するステップ２７１７ａ）。イニシャライゼーションデータが受信されると、クライアントは、その後、そのメディア復号器をイニシャライズすることができる（ステップ２７１７ｂ）。
随意に、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを処理するときにクライアント装置によってセグメント信号送信およびその後の識別を向上させるために（以下に記載のステップ２８０６を参照）、サーバは、ステップ２７１３において、プッシュされたデータの性質と、イニシャライゼーションまたはメディア若しくは両方（自分でイニシャライズするセグメントの場合）と、ＵＲＬテンプレートのパラメータまたは図５ｂのＭＰＤリプレゼンテーションツリーにおけるパスのようなセグメントの表示（例えば：Ｐ２ＡＳ２１Ｒ２１１Ｓ１、すなわち、識別子に続く要素型の連結）を示すことができる。これは、ＭＰＤを受信するようにクライアント装置に要求する、ということに留意されたい。そして、サーバは、クライアント装置によってＭＰＤ受信の後に処理されることになると考えるＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージ内にのみ、この特定情報を追加することを決定することができる。ＭＰＤの受信および解析の前にＰＵＳＨ＿ＰＲＯＭＩＳＥを受け入れるかまたは受け入れないかをクライアント装置で決定することを支援するために、サーバは、ＭＰＤ内のセグメントパスの代わりに、プッシュされたセグメントの定性的情報（例えばそれがベース層またはエンハンスメント層からのセグメントであるか否かなど）を示すことができ、また、別の例によれば、サーバは、それらの値で選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの属性をヘッダ内に配置することができる。
（図２７には表現されない）可能な実施形態によれば、ステップ２７０８においてマニフェストの解析が、イニシャライゼーションデータがマニフェストのトップレベル要素内にあることを判定するときに、（すなわち、例えば依存するＲｅｐｒｅｓｅｎｔａｔｉｏｎの場合には、いかなるＲｅｐｒｅｓｅｎｔａｔｉｏｎでも、イニシャライゼーションデータは、すべてのリプレゼンテーションに共通である）、サーバは、プッシュされたデータとクライアントが選択したであろうものとの間のミスマッチのリスクがないので、「高」値に設定されたｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータセットによりイニシャライゼーションデータを指定するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを直ちに（すなわちステップ２７０８と同時に）送信することができる。例えばＨＴＴＰヘッダとしてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームとともにｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを送信する利点は、プッシュプロミスを受け入れるかまたはキャンセルする際に、それがクライアント装置を支援することができるということである（以下に説明する図２８の記述を参照）。
この機能のおかげで、クライアントは、（ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが初期に送信されるので）その復号器を設定するのに必要なイニシャライゼーションデータを一層早く受信することになる。イニシャライゼーションデータが所定のメディアタイプごとにユニークであるときに（例えば、このＡｄａｐｔａｔｉｏｎＳｅｔ内のリプレゼンテーションの数はいくつであってもＡｄａｐｔａｔｉｏｎＳｅｔ当たり１つの単一のＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔである）、これもまた動作する。この一層高速のプッシュは、マニフェストの解析（上記のステップ２７０８）の直後に行われることになり、従ってログまたはプレファレンスを処理する（上記のステップ２７０１、２７０３、および２７０５）前に行われる。
そして、先にサーバによって決定されたｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータが、値「中」以上であれば（テスト２７１４）、サーバは、クライアントのために適しているものとして考えられる第１のメディアデータをプッシュするイニシアチブをとる。
これは、２つステップにおいて反復して行われ、最初にＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが送信され（図２６のステップ２６５６に対応するステップ２７１５）、そして、第１のメディアデータのプッシュがステップ２７１９において開始する。これは、ステップ２７０９においてプッシュされるように選択された各第１のメディアデータセグメントに対して繰り返される。
可能な実施形態によれば、連続するメディアセグメントがプッシュされることがプロミスされるときに（すなわち、複数のＰＵＳＨ＿ＰＲＯＭＩＳＥがそれぞれのメディアセグメントのために送信される）、現在のメディアセグメントに関連付けられたＰＵＳＨ＿ＰＲＯＭＩＳＥは、先のＰＵＳＨ＿ＰＲＯＭＩＳＥのチャイルドまたはフォロアとしてマークされる（ステップ２７１６）。サーバがステートレスである場合、これは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内に新たなＨＴＴＰヘッダとして加えることができ、また、サーバがステートフルである場合テーブル内に保持されることができる。この関連性の保持は、プッシュプロミスに対して階層的なキャンセルを実行するのに有用かもしれない（図２８を参照して以下で説明するように）。
データの様々な送信が可能なスケジュールは、以下の通りである。すなわち、実際に第１のメディアデータをプッシュする前に、サーバは上記のステップ２７１７ａにおいてイニシャライゼーションデータをプッシュし始める。第１のメディアデータおよびイニシャライゼーションデータに関連するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信と並行して、サーバは、また、ステップ２７１８において、ＭＰＤファイル（マニフェスト）を送信し、プッシュされたデータが完全に送信されるまで、ストリームのオープンを保持する。
別の実施形態において、テスト２７１４は、いかなる信頼度であっても、第１のメディアデータをプッシュするために回避されることができる。但し、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータが「低」に設定されている場合、サーバは、第１の（または初期の）メディアデータを実際にプッシュする前に、クライアントからの可能性のあるＣＡＮＣＥＬを待ってもよい。
第１のメディアデータをプッシュすると、サーバは、プッシュするデータの全体的な量を決定し、使用する速度を決定する（フロー制御）。
第１の態様に関して、サーバは、例えばマニフェストの先頭における前述のｍｉｎＢｕｆｆｅｒＴｉｍｅ属性などのマニフェストからの情報を活用することができる。この属性を用い、ステップ２７０９または２７１１において選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎ考慮し、所定のセグメント期間属性がマニフェスト内にあるとすると、サーバは、ｍｉｎＢｕｆｆｅｒＴｉｍｅ制約を実現するためにプッシュするセグメントの数（すなわち、セグメントの量、したがってプッシュされる初期のメディアデータを形成するデータの量）を容易に決定できる。有なことに、マニフェストの解析をオフラインで実行する場合（ステップ２７０８）、第１のメディアセグメントのこの数を、サーバのメモリ内のテーブル内に記録することができる。
第２の態様に関して、セグメントの期間および選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの帯域幅を与えられると、必要なビットレートの推定は、サーバによって取得されるであろう。これは、主としてビデオセグメントのために、用いる送信速度を提供する。例えば、５秒の期間のセグメントを有する、１．６メガビット／秒に等しい帯域幅により圧縮されたビデオリプレゼンテーションに対して、各セグメントは、送信する１メガバイトのデータを表現するだろう。デフォルトでは、ＨＴＴＰｖ２．０におけるフロー制御は、６５５３５バイトにほぼ等しいストリームウィンドウサイズを提供する。したがって、我々の例において、これは、プッシュされた６５５３６バイトの各パケットに対して、クライアントは、サーバに戻す肯定応答を送信しなければならず、そのため、我々の例においては、１セグメント当たり１５回を超える！ということを意味する。開発中のＨＴＴＰ２．０下でプッシュ機能を用いる場合にネットワークラウンドトリップおよびトラフィックを減少させることを目指すので、我々は、（ネットワークトラフィックを減少させることによって）ＤＡＳＨ高速起動を可能にするためにデフォルト挙動（実際にはデフォルトの輻輳ウィンドウサイズ）を改善する必要がここにある、ということを明確に認識する。
クライアント装置が、マニフェストに対する要求内に含まれたプレファレンスを送信する場合、要求の直後にＳＥＴＴＩＮＧＳフレームが送信されるべきである、ということを、また、示すことができ、このＳＥＴＴＩＮＧＳフレームは、そのバッファリング容量にしたがって、例えば初期ウィンドウサイズ（ＳＥＴＴＩＮＧＳ＿ＩＮＩＴＩＡＬ＿ＷＩＮＤＯＷ＿ＳＩＺＥ）を指定する。可能な変形物によれば、このＳＥＴＴＩＮＧＳフレームは、接続設定時間に送信することができる。別な可能性は、クライアント装置が、第１のプッシュデータを通知する場合に適切なサイズのＷＩＮＤＯＷ＿ＵＰＤＡＴＥを送信することである。
図２８は、本発明の教示による、例えば図２７に記載されたような方法を実行するサーバとデータを交換する場合に、クライアント装置によって実施される可能な方法を記述する。
この方法の可能なアプリケーションによれば、クライアント装置は、ビデオ・オン・デマンドサービスから恩恵を得るために、サーバに対して接続する。クライアントとサーバとの間の接続確立は、従来のものである。本例において、クライアント装置およびサーバの両方は、例えば既に前述したドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ」に記述されたＨＴＴＰ／２．０プロトコルを用いてメッセージを交換することができる。
ある時に（例えばクライアント装置におけるユーザが所定のビデオを選択するときに）、クライアント装置は、メディアプレゼンテーション（ここではユーザが見たいビデオ）を記述するマニフェストのアドレス（例えばＵＲＬ）上のサーバから情報を得る。
そして、クライアント装置は、マニフェストをダウンロードする要求を準備する（ステップ２８００）。好ましい実施形態において、クライアントは、ＨＴＴＰヘッダを通じてビデオ解像度、コーデック、それを支援する帯域幅に、いくつかのプレファレンスを追加する（ステップ２８０１）。そして、クライアント装置は、サーバに対してその要求を送信する（ステップ２８０２）。
本実施形態において、クライアント装置は、そして、そのバッファリング容量に従って初期ウィンドウサイズ（ＳＥＴＴＩＮＧＳ＿ＩＮＩＴＩＡＬ＿ＷＩＮＤＯＷ＿ＳＩＺＥ）を示すために、ステップ２８０３において、ＨＴＴＰ／２．０ ＳＥＴＴＩＮＧＳフレームを送信する（上記のドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ」のセクション３．８．５を参照）。
ステップ２８０４において、クライアント装置は、様々なサーバ応答を処理し始める。すなわち、マニフェストを形成するデータを受信し、そのマニフェストを解析する（ステップ２８０５）だけでなく、サーバによって送信されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームも受信し、解析する（ステップ２８０６）。
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（単数または複数）内の指定されたプッシュ（単数または複数）を受け入れるかキャンセルするかを決定する前に、クライアントは、サーバがプッシュするように意図するリソースのＵＲＬを構築し（ステップ２８０６）、サーバによってＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内に含まれているｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータをチェックする（ステップ２８０７）。
並行して、そしてマニュフェスト（記述ファイル）が完全に受信されると、クライアント装置は、入手したい所望のメディアセグメントのリスト（すなわちそのニーズに最良に適する各セグメントのバージョンのリスト）を構築し（ステップ２８０８）、現在のｓｅｇｍｅｎｔ＿ｉｎｄｅｘ変数を０にイニシャライズする（ステップ２８０９）。ＰＵＳＨ＿ＰＲＯＭＩＳＥの処理において第１のステップは、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータをチェックすることにある（ステップ２８１０ａ）。そして、例えば（事前に定義された）クライアントセッティングまたはユーザのプレファレンスに依存して、クライアントは、例えば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが「低」値のｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを含むＰＵＳＨ＿ＰＲＯＭＩＳＥなどの、一定レベルの信頼度下のＰＵＳＨ＿ＰＲＯＭＩＳＥを拒否することを決定することができる。
クライアントが（前述のステップ２８０８においてマニフェストから導き出されたような）所望のセグメントのＵＲＬとＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内の前述のＵＲＬとをマッチさせることができる（ステップ２８１０ｂ）ならば、それらの送信状態により送信されている保留中のセグメントのリストのためのテーブルをイニシャライズする（ステップ２８１１）。ステップ２８１０ｂにおいて、所望のメディアセグメントのリスト内のサーバによってプッシュされるように意図されたセグメントをクライアントが識別することができなければ、サーバに対して適切なＣＡＮＣＥＬ命令を送信することによってプッシュをキャンセルする（ステップ２８１２）。
ステップ２８１０ｂにおけるセグメント識別を容易にするために、クライアントは、例えば、ＭＰＤツリー表現内のパス（図５ｂを参照）として、プッシュされたセグメントのインデックス、または記述ファイル（すなわちＭＰＤファイルまたはマニフェスト）がＳｅｇｍｅｎｔＴｅｍｐｌａｔｅに依存する場合にはＵＲＬテンプレートパラメータのような、付加的なヘッダ情報を活用することができる。
これは、ＰＵＳＨ＿ＰＲＯＭＩＳＥを構築する際にサーバによって挿入された階層関係を用いるので（上記図２７の記述を参照）、ここでは特定のＣＡＮＣＥＬメッセージであり（ステップ２８１２）、クライアントは、後続の１つを加えた現在のＰＵＳＨ＿ＰＲＯＭＩＳＥのキャンセルをもたらす再帰的なＣＡＮＣＥＬを送信することができる。
可能な実施形態によれば、クライアント装置がプッシュプロミスを解釈することができない場合、メディアのリソースの次の時間セグメントに対応するメディアデータのすべてのプッシュを、デフォルトによって停止する。
ＣＡＮＣＥＬ命令のこの新たな利用により、メディアセグメント識別の観点から、一旦それがサーバと非同期にされると、クライアントがＣＡＮＣＥＬメッセージを繰り返すことを回避する。そのような場合、クライアントは、プルモードに戻ることになる。
そして、プッシュによってサーバから受信されるセグメントが所望のセグメントに対応する場合（テスト２８１０ｂで真）、クライアントは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの処理を継続する（テスト２８１３およびステップ２８０６上でのループ）。
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがすべて処理されると、クライアント装置は、受理したＰＵＳＨ＿ＰＲＯＭＩＳＥに対応するデータを受信してバッファリングすることを（ステップ２８１４）予期し、開始する。
十分なメディアセグメントがクライアントの受信バッファ内に受信されると（テスト２８１５）、それらはクライアントによって処理される（２８１６）。そして、現在のｓｅｇｍｅｎｔ＿ｉｎｄｅｘ変数は、リスト内の第１のセグメントの順序付け数で更新される（ステップ２８１７）。すべてのクライアントがクライアントのバッファに対してアクセスするとは限らないかもしれない、ということに留意するべきである。例えば、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。この情報は、例えばウェブソケット接続を用いて、サーバからクライアントまで交換されることができる。
プッシュされたメディアセグメントがすべて処理されると、クライアントは、次に、標準的なプルベースのＤＡＳＨ（ステップ２８１８）に戻り、変数ｓｅｇｍｅｎｔ＿ｉｎｄｅｘ＋１によって指定された、次のセグメントに対応するデータの要求を開始する。並行して、プッシュされたセグメントデータは、選択されたビデオの復号化および表示を開始するために用いられる。
図１３は、実施形態に従う装置の概略図である。装置は、サーバ、クライアント、またはプロキシであってもよい。装置は、実施形態による方法を実施するように構成された制御部１３０１のためにワークメモリとして用いられるＲＡＭメモリ１３０２を備える。例えば、制御部は、ＲＯＭメモリ１３０３からロードされたコンピュータプログラムの命令を実行するように構成されるであろう。プログラムは、また、ハードドライブ１３０６からロードしても良い。例えば、コンピュータプログラムは、図８〜図１２、図１４、図１５、図１７、図２０〜図２２、および図２６〜図２８のフローチャートおよび上記の記述に基づいて設計される。
装置は、また、単一のネットワークインタフェースであってもよいネットワークインタフェース１３０４を備えるか、または、１セットのネットワークインタフェース（例えば、いくつかの無線インタフェース、またはいくつかのタイプの有線若しくは無線インタフェース）を備える。装置は、ユーザに対する情報を表示するための、およびユーザから入力を受信するための、ユーザインタフェース１３０５を備えてもよい。
装置は、また、外部装置から／外部装置に、データを受信および／または送信するための入出力モジュール１３０７を備えてもよい。
本発明が図面および前述の記述に詳細に図示され記述されたが、このような例証および記述は、例証または例示的であって限定的ではなく、本発明が、開示された実施形態に限定されない、ということを考慮すべきである。開示された実施形態にする他の変形物は、図面、開示物、および添付の請求項に関する研究から、特許請求された発明を実施する際に、当業者によって理解され、達成され得る。
なお、本実施形態は以下のように捉えることもできる。
すなわち、サーバの観点に対応する本発明の第１の態様によれば、サーバ装置によってメディアデータをクライアント装置に対してストリーミングする方法は、
・クライアント装置から第１のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第２のメディアデータを識別するステップと、
・前記要求に応答して、前記クライアント装置に対して前記第１のメディアデータに関連する情報を送信し、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージを準備するステップと
を備え、
前記方法は、サーバ装置がクライアント装置に対する第２の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるステップをさらに備える。
クライアントの観点に対応する本発明の第２の態様によれば、サーバ装置によってストリーミングされたメディアデータにクライアント装置によってアクセスする方法は、・第１のメディアデータに関連する要求をサーバ装置に対して送信するステップと、・前記要求に応答して、前記第１のメディアデータに関連する情報を前記サーバ装置から受信するステップと
を備え、
前記方法は、クライアント装置が、クライアント装置によって要求されることなくサーバ装置によって送信される第２のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるステップをさらに備える。
特に、共有されるプッシュポリシーは、クライアント装置に対してサーバ装置によって送信される第２の非要求メディアデータを決定する装置のために、第２のメディアデータを決定する方法を定義してもよい。
このアプローチにより、サーバのプッシュされるメディアデータに関する判定とクライアントのニーズとの間のミスマッチを減少させることができ、それにより、リソースを節約することができる。
これは、クライアントが、サーバの挙動と、それによりこれからプッシュされる第２のメディアデータを予期することを可能にする共有されるプッシュポリシーを用いることによって、実現される。いくつかのクライアントの後続の要求のために用いられる共有されるプッシュポリシーにより、クライアントは、要求がサーバに対して送信される前でさえも、サーバの挙動を予期することができる。
予期の結果として、クライアントは、サーバによるアナウンスに関して予期される方式で、必要でないこのような第２のメディアデータのキャンセルを準備し要求することができる。
第１のメディアデータに関連する要求は、第１のメディアデータおよび／またはこの第１のメディアデータに関連する他のデータに関係してもよい。
第２のメディアデータは、例えばサーバ装置によって、前記第１のメディアデータに関連づけられてもよい。
本発明の実施形態は、サーバ誘導（ｓｅｒｖｅｒ−ｇｕｉｄｅｄ）ストリーミングのための軽量のメカニズムを提供する。実施形態は、ＤＡＳＨネットワークとの関連で実施されてもよい。
サーバ装置は、クライアント装置に対してコンテンツ推薦を行うことができる。また、それらはネットワーク利用を最適化することができる。
本発明の実施形態は、既存のＨＴＴＰ／２機能との互換性をもつ。これらの機能は、本発明の実現実施形態のために有利に用いることができる。
ネットワークの性能は、一般的には増加する。
それに対応して、本発明は、また、クライアント装置に対してメディアデータをストリーミングするためのサーバ装置に関係し、サーバ装置は、
・クライアント装置から第１のメディアデータに関連する要求を受信するように構成された受信器と、
・要求されることなくクライアント装置に対して送信される第２のメディアデータを識別するように構成された制御部と、
・前記要求に応答して、前記第１のメディアデータに関連する情報を前記クライアント装置に対して送信し、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージを準備するように構成された送信器と
を備え、
前記制御部は、クライアント装置に対する第２の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるようにさらに構成される。
本発明は、また、サーバ装置によってストリーミングされたメディアデータへのアクセスのためのクライアント装置に関係し、前記装置は、
・サーバ装置に対して第１のメディアデータに関連する要求を送信するように構成された送信器と、
・前記要求に応答して、前記サーバ装置から前記第１のメディアデータに関連する情報を受信するように構成された受信器と
を備え、
クライアント装置は、クライアント装置によって要求されることなくサーバ装置によって送信される第２のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるように構成される。
サーバおよびクライアント装置は、上記の対応する方法と同じ利点を有する。
方法および装置のオプション機能は、従属請求項において定義される。それらのいくつかは、方法に関して以下に説明される。しかしながら、それらは、また、対応する装置に対して適応することができる。
明示的なアプローチに関して以下に参照された、いくつかの実施形態において、サーバの観点からの方法は、
サーバ装置によってプッシュポリシーを決定するステップと、
クライアント装置とプッシュポリシーを共有するために決定されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置からクライアント装置に対して送信するステップと
をさらに備える。
それに対応して、クライアント側において、前記方法は、共有されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置から受信するステップをさらに備えてもよい。
以下のいくつかの例に記述されるように、共有されたプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
具体的な実施形態において、記述ファイルは、複数のメディアデータ属性レベルを用いてメディアデータを記述し、様々な共有されるプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義される。
他の例において、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたＨＴＴＰフレームのヘッダ内に埋め込まれる。
具体的な機能によれば、前記方法は、サーバ装置において、クライアント装置からＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を受信し、それに応じて、クライアント装置によって要求された他のメディアデータから非要求メディアデータを決定する前に共有されるプッシュポリシーを更新するステップをさらに備えてもよい。それに対応して、前記方法は、クライアント装置において、ＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を、サーバ装置に対して送信するステップをさらに備えてもよい。
複合型アプローチによれば、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第１のプッシュポリシー部および第２のプッシュポリシー部によって定義され、第１のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備え、第２のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるＨＴＴＰフレームのヘッダ内に埋め込まれる。
例えば、第２のプッシュポリシー部は、第１のプッシュポリシー部内に定義された１つ以上の関連変数に対する１つ以上の値を備えてもよい。
また、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第２のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第１のプッシュポリシー部を形成する。
他の実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたウェブページ内に埋め込まれたＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含む。
さらに他の実施形態において、前記方法は、構造化ドキュメント（上記の記述ファイルまたは以下の例に導入されるＨＴＭＬページなど）に基づいて第２の非要求メディアデータを決定するステップをさらに備え、構造化ドキュメントは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、
プッシュポリシー情報は、第２の非要求メディアデータを識別する構造化ドキュメントのツリー表現上で評価される、ＸＰａｔｈ式を含む。
前記プッシュポリシー情報の構文に関して、実施形態は、プッシュポリシー情報が記述ファイル内に識別された第２の非要求メディアデータの量を定義する第１のプッシュ属性を含む、ということを提供し、
前記記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
具体的な機能によれば、第１のプッシュ属性は、記述ファイル内の要求された第１のメディアデータに相対する第２の非要求メディアデータを識別する。これは、以下に記載されるようなオペレータを用いて行われてもよい。
変形において、第１のプッシュ属性は、記述ファイル内部の具体的なメディアデータの識別子である。
具体的な機能によれば、記述ファイル内の記述情報は、メディアデータが属する期間を定義する期間属性と、メディアデータのメディアタイプを定義するアダプテーション属性と、メディアデータの符号化バージョン（例えば、ビットレート、フレームレート、フレーム解像度、タイミング情報、など）を定義するリプレゼンテーション属性と、定義するセグメント属性との中の少なくとも１つのメディアデータ属性にしたがってメディアデータを記述し、
前記プッシュポリシー情報は、第２の非要求メディアデータを識別するために、メディアデータ属性（単数または複数）上の制約を定義する少なくとも第２のプッシュ属性を含む。
これは、記述ファイルを通じて非常に選択的なプッシュポリシーを有することを可能にする。
特に、プッシュ属性（単数または複数）は、記述ファイル内部の第１のメディアデータの対応するメディアデータ属性（単数または複数）に相対する第２の非要求メディアデータのメディアデータ属性（単数または複数）を定義してもよい。
または、プッシュ属性（単数または複数）は、第２の非要求のメディアデータが検索されなければならない記述ファイル内のノードを識別してもよい。
いくつかの実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに１つのプライオリティ属性があり、第２のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。これは、プッシュデータの送信の順序を定義するためである。
実施形態において、共有されるプッシュポリシーは、要求された第１のメディアデータから第２のメディアデータを識別する。
暗示的アプローチに関して以下に参照された実施形態において、共有のプッシュポリシーは、サーバ装置およびクライアント装置の両方において同じ第２のメディアデータを決定するアルゴリズムを用いて実施され、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第１のメディアデータから同じ第２のメディアデータを決定することを可能にする。
暗示的アプローチおよび明示的アプローチの双方に適応した、いくつかの実施形態において、識別された第２のメディアデータが、各々がアナウンスメッセージを要求する複数のメディアセグメントを備えるならば、前記方法は、クライアント装置に対して送信される単一のアナウンスメッセージに、対応する複数のアナウンスメッセージをマージするステップをさらに備えてもよい。これは、より少量のアナウンスメッセージが送信されるので、帯域幅の消費量を低減するためである。
共有されたプッシュポリシーおよびクライアント装置によるプッシュの結果として生ずる予期を実際に活用するために、前記方法は、サーバ装置が対応する準備したアナウンスメッセージを送信しないように、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、クライアント装置から受信するステップをさらに備えてもよい。
それに対応して、クライアントにおいて、前記方法は、第２の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、サーバ装置に対して送信するステップをさらに備えてもよい。
本発明の実施形態において、第２の非要求メディアデータは、サーバ装置によって準備され（および多分受信され）、少なくとも１つのアナウンスメッセージから独立してクライアント装置によって決定され、要求されることなくサーバ装置がクライアント装置に対して送信する予定である第２の非要求メディアデータを識別する。ここで「独立して（ｉｎｄｅｐｅｎｄｅｎｔｌｙ）」は、このような非要請データの今後の送信のクライアント装置に通知する専用のこのようなアナウンスメッセージ（すなわち、ＰＵＳＨ＿ＰＲＯＭＩＳＥ）を認識することなく、クライアント装置が第２の非要請データの決定を行うことができる、ということを意味する。
本発明の他の実施形態において、同じ共有されたプッシュポリシーは、それぞれの第１のメディアデータに関連する複数の要求からそれぞれの非要求メディアデータを決定するために用いられる。経時的に同じプッシュポリシーと連続的な要求とを用いることによって、クライアントは、サーバによる無用データの送信をさらに一層効率的に予期しやすいポジションにあり、それにより、それらの送信および対応するアナウンスメッセージの送信を効率的にキャンセルしやすいポジションにある。
サーバからクライアントに対するプッシュデータの送信の順序の通知に関して、サーバ装置によってクライアント装置に対してメディアデータをストリーミングする方法は、
・クライアント装置から第１のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第２のメディアデータを識別するステップと、
・前記要求に応答して、前記第１のメディアデータに関連する情報と前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージとを前記クライアント装置に送信するステップと
を備えてもよく、
前記方法は、
・サーバ装置によって第２のメディアデータ（これは、共有されたプッシュポリシーの一部またはすべてを形成する）の送信の順序を定義するステップと、
・送信の順序に関する情報であってクライアント装置がサーバによって定義された送信の順序を決定することを可能にする前記情報を、前記アナウンスメッセージとともに送信するステップと
をさらに備える。
例えば、前記第２のメディアの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
前記プライオリティ値は、ＨＴＴＰ／２プロトコルにしたがって定義されてもよい。実施形態によれば、少なくとも１つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第２のメディアデータをクライアント装置に対して送信するステップと、
・前記第２のメディアデータに応答して、クライアント装置から少なくとも１つの制御フローメッセージを受信するステップと、
・受信された前記少なくとも１つの制御フローメッセージに基づいて、利用可能な帯域幅を推定するステップと
をさらに備える。
例えば、サーバ装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第２のメディアデータを送信する。
前記方法は、前記帯域幅推定に基づいて、第２のメディアデータの送信の更新された順序をサーバ装置によって定義するステップをさらに備えてもよい。
実施形態によれば、クライアント装置からの前記要求は、前記第１のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第１のメディアデータに関係する記述情報を含み、方法は、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第１のメディアデータは、ビデオセグメントである。
ストリーミングは、ＤＡＳＨ規格にしたがって実行されてもよい。
例えば、前記方法は、
・クライアント装置から順序更新要求を受信するステップと
・前記順序更新要求に基づいて、第２のメディアデータの送信の新たな順序を定義し、第２のメディアデータの送信の前記新たな順序に関する情報を更新するステップと、・送信の順序に関連する前記更新通知にしたがってクライアントに対して前記第２のメディアデータを送信するステップと
をさらに備える。
前記方法は、クライアント装置に対して順序更新確認メッセージを送信するステップをさらに備えてもよい。
例えば、前記更新された順序は、前記順序更新要求の受信時刻にクライアント装置に対する送信が始まっていない、第２のメディアデータのために定義される。
例えば、前記順序更新要求は、少なくとも第２のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第２のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第１のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第２のメディアデータの一部のためのおよび少なくとも前記第１のメディアデータの一部に関連するプライオリティ値は、それに応じて更新される。
例えば、前記第１のメディアおよび第２のメディアは、時間的関係、空間的関係、および品質関係の少なくとも１つにしたがって関連付けられる。
実施形態によれば、
・前記第２のメディアデータは、第１のメディアデータの品質を強化するためのエンハンスメントデータを備え、
・プライオリティ値が前記エンハンスメント層のメディアデータのために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第１のメディアデータおよび第２のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第１のメディアデータのビデオコンテンツに関連する情報に基づく。
例えば、第１のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
例えば、前記送信の順序は、少なくとも第１のメディアデータと第２のメディアデータとの間の復号化関連性に基づく。
例えば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。例えば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
例えば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。例えば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをクライアント装置から受信するステップと、・第２のメディアデータの更新される送信の順序を、前記制御メッセージに基づいて、サーバによって定義するステップと、
・前記更新された送信の順序にしたがってクライアントに対して前記第２のメディアデータを送信するステップと
をさらに備えてもよい。
前記方法は、順序更新確認メッセージをクライアント装置に対して送信するステップをさらに備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアントによって再生されるそれらのメディアデータを保存する。
例えば、サーバ装置は、送信された第１の要求メディアデータの記録を保持し、第２のメディアデータの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で送信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で送信される。
クライアントの観点から、サーバ装置によってストリーミングされたメディアデータをクライアント装置によってアクセスする方法は、
・第１のメディアデータに関連する要求をサーバ装置に対して送信するステップと、・前記要求に応答して、前記第１のメディアデータに関連する情報と、要求されていなくともクライアント装置に対して送信される第２のメディアそれぞれ識別する少なくとも１つのアナウンスメッセージとを、前記サーバ装置から受信するステップと
を備えてもよく、
前記方法は、前記アナウンスメッセージとともに第２のメディアデータの送信の順序に関連する情報を受信するステップをさらに備え、前記情報（すなわち共有されたプッシュポリシー）は、サーバによって定義された第２のメディアデータの送信の順序を決定することをクライアント装置が可能にする。
前記方法は、サーバ装置によって定義された第２のメディアデータの送信の順序がクライアント装置の端部におけるストリーミング制約を満たすか否かをクライアント装置によって判定し、前記制約が満たされなければ、順序更新要求をサーバ装置に対して送信するステップをさらに備えてもよい。
例えば、前記第２のメディアデータの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
例えば、前記プライオリティ値は、ＨＴＴＰ／２プロトコルにしたがって定義される。
実施形態によれば、少なくとも１つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、前記方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第２のメディアデータをサーバ装置から受信するステップと、
・前記第２のメディアデータに応答して、少なくとも１つの制御フローメッセージを前記サーバ装置に対して送信し、それによって、送信された前記少なくとも１つの制御フローメッセージに基づいてサーバ装置が利用可能な帯域幅を推定することを可能にするステップと
をさらに備える。
例えば、クライアント装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第２のメディアデータを受信する。
例えば、第２のメディアデータの更新される送信の順序は、前記帯域幅推定に基づいて、サーバ装置によって定義される。
例えば、クライアント装置からの前記要求は、前記第１のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第１のメディアデータに関係する記述情報を含み、前記方法は、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第１のメディアデータは、ビデオセグメントである。
例えば、前記ストリーミングは、ＤＡＳＨ規格にしたがって実行される。
方法は、サーバ装置によって定義された第２のメディアデータの新たな送信の順序に関連する更新情報にしたがってサーバ装置から前記第２のメディアデータを受信するステップをさらに備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップをさらに備えてもよい。
実施形態によれば、前記更新された順序は、前記順序更新要求の受信時刻に送信が始まっていない、第２のメディアデータのためにサーバ装置によって定義される。
実施形態によれば、前記順序更新要求は、少なくとも第２のメディアデータの一部のための順序値を備える。
実施形態によれば、前記第２のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第１のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第２のメディアデータの一部のための且つ少なくとも前記第１のメディアデータの一部に関連付けられたプライオリティ値は、それに応じて更新される。
例えば、前記第１のメディアおよび第２のメディアデータは、時間的関係、空間的関係、および品質関係の少なくとも１つにしたがって関連づけられる。
実施形態によれば、
・前記第２のメディアデータは、第１のメディアデータの品質の強化するためのエンハンスメントデータを備え、
・プライオリティ値がエンハンスメント層の第１のメディアデータの少なくとも一部のために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第１のメディアデータおよび第２のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第１のメディアデータのビデオコンテンツに関連する情報に基づく。
実施形態によれば、第１のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
実施形態によれば、前記送信の順序は、少なくとも第１のメディアデータと第２のメディアデータとの間の復号化関連性に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
実施形態によれば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをサーバ装置に送信するステップと、
・前記制御メッセージに基づいて、サーバ装置によって、定義された更新された送信の順序にしたがってサーバ装置から前記第２のメディアデータを受信するステップとを備えてもよい。
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップを備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアント装置によって再生されるそれらのメディアデータを保存する。
実施形態によれば、サーバ装置は、送信された第１の要求メディアデータの記録を保持し、現在再生されているメディアの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で受信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で受信される。
さらに送信の順序を参照して、プロキシサーバによる、クライアント装置とサーバ装置との間のデータ交換を管理する方法は、
・送信の順序の通知に関して以上に定義されるような方法を実行するサーバから、クライアント装置に対して再送信されるメディアデータを受信するステップと
・メディアデータの送信の順序に基づいて、メディアデータのための再送信プライオリティを決定するステップと、
・決定された前記送信プライオリティに基づいて、クライアント装置に対する受信されたメディアデータの再送信を実行するステップと
を備えてもよい。
前記方法は、決定された前記再送信プライオリティに基づいて、受信された前記メディアデータを保存するステップをさらに備えてもよい。
前記方法は、
・第２の態様による方法を実施するクライアント装置から順序更新要求を受信するステップと、
・前記要求が再送信されるメディアデータに関連する場合、前記順序更新要求にしたがって前記再送信プライオリティを更新するステップと、
・更新された再送信プライオリティにしたがってメディアデータの再送信を実行するステップと
をさらに備えてもよい。
前記方法は、
・メディアデータのための、第１のサーバ装置に対する要求を、第１のクライアント装置から受信するステップであって、前記メディアデータは、第２のサーバ装置から第２のクライアント装置に対する再送信のためにプロキシサーバによって保存されるステップと、・第１のサーバ装置および第２のサーバ装置によって前記メディアデータにそれぞれ関連付けられたプライオリティ値を決定するステップと、
・第１のクライアント装置および第２のクライアント装置に対するそれぞれのストリーミング制約にしたがって前記プライオリティ値を更新するステップと、
・前記更新されたプライオリティ値にしたがって、前記第１のクライアント装置および第２のクライアント装置に対して前記メディアデータを再送信するステップと
をさらに備えてもよく、
前記第１のサーバ装置および第２のサーバ装置は、第１の態様による方法を実施し、前記第１のクライアント装置および第２のクライアント装置は、第２の態様による方法を実施する。
前記方法は、更新されたプライオリティ値に関連する更新通知を第１のサーバ装置および第２のサーバ装置に対して送信するステップをさらに備えてもよい。
本発明の別の態様によれば、サーバ装置とクライアント装置との間でデータをストリーミングする方法であって、
・サーバ装置によって第１の態様による方法を実行するステップと、
・クライアント装置によって第２の態様による方法を実行するステップと
を備える方法が提供される。
本発明のさらに別の態様によれば、プログラミング可能な装置のコンピュータ手段にロードされ実行されたときに、以上に定義されるような方法を実施するための命令を備えるコンピュータプログラムおよびコンピュータプログラムプロダクトが提供される。本発明のさらに別の態様によれば、第１の態様による方法を実施するように構成されたサーバ装置が提供される。
本発明のさらに別の態様によれば、第２の態様による方法を実施するように構成されたクライアント装置が提供される。
サーバからクライアント装置に対するメディアデータの適応型ストリーミングにための解決手段は、関係のあるクライアント装置の機能に対して、およびサーバとクライアント装置との間の接続を提供するネットワークの特性に対して、クライアント装置に送信されるデータのタイプおよび量を特に適応するために提案されてきた。
これに関連して、ＤＡＳＨ（動的適応型ＨＴＴＰストリーミング）規格などのいくつかの解決手段は、配信されるリソース（またはコンテンツ）の複数のバージョンを保存し、且つこれらのバージョンに対してリソースおよびそれぞれのポインタ（例えばＵＲＬ）を表現する様々なバージョンの記述を含む記述ファイルを、リソースを要求するクライアント装置に対して送信することを提案する。
そして、記述ファイルに基づいて、クライアント装置は、対応するポインタを用いて、このバージョンのニーズおよび要求にベストマッチするリソースのバージョンを選択することができる。
この解決手段は、記述ファイルがメディアデータを含まない（但しメディアデータに対するポインタのみ含む）光である、という点で有利である。その利用のために関連するバージョンをクライアントに選択させることによって、クライアント装置に適さないメディアデータの交換を回避する。さらに、それはＨＴＴＰに基づく現在のウェブアーキテクチャに適合し、既に配備されたキャッシュメカニズムを利用することができる。
その代わりに、しかしながら、メディアデータがクライアント装置において受信されて、その後、復号され表示され得る前に、この解決手段は、クライアント装置とサーバとの間のいくつかの交換（またはラウンドトリップ）を必要とし、それは開始遅延をもたらす。実施形態において、本発明は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを提供する方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、サーバによって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するステップと、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、・クライアント装置に対して記述ファイルを送信するステップと、
・クライアント装置に対して選択されたデータをプッシュするステップと
を備える。
適切な方式において選択されたデータをプッシュ（すなわち、クライアント装置によって請求されないが、以下にさらに説明するようにサーバによって選択されたデータの送信）することによって、１つまたは複数のラウンドトリップを回避することができ、それにより、メディアデータの復号化および表示をさらに高速に開始することができる。メディアアイテムは、例えば、ビデオ、または例えばオーディオトラックなどのオーディオアイテムであってもよい。
上述のデータのセットは、時間セグメントを表現するバージョンを含むが、以下に説明されるようにイニシャライゼーションデータなどの他のデータを含んでもまたよい、ということに注目されたい。
まさに述べた如く、選択されたデータは、クライアント装置の復号器のためのイニシャライゼーションデータを含んでもよい。したがって、復号器は、クライアント装置がイニシャライゼーションデータを特に、要求する必要なしに、イニシャライズでき、従ってより高速にイニシャライズできる。
上述のように、選択されたデータは、また、時間セグメントを表現する前記バージョンの１つの少なくとも一部を含んでもよい。
データを選択するステップは、プッシュされるデータ（例えばビデオデータ）の量を推定するステップを含んでもよく、それは、どのデータが選択されるのかを決定するときに用いられてもよい。量は、記述ファイル内に定義されたバッファ時間に基づいて、および／または、サーバによって決定された帯域幅推定に基づいて推定されてもよい。
データを選択するステップは、要求に含まれる少なくとも１つのプレファレンスに基づいて、および／またはサーバとクライアント装置との間の従来の交換から導き出される使用データに基づいて、および／またはサーバによる記述ファイルの解析に基づいて、および／またはサーバ内に保存され、記述ファイルに関連するテーブルに基づいて、実行されてもよい。
可能な実施形態によれば、選択されたデータをプッシュするステップに関連するとともに、そのステップに先立って、プッシュプロミスを送信するステップを備えてもよい。したがって、これらのデータを実際に受信する前に、プッシュされるデータがクライアント装置に通知されてもよい。
プッシュプロミスを送信するステップは、記述ファイルを送信するステップの前に実行されてもよく、それは、初期のステージにおいてクライアント装置に通知することを可能にする。
プッシュプロミスは、例えば選択されたデータの識別を含む。
提案された実施形態によれば、サーバは、選択されたデータに関連する信頼水準を決定し、プッシュプロミスは、決定された信頼水準を含む。
以下に述べる詳細説明において説明する可能なインプランテーションによれば、サーバは、選択されたデータを形成するデータのブロックの階層的リプレゼンテーションを保存してもよい。
このようなケースにおいて、
・データのブロックをプッシュしないための命令をクライアント装置から受信するステップと、
・前記データのブロック、および階層的リプレゼンテーションにおける前記データのブロックに連結されたデータのブロックのプッシングをキャンセルするステップと
が備えられていてもよい。
提案された方法は、選択されたデータに関連した信頼度を決定するステップを含んでもよく、そして、
・決定された信頼度が所定の閾値未満であれば、選択されたデータをプッシュするステップは、クライアント装置の復号器のイニシャライゼーションデータのみをプッシュするステップを含み、
・決定された信頼度が所定の閾値を上回れば、選択されたデータをプッシュするステップは、クライアント装置の復号器のためのイニシャライゼーションデータと、時間セグメントを表現する前記バージョンの１つの少なくとも一部をプッシュするステップを含む。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを受信するための方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、クライアント装置によって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・記述ファイルをサーバから受信するステップであって、前記記述ファイルはデータのセットに対するポインタを含むステップと、
・サーバから、非要請データを受信するステップであって、前記非要請データは前記データのセットに属するステップと
を有する。
上述のように、非要請データは、クライアント装置の復号器のためのイニシャライゼーションデータ（その場合には前記非要請データにより復号器をイニシャライズするステップが提供されてもよい）、および／または、少なくとも時間セグメントを表現する前記バージョンの１つの一部（その場合には非要請データの少なくとも一部を復号するステップが提供されてもよい）を含んでもよい。
前記要求は、プッシュされるメディアデータを決定する際にサーバを支援することができる、クライアント装置における復号化を定義する少なくとも１つのプレファレンスを含んでもよい。
前記要求は、また、クライアント装置がプッシュされたデータを受け入れるというインディケータを含んでもよく、それに基づいて、サーバは、データをプッシュすることを効率的に決定することができる。
上記したように、非要請データを受信するステップに関連するとともに、そのステップに先立って、プッシュプロミスを受信するステップを備えてもよい。このプッシュプロミスを受信するステップは、記述ファイルを受信するステップに先立って行われてもよい。
プッシュプロミスは、非要請データおよび／または非要請データに関連付けられた信頼度の識別を含んでもよい。
クライアント装置において、以下のステップ、
・プッシュプロミス内に含まれるデータに基づいてプッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが有していてもよい。
以下のステップ、
・非要請データに関連付けられ且つプッシュプロミス内に含まれた信頼度に基づいて、プッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが用いられてもよい。
受信に際して前記非要請データをバッファするステップは、これらのデータを復号する前に用いられてもよい。
プッシュされたデータがイニシャライゼーションデータおよび／または初期のメディアデータに対してのみ対応するように意図されるように以下のステップ、
・記述ファイルに、およびプッシュプロミス内に含まれるデータに基づいて要求される（すなわち、プッシュされるようには計画されない）データ（例えばビデオデータ）を決定するステップと、
・決定されたデータに対する要求を、サーバに対して送信するステップと
が実施されてもよい。
本発明の実施形態は、また、クライアント装置に対して、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータをストリーミングする方法を提案し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、前記方法は、
・前記クライアント装置が、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・サーバが、クライアント装置から要求を受信するステップと、
・サーバが、記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・サーバが、クライアント装置に対して記述ファイルを送信するステップと、
・サーバが、クライアント装置に対して選択されたデータをプッシュするステップと、・クライアント装置が、サーバから記述ファイルを受信するステップと、
・クライアント装置が、サーバから選択されたデータを受信するステップと
を有する。
本発明の実施形態は、また、サーバからメディアアイテム（例えばビデオ）を表現するメディアデータを提供するための装置を提供するのであって、サーバは、メディアアイテムを表現するデータを保存し、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するように構成された受信器と、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、
・クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、・クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと
を有する。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを受信するための装置を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールと、
・サーバから記述ファイルを受信するように構成されたモジュールであって、前記記述ファイルがデータのセットに対するポインタを含むモジュールと、
・サーバから非要請データを受信するように構成されたモジュールであって、前記非要請データは前記データのセットに属するモジュールと
を有する。
最後に、本発明の実施形態は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータをクライアント装置に対してストリーミングするためのサーバおよびクライアント装置を有するシステムを提供し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、
・前記クライアント装置は、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールを有し、
・前記サーバは、クライアント装置から要求を受信するように構成されたモジュールと、記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと、を有し、
・クライアント装置は、サーバから記述ファイルを受信するように構成されたモジュールと、サーバから選択されたデータを受信するように構成されたモジュールと、を有する、を前記システムは有する。
メディアデータを提供する方法、およびメディアデータを受信する方法のために以上に提案されたオプション機能は、また、メディアデータをストリーミングする方法に対して、および前述の各種装置およびシステムに対して適用する。
特許請求の範囲の単語「備える（ｃｏｍｐｒｉｓｉｎｇ）」は、他の要素またはステップを除外せず、また、不定冠詞「ａ」または「ａｎ」は、複数のものを除外しない。単一のプロセッサまたは他のユニットは、特許請求の範囲内の列挙された、いくつかのアイテムの機能を実現してもよい。個別の機能が個別の従属請求項内に相互に列挙されるという単なる事実は、これらの機能の組み合わせを有利に用いることができない、ということを示すものではない。特許請求の範囲内の任意の参照符号も、また、本発明の範囲を制限するものとして解釈するべきでない。

Claims (22)

  1. サーバによるクライアントへのメディアデータの提供方法であって、
    前記サーバにおいて、前記サーバから前記クライアントへメディアセグメントがどのようにプッシュされるかを示すプッシュ戦略を有する第１情報を前記クライアントから受信する受信工程と、
    前記サーバにおいて、前記受信工程により前記第１情報を前記クライアントから受信したことに応じて、前記第１情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアセグメントを識別する識別工程と、
    前記サーバにおいて、前記クライアントから前記第１情報を受信したことに応じて、前記クライアントに第２情報を通知する通知工程と、
    前記サーバにおいて、前記クライアントから、前記１つ以上のメディアセグメントのうち少なくとも１つのメディアセグメントに関するキャンセルリクエストを受信したことに応じて、前記識別工程において識別された前記少なくとも１つのメディアセグメントの前記クライアントへのプッシュをキャンセルするキャンセル工程と、
    を有することを特徴とする提供方法。
  2. 前記通知工程において通知される前記第２情報は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項１記載の提供方法。
  3. 前記通知工程において通知される前記第２情報は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１記載の提供方法。
  4. 前記通知工程において通知される前記第２情報は、ウェブソケットによって定義されたメッセージであることを特徴とする請求項１記載の提供方法。
  5. 前記識別工程は、前記クライアントからの所定のリクエストを受信したことに応じて実行されることを特徴とする請求項１乃至４の何れか一項に記載の提供方法。
  6. 前記所定のリクエストは、ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）を要求するリクエストであることを特徴とする請求項５記載の提供方法。
  7. 前記所定のリクエストは、所定の期間のメディアデータに対応するメディアセグメントを要求するリクエストであることを特徴とする請求項５記載の提供方法。
  8. 前記識別工程によって識別された１つ以上のメディアセグメントは、前記通知工程において前記クライアントに通知されることを特徴とする請求項１乃至７の何れか一項に記載の提供方法。
  9. 前記キャンセルリクエストは、ＨＴＴＰ／２によって定義されたＲＳＴ＿ＳＴＲＥＡＭフレームであることを特徴とする請求項１乃至８の何れか一項に記載の提供方法。
  10. 前記キャンセルリクエストは、前記識別工程において識別されたメディアセグメントをプッシュするために確立されたストリームの識別情報を含むことを特徴とする請求項１乃至９の何れか一項に記載の提供方法。
  11. クライアントによるサーバからのメディアデータの受信方法であって、
    前記クライアントにおいて、前記サーバから前記クライアントへプッシュすべきデータを決定するための情報であって、前記サーバから前記クライアントへメディアセグメントがどのようにプッシュされるかを示すプッシュ戦略を有する第１情報を、前記サーバに送信する第１送信工程と、
    前記クライアントにおいて、前記サーバが前記第１情報を受信したことに応じて前記サーバが送信する第２情報を受信する受信工程と、
    前記クライアントにおいて、前記サーバから前記クライアントへのプッシュをキャンセルするかどうかを判定する判定工程と、
    前記判定工程における判定結果に従って、前記第１情報に基づいて識別される１つ以上のメディアセグメントのうち少なくとも１つのメディアセグメントのプッシュのキャンセルを要求するキャンセルリクエストを、前記クライアントから前記サーバへ送信する第２送信工程と、
    を有することを特徴とする受信方法。
  12. 前記受信工程により受信される前記第２情報は、確認応答メッセージであることを特徴とする請求項１１記載の受信方法。
  13. 前記受信工程により受信される前記第２情報は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１１記載の受信方法。
  14. １つ以上のメディアセグメントが、前記受信工程により受信される前記第２情報によって、通知されることを特徴とする請求項１１記載の受信方法。
  15. 前記キャンセルリクエストは、ＨＴＴＰ／２によって定義されたＲＳＴ＿ＳＴＲＥＡＭフレームであることを特徴とする請求項１１乃至１４の何れか一項に記載の受信方法。
  16. クライアントへのメディアデータを提供するサーバであって、
    前記サーバから前記クライアントへメディアセグメントがどのようにプッシュされるかを示すプッシュ戦略を有する第１情報を前記クライアントから受信する受信手段と、
    前記受信手段により前記第１情報を前記クライアントから受信したことに応じて、前記第１情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアセグメントを識別する識別手段と、
    前記クライアントから前記第１情報を受信したことに応じて、前記クライアントに第２情報を通知する通知手段と、
    前記クライアントから、前記１つ以上のメディアセグメントのうち少なくとも１つのメディアセグメントに関するキャンセルリクエストを受信したこと応じて、前記識別手段により識別された前記少なくとも１つのメディアセグメントの前記クライアントへのプッシュをキャンセルするキャンセル手段と、
    を有することを特徴とするサーバ。
  17. 前記通知手段により通知される前記第２情報は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項１６記載のサーバ。
  18. 前記通知手段により通知される前記第２情報は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１６記載のサーバ。
  19. サーバからメディアデータを受信するクライアントであって、
    前記サーバから前記クライアントへプッシュすべきデータを決定するための情報であって、前記サーバから前記クライアントへメディアセグメントがどのようにプッシュされるかを示すプッシュ戦略を有する第１情報を、前記サーバに送信する第１送信手段と、
    前記サーバが前記第１情報を受信したことに応じて前記サーバが送信する第２情報を受信する受信手段と、
    前記サーバから前記クライアントへのプッシュをキャンセルするかどうかを判定する判定手段と、
    前記判定手段による判定結果に従って、前記第１情報に基づいて識別される１つ以上のメディアセグメントのうち少なくとも１つのメディアセグメントのプッシュのキャンセルを要求するキャンセルリクエストを、前記サーバへ送信する第２送信手段と、
    を有することを特徴とするクライアント。
  20. 前記受信手段により受信される前記第２情報は、確認応答メッセージであることを特徴とする請求項１９記載のクライアント。
  21. 前記受信手段により受信される前記第２情報は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１９記載のクライアント。
  22. コンピュータに、請求項１６乃至２１の何れか一項に記載の各手段を実行させるためのプログラム。
JP2019223944A 2013-07-12 2019-12-11 メディアデータの提供方法、メディアデータの受信方法、及びプログラム Active JP6918910B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
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
GB1312561.2 2013-07-12
GB1312561.2A GB2516116B (en) 2013-07-12 2013-07-12 Adaptive data streaming method with push messages control
GB1410540.7A GB2517060B (en) 2013-07-12 2014-06-12 Adaptive data streaming method with push messages control
GB1410540.7 2014-06-12
JP2018192305A JP6632682B2 (ja) 2013-07-12 2018-10-11 メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2018192305A Division JP6632682B2 (ja) 2013-07-12 2018-10-11 メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム

Publications (2)

Publication Number Publication Date
JP2020047303A JP2020047303A (ja) 2020-03-26
JP6918910B2 true JP6918910B2 (ja) 2021-08-11

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 Before (2)

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 メディアデータの提供装置、提供方法、制御装置、制御方法、及び、プログラム

Country Status (7)

Country Link
US (3) US10104190B2 (ja)
EP (1) EP3020208B1 (ja)
JP (3) JP6419173B2 (ja)
KR (3) KR102264477B1 (ja)
CN (2) CN109842613B (ja)
RU (3) RU2625328C1 (ja)
WO (1) WO2015004276A2 (ja)

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9077784B2 (en) * 2009-02-06 2015-07-07 Empire Technology Development Llc Media file synchronization
MY182338A (en) 2013-07-19 2021-01-20 Sony Corp Information processing device and method
US10721530B2 (en) 2013-07-29 2020-07-21 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
US10397666B2 (en) 2014-06-27 2019-08-27 Koninklijke Kpn N.V. Determining a region of interest on the basis of a HEVC-tiled video stream
US10694192B2 (en) 2014-06-27 2020-06-23 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
WO2016105090A1 (ko) * 2014-12-22 2016-06-30 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
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
CN106664299B (zh) * 2015-02-15 2020-01-17 华为技术有限公司 基于超文本传输协议媒体流的媒体呈现导览方法和相关装置
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
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
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
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 キヤノン株式会社 通信装置、通信方法、及び通信システム
JP6675475B2 (ja) * 2015-08-20 2020-04-01 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ メディア・ストリームに基づくタイルド・ビデオの形成
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
US10158682B2 (en) 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
US10152080B2 (en) * 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
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 中兴通讯股份有限公司 自适应流媒体传输方法及装置
US10735485B2 (en) 2015-12-04 2020-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Technique for adaptive streaming of temporally scaling media segment levels
CN112738201B (zh) * 2016-01-28 2024-08-02 联发科技股份有限公司 一种消息交互的方法和提供媒体服务的系统
US10230812B1 (en) * 2016-01-29 2019-03-12 Amazon Technologies, Inc. Dynamic allocation of subtitle packaging
CN108476332B (zh) 2016-02-01 2022-02-08 松下电器（美国）知识产权公司 客户端、服务器、接收方法及发送方法
US10820025B2 (en) * 2016-02-03 2020-10-27 Mediatek, Inc. Method and system of push-template and URL list for dash on full-duplex protocols
CN107040505B (zh) * 2016-02-04 2021-01-26 中兴通讯股份有限公司 媒体数据传输方法及装置
WO2017138387A1 (ja) * 2016-02-12 2017-08-17 ソニー株式会社 情報処理装置および情報処理方法
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
US10382313B2 (en) 2017-02-16 2019-08-13 International Business Machines Corporation Test building for testing server operation
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
WO2018151847A1 (en) * 2017-02-16 2018-08-23 Tenta, Llc 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
EP3635959B1 (en) 2017-06-02 2021-08-04 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
US11201901B2 (en) * 2018-04-30 2021-12-14 Dolby International Ab Methods and systems for streaming media data over a content delivery network
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 百度在线网络技术（北京）有限公司 一种信息推送方法、服务器、终端及电子设备
KR102654182B1 (ko) * 2019-07-03 2024-04-02 텔레폰악티에볼라겟엘엠에릭슨(펍) 네트워크 트래픽 관리의 개선을 위한 패킷 확인 응답 기술
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
DE112021001748T5 (de) * 2020-03-20 2023-03-30 Harmonic, Inc. Optimieren der tatsächlichen nutzung eines kabelnetzes
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)

* Cited by examiner, † Cited by third party
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
JP5210886B2 (ja) * 2006-01-09 2013-06-12 トムソン ライセンシング マルチメディア・コンテンツを配信する方法及びシステム
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
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 삼성전자주식회사 적응적인 스트리밍 방법 및 장치
CN102783167B (zh) * 2010-03-05 2015-10-14 三星电子株式会社 基于文件格式生成和再现自适应流的方法和装置
US9497290B2 (en) * 2010-06-14 2016-11-15 Blackberry Limited Media presentation description delta file for HTTP streaming
KR20120010089A (ko) * 2010-07-20 2012-02-02 삼성전자주식회사 Ｈｔｔｐ 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
US8782268B2 (en) * 2010-07-20 2014-07-15 Microsoft Corporation Dynamic composition of media
US9319448B2 (en) * 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes 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
JP5932987B2 (ja) * 2011-06-08 2016-06-08 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化されたコンテンツの位置特定および抽出
WO2013004260A1 (en) 2011-07-07 2013-01-10 Telefonaktiebolaget L M Ericsson (Publ) Network-capacity optimized adaptive http streaming
WO2013019261A1 (en) * 2011-08-01 2013-02-07 Intel Corporation MULTI-HOP SINGLE SIGN-ON (SSO) FOR IDENTITY PROVIDER (IdP) ROAMING/PROXY
US8924580B2 (en) 2011-08-12 2014-12-30 Cisco Technology, Inc. Constant-quality rate-adaptive streaming
JP5908984B2 (ja) 2011-10-21 2016-04-26 フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン 情報資源管理概念
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
JP6023213B2 (ja) * 2011-12-29 2016-11-09 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化されたコンテンツについての制御されたストリーミング
EP3068102B1 (en) * 2011-12-29 2017-11-08 Koninklijke KPN N.V. Network-initiated content streaming control
US8874634B2 (en) 2012-03-01 2014-10-28 Motorola Mobility Llc Managing adaptive streaming of data via a communication connection
WO2014011622A2 (en) 2012-07-09 2014-01-16 Vid Scale, Inc. Power aware video decoding and streaming
JP5962943B2 (ja) 2013-02-04 2016-08-03 ▲ホア▼▲ウェイ▼技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． ストリーミング・メディア・データを送信するための方法および装置
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

Also Published As

Publication number Publication date
CN105532013A (zh) 2016-04-27
KR101909160B1 (ko) 2018-10-18
EP3020208A2 (en) 2016-05-18
KR20190109580A (ko) 2019-09-25
RU2683595C1 (ru) 2019-03-29
KR102264477B1 (ko) 2021-06-15
US10728353B2 (en) 2020-07-28
JP6632682B2 (ja) 2020-01-22
US20200322441A1 (en) 2020-10-08
EP3020208B1 (en) 2022-03-09
JP2016531466A (ja) 2016-10-06
WO2015004276A2 (en) 2015-01-15
RU2625328C1 (ru) 2017-07-13
CN109842613B (zh) 2021-11-19
CN105532013B (zh) 2018-12-28
CN109842613A (zh) 2019-06-04
JP6419173B2 (ja) 2018-11-07
KR102024311B1 (ko) 2019-09-23
JP2020047303A (ja) 2020-03-26
US10104190B2 (en) 2018-10-16
US20160198012A1 (en) 2016-07-07
JP2019033520A (ja) 2019-02-28
KR20160032143A (ko) 2016-03-23
KR20180114964A (ko) 2018-10-19
US20180359328A1 (en) 2018-12-13
RU2659041C1 (ru) 2018-06-27
WO2015004276A3 (en) 2015-03-19
US11375031B2 (en) 2022-06-28

Similar Documents

Publication Publication Date Title
JP6918910B2 (ja) メディアデータの提供方法、メディアデータの受信方法、及びプログラム
JP2016531466A5 (ja)
CN107211022B (zh) 利用服务器装置的改进的客户端驱动资源推送
US11477262B2 (en) Requesting multiple chunks from a network node on the basis of a single request message
US10110507B2 (en) Push-based transmission of resources and correlated network quality estimation
US9769239B2 (en) Systems and methods for user agent signaling request acceleration by transport accelerator
GB2517060A (en) Adaptive data streaming method with push messages control
GB2516112A (en) Methods for providing media data, method for receiving media data and corresponding devices
US20170041422A1 (en) Method and system for retrieving a content manifest in a network
US20160036883A1 (en) Systems and methods for selective transport accelerator operation
GB2575189A (en) Adaptive client-driven push of resources by a server device
GB2551674A (en) Adaptive data streaming method with push messages control

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200928

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20201110

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210330

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210531

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210622

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210721

R151 Written notification of patent or utility model registration

Ref document number: 6918910

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151