JP6807852B2 - Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング - Google Patents

Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング Download PDF

Info

Publication number
JP6807852B2
JP6807852B2 JP2017545751A JP2017545751A JP6807852B2 JP 6807852 B2 JP6807852 B2 JP 6807852B2 JP 2017545751 A JP2017545751 A JP 2017545751A JP 2017545751 A JP2017545751 A JP 2017545751A JP 6807852 B2 JP6807852 B2 JP 6807852B2
Authority
JP
Japan
Prior art keywords
data
lct
media
representation
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017545751A
Other languages
English (en)
Other versions
JP2018512771A (ja
JP2018512771A5 (ja
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 JP2018512771A publication Critical patent/JP2018512771A/ja
Publication of JP2018512771A5 publication Critical patent/JP2018512771A5/ja
Application granted granted Critical
Publication of JP6807852B2 publication Critical patent/JP6807852B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • 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/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)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本出願は、各々の内容全体が参照によって本明細書に組み込まれている、2015年3月4日に出願した米国仮出願第62/128,380号、および2015年3月5日に出願した米国仮出願第62/128,943号の利益を主張するものである。
本開示は、符号化ビデオデータの記憶および転送に関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンストビデオコーディング(AVC)、ITU-T H.265/MPEG-H Part 2(高効率ビデオコーディング(HEVC:High Efficiency Video Coding)とも呼ばれる)によって定められた規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームもしくはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
米国仮出願第62/114,423号
一般に、本開示は、表現に対するメディアプレゼンテーション記述(MPD:Media Presentation Description)などのマニフェストファイルを使用することなく、階層符号化トランスポート(LCT:layered coding transport)によって搬送される1つまたは複数の表現のメディアデータにアクセスするための様々な技法について説明する。たとえば、LCTセッションインスタンス記述(LSID:LCT Session Instance Description)は、メディアデータにアクセスするためのサービスの起動および/または連続動作のために使用されるマニフェストファイルデータのうちの少なくともいくつかを含み得る。たとえば、LSIDは、表現の特性を示す情報を含み得る。追加または代替として、LCTセッションのパケットは、パケットが表現のセグメントにどのように関係するか、たとえばどのパケットが各セグメントに対応するかを示す、割り当てられたデータを有するLCTヘッダを含み得る。このようにして、クライアントデバイスは、マニフェストファイルを受信することなく(または受信する前に)表現のうちの1つまたは複数の表現の消費を開始し得る。
一例では、メディアデータを受信する方法は、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH:Dynamic Adaptive Streaming over HTTP)メディアプレゼンテーションの複数の表現を決定するステップであって、LSIDが複数のLCTセッションを表す情報を含み、LCTセッションの各々が表現のそれぞれの表現のデータを含む、決定するステップと、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始するステップとを含み、消費の開始は、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットを受信するステップと、パケットのデータをメディアデコーダに供給するステップとを含む。
別の例では、メディアデータを受信するためのデバイスは、メディアデータを復号するように構成された1つまたは複数のメディアデコーダと、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を受信するように構成されたネットワークインターフェースであって、LSIDは複数のLCTセッションを表す情報を含み、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータとLCTセッションのうちの1つまたは複数のLCTセッションのデータとを含む、ネットワークインターフェースと、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始するように構成されプロセッサとを含み、消費を開始するために、プロセッサは、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットをネットワークインターフェースを介して受信することとパケットのデータを1つまたは複数のメディアデコーダに供給することとを行うように構成される。
別の例では、メディアデータを受信するためのデバイスは、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定するための手段であって、LSIDが複数のLCTセッションを表す情報を含み、LCTセッションの各々が表現のそれぞれの表現のデータを含む、決定するための手段と、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始するための手段とを含み、消費を開始するための手段は、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットを受信するための手段と、パケットのデータをメディアデコーダに供給するための手段とを含む。
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、その命令は、実行されたとき、メディアデータを受信するためのデバイスのプロセッサに、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定することであって、LSIDが複数のLCTセッションを表す情報を含み、LCTセッションの各々が表現のそれぞれの表現のデータを含む、決定することと、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始することとを行わせ、プロセッサに消費を開始させる命令は、プロセッサに、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットを受信することと、パケットのデータをメディアデコーダに供給することとを行わせる命令を含む。
別の例では、メディアデータを送る方法は、複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築するステップであって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、ステップと、LSIDを出力するステップと、対応するLCTセッション内の表現のデータを出力するステップとを含む。
別の例では、メディアデータを送るためのデバイスは、複数の階層符号化トランスポート(LCT)セッションのデータを出力するためのネットワークインターフェースと、プロセッサとを含み、プロセッサは、複数のLCTセッションを表す情報を含むLCTセッションインスタンス記述(LSID)を構築することであって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、構築することと、ネットワークインターフェースを介してLSIDを出力することと、およびネットワークインターフェースを介して対応するLCTセッション内の表現のデータを出力することとを行うように構成される。
別の例では、メディアデータを送るためのデバイスは、複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築するための手段であって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、手段と、LSIDを出力するための手段と、対応するLCTセッション内の表現のデータを出力するための手段とを含む。
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、その命令は、実行されたとき、メディアデータを送るためのデバイスのプロセッサに、複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築することであって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、構築することと、LSIDを出力することと、および対応するLCTセッション内の表現のデータを出力することとを行わせる。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。 ブロードキャスト配信においてしばしば生じる例示的なシナリオを示す概念図である。 本開示の技法を実行し得る例示的なシステムを示す概念図である。 本開示の技法を実行し得る例示的なシステムを示す概念図である。 FLUTEを介するDASHの例におけるサービスエントリの異なる態様を示す概念図である。 ROUTEを介するDASHの例に対するサービスエントリの異なる態様を示す概念図である。 本開示の技法によるデータを搬送するために使用され得るRFC5651に従うヘッダフィールドの例示的なセットを示す概念図である。 オブジェクトのプレフィックスが復号のために次のレイヤにリリースされ得るときをシグナリングするための様々なオプションを示す概念図である。 データ受信のための例示的なモデルを示す概念図である。 メディアデータを受信するための例示的なシステムを示す概念図である。 手順を送る一例を示す概念図である。 例示的なハイブリッドDASHクライアントモデルを示す概念図である。 本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための例示的な方法を示すフローチャートである。 本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための別の例示的な方法を示すフローチャートである。 本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための別の例示的な方法を示すフローチャートである。
一般に、本開示は、メディアストリームの配信およびプレイアウトをサポートするIPベースのブロードキャストメディア配信システムを生成するために、単方向プロトコル、たとえば、単方向伝送によるファイル配信(FLUTE:File Delivery over Unidirectional Transport)、単方向伝送によるリアルタイムオブジェクト配信(ROUTE:Real-Time Object Delivery over Unidirectional Transport)、または非同期階層符号化およびNACK指向高信頼マルチキャストプロトコルのためのオブジェクト配信(FCAST:Object Delivery for the Asynchronous Layered Coding and NACK-Oriented Reliable Multicast Protocols)、ならびにISOベースメディアファイルフォーマット(ISO BMFF:ISO base media file format)に基づく動的適応ストリーミングオーバーHTTP(DASH)セグメント、および場合によっては同様にMPEG-2トランスポートストリーム(TS)などの他のフォーマットを、その能力が使用することを可能にする技法について説明し、このメディアストリームは、
・互いの間で同期されるべきである(ISO BMFFによって取り扱われる)。
・ランダムにアクセスされるべきである(配信プロトコルにおける特定のシグナリングによって取り扱われる)。
・再バッファリングおよびストーリングが発生しないように再生されるべきである。
・ブロードバンドおよびユニキャスト上で供給および提供されるメディアストリームと組み合わされるべきである。
・マルチプログラム配信および多重化を可能にする。
・低い起動遅延および速いチャネル変更を可能にする。
・送信側および受信側においてコンテンツを接合することを可能にする。
・および、ブロードキャスト配信システムにおいてDASHの全特徴を提供する。
より具体的には、本開示の技法は、表現に対するマニフェストファイル(メディアプレゼンテーション記述(MPD)など)を受信することなく(または受信する前に)、階層符号化トランスポート(LCT)セッションを介して1つまたは複数の表現のメディアデータの受信を可能にする。このようにして、本開示の技法は、メディアデータの消費を開始すること(たとえば、サービス起動を実行すること)と関連付けられたレイテンシを低減し得る。すなわち、これらの技法がなければ、クライアントデバイスは、マニフェストファイルの受信を待つことが必要になり、そのことが、劣悪なユーザエクスペリエンス(たとえば、黒い画面を見ることおよび/またはオーディオ再生を聞けないこと)を生じる場合がある。これらの技法を使用することでレイテンシが低減され、それによってユーザエクスペリエンスが改善され得る(たとえば、オーディオデータおよび/またはビデオデータのより速い再生が可能になる)。
本開示の技法は、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の様々な要素は、一般に、以下でより詳細に説明するように、図5および図6に示す例の同様の要素に対応し得る。同様に、クライアントデバイス40の構成要素は、一般に、同じく以下でさらに詳細に説明するように、図11、図12および図14の構成要素に対応し得る。
図1の例では、システム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)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。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などの加入側クライアントデバイスに向けさせることができる。
図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は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。
ネットワークインターフェース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に送る。
システム10の様々な要素(たとえば、クライアントデバイス40、コンテンツ準備デバイス20および/またはサーバデバイス60)は、本開示の様々な技法を実行するように構成され得る。一般に、システム10の例は、ISOベースメディアファイルフォーマット(ISO BMFF)またはセグメント化ISO BMFFファイルに基づいてDASHメディアプレゼンテーションの消費を開始するように構成され得る様々な要素を含み、セグメント化ISO BMFFファイルに対して、セグメントは、階層符号化トランスポート(LCT)オブジェクト配信プロトコル、たとえばMPD(たとえば、マニフェストファイル66)がなくかつトランスポートオブジェクト識別子(TOI)とURL(FDT、EFDT、またはGFDもしくはROUTEにおけるエンティティヘッダなど)との間の関連メタデータの配信がないROUTEプロトコルを介して配信され、MPDシグナリングは、他の手段、たとえばROUTEにおけるLCTセッションインスタンス記述(LSID)、FLUTEにおけるSDP、LCTヘッダ、ISO BMFF IS、などによって与えられる。すなわち、クライアントデバイス40は、サービスエントリポイントにアクセスすることを含み得るサービス起動を実行することによって消費を開始し得る。
また、システム10の要素(クライアントデバイス40など)は、(追加または代替として)上記の配信仮説の下で単方向ストリーム、すなわちブロードキャスト配信を完全に消費するように構成され得る。
また、システム10の要素は、(追加または代替として)MPD(たとえば、マニフェストファイル66)なしにDASHメディアプレゼンテーションを開始するが、初期起動およびプレイアウト後、MPDは、より豊富な情報を取得し、ブロードバンド/ユニキャスト配信と組み合わせるために、受信され、処理され得る(たとえば、サーバデバイス60によって配信され、クライアントデバイス40によって受信され得る)。
MPDは、ブロードキャストの同調またはチャネル変更のために絶対に必要な情報だけを含有してよく、以下のうちの1つまたは複数が適用され得る:
・MPD情報がまったく必要でないときは、MPDは空であり得る。
・通常のMPDコピー(必ずしも絶対に必要であるとは限らない、たとえば何らかの強化または最適化のために必要であるにすぎないいくつかの情報を有する)が、いくつかのランダムアクセスポイント(RAP)において疎に含まれ、2つの通常のMPDコピーの間で、軽量のMPD(絶対に必要な情報だけを有する)が各RAPにおいて含まれる。
また、システム10の要素は、(追加または代替として)受信側が、同じROUTEセッションにおける他のデータに対して、そのデータを消費(復号およびレンダリング)しているときの時間を反映する、ROUTEパケットに追加される各パケットのターゲット送信時間を使用するように構成されてよく、以下のうちの1つまたは複数がターゲット送信時間に適用される。
・ターゲット送信時間によってこの時間がLCTヘッダ内でシグナリングされる。
・ターゲット送信時間によってこの時間がCCヘッダ内でシグナリングされる。
・ターゲット送信時間によってこの時間が拡張ヘッダ内でシグナリングされる。
・この時間は相対的時間である。
・この時間はネットワークタイムプロトコル(NTP)時間などの絶対的壁時計時間である。
・この時間は相対的時間であり、リリース時間はパケット内でシグナリングされ、パケットは、リリース時間がターゲット送信時間以下であるときだけ消費のためにリリースされる。
また、システム10の要素は、(追加または代替として)パケットが存在するときにパケット内に含有されるデータを受信側が消費(復号およびレンダリング)しているかどうかを反映する、ROUTEパケットに追加されたフラグを使用するように構成されてよく、以下のうちの1つまたは複数が適用され得る。
・フラグが1に等しいとき、パケットは送信側によって保持され、消費のために受信側に送られない。
・フラグが0に等しいとき、パケットは消費のために送信側によって受信側にリリースされる。
・フラグの値は、オブジェクトの最後のパケットに対して1に等しいことが必要である。
したがって、システム10は、顕著な不都合なしに、帯域幅効率、初期起動遅延、簡潔さ、頑強さ、拡張性、および複雑さの理由に対する有利な手法である設計を実施し得る。
このようにして、以下でより詳細に説明するように、サーバデバイス60は、複数の階層符号化トランスポート(LCT)セッションのデータを出力するためのネットワークインターフェースと、プロセッサとを含む、メディアデータを送るためのデバイスの一例を表し、プロセッサは、複数のLCTセッションを表す情報を含むLCTセッションインスタンス記述(LSID)を構築することであって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、構築することと、ネットワークインターフェースを介してLSIDを出力することと、およびネットワークインターフェースを介して対応するLCTセッション内の表現のデータを出力することとを行うように構成される。
同様に、クライアントデバイス40は、メディアデータを復号するように構成された1つまたは複数のメディアデコーダと、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を受信するように構成されたネットワークインターフェースであって、LSIDは複数のLCTセッションを表す情報を含み、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータと、LCTセッションのうちの1つまたは複数のLCTセッションのデータとを含む、ネットワークインターフェースと、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始するように構成されたプロセッサとを含む、メディアデータを受信するためのクライアントデバイスの一例を表しており、消費を開始するためにプロセッサは、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットをネットワークインターフェースを介して受信することと、パケットのデータを1つまたは複数のメディアデコーダに供給することとを行うように構成される。
図2は、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図2の例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104と複数の表現110A〜110Nとを含む。表現110Aは、任意のヘッダデータ112とセグメント114A〜114N(セグメント114)とを含む一方、表現110Nは、任意のヘッダデータ122とセグメント124A〜124N(セグメント124)とを含む。文字Nが、便宜的に、表現110A、110Nの各々内の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現110A、110Nの間に、異なる数の動画フラグメントが存在し得る。
MPD104は、表現110A〜110Nとは別個のデータ構造を含み得る。MPD104は、図1のマニフェストファイル66に対応し得る。同様に、表現110A〜110Nは、図1の表現68に対応する場合がある。一般に、MPD104は、コーディング特性およびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110A〜110Nの特性を一般に表す、データを含み得る。
ヘッダデータ112は、存在するとき、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント114のうちのどれがランダムアクセスポイントを含むのか、セグメント114内のランダムアクセスポイントへのバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の態様を記述し得る。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を記述することができる。追加または代替として、そのような特性はMPD104内に完全に含まれ得る。
セグメント114、124は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。MPD104のデータは、図2の例には示されていないが、そのような特性は、MPD104のデータによって記述され得る。MPD104は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
図3は、図2のセグメント114、124のうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイル150の要素を示すブロック図である。セグメント114、124の各々は、図3の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図3の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、動画(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と動画フラグメント(MOOF)ボックス164と、動画フラグメントランダムアクセス(MFRA)ボックス166とを含む。図3は、ビデオファイルの例を表すが、他のメディアファイルは、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更新ボックスに関する追加の情報を提供する。
MOOVボックス154は、図3の例では、動画ヘッダ(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(図2)がビデオファイル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、図3には示されない)を含み得る。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フレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
図4は、ブロードキャスト配信においてしばしば生じる例示的なシナリオを示す概念図である。シナリオは、次のように説明され得る。
・複数のサービスが(一般的に異なるチャネル上に)配信される。
・サービスはブロードキャスト構成要素を有し、追加のユニキャスト/ブロードバンド構成要素を有してもよい。
・一般的に、サービスは、メタデータによって記述される異なる構成要素、たとえばビデオ、オーディオ、字幕、代替オーディオ、代替ビデオ、などを含む。
・ブロードキャスト上で、各構成要素は、構成要素が選択/フィルタリングされ得るように、異なるトランスポートセッション上で送られ得る。
・構成要素およびサービスはパケットレベルで多重化される。
図4の例では、2つの別個のメディアブロードキャスティング局180A、180Bがある。局180Aは、LSID184と、関連するシグナリングフラグメント186A〜186N(シグナリングフラグメント186)とを含むブートストラップデータ182を供給する。また、局180Aは、オーディオデータ188(図4に示すオーディオデータ188Aおよび188Bを含む)と、ビデオデータ190(図4のビデオデータ190Aおよび190Bを含む)と、時限のテキストデータ192と、ビデオエンハンスメントレイヤデータ194(図4に示すビデオエンハンスメントレイヤデータ194Aおよび194Bを含む)と、代替オーディオ言語データ196(図4に示す代替オーディオ言語データ196Aおよび196Bを含む)とを供給する。一例では、局180Aは、トランスポートセッション識別子(TSI)0を使用するユーザデータグラムプロトコル(UDP)を介するブートストラップデータ182と、TSI1を使用するUDPを介するオーディオデータ188と、TSI2を使用するUDPを介するビデオデータ190と、ブロードバンドを介するビデオエンハンスメントレイヤデータ194と、HTTPを介する代替オーディオ言語データ196とを供給する。
局180Bは、この例では、LSID202と、関連するシグナリングフラグメント204A〜204N(シグナリングフラグメント204)とを含むブートストラップデータ200を供給する。また、局180Bは、オーディオデータ206(図4に示すオーディオデータ206Aおよび206Bを含む)と、ビデオデータ208(図4のビデオデータ208Aおよび208Bを含む)と、アクセシビリティオーディオデータ210(図4に示すアクセシビリティオーディオ言語データ210Aおよび210Bを含む)とを供給する。一例では、局180Aは、トランスポートセッション識別子(TSI)0を使用するユーザデータグラムプロトコル(UDP)を介するブートストラップデータ182と、TSI1を使用するUDPを介するオーディオデータ188と、TSI2を使用するUDPを介するビデオデータ190と、ブロードバンドを介するビデオエンハンスメントレイヤデータ194と、ユニキャスト(たとえば、HTTPによる)を介する代替オーディオ言語データ196とを供給する。
一般に、局180A、180Bは、図1のコンテンツ準備デバイス20およびサーバデバイス60と同様のデバイスを含み得る。具体的には、局180A、180Bは、コンテンツ準備デバイス20および/またはサーバデバイス60に起因する機能と同様の機能を実行する、互いに異なるデバイスを含み得る。追加または代替として、局180A、180Bは、メディアデータを準備し、準備されたメディアデータをコンテンツ配信ネットワーク(CDN)、ローカル系列局、ケーブル会社、あるいはメディアデータをブロードキャストもしくはユニキャストされるネットワークまたはオーバージエア送信を介して配信し得る他のコンテンツ配信者に供給し得る。
図4には示されていないが、データストリーム(すなわち、ブートストラップデータ182、200、オーディオデータ188、206、ビデオデータ190、208、時限のテキストデータ192、ビデオエンハンスメントレイヤデータ194、代替オーディオ言語データ196、およびアクセシビリティオーディオ210)は、メタデータの符号化されたサンプルを含有する静的構成データおよび一連のメディアセグメントを含む初期化セグメント(IS)などのセグメントに編成され得る。セグメントは、タイミングのために十分な情報を含有してよく、それによってデータは復号され、同期されたプレイアウトのために他の表現と一緒に提示され得る。たとえば、オーディオデータ188およびビデオデータ190からのセグメントは、オーディオおよびビデオが再生中に同期されるように、同期データを含み得る。
セグメントは、たとえばDASHによる特定の規則に従う。すなわち、セグメントはデータオブジェクトであり、コンテンツ準備デバイス20またはサーバデバイス60は、他のセグメントとは無関係にセグメントを生成し得る。セグメントは復号順序に従う、すなわち、より低い番号を有するセグメント内に含有されるすべてのデータは、より高いセグメント番号を有するセグメントよりも低い(すなわち、より早い)復号時間を有する。加えて、コンテンツは、いくつかの位置において接合され得る。これは、各表現が新しいISを受信することになる、新しい期間をもたらす。新しいISが与えられ得るが、タイムラインは継続するときの、他の事例が存在する。これは、たとえば、ISが新しいメタデータを含む場合の事例であり得る。
図5は、図1のクライアントデバイス40の取出しユニット52の例示的な構成要素を示すブロック図である。この例では、取出しユニット52は、IPマルチキャストユニット220と、静的構成ユニット222と、ROUTE受信ユニット224と、キャッシュ226と、プロキシサーバ228と、DASHクライアント230とを含む。一般に、DASHクライアント230は、ユニキャスト要求を使用して(たとえば、サーバデバイス60から)ネットワーク74を介して1つまたは複数の表現のセグメントを取り出し得る。追加または代替として、取出しユニット52は、IPマルチキャストユニット220を使用してIPマルチキャストに加入し、1つまたは複数の表現のセグメントを含むIPマルチキャストデータを受信し得る。IPマルチキャストユニット220は、受信されたセグメント232をROUTE受信ユニット224に送ってよく、ROUTE受信ユニット224は受信されたセグメントをキャッシュ226に記憶してよい。次いで、DASHクライアント230は、プロキシサーバユニット228からセグメントを要求し得る。このようにして、DASHクライアント230は、サーバデバイス60のIPアドレス、または取出しユニット52を含むクライアントデバイス40のローカルホストアドレスのいずれかからセグメントを要求し得る。いずれの場合も、DASHクライアント230は、HTTP GETまたは部分Get要求を使用してセグメントを取り出し得る。したがって、取出しユニット52は、一般に、ユニキャストまたはIPマルチキャストを介してセグメントを受信し得る。
データがユニキャストを介して利用可能にされる場合、利用可能なデータは、メディアプレゼンテーション、期間、適応セット、表現、およびセグメントなどのDASH概念を使用してマニフェストファイル(たとえば、メディアプレゼンテーション記述(MPD))の中で記述される。DASHメディアプレゼンテーションの単方向ブロードキャスト配信のための基本配備において、MPDおよびセグメントを、ROUTE、FLUTEまたはFCASTなどのオブジェクト配信プロトコルを使用して通常のデータオブジェクトとして配信することが提案されている。次いで、図1および図5に示すように、オブジェクト受信機は、ローカルサーバからのメディアプレゼンテーションをDASHクライアントに供給するために復元されたオブジェクトを使用し得る(例としてROUTEを使用するが、そのような技法はFLUTEまたはFCASTに対しても同様に適用可能である)。セグメントは、MPD内のURLが、たとえばファイル配信テーブル(FDT)、拡張FDT(EFDT)を介して、またはHTTPエンティティヘッダを使用してオブジェクトの一部として、オブジェクト配信プロトコルで配信されるオブジェクトに割り当てられるように配信される。
送信側(たとえば、サーバデバイス60または同様のデバイス)は、それぞれのセグメントの利用可能時間がMPD内で告知される前に、セグメントがクライアントデバイス40において受信されるようにオブジェクトを配信する。サーバデバイス60(またはコンテンツ準備デバイス20)は、セグメントをパケット化し、それに応じてパケットを多重化する。オブジェクトは、異なるトランスポートオブジェクト識別子(TOI)によって分離されてよく、URLへの割当ては上述のようにもたらされる。より高度な送信セットアップでは、1つの表現のうちのすべてのセグメントが、たとえば専用のユーザデータグラムプロトコル(UDP)ポート、または固有のトランスポートセッション識別子(TSI)によって識別される専用の階層符号化トランスポート(LCT)セッションを使用して、専用のセッション内で配信される。この割当ては、受信側が、DASHクライアント230による表現の選択に基づいて全セッションを選択または無視することを可能にする。
しかしながら、ブロードキャストを介するメディアプレゼンテーションのプロビジョニングは、送信側に対するいくつかの課題を生じる場合がある。なぜならば、送信側は、MPD内でセグメント利用可能時間を適切に設定するために、配信および処理の時間を予測する必要がある場合があるからである。何らかの理由で配信システムが予想より多かれ少なかれ遅延する場合、DASHクライアント230または他のプレーヤの性能に悪影響を及ぼす場合がある。再生の起動が早すぎるかまたは遅すぎる場合がある。起動が早すぎる再生はメディア再生のストールをもたらす場合があり、起動が遅すぎる再生は、通常起こり得るよりも遅いチャネル変更と、増加したエンドツーエンドレイテンシをもたらす場合がある。別の課題は、DASHクライアント230がセグメントおよび含有されるメディアを利用する前に、DASHクライアント230は、FDT(または等価データ構造)およびMPDを受信する必要がある場合があることである。頻度が高いランダムアクセスポイントに対して、これは、メタデータからのオーバーヘッドを増加させる場合がある。
上記でおよび以下でそれぞれより詳細に説明するように、図1および図6は例示的な送信インフラストラクチャを示す。より具体的には、図6は、本開示の技法による異なる送信オプションを提供する基本的送信側アーキテクチャ240の一例を示すブロック図である。この例では、送信側アーキテクチャ240は、マルチビットレートオフラインメディアエンコーダ244と、マルチビットレートライブメディアエンコーダ248と、広告(ad)挿入ユニット252と、DASHオフラインオーサリングユニット250と、DASHライブオーサリングユニット256と、HTTPライブエミュレーションサーバ258と、HTTPライブサーバ260と、ROUTEサーバ262とを含む。この例では、マルチビットレートオフラインメディアエンコーダ244はオーディオ/ビデオ(A/V)ソースコンテンツ242の1つまたは複数のセットを符号化する一方で、マルチビットレートライブメディアエンコーダ248はA/Vソースコンテンツ246AおよびA/Vライブコンテンツ246Bの一方または両方を符号化する。A/Vソースコンテンツ246Aは事前に記録されたコンテンツを表してよく、一方でA/Vライブコンテンツ246Bはオンザフライでキャプチャされているライブコンテンツ、たとえばライブニュースイベント、スポーツイベント、または他のそのようなライブイベントを表してよい。
マルチビットレートオフラインメディアエンコーダ244は、符号化されたメディアコンテンツをDASHオフラインオーサリングユニット250に供給する。DASHオフラインオーサリングユニット250は、一般に、トランスポートのために符号化されたメディアデータを、たとえばDASHを介して準備し得る。たとえば、ビデオデータのために、DASHオフラインオーサリングユニット250は、符号化されたビデオフレームのセットを含むセグメントを準備してよく、符号化されたビデオフレームのセットはランダムアクセスポイント(RAP)ビデオフレームを含み得る。アド挿入ユニット252は、HTTPライブエミュレーションサーバ258によって準備されたメディアストリームの適切なポイントにおいて挿入するための広告コンテンツを準備し得る。同様に、DASHオフラインオーサリングユニット250は、1つまたは複数のメディア表現の準備されたセグメントをHTTPライブエミュレーションサーバ258に供給し得る。
一般に、HTTPライブエミュレーションサーバ258は、HTTPライブサーバ260などのライブメディアサーバをエミュレートする。たとえば、HTTPライブエミュレーションサーバ258は、様々な表現(たとえば、いくつかの例における、オーディオおよびビデオ表現、ならびに時限のテキスト表現)のセグメントに対するセグメント利用可能時間をシグナリングし得る。HTTPライブエミュレーションサーバ258は、セグメントをROUTEサーバ262に供給してよく、ROUTEサーバ262は、ヒントおよびタイミング情報254に基づいて、セグメントを特定の時間にIPマルチキャストを使用してROUTEを介して出力し得る。追加または代替として、ROUTEサーバ262は、ライブDASHコンテンツをHTTPライブサーバ260から受信してよく、HTTPライブサーバ260は、DASHコンテンツをDASHライブオーサリングユニット256から受信し、DASHライブオーサリングユニット256は、マルチビットレートライブメディアエンコーダ248から受信された符号化されたメディアデータからライブDASHコンテンツを準備し得る。単一のマルチビットレートライブメディアエンコーダ248がこの例で示されているが、いくつかの例では、複数のエンコーダがライブメディアデータを符号化するために利用されてよいことを理解されたい。
送信側アーキテクチャ240は、DASHを使用して生成された疑似ライブサービスおよび/またはライブサービスとしての一方または両方のオンデマンドコンテンツを提供し得る。加えて、送信側アーキテクチャ240は、アド挿入ユニット252などの広告(アド)挿入をサポートするツールを含み得る。別のオプションは、たとえば、MPDレベルおよび/またはセグメントレベルを使用して再同期を可能にするために、複数の期間を送ることによって何らかの頑健さをDASHに加えることである。コンテンツはHTTPサービスを介して利用可能にされてよく、それによってユニキャストを介して(たとえば、ネットワーク74を介して)接続されたクライアントは、ユニキャストを介してサービスの全部または一部にアクセスし得る。1つの例示的な使用事例は、ファイル配信プロトコルを介する配信である。すなわち、送信側アーキテクチャ240は、ファイル配信プロトコル、たとえばFLUTE、FCAST、MPEGメディアトランスポート(MMT)一般ファイル配信(GFD)、またはROUTEを介して生成されたDASHオブジェクト(MPD、セグメント、または他のデータオブジェクト)を配信し得る。ライブストリーミングの場合、ROUTEの使用が好ましいことがある。なぜならば、ROUTEはリアルタイム機能をサポートし、IPマルチキャストを介して、および潜在的に次いで汎用カプセル化ストリーム(GSE:Generic Stream Encapsulation)またはATSC3.0で規定される技術を用いるDVB-T2などのブロードキャスト物理レイヤを介して配信されたパケットに適切にオブジェクトをマッピングするからである。
一般的に、マルチメディアブロードキャストマルチキャストサービス(MBMS)、拡張MBMS(eMBMS)、およびATSC3.0に対して、サービスエントリに対するトップダウン手法が考慮される。
・サービスエントリポイント、たとえば、MPDを含有するHTML-5ページまたはMPD自体が存在し得る。
・ストリーミングサービスは、複数のメディア構成要素を含有するMPDによって記述されてよく、メディア構成要素の各々は、メタデータ、レーティング、アクセシビリティなどを含む、適切な選択のための1つまたは複数の適応セットの中に記述される。
・各適応セットは、1つまたは複数の表現を含有し得る。
・いくつかの表現はブロードキャスト上で利用可能であり、基本サービスを構築する。
・その他は、表現を豊富にし、強化するためにユニキャスト上で利用可能である。
・サービスをブートストラップするために、MPDが必要であり、MPDはタイミングおよびプレイアウトを制御する。
以下は、ランダムアクセスのためのデータとして考慮されてきた。
・MBMSにおいて規定されたFLUTEを介するDASHに対して、
○いくつかのメタデータフラグメント、すなわちユーザサービス記述バンドル(USDB)およびセッション記述プロトコル(SDP)は静的であり、キャッシュ内にあることが、仮定される。
○リアルタイムで収集される必要のあるデータは以下の、FDTインスタンス、MPD、IS、および閉じた画像グループ(GOP)のランダムアクセスポイント(RAP)で開始するメディアセグメントである。閉じたGOP RAP要件は、今日の配備の制約である。必要なデータの集合はグループと呼ばれる。
○FDTの第1のパケットは、グループの第1のパケットであり、すなわち、このパケットが受信される必要があり、次いでこのグループに関連する後続の残りのパケットが受信される。
○潜在的にデータをプレイアウトのためにDASHクライアントに渡すために、少なくとも1つの完全なセグメントが受信される必要があり、すなわち、完全な受信の後でのみセグメントは「利用可能」であり、DASHクライアントによって要求されていることに対してスケジュールされ得る。次いで、DASHクライアントは、適切なバッファを生成することによって、またはMPD内で示唆されたプレゼンテーション遅延からの命令に固執することによって、セグメントのプレイアウトを進捗させ、スケジュールすることになる。
○この手順は、ROUTEを介するセグメントベースのDASHと等価であることに留意されたい。
図7は、FLUTEを介するDASHの例におけるサービスエントリの異なる態様の例を示す概念図である。具体的には、図7は、例示的なサービスエントリ280を示しており、MPD URL照合とともにインターネットプロトコル(IP)アドレスおよびポートがデータを取り出すために使用され得る。具体的には、サービスエントリ280は、クライアントデバイス40などのクライアントデバイスが、ファイル配信テーブル(FDT)288を使用してMPD284を取り出し、次いでFDT288およびMPD284を使用して初期化セグメント282およびメディアセグメント286を取り出し得ることを示す。
また、図7は、これらの様々な要素間の処理依存性290を示す。具体的には、FDT288は独立しており、MPD284はFDT288に依存し、初期化セグメント282はFDT288およびMPD284に依存し、メディアセグメント286はFDT288、MPD284および初期化セグメント282の各々に依存する。
図7は、さらに、典型的な送信順序292を左から右に示す。処理依存性290により、典型的な送信順序292に従って、FDT288はMPD284の前に送られ、MPD284は初期化セグメント282の前に送られ、初期化セグメント282は1つまたは複数のメディアセグメントパケット286A、286B(それらはメディアセグメント286の全部または一部を形成する)の前に送られる。
・ROUTEを介するDASHに対して、
○この場合、仮定は、LCTセッションインスタンス記述(LSID)は受信側デバイスのキャッシュ内で利用可能であること、すなわち受信側はスケジュールされたセッションについて、およびLCTトランスポートセッションの各々に割り当てられるものについての情報を有することである。
○リアルタイムで収集されるべきデータは以下の、EFDTインスタンス、MPD、IS、および閉じたGOP RAPで開始するメディアセグメントを含み得る。閉じたGOP RAP要件は、今日の配備の制約である。必要なデータの集合はグループと呼ばれる。本開示の説明では、EFDTおよびMPDの除去が提案される。
○EFDTは、グループの第1のパケットであり、すなわち、このパケットが受信され、次いでこのグループに関連する後続の残りのパケットが受信される必要がある。
○一動作モードでは、上記で説明したセグメントベースの受信モードは実現可能である。しかしながら、ROUTEはメディア配信イベント(MDE:Media Delivery Event)ベースの配信をサポートするので、DASHクライアントおよび/またはISO BMFF処理エンジンは、メディアセグメントの十分に大きいプレフィックスが受信される時点より早くプレイアウトを開始してもよい。この場合、潜在的にデータをプレイアウトのためにDASHクライアントに渡すために、MDEは利用可能である必要があり、DASHクライアントによって要求されていることに対してスケジュールされ得る。次いで、DASHクライアントは、初期の遅延を加速するためにメディアセグメントのプレフィックスのプレイアウトを進捗し、スケジュールすることになる。重要であり、考慮される必要があるものは、利用可能性および復号時間(一般的に同等である)が適切に導出される方法である。
図8は、ROUTEを介するDASHデータの配信の一例におけるサービスエントリ300の例示的な態様の別のセットを示す概念図である。この例では、拡張FDT(EFDT)302は、MPD306に対するURLおよびコンテンツタイプ、初期化セグメント304、ならびにメディアセグメント310(メディアセグメントメディア配信イベント(MDE)308Aおよびメディアセグメント残余308Bによって形成される)に対するTOIのマッピングを含有する。処理の観点から(すなわち、処理依存性312に示すように)メディアデータを有するメディアセグメント310へのアクセスは、初期化セグメント304、MPD306、およびEFDT302に依存する。初期化セグメント304は、MPD306およびEFDT302を処理することに依存する。そして、MPD306の処理は、EFDT302の処理に依存する。そのような処理を可能にするために、パケットの送信順序314は、図7に示すとおりであり、すなわち、EFDT302、次いでMPD306、次いで初期化セグメント304、および次いでメディアセグメントパケットである(たとえば、メディアセグメントMDE308Aの後ろにメディアセグメント残余308Bが続く)。
ROUTEに対する特定の受信が次のように記述されている。
・LSIDは、IP/ポート組合せと、異なるLCTセッションとを記述する。
・セグメント化されたISO BMFFファイル内で表される異なるメディア構成要素は、IP/ポート/TSIの組合せに関連し、その組合せに一意に割り当てられる。
・サービスはMPD URLによって記述される。
・ROUTE受信機は、チャネルから構成要素/サービスに対するオブジェクトを取り出す。
・オブジェクトの受信では、ROUTE受信機は、FDT/EFDT(または可能であればエントリモード)を使用してURLを各オブジェクトに割り当てる。
・DASHクライアントは、MPD URLを得て、それをローカルキャッシュからフェッチし、MPD内のURLに基づいてセグメントの消費を開始する。
・タイミングは、MPDおよびDASHクライアントによって制御され、すなわちセグメントはタイミングを割り当てられない。
代替手法では、以下が適用され得る。
・下位レイヤシグナリングが、MPDなしにサービスを開始するために十分な情報を提供する。
・ユニキャストが追加される場合、またはより豊富な選択が必要である場合、MPDが顧慮され、MPDは依然として統合されたMPDであり得るが、起動に必要ではないとして取り扱われる。MPDは、さらに、ブロードキャストのみに対して、MPDは使用されず、またURLバインディングの必要性は不要であるように構成されてもよい。このようにして、これらの技法は、FDT、EFDT、またはURLをオブジェクトにバインドするための他の手段の必要性を回避し得る。
本開示は、この手法と同様の例示的な設計について説明しており、この手法は、顕著な不都合なしに、帯域幅効率、初期起動、簡潔さ、頑強さ、拡張性、および複雑さの理由に対する利点を提供し得る。既存のサービスとの互換性を維持し、異なる使用事例に対処するために、以下の手法が考慮され得る。
・サービスシグナリングは、以下の手法のうちのどれが採用され得るかについての表示を提供する。
1. 受信側は、起動に対してもMPDを必要とする、すなわちDASHクライアントは開始されてはならず、サービス起動はMPDなしになされてはならない。これは、基本的に現在の手法を模写する。
2. サービスプロバイダは、MPDなしの起動が可能であり、許容されるように十分なシグナリングを提供するが、MPDは同様に提供され、より豊富なコンテンツ提示および代替物を記述する。
3. サービスプロバイダは、MPDをまったく提供せず、サービスは、下位レイヤシグナリングによって完全に記述され、より豊富な情報は有効にされない。これは、ハイブリッドブロードキャスト/ブロードバンドサービスを妨げることになる。
・異なる事例に対する例示的なサービス
1. 第1の手法を使用する、MPD内に詳細な情報を有する暗号化されたサービス。
2. 第2の手法を使用する、サービスを豊富にすることができるユニキャスト構成要素を有する無料のA/Vサービス。
3. 第3の手法を使用する、MPDを必要としない単純な無料のA/Vサービス。
以下の問題は、MPDをエントリポイントとして配信するトップダウン手法によって生じる場合がある。
・DASHメディアフォーマットは、ブロードキャスト配信を介して配信される。
・セッションを起動するために、いくつかのデータオブジェクト(下位レイヤシグナリング、セッション記述、FDT/EFDT/等価方法、MPD、IS、および少なくとも一部のメディアセグメント)は、データにランダムにアクセスし、プレイアウトをスケジュールするために受信される必要がある。
・メディアおよび時間制御の選択はMPD内にあるので、起動前にMPDを受信すること、およびメタデータを受信してMPDを識別することが必要である。
・別の課題は、MPDは、修正されない場合、受信側におけるタイミングが予測され得るように、送信側において生成される必要があることである。
・別の課題は、MPDは、ビデオまたはオーディオに速やかにアクセスするために、あらゆる構成要素内のあらゆるランダムアクセスポイントとともに送られる必要があることである。
・さらに別の課題は、FDTまたはEFDTが、URLをマッピングすることが可能であるために必要とされることである。
・最後に、MPDおよびメタデータは一般的にXMLに従ってフォーマットされ、統合されたMPDは、すべての構成要素ならびにすべてのユニキャスト/ブロードバンドで配信されたデータを含む全サービスを記述する。これは、MPDを不必要に大きくする一方で、ブロードキャスト情報は、開始においてのみ必要である場合がある。
本開示の技法は、上述の問題のいずれかまたはすべてを克服し得る。
たとえば、受信デバイス(たとえば、クライアントデバイス40)は、単方向/ブロードキャストモードにおいてEFDT、FDTおよび/またはMPDなしに動作(すなわち、メディアデータを受信、処理、および復号)するように構成され得る。具体的には、クライアントデバイス40は、場合によっては起動のためおよび/または他の手段による永久的動作のために必要となるこれらのデータ構造からの情報の代替バージョンを受信し得る。
図9は、本開示の技法によるデータを搬送するために使用され得るRFC5651に従うLCTヘッダ320のフィールドを示す概念図である。具体的には、LCTヘッダ320は、バージョンフィールド322と、輻輳制御フラグ324と、プロトコル固有の表示(PSI)フィールド326と、トランスポートセッション識別子フラグ(S)328と、トランスポートオブジェクト識別子(O)フラグ330と、ハーフワード(H)フラグ332と、確保された(RES)フィールド334と、クローズセッション(A)フラグ336と、クローズオブジェクト(B)フラグ338と、LCTヘッダ長(HDR_LEN)フィールド340と、コードポイントフィールド342と、輻輳制御情報344と、トランスポートセッション識別子346と、トランスポートオブジェクト識別子348と、ヘッダ拡張フィールド350とを含む。
バージョンフィールド322、輻輳制御フラグ324、プロトコル固有の表示(PSI)フィールド326、トランスポートセッション識別子フラグ(S)328、トランスポートオブジェクト識別子(O)フラグ330、ハーフワード(H)フラグ332、確保された(RES)フィールド334、クローズセッション(A)フラグ336、クローズオブジェクト(B)フラグ338、LCTヘッダ長(HDR_LEN)フィールド340、コードポイントフィールド342、輻輳制御情報344、トランスポートセッション識別子346、およびトランスポートオブジェクト識別子348の値は、以下で説明するように、RFC5651に従って、および本開示の技法に従って設定され得る。ヘッダ拡張フィールド350は、本開示の技法に従って設定され得る。
以下の機能は、場合によってはMPDおよび/またはEFDT内で与えられる情報の配信をサポートするために、利用可能であり、かつ使用される可能性がある。本開示の技法に従ってデータを搬送するために使用され得るフィールドは、以下にイタリック体で記される。
・LSID(ATSC3.0のROUTE仕様の草案の中で定義される)
○メディアレイヤに渡されるためのトランスポートセッションを選択するために構成要素特性のトランスポートセッションへの割当てをシグナリングするためのLSIDにおけるコンテンツ記述子の使用。
○コードポイント割当ての使用。
・ROUTE/LCTヘッダフィールド(RFC5651および図9参照)
○輻輳制御情報(CCI)344:32、64、96または128ビット。輻輳制御情報を搬送するために使用される。たとえば、輻輳制御情報は、レイヤ番号、論理チャネル番号、およびシーケンス番号を含み得る。このフィールドは、この仕様の目的に対して不明瞭であり、したがって恣意的に使用されてよい。
○TSI:トランスポートセッション識別子(TSI)346:0、16、32または48ビット。TSIは、特定の送信側からのすべてのセッションの間で1つのセッションを一意に識別する。TSIは送信側のIPアドレスによってスコープされ、したがって送信側のIPアドレスおよびTSIはともに、セッションを一意に識別する。TSIは、送信側のIPアドレスとともに、セッションを常に一意に識別するが、TSIがLCTヘッダ内に含まれるか否かは、TSI値として何が使用されるかに依存する。基礎をなすトランスポートがUDPである場合、16ビットUDPソースポート番号MAYは、セッションに対するTSIとして働く。
○トランスポートオブジェクト識別子(TOI)348:0、16、32、48、64、80、96または112ビット。このフィールドは、セッション内のどのオブジェクトにこのパケットが関連するかを示す。たとえば、送信側は、第1のファイルに対してTOI=0、第2のファイルに対してTOI=1、などを使用して、同じセッション内のいくつかのファイルを送る場合がある。別の例として、TOIは、いくつかの送信側から同時に送信されているオブジェクトの一意のグローバル識別子であり、TOI値は、オブジェクトに適用されるハッシュ関数の出力であり得る。
○コードポイント342:8ビットが、含有されるオブジェクトならびに現在パケットに対する関係の異なる特性をシグナリングするために利用可能である。コーデック上の情報を伝達するためにパケットペイロード復号に渡された不明瞭な識別子が、パケットペイロードに対して使用される。コードポイントと実際のコーデックとの間のマッピングは、セッションごとに規定され、セッション記述情報の一部として帯域外で通信される。CPフィールドの使用は、[RFC3550]に記載されるRTPヘッダ内のペイロードタイプ(PT)フィールドと同様である。
○LCTヘッダ内の特定のヘッダフラグ
・PSI326:これらのビットが存在する場合、これらのビットの使用は、LCTビルディングブロックを使用する各プロトコルインスタンシエーションに固有である。これらのビットのプロトコルインスタンシエーション固有の使用が規定されない場合、送信側はこれらのビットをゼロに設定しなければならず、受信側はこれらのビットを無視しなければならない。
・RES334:LCTによって所有され、したがって現在使用されない
・ROUTE/LCT拡張ヘッダ(RFC5651および図9参照)。
○ヘッダ拡張350は、必ずしも常に使用されないかまたは可変サイズを有するとは限らないオプションのヘッダフィールドを受け入れるために、LCT内で使用され得る。ヘッダ拡張の使用の例は、以下を含む。
・既存のヘッダフィールドの拡張サイズバージョン。
・送信側および受信側の認証情報。
・タイミング情報の送信。
・ISO BMFFの初期化セグメント(ムービーヘッダ)(ISO/IEC 14496-12参照)
○プレゼンテーションに対するメタデータは、ファイルのトップレベルにおいて発生する単一のムービーボックス内に記憶される。ムービーヘッダは、構成要素、たとえば、
・メディアヘッダ、メディアについての全情報
・ハンドラ、メディア(ハンドラ)タイプを宣言する
・メディア情報コンテナ
のメディア固有の態様に関連する追加情報を加えることを可能にする。
・ROUTE、LCTおよびISO BMFFの外部
○物理レイヤ(FIT)上の情報
○サービスを実行するプレゼンテーションレイヤ/アプリケーション内の情報。
MPDの関連機能が以下に要約されており、本開示の技法に従ってそれらにいかに対処するかについて、以下でさらに詳細に説明する。
利用可能時間およびプレゼンテーション時間アンカリング:利用可能時間は、オブジェクトの利用可能時間またはオブジェクトのMDE部分がヘッダ内でシグナリングされるようにシグナリングされる。プレゼンテーション時間アンカリングは、データがISO BMFFクライアントに対して利用可能にされると直ちに、クライアントがプレイアウトの復号および実行を開始するというものである。タイミングの詳細について、以下で説明する。
プレゼンテーションのタイプ--プロファイル、静的、動的、など:これらのパラメータはブロードキャストのために設定される必要はないが、データはいくつかの規則に従う場合がある。プロファイルが定義され得る。タイプは静的と見なされる。詳細なプロファイルおよびメディアフォーマット定義は、以下で与えられる。
帯域幅およびバッファ記述:タイミングはデータの到来によって決定されるので、これらのパラメータはブロードキャスト配信と無関係である。しかしながら、短い最小のバッファ時間を開始するために、この態様は考慮されるべきである。この問題について、以下で説明する。
時間シフトバッファ深度:時間シフトバッファは受信情報によって決定されるので、このパラメータはブロードキャストと無関係である。しかしながら、データがどれほど長くクライアントデバイス(すなわち、受信側デバイス)内に記憶されるべきかについて、送信側から何らかの命令があることが考慮されてもよい。
期間を使用する情報の接合およびリセット:このために、シグナリングが必要である。期間は初期化セグメントを変更し、タイムラインをリセットする。この情報が伝達され、前のデータに対する期間開始のプレイアウトが適切にスケジュールされることが必要である。これがいかにして達成され得るかについての詳細は、以下で与えられる。
選択/拒絶に対する適応セットおよび表現メタデータ:ROUTEベースの配信に対して、適応セットおよび表現の選択は、LCTトランスポートセッションレベルで発生する必要がある。トランスポートセッションが選択されると、このデータは、復号および処理のためにISO BMFFレイヤに転送される。初期化セグメント内の情報に基づいて、ISO BMFFレイヤは、依然としていくつかのデータを選択もしくは拒絶またはフィルタリングしてよいが、これは、本明細書の議論とは無関係である。適切なセッションを選択するために、LSID内の情報が使用される。この問題について、以下でより詳細に説明する。
表現(切替え可能、依存性、など)とシームレスな切替え情報との関係:大部分のアプリケーションでは、適応セット当たり1つの表現だけが、ブロードキャストにおいて配信される。しかしながら、複数の表現がブロードキャストされる事例が存在する場合、以下で説明するように、各表現の個別の態様がLSID内に与えられ得る。異なる表現にわたるシームレスな切替えが要求される場合、これは、表現の切替えを実行するときだけMPDを必要とし、異なる表現にわたるシームレスな切替えに必要な情報は、同じく、初期化セグメント内でシグナリングされ得る。いくつかの場合、たとえばレイヤードコーディングを使用するとき、この情報は、同じく、初期化セグメント内に与えられる。LSIDセッションの依存性はLSID内でシグナリングされ、追加の詳細が以下で説明される。
プレゼンテーション時間オフセット:プレゼンテーション時間オフセットは、期間内の表現の第1のプレゼンテーション時間をシグナリングする、すなわち、プレゼンテーション時間オフセットはアンカーを提供する。この情報は、ROUTEヘッダ内の情報を使用することによって複製されなければならない。この問題について、以下でより詳細に述べる。
初期化セグメントおよびメディアセグメントのロケーションおよびURL:MPDは、以下の問題に対処することによってMPD構造に対するオブジェクトのロケーションおよびバインディングを記述する。MPDは、それがどのオブジェクト(初期化セグメント、メディアセグメント、他のタイプ)であるかを知って、それをコンテキスト内に位置付ける、たとえば、メディアセグメントのシーケンスが記述されて、データオブジェクトの使用の仕方についての情報をDASHクライアントに提供する。MPDはURLを指し、およびこれによってMPD情報とそのファイルとの間のバインディングを指し、メディアストリーミングが確立される。さらに、(E)FDTは、TOIからURLへのマッピングを提供する。この関係およびタイプの表示は、ROUTE配信によって複製されなければならず、このために、ROUTEヘッダが使用され、TSI、TOIおよびROUTEヘッダの厳密な使用が、この目的を実現するために必要である。また、特定の送信順序が考慮されてよい。考慮されてよい別の態様は、ISがメディアセグメントにどのように関連するかである。その制約および詳細について、以下で説明する。
メディアセグメントの持続時間:一般に、メディアセグメントの持続時間は、セグメント利用可能時間を計算するため、および探索の目的のために使用される。持続時間は、それ以外は重要でない。したがって、一般に、情報はブロードキャストに対して不要である。
コンテンツ保護についての詳細情報:コンテンツ保護は、初期化セグメント内でシグナリングされ得る。複雑な問題がシグナリングされるべきである場合は、MPDが必要であると見なされてよい。しかし、一般に、初期化セグメント内の情報で十分であると見なされる。
イベントストリームシグナリング:表現は、DASHクライアントによってパースされなければならないイベントストリームを搬送し得る。イベントストリームが重要であると見なされる場合、イベントストリームは、LSIDコンテンツ記述子内でシグナリングされ得る。代替として、MPDは、イベントストリームを通信するために使用され得るが、そのようなイベントストリームは起動に対して無関係である。LSID内の帯域内イベントストリームのシグナリングについての付加的詳細について、以下で説明する。
補助データ--プログラム情報、メトリック:MPDは、プログラム情報、メトリック収集開始、または他の手段など、いくつかの動作に対して関連がある情報を搬送し得る。この情報は、リアルタイムクリティカルではなく、仮に必要ならば、より遅い周波数で配信されるかまたはユニキャストを介して供給されるMPD内で供給され得る。
以下の態様は、タイミングおよびバッファモデルを確立するために考慮される:
・あらゆるパケットは、MPEG-2 TSのRTPベースの配信に対するRFC2250内で定義されるものと同様のターゲット送信時間(TTT)を有する。ターゲット送信時間は、
○送信側のヒント情報のみであるか、または
○NTPタイムスタンプ(中間の32ビット)として、またはMPEG-2 TSと同様の90kHzクロックとして、またはLSID内で定義されるタイムスケールを有する任意の他のクロック、たとえば含有されるメディアのクロックとして、LCTパケットの輻輳制御ヘッダ内でシグナリングされるかのいずれかであり得る。
・TTTは、存在して受信側に知られている場合、データを次のレイヤに、すなわちISO BMFFレイヤにリリースする正確な時点についての情報を提供する。
・ISO BMFFハンドラは、データがROUTEレベルからリリースされるとすぐに復号を開始し、そのデータを直ちにレンダリングすることが仮定される。
・それがデータを配信し得る時間を受信側にいかにしてシグナリングするかについて、異なる方法が考慮される。
○RAPグループ(一般的にIS)の第1のパケットおよびメディアセグメントの第1のパケットの中の拡張ヘッダは、データが次のレベルにリリースされるまで、データがROUTE受信機内でどれほど長く保持される必要があるかをシグナリングする。この時間は、リリース時間(RT)と呼ばれる。RTはTTTと同じ時間スケール内にあり、TTTタイムスタンプ(実際の時間ではない)と比較され得る。増加するTTTとともに、RTが減少してはならない。拡張ヘッダ内のRT時間が現在のオブジェクト/セグメントの最大TTT時間を超える場合、このパケット内に含有されるデータは、TTT時間が次のセグメントまたは任意の今後のセグメントに到達するまで保持されるべきである。具体的には、受信側は以下のように働き得る。
・パケットがRT時間とともに受信された場合、このデータは、パケットがRTを超えるTTTとともに受信されるまで保持され得る。
・パケットがRT時間を伴わずに受信された場合、含有されるオブジェクトデータは、先行データとともにリリースされてよく、ここで「先行する」は、増加するstart_offsetおよび増加するTOI番号におけるオブジェクトの順序である。
TTTが使用中であり、受信側がTTTと実際の受信時間との間に顕著なジッタを観測する場合、このジッタは、バッファアンダーフローを回避するために補償されるべきである。
・たとえば、デバイスは何らかの追加の遅延を加えてよく、または送信インフラストラクチャは何らかの追加の起動遅延を加える。
○オプション2:この場合、絶対的壁時計時間が、復号をスケジュールするために使用される。オブジェクトは、オブジェクトがISO BMFFエンジンに転出されるべき壁時計時間を割り当てられる。この事例は、大部分、異なるユーザの間の同期されたプレイアウトが重要であるときに重要である。増加する壁時計時間とともに、RTは増加しなければならない。具体的には、受信側は以下のように働くことを予想される。
・パケットがRT時間とともに受信された場合、このデータは、RT内に記述された壁時計時間が到来するまで保持され得る。
・パケットがRT時間を伴わずに受信された場合、含有されるオブジェクトデータは、先行データとともにリリースされてよく、ここで先行することは、増加するstart_offsetおよび増加するTOI番号におけるオブジェクトの順序である。
○オプション3:ROUTEヘッダ内のヘッダビットは、含有されるデータがまだ次のレベルにリリースされ得ないことをシグナリングするために、10に設定される。ビットが設定されていない場合のみ、設定する(すなわち、1に等しい)、データは配信され、前方に送られ得る。オブジェクトの最後のパケット(BフラグがLCTヘッダ内で設定されていることによって示される)が依然として10に設定されたビットを有する場合、このパケットはオブジェクトが完了したときだけリリースされ得る。しかしながら、完了したオブジェクトは、常に配信され得ることに留意されたい。代替として、このヘッダビットは、各オブジェクトの最後のパケットに対して1に等しくあるべきことを命じられている。
・TTTが使用中であり、受信側がTTTと実際の受信時間との間に顕著なジッタを観測する場合、このジッタは、バッファアンダーフローを回避するために補償されるべきである。
○たとえば、デバイスは何らかの追加の遅延を加えてよく、または送信インフラストラクチャは何らかの追加の起動遅延を加える。
3つの異なるタイプの受信が考慮される:
1. MDEベースの受信:第1の事例では、受信側におけるプレイアウトは、ISO BMFFファイルのプレフィックスに基づいて可能な限り速やかに発生している。
2. 第2の事例では、フルセグメントだけが、次のレベルにリリースされなければならない。フルセグメントは、DASHクライアントによって要求されるか、またはフルセグメントがRTと、TTTもしくは壁時計との比較に従ってリリースされるかのいずれかである。一般的に、ROUTE受信機は、RT情報に基づいてセグメントを利用可能にする。DASHクライアントは、MPD情報に基づいて要求を送る。コンテンツは、セグメント利用可能性開始時間がリリース時間より早くならないように記載され、配信されるべきである。
3. 壁時計アンカリング:第3の事例では、データのプレゼンテーションが、たとえばDASHシステムの外部に配信された他のメディアとの同期を可能にするために、しばらくの間保持される。RAPは、このデータに従ってリリースされなければならない。
それにもかかわらず、3つすべての事例における原理は同じままであり、リリースされるデータユニットがMDEまたはフルセグメントのいずれかであることだけが異なる。
図10は、オブジェクトのプレフィックスが復号のために次のレイヤにリリースされ得るときをシグナリングするための様々なオプションを示す概念図である。以下でさらに詳細に説明する様々なオプションのうちのいくつかに対応する以下の例示的なオプションが、以下で簡単に説明され、図10に示される。
1. 第1の例示的なオプション360:この例では、図10は、RAPパケット366ならびにパケット368A、368Bおよび374を含む一連のパケットを示す。これらのパケットの各々は、基本的にシステムレベルの復号時間に一致するそれぞれのターゲット送信時間(TTT)を含有する。この例では、RAPパケット366およびパケット368A、368Bの各々はTTT1 362を含有する一方で、パケット374はTTT2 370を含む。TTT情報は、配信をスケジュールするためにスケジューラによって使用される。加えて、RAPパケット366は、TTT情報と同じドメインの中にリリース時間(RT)364を含み、RT364は、グループ(一般的に、初期化セグメント(IS))の第1のパケット、または任意の他のパケットが即時処理のために次のレイヤにリリースされ得るときを決定する。RTは、1つのオブジェクトに対して一度加えられてよく、またはRTは、1つのオブジェクトに対して複数回加えられてもよい。RTは、よりストリーミングに似た方法でオブジェクトをリリースするために、1つのオブジェクトの中で送信時間が増加するとともに増加してよい。この例では、RAPパケット366、パケット368Aおよびパケット368Bは、TTT1<RT364<TTT2のときにリリースされる。
2. 第2の例示的なオプション380:この例では、図10は、RAPパケット384およびパケット386、388、392を含む一連のパケットを示す。RAPパケット384は、RT382と関連付けられる。RAPパケット384は時間NTP1において受信され、パケット386はNTP2において受信され、パケット388はNTP3において受信され、パケット392はNTPXにおいて受信されることが仮定される。この場合、NTPにおけるリリース時間だけがオブジェクトに対して加えられる。これは、MPDにおけるセグメント利用可能時間と同様であり、この時間の後でオブジェクトを転送することが許可される。したがって、RAPパケット384は、NTP>=RT382のときに時間390においてリリースされ得る。有利な態様として、これは、追加のタイミングシグナリングを必要としないことが挙げられるが、送信側はNTP内のこのリリース時間の設定において配信遅延およびジッタを考慮に入れる必要があるか、あるいは、配信における任意の予期しない遅延によって、オブジェクトが適時に提示され得ない(起動遅延をもたらす)ことか、またはオブジェクトが遅れて受信されてタイムラインが失われることのいずれかの課題が引き起こされるという問題が存在する。このオプションは、壁時計同期を使用するときの目的に対して有利である。
3. 第3の例示的なオプション400:この例では、図10は、RAPパケット404およびパケット406A、406B、412を含む一連のパケットを示す。この場合、RAPパケット404は、どの時間の後にデータが次のレイヤにリリースされ得るかを示す情報を含むリリースフラグ(RF)402(または「保持フラグ」)を含有する。この例では、RAPパケット404およびパケット406A、406Bに対してRF=0である。したがって、NTP時間410の後、RAPパケット404およびパケット406A、406Bはリリースされてよい。なぜならば、NTP時間410における時間は、RF=1 408(パケット412と関連付けられる)であるからである。この手法は極めて単純であるが、セグメント境界を超えてシグナリングすることができないという問題に遭遇する場合がある。それにもかかわらず、オプション400は、ROUTE受信機の動作を単純にするので、依然として考慮に入れるべきである。
図11は、データを受信するため、および受信されたデータをバッファリングするための2つの例示的なモデルを示す概念図である。クライアントデバイス40の取出しユニット52は、これらの例のいずれかに従って構成された1つまたは複数の構成要素を含み得る。第1の例示的なモデル432では、ROUTE受信機および出力バッファ426は、RAPパケット420およびパケット422、424などのパケットを受信する。ROUTE受信機および出力バッファは、ISO BMFFデコーダ430を用いて復号およびプレゼンテーションを開始し、スケジュールする。ROUTE受信機および出力バッファは、受信されたデータをISO BMFFストリームの形態でISO BMFFバッファ428に送る。ROUTE受信機および出力バッファ426によって確立されたスケジュールに基づいて、ISO BMFFデコーダ430はISO BMFFバッファ428からデータをフェッチし、次いでフェッチされたデータを復号して提示する。
第2の例示的なモデル452では、ROUTE受信機446は、RAPパケット440およびパケット442、444などのパケットを受信する。ROUTE受信機は、受信されたパケットをROUTE出力およびISO BMFFバッファ448内でバッファリングし、ISO BMFFデコーダ450を用いて復号およびプレゼンテーションを開始してスケジュールする。ISO BMFFデコーダ450は、ROUTE出力およびISO BMFFバッファ448からデータをフェッチし、フェッチされたデータを復号して提示する。
上記に基づいて、以下の態様が重要であり得る:
・利用可能時間が、たとえば、上記の図10の3つのオプションのうちの1つ、たとえばオプション360、380または400のうちの1つに従って与えられる。これは、セグメントの第1の部分がISO BMFFクライアントにリリースされる時間である。
・プレゼンテーション時間は、復号およびレンダリングが与えられた情報に基づいて受信側において瞬時に開始されるというものである。これは、データモデルのみであり、ROUTE受信機とISO BMFF受信機との間のバッファは共有され得ることに留意されたい。2つの例示的なモデル(432、452)を、図11に示す。RAPパケット(たとえば、RAPパケット420またはRAPパケット440)は、期間開始およびプレゼンテーション時間オフセットを補償するMDE内の情報を含有してよく、すなわち、メディアセグメント内の最早プレゼンテーションの開始は即時であってよい。
・バッファ検証および初期プレイアウト遅延が、上記の3つの例示的なオプション(360、380、400)のうちの1つによってシグナリングされ得る。
・動作モードにおいて以下で考慮され得る異なる事例が存在する(異なるタイプの例示的なシグナリングが以下で提供される)。考慮されるべき異なる事例は以下を含む。
○通常のメディアセグメントのパケットが、ROUTE受信機においてスケジューリングなしに単にISO BMFFバッファに渡される。送信側は、初期プレイアウト遅延がバッファアンダーランなしにシームレスなプレイアウトを与えることを保証する。これらのパケットは、リリースをスケジューリングするためにRTをも含有してもよいが、一般的に、これは不要である。なぜならば、RTは、プレイアウトがISO BMFFレイヤによってスケジュールされると、直ちにリリースされ得るからである。
○冗長な初期化セグメントは受信側によって無視されてドロップされ、ISO BMFFデコーダに渡されないことになる。
○増大する初期化セグメントが、ISO BMFFデコーダに与えられる。しかしながら、デコーダは、メディアが時間的に連続しており、何らかの本質的でない情報だけが変化したことを通知されるべきである。しかしながら、そのようなAPIが存在しない場合、リセットが行われ、プレイアウトが再スケジュールされ得る。
○コンテンツ期間境界:この場合、ISが転送されなければならず、完全な新しいスケジューリングが実行される。これは、少数のサンプルを有するISO BMFFバッファがフラッシュされる事例、またはデコーダによって取り扱われる必要のある短い時間の間にデータが利用可能でない事例を生じる場合があることに留意されたい。これは、通常のDASH動作と同等である。
・送信側が、以下でより詳細に説明する送信要件に準拠しなければならないので、上記の動作は可能であることに留意されたい。
送信側および受信側がセグメントベースの配信/受信を使用するように構成される場合、情報は、以下で説明するように、タイミングシグナリングに加えられ得る。しかしながら、セグメントベースの受信がMDEベースの配信に基づいて実行される場合、受信側はタイミング情報をいかに利用するかを理解する必要があるので、課題はより扱いにくくなる。以下のオプションが考慮されるべきである:
・セグメント利用可能時間をスケジュールしてシグナリングするために、MPDが利用可能にされる。
・セグメントベースの受信をサポートするために、メディア時間(およびTTT)の時間における追加の遅延を示す属性が、各構成要素に対するLSIDに加えられる。一般的には、そのような時間は最大セグメント持続時間である。時間は壁時計時間におけるものではなく、送信時間におけるものであり、したがって、バーストベースの配信が行われる場合、セグメント配信の追加の遅延は、MDEベースの受信の遅延よりわずかに大きくなることがあることに留意されたい。
送信側および受信側が壁時計アンカリング、すなわち壁時計ベースの復号を利用するように構成される場合、情報が、以下で説明するタイミングシグナリング情報に加えられ得る。しかしながら、MDEベースの配信がシグナリングされるが、受信側は復号およびプレイアウトを壁時計時間に同期させる必要がある場合があり得る。以下のオプションが考慮され得る:
・セグメント利用可能時間、ならびに示唆されたプレゼンテーション遅延をスケジュールしてシグナリングするために、MPDが利用可能にされる。
・TTTまたは復号時間の壁時計時間へのマッピングを示す属性が、各構成要素に対するLSIDに加えられる。
・この情報、すなわち壁時計プレイアウトスケジューリングへのマッピングを与える、LCTに対する拡張ヘッダが、生成される。
LSID内の情報に基づいてLCTトランスポートセッション内に配信されたメディアの選択を可能にするために、表現を除いて、適応セットに割り当てられた多くの要素および属性が、LSIDに加えられ得る。具体的には、これは、以下の情報のいずれかまたは全部を含み得る(詳細について、ISO/IEC 23009-1、第5.3.4節(適応セット)および第5.3.7節(共通属性)参照):
・@id要素を使用する識別子。
・@group属性を使用するグループ関連付け。
・@lang属性によって記述される言語。
・@contentType属性によって記述されるメディア構成要素タイプ。
・@par属性によって記述されるピクチャアスペクト比。
・ロール要素によって記述されるロール特性。
・アクセシビリティ要素によって記述されるアクセシビリティ特性。
・視点要素によって記述される視点特性。
・レーティング要素によって記述されるレーティング特性。
・セグメント特性(ランダムアクセス、など)についての情報:SISSIコア実験参照。
・適応セットに対する@profiles属性。
・@widthおよび@heightの提供は、@sar属性によって決定されるグリッド上のビデオメディアタイプの水平および垂直視覚的表現サイズを指定する。
・@sarは、ビデオメディア構成要素タイプのサンプルアスペクト比を指定する。
・@framerate:ビデオメディアタイプの出力フレームレート(またはインターレースの場合、出力フィールドレートの半分)を指定する。
・@audiosamplingRate:オーディオメディア構成要素タイプの最大サンプリングレート。
・@mimeType:初期化セグメント、存在する場合、と表現内のすべての連続するメディアセグメントとの、MIMEタイプの連結を指定する。
・@codecs:表現内に存在するコーデックを指定する。コーデックパラメータはまた、適用可能な場合にプロファイルおよびレベル情報を含み得る。
・@scanType:ビデオメディア構成要素タイプの原材料の走査タイプを指定する。
・FramePacking:ビデオメディア構成要素タイプのフレームパッキング配置情報を指定する。
・AudioChannelConfiguration:オーディオメディア構成要素タイプのオーディオチャネル構成を指定する。
・ContentProtection:関連する表現に使用されるコンテンツ保護方式についての情報を指定する。
・EssentialProperty:この構成要素を選択するメディアプレゼンテーションオーサーによって本質的であると見なされる含有要素についての情報を指定する。
・SupplementalProperty:構成要素を処理するために使用され得る含有要素についての補足情報を指定する。
・InbandEventStream:関連する表現内の帯域内イベントストリームの存在を指定する。
この情報のすべては、LCTトランスポートセッションレベルにおける選択のために使用され得る。選択が与えられない場合、すべてのストリームが、処理のためにISO BMFFハンドラに転送され得る。この情報は、トランスポートセッションレベルで早期のフィルタリングおよび選択のために与えられ得る。
図12は、選択およびフィルタリングユニット462と、ROUTE受信機464と、他のオブジェクトプロセッサ466と、ISO BMFFメディアプロセッサ468と、ISO BMFFプリプロセッサ470とを含む、受信側デバイス460の構成要素の例示的なセットを示す概念図である。受信側デバイス460は、クライアントデバイス40に対応してよく、ここで取出しユニット52は、選択およびフィルタリングユニット462とROUTE受信機464とを含んでよく、一方でカプセル化解除ユニット54は、ISO BMFFプリプロセッサ470と、ISO BMFFメディアプロセッサ468と、他のオブジェクトプロセッサ466とに対応してよい。
この例では、ROUTE受信機464は、コンテンツ記述子を有するLSIDを選択およびフィルタリングユニット462に与える。この情報に基づいて、選択およびフィルタリングユニット462は、プロセッサ(たとえば、ISO BMFFプリプロセッサ470、ISO BMFFメディアプロセッサ468、および他のオブジェクトプロセッサ466)に転送されるべき適切な構成要素を選択し得る。
上記の原理を適用することによって、拡張性が、新しい方式および拡張によって確実にされ得る。このシステムは、DASHベースの配備との互換性を維持する。加えて、ISO BMFFメディアプロセッサ468はまた、そのレベルでのいくつかのメディアストリームを選択または拒絶し得る。
LCTヘッダは、いくつかの特性をシグナリングするために柔軟に使用され得る。しかしながら、ヘッダの使用は、ROUTEに対して命じられる必要がある。これについて、以下で説明する。
メディアフローを搬送するLSID(コンテンツタイプxxx/mp4によって示される)において、Table 1(表1)が、コードポイントフィールドの設定を与える。これは、送信側および受信側がFDTおよびMPDなしに動作することを可能にする。
以下のLCTヘッダは、MPDなしのROUTE内で使用され得る。
・TSIは、単一のISO BMFFベースの表現をシグナリングする。
・TOIは、オブジェクトをシグナリングするために使用される。1つのコンテンツ期間内のメディアセグメントは、増加するTOI番号とともに送られなければならない、すなわちオブジェクトは1だけ増加される。コンテンツ期間においてのみ、これは変化し得る。メディアセグメントTOIは、TOIの第1のビットが1に設定されるスペースだけを使用し得る。非メディアセグメントは、第1のビットが0に設定されるTOIスペースを使用し得る。
・コードポイントは、第3.6.2節において記述されているように使用される。
・PSIビットは、以下のように使用される:
○第1のビットが0に設定される場合、時間ベースのリリースシグナリングが適用される:
・第2のビットが0に設定される場合、輻輳制御フィールドは使用されない。
・第2のビットが1に設定される場合、輻輳制御フィールドは、90kHzクロック周波数におけるタイムスタンプを含有する。
○第1のビットが1に設定される場合、
・第2のビットは、オブジェクトに対するリリースフラグをシグナリングする。
・輻輳制御フィールドは、90kHzクロック周波数におけるタイムスタンプをシグナリングするために使用され得る。
以下の例示的なLCT拡張ヘッダが定義される:
・TTTにおける初期リリース時間:TTT時間内にこのパケットに含有されるデータの最早リリース時間を指定する。サイズ32ビットの拡張ヘッダが好適である。
・NTPにおける初期リリース時間:NTP時間内のオブジェクトの現在の初期バイトの正確なリリース時間を指定する。同じく、32ビットが好適であり、NTPタイムスタンプの中間の32ビットを与える。
オプション1からの送信手順が以下で選択されることを仮定する。オプション2およびオプション3の変形態は、さらなる研究のためにあり、以下で説明する技法かまたは他の技法とともに使用され得る。以下の送信挙動は、一定のメディアプレゼンテーションに対するMPDを使用せずに考慮される:
・LSIDフラグメントが、ブートストラッピングによって与えられ得る。
○LSIDフラグメントは、サービス提供における任意の変更をシグナリングするために更新され得る。
○LSIDフラグメントは、サービスのすべてのブロードキャスト構成要素を記述する。
○コンテンツ記述子は、各メディア構成要素の特性を記述するために加えられ得る。コンテンツ記述子は、ROUTE受信機がいくつかの構成要素を選択または拒絶し得るように十分な情報を与えるべきである。
・一般に、各構成要素(適応セット)に対して単一の表現だけが配信される。しかしながら、異なる表現が同じ適応セットに対して配信される場合、LSIDは、たとえば、品質ランキング、空間解像度、必要なコーデックパラメータ、などによって構成要素を区別するために十分な情報を含有し得る。
・1つのLCTセッション(TSIによって識別される)は、各表現に対して使用され得る。LCTセッションは、パケットレベルで多重化される。TTTは、多重化されたLCTセッションにわたって一貫して使用されるべきである。
・各パケットは、90kHzベースでのターゲット送信時間を含有し得る。この時間は、ターゲット配信時間を表す。好ましくは、ISO BMFF内で含有されるメディアの復号時間が使用される。
・以下の送信手順は、単一のLCTセッション内の表現に対して適用され得る。
○任意のオブジェクトがLCTセッション内で送られ得る。オブジェクトがメディアセグメントでない場合、TOI内の最上位ビットは0であり得る。オブジェクトがメディアセグメントである場合、TOI内の最上位ビットは1であり得る。オブジェクトがTable 1(表1)内の静的割当てによって識別されてよく、またはコードポイントがLSID内で定義されてもよい。
○メディアセグメントが特定のリリース時間を有するものと仮定する。メディアセグメントに対応するISは、同じリリース時間をシグナリングし得る。リリース時間は、メディアセグメントが直ちに後続する場合にのみ、IS内に送られ得ることに留意されたい。
○初期化セグメントは、ROUTEプロトコルを使用してオブジェクトとして送られる。ISに対して、最上位ビット内の0で始まるTOI番号だけが、使用され得る。
・初期化セグメントのタイプが、Table 1(表1)に従ってコードポイント内で告知される。
・ISが単一のROUTEパケットに適合する場合、コードポイント2、4または6が使用され得る。ISが単一のROUTEパケットに適合しない場合、コードポイント3、5または7が使用され得る。
・ISが最初に送られるかまたはタイムラインが連続でない場合、コードポイント2または3のいずれかがシグナリングされ得る。ISは新しいTOIを使用しなければならない。ISの第1のパケットは、TTTに対するランダム番号を与え得る。しかしながら、後者の場合、連続ストリームにおいて、TTTはプレイアウトスケジュールを表現するために連続しているべきである。
・ISがランダムアクセスをサポートするために繰り返される場合、コードポイント6または7のいずれかがシグナリングされ得る。TOIは同じままであってよい。TTTは連続であり、減少していない。
・ISが更新されるが、タイムラインは連続である場合、コードポイント4または5のいずれかが使用される。ISは新しいTOIを使用しなければならない。TTTは連続であってよく、減少していない。
・ISとともに、TTTと同じスケールでISの最早リリース時間を次のレイヤに示す拡張ヘッダが、送られ得る。存在しない場合、リリース時間は即時である。
○ メディアセグメント(MS)は、ROUTEプロトコルを使用してオブジェクトとして送られる。MSに対して、最上位ビット内の1で始まるTOI番号だけが、使用され得る。
・MSのタイプが、Table 1(表1)に従ってコードポイント内で告知される。
・MSが単一のROUTEパケットに適合する場合、コードポイント8が使用され得る。MSが単一のROUTEパケットに適合しない場合、コードポイント9が使用され得る。
○いくつかの追加の規則が必要である場合がある。
図13は、例示的な一連のパケットに対する例示的な送信手順を示す概念図である。この例では、第1の表現は、初期化セグメント480と2つのメディアセグメント482、484を含み、2つのメディアセグメント482、484が送られた後に、新しい初期化セグメント486および次のメディアセグメント488を有する第2の表現が続く。セグメントの各々はTSI=1を使用する。すなわち、このLCTセッションが使用される。順序を追ってパケットを送ることが、図13に示される:
・送られる第1のパケット(初期化セグメントパケット490A)は初期化セグメント480に対応し、TTTは、MS内の第1のサンプルの復号時間がAになるように設定される。TOIは初期化セグメントパケット490Aに対して選択され、CPは新しいタイムラインを示すために2に設定される。初期化セグメント480のリリース時間は、プレゼンテーションが開始するときを示すために、Aよりわずかに大きい値に設定される。
・第2のパケット(メディアセグメントパケット492A)はメディアセグメント482の第1のパケットであり、メディアセグメント482は断片化される。それゆえ、CP=9である。新しいTOIは、新しいオブジェクトを示すために使用される。初期化セグメント480のために使用されるTTTと同じTTTが、使用される。データは初期化セグメント480とともにリリースされるので、新しいRTは送られない。
・メディアセグメント482の第2のパケット(メディアセグメントパケット492B)に対して、(新しい送信時間が後の復号時間を含有するものと仮定して)新しい送信時間がC>Aに設定される。B<Cの場合、これは、初期化セグメント480およびメディアセグメントパケット492Aを次のレイヤにリリースすることをもたらすことになる。
・ランダムアクセスを可能にするために、初期化セグメント480は、TTTがメディアセグメント484のメディアセグメントパケット494AのTTTと一致するように、重複して(CP=4)送られることになる。リリース時間は、TTTのスケールにおいて設定される。
・次いで、メディアセグメント484は、メディアセグメント482と同じ方式で2つのパケット(メディアセグメントパケット494A、494B)内で送られる。この時間は、パケットをリリースするために使用される。新しいTOIが使用され、それは、メディアセグメント482のTOIより1つ多い。
・新しい期間が開始することによって、新しい初期化セグメント486が(初期化セグメントパケット496の形態で)送られることになり、新しい初期化セグメント486は、それゆえ、CP=2で記される。新しいTOIは、初期化セグメント486に対して使用される。新しい表現のTTTおよびRTは、プレイアウトシーケンスおよびタイミングを教示するために、前のTTTの継続であるべきである。
・その後、メディアセグメント488が、メディアセグメントパケット498を含む1つまたは複数のパケットとして送られ得る。
代替例では、軽量MPDが使用され得る。この例では、タイミングおよびバッファリングのシグナリングおよび動作は上記と同じであるが、他の手段を介する非タイミングMPD情報のシグナリングに対する上記の他の変更は取られない。代わりに、MPDが異なるシナリオに対して絶対に必要な情報(ブロードキャストにおける同調およびチャネル変更を含む)だけを含有するが、他の情報は存在しないことを可能にするように、MPDが変更される。極端な場合、MPD情報がまったく必要でないときは、MPDは空であってよい。情報のサブセットだけが必要でありかつ存在するとき、MPDは軽量であり、したがって不要なオーバーヘッドが回避される。送信側は、通常のMPDコピーをいくつかのRAPにおいて疎に置くこと、および2つの通常のMPDコピーの間で、軽量MPDを各RAPにおいて置くことを選択し得る。
これは、以下のいずれかまたは全部をもたし得る:
・単純であるが、フルMPDが受信されると冗長になる起動MPDを起動する。
・MPDは構成要素の情報だけを含有する。
・タイミングは、下位レイヤによって駆動されるので無視される。
・セグメントに対するURLはオブジェクトプロトコルを介して配信されるので、セグメントに対するURLは指定されない。
・基本的に、上述のコンテンツ識別子は、別個のオブジェクトにマッピングされる。
この時点において、ISO BMFFライブプロファイルに準拠するセグメントが使用され得る。そのようなアプリケーションに対する改善されたメディアフォーマットに対する最適化が、2015年2月10日に出願された米国仮出願第62/114,423号、Stockhammerら、「LOW LATENCY VIDEO STREAMING」に記載されており、その全内容が参照により本明細書に組み込まれている。
ハイブリッドサービス提案に対して、MPDは重要であり得る。ブロードキャストおよびブロードバンド配信コンテンツを記述する統合されたMPDが使用されてよく、それにより:
・MPDはROUTEセッション内のオブジェクトとして配信されるか、またはMPDはリンクを介してブロードバンド上のみで与えられるかのいずれかである。
・EFDTはROUTEセッション内のオブジェクトとして配信されるか、またはEFDTはリンクを介してブロードバンド上のみで与えられるかのいずれかである。
・EFDTは、オブジェクト配信内のTOIとMPD内で見ることができるURLとの間のマッピングを記述する。
・次いで、タイミングはMPDによって制御される、すなわちブロードキャストセグメントは、もはやISO BMFFクライアントにプッシュされず、DASHクライアントがタイミングを制御する。しかしながら、詳細は実装形態に固有のものである。
図14は、例示的なハイブリッドDASHクライアントモデルを示す概念図である。図1のクライアントデバイス40の取出しユニット52は、図14の例に従って構成され得る。この例では、ハイブリッドDASHクライアントモデルは、ROUTE受信機および出力バッファ506とDASHクライアント512とを含む。ハイブリッドDASHクライアントモデルによれば、クライアントデバイスは、ROUTE受信機および出力バッファ506を使用してROUTE送信を介して、またはDASHクライアント512を使用してネットワーク514からのユニキャスト送信を介してセグメント(たとえば、RAPパケット500およびパケット502、504)を受信し得る。セグメントを受信すると、ROUTE受信機および出力バッファ506がセグメントをISO BMFFバッファ508に供給するか、またはDASHクライアント512がセグメントをISO BMFFバッファ508に供給する。
ブロードキャストに対する受信のタイプに対して、2つの例示的なタイプの実装形態が存在する。
・MPDなしの受信:ROUTE受信機および出力バッファ506は、データを、ISO BMFFデコーダ510による復号およびプレイアウトのためにISO BMFFバッファ508に直接転送する。
・MPDベースの受信:ROUTE受信機および出力バッファ506は、すべての情報を含むMPDを生成し、それによって、DASHクライアント512はROUTE受信機および出力バッファ506(たとえば、プロキシサーバとして働く)からデータを取り出して、そのデータを復号およびプレイアウトのためにISO BMFFバッファ508に記憶する。
両バージョンが可能であり、実装形態の選択事項である。加えて、図14に示す方法でブロードキャストおよびブロードバンドを使用するハイブリッドクライアントが実装されてもよい。この場合、ROUTE受信機および出力バッファ506は、ブロードキャストストリームからデータを受信した後、受信されたデータをISO BMFFバッファ508に供給する。ブロードバンドが加えられると、その関係がMPDによって生成される。DASHクライアント512は、URLをTOIに割り当て、それゆえMPD内の情報に基づいてブロードバンドに切り替えることができる。
図15は、本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための例示的な方法を示すフローチャートである。図15の例は、図1のサーバデバイス60およびクライアントデバイス40に関して説明される。しかしながら、他のデバイスがこれらの技法を実行するように構成されてもよいことを理解されたい。たとえば、図4、図5、図6、図11、図12または図14のデバイスは、これらの技法を実行するように構成され得る。
最初に、サーバデバイス60は、メディアプレゼンテーションの複数の表現に対するデータを取得し得る(550)。たとえば、サーバデバイス60は、コンテンツプレゼンテーションデバイス20(図1)から、準備されたコンテンツを受信することができる。代替として、サーバデバイス60は、配信に対する表現を準備するためにメディアエンコーダ(オーディオエンコーダ26およびビデオエンコーダ28など)および/またはカプセル化ユニット(カプセル化ユニット30など)を含み得る。複数の表現は、図1のマルチメディアコンテンツ64の表現68に対応し得る。加えて、サーバデバイス60は、複数の表現(たとえば、図1のマニフェストファイル66)に対するMPDなどのマニフェストファイルを取得し得る。
次いで、サーバデバイス60は、表現をLCTセッションに割り当て得る(552)。一般に、LCTセッションの各々は、LCTセッションと表現との間に1対1の関係が存在するように、表現のうちの1つのデータを搬送し得る。その上、サーバデバイス60は、表現とLCTセッションとの間の対応を示す、LCTセッションに対するLSIDを構築し得る(554)。LSIDは、たとえば、LCTセッションに対するTSIと表現識別子(たとえば、表現に対する帯域幅)との間の関係をシグナリングし得る。上述のように、サーバデバイス60はまた、様々なLCTセッションに対するIPおよびポートの組合せを記述するためにLSIDを構築し得る。
サーバデバイス60はさらに、たとえば、上記で説明した@id、@group、@lang、@contentType、@par(ピクチャアスペクト比)、ロール要素、アクセシビリティ要素、視点要素、レーティング要素、表現のセグメントのセグメント特性、@profiles、@widthおよび@height、@sar、@framerate、@audiosamplingRate、@mimeType、@codecs、@scanType、FramePacking、AudioChannelConfiguration、ContentProtection、EssentialProperty、SupplementalProperty、および/またはInbandEventStreamのうちのいずれかまたは全部を含む属性など、マニフェストファイル内に従来から含まれるデータを含むようにLSIDを構築し得る。
その上、サーバデバイス60は、たとえば、図9の例によるLCTヘッダを含めるためにLCTセッションのパケットを構築し得る。パケットは、表現のセグメントのデータを含み得る。ヘッダ情報は、たとえば、対応する表現およびセグメントのTSIおよび/またはTOIを示し得る。
次いで、サーバデバイス60は、対応するLCTセッションを介してLSIDおよび表現のデータを送り得る(556)。クライアントデバイス40は、LCTセッションに対するLSIDを受信し得る(558)。図15の例には示さないが、サーバデバイス60はまた、マニフェストファイルを、たとえば表現のいくつかのランダムアクセスポイントとともに周期的に送り得る。具体的には、この例では、クライアントデバイス40は、マニフェストファイルを受信する前に(たとえば、マニフェストファイルの間に)LSIDを受信することが仮定されている。しかしながら、本開示の技法によれば、クライアントデバイス40は、マニフェストファイルを受信することなく(または受信する前に)LSIDを使用してLCTセッションのうちの1つまたは複数のメディアデータ(およびそれゆえ、対応する表現)にアクセスし得る。
たとえば、クライアントデバイス40は、LCTセッションと表現との間の対応を決定し得る。また、クライアントデバイス40は、LSID内でシグナリングされたデータを使用して表現の特性を決定し得る。たとえば、クライアントデバイス40は、表現のうちのどれが、オーディオデコーダ46、ビデオデコーダ48、オーディオ出力42およびビデオ出力44など、クライアントデバイス40の要素によってサポートされるコーディングおよびレンダリングの特性に匹敵するかを決定し得る。表現のサポートされる特性ならびにコーディングおよびレンダリングの特性に基づいて、クライアントデバイス40は、LSIDを使用して表現を選択し得る(560)。たとえば、クライアントデバイス40は、クライアントデバイス40の要素によってサポートされるコーディングおよびレンダリングの特性を有するそれらの表現を選択し得る。
さらに、クライアントデバイス40は、選択された表現のLCTセッションからパケットを抽出し得る(562)。各パケットは、表現のセグメントに対応し得る。表現の各セグメントは、1つまたは複数のパケットの形態で送信され得る。図10の様々な例に関して上記で説明したように、パケットは、パケットがいつリリースされ得るかを示す情報を含み得る。したがって、セグメントに対するすべてのパケットが受信された後、クライアントデバイス40の取出しユニット52は、再構築されたセグメントをカプセル化解除ユニット50に送ってよく、カプセル化解除ユニット50は最終的にメディアデータをカプセル化解除し、そのメディアデータを適切なデコーダ、たとえばオーディオデコーダ46またはビデオデコーダ48に送ってよい。このようにして、クライアントデバイス40は、メディアデータを復号のため、および最終的にプレゼンテーションのために、パケットから適切なデコーダに送り得る(564)。
このようにして、図15の例示的な方法は、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定するステップであって、LSIDが複数のLCTセッションを表す情報を含み、LCTセッションの各々が表現のそれぞれの表現のデータを含む、決定するステップと、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始するステップとを含む方法の一例を表し、消費の開始は、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットを受信するステップと、パケットのデータをメディアデコーダに供給するステップとを含む。
また、図15の例示的な方法は、複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築するステップであって、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す、ステップと、LSIDを出力するステップと、対応するLCTセッション内の表現のデータを出力するステップとを含む方法の一例をも表す。
図16は、本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための別の例示的な方法を示すフローチャートである。この例では、クライアントデバイス40は、最初に、階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定し、LSIDは複数のLCTセッションを表す情報を含み、LCTセッションの各々は表現のそれぞれの表現のデータを含む(580)。次いで、クライアントデバイス40は、DASHメディアプレゼンテーションに対してマニフェストファイルを使用せずにLSIDを使用してDASHメディアプレゼンテーションの表現のうちの1つまたは複数の表現の消費を開始する(582)。具体的には、消費を開始するとき、クライアントデバイス40は、表現のうちの1つまたは複数の表現のデータの部分を含むLCTセッションのパケットを受信し(584)、パケットのデータをメディアデコーダに供給する(586)。
図17は、本開示の技法によるLCTセッションを介するメディアプレゼンテーションのメディアデータをトランスポートするための別の例示的な方法を示すフローチャートである。この例では、サーバデバイス60は、複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築し、LCTセッションの各々は、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、LSIDは、LCTセッションと表現との間の対応を示す(590)。次いで、サーバデバイス60はLSIDを出力し(592)、対応するLCTセッション内の表現のデータを出力する(594)。
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 ネットワーク
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述(MPD)
110A 表現
110N 表現
112 ヘッダデータ
114 セグメント
114A セグメント
114B セグメント
114N セグメント
122 ヘッダデータ
124A セグメント
124B セグメント
124N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 動画(MOOV)ボックス
156 動画ヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 動画延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 ムービーフラグメントボックス
166 動画フラグメントランダムアクセス(MFRA)ボックス
180A メディアブロードキャスティング局
180B メディアブロードキャスティング局
182 ブートストラップデータ
184 階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)
186A シグナリングフラグメント
186N シグナリングフラグメント
188 オーディオデータ
188A オーディオデータ
188B オーディオデータ
190 ビデオデータ
190A ビデオデータ
190B ビデオデータ
192 時限のテキストデータ
194 ビデオエンハンスメントレイヤデータ
194A ビデオエンハンスメントレイヤデータ
194B ビデオエンハンスメントレイヤデータ
196 代替オーディオ言語データ
196A 代替オーディオ言語データ
196B 代替オーディオ言語データ
200 ブートストラップデータ
202 LSID
204 シグナリングフラグメント
204A シグナリングフラグメント
204N シグナリングフラグメント
206 オーディオデータ
206A オーディオデータ
206B オーディオデータ
208 ビデオデータ
208A ビデオデータ
208B ビデオデータ
210 アクセシビリティオーディオデータ
210A アクセシビリティオーディオデータ
210B アクセシビリティオーディオデータ
220 インターネットプロトコル(IP)マルチキャストユニット
222 静的構成ユニット
224 リアルタイムオブジェクト配信(ROUTE)受信ユニット
226 キャッシュ
228 プロキシサーバ
230 動的適応ストリーミングオーバーHTTP(DASH)クライアント
240 基本的送信側アーキテクチャ
242 オーディオ/ビデオ(A/V)ソースコンテンツ
244 マルチビットレートオフラインメディアエンコーダ
246A オーディオ/ビデオ(A/V)ソースコンテンツ
246B A/Vライブコンテンツ
248 マルチビットレートライブメディアエンコーダ
250 DASHオフラインオーサリングユニット
252 広告(ad)挿入ユニット
254 ヒントおよびタイミング情報
256 DASHライブオーサリングユニット
258 HTTPライブエミュレーションサーバ
260 HTTPライブサーバ
262 ROUTEサーバ
264 構成データ(図6より)
280 サービスエントリ
282 初期化セグメント
284 MPD
286 メディアセグメント
286A メディアセグメント
286B メディアセグメント
288 ファイル配信テーブル(FDT)
290 処理依存性
292 送信順序
300 サービスエントリ
302 拡張FDT(EFDT)
304 初期化セグメント
306 MPD
308A メディアセグメントメディア配信イベント(MDE)
308B メディアセグメント残余
310 メディアセグメント
312 処理依存性
314 パケットの送信順序
320 LCTヘッダ
322 バージョンフィールド
324 輻輳制御フラグ
326 プロトコル固有の表示(PSI)フィールド
328 トランスポートセッション識別子フラグ(S)
330 トランスポートオブジェクト識別子(O)フラグ
332 ハーフワード(H)フラグ
334 確保された(RES)フィールド
336 クローズセッション(A)フラグ
338 クローズオブジェクト(B)フラグ
340 LCTヘッダ長(HDR_LEN)フィールド
342 コードポイントフィールド
344 輻輳制御情報
346 トランスポートセッション識別子
348 トランスポートオブジェクト識別子
350 ヘッダ拡張フィールド
360 第1の例示的なオプション
362 TTT1(TTT:ターゲット送信時間)
364 リリース時間(RT)
366 ランダムアクセスポイント(RAP)パケット
368A パケット
368B パケット
370 TTT2
374 パケット
380 第2の例示的なオプション
382 リリース時間(RT)
384 RAPパケット
386 パケット
388 パケット
390 時間
392 パケット
400 第3の例示的なオプション
402 リリースフラグ(RF)
404 RAPパケット
406A パケット
406B パケット
408 RF=1
410 NTP時間
412 パケット
420 RAPパケット
422 パケット
424 パケット
426 ROUTE受信機および出力バッファ
428 ISOベースメディアファイルフォーマット(ISO BMFF)バッファ
430 ISO BMFFデコーダ
432 モデル
440 RAPパケット
442 パケット
444 パケット
446 ROUTE受信機
448 ROUTE出力およびISO BMFFバッファ
450 ISO BMFFデコーダ
452 モデル
460 受信側デバイス
462 選択およびフィルタリングユニット
464 ROUTE受信機
466 オブジェクトプロセッサ
468 ISO BMFFメディアプロセッサ
470 ISO BMFFプリプロセッサ
480 初期化セグメント
482 メディアセグメント
484 メディアセグメント
486 初期化セグメント
488 メディアセグメント
490A 初期化セグメントパケット
490B 初期化セグメントパケット
492A メディアセグメントパケット
492B メディアセグメントパケット
494A メディアセグメントパケット
494B メディアセグメントパケット
496 初期化セグメントパケット
498 メディアセグメントパケット
500 RAPパケット
502 パケット
504 パケット
506 ROUTE受信機および出力バッファ
508 ISO BMFFバッファ
510 ISO BMFFデコーダ
512 DASHクライアント
514 ネットワーク

Claims (14)

  1. メディアデータを受信する方法であって、
    受信された階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定するステップであって、前記LSIDが複数のLCTセッションを表す情報を含み、前記LCTセッションの各々が前記表現のそれぞれの表現のデータを含み、前記LSIDが前記LCTセッションと前記表現との間の対応を示す、決定するステップと、
    前記LSIDを使用して前記DASHメディアプレゼンテーションの前記表現のうちの1つまたは複数の表現の消費を開始するステップとを含み、前記消費を開始するステップが、
    前記LSIDに基づいて前記LCTセッションと前記表現との間の前記対応を決定するステップと、
    前記表現のうちの1つまたは複数の表現のデータの部分を含む前記LCTセッションのパケットを受信するステップと、
    前記パケットのデータをメディアデコーダに供給するステップとを含む、方法。
  2. 前記LSIDの1つまたは複数のコンテンツ記述子から前記DASHメディアプレゼンテーションの前記表現のコーディング特性またはレンダリング特性のうちの少なくとも1つを決定するステップと、
    前記決定されたコーディング特性またはレンダリング特性に基づいて前記表現のうちの前記1つまたは複数を選択するステップとをさらに含む、請求項1に記載の方法。
  3. 前記1つまたは複数のコーディング特性またはレンダリング特性が、コーデック、アクセシビリティ情報、品質、空間解像度、視点、レーティング、適応セットのプロファイル属性、サンプルアスペクト比、フレームレート、オーディオサンプリングレート、mimeタイプ、走査タイプ、フレームパッキング情報、オーディオチャネル構成、コンテンツ保護方式、本質的特性、補助的特性、または帯域内イベントストリームの存在のうちの1つまたは複数を含む、請求項2に記載の方法。
  4. 消費を開始するステップが、マニフェストファイルを使用することなく第1の再生時間まで前記1つまたは複数の表現の第1のデータのセットを受信するステップを含み、前記方法が、
    前記マニフェストファイルを受信するステップと、
    前記マニフェストファイルを使用して前記DASHメディアプレゼンテーションの、前記第1のデータのセットとは異なる第2のデータのセットを受信するステップとをさらに含み、前記第2のデータのセットが前記第1の再生時間に続く再生時間を有する、請求項1に記載の方法。
  5. 前記DASHメディアプレゼンテーションのデータのブロードキャスト配信とユニキャスト配信とを組み合わせるために前記マニフェストファイルを使用するステップをさらに含む、請求項4に記載の方法。
  6. 前記マニフェストファイルが、メディアプレゼンテーション記述(MPD)である、請求項4に記載の方法。
  7. 前記LCTセッションの前記パケット内でターゲット送信時間を示すデータを受信するステップをさらに含み、
    前記ターゲット送信時間を示す前記データを受信するステップが、前記パケットのLCTヘッダの輻輳制御情報フィールドまたは前記LCTヘッダのヘッダ拡張フィールドの中の前記ターゲット送信時間を示す前記データを受信するステップを含む、請求項1に記載の方法。
  8. 前記1つまたは複数の表現のうちの少なくとも1つが、初期化セグメントと、DASHセグメントフォーマットに従ってフォーマットされた1つまたは複数のメディアセグメントとを含み、前記初期化セグメントまたはメディアセグメントに対するデータを備えるパケットが、LCTヘッダをさらに備える、請求項1に記載の方法。
  9. 前記LCTセッションと前記表現との間の対応を決定するために、前記LCTセッション記述の前記パケットのLCTヘッダのトランスポートセッション識別子(TSI)フィールドを使用するステップをさらに含む、請求項1に記載の方法。
  10. 前記パケットのLCTヘッダのプロトコル固有の表示(PSI)ビットまたは前記パケットの前記LCTヘッダの拡張ヘッダのうちの少なくとも1つから前記LCTセッションのパケットのデータに対するリリース時間を決定するステップをさらに含む、請求項1に記載の方法。
  11. 前記パケットのLCTヘッダの輻輳制御情報から前記LCTセッションのパケットに対するターゲット送信時間を決定するステップをさらに含む、請求項1に記載の方法。
  12. メディアデータを受信するためのデバイスであって、
    受信された階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)から動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現を決定するための手段であって、前記LSIDが複数のLCTセッションを表す情報を含み、前記LCTセッションの各々が前記表現のそれぞれの表現のデータを含み、前記LSIDが前記LCTセッションと前記表現との間の対応を示す、決定するための手段と、
    前記LSIDを使用して前記DASHメディアプレゼンテーションの前記表現のうちの1つまたは複数の表現の消費を開始するための手段とを含み、消費を開始するための前記手段が、
    前記LSIDに基づいて前記LCTセッションと前記表現との間の前記対応を決定するための手段と、
    前記表現のうちの前記1つまたは複数の表現のデータの部分を含む前記LCTセッションのパケットを受信するための手段と、
    前記パケットのデータをメディアデコーダに供給するための手段とを含む、デバイス。
  13. メディアデータを送る方法であって、
    複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築するステップであって、前記LCTセッションの各々が動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、前記LSIDが前記LCTセッションと前記表現との間の対応を示す、構築するステップと、
    前記LSIDを出力するステップと、
    前記対応するLCTセッション内の前記表現のデータを出力するステップとを含む、方法。
  14. メディアデータを送るためのデバイスであって、
    複数のLCTセッションを表す情報を含む階層符号化トランスポート(LCT)セッションインスタンス記述(LSID)を構築するための手段であって、前記LCTセッションの各々が動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーションの複数の表現のそれぞれの表現のデータを含み、前記LSIDが前記LCTセッションと前記表現との間の対応を示す、構築するための手段と、
    前記LSIDを出力するための手段と、
    前記対応するLCTセッション内の前記表現のデータを出力するための手段とを含む、デバイス。
JP2017545751A 2015-03-04 2016-03-03 Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング Active JP6807852B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562128380P 2015-03-04 2015-03-04
US62/128,380 2015-03-04
US201562128943P 2015-03-05 2015-03-05
US62/128,943 2015-03-05
US15/058,963 US10454985B2 (en) 2015-03-04 2016-03-02 File format based streaming with dash formats based on LCT
US15/058,963 2016-03-02
PCT/US2016/020652 WO2016141165A1 (en) 2015-03-04 2016-03-03 File format based streaming with dash formats based on lct

Publications (3)

Publication Number Publication Date
JP2018512771A JP2018512771A (ja) 2018-05-17
JP2018512771A5 JP2018512771A5 (ja) 2019-03-28
JP6807852B2 true JP6807852B2 (ja) 2021-01-06

Family

ID=55587361

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017545751A Active JP6807852B2 (ja) 2015-03-04 2016-03-03 Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング

Country Status (8)

Country Link
US (1) US10454985B2 (ja)
EP (1) EP3266218B1 (ja)
JP (1) JP6807852B2 (ja)
KR (1) KR102469676B1 (ja)
CN (1) CN107409234B (ja)
AU (1) AU2016226206B2 (ja)
ES (1) ES2848116T3 (ja)
WO (1) WO2016141165A1 (ja)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101901944B1 (ko) 2014-07-09 2018-09-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016105100A1 (ko) 2014-12-22 2016-06-30 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016126116A1 (ko) * 2015-02-04 2016-08-11 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016148547A1 (ko) 2015-03-19 2016-09-22 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017043863A1 (ko) * 2015-09-07 2017-03-16 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
MX2019002898A (es) 2016-10-04 2019-07-04 Sony Corp Dispositivo de recepcion, dispositivo de transmision y metodo de procesamiento de datos.
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
EP3364580B1 (en) * 2017-02-17 2022-06-22 Tdf Transmission of redundancy data in a hybrid network system
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
KR102263223B1 (ko) 2017-03-14 2021-06-09 삼성전자 주식회사 전자장치 및 그 제어방법
EP3410728A1 (en) * 2017-05-30 2018-12-05 Vestel Elektronik Sanayi ve Ticaret A.S. Methods and apparatus for streaming data
CN107888932A (zh) * 2017-10-20 2018-04-06 深圳思麦杰科技有限公司 一种基于浏览器的跨平台视频直播的系统及方法
GB2570879B (en) * 2018-02-06 2022-08-17 Advanced Risc Mach Ltd Encoding data arrays
WO2019199379A1 (en) * 2018-04-13 2019-10-17 Futurewei Technologies, Inc. Immersive media metrics for virtual reality content with multiple viewpoints
WO2020000135A1 (zh) * 2018-06-25 2020-01-02 华为技术有限公司 一种包含字幕的高动态范围视频处理的方法及装置
US11184665B2 (en) * 2018-10-03 2021-11-23 Qualcomm Incorporated Initialization set for network streaming of media data
US11546402B2 (en) * 2019-01-04 2023-01-03 Tencent America LLC Flexible interoperability and capability signaling using initialization hierarchy
US11381867B2 (en) * 2019-01-08 2022-07-05 Qualcomm Incorporated Multiple decoder interface for streamed media data
JP7296219B2 (ja) * 2019-03-07 2023-06-22 日本放送協会 受信装置、送信装置、及びプログラム
US12074934B2 (en) 2019-03-15 2024-08-27 Nokia Technologies Oy Method and apparatus for grouping entities in media content
US10979477B1 (en) * 2019-03-26 2021-04-13 Amazon Technologies, Inc. Time synchronization between live video streaming and live metadata
US11425187B2 (en) * 2019-09-30 2022-08-23 Tencent America Llc. Session-based information for dynamic adaptive streaming over HTTP
US11303688B2 (en) * 2019-09-30 2022-04-12 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
US11616822B2 (en) * 2019-09-30 2023-03-28 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
CN114930866A (zh) * 2020-01-03 2022-08-19 诺基亚技术有限公司 用于实时纹理适配的方法
US11570509B2 (en) * 2020-01-06 2023-01-31 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
US11228796B2 (en) * 2020-01-07 2022-01-18 Tencent America LLC Pattern addressing for session-based dash operations
US11822555B2 (en) * 2020-02-03 2023-11-21 Tencent America LLC Signaling and resolution model for multi-level session-based description descriptors
CN113206819B (zh) * 2020-02-03 2023-04-07 腾讯美国有限责任公司 基于多级别会话描述符的信令发送方法及装置
EP3958579A1 (en) * 2020-08-17 2022-02-23 THEO Technologies A media decoder for decoding streamed media and a method therefor
US11470136B2 (en) * 2020-10-07 2022-10-11 Tencent America LLC URL customization using the session-based dash operations
US11533346B2 (en) * 2021-01-05 2022-12-20 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
US11451602B2 (en) * 2021-01-06 2022-09-20 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
US11895172B2 (en) * 2021-04-21 2024-02-06 Tencent America LLC Session-based description URL customization using the session-based DASH operations
US11412283B1 (en) 2021-04-27 2022-08-09 City University Of Hong Kong System and method for adaptively streaming video
US11888913B2 (en) * 2021-04-28 2024-01-30 Lemon Inc. External stream representation properties
CN113691880B (zh) * 2021-08-25 2024-04-16 三星电子（中国）研发中心 一种应用于dash低延迟直播流的带宽测量方法和设备
US12052447B1 (en) 2022-06-27 2024-07-30 Amazon Technologies, Inc. Dynamically moving transcoding of content between servers
US11910044B1 (en) * 2022-06-30 2024-02-20 Amazon Technologies, Inc. Systems and methods for switching the processing of a live content stream to another datacenter

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7376150B2 (en) * 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
US20130097334A1 (en) * 2010-06-14 2013-04-18 Thomson Licensing Method and apparatus for encapsulating coded multi-component video
US9026671B2 (en) 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
WO2013107502A1 (en) * 2012-01-17 2013-07-25 Telefonaktiebolaget L M Ericsson (Publ) Method for sending respectively receiving a media stream
US10389780B2 (en) * 2012-02-08 2019-08-20 Arris Enterprises Llc Managed adaptive streaming
WO2014063730A1 (en) 2012-10-24 2014-05-01 Huawei Technologies Co., Ltd. Communication receiver
KR102273757B1 (ko) * 2014-01-03 2021-07-06 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
JP6466951B2 (ja) * 2014-01-13 2019-02-06 エルジー エレクトロニクス インコーポレイティド 一つ以上のネットワークを介して放送コンテンツを送受信する装置及び方法
EP3175624A4 (en) * 2014-07-31 2018-02-28 LG Electronics Inc. Apparatus and method for transmitting/receiving processes of a broadcast signal
US10129308B2 (en) 2015-01-08 2018-11-13 Qualcomm Incorporated Session description information for over-the-air broadcast media data
US10270823B2 (en) 2015-02-10 2019-04-23 Qualcomm Incorporated Low latency video streaming

Also Published As

Publication number Publication date
JP2018512771A (ja) 2018-05-17
US10454985B2 (en) 2019-10-22
AU2016226206B2 (en) 2020-01-23
BR112017018956A2 (pt) 2018-05-15
AU2016226206A1 (en) 2017-08-17
EP3266218B1 (en) 2020-11-04
WO2016141165A1 (en) 2016-09-09
EP3266218A1 (en) 2018-01-10
US20160261665A1 (en) 2016-09-08
ES2848116T3 (es) 2021-08-05
CN107409234B (zh) 2020-12-25
KR102469676B1 (ko) 2022-11-21
CN107409234A (zh) 2017-11-28
KR20170123630A (ko) 2017-11-08

Similar Documents

Publication Publication Date Title
JP6807852B2 (ja) Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング
US10666961B2 (en) Determining media delivery event locations for media transport
KR102168596B1 (ko) 저 레이턴시 비디오 스트리밍
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
TWI668982B (zh) 用於多媒體和檔案傳輸的傳輸介面的方法及伺服器設備、及用於記錄相關指令於其上的電腦可讀取儲存媒體
TWI846795B (zh) 用於經串流媒體資料之多個解碼器介面
US20200112753A1 (en) Service description for streaming media data
KR102076064B1 (ko) Dash의 강건한 라이브 동작
JP2018532334A (ja) メディアデータのストリーミングのためのデッドラインシグナリング
BR112017018956B1 (pt) Fluxo contínuo baseado em formato de arquivo com formatos dash baseados em lct
EA045713B1 (ru) Способ и клиентское устройство для извлечения мультимедийных данных из серверного устройства

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190214

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190214

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191007

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191125

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200225

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20200727

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200831

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20200831

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20200908

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20200914

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201109

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201208

R150 Certificate of patent or registration of utility model

Ref document number: 6807852

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250