JP2018532146A - コーディングされたオーディオデータのトランスポート - Google Patents

コーディングされたオーディオデータのトランスポート Download PDF

Info

Publication number
JP2018532146A
JP2018532146A JP2018509888A JP2018509888A JP2018532146A JP 2018532146 A JP2018532146 A JP 2018532146A JP 2018509888 A JP2018509888 A JP 2018509888A JP 2018509888 A JP2018509888 A JP 2018509888A JP 2018532146 A JP2018532146 A JP 2018532146A
Authority
JP
Japan
Prior art keywords
data
audio
adaptation sets
adaptation
client
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
JP2018509888A
Other languages
English (en)
Other versions
JP6845223B2 (ja
JP2018532146A5 (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 JP2018532146A publication Critical patent/JP2018532146A/ja
Publication of JP2018532146A5 publication Critical patent/JP2018532146A5/ja
Application granted granted Critical
Publication of JP6845223B2 publication Critical patent/JP6845223B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • 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/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/233—Processing of audio elementary streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/81—Monomedia components thereof
    • H04N21/8106—Monomedia components thereof involving special audio data, e.g. different tracks for different languages
    • 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
    • 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/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)

Abstract

一例では、オーディオデータを取り出すためのデバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。

Description

本出願は、各々の内容全体が参照により本明細書に組み込まれている、2015年8月25日に出願した米国仮出願第62/209,779号、および2015年8月25日に出願した米国仮出願第62/209,764号の利益を主張するものである。
本開示は、符号化されたメディアデータの記憶およびトランスポートに関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、ITU-T H.265/高効率ビデオコーディング(HEVC:High Efficiency Video Coding)によって定められた規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
高次アンビソニックス(HOA)信号(複数の球面調和係数(SHC)または他の階層的要素によって表されることが多い)は、音場の3次元表現である。HOA表現またはSHC表現は、SHC信号からレンダリングされるマルチチャンネルオーディオ信号を再生するために使用される局所的なスピーカー配置とは無関係な方式で、音場を表現することができる。
オーディオデータまたはビデオデータなどのメディアデータが符号化された後、メディアデータは送信または記憶のためにパケット化され得る。メディアデータは、国際標準化機構(ISO)ベースメディアファイルフォーマットおよびその拡張などの、様々な規格のいずれかに準拠するメディアファイルへと、アセンブルされ得る。
米国仮出願第62/145,960号
MPEG-H 3D Audio-The New Standard for Coding of Immersive Spatial Audio、Jurgen Herre、Senior Member、IEEE, Johannes Hilpert、Achim Kuntz、およびJan Plogsties、IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING、VOL.9、NO.5、2015年8月 「Information Technology-Dynamic Adaptive Streaming over HTTP (DASH)-Part 1: Media Presentation Description and Segment Formats」、ISO/IEC 23089-1、2012年4月1日、 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 12) 3GPP TS 26.247、V12.1.0、2013年12月 「Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems」、ISO/IEC 13818-1:2013(さらにISO/IEC 13818-1:2015) 「Information technology-Coding of audio-visual objects-Part 12: ISO base media file format」、ISO/IEC 14496-12:2012 R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月 T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月
一般に、本開示は、動的適応ストリーミングオーバーHTTP(DASH)などのストリーミングメディアトランスポート技術を使用して、3次元(3D)オーディオデータをトランスポートするための技法について説明する。3Dオーディオデータは、たとえば、1つもしくは複数のHOA信号および/または球面調和係数(SHC)の1つもしくは複数のセットを含み得る。具体的には、本開示の技法によれば、様々なタイプのオーディオデータが、たとえば、DASHに従って、別個の適応セットにおいて提供され得る。たとえば、第1の適応セットは、シーンオーディオデータを含むことができ、適応セットのうちの第1のセットは、チャンネルオーディオデータを含むことができ、適応セットのうちの第2のセットは、オブジェクトオーディオデータを含むことができる。シーンオーディオデータは一般に、背景雑音に対応し得る。チャンネルオーディオデータは一般に、(たとえば、特定の対応するスピーカーのための)特定のチャンネルに専用のオーディオデータに対応し得る。オブジェクトオーディオデータは、3次元空間において音を生成するオブジェクトから記録されたオーディオデータに対応し得る。たとえば、オブジェクトは、楽器、話している人、または他の音を生成する現実世界のオブジェクトに対応し得る。
利用可能性データは、オーディオデータのタイプの各々を含む適応セットを示すために使用され得、利用可能性データは、たとえば、MPEG-H 3D Audioデータフォーマットに従ってフォーマットされ得る。したがって、MPEG-H 3D Audioデコーダなどの専用処理ユニットが、利用可能性データを復号するために使用され得る。選択データ(たとえば、ユーザ入力または事前設定されたデータ)は、オーディオデータのタイプのうちのどれが取り出されるべきであるかを選択するために使用され得る。その場合、(DASHクライアントなどの)ストリーミングクライアントは、選択された適応セットに関するデータを取り出すよう命令され得る。
一例では、オーディオデータを取り出す方法は、複数の利用可能な適応セットを表す利用可能性データを受信するステップであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、ステップと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信するステップと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供するステップとを含む。
別の例では、オーディオデータを取り出すためのデバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。
別の例では、オーディオデータを取り出すためのデバイスは、複数の利用可能な適応セットを表す利用可能性データを受信するための手段であって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、手段と、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信するための手段と、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供するための手段とを含む。
別の例では、コンピュータ可読記憶媒体は、実行されたときに、プロセッサに、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行わせる命令を記憶している。
1つまたは複数の例の詳細が、添付図面および以下の説明において記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 取出しユニットの構成要素の例示的なセットをより詳細に示すブロック図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 表現のセグメントに対応し得る例示的なメディアファイルの要素を示すブロック図である。 符号化された3Dオーディオデータなどの符号化されたメディアデータをトランスポートするための例示的なシステムを示すブロック図である。 符号化された3Dオーディオデータなどの符号化されたメディアデータをトランスポートするための例示的なシステムを示すブロック図である。 オブジェクトベースのコンテンツからの様々なタイプのデータが別個にストリーミングされる別の例を示すブロック図である。 オブジェクトベースのコンテンツからの様々なタイプのデータが別個にストリーミングされる別の例を示すブロック図である。 本開示の技法による別の例示的なシステムを示すブロック図である。 本開示の技法による別の例示的なシステムを示すブロック図である。 本開示の技法による別の例示的なシステムを示すブロック図である。 本開示の技法によるさらなる例示的なシステムを示すブロック図である。 本開示の技法による別の例示的なシステムである。 本開示の技法が使用され得る別の例示的なシステムを示す概念図である。 本開示の技法が実装され得る別の例示的なシステムを示す概念図である。 ATSC 3.0のための例示的な概念プロトコルモデルを示す概念図である。 マルチレイヤオーディオデータの例を表す概念図である。 マルチレイヤオーディオデータの例を表す概念図である。 マルチレイヤオーディオデータの追加の例を示す概念図である。 マルチレイヤオーディオデータの追加の例を示す概念図である。 本開示の技法による、スケーラブルHOAデータが転送される別の例示的なシステムを示すブロック図である。 本開示の技法による例示的なアーキテクチャを示す概念図である。 本開示の技法による例示的なクライアントデバイスを示すブロック図である。 本開示の技法を実行するための例示的な方法を示すフローチャートである。 本開示の技法を実行するための別の例示的な方法を示すフローチャートである。
一般に、本開示は、符号化された3次元(3D)オーディオデータなどの符号化されたメディアデータをトランスポートするための技法について説明する。サラウンドサウンドの進化は、娯楽に利用可能な多数の出力フォーマットを生み出した。そのような消費者向けのサラウンドサウンドフォーマットの例は、いくつかの幾何学的座標中のラウドスピーカーへのフィードを暗黙的に指定するという点で、大半が「チャンネル」ベースである。消費者向けサラウンドサウンドフォーマットには、一般的な5.1フォーマット(これは、フロントレフト(FL)、フロントライト(FR)、センターまたはフロントセンター、バックレフトまたはサラウンドレフト、バックライトまたはサラウンドライト、および低周波効果(LFE)という6つのチャンネルを含む)、成長している7.1フォーマット、ならびに(たとえば、超解像度テレビジョン規格とともに使用するための)7.1.4フォーマットおよび22.2フォーマットのようなハイトスピーカーを含む様々なフォーマットがある。非消費者向けフォーマットは、「サラウンドアレイ」と呼ばれることが多い(対称的な、および非対称的な幾何学的配置の)任意の数のスピーカーに及び得る。そのようなアレイの一例は、切頭正二十面体の角に座標上で配置される32個のラウドスピーカーを含む。
将来のMPEG-Hエンコーダへの入力は、任意選択で、次の3つの可能性のあるフォーマットのうちの1つである。(i)事前に指定された場所にあるラウドスピーカーを通じて再生されることが意図される(上で論じられたような)従来のチャンネルベースのオーディオ、(ii)(情報の中でもとりわけ)位置座標を含む関連するメタデータを有する、単一のオーディオオブジェクトのための個別のパルス符号変調(PCM)データを伴うオブジェクトベースのオーディオ、および、(iii)(「球面調和係数」すなわちSHC、「高次アンビソニックス」すなわちHOA、および「HOA係数」とも呼ばれる)球面調和基底関数の係数を使用して音場を表すことを伴うシーンベースのオーディオ。MPEG-Hエンコーダの例は、MPEG-H 3D Audio-The New Standard for Coding of Immersive Spatial Audio、Jurgen Herre、Senior Member、IEEE, Johannes Hilpert、Achim Kuntz、およびJan Plogsties、IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING、VOL.9、NO.5、2015年8月により詳しく説明されている。
新しいMPEG-H 3D Audio規格は、チャンネル、オブジェクト、およびSCEベースのオーディオストリームの各々のための標準化されたオーディオビットストリームと、スピーカー配置(およびスピーカーの数)ならびに(レンダラを伴う)再生の位置における音響状態に対して適用可能で、かつアグノスティックである後続の復号とを規定する。
IEEEペーパー(771ページ)で指摘されているように、HOAは、係数信号の増加、ひいては空間選択性の向上をもたらし、それにより、クロストークを少なくしてラウドスピーカー信号をレンダリングすることが可能になり、その結果、音声のアーティファクトが減少する。オブジェクトとは対照的に、HOAにおける空間情報は、明示的な幾何学的メタデータにおいてではなく、係数信号自体において伝達される。したがって、アンビソニックス/HOAは、音シーンにおける個々のオブジェクトへのアクセスを可能にするには、それほど好適ではない。しかしながら、音場を表すために要素の階層的なセットを使用する、コンテンツ作成者にとってより大きい柔軟性がある。要素の階層的なセットとは、より低次の要素の基本的なセットがモデル化された音場の完全な表現を提供するように要素が並べられる、要素のセットを指し得る。セットが高次の要素を含むように拡張されるにつれて、表現はより詳細になり、分解能が向上する。
要素の階層的なセットの一例は、球面調和係数(SHC)のセットである。次の式は、SHCを使用した音場の記述または表現を示す。
この式は、時間tにおける、音場の任意の点{rr,θr,φr}における圧力piが、SHC、
によって一意に表され得ることを示す。ここで、
であり、cは音の速さ(約343m/s)であり、{rr,θr,φr}は基準の点(または観測点)であり、jn(・)は次数nの球面ベッセル関数であり、
は、次数nおよび位数mの球面調和基底関数である。角括弧の中の項は、離散フーリエ変換(DFT)、離散コサイン変換(DCT)、またはウェーブレット変換のような様々な時間-周波数の変換によって近似され得る、信号の周波数領域の表現(すなわち、S(ω,rr,θr,φr))であることが認識され得る。階層的なセットの他の例は、ウェーブレット変換係数のセットと、多分解能基底関数の係数の他のセットとを含む。
本開示の技法は、動的適応ストリーミングオーバーHTTP(DASH)などのストリーミングプロトコルを使用して、上記で説明したように符号化されたオーディオデータをトランスポートするために使用され得る。DASHの様々な態様は、たとえば、「Information Technology-Dynamic Adaptive Streaming over HTTP (DASH)-Part 1: Media Presentation Description and Segment Formats」、ISO/IEC 23089-1、2012年4月1日、および3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 12) 3GPP TS 26.247、V12.1.0、2013年12月において説明されている。
HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GET、および部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)と関連付けられたペイロードを取り出さずに、URLまたはURNと関連付けられたファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々のムービーフラグメントを取得できるので、ムービーフラグメントがHTTPストリーミングのために提供されてもよい。ムービーフラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在してもよい。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントがアクセス可能なデータの構造化された集合体であってもよい。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオデータおよび/またはオーディオデータに関して複数の表現が存在し得る。
以下で説明するように、異なる表現は、HoA、すなわち、シーンベースのオーディオのための異なる形式のスケーラブルコーディングに対応し得る。
そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造において定義されてもよい。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスがアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含んでもよい。期間は、MPDにおいて期間要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含んでもよい。表現は、オーディオデータまたはビデオデータの、多数の符号化されたバージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化されたオーディオデータまたはビデオデータのあるセクションを指すために使用される場合がある。
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられてもよい。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅適応を実行するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられてもよいので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択されてもよい。別の例として、オーディオ適応セットの表現は、帯域幅適応をサポートするために異なるビットレートで符号化された、同じタイプのオーディオデータを含み得る。いくつかの例では、1つの期間内のメディアコンテンツは、グループ0が存在する場合にはグループ0からの1つの表現によって表されてもよく、または各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表されてもよい。ある期間の各表現のタイミングデータは、期間の開始時間に対して表されてもよい。
表現は1つまたは複数のセグメントを含んでもよい。各表現が初期化セグメントを含んでもよく、または表現の各セグメントが自己初期化するものであってもよい。初期化セグメントは、それが存在する場合、表現にアクセスするための初期化情報を含んでもよい。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照されてもよい。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDは、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提示してもよい。
異なるタイプのメディアデータに対して実質的に同時に取出しを行うために異なる表現が選択されてもよい。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅適応を実行するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含むビデオ適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。
本開示の技法は、メディア(たとえば、3Dオーディオ)データを、たとえば、「Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems」、ISO/IEC 13818-1:2013(さらにISO/IEC 13818-1:2015)において説明されているMPEG-2システムに多重化するために使用され得る。システム仕様は、タイムスタンプをそれぞれ有する、アクセスユニットを有するストリーム/トラックについて説明している。アクセスユニットは多重化され、通常、この多重化が実行され得る方法についてのある程度の柔軟性がある。MPEG-Hオーディオは、すべてのオブジェクトのサンプルが1つのストリームに配置されることを許容しており、たとえば、同じタイムコードを有するすべてのサンプルは、1つのアクセスユニットにマップされ得る。システムレベルでは、オブジェクトを異なるシステムストリームに分けることを可能にする1つのマスターストリームおよび複数の補助ストリームを生成することが可能である。システムストリームは柔軟性をもたらす、すなわち、システムストリームは、ハイブリッド配信のための、まったく配信しないための、などの異なる配信経路を可能にする。
メディアデータ、たとえば、オーディオデータおよび/またはビデオデータを含むファイルは、たとえば、「Information technology-Coding of audio-visual objects-Part 12: ISO base media file format」、ISO/IEC 14496-12:2012において説明されている、ISOベースメディアファイルフォーマット(BMFF)に従って形成され得る。ISO BMFFでは、ストリームはトラックであり、アクセスユニットは、ムービーデータ(mdat)ボックスの中に含まれる。各トラックは、ムービーヘッダにおけるサンプルエントリを取得し、サンプルを表すサンプルテーブルが物理的に発見され得る。ムービーフラグメントを使用することによって分散記憶も可能である。
MPEG-2トランスポートストリーム(TS)では、ストリームはエレメンタリストリームである。MPEG-2 TSには柔軟性が少ないが、一般に、本技法はISO BMFFと同様である。メディアデータ(たとえば、符号化された3Dオーディオデータ)を含むファイルは、上記で説明した様々な技法のいずれかに従って形成され得るが、本開示は、ISO BMFF/ファイルフォーマットに関する技法について説明する。したがって、3Dオーディオデータ(たとえば、シーンオーディオデータ、オブジェクトオーディオデータ、および/またはチャンネルオーディオデータ)は、MPEG-H 3D Audioに従って符号化され、たとえば、ISO BMFFに従ってカプセル化され得る。同様に、利用可能性データは、MPEG-H 3D Audioに従って符号化され得る。したがって、(MPEG-H 3D Audioデコーダなどの)DASHクライアントとは別個のユニットまたはデバイスは、利用可能性データを復号し、適応セットのうちのどれが取り出されるべきであるかを判定し、次いで、選択された適応セットに関するデータをDASHクライアントに取り出させるための命令データをDASHクライアントに送ることができる。
一般に、ファイルは、符号化された3Dオーディオデータなどの符号化されたメディアデータを含み得る。DASHでは、そのようなファイルは、上記で説明したように、表現の「セグメント」と呼ばれ得る。さらに、コンテンツプロバイダは、上述のように、様々な適応セットを使用してメディアコンテンツを提供し得る。3Dオーディオデータに関して、シーンオーディオデータは、1つの適応セットにおいて提供され得る。この適応セットは、(たとえば、ビットレートが互いに異なるが、それ以外では実質的に同じである)シーンオーディオデータに関する様々な切替え可能(すなわち、代替)表現を含み得る。同様に、オーディオオブジェクトは各々、それぞれの適応セットにおいて提供され得る。あるいは、適応セットは、複数のオーディオオブジェクトを含むことができ、かつ/または1つもしくは複数のオーディオオブジェクトは、複数の適応セットにおいて提供され得る。
本開示の技法によれば、クライアントデバイス(たとえば、ユーザ機器、「UE」)は、(MPEG-H 3D Audio規格に従ってフォーマットされ得る)オーディオメタデータを復号しパースするように構成されたMPEG-Hオーディオデコーダまたは他のユニットを含み得る。オーディオメタデータは、(1つまたは複数のシーン適応セットおよび1つまたは複数のオーディオオブジェクト適応セットを含む)利用可能な適応セットの記述を含み得る。より詳細には、オーディオメタデータは、シーンおよび/またはオブジェクトオーディオデータとシーン/オブジェクトオーディオデータを含む適応セットとの間のマッピングを含み得る。そのようなメタデータは、本明細書では利用可能性データと呼ばれることがある。
オーディオデコーダ(または他のユニット)はさらに、ユーザインターフェースから選択データを受信し得る。ユーザは、シーンおよび/またはオーディオオブジェクトのうちのどれが出力に望ましいかを選択し得る。あるいは、ユーザは、オーディオプロファイル(たとえば、「ムービー」、「コンサート」、「ビデオゲーム」など)を選択することができ、ユーザインターフェース(または他のユニット)は、シーンおよびオーディオオブジェクトのうちのどれが、選択されたオーディオプロファイルに対応するかを判定するように構成され得る。
オーディオデコーダ(または他のユニット)は、選択データおよび利用可能性データに基づいて、適応セットのうちのどれが取り出されるべきであるかを判定し得る。次いで、オーディオデコーダは命令データを、たとえば、クライアントデバイスのDASHクライアントに提供し得る。命令データは、適応セットのうちのどれが取り出されるべきであるか、またはより詳細には、適応セットのうちのどれからデータが取り出されるべきであるかを示し得る。次いで、DASHクライアントは、選択された適応セットに関する表現を選択し、(たとえば、HTTP GET要求または部分GET要求を使用して)相応に、選択された表現からセグメントを取り出すことができる。
このようにして、DASHクライアントは、利用可能性データとオーディオデータの両方を受信し得る。しかしながら、利用可能性データは、オーディオデータとは異なるフォーマットに従って(たとえば、ISO BMFFではなくMPEG-H 3D Audioフォーマットで)フォーマットされ得る。利用可能性データはまた、メディアプレゼンテーション記述(MPD)または利用可能性データを含み得る他のマニフェストファイルのデータなど、他のメタデータとは別様にフォーマットされ得る。したがって、DASHクライアントは、利用可能性データを正確にパースし解釈することが可能ではないことがある。したがって、MPEG-H 3Dオーディオデコーダ(またはDASHクライアントとは別個の他のユニットもしくはデバイス)が、利用可能性データを復号し、どの適応セットからオーディオデータが取り出されるべきであるかを示す命令データをDASHクライアントに提供することができる。もちろん、DASHクライアントは、ビデオ適応セットからのビデオデータ、および/または時限のテキストデータなどの他のメディアデータを取り出し得る。別個のユニットまたはデバイスからそのような命令データを受信することによって、DASHクライアントは、適切な適応セットを選択し、選択された適切な適応セットからメディアデータを取り出すことが可能である。
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図1の例では、コンテンツ準備デバイス20は、オーディオソース22とビデオソース24とを含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを含み得る。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含み得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含み得る。コンテンツ準備デバイス20は必ずしも、すべての例においてサーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶する場合がある。
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含み得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化され得る。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を含んでもよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を含んでもよい。このようにして、本開示で説明する技法は、ライブオーディオデータおよびビデオデータ、ストリーミングオーディオデータおよびビデオデータ、リアルタイムオーディオデータおよびビデオデータに適用されてもよく、またはアーカイブされたオーディオデータおよびビデオデータ、以前に記録されたオーディオデータおよびビデオデータに適用されてもよい。
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に含まれるビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを含むオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応する場合がある。したがって、ビデオフレームに対応するオーディオフレームは、一般に、オーディオデータおよびビデオデータが同時にキャプチャされた(またはさもなければ同時に提示されるべき)状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。さらに、ビデオデータおよび他のオーディオデータ、たとえば、ナレーションと同時に提示されるべきであるオーディオデータは、別個に生成され得る。
いくつかの例では、オーディオエンコーダ26は、符号化された各オーディオフレームにおいて、符号化されたオーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプを符号化してもよく、同様に、ビデオエンコーダ28は、符号化された各ビデオフレームにおいて、符号化されたビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプを符号化してもよい。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/もしくはビデオエンコーダ28がタイムスタンプを生成する場合がある内部クロック、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用する場合がある内部クロックを含み得る。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ってもよく、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ってもよい。いくつかの例では、オーディオエンコーダ26は、符号化されたオーディオデータにおいて、符号化されたオーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化してもよく、同様に、ビデオエンコーダ28も、符号化されたビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用してもよい。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は、一般に、符号化されたオーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化されたビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の、デジタル的にコーディングされた(場合によっては、圧縮された)単一の構成要素である。たとえば、表現のコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであってもよい。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コーディングされたビデオデータは、一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコーディングされたビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコーディングされたオーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのパケタイザを含む場合がある。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化されたオーディオデータおよび符号化されたビデオデータからPESパケットを形成するためのパケタイザを含む場合がある。
ビデオエンコーダ28は、様々な方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数のビューを有する表現(たとえば、2次元もしくは3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの異なる表現を生成してもよい。同様にオーディオエンコーダ26は、様々な特性とともに様々な異なる方法でオーディオデータを符号化し得る。以下でより詳細に説明するように、たとえば、オーディオエンコーダ26は、シーンベースのオーディオデータ、チャンネルベースのオーディオデータ、および/またはオブジェクトベースのオーディオデータのうちの1つまたは複数をそれぞれ含むオーディオ適応セットを形成し得る。さらに、または代替として、オーディオエンコーダ26は、スケーラブルオーディオデータを含む適応セットを形成し得る。たとえば、オーディオエンコーダ26は、以下でより詳細に説明するように、ベースレイヤ、左/右情報、および高さ情報に関する適応セットを形成し得る。
本開示で使用する表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含み得る。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含み得る。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームをアセンブルする役割を担う。カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを出力インターフェース32に提供し得る。出力インターフェース32は、ネットワークインターフェースもしくはユニバーサルシリアルバス(USB)インターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェースのような記憶媒体へ書き込むためのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送ることができる。図1の例では、サーバデバイス60は、それぞれのマニフェストファイル66と1つまたは複数の表現68A〜68N(表現68)とをそれぞれが含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
いくつかの例では、表現68は、適応セットへと分割されてもよい。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を識別する場合があるテキストタイプ情報、カメラの角度または適応セット内の表現のシーンの現実世界のカメラの視野を表す場合があるカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報などのような、特性のそれぞれの共通のセットを含み得る。
マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、ならびに適応セットの共通の特性を含み得る。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にする場合がある。適応セット内の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示されてもよい。
サーバデバイス60は、要求処理ユニット70とネットワークインターフェース72とを含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送受信するように構成される。
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求をクライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に記述されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答して、マルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定することができる。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成され得る。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成され得る。
追加または代替として、要求処理ユニット70は、eMBMSなどのブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントを、eMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループと関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)と関連付けられたクライアントデバイスに広告することができる。次に、クライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえば、ネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応する場合があるマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、異なる品質を有するビデオサービス)の記述を含んでもよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含んでもよい。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、表現68のセグメントにどのようにアクセスするかを決定することができる。
具体的には、取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力部44のレンダリング能力を判定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを含み得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能のすべてまたは一部は、ハードウェア、または、ハードウェア、ソフトウェア、および/もしくはファームウェアの組合せにおいて実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定することができる。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、たとえば、適応セット内の表現のためのビットレートを判定し、ネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出し得る。
概して、表現のビットレートが高くなると、再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を介してマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
追加または代替として、取出しユニット52は、eMBMSまたはIPマルチキャストなど、ブロードキャストまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を止めること、または異なるマルチキャストグループにチャンネルを変えることを求める要求を提出することができる。
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化されたデータをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号されたオーディオデータをオーディオ出力部42に送る一方、ビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力部44に送る。オーディオ出力部42が1つまたは複数のスピーカーを含む一方、ビデオ出力部44が1つまたは複数のディスプレイを含み得る。図1には示されていないが、クライアントデバイス40はまた、キーボード、マウス、ポインタ、タッチスクリーンデバイス、遠隔制御インターフェース(たとえば、ブルートゥース(登録商標）または赤外線遠隔制御装置)などのような1つまたは複数のユーザインターフェースを含み得る。
ビデオエンコーダ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の代わりに(または、サーバデバイス60に加えて)これらの技法を実行するように構成され得ることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートもしくはプログラムストリームを記述するデータを特定するヘッダを含むNALユニットを形成してもよい。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含み得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含み得る。カプセル化ユニット30は、ビデオエンコーダ28からの符号化されたビデオデータを、エレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットをアセンブルしてもよい。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含むことができる。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば、1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが毎秒20フレーム(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応する場合がある。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、コーディングされた一次ピクチャとして提示される場合がある、1つの時間インスタンス内のコーディングされたピクチャを含み得る。
したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば、時間Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに対する符号化されたピクチャ(またはフレーム)を含み得る。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を含む場合があるメディアプレゼンテーション記述(MPD)を含んでもよく、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含んでもよい。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定することができる。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス(moofボックス)内に配置され得る。
マニフェストファイル66(たとえば、MPDを含み得る)は、表現68のセグメントの利用可能性を広告することができる。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス40の取出しユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になるときを判定することができる。
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルにアセンブルした後、カプセル化ユニット30は、ビデオファイルを出力のために出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送る代わりに、ビデオファイルをローカルに記憶するか、または出力インターフェース32を介してビデオファイルをリモートサーバに送ることができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえば、オプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピードライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含み得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供する。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化されたデータをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号されたオーディオデータをオーディオ出力部42に送る一方、ビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力部44に送る。
図2に示すように、また図2に関してより詳細に論じるように、取出しユニット52は、たとえば、DASHクライアントを含み得る。DASHクライアントは、MPEG-H 3D Audioデコーダを表し得るオーディオデコーダ46と対話するように構成され得る。図1には示されていないが、オーディオデコーダ46はさらに、(たとえば、図5〜図9に示すように)ユーザインターフェースからユーザ入力を受信するように構成され得る。したがって、DASHクライアントは、オーディオデコーダ46に利用可能性データを送ることができ、オーディオデコーダ46は、どの適応セットがどのタイプのオーディオデータ(たとえば、シーン、オブジェクト、および/またはチャンネルオーディオデータ)に対応するかを判定し得る。オーディオデコーダ46はさらに、たとえば、ユーザインターフェースを介してユーザから、または事前設定された選択から、選択データを受信し得る。オーディオデコーダ46は、次いで、(選択されたタイプのオーディオデータ、たとえば、シーン、チャンネル、および/またはオブジェクトデータに対応する)選択された適応セットに関するオーディオデータをDASHクライアントに取り出させるための命令データを(DASHクライアントに送られるように)取出しユニット52に送ることができる。
図2は、図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。図2の取出しユニット52は一例にすぎず、他の例では、取出しユニット52はDASHクライアントのみに対応し得ることを理解されたい。この例では、取出しユニット52は、eMBMSミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。図2は、図1のオーディオデコーダ46も示しており、以下で説明するように、DASHクライアント110はオーディオデコーダ46と対話し得る。
この例では、eMBMSミドルウェアユニット100は、eMBMS受信ユニット106と、キャッシュ104と、サーバユニット102とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、http://tools.ietf.org/html/rfc6726において入手可能な、T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月に記述されたFile Delivery over Unidirectional Transport(FLUTE)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、たとえば、BM-SCとして機能し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
eMBMSミドルウェアユニット100がファイルに関するデータを受信すると、eMBMSミドルウェアユニットは受信されたデータをキャッシュ104内に記憶することができる。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体など、コンピュータ可読記憶媒体を含み得る。
プロキシサーバ102は、DASHクライアント110に関するサーバとして機能してもよい。たとえば、プロキシサーバ102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に提供することができる。プロキシサーバ102は、MPDファイル内、ならびにセグメントを取り出すことができるハイパーリンク内のセグメントに関する利用可能性時間を広告することができる。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GET要求または部分GET要求を使用して、プロキシサーバ102にセグメントを要求してもよい。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を作成し、その要求をプロキシサーバ102に提出することができる。プロキシサーバ102は、要求されたデータをキャッシュ104から取り出し、そのような要求に応答して、そのデータをDASHクライアント110に提供することができる。
図2の例では、取出しユニット52はeMBMSミドルウェアユニット100を含むが、他の例では、他のタイプのミドルウェアが設けられ得ることを理解されたい。たとえば、新型テレビジョンシステム委員会(ATSC)ミドルウェアまたは全米テレビジョン方式委員会(NTSC)ミドルウェアなどのブロードキャストミドルウェアが、それぞれATSCブロードキャスト信号またはNTSCブロードキャスト信号を受信するためにeMBMSミドルウェアユニット100の代わりに設けられてよい。そのようなATSCミドルウェアまたはNTSCミドルウェアは、eMBMS受信ユニット106の代わりにATSC受信ユニットまたはNTSC受信ユニットのいずれかを含むことになるが、それ以外では、図2の例に示すようなプロキシサーバおよびキャッシュを含むことになる。受信ユニットは、すべての受信されたブロードキャストデータを受信しキャッシュすることができ、プロキシサーバは、要求されたメディアデータ(たとえば、要求されたオーディオデータ)のみをDASHクライアント110に送るだけでよい。
その上、DASHクライアント110は、図1に関して上記で説明したように、オーディオデコーダ46と対話し得る。すなわち、DASHクライアント110は、マニフェストファイルまたは利用可能性データを含む他のデータセットを受信し得る。利用可能性データは、たとえば、MPEG-H 3D Audioに従ってフォーマットされ得る。その上、利用可能性データは、どの適応セットがシーンオーディオデータ、チャンネルオーディオデータ、オブジェクトオーディオデータ、および/またはスケーラブルオーディオデータなどの様々なタイプのオーディオデータを含むかを表し得る。DASHクライアント110は、オーディオデコーダ46から選択データを受信することができ、この選択データは、たとえば、ユーザの選択に基づく、オーディオデータが取り出されるべき適応セットを示し得る。
図3Aは、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応する場合がある。図3Aの例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数の表現124A〜124N(表現124)とを含む。表現124Aは、任意のヘッダデータ126とセグメント128A〜128N(セグメント128)とを含む一方、表現124Nは、任意のヘッダデータ130とセグメント132A〜132N(セグメント132)とを含む。文字Nが、便宜的に、表現124の各々の最後のムービーフラグメントを指定するために使用される。いくつかの例では、表現124同士の間で異なる数のムービーフラグメントが存在し得る。
MPD122は、表現124とは別個のデータ構造を含んでもよい。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124は、図2の表現68に対応し得る。一般に、MPD122は、コーディングおよびレンダリングの特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへのターゲティング広告の挿入)のような、表現124の特性を一般に記述するデータを含んでもよい。
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間ロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在するとき、セグメント132の同様の特性を記述し得る。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
セグメント128、132は、1つまたは複数のコーディングされたメディアサンプルを含む。セグメント128のコーディングされたメディアサンプルの各々は、同様の特性、たとえば、言語(発話が含まれる場合)、ロケーション、コーデック、および帯域幅要件を有し得る。MPD122のデータは、図3Aの例には示されていないが、そのような特性は、MPD122のデータによって記述され得る。MPD122は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント128、132の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、別個に取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント128または132を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント128または132の特定のバイト範囲を取り出すことができる。
図3Bは、表現124BA〜124BD(表現124B)の別の例示的なセットを示す概念図である。この例では、様々な表現124Bが各々、異なるそれぞれの適応セットに対応することが想定されている。
スケーラブルシーンベースのオーディオは、再生レイアウトについての情報を含み得る。異なるタイプのシーンベースのオーディオコーデックがあり得る。様々な例について、本開示全体にわたって説明する。たとえば、シーンベースのオーディオスケーラブルコーデックタイプ0は、以下を含み得る。レイヤ0は、オーディオ左およびオーディオ右チャンネルを含み、レイヤ1は、水平HOA成分を含み、レイヤ2は、ラウドスピーカーの高さに関係する1次HOAの高さ情報を含む(これは、図13Aおよび図13Bにおけるシナリオである)。
第2の例では、シーンベースのオーディオスケーラブルコーデックタイプ1は、以下を含み得る。レイヤ0は、オーディオ左およびオーディオ右チャンネルを含み、レイヤ1は、水平HOA成分を含み、レイヤ2は、ラウドスピーカーの高さに関係する1次HOAの高さ情報を含む(たとえば、図14Aおよび図14Bに示すとおり)。
第3の例では、シーンベースのオーディオスケーラブルコーデックタイプ2は、以下を含み得る。レイヤ0は、モノチャンネルを含み、レイヤ1は、オーディオ左およびオーディオ右チャンネルを含み、レイヤ2は、オーディオフロントおよびオーディオバックチャンネルを含み、レイヤ3は、1次HOAの高さ情報を含む。
第4の例では、シーンベースのオーディオスケーラブルコーデックタイプ3は、以下を含み得る。レイヤ0は、W、X、およびY信号の形式による1次水平限定HOA情報を含む。レイヤ1は、オーディオ左およびオーディオ右チャンネルを含み、レイヤ2は、オーディオフロントおよびオーディオバックチャンネルを含む。
第5の例では、第1から第4の例が使用されてよく、追加のレイヤが、たとえば、前述の例におけるスピーカーが位置し得る水平面を下回るか、または上回る高さの、ラウドスピーカーの異なるアレイに関する高さ情報を含み得る。
したがって、表現124は各々、様々なタイプのシーンベースのスケーラブルオーディオデータを含む異なる適応セットに対応する。4つの例示的な表現124が示されているが、任意の数の適応セット(およびそれらの適応セット内の任意の数の表現)が提供されてよいことを理解されたい。
図3Bの例では、表現124BAは、タイプ0スケーラブルシーンベースのオーディオデータを含み、表現124BBは、タイプ1スケーラブルシーンベースのオーディオデータを含み、表現124BCは、タイプ2スケーラブルシーンベースのオーディオデータを含み、表現124BDは、タイプ3スケーラブルシーンベースのオーディオデータを含む。表現124Bは、対応するタイプのそれぞれのセグメントを含む。すなわち、表現124BAは、ヘッダデータタイプ0 126BAおよびタイプ0セグメント128BA〜128BNを含み、表現124BBは、ヘッダデータタイプ1 126BBおよびタイプ1セグメント128CA〜128CNを含み、表現124BCは、ヘッダデータタイプ2 126BCおよびタイプ2セグメント128DA〜128DNを含み、表現124BDは、ヘッダデータタイプ3 126BDおよびタイプ3セグメント128EA〜128ENを含む。様々な適応セット(具体的には、適応セットに含まれるスケーラブルオーディオレイヤならびに表現124Bのうちのどれがどの適応セットに対応するか)がMPD122Bにおいて記述されている。
図4は、図3のセグメント128、132のうちの1つのような表現のセグメントに対応し得る例示的なメディアファイル150の要素を示すブロック図である。セグメント128、132の各々は、図4の例で示されるデータの構成に実質的に準拠するデータを含み得る。メディアファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースメディアファイルフォーマットおよびその拡張によるメディアファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図4の例では、メディアファイル150は、ファイルタイプ(FTYP)ボックス152と、ムービー(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と、ムービーフラグメント(MOOF)ボックス164と、ムービーフラグメントランダムアクセス(MFRA)ボックス166とを含む。図4は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースメディアファイルフォーマットおよびその拡張に従ってメディアファイル150のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、時限のテキストデータなど)を含み得ることを理解されたい。
ファイルタイプ(FTYP)ボックス152は一般に、メディアファイル150のファイルタイプを表す。ファイルタイプボックス152は、メディアファイル150の最良の使用法を表す仕様を特定するデータを含み得る。ファイルタイプボックス152は、代替的には、MOOVボックス154、ムービーフラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
図4の例では、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(図3)がメディアファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を記述し得る。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングしてもよい。
MVEXボックス160は、たとえば、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、ムービーフラグメント164をメディアファイル150が含むことをシグナリングするために、対応するムービーフラグメント164の特性を記述し得る。ストリーミングビデオデータの文脈では、コーディングされたビデオピクチャは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。したがって、すべてのコーディングされたビデオサンプルは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。
MOOVボックス154は、メディアファイル150の中のムービーフラグメント164の数に等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、ムービーフラグメント164の対応する1つの特性を記述し得る。たとえば、各MVEXボックスは、ムービーフラグメント164の対応する1つの持続時間を記述するムービー延長ヘッダ(MEHD)ボックスを含み得る。
上述したように、カプセル化ユニット30(図1)は、実際のコーディングされたビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶し得る。ビデオサンプルは、一般に、アクセスユニットに対応してもよく、アクセスユニットは、特定の時間インスタンスにおけるコーディングされたピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を包含する、1つまたは複数のVCL NALユニットをコーディングされたピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、ムービーフラグメント164のうちの1つの中に含め得る。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、ムービーフラグメント164のうちの1つに対応するMVEXボックス160のうちの1つの中のムービーフラグメント164のうちの1つの中に存在するものとして、シグナリングすることができる。
SIDXボックス162は、メディアファイル150の任意の要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含むとは限らない。3GPPファイルフォーマットの例によれば、SIDXボックスは、セグメント(たとえば、メディアファイル150内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「メディアデータボックスに対応する1つまたは複数の連続するムービーフラグメントボックスの自己完結型セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスが、そのムービーフラグメントボックスに続き、同じトラックについての情報を包含する次のムービーフラグメントボックスに先行する」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を包含する。参照されるサブセグメントは、プレゼンテーション時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照される材料におけるバイトの数のカウントを与える。」ことを示す。
SIDXボックス162は、一般に、メディアファイル150内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。
ムービーフラグメント164は、1つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント164は、1つまたは複数のピクチャグループ(GOP)を含んでよく、GOPの各々は、多数のコーディングされたビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上記で説明したように、ムービーフラグメント164は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント164の各々は、ムービーフラグメントヘッダボックス(MFHD、図4には示されない)を含み得る。MFHDボックスは、ムービーフラグメントのシーケンス番号などの、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント164は、メディアファイル150の中でシーケンス番号の順番に含まれ得る。
MFRAボックス166は、メディアファイル150のムービーフラグメント164内のランダムアクセスポイントを記述し得る。これは、メディアファイル150によってカプセル化されたセグメント内の特定の時間ロケーション(すなわち、再生時間)の探索を実行するなど、トリックモードを実行することを支援し得る。MFRAボックス166は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、メディアファイル150のビデオデータを正確に復号し表示するために、MFRAボックス166を必ずしも参照する必要はない。MFRAボックス166は、メディアファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでもよく、またはいくつかの例では、メディアファイル150のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでもよい。
いくつかの例では、ムービーフラグメント164は、1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SAPのメディアファイル150内の位置の指標を提供し得る。したがって、メディアファイル150の時間的サブシーケンスは、メディアファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
図5Aは、符号化された3Dオーディオデータなどの符号化されたメディアデータをトランスポートするための例示的なシステム200を示すブロック図である。システム200は、オブジェクトベースのコンテンツ202を含み、オブジェクトベースのコンテンツ202自体は、メタデータ204、シーンデータ206、チャンネルデータ208の様々なセット、およびオブジェクトデータ210の様々なセットを含む。図5Bは、図5Aのオブジェクトベースのコンテンツ202の代わりにオーディオベースのコンテンツ202'を図5Bが含むことを除いて、図5Aと実質的に同様である。オブジェクトベースのコンテンツ202は、MPEG-Hオーディオエンコーダ212に提供され、MPEG-Hオーディオエンコーダ212は、オーディオエンコーダ214およびマルチプレクサ216を含む。MPEG-Hオーディオエンコーダ212は一般に、オーディオエンコーダ26(図1)に対応する。マルチプレクサ216は、カプセル化ユニット30(図1)の一部を形成すること、またはカプセル化ユニット30と対話することがある。図5Aには示されていないが、図1に示すようにビデオ符号化および多重化ユニットが設けられてもよいことを理解されたい。
この例では、MPEG-Hオーディオエンコーダ212は、オブジェクトベースのコンテンツ202を受信し、オーディエンコーダ214にオブジェクトベースのコンテンツ202を符号化させる。符号化され多重化されたオーディオデータ218は、MPEG-Hオーディオデコーダ220にトランスポートされ、MPEG-Hオーディオデコーダ220は、メタデータ抽出ユニット222、シーンデータ抽出ユニット224、およびオブジェクトデータ抽出ユニット226を含む。ユーザが再生中にレンダリングされるべきシーンデータ206、チャンネルデータ208、および/またはオブジェクトデータ210のうちの1つまたは複数を選択できるように、ユーザがアプリケーションプログラミングインターフェース(API)230を介してあるバージョンの抽出されたメタデータにアクセスすることを可能にするために、ユーザインターフェース228が設けられる。選択されたシーン、チャンネル、および/またはオブジェクトに従って、シーンデータ抽出ユニット224およびオブジェクトデータ抽出ユニット226は、要求されたシーン、チャンネル、および/またはオブジェクトデータを抽出することができ、MPEG-Hオーディオデコーダ220は再生中にそれを復号してオーディオレンダリングユニット232に提供する。
図5Aの例では、オブジェクトベースのコンテンツ202のデータのすべてが、符号化され多重化されたオーディオデータ218によって表されるシングルストリームにおいて提供される。しかしながら、オブジェクトベースのコンテンツ202の様々な要素を別個に提供するために複数のストリームが使用されてよい。たとえば、図6Aおよび図6Bは、オブジェクトベースのコンテンツ202(またはオーディオベースのコンテンツ202')からの様々なタイプのデータが別個にストリーミングされる別の例を示すブロック図である。具体的には、図6Aおよび図6Bの例では、符号化されたバージョンのシーンデータ206がストリーム240において提供され、ストリーム240は、符号化されたバージョンのチャンネルデータ208も含む。
図6Aおよび図6Bの例では、符号化されたバージョンのオブジェクトデータ210が、ストリーム242A〜242N(ストリーム242)の形式で提供される。オブジェクトデータ210とストリーム242との間のマッピングは、任意の方法で形成され得る。たとえば、オブジェクトデータ210のセットとストリーム242との間の1対1のマッピングがあってよく、オブジェクトデータ210の複数のセットがストリーム242のシングルストリームにおいて提供されてよく、かつ/またはストリーム242のうちの1つもしくは複数がオブジェクトデータ210の1つのセットに関するデータを含んでよい。ストリーム218、240、242は、新型テレビジョンシステム委員会(ATSC)信号もしくは全米テレビジョン方式委員会(NTSC)信号などのオーバージエア信号、eMBMSなどのコンピュータネットワークベースのブロードキャストもしくはマルチキャスト、またはHTTPなどのコンピュータネットワークベースのユニキャストを使用して送信され得る。このようにして、オブジェクトデータ210のいくつかのセットが望まれていないとき、MPEG-Hオーディオデコーダ220は、ストリーム242のうちの対応するもののデータを受信するのを回避し得る。
本開示のいくつかの例によれば、各シーンは、(たとえば、図4のMOOVボックス154など、ムービーヘッダにおいて)構成情報を有し得る。構成情報は、オブジェクトに関する情報およびオブジェクトが表すものを含み得る。構成情報はまた、対話性エンジンによって使用され得る何らかの情報を含み得る。従来、この構成情報は静的であって、ほとんど変更できなかった。しかしながら、この情報は、MPEG-2 TSの技法を使用して帯域内で修正できる。構成情報はまた、図6Aおよび図6Bに示すように、様々なストリームへのオブジェクトのマッピングを表す。
図6Aのストリーム240などのメインストリームは、構成情報ならびにオブジェクトのすべて(たとえば、オブジェクトデータ210)をどこで発見すべきかを含む。たとえば、ストリーム240は、ストリーム242のうちのどれがオブジェクトデータ210のうちのどれを含むかを示すデータを含み得る。ストリーム242は、オブジェクトデータ210のうちの含まれるもののアクセスユニットのみを搬送し得るので、「補助ストリーム」と呼ばれ得る。一般に、各オブジェクトは、補助ストリーム242のうちの個々のものにおいて搬送され得るが、上記で説明したように、補助ストリームは、複数のオブジェクトに関するデータを搬送することがあり、かつ/または1つのオブジェクトが複数の補助ストリームにおいて搬送されることがある。
ユーザインターフェース228とメタデータ抽出ユニット222との間にAPI230が存在する。API230は、メインストリームに含まれるメタデータの構成記録との対話性を可能にし得る。したがって、API230は、ユーザまたは他のエンティティがオブジェクトデータ210の1つまたは複数のオブジェクトを選択し、それらのレンダリングを決めることを可能にし得る。たとえば、ユーザは、オブジェクトデータ210のうちのどのオブジェクトが望ましいか、ならびに望ましいオブジェクトの各々を再生する際のボリュームを選択し得る。
以下の説明では、オブジェクトデータ210の各オブジェクトが別個の補助ストリームにおいて提供される(たとえば、オブジェクトデータ210とストリーム242との間の1対1の上への関係(onto relationship)がある)と想定される。しかしながら、オブジェクトデータ210は配信最適化として多重化されマップされ得ることを理解されたい。DASHによれば、各補助ストリームは、1つまたは複数の表現にマップされ得る。
図7A〜図7Cは、本開示の技法による別の例示的なシステム250を示すブロック図である。システム250は一般に、図5A、図5B、図6A、および図6Bのシステム200の要素と同様の要素を含み、かかる要素は、図7Aおよび図7Bでは同じように番号付けされている。しかしながら、システム250はさらに、図5A、図5B、図6A、および図6Bに示されていないメディアサーバ252を含む。図7Cは、図7Aのオブジェクトベースのコンテンツ202の代わりにオーディオベースのコンテンツ202'を図7Cが含むことを除いて、図7Aと実質的に同様である。
本開示の技法によれば、メディアサーバ252は、符号化されたメタデータ254と、シーンおよびチャンネル適応セット256と、様々なオブジェクト適応セット260A〜260N(オブジェクト適応セット260)とを提供する。図7Bに示すように、シーン&チャンネル適応セット256は表現258A〜258M(表現258)を含み、オブジェクト適応セット260Aは表現262A〜262P(表現262)を含み、オブジェクト適応セット260Nは表現264A〜264Q(表現264)を含む。この例では、シーンおよびチャンネル適応セット256は、単一の適応セットとして示されているが、他の例では、シーンデータおよびチャンネルデータのために別個の適応セットが提供され得る。すなわち、いくつかの例では、第1の適応セットがシーンデータを含むことができ、第2の適応セットがチャンネルデータを含むことができる。
図7Aおよび図7Bの例では、以下のマッピングに従ってコンテンツが提供される。エントリポイントであり、構成情報を搬送する1つのマスターオブジェクトがある。各オブジェクトは、(選択可能である)1つの適応セットとして提供される。各適応セット内で、(切替え可能である)複数の表現が提供される。すなわち、所与の適応セットに関する各表現は、帯域幅適応をサポートするために異なるビットレートを有し得る。オブジェクトを指すメタデータが提供される(別個に、たとえば、MPEG-Hメタデータにおいて、オブジェクトと適応セットとの間にマッピングがあり得る)。すべての表現が、この例では、同調および切替えを可能にするように時間整合される。
(MPEG-Hオーディオデコーダ220を含む)受信機では、最初にすべてのオブジェクトが利用可能であると想定される。配信のための機構が、どのデータが所与のストリームによって搬送されるかを判定する必要がないという点で、含まれるデータのラベリングは、「不明瞭」と見なされ得る。代わりに、抽象的なラベリングが使用され得る。表現の選択は、通常、DASHクライアント動作の一部であるが、API230によってサポートされ得る。以下で説明するように、DASHクライアントの例が図8に示されている。
図8は、本開示の技法によるさらなる例示的なシステムを示すブロック図である。具体的には、図8では、(雲によって表される)コンテンツ配信ネットワークが、符号化されたメタデータ254、シーンおよびチャンネル適応セット256、ならびにオブジェクト適応セット260のほか、メディアプレゼンテーション記述(MPD)270を提供する。図8には示されていないが、メディアサーバ252は、コンテンツ配信ネットワークの一部を形成し得る。
さらに、図8はDASHクライアント280を示す。この例では、DASHクライアント280は、選択ユニット282およびダウンロード&切替えユニット284を含む。選択ユニット282は、一般に、たとえば、API230を介してユーザインターフェース228から受信された選択に基づくメタデータ抽出ユニット222から受信された選択に従って、適応セットを選択し、適応セットからの表現の初期選択を行う役割を担う。
以下は、本開示の技法による、例および説明として図8の要素を参照する、基本的な動作シーケンスの一例である。最初に、DASHクライアント280は、MPD270をダウンロードし(272)、オーディオメタデータと利用可能な各オーディオオブジェクト(すなわち、利用可能な各オーディオ適応セット)の1つの表現とを含むオーディオデータのマスターセットをダウンロードする。構成情報が、MPEG-Hオーディオデコーダ220のメタデータ抽出ユニット222に提供され、メタデータ抽出ユニット222は、オブジェクトの手動選択/選択解除またはユーザエージェント選択/選択解除(すなわち、自動選択/選択解除)のためにAPI230を介してユーザインターフェース228とインターフェースをとる。同様に、DASHクライアント280の選択ユニット282は、選択情報を受信する。すなわち、MPEG-Hオーディオデコーダ220はDASHクライアント280に、(記述子または他のデータ要素によって標示された)どの適応セットが選択または選択解除されるべきであるかについて知らせる。この交換は、図8の要素274によって表される。
次いで、選択ユニット282は、選択された適応セットに関するデータを取り出し、選択解除された適応セットに関するデータのダウンロードを止めるための命令をダウンロード&切替えユニット284に提供する。したがって、ダウンロード&切替えユニット284は、選択された適応セットに関する(ただし、選択解除された適応セットに関するものではない)データをコンテンツ配信ネットワークから取り出す(276)。たとえば、ダウンロード&切替えユニット284は、選択された適応セットの選択された表現のセグメントを取り出すことを求めるHTTP GET要求または部分GET要求をコンテンツ配信ネットワークに提出し得る。
いくつかの例では、いくつかの適応セットが選択解除されるので、ダウンロード&切替えユニット284は、選択解除された適応セットに以前割り振られていた帯域幅を、選択されたままである他の適応セットに割り振ることができる。したがって、ダウンロード&切替えユニット284は、選択された適応セットのうちの1つまたは複数に関して、より高いビットレートの(ひいては、より高い品質の)表現を選択し得る。いくつかの例では、DASHクライアント280およびMPEG-Hオーディオデコーダ220は、いくつかの適応セットの品質予想に関する情報を交換する。たとえば、MPEG-Hオーディオデコーダ220は、選択された適応セットの各々に関する相対的ボリュームを受信し、より低い相対的ボリュームを有する適応セットよりも高い相対的ボリュームを有する適応セットに関して、より高い品質の表現が取り出されるべきであると判定し得る。
いくつかの例では、選択解除された適応セットに関する取出しを止めるのではなく、DASHクライアント280は、適応セットの最低ビットレート表現に関するデータを取り出すだけでよく、かかるデータは、MPEG-Hオーディオデコーダ220によって復号されず、バッファリングされ得る。このようにして、将来のある時点において、選択解除された適応セットのうちの1つは、再び選択され、その適応セットに関するバッファリングされたデータは、直ちに復号され得る。必要な場合、かつ帯域幅が利用可能である場合、ダウンロード&切替えユニット284は、再選択後にそのような適応セットのより高いビットレートの表現に切り替えることができる。
選択された適応セットに関するデータを取り出した後、ダウンロード&切替えユニット284は、MPEG-Hオーディオデコーダ220にデータを提供する(278)。したがって、MPEG-Hオーディオデコーダ220は受信されたデータを、シーンデータ抽出ユニット224およびオブジェクトデータ抽出ユニット226のうちの対応するものによる抽出の後に復号し、復号されたデータを、レンダリング、および最終的に提示のためにオーディオレンダリングユニット232に提供する。
API230にとどまらず様々な追加のAPIが設けられてもよい。たとえば、MPD270におけるデータをシグナリングするためにAPIが設けられ得る。MPD270のメタデータは、MPEG-Hオーディオにおける使用のためにダウンロードされるべきである1つのオブジェクトとして明示的にシグナリングされ得る。MPD270はまた、ダウンロードされる必要があるすべてのオーディオ適応セットをシグナリングし得る。さらに、MPD270は、選択のために使用されるべき各適応セットに関するラベルをシグナリングし得る。
同様に、MPEG-Hオーディオデコーダ220とDASHクライアント280との間の選択および選好論理のために、APIが定められ得る。DASHクライアント280は、このAPIを使用して、MPEG-Hオーディオデコーダ220に構成情報を提供し得る。MPEG-Hオーディオデコーダ220は、データ取出しの目的で選択される適応セットを示すラベルをDASHクライアント280に提供し得る。MPEG-Hオーディオデコーダ220はまた、選択された適応セットに関する適切な表現を選択するためにDASHクライアント280によって使用される、様々な適応セットの相対的重要性を表す何らかの重み付けを提供し得る。
さらに、多重化されたメディアデータをDASHクライアント280からMPEG-Hオーディオデコーダ220に提供するために、APIが定められ得る。DASHクライアント280は一般に、適応セットに割り当てられたデータのチャンクをダウンロードする。DASHクライアント280は、多重化され注釈を付けられた形でデータを提供し、また、適応セットの表現間で切り替えるための切替え論理を実装する。
このようにして、図8は、オーディオデータを取り出すためのデバイスの例を表し、デバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。
図9は、本開示の技法による別の例示的なシステムである。一般に、図9は、図8の例と実質的に同様である。図8と図9との間の違いは、図9では、メタデータ抽出ユニット222'がMPEG-Hオーディオデコーダ220'の外に設けられていることである。したがって、図8では、利用可能な適応セットを表すメタデータを提供するために、かつ利用可能な適応セットの選択(および/または選択解除)のために、選択ユニット282とメタデータ抽出ユニット222'との間に対話274'が発生する。それ以外では、図9の例は、図8の例と実質的に合致する方法で動作し得る。しかしながら、本開示の技法を実行するためにユーザインターフェースがMPEG-Hオーディオデコーダ220'と直接対話する必要がないことが強調されている。
このようにして、図9は、オーディオデータを取り出すためのデバイスの例を表し、デバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。
図10は、本開示の技法が使用され得る別の例示的なシステム350を示す概念図である。図10の例では、システム350は、メディアサーバ352を含み、メディアサーバ352は、メディアコンテンツを準備し、メディアコンテンツをブロードキャストサーバ354およびHTTPコンテンツ配信ネットワーク(CDN)358に提供する。ブロードキャストサーバ354は、たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)であり得る。ブロードキャストサーバ354は、ブロードキャスト送信機356を介してメディア信号をブロードキャストする。テレビジョン、パーソナルコンピュータ、またはセルラー電話、タブレットなどのようなモバイルデバイスなどの様々なユーザ機器(UE)クライアントデバイス364A〜364N(クライアントデバイス364)は、ブロードキャスト信号を受信し得る。ブロードキャスト送信機356は、ATSCまたはNTSCなどのオーバージエア規格に従って動作し得る。
HTTP CDN358は、コンピュータベースのネットワークを介してメディアコンテンツを提供することができ、これは、HTTPベースのストリーミング、たとえば、DASHを使用し得る。追加または代替として、CDN358は、eMBMSなどのネットワークベースのブロードキャストまたはマルチキャストプロトコルを使用して、コンピュータベースのネットワークを介してメディアコンテンツをブロードキャストまたはマルチキャストし得る。CDN358は、ユニキャスト、ブロードキャスト、および/またはマルチキャストプロトコルを介してデータを送信する複数のサーバデバイス360A〜360N(サーバデバイス360)を含む。いくつかの例では、CDN358は、ロングタームエボリューション(LTE)に従って、eNode-B362などのeNode-Bを経由して無線アクセスネットワーク(RAN)を介してコンテンツを配信する。
図10のシステムでは、様々な使用事例が発生し得る。たとえば、いくつかのメディア構成要素が、(たとえば、ブロードキャストサーバ354によって)ブロードキャストを介して配信され得る一方、他のメディア構成要素が、1つまたは複数のコンパニオンストリームとしてユニキャストを通じてのみ入手可能であり得る。たとえば、シーンベースのオーディオコンテンツが、ブロードキャストサーバによってブロードキャスト送信機を介してブロードキャストされ得る一方、オブジェクトオーディオデータが、HTTP CDN358からのみ入手可能であり得る。別の例では、チャンネル切替え時間を減らすためにユニキャストを介してデータが配信され得る。
図11は、本開示の技法が実装され得る別の例示的なシステム370を示す概念図である。図11の例は、図3に関して説明した例と概念的に同様である。すなわち、図11の例示的なシステム370では、ブロードキャストDASHサーバ376が、たとえば、ファイルのブロードキャスト配信のために、ブロードキャストファイルトランスポートパッケージャ378にメディアデータを提供する。たとえば、ブロードキャストファイルトランスポートパッケージャ378およびブロードキャストファイルトランスポート受信機380は、tools.ietf.org/html/rfc6726において入手可能な、Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Internet Engineering Task Force、RFC 6726、2012年11月に記述されているように、File Delivery over Unidirectional Transport (FLUTE)に従って動作し得る。あるいは、ブロードキャストファイルトランスポートパッケージャ378およびブロードキャストファイルトランスポート受信機380は、Real-Time Object Delivery over Unidirectional Transport (ROUTE)プロトコルに従って動作し得る。
さらに別の例では、ブロードキャストファイルトランスポートパッケージャ378およびブロードキャストファイルトランスポート受信機380は、ATSCまたはNTSCなどのオーバージエアブロードキャストプロトコルに従って動作し得る。たとえば、ATSC 3.0のためのDASHレイヤとMBMSサービスレイヤとが組み合わせられ得る。そのような組合せは、IP中心の方法でレイヤリングクリーンなMBMSサービスレイヤ実装形態を提供し得る。複数の配信の経路および方法にわたって統一された同期もあり得る。そのようなシステムはまた、多くの利益をもたらし得る、ブロードキャストを介してDASHのためのクリーンな/最適化されたサポートを提供し得る。強化されたAL FECサポートは、すべてのサービス構成要素に対して一定のサービス品質(QoS)を提供し得る。その上、この例示的なシステムは、様々な使用事例をサポートし、高速チャンネル変更および/または低レイテンシなど、様々な利益をもたらすことができる。
図11の例では、ブロードキャストDASHサーバ376は、メディアデータがいつ送信されるべきであるかを判定するために、ユニフォームタイムコード(UTC:uniform time code)ソース372を使用してタイミング情報を決定する。DASHプレーヤ384は最終的に、ローカルUTCソース374によって提供されたタイミング情報を使用して、ブロードキャストファイルトランスポート受信機380からMPDおよびメディアデータ382を受信する。あるいは、DASHプレーヤ384は、CDN386からMPDおよびメディアデータ382'を取り出し得る。DASHプレーヤ384は、時間整合された圧縮済みメディアデータ390を抽出し、時間整合された圧縮済みメディアデータ390を(図1のオーディオデコーダ46およびビデオデコーダ48を表し得る)コーデック388に渡すことができる。コーデック388は、次いで、符号化されたメディアデータを復号して、(たとえば、図1のオーディオ出力部42およびビデオ出力部44を介して)提示され得る時間整合されたメディアサンプルおよびピクセル392を生成することができる。
図12は、ATSC 3.0のための例示的な概念プロトコルモデル400を示す概念図である。モデル400では、リニアおよびアプリケーションベースのサービス412は、リニアTV、対話型サービス、コンパニオンスクリーン、個別化、緊急警報、および使用報告を含んでおり、たとえば、HTML 5および/またはジャバスクリプトを使用して実装される他のアプリケーションを含み得る。
モデル400の符号化、フォーマッティング、およびサービス管理データ410は、(たとえば、オーディオデータおよびビデオデータのための)様々なコーデックと、ISO BMFFファイルと、暗号化メディア拡張(EME:encrypted media extension)および/または共通暗号化(CENC:common encryption)を使用する暗号化と、メディア処理ユニット(MPU)と、NRTファイルと、シグナリングオブジェクトと、様々なタイプのシグナリングデータとを含む。
モデル400の配信レイヤ408において、この例では、MPEGメディアトランスポートプロトコル(MMTP)データと、ROUTEデータと、アプリケーションレイヤ前方誤り訂正(AL FEC)データ(任意であり得る)と、ユニフォームデータグラムプロトコル(UDP)データおよび伝送制御プロトコル(TCP)データ406と、ハイパーテキスト転送プロトコル(HTTP)データと、インターネットプロトコル(IP)データ404とがある。このデータは、物理レイヤ402を介したブロードキャストおよび/またはブロードバンド送信を使用してトランスポートされ得る。
図13Aは、マルチレイヤオーディオデータ700を表す概念図である。この例は、3つのサブレイヤを有する第1のレイヤを示すが、他の例では、3つのサブレイヤは3つの別個のレイヤであり得る。
図13Aの例では、高次アンビソニックオーディオデータの2つ以上のレイヤのうちの、ベースサブレイヤ702、第1のエンハンスメントサブレイヤ704、および第2のエンハンスメントサブレイヤ706を含む第1のレイヤは、1以下の次数を有する1つまたは複数の球面基底関数に対応する高次アンビソニック係数を含み得る。いくつかの例では、第2のレイヤ(すなわち、第3のエンハンスメントレイヤ)は、ベクトルベースの支配的オーディオデータを含む。いくつかの例では、ベクトルベースの支配的オーディオデータは少なくとも、支配的オーディオデータおよび符号化されたVベクトルを含み、符号化されたVベクトルは、線形可逆変換の適用を通じて高次アンビソニックオーディオデータから分解される。2015年4月10日に出願された米国仮出願第62/145,960号、およびHerre他、「MPEG-H 3D Audio-The New Standard for Coding of Immersive Spatial Audio」、IEEE 9 Journal of Selected Topics in Signal Processing 5、2015年8月は、Vベクトルに関する追加情報を含む。他の例では、ベクトルベースの支配的オーディオデータは少なくとも、追加の高次アンビソニックチャンネルを含む。さらに他の例では、ベクトルベースの支配的オーディオデータは少なくとも、自動利得補正側波帯を含む。他の例では、ベクトルベースの支配的オーディオデータは少なくとも、支配的オーディオデータ、符号化されたVベクトル、追加の高次アンビソニックチャンネル、および自動利得補正側波帯を含み、符号化されたVベクトルは、線形可逆変換の適用を通じて高次アンビソニックオーディオデータから分解される。
図13Aの例では、第1のレイヤは、少なくとも3つのサブレイヤを含み得る。ある例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ702)は少なくとも、左オーディオチャンネルと関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ702)は少なくとも、右オーディオチャンネルと関連付けられた高次アンビソニックオーディオデータを含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ702)は少なくとも、自動利得補正のための側波帯を含む。他の例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ702)は少なくとも、左オーディオチャンネルおよび右オーディオチャンネルと関連付けられた高次アンビソニックオーディオデータと、自動利得補正のための側波帯とを含む。
いくつかの例では、図13Aの少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ704)は少なくとも、局在化チャンネルと関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ704)は少なくとも、自動利得補正のための側波帯を含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ704)は少なくとも、局在化チャンネルと関連付けられた高次アンビソニックオーディオデータ、および自動利得補正のための側波帯を含む。
いくつかの例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ706)は少なくとも、高さチャンネルと関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ706)は少なくとも、自動利得補正のための側波帯を含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ706)は少なくとも、高さチャンネルと関連付けられた高次アンビソニックオーディオデータ、および自動利得補正のための側波帯を含む。
4つの別個のレイヤ(すなわち、ベースレイヤ702、第1のエンハンスメントレイヤ704、第2のエンハンスメントレイヤ706、および第3のエンハンスメントレイヤ)が存在する図13の例では、オーディオコーディングデバイスは、誤りチェックプロセスを実行し得る。いくつかの例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行し得る。別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行し、第2のレイヤ、第3のレイヤ、および第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ704)に対して誤りチェックプロセスを実行することができ、オーディオコーディングデバイスは、第3のレイヤおよび第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ704)に対して誤りチェックプロセスを実行することができ、第2のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第3のレイヤ(すなわち、第2のエンハンスメントレイヤ)に対して誤りチェックプロセスを実行することができ、オーディオコーディングデバイスは、第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ704)に対して誤りチェックプロセスを実行することができ、第2のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第3のレイヤ(すなわち、第2のエンハンスメントレイヤ706)に対して誤りチェックプロセスを実行することができ、第3のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第4のレイヤ(すなわち、第3のエンハンスメントレイヤ)に対して誤りチェックプロセスを実行することができる。オーディオコーディングデバイスが第1のレイヤ(すなわち、ベースレイヤ702)に対して誤りチェックプロセスを実行する上記の例のいずれにおいても、第1のレイヤは、誤りに対しロバストであるロバストレイヤと見なされ得る。
本開示の技法によれば、一例では、上記で説明した様々なレイヤ(たとえば、ベースレイヤ702、第2のレイヤ704、第3のレイヤ706、および第4のレイヤ)の各々からのデータは、それぞれの適応セット内で提供され得る。すなわち、ベースレイヤ適応セットは、ベースレイヤ702に対応するデータを含む1つまたは複数の表現を含むことができ、第2のレイヤ適応セットは、第2のレイヤ704に対応するデータを含む1つまたは複数の表現を含むことができ、第3のレイヤ適応セットは、第3のレイヤ706に対応するデータを含む1つまたは複数の表現を含むことができ、第4のレイヤ適応セットは、第4のレイヤに対応するデータを含む1つまたは複数の表現を含むことができる。
図13Bは、マルチレイヤオーディオデータの別の例を表す概念図である。図13Bの例は、図13Aの例と実質的に同様である。しかしながら、この例では、UHJ相関解除は実行されない。
図14Aは、マルチレイヤオーディオデータ710の別の例を示す概念図である。この例は、3つのサブレイヤを有する第1のレイヤを示すが、他の例では、3つのサブレイヤは3つの別個のレイヤであり得る。
図14Aの例では、高次アンビソニックオーディオデータの2つ以上のレイヤのうちの、ベースサブレイヤ712、第1のエンハンスメントサブレイヤおよび第2のエンハンスメントサブレイヤを含む第1のレイヤは、1以下の次数を有する1つまたは複数の球面基底関数に対応する高次アンビソニック係数を含み得る。いくつかの例では、第2のレイヤ(すなわち、第3のエンハンスメントレイヤ)は、ベクトルベースの支配的オーディオデータを含む。いくつかの例では、ベクトルベースの支配的オーディオデータは少なくとも、支配的オーディオデータおよび符号化されたVベクトルを含み、符号化されたVベクトルは、線形可逆変換の適用を通じて高次アンビソニックオーディオデータから分解される。他の例では、ベクトルベースの支配的オーディオデータは少なくとも、追加の高次アンビソニックチャンネルを含む。さらに他の例では、ベクトルベースの支配的オーディオデータは少なくとも、自動利得補正側波帯を含む。他の例では、ベクトルベースの支配的オーディオデータは少なくとも、支配的オーディオデータ、符号化されたVベクトル、追加の高次アンビソニックチャンネル、および自動利得補正側波帯を含み、符号化されたVベクトルは、線形可逆変換の適用を通じて高次アンビソニックオーディオデータから分解される。
図14Aの例では、第1のレイヤは、少なくとも3つのサブレイヤを含み得る。いくつかの例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ712)は少なくとも、0次アンビソニックと関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ712)は少なくとも、自動利得補正のための側波帯を含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第1のサブレイヤ(すなわち、ベースレイヤ712)は少なくとも、0次アンビソニックと関連付けられた高次アンビソニックオーディオデータ、および自動利得補正のための側波帯を含む。
いくつかの例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ714)は少なくとも、X成分と関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ714)は少なくとも、Y成分と関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ714)は少なくとも、自動利得補正のための側波帯を含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第2のサブレイヤ(すなわち、第1のエンハンスメントレイヤ714)は少なくとも、X成分およびY成分と関連付けられた高次アンビソニックオーディオデータと、自動利得補正のための側波帯とを含む。
いくつかの例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ716)は少なくとも、Z成分と関連付けられた高次アンビソニックオーディオデータを含む。他の例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ716)は少なくとも、自動利得補正のための側波帯を含む。さらに他の例では、少なくとも3つのサブレイヤのうちの第3のサブレイヤ(すなわち、第2のエンハンスメントレイヤ716)は少なくとも、Z成分と関連付けられた高次アンビソニックオーディオデータ、および自動利得補正のための側波帯を含む。
4つの別個のレイヤ(すなわち、ベースレイヤ712、第1のエンハンスメントレイヤ714、第2のエンハンスメントレイヤ716、および第3のエンハンスメントレイヤ)が存在する図14Aの例では、オーディオコーディングデバイスは、誤りチェックプロセスを実行し得る。いくつかの例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行し得る。別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行し、第2のレイヤ、第3のレイヤ、および第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ714)に対して誤りチェックプロセスを実行することができ、オーディオコーディングデバイスは、第3のレイヤおよび第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ714)に対して誤りチェックプロセスを実行することができ、第2のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第3のレイヤ(すなわち、第2のエンハンスメントレイヤ716)に対して誤りチェックプロセスを実行することができ、オーディオコーディングデバイスは、第4のレイヤに対して誤りチェックプロセスを実行するのを控えることができる。また別の例では、オーディオコーディングデバイスは、第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行することができ、第1のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第2のレイヤ(すなわち、第1のエンハンスメントレイヤ714)に対して誤りチェックプロセスを実行することができ、第2のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第3のレイヤ(すなわち、第2のエンハンスメントレイヤ716)に対して誤りチェックプロセスを実行することができ、第3のレイヤに誤りがないとの判定に応答して、オーディオコーディングデバイスは、第4のレイヤ(すなわち、第3のエンハンスメントレイヤ)に対して誤りチェックプロセスを実行することができる。オーディオコーディングデバイスが第1のレイヤ(すなわち、ベースレイヤ712)に対して誤りチェックプロセスを実行する上記の例のいずれにおいても、第1のレイヤは、誤りに対しロバストであるロバストレイヤと見なされ得る。
本開示の技法によれば、一例では、上記で説明した様々なレイヤ(たとえば、ベースレイヤ712、第2のレイヤ、第3のレイヤ、および第4のレイヤ)の各々からのデータは、それぞれの適応セット内で提供され得る。すなわち、ベースレイヤ712適応セットは、ベースレイヤ712に対応するデータを含む1つまたは複数の表現を含むことができ、第2のレイヤ適応セットは、第2のレイヤ714に対応するデータを含む1つまたは複数の表現を含むことができ、第3のレイヤ適応セットは、第3のレイヤ716に対応するデータを含む1つまたは複数の表現を含むことができ、第4のレイヤ適応セットは、第4のレイヤに対応するデータを含む1つまたは複数の表現を含むことができる。
図14Bは、マルチレイヤオーディオデータの別の例を表す概念図である。図14Bの例は、図14Aの例と実質的に同様である。しかしながら、この例では、モード行列相関解除は実行されない。
図15は、本開示の技法による、スケーラブルHOAデータが転送される別の例示的なシステムを示すブロック図である。一般に、図15の要素は、図8および図9の要素と実質的に同様である。すなわち、図15は、MPEG-Hオーディオデコーダ440を含むシステムを示しており、MPEG-Hオーディオデコーダ440は、コンテンツ配信ネットワークからオーディオデータを取り出すためにDASHクライアント430と対話する。図8および図9の要素と同様に名付けられている図15の要素は一般に、上記で説明したそれらの要素と同じように構成される。ただし、この例では、たとえば、図13A、図13B、図14A、および図14Bに関して上記で説明したように、シーンベースのオーディオデータのレイヤ(またはサブレイヤ)にそれぞれ対応する複数の適応セットが提供される。
具体的には、この例におけるCDN420は、シーンベースのスケーラブルオーディオコンテンツ422を提供しており、シーンベースのスケーラブルオーディオコンテンツ422は、(シーンベースのオーディオ、ベースレイヤ適応セット426の形式による)シーンベースのオーディオのベースレイヤ、および(シーンベースのオーディオ、エンハンスメントレイヤ適応セット428A〜428N(適応セット428)の形式による)複数のエンハンスメントレイヤを含むメディアコンテンツのための符号化されたメタデータ424を含む。たとえば、ベースレイヤはモノオーディオデータを含むことができ、第1のエンハンスメントレイヤは左/右情報を提供することができ、第2のエンハンスメントレイヤはフロント/バック情報を提供することができ、第3のエンハンスメントレイヤは高さ情報を提供することができる。メディアコンテンツは、MPD421によって記述される。
したがって、ユーザは、ユーザインターフェース448を介してどのタイプの情報が必要とされているかを示し得る。ユーザインターフェース448は、ディスプレイ、キーボード、マウス、タッチパッド、タッチスクリーン、トラックパッド、遠隔制御装置、マイクロフォン、ボタン、ダイヤル、スライダー、スイッチなどのような様々な入力および/または出力インターフェースのいずれかを含み得る。たとえば、シングルスピーカーのみが利用可能である場合、DASHクライアント430は、シーンベースのオーディオ、ベースレイヤ適応セット426からのみデータを取り出し得る。一方、複数のスピーカーが利用可能である場合、スピーカーの構成に応じて、DASHクライアント430は、左/右情報、フロント/バック情報、および/または高さ情報のいずれかまたはすべてを、シーンベースのオーディオ、エンハンスメントレイヤ適応セット428のうちの対応するものから取り出し得る。
DASHにおけるオーディオデータに関する2つの例示的なタイプのスケーラビリティについて、以下で説明する。第1の例は、静的デバイススケーラビリティである。この例では、ベースレイヤおよびエンハンスメントレイヤが、異なるソース信号を表す。たとえば、ベースレイヤは1080p 30fps SDRを表すことができ、エンハンスメントレイヤは4K 60fps HDRを表すことができる。この主な理由は、デバイス適応のためにより低い品質へのアクセスをサポートすることであり、たとえば、ベースレイヤは、あるデバイスクラスによって選択され、エンハンスメントレイヤは、第2のデバイスクラスによって選択される。静的デバイススケーラビリティの例では、ベースレイヤおよびエンハンスメントレイヤは、異なる適応セットにおいて提供される。すなわち、デバイスは、(たとえば、異なる適応セットにおける相補的表現からデータを取得することによって)適応セットのうちの1つまたは複数を選択し得る。
第2の例は、動的アクセス帯域幅スケーラビリティに関係する。この例では、1つのベースレイヤおよび1つまたは複数のエンハンスメントレイヤが生成される。ただし、すべてのレイヤは、同じソース信号(たとえば、1080p 60fps)を示す。これは、たとえば、DASHの技法に従って、適応ストリーミングをサポートし得る。すなわち、帯域幅の推定利用可能量に基づいて、より多いまたはより少ないエンハンスメントレイヤがダウンロード/アクセスされ得る。この例では、ベースレイヤおよびエンハンスメントレイヤは1つの適応セットにおいて提供され、シームレスに切替え可能である。この例は、ブロードキャスト/マルチキャスト配信よりもユニキャスト配信に大きく関係する。
第3の例は、静的デバイススケーラビリティおよび動的アクセス帯域幅スケーラビリティの技法の組合せを含み得る。
これらの例の各々は、DASHを使用してサポートされ得る。
図15の例では、DASHクライアント430は最初に、MPD421を受信する(460)。選択ユニット432は、利用可能な適応セット、および適応セット内の表現を決定する。選択ユニット432は、利用可能な適応セット(具体的には、利用可能なスケーラブルオーディオレイヤ)を表すデータを、MPEG-Hオーディオデコーダ440のメタデータ抽出ユニット442に提供する(462)。この例では、ユーザまたは他のエンティティは、所望のオーディオレイヤの選択を、API450を介してMPEG-Hオーディオデコーダ440に提供する。次いで、これらの選択は選択ユニット432に渡される。選択ユニット432はダウンロード&切替えユニット434に、所望の適応セット、ならびに初期表現選択(たとえば、利用可能なネットワーク帯域幅に基づく)を知らせる。
次いで、ダウンロード&切替えユニット434は、たとえば、HTTP GET要求または部分GET要求をCDN420のサーバに提出することによって、所望の適応セットの各々の1つの表現からデータを取り出す(464)。要求されたデータを受信した後、ダウンロード&切替えユニット434は、取り出されたデータをMPEG-Hオーディオデコーダ440に提供する(466)。シーンデータ抽出ユニット444は、該当するシーンデータを抽出し、スケーラブルオーディオレイヤ復号ユニット446は、様々なレイヤの各々に関するオーディオデータを復号する。最終的に、MPEG-Hオーディオデコーダ440は、復号されたオーディオレイヤをオーディオレンダリングユニット452に提供し、オーディオレンダリングユニット452は、オーディオ出力部454による再生のためにオーディオデータをレンダリングする。オーディオ出力部454は一般に、図1のオーディオ出力部42に対応し得る。たとえば、オーディオ出力部454は、様々な構成による1つまたは複数のスピーカーを含み得る。たとえば、オーディオ出力部454は、シングルスピーカー、左および右ステレオスピーカー、5.1構成スピーカー、7.1構成スピーカー、または3Dオーディオを提供するための様々な高さのスピーカーを含み得る。
一般に、図8および図9に関して上記で説明した様々な技法は、図15のシステムによっても実行され得る。
図16は、本開示の技法による例示的なアーキテクチャを示す概念図である。図16の例は、送信機470と、2つの受信機、受信機482および受信機494とを含む。
送信機470は、ビデオエンコーダ472およびオーディオエンコーダ474を含む。ビデオエンコーダ472はビデオデータ506を符号化する一方、オーディオエンコーダ474はオーディオデータ508を符号化する。この例における送信機470は、複数の表現、たとえば、3つのオーディオ表現、表現1、表現2、および表現3を準備し得る。したがって、符号化されたオーディオデータ508は、表現1、表現2、および表現3の各々に関するオーディオデータを含み得る。ファイルフォーマットカプセル化装置476は、符号化されたビデオデータ506および符号化されたオーディオデータ508を受信し、カプセル化されたデータ510を形成する。DASHセグメント化装置478は、セグメント512を形成し、セグメント512の各々は、カプセル化された、符号化されたオーディオデータまたはビデオデータの別個のセットを含む。ROUTE送信機480は、様々な対応するビットストリームにおいてセグメントを送る。この例では、ビットストリーム514は、すべてのオーディオデータ(たとえば、表現1、2、および3の各々)を含む一方、ビットストリーム514'は、表現1および3を含むが、表現2を省く。
受信機482は、ビデオデコーダ484と、シーン、オブジェクト、およびチャンネルオーディオデコーダ486と、ファイルフォーマットパーサ488と、DASHクライアント490と、ROUTE受信機492とを含む一方、受信機494は、ビデオデコーダ496と、シーンおよびチャンネルオーディオデコーダ498と、ファイルフォーマットパーサ500と、DASHクライアント502と、ROUTE受信機504とを含む。
最終的に、この例では、受信機482は、表現1、表現2、および表現3の各々に関するデータを含むビットストリーム514を受信する。一方、受信機494は、表現1および表現3に関するデータを含むビットストリーム514'を受信する。これは、送信機と受信機494との間のネットワーク状態が、3つの利用可能な表現すべてに関するデータを取り出すのに十分な量の帯域幅を提供しないため、または受信機494に結合されたレンダリングデバイスが表現2からのデータを使用することが可能ではないためであり得る。たとえば、表現2がオーディオデータに関する高さ情報を含むが、受信機494が左/右ステレオシステムと関連付けられている場合、表現2からのデータは、受信機494を介して受信されたオーディオデータをレンダリングするために不必要であり得る。
この例では、ROUTE受信機492は、ビットストリーム514を受信し、DASHクライアント490がセグメントを要求するまで、受信されたセグメントをローカルにキャッシュする。DASHクライアント490は、たとえば、広告された壁時計時間に基づいて、セグメントが利用可能である(または利用可能であるべきである)ことをセグメント利用可能性情報が示すとき、セグメントを要求し得る。次いで、DASHクライアント490は、ROUTE受信機492にセグメントを要求し得る。DASHクライアント490は、ファイルフォーマットパーサ488にセグメント510を送り得る。ファイルフォーマットパーサ488は、セグメントをカプセル化解除し、カプセル化解除されたデータが符号化されたオーディオデータ508に対応するか、それとも符号化されたビデオデータ506に対応するかを判定し得る。ファイルフォーマットパーサ488は、符号化されたオーディオデータ508をシーン、オブジェクト、およびチャンネルオーディオデコーダ486に配信し、符号化されたビデオデータ506をビデオデコーダ484に配信する。
この例では、ROUTE受信機504は、ビットストリーム514'を受信し、DASHクライアント502がセグメントを要求するまで、受信されたセグメントをローカルにキャッシュする。DASHクライアント502は、たとえば、広告された壁時計時間に基づいて、セグメントが利用可能である(または利用可能であるべきである)ことをセグメント利用可能性情報が示すとき、セグメントを要求し得る。次いで、DASHクライアント502は、ROUTE受信機504にセグメントを要求し得る。DASHクライアント502は、ファイルフォーマットパーサ500にセグメント510'を送り得る。ファイルフォーマットパーサ500は、セグメントをカプセル化解除し、カプセル化解除されたデータが(上記で説明したように、表現2を省く)符号化されたオーディオデータ508'に対応するか、それとも符号化されたビデオデータ506に対応するかを判定し得る。ファイルフォーマットパーサ500は、符号化されたオーディオデータ508'をシーンおよびチャンネルオーディオデコーダ498に配信し、符号化されたビデオデータ506をビデオデコーダ496に配信する。
本開示の技法は、様々な使用事例において適用され得る。たとえば、本開示の技法は、2つ以上の異なる受信機のためにデバイススケーラビリティをもたらすために使用され得る。別の例として、オブジェクトフローおよび/または異なるスケーラブルオーディオレイヤのためのフローは、異なるトランスポートセッションによって搬送され得る。また別の例として、本技法は、レガシー受信機がベースレイヤのみを取り出し得る一方、先進的な受信機がベースレイヤおよび1つまたは複数のエンハンスメントレイヤにアクセスし得るという点で、後方互換性をサポートし得る。さらに、上記で説明したように、メディアデータのブロードバンド、ブロードキャスト/マルチキャスト、および/またはユニキャスト受信は、(ハイブリッドスケーラビリティとして説明され得る)品質向上をサポートするために組み合わされ得る。その上、これらの技法は、8K信号およびHDR拡張レイヤ、スケーラブルオーディオ、ならびに/またはリアルタイムベースレイヤおよびNRTエンハンスメントレイヤの技法の組合せなど、将来の技術をサポートし得る。これらの使用事例の各々は、スタック全体にわたる機能的分離に起因してDASH/ROUTEによってサポートされ得る。
このようにして、図16は、オーディオデータを取り出すためのデバイス(受信機482、494)の例を表し、デバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。
図17は、本開示の技法による例示的なクライアントデバイス520を示すブロック図である。クライアントデバイス520は、ネットワークインターフェース522を含み、ネットワークインターフェース522は一般に、インターネットなどのコンピュータベースのネットワークへの接続を提供する。ネットワークインターフェース522は、たとえば、1つまたは複数のネットワークインターフェースカード(NIC)を含むことができ、NICは、イーサネット(登録商標）および/またはIEEE 802.11a、b、g、nなどのような1つもしくは複数のワイヤレスネットワーク規格など、様々なネットワークプロトコルに従って動作し得る。
クライアントデバイス520は、DASHクライアント524をも含む。DASHクライアント524は一般に、DASH技法を実装する。この例では、クライアントデバイス520はDASHクライアント524を含むが、他の例では、クライアントデバイス520は、たとえば、図2に関して上記で説明したように、DASHクライアント524に加えてミドルウェアユニットを含み得る。一般に、DASHクライアント524は、たとえば、以下で説明するように、オーディオコントローラ530およびビデオコントローラ540によって指示されるように、メディアコンテンツの1つまたは複数の適応セットから適切な表現を選択する。
クライアントデバイス520は、それぞれ、オーディオデータおよびビデオデータの選択を制御するためのオーディオコントローラ530およびビデオコントローラ540を含む。オーディオコントローラ530は一般に、上記で説明したように、本開示の技法に従って動作する。たとえば、オーディオコントローラ530は、利用可能なオーディオデータを表す(たとえば、MPEG-Hメタデータからなど、MPDまたは他のデータ構造からの)メタデータを受信するように構成され得る。利用可能なオーディオデータは、シーンベースのオーディオ、チャンネルベースのオーディオ、オブジェクトベースのオーディオ、またはそれらの任意の組合せを含み得る。その上、上記で説明したように、シーンベースのオーディオは、スケーラブルである、すなわち、複数のレイヤを有することができ、複数のレイヤは、別個のそれぞれの適応セットにおいて提供され得る。一般に、オーディオコントローラ530のオーディオメタデータ処理ユニット532は、どのタイプのオーディオデータが利用可能であるかを判定する。
オーディオメタデータ処理ユニット532は、API536と対話し、API536は、ユーザインターフェース550のうちの1つまたは複数とオーディオメタデータ処理ユニット532との間のインターフェースを提供する。たとえば、ユーザインターフェース550は、ユーザから入力を受信し、ユーザにオーディオ出力および/またはビデオ出力を提供するための、ディスプレイ、1つもしくは複数のスピーカー、キーボード、マウス、ポインタ、トラックパッド、タッチスクリーン、遠隔制御装置、マイクロフォン、スイッチ、ダイヤル、スライダーなどのうちの1つまたは複数を含み得る。したがって、ユーザは、ユーザインターフェース550を介して所望のオーディオデータおよびビデオデータを選択し得る。
たとえば、ユーザは、様々な構成のいずれかにおいて、クライアントデバイス520に1つまたは複数のスピーカーを接続し得る。そのような構成は、シングルスピーカー、ステレオスピーカー、3.1サラウンド、5.1サラウンド、7.1サラウンド、または3Dオーディオのための複数の高さおよびロケーションのスピーカーを含み得る。したがって、ユーザは、ユーザインターフェース550を介してクライアントデバイス520にスピーカー構成の指示を提供し得る。同様に、ユーザは、ビデオ構成、たとえば、2次元ビデオ、3次元ビデオ、または多次元ビデオ(たとえば、複数の視点を有する3次元ビデオ)の選択を提供し得る。ユーザインターフェース550は、API546を介してビデオコントローラ540と対話することができ、API546は、API536と実質的に同様の方法で、ビデオメタデータ処理ユニット542へのインターフェースを提供する。
したがって、オーディオメタデータ処理ユニット532は、オーディオデータが取り出されるべき適切な適応セットを選択し得る一方、ビデオメタデータ処理ユニット542は、ビデオデータが取り出されるべき適切な適応セットを選択し得る。オーディオメタデータ処理ユニット532およびビデオメタデータ処理ユニット542は、オーディオデータおよびビデオデータが取り出されるべき適応セットの指示をDASHクライアント524に提供し得る。次に、DASHクライアント524は、適応セットの表現を選択し、選択された表現からメディアデータ(それぞれ、オーディオデータまたはビデオデータ)を取り出す。DASHクライアント524は、たとえば、利用可能なネットワーク帯域幅、適応セットの優先度などに基づいて、表現を選択し得る。DASHクライアント524は、選択された表現からネットワークインターフェース522を介してデータに対するHTTP GET要求または部分GET要求を提出し、要求に応答して、要求されたデータをネットワークインターフェース522を介して受信し得る。次いで、DASHクライアント524は、受信されたデータをオーディオコントローラ530またはビデオコントローラ540に提供し得る。
オーディオデコーダ534は、DASHクライアント524から受信されたオーディオデータを復号し、ビデオデコーダ544は、DASHクライアント524から受信されたビデオデータを復号する。オーディオデコーダ534は、復号されたオーディオデータをオーディオレンダラ538に提供する一方、ビデオデコーダ544は、復号されたビデオデータをビデオレンダラ548に提供する。オーディオレンダラ538は、復号されたオーディオデータをレンダリングし、ビデオレンダラ548は、復号されたビデオデータをレンダリングする。オーディオレンダラ538は、レンダリングされたオーディオデータを、提示のためにユーザインターフェース550に提供する一方、ビデオレンダラ548は、レンダリングされたビデオデータを、提示のためにユーザインターフェース550に提供する。
このようにして、図17は、オーディオデータを取り出すためのデバイスの例を表し、デバイスは、複数の利用可能な適応セットを表す利用可能性データを受信することであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供することとを行うように構成された1つまたは複数のプロセッサと、オーディオ適応セットに関する取り出されたデータを記憶するように構成されたメモリとを含む。
図18は、本開示の技法を実行するための例示的な方法を示すフローチャートである。この例では、方法は、サーバデバイスおよびクライアントデバイスに関して説明される。例および説明として、サーバデバイスのアクションは、サーバデバイス60(図1)に関して述べられ、クライアントデバイスのアクションは、クライアントデバイス40(図1)に関して述べられる。しかしながら、他のサーバデバイスおよびクライアントデバイスが述べられる機能を実行するように構成されてよいことを理解されたい。
最初に、サーバデバイス60は、オーディオデータを符号化する(560)。たとえば、オーディオエンコーダ26(図1)、MPEG-Hオーディオエンコーダ212(図5〜図7)、またはオーディオエンコーダ474(図16)は、シーンオーディオデータ、チャンネルオーディオデータ、スケーラブルオーディオデータ、および/またはオブジェクトオーディオデータなどのオーディオデータを符号化する。サーバデバイス60はまた、たとえば、ISO BMFFなど、オーディオデータをストリーミングするために使用されるべきファイルフォーマットに、オーディオデータをカプセル化する(562)。具体的には、カプセル化ユニット30(図1)、マルチプレクサ216(図5、図6)、ブロードキャストファイルトランスポートパッケージャ378(図11)、またはファイルフォーマットカプセル化装置476(図16)は、符号化されたオーディオデータを、たとえば、ISO BMFFに従ってフォーマットされたセグメントなど、トランスポート可能なファイルにカプセル化する。サーバデバイス60はまた、利用可能性データを符号化する(564)。利用可能性データは、DASHのMPDなどのマニフェストファイルに含まれ得る。利用可能性データ自体は、たとえば、MPEG-H 3D Audioなどのオーディオ符号化フォーマットに従ってフォーマットされ得る。したがって、サーバデバイス60はクライアントデバイス40に、マニフェストファイルにおいて利用可能性データを送り得る(566)。
クライアントデバイス40は、マニフェストファイル、ひいては利用可能性データを受信し得る(568)。以下でより詳細に説明するように、クライアントデバイス40のDASHクライアントは、マニフェストファイルを受信し、利用可能性データを抽出し得る。ただし、利用可能性データは、MPEG-H 3D Audioなどのオーディオ符号化フォーマットに従ってフォーマットされ得るので、DASHクライアントは、(図1のオーディオデコーダ46などの)MPEG-H 3D Audioデコーダに利用可能性データを送り得る。次いで、クライアントデバイス40は、利用可能性データから取り出されるべきオーディオデータを決定し得る(570)。たとえば、以下で説明するように、DASHクライアントは、たとえば、(図1のオーディオデコーダ46などの)MPEG-H 3D Audioデコーダから、メディアデータを取り出すべき適応セットを示す命令データを受信し得る。クライアントデバイス40は、命令データに従って、決定されたオーディオデータを要求し得る(572)。
一例では、クライアントデバイス40は、すべての利用可能なオーディオ適応セットからのオーディオデータを要求し得るが、選択されていない適応セット(すなわち、たとえば、MPEG-H 3D Audioデコーダから受信された命令データの選択データによって識別されない適応セット)の最低ビットレート表現からのオーディオデータのみを要求し得る。この例では、クライアントデバイス40は、選択された適応セットに対する帯域幅適応を実行し得る。このようにして、ユーザ選択が変わった場合、クライアントデバイス40は、少なくとも一部のオーディオデータに直ちにアクセスすることができ、新しく選択された適応セットに対する帯域幅適応を実行すること(たとえば、新しく選択された適応セットに関するより高いビットレートの表現からオーディオデータを取り出すこと)を始め得る。
別の例では、クライアントデバイス40は、単に、選択された適応セットからのオーディオデータを要求するだけであり、選択されていない適応セットに関するいかなるオーディオデータを要求することも回避することができる。
いずれの場合でも、サーバデバイス60は、オーディオデータに対する要求を受信し得る(574)。次いで、サーバデバイス60はクライアントデバイス40に、要求されたオーディオデータを送り得る(576)。あるいは、別の例では、サーバデバイス60は、ネットワークブロードキャストもしくはマルチキャスト、またはオーバージエアブロードキャストを介して、クライアントデバイス40にオーディオデータを送信することができ、クライアントデバイス40はミドルウェアユニット(たとえば、図2のeMBMSミドルウェアユニット100)に、選択された適応セットデータを要求し得る。
クライアントデバイス40はオーディオデータを受信し得る(578)。たとえば、DASHクライアントは、要求されたオーディオデータを受信し得る。クライアントデバイス40はまた、オーディオデータを復号し、提示し得る(580)。復号は、オーディオデコーダ46(図1)、MPEG-Hオーディオデコーダ220(図5〜図8)、MPEG-Hオーディオデコーダ220'(図9)、コーデック388(図11)、MPEG-Hオーディオデコーダ440(図15)、シーン、オブジェクト、およびチャンネルオーディオデコーダ486(図16)、シーンおよびチャンネルオーディオデコーダ498(図16)、またはオーディオデコーダ534(図17)によって実行され得る一方、提示は、オーディオ出力部42(図1)、オーディオレンダリングユニット232(図5〜図9)、オーディオ出力部454(図15)、またはユーザインターフェース550(図17)によって実行され得る。
図19は、本開示の技法を実行するための別の例示的な方法を示すフローチャートである。この例では、方法は、DASHクライアントおよびMPEG-Hメタデータ抽出ユニットによって実行されるものとして説明される。図19の例示的な方法は、例としてDASHクライアント280(図8)およびメタデータ抽出ユニット222(図8)に関して述べられる。しかしながら、他の例が実行されてよいことを理解されたい。たとえば、メタデータ抽出ユニットは、図9の例に示すように、MPEG-Hオーディオデコーダとは別個であり得る。
最初に、この例では、DASHクライアント280は、マニフェストファイルを受信する(590)。マニフェストファイルは、たとえば、DASHのMPDファイルを含み得る。次いで、DASHクライアント280は、マニフェストファイルから利用可能性データを抽出し得る(592)。利用可能性データは、MPEG-H 3D Audioに従ってフォーマットされ得る。したがって、DASHクライアント280は、メタデータ抽出ユニット222に利用可能性データを送り得る(594)。
メタデータ抽出ユニット222は利用可能性データを受信し得る(596)。メタデータ抽出ユニットは、どのタイプのオーディオデータが利用可能であるか(たとえば、シーン、チャンネル、オブジェクト、および/またはスケーラブルオーディオデータ)を示し得る利用可能性データを抽出することができ、オーディオデータのセットが取り出されるべき選択を示す選択データを受信するためにユーザに提示するデータのこれらの利用可能なセットの指示を送ることができる(598)。選択データに応答して、メタデータ抽出ユニット222は、取り出されるべき復号可能なデータを含む適応セットの選択を受信し得る(600)。具体的には、メタデータ抽出ユニット222は、取り出されるべきタイプのオーディオデータの選択を受信し、選択されたタイプのオーディオデータと対応する適応セットとの間のマッピングを(利用可能性データを使用して)決定することができる。次いで、メタデータ抽出ユニット222は、オーディオデータが取り出されるべき適応セットを示す命令データをDASHクライアント280に送り得る(602)。
したがって、DASHクライアント280は、命令データを受信し得る(604)。次いで、DASHクライアント280は、選択されたオーディオデータを要求し得る(606)。たとえば、DASHクライアント280は、選択されたオーディオ適応セットに関して(たとえば、帯域幅適応技法を使用して)オーディオデータの比較的高い品質のセットを取り出し、選択されていないオーディオ適応セットに関して比較的低い品質または最低の利用可能なビットレートの表現を取り出すことができる。あるいは、DASHクライアント280は、選択されたオーディオ適応セットに関するオーディオデータのみを取り出し、選択されていないオーディオ適応セットに関するオーディオデータをまったく取り出さないことがある。
いくつかの例では、DASHクライアント280は、選択されたオーディオ適応セットに関する相対的品質レベルの指示を受信し得る。たとえば、ある適応セットの相対的品質を別のものと比較する相対的品質レベル。この例では、ある適応セットが、選択データによって示されるように、別のものよりも高い相対的品質値を有する場合、DASHクライアント280は、より高い相対的品質値を有する適応セットに関する比較的高いビットレートの表現からオーディオデータを取り出すことを優先し得る。
いずれの場合でも、次いで、DASHクライアント280は、要求されたオーディオデータを受信し得る(608)。たとえば、DASHクライアント280は、要求されたオーディオデータを外部のサーバデバイスから(たとえば、要求が、外部のサーバデバイスに送られたユニキャスト要求であった場合)、またはミドルウェアユニットから(たとえば、ミドルウェアユニットが最初に、オーディオデータを受信しており、受信されたオーディオデータを、DASHクライアント280による後の取出しのためにキャッシュした場合)受信し得る。次いで、DASHクライアント280は、受信されたオーディオデータをMPEG-Hオーディオデコーダに送り得る(610)。MPEG-Hオーディオデコーダは、(図8の例に示すように)メタデータ抽出ユニット222を含んでよく、または(図9の例に示すように)メタデータ抽出ユニット222'とは別個であり得る。
このようにして、図19の方法は、複数の利用可能な適応セットを表す利用可能性データを受信するステップであって、利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、ステップと、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信するステップと、選択データによって識別された適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データをストリーミングクライアントに提供するステップとを含む、オーディオデータを取り出す方法の例を表す。
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得、またはコンピュータ可読媒体を介して送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は一般に、(1)非一時的である有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品がコンピュータ可読媒体を含み得る。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路構成もしくは個別論理回路構成などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明した技法の実装に適した任意の他の構造のいずれかを指すことがある。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび/もしくはソフトウェアモジュール内で提供されることがあり、または複合コーデックに組み込まれることがある。また、技法は、1つまたは複数の回路または論理要素において完全に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、様々なデバイスまたは装置において実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが説明されているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニットにおいて結合されることがあり、または適切なソフトウェアおよび/もしくはファームウェアとともに、上記で説明したような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されることがある。
様々な例が記載されている。これらおよび他の例は、以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力部
44 ビデオ出力部
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A〜68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
100 eMBMSミドルウェアユニット
102 サーバユニット、プロキシサーバ
104 キャッシュ
106 eMBMS受信ユニット
110 DASHクライアント
112 メディアアプリケーション
120 マルチメディアコンテンツ
122 メディアプレゼンテーション記述(MPD)
122B MPD
124 表現
124A〜124N 表現
124B 表現
124BA 表現
124BB 表現
124BC 表現
124BD 表現
126 ヘッダデータ
126BA ヘッダデータタイプ0
126BB ヘッダデータタイプ1
126BC ヘッダデータタイプ2
126BD ヘッダデータタイプ3
128 セグメント
128A〜128N セグメント
128BA〜128BN タイプ0セグメント
128CA〜128CN タイプ1セグメント
128DA〜128DN タイプ2セグメント
128EA〜128EN タイプ3セグメント
130 ヘッダデータ
132 セグメント
132A〜132N セグメント
150 メディアファイル
152 ファイルタイプ(FTYP)ボックス
154 ムービー(MOOV)ボックス
156 ムービーヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 ムービー延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス、SIDXボックス
164 ムービーフラグメント(MOOF)ボックス、ムービーフラグメント
166 ムービーフラグメントランダムアクセス(MFRA)ボックス
200 システム
202 オブジェクトベースのコンテンツ
202' オーディオベースのコンテンツ
204 メタデータ
206 シーンデータ
208 チャンネルデータ
210 オブジェクトデータ
212 MPEG-Hオーディオエンコーダ
214 オーディオエンコーダ
216 マルチプレクサ
218 符号化され多重化されたオーディオデータ、ストリーム
220 MPEG-Hオーディオデコーダ
220' MPEG-Hオーディオデコーダ
222 メタデータ抽出ユニット
222' メタデータ抽出ユニット
224 シーンデータ抽出ユニット
226 オブジェクトデータ抽出ユニット
228 ユーザインターフェース
230 アプリケーションプログラミングインターフェース(API)
232 オーディオレンダリングユニット
240 ストリーム
242 ストリーム、補助ストリーム
242A〜242N ストリーム
250 システム
252 メディアサーバ
254 符号化されたメタデータ
256 シーンおよびチャンネル適応セット、シーン&チャンネル適応セット
258 表現
258A〜258M 表現
260 オブジェクト適応セット
260A〜260N オブジェクト適応セット
262 表現
262A〜262P 表現
264 表現
264A〜264Q 表現
270 メディアプレゼンテーション記述(MPD)
274 要素
274' 対話
280 DASHクライアント
282 選択ユニット
284 ダウンロード&切替えユニット
350 システム
352 メディアサーバ
354 ブロードキャストサーバ
356 ブロードキャスト送信機
358 HTTPコンテンツ配信ネットワーク(CDN)、CDN
360 サーバデバイス
360A〜360N サーバデバイス
362 eNode-B
364 クライアントデバイス
364A〜364N ユーザ機器(UE)クライアントデバイス
370 システム
372 ユニフォームタイムコード(UTC)ソース
374 ローカルUTCソース
376 ブロードキャストDASHサーバ
378 ブロードキャストファイルトランスポートパッケージャ
380 ブロードキャストファイルトランスポート受信機
382 MPDおよびメディアデータ
382' MPDおよびメディアデータ
384 DASHプレーヤ
386 CDN
388 コーデック
390 時間整合された圧縮済みメディアデータ
392 時間整合されたメディアサンプルおよびピクセル
400 概念プロトコルモデル、モデル
402 物理レイヤ
404 インターネットプロトコル(IP)データ
406 ユニフォームデータグラムプロトコル(UDP)データおよび伝送制御プロトコル(TCP)データ
408 配信レイヤ
410 符号化、フォーマッティング、およびサービス管理データ
412 リニアおよびアプリケーションベースのサービス
420 CDN
421 MPD
422 シーンベースのスケーラブルオーディオコンテンツ
424 符号化されたメタデータ
426 シーンベースのオーディオ、ベースレイヤ適応セット
428 適応セット、シーンベースのオーディオ、エンハンスメントレイヤ適応セット
428A〜428N シーンベースのオーディオ、エンハンスメントレイヤ適応セット
430 DASHクライアント
432 選択ユニット
434 ダウンロード&切替えユニット
440 MPEG-Hオーディオデコーダ
442 メタデータ抽出ユニット
444 シーンデータ抽出ユニット
446 スケーラブルオーディオレイヤ復号ユニット
448 ユーザインターフェース
450 API
452 オーディオレンダリングユニット
454 オーディオ出力部
470 送信機
472 ビデオエンコーダ
474 オーディオエンコーダ
476 ファイルフォーマットカプセル化装置
478 DASHセグメント化装置
480 ROUTE送信機
482 受信機
484 ビデオデコーダ
486 シーン、オブジェクト、およびチャンネルオーディオデコーダ
488 ファイルフォーマットパーサ
490 DASHクライアント
492 ROUTE受信機
494 受信機
496 ビデオデコーダ
498 シーンおよびチャンネルオーディオデコーダ
500 ファイルフォーマットパーサ
502 DASHクライアント
504 ROUTE受信機
506 ビデオデータ、符号化されたビデオデータ
508 オーディオデータ、符号化されたオーディオデータ
508' 符号化されたオーディオデータ
510 カプセル化されたデータ、セグメント
510' セグメント
512 セグメント
514 ビットストリーム
514' ビットストリーム
520 クライアントデバイス
522 ネットワークインターフェース
524 DASHクライアント
530 オーディオコントローラ
532 オーディオメタデータ処理ユニット
534 オーディオデコーダ
536 API
538 オーディオレンダラ
540 ビデオコントローラ
542 ビデオメタデータ処理ユニット
544 ビデオデコーダ
546 API
548 ビデオレンダラ
550 ユーザインターフェース
700 マルチレイヤオーディオデータ
702 ベースサブレイヤ、ベースレイヤ
704 第1のエンハンスメントサブレイヤ、第2のレイヤ
706 第2のエンハンスメントサブレイヤ、第3のレイヤ
710 マルチレイヤオーディオデータ
712 ベースサブレイヤ、ベースレイヤ
714 第1のエンハンスメントレイヤ、第2のレイヤ
716 第2のエンハンスメントレイヤ、第3のレイヤ

Claims (40)

  1. オーディオデータを取り出す方法であって、
    複数の利用可能な適応セットを表す利用可能性データを受信するステップであって、前記利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、ステップと、
    前記シーンベースのオーディオ適応セットおよび前記1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信するステップと、
    前記選択データによって識別された前記適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データを前記ストリーミングクライアントに提供するステップと
    を含む、方法。
  2. 前記複数の利用可能な適応セットは、複数の利用可能なスケーラブルオーディオ適応セットを含み、前記複数のスケーラブルオーディオ適応セットの各々は、スケーラブルオーディオデータのそれぞれのレイヤに対応する、請求項1に記載の方法。
  3. 前記ストリーミングクライアントは、第1のデータフォーマットを定めるストリーミングプロトコルに従って、前記選択データによって識別された前記適応セットの各々に関する前記データを取り出すように構成され、前記利用可能性データは、前記ストリーミングプロトコルによって定められた前記第1のデータフォーマットとは異なる第2のデータフォーマットに従ってフォーマットされる、請求項1に記載の方法。
  4. 前記ストリーミングプロトコルは、動的適応ストリーミングオーバーHTTP(DASH)を含み、
    前記第1のデータフォーマットは、ISOベースメディアファイルフォーマット(ISO BMFF)、前記ISO BMFFの拡張、またはMPEG-2トランスポートストリーム(MPEG-2 TS)のうちの1つを含み、
    前記第2のデータフォーマットは、MPEG-H 3D Audioを含む、請求項3に記載の方法。
  5. 前記利用可能性データを受信するステップは、前記ストリーミングクライアントから前記利用可能性データを受信するステップを含む、請求項1に記載の方法。
  6. 前記選択データを受信するステップは、ユーザインターフェースから前記選択データを受信するステップを含む、請求項1に記載の方法。
  7. 前記命令データを提供するステップは、前記ストリーミングクライアントに、前記選択データによって識別された前記適応セットに関するデータのみを取り出させ、前記選択データによって識別されない適応セットに関するいかなるデータの取出しも回避させるための前記命令データを提供するステップを含む、請求項1に記載の方法。
  8. 前記命令データを提供するステップは、前記ストリーミングクライアントに、前記選択データによって識別された前記適応セットに対する帯域幅適応を実行させ、前記選択データによって識別されない前記利用可能な適応セットの最低の利用可能なビットレートを有する表現からデータを取り出させるための前記命令データを提供するステップを含む、請求項1に記載の方法。
  9. 取り出されるべきである前記適応セットのうちの少なくとも1つに関する相対的品質を表す品質データを受信するステップをさらに含み、前記命令データを提供するステップは、前記相対的品質に対応する前記適応セットのうちの前記少なくとも1つの表現を前記ストリーミングクライアントに取り出させるための前記命令データを形成するステップを含む、請求項1に記載の方法。
  10. 前記品質データを受信するステップは、前記適応セットのうちの前記少なくとも1つに関する相対的ボリュームを受信するステップを含み、前記方法は、前記適応セットのうちの前記少なくとも1つに関する前記相対的ボリュームが、前記選択データによって識別された他の適応セットに関する相対的ボリュームよりも高いとの判定に応答して、前記選択データによって識別された前記他の適応セットの表現に関するビットレートよりも比較的高いビットレートを有する前記少なくとも1つの適応セットの表現を前記ストリーミングクライアントに取り出させるための前記命令データを形成するステップをさらに含む、請求項9に記載の方法。
  11. 前記選択データによって識別された前記適応セットの各々に関して取り出されるべき表現を識別するための前記命令データを形成するステップをさらに含む、請求項1に記載の方法。
  12. 前記ストリーミングクライアントによって、前記命令データを受信する前に前記利用可能な適応セットの各々に関するデータを取り出すステップをさらに含む、請求項1に記載の方法。
  13. 前記命令データに応答して、前記ストリーミングクライアントによって、
    取り出されるべきではない前記利用可能な適応セットのうちの少なくとも1つを決定するステップと、
    前記命令データを受信する前に前記利用可能な適応セットのうちの前記少なくとも1つに割り振られた帯域幅の量を判定するステップと、
    前記命令データに従って取り出されるべき前記適応セットのうちの1つまたは複数に、帯域幅の前記判定された量を割り振るステップと、
    帯域幅の前記割り振られた量に基づいて、取り出されるべき前記適応セットのうちの1つまたは複数に関する表現選択を調整するステップと
    をさらに含む、請求項12に記載の方法。
  14. 前記ストリーミングクライアントによって、前記利用可能性データを含むマニフェストファイルを受信するステップをさらに含む、請求項1に記載の方法。
  15. 前記マニフェストファイルは、メディアプレゼンテーション記述(MPD)を含む、請求項14に記載の方法。
  16. 前記ストリーミングクライアントによって、前記命令データに従ってデータを取り出すことを求めるそれぞれのHTTP GET要求または部分GET要求を送るステップをさらに含む、請求項1に記載の方法。
  17. 前記ストリーミングクライアントは、動的適応ストリーミングオーバーHTTP(DASH)クライアントを含む、請求項1に記載の方法。
  18. 前記ストリーミングクライアントは、ブロードキャストまたはマルチキャスト受信ユニットおよびプロキシサーバをさらに含むミドルウェアユニットに含まれ、前記方法は、前記ストリーミングクライアントによって、前記プロキシサーバからユニキャストを介して前記命令データに従って、キャッシュされたメディアデータを取り出すステップをさらに含む、請求項1に記載の方法。
  19. オーディオデータを取り出すためのデバイスであって、
    複数の利用可能な適応セットを表す利用可能性データを受信することであって、前記利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、
    前記シーンベースのオーディオ適応セットおよび前記1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、
    前記選択データによって識別された前記適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データを前記ストリーミングクライアントに提供することと
    を行うように構成された1つまたは複数のプロセッサと、
    前記オーディオ適応セットに関する前記取り出されたデータを記憶するように構成されたメモリと
    を含む、デバイス。
  20. 前記複数の利用可能な適応セットは、複数の利用可能なスケーラブルオーディオ適応セットを含み、前記複数のスケーラブルオーディオ適応セットの各々は、スケーラブルオーディオデータのそれぞれのレイヤに対応する、請求項19に記載のデバイス。
  21. 前記ストリーミングクライアントは、第1のデータフォーマットを定めるストリーミングプロトコルに従って、前記選択データによって識別された前記適応セットの各々に関する前記データを取り出すように構成され、前記利用可能性データは、前記ストリーミングプロトコルによって定められた前記第1のデータフォーマットとは異なる第2のデータフォーマットに従ってフォーマットされる、請求項19に記載のデバイス。
  22. ユーザ定義のアクションに基づくユーザ提供の選択データを受信し、前記1つまたは複数のプロセッサに前記選択データを提供するように構成されたユーザインターフェースをさらに含む、請求項19に記載のデバイス。
  23. 前記ストリーミングクライアントは、ヘッダデータを含むメディアデータに対する要求をサーバデバイスに送るように構成された動的適応ストリーミングオーバーHTTP(DASH)クライアントを含む、請求項19に記載のデバイス。
  24. 前記DASHクライアントは、前記ヘッダデータを含む前記メディアデータを前記サーバデバイスから受信するように構成される、請求項23に記載のデバイス。
  25. シーンベースのオーディオデータ、チャンネルベースのオーディオデータ、またはオブジェクトベースのオーディオデータのうちの少なくとも1つを復号するように構成されたMPEG-H(Moving Pictures Experts Group)Audioデコーダをさらに含む、請求項19に記載のデバイス。
  26. 前記1つまたは複数のプロセッサは、MPEG-Hオーディオデコーダを含む、請求項19に記載のデバイス。
  27. 前記1つまたは複数のプロセッサは、MPEG-Hオーディオデコーダのメタデータ処理ユニットを含む、請求項19に記載のデバイス。
  28. MPEG-Hオーディオデコーダをさらに含み、前記1つまたは複数のプロセッサは、前記MPEG-Hオーディオデコーダとは別個のメタデータ処理ユニットを含む、請求項19に記載のデバイス。
  29. オーディオデータを取り出すためのデバイスであって、
    複数の利用可能な適応セットを表す利用可能性データを受信するための手段であって、前記利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、手段と、
    前記シーンベースのオーディオ適応セットおよび前記1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信するための手段と、
    前記選択データによって識別された前記適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データを前記ストリーミングクライアントに提供するための手段と
    を含む、デバイス。
  30. 前記複数の利用可能な適応セットは、複数の利用可能なスケーラブルオーディオ適応セットを含み、前記複数のスケーラブルオーディオ適応セットの各々は、スケーラブルオーディオデータのそれぞれのレイヤに対応する、請求項29に記載のデバイス。
  31. 前記ストリーミングクライアントは、第1のデータフォーマットを定めるストリーミングプロトコルに従って、前記選択データによって識別された前記適応セットの各々に関する前記データを取り出すように構成され、前記利用可能性データは、前記ストリーミングプロトコルによって定められた前記第1のデータフォーマットとは異なる第2のデータフォーマットに従ってフォーマットされる、請求項29に記載のデバイス。
  32. 前記選択データを受信するための前記手段は、ユーザインターフェースから前記選択データを受信するための手段を含む、請求項29に記載のデバイス。
  33. 前記命令データを提供するための前記手段は、前記ストリーミングクライアントに、前記選択データによって識別された前記適応セットに関するデータのみを取り出させ、前記選択データによって識別されない適応セットに関するいかなるデータの取出しも回避させるための前記命令データを提供するための手段を含む、請求項29に記載のデバイス。
  34. 前記ストリーミングクライアントは、ヘッダデータを含むメディアデータに対する要求をサーバデバイスに送るように構成された動的適応ストリーミングオーバーHTTP(DASH)クライアントを含む、請求項29に記載のデバイス。
  35. 実行されたときに、プロセッサに、
    複数の利用可能な適応セットを表す利用可能性データを受信することであって、前記利用可能な適応セットは、シーンベースのオーディオ適応セットおよび1つまたは複数のオブジェクトベースのオーディオ適応セットを含む、受信することと、
    前記シーンベースのオーディオ適応セットおよび前記1つまたは複数のオブジェクトベースのオーディオ適応セットのうちのどれが取り出されるべきであるかを識別する選択データを受信することと、
    前記選択データによって識別された前記適応セットの各々に関するデータをストリーミングクライアントに取り出させるための命令データを前記ストリーミングクライアントに提供することと
    を行わせる命令を記憶している、コンピュータ可読記憶媒体。
  36. 前記複数の利用可能な適応セットは、複数の利用可能なスケーラブルオーディオ適応セットを含み、前記複数のスケーラブルオーディオ適応セットの各々は、スケーラブルオーディオデータのそれぞれのレイヤに対応する、請求項35に記載のコンピュータ可読記憶媒体。
  37. 前記ストリーミングクライアントは、第1のデータフォーマットを定めるストリーミングプロトコルに従って、前記選択データによって識別された前記適応セットの各々に関する前記データを取り出すように構成され、前記利用可能性データは、前記ストリーミングプロトコルによって定められた前記第1のデータフォーマットとは異なる第2のデータフォーマットに従ってフォーマットされる、請求項35に記載のコンピュータ可読記憶媒体。
  38. 前記プロセッサに、前記選択データを受信することを行わせる前記命令は、前記プロセッサに、ユーザインターフェースから前記選択データを受信することを行わせる命令を含む、請求項35に記載のコンピュータ可読記憶媒体。
  39. 前記ストリーミングクライアントは、第1のデータフォーマットを定めるストリーミングプロトコルに従って、前記選択データによって識別された前記適応セットの各々に関する前記データを取り出すように構成され、前記利用可能性データは、前記ストリーミングプロトコルによって定められた前記第1のデータフォーマットとは異なる第2のデータフォーマットに従ってフォーマットされる、請求項35に記載のコンピュータ可読記憶媒体。
  40. 前記ストリーミングクライアントは、ヘッダデータを含むメディアデータに対する要求をサーバデバイスに送るように構成された動的適応ストリーミングオーバーHTTP(DASH)クライアントを含む、請求項35に記載のコンピュータ可読記憶媒体。
JP2018509888A 2015-08-25 2016-08-25 コーディングされたオーディオデータのトランスポート Active JP6845223B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201562209779P 2015-08-25 2015-08-25
US201562209764P 2015-08-25 2015-08-25
US62/209,779 2015-08-25
US62/209,764 2015-08-25
US15/246,370 2016-08-24
US15/246,370 US10693936B2 (en) 2015-08-25 2016-08-24 Transporting coded audio data
PCT/US2016/048740 WO2017035376A2 (en) 2015-08-25 2016-08-25 Transporting coded audio data

Publications (3)

Publication Number Publication Date
JP2018532146A true JP2018532146A (ja) 2018-11-01
JP2018532146A5 JP2018532146A5 (ja) 2020-09-03
JP6845223B2 JP6845223B2 (ja) 2021-03-17

Family

ID=58097069

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018509888A Active JP6845223B2 (ja) 2015-08-25 2016-08-25 コーディングされたオーディオデータのトランスポート

Country Status (8)

Country Link
US (1) US10693936B2 (ja)
EP (1) EP3342174A2 (ja)
JP (1) JP6845223B2 (ja)
KR (1) KR102179269B1 (ja)
CN (1) CN107925797B (ja)
CA (1) CA2992599C (ja)
TW (1) TWI729997B (ja)
WO (1) WO2017035376A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230003091A (ko) * 2021-05-05 2023-01-05 텐센트 아메리카 엘엘씨 오디오 장면의 관심 공간을 표현하기 위한 방법 및 장치
JP2023533414A (ja) * 2021-06-02 2023-08-03 テンセント・アメリカ・エルエルシー 適応オーディオ配信およびレンダリング

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2016269886B2 (en) 2015-06-02 2020-11-12 Sony Corporation Transmission device, transmission method, media processing device, media processing method, and reception device
EP3357259B1 (en) * 2015-09-30 2020-09-23 Dolby International AB Method and apparatus for generating 3d audio content from two-channel stereo content
US9854375B2 (en) 2015-12-01 2017-12-26 Qualcomm Incorporated Selection of coded next generation audio data for transport
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10574718B2 (en) * 2016-08-25 2020-02-25 Comcast Cable Communications, Llc Packaging content for delivery
US10834164B2 (en) * 2017-02-08 2020-11-10 Wyse Technology L.L.C. Virtualizing audio and video devices using synchronous A/V streaming
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
CN109792394B (zh) 2017-08-15 2021-05-11 谷歌有限责任公司 使用多播的流式带宽的优化利用
US10891960B2 (en) * 2017-09-11 2021-01-12 Qualcomm Incorproated Temporal offset estimation
US11310540B2 (en) * 2017-11-10 2022-04-19 Qualcomm Incorporated Interfaces between dash aware application and dash client for service interactivity support
US11321516B2 (en) * 2018-01-19 2022-05-03 Qualcomm Incorporated Processing dynamic web content of an ISO BMFF web resource track
US10264386B1 (en) * 2018-02-09 2019-04-16 Google Llc Directional emphasis in ambisonics
CN115691519A (zh) * 2018-02-22 2023-02-03 杜比国际公司 用于处理嵌入在mpeg-h 3d音频流中的辅媒体流的方法及设备
EP3780627A1 (en) 2018-03-29 2021-02-17 Sony Corporation Information processing device, information processing method, and program
US11323757B2 (en) 2018-03-29 2022-05-03 Sony Group Corporation Information processing apparatus, information processing method, and program
US11082728B2 (en) 2018-08-31 2021-08-03 Electronics And Telecommunications Research Institute Method and apparatus for providing broadcast service based on scalable codec
CN111223302B (zh) * 2018-11-23 2021-12-03 明创能源股份有限公司 移动载具用外部坐标实时三维路况辅助装置及该系统
US11381867B2 (en) * 2019-01-08 2022-07-05 Qualcomm Incorporated Multiple decoder interface for streamed media data
CN111510756A (zh) * 2019-01-30 2020-08-07 上海哔哩哔哩科技有限公司 音视频的切换方法、装置、计算机设备及可读存储介质
IL289261B2 (en) 2019-07-02 2024-07-01 Dolby Int Ab Methods, devices and systems for displaying, encoding and interpreting discontinuous directional data
US11140503B2 (en) * 2019-07-03 2021-10-05 Qualcomm Incorporated Timer-based access for audio streaming and rendering
US11509972B2 (en) 2019-07-09 2022-11-22 Dolby International Ab Method and device for personalization of media data for playback
EP4002358A4 (en) * 2019-07-19 2023-03-22 Intellectual Discovery Co., Ltd. ADAPTIVE AUDIO PROCESSING METHOD, DEVICE, COMPUTER PROGRAM AND ASSOCIATED RECORDING MEDIA IN A WIRELESS COMMUNICATION SYSTEM
CN114731459A (zh) * 2019-11-20 2022-07-08 杜比国际公司 用于个性化音频内容的方法和设备
TWI739429B (zh) * 2020-05-14 2021-09-11 許祐豪 喇叭聲道音訊控制系統
CN113923264A (zh) * 2021-09-01 2022-01-11 赛因芯微(北京)电子科技有限公司 基于场景音频通道元数据和生成方法、设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2451956A1 (en) 2001-07-19 2003-01-30 British Telecommunications Public Limited Company Video stream switching
WO2007112384A2 (en) * 2006-03-27 2007-10-04 Vidyo, Inc. System and method for management of scalability information in scalable video and audio coding systems using control messages
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US8315396B2 (en) 2008-07-17 2012-11-20 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Apparatus and method for generating audio output signals using object based metadata
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US9357275B2 (en) * 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data
MX342150B (es) 2012-07-09 2016-09-15 Koninklijke Philips Nv Codificacion y decodificacion de señales de audio.
US9954717B2 (en) * 2012-07-11 2018-04-24 Futurewei Technologies, Inc. Dynamic adaptive streaming over hypertext transfer protocol as hybrid multirate media description, delivery, and storage format
US9804668B2 (en) 2012-07-18 2017-10-31 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear TV experience using streaming content distribution
GB2512310A (en) * 2013-03-25 2014-10-01 Sony Corp Media Distribution
US10499176B2 (en) * 2013-05-29 2019-12-03 Qualcomm Incorporated Identifying codebooks to use when coding spatial components of a sound field
WO2015104451A1 (en) * 2014-01-07 2015-07-16 Nokia Technologies Oy Method and apparatus for video coding and decoding
US20150199498A1 (en) * 2014-01-10 2015-07-16 Furturewei Technologies, Inc. Flexible and efficient signaling and carriage of authorization acquisition information for dynamic adaptive streaming
US9854375B2 (en) 2015-12-01 2017-12-26 Qualcomm Incorporated Selection of coded next generation audio data for transport

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230003091A (ko) * 2021-05-05 2023-01-05 텐센트 아메리카 엘엘씨 오디오 장면의 관심 공간을 표현하기 위한 방법 및 장치
JP2023529788A (ja) * 2021-05-05 2023-07-12 テンセント・アメリカ・エルエルシー オーディオシーンの関心空間を表現する方法および装置
JP7489488B2 (ja) 2021-05-05 2024-05-23 テンセント・アメリカ・エルエルシー オーディオシーンの関心空間を表現する方法および装置
KR102711220B1 (ko) * 2021-05-05 2024-09-30 텐센트 아메리카 엘엘씨 오디오 장면의 관심 공간을 표현하기 위한 방법 및 장치
JP2023533414A (ja) * 2021-06-02 2023-08-03 テンセント・アメリカ・エルエルシー 適応オーディオ配信およびレンダリング
JP7505029B2 (ja) 2021-06-02 2024-06-24 テンセント・アメリカ・エルエルシー 適応オーディオ配信およびレンダリング

Also Published As

Publication number Publication date
TWI729997B (zh) 2021-06-11
TW201714456A (zh) 2017-04-16
KR102179269B1 (ko) 2020-11-16
JP6845223B2 (ja) 2021-03-17
US10693936B2 (en) 2020-06-23
EP3342174A2 (en) 2018-07-04
BR112018003386A2 (pt) 2018-09-25
WO2017035376A2 (en) 2017-03-02
CA2992599C (en) 2022-02-15
US20170063960A1 (en) 2017-03-02
CN107925797A (zh) 2018-04-17
KR20180044915A (ko) 2018-05-03
CN107925797B (zh) 2020-12-01
WO2017035376A3 (en) 2017-04-27
CA2992599A1 (en) 2017-03-02

Similar Documents

Publication Publication Date Title
JP6845223B2 (ja) コーディングされたオーディオデータのトランスポート
US11405699B2 (en) Using GLTF2 extensions to support video and audio data
KR102125484B1 (ko) 전송을 위해 코딩된 차세대 오디오 데이터의 선택
JP6545804B2 (ja) オーバージエアブロードキャストメディアデータに関するセッション記述情報
KR102145653B1 (ko) 연속적인 멀티-주기 콘텐츠의 프로세싱
JP5964972B2 (ja) 複数のソースからのマルチメディアデータのストリーミング
JP2019521584A (ja) Ｈｔｔｐを介した動的適応型ストリーミングにおけるバーチャルリアリティビデオのシグナリング
US11665219B2 (en) Processing media data using a generic descriptor for file format boxes
JP2018521538A (ja) ウェブソケットサブプロトコルを使用したメディアデータの転送
JP2018510545A (ja) 低レイテンシビデオストリーミング
TW201711431A (zh) 超級本文傳輸協定上動態自適應串流客戶經驗品質度量之中間軟體傳遞
JP2017517167A (ja) メディアデータをストリーミングするためのターゲット広告挿入
JP2019520741A (ja) サンプルエントリーおよびランダムアクセス
JP2019525677A (ja) メディアデータストリーミングのためのｓｅｉトラックのシステムレベルシグナリング
CN114930862A (zh) 用于流式媒体数据的多解码器接口
TWI820227B (zh) 用於媒體資料之網路串流之初始化集合
KR102117805B1 (ko) 전방향성 미디어 포맷을 이용한 미디어 데이터 프로세싱
BR112018003386B1 (pt) Método de recuperação de dados de áudio em um equipamento de usuário, dispositivo para recuperar dados de áudio, e, memória

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180301

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190805

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190805

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200722

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20200722

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20200819

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200831

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201105

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210225

R150 Certificate of patent or registration of utility model

Ref document number: 6845223

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250