JP6542378B2 - 階層化されたビデオファイルフォーマットにおけるサンプルエントリー及び動作点信号伝達の設計 - Google Patents

階層化されたビデオファイルフォーマットにおけるサンプルエントリー及び動作点信号伝達の設計 Download PDF

Info

Publication number
JP6542378B2
JP6542378B2 JP2017541910A JP2017541910A JP6542378B2 JP 6542378 B2 JP6542378 B2 JP 6542378B2 JP 2017541910 A JP2017541910 A JP 2017541910A JP 2017541910 A JP2017541910 A JP 2017541910A JP 6542378 B2 JP6542378 B2 JP 6542378B2
Authority
JP
Japan
Prior art keywords
box
video data
information
video
layer
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
JP2017541910A
Other languages
English (en)
Other versions
JP2018511208A5 (ja
JP2018511208A (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 JP2018511208A publication Critical patent/JP2018511208A/ja
Publication of JP2018511208A5 publication Critical patent/JP2018511208A5/ja
Application granted granted Critical
Publication of JP6542378B2 publication Critical patent/JP6542378B2/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/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/187—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 a scalable video layer
    • 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
    • H04N19/39—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability involving multiple description coding [MDC], i.e. with separate layers being structured as independently decodable descriptions of input picture data
    • 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/46—Embedding additional information in the video signal during the compression process
    • 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
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • 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/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Processing Or Creating Images (AREA)

Description

[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、２０１５年２月１１日に出願された米国仮特許出願第６２／１１５，０７５号の利益を主張する。
[0002]本開示は、ビデオコード化に関する。
[0003]デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップコンピュータ又はデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録機器、デジタルメディアプレーヤ、ビデオゲーム機器、コンソール型ビデオゲーム機、携帯電話機若しくは衛星無線電話機、所謂「スマートフォン」、ビデオ会議機器、ビデオストリーミング機器などを含む広範囲の機器に組み込まれ得る。デジタルビデオ機器は、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ １０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格によって定義された規格、及びそのような規格の拡張に記載されているもののような、ビデオ圧縮技法を実装する。これらのビデオ機器は、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信し、受信し、符号化し、復号し、及び／又は記憶することができる。
[0004]ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減又は除去するために、空間的（イントラピクチャ）予測及び／又は時間的（インターピクチャ）予測を実行する。ブロックベースのビデオコード化では、ビデオスライス（即ち、ビデオフレーム又はビデオフレームの一部分）が、ツリーブロック、コード化単位（ＣＵ）及び／又はコード化ノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャの被イントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測を使用して符号化される。ピクチャの被インターコード化（Ｐ又はＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測又は他の参照ピクチャ中の参照サンプルに対する時間的予測を使用することができる。ピクチャは、フレームと呼ばれることがあり、参照ピクチャは、参照フレームと呼ばれることがある。
[0005]ビデオデータが符号化された後、ビデオデータは送信又は記憶のためにパケット化され得る。ビデオデータは、ＡＶＣなどの、国際標準化機構（ＩＳＯ）ベースのメディアファイルフォーマット及びその拡張などの、様々な規格のいずれかに準拠するビデオファイルへと組み立てられ得る。
[0006]全般に、本開示は、ファイルにビデオコンテンツを記憶することに関する。幾つかの例では、本開示の技法は、国際標準化機構（ＩＳＯ）ベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ISO base media file format）に基づく。本開示の幾つかの例は、複数の被コード化レイヤを含むビデオストリームを記憶するための方法に関し、ここで各レイヤは、スケーラブルレイヤ、テクスチャビュー、深度ビューなどであってよく、その方法は、Ｍｕｌｔｉ−Ｖｉｅｗ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＭＶ−ＨＥＶＣ）、Ｓｃａｌａｂｌｅ ＨＥＶＣ（ＳＨＶＣ）、３次元ＨＥＶＣ（３Ｄ−ＨＥＶＣ）、及び他のタイプのビデオデータの記憶に適用され得る。
[0007]一例では、マルチレイヤビデオデータを処理する方法は、マルチレイヤビデオデータを取得することと、マルチレイヤビデオデータをあるファイルフォーマットで記憶することと、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスにマルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶することと、そのファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成することとを含む。
[0008]別の例では、マルチレイヤビデオデータを処理する方法は、あるファイルフォーマットに従ってフォーマットされたマルチレイヤビデオデータのファイルを取得することと、そのファイルフォーマットに対して、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックス中のマルチレイヤビデオデータの各動作点のための表現フォーマット情報を決定することと、決定された表現フォーマット情報に基づいてマルチレイヤビデオデータを復号することとを含む。
[0009]別の例では、マルチレイヤビデオデータを処理するためのビデオ機器は、マルチレイヤビデオデータを記憶するように構成されるデータ記憶媒体と、１つ又は複数のプロセッサとを含み、１つ又は複数のプロセッサは、マルチレイヤビデオデータを取得し、マルチレイヤビデオデータをあるファイルフォーマットで記憶し、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスにマルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶し、そのファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成するように構成される。
[0010]別の例では、マルチレイヤビデオデータを処理するためのビデオ機器は、マルチレイヤビデオデータを記憶するように構成されるデータ記憶媒体と、１つ又は複数のプロセッサとを含み、１つ又は複数のプロセッサは、あるファイルフォーマットに従ってフォーマットされたマルチレイヤビデオデータのファイルを取得し、そのファイルフォーマットに対して、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックス中のマルチレイヤビデオデータの各動作点のための表現フォーマット情報を決定し、決定された表現フォーマット情報に基づいてマルチレイヤビデオデータを復号するように構成される。
[0011]別の例では、マルチレイヤビデオデータを処理するためのビデオ機器は、マルチレイヤビデオデータを取得するための手段と、マルチレイヤビデオデータをあるファイルフォーマットで記憶するための手段と、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスにマルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶するための手段と、そのファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成するための手段とを含む。
[0012]別の例では、コンピュータ可読記憶媒体は、実行されると、１つ又は複数のプロセッサに、マルチレイヤビデオデータを取得させ、マルチレイヤビデオデータをあるファイルフォーマットで記憶させ、そのファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスにマルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶させ、そのファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成させる命令を記憶する。
[0013]本開示の１つ又は複数の例の詳細は、添付の図面及び以下の説明に記載される。他の特徴、目的、及び利点は、説明、図面、及び特許請求の範囲から明らかになろう。
[0014]本開示で説明される技法を使用することができる、例示的なビデオ符号化及び復号システムを示すブロック図。 [0015]本開示で説明される技法を実施し得る例示的なビデオエンコーダを示すブロック図。 [0016]本開示で説明される技法を実施し得る例示的なビデオデコーダを示すブロック図。 [0017]ネットワークの一部を形成する機器の例示的なセットを示すブロック図。 [0018]本開示の１つ又は複数の技法による、ファイルの例示的な構造を示す概念図。 本開示の１つ又は複数に技法による、ファイルの例示的な構造を示す概念図。 [0020]本開示の１つ又は複数の技法による、ファイルの例示的な構造を示す概念図。 [0021]ファイル生成機器の例示的な動作を示すフローチャート。 [0022]本開示の１つ又は複数の技法による、ファイル読取り機器の例示的な動作を示すフローチャート。
[0023]ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ）は、メディアデータを記憶するためのファイルフォーマットである。ＩＳＯＢＭＦＦは、特定のビデオコード化規格に準拠するビデオデータの記憶をサポートするように拡張可能である。例えば、ＩＳＯＢＭＦＦは以前、Ｈ．２６４／ＡＶＣ及びＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）ビデオコード化規格に準拠するビデオデータの記憶をサポートするように、拡張されている。更に、ＩＳＯＢＭＦＦは以前、Ｈ．２６４／ＡＶＣのマルチビューコード化（ＭＶＣ）及びスケーラブルビデオコード化（ＳＶＣ）拡張に準拠するビデオデータの記憶をサポートするように拡張されている。ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ及びＳＨＶＣは、マルチレイヤビデオデータをサポートするＨＥＶＣビデオコード化規格の拡張である。Ｈ．２６４／ＡＶＣのＭＶＣ及びＳＶＣ拡張に準拠するビデオデータの記憶のためにＩＳＯＢＭＦＦに追加される特徴は、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、及びＳＨＶＣに準拠するビデオデータの効果的な記憶には十分ではない。言い換えると、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、及びＳＨＶＣに準拠するビデオデータの記憶のためにＨ．２６４／ＡＶＣのＭＶＣ及びＳＶＣ拡張に準拠するビデオデータの記憶のためにＩＳＯＢＭＦＦの拡張を使用しようとすると、様々な問題が生じ得る。
[0024]例えば、Ｈ．２６４／ＡＶＣのＭＶＣ又はＳＶＣ拡張に準拠するビットストリームとは異なり、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ、又はＳＨＶＣに準拠するビットストリームは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャと非ＩＲＡＰピクチャとを含むアクセス単位を含み得る。ＩＲＡＰピクチャと非ＩＲＡＰピクチャとを含むアクセス単位は、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ及びＳＨＶＣではランダムアクセスのために使用され得る。しかしながら、ＩＳＯＢＭＦＦ及びその既存の拡張は、そのようなアクセス単位を特定する方法を提供しない。このことは、ランダムアクセス、レイヤ切替え、及びマルチレイヤビデオデータと関連付けられる他のそのような機能を実行するためのコンピュータ機器の能力を妨げ得る。
[0025]本開示の技法の説明の大半は、ＭＶ−ＨＥＶＣと、３Ｄ−ＨＥＶＣと、ＳＨＶＣとを説明するが、本開示の技法は、他のビデオコード化規格及び／又はその拡張に適用可能であり得ることを、読者は理解するだろう。
[0026]以下でより詳細に説明されるように、ＨＥＶＣファイルフォーマットに準拠するファイルは、ボックスと呼ばれる一連のオブジェクトを含み得る。ボックスは、固有のタイプ識別子及び長さによって定義されるオブジェクト指向の構築ブロックであり得る。本開示は、ファイルフォーマットに従ってファイルを生成することに関する技法を説明し、より具体的には、複数の動作点を含むファイルを処理するための再生機器の能力を潜在的に向上させるように幾つかのボックス中の幾つかのタイプの情報を見つけるための技法を説明する。
[0027]本開示の技法の説明の大半は、ＭＶ−ＨＥＶＣと、３Ｄ−ＨＥＶＣと、ＳＨＶＣとを説明するが、本開示の技法は、他のビデオコード化規格及び／又はその拡張に適用可能であり得ることを、読者は理解するだろう。
[0028]図１は、本開示で説明される技法を使用することができる、例示的なビデオ符号化及び復号システム１０を示すブロック図である。図１に示されているように、システム１０は、宛先機器１４によって後で復号されるべき被符号化ビデオデータを生成する発信源機器１２を含む。発信源機器１２及び宛先機器１４は、デスクトップコンピュータ、ノートブック（即ち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、所謂「スマート」フォンなどの電話ハンドセット、所謂「スマート」パッド、テレビジョン、カメラ、表示装置、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミング機器などを含む、広範囲の機器のいずれかを備え得る。場合によっては、発信源機器１２及び宛先機器１４は、ワイヤレス通信に対応し得る。発信源機器１２及び宛先機器１４は、ビデオ機器と見なされ得る。
[0029]図１の例では、発信源機器１２は、ビデオ発信源１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。場合によっては、出力インターフェース２２は、変調器／復調器（モデム）及び／又は送信機を含み得る。発信源機器１２において、ビデオ発信源１８は、撮像装置、例えばビデオカメラ、以前に撮られたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース及び／又は発信源ビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムのような、発信源、又はそのような発信源の組合せを含み得る。しかしながら、本開示で説明される技法は、ビデオコード化全般に適用可能であってよく、ワイヤレス及び／又は有線の適用例に適用され得る。
[0030]ビデオエンコーダ２０は、撮られたビデオ、以前に撮られたビデオ、又はコンピュータで生成されたビデオを符号化することができる。発信源機器１２は、被符号化ビデオデータを、発信源機器１２の出力インターフェース２２を介して宛先機器１４に直接送信することができる。被符号化ビデオデータは、更に（又は代替的に）、復号及び／又は再生のための宛先機器１４又は他の機器による後のアクセスのために、記憶機器３３に記憶され得る。
[0031]宛先機器１４は、入力インターフェース２８と、ビデオデコーダ３０と、表示装置３２とを含む。場合によっては、入力インターフェース２８は、受信機及び／又はモデムを含み得る。宛先機器１４の入力インターフェース２８は、リンク１６を通じて、被符号化ビデオデータを受信する。リンク１６を通じて通信され、又は記憶機器３３上に与えられた被符号化ビデオデータは、ビデオデータを復号する際にビデオデコーダ３０などのビデオデコーダが使用するための、ビデオエンコーダ２０によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信される、記憶媒体上に記憶される、又はファイルサーバ上に記憶される、被符号化ビデオデータとともに含まれ得る。
[0032]表示装置３２は、宛先機器１４と一体化されてよく、又はその外部にあってよい。幾つかの例では、宛先機器１４は、一体型表示装置を含んでよく、外部の表示装置とインターフェースするように構成されてもよい。他の例では、宛先機器１４は表示装置であり得る。一般に、表示装置３２は、被復号ビデオデータをユーザに表示し、液晶表示器（ＬＣＤ）、プラズマ表示器、有機発光ダイオード（ＯＬＥＤ）表示器、又は別のタイプの表示装置などの様々な表示装置のいずれかを備え得る。
[0033]ビデオエンコーダ２０及びビデオデコーダ３０は各々、１つ又は複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組合せのような、様々な適切なエンコーダ回路のいずれかとして実装され得る。本技法がソフトウェアで部分的に実装されるとき、機器は、ソフトウェアに対する命令を適切な非一時的コンピュータ可読媒体に記憶し、本開示の技法を実行するために、１つ又は複数のプロセッサを使用して命令をハードウェアで実行することができる。ビデオエンコーダ２０及びビデオデコーダ３０の各々は、１つ又は複数のエンコーダ又はデコーダの中に含まれてよく、そのいずれかが、それぞれの機器において複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。
[0034]宛先機器１４は、リンク１６を介して、復号されるべき被符号化ビデオデータを受信することができる。リンク１６は、発信源機器１２から宛先機器１４に被符号化ビデオデータを移すことが可能な任意のタイプの媒体又は機器を備え得る。一例では、リンク１６は、発信源機器１２が、被符号化ビデオデータをリアルタイムで宛先機器１４に直接送信することを可能にするための通信媒体を備え得る。被符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先機器１４に送信され得る。通信媒体は、高周波（ＲＦ）スペクトル又は１つ又は複数の物理伝送線路のような、任意のワイヤレス又は有線の通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク又はインターネットなどのグローバルネットワークのような、パケットベースのネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局又は発信源機器１２から宛先機器１４への通信を容易にするために有用であり得る任意の他の機器を含み得る。
[0035]代替的に、出力インターフェース２２は、記憶機器３３に符号化されたデータを出力することができる。同様に、入力インターフェース２８は、符号化されたデータ記憶機器３３にアクセスすることができる。記憶機器３３は、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性若しくは不揮発性メモリ、又は被符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体のような、様々な分散された、又はローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。更なる例では、記憶機器３３は、発信源機器１２によって生成された被符号化ビデオを保持し得るファイルサーバ又は別の中間記憶機器に対応し得る。宛先機器１４は、ストリーミング又はダウンロードを介して、記憶機器３３から記憶されたビデオデータにアクセスすることができる。ファイルサーバは、被符号化ビデオデータを記憶し、その被符号化ビデオデータを宛先機器１４に送信することが可能な任意のタイプのサーバであってよい。例示的なファイルサーバは、（例えば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続記憶（ＮＡＳ）機器又はローカルディスクドライブを含む。宛先機器１４は、インターネット接続を含む、任意の標準的なデータ接続を介して、被符号化ビデオデータにアクセスすることができる。これは、ファイルサーバ上に記憶されている被符号化ビデオデータにアクセスするのに適した、ワイヤレスチャネル（例えば、Ｗｉ−Ｆｉ（登録商標）接続）、有線接続（例えば、ＤＳＬ、ケーブルモデムなど）、又はその両方の組合せを含み得る。記憶機器３３からの被符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、又は両方の組合せであり得る。
[0036]本開示の技法は、必ずしもワイヤレスの適用例又は設定に限定されるとは限らない。本技法は、無線テレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、例えばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、又は他の適用例などの、様々なマルチメディア適用例のいずれかをサポートするビデオコード化に適用され得る。幾つかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング及び／又はビデオ電話などの適用例をサポートするために、一方向又は双方向のビデオ送信をサポートするように構成され得る。
[0037]更に、図１の例では、ビデオコード化システム１０はファイル生成機器３４を含み得る。ファイル生成機器３４は、発信源機器１２によって生成された被符号化ビデオデータを受信することができ、また被符号化ビデオデータを含むファイルを生成することができる。宛先機器１４は、直接、又は記憶機器３３を介して、ファイル生成機器３４によって生成されたファイルを受信し得る。様々な例において、ファイル生成機器３４は、様々なタイプのコンピュータ機器を含み得る。例えば、ファイル生成機器３４は、メディア認識ネットワーク要素（ＭＡＮＥ：Media Aware Network Element）、サーバコンピュータ機器、パーソナルコンピュータ機器、専用コンピュータ機器、商用コンピュータ機器、又は別のタイプのコンピュータ機器を備え得る。幾つかの例では、ファイル生成機器３４は、コンテンツ配信ネットワークの一部である。ファイル生成機器３４は、リンク１６のようなチャネルを介して発信源機器１２から被符号化ビデオデータを受信することができる。更に、宛先機器１４は、リンク１６のようなチャネルを介してファイル生成機器３４からファイルを受信することができる。
[0038]幾つかの構成では、ファイル生成機器３４は、発信源機器１２及び宛先機器１４とは別個のビデオ機器であり得るが、他の構成では、ファイル生成機器３４は、発信源機器１２又は宛先機器１４のコンポーネントとして実装され得る。ファイル生成機器３４が発信源機器１２又は宛先機器１４のコンポーネントである実装形態では、ファイル生成機器３４は、メモリ、プロセッサ及び他のハードウェアなどの、ビデオエンコーダ２０及びビデオデコーダ３０によって利用される同じリ発信源の一部を共有し得る。ファイル生成機器３４が別個の機器である実装形態では、ファイル生成機器は、固有のメモリと、プロセッサと、他のハードウェアユニットとを含み得る。
[0039]他の例では、発信源機器１２又は別のコンピュータ機器は、被符号化ビデオデータを含むファイルを生成することができる。しかしながら、説明を簡単にするために、本開示は、ファイルを生成するものとしてファイル生成機器３４を説明する。それでも、そのような説明はコンピュータ機器全般に適用可能であることを理解されたい。
[0040]ビデオエンコーダ２０及びビデオデコーダ３０は、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格及びその拡張のような、ビデオ圧縮規格に従って動作し得る。ＨＥＶＣ規格は、ＩＳＯ／ＩＥＣ ２３００８−２とも呼ばれ得る。最近、ＨＥＶＣの設計は、ＩＴＵ−Ｔ Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＶＣＥＧ）とＩＳＯ／ＩＥＣ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）とのＪｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｏｎ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって完成された。以後ＨＥＶＣ ＷＤと呼ばれる、最新のＨＥＶＣドラフト仕様は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００３−ｖ１．ｚｉｐから入手可能である。ＨＥＶＣに対するマルチビュー拡張、即ちＭＶ−ＨＥＶＣも、ＪＣＴ−３Ｖによって開発中である。以後ＭＶ−ＨＥＶＣ ＷＤ５と呼ばれる、「ＭＶ−ＨＥＶＣ Ｄｒａｆｔ Ｔｅｘｔ ５」という表題の、ＭＶ−ＨＥＶＣの最近のワーキングドラフト（ＷＤ）は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００４−ｖ６．ｚｉｐから入手可能である。ＳＨＶＣと称するＨＥＶＣに対するスケーラブル拡張も、ＪＣＴ−ＶＣによって開発中である。以後ＳＨＶＣ ＷＤ３と呼ばれる、「Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ（ＨＥＶＣ） ｓｃａｌａｂｌｅ ｅｘｔｅｎｓｉｏｎ ｄｒａｆｔ ３」という表題の、ＳＨＶＣの最新のワーキングドラフト（ＷＤ）は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｔ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００８−ｖ３．ｚｉｐから入手可能である。ＨＥＶＣの範囲の拡張の最新のワーキングドラフト（ＷＤ）は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１４＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴＶＣ−Ｎ１００５−ｖ３．ｚｉｐから入手可能である。「３Ｄ−ＨＥＶＣ Ｄｒａｆｔ Ｔｅｘｔ １」という表題の、ＨＥＶＣの３Ｄ拡張、即ち３Ｄ−ＨＥＶＣの最新のワーキングドラフト（ＷＤ）は、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ２／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／５＿Ｖｉｅｎｎａ／ｗｇ１１／ＪＣＴ３Ｖ−Ｅ１００１−ｖ３．ｚｉｐから入手可能である。ビデオエンコーダ２０及びビデオデコーダ３０は、これらの規格の１つ又は複数に従って動作し得る。
[0041]代替的に、ビデオエンコーダ２０及びビデオデコーダ３０は、他のプロプライエタリ規格、若しくは、ＭＰＥＧ−４，Ｐａｒｔ １０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と代替的に呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格のような業界規格、又は、そのような規格の拡張に従って動作することができる。しかしながら、本開示の技法は、いかなる特定のコード化規格にも限定されない。ビデオ圧縮規格の他の例は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２又はＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ及びスケーラブルビデオコード化（ＳＶＣ）拡張とマルチビュービデオコード化（ＭＶＣ）拡張とを含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４を含む。
[0042]図１には示されていないが、幾つかの態様では、ビデオエンコーダ２０及びビデオデコーダ３０は各々、オーディオエンコーダ及びデコーダと統合されてよく、共通のデータストリーム又は別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、又は他のハードウェア及びソフトウェアを含み得る。ＭＵＸ−ＤＥＭＵＸユニットは、適用可能な場合、幾つかの例では、ＩＴＵ Ｈ．２２３マルチプレクサプロトコル、又はユーザデータプロトコル（ＵＤＰ）のような他のプロトコルに適合し得る。
[0043]ＪＣＴ−ＶＣは、ＨＥＶＣ規格を開発した。ＨＥＶＣ規格化の取組みは、ＨＥＶＣ Ｔｅｓｔ Ｍｏｄｅｌ（ＨＭ）と呼ばれるビデオコード化機器の進化するモデルに基づく。ＨＭは、例えばＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣに従う既存の機器に対する、ビデオコード化機器の幾つかの追加の能力を仮定する。例えば、Ｈ．２６４／ＡＶＣは、９つのイントラ予測符号化モードを提供するが、ＨＭは、３３個もの多数のイントラ予測符号化モードを提供することができる。
[0044]全般に、ＨＭの作業モデルは、ビデオフレーム又はピクチャが、ルーマサンプルとクロマサンプルの両方を含むツリーブロック又は最大コード化単位（ＬＣＵ）のシーケンスに分割され得ることを記述する。ツリーブロックは、「コード化ツリー単位」（ＣＴＵ）とも呼ばれ得る。ツリーブロックは、Ｈ．２６４／ＡＶＣ規格のマクロブロックと同様の目的を有する。スライスは、コード化順序での、幾つかの連続するツリーブロックを含む。ビデオフレーム又はピクチャは、１つ又は複数のスライスに区分され得る。各ツリーブロックは、四分木に従ってコード化単位（ＣＵ）に分割され得る。例えば、４分木のルートノードとしてのツリーブロックは、４つの子ノードに分割されてよく、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割されてよい。４分木のリーフノードとしての、最終的な、分割されていない子ノードは、コード化ノード、即ち、被コード化ビデオブロックを備える。被コード化ビットストリームと関連付けられるシンタックスデータは、ツリーブロックが分割され得る最大の回数を定義することができ、コード化ノードの最小のサイズを定義することもできる。
[0045]ＣＵは、コード化ノードと、コード化ノードと関連付けられる予測単位（ＰＵ）及び変換単位（ＴＵ）とを含む。ＣＵのサイズは、コード化ノードのサイズに対応し、形状が正方形でなければならない。ＣＵのサイズは、８×８画素から、最大で６４×６４画素、又はそれを越えるツリーブロックのサイズにまでわたり得る。各ＣＵは、１つ又は複数のＰＵと、１つ又は複数のＴＵとを含み得る。ＣＵと関連付けられるシンタックスデータは、例えば、ＣＵの１つ又は複数のＰＵへの区分を記述し得る。区分モードは、ＣＵがスキップモード符号化若しくは直接モード符号化されるのか、イントラ予測モード符号化されるのか、又はインター予測モード符号化されるのかによって異なり得る。ＰＵは、形状が非方形となるように区分され得る。ＣＵと関連付けられるシンタックスデータは、例えば、４分木に従った１つ又は複数のＴＵへのＣＵの区分を記述し得る。ＴＵは、形状が方形又は非方形であり得る。
[0046]ＨＥＶＣ規格は、異なるＣＵに対して異なり得る、ＴＵに従った変換を可能にする。ＴＵは通常、区分されたＬＣＵについて定義される所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、必ずそうなっているとは限らない。ＴＵは通常、ＰＵ以下のサイズである。幾つかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ）として知られる４分木構造を使用して、より小さい単位に再分割され得る。ＲＱＴのリーフノードは、ＴＵと呼ばれ得る。ＴＵと関連付けられる画素差分値は、量子化され得る変換係数を生成するために変換され得る。
[0047]一般に、ＰＵは、予測プロセスに関するデータを含む。例えば、ＰＵがイントラモード符号化されるとき、ＰＵは、ＰＵのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵの動きベクトルを定義するデータを含み得る。ＰＵの動きベクトルを定義するデータは、例えば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの分解能（例えば、１／４画素精度又は１／８画素精度）、動きベクトルが指す参照ピクチャ、及び／又は動きベクトルの参照ピクチャリスト（例えば、リスト０、リスト１、又はリストＣ）を記述することができる。
[0048]一般に、ＴＵは、変換プロセス及び量子化プロセスのために使用される。１つ又は複数のＰＵを有する所与のＣＵは、１つ又は複数の変換単位（ＴＵ）も含み得る。予測の後に、ビデオエンコーダ２０は、ＰＵに対応する残差値を計算することができる。残差値は画素差分値を備え、画素差分値は、エントロピーコード化のための被直列化変換係数を生成するために、ＴＵを使用して変換係数に変換され、量子化され、走査され得る。本開示は通常、ＣＵのコード化ノード（即ち、コード化ブロック）を指すために「ビデオブロック」という用語を使用する。幾つかの特定の場合には、本開示はまた、コード化ノードとＰＵとＴＵと含む、ツリーブロック、即ち、ＬＣＵ又はＣＵを指すために、「ビデオブロック」という用語を使用し得る。
[0049]ビデオシーケンスは通常、一連のビデオフレーム又はピクチャを含む。ピクチャグループ（ＧＯＰ）は、一般に、ビデオピクチャのうちの一連の１つ又は複数を備える。ＧＯＰは、ＧＯＰに含まれる幾つかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ、ピクチャの１つ又は複数のヘッダ、又は他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスの符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコード化ノードに対応し得る。ビデオブロックは、固定されたサイズ又は変化するサイズを有してよく、指定されるコード化規格によってサイズが異なり得る。
[0050]例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２Ｎ又はＮ×ＮのＰＵサイズでのイントラ予測と、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、又はＮ×Ｎの対称的なＰＵサイズでのインター予測とをサポートする。ＨＭは、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、及びｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をもサポートする。非対称区分では、ＣＵの一方の方向は、区分されず、他方の方向は、２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とそれに続く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」又は「Ｒｉｇｈｔ」の表示とによって示される。従って、例えば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ ＰＵ及び下部の２Ｎ×１．５Ｎ ＰＵへと水平に区分される２Ｎ×２Ｎ ＣＵを指す。
[0051]本開示では、「Ｎ×Ｎ（Ｎ×Ｎ）」及び「Ｎ×Ｎ（Ｎ ｂｙ Ｎ）」は、垂直方向の寸法及び水平方向の寸法に関するビデオブロックの画素寸法、例えば、１６×１６（１６×１６）画素又は１６×１６（１６ ｂｙ １６）画素を指すために互換的に使用され得る。一般に、１６×１６ブロックは、垂直方向に１６画素（ｙ＝１６）及び水平方向に１６画素（ｘ＝１６）を有する。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮ画素、及び水平方向にＮ画素を有し、ここでＮは非負の整数値を表す。ブロック中の画素は、行及び列に配置され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数の画素を有する必要はない。例えば、ブロックはＮ×Ｍ画素を備えてよく、この場合に、Ｍは必ずしもＮに等しいとは限らない。
[0052]ＣＵのＰＵを使用したイントラ予測コード化又はインター予測コード化に続いて、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算することができる。ＰＵは、（画素領域とも呼ばれる）空間領域における画素データを備えてよく、ＴＵは、変換、例えば、残差ビデオデータに対する離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、又は概念的に同様の変換の適用の後の、変換領域における係数を備えてよい。残差データは、符号化されていないピクチャの画素とＰＵに対応する予測値との間の画素差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＣＵのための変換係数を生成するためにＴＵを変換することができる。
[0053]変換係数を生成するためのあらゆる変換の後で、ビデオエンコーダ２０は、変換係数の量子化を実行することができる。量子化は一般に、係数を表すために使用されるデータの量をできるだけ低減するために、変換係数が量子化され、更なる圧縮を実現するプロセスを指す。量子化プロセスは、係数の一部又は全てと関連付けられるビット深度を低減することができる。例えば、ｎビットの値は、量子化の間にｍビットの値に切り捨てられてよく、ここで、ｎはｍよりも大きい。
[0054]幾つかの例では、ビデオエンコーダ２０は、被量子化変換係数を走査して、エントロピー符号化され得る被直列化ベクトルを生成するために、予め定義された走査順序を使用することができる。他の例では、ビデオエンコーダ２０は、適応走査を実行することができる。被量子化変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、例えば、コンテキスト適応型可変長コード化（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応型バイナリ算術コード化（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コード化、又は別のエントロピー符号化方法に従って、１次元ベクトルをエントロピー符号化することができる。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための、被符号化ビデオデータと関連付けられるシンタックス要素をエントロピー符号化することができる。
[0055]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当てることができる。コンテキストは、例えば、シンボルの隣接値が０ではないかどうかに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルの可変長コードを選択することができる。可変長コード化（ＶＬＣ）におけるコードワードは、比較的短いコードが優勢シンボルに対応する一方で、より長いコードが劣勢シンボルに対応するように構成され得る。このように、ＶＬＣの使用は、例えば、送信されるべき各シンボルに対して等長のコードワードを使用するよりもビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づき得る。
[0056]ビデオエンコーダ２０は、被コード化ピクチャ及び関連付けられるデータの表現を形成するビットのシーケンスを含むビットストリームを出力することができる。「ビットストリーム」という用語は、ネットワーク抽象化レイヤ（ＮＡＬ）単位ストリーム（例えば、ＮＡＬ単位のシーケンス）、又はバイトストリーム（例えば、ＨＥＶＣ規格のＡｎｎｅｘ Ｂによって指定されたスタートコードプレフィックスとＮＡＬ単位とを含むＮＡＬ単位ストリームのカプセル化）のいずれかを指すために使用される総称であり得る。ＮＡＬ単位は、ＮＡＬ単位中のデータのタイプの指示と、必要に応じてエミュレーション防止ビットが点在するローバイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）の形態でそのデータを含むバイトとを含む、シンタックス構造である。ＮＡＬ単位の各々は、ＮＡＬ単位ヘッダを含んでよく、ＲＢＳＰをカプセル化することができる。ＮＡＬ単位ヘッダは、ＮＡＬ単位タイプコードを示すシンタックス要素を含み得る。ＮＡＬ単位のＮＡＬ単位ヘッダによって指定されるＮＡＬ単位タイプコードは、ＮＡＬ単位のタイプを示す。ＲＢＳＰは、ＮＡＬ単位内にカプセル化された整数個のバイトを含むシンタックス構造であり得る。幾つかの事例では、ＲＢＳＰは０ビットを含む。
[0057]様々なタイプのＮＡＬ単位は、様々なタイプのＲＢＳＰをカプセル化することができる。例えば、第１のタイプのＮＡＬ単位はＰＰＳのためのＲＢＳＰをカプセル化することができ、第２のタイプのＮＡＬ単位はスライスセグメントのためのＲＢＳＰをカプセル化することができ、第３のタイプのＮＡＬ単位はＳＥＩのためのＲＢＳＰをカプセル化することができ、以下同様である。ビデオコード化データのためのＲＢＳＰをカプセル化するＮＡＬ単位は（パラメータセット及びＳＥＩメッセージのためのＲＢＳＰとは対照的に）、ビデオコード化レイヤ（ＶＣＬ）ＮＡＬ単位と呼ばれ得る。パラメータセット（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳなど）を含むＮＡＬ単位は、パラメータセットＮＡＬ単位と呼ばれ得る。
[0058]本開示は、セグメントスライスのためのＲＢＳＰをカプセル化するＮＡＬ単位を、被コード化スライスＮＡＬ単位と呼び得る。ＨＥＶＣ ＷＤにおいて定められるように、スライスセグメントは、タイル走査において連続的に順序付けられ単一のＮＡＬ単位に含まれる整数個のＣＴＵである。対照的に、ＨＥＶＣ ＷＤでは、スライスは、１つの独立したスライスセグメントと、同じアクセス単位内の（もしあれば）次の独立スライスセグメントに先行する（もしあれば）全ての後続の従属スライスセグメントとに含まれる、整数個のＣＴＵであり得る。独立スライスセグメントは、スライスセグメントヘッダのシンタックス要素の値が先行するスライスセグメントの値から推測されない、スライスセグメントである。従属スライスセグメントは、スライスセグメントヘッダの一部のシンタックス要素の値が復号順序で先行する独立スライスセグメントの値から推測される、スライスセグメントである。被コード化スライスＮＡＬ単位のＲＢＳＰは、スライスセグメントヘッダとスライスデータとを含み得る。スライスセグメントヘッダは、スライスセグメントにおいて表される最初の又は全てのＣＴＵに関するデータ要素を含む、被コード化スライスセグメントの一部である。スライスヘッダは、現在のスライスセグメントである、又は復号順序で現在の従属スライスセグメントに先行する直近の独立スライスセグメントである、独立スライスセグメントのスライスセグメントヘッダである。
[0059]ＶＰＳは、０個以上のコード化されたビデオシーケンス（ＣＶＳ）全体に適用されるシンタックス要素を備えるシンタックス構造である。ＳＰＳは、０個以上のＣＶＳ全体に適用されるシンタックス要素を含むシンタックス構造である。ＳＰＳは、ＳＰＳがアクティブであるときにアクティブであるＶＰＳを特定するシンタックス要素を含み得る。従って、ＶＰＳのシンタックス要素は、ＳＰＳのシンタックス要素よりも一般的に適用可能であり得る。
[0060]パラメータセット（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳなど）は、スライスのスライスヘッダから直接又は間接的に参照される識別情報を含み得る。参照プロセスは「アクティブ化」として知られる。従って、ビデオデコーダ３０が特定のスライスを復号しているとき、その特定のスライスのスライスヘッダ中のシンタックス要素によって直接又は間接的に参照されるパラメータセットは「アクティブ化される」と言われる。パラメータセットタイプに応じて、アクティブ化は、ピクチャごとに、又はシーケンスごとに行われ得る。例えば、スライスのスライスヘッダは、ＰＰＳを特定するシンタックス要素を含み得る。従って、ビデオコーダがスライスをコード化するとき、ＰＰＳはアクティブ化され得る。更に、ＰＰＳは、ＳＰＳを特定するシンタックス要素を含み得る。従って、ＳＰＳを特定するＰＰＳがアクティブ化されるとき、ＳＰＳはアクティブ化され得る。ＳＰＳは、ＶＰＳを特定するシンタックス要素を含み得る。従って、ＶＰＳを特定するＳＰＳがアクティブ化されるとき、ＶＰＳはアクティブ化される。
[0061]ビデオデコーダ３０は、ビデオエンコーダ２０によって生成されたビットストリームを受信することができる。加えて、ビデオデコーダ３０は、ビットストリームを解析して、ビットストリームからシンタックス要素を取得することができる。ビデオデコーダ３０は、ビットストリームから取得されたシンタックス要素に少なくとも部分的に基づいて、ビデオデータのピクチャを再構築することができる。ビデオデータを再構築するためのプロセスは、全般に、ビデオエンコーダ２０によって実行されるプロセスの逆であり得る。例えば、ビデオデコーダ３０は、現在ＣＵのＰＵの予測ブロックを決定するために、ＰＵの動きベクトルを使用することができる。加えて、ビデオデコーダ３０は、現在のＣＵのＴＵの係数ブロックを逆量子化することができる。ビデオデコーダ３０は、現在のＣＵのＴＵの変換ブロックを再構築するために、係数ブロックに対して逆変換を実行することができる。ビデオデコーダ３０は、現在のＣＵのＰＵの予測ブロックのサンプルを現在のＣＵのＴＵの変換ブロックの対応するサンプルに加算することによって、現在のＣＵのコード化ブロックを再構築することができる。ピクチャの各ＣＵのコード化ブロックを再構築することによって、ビデオデコーダ３０はピクチャを再構築することができる。
[0062]ＨＥＶＣ ＷＤでは、ＣＶＳは、瞬時復号リフレッシュ（ＩＤＲ）ピクチャ、又はブロークンリンクアクセス（ＢＬＡ）ピクチャ、又は、ＩＤＲ又はＢＬＡピクチャではない全ての後続のピクチャを含むビットストリーム中の最初のピクチャであるクリーンランダムアクセス（ＣＲＡ）ピクチャから開始し得る。ＩＤＲピクチャはＩスライス（即ち、イントラ予測のみが使用されるスライス）のみを含む。ＩＤＲピクチャは、復号順序でビットストリームにおいて最初のピクチャであり得るか、又はビットストリームにおいて後のほうに現れ得る。各ＩＤＲピクチャは、復号順序においてＣＶＳの最初のピクチャである。ＨＥＶＣ ＷＤでは、ＩＤＲピクチャは、ＩＤＲ＿Ｗ＿ＲＡＤＬ又はＩＤＲ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャであり得る。
[0063]ＩＤＲピクチャは、ランダムアクセスのために使用され得る。しかしながら、復号順序でＩＤＲピクチャに後続するピクチャは、参照としてＩＤＲピクチャより前に復号されるピクチャを使用することができない。従って、ランダムアクセスのためにＩＤＲピクチャに依拠するビットストリームは、追加のタイプのランダムアクセスピクチャを使用するビットストリームよりも著しく低いコード化効率を有し得る。少なくとも幾つかの例では、ＩＤＲアクセス単位は、ＩＤＲピクチャを含むアクセス単位である。
[0064]復号順序でＣＲＡピクチャに後続するが出力順序でＣＲＡピクチャに先行するピクチャが、参照のためにＣＲＡピクチャの前に復号されるピクチャを使用することを可能にするために、ＣＲＡピクチャの概念がＨＥＶＣに導入された。復号順序でＣＲＡピクチャに後続するが出力順序でＣＲＡピクチャに先行するピクチャは、ＣＲＡピクチャと関連付けられる先頭ピクチャ（又はＣＲＡピクチャの先頭ピクチャ）と呼ばれる。即ち、コード化効率を改善するために、復号順序でＣＲＡピクチャに後続するが出力順序でＣＲＡピクチャに先行するピクチャが、参照のためにＣＲＡピクチャの前に復号されるピクチャを使用することを可能にするように、ＣＲＡピクチャの概念がＨＥＶＣに導入された。ＣＲＡアクセス単位は、被コード化ピクチャがＣＲＡピクチャであるアクセス単位である。ＨＥＶＣ ＷＤでは、ＣＲＡピクチャは、ＣＲＡ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する、イントラランダムアクセスピクチャであり得る。
[0065]ＣＲＡピクチャの先頭ピクチャは、復号順序でそのＣＲＡピクチャの前に存在するＩＤＲピクチャ又はＣＲＡピクチャから復号が開始する場合、正しく復号可能である。しかしながら、ＣＲＡピクチャの先頭ピクチャは、そのＣＲＡピクチャからのランダムアクセスが行われるとき、復号不可能であり得る。従って、ビデオデコーダは通常、ランダムアクセス復号の間にＣＲＡピクチャの先頭ピクチャを復号する。復号が始まる場所によっては利用可能でないことがある参照ピクチャからの誤りの伝搬を防止するために、復号順序と出力順序の両方でＣＲＡピクチャに後続するピクチャは、復号順序又は出力順序のいずれかでＣＲＡピクチャに先行するいずれのピクチャ（先頭ピクチャを含む）も参照のために使用することができない。
[0066]ＢＬＡピクチャの概念は、ＣＲＡピクチャの導入の後にＨＥＶＣに導入され、ＣＲＡピクチャの概念に基づく。ＢＬＡピクチャは通常、ＣＲＡピクチャの位置におけるビットストリームのスプライシングから生じ、スプライシングされたビットストリームにおいて、スプライシングポイントのＣＲＡピクチャはＢＬＡピクチャに変更される。従って、ＢＬＡピクチャは元のビットストリームにおけるＣＲＡピクチャであってよく、ＣＲＡピクチャは、ＣＲＡピクチャの位置におけるビットストリームのスプライシングの後でビットストリームスプライサによってＢＬＡピクチャとなるように変更される。幾つかの例では、ＲＡＰピクチャを含むアクセス単位は、本明細書ではＲＡＰアクセス単位と呼ばれ得る。ＢＬＡアクセス単位は、ＢＬＡピクチャを含むアクセス単位である。ＨＥＶＣ ＷＤでは、ＢＬＡピクチャは、ＢＬＡ＿Ｗ＿ＬＰ、ＢＬＡ＿Ｗ＿ＲＡＤＬ、又はＢＬＡ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する、イントラランダムアクセスピクチャであり得る。
[0067]一般に、ＩＲＡＰピクチャは、Ｉスライスのみを含み、ＢＬＡピクチャ、ＣＲＡピクチャ又はＩＤＲピクチャであり得る。例えば、ＨＥＶＣ ＷＤは、ＩＲＡＰピクチャが、両端値を含めてＢＬＡ＿Ｗ＿ＬＰからＲＳＶ＿ＩＲＡＰ＿ＶＣＬ２３の範囲のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する被コード化ピクチャであり得ることを、示す。更に、ＨＥＶＣ ＷＤは、復号順序でのビットストリームにおける最初のピクチャがＩＲＡＰピクチャでなければならないことを示す。ＨＥＶＣ ＷＤの表７−１は、ＮＡＬ単位タイプコードとＮＡＬ単位タイプクラスとを示す。ＨＥＶＣ ＷＤの表７−１が以下で転載される。
Figure 0006542378
Figure 0006542378
Figure 0006542378
[0068]ＢＬＡピクチャとＣＲＡピクチャとの１つの違いは以下の通りである。ＣＲＡピクチャの場合、関連付けられた先頭ピクチャは、復号順序でそのＣＲＡピクチャの前にあるＲＡＰピクチャから復号が開始する場合、正しく復号可能である。しかしながら、ＣＲＡピクチャと関連付けられた先頭ピクチャは、そのＣＲＡピクチャからのランダムアクセスが行われるとき（即ち、復号がＣＲＡピクチャから開始するとき、又は言い換えると、ＣＲＡピクチャがビットストリーム中の最初のピクチャであるとき）、正しく復号可能ではないことがある。対照的に、復号順序でＢＬＡピクチャの前にあるＲＡＰピクチャから復号が開始するときでも、ＢＬＡピクチャと関連付けられる先頭ピクチャが復号可能であるシナリオは存在し得ない。
[0069]特定のＣＲＡピクチャ又は特定のＢＬＡピクチャと関連付けられる先頭ピクチャの幾つかは、その特定のＣＲＡピクチャ又は特定のＢＬＡピクチャがビットストリーム中の最初のピクチャであるときでも、正しく復号可能であり得る。これらの先頭ピクチャは復号可能先頭ピクチャ（ＤＬＰ：decodable leading picture）又はランダムアクセス復号可能先頭（ＲＡＤＬ：random access decodable leading）ピクチャと呼ばれ得る。ＨＥＶＣ ＷＤでは、ＲＡＤＬピクチャは、ＲＡＤＬ＿Ｒ又はＲＡＤＬ＿Ｎに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する、被コード化ピクチャであり得る。更に、ＨＥＶＣ ＷＤは、全てのＲＡＤＬピクチャが先頭ピクチャであることと、ＲＡＤＬピクチャが同じ関連付けられるＩＲＡＰピクチャの末尾ピクチャの復号プロセスのための参照ピクチャとして使用されないこととを、示す。全てのＲＡＤＬピクチャは、存在すれば、復号順序において、同じ関連付けられるＩＲＡＰピクチャの全ての末尾ピクチャに先行する。ＲＡＤＬアクセス単位が、被コード化ピクチャがＲＡＤＬピクチャであるアクセス単位であり得ることを、ＨＥＶＣ ＷＤは示す。末尾ピクチャは、出力順序において関連付けられるＩＲＡＰピクチャ（即ち、復号順序において前のＩＲＡＰピクチャ）の後に続くピクチャであり得る。
[0070]他の先頭ピクチャは復号不可能先頭ピクチャ（ＮＬＰ：non-decodable leading picture）又はランダムアクセススキップ先頭（ＲＡＳＬ：random access skipped leading）ピクチャと呼ばれ得る。ＨＥＶＣ ＷＤでは、ＲＡＳＬピクチャは、ＲＡＳＬ＿Ｒ又はＲＡＳＬ＿Ｎに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを各ＶＣＬ ＮＡＬ単位が有する、被コード化ピクチャであり得る。全てのＲＡＳＬピクチャは、関連付けられるＢＬＡピクチャ又はＣＲＡピクチャの先頭ピクチャである。
[0071]必要なパラメータセットが、アクティブ化されることが必要なときに利用可能であるという条件で、ＩＲＡＰピクチャ及び復号順序での全ての後続の非ＲＡＳＬピクチャは、復号順序においてＩＲＡＰピクチャに先行するいかなるピクチャの復号プロセスも実行することなく、正確に復号され得る。ＩＲＡＰピクチャではないＩスライスのみを含むピクチャがビットストリーム中にあり得る。
[0072]マルチビューコード化では、異なる視点からの同じシーンの複数のビューが存在し得る。「アクセス単位」という用語は、同じ時間インスタンスに対応するピクチャのセットを指すために使用され得る。従って、ビデオデータは、時間とともに生じる一連のアクセス単位として概念化され得る。「ビュー成分」は、単一のアクセス単位中のビューのコード化された表現であり得る。本開示では、「ビュー」は、同じビュー識別子と関連付けられたビュー成分のシーケンス又はセットを指し得る。ビュー成分は、テクスチャビュー成分と深度ビュー成分とを含み得る。本開示では、「ビュー」は、同じビュー識別子と関連付けられる１つ又は複数のビュー成分のセット又はシーケンスを指し得る。
[0073]テクスチャビュー成分（即ち、テクスチャピクチャ）は、単一のアクセス単位中のビューのテクスチャのコード化された表現であり得る。テクスチャビューは、ビュー順序インデックスの同一の値と関連付けられるテクスチャビュー成分のシーケンスであり得る。ビューのビュー順序インデックスは、他のビューに対するビューのカメラ位置を示し得る。深度ビュー成分（即ち、深度ピクチャ）は、単一のアクセス単位中のビューの深度のコード化された表現であり得る。深度ビューは、ビュー順序インデックスの同一の値と関連付けられる１つ又は複数の深度ビュー成分のセット又はシーケンスであり得る。
[0074]ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ及びＳＨＶＣでは、ビデオエンコーダは、一連のＮＡＬ単位を備えるビットストリームを生成し得る。ビットストリームの異なるＮＡＬ単位が、ビットストリームの異なるレイヤと関連付けられ得る。レイヤは、同じレイヤ識別子を有するＶＣＬ ＮＡＬ単位及び関連付けられる非ＶＣＬ ＮＡＬ単位のセットとして定義され得る。レイヤは、マルチビュービデオコード化におけるビューと等価であり得る。マルチビュービデオコード化では、レイヤは、異なる時間インスタンスを伴う同じレイヤの全てのビュー成分を含み得る。各ビュー成分は、特定の時間インスタンスにおける特定のビューに属するビデオシーンの被コード化ピクチャであり得る。３Ｄビデオコード化の幾つかの例では、レイヤは、特定のビューの全ての被コード化深度ピクチャ、又は特定のビューの被コード化テクスチャピクチャのいずれかを含み得る。３Ｄビデオコード化の他の例では、レイヤは、特定のビューのテクスチャビュー成分と深度ビュー成分の両方を含み得る。同様に、スケーラブルビデオコード化の状況において、レイヤは通常、他のレイヤの中の被コード化ピクチャと異なるビデオ特性を有する被コード化ピクチャに対応する。そのようなビデオ特性は通常、空間解像度と品質レベル（例えば、信号対雑音比）とを含む。ＨＥＶＣ及びその拡張では、時間スケーラビリティは、特定の時間レベルを伴うピクチャのグループをサブレイヤとして定義することによって、１つのレイヤ内で達成され得る。
[0075]ビットストリームの各々のそれぞれのレイヤについて、より低いレイヤの中のデータは、任意のより高いレイヤの中のデータを参照せずに復号され得る。スケーラブルビデオコード化では、例えば、ベースレイヤの中のデータは、拡張レイヤの中のデータを参照せずに復号され得る。一般に、ＮＡＬ単位は、単一のレイヤのデータをカプセル化するだけであり得る。従って、ビットストリームの残りの最高次のレイヤのデータをカプセル化するＮＡＬ単位は、ビットストリームの残りのレイヤの中のデータの復号可能性に影響を及ぼすことなく、ビットストリームから除去され得る。マルチビューコード化及び３Ｄ−ＨＥＶＣでは、より高いレイヤは、更なるビュー成分を含み得る。ＳＨＶＣでは、より高次のレイヤは、信号対雑音比（ＳＮＲ）強化データ、空間的拡張トデータ、及び／又は時間的拡張トデータを含み得る。ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ及びＳＨＶＣでは、ビデオデコーダが、あるレイヤの中のピクチャをいかなる他のレイヤのデータも参照せずに復号できる場合、そのレイヤは「ベースレイヤ」と呼ばれ得る。ベースレイヤは、ＨＥＶＣベースの規格（例えば、ＨＥＶＣ ＷＤ）に準拠し得る。
[0076]ＳＶＣでは、ベースレイヤ以外のレイヤは、「拡張レイヤ（enhancement layer）」と呼ばれることがあり、ビットストリームから復号されるビデオデータの視覚的品質を向上させる情報を提供し得る。ＳＶＣは、空間分解能、信号対雑音比（即ち、品質）又は時間レートを向上させることができる。スケーラブルビデオコード化（例えば、ＳＨＶＣ）では、「レイヤ表現」は、単一のアクセス単位中の空間レイヤのコード化された表現であり得る。説明を簡単にするために、本開示は、ビュー成分及び／又はレイヤ表現を「ビュー成分／レイヤ表現」又は単に「ピクチャ」と呼び得る。
[0077]ＨＥＶＣにおけるレイヤを実装するために、ＮＡＬ単位のヘッダは、ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を含み、このシンタックス要素は以前、最終的なＨＥＶＣ規格に先行していた様々なワーキングドラフトにおいて、ｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓシンタックス要素と呼ばれていた。基本のＨＥＶＣ規格では、ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は０という値に限定される。しかしながら、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣ及びＳＶＣでは、ｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素はレイヤの識別子を指定するために０より大きいことがある。異なる値を指定するｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を有するビットストリームのＮＡＬ単位は、ビットストリームの異なるレイヤに属する。
[0078]幾つかの例では、ＮＡＬ単位がマルチビューコード化（例えば、ＭＶ−ＨＥＶＣ）、３ＤＶコード化（例えば、３Ｄ−ＨＥＶＣ）又はスケーラブルビデオコード化（例えば、ＳＨＶＣ）におけるベースレイヤに関係する場合、ＮＡＬ単位のｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は０に等しい。ビットストリームのベースレイヤの中のデータは、ビットストリームのいずれの他のレイヤの中のデータも参照せずに復号され得る。ＮＡＬ単位が、マルチビューコード化、３ＤＶ又はスケーラブルビデオコード化におけるベースレイヤに関係しない場合、ＮＡＬ単位のｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素は０ではない値を有し得る。
[0079]更に、レイヤ内の幾つかのビュー成分／レイヤ表現は、同じレイヤ内の他のビュー成分／レイヤ表現を参照せずに復号され得る。従って、レイヤの幾つかのビュー成分／レイヤ表現のデータをカプセル化したＮＡＬ単位は、そのレイヤ中の他のビュー成分／レイヤ表現の復号可能性に影響を及ぼすことなくビットストリームから除去され得る。そのようなビュー成分／レイヤ表現のデータをカプセル化したＮＡＬ単位を除去すると、ビットストリームのフレームレートが下がり得る。レイヤ内の他のビュー成分／レイヤ表現を参照せずに復号され得るレイヤ内のビュー成分／レイヤ表現のサブセットは、本明細書では「サブレイヤ」又は「時間サブレイヤ」と呼ばれ得る。
[0080]ＮＡＬ単位は、ＮＡＬ単位の時間識別子（即ち、ＴｅｍｐｏｒａｌＩｄ）を指定するｔｅｍｐｏｒａｌ＿ｉｄシンタックス要素を含み得る。ＮＡＬ単位の時間識別子は、そのＮＡＬ単位が属するサブレイヤを特定する。従って、ビットストリームの各サブレイヤは、異なる時間識別子を有し得る。一般に、レイヤの第１のＮＡＬ単位の時間識別子が同じレイヤの第２のＮＡＬ単位の時間識別子よりも小さい場合、第１のＮＡＬ単位によってカプセル化されたデータは、第２のＮＡＬ単位によってカプセル化されたデータを参照せずに復号され得る。
[0081]ビットストリームは、複数の動作点と関連付けられ得る。ビットストリームの各動作点は、レイヤ識別子のセット（例えば、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値のセット）及び時間識別子と関連付けられる。レイヤ識別子のセットはＯｐＬａｙｅｒＩｄＳｅｔと表記されることがあり、時間識別子はＴｅｍｐｏｒａｌＩＤと表記されることがある。ＮＡＬ単位のレイヤ識別子が動作点のレイヤ識別子のセットの中にあり、ＮＡＬ単位の時間識別子が動作点の時間識別子以下である場合、ＮＡＬ単位は動作点と関連付けられる。従って、動作点は、ビットストリーム中のＮＡＬ単位のサブセットに対応し得る。ＨＥＶＣは、別のビットストリームと、目標の最高のＴｅｍｐｏｒａｌＩｄと、ターゲットレイヤ識別子リストとを入力として用いるサブビットストリーム抽出プロセスの動作によって、別のビットストリームから作成されるビットストリームを、動作点として定義する。
[0082]上で紹介されたように、本開示は、ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ）に基づくファイルにビデオコンテンツを記憶することに関する。具体的には、本開示は、複数のコード化されたレイヤを含むビデオストリームを記憶するための様々な技法を説明し、各レイヤは、スケーラブルレイヤ、テクスチャビュー、深度ビュー、又は他のタイプのレイヤ若しくはビューであり得る。本開示の技法は、例えば、ＭＶ−ＨＥＶＣビデオデータ、ＳＨＶＣビデオデータ、３Ｄ−ＨＥＶＣビデオデータ、及び／又は他のタイプのビデオデータの記憶に適用され得る。
[0083]ファイルフォーマット及びファイルフォーマット規格が、ここで簡単に論じられる。ファイルフォーマット規格は、ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ、ＩＳＯ／ＩＥＣ １４４９６−１２、以後「ＩＳＯ／ＩＥＣ １４９９６−１２」）と、ＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１４）、３ＧＰＰ（登録商標）ファイルフォーマット（３ＧＰＰ ＴＳ２６．２４４）及びＡＶＣファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５、以後「ＩＳＯ／ＩＥＣ １４９９６−１５」）を含む、ＩＳＯＢＭＦＦから派生した他のファイルフォーマット規格とを含む。従って、ＩＳＯ／ＩＥＣ １４９９６−１２は、ＩＳＯベースのメディアファイルフォーマットを規定する。他の文書は、特定の用途のためにＩＳＯベースのメディアファイルフォーマットを拡張する。例えば、ＩＳＯ／ＩＥＣ １４９９６−１５は、ＩＳＯベースのメディアファイルフォーマットにおける、ＮＡＬ単位構造のビデオの搬送を記述する。Ｈ．２６４／ＡＶＣ及びＨＥＶＣ、更にはそれらの拡張は、ＮＡＬ単位構造のビデオの例である。ＩＳＯ／ＩＥＣ １４９９６−１５は、Ｈ．２６４／ＡＶＣ ＮＡＬ単位の搬送を記述するセクションを含む。加えて、ＩＳＯ／ＩＥＣ １４９９６−１５のセクション８は、ＨＥＶＣ ＮＡＬ単位の搬送を記述する。
[0084]ＩＳＯＢＭＦＦは、ＡＶＣファイルフォーマットのような多くのコーデックカプセル化フォーマットのための、更には、ＭＰＥＧ−４ファイルフォーマット、３ＧＰＰファイルフォーマット（３ＧＰ）、及びＤＶＢファイルフォーマットのような多くのマルチメディアコンテナフォーマットのための、基礎として使用され得る。オーディオ及びビデオのような連続的なメディアに加えて、画像、更にはメタデータのような静的なメディアが、ＩＳＯＢＭＦＦに準拠したファイルに記憶され得る。ＩＳＯＢＭＦＦに従って構成されたファイルは、ローカルメディアファイルの再生、リモートファイルの漸進的なダウンロード、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）のためのセグメント、ストリーミングされるべきコンテンツのためのコンテナ及びそのパケット化命令並びに受信されたリアルタイムメディアストリームの記録を含む、多くの目的のために使用され得る。従って、元々は記憶のために設計されたが、ＩＳＯＢＭＦＦは、ストリーミング、例えばプログレッシブダウンロード又はＤＡＳＨのために有用であることがわかっている。ストリーミングの目的で、ＩＳＯＢＭＦＦで定義されたムービーフラグメントが使用され得る。
[0085]ＨＥＶＣファイルフォーマットに準拠するファイルは、ボックスと呼ばれる一連のオブジェクトを備え得る。「ボックス」は、固有のタイプ識別子及び長さによって定義されるオブジェクト指向の構築ブロックであり得る。例えば、ボックスは、４文字のコード化されたボックスタイプと、ボックスのバイトカウントと、ペイロードとを含む、ＩＳＯＢＭＦＦにおける基本的なシンタックス構造であり得る。言い換えると、ボックスは、コード化されたボックスタイプと、ボックスのバイトカウントと、ペイロードとを備える、シンタックス構造であり得る。幾つかの事例では、ＨＥＶＣファイルフォーマットに準拠するファイル中の全てのデータがボックスに含まれることがあり、ボックス中にないファイルの中にはデータがないことがある。従って、ＩＳＯＢＭＦＦファイルは、ボックスのシーケンスからなっていてよく、ボックスは他のボックスを含んでよい。例えば、ボックスのペイロードは、１つ又は複数の追加のボックスを含み得る。本開示の他の箇所で詳細に説明される図５Ａ、図５Ｂ及び図６は、本開示の１つ又は複数の技法による、ファイル内の例示的なボックスを示す。
[0086]ＩＳＯＢＭＦＦに準拠するファイルは、様々なタイプのボックスを含み得る。例えば、ＩＳＯＢＭＦＦに準拠するファイルは、ファイルタイプボックス、メディアデータボックス、ムービーボックス、ムービーフラグメントボックスなどを含み得る。この例では、ファイルタイプボックスは、ファイルタイプと互換性情報とを含む。メディアデータボックスは、サンプル（例えば、被コード化ピクチャ）を含み得る。ムービーボックス（「ｍｏｏｖ」）は、ファイル中に存在する連続的なメディアストリームのメタデータを含む。連続的なメディアストリームの各々は、トラックとしてファイルにおいて表され得る。例えば、ムービーボックスは、ムービーに関するメタデータ（例えば、サンプル間の論理関係及びタイミング関係、並びにまた、サンプルの位置へのポインタ）を含み得る。ムービーボックスは、幾つかのタイプのサブボックスを含み得る。ムービーボックス中のサブボックスは、１つ又は複数のトラックボックスを含み得る。トラックボックスは、ムービーの個々のトラックについての情報を含み得る。トラックボックスは、単一のトラックの全体的な情報を指定するトラックヘッダボックスを含み得る。加えて、トラックボックスは、メディア情報ボックスを含むメディアボックスを含み得る。メディア情報ボックスは、トラック中のメディアサンプルのデータインデックスを含むサンプルテーブルボックスを含み得る。サンプルテーブルボックス中の情報は、時間的にサンプルの位置を特定するために使用されてよく、トラックのサンプルの各々について、サンプルのタイプ、サイズ、コンテナ、及びそのコンテナ中のオフセットを特定するために使用されてよい。従って、トラックに対するメタデータは、トラックボックス（「ｔｒａｋ」）に封入されるが、トラックのメディアコンテンツは、メディアデータボックス（「ｍｄａｔ」）に封入されるか、又は別のファイルに直接封入されるかのいずれかである。トラックに対するメディアコンテンツは、オーディオ又はビデオアクセス単位のようなサンプルのシーケンスを備える（例えば、それらからなる）。
[0087]ＩＳＯＢＭＦＦは、次のタイプのトラック、即ち、エレメンタリメディアストリームを含むメディアトラックと、メディア送信命令を含むか受信されたパケットストリームを表すかのいずれかであるヒントトラックと、時間同期されたメタデータを備えるタイムドメタデータトラックとを規定する。各トラックに対するメタデータは、サンプル記述エントリーのリストを含み、サンプル記述エントリーの各々が、トラック中で使用されるコード化フォーマット又はカプセル化フォーマットと、そのフォーマットを処理するために必要な初期化データとを提供する。各サンプルは、トラックのサンプル記述エントリーの１つと関連付けられる。
[0088]ＩＳＯＢＭＦＦは、様々な機構によってサンプル固有のメタデータを規定することを可能にする。Ｓａｍｐｌｅ Ｔａｂｌｅボックス（「ｓｔｂｌ」）内の特定のボックスが、一般的な需要に応えるために標準化されている。例えば、Ｓｙｎｃ Ｓａｍｐｌｅボックス（「ｓｔｓｓ」）は、サンプルテーブルボックス内のボックスである。Ｓｙｎｃ Ｓａｍｐｌｅボックスは、トラックのランダムアクセスサンプルを列挙するために使用される。本開示は、Ｓｙｎｃ Ｓａｍｐｌｅボックスにより列挙されるサンプルを、シンクサンプルと呼び得る。別の例では、サンプルグループ化機構は、ファイル中のサンプルグループ記述エントリーとして指定される同じ特性を共有するサンプルのグループへの、４文字のグループ化タイプに従ったサンプルのマッピングを可能にする。幾つかのグループ化タイプが、ＩＳＯＢＭＦＦにおいて規定されている。
[0089]サンプルテーブルボックスは、１つ又は複数のＳａｍｐｌｅＴｏＧｒｏｕｐボックスと、１つ又は複数のサンプルグループ記述ボックス（即ち、ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス）とを含み得る。ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、サンプルが属するサンプルグループを、そのサンプルグループの関連付けられた記述とともに決定するために使用され得る。言い換えると、ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、サンプルが属するグループを示し得る。ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、「ｓｂｇｐ」というボックスタイプを有し得る。ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、グループ化タイプ要素（例えば、ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ）を含み得る。グループ化タイプ要素は、サンプルグループ化のタイプ（即ち、サンプルグループを形成するために使用される基準）を特定する整数であり得る。更に、ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、１つ又は複数のエントリーを含み得る。ＳａｍｐｌｅＴｏＧｒｏｕｐボックス中の各エントリーは、トラック中の異なる重複しない一連の連続するサンプルと関連付けられ得る。各エントリーは、サンプルカウント要素（例えば、ｓａｍｐｌｅ＿ｃｏｕｎｔ）と、グループ記述インデックス要素（例えば、ｇｒｏｕｐ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｉｎｄｅｘ）とを示し得る。エントリーのサンプルカウント要素は、エントリーと関連付けられる幾つかのサンプルを示し得る。言い換えると、エントリーのサンプルカウント要素は、同じサンプルグループ記述子をもつ連続するサンプルの数を与える整数であり得る。グループ記述インデックス要素は、エントリーと関連付けられたサンプルの記述を含むＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスを特定することができる。複数のエントリーのグループ記述インデックス要素は、同じＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスを特定することができる。
[0090]現在のファイルフォーマット設計には、１つ又は複数の問題があり得る。ＩＳＯＢＭＦＦに基づく特定のビデオコーデックのビデオコンテンツを記憶するために、そのビデオコーデックに対するファイルフォーマット規格が必要となり得る。ＭＶ−ＨＥＶＣ及びＳＨＶＣのような複数のレイヤを含むビデオストリームの記憶のために、ＳＶＣ及びＭＶＣファイルフォーマットから概念の一部を再使用することが可能である。しかしながら、多くの部分は、ＳＨＶＣ及びＭＶ−ＨＥＶＣビデオストリームに対して直接使用され得ない。ＨＥＶＣファイルフォーマットの直接の適用には、少なくとも次の欠点がある。ＳＨＶＣ及びＭＶ−ＨＥＶＣビットストリームは、ベースレイヤ中のＩＲＡＰピクチャを含むアクセス単位で開始し得るが、他のレイヤ中の他の非ＩＲＡＰピクチャも含むことがあり、又はこの逆であることがある。シンクサンプルは現在、ランダムアクセスのためにそのような点を指し示すことを許容しない。
[0091]本開示は、複数のレイヤを含むビデオストリームの効率的で柔軟な記憶を可能にするために、上記の問題に対する可能性のある解決法を説明し、更に、他の可能性のある改善を提供する。本開示で説明される技法は潜在的に、任意のビデオコーデックによってコード化されたそのようなビデオコンテンツの記憶のために任意のフォーマットに適用されるが、この説明は、ＩＳＯ／ＩＥＣ １４４９６−１５の第８項において規定されるＨＥＶＣファイルフォーマットに基づくＳＨＶＣ及びＭＶ−ＨＥＶＣビデオストリームの記憶に特有である。
[0092]以下で、本開示の幾つかの技法の例示的な実装形態が説明される。以下で説明される例示的な実装形態は、ＭＰＥＧ ｏｕｔｐｕｔ ｄｏｃｕｍｅｎｔ Ｗ１３４７８における１４４９６−１５の最新の統合された規格に基づく。以下では、Ａｎｎｅｘ Ａに対する変更（下線により示される）及び追加されたセクション（ＳＨＶＣについてはセクション９及びＭＶ−ＨＥＶＣについてはセクション１０）が含まれる。言い換えると、本開示の特定の例は、ＩＳＯ／ＩＥＣ １４４９６−１５のＡｎｎｅｘ Ａを修正することができ、ＩＳＯ／ＩＥＣ １４４９６−１５にセクション９及び／又は１０を追加することができる。下線及び二重下線により示される文章は、本開示の実施例に特に関連があり得る。本明細書で説明される例では、ＳＨＶＣという用語が様々な箇所で使用されるが、本開示の設計は実際には、ＳＨＶＣコーデックをサポートするためだけのものではなく、代わりに、別段明示的に言及されない限り、ＭＶ−ＨＥＶＣ、３Ｄ−ＨＥＶＣを含む全てのマルチレイヤコーデックがサポートされ得る。
[0093]ＩＳＯＢＭＦＦ仕様は、ＤＡＳＨとともに使用するための６つのタイプのストリームアクセスポイント（ＳＡＰ）を規定する。最初の２つのＳＡＰタイプ（タイプ１及び２）は、Ｈ．２６４／ＡＶＣ及びＨＥＶＣにおけるＩＤＲピクチャに対応する。第３のＳＡＰタイプ（タイプ３）は、オープンＧＯＰランダムアクセスポイント、従ってＨＥＶＣにおけるＢＬＡピクチャ又はＣＲＡピクチャに対応する。第４のＳＡＰタイプ（タイプ４）は、ＧＤＲランダムアクセスポイントに対応する。
[0094]現在のＬ−ＨＥＶＣファイルフォーマットでは、幾つかの高レベルの情報（例えば、ビットストリーム中のレイヤの情報、ビットレート、フレームレート、時間サブレイヤ、パラレリズム、動作点など）は、ＬＨＥＶＣＳａｍｐｌｅＥｎｔｒｙ、ＨＥＶＣＬＨＶＣＳａｍｐｌｅＥｎｔｒｙ、ＬＨＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ、トラックコンテンツ情報（「ｔｃｏｎ」）及びＯｐｅｒａｔｉｏｎＰｏｉｎｔｓＩｎｆｏｒｍａｔｉｏｎＢｏｘ（「ｏｉｎｆ」）で信号伝達される。一例では、前述のボックスのシンタックス設計は次の通りである。
[0095]上のボックスの現在の構造、及びそこに含まれる情報に基づいて、ファイル中のコンテンツを生成するために、プレーヤは、どの動作点が含まれているかを知るためにまず（ファイルの中に１つだけの）「ｏｉｎｆ」ボックスを見つけ、次いで再生されるべき動作点の１つを選ぶように構成され得る。ビデオプレーヤは次いで、選ばれた動作点のレイヤをどのトラックが含んでいるかを知るために、（Ｌ−ＨＥＶＣビデオを含む各トラックに１つの）「ｔｃｏｎ」ボックスをチェックスし得る。
//LHVC and HEVCLHVC sample entry
class LHEVCConfigurationBox extends Box(‘lhvC’) {
LHEVCDecoderConfigurationRecord() LHEVCConfig;
}
class HEVCLHVCSampleEntry() extends HEVCSampleEntry() {
LHEVCConfigurationBox lhvcconfig;
MPEG4BitRateBox (); // optional
MPEG4ExtensionDescriptorsBox (); // optional
extra_boxes boxes; // optional
}
// Use this if track is not HEVC compatible
class LHEVCSampleEntry() extends VisualSampleEntry (‘lhv1’, or 'lhe1') {
LHVCConfigurationBox lhvcconfig;

MPEG4BitRateBox (); // optional
MPEG4ExtensionDescriptorsBox (); // optional
Box extra_boxes[];
}

aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
bit(1) complete_representation;
bit(3) reserved = ‘111’b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2) parallelismType;
bit(6) reserved = ‘111111’b;
unsigned int(2) chromaFormat;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthChromaMinus8;
bit(16) avgFrameRate;
bit(2) constantFrameRate;
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
unsigned int(16) operationPointIdx;
}

class TrackContentsInfoBox extends FullBox(‘tcon’, version = 0, 0)){
unsigned int (2) reserved
unsigned int (6) num_layers_in_track
for (i=0; i<num_layers_in_track; i++){
unsigned int (4) reserved
unsigned int (6) layer_id
unsigned int (3) min_sub_layer_id
unsigned int (3) max_sub_layer_id
}
}

class OperationPointsInformation extends FullBox(‘oinf’, version = 0, 0){
unsigned int(16) scalability_mask
unsigned int(2) reserved
unsigned int(6) num_profile_tier_level
for (i=1; i<=num_profile_tier_level; i++) {
unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
}
unsigned int(16) num_operation_points
for (i=0; i<num_operation_points) {
unsigned int(16) operation_point_id
unsigned int(8) max_temporal_id;
unsigned int(8) layer_count
for (i=0; i<layer_count; i++) {
unsigned int(8) ptl_idx
unsigned int(6) layer_id;
unsigned int(1) is_outputlayer;
unsigned int(1) is_alternate_outputlayer;
}
}
unsigned int(8) max_layer_count
for (i=0; i<max_layer_count; i++) {
unsigned int(8) dependent_layerID
unsigned int(8) num_layers_dependent_on
for (j=0; j< num_layers_dependent_on; j++) {
unsigned int(8) dependent_on_layerID
}
for (j = 0; j < 16; j++) {
if (scalability mask & (1 << j))
unsigned int(8) dimension_identifier
}
}
}
[0096]上のボックスの現在の構造、及びそこに含まれる情報に基づいて、ファイル中のコンテンツを生成するために、プレーヤは、どの動作点が含まれているかを知るためにまず（ファイルの中に１つだけの）「ｏｉｎｆ」ボックスを見つけ、次いで再生されるべき動作点の１つを選ぶように構成され得る。ビデオプレーヤは次いで、選ばれた動作点のレイヤをどのトラックが含んでいるかを知るために、（Ｌ−ＨＥＶＣビデオを含む各トラックに１つの）「ｔｃｏｎ」ボックスをチェックスし得る。
[0097]現在の設計の上記の基本的な使用法に留意した上で、本開示は、表現フォーマット（空間分解能と、ビット深度と、色フォーマットとを含む）、ビットレート及びフレームレートなどのより多くの情報が、動作点の選択を可能にするために「ｏｉｎｆ」ボックスに含められることを提案する。各トラック中のサンプルエントリーは、そのような情報の１つのセットを含むが、それは特定の動作点に対するものだけである。複数の動作点が１つのトラックに含まれるとき、他の動作点の情報は欠けている。
[0098]別の問題は、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの中のフィールドの多くのセマンティクスが明確ではなく、それらのうちの一部は混乱を招くようなものであるという事実である。例えば、プロファイル、ティア及びレベル（ＰＴＬ）、ｃｈｒｏｍａＦｏｒｍａｔ、ｂｉｔＤｅｐｔｈＬｕｍａＭｉｎｕｓ８並びにｂｉｔＤｅｐｔｈＣｈｒｏｍａＭｉｎｕｓ８はレイヤ固有の特性であるが、現在は、ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘによって示される動作点に適用されるものと言われている。動作点が２つ以上のレイヤを含むとき、セマンティクスはまったく明確ではない。
[0099]実際に、従来の設計の基本的な使用法のステップに基づくと、動作点の選択のための情報が「ｏｉｎｆ」ボックスの中に十分にないときには特に、サンプルエントリー中の情報の一部がまったく使いものにならない。
[0100]別の問題は、ＳＨＶＣ及びＭＶ−ＨＥＶＣでは、ＰＴＬが各々の必要なレイヤ（即ち、出力レイヤ又は動作点内で出力レイヤによって直接若しくは間接的に参照されるレイヤのいずれか、又は両方であるレイヤ）のためだけに信号伝達され、いずれの不要なレイヤ（必要なレイヤではないレイヤ）のためにも信号伝達されないということである。従って、ファイルフォーマットの設計において、不要なレイヤのためにＰＴＬを信号伝達することは不要であり得る。
[0101]本開示で説明される方法及び技法の概要が、以下で列挙される。例示的な詳細な実装形態は後のセクションで与えられる。本開示の方法及び技法は、独立に適用されることがあり、又は組み合わせて適用されることがある。
[0102]本開示の第１の技法は、ＬＨＥＶＣサンプルエントリー及びＨＥＶＣＬＨＶＣサンプルエントリー内でのＬＨＥＶＣＣｏｎｆｉｇｕｒａｔｉｏｎＢｏｘの後のＭＰＥＧ４ＢｉｔＲａｔｅＢｏｘ（）の信号伝達を除去することを含む。代わりに、「ｏｉｎｆ」ボックスでの、各動作点のためのビットレート情報の信号伝達を可能にする。
[0103]本開示の第２の技法は、「ｏｉｎｆ」ボックスの中で、各動作点のための表現フォーマット（空間分解能と、ビット深度と、色フォーマットとを含む）についての情報を信号伝達することを含む。
[0104]本開示の第３の技法は、「ｏｉｎｆ」ボックスにおいてすでに提供されているか、又は「ｏｉｎｆ」ボックスに追加されることが提案されるかのいずれかである、ＰＴＬ情報と、表現フォーマット情報と、フレームレート情報とを、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄから除去することを含む。ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの中の残りの情報は、トラックに含まれる全てのレイヤに適用される。第３の技法の別の例では、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの設計は、表現フォーマット情報及びフレームレート情報、並びに場合によっては追加のパラメータ／情報（例えば、パラレリズム情報）が各レイヤのために信号伝達されるように、再構築される。ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの中のシンタックス要素ｕｎｓｉｇｎｅｄ ｉｎｔ（２） ｐａｒａｌｌｅｌｉｓｍＴｙｐｅは、レイヤ中のピクチャを復号するためにどのタイプの並列復号機能が使用され得るかを示し得る。タイル、波面及びスライスが、並列処理を容易にするために使用され得るピクチャセグメント化機構の例である。
[0105]本開示の第４の技法は、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄからｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘを除去することを含む。第４の技法の別の例では、ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄにおけるトラックと関連付けられる動作点インデックスのリストの信号伝達が有効にされる。
[0106]本開示の第５の技法は、動作点の必要なレイヤだけをカウントするように、「ｏｉｎｆ」ボックス中のｌａｙｅｒ＿ｃｏｕｎｔフィールドのセマンティクスを変更することを含む。
[0107]本開示の方法及び技法の例示的な実装形態が以下で説明される。以下の例では、ＨＥＶＣ及びＬＨＥＶＣファイルフォーマットに対するテキストの変更が示されている。追加されるテキストは、識別子［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］と［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］との間に示されている。削除されるテキストは、識別子［ＳＴＡＲＴ ＤＥＬＥＴＩＯＮ］と［ＥＮＤ ＤＥＬＥＴＩＯＮ］との間に示されている。
[0108]第１の実装形態が以下で説明される。
このセクションは、本開示の技法１、２、３（その例ａを含まない）、４（その例ａを含まない）及び５のための、ＬＨＥＶＣＳａｍｐｌｅＥｎｔｒｙ、ＨＥＶＣＬＨＶＣＳａｍｐｌｅＥｎｔｒｙ、ＬＨＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄ、及びＯｐｅｒａｔｉｏｎＰｏｉｎｔｓＩｎｆｏｒｍａｔｉｏｎＢｏｘ（「ｏｉｎｆ」）の信号伝達に対する詳細な修正を記述する。
class LHEVCConfigurationBox extends Box(‘lhvC’) {
LHEVCDecoderConfigurationRecord() LHEVCConfig;
}
class HEVCLHVCSampleEntry() extends HEVCSampleEntry() {
LHEVCConfigurationBox lhvcconfig;
[START DELETION] MPEG4BitRateBox (); // optional [END DELETION]
MPEG4ExtensionDescriptorsBox (); // optional
extra_boxes boxes; // optional
}
// Use this if track is not HEVC compatible
class LHEVCSampleEntry() extends VisualSampleEntry (‘lhv1’, or 'lhe1') {
LHVCConfigurationBox lhvcconfig;
[START DELETION] MPEG4BitRateBox (); // optional [END DELETION]
MPEG4ExtensionDescriptorsBox (); // optional
Box extra_boxes[];
}
aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
[START DELETION] unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc; [END DELETION]
bit(1) complete_representation;
bit(3) reserved = ‘111’b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2) parallelismType;
[START DELETION] bit(6) reserved = ‘111111’b;
unsigned int(2) chromaFormat;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthChromaMinus8;
bit(16) avgFrameRate;
bit(2) constantFrameRate; [END DELETION]
[START INSERTION] bit(2) reserved = ‘11’b; [END INSERTION]
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
[START DELETION] unsigned int(16) operationPointIdx; [END DELETION]
}
class OperationPointsInformation extends FullBox(‘oinf’, version = 0, 0){
unsigned int(16) scalability_mask
unsigned int(2) reserved
unsigned int(6) num_profile_tier_level
for (i=1; i<=num_profile_tier_level; i++) {
unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
}
unsigned int(16) num_operation_points
for (i=0; i<num_operation_points) {
unsigned int(16) operation_point_id
unsigned int(8) max_temporal_id;
unsigned int(8) layer_count;
for (i=0; i<layer_count; i++) {
unsigned int(8) ptl_idx
unsigned int(6) layer_id;
unsigned int(1) is_outputlayer;
unsigned int(1) is_alternate_outputlayer;
}
[START INSERTION]
unsigned int(16) minPicWidth;
unsigned int(16) minPicHeight;
unsigned int(16) maxPicWidth;
unsigned int(16) maxPicHeight;
unsigned int(2) maxChromaFormat;
unsigned int(3) maxBitDepthMinus8;
unsigned int(1) reserved
unsigned int(1) frame_rate_info_flag
unsigned int(1) bit_rate_info_flag
if (frame_rate_info_flag) {
bit(16) avgFrameRate;
unsigned int(6) reserved
bit(2) constantFrameRate;
}
if (bit_rate_info_flag) {
unsigned int(32) maxBitRate;
unsigned int(32) avgBitRate;
}[END INSERTION]
}
unsigned int(8) max_layer_count
for (i=0; i<max_layer_count; i++) {
unsigned int(8) dependent_layerID
unsigned int(8) num_layers_dependent_on
for (j=0; j< num_layers_dependent_on; j++) {
unsigned int(8) dependent_on_layerID
}
for (j = 0; j < 16; j++) {
if (scalability mask & (1 << j))
unsigned int(8) dimension_identifier
}
}
}
…
ｌａｙｅｒ＿ｃｏｕｎｔ：このフィールドは、［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］その［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］［ＳＴＡＲＴ ＤＥＬＥＴＩＯＮ］ａｎ［ＥＮＤ ＤＥＬＥＴＩＯＮ］動作点の一部である［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］必要な［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］レイヤの数を示す。
．．．
［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］
ｍｉｎＰｉｃＷｉｄｔｈは、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓパラメータによって定義されるようなルーマ幅インジケータの最小値を規定する。
ｍｉｎＰｉｃＨｅｉｇｈｔは、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓパラメータによって定義されるようなルーマ高さインジケータの最小値を規定する。
ｍａｘＰｉｃＷｉｄｔｈは、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓパラメータによって定義されるようなルーマ幅インジケータの最大値を規定する。
ｍａｘＰｉｃＨｅｉｇｈｔは、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓパラメータによって定義されるようなルーマ高さインジケータの最大値を規定する。
ｍａｘＣｈｒｏｍａＦｏｒｍａｔは、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃパラメータによって定義されるようなｃｈｒｏｍａ＿ｆｏｒｍａｔインジケータの最大値を規定する。
ｍａｘＢｉｔＤｅｐｔｈＭｉｎｕｓ８は、動作点のストリームに対してＩＳＯ／ＩＥＣ ２３００８−２におけるｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８パラメータ及びｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８パラメータによってそれぞれ定義されるようなルーマビット深度インジケータ及びクロマビット深度インジケータの最大値を規定する。
０に等しいｆｒａｍｅ＿ｒａｔｅ＿ｉｎｆｏ＿ｆｌａｇは、フレームレート情報がその動作点に対して存在しないことを示す。値１は、フレームレート情報がその動作点に対して存在することを示す。
０に等しいｂｉｔ＿ｒａｔｅ＿ｉｎｆｏ＿ｆｌａｇは、ビットレート情報がその動作点に対して存在しないことを示す。値１は、ビットレート情報がその動作点に対して存在することを示す。
ａｖｇＦｒａｍｅＲａｔｅは、その動作点に対する平均フレームレートをフレーム／（２５６秒）の単位で与える。値０は、未指定の平均フレームレートを示す。
１に等しいｃｏｎｓｔａｎｔＦｒａｍｅＲａｔｅは、動作点のストリームのフレームレートが一定であることを示す。値２は、動作点のストリーム中の各時間レイヤの表現のフレームレートが一定であることを示す。値０は、動作点のストリームのフレームレートが一定であることも、又は一定ではないこともあることを示す。
ｍａｘＢｉｔＲａｔｅは、１秒の任意の時間枠にわたる、動作点のストリームのビット／秒単位の最大ビットレートを与える。
ａｖｇＢｉｔＲａｔｅは、動作点のストリームのビット／秒単位の平均ビットレートを与える。
．．．
［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］
[0109]第２の実装形態が以下で説明される。
このセクションは、本開示の例３（ａ）に対するＬＨＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの信号伝達への詳細な修正を記述した。
aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
[START DELETION] unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
bit(1) complete_representation;
bit(3) reserved = ‘111’b; [END DELETION]
[START INSERTION] bit(2) reserved = ‘11’b; [END INSERTION]
[START INSERTION] unsigned int(6) num_layers; [END INSERTION]
for (j=0; j < num_layers; j++) {
[START INSERTION] unsigned int(8) layer_id; [END INSERTION]
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2) parallelismType;
bit(6) reserved = ‘111111’b;
unsigned int(2) chromaFormat;
[START INSERTION] bit(6) reserved = ‘111111’b; [END INSERTION]
[START DELETION] bit(5) reserved = ‘11111’b; [ENDDELETION]
unsigned int(3) bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthChromaMinus8;
[START INSERTION] bit(5) reserved = ‘11111’b; [END INSERTION]
[START DELETION] bit(16) avgFrameRate;
bit(2) constantFrameRate; [END DELETION]
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
[START INSERTION] bit(4) reserved = ‘1111’b; [END INSERTION]
}
[START INSERTION] bit(1) complete_representation; [END INSERTION]
unsigned int(2) lengthSizeMinusOne;
[START INSERTION] bit(5) reserved = ‘11111’b; [END INSERTION]
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
[START DELETION] unsigned int(16) operationPointIdx; [END DELETION]
}
[START INSERTION]
num_layers specifies the number of layers in the track.
layer_id specifies the layer ID value for which the information in this loop is provided.
[END INSERTION]
[1] A third implementation is described below.
This section describes the detail modifications to the signaling of LHVCDecoderConfigurationRecord for the disclosure example 4(a).

aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
bit(1) complete_representation; bit(3) reserved = ‘111’b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2) parallelismType;
bit(6) reserved = ‘111111’b;
unsigned int(2) chromaFormat;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthChromaMinus8;
bit(16) avgFrameRate;
bit(2) constantFrameRate;
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］
ｎｕｍ＿ｌａｙｅｒｓは、トラック中のレイヤの数を規定する。
ｌａｙｅｒ＿ｉｄは、このループ中の情報が提供される対象のレイヤＩＤ値を規定する。
［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］
[0110]第３の実装形態が以下で説明される。
このセクションは、本開示の例４（ａ）に対するＬＨＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの信号伝達に対する詳細な修正を記述する。
aligned(8) class LHEVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
unsigned int(2) general_profile_space;
unsigned int(1) general_tier_flag;
unsigned int(5) general_profile_idc;
unsigned int(32) general_profile_compatibility_flags;
unsigned int(48) general_constraint_indicator_flags;
unsigned int(8) general_level_idc;
bit(1) complete_representation; bit(3) reserved = ‘111’b;
unsigned int(12) min_spatial_segmentation_idc;
bit(6) reserved = ‘111111’b;
unsigned int(2) parallelismType;
bit(6) reserved = ‘111111’b;
unsigned int(2) chromaFormat;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthLumaMinus8;
bit(5) reserved = ‘11111’b;
unsigned int(3) bitDepthChromaMinus8;
bit(16) avgFrameRate;
bit(2) constantFrameRate;
bit(3) numTemporalLayers;
bit(1) temporalIdNested;
unsigned int(2) lengthSizeMinusOne;
unsigned int(8) numOfArrays;
for (j=0; j < numOfArrays; j++) {
bit(1) array_completeness;
unsigned int(1) reserved = 0;
unsigned int(6) NAL_unit_type;
unsigned int(16) numNalus;
for (i=0; i< numNalus; i++) {
unsigned int(16) nalUnitLength;
bit(8*nalUnitLength) nalUnit;
}
}
[START DELETION] unsigned int(16) operationPointIdx; [END DELETION]
[START INSERTION]
unsigned int(16) numOfOperationPoints;
for (j=0; j < numOfOperationPoints; j++) {
unsigned int(16) operationPointIdx;
} [END INSERTION]
}
［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］ｎｕｍＯｐｅｒａｔｉｏｎＰｏｉｎｔｓ：このフィールドは、トラックに対して利用可能な動作点の数を信号伝達する。［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］
ｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ：このフィールドは、動作点情報ボックスにおいて記載される動作点のインデックスを信号伝達する。［ＳＴＡＲＴ ＤＥＬＥＴＩＯＮ］ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの中のｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇｓ、ｇｅｎｅｒａｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｄｉｃａｔｏｒ＿ｆｌａｇ、及びｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃの値は、動作点情報ボックス中のｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ番目の動作点のそれぞれの値と同じであるものとする。［ＥＮＤ ＤＥＬＥＴＩＯＮ］［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］動作点情報ボックス中のｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ番目の動作点におけるｍａｘ＿ｔｅｍｐｏｒａｌ＿ｉｄの値は、ｎｕｍＴｅｍｐｏｒａｌＬａｙｅｒｓの値以下であるものとする。［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］
注意 トラックは、［ＳＴＡＲＴ ＤＥＬＥＴＩＯＮ］１つの出力レイヤセットと関連付けられることがあり、又は２つ以上の出力レイヤを、従って２つ以上のプロファイルを表すことがある［ＥＮＤ ＤＥＬＥＴＩＯＮ］［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］１つ又は２つ以上の出力レイヤセットと関連付けられることがある［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］。プレーヤは、［ＳＴＡＲＴ ＩＮＳＥＲＴＩＯＮ］インデックスｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘを有する選択された動作点に対する［ＥＮＤ ＩＮＳＥＲＴＩＯＮ］ＬＨＥＶＣＤｅｃｏｄｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＲｅｃｏｒｄの中のプロファイル情報に対応する、どのレイヤが復号されるべきかということと、どのレイヤが出力されるべきかということとを、動作点情報ボックス中のｏｐｅｒａｔｉｏｎＰｏｉｎｔＩｄｘ番目の動作点に対して提供される情報を調査することによって、見出すことができる。
注意 トラックに含まれる各補助ピクチャレイヤに対して、ｎａｌＵｎｉｔ内に、深度補助ピクチャレイヤのための深度表現情報ＳＥＩメッセージなどの、補助ピクチャレイヤの特性を規定する宣言型ＳＥＩメッセージを含むＳＥＩ ＮＡＬ単位を含めることが推奨される。
[0111]図２は、本開示で説明される技法を実施し得る例示的なビデオエンコーダ２０を示すブロック図である。ビデオエンコーダ２０は、シングルビュー、マルチビュー、スケーラブル、３Ｄ、及び他のタイプのビデオデータを出力するように構成され得る。ビデオエンコーダ２０は、ビデオを後処理エンティティ２７に出力するように構成され得る。後処理エンティティ２７は、ＭＡＮＥ又はスプライシング／編集機器などの、ビデオエンコーダ２０からの被符号化ビデオデータを処理し得るビデオエンティティの例を表すことが意図されている。場合によっては、後処理処理エンティティはネットワークエンティティの例であり得る。幾つかのビデオ符号化システムでは、後処理エンティティ２７及びビデオエンコーダ２０は別個の機器の部分であってもよく、他の事例では、後処理エンティティ２７に関して説明される機能は、ビデオエンコーダ２０を備える同じ機器によって実行されてもよい。後処理エンティティ２７はビデオ機器であり得る。幾つかの例では、後処理エンティティ２７は図１のファイル生成機器３４と同じであり得る。
[0112]ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコード化とインターコード化とを実行することができる。イントラコード化は、所与のビデオフレーム又はピクチャ内のビデオの空間冗長性を低減又は除去するために空間的予測に依拠する。インターコード化は、ビデオシーケンスの隣接するフレーム又はピクチャ内のビデオの時間的冗長性を低減又は除去するために時間的予測に依拠する。イントラモード（Ｉモード）は、幾つかの空間ベースの圧縮モードのいずれかを指し得る。単方向予測（Ｐモード）又は双予測（Ｂモード）のようなインターモードは、幾つかの時間ベースの圧縮モードのいずれかを指し得る。
[0113]図２の例では、ビデオエンコーダ２０は、区分ユニット３７と、予測処理ユニット４１と、フィルタユニット６３と、参照クチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。予測処理ユニット４１は、動き推定ユニット４２と、動き補償ユニット４４と、イントラ予測処理ユニット４６とを含む。ビデオブロックの再構築のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換処理ユニット６０と、加算器６２とを含む。フィルタユニット６３は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ）及びサンプル適応オフセット（ＳＡＯ）フィルタのような、１つ又は複数のループフィルタを表すことが意図されている。図２では、フィルタユニット６３はループ内フィルタであるものとして示されているが、他の構成では、フィルタユニット６３はループ後フィルタとして実装され得る。
[0114]ビデオエンコーダ２０のビデオデータメモリ３５は、ビデオエンコーダ２０のコンポーネントによって符号化されるべきビデオデータを記憶することができる。ビデオデータメモリ３５に記憶されるビデオデータは、例えば、ビデオ発信源１８から取得され得る。参照ピクチャメモリ６４は、例えば、イントラコード化モード又はインターコード化モードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための、参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ３５及び参照ピクチャメモリ６４は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、又は他のタイプのメモリ機器を含む、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）のような、様々なメモリ機器のいずれかによって形成され得る。ビデオデータメモリ３５及び参照ピクチャメモリ６４は、同じメモリ機器又は別個のメモリ機器によって提供され得る。様々な例では、ビデオデータメモリ３５は、ビデオエンコーダ２０の他のコンポーネントとともにオンチップであるか、又はそれらのコンポーネントに対してオフチップであり得る。
[0115]図２に示されているように、ビデオエンコーダ２０はビデオデータを受信し、区分ユニット３７はデータをビデオブロックに区分する。この区分はまた、例えば、ＬＣＵ及びＣＵの４分木構造に従って、スライス、タイル、又は他のより大きいユニットへの区分、アズウェルズアズビデオブロック区分も含み得る。ビデオエンコーダ２０は一般に、符号化されるべきビデオスライス内のビデオブロックを符号化するコンポーネントを示す。スライスは、複数のビデオブロック（場合によってはタイルと呼ばれるビデオブロックのセット）に分割され得る。予測処理ユニット４１は、現在のビデオブロックに関して、誤差結果（例えば、コード化レート及び歪みレベル）に基づいて、複数のイントラコード化モードの１つ又は複数のインターコード化モードの１つのような、複数の可能なコード化モードの１つを選択することができる。予測処理ユニット４１は、得られた被イントラコード化ブロック又は被インターコード化ブロックを、残差ブロックデータを生成するために加算器５０に与え、参照ピクチャとして使用するための被符号化ブロックを再構築するために加算器６２に与え得る。
[0116]予測処理ユニット４１内のイントラ予測処理ユニット４６は、空間的圧縮を行うために、コード化されるべき現在のブロックと同じフレーム又はスライス中の１つ又は複数の隣接ブロックに対する現在のビデオブロックのイントラ予測コード化を実行することができる。予測処理ユニット４１内の動き推定ユニット４２及び動き補償ユニット４４は、時間的圧縮を行うために、１つ又は複数の参照ピクチャ中の１つ又は複数の予測ブロックに対して現在のビデオブロックのインター予測コード化を実行する。
[0117]動き推定ユニット４２は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを決定するように構成され得る。所定のパターンは、シーケンス中のビデオスライスを、Ｐスライス、Ｂスライス又はＧＰＢスライスとして指定し得る。動き推定ユニット４２及び動き補償ユニット４４は、高度に統合され得るが、概念的な目的のために別々に示されている。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、例えば、参照ピクチャ内の予測ブロックに対する現在のビデオフレーム又は現在のピクチャ内のビデオブロックのＰＵの変位を示し得る。
[0118]予測ブロックは、絶対差分和（ＳＡＤ）、２乗差分和（ＳＳＤ）、又は他の差分の尺度によって決定され得る画素差分に関して、コード化されるべきビデオブロックのＰＵと厳密に一致することが判明しているブロックである。幾つかの例では、ビデオエンコーダ２０は、参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数画素位置の値を計算することができる。例えば、ビデオエンコーダ２０は、参照ピクチャの４分の１画素位置、８分の１画素位置、又は他の分数の画素位置の値を補間することができる。従って、動き推定ユニット４２は、フル画素位置及び分数画素位置に対して動き探索を実行し、動きベクトルを分数画素精度で出力することができる。
[0119]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、被インターコード化スライス中のビデオブロックのＰＵの動きベクトルを計算する。参照ピクチャは、その各々が、参照ピクチャメモリ６４に記憶された１つ又は複数の参照ピクチャを識別する、第１の参照ピクチャリスト（リスト０）又は第２の参照ピクチャリスト（リスト１）から選択され得る。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。
[0120]動き補償ユニット４４によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチ又は生成すること、場合によってはサブ画素精度への補間を実行することを伴い得る。現在のビデオブロックのＰＵの動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストの１つにおいて指す予測ブロックの位置を特定することができる。ビデオエンコーダ２０は、コード化されている現在のビデオブロックの画素値から予測ブロックの画素値を減算し、画素差分値を形成することによって残差ビデオブロックを形成することができる。画素差分値は、ブロックのための残差データを形成し、ルーマとクロマの両方の差分成分を含み得る。加算器５０は、この減算演算を実行する１つ又は複数のコンポーネントを表す。動き補償ユニット４４はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０によって使用するための、ビデオブロックとビデオスライスとに関連付けられたシンタックス要素を生成することができる。
[0121]イントラ予測処理ユニット４６は、上で説明されたように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測することができる。特に、イントラ予測処理ユニット４６は、現在のブロックを符号化するために使用するイントラ予測モードを決定することができる。幾つかの例では、イントラ予測処理ユニット４６は、例えば、別個の符号化パスの間に、様々なイントラ予測モードを使用して現在のブロックを符号化することができ、イントラ予測処理ユニット４６（又は、幾つかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。例えば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードにレート歪み分析を使用してレート歪み値を計算し、テストされたモードの中で最良のレート歪み特性を有するイントラ予測モードを選択することができる。レート歪み分析は、一般に、符号化されたブロックと、被符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間の歪み（又は、誤差）の量、及び符号化されたブロックを作成するのに使用されたビットレート（即ち、ビットの数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックに関する最良のレート歪み値を示すのかを決定するために、様々な符号化されたブロックの歪み及びレートから比を算出することができる。
[0122]いずれの場合も、ブロックのためのイントラ予測モードを選択した後に、イントラ予測処理ユニット４６は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット５６に与えることができる。エントロピー符号化ユニット５６は、本開示の技法に従って、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ２０は、複数のイントラ予測モードインデックステーブル及び（符号語マッピングテーブルとも呼ばれる）複数の被修正イントラ予測モードインデックステーブルと、様々なブロックに対する符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、及び被修正イントラ予測モードインデックステーブルの指示とを含み得る構成データを、送信されるビットストリーム中に含めることができる。
[0123]予測処理ユニット４１が、インター予測又はイントラ予測のいずれかを介して、現在のビデオブロックの予測ブロックを生成した後に、ビデオエンコーダ２０は、現在のビデオブロックから予測ブロックを減算することによって、残差ビデオブロックを形成することができる。残差ブロック中の残差ビデオデータは、１つ又は複数のＴＵ中に含まれ、変換処理ユニット５２に適用され得る。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）又は概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット５２は、残差ビデオデータを画素領域から周波数領域などの変換領域に変換することができる。
[0124]変換処理ユニット５２は、結果として得られる変換係数を量子化ユニット５４に送ることができる。量子化ユニット５４は、ビットレートを更に低減するために変換係数を量子化する。量子化プロセスは、係数の一部又は全てと関連付けられるビット深度を減らすことができる。量子化の程度は、量子化パラメータを調整することによって、修正され得る。幾つかの例では、量子化ユニット５４は次いで、被量子化変換係数を含む行列の走査を実行することができる。代替的に、エントロピー符号化ユニット５６が走査を実行することができる。
[0125]量子化に続いて、エントロピー符号化ユニット５６は、被量子化変換係数を表すシンタックス要素をエントロピー符号化することができる。例えば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コード化（ＣＡＶＬＣ：context adaptive variable length coding）、コンテキスト適応型バイナリ算術コード化（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コード化（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：probability interval partitioning entropy）コード化、又は別のエントロピー符号化の方法若しくは技法を実行し得る。エントロピー符号化ユニット５６によるエントロピー符号化の後に、符号化されたビットストリームはビデオデコーダ３０に送信され、又は、ビデオデコーダ３０による後の送信又は取り出しのためにアーカイブされ得る。エントロピー符号化ユニット５６はまた、コード化されている現在のビデオスライスのための動きベクトルと他のシンタックス要素とをエントロピー符号化することができる。
[0126]逆量子化ユニット５８及び逆変換処理ユニット６０は、それぞれ逆量子化及び逆変換を適用して、参照ピクチャの参照ブロックとして後で使用するために画素領域において残差ブロックを再構築する。動き補償ユニット４４は、残差ブロックを参照ピクチャリストのうちの１つの中の参照ピクチャの１つの予測ブロックに加算することによって参照ブロックを計算することができる。動き補償ユニット４４はまた、再構築された残差ブロックに１つ又は複数の補間フィルタを適用して、動き推定において使用するためのサブ整数画素値を計算し得る。加算器６２は、再構築された残差ブロックを動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ６４に記憶するための参照ブロックを生成する。参照ブロックは、後続のビデオフレーム又はピクチャ中のブロックをインター予測するために、動き推定ユニット４２及び動き補償ユニット４４によって参照ブロックとして使用され得る。
[0127]ビデオエンコーダ２０は、本開示で説明されるファイルフォーマット技法を使用して記憶され得る、ビデオコーダコンフィギャードジェネレートビデオデータの例を表す。
[0128]図３は、本開示で説明される技法を実施し得る例示的なビデオデコーダ３０を示すブロック図である。ビデオデコーダ３０は、シングルビュー、マルチビュー、スケーラブル、３Ｄ、及び他のタイプのビデオデータを復号するように構成され得る。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット８０と、予測処理ユニット８１と、逆量子化ユニット８６と、逆変換処理ユニット８８と、加算器９０と、フィルタユニット９１と、参照ピクチャメモリ９２とを含む。予測処理ユニット８１は、動き補償ユニット８２とイントラ予測処理ユニット８４とを含む。ビデオデコーダ３０は、幾つかの例では、図２においてビデオエンコーダ２０に関して説明された符号化パスとは概ね逆の復号パスを実行することができる。
[0129]被コード化ピクチャバッファ（ＣＰＢ）７９は、ビットストリームの被符号化ビデオデータ（例えば、ＮＡＬ単位）を受信し、記憶することができる。ＣＰＢ７９に記憶されるビデオデータは、例えば、リンク１６から、例えば、カメラなどのローカルビデオ発信源から、ビデオデータの有線若しくはワイヤレスネットワーク通信を介して、又は物理データ記憶媒体にアクセスすることによって、取得され得る。ＣＰＢ７９は、被符号化ビデオビットストリームからの被符号化ビデオデータを記憶するビデオデータメモリを形成し得る。ＣＰＢ７９は、例えば、イントラコード化モード又はインターコード化モードでビデオデコーダ３０によってビデオデータを復号する際に使用するための参照ビデオデータを記憶する参照ピクチャメモリであり得る。ＣＰＢ７９及び参照ピクチャメモリ９２は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ）、又は他のタイプのメモリ機器を含む、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの様々なメモリ機器のいずれかによって形成され得る。ＣＰＢ７９及び参照ピクチャメモリ９２は、同じメモリ機器又は別々のメモリ機器によって提供され得る。様々な例では、ＣＰＢ７９は、ビデオデコーダ３０の他のコンポーネントとともにオンチップであってよく、又はそれらのコンポーネントに対してオフチップであってもよい。
[0130]復号プロセスの間、ビデオデコーダ３０は、被符号化ビデオスライスのビデオブロックと、関連付けられたシンタックス要素とを表す、被符号化ビットストリームをビデオエンコーダ２０から受信する。ビデオデコーダ３０は、ネットワークエンティティ２９から被符号化ビデオビットストリームを受信することができる。ネットワークエンティティ２９は、例えば、上で説明された技法の１つ又は複数を実装するように構成されたサーバ、ＭＡＮＥ、ビデオエディタ／スプライサ、又は他のそのような機器であり得る。ネットワークエンティティ２９は、ビデオエンコーダ２０のようなビデオエンコーダを含んでもよく、又は含まなくてもよい。本開示で説明される技法の幾つかは、ネットワークエンティティ２９が被符号化ビデオビットストリームをビデオデコーダ３０に送信するのに先立って、ネットワークエンティティ２９によって実施され得る。幾つかのビデオ復号システムでは、ネットワークエンティティ２９及びビデオデコーダ３０は別個の機器の一部であり得るが、他の事例では、ネットワークエンティティ２９に関して説明される機能は、ビデオデコーダ３０を備える同じ機器によって実行され得る。ネットワークエンティティ２９は、ビデオ機器と見なされ得る。更に、幾つかの例では、ネットワークエンティティ２９は、図１のファイル生成機器３４である。
[0131]ビデオデコーダ３０のエントロピー復号ユニット８０は、被量子化係数と、動きベクトルと、他のシンタックス要素とを生成するために、ビットストリームの特定のシンタックス要素をエントロピー復号する。エントロピー復号ユニット８０は、動きベクトルと他のシンタックス要素とを予測処理ユニット８１に転送する。ビデオデコーダ３０は、ビデオスライスレベル及び／又はビデオブロックレベルでシンタックス要素を受信し得る。
[0132]ビデオスライスがイントラコード化された（Ｉ）スライスとしてコード化されるとき、予測処理ユニット８１のイントラ予測処理ユニット８４は、信号伝達されたイントラ予測モード、及び現在のフレーム又はピクチャの前に復号されたブロックからのデータに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成することができる。ビデオフレームがインターコード化された（即ち、Ｂ、Ｐ又はＧＰＢ）スライスとしてコード化されるとき、予測処理ユニット８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトル及び他のシンタックス要素に基づいて、現在のビデオスライスのビデオブロックの予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの１つの中の参照ピクチャの１つから生成され得る。ビデオデコーダ３０は、参照ピクチャメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、即ち、リスト０とリスト１とを構築することができる。
[0133]動き補償ユニット８２は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックに対する予測情報を決定し、予測情報を使用して、復号されている現在のビデオブロックの予測ブロックを生成する。例えば、動き補償ユニット８２は、ビデオスライスのビデオブロックをコード化するために使用される予測モード（例えば、イントラ予測又はインター予測）と、インター予測スライスタイプ（例えば、Ｂスライス、Ｐスライス又はＧＰＢスライス）と、スライスの参照ピクチャリストの１つ又は複数のための構成情報と、スライスの各々のインター符号化されたビデオブロックのための動きベクトルと、スライスの各々のインター被コード化ビデオブロックのためのインター予測ステータスと、現在のビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素の幾つかを使用する。
[0134]動き補償ユニット８２はまた、補間フィルタに基づいて補間を実行することができる。動き補償ユニット８２は、参照ブロックのサブ整数画素の補間された値を計算するために、ビデオブロックの符号化の間にビデオエンコーダ２０によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット８２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定することができ、その補間フィルタを使用して予測ブロックを生成することができる。
[0135]逆量子化ユニット８６は、ビットストリーム中で与えられ、エントロピー復号ユニット８０によって復号された被量子化変換係数を逆量子化し（inverse quantize）、即ち逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ２０によって計算される量子化パラメータの使用を含み得る。逆変換処理ユニット８８は、画素領域において残差ブロックを生成するために、逆変換、例えば、逆ＤＣＴ、逆整数変換、又は概念的に同様の逆変換処理を変換係数に適用する。
[0136]動き補償ユニット８２が、動きベクトル及び他のシンタックス要素に基づいて現在のビデオブロックの予測ブロックを生成した後、ビデオデコーダ３０は、逆変換処理ユニット８８からの残差ブロックを動き補償ユニット８２によって生成された対応する予測ブロックと加算することによって、被復号ビデオブロックを形成する。加算器９０は、この加算演算を実行する１つ又は複数のコンポーネントを表す。所望される場合、ループフィルタ（コード化ループの中又はコード化ループの後のいずれかの）も、画素移行を平滑化し、又は別様にビデオ品質を向上させるために使用され得る。フィルタユニット９１は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ）及びサンプル適応オフセット（ＳＡＯ）フィルタのような、１つ又は複数のループフィルタを表すことが意図されている。図３では、フィルタユニット９１はループ内フィルタであるものとして示されているが、他の構成では、フィルタユニット９１はループ後フィルタとして実装され得る。所与のフレーム又はピクチャ中の復号ビデオブロックは、次いで、後続の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ９２に記憶される。参照ピクチャメモリ９２はまた、図１の表示装置３２のような表示装置上での後の表示のために、復号されたビデオを記憶する。
[0137]図３のビデオデコーダ３０は、本開示で説明されるファイルフォーマット技法を使用して記憶され得る、ビデオデータを復号するように構成されるビデオデコーダの例を表す。
[0138]図４は、ネットワーク１００の一部を形成する機器の例示的なセットを示すブロック図である。この例では、ネットワーク１００は、ルーティング機器１０４Ａ、１０４Ｂ（ルーティング機器１０４）とトランスコード化機器１０６とを含む。ルーティング機器１０４及びトランスコード化機器１０６は、ネットワーク１００の一部を形成し得る少数の機器を表すことが意図されている。スイッチ、ハブ、ゲートウェイ、ファイアウォール、ブリッジ、及び他のそのような機器などの他のネットワーク機器も、ネットワーク１００内に含まれ得る。その上、サーバ機器１０２とクライアント機器１０８との間のネットワーク経路に沿って、追加のネットワーク機器が提供され得る。幾つかの例では、サーバ機器１０２は発信源機器１２（図１）に対応し得る一方、クライアント機器１０８は宛先機器１４（図１）に対応し得る。
[0139]一般に、ルーティング機器１０４は、ネットワーク１００を通じてネットワークデータを交換するための１つ又は複数のルーティングプロトコルを実装する。幾つかの例では、ルーティング機器１０４は、プロキシ又はキャッシュ動作を実行するように構成され得る。従って、幾つかの例では、ルーティング機器１０４はプロキシ機器と呼ばれ得る。一般に、ルーティング機器１０４は、ネットワーク１００を通るルートを発見するためにルーティングプロトコルを実行する。そのようなルーティングプロトコルを実行することによって、ルーティング機器１０４Ｂは、それ自体からルーティング機器１０４Ａを介してサーバ機器１０２へ至るネットワークルートを発見することができる。
[0140]本開示の技法は、ルーティング機器１０４及びトランスコード化機器１０６のようなネットワーク機器によって実施され得るが、クライアント機器１０８によっても実施され得る。このように、ルーティング機器１０４、トランスコード化機器１０６及びクライアント機器１０８は、本開示の技法を実行するように構成された機器の例を表す。その上、図１の機器並びに図２に示されるエンコーダ２０及び図３に示されるデコーダ３０も、本開示の技法の１つ又は複数を実行するように構成され得る機器の例である。
[0141]図５Ａは、本開示の１つ又は複数の技法による、ファイル３００の例示的な構造を示す概念図である。図５Ａの例では、ファイル３００は、ムービーボックス３０２と、複数のメディアデータボックス３０４とを含む。図５Ａの例では同じファイルの中にあるものとして示されるが、他の例では、ムービーボックス３０２及びメディアデータボックス３０４は別のファイルの中にあり得る。上で示されたように、「ボックス」は、固有のタイプ識別子及び長さによって定義されるオブジェクト指向の構築ブロックであり得る。例えば、ボックスは、４文字のコード化されたボックスタイプと、ボックスのバイトカウントと、ペイロードとを含む、ＩＳＯＢＭＦＦにおける基本的なシンタックス構造であり得る。
[0142]ムービーボックス３０２は、ファイル３００のトラックのためのメタデータを含み得る。ファイル３００の各トラックは、メディアデータの連続的なストリームを備え得る。メディアデータボックス３０４の各々は、１つ又は複数のサンプル３０５を含み得る。サンプル３０５の各々は、オーディオ又はビデオアクセス単位を備え得る。本開示の他の箇所で説明されるように、各アクセス単位は、マルチビューコード化（例えば、ＭＶ−ＨＥＶＣ及び３Ｄ−ＨＥＶＣ）及びスケーラブルビデオコード化（例えば、ＳＨＶＣ）では複数の被コード化ピクチャを備え得る。例えば、アクセス単位は、各レイヤのための１つ又は複数の被コード化ピクチャを含み得る。
[0143]更に、図５Ａの例では、ムービーボックス３０２はトラックボックス３０６を含む。トラックボックス３０６は、ファイル３００のトラックのためのメタデータを封入し得る。他の例では、ムービーボックス３０２は、ファイル３００の異なるトラックのために複数のトラックボックスを含み得る。トラックボックス３０６は、メディアボックス３０７を含む。メディアボックス３０７は、トラック内のメディアデータについての情報を宣言する全てのオブジェクトを含み得る。メディアボックス３０７は、メディア情報ボックス３０８を含む。メディア情報ボックス３０８は、トラックのメディアの特性情報を宣言する全てのオブジェクトを含み得る。メディア情報ボックス３０８は、サンプルテーブルボックス３０９を含む。サンプルテーブルボックス３０９は、サンプル固有のメタデータを指定することができる。
[0144]図５Ａの例では、サンプルテーブルボックス３０９は、ＳａｍｐｌｅＴｏＧｒｏｕｐボックス３１０と、ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２とを含み、ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２はｏｉｎｆボックス３１６を含む。他の例では、サンプルテーブルボックス３０９は、ＳａｍｐｌｅＴｏＧｒｏｕｐボックス３１０及びＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２に加えて他のボックスを含んでよく、及び／又は複数のＳａｍｐｌｅＴｏＧｒｏｕｐボックスとＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスとを含んでよい。ＳａｍｐｌｅＴｏＧｒｏｕｐボックス３１０は、サンプル（例えば、サンプル３０５の特定の１つ）をサンプルのグループにマッピングすることができる。ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２は、サンプルのグループ（即ち、サンプルグループ）の中のサンプルによって共有される性質を指定し得る。更に、サンプルテーブルボックス３０９は、複数のサンプルエントリーボックス３１１を含み得る。サンプルエントリーボックス３１１の各々は、サンプルのグループ中のサンプルに対応し得る。幾つかの例では、サンプルエントリーボックス３１１は、ベースサンプルグループ記述クラスを拡張する、Ｒａｎｄｏｍ Ａｃｃｅｓｓｉｂｌｅ Ｓａｍｐｌｅ Ｅｎｔｒｙクラスの事例である。
[0145]本開示の１つ又は複数の技法によれば、ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２は、サンプルグループの各サンプルが少なくとも１つのＩＲＡＰピクチャを含むことを指定し得る。このようにして、ファイル生成機器３４は、ファイル３００中のトラックのためのメタデータを含むトラックボックス３０６を備えるファイルを生成することができる。トラックのためのメディアデータは、サンプル３０５のシーケンスを備える。サンプルの各々は、マルチレイヤビデオデータ（例えば、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、又は３Ｄ−ＨＥＶＣビデオデータ）のビデオアクセス単位であり得る。更に、ファイル３００を生成することの一部として、ファイル生成機器３４は、ファイル３００において、少なくとも１つのＩＲＡＰピクチャを含むサンプル３０５の全てを記録する追加のボックス（即ち、サンプルテーブルボックス３０９）を生成することができる。言い換えると、追加のボックスは、少なくとも１つのＩＲＡＰピクチャを含むサンプル３０５の全てを特定する。図５Ａの例では、追加のボックスは、少なくとも１つのＩＲＡＰピクチャを含むサンプル３０５の各々を記録する（例えば、特定する）サンプルグループを定義する。言い換えると、追加のボックスは、少なくとも１つのＩＲＡＰピクチャを含むサンプル３０５がサンプルグループに属することを指定する。
[0146]本開示の技法によれば、ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス３１２はｏｉｎｆボックス３１６を含み得る。ｏｉｎｆボックスは、ビデオデータの各動作点のための表現フォーマット情報を記憶し得る。表現フォーマット情報は、空間分解能、ビット深度又は色フォーマットの１つ又は複数を含み得る。加えて、ｏｉｎｆボックスは、ビデオデータの動作点の幾つかの必要なレイヤを示すレイヤカウントを記憶し得る。ｏｉｎｆボックスは加えて、ビデオデータの各動作点のためのビットレート情報を記憶し得る。従って、ビットレート情報がｏｉｎｆボックスにおいて信号伝達されるので、構成ボックスの後でビットレートボックスを信号伝達する必要がないことがある。
[0147]加えて、プロファイル、ティア及びレベルＰＴＬ情報と、表現フォーマット情報と、フレームレート情報とを、ファイルフォーマットのデコーダ構成記録に記憶する必要はないことがある。デコーダ構成記録中の全ての他の情報が、トラック中のビデオデータの全てのレイヤと関連付けられ得る。ビデオデータの各レイヤに対するデコーダ構成記録は、表現フォーマット情報とフレームレート情報とを記憶し得る。デコーダ構成記録は、ビデオデータの各レイヤのためのパラレリズム情報を記憶し得る。ファイルは通常、トラックのための１つのデコーダ構成記録を含むだけであるが、トラックは１つ又は複数のレイヤと１つ又は複数の動作点とを含み得る。ＰＴＬ情報、表現フォーマット情報及びフレームレート情報は、各レイヤ又は各ＯＰのいずれかと関連付けられ得る。従って、１つのレイヤだけをサポートするＨＥＶＣファイルフォーマットとは異なり、デコーダ構成記録は、複数のレイヤをサポートするＬＨＥＶＣファイルフォーマットに対してこの関連付けを適切に支援することが可能ではないことがある。
[0148]デコーダ構成記録は、デコーダ構成記録に動作点インデックスを記憶しないことがあり、動作点インデックスは、動作点情報ボックスにおいて記載される動作点のインデックスを参照する。デコーダ構成記録に動作点インデックスを記憶することは、トラックを再生する機器（即ち、デコーダ構成記録と関連付けられるザ）に、その動作点インデックスによって参照される動作点を再生させ得る。しかしながら、利用可能なより多くの動作点が存在することがある。動作点インデックスを除去することは、再生機器がファイルによってサポートされる全ての動作点を特定することをより可能にし得る。デコーダ構成記録は、ビデオデータのトラックと関連する動作点インデックスのリストを記憶し得る。デコーダ構成記録は、例えば、図５Ａのサンプルエントリーボックス３１１の中の情報から導出され得る。
[0149]デコーダ構成記録は、各サンプルにおいて使用される長さフィールドのサイズなどの情報を、その含まれているＮＡＬ単位の長さ及びサンプルエントリーに記憶されていればパラメータセットを示すために、記憶する。デコーダ構成記録は、例えば、外部的に枠組みが決められ得る（例えば、デコーダ構成記録のサイズはデコーダ構成記録を含む構造によって供給されるべきである）。デコーダ構成記録はまた、従っている仕様のバージョンを特定するためのバージョンフィールドを含むことがあり、記録に対する適合しない変更がバージョン番号の変更によって示される。対照的に、この記録に対する適合する拡張は、構成バージョンコードへの変更を必要としないことがある。デコーダ構成記録はまた、ＨＥＶＣにおいて定義される、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ、ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃ、ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇｓ、ｇｅｎｅｒａｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｄｉｃａｔｏｒ＿ｆｌａｇｓ、ｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃ、ｍｉｎ＿ｓｐａｔｉａｌ＿ｓｅｇｍｅｎｔａｔｉｏｎ＿ｉｄｃ、ｃｈｒｏｍａ＿ｆｏｒｍａｔ＿ｉｄｃ、ｂｉｔ＿ｄｅｐｔｈ＿ｌｕｍａ＿ｍｉｎｕｓ８、及びｂｉｔ＿ｄｅｐｔｈ＿ｃｈｒｏｍａ＿ｍｉｎｕｓ８などの、幾つかのＨＥＶＣシンタックス要素の値を含み得る。デコーダ構成記録は、時間サブレイヤの数、セグメント化情報、サポートされるパラレリズムタイプ及びパラメータセットＮＡＬ単位（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳ、ＳＥＩなど）を、構成記録を含むトラックと関連付ける、一般的な情報を含み得る。
[0150]更に、本開示の１つ又は複数の技法によれば、サンプルエントリーボックス３１１の各々は、対応するサンプル中の全ての被コード化ピクチャがＩＲＡＰピクチャであるかどうかを示す値（例えば、ａｌｌ＿ｐｉｃｓ＿ａｒｅ＿ＩＲＡＰ）を含み得る。幾つかの例では、１に等しい値は、全ての被コード化ピクチャサンプルがＩＲＡＰピクチャであることはないことを指定する。０に等しい値は、サンプルグループの各サンプル中の各々の被コード化ピクチャがＩＲＡＰピクチャであることが要求されないことを指定する。
[0151]幾つかの例では、特定のサンプル中の全ての被コード化ピクチャがＩＲＡＰピクチャであることはないとき、ファイル生成機器３４は、特定のサンプル中の幾つかのＩＲＡＰピクチャを示す値（例えば、ｎｕｍ＿ＩＲＡＰ＿ｐｉｃｓ）を、特定のサンプルのためのサンプルエントリーボックス３１１の１つに含め得る。加えて、ファイル生成機器３４は、特定のサンプル中のＩＲＡＰピクチャのレイヤ識別子を示す値を、特定のサンプルのためのサンプルエントリーに含め得る。ファイル生成機器３４はまた、特定のサンプル中のＩＲＡＰピクチャ中のＶＣＬ ＮＡＬ単位のＮＡＬ単位タイプを示す値を、特定のサンプルのためのサンプルエントリーに含め得る。
[0152]更に、図５Ａの例では、サンプルテーブルボックス３０９はサブサンプル情報ボックス３１４を含む。図５Ａの例は１つのサブサンプル情報ボックスのみを示すが、サンプルテーブルボックス３０９は複数のサブサンプル情報ボックスを含み得る。一般に、サブサンプル情報ボックスは、サブサンプル情報を含むように設計される。サブサンプルは、サンプルのうちのある連続的な範囲のバイトである。ＩＳＯ／ＩＥＣ １４４９６−１２は、Ｈ．２６４／ＡＶＣ又はＨＥＶＣのような、所与のコード化システムに対してサブサンプルの固有の定義が与えられるべきであることを示す。
[0153]ＩＳＯ／ＩＥＣ １４４９６−１５のセクション８．４．８は、ＨＥＶＣのためのサブサンプルの定義を規定する。具体的には、ＩＳＯ／ＩＥＣ １４４９６−１５のセクション８．４．８は、ＨＥＶＣストリームにおけるサブサンプル情報ボックス（ＩＳＯ／ＩＥＣ １４４９６−１２の８．７．７）の使用のために、サブサンプル情報ボックスのフラグフィールドの値に基づいてサブサンプルが定義されることを規定する。本開示の１つ又は複数の技法によれば、サブサンプル情報ボックス３１４の中のフラグフィールドが５に等しい場合、サブサンプル情報ボックス３１４に対応するサブサンプルは、１つの被コード化ピクチャと、関連付けられる非ＶＣＬ ＮＡＬ単位とを含む。関連付けられる非ＶＣＬ ＮＡＬ単位は、被コード化ピクチャに適用可能なＳＥＩメッセージを含むＮＡＬ単位と、被コード化ピクチャに適用可能なパラメータセット（例えば、ＶＰＳ、ＳＰＳ、ＰＰＳなど）を含むＮＡＬ単位とを含み得る。
[0154]従って、一例では、ファイル生成機器３４は、ファイル中のトラックのためのメタデータを含むトラックボックス（例えば、トラックボックス３０６）を備えるファイル（例えば、ファイル３００）を生成することができる。この例では、トラックのためのメディアデータは、サンプルのシーケンスを備え、サンプルの各々は、マルチレイヤビデオデータ（例えば、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、又は３Ｄ−ＨＥＶＣビデオデータ）のビデオアクセス単位である。更に、この例では、ファイル生成機器３４がファイルを生成することの一部として、ファイル生成機器３４は、ファイルにおいて、サブサンプル情報ボックス中で与えられるサブサンプル情報のタイプを指定するフラグを含むサブサンプル情報ボックス（例えば、サブサンプル情報ボックス３１４）を生成することができる。そのフラグがある特定の値を有するとき、サブサンプル情報ボックスに対応するサブサンプルは、ちょうど１つの被コード化ピクチャと、被コード化ピクチャと関連付けられる０個以上の非ＶＣＬ ＮＡＬ単位とを含む。
[0155]更に、本開示の１つ又は複数の技法によれば、サブサンプル情報ボックス３１４のフラグフィールドが０に等しい場合、サブサンプル情報ボックス３１４は更に、ＤｉｓｃａｒｄａｂｌｅＦｌａｇ値と、ＮｏＩｎｔｅｒＬａｙｅｒＰｒｅｄＦｌａｇ値と、ＬａｙｅｒＩｄ値と、ＴｅｍｐＩｄ値とを含む。サブサンプル情報ボックス３１４のフラグフィールドが５に等しい場合、サブサンプル情報ボックス３１４は、ＤｉｓｃａｒｄａｂｌｅＦｌａｇ値と、ＶｃｌＮａｌＵｎｉｔＴｙｐｅ値と、ＬａｙｅｒＩｄ値と、ＴｅｍｐＩｄ値と、ＮｏＩｎｔｅｒＬａｙｅｒＰｒｅｄＦｌａｇ値と、ＳｕｂＬａｙｅｒＲｅｆＮａｌＵｎｉｔＦｌａｇ値と、予備の値とを含み得る。
[0156]０に等しいＳｕｂＬａｙｅｒＲｅｆＮａｌＵｎｉｔＦｌａｇは、サブサンプル中の全てのＮＡＬ単位が、ＩＳＯ／ＩＥＣ ２３００８−２（即ち、ＨＥＶＣ）において規定されるようなサブレイヤ非参照ピクチャのＶＣＬ ＮＡＬ単位であることを示す。１に等しいＳｕｂＬａｙｅｒＲｅｆＮａｌＵｎｉｔＦｌａｇは、サブサンプル中の全てのＮＡＬ単位が、ＩＳＯ／ＩＥＣ ２３００８−２（即ち、ＨＥＶＣ）において規定されるようなサブレイヤ参照ピクチャのＶＣＬ ＮＡＬ単位であることを示す。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、サブサンプル中の全てのＮＡＬ単位がサブレイヤ非参照ピクチャのＶＣＬ ＮＡＬ単位であるかどうかを示す追加のフラグを、サブサンプル情報ボックス３１４に含める。
[0157]ＤｉｓｃａｒｄａｂｌｅＦｌａｇ値は、サブサンプル中のＶＣＬ ＮＡＬ単位のｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇ値の値を示す。ＩＳＯ／ＩＥＣ １４４９６−１５のセクションＡ．４において規定されるように、ｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇ値は、全ての抽出されたＮＡＬ単位又は集約されたＮＡＬ単位が１に設定されたｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇを有する場合にだけ１に設定されるべきであり、それ以外の場合は０に設定されるべきである。ＮＡＬ単位は、ＮＡＬ単位を含むビットストリームがＮＡＬ単位を伴わずに正確に復号され得る場合、１に設定されたｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇを有し得る。従って、ＮＡＬ単位は、ＮＡＬ単位を含むビットストリームがＮＡＬ単位を伴わずに正確に復号され得る場合、「廃棄可能」であり得る。サブサンプル中の全てのＶＣＬ ＮＡＬ単位は、同じｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇの値を有するべきである。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、サブサンプルのＶＣＬ ＮＡＬ単位の全てが廃棄可能かどうかを示す追加のフラグ（例えば、ｄｉｓｃａｒｄａｂｌｅ＿ｆｌａｇ）を、サブサンプル情報ボックス３１４に含める。
[0158]ＮｏＩｎｔｅｒＬａｙｅｒＰｒｅｄＦｌａｇ値は、サブサンプル中のＶＣＬ ＮＡＬ単位のｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値を示す。ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、全ての抽出されたＶＣＬ ＮＡＬ単位又は集約されたＶＣＬ ＮＡＬ単位が１に設定されたｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇを有する場合にだけ１に設定されるべきであり、それ以外の場合は０に設定されるべきである。サブサンプル中の全てのＶＣＬ ＮＡＬ単位は、同じ値のｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇを有するべきである。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、レイヤ間予測がサブサンプルの全てのＶＣＬ ＮＡＬ単位に対して有効にされるかどうかを示す追加の値（例えば、ｉｎｔｅｒ＿ｌａｙｅｒ＿ｐｒｅｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）を、サブサンプル情報ボックス３１４に含める。
[0159]ＬａｙｅｒＩｄは、サブサンプル中のＮＡＬ単位のｎｕｈ＿ｌａｙｅｒ＿ｉｄの値を示す。サブサンプル中の全てのＮＡＬ単位は、同じｎｕｈ＿ｌａｙｅｒ＿ｉｄの値を有するべきである。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、サブサンプルの各ＮＡＬ単位のレイヤ識別子を示す追加の値（例えば、ＬａｙｅｒＩｄ）を、サブサンプル情報ボックス３１４に含める。
[0160]ＴｅｍｐＩｄは、サブサンプル中のＮＡＬ単位のＴｅｍｐｏｒａｌＩｄの値を示す。サブサンプル中の全てのＮＡＬ単位は、同じＴｅｍｐｏｒａｌＩｄの値を有するべきである。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、サブサンプルの各ＮＡＬ単位の時間識別子を示す追加の値（例えば、ＴｅｍｐＩｄ）を、サブサンプル情報ボックス３１４に含める。
[0161]ＶｃｌＮａｌＵｎｉｔＴｙｐｅは、サブサンプル中のＶＣＬ ＮＡＬ単位のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素を示す。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素は、ＮＡＬ単位のＮＡＬ単位ヘッダ中のシンタックス要素である。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅシンタックス要素は、ＮＡＬ単位に含まれるＲＢＳＰのタイプを指定する。サブサンプル中の全てのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ ＶＣＬ ＮＡＬ単位は、同じｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値を有するべきである。従って、ファイル生成機器３４がサブサンプル情報ボックス３１４を生成し、フラグが特定の値（例えば、５）を有するとき、ファイル生成機器３４は、サブサンプルのＶＣＬ ＮＡＬ単位のＮＡＬ単位タイプを示す追加の値（例えば、ＶｃｌＮａｌＵｎｉｔＴｙｐｅ）を、サブサンプル情報ボックス３１４に含める。サブサンプルの全てのＶＣＬ ＮＡＬ単位が、同じＮＡＬ単位タイプを有する。
[0162]図５Ｂは、本開示の１つ又は複数に技法による、ファイル３００の代替的な例示の構造を示す概念図である。図５Ｂの例では、図５Ａに示されるようにｏｉｎｆボックス３１６がサンプルグループ記述ボックス３１２に含まれる代わりに、ｏｉｎｆボックス３１６は、サンプルテーブルボックス３０９とは別個のボックスとしてメディア情報ボックス３０８に含まれる。図３Ｂにおける様々なボックスの内容及び機能は、それ以外は、図５Ａに関して説明されたものと同じであり得る。
[0163]図６は、本開示の１つ又は複数の技法による、ファイル３００の例示的な構造を示す概念図である。ＩＳＯ／ＩＥＣ １４４９６−１５のセクション８．４．９において規定されるように、ＨＥＶＣは、参照のためだけに使用され出力のために使用されないファイルフォーマットサンプルを可能にする。例えば、ＨＥＶＣは、ビデオ中の表示されない参照ピクチャを可能にする。
[0164]更に、ＩＳＯ／ＩＥＣ １４４９６−１５のセクション８．４．９は、任意のそのような非出力サンプルがトラック中に存在するときに、ファイルが次のように制約されるべきであることを規定する。
１．非出力サンプルは、出力されるサンプルの時間の範囲外の合成時間を与えられるべきである。
２．編集リストは、非出力サンプルの合成時間を除外するために使用されるべきである。
３．トラックがＣｏｍｐｏｓｉｔｉｏｎＯｆｆｓｅｔＢｏｘ（「ｃｔｔｓ」）を含むとき、
ａ． ＣｏｍｐｏｓｉｔｉｏｎＯｆｆｓｅｔＢｏｘのバージョン１が使用されるべきであり、
ｂ． ｓａｍｐｌｅ＿ｏｆｆｓｅｔの値が非出力サンプルの各々に対して−２31に等しく設定されるべきであり、
ｃ． ＣｏｍｐｏｓｉｔｉｏｎＴｏＤｅｃｏｄｅＢｏｘ（「ｃｓｌｇ」）がトラックのＳａｍｐｌｅＴａｂｌｅＢｏｘ（「ｓｔｂｌ」）に含まれるべきであり、
ｄ． ＣｏｍｐｏｓｉｔｉｏｎＴｏＤｅｃｏｄｅＢｏｘがトラックに対して存在するとき、ボックス中のｌｅａｓｔＤｅｃｏｄｅＴｏＤｉｓｐｌａｙＤｅｌｔａフィールドの値が、非出力サンプルに対するｓａｍｐｌｅ＿ｏｆｆｓｅｔ値を除くＣｏｍｐｏｓｉｔｉｏｎＯｆｆｓｅｔＢｏｘ中の最小の合成オフセットに等しくなければならない。
注意：従って、ｌｅａｓｔＤｅｃｏｄｅＴｏＤｉｓｐｌａｙＤｅｌｔａは、−２31よりも大きい。
[0165]ＩＳＯ／ＩＥＣ １４４９６−１２において規定されるように、ＣｏｍｐｏｓｉｔｉｏｎＯｆｆｓｅｔＢｏｘは、復号時間と合成時間との間のオフセットを与える。ＣｏｍｐｏｓｉｔｉｏｎＯｆｆｓｅｔＢｏｘは、ｓａｍｐｌｅ＿ｏｆｆｓｅｔ値のセットを含む。ｓａｍｐｌｅ＿ｏｆｆｓｅｔ値の各々は、合成時間と復号時間との間のオフセットを与える非負の整数である。合成時間は、サンプルが出力されるべき時間を指す。復号時間は、サンプルが復号されるべき時間を指す。
[0166]上で示されたように、被コード化スライスＮＡＬ単位は、スライスセグメントヘッダを含み得る。スライスセグメントヘッダは、被コード化スライスセグメントの一部であってよく、スライスセグメント中の最初の、又は全てのＣＴＵに関するデータ要素を含んでよい。ＨＥＶＣでは、スライスセグメントヘッダは、ｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素を含む。一般に、ｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素は、ピクチャのスライスの最初のスライスセグメントヘッダに含まれる。従って、本開示は、ピクチャのスライスの最初のスライスセグメントヘッダのｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを、ピクチャのｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇと呼ぶことがある。
[0167]ＨＥＶＣ ＷＤのセクション７．４．７．１において規定されるように、ｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素は、ＨＥＶＣ ＷＤのＡｎｎｅｘ Ｃにおいて規定されるような復号されたピクチャの出力及び除去のプロセスに影響を与える。一般に、スライスセグメントのスライスセグメントヘッダのｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素が１である場合、スライスセグメントヘッダに対応するスライスを含むピクチャが出力される。そうではなく、スライスセグメントのスライスセグメントヘッダのｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇシンタックス要素が０である場合、スライスセグメントヘッダに対応するスライスを含むピクチャが参照ピクチャとして使用するために復号され得るが、出力はされない。
[0168]本開示の１つ又は複数の技法によれば、ＩＳＯ／ＩＥＣ １４４９６−１５のセクション８．４．９におけるＨＥＶＣへの言及は、ＳＨＶＣ、ＭＶ−ＨＥＶＣ、又は３Ｄ−ＨＥＶＣへの対応する言及と置き換えられ得る。更に、本開示の１つ又は複数の技法によれば、アクセス単位が１に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する幾つかの被コード化ピクチャと、０に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する幾つかの他の被コード化ピクチャとを含むとき、少なくとも２つのトラックがストリームを記憶するために使用されなければならない。トラックの各々のそれぞれ１つに対して、それぞれのトラックの各サンプル中の全ての被コード化ピクチャは、同じ値のｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する。従って、トラックのうちの最初のものの中の全ての被コード化ピクチャは０に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有し、トラックのうちの２番目のもの中の全ての被コード化ピクチャは１に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する。
[0169]従って、図６の例では、ファイル生成機器３４はファイル４００を生成することができる。図５Ａの例におけるファイル３００と同様に、ファイル４００は、ムービーボックス４０２と、１つ又は複数のメディアデータボックス４０４とを含む。メディアデータボックス４０４の各々は、ファイル４００の異なるトラックに対応し得る。ムービーボックス４０２は、ファイル４００のトラックのためのメタデータを含み得る。ファイル４００の各トラックは、メディアデータの連続的なストリームを備え得る。メディアデータボックス４０４の各々は、１つ又は複数のサンプル４０５を含み得る。サンプル４０５の各々は、オーディオ又はビデオアクセス単位を備え得る。
[0170]上で示されたように、幾つかの例では、アクセス単位が１に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する幾つかの被コード化ピクチャと、０に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する幾つかの他の被コード化ピクチャとを含むとき、少なくとも２つのトラックがストリームを記憶するために使用されなければならない。従って、図６の例では、ムービーボックス４０２は、トラックボックス４０６とトラックボックス４０８とを含む。トラックボックス４０６及び４０８の各々は、ファイル４００の異なるトラックのためのメタデータを封入する。例えば、トラックボックス４０６は、０に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する被コード化ピクチャを有し１に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有するピクチャを有しない、トラックのためのメタデータを封入し得る。トラックボックス４０８は、１に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有する被コード化ピクチャを有し０に等しいｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇを有するピクチャを有しない、トラックのためのメタデータを封入し得る。
[0171]従って、一例では、ファイル生成機器３４は、メディアコンテンツを封入する（例えば、備える）メディアデータボックス（例えば、メディアデータボックス４０４）を備えるファイル（例えば、ファイル４００）を生成することができる。メディアコンテンツは、サンプルのシーケンスを備える（例えば、サンプル４０５）。サンプルの各々は、マルチレイヤビデオデータのアクセス単位であり得る。この例では、ファイル生成機器３４がファイルを生成するとき、ビットストリームの少なくとも１つのアクセス単位が１に等しいピクチャ出力フラグを有する被コード化ピクチャと０に等しいピクチャ出力フラグを有する被コード化ピクチャとを含むという決定に応答して、ファイル生成機器３４は、ファイルにビットストリームを記憶するために少なくとも２つのトラックを使用することができる。少なくとも２つのトラックからの各々のそれぞれのトラックに対して、それぞれのトラックの各サンプル中の全ての被コード化ピクチャは、同じ値のピクチャ出力フラグを有する。１に等しいピクチャ出力フラグを有するピクチャは、出力されることが許可され、０に等しいピクチャ出力フラグを有するピクチャは、参照ピクチャとして使用されることが許可されるが、出力されることは許可されない。
[0172]図７は、本開示の１つ又は複数の技法による、ファイル生成機器３４の例示的な動作を示すフローチャートである。本開示の他のフローチャートに示される動作とともに、図７の動作は例である。本開示の技法による他の例示的な動作は、より多数の、より少数の、又は異なる活動を含み得る。
[0173]図７の例では、ファイル生成機器３４はファイルを生成する。ファイルを生成することの一部として、ファイル生成機器３４は、マルチレイヤビデオデータを取得し（１７０）、マルチレイヤビデオデータをあるファイルフォーマットで記憶する（１７２）。ファイル生成機器３４は、そのファイルフォーマットのｏｉｎｆボックスに、マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶する（１７４）。ファイル生成機器３４は、そのファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成する（１７６）。表現フォーマット情報は、空間分解能、ビット深度又は色フォーマットの１つ又は複数を含み得る。ファイル生成機器３４は追加で、又は代替的に、そのファイルフォーマットのｏｉｎｆボックスにマルチレイヤビデオデータの各動作点のためのビットレート情報を記憶することがあり、及び／又は、そのファイルフォーマットの構成ボックスの後でビットレートボックスを信号伝達しないことがある。ファイル生成機器３４は追加で、又は代替的に、プロファイル、ティア、及びレベル（ＰＴＬ）情報と、表現フォーマット情報と、フレームレート情報とを、そのファイルフォーマットのデコーダ構成記録に記憶し、デコーダ構成記録中の全ての他の情報をトラック中のマルチレイヤビデオデータの全てのレイヤと関連付け得る。ファイル生成機器３４は加えて、又は代替的に、ファイルフォーマットのｏｉｎｆボックスにレイヤカウントを記憶することがあり、レイヤカウントはマルチレイヤビデオデータの動作点の幾つかの必要なレイヤを示す。
[0174]ｏｉｎｆボックスはメディア情報ボックスに含まれることがあり、ｏｉｎｆボックスはサンプルグループ記述ボックスに含まれることがある。サンプルグループ記述ボックスはサンプルテーブルボックスに含まれることがあり、サンプルテーブルボックスはメディア情報ボックスに含まれることがある。
[0175]ファイル生成機器３４は、表現フォーマット情報とフレームレート情報とを、マルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶し得る。ファイル生成機器３４は追加で、又は代替的に、パラレリズム情報をマルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶し得る。ファイル生成機器３４は、そのファイルフォーマットのデコーダ構成記録に動作点インデックスを記憶しないことがある。ファイル生成機器３４は、追加的に、又は代替的に、そのファイルフォーマットのデコーダ構成記録中のマルチレイヤビデオデータのトラックと関連する動作点インデックスのリストを記憶し得る。
[0176]図８は、宛先機器１４、後処理エンティティ２７又はネットワークエンティティ２９などの、ファイル読取り機器の例示的な動作を示すフローチャートである。本開示の他のフローチャートに示される動作とともに、図８の動作は例である。本開示の技法による他の例示的な動作は、より多数の、より少数の、又は異なる活動を含み得る。
[0177]図８の例では、ファイル読取り機器は、あるファイルフォーマットに従ってフォーマットされたマルチレイヤビデオデータのファイルを取得する（１８０）。ファイル読取り機器は、そのファイルフォーマットに対して、そのファイルフォーマットのためのｏｉｎｆボックス中のマルチレイヤビデオデータの各動作点のための表現フォーマット情報を決定する（１８２）。ファイル読取り機器は、場合によってはビデオデコーダ３０などのビデオデコーダとともに、決定された表現フォーマット情報に基づいてマルチレイヤビデオデータを復号する（１８４）。
[0178]１つ又は複数の例において、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は１つ又は複数の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、又はコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、又は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形のコンピュータ可読記憶媒体、又は（２）信号若しくは搬送波のような通信媒体に対応し得る。データ記憶媒体は、本開示で説明される技法の実施のための命令、コード及び／又はデータ構造を取り出すために、１つ又は複数のコンピュータ又は１つ又は複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0179]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭ若しくは他の光ディスクストレージ、磁気ディスクストレージ若しくは他の磁気ストレージ機器、フラッシュメモリ、又は、命令又はデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、任意の接続が、コンピュータ可読媒体と適切に呼ばれる。例えば、命令が、ウェブサイト、サーバ、又は他の遠隔発信源から、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線、及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時的媒体を含まないが、代わりに、非一時的な有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）、及びブルーレイディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上の組合せも、コンピュータ可読媒体の範囲の中に含まれるべきである。
[0180]命令は、１つ又は複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、又は他の等価な集積回路又はディスクリート論理回路のような、１つ又は複数のプロセッサによって実行され得る。従って、本明細書で使用される「プロセッサ」という用語は、前述の構造のいずれか又は本明細書で説明された技法の実装に適切な任意の他の構造を指し得る。加えて、幾つかの態様では、本明細書で説明された機能は、符号化及び復号のために構成されるか、又は複合コーデックに組み込まれる、専用のハードウェアモジュール及び／又はソフトウェアモジュール内で提供され得る。また、本技法は、１つ又は複数の回路又は論理素子において完全に実装され得る。
[0181]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）又はＩＣのセット（例えば、チップセット）を含む、多種多様な機器又は装置で実装され得る。様々なコンポーネント、モジュール、又はユニットは、開示されている技術を実行するように構成された機器の機能的態様を強調するように本開示において説明されているが、異なるハードウェアユニットによる実現を必ずしも必要としない。そうではなく、上で説明されたように、様々なユニットは、コーデックハードウェアユニット中で組み合わせられるか、又は上で説明された１つ又は複数のプロセッサを含む、適切なソフトウェア及び／又はファームウェアとともに相互動作可能なハードウェアユニットの集合体によって提供され得る。
[0182]様々な例が、説明された。これら及び他の例は、以下の特許請求の範囲に含まれる。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
マルチレイヤビデオデータを処理する方法であって、
前記マルチレイヤビデオデータを取得することと、
前記マルチレイヤビデオデータをあるファイルフォーマットで記憶することと、
前記ファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶することと、
前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成することとを備える、方法。
［Ｃ２］
前記表現フォーマット情報が、空間分解能、ビット深度又は色フォーマットの１つ以上を備える、Ｃ１に記載の方法。
［Ｃ３］
前記ファイルフォーマットの前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のためのビットレート情報を記憶することと、
前記ファイルフォーマットの構成ボックスの後でビットレートボックスを信号伝達しないこととを更に備える、Ｃ１に記載の方法。
［Ｃ４］
プロファイル、ティア、及びレベル（ＰＴＬ）情報と、表現フォーマット情報と、フレームレート情報とを、前記ファイルフォーマットのデコーダ構成記録に記憶しないことと、
前記デコーダ構成記録中の全ての他の情報を、トラック中の前記マルチレイヤビデオデータの全てのレイヤと関連付けることとを更に備える、Ｃ１に記載の方法。
［Ｃ５］
表現フォーマット情報とフレームレート情報とを、前記マルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶することを更に備える、Ｃ１に記載の方法。
［Ｃ６］
パラレリズム情報を前記マルチレイヤビデオデータの各レイヤのための前記デコーダ構成記録に記憶することを更に備える、Ｃ５に記載の方法。
［Ｃ７］
前記ファイルフォーマットのデコーダ構成記録に動作点インデックスを記憶しないことを更に備える、Ｃ１に記載の方法。
［Ｃ８］
前記ファイルフォーマットのデコーダ構成記録中の前記マルチレイヤビデオデータのトラックを関連する動作点インデックスのリストを記憶することを更に備える、Ｃ１に記載の方法。
［Ｃ９］
前記ファイルフォーマットの前記ｏｉｎｆボックスにレイヤカウントを記憶することを更に備え、前記レイヤカウントが前記マルチレイヤビデオデータの動作点の幾つかの必要なレイヤを示す、Ｃ１に記載の方法。
［Ｃ１０］
前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、Ｃ１に記載の方法。
［Ｃ１１］
前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、Ｃ１０に記載の方法。
［Ｃ１２］
前記マルチレイヤビデオデータの各動作点が、それぞれ、別のビットストリームを用いたサブビットストリーム抽出プロセスの動作によって、前記別のビットストリームから作成されるビットストリームを備える、Ｃ１に記載の方法。
［Ｃ１３］
マルチレイヤビデオデータを処理するためのビデオ機器であって、
前記マルチレイヤビデオデータを記憶するように構成されるデータ記憶媒体と、
１つ以上のプロセッサを備え、前記１つ以上のプロセッサが、
前記マルチレイヤビデオデータを取得し、
前記マルチレイヤビデオデータをあるファイルフォーマットで記憶し、
前記ファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶し、
前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成する
ように構成される、ビデオ機器。
［Ｃ１４］
前記表現フォーマット情報が、空間分解能、ビット深度、又は色フォーマットの１つ以上を備える、Ｃ１３に記載の機器。
［Ｃ１５］
前記１つ以上のプロセッサが更に、
前記ファイルフォーマットの前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のためのビットレート情報を記憶し、
前記ファイルフォーマットの構成ボックスの後でビットレートボックスを信号伝達しないように構成される、Ｃ１３に記載の機器。
［Ｃ１６］
前記１つ以上のプロセッサが更に、
プロファイル、ティア及びレベル（ＰＴＬ）情報と、表現フォーマット情報と、フレームレート情報とを、前記ファイルフォーマットのデコーダ構成記録に記憶せず、
前記デコーダ構成記録中の全ての他の情報を、トラック中の前記マルチレイヤビデオデータの全てのレイヤと関連付けるように構成される、Ｃ１３に記載の機器。
［Ｃ１７］
前記１つ以上のプロセッサが更に、
表現フォーマット情報とフレームレート情報とを、前記マルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶するように構成される、Ｃ１３に記載の機器。
［Ｃ１８］
前記１つ以上のプロセッサが更に、
パラレリズム情報を前記マルチレイヤビデオデータの各レイヤのための前記デコーダ構成記録に記憶するように構成される、Ｃ１７に記載の機器。
［Ｃ１９］
前記１つ以上のプロセッサが更に、
前記ファイルフォーマットのデコーダ構成記録に動作点インデックスを記憶しないように構成される、Ｃ１３に記載の機器。
［Ｃ２０］
前記１つ以上のプロセッサが更に、
前記ファイルフォーマットのデコーダ構成記録中の前記マルチレイヤビデオデータのトラックと関連する動作点インデックスのリストを記憶するように構成される、Ｃ１３に記載の機器。
［Ｃ２１］
前記１つ以上のプロセッサが更に、
前記ファイルフォーマットの前記ｏｉｎｆボックスにレイヤカウントを記憶するように構成され、前記レイヤカウントが前記マルチレイヤビデオデータの動作点の幾つかの必要なレイヤを示す、Ｃ１３に記載の機器。
［Ｃ２２］
前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、Ｃ１３に記載の機器。
［Ｃ２３］
前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、Ｃ２２に記載の機器。
［Ｃ２４］
前記マルチレイヤビデオデータの各動作点が、それぞれ、別のビットストリームを用いたサブビットストリーム抽出プロセスの動作によって、前記別のビットストリームから作成されるビットストリームを備える、Ｃ１３に記載の機器。
［Ｃ２５］
マルチレイヤビデオデータを処理するためのビデオ機器であって、
前記マルチレイヤビデオデータを取得するための手段と、
前記マルチレイヤビデオデータをあるファイルフォーマットで記憶するための手段と、
前記ファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶するための手段と、
前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成するための手段とを備える、ビデオ機器。
［Ｃ２６］
前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、Ｃ２５に記載の機器。
［Ｃ２７］
前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、Ｃ２６に記載の機器。
［Ｃ２８］
命令を記憶するコンピュータ可読記憶媒体であって、前記前記命令が、実行されると、１つ以上のプロセッサに、
マルチレイヤビデオデータを取得させ、
前記マルチレイヤビデオデータをあるファイルフォーマットで記憶させ、
前記ファイルフォーマットのための動作点情報（ｏｉｎｆ）ボックスへ、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶させ、
前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成させる、コンピュータ可読記憶媒体。
［Ｃ２９］
前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、Ｃ２８に記載のコンピュータ可読記憶媒体。
［Ｃ３０］
前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、Ｃ２９に記載のコンピュータ可読記憶媒体。

Claims (28)

  1. マルチレイヤビデオデータを処理する方法であって、
    ２つ以上の動作点を備えるマルチレイヤビデオデータを取得することと、
    前記マルチレイヤビデオデータをあるファイルフォーマットで記憶することと、ここにおいて、前記ファイルフォーマットが、前記マルチレイヤビデオデータに含まれる前記動作点を識別する動作点情報（ｏｉｎｆ）ボックスを含む、
    前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶することと、ここにおいて、前記表現フォーマット情報が、空間分解能、ビット深度、又は色フォーマットの１つ以上を備える、
    前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成することと
    を備える、方法。
  2. 前記ファイルフォーマットの前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のためのビットレート情報を記憶することと、
    前記ファイルフォーマットの構成ボックスの後でビットレートボックスを信号伝達しないことと
    を更に備える、請求項１に記載の方法。
  3. プロファイル、ティア、及びレベル（ＰＴＬ）情報と、表現フォーマット情報と、フレームレート情報とを、前記ファイルフォーマットのデコーダ構成記録に記憶しないことと、
    前記デコーダ構成記録中の全ての情報を、トラック中の前記マルチレイヤビデオデータの全てのレイヤと関連付けることと
    を更に備える、請求項１に記載の方法。
  4. 表現フォーマット情報とフレームレート情報とを、前記マルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶することを更に備える、請求項１に記載の方法。
  5. パラレリズム情報を前記マルチレイヤビデオデータの各レイヤのための前記デコーダ構成記録に記憶することを更に備える、請求項４に記載の方法。
  6. 前記ファイルフォーマットのデコーダ構成記録に動作点インデックスを記憶しないことを更に備える、請求項１に記載の方法。
  7. 前記ファイルフォーマットのデコーダ構成記録に前記マルチレイヤビデオデータのトラックと関連する動作点インデックスのリストを記憶することを更に備える、請求項１に記載の方法。
  8. 前記ファイルフォーマットの前記ｏｉｎｆボックスにレイヤカウントを記憶することを更に備え、前記レイヤカウントが前記マルチレイヤビデオデータの動作点の必要なレイヤの数を示す、請求項１に記載の方法。
  9. 前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、請求項１に記載の方法。
  10. 前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、請求項９に記載の方法。
  11. 前記マルチレイヤビデオデータの各動作点が、それぞれ、別のビットストリームを用いたサブビットストリーム抽出プロセスの動作によって、前記別のビットストリームから作成されるビットストリームを備える、請求項１に記載の方法。
  12. マルチレイヤビデオデータを処理するためのビデオ機器であって、
    前記マルチレイヤビデオデータを記憶するように構成されるデータ記憶媒体と、
    １つ以上のプロセッサを備え、前記１つ以上のプロセッサが、
    ２つ以上の動作点を備えるマルチレイヤビデオデータを取得し、
    前記マルチレイヤビデオデータをあるファイルフォーマットで記憶し、ここにおいて、前記ファイルフォーマットが、前記マルチレイヤビデオデータに含まれる前記動作点を識別する動作点情報（ｏｉｎｆ）ボックスを含む、
    前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶し、ここにおいて、前記表現フォーマット情報が、空間分解能、ビット深度、又は色フォーマットの１つ以上を備える、
    前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成する
    ように構成される、ビデオ機器。
  13. 前記１つ以上のプロセッサが更に、
    前記ファイルフォーマットの前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のためのビットレート情報を記憶し、
    前記ファイルフォーマットの構成ボックスの後でビットレートボックスを信号伝達しない
    ように構成される、請求項１２に記載の機器。
  14. 前記１つ以上のプロセッサが更に、
    プロファイル、ティア、及びレベル（ＰＴＬ）情報と、表現フォーマット情報と、フレームレート情報とを、前記ファイルフォーマットのデコーダ構成記録に記憶せず、
    前記デコーダ構成記録中の全ての情報を、トラック中の前記マルチレイヤビデオデータの全てのレイヤと関連付ける
    ように構成される、請求項１２に記載の機器。
  15. 前記１つ以上のプロセッサが更に、
    表現フォーマット情報とフレームレート情報とを、前記マルチレイヤビデオデータの各レイヤのためのデコーダ構成記録に記憶するように構成される、請求項１２に記載の機器。
  16. 前記１つ以上のプロセッサが更に、
    パラレリズム情報を前記マルチレイヤビデオデータの各レイヤのための前記デコーダ構成記録に記憶するように構成される、請求項１５に記載の機器。
  17. 前記１つ以上のプロセッサが更に、
    前記ファイルフォーマットのデコーダ構成記録に動作点インデックスを記憶しないように構成される、請求項１２に記載の機器。
  18. 前記１つ以上のプロセッサが更に、
    前記ファイルフォーマットのデコーダ構成記録に前記マルチレイヤビデオデータのトラックと関連する動作点インデックスのリストを記憶するように構成される、請求項１２に記載の機器。
  19. 前記１つ以上のプロセッサが更に、
    前記ファイルフォーマットの前記ｏｉｎｆボックスにレイヤカウントを記憶するように構成され、前記レイヤカウントが前記マルチレイヤビデオデータの動作点の必要なレイヤの数を示す、請求項１２に記載の機器。
  20. 前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、請求項１２に記載の機器。
  21. 前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、請求項２０に記載の機器。
  22. 前記マルチレイヤビデオデータの各動作点が、それぞれ、別のビットストリームを用いたサブビットストリーム抽出プロセスの動作によって、前記別のビットストリームから作成されるビットストリームを備える、請求項１２に記載の機器。
  23. マルチレイヤビデオデータを処理するためのビデオ機器であって、
    ２つ以上の動作点を備えるマルチレイヤビデオデータを取得するための手段と、
    前記マルチレイヤビデオデータをあるファイルフォーマットで記憶するための手段と、ここにおいて、前記ファイルフォーマットが、前記マルチレイヤビデオデータに含まれる前記動作点を識別する動作点情報（ｏｉｎｆ）ボックスを含む、
    前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶するための手段と、ここにおいて、前記表現フォーマット情報が、空間分解能、ビット深度、又は色フォーマットの１つ以上を備える、
    前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成するための手段と
    を備える、ビデオ機器。
  24. 前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、請求項２３に記載の機器。
  25. 前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、請求項２４に記載の機器。
  26. 命令を記憶する非一時的コンピュータ可読記憶媒体であって、前記命令が、実行されると、１つ以上のプロセッサに、
    ２つ以上の動作点を備えるマルチレイヤビデオデータを取得させ、
    前記マルチレイヤビデオデータをあるファイルフォーマットで記憶させ、ここにおいて、前記ファイルフォーマットが、前記マルチレイヤビデオデータに含まれる前記動作点を識別する動作点情報（ｏｉｎｆ）ボックスを含む、
    前記ｏｉｎｆボックスに、前記マルチレイヤビデオデータの各動作点のための表現フォーマット情報を記憶させ、ここにおいて、前記表現フォーマット情報が、空間分解能、ビット深度、又は色フォーマットの１つ以上を備える、
    前記ファイルフォーマットに従ってフォーマットされたビデオデータのファイルを生成させる、
    非一時的コンピュータ可読記憶媒体。
  27. 前記ｏｉｎｆボックスがメディア情報ボックスに含まれる、請求項２６に記載の非一時的コンピュータ可読記憶媒体。
  28. 前記ｏｉｎｆボックスが更にサンプルグループ記述ボックスに含まれ、前記サンプルグループ記述ボックスがサンプルテーブルボックスに含まれ、前記サンプルテーブルボックスが前記メディア情報ボックスに含まれる、請求項２７に記載の非一時的コンピュータ可読記憶媒体。
JP2017541910A 2015-02-11 2016-02-10 階層化されたビデオファイルフォーマットにおけるサンプルエントリー及び動作点信号伝達の設計 Active JP6542378B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562115075P 2015-02-11 2015-02-11
US62/115,075 2015-02-11
US15/019,634 US10148969B2 (en) 2015-02-11 2016-02-09 Of sample entry and operation point signalling in a layered video file format
US15/019,634 2016-02-09
PCT/US2016/017280 WO2016130635A1 (en) 2015-02-11 2016-02-10 Design of sample entry and operation point signalling in a layered video file format

Publications (3)

Publication Number Publication Date
JP2018511208A JP2018511208A (ja) 2018-04-19
JP2018511208A5 JP2018511208A5 (ja) 2019-03-07
JP6542378B2 true JP6542378B2 (ja) 2019-07-10

Family

ID=56567245

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017541910A Active JP6542378B2 (ja) 2015-02-11 2016-02-10 階層化されたビデオファイルフォーマットにおけるサンプルエントリー及び動作点信号伝達の設計

Country Status (21)

Country Link
US (2) US10148969B2 (ja)
EP (1) EP3257250B1 (ja)
JP (1) JP6542378B2 (ja)
KR (1) KR102040383B1 (ja)
CN (1) CN107211168B (ja)
AU (1) AU2016219441B2 (ja)
BR (1) BR112017017307B1 (ja)
CA (1) CA2973376C (ja)
CL (1) CL2017002016A1 (ja)
CO (1) CO2017008026A2 (ja)
EA (1) EA035924B1 (ja)
ES (1) ES2902675T3 (ja)
MX (1) MX365155B (ja)
MY (1) MY181352A (ja)
NZ (2) NZ733479A (ja)
PH (1) PH12017501245A1 (ja)
SG (2) SG10201907302PA (ja)
TN (1) TN2017000305A1 (ja)
TW (2) TW201946473A (ja)
WO (1) WO2016130635A1 (ja)
ZA (1) ZA201705086B (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9648348B2 (en) * 2013-10-23 2017-05-09 Qualcomm Incorporated Multi-layer video file format designs
EP3148200B1 (en) * 2014-06-30 2020-06-17 Sony Corporation Information processing device and method selecting content files based on encoding parallelism type
US10148969B2 (en) * 2015-02-11 2018-12-04 Qualcomm Incorporated Of sample entry and operation point signalling in a layered video file format
US20180213216A1 (en) * 2015-06-16 2018-07-26 Lg Electronics Inc. Media data transmission device, media data reception device, media data transmission method, and media data rececption method
US10623755B2 (en) * 2016-05-23 2020-04-14 Qualcomm Incorporated End of sequence and end of bitstream NAL units in separate file tracks
CN108650481B (zh) * 2018-04-19 2021-08-10 北京软通智慧城市科技有限公司 一种视频流数据的存储方法及装置
JP7273193B2 (ja) * 2019-05-12 2023-05-12 北京字節跳動網絡技術有限公司 参照ピクチャ再サンプリングのための信号通知
CN114208173A (zh) * 2019-07-03 2022-03-18 华为技术有限公司 参考图像列表中参考图像的类型
WO2021134019A1 (en) 2019-12-26 2021-07-01 Bytedance Inc. Constraints on coding of layered video
KR20220115958A (ko) 2019-12-26 2022-08-19 바이트댄스 아이엔씨 코딩된 비트스트림들에서의 비디오 계층들의 시그널링에 대한 제약들
WO2021134055A1 (en) 2019-12-27 2021-07-01 Bytedance Inc. Subpicture signaling in parameter sets
CN115004669A (zh) 2020-01-09 2022-09-02 字节跳动有限公司 不同sei消息的解码顺序
EP4131969A4 (en) * 2020-03-30 2024-03-13 Lg Electronics Inc IMAGE CODING/DECODING METHOD AND APPARATUS FOR SIGNALING PTL RELATED INFORMATION AND COMPUTER READABLE RECORDING MEDIUM HAVING BIT STREAM STORED THEREIN
EP4128810A1 (en) * 2020-04-03 2023-02-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. File format concepts for video coding
CA3181101A1 (en) 2020-06-02 2021-12-09 Bytedance Inc. Signaling of general constrain information
KR20230023708A (ko) * 2020-06-03 2023-02-17 엘지전자 주식회사 영상/비디오 코딩 시스템에서 상위 레벨 신택스를 처리하는 방법 및 장치
JPWO2021251173A1 (ja) * 2020-06-12 2021-12-16
US20230336761A1 (en) * 2020-09-16 2023-10-19 Lg Electronics Inc. Method for processing media file and device therefor
US11729427B2 (en) 2020-09-17 2023-08-15 Lemon Inc. Chroma format and bit depth indication in coded video
US11711518B2 (en) 2020-09-17 2023-07-25 Lemon Inc. Decoding capability information storage in video coding
US20230388508A1 (en) * 2020-09-29 2023-11-30 Lg Electronics Inc. Method and device for generating media file
WO2022139261A1 (ko) * 2020-12-21 2022-06-30 엘지전자 주식회사 미디어 파일 처리 방법 및 장치
GB2605965A (en) * 2021-04-16 2022-10-26 Canon Kk Methods and devices for improving storage and transmission of uncompressed data while using a standard format

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7535383B2 (en) * 2006-07-10 2009-05-19 Sharp Laboratories Of America Inc. Methods and systems for signaling multi-layer bitstream data
EP2080383A4 (en) 2006-10-20 2009-12-09 Nokia Corp GENERIC INDICATION OF ADJUSTMENT GUIDE FOR SCALABLE MULTIMEDIA
US20100250763A1 (en) * 2009-03-31 2010-09-30 Nokia Corporation Method and Apparatus for Transmitting Information on Operation Points
CN101924944B (zh) * 2009-06-15 2013-06-05 华为技术有限公司 可伸缩视频编码操作点选择方法、信息提供方法及设备
US9185439B2 (en) * 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US8930562B2 (en) * 2010-07-20 2015-01-06 Qualcomm Incorporated Arranging sub-track fragments for streaming video data
TWI606718B (zh) * 2012-01-03 2017-11-21 杜比實驗室特許公司 規定視覺動態範圍編碼操作及參數
US9451252B2 (en) * 2012-01-14 2016-09-20 Qualcomm Incorporated Coding parameter sets and NAL unit headers for video coding
SG11201406493RA (en) * 2012-04-13 2014-11-27 Ge Video Compression Llc Low delay picture coding
US9161004B2 (en) * 2012-04-25 2015-10-13 Qualcomm Incorporated Identifying parameter sets in video files
US9716892B2 (en) * 2012-07-02 2017-07-25 Qualcomm Incorporated Video parameter set including session negotiation information
US9912941B2 (en) * 2012-07-02 2018-03-06 Sony Corporation Video coding system with temporal layers and method of operation thereof
US10110890B2 (en) * 2012-07-02 2018-10-23 Sony Corporation Video coding system with low delay and method of operation thereof
US9774927B2 (en) * 2012-12-21 2017-09-26 Telefonaktiebolaget L M Ericsson (Publ) Multi-layer video stream decoding
US9584792B2 (en) 2013-01-04 2017-02-28 Qualcomm Incorporated Indication of current view dependency on reference view in multiview coding file format
US20140269934A1 (en) * 2013-03-15 2014-09-18 Sony Corporation Video coding system with multiple scalability and method of operation thereof
WO2015004924A1 (en) * 2013-07-10 2015-01-15 Sharp Kabushiki Kaisha Scaling list signaling and parameter sets activation
US10205954B2 (en) * 2013-10-23 2019-02-12 Qualcomm Incorporated Carriage of video coding standard extension bitstream data using MPEG-2 systems
GB2527786B (en) * 2014-07-01 2016-10-26 Canon Kk Method, device, and computer program for encapsulating HEVC layered media data
US10306269B2 (en) * 2014-10-10 2019-05-28 Qualcomm Incorporated Operation point for carriage of layered HEVC bitstream
US10148969B2 (en) * 2015-02-11 2018-12-04 Qualcomm Incorporated Of sample entry and operation point signalling in a layered video file format
GB2539462B (en) * 2015-06-16 2019-04-03 Canon Kk Obtaining media data and metadata from encapsulated bit-streams wherein operating point descriptors can be dynamically set
US20160373771A1 (en) * 2015-06-18 2016-12-22 Qualcomm Incorporated Design of tracks and operation point signaling in layered hevc file format
US10419768B2 (en) * 2016-03-30 2019-09-17 Qualcomm Incorporated Tile grouping in HEVC and L-HEVC file formats
US10536721B2 (en) * 2017-01-09 2020-01-14 Qualcomm Incorporated Restricted scheme design for video

Also Published As

Publication number Publication date
US20160234516A1 (en) 2016-08-11
KR20170115056A (ko) 2017-10-16
CN107211168B (zh) 2020-07-31
EA035924B1 (ru) 2020-09-01
NZ733479A (en) 2020-08-28
US20190075306A1 (en) 2019-03-07
TN2017000305A1 (en) 2019-01-16
CA2973376C (en) 2021-01-12
TW201946473A (zh) 2019-12-01
MY181352A (en) 2020-12-21
CL2017002016A1 (es) 2018-03-16
EP3257250B1 (en) 2021-12-08
SG11201705442YA (en) 2017-08-30
US10148969B2 (en) 2018-12-04
AU2016219441B2 (en) 2019-10-31
MX2017010275A (es) 2017-11-17
SG10201907302PA (en) 2019-09-27
ES2902675T3 (es) 2022-03-29
AU2016219441A1 (en) 2017-07-27
KR102040383B1 (ko) 2019-11-04
WO2016130635A1 (en) 2016-08-18
JP2018511208A (ja) 2018-04-19
CA2973376A1 (en) 2016-08-18
TW201705766A (zh) 2017-02-01
BR112017017307B1 (pt) 2023-10-03
MX365155B (es) 2019-05-24
EA201791565A1 (ru) 2017-12-29
TWI675588B (zh) 2019-10-21
CO2017008026A2 (es) 2018-01-31
ZA201705086B (en) 2019-02-27
NZ766662A (en) 2022-08-26
US10298938B2 (en) 2019-05-21
PH12017501245A1 (en) 2017-10-30
BR112017017307A2 (pt) 2018-04-10
CN107211168A (zh) 2017-09-26
EP3257250A1 (en) 2017-12-20

Similar Documents

Publication Publication Date Title
JP6542378B2 (ja) 階層化されたビデオファイルフォーマットにおけるサンプルエントリー及び動作点信号伝達の設計
JP6690010B2 (ja) Ｈｅｖｃおよびｌ−ｈｅｖｃファイルフォーマットにおけるタイルグループ化に対する改善
JP6559663B2 (ja) マルチレイヤビデオファイルフォーマットの設計

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190124

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190124

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20190124

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190424

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20190426

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190612

R150 Certificate of patent or registration of utility model

Ref document number: 6542378

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