JP2018521538A - ウェブソケットサブプロトコルを使用したメディアデータの転送 - Google Patents

ウェブソケットサブプロトコルを使用したメディアデータの転送 Download PDF

Info

Publication number
JP2018521538A
JP2018521538A JP2017558549A JP2017558549A JP2018521538A JP 2018521538 A JP2018521538 A JP 2018521538A JP 2017558549 A JP2017558549 A JP 2017558549A JP 2017558549 A JP2017558549 A JP 2017558549A JP 2018521538 A JP2018521538 A JP 2018521538A
Authority
JP
Japan
Prior art keywords
channel
streaming client
client
data
media data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017558549A
Other languages
English (en)
Inventor
ギリダハール・ダハティ・マンディアム
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2018521538A publication Critical patent/JP2018521538A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • 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
    • 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)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

例示的なデバイスは、ストリーミングクライアントを含むクライアントデバイスのプロキシサーバを実行するように構成された1つまたは複数のプロセッサを含む。プロキシサーバは、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することと、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したとの決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信することとを行うように構成される。このようにして、ストリーミングクライアントは、現在のチャネルのマニフェストファイルを受信することなしに、また現在のチャネルのメディアデータに対する要求をプロキシサーバに送信せずに、(チャネル変更イベントに続く)現在のチャネルのメディアデータを受信することができる。

Description

本出願は、その内容全体が参照により本明細書に組み込まれている、2015年5月13日に出願した米国仮出願第62/160,928号の利益を主張するものである。
本開示は、符号化ビデオデータの記憶および転送に関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンストビデオコーディング(AVC)によって定められた規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
本出願は一般に、ストリーミング環境においてチャネル変更イベントを処理するための技法を説明する。具体的には、メディアデータは、単方向伝送によるリアルタイムオブジェクト配信(ROUTE)などのファイル変換フォーマットを使用してプロキシサーバに配信されてよい。クライアントデバイスは、動的適応ストリーミングオーバーHTTP(DASH)クライアントなど、プロキシサーバからメディアデータを受信するストリーミングクライアントを含んでもよい。本開示の技法を使用して、ストリーミングクライアントおよびプロキシサーバはウェブソケットセッションを確立してよく、具体的には、ウェブソケットサブプロトコルを交渉してもよい。プロキシサーバは、最初に、同調チャネルが前のチャネルから現在のチャネルに変化したと決定してよい。しかしながら、プロキシサーバは、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、また現在のチャネルのマニフェストファイルをストリーミングクライアントに送信することなく(たとえば、送信する前に)、ウェブソケットサブプロトコルを使用して現在のチャネルのメディアデータをストリーミングクライアントに配信することができる。
一例では、メディアデータを転送する方法は、ストリーミングクライアントを含むクライアントデバイスのプロキシサーバによって、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定するステップと、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したとの決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信するステップとを含む。
別の例では、メディアデータを転送するためのデバイスは、メディアデータを記憶するように構成されたメモリと、ストリーミングクライアントを含むクライアントデバイスのプロキシサーバを実行するように構成された1つまたは複数のプロセッサとを含む。プロキシサーバは、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することと、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したとの決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信することとを行うように構成される。
別の例では、メディアデータを転送するためのデバイスは、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定するための手段であって、クライアントデバイスはストリーミングクライアントを実行している、決定するための手段と、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したとの決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信するための手段とを含む。
別の例では、コンピュータ可読記憶媒体が命令をそれ自体に記憶しており、命令は、実行されたとき、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することであって、クライアントデバイスはストリーミングクライアントを実行している、決定することと、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したとの決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信することとをプロセッサに行わせる。
1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 取出しユニットの構成要素の例示的なセットを示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 例示的なビデオファイルの要素を示すブロック図である。 本開示の技法を実行し得る例示的なシステムを示すブロック図である。 システムの構成要素間の例示的な通信交換を示す流れ図である。
本開示は一般に、たとえばウェブソケットプロトコルを使用して、メディアデータをプロキシサーバからクライアントデバイスのストリーミングクライアントに転送するための技法を説明する。プロキシサーバは、マルチメディアブロードキャスト/マルチキャストサービス(MBMS)または拡張MBMS(eMBMS)を使用してオーバージエア(OTA)ブロードキャストまたはネットワークブロードキャストなどのブロードキャストを介してメディアデータを受信してよい。代替として、プロキシサーバは、チャネルチューナデバイスなど、ブロードキャストを介してメディアデータを受信する別個のデバイスからメディアデータを取得してもよい。プロキシサーバは、ストリーミングクライアントに対するサーバデバイスとして働くように構成されてもよい。ストリーミングクライアントは、メディアデータをプロキシサーバから取り出すためおよびメディアデータを与えるために、動的適応ストリーミングオーバーHTTP(DASH)などのネットワークストリーミング技法を使用するように構成されてもよい。
ユーザは、メディアデータを観測する(たとえば、オーディオを聴取するおよび/またはビデオを視聴する)とき、チャネルチューナ(すなわち、チャネル選択デバイス)と対話する場合がある。さらに、ユーザは、現在同調されているチャネルを変更するためにチャネルチューナと対話する場合がある。たとえば、ユーザが現在、1つのチャネル上でプログラムを視聴している場合、ユーザは、異なるプログラムを視聴するために新しいチャネルに切り替える場合がある。応答して、チャネルチューナは、新しいチャネルに切り替えて、新しいチャネルのメディアデータを受信することを始める場合がある。同様に、チャネルチューナは、新しいチャネルのメディアデータをプロキシサーバに与える場合がある。
DASHなどのストリーミングサービスの一部として、ストリーミングクライアント(たとえば、DASHクライアント)は、一般的に、サーバデバイスからメディアデータを取り出すためにメディアプレゼンテーション記述(MPD)などのマニフェストファイルを使用する。したがって、従来のストリーミングクライアントは、チャネル変更イベントに続いて新しいチャネルのメディアデータを取り出すことができる前に、マニフェストファイルの配信を待つことになる。しかしながら、マニフェストファイルを待つことは、たとえ新しいチャネルの再生可能なメディアデータが受信されているとしても、チャネル変更イベントと、ユーザが新しいチャネルのメディアデータを観察し得る時点との間の時間を遅延させることになる。したがって、本開示は、たとえ新しいチャネルと関連付けられたマニフェストファイルをストリーミングクライアントに配信しなくても(配信する前であっても)新しいチャネルのメディアデータをストリーミングクライアントに配信することを可能にする技法を説明する。
具体的には、以下でより詳細に説明するように、プロキシサーバおよびストリーミングクライアントは、ウェブソケットサブプロトコルに従って通信するように構成され得る。したがって、プロキシサーバは、ストリーミングクライアントからのメディアデータに対する要求(たとえば、HTTP GET要求)を待つのではなく、ウェブソケットサブプロトコルを介してストリーミングクライアントにメディアデータを配信してもよい。ウェブソケットプロトコルは、Fette他、「The WebSocket Protocol」、インターネットエンジニアリングタスクフォース、RFC 6455、2011年12月(tools.ietf.org/html/rfc6455において入手可能)において記述されている。ウェブソケットサブプロトコルは、RFC 6455のセクション1.9の中で記述されている。
本開示の技法は、その各々の全内容が参照により本明細書に組み込まれている、Walkerら、「TRANSPORT INTERFACE FOR MULTIMEDIA AND FILE TRANSPORT」、米国出願第14/958,086号の中で記述される技法の一部または全部を利用してもよい。これらの仮出願は、メディアデータイベント(MDE)を説明する。MDEは、たとえばブロードキャストテレビジョン(TV)サービスに対するチャネル変更時間を低減するために使用されてもよい。これらの技法は、リニアTVに関係する場合があり、特に、セグメント(すなわち、ファイルベース)配信サービスに関係する場合がある。
ファイルベースまたはセグメントベースの配信サービスは、たとえばデータがDASHに従ってフォーマットされるとき、他のサービスの間で使用されてよく、単方向伝送によるリアルタイムオブジェクト配信(ROUTE)において、またはPaila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月(tools.ietf.org/html/rfc6726において入手可能)で定義される単方向伝送によるファイル配信(FLUTE)において使用されてもよい。セグメントベースの配信技法は、より大きいペイロードがいくつかのより小さいペイロードに分割されるHTTPチャンキングに類似すると見なされてよい。しかしながら、セグメントベースの配信技法とHTTPチャンキングとの間の重要な差異は、「チャンク」(すなわち、MDE)が概して即時消費のために提供されることである。すなわち、MDEは再生可能なメディアを含み、受信機はすでに、MDEのプレイアウトを始動するために必要なメディアメタデータ(コーデック、暗号化メタデータ、など)を所有していることが仮定される。
最近、DASHソリューションは、次世代ワイヤレスビデオブロードキャストのために提案されてきた。DASHは、ブロードキャストアクセス(すなわち、コンピュータネットワークベースのブロードキャスト配信)と連携してうまく使用されてきた。DASHは、ハイブリッド配信手法を可能にする。DASH受信に対するHTMLおよびジャバスクリプトクライアントは、ブロードバンド配信を使用するように構成される。ブロードキャスト技術は、めったにウェブブラウザアプリケーションに及ぶことはないが、(ウェブブラウザアプリケーションに埋め込まれ得る)DASHクライアントは、ウェブブラウザアプリケーションを実行している同じクライアントデバイスの一部分を形成し得るプロキシサーバからメディアデータを取り出すことができる。
DASHジャバスクリプトクライアントは、コンテンツのロケーションを判定するためにメディアプレゼンテーション記述(MPD)または他のマニフェストファイルを活用することができる。MPDは、概して、拡張可能マークアップ言語(XML)ドキュメントとして形成される。また、MPDは、メディアセグメントのURLロケーションの表示を提供する。
DASHジャバスクリプトクライアントは、セグメントをフェッチするためにXMLオーバーHTTP(XHR)などのブラウザ提供ジャバスクリプト方法を使用してもよい。XHRは、セグメントに対してチャンクされた配信を実行するために使用され得る。概して、XHRは、チャンク(すなわち、部分的セグメント)をジャバスクリプトをジャバスクリプトにリリースするためには使用されず、代わりに全セグメントをリリースするために使用される。バイト範囲要求は、部分的セグメント要求を可能にするために使用され得るが、DASHクライアントは、一般に、バイト範囲とMDEとの間のマッピングを決定することはできない。MPDは、MDEおよび関連するバイト範囲を記述するために拡張され得るが、これは、高速チャネル変更のために特別に調整されたMPDを取得することをDASHクライアントに強制することになる。本開示の技法は、この要求を回避し得る。
上述のように、本開示の技法は、ウェブソケットおよびウェブソケットサブプロトコルを利用してもよい。ウェブソケットは、ウェブベースのクライアントとサーバとの間の双方向通信を確立するための一方法としてHTML5内に導入された。ウェブソケットに対するURLは、一般に、「ws://」プレフィックス、またはセキュアなウェブソケットに対する「wss://」プレフィックスを含む。ウェブソケット(URL)は、readyState読取り専用属性(Connecting、Open、Closing、またはClosed)を有する主インターフェースである。他の読取り専用属性は拡張子およびプロトコルにおいて定義され、さらなる仕様を待っている。ウェブソケット(URL)主インターフェースは、3つのイベント、onOpen、onError、およびonCloseを伝搬する。また、ウェブソケット(URL)は、2つのメソッド、send()およびclose()を提供する。send()は、3つの引数、string、blob、またはArrayBufferをとることができる。ウェブソケット(URL)主インターフェースは、send()処理の一部分として読取り専用属性bufferedAmount(long)にアクセスすることができる。ウェブソケットに対する広範なサポートが、Mozilla Firefox、Google Chromeなどの多様なウェブブラウザ内で提供される。
ウェブソケット宣言の一例が、以下で示される(ダブルスラッシュ「//」に続くテキストは実行されないコメントを表す)。
var connection = new WebSocket('ws://QRTCserver.qualcomm.com');
//‘ws://'および‘wss://'は、それぞれウェブソケットおよびセキュアなウェブソケットに対する新しいURL方式である
//接続がオープンのとき、いくつかのデータをサーバに送信する
connection.onopen = function () {
connection.send('Ping'); //メッセージ「Ping」をサーバに送信する
};
//ログエラー
connection.onerror = function (error) {
console.log('WebSocket Error ' + error);
};
//サーバからのログメッセージ
connection.onmessage = function (e) {
console.log('Server:' + e.data);
};
インターネットエンジニアリングタスクフォース(IETF)は、RFC 6455において指定されたウェブソケットに対して対応する仕様を有する。UAは、ウェブソケット要求に際して標準的HTTPConnectionを開始していない。HTTPハンドシェイクは、TCP接続上で発生し得る。同じ接続は、同じサーバに接続している他のウェブアプリケーションによって再使用され得る。サーバは、「ws://」タイプの要求と「http://」タイプの要求の両方をサービスする場合がある。
クライアントハンドシェイクおよびRFC 6455のセクション1.2からのサーバ応答の一例を以下に示す:
Client Handshake:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Server Response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
RFC 6455のセクション1.9において説明したように、ウェブソケットサブプロトコルは、RFC 6455のセクション11.5を使用してサブプロトコル名を登録することによって形成され得る。一般に、登録は、サブプロトコル識別子と、サブプロトコル共通名と、サブプロトコル定義とを登録することを伴う。サブプロトコルを使用するために、RFC 6455のセクション11.3.4は、クライアントデバイスが、サーバデバイスに対してハンドシェイクをオープンしているウェブソケット内のサブプロトコル固有のヘッダを含むべきであることを示す。
HTTPハンドシェイクにおいて拡張子またはプロトコルを指定することはオプションである。ハンドシェイクが完了した後、データは、RFC 6455内で定義されるようなフレーミングプロトコルを使用して交換されてよい。すなわち、データ交換は、メッセージ(制御、データ、など)のタイプと、マスク(クライアントからサーバへのデータはマスクされることを要求される一方で、サーバからクライアントへのデータはアンマスクされることを要求される)と、ペイロード長と、ペイロードデータとを定義するためのオペコードを含んでよい。接続がクローズされるべきであることを示す制御フレームは、TCP接続を終了する「TCP FIN」メッセージを生じる場合がある。
本開示の技法は、ISOベースメディアファイルフォーマット、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンストビデオコーディング(AVC)ファイルフォーマット、第3世代パートナーシッププロジェクト(3GPP)ファイルフォーマット、および/もしくはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
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においてPeriod要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブのサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含んでもよい。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用される場合がある。
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられてもよい。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられてもよいので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択されてもよい。いくつかの例では、1つの期間内のメディアコンテンツは、グループ0が存在する場合にはグループ0からの1つの表現によって表されてもよく、あるいは各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表されてもよい。ある期間の各表現のタイミングデータは、期間の開始時間に対して表されてもよい。
表現は1つまたは複数のセグメントを含んでもよい。各表現が初期化セグメントを含んでもよく、または表現の各セグメントが自己初期化するものであってもよい。初期化セグメントは、それが存在する場合、表現にアクセスするための初期化情報を含んでもよい。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照されてもよい。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
それぞれに異なるタイプのメディアデータに対して実質的に同時に取出しを行うためにそれぞれに異なる表現が選択されてもよい。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
図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:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは、一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
ITU-T H.264/AVCおよび高効率ビデオコーディング(HEVC)規格(ITU-T H.265とも呼ばれる)など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。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:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、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(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。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は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえば、ネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
さらに、本開示のいくつかの技法によれば、サーバデバイス60は、オーバージエア(OTA)ブロードキャストを介してクライアントデバイス40にメディアデータを送信してもよい。すなわち、ネットワーク74を介してメディアデータを配信するのではなく、サーバデバイス60は、アンテナ、衛星、ケーブルテレビジョンプロバイダなどを介して送信され得るOTAブロードキャストを介してメディアデータを送信してもよい。
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応する場合があるマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含んでもよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含んでもよい。クライアントデバイス40は、メディアプレゼンテーションMPDを取り出し、表現68のセグメントにどのようにアクセスするかを判定してもよい。
特に、取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を決定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能のすべてまたは一部は、ハードウェア、もしくはハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定することができる。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内の表現に対するビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
概して、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を介してマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
追加または代替として、取出しユニット52は、ブロードキャスト、またはeMBMSまたはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。
上述のように、いくつかの例では、取出しユニット52は、サーバデバイス60からOTAブロードキャストを受信するように構成され得る。そのような例では、取出しユニット52は、たとえば以下の図2に関してより詳細に図示し説明するように、OTA受信ユニットとストリーミングクライアントとを含んでもよい。一般に、ストリーミングクライアント(たとえば、DASHクライアント)は、プッシュ有効化されるように構成されてもよい。すなわち、ストリーミングクライアントは、最初にプロキシサーバからメディアデータを要求することなく、プロキシサーバからメディアデータを受信してもよい。したがって、プロキシサーバは、ストリーミングクライアントからのメディアデータに対する要求に応答してメディアデータを配信するのではなく、ストリーミングクライアントにメディアデータをプッシュしてもよい。
プッシュ有効化技術は、高速チャネル変更における性能を改善し得る。したがって、チャネル変更イベントが発生した(すなわち、現在のチャネルが前のチャネルから新しいチャネルに切り替えた)ものと取出しユニット52が決定した場合、プロキシサーバは、新しいチャネルのメディアデータをストリーミングクライアントにプッシュしてもよい。XHRを使用するのではなく、取出しユニット52は、このプッシュベースの配信を実施するためにウェブソケットを使用するように構成されてもよい。したがって、チャネル変更イベントは、チャネルチューナから生じたイベントを通して組み込まれてもよい。たとえば、チャネル変更およびプッシュベースの配信に対する本開示の技法は、ジャバスクリプトをバイパスしてよく、プロキシサーバは、チャネル変更イベントが発生したものと決定してもよい。チャネル変更イベントに応答して、プロキシサーバは、ストリーミングクライアントにセグメントの代わりにMDEを配信することを直ちに開始してもよい。いくつかの例では、プロキシサーバは、「帯域内」のチャネル変更を記述する情報を、ストリーミングクライアントに対するメディアデータとともに、たとえばストリーミングクライアントへのウェブソケット接続を通して提供する。
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力44に送る。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は、各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路のいずれかとして実装され得る。ビデオエンコーダ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に対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時刻における特定のビューに対する符号化ピクチャ(またはフレーム)を含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、それぞれに異なる代替表現(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含む場合があるメディアプレゼンテーション記述(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は、OTAミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。
この例では、OTAミドルウェアユニット100は、OTA受信ユニット106と、キャッシュ104と、プロキシサーバ102とをさらに含む。この例では、OTA受信ユニット106は、たとえば単方向伝送によるファイル配信(FLUTE)に従ってOTAを介してデータを受信するように構成される。すなわち、OTA受信ユニット106は、たとえば、BM-SCとして機能し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
OTAミドルウェアユニット100がファイルに関するデータを受信すると、OTAミドルウェアユニットは受信したデータをキャッシュ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に与えてもよい。
いくつかの例では、プロキシサーバ102は、新しいチャネルに対するMPDをDASHクライアント110に送信する前に(送信することなく)、新しいチャネルのメディアデータイベント(MDE)をDASHクライアント110にプッシュする。したがって、そのような例では、プロキシサーバ102は、DASHクライアント110からメディアデータに対する要求を実際に受信することなく、新しいチャネルのメディアデータをDASHクライアント110に送信してもよい。プロキシサーバ102およびDASHクライアント110は、そのようなメディアデータプッシングを可能にするためにウェブソケットサブプロトコルを実行するように構成されてもよい。
一般に、ウェブソケットは、サブプロトコルの定義を可能にする。たとえば、RFC 7395は、ウェブソケットに対する拡張可能メッセージング/プレゼンスプロトコル(XMPP)サブプロトコルを定義する。本開示の技法は、同様の方式でウェブソケットサブプロトコルを使用してもよい。具体的には、プロキシサーバ102およびDASHクライアント110は、HTTPハンドシェイクの間にウェブソケットサブプロトコルを交渉してもよい。サブプロトコルに対するデータは、このHTTPハンドシェイクの間にSec-WebSocket-Protocolヘッダ内に含まれ得る。いくつかの例では、サブプロトコル交渉は、たとえばウェブソケットの両端が共通のサブプロトコルを使用していることがアプリオリに知られる場合、回避され得る。
さらに、サブプロトコルの定義は、HTTP1.1/XHRセマンティクスのサブセットを保持してもよい。たとえばサブプロトコルは、テキストベースのGET URLメッセージの使用を含んでもよい。PUSH、PUTおよびPOSTなどの他のメソッドは、サブプロトコルにおいて必ずしも必要であるとは限らない。また、ウェブソケットエラーメッセージは十分であるので、HTTPエラーコードは不要である。それにもかかわらず、いくつかの例では、他のメソッド(たとえば、PUSH、PUTおよびPOSTならびに/あるいはHTTPエラーコード)が、サブプロトコル内に含まれる場合がある。
一般に、サブプロトコルは、ウェブソケットを通してMDEイベントを伝搬してもよい。これは、チューナイベントへの直接のアクセスの活用を可能にする場合がある。サブプロトコルは、クライアントからサーバへのメッセージングを、たとえばURLを指定するテキストベースのメッセージの形式で含んでもよい。サーバ(たとえば、プロキシサーバ102)は、クライアント(たとえば、DASHクライアント110)から到来するテキストをパースしてもよい。応答して、プロキシサーバ102は、代わりにセグメントを与えてもよい。プロキシサーバ102は、そのようなメッセージをHTTP GETメッセージとして解釈してもよい。
サブプロトコルのサーバからクライアントへのメッセージングは、テキストベースのメッセージとバイナリベースのメッセージの両方を含んでもよい。テキストベースのメッセージは、セグメントに対するデータが開始したことまたは終了したことを示す「START SEGMENT」および/または「END SEGMENT」を含んでもよい。「END SEGMENT」は、たとえばセグメントがGETまたはチャネル変更に応答して配信されるだけであるときの、同期配信に対するいくつかの例において十分であり得る。いくつかの例では、メッセージは、対応するセグメントに対する(たとえば、「END [URL]」の形態の)URLをさらに含んでもよい。
また、プロキシサーバ102からDASHクライアント110へのテキストベースのメッセージは、チャネル変更が発生したことおよび新しいセグメントが来つつあることを示す「CHANNEL CHANGE」を含んでもよい。DASHクライアント110は、新しいチャネルに対するMPDをまだ取得していないことがあるので、「CHANNEL CHANGE」メッセージは、新しいセグメントに対するセグメントURLを含んでもよい。いくつかの例では、テキストベースのメッセージは、MPDがDASHクライアント110に配信されていることを示すために「MPD」を含んでもよい。プロキシサーバ102は、MPDを帯域内でDASHクライアント110に(すなわち、MPDに対応するメディアデータとともに)プッシュしてよく、またはDASHクライアント110は、MPDを帯域外で取り出してもよい。帯域外で取り出された場合、プロキシサーバ102は、MPDに対するURLを示す帯域内MPD URLメッセージをDASHクライアント110に提供し得る。
プロキシサーバ102からDASHクライアント110へのバイナリメッセージは、メディアペイロードを含んでもよい。たとえば、メディアペイロードは、フルセグメントまたはMPDを含んでもよい。MDEが配信された場合、プロキシサーバ102は、MDEが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は、表現124A〜124Nとは別個のデータ構造を含み得る。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124A〜124Nは、図1の表現68に対応する場合がある。一般に、MPD122は、コーディング特性およびレンダリングの特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現124A〜124Nの特性を一般に表す、データを含み得る。
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在する場合、セグメント132の同様の特性を記述することができる。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
セグメント128、132は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。MPD122のデータは、図3の例には示されていないが、そのような特性は、MPD122のデータによって記述され得る。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のセグメントタイプを定義し得る。
MOOVボックス154は、図4の例では、動画ヘッダ(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は、SPAのビデオファイル150内の位置の指標を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
図5は、本開示の技法を実行し得る例示的なシステム200を示すブロック図である。図5のシステムは、リモート202、チャネルセレクタ204、ROUTEハンドラ206、DASHクライアント208、デコーダ210、HTTP/WSプロキシサーバ214、ブロードキャスト構成要素218を記憶するデータ記憶デバイス216、ブロードバンド構成要素220、および1つまたは複数のプレゼンテーションデバイス212を含む。ブロードキャスト構成要素218は、たとえば、マニフェストファイル(メディアプレゼンテーション記述(MPD)など)、およびメディアデータまたはメディア配信イベント(MDE)データを含んでもよい。
図5の要素は、一般に、クライアントデバイス40(図1)の要素に対応し得る。たとえば、チャネルセレクタ204およびブロードキャスト構成要素220はネットワークインターフェース54(またはOTA受信ユニット、図1に示さず)、ROUTEハンドラ206、DASHクライアント208、プロキシサーバ214に対応してもよく、データ記憶デバイス216は取り出しユニット52に対応してもよく、デコーダ210はオーディオデコーダ46およびビデオデコーダ48のいずれかまたは両方に対応してもよく、プレゼンテーションデバイス212はオーディオ出力42およびビデオ出力44に対応してもよい。
全般に、プロキシサーバ214は、MPDなどのマニフェストファイルをDASHクライアント208に供給してもよい。しかしながら、MPDをDASHクライアント208に配信しなくても、プロキシサーバ214は、チャネル(たとえば、チャネル変更イベントに続く新しいチャネル)のメディアデータのMDEをDASHクライアント208にプッシュし得る。具体的には、ユーザは、チャネル変更命令をチャネルセレクタ204に送信するリモート202にアクセスすることによってチャネル変更イベントを要求してもよい。
チャネルセレクタ204は、たとえばオーバージエア(OTA)チャネルチューナ、ケーブルセットトップボックス、衛星セットトップボックス、などを備えてもよい。全般に、チャネルセレクタ204は、リモート202から受信された信号を介して選択されたチャネルに対するサービス識別子(serviceID)を決定するように構成される。また、チャネルセレクタ204は、serviceIDに対応するサービスに対するトランスポートセッション識別子(TSI)を決定する。チャネルセレクタ204は、TSIをROUTEハンドラ206に与える。
ROUTEハンドラ206は、ROUTEプロトコルに従って動作するように構成される。たとえば、ROUTEハンドラ206は、チャネルセレクタ204からTSIを受信することに応答して、対応するROUTEセッションを連結する。ROUTEハンドラ206は、ROUTEセッションに対する階層符号化トランスポート(LCT)セッションによって、ROUTEセッションに対するメディアデータおよびマニフェストファイルを受信するために、ROUTEセッションに対するLCTセッションを決定する。また、ROUTEハンドラ206は、LCTに対するLCTセッションインスタンス記述(LSID)を取得する。ROUTEハンドラ206は、ROUTE配信データからメディアデータを抽出し、ブロードキャスト構成要素218へのデータをキャッシュする。
したがって、プロキシサーバ214は、DASHクライアント208への後続の配信のためにブロードキャスト構成要素からメディアデータを取り出すことができる。具体的には、HTTPを実行するとき、プロキシサーバ214は、メディアデータに対する特定の要求に応答して、そのようなメディアデータ(およびマニフェストファイル)をDASHクライアント208に与える。しかしながら、ウェブソケットを実行するとき、プロキシサーバ214は、(たとえば、ブロードバンド構成要素220を介して受信された、またはブロードキャスト構成要素218から取り出された)メディアデータをDASHクライアント208に「プッシュ」することができる。すなわち、プロキシサーバ214は、メディアデータに対する個別の要求をDASHクライアント208から受信することなく、メディアデータが配信のための準備ができた後にメディアデータを配信することができる。
DASHクライアント208は、依然として、チャネル変更イベントをローカルチューナ(すなわち、チャネルセレクタ204)から直接受信することができるが、適時にチャネル変更イベントに対応することはできない。したがって、新しいチャネルのメディアデータのMDEをDASHクライアント208にプッシュすることによって、DASHクライアント208は、マニフェストファイルがなくても、使用可能なメディアデータをMDEから抽出することができる。
DASHクライアント208およびプロキシサーバ214はそれぞれ、ハードウェア、またはソフトウェアおよび/もしくはファームウェアとハードウェアとの組合せの中に実装されてもよい。すなわち、DASHクライアント208またはプロキシサーバ214に対するソフトウェアおよび/またはファームウェアの命令が与えられたとき、不可欠なハードウェア(命令を記憶するためのメモリおよび命令を実行するための1つまたは複数の処理ユニットなど)もまた与えられることを理解されたい。処理ユニットは、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは離散論理回路などの1つまたは複数のプロセッサを、単独でまたは任意の組合せにおいて備えてもよい。全般に、「処理ユニット」は、ハードウェアベースのユニット、すなわち固定の機能および/またはプログラマブル回路を含み得る何らかの形態の回路を含むユニットを指すことを理解されたい。
このようにして、システム200は、メディアデータを転送するためのデバイス、メディアデータを記憶するように構成されたメモリを含むデバイス、およびストリーミングクライアントを含むクライアントデバイスのプロキシサーバを実行するように構成された1つまたは複数のプロセッサのうちの一例を表す。プロキシサーバは、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することと、その決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信することとを行うように構成される。
図6は、図5のシステム200の構成要素間の例示的な通信交換を示す流れ図である。図5のシステム200の構成要素に関して説明したが、図5の技法はまた、他のデバイスおよびシステム、たとえば図1のクライアントデバイス40および図2の取り出しユニット52によって実行されてもよい。具体的には、図6の例示的なフロー図が、チャネルセレクタ204、プロキシサーバ214およびDASHクライアント208に関して説明される。
図6の例では、DASHクライアント208(図6において「HTML/JS/Browser Broadcast WebSocket Client」と標示されている)は、セグメントのURL(URL (WS))をプロキシサーバ214(図6において「Local HTTP Proxy」と標示されている)に送信する(230)。すなわち、上記で説明したように、DASHクライアント208は、メッセージがセグメントのURLを規定するプロキシサーバ214に、ウェブソケットを使用してテキストベースのメッセージを送信してもよい。URLは、「ws://」プレフィックスまたは「wss://」プレフィックスを含んでもよい。応答して、プロキシサーバ214は、セグメントの形態でDASHクライアント208にウェブソケットを使用してメディアデータを送信し(232)、ならびにセグメントの終了を示すテキストベースのメッセージ(END SEGMENT(WS))を送信する(234)。
この一連の通信の後、チャネルセレクタ204は、(たとえば、図6に示していないリモート202からの信号を受信した後)チャネルが変更されたこと(236)を示す。応答して、この例では、プロキシサーバ214は、チャネルが変更されたことを示すテキストベースのメッセージならびに新しいチャネルのURLを、DASHクライアント208にウェブソケットを介して送信する(238)。さらに、プロキシサーバ214は、新しいチャネルのメディアデータを含む1つまたは複数のメディアデータイベント(MDE)をDASHクライアント208に配信する(240A〜240N)。図6に示すように、MDEの配信は、新しいチャネルに対するMPDをDASHクライアントに配信する(244)前に発生する。しかしながら、いくつかの例では、プロキシサーバ214は、決して、MPDをDASHクライアント208に実際に配信することはない。さらに、MPDの配信に続いて、MPDが図示のように実際に配信される場合、プロキシサーバ214は、MDEをDASHクライアント208に配信し続けてもよい。
セグメントのMDEをウェブソケットを介してDASHクライアント208に配信した後、プロキシサーバ214は、セグメントの終了を示すテキストベースのメッセージを配信する(242)。単一のセグメントだけが図6に表されているが、このプロセスは、複数のセグメントに対して繰り返し発生する場合があることを理解されたい。すなわち、プロキシサーバ214は、「END SEGMENT」メッセージまたはセグメントが終了したことを示す同様のメッセージ(たとえば、同様のテキストベースのメッセージ)が後続する複数のセグメントに対してMDEを配信してもよい。図6の例では、MDEの配信(240A〜240N)およびセグメントの終了の配信(242)は、新しいチャネルに対するMPDをDASHクライアントに配信する(244)前に発生する。
図6に示していないが、セグメントのデータを配信した後、DASHクライアント208はメディアデータをセグメントから抽出し、抽出されたメディアデータをプレゼンテーションのために対応するデコーダに配信してもよい。図5に関して、たとえば、DASHクライアント208は、抽出されたメディアデータをデコーダ210に配信してもよい。デコーダ210は次に、メディアデータを復号し、復号されたメディアデータをプレゼンテーションのためにプレゼンテーションデバイス212に配信してもよい。
このようにして、図6の方法は、ストリーミングクライアントを含むクライアントデバイスのプロキシサーバによって、クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定するステップと、その決定に応答して、現在のチャネルのメディアデータに対する要求をストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従ってクライアントデバイスのストリーミングクライアントにメディアデータを配信するステップとを含むメディアデータを転送する方法の一例を表す。
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得、またはコンピュータ可読媒体を介して送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号または搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品がコンピュータ可読媒体を含んでもよい。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlue-rayディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生する一方、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せはまた、コンピュータ可読媒体の範囲内に同じく含まれるものとする。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサによって実行されてよい。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明する機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に設けられてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素において全体的に実施されてよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、また1組の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 オーバージエア(OTA)ミドルウェアユニット
102 プロキシサーバ
104 キャッシュ
106 OTA受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
122 メディアプレゼンテーション記述(MPD)
124A 表現
124N 表現
126 ヘッダデータ
128 セグメント
128A セグメント
128N セグメント
130 ヘッダデータ
132A セグメント
132N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 動画(MOOV)ボックス
156 動画ヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 動画延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 ムービーフラグメントボックス
166 動画フラグメントランダムアクセス(MFRA)ボックス
200 システム
202 リモート
204 チャネルセレクタ
206 ROUTEハンドラ
208 DASHクライアント
210 デコーダ
212 プレゼンテーションデバイス
214 HTTP/WSプロキシサーバ
216 データストレージデバイス
218 ブロードキャスト構成要素
220 ブロードバンド構成要素
230 URL(WS)
232 Media(WS)送信
234 END SEGMENT(WS)送信
236 チャネル変更送信
238 チャネル変更およびURL送信
240A MDE送信
240N MDE送信
242 セグメントの終了送信
244 MPD送信

Claims (41)

  1. メディアデータを転送する方法であって、
    ストリーミングクライアントを含むクライアントデバイスのプロキシサーバによって、
    前記クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定するステップと、
    前記クライアントデバイスのための前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したとの前記決定に応答して、前記現在のチャネルのメディアデータに対する要求を前記ストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従って前記クライアントデバイスの前記ストリーミングクライアントに前記メディアデータを配信するステップとを含む、方法。
  2. 配信するステップが、前記現在のチャネルのマニフェストファイルを前記ストリーミングクライアントに送信することなく、前記現在のチャネルの前記メディアデータを前記ストリーミングクライアントに配信するステップを含む、請求項1に記載の方法。
  3. 配信するステップが、前記現在のチャネルのマニフェストファイルを前記ストリーミングクライアントに送信する前に、前記現在のチャネルの前記メディアデータの少なくとも一部分を前記ストリーミングクライアントに配信するステップを含み、前記方法が、前記マニフェストファイルを前記ストリーミングクライアントに送信するステップをさらに含む、請求項1に記載の方法。
  4. 前記マニフェストファイルが、メディアプレゼンテーション記述(MPD)ファイルを含む、請求項3に記載の方法。
  5. 前記マニフェストファイルを送信するステップが、前記マニフェストファイルを前記現在のチャネルの前記メディアデータとともに帯域内で送信するステップを含む、請求項3に記載の方法。
  6. 前記マニフェストファイルを送信するステップが、
    前記マニフェストファイルに対する要求を前記ストリーミングクライアントから受信するステップと、
    前記要求に応答して、前記現在のチャネルの前記メディアデータに対して帯域外で前記マニフェストファイルを送信するステップとを含む、請求項3に記載の方法。
  7. 配信するステップが、
    前記前のチャネルの最後に受信されたセグメントを前記ストリーミングクライアントに送信するステップと、
    前記現在のチャネルの最初のセグメントを前記ストリーミングクライアントに送信するステップとを含む、請求項1に記載の方法。
  8. 前記前のチャネルの前記最後に受信されたセグメントを送信した後かつ前記現在のチャネルの前記最初のセグメントを送信する前に、前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したことを示すデータを前記ストリーミングクライアントに送信するステップをさらに含む、請求項7に記載の方法。
  9. 前記同調チャネルが変化したことを示す前記データがテキストベースのメッセージを含む、請求項8に記載の方法。
  10. 前記同調チャネルが変化したことを示す前記データが、前記現在のチャネルのユニフォームリソースロケータ(URL)を含む、請求項8に記載の方法。
  11. 前記同調チャネルが変化したことを示す前記データが、前記前のチャネルのURLと、前記前のチャネルのデータのサブミットが終了したことの表示とを含む、請求項8に記載の方法。
  12. 決定するステップが、前記同調チャネルが前記現在のチャネルに変化したことを示すデータを、前記プロキシサーバが通信可能に結合されたチャネル選択デバイスから受信するステップを含む、請求項1に記載の方法。
  13. 前記チャネル選択デバイスが、オーバージエア(OTA)テレビジョンチューナを備える、請求項12に記載の方法。
  14. 前記チャネル選択デバイスが、マルチメディアブロードキャストマルチキャストサービス(MBMS)ユニットまたは拡張MBMS(eMBMS)ユニットを備える、請求項12に記載の方法。
  15. 前記メディアデータを前記チャネル選択デバイスから受信するステップをさらに含む、請求項12に記載の方法。
  16. ハイパーテキスト転送プロトコル(HTTP)ハンドシェイクの間に、前記ウェブソケットサブプロトコルを前記ストリーミングクライアントと交渉するステップをさらに含む、請求項1に記載の方法。
  17. 前記クライアントデバイスが、前記プロキシサーバと前記ストリーミングクライアントとを含む、請求項1に記載の方法。
  18. 前記同調チャネルが変化したと決定する前に、前記前のチャネルのユニフォームリソースロケータ(URL)を指定する要求を前記ストリーミングクライアントから受信するステップをさらに含み、前記URLが「ws://」プレフィックスを含む、請求項1に記載の方法。
  19. メディアデータを転送するためのデバイスであって、
    メディアデータを記憶するように構成されたメモリと、
    ストリーミングクライアントを含むクライアントデバイスのプロキシサーバを実行するように構成された1つまたは複数のプロセッサとを備え、前記プロキシサーバが、
    前記クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することと、
    前記クライアントデバイスのための前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したとの前記決定に応答して、前記現在のチャネルのメディアデータに対する要求を前記ストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従って前記クライアントデバイスの前記ストリーミングクライアントに前記メディアデータを配信することとを行うように構成される、デバイス。
  20. 前記デバイスが前記クライアントデバイスを備え、前記1つまたは複数のプロセッサが前記ストリーミングクライアントを実行するように構成される、請求項19に記載のデバイス。
  21. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、
    前記現在のチャネルのマニフェストファイルを前記ストリーミングクライアントに送信する前に、前記現在のチャネルの前記メディアデータの少なくとも一部分を前記ストリーミングクライアントに配信することと、
    前記マニフェストファイルを前記ストリーミングクライアントに送信することとを行うように構成される、請求項19に記載のデバイス。
  22. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、前記マニフェストファイルを前記現在のチャネルの前記メディアデータとともに帯域内で送信するように構成される、請求項21に記載のデバイス。
  23. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、
    前記前のチャネルの最後に受信されたセグメントを前記ストリーミングクライアントに送信することと、
    前記現在のチャネルの最初のセグメントを前記ストリーミングクライアントに送信することとを行うように構成される、請求項19に記載のデバイス。
  24. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、
    前記前のチャネルの前記最後に受信されたセグメントを送信した後かつ前記現在のチャネルの前記最初のセグメントを送信する前に、前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したことを示すデータを前記ストリーミングクライアントに送信するようにさらに構成される、請求項23に記載のデバイス。
  25. 前記同調チャネルが変化したことを示す前記データが、前記現在のチャネルのユニフォームリソースロケータ(URL)を含む、請求項24に記載のデバイス。
  26. 前記同調チャネルが変化したことを示す前記データが、前記前のチャネルのURLと、前記前のチャネルのデータのサブミットが終了したことの表示とを含む、請求項24に記載のデバイス。
  27. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、前記同調チャネルが前記現在のチャネルに変化したことを示すデータを、前記プロキシサーバが通信可能に結合されたチャネル選択デバイスから受信するように構成される、請求項19に記載のデバイス。
  28. 前記1つまたは複数のプロセッサによって実行される前記プロキシサーバが、ハイパーテキスト転送プロトコル(HTTP)ハンドシェイクの間に、前記ウェブソケットサブプロトコルを前記ストリーミングクライアントと交渉するように構成される、請求項19に記載のデバイス。
  29. 前記プロキシサーバが、前記同調チャネルが変化したと決定する前に、前記前のチャネルのユニフォームリソースロケータ(URL)を指定する要求を前記ストリーミングクライアントから受信するように構成され、前記URLが「ws://」プレフィックスを含む、請求項19に記載のデバイス。
  30. メディアデータを転送するためのデバイスであって、
    クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定するための手段であって、前記クライアントデバイスがストリーミングクライアントを実行する、決定するための手段と、
    前記クライアントデバイスのための前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したとの前記決定に応答して、前記現在のチャネルのメディアデータに対する要求を前記ストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従って前記クライアントデバイスの前記ストリーミングクライアントに前記メディアデータを配信するための手段とを含む、デバイス。
  31. 配信するための前記手段が、
    前記現在のチャネルのマニフェストファイルを前記ストリーミングクライアントに送信する前に、前記現在のチャネルの前記メディアデータの少なくとも一部分を前記ストリーミングクライアントに配信するための手段と、
    前記マニフェストファイルを前記ストリーミングクライアントに送信するための手段とを含む、請求項30に記載のデバイス。
  32. 配信するための前記手段が、
    前記前のチャネルの最後に受信されたセグメントを前記ストリーミングクライアントに送信するための手段と、
    前記現在のチャネルの最初のセグメントを前記ストリーミングクライアントに送信するための手段とを含む、請求項30に記載のデバイス。
  33. 前記前のチャネルの前記最後に受信されたセグメントを送信した後かつ前記現在のチャネルの前記最初のセグメントを送信する前に、前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したことを示すデータを前記ストリーミングクライアントに送信するための手段をさらに含む、請求項32に記載のデバイス。
  34. ハイパーテキスト転送プロトコル(HTTP)ハンドシェイクの間に、前記ウェブソケットサブプロトコルを前記ストリーミングクライアントと交渉するための手段をさらに含む、請求項30に記載のデバイス。
  35. 前記同調チャネルが変化したと決定する前に、前記前のチャネルのユニフォームリソースロケータ(URL)を指定する要求を前記ストリーミングクライアントから受信するための手段をさらに含み、前記URLが「ws://」プレフィックスを含む、請求項30に記載のデバイス。
  36. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、実行されたとき、
    クライアントデバイスのための同調チャネルが前のチャネルから現在のチャネルに変化したと決定することであって、前記クライアントデバイスがストリーミングクライアントを実行する、決定することと、
    前記クライアントデバイスのための前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したとの前記決定に応答して、前記現在のチャネルのメディアデータに対する要求を前記ストリーミングクライアントから受信することなく、ウェブソケットサブプロトコルに従って前記クライアントデバイスの前記ストリーミングクライアントに前記メディアデータを配信することとをプロセッサに行わせる、コンピュータ可読記憶媒体。
  37. 前記メディアデータを配信することを前記プロセッサに行わせる前記命令が、
    前記現在のチャネルのマニフェストファイルを前記ストリーミングクライアントに送信する前に、前記現在のチャネルの前記メディアデータの少なくとも一部分を前記ストリーミングクライアントに配信することと、
    前記マニフェストファイルを前記ストリーミングクライアントに送信することとを前記プロセッサに行わせる命令を含む、請求項36に記載のコンピュータ可読記憶媒体。
  38. 前記メディアデータを配信することを前記プロセッサに行わせる前記命令が、
    前記前のチャネルの最後に受信されたセグメントを前記ストリーミングクライアントに送信することと、
    前記現在のチャネルの最初のセグメントを前記ストリーミングクライアントに送信することとを前記プロセッサに行わせる命令を含む、請求項36に記載のコンピュータ可読記憶媒体。
  39. 前記前のチャネルの前記最後に受信されたセグメントを送信した後かつ前記現在のチャネルの前記最初のセグメントを送信する前に、前記同調チャネルが前記前のチャネルから前記現在のチャネルに変化したことを示すデータを前記ストリーミングクライアントに送信することを前記プロセッサに行わせる命令をさらに含む、請求項38に記載のコンピュータ可読記憶媒体。
  40. ハイパーテキスト転送プロトコル(HTTP)ハンドシェイクの間に、前記ウェブソケットサブプロトコルを前記ストリーミングクライアントと交渉することを前記プロセッサに行わせる命令をさらに含む、請求項36に記載のコンピュータ可読記憶媒体。
  41. 前記同調チャネルが変化したと決定する前に、前記前のチャネルのユニフォームリソースロケータ(URL)を指定する要求を前記ストリーミングクライアントから受信することを前記プロセッサに行わせる命令をさらに含み、前記URLが「ws://」プレフィックスを含む、請求項36に記載のコンピュータ可読記憶媒体。
JP2017558549A 2015-05-13 2016-05-05 ウェブソケットサブプロトコルを使用したメディアデータの転送 Pending JP2018521538A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562160928P 2015-05-13 2015-05-13
US62/160,928 2015-05-13
US15/146,538 US20160337424A1 (en) 2015-05-13 2016-05-04 Transferring media data using a websocket subprotocol
US15/146,538 2016-05-04
PCT/US2016/030948 WO2016182844A1 (en) 2015-05-13 2016-05-05 Transferring media data using a websocket subprotocol

Publications (1)

Publication Number Publication Date
JP2018521538A true JP2018521538A (ja) 2018-08-02

Family

ID=56101784

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017558549A Pending JP2018521538A (ja) 2015-05-13 2016-05-05 ウェブソケットサブプロトコルを使用したメディアデータの転送

Country Status (5)

Country Link
US (1) US20160337424A1 (ja)
EP (1) EP3295674A1 (ja)
JP (1) JP2018521538A (ja)
CN (1) CN107637040A (ja)
WO (1) WO2016182844A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10511805B2 (en) 2016-04-14 2019-12-17 Popio Ip Holdings, Llc Methods and systems for multi-pane video communications to execute user workflows
US10827149B2 (en) 2016-04-14 2020-11-03 Popio Ip Holdings, Llc Methods and systems for utilizing multi-pane video communications in connection with check depositing
US10218938B2 (en) 2016-04-14 2019-02-26 Popio Ip Holdings, Llc Methods and systems for multi-pane video communications with photo-based signature verification
US11523087B2 (en) 2016-04-14 2022-12-06 Popio Mobile Video Cloud, Llc Methods and systems for utilizing multi-pane video communications in connection with notarizing digital documents
US10218939B2 (en) 2016-04-14 2019-02-26 Popio Ip Holdings, Llc Methods and systems for employing virtual support representatives in connection with mutli-pane video communications
USD845972S1 (en) 2016-04-14 2019-04-16 Popio Ip Holdings, Llc Display screen with graphical user interface
US9699406B1 (en) * 2016-04-14 2017-07-04 Alexander Mackenzie & Pranger Methods and systems for multi-pane video communications
CN107370775B (zh) * 2016-05-11 2020-04-28 阿里巴巴集团控股有限公司 一种启动应用的方法和***
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10574718B2 (en) * 2016-08-25 2020-02-25 Comcast Cable Communications, Llc Packaging content for delivery
JP7061121B2 (ja) * 2016-11-10 2022-04-27 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 配信性能を改善するためのリソースセグメント化
US20180176278A1 (en) * 2016-12-19 2018-06-21 Qualcomm Incorporated Detecting and signaling new initialization segments during manifest-file-free media streaming
US10440085B2 (en) * 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming
US10476943B2 (en) 2016-12-30 2019-11-12 Facebook, Inc. Customizing manifest file for enhancing media streaming
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
US11659057B2 (en) * 2017-04-19 2023-05-23 Comcast Cable Communications, Llc Methods and systems for content delivery using server push
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
US10887645B2 (en) 2017-07-13 2021-01-05 Qualcomm Incorporated Processing media data using file tracks for web content
EP3468207A1 (en) * 2017-10-06 2019-04-10 Nagravision S.A. Masking technique
CN107888932A (zh) * 2017-10-20 2018-04-06 深圳思麦杰科技有限公司 一种基于浏览器的跨平台视频直播的***及方法
US11321516B2 (en) * 2018-01-19 2022-05-03 Qualcomm Incorporated Processing dynamic web content of an ISO BMFF web resource track
US11178453B2 (en) * 2018-01-29 2021-11-16 Qualcomm Incorporated Signaling and reporting interactivity usage in streaming services
CN108111634B (zh) * 2018-02-28 2020-11-20 北京焦点新干线信息技术有限公司 一种基于websocket协议与http协议的即时数据传输方法及***
CN110381344A (zh) * 2018-11-27 2019-10-25 北京京东尚科信息技术有限公司 无人配送车视频流上传方法、装置及存储介质和电子设备
US11509972B2 (en) 2019-07-09 2022-11-22 Dolby International Ab Method and device for personalization of media data for playback
CN110599296A (zh) * 2019-08-23 2019-12-20 达疆网络科技(上海)有限公司 基于Netty和WebSocket协议实现Web端自动打印订单服务方法
CN117157988A (zh) * 2021-04-16 2023-12-01 抖音视界有限公司 最小化直播流中的初始化延迟
CN114500487A (zh) * 2021-11-15 2022-05-13 广州方阵科技有限公司 一种端到端超文本传输协议转换***
CN114827670A (zh) * 2022-06-30 2022-07-29 椭圆方程（深圳）信息技术有限公司 一种视频播放方法、装置及电子设备
US11652890B1 (en) 2022-07-13 2023-05-16 Oxylabs, Uab Methods and systems to maintain multiple persistent channels between proxy servers
US20240073056A1 (en) * 2022-08-31 2024-02-29 Simple Things Inc. Flow programming platform for home automation
CN115914410B (zh) * 2023-03-03 2023-07-14 无锡顶视科技有限公司 基于数据驱动的数字孪生仿真方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7873710B2 (en) * 2007-02-06 2011-01-18 5O9, Inc. Contextual data communication platform
CN102449975A (zh) * 2009-04-09 2012-05-09 诺基亚公司 用于媒体文件流式传输的***、方法和装置
KR20100126053A (ko) * 2009-05-22 2010-12-01 삼성전자주식회사 스트리밍 서비스 제공방법, 스트리밍 서비스 수신방법, 이에 적용되는 스트리밍 서비스 제공 서버 및 클라이언트 장치
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
JP5607095B2 (ja) * 2012-03-19 2014-10-15 株式会社東芝 情報生成装置および情報出力装置
WO2014076052A1 (en) * 2012-11-13 2014-05-22 Telefonaktiebolaget L M Ericsson (Publ) Processing of multimedia data
EP3017605B1 (en) * 2013-07-03 2022-12-07 Koninklijke KPN N.V. Streaming of segmented content

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
US12022306B2 (en) * 2019-05-31 2024-06-25 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring

Also Published As

Publication number Publication date
WO2016182844A1 (en) 2016-11-17
CN107637040A (zh) 2018-01-26
US20160337424A1 (en) 2016-11-17
EP3295674A1 (en) 2018-03-21

Similar Documents

Publication Publication Date Title
JP2018521538A (ja) ウェブソケットサブプロトコルを使用したメディアデータの転送
CN107743703B (zh) 用于媒体数据传输的方法、设备及计算机可读存储介质
CN107810624B (zh) 用于检索媒体数据的方法、设备和计算机可读存储介质
CN110089122B (zh) 用于检索媒体数据的方法、媒体装置及计算机可读存储媒体
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
US11617019B2 (en) Retrieving and accessing segment chunks for media streaming
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
JP6254291B2 (ja) Ｄａｓｈのロバストなライブ動作
US20180176278A1 (en) Detecting and signaling new initialization segments during manifest-file-free media streaming
US11184665B2 (en) Initialization set for network streaming of media data
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
TW202127897A (zh) 用於串流傳輸媒體資料的多解碼器介面
JP2024525323A (ja) リアルタイム拡張現実通信セッション
JP2022550528A (ja) 適応ビットレートマルチキャストのための修復機構

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171114