(57)【要約】  ピクチャの符号化領域の完了を示すシンタックス構造を説明する。例えばエレメンタリビットストリーム内のシンタックス構造が、ピクチャの符号化領域の完了を示す。シンタックス構造は、ネットワーク抽象化レイヤユニットのタイプ、補足エンハンスメント情報メッセージのタイプ又は別のシンタックス構造とすることができる。例えばエンコーダ等のメディア処理ツールは、ピクチャの符号化領域の完了を検出し、次いで、符号化領域を含むシンタックス構造と、符号化領域の完了を示す異なるシンタックス構造とを、エレメンタリビットストリーム内に所定の順序で出力することができる。デコーダ等の別のメディア処理ツールは、符号化領域を含むシンタックス構造と、符号化領域の完了を示す異なるシンタックス構造とを、エレメンタリビットストリーム内において所定の順序で受け取ることができる。
2017535167.tif 000002
【特許請求の範囲】
【請求項１】
画像又はビデオの領域についての符号化領域を含む１つ以上のシンタックス構造と、前記符号化領域を含む前記１つ以上のシンタックス構造の後に、前記符号化領域の完了を示す異なるシンタックス構造とを、エレメンタリビットストリームの一部として格納するよう構成される、バッファと；
前記異なるシンタックス構造を使用して、前記符号化領域の前記完了を検出するよう構成されるメディア処理ツールと；
を具備するコンピューティングシステム。
【請求項２】
前記メディア処理ツールは、
前記符号化領域を復号して前記領域を再構築する、
よう更に構成される、請求項１に記載のコンピューティングシステム。
【請求項３】
前記異なるシンタックス構造は：
ネットワーク抽象化レイヤ（「ＮＡＬ」）ユニットタイプを有するＮＡＬユニットであって、前記ＮＡＬユニットタイプが当該ＮＡＬユニットを領域の終わりのインジケータとして指定する、ＮＡＬユニット；又は
ペイロードタイプを有する補足エンハンスメント情報（「ＳＥＩ」）メッセージであって、前記ペイロードタイプが当該ＳＥＩメッセージを領域の終わりのインジケータとして指定し、サフィックスＳＥＩメッセージである、ＳＥＩメッセージ；
である、請求項１に記載のコンピューティングシステム。
【請求項４】
前記異なるシンタックス構造は、次のスライスセグメントヘッダのスライスセグメントアドレスが前記エレメンタリビットストリーム内に存在するとき、前記次のスライスセグメントヘッダの前記スライスセグメントアドレスを示す次のスライスセグメントアドレスを含む、
請求項１に記載のコンピューティングシステム。
【請求項５】
前記次のスライスセグメントアドレスがゼロの場合、前記符号化領域の前記完了は、ピクチャの最後のスライスの符号化データの完了であり、
前記次のスライスセグメントアドレスがゼロ超の場合、前記符号化領域の前記完了は、前記ピクチャの最後でないスライスの符号化データの完了である、
請求項４に記載のコンピューティングシステム。
【請求項６】
プログラムされているときに、プロセッサに、
画像又はビデオの領域についての符号化領域の完了を検出するステップと；
前記符号化領域を含む１つ以上のシンタックス構造と、前記符号化領域を含む前記１つ以上のシンタックス構造の後に、前記符号化領域の完了を示す異なるシンタックス構造とを、エレメンタリビットストリーム内に出力するステップと；
を実行させるコンピュータ実行可能命令を格納する、コンピュータ読取可能媒体。
【請求項７】
前記プロセッサに、
前記領域を符号化して前記符号化領域を生成するステップを実行させるコンピュータ実行可能命令を更に備え、
前記の符号化は、前記符号化領域の前記完了を前記検出することと、該検出に基づいて、前記異なるシンタックス構造を前記エレメンタリビットストリームに追加することとを含む、。
請求項６に記載のコンピュータ読取可能媒体。
【請求項８】
前記領域は、ピクチャ、タイル又はスライスである、
請求項６に記載のコンピュータ読取可能媒体。
【請求項９】
前記異なるシンタックス構造は：
ネットワーク抽象化レイヤ（「ＮＡＬ」）ユニットタイプを有するＮＡＬユニットであって、前記ＮＡＬユニットタイプが当該ＮＡＬユニットを領域の終わりのインジケータとして指定する、ＮＡＬユニット；又は
ペイロードタイプを有する補足エンハンスメント情報（「ＳＥＩ」）メッセージであって、前記ペイロードタイプが当該ＳＥＩメッセージを領域の終わりのインジケータとして指定し、サフィックスＳＥＩメッセージである、ＳＥＩメッセージ；
である、請求項６に記載のコンピュータ読取可能媒体。
【請求項１０】
前記異なるシンタックス構造は、次のスライスセグメントヘッダのスライスセグメントアドレスが前記エレメンタリビットストリーム内に存在するとき、前記次のスライスセグメントヘッダの前記スライスセグメントアドレスを示す次のスライスセグメントアドレスを含む、
請求項６に記載のコンピュータ読取可能媒体。
【請求項１１】
前記次のスライスセグメントアドレスがゼロの場合、前記符号化領域の前記完了は、ピクチャの最後のスライスの符号化データの完了であり、
前記次のスライスセグメントアドレスがゼロ超の場合、前記符号化領域の前記完了は、前記ピクチャの最後でないスライスの符号化データの完了である、
請求項１０に記載のコンピュータ読取可能媒体。
【請求項１２】
前記エレメンタリビットストリーム内の単一のアクセスユニットが、前記符号化領域を含む前記１つ以上のシンタックス構造と、前記符号化領域の前記完了を示す前記異なるシンタックス構造とを含む、
請求項６に記載のコンピュータ読取可能媒体。
【請求項１３】
コンピューティングシステムにおける方法であって：
画像又はビデオの領域についての符号化領域を含む１つ以上のシンタックス構造と、前記符号化領域を含む前記１つ以上のシンタックス構造の後の異なるシンタックス構造とを、エレメンタリビットストリーム内において所定の順序で受け取るステップであって、前記異なるシンタックス構造は、次のスライスセグメントヘッダのスライスセグメントアドレスが前記エレメンタリビットストリーム内に存在するとき、前記次のスライスセグメントヘッダの前記スライスセグメントアドレスを示す次のスライスセグメントアドレスを含む、ステップと；
前記異なるシンタックス構造を使用して、前記符号化領域の完了を検出するステップと；
を具備する方法。
【請求項１４】
前記異なるシンタックス構造は、ペイロードタイプを有するサフィックス補足エンハンスメント情報（「ＳＥＩ」）メッセージであり、前記ペイロードタイプは、当該サフィックスＳＥＩメッセージを領域の終わりのインジケータとして指定する、
請求項１３に記載の方法。
【請求項１５】
前記次のスライスセグメントアドレスがゼロの場合、前記符号化領域の前記完了は、ピクチャの最後のスライスの符号化データの完了であり、
前記次のスライスセグメントアドレスがゼロ超の場合、前記符号化領域の前記完了は、前記ピクチャの最後でないスライスの符号化データの完了である、
請求項１３に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
エンジニアは、圧縮（ソースコーディング又はソース符号化とも呼ばれる）を使用してデジタルビデオのビットレートを減らす。圧縮は、ビデオ情報をより低ビットレートの形に変換することにより、ビデオ情報を格納及び伝送するコストを低減する。圧縮解除（復号とも呼ばれる）は、圧縮された形式から元の情報のバージョンを再構築する。「コーデック」は、エンコーダ／デコーダシステムである。
【０００２】
過去２５年にわたって、ITU-T  H.261、H.262（MPEG-2又はISO/IEC  13818-2）、H.263及びH.264（MPEG-4  AVC又はISO/IEC  14496-10）規格、MPEG-1（ISO/IEC  11172-2）及びMPEG-4  Visual（ISO/IEC  14496-2）規格及びSMPTE  421M（VC-1）規格のような様々なビデオコーデック規格が採用されている。より最近では、H.265/HEVC規格（ITU-T  H.265又はISO/IEC  23008-2）が承認されている。ビデオコーデック規格は、典型的に、符号化されたビデオストリームのシンタックスについてオプションを定義し、特定の特徴が符号化及び復号に使用されるときのビットストリーム内のパラメータを列挙している。例えば最近のビデオコーデック規格（例えばH.264/AVC、H.265/HEVC）は、様々なシンタックス構造を定義している。この場合、シンタックス構造は、ビットストリーム内における指定の順序の１組のゼロ又はそれ以上のシンタックス要素（データの要素）である。多くの場合において、コーデック規格は、復号の際に適合する結果を達成するためにデコーダが実行すべき復号操作に関する詳細も提供している。コーデック規格とは別に、様々な専用のコーデックフォーマットが、符号化ビデオビットストリームのシンタックス及び対応する復号操作についての他のオプションを定義する。
【０００３】
最近のビデオコーデック規格（例えばH.264/AVC、H.265/HEVC）では、ピクチャが１つ以上のスライスとして編成され、この場合、１つのスライスはブロックのセット（例えばH.264/AVC規格ではマクロブロック；H.265/HEVC規格では符号化ツリーユニット（coding  tree  units））である。スライスの符号化データは、ネットワーク抽象化レイヤ（「ＮＡＬ」：network  abstraction  layer）ユニット内に含まれる特定のシンタックス構造内に編成される。ＮＡＬユニットは、（１）従うべきデータのタイプの指示と、（２）そのデータの一連のゼロ又はそれ以上のバイト（例えばスライスについての符号化データ）を含む、シンタックス構造である。ＮＡＬユニットのサイズ（バイト単位）は、ＮＡＬユニットの外側で示されることがあり、バイトストリームフォーマット内のＮＡＬユニット間の境界を識別することにより測定されることがある（例えば一部の場合には、デコーダが、ＮＡＬユニットを開始する開始コードを検索するときに、ＮＡＬユニットのサイズを測定することができ、他の場合には、ＮＡＬユニットのサイズは、マルチメディアシステム多重化プロトコル、パケットネットワークプロトコル又はファイルフォーマットに従ってデータフィールド内に担持されるデータのような「帯域外」情報によって示される可能性がある）。アクセスユニットは、ピクチャのスライスについての符号化データ（及び場合によってはメタデータ等の他の関連するデータ）を含む１つ以上のＮＡＬユニットのセットである。
【０００４】
H.264/AVC規格又はH.265/HEVC規格による復号のために、デコーダは、所与のピクチャについての符号化スライスを受け取った後に、所与のピクチャについての復号処理を開始するように設計されることがあり、この場合、デコーダは、符号化スライスの復号を開始することができる。しかしながら、多くの実装では、デコーダは、該デコーダが所与のピクチャについての符号化データの全てを受け取った後に、所与のピクチャについての復号処理を開始するように設計される。所与のピクチャについての符号化データの全てを受け取ったことを判断するために、デコーダは、（次のアクセスユニット内の）次のピクチャについての符号化データを受け取るまで待機する可能性がある。このデータは、次のピクチャのついての符号化データの開始を示す１つ以上のシンタックス要素を含む。あるいは、所与のピクチャについての符号化データの全てを受け取ったことを判断するために、デコーダは、所与のピクチャの符号化データを十分に解析する可能性がある。いずれのアプローチも復号処理にディレイ又は追加の複雑性を導入する可能性があり、これは、特に超低レイテンシにすることが重要なリアルタイムビデオ通信シナリオ（例えばビデオ会議、、コンピューティングデバイスから近くのディスプレイへの無線「スクリーンキャスティング」、リモートビデオゲーム等）では望ましくない。
【０００５】
別のアプローチでは、メディア再生ツール又は特定のシステム環境内において、メディア再生ツール（又は特定のシステム環境）内のあるコンポーネントが、所与のピクチャの符号化データの終了を伝えるのに使用されるカスタムシンタックス構造を作成し、次いでそのシンタックス構造をメディア再生ツール（又は特定のシステム環境）内のデコーダに提供する可能性がある。このカスタムシンタックス構造は、例えばシステム多重化データ等のシステムレベルの情報内の符号化ビデオデータを含むエレメンタリビットストリーム（elementary  bitstream）の外側で提供される。したがって、このアプローチは、ビデオコーデック規格又はフォーマットのエレメンタリビットストリーム内のカスタムシンタックス構造を持たない。これは一般的適用性に欠き、特定のメディア再生ツール（又は特定のシステム環境）の外側のエンコーダ又は他のコンポーネントの関連を排除する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
要約すると、詳細な説明は、符号化領域（coded  region）の完了（completion）を示すシンタックス構造における革新を提示する。例えばコーデックフォーマットに整合するエレメンタリビットストリーム内のシンタックス構造が、符号化領域の完了をを示す。本革新は、より迅速に復号処理を開始することを可能にすることにより、復号中の全体的なレイテンシを低減することができる。一部の場合には、本革新は、復号前にバッファする必要があるデータの量を減らすことにより、あるいは、受信データ（incoming  data）が到着するときにこの受信データを十分に解析する必要性をなくすことにより、復号処理の複雑性を低減することもできる。また、本革新は、誤り検出を容易にし、符号化データのパケットの損失に対するロバスト性を改善することもできる。
【０００７】
本明細書で説明される革新の一態様によると、エンコーダ、マルチプレクサ又はビットストリームエディタ等のメディア処理ツールは、画像又はビデオの領域についての符号化領域の完了を検出する。メディア処理ツールは、エレメンタリビットストリーム内において、（１）上記の符号化領域を含む１つ以上のシンタックス構造と、（２）上記の符号化領域を含むシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを出力する。
【０００８】
本明細書で説明される革新の別の態様によると、デコーダ、デマルチプレクサ又はビットストリームエディタ等のメディア処理ツールは、エレメンタリビットストリーム内において、（１）画像又はビデオの領域についての符号化領域を含む１つ以上のシンタックス構造と、（２）上記の符号化領域を含むシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを受け取る。メディア処理ツールは、上記の異なるシンタックス構造を使用して、符号化領域の完了を検出する。
【０００９】
一部の例示の実装において、エレメンタリビットストリームは、コーデックフォーマットに適合する。また、符号化領域を含むシンタックス構造と、符号化領域の完了を示す異なるシンタックス構造は典型的に、所定の順序（例えばアクセスユニットについてのネットワーク抽象化レイヤユニットの特定の順序）であり、これは、異なるシンタックス構造を使用する符号化領域の完了の検出を容易にする。
【００１０】
本革新は、方法の一部として、方法を実行するよう構成されるコンピューティングシステムの一部として、あるいはプログラムされるときにプロセッサに方法を実行させるコンピュータ実行可能命令を格納する有形のコンピュータ読取可能媒体の一部として実装されることが可能である。様々な革新を組み合わせて又は別個に用いることができる。この要約は、以下で詳細な説明において更に説明される概念の選択を簡単な形で紹介するために提供される。この要約は、特許請求に係る主題の主要な特徴又は本質的特徴を特定するようには意図されておらず、また特許請求に係る主題の範囲を限定するのに用いられるようにも意図されていない。本発明の前述及び他の目的、特徴又は利点は、添付の図面との関連で進行する以下の詳細な説明からより明らかになるであろう。
【図面の簡単な説明】
【００１１】
【図１】一部の説明される実施形態を実装することができる例示のコンピューティングシステムの図である。
【００１２】
【図２ａ】一部の説明される実施形態を実装することができる例示のネットワーク環境の図である。
【図２ｂ】一部の説明される実施形態を実装することができる例示のネットワーク環境の図である。
【００１３】
【図３】例示のエンコーダシステムの図であり、このエンコーダシステムとともに、一部の説明される実施形態を実装することができる。
【００１４】
【図４】例示のデコーダシステムの図であり、このデコーダシステムとともに、一部の説明される実施形態を実装することができる。
【００１５】
【図５ａ】符号化領域の完了を示すシンタックス構造の用途の図である。
【図５ｂ】符号化領域の完了を示すシンタックス構造の用途の図である。
【００１６】
【図６】符号化領域の完了を示す例示のネットワーク抽象化レイヤの一部を示す図である。
【００１７】
【図７】符号化領域の完了を示す例示の補足エンハンスメント情報メッセージの例を示す図である。
【００１８】
【図８】符号化領域の完了を示すシンタックス構造を挿入するための一般化した技法を示すフローチャートである。
【図９】符号化領域の完了を示すシンタックス構造を使用するための一般化した技法を示すフローチャートである。
【発明を実施するための形態】
【００１９】
詳細な説明は、符号化領域の完了を示すシンタックス構造における革新を提示する。例えばエレメンタリビットストリーム内のシンタックス構造が、符号化領域の完了をを示す。この場合、領域は、スライス、タイル、ピクチャ又はピクチャ内の他の領域とすることができる。符号化領域の完了を示すシンタックス構造は、特別なタイプのネットワーク抽象化レイヤ（「ＮＡＬ」：network  abstraction  layer）ユニット、特別なタイプの補足エンハンスメント情報（「ＳＥＩ」）メッセージ又は別のシンタックス構造とすることができる。本革新は、デコーダが、より迅速に符号化ピクチャ境界を検出して、所与のピクチャの復号処理を開始することを可能にすることにより、復号中のレイテンシを低減することができる。一部の場合には、本革新は、復号する前にバッファする必要があるデータの量を減らすことにより、あるいは、受信データが到着するときにこの受信データを十分に解析する必要性をなくすことにより、復号処理を簡潔にすることもできる。さらに、本革新は、誤り検出を容易にし、（例えばスライス又はタイルの）符号化データのパケットの損失に対するロバスト性を改善することができる。
【００２０】
本明細書の適所で説明される動作は、ビデオエンコーダ又はビデオデコーダによって実行されるように説明される。多くの場合において、これらの動作を、別のタイプのメディア処理ツール（例えば画像エンコーダ又は画像デコーダ、マルチプレクサ、デマルチプレクサ、ビットストリームエディタ）によって実行することができる。エンコーダ、デコーダ、マルチプレクサ及びデマルチプレクサの例は以下で提供される。ビットストリームエディタは、エレメンタリビットストリームのシンタックス構造を編集する（例えばシンタックス構造を挿入、修正又は除去する）任意のツールとすることができる。
【００２１】
本明細書で説明される革新の一部は、H.264/AVC規格又はH.265/HEVC規格に固有の用語に関連して説明される。例えば２０１３年４月版のH.265/HEVC規格（ITU-T  H.265、「High  Efficiency  Video  Coding」）及び２０１０年３月版のH.264/AVC規格（ITU-T  H.264、「Advanced  Video  Coding  for  Generic  Audiovisual  Services」）を参照する。本明細書で説明される革新を、他の規格又はフォーマットに関して実装することもできる。
【００２２】
より一般的に、本明細書で説明される例に対する様々な代替が可能である。例えば本明細書で説明される方法の一部を、説明される方法の動作の順番を変更することにより、特定の方法の動作を分割、反復又は省略すること等により代替することができる。開示されるテクノロジの様々な側面を組み合わせて又は別個に使用することができる。異なる実施形態は、説明される革新の１つ又はそれ以上を使用する。本明細書で説明される革新の一部は、背景技術として示される問題の１つ又はそれ以上に対処する。典型的に所与の技術／ツールはそのような問題の全ては解決しない。
【００２３】
Ｉ．例示のコンピューティングシステム
図１は、説明される革新の幾つかを実装することができる適切なコンピューティングシステム（１００）の一般化した例を図示している。本革新は多様な汎用又は専用のコンピューティングシステムにおいて実装されてよいので、コンピューティングシステム（１００）は、使用又は機能の範囲に関していかなる限定も示唆するようには意図されていない。
【００２４】
図１を参照すると、コンピューティングシステム（１００）は、１つ以上の処理ユニット（１１０、１１５）及びメモリ（１２０、１２５）を含む。処理ユニット（１１０、１１５）は、コンピュータ実行可能命令を実行する。処理ユニットは、汎用の中央処理ユニット（「ＣＰＵ」）、特定用途向け集積回路（「ＡＳＩＣ」）によるプロセッサ又は任意の他のタイプのプロセッサとすることができる。マルチ処理システムでは、複数の処理ユニットがコンピュータ実行可能命令を実行して処理パワーを増加させる。例えば図１は、中央処理ユニット（１１０）だけでなく、グラフィクス処理ユニット又はコプロセッシングユニット（１１５）を示している。有形のメモリ（１２０、１２５）は、処理ユニットによってアクセス可能な、揮発性メモリ（例えばレジスタ、キャッシュ、ＲＡＭ）、不揮発性メモリ（例えばＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等）又はこれら２つの何らかの組合せとすることができる。メモリ（１２０、１２５）は、処理ユニットによる実行に適したコンピュータ実行可能命令の形で、符号化領域の完了を示すシンタックス構造のための１つ以上の革新を実装するソフトウェア（１８０）を格納する。
【００２５】
コンピューティングシステムは、追加の機能を有してもよい。例えばコンピューティングシステム（１００）は、ストレージ（１４０）、１つ以上の入力デバイス（１５０）、１つ以上の出力デバイス（１６０）及び１つ以上の通信接続（１７０）を含む。バス、コントローラ又はネットワークのような相互接続機構（図示せず）は、コンピューティングシステム（１００）のコンポーネントを相互接続する。典型的に、オペレーティングシステムソフトウェア（図示せず）は、コンピューティングシステム（１００）内で実行する他のソフトウェアのための動作環境を提供し、コンピューティングシステム（１００）のコンポーネントのアクティビティを調整する。
【００２６】
有形のストレージ（１４０）は、取外し可能であっても取外し不可能であってよく、磁気ディスク、磁気テープ又はカセット、ＣＤ−ＲＯＭ、ＤＶＤ、あるいは情報を格納するのに使用することができ、かつコンピューティングシステム（１００）内でアクセスすることができる任意の他の媒体のようなデバイスを含む。ストレージ（１４０）は、符号化領域の完了を示すシンタックス構造のための１つ以上の革新を実装するソフトウェア（１８０）のための命令を格納する。
【００２７】
入力デバイス（１５０）は、キーボード、マウス、ペン又はトラックボールのようなタッチ入力デバイス、音声入力デバイス、スキャニングデバイス又はコンピューティングシステム（１００）への入力を提供する別のデバイスのようなタッチ入力デバイスであって。ビデオに関して、入力デバイス（１５０）は、カメラ、ビオカード、ＴＶチューナカード、スクリーンキャプチャモジュール又はアナログ若しくはデジタル形式でビデオ入力を受け取る同様のデバイス、あるいはコンピューティングシステム（１００）へのビデオ入力を読み取るＣＤ−ＲＯＭ又はＣＤ−ＲＷであってよい。出力デバイス（１６０）は、ディスプレイ、プリンタ、スピーカ、ＣＤライタ又はコンピューティングシステム（１００）からの出力を提供する別のデバイスとすることができる。
【００２８】
通信接続（１７０）は、通信媒体を介して別のコンピューティングエンティティへの通信を可能にする。通信媒体は、コンピュータ実行可能命令、オーディオ又はビデオ入力又は出力、変調データ信号内の他のデータのような情報を伝達する。変調データ信号は、信号特性のうち、信号内に情報をエンコードするような方法で設定又は変更された１つ以上の特性を有する信号である。限定ではなく例として、通信媒体は、電子、光、ＲＦ又は他の搬送波を使用することができる。
【００２９】
本革新を、コンピュータ読取可能媒体の一般的な文脈で説明することができる。コンピュータ読取可能媒体は、コンピューティング環境内でアクセスすることができる、任意の利用可能な有形の媒体である。限定ではなく例として、コンピューティングシステム（１００）では、コンピュータ読取可能媒体は、メモリ（１２０、１２５）、ストレージ（１４０）及び上記のいずれかの組合せを含む。「コンピュータ読取可能媒体」という用語は、搬送波、信号自体又は一時的な伝播信号を網羅せず、包含せず、あるいは含まない。
【００３０】
本革新を、コンピュータ実行可能命令の一般的な文脈で説明することができる。コンピュータ実行可能命令は、例えばコンピューティングシステム内で対象となる実際のプロセッサ又は仮想プロセッサ上で実行される、プログラムモジュールに含まれる命令等である。一般に、プログラムモジュールは、特定のタスクを実行するか、特定の抽象データタイプを実装する、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造等を含む。プログラムモジュールの機能は、様々な実施形態において所望のとおりに組み合わされてもよく、プログラムモジュール間で分けられてもよい。プログラムモジュールのためのコンピュータ実行可能命令は、ローカルのコンピューティングシステム内で実行されてもよく、分散コンピューティングシステム内で実行されてもよい。
【００３１】
「システム」及び「デバイス」という用語は、本明細書で交換可能に使用される。文脈上そうでないことが明確に示されない限り、いずれも用語も、コンピューティングシステム又はコンピューティングデバイスのタイプに関する如何なる限定も示唆しない。一般に、コンピューティングシステム又はコンピューティングデバイスは、ローカルとすることも分散型とすることもでき、本明細書で説明される機能を実装するソフトウェアとともに、専用のハードウェア及び／又は汎用のハードウェアのいずれかの組合せを含むことができる。
【００３２】
開示される方法は、これらの開示される方法のいずれかを実行するように構成される特別なコンピューティングハードウェアを使用して実装することも可能である。例えば開示される方法は、これらの開示される方法のいずれかを実装するように特別に設計又は構成される集積回路（例えばＡＳＩＣデジタル信号プロセッサ（「ＤＳＰ」）のようなＡＳＩＣ、グラフィクス処理ユニット（「ＧＰＵ」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）のようなプログラム可能な論理デバイス（「ＰＬＤ」））によって実装することができる。
【００３３】
提示の目的のために、詳細な説明は、「判断／決定する」及び「使用する」等の用語を使用してコンピューティングシステムにおける演算動作を説明している。これらの用語は、コンピュータによって実行される動作の高レベルな抽象表現であり、人間によって行われる行為と混同されるべきではない。これらの用語に対応する実際の演算動作は、実装に応じて異なる。
【００３４】
ＩＩ．例示のネットワーク環境
図２ａ及び図２ｂは、ビデオエンコーダ（２２０）及びビデオデコーダ（２７０）を含む例示のネットワーク環境（２０１、２０２）を図示している。エンコーダ（２２０）及びデコーダ（２７０）は、適切な通信プロトコルを介してネットワーク（２５０）上で接続される。ネットワーク（２５０）は、インターネット又は別のコンピュータネットワークを含むことができる。
【００３５】
図２ａに図示されるネットワーク環境（２０１）では、各リアルタイム通信（「ＲＴＣ」）ツール（２１０）が、双方向通信のためにエンコーダ（２２０）とデコーダ（２７０）の双方を含む。所与のエンコーダ（２２０）は、H.265/HEVC規格、SMPTE  421M規格、（H.264又はAVCとしても知られる）ISO/IEC14496-10規格、別の規格又は専用のフォーマットの変形又は拡張と互換性がある出力を生成することができ、対応するデコーダ（２７０）が、エンコーダ（２２０）からの符号化データを受け入れる。双方向通信は、ビデオ会議、ビデオ電話あるいは他の二者又はマルチパーティ通信シナリオの一部とすることができる。図２ａのネットワーク環境（２０１）は２つのリアルタイム通信ツール（２１０）を含んでいるが、ネットワーク環境（２０１）は、代わりに、マルチパーティ通信に参加する３つ又はそれ以上のリアルタイム通信ツール（２１０）を含むことができる。
【００３６】
リアルタイム通信ツール（２１０）は、エンコーダ（２２０）による符号化を管理する。図３は、リアルタイム通信ツール（２１０）に含まれ得る例示のエンコーダシステム（３００）を示す。代替的に、リアルタイム通信ツール（２１０）は別のエンコーダシステムを使用する。リアルタイム通信ツール（２０）は、デコーダ（２７０）による復号も管理する。図４は、リアルタイム通信ツール（２１０）に含まれ得る例示のデコーダシステム（４００）を示している。代替的に、リアルタイム通信ツール（２１０）は別のデコーダシステムを使用する。
【００３７】
図２ｂに図示されるネットワーク環境（２０２）では、符号化ツール（２１２）は、複数の再生ツール（２１４）への伝達のためにビデオを符号化するエンコーダ（２２０）を含む。再生ツール（２１４）はデコーダ（２７０）を含む。ビデオ監視システム、ウェブカメラモニタリングシステム、リモートデスクトップ会議プレゼンテーション、あるいはビデオが符号化されて、ある場所から１つ以上の他の場所へ送信される他のシナリオのために一方向通信を提供することができる。図２ｂ内のネットワーク環境（２０２）は２つの再生ツール（２１４）を含んでいるが、ネットワーク環境（２０２）は、より多くの又は少ない再生ツール（２１４）を含むことができる。一般に、再生ツール（２１４）は、符号化ツール（２１２）と通信して、再生ツール（２１４）が受け取るべきビデオストリームを決定する。再生ツール（２１４）は、そのストリームを受け取って、受け取った符号化データを適切な期間の間バッファし、そして復号及び再生を開始する。
【００３８】
図３は、符号化ツール（２１２）に含まれ得る例示のエンコーダシステム（３００）を示している。代替的に、符号化ツール（２１２）は別のエンコーダシステムを使用する。符号化ツール（２１２）は、１つ以上の再生ツール（２１４）との接続を管理するためにサーバ側のコントローラロジックを含むこともできる。図４は、再生ツール（２１４）に含まれ得る例示のデコーダシステム（４００）を示している。代替的に、再生ツール（２１４）は別のデコーダシステムを使用する。再生ツール（２１４）は、符号化ツール（２１２）との接続を管理するためにクライアント側のコントローラロジックを含むこともできる。
【００３９】
ＩＩＩ．例示のエンコーダシステム
図３は、例示のエンコーダシステム（３００）のブロック図であり、この例示のエンコーダシステム（３００）とともに、幾つかの説明される実施形態が実装されてよい。エンコーダシステム（３００）は、リアルタイム通信のための超低レイテンシ（ultra-low-latency）又は低レイテンシ（low-latency）符号化モード、トランスコーディングモード、並びにファイル又はストリームからの再生のためのメディアを生成する高レイテンシ符号化モードといった複数の符号化モードのうちのいずれかで動作することができる汎用の符号化ツールとすることができ、あるいはそのような符号化モードの１つに適合される専用の符号化ツールとすることができる。エンコーダシステム（３００）は、特定のタイプのコンテンツ（例えば画面キャプチャコンテンツ）の符号化のために適合されることができる。エンコーダシステム（３００）を、オペレーティングシステムモジュールの一部として、アプリケーションライブラリの一部として、スタンドアロンアプリケーションの一部として、あるいは専用のハードウェアを使用して実装することができる。全体として、エンコーダシステム（３００）は、ビデオソース（３１０）からソースビデオピクチャ（３１１）のシーケンスを受け取り、チャネル（３９０）への出力として符号化データを生成する。チャネルへ出力される符号化データは、符号化領域の完了を示すシンタックス構造を含むことができる。
【００４０】
ビデオソース（３１０）は、カメラ、チューナカード、記憶媒体、スクリーンキャプチャモジュール又は他のデジタルビデオソースとすることができる。ビデオソース（３１０）は、ビデオピクチャのシーケンスを、例えば毎秒３０フレームのフレームレートで生成する。本明細書で使用されるとき、「ピクチャ」という用語は、一般に、ソース、符号化又は再構築された画像データを指す。プログレッシブスキャンビデオでは、ピクチャはプログレッシブスキャンビデオフレームである。インタレースビデオでは、例示の実施形態において、インタレースビデオフレームが、符号化の前にデインタレースされる可能性がある。あるいは、２つの相補的インタレースビデオフィールドを、単一のビデオフレームとして一緒に符号化するか、２つの別個に符号化されたフィールドとして符号化する。プログレッシブスキャンビデオフレームを示すか、デインタレース・スキャンビデオフレームを示すかは別として、「ピクチャ」という用語は、単一の非ペアの映像フィールド、相補的ペアのビデオフィールド、所与の時間の映像オブジェクトを表す映像オブジェクト面（video  object  plane）又はより大きな画像内の関心領域を示すことができる。映像オブジェクト面又は領域は、シーンの複数の領域又は複数のオブジェクトを含むより大きな画像の一部とすることができる。
【００４１】
到来するソースピクチャ（３１１）は、複数のピクチャバッファストレージエリア（３１１、３２２・・・３２ｎ）を含む、ソースピクチャ一時メモリストレージエリア（３２０）に格納される。ピクチャバッファ（３２１、３２２等）は、ソースピクチャストレージエリア（３２０）内に１つのソースピクチャを保持する。ソースピクチャ（３１１）のうちの１つ以上がピクチャバッファ（３２１、３２２等）に格納された後、ピクチャセレクタ（３３０）は、ソースピクチャストレージエリア（３２０）から個々のソースピクチャを選択する。ピクチャがピクチャセレクタ（３３０）によってエンコーダ（３４０）への入力用に選択される順序は、ピクチャがビデオソース（３１０）によって生成される順序と異なる。例えば幾つかの後のピクチャが最初に符号化されて、後方予測を時間的に促進するように、幾つかのピクチャの符号化がその順序において遅延されてもよい。エンコーダ（３４０）の前に、エンコーダシステム（３００）はプリプロセッサ（図示せず）を含むことができる。プリプロセッサは、符号化の前に、選択されたピクチャ（３３１）の事前処理（例えばフィルタリング）を実行する。事前処理は、一次（例えば輝度）成分及び二次（例えば赤及び青に対する彩度差（chroma  differences））成分への色空間変換及び符号化のための再サンプリング処理（例えば彩度成分の空間分解能を低減する）を含むことができる。符号化の前に、ビデオをＹＵＶのような色空間に変換してもよい。ＹＵＶでは、輝度（Ｙ）成分のサンプル値が明るさ（brightness）又は明度（intensity）の値を表し、彩度（Ｕ、Ｖ）成分のサンプル値が色差値を表す。色差値の厳密な定義（及びＲＧＢ等の別の色空間に対するＹＵＶ色空間へ／からの変換操作）は実装に依存する。
【００４２】
エンコーダ（３４０）は、選択されたピクチャ（３３１）を符号化して符号化ピクチャ（３４１）を生成し、また、メモリ管理制御動作（「ＭＭＣＯ」：memory  management  control  operation）信号（３４２）又は参照ピクチャセット（「ＲＰＳ」：reference  picture  set）情報も生成する。ＲＰＳは、現在のピクチャ又はいずれかの後続ピクチャのための動き補償における参照のために使用され得るピクチャのセットである。現在のピクチャが、符号化されている最初のピクチャでない場合、その符号化処理を実行するときに、エンコーダ（３４０）は、復号済みピクチャ一時メモリストレージエリア（３６０）内に格納されている１つ以上の以前に符号化／復号されたピクチャ（３６９）を使用してもよい。そのように格納される復号済みピクチャ（３６９）は、現在のソースピクチャ（３３１）のコンテンツ（content）のインターピクチャ予測のための参照ピクチャとして使用される。MMCO／RPS情報（３４２）は、いずれの再構築済みピクチャを参照ピクチャとして使用することができ、したがって、ピクチャストレージエリアに格納すべきであることかをデコーダに示す。
【００４３】
一般に、デコーダ（３４０）は、タイルへ分割すること、イントラピクチャ予測及び推定、動き推定及び補償、周波数変換、量子化及びエントロピー符号化等のような符号化タスクを実行する複数の符号化モジュールを含む。エンコーダ（３４０）によって実行される正確な動作は、圧縮フォーマットに依存して異なる可能性がある。出力符号化データのフォーマットは、Windows（登録商標）メディアビデオフォーマット、VC-1フォーマット、MPEG-xフォーマット（例えばMPEG-1、MPED-2又はMPEG-4）、H.26xフォーマット（例えばH.261、H.262、H.263、H.264、H.265）又は別のフォーマットの変形又は拡張とすることができる。
【００４４】
エンコーダ（３４０）は、ピクチャを、同じサイズ又は異なるサイズの複数のタイルに分割することができる。例えばエンコーダ（３４０）はピクチャをタイルの行及びタイルの列に沿って分ける。タイルの行及びタイルの列は、ピクチャ境界によりピクチャ内のタイルの水平及び垂直境界を規定し、各タイルは矩形領域である。タイルは、多くの場合、並列処理のためのオプションを提供するために使用される。ピクチャは、１つ以上のスライスとして編成されることも可能であり、この場合、１つのスライスを全体のピクチャとすることも、ピクチャの一部とすることもできる。スライスを、ピクチャ内の他のスライスと独立に復号することができ、これは、誤り耐性を改善する。スライス又はタイルのコンテンツは更に、符号化及び復号の目的のために、サンプル値のブロック又は他のセットに分割される。
【００４５】
H.264/AVC規格によるシンタックスでは、エンコーダ（３４０）は、フレームを同じサイズ又は異なるサイズの複数のスライスに分割することができる。エンコーダ（３４０）は、フレーム（又はスライス）のコンテンツを16x16のマクロブロックに分ける。マクロブロックは、４つの8x8輝度ブロックとして編成される輝度サンプル値と、8x8彩度ブロックとして編成される対応する彩度サンプル値を含む。一般に、マクロブロックは、インター又はイントラ等の予測モードを有する。マクロブロックは、（予測モードの詳細、動きベクトル（「ＭＶ」：motion  vector）情報等のような）予測情報のシグナリング及び／又は予測処理の目的のために、１つ以上の予測ユニット（prediction  units）（例えばインターフレーム予測のための区分と呼ばれ得る、8x8ブロック、4x4ブロック）を含む。マクロブロックは、残差符号化／復号の目的のために１つ以上の残差データユニットも有する。
【００４６】
H.265/HEVC規格によるシンタックスでは、エンコーダは、ピクチャ（又はスライス若しくはタイル）のコンテンツを符号化ツリーユニットに分ける。符号化ツリーユニット（「ＣＴＵ」）は、輝度符号化ツリーブロック（「ＣＴＢ」：coding  tree  block）として編成された輝度サンプル値と、２つの彩度ＣＴＢとして編成される、対応する彩度サンプル値を含む。ＣＴＵ（及びそのＣＴＢ）のサイズはエンコーダによって選択される。輝度ＣＴＢは、例えば64x64、32x32又は16x16輝度サンプル値を含むことができる。ＣＴＵは１つ以上の符号化ユニットを含む。符号化ユニット（「ＣＵ」：coding  unit）は、輝度符号化ブロック（「ＣＢ」：coding  block）と、２つの対応する彩度ＣＢを有する。一般に、ＣＵは、インター又はイントラ等の予測モードを有する。ＣＵは、（予測モードの詳細、変位値等のような）予測情報のシグナリング及び／又は予測処理のために１つ以上の予測ユニットを含む。予測ユニット（「ＰＵ」：prediction  unit）は、輝度予測ブロック（「ＰＢ」：prediction  block）と２つの彩度ＰＢを有する。ＣＵは、残差符号化／復号のために１つ以上の変換ユニットも有し、変換ユニット（「ＴＵ」：transform  unit）は、輝度変換ブロック（「ＴＢ」：transform  block）と２つの彩度ＴＢを有する。ＣＵは、単一のＴＵを有してもよく、複数のＴＵを有してもよい。エンコーダは、ビデオをどのようにＣＴＵ、ＣＵ、ＰＵ、ＴＵ等に分割するかを決定する。
【００４７】
H.265/HEVCの実装では、スライスは、単一のスライスセグメント（独立スライスセグメント）を含むことができ、あるいは複数のスライスセグメント（独立スライスセグメントと１つ以上の従属スライスセグメント）に分割されることもできる。スライスセグメントは、タイルスキャンで連続的に順序付けされ、かつ単一のネットワーク抽象化レイヤ（「ＮＡＬ」：network  abstraction  layer）ユニット内に含まれる、整数のＣＴＵである。独立スライスセグメントでは、スライスセグメントヘッダが、独立スライスセグメントを求めるシンタックス要素の値を含む。従属スライスセグメントでは、短縮されたスライスセグメントヘッダ（truncated  slice  segment  header）が、その従属スライスセグメントを求めるわずかなシンタックス要素の値を含み、従属スライスセグメントについての他のシンタックス要素の値は、復号順で先行する独立スライスセグメントの値から推論される。
【００４８】
本明細書で使用されるとき、「ブロック」という用語は、文脈に応じてマクロブロック、残差データユニット、ＣＴＢ、ＣＢ、ＰＢ又はＴＢ、あるいは何らかの他のサンプル値のセットを示す可能性がある。「ユニット」という用語は、文脈に応じてマクロブロック、ＣＴＵ、ＣＵ、ＰＵ又はＴＵ、あるいは何らかの他のブロックのセットを示す可能性があり、あるいは単一のブロックを示す可能性もある。
【００４９】
図３に戻ると、エンコーダは、ピクチャ（３３１）内の他の以前に再構築されたサンプル値からの予測に関して、ソースピクチャ（３３１）のイントラ符号化ブロックを表す。イントラブロックコピー（「ＩＢＣ」：intra  block  copy）予測では、イントラピクチャ推定器は、現在のブロックから、他の以前に再構築されたサンプル値内の位置までの変位を推定する。ピクチャ内のサンプル値の参照ブロックを使用して、現在のブロックについての予測値を生成する。参照ブロックは、ブロックベクトル（「ＢＶ」：block  vector）値（ＢＶ推定で決定される）により示されることができる。ＩＢＣ予測は、参照ピクチャが現在のピクチャである、イントラピクチャ予測の特別なケースとして実装され得る。ブロックについてのイントラ空間予測では、イントラピクチャ推定器は、隣接する再構築されたサンプル値について、ブロックへの外挿（extrapolation）を推定する。
【００５０】
イントラピクチャ推定器は、（ＩＢＣ予測についてのＢＶ値、あるいはイントラ空間予測についての予測モード（方向）のような）予測情報を出力することができる。予測情報は、エントロピー符号化される。イントラピクチャ予測の予測器は、予測情報を利用して、イントラ予測値を決定する。
【００５１】
エンコーダ（３４０）は、参照ピクチャからの予測に関して、ソースピクチャ（３３１）のイントラピクチャ符号化予測ブロックを表す。動き推定器が、１つ以上の参照ピクチャ（３６９）に関してブロックの動きを推定する。複数の参照ピクチャが使用されるとき、これらの複数の参照ピクチャは、異なる時間的方向からのものとすることも、同じ時間的方向からのものとすることもできる。動き補償された予測参照領域は、参照ピクチャ内のサンプル値の領域であり、この参照ピクチャ内のサンプル値を使用して、現在のピクチャのサンプル値のブロックについて動き補償された予測値を生成する。動き推定器は、動きベクトル（「ＭＶ」：motion  vector）情報のような動き情報を出力する。動きベクトル情報はエントロピー符号化される。動き補償器は、ＭＶを参照ピクチャ（３６９）に適用して、インターピクチャ予測について動き補償された予測値を決定する。
【００５２】
エンコーダは、ブロックの予測値（イントラ又はインター）と、対応する元の値の間の差分（もしあれば）を符号化して送信するか否かを決定することができる。これらの差分を符号化／送信する場合、これらの差分（予測残差値とも呼ばれる）は、（周波数変換がスキップされない場合）周波数変換、量子化及びエントロピー符号化を使用して更に符号化される。例えばエンコーダ（３４０）は、ピクチャ、タイル、スライス及び／又はビデオの他の部分について量子化パラメータ（「ＱＰ」：quantization  parameter）の値を設定し、これに応じて変換係数を量子化する。エンコーダ（３４０）のエントロピーコーダは、量子化された変換係数値、並びに特定のサイド情報（side  information）（例えばＭＶ情報、ＢＶ情報、ＱＰ値、モード決定、パラメータ選択）を圧縮する。典型的なエントロピー符号化技術は、指数ゴロム符号化、ゴロム・ライス符号化、算術符号化、差分符号化（differential  coding）、ハフマン符号化、ランレングス符号化、Ｖ２Ｖ（variable-length-to-variable-length）符号化、Ｖ２Ｆ（variable-length-to-fixed-length）符号化、ＬＺ（Lempel-Ziv）符号化、ディクショナリ符号化、ＰＩＰＥ（probability  interval  partitioning  entropy）符号化及び上記の組合せを含む。エントロピーコーダは、異なる種類の情報に異なる符号化技術を使用することができ、複数の技術を組み合わせて適用することができ（例えばゴロム・ライス符号化を適用し、続いて算術符号化を行うことにより）、特定の符号化技術の複数のコードテーブルの中から選択することができる。一部の実装では、周波数変換をスキップすることができる。この場合、予測残差値を量子化してエントロピー符号化することができる。
【００５３】
適応的デブロッキングフィルタが、エンコーダ（３４０）の動き補償ループに含まれ（すなわち、「インループ」フィルタリング）、復号されたピクチャ内のブロック境界行及び／又は列にわたる不連続性をスムーズにする。あるいはまた、（デリング（de-ringing）フィルタリング、適応的ループフィルタリング（「ＡＬＦ」：adaptive  loop  filtering）又はサンプル適応的オフセット（「ＳＡＯ」：sample-adaptive  offset）フィルタリング（図示せず）のような）他のフィルタリングをインループフィルタリング動作として適用することができる。
【００５４】
エンコーダ（３４０）は、エレメンタリビットストリーム内の符号化データを生成する。エレメンタリビットストリームのシンタックスは典型的に、コーデック規格又はフォーマット、あるいはその拡張又は変形で定義される。エンコーダ（３４０）の出力として、エレメンタリビットストリームは典型的に、以下で説明されるように、コンテナフォーマットにパケット化又は編成される。
【００５５】
エレメンタリビットストリーム内の符号化データは、シンタックス構造として編成されるシンタックス要素を含む。一般に、シンタックス要素は、データのいずれかの要素とすることができ、シンタックス構造は、エレメンタリビットストリーム内の指定された順序のゼロ又はそれ以上のシンタックス要素である。H.264/AVC規格及びH.265/HEVC規格において、ＮＡＬユニットは、（１）従うべきデータのタイプの指示と、（２）そのデータの一連のゼロ又はそれ以上のバイトとを含む、シンタックス構造である。例えばＮＡＬユニットはスライス（符号化スライス）についえての符号化データを含むことができる。ＮＡＬユニットのサイズ（バイト単位）は、ＮＡＬユニットの外側（outside）で示される。符号化スライスＮＡＬユニット及び特定の他の定義されたタイプのＮＡＬユニットは、ビデオ符号化レイヤ（「ＶＣＬ」：video  coding  layer）ＮＡＬユニットと呼ばれる。アクセスユニットは、ピクチャのスライスについての符号化データを含み、場合によってはメタデータのような他の関連するデータを含む、連続する復号順の１つ以上のＮＡＬユニットのセットである。本明細書で説明される革新によると、エレメンタリビットストリームは、符号化領域（例えば符号化スライス、符号化ピクチャ）の完了を示すシンタックス構造を含むことができる。一部の実装では、符号化領域の完了を示すシンタックス構造は、特別なタイプのＮＡＬユニットである。
【００５６】
H.264/AVC規格又はH.265/HEVC規格によるシンタックスでは、ピクチャパラメータセット（「ＰＰＳ」：picture  parameter  set）は、ピクチャに関連付けることができるシンタックス要素を含むシンタックス構造である。ＰＰＳを単一のピクチャに使用することができ、あるいはＰＰＳを一連の複数のピクチャに再使用することができる。ＰＰＳは典型的に、ピクチャについての符号化データから別個にシグナリングされる（例えばＰＰＳのための１つのＮＡＬユニットと、ピクチャの符号化データのための１つ以上の他のＮＡＬユニット）。ピクチャの符号化データ内では、どのシンタックス要素をピクチャのために使用すべきかを示す。同様に、H.264/AVC規格又はH.265/HEVC規格によるシンタックスでは、シーケンスパラメータセット（「ＳＰＳ」：sequence  parameter  set）は、ピクチャのシーケンスに関連付けることができるシンタックス要素を含むシンタックス構造である。ビットストリームは単一のＳＰＳを含むことも、複数のＳＰＳを含むこともできる。ＳＰＳは典型的に、シーケンスについての他のデータから別個にシグナリングされ、他のデータ内のシンタックス要素は、どのＳＰＳを使用すべきかを示す。
【００５７】
図３を参照すると、符号化ピクチャ（３４１）及びMMCO/RPS情報（３４２）（あるいは、ピクチャについての従属性及び順序付け構造はエンコーダ（３４０）において既知であるので、MMCO/RPS情報（３４２）と等しい情報）が、復号処理エミュレータ（３５０）によって処理される。復号処理エミュレータ（３５０）は、デコーダの機能の一部、例えば参照ピクチャを再構築する復号タスクを実装する。MMCO/RPS情報（３４２）に合致する手法では、復号処理エミュレータ（３５０）は、符号化すべき後続のピクチャのインターピクチャ予測において参照ピクチャとして使用するために、所与の符号化ピクチャ（３４１）を再構築して格納する必要があるかどうかを判断する。符号化ピクチャ（３４１）を格納する必要がある場合、復号処理エミュレータ（３５０）は、符号化ピクチャ（３４１）を受け取って対応する復号ピクチャ（３５１）を生成するデコーダによって構築されたであろう復号処理をモデル化する。そのようにする際、エンコーダ（３４０）が、復号済みピクチャストレージエリア（３６０）内に格納されている復号済みピクチャ（３６９）を使用すると、復号処理エミュレータ（３５０）も、復号処理の一部として、ストレージエリア（３６０）からの復号済みピクチャ（３６９）を使用する。
【００５８】
復号済みピクチャ一時メモリストレージエリア（３６０）は、複数のピクチャバッファストレージエリア（３６１、３６２・・３６ｎ）を含む。MMCO/RPS情報（３４２）に合致する手法では、復号処理エミュレータ（３５０）は、参照ピクチャとしての使用のためにエンコーダ（３４０）がもはや必要としないピクチャを有する、いずれかのピクチャバッファ（３６１、３６２等）を識別するために、ストレージエリア（３６０）内のコンテンツを管理する。復号処理をモデル化した後、復号処理エミュレータ（３５０）は、新たに復号されたピクチャ（３５１）を、この手法で識別されたピクチャバッファ（３６１、３６２等）内に格納する。
【００５９】
符号化ピクチャ（３４１）及びMMCO/RPS情報（３４２）は、一時符号化データエリア（３７０）にバッファされる。符号化データエリア（３７０）内に集約される符号化データは、エレメンタリビットストリームのシンタックスの一部として、１つ以上のピクチャの符号化データを含む。符号化データエリア（３７０）内に集約される符号化データは、（例えば１つ以上の補足エンハンスメント情報（「ＳＥＩ」：supplemental  enhancement  information）メッセージ又はビデオユーザビリティ情報（「ＶＵＩ」：video  usability  information）メッセージ内の１つ以上のパラメータとして）符号化ビデオデータに関連するメディアメタデータも含むことができる。符号化データエリア（３７０）は、領域についての符号化領域を含むシンタックス構造と、これらのシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを、エレメンタリビットストリームの一部として格納するように構成されるバッファの例である。
【００６０】
ＳＥＩメッセージは、デコーダが様々な目的のために使用することができるメタデータである。フォーマットに関して、ＳＥＩメッセージは、（１）従うべきペイロードデータのペイロードタイプの指示、（２）従うべきペイロードデータのサイズ（バイト単位）の指示、及び（３）ペイロードデータの一連のゼロ又はそれ以上のバイトを含む、シンタックス構造である。ペイロードデータのシンタックスはペイロードタイプに依存する。一部の実装において、符号化領域の完了を示すシンタックス構造は、特別なタイプのＳＥＩメッセージである。H.265/HEVC規格では、ＳＥＩメッセージは、プレフィックスＳＥＩメッセージ又はサフィックスＳＥＩメッセージとすることができる。プレフィックスＳＥＩメッセージは、ピクチャの少なくとも一部の符号化された部分に先行するＳＥＩメッセージである。サフィックスＳＥＩメッセージは、ピクチャの少なくとも一部の符号化された部分に続くＳＥＩメッセージである。
【００６１】
一時符号化データエリア（３７０）から集約されたデータ（３７１）は、チャネルエンコーダ（３８０）によって処理される。チャネルエンコーダ（３８０）は、集約されたデータを（例えばITU-TH.222.0｜ISO/IEC13818-1のようなメディアプログラムストリーム又はトランスポートストリームフォーマット、あるいはIETF  RFC3550のようなインターネットリアルタイムトランスポートプロトコルフォーマットに従って）メディアストリームとして伝送又は格納するためにパケット化及び／又は多重化することができ、この場合、チャネルエンコーダ（３８０）は、メディア伝送ストリームのシンタックスの一部としてシンタックス要素を追加することができる。あるいは、チャネルエンコーダ（３８０）は、集約されたデータを（例えばISO/IEC  14496-12のようなメディアコンテナフォーマットに従って）ファイルとしての格納するために編成することができ、この場合、チャネルエンコーダ（３８０）は、メディアストレージファイルのシンタックスの一部としてシンタックス要素を追加することができる。あるいは、より一般的に、チャネルエンコーダ（３８０）は、１つ以上のメディアシステム多重化プロトコル又はトランスポートプロトコルを実装することができ、この場合、チャネルエンコーダ（３８０）は、プロトコルのシンタックスの一部としてシンタックス要素を追加することができる。チャネルエンコーダ（３８０）は、ストレージ、通信接続又は出力用の別のチャネルを表すチャネル（３９０）に出力を提供する。チャネルエンコーダ（３８０）又はチャネル（３９０）は、例えば順方向誤り訂正（「ＦＥＣ」：forward-error  correction）符号化及びアナログ信号変調のための他の要素（図示せず）も含んでよい。
【００６２】
ＩＶ．例示のデコーダシステム
図４は、例示のデコーダシステム（４００）のブロック図であり、この例示のデコーダシステム（４００）とともに、幾つかの説明される実施形態が実装されてよい。デコーダシステム（４００）は、リアルタイム通信のための超低レイテンシ又は低レイテンシ復号モード、トランスコーディングモード、並びにファイル又はストリームからのメディア再生のための高レイテンシ復号モードといった複数の復号モードのうちのいずれかで動作することができる汎用復号ツールとすることができ、あるいは、そのような復号モードの１つに適合される専用の復号ツールとすることができる。デコーダシステム（４００）を、オペレーティングシステムモジュールの一部として、アプリケーションライブラリの一部として、スタンドアロンアプリケーションの一部として、あるいは専用のハードウェアを使用して実装することができる。全体として、デコーダシステム（４００）は、チャネル（４１０）から符号化データを受け取り、出力宛先（４９０）への出力として再構築されたピクチャを生成する。受信される符号化データは、符号化領域の完成を示すシンタックス構造を含むことができる。
【００６３】
デコーダシステム（４００）は、ストレージ、通信接続又は入力としての符号化データのための別のチャネルを表すチャネル（４１０）を含む。チャネル（４１０）は、チャネル符号化された符号化データを生成する。チャネルデコーダ（４２０）は、符号化データを処理することができる。例えばチャネルデコーダ（４２０）は、（例えばITU-TH.222.0｜ISO/IEC13818-1のようなメディアプログラムストリーム又はトランスポートストリームフォーマット、あるいはIETF  RFC3550のようなインターネット・リアルタイム・トランスポートプロトコルフォーマットに従って）メディアストリームとして伝送又は格納するために集約されたデータを、パケット化解除及び／又は多重化解除し、この場合、チャネルデコーダ（４２０）は、メディア伝送ストリームのシンタックスの一部として追加されたシンタックス要素を解析することができる。あるいは、チャネルデコーダ（４２０）は、（例えばISO/IEC  14496-12のようなメディアコンテナフォーマットに従って）ファイルとして格納するために集約された符号化ビデオデータを分けることができ、この場合、チャネルデコーダ（４２０）は、メディアストレージファイルのシンタックスの一部として追加されたシンタックス要素を解析することができる。あるいは、より一般的に、チャネルデコーダ（４２０）は、１つ以上のメディアシステム多重化解除プロトコル又はトランスポートプロトコルを実装することができ、この場合、チャネルデコーダ（４２０）は、プロトコルのシンタックスの一部として追加されたシンタックス要素を解析することができる。チャネル（４１０）又はチャネルデコーダ（４２０）は、例えばＦＥＣ復号及びアナログ信号復調のための他の要素（図示せず）も含んでよい。
【００６４】
チャネルデコーダ（４２０）から出力される符号化データ（４２１）は、十分な量の符号化データが受け取られるまで、一時符号化データエリア（４３０）に格納される。符号化データ（４２１）は符号化ピクチャ（４３１）及びMMCO/RPS情報（４３２）を含む。符号化データエリア（４３０）内の符号化データ（４２１）は、エレメンタリビットストリームのシンタックスの一部として、１つ以上のピクチャの符号化データを含む。符号化データエリア（４３０）内の符号化データ（４２１）は、（例えば１つ以上のＳＥＩメッセージ又はＶＵＩメッセージ内の１つ以上のパラメータとして）符号化ビデオデータに関連するメディアメタデータも含むことができる。一部の実装において、符号化領域の完了を示すシンタックス構造は、特別なタイプのＳＥＩメッセージである。他の実装では、符号化領域の完了を示すシンタックス構造は、特別なタイプのＮＡＬユニットである。
【００６５】
一般に、符号化データエリア（４３０）は、符号化データ（４２１）がデコーダ（４５０）によって使用されるまで、その符号化データ（４２１）を一時的に格納する。符号化データエリア（４３０）は、エレメンタリビットストリームの一部として、領域についての符号化領域を含むシンタックス構造と、これらのシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを格納するように構成されるバッファの例である。以下で説明されるように、デコーダ（４５０）は、符号化領域（例えば符号化ピクチャ、符号化スライス）の完了を示すシンタックス構造を使用して、デコーダ（４５０）が符号化領域の復号を開始することができるよう、符号化データエリア（４３０）が符号化領域の符号化データの全てを有するときを決定することができる。符号化ピクチャ（４３１）のための十分な量の符号化データを受け取ると、符号化ピクチャ（４３１）及びMMCO/RPS情報（４３２）についての符号化データが、符号化データエリア（４３０）からデコーダ（４５０）に転送される。復号が継続するにつれて、新たな符号化データが符号化データエリア（４３０）に追加され、符号化データエリア（４３０）内に残っている最も古い符号化データがデコーダ（４５０）に転送される。
【００６６】
デコーダ（４５０）は、符号化ピクチャ（４３１）を復号して、対応する復号ピクチャ（４５１）を生成する。ピクチャを、同じサイズ又は異なるサイズの複数のタイルに分割することができる。ピクチャを１つ以上のスライスとして編成することもできる。スライス又はタイルのコンテンツをサンプル値のブロック又は他のセットに更に分割することができる。
【００６７】
必要に応じて、その復号処理を実行するときに、デコーダ（４５０）は、１つ以上の以前に復号されたピクチャ（４６９）をインターピクチャ予測の参照ピクチャとして使用してもよい。デコーダ（４５０）は、そのように以前に復号されたピクチャ（４６）を復号ピクチャ一時メモリストレージエリア（４６０）から読み出す。一般に、デコーダ（４５０）は、エントロピー復号、イントラピクチャ予測、動き補償インターピクチャ予測、逆量子化、逆周波数変換（スキップされない場合）及びタイルのマージのような復号タスクを実行する複数の復号モジュールを含む。デコーダ（４５０）によって実行される正確な動作は、圧縮フォーマットに応じて異なることができる。
【００６８】
例えばデコーダ（４５０）は、圧縮されたピクチャ又はピクチャのシーケンスの符号化データを受け取り、復号されたピクチャ（４５１）を含む出力を生成する。デコーダ（４５０）では、バッファが、符号化ピクチャについての符号化データを受け取り、適切な時に、受け取った符号化データをエントロピーデコーダに利用可能にする。エントロピーデコーダは、エントロピー符号化された量子化データ並びにエントロピー符号化されたサイド情報を復号し、典型的にはエンコーダで実行されたエントロピー符号化の逆を適用する。
【００６９】
動き補償器は、動き情報を１つ以上の参照ピクチャに適用して、再構築されているピクチャの任意のインター符号化ブロックについての動き補償された予測値を形成する。イントラピクチャ予測モジュールは、隣接する以前に再構築されたサンプル値から、現ブロックのサンプル値を空間的に予測することができる。あるいは、ＩＢＣ予測では、イントラピクチャ予測モジュールは、変位値により示される、ピクチャ内の参照ブロックの以前に再構築されたサンプル値を使用して、現ブロックのサンプル値を予測することができる。
【００７０】
デコーダ（４５０）は予測残差値も再構築する。逆量子化器は、エントロピー復号されたデータを逆量子化する。例えばデコーダ（４５０）は、ピクチャ、タイル、スライス及び／又はビデオの他の部分についてのＱＲの値をビットストリーム内のシンタックス要素に基づいて設定し、それに応じて変換係数を逆量子化する。逆周波数変換器は、量子化された周波数領域データを空間領域データに変換する。一部の実装では、周波数変換をスキップすることができ、この場合、逆周波数変換もスキップされる。そのようにする場合、予測残差値をエントロピー復号して逆量子化することができる。インターピクチャ予測ブロックでは、デコーダ（４５０）は、再構築された予測残差値を、動き補償された予測値と組み合わせる。デコーダ（４５０）は同様に、予測残差値をイントラピクチャ予測からの予測値と組み合わせることができる。
【００７１】
適応的デブロッキングフィルタが、ビデオデコーダ（４５０）の動き補償ループに含まれ、復号されたピクチャ（４５１）内のブロック境界行及び／又は列にわたる不連続性をスムーズにする。あるいはまた、（デリングフィルタリング、ＡＬＦ又はＳＡＯフィルタリング（図示せず）のような）他のフィルタリングをインループフィルタリング動作として適用することができる。
【００７２】
復号ピクチャ一時メモリストレージエリア（４６０）は、複数のピクチャバッファストレージエリア（４６１、４６２・・４６ｎ）を含む。復号ピクチャストレージエリア（４６０）は、復号ピクチャバッファの一例である。デコーダ（４５０）は、MMCO/RPS情報（４３２）を使用して、復号ピクチャ（４５１）を格納することができるピクチャバッファ（４６１、４６２等）を識別する。デコーダ（４５０）は、復号ピクチャ（４５１）をそのピクチャバッファ内に格納することができる。
【００７３】
出力シーケンサ（４８０）は、出力順で生成されることになる次のピクチャが、復号ピクチャストレージエリア（４６０）で利用可能になるときを識別する。出力順で生成されることになる次のピクチャが、復号ピクチャストレージエリア（４６０）で利用可能になると、該当する次のピクチャが、出力シーケンサ（４８０）によって読み取られて出力宛先（４９０）（例えばディスプレイ）に出力される。一般に、ピクチャが、出力シーケンサ（４８０）によって復号ピクチャストレージエリアから出力される順序は、ピクチャがデコーダによって復号される順序とは異なっていてよい。
【００７４】
Ｖ．復号領域の完了を示すシンタックス構造
このセクションは、符号化領域の完了を示すシンタックス構造における革新を示す。例えばエレメンタリビットストリーム内のシンタックス構造は、領域の符号化された表現である符号化領域の完了をを示す。領域は、ピクチャ内のスライス、タイル、ピクチャ又は他の任意の領域とすることができる。符号化領域の完了を示すシンタックス構造は、特別なタイプのＮＡＬユニット、特別なタイプの補足エンハンスメント情報（「ＳＥＩ」）メッセージ又は別のシンタックス構造とすることができる。この革新は、デコーダがより迅速に符号化ピクチャ境界を検出し、所与のピクチャの復号処理を開始することを可能にすることにより、復号中のレイテンシを低減することができる。これは、特に（レイテンシが５〜３０ミリ秒に限られる）超低レイテンシ・シナリオに役立つ可能性があるが、（より長いレイテンシの耐性がある）低レイテンシ・シナリオにも有益であり得る。また、複数の領域の復号を並列に実行することができるとき、この革新は、デコーダがより迅速に符号化領域境界を検出し、所与の領域の復号処理を開始することを可能にすることにより、復号中のレイテンシを低減することができる。本革新は、復号前にバッファする必要があるデータの量を減らすことにより、あるいは、受信データが到着するときにこの受信データを十分に解析する必要性をなくすことにより、復号処理を簡潔にすることができる。さらに、本革新は、誤り検出を容易にし、（例えばスライス又はタイルの）符号化データのパケットの損失に対するロバスト性を改善することができる。
【００７５】
Ａ．導入
H.264/AVC規格又はH.265/HEVC規格による復号では、デコーダは、該デコーダが所与のピクチャの符号化スライスを受け取った後に、そのピクチャについての復号処理を開始するように設計されてよく、この場合、デコーダは、符号化スライスの復号を開始することができる。しかしながら、多くの実装では、デコーダは、該デコーダが所与のピクチャの符号化データの全てを受け取った後に、所与のピクチャについての復号処理を開始するように設計される。H.264/AVC規格及びH.265/HEVC規格は、所与のピクチャの符号化データの全てを受け取ったときに状態を認識するためのルールを定義する。例えばH.264/AVC規格のセクション7.4.1.2.3（「order  of  NAL  units  and  coded  pictures  and  association  to  access  units」）及び7.4.1.2.4（「detection  of  the  first  VCL  NAL  unit  of  a  primary  coded  picture」）；例えばH.265/HEVC規格のセクション7.4.2.4.4（「order  of  NAL  units  and  coded  pictures  and  their  association  to  access  units」及び7.4.2.4.5（「order  of  VCL  NAL  units  and  association  to  coded  pictures」）を参照されたい。H.264/AVC規格又はH.265/HEVC規格で定義されるルールを使用して所与のピクチャの符号化データの完了を検出することは、符号化中にかなりのディレイ及び／又は複雑性を導入する可能性がある。特に、ディレイの導入は、極めて低レイテンシにすることが重要であるリアルタイムビデオ通信シナリオ（例えばビデオ会議、コンピューティングデバイスから近くのディスプレイへの無線「スクリーンキャスティング」、リモートビデオゲーム等のような）において問題となる。そのようなシナリオは、５〜３０ミリ秒の範囲の超低レイテンシを必要とすることがある。
【００７６】
１つの一般的なアプローチでは、デコーダが、所与のピクチャの符号化データの全てを受け取った後に、所与のピクチャについての復号処理を開始するように設計されるとき、完全な符号化ピクチャを受け取ったことを決定するために（すなわち、デコーダが、所与のアクセスユニット内の所与のピクチャについての符号化データの全てを受け取ったことを決定するために）、デコーダは、次のアクセスユニット内の（復号順で）次のピクチャについての特定のデータを受け取るか、シーケンス又はビットストリームの終了の指示を受け取るまで待機する。次のピクチャについてのデータは、次のピクチャの符号化データの開始と、暗示的に所与のピクチャの符号化データの完了とを示す１つ以上のシンタックス要素を含む。所与のピクチャの復号の開始が、次のピクチャのデータ内の値の識別に直接的に依存するので、このアプローチは多くの場合、復号中に最大で１ピクチャのディレイ（one-picture  delay）を追加する。絶対的には、ディレイは、特に超低レイテンシ復号シナリオ又は低レイテンシ復号シナリオにとって、かなりの量である可能性がある。そのような復号シナリオでは、異なるＶＣＬ  ＮＡＬユニット間の伝送の間、あるピクチャの最後のＶＣＬ  ＮＡＬユニットと次のピクチャの最初のVCL  ＮＡＬユニットとの間に、かなりの「デッドエアー（dead  air）」ギャップ（又はフィラーデータ（filler  data））が存在することがあり、完全な符号化ピクチャの受信を待つように設計されたデコーダのレイテンシを与えることになる。
【００７７】
例えばデコーダは、次のアクセスユニット内の（復号順で所与のピクチャの後の）次のピクチャの符号化スライスＮＡＬユニット内のシンタックス要素の値を識別することができ、このシンタックス要素の値は、次のピクチャの符号化データが開始されることを示す。シンタックス要素は、次のピクチャのスライスのスライスヘッダ内のフラグとすることができる。H.265/HEVC規格では、スライスセグメントヘッダ内のfirst_slice_segment_in_pic_flagの値が、そのスライスセグメントがピクチャ内の最初のスライスセグメントであるかどうかを示す。first_slice_segment_in_pic_flagの値が「１」の場合、そのスライスセグメントはピクチャ内の最初のスライスセグメントである。そうでなければ、スライスセグメントは、ピクチャ内の最初のスライスセグメントではない。あるいは、H.264/AVC規格による復号では、シンタックス要素は、フレーム数、ＰＰＳ識別子、あるいはスライスがピクチャ内の最初のスライスである場合にその値が変化し得る別のシンタックス要素である。次のピクチャの符号化データの開始は、その所与のピクチャについての符号化データの完了を意味する。これらの例では、次のピクチャの符号化スライスＮＡＬユニット内のシンタックス要素を使用して所与の符号化ピクチャの完了を検出するので、最大で１ピクチャのディレイが復号に追加される。
【００７８】
別の例として、デコーダは、エレメンタリビットストリーム内で、次のピクチャの復号データの開始を示すアクセスユニットデリミタ（「ＡＵＤ」：access  unit  delimiter）ＮＡＬユニットを識別することができる。デコーダが（復号順で所与のピクチャの後の）次のピクチャの符号化データの前のＡＵＤ  ＮＡＬユニットを受け取ると、デコーダは、所与のピクチャの符号化データが完了したと推論することができる。H.264/AVC規格及びH.265/HEVC規格では、ＡＵＤ  ＮＡＬユニットはオプションである。しかしながら、エレメンタリビットストリーム内に存在するとき、ＡＵＤ  ＮＡＬユニットは、アクセスユニットの最初のＮＡＬユニットであると仮定される。理論的には、次のピクチャのＡＵＤ  ＮＡＬユニットは、所与の符号化ピクチャの完了のすぐ後に、次のピクチャを受け取る前であっても出力することが可能であるが、実際には、これは、リアルタイム通信にとって、あるいは超低レイテンシ又は低レイテンシを必要とする他のシナリオにとって効果的なストラテジではない。簡潔に言うと、アクセスユニットにタイムスタンプを割り当てることに関するルールは、ＡＵＤ  ＮＡＬユニットの早期のシグナリングを妨げることがある。（例えばタイムスタンプが、パケット内で開始する最初のアクセスユニットに関連付けられ、パケット内のアクセスユニットは、そのアクセスユニット内のデータの最初のバイトがそのパケット内に存在するときに開始すると仮定する。存在する場合、タイムスタンプは、ＡＵＤ  ＮＡＬユニットと同じパケット内でなければいけないが、次のピクチャのタイムスタンプは、存在する場合、所与の符号化ピクチャの完了の時点で既知ではなくでもよい。タイムスタンプは通常、次のピクチャについてはまだ受信されていない可能性がある、入力ピクチャとともに提供される。また、タイムスタンプは、該タイムスタンプに関連付けられる符号化スライスデータと同じパケット内であることが予想されるが、この符号化スライスデータは、典型的に、所与の符号化ピクチャの完了の時点では準備ができていない。これらの要因は、次のピクチャのＡＵＤ  ＮＡＬユニットを送信する際にディレイを要する。）したがって、次のピクチャのＡＵＤ  ＮＡＬユニットの受信を待つことは、所与のピクチャの復号に対して最大で１ピクチャのディレイを与え、また所与の現在のピクチャの符号化スライスデータのための追加のバッファ空間を必要とすることもある。単にＡＵＤ  ＮＡＬユニットの早期のシグナリングを可能にするアクセスユニットの境界の位置は、他の理由にとっても望ましくない可能性がある。
【００７９】
別のアプローチにおいて、デコーダが、所与のピクチャの符号化データの全てを受け取った後に、所与のピクチャの符号化処理を開始するように設計されているとき、所与のピクチャの符号化データの全てを受け取ったことを決定するために、デコーダは、所与のピクチャの符号化データを十分に解析して、所与のピクチャの符号化データが完了したこと決定することができる。例えばデコーダは、符号化スライスＮＡＬユニットを受け取って十分に解析し、そのスライスが所与のピクチャを完成すると判断することができる。このアプローチは、潜在的に、復号中の何らかのディレイを回避するが、所与のピクチャの符号化データの全てを受け取ったかどうかを評価するためにデコーダによる追加の処理及び決定を行うことを必要とする可能性がある。
【００８０】
所与の符号化ピクチャについての符号化データが完了したかどうかを判断する別のアプローチは、次のアクセスユニットのデータに対する如何なる依存性もない、コンテナフォーマット又はサイドメタデータチャネル内のシンタックス要素を使用する。例えばH.264ビデオのためのRTPペイロードフォーマット（IETF  RFC  6184）によると、タイムスタンプにより指示されるアクセスユニットの最後のパケットを指示するようにマーカービット（marker  bit）を設定することができる。デコーダは、マーカービットをアクセスユニットの最後のパケットの早期の指示として使用してもよい。しかしながら、マーカービットは、エレメンタリビットストリームのシンタックスの一部ではなく、したがって、通常は利用可能ではない。また、マーカービットの使用は信頼できないことがある。
【００８１】
別のアプローチでは、メディア再生ツール内において、メディア再生ツール内のデマルチプレクサが、冗長ＡＵＤ  ＮＡＬユニット（redundant  AUD  NAL  unit）を作成することができる。１つのＡＵＤ  ＮＡＬユニットを使用して所与のピクチャの符号化データの終わりをシグナリングし、別のＡＵＤ  ＮＡＬユニットを使用して次のピクチャの符号化データの開始をシグナリングする。デマルチプレクサは、ＡＵＤ  ＮＡＬユニットをメディア再生ツール内のコアデコーダに提供する。コアデコーダは、第１の冗長ＡＵＤ  ＮＡＬユニットを使用して符号化ピクチャの完了を検出し、次いで第２のＡＵＤ  ＮＡＬユニットを使用して次のピクチャの符号化データの開始を検出することができる。このアプローチは、単一の符号化ピクチャの前の複数のＡＵＤ  ＮＡＬユニットを許容しないH.264/AVC規格又はH.265/HEVC規格に適合していない。したがって、このアプローチは一般的適用性を欠いており、多くのデコーダ実装と互換性がない。複数のＡＵＤ  ＮＡＬユニットのうちのいずれが、それに関連付けられる符号化データを有しているのか不明確であることがある。また、このアプローチによると、結果として得られるエレメンタリビットストリームを適合しないものにする可能性があるので、エンコーダ又は特定のメディア再生ツールの外側にある他のコンポーネントは、符号化ピクチャの完了を示すよう冗長ＡＵＤ  ＮＡＬユニットを挿入することができない。
【００８２】
Ｂ．符号化領域の完了を示すシンタックス構造の例
このセクションは、符号化領域の完了を示すシンタックス構造の例を説明する。例えばシンタックス構造を使用して、エレメンタリビットストリーム内の符号化ピクチャの終わりを示すことができ、次のアクセスユニットのデータに対する如何なる依存性も伴わずに、デコーダが符号化ピクチャの完了を検出することを可能にすることができる。このことは、完了した符号化ピクチャを検出する処理を簡潔にして加速させ、これにより、多くのシナリオにおける復号レイテンシを低減する。特に、超低レイテンシ又は低レイテンシを必要とするリアルタイム通信及び他のシナリオにおいて、レイテンシを低減することができる。符号化領域の完了を示すシンタックス構造を使用することは、復号の前にバッファされるデータ量を減らし、受信データが到着したときに十分に解析する必要なく、符号化ピクチャの完了の検出を可能にすることができる。
【００８３】
あるいは、別の例として、シンタックス構造を使用して、エレメンタリビットストリーム内に存在する次のスライスヘッダがもしあれば、次のスライスヘッダについて、スライスの最初のユニット（例えばブロック、マクロブロック、ＣＴＢ、ＣＴＵ）のアドレスを指示することができる。これは、デコーダが、次のアクセスユニットのデータに対する如何なる依存性も伴わずに、符号化スライス又は（一部の場合には）符号化ピクチャの完了を検出することを可能にする。完了した符号化ピクチャを検出する処理を簡潔にして加速させ、これにより復号レイテンシを減らすことに加えて、このシンタックス構造の使用は、領域セグメンテーションを使用する復号アーキテクチャにおけるパフォーマンスを改善することができる。そのような復号アーキテクチャでは、デコーダは、次のスライスヘッダを待つことなく、どのくらい多くのピクチャが、先行するＶＣＬ  ＮＡＬユニットに送信されたかを迅速に判断することができる。より一般的には、アクセスユニット境界はピクチャ全体の粒度を持つが、符号化スライス（又は他の部分的なピクチャ領域）の完了を示すシンタックス構造は、エレメンタリビットストリーム内のより細かな粒度の境界の挿入のための有益な機構を提供する。
【００８４】
エレメンタリビットストリーム内の符号化領域境界をマークすることにより、符号化領域の完了を示すシンタックス構造は、誤り検出を容易にし、符号化データのパケットの損失に対するロバスト性を改善することができる。例えばデコーダが、符号化ピクチャの完了を示すシンタックス構造を受け取るが、ピクチャの符号化データの全ては受け取っていないとき、デコーダは、ピクチャの一部について（スライスについて、タイルについて等）符号化データの損失を検出することができる。また、符号化データが破損した場合、デコーダは、符号化領域の完了を示すシンタックス構造を使用して、ビットストリームから符号化データの解析を確実に再スタートすることができるポイントを識別することが可能である。
【００８５】
符号化領域の完了を示すシンタックス構造を含むときにも、一部の例示の実装において、エレメンタリビットストリームは、コーデックフォーマット（例えばコーデック規格、専用フォーマット）に適合する。デコーダが、符号化領域の完了を示すシンタックス構造を認識しない場合であっても、エレメンタリビットストリームを、適合するデコーダによって復号することができる。したがって、これらの例示の実装において、符号化領域の完了を示すシンタックス構造を含むエレメンタリビットストリームは、そのシンタックス構造を認識するデコーダと互換性があり、また、そのシンタックス構造を認識しないデコーダとも互換性がある。また、デコーダ又は他のメディア処理ツールは、符号化領域の完了を示すシンタックス構造を挿入することができる。
【００８６】
実装に応じて、シンタックス構造は、特別なタイプのＮＡＬユニット、特別な対応のＳＥＩメッセージ又は他のシンタックス構造とすることができる。符号化領域の完了を示すシンタックス構造は、符号化領域を含む同じアクセスユニットの一部とすることができ、処理を簡潔にすることができる。符号化領域の完了を示すシンタックス構造を、H.264/AVC規格、H.265/HEVC規格又は別のコーデック規格又はフォーマットの変形又は拡張において使用することができる。所与の規格又はフォーマットにおいて、符号化領域の完了を示すシンタックス構造は、典型的に、ピクチャの符号化データの開始を示すシンタックス構造（例えばＡＵＤ  ＮＡＬユニット）とは異なる。また、ピクチャ間で複数のＡＵＤ  ＮＡＬユニットを使用するアプローチとは異なり、符号化領域の完了を示すシンタックス構造を使用することは、どのＮＡＬユニットが所与のアクセスユニットに関連付けられるかに関する曖昧さを回避する。
【００８７】
図５ａ及び図５ｂは、符号化領域の完了を示すシンタックス構造の使用の例（５０１、５０２）を示す。図５ａ及び図５ｂでは、ピクチャ（５１０）が３つのスライス、すなわち、スライスＡ（５１１）、スライスＢ（５１２）及びスライスＣ（５１３）を含む。ピクチャはタイルを含んでいない。代替的に、ピクチャ（５１０）は、スライス及び／又はタイルの何らかの他の構成を有することができる。
【００８８】
エンコーダは、ピクチャ（５１０）のスライス（５１１、５１２、５１３）を符号化し、これらのスライスのための符号化データを生成する。特に、エンコーダは、符号化スライスＡを含む１つ以上のシンタックス構造（５２１）、符号化スライスＢを含む１つ以上のシンタックス構造（５２２）及び符号化スライスＣを含む１つ以上のシンタックス構造（５２３）を生成する。シンタックス構造は、例えばH.264/AVC規格又はH.265/HEVC規格による符号化スライスＮＡＬユニットである。代替的に、符号化スライスデータのためのシンタックス構造は別のタイプのシンタックス構造である。
【００８９】
図５ａでは、シンタックス構造（５３０）が符号化領域の完了を示す。具体的には、シンタックス構造（５３０）は、符号化スライスＣを含むシンタックス構造（５２３）に従う。例えばシンタックス構造（５３０）は、ピクチャ（５１０）の符号化データの終わり（すなわち、符号化データの完了）を示す特別なタイプのＮＡＬユニットとすることができる。あるいは、シンタックス構造（５３０）は、ピクチャ（５１０）の符号化データの終わりでもあるスライスＣ（５１３）の符号化データの終わり（すなわち、符号化スライスＣの完了）を示す特別なタイプのＳＥＩメッセージとすることができる。
【００９０】
図５ｂでは、３つのシンタックス構造（５３１、５３２、５３３）が、符号化領域の完了を示す。具体的には、シンタックス構造（５３１）は、符号化スライスＡを含むシンタックス構造（５２１）に従い、シンタックス構造（５３２）は、符号化スライスＢを含むシンタックス構造（５２２）に従い、シンタックス構造（５３３）は、符号化スライスＣを含むシンタックス構造（５２３）に従う。例えばシンタックス構造（５３１、５３２、５３３）の各々は、それに先行する符号化スライス（５２１、５２２、５２３）の完了を示す特別なタイプのＳＥＩメッセージとすることができる。
【００９１】
図５ａにおいて、シンタックス構造（５３０）は、符号化ピクチャである符号化領域の完了を示すことができる。図５ｂにおいて、シンタックス構造（５３１、５３２、５３３）は、符号化スライスである符号化領域の完了を示し、３つめのシンタックス構造（５３３）は符号化ピクチャの完了も示す。より一般的に、符号化領域の完了を示すシンタックス構造は、所与のピクチャにおける任意領域（arbitrary  region）についての符号化データの終わりを示すことができる。任意領域は、スライス、ピクチャ又は何らかの量のブロック又はピクチャ内の他のユニットに相当する可能性がある。例えばシンタックス構造は、ビットストリーム内の符号化データを有する、（定義されたスキャン順で）次のユニット（例えばブロック、マクロブロック、ＣＴＢ、ＣＴＵ）のアドレスを指定するシンタックス要素を含む。暗に、符号化データは、所与のピクチャ内の（定義されたスキャン順で）次のユニットの前の全てユニットについて受け取られている。次のユニットのアドレスがゼロの場合、所与のピクチャの符号化データの終わりが示される（すなわち、ビットストリーム内の符号化データを有する次のユニットがもしあれば、次のユニットは、次のピクチャのユニットゼロ（unit  zero）である）。定義されるスキャン順は、所与のピクチャにわたるラスタスキャンパターン（raster  scan  pattern）、タイル優先順位付け（tile-prioritized）ラスタスキャンパターン（例えばタイル内の左から右へ、タイルが終了するまでそのタイル内で上から下まで反復し、次いで、もしあれば右の次のタイルに続くか、もしあれば、所与のピクチャの上から下にスキャンされるタイルの行として、所与のピクチャ内のタイルの次の行に続くユニット）、あるいはエンコーダ及びデコーダで定義される何らかの他のスキャン順とすることができる。符号化された任意領域の完了を示すシンタックス構造の挿入は、符号化領域の復号が開始するときに、（例えばコンテキスト適応型バイナリ算術符号化／復号について）エントロピー復号処理の正しさを示すこともできる。すなわち、（例えば満たされなかった可能性があるエントロピー復号の依存性に起因して）シンタックス構造がデコーダによって受け取られてからできるだけすぐに符号化領域の復号が開始することができない場合、符号化領域の完了を示すシンタックス構造を挿入するべきではない。
【００９２】
図６は、符号化領域の完了を示す例示のピクチャの終わりのＮＡＬユニット（end-of-picture  NAL  unit）の部分（６００）のシンタックスを示す。特に、図６は、ピクチャの終わりのＮＡＬユニットのローバイト・シーケンスペイロード（「ＲＢＳＰ」：raw  byte  sequence  payload）を示す。全体的に、ピクチャの終わりのＮＡＬユニットは、（一般に、H.265  ＮＡＬユニットのための）H.265/HEVC規格のセクション7.3.1.1及び7.3.1.2で定義されるように編成されることができ、（一般に、H.264  ＮＡＬユニットのための）H.264/AVC規格のセクション7.3.1で定義されるように編成されることができ、あるいは何らかの他の方法で編成されることができる。
【００９３】
ピクチャの終わりのＮＡＬユニットのシンタックス要素（例えばnal_unit_type）は、領域の終わりのインジケータ（end-of-region  indicator）としてＮＡＬユニットを指定する。例えばH.264/AVC実装では、nal_unit_typeは22という値を有する。この値は現在、H.264/AVC規格におけるリザーブ値である。別の例として、H.265/HEVC実装では、nal_unit_typeは45という値を有し、の値は現在、H.265/HEVC規格におけるリザーブ値である。代替的に、nal_unit_typeは別の値を有し、あるいはＮＡＬユニットタイプ拡張機構が使用される。一般に、H.264/AVC規格又はH.265/HEVC規格を拡張し、結果として得られるエレメンタリビットストリームがH.264/AVC規格又はH.265/HEVC規格に整合するように、以前にリザーブしたnal_unit_typeの値を新たなＮＡＬユニットのタイプに割り当てることができる。デコーダが、ＮＡＬユニットの新たなタイプを認識しない場合、デコーダは単に、そのＮＡＬユニットの新たなタイプを無視することができる。
【００９４】
図６では、ピクチャの終わりのＮＡＬユニットのＲＢＳＰ部分（６００）は、シンタックス要素を含んでいない。代替的には、ＲＢＳＰ部分（６００）は、例えば復号すべき次のユニットのアドレスを指定する１つ以上のシンタックス要素を含むことができ、この場合、ピクチャの終わりのＮＡＬユニットを、領域の終わりのインジケータとして、より一般的に使用することができる。
【００９５】
一部の例示の実装では、エレメンタリビットストリーム内のピクチャの終わりのＮＡＬユニットの配置に対する制約が存在する。例えばH.264/AVC実装では、ピクチャの終わりのＮＡＬユニットが存在するとき、ピクチャの終わりのＮＡＬユニットは、プライマリ符号化ピクチャに続く第１のＮＡＬユニット、（もしあれば）全ての冗長符号化ピクチャ、（もしあれば）ＮＡＬユニットを分割することなく、補助符号化ピクチャ（auxiliary  coded  picture）の全ての符号化スライス及び（もしあれば）フィラーデータＮＡＬユニットである必要がある。あるいは、H.265/HEVC実装では、ピクチャの終わりのＮＡＬユニットが存在するとき、このピクチャの終わりのＮＡＬユニットは、アクセスユニットの最後のＶＣＬ  ＮＡＬユニットに従い、そしてFD_NUT（フィラーデータのＮＡＬユニットタイプ）又はSUFFIX_SEI_NUTに等しいか、RSV_NVCL46．．．SV_NVCL47又はUNSPEC56．．．UNSPEC63の範囲内のnal_unit_typeのＮＡＬユニット（もしあれば）に従う必要がある。あるいは、エレメンタリビットストリームにおけるピクチャの終わりのＮＡＬユニットの配置に関して、他の及び／又は追加の制約が適用される。
【００９６】
図７は、符号化領域の完了を示す例示の領域の終わりのＳＥＩメッセージ（end-of-region  SEI  message）の部分（７００）のシンタックスを示す。特に、図７は、領域の終わりのＳＥＩメッセージのペイロードを示す。領域の終わりのＳＥＩメッセージは、（一般に、H.265  ＮＡＬユニットのための）H.265/HEVC規格のセクション7.3.2.3.1で定義されるように編成されることができ、あるいは何らかの他の方法で編成されることができる。
【００９７】
領域の終わりのＳＥＩメッセージ内の１つ以上のシンタックス要素は、領域の終わりのインジケータとしてＳＥＩメッセージを指定する。例えばH.264/AVC実装では、ＳＥＩメッセージは領域の終わりのＳＥＩメッセージに割り当てられるペイロードタイプ値を有する。一般に、H.265/HEVC規格を拡張し、結果として得られるエレメンタリビットストリームがH.265/HEVC規格に整合するように、以前に未割り当てのペイロードタイプの値を、ＳＥＩメッセージの新たなタイプに割り当てることができる。デコーダが、ＳＥＩメッセージの新たなタイプを認識しない場合、デコーダは単に、そのＳＥＩメッセージの新たなタイプを無視することができる。
【００９８】
図７では、領域の終わりのＳＥＩメッセージのペイロード部分（７００）は、単一のシンタックス要素を含む。シンタックス要素next_segment_addressは、存在するときにはエレメンタリビットストリーム内の次のスライスヘッダ内のシンタックス要素slice_segment_addressの値を示す。H.265/HEVC規格では、slice_segment_addressというシンタックス要素は、ピクチャのＣＴＢラスタスキャン順でスライスセグメント内の最初のＣＴＢのアドレスを指定する。しかしながら、ピクチャの最初のスライスセグメントについて（すなわち、first_slice_in_pic_flagが１に等しいとき）、あるいは次のスライスヘッダがビットストリーム内に存在しない場合、次のスライスヘッダ内のslice_segment_addressというシンタックス要素は、エレメンタリビットストリーム内に存在しない。図５ｂの例では、例えばシンタックス構造（５３１）が領域の終わりのＳＥＩメッセージであり、そのペイロードが図７のように編成される場合、ＳＥＩメッセージ内のシンタックス要素next_segment_addressは、スライスＢのスライスヘッダ内のslice_segment_addressに等しい値を有する。
【００９９】
次のスライスが、次のピクチャの最初のスライスであるとき（例えばH.265/HEVC実装において、次のスライスヘッダが、１に等しいfirst_slice_in_pic_flagを有するとき）、あるいはビットストリーム内に次のスライスヘッダが存在しないとき、next_segment_addressの値は０に等しい。図５ｂの例では、例えばシンタックス構造（５３３）が領域の終わりのＳＥＩメッセージであり、そのペイロードが図７のように編成される場合、ＳＥＩメッセージ内のシンタックス要素next_segment_addressは値ゼロを有する。
【０１００】
あるいは、コーデック規格又はフォーマットが、スライスセグメントではなくスライスを使用する場合、ＳＥＩメッセージは、ビットストリーム内の符号化データを有する次のスライスのスライスアドレスを示すシンタックス要素を含むことができる。スライスアドレスは、例えばブロック、マクロブロック、ＣＴＢ、ＣＴＵ又は次のスライスを開始する他のユニットのアドレスとすることができ、あるいはスライスアドレスは、次のスライス又はその開始点の何らかの他の識別子とすることができる。次のスライスのスライスアドレスがゼロの場合、所与のピクチャの符号化データの終わりを示す（すなわち、ビットストリーム内の符号化データを有する次のユニットは、もしあれば、次のピクチャのユニットゼロである）。
【０１０１】
あるいは、より一般的に、ＳＥＩメッセージは、ビットストリーム内の符号化データを有する領域（例えばスライス、タイル、ピクチャ）の次のユニット（例えばブロック、マクロブロック、ＣＴＢ、ＣＴＵ）のアドレスを示すシンタックス要素を含むことができる。次のユニットのアドレスがゼロである場合、所与のピクチャの符号化データの終わりを示す（すなわち、ビットストリーム内の符号化データを有する次のユニットは、もしあれば、次のピクチャのユニットゼロである）。あるいは、ペイロード部分（７００）は、（例えばＳＥＩメッセージが符号化ピクチャの完了を示す場合）シンタックス要素を全く含まないことも可能であり、ペイロード部分（７００）が、他の及び／又は追加のシンタックス要素を含むことも可能である。
【０１０２】
図７では、シンタックス要素next_segment_addressは、符号なし指数ゴロム符号化（ue(v)として示される）を使用して表される。このアプローチは、値ゼロを表すのに使用されるビット数を減らす。値ゼロは、（もしあれば、次のスライスが新たな符号化ピクチャを開始することを示す）シンタックス要素next_segment_addressの最も一般的な値であるよう予想される。例えばシングルビット値１は、next_segment_addressの値ゼロを表す。反対に、H.265/HEVC規格によると、シンタックス要素slice_segment_addressは、符号なし整数の固定長の表現を使用して表され、この場合、（ピクチャの幅と高さについての）他のシンタックス要素は、固定長の表現の長さを示す。領域の終わりのＳＥＩメッセージ内のシンタックス要素next_segment_addressも、符号なし整数の固定長表現を使用して表すことができるが、これは、符号なし整数の固定長表現におけるビット数を示す別のシンタックス要素への依存性を生じることがある。代替的には、シンタックス要素next_segment_addressは何らかの他の方法で表される。
【０１０３】
エレメンタリビットストリーム内の領域の終わりのＳＥＩメッセージの配置における制約が存在することがある。一部の例示の実装では、例えば符号化領域の完了を示すＳＥＩメッセージはサフィックスＳＥＩメッセージである。領域の終わりのＳＥＩメッセージがサフィックスＳＥＩメッセージである場合、このＳＥＩメッセージを、その完了が示される符号化領域と同じアクセスユニット内に配置することができる。複数の領域の終わりのサフィックスＳＥＩメッセージを、所与のアクセスユニットに配置することができる。あるいは、領域の終わりのＳＥＩメッセージはプレフィックスＳＥＩメッセージとすることもできる。領域の終わりのＳＥＩメッセージがプレフィックスＳＥＩメッセージである場合、このＳＥＩメッセージを次のアクセスユニット内に、その完了が示される符号化領域の後に配置することができる。あるいは、エレメンタリビットストリーム内の領域の終わりのＳＥＩメッセージの配置に関して、他の及び／又は追加の制約が適用される。
【０１０４】
従属スライスセグメント（dependent  slice  segments）が有効にされる場合、次のスライスセグメントが従属スライスセグメントであれば、領域の終わりのＳＥＩメッセージの存在を禁止することができる。あるいは、次のスライスセグメントが従属スライスセグメントであるとき、領域の終わりのＳＥＩメッセージは、従属スライスセグメントの最初のＣＴＵの位置を示すことができる（例えば領域の終わりのＳＥＩメッセージのnext_segment_addressというシンタックス要素は、次の従属スライスセグメントについてのスライスヘッダ内のslice_segment_addressというシンタックス要素の値を示す）。
【０１０５】
H.264/AVC規格は現在、サフィックスＳＥＩメッセージをサポートしていない。H.264/AVC規格によると、ＳＥＩメッセージは、アクセスユニットの開始で符号化ピクチャに先行する。図７に示されるような領域の終わりのＳＥＩメッセージを使用するために、サフィックスＳＥＩメッセージをサポートするようH.264/AVC規格を拡張することができる。２つの符号化ツール、すなわち、任意のスライス順又はフレキシブルなマクロブロック順は、H.264/AVC規格の少なくとも一部のプロファイルについて他の複雑性（complications）を与える。これらの２つの符号化ツールでは、スライスのユニットは、符号化領域の完了のシグナリングを複雑にする可能性がある、簡単で定義されたスキャン順を使用する必要がない。
【０１０６】
Ｃ．符号化領域の完了を示すシンタックス構造の例示の使用
図８は、符号化領域の完了を示すシンタックス構造を挿入するための一般化した技術（８００）を図示している。ビデオエンコーダ（例えば図３に図示されるエンコーダ（３４０）又は他のエンコーダ）、マルチプレクサ（例えば図３に図示されるチャネルエンコーダ（３８０）又は他のマルチプレクサ）又はビットストリームエディタのようなメディア処理ツールが、技術（８００）を実行することができる。図９は、符号化領域の完了を示すシンタックス構造を使用するための一般化した技術を図示している。ビデオデコーダ（例えば図４に図示されるデコーダ（４５０）又は他のデコーダ）、デマルチプレクサ（例えば図４に図示されるチャネルデコーダ（４２０）又は他のデマルチプレクサ）又はビットストリームエディタのようなメディア処理ツールが、技術（９００）を実行することができる。
【０１０７】
図８を参照すると、メディア処理ツール（エンコーダ、マルチプレクサ又はビットストリームエディタ等）が、画像又はビデオの領域について符号化領域の完了を検出する（８１０）。符号化領域は、領域の符号化された表現であり、領域は、スライス、タイル、ピクチャ又はピクチャ内の他の任意領域とすることができる。
【０１０８】
メディア処理ツールは、エレメンタリビットストリーム内において、符号化領域を含む１つ以上のシンタックス構造と、符号化領域を含む１つ以上のシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを出力する（８２０）。例えば異なるシンタックス構造は、符号化スライス、符号化タイル又は符号化ピクチャの完了を示す。あるいは、異なるシンタックス構造は、ピクチャ内の何らかの他の任意の領域についての符号化データの完了を示す。典型的に、エレメンタリビットストリームは、コーデックフォーマットに適合する。
【０１０９】
エレメンタリビットストリーム内の単一のアクセスユニットが、符号化領域を含むシンタックス構造と、符号化領域の完了を示す異なるシンタックス構造とを含むことができる。符号化領域の完了を示す異なるシンタックス構造を含むときも、エレメンタリビットストリームは、コーデックフォーマット（例えばコーデック規格、専用のフォーマット）に適合する。単一のアクセスユニットが、複数の符号化領域（例えば所与のピクチャの複数の符号化スライス）を含むシンタックス構造、並びに符号化領域の完了をそれぞれ示す複数の異なるシンタックス構造を含むことができる。
【０１１０】
メディア処理ツールがエンコーダである場合、該メディア処理ツールは領域を符号化して符号化領域を生成することもできる。この場合、符号化は、符号化領域の完了の検出（８１０）と、その検出（８１０）に基づく、エレメンタリビットストリームへの異なるシンタックス構造の追加を含むことができる。
【０１１１】
図９を参照すると、メディア処理ツール（デコーダ、デマルチプレクサ又はビットストリームエディタ等）が、エレメンタリビットストリーム内において、符号化領域を含む１つ以上のシンタックス構造と、符号化領域を含む１つ以上のシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを受け取る（９１０）。例えば異なるシンタックス構造は、符号化スライス、符号化タイル又は符号化ピクチャの完了を示す。あるいは、異なるシンタックス構造は、ピクチャ内の何らかの他の任意の領域についての符号化データの完了を示す。典型的に、エレメンタリビットストリームは、コーデックフォーマットに適合する。
【０１１２】
エレメンタリビットストリーム内の単一のアクセスユニットが、符号化領域を含むシンタックス構造と、符号化領域の完了を示す異なるシンタックス構造とを含むことができる。異なるシンタックス構造を含むときも、エレメンタリビットストリームは、コーデックフォーマット（例えばコーデック規格、専用のフォーマット）に適合する。単一のアクセスユニットが、複数の符号化領域（例えば所与のピクチャの複数の符号化スライス）を含むシンタックス構造、並びに符号化領域の完了をそれぞれ示す複数の異なるシンタックス構造を含むことができる。
【０１１３】
メディア処理ツールは、異なるシンタックス構造を使用して符号化領域の完了を検出する（９２０）。符号化領域は、画像又はビデオの領域の符号化された表現であり、領域は、スライス、タイル、ピクチャ又はピクチャ内の他の任意領域とすることができる。メディア処理ツールがデコーダである場合、該メディア処理ツールは、符号化領域を復号してその領域を再構築することもできる。メディア処理ツールのデコーダを、全体としてソフトウェアで実装することができる。あるいは、デコーダの少なくとも一部の操作を、専用のハードウェアを使用して実行することもできる（例えば特定の復号操作をＧＰＵ又は他の加速ハードウェアにオフロードするか、復号操作のための専用のハードウェアデコーダを使用する）。
【０１１４】
図８及び図９に関連して、符号化領域を含むシンタックス構造は、H.265/HEVC規格又はH.264/AVC規格に従って符号化されたスライスＮＡＬユニットとすることができる。あるいは、シンタックス構造は、符号化領域の符号化データを含む何らかの他のタイプのシンタックス構造とすることができる。
【０１１５】
図８及び図９に関連して、異なるシンタックス構造は、ＮＡＬユニットタイプを有するＮＡＬユニットとすることができ、この場合、ＮＡＬユニットタイプは、（例えば図６に関連して説明したように）ＮＡＬユニットを領域の終わりのインジケータとして指定する。あるいは、異なるシンタックス構造は、ペイロードタイプを有するＳＥＩメッセージとすることができ、この場合、ペイロードタイプは、（例えば図７に関連して説明したように）ＳＥＩメッセージを領域の終わりのインジケータとして指定する。ＳＥＩメッセージは、サフィックスＳＥＩメッセージ又はプレフィックスＳＥＩメッセージとすることができる。あるいは、異なるシンタックス構造は別のタイプのシンタックス構造とすることもできる。１つ以上の制約が、符号化領域の完了を示すシンタックス構造のエレメンタリビットストリーム内の配置を制御してもよい。制約の例は、図８及び図９に関連して説明されている。あるいは、他の及び／又は追加の制約が、符号化領域の完了を示すシンタックス構造のエレメンタリビットストリーム内の配置に関連して適用される。いずれかの場合において、符号化領域を含むシンタックス領域と、符号化領域の完了を示すシンタックス構造は、典型的に、符号化領域の完了の検出を容易にする所定の順序である。例えば符号化領域を含むシンタックス領域と、符号化領域の完了を示すシンタックス構造は、アクセスユニットのためのＮＡＬユニットの特定の順序に従う。あるいは、符号化領域を含むシンタックス領域と、符号化領域の完了を示すシンタックス構造は、コーデックフォーマットに従って定義される何らかの他の方法で順序付けされる。
【０１１６】
図８及び図９に関連して、符号化領域の完了を示すシンタックス構造は、空（シンタックス要素を含まない）とすることができる。例えばこのシンタックス構造は、ピクチャについての符号化データの完了を示す。あるいは、符号化領域の完了を示すシンタックス構造は、１つ以上のシンタックス要素を含むことができる。例えばシンタックス構造は、次のスライスヘッダについてスライスの最初のユニットのアドレス（例えば次のスライスセグメントヘッダのスライスセグメントアドレス）を含む。アドレスがゼロの場合、シンタックス構造は、（符号化領域の完了として）ピクチャの最後のスライスについての符号化データの完了を示す。そうではなく、アドレスがゼロ超の場合、シンタックス構造は、（符号化領域の完了として）ピクチャの最後でないスライスについての符号化データの完了を示す。あるいは、符号化領域の完了を示すシンタックス構造は、他の及び／又は追加のシンタックス要素を含む。
【０１１７】
あるいは、（デコーダのような）メディア処理ツールは、エレメンタリビットストリーム内において、符号化領域を含む１つ以上のシンタックス構造と、符号化領域を含む１つ以上のシンタックス構造の後に、符号化領域の完了を示す異なるシンタックス構造とを受け取る。メディア処理ツールは、異なるシンタックス構造を処理すること（例えば異なるシンタックス構造を使用して符号化領域の完了を検出すること）ができ、あるいは異なるシンタックス構造を無視すること（例えば異なるシンタックス構造を破棄すること）ができる。メディア処理ツールは、符号化領域を復号して領域を再構築する。復号は、全体としてソフトウェアで実施することができる。あるいは、復号の少なくとも一部の操作を、専用のハードウェアを使用して実行することができる（例えば特定の復号操作をＧＰＵ又は他の加速ハードウェアにオフロードするか、復号操作のための専用のハードウェアデコーダを使用する）。異なるシンタックス構造は、上述のようにＮＡＬユニット、ＳＥＩメッセージ又は他のタイプのシンタックス構造とすることができ、また上述のように空であってもよく、１つ以上のシンタックス構造を含むこともできる。
【０１１８】
開示される革新の原理を適用することができる多くの可能性のある実施形態の観点で、図示される実施形態は、単に本革新の好ましい例にすぎず、本革新の範囲を限定するように解釈されるべきではないことを認識されたい。むしろ、本革新の範囲は以下の特許請求の範囲によって定められる。したがって、これらの特許請求の範囲及びその精神の中に入る全ての発明を特許請求する。
【図１】
2017535167.tif 000003
【図２ａ】
2017535167.tif 000004
【図２ｂ】
2017535167.tif 000005
【図３】
2017535167.tif 000006
【図４】
2017535167.tif 000007
【図５ａ】
2017535167.tif 000008
【図５ｂ】
2017535167.tif 000009
【図６】
2017535167.tif 000010
【図７】
2017535167.tif 000011
【図８】
2017535167.tif 000012
【図９】
2017535167.tif 000013
【国際調査報告】
2017535167.tif 000014
2017535167.tif 000015
2017535167.tif 000016