特開2024-75651 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ ホアウェイ・テクノロジーズ・カンパニー・リミテッドの特許一覧

特開2024-75651マルチレイヤビデオビットストリームにおけるアクセスユニット内の混在したＩＲＡＰおよび非ＩＲＡＰピクチャのサポート

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024075651

(43)【公開日】2024-06-04

(54)【発明の名称】マルチレイヤビデオビットストリームにおけるアクセスユニット内の混在したＩＲＡＰおよび非ＩＲＡＰピクチャのサポート

(51)【国際特許分類】

H04N 19/30 20140101AFI20240528BHJP

H04N 19/70 20140101ALI20240528BHJP

【ＦＩ】

H04N19/30

H04N19/70

【審査請求】有

【請求項の数】11

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2024040716

(22)【出願日】2024-03-15

(62)【分割の表示】P 2022518690の分割

【原出願日】2020-09-16

(31)【優先権主張番号】62/905,141

(32)【優先日】2019-09-24

(33)【優先権主張国・地域又は機関】US

(71)【出願人】

【識別番号】504161984

【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド

(74)【代理人】

【識別番号】110000877

【氏名又は名称】弁理士法人ＲＹＵＫＡ国際特許事務所

(72)【発明者】

【氏名】ワン、イエ－クイ

(57)【要約】（修正有）

【課題】ビデオデコーダによって実装される復号の方法及び装置を提供する。
【解決手段】ビデオデコーダによって実装される復号の方法であって、ビデオデコーダによって、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）を含むビットストリームを受信する段階を含む。ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである。方法はまた、ビデオデコーダによって、ピクチャ順序カウント（ＰＯＣ）値に基づいて、レイヤの１つからコーディング済みピクチャを識別する段階と、ビデオデコーダによってコーディング済みピクチャを復号して復号済みピクチャを取得する段階を含む。
【選択図】なし

【特許請求の範囲】

【請求項1】

ビデオエンコーダによって実装される符号化の方法であって、
前記ビデオエンコーダによって、コーディング済みピクチャを含むピクチャユニット（ＰＵ）を、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入する段階であって、前記ビデオエンコーダは、各レイヤにおける前記コーディング済みピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約を受ける、段階と、
前記ビデオエンコーダによって、前記ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化する段階と、
前記ビデオエンコーダによって、ビデオデコーダへの通信のために前記ビットストリームを格納する段階と
を備える方法。

【請求項2】

前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、請求項１に記載の方法。

【請求項3】

前記ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである、請求項１に記載の方法。

【請求項4】

前記ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される、請求項１から３のいずれか一項に記載の方法。

【請求項5】

符号化デバイスであって、
命令を含むメモリと、
前記メモリに結合されたプロセッサであって、
コーディング済みピクチャを含むピクチャユニット（ＰＵ）をコーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入することであって、前記符号化デバイスは、前記コーディング済みピクチャが各レイヤにおいてコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約される、こと、および、
前記ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化すること
を前記符号化デバイスに行わせるために前記命令を実装するよう構成される、プロセッサと、
前記プロセッサに結合された送信機であって、前記ビットストリームをビデオデコーダへ伝送するよう構成される、送信機と
を備える符号化デバイス。

【請求項6】

前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャまたは漸次復号リフレッシュ（ＧＤＲ）ピクチャである、請求項５に記載の符号化デバイス。

【請求項7】

前記ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される、請求項５または６に記載の符号化デバイス。

【請求項8】

ビットストリームを受信するよう構成される受信機であって、前記ビットストリームは、請求項１から４のいずれか一項に記載の方法を実行することにより取得される、受信機と、
前記ビットストリームを記憶するよう構成されるメモリと、
前記受信機に結合された送信機であって、前記送信機は、前記ビットストリームをデコーダへ伝送するよう構成される、送信機と
を備えるコーディング装置。

【請求項9】

エンコーダと、
前記エンコーダと通信するデコーダとを備え、前記エンコーダは、請求項５から７のいずれか一項に記載の符号化デバイスを含む、
システム。

【請求項10】

少なくとも１つのハードウェアプロセッサにより実行されるときに、前記少なくとも１つのハードウェアプロセッサに、請求項１から４のいずれか一項に記載の方法を実行させる、オーディオコーディングのためのコンピュータ命令を記憶する非一時的コンピュータ可読記憶媒体。

【請求項11】

コンピュータに請求項１から４のいずれか一項に記載の方法を実行させるよう構成されている、記憶媒体上に格納されるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

［関連出願の相互参照］
本特許出願は、Ｙｅ－ＫｕｉＷａｎｇによって２０１９年９月２４日に出願された、「マルチレイヤビデオビットストリームにおけるアクセスユニット内の混在したＲＡＰおよび非ＩＲＡＰピクチャのサポート」と題する米国仮特許出願第６２／９０５，１４１号の利益を主張する。

【0002】

一般的に、本開示は、ビデオコーディングにおけるマルチレイヤビデオビットストリームに関する。より具体的には、本開示は、イントラランダムアクセスポイント（ＩＲＡＰ）および非ＩＲＡＰピクチャの両方を含むマルチレイヤビデオビットストリームのサポートに関する。

【背景技術】

【0003】

比較的短いビデオでさえも、その描画に必要とされるビデオデータの量は著しいものになる可能性があり、その結果、帯域幅容量の制限された通信ネットワークを介してデータをストリーミングするか、そうでなければ通信するときに困難が生じることがある。したがって、ビデオデータは概して、現代の遠隔通信ネットワークを介して通信される前に圧縮される。ビデオのサイズは、メモリリソースが限定的である場合があるので、ビデオが格納デバイス上に格納される場合にもまた問題となり得る。ビデオ圧縮デバイスは、多くの場合、ソースにおけるソフトウェアおよび／またはハードウェアを用いて、伝送または格納の前にビデオデータをコーディングし、これによりデジタルビデオイメージを表現するのに必要なデータの量を低下させる。次に、圧縮データは、デスティネーションにおいて、ビデオデータを復号するビデオ展開デバイスによって受信される。限られたネットワークリソースと高いビデオ品質への増加し続ける要求とによって、画質を全くかほとんど犠牲にすることなく圧縮比率を改善させる圧縮／展開技法の改善が望まれている。

【発明の概要】

【0004】

第１態様は、ビデオデコーダによって実装される復号の方法であって、ビデオデコーダによって、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）を含むビットストリームを受信する段階であって、ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである、段階と、ビデオデコーダによって、ピクチャ順序カウント（ＰＯＣ）値に基づいて、レイヤの１つからコーディング済みピクチャを識別する段階と、ビデオデコーダによってコーディング済みピクチャを復号して復号済みピクチャを取得する段階とを備える方法に関する。

【0005】

方法は、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0006】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＬＶＳＳピクチャがイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャであることを提供する。

【0007】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＬＶＳＳピクチャが漸次復号リフレッシュ（ＧＤＲ）ピクチャであることを提供する。

【0008】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＬＶＳＳピクチャが、ＰＵのピクチャパラメータセット（ＰＰＳ）に配置される復旧前出力無しフラグに関連付けられることを提供し、復旧前出力無しフラグは１に等しい。

【0009】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＶＳＳＡＵの各レイヤが、ビデオパラメータセット（ＶＰＳ）によって指定されることを提供する。

【0010】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＶＳＳＡＵは、コーディング済みビデオシーケンス（ＣＶＳ）の最初のＡＵであることを提供する。

【0011】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＰＵがレイヤアクセスユニットと称されることを提供する。

【0012】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＶＳＳＡＵの各レイヤがＰＵの１つを含むのでＣＶＳＳＡＵは完全ＡＵと称されることを提供する。

【0013】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、コーディング済みピクチャを復号された状態で電子デバイスのディスプレイ上に表示することを提供する。

【0014】

第２態様は、ビデオエンコーダによって実装される符号化の方法であって、ビデオエンコーダによって、コーディング済みピクチャを含むピクチャユニット（ＰＵ）を、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入する段階であって、ビデオエンコーダは、コーディング済みピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約を受ける、段階と、ビデオエンコーダによって、ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化する段階と、ビデオエンコーダによって、ビデオデコーダへの通信のためにビットストリームを格納する段階とを備える方法に関する。

【0015】

【0016】

【0017】

【0018】

【0019】

第３態様は、復号デバイスであって、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）を含むビットストリームを受信することを行うよう構成される受信機であって、ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである、受信機と、受信機に結合されたメモリであって、命令を記憶するメモリと、メモリに結合されたプロセッサであって、ピクチャ順序カウント（ＰＯＣ）値に基づいて、レイヤの１つからコーディング済みピクチャを識別すること、および、コーディング済みピクチャを復号して、復号されたピクチャを取得することを復号デバイスに行わせる命令を実行するよう構成されるプロセッサとを備える復号デバイスに関する。

【0020】

復号デバイスは、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0021】

【0022】

【0023】

【0024】

第４態様は、符号化デバイスであって、命令を含むメモリと、メモリに結合されたプロセッサであって、コーディング済みピクチャを含むピクチャユニット（ＰＵ）をコーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入することであって、符号化デバイスは、コーディング済みピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約される、こと、および、ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化することを符号化デバイスに行わせるための命令を実装するよう構成される、プロセッサと、プロセッサに結合された送信機であって、ビデオビットストリームをビデオデコーダへ伝送するよう構成される、送信機とを備える符号化デバイスに関する。

【0025】

符号化デバイスは、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0026】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、ＣＬＶＳＳピクチャがイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャまたは漸次復号リフレッシュ（ＧＤＲ）ピクチャであることを提供する。

【0027】

【0028】

第５態様はコーディング装置に関する。コーディング装置は、符号化するピクチャを受信するよう、または、復号するビットストリームを受信するよう構成される受信機と、受信機に結合された送信機であって、ビットストリームをデコーダへ送信する、または、復号されたイメージをディスプレイへ送信するよう構成される送信機と、受信機または送信機の少なくとも１に結合されたメモリであって、命令を格納するよう構成されるメモリと、メモリに結合されたプロセッサであって、メモリに格納された命令を実行し、本明細書に開示された方法のいずれかを実行するよう構成されるプロセッサとを備える。

【0029】

コーディング装置は、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0030】

任意選択で、上述の態様のいずれかにおいて、態様の別の実装は、復号済みピクチャを表示するよう構成されるディスプレイを提供する。

【0031】

第６態様はシステムに関する。システムは、エンコーダと、エンコーダと通信するデコーダとを備え、エンコーダまたはデコーダは、本明細書において開示される復号デバイス、符号化デバイス、またはコーディング装置を含む。

【0032】

システムは、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0033】

第７態様は、コーディングのための手段に関する。コーディングの手段は、符号化するピクチャを受信する、または、復号するビットストリームを受信するよう構成される受信手段と、受信手段に結合された送信手段であって、ビットストリームを復号手段へ送信するよう、または、復号済みイメージを表示手段へ送信するよう構成される送信手段と、受信手段または送信手段の少なくとも１つに結合された記憶手段であって、命令を格納するよう構成される記憶手段と、記憶手段に結合された処理手段であって、記憶手段に格納された命令を実行して、本明細書において開示される方法のいずれかを実行するよう構成される、処理手段とを備える。

【0034】

コーディングの手段は、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法を提供する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0035】

明確にすることを目的に、前述の実施形態のうちのいずれか１つは、本開示の範囲内の新たな実施形態を作成するために、その他の前述の実施形態のうちの任意の１または複数と組み合わされてよい。

【0036】

これらの特徴および他の特徴は、添付図面および特許請求の範囲と共に、以下の詳細な説明からより明確に理解されるであろう。

【図面の簡単な説明】

【0037】

本開示のより完全な理解のために、添付図面および詳細な説明と関連した以下の簡単な説明についてここで参照し、類似の参照番号は類似の部分を表す。

【0038】

【図1】ビデオ信号をコーディングする例示的な方法のフローチャートである。

【0039】

【図2】ビデオコーディングに関する例示的なコーディングおよび復号（コーデック）システムの概略図である。

【0040】

【図3】例示的なビデオエンコーダを示す概略図である。

【0041】

【図4】例示的なビデオデコーダを示す概略図である。

【0042】

【図5】空間的スケーラビリティのマルチレイヤコーディングに関する例を示す。

【0043】

【図6】復号順序および提示順序における、リーディングピクチャと相対的なＩＲＡＰピクチャとトレーリングピクチャとの間の関係の表現である。

【0044】

【図7】漸次復号リフレッシュ（ＧＤＲ）技法を実装するよう構成されるビデオビットストリームを示す。

【0045】

【図8】ＧＤＲをサポートするためにエンコーダ制約を使用するときの望ましくない動き検索を示す概略図である。

【0046】

【図9】ビデオビットストリームの実施形態を示す。

【0047】

【図10】コーディング済みビデオビットストリームを復号する方法の実施形態である。

【0048】

【図11】コーディング済みビデオビットストリームを符号化する方法の実施形態である。

【0049】

【図12】ビデオコーディングデバイスの概略図である。

【0050】

【図13】コーディングのための手段の実施形態の概略図である。

【発明を実施するための形態】

【0051】

１または複数の実施形態に係る例示的な実装態様が以下に提供されるが、開示されたシステムおよび／または方法は、現時点で知られているのかまたは存在しているのかに関係なく、任意の数の技法を使用して実装されてよいことを最初に理解されたい。本開示は、本明細書において図示され説明される例示的な設計例および実装形態を含む、以下に示される例示的な実装、図面、および技法に決して限定されるべきではなく、添付の特許請求の範囲と共に、その均等物の全範囲内で修正されてよい。

【0052】

以下に挙げる用語は、本明細書と反対の文脈で用いられない限り、以下のように定義される。具体的には、次の定義は、本開示に追加の明確性を提供するように意図される。しかしながら、用語は、異なる文脈においては異なるように説明されることがある。それに応じて、次の定義は、補足とみなされるべきであり、本明細書のそのような用語に関して提供された説明のいかなる他の定義を限定するようにもみなされるべきではない。

【0053】

ビットストリームとは、エンコーダとデコーダとの間で送信するために圧縮されたビデオデータを含むビットのシーケンスである。エンコーダとは、符号化処理を利用し、ビデオデータを圧縮してビットストリームにするように構成されたデバイスである。デコーダとは、復号処理を利用し、表示のためにビットストリームをビデオデータに再構築するように構成されたデバイスである。ピクチャとは、フレームもしくはそのフィールドを作るルマサンプルの配列および／またはクロマサンプルの配列である。説明を明確にするために、符号化または復号されているピクチャは、現ピクチャと称され得る。参照ピクチャは、インター予測および／またはインターレイヤ予測に従って参照により他のピクチャをコーディングするときに使用され得る参照サンプルを含むピクチャである。参照ピクチャリストとは、インター予測および／またはインターレイヤ予測に用いられる参照ピクチャのリストである。一部のビデオコーディングシステムでは２つの参照ピクチャリストを利用し、これらのリストは参照ピクチャリスト１および参照ピクチャリスト０として表され得る。参照ピクチャリスト構造とは、複数の参照ピクチャリストを含むアドレス指定可能なシンタックス構造である。インター予測とは、現ピクチャと異なる参照ピクチャ内の示されたサンプルを参照することにより現ピクチャのサンプルをコーディングする機構であり、参照ピクチャおよび現ピクチャは同一のレイヤにある。参照ピクチャリスト構造エントリは、参照ピクチャリストに関連付けられた参照ピクチャを示す参照ピクチャリスト構造におけるアドレス指定可能な場所である。スライスヘッダは、スライスにおいて表されるタイル内のすべてのビデオデータに関連するデータ要素を含む、コーディング済みスライスの一部である。シーケンスパラメータセット（ＳＰＳ）は、ピクチャのシーケンスに関するデータを含むパラメータセットである。ピクチャパラメータセット（ＰＰＳ）は、各ピクチャヘッダにおいて見られるシンタックス要素によって決定される、０またはより多くのコーディング済みピクチャ全体に適用するシンタックス要素を含むシンタックス構造である。

【0054】

ビデオパラメータセット（ＶＰＳ）は、拡張レイヤの参照ピクチャセット構成についての復号依存性または情報を含む。ＶＰＳは、何のタイプのオペレーションポイントが提供されるか、オペレーションポイントのプロファイル、ティア、およびレベル、ならびに、セッションネゴシエーションおよびコンテンツ選択の基礎として使用され得るビットストリームのいくつかの他の高レベル特性などを含む、スケーラブルシーケンスの全体的な視点または表示を提供する。

【0055】

フラグは、２つの可能な値０および１のうち１つをとり得る変数または単一ビットのシンタックス要素である。アクセスユニット（ＡＵ）とは、復号ピクチャバッファ（ＤＰＢ）から出力するために（例えば、ユーザに表示するために）、同じ表示時間（例えば、同じピクチャ順序カウント）と関連付けられた１または複数のコーディング済みピクチャのセットである。アクセスユニットデリミタ（ＡＵＤ）は、ＡＵの開始またはＡＵ間の境界を示すために使用されるインジケータまたはデータ構造である。復号されたビデオシーケンスとは、ユーザへの表示に備えてデコーダにより再構築されたピクチャのシーケンスである。

【0056】

コーディング済みビデオシーケンス（ＣＶＳ）は、復号順序で、コーディング済みビデオシーケンス開始（ＣＶＳＳ）ＡＵ、および、それに続く、ＣＶＳＳＡＵである任意の後続のＡＵまで（ただしそれを含まない）のすべての後続のＡＵを含むＣＶＳＳＡＵでない０またはより多くのＡＵを含むアクセスユニット（ＡＵ）のシーケンスである。ＣＶＳＳＡＵは、ビデオパラメータセット（ＶＰＳ）によって指定される各レイヤについて予測ユニット（ＰＵ）があり、かつ、各ＰＵにおけるコーディング済みピクチャが、コーディング済みレイヤビデオ開始シーケンス（ＣＬＶＳＳ）ピクチャであるＡＵである。実施形態において、各ピクチャはＡＵ内にある。ＰＵは、指定された分類規則に従って互いに関連付けられたネットワーク抽象化レイヤ（ＮＡＬ）ユニットのセットであり、復号の順序で連続し、厳密に１つのコーディング済みピクチャを含む。

【0057】

イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャは、すべてのＶＣＬＮＡＬユニットが、ＩＤＲ＿Ｗ＿ＲＡＤＬからＣＲＡ＿ＮＵＴ（両端を含む）の範囲にある同じ値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するコーディング済みピクチャである。コーディング済みビデオシーケンスについての復号プロセスは、常にＩＲＡＰから開始する。ＩＲＡＰピクチャは、ランダムアクセスポイント（ＲＡＰ）を提供する。

【0058】

漸次復号リフレッシュ（ＧＤＲ）ピクチャは、各ＶＣＬＮＡＬユニットがＧＤＲ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するピクチャである。（ＧＤＲ）ピクチャはまた、ＩＲＡＰピクチャとみなされ得る。ＧＤＲピクチャは、ＣＶＳ開始（ＣＶＳＳ）ピクチャと称される。

【0059】

ピクチャ順序カウント（ＰＯＣ）は、各ピクチャに関連付けられた変数であり、ＣＬＶＳにおけるすべてのピクチャの中で関連付けられたピクチャを一意に識別し、関連付けられたピクチャがＤＰＢから出力されるとき、ＤＰＢから出力される同一のＣＬＶＳにおける他のピクチャの出力順序位置に対する、出力順序における関連付けられたピクチャの位置を示す。

【0060】

以下の頭字語、すなわち、アクセスユニット（ＡＵ）、コーディングツリーブロック（ＣＴＢ）、コーディングツリーユニット（ＣＴＵ）、コーディングユニット（ＣＵ）、コーディング済みレイヤビデオシーケンス（ＣＬＶＳ）、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）、コーディング済みビデオシーケンス（ＣＶＳ）、コーディング済みビデオシーケンス開始（ＣＶＳＳ）、ジョイントビデオエキスパートチーム（ＪＶＥＴ）、動き拘束タイルセット（ＭＣＴＳ）、最大転送単位（ＭＴＵ）、ネットワーク抽象化レイヤ（ＮＡＬ）、出力レイヤセット（ＯＬＳ）、ピクチャ順序カウント（ＰＯＣ）、ピクチャパラメータセット（ＰＰＳ）、ランダムアクセスポイント（ＲＡＰ）、ローバイトシーケンスペイロード（ＲＢＳＰ）、シーケンスパラメータセット（ＳＰＳ）、ビデオパラメータセット（ＶＰＳ）、多目的ビデオコーディング（ＶＶＣ）およびワーキングドラフト（ＷＤ）が本明細書において使用される。

【0061】

図１は、ビデオ信号をコーディングする例示的な動作方法１００のフローチャートである。具体的には、ビデオ信号はエンコーダにおいて符号化される。符号化処理は、ビデオファイルサイズを低減するように、様々な機構を利用することによってビデオ信号を圧縮する。より小さいファイルサイズは、関連付けられた帯域幅オーバヘッドを低減させながら、圧縮されたビデオファイルをユーザへ送信することを可能にする。デコーダは次に、エンドユーザへの表示のために元のビデオ信号を再構築するように、圧縮されたビデオファイルを復号する。復号処理は概して、デコーダがビデオ信号を整合性をもって再構築可能となるように、符号化処理のミラー動作を行う。

【0062】

段階１０１において、ビデオ信号がエンコーダに入力される。例えば、ビデオ信号は、メモリに格納された非圧縮ビデオファイルであってよい。別の例として、ビデオファイルは、ビデオカメラなどのビデオキャプチャデバイスによってキャプチャされ、ビデオのライブストリーミングをサポートするように符号化されてよい。ビデオファイルは、オーディオコンポーネントとビデオコンポーネントの両方を含んでよい。ビデオコンポーネントは、シーケンスで見られたときに、動きの視覚的印象を提示する、一連のイメージフレームを含む。フレームは、本明細書ではルマ成分（またはルマサンプル）と呼ばれる光と、クロマ成分（または色サンプル）と呼ばれる色の観点で表現される、画素を含む。いくつかの例において、フレームはまた、３次元ビューイングをサポートする深度値を含み得る。

【0063】

段階１０３において、ビデオはブロックにパーティショニングされる。パーティショニングは、圧縮のために、各フレームにおける画素を正方形および／または長方形のブロックに細分割することを含む。例えば、高効率ビデオコーディング（ＨＥＶＣ）（Ｈ．２６５およびＭＰＥＧ－ＨＰａｒｔ２としてもまた知られる）において、フレームはまず、コーディングツリーユニット（ＣＴＵ）に分割され得、それは、予め定義されたサイズ（例えば、６４画素×６４画素）のブロックである。ＣＴＵは、ルマサンプルとクロマサンプルの両方を含む。コーディングツリーは、ＣＴＵをブロックに分割するように利用され得、次に、更なる符号化をサポートする構成が実現されるまで、ブロックを再帰的に細分割してよい。例えば、フレームのルマ成分は、個々のブロックが比較的均質照明値を含むまで、細分割されてよい。更に、フレームのクロマ成分は、個々のブロックが比較的均質の色値を含むまで、細分割されてよい。それに応じて、パーティショニング機構は、ビデオフレームのコンテンツに依存して変わる。

【0064】

段階１０５において、様々な圧縮機構が、段階１０３においてパーティショニングされたイメージブロックを圧縮するように利用される。例えば、インター予測および／またはイントラ予測が利用されてよい。インター予測は、共通のシーンにおけるオブジェクトは連続するフレームにおいて現れる傾向がある、という事実を利用するように設計される。それに応じて、参照フレームにおけるオブジェクトを描画するブロックは、隣接フレームにおいて繰り返して表現される必要がない。具体的には、テーブルなどのオブジェクトは、複数のフレームにわたって一定の位置に残ることがある。したがって、テーブルが一度表現されると、隣接フレームは、参照フレームに戻って参照され得る。パターンマッチング機構が、複数のフレームにわたってオブジェクトをマッチさせるように利用され得る。更に、例えばオブジェクトの動きまたはカメラの動きに起因して、移動するオブジェクトは、複数のフレームにわたって表されることがある。特定の例として、ビデオが、複数のフレームにわたって画面を横切って移動する自動車を示してよい。動きベクトルは、そのような動きを表現するように利用され得る。動きベクトルは、フレームにおけるオブジェクトの座標から参照フレームにおけるオブジェクトの座標へのオフセットを提供する二次元ベクトルである。したがって、インター予測は、現フレームにおけるイメージブロックを、参照フレームにおける対応するブロックからのオフセットを示す動きベクトルのセットとして、符号化し得る。

【0065】

イントラ予測は、共通フレームにおいてブロックを符号化する。イントラ予測は、ルマおよびクロマ成分はフレームにおいてクラスタとなる傾向がある、という事実を利用する。例えば、ツリーの部分における緑のパッチは、緑の同様のパッチに隣接するように位置する傾向がある。イントラ予測は、複数の指向性予測モード（例えば、ＨＥＶＣにおいては３３）、平面モード、および直流（ＤＣ）モードを利用する。指向性モードは、現ブロックが、隣接ブロックのサンプルと、対応する方向において同様／同じであることを示す。平面モードは、行／列（例えば、平面）に沿った一連のブロックが、行の縁において隣接ブロックに基づいて補間され得ることを示す。平面モードは、実質的に、値を変更する際に比較的一定のスロープを利用することによって、行／列にわたる光／色の円滑な移行を示す。ＤＣモードは、境界のスムージングに利用され、ブロックが、指向性予測モードの角度方向に関連付けられた全ての隣接ブロックのサンプルに関連付けられた平均値と、同様／同じであることを示す。それに応じて、イントラ予測ブロックは、実際の値の代わりに、様々な相関予測モード値としてイメージブロックを表し得る。更に、インター予測ブロックは、実際の値の代わりに動きベクトル値としてイメージブロックを表し得る。どちらの場合も、予測ブロックは、いくつかの場合において、イメージブロックを正確に表さないことがある。いかなる差異も、残差ブロックに格納される。更にファイルを圧縮するように、変換が、残差ブロックに適用され得る。

【0066】

段階１０７において、様々なフィルタリング技法が適用され得る。ＨＥＶＣにおいて、フィルタはインループフィルタリングスキームに従って適用される。上記で論じられたブロックベースの予測は、デコーダにおいて、ブロックノイズのあるイメージを作成する結果となることがある。更に、ブロックベースの予測スキームは、ブロックを符号化し得、次に、参照ブロックとして後に使用するための符号化済みブロックを再構築し得る。インループフィルタリングスキームは、ノイズ抑制フィルタ、ブロック解除フィルタ、適応ループフィルタ、およびサンプル適応オフセット（ＳＡＯ）フィルタを、ブロック／フレームに繰り返し適用する。これらのフィルタは、符号化されたファイルが正確に再構築され得るように、そのようなブロッキングアーチファクトを軽減する。更に、これらのフィルタは再構築された参照ブロックへのアーチファクトを軽減し、その結果、アーチファクトが、再構築された参照ブロックに基づいて符号化された後続のブロックにおいて追加のアーチファクトを作成する可能性が小さくなる。

【0067】

ビデオ信号がパーティショニング、圧縮、およびフィルタリングされると、得られるデータは、段階１０９でビットストリームにおいて符号化される。ビットストリームは、上記で論じられたデータのみならず、デコーダにおいて適切なビデオ信号再構築をサポートするように要望される任意のシグナリングデータを含む。例えば、そのようなデータは、デコーダにコーディング命令を提供する、パーティションデータ、予測データ、残差ブロック、および様々なフラグを含み得る。ビットストリームは、要求時にデコーダに向けての伝送のために、メモリに格納され得る。ビットストリームはまた、複数のデコーダに向けてブロードキャストおよび／またはマルチキャストされ得る。ビットストリームの作成は反復処理である。それに応じて、段階１０１、１０３、１０５、１０７および１０９は、継続的および／または同時に、多くのフレームおよびブロックにわたって発生し得る。図１に示された順序は明確性および説明の容易性のために存在するものであり、ビデオコーディングプロセスを特定の順序に限定することを意図するものではない。

【0068】

デコーダは、段階１１１でビットストリームを受信し復号処理を始める。具体的には、デコーダは、エントロピー復号スキームを利用して、ビットストリームを対応するシンタックスおよびビデオデータに変換する。段階１１１において、デコーダは、ビットストリームからのシンタックスデータを利用して、フレームに関するパーティションを決定する。パーティショニングは、段階１０３において、ブロックパーティショニングの結果とマッチすべきである。段階１１１において利用されるようなエントロピー符号化／復号が、ここで説明される。エンコーダは、圧縮処理の最中に、入力イメージにおける値の空間的位置に基づいて、いくつかの可能な選択肢から、ブロックパーティショニングスキームの選択などの多くの選択を行う。正確な選択のシグナリングは、多数のビン（ｂｉｎ）を利用し得る。本明細書で用いられるとき、ビンは、変数（例えば、コンテキストに依存して変わり得るビット値）として扱われる二進値である。エントロピーコーディングは、エンコーダが、特定の場合において実行可能でないことが明確な任意の選択肢を棄却し、許容可能な選択肢のセットを残すことを可能にする。各許容可能な選択肢は次に、コードワードを割り当てられる。コードワードの長さは、許容可能な選択肢（例えば、２つの選択肢に関して１つのビン、３から４つの選択肢に関して２つのビンなど）の数に基づく。エンコーダは次に、選択された選択肢に関するコードワードを符号化する。コードワードは、全ての可能な選択肢の大きい可能性のあるセットからの選択を一意に示すのとは対照的に、許容可能な選択肢の小さいサブセットからの選択を一意に示すように要望されるくらいの大きさなので、このスキームは、コードワードのサイズを低減する。デコーダは次に、エンコーダと同様の方式において許容可能な選択肢のセットを決定することによって、選択したものを復号する。許容可能な選択肢のセットを決定することにより、デコーダはコードワードを読み出し、エンコーダによって行われた選択を決定することができる。

【0069】

段階１１３において、デコーダはブロック復号を実行する。具体的には、デコーダは、逆変換を利用して残差ブロックを生成する。次に、デコーダは、残差ブロックおよび対応する予測ブロックを利用して、パーティショニングに従ってイメージブロックを再構築する。予測ブロックは、段階１０５においてエンコーダで生成されたようなイントラ予測ブロックおよびインター予測ブロックの両方を含み得る。再構築されたイメージブロックは次に、段階１１１において決定されたパーティショニングデータに従って再構築されたビデオ信号のフレームに位置決めされる。段階１１３に関するシンタックスはまた、上記で論じられたようなエントロピーコーディングを介して、ビットストリームにおいてシグナリングされ得る。

【0070】

段階１１５において、フィルタリングは、エンコーダにおいて段階１０７と同様の方式で、再構築されたビデオ信号のフレームに対して実行される。例えば、ノイズ抑制フィルタ、ブロック解除フィルタ、適応ループフィルタ、およびＳＡＯフィルタが、ブロックアーチファクトを除去するようにフレームに適用され得る。フレームがフィルタリングされると、ビデオ信号は、エンドユーザが見るように、段階１１７においてディスプレイに出力され得る。

【0071】

図２は、ビデオコーディングに関する例示的なコーディングおよび復号（コーデック）システム２００の概略図である。具体的には、コーデックシステム２００は、動作方法１００の実装形態をサポートする機能を提供する。コーデックシステム２００は、エンコーダおよびデコーダの両方において利用されるコンポーネントを描画するために一般化される。コーデックシステム２００は、動作方法１００における段階１０１および１０３に関して論じられたように、ビデオ信号を受信およびパーティショニングし、それにより、パーティショニングされたビデオ信号２０１が生じる。コーデックシステム２００は次に、方法１００における段階１０５、１０７および１０９に関して論じられたように、エンコーダとして作用するときに、パーティショニングされたビデオ信号２０１をコーディング済みビットストリームに圧縮する。デコーダとして作用するときに、コーデックシステム２００は、動作方法１００における段階１１１、１１３、１１５および１１７に関して論じられたように、ビットストリームから出力ビデオ信号を生成する。コーデックシステム２００は、汎用コーダ制御コンポーネント２１１、変換スケーリングおよび量子化コンポーネント２１３、イントラピクチャ推定コンポーネント２１５、イントラピクチャ予測コンポーネント２１７、動き補償コンポーネント２１９、動き推定コンポーネント２２１、スケーリングおよび逆変換コンポーネント２２９、フィルタ制御分析コンポーネント２２７、インループフィルタコンポーネント２２５、復号済みピクチャバッファコンポーネント２２３、およびヘッダフォーマットおよびコンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ）コンポーネント２３１を含む。そのようなコンポーネントは、示されるように結合される。図２において、黒い線は、符号化／復号されるデータの動きを示し、破線は、他のコンポーネントのオペレーションを制御する制御データの動きを示す。コーデックシステム２００のコンポーネントは、全てエンコーダにおいて存在し得る。デコーダは、コーデックシステム２００のコンポーネントのサブセットを含み得る。例えば、デコーダはイントラピクチャ予測コンポーネント２１７、動き補償コンポーネント２１９、スケーリングおよび逆変換コンポーネント２２９、インループフィルタコンポーネント２２５、および復号済みピクチャバッファコンポーネント２２３を含み得る。これらのコンポーネントがここで説明される。

【0072】

パーティショニングされたビデオ信号２０１は、コーディングツリーによって画素のブロックにパーティショニングされた、キャプチャされたビデオシーケンスである。コーディングツリーは、画素のブロックを画素のより小さいブロックに細分割するように、様々なスプリットモードを利用する。これらのブロックは次に、より小さいブロックへと更に細分割され得る。ブロックは、コーディングツリー上のノードと呼ばれてよい。より大きい親ノードは、より小さい子ノードへと分割される。ノードが細分割される回数は、ノード／コーディングツリーの深度と呼ばれる。分割されたブロックは、いくつかの場合において、コーディングユニット（ＣＵ）に含まれ得る。例えば、ＣＵは、ＣＵに関して対応するシンタックス命令に従う、ルマブロック、赤色差クロマ（Ｃｒ）ブロック、および青色差クロマ（Ｃｂ）ブロックを含むＣＴＵのサブ部分であり得る。スプリットモードは、ノードをそれぞれ２、３、または４の子ノードにパーティショニングするように利用される二分木（ＢＴ）、三分木（ＴＴ）、および四分木（ＱＴ）を含み得、それらは利用されるスプリットモードに依存して様々な形状をとる。パーティショニングされたビデオ信号２０１は、圧縮のために、汎用コーダ制御コンポーネント２１１、変換スケーリングおよび量子化コンポーネント２１３、イントラピクチャ推定コンポーネント２１５、フィルタ制御分析コンポーネント２２７、および動き推定コンポーネント２２１へ転送される。

【0073】

汎用コーダ制御コンポーネント２１１は、用途制約に従って、ビデオシーケンスのイメージをビットストリームにコーディングすることに関する決定を行うように構成される。例えば、汎用コーダ制御コンポーネント２１１は、再構築品質に対する、ビットレート／ビットストリームサイズの最適化を管理する。そのような決定は、格納空間／帯域幅有効性およびイメージ解像度要求に基づいて作成され得る。汎用コーダ制御コンポーネント２１１はまた、バッファアンダーランおよびオーバーラン問題を軽減するように、送信速度に鑑みバッファ利用を管理する。これらの問題を管理するように、汎用コーダ制御コンポーネント２１１は、パーティショニング、予測、および他のコンポーネントによるフィルタリングを管理する。例えば、汎用コーダ制御コンポーネント２１１は、解像度を増加させて帯域幅利用率を増加させるように圧縮複雑性を動的に増加させることがあり、または、解像度および帯域幅利用率を低下させるように圧縮複雑性を低下させることがある。したがって、汎用コーダ制御コンポーネント２１１は、ビデオ信号再構築品質とビットレート問題とのバランスをとるように、コーデックシステム２００の他のコンポーネントを制御する。汎用コーダ制御コンポーネント２１１は制御データを作成し、それにより他のコンポーネントの動作を制御する。制御データはまた、デコーダにおける復号のためのパラメータをシグナリングするように、ビットストリームに符号化されるヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１に転送される。

【0074】

パーティショニングされたビデオ信号２０１はまた、インター予測のために動き推定コンポーネント２２１および動き補償コンポーネント２１９に送信される。パーティショニングされたビデオ信号２０１のフレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定コンポーネント２２１および動き補償コンポーネント２１９は、受信されたビデオブロックのインター予測コーディングを、１または複数の参照フレーム内の１または複数のブロックと比較することで実行し、時間的予測を提供する。コーデックシステム２００は、複数のコーディングパスを実行して、例えば、ビデオデータの各ブロックに適切なコーディングモードを選択してよい。

【0075】

動き推定コンポーネント２２１および動き補償コンポーネント２１９は、高度に統合されてよいが、概念的目的で別々に示されている。動き推定コンポーネント２２１により実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成する処理である。動きベクトルは、例えば、予測ブロックと比較してコーディング済みオブジェクトの変位を示し得る。予測ブロックは、画素差分の観点から、コーディングされるブロックによくマッチするとわかったブロックである。予測ブロックはまた、参照ブロックと呼ばれ得る。そのような画素差分は、差分絶対値和（ＳＡＤ）、差分二乗和（ＳＳＤ）、または他の差分指標によって決定されてよい。ＨＥＶＣは、ＣＴＵ、コーディングツリーブロック（ＣＴＢ）およびＣＵを含む、いくつかのコーディング済みオブジェクトを利用する。例えば、ＣＴＵはＣＴＢに分割され得、それは次に、ＣＵに含まれるためにＣＢに分割され得る。ＣＵは、予測データを含む予測ユニット（ＰＵ）および／または、ＣＵに関して変換された残差データを含む変換ユニット（ＴＵ）として符号化され得る。動き推定コンポーネント２２１は、レート歪み最適化プロセスの一部としてレート歪み解析を使用して、動きベクトル、ＰＵ、およびＴＵを生成する。例えば、動き推定コンポーネント２２１は、現ブロック／フレームに関する複数の参照ブロック、複数の動きベクトルなどを決定し得、最良のレート歪み特性を有する参照ブロック、動きベクトルなどを選択し得る。最良のレート歪み特性は、ビデオ再構築の品質（例えば、圧縮によるデータ損失の量）、およびコーディング効率（例えば、最終的な符号化のサイズ）の両方のバランスをとる。

【0076】

いくつかの例において、コーデックシステム２００は、復号済みピクチャバッファコンポーネント２２３に格納された参照ピクチャのサブ整数画素位置の値を計算してよい。例えば、ビデオコーデックシステム２００は、参照ピクチャの４分の１画素位置、８分の１画素位置、または他の端数画素位置の値を補間してよい。したがって、動き推定コンポーネント２２１は、フル画素位置および端数画素位置に対して動き検索を実行し、端数画素精度を有する動きベクトルを出力してよい。動き推定コンポーネント２２１は、インターコーディングスライス内のビデオブロックのＰＵに対する動きベクトルを、ＰＵの位置と参照ピクチャの予測ブロックの位置とを比較することで計算する。動き推定コンポーネント２２１は、計算した動きベクトルを動きデータとしてヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１に符号化のために出力し、また動きを動き補償コンポーネント２１９に出力する。

【0077】

動き補償コンポーネント２１９により実行される動き補償は、動き推定コンポーネント２２１により決定される動きベクトルに基づいて予測ブロックをフェッチするまたは生成することを必要とし得る。ここでも、動き推定コンポーネント２２１および動き補償コンポーネント２１９は、いくつかの例において機能的に統合されてよい。動き補償コンポーネント２１９は、現ビデオブロックのＰＵに対する動きベクトルを受信すると、動きベクトルが指す予測ブロックの位置を特定してよい。残差ビデオブロックは次に、コーディングされている現ビデオブロックの画素値から予測ブロックの画素値を減算することで形成され、画素差分値を形成する。一般的に、動き推定コンポーネント２２１は、ルマ成分に対して動き推定を実行し、動き補償コンポーネント２１９はルマ成分に基づいて計算された動きベクトルをクロマ成分およびルマ成分の両方に用いる。予測ブロックおよび残差ブロックは、変換スケーリングおよび量子化コンポーネント２１３に転送される。

【0078】

パーティショニングされたビデオ信号２０１はまた、イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７に送信される。動き推定コンポーネント２２１および動き補償コンポーネント２１９と同様に、イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７は高度に統合されてよいが、概念的目的で別々に示される。上記で説明されるように、フレーム間の動き推定コンポーネント２２１および動き補償コンポーネント２１９によって実行されるインター予測の代替手段として、イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７は、現フレームにおけるブロックと比較して、現ブロックをイントラ予測する。特に、イントラピクチャ推定コンポーネント２１５は、現ブロックを符号化するように用いるイントラ予測モードを決定する。いくつかの例において、イントラピクチャ推定コンポーネント２１５は、複数のテストされたイントラ予測モードから、現ブロックを符号化するための適切なイントラ予測モードを選択する。選択されたイントラ予測モードは次に、符号化のために、ヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１に転送される。

【0079】

例えば、イントラピクチャ推定コンポーネント２１５は、様々なテスト済みイントラ予測モードに関して、レート歪み解析を使用してレート歪み値を計算し、テスト済みモードの中で最良のレート歪み特性を有するイントラ予測モードを選択してよい。レート歪み解析は概して、符号化済みブロックと、符号化済みブロックを生み出すために符号化された元の符号化前のブロックとの間の歪み（またはエラー）の量、および符号化済みブロックを生成するのに用いられるビットレート（例えば、ビット数）を決定する。イントラピクチャ推定コンポーネント２１５は、様々な符号化されたブロックの歪みおよびレートから比を計算し、どのイントラ予測モードが該当ブロックに対して最良のレート歪み値を示すかを決定してよい。更に、イントラピクチャ推定コンポーネント２１５は、レート歪み最適化（ＲＤＯ）に基づいて深度モデリングモード（ＤＭＭ）を使用して、深度マップの深度ブロックをコーディングするように構成されてよい。

【0080】

イントラピクチャ予測コンポーネント２１７は、エンコーダ上で実装されるとき、イントラピクチャ推定コンポーネント２１５によって決定される選択されたイントラ予測モードに基づいて予測ブロックから残差ブロックを生成し、または、デコーダ上で実装されるとき、ビットストリームから残差ブロックを読み出し得る。残差ブロックは、行列として表される、予測ブロックと元のブロックの間の値の差異を含む。残差ブロックは次に、変換スケーリングおよび量子化コンポーネント２１３に転送される。イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７は、ルマおよびクロマ成分の両方において動作し得る。

【0081】

変換スケーリングおよび量子化コンポーネント２１３は、更に残差ブロックを圧縮するように構成される。変換スケーリングおよび量子化コンポーネント２１３は、離散余弦変換（ＤＣＴ）、離散正弦変換（ＤＳＴ）または概念的に同様の変換などの変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生み出す。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も用いることができる。変換は、残差情報を画素値ドメインから周波数ドメイン等の変換ドメインに変換してよい。変換スケーリングおよび量子化コンポーネント２１３は、また、例えば周波数に基づいて、変換された残差情報をスケーリングするように構成される。そのようなスケーリングは、異なる周波数情報を異なる粒度で量子化するように、スケール因子を残差情報に適用することを含み、それは再構築済みビデオの最終視覚的品質に影響し得る。変換スケーリングおよび量子化コンポーネント２１３はまた、ビットレートを更に低減するために変換係数を量子化するように構成される。量子化プロセスは、いくつかの、または全ての係数に関連付けられたビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例において、変換スケーリングおよび量子化コンポーネント２１３は次に、量子化変換係数を含む行列のスキャンを実行し得る。量子化変換係数は、ビットストリームで符号化されるように、ヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１に転送される。

【0082】

スケーリングおよび逆変換コンポーネント２２９は、動き推定をサポートするように、変換スケーリングおよび量子化コンポーネント２１３の逆動作を適用する。スケーリングおよび逆変換コンポーネント２２９は、例えば、別の現ブロックに関する予測ブロックとなり得る参照ブロックとして後に使用するために、画素ドメインにおける残差ブロックを再構築するように、逆スケーリング、変換、および／または量子化を適用する。動き推定コンポーネント２２１および／または動き補償コンポーネント２１９は、より後のブロック／フレームの動き推定を用いるように、残差ブロックを対応する予測ブロックに戻して加えることにより、参照ブロックを計算し得る。フィルタは、スケーリング、量子化、および変換の最中に作成したアーチファクトを軽減するように、再構築された参照ブロックに適用される。そうでない場合は、そのようなアーチファクトは、後続のブロックが予測されるとき、不正確な予測を生じさせる（および、追加のアーチファクトを作成させる）であろう。

【0083】

フィルタ制御分析コンポーネント２２７およびインループフィルタコンポーネント２２５は、残差ブロックおよび／または再構築されたイメージブロックにフィルタを適用する。例えば、スケーリングおよび逆変換コンポーネント２２９からの変換された残差ブロックは、元のイメージブロックを再構築するように、イントラピクチャ予測コンポーネント２１７および／または動き補償コンポーネント２１９からの対応する予測ブロックと組み合され得る。フィルタは次に、再構築されたイメージブロックに適用され得る。いくつかの例において、フィルタは、代わりに、残差ブロックに適用され得る。図２における他のコンポーネントと同様に、フィルタ制御分析コンポーネント２２７およびインループフィルタコンポーネント２２５は高度に統合され、一緒に実装されてよいが、概念的目的で別々に描画される。再構築された参照ブロックに適用されるフィルタは、特定の空間領域に適用され、そのようなフィルタがどのように適用されるかを調整するように、複数のパラメータを含む。フィルタ制御分析コンポーネント２２７は、そのようなフィルタがどこで適用されるべきか決定するように、再構築された参照ブロックを分析し、対応するパラメータを設定する。そのようなデータは、符号化のためにフィルタ制御データとしてヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１に転送される。インループフィルタコンポーネント２２５は、フィルタ制御データに基づいて、そのようなフィルタを適用する。フィルタは、デブロッキングフィルタ、ノイズ抑制フィルタ、ＳＡＯフィルタ、および適応ループフィルタを含んでよい。そのようなフィルタは、例に依存して、空間／画素ドメインにおいて（例えば、再構築された画素ブロック上で）、または、周波数ドメインにおいて、適用されてよい。

【0084】

エンコーダとして動作するとき、フィルタリングされた再構築されたイメージブロック、残差ブロック、および／または予測ブロックは、上記で論じられる動き推定において後に使用するために、復号済みピクチャバッファコンポーネント２２３に格納される。デコーダとして動作するとき、復号済みピクチャバッファコンポーネント２２３は、再構築およびフィルタリングされたブロックを格納し、出力ビデオ信号の一部として、ディスプレイに向けて転送する。復号済みピクチャバッファコンポーネント２２３は、予測ブロック、残差ブロック、および／または再構築されたイメージブロックを格納できる任意のメモリデバイスでよい。

【0085】

ヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１は、コーデックシステム２００の様々なコンポーネントからデータを受信し、そのようなデータを、デコーダに向けて伝送するために、コーディング済みビットストリームへ符号化する。具体的には、ヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１は、全体制御データおよびフィルタ制御データなどの制御データを符号化するように、様々なヘッダを生成する。更に、イントラ予測および動きデータを含む予測データ、ならびに、量子化変換係数データの形式の残差データは、全てビットストリームにおいて符号化される。最終ビットストリームは、元のパーティショニングされたビデオ信号２０１を再構築するためにデコーダによって要望される全ての情報を含む。そのような情報は、また、イントラ予測モードインデックステーブル（また、コードワードマッピングテーブルと呼ばれる）、様々なブロックに関する符号化コンテキストの定義、もっとも可能性が高いイントラ予測モードのインジケーション、パーティション情報のインジケーションなどを含んでよい。そのようなデータは、エントロピーコーディングを利用することによって符号化されてよい。例えば、情報は、コンテキスト適応可変長コーディング（ＣＡＶＬＣ）、ＣＡＢＡＣ、シンタックスベースのコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ）、確率区間パーティショニングエントロピー（ＰＩＰＥ）コーディング、または別のエントロピーコーディング技術を利用して符号化されてよい。エントロピーコーディングに続いて、コーディング済みビットストリームは、別のデバイス（例えば、ビデオデコーダ）に伝送されても、後の伝送または検索のためにアーカイブされてもよい。

【0086】

図３は、例示的なビデオエンコーダ３００を示すブロック図である。ビデオエンコーダ３００は、コーデックシステム２００の符号化機能を実装するように、および／または、動作方法１００の段階１０１、１０３、１０５、１０７および／または１０９を実装するように、利用され得る。エンコーダ３００は入力されるビデオ信号をパーティショニングし、パーティショニングされたビデオ信号３０１をもたらし、それは、パーティショニングされたビデオ信号２０１と実質的に同様となる。パーティショニングされたビデオ信号３０１は次に、エンコーダ３００のコンポーネントによって圧縮され、ビットストリームに符号化される。

【0087】

具体的には、パーティショニングされたビデオ信号３０１は、イントラ予測のために、イントラピクチャ予測コンポーネント３１７に転送される。イントラピクチャ予測コンポーネント３１７は、イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７と実質的に同様であってよい。パーティショニングされたビデオ信号３０１はまた、復号済みピクチャバッファコンポーネント３２３における参照ブロックに基づいて、インター予測のために動き補償コンポーネント３２１に転送される。動き補償コンポーネント３２１は、動き推定コンポーネント２２１および動き補償コンポーネント２１９と実質的に同様であってよい。イントラピクチャ予測コンポーネント３１７および動き補償コンポーネント３２１からの予測ブロックおよび残差ブロックは、残差ブロックの変換および量子化のために、変換および量子化コンポーネント３１３に転送される。変換および量子化コンポーネント３１３は、変換スケーリングおよび量子化コンポーネント２１３と実質的に同様であってよい。変換および量子化された残差ブロック、および対応する予測ブロック（関連付けられた制御データと共に）は、ビットストリームにコーディングするために、エントロピーコーディングコンポーネント３３１に転送される。エントロピーコーディングコンポーネント３３１は、ヘッダフォーマットおよびＣＡＢＡＣコンポーネント２３１と実質的に同様であってよい。

【0088】

変換および量子化された残差ブロック、および／または対応する予測ブロックはまた、動き補償コンポーネント３２１によって用いるための参照ブロックへの再構築のために、変換および量子化コンポーネント３１３から逆変換および量子化コンポーネント３２９に転送される。逆変換および量子化コンポーネント３２９は、スケーリングおよび逆変換コンポーネント２２９と実質的に同様であってよい。インループフィルタコンポーネント３２５におけるインループフィルタはまた、例に依存して、残差ブロックおよび／または再構築された参照ブロックに適用される。インループフィルタコンポーネント３２５は、フィルタ制御分析コンポーネント２２７およびインループフィルタコンポーネント２２５と実質的に同様であってよい。インループフィルタコンポーネント３２５は、インループフィルタコンポーネント２２５に関して説明されたような複数のフィルタを含んでよい。フィルタリングされたブロックは次に、動き補償コンポーネント３２１によって参照ブロックとして用いるために、復号済みピクチャバッファコンポーネント３２３に格納される。復号済みピクチャバッファコンポーネント３２３は、復号済みピクチャバッファコンポーネント２２３と実質的に同様であってよい。

【0089】

図４は、例示的なビデオデコーダ４００を示すブロック図である。ビデオデコーダ４００は、コーデックシステム２００の復号機能を実装し、および／または、動作方法１００の段階１１１、１１３、１１５および／または１１７を実装するように利用されてよい。デコーダ４００は、例えばエンコーダ３００からビットストリームを受信し、エンドユーザへの表示のために、ビットストリームに基づいて、再構築された出力ビデオ信号を生成する。

【0090】

ビットストリームは、エントロピー復号コンポーネント４３３によって受信される。エントロピー復号コンポーネント４３３は、ＣＡＶＬＣ、ＣＡＢＡＣ、ＳＢＡＣ、ＰＩＰＥコーディング、または他のエントロピーコーディング技術などの、エントロピー復号スキームを実装するように構成される。例えば、エントロピー復号コンポーネント４３３は、ビットストリーム内のコードワードとして符号化された追加のデータを解釈するために、ヘッダ情報を利用してコンテキストを提供してよい。復号された情報は、全体制御データ、フィルタ制御データ、パーティション情報、動きデータ、予測データ、および残差ブロックからの量子化変換係数などの、ビデオ信号を復号する任意の望ましい情報を含む。量子化変換係数は、残差ブロックに再構築されるように、逆変換および量子化コンポーネント４２９に転送される。逆変換および量子化コンポーネント４２９は、逆変換および量子化コンポーネント３２９と同様であってよい。

【0091】

再構築された残差ブロックおよび／または予測ブロックは、イントラ予測動作に基づくイメージブロックへの再構築のために、イントラピクチャ予測コンポーネント４１７に転送される。イントラピクチャ予測コンポーネント４１７は、イントラピクチャ推定コンポーネント２１５およびイントラピクチャ予測コンポーネント２１７と同様であってよい。具体的には、イントラピクチャ予測コンポーネント４１７は、予測モードを利用してフレームにおける参照ブロックを位置決めし、イントラ予測されたイメージブロックを再構築するように、結果に残差ブロックを適用する。再構築されたイントラ予測されたイメージブロックおよび／または残差ブロック、および対応するインター予測データは、復号済みピクチャバッファコンポーネント４２３に、インループフィルタコンポーネント４２５を介して転送され、それらは実質的に、復号済みピクチャバッファコンポーネント２２３およびインループフィルタコンポーネント２２５と、それぞれ同様であり得る。インループフィルタコンポーネント４２５は、再構築されたイメージブロック、残差ブロック、および／または予測ブロックをフィルタリングし、そのような情報は、復号済みピクチャバッファコンポーネント４２３に格納される。復号済みピクチャバッファコンポーネント４２３からの再構築されたイメージブロックは、インター予測のために、動き補償コンポーネント４２１に転送される。動き補償コンポーネント４２１は、動き推定コンポーネント２２１および／または動き補償コンポーネント２１９と実質的に同様であってよい。具体的には、動き補償コンポーネント４２１は、参照ブロックからの動きベクトルを利用して予測ブロックを生成し、イメージブロックを再構築するように、結果に残差ブロックを適用する。得られた再構築されたブロックはまた、インループフィルタコンポーネント４２５を介して、復号済みピクチャバッファコンポーネント４２３に転送され得る。復号済みピクチャバッファコンポーネント４２３は、追加の再構築されたイメージブロックを継続して格納し、それはパーティション情報を介してフレームに再構築され得る。そのようなフレームはまた、シーケンスに配置されてよい。シーケンスは、再構築された出力ビデオ信号として、ディスプレイに向けて出力される。

【0092】

以上を踏まえると、こうしたビデオ圧縮技法は、空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を実行し、ビデオシーケンスに固有の冗長性を減らすまたは除去する。ブロックベースのビデオコーディングについては、ビデオスライス（すなわち、ビデオピクチャまたはビデオピクチャの一部）は、ツリーブロック、コーディングツリーブロック（ＣＴＢ）、コーディングツリーユニット（ＣＴＵ）、コーディングユニット（ＣＵ）および／またはコーディングノードとも称され得るビデオブロックにパーティショニングされ得る。あるピクチャのイントラコーディングされた（Ｉ）スライス内のビデオブロックが、同じピクチャ内の隣接ブロックにおける参照サンプルに関する空間的予測を用いて符号化される。あるピクチャのインターコーディングされた（ＰまたはＢ）スライスに含まれるビデオブロックが、同じピクチャ内の隣接ブロックにおける参照サンプルに関する空間的予測、または他の参照ピクチャにおける参照サンプルに関する時間的予測を用いてよい。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

【0093】

空間的予測または時間的予測が、コーディングされるブロックに対する予測ブロックをもたらす。残差データは、コーディングされる元のブロックと予測ブロックとの間の画素差分を表している。インターコーディング済みブロックが、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコーディング済みブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコーディング済みブロックが、イントラコーディングモードおよび残差データに従って符号化される。更なる圧縮のために、残差データは、画素ドメインから変換ドメインに変換され得、残差変換係数がもたらされ、これはその後に量子化されてよい。量子化された変換係数は、最初は２次元配列に配置されており、変換係数の１次元ベクトルを作り出すためにスキャンされてよく、更なる圧縮を実現するためにエントロピーコーディングが適用されてよい。

【0094】

イメージおよびビデオ圧縮は急成長を遂げており、様々なコーディング規格がもたらされている。そのようなビデオコーディング規格には、ＩＴＵ－ＴのＨ．２６１、国際標準化機構／国際電気標準会議（ＩＳＯ／ＩＥＣ）のＭＰＥＧ－１Ｐａｒｔ２、ＩＴＵ－ＴＨ．２６２またはＩＳＯ／ＩＥＣＭＰＥＧ－２Ｐａｒｔ２、ＩＴＵ－ＴＨ．２６３、ＩＳＯ／ＩＥＣＭＰＥＧ－４Ｐａｒｔ２、高度ビデオコーディング（ＡＶＣ）（ＩＴＵ‐ＴＨ．２６４またはＩＳＯ／ＩＥＣＭＰＥＧ－４Ｐａｒｔ１０としても知られている）、および高効率ビデオコーディング（ＨＥＶＣ）（ＩＴＵ‐ＴＨ．２６５またはＭＰＥＧ－ＨＰａｒｔ２としても知られている）が含まれる。ＡＶＣには、スケーラブルビデオコーディング（ＳＶＣ）、多視点ビデオコーディング（ＭＶＣ）および多視点ビデオコーディング＋深度（ＭＶＣ＋Ｄ）、並びに３ＤＡＶＣ（３Ｄ－ＡＶＣ）などの拡張が含まれる。ＨＥＶＣには、スケーラブルＨＥＶＣ（ＳＨＶＣ）、多視点ＨＥＶＣ（ＭＶ－ＨＥＶＣ）、および３ＤＨＥＶＣ（３Ｄ－ＨＥＶＣ）などの拡張が含まれる。

【0095】

多目的ビデオコーディング（ＶＶＣ）という名前の新たなビデオコーディング規格もあり、これは、ＩＴＵ－ＴおよびＩＳＯ／ＩＥＣのジョイントビデオエキスパートチーム（ＪＶＥＴ）によって開発中である。ＶＶＣ規格は複数のワーキングドラフトを有するが、ここでは、特に１つのＶＶＣのワーキングドラフト（ＷＤ）、すなわち、２０１９年３月２７日の第１３回ＪＶＥＴ会合におけるＢ．Ｂｒｏｓｓ，Ｊ．ＣｈｅｎおよびＳ．Ｌｉｕの「多目的ビデオコーディング（ドラフト５）」、ＪＶＥＴ－Ｎ１００１－ｖ３（ＶＶＣドラフト５）が参照される。

【0096】

階層化ビデオコーディングはまた、スケーラブルビデオコーディングまたはスケーラビリティを有するビデオコーディングと称される。ビデオコーディングにおけるスケーラビリティは通常、マルチレイヤコーディング技法を使用することによってサポートされる。マルチレイヤビットストリームは、ベースレイヤ（ＢＬ）および１または複数の拡張レイヤ（ＥＬ）を含む。スケーラビリティの例は、空間的スケーラビリティ、品質／信号雑音比（ＳＮＲ）スケーラビリティ、多視点スケーラビリティなどを含む。マルチレイヤコーディング技法を用いる場合、ピクチャまたはその一部を、（１）参照ピクチャを用いることなく（すなわち、イントラ予測を用いて）、（２）同じレイヤにある参照ピクチャを参照する（すなわち、インター予測を用いる）ことにより、または（３）他のレイヤにある参照ピクチャを参照する（すなわち、インターレイヤ予測を用いる）ことによりコーディングしてよい。現ピクチャのインターレイヤ予測に用いられる参照ピクチャは、インターレイヤ参照ピクチャ（ＩＬＲＰ）と呼ばれる。

【0097】

図５は、例えば、ブロック圧縮段階１０５、ブロック復号段階１１３、動き推定コンポーネント２２１、動き補償コンポーネント２１９、動き補償コンポーネント３２１および／または動き補償コンポーネント４２１において動きベクトル（ＭＶ）を決定するために実行されるレイヤベース予測５００の例を示す概略図である。レイヤベース予測５００は、単方向インター予測および／または双方向インター予測と互換性があるが、異なるレイヤのピクチャ間でも実行される。

【0098】

レイヤベース予測５００が、異なるレイヤにおけるピクチャ５１１、５１３と、ピクチャ５１５、５１７との間に適用される。示される例において、ピクチャ５１１および５１３は、レイヤＮ＋１５３２の一部であり、ピクチャ５１５、５１６、５１７および５１８は、レイヤＮ５３１の一部である。レイヤＮ５３１および／またはレイヤＮ＋１５３２などのレイヤは、同様のサイズ、品質、解像度、信号雑音比、能力などの特性の同様の値にすべて関連付けられたピクチャのグループである。示される例において、レイヤＮ＋１５３２は、レイヤＮ５３１より大きいイメージサイズに関連付けられる。したがって、本例において、レイヤＮ＋１５３２におけるピクチャ５１１および５１３は、レイヤＮ５３１におけるピクチャ５１５、５１６、５１７および５１８より大きいピクチャサイズを有する（例えば、高さおよび幅がより大きく、したがって、サンプルがより多い）。しかしながら、そのようなピクチャは、他の特性によってレイヤＮ＋１５３２とレイヤＮ５３１との間で分けることができる。レイヤＮ＋１５３２およびレイヤＮ５３１という２つのレイヤだけが示されるが、ピクチャのセットは、関連付けられた特性に基づいて、任意の数のレイヤに分けることができる。レイヤＮ＋１５３２およびレイヤＮ５３１はまた、レイヤ識別子（ＩＤ）によって示され得る。レイヤＩＤは、ピクチャに関連付けられて、ピクチャが示されたレイヤの一部であることを示すデータの項目である。したがって、各ピクチャ５１１、５１３、および５１５－５１８は、対応するレイヤＩＤに関連付けられ、レイヤＮ＋１５３２またはレイヤＮ５３１のどちらが対応するピクチャを含むかを示し得る。

【0099】

異なるレイヤ５３１－５３２におけるピクチャ５１１、５１３、および５１５－５１８は、別の方式で表示されるよう構成される。したがって、異なるレイヤ５３１－５３２におけるピクチャ５１１、５１３、および５１５－５１８は、同一の時間識別子（ＩＤ）を共有でき、同一のＡＵに含まれることができる。本明細書で用いる場合、ＡＵとは、ＤＰＢから出力するために、同じ表示時間と関連付けられた１または複数のコーディング済みピクチャのセットである。例えば、より小さいピクチャが望しい場合、デコーダは、現在の表示時間でピクチャ５１５を復号および表示し得、または、より大きいピクチャが望しい場合、デコーダは、現在の表示時間でピクチャ５１１を復号および表示し得る。したがって、上位レイヤＮ＋１５３２におけるピクチャ５１１および５１３は、下位レイヤＮ５３１における対応するピクチャ５１５および５１７と（ピクチャサイズに差があるにもかかわらず）実質的に同一のイメージデータを含む。具体的には、ピクチャ５１１は、ピクチャ５１５と実質的に同一のイメージデータを含み、ピクチャ５１３は、ピクチャ５１７と実質的に同一のイメージデータを含む、といったことになる。

【0100】

ピクチャ５１１。５１３および５１５－５１８は、同一のレイヤＮ５３１またはＮ＋１５３２における他のピクチャ５１１、５１３－５１８を参照してコーディングされ得る。同一のレイヤにおける別のピクチャを参照してピクチャをコーディングすることは、インター予測５２３をもたらす。これは、単方向インター予測および／または双方向インター予測と互換性がある。インター予測５２３は、実線矢印で描画される。例えば、ピクチャ５１６は、レイヤＮ＋１５３２におけるピクチャ５１５および／または５１７の１または２を参照として使用してインター予測５２３を利用することによってコーディングされ得る。ここで、１つのピクチャが単方向インター予測のために参照され、および／または、２つのピクチャが双方向インター予測のために参照される。ピクチャが、インター予測５２３を実行するときに同一のレイヤにある別のピクチャの参照として用いられるとき、そのピクチャは参照ピクチャと呼ばれることがある。例えば、ピクチャ５１１は、インター予測５２３に従ってピクチャ５１３をコーディングするために使用される参照ピクチャであり得る。インター予測５２３はまた、マルチレイヤコンテキストにおいてイントラレイヤ予測と称され得る。したがって、インター予測５２３は、現ピクチャとは異なる、参照ピクチャにおける示されたサンプルを参照することによって、現ピクチャのサンプルをコーディングする機構である。ここで、参照ピクチャおよび現ピクチャは同一のレイヤにある。

【0101】

ピクチャ５１１、５１３、および５１５－５１８はまた、異なるレイヤにおける他のピクチャ５１１、５１３、および５１５－５１８を参照することによってコーディングされ得る。このプロセスは、インターレイヤ予測５２１として知られ、破線矢印によって描画される。インターレイヤ予測５２１は、参照ピクチャ内の示されたサンプルを参照することにより現ピクチャのサンプルをコーディングする機構であり、ここで、現ピクチャおよび参照ピクチャは異なるレイヤにあり、したがって異なるレイヤＩＤを有する。例えば、下位レイヤＮ５３１におけるピクチャは、上位レイヤＮ＋１５３２における対応するピクチャをコーディングするために参照ピクチャとして使用され得る。具体的な例として、ピクチャ５１１は、インターレイヤ予測５２１に従ってピクチャ５１５を参照してコーディングされ得る。そのような場合において、ピクチャ５１５はインターレイヤ参照ピクチャとして使用される。インターレイヤ参照ピクチャは、インターレイヤ予測５２１に使用される参照ピクチャである。ほとんどの場合、インターレイヤ予測５２１には制約があり、ピクチャ５１１などの現ピクチャが、同一のＡＵに含まれ、かつ、ピクチャ５１５などの下位レイヤにあるインターレイヤ参照ピクチャのみを使用できるようになっている。複数の（例えば２より多い）レイヤが利用可能であるとき、インターレイヤ予測５２１は、現ピクチャより下位レベルにある複数のインターレイヤ参照ピクチャに基づいて現ピクチャを符号化／復号できる。

【0102】

ビデオエンコーダは、レイヤベース予測５００を利用して、インター予測５２３およびインターレイヤ予測５２１の多くの異なる組み合わせおよび／または順序変更を介してピクチャ５１１、５１３、５１５－５１８を符号化できる。例えば、ピクチャ５１５は、イントラ予測に従ってコーディングされ得る。ピクチャ５１６－５１８はその後、ピクチャ５１５を参照ピクチャとして使用することによってインター予測５２３に従ってコーディングされ得る。更に、ピクチャ５１１は、ピクチャ５１５をインターレイヤ参照ピクチャとして使用することによってインターレイヤ予測５２１に従ってコーディングされ得る。ピクチャ５１３はその後、ピクチャ５１１を参照ピクチャとして使用することによってインター予測５２３に従ってコーディングされ得る。したがって、参照ピクチャは、異なるコーディング機構について、シングルレイヤ参照ピクチャおよびインターレイヤ参照ピクチャの両方として機能し得る。下位レイヤＮ５３１ピクチャに基づいて上位レイヤＮ＋１５３２ピクチャをコーディングすることによって、上位レイヤＮ＋１５３２は、インター予測５２３およびインターレイヤ予測５２１よりはるかに低いコーディング効率を有するイントラ予測を利用することを回避し得る。したがって、イントラ予測の低いコーディング効率は、最小／最低の品質のピクチャに限定され、したがって、最小量のビデオデータのコーディングに限定され得る。参照ピクチャおよび／またはインターレイヤ参照ピクチャとして使用されるピクチャは、参照ピクチャリスト構造に含まれる参照ピクチャリストのエントリにおいて示され得る。

【0103】

図５における各ＡＵ５０６は、１または複数のピクチャを含み得る。例えば、１つのＡＵ５０６はピクチャ５１１および５１５を含み得る。別のＡＵ５０６は、ピクチャ５１６のみを含み得る。実際、各ＡＵ５０６は、復号済みピクチャバッファ（ＤＰＢ）から出力するための（例えばユーザに表示するための）同一の表示時間（例えば同一の時間ＩＤ）に関連付けられた１または複数のコーディング済みピクチャのセットである。各アクセスユニットデリミタ（ＡＵＤ）５０８は、ＡＵ（例えばＡＵ５０６）の開始またはＡＵ間の境界を示すために使用されるインジケータまたはデータ構造である。

【0104】

実施形態において、すべてのレイヤにおいてピクチャを含むＡＵ５０６は、完全ＡＵと称される。完全ＡＵの例は、ピクチャ５１１および５１５を含むＡＵ５０６、または、ピクチャ５１３および５１７を含むＡＵ５０６である。実施形態において、すべてのレイヤにおいてピクチャを含まないＡＵ５０６は不完全ＡＵと称される。不完全ＡＵの例は、ピクチャ５１６を含むＡＵ５０６、または、ピクチャ５１８を含むＡＵ５０６である。ＣＬＶＳ５４０において完全ＡＵおよび不完全ＡＵの両方を使用することにより、異なるレイヤが異なるビットレートを有することが可能となる。例として、レイヤ５３２の２つのピクチャ５１１、５１３と対照的に、レイヤ５３１は、４つのピクチャ５１５－５１８を有する。したがって、レイヤ５３１は、レイヤ５３２より高いビットレートを有する。実際の適用において、異なる数のレイヤがＣＬＶＳ５４０に含まれ得、異なるレイヤは、異なるビットレートをサポートするために、異なる数のピクチャを有し得る。

【0105】

実施形態において、コーディング済みレイヤビデオシーケンス（ＣＬＶＳ）５４０の開始または始まりにおけるＡＵ５０６は、コーディング済みビデオシーケンス開始（ＣＶＳＳ）ＡＵと称される。すなわち、ＣＶＳ５４０における最初または第１のＡＵ５０６はＣＶＳＳＡＵである。実施形態において、ＣＶＳＳＡＵとして指定されたＡＵ５０６の各レイヤ５３１、５３２におけるピクチャ５１１、５１５は、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである。すなわち、ＣＶＳＳＡＵは、１つのレイヤ（例えばレイヤＮ５３１）におけるＣＬＶＳＳピクチャ（例えばピクチャ５１５）、および、別のレイヤ（例えばレイヤＮ＋１５３２）における別のＣＬＶＳＳピクチャ（例えばピクチャ５１１）を含む。ＣＬＶＳＳピクチャは例えば、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャ、漸次復号リフレッシュピクチャ、クリーンランダムアクセス（ＣＲＡ）ピクチャ、即時デコーダリフレッシュ（ＩＤＲ）ピクチャ、ブロークンリンクアクセス（ＢＬＡ）ピクチャ、または別のタイプのランダムアクセスポイントピクチャである。

【0106】

実施形態において、ＡＵ５０６の一部（ＣＶＳＳＡＵを除く）は、１つのレイヤ（例えばレイヤＮ５３１）においてＩＲＡＰピクチャ（例えばピクチャ５１７）を、別のレイヤ（例えばレイヤＮ＋１５３２）において非ＩＲＡＰピクチャ（例えばピクチャ５１３）を含み得る。すなわち、同一のＡＵは、異なるレイヤにおいてＩＲＡＰおよび非ＩＲＡＰピクチャの両方を含む。図５におけるＡＵ５０６の１つは、１つのＩＲＡＰピクチャおよび１つの非ＩＲＡＰピクチャを含むように示されているが、ＡＵが２より多くのレイヤを含むとき、実際の適用では、異なる数のＩＲＡＰおよび非ＩＲＡＰピクチャがＡＵに含まれ得る。ＩＲＡＰピクチャは、以下で更に詳細に説明される。

【0107】

以前のＨ．２６ｘビデオコーディングファミリでは、シングルレイヤコーディングのプロファイルとは別個のプロファイルにおけるスケーラビリティに対してサポートを提供している。スケーラブルビデオコーディング（ＳＶＣ）は、空間的、時間的、および品質的スケーラビリティに対するサポートを提供するＡＶＣ／Ｈ．２６４のスケーラブル拡張である。ＳＶＣについては、フラグがＥＬピクチャにおける各マクロブロック（ＭＢ）においてシグナリングされ、下位レイヤからの収集されたブロックを使用してＥＬＭＢが予測されるかどうかを示す。収集されたブロックからの予測は、テクスチャ、動きベクトル、および／またはコーディングモードを含み得る。ＳＶＣの実装は、それらの設計において、未修正のＨ．２６４／ＡＶＣ実装を直接再使用できない。ＳＶＣＥＬマクロブロックシンタックスおよび復号プロセスは、Ｈ．２６４／ＡＶＣシンタックスおよび復号プロセスと異なる。

【0108】

スケーラブルＨＥＶＣ（ＳＨＶＣ）は、空間及び品質的スケーラビリティに対してサポートを提供するＨＥＶＣ／Ｈ．２６５規格の拡張であり、多視点ＨＥＶＣ（ＭＶ－ＨＥＶＣ）は、多視点スケーラビリティに対してサポートを提供するＨＥＶＣ／Ｈ．２６５の拡張であり、３ＤＨＥＶＣ（３Ｄ－ＨＥＶＣ）は、ＭＶ－ＨＥＶＣより先進的で効率的な３次元（３Ｄ）ビデオコーディングに対してサポートを提供するＨＥＶＣ／Ｈ．２６４の拡張である。時間的スケーラビリティは、シングルレイヤＨＥＶＣコーデックの不可欠な部分として含まれることに留意されたい。ＨＥＶＣのマルチレイヤ拡張の設計には、インターレイヤ予測に用いられる復号されたピクチャが同じアクセスユニット（ＡＵ）からのみもたらされて長期参照ピクチャ（ＬＴＲＰ）として扱われ、また現レイヤにある他の時間参照ピクチャと共に参照ピクチャリスト内の参照インデックスを割り当てられるという考えが利用される。インターレイヤ予測（ＩＬＰ）は、参照インデックスの値を設定して、参照ピクチャリスト内のインターレイヤ参照ピクチャを参照することにより、予測ユニット（ＰＵ）レベルで実現される。

【0109】

特に、参照ピクチャリサンプリング機能および空間的スケーラビリティ機能は両方とも、参照ピクチャまたはその一部のリサンプリングを必要とする。参照ピクチャリサンプリング（ＲＰＲ）は、ピクチャレベルまたはコーディングブロックレベルのいずれかで実現され得る。しかしながら、ＲＰＲがコーディング機能と呼ばれる場合、これはシングルレイヤコーディングの機能である。そうであっても、コーデック設計の観点から、シングルレイヤコーディングのＲＰＲ機能およびマルチレイヤコーディングの空間的スケーラビリティ機能の両方に同じリサンプリングフィルタを用いることは可能である、またはむしろ好ましい。

【0110】

最新のＶＶＣドラフトは階層化ビデオコーディングをサポートする。ＶＶＣビットストリームは複数のレイヤを含むことができる。レイヤは互いから完全に独立でき、すなわち、各レイヤは、インターレイヤ予測（ＩＬＰ）を使用することなくコーディングされる。この場合、レイヤは、サイマルキャストレイヤとも称される。レイヤの一部はＩＬＰを使用してコーディングされることも可能である。ＶＰＳにおけるフラグは、レイヤがサイマルキャストレイヤであるかどうか、または、一部のレイヤがＩＬＰを使用するかどうかを示すために使用される。いくつかのレイヤがＩＬＰを使用するとき、レイヤ間のレイヤ依存性関係もＶＰＳにおいてシグナリングされる。

【0111】

ＳＨＶＣおよびＭＶ－ＨＥＶＣと異なり、最新のＶＶＣドラフトはＯＬＳを指定しない。ＯＬＳは、１または複数のレイヤが出力レイヤとして指定されるレイヤのセットである。出力レイヤは、出力される出力レイヤセットのレイヤである。

【0112】

最新のＶＶＣドラフトでは、レイヤがサイマルキャストレイヤであるとき、１つのレイヤのみが復号および出力のために選択され得ることが指定される。最新のＶＶＣドラフトでは、いくつかのレイヤがＩＬＰを使用するとき、ビットストリームにおけるレイヤのすべてが復号されるように指定されるが、特定のレイヤのみが出力レイヤとなるように指定される。出力レイヤは、１）最高レイヤのみ、２）すべてのレイヤ、または、３）最高のレイヤ＋示された下位レイヤのセットであるように示され得る。

【0113】

図６は、復号順序６０８および提示順序６１０（すなわち出力順序）における、リーディングピクチャ６０４と相対的なイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャ６０２と、トレーリングピクチャ６０６との間の関係の表現６００である。実施形態において、ＩＲＡＰピクチャ６０２は、クリーンランダムアクセス（ＣＲＡ）ピクチャ、またはランダムアクセス復号可能（ＲＡＤＬ）ピクチャを伴う即時デコーダリフレッシュ（ＩＤＲ）ピクチャと呼ばれる。ＨＥＶＣでは、ＩＤＲピクチャ、ＣＲＡピクチャ、およびブロークンリンクアクセス（ＢＬＡ）ピクチャが全て、ＩＲＡＰピクチャ６０２とみなされる。ＶＶＣについては、２０１８年１０月の第１２回ＪＶＥＴ会合において、ＩＤＲピクチャおよびＣＲＡピクチャを両方ともＩＲＡＰピクチャとして有することが合意された。実施形態では、ブロークンリンクアクセス（ＢＬＡ）ピクチャおよび漸次デコーダリフレッシュ（ＧＤＲ）ピクチャも、ＩＲＡＰピクチャとみなされてよい。コーディング済みビデオシーケンスのための復号プロセスは常にＩＲＡＰから開始する。ＩＲＡＰピクチャはランダムアクセスポイント（ＲＡＰ）を提供する。

【0114】

図６に示されるように、リーディングピクチャ６０４（例えばピクチャ２および３）は、復号順序６０８においてＩＲＡＰピクチャ６０２に続くが、提示順序６１０においてＩＲＡＰピクチャ６０２に先行する。トレーリングピクチャ６０６は、復号順序６０８および提示順序６１０の両方においてＩＲＡＰピクチャ６０２に続く。２つのリーディングピクチャ６０４および１つのトレーリングピクチャ６０６が図６において描画されるが、当業者であれば、実際の適用において、より多くの、または、より少ないリーディングピクチャ６０４および／またはトレーリングピクチャ６０６が復号順序６０８および提示順序６１０において存在し得ることを理解する。

【0115】

図６のリーディングピクチャ６０４は、２つのタイプ、すなわち、ランダムアクセススキップリーディング（ＲＡＳＬ）およびＲＡＤＬに分割されている。復号がＩＲＡＰピクチャ６０２（例えば、ピクチャ１）で始まる場合、ＲＡＤＬピクチャ（例えば、ピクチャ３）を適切に復号することができる。しかしながら、ＲＡＳＬピクチャ（例えば、ピクチャ２）を適切に復号することはできない。したがって、ＲＡＳＬピクチャは破棄される。ＲＡＤＬピクチャとＲＡＳＬピクチャとの間の違いを考慮して、ＩＲＡＰピクチャ６０２と関連付けられるリーディングピクチャ６０４のタイプは、効率的且つ適切なコーディングのために、ＲＡＤＬまたはＲＡＳＬのいずれかとして識別されなければならない。ＨＥＶＣでは、ＲＡＳＬピクチャおよびＲＡＤＬピクチャが存在する場合、同じＩＲＡＰピクチャ６０２と関連付けられたＲＡＳＬピクチャおよびＲＡＤＬピクチャについては、ＲＡＳＬピクチャが提示順序６１０においてＲＡＤＬピクチャの先に来なければならないということが制約されている。

【0116】

ＩＲＡＰピクチャ６０２は、以下に挙げる２つの重要な機能／利点を提供する。第一に、ＩＲＡＰピクチャ６０２の存在は、当該ピクチャから復号プロセスが開始できることを示している。この機能により、ＩＲＡＰピクチャ６０２が当該位置に存在する限り、復号プロセスはビットストリームの当該位置で開始され、必ずしもビットストリームの開始の部分ではないというランダムアクセス機能が可能になる。第二に、ＩＲＡＰピクチャ６０２の存在で、復号プロセスがリフレッシュされ、ＩＲＡＰピクチャ６０２で始まるコーディング済みピクチャ（ＲＡＳＬピクチャを除く）が前のピクチャを全く参照することなくコーディングされるようになる。したがって、ＩＲＡＰピクチャ６０２がビットストリームに存在することで、結果として、ＩＲＡＰピクチャ６０２の前にあるコーディング済みピクチャを復号する際に発生し得るあらゆるエラーが、ＩＲＡＰピクチャ６０２および復号順序６０８でＩＲＡＰピクチャ６０２の後に来るピクチャに伝搬するのを阻止することになる。

【0117】

ＩＲＡＰピクチャ６０２は重要な機能を提供するが、これは圧縮効率に対する代償を伴う。ＩＲＡＰピクチャ６０２の存在は、ビットレートの急増を引き起こす。圧縮効率に対するこの代償は、２つの理由によるものである。第一に、ＩＲＡＰピクチャ６０２がイントラ予測ピクチャのため、このピクチャ自体は、インター予測ピクチャである他のピクチャ（例えば、リーディングピクチャ６０４、トレーリングピクチャ６０６）と比較すると、表現するのに比較的多くのビットを必要とすることになる。第二に、ＩＲＡＰピクチャ６０２の存在が時間的予測を中断するので（これは、デコーダが復号プロセスをリフレッシュし、このために復号プロセスのアクションのうちの１つが、復号ピクチャバッファ（ＤＰＢ）にある前の参照ピクチャを除去するからである）、ＩＲＡＰピクチャ６０２は、復号順序６０８でＩＲＡＰピクチャ６０２の後に来るピクチャのコーディング効率を低下させる（すなわち、表現するのにより多くのビットを必要とする）。こうしたピクチャには、インター予測コーディング用の参照ピクチャが少ないためである。

【0118】

ＩＲＡＰピクチャ６０２とみなされるピクチャタイプの中で、ＨＥＶＣのＩＤＲピクチャは、他のピクチャタイプと比較すると、シグナリングおよび導出が異なる。その違いのいくつかは、以下の通りである。

【0119】

ＩＤＲピクチャのピクチャ順序カウント（ＰＯＣ）値のシグナリングおよび導出については、ＰＯＣの最上位ビット（ＭＳＢ）部分が前の重要なピクチャから導出されるのではなく、単に０と等しくなるように設定される。

【0120】

参照ピクチャ管理に必要なシグナリング情報については、ＩＤＲピクチャのスライスヘッダは、参照ピクチャ管理を支援するようにシグナリングされる必要がある情報を含まない。他のピクチャタイプ（すなわちＣＲＡ、トレーリング、時間的サブレイヤアクセス（ＴＳＡ）など）については、下で説明される参照ピクチャセット（ＲＰＳ）などの情報または他の形態の同様の情報（例えば、参照ピクチャリスト）が参照ピクチャマーキングプロセス（すなわち、参照に使用される、または参照に使用されない、復号済みピクチャバッファ（ＤＰＢ）における参照ピクチャのステータスを決定するプロセス）に必要である。しかしながら、ＩＤＲピクチャについては、そのような情報をシグナリングする必要はない。ＩＤＲが存在することで、ＤＰＢにおける全ての参照ピクチャを復号プロセスが参照に使用されないとして単にマークしなければならないことを示しているからである。

【0121】

ＨＥＶＣおよびＶＶＣにおいて、ＩＲＡＰピクチャおよびリーディングピクチャには、異なるＮＡＬユニットタイプ（ＮＵＴ）が与えられ、その結果、それらはシステムレベルアプリケーションによって容易に識別され得る。例えば、ビデオスプライサは、特に、ＩＲＡＰピクチャを非ＩＲＡＰピクチャから識別し、リーディングピクチャをトレーリングピクチャから識別する（ＲＡＳＬピクチャおよびＲＡＤＬピクチャを決定することを含む）ために、コーディング済みビットストリームにおけるシンタックス要素の過度な詳細を理解することなく、コーディング済みピクチャタイプを理解する必要がある。トレーリングピクチャは、ＩＲＡＰピクチャに関連付けられ、かつ、出力順序においてＩＲＡＰピクチャに続くピクチャである。特定のＩＲＡＰピクチャに関連付けられたピクチャは、復号順序において特定のＩＲＡＰピクチャに続き、復号順序において任意の他のＩＲＡＰピクチャに先行する。このために、ＩＲＡＰおよびリーディングピクチャに自身のＮＡＬユニットタイプを与えることは、そのような適用を助け得る。

【0122】

ＨＥＶＣにおいて、すべてのピクチャには、ＰｉｃＯｒｄｅｒＣｎｔＶａｌとして示されるＰＯＣ値が割り当てられる。ＰＯＣには３つの主な用途がある。すなわち、ピクチャを一意に識別すること、同一のＣＶＳにおける他のピクチャに対する出力位置を示すこと、および、下位レベルのビデオコーディングレイヤ（ＶＣＬ）復号プロセス内で動きベクトルスケーリングを実行することである。同一のＣＶＳにおけるすべてのピクチャは固有のＰＯＣ値を有する。異なるＣＶＳからのピクチャは、同一のＰＯＣ値を共有し得るが、ピクチャはなお一意に識別され得る。なぜなら、１つのＣＶＳからのピクチャが別のＣＶＳの任意のピクチャと混ざる可能性が無いからである。ＰＯＣ値のギャップはＣＶＳにおいて許可される。すなわち、出力順序において連続する２つのピクチャ間のＰＯＣ値の差は、１より多く異なり得る（実際、連続するピクチャについてのＰＯＣ値が変動し得る量は任意に変動できる）。

【0123】

ＨＥＶＣにおいて、ピクチャのＰＯＣ値は、スライスヘッダにおけるコードワードを使用してシグナリングされる。許可されるＰＯＣ値の範囲は、－２^３１から２^３１－１なので、スライスヘッダにおけるビットを節約するために、ＰＯＣ値の最下位ビット（ＰＯＣＬＳＢ）のみがシグナリングされる。ＰＯＣＬＳＢに使用するためのビットの数は、４から１６の間であり得、ＳＰＳにおいてシグナリングされる。残りのビットは、最上位ＰＯＣ値ビット（ＰＯＣＭＳＢ）である。ＰＯＣＬＳＢのみがスライスヘッダにおいてシグナリングされるので、現ピクチャのＰＯＣＭＳＢは、ｐｒｅｖＴｉｄ０Ｐｉｃと呼ばれる前のピクチャから導出される。ピクチャが削除されるときでも同一の方式でＰＯＣ導出が機能するには、ｐｒｅｖＴｉｄ０Ｐｉｃが、ＲＡＳＬピクチャ、ＲＡＤＬピクチャ、またはサブレイヤ非参照ピクチャでない時間的レイヤ０の直前のピクチャに設定される。デコーダは、現ピクチャのＰＯＣ値をｐｒｅｖＴｉｄ０ＰｉｃピクチャのＰＯＣ値と比較することによってＰＯＣＭＳＢ値を導出する。

【0124】

残念なことに既存のコーディング設計は欠点を有する。例えば、ＳＨＶＣおよびＭＶ－ＨＥＶＣにおいて、混在したＩＲＡＰおよび非ＩＲＡＰピクチャが同一のアクセスユニット（例えば図５におけるＡＵ５０６におけるピクチャ５１１および５１５）内に含まれ得るが、設計は非常に複雑である。実際、この設計の一般的な復号プロセスは、最新のＨＥＶＣ規格の条項Ｆ．８．１におけるテキストの複数のページを使用してＳＨＶＣおよびＭＶ－ＨＥＶＣにおいて指定される。テキストは、ＮｏＣｌｒａｓＯｕｔｐｕｔＦｌａｇ、ＬａｙｅｒＩｎｉｔｉａｌｉｚｅｄＦｌａｇ、ＬａｙｅｒＲｅｓｅｔＦｌａｇ、ＦｉｒｓｔＰｉｃＩｎＬａｙｅｒＤｅｃｏｄｅｄＦｌａｇ、ＮｕｍＰｒｅｄｉｃｔｅｄＬａｙｅｒｓ、ＩｄＰｒｅｄｉｃｔｅｄＬａｙｅｒ、ＩｄＤｉｒｅｃｔＲｅｆＬａｙｅｒ、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ、ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ、ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ０、ＮｕｍＡｃｔｉｖｅＲｅｆＬａｙｅｒＰｉｃｓ１などを含む多くのグローバルフラグ／変数／リストの使用を伴う。アクセスユニット内における混在したＩＲＡＰおよび非ＩＲＡＰピクチャに対するサポートを提供するＳＨＶＣおよびＭＶ－ＨＥＶＣにおける多くの他の箇所も複雑である。これはＰＯＣ導出プロセスを含む。

【0125】

各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによってコーディングを簡略化する技法が本明細書において開示される。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0126】

図７は、漸次復号リフレッシュ（ＧＤＲ）技法７００を実装するよう構成されるビデオビットストリーム７５０を示す。本明細書において使用される場合、ビデオビットストリーム７５０は、コーディング済みビデオビットストリーム、ビットストリームとも称され得るか、または、その変形で称され得る。図７に示されるように、ビットストリーム７５０は、シーケンスパラメータセット（ＳＰＳ）７５２、ピクチャパラメータセット（ＰＰＳ）７５４、スライスヘッダ７５６、およびイメージデータ７５８を含む。

【0127】

ＳＰＳ７５２には、ピクチャのシーケンス（ＳＯＰ）に含まれる全ピクチャに共通のデータが含まれている。それに対して、ＰＰＳ７５４は、ピクチャ全体に共通のデータを含む。スライスヘッダ７５６は、現スライスに関する情報、例えば、スライスタイプ、参照ピクチャのうちのどれが用いられるか、などといった情報を含む。ＳＰＳ７５２およびＰＰＳ７５４は、パラメータセットと総称され得る。ＳＰＳ７５２、ＰＰＳ７５４、およびスライスヘッダ７５６は、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのタイプである。ＮＡＬユニットは、後に続くデータのタイプ（例えば、コーディングビデオデータ）のインジケーションを含むシンタックス構造である。ＮＡＬユニットはビデオコーディングレイヤ（ＶＣＬ）および非ＶＣＬＮＡＬユニットに分類される。ＶＣＬＮＡＬユニットは、ビデオピクチャにおけるサンプルの値を表すデータを含み、非ＶＣＬＮＡＬユニットは、パラメータセットなどの任意の関連付けられた追加情報（複数のＶＣＬＮＡＬユニットに適用し得る重要データ）および補足拡張情報（復号されたビデオ信号の使用性を促進し得るが、ビデオピクチャにおけるサンプルの値を復号するのに必要でないタイミング情報および他の補足データ）を含む。当業者であれば、ビットストリーム７５０は、実際の適用において他のパラメータおよび情報を含み得ることを理解する。

【0128】

図７のイメージデータ７５８は、符号化または復号されているイメージまたはビデオに関連付けられたデータを含む。イメージデータ７５８は単に、ビットストリーム７５０に保持されるペイロードまたはデータと称され得る。実施形態において、イメージデータ７５８は、ＧＤＲピクチャ７０２、１または複数のトレーリングピクチャ７０４、および復旧ポイントピクチャ７０６を含むＣＶＳ７０８（またはＣＬＶＳ）を含む。実施形態において、ＧＤＲピクチャ７０２は、ＣＶＳ開始（ＣＶＳＳ）ピクチャと称される。ＣＶＳ７０８は、ビデオビットストリーム７５０におけるすべてのコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）についてのコーディング済みビデオシーケンスである。特に、ビデオビットストリーム７５０がシングルレイヤを含むとき、ＣＶＳおよびＣＬＶＳは同一である。ＣＶＳおよびＣＬＶＳは、ビデオビットストリーム７５０が複数のレイヤを含むときだけ異なる。実施形態において、トレーリングピクチャ７０４は、ＧＤＲピクチャの形態とみなされ得る。なぜなら、それらはＧＤＲ期間において復旧ポイントピクチャ７０６に先行するからである。

【0129】

実施形態において、ＧＤＲピクチャ７０２、トレーリングピクチャ７０４、および復旧ポイントピクチャ７０６は、ＣＶＳ７０８におけるＧＤＲ期間を定義し得る。実施形態において、復号順序は、ＧＤＲピクチャ７０２で開始し、トレーリングピクチャ７０４に継続し、その後、復旧ピクチャ７０６に進む。

【0130】

ＣＶＳ７０８は、ＧＤＲピクチャ７０２で開始し、次のＧＤＲピクチャまで（ただしこれを含まない）の、または、ビットストリーム７５０の終了までのすべてのピクチャ（またはその一部）を含む一連のピクチャ（またはその一部）である。ＧＤＲ期間は、ＧＤＲピクチャ７０２で開始する、復旧ポイントピクチャ７０６まで（これを含む）のすべてのピクチャを含む一連のピクチャである。ＣＶＳ７０８のための復号プロセスは常にＧＤＲピクチャ７０２で開始する。

【0131】

図７に示されるように、ＧＤＲ技法７００または原理は、ＧＤＲピクチャ７０２で開始し復旧ポイントピクチャ７０６で終了する一連のピクチャに対して機能する。ＧＤＲピクチャ７０２は、イントラ予測を使用してすべてコーディングされたブロック（すなわち、イントラ予測ブロック）を含むリフレッシュ／クリーン領域７１０、および、インター予測を使用してすべてコーディングされたブロック（すなわちインター予測ブロック）を含む未リフレッシュ／ダーティ領域７１２を含む。

【0132】

ＧＤＲピクチャ７０２に直接隣接するトレーリングピクチャ７０４は、イントラ予測を使用してコーディングされた第１部分７１０Ａ、および、インター予測を使用してコーディングされた第２部分７１０Ｂを有するリフレッシュ／クリーン領域７１０を含む。第２部分７１０Ｂは、例えば、ＣＶＳ７０８のＧＤＲ期間内の先行するピクチャのリフレッシュ／クリーン領域７１０を参照することによってコーディングされる。示されるように、トレーリングピクチャ７０４のリフレッシュ／クリーン領域７１０は、コーディングプロセスが一貫した方向（例えば、左から右）に動く、または進行するにつれて拡張し、これに対応して、未リフレッシュ／ダーティ領域７１２が縮小する。最終的に、リフレッシュ／クリーン領域７１０のみを含む復旧ポイントピクチャ７０６は、コーディングプロセスから取得される。特に、下で更に説明されるように、インター予測ブロックとしてコーディングされるリフレッシュ／クリーン領域７１０の第２部分７１０Ｂは、参照ピクチャにおけるリフレッシュ／クリーン領域７１０のみを指し得る。

【0133】

図７に示されるように、ＣＶＳ７０８におけるＧＤＲピクチャ７０２、トレーリングピクチャ７０４、および復旧ポイントピクチャ７０６のスライスは各々、それら自体のＶＣＬＮＡＬユニット７３０内に含まれる。

【0134】

実施形態において、ＣＶＳ７０８におけるＧＤＲピクチャ７０２を含むＶＣＬＮＡＬユニット７３０は、ＧＤＲＮＡＬユニットタイプ（ＧＤＲ＿ＮＵＴ）を有する。すなわち、実施形態において、ＣＶＳ７０８におけるＧＤＲピクチャ７０２を含むＶＣＬＮＡＬユニット７３０は、トレーリングピクチャ７０４および復旧ポイントピクチャ７０６に対する、それ自体の固有のＮＡＬユニットタイプを有する。実施形態において、ＧＤＲ＿ＮＵＴは、ビットストリーム７５０がＧＤＲピクチャ７０２から開始することを許可し、ビットストリーム７５０はイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャから開始する必要はない。ＧＤＲピクチャ７０２のＶＣＬＮＡＬユニット７３０をＧＤＲ＿ＮＵＴとして指定することにより、例えば、ＣＶＳ７０８における最初のＶＣＬＮＡＬユニット７３０がＧＤＲピクチャ７０２を含むことをデコーダに示し得る。実施形態において、ＧＤＲピクチャ７０２はＣＶＳ７０８における最初のピクチャである。実施形態において、ＧＤＲピクチャ７０２は、ＧＤＲ期間における最初のピクチャである。

【0135】

図８は、エンコーダ制約を使用してＧＤＲをサポートするときの望ましくない動き検索８００を示す概略図である。示されるように、動き検索８００は、現ピクチャ８０２および参照ピクチャ８０４を描画する。現ピクチャ８０２および参照ピクチャ８０４は各々、イントラ予測でコーディングされたリフレッシュ領域８０６、インター予測でコーディングされたリフレッシュ領域８０８、および、未リフレッシュ領域８１０を含む。リフレッシュ領域８０６、リフレッシュ領域８０８、および未リフレッシュ領域８１０は、図７におけるリフレッシュ／クリーン領域７１０の第１部分７１０Ａ、リフレッシュ／クリーン領域７１０の第２部分７１０Ｂ、および、未リフレッシュ／ダーティ領域７１２と同様である。

【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】

実施形態において、図５における各ピクチャ５１１、５１３、５１５－５１８は、図９において示されるピクチャ９１４と同一または同様の方式で、ＰＵ（例えばＰＵ９０１）の一部であるか、またはそれに含まれる。したがって、図５における各ＡＵ５０６は、各レイヤにおいてＰＵを含む。しかしながら、説明を容易にするために、図９のＰＵ９０１全体は図５に描画されない。むしろ、それらのＰＵからのピクチャ（例えばピクチャ５１１、５１３、５１５－５１８）のみが図５に示される。

【0165】

実施形態において、ＣＶＳＳＡＵとして指定される、図５におけるＣＬＶＳ５４０の第１または最初のＡＵ５０６は、各レイヤ（例えばレイヤ５３１および５３２）についてのＰＵ（例えばＰＵ９０１）を含む。さらに、ＣＶＳＳＡＵにおけるそれらのＰＵの各々におけるコーディング済みピクチャ（例えばピクチャ５１１、５１３）はＣＬＶＳＳピクチャである。上で記載されたように、ＣＬＶＳＳピクチャは、ＩＲＡＰピクチャ、ＧＤＲピクチャ、または別のランダムアクセスポイントピクチャであり得る。実施形態において、特定のピクチャ（例えばＲＡＳＬピクチャ）が復号可能でないことがあり得るのでデコーダによって出力されないことを示すために、ＣＬＶＳＳピクチャは、１に等しく設定された復旧前出力無しフラグ（すなわち、ＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙフラグ）を有する。実際、そのようなピクチャは、ビットストリームに存在しないピクチャへの参照を含み得る。

【0166】

実施形態において、ＣＶＳＳＡＵおよび／またはＣＬＶＳ（例えばＣＬＶＳ５４０）におけるレイヤの数は、ＶＰＳ（例えば９０４）によって指定される。

【0167】

当業者であれば、実際の適用において、ビットストリーム９００が、他のパラメータおよび情報を含み得ることを理解する。

【0168】

図１０は、ビデオデコーダ（例えばビデオデコーダ４００）によって実装される復号の方法１０００の実施形態である。方法１０００は、ビットストリームがビデオエンコーダ（例えばビデオエンコーダ３００）から直接または間接的に受信された後に実行され得る。方法１０００は、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによって復号プロセスを改善し、これにより、現在の規格と比べてコーディングを簡略化する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0169】

ブロック１００２において、ビデオデコーダは、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）（例えば、ＣＶＳＳＡＵとして指定されるＡＵ５０６）を含むビットストリーム（例えばビットストリーム９０１）を受信する。実施形態において、ＣＶＳＳＡＵは、各レイヤ（例えばレイヤ５３１およびレイヤ５３２）についてのピクチャユニット（ＰＵ）（例えばＰＵ９０１）を含む。実施形態において、各ＰＵにおけるコーディング済みピクチャ（例えばコーディング済みピクチャ５１１および５１５）は、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである。

【0170】

実施形態において、ビデオデコーダは、各ＰＵにおけるコーディング済みピクチャがＣＬＶＳＳピクチャであると予期する。しかしながら、デコーダが、この条件が真でないと判定した場合、デコーダは、エラーを検出するか、エラーをシグナリングするか、受信されたビットストリーム（またはその一部）の再送信を要求するか、または、いくつかの他の是正措置を講じて、適合するビットストリームが受信されることを確実にし得る。

【0171】

実施形態において、ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである。実施形態において、ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである。実施形態において、ＣＬＶＳＳピクチャは、１に等しい復旧前出力無しフラグを有する。

【0172】

実施形態において、ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される。すなわち、ＶＰＳは、いくつのレイヤがＣＬＶＳの各ＡＵに含まれるかを示す。実施形態において、ＣＶＳＳＡＵは、コーディング済みビデオシーケンス（ＣＶＳ）の最初のＡＵである。

【0173】

実施形態において、ＰＵはレイヤアクセスユニットと称される。実施形態において、ＣＶＳＳＡＵは、ＣＶＳＳＡＵの各レイヤがＰＵの１つを含むので、完全ＡＵと称される。

【0174】

ブロック１００４において、ビデオデコーダは、ピクチャ順序カウント（ＰＯＣ）値に基づいて、レイヤの１つからコーディング済みピクチャ（例えばピクチャ９１４）を識別する。ブロック１００６において、ビデオデコーダは、コーディング済みピクチャを復号して復号済みピクチャを取得する。復号済みピクチャは、復号されると、電子デバイス（例えばスマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど）のディスプレイまたは画面上でユーザに表示するためのイメージまたはビデオシーケンスを生成する、または作成するために使用され得る。

【0175】

図１１は、ビデオエンコーダ（例えばビデオエンコーダ３００）によって実装されるビデオビットストリームを符号化する方法１１００の実施形態である。方法１１００は、（例えばビデオからの）ピクチャがビデオビットストリームに符号化され、その後、ビデオデコーダ（例えばビデオデコーダ４００）へ送信されるときに実行され得る。方法１１００は、各コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）が完全ＡＵであり、かつ、ＣＶＳＳＡＵにおける各ピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約されるビットストリームを利用することによって符号化プロセスを改善し、これにより、現在の規格と比べてコーディングを簡略化する。これにより、ランダムアクセスポイント（ＲＡＰ）が、すべてのコーディング済みビデオシーケンス（ＣＶＳ）の開始において、マルチレイヤビットストリームの各レイヤについて提供されることを確実にする。したがって、ビデオコーディングにおけるコーダ／デコーダ（すなわち「コーデック」）は、現在のコーデックと比較して改善される。現実問題としては、ビデオコーディングプロセスの改善によって、ビデオが送信、受信、および／または視聴されるとき、より良いユーザエクスペリエンスがユーザに提供される。

【0176】

ブロック１１０２において、ビデオエンコーダは、コーディング済みピクチャ（例えばコーディング済みピクチャ５１１および５１５）を含むピクチャユニット（ＰＵ）（例えばＰＵ９０１）をコーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）（例えば、ＣＶＳＳＡＵとして指定されたＡＵ５０６）の各レイヤ（例えばレイヤ５３１およびレイヤ５３２）に挿入する。実施形態において、コーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである。実施形態において、コーディング済みピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように、ビデオエンコーダは制約される。すなわち、ビデオエンコーダは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるコーディング済みピクチャを有することを要求される。そのような制約または要件は、ビットストリームが、本明細書において示されるように修正された、例えばＶＶＣまたはいくつかの他の規格に適合することを確実にする。しかしながら、エンコーダは、異なる規格または同じ規格の異なるバージョンで動作するときなど、そのように制約されない他のモードで動作することも可能であり得る。

【0177】

実施形態において、ＣＬＶＳＳピクチャはイントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである。実施形態において、ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである。実施形態において、ＣＬＶＳＳピクチャは、１に等しい復旧前出力無しフラグを有する。

【0178】

【0179】

【0180】

ブロック１１０４において、ビデオエンコーダは、ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）（例えばＣＬＶＳ５４０）をビットストリームに符号化する。ブロック１１０６において、ビデオエンコーダは、ビデオデコーダへの通信のためにビットストリームを格納する。ビデオビットストリームは、ビデオビットストリームがビデオデコーダへ送信されるまでメモリに格納され得る。符号化されたビデオビットストリームは、ビデオデコーダによって受信されると、電子デバイス（例えば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど）のディスプレイまたは画面上でユーザに表示するためのイメージまたはビデオシーケンスを生成または作成するために（例えば上で説明されたように）復号され得る。

【0181】

なお、本明細書において説明される解決手段はなお、レイヤ間の非同期ＩＲＡＰピクチャを可能にする。しかしながら、簡潔にするために、最低レイヤにおいてＩＲＡＰピクチャを含むが他のレイヤにおいて非ＩＲＡＰピクチャを含むＡＵから開始する復号プロセスは、規範的に指定されない。しかしながら、設計がレイヤ間の非同期ＩＲＡＰピクチャを許可する限り、そのような許容の技術的利益はなお、実践において実装によって実現され得る。

【0182】

以下のシンタックスおよびセマンティックスは、本明細書において開示される実施形態を実装するために利用され得る。以下の説明は、最新ＶＶＣドラフト仕様である基本テキストに対するものである。

【0183】

実施形態において、（特定の値ｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する特定のピクチャの）関連付けられたＩＲＡＰピクチャは、（存在する場合）ｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する、復号順序における前のＩＲＡＰピクチャであり、その間にはｌａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＧＤＲピクチャは無い。ｎｕｈ＿ｌａｙｅｒ＿ｉｄは、ＶＣＬＮＡＬユニットが属するレイヤの識別子、または、非ＶＣＬＮＡＬユニットが適用するレイヤの識別子を指定する。ｎｕｈ＿ｌａｙｅｒ＿ｉｄの値は、０から５５（両端を含む）の範囲とする。ｎｕｈ＿ｌａｙｅｒ＿ｉｄの他の値は、ＩＴＵ－Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のために予約される。

【0184】

本明細書おいて使用される場合、ＰＵはレイヤアクセスユニットとも称され得る。実施形態において、クリーンランダムアクセス（ＣＲＡ）レイヤアクセスユニットは、コーディング済みピクチャがＣＲＡピクチャであるレイヤアクセスユニットである。実施形態において、クリーンランダムアクセス（ＣＲＡ）ピクチャは、各ＶＣＬＮＡＬユニットが、ＣＲＡ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＩＲＡＰピクチャである。実施形態において、ＣＲＡピクチャは、その復号プロセスにおいてインター予測を使用せず、復号順序において、ビットストリームにおける第１ピクチャであり得るか、または、ビットストリームにおいて後に出現し得る。実施形態において、ＣＲＡピクチャは、関連付けられたＲＡＤＬまたはＲＡＳＬピクチャを有し得る。ＣＲＡピクチャが、１に等しいＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙＦｌａｇを有するとき、関連付けられたＲＡＳＬピクチャはデコーダによって出力されない。なぜなら、それらは、ビットストリームに存在しないピクチャへの参照を含み得るので、それらは復号可能でないことがあり得るからである。

【0185】

実施形態において、コーディング済みレイヤビデオシーケンス（ＣＬＶＳ）は、復号順序において、ＣＬＶＳＳＰＵ、および、それに続く、ＣＬＶＳＳＰＵである任意の後続のＰＵまで（ただしそれを含まない）のすべての後続のＰＵを含む、ＣＬＶＳＳＰＵでない０またはより多くのＰＵから構成される、同一の値のｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＰＵのシーケンスである。実施形態において、ＣＬＶＳＳＰＵは、ＩＤＲＰＵ、ＣＲＡＰＵ、またはＧＤＲＰＵであり得る。ＮｏＯｕｔｐｕｔＢｅｆｏｒｅＲｅｃｏｖｅｒｙＦｌａｇの値は、各ＩＤＲＰＵ、ならびに、１に等しいＨａｎｄｌｅＣｒａＡｓＣｌｖｓＳｔａｒｔＦｌａｇを有する各ＣＲＡＰＵ、および、復号順序においてビットストリームのレイヤにおける第１ＰＵ、または、復号順序においてＥＯＳＮＡＬユニットに続くビットストリームのレイヤにおける第１ＰＵである各ＣＲＡまたはＧＤＲＰＵについて、１に等しい。

【0186】

実施形態において、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）レイヤアクセスユニットは、コーディング済みピクチャがＣＬＶＳＳピクチャであるレイヤアクセスユニットである。コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャは、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャ、または、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＧＤＲピクチャであるコーディング済みピクチャである。

【0187】

実施形態において、コーディング済みビデオシーケンス（ＣＶＳ）は、復号順序において、ＣＶＳＳアクセスユニット、および、それに続く、ＣＶＳＳアクセスユニットである任意の後続のアクセスユニットまで（ただしそれを含まない）のすべての後続のアクセスユニットを含む、ＣＶＳＳアクセスユニットでない０またはより多くのアクセスユニットから構成されるアクセスユニットのシーケンスである。

【0188】

実施形態において、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニットは、ＣＶＳにおける各レイヤについてレイヤアクセスユニットがあり、かつ、各レイヤアクセスユニットにおけるコーディング済みピクチャがＣＬＶＳＳピクチャであるアクセスユニットである。なお、これは、各ＣＶＳＳＡＵが完全なＡＵであること、および、ＣＶＳＳＡＵにおける各ピクチャがＣＬＶＳＳピクチャであることを要求する。実施形態において、漸次復号リフレッシュ（ＧＤＲ）アクセスユニットは、各現在のレイヤアクセスユニットにおけるコーディング済みピクチャがＧＤＲピクチャであるアクセスユニットである。実施形態において、漸次復号リフレッシュ（ＧＤＲ）レイヤアクセスユニットは、コーディング済みピクチャがＧＤＲピクチャであるレイヤアクセスユニットである。実施形態において、漸次復号リフレッシュ（ＧＤＲ）ピクチャは、各ＶＣＬＮＡＬユニットがＧＤＲ＿ＮＵＴに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するピクチャである。

【0189】

ＳＰＳシンタックスは以下の通りである。

【表1】

【0190】

実施形態において、上の太字のシンタックス要素はＶＰＳに含まれ得る。

【0191】

スライスヘッダシンタックスは以下の通りである。

【表2】

【0192】

実施形態において、シンタックス条件部分「＆＆ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＞＝ＩＤＲ＿Ｗ＿ＲＡＤＬ＆＆ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＜＝ＧＤＲ＿ＮＵＴ」は削除され得る。すなわち、ｐｏｃ＿ｍｓｂ＿ｉｎ＿ｒａｐ＿ｐｉｃｓ＿ｆｌａｇが１に等しいとき、任意の値のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するスライスについてｐｏｃ＿ｍｓｂ＿ｖａｌをシグナリングする。

【0193】

実施形態において、シンタックス要素ｐｏｃ＿ｍｓｂ＿ｖａｌの存在を条件とするために、１つのピクチャレベルフラグを追加する。すなわち、エンコーダが、ｐｏｃ＿ｍｓｂ＿ｉｎ＿ｒａｐ＿ｐｉｃｓ＿ｆｌａｇが１に等しいとき、ＩＲＡＰまたはＧＤＲピクチャの各スライスについて個別にｐｏｃ＿ｍｓｂ＿ｖａｌをシグナリングするか、またはシグナリングしないかを決定することを可能にする。

【0194】

実施形態において、上の両方の代替形態を適用する。実施形態において、ｓｅ（ｖ）またはｕｅ（ｖ）を使用してｐｏｃ＿ｍｓｂ＿ｖａｌをシグナリングし、ｐｏｃ＿ｍｓｂ＿ｌｅｎ＿ｍｉｎｕｓ１シンタックス要素をＳＰＳシンタックスから削除する。

【0195】

ＮＡＬユニットヘッダセマンティックスが提供される。

【0196】

ｎｕｈ＿ｌａｙｅｒ＿ｉｄは、ＶＣＬＮＡＬユニットが属するレイヤの識別子、または、非ＶＣＬＮＡＬユニットが適用するレイヤの識別子を指定する。

【0197】

ｎｕｈ＿ｌａｙｅｒ＿ｉｄの値は、コーディング済みピクチャのすべてのＶＣＬＮＡＬユニットについて同一とする。コーディング済みピクチャまたはレイヤアクセスユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄの値は、コーディング済みピクチャまたはレイヤアクセスユニットのＶＣＬＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄの値である。

【0198】

ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅは、ＮＡＬユニットタイプ、すなわち、ＮＡＬユニットに含まれるＲＢＳＰデータ構造のタイプを指定する。

【0199】

ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値は、ピクチャのすべてのコーディング済みスライスＮＡＬユニットについて同一とする。ピクチャまたはレイヤアクセスユニットは、ピクチャまたはレイヤアクセスユニットのコーディング済みスライスＮＡＬユニットと同一のＮＡＬユニットタイプを有すると称される。なお、上の２つの段落は、ＡＵ内のＶＣＬＮＡＬユニットが、異なるＮＡＬユニットタイプを有することを可能にし、これにより、ＡＵ内の混在するＲＡＰおよび非ＲＡＰピクチャが可能となる。ＲＡＰピクチャは、ＩＤＲ、ＣＡＲ、またはＧＤＲピクチャである。

【0200】

ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値は、ＣＶＳＳアクセスユニットのピクチャについて同一であるものとする。

【0201】

アクセスユニットの順序およびＣＶＳとの関連付けが提供される。

【0202】

規格に適合するビットストリームは、１または複数のＣＶＳを含む。ＣＶＳは、１または複数のアクセスユニットから構成される。ＣＶＳの第１アクセスユニットは、ＣＶＳＳアクセスユニットである。ここで、各現在のレイヤアクセスユニットは、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰレイヤアクセスユニット、または、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＧＤＲレイヤアクセスユニットのいずれかである、ＣＬＶＳＳレイヤアクセスユニットである。各ＣＶＳＳアクセスユニットは、ＣＶＳに存在するレイヤの各々におけるピクチャを有するものとする。ビットストリーム適合性の要件として、シーケンス終了ＮＡＬユニットまたはビットストリーム終了ＮＡＬユニットを含むアクセスユニットの後の次のアクセスユニットにおける各レイヤアクセスユニットは、存在するとき、ＩＤＲレイヤアクセスユニットもしくはＣＲＡレイヤアクセスユニットであり得るＩＲＡＰレイヤアクセスユニット、またはＧＤＲレイヤアクセスユニットであるものとする。

【0203】

ＳＰＳセマンティックスが提供される。

【0204】

ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４は、以下のようにピクチャ順序カウントのために復号プロセスにおいて使用される変数ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂの値を指定する。

【0205】

ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ＝２（ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４＋４）

【0206】

ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４の値は、０から１２（両端を含む）の範囲とする。

【0207】

１に等しいｐｏｃ＿ｍｓｂ＿ｉｎ＿ｒａｐ＿ｐｉｃｓ＿ｆｌａｇは、ｐｏｃ＿ｍｓｂ＿ｖａｌシンタックス要素が、ＳＰＳを参照し、かつ、ＶＣＬＮＡＬユニットがＩＤＲ＿Ｗ＿ＲＡＤＬからＧＤＲ＿ＮＵＴ（両端を含む）の範囲のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するピクチャについてシグナリングされることを指定する。０に等しいｐｏｃ＿ｍｓｂ＿ｉｎ＿ｒａｐ＿ｐｉｃｓ＿ｆｌａｇは、ｐｏｃ＿ｍｓｂ＿ｖａｌシンタックス要素が、ＳＰＳを参照するピクチャについてシグナリングされないことを指定する。

【0208】

ｐｏｃ＿ｍｓｂ＿ｌｅｎ＿ｍｉｎｕｓ１＋１は、存在するとき、ｐｏｃ＿ｍｓｂ＿ｖａｌシンタックス要素の長さをビットで指定する。ｐｏｃ＿ｍｓｂ＿ｌｅｎ＿ｍｉｎｕｓ１の値は、０から３２－ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４－５（両端を含む）の範囲とする。

【0209】

スライスヘッダセマンティックスが提供される。

【0210】

ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂは、ピクチャ順序カウントモジュロＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂを現ピクチャについて指定する。ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックス要素の長さは、ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４＋４ビットである。ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂの値は、０からＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ－１（両端を含む）の範囲とする。

【0211】

ｐｏｃ＿ｍｓｂ＿ｖａｌは、現ピクチャのＰＯＣＭＳＢ値を指定する。シンタックス要素ｐｏｃ＿ｍｓｂ＿ｖａｌの長さはｐｏｃ＿ｍｓｂ＿ｌｅｎ＿ｍｉｎｕｓ１＋１ビットである。

【0212】

コーディング済みピクチャの復号プロセスが提供される。

【0213】

ＰｉｃｔｕｒｅＯｕｔｐｕｔＦｌａｇが以下のように設定される。

【0214】

以下の条件の１つが真である場合、ＰｉｃｔｕｒｅＯｕｔｐｕｔＦｌａｇは０に等しいように設定される。

【0215】

現ピクチャはＲＡＳＬピクチャであり、関連付けられたＩＲＡＰピクチャのＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇは１に等しい。

【0216】

ｇｄｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは１に等しく、現ピクチャは、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＧＤＲピクチャである。

【0217】

ｇｄｒ＿ｅｎａｂｌｅｄ＿ｆｌａｇは１に等しく、現ピクチャは、１に等しいＮｏＩｎｃｏｒｒｅｃｔＰｉｃＯｕｔｐｕｔＦｌａｇを有するＧＤＲピクチャに関連付けられ、現ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌは、関連付けられたＧＤＲピクチャのＲｐＰｉｃＯｒｄｅｒＣｎｔＶａｌより小さい。

【0218】

現ピクチャは出力レイヤに属さない。

【0219】

そうでない場合、ＰｉｃｔｕｒｅＯｕｔｐｕｔＦｌａｇはｐｉｃ＿ｏｕｔｐｕｔ＿ｆｌａｇに等しく設定される。

【0220】

ピクチャ順序カウントの復号プロセスが提供される。

【0221】

このプロセスの出力は、ＰｉｃＯｒｄｅｒＣｎｔＶａｌ、現ピクチャのピクチャ順序カウントである。

【0222】

各コーディング済みピクチャは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌとして示されるピクチャ順序カウント変数に関連付けられる。

【0223】

ｐｏｃ＿ｍｓｂ＿ｖａｌがピクチャについて存在せず、現ピクチャがＣＬＶＳＳピクチャでないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは以下のように導出される。

【0224】

ｐｒｅｖＴｉｄ０Ｐｉｃを、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄおよび０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつ、ＲＡＳＬまたはＲＡＤＬピクチャでない、復号順序における前のピクチャとする。

【0225】

変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂは、ｐｒｅｖＴｉｄ０Ｐｉｃのｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂに等しく設定される。

【0226】

変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、ｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＭｓｂに等しく設定される。

【0227】

現ピクチャの変数ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは以下のように導出される。

【0228】

ｐｏｃ＿ｍｓｂ＿ｖａｌがピクチャについて存在する場合、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、ｐｏｃ＿ｍｓｂ＿ｖａｌ×ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定される。

【0229】

そうでない場合（ｐｏｃ＿ｍｓｂ＿ｖａｌがピクチャについて存在しない）、現ピクチャがＣＬＶＳＳピクチャである場合、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは０に等しく設定される。

【0230】

そうでない場合、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは以下のように導出される。
ｉｆ（（ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＜ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂ）＆＆
（（ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂ－ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ）＞＝（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ／２）））
ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＝ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＋ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ（８－１）
ｅｌｓｅｉｆ（（ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＞ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂ）＆＆
（（ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ－ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂ）＞（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ／２）））
ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＝ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂ－ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ
ｅｌｓｅ
ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＝ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂ

【0231】

ＰｉｃＯｒｄｅｒＣｎｔＶａｌは以下のように導出される。

【0232】

ＰｉｃＯｒｄｅｒＣｎｔＶａｌ＝ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＋ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ（８－２）

【0233】

なお、ｐｏｃ＿ｍｓｂ＿ｖａｌが存在しないすべてのＣＬＶＳＳピクチャは、ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂに等しいＰｉｃＯｒｄｅｒＣｎｔＶａｌを有する。なぜなら、それらのピクチャについて、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは０に等しく設定されるからである。

【0234】

ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値は、－２３１から２３１－１（両端を含む）の範囲とする。

【0235】

１つのＣＶＳにおいて、同一の値のｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する任意の２つのコーディング済みピクチャについてのＰｉｃＯｒｄｅｒＣｎｔＶａｌ値は同一でないものとする。

【0236】

任意の特定のアクセスユニットにおけるすべてのピクチャは、同一の値のＰｉｃＯｒｄｅｒＣｎｔＶａｌを有するものとする。

【0237】

関数ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）は以下のように指定される。

【0238】

ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）＝ピクチャｐｉｃＸのＰｉｃＯｒｄｅｒＣｎｔＶａｌ（８－３）

【0239】

関数ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）は以下のように指定される。

【0240】

ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）＝ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ）－ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＢ）（８－４）

【0241】

ビットストリームは、－２１５から２１５－１の範囲（両端を含む）にない復号プロセスにおいて使用されるＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）の値をもたらすデータを含まないものとする。

【0242】

なお、Ｘを現ピクチャとし、ＹおよびＺを同一のＣＶＳにおける２つの他のピクチャとし、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｙ）およびＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｚ）の両方が正または両方が負であるとき、ＹおよびＺは、Ｘから同一の出力順序方向にあるとみなされる。

【0243】

【0244】

図１２は、開示の実施形態による、ビデオコーディングデバイス１２００（例えばビデオエンコーダ３００またはビデオデコーダ４００）の概略図である。ビデオコーディングデバイス１２００は、本明細書において説明される開示された実施形態を実装するのに好適である。ビデオコーディングデバイス１２００は、データを受信するための入口ポート１２１０および受信機ユニット（Ｒｘ）１２２０、データを処理するためのプロセッサ、論理ユニット、または、中央演算処理装置（ＣＰＵ）１２３０、データを送信するための送信機ユニット（Ｔｘ）１２４０および出口ポート１２５０、ならびに、データを格納するためのメモリ１２６０を含む。ビデオコーディングデバイス１２００はまた、光または電気信号の出口または入口のために、入口ポート１２１０、受信機ユニット１２２０、送信機ユニット１２４０、および出口ポート１２５０に結合される光／電気（ＯＥ）コンポーネントおよび電気／光（ＥＯ）コンポーネントを含み得る。

【0245】

プロセッサ１２３０はハードウェアおよびソフトウェアによって実装される。プロセッサ１２３０は、１または複数のＣＰＵチップ、コア（例えば、マルチコアプロセッサとして）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、およびデジタル信号プロセッサ（ＤＳＰ）として実装されてよい。プロセッサ１２３０は、入口ポート１２１０、受信機ユニット１２２０、送信機ユニット１２４０、出口ポート１２５０、およびメモリ１２６０と通信する。プロセッサ１２３０はコーディングモジュール１２７０を含む。コーディングモジュール１２７０は、上で説明された開示された実施形態を実装する。例えば、コーディングモジュール１２７０は、様々なコーデック機能を実装し、処理し、準備し、または提供する。したがって、コーディングモジュール１２７０を含めることにより、ビデオコーディングデバイス１２００の機能の著しい改善を提供し、ビデオコーディングデバイス１２００の異なる状態への変換をもたらす。代替的に、コーディングモジュール１２７０は、メモリ１２６０に格納された命令として実装され、プロセッサ１２３０によって実行される。

【0246】

ビデオコーディングデバイス１２００はまた、ユーザとの間のデータ通信のために、入力および／または出力（Ｉ／Ｏ）デバイス１２８０を含み得る。Ｉ／Ｏデバイス１２８０は、ビデオデータを表示するためのディスプレイ、音声データを出力するためのスピーカなどの出力デバイスを含んでよい。Ｉ／Ｏデバイス１２８０はまた、キーボード、マウス、トラックボールなどの入力デバイス、および／またはそのような出力デバイスとインタラクトするための対応するインタフェースも含んでよい。

【0247】

メモリ１２６０は、１または複数のディスク、テープドライブ、及びソリッドステートドライブを含み、プログラムが実行のために選択されるときにそのようなプログラムを記憶するために、並びに、プログラム実行中に読み出される命令及びデータを記憶するために、オーバフローデータ記憶デバイスとして使用され得る。メモリ１２６０は、揮発性および／または不揮発性でよく、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、三値連想メモリ（ＴＣＡＭ）および／またはスタティックランダムアクセスメモリ（ＳＲＡＭ）でよい。

【0248】

図１３は、コーディングの手段１３００の実施形態の概略図である。実施形態において、コーディングの手段１３００は、ビデオコーディングデバイス１３０２（例えば、ビデオエンコーダ３００またはビデオデコーダ４００）において実装される。ビデオコーディングデバイス１３０２は、受信手段１３０１を含む。受信手段１３０１は、符号化するピクチャを受信する、または、復号するビットストリームを受信するよう構成される。ビデオコーディングデバイス１３０２は、受信手段１３０１に結合された送信手段１３０７を含む。送信手段１３０７は、ビットストリームをデコーダへ送信する、または、復号されたイメージを表示手段（例えば、Ｉ／Ｏデバイス１２８０の１つ）へ送信するよう構成される。

【0249】

ビデオコーディングデバイス１３０２は記憶手段１３０３を含む。記憶手段１３０３は、受信手段１３０１または送信手段１３０７の少なくとも１つに結合される。記憶手段１３０３は、命令を格納するよう構成される。ビデオコーディングデバイス１３０２はまた、処理手段１３０５を含む。処理手段１３０５は、記憶手段１３０３に結合される。処理手段１３０５は、本明細書に開示される方法を実行するために、記憶手段１３０３に格納された命令を実行するよう構成される。

【0250】

本明細書に記載された例示的な方法の段階は、必ずしも説明された順序で実行される必要はないこともまた、理解されるべきであり、このような方法の段階の順序は、単なる例示的なものとして理解されるべきである。同様に、追加の段階がこのような方法に含まれてよく、特定の段階が、本開示の様々な実施形態において一貫した方法において、省略または組み合されてよい。

【0251】

複数の実施形態が本開示において提供されてきたが、開示されたシステム及び方法は、本開示の趣旨または範囲から逸脱することなく、多数の他の具体的形態で具現化されてよいことが理解されるべきである。本例は、例示的なものであって、限定的なものではないとみなされるべきであり、その意図は、本明細書において与えられた詳細に限定されるべきではない。例えば、様々な要素またはコンポーネントが、別のシステムに組み合わせられ、または、統合されてよく、または、特定の特徴が省略されても、実装されなくてもよい。

【0252】

更に、様々な実施形態に個別または別個に説明及び図示された技法、システム、サブシステム、及び方法が、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わされても統合されてもよい。互いに結合される、互いに直接結合される、または互いに通信するものとして示され説明された他の要素が、電気的であれ、機械的であれ、または別の方法であれ、何らかのインタフェース、デバイス、または中間コンポーネントを介して間接的に結合されても、通信してもよい。変更、置換、及び修正の他の例は、当業者によって確認可能であり、それらは本明細書において開示される主旨及び範囲から逸脱することなく成され得る。
［他の考えられる項目］
（項目１）
ビデオデコーダによって実装される復号の方法であって、
前記ビデオデコーダによって、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）を含むビットストリームを受信する段階であって、前記ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである、段階と、
前記ビデオデコーダによって、ピクチャ順序カウント（ＰＯＣ）値に基づいて、前記レイヤの１つから前記コーディング済みピクチャを識別する段階と、
前記ビデオデコーダによって、前記コーディング済みピクチャを復号して復号済みピクチャを取得する段階と
を備える方法。
（項目２）
前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、項目１に記載の方法。
（項目３）
前記ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである、項目１に記載の方法。
（項目４）
前記ＣＬＶＳＳピクチャは、前記ＰＵのピクチャパラメータセット（ＰＰＳ）に配置された復旧前出力無しフラグに関連付けられ、前記復旧前出力無しフラグは１に等しい、項目１から３のいずれかに記載の方法。
（項目５）
前記ＣＶＳＳＡＵの各レイヤはビデオパラメータセット（ＶＰＳ）によって指定される、項目１から４のいずれかに記載の方法。
（項目６）
前記ＣＶＳＳＡＵは、コーディング済みビデオシーケンス（ＣＶＳ）の最初のＡＵである、項目１から５のいずれかに記載の方法。
（項目７）
前記ＰＵは、レイヤアクセスユニットと称される、項目１から６のいずれかに記載の方法。
（項目８）
前記ＣＶＳＳＡＵの各レイヤは前記ＰＵの１つを含むので、前記ＣＶＳＳＡＵは完全ＡＵと称される、項目１から７のいずれかに記載の方法。
（項目９）
前記コーディング済みピクチャを復号された状態で電子デバイスのディスプレイ上に表示する段階を更に備える、項目１から８のいずれかに記載の方法。
（項目１０）
前記ビデオデコーダによって、第２ＣＶＳＳＡＵを含む第２ビデオビットストリームを受信する段階であって、前記第２ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャはＣＬＶＳＳピクチャでない、段階と、
前記受信に応答して、いくつかの他の訂正措置を講じて、前記第２ビデオビットストリームに対応する適合ビットストリームが、前記コーディング済みピクチャの復号前に受信されることを確実にする段階と
を更に備える、項目１から９のいずれかに記載の方法。
（項目１１）
ビデオエンコーダによって実装される符号化の方法であって、
前記ビデオエンコーダによって、コーディング済みピクチャを含むピクチャユニット（ＰＵ）を、コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入する段階であって、前記ビデオエンコーダは、各レイヤにおける前記コーディング済みピクチャがコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約を受ける、段階と、
前記ビデオエンコーダによって、前記ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化する段階と、
前記ビデオエンコーダによって、ビデオデコーダへの通信のために前記ビットストリームを格納する段階と
を備える方法。
（項目１２）
前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、項目１１に記載の方法。
（項目１３）
前記ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである、項目１１に記載の方法。
（項目１４）
前記ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される、項目１１から１３のいずれかに記載の方法。
（項目１５）
復号デバイスであって、
コーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）を含むビットストリームを受信することを行うよう構成される受信機であって、前記ＣＶＳＳＡＵは、各レイヤについてのピクチャユニット（ＰＵ）を含み、各ＰＵにおけるコーディング済みピクチャは、コーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャである、受信機と、
前記受信機に結合されたメモリであって、命令を記憶するメモリと、
前記メモリに結合されたプロセッサであって、
ピクチャ順序カウント（ＰＯＣ）値に基づいて、前記レイヤの１つから前記コーディング済みピクチャを識別すること、および、
前記コーディング済みピクチャを復号して、復号されたピクチャを取得すること
を前記復号デバイスに行わせるために前記命令を実行するよう構成されるプロセッサと
を備える復号デバイス。
（項目１６）
前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャである、項目１５に記載の復号デバイス。
（項目１７）
前記ＣＬＶＳＳピクチャは、漸次復号リフレッシュ（ＧＤＲ）ピクチャである、項目１５に記載の復号デバイス。
（項目１８）
前記ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される、項目１５から１７のいずれかに記載の復号デバイス。
（項目１９）
符号化デバイスであって、
命令を含むメモリと、
前記メモリに結合されたプロセッサであって、
コーディング済みピクチャを含むピクチャユニット（ＰＵ）をコーディング済みビデオシーケンス開始（ＣＶＳＳ）アクセスユニット（ＡＵ）の各レイヤに挿入することであって、前記符号化デバイスは、前記コーディング済みピクチャが各レイヤにおいてコーディング済みレイヤビデオシーケンス開始（ＣＬＶＳＳ）ピクチャであるように制約される、こと、および、
前記ＣＶＳＳＡＵを含むコーディング済みレイヤビデオシーケンス（ＣＬＶＳ）をビットストリームに符号化すること
を前記符号化デバイスに行わせるために前記命令を実装するよう構成される、プロセッサと、
前記プロセッサに結合された送信機であって、前記ビデオビットストリームをビデオデコーダへ伝送するよう構成される、送信機と
を備える符号化デバイス。
（項目２０）
前記ＣＬＶＳＳピクチャは、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャまたは漸次復号リフレッシュ（ＧＤＲ）ピクチャである、項目１９に記載の符号化デバイス。
（項目２１）
前記ＣＶＳＳＡＵの各レイヤは、ビデオパラメータセット（ＶＰＳ）によって指定される、項目１９から２０のいずれかに記載の符号化デバイス。
（項目２２）
コーディング装置であって、
符号化するピクチャを受信する、または、復号するビットストリームを受信するよう構成される受信機と、
前記受信機に結合された送信機であって、前記ビットストリームをデコーダへ送信する、または、復号されたイメージをディスプレイへ送信するよう構成される送信機と、
前記受信機または前記送信機の少なくとも１つに結合されたメモリであって、命令を格納するよう構成されるメモリと、
前記メモリに結合されたプロセッサであって、前記メモリに格納された前記命令を実行して、項目１から１０のいずれかまたは項目１１から１４のいずれかに記載の方法を実行するよう構成されるプロセッサと
を備えるコーディング装置。
（項目２３）
復号されたピクチャを表示するよう構成されるディスプレイを更に備える、項目２２に記載のコーディング装置。
（項目２４）
システムであって、
エンコーダと、
前記エンコーダと通信するデコーダとを備え、
前記エンコーダまたは前記デコーダは、項目１６から２３のいずれかに記載の復号デバイス、符号化デバイス、または、コーディング装置を含む、
システム。
（項目２５）
コーディングのための手段であって、
符号化するピクチャを受信する、または、復号するビットストリームを受信するよう構成される受信手段と、
前記受信手段に結合された送信手段であって、前記ビットストリームを復号手段へ送信するよう、または、復号されたイメージを表示手段へ送信するよう構成される送信手段と、
前記受信手段または前記送信手段の少なくとも１つに結合された記憶手段であって、命令を格納するよう構成される記憶手段と、
前記記憶手段に結合された処理手段であって、前記記憶手段に格納された前記命令を実行して、項目１から１０のいずれか、および、項目１１から１４のいずれかに記載の方法を実行するよう構成される、処理手段と
を備える手段。

【図1】