JP6553054B2 - Ｍｐｅｇ−２システムによるｈｅｖｃ拡張ビットストリームの搬送およびバッファモデル - Google Patents

Ｍｐｅｇ−２システムによるｈｅｖｃ拡張ビットストリームの搬送およびバッファモデル Download PDF

Info

Publication number
JP6553054B2
JP6553054B2 JP2016544789A JP2016544789A JP6553054B2 JP 6553054 B2 JP6553054 B2 JP 6553054B2 JP 2016544789 A JP2016544789 A JP 2016544789A JP 2016544789 A JP2016544789 A JP 2016544789A JP 6553054 B2 JP6553054 B2 JP 6553054B2
Authority
JP
Japan
Prior art keywords
hevc
video
stream
layer
buffer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016544789A
Other languages
English (en)
Other versions
JP2017508339A5 (ja
JP2017508339A (ja
Inventor
チェン、イン
ワン、イェ−クイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2017508339A publication Critical patent/JP2017508339A/ja
Publication of JP2017508339A5 publication Critical patent/JP2017508339A5/ja
Application granted granted Critical
Publication of JP6553054B2 publication Critical patent/JP6553054B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Thin Film Transistor (AREA)
  • Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)

Description

優先権の主張
本出願は、その内容全体が参照により本明細書に組み込まれる、２０１４年１月８日に出願された米国仮特許出願第６１／９２５，１９１号の利益を主張する。
本開示は、ビデオコーディングに関し、より詳細には、ＨＥＶＣマルチレイヤ拡張ビットストリームの搬送に関する。
[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、タブレットコンピュータ、スマートフォン、携帯情報端末（ＰＤＡ）、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話または衛星無線電話、ビデオ遠隔会議デバイス、セットトップデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。
[0004]様々なデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、アドバンストビデオコーディング（ＡＶＣ）、高効率ビデオコーディング（ＨＥＶＣ）規格によって定義された規格、およびそのような規格の拡張に記述されているビデオ圧縮技法などのビデオ圧縮技法を実装することができる。マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）は、ＨＥＶＣ規格に対するマルチレイヤ拡張の例である。
[0005]一般に、本開示は、ＭＰＥＧ−２システムによる、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）の拡張ビットストリームを含む、高効率ビデオコーディング（ＨＥＶＣ）マルチレイヤ拡張ビットストリームの搬送のための技法を記載する。本開示の１つまたは複数の技法によれば、ビデオデコーダは、バッファモデルにおいて、データストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルする。データストリームは、トランスポートストリームまたはプログラムストリームであり得る。エレメンタリストリームがＳＨＶＣ、ＭＶ−ＨＥＶＣ、または３Ｄ−ＨＥＶＣのビットストリームを含むかどうかにかかわらず、同じバッファモデルが使用される。さらに、ビデオデコーダはアクセスユニットを復号する。
[0006]一態様では、本開示はビデオデータを復号する方法を記載し、方法は、複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、バッファモデルにおいて、ビデオデータストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルすること、ここにおいて、ビデオデータストリームはトランスポートストリームまたはプログラムストリームであり、エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのうちのいずれかを含むかどうかにかかわらず、アクセスユニットをアセンブルするために同じバッファモデルが使用される、と、アクセスユニットを復号することと、を備え、アクセスユニットはビデオデータの１つまたは複数のピクチャを備える。
[0007]別の態様では、本開示は、ビデオデータを記憶するように構成されたメモリと、複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、バッファモデルにおいて、ビデオデータストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルすること、ここにおいて、ビデオデータストリームはトランスポートストリームまたはプログラムストリームであり、エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのうちのいずれかを含むかどうかにかかわらず、アクセスユニットをアセンブルするために同じバッファモデルが使用される、と、アクセスユニットを復号することと、を行うように構成された、１つまたは複数のプロセッサとを備えるビデオ復号デバイスを記載し、アクセスユニットはビデオデータの１つまたは複数のピクチャを備える。
[0008]別の態様では、本開示は、複数のエレメンタリストリームを備えるビデオデータストリームを受信するための手段と、バッファモデルにおいて、ビデオデータストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルするための手段、ここにおいて、ビデオデータストリームはトランスポートストリームまたはプログラムストリームであり、エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのうちのいずれかを含むかどうかにかかわらず、アクセスユニットをアセンブルするために同じバッファモデルが使用される、と、アクセスユニットを復号するための手段と、を備えるビデオ復号デバイスを記載し、アクセスユニットはビデオデータの１つまたは複数のピクチャを備える。
[0009]別の態様では、本開示は、実行されると、複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、バッファモデルにおいて、ビデオデータストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルすること、ここにおいて、ビデオデータストリームはトランスポートストリームまたはプログラムストリームであり、エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのうちのいずれかを含むかどうかにかかわらず、アクセスユニットをアセンブルするために同じバッファモデルが使用される、と、アクセスユニットを復号することと、をビデオ復号デバイスに行わせる命令を記憶したコンピュータ可読データ記憶媒体を記載し、アクセスユニットはビデオデータの１つまたは複数のピクチャを備える。
[0010]本開示の１つまたは複数の態様の詳細が、添付の図面および以下の説明において記載される。本開示に記載される技法の他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。
本開示の技法を利用することができる、例示的なビデオ符号化および復号システムを示すブロック図。 単層高効率ビデオコーディング（ＨＥＶＣ）用の例示的なトランスポートストリームシステムターゲットデコーダ（Ｔ−ＳＴＤ）モデル拡張を示す概念図。 ＨＥＶＣ時間ビデオサブセットの積層トランスポート用の例示的なＴ−ＳＴＤモデル拡張を示す概念図。 本開示の１つまたは複数の技法による、ＨＥＶＣ積層ビデオサブビットストリーム用の例示的なＴ−ＳＴＤモデル拡張を示す概念図。 本開示の１つまたは複数の技法による、ＨＥＶＣ積層ビデオサブビットストリーム用の例示的なＰ−ＳＴＤモデル拡張を示す概念図。 本開示の技法を実装することができる、例示的なビデオエンコーダを示すブロック図。 本開示の技法を実装することができる、例示的なビデオデコーダを示すブロック図。 本開示の１つまたは複数の技法による、ビデオデコーダの例示的な動作を示すフローチャート。 本開示の１つまたは複数の技法による、アクセスユニットをアセンブルおよび復号するビデオデコーダの例示的な動作を示すフローチャート。
[0020]本開示は、ＭＰＥＧ−２システムによる、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）の拡張ビットストリームを含む、ＨＥＶＣマルチレイヤ拡張ビットストリームの搬送のための技法を記載する。ＭＶ−ＨＥＶＣでは、複数のビューが、たとえば、様々な視点に対してコード化され得る。ＳＨＶＣでは、複数のレイヤが、たとえば、空間スケーラビリティ、時間スケーラビリティ、または品質スケーラビリティをサポートするためにコード化され得る。３Ｄ−ＨＥＶＣでは、複数のビューが、たとえば、３Ｄ表現をサポートするために、テクスチャ成分と深度成分とを用いてコード化され得る。一般に、ＭＶ−ＨＥＶＣにおけるビュー、ＳＨＶＣにおけるレイヤ、または３Ｄ−ＨＥＶＣにおけるビューは、各々概してレイヤと呼ばれる場合がある。したがって、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣは、総称して、積層（layered）ＨＥＶＣまたはマルチレイヤ(multi-layer)ＨＥＶＣのコーディング技法と呼ばれる場合がある。
[0021]ＭＰＥＧ−２システム仕様は、デジタル送信または記憶に適した単一のデータストリームを形成するために、圧縮マルチメディア（ビデオおよびオーディオ）データストリームが他のデータとともにどのように多重化され得るかを記述している。ＭＰＥＧ−２システム仕様は、プログラムストリームおよびトランスポートストリームの概念を定義する。プログラムストリームは、デジタルストレージサービスからの単一のプログラムの記憶および表示のためにバイアスされ、プログラムストリームは、誤りのない環境での使用を目的とする。対照的に、トランスポートストリームは、潜在的に誤りを起こしやすいチャネルを介するいくつかのプログラムの同時配信を目的とする。プログラムストリームおよびトランスポートストリームは、パケット化エレメンタリストリーム（ＰＥＳ）パケットを含む。プログラムストリームおよびトランスポートストリームのＰＥＳパケットは、１つまたは複数のエレメンタリストリームに属する。エレメンタリストリームは、単一のデジタル的にコーディングされた（場合によってはＭＰＥＧ圧縮された）プログラムの構成要素である。たとえば、プログラムのコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。
[0022]ビデオデコーダは、プログラムストリームおよびトランスポートストリームのＰＥＳパケットを受信する。ビデオデコーダは、ＰＥＳパケットから取得されたビデオデータを復号することができる。積層ＨＥＶＣでは、アクセスユニット（ＡＵ）は、同じ時間インスタンスであるが、異なるレイヤに関連付けられたピクチャを含む場合がある。アクセスユニットのピクチャを復号するより前に、ビデオデコーダは、ＰＥＳパケット内のデータから、アクセスユニットに対応する符号化データを再アセンブルする必要があり得る。言い換えれば、ビデオデコーダは、復号の準備ができている状態にあるアクセスユニットに対応する符号化データを有する必要があり得る。
[0023]Ｇｒｕｎｅｂｅｒｇら、「Ｔｅｘｔ ｏｆ ＩＳＯ／ＩＥＣ１３８１８−１：２０１３／Ｆｉｎａｌ Ｄｒａｆｔ Ａｍｅｎｄｍｅｎｔ ３−Ｔｒａｎｓｐｏｒｔ ｏｆ ＨＥＶＣ ｖｉｄｅｏ ｏｖｅｒ ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ１０５／Ｎ１３６５６、２０１３年７月、ウィーン、オーストリア（本明細書では「ｎ１３６５６」または「ＦＤＡＭ３」）は、ＭＰＥＧ−２システムにおけるＨＥＶＣビデオのトランスポートを記述している。さらに、Ｃｈｅｎら、「Ｃａｒｒｉａｇｅ ｏｆ ＨＥＶＣ ｅｘｔｅｎｓｉｏｎ ｓｔｒｅａｍｓ ｗｉｔｈ ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ」、ＭＰＥＧ入力文書ｍ３１４３０、第１０６回ＭＰＥＧ会合、２０１３年１０月、ジュネーブ、スイス、ＭＰＥＧ入力文書ｍ３１４３０（本明細書では「ＭＰＥＧ入力文書ｍ３１４３０」）は、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送の基本設計を提案している。ＨＥＶＣ拡張ストリームは、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣに準拠するＨＥＶＣストリームである。ＦＤＡＭ３も、ＭＰＥＧ入力文書ｍ３１４３０も、ビデオデコーダがＨＥＶＣ拡張ストリームのアクセスユニットをどのように再アセンブルするかを記述していない。たとえば、ＦＤＡＭ３も、ＭＰＥＧ入力文書ｍ３１４３０も、ビデオデコーダがＨＥＶＣ拡張ストリームのアクセスユニットの再アセンブリに使用することができるバッファモデルを記述していない。
[0024]本開示の１つまたは複数の技法によれば、ビデオデコーダは、バッファモデルにおいて、トランスポートストリームまたはプログラムストリームなどの、データストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルする。エレメンタリストリームがＳＨＶＣ、ＭＶ−ＨＥＶＣ、または３Ｄ−ＨＥＶＣのビットストリームを含むかどうかにかかわらず、同じバッファモデルが使用される。次いで、ビデオデコーダはアクセスユニットを復号することができる。バッファリングモデルを使用することによって、ビデオデコーダは、トランスポートストリームまたはプログラムストリームのＰＥＳパケットからデータを、復号の準備ができているアクセスユニットへの再アセンブリのために集めることができる。ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣ用の統合バッファモデルを使用すると、ＳＨＶＣと、ＭＶ−ＨＥＶＣと、３Ｄ−ＨＥＶＣとをサポートするためにビデオデコーダに加わる複雑さを最小化することができる。
[0025]図１は、ＭＰＥＧ−２システムによる、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）の拡張ビットストリームを含む、ＨＥＶＣマルチレイヤ拡張ビットストリームの搬送のための技法などの、本開示の様々な技法を利用するように構成され得る、例示的なビデオ符号化および復号システム１０を示すブロック図である。
[0026]図１に示されたように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを供給するソースデバイス１２を含む。詳細には、ソースデバイス１２は、コンピュータ可読媒体１６を介して宛先デバイス１４に符号化ビデオデータを供給する。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備える場合がある。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に対応する場合がある。
[0027]宛先デバイス１４は、コンピュータ可読媒体１６を介して符号化ビデオデータを受信することができる。コンピュータ可読媒体１６は、符号化ビデオデータをソースデバイス１２から宛先デバイス１４に移動することが可能な、任意のタイプの媒体またはデバイスを備える場合がある。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が符号化ビデオデータを宛先デバイス１４にリアルタイムに直接送信することを可能にするために、送信チャネルなどの通信媒体を備える場合がある。
[0028]符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を備える場合がある。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースのネットワークの一部を形成することができる。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス１２から宛先デバイス１４への通信を容易にするために有用であり得る任意の他の機器を含む場合がある。
[0029]いくつかの例では、符号化データは、出力インターフェース２２から、非一時的コンピュータ可読記憶媒体などのコンピュータ可読記憶媒体、すなわちデータストレージデバイスに出力され得る。同様に、符号化データは、ストレージデバイスから入力インターフェースによってアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性もしくは不揮発性のメモリ、または符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの、様々な分散されたまたはローカルにアクセスされる非一時的データ記憶媒体のいずれかを含む場合がある。さらなる例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶することができる、ファイルサーバまたは別の中間ストレージデバイスに対応する場合がある。宛先デバイス１４は、たとえば、ストリーミングまたはダウンロードを介して、ストレージデバイスからの記憶されたビデオデータにアクセスすることができる。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能な、任意のタイプのサーバであり得る。例示的なファイルサーバには、（たとえば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブが含まれる。宛先デバイス１４は、インターネット接続を含む任意の標準的なデータ接続を介して、符号化ビデオデータにアクセスすることができる。これは、ファイルサーバ上に記憶された符号化ビデオデータにアクセスすることに適した、ワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、有線接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含む場合がある。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
[0030]本開示の技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されたデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例などの、様々な有線またはワイヤレスのマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオ放送、および／またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
[0031]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。他の例では、ソースデバイス１２および宛先デバイス１４は、他の構成要素または装置を含む。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソースからビデオデータを受信することができる。同様に、宛先デバイス１４は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースする場合がある。
[0032]本開示は、ＨＥＶＣコーディング拡張、詳細には、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、および３Ｄ−ＨＥＶＣのコーディング拡張のコンテキストで、ビデオエンコーダ２０とビデオデコーダ３０とを記載する。しかしながら、本開示の技法は、他のビデオコーディングの規格または方法に適用可能であり得る。本開示に記載される技法は、ビデオエンコーダ２０、ビデオデコーダ３０、または、スプライシングエンジン、媒体認識ネットワーク要素、ストリーミングサーバ、ルータ、およびコード化ビデオビットストリームを符号化、復号、アセンブル、構築、抽出、もしくは場合によっては処理する他のデバイスなどの、他のデバイスによって実施される場合がある。
[0033]図１の示されたシステム１０は、一例にすぎない。本開示の技法は、デジタルビデオ符号化および／または復号デバイスによって実施される場合がある。一般に、本開示の技法は、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実施されるが、本技法は、通常「コーデック」と呼ばれるビデオエンコーダ／デコーダによって実施される場合もある。その上、本開示の技法は、ビデオプリプロセッサによって実施される場合もある。ソースデバイス１２および宛先デバイス１４は、宛先デバイス１４に送信するためのコード化ビデオデータをソースデバイス１２が生成する、そのようなコーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４は、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、実質的に対称的に動作することができる。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオ放送、またはビデオ電話のための、ビデオデバイス１２、１４の間の一方向または双方向のビデオ送信をサポートすることができる。
[0034]ソースデバイス１２のビデオソース１８は、ビデオカメラ、以前キャプチャされたビデオを含むビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェースなどの、ビデオキャプチャデバイスを含む場合がある。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオ、アーカイブビデオ、およびコンピュータ生成ビデオの組合せを生成することができる。いくつかの例では、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるスマートフォン、タブレットコンピュータ、またはビデオ電話を形成することができる。しかしながら、上述されたように、本開示に記載される技法は、一般にビデオコーディングに適用可能であり得るし、ワイヤレスおよび／または有線の適用例に適用される場合がある。各場合において、キャプチャされたビデオ、事前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。次いで、符号化されたビデオ情報は、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
[0035]コンピュータ可読媒体１６は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはデータ記憶媒体（すなわち、非一時的記憶媒体）を含む場合がある。いくつかの例では、ネットワークサーバ（図示せず）は、ソースデバイス１２から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス１４に供給することができる。同様に、ディスクスタンピング設備などの媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含むディスクを製造することができる。したがって、様々な例では、コンピュータ可読媒体１６は、様々な形態の１つまたは複数のコンピュータ可読媒体を含むと理解され得る。
[0036]本開示は、一般に、ビデオエンコーダ２０が、ビデオデコーダ３０などの別のデバイスにある情報を「シグナリング」することに言及する場合がある。ビデオエンコーダ２０は、いくつかのシンタックス要素をビデオデータの様々な符号化された部分と関連付けることによって、情報をシグナリングできることを理解されたい。すなわち、ビデオエンコーダ２０は、ビデオデータの様々な符号化される部分のヘッダまたはペイロードにいくつかのシンタックス要素を格納することによって、データを「シグナリング」することができる。場合によっては、そのようなシンタックス要素は、ビデオデコーダ３０によって受信および復号されるより前に、符号化および記憶（たとえば、コンピュータ可読媒体１６に記憶）される場合がある。したがって、「シグナリング」という用語は、一般に、そのような通信がリアルタイムもしくはほぼリアルタイムで発生するか、またはある期間にわたって発生するかにかかわらず、圧縮されたビデオデータを復号するためのシンタックスまたは他のデータの通信を指す場合があり、ある期間にわたる通信は、シンタックス要素を符号化の時点で媒体に記憶し、次いで、シンタックス要素がこの媒体に記憶された後の任意の時点で復号デバイスによって取り出され得るときに発生する場合がある。
[0037]宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、ビデオエンコーダ２０によって定義され、ビデオデコーダ３０によっても使用される、シンタックス情報を含む場合がある。ディスプレイデバイス３２は、ユーザに復号ビデオデータを表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、投影デバイス、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備える場合がある。
[0038]図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、各々、オーディオエンコーダおよびデコーダと統合される場合があり、共通のデータストリームまたは別々のデータストリーム内のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含む場合がある。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットは、一例として、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。
[0039]ビデオエンコーダ２０およびビデオデコーダ３０は、各々、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、個別論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な適切なエンコーダ回路またはデコーダ回路のいずれかとして実装される場合がある。ビデオエンコーダ２０およびビデオデコーダ３０の各々は、１つまたは複数のエンコーダまたはデコーダに含まれる場合があり、それらのいずれも、複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合される場合がある。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／または携帯電話などのワイヤレス通信デバイスを備える場合がある。
[0040]例示的なビデオコーディング規格には、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびそのスケーラブルビデオコーディング（ＳＶＣ）拡張とマルチビュービデオコーディング（ＭＶＣ）拡張とを含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４が含まれる。ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０は、Ｈ．２６４／ＡＶＣビデオコーディング規格を定義する。ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の特定の付属書類（Annex）は、Ｈ．２６４／ＡＶＣビデオコーディング規格の拡張を定義する。たとえば、ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｂは、Ｈ．２６４／ＡＶＣ用のバイトストリームフォーマットを定義する。ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｇは、Ｈ．２６４／ＡＶＣのＳＶＣ拡張を定義する。ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｈは、Ｈ．２６４／ＡＶＣのＭＶＣ拡張を定義する。
[0041]最近、新しいビデオコーディング規格、すなわち高効率ビデオコーディング（ＨＥＶＣ）の設計が、ＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）およびＩＳＯ／ＩＥＣ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）のビデオコーディング共同研究部会（ＪＣＴ−ＶＣ）によって確定された。ビデオエンコーダ２０およびビデオデコーダ３０は、ＨＥＶＣ規格、および、より詳細には、本開示で参照されるようなＨＥＶＣ規格のマルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、または３Ｄ−ＨＥＶＣの拡張に従って動作することができる。ＨＥＶＣは、たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣなどの他の処理に従ってコーディングを実行するように構成されるデバイスと比較して、ビデオコーディングデバイスのいくつかの追加能力を仮定する。たとえば、Ｈ．２６４は９個のイントラ予測符号化モードを提供するが、ＨＥＶＣの参照モデルは３５個ものイントラ予測符号化モードを提供することができる。
[0042]本明細書では「ＨＥＶＣ ＷＤ」または「ＨＥＶＣ」と呼ばれる、ＨＥＶＣドラフト仕様、Ｗａｎｇら、文書ＪＣＴＶＣ−Ｎ１００３＿ｖ１、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１のビデオコーディング共同研究部会（ＪＣＴ−ＶＣ）、第１４回会合：ウィーン、オーストリア、２０１３年７月２５日〜８月２日は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００３−ｖ１．ｚｉｐから入手可能である。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２がＨＥＶＣ規格の最終版である。
[0043]３Ｄビデオコーディング拡張開発共同研究部会（ＪＣＴ−３Ｖ）は、ＨＥＶＣに対するマルチビュー拡張、すなわちＭＶ−ＨＥＶＣを開発している。本明細書では「ＭＶ−ＨＥＶＣ ＷＤ５」または「ＭＶ−ＨＥＶＣ」と呼ばれる、ＭＶ−ＨＥＶＣの最新ワーキングドラフト（ＷＤ）、Ｔｅｃｈら、文書ＪＣＴ３Ｖ−Ｅ１００４−ｖ６、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１の３Ｄビデオコーディング拡張開発共同研究部会、第５回会合：ウィーン、オーストリア、２０１３年７月２７日〜８月２日は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００４−ｖ６．ｚｉｐから入手可能である。
[0044]Ｔｅｃｈら、文書ＪＣＴ３Ｖ−Ｅ１００１−ｖ３、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１の３Ｄビデオコーディング拡張開発共同研究部会、第５回会合：ウィーン、オーストリア、２０１３年７月２７日〜８月２日（本明細書では「ＪＣＴ３Ｖ−Ｅ１００１」または「３Ｄ−ＨＥＶＣ」）は、ＨＥＶＣの３Ｄ拡張、すなわち３Ｄ−ＨＥＶＣの最新ワーキングドラフトである。ＪＣＴ３Ｖ−Ｅ１００１は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００１−ｖ３．ｚｉｐから入手可能である。
[0045]ＪＣＴ−ＶＣは、ＨＥＶＣに対するスケーラブル拡張、すなわちＳＨＶＣも開発している。Ｃｈｅｎら、文書ＪＣＴＶＣ−Ｎ１００８＿ｖ３、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１のビデオコーディング共同研究部会（ＪＣＴ−ＶＣ）、第１４回会合：ウィーン、オーストリア、２０１３年７月２５日〜８月２日（本明細書では「ＳＨＶＣ ＷＤ３」または単に「ＳＨＶＣ」）は、ＳＨＶＣの最新ワーキングドラフト（ＷＤ）である。ＳＨＶＣ ＷＤ３は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００８−ｖ３．ｚｉｐから入手可能である。
[0046]Ｆｌｙｎｎら、文書ＪＣＴＶＣ−Ｎ１００５＿ｖ１、ＩＴＵ−Ｔ ＳＧ１６ ＷＰ３およびＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１のビデオコーディング共同研究部会（ＪＣＴ−ＶＣ）、第１３回会合：インチョン、韓国、２０１３年４月１８日〜２６日、文書ＪＣＴＶＣ−Ｎ１００５（本明細書ではＪＣＴＶＣ−Ｎ１００５）は、ＨＥＶＣの範囲拡張の最新ワーキングドラフトである。ＪＣＴＶＣ−Ｎ１００５は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００５−ｖ３．ｚｉｐから入手可能である。
[0047]一般に、ＨＥＶＣは、ビデオピクチャ（または「フレーム」）が、コーディングツリーユニット（ＣＴＵ）と呼ばれる一連の最大コーディングユニットに分割され得ることを規定する。ＣＴＵは、それぞれ、ルーマサンプルとクロマサンプルとを含むコーディングツリーブロック（ＣＴＢ）、たとえばルーマＣＴＢおよびクロマＣＴＢと呼ばれる、対応するルーマ成分とクロマ成分とを含む場合がある。ビットストリーム内のシンタックスデータは、ＣＴＵについてのサイズを定義することができ、ＣＴＵは、ピクセルの数の観点から最大のコーディングユニットである。スライスは、コーディング順にいくつかの連続するＣＴＢを含む。ピクチャは、１つまたは複数のスライスに区分化され得る。各ＣＴＢは、４分木区分化構造に従って、１つまたは複数のコーディングユニット（ＣＵ）に分割され得る。一般に、４分木データ構造は、ＣＵあたり１つのノードを含み、ルートノードがＣＴＢに対応する。ＣＵが４つのサブＣＵに分割される場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。ＣＵは、ルーマサンプルアレイと、Ｃｂサンプルアレイと、Ｃｒサンプルアレイとを有するピクチャの、ルーマサンプルのコーディングブロックと、クロマサンプルの２つの対応するコーディングブロックと、それらのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備える場合がある。３つの別々のカラープレーンを有する１つまたは複数のモノクロームピクチャでは、ＣＵは、単一のコーディングブロックと、そのコーディングブロックのサンプルをコーディングするために使用されるシンタックス構造とを備える場合がある。
[0048]４分木データ構造の各ノードは、対応するＣＵにシンタックスデータを供給することができる。たとえば、４分木内のノードは、そのノードに対応するＣＵがサブＣＵに分割されるのかどうかを示す分割フラグを含む場合がある。ＣＵのシンタックス要素は、再帰的に定義される場合があり、ＣＵがサブＣＵに分割されるかどうかに依存する場合がある。ＣＵがこれ以上分割されない場合、そのＣＵはリーフＣＵと呼ばれる。元のリーフＣＵの明示的な分割がない場合でも、リーフＣＵの４つのサブＣＵはリーフＣＵと呼ばれる場合もある。たとえば、１６×１６サイズのＣＵがこれ以上分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵがリーフＣＵと呼ばれる場合がある。
[0049]ＨＥＶＣにおけるＣＵは、ＣＵがサイズの差異を有していないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ＣＴＢは、（サブＣＵとも呼ばれる）４つの子ノードに分割され得るし、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割され得る。４分木のリーフノードと呼ばれる、最後の分割されない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームと関連付けられるシンタックスデータは、最大ＣＵ深度と呼ばれる、ＣＴＢが分割され得る最大回数を定義することができ、コーディングノードの最小サイズも定義することができる。したがって、いくつかの例では、ビットストリームは、最小コーディングユニットを定義することもできる。
[0050]ＣＵは、コーディングノードと、コーディングノードに関連付けられた１つまたは複数の予測ユニット（ＰＵ）および１つまたは複数の変換ユニット（ＴＵ）とを含む。本開示は、ＨＥＶＣのコンテキストでは、ＣＵ、予測ユニット（ＰＵ）、変換ユニット（ＴＵ）、もしくはそれらのパーティションのいずれか、または他の規格のコンテキストでは、同様のデータ構造を指すために、「ブロック」という用語を使用する場合がある。ＣＵのサイズはコーディングノードのサイズに対応する。ＣＵのサイズは、８×８ピクセルから最大６４×６４ピクセル以上のＣＴＢのサイズまで及ぶ場合がある。
[0051]ＣＵに関連付けられたシンタックスデータは、１つまたは複数のＰＵへのＣＵの区分化を記述することができる。一般に、ＰＵは、ＣＵのすべてまたは一部に対応する空間領域を表す。区分化モードは、ＣＵがスキップモード符号化もしくは直接モード符号化されるのか、イントラ予測モード符号化されるのか、またはインター予測モード符号化されるのかの間で異なる場合がある。本開示に記載される深度コーディングの場合、ＰＵは、形状が非正方形となるように区分化される場合があるか、または、形状が非方形であるパーティションを含む場合がある。ＣＵのＰＵは、ルーマサンプルの予測ブロックと、クロマサンプルの２つの対応する予測ブロックと、それらの予測ブロックを予測するために使用されるシンタックス構造とを備える場合がある。３つの別々のカラープレーンを有する１つまたは複数のモノクロームピクチャでは、ＰＵは、単一の予測ブロックと、その予測ブロックを予測するために使用されるシンタックス構造とを備える場合がある。ビデオエンコーダ２０は、ＣＵの各ＰＵの予測ブロック（prediction block）（たとえば、ルーマ予測ブロック（prediction block）、Ｃｂ予測ブロック（prediction block）、およびＣｒ予測ブロック（prediction block））用の予測ブロック（predictive block）（たとえば、ルーマ予測ブロック（predictive block）、Ｃｂ予測ブロック（predictive block）、およびＣｒ予測ブロック（predictive block））を生成することができる。
[0052]ＰＵは、ＰＵのための参照サンプルを取り出すためのデータを含む場合がある。参照サンプルは、参照ブロックからのピクセルであり得る。いくつかの例では、参照サンプルは、たとえば、補間または他の技法によって、参照ブロックから取得されるか、または生成される場合がある。ＰＵはまた、予測に関するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵ用のデータは、残差４分木（ＲＱＴ）に含まれる場合があり、ＲＱＴは、ＰＵに対応するＴＵ用のイントラ予測モードを記述するデータを含む場合がある。
[0053]別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵ用の１つまたは複数の動きベクトルを定義するデータを含む場合がある。ＰＵ用の動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトル用の参照ピクチャリスト（たとえば、ＲｅｆＰｉｃＬｉｓｔ０もしくはＲｅｆＰｉｃＬｉｓｔ１）を記述することができる。
[0054]ＨＥＶＣは、様々なＰＵサイズにおける予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＥＶＣは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズにおけるイントラ予測と、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズにおけるインター予測とをサポートする。２Ｎ×２Ｎのサイズを有するＰＵは、ＰＵが存在するＣＵと同じサイズである。ＨＥＶＣは、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズにおけるインター予測のための非対称区分化をサポートする。非対称区分化では、ＣＵの一方の方向は区分化されず、他方の方向は、２５％と７５％に区分化される。２５％パーティションに対応するＣＵの部分は、「ｎ」、ならびにそれに続く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」の指示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５ＮのＰＵおよび下部の２Ｎ×１．５ＮのＰＵを用いて水平に区分化される２Ｎ×２ＮのＣＵを指す。深度コーディングの場合、ＪＣＴ３Ｖ−Ｅ１００１は、記載されるような非方形パーティションを含む、深度モデル化モード（ＤＭＭ）に従うＰＵの区分化をさらにサポートする。
[0055]本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法の観点からビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用される場合がある。一般に、１６ｘ１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセル、水平方向にＮピクセルを有し、Ｎは非負整数値を表す。ブロック内のピクセルは、行および列に配置される場合がある。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍピクセルを備える場合があり、ここで、Ｍは必ずしもＮに等しいとは限らない。
[0056]ＣＵに関連付けられたシンタックスデータはまた、４分木に従う１つまたは複数のＴＵへのＣＵの区分化を記述することができる。ＴＵは、形状が正方形または非正方形（たとえば、長方形）であり得る。ＣＵのＴＵは、ルーマサンプルの変換ブロックと、クロマサンプルの２つの対応する変換ブロックと、それらの変換ブロックサンプルを変換するために使用されるシンタックス構造とを備える場合がある。３つの別々のカラープレーンを有する１つまたは複数のモノクロームピクチャでは、ＴＵは、単一の変換ブロックと、その変換ブロックのサンプルを変換するために使用されるシンタックス構造とを備える場合がある。ＨＥＶＣ規格は、ＴＵによる変換を可能にする。ビデオエンコーダ２０は、変換係数を生成するためにＴＵに関連付けられたピクセル差分値を変換することができる。
[0057]いくつかの例では、ＣＵのＴＵのサイズは、ＣＵのＰＵのサイズに基づくが、いつもこうであるとは限らない。さらに、いくつかの例では、ＴＵは、ＰＵと同じサイズであるか、またはＰＵよりも小さい。ＣＵに対応する残差サンプル（すなわち、ピクセル差分値）は、「残差４分木」（ＲＱＴ）として知られる４分木構造を使用して、より小さいユニット（すなわち、変換ブロック）に再分割され得る。言い換えれば、リーフＣＵは、リーフＣＵがどのようにＴＵに区分化されるかを示す４分木を含む場合がある。ＴＵ４分木（すなわち、ＲＱＴ）のルートノードは、一般に、リーフＣＵに対応する。ＲＱＴのリーフノードはＴＵに対応する。分割されないＲＱＴのＴＵは、リーフＴＵと呼ばれる。一般に、本開示は、別段に記載されていない限り、それぞれ、リーフＣＵおよびリーフＴＵを指すために、ＣＵおよびＴＵという用語を使用する。
[0058]ＴＵは、上記で説明されたように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定される場合がある。たとえば、分割フラグは、リーフＣＵが４つのＴＵに分割されるかどうかを示すことができる。次いで、各ＴＵは、さらなるサブＴＵにさらに分割され得る。ＴＵがこれ以上分割されないとき、ＴＵはリーフＴＵと呼ばれる場合がある。いくつかの例では、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは、同じイントラ予測モードを共有する。すなわち、一般に、リーフＣＵのすべてのＴＵについての予測値を計算するために、同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダ２０は、イントラ予測モードを使用して、リーフＴＵごとの残差値を、ＴＵに対応するＣＵの部分と元のブロックとの間の差分として計算することができる。ＴＵは、必ずしもＰＵのサイズに限定されるとは限らない。したがって、ＴＵは、ＰＵよりも大きい場合もあり、小さい場合もある。イントラコーディングの場合、ＰＵは、同じＣＵ用の対応するリーフＴＵとコロケートされる場合がある。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに対応する場合がある。
[0059]ＣＵのＰＵを使用する通常のイントラ予測コーディングまたはインター予測コーディングに続いて、ビデオエンコーダ２０は、ＣＵのＴＵについての残差データを計算することができる。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備える場合があり、ＴＵは、通常の残差コーディングの場合、残差ビデオデータに対する変換、たとえば離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用に従って、変換領域内の係数を備える場合がある。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応することができる。ビデオエンコーダ２０は、ＣＵについての残差データを含むＴＵを形成し、次いで、ＣＵ用の変換係数を生成するためにＴＵを変換することができる。
[0060]変換係数を生成する任意の変換に続いて、ビデオエンコーダ２０は、変換係数の量子化を実行することができる。量子化は、一般に、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を実現するプロセスを指す。量子化プロセスは、係数の一部またはすべてに関連付けられたビット深度を低減することができる。たとえば、ｎビットの値は、量子化の間にｍビットの値に切り捨てられる場合があり、ここで、ｎはｍよりも大きい。
[0061]量子化に続いて、ビデオエンコーダ２０は、量子化変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成することができる。走査は、より高いエネルギー（したがって、より低い頻度）の係数を配列の前方に配置し、より低いエネルギー（したがって、より高い頻度）の係数を配列の後方に配置するように設計され得る。
[0062]いくつかの例では、ビデオエンコーダ２０は、量子化変換係数を走査して、エントロピー符号化され得るシリアル化されたベクトルを生成するために、あらかじめ定義された走査順序を利用することができる。他の例では、ビデオエンコーダ２０は適応型走査を実行することができる。量子化変換係数を走査して１次元ベクトルを形成した後、ビデオエンコーダ２０は、たとえば、ＨＥＶＣにおいて使用されるコンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）に従って、１次元ベクトルをエントロピー符号化することができる。他のエントロピーコーディングプロセスの例には、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、および確率間隔区分化エントロピー（ＰＩＰＥ）コーディングが含まれる。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための、符号化ビデオデータに関連付けられたシンタックス要素をエントロピー符号化することができる。
[0063]ビデオシーケンスは、通常、一連のピクチャを含む。本明細書に記載されるように、「ピクチャ」および「フレーム」は互換的に使用される場合がある。ピクチャの各スライスは、それぞれのスライスについての符号化モードを記述するスライスシンタックスデータを含む場合がある。ビデオエンコーダ２０は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに作用する。ビデオブロックはＣＵ内のコーディングノードに対応する場合がある。ビデオブロックは、固定サイズまたは可変サイズを有する場合があり、指定されたコーディング規格に応じてサイズが異なる場合がある。
[0064]ビデオエンコーダ２０および／またはビデオデコーダ３０は、深度データのイントラピクチャ予測コーディングと、深度データのインター予測コーディングとを実行することができる。ＨＥＶＣにおいて、ＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、イントラ予測の場合は２Ｎ×２ＮまたはＮ×Ｎの様々なＰＵサイズをサポートすることができ、インター予測の場合は２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、または同様のサイズの対称的なＰＵサイズをサポートすることができる。ビデオエンコーダおよびビデオデコーダはまた、インター予測の場合は２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズに対する非対称区分化をサポートすることができる。
[0065]ビデオエンコーダ２０は、コード化ピクチャおよび関連データの表現を形成するビットのシーケンスを含む、ビットストリームを出力することができる。「ビットストリーム」という用語は、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットストリーム（たとえば、ＮＡＬユニットのシーケンス）、またはバイトストリーム（たとえば、ＨＥＶＣ規格の付属書類Ｂによって指定されたスタートコードプレフィックスとＮＡＬユニットとを含むＮＡＬユニットストリームのカプセル化）のいずれかを指すために使用される総称であり得る。ＮＡＬユニットは、ＮＡＬユニット内のデータのタイプの指示と、必要に応じてエミュレーション防止ビットが散在するローバイトシーケンスペイロード（ＲＢＳＰ）の形態でそのデータを含むバイトとを含む、シンタックス構造である。
[0066]ＮＡＬユニットの各々は、ＮＡＬユニットヘッダを含む場合があり、ＲＢＳＰをカプセル化することができる。ＮＡＬユニットヘッダは、ＮＡＬユニットタイプコードを示すシンタックス要素などの、様々なシンタックス要素を含む場合がある。ＮＡＬユニットヘッダに含まれるシンタックス要素は、本明細書ではＮＡＬユニットヘッダシンタックス要素と呼ばれる場合がある。ＮＡＬユニットのＮＡＬユニットヘッダによって指定されるＮＡＬユニットタイプコードは、ＮＡＬユニットのタイプを示す。ＲＢＳＰは、ＮＡＬユニット内にカプセル化された整数個のバイトを含むシンタックス構造であり得る。場合によっては、ＲＢＳＰは０ビットを含む。
[0067]様々なタイプのＮＡＬユニットは、様々なタイプのＲＢＳＰをカプセル化することができる。たとえば、第１のタイプのＮＡＬユニットはピクチャパラメータセット（ＰＰＳ）用のＲＢＳＰをカプセル化することができ、第２のタイプのＮＡＬユニットはスライスセグメント用のＲＢＳＰをカプセル化することができ、第３のタイプのＮＡＬユニットは補足エンハンスメント情報（ＳＥＩ）用のＲＢＳＰをカプセル化することができ、以下同様である。（パラメータセットおよびＳＥＩメッセージ用のＲＢＳＰとは対照的に）ビデオコーディングデータ用のＲＢＳＰをカプセル化するＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと呼ばれる場合がある。パラメータセット（たとえば、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ＰＰＳなど）を含むＮＡＬユニットは、パラメータセットＮＡＬユニットと呼ばれる場合がある。ＳＥＩメッセージを含むＮＡＬユニットは、ＳＥＩ ＮＡＬユニットと呼ばれる場合がある。補足エンハンスメント情報（ＳＥＩ）は、ＶＣＬ ＮＡＬユニットからのコード化ピクチャのサンプルを復号するために必要ではない情報を含んでいる。
[0068]ビデオデコーダ３０は、ビデオエンコーダ２０によって生成されたビットストリームを受信することができる。加えて、ビデオデコーダ３０は、ビットストリームからシンタックス要素を取得するために、ビットストリームを構文解析する（parse）ことができる。ビデオデコーダ３０は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを復元することができる。ビデオデータを復元するプロセスは、一般に、ビデオデータを符号化するためにビデオエンコーダ２０によって実行されるプロセスの逆であり得る。たとえば、ビデオデコーダ３０は、現在ＣＵのＰＵ用の予測ブロックを決定するために、ＰＵの動きベクトルを使用することができる。加えて、ビデオデコーダ３０は、現在ＣＵのＴＵの係数ブロックを逆量子化することができる。ビデオデコーダ３０は、現在ＣＵのＴＵの変換ブロックを復元するために、係数ブロックに対して逆変換を実行することができる。ビデオデコーダ３０は、現在ＣＵのＰＵの予測ブロックのサンプルを、現在ＣＵのＴＵの変換ブロックの対応するサンプルに加算することによって、現在ＣＵのコーディングブロックを復元することができる。ピクチャの各ＣＵにコーディングブロックを復元することによって、ビデオデコーダ３０はピクチャを復元することができる。
[0069]マルチビューコーディングでは、異なる視点からの同じシーンの複数のビューが存在する場合がある。「アクセスユニット」という用語は、同じ時間インスタンスに対応するピクチャのセットを指すために使用される場合がある。したがって、ビデオデータは、時間とともに発生する一連のアクセスユニットとして概念化される場合がある。「ビュー成分」は、単一のアクセスユニット内のビューのコード化表現であり得る。本開示では、「ビュー」は、同じビュー識別子に関連付けられたビュー成分のシーケンスまたはセットを指す場合がある。ビュー成分は、テクスチャビュー成分と深度ビュー成分とを含む場合がある。
[0070]テクスチャビュー成分（すなわち、テクスチャピクチャ）は、単一のアクセスユニット内のビューのテクスチャのコード化表現であり得る。テクスチャビューは、ビュー順序インデックスの同一の値に関連付けられたテクスチャビュー成分のシーケンスであり得る。ビューのビュー順序インデックスは、他のビューに対するビューのカメラ位置を示すことができる。深度ビュー成分（すなわち、深度ピクチャ）は、単一のアクセスユニット内のビューの深度のコード化表現であり得る。深度ビューは、ビュー順序インデックスの同一の値に関連付けられた１つまたは複数の深度ビュー成分のセットまたはシーケンスであり得る。
[0071]ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、およびＳＨＶＣでは、ビデオエンコーダは、一連のＮＡＬユニットを備えるビットストリームを生成することができる。ビットストリームの様々なＮＡＬユニットは、ビットストリームの様々なレイヤに関連付けられる場合がある。レイヤは、同じレイヤ識別子を有するＶＣＬ ＮＡＬユニットおよび関連する非ＶＣＬ ＮＡＬユニットのセットとして定義され得る。レイヤは、マルチビュービデオコーディングにおけるビューと等価であり得る。マルチビュービデオコーディングでは、レイヤは、様々な時間インスタンスを有する同じレイヤのすべてのビュー成分を含むことができる。各ビュー成分は、特定の時間インスタンスにおいて特定のビューに属するビデオシーンのコード化ピクチャであり得る。３Ｄビデオコーディングのいくつかの例では、レイヤは、特定のビューのすべてのコード化深度ピクチャ、または特定のビューのコード化テクスチャピクチャのいずれかを含むことができる。３Ｄビデオコーディングの他の例では、レイヤは、特定のビューのテクスチャビュー成分と深度ビュー成分の両方を含むことができる。同様に、スケーラブルビデオコーディングのコンテキストにおいて、レイヤは、通常、他のレイヤ内のコード化ピクチャと異なるビデオ特性を有するコード化ピクチャに対応する。そのようなビデオ特性は、通常、空間解像度と品質レベル（たとえば、信号対雑音比）とを含む。ＨＥＶＣおよびその拡張では、時間スケーラビリティは、特定の時間レベルを有するピクチャのグループをサブレイヤとして定義することによって、１つのレイヤ内で実現され得る。
[0072]ビットストリームのそれぞれのレイヤの各々に、下位レイヤ内のデータは、いかなる上位レイヤ内のデータとも無関係に復号され得る。スケーラブルビデオコーディングでは、たとえば、ベースレイヤ内のデータは、エンハンスメントレイヤ内のデータと無関係に復号され得る。一般に、ＮＡＬユニットは、単一のレイヤのデータをカプセル化することだけができる。したがって、ビットストリームの残りの最上位の残存レイヤのデータをカプセル化するＮＡＬユニットは、ビットストリームの残存レイヤ内のデータの復号可能性に影響を及ぼすことなく、ビットストリームから除去され得る。マルチビューコーディングおよび３Ｄ−ＨＥＶＣでは、上位レイヤは、さらなるビュー成分を含み得る。ＳＨＶＣでは、上位レイヤは、信号対雑音比（ＳＮＲ）エンハンスメントデータ、空間エンハンスメントデータ、および／または時間エンハンスメントデータを含む場合がある。ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、およびＳＨＶＣでは、ビデオデコーダが、あるレイヤ内のピクチャをいかなる他のレイヤのデータとも無関係に復号することができる場合、そのレイヤは「ベースレイヤ」と呼ばれる場合がある。ベースレイヤは、ＨＥＶＣ基本仕様（たとえば、ＨＥＶＣ ＷＤ）に準拠することができる。
[0073]ＳＶＣでは、ベースレイヤ以外のレイヤは、「エンハンスメントレイヤ」と呼ばれる場合があり、ビットストリームから復号されるビデオデータの視覚的品質を向上させる情報を提供することができる。ＳＶＣは、空間分解能、信号対雑音比（すなわち、品質）、または時間レートを向上させることができる。スケーラブルビデオコーディング（たとえば、ＳＨＶＣ）では、「レイヤ表現」は、単一のアクセスユニット内の空間レイヤのコード化表現であり得る。説明を簡単にするために、本開示は、ビュー成分および／またはレイヤ表現を「ビュー成分／レイヤ表現」または単に「ピクチャ」と呼ぶ場合がある。
[0074]レイヤを実装するために、ＮＡＬユニットのヘッダは、ｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓシンタックス要素を含む場合がある。ＨＥＶＣ ＷＤでは、ｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓシンタックス要素は予備（reserved）である。しかしながら、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、およびＳＶＣでは、ｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓシンタックス要素は、ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素と呼ばれる。ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は、レイヤの識別子を指定する。様々な値を指定するｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を有するビットストリームのＮＡＬユニットは、ビットストリームの様々なレイヤに属する。
[0075]いくつかの例では、ＮＡＬユニットが、マルチビューコーディング（たとえば、ＭＶ−ＨＥＶＣ）、３ＤＶコーディング（たとえば、３Ｄ−ＨＥＶＣ）、またはスケーラブルビデオコーディング（たとえば、ＳＨＶＣ）におけるベースレイヤに関係する場合、ＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は０に等しい。ＮＡＬユニットが、マルチビューコーディング、３ＤＶ、またはスケーラブルビデオコーディングにおけるベースレイヤに関係しない場合、ＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は０でない値を有する場合がある。
[0076]さらに、レイヤ内のいくつかのビュー成分／レイヤ表現は、同じレイヤ内の他のビュー成分／レイヤ表現と無関係に復号され得る。したがって、レイヤのいくつかのビュー成分／レイヤ表現のデータをカプセル化するＮＡＬユニットは、そのレイヤ内の他のビュー成分／レイヤ表現の復号可能性に影響を及ぼすことなく、ビットストリームから除去され得る。そのようなビュー成分／レイヤ表現のデータをカプセル化するＮＡＬユニットを除去すると、ビットストリームのフレームレートが低減することができる。レイヤ内の他のビュー成分／レイヤ表現と無関係に復号され得るレイヤ内のビュー成分／レイヤ表現のサブセットは、本明細書では「サブレイヤ」または「時間サブレイヤ」と呼ばれる場合がある。
[0077]ＮＡＬユニットは、ＮＡＬユニットの時間識別子（すなわち、ＴｅｍｐｏｒａｌＩｄ）を指定するｔｅｍｐｏｒａｌ＿ｉｄシンタックス要素を含む場合がある。ＮＡＬユニットの時間識別子は、そのＮＡＬユニットが属するサブレイヤを識別する。したがって、レイヤの各サブレイヤは、異なる時間識別子を有する場合がある。一般に、レイヤの第１のＮＡＬユニットの時間識別子が同じレイヤの第２のＮＡＬユニットの時間識別子よりも小さい場合、第１のＮＡＬユニットによってカプセル化されたデータは、第２のＮＡＬユニットによってカプセル化されたデータと無関係に復号され得る。
[0078]ビットストリームは、複数のオペレーションポイントに関連付けられる場合がある。ビットストリームの各オペレーションポイントは、レイヤ識別子のセット（たとえば、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値のセット）および時間識別子に関連付けられる。レイヤ識別子のセットは、ＯｐＬａｙｅｒＩｄＳｅｔと表記されることがあり、時間識別子はＴｅｍｐｏｒａｌＩＤと表記される場合がある。ＮＡＬユニットのレイヤ識別子がオペレーションポイントのレイヤ識別子のセットの中にあり、ＮＡＬユニットの時間識別子がオペレーションポイントの時間識別子以下である場合、ＮＡＬユニットはオペレーションポイントに関連付けられる。したがって、オペレーションポイントは、ビットストリーム内のＮＡＬユニットのサブセット（たとえば、真部分集合）に対応する場合がある。
[0079]ＭＰＥＧ−２システム仕様は、デジタル送信または記憶に適した単一のデータストリームを形成するために、圧縮マルチメディア（ビデオおよびオーディオ）データストリームが他のデータとともにどのように多重化され得るかを記述している。ＭＰＥＧ−２ ＴＳの最新仕様は、ＩＴＵ−Ｔ勧告Ｈ．２２２．０、２０１２年６月版（本明細書では「ＭＰＥＧ−２ ＴＳ」）であり、アドバンストビデオコーディング（ＡＶＣ）およびＡＶＣ拡張のサポートが提供される。最近、ＨＥＶＣについてのＭＰＥＧ−２ ＴＳの改正案が開発された。最新文書は、ＭＰＥＧ出力文書Ｎ１３６５６、２０１３年７月の中の「Ｔｅｘｔ ｏｆ ＩＳＯ／ＩＥＣ１３８１８−１：２０１３／Ｆｉｎａｌ Ｄｒａｆｔ Ａｍｅｎｄｍｅｎｔ ３−Ｔｒａｎｓｐｏｒｔ ｏｆ ＨＥＶＣ ｖｉｄｅｏ ｏｖｅｒ ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ」である。
[0080]ＭＰＥＧ−２システム仕様は、エレメンタリストリームの概念を定義する。具体的には、エレメンタリストリームは、単一のデジタル的にコーディングされた（場合によってはＭＰＥＧ圧縮された）プログラムの構成要素である。たとえば、プログラムのコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、第一に、プログラムストリームまたはトランスポートストリームに多重化される前に、パケット化エレメンタリストリーム（ＰＥＳ）に変換される。同じプログラム内では、１つのエレメンタリストリームに属するＰＥＳパケットを別のものと区別するために、ｓｔｒｅａｍ＿ｉｄが使用される。
[0081]加えて、ＭＰＥＧ−２システム仕様は、プログラムストリームおよびトランスポートストリームの概念を定義する。プログラムストリームおよびトランスポートストリームは、異なるアプリケーションをターゲットにする２つの代替的な多重化である。プログラムストリームは、デジタルストレージサービスからの単一のプログラムの記憶および表示のためにバイアスされ、プログラムストリームは、誤りが起こりやすいので、誤りのない環境での使用を目的とする。対照的に、トランスポートストリームは、潜在的に誤りを起こしやすいチャネルを介するいくつかのプログラムの同時配信を目的とする。一般に、トランスポートストリームは、単一のトランスポートストリームが多くの独立したプログラムに適応することができるように、ブロードキャストなどのマルチプログラムアプリケーションのために考案された多重化である。プログラムストリームは、それに属するエレメンタリストリームを備えるにすぎず、通常、可変長のパケットを有するパケットを含んでいる。
[0082]プログラムストリームでは、寄与しているエレメンタリストリームから導出されたＰＥＳパケットが「パック」に編成される。パックは、パックヘッダと、オプションのシステムヘッダと、寄与しているエレメンタリストリーム（すなわち、プログラムストリームのエレメンタリストリーム）のいずれかから取られる任意の数のＰＥＳパケットとを任意の順序で備える。システムヘッダは、プログラムストリームの最大データレート、プログラムストリームの寄与しているビデオおよびオーディオのエレメンタリストリームの数、およびさらなるタイミング情報などの、プログラムストリームの特性の概要を含んでいる。ビデオデコーダ３０などのデコーダは、デコーダがプログラムストリームを復号することが可能であるかどうかを決定するために、システムヘッダに含まれている情報を使用することができる。
[0083]トランスポートストリームは、一連のトランスポートパケットを備える。トランスポートパケットは、ＰＥＳパケットの１つのタイプである。トランスポートパケットの各々は、１８８バイト長である。トランスポートストリーム内の短い固定長パケットの使用は、トランスポートストリームがプログラムストリームよりも誤りが起こりにくいことを意味する。さらに、リードソロモン符号化などの標準的な誤り保護プロセスを介してトランスポートパケットを処理すると、各々１８８バイト長のトランスポートパケットのさらなる誤り保護を与えることができる。トランスポートストリームの誤り耐性の改善は、ブロードキャスト環境において発見されるものなどの、誤りを起こしやすいチャネルを克服するより良い機会をトランスポートストリームが有することを意味する。トランスポートストリームの誤り耐性およびトランスポートストリーム内で多くの同時プログラムを搬送する能力が増大すると仮定すると、トランスポートストリームが明らかに２つの多重化（すなわち、プログラムストリームおよびトランスポートストリーム）のうちの良い方であるように見える。しかしながら、トランスポートストリームは、プログラムストリームよりもさらに高度な多重化であり、その結果、作成および逆多重化を行うことがより困難である。
[0084]トランスポートパケットの最初のバイトは同期バイトであり、０ｘ４７である。単一のトランスポートストリームは、各々が多くのパケット化エレメンタリストリームを備える、多くの様々なプログラムを搬送することができる。加えて、トランスポートパケットは、１３ビットのパケット識別子（ＰＩＤ）フィールドを含む。ＰＩＤフィールドは、あるエレメンタリストリームのデータを含むトランスポートパケットを、他のエレメンタリストリームのデータを搬送するトランスポートパケットと区別するために使用される。各エレメンタリストリームが一意のＰＩＤ値を与えられることを保証することは、マルチプレクサの責務である。トランスポートパケットの最後のバイトは連続カウントフィールドである。連続カウントフィールドの値は、同じエレメンタリストリームに属する連続するトランスポートパケットの間で増分される。連続カウントフィールドの値を増分すると、デコーダ３０などのデコーダが、トランスポートパケットの減少または増加を検出し、そうでない場合トランスポートパケットの減少または増加からもたらされる場合がある誤りを潜在的に隠すことが可能になる。
[0085]トランスポートパケットが属するエレメンタリストリームは、トランスポートパケットのＰＩＤ値に基づいて決定される場合があるが、デコーダは、どのエレメンタリストリームがどのプログラムに属するかを決定することができる必要があり得る。したがって、プログラム固有情報は、プログラムと構成要素のエレメンタリストリームとの間の関係を明示的に指定する。たとえば、プログラム固有情報は、プログラムとプログラムに属するエレメンタリストリームとの間の関係を指定することができる。トランスポートストリームのプログラム固有情報には、プログラムマップテーブル（ＰＭＴ）、プログラム関連テーブル（ＰＡＴ）、限定アクセステーブル、およびネットワーク情報テーブルが含まれ得る。
[0086]トランスポートストリーム内で搬送されるすべてのプログラムは、プログラムマップテーブル（ＰＭＴ）に関連付けられる。ＰＭＴは、２つ以上のプログラムを含むことが許可される。たとえば、トランスポートストリーム内で搬送される複数のプログラムは、同じＰＭＴに関連付けられ得る。プログラムに関連付けられたＰＭＴは、そのプログラムおよびそのプログラムを備えるエレメンタリストリームに関する詳細を与える。たとえば、番号３を有するプログラムは、ＰＩＤ３３を有するビデオと、ＰＩＤ５７を有する英語のオーディオと、ＰＩＤ６０を有する中国語のオーディオとを含んでいる場合がある。言い換えれば、この例では、ＰＭＴは、そのトランスポートパケットが３３に等しい値を有するＰＩＤフィールドを含むエレメンタリストリームが、３に等しい番号（たとえば、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒ）を有するプログラムのビデオを含んでいることと、そのトランスポートパケットが５７に等しい値を有するＰＩＤフィールドを含むエレメンタリストリームが、番号３を有するプログラムの英語のオーディオを含んでいることと、そのトランスポートパケットが６０に等しい値を有するＰＩＤフィールドを含むエレメンタリストリームが、番号３を有するプログラムの中国語のオーディオを含んでいることと、を示す場合がある。
[0087]基本ＰＭＴは、ＭＰＥＧ−２システム仕様内で指定された多くの記述子のうちのいくつかで装飾される場合がある。言い換えれば、ＰＭＴは１つまたは複数の記述子を含む含む場合がある。記述子は、プログラムまたはプログラムの構成要素のエレメンタリストリームに関するさらなる情報を搬送する。記述子は、ビデオ符号化パラメータ、オーディオ符号化パラメータ、言語識別情報、パンアンドスキャン情報、限定アクセス詳細、著作権情報などを含む場合がある。放送事業者または他のユーザは、必要な場合、追加のプライベート記述子を定義することができる。ビデオ関連構成要素のエレメンタリストリームでは、階層記述子も存在する。階層記述子は、階層的にコーディングされたビデオ、オーディオ、およびプライベートストリームの構成要素を含むプログラム要素を識別する情報を提供する。プライベートストリームは、プログラム固有情報のストリームなどのメタデータを含む場合がある。一般に、プログラム要素は、プログラム（すなわち、プログラムの構成要素のエレメンタリストリーム）に含まれるデータまたはエレメンタリストリームのうちの１つである。ＭＰＥＧ−２トランスポートストリームでは、プログラム要素は通常パケット化される。ＭＰＥＧ−２プログラムストリームでは、プログラム要素はパケット化されない。
[0088]プログラムストリームのプログラム固有情報は、プログラムストリームマップ（ＰＳＭ）を含む場合がある。プログラムストリームのＰＳＭは、プログラムストリーム内のエレメンタリストリームの記述と、エレメンタリストリームの互いとの関係とを提供する。トランスポートストリーム内で搬送されるとき、この構造は修正されてはならない。ＰＳＭは、ｓｔｒｅａｍ＿ｉｄ値が０ｘＢＣであるときにＰＥＳパケットとして存在する。
[0089]上記で示されたように、トランスポートストリームのプログラム固有情報は、プログラム関連テーブル（ＰＡＴ）を含む場合がある。トランスポートストリームのＰＡＴは、トランスポートストリーム内で利用可能なすべてのプログラムの完全なリストを含んでいる。ＰＡＴは、常にＰＩＤ値０を有する。言い換えれば、０に等しいＰＩＤ値を有するトランスポートパケットは、ＰＡＴを含んでいる。ＰＡＴは、それぞれのプログラムに関連付けられたプログラムマップテーブルを含むトランスポートパケットのＰＩＤ値とともに、トランスポートストリームの各それぞれのプログラムを列記する。たとえば、上述された例示的なＰＭＴでは、ＰＡＴは、プログラム番号３のエレメンタリストリームを指定するＰＭＴが１００１のＰＩＤを有することを指定する情報を含む場合があり、別のＰＭＴが１００２の別のＰＩＤを有することを指定する情報を含む場合がある。言い換えれば、この例では、ＰＭＴは、そのＰＩＤフィールドが１００１に等しい値を有するトランスポートパケットが、プログラム番号３のＰＭＴを含んでいることを指定する場合があり、ＰＭＴは、そのＰＩＤフィールドが１００２に等しい値を有するトランスポートパケットが、別のプログラムのＰＭＴを含んでいることを指定する場合がある。
[0090]さらに、上記で示されたように、トランスポートストリームのプログラム固有情報は、ネットワーク情報テーブル（ＮＩＴ）を含む場合がある。トランスポートストリームのＰＡＴ内で指定されたプログラム番号０は、特別な意味を有する。具体的には、プログラム番号０はＮＩＴを指す。トランスポートストリームのＮＩＴはオプションであり、存在するとき、ＮＩＴは、トランスポートストリームを搬送する物理ネットワークに関する情報を提供する。ＮＩＴは、チャネル周波数、衛星トランスポンダ詳細、変調特性、サービス発信者、サービス名称、および利用可能な代替ネットワークの詳細などの情報を提供することができる。
[0091]上記で示されたように、トランスポートストリームのプログラム固有情報は、限定アクセステーブル（ＣＡＴ）を含む場合がある。トランスポートストリーム内の任意のエレメンタリストリームがスクランブルされる場合、ＣＡＴは存在しなければならない。ＣＡＴは、使用中のスクランブリングシステムの詳細を提供し、限定アクセス管理（conditional access management）と資格情報(entitle information)とを含むトランスポートパケットのＰＩＤ値を提供する。ＭＰＥＧ−２は、この情報のフォーマットを指定しない。
[0092]上記で示されたように、ＰＭＴは、プログラムまたはプログラムの構成要素のエレメンタリストリームに関する情報を搬送する、１つまたは複数の記述子を含む場合がある。ＰＭＴ内の１つまたは複数の記述子は、階層記述子を含む場合がある。ＭＰＥＧ−２トランスポートストリーム（ＴＳ）では、階層記述子は、様々なエレメンタリストリーム内でサブビットストリームの階層をシグナリングするように設計されている。階層記述子は、階層的にコーディングされたビデオ、オーディオ、およびプライベートストリームの構成要素を含むプログラム要素を識別する情報を提供する。下記の表２−４９は、階層記述子のシンタックスを示す。表２−４９に続く段落は、階層記述子のフィールドのセマンティクスを記載する。
Figure 0006553054
[0093]ｔｅｍｐｏｒａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ−「０」に設定されると、関連するプログラム要素が、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘによって参照されるプログラム要素から得られるビットストリームのフレームレートを向上させることを示す、１ビットフラグ。このフラグ用の「１」の値は予約済みである。
[0094]ｓｐａｔｉａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ−「０」に設定されると、関連するプログラム要素が、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘによって参照されるプログラム要素から得られるビットストリームの空間解像度を向上させることを示す、１ビットフラグ。このフラグ用の「１」の値は予約済みである。
[0095]ｑｕａｌｉｔｙ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ−「０」に設定されると、関連するプログラム要素が、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘによって参照されるプログラム要素から得られるビットストリームのＳＮＲ品質または忠実度を向上させることを示す、１ビットフラグ。このフラグ用の「１」の値は予約済みである。
[0096]ｈｉｅｒａｒｃｈｙ＿ｔｙｐｅ−関連する階層レイヤとその階層組込み型レイヤとの間の階層関係が（下記に示される）表２−５０において定義される。スケーラビリティが２つ以上の次元において適用される場合、このフィールドは、「８」の値（「合成スケーラビリティ」）に設定されることになり、フラグｔｅｍｐｏｒａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、ｓｐａｔｉａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、およびｑｕａｌｉｔｙ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇはそれに応じて設定されることになる。ＭＶＣビデオサブビットストリームの場合、このフィールドは、「９」の値（「ＭＶＣビデオサブビットストリーム」）に設定されることになり、フラグｔｅｍｐｏｒａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、ｓｐａｔｉａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、およびｑｕａｌｉｔｙ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、「１」に設定されることになる。ＭＶＣベースビューサブビットストリームの場合、ｈｉｅｒａｒｃｈｙ＿ｔｙｐｅフィールドは、「１５」の値に設定されることになり、フラグｔｅｍｐｏｒａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、ｓｐａｔｉａｌ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇ、およびｑｕａｌｉｔｙ＿ｓｃａｌａｂｉｌｉｔｙ＿ｆｌａｇは、「１」に設定されることになる。
[0097]ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘ−ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘは、コーディングレイヤ階層のテーブルにおいて関連するプログラム要素の一意のインデックスを定義する６ビットフィールドである。インデックスは、単一のプログラム定義内で一意でなければならない。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｇにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームのビデオサブビットストリームの場合、これは、同じアクセスユニットのビデオサブビットストリームの関連するＳＶＣ依存性表現が、ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で再アセンブルされる場合にビットストリーム順序が正しくなるように割り当てられる、プログラム要素インデックスである。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームのＭＶＣビデオサブビットストリームの場合、これは、同じアクセスユニットのＭＶＣビデオサブビットストリームの関連するＭＶＣビュー成分サブセットが、ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で再アセンブルされる場合にビットストリーム順序が正しくなるように割り当てられる、プログラム要素インデックスである。
[0098]ｔｒｅｆ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ−「０」に設定されると、ＴＲＥＦフィールドが関連するエレメンタリストリーム内のＰＥＳパケットヘッダ内に存在できることを示す、１ビットフラグ。このフラグ用の「１」の値は予約済みである。
[0099]ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘ−ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘは、このｈｉｅｒａｒｃｈｙ＿ｄｅｓｃｒｉｐｔｏｒに関連付けられたエレメンタリストリームの復号の前に、復号順序でアクセスされ存在する必要があるプログラム要素のｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘを定義する６ビットフィールドである。ｈｉｅｒａｒｃｈｙ＿ｔｙｐｅ値が１５である場合、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドは未定義になる。
[0100]ｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌ−ｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌは、送信チャネルの順序セットにおいて関連するプログラム要素のための所期のチャネル番号を示す６ビットフィールドである。最もロバストな送信チャネルは、全体的な送信階層定義に関して、このフィールドの最低値によって定義される。所与のｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌは、いくつかのプログラム要素に同時に割り当てられ得る。
[0101]下記の表２−５０は、階層記述子のｈｉｅｒａｒｃｈｙ＿ｔｙｐｅフィールドの値の意味を記載する。
Figure 0006553054
[0102]上記で示されたように、ＰＭＴは、プログラムまたはプログラムの構成要素のエレメンタリストリームに関する情報を搬送する、１つまたは複数の記述子を含む場合がある。ＭＰＥＧ−２ ＴＳでは、２つの記述子、ＳＶＣ拡張記述子およびＭＶＣ拡張記述子は、それぞれ、ＳＶＣおよびＭＶＣの場合のサブビットリームの特性をシグナリングする。加えて、オペレーションポイントの特性を記述するＭＶＣオペレーションポイント記述子が存在する。３つの記述子のシンタックスおよびセマンティクスが、下記に提供される。
[0103]Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｇにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームのビデオサブビットストリームの場合、ＳＶＣ拡張記述子は、（最大）関連するビデオサブビットストリームを再アセンブルすることから得られるＡＶＣビデオストリームに関する情報を提供し、関連するビデオサブビットストリームのスケーラビリティおよび再アセンブリに関する情報を提供する。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｇにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームのビデオサブビットストリームのいずれかに関連付けられた、１つのＳＶＣ拡張記述子が存在する場合がある。表２−９６は、ＳＶＣ拡張記述子のシンタックスを記載する。表２−９６に続く段落は、ＳＶＣ拡張記述子のフィールドのセマンティクスを記載する。
Figure 0006553054
[0104]ｗｉｄｔｈ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのピクセル単位での最大画像幅解像度を示す。
[0105]ｈｅｉｇｈｔ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのピクセル単位での最大画像高さ解像度を示す。
[0106]ｆｒａｍｅ＿ｒａｔｅ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのフレーム／２５６秒単位での最大フレームレートを示す。
[0107]ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのキロビット毎秒単位での平均ビットレートを示す。
[0108]ｍａｘｉｍｕｍ＿ｂｉｔｒａｔｅ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのキロビット毎秒単位での最大ビットレートを示す。
[0109]ｄｅｐｅｎｄｅｎｃｙ＿ｉｄ−この３ビットフィールドは、ビデオサブビットストリームに関連付けられたｄｅｐｅｎｄｅｎｃｙ＿ｉｄの値を示す。
[0110]ｑｕａｌｉｔｙ＿ｉｄ＿ｓｔａｒｔ−この４ビットフィールドは、関連するビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｑｕａｌｉｔｙ＿ｉｄの最小値を示す。ｑｕａｌｉｔｙ＿ｉｄは、ＮＡＬユニット用の品質識別子を指定する。
[0111]ｑｕａｌｉｔｙ＿ｉｄ＿ｅｎｄ−この４ビットフィールドは、関連するビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｑｕａｌｉｔｙ＿ｉｄの最大値を示す。
[0112]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｓｔａｒｔ−この３ビットフィールドは、関連するビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｔｅｍｐｏｒａｌ＿ｉｄの最小値を示す。
[0113]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｅｎｄ−この３ビットフィールドは、関連するビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｔｅｍｐｏｒａｌ＿ｉｄの最大値を示す。
[0114]ｎｏ＿ｓｅｉ＿ｎａｌ＿ｕｎｉｔ＿ｐｒｅｓｅｎｔ−この１ビットフラグは、「１」に設定されると、ＳＥＩ ＮＡＬユニットが関連するビデオサブビットストリーム内に存在しないことを示す。ｎｏ＿ｓｅｉ＿ｎａｌ＿ｕｎｉｔ＿ｐｒｅｓｅｎｔフラグが、すべてのＳＶＣビデオサブビットストリームに対して「１」に設定され、ＳＶＣのＡＶＣビデオサブビットストリームに対して「１」に設定されていないか、または存在しない場合、任意のＳＥＩ ＮＡＬユニットは、存在する場合、ＳＶＣのＡＶＣビデオサブビットストリームに含まれる。すべてのビデオサブビットストリームについてＳＶＣ拡張記述子がない場合、ＳＥＩ ＮＡＬユニットは、ＳＶＣビデオサブビットストリームのいずれかのＳＶＣ依存性表現内に存在する場合があり、アクセスユニットの再アセンブリングの前に、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されているように、アクセスユニット内でＮＡＬユニットの順序に並べ替えることを必要とする場合がある。
[0115]Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームのＭＶＣビデオサブビットストリームの場合、ＭＶＣ拡張記述子は、（最大）関連するＭＶＣビデオサブビットストリームを再アセンブルすることから得られるＡＶＣビデオストリームに関する情報を提供し、含まれているＭＶＣビデオサブビットストリームに関する情報と関連するＭＶＣビデオサブビットストリームの再アセンブリについての情報とを提供する。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０の付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＡＶＣビデオストリームの（ｓｔｒｅａｍ＿ｔｙｐｅが０ｘ２０に等しい）ＭＶＣビデオサブビットストリームのいずれかに関連付けられた１つのＭＶＣ拡張記述子が存在する場合がある。ＭＶＣビデオサブビットストリームがＭＶＣベースビューサブビットストリームであるとき、ＭＶＣ拡張記述子は、０ｘ１Ｂに等しいｓｔｒｅａｍ＿ｔｙｐｅについて、関連するＰＭＴまたはＰＳＭ内に存在しなければならない。表２−９７は、ＭＶＣ拡張記述子のシンタックスを記載する。表２−９７に続く段落は、ＭＶＣ拡張記述子の特定のフィールドのセマンティクスを記載する。
Figure 0006553054
[0116]ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのキロビット毎秒単位での平均ビットレートを示す。０に設定されると、平均ビットレートは示されない。
[0117]ｍａｘｉｍｕｍ＿ｂｉｔｒａｔｅ−この１６ビットフィールドは、再アセンブルされたＡＶＣビデオストリームのキロビット毎秒単位での最大ビットレートを示す。０に設定されると、最大ビットレートは示されない。
[0118]ｖｉｅｗ＿ｏｒｄｅｒ＿ｉｎｄｅｘ＿ｍｉｎ−この１０ビットフィールドは、関連するＭＶＣビデオサブビットストリームに含まれているすべてのＮＡＬユニットのビュー順序インデックスの最小値を示す。
[0119]ｖｉｅｗ＿ｏｒｄｅｒ＿ｉｎｄｅｘ＿ｍａｘ−この１０ビットフィールドは、関連するＭＶＣビデオサブビットストリームに含まれているすべてのＮＡＬユニットのビュー順序インデックスの最大値を示す。
[0120]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｓｔａｒｔ−この３ビットフィールドは、関連するＭＶＣビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｔｅｍｐｏｒａｌ＿ｉｄの最小値を示す。
[0121]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｅｎｄ−この３ビットフィールドは、関連するＭＶＣビデオサブビットストリームに含まれているすべてのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｔｅｍｐｏｒａｌ＿ｉｄの最大値を示す。
[0122]ｎｏ＿ｓｅｉ＿ｎａｌ＿ｕｎｉｔ＿ｐｒｅｓｅｎｔ−この１ビットフラグは、「１」に設定されると、ＳＥＩ ＮＡＬユニットが関連するビデオサブビットストリーム内に存在しないことを示す。ｎｏ＿ｓｅｉ＿ｎａｌ＿ｕｎｉｔ＿ｐｒｅｓｅｎｔフラグが、すべてのＭＶＣビデオサブビットストリームに対して「１」に設定され、ＭＶＣのＡＶＣビデオサブビットストリームに対して「１」に設定されていないか、または存在しない場合、任意のＳＥＩ ＮＡＬユニットは、存在する場合、ＭＶＣのＡＶＣビデオサブビットストリームに含まれる。すべてのＭＶＣビデオサブビットストリームについてＭＶＣ拡張記述子がない場合、ＳＥＩ ＮＡＬユニットは、ＭＶＣビデオサブビットストリームのいずれかのＭＶＣビュー成分サブセット内に存在する場合があり、アクセスユニットの再アセンブリングの前に、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されているように、アクセスユニット内でＮＡＬユニットの順序に並べ替えることを必要とする場合がある。
[0123]ｎｏ＿ｐｒｅｆｉｘ＿ｎａｌ＿ｕｎｉｔ＿ｐｒｅｓｅｎｔ−この１ビットフラグは、「１」に設定されると、プレフィックスＮＡＬユニットがＭＶＣのＡＶＣビデオサブビットストリームまたはＭＶＣビデオサブビットストリームのいずれかの中に存在しないことを示す。このビットが「０」に設定されると、プレフィックスＮＡＬユニットがＭＶＣのＡＶＣビデオサブビットストリームの中にのみ存在することを示す。
[0124]ＭＶＣオペレーションポイント記述子は、１つまたは複数のオペレーションポイントについてのプロファイルとレベルの情報とを示す。
[0125]１つまたは複数のオペレーションポイントの各々は、１つまたは複数のＭＶＣビデオサブビットストリームのセットによって構成される。存在する場合、ＭＶＣオペレーションポイント記述子は、ｐｒｏｇｒａｍ＿ｍａｐ＿ｓｅｃｔｉｏｎ内のｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドの直後のデータ要素のグループに含まれることになる。ＭＶＣオペレーションポイント記述子がプログラム記述内に存在する場合、同じプログラム内に存在するＭＶＣビデオサブビットストリームごとに少なくとも１つの階層記述子が存在しなければならない。様々なプロファイルを示すために、プロファイル当たり１つのＭＶＣオペレーションポイント記述子が必要とされる。表２−１００は、ＭＶＣオペレーションポイント記述子のシンタックスを規定する。表２−１００に続く段落は、ＭＶＣオペレーションポイント記述子のフィールドのセマンティクスを記載する。
Figure 0006553054
[0126]ｐｒｏｆｉｌｅ＿ｉｄｃ−この８ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されているように、ＭＶＣビットストリーム用のこの記述子内で記述されるすべてのオペレーションポイントのプロファイルを示す。
[0127]ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ０＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ１＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ２＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ３＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ４＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ５＿ｆｌａｇ−これらのフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されている、これらのフィールドについてのセマンティクスに従ってコーディングされることになる。
[0128]ＡＶＣ＿ｃｏｍｐａｔｉｂｌｅ＿ｆｌａｇｓ−ＡＶＣ＿ｃｏｍｐａｔｉｂｌｅ＿ｆｌａｇｓのセマンティクスは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されているように、シーケンスパラメータセット内のｃｏｎｓｔｒａｉｎｔ＿ｓｅｔ２フラグとｌｅｖｅｌ＿ｉｄｃフィールドとの間の２ビットに対して定義されるフィールドのセマンティクスに正確に等しい。
[0129]ｌｅｖｅｌ＿ｃｏｕｎｔ−この８ビットフィールドは、オペレーションポイントが記述されるレベルの数を示す。
[0130]ｌｅｖｅｌ＿ｉｄｃ−この８ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０において定義されているように、データ要素の以下のグループによって記述されるオペレーションポイントについてのＭＶＣビットストリームのレベルを示す。
[0131]ｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔｓ＿ｃｏｕｎｔ−この８ビットフィールドは、データ要素の以下のグループに含まれるリストによって記述されるオペレーションポイントの数を示す。
[0132]ａｐｐｌｉｃａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｉｄ−この３ビットフィールドは、再アセンブルされたＡＶＣビデオストリーム内のＶＣＬ ＮＡＬユニットのｔｅｍｐｏｒａｌ＿ｉｄの最高値を示す。
[0133]ｎｕｍ＿ｔａｒｇｅｔ＿ｏｕｔｐｕｔ＿ｖｉｅｗｓ−この８ビットフィールドは、関連するオペレーションポイントについての出力の対象とされるビューの数の値を示す。
[0134]ＥＳ＿ｃｏｕｎｔ−この８ビットフィールドは、データ要素の以下のグループに含まれるＥＳ＿ｒｅｆｅｒｅｎｃｅ値の数を示す。データ要素の以下のグループ内で示されるエレメンタリストリームは、ＭＶＣビデオビットストリームのオペレーションポイントを一緒に形成する。値０ｘｆｆは予約済みである。
[0135]ＥＳ＿ｒｅｆｅｒｅｎｃｅ−この６ビットフィールドは、ビデオサブビットストリームを識別する階層記述子内に存在する階層レイヤインデックス値を示す。単一のオペレーションポイント、たとえば、ＭＶＣビデオビットストリーム全体についてのプロファイルおよびレベルは、ＡＶＣビデオ記述子を使用してシグナリングされ得る。その上、ＭＶＣにより、様々なプロファイルおよび／またはレベルを必要とする可能性がある様々なビューサブセットを復号することが可能になる。ＭＶＣオペレーションポイント記述子の仕様は、複数のオペレーションポイントについての様々なプロファイルおよびレベルの指示をサポートする。
[0136]ＨＥＶＣビデオストリームの場合、ＨＥＶＣビデオ記述子は、そのＨＥＶＣビデオストリームの、プロファイルおよびレベルのパラメータなどのコーディングパラメータを識別するための基本情報を提供する。ＨＥＶＣ時間ビデオサブビットストリームまたはＨＥＶＣ時間ビデオサブセットの場合、ＨＥＶＣビデオ記述子は、それが適用されるエレメンタリストリームに含まれている、関連するＨＥＶＣ最高時間サブレイヤ表現などの情報を提供する。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において規定されているように、０に等しいＴｅｍｐｏｒａｌＩｄに関連付けられた時間サブレイヤのすべてのＶＣＬ ＮＡＬユニットと関連する非ＶＣＬ ＮＡＬユニットとを含み、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において規定されているように、１から、アクティブなシーケンスパラメータセットに含まれるｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１に等しいか、またはそれより小さい値までの、連続範囲のＴｅｍｐｏｒａｌＩｄに関連付けられたすべての時間サブレイヤのすべてのＶＣＬ ＮＡＬユニットと関連する非ＶＣＬ ＮＡＬユニットとをさらに含む場合がある、ＨＥＶＣ時間ビデオサブビットストリーム。ＨＥＶＣ時間ビデオサブセットは、１つまたは複数の時間サブレイヤのすべてのＶＣＬ ＮＡＬユニットと関連する非ＶＣＬ ＮＡＬユニットとを含んでおり、対応するＨＥＶＣ時間ビデオサブビットストリーム内に存在しない各時間サブレイヤ、および各時間サブレイヤに関連付けられたＴｅｍｐｏｒａｌＩｄは、連続範囲の値を形成する。
[0137]下記の表Ｘ−１は、ＨＥＶＣビデオ記述子のシンタックスを示す。表Ｘ−１に続く段落は、ＨＥＶＣビデオ記述子内のフィールドのセマンティック定義を提供する。
Figure 0006553054
[0138]ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｔｉｅｒ＿ｆｌａｇ、ｐｒｏｆｉｌｅ＿ｉｄｃ、ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｌｅｖｅｌ＿ｉｄｃ−ＨＥＶＣビデオ記述子が、ＨＥＶＣビデオストリームまたはＨＥＶＣ完全時間表現に適用されるとき、これらのフィールドは、対応するＨＥＶＣビデオストリームまたはＨＥＶＣ完全時間表現について、それぞれ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ［ｉ］、ｇｅｎｅｒａｌ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃについて、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているセマンティクスに従ってコーディングされなければならず、ＨＥＶＣビデオ記述子が関連付けられるＨＥＶＣビデオストリームまたはＨＥＶＣ完全時間表現全体は、これらのフィールドによってシグナリングされる情報に準拠しなければならない。
[0139]ＨＥＶＣビデオ記述子が、その対応するＨＥＶＣ最高時間サブレイヤ表現がＨＥＶＣ完全時間表現（すなわち、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において規定されているように、アクティブなシーケンスパラメータセットに含まれるｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１＋１に等しいＴｅｍｐｏｒａｌＩｄを有する時間サブレイヤまでのすべての時間サブレイヤを含んでいる、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているサブレイヤ表現）ではない、ＨＥＶＣ時間ビデオサブビットストリームまたはＨＥＶＣ時間ビデオサブセットに適用されるとき、ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｔｉｅｒ＿ｆｌａｇ、ｐｒｏｆｉｌｅ＿ｉｄｃ、ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｌｅｖｅｌ＿ｉｄｃは、対応するＨＥＶＣ最高時間サブレイヤ表現について、それぞれ、ｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｓｕｂ＿ｌａｙｅｒ＿ｔｉｅｒ＿ｆｌａｇ、ｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ［ｉ］、ｓｕｂ＿ｌａｙｅｒ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｓｕｂ＿ｌａｙｅｒ＿ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｓｕｂ＿ｌａｙｅｒ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｓｕｂ＿ｌａｙｅｒ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｓｕｂ＿ｌａｙｅｒ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｓｕｂ＿ｌａｙｅｒ＿ｌｅｖｅｌ＿ｉｄｃについて、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているセマンティクスに従ってコーディングされなければならず、ＨＥＶＣビデオ記述子が関連付けられるＨＥＶＣ最高時間サブレイヤ表現全体は、これらのフィールドによってシグナリングされる情報に準拠しなければならない。ＨＥＶＣ完全時間表現は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において規定されているように、アクティブなシーケンスパラメータセットに含まれるｓｐｓ＿ｍａｘ＿ｓｕｂ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１＋１に等しいＴｅｍｐｏｒａｌＩｄを有する時間サブレイヤまでのすべての時間サブレイヤを含んでいる、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているサブレイヤ表現である。ＨＥＶＣ最高時間サブレイヤ表現は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているように、関連するＨＥＶＣ時間ビデオサブビットストリームまたはＨＥＶＣ時間ビデオサブセット内の、ＴｅｍｐｏｒａｌＩｄの最高値を有する時間サブレイヤのサブレイヤ表現である。
注Ｘ２−ＨＥＶＣビデオストリーム内の１つまたは複数のシーケンスにおいて、レベルは、ＨＥＶＣビデオ記述子内でシグナリングされるレベルよりも低くなり得るし、一方、ＨＥＶＣビデオ記述子内でシグナリングされるプロファイルのサブセットであるプロファイルも生じる場合がある。しかしながら、ＨＥＶＣビデオストリーム全体において、存在する場合、ＨＥＶＣビデオ記述子内でシグナリングされるプロファイルに含まれる、ビットストリームシンタックス全体のサブセットのみが使用されることになる。ＨＥＶＣビデオストリーム内のシーケンスパラメータセットが異なるプロファイルをシグナリングし、追加の制約がシグナリングされない場合、ストリームは、ストリーム全体が、もしあれば、どのプロファイルに準拠するかを決定する審査を必要とする場合がある。ＨＥＶＣビデオ記述子が、単一のプロファイルに準拠しないＨＥＶＣビデオストリームに関連付けられるべきである場合、ＨＥＶＣビデオストリームは、２つ以上のサブストリームに区分化されるべきであり、その結果、ＨＥＶＣビデオ記述子は、そのようなサブストリームごとに単一のプロファイルをシグナリングすることができる。
[0140]ｔｅｍｐｏｒａｌ＿ｌａｙｅｒ＿ｓｕｂｓｅｔ＿ｆｌａｇ−この１ビットフラグは、「１」に設定されると、時間レイヤのサブセットを記述するシンタックス要素がこの記述子に含まれることを示す。このフィールドは、ＨＥＶＣ時間ビデオサブセットについて、およびＨＥＶＣ時間ビデオサブビットストリームについて、１に設定されなければならない。「０」に設定されると、シンタックス要素ｔｅｍｐｏｒａｌ＿ｉｄ＿ｍｉｎおよびｔｅｍｐｏｒａｌ＿ｉｄ＿ｍａｘは、この記述子に含まれない。
[0141]ＨＥＶＣ＿ｓｔｉｌｌ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ−この１ビットフィールドは、「１」に設定されると、ＨＥＶＣビデオストリームまたはＨＥＶＣ最高時間サブレイヤ表現がＨＥＶＣ静止ピクチャを含む場合があることを示す。「０」に設定されると、関連するＨＥＶＣビデオストリームはＨＥＶＣ静止ピクチャを含んではならない。
注Ｘ３−Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２によれば、ＩＤＲピクチャが０に等しいＴｅｍｐｏｒａｌＩｄ値に常に関連付けられ、その結果、ＨＥＶＣビデオ記述子がＨＥＶＣ時間ビデオサブセットに適用される場合、ＨＥＶＣ静止ピクチャは、関連するＨＥＶＣ時間ビデオサブビットストリーム内にのみ存在することができる。
[0142]ＨＥＶＣ＿２４＿ｈｏｕｒ＿ｐｉｃｔｕｒｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ−この１ビットフラグは、「１」に設定されると、関連するＨＥＶＣビデオストリームまたはＨＥＶＣ最高時間サブレイヤ表現が、ＨＥＶＣ２４時間ピクチャを含む場合があることを示す。ＨＥＶＣ２４時間ピクチャの定義については、Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ Ｃｏｄｉｎｇ ｏｆ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ａｕｄｉｏ Ｉｎｆｏｒｍａｔｉｏｎ：Ｓｙｓｔｅｍｓ、Ａｍｅｎｄｍｅｎｔ ３、Ｔｒａｎｓｐｏｒｔ ｏｆ ＨＥＶＣ ｖｉｄｅｏ ｏｖｅｒ ＭＰＥＧ−２ ｓｙｓｔｅｍｓの２．１．９７を参照。このフラグが「０」に設定される場合、関連するＨＥＶＣビデオストリームは、いかなるＨＥＶＣ２４時間ピクチャも含んではならない。
[0143]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｍｉｎ−この３ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているように、関連するエレメンタリストリーム内のすべてのＨＥＶＣアクセスユニットのＴｅｍｐｏｒａｌＩｄの最小値を示す。
[0144]ｔｅｍｐｏｒａｌ＿ｉｄ＿ｍａｘ−この３ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているように、関連するエレメンタリストリーム内のすべてのＨＥＶＣアクセスユニットのＴｅｍｐｏｒａｌＩｄの最大値を示す。
[0145]Ｃｈｅｎら、「Ｃａｒｒｉａｇｅ ｏｆ ＨＥＶＣ ｅｘｔｅｎｓｉｏｎ ｓｔｒｅａｍｓ ｗｉｔｈ ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ」、ＭＰＥＧ入力文書ｍ３１４３０、第１０６回ＭＰＥＧ会合、２０１３年１０月、ジュネーブ、スイス、ＭＰＥＧ入力文書ｍ３１４３０（本明細書では「ＭＰＥＧ入力文書ｍ３１４３０」）は、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送の基本設計を提案している。具体的には、ＭＰＥＧ入力文書ｍ３１４３０は、オペレーションポイントを形成するためにサブビットストリームが一緒にアセンブルされることを提案している。サブビットストリームのアセンブリングは一般的であり、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、またはさらに３Ｄ−ＨＥＶＣなどの、任意のＨＥＶＣマルチレイヤ拡張規格に役立つ。
[0146]ＭＰＥＧ入力文書ｍ３１４３０のいくつかの基本設計原理は、以下のように要約される。第１に、Ｇｒｕｎｅｂｅｒｇら、「Ｔｅｘｔ ｏｆ ＩＳＯ／ＩＥＣ１３８１８−１：２０１３／Ｆｉｎａｌ Ｄｒａｆｔ Ａｍｅｎｄｍｅｎｔ ３−Ｔｒａｎｓｐｏｒｔ ｏｆ ＨＥＶＣ ｖｉｄｅｏ ｏｖｅｒ ＭＰＥＧ−２ Ｓｙｓｔｅｍｓ」、ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ１０５／Ｎ１３６５６、２０１３年７月、ウィーン、オーストリア（本明細書では「ｎ１３６５６」または「ＦＤＡＭ３」）における階層記述子が、時間サブレイヤの階層を形成するために使用される。同様に、複数のレイヤが関連するとき、階層記述子は時間スケーラビリティのためのみに使用される。
[0147]第２の設計原理は、ＭＰＥＧ入力文書ｍ３１４３０において、レイヤ（たとえば、ビュー、ベースレイヤ、エンハンスメントレイヤ）の階層を形成するために、新しい記述子、すなわち階層拡張記述子の導入を備える。詳細には、階層拡張記述子は、階層的にコーディングされたビデオ、オーディオ、およびプライベートストリームの構成要素を含むプログラム要素を識別する情報を提供する。ＭＰＥＧ入力文書ｍ３１４３０は、各エレメンタリストリームが２つ以上のレイヤを含んでいないことを仮定する。したがって、階層拡張記述子は、１つの一意のレイヤに対応するエレメンタリストリームのみに関係する。階層拡張記述子のシンタックスおよびセマンティクスは、文書ｍ３１４３０において提示されているように、下記に転載される。
Figure 0006553054
２．６．９８ 階層拡張記述子内のフィールドのセマンティック定義
階層拡張記述子が存在するとき、階層拡張記述子は、様々なエレメンタリストリーム内に存在するレイヤの依存性を指定するために使用される。しかしながら、時間サブレイヤの集合は、ＩＳＯ／ＩＥＣ１３８１８−１の改定３において規定されているように、階層記述子によって実現される。
ｅｘｔｅｎｓｉｏｎ＿ｄｉｍｅｎｓｉｏｎ＿ｂｉｔｓ−０に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤのプログラム要素から得られるベースレイヤからの関連するプログラム要素の可能なエンハンスメントを示す１６ビットフィールド。
エンハンスメント次元へのビットの割当ては、以下の通りである。
Figure 0006553054
１に等しいｉ番目のビットは、対応するエンハンスメント次元が存在することを示す。
ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘ−ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘは、コーディングレイヤ階層のテーブルにおいて関連するプログラム要素の一意のインデックスを定義する６ビットフィールドである。インデックスは、単一のプログラム定義内で一意でなければならない。Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類ＧまたはＨにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣビデオストリームのビデオサブビットストリームの場合、これは、同じアクセスユニットのビデオサブビットストリームの関連する依存レイヤが、ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で再アセンブルされる場合にビットストリーム順序が正しくなるように割り当てられる、プログラム要素インデックスである。
ｔｒｅｆ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ−「０」に設定されると、ＴＲＥＦフィールドが関連するエレメンタリストリーム内のＰＥＳパケットヘッダ内に存在できることを示す、１ビットフラグ。このフラグ用の「１」の値は予約済みである。
ｎｕｈ＿ｌａｙｅｒ＿ｉｄ−６ビットフィールドは、このｈｉｅｒａｒｃｈｙ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ（）に関連付けられたエレメンタリストリーム内のＮＡＬユニットの最高のｎｕｈ＿ｌａｙｅｒ＿ｉｄを指定する。
ｔｅｍｐｏｒａｌ＿ｉｄ−３ビットフィールドは、このｈｉｅｒａｒｃｈｙ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ（）に関連付けられたエレメンタリストリーム内のＮＡＬユニットの最高のＴｅｍｐｏｒａｌＩｄを指定する。
ｎｕｍ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒｓ−このｈｉｅｒａｒｃｈｙ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ（）に関連付けられたエレメンタリストリームの復号の前に、復号順序でアクセスされ存在する必要がある直接依存プログラム要素の数を指定する６ビットフィールド。
ｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘ−ｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘは、このｈｉｅｒａｒｃｈｙ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに関連付けられたエレメンタリストリームの復号の前に、復号順序でアクセスされ存在する必要があるプログラム要素のｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘを定義する６ビットフィールドである。ｈｉｅｒａｒｃｈｙ＿ｔｙｐｅ値が１５である場合、このフィールドは未定義になる。
ｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌ−ｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌは、送信チャネルの順序セットにおいて関連するプログラム要素のための所期のチャネル番号を示す６ビットフィールドである。最もロバストな送信チャネルは、全体的な送信階層定義に関して、このフィールドの最低値によって定義される。
注−所与のｈｉｅｒａｒｃｈｙ＿ｃｈａｎｎｅｌは、いくつかのプログラム要素に同時に割り当てられ得る。
[0148]第３の設計原理は、階層拡張記述子が、ＭＶ−ＨＥＶＣ／ＳＨＶＣコーディング規格のＶＰＳ拡張と同様のスケーラビリティタイプをシグナリングするための一般的な設計を含んでいることである。加えて、複数の依存エレメンタリストリームは、現在のエレメンタリストリームのためにシグナリングされ得る。
[0149]第４の設計原理は、ＨＥＶＣ拡張記述子の提案である。ＨＥＶＣ拡張記述子は、ＦＤＡＭ３におけるように、ＨＥＶＣビデオ記述子の一部として含まれ得る。ＨＥＶＣ拡張記述子はオペレーションポイントをシグナリングし、オペレーションポイントの各々は、ＭＶ−ＨＥＶＣ／ＳＨＶＣにおける出力レイヤセットに対応する。出力レイヤセットは、出力されるべきビットストリームのレイヤのセットである。ビットストリームは、ビデオデコーダが出力しないが、出力レイヤセットを復号するためにビデオデコーダによって使用される参照レイヤを含む場合もある。オペレーションポイントの構成は、出力レイヤセットに属するレイヤを指定することにより、階層拡張記述子に依存する。プロファイル、ティア、およびレベル、ならびに、ビットレートおよびフレームレートを含む、各オペレーションポイントの特性は、この記述子内でシグナリングされる。
[0150]一般に、「プロファイル」は、ビットストリームシンタックスのサブセットを指す場合がある。「ティア」および「レベル」は、各プロファイル内で指定され得る。ティアのレベルは、ビットストリーム内のシンタックス要素の値に課される制約の指定されたセットであり得る。これらの制約は、値に関する単純な制限であり得る。代替として、制約は、値の演算の組合せ（たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数）に関する制約の形態をとる場合がある。通常、下位ティアに指定されたレベルは、上位ティアにしてされたレベルよりも制約される。
[0151]ｍ３１４３０内に記述されたＨＥＶＣ拡張記述子のシンタックスが、下記に転載される。表Ｘに続く段落は、ＨＥＶＣ拡張記述子のセマンティクスを提供する。
Figure 0006553054
[0152]ｎｕｍ＿ｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔｓ−８ビットフィールドは、この記述子内の指定されたオペレーションポイントの数を指定する。
[0153]ｐｒｏｆｉｌｅ＿ｓｐａｃｅ−２ビットフィールドは、両端値を含む０から３１までの範囲内のｉのすべての値について、ｐｒｏｆｉｌｅ＿ｉｄｃの解釈についてのコンテキストを指定する。ｐｒｏｆｉｌｅ＿ｓｐａｃｅは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ａまたは小項Ｇ．１１または小項Ｈ．１１において規定されている値以外の値を割り当てられてはならない。ｐｒｏｆｉｌｅ＿ｉｄｃの他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約済みである。
[0154]ｔｉｅｒ＿ｆｌａｇ−１ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ａまたは小項Ｇ．１１または小項Ｈ．１１において規定されているｌｅｖｅｌ＿ｉｄｃの解釈についてのティアコンテキストを指定する。
[0155]ｐｒｏｆｉｌｅ＿ｉｄｃ−ｐｒｏｆｉｌｅ＿ｓｐａｃｅが０に等しいとき、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ａにおいて規定されているように、ＣＶＳが準拠するプロファイルを示す、５ビットフィールド。ｐｒｏｆｉｌｅ＿ｉｄｃは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類ＡまたはＧ．１１またはＨ．１１において規定されている値以外の値を割り当てられてはならない。ｐｒｏｆｉｌｅ＿ｉｄｃの他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約済みである。
[0156]ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｉｎｄｉｃａｔｉｏｎ、ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｌｅｖｅｌ＿ｉｄｃ−ＨＥＶＣ拡張ビデオ記述子がＨＥＶＣ拡張ビデオストリームに適用されるとき、これらのフィールドは、対応するＨＥＶＣビデオストリームまたはＨＥＶＣ拡張ビデオストリームまたはＨＥＶＣ完全時間表現について、それぞれ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇ［ｉ］、ｇｅｎｅｒａｌ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｉｎｔｅｒｌａｃｅｄ＿ｓｏｕｒｃｅ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｎｏｎ＿ｐａｃｋｅｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｆｒａｍｅ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿４４ｂｉｔｓ、ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃについて、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されているセマンティクスに従ってコーディングされなければならず、ＨＥＶＣビデオ記述子が関連付けられるＨＥＶＣビデオストリームまたはＨＥＶＣ完全時間表現全体は、これらのフィールドによってシグナリングされる情報に準拠しなければならない。
[0157]ｌｅｖｅｌ＿ｉｄｃ−８ビットフィールドは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ａ、Ｇ．１１、またはＨ．１１において規定されているように、ＣＶＳが準拠するレベルを示す。ｌｅｖｅｌ＿ｉｄｃは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ａ、Ｇ．１１、またはＨ．１１において規定されている値以外のｌｅｖｅｌ＿ｉｄｃの値を割り当てられてはならない。ｌｅｖｅｌ＿ｉｄｃの他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約済みである。
[0158]ｍａｘ＿ｔｅｍｐｏｒａｌ＿ｉｄ−３ビットフィールドは、ｉ番目のオペレーションポイント内のレイヤのＮＡＬユニットの最高のＴｅｍｐｏｒａｌＩｄを指定する。
[0159]ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿５ｂｉｔｓ−値「０」の予約された５ビットフィールド。
[0160]ｈｅｖｃ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇ−１ビットフィールドは、値「１」が割り当てられると、ｉに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤが出力レイヤセットに属し、ｉ番目のオペレーションポイントが復号されるときの出力に必要とされることを示す。値「０」が割り当てられると、ｉに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するレイヤは出力レイヤセットに属さない。ｉ番目のｈｅｖｃ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇが「１」に等しいとき、ｉ番目のｈｅｖｃ＿ｌａｙｅｒ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は「１」に等しくなければならない。
[0161]ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ−１６ビットフィールドは、ｉ番目のオペレーションポイントに対応するＨＥＶＣ拡張ビデオストリームのキロビット毎秒単位での平均ビットレートを示す。
[0162]ｍａｘｉｍｕｍ＿ｂｉｔｒａｔｅ−１６ビットフィールドは、ｉ番目のオペレーションポイントに対応するＨＥＶＣ拡張ビデオストリームのキロビット毎秒単位での最大ビットレートを示す。
[0163]ｆｒａｍｅ＿ｒａｔｅ−１６ビットフィールドは、ｉ番目のオペレーションポイントに対応するＨＥＶＣ拡張ビデオストリームのフレーム／２５６秒単位での最大フレームレートを示す。
[0164]ＭＰＥＧ入力文書ｍ３１４３０では、ＭＰＥＧ−２のトランスポートストリームまたはプログラムストリームにおいて定義されている、複数のエレメンタリストリームからのピクチャのバッファ管理は提供されていない。たとえば、ＭＰＥＧ入力文書ｍ３１４３０は、マルチレイヤＨＥＶＣのための（たとえば、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、または３Ｄ−ＨＥＶＣのための）トランスポートストリームシステムターゲットデコーダ（Ｔ−ＳＴＤ）モデルまたはプログラムストリームシステムターゲットデコーダモデルを記述していない。結果として、既存のバッファリングモデルは、マルチレイヤＨＥＶＣと互換性がない場合がある。
[0165]本開示は、ＭＰＥＧ入力文書ｍ３１４３０に基づいて、ＨＥＶＣ拡張ビットストリームの搬送のための技法を提供する。本開示の技法は、別々に、または互いに連携して使用される場合がある。
[0166]本開示の第１の技法によれば、（トランスポートストリームシステムターゲットデコーダ（Ｔ−ＳＴＤ）モデルとプログラムストリームシステムターゲットデコーダ（Ｐ−ＳＴＤ）モデルとを含む）ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣのバッファモデルは、同じレイヤベースモデルにおいて統合される。言い換えれば、１つのＴ−ＳＴＤモデルは、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣに適用することができ、１つのＰ−ＳＴＤモデルは、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣに適用することができる。１つの代替では、そのようなモデルは、Ｈ．２６４用のＭＶＣに対して行われるＴ−ＳＴＤモデルおよびＰ−ＳＴＤモデルと同様の方法で設計され得る。
[0167]このようにして、ビデオデコーダ３０は、バッファモデル（たとえば、Ｐ−ＳＴＤモデルまたはＴ−ＳＴＤモデル）において、データストリーム（すなわち、トランスポートストリームまたはプログラムストリーム）の複数のエレメンタリストリームからのアクセスユニットをアセンブルすることができる。ビデオデコーダ３０は、エレメンタリストリームがＳＨＶＣ、ＭＶ−ＨＥＶＣ、または３Ｄ−ＨＥＶＣのビットストリームを含むかどうかにかかわらず、同じバッファモデルを使用する。その後、ビデオデコーダ３０はアクセスユニットを復号することができる。言い換えれば、ビデオデコーダ３０はアクセスユニットのコード化ピクチャを復号することができる。
[0168]上記に示されたように、トランスポートストリームおよびプログラムストリームは、それぞれの一連のＰＥＳパケットを備える。トランスポートストリームまたはプログラムストリームの各それぞれのＰＥＳパケットは、複数のエレメンタリストリーム内のエレメンタリストリームに関連付けられる。したがって、トランスポートストリームまたはプログラムストリームは、複数のエレメンタリストリームを備えると言われる場合がある。エレメンタリストリームには、ビデオストリーム、オーディオストリーム、およびプライベートストリームが含まれ得る。本開示の１つまたは複数の技法によれば、ビットストリームの各それぞれのレイヤの各それぞれの時間サブレイヤは、異なるエレメンタリストリームに対応する場合がある。これにより、媒体認識ネットワーク要素（ＭＡＮＥ）または他のデバイスが、ＰＥＳパケットのペイロード内のＨＥＶＣデータを構文解析または解釈することなく、特定のレイヤおよび特定のサブレイヤに関連付けられたＰＥＳパケットを選択的に転送することが可能になる。むしろ、ＭＡＮＥまたは他のデバイスは、ＰＥＳパケットヘッダ内のデータ、およびトランスポートストリームまたはプログラムストリームのプログラム固有情報内の様々な記述子（たとえば、ＨＥＶＣ階層記述子、ＨＥＶＣ拡張記述子など）の中のデータに基づいて、特定のＰＥＳパケットを転送するべきかどうかを決定することができる場合がある。
[0169]ターゲットデコーダ（たとえば、ビデオデコーダ３０）は、アクセスユニットのピクチャを復号するより前に、ビットストリームのアクセスユニットを再アセンブルする必要があり得る。言い換えれば、ターゲットデコーダは、アクセスユニットのピクチャを復号するために必要とされるデータが、アクセスユニットに対する復号時に利用可能であることを保証する必要があり得る。トランスポートストリームは、トランスポートパケット内に誤り（たとえば、紛失ＰＥＳパケット、ジッタ、破損など）が存在する場合がある、潜在的に誤りを起こしやすいチャネル（たとえば、インターネット）上のプログラムの配信を目的とする。したがって、ターゲットデコーダがトランスポートストリームからのビデオを復号しているとき、ターゲットデコーダは、アクセスユニットのピクチャを復号するために必要とされるデータが直ちに利用可能であると見なすことができない。代わりに、ターゲットデコーダは、トランスポートストリームのプログラムごとにバッファリングモデルを実装することができる。トランスポートストリーム用のバッファリングモデルは、プログラムに関連付けられたそれぞれのエレメンタリビデオストリーム（すなわち、ビデオストリームを含むエレメンタリストリーム）ごとに、バッファのそれぞれのセットを含む場合がある。
[0170]本開示の第１の技法の一例によれば、エレメンタリビデオストリームｎ用のバッファのセットは、エレメンタリビデオストリーム用のトランスポートバッファＴＢnと、エレメンタリビデオストリーム用の多重化バッファＭＢnと、エレメンタリビデオストリーム用のＨＥＶＣレイヤピクチャサブセットバッファＶＳＢnとを含む場合がある。ターゲットデコーダがトランスポートストリームのＰＥＳパケットを受信するとき、ターゲットデコーダは、様々なエレメンタリストリームに属するトランスポートストリームのＰＥＳパケットが、様々なトランスポートバッファに記憶されるように、トランスポートストリームを逆多重化する。言い換えれば、プログラムに関連付けられた各それぞれのエレメンタリストリームの場合、ビデオデコーダは、それぞれのエレメンタリストリームに属するトランスポートストリームのそれぞれのＰＥＳパケットごとに、それぞれのエレメンタリストリーム用のバッファ（たとえば、トランスポートバッファ）にそれぞれのＰＥＳパケットを記憶することができる。したがって、エレメンタリストリームｎ用のトランスポートバッファＴＢnは、エレメンタリビデオストリームｎに属するトランスポートパケットを受信する。
[0171]ターゲットデコーダは、レートＲｘnでトランスポートバッファからトランスポートパケットを取り出す。トランスポートバッファＴＢn内にデータが存在しない場合、レートＲｘnは０である。そうではなく、トランスポートバッファＴＢn内にデータが存在する場合、レートＲｘnはビットレートに等しい。本開示内の他の場所で記載されるように、ターゲットデコーダは、第１の係数（すなわち、ＣｐｂＢｒＮａｌＦａｃｔｏｒ）、第２の係数（すなわち、ＣｐｂＢｒＶｃｌＦａｃｔｏｒ）、および第３の係数（すなわち、ＢｉｔＲａｔｅ［ＳｃｈｅｄＳｅｌＩｄｘ］）に基づいて、ビットレートを決定することができる。第１、第２、および第３の係数は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２において定義されている。
[0172]ターゲットデコーダが、エレメンタリストリームｎ用のトランスポートバッファＴＢnからトランスポートパケットを取り出すと、ターゲットデコーダは、そのトランスポートパケットをエレメンタリストリームｎ用の多重化バッファＭＢnに追加する。ターゲットデコーダは、１バイトずつ多重化バッファＭＢnからデータを取り出す。ターゲットデコーダが多重化バッファＭＢnから１バイトを取り出すと、ターゲットデコーダは、そのバイトがＰＥＳパケット（たとえば、トランスポートパケット）のヘッダバイトでない場合、エレメンタリストリームｎ用のＨＥＶＣレイヤピクチャサブセットバッファＶＳＢnにそのバイトを挿入する。
[0173]したがって、プログラムに関連付けられたそれぞれのエレメンタリストリームごとに、ターゲットデコーダは、それぞれのエレメンタリストリーム用のトランスポートバッファからＰＥＳパケットを取り出すことができる。さらに、ターゲットデコーダは、それぞれのエレメンタリストリーム用のトランスポートバッファから取り出されたＰＥＳパケットを、それぞれのエレメンタリストリーム用の多重化バッファに記憶することができる。ターゲットデコーダは、それぞれのエレメンタリストリーム用の多重化バッファからバイトを取り出すことができる。さらに、ターゲットデコーダは、それぞれのエレメンタリストリーム用の多重化バッファから取り出されたバイトを、それぞれのエレメンタリストリーム用のＨＥＶＣレイヤピクチャサブセットバッファに記憶することができる。
[0174]このようにして、ＨＥＶＣレイヤピクチャサブセットバッファＶＳＢnは、トランスポートパケットのペイロードバイトを受け取る。ＨＥＶＣレイヤピクチャサブセットバッファＶＳＢnは、ＨＥＶＣレイヤピクチャサブセット用のアセンブリポイントとして働くことができる。本開示で使用するＨＥＶＣレイヤピクチャサブセットは、レイヤ識別子セット（すなわち、レイヤ識別子値のセット）に関連付けられたアクセスユニットのＨＥＶＣレイヤピクチャのセットである。ＨＥＶＣレイヤピクチャは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、その制約が（下記に転載されている）Ｎ１３６５６の節２．１７．１において規定されている。
[0175]ターゲットデコーダは、アクセスユニットに対する復号時に、ＨＥＶＣレイヤピクチャサブセットバッファＶＳＢnからアクセスユニットに対応するデータを取り出す。たとえば、アクセスユニットＡH（ｊ）のピクチャを復号するために、ターゲットデコーダは、エレメンタリストリームｎ用のＨＥＶＣレイヤピクチャバッファＶＳＢnから、復号時間ｔｄn（ｊn）に対応するＨＥＶＣレイヤピクチャサブセットＶＳn（ｊn）を取り出すことができる。ｔｄn（ｊn）は、エレメンタリストリームｎ用のＨＥＶＣレイヤピクチャサブセットＶＳn（ｊn）の、ターゲットデコーダにおいて秒単位で測定された復号時間を示す。ｊnは、ＨＥＶＣレイヤピクチャサブセットＶＳn（ｊn）を定義するレイヤ識別子セットへのインデックスである。加えて、ターゲットデコーダは、エレメンタリストリームｎ＋１〜ｎ＋ｍ用のＨＥＶＣレイヤピクチャバッファＶＳＢn+1〜ＶＳＢn+mから、ＨＥＶＣレイヤピクチャサブセットＶＳn+1（ｊn+1）〜ＶＳn+m（ｊn+m）を取り出し、ＨＥＶＣレイヤピクチャサブセットＶＳn+1（ｊn+1）〜ＶＳn+m（ｊn+m）用の復号時間（すなわち、ｔｄn+1（ｊn+1）〜ｔｄn+m（ｊn+m））はｔｄn（ｊn）に等しい。アクセスユニットは、ＶＳＢn〜ＶＳＢn+mから取り出されたＨＥＶＣレイヤサブセットの組合せであり得る。
[0176]このようにして、プログラムに関連付けられたそれぞれのエレメンタリストリームごとに、バッファモデルは、それぞれのエレメンタリストリーム用のバッファ（たとえば、ＨＥＶＣレイヤピクチャバッファ）を備える。アクセスユニットは、それぞれのエレメンタリストリーム用のそれぞれのＨＥＶＣレイヤピクチャサブセットを備える。それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられたアクセスユニットのＨＥＶＣレイヤピクチャを備える。ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャである。プログラムに関連付けられたそれぞれのエレメンタリストリームごとに、ターゲットデコーダは、それぞれのエレメンタリストリーム用のバッファから、それぞれのエレメンタリストリーム用のそれぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことができる。ターゲットデコーダは、アクセスユニットにそれぞれのＨＥＶＣレイヤピクチャサブセットを含めることができる。
[0177]ターゲットデコーダは、プログラムストリーム内のＰＥＳパケットがトランスポートストリームに関連する誤り（たとえば、ジッタ、損失など）なしに利用可能であると見なすことができるので、プログラムストリーム用のバッファリングモデル（すなわち、Ｐ−ＳＴＤモデル）は、トランスポートストリーム用のバッファリングモデル（すなわち、Ｔ−ＳＴＤモデル）よりも簡単であり得る。本開示の１つまたは複数の技法によれば、ビットストリームの各それぞれのレイヤの各それぞれの時間サブレイヤは、プログラムストリームの異なるエレメンタリストリームに対応する場合がある。さらに、Ｐ−ＳＴＤモデルは、プログラムストリームのそれぞれのエレメンタリストリームごとに、ＨＥＶＣレイヤピクチャサブセットバッファを含む場合がある。ターゲットデコーダがプログラムストリームのＰＥＳパケットを受信するとき、ターゲットデコーダは、様々なエレメンタリストリームに属するＰＥＳパケットが、様々なＨＥＶＣレイヤピクチャサブセットバッファに記憶されるように、プログラムストリームを逆多重化する。ターゲットデコーダは、トランスポートストリームに関して上述された方式と同じ方式で、ＨＥＶＣレイヤピクチャサブセットバッファからアクセスユニットに対応するデータを取り出すことができる。
[0178]いくつかの例では、ターゲットデコーダは、受信されたトランスポートストリームまたはプログラムストリームのコンテンツに応じて、様々なバッファモデルを使用する。たとえば、プログラム内にＨＥＶＣレイヤのセットが存在することと、複数のエレメンタリストリーム内に、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、ターゲットデコーダは、アクセスユニットをアセンブルする際に使用するために、本開示の第１の技法に関して記載されたバッファモデルを選択することができる。
[0179]本開示の第２の例示的な技法によれば、各ＨＥＶＣ積層ビデオストリームは、Ｔ−ＳＴＤモデルおよび／またはＰ−ＳＴＤモデルを有することができる。ＨＥＶＣ積層ビデオサブビットストリームは、１つまたは複数のＨＥＶＣ積層ビデオサブストリームからアセンブルされる場合があり、ＨＥＶＣ拡張記述子内でオペレーションポイントとして表される。言い換えれば、ＨＥＶＣ積層ビデオストリームは、オペレーションポイントに対応し、ＨＥＶＣ積層ビデオサブビットストリームからアセンブルされる。ＨＥＶＣ積層ビデオサブビットストリームは、同じ値のｎｕｈ＿ｌａｙｅｒ＿ｉｄ（レイヤ識別子）を有するＶＣＬ ＮＡＬユニットと、それらの関連する非ＶＣＬ ＮＡＬユニットとを含む、複数のＨＥＶＣビデオレイヤサブビットストリームを含んでいる。たとえば、ＨＥＶＣ積層ビデオサブビットストリームは、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆまたは付属書類Ｇにおいて定義されている１つまたは複数のプロファイルに準拠する、ＨＥＶＣ拡張ビデオストリームのＨＥＶＣレイヤセットに属するｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するすべてのＶＣＬ ＮＡＬユニット、および関連する非ＶＣＬ ＮＡＬユニットであるように定義される場合がある。Ｔ−ＳＴＤおよびＰ−ＳＴＤは、上述され、本開示内の他の場所で記載される方式で動作することができる。したがって、いくつかの例では、ビデオデコーダ３０は、ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームごとにバッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルすることができる。そのような例では、各それぞれのＨＥＶＣ積層ビデオストリームは、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、複数のＨＥＶＣビデオレイヤサブビットストリームの各それぞれのＨＥＶＣビデオレイヤサブビットストリームは、同じレイヤ識別子値を有するＶＣＬ ＮＡＬユニットを備える。
[0180]前に示されたように、階層拡張記述子は、階層的にコーディングされたビデオ、オーディオ、およびプライベートストリームの構成要素を含むプログラム要素を識別する情報を提供する記述子である。言い換えれば、階層拡張記述子は、階層拡張記述子に対応するプログラム要素に関する情報を提供する。階層拡張記述子は、階層拡張記述子に関連付けられたエレメンタリストリームの復号の前に、復号順序でアクセスされ存在する必要がある直接依存プログラム要素ごとに、ｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドを含む場合がある。言い換えれば、階層拡張記述子は、複数のｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドを含む場合がある。階層拡張記述子の各それぞれのｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドは、対応するプログラム要素（すなわち、階層拡張記述子に対応するプログラム要素）用のそれぞれの直接依存プログラム要素を識別する。対応するプログラム要素用のそれぞれの直接依存プログラム要素は、ターゲットデコーダが対応するプログラム要素を復号することができる前に、ターゲットデコーダに利用可能になる必要があるプログラム要素である。たとえば、対応するプログラム要素は、非ベースレイヤ用のデータを含む場合があり、それぞれの直接依存プログラム要素は、ベースレイヤ用のデータを含む場合がある。それぞれのプログラム要素はそれぞれのレイヤに対応する場合があるので、階層拡張記述子の各それぞれのｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘは、階層拡張記述子に対応するレイヤを復号するために必要とされるそれぞれの参照レイヤを識別することができる。このようにして、アクセスユニットをアセンブルするとき、ターゲットデコーダは、現在のオペレーションポイントの出力レイヤに対応する記述子内の１つまたは複数のフィールドに基づいて、現在のオペレーションポイントの出力レイヤを復号するために必要とされる参照レイヤを識別することができる。
[0181]本開示の第３の技法によれば、Ｔ−ＳＴＤモデルまたはＰ−ＳＴＤモデルにおいて複数のストリームからのアクセスユニット内のＨＥＶＣレイヤピクチャをアセンブルするとき、関連する階層拡張記述子内で示されたｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘの値は、現在のオペレーションポイントの出力レイヤを復号するために必要とされる参照レイヤを識別するために使用される。たとえば、ｊ番目のアクセスユニットＡH（ｊ）を再アセンブルするとき、ターゲットデコーダは、トランスポートストリームまたはプログラムストリーム内のプログラムのプログラム要素ごとに、ＨＥＶＣレイヤピクチャサブセットバッファからＨＥＶＣレイヤピクチャサブセットを収集することができる。ターゲットデコーダは、以下が適用されるように、ＨＥＶＣレイヤピクチャサブセットを収集する。
・値ｙはレイヤ識別子を示す。値ｙは０以上である。
・ＨＥＶＣレイヤピクチャサブセットＶＳy+1（ｊy+1）は、レイヤｙ＋１用のプログラム要素に対応する。ｙ≧０なので、レイヤ識別子ｙ＋１を有するレイヤは非ベースレイヤである。
・ｔｄy+1（ｊy+1）は、ＶＳy+1（ｊy+1）用の復号タイムスタンプ（ＤＴＳ）の値を表記する。
・階層拡張記述子は、レイヤｙ＋１用のプログラム要素（すなわち、対応するプログラム要素）に対応する。
・階層拡張記述子は、０個以上のｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドを含む。
・それぞれのｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドごとに、
○それぞれのｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドは、対応するプログラム要素用のそれぞれの直接依存プログラム要素を識別するそれぞれの値を有する。
○ＶＳy（ｊy）は、それぞれの直接依存プログラム要素に対応するＨＥＶＣレイヤピクチャサブセットである。
○ｔｄy（ｊy）はＶＳy（ｊy）用のＤＴＳ値である。
○ｔｄy（ｊy）はｔｄy+1（ｊy+1）に等しい。
[0182]本開示の第４の技法によれば、現在のＨＥＶＣ ＭＰＥＧ−２システムにおけるようなＨＥＶＣタイミングおよびＨＲＤ記述子は、オペレーションポイントごとに存在することができる。言い換えれば、それぞれのオペレーションポイントごとに、それぞれのＨＥＶＣタイミングおよびＨＲＤ記述子が存在することができる。ＨＥＶＣタイミングおよびＨＲＤ記述子は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｃにおいて定義されているように、それぞれ、関連するＨＥＶＣビデオストリームまたはそのＨＥＶＣ最高時間サブレイヤ表現用の、タイミングおよびＨＲＤのパラメータを提供する。ＨＥＶＣタイミングおよびＨＲＤ記述子の例示的なシンタックスは、下記の節２．６．９５において提供される。
[0183]本開示の第４の技法の一例では、ＨＥＶＣ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒにおいて、各オペレーションポイントのループ内に、ＨＥＶＣタイミングおよびＨＲＤ記述子が存在することができる。上記に示されたように、ＨＥＶＣ拡張記述子は、ループ（すなわち、「ｆｏｒ（ｉ＝０；ｉ＜ｎｕｍ＿ｏｐｅｒａｔｉｏｎ＿ｐｏｉｎｔｓ；ｉ＋＋） ｛．．．｝」を含み、ここでは、ループの各それぞれの繰返しは、それぞれのオペレーションポイント用の要素のシーケンス（たとえば、ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｔｉｅｒ＿ｆｌａｇ、ｐｒｏｆｉｌｅ＿ｉｄｃなど）に対応する。この例では、それぞれのオペレーションポイント用の要素は、ＨＥＶＣタイミングとＨＲＤ記述子とをさらに含む。
[0184]本開示の第４の技法の別の例では、ＨＥＶＣタイミングおよびＨＲＤ記述子は、復号されるべきレイヤの同じレイヤ識別子セットを共有するオペレーションポイント用に１度存在するだけである。別の例では、ＨＥＶＣタイミングおよびＨＲＤ記述子は、すべての出力レイヤセットのすべてのオペレーションポイント用に１度存在するだけである。
[0185]本開示の第５の技法は、レイヤピクチャデリミタＮＡＬユニットを要する。レイヤピクチャデリミタＮＡＬユニットは、ＨＥＶＣ内のＮＡＬユニットヘッダと同じシンタックス構造を含む場合があり、以下のシンタックス要素、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔと、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅと、ｎｕｈ＿ｌａｙｅｒ＿ｉｄと、ｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１とを有する場合がある。ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔシンタックス要素は、常に０に等しい１ビットのシンタックス要素である。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素は、ＮＡＬユニットに含まれるＲＢＳＰデータ構造のタイプを指定する。ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は、ＮＡＬユニットが属するレイヤの識別子を指定する。様々な値を指定するｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を有するＮＡＬユニットは、ビットストリームの様々なレイヤに属する。ｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１シンタックス要素マイナス１は、ＮＡＬユニット用の時間識別子を指定する。
[0186]本開示の第５の技法のいくつかの例によれば、レイヤピクチャデリミタＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素は、０ｘ３０（すなわち、４８）に設定される。他の例では、レイヤピクチャデリミタＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素は、両端値を含む０ｘ３０〜０ｘ３Ｆ（すなわち、両端値を含む４８〜６３）の範囲内の値を有する。ＨＥＶＣ仕様は、０ｘ３０〜０ｘ３Ｆの範囲内の値を「未指定（unspecified）」としてマークする。
[0187]本開示の第５の技法のいくつかの例によれば、レイヤピクチャデリミタＮＡＬユニット内のｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１のシンタックス要素は、レイヤピクチャデリミタＮＡＬユニットの直後にくるＶＣＬ ＮＡＬユニットに関連付けられたピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１のシンタックス要素に等しくなるように設定される。０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリーム（すなわち、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６４｜ＩＳＯ／ＩＥＣ２３００８の付属書類Ｇおよび付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームを備えるエレメンタリストリーム）では、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔ（すなわち、レイヤプレゼンテーションデリミタＮＡＬユニット）は、ＬＰＤ＿ｎａｌ＿ｕｎｉｔのそれらに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値を有するすべてのＮＡＬユニットに先行することができる。他の例では、レイヤピクチャデリミタＮＡＬユニット内のｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１のシンタックス要素の値は、０および０になるように固定される。さらに、いくつかの例では、レイヤピクチャデリミタＮＡＬユニット内のｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１シンタックス要素は、レイヤピクチャデリミタＮＡＬユニットがレイヤピクチャデリミタＮＡＬユニットであることを示すために、０になるように設定される。いくつかの例では、０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリームでは、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔは、ＬＰＤ＿ｎａｌ＿ｕｎｉｔのそれに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄの値を有するすべてのＮＡＬユニットに先行することができる。いくつかの例では、０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリームでは、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔは、その最小値がＬＰＤ＿ｎａｌ＿ｕｎｉｔのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいＨＥＶＣレイヤ識別子セットに属する値を有する、すべてのＮＡＬユニットに先行することができる。
[0188]この発明を実施するための形態の最後に、一例として、提案されるソリューションのワーキングドラフトテキストが本開示に記載される（「ＩＮＦＯＲＭＡＴＩＯＮ ＴＥＣＨＮＯＬＯＧＹ−ＧＥＮＥＲＩＣ ＣＯＤＩＮＧ ＯＦ ＭＯＶＩＮＧ ＰＩＣＴＵＲＥＳ ＡＮＤ ＡＳＳＯＣＩＡＴＥＤ ＡＵＤＩＯ ＩＮＦＯＲＭＡＴＩＯＮ：ＳＹＳＴＥＭＳ、ＡＭＥＮＤＭＥＮＴ ３、Ｔｒａｎｓｐｏｒｔ ｏｆ ＨＥＶＣ ｖｉｄｅｏ ｏｖｅｒ ＭＰＥＧ−２ ｓｙｓｔｅｍｓ」と題する）。新しく追加されたテキストはボールドイタリック体で示される。完全に新しい小節は、小節の表題のみがボールドイタリック体で示される場合がある。仕様テキストの実装は、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、または３Ｄ−ＨＥＶＣなどのＨＥＶＣ積層ビデオではなく、ＨＥＶＣビデオの転送のみを含むＭＰＥＧ出力文書Ｎ１３６５６に基づく。以下のテキストは、図Ｘ−１と、図Ｘ−２と、図２−１５と、図Ｘ−４とを参照する。図Ｘ−１は、本開示の図２として提示される。図２は、単層ＨＥＶＣ用の例示的なＴ−ＳＴＤモデル拡張を示す概念図である。図Ｘ−２は、本開示の図３として提示される。図３は、本開示の１つまたは複数の技法による、ＨＥＶＣ時間ビデオサブセットの積層トランスポート用の例示的なＴ−ＳＴＤモデル拡張を示す概念図である。図２−１５は、本開示の図４として提示される。図４は、本開示の１つまたは複数の技法による、ＨＥＶＣ積層ビデオサブビットストリームを有するＲｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２ビデオ用の例示的なＴ−ＳＴＤモデル拡張を示す概念図である。図Ｘ−４は、本開示の図５として提示される。したがって、図５は、本開示の１つまたは複数の技法による、ＨＥＶＣ積層ビデオサブビットストリームを有するＲｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２ビデオ用の例示的なＰ−ＳＴＤモデル拡張を示す概念図である。
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
Figure 0006553054
[0189]本開示に記載される技法は、ビデオエンコーダ２０、ビデオデコーダ３０、または、スプライシングエンジン、媒体認識ネットワーク要素（ＭＡＮＥ）、ストリーミングサーバ、ルータ、およびコード化ビデオビットストリームを符号化、復号、アセンブル、構築、抽出、もしくは場合によっては処理する他のデバイスなどの、様々なビデオ処理デバイスのいずれかによって実施され得る。
[0190]図６は、ＭＰＥＧ−２システムによる、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）の拡張ビットストリームを含む、ＨＥＶＣマルチレイヤ拡張ビットストリームの搬送のための技法などの、本開示の様々な技法を実施するように構成され得る、例示的なビデオエンコーダ２０を示すブロック図である。
[0191]本開示は、ＨＥＶＣコーディング、より詳細には、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、および３Ｄ−ＨＥＶＣのコーディング拡張のコンテキストで、ビデオエンコーダ２０を記載する。しかしながら、本開示の技法は、他のビデオコーディングの規格または方法に適用可能であり得る。したがって、図６は、説明のために提供されるものであり、本開示で広く例示され記載される技法を限定するものと見なされるべきではない。
[0192]図６の例では、ビデオエンコーダ２０は、予測処理ユニット１００と、ビデオデータメモリ１０１と、残差生成ユニット１０２と、変換処理ユニット１０４と、量子化ユニット１０６と、逆量子化ユニット１０８と、逆変換処理ユニット１１０と、復元ユニット１１２と、フィルタユニット１１４と、復号ピクチャバッファ１１６と、エントロピー符号化ユニット１１８とを含む。予測処理ユニット１００は、インター予測処理ユニット１２０と、イントラ予測処理ユニット１２６とを含む。インター予測処理ユニット１２０は、動き推定（ＭＥ）ユニット１２２と、動き補償（ＭＣ）ユニット１２４とを含む。
[0193]予測処理ユニット１００の構成要素は、テクスチャ符号化と深度符号化の両方を実行するものとして記載される。いくつかの例では、テクスチャ符号化および深度符号化は、予測処理ユニット１００の同じ構成要素、または予測処理ユニット１００内の異なる構成要素によって実行される場合がある。たとえば、いくつかの実装形態では、別々のテクスチャエンコーダおよび深度エンコーダが提供される場合がある。また、複数のビューを符号化するために、たとえば、マルチビュープラス深度コーディングのために、複数のテクスチャエンコーダおよび深度エンコーダが提供される場合がある。ビデオエンコーダ２０は、図６に示されているよりも、多いか、少ないか、または異なる機能構成要素を含む場合がある。
[0194]いくつかの例では、予測処理ユニット１００は、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、または３Ｄ−ＨＥＶＣに実質的に従って、たとえば、本開示に記載された修正および／または追加に従って、動作することができる。予測処理ユニット１００は、エントロピー符号化ユニット１１８にシンタックス情報を供給することができる。シンタックス情報は、たとえば、どの予測モードが使用されたかと、そのモードに関係する情報とを示すことができる。
[0195]ビデオエンコーダ２０は符号化されるべきビデオデータを受信する。ビデオデータメモリ１０１は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶することができる。ビデオデータメモリ１０１内に記憶されるビデオデータは、たとえば、ビデオソース１８から取得される場合がある。復号ピクチャバッファ１１６は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための、参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ１０１および復号ピクチャバッファ１１６は、同じメモリデバイスまたは別々のメモリデバイスによって提供される場合がある。様々な例では、ビデオデータメモリ１０１は、ビデオエンコーダ２０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
[0196]ビデオエンコーダ２０は、ビデオデータのピクチャのスライス内の複数のコーディングツリーユニット（ＣＴＵ）の各々を符号化することができる。ＣＴＵの各々は、ピクチャの等しいサイズのルーマコーディングツリーブロック（ＣＴＢ）、および対応するクロマＣＴＢに関連付けられ得る。ＣＴＵを符号化することの一部として、予測処理ユニット１００は、ＣＴＵのＣＴＢを徐々により小さいブロックに分割するために、４分木区分化を実行することができる。より小さいブロックは、ＣＵのコーディングブロックであり得る。たとえば、予測処理ユニット１００は、ＣＴＵに関連付けられたＣＴＢを４つの等しいサイズのサブブロックに区分化することができ、サブブロックのうちの１つまたは複数を４つの等しいサイズのサブサブブロックに区分化することができ、以下同様である。
[0197]ビデオエンコーダ２０は、ＣＵの符号化表現（すなわちコード化ＣＵ）を生成するために、ＣＴＢのＣＵを符号化することができる。ＣＵを符号化することの一部として、予測処理ユニット１００は、ＣＵの１つまたは複数のＰＵの間でＣＵに関連付けられたコーディングブロックを区分化することができる。したがって、各ＰＵは、ルーマ予測ブロックおよび対応するクロマ予測ブロックに関連付けられ得る。
[0198]ビデオエンコーダ２０およびビデオデコーダ３０は、様々なサイズを有するＰＵをサポートすることができる。上記で示されたように、ＣＵのサイズは、ＣＵのルーマコーディングブロックのサイズを指す場合があり、ＰＵのサイズは、ＰＵのルーマ予測ブロックのサイズを指す場合がある。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ビデオエンコーダ２０およびビデオデコーダ３０は、イントラ予測の場合は２Ｎ×２ＮまたはＮ×ＮのＰＵサイズをサポートすることができ、インター予測の場合は２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、Ｎ×Ｎ、または同様の対称のＰＵサイズをサポートすることができる。ビデオエンコーダ２０およびビデオデコーダ３０はまた、インター予測の場合は２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズ向けの非対称区分化をサポートすることができる。本開示の態様によれば、ビデオエンコーダ２０およびビデオデコーダ３０はまた、深度インターコーディングのためのＰＵの非方形区分化をサポートする。
[0199]インター予測処理ユニット１２０は、ＣＵの各ＰＵに対してインター予測を実行することによって、ＰＵ用の予測データを生成することができる。ＰＵ用の予測データは、ＰＵの予測ブロックとＰＵについての動き情報とを含む場合がある。インター予測処理ユニット１２０は、ＰＵがＩスライス内にあるか、Ｐスライス内にあるか、またはＢスライス内にあるかに応じて、ＣＵのＰＵに対して様々な演算を実行することができる。Ｉスライスでは、すべてのＰＵはイントラ予測される。したがって、ＰＵがＩスライス内にある場合、インター予測処理ユニット１２０は、ＰＵに対してインター予測を実行しない。したがって、Ｉモードで符号化されたブロックの場合、予測ブロックは、同じピクチャ内の以前に符号化された隣接ブロックからの空間予測を使用して形成される。
[0200]ＰＵがＰスライス内にある場合、動き推定（ＭＥ）ユニット１２２は、ＰＵ用の参照領域について参照ピクチャのリスト（たとえば、「ＲｅｆＰｉｃＬｉｓｔ０」）の中で参照ピクチャを探索することができる。参照ピクチャは、復号ピクチャバッファ１１６に記憶される場合がある。ＰＵ用の参照領域は、ＰＵのサンプルブロックに最も密接に対応するサンプルブロックを含む、参照ピクチャ内の領域であり得る。動き推定（ＭＥ）ユニット１２２は、ＰＵ用の参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０内の位置を示す参照インデックスを生成することができる。
[0201]加えて、インターコーディングの場合、動き推定（ＭＥ）ユニット１２２は、ＰＵのコーディングブロックと参照領域に関連付けられた参照位置との間の空間変位を示す動きベクトル（ＭＶ）を生成することができる。たとえば、ＭＶは、現在のピクチャ内の座標から参照ピクチャ内の座標までのオフセットを提供する２次元ベクトルであり得る。動き推定（ＭＥ）ユニット１２２は、ＰＵの動き情報として参照インデックスとＭＶとを出力することができる。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示された参照位置における実際のサンプルまたは補間されたサンプルに基づいて、ＰＵの予測サンプルブロックを生成することができる。
[0202]ＰＵがＢスライス内にある場合、動き推定ユニット１２２は、ＰＵについての単予測または双予測を実行することができる。ＰＵについての単予測を実行するために、動き推定ユニット１２２は、ＰＵ用の参照領域について、ＲｅｆＰｉｃＬｉｓｔ０または第２の参照ピクチャリスト（「ＲｅｆＰｉｃＬｉｓｔ１」）の参照ピクチャを探索することができる。動き推定（ＭＥ）ユニット１２２は、ＰＵの動き情報として、参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０またはＲｅｆＰｉｃＬｉｓｔ１内の位置を示す参照インデックスと、ＰＵのサンプルブロックと参照領域に関連付けられた参照位置との間の空間変位を示すＭＶと、参照ピクチャがＲｅｆＰｉｃＬｉｓｔ０内にあるかＲｅｆＰｉｃＬｉｓｔ１内にあるかを示す１つまたは複数の予測方向インジケータとを出力することができる。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示された参照領域における実際のサンプルまたは補間されたサンプルに少なくとも部分的に基づいて、ＰＵの予測ブロックを生成することができる。
[0203]ＰＵについての双方向インター予測を実行するために、動き推定ユニット１２２は、ＰＵ用の参照領域について、ＲｅｆＰｉｃＬｉｓｔ０内の参照ピクチャを探索することができ、ＰＵ用の別の参照領域について、ＲｅｆＰｉｃＬｉｓｔ１内の参照ピクチャを探索することもできる。動き推定（ＭＥ）ユニット１２２は、参照領域を含む参照ピクチャのＲｅｆＰｉｃＬｉｓｔ０およびＲｅｆＰｉｃＬｉｓｔ１内の位置を示す参照ピクチャインデックスを生成することができる。加えて、動き推定（ＭＥ）ユニット１２２は、参照領域に関連付けられた参照位置とＰＵのサンプルブロックとの間の空間変位を示すＭＶを生成することができる。ＰＵの動き情報は、ＰＵの参照インデックスとＭＶとを含む場合がある。動き補償（ＭＣ）ユニット１２４は、ＰＵの動きベクトルによって示された参照領域における実際のサンプルまたは補間されたサンプルに少なくとも部分的に基づいて、ＰＵの予測ブロックを生成することができる。
[0204]イントラ予測処理ユニット１２６は、ＰＵに対してイントラ予測を実行することによって、ＰＵ用の予測データを生成することができる。ＰＵ用の予測データは、ＰＵ用の予測ブロックと様々なシンタックス要素とを含む場合がある。イントラ予測処理ユニット１２６は、Ｉスライス、Ｐスライス、およびＢスライスの中のＰＵに対してイントラ予測を実行することができる。ＰＵに対してイントラ予測を実行するために、イントラ予測処理ユニット１２６は、複数のイントラ予測モードを使用してＰＵ用の予測データの複数のセットを生成し、次いで、たとえばレートひずみ最適化技法を使用して、受け入れ可能または最適なコーディング性能を生み出すイントラ予測モードのうちの１つを選択することができる。
[0205]いくつかのイントラ予測モードを使用してＰＵ用の予測データのセットを生成するために、イントラ予測処理ユニット１２６は、そのイントラ予測モードに関連付けられた方向にあるＰＵのサンプルブロック全体にわたって、空間的に隣接するＰＵのサンプルブロックからのサンプルを拡張することができる。隣接するＰＵは、ＰＵ、ＣＵ、およびＣＴＵについて左から右、上から下の符号化順序を仮定すると、ＰＵの上、右上、左上、または左にあり得る。イントラ予測処理ユニット１２６は、様々な数のイントラ予測モード、たとえば３３個の方向性イントラ予測モードを使用することができる。いくつかの例では、イントラ予測モードの数は、ＰＵに関連付けられた領域のサイズに依存する場合がある。
[0206]予測処理ユニット１００は、ＰＵ用にインター予測処理ユニット１２０によって生成された予測データ、またはＰＵ用にイントラ予測処理ユニット１２６によって生成された予測データの中から、ＣＵのＰＵ用の予測データを選択することができる。いくつかの例では、予測処理ユニット１００は、予測データのセットのレート／ひずみメトリックに基づいて、ＣＵのＰＵ用の予測データを選択する。選択された予測データの予測ブロックは、本明細書では、選択された予測ブロックと呼ばれる場合がある。
[0207]残差生成ユニット１０２は、ＣＵのコーディングブロック（たとえば、ルーマコーディングブロック、Ｃｂコーディングブロック、またはＣｒコーディングブロック）、およびＣＵのＰＵの選択されたインター予測ブロックまたはイントラ予測ブロック（たとえば、ルーマ予測ブロック、Ｃｂ予測ブロック、またはＣｒ予測ブロック）に基づいて、ＣＵの残差ブロック（たとえば、ルーマ残差ブロック、Ｃｂ残差ブロック、またはＣｒ残差ブロック）を生成することができる。たとえば、残差生成ユニット１０２は、残差ブロック内の各サンプルが、ＣＵのコーディングブロック内のサンプルと、ＣＵのＰＵの対応する選択された予測サンプルブロック内の対応するサンプルとの間の差分に、すなわち、適用可能な場合ルーマピクセル値またはクロマピクセル値の単位で、等しい値を有するように、ＣＵの残差ブロックを生成することができる。
[0208]変換処理ユニット１０４は、ＣＵに関連付けられた残差ブロックを、ＣＵのＴＵに関連付けられた変換ブロックに区分化するために、４分木区分化を実行することができる。したがって、ＴＵは、ルーマ変換ブロックおよび２つのクロマ変換ブロックに関連付けられ得る。ＣＵのＴＵのルーマ変換ブロックおよびクロマ変換ブロックのサイズおよび位置は、ＣＵのＰＵの予測ブロックのサイズおよび位置に、基づく場合も基づかない場合もある。「残差４分木」（ＲＱＴ）として知られる４分木構造は、領域の各々に関連付けられたノードを含む場合がある。ＣＵのＴＵは、ＲＱＴのリーフノードに対応することができる。
[0209]通常の残差コーディングの場合、変換処理ユニット１０４は、ＴＵの変換ブロックに１つまたは複数の変換を適用することによって、ＣＵのＴＵごとに変換係数ブロックを生成することができる。変換処理ユニット１０４は、ＴＵに関連付けられた変換ブロックに様々な変換を適用することができる。たとえば、変換処理ユニット１０４は、離散コサイン変換（ＤＣＴ）、方向性変換、または概念的に同様の変換を変換ブロックに適用することができる。いくつかの例では、変換処理ユニット１０４は、変換ブロックに変換を適用しない。そのような例では、変換ブロックは、変換係数ブロックとして扱われ得る。
[0210]量子化ユニット１０６は、通常の残差コーディングの場合、係数ブロック内の残差変換係数を量子化することができる。量子化処理は、変換係数の一部またはすべてに関連付けられるビット深度を低減することができる。たとえば、ｎビットの変換係数が量子化の間にｍビットの変換係数に切り捨てられる場合があり、ここで、ｎはｍよりも大きい。量子化ユニット１０６は、ＣＵに関連付けられた量子化パラメータ（ＱＰ）値に基づいて、ＣＵのＴＵの係数ブロックを量子化することができる。ビデオエンコーダ２０は、ＣＵに関連付けられたＱＰ値を調整することによって、ＣＵに関連付けられた係数ブロックに適用される量子化の程度を調整することができる。量子化は、情報の損失をもたらす場合があり、したがって、量子化された変換係数は、元の係数よりも低い精度を有する場合がある。
[0211]逆量子化ユニット１０８および逆変換処理ユニット１１０は、係数ブロックから残差ブロックを復元するために、それぞれ、係数ブロックに逆量子化と逆変換とを適用することができる。復元ユニット１１２は、ＴＵに関連付けられた復元された変換ブロックを生成するために、予測処理ユニット１００によって生成された１つまたは複数の予測サンプルブロックからの対応するサンプルに、復元された残差ブロックを加算することができる。このようにしてＣＵのＴＵごとに変換ブロックを復元することによって、ビデオエンコーダ２０は、ＣＵのコーディングブロックを復元することができる。
[0212]フィルタユニット１１４は、復元されたＣＵに関連付けられたコーディングブロック内の、ブロッキングアーティファクトなどのアーティファクトを低減するために、１つまたは複数のフィルタリング演算を実行することができる。フィルタリング演算は、ブロック境界においてブロッキネスを低減するデブロッキング、ピクセル変換を平滑化するループフィルタリング、ピクセル変換を平滑化するサンプル適応オフセットフィルタリング、または場合によっては他のタイプのフィルタリング演算もしくはフィルタリング技法のうちの１つまたは複数を含む場合がある。復号ピクチャバッファ１１６は、フィルタユニット１１４が、復元されたコーディングブロックに対して１つまたは複数のデブロッキング演算を実行した後、復元されたコーディングブロックを記憶することができる。インター予測処理ユニット１２０は、他のピクチャのＰＵに対してインター予測を実行するために、復元されたコーディングブロックを含む参照ピクチャを使用することができる。加えて、イントラ予測処理ユニット１２６は、ＣＵと同じピクチャ内の他のＰＵに対してイントラ予測を実行するために、復号ピクチャバッファ１１６内の復元されたコーディングブロックを使用することができる。
[0213]エントロピー符号化ユニット１１８は、ビデオエンコーダ２０の様々な機能構成要素からデータを受け取ることができる。たとえば、エントロピー符号化ユニット１１８は、量子化ユニット１０６から係数ブロックを受け取ることができ、予測処理ユニット１００からシンタックス要素を受け取ることができる。エントロピー符号化ユニット１１８は、エントロピー符号化データを生成するために、データに対して１つまたは複数のエントロピー符号化演算を実行することができる。たとえば、エントロピー符号化ユニット１１８は、ＣＡＢＡＣ演算を実行することができる。他のエントロピーコーディングプロセスの例には、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、および確率間隔区分化エントロピー（ＰＩＰＥ）コーディングが含まれる。ＨＥＶＣでは、ＣＡＢＡＣが使用される。ビデオエンコーダ２０は、エントロピー符号化ユニット１１８によって生成されたエントロピー符号化データを含むビットストリームを出力することができる。たとえば、ビットストリームは、バイナリシンタックス要素またはバイナリ化シンタックス要素のビンを表すビットを含む場合がある。
[0214]図７は、ＭＰＥＧ−２システムによる、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、スケーラブルＨＥＶＣ（ＳＨＶＣ）、および３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）の拡張ビットストリームを含む、ＨＥＶＣマルチレイヤ拡張ビットストリームの搬送のための技法などの、本開示の技法を実施するように構成された、例示的なビデオデコーダ３０を示すブロック図である。図７は、例示のために提供され、本開示で広く例示され記載される技法を限定するものと見なされるべきではない。本開示は、ＨＥＶＣコーディング拡張、詳細には、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、および３Ｄ−ＨＥＶＣのコーディング拡張のコンテキストで、ビデオデコーダ３０を記載する。しかしながら、本開示の技法は、他のビデオコーディングの規格または方法に適用可能であり得る。したがって、図７は、説明のために提供され、本開示で広く例示され記載される技法を限定するものと見なされるべきではない。
[0215]図７の例では、ビデオデコーダ３０は、エントロピー復号ユニット１５０と、予測処理ユニット１５２と、逆量子化ユニット１５４と、逆変換処理ユニット１５６と、復元ユニット１５８と、フィルタユニット１６０と、復号ピクチャバッファ１６２とを含む。予測処理ユニット１５２は、インター予測用の動き補償（ＭＣ）ユニット１６４と、イントラ予測処理ユニット１６６とを含む。説明を容易にするために、予測処理ユニット１５２の構成要素は、テクスチャ復号と深度復号の両方を実行するものとして記載される。いくつかの例では、テクスチャ復号および深度復号は、予測処理ユニット１５２の同じ構成要素、または予測処理ユニット１５２内の異なる構成要素によって実行される場合がある。たとえば、いくつかの実装形態では、別々のテクスチャデコーダおよび深度デコーダが提供される場合がある。また、たとえば、マルチビュープラス深度コーディングのための複数のビューを復号するために、複数のテクスチャデコーダおよび深度デコーダが提供される場合がある。いずれの場合も、予測処理ユニット１５２は、３Ｄ−ＨＥＶＣプロセスなどの３Ｄコーディングプロセスの一部として、テクスチャデータと深度データとをイントラ復号またはインター復号するように構成される場合がある。
[0216]したがって、予測処理ユニット１５２は、ＭＶ−ＨＥＶＣ、ＳＨＶＣ、または３Ｄ−ＨＥＶＣに実質的に従って動作し、本開示に記載された修正および／または追加に従う場合がある。予測処理ユニット１５２は、エントロピー復号ユニット１５０を介して、イントラ復号またはインター復号された深度データについて、符号化ビデオビットストリームから残差データを取得し、イントラ復号またはインター復号された深度データと残差データとを使用して、ＣＵを復元することができる。いくつかの例では、ビデオデコーダ３０は、図７に示されているよりも、多いか、少ないか、または異なる機能構成要素を含む場合がある。
[0217]ビデオデコーダ３０は、符号化ビデオビットストリームを受信する。コード化ピクチャバッファ（ＣＰＢ）１５１は、ビットストリームの符号化ビデオデータ（たとえば、ＮＡＬユニット）を受信および記憶することができる。ＣＰＢ１５１に記憶されたビデオデータは、たとえば、コンピュータ可読媒体１６から、たとえば、カメラなどのローカルビデオソースから、ビデオデータの有線もしくはワイヤレスのネットワーク通信を介して、または物理データ記憶媒体にアクセスすることによって取得され得る。ＣＰＢ１５１は、符号化ビデオビットストリームからの符号化ビデオデータを記憶するビデオデータメモリを形成することができる。復号ピクチャバッファ１６２は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオデコーダ３０によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ＣＰＢ１５１および復号ピクチャバッファ１６２は、同期ＤＲＡＭ（ＳＤＲＡＭ）を含むダイナミックランダムアクセスメモリ（ＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスなどの、様々なメモリデバイスのいずれかによって形成され得る。ＣＰＢ１５１および復号ピクチャバッファ１６２は、同じメモリデバイスまたは別々のメモリデバイスによって提供される場合がある。様々な例では、ＣＰＢ１５１は、ビデオデコーダ３０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。
[0218]エントロピー復号ユニット１５０は、ビットストリームからエントロピー符号化シンタックス要素を復号するために、ビットストリームを構文解析する。いくつかの例では、エントロピー復号ユニット１５０は、ビットストリーム内のビットからシンタックス要素用のビンを復号するために、ＣＡＢＡＣコーダを使用するように構成される場合がある。エントロピー復号ユニット１５０は、イントラコーディングモードまたはインターコーディングモードを含む様々なコーディングモードについて、様々な他のシンタックス要素を復号するために、ＣＡＢＡＣコーダを使用することができる。
[0219]予測処理ユニット１５２、逆量子化ユニット１５４、逆変換処理ユニット１５６、復元ユニット１５８、およびフィルタユニット１６０は、ビットストリームから抽出されたシンタックス要素に基づいて、復号ビデオデータを生成することができる。ビットストリームは、一連のＮＡＬユニットを備える場合がある。ビットストリームのＮＡＬユニットは、コード化スライスＮＡＬユニットを含む場合がある。ビットストリームを復号することの一部として、エントロピー復号ユニット１５０は、コード化スライスＮＡＬユニットからシンタックス要素を抽出し、エントロピー復号することができる。ビットストリームのいくつかのシンタックス要素は、エントロピー符号化またはエントロピー復号されない。
[0220]コード化スライスの各々は、スライスヘッダとスライスデータとを含む場合がある。スライスヘッダは、スライスに関係するシンタックス要素を含む場合がある。スライスヘッダ内のシンタックス要素は、スライスを含むピクチャに関連付けられたＰＰＳを識別するシンタックス要素を含む場合がある。ＰＰＳはＳＰＳを参照することができ、ＳＰＳは次にＶＰＳを参照することができる。エントロピー復号ユニット１５０はまた、ＳＥＩメッセージなどのシンタックス情報を含む場合がある他の要素をエントロピー復号することができる。スライスヘッダ、パラメータセット、またはＳＥＩメッセージのいずれかの中の復号されたシンタックス要素は、本明細書に記載された例示的な技法に従ってシグナリングされるものとして、本明細書に記載された情報を含む場合がある。そのようなシンタックス情報は、テクスチャブロックまたは深度ブロックの復号および復元のために、予測処理ユニット１５２に供給され得る。
[0221]ビデオデコーダ３０は、区分化されていないＣＵおよびＰＵに対して復元演算を実行することができる。復元演算を実行するために、ビデオデコーダ３０は、ＣＵの各ＴＵに対して復元演算を実行することができる。ＣＵのＴＵごとに復元演算を実行することによって、ビデオデコーダ３０は、ＣＵのブロックを復元することができる。ＣＵのＴＵに対して復元演算を実行することの一部として、逆量子化ユニット１５４は、ＴＵに関連付けられた係数ブロックを逆量子化（ｉｎｖｅｒｓｅ ｑｕａｎｔｉｚｅ）、すなわち逆量子化（ｄｅ−ｑｕａｎｔｉｚｅ）することができる。逆量子化ユニット１５４は、量子化の程度を決定するために、同様に、逆量子化ユニット１５４が適用すべき逆量子化の程度を決定するために、ＴＵのＣＵに関連付けられたＱＰ値を使用することができる。すなわち、圧縮比、すなわち、元のシーケンスと圧縮されたシーケンスとを表すために使用されるビット数の比は、変換係数を量子化するときに使用されるＱＰの値を調整することによって制御され得る。圧縮比はまた、利用されるエントロピーコーディングの方法に依存する場合がある。
[0222]逆量子化ユニット１５４が係数ブロックを逆量子化した後、逆変換処理ユニット１５６は、ＴＵに関連付けられた残差ブロックを生成するために、係数ブロックに１つまたは複数の逆変換を適用することができる。たとえば、逆変換処理ユニット１５６は、逆ＤＣＴ、逆整数変換、逆カルーネンレーベ変換（ＫＬＴ）、逆回転変換、逆方向性変換、または別の逆変換を係数ブロックに適用することができる。
[0223]ＰＵがイントラ予測を使用して符号化される場合、イントラ予測処理ユニット１６６は、ＰＵ用の予測ブロックを生成するために、イントラ予測を実行することができる。イントラ予測処理ユニット１６６は、空間的に隣接するＰＵの予測ブロックに基づいて、ＰＵ用の予測ブロック（たとえば、ルーマ予測ブロック、Ｃｂ予測ブロック、およびＣｒ予測ブロック）を生成するために、イントラ予測モードを使用することができる。イントラ予測処理ユニット１６６は、ビットストリームから復号された１つまたは複数のシンタックス要素に基づいて、ＰＵ用のイントラ予測モードを決定することができる。
[0224]ＰＵがインター予測を使用して符号化される場合、ＭＣユニット１６４は、ＰＵ用のインター予測ブロックを生成するために、インター予測を実行することができる。ＭＣユニット１６４は、他のピクチャまたはビュー内のブロックに基づいて、ＰＵ用の予測ブロック（たとえば、ルーマ予測ブロック、Ｃｂ予測ブロック、およびＣｒ予測ブロック）を生成するために、インター予測モードを使用することができる。ＭＣユニット１６４は、ビットストリームから復号された１つまたは複数のシンタックス要素に基づいて、ＰＵ用のインター予測モードを決定することができ、動きベクトル、予測方向、および参照ピクチャインデックスなどの動き情報を受信または決定することができる。
[0225]インター予測の場合、ＭＣユニット１６４は、ビットストリームから抽出されたシンタックス要素に基づいて、第１の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ０）と第２の参照ピクチャリスト（ＲｅｆＰｉｃＬｉｓｔ１）とを構築することができる。ＰＵがインター予測を使用して符号化される場合、エントロピー復号ユニット１５０は、ＰＵについての動き情報を抽出または決定することができる。ＭＣユニット１６４は、ＰＵの動き情報に基づいて、ＰＵ用の１つまたは複数の参照ブロックを決定することができる。動き補償（ＭＣ）ユニット１６４は、ＰＵ用の１つまたは複数の参照ブロックにおけるブロック内のサンプルに基づいて、ＰＵ用の予測ブロック（たとえば、ルーマ予測ブロック、Ｃｂ予測ブロック、およびＣｒ予測ブロック）を生成することができる。
[0226]復元ユニット１５８は、ＣＵのコーディングブロック（たとえば、ルーマコーディングブロック、Ｃｂコーディングブロック、およびＣｒコーディングブロック）を復元するために、適用可能な場合、ＣＵのＴＵの変換ブロック（たとえば、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロック）、ならびに、ＣＵのＰＵの予測ブロック（たとえば、ルーマ予測ブロック、Ｃｂ予測ブロック、およびＣｒ予測ブロック）、すなわち、イントラ予測データまたはインター予測データのいずれかを使用することができる。たとえば、復元ユニット１５８は、ＣＵのルーマコーディングブロックと、Ｃｂコーディングブロックと、Ｃｒコーディングブロックとを復元するために、ルーマ変換ブロック、Ｃｂ変換ブロック、およびＣｒ変換ブロックの残差サンプルを、予測ルーマブロック、予測Ｃｂブロック、および予測Ｃｒブロックの対応するサンプルに加算することができる。
[0227]フィルタユニット１６０は、ＣＵのコーディングブロック（たとえば、ルーマコーディングブロック、Ｃｂコーディングブロック、およびＣｒコーディングブロック）に関連付けられたブロッキングアーティファクトを低減するために、デブロッキング演算を実行することができる。ビデオデコーダ３０は、ＣＵのコーディングブロック（たとえば、ルーマコーディングブロック、Ｃｂコーディングブロック、およびＣｒコーディングブロック）を復号ピクチャバッファ１６２に記憶することができる。復号ピクチャバッファ１６２は、次の動き補償、イントラ予測、および図１のディスプレイデバイス３２などのディスプレイデバイス上での提示のために、参照ピクチャを供給することができる。たとえば、ビデオデコーダ３０は、復号ピクチャバッファ１６２内のルーマブロック、Ｃｂブロック、およびＣｒブロックに基づいて、他のＣＵのＰＵに対してイントラ予測演算またはインター予測演算を実行することができる。
[0228]本開示に記載された様々な技法は、それらの両方が一般にビデオコーダと呼ばれ得る、ビデオエンコーダ２０（図１および図６）ならびに／またはビデオデコーダ３０（図１および図７）によって実施され得る。加えて、ビデオコーディングは、一般に、適用可能な場合、ビデオ符号化および／またはビデオ復号を指す場合がある。
[0229]本開示の技法は、全般にＭＶ−ＨＥＶＣ、ＳＨＶＣ、および３Ｄ−ＨＥＶＣに関して記載されたが、本技法は、必ずしもこのように限定されるとは限らない。上記に記載された技法は、他の現在の規格または将来の規格にも適用可能であり得る。
[0230]図８は、本開示の１つまたは複数の技法による、ビデオデコーダ３０の例示的な動作を示すフローチャートである。図８の動作および本開示の他のフローチャートの動作は、例として提供される。本開示の技法による他の動作は、より多数の、より少数の、または異なるアクションを含む場合がある。
[0231]図８の例では、ビデオデコーダ３０は、複数のエレメンタリストリームを備えるビデオデータストリームを受信する（２００）。さらに、ビデオデコーダ３０は、バッファモデルにおいて、ビデオデータストリームの複数のエレメンタリストリームからアクセスユニットをアセンブルする（２０２）。この例では、ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり得る。エレメンタリストリームがスケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、または３Ｄ−ＨＥＶＣのビットストリームを含むかどうかにかかわらず、アクセスユニットをアセンブルするために同じバッファモデルが使用される。さらに、図８の例では、ビデオデコーダ３０はアクセスユニットを復号することができる（２０４）。アクセスユニットは、ビデオデータの１つまたは複数のピクチャを備える場合がある。
[0232]図９は、本開示の１つまたは複数の技法による、アクセスユニットをアセンブルおよび復号するビデオデコーダ３０の例示的な動作を示すフローチャートである。図９の例では、ビデオデコーダ３０は、アクセスユニット用のエレメンタリストリーム（たとえば、プログラム要素）のセットを決定することができる（２５０）。ビデオデコーダ３０は、様々な方法でアクセスユニット用のエレメンタリストリームのセットを決定することができる。
[0233]たとえば、ビデオデコーダ３０は、現在のオペレーションポイントを復号している場合がある。この例では、ＨＥＶＣ拡張記述子は、現在のオペレーションポイントについてｈｅｖｃ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇ（hevc_output_layer_flags）を規定することができる。ｈｅｖｃ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇは、特定のレイヤ（paticular layers）が現在のオペレーションポイントのための出力レイヤセット内にあるかどうかを示す。したがって、この例では、ビデオデコーダ３０は、現在のオペレーションポイント用のｈｅｖｃ＿ｏｕｔｐｕｔ＿ｌａｙｅｒ＿ｆｌａｇ（hevc_output_layer_flags）に基づいて、現在のオペレーションポイント用の出力レイヤセットを決定することができる。この例では、現在のオペレーションポイント用の出力レイヤセット内のそれぞれの出力レイヤの各々に、ビデオデコーダ３０は、エレメンタリストリームのセットを決定することができる。説明を容易にするために、本開示は、エレメンタリストリームの決定されたセットを、エレメンタリストリームの出力セットとして言及する。エレメンタリストリームの出力セット内のそれぞれのエレメンタリストリームの各々は、現在のオペレーションポイントのそれぞれの出力レイヤに対応する。
[0234]さらに、この例では、エレメンタリストリームの出力セットのそれぞれのエレメンタリストリームの各々は、ｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドのそれぞれのセット（the respective set of hierarchy_ext_embedded_layer_index field）を含むそれぞれの階層拡張記述子に関連付けられる。ｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘフィールドのそれぞれのセットは、それぞれのエレメンタリストリームについて従属エレメンタリストリーム（dependent elementary strams）を識別する。ビデオデコーダ３０は、エレメンタリストリームの出力セットと、エレメンタリストリームの出力セットの各エレメンタリストリームのための従属エレメンタリストリームとを、アクセスユニットのためのエレメンタリストリームのセット内に含める。
[0235]さらに、図９の例では、ビデオデコーダ３０は、アクセスユニットのためのエレメンタリストリームのセットが任意の未処理のエレメンタリストリームを含むかどうかを決定する（２５２）。アクセスユニットのためのエレメンタリストリームのセットが１つまたは複数の未処理のエレメンタリストリームを含むと決定することに応答して（２５２の「Yes」）、ビデオデコーダ３０は、未処理のエレメンタリストリームのうちの１つ（すなわち、現在のエレメンタリストリーム）について、ＨＥＶＣレイヤピクチャサブセットバッファからＨＥＶＣレイヤピクチャサブセットを取り出すことができる（２５４）。ＨＥＶＣレイヤピクチャサブセットの各ピクチャは、アクセスユニットの復号タイムスタンプに等しい復号タイムスタンプを有する。ビデオデコーダ３０は、再アセンブルされたアクセスユニットにＨＥＶＣレイヤピクチャサブセットを含めることができる（２５６）。次いで、現在のエレメンタリストリームが処理されたと見なされる。次いで、ビデオデコーダ３０は、アクセスユニット用のエレメンタリストリームのセットが１つまたは複数の未処理のエレメンタリストリームを含むかどうかを再び決定することができる（２５２）。
[0236]未処理のエレメンタリストリームが残っていない場合、ビデオデコーダ３０は、再アセンブルされたアクセスユニットに、アクセスユニットのためのエレメンタリストリームのセットの各エレメンタリストリーム用のＨＥＶＣレイヤピクチャサブセットを含めている。したがって、未処理のエレメンタリストリームが残っていないと決定することに応答して（２５２の「No」）、ビデオデコーダ３０は、アクセスユニットのピクチャを復号することができる（２５８）。
[0237]以下の段落は、本開示の技法の様々な例を記載する。
[0238]例１．ビデオデータを処理する方法であって、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送のために、同じレイヤベースモデルにおいて統合される、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、および３Ｄ−ＨＥＶＣのバッファモデルを使用することを備える、方法。
[0239]例２．バッファモデルはＴ−ＳＴＤモデルとＰ−ＳＴＤモデルとを含む、例１の方法。
[0240]例３．バッファモデルはＭＶＣに使用されるＴ−ＳＴＤモデルおよびＰ−ＳＴＤモデルに類似する、例１の方法。
[0241]例４．ビデオデータを処理する方法であって、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送のために、各ＨＥＶＣ積層ビデオストリームにＴ−ＳＴＤモデルおよび／またはＰ−ＳＴＤモデルを使用することを備え、各ＨＥＶＣ積層ビデオストリームは、ＨＥＶＣ積層ビデオサブビットストリームからアセンブルされるオペレーションポイントに対応する、方法。
[0242]例５．ＨＥＶＣ積層ビデオサブビットストリームは、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ（レイヤ識別子）の同じ値を有するＶＣＬ ＮＡＬユニットと、それらの関連する非ＶＣＬ ＮＡＬユニットとを含む複数のＨＥＶＣビデオレイヤサブビットストリームを含む、例４の方法。
[0243]例６．ビデオデータを処理する方法であって、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送のために、Ｔ−ＳＴＤモデルまたはＰ−ＳＴＤモデルにおいて複数のストリームからアクセスユニット内のＨＥＶＣレイヤピクチャをアセンブルするときに、現在のオペレーションポイントの出力レイヤを復号するために必要とされる参照レイヤを識別するために、関連する階層拡張記述子内で示されるｈｉｅｒａｒｃｈｙ＿ｅｘｔ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘ値を使用することを備える、方法。
[0244]例７．ビデオデータを処理する方法であって、ＭＰＥＧ−２システムによるＨＥＶＣ拡張ストリームの搬送のために、少なくともいくつかのオペレーションポイントについての現在のＨＥＶＣ ＭＰＥＧ−２システムにおけるような、ＨＥＶＣタイミングとＨＲＤ記述子とを使用することを備える、方法。
[0245]例８．ＨＥＶＣタイミングおよびＨＲＤ記述子が各オペレーションポイントに提示され得る、例７の方法。
[0246]例９．ＨＥＶＣ＿ｅｘｔｅｎｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ内で、各オペレーションポイントのループにおいて、ＨＥＶＣタイミングとＨＲＤ記述子とを使用することをさらに備える、例７の方法。
[0247]例１０．そのようなＨＥＶＣタイミングおよびＨＲＤ記述子は、復号されるべきレイヤの同じレイヤ識別子セットを共有するオペレーションポイント用に１度存在するのみである、例７〜例９のいずれかの方法。
[0248]例１１．そのようなＨＥＶＣタイミングおよびＨＲＤ記述子が、すべての出力レイヤセットのすべてのオペレーションポイント用に１度存在するのみである、例７〜例９のいずれかの方法。
[0249]例１２．ビデオデータを処理する方法であって、ＭＰＥＧ−２シテムによるＨＥＶＣ拡張ストリームの搬送のために、レイヤピクチャデリミタＮＡＬユニットを使用することを備える、方法。
[0250]例１３．レイヤピクチャデリミタＮＡＬユニットは、ＨＥＶＣ内のＮＡＬユニットヘッダと同じシンタックス要素を含み、以下のシンタックス要素：ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ、およびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１を有する、例１２の方法。
[0251]例１４．レイヤピクチャデリミタＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、０ｘ３０（すなわち、４８）になるように設定される、例１２の方法。
[0252]例１５．ＨＥＶＣ仕様において「未指定」とマークされている、両端を含む０ｘ３０〜０ｘ３Ｆ（すなわち、両端を含む４８〜６３）の範囲内の異なるＮＡＬユニットタイプが、レイヤピクチャデリミタＮＡＬユニットに使用される、例１２の方法。
[0253]例１６．ｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値は、レイヤピクチャデリミタＮＡＬユニットの直後にくるＶＣＬ ＮＡＬユニットについて関連するピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値に等しいように設定される、例１２の方法。
[0254]例１７．０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリームにおいて、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔが、ＬＰＤ＿ｎａｌ＿ｕｎｉｔのそれらに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値を有するすべてのＮＡＬユニットに先行することができる、例１６の方法。
[0255]例１８．ｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値が０および０になるように固定される、例１６の方法。
[0256]例１９．このＮＡＬユニットがレイヤピクチャデリミタＮＡＬユニットであること示すために、ｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１が０になるように設定される、例１６の方法。
[0257]例２０．０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリームにおいて、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔが、ＬＰＤ＿ｎａｌ＿ｕｎｉｔのそれに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄの値を有するすべてのＮＡＬユニットに先行することができる、例１６の方法。
[0258]例２１．０ｘ２６に等しいｓｔｒｅａｍ＿ｔｙｐｅを有する各エレメンタリストリームにおいて、ちょうど１つのＬＰＤ＿ｎａｌ＿ｕｎｉｔが、最小値がＬＰＤ＿ｎａｌ＿ｕｎｉｔのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しい、ＨＥＶＣレイヤ識別子セットに属する値を有するすべてのＮＡＬユニットに先行することができる、例１６の方法。
[0259]例２２．例１〜例２１の方法の任意の組合せを備える、ビデオデータをアセンブルする方法。
[0260]例２３．例１〜例２１の方法の任意の組合せを備える、方法。
[0261]例２４．ビデオデータを処理するためのデバイスであって、ビデオデータを記憶するメモリと、例１〜例２３のいずれかの方法を実施するように構成された１つまたは複数のプロセッサとを備える、デバイス。
[0262]例２５．デバイスがビデオデコーダである、例２４のデバイス。
[0263]例２６．デバイスがビデオエンコーダである、例２４のデバイス。
[0264]例２７．デバイスがビットストリームスプライシングデバイスである、例２４のデバイス。
[0265]例２８．デバイスが媒体アウェア（aware）ネットワーク要素である、例２４のデバイス。
[0266]例２９．ビデオデータを処理するためのデバイスであって、例１〜例２３のいずれかの方法を実施するための手段を備える、デバイス。
[0267]例３０．デバイスがビデオエンコーダまたはビデオデコーダを備える、例２９のデバイス。
[0268]例３１．ビデオ処理デバイスの１つまたは複数のプロセッサに、例１〜例２３のいずれかの方法を実施させる命令を備える、非一時的コンピュータ可読記憶媒体。
[0269]１つまたは複数の例では、本明細書に記載された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装される場合がある。ソフトウェアに実装される場合、機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行される場合がある。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含む場合がある。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形のコンピュータ可読記憶媒体、または（２）信号もしくは搬送波などの通信媒体に相当する場合がある。データ記憶媒体は、本開示に記載された技法の実施のための命令、コード、および／またはデータ構造を取り出すために、１つもしくは複数のコンピュータまたは１つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含む場合がある。
[0270]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに、非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）、およびブルーレイディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲の中に含まれるべきである。
[0271]命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路などの、１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造または本明細書に記載された技法の実施に適した任意の他の構造のいずれかを指す場合がある。加えて、いくつかの態様では、本明細書に記載された機能は、符号化および復号のために構成されるか、または複合コーデックに組み込まれる、専用のハードウェアモジュールおよび／またはソフトウェアモジュール内で提供される場合がある。また、本技法は、１つまたは複数の回路または論理素子において完全に実装され得る。
[0272]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実施される場合がある。様々な構成要素、モジュール、またはユニットは、開示された技法を実施するように構成されたデバイスの機能的態様を強調するように本開示において記載されているが、様々なハードウェアユニットによる実現を必ずしも必要としない。むしろ、上記に記載されたように、様々なユニットは、コーデックハードウェアユニット内で組み合わされるか、または適切なソフトウェアおよび／もしくはファームウェアとともに、上記に記載された１つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合体によって提供される場合がある。
[0273]様々な例が記載されている。これらおよび他の例は、以下の特許請求の範囲の範囲内に入る。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ビデオデータを復号する方法であって、
複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、
バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニットをアセンブルすることと、ここにおいて、
前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用され、
前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号することと、
を備える方法。
［Ｃ２］
前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、または３Ｄ−ＨＥＶＣのビットストリームを含む、Ｃ１に記載の方法。
［Ｃ３］
前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルすること、
をさらに備え、
それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
Ｃ１に記載の方法。
［Ｃ４］
前記ビデオデータストリームはプログラムを含み、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
前記アクセスユニットをアセンブルすることは、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと、
を備える、Ｃ１に記載の方法。
［Ｃ５］
前記アクセスユニットをアセンブルすることは、
現在のオペレーションポイントの出力レイヤに対応する記述子内の１つまたは複数のフィールドに基づいて、前記現在のオペレーションポイントの前記出力レイヤを復号するために必要とされる参照レイヤを識別すること、
を備える、Ｃ４に記載の方法。
［Ｃ６］
前記ビデオデータストリームはトランスポートストリームであり、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファを備え、
前記方法は、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶することをさらに備える、
Ｃ４に記載の方法。
［Ｃ７］
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
前記方法は、
前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶することと、
前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶することと、
さらに備える、Ｃ６に記載の方法。
［Ｃ８］
前記ビデオデータストリームはプログラムを含み、
前記方法は、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択することをさらに備える、
Ｃ１に記載の方法。
［Ｃ９］
ビデオデータを記憶するように構成されたメモリと、
複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、
バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニットをアセンブルすることと、ここにおいて、
前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用され、
前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号することと、
を行うように構成された、１つまたは複数のプロセッサと、
を備える、ビデオ復号デバイス。
［Ｃ１０］
前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、または３Ｄ−ＨＥＶＣのビットストリームを含む、Ｃ９に記載のビデオ復号デバイス。
［Ｃ１１］
前記１つまたは複数のプロセッサは、前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルするように構成され、
それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
Ｃ９に記載のビデオ復号デバイス。
［Ｃ１２］
前記ビデオデータストリームはプログラムを含み、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
前記アクセスユニットをアセンブルすることの一部として、前記１つまたは複数のプロセッサは、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと、
を行う、Ｃ９に記載のビデオ復号デバイス。
［Ｃ１３］
前記アクセスユニットをアセンブルすることの一部として、前記１つまたは複数のプロセッサは、
現在のオペレーションポイントの出力レイヤに対応する記述子内の１つまたは複数のフィールドに基づいて、前記現在のオペレーションポイントの前記出力レイヤを復号するために必要とされる参照レイヤを識別すること、
を行う、Ｃ１２に記載のビデオ復号デバイス。
［Ｃ１４］
前記ビデオデータストリームはトランスポートストリームであり、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファを備え、
前記１つまたは複数のプロセッサは、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶するように構成される、
Ｃ１２に記載のビデオ復号デバイス。
［Ｃ１５］
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
前記１つまたは複数のプロセッサは、
前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶することと、
前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶することと、
を行うように構成される、
Ｃ１４に記載のビデオ復号デバイス。
［Ｃ１６］
前記ビデオデータストリームはプログラムを含み、
前記１つまたは複数のプロセッサは、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択するようにさらに構成される、
Ｃ９に記載のビデオ復号デバイス。
［Ｃ１７］
複数のエレメンタリストリームを備えるビデオデータストリームを受信するための手段と、
バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニットをアセンブルするための手段と、ここにおいて、
前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用され、
前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号するための手段と、
を備える、ビデオ復号デバイス。
［Ｃ１８］
前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、または３Ｄ−ＨＥＶＣのビットストリームを含む、Ｃ１７に記載のビデオ復号デバイス。
［Ｃ１９］
前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルするための手段をさらに備え、
それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
Ｃ１７に記載のビデオ復号デバイス。
［Ｃ２０］
前記ビデオデータストリームはプログラムを含み、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
前記アクセスユニットをアセンブルすることは、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと
を備える、Ｃ１７に記載のビデオ復号デバイス。
［Ｃ２１］
前記アクセスユニットをアセンブルすることは、
現在のオペレーションポイントの出力レイヤに対応する記述子内の１つまたは複数のフィールドに基づいて、前記現在のオペレーションポイントの前記出力レイヤを復号するために必要とされる参照レイヤを識別すること、
を備える、Ｃ２０に記載のビデオ復号デバイス。
［Ｃ２２］
前記ビデオデータストリームはトランスポートストリームであり、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファを備え、
前記ビデオ復号デバイスは、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶するための手段をさらに備える、
Ｃ２０に記載のビデオ復号デバイス。
［Ｃ２３］
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
前記ビデオ復号デバイスは、
前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すための手段と、
前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶するための手段と、
前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すための手段と、
前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶するための手段と、
をさらに備える、Ｃ２２に記載のビデオ復号デバイス。
［Ｃ２４］
前記ビデオデータストリームはプログラムを含み、
前記ビデオ復号デバイスは、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択するための手段をさらに備える、
Ｃ１７に記載のビデオ復号デバイス。
［Ｃ２５］
実行されると、ビデオ復号デバイスに、
複数のエレメンタリストリームを備えるビデオデータストリームを受信することと、
バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニットをアセンブルすることと、ここにおいて、
前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用される、
前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号することと、
を行わせる命令を記憶した、コンピュータ可読データ記憶媒体。
［Ｃ２６］
前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、または３Ｄ−ＨＥＶＣのビットストリームを含む、Ｃ２５に記載のコンピュータ可読データ記憶媒体。
［Ｃ２７］
前記命令は、前記ビデオ復号デバイスに、
前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルすることをさらに行わせ、
それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
Ｃ２５に記載のコンピュータ可読データ記憶媒体。
［Ｃ２８］
前記ビデオデータストリームはプログラムを含み、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
前記アクセスユニットをアセンブルすることの一部として、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、前記命令は前記ビデオ復号デバイスに、
前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと、
を行わせる、Ｃ２５に記載のコンピュータ可読データ記憶媒体。
［Ｃ２９］
前記アクセスユニットをアセンブルすることの一部として、前記命令は前記ビデオ復号デバイスに、
現在のオペレーションポイントの出力レイヤに対応する記述子内の１つまたは複数のフィールドに基づいて、前記現在のオペレーションポイントの前記出力レイヤを復号するために必要とされる参照レイヤを識別すること、
を行わせる、Ｃ２８に記載のコンピュータ可読データ記憶媒体。
［Ｃ３０］
前記ビデオデータストリームはトランスポートストリームであり、
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファを備え、
前記命令は、前記ビデオ復号デバイスに、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶することをさらに行わせる、
Ｃ２８に記載のコンピュータ可読データ記憶媒体。
［Ｃ３１］
前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
前記命令は、前記ビデオ復号デバイスに、
前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶することと、
前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すことと、
前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶することと、
をさらに行わせる、Ｃ３０に記載のコンピュータ可読データ記憶媒体。
［Ｃ３２］
前記ビデオデータストリームはプログラムを含み、
前記命令は、前記ビデオ復号デバイスに、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択することをさらに行わせる、
Ｃ２５に記載のコンピュータ可読データ記憶媒体。

Claims (15)

  1. ビデオデータを復号する方法であって、
    複数のエレメンタリストリームおよび複数の階層拡張記述子を備えるビデオデータストリームを受信することと、前記複数の階層拡張記述子のそれぞれの階層拡張記述子の各々は、前記複数のエレメンタリストリーム内のそれぞれのエレメンタリストリームに対応し、各エレメンタリストリームは１つのレイヤに対応し、各階層拡張記述子は、対応するエレメンタリストリームの前記１つのレイヤに関係し、前記複数のストリームのそれぞれのストリームの各々は、ＭＰＥＧ−２システムにおける高効率ビデオコーディング（ＨＥＶＣ）拡張ビデオストリームであり、
    バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニット内のＨＥＶＣレイヤピクチャをアセンブルすることと、ここにおいて、
    前記バッファモデルは、トランスポートストリームシステムターゲットデコーダモデルまたはプログラムストリームシステムターゲットデコーダモデルであり、
    前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
    前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用され、
    前記アクセスユニットをアセンブルすることは、現在のオペレーションポイントの出力レイヤに対応する前記階層拡張記述子内の１つまたは複数の値に基づいて、前記現在のオペレーションポイントの前記出力レイヤを復号するために必要とされる複数の参照レイヤを識別することを備え、
    前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号することと、
    を備え、
    前記階層拡張記述子内の前記１つまたは複数の値は、前記階層拡張記述子に対応する前記１つのレイヤを復号するために必要とされる参照レイヤを識別する、方法。
  2. 前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、および３Ｄ−ＨＥＶＣのビットストリームを含む、請求項１に記載の方法。
  3. 前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルすること、
    をさらに備え、
    それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
    前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
    請求項１に記載の方法。
  4. 前記ビデオデータストリームはプログラムを含み、
    前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
    前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
    前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
    前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
    前記アクセスユニットをアセンブルすることは、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
    前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと、
    を備える、請求項１に記載の方法。
  5. 前記ビデオデータストリームはトランスポートストリームであり、
    前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファをさらに備え、
    前記方法は、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶することをさらに備え、
    前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットは、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶される、
    請求項４に記載の方法。
  6. 前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
    前記方法は、
    前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すことと、
    前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶することと、
    前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すことと、
    前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶することと、
    さらに備える、請求項５に記載の方法。
  7. 前記ビデオデータストリームはプログラムを含み、
    前記方法は、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択することをさらに備える、
    請求項１に記載の方法。
  8. 複数のエレメンタリストリームおよび複数の階層拡張記述子を備えるビデオデータストリームを受信するための手段と、前記複数の階層拡張記述子のそれぞれの階層拡張記述子の各々は、前記複数のエレメンタリストリーム内のそれぞれのエレメンタリストリームに対応し、各エレメンタリストリームは１つのレイヤに対応し、各階層拡張記述子は、対応するエレメンタリストリームの前記１つのレイヤに関係し、前記複数のストリームのそれぞれのストリームの各々は、ＭＰＥＧ−２システムにおける高効率ビデオコーディング（ＨＥＶＣ）拡張ストリームであり、
    バッファモデルにおいて、前記ビデオデータストリームの前記複数のエレメンタリストリームからアクセスユニット内のＨＥＶＣレイヤピクチャをアセンブルするための手段と、ここにおいて、
    前記バッファモデルは、トランスポートストリームシステムターゲットデコーダモデルまたはプログラムストリームシステムターゲットデコーダモデルであり、
    前記ビデオデータストリームは、トランスポートストリームまたはプログラムストリームであり、
    前記エレメンタリストリームが異なる複数のタイプのマルチレイヤコード化ビットストリームのいずれかを含むかどうかにかかわらず、前記アクセスユニットをアセンブルするために同じバッファモデルが使用され、
    前記アクセスユニットをアセンブルすることは、現在のオペレーションポイントの出力レイヤに対応する前記階層拡張記述子内の１つまたは複数の値に基づいて、現在のオペレーションポイントの出力レイヤを復号するために必要とされる複数の参照レイヤを識別することを備え、
    前記ビデオデータの１つまたは複数のピクチャを備える前記アクセスユニットを復号するための手段と、
    を備え、
    前記階層拡張記述子内の前記１つまたは複数の値は、前記階層拡張記述子に対応する前記１つのレイヤを復号するために必要とされる参照レイヤを識別する、ビデオ復号デバイス。
  9. 前記異なる複数のタイプのマルチレイヤコード化ビットストリームは、スケーラブル高効率ビデオコーディング（ＳＨＶＣ）、マルチビューＨＥＶＣ（ＭＶ−ＨＥＶＣ）、および３Ｄ−ＨＥＶＣのビットストリームを含む、請求項８に記載のビデオ復号デバイス。
  10. 前記ビデオデータストリームのそれぞれのＨＥＶＣ積層ビデオストリームの各々について、前記バッファモデルの別々のインスタンスを使用して、アクセスユニットをアセンブルするための手段をさらに備え、
    それぞれのＨＥＶＣ積層ビデオストリームの各々は、複数のＨＥＶＣビデオレイヤサブビットストリームを備え、
    前記複数のＨＥＶＣビデオレイヤサブビットストリームのそれぞれのＨＥＶＣビデオレイヤサブビットストリームの各々は、同じレイヤ識別子値を有するビデオコーディングレイヤ（ＶＣＬ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える、
    請求項８に記載のビデオ復号デバイス。
  11. 前記ビデオデータストリームはプログラムを含み、
    前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのためのバッファを備え、
    前記アクセスユニットは、前記それぞれのエレメンタリストリームのためのそれぞれのＨＥＶＣレイヤピクチャサブセットを備え、
    前記それぞれのＨＥＶＣレイヤピクチャサブセットは、それぞれのレイヤ識別子セットに関連付けられた前記アクセスユニットのＨＥＶＣレイヤピクチャを備え、
    前記ＨＥＶＣレイヤピクチャの各々は、Ｒｅｃ．ＩＴＵ−Ｔ Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｆにおいて定義されているコード化ピクチャであり、
    前記アクセスユニットをアセンブルすることは、前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記それぞれのエレメンタリストリームのための前記バッファから、前記それぞれのエレメンタリストリームのための前記それぞれのＨＥＶＣレイヤピクチャサブセットを取り出すことと、
    前記アクセスユニットに前記それぞれのＨＥＶＣレイヤピクチャサブセットを含めることと
    を備える、請求項８に記載のビデオ復号デバイス。
  12. 前記ビデオデータストリームはトランスポートストリームであり、
    前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記それぞれのエレメンタリストリームのための前記バッファは、前記それぞれのエレメンタリストリームのための第１のバッファであり、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのための第２のバッファをさらに備え、
    前記ビデオ復号デバイスは、前記それぞれのエレメンタリストリームに属する前記トランスポートストリームのそれぞれのパケット化エレメンタリストリーム（ＰＥＳ）パケットの各々について、前記それぞれのエレメンタリストリームのための前記第２のバッファに前記それぞれのＰＥＳパケットを記憶するための手段をさらに備え、
    前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットは、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶される、
    請求項１１に記載のビデオ復号デバイス。
  13. 前記プログラムに関連付けられたそれぞれのエレメンタリストリームの各々について、
    前記バッファモデルは、前記それぞれのエレメンタリストリームのための第３のバッファを備え、
    前記ビデオ復号デバイスは、
    前記それぞれのエレメンタリストリームのための前記第２のバッファからＰＥＳパケットを取り出すための手段と、
    前記それぞれのエレメンタリストリームのための前記第２のバッファから取り出された前記ＰＥＳパケットを、前記それぞれのエレメンタリストリームのための前記第３のバッファに記憶するための手段と、
    前記それぞれのエレメンタリストリームのための前記第３のバッファからバイトを取り出すための手段と、
    前記それぞれのエレメンタリストリームのための前記第３のバッファから取り出された前記バイトを、前記それぞれのエレメンタリストリームのための前記第１のバッファに記憶するための手段と、
    をさらに備える、請求項１２に記載のビデオ復号デバイス。
  14. 前記ビデオデータストリームはプログラムを含み、
    前記ビデオ復号デバイスは、前記プログラム内にＨＥＶＣレイヤのセットが存在することと、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６５｜ＩＳＯ／ＩＥＣ２３００８−２の付属書類Ｇまたは付属書類Ｈにおいて定義されている１つまたは複数のプロファイルに準拠するＨＥＶＣ拡張ビデオストリームである前記複数のエレメンタリストリーム内に、少なくとも１つのＨＥＶＣ積層ビデオサブビットストリームが存在することとを決定することに応答して、前記アクセスユニットをアセンブルする際に使用するために、前記バッファモデルを選択するための手段をさらに備える、
    請求項８に記載のビデオ復号デバイス。
  15. 実行されると、ビデオ復号デバイスに、請求項１乃至７のいずれか１つに記載の方法を行わせる命令を記憶した、コンピュータ可読データ記憶媒体。
JP2016544789A 2014-01-08 2015-01-08 Ｍｐｅｇ−２システムによるｈｅｖｃ拡張ビットストリームの搬送およびバッファモデル Active JP6553054B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461925191P 2014-01-08 2014-01-08
US61/925,191 2014-01-08
US14/591,649 2015-01-07
US14/591,649 US10567804B2 (en) 2014-01-08 2015-01-07 Carriage of HEVC extension bitstreams and buffer model with MPEG-2 systems
PCT/US2015/010559 WO2015105934A1 (en) 2014-01-08 2015-01-08 Carriage of hevc extension bitstreams and buffer model with mpeg-2 systems

Publications (3)

Publication Number Publication Date
JP2017508339A JP2017508339A (ja) 2017-03-23
JP2017508339A5 JP2017508339A5 (ja) 2018-02-01
JP6553054B2 true JP6553054B2 (ja) 2019-07-31

Family

ID=53496204

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016544789A Active JP6553054B2 (ja) 2014-01-08 2015-01-08 Ｍｐｅｇ−２システムによるｈｅｖｃ拡張ビットストリームの搬送およびバッファモデル

Country Status (16)

Country Link
US (1) US10567804B2 (ja)
EP (1) EP3092814A1 (ja)
JP (1) JP6553054B2 (ja)
KR (1) KR102122110B1 (ja)
CN (1) CN106063287B (ja)
AU (1) AU2015204790C1 (ja)
CA (1) CA2932442C (ja)
CL (1) CL2016001719A1 (ja)
IL (1) IL246147B (ja)
MX (1) MX370171B (ja)
MY (1) MY189813A (ja)
PH (1) PH12016501217A1 (ja)
RU (1) RU2685233C2 (ja)
SA (1) SA516371468B1 (ja)
SG (2) SG10201805774WA (ja)
WO (1) WO2015105934A1 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150103895A1 (en) * 2013-10-13 2015-04-16 Sharp Laboratories Of America, Inc. Electronic devices for signaling multiple initial buffering parameters
WO2015125489A1 (en) * 2014-02-24 2015-08-27 Sharp Kabushiki Kaisha Restrictions on signaling
US10057582B2 (en) * 2014-05-21 2018-08-21 Arris Enterprises Llc Individual buffer management in transport of scalable video
MX364550B (es) * 2014-05-21 2019-04-30 Arris Entpr Llc Señalización y selección para la mejora de capas en vídeo escalable.
US9699480B2 (en) * 2014-06-13 2017-07-04 Sharp Laboratories Of America, Inc. Level limits
US9998765B2 (en) 2014-07-16 2018-06-12 Qualcomm Incorporated Transport stream for carriage of video coding extensions
US10306269B2 (en) 2014-10-10 2019-05-28 Qualcomm Incorporated Operation point for carriage of layered HEVC bitstream
US20160112724A1 (en) * 2014-10-15 2016-04-21 Qualcomm Incorporated Hrd descriptor and buffer model of data streams for carriage of hevc extensions
US20160234528A1 (en) * 2015-02-09 2016-08-11 Arris Enterprises, Inc. Carriage of video coding for browsers (vcb) video over mpeg-2 transport streams
EP3313043B1 (en) * 2016-10-19 2019-08-07 Sandvine Incorporated ULC System and method for determining quality of a media stream
CN106782623A (zh) * 2017-01-12 2017-05-31 浙江新盛蓝科技有限公司 一种视频播放器
US11070846B2 (en) * 2017-05-01 2021-07-20 Realnetworks, Inc. Multi-layered video streaming systems and methods
US10917650B2 (en) * 2018-07-11 2021-02-09 Cisco Technology, Inc. Resilient transmission of raw video streams over an IP communication network
US10796443B2 (en) * 2018-10-17 2020-10-06 Kneron, Inc. Image depth decoder and computing device
WO2020188273A1 (en) * 2019-03-20 2020-09-24 V-Nova International Limited Low complexity enhancement video coding
WO2021027774A1 (en) 2019-08-10 2021-02-18 Beijing Bytedance Network Technology Co., Ltd. Subpicture dependent signaling in video bitstreams
MX2022008794A (es) * 2020-03-25 2022-08-11 Panasonic Ip Corp America Codificador, decodificador, metodo de codificacion y metodo de decodificacion.
CN113225584B (zh) * 2021-03-24 2022-02-22 西安交通大学 一种基于编码和缓存的跨层联合的视频传输方法、系统
CN114630129A (zh) * 2022-02-07 2022-06-14 浙江智慧视频安防创新中心有限公司 一种基于智能数字视网膜的视频编解码方法和装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2007287222A1 (en) 2006-08-24 2008-02-28 Nokia Corporation System and method for indicating track relationships in media files
GB0700381D0 (en) 2007-01-09 2007-02-14 Mitsubishi Electric Inf Tech Generalised Hypothetical Reference Decoder for Scalable Video Coding with Bitstream Rewriting
US9167246B2 (en) 2008-03-06 2015-10-20 Arris Technology, Inc. Method and apparatus for decoding an enhanced video stream
CA2748866C (en) 2009-01-06 2016-06-21 Lg Electronics Inc. Method for processing three dimensional (3d) video signal and digital broadcast receiver for performing the method
CN103202023A (zh) * 2010-10-25 2013-07-10 松下电器产业株式会社 编码方法、显示装置、解码方法
US9451252B2 (en) 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
WO2015009693A1 (en) 2013-07-15 2015-01-22 Sony Corporation Layer based hrd buffer management for scalable hevc
CN105874804A (zh) * 2014-01-02 2016-08-17 Vid拓展公司 针对hevc扩展的子比特流提取过程

Also Published As

Publication number Publication date
CN106063287B (zh) 2020-07-28
SG10201805774WA (en) 2018-08-30
NZ720689A (en) 2021-07-30
BR112016015903A2 (pt) 2017-08-08
IL246147B (en) 2019-12-31
MX370171B (es) 2019-12-04
PH12016501217B1 (en) 2016-08-15
SA516371468B1 (ar) 2020-09-26
KR102122110B1 (ko) 2020-06-11
US10567804B2 (en) 2020-02-18
US20150195578A1 (en) 2015-07-09
AU2015204790A1 (en) 2016-06-16
RU2016127197A (ru) 2018-02-09
KR20160106097A (ko) 2016-09-09
SG11201604247UA (en) 2016-07-28
CA2932442C (en) 2021-01-26
CA2932442A1 (en) 2015-07-16
PH12016501217A1 (en) 2016-08-15
MY189813A (en) 2022-03-09
RU2685233C2 (ru) 2019-04-17
CL2016001719A1 (es) 2017-02-10
RU2016127197A3 (ja) 2018-07-02
IL246147A0 (en) 2016-07-31
JP2017508339A (ja) 2017-03-23
AU2015204790C1 (en) 2019-07-04
CN106063287A (zh) 2016-10-26
WO2015105934A1 (en) 2015-07-16
MX2016008897A (es) 2016-09-16
EP3092814A1 (en) 2016-11-16
AU2015204790B2 (en) 2019-01-31

Similar Documents

Publication Publication Date Title
JP6553054B2 (ja) Ｍｐｅｇ−２システムによるｈｅｖｃ拡張ビットストリームの搬送およびバッファモデル
US10171842B2 (en) HRD descriptor and buffer model of data streams for carriage of HEVC extensions
KR101984368B1 (ko) 하나 이상의 계층들을 포함하는 파티션과 연관된 프로파일, 티어 및 레벨에 기초하여 디코더의 능력을 결정하는 것에 의해 멀티-계층 비디오 데이터를 디코딩하기 위한 방법 및 디바이스
CN106797480B (zh) 用于分层hevc位流的运载的操作点
KR102315232B1 (ko) Mpeg-2 시스템들을 이용한 비디오 코딩 표준 확장 비트스트림 데이터의 캐리지
KR101968425B1 (ko) 비디오 코딩 확장본들의 캐리지를 위한 전송 스트림
KR101906136B1 (ko) Hevc 확장들의 캐리지를 위한 동작 포인트들의 시그널링
BR112016008953B1 (pt) Condução de dados de fluxo de bits com extensão- padrão de codificação de vídeo com o uso de sistemas de mpeg-2

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171213

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171213

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180913

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181213

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190703

R150 Certificate of patent or registration of utility model

Ref document number: 6553054

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250