JP2019506059A - メディア転送のためのメディア配信イベントロケーションの決定 - Google Patents

メディア転送のためのメディア配信イベントロケーションの決定 Download PDF

Info

Publication number
JP2019506059A
JP2019506059A JP2018535028A JP2018535028A JP2019506059A JP 2019506059 A JP2019506059 A JP 2019506059A JP 2018535028 A JP2018535028 A JP 2018535028A JP 2018535028 A JP2018535028 A JP 2018535028A JP 2019506059 A JP2019506059 A JP 2019506059A
Authority
JP
Japan
Prior art keywords
mde
data
determining
location
video
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.)
Granted
Application number
JP2018535028A
Other languages
English (en)
Other versions
JP2019506059A5 (ja
JP6893930B2 (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 JP2019506059A publication Critical patent/JP2019506059A/ja
Publication of JP2019506059A5 publication Critical patent/JP2019506059A5/ja
Application granted granted Critical
Publication of JP6893930B2 publication Critical patent/JP6893930B2/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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • 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/23614—Multiplexing 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/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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Warehouses Or Storage Devices (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

メディアデータを転送する方法は、ソースデバイスのファイルベースプロトコル送信ユニットによって、セグメントを形成するソースデバイスのセグメンタからメディアデータのセグメントを含むデータのストリームを受信するステップであって、セグメントの各々が、固有のユニフォームリソースロケータ(URL)に関連付けられたそれぞれの個別に取出し可能なファイルを含む、ステップと、メディアデータのストリーム内のメディア配信イベント(MDE)のロケーションを決定するステップであって、MDEがセグメントのうちの1つの少なくとも一部分に対するデータを含む、ステップと、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する1つまたは複数の送信時間要件を決定するステップと、物理層送信ユニットに対する利用可能な配信スロットに従ってソースデバイスの物理層送信ユニットにMDEと送信時間要件を表すデータとを提供するステップとを含む。

Description

本出願は、その内容全体が参照により本明細書に組み込まれている、2016年1月8日に出願した米国仮出願第62/276,674号の利益を主張するものである。
本開示は、メディアデータの転送に関する。
デジタルオーディオおよびビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。
オーディオおよびビデオデータなどのメディアデータは、転送のために圧縮され得る。圧縮は、一般にメディアデータの符号化を含む。メディアデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。メディアデータは、AVCなどの国際標準化機構ベースメディアファイルフォーマット(ISO BMFF)およびその拡張であるAVCなど、様々な規格のいずれかに準拠するメディアファイルへとアセンブルされ得る。
様々な技法が、コンピュータネットワークを介してメディアデータを転送するために使用され得る。たとえば、メディアデータは、ブロードキャストプロトコルまたはユニキャストプロトコルを介して配信され得る。ブロードキャストプロトコルでは、サーバデバイスは、複数の加入側クライアントデバイスにメディアデータを送信する。ユニキャストプロトコルでは、クライアントデバイスはサーバデバイスからメディアデータを要求し、サーバデバイスは要求に応答してメディアデータを配信する。
一般に、本開示は、たとえば、ROUTE(ATSC作業草案:シグナリング、配信、同期、およびエラー保護、2015年11月20日)およびMMT(ISO/IEC:ISO/IEC 23008-1第2版、情報技術-異機種環境における高効率コーディングおよびメディア配信-パート1:MPEGメディア転送(MMT))またはFLUTE(ROUTEの適切なサブセットであるRFC 6726)を介するメディアアウェアバイト範囲配信において使用されるメディア配信イベント(MDE)のサポートに関連する技法を説明する。これらの配信技法は、さらに、ブロードキャスト動的適応ストリーミングオーバーHTTP(DASH)、共通メディアアプリケーションフォーマット(CMAF)、または同様のセグメントもしくはメディアアウェアバイト範囲ベースのメディア配信方法を使用し得る。本開示はまた、検出されたMDEの時間ラベリングを決定するための技法と、メディア整合された物理層フレーミングに対する早期メディア配信の影響を考慮する物理層における配信に対する適応技法とを説明する。
一例では、メディアデータを転送する方法は、ソースデバイスのファイルベースプロトコル送信ユニットによって、セグメントを形成するソースデバイスのセグメンタからメディアデータのセグメントを含むデータのストリームを受信するステップであって、セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個別に取出し可能なファイルを含む、ステップと、メディアデータのストリーム内のメディア配信イベント(MDE)のロケーションを決定するステップであって、MDEがセグメントのうちの1つの少なくとも一部分に対するデータを含む、ステップと、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する1つまたは複数の送信時間要件を決定するステップと、物理層送信ユニットに対する利用可能な配信スロットに従ってソースデバイスの物理層送信ユニットにMDEと送信時間要件を表すデータとを提供するステップとを含む。
別の例では、メディアデータを転送するためのデバイスは、メディアデータのセグメントを含むデータのストリームを形成するように構成されたセグメンタを含み、セグメントの各々は、それぞれの個々に取出し可能なファイル、たとえば、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたISO BMFFフォーマットを含む。デバイスはまた、メディア配信イベント(MDE)に対する送信時間要件に従ってクライアントデバイスにMDEを配信するように構成された物理層送信ユニットを含み、MDEはセグメントのうちの1つの少なくとも一部分に対するデータを含み、物理層送信ユニットは配信されるべきデータを受信するために利用可能な配信スロットで構成される。デバイスは、セグメンタからメディアデータのセグメントを含むデータのストリームを受信することと、メディアデータのストリーム内のMDEのロケーションを決定することと、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する送信時間要件のうちの1つまたは複数を決定することと、物理層送信ユニットに対する利用可能な配信スロットに従って物理層送信ユニットにMDEと送信時間要件を表すデータとを提供することとを行うように構成された、ファイルベースプロトコル送信ユニットをさらに含む。
別の例では、メディアデータを転送するためのデバイスは、メディアデータのセグメントを含むデータのストリームを形成するように構成されたセグメンタを含み、セグメントの各々は、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個々に取出し可能なファイルを含む。デバイスはまた、メディア配信イベント(MDE)に対する送信時間要件に従ってクライアントデバイスにMDEを配信するように構成された物理層送信ユニットを含み、MDEはセグメントのうちの1つの少なくとも一部分に対するデータを含み、物理層送信ユニットは配信されるべきデータを受信するために利用可能な配信スロットで構成される。デバイスは、セグメンタからメディアデータのセグメントを含むデータのストリームを受信するための手段と、メディアデータのストリーム内のMDEのロケーションを決定するための手段と、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する1つまたは複数の送信時間要件を決定するための手段と、物理層送信ユニットに対する利用可能な配信スロットに従って物理層送信ユニットにMDEと送信時間要件を表すデータとを提供するための手段とをさらに含む。
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、命令は、実行されたとき、ソースデバイスのファイルベースプロトコル送信ユニットに、セグメントを形成するソースデバイスのセグメンタからメディアデータのセグメントを含むデータのストリームを受信することであって、セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個別に取出し可能なファイルを含む、受信することと、メディアデータのストリーム内のメディア配信イベント(MDE)のロケーションを決定することであって、MDEがセグメントのうちの1つの少なくとも一部分に対するデータを含む、決定することと、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する1つまたは複数の送信時間要件を決定することと、物理層送信ユニットに対する利用可能な配信スロットに従ってソースデバイスの物理層送信ユニットにMDEと送信時間要件を表すデータとを提供することとを行わせる。
1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。 例示的なブロードキャスト動的適応ストリーミングオーバーHTTP(DASH)インフラストラクチャシステムを示すブロック図である。 例示的な高レベル構成のMDEを示す概念図である。 例示的なフレームタイプケイデンスおよび対応する規定されたMDEを示す概念図である。 システム時間の単純なビューを表す概念図である。 送信インフラストラクチャ内の時間関係を表すブロック図である。 千鳥形ランダムアクセスポイント(RAP)ロケーションを有するピクチャグループ(GOP)につき複数のセグメントを示す概念図である。 メディア再生のための時間を復号する最小遅延を示す概念図である。 任意の物理層同期および関連するメタデータを示す概念図である。 獲得イベントの例示的なシーケンスを示すフローチャートである。 本開示の技法による別の例示的な方法を示すフローチャートである。
一般に、本開示は、メディアデータの転送に関連する技法を説明する。本開示の技法は、クライアントデバイスにメディアデータをストリーミングするサーバデバイスまたは他のソースデバイスによって実行され得る。詳細には、ソースデバイスは、セグメンタと、ファイルベースプロトコル送信ユニットと、物理層送信ユニットとを含み得る。セグメンタは、メディアデータのセグメントを形成するユニットに対応し得、セグメントは、たとえば動的適応ストリーミングオーバーHTTP(DASH)セグメントに準拠する。たとえば、セグメンタは、それぞれのDASHセグメントにネットワークアブストラクションレイヤ(NAL)ユニットをカプセル化し得、セグメントはそれぞれ、別個のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられ得る。ファイルベースプロトコル送信ユニットは、単方向伝送によるファイル配信(FLUTE)またはROUTEなどのファイルベースプロトコルを使用してデータを送信するように構成され得る。物理層送信ユニットは、たとえばイーサネット(登録商標)を使用して物理層においてメディアデータを送信することができる。
本開示の技法によれば、セグメンタは、メディアデータの両セグメントをセグメントのストリームの形式でファイルベースプロトコル送信ユニットに供給し得る。したがって、ファイルベースプロトコル送信ユニットは、セグメンタからメディアデータのセグメントを含むデータのストリームを受信し得る。次いで、ファイルベースプロトコル送信ユニットは、メディアデータのストリーム内のメディア配信イベント(MDE)のロケーションを決定し得る。一例では、ファイルベースプロトコル送信ユニットは、メディアデータのストリームからMDEを形成し得る。たとえば、ファイルベースプロトコル送信ユニットは、ストリームのどの部分が特定のMDE内に含まれるべきであるかを決定し得、それにより、MDEは、メディアデコーダに有用なデータ(たとえば、以前のデータが正確に配信されたと仮定して、メディアデコーダによって適切に復号され得るデータ)を含む。
MDEのロケーションを決定するために、ファイルベースプロトコル送信ユニットはパターンマッチング技法を使用し得、その技法において、ファイルベースプロトコル送信ユニットは、ストリーム内に含まれるメディアデータに対する1つまたは複数のパターンで構成される。そのようなパターンは、たとえば、階層的復号順序におけるメディアデータの配置を表し得る。たとえば、ビデオデータは、一定数のイントラ予測フレーム(Iフレーム)に従って配置され、一定数の単方向インター予測フレーム(Pフレーム)が続いて配置され、一定数の双方向インター予測フレーム(Bフレーム)が続いて(または中間に)配置され得る。ファイルベースプロトコル送信ユニットは、I、P、およびBフレームの検出に基づいてMDEのロケーションを決定し得、一例として、最初のIフレームから開始して後続のIフレームの前に最終のBフレームで終了するビデオシーケンスをMDEが含むものと決定する。さらに、ファイルベースプロトコル送信ユニットは、ビデオMDEがセグメントの特定のバイト範囲に対応し、バイト範囲はフレーム境界において終了するものと決定し得る。別の例として、ファイルベースプロトコル送信ユニットは、オーディオMDEが固定数のオーディオフレームを含むものと決定し得る。
別の例として、(たとえば、MDEを形成するために)MDEのロケーションを決定するために、ファイルベースプロトコル送信ユニットは、ストリーム内のオーディオデータ、ビデオデータ、および/または時限テキストデータなど、様々なタイプのメディアデータのロケーションを規定するルールに従って構成され得る。ルールは、たとえば、ファイルベースプロトコル送信ユニットが、メディアデータのタイプを区別してメディアデータのタイプをそれぞれのMDEに割り振ることができるように、ストリーム内のメディアデータの様々なタイプの配置を規定し得る。
加えて、ファイルベースプロトコル送信ユニットはまた、MDEに対する1つまたは複数の配信時間要件(送信時間要件とも呼ばれる)を決定し得、ここで送信時間要件は、MDEがクライアントデバイスに送信されるべき時間を表す。たとえば、送信時間要件は、MDEがクライアントデバイスに送信されるべき最早および/または最遅の時間を表し得る。MDEは、たとえば、クライアントデバイスにおけるバッファオーバーフローを予防するために、MDEがクライアントデバイスに送信され得る最早の時間要件を有し得る。MDEはまた、たとえば、クライアントデバイスにおけるバッファアンダーランを予防するために、MDEがクライアントデバイスに送信され得る最遅の時間要件を有し得る。
次いで、ファイルベースプロトコル送信ユニットは、MDEを、送信時間要件を表すデータとともに物理層送信ユニットに送信し得る。詳細には、ファイルベースプロトコル送信ユニットは、物理層送信ユニットに対する利用可能な配信スロットを決定し、物理層送信ユニットが送信時間要件に従ってMDEを配信することができるように物理層送信ユニットにMDEと送信時間要件データとを送信することができる。
上記で説明したソースデバイスは、DASHなどのHTTPストリーミングプロトコルに従ってデータをストリーミングするように構成され得る。HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)またはユニフォームリソース識別子(URI)に関連付けられたペイロードを取り出すことなく、URL、URNまたはURIに関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURL、URN、またはURIと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、HTTPストリーミングに動画フラグメントが利用されてもよい。動画フラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在してもよい。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントがアクセス可能なデータの構造化された集合体であってもよい。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示してもよい。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含んでもよい。周期は、MPDにおける周期要素によって定義されてもよい。各周期は、MPDにおける属性startを有してもよい。MPDは、周期ごとにstart属性とavailableStartTime属性とを含んでもよい。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含んでもよい。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用される場合がある。
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられてもよい。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられてもよいので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択されてもよい。いくつかの例では、1つの期間内のメディアコンテンツは、グループ0が存在する場合にはグループ0からの1つの表現によって表されてもよく、あるいは各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表されてもよい。ある期間の各表現のタイミングデータは、期間の開始時間に対して表されてもよい。
表現は1つまたは複数のセグメントを含んでもよい。各表現が初期化セグメントを含んでもよく、または表現の各セグメントが自己初期化するものであってもよい。初期化セグメントは、それが存在する場合、表現にアクセスするための初期化情報を含んでもよい。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照されてもよい。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
それぞれに異なるタイプのメディアデータに対して実質的に同時に取出しを行うためにそれぞれに異なる表現が選択されてもよい。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74または別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図1の例では、コンテンツ準備デバイス20は、オーディオソース22とビデオソース24とを備える。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備えてもよい。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備えてもよい。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備えてもよい。コンテンツ準備デバイス20は必ずしも、すべての例において、サーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶する場合がある。
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含んでもよい。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化されてもよい。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を備えてもよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を備えてもよい。このようにして、本開示において説明する技法は、ライブオーディオデータおよびビデオデータ、ストリーミングオーディオデータおよびビデオデータ、リアルタイムオーディオデータおよびビデオデータに適用されてもよく、あるいは保管されたオーディオデータおよびビデオデータ、以前に記録されたオーディオデータおよびビデオデータに適用されてもよい。
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に包含されたビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを包含するオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応する場合がある。したがって、ビデオフレームに対応するオーディオフレームは、一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
いくつかの例では、オーディオエンコーダ26は、符号化された各オーディオフレームにおいて、符号化されたオーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプを符号化してもよく、同様に、ビデオエンコーダ28は、符号化された各ビデオフレームにおいて、符号化されたビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプを符号化してもよい。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含んでもよい。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成する場合がある内部クロック、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用する場合がある内部クロックを含んでもよい。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に相当するデータをオーディオエンコーダ26に送ってもよく、ビデオソース24は、ビデオデータが記録された時間に相当するデータをビデオエンコーダ28に送ってもよい。いくつかの例では、オーディオエンコーダ26は、符号化されたオーディオデータにおいて、符号化されたオーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化してもよく、同様に、ビデオエンコーダ28も、符号化されたビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用してもよい。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は、一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の、デジタル的にコーディングされた(場合によっては、圧縮された)単一の構成要素である。たとえば、表現のコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであってもよい。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは、一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
図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またはURIを使用して、表現68のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。
追加または代替として、要求処理ユニット70は、ブロードキャストまたはeMBMSもしくはDVB-T/T2などのマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントをeMBMS、DVB-T/T2または別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループと関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)と関連付けられたクライアントデバイスに広告することができる。次に、クライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえば、ネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
さらに、サーバデバイス60のネットワークインターフェース72は、本開示の技法を実行するように構成され得る。追加または代替として、要求処理ユニット70およびネットワークインターフェース72は、本開示の技法を実行するように構成され得る。説明の目的で、ネットワークインターフェース72は、以下でさらに詳細に説明する様々な例など、図1に明示的に示していない副構成要素を含むことが仮定されている。たとえば、ネットワークインターフェース72は、センダ、スケジューラ、フレーマ、および励振器/増幅器を含み得る。加えて、この例では、カプセル化ユニット30は、セグメンタ(すなわち、メディアデータのセグメントを形成するユニット、ここでセグメントはそれぞれのURL/URIに関連付けられた個々のファイルを表す)の一例を表す。詳細には、カプセル化ユニット30は、セグメント内のMDEをカプセル化し得、各セグメントは1つまたは複数のMDEを含み得る。
本開示の技法によれば、カプセル化ユニット30は、サーバデバイス60にメディアデータのセグメントのストリームを提供し得、サーバデバイス60は、最終的に、クライアントデバイス40への送信のためにセグメントのストリームをネットワークインターフェース72に導く。セグメントのストリームは、表現68のうちの1つなどの表現に対応し得る。さらに、カプセル化ユニット30は、サーバデバイス60にセグメント内に含まれるMDEに対する送信時間要件を表すデータを提供し得、サーバデバイス60はまた、最終的に、送信時間要件をネットワークインターフェース72に導く。たとえば、送信時間要件は、マニフェストファイル66内で指定され得る。送信時間要件は、一般に、MDEがクライアントデバイス40に配信されるべき最早および/または最遅の時間を示す。したがって、ネットワークインターフェース72は、送信時間要件に従ってクライアントデバイス40にMDE(たとえば、セグメントまたはセグメントのバイト範囲)を送信し得る。たとえば、ネットワークインターフェース72は、クライアントデバイス40においてMDEが、最早の送信時間より早く、および/または最遅の送信時間より遅く到達することがないように、MDEを配信し得る。
図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に送る。
図1の例のいくつかの要素は、本開示の技法を実行するように構成され得る。たとえば、ネットワークインターフェース72および/または要求処理ユニット70は、本開示の技法を実行するために独立してまたは連携して動作するように構成され得る。
図2は、図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット52は、eMBMSミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。
この例では、eMBMSミドルウェアユニット100は、eMBMS受信ユニット106と、キャッシュ104と、ローカルサーバユニット102とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、T. Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月(http://tools.ietf.org/html/rfc6726において入手可能)に記載された単方向伝送によるファイル配信(FLUTE)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、たとえば、BM-SCとして機能し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
eMBMSミドルウェアユニット100がファイルに関するデータを受信すると、eMBMSミドルウェアユニットは受信したデータをキャッシュ104内に記憶することができる。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体など、コンピュータ可読記憶媒体を含んでもよい。
ローカルサーバユニット102は、DASHクライアント110に関するサーバとして機能してもよい。たとえば、ローカルサーバユニット102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に提供してもよい。ローカルサーバユニット102は、MPDファイル内、ならびにセグメントが取り出され得るハイパーリンク内のセグメントに関する利用可能時間を通知してもよい。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GET要求または部分GET要求を使用して、ローカルサーバユニット102にセグメントを要求してもよい。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を作成し、その要求をローカルサーバユニット102にサブミットしてもよい。ローカルサーバユニット102は、キャッシュ104から要求されたデータを取り出し、そのような要求に応答して、そのデータをDASHクライアント110に与えてもよい。
図3は、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数の表現124A〜124N(表現124)とを含む。表現124Aは、任意のヘッダデータ126とセグメント128A〜128N(セグメント128)とを含む一方、表現124Nは、任意のヘッダデータ130とセグメント132A〜132N(セグメント132)とを含む。文字Nが、便宜的に、表現124の各々内の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現124の間に、異なる数の動画フラグメントが存在し得る。
MPD122は、表現124とは別個のデータ構造を含み得る。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124は、図2の表現68に対応する場合がある。一般に、MPD122は、コーディング特性およびレンダリングの特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現124の特性を一般に表す、データを含み得る。
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)もしくはURI、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在する場合、セグメント132の同様の特性を記述することができる。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
セグメント128、132は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。MPD122のデータは、図3の例には示されていないが、そのような特性は、MPD122のデータによって記述され得る。MPD122は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント128、132の各々は、固有のユニフォームリソースロケータ(URL)またはURIと関連付けられ得る。したがって、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント128または132を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント128または132の特定のバイト範囲を取り出すことができる。
図4は、図3のセグメント128、132のうちの1つのような表現のセグメントに対応し得る、例示的なビデオファイル150の要素を示すブロック図である。図4の例はビデオファイルを示すが、オーディオファイルまたは他のファイルが、ビデオファイル150のデータと同様のデータを含み得ることを理解されたい。セグメント128、132の各々は、図4の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図4の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、動画(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と動画フラグメント(MOOF)ボックス164と、動画フラグメントランダムアクセス(MFRA)ボックス166とを含む。図4は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従ってビデオファイル150のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、時限のテキストデータなど)を含み得る。
ファイルタイプ(FTYP)ボックス152は一般に、ビデオファイル150のファイルタイプを表す。ファイルタイプボックス152は、ビデオファイル150の最良の使用法を表す仕様を特定するデータを含んでもよい。ファイルタイプボックス152は、代替的には、MOOVボックス154、ムービーフラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル150のセグメントタイプを定義し得る。以下でより詳細に論じる図7は、MPD更新ボックスに関する追加の情報を提供する。
MOOVボックス154は、図4の例では、動画ヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数の動画延長(MVEX)ボックス160とを含む。一般に、MVHDボックス156は、ビデオファイル150の一般的な特性を表してもよい。たとえば、MVHDボックス156は、ビデオファイル150がいつ最初に作成されたかを表すデータ、ビデオファイル150がいつ最後に修正されたかを表すデータ、ビデオファイル150のタイムスケールを表すデータ、ビデオファイル150の再生の長さを表すデータ、または、ビデオファイル150を全般的に表す他のデータを含んでもよい。
TRAKボックス158は、ビデオファイル150のトラックのデータを含んでもよい。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を記述する、トラックヘッダ(TKHD)ボックスを含んでもよい。いくつかの例では、TRAKボックス158は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは、TRAKボックス158のデータおよび/またはsidxボックス162のデータによって参照され得る動画フラグメント164内に含まれ得る。
いくつかの例では、ビデオファイル150は、2つ以上のトラックを含み得る。したがって、MOOVボックス154は、ビデオファイル150中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を記述する場合がある。たとえば、TRAKボックス158は、対応するトラックの時間情報および/または空間情報を表す場合がある。MOOVボックス154のTRAKボックス158と同様のTRAKボックスは、カプセル化ユニット30(図3)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を記述してもよい。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングしてもよい。
MVEXボックス160は、たとえば、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150がムービーフラグメント164を含むことをシグナリングするために、対応するムービーフラグメント164の特性を記述し得る。ストリーミングビデオデータの文脈では、コード化ビデオピクチャは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。
MOOVボックス154は、ビデオファイル150の中のムービーフラグメント164の数に等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、ムービーフラグメント164の対応する1つの特性を記述し得る。たとえば、各MVEXボックスは、ムービーフラグメント164の対応する1つの持続時間を記述するムービー延長ヘッダ(MEHD)ボックスを含み得る。
上述したように、カプセル化ユニット30は、実際のコード化ビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶してもよい。ビデオサンプルは、一般に、アクセスユニットに対応してもよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を包含する、1つまたは複数のVCL NALユニットをコード化ピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、ムービーフラグメント164のうちの1つの中に含み得る。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、ムービーフラグメント164の1つに対応するMVEXボックス160の1つの中のムービーフラグメント164の1つの中に存在するものとして、シグナリングすることができる。
SIDXボックス162は、ビデオファイル150の任意の要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含むとは限らない。3GPPファイルフォーマットの例によれば、SIDXボックスは、セグメント(たとえば、ビデオファイル150内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「メディアデータボックスに対応する1つまたは複数の連続するムービーフラグメントボックスの自己完結型セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスが、そのムービーフラグメントボックスに続き、同じトラックについての情報を包含する次のムービーフラグメントボックスに先行する」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を包含する。参照されるサブセグメントは、プレゼンテーション時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照される材料におけるバイトの数のカウントを与える。」ことを示す。
SIDXボックス162は、一般に、ビデオファイル150内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。
ムービーフラグメント164は、1つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント164は、1つまたは複数のピクチャのグループ(GOP)を含んでよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上記で説明したように、ムービーフラグメント164は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント164の各々は、ムービーフラグメントヘッダボックス(MFHD、図4には示されない)を含み得る。MFHDボックスは、ムービーフラグメントのシーケンス番号などの、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント164は、ビデオファイル150の中でシーケンス番号の順番に含まれ得る。
MFRAボックス166は、ビデオファイル150のムービーフラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)の探索を実行するなど、トリックモードを実行することを支援し得る。MFRAボックス166は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正確に復号し表示するために、MFRAボックス166を必ずしも参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでよく、またはいくつかの例では、ビデオファイル150のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでよい。
いくつかの例では、ムービーフラグメント164は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SPAのビデオファイル150内の位置の指標を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
図5は、例示的なブロードキャストDASHインフラストラクチャシステム180を示すブロック図である。システム180は、システム管理ユニット198、GOP持続時間メディアバッファ182、メディアエンコーダ184、セグメンタ186、センダ188、スケジューラ190、フレーマ192、および励振器/増幅器194を含む。システム180、したがってシステム180のこれらの構成要素の各々は、図1のサーバデバイス60または図1のコンテンツ準備デバイス20などのソースデバイス内に含まれ得る。同じく、サーバデバイスおよびコンテンツ準備デバイスは、機能的に単一のデバイス内に統合され得る。
システム180の例では、GOP持続時間メディアバッファ182は、符号化されるべきメディアデータを受信してバッファリングする。メディアエンコーダ184(それは、実際に、図1のオーディオエンコーダ26および図1のビデオエンコーダ28など、複数のメディアエンコーダを表す)は、メディアデータ(たとえば、オーディオデータ、ビデオデータおよび/または時限テキストデータ)を符号化し、メディアデータをネットワーク抽象化層(NAL)ユニット内にカプセル化し、符号化されたメディアデータをNALユニット形式202でセグメンタ186に供給する。加えて、メディアエンコーダ184は、セグメンタ186に明示的MDE識別子200を表すデータを送信する。
セグメンタ186は、受信されたNALユニットをそれぞれのセグメントにカプセル化する。したがって、一般に、セグメンタ186は、セグメント内のMDEのロケーションを示す明示的情報を提供しない。しかしながら、効果的に、セグメンタ186は、センダ188にMDEを、セグメント内のバイト範囲の形式(206)で提供する。さらに、セグメンタ186はまた、MDEに対する送信時間要件204を決定し、センダ188に送信時間要件204を示すデータを送信する。
センダ188は、本開示の技法によるファイルベースプロトコル送信ユニットの一例を表す。この例では、センダ188は、ROUTEに従って受信されたセグメントのデータを送信する。他の例では、センダ188は、FLUTEまたは他のそのようなファイルベースプロトコルに従って受信されたセグメントのデータを送信し得る。本開示の技法によれば、センダ188は、スケジューラ190およびフレーマ192に、MDEデータ(たとえばIP、UDP、ROUTE、ALPなど、ネットワークベースデータユニット内にカプセル化された)210と送信時間要件208の両方を送信する。フレーマ192は、スケジューラ190によって決定されたスケジュールデータに従って励振器/増幅器194へのネットワークデータをカプセル化するネットワークフレームを形成し、ここでネットワークフレームは、物理層データ配信イベント(DDE)のベースバンド記述212をさらに含む。励振器/増幅器194は、たとえばATSC OTAブロードキャスト、イーサネット(登録商標)などを介するなど、物理ネットワーク層を介してデータをアクティブに送信する。
新型テレビジョンシステム委員会(ATSC)システムなどのブロードキャストシステムは、ROUTE内またはメディアアウェアバイト範囲を含む他のオブジェクト配信プロトコル内のMDEで実装されたメディアアウェアバイト範囲の使用をサポートし得る。システムに対する個々のMDEの識別(規定)は必要な挙動であり、それゆえ、システムはMDEを配信することができる。すなわち、MDEをパッケージ化して適切な時間ラベリングとともにスケジューラに送信するために、システムは、どのメディアアウェアバイト範囲がMDE(または同様のデータオブジェクト)を表すかを決定することができなければならない。
MDEの例示的な定義は、受信メディアコーデックにとって有意義なメディアのメディアアウェアバイト範囲である。コーデックのフレーム構造によって、MDEは、タームサンプルのISO BMFF使用における複数のサンプルである場合があり、またはない場合がある。複数のオーディオサンプルを含む高効率アドバンストオーディオコーディング(HE-AAC)(ISO/IECJTC1/SC29/WG11/N7016(2005年1月11日))におけるオーディオフレームは、それ自体、ISO BMFFの文脈における単一のサンプルである。HEVCの文脈におけるISO BMFFサンプルは、ビデオデータの単一のフレームであり得る。MDEは、単一のまたは複数のISO BMFFサンプルを含み得る。この可能性は、一連のビデオフレーム間の相互依存性によって存在する。最小のMDEが存在するが、便宜上または他の目的で、これらのアトミックMDE、すなわち最小のMDEは、より大きいMDEにアグリゲートされ得る。一般的な用語におけるMDEは重複しない。
MDEに最初に気づき得る図5のシステム180の要素は、メディアエンコーダ184、セグメンタ186およびセンダ188である。図5の機能エンティティは概念である。カスケードのこの論理構造は、システムを考察するのに便利なためであって、必要とされるものではない。この機能は、単一のエンティティに機能的に統合され得るか、または場合によっては異なる方法で追加のまたは代替のユニットに再分割され得る。MDE構成の論理ロケーションは、メディアエンコーダ184、セグメンタ186、またはセンダ188の入力セクションの範囲内にある。
MDEの範囲および規定は、取り扱われるメディアタイプに従って規定される。たとえば、オーディオは、個別のセグメントにパッケージ化され得るか、またはセグメント、すなわちISO BMFFファイル/オブジェクト内に多重化され得る。MPEG DASH(国際規格ISO/IEC 23009-1第2版、2014年5月1日、情報技術-動的適応ストリーミングオーバーHTTP(DASH)パート1:メディアプレゼンテーション記述およびセグメントフォーマット)は、たとえば、多重化セグメントと非多重化セグメントの両方を規定する。これは、構成の一態様にすぎない。上記の図5に示すように、様々な機能に構成を提供するシステム構成機能が存在し得る。
いくつかの潜在的に構成される態様の例は、以下を含む:
・DASHに対して
○セグメント持続時間
○セグメント構成、すなわち特定のメディアオブジェクト内に含まれるメディアタイプ
○セグメントタイプケイデンス、たとえば特定のメディアセグメントはストリームアクセスポイントを含むかまたは含まないか
・ビデオエンコーダに対して
○GoP持続時間(特定のコーデックネーミングはそのような構造に対して変化する)
○GoPタイプ、たとえば開か閉か
○フレームタイプケイデンス、たとえばI、B、B、P、B、B、P...
○フレームレート、解像度、プログレッシブ対インターレースなど
○パターンマッチを介するかまたはたとえば許容されたメディア構造からのMDE境界
・オーディオフレームはアトミックMDEおよびISO BMFFサンプルである
・個々のI(IDR)フレームはアトミックMDEである
・ビデオフレームのグループは図3に示すアトミックMDEである
○そのような決定はエンコーダ内で下されるかもしくは知られている場合があり、またはセグメンタによって決定される場合がある
・オーディオエンコーダに対して
○サンプルレート
○コーディングツールの選択
○特定のコーデックによるオーディオフレーム構造の詳細
これらの態様が静的構成である限り、関連するMDE規定は静的規定として提供され得、すなわちエンコーダの構成はセグメンタおよびまたはセンダに知られている。なぜならば、エンコーダの構成はセッティングの静的に構成されたセットであるからである。ビデオがビデオフレームタイプの単一の規定されたケイデンスを実行すると仮定すると、MDE境界はその構成によって画定され得る。特定のビデオケイデンスおよびそのアトミックMDEの一例として、以下の図7を参照されたい。この図は、ビデオフレームの表示順序を示すことに留意されたい。
図6は、例示的な高レベル構成のMDEを示す概念図である。
図7は、例示的なフレームタイプケイデンスおよび対応する規定されたMDEを示す概念図である。詳細には、図7は、ビデオフレーム250〜296を示す。様々なビデオフレームは、フレームがイントラ予測(I)、単方向インター予測(P)、または双方向インター予測(B)のいずれであるかを表すために、I、PまたはBのいずれかとして標示される。
図7に示すビデオフレームは、表示順序で示される。図が配信順序で示されるならば、フレームグルーピングは、ビデオエンコーダからのソースストリームの中、およびISO BMFFコンテナ、すなわちDASHに対するメディアセグメントの中の隣接するバイト範囲として現れることになる。
そのような規定されたケイデンスに対するMDE境界の識別は、たとえば、GoPの第1のN個のビデオフレームをMDE 1として規定し、次のM個のフレームをMDE 2として規定し、以下同様に規定する表を介して、またはフレームタイプの特定のケイデンス、たとえばコーデックシンタックス内で認識されるパターンマッチを介して達成され得る。表手法の使用は、フレームタイプのケイデンスがセグメントごとに静的であるならば、単純でかつ便利である。これは、MDE当たりおよびコーデック当たりに固定数のオーディオコーデックフレームが存在し得るオーディオメディアタイプに対して、潜在的に便利な方法である。(これはまた、些細なルールの一例である。)パターンまたはルールの明示的な記述を含み得るこれらの表は、XMLとして表現され得る。図7は、いくつかのアトミックMDEがアグリゲートされてより大きいMDEを形成することができることを示す。これは、ルールマッチもしくはパターンマッチ、またはそれらの組合せを介して決定され得る。これらの方法は、メディアエンコーダ内で実装され得、セグメンタおよびセンダ、たとえばROUTEまたはMMTへの明示的な記述として前方に送られ得る。
上記で簡単に述べたように、構成テーブルはルールに従って形成され得る。そのようなルールの論理は、MDE(メディアアウェアバイト範囲)識別機能の動作が適応的であることを可能にし得る。これは、たとえば、セグメント(ISO BMFFオブジェクト)が多重化される、すなわち複数のメディアタイプを含む場合に便利である。セグメンタのMDE識別機能は、たとえば、クローズドキャプション、オーディオ、およびビデオをパースすることができる。さらに、例示的なビデオフレームタイプのケイデンスは、適応的であり得る。
MDEの観点からビデオの適応的態様の例は、以下を含む:
・セグメントのシーケンス内の開いたおよび閉じたGoPを可能にするためのビデオフレームタイプケイデンス
・セグメントごとまたは周期ごとのビデオフレームカウントおよびタイプケイデンス
○たとえば、散在した24fpsのコマーシャルおよび30fpsのコンテンツ
○フレームレートにおけるそのような変化は、ビデオフレームタイプケイデンスの変化、および結果としてMDEケイデンスを引き起こす可能性がある。
セグメント内のMDE識別、すなわちバイト範囲アウェアプロトコルたとえばROUTEまたはMMTをサポートにおいて関連メディアコーデックに文脈上関係するメディアアウェアバイト範囲をサポートするための技法が説明される。
そのようなMDE規定、すなわちメディアコーデックアウェアバイト範囲をサポートするための技法の例は、以下を含み得る。
・以下のような特定のシーケンスを記述する表手法:
○ビデオフレームタイプ
○ビデオフレームタイプのシーケンス
○たとえば、ビデオフレームまたはオーディオフレームの数
○記述された構造の組合せ
○たとえば、ビデオフレームタイプの特定のシーケンスのパターンマッチ
○メディアエンコーダ、セグメンタまたはセンダ内で実装されるこれらの方法
・ルールベースのMDEベース検出
○たとえば、HEVCコーデックの特定の構成は、以下のフレームタイプシーケンスのこれらの論理構造を可能にし得る:
・フレームシーケンス(MDE)の開始は条件のこの第1のセットを満足する。
・フレームシーケンス(MDE)の終了は条件の第2のセットを満足する。
・フレームタイプのシーケンスは条件の第3のセットを満足する。
・説明されるパターンおよびルールの方法は組み合わされ得る、たとえば、
○このパターンが発見され
○次いで、このルールが適用されるべきである
・メディアエンコーダは、特定のMDE構造を有する規定された動作モードのライブラリを有し得る。
○メディアエンコーダは前記動作モードをセグメンタに送られた符号化されたメディアとリアルタイムで通信する
・たとえば、XMLまたはルールベースの論理およびパターンベースの論理のファイルの付録A参照
各MDEは、最早および/または最遅の送信時間で規定され得る。これはスケジューラのためになり、スケジューラのタスクは、配信スロット、たとえば物理層上のATSC 3.0内の特定のFECフレームにメディアを割り当てることである。これらの最早および最遅の属性は、以下のような異なる態様によって制約され得る。
・最早の送信時間:これは、文字通り、所与のMDE(またはセグメント)の第1のビットが放射され得る瞬間である。この最早の放射ビットは、すべての関連するカプセル化プロトコルを含む。
・最遅の送信時間:これは、文字通り、MDE(またはセグメント)の最後のビットが放射されなければならない最後の瞬間である。この最後のビットは、すべての関連するカプセル化プロトコルを含む。
最早の送信時間は、システム構成によって制約され得る。たとえば、物理層フレームケイデンスは、ATSC物理層時間(48b TAI秒、10b msec、または場合によっては他の数分の1秒)の全体の秒の境界で開始するフレームを有し得る。この物理層フレームケイデンスは、メディアセグメント持続時間に直接関連する場合があり、または関連しない場合がある。たとえば、プログラムの所与の期間は、置換広告である広告に先行して、すべての秒が終了する前にその全体が配信されなければならない。たとえば、置換広告をトレーリングすることは、少なくとも次のすべての秒が開始するまで配信を開始してはならない。期間の境界から離れた時間に対して、最早の送信時間は、たとえば先行するすべての秒の中にある。
最遅の送信時間は、標示されたMDE内に含まれる最後に復号されたメディアの復号時間に関係し得る。メディアセグメントレベル配信に適用されたラベリングは、名目上のDASH/セグメント利用可能性タイムラインによって決定され得る。最遅の送信時間は、セグメントに対する配信の最終期限を満足することと一致し得る。セグメントの最後のMDE(メディアアウェアバイト範囲)に対する最遅の送信時間要件は、完了したセグメントと同じであり得る。
図8は、システム時間の単純なビューを表す概念図である。すなわち、図8は、システム時間のトップレベルビューを示す。これは、セグメントレベルの再生またはバイト範囲ベースの再生のいずれかに対する場合である。MDE再生に対する1つの差は、静的受信機遅延はセグメント再生に対する遅延より著しく短いことである。局壁時計時間は、物理層およびサポートプロトコルを介して受信機に配信され得る。同期後の任意の瞬間における受信機壁時計は、最新の局壁時計時間から、支配的な送信機から受信機までの最新の信号飛行時間を減算したものである。
図9は、時間関係で構成された送信インフラストラクチャを表すシステム300を表すブロック図である。すなわち、図9は、時間遅延がシステム300の送信プロセスにどのように影響を及ぼし得るかについての概念表現を提供する。この例では、システム300は、GoP持続時間メディアバッファ306、メディアエンコーダ308、セグメンタ310、レート制御304、システム管理ユニット302、センダ312、スケジューラ314、および励振器/増幅器316を含む。
この例では、GoP持続時間メディアバッファ306は、符号化されるべき生のメディアデータを記憶する(すなわち、バッファリングする)。メディアエンコーダ308は、GoP持続時間メディアバッファ306から符号化されるべきメディアデータを取り出し、メディアデータを符号化し、符号化されたメディアデータをNALユニットの形態にカプセル化し、セグメンタ310にNALユニット320を配信する。符号化されたメディアデータはまた、たとえば図7に示すMDEを含むことを理解されたい。その上、上記で説明したように、MDEの各々は、最早の送信時間要件および/または最遅の送信時間要件などの送信時間要件を有し得る。
セグメンタ310は、メディアエンコーダ308からNALユニット320を受信し、それぞれのセグメント内で1つまたは複数のMDE(すなわち、NALユニットのうちの1つまたは複数)をカプセル化する。同じく、セグメントは、それぞれのURLに関連付けられた、独立して配信可能なファイルに対応し得、ここでURLは、対応するセグメントをそれぞれ一意に識別し得る。MDEは、セグメントのそれぞれのバイト範囲に対応し得る。加えて、セグメンタ310は、MDEの各々に対する送信時間要件を決定し、センダ312に送信時間要件322と(セグメントのバイト範囲の形態の)MDE324の両方を送信することができる。
センダ312は、ROUTEなどのファイルベース配信プロトコルに従って動作し得る。したがって、センダ312は、送信のためのスケジューラ314に対して、セグメント(たとえば、MDE)のそれぞれの部分を、パケットまたはフレームなど、それぞれのネットワークベースの配信ユニット328にカプセル化し得る。加えて、センダ312は、スケジューラ314が送信時間要件に従ってクライアントデバイス(図9に示されず)にネットワークベースの配信ユニットを配信し得るように、スケジューラ314に送信時間要件326を提供する。より詳細には、スケジューラ314は、物理層データ配信イベント(DDE)のベースバンド記述330を形成し、励振器/増幅器316に物理層DDEのベースバンド記述330を送信する。次いで、励振器/増幅器316は、たとえばクライアントデバイスに物理層におけるデータを送信する。
図9はまた、クライアントデバイスにメディアデータを送信するときにシステム300によってもたらされる様々な遅延を表す。たとえば、バッファリングされるメディアデータと送信のためにスケジュールされるメディアデータとの間の時間は、分析持続時間遅延332と呼ばれる。分析持続時間遅延は、特に、特定のサンプル334に対する単一のパス遅延を含み、単一のパス遅延は、図9に示すように、メディアエンコーダ308がサンプルを符号化するときと、NALユニットにおけるサンプルをカプセル化してセグメンタ310にNALユニットを提供するときとの間の時間である。その上、送信のためのデータがスケジュールされたときとデータが実際に送信されるときの間の時間は、送信機およびSTL遅延336と呼ばれる。
メディアデータに対する時間を規定することは、放射時間よりどれだけ前にシステム300の送信インフラストラクチャの様々な機能ブロックが動作していなければならないか、および受信からどれだけ後にメディアがメディアデコーダに手渡されることになるかを考慮することである。したがって、この議論は放射の前と受信の後に分割される。実際の放射時間はなぜ重要であるか。パーソナライズされた広告の挿入などのアプリケーションのためのソースストリームの間で潜在的な同期切換えを達成するために。メディアの送信を境界付ける実際の時間は制約される場合がある。受信機に配信される時間は、物理層のブートストラップ特性の放射時間に同期される。特定の期間が物理層上に存在する時間スパンは、把握されて制御されなければならない。MDEまたはメディアセグメントは、放射を許容される時間の範囲で標示され、それゆえ、実際の放出の前のすべてのプロセスは、一般的に、特定のブロックまたは機能に関連する一定の遅延によって時間的にオフセットされる。図9は、送信インフラストラクチャ内の時間領域の妥当な構成を示す。この区画は要件ではなく、それは概念的な観点から便利であるにすぎない。以下は、いくつかの可能な時間領域およびそれらの妥当な持続時間の記述である。
送信機およびスタジオ送信機リンク(STL)遅延336:これらのブロックにわたる規定された遅延は十分に長く、STLへの配信を開始しようとしている所与の物理層フレームは、この期間が経過したときに送信機による出力を開始し得る。この遅延は、名目上、少なくとも物理層フレーム遅延、インターリーバ持続時間、およびSFN配信網内の最長送信遅延を含む。たとえば、サブフレーム上でこの遅延をより短く実行することが考慮され得る。サブフレームを潜在的にサポートすることは、スタジオ送信機リンクのスタジオ上に増加したピークレートを生じる場合があり、すなわち、スタジオ送信機リンクは、少なくともサブフレーム持続時間の間、物理層の最大許容スループットを持続しなければならない。フルフレーム実装に対する制約は、フルフレームベースで測定されたピーク許容レート割り振りであり、それはサブフレーム当たりにより低くなり得るが、それはすべてのアクティブPLPが同じ能力であるならば同じであり得る。
分析持続時間遅延332:スケジューラ314のタスクの1つは、その規定された時間の最終期限を満足し、現在の物理層PLP規定当たりの能力制約を満足するように、物理層にメディアを割り当てることである。これを達成するために、スケジューラ314は、メディアに値する物理層フレームの最長持続時間を少なくとも分析すべきである。スケジューラ314が、経過した物理層フレーム時間当たりに符号化されたメディアの少なくとも1つの物理層フレーム時間を正常にスケジュールしない場合、スケジューラ314は最終的に失敗する可能性がある。これは累積的タスクである。メディア時間のその持続時間より小さい物理層フレームは、より多いメディア時間を表す物理層フレームでオフセットされ得る。
物理層フレームの持続時間は、最長のメディアセグメントまたはGoP持続時間の持続時間より短い場合がある。そのような場合、限界の境界は、少なくとも最長のメディアセグメント持続時間またはGoP持続時間に関係し、GoPは複数のメディアセグメントからなる。スケジューラ314は、最長持続時間メディアセグメント/GoPが正常にスケジュールされることを確実にし得る。スケジューラ314は、さらに、メディア秒当たりに、符号化されたメディアセグメント/GoPの少なくとも1つの秒を生成し得る。本明細書で説明するように、分析持続時間遅延332は一定ではない。なぜならば、スケジューラ314は、実際の放射時間内に最遅の放射時間-最早の放射時間の柔軟性を有するからである。
単一のパス遅延334:入力メディアがメディアエンコーダ308およびセグメンタ310上で直接ストリーミングされるならば、得られた第1のセグメントにおいて説明したように、GoPの第1のフレームの入力から第1の復号されたフレームの復号時間までの所与の構成に対して静的な復号遅延が存在することになる。これは概念的構成である。
メディアエンコーダ308(それは複数のエンコーダを表し得る)は、メディアセグメント時間当たりに符号化されたコンテンツの2つ以上のメディア時間を作成し得る可能性が非常に高い場合があり得る。実際の制約は、符号化方式が利用する「パス」の数によって規定される可能性がある。この文脈では、「パス」は、メディア符号化の一例である。メディアエンコーダ308が1つの符号化パス上ですべてのターゲットを満足することができるならば、要件は、経過したメディアセグメント時間当たりメディアの少なくとも1つのメディアセグメント持続時間である。第1のパス上で所望のデータサイズを得ることはかなり困難であり、それゆえ、スケジューラは、パスを2つのパス符号化に制限することを試みることができる。2パス符号化では、第1のパスは、符号化されるべきメディアデータの複雑さに対するキャリブレーションを提供し、第2のパスは、物理層の能力を満足するために第1のパスの間に行われた決定を調整するために使用され得る。最初の符号化パスが最終の所望の/必要なデータサイズと大幅に異なるデータサイズを生じた場合、データレートに対して第3のパスまたは他の調整が実行され得る。スケジューラは、すべてのカプセル化を含む物理層内で配信されるべき実際のデータサイズで動作しなければならないことに留意されたい。
メディアはリアルタイムでメディアエンコーダ308にストリーミングしていると仮定すると、これは複数パス符号化方式であり、潜在的に、メディアエンコーダの前方にリアルタイムストリーミングメディアをキャプチャするために必要なフルGoP遅延が存在する。受信機において符号化されたメディアが与えられる復号時間は、インフラストラクチャおよび受信機のすべての遅延を考慮しなければならない。これらはメディアセグメント再生に基づくことが予想される。MDE時間は、セグメントレベルの再生に対して発生したものに対して、MDE RAPスタートアップポイントから計算され得る。
図10は、千鳥形RAPロケーションを有するGOPにつき複数のセグメントを示す概念図である。図10に示す千鳥形RAPセグメント時間(GoPにつき複数の分析持続時間)は、メディアのスケジューリング前の最小の必要キャプチャ時間を低減し得、したがって全レイテンシを引き下げる。これは、いくぶん制限された直ちに多重化する利益を有する。なぜならば、図示のように、所与の物理層フレームに対するデータレートは、単一のRAPセグメントデータサイズによって影響を及ぼされるからである。メディアの時間ラベリングは、メディアによってキャプチャされる。
上記で説明したように、送信遅延、または放射に対する遅延は、以下のように表現され得る。
分析遅延持続時間-特定のサンプルに対する単一のパス遅延+送信機およびSTL遅延
(フレーム時間+インターリーバ深度+SFN分配)
図11は、メディア再生のための時間を復号する最小遅延を示す概念図である。すなわち、図11は、メディアセグメントおよびMDE再生に対するメディア復号時間に影響を及ぼす最小遅延を示す。メディアセグメントとMDE再生との間の1つの差は、セグメントレベルの遅延におけるMDE再生に対する開始時間は、最長のスタック遅延と推奨された表示遅延との和を考慮しなければならないが、一方で、MDEレベルの再生は、静的な個々のデバイスの実際の遅延と、ROUTEバッファフルネスが十分であることを確実にするための遅延との和であることである。全MDE遅延値は、セグメント時間より小さい場合がある。
端から端までの全セグメント復号遅延は、以下のように表現され得る。
分析遅延持続時間-特定のサンプルに対する単一のパス遅延+送信機およびSTL遅延
(フレーム時間+インターリーバ深度+SFN分配)+飛行時間+利用可能性開始時間に対する遅延+MPD@suggestedPresentationDelay+特定のサンプルに対するセグメント内遅延
端から端までの全MDE復号遅延は、以下のように表現され得る。
分析遅延持続時間-特定のサンプルに対する単一のパス遅延+送信機およびSTL遅延
(フレーム時間+インターリーバ深度+SFN分配)+飛行時間+ROUTEまたは同様のMMT受信機における遅延到達+ストリーミングバイト範囲ホールドオフ時間+特定のサンプルに対するセグメント内遅延
スケジューリングのための時間メタデータ方法のいくつかの詳細が、上記で説明された。スケジューリングのための時間メタデータ方法のさらなる詳細が、本明細書で説明される。MDEに対する時間メタデータの構造は、セグメント開始による最遅に必要な送信時間によって規定されるアンカーポイントに基づき得る。MDEに対する必要な最遅の時間は、セグメント開始後の各それぞれのMDEの第1の復号時間の順にリニアであり得る。最遅の時間は、セグメントの第1の復号されたMDEでもあるセグメントの第1の復号されたサンプルに対して、MDE内の現在復号されるべきサンプルの復号時間によって制約され得る。この種の方法は、復号時間においてリニアであり、方法は、最遅の送信時間メタデータを規定するための唯一の手法である。
たとえば、場合によっては、オーディオおよびキャプションなど、前倒しのメディア構成要素を考慮するための追加の態様がある。これらのメディア構成要素はビデオに対して小さいが、完全なプレゼンテーションはこれらのメディア構成要素がなくては再生できないので、ビデオRAPの前にそれらを送信することがおそらく最もシンプルであるが、後でMPDおよびISなどのメタデータオブジェクトを必要とする可能性がある。すなわち、一般に、方法は、すべての必要な小さいデータオブジェクトが最初に配信されることを確実にするために使用され得る。
図12は、任意の物理層同期および関連するメタデータを示す概念図である。T-RAPに対する物理層フレームの関係は、最早の送信に対して関連する態様である。たとえば、名目上の物理フレーム開始の前に移動するための自由さの最早の時間を示す図12の例を考慮する。これは、全層において開始メタデータの完全なシーケンスがない場合、チャネル変更時間に影響を及ぼし得る。
物理層の設計は、上記で説明したように、GoP境界に正確に同期させることができる場合があり、またはできない場合がある。同期位置の規定は、物理層のヌメロロジーによって他のロケーションに制約され得る。実行可能な方法は、GoP持続時間の近くのロケーションを使用することである。たとえば、次に利用可能な時間、すなわち、先行するトラフィックベアリング変換の名目上の境界の前後が近くであり得る。最小変換に対する時間のスケールは1msecのスケールの中にあり、一方、最大変換に対する時間のスケールは10msecの範囲内にあり得る。
前述のように、スケジューリング機能は、名目上、場合によってはメディアGoP持続時間またはセグメント持続時間に関係する固定ブロックの時間を考慮し得る。より効率的なGoP持続時間方式に対して、すべてのメディアがスケジューリングされ、いくつかの有意な能力が、次の分析間隔(N+1)による潜在的使用のために(N)において利用可能なまま残され得る。そのような条件では、スケジューラは、次の分析間隔(N+1)からのメディアによって(N)においてこの能力を満たすことを試みることができる。これは、最早のパラメータを介してより早い間隔の送信を可能にする時間メタデータによって可能にされ得る。先行する間隔の満たされた部分が知られると、物理層構成要素は、疑似固定の周期的フレーミング、たとえばATSC 3.0のブートストラップおよびプリアンブルで可能であるより早く、メディアサービスの獲得を可能にする目的で提供される任意のフレーム同期要素を挿入し得る。
図13は、メディアデータの複数の層に対するサービス獲得を可能にするために潜在的なシステムイベントに対応するステップのシーケンスを含む方法の一例を示す。すなわち、図13は、獲得イベントの例示的なシーケンスを示すフローチャートである。図13の方法は、図1のコンテンツ準備デバイス20およびソースデバイス60、図5のシステム180、または図9のシステム300など、本明細書に示す様々なデバイスおよびシステムによって実行され得る。例および説明として、図13の方法は、図5のシステム180に関して説明される。
システム180は、リニアまたはアプリケーションベースリニアサービスの開始を可能にするデータのシーケンスを配信する(350)。図13は、受信機におけるイベントの一般的なシーケンス、ならびに関連するメタデータ、他のオブジェクト、およびサービス受信の一般的な開始に関連するメディアファイルのシステム(180)配信の順序を示す。サービスのこの開始は、一般的に、チャネル数エントリ、チャネルアップ/ダウンキーエントリ、またはサービスのガイド選択によって開始される(350)。物理層の獲得は、ブートストラップまたはシステム同期パターンの受信によって開始される(352)。物理層に関連するシステムメタデータおよび追加のシステムメタデータの獲得は、プリアンブルまたは同様の物理層記述メタデータの受信を介して達成される(354)。所望のPLP、または波形の中の他の物理層パケットストリームのロケーションが識別されると、ALPを含む所望のパケットストリームが受信され、他の同様のカプセル化プロトコルは、パケットストリームID(PLP ID)の、含まれるIPまたは他の同様のパケットストリームIDもしくはアドレスへのマップ(相互参照)を含む(356)。プリアンブルまたは同様のもの(354)は、システム時間、サービス構成(SLT)、可能なアラート情報(AEAT)など、サービスの詳細を識別するシステムメタデータ(LLS)の存在を識別するフラグを含む(358)。LLS(358)において利用可能にされたSLTは、SLSにおけるサービスごとの詳細のロケーションを含む(360)。サービスを搬送するPLPはまた、テレビジョンサービスがブラウザベースインターフェース内で動作することを可能にし得るランタイムアプリケーションを含み得るアプリケーションを含み得る(362)。存在する場合、アプリケーションは、サービス開始の前または後に開始し得る。関連するデータ受信によって駆動されるこれらのステップが完了すると、メディア再生は、IS(364)および関連するメディアセグメント(366)の受信および復号から開始され得る。次いで、リニアまたはアプリケーションベースリニアサービスが始まり得る(368)。
MDEの端から端までの復号遅延は、セグメントレベルの復号より早い静的な時間である。この静的オフセットは、MPD内のメタデータの存在、またはMDEのMPD再生を可能にするためにメタデータの値を変更するMPDのリライトを介して達成され得る。オフセットの値は、第1のRAPがセグメントレベルから再生する時間に関連するMDEを介して第1のRAP再生から決定され得る。
MDEのスケジューリングに関連する特徴は、以下を含み得る。
・獲得時間を最小化するためのメディアタイプおよびメタデータの時間的構成。
○完全な配信を確実にするため、および多くのより小さいスケジュールされたオブジェクトを介して他のメディアとのインターリーブを試みることに関連する単純化として、より早い最遅の時間をより小さいメディアデータタイプに提供すること。この方法は、スケジューリングにおいてより大きい柔軟性、すなわちタイトな要件を有する多くのより小さいオブジェクトの代わりに、より多くの時間自由度を有する少数のより大きいオブジェクトをもたらす。増加したスケジューリング柔軟性は、一般に、総合効率に関して優れた結果をもたらす。
○よりロバストな性能がオーディオおよび本質的メタデータに対して望まれるならば、これらは、よりロバストな物理層パイプ内で一緒にスケジュールされ得る。
○メディアタイプの特定のインターリーブが共通の配信パイプ内で望まれる場合、多重化セグメントの使用が、実装するためにより単純であり得る。多重化メディアオブジェクトの内部のサンプルが、配信/復号順序で提供される。
・任意の物理層同期ロケーションによって高速獲得を維持する方法。
○名目上のロケーションの前にT-RAP配信を認識すること、すなわち名目上の物理層同期または関連する名目上の分析間隔をトレーリングすること。
○現在のスケジューリングサイクルがすべての配信要求を満足したこと、すなわち名目上のフレーム物理層期間に最遅ですべてのデータ要求が満足されたかどうか、に基づく適応。
・送信機が知られているすべての秒およびmsecで開始しなければならないというルールを利用してメディアGoP整合された分析間隔に物理層フレームの不正確な持続時間を適応させる手段。(同期モードは、常に、規定によって同じ秒およびミリ秒で実行することになる。)シンボルモードは、常に、ATSC時間の秒およびミリ秒から開始する経過時間の整数個のシンボルを維持することになる。(シンボルレートは、構成情報内で指定されるかまたは構成情報から決定されるあらかじめ規定された値の間で変更され得る。)
○分析間隔に対する名目上の位置をトレーリングする時間内に最も近い利用可能なシンボルロケーションにフレーム同期を割り当てること。
○名目上の分析間隔位置を導くシンボル内の最も近い利用可能なロケーションにフレーム同期を割り当てること。
○規定された分析間隔に対する物理層同期ベースの方式を基礎とする任意の他のルール。
○メディアGoPまたは同様の構造にリンクされた規定された分析間隔。
・GoPではなくセグメント持続時間に基づく分析間隔に基づく可能な低レイテンシ方法。
○RAPセグメントに基づくプライマリレート管理。
○失敗したPSNRまたは他の品質メトリックを補償するための非RAPセグメントをトレーリングすることの調整。
本開示は、一般に、ROUTEまたはMMTなどのファイル転送プロトコル内でMDE、メディアアウェアバイト範囲のロケーションを識別するために、単独でまたは任意の組合せで使用され得る様々な技法を説明する。これらの技法は、明示的な記述、およびルールによる有効パターンのマッチングまたは有効パターンの決定に基づき得る。これらの技法は組み合わされ得る。組合せの順序についての制限はない。同様に、本開示はまた、物理層同期および他の配信態様を編成するための技法の説明に対する背景として時間的態様を説明する。これらの技法は、メディアに関連する分析間隔に対して変動するかまたは不正確な同期ロケーションを有するシステム内で高速獲得を可能にし得る。
図14は、本開示の技法による別の例示的な方法を示すフローチャートである。図14の方法は、図5のセンダ188または図9のセンダ312など、ファイルベースプロトコル送信ユニットによって実行されるとして説明されている。説明の目的で、図14の方法は、図9のセンダ312に関して説明されているが、他のユニットがこの方法または同様の方法を実行するように構成され得ることを理解されたい。上記で説明したように、センダ312は、ファイルベースプロトコル送信ユニット、たとえばROUTEプロトコルもしくはFLUTEプロトコル、または他のファイルベース送信プロトコルに従ってデータを送信するユニットの一例を表す。
最初に、図14の例では、センダ312は、1つまたは複数のMDEを含む1つまたは複数のセグメントを受信する(380)。たとえば、MDEは、セグメントの配信可能なバイト範囲に対応し得る。次いで、センダ312はMDEロケーションを決定する(382)。一般に、センダ312は、MDEのロケーションをシグナリングする明示的な情報を受信しないが、代わりに、MDEのロケーションを決定するためにセグメントのデータを処理するための本開示の技法のうちの1つまたは複数を使用する。たとえば、センダ312は、上記で説明したように、パターンマッチング技法またはMDEがいかにして識別され得るかを規定するルールを実行し得る。したがって、センダ312は、セグメント内のMDEを識別するためにパターンマッチング技法、ルール、または他のそのような技法を使用し得る。
センダ312は、さらに、MDEに対する送信時間要件を決定し得る(384)。たとえば、センダ312は、セグメントに対応するマニフェストファイルのデータを分析し、マニフェストファイルから送信時間要件を決定し得る。マニフェストファイルは、たとえば、DASHによるMPDを含み得る。送信時間要件は、上記で説明したように、MDEのうちの1つまたは複数に対する最早の送信時間または最遅の送信時間のうちの一方または両方を表し得る。
最終的に、センダ312は、スケジューラ314および励振器/増幅器316などの物理層送信ユニットに、MDEとMDEに対する送信時間要件を表すデータとを提供し得る(386)。このようにして、スケジューラ314は、励振器/増幅器316が、最早の送信時間より早くなくかつ/または最遅の送信時間より遅くなく、MDEのデータを送信するように、送信時間要件に従ってMDEの送信をスケジュールし得る。
このようにして、図14の方法は、ソースデバイスのファイルベースプロトコル送信ユニットによって、セグメントを形成するソースデバイスのセグメンタからメディアデータのセグメントを含むデータのストリームを受信するステップであって、セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個別に取出し可能なファイルを含む、ステップと、メディアデータのストリーム内のメディア配信イベント(MDE)のロケーションを決定するステップであって、MDEがセグメントのうちの1つの少なくとも一部分に対するデータを含む、ステップと、MDEがクライアントデバイスに送信されるべき時間を表すMDEに対する1つまたは複数の送信時間要件を決定するステップと、物理層送信ユニットに対する利用可能な配信スロットに従ってソースデバイスの物理層送信ユニットにMDEと送信時間要件を表すデータとを提供するステップとを含む方法の一例を表す。
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得、またはコンピュータ可読媒体を介して送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号または搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品がコンピュータ可読媒体を含んでもよい。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlue-rayディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生する一方、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せはまた、コンピュータ可読媒体の範囲内に同じく含まれるものとする。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサによって実行されてよい。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明する機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に設けられてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素において全体的に実施されてよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、また1組のIC(たとえば、チップセット)を含む、様々なデバイスまたは装置において実施され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが説明されているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて結合されることがあり、または適切なソフトウェアおよび/もしくはファームウェアとともに、上で説明されたような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されることがある。
種々の例について説明した。これらの例および他の例は以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A 表現
68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 eMBMSミドルウェアユニット
102 ローカルサーバユニット
104 キャッシュ
106 eMBMS受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
122 メディアプレゼンテーション記述(MPD)
124A 表現
124N 表現
126 ヘッダデータ
128 セグメント
128A セグメント
128N セグメント
130 ヘッダデータ
132A セグメント
132N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 動画(MOOV)ボックス
156 動画ヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 動画延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 ムービーフラグメントボックス
166 動画フラグメントランダムアクセス(MFRA)ボックス
180 システム
182 ピクチャグループ(GOP)持続時間メディアバッファ
184 メディアエンコーダ
186 セグメンタ
188 センダ
190 スケジューラ
192 フレーマ
194 励振器/増幅器
196 レート制御
198 システム管理ユニット
200 明示的メディア配信イベント(MDE)識別子
202 ネットワークアブストラクションレイヤ(NAL)ユニット形式
204 送信時間要件
206 バイト範囲の形式
208 送信時間要件
210 MDEデータ
212 物理層データ配信イベント(DDE)のベースバンド記述
250 ビデオフレーム
252 ビデオフレーム
254 ビデオフレーム
256 ビデオフレーム
258 ビデオフレーム
260 ビデオフレーム
262 ビデオフレーム
264 ビデオフレーム
266 ビデオフレーム
268 ビデオフレーム
270 ビデオフレーム
272 ビデオフレーム
274 ビデオフレーム
276 ビデオフレーム
278 ビデオフレーム
280 ビデオフレーム
282 ビデオフレーム
284 ビデオフレーム
286 ビデオフレーム
288 ビデオフレーム
290 ビデオフレーム
292 ビデオフレーム
294 ビデオフレーム
296 ビデオフレーム
300 システム
302 システム管理ユニット
304 レート制御
306 GoP持続時間メディアバッファ
308 メディアエンコーダ
310 セグメンタ
312 センダ
314 スケジューラ
316 励振器/増幅器
320 NALユニット
322 送信時間要件
324 MDE
326 送信時間要件
328 ネットワークベースの配信ユニット
330 物理層DDEのベースバンド記述
332 分析持続時間遅延
334 サンプル
336 送信機およびスタジオ送信機リンク(STL)遅延

Claims (36)

  1. メディアデータを転送する方法であって、ソースデバイスのファイルベースプロトコル送信ユニットによって、
    セグメントを形成する前記ソースデバイスのセグメンタからメディアデータの前記セグメントを含むデータのストリームを受信するステップであって、前記セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個々に取出し可能なファイルを含む、ステップと、
    メディアデータの前記ストリーム内のメディア配信イベント(MDE)のロケーションを決定するステップであって、前記MDEが前記セグメントのうちの1つの少なくとも一部分に対するデータを含む、ステップと、
    前記MDEがクライアントデバイスに送信されるべき時間を表す前記MDEに対する1つまたは複数の送信時間要件を決定するステップと、
    物理層送信ユニットに対する利用可能な配信スロットに従って前記ソースデバイスの前記物理層送信ユニットに前記MDEと前記送信時間要件を表すデータとを提供するステップとを含む、方法。
  2. 前記MDEの前記ロケーションを決定するステップが、パターンマッチングを使用して前記MDEの前記ロケーションを決定するステップを含む、請求項1に記載の方法。
  3. 前記メディアデータがビデオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するステップが、
    前記ストリームのビデオフレームに対するケイデンスを規定するデータを取得するステップであって、前記規定されたケイデンスが、前記ビデオフレームのタイプが送信される順序を表し、前記ビデオフレームの前記タイプがイントラ予測されたビデオフレームおよびインター予測されたビデオフレームを含む、ステップと、
    前記MDEがそれぞれのビデオフレーム境界の間にあるように、前記規定されたケイデンスに基づいて前記MDEのうちの少なくとも一部を決定するステップとを含む、請求項2に記載の方法。
  4. 前記メディアデータがオーディオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するステップが、
    前記MDEの各々に含まれるべき前記ストリームの固定数のオーディオフレームを決定するステップと、
    前記ストリームから前記固定数のオーディオフレームを各々が含むように前記MDEのうちの少なくとも一部を決定するステップとを含む、請求項2に記載の方法。
  5. 前記MDEの前記ロケーションを決定するステップが、ルールを使用して前記MDEの前記ロケーションを決定するステップを含み、前記ルールが、
    オーディオフレーム、ビデオフレームおよび時限テキストインスタンスのうちの1つまたは複数を規定する1つまたは複数のルールを表すデータを受信するステップと、
    前記ルールに基づいて少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスのロケーションを決定するステップと、
    前記少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスの前記ロケーションに基づいて前記MDEを決定するステップとを含む、請求項1に記載の方法。
  6. 前記MDEの前記ロケーションを決定するステップが、前記物理層送信ユニットの物理層同期のためのタイミング情報に基づいて前記MDEの前記ロケーションを決定するステップを含む、請求項1に記載の方法。
  7. 前記MDEの前記ロケーションを決定するステップが、前記ストリーム内の再生可能なデータのロケーションを表すメタデータを含むヒントトラックを分析するステップを含む、請求項1に記載の方法。
  8. 前記送信時間要件を決定するステップが、前記ソースデバイスのシステム構成に基づいて前記MDEのうちの1つに対する最早の送信時間を決定するステップを含む、請求項1に記載の方法。
  9. 前記送信時間要件を決定するステップが、前記MDEのうちの1つに対する最遅の送信時間を、前記MDEのうちの前記1つの中にデータが含まれるセグメントのセグメント利用可能性時間に基づいて決定するステップを含み、前記方法が、データの前記ストリームのマニフェストファイルからセグメント利用可能性時間を決定するステップをさらに含む、請求項1に記載の方法。
  10. メディアデータを転送するためのソースデバイスであって、
    メディアデータのセグメントを含むデータのストリームを形成するように構成されたセグメンタであって、前記セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個々に取出し可能なファイルを含む、セグメンタと、
    メディア配信イベント(MDE)に対する送信時間要件に従ってクライアントデバイスに前記MDEを配信するように構成された物理層送信ユニットであって、前記MDEが前記セグメントのうちの1つの少なくとも一部分に対するデータを含み、前記物理層送信ユニットが配信されるべきデータを受信するために利用可能な配信スロットで構成される、物理層送信ユニットと、
    ファイルベースプロトコル送信ユニットとを備え、前記ファイルベースプロトコル送信ユニットが、
    前記セグメンタからメディアデータの前記セグメントを含むデータの前記ストリームを受信することと、
    メディアデータの前記ストリーム内の前記MDEのロケーションを決定することと、
    前記MDEが前記クライアントデバイスに送信されるべき時間を表す前記MDEに対する前記送信時間要件のうちの1つまたは複数を決定することと、
    前記物理層送信ユニットに対する前記利用可能な配信スロットに従って前記物理層送信ユニットに前記MDEと前記送信時間要件を表すデータとを提供することとを行うように構成される、ソースデバイス。
  11. 前記ファイルベースプロトコル送信ユニットが、パターンマッチングを使用して前記MDEの前記ロケーションを決定するように構成される、請求項10に記載のソースデバイス。
  12. 前記メディアデータがビデオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するために、前記ファイルベースプロトコル送信ユニットが、
    前記ストリームのビデオフレームに対するケイデンスを規定するデータを取得することであって、前記規定されたケイデンスが、前記ビデオフレームのタイプが送信される順序を表し、前記ビデオフレームの前記タイプがイントラ予測されたビデオフレームおよびインター予測されたビデオフレームを含む、取得することと、
    前記MDEがそれぞれのビデオフレーム境界の間にあるように、前記規定されたケイデンスに基づいて前記MDEのうちの少なくとも一部を決定することとを行うように構成される、請求項11に記載のソースデバイス。
  13. 前記メディアデータがオーディオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するために、前記ファイルベースプロトコル送信ユニットが、
    前記MDEの各々に含まれるべき前記ストリームの固定数のオーディオフレームを決定することと、
    前記ストリームから前記固定数のオーディオフレームを各々が含むように前記MDEのうちの少なくとも一部を決定することとを行うように構成される、請求項11に記載のソースデバイス。
  14. 前記ファイルベースプロトコル送信ユニットが前記MDEの前記ロケーションを決定するためのルールを使用するように構成され、前記ルールを使用するために、前記ファイルベースプロトコル送信ユニットが、
    オーディオフレーム、ビデオフレームおよび時限テキストインスタンスのうちの1つまたは複数を規定する1つまたは複数のルールを表すデータを受信することと、
    前記ルールに基づいて少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスのロケーションを決定することと、
    前記少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスの前記ロケーションに基づいて前記MDEを決定することとを行うように構成される、請求項10に記載のソースデバイス。
  15. 前記ファイルベースプロトコル送信ユニットが、前記物理層送信ユニットの物理層同期のためのタイミング情報に基づいて前記MDEの前記ロケーションを決定するように構成される、請求項10に記載のソースデバイス。
  16. 前記MDEの前記ロケーションを決定するために、前記ファイルベースプロトコル送信ユニットが、前記ストリーム内の再生可能なデータのロケーションを表すメタデータを含むヒントトラックを分析するように構成される、請求項10に記載のソースデバイス。
  17. 前記送信時間要件を決定するために、前記ファイルベースプロトコル送信ユニットが、前記ソースデバイスのシステム構成に基づいて前記MDEのうちの1つに対する最早の送信時間を決定するように構成される、請求項10に記載のソースデバイス。
  18. 前記送信時間要件を決定するために、前記ファイルベースプロトコル送信ユニットが、前記MDEのうちの1つに対する最遅の送信時間を、前記MDEのうちの前記1つの中にデータが含まれるセグメントのセグメント利用可能性時間に基づいて決定するように構成され、前記ファイルベースプロトコル送信ユニットが、データの前記ストリームのマニフェストファイルからセグメント利用可能性時間を決定するようにさらに構成される、請求項10に記載のソースデバイス。
  19. メディアデータを転送するためのソースデバイスであって、
    メディアデータのセグメントを含むデータのストリームを形成するように構成されたセグメンタであって、前記セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個々に取出し可能なファイルを含む、セグメンタと、
    メディア配信イベント(MDE)に対する送信時間要件に従ってクライアントデバイスに前記MDEを配信するように構成された物理層送信ユニットであって、前記MDEが前記セグメントのうちの1つの少なくとも一部分に対するデータを含み、前記物理層送信ユニットが配信されるべきデータを受信するために利用可能な配信スロットで構成される、物理層送信ユニットと、
    前記セグメンタからメディアデータのセグメントを含むデータのストリームを受信するための手段と、
    メディアデータの前記ストリーム内の前記MDEのロケーションを決定するための手段と、
    前記MDEが前記クライアントデバイスに送信されるべき時間を表す前記MDEに対する1つまたは複数の送信時間要件を決定するための手段と、
    前記物理層送信ユニットに対する利用可能な配信スロットに従って前記物理層送信ユニットに前記MDEと前記送信時間要件を表すデータとを提供するための手段とを含む、ソースデバイス。
  20. 前記MDEの前記ロケーションを決定するための前記手段が、パターンマッチングを使用して前記MDEの前記ロケーションを決定するための手段を含む、請求項19に記載のソースデバイス。
  21. 前記メディアデータがビデオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するための前記手段が、
    前記ストリームのビデオフレームに対するケイデンスを規定するデータを取得するための手段であって、前記規定されたケイデンスが、前記ビデオフレームのタイプが送信される順序を表し、前記ビデオフレームの前記タイプがイントラ予測されたビデオフレームおよびインター予測されたビデオフレームを含む、手段と、
    前記MDEがそれぞれのビデオフレーム境界の間にあるように、前記規定されたケイデンスに基づいて前記MDEのうちの少なくとも一部を決定するための手段とを含む、請求項20に記載のソースデバイス。
  22. 前記メディアデータがオーディオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを決定するための前記手段が、
    前記MDEの各々に含まれるべき前記ストリームの固定数のオーディオフレームを決定するための手段と、
    前記ストリームから前記固定数のオーディオフレームを各々が含むように前記MDEのうちの少なくとも一部を決定するための手段とを含む、請求項20に記載のソースデバイス。
  23. 前記MDEの前記ロケーションを決定するための前記手段が、ルールを使用して前記MDEの前記ロケーションを決定するための手段を含み、前記ルールが、
    オーディオフレーム、ビデオフレームおよび時限テキストインスタンスのうちの1つまたは複数を規定する1つまたは複数のルールを表すデータを受信するための手段と、
    前記ルールに基づいて少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスのロケーションを決定するための手段と、
    前記少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスの前記ロケーションに基づいて前記MDEを決定するための手段とを含む、請求項19に記載のソースデバイス。
  24. 前記MDEの前記ロケーションを決定するための前記手段が、前記物理層送信ユニットの物理層同期のためのタイミング情報に基づいて前記MDEの前記ロケーションを決定するための手段を含む、請求項19に記載のソースデバイス。
  25. 前記MDEの前記ロケーションを決定するための前記手段が、前記ストリーム内の再生可能なデータのロケーションを表すメタデータを含むヒントトラックを分析するための手段を含む、請求項19に記載のソースデバイス。
  26. 前記送信時間要件を決定するための前記手段が、前記ソースデバイスのシステム構成に基づいて前記MDEのうちの1つに対する最早の送信時間を決定するための手段を含む、請求項19に記載のソースデバイス。
  27. 前記送信時間要件を決定するための前記手段が、前記MDEのうちの1つに対する最遅の送信時間を、前記MDEのうちの前記1つの中にデータが含まれるセグメントのセグメント利用可能性時間に基づいて決定するための手段を含み、前記方法が、データの前記ストリームのマニフェストファイルからセグメント利用可能性時間を決定することをさらに含む、請求項19に記載のソースデバイス。
  28. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、実行されたとき、ソースデバイスのファイルベースプロトコル送信ユニットに、
    セグメントを形成する前記ソースデバイスのセグメンタからメディアデータの前記セグメントを含むデータのストリームを受信することであって、前記セグメントの各々が、固有のユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)に関連付けられたそれぞれの個々に取出し可能なファイルを含む、受信することと、
    メディアデータの前記ストリーム内のメディア配信イベント(MDE)のロケーションを決定することであって、前記MDEが前記セグメントのうちの1つの少なくとも一部分に対するデータを含む、決定することと、
    前記MDEがクライアントデバイスに送信されるべき時間を表す前記MDEに対する1つまたは複数の送信時間要件を決定することと、
    物理層送信ユニットに対する利用可能な配信スロットに従って前記ソースデバイスの前記物理層送信ユニットに前記MDEと前記送信時間要件を表すデータとを提供することとを行わせる、コンピュータ可読記憶媒体。
  29. 前記MDEの前記ロケーションをプロセッサに決定させる前記命令が、パターンマッチングを使用して前記MDEの前記ロケーションを前記プロセッサに決定させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
  30. 前記メディアデータがビデオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを前記プロセッサに決定させる前記命令が、
    前記ストリームのビデオフレームに対するケイデンスを規定するデータを取得することであって、前記規定されたケイデンスが、前記ビデオフレームのタイプが送信される順序を表し、前記ビデオフレームの前記タイプがイントラ予測されたビデオフレームおよびインター予測されたビデオフレームを含む、取得することと、
    前記MDEがそれぞれのビデオフレーム境界の間にあるように、前記規定されたケイデンスに基づいて前記MDEのうちの少なくとも一部を決定することとを前記プロセッサに行わせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
  31. 前記メディアデータがオーディオデータを含み、パターンマッチングを使用して前記MDEの前記ロケーションを前記プロセッサに決定させる前記命令が、
    前記MDEの各々に含まれるべき前記ストリームの固定数のオーディオフレームを決定することと、
    前記ストリームから前記固定数のオーディオフレームを各々が含むように前記MDEのうちの少なくとも一部を決定することとを前記プロセッサに行わせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
  32. 前記MDEの前記ロケーションを前記プロセッサに決定させる前記命令が、ルールを使用して前記MDEの前記ロケーションを前記プロセッサに決定させる命令を含み、前記ルールが、
    オーディオフレーム、ビデオフレームおよび時限テキストインスタンスのうちの1つまたは複数を規定する1つまたは複数のルールを表すデータを受信することと、
    前記ルールに基づいて少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスのロケーションを決定することと、
    前記少なくとも1つのオーディオフレーム、ビデオフレームまたは時限テキストインスタンスの前記ロケーションに基づいて前記MDEを決定することとを前記プロセッサに行わせる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
  33. 前記MDEの前記ロケーションを前記プロセッサに決定させる前記命令が、前記物理層送信ユニットの物理層同期に対するタイミング情報に基づいて前記MDEの前記ロケーションを前記プロセッサに決定させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
  34. 前記MDEの前記ロケーションを前記プロセッサに決定させる前記命令が、前記ストリーム内の再生データのロケーションを表すメタデータを含むヒントトラックを前記プロセッサに分析させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
  35. 前記送信時間要件を前記プロセッサに決定させる前記命令が、前記ソースデバイスのシステム構成に基づいて前記MDEのうちの1つに対する最早の送信時間を前記プロセッサに決定させる命令を含む、請求項28に記載のコンピュータ可読記憶媒体。
  36. 前記送信時間要件を前記プロセッサに決定させる前記命令が、前記MDEのうちの1つに対する最遅の送信時間を、データが前記MDEのうちの1つの中に含まれるセグメントのセグメント利用可能性時間に基づいて前記プロセッサに決定させる命令を含み、前記方法が、データの前記ストリームのマニフェストファイルからセグメント利用可能性時間を決定することをさらに含む、請求項28に記載のコンピュータ可読記憶媒体。
JP2018535028A 2016-01-08 2017-01-06 メディア転送のためのメディア配信イベントロケーションの決定 Active JP6893930B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201662276674P 2016-01-08 2016-01-08
US62/276,674 2016-01-08
US15/399,381 2017-01-05
US15/399,381 US10666961B2 (en) 2016-01-08 2017-01-05 Determining media delivery event locations for media transport
PCT/US2017/012551 WO2017120482A1 (en) 2016-01-08 2017-01-06 Determining media delivery event locations for media transport

Publications (3)

Publication Number Publication Date
JP2019506059A true JP2019506059A (ja) 2019-02-28
JP2019506059A5 JP2019506059A5 (ja) 2020-02-06
JP6893930B2 JP6893930B2 (ja) 2021-06-23

Family

ID=57882176

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018535028A Active JP6893930B2 (ja) 2016-01-08 2017-01-06 メディア転送のためのメディア配信イベントロケーションの決定

Country Status (20)

Country Link
US (1) US10666961B2 (ja)
EP (1) EP3400712B1 (ja)
JP (1) JP6893930B2 (ja)
KR (1) KR20180101371A (ja)
CN (1) CN108432261B (ja)
AU (1) AU2017205187B2 (ja)
CA (1) CA3007318C (ja)
CL (1) CL2018001833A1 (ja)
CO (1) CO2018006980A2 (ja)
ES (1) ES2864645T3 (ja)
HK (1) HK1257973A1 (ja)
HU (1) HUE052430T2 (ja)
MX (1) MX2018008372A (ja)
MY (1) MY192795A (ja)
NZ (1) NZ743019A (ja)
RU (1) RU2718170C2 (ja)
SA (1) SA518391872B1 (ja)
SG (1) SG11201804448QA (ja)
TW (1) TWI740878B (ja)
WO (1) WO2017120482A1 (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10129358B2 (en) * 2016-01-15 2018-11-13 Verizon Digital Media Services Inc. Partitioned serialized caching and delivery of large files
WO2017152178A1 (en) * 2016-03-04 2017-09-08 Bladelogic, Inc. Provisioning of containers for virtualized applications
WO2018003540A1 (ja) * 2016-06-30 2018-01-04 ソニーセミコンダクタソリューションズ株式会社 受信装置、送信装置、及び、データ処理方法
EP3490266B1 (en) * 2016-07-20 2022-09-21 Sony Group Corporation Receiving device and data processing method
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US11412312B2 (en) * 2016-09-28 2022-08-09 Idomoo Ltd System and method for generating customizable encapsulated media files
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
US10904313B2 (en) * 2017-06-20 2021-01-26 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses, methods, computer programs, and computer program products for live uplink adaptive streaming
US11146608B2 (en) * 2017-07-20 2021-10-12 Disney Enterprises, Inc. Frame-accurate video seeking via web browsers
US10750220B2 (en) * 2018-04-06 2020-08-18 Enensys Technologies Method for generating a STL stream, local adapter and corresponding computer program
CN108737845B (zh) * 2018-05-22 2019-09-10 北京百度网讯科技有限公司 直播处理方法、装置、设备以及存储介质
US10652849B2 (en) * 2018-07-16 2020-05-12 Sinclair Broadcast Group, Inc. Using broadcast physical layer for one-way time transfer of universal coordinated time to receivers
CN109471736A (zh) * 2018-09-14 2019-03-15 叮联信息技术有限公司 事件信息不间断随机传递及实时共享方法
CN115460184A (zh) 2018-09-17 2022-12-09 谷歌有限责任公司 用于传递无清单流媒体内容的方法、系统和介质
KR102124194B1 (ko) * 2018-12-19 2020-06-23 포디리플레이코리아 주식회사 영상분석을 위한 다채널 영상 전송 시스템 및 이의 제어 방법
US10700798B1 (en) * 2019-03-01 2020-06-30 GM Global Technology Operations LLC System and method to receive and deliver audio content
US12101526B2 (en) * 2019-12-11 2024-09-24 Saturn Licensing Llc Reducing latency during service change and improving robustness in advanced television systems committee (ATSC) 3.0 system
US11403804B2 (en) * 2020-01-03 2022-08-02 Nokia Technologies Oy Method for real time texture adaptation
CN113141514B (zh) * 2020-01-17 2022-07-22 北京达佳互联信息技术有限公司 媒体流传输方法、系统、装置、设备及存储介质
EP4162695A4 (en) * 2020-06-09 2023-08-02 Telefonaktiebolaget LM ERICSSON (PUBL) PROVISION OF SEMANTIC INFORMATION WITH ENCODED IMAGE DATA
RU203858U1 (ru) * 2020-08-05 2021-04-23 Общество с ограниченной ответственностью "Витрина ТВ" Устройство отображения и воспроизведения аудиовизуального контента
CN114598756B (zh) * 2020-12-01 2024-03-12 深圳Tcl数字技术有限公司 一种alp数据包的处理方法、存储介质及电子设备
US11882170B2 (en) * 2021-04-19 2024-01-23 Tencent America LLC Extended W3C media extensions for processing dash and CMAF inband events

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014517558A (ja) * 2011-04-05 2014-07-17 クアルコム，インコーポレイテッド ファイル配信方式を使用したｉｐブロードキャストストリーミングサービスの配信
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4392880B2 (ja) * 1998-06-29 2010-01-06 キヤノン株式会社 認証装置及びその制御方法並びに記憶媒体
US7146429B2 (en) * 2001-03-16 2006-12-05 The Aerospace Corporation Cooperative adaptive web caching routing and forwarding web content data requesting method
JP2007213772A (ja) * 2006-01-11 2007-08-23 Sony Corp 記録転送プログラム、記録転送装置及び記録転送方法
US20080037956A1 (en) 2006-06-30 2008-02-14 Scientific-Atlanta, Inc. Systems and Methods of Generating Encapsulated MPEG Program Streams
JP2008257592A (ja) * 2007-04-06 2008-10-23 Iwate Broadcasting Co Ltd クライアント端末、コンテンツ再生方法及びコンテンツ再生プログラム
JP4427567B2 (ja) * 2007-07-03 2010-03-10 株式会社東芝 無線通信装置及び無線通信方法
CA2709309C (en) 2007-12-13 2018-04-03 Highwinds Holdings, Inc. Content delivery network
CN101222509B (zh) * 2008-01-22 2011-10-26 中兴通讯股份有限公司 一种点对点网络的数据保护传输方法
CN101616009B (zh) * 2008-06-27 2011-07-06 中国移动通信集团公司 数据业务的传输方法及其设备
RU2481720C2 (ru) 2008-12-31 2013-05-10 Эпл Инк. Потоковая передача данных в режиме реального времени или в режиме, близком к реальному времени
US9036092B2 (en) * 2013-06-24 2015-05-19 Broadcom Corporation Video channel change system
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
US9032451B2 (en) 2011-09-01 2015-05-12 The Directv Group, Inc. Method and system for using a second screen device for interacting with a set top box to enhance a user experience
US9591361B2 (en) * 2011-09-07 2017-03-07 Qualcomm Incorporated Streaming of multimedia data from multiple sources
CN102769509B (zh) 2012-06-07 2015-10-21 华为技术有限公司 一种物理层信号的发送方法、装置及系统
GB2506911B (en) * 2012-10-12 2015-12-09 Canon Kk Method and correponding device for streaming video data
WO2014113486A1 (en) 2013-01-15 2014-07-24 Futurewei Technologies, Inc. Using quality information for adaptive streaming of media content
CN105393548A (zh) 2013-04-16 2016-03-09 Lg电子株式会社 广播发射设备、广播接收设备、操作广播发射设备的方法和操作广播接收设备的方法
CN104283849A (zh) * 2013-07-04 2015-01-14 深圳市天趣网络科技有限公司 弹窗数据推送、展示方法及装置、系统
CN105100015B (zh) 2014-05-16 2018-07-03 林琳 一种采集互联网访问数据的方法及装置
US20170055046A1 (en) 2014-05-21 2017-02-23 Lg Electronics Inc. Broadcast signal transmitting/receiving method and device
WO2016129973A1 (ko) 2015-02-15 2016-08-18 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014517558A (ja) * 2011-04-05 2014-07-17 クアルコム，インコーポレイテッド ファイル配信方式を使用したｉｐブロードキャストストリーミングサービスの配信
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"ATSC CANDIDATE STANDARD: SIGNALING, DELIVERY, SYNCHRONIZATION, AND ERROR PROTECTION (A/331) 以下備考", ADVANCED TELEVISION SYSTEMS COMMITTEE, JPN5019002026, 5 January 2016 (2016-01-05), pages 49 - 58, ISSN: 0004426613 *
"ＩＰＤＣによるライブストリーミング配信システムの開発と性能評価", 映像情報メディア学会技術報告, vol. 38, no. 35, JPN6021001004, 5 September 2014 (2014-09-05), pages 1 - 4, ISSN: 0004426614 *

Also Published As

Publication number Publication date
WO2017120482A1 (en) 2017-07-13
CO2018006980A2 (es) 2018-07-19
ES2864645T3 (es) 2021-10-14
AU2017205187A1 (en) 2018-06-21
CN108432261A (zh) 2018-08-21
AU2017205187B2 (en) 2020-09-10
US20170201761A1 (en) 2017-07-13
CN108432261B (zh) 2021-01-05
HK1257973A1 (zh) 2019-11-01
SG11201804448QA (en) 2018-07-30
EP3400712A1 (en) 2018-11-14
TW201725911A (zh) 2017-07-16
MY192795A (en) 2022-09-09
CL2018001833A1 (es) 2018-10-12
EP3400712B1 (en) 2020-12-23
MX2018008372A (es) 2018-09-21
RU2018124449A3 (ja) 2020-02-10
BR112018013750A2 (pt) 2018-12-11
HUE052430T2 (hu) 2021-04-28
SA518391872B1 (ar) 2022-01-24
NZ743019A (en) 2024-07-05
TWI740878B (zh) 2021-10-01
RU2718170C2 (ru) 2020-03-30
JP6893930B2 (ja) 2021-06-23
KR20180101371A (ko) 2018-09-12
CA3007318C (en) 2023-08-15
US10666961B2 (en) 2020-05-26
RU2018124449A (ru) 2020-02-10
CA3007318A1 (en) 2017-07-13

Similar Documents

Publication Publication Date Title
JP6893930B2 (ja) メディア転送のためのメディア配信イベントロケーションの決定
US20240364768A1 (en) Deadline signaling for streaming of media data
JP6807852B2 (ja) Ｌｃｔに基づくｄａｓｈフォーマットを有するファイルフォーマットベースのストリーミング
JP6612249B2 (ja) メディアデータをストリーミングするためのターゲット広告挿入
US10938872B2 (en) Processing interactivity events for streaming media data
JP2018524882A (ja) ブロードキャストのためのキャッシュされたセグメントのシグナリング
JP2018526845A (ja) ＤＡＳＨクライアントＱｏＥメトリックのミドルウェア配信
US20170331666A1 (en) Real-time control interface for broadcast object streaming
KR20160138044A (ko) 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입
BR112018013750B1 (pt) Método de transporte de dados de mídia por uma unidade de envio de protocolo baseado em arquivo de um dispositivo de origem, dispositivo de origem para transporte de dados de mídia e memória legível por computador

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191220

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20191220

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20201223

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210419

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: 20210510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210602

R150 Certificate of patent or registration of utility model

Ref document number: 6893930

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250