JP2018510545A - 低レイテンシビデオストリーミング - Google Patents

低レイテンシビデオストリーミング Download PDF

Info

Publication number
JP2018510545A
JP2018510545A JP2017541633A JP2017541633A JP2018510545A JP 2018510545 A JP2018510545 A JP 2018510545A JP 2017541633 A JP2017541633 A JP 2017541633A JP 2017541633 A JP2017541633 A JP 2017541633A JP 2018510545 A JP2018510545 A JP 2018510545A
Authority
JP
Japan
Prior art keywords
segment
representation
media
segments
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017541633A
Other languages
English (en)
Other versions
JP6655091B2 (ja
JP2018510545A5 (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 JP2018510545A publication Critical patent/JP2018510545A/ja
Publication of JP2018510545A5 publication Critical patent/JP2018510545A5/ja
Application granted granted Critical
Publication of JP6655091B2 publication Critical patent/JP6655091B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/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
    • 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/70—Media network packetisation
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • 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
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • 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/234327—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 by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26616—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for merging a unicast channel into a multicast channel, e.g. in a VOD application, when a client served by unicast channel catches up a multicast channel to save bandwidth
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

クライアントデバイスは、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととを行うように構成された1つまたは複数のプロセッサを含む。

Description

本出願は、各々の内容全体が参照によって本明細書に組み込まれている、2015年2月10日に出願した米国仮出願第62/114,423号、および2015年6月22日に出願した米国仮出願第62/183,054号の利益を主張するものである。
本開示は、符号化ビデオデータの記憶および転送に関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4、Part10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、ITU-T H.265/高効率ビデオコーディング(HEVC:High Efficiency Video Coding)により定義されている規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームまたはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
第3世代パートナシッププロジェクト、Technical Specification Group Services and System Aspects、Transparent end-to-end packet switched streaming service(PSS)、3GPPファイルフォーマット(3GP)(リリース12)V12.2.0、2013年12月 R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月
一般に、本開示は、低レイテンシビデオ(および/または、他のメディアデータ)ストリーミングを実現するために使用され得る技法について説明する。たとえば、メディアコンテンツは、互いの代替物として働く様々な表現を含み得る。本開示の技法によれば、1つの表現は周波数が比較的に高いストリーミングアクセスポイント(SAP)を含むことができる一方、もう1つの代替表現は周波数が比較的に低いSAPを含むことができる。マニフェストファイル(動的適応ストリーミングオーバーHTTP(DASH:Dynamic Adaptive Streaming over HTTP)のメディアプレゼンテーション記述(MPD)など)は、セグメントのタイプ(または、セグメントが準拠するフォーマット)、ならびにそのようなセグメントのロケーション(または、そのようなセグメントが対応する表現の中で生じる相対的周波数)をシグナリングすることができる。クライアントデバイスは、マニフェストファイルを使用して、周波数が比較的高いSAPを有する表現のうちの1つを決定し、次いで、異なるターゲット表現からSAPが利用可能になるまで、その表現からセグメントまたはセグメントの部分を取り出すことができる。ターゲット表現は、より少ない(すなわち、より低い周波数の)SAPを有するため、比較的より高い品質を有し得る。いくつかの例では、ユニキャストまたはブロードキャストなど、種々の取出しを機構によって種々の表現が利用可能であり得る。たとえば、初期表現はユニキャストを介して利用可能であり得る一方、ターゲット表現はブロードキャストを介して利用可能であり得る。
一例では、方法は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するステップと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するステップと、決定されたセグメントをその表現から取り出すステップとを含む。
別の例では、メディアデータを取り出すためのクライアントデバイスは、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととを行うように構成された1つまたは複数のプロセッサを含む。
別の例では、メディアデータを取り出すためのクライアントデバイスは、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するための手段であって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するための手段と、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するための手段と、決定されたセグメントをその表現から取り出すための手段とを含む。
別の例では、コンピュータ可読記憶媒体は、実行されると、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととをプロセッサに行わせる命令を記憶している。
別の例では、メディア情報をシグナリングする方法は、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するステップと、そのマニフェストファイルをクライアントデバイスに送るステップと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るステップとを含む。
別の例では、メディア情報をシグナリングするためのサーバデバイスは、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることと行うように構成された1つまたは複数のプロセッサを含む。
別の例では、メディア情報をシグナリングするためのサーバデバイスは、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するための手段であって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するための手段と、そのマニフェストファイルをクライアントデバイスに送るための手段と、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るための手段とを含む。
別の例では、コンピュータ可読記憶媒体は、実行されると、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることとをサーバデバイスのプロセッサに行わせる命令を記憶している。
1つまたは複数の例の詳細が、以下の添付の図面および説明で述べられる。他の特徴、目的、および利点は、説明、および図面、ならびに特許請求の範囲から明らかになるであろう。
ストリームに迅速に加わるための例示的な使用事例を示す概念図である。 様々なタイプのメディアセグメント同士の間の関係を示すベン図である。 表現およびISOベースのメディアファイルフォーマット(BMFF)ファイルの例示的な構造を示す概念図である。 ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 本開示の技法による、メディアプレゼンテーション記述の例示的なコンテンツを示す概念図である。 図5Aのセグメントのうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。 本開示の技法による、使用事例に関して提供される例示的なセグメントを示す概念図である。 本開示の技術による、スケーラブルHEVC(SHVC)との高速同調を含む使用事例を示す概念図である。 本開示の技術による、ストリームアクセスポイント(SAP)タイプ3との高速同調を含む例示的な使用事例を示す概念図である。 高速同調およびハイブリダイゼーションを含む例示的な使用事例を示す概念図である。 高速同調、ハイブリダイゼーション、およびオープンGOPを含む例示的な使用事例を示す概念図である。 オープンGOPとの高速同調およびハイブリダイゼーションを含む別の例示的な使用事例を示す概念図である。 高速同調および超低レイテンシを含む例示的な使用事例を示す概念図である。 高速同調および超低レイテンシを含む別の例示的な使用事例を示す概念図である。 本開示のいくつかの技法による、メディアコンテンツの表現のセグメントを取り出すための例示的な方法を示すフローチャートである。
一般に、本開示は、たとえば、ISOベースのメディアファイルフォーマット(ISOBMFF:ISO base media file format)および動的適応ストリーミングオーバーHTTP(DASH)に従ってフォーマットされたメディアコンテンツに基づく、低レイテンシビデオストリーミングのための技法について説明する。DASHは、たとえば、第3世代パートナシッププロジェクト、Technical Specification Group Services and System Aspects、Transparent end-to-end packet switched streaming service(PSS)、3GPPファイルフォーマット(3GP)(リリース12)V12.2.0、2013年12月において記述される。本開示は、同時に高効率ビデオコーディング構造を潜在的に有効化しながら、新しいDASHプロファイル(たとえば、アドバンストライブプロファイル)およびブロードキャストおよびマルチキャストにおける低減されたチャネル獲得およびチャネル変更回数を含む、低レイテンシビデオストリーミングを可能にし得るメディアセグメントのいくつかの新しいタイプに準拠し得るデータを定義およびシグナリングするための様々な方法について説明する。
ビデオコーディング規格は、ITU-T H.261と、ISO/IEC MPEG-1 Visualと、ITU-T H.262またはISO/IEC MPEG-2 Visualと、ITU-T H.263と、ISO/IEC MPEG-4 Visualと、そのスケーラブルビデオコーディング(SVC:Scalable Video Coding)およびマルチビュービデオコーディング(MVC:Multiview Video Coding)拡張を含むITU-T H.264またはISO/IEC MPEG-4 AVCと、そのスケーラブルコーディング拡張(すなわち、スケーラブル高効率ビデオコーディング、SHVC)およびマルチビュー拡張(すなわち、マルチビュー高効率ビデオコーディング、MV-HEVC)を含む、ITU-T H.265およびISO/IEC 23008-2としても知られている高効率ビデオコーディング(HEVC:High-Efficiency Video Coding)とを含む。
ランダムアクセスは、ビットストリーム内の第1のコード化ピクチャではない、コード化ピクチャから開始するビデオストリームの復号を指す。ビットストリームに対するランダムアクセスは、たとえば、ユーザが、いつでもプログラムに同調するために、異なるチャネル間を切り替えるために、ビデオの特定の部分にジャンプするために、または(ビットレート、フレームレート、空間分解度などの)ストリーム適合のために異なるビットストリームに切り替えるためになど、ブロードキャストおよびストリーミングなどの多くのビデオアプリケーションにおいて使用され得る。この特徴は、ランダムアクセスピクチャまたはランダムアクセスポイントを規則的な間隔で何回もビデオビットストリーム内に挿入することによって有効化にされ得る。
ビットストリームスプライシングは、2つ以上のビットストリームまたはその部分の連結を指す。たとえば、スプライスされたビットストリームを生成するために、第1のビットストリームを、第2のビットストリームによって、場合によっては、何らかの修正を用いて、ビットストリームのいずれか1つまたは両方に追加することができる。第2のビットストリーム内の第1のコード化ピクチャは、スプライシングポイントと呼ばれることもある。したがって、スプライスされたビットストリーム内のスプライシングポイントに続くピクチャは第2のビットストリームから発生し、スプライスされたビットストリーム内のスプライシングポイントに先行するピクチャは第1のビットストリームから発生する。
ビットストリームのスプライシングはビットストリームスプライサによって実行され得る。ビットストリームスプライサは、軽量であり、エンコーダよりもはるかに知的ではないことが多い。たとえば、ビットストリームスプライサは、エントロピー復号および符号化能力を備えていない場合がある。
ビットストリーム切替えは、適応ストリーミグ環境において使用され得る。切替え先ビットストリーム内で特定のピクチャにおいて実行されるビットストリーム切替え動作は、事実上、スプライシングポイントがビットストリームスイッチポイント、すなわち、切替え先ビットストリームからの第1のピクチャであるビットストリームスプライシング動作である。別個の表現は、それぞれのビットストリームと呼ばれる(または、それを提供する)場合もある。
ITU-T H.264/AVC(アドバンストビデオコーディング)または高効率ビデオコーディング(HEVC)において指定された瞬時復号リフレッシュ(IDR:Instantaneous decoding refresh)をランダムアクセスのために使用することができる。しかしながら、復号順序でIDRピクチャに続くピクチャは参照のために(ピクチャ間予測のために)IDRピクチャに先立って復号されたピクチャを使用することができないため、ランダムアクセスのためにIDRピクチャに依存するビットストリームは、かなり低いコーディング効率を有し得る。
コーディング効率を改善するために、クリーンランダムアクセス(CRA)ピクチャの概念がHEVCにおいて導入され、復号順序ではCRAピクチャに続くが、出力順序ではそれに先行するピクチャが、参照として、CRAピクチャの前に復号されたピクチャを使用することを可能にした。復号順序でCRAピクチャに続くが、出力順序ではCRAピクチャに先行するピクチャは、CRAピクチャに関連付けられたリーディングピクチャ(またはCRAピクチャのリーディングピクチャ)と呼ばれる。復号が現在のCRAピクチャの前にIDRピクチャまたはCRAピクチャから開始する場合、CRAピクチャのリーディングピクチャは正確に復号可能である。しかしながら、CRAピクチャからランダムアクセスが生じるとき、CRAピクチャのリーディングピクチャは復号可能でない場合がある。したがって、リーディングピクチャは、一般に、ランダムアクセス復号中に廃棄される。復号がどこで開始するかに応じて利用可能でない場合がある参照ピクチャからの誤り伝搬を防止するために、復号順序と出力順序の両方でCRAピクチャに続くすべてのピクチャは、参照として、復号順序または出力順序のいずれでもCRAピクチャに先行する(リーディングピクチャを含む)任意のピクチャを使用するべきでない。
CRAピクチャの導入後、CRAピクチャの概念に基づいて、切断リンクアクセス(BLA:broken link access)ピクチャの概念がHEVCにさらに導入された。BLAピクチャは、一般に、CRAピクチャの位置におけるビットストリームスプライシングから発生し、スプライスされたビットストリーム内で、スプライシングポイントCRAピクチャはBLAピクチャに変更される。
IDRピクチャ、CRAピクチャ、およびBLAピクチャは、集合的にランダムアクセスポイント(RAP)ピクチャと呼ばれる。IDRピクチャは、いわゆる、クローズドピクチャグループ(GOP:group of pictures)ベースのRAPに対応し、CRAピクチャおよびBLAピクチャは、通常、いわゆる、オープンピクチャグループ(GOP)ベースのRAPに対応する。
BLAピクチャとCRAピクチャとの間の1つの違いは次の通りである。CRAピクチャの場合、関連付けられたリーディングピクチャは、復号が復号順序でCRAピクチャの前にRAPピクチャから開始する場合、正確に復号可能であり、CRAピクチャからのランダムアクセスが生じるとき(すなわち、復号がCRAピクチャから開始するとき、または言い換えると、CRAピクチャがビットストリーム内の第1のピクチャであるとき)、正確に復号可能でない場合がある。BLAピクチャの場合、関連付けられたリーディングピクチャは、復号が復号順序でBLAピクチャの前にRAPピクチャから開始するときですら、すべての場合において復号可能でない場合がある。
ファイルフォーマット規格は、ISOベースのメディアファイルフォーマット(ISOBMFF, ISO/IEC 14496-12)と、MPEG-4ファイルフォーマット(ISO/IEC 14496-14)、3GPPファイルフォーマット(3GPP TS 26.244)、およびAVCファイルフォーマット(ISO/IEC 14496-15)を含めて、ISOBMFFから導出された他のメディアファイルフォーマットとを含む。
ISOBMFFは、AVCファイルフォーマットなど、多くのコーデックカプセル化フォーマット用の、ならびにMPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GP)、およびDVBファイルフォーマットなど、多くのマルチメディアコンテナフォーマット用の基礎として使用される。
オーディオおよびビデオなど、連続的なメディアに加えて、画像、ならびにメタデータなどの静的メディアをISOBMFFに準拠するファイル内に記憶することができる。ISOBMFFに従って構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、動的適応ストリーミングオーバーHTTP(DASH)のためのセグメント、ストリームされることになるコンテンツ用のコンテナおよびそのパケット化命令、ならびに受信されたリアルタイムメディアストリームの記録を含めて、多くの目的で使用され得る。
ボックスは、4文字のコード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ISOBMFF内のエレメンタリシンタックス構造である。ISOBMFFファイルは、ボックスのシーケンスからなり、ボックスは他のボックスを包含し得る。ムービーボックス(「moov」)は、各々がトラックとしてファイル内に表される、ファイル内に存在する連続的なメディアストリーム用のメタデータを包含する。トラック用のメタデータはトラックボックス(「track」)内に密閉される一方、トラックのメディアコンテンツはメディアデータボックス(「mdat」)内にまたは別個のファイル内に直接的にのいずれかで密閉される。トラック用のメディアコンテンツは、オーディオアクセスユニットまたはビデオアクセスユニットなど、サンプルのシーケンスからなる。
ISOBMFFは次のタイプのトラックを規定する:すなわち、エレメンタリメディアストリームを包含するメディアトラック、メディア送信命令を含むか、または受信されたパケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備えた時限メタデータトラックである。
当初は記憶のために設計されたが、ISOBMFFは、ストリーミングのために、たとえば、プログレッシブダウンロードまたはDASHのために、非常に貴重であることが証明されている。ストリーミングのために、ISOBMFFにおいて定義されるムービーフラグメントを使用することができる。
各トラック用のメタデータは、各々が、トラックにおいて使用されるコーディングフォーマットまたはカプセル化フォーマットと、そのフォーマットを処理するために必要とされる初期化データとを提供するサンプル記述エントリのリストを含む。各サンプルは、トラックのサンプル記述エントリのうちの1つに関連付けられる。
ISOBMFFは、様々な機構を用いてサンプル固有のメタデータの規定を有効化にする。サンプルテーブルボックス(「stbl」)内の固有のボックスは共通のニーズに応じるために規格化されている。たとえば、トラックのランダムアクセスサンプルを列挙するために、シンタックスサンプルボックス(「stss」)が使用される。サンプルグルーピング機構は、4文字グルーピングタイプによるサンプルのファイル内でサンプルグループ記述エントリとして指定された同じ属性を共有するサンプルのグループへのマッピングを有効化にする。いくつかのグルーピングタイプがISOBMFFにおいて指定されている。
本開示の技法は、ISOBMFF、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンストビデオコーディング(AVC)ファイルフォーマット、第3世代パートナシッププロジェクト(3GPP)ファイルフォーマット、および/もしくはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
ISO/IEC23001-7は、ISOベースのメディアファイルフォーマットのための共通の暗号化を定義する。この規格の場合、暗号化はエレメンタリストリームに基づく。さらに、この規格は、AES-128のCTRモードおよびCBCモードを可能にする。ランダムアクセスポイントにおいてメディアを解読するために、保護方式固有情報ならびに初期化ベクトルを含めて、すべてのDRM関連情報が必要とされる。
ISO/IEC 23009-1において指定される動的適応ストリーミングオーバーHTTP(DASH)は、HTTP(適応)ストリーミングアプリケーションに関する規格である。これは主に、一般に、マニフェストファイルも呼ばれるメディアプレゼンテーション記述(MPD)のフォーマット、およびメディアセグメントフォーマットを指定する。MPDは、サーバ上で利用可能なメディアを記述し、DASHクライアントにそのDASHクライアントが関心をもつメディア時間にメディアバージョンを自律的にダウンロードさせる。
DASHベースのHTTPストリーミングのための例示的な手順は次のステップを含む。
1)クライアントはストリーミングコンテンツ、たとえば、ムービーのMPDを取得する。MPDは、ストリーミングコンテンツの様々な代替表現、たとえば、ビットレート、ビデオ解像度、フレームレート、オーディオ言語に関する情報、ならびにHTTPリソースのURL(初期化セグメントおよびメディアセグメント)を含む。
2)MPD内の情報、およびクライアントのローカル情報、たとえば、ネットワーク帯域幅、復号/ディスプレイ能力、およびユーザの選好に基づいて、クライアントは、所望の表現を一度に1つのセグメント(または、その一部)ずつ要求する。
3)クライアントがネットワーク帯域幅変化を検出したとき、クライアントは、理想的には、ランダムアクセスポイントから開始するセグメントから開始する、より良好に一致するビットレートを有する異なる表現のセグメントを要求する。
HTTPストリーミング「セッション」中に、過去の位置に戻ること、または将来の位置に進むことを求めるユーザ要求に応じて、クライアントは、所望の位置に近く、理想的には、ランダムアクセスポイントから開始する過去または将来のセグメントを要求する。ユーザは、コンテンツを早送りすることを要求することもでき、これは、イントラコード化ビデオピクチャだけ、またはビデオストリームの時間サブセットだけを復号するために十分なデータを要求することによって実現可能である。
最後のISOBMF仕様書は、DASHとともに使用するための6つのタイプのストリームアクセスポイント(SAP)を指定している。第1の2つのSAPタイプ(タイプ1および2)は、H.264/AVCおよびHEVCにおけるIDRピクチャに対応する。第3のSAP(タイプ3)は、オープンGOPランダムアクセスポイント、したがって、HEVCにおけるBLAピクチャまたはCRAピクチャに対応する。
HTTPストリーミングにおいて、たとえば、DASHに従って、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、ユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)と関連付けられたペイロードを取り出さずに、所与のURLまたはURNと関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを包含し得る。期間は、MPDにおいて期間要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性とavailableStartTime属性とを含み得る。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を包含し得る。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用され得る。
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられ得る。同じ適応セット内の表現は、一般に、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合には、グループ0からの1つの表現、または各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
表現は1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでもよく、または表現の各セグメントは自己初期化するものであってもよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照され得る。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
異なるタイプのメディアデータに関して実質的に同時に取り出すために異なる表現を選択することができる。たとえば、クライアントデバイスは、そこからセグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
従来のDASH技法において様々な問題が生じる。たとえば、低レイテンシライブサービスの配布など、低レイテンシビデオストリーミングサービスの場合、オリジンサーバ上で利用可能にされるように各セグメントを可能な限り迅速に生成することができることは重要である。言い換えれば、そのようなシナリオでは短いセグメントが必要である。現在、短いセグメントを作成するための2つのオプションが存在する。
1)ISOBMFFライブプロファイルの使用。これは、各セグメントは、タイプ1または2のSAPから開始しなければならないが、セグメントはすべて1つの適応セット内で同じ持続時間のものでなければならないことを意味する。言い換えれば、RAPを提供するために、IDRピクチャを使用しなければならず、SAPタイプ3に対応するオープンGOP RAPを使用することはできない。結果として、ビデオコーディング効率を損なわざるを得ない。
2)ISOBMFFメインプロファイルの使用。しかしながら、これは、スイッチポイント(SAPタイプ1または2)上で何のMPDベースのシグナリングも可能でなく、クライアントは、サンプルにどのようにアクセスするかを見出すためにそれらのセグメントをパースする必要があることを意味する。
さらに、セグメントオーバーローディング問題が生じ得る。すなわち、コアDASH仕様書では、セグメントは、整数のムービーフラグメントを含まなければならない配信ユニットである。一般性を失わずに、セグメントは単一のムービーフラグメントを包含すると仮定する。ムービーフラグメント自体は、復号順序で整数のサンプルを提供するという点でのみ制約を有する。
コアDASHでは、セグメントは、さらなる制限なしに、アドレス可能および配信可能なユニットを作成するために生成され得る。しかしながら、制限されたプロファイル(たとえば、ISOライブプロファイル)では、セグメントは同時に表現切替えを可能にするために使用され得る。後者はかなりの制限を加える。
各セグメントはクローズドGOPから開始しなければならない。
セグメントは1つの表現内のプレゼンテーション時間が重複してはならない。
これらの2つの制限は、特に、セグメントが比較的短い場合、コーディング効率を低減させる。
さらに、ブロードキャストアプリケーションの場合、配信ユニットへのランダムアクセスは重要である。セグメントの持続時間は、チャネル獲得およびチャネル変更に関連するランダムアクセス時間を決定する。ランダムアクセスの場合、より効率的なオープンGOPが十分であり、セグメントは、ある程度までプレゼンテーション時間重複すら有する場合があり、これはアクセスにおいてプレイアウト品質の低減(フレームの何らかのドロップ)をもたらし得るが、依然として、ストリームへの高速アクセスを可能にする。
本開示の技法は、下記で論じるように、セグメントの異なる機能的態様に対処し、セグメントを様々なクラスに区分することができる。
図1は、ストリームに迅速に加わるための例示的な使用事例を示す概念図である。この例では、いくつかのセグメントはブロードキャストを介して利用可能である一方、他のセグメントはユニキャストを介して利用可能である。具体的には、ラベル「8」および「9」と標示されたセグメントはブロードキャストを介して利用可能である一方、7A〜7D、8A〜8D、および9A〜9Dと標示されたセグメントはユニキャストを介して利用可能である。この使用事例では、クライアントデバイスは、ユニキャストを介してセグメント7Dおよび8A〜8Dを取り出し(ここで、セグメント8A〜8Dはブロードキャストを介して利用可能なセグメント8と同じメディアデータを含む)、次いで、ブロードキャストを介してセグメント9を取り出す。具体的には、クライアントデバイスは、ブロードキャストを介したセグメント8の送信中である同調時間2においてブロードキャストに同調する。したがって、クライアントデバイスは、ブロードキャストを介してセグメント8を受信することができず、代わりに、クライアントデバイスは、ブロードキャストを介してセグメント9を受信する前に、セグメント7Dおよび8A〜8Dを取り出す。したがって、クライアントデバイスは、セグメント8Dを取り出した後で、ブロードキャストからユニキャストに切り替える。したがって、メディアデータをプレイアウトするとき、クライアントデバイスは、(ユニキャストを介して受信された)セグメント7Dおよび8A〜8Dからメディアデータをプレイアウトし、次いで、(ブロードキャストを介して受信された)セグメント9からプレイアウトするように切り替える。
この使用事例は、ユニキャストとの「高速同調」を実証する。この場合、サービスプロバイダは、迅速にアクセスするために、高SAP周波数(典型的には、タイプ3が可能である)を有する1つの表現を配布することを望む。しかしながら、同調の後で、クライアントは、より効率的であり、IDRフレームがより少ない表現に切り替えることを望む。切替え先表現は異なるセグメントサイズを有することすら可能である。このシナリオは、ユニキャストにおける事例であってよいが、ハイブリッド事例であってもよい。このシナリオを図1に示す。この図では、より短いセグメントはユニキャストを介して可能にされ、各セグメントはIDRフレームを含む。クライアントがある時間にユニキャストサポートなしにプログラムに加わる場合、セグメントが受信され、再生が開始され得るまである程度の時間がかかることになる(図1のセグメント9)。これは、(たとえば、セグメントのメディアデータを復号するためのメディアデコーダを適切に初期化するために)セグメント全体が受信される必要があることによる。
この場合、ユニキャスト表現は、セグメント持続時間の4分の1で提供される。クライアントは、効率的な(長いセグメント、長いIDRフレーム距離)ブロードキャスト表現がブロードキャストを介して到着するまで、ユニキャスト短セグメントをプレイアウトすることを速やかに選ぶことができる。MPDにおけるこれらの能力(ランダムアクセスポイントおよびスイッチポイントの位置)のシグナリングは重要であるが、今日、不可能である。
別の同様の使用事例は、SHVCとの高速同調に関連する。低RAP周波数およびさらに小さなセグメントサイズを有するベースレイヤ、ならびにより大きなGOP周波数を有するエンハンスメントレイヤの提供が存在し得る。その場合、図1に関して論じるのと同じことを実現することができる。これらの特徴をシグナリングすることは、今日、不可能である。
別の望ましい使用事例は、効果的な時間シフトバッファの使用である。場合によっては、表現は、小さなセグメントを有するライブエッジにおいて提供され得るが、クライアントが時間シフトバッファに移動するとすぐに、そのセグメントサイズは増大する。表現は依然としてシームレスな切替え能力を表すための1つの適応セットの形であり得るが、これらの表現は、同じセグメントサイズおよび/または同じスイッチポイント/ランダムアクセスポイント周波数を有することを強制されるべきではない。同じことは、将来のオンデマンド使用のためのライブイベントの記録にも当てはまる。
別の使用事例は、オープンGOPとの高速同調に関連する。オープンGOPは、一般に、GOPの外部のピクチャに対して予測され得るピクチャを含むGOPに対応し得る。これは、GOPのすべてのピクチャがGOP内の他のピクチャから予測される自己完結型であるクローズドGOPと対照的である。たとえば、オープンGOPはインター予測されたピクチャ(または、インター予測されたキーフレーム)から開始し得るが、クローズドGOPはイントラ予測されたピクチャから開始し得る。
オープンGOPとの高速同調の事例は、ブロードキャスト高速同調に関する典型的な事例であり得る。問題は、迅速に同調し、表現にわたって切り替え、場合によっては、低レイテンシを提供することを望む場合が存在することである。これは、シグナリング、すなわち、セグメント、オープンGOP、クローズドGOP、セグメントアラインメントなどのシグナリングに関して複雑な使用事例を生じ得る。
別の使用事例は、連続性のための高速スイッチダウン(switch down)に関連する。この事例はまた、ブロードキャスト高速同調シナリオに関して一般的であり得る。問題は、迅速に同調し、表現にわたって切り替え、場合によっては、低レイテンシを提供することを望む場合が存在することである。これは、シグナリング、すなわち、セグメント、オープンGOP、クローズドGOP、セグメントアラインメントなどのシグナリングに関して複雑な使用事例をも生じ得る。
別の使用事例は、セグメント可用性に関連する。レイテンシを低減するために、セグメントは短い必要があるだけでなく、セグメントの生成と公開との間の時間も短い必要がある。HTTP404エラーを回避するために、セグメント可用性時間が受信機に利用可能にされる(たとえば、シグナリングされる)必要がある。セグメントテンプレートは可用性時間を告知するためのパターンを提供するが、これは、セグメントが正確な時間に利用可能であることを必要とし、したがって、セグメント可用性開始時間を告知するとき、セグメント持続時間における変化を考慮に入れる必要があり、エンコーダはこのパターンに従う必要がある。コンテンツプロバイダがセグメント可用性時間にIDRフレームを生成することを強制される場合、それは、IDRフレーム配置をより容易に変化させることができ、セグメント可用性時間はより正確に告知され得る。この態様は、セグメントシグナリング持続時間において考慮されるべきである。
様々な使用事例において、切替え、配信、およびランダムアクセスの様々な特徴の関連性はより高いか、または低いが、これらの特徴は1つのコンテンツ提供内で提供される必要があり得る。考慮されるべきいくつかのシナリオが存在する。
より低い周波数においてユニキャスト表現に切り替える能力とともに、低チャネル獲得時間を用いたブロードキャスト配布の展開。
ブロードキャストと同期するユニキャストを介したライブエッジにおける低レイテンシバージョンの配信。
配信ユニットよりも長いランダムアクセル周波数だけを用いたブロードキャストを介した低レイテンシバージョンの配信。
考慮する必要がある様々なセグメント持続時間。
本開示の技法は、これらの様々な使用事例を、単独で、または任意の組合せで可能にすることができ、上記で論じた問題のうちのいずれかまたはすべてを克服することができる。
図2は、様々なタイプのメディアセグメント同士の間の関係を示すベン図200である。メディアセグメントは、次のように、DASHにおいて様々な目的のうちのいずれかまたはすべてに関して使用され得る。
表現切替え
クローズドGOPが一般に必要である。
セグメントは1つの表現内で時間的に重複してはならない。
セグメントは1つの適応セット内の異なる表現にわたって整合されなければならない。
ランダムアクセス
オープンGOPが一般に必要である。
オープンGOPランダムアクセスが許可される場合、セグメントは1つの表現内で時間的に重複してよい。
配信ユニット
ランダムアクセスまたは切替えに関して何の要件もない。
セグメントは整数のムービーセグメントを含まなければならない。
様々な態様に対処するために、図2に従って、4つの異なるセグメントタイプ(または、フォーマット)を考慮することができる。
配信ユニットセグメントフォーマット202:何の制約もないフラグメントのみ。(図2において実線の輪郭を用いて楕円によって表現されている)。
ランダムアクセスセグメントフォーマット204:同調のためのオープンGOP。(図2において破線の輪郭を用いて楕円によって表現されている)。
非重複セグメントフォーマット206:クライアントデバイスは、何の問題もなしに、このフォーマットのセグメントに切り替えることができる。(図2において点線の輪郭を用いて楕円によって表現されている)。
切り替えセグメントフォーマット208:クライアントデバイスは、このフォーマットのセグメントに切り替えることができる。(図2において二重点線の輪郭を用いて楕円によって表現されている)。
図3は、表現210およびISO BMFFファイル212A〜212Cの例示的な構造を示す概念図である。図3はまた、(ムービーフラグメント)ボックスとムービーデータ(mdat)ボックスとを含む、ISO BMFFファイル212Aの分解図を示す。図3の例示的なISO BMFFファイル212Aは、下でより詳細に説明する、図6のムービーフラグメント164に概念的に類似する。ムービーフラグメントはメディアデータのための配信ユニットであると考えることが重要である。ムービーフラグメントは、たとえば、図3に示すように、それらのムービーフラグメントがmoofボックスおよびmdatボックスのシーケンスを包含するように生成される。
図4は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図4の例では、コンテンツ準備デバイス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ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを決定することができる。
図4の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコード化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコード化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケタイザを含む場合がある。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケタイザを含む場合がある。
ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つまたは複数のビューを有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの異なる表現を生成してもよい。本開示で使用される場合、表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含み得る。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含んでもよい。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームを組み立てる役割を担う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(アドバンストビデオコーディング)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(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:Supplemental Enhancement Information)は、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に送ることができる。図4の例では、サーバデバイス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などの加入側クライアントデバイスに向けさせることができる。
図4の例に示すように、マルチメディアコンテンツ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に送信する。
本開示の技法によれば、マニフェストファイル66は、(本明細書において、セグメントのタイプとも呼ばれる)セグメントが準拠し得る様々なセグメントフォーマットをシグナリングすることができる。マニフェストファイル66は、各フォーマットに準拠するセグメントのロケーション(すなわち、セグメントの様々なタイプの各々のロケーション)をシグナリングすることもできる。たとえば、マニフェストファイル66は、セグメントの様々なタイプの各々が表現68の各々の中で生じる周波数をシグナリングする。
マニフェストファイル66を使用して、クライアントデバイス40は、メディアデータの低レイテンシ再生を実現することができる。たとえば、表現68のうちの1つ(たとえば、表現68A)は、マニフェストファイル66によって示されるように、比較的高い周波数のSAPを含むことができ、表現68の別の表現(たとえば、表現68N)は、比較的低い周波数のSAPを含むことができる。具体的には、SAPは特定のフォーマット、たとえば、ランダムアクセスメディアセグメントフォーマットおよび/または切替えメディアセグメントフォーマットに準拠するセグメントの部分を形成することができる。さらに、表現68は、異なる送信サービスを介した取出しのために利用可能であり得る。たとえば、表現68Aはユニキャストを介して利用可能であり得る一方、表現68Nはブロードキャストを介して利用可能であり得る。
本開示の技法のいくつかの例によれば、クライアントデバイス40は、上記の例によれば、表現68Aが、マニフェストファイル66によって示されるように、比較的高い周波数のSAP(たとえば、非常に高い周波数のランダムアクセスメディアセグメントおよび/または非常高い周波数の切替えメディアセグメント)を示すと決定することができる。さらに、クライアントデバイス40は、表現68Nが、比較的低い周波数のSAPを含むが、比較的高い品質も含むと決定することができる。したがって、メディアデータ取出しを開始するために、クライアントデバイス40は、クライアントデバイス40が、マニフェストファイル66によって示されるように、たとえば、68Nのランダムアクセスメディアセグメントまたは切替えメディアセグメントにおいて、クライアントデバイス40が表現68Nに切り替えることができるまで、表現68Aからメディアセグメントを取り出すことによって開始することができる。これらの技法の例を説明する様々な詳細な使用事例について、たとえば、図7〜図14に関して下記で説明する。
ビデオエンコーダ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に送る。
本開示の技法によれば、コンテンツ準備デバイス20、サーバデバイス60、および/またはクライアントデバイス40のうちのいずれかまたはすべては、新しいDASHプロファイル(たとえば、アドバンストライブプロファイル)に従って、メディアデータを定義、シグナリング、および/または処理するための様々な方法を実行するように構成され得る。同様に、これらのデバイスのうちのいずれかまたはすべては、同時に高効率ビデオコーディング構造を有効化しながら、ブロードキャストおよびマルチキャストにおける低減されたチャネル変更時間を含めて、レイテンシビデオストリーミングを有効化し得る新しいタイプのメディアセグメントを処理するように構成され得る。一般に、単独で、または任意の組合せで実行され得る次の態様について論じる。
様々なメディアセグメントタイプおよびその構造の定義。
現在の属性の検討。
ソリューション考慮。
MPDシグナリング。
セグメント内のタイプのシグナリング。
MPD内のタイプのシグナリング。
様々な使用事例に関する適応セットの有効化。
いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40は、次のフォーマットのうちのいずれかに準拠するメディアセグメントを利用するように構成され得る。すなわち、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、および/または切替えメディアセグメントフォーマットである。これらのフォーマットについて、下記でより詳細に説明する。
配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る:
各メディアセグメントは、1つまたは複数の自己完結型ムービーフラグメントを含むべきである。自己完結型ムービーフラグメント全体はムービーフラグメント(「moof」)ボックスであり、トラックによって参照される外部データ参照を使用しないすべてのメディアサンプルを含むメディアデータ(「mdat」)ボックスはムービーフラグメントボックス内で実行する。
各「moof」ボックスは少なくとも1つのトラックフラグメントを包含すべきである。
「moof」ボックスは外部データ参照を使用すべきではなく、フラグ「default-base-is-moof」が設定されるべきであり、データオフセットが使用されるべき、すなわち、「base-data-offset-present」は使用されるべきではない。設定のこの組合せは、メディアデータに関するムービーフラグメント相対アドレッシングと呼ばれる場合がある。
各メディアセグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「dums」を搬送することができる。このブランドの準拠要件は本開示において定義される通りであり得る。
ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義される:
メディアセグメントは、上記で指定したように、配信ユニットメディアセグメントフォーマットに準拠すべきである。
ランダムアクセスメディアセグメント内の各ムービーフラグメント内の第1のアクセスユニットは、(たとえば、IDRピクチャ、CRAピクチャ、またはBLAピクチャを含む)タイプ1、2、または3のSAPのISAUに対応すべきである。
メディアセグメントは、ストリーム内のメディアにアクセスするために十分な情報、たとえば、利用可能な場合、初期化セグメントとの組合せですべての必要な暗号を搬送すべきである。
各「traf」ボックス(トラックフラグメントボックス)は「tfdt」ボックス(トラックフラグメント復号時間ボックス)を含むべきである。
各メディアセグメントは、互換性のあるブランドとして、セグメントタイプボックス(「styp」)内で「rams」を搬送することができる。このブランドの準拠要件は本下位条項において定義される通りである。
各メディアセグメントは、1つまたは複数の「sidx」ボックスを含み得る。存在する場合、第1の「sidx」ボックスはいずれの「moof」ボックスの前に配置されるべきであり、第1のセグメントインデックスボックスはセグメント全体を文書化すべきである。
重複なしセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る:
メディアセグメントは、上記で指定したように、配信ユニットメディアセグメントフォーマットに準拠すべきである。
セグメントおよびその先行するセグメントは非重複属性を満たすという意味で、セグメントはISO/IEC23009-1の4.5.3において定義されるように非重複属性を満たすべきである。
切替えメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る。
メディアセグメントは、上記で指定したように、ランダムアクセスメディアセグメントフォーマットに準拠すべきである。
切替えメディアセグメント内の第1のムービーフラグメント内の第1のサンプルは、タイプ1または2のSAPのISAUに対応すべきである(たとえば、IDRピクチャ)。
各メディアセグメントは、互換性があるブランドとして、セグメントタイプボックス内で「swms」を搬送する。このブランドの準拠要件は本下位条項において定義される通りである。
様々なフォーマットのセグメントが異なる機能を実行し得る。たとえば、配信ユニットメディアセグメントは、一般に、メディアデータを配信する機能を実行する。別のデータとして、ランダムアクセスメディアセグメントは、ランダムアクセスメディアセグメントを含む表現に(初期化データを含む)ランダムアクセスポイントを提供する機能を実行する。重複なしセグメントは、単純な表現切替えを有効化し得る、表現同士の間のセグメントアラインメントを示す機能を実行し得る。切替えメディアセグメントは、ランダムアクセスメディアセグメントに関して必要とされることになる余分な初期化データを含まずに、表現切替えを可能にする機能を実現する。
さらに、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40は、上記で論じたフォーマットを表すデータおよび/または、たとえば、マニフェストファイル66内の、本開示の技法による他のデータ(MPDなど)を処理するように構成され得る。次の特徴は、単独で、または何らかの組合せで、マニフェストファイル66内でシグナリングされ得る。
明示的にシグナリングされるか、またはパターンを通してシグナリングされる、表現内の各メディアセグメントのタイプ。
1つの適応セット内に異なるセグメントサイズを有するが、依然として、整合された切替えポイントを有する能力、すなわち、切替えメディアセグメントは同時に開始する。
minBufferTimeおよび帯域幅の計算に関する結果(ランダムアクセスポイントから開始すべき)。
表現68の各々に関して、かつ場合によっては、デフォルト設定された適応セットレベルにおいて、以下がマニフェストファイル66内でシグナリングされ得る。
表現内のパターン。
すべてのセグメントは配信ユニットメディアタイプのセグメントのものであり、すべてのN番目のセグメントはランダムアクセスメディアセグメントであり、すべてのM番目のセグメントはM>=Nである切替えセグメントである。一部の省略およびデフォルトは実行可能であり得る。
これは新しい属性、rams-frequencyおよびswmg-frequencyを用いてシグナリングされ得る。
MPDを更新せずにパターンの表現を可能にする他の省略パターン。
タイムラインセグメント内のパターン
各要素に関するタイムラインセグメント内のオプションのタイプフィールドの追加。
セグメントタイプ。
タイプフィールドはまた上記のパターンのようにパターンを表すこともできる。
タイムラインセグメント内のS要素の更新に伴う不規則性のシグナリングを有効化する。
明示的
場合によっては、いくつかのパターンを交互させて、明示的なリスト内でセグメントパターンをシグナリングすることを可能にするフィールドを追加する。
これはセグメント持続時間のシグナリングも含み得る。
共通の適応セット内の表現は異なるセグメント持続時間を有することが可能であり得る。しかしながら、切替えに関する問題は、シームレスな切替えを有効化するために、表現にわたる切替えポイントがシグナリングされる必要があるということである。切替えポイントの位置は上記で論じたようにシグナリングされ得る。以下のシグナリングを考慮することもできる。
すべての表現は同じ位置に切替えポイントを有し、すべての表現は整合される。これは単一のフラグを用いてシグナリングされ得る。
切替えポイントが特定の時間(この場合、複雑であり得るMPD時間)にシグナリングされるとき、これは、表現内のすべての他の切替えポイントに整合される。これはまた、単一のフラグを用いてシグナリング可能であり、上記で論じたのと同じフラグを使用することができる。
いくつかの例では、続く切替えメディアセグメントが存在しない場合ですら、クライアントデバイス40が重複なしポイントから切替えメディアセグメントに切り替えることができるように、依然として重複は存在しない。
切替えポイントの他のより明示的なシグナリングをマニフェストファイル66内でさらにシグナリングすることができる。
上述のように、いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、および/またはクライアントデバイス40は、DASHのアドバンストライブプロファイルを利用するように構成され得る。アドバンストライブプロファイルは、上記で定義されたすべての特徴およびセグメント「タイプ」を含み得る。アドバンストライブプロファイルは、ユニフォームリソースネーム(URN)「"urn:mpeg:dash:profile:advanced-live:2015」によって特定され得る。
いくつかの例では、適応セット内でアドバンストライブプロファイルが使用される場合:
すべての切替えメディアセグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「swms」を搬送すべきである。
「swms」を搬送しないすべての「ランダムアクセスメディア」セグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「rams」を搬送すべきである。
本開示は、MPD属性に関する従来のシグナリングに関する次の問題および限界を認識する:
1.セグメント可用性時間のシグナリング
@durationまたはセグメントタイムラインのいずれか:
提案は、新しいプロファイル内で簡素化し、この目的でセグメントタイムラインだけを使用するが、これは、セグメントタイムラインは@durationのスーパーセットであるためである。
しかしながら、セグメントタイムラインは例外を認めるため、セグメントタイムラインはより複雑である。
セグメントライムライン内の時間が正確なセグメント持続時間であるか(コンテンツオーサリングにおいてより低いフレキシビリティを許可するか)またはドリフトフリー(drift-free)持続時間であり、セグメント可用性時間だけをシグナリングするかどうかを明らかにする必要もある。
@timecaleの適切な適用によって、この問題を解決することができることに留意することが重要である。
2.属性、すなわち、重複なしからの切替えのシグナリング
セグメントアラインメントが適応セット内で真に設定されていることによる。
問題は、これは各セグメントが同じ持続時間を有する必要があることである。
重複なしは、より蜜な粒度で表される必要がある。
3.ランダムアクセスのシグナリング
SAPを1、2、または3に設定することから開始する:
問題は、これはあまり明示的に示されないことである。
他の要件も設定されなければならない。ランダムアクセスセグメントの拡張された定義を参照。
4.切替えポイントのシグナリング。
SAPを1または2に設定することから開始する:
問題は、これはあまり明示的に示されないことである。
他のタイプの切替えを適用することができるが、これはさらなる考えを必要とする。何らかのフレキシビリティを追加すべきである。
5.セグメントURLのシグナリング
数ベースのテンプレート
問題は基本的に、各セグメントが各適応セット内の各表現内に同じ数を有するという仮定が存在することである。これは要件ではないが、実装において仮定される可能性が高いことに留意されたい。1つの適応セット内で異なるサイズのセグメントを有するように変更する場合、番号付けの対応はもはや存在しない。
差し当たり、簡素化するために、番号を使用しない。
時間ベースのテンプレート
問題は基本的に、各セグメントが各適応セット内の各表現内に同じ時間を有するという仮定が存在することである。これは要件ではないが、実装において仮定される可能性が高いことに留意されたい。
しかしながら、これは共通のタイムラインに関して表され得ることにも留意されたい。さらに、異なる表現にわたる関係を表すために、タイムラインは番号付けよりも適切である。
「セグメント」のリスト
問題は、ここで、リスト位置はセグメントに整合し、これはネーミングが任意である場合に当てはまる可能性があることである。クライアントは、適応セット内の各表現のリストの正確なマッピングおよび順序を維持する必要がある。
異なる部分を割り当てるために本開示の技法が必要とされる。サーバデバイス60およびクライアントデバイス40は、いくつかの例において、次の手法に従って構成され得る。
持続時間/セグメントタイムラインは配信ユニットに割り当てられるが、これは、セグメントがサーバにおいて利用可能であるとき、持続時間/セグメントタイムラインは時間を表すためである。
時間は、メディア時間の点で正確でない可能性があるが、セグメント可用性開始時間を計算するために使用される。
このタイミングは1つの適応セット内の異なる表現に対して異なり得る。たとえば、他の表現よりもより多くの配信ユニットを有する、利用可能な「表現」が存在し得る。使用事例の議論を参照されたい。
上記の信号に基づいてセグメント可用性開始時間をどのように計算するかに関する明瞭な命令が必要とされる。既存のモデルは効果的であるが、本開示の技法に従ってセグメント可用性開始時間の計算について既存のモデルが使用される場合、その実務家は既存のモデルを適切に使用することが確実であるべきである。
これは、セグメント可用性時間はいくつかの表現に関して調整され得るか、または可用性時間オフセットによってbaseURLに関して調整され得ることを含む。
明瞭にすべきもう1つの重要な問題は、セグメント持続時間が可用性開始時間およびシグナリングに与える影響がどの程度不規則であるかである。一般に、セグメントは同じサイズのものであるべきである。
ランダムアクセスは異なる表現内で異なり得る。
ランダムアクセスがセグメントの開始時においてだけタイミングワイズ(timing wise)であるか、またはランダムアクセスがやはりセグメントの中央にあるかを明らかにする必要がある。
4.2.2.によれば、これは、現在、セグメントの開始にあるが、ランダムアクセスポイントが不規則に配置される場合、これは不規則なセグメントをもたらし得る。
セグメント可用性の予測可能性は低いため、これはレイテンシにも影響を及ぼす。
しかしながら、作業仮説として、「ランダムアクセス」はセグメントの開始時であるという4.2.2モデルを維持すべきである。
「ランダムアクセス」は、2つの領域、すなわち、時間、またはセグメント番号付けにおいてシグナリングされ得る。
一般的なツールに達するために、時間ベースの手法を使用することができる。
核心となる実験において、少なくとも2つの切替え手法が論じられた。
ビットストリーム切替え:
DASHクライアントは、表現の内部構造に気づかない。DASHクライアントは、表現をどこでスプライスできるかを単に知っており、これを単一のビットストリームとしてメディアデコーダに供給する。エンコーダは、この属性がカプセル化およびメディアストリームレベルで満たされるように、表現が符号化されることを確実にする。
これは、基本的に、クライアントが次のようにシーケンス/ビットストリームを作成することを許可することになる:
適応セットに関する初期化セグメント
表現1のメディアセグメント1
...
表現1のメディアセグメントX
表現2のメディアセグメントX+1
...
切替えは、メディア内の特定の属性によって有効化される。これはDASHにおいて行われたことである。切替えがファイルプレイアウトレベルにおいてどのように行われ得るかについて何らかの規則が作成された。基本的な規則は、当然、セグメントアラインメントが真に設定され、SAPからの開始が1または2である場合、次のシーケンスがシームレスな切替えを実現することである:
初期化セグメント表現1
表現1のメディアセグメント1
...
表現1のメディアセグメントX
初期化セグメント表現2
表現2のメディアセグメントX+1
...
オープンGOPにおける切替え、またはメディア処理のより詳細な理解を必要とする他の態様。
上記の議論に基づいて、マニフェストファイル66(たとえば、MPD)に拡張および制限を適用することができ、拡張および制限は新しいツールに適用され得る。たとえば、次の拡張を、単独で、または何らかの組合せで適用することができる。
表現レベルで@timescaleの規模で表される新しい属性@randomAccessPeriod(または、ランダムアクセス期間を表すための何らかの他の手段)を追加する。$Time$が@timescaleおよび@randomAccessPeriodの積の整数倍になる任意のセグメントは、ランダムアクセスセグメントであり、すなわち、これは、この表現の適応セットへのアクセスを許可する。
ランダムアクセスをさらに条件付けることができる。たとえば、何の期間に何のSAPタイプ、すなわち、SAPタイプ1、2、または3が利用可能であるか。3は受けたSAPタイプはまた1または2であり得ることを意味することに留意されたい。
適応セットレベル(1つまたは複数が存在し得る)に関する2つの属性を有する新しい切替えメディアセグメント要素(または、切替えを表すための何らかの他の手段)を追加する。
@timescaleの尺度での@period表現。$Time$が@timescaleとの積の整数倍になる任意の時間位置は、切替え機会を提供し、すなわち、これはこの表現への切替えを許可する。
切替えのタイプを表す@typeが有効化される。少なくとも2つのタイプ、すなわち、ビットストリーム切替えおよびメディアレベル切替えが定義され得る。オープンGOP切替えなど、他のタイプが定義され得る。
そのような切替えを表す別の方法は、記述子を使用することであり、記述子は、切替えのタイプおよび切替え周波数の値を表す。
セグメントタイムラインおよびS要素において、デフォルト設定によって偽に設定する追加の属性@resetを提供する。リセットは、ランダムアクセス期間および切替え期間の周期性がこの時点でリセットされることを意味する。これは、IDRが追加され、セグメントタイムラインが基本的により任意の時間にリセットされることを可能にする。
上記のシナリオは、セグメントテンプレートが上記で論じたセグメント可用性を提供する使用事例を必ずしもサポートするとは限らない。やはりこの使用事例に対処するために、次の拡張を追加することができる。
表現レベル(1つまたは複数が存在し得る)に関する2つの属性を有する新しい切替え要素(または、切替えを表すための何らかの他の手段または要素)を追加する:
@timescaleの尺度での@period表現。$Time$が@timescaleとの積の整数倍になる任意の時間位置は、切替え機会を提供し、すなわち、これはこの表現への切替えを許可する。
切替えのタイプを表す@typeが有効化される。少なくとも2つのタイプ、すなわち、ビットストリーム切替えおよびメディアレベル切替えが定義され得る。オープンGOP切替えなど、他のタイプが定義され得る。
より高度な使用事例を有効化するために、アドバンストライブプロファイルに次の制限を適用することが提案される。
1つの適応セット内のすべての表現に関して単一の@timescaleを使用する。
(簡単のために)セグメント持続時間のシグナリングのためにセグメントタイムラインを使用する。
(簡単のために)URLのシグナリングのために$Time$だけを使用する。
セグメント持続時間に関するタイミングは正確である(作業仮定、その結果を理解する必要がある)。
セグメント持続時間の精度は、使用中の@timescaleによって制御可能であり(留意)、たとえば、タイムスケールが実際のサンプリングレートの1/5だけである場合、正確なサンプリングレートに関して何らかのフレキシビリティを有する。
異なる表現内の異なるセグメント持続時間を可能にするために、セグメントタイムラインは表現単位である。しかしながら、セグメントタイムラインは適応セットレベルにおいてデフォルトであり得る。
セグメントタイムラインは、終端開放型@r(-1)または閉鎖型@r(>=0)を使用することができる。
セグメントアラインメントおよびSAPからの開始は、後方互換性の開発に関して使用され得るが、一般に、使用すべきではない。シグナリングは常に@randomAccess Periodおよび切替え要素によって提供されなければならない。
適応セットが2つ以上の「表現」を含む場合、適応セットレベルの表現に関して切替え論理が提供されることを確実にする必要がある。
DASHに関して主に説明するが、本開示の技法は、MPEG-2 TS(トランスポートストリーム)、またはWebMなど、他のメディアフォーマットのために使用されてもよい。
このようにして、クライアントデバイス40は、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、または切替えメディアセグメントフォーマットのうちの少なくとも1つに準拠するメディアセグメントを取り出し、メディアセグメントが配信ユニットメディアセグメントフォーマットに準拠するか、ランダムアクセスメディアセグメントフォーマットに準拠するか、重複なしセグメントフォーマットに準拠するか、または切替えメディアセグメントフォーマットに準拠するかに少なくとも部分的に基づいて、メディアセグメントを処理するように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
クライアントデバイス40はまた、表現内の様々なタイプのメディアセグメントに関するパターンを示すデータを含むマニフェストファイルを受信し、そのパターンに少なくとも部分的に基づいて、メディアセグメントのうちの1つまたは複数を取り出すように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
さらに、クライアントデバイス40は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととを行うように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
同様に、サーバデバイス60およびコンテンツ準備デバイス20は、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、または切替えメディアセグメントフォーマットのうちの少なくとも1つに準拠するメディアセグメントを形成し、メディアセグメントをクライアントデバイスに送るように構成された1つまたは複数のプロセッサを備えるメディアデータを送るためのデバイスの例を表す。
サーバデバイス60またはコンテンツ準備デバイス20はまた、表現内の様々なタイプのメディアセグメントに関するパターンを示すデータを含むマニフェストファイルをクライアントデバイスに送り、1つまたは複数の要求に応じて、そのパターンに少なくとも部分的に基づいて、メディアセグメントのうちの1つまたは複数をクライアントデバイスに送るように構成された1つまたは複数のプロセッサを備えるメディアデータを送るためのデバイスの例を表す。
サーバデバイス60およびコンテンツ準備デバイス20は、メディア情報をシグナリングするためのデバイスであって、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることと行うように構成された1つまたは複数のプロセッサを含むデバイスの例を表す。
図5Aは、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図4)、または記憶媒体62内に記憶された別のマルチメディアコンテンツに対応し得る。図5Aの例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104と複数の表現110A〜110N(表現110)とを含む。表現110Aは、任意のヘッダデータ112とセグメント114A〜114N(セグメント114)とを含む一方、表現110Nは、任意のヘッダデータ122とセグメント124A〜124N(セグメント124)とを含む。文字Nが、便宜的に、表現110の各々の最後のムービーフラグメントを指定するために使用される。いくつかの例では、表現110同士の間で異なる数のムービーフラグメントが存在し得る。
MPD104は、表現110とは別個のデータ構造を含んでもよい。MPD104は、図4のマニフェストファイル66に対応し得る。同様に、表現110は、図4の表現68に対応し得る。一般に、MPD104は、コーディングおよびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を`検索するための情報(たとえば、再生中のメディアコンテンツへのターゲティング広告の挿入)のような、表現110の特性を一般に記述するデータを含んでもよい。
ヘッダデータ112は、存在するとき、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント114のうちのどれがランダムアクセスポイントを含むのか、セグメント114内のランダムアクセスポイントへのバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の態様を記述し得る。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を記述することができる。追加または代替として、そのような特性はMPD104内に完全に含まれ得る。
セグメント114、124は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。MPD104のデータは、図5Aの例には示されていないが、そのような特性は、MPD104のデータによって記述され得る。MPD104は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
図5Bは、本開示の技法による、メディアプレゼンテーション記述(MPD)104の例示的なコンテンツを示す概念図である。一般に、MPD104内でシグナリングされるデータの中でも、図5Bの例では、MPD104は、期間情報130と、適応セット情報132と、表現情報134A〜134N(表現情報134)とを含む。適応セット情報132の単一のセットだけがこの例に示されるが、一般に、適応セット情報の複数のセットが含まれてよいことを理解されたい。同様に、期間情報130の単一のセットだけがこの例に示されるが、一般に、期間情報の複数のセットが含まれてよいことを理解されたい。
本開示の技法によれば、表現情報134Aは、セグメントタイプ情報136Aと、セグメント機能情報138Aと、セグメントロケーション140Aとを含む。同様に、表現情報134Nは、セグメントタイプ情報136Nと、セグメント機能情報138Nと、セグメントロケーション140Nとを含む。一般に、セグメントタイプ情報136A、136Nは、それぞれ、表現情報134A、134Nに対応する表現内に含まれたセグメントの様々なタイプを記述する。たとえば、セグメントタイプ136A、136Nは、配信ユニットメディアセグメントタイプ(または、フォーマット)、ランダムアクセスメディアセグメントタイプ(または、フォーマット)、重複なしセグメントタイプ(または、フォーマット)、および切替えメディアセグメントタイプ(または、フォーマット)のうちのいずれかまたはすべてを含み得る。
セグメント機能情報138A、138Nは、一般に、様々なセグメントタイプによって実行される機能を記述する。たとえば、対応するセグメントタイプ情報136A、136Nに配信ユニットメディアセグメントタイプ(または、フォーマット)、ランダムアクセスメディアセグメントタイプ(または、フォーマット)、重複なしセグメントタイプ(または、フォーマット)、および切替えメディアセグメントタイプ(または、フォーマット)が存在すると仮定すると、セグメント機能情報138A、138Nは、それらのタイプ/フォーマットのうちのいずれかまたはすべてによって実行される機能を記述し得る。セグメント機能情報138A、138Nは、配信ユニットメディアセグメントタイプが一般にメディアデータを搬送するために使用され、ランダムアクセスメディアセグメントタイプが(初期化情報を含む)ランダムアクセスポイントを提供するために使用され、重複なしセグメントタイプが、そのようなセグメントが同じ表現または他の表現の他のセグメントに重複しないことを示し、切替えメディアセグメントタイプが適応セット内の表現同士の間の切替えを可能にすることを示し得る。
セグメントロケーション情報140A、140Nは、一般に、対応する表現内の様々なタイプのセグメントのロケーション(または、位置)をシグナリングすることができる。たとえば、セグメントロケーション情報140A、140Nは、配信ユニットメディアセグメントタイプ、ランダムアクセスメディアセグメントタイプ、重複なしセグメントタイプ、および/または切替えメディアセグメントタイプの各々内のセグメントが対応する表現内で生じる周波数をシグナリングすることができる。セグメントロケーション情報140A、140Nは、そのような情報をパターンの形態で(たとえば、第N番目ごとのセグメントがタイプXのセグメントであることを)示し得る。追加または代替として、セグメントロケーション情報140A、140Nは、個々のセグメントのロケーションを明示的に列挙することができる。
図6は、図5Aのセグメント114、124のうちの1つなど、表現のセグメントに対応し得る例示的なビデオファイル150の要素を示すブロック図である。セグメント114、124の各々は、図6の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図6の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、ムービー(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と、ムービーフラグメント(MOOF)ボックス164と、ムービーフラグメントランダムアクセス(MFRA)ボックス166とを含む。図6は、ビデオファイルの例を表すが、他のメディアファイルは、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更新ボックスに関する追加の情報を提供する。
図6の例では、MOOVボックス154は、ムービーヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数のムービー延長(MVEX:movie extends)ボックス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(図4)がビデオファイル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、図6には示されない)を含み得る。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フレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
アドバンストライブプロファイルは、ライブサービス配布に重点を置く予想される新しいプロファイルである。予想されるプロファイルは、必ずしも拡張された共通プロファイルに対して後方互換性があると見なされるとは限らない。しかしながら、コンテンツプロバイダは、必須と見なされる場合、コンテンツの後方互換性があるバージョンを生成することができる。下記で論じる図は、本開示の技法を適用することができる様々な使用事例を表す。
図7は、本開示の技法による、使用事例に関する例示的なセグメント提供を示す概念図である。具体的には、図7は、表現232と表現234とを含む適応セット230を示す。表現232は、IDRセグメント236AとIDRセグメント236Eとを含むセグメント236A〜236Eを含み、表現234は、IDRセグメント238AとIDRセグメント238Eとを含むセグメント238A〜238Eを含む。
この使用事例は、低レイテンシビデオストリーミングサービスおよび切替えを含む。セグメントは(再生時間の点で)0.5秒の持続時間であり、フレームレートは50フレーム毎秒(FPS)であると仮定する。この例では、本開示の技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
4つごとのセグメントが切替え/IDR(瞬時デコーダリフレッシュ)セグメントである。
すべてのセグメントが配信ユニットである。
図7によれば、適応セット230に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=100
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=232
表現:@id=234
低レイテンシビデオストリーミングサービスおよび切替えを含む、本開示の技法による別の使用事例について図1を参照して説明する。図1は、この使用事例の場合のセグメント提供を示す。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、この使用事例に関するセットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現内のセグメントは、ユニキャスト表現内のセグメントのサイズの4倍である。
ブロードキャスト/ユニキャスト重複の位置におけるセグメントは切替えセグメントである。
図7によれば、適応セット230に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=1, @randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=2、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
図8は、本開示の技術による、スケーラブルHEVC(SHVC)との高速同調を含む使用事例を示す概念図である。図8の例は、ベースレイヤ(ユニキャスト)表現242と、エンハンスメントレイヤ(ブロードキャスト)表現244とを含む適応セット240を示す。ベースレイヤ表現242はセグメント246A〜246E(セグメント246)を含む一方、エンハンスメントレイヤ表現244はセグメント248A、248B(セグメント248)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で説明した技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
セグメント246、248の各々はランダムアクセスセグメントである。(セグメント246Aは図8においてIDRを含むとして示されているが、他の機能的エントリポイントが存在し得るため、ランダムアクセスポイントは必ずしもIDRに制約されるとは限らない。オープンGOPは十分であり得る。)
エンハンスメントレイヤ表現244(すなわち、ブロードキャスト表現)内のセグメント248は、ベースレイヤ表現242(すなわち、ユニキャスト表現)内のセグメント246の持続時間の4倍である。
図8の例によれば、適応セット240に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=242、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
表現:@id=244、@randomAccessPeriod=100、@dependencyID=242
SegmentTimeline.S:@t=0、@d=100、@r=-1
図9は、本開示の技術による、ストリームアクセスポイント(SAP)タイプ3との高速同調を含む例示的な使用事例を示す概念図である。具体的には、図9の例では、適応セット254は、その各々がオープンGOPを含むセグメント252A〜252Eを含む表現250を含む。図9には示されないが、適応セット254は表現250に加えて複数の表現を含み得る。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。図9の例によれば、適応セット254に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=250
図10は、高速同調およびハイブリダイゼーションを含む例示的な使用事例を示す概念図である。具体的には、この例では、適応セット260は、表現262と表現264とを含む。表現262は、セグメント266A〜266F(セグメント266)を含む一方、表現264は、セグメント268A〜268F(セグメント268)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
4つごとのセグメントはメディア切替えのための切替えセグメントである。
図10によれば、適応セット260に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=25
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=262
表現:@id=264
図11は、高速同調、ハイブリダイゼーション、およびオープンGOPを含む例示的な使用事例を示す概念図である。図10のセグメント提供と同じセグメント提供を図11に示す。さらに、図11の例は、クライアントデバイス40(図1)などのクライアントデバイスによって取り出されるセグメントを表すセグメントトラバーサル270を示す。すなわち、クライアントデバイス40は、最初に、表現262のセグメント266Aを取り出し、次いで、(たとえば、利用可能なネットワーク帯域幅の変更により)表現264に切り替えることができる。切り替えるために、クライアントデバイス40はセグメント268Bを取り出すことができる。この例では、セグメント266AはIDRセグメントである一方、セグメント268BはオープンGOPセグメントである。本開示の技法によれば、セグメント268BはオープンGOPセグメントであるため、クライアントデバイス40は、表現264のIDRセグメント(たとえば、セグメント268E)を待たずに、268Bにおいて切替えを実現することができる。クライアントデバイス40はまた、表現264のセグメント268Cを取り出す。その後、クライアントデバイス40は、表現を、このとき表現262に再び切替え、やはりオープンGOPセグメントであるセグメント266Dを取り出す。この例では、クライアントデバイス40は、セグメントトラバーサル270に従って、表現262からセグメント266Eおよび266Fを取り出す。
切替えはタイプ3のSAPにおいて生じ得る。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
4つごとのセグメントはメディア切替えのための切替えセグメントである。
すべてのセグメントはオープンGOP切替えのための切替えセグメントである。
図11によれば、適応セット260に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=25
Switching:@period=100、@type=「media」
Switching:@period=25、@type=「open GOP」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=262
表現:@id=264
図12は、オープンGOPとの高速同調およびハイブリダイゼーションを含む別の例示的な使用事例を示す概念図である。この例では、適応セット280は、ユニキャスト表現282とブロードキャスト表現284とを含む。ユニキャスト表現282は、セグメント286A〜286F(セグメント286)を含む一方、ブロードキャスト表現284は、セグメント288A、288B(セグメント288)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現284内のセグメント288は、ユニキャスト表現282内のセグメント286の持続時間の4倍である。
ブロードキャスト/ユニキャスト重複の位置にあるセグメント(たとえば、セグメント286A、286E、288A、288B)は切替えセグメントである。
図12によれば、適応セット280に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=282、@randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=284、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
図13は、高速同調および超低レイテンシを含む例示的な使用事例を示す概念図である。この例では、適応セット290は、ユニキャスト表現292とブロードキャスト表現294とを含む。ユニキャスト表現292は、セグメント296A〜296F(セグメント296)を含む一方、ブロードキャスト表現294は、セグメント298A、298B(セグメント298)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現294内のセグメント298は、ユニキャスト表現292内のセグメント296の持続時間の4倍である。
ブロードキャスト/ユニキャスト重複の位置にあるセグメント(たとえば、セグメント296A、296E、298A、298B)は切替えセグメントである。
さらに、表現292のすべてのセグメント296が切替えのための情報を提供するわけではない。たとえば、セグメント296Cはブロードキャスト表現294からユニキャスト表現292への切替えを可能にする(たとえば、ブロードキャストサービスが利用不可能になる場合)。しかしながら、セグメント296B、296D、および296Fは、配信ユニットメディアセグメントフォーマットに準拠し、切替えポイントを含まない。これは、たとえば、非イントラ予測フレーム(たとえば、インター予測フレーム)がより高い品質でコーディングされ得るように、セグメント296B、296D、および296Fのより多くのビットがこれらのフレームに割り振られることを可能にする。
図13によれば、適応セット290に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=292、@randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=294、@randomAccessPeriod=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
図14は、高速同調および超低レイテンシを含む別の例示的な使用事例を示す概念図である。この例では、適応セット300は、表現302と表現304とを含む。表現302は、セグメント306A〜306F(セグメント306)を含む一方、表現304は、セグメント308A〜308F(セグメント308)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
表現302内のセグメント306の各々はランダムアクセスセグメントである。
すなわち、図14に示すように、セグメント306の各々はIDRピクチャを含む。しかしながら、表現304のセグメント308Aおよび308EはIDRピクチャを含むが、セグメント308B、308C、308D、および308FはIDRピクチャを含まない。これは、クライアントデバイス40(図1)などのクライアントデバイスが、セグメント306のうち最近利用可能なセグメントを取り出し、次いで、IDRを含むセグメント308の次のセグメントが利用可能になるとき、表現304に切り替えることによって、適応セット300のメディアコンテンツに迅速に同調することを可能にする。
図14によれば、適応セット300に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTimeline.S:@t=0、@d=25、@r=-1
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=302、@randomAccessPeriod=25
Switching:@period=25、@type=「media」
表現:@id=304、@randomAccessPeriod=100
Switching:@period=100、@type=「media」
このようにして、本開示の技法は以下を含む。
追加の新しいセグメントタイプ。
切替えおよび@randomAccessPeriodのための追加のMPDシグナリング。
異なるタイプの切替えに関する定義。
メディア切替え:セグメントアラインメントおよびSAPタイプ1または2。
ビットストリーム切替え:連結が許可される。
オープンGOP切替え。
拡張および制限を文書化するプロファイルを追加する。
後方互換性に関するいずれの問題も文書化する。
より詳細な例を提供する。
未解決の問題および代替案が残る。次の問題が未解決のまま残る。
本開示の技法に加えて、またはその代替として、ある種の影響および利益をもたらし得る番号ベースのシグナリングが可能である。
本開示の技法に加えて、またはその代替として、リサンプリングおよび非リサンプリングを並行させることが可能な、異なるタイプのオープンGOP切替えも可能である。
上記で論じたメディアフォーマットに関して、追加または代替のメディアフォーマットを使用することができる。
いくつかの例では、フルセグメントに加えて、またはその代替として、サブセグメントを使用することもできる。図6に示したようなセグメントインデックスボックス(SIDX)は、サブセグメントのロケーションをシグナリングすることができ、かつ/または(たとえば、ファイルメタデータ内で、および/またはMPDなどのマニフェストファイル内で)追加の情報がシグナリングされ得る。
図15は、本開示のいくつかの技法による、メディアコンテンツの表現のセグメントを取り出すための例示的な方法を示すフローチャートである。図15の方法は、図4のサーバデバイス60およびクライアントデバイス40によって実行されるとして説明される。しかしながら、この方法は、他のデバイスによって実行され得ることを理解されたい。たとえば、サーバデバイスに帰属する方法のすべてまたは部分は、(たとえば、図4のサーバデバイス60に加えて、またはその代替として)図4のコンテンツ準備デバイス20によって実行され得る。同様に、クライアントデバイスに帰属する方法のすべてまたは部分は、ブロードキャストおよび/またはユニキャスト送信を介してメディアデータを受信するように構成されたクライアントデバイスのミドルウェアユニットによって実行され得る。
この例では、サーバデバイス60は最初に、コード化メディアストリームを受信する(320)。いくつかの例では、サーバデバイス60は、コード化メディアストリームをコンテンツ準備デバイス20から受信する一方、他の例では、サーバデバイス60は、コード化メディアストリームを形成するための1つまたは複数の符号化生メディアデータを含み得る。
サーバデバイス60は、その場合、この例では、コード化メディアストリーム内のセグメントのタイプおよびロケーションを決定する(322)。いくつかの例では、サーバデバイス60は、セグメント(すなわち、独立して取出し可能なファイル)を形成することができる一方、他の例では、サーバデバイス60は、コード化メディアストリームの一部としてセグメントを受信および分析し、その特性に基づいて、セグメントのタイプを決定することができる。配信ユニットメディアセグメント、ランダムアクセスメディアセグメント、重複なしセグメント、および切替えメディアセグメントなど、セグメントの様々なタイプの特性について上記で論じた。このようにして、サーバデバイス60は、各セグメントを分析して、これらのセグメントタイプのうちどれが分析されているセグメントの特性に一致するかを決定することができる。さらに、サーバデバイス60は、コード化メディアストリーム内の各タイプのセグメントの位置を決定することができる。たとえば、サーバデバイス60は、各セグメントタイプが生じる周波数を決定することができる。一例として、図7に関して、IDRを含むセグメント(すなわち、ランダムアクセスメディアセグメント)は、表現232、234の各々の4つのセグメントごとに生じる。
この例では、サーバデバイス60は、次いで、セグメントのタイプおよびロケーションをシグナリングする(MPDなどの)マニフェストファイルを構築する(324)。代替として、サーバデバイス60は、コンテンツ準備デバイス20から、本開示の技法に従って部分的または完全に構築されたマニフェストファイルを受信することができる。サーバデバイス60は、マニフェストファイルによって表された各適応の各対応する表現内のセグメントのタイプおよびロケーションに関する情報(すなわち、信号)を含めるようにマニフェストファイルを構築することができる。サーバデバイス60は、図7〜図14の例に関して上記で論じたデータと同様のデータを含めるようにマニフェストファイルを構築することができる。マニフェストファイルは、表現および表現自体のメディアデータとは別であることを理解されたい。たとえば、マニフェストファイルは、マニフェストファイルによって記述されたメディアデータ(たとえば、セグメントまたはセグメントの部分)に関して行われる要求とは別の要求に関して利用可能であり得る。
サーバデバイス60は、次いで、マニフェストファイルを、たとえば、クライアントデバイス40に出力することができる(326)。いくつかの例では、クライアントデバイス40は、最初に、たとえば、マニフェストファイルに関するユニキャスト要求によって、マニフェストファイルを要求することができる。他の例では、クライアントデバイス40は、ブロードキャスト送信に加入することができ、サーバデバイス60はブロードキャストを介してマニフェストファイルを周期的に出力することができる。いずれの場合も、クライアントデバイス40はサーバデバイス60によって出力されたマニフェストファイルを受信することができる(328)。
クライアントデバイス40は、次いで、マニフェストファイルからセグメントのタイプおよびロケーションを決定することができる(330)。たとえば、クライアントデバイス40は、マニフェストファイルが、特定の適応セットが、たとえば、配信ユニットメディアセグメント、ランダムアクセスメディアセグメント、重複なしセグメント、および切替えメディアセグメントを含む表現を含むことを示すと決定することができる。クライアントデバイス40はまた、セグメントのこれらのタイプの各々のロケーションを決定することができる。たとえば、クライアントデバイス40はセグメントのこれらのタイプのすべてまたは一部が生じる周波数をマニフェストファイルから決定することができる。
クライアントデバイス40は、メディアデータの取出しを開始する表現のうちの1つを決定することができる。クライアントデバイス40は、上記で論じた様々な使用事例のうちのいずれかを実行することができる。低レイテンシ再生を実現するために、クライアントデバイス40は、もしあれば、表現のうちのどれが、ストリームアクセスポイント(SAP)、たとえば、IDRフレームを含む頻度が最も高いセグメントを有するかを決定することができる。そのような表現は、ユニキャストを介した取出しのために利用可能なセグメントを含み得る。クライアントデバイス40は、そのようなセグメントをユニキャスト表現から最初に取り出し、次いで、(この場合も、マニフェストファイルによって示された)ブロードキャスト表現の次に利用可能なSAPにおいてブロードキャスト表現に切り替えるように構成され得る。
いずれの場合にも、クライアントデバイス40は、開始ポイントを提供する表現のセグメントを決定することができる(332)。上記で論じたように、セグメントは、ランダムアクセスメディアセグメントを含むことができ、すなわち、ランダムアクセスメディアセグメントフォーマットに準拠し得る。同様に、クライアントデバイス40は、たとえば、マニフェストファイルによって指定されたテンプレートに従って、決定されたセグメントに関するユニフォームリソースロケータ(URL)を決定することができる。次いで、クライアントデバイス40は、たとえば、サーバデバイス60に対してURLに関するHTTP Get要求または部分Get要求を発行することによって、決定されたセグメントを要求することができる(334)。
次いで、サーバデバイス60は、要求を受信し(336)、要求に応じて、要求されたセグメントをクライアントデバイス40に送信する(338)ことができる。セグメントを受信した(340)後で、クライアントデバイス40は、受信されたセグメントのデータを最初にバッファし、次いで、受信されたセグメントのデータを最終的に復号し、提示することができる(342)。
上記で論じたように、表現の決定されたセグメントを最初に取り出した後で、クライアントデバイス40は、異なる表現に切り替えるかどうか、およびいつ切り替えるかを決定することができる。たとえば、初期表現は、周波数が非常に高いSAPを含むことができ、ターゲット表現は周波数が比較的に低いSAPを含むことができる。クライアントデバイス40は、ターゲット表現のSAPを含むセグメント(たとえば、ランダムアクセスメディアセグメントまたは切替えメディアセグメント)に達するまで、初期表現からセグメントを要求し続けることができる。その場合、クライアントデバイス40は、(ターゲット表現がユニキャストを介して利用可能である場合)ターゲット表現からセグメントの要求を開始すること、または(ターゲット表現がブロードキャストを介して利用可能である場合)ターゲット表現のメディアデータをトランスポートしているブロードキャストサービスに加入することのいずれかが可能である。
このようにして、図15は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するステップであって、それらのタイプのセグメントのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するステップと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するステップと、決定されたセグメントをその表現から取り出すステップとを含む方法の一例を表す。
図15はまた、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するステップと、そのマニフェストファイルをクライアントデバイスに送るステップと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るステップとを含む方法の一例を表す。
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 マニフェストファイル
68A〜68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述(MPD)
110A〜110N 表現
112 ヘッダデータ
114 セグメント114A〜114N
122 ヘッダデータ
124A〜124N セグメント
130 期間情報
132 適応セット情報
134A〜134N 表現情報
136A セグメントタイプ情報
136N セグメントタイプ情報
138A セグメント機能情報
138N セグメント機能情報
140A セグメントロケーション
140N セグメントロケーション
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 ムービー(MOOV)ボックス
156 ムービーヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 ムービー延長(MVEX:movie extends)ボックス
162 セグメントインデックス(SIDX)ボックス
164 ムービーフラグメント(MOOF)ボックス、ムービーフラグメント
166 ムービーフラグメントランダムアクセス(MFRA)ボックス
200 ベン図
202 配信ユニットセグメントフォーマット
204 ランダムアクセスセグメントフォーマット
206 非重複セグメントフォーマット
208 切替えセグメントフォーマット
210 表現
212A〜212C ISO MBFFファイル
230 適応セット
232 表現
234 表現
236A〜236E IDRセグメント
238A〜238E セグメント
240 適応セット
242 ベースレイヤ(ユニキャスト)表現
244 エンハンスメントレイヤ(ブロードキャスト)表現
246A〜246E セグメント
248A セグメント
248B セグメント
250 表現
252A〜252E セグメント
254 適応セット
260 適応セット
262 表現
264 表現
266A〜266F セグメント
268A〜268F セグメント
270 セグメントトラバーサル
280 適応セット
282 ユニキャスト表現
284 ブロードキャスト表現
286A〜286F セグメント
288A セグメント
288B セグメント
290 適応セット
292 ユニキャスト表現
294 ブロードキャスト表現
296A〜296F セグメント
298A セグメント
298B セグメント
300 適応セット
302 表現
304 表現
306A〜306F セグメント
308A〜308F セグメント

Claims (44)

  1. メディアデータを取り出す方法であって、
    マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を決定するステップであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からのデータの取出しを開始するポイントを提供する、決定するステップと、
    前記マニフェストファイルから、前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを決定するステップと、
    前記決定されたセグメントを前記表現から取り出すステップと
    を含む、方法。
  2. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項1に記載の方法。
  3. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項2に記載の方法。
  4. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記セグメントに続くビットストリーム内に含めることと
    を示す、請求項2に記載の方法。
  5. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備えることを示す、請求項4に記載の方法。
  6. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項2に記載の方法。
  7. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項2に記載の方法。
  8. メディアデータを取り出すためのクライアントデバイスであって、
    マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を決定することであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からのデータの取出しを開始するポイントを提供する、決定することと、
    前記マニフェストファイルから、前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを決定することと、
    前記決定されたセグメントを前記表現から取り出すことと
    を行うように構成された1つまたは複数のプロセッサを備える、クライアントデバイス。
  9. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項8に記載のクライアントデバイス。
  10. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項9に記載のクライアントデバイス。
  11. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記セグメントに続くビットストリーム内に含めることと
    を示す、請求項9に記載のクライアントデバイス。
  12. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備えることを示す、請求項11に記載のクライアントデバイス。
  13. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項9に記載のクライアントデバイス。
  14. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項9に記載のクライアントデバイス。
  15. メディアデータを取り出すためのクライアントデバイスであって、
    マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を決定するための手段であって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からのデータの取出しを開始するポイントを提供する、決定するための手段と、
    前記マニフェストファイルから、前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを決定するための手段と、
    前記決定されたセグメントを前記表現から取り出すための手段と
    を備える、クライアントデバイス。
  16. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項15に記載のクライアントデバイス。
  17. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項16に記載のクライアントデバイス。
  18. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記ストリームに続くビットストリーム内に含めることと
    を示す、請求項16に記載のクライアントデバイス。
  19. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備えることを示す、請求項18に記載のクライアントデバイス。
  20. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項16に記載のクライアントデバイス。
  21. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項16に記載のクライアントデバイス。
  22. 実行されると、
    マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を決定することであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からのデータの取出しを開始するポイントを提供する、決定することと、
    前記マニフェストファイルから、前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを決定することと、
    前記決定されたセグメントを前記表現から取り出すことと
    をプロセッサに行わせる命令を記憶したコンピュータ可読記憶媒体。
  23. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項22に記載のコンピュータ可読記憶媒体。
  24. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項23に記載のコンピュータ可読記憶媒体。
  25. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが:
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記セグメントに続くビットストリーム内に含めることと
    を示す、請求項23に記載のコンピュータ可読記憶媒体。
  26. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備えることを示す、請求項25に記載のコンピュータ可読記憶媒体。
  27. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項23に記載のコンピュータ可読記憶媒体。
  28. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項23に記載のコンピュータ可読記憶媒体。
  29. メディア情報をシグナリングする方法であって、
    メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するステップであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からの取出しを開始するポイント、および前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを提供する、構築するステップと、
    前記マニフェストファイルをクライアントデバイスに送るステップと、
    前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記セグメントに対する前記クライアントデバイスからの要求に応じて、前記表現からのデータの取出しを開始する前記ポイントを提供する前記セグメントを前記クライアントデバイスに送るステップと
    を含む、方法。
  30. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項29に記載の方法。
  31. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項30に記載の方法。
  32. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記セグメントに続くビットストリーム内に含めることと
    を示す、請求項30に記載の方法。
  33. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項30に記載の方法。
  34. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項30に記載の方法。
  35. メディア情報をシグナリングするためのサーバデバイスであって、
    メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からの取出しを開始するポイント、および前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを提供する、構築することと、
    前記マニフェストファイルをクライアントデバイスに送ることと、
    前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記セグメントに対する前記クライアントデバイスからの要求に応じて、前記表現からのデータの取出しを開始する前記ポイントを提供する前記セグメントを前記クライアントデバイスに送ることと
    を行うように構成された1つまたは複数のプロセッサを備える、サーバデバイス。
  36. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項35に記載のサーバデバイス。
  37. 前記配信ユニットメディアセグメントフォーマットが、対応するセグメントが、
    前記セグメントのセグメントタイプボックス内に「dums」の値を包含し、
    1つまたは複数の自己完結型ムービーフラグメントを含むことであって、各自己完結型ムービーフラグメントが、ムービーフラグメント(「moof」)ボックスと前記ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備える、含むことと、
    前記moofボックスの各々が少なくとも1つのトラックフラグメントを含むことと、
    前記moofボックスの各々が外部参照を使用しないことと、
    前記メディアセグメントの「default-base-is-moof」フラグが真に設定されることと、
    前記メディアセグメントの「base-data-offset-present」フラグが偽に設定されることと
    を示す、請求項36に記載のサーバデバイス。
  38. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが、
    ランダムアクセスセグメントを備えることであって、前記セグメントの各ムービーセグメント内の順序を示す第1のアクセスユニットがタイプ1、2、または3のストリームアクセスポイント(SAP)のISAUに対応する、備えることと、
    メディアデータにアクセスするためのすべての必要な情報を前記セグメントに続くビットストリーム内に含めることと
    を示す、請求項36に記載のサーバデバイス。
  39. 前記ランダムアクセスメディアセグメントフォーマットが、対応するセグメントが1つまたは複数のセグメントインデックス(「sidx」)ボックスを含むことを示し、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、前記メディアセグメント全体を記述する、請求項36に記載のサーバデバイス。
  40. 前記切替えメディアセグメントフォーマットが、前記対応するセグメントの順序を示す第1のムービーフラグメント内の順序を示す第1のサンプルがタイプ1または2のストリームアクセスポイント(SAP)のISAUに対応することを示す、請求項36に記載のサーバデバイス。
  41. メディア情報をシグナリングするためのサーバデバイスであって、
    メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するための手段であって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からの取出しを開始するポイント、および前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを提供する、構築するための手段と、
    前記マニフェストファイルをクライアントデバイスに送るための手段と、
    前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記セグメントに対する前記クライアントデバイスからの要求に応じて、前記表現からのデータの取出しを開始する前記ポイントを提供する前記セグメントを前記クライアントデバイスに送るための手段と
    備える、サーバデバイス。
  42. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項41に記載のサーバデバイス。
  43. 実行されると、
    メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントの前記タイプの各々によって提供される1つまたは複数の機能、および前記表現内のセグメントの前記タイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントの前記タイプのうちの少なくとも1つが、前記表現からの取出しを開始するポイント、および前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記表現のセグメントを提供する、構築することと、
    前記マニフェストファイルをクライアントデバイスに送ることと、
    前記表現からのデータの取出しを開始する前記ポイントを提供する前記タイプに準拠する前記セグメントに対する前記クライアントデバイスからの要求に応じて、前記表現からのデータの取出しを開始する前記ポイントを提供する前記セグメントを前記クライアントデバイスに送ることと
    をサーバデバイスのプロセッサに行わせる命令を記憶したコンピュータ可読記憶媒体。
  44. セグメントの前記複数のタイプが、
    対応するセグメントがメディアデータを含むことを示す配信ユニットメディアセグメントフォーマットと、
    対応するセグメントが前記表現からのデータの取出しが開始し得るポイントを提供することを示すランダムアクセスメディアセグメントフォーマットと、
    対応するセグメントが前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しないことを示す重複なしセグメントフォーマットと、
    対応するセグメントが、その時点で、取出しが、再初期化なしに、前記適応セット内の前記他の表現から前記表現に切り替えることができるポイントを提供することを示す切替えメディアセグメントフォーマットと
    を含む、請求項43に記載のコンピュータ可読記憶媒体。
JP2017541633A 2015-02-10 2016-02-10 低レイテンシビデオストリーミング Active JP6655091B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562114423P 2015-02-10 2015-02-10
US62/114,423 2015-02-10
US201562183054P 2015-06-22 2015-06-22
US62/183,054 2015-06-22
US15/019,804 US10270823B2 (en) 2015-02-10 2016-02-09 Low latency video streaming
US15/019,804 2016-02-09
PCT/US2016/017325 WO2016130657A1 (en) 2015-02-10 2016-02-10 Low latency video streaming

Publications (3)

Publication Number Publication Date
JP2018510545A true JP2018510545A (ja) 2018-04-12
JP2018510545A5 JP2018510545A5 (ja) 2019-03-07
JP6655091B2 JP6655091B2 (ja) 2020-02-26

Family

ID=56567242

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017541633A Active JP6655091B2 (ja) 2015-02-10 2016-02-10 低レイテンシビデオストリーミング

Country Status (13)

Country Link
US (1) US10270823B2 (ja)
EP (1) EP3257255B1 (ja)
JP (1) JP6655091B2 (ja)
KR (1) KR102168596B1 (ja)
CN (1) CN107251562B (ja)
AU (1) AU2016219369B2 (ja)
BR (1) BR112017017152A2 (ja)
EA (1) EA201791558A1 (ja)
ES (1) ES2767288T3 (ja)
HU (1) HUE047298T2 (ja)
TN (1) TN2017000306A1 (ja)
TW (1) TWI686077B (ja)
WO (1) WO2016130657A1 (ja)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10454985B2 (en) 2015-03-04 2019-10-22 Qualcomm Incorporated File format based streaming with dash formats based on LCT
US10681107B2 (en) * 2015-06-16 2020-06-09 Apple Inc. Adaptive video content for cellular communication
US10554713B2 (en) * 2015-06-19 2020-02-04 Microsoft Technology Licensing, Llc Low latency application streaming using temporal frame transformation
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10484701B1 (en) * 2016-11-08 2019-11-19 Amazon Technologies, Inc. Rendition switch indicator
EP3560206A1 (en) * 2016-12-22 2019-10-30 Fraunhofer Gesellschaft zur Förderung der Angewand Media streaming with fast tuning and fast channel switching
CN106658042B (zh) * 2016-12-28 2019-07-02 广州华多网络科技有限公司 一种数据推送方法及相关客户端、服务器
US10476943B2 (en) 2016-12-30 2019-11-12 Facebook, Inc. Customizing manifest file for enhancing media streaming
US10440085B2 (en) * 2016-12-30 2019-10-08 Facebook, Inc. Effectively fetch media content for enhancing media streaming
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
GB2560953A (en) * 2017-03-30 2018-10-03 Nokia Technologies Oy Video Streaming
US10924822B2 (en) 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
US11665219B2 (en) 2017-07-10 2023-05-30 Qualcomm Incorporated Processing media data using a generic descriptor for file format boxes
JP6271072B1 (ja) * 2017-10-10 2018-01-31 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
US10432970B1 (en) * 2018-06-14 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for encoding 360° immersive video
US10862940B1 (en) * 2018-07-31 2020-12-08 Glance Networks, Inc. Low latency live video on a communication session
US11284134B2 (en) * 2018-08-08 2022-03-22 Comcast Cable Communications, Llc Media content enhancement based on content importance
US10779017B2 (en) * 2018-12-10 2020-09-15 Warner Bros. Entertainment Inc. Method and system for reducing drop-outs during video stream playback
WO2020183055A1 (en) 2019-03-14 2020-09-17 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding
US11831879B2 (en) * 2019-09-20 2023-11-28 Comcast Cable Communications, Llc Methods, systems, and apparatuses for enhanced adaptive bitrate segmentation
US11765444B2 (en) 2020-07-01 2023-09-19 Qualcomm Incorporated Streaming media data including an addressable resource index track
CN113691886B (zh) * 2021-08-25 2024-05-07 三星电子（中国）研发中心 流媒体文件的下载方法和装置
US20230076014A1 (en) * 2021-08-27 2023-03-09 AirMettle, Inc. Partitioning, processing, and protecting media data
CN118044207A (zh) * 2021-09-30 2024-05-14 抖音视界有限公司 用于视频流式传输的方法、装置和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013535865A (ja) * 2010-06-29 2013-09-12 クゥアルコム・インコーポレイテッド ビデオデータをストリーミングするためのランダムアクセスポイントに信号伝達すること
JP2014239291A (ja) * 2013-06-06 2014-12-18 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP2014534684A (ja) * 2011-10-05 2014-12-18 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ コーディングされたマルチメディアデータのネットワークストリーミング中の表現の切り替え

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8803948B2 (en) * 2009-02-12 2014-08-12 Lg Electronics Inc. Broadcast receiver and 3D subtitle data processing method thereof
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9456015B2 (en) * 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US20130170561A1 (en) * 2011-07-05 2013-07-04 Nokia Corporation Method and apparatus for video coding and decoding
US20130042100A1 (en) * 2011-08-09 2013-02-14 Nokia Corporation Method and apparatus for forced playback in http streaming
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) * 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
WO2013166411A1 (en) * 2012-05-03 2013-11-07 United Video Properties, Inc. Systems and methods for preventing access to a media asset segment during a fast-access playback operation
US20150026358A1 (en) * 2013-07-19 2015-01-22 Futurewei Technologies, Inc. Metadata Information Signaling And Carriage In Dynamic Adaptive Streaming Over Hypertext Transfer Protocol

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013535865A (ja) * 2010-06-29 2013-09-12 クゥアルコム・インコーポレイテッド ビデオデータをストリーミングするためのランダムアクセスポイントに信号伝達すること
JP2014534684A (ja) * 2011-10-05 2014-12-18 クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ コーディングされたマルチメディアデータのネットワークストリーミング中の表現の切り替え
JP2014239291A (ja) * 2013-06-06 2014-12-18 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム

Also Published As

Publication number Publication date
JP6655091B2 (ja) 2020-02-26
TN2017000306A1 (en) 2019-01-16
BR112017017152A2 (pt) 2018-04-03
EP3257255A1 (en) 2017-12-20
EA201791558A1 (ru) 2017-12-29
US20160234536A1 (en) 2016-08-11
TW201633783A (zh) 2016-09-16
CN107251562A (zh) 2017-10-13
TWI686077B (zh) 2020-02-21
KR20170116027A (ko) 2017-10-18
CN107251562B (zh) 2020-03-20
AU2016219369A1 (en) 2017-07-27
EP3257255B1 (en) 2019-10-16
US10270823B2 (en) 2019-04-23
HUE047298T2 (hu) 2020-04-28
KR102168596B1 (ko) 2020-10-21
ES2767288T3 (es) 2020-06-17
AU2016219369B2 (en) 2019-10-31
WO2016130657A1 (en) 2016-08-18

Similar Documents

Publication Publication Date Title
JP6655091B2 (ja) 低レイテンシビデオストリーミング
US10805650B2 (en) Signaling important video information in network video streaming using mime type parameters
KR102534899B1 (ko) Http 를 통한 동적 적응형 스트리밍에서의 가상 현실 비디오 시그널링
KR101558116B1 (ko) 코딩된 멀티미디어 데이터의 네트워크 스트리밍 동안의 표현들 사이의 전환
US9866608B2 (en) Processing continuous multi-period content
US11665219B2 (en) Processing media data using a generic descriptor for file format boxes
JP6254291B2 (ja) Ｄａｓｈのロバストなライブ動作
KR102434300B1 (ko) 샘플 엔트리들 및 랜덤 액세스
KR102434299B1 (ko) 샘플 엔트리들 및 랜덤 액세스
US11184665B2 (en) Initialization set for network streaming of media data
KR102117805B1 (ko) 전방향성 미디어 포맷을 이용한 미디어 데이터 프로세싱
EA045713B1 (ru) Способ и клиентское устройство для извлечения мультимедийных данных из серверного устройства
OA18391A (en) Low latency video streaming.

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170814

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190125

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190125

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190902

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191202

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200131

R150 Certificate of patent or registration of utility model

Ref document number: 6655091

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250