JP2018532334A - メディアデータのストリーミングのためのデッドラインシグナリング - Google Patents
メディアデータのストリーミングのためのデッドラインシグナリング Download PDFInfo
- Publication number
- JP2018532334A JP2018532334A JP2018518703A JP2018518703A JP2018532334A JP 2018532334 A JP2018532334 A JP 2018532334A JP 2018518703 A JP2018518703 A JP 2018518703A JP 2018518703 A JP2018518703 A JP 2018518703A JP 2018532334 A JP2018532334 A JP 2018532334A
- Authority
- JP
- Japan
- Prior art keywords
- data
- time
- request
- deadline information
- client device
- 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.)
- Pending
Links
- 230000011664 signaling Effects 0.000 title description 7
- 239000000872 buffer Substances 0.000 claims abstract description 135
- 230000003139 buffering effect Effects 0.000 claims abstract description 4
- 238000000034 method Methods 0.000 claims description 77
- 238000003860 storage Methods 0.000 claims description 35
- 230000003044 adaptive effect Effects 0.000 claims description 6
- 238000012546 transfer Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 43
- 239000012634 fragment Substances 0.000 description 41
- 230000000875 corresponding effect Effects 0.000 description 33
- 241000760358 Enodes Species 0.000 description 30
- 230000006978 adaptation Effects 0.000 description 30
- 238000005538 encapsulation Methods 0.000 description 24
- 238000002360 preparation method Methods 0.000 description 14
- 238000012545 processing Methods 0.000 description 13
- 230000005540 biological transmission Effects 0.000 description 11
- 238000009826 distribution Methods 0.000 description 10
- 230000002123 temporal effect Effects 0.000 description 10
- 230000000750 progressive effect Effects 0.000 description 8
- 238000009877 rendering Methods 0.000 description 7
- 230000014509 gene expression Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000013515 script Methods 0.000 description 3
- 101100412093 Schizosaccharomyces pombe (strain 972 / ATCC 24843) rec16 gene Proteins 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 208000024714 major depressive disease Diseases 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 239000013598 vector Substances 0.000 description 2
- FMYKJLXRRQTBOR-UBFHEZILSA-N (2s)-2-acetamido-4-methyl-n-[4-methyl-1-oxo-1-[[(2s)-1-oxohexan-2-yl]amino]pentan-2-yl]pentanamide Chemical group CCCC[C@@H](C=O)NC(=O)C(CC(C)C)NC(=O)[C@H](CC(C)C)NC(C)=O FMYKJLXRRQTBOR-UBFHEZILSA-N 0.000 description 1
- 101100498930 Mus musculus Degs1 gene Proteins 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 239000002775 capsule Substances 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
Classifications
-
- 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/26208—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 the scheduling operation being performed under constraints
- H04N21/26241—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 the scheduling operation being performed under constraints involving the time of distribution, e.g. the best time of the day for inserting an advertisement or airing a children program
-
- 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
- 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
- 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
-
- 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/64322—IP
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Marketing (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Computer Security & Cryptography (AREA)
Abstract
クライアントデバイスが、リアルタイム制約を有するデータをバッファリングするためのバッファを備えるメモリと、デジタル論理回路機構を備えるハードウェアベースのプロセッサとを含む。プロセッサは、データがダウンロードのために利用可能である時間を判断し、バッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断し、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るように構成されたリアルタイムのアプリケーションを実行するように構成される。このようにして、送付デバイスは、クライアントデバイスのためにバッファアンダーランを防止するために、要求されたデータの配信を優先することができる。
Description
本出願は、その内容全体が参照により本明細書に組み込まれる、2015年10月16日に出願されたPCT出願第PCT/CN2015/092095号の優先権を主張する。
本開示は、メディアデータの搬送に関する。
デジタルメディア能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。
デジタルメディアは、送信に先立って圧縮されてよい。たとえば、ビデオデータは、空間的予測および/または時間的予測を実施し、ビデオシーケンスに固有の冗長性を低減または除去するビデオ圧縮技法を使って圧縮され得る。
メディアデータが符号化された後、メディアデータは送信または記憶のためにパケット化され得る。メディアデータは、国際標準化機構(ISO)ベースメディアファイルフォーマットおよびその拡張などの、様々な規格のいずれかに準拠するメディアファイルへと、アセンブルされ得る。メディアデータはさらに、動的適応ストリーミングオーバーHTTP(DASH)などのストリーミングプロトコルにより、コンピュータベースのネットワークを使って送信され得る。
R. Fielding他、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月
T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月
DASH-IF IOP v3.1、セクション4.3.4
概して、本開示は、メディアデータについてのデッドライン情報をシグナリングするための技法について記載する。つまり、クライアントデバイスは、DASHセグメントなどのメディアファイルが受信されなければならない時間を表すデータをシグナリングし得る。この時間は、クライアントデバイスによる平滑な、連続したプレイアウトを保証するために(たとえば、バッファアンダーランを防止するために)メディアファイルが受信されなければならない時間を表し得る。
一例では、リアルタイム制約を有するデータを取り出す方法が、リアルタイムのアプリケーションを実行するデジタル論理回路機構を備えるハードウェアベースのプロセッサを有するクライアントデバイスによって実施される。方法は、データがダウンロードのために利用可能である時間を判断するステップと、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するステップと、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るステップとを含む。
別の例では、リアルタイム制約を有するデータを取り出すためのクライアントデバイスは、リアルタイム制約を有するデータをバッファリングするためのバッファを備えるメモリと、デジタル論理回路機構を備えるハードウェアベースのプロセッサとを含む。プロセッサは、データがダウンロードのために利用可能である時間を判断し、バッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断し、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るように構成されたリアルタイムのアプリケーションを実行するように構成される。
別の例では、リアルタイム制約を有するデータを取り出すためのクライアントデバイスは、データがダウンロードのために利用可能である時間を判断するための手段と、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するための手段と、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るための手段とを含む。
別の例では、コンピュータ可読記憶媒体(つまり、非一時的コンピュータ可読記憶媒体)は、プロセッサに、データがダウンロードのために利用可能である時間を判断させ、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断させ、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送らせる命令を記憶している。
1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
概して、本開示は、ハイパーテキスト転送プロトコル(HTTP)を使うメディアデータのストリーミング中にデッドライン情報をシグナリングするための技法について記載する。そのようなストリーミング技法は、本明細書ではHTTPストリーミングとも呼ばれる。特に、以下で説明するように、本開示は、クライアントデバイスのストリーミングクライアントが、それぞれのデッドラインまでにセグメントの迅速な配信を保証することを試みるために、ストリーミングアウェアネットワーク要素にデッドライン情報をシグナリングすることができるようにするための技法について記載する。同様に、ストリーミングアウェアネットワーク要素は、これらの技法を、セグメントがそれぞれのデッドラインまでにクライアントデバイスに届くように、クライアントデバイスにセグメントを配信するのに使うことができる。
HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GET、および部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)に関連付けられたペイロードを取り出さずに、URLまたはURNに関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNに関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々のムービーフラグメントを取得できるので、ムービーフラグメントがHTTPストリーミングのために提供されてよい。ムービーフラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在してよい。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにとってアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/もしくはスケーラブル拡張など)、あるいは異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにとってアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含み得る。期間は、MPDにおいて期間要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能性時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間の場合、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含み得る。表現は、オーディオデータまたはビデオデータの、いくつかの代替符号化バージョンのうちの1つであり得る。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定のやり方で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用される場合がある。
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられ得る。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅適応を実施するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合には、グループ0からの1つの表現、または各非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
表現は1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでよく、または表現の各セグメントは、自己初期化するものであってよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照され得る。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
異なるタイプのメディアデータに関して実質的に同時に取り出すために異なる表現を選択することができる。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅適応を実施するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
DASHは、オブジェクトベースのリアルタイムのストリーミング配信を可能にする。基本動作モードにおいて、クライアントは、サーバに対してデータを要求し、プレイアウトをスケジュールする。DASHクライアントは、プレイアウトを最適化し、バッファアンダーランを避けるために、バッファを使う。また、クライアントは、適切なプレイアウトを保証するためにセグメントがクライアントに到着することを保証するために、セグメントについての要求を適切にスケジュールする。基本動作では、全制御およびタイミングがクライアントにかかっている。
ただし、いくつかのシナリオでは、具体的には、サーバおよびネットワーク支援型DASH(SAND)において考慮されるケースでは、サーバおよびネットワークは、配信を主にネットワーク効率ならびにユーザエクスペリエンスの点で最適化するために、クライアントと協力し、クライアントを支援する。さらに、HTTP要求は通常、状態をもたない、時間に関係のない要求としてネットワークにおいて扱われるので、クライアントは、特にネットワークが配信についてのデッドラインを認識している場合、HTTPを介したオブジェクトの配信においてネットワークをサポートすることができる。そのような技術は特に、ネットワークがそのようなデッドラインを配信において利用することができるケースにおいて適している。
このコンテキストにおいて、本開示は、SANDのコンテキストにおける以下のメッセージの追加を提案する。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。
●要求されたオブジェクトについての最大RTT(持続時間)を提供するための状況メッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。
●要求されたオブジェクトについての最大RTT(持続時間)を提供するための状況メッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。
本開示の技法は、いくつかの利点をもたらし得る。たとえば、本開示の技法は、DASHアウェアネットワーク要素(DANE)またはメディアアウェアネットワーク要素(MANE)などのネットワーク要素に、データがクライアントデバイスに配信されるための、クライアントデバイスのタイミング要件の情報を提供することができる。これは、データがクライアントデバイスによって必要とされるときにクライアントデバイスがデータを受信することを保証することができ、このことは、データについてのクライアントデバイスのリアルタイム制約を満足し得る。たとえば、DASHのコンテキストでは、メディアデータは、いくつかの時間において、バッファアンダーフロー(つまり、クライアントデバイスが、すべてのバッファリングされたデータを消費する)を避けることを求められる場合がある。バッファアンダーフローは、バッファアンダーランとも呼ばれ得る。バッファアンダーフローは概して、結果として、追加データの受信を待ち受けることを必要とするものであり、このことが、再生における望ましくない一時停止を引き起こし得る。これらの技法は、バッファアンダーフローを避けることによって、そのような一時停止を避けることができる。
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてよく、または直接通信可能に(介入ネットワークなしで)結合されてよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図1の例では、コンテンツ準備デバイス20は、オーディオソース22とビデオソース24とを含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替として、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス20は必ずしも、すべての例において、サーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶する場合がある。
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含み得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化され得る。オーディオソース22は、話している参加者から、その話している参加者が話している間オーディオデータを取得することができ、ビデオソース24は、話している参加者のビデオデータを同時に取得することができる。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を備えてよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を備え得る。このように、本開示で説明される技術は、ライブ、ストリーミング、リアルタイムオーディオデータ、およびリアルタイムビデオデータに適用され得、または、アーカイブされた事前に記録されたオーディオデータ、およびアーカイブされた事前に記録されたビデオデータに適用され得る。
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に含まれるビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを含むオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは、一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
いくつかの例では、オーディオエンコーダ26は、各符号化オーディオフレームにおいて、符号化オーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプを符号化することができ、同様に、ビデオエンコーダ28は、各符号化ビデオフレームにおいて、符号化ビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプを符号化することができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/もしくはビデオエンコーダ28がタイムスタンプを生成する場合がある内部クロック、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプに関連付けるために使用する場合がある内部クロックを含み得る。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ることができ、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ることができる。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は、一般に、符号化オーディオデータのストリームを生成し、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個々の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の単一のデジタル的にコーディングされた(場合によっては圧縮された)成分である。たとえば、表現のコード化ビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化エレメンタリストリーム(PES)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化エレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは、一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
ITU-T H.264/AVCおよび今度の高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、特徴、またはツールのサブセット、およびこれらに適用される制約に対応する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって指定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に対応し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。
たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの指定されたサイズのようなビットストリーム内のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を求めることが依然として可能であることを、H.264規格は認める。多くの用途において、特定のプロファイル内のシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム内のシンタックス要素の値に課される制約の指定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。代替として、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとり得る。個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートしてもよいことを、H.264規格はさらに規定する。
プロファイルに準拠するデコーダは、普通、プロファイル内で定義されるすべての特徴をサポートする。たとえば、コーディング特徴として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル内で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、説明可能性のために有用であり得る。たとえば、ビデオ送信中、プロファイルおよびレベルの定義のペアが、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCにおいて、レベルは、処理される必要があるマクロブロックの数、復号ピクチャバッファ(DPB)のサイズ、コード化ピクチャバッファ(CPB)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMB当たりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区分を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうか判断することができる。
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコード化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコード化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケッタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケッタイザを含み得る。
ビデオエンコーダ28は、種々のやり方でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数のビューを有する表現(たとえば、2次元または3次元の再生のための)、または他のそのような特性のような、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々な表現を生成することができる。本開示において使用される表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含んでもよい。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含み得る。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームを組み立てる役割を担う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28から表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(アドバンストビデオコーディング)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類され得る。VCLユニットは、コア圧縮エンジンを含んでよく、ブロック、マクロブロック、および/またはスライスレベルのデータを含んでよい。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニット内に包含され得る。
非VCL NALユニットは、特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)内に)シーケンスレベルヘッダ情報を包含し、(ピクチャパラメータセット(PPS)内に)頻繁には変化しないピクチャレベルヘッダ情報を包含し得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがって、コーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を有効化することができ、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。
補足強調情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに包含され得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおけるビュースケーラビリティ情報SEIメッセージなどのSEIメッセージ内に包含され得る。これらの例示的なSEIメッセージは、たとえば、動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを出力インターフェース32に提供し得る。出力インターフェース32は、ネットワークインターフェースもしくはユニバーサルシリアルバス(USB)インターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェースのような記憶媒体へ書き込むためのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送ることができる。図1の例では、サーバデバイス60は、それぞれのマニフェストファイル66と1つまたは複数の表現68A〜68N(表現68)とをそれぞれが含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
いくつかの例では、表現68は、適応セットに分離され得る。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を識別する場合があるテキストタイプ情報、カメラの角度または適応セット内の表現のシーンの現実世界のカメラの視野を表す場合があるカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報などのような、特性のそれぞれの共通のセットを含み得る。
マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、ならびに適応セットの共通の特性を含み得る。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にする場合がある。適応セット内の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示され得る。
サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の特徴のいずれかまたはすべては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなどの、コンテンツ配信ネットワークの他のデバイス上に実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送受信するように構成される。
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求をクライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に記述されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット70は、HTTP GETまたは部分GET要求を受信して、それらの要求に応答して、マルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定することができる。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてよい。いずれの場合でも、要求処理ユニット70は、クライアントデバイス40のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。
追加または代替として、要求処理ユニット70は、拡張マルチメディアブロードキャストマルチキャストサービス(eMBMS)などのブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じやり方で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントを、eMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、特定のマルチメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)に関連付けられたマルチキャストグループに関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含むクライアントデバイスに広告し得る。次に、クライアントデバイス40は、マルチキャストグループに加わるための要求を提出することができる。この要求は、ルータがマルチキャストグループに関連付けられたIPアドレス宛のトラフィックをクライアントデバイス40などの加入クライアントデバイスに向けるように、ネットワーク74中、たとえば、ネットワーク74を構成するルータに伝搬され得る。
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、品質が異なるビデオサービス)の記述を包含してよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を含み得る。クライアントデバイス40は、表現68のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを取り出し得る。
具体的には、取出しユニット52は、ビデオデコーダ48の復号能力とビデオ出力44のレンダリング能力とを決定するために、クライアントデバイス40の構成データ(図示せず)を取り出し得る。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GETおよび部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能性のすべてまたは一部は、ハードウェア、または、ハードウェア、ソフトウェア、および/もしくはファームウェアの組合せにおいて実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は、表現68の特性を決定するために、マニフェストファイル66の少なくとも一部分を最初に取り出し得る。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性について説明する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40の復号およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内の表現に対するビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
概して、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このように、クライアントデバイス40は、ネットワーク74の変化するネットワーク帯域幅の利用可能性にも適応しながら、ネットワーク74を介してマルチメディアデータをストリーミングし得る。
追加または代替として、取出しユニット52は、ブロードキャスト、またはeMBMSもしくはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加わるための要求を提出することができる。取出しユニット52は、マルチキャストグループに加わった後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を発行することなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、たとえば、再生を停止するために、または、チャネルを異なるマルチキャストグループに変更するために、マルチキャストグループのデータがもはや必要とされないとき、マルチキャストグループを出るための要求を提出することができる。
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部それともビデオストリームの一部であるかに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力44に送る。
図1には示さないが、ネットワーク74は、DASHアウェアネットワーク要素(DANE)またはメディアアウェアネットワーク要素(MANE)などのストリーミングアウェアネットワーク要素をさらに含み得る。取出しユニット52は、後でより詳細に記載される、ネットワーク74のストリーミングアウェアネットワーク要素にデッドライン情報を広告するための本開示の技法を実装することができる。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理回路機構、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路機構のいずれかとして実装され得る。いくつかの例では、ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50のうちの1つまたは複数が、「システムオンチップ」(または「SoC」)と呼ばれる、単一の製造されたチップに統合され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、複合ビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、複合コーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話のようなワイヤレス通信デバイスを含み得る。
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法について説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりに(または、それに加えて)これらの技法を実施するように構成され得ることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームを記述するデータを特定するヘッダを含むNALユニットを形成することができる。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含み得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含み得る。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムに関連付けることができる。
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットを組み立てることができる。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含むことができる。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが20フレーム毎秒(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応し得る。この時間間隔中、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、一次コード化ピクチャとして提示され得る、1つの時間インスタンス内のコード化ピクチャを含み得る。
したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば、時間Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに対する符号化ピクチャ(または、フレーム)を含み得る。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を包含し得るメディアプレゼンテーション記述(MPD)を含むことができ、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含み得る。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定することができる。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス(moofボックス)内に配置され得る。
マニフェストファイル66(たとえば、MPDを含み得る)は、表現68のセグメントの利用可能性を広告することができる。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス40の取出しユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能であるときを判断することができる。
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルに組み立てた後、カプセル化ユニット30は、ビデオファイルを出力のために出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送る代わりに、ビデオファイルをローカルに記憶するか、または出力インターフェース32を介してビデオファイルをリモートサーバに送ることができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえば、オプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピードライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含み得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部それともビデオストリームの一部であるかに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力44に送る。
図2は、図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット52は、eMBMSミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。
この例では、eMBMSミドルウェアユニット100は、eMBMS受信ユニット106と、キャッシュ104と、サーバユニット102とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、http://tools.ietf.org/html/rfc6726において入手可能な、T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月に記述されたFile Delivery over Unidirectional Transport(FLUTE)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、たとえば、BM-SCとして作用し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
eMBMSミドルウェアユニット100がファイルに関するデータを受信すると、eMBMSミドルウェアユニットは受信されたデータをキャッシュ104内に記憶することができる。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体などのコンピュータ可読記憶媒体を含み得る。
ローカルサーバユニット102は、DASHクライアント110用のサーバとして作用し得る。たとえば、ローカルサーバユニット102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に提供することができる。ローカルサーバユニット102は、MPDファイル内、ならびにセグメントを取り出すことができるハイパーリンク内のセグメントに関する利用可能性時間を広告することができる。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GETまたは部分GET要求を使用して、ローカルサーバユニット102にセグメントを要求することができる。たとえば、リンクhttp://127.0.0.1/rep1/seg3から入手可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を構築し、その要求をローカルサーバユニット102に提出することができる。ローカルサーバユニット102は、要求されたデータをキャッシュ104から取り出し、そのような要求に応答して、そのデータをDASHクライアント110に提供することができる。
図3は、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数の表現124A〜124N(表現124)とを含む。表現124Aは、任意選択のヘッダデータ126とセグメント128A〜128N(セグメント128)とを含む一方、表現124Nは、任意選択のヘッダデータ130とセグメント132A〜132N(セグメント132)とを含む。文字Nが、便宜的に、表現124の各々の最後のムービーフラグメントを指定するために使用される。いくつかの例では、表現124同士の間で異なる数のムービーフラグメントが存在し得る。
MPD122は、表現124とは別個のデータ構造を含んでよい。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124は、図2の表現68に対応し得る。一般に、MPD122は、復号およびレンダリング特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的サブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへのターゲティング広告の挿入のため)のような、表現124の特性を一般に表すデータを含んでよい。
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間的ロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在するとき、セグメント132の同様の特性を記述し得る。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
セグメント128、132は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD122のデータによって記述され得るが、そのようなデータは図3の例には示されていない。MPD122は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント128、132の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、別個に取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント128または132を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント128または132の特定のバイト範囲を取り出すことができる。
図4は、図3のセグメント128、132のうちの1つのような表現のセグメントに対応し得る、例示的なビデオファイル150の要素を示すブロック図である。セグメント128、132の各々は、図4の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図4の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、ムービー(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と、ムービーフラグメント(MOOF)ボックス164と、ムービーフラグメントランダムアクセス(MFRA)ボックス166とを含む。図4は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従ってビデオファイル150のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、時限のテキストデータなど)を含み得ることを理解されたい。
ファイルタイプ(FTYP)ボックス152は一般に、ビデオファイル150のファイルタイプを表す。ファイルタイプボックス152は、ビデオファイル150の最良の使用法を表す仕様を特定するデータを含み得る。ファイルタイプボックス152は、代替的には、MOOVボックス154、ムービーフラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル150のセグメントタイプを定義し得る。以下でより詳細に論じる図7は、MPD更新ボックスに関する追加の情報を提供する。
図4の例では、MOOVボックス154は、ムービーヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数のムービー延長(MVEX)ボックス160とを含む。一般に、MVHDボックス156は、ビデオファイル150の一般的な特性を記述し得る。たとえば、MVHDボックス156は、ビデオファイル150がいつ最初に作成されたかを表すデータ、ビデオファイル150がいつ最後に修正されたかを表すデータ、ビデオファイル150のタイムスケールを表すデータ、ビデオファイル150の再生の長さを表すデータ、または、ビデオファイル150を全般に表す他のデータを含み得る。
TRAKボックス158は、ビデオファイル150のトラックのためのデータを含み得る。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を記述するトラックヘッダ(TKHD)ボックスを含み得る。いくつかの例では、TRAKボックス158は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは、TRAKボックス158のデータおよび/またはsidxボックス162のデータによって参照され得るムービーフラグメント164内に含まれ得る。
いくつかの例では、ビデオファイル150は、2つ以上のトラックを含み得る。したがって、MOOVボックス154は、ビデオファイル150中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を記述し得る。たとえば、TRAKボックス158は、対応するトラックの時間情報および/または空間情報を記述し得る。MOOVボックス154のTRAKボックス158と同様のTRAKボックスは、カプセル化ユニット30(図3)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を記述し得る。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングすることができる。
MVEXボックス160は、たとえば、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150がムービーフラグメント164を含むことをシグナリングするために、対応するムービーフラグメント164の特性を記述し得る。ストリーミングビデオデータのコンテキストでは、コード化ビデオピクチャは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。
MOOVボックス154は、ビデオファイル150の中のムービーフラグメント164の数に等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、ムービーフラグメント164のうちの対応する1つの特性を記述し得る。たとえば、各MVEXボックスは、ムービーフラグメント164のうちの対応する1つの持続時間を記述するムービー延長ヘッダ(MEHD)ボックスを含み得る。
上述のように、カプセル化ユニット30は、実際のコード化ビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶し得る。ビデオサンプルは、一般にアクセスユニットに対応してよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCのコンテキストでは、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を包含する、1つまたは複数のVCL NALユニットをコード化ピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、ムービーフラグメント164のうちの1つの中に含め得る。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、ムービーフラグメント164のうちの1つに対応するMVEXボックス160のうちの1つの中のムービーフラグメント164のうちの1つの中に存在するものとして、シグナリングすることができる。
SIDXボックス162は、ビデオファイル150の任意選択の要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含むとは限らない。3GPPファイルフォーマットの例によれば、SIDXボックスは、セグメント(たとえば、ビデオファイル150内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「対応するメディアデータボックスを有する1つまたは複数の連続するムービーフラグメントボックスの自己完結型セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスが、そのムービーフラグメントボックスに続き、同じトラックについての情報を包含する次のムービーフラグメントボックスに先行しなければならない」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を包含する。参照されるサブセグメントは、プレゼンテーション時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照される材料におけるバイトの数のカウントを与える」ことを示す。
SIDXボックス162は、一般に、ビデオファイル150内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。
ムービーフラグメント164は、1つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント164は、1つまたは複数のピクチャグループ(GOP)を含んでよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上記で説明したように、ムービーフラグメント164は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント164の各々は、ムービーフラグメントヘッダボックス(MFHD、図4には示されない)を含み得る。MFHDボックスは、ムービーフラグメントのシーケンス番号などの、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント164は、ビデオファイル150の中でシーケンス番号の順序に含まれ得る。
MFRAボックス166は、ビデオファイル150のムービーフラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)の探索を実施することなど、トリックモードを実施することを支援し得る。MFRAボックス166は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正確に復号し表示するために、MFRAボックス166を必ずしも参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでよく、またはいくつかの例では、ビデオファイル150のメディアトラック(たとえば、非ヒントトラック)の数と等しい数のTFRAボックスを含んでよい。
いくつかの例では、ムービーフラグメント164は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SAPのビデオファイル150内の位置の指示を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号され得るように、セグメント内に並べられ得る。たとえば、データの階層的構成において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
図5は、HTTP適応ストリーミングセッションに参加するように構成されたデバイスを含むシステム200を示す概念図である。この例では、システム200は、キャプチャデバイス202、符号化および暗号化デバイス204、メディアオリジンサーバデバイス206A〜206N(メディアオリジンサーバデバイス206)、HTTPキャッシュサーバデバイス208A〜208N(HTTPキャッシュサーバデバイス208)、クライアントデバイス210A〜210N(クライアントデバイス210)、ならびにデジタル著作権管理(DRM)ライセンスサーバデバイス212A〜212N(DRMライセンスサーバデバイス212)を含む。概して、キャプチャデバイス202は図1のオーディオソース22とビデオソース24のいずれかまたは両方に対応してよく、符号化および暗号化デバイス204は図1のオーディオエンコーダ26、ビデオエンコーダ28、および/またはカプセル化ユニット30に対応してよく、メディアオリジンサーバデバイス206および/またはHTTPキャッシュサーバデバイス208のいずれかまたはすべては図1のサーバデバイス60に対応してよく、クライアントデバイス210は図1のクライアントデバイス40に対応してよい。
この例では、キャプチャデバイス202は、メディアデータ(たとえば、オーディオおよび/またはビデオデータ)をキャプチャする。符号化および暗号化デバイス204は、メディアデータの複数のセット(たとえば、複数の表現)を形成するために、メディアデータを複数のビットレートで符号化する。符号化および暗号化デバイス204のセットの各々は、メディアデータを、図4のビデオファイル150などの小さいセグメントに分裂させることができる。さらに、符号化および暗号化デバイス204は、各セグメントを暗号化し、各セグメントを、HTTP URLを介して、メディアオリジンサーバデバイス206およびHTTPキャッシュサーバデバイス208により利用可能にすることができる。クライアントデバイス210のうちの1つまたは複数などのクライアントデバイスは、どのセグメントをダウンロードするか判断し、暗号化コンテンツ用のライセンスをDRMライセンスサーバデバイス212のうちの1つから獲得し、次いで、コンテンツをつなぎ合わせ、プレイバックする。
図6は、「スマート」クライアントデバイスの責任を示す概念図である。図6の例は、コンテンツ分配ネットワーク(CDN)220および例示的な「スマート」クライアントデバイスを表すクライアントデバイス222の例を示す。この例では、クライアントデバイス222は、1つまたは複数のマニフェストファイル(たとえば、1つまたは複数のMPD)、HTTPトランスポート、および1つまたは複数のTCP接続を管理する。クライアントデバイス222は、プレイアウトバッファ、セグメントのダウンロード時間およびスループット、(CPU、メモリ、スクリーンなどのような)ローカルリソース、ならびにドロップされたフレームを監視し、または測定する。クライアントデバイス222は、帯域幅適応も実施する。
図7は、HTTPサーバ232およびDASHクライアント240を含むシステム230を示す概念図である。システム230は、そのようなシステムにおけるMPEG DASHのスコープについて説明するために示されている。特に、この例では、HTTPサーバ232は、メディアコンテンツ234Aおよびメディアコンテンツ234Bなど、メディアコンテンツの様々なセットを記憶する。メディアコンテンツ234Aは、MPD236Aおよびセグメント238Aを含む。メディアコンテンツ234Bは、MPD236Bおよびセグメント238Bを含む。DASHクライアント240は、制御エンジン242、メディアエンジン244、MPDパーサ246、セグメントパーサ248、およびHTTPクライアント250を含む。概して、制御エンジン242、HTTPクライアント250、およびMPDパーサ246は図1の取出しユニット52に対応してよく、セグメントパーサ248は図1のカプセル化解除ユニット50に対応してよく、メディアエンジン244はオーディオデコーダ46および/またはビデオデコーダ48に対応してよい。MPEG DASHのスコープ内の、システム230の要素は、グレーシェーディングを使ってハイライトされている。この例では、MPEG DASHは、MPD236、セグメント238、MPDパーサ246、およびセグメントパーサ248を含むスコープを有する。
図8は、本開示の技法による例示的なシステム260を示す概念図である。図8の例に示すように、システム260はHTTPサーバ262およびDASHクライアント270を含み、これらは、それぞれ図7のHTTPサーバ232およびDASHクライアント240と同様である。つまり、HTTPサーバ262は、MPD266Aおよびセグメント268Aを含むメディアデータ264Aと、MPD266Bおよびセグメント268Bを含むメディアデータ264Bとを記憶する。同様に、DASHクライアント270は、制御エンジン272、メディアエンジン274、MPDパーサ276、セグメントパーサ278、およびHTTPクライアント280を含む。ただし、システム260は、下位レイヤトランスポート284を介してDASHクライアント270に結合されたDASHアウェアネットワーク要素(DANE)デバイス282をさらに含む。
図8は、考慮されるメッセージフローのハイレベルアーキテクチャを提供する。DASHメディアが、HTTPサーバ262上に記憶され、HTTP-CDNを通して配信される。DASHクライアント270は、セッションを制御し、適切な時間にHTTP要求を発行する。HTTP接続を終端する中間ノード(たとえば、DANE282)は、DASHアンアウェアな場合はキャッシュとして、またはDASHアウェアな場合はDANEとして作用し得る。DANE282は、たとえば、下位レイヤトランスポート284を介してデッドライン情報を提供することによって、配信を最適化するために、HTTPサーバ262および/またはDASHクライアント270から情報を受信することができ、そうすることによって、DANE282または下位レイヤトランスポート284にのっとった他のデバイスは、メディアデータがDASHクライアント270に配信されるための配信決定において、デッドライン情報を利用することができる。
図9は、単純なクライアントモデル290を示す概念図である。図1のクライアントデバイス40、図5のクライアントデバイス210、図6のクライアントデバイス222、図7のDASHクライアント240、および図8のDASHクライアント270は概して、クライアントモデル290に従って構成され得る。クライアントモデル290の例において、クライアントは、ダウンロードエンジン292、バッファ294、ならびにメディアデコーダおよびレンダラ296を含む。図1のクライアントデバイス40に関して、たとえば、ダウンロードエンジン292およびバッファ294は取出しユニット52に含まれてよく、メディアデコーダおよびレンダラ296は、オーディオデコーダ46、ビデオデコーダ48、オーディオ出力42、およびビデオ出力44に対応してよい。
DASH-IF IOP v3.1、セクション4.3.4の記述によると、DASHクライアントは次のように作用する。DASHクライアントは、MPD中で提供される情報によって、たとえば、図9に示すクライアントモデル290に従って案内される。
DASHクライアントは、MPDへのアクセスを有し、各セグメントについてのセグメント利用可能性時間をMPDから導出することができると仮定する。簡単のために、MPDは、期間開始時間PSwc[i]をもつ単一の期間を含むだけであり、MPD-URLはいかなるフラグメントパラメータも含まないと仮定される。以下の例示的なクライアント挙動は、連続したストリーミングエクスペリエンスをユーザに提供する。
1.DASHクライアントは、MPDを解析し、その環境に適した適応セットの集合体を、AdaptationSet要素の各々の中で提供される情報に基づいて選択する。
2.各適応セット内で、DASHクライアントは、通常は@bandwidth属性の値に基づいて、ただしクライアントの復号およびレンダリング能力も考慮に入れて、1つの表現を選択する。
3.DASHクライアントは、MPD中の情報およびDASHクライアントにおける現在時間JOIN、ならびに、特に、ライブエッジセグメントと呼ばれるライブエッジに最も近いセグメントを考慮に入れて、少なくとも各選択された表現についてのアクセス可能セグメントのリストを作成する。
4.DASHクライアントは、選択された表現の初期化セグメントをダウンロードし、次いで、セグメント全体またはセグメントのバイト範囲を要求することによって、コンテンツにアクセスする。通常、いつでも、DASHクライアントは、(i)現在のセグメントのダウンロードの完了、または(ii)次のセグメントのセグメント利用可能性開始時間のうちのより大きい方において、次のセグメントをダウンロードする。@availabilityTimeOffsetが存在する場合、セグメントは、より早く、すなわち、調節されたセグメント利用可能性開始時間にダウンロードされ得る。バッファフルネスおよび他の基準に基づいて、レート適応が検討される。通常、ダウンロードされる第1のメディアセグメントはライブエッジセグメントであるが、スタートアップ待ち時間を最小限にするために、他の決定が行われる場合がある。
5.図9の例によると、ダウンロードエンジン292は、取り出されたメディアデータをバッファ294中に供給し、どこかの時点で、メディアデコーダおよびレンダラ296が、メディアデータを復号し、レンダリングし始める。各選択された適応セットの選択された表現を、ダウンロードエンジン292がダウンロードし、メディアデコーダおよびレンダラ296が提示する。同期は、MPD中でシグナリングされる期間情報中のプレゼンテーション時間を使って行われる。同期されたプレイアウトのために、メディアにおける正確なプレゼンテーション時間が使われるものとする。
a.プレゼンテーションが始まると、プレイアウトプロセスは絶え間なく続く。プレイアウトプロセスは、メディアデータがバッファ294中に絶えず存在するという仮定に基づく。MPD中にMPD@suggestedPresentationDelayが存在する場合、この値はプレゼンテーション遅延、すなわちPDとして使われ得る。MPD中にMPD@suggestedPresentationDelayが存在しないが、DASHクライアントが、ライブエッジにおいてサービスを消費すると予想される場合、適切なプレゼンテーション遅延が、通常は@minBufferTimeの値と@timeShiftBufferDepthの値との間で選択されるべきである。DASHクライアントは、ダウンロードされたメディアセグメントkの第1のサンプルを、最も早いプレゼンテーション時間EPT(k)で、PSwc[i]+(EPT(k)-o[r,i])+PDにおいてレンダリングし始めることが推奨される。
6.DASHクライアントは、利用可能性時間ウィンドウ中に、生成されたセグメントリストを使うことによって、選択された表現のメディアセグメントを要求することができる。
7.プレゼンテーションが始まると、DASHクライアントは、ダウンロードエンジン292がメディアセグメントまたはメディアセグメントのいくつかの部分を連続的に要求するという点で、メディアコンテンツを消費し続け、メディアデコーダおよびレンダラ296は、メディアプレゼンテーションタイムラインに従ってコンテンツを再生する。DASHクライアントは、その環境からの更新された情報を考慮に入れて、表現を切り替えることができるが、この態様は、本文書における考察には比較的関連性がない。
8.壁時計時間NOWが進むと、DASHクライアントは利用可能セグメントを消費する。NOWが進むと、クライアントは可能性として、利用可能セグメントのリストを、期間中の各表現について拡大する。
1.DASHクライアントは、MPDを解析し、その環境に適した適応セットの集合体を、AdaptationSet要素の各々の中で提供される情報に基づいて選択する。
2.各適応セット内で、DASHクライアントは、通常は@bandwidth属性の値に基づいて、ただしクライアントの復号およびレンダリング能力も考慮に入れて、1つの表現を選択する。
3.DASHクライアントは、MPD中の情報およびDASHクライアントにおける現在時間JOIN、ならびに、特に、ライブエッジセグメントと呼ばれるライブエッジに最も近いセグメントを考慮に入れて、少なくとも各選択された表現についてのアクセス可能セグメントのリストを作成する。
4.DASHクライアントは、選択された表現の初期化セグメントをダウンロードし、次いで、セグメント全体またはセグメントのバイト範囲を要求することによって、コンテンツにアクセスする。通常、いつでも、DASHクライアントは、(i)現在のセグメントのダウンロードの完了、または(ii)次のセグメントのセグメント利用可能性開始時間のうちのより大きい方において、次のセグメントをダウンロードする。@availabilityTimeOffsetが存在する場合、セグメントは、より早く、すなわち、調節されたセグメント利用可能性開始時間にダウンロードされ得る。バッファフルネスおよび他の基準に基づいて、レート適応が検討される。通常、ダウンロードされる第1のメディアセグメントはライブエッジセグメントであるが、スタートアップ待ち時間を最小限にするために、他の決定が行われる場合がある。
5.図9の例によると、ダウンロードエンジン292は、取り出されたメディアデータをバッファ294中に供給し、どこかの時点で、メディアデコーダおよびレンダラ296が、メディアデータを復号し、レンダリングし始める。各選択された適応セットの選択された表現を、ダウンロードエンジン292がダウンロードし、メディアデコーダおよびレンダラ296が提示する。同期は、MPD中でシグナリングされる期間情報中のプレゼンテーション時間を使って行われる。同期されたプレイアウトのために、メディアにおける正確なプレゼンテーション時間が使われるものとする。
a.プレゼンテーションが始まると、プレイアウトプロセスは絶え間なく続く。プレイアウトプロセスは、メディアデータがバッファ294中に絶えず存在するという仮定に基づく。MPD中にMPD@suggestedPresentationDelayが存在する場合、この値はプレゼンテーション遅延、すなわちPDとして使われ得る。MPD中にMPD@suggestedPresentationDelayが存在しないが、DASHクライアントが、ライブエッジにおいてサービスを消費すると予想される場合、適切なプレゼンテーション遅延が、通常は@minBufferTimeの値と@timeShiftBufferDepthの値との間で選択されるべきである。DASHクライアントは、ダウンロードされたメディアセグメントkの第1のサンプルを、最も早いプレゼンテーション時間EPT(k)で、PSwc[i]+(EPT(k)-o[r,i])+PDにおいてレンダリングし始めることが推奨される。
6.DASHクライアントは、利用可能性時間ウィンドウ中に、生成されたセグメントリストを使うことによって、選択された表現のメディアセグメントを要求することができる。
7.プレゼンテーションが始まると、DASHクライアントは、ダウンロードエンジン292がメディアセグメントまたはメディアセグメントのいくつかの部分を連続的に要求するという点で、メディアコンテンツを消費し続け、メディアデコーダおよびレンダラ296は、メディアプレゼンテーションタイムラインに従ってコンテンツを再生する。DASHクライアントは、その環境からの更新された情報を考慮に入れて、表現を切り替えることができるが、この態様は、本文書における考察には比較的関連性がない。
8.壁時計時間NOWが進むと、DASHクライアントは利用可能セグメントを消費する。NOWが進むと、クライアントは可能性として、利用可能セグメントのリストを、期間中の各表現について拡大する。
いくつかの態様が、上の黒丸5〜7に要約されている。DASHクライアントは、要求のスケジューリングおよびプレイアウトスケジューリングを制御する。同時に、DASHクライアントは、バッファアンダーフローを避けるために、表現の次のセグメントが利用可能になる必要がある最新の時間についての知識を有する。情報は、少なくとも、MPDからの良好な正確さで(期間タイムラインからメディアタイムラインへのマッピングを使う)、ただし、前のセグメントがダウンロードされると、一層良好な正確さで利用可能である。さらなる詳細が、以下の図10に示されている。
図10は、サーバデバイスおよびクライアントデバイスの視点からのセグメントを示す概念図である。サーバデバイスは、データ(たとえば、セグメント)を利用可能にし、一定の時間(特定のセグメントがサーバからの取出しのために利用可能である時間期間は、「セグメント利用可能性ウィンドウ」と呼ばれ得る)までデータを利用可能なままにしておく。DASHクライアントは、この情報(すなわち、利用可能性の時間またはセグメント利用可能性ウィンドウ)をMPDから判断する。
DASHクライアントがMPDを初めてダウンロードした(図10のFetchMPD(1))後、DASHクライアントは、セグメント1および2が利用可能であると判断する。さらに、時間とともに、ますます多くのセグメントが、MPD中で提供される情報に基づいて利用可能になる。ある程度のプレゼンテーション遅延(提案されたプレゼンテーション遅延またはクライアントが選択したものを使う)の後のどこかの時点で、DASHクライアントは、プレイアウトをスケジュールし、取り出されたセグメントのメディアデータを復号およびレンダリングし始める。始まると、クライアントは、MPDと、セグメントが要求されたときとに基づいて、平滑なプレイアウトを保証するために、DASHクライアント中でセグメントがいつ利用可能にならなければならないかを判断することができる。同時に、DASHクライアントは、セグメントがサーバ上で依然として利用可能である最新の時間を判断することができる。
本開示の技法によると、DASHクライアント(図8のDASHクライアント270など)は、デッドライン情報(つまり、バッファアンダーランなどのリアルタイム制約を満足するために特定のセグメントまたは他のデータが受信されなければならないときを表す情報)を生成し、要求をどのようにスケジュールするかをネットワークが決めるために、デッドライン情報をネットワークに返送することができる。以下でいくつかの例について説明する。さらに、DASHクライアントは、いくつかの状況では、比較的良好なネットワーク時間プロトコル(NTP)同期クロックに従い得る。他の状況では、同期ははるかに緩くてよい。さらに、利用可能性時間およびスケジューリングは、静的タイプコンテンツ、たとえば、オンデマンドコンテンツにも関わる。
デッドライン情報を使うための様々な使用ケースが企図される。そのようなデッドライン情報を使うためのいくつかの例には、以下のものがある。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインについての情報は、緊急オブジェクトの適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインについての情報は、緊急オブジェクトの適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。
関連ソリューションを作成する際、以下の基準が考慮される。
●ソリューションは単純でよい。
●ソリューションは好ましくは、DASHに依存せずに働き得る。
●ソリューションは、SAND状況メッセージフレームワークの一部であり得る。
●ソリューションは、DASHクライアント用に実装可能であり得る。
●ソリューションは、絶対値または相対値としてのデッドライン情報の提供を可能にし得る。
●ソリューションは、正規セグメント要求ならびにバイト範囲要求(たとえば、HTTP GETまたは部分GET要求)とともに働き得る。
●ソリューションは、最適化であり、後方互換方式で働き得る。
●ソリューションは単純でよい。
●ソリューションは好ましくは、DASHに依存せずに働き得る。
●ソリューションは、SAND状況メッセージフレームワークの一部であり得る。
●ソリューションは、DASHクライアント用に実装可能であり得る。
●ソリューションは、絶対値または相対値としてのデッドライン情報の提供を可能にし得る。
●ソリューションは、正規セグメント要求ならびにバイト範囲要求(たとえば、HTTP GETまたは部分GET要求)とともに働き得る。
●ソリューションは、最適化であり、後方互換方式で働き得る。
概して、いくつかのシナリオでは、DASHクライアントが、要求されたメディアデータを適時に受信していないので、バッファアンダーランが起こり得るという問題が生じ得る。つまり、様々な理由により、DASHクライアントがメディアデータを要求するのにもかかわらず、メディアデータは時間内に配信されない場合があり、したがって、DASHクライアントのバッファの内容は、新規メディアデータが利用可能になり、復号およびレンダリングの用意ができる前に空にされ得る。
本開示の技法は、DASHクライアントが、タイミング情報を十分に認識しているという基本的考え方を前提とする。つまり、DASHクライアントは、マニフェストファイル(たとえば、MPD)から、壁時計時間で以下の情報、すなわち、ネットワーク上でセグメントがいつ利用可能であるか、および平滑なプレイアウトを続けることが可能である(たとえば、バッファアンダーランを防止する)ために、各セグメントが受信機において利用可能である必要がある時間を判断することができる。DASHクライアントが、この情報の一部をDANEに提供した場合、DANEは、セグメントが時間内に受信機において利用可能になることを保証するために、配信を最適化することができる。説明の目的で、本技法は、DASHクライアントおよびDANEに関して記載されるが、これらの技法は、他のストリーミングデバイス(たとえば、他の任意のストリーミングクライアントおよびストリーミングアウェアネットワーク要素)によって実施されてよい。
ユーザ機器(UE)(つまり、クライアントデバイス)は、DANEなどのストリーミングアウェアネットワーク要素に、以下の情報を報告し得る。
●HTTPストリーミングプレイアウトバッファ状況:
○バッファレベル(ms)。
○タイムスタンプ:UEがバッファ状況情報を生成する時間。
○プレイアウトデータレート:eNBがDASHアウェアでない場合、eノードB(eNB)がUEのバッファレベルを推定するため。
●セグメント全体(オブジェクト)についての壁時計時間でのデッドラインまたは最大RTT。
○UEは、この時間を各HTTP GET要求中で指定することができる。
●より詳細な情報。たとえば、セグメントの初期部分が、後半部分とは異なるデッドラインを有するということであってよい。
○クライアントは、初期パケットのデッドラインを報告する。
○オブジェクトは、中間ノードが各バイト範囲の配信をDASHクライアントからの情報およびプレイアウト曲線に従ってスケジュールすることができるように、各バイト範囲についてのプレイアウトスケジュールを含む。
●また、受信モード、すなわちフルセグメントモードまたはメディア配信イベント(MDE)モードを報告する。
●HTTPストリーミングプレイアウトバッファ状況:
○バッファレベル(ms)。
○タイムスタンプ:UEがバッファ状況情報を生成する時間。
○プレイアウトデータレート:eNBがDASHアウェアでない場合、eノードB(eNB)がUEのバッファレベルを推定するため。
●セグメント全体(オブジェクト)についての壁時計時間でのデッドラインまたは最大RTT。
○UEは、この時間を各HTTP GET要求中で指定することができる。
●より詳細な情報。たとえば、セグメントの初期部分が、後半部分とは異なるデッドラインを有するということであってよい。
○クライアントは、初期パケットのデッドラインを報告する。
○オブジェクトは、中間ノードが各バイト範囲の配信をDASHクライアントからの情報およびプレイアウト曲線に従ってスケジュールすることができるように、各バイト範囲についてのプレイアウトスケジュールを含む。
●また、受信モード、すなわちフルセグメントモードまたはメディア配信イベント(MDE)モードを報告する。
クライアントデバイスは、追加または代替として、プレイアウト情報を報告することができる。
●プレイアウトスケジュールは、以下のようであり得る。
○デフォルトでステップ関数となり、すなわち、セグメント全体が、利用可能である必要がある。
○プレイアウト曲線(時間によるバイト範囲)として、メディア/DASHサーバから補足情報として報告される。
○クライアントが、スケジューリングにおいて使われ得るそのような情報を(たとえば、セグメントインデックスによって)有する場合、クライアントからDANEに返送する。
●そのような情報は、スケジューラによって、バイト範囲の配信を最適化するのに使われ得る。
●プレイアウトスケジュールは、以下のようであり得る。
○デフォルトでステップ関数となり、すなわち、セグメント全体が、利用可能である必要がある。
○プレイアウト曲線(時間によるバイト範囲)として、メディア/DASHサーバから補足情報として報告される。
○クライアントが、スケジューリングにおいて使われ得るそのような情報を(たとえば、セグメントインデックスによって)有する場合、クライアントからDANEに返送する。
●そのような情報は、スケジューラによって、バイト範囲の配信を最適化するのに使われ得る。
図11は、ビデオオブジェクトデッドラインアウェアスケジューリングを実施するための1つの例示的な方法を示す概念図である。この例では、方法は、クライアントデバイス302、DASHサーバデバイス304、およびDANE306を含むシステム300によって実施される。DANE306は、次に、パケットゲートウェイ(PGW)デバイス308およびeノードB310を含む。この例では、クライアントデバイス302は、デッドライン情報を、HTTP要求によりDASHサーバ304に配信する(312)。特に、クライアントデバイス302(UEの例)は、HTTPによりデッドライン情報をDASHサーバに報告する。DASHサーバ304は次いで、デッドライン情報をDANE306のPGWデバイス308に送る(314)。さらに、PGWデバイス308は、デッドライン情報をeノードB310に送る(316)。次いで、eノードB310は、デッドライン情報を使って、DASHサーバデバイス304へのメディアデータ(たとえば、セグメントまたはMDE)の配信をスケジュールし(318)、デバイス304は次いで、メディアデータをクライアントデバイス302に送って(320)、メディアデータが、デッドライン情報に従って、クライアントデバイス302のバッファのバッファアンダーランを防止するためにメディアデータが必要とされる時間に、またはその前に、クライアントデバイス302に到着することを保証することができる。代替として、eノードB310は、メディアデータをクライアントデバイス302に直接配信してよい。
一例では、PGWデバイス308とDASHサーバデバイス304(プロキシサーバデバイスに対応し得る)との間には、ネットワークトンネルがある。デッドライン情報は、マルチプロトコルラベルスイッチング(MPLS)などのネットワークトンネルプロトコルに従って送られるトンネル化パケットのヘッダ中で搬送され得る。
別の例では、PGWデバイス308は、DASHサーバデバイス304から受信されたパケットに対して選択的ディープパケット検査(DPI)を実施することができる。つまり、HTTPサーバデバイス304は、HTTPメッセージ中にデッドライン情報を含めることができる。PGWデバイス308は、デッドライン情報を取り出すために、DASHサーバデバイス304からのパケットに対してDPIを実施することができる。
PGWデバイス308は、eノードB310(つまり、基地局)に送られる各ダウンリンクパケットのGPRSトンネリングプロトコルU(GTP-U)ヘッダ中にデッドライン情報を含めればよい。eノードB310は次いで、これらのパケットの送信をデッドライン情報ごとにスケジュールすればよい。
別の例では、クライアントデバイス302は、HTTPによりデッドライン情報をDANE306に報告することができる。DANE306は、各セグメントのプレイアウト曲線を解釈することもできる。DANE306は次いで、この情報を、eノードB310のスケジューラにとって利用可能にしてよい。eノードB310は次いで、この情報を、プレイアウトスケジューリング(たとえば、パケット配信)を最適化するのに使うことができる。
HTTPベースのデッドライン情報配信において、クライアントデバイス302によって実行されるストリーミングクライアントからDANE306に送られる情報(たとえば、メディアデータについての要求に対応するパケット)は、デッドライン情報を含み得る。デッドライン情報は、シンタックスおよびプロトコルオプションを含み得る。これらのオプションは、HTTPヘッダ拡張中に、および/または照会パラメータの一部として要求中に含まれ得る。追加または代替として、デッドライン情報は、既存の展開に、たとえば、HTTP/1.1ベースの配信またはHTTP/2.0ベースの配信にマップされ得る。DASHサーバデバイス304からDANE306への情報およびこの例におけるデッドライン情報の使用は、リアルタイムオブジェクト配信オーバー単方向トランスポート(ROUTE:Real-Time Object Delivery over Unidirectional Transport)トランスポートプロトコルおよびMDEを含み得る。
様々な例において、これらの様々なデバイスの間で交換される情報は、様々な問題に対するソリューションを定義し得る。たとえば、セグメント全体(オブジェクト)についての、壁時計時間でのデッドライン、セグメント全体(オブジェクト)についての、ミリ秒での最大RTT、クライアントにおける現在利用可能なバッファ、および/またはより詳細な情報(たとえば、セグメントの初期部分が、後半部分とは違うデッドラインを有するということであってよい)を含み得る、どのような情報がクライアントからネットワークに送られるかという意味論的問題である。同様に、シンタックスおよびプロトコルオプションが、要求における照会パラメータの一部としての、要求におけるHTTPヘッダ拡張、またはDASHクライアントとDANEとの間の他の制御チャネル中で交換され得る。さらに、そのような情報から、HTTP/1.1ベースの配信、HTTP/2.0ベースの配信、またはROUTEトランスポートプロトコルおよびMDEなど、既存の展開へのマッピングがあり得る。
図12は、図11の方法を実施することができるシステム330の例示的な実装形態の概念図である。この例では、システム330は、この例ではパケットゲートウェイ(PGW)/サービングゲートウェイ(SGW)342であるゲートウェイ(GW)の上にHTTPプロキシ/キャッシュ344を含む。さらに、システム330は、クライアントデバイス332、eノードB340、およびCDN346を含む。PGW/SGW342とHTTPプロキシ/キャッシュ344は、この例では、Gi-LANインターフェース348によって結合される。その上、クライアントデバイス332はモデム336を含み、モデム336は、eノードB340と通信するように構成され得る。クライアントデバイス332はHTTPクライアント334も含み、クライアント334は、クライアントデバイス332のデジタル論理回路機構(図12には示さず)を備える、ハードウェアベースのプロセッサによって実行されるストリーミングアプリケーションであってよい。クライアントデバイス332はキャッシュ338も含み、キャッシュ338は、取り出されたメディアコンテンツをバッファリングするための、様々なランダムアクセスメモリ(RAM)、ハードディスク、フラッシュドライブなどのいずれかのような、物理的、非一時的コンピュータ可読媒体の一部分を表し得る。
クライアントデバイス332およびHTTPプロキシ/キャッシュ344は、本開示の技法に従ってデッドライン情報を交換するように構成され得る。つまり、クライアントデバイス332は、デッドライン情報報告技法を実装することができ、HTTPプロキシ/キャッシュ344は、報告されたデッドライン情報に従ってメディアデータがクライアントデバイス332において利用可能であることを保証するために、デッドラインベースのスケジューリング技法を実装することができる。クライアントデバイス332およびHTTPプロキシ/キャッシュ344は、HTTPプロキシ/キャッシュ344からPGW/SGW342への無線アクセスネットワーク(RAN)を介して、デッドライン情報を、eノードB340へのGTP-Uヘッダ中で交換することができる。
たとえば、クライアントデバイス332のHTTPクライアント334は、HTTPプロキシ/キャッシュ344を介してCDN346から取り出されるメディアデータのプレイアウトレートを判断するように構成され得る。HTTPクライアント334は、キャッシュ338の充填レベル(つまり、キャッシュ338中に記憶されたメディアデータの量)も判断することができる。キャッシュ338の充填レベルおよびプレイアウトレートに基づいて、HTTPクライアント334は、キャッシュ338のバッファアンダーランを防止するために、要求されたメディアデータが受信されなければならないデッドラインを判断することができる。HTTPクライアント334は、デッドラインを表すデッドライン情報を、たとえば、メディアデータについての要求中で広告してよく、要求は最終的に、HTTPプロキシ/キャッシュ344および/またはCDN346に配信される。HTTPプロキシ/キャッシュ344は、クライアントデバイス332のキャッシュ338のバッファアンダーランを防止するために、デッドライン情報に従って、要求されたメディアデータの配信を優先してよい。追加または代替として、eノードB340が、クライアントデバイス332のキャッシュ338のバッファアンダーランを防止するために、デッドライン情報に従って、要求されたメディアデータの配信を優先してよい。
図13は、メディアオブジェクトデッドラインアウェアスケジューリングのための本開示の技法を実装し得る別の例示的なシステム350を示す概念図である。システム350は、DASHサーバ352、PGW354、eノードB356、およびクライアントデバイス358を含む。やはり、クライアントデバイス358は、図1のクライアントデバイス40と同様の構成要素を含んでよく、DASHサーバ352は、図1のサーバデバイス60と同様の構成要素を含んでよい。この例では、クライアントデバイス358は、DANE固有デッドライン情報を、たとえば、eノードB356に配信する。特に、クライアントデバイス358は、たとえば、パケットデータコンバージェンスプロトコル(PDCP)または無線リソース制御(RRC)プロトコルを使って、RANシグナリングによりデッドライン情報をeノードB356に報告する。クライアントデバイス358はDASHクライアントを実行することができ、DASHクライアントは、アプリケーションプログラミングインターフェース(API)により、デッドライン情報をクライアントデバイス358のモデムに報告してよい。
デッドライン情報を受信した後、eノードB356は、デッドライン情報ごとに、クライアントデバイス358とDASHサーバ352との間のHTTPストリーミングセッション用の送信をスケジュールすることができる。つまり、DASHサーバ352は、メディアデータ(たとえば、適応セットの表現のセグメントの全部または一部分)についての要求をクライアントデバイス358から受信し、要求されたメディアデータを、PGW354およびeノードB356を介してクライアントデバイス358に送ればよい。次いで、eノードB356は、クライアントデバイス358から前に受信されたデッドライン情報に従って、要求されたメディアデータの配信を優先してよい。
デッドライン情報は、様々なやり方でダウンリンク(DL)パケットに関連付けられ得る。一例では、HTTPプロキシが、eノードB356に論理的に統合され得る。したがって、HTTPプロキシは、特定のデッドラインを要求されたメディアデータ(たとえば、セグメント番号)に関連付けるテーブルまたは他のデータ構造を記憶することができる。つまり、テーブルは、メディアデータ(特定のセグメント番号など)のセットを表す第1の列、および対応するセグメントに関連付けられたデッドライン情報中で指定されたデッドラインを表す第2の列を含み得る。したがって、HTTPプロキシが、第1の列中で識別されたセグメントをキャッシュしているとき、HTTPプロキシは、テーブルの第2の列中で指定されたデッドラインに、またはその前にセグメントがクライアントデバイス358に配信されることを保証するために、クライアントデバイス358へのセグメントの配信を優先してよい。別の例では、専用ベアラチャネルが、HTTPストリーミングセッション用に確立され得る。
図14は、図13に関して上で論じた方法を実施することができる例示的なシステム360を示す概念図である。この例では、システム360は、クライアントデバイス362、eノードB370、PGW/SGW376、およびCDN378を含む。クライアントデバイス362は、HTTPクライアント364、モデム366、およびキャッシュ368を含み、eノードB370はHTTPプロキシ/キャッシュ372を含む。したがって、eノードB370のHTTPプロキシ/キャッシュ372は、RANキャッシングと呼ばれるHTTPキャッシングを実施する。したがって、eノードB370は、コンテンツを論理的にキャッシュすることができる。モデム366、キャッシュ368、eノードB370、およびHTTPプロキシ/キャッシュ372はまとめて、HTTPプロキシ374と呼ばれ得る。
物理的に、HTTPプロキシ/キャッシュ372およびキャッシュ用のメモリは、eノードB370の外にあってよい(たとえば、以下の図15に示すように)。ローカルに、物理的にキャッシュされない場合、eノードB370は、CDN378またはコンテンツサーバからPGW/SGW376を介してコンテンツをフェッチする。これは、eノードB370をインターネットに直接曝すのを避け、HTTPによるサービス継続性も保証する。モバイルネットワークオペレータは、予測に基づいてeノードB370にコンテンツをプッシュしてもよい。クライアントデバイス362は、PDCP、HTTP、またはRRCを介して、デッドライン情報をeノードB370に報告すればよい。
図15は、本開示の技法によるパケット化の例を示す概念図である。この例では、プレイアウト曲線メタデータが、送付機によって、データを適切にパケット化し、スケジュールするのに使われ得る。
図16は、初期化セグメント(IS)382および複数のメディアセグメント(MS)384A〜384G(MS384)を含む一連のセグメント380を示す概念図である。IS382は、1つの構成要素に対して、すべての関連メタデータ、ならびにメディアデータを包含し、ファイルフォーマットレベルでランダムアクセスポイントを提供し、バイトでのサイズ、ファイルフォーマットでの最も早いプレゼンテーション時間(期間の開始に相対したISO BMFFタイムライン内)および持続時間情報、すなわち、それが(「期間/MPU」内で)またがるサンプルの持続時間を提供する。セグメント382、384の順序連結の結果、ISO BMFF用の適合ビットストリームが生じる。
図17Aおよび図17Bは、メディアセグメントについてのプレイアウト曲線を表す概念図である。プレイアウト曲線は、一定の時間まで存在するのに必要なバイトの量を表す。曲線の形状は、メディアエンコーダ/準備によって決定される。例は、サンプル境界および時間における線形増加を含む。完全なセグメントが、プレイアウトのために必要である。プレイアウト曲線は、トランスポートによって、配信に使われ得る。より多くのメタデータが、トランスポート用に追加され、または使われてよい。
いくつかの例では、適切なプレイアウトのために、セグメント全体が受信機において利用可能である必要がある。そのようなモデルは、いくつかの受信機実装形態には適しているが、多くのケースでは、セグメントは「プログレッシブに」、すなわち、同時に再生し、ダウンロードすることによって再生され得る。そのような特徴は特に、低遅延シナリオに適している。情報は、単純なデッドライン状況メッセージへの拡張として、クライアントからDANEに提供されてよく、またはPEDとしてDASHサーバからDANEに提供されてよい。
メディアセグメントは、再生可能プレフィックスに下位分割され得る。セグメント中で最も早いプレゼンテーション時間を仮定すると、プレイアウト曲線は、一定の時間まで存在するのに必要なバイトの量を表す。「最悪ケース」では、すべてのバイトが、最も早いプレゼンテーション時間を再生するのに必要である。このケースでは、セグメント全体が一度利用可能になるだけで、データが再生され得る。ただし、通常、セグメント全体のプレフィックスのみがあれば、セグメントは、提示され始めることができ、連続的により多くのバイトがプレフィックスに追加されると、ますます多くのプレゼンテーション時間が再生され得る。プレイアウト曲線の形状は、メディアエンコーダ/準備によって決定される。いくつかの例は、以下を含む。
●サンプル境界および時間における線形増加(たとえば、図17Aに示すように)
●完全なセグメントが、プレイアウトのために必要である。
●復号およびプレゼンテーション順序のためのより複雑な構造は、たとえば、階層状のBピクチャが使われるとき、同一でない。
●サンプル境界および時間における線形増加(たとえば、図17Aに示すように)
●完全なセグメントが、プレイアウトのために必要である。
●復号およびプレゼンテーション順序のためのより複雑な構造は、たとえば、階層状のBピクチャが使われるとき、同一でない。
2つの異なるプレイアウト曲線を、図17Bに示す。x軸は、プレゼンテーション時間(PT)から、セグメントの最も早いプレゼンテーション時間(EPT)を引いたものを示す。EPTを再生するために、一定の量のバイトが必要である。破線曲線は、EPTをもつサンプルを再生するのにセグメントのすべてのバイトを求めるが、実線曲線は、再生し始めるのに、小さい部分を必要とするだけであり、幾分多くのデータが続く。プレイアウト曲線は、典型的な階段ケースである。
ネットワークは、曲線を認識している場合、ネットワークが、クライアントがいつEPTを受信する必要があるかも知っていると仮定すると、データの適時受信を保証するために、関連するバイト範囲の配信を最適化することができる。これは、たとえば、図9および図10に関して上で論じた技法によって遂行され得る。
図18は、セグメントのデータを配信するためのメディア配信イベント(MDE)の概念図である。IP/UDP/ROUTE中にカプセル化されているランダムアクセスポイント(RAP)で始まるMDEは、T-RAPで始まるT-MDEになる。
図19は、起こり得る簡略化した例において本開示の技法を実施するのに使われ得る別の例示的なシステム390を示す概念図である。この例では、システム390は、ROUTE受信機および出力バッファ392、ISO BMFFバッファ396、ISO BMFFデコーダ398、DASHクライアント394、ならびにCDN404を含む。概して、ROUTE受信機および出力バッファ392は、RAPパケット400およびメディアデータを含むパケット402A、402Bを、ROUTEを介して受信する。追加または代替として、DASHクライアント394は、HTTPなどのユニキャストプロトコルにより、CDN404からセグメントを取り出す。したがって、特定のセグメントを受信する、ROUTE受信機および出力バッファ392またはDASHクライアント394のうちの1つが、ISO BMFFバッファ396にセグメントを提供する。ISO BMFFデコーダ398は、ISO BMFFレベルでの復号のために、たとえば、オーディオデコーダまたはビデオデコーダなど、対応するメディアデコーダによって復号されるべきPESパケットを抽出するために、ISO BMFFバッファ396からセグメントを取り出す。この例では、下位レイヤシグナリングが、MPD406なしでサービスを開始するのに十分な情報を提供する。ユニキャストが追加された場合のみ、またはより豊富な選択が必要な場合、MPD406が照会される。依然として、統合MPD406が存在するが、MPD406は、スタートアップおよび/またはブロードキャストのみのために必要なわけではない。
図20は、本開示の技法による例示的な配信アーキテクチャ410の概念図である。この例では、配信アーキテクチャ410は、ISO BMFFおよびビデオエンコーダ412、セグメンタおよびROUTE送付機412、ならびに送付スケジューラ414をサーバ/送付機側に、ROUTE受信機および出力バッファ416、ISO BMFFバッファ418、ならびにISO BMFFデコーダ420をクライアント/受信機側に含む。概して、ISO BMFFおよびビデオエンコーダ412は、セグメンタおよびROUTE送付機412にISO BMFFストリーム422を送る。セグメンタおよびROUTE送付機412は、ISO BMFFストリーム422をそれぞれのパケット426A、426B(パケット426)およびランダムアクセスポイント(RAP)パケット424に分割し、パケット424、426を送付スケジューラ414に送る。
送付スケジューラ414は、ROUTE受信機および出力バッファ416にパケット424、426をいつ送るかを判断する。パケットを送った後、ROUTE受信機および出力バッファ416は、送付スケジューラ414からパケット424、426を受信する。ROUTE受信機および出力バッファ416は、復号およびプレゼンテーションを始動し、スケジュールするための情報430をISO BMFFデコーダ420に送る。ROUTE受信機および出力バッファ416はまた、パケット424、426からISO BMFFストリーム422を再構築し、ISO BMFFストリーム422をISO BMFFバッファ418に送る。ISO BMFFデコーダ420は、たとえば、たとえばオーディオおよびビデオデコーダ(図20には示さず)によって復号されるべきメディアデータを含むPESパケットを抽出するために、ISO BMFFレベルで復号されるべきメディアデータ428を、ISO BMFFバッファ418からフェッチする。
プログレッシブプレイアウトを使うための使用ケースの様々な例について、以下で論じる。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。プログレッシブプレイアウトについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインとともにプログレッシブプレイアウトについての情報は、いくつかのオブジェクトの緊急部分の適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインおよびプログレッシブプレイアウトについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。図20は、そのようなケースのための起こり得る配信アーキテクチャを示す。セグメンタおよびROUTE送付機412は、パケッタイザとして作用し得る。さらに、この例では、セグメンタおよびROUTE送付機412は、ATSCにおいて定義されているROUTEを使い、パケットがROUTE受信機および出力バッファ416に送られ/それによって受信される目標時間を追加するために、送付機からの(プログレッシブプレイアウト)、および可能性としては受信機からの情報(デッドライン情報)を使うことができる。こうすることにより、ネットワークは、この情報を、たとえば、ISO BMFFバッファ418についてバッファアンダーランがないことを保証するのに使うことができる。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。プログレッシブプレイアウトについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインとともにプログレッシブプレイアウトについての情報は、いくつかのオブジェクトの緊急部分の適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインおよびプログレッシブプレイアウトについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。図20は、そのようなケースのための起こり得る配信アーキテクチャを示す。セグメンタおよびROUTE送付機412は、パケッタイザとして作用し得る。さらに、この例では、セグメンタおよびROUTE送付機412は、ATSCにおいて定義されているROUTEを使い、パケットがROUTE受信機および出力バッファ416に送られ/それによって受信される目標時間を追加するために、送付機からの(プログレッシブプレイアウト)、および可能性としては受信機からの情報(デッドライン情報)を使うことができる。こうすることにより、ネットワークは、この情報を、たとえば、ISO BMFFバッファ418についてバッファアンダーランがないことを保証するのに使うことができる。
図21は、本開示の技法による受信機モデルの例の2つの概念図を示す。モデル440の例は、ROUTE受信機および出力バッファ442、ISO BMFFバッファ444、ならびにISO BMFFデコーダ446を含む。ROUTE受信機および出力バッファ442は、パケット448、450を受信する。ROUTE受信機および出力バッファ442は、復号およびプレゼンテーションを始動し、スケジュールするための情報456をISO BMFFデコーダ446に送る。ROUTE受信機および出力バッファ442はまた、パケット448、450からISO BMFFストリーム452を再構築し、ISO BMFFストリーム452をISO BMFFバッファ444に送る。ISO BMFFデコーダ446は、たとえば、たとえばオーディオおよびビデオデコーダ(図21のモデル440には示さず)によって復号されるべきメディアデータを含むPESパケットを抽出するために、ISO BMFFレベルで復号されるべきメディアデータ454を、ISO BMFFバッファ444からフェッチする。
モデル460の例は、ROUTE受信機および出力バッファ462、MSEバッファ464、ブラウザおよびJava(登録商標)スクリプトユニット478、ならびにプレイアウトユニット466を含む。ROUTE受信機および出力バッファ462は、パケット468、470を受信する。ROUTE受信機および出力バッファ462は、復号およびプレゼンテーションを始動し、スケジュールするための情報476をISO BMFFデコーダ446に送る。Java(登録商標)スクリプトを(たとえば、ブラウザ478へのプラグインとして)も実行するプロセッサによって実行されるブラウザ478は、ROUTE受信機および出力バッファ462からメディアユニットを抽出し、メディアユニットをMSEバッファ464に配信する。プレイアウトユニット466は、復号され、提示されるべきメディアデータ474を、ISO BMFFバッファ444からフェッチする。
上記使用ケースおよびシナリオに対処するために、以下の拡張が提供され、本開示の様々なユニットおよび構成要素によって使われ得る。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。つまり、受信機(特に、受信機のプロセッサ)は、状況メッセージ中で、絶対デッドラインを壁時計時間で指定し、この状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●要求されたオブジェクトについての最大ラウンドトリップ時間(RTT)(持続時間)を提供するための状況メッセージ。つまり、受信機は、状況メッセージ中で、最大RTTを指定し、このメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。つまり、受信機は、1つまたは複数のPEDメッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらのPEDメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。つまり、受信機は、1つまたは複数の状況メッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらの状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。つまり、受信機(特に、受信機のプロセッサ)は、状況メッセージ中で、絶対デッドラインを壁時計時間で指定し、この状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●要求されたオブジェクトについての最大ラウンドトリップ時間(RTT)(持続時間)を提供するための状況メッセージ。つまり、受信機は、状況メッセージ中で、最大RTTを指定し、このメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。つまり、受信機は、1つまたは複数のPEDメッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらのPEDメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。つまり、受信機は、1つまたは複数の状況メッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらの状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
AbsoluteDeadlineパラメータが、デッドライン情報中で指定され得る。このパラメータにより、DASHクライアントは、セグメントが受信される必要がある、壁時計時間での絶対デッドラインをDANEキャッシュに指示することができる。
AbsoluteDeadlineパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
以下のテーブルは、AbsoluteDeadlineパラメータ用の例示的なデータ表現を表す。
絶対的な時間のフォーマット用に、基本的には、以下のフォーマットのうちのどれが使われてもよい。絶対的な時間のフォーマットについての例は、以下を含む。
●xsdateフォーマット
●ISOタイミングフォーマット
●NTPフォーマット
●xsdateフォーマット
●ISOタイミングフォーマット
●NTPフォーマット
要求中で拡張ヘッダ(またはヘッダ拡張)を定義するための例示的なやり方は、次のようになる。
X-Dash-Deadline-ISO:<ISOフォーマットでの時間>
X-Dash-Deadline-ISO:<ISOフォーマットでの時間>
一例は次の通りである。
X-Dash-Deadline-ISO:2015-10-11T17:53:03Z
X-Dash-Deadline-ISO:2015-10-11T17:53:03Z
追加または代替として、最大ラウンドトリップ時間(MaxRTT)パラメータが、デッドライン情報中で指定され得る。このパラメータにより、DASHクライアントは、要求が発行された時間から、要求されたデータがDASHクライアントにおいて完全に利用可能になる必要があるときまでの、要求の最大ラウンドトリップ時間をDANEキャッシュに指示することができる。時間はmsで表され得る。
MaxRTTパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
以下のテーブルは、MaxRTTパラメータ用の例示的なデータ表現を表す。
要求中で拡張ヘッダを定義するための例示的なやり方は、次のようになる。
X-Dash-MaxRTT:<msでの最大ラウンドトリップ時間>
X-Dash-MaxRTT:<msでの最大ラウンドトリップ時間>
一例は次の通りである。
X-Dash-MaxRTT:2345
X-Dash-MaxRTT:2345
この例は、バッファアンダーフローを避けるために、クライアントが、要求を発行してから2.345秒後に、セグメントの利用可能性を要求することを表す。
追加または代替として、デッドライン情報は、プログレッシブプレイアウトプロファイルメトリック(ProgressivePlayout)パラメータを含み得る。このパラメータにより、DASHクライアントは、セグメントのプログレッシブプレイアウトプロファイルをDANEキャッシュに指示することができる。
ProgressivePlayoutパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
以下のテーブルは、ProgressivePlayoutパラメータ用の例示的なデータ表現を表す。
要求中で拡張ヘッダを定義するための例示的なやり方は、次のようになる。
X-Dash-Progressive-Playout:<バイトおよびmsでの時間のタプル>
X-Dash-Progressive-Playout:<バイトおよびmsでの時間のタプル>
一例は次の通りである。
X-Dash-Progressive-Playout:<4321,0;62345,200;82220,400;1010101,600;121212,800;1313131;1000>
X-Dash-Progressive-Playout:<4321,0;62345,200;82220,400;1010101,600;121212,800;1313131;1000>
この例は、プレイアウトを始動するために、4321バイトが配信される必要があることと、次いで、プレイアウト時間の各々についてのバイトの総量とを表す。ステップは、デルタとしても表され得ることに留意されたい。
ProgressivePlayout情報は、追加または代替として、応答とともに拡張ヘッダとして配信され得る。
デッドライン情報をこのようにしてシグナリングすると、メディアデータなど、リアルタイム制約を有するデータの適時配信を保証することができる。たとえば、デッドライン情報をDANEに提供することによって、DANEは、リアルタイム制約に従ってクライアントデバイスにデータが配信されることを保証することができる。したがって、DASHまたはメディアデータの他のストリーミングに関して、クライアントデバイスはバッファアンダーフローを避けることができ、これは、連続した、平滑なプレイアウトを保証することができる。
図22は、本開示の技法を実施するための例示的な方法を示すフローチャートである。図22の技法は、図1のサーバデバイス60およびクライアントデバイス40に関して記載される。ただし、これらまたは同様の技法は、たとえば、図5のクライアントデバイス210およびメディアオリジンサーバデバイス206またはHTTPキャッシュサーバデバイス208、図6のクライアントデバイス222およびCDN220のサーバ、図7のDASHクライアント240およびHTTPサーバ232、図8のDASHクライアント270およびHTTPサーバ262またはDANE282、図9のダウンロードエンジン292、図11のクライアントデバイス302およびDASHサーバデバイス304またはDANE306、図12のクライアントデバイス332およびeノードB340またはHTTPプロキシ/キャッシュ344、図13のクライアントデバイス358およびeノードB356またはDASHサーバ352、図14のクライアントデバイス362およびeノードB370/HTTPプロキシ/キャッシュ372、図19のシステム390に従って構成されたクライアントデバイス、図20の、セグメンタおよびROUTE送付機412と送付スケジューラ414とを含むサーバデバイスならびにROUTE受信機および出力バッファ416と、ISO BMFFバッファ418と、ISO BMFFデコーダ420とを含むクライアントデバイス、または図21のモデル440もしくは460のいずれかの、構成要素を含むクライアントデバイスなど、本明細書に示す他のデバイスによって実施され得ることを理解されたい。
この例では、サーバデバイス60が、セグメントが利用可能になる壁時計時間を指定する情報を含むメディアプレゼンテーション記述(MPD)(または、他の例では他のマニフェストファイル)を最初に準備し、または受信すると推定される。したがって、クライアントデバイス40は、サーバデバイス60に対してMPDを要求する(480)。サーバデバイス60は、MPDについての要求を受信し(482)、それに応答して、クライアントデバイス40にMPDを送る(484)。したがって、クライアントデバイス40はMPDを受信する(486)。
クライアントデバイス40は、たとえば、クライアントデバイス40の復号およびレンダリング能力(たとえば、オーディオデコーダ46およびビデオデコーダ48の復号能力、オーディオ出力42およびビデオ出力44のレンダリング能力、ならびにたとえば、様々な適応セットについてのプロファイル、ティア、および/またはレベルシグナリング情報中で指定された復号およびレンダリング要件)に従って、メディアデータをそこから取り出すべき1つまたは複数の適応セットを判断するのに、MPDを使う。クライアントデバイス40は次いで、セグメントをそれに対して要求するべき適応セットの各々の表現を、たとえば、ネットワーク帯域幅の利用可能量に基づいて選択すればよい。クライアントデバイス40は次いで、選択された表現のセグメントを要求し始め、セグメントを受信し、受信されたときにセグメントをバッファリングしてよい。
さらに、本開示の技法によると、クライアントデバイス40は、MPDからセグメント利用可能性時間を判断することができる(488)。クライアントデバイス40は、まだ利用可能でないセグメントを要求するのを避けるために、セグメントが取出しのためにいつ利用可能であるかを判断するのに、セグメント利用可能性時間を使うことができる。さらに、クライアントデバイス40は、プレイアウトレートおよびバッファ充填レベルを判断することができる(490)。つまり、クライアントデバイス40は、メディアデータの再生により、どれだけ急速にバッファが空にされているかを追跡し、また、バッファの現在の充填レベルを監視することができる。この情報に基づいて、クライアントデバイス40は、バッファアンダーランを避けるために、次のセグメントが受信されなければならないときを判断することができる(492)。他の例では、クライアントデバイス40は、バイト範囲など、セグメントのある部分が受信されなければならないときを判断することができ、セグメントの異なる部分(たとえば、バイト範囲)について異なる値を判断する場合がある。概して、クライアントデバイス40は、セグメント(またはその部分)が受信されなければならない時間を、公式
Deadline=CurrentTime-FillLevel/PlaybackRate
に従って算出することができ、上式で、Deadlineは、次のセグメントが受信されなければならない、壁時計時間での時間であり、CurrentTimeは、壁時計時間での現在時間であり、FillLevelは、バッファに記憶されたデータの量であり、PlaybackRateはメディアデータの再生レートである。
Deadline=CurrentTime-FillLevel/PlaybackRate
に従って算出することができ、上式で、Deadlineは、次のセグメントが受信されなければならない、壁時計時間での時間であり、CurrentTimeは、壁時計時間での現在時間であり、FillLevelは、バッファに記憶されたデータの量であり、PlaybackRateはメディアデータの再生レートである。
したがって、次のセグメントが利用可能なとき、クライアントデバイス40は、(たとえば、HTTP GETまたは部分GET要求を使って)次のセグメントを要求してよく、バッファアンダーランを避けるためにセグメント(またはその部分)が受信されなければならない時間を表すデッドライン情報をさらに送ることができる(494)。いくつかの例では、クライアントデバイス40は、要求自体にデッドライン情報を、たとえば、上述したように、属性としてHTTPヘッダ拡張中に、またはセグメント用のURLの引数もしくは要素として、要求を含むパケットのヘッダ中などに含めてよい。代替として、クライアントデバイス40は、やはり上で論じたように、デッドライン情報をサイド情報として指定してよい。さらに、デッドライン情報は、上で論じた値「Deadline」であってよく、または単に、サーバデバイス60(DANE、eノードB、HTTPプロキシ/キャッシュなどのような中間デバイスを表し得る)がデッドライン値を、たとえば、上の公式に従って算出することができるように、クライアントデバイス40によって判断されたバッファ充填レベル、現在時間用のタイムスタンプ、および/もしくは再生レート情報を含んでよい。
サーバデバイス60は次いで、セグメントについての要求を受信し得る(496)。サーバデバイス60は次いで、たとえば、要求自体から、またはクライアントデバイス40から受信されたサイド情報から、セグメントについてのデッドライン情報を判断することができる(498)。サーバデバイス60は次いで、要求されたセグメント(またはその部分、たとえば、セグメントの要求されたバイト範囲)の配信を、デッドライン情報に従って優先してよい(500)。たとえば、サーバデバイス60は、データがクライアントデバイス40に到着するためのラウンドトリップ時間を判断し、要求されたセグメント(またはそのバイト範囲)の配信を、データが受信されなければならないデッドラインに先んじてラウンドトリップ時間の少なくとも半分であるときにスケジュールすることができる。サーバデバイス60は次いで、要求されたセグメント(またはその部分)を、デッドライン情報(つまり、優先度付け)に従って送ってよい(502)。
最終的に、クライアントデバイス40は、バッファアンダーランを避けるためにセグメントが必要とされるデッドラインに、またはその前にセグメントを受信し得る(504)。したがって、クライアントデバイス40は、後続プレイアウトのために、セグメントをバッファに追加することができる(506)。後で、セグメントよりも前の、バッファ中のデータがバッファから抽出されてから、セグメントは、抽出され、復号され、プレイアウトされ、そのときまでに追加データが(たとえば、ステップ488〜504の技法に従って)取り出されてしまってよく、やはりバッファアンダーランを防止するために、バッファリングされる。
このように、図22は、データがダウンロードのために利用可能である時間を判断するステップと、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するステップと、データが利用可能であるとき、データについての要求およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るステップとを含む方法の例を表す。
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このように、コンピュータ可読媒体は、一般に、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コード、および/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品が、コンピュータ可読媒体を含む場合がある。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路機構もしくは個別論理回路機構などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指すことがある。加えて、いくつかの態様では、本明細書で説明された機能性は、符号化および復号のために構成された専用のハードウェアモジュールおよび/もしくはソフトウェアモジュール内で提供され得、または複合コーデックに組み込まれ得る。また、技法は、1つまたは複数の回路または論理要素で完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装され得る。開示された技法を実施するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが本開示に記載されているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明されたように、様々なユニットが、好適なソフトウェアおよび/またはファームウェアとともに、上記で説明された1つまたは複数のプロセッサを含んで、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作可能なハードウェアユニットの集合体によって与えられ得る。
様々な例について述べた。これらおよび他の例は、以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A〜68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 eMBMSミドルウェアユニット
102 サーバユニット、ローカルサーバユニット
104 キャッシュ
106 eMBMS受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
122 メディアプレゼンテーション記述(MPD)
124 表現
124A 表現
124N 表現
126 ヘッダデータ
128 セグメント
128A〜128N セグメント
130 ヘッダデータ
132 セグメント
132A〜132N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 ムービー(MOOV)ボックス
156 ムービーヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 ムービー延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 ムービーフラグメント(MOOF)ボックス
166 ムービーフラグメントランダムアクセス(MFRA)ボックス
200 システム
202 キャプチャデバイス
204 符号化および暗号化デバイス
206 メディアオリジンサーバデバイス
206A〜206N メディアオリジンサーバデバイス
208 HTTPキャッシュサーバデバイス
208A〜208N HTTPキャッシュサーバデバイス
210 クライアントデバイス
210A〜210N クライアントデバイス
212 デジタル著作権管理(DRM)ライセンスサーバデバイス
212A〜212N デジタル著作権管理(DRM)ライセンスサーバデバイス
220 コンテンツ分配ネットワーク(CDN)
222 クライアントデバイス
230 システム
232 HTTPサーバ
234A メディアコンテンツ
234B メディアコンテンツ
236 MPD
236A MPD
236B MPD
238 セグメント
238A セグメント
238B セグメント
240 DASHクライアント
242 制御エンジン
244 メディアエンジン
246 MPDパーサ
248 セグメントパーサ
250 HTTPクライアント
260 システム
262 HTTPサーバ
264A メディアデータ
266A MPD
268A セグメント
264B メディアデータ
266B MPD
268B セグメント
270 DASHクライアント
272 制御エンジン
274 メディアエンジン
276 MPDパーサ
278 セグメントパーサ
280 HTTPクライアント
282 DASHアウェアネットワーク要素(DANE)デバイス、DANE
284 下位レイヤトランスポート
290 クライアントモデル
292 ダウンロードエンジン
294 バッファ
296 メディアデコーダおよびレンダラ
300 システム
302 クライアントデバイス
304 DASHサーバデバイス
306 DANE
308 パケットゲートウェイ(PGW)デバイス
310 eノードB
330 システム
332 クライアントデバイス
334 HTTPクライアント
336 モデム
338 キャッシュ
340 eノードB
342 パケットゲートウェイ(PGW)/サービングゲートウェイ(SGW)
344 HTTPプロキシ/キャッシュ
346 CDN
348 Gi-LANインターフェース
350 システム
352 DASHサーバ
354 PGW
356 eノードB
358 クライアントデバイス
360 システム
362 クライアントデバイス
364 HTTPクライアント
366 モデム
368 キャッシュ
370 eノードB
372 HTTPプロキシ/キャッシュ
374 HTTPプロキシ
376 PGW/SGW
378 CDN
380 セグメント
382 初期化セグメント(IS)、セグメント
384 メディアセグメント(MS)、セグメント
384A〜384G メディアセグメント(MS)
390 システム
392 ROUTE受信機および出力バッファ
394 DASHクライアント
396 ISO BMFFバッファ
398 ISO BMFFデコーダ
400 RAPパケット
402A パケット
402B パケット
404 CDN
406 MPD
410 配信アーキテクチャ
412 ISO BMFFおよびビデオエンコーダ
412 セグメンタおよびROUTE送付機
414 送付スケジューラ
416 ROUTE受信機および出力バッファ
418 ISO BMFFバッファ
420 ISO BMFFデコーダ
422 ISO BMFFストリーム
424 ランダムアクセスポイント(RAP)パケット、パケット
426 パケット
426A パケット
426B パケット
428 メディアデータ
430 情報
440 モデル
442 ROUTE受信機および出力バッファ
444 ISO BMFFバッファ
446 ISO BMFFデコーダ
448 パケット
450 パケット
452 ISO BMFFストリーム
454 メディアデータ
456 情報
460 モデル
462 ROUTE受信機および出力バッファ
464 MSEバッファ
466 プレイアウトユニット
468 パケット
470 パケット
474 メディアデータ
476 情報
478 ブラウザおよびJava(登録商標)スクリプトユニット、ブラウザ
466 プレイアウトユニット
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A〜68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 eMBMSミドルウェアユニット
102 サーバユニット、ローカルサーバユニット
104 キャッシュ
106 eMBMS受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
122 メディアプレゼンテーション記述(MPD)
124 表現
124A 表現
124N 表現
126 ヘッダデータ
128 セグメント
128A〜128N セグメント
130 ヘッダデータ
132 セグメント
132A〜132N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 ムービー(MOOV)ボックス
156 ムービーヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 ムービー延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 ムービーフラグメント(MOOF)ボックス
166 ムービーフラグメントランダムアクセス(MFRA)ボックス
200 システム
202 キャプチャデバイス
204 符号化および暗号化デバイス
206 メディアオリジンサーバデバイス
206A〜206N メディアオリジンサーバデバイス
208 HTTPキャッシュサーバデバイス
208A〜208N HTTPキャッシュサーバデバイス
210 クライアントデバイス
210A〜210N クライアントデバイス
212 デジタル著作権管理(DRM)ライセンスサーバデバイス
212A〜212N デジタル著作権管理(DRM)ライセンスサーバデバイス
220 コンテンツ分配ネットワーク(CDN)
222 クライアントデバイス
230 システム
232 HTTPサーバ
234A メディアコンテンツ
234B メディアコンテンツ
236 MPD
236A MPD
236B MPD
238 セグメント
238A セグメント
238B セグメント
240 DASHクライアント
242 制御エンジン
244 メディアエンジン
246 MPDパーサ
248 セグメントパーサ
250 HTTPクライアント
260 システム
262 HTTPサーバ
264A メディアデータ
266A MPD
268A セグメント
264B メディアデータ
266B MPD
268B セグメント
270 DASHクライアント
272 制御エンジン
274 メディアエンジン
276 MPDパーサ
278 セグメントパーサ
280 HTTPクライアント
282 DASHアウェアネットワーク要素(DANE)デバイス、DANE
284 下位レイヤトランスポート
290 クライアントモデル
292 ダウンロードエンジン
294 バッファ
296 メディアデコーダおよびレンダラ
300 システム
302 クライアントデバイス
304 DASHサーバデバイス
306 DANE
308 パケットゲートウェイ(PGW)デバイス
310 eノードB
330 システム
332 クライアントデバイス
334 HTTPクライアント
336 モデム
338 キャッシュ
340 eノードB
342 パケットゲートウェイ(PGW)/サービングゲートウェイ(SGW)
344 HTTPプロキシ/キャッシュ
346 CDN
348 Gi-LANインターフェース
350 システム
352 DASHサーバ
354 PGW
356 eノードB
358 クライアントデバイス
360 システム
362 クライアントデバイス
364 HTTPクライアント
366 モデム
368 キャッシュ
370 eノードB
372 HTTPプロキシ/キャッシュ
374 HTTPプロキシ
376 PGW/SGW
378 CDN
380 セグメント
382 初期化セグメント(IS)、セグメント
384 メディアセグメント(MS)、セグメント
384A〜384G メディアセグメント(MS)
390 システム
392 ROUTE受信機および出力バッファ
394 DASHクライアント
396 ISO BMFFバッファ
398 ISO BMFFデコーダ
400 RAPパケット
402A パケット
402B パケット
404 CDN
406 MPD
410 配信アーキテクチャ
412 ISO BMFFおよびビデオエンコーダ
412 セグメンタおよびROUTE送付機
414 送付スケジューラ
416 ROUTE受信機および出力バッファ
418 ISO BMFFバッファ
420 ISO BMFFデコーダ
422 ISO BMFFストリーム
424 ランダムアクセスポイント(RAP)パケット、パケット
426 パケット
426A パケット
426B パケット
428 メディアデータ
430 情報
440 モデル
442 ROUTE受信機および出力バッファ
444 ISO BMFFバッファ
446 ISO BMFFデコーダ
448 パケット
450 パケット
452 ISO BMFFストリーム
454 メディアデータ
456 情報
460 モデル
462 ROUTE受信機および出力バッファ
464 MSEバッファ
466 プレイアウトユニット
468 パケット
470 パケット
474 メディアデータ
476 情報
478 ブラウザおよびJava(登録商標)スクリプトユニット、ブラウザ
466 プレイアウトユニット
Claims (36)
- リアルタイム制約を有するデータを取り出す方法であって、クライアントデバイスのデジタル論理回路機構を備えるハードウェアベースのプロセッサによって実行されるリアルタイムのアプリケーションによって、
前記データがダウンロードのために利用可能である時間を判断するステップと、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断するステップと、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るステップとを含む方法。 - 前記データが利用可能である前記時間を判断するステップは、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断するステップを含む、請求項1に記載の方法。
- 前記マニフェストファイルは、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーション記述(MPD)を含む、請求項2に記載の方法。
- 前記要求および前記デッドライン情報を送るステップは、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するステップを含む、請求項1に記載の方法。
- 前記要求および前記デッドライン情報を送るステップは、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
- 前記要求を送るステップは、ストリーミングアウェアネットワーク要素、DASHアウェアネットワーク要素(DANE)、DASHサーバ、モバイルセルサイト、またはワイヤレスアクセスポイントのうちの少なくとも1つに前記要求を送るステップを含む、請求項1に記載の方法。
- 前記デッドライン情報を判断するステップをさらに含み、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項1に記載の方法。
- 前記デッドライン情報を判断するステップをさらに含み、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項1に記載の方法。
- プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るステップをさらに含む、請求項1に記載の方法。
- 前記要求を送るステップは、前記要求をストリーミングアウェアネットワーク要素に送るステップを含み、前記方法は、前記要求および前記デッドライン情報を送ったことに応答して、前記データが必要とされる前記時間に、またはその前に、前記ストリーミングアウェアネットワーク要素から前記データを受信するステップをさらに含む、請求項1に記載の方法。
- 前記データは、リアルタイムのメディアデータ、ストリーミングメディアデータ、メディアセグメント、またはメディアサブセグメントのうちの少なくとも1つを含む、請求項1に記載の方法。
- 前記データはメディアセグメントを含み、前記デッドライン情報を送るステップは、前記データがフルセグメントとして、それとも複数のメディア配信イベント(MDE)として受信されるべきかを表すデータを送るステップを含む、請求項1に記載の方法。
- 前記デッドライン情報を送るステップは、前記ストリーミングサーバに、前記デッドライン情報をストリーミングアウェアネットワーク要素へフォワードさせるために、ハイパーテキスト転送プロトコル(HTTP)によりストリーミングサーバに前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
- 前記デッドライン情報を送るステップは、無線アクセスネットワーク(RAN)を介して直接、ストリーミングアウェアネットワーク要素に前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
- リアルタイム制約を有するデータを取り出すためのクライアントデバイスであって、
前記リアルタイム制約を有する前記データをバッファリングするためのバッファを備えるメモリと、
デジタル論理回路機構を備えるハードウェアベースのプロセッサとを備え、前記プロセッサは、リアルタイムのアプリケーションを実行するように構成され、前記アプリケーションは、
前記データがダウンロードのために利用可能である時間を判断し、
前記バッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断し、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るように構成される、クライアントデバイス。 - 前記リアルタイムのアプリケーションは、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから、前記データがダウンロードのために利用可能である前記時間を判断するように構成される、請求項15に記載のクライアントデバイス。
- 前記リアルタイムのアプリケーションは、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するように構成される、請求項15に記載のクライアントデバイス。
- 前記リアルタイムのアプリケーションは、前記デッドライン情報を、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で送るように構成される、請求項15に記載のクライアントデバイス。
- 前記リアルタイムのアプリケーションは、前記デッドライン情報を判断するように構成され、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項15に記載のクライアントデバイス。
- 前記リアルタイムのアプリケーションは、前記デッドライン情報を判断するように構成され、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項15に記載のクライアントデバイス。
- 前記リアルタイムのアプリケーションは、プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るようにさらに構成される、請求項15に記載のクライアントデバイス。
- リアルタイム制約を有するデータを取り出すためのデバイスであって、
前記データがダウンロードのために利用可能である時間を判断するための手段と、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断するための手段と、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るための手段とを備えるデバイス。 - 前記データが利用可能である前記時間を判断するための前記手段は、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断するための手段を備える、請求項22に記載のデバイス。
- 前記要求および前記デッドライン情報を送るための前記手段は、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するための手段を備える、請求項22に記載のデバイス。
- 前記要求および前記デッドライン情報を送るための前記手段は、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送るための手段を備える、請求項22に記載のデバイス。
- 前記デッドライン情報を判断するための手段をさらに備え、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項22に記載のデバイス。
- 前記デッドライン情報を判断するための手段をさらに備え、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項22に記載のデバイス。
- プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るための手段をさらに備える、請求項22に記載のデバイス。
- 命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されると、クライアントデバイスのプロセッサに、
前記データがダウンロードのために利用可能である時間を判断させ、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断させ、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送らせる、コンピュータ可読記憶媒体。 - 前記プロセッサに、前記データが利用可能である前記時間を判断させる前記命令は、前記プロセッサに、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断させる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに、前記要求および前記デッドライン情報を送らせる前記命令は、前記プロセッサに、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定させる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに、前記要求および前記デッドライン情報を送らせる前記命令は、前記プロセッサに、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送らせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに前記要求を送らせる前記命令は、前記プロセッサに、ストリーミングアウェアネットワーク要素、DASHアウェアネットワーク要素(DANE)、DASHサーバ、モバイルセルサイト、またはワイヤレスアクセスポイントのうちの少なくとも1つへ前記要求を送らせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに前記デッドライン情報を判断させる命令をさらに含み、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに前記デッドライン情報を判断させる命令をさらに含み、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項29に記載のコンピュータ可読記憶媒体。
- 前記プロセッサに、プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送らせる命令をさらに含む、請求項29に記載のコンピュータ可読記憶媒体。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2015/092095 WO2017063189A1 (en) | 2015-10-16 | 2015-10-16 | Deadline signaling for streaming of media data |
| CNPCT/CN2015/092095 | 2015-10-16 | ||
| PCT/CN2016/102194 WO2017063592A1 (en) | 2015-10-16 | 2016-10-14 | Deadline signaling for streaming of media data |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2018532334A true JP2018532334A (ja) | 2018-11-01 |
Family
ID=58517016
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018518703A Pending JP2018532334A (ja) | 2015-10-16 | 2016-10-14 | メディアデータのストリーミングのためのデッドラインシグナリング |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US12088652B2 (ja) |
| EP (1) | EP3363181B1 (ja) |
| JP (1) | JP2018532334A (ja) |
| CN (1) | CN108141455B (ja) |
| TW (1) | TW201729601A (ja) |
| WO (2) | WO2017063189A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2024510139A (ja) * | 2021-10-06 | 2024-03-06 | テンセント・アメリカ・エルエルシー | メディアストリーミング及び再生中のプレロール及びミッドロールをサポートするための方法、装置及びコンピュータプログラム |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6663082B2 (ja) * | 2016-11-10 | 2020-03-11 | ソニーモバイルコミュニケーションズ株式会社 | ノードタイプに基づくデータストリーミングの支援制御 |
| GB2563251A (en) * | 2017-06-07 | 2018-12-12 | Sony Mobile Communications Inc | Terminal device, data processing apparatuses and methods |
| US10404766B2 (en) * | 2017-12-07 | 2019-09-03 | Mcom Media Communications Dmcc | Managing content casting |
| WO2019148498A1 (en) * | 2018-02-05 | 2019-08-08 | Telefonaktiebolaget Lm Ericsson (Publ) | A method, a user equipment and a computer program product for enabling a dynamic adaptive streaming over http, dash, player to fetch media segments from a network |
| CN108600377B (zh) * | 2018-04-28 | 2021-04-27 | 武汉斗鱼网络科技有限公司 | 一种文件下载的暂停方法、装置、终端和存储介质 |
| JP7116196B2 (ja) | 2018-06-07 | 2022-08-09 | ソニーグループ株式会社 | ネットワーク容量に制約のあるシナリオにおける共同メディア制作のためのネットワーク制御上りリンクメディア伝送 |
| US11368512B2 (en) | 2018-08-20 | 2022-06-21 | Sony Group Corporation | Method and system for utilizing network conditions feedback for improving quality of a collaborative media production |
| CN112585922B (zh) | 2018-08-20 | 2023-05-23 | 索尼公司 | 提供辅助的方法、提供信息的方法、流传输的方法和设备 |
| EP3852380B1 (en) * | 2018-11-08 | 2024-05-01 | SK Telecom Co., Ltd. | Method and device for switching media service channels |
| US11199994B1 (en) * | 2018-11-14 | 2021-12-14 | Amazon Technologies, Inc. | Decoupling data request rate from hardware medium for archival data storage devices |
| FR3094597B1 (fr) * | 2019-03-27 | 2021-06-11 | Streamroot | Procédé de diffusion de contenus en streaming dans un réseau pair à pair |
| GB2586442B (en) * | 2019-06-26 | 2024-03-27 | Univ Dublin City | A method and system for encoding and decoding to enable adaptive delivery of mulsemedia streams |
| US11831879B2 (en) * | 2019-09-20 | 2023-11-28 | Comcast Cable Communications, Llc | Methods, systems, and apparatuses for enhanced adaptive bitrate segmentation |
| CN113038245B (zh) * | 2019-12-24 | 2023-07-21 | 瑞昱半导体股份有限公司 | 多媒体内容播放装置与多媒体内容播放方法 |
| CA3126585A1 (en) * | 2020-08-03 | 2022-02-03 | Comcast Cable Communications, Llc | Video content processing systems and methods |
| EP4260624B1 (en) * | 2020-12-08 | 2024-09-25 | Nokia Technologies Oy | Method and apparatus for use in a data pulling operation |
| US12346291B2 (en) * | 2021-11-03 | 2025-07-01 | Vimeo.Com, Inc. | On-the-fly/transparent fragmented ISOBMFF to progressive ISOBMFF transmultiplexing proxy |
| US20230275977A1 (en) * | 2022-02-28 | 2023-08-31 | Comcast Cable Communications, Llc | Methods, systems, and apparatuses for signaling server-associated delays in content delivery |
| US20230345298A1 (en) * | 2022-04-25 | 2023-10-26 | Qualcomm Incorporated | Deadline-based data packets |
| US12034790B1 (en) * | 2023-04-28 | 2024-07-09 | Directv, Llc | Methods and apparatus for asynchronous media requests |
| WO2025122778A1 (en) * | 2023-12-07 | 2025-06-12 | Netflix, Inc. | Techniques for simulating a live edge in a live field test |
| US12457259B2 (en) | 2024-03-06 | 2025-10-28 | Comcast Cable Communications, Llc | Methods, systems, and apparatuses to mitigate server-associated delays in content delivery |
| CN120639765B (zh) * | 2025-08-15 | 2025-11-25 | 上海卫星互联网研究院有限公司 | 下载文件的方法及系统 |
Family Cites Families (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7633945B1 (en) * | 1999-02-09 | 2009-12-15 | Sony Corporation | Information distribution system, terminal device, server device, method of data reception and method of data transmission |
| US6988144B1 (en) | 1999-11-18 | 2006-01-17 | International Business Machines Corporation | Packet scheduling system and method for multimedia data |
| EP1170919A1 (en) | 2000-07-04 | 2002-01-09 | TELEFONAKTIEBOLAGET LM ERICSSON (publ) | Method and device for improving the transmission efficiency in a communication system with a layered protocol stack |
| US6952739B2 (en) * | 2000-08-03 | 2005-10-04 | International Business Machines Corporation | Method and device for parameter independent buffer underrun prevention |
| US20050273514A1 (en) * | 2000-12-22 | 2005-12-08 | Ray Milkey | System and method for automated and optimized file transfers among devices in a network |
| EP1593047A4 (en) * | 2003-02-13 | 2010-06-09 | Nokia Corp | METHOD OF SIGNALING STREAMING QUALITY ADAPTATION AND CONTROL MCHANISMS IN MULTIMEDIA STREAMING |
| US7844727B2 (en) * | 2003-04-24 | 2010-11-30 | Nokia Corporation | Method and device for proactive rate adaptation signaling |
| US7068575B2 (en) * | 2003-07-30 | 2006-06-27 | Microsoft Corporation | High speed optical disc recording |
| US7489706B2 (en) | 2004-06-28 | 2009-02-10 | Spirent Communications, Inc. | Method and apparatus for placing a timestamp in a frame |
| US9065595B2 (en) * | 2005-04-07 | 2015-06-23 | Opanga Networks, Inc. | System and method for peak flow detection in a communication network |
| US8909807B2 (en) * | 2005-04-07 | 2014-12-09 | Opanga Networks, Inc. | System and method for progressive download using surplus network capacity |
| JP2007074225A (ja) | 2005-09-06 | 2007-03-22 | Sony Corp | 通信処理装置、および通信制御方法、並びにコンピュータ・プログラム |
| US8214516B2 (en) * | 2006-01-06 | 2012-07-03 | Google Inc. | Dynamic media serving infrastructure |
| US20070195756A1 (en) * | 2006-02-23 | 2007-08-23 | Matsushita Electric Industrial Co., Ltd. | Terminal switching technology for seamless switching of streaming sessions between terminals |
| US9209934B2 (en) | 2006-06-09 | 2015-12-08 | Qualcomm Incorporated | Enhanced block-request streaming using cooperative parallel HTTP and forward error correction |
| US20140358267A1 (en) * | 2006-09-26 | 2014-12-04 | Clear Channel Management Services, Inc. | Scheduling Advertising During Restricted Periods |
| WO2009005747A1 (en) * | 2007-06-28 | 2009-01-08 | The Trustees Of Columbia University In The City Of New York | Set-top box peer-assisted video-on-demand |
| CN101904149B (zh) | 2007-07-05 | 2015-09-09 | 相干逻辑公司 | 用于在移动设备上接收和呈现视听流的方法、设备和系统 |
| CN101370175B (zh) | 2007-08-15 | 2011-12-28 | 华为技术有限公司 | 确定数据发送时间的方法、组播分组方法、装置和系统 |
| EP2232791B1 (en) | 2007-12-28 | 2013-07-10 | Bytemobile, Inc. | Tcp packet spacing |
| US8141120B2 (en) * | 2008-01-03 | 2012-03-20 | Nec Laboratories America, Inc. | Adaptive scheduling of streaming video over wireless networks |
| US20100011091A1 (en) * | 2008-07-10 | 2010-01-14 | Blackwave Inc. | Network Storage |
| US8762561B2 (en) | 2008-07-23 | 2014-06-24 | Qualcomm Incorporated | System, method or apparatus for combining multiple streams of media data |
| CN101674492B (zh) | 2008-09-09 | 2011-09-21 | 中兴通讯股份有限公司 | 一种流媒体服务器性能测试方法及装置 |
| CN101420457B (zh) * | 2008-12-03 | 2011-10-05 | 腾讯科技（深圳）有限公司 | 对等体下载数据分片的方法、装置及对等体 |
| US8717890B2 (en) * | 2009-01-30 | 2014-05-06 | Movik Networks | Application, usage and radio link aware transport network scheduler |
| WO2010111261A1 (en) * | 2009-03-23 | 2010-09-30 | Azuki Systems, Inc. | Method and system for efficient streaming video dynamic rate adaptation |
| US9177540B2 (en) * | 2009-06-01 | 2015-11-03 | Music Mastermind, Inc. | System and method for conforming an audio input to a musical key |
| US20120327779A1 (en) * | 2009-06-12 | 2012-12-27 | Cygnus Broadband, Inc. | Systems and methods for congestion detection for use in prioritizing and scheduling packets in a communication network |
| US9137301B1 (en) * | 2009-06-30 | 2015-09-15 | Amazon Technologies, Inc. | Client based opportunistic routing |
| US8631455B2 (en) * | 2009-07-24 | 2014-01-14 | Netflix, Inc. | Adaptive streaming for digital content distribution |
| WO2011020437A1 (en) | 2009-08-21 | 2011-02-24 | The Chinese University Of Hong Kong | Devices and methods for scheduling transmission time of media data |
| US9185445B2 (en) | 2009-09-24 | 2015-11-10 | At&T Intellectual Property I, L.P. | Transmitting a prioritized audio stream along with multimedia content |
| US8484368B2 (en) * | 2009-10-02 | 2013-07-09 | Disney Enterprises, Inc. | Method and system for optimizing download and instantaneous viewing of media files |
| EP2317727A1 (en) * | 2009-10-28 | 2011-05-04 | Alcatel Lucent | Method for cache management and devices therefore |
| US8117332B2 (en) * | 2010-04-23 | 2012-02-14 | Canon Kabushiki Kaisha | Network streaming over multiple physical interfaces |
| KR20120010089A (ko) | 2010-07-20 | 2012-02-02 | 삼성전자주식회사 | Ｈｔｔｐ 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치 |
| US9456015B2 (en) | 2010-08-10 | 2016-09-27 | Qualcomm Incorporated | Representation groups for network streaming of coded multimedia data |
| EP2538635B1 (en) * | 2011-06-21 | 2014-11-05 | Alcatel Lucent | Method of delivering content from a content delivery protocol server to a client, and device for use in such a method |
| CN102333083B (zh) * | 2011-08-24 | 2017-04-05 | 中兴通讯股份有限公司 | 一种传输数据的方法和系统 |
| CA2851783C (en) * | 2011-10-21 | 2023-04-04 | Thomas Schierl | Resource management concept |
| WO2013102179A1 (en) | 2011-12-30 | 2013-07-04 | Krause Edward A | High capacity network communication link using multiple cellular devices |
| US9401968B2 (en) * | 2012-01-20 | 2016-07-26 | Nokia Techologies Oy | Method and apparatus for enabling pre-fetching of media |
| US9450997B2 (en) * | 2012-02-27 | 2016-09-20 | Qualcomm Incorporated | Dash client and receiver with request cancellation capabilities |
| US20130271655A1 (en) | 2012-04-12 | 2013-10-17 | Google Inc. | System, apparatus and method to facilitate live video streaming |
| EP2665239B1 (en) * | 2012-05-14 | 2016-08-31 | Alcatel Lucent | An adaptive streaming aware networks node, client and method with priority marking |
| US9125073B2 (en) | 2012-08-03 | 2015-09-01 | Intel Corporation | Quality-aware adaptive streaming over hypertext transfer protocol using quality attributes in manifest file |
| US9712585B2 (en) * | 2012-11-13 | 2017-07-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Processing of multimedia data |
| EP2936742B1 (en) * | 2012-12-21 | 2019-10-09 | Koninklijke KPN N.V. | Low-latency streaming |
| CN103929684B (zh) | 2013-01-14 | 2018-06-15 | 华为技术有限公司 | 一种基于流媒体选择码流分段的方法、播放器和终端 |
| US9432426B2 (en) * | 2013-02-04 | 2016-08-30 | Qualcomm Incorporated | Determining available media data for network streaming |
| US9131009B2 (en) * | 2013-03-08 | 2015-09-08 | Comcast Cable Holdings, Llc | Resource request management |
| US20140282792A1 (en) * | 2013-03-15 | 2014-09-18 | Cygnus Broadband, Inc. | Video streaming with buffer occupancy prediction based quality adaptation |
| US9503491B2 (en) * | 2013-03-15 | 2016-11-22 | Echostar Technologies L.L.C. | Playback stall avoidance in adaptive media streaming |
| EP2784996A1 (en) * | 2013-03-27 | 2014-10-01 | British Telecommunications public limited company | Deadline driven content delivery |
| EP2784673A1 (en) * | 2013-03-28 | 2014-10-01 | Alcatel Lucent | Scheduling |
| ITBA20130077A1 (it) * | 2013-11-25 | 2015-05-26 | Cicco Luca De | Meccanismo per il controllo del bitrate di codifica in un sistema di video streaming adattivo basato su buffer di playout e sulla stima di banda. |
| CN103747283B (zh) * | 2013-12-24 | 2017-02-01 | 中国科学院声学研究所 | 视频分片的下载方法 |
| US9635077B2 (en) * | 2014-03-14 | 2017-04-25 | Adobe Systems Incorporated | Low latency live video streaming |
| CN103973937B (zh) | 2014-04-29 | 2016-08-17 | 南京邮电大学 | 基于无线多媒体传感器网络的信息隐藏方法 |
| EP2958294A1 (en) * | 2014-06-16 | 2015-12-23 | Thomson Licensing | Method for operating a network equipment arranged along a transmission path between a client terminal and at least one server, and corresponding network equipment. |
| US9854282B2 (en) * | 2014-11-20 | 2017-12-26 | Alcatel Lucent | System and method for enabling network based rate determination for adaptive video streaming |
| KR102104353B1 (ko) * | 2015-05-08 | 2020-04-24 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 무선 장치 내의 서비스 애플리케이션의 네트워크 추천된 버퍼 관리 |
| EP3304844B1 (en) * | 2015-06-03 | 2022-11-23 | Telefonaktiebolaget LM Ericsson (publ) | Methods, radio communication device and base station device for managing a media stream |
| EP3285454B1 (en) * | 2016-08-16 | 2020-01-15 | Alcatel Lucent | Method and device for transmission of content |
-
2015
- 2015-10-16 WO PCT/CN2015/092095 patent/WO2017063189A1/en not_active Ceased
-
2016
- 2016-10-14 EP EP16854968.1A patent/EP3363181B1/en active Active
- 2016-10-14 TW TW105133351A patent/TW201729601A/zh unknown
- 2016-10-14 JP JP2018518703A patent/JP2018532334A/ja active Pending
- 2016-10-14 CN CN201680059719.XA patent/CN108141455B/zh active Active
- 2016-10-14 US US15/765,977 patent/US12088652B2/en active Active
- 2016-10-14 WO PCT/CN2016/102194 patent/WO2017063592A1/en not_active Ceased
-
2024
- 2024-07-09 US US18/767,280 patent/US20240364768A1/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2024510139A (ja) * | 2021-10-06 | 2024-03-06 | テンセント・アメリカ・エルエルシー | メディアストリーミング及び再生中のプレロール及びミッドロールをサポートするための方法、装置及びコンピュータプログラム |
| JP7691210B2 (ja) | 2021-10-06 | 2025-06-11 | テンセント・アメリカ・エルエルシー | メディアストリーミング及び再生中のプレロール及びミッドロールをサポートするための方法、装置及びコンピュータプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US12088652B2 (en) | 2024-09-10 |
| WO2017063189A1 (en) | 2017-04-20 |
| US20180316740A1 (en) | 2018-11-01 |
| TW201729601A (zh) | 2017-08-16 |
| EP3363181B1 (en) | 2023-03-29 |
| EP3363181A4 (en) | 2019-04-03 |
| CN108141455B (zh) | 2021-08-20 |
| US20240364768A1 (en) | 2024-10-31 |
| EP3363181A1 (en) | 2018-08-22 |
| CN108141455A (zh) | 2018-06-08 |
| WO2017063592A1 (en) | 2017-04-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20240364768A1 (en) | Deadline signaling for streaming of media data | |
| US10666961B2 (en) | Determining media delivery event locations for media transport | |
| US10454985B2 (en) | File format based streaming with dash formats based on LCT | |
| US10938872B2 (en) | Processing interactivity events for streaming media data | |
| TW202037177A (zh) | 用於串流媒體資料之服務描述 | |
| JP6254291B2 (ja) | Ｄａｓｈのロバストなライブ動作 | |
| JP2018524882A (ja) | ブロードキャストのためのキャッシュされたセグメントのシグナリング | |
| JP2018526845A (ja) | ＤＡＳＨクライアントＱｏＥメトリックのミドルウェア配信 | |
| KR20170089863A (ko) | 멀티미디어 및 파일 전송을 위한 전송 인터페이스 | |
| US20170331666A1 (en) | Real-time control interface for broadcast object streaming | |
| US20210218976A1 (en) | Multiple decoder interface for streamed media data | |
| WO2026020261A1 (en) | Exchanging common media client data (cmcd) metrics for media streaming session over radio access network | |
| HK1257973B (en) | Method and apparatus for determining media delivery event locations for media transport |