JP6238318B2 - ビデオランダムアクセスを簡素化する制約及びユニットタイプ - Google Patents

Description

本出願は、ビデオエンコーディング及びデコーディングに関し、詳細には、ランダムアクセスポイントピクチャに関連した改良に関する。

エンジニアは、圧縮（情報源符号化又は情報源エンコーディングとも言う）を使用して、デジタルビデオのビットレートを低減させる。圧縮は、情報をより低いビットレート形式に変換することによって、ビデオ情報を記憶及び送信するコストを減らす。展開（デコーディングとも言う）は、圧縮された形式から元のバージョンの情報を再構成する。「コーデック」は、エンコーダ／デコーダシステムである。

ここ20年にわたり、様々なビデオコーデック標準が採用されており、そのビデオコーデック標準には、H.261、H.262（MPEG-2又はISO/IEC 13818-2）、H.263及びH.264（AVC又はISO/IEC 14496-10）標準と、MPEG-1（ISO/IEC 11172-2）、MPEG-4 Visual（ISO/IEC 14496-2）及びSMPTE 421M標準とを含む。より直近では、HEVC標準が開発下にある。ビデオコーデック標準は、通常、エンコードされるビデオビットストリームのシンタックスのためのオプションを定めており、特定の特徴がエンコーディング及びデコーディングにおいて使用されるときの、ビットストリーム内のパラメータを詳述している。多くの場合、ビデオコーデック標準は、デコーダがデコーディングにおいて正しい結果を達成するために実行すべきデコーディングオペレーションに関する詳細も提供する。

ブロードキャスティング及びストリーミングアプリケーションにおいて、デコーダがエンコードされたビットストリーム内のポイントにランダムにアクセスし、このランダムアクセスポイントからピクチャをデコードする能力は、望ましい特徴である。こうしたランダムアクセスは、例えば、ビューアがブロードキャストかストリームかの間で切り替わるとき、あるいはビットストリームの接合が行われるとき、発生する。

要約すると、詳細な説明は、クリーンランダムアクセス（CRA）ピクチャ及び／又は他のタイプのランダムアクセスポイント（RAP）ピクチャを有するビットストリームのためのイノベーションを提示する。RAPピクチャのタイプにおける新しいタイプ定義及び戦略的制約により、基本コンテナフォーマットへのビデオストリームデータのユニットのマッピングを簡素化することができる。こうしたイノベーションは、ビデオ符号化システムが適応的ビデオ配信、製作物編集、コマーシャル挿入及び同様のことをより柔軟に行う能力の向上に役立ち得る。

これに限定されないが、本明細書に説明されるイノベーションにより、ビットストリームの始めにおいてだけでなくビットストリームの中間にあるCRAピクチャが、ビットストリーム内でCRAピクチャの後に現れる1又は複数の潜在的にデコード不能なピクチャを有することができる。いくつかの用法において、これらの潜在的にデコード不能なピクチャは、ビットストリーム内でCRAピクチャの後に現れ、しかしながらCRAピクチャの表示出力順の前に来る識別された表示出力順を有するという意味において、CRAピクチャに対するリーディングピクチャである。換言すると、ビットストリームの始めにおけるCRAピクチャがデコード不能リーディングピクチャを有することが可能であることに加えて、ビットストリームは、ビットストリームの始め以外のところに存在し、かつ潜在的にデコード不能なピクチャを有するCRAピクチャを有することが可能となり、この潜在的にデコード不能なピクチャは、ビットストリームの中でCRAピクチャの後に続く。この文脈において、リーディングピクチャは、ビットストリーム順序（符号化順序、デコード順序、デコーディング順序等とも言う）においてCRAピクチャの後に続くが、表示順序（出力順序とも言う）においてCRAピクチャの前に来るピクチャである。ビットストリームの始めのCRAピクチャは、前の参照ピクチャを欠くことに起因してデコードされない可能性があるリーディングピクチャが（ビットストリーム順序において）後に続くことが許されている。今回、ビットストリームの中間に入るCRAピクチャもまた、ビットストリームの中で上記のようなデコード不能ピクチャが後に続くことが許される。開示されるテクノロジーの実施形態に従い、ビットストリーム中間CRAピクチャの後のデコード不能リーディングピクチャの存在に対する制約が取り除かれる。

特定の例示的な実装において、CRAピクチャに対する上記のようなデコード不能リーディングピクチャの潜在的な存在を示すフラグ又は他のインジケータが追加される（例えば、ピクチャレベル情報として、スライスヘッダの中になど）。インジケータを（例えばデコーダが）使用して、リーディングピクチャをどのように扱うか（例えば、デコーダがリーディングピクチャをデコードすべきかどうか）を決定することができる。例えば、本明細書に説明されるブロークンリンク機能性が使用されるとき、リーディングピクチャが存在するかどうかとどのタイプのリーディングピクチャが存在するかを示すために、種々のネットワーク抽象化レイヤ（NAL）ユニットタイプが使用される。さらに、これらのNALユニットタイプは、CRAのための通常のNALユニットタイプとは異なる。また、特定の例示的な実装において、リーディングピクチャとしてのピクチャの分類を潜在的にデコード不能なピクチャを識別するルールとして用いるのではなく、潜在的にデコード不能なピクチャを明示的に識別するように、フラグ又は他のインジケータが追加される（例えば、潜在的にデコード不能なピクチャのためのピクチャレベルにおけるシンタックス要素として、潜在的にデコード不能なピクチャを合図するNALユニットタイプとしてなど）。

本明細書に説明される他のイノベーションには、これらに限定されないが、（a）コンテナフォーマットへのビデオ基本ストリームデータのユニットのマッピングを簡素化する、RAPピクチャのためのユニットタイプの新しい定義、（b）上記のようなマッピングオペレーションを簡素化する、RAPピクチャにおける戦略的制約、及び（c）冗長なユニットタイプの除去を含む。

本明細書において導入される新しいCRAピクチャタイプとその関連するフラグ又は他のインジケータとの実施形態は、「ブロークンリンクアクセス」（BLA）ピクチャと呼ばれることがある。こうしたBLAピクチャとその関連するインジケータとの使用は、デコーダがデコーディングを始めることができるアクセスポイントの数を増加させることができ、これにより、ビデオデコーディングシステムは、改良されたスピードとシームレス性とを備えて、早送りオペレーション、巻き戻しオペレーション、スキャニングオペレーション、接合オペレーション又はビデオストリーム間の切り替えオペレーションなどの様々なオペレーションを行うことができる。さらに、こうしたBLAピクチャとその関連するインジケータとの使用は、ビデオエンコーディングシステム又はビデオデコーディングシステムが適応的ビデオ配信、製作物編集、コマーシャル挿入及び同様のことをより柔軟に行うことを可能にすることができる。

本発明の前述及び他の目的、特徴及び利点が、添付の図面を参照して進められる下記の詳細な説明からより明らかになるであろう。

いくつかの説明される実施形態を実施することができる一例示的コンピューティングシステムの図である。 図2a及び図2bは、いくつかの説明される実施形態を実施することができる例示的ネットワーク環境の図である。 一例示的エンコーダシステムの図であり、このエンコーダシステムと連動していくつかの説明される実施形態を実施することができる。 一例示的デコーダシステムの図であり、このデコーダシステムと連動していくつかの説明される実施形態を実施することができる。 CRAピクチャを含む符号化されたピクチャの一例示的シーケンスを例示する図である。 ビットストリームを生成するための第1の例示的方法を示すフローチャートである。 ビットストリームをデコードするための第1の例示的方法を示すフローチャートである。 ビットストリームを生成するための第2の例示的方法を示すフローチャートである。 ビットストリームをデコードするための第2の例示的方法を示すフローチャートである。 ビットストリームを生成するための第3の例示的方法を示すフローチャートである。 ビットストリームをデコードするための第3の例示的方法を示すフローチャートである。 ビットストリーム部分を処理するための第1の例示的方法を示すフローチャートである。 ビットストリーム部分を処理するための第2の例示的方法を示すフローチャートである。 ビットストリームを生成するための第4の例示的方法を示すフローチャートである。 ビットストリームをデコードするための第4の例示的方法を示すフローチャートである。

本詳細な説明は、クリーンランダムアクセス（CRA）ピクチャと他のランダムアクセスポイント（RAP）ピクチャとを有するビットストリームのエンコーディング及びデコーディングのためのイノベーションを提示する。具体的には、本詳細な説明は、ビットストリームがビットストリームの始めにおいてCRAピクチャを有することが可能にされ、さらにビットストリームの始めではないところにおいてCRAピクチャを有することも可能にされる実施形態を説明し、これにおいて、こうしたCRAピクチャのうち任意のものが、1又は複数のデコード不能リーディングピクチャを有することが可能にされる。こうしたCRAピクチャは、本明細書において、「ブロークンリンクアクセス（broken link access）」（BLA）ピクチャと呼ばれることがある。本詳細な説明は、さらに、RAPピクチャのためのユニットタイプの新しい定義とRAPピクチャにおける戦略的制約とがコンテナフォーマットへのビデオ基本ストリームデータのユニットのマッピングを簡素化し、冗長なユニットタイプが除外される実施形態を説明する。

本明細書に説明されるイノベーションのいくつかは、HEVC標準に固有のシンタックス要素とオペレーションとを参照して例示される。例えば、HEVC標準のJCTVC-I1003 - “High efficiency video coding (HEVC) text specification draft 7”、JCTVC-I1003_d5、9^th meeting、Geneva、2012年4月（以降、“JCTVC-I1003_d5”）を含むHEVC標準の特定のドラフトバージョンが参照される。本明細書に説明されるイノベーションは、他の標準又はフォーマットに対して実施することもできる。

より一般的に、本明細書に説明される例に対する様々な代替手段が可能である。例えば、本明細書に説明される方法のうち任意のものを、特定の方法動作を分割し、繰り返し又は省略することなどにより、説明される方法動作の順序付けを変更することによって、変えることができる。開示されるテクノロジーの様々な態様は、組み合わせて又は別個に使用することができる。種々の実施形態が、説明されるイノベーションのうち1又は複数を使用する。本明細書に説明されるイノベーションのいくつかは、背景技術に記された課題のうち1又は複数に対処する。通常、既知の技術／ツールは、すべてのこうした課題を解決しない。

I. 例示的なコンピューティングシステム
図1は、説明されるイノベーションのうちいくつかを実施できる適切なコンピューティングシステム（100）の汎用例を例示する。本イノベーションは、多様な汎用目的又は特別目的のコンピューティングシステムにおいて実施することができ、コンピューティングシステム（100）は、用法又は機能性の範囲に関していかなる制限も示唆するものではない。

図1を参照すると、コンピューティングシステム（100）は、1又は複数のプロセシングユニット（110、115）とメモリ（120、125）とを含む。図1において、この最も基本的な構成（130）は、破線内に含まれる。プロセシングユニット（110、115）は、コンピュータ実行可能命令を実行する。プロセシングユニットは、汎用目的の中央プロセシングユニット（CPU）、特定用途向け集積回路（ASIC）内のプロセッサ又は任意の他のタイプのプロセッサであってよい。マルチプロセシングシステムにおいて、複数のプロセシングユニットがコンピュータ実行可能命令を実行して処理力を増大させる。例えば、図1は、中央プロセシングユニット（110）と、グラフィクスプロセシングユニット又はコプロセシングユニット（115）とを示す。有形メモリ（120、125）は、（1又は複数の）プロセシングユニットがアクセス可能な揮発性メモリ（例えば、レジスタ、キャッシュ、RAM）、不揮発性メモリ（例えば、ROM、EEPROM、フラッシュメモリなど）又はこれら２つの組み合わせであってよい。メモリ（120、125）は、メディアコンテナフォーマットへのマッピングを簡素化するユニットタイプ及び／又は戦略的制約を用いてRAPピクチャをエンコード及びデコードするための1又は複数のイノベーション（セクションV、VI及びVII参照）を実施するソフトウェア（180）を、（1又は複数の）プロセシングユニットによる実行に適したコンピュータ実行可能命令の形式で記憶する。

コンピューティングシステムは、追加の特徴を有してよい。例えば、コンピューティングシステム（100）は、記憶装置（140）と1又は複数の入力装置（150）と1又は複数の出力装置（160）と１又は複数の通信接続（170）とを含む。バス、コントローラ又はネットワークなどの相互接続メカニズム（図示せず）が、コンピューティングシステム（100）のコンポーネントを相互接続する。通常、オペレーティングシステムソフトウェア（図示せず）が、コンピューティングシステム（100）において実行される他のソフトウェアにオペレーティング環境を提供し、コンピューティングシステム（100）のコンポーネントのアクティビティを調整する。

有形記憶装置（140）は、取外し可能又は取外し不能であってよく、磁気ディスク、磁気テープ若しくはカセット、CD-ROM、DVD、又は、非一時的方法で情報を記憶するために使用することができ、かつコンピューティングシステム（100）内でアクセスすることができる任意の他の媒体を含む。記憶装置（140）は、メディアコンテナフォーマットへのマッピングを簡素化するユニットタイプ及び／又は戦略的制約を用いてRAPピクチャをエンコード又はデコードするための1又は複数のイノベーション（セクションV、VI及びVII参照）を実施するソフトウェア（180）のための命令を記憶する。

（1又は複数の）入力装置（150）は、キーボード、マウス、ペン若しくはトラックボールなどのタッチ入力装置、音声入力装置、スキャニング装置、又はコンピューティングシステム（100）に対する入力を提供する別の装置であってよい。ビデオエンコーディングに関して、（1又は複数の）入力装置（150）は、カメラ、ビデオカード、TVチューナカード、若しくはアナログ若しくはデジタル形式でビデオ入力を受け入れる同様の装置、又はコンピューティングシステム（100）にビデオサンプルを読み込むCD-ROM若しくはCD-RWであってよい。（1又は複数の）出力装置（160）は、ディスプレイ、プリンタ、スピーカ、CDライター、又はコンピューティングシステム（100）から出力を提供する別の装置であってよい。

（1又は複数の）通信接続（170）は、別のコンピューティングエンティティに対する通信媒体を介した通信を可能にする。通信媒体は、コンピュータ実行可能命令、オーディオ若しくはビデオの入力若しくは出力、又は他のデータなどの情報を、変調されたデータ信号で伝える。変調されたデータ信号は、その特性のうち1又は複数を、信号内に情報をエンコードする方法で設定又は変更させた信号である。限定ではなく例として、通信媒体は、電気の、光の、RFの又は他の搬送波を使用してよい。

本イノベーションは、コンピュータ読取可能媒体の一般的文脈において説明され得る。コンピュータ読取可能媒体は、コンピューティング環境内でアクセスすることができる任意の利用可能な有形媒体である。限定ではなく例として、コンピューティングシステム（100）を用いると、コンピュータ読取可能媒体は、メモリ（120、125）と記憶装置（140）と上記のうち任意のものの組み合わせとを含む。

本イノベーションは、対象となる実プロセッサ又は仮想プロセッサ上でコンピューティングシステム内で実行される、プログラムモジュールに含まれる命令などの、コンピュータ実行可能命令の一般的文脈において説明され得る。一般に、プログラムモジュールは、特定のタスクを実行し、又は特定の抽象データタイプを実装するルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などを含む。プログラムモジュールの機能性は、様々な実施形態において所望されるとおり、プログラムモジュール間で組み合わせ、あるいは分割することができる。プログラムモジュールのためのコンピュータ実行可能命令は、ローカルの又は分散型のコンピューティングシステム内で実行することができる。

用語「システム」及び「装置」は、本明細書において置き換え可能に使用される。文脈が他の方法で明確に示さない限り、いずれの用語も、コンピューティングシステム又はコンピューティング装置のタイプにおける何らかの限定を示すものではない。概して、コンピューティングシステム又はコンピューティング装置は、ローカルのもの又は分散型のものであってよく、本明細書に説明される機能性を実施するソフトウェアを備えた特別目的のハードウェア及び／又は汎用目的のハードウェアの任意の組み合わせを含んでよい。

開示される方法は、開示される方法のうち任意のものを行うように構成された特化されたコンピューティングハードウェアを用いて実施してもよい。例えば、開示される方法は、開示される方法のうち任意のものを実施するように特別に設計又は構成された集積回路（例えば、特定用途向け集積回路（ASIC）（ASICデジタルシグナルプロセスユニット（DSP）など）、グラフィクスプロセシングユニット（GPU）、又はフィールドプログラマブルゲートアレイ（FPGA）などのプログラマブル論理デバイス（PLD））により実施することができる。

提示を目的として、本詳細な説明は、「決定する」及び「使用する」のような用語を使用してコンピューティングシステムにおけるコンピュータオペレーションを説明する。これらの用語は、コンピュータにより行われるオペレーションのための高レベルの抽象化であり、人間により行われる動作と混同されるべきではない。これらに対応する実際のコンピュータオペレーションは、実装に依存して変化する。

II. 例示的なネットワーク環境
図2a及び図2bは、ビデオエンコーダ（220）とビデオデコーダ（270）とを含む例示的なネットワーク環境（201、202）を示す。エンコーダ（220）とデコーダ（270）とは、適切な通信プロトコルを用いてネットワーク（250）を介して接続される。ネットワーク（250）は、インターネット又は別のコンピュータネットワークを含んでよい。

図2aに示されるネットワーク環境（201）において、各リアルタイム通信（“RTC”）ツール（210）が、双方向通信のため、エンコーダ（220）とデコーダ（270）との双方を含む。所与のエンコーダ（220）は、エンコーダ（220）からエンコードされたデータを受け入れる対応するデコーダ（270）を用いて、SMPTE 421M標準、ISO/IEC 14496-10標準（H.264又はAVCとしても知られる）、HEVC標準、別の標準、又は独自仕様のフォーマットに準拠した出力を作成することができる。双方向通信は、ビデオ会議、ビデオ電話コール又は他の二者通信シナリオの一部であってよい。図2aにおけるネットワーク環境（201）は2つのリアルタイム通信ツール（210）を含むが、ネットワーク環境（201）は、代わって、多者通信に関与する3つ以上のリアルタイム通信ツール（210）を含むことができる。

リアルタイム通信ツール（210）は、エンコーダ（220）によるエンコーディングを管理する。図3は、リアルタイム通信ツール（210）に含むことができる一例示的エンコーダシステム（300）を示す。別法として、リアルタイム通信ツール（210）は、別のエンコーダシステムを使用する。リアルタイム通信ツール（210）は、デコーダ（270）によるデコーディングも管理する。図4は、リアルタイム通信ツール（210）に含むことができる一例示的デコーダシステム（400）を示す。別法として、リアルタイム通信ツール（210）は、別のデコーダシステムを使用する。

図2bに示されるネットワーク環境（202）において、エンコーディングツール（212）はエンコーダ（220）を含み、エンコーダ（220）は、デコーダ（270）を含む複数のプレイバックツールに対する配信のため、ビデオをエンコードする。ビデオ監視システム、ウェブカメラモニタリングシステム、リモートデスクトップ会議開催プレゼンテーション、ビデオ配信システム（例えば、ストリーミングビデオストリーミング配信システム）、又は、ビデオがエンコードされて或る場所から1若しくは複数の他の場所に送信される他のシナリオに対して、単方向通信を提供することができる。図2bにおけるネットワーク環境（202）が2つのプレイバックツール（214）を含むが、ネットワーク環境（202）は、より多くの又はより少ないプレイバックツール（214）を含んでもよい。概して、プレイバックツール（214）は、エンコーディングツール（212）と通信して、プレイバックツール（214）が受信すべきビデオのストリームを決定する。プレイバックツール（214）は、ストリームを受信し、受信したエンコードされたデータを適切な期間にわたりバッファに格納し、デコーディングとプレイバックとを始める。

図3は、エンコーディングツール（212）に含むことができる一例示的エンコーダシステム（300）を示す。別法として、エンコーディングツール（212）は、別のエンコーダシステムを使用する。エンコーディングツール（212）は、1又は複数のプレイバックツール（214）との通信を管理するためのサーバ側コントローラロジックを含むこともできる。図4は、プレイバックツール（214）に含むことができる一例示的デコーダシステム（400）を示す。別法として、プレイバックツール（214）は、別のデコーダシステムを使用する。プレイバックツール（214）は、エンコーディングツール（212）との通信を管理するためのクライアント側コントローラロジックを含むこともできる。

III. 例示的なエンコーダシステム
図3は、一例示的エンコーダシステム（300）のブロック図であり、このエンコーダシステム（300）と連動して、いくつかの説明される実施形態を実施することができる。エンコーダシステム（300）は、リアルタイム通信のための低レイテンシエンコーディングモード、トランスコーディングモード、及びファイル又はストリームからのメディアプレイバックのための通常エンコーディングモードなどの複数のエンコーディングモードのうち任意のものにおいて動作する能力がある汎用目的のエンコーディングツールであってよく、あるいは、1つのこうしたエンコーディングモードのために構成された特別目的のエンコーディングツールであってよい。エンコーダシステム（300）は、オペレーティングシステムモジュールとして、アプリケーションライブラリの一部として、又は標準アプリケーションとして実施することができる。全体として、エンコーダシステム（300）は、ビデオソース（310）からソースビデオフレーム（311）のシーケンスを受信し、エンコードされたデータをチャネル（390）に対する出力として作成する。チャネルに対して出力されるエンコードされたデータは、セクションV、VI及びVIIに説明される戦略的制約及び／又はユニットタイプを有するRAPピクチャのための符号化されたデータを含むことができる。

ビデオソース（310）は、カメラ、チューナカード、記憶媒体又は他のデジタルビデオソースであってよい。ビデオソース（310）は、例えば30フレーム毎秒というフレームレートでビデオフレームのシーケンスを作成する。本明細書において、用語「フレーム」は、概して、情報源の、符号化又は再構成された画像データを示す。プログレッシブビデオに関して、フレームはプログレッシブビデオフレームである。インタレースされたビデオに関して、例示的な実施形態において、インタレースされたビデオフレームはエンコーディングの前にインタレース解除される。別法として、2つの補完的なインタレースされたビデオフィールドが、インタレースされたビデオフレーム又は別個のフィールドとしてエンコードされる。プログレッシブビデオフレームを示すことを除いては、用語「フレーム」は、単一の非ペアのビデオフィールド、補完的なペアのビデオフィールド、所与の時点におけるビデオオブジェクトを表すビデオオブジェクトプレーン、又はより大きな画像の中で関心のある領域を示し得る。ビデオオブジェクトプレーン又は領域は、或るシーンについての複数のオブジェクト又は領域を含むより大きな画像の一部であってよい。

到着ソースフレーム（311）は、複数のフレームバッファ記憶領域（321、322、…、32n）を含むソースフレーム一時メモリ記憶領域（320）に記憶される。1つのフレームバッファ（321、322等）は、ソースフレーム記憶領域（320）内で1つのソースフレームを保持する。ソースフレーム（311）のうち1又は複数がフレームバッファ（321、322等）に記憶された後、フレーム選択部（330）が、ソースフレーム記憶領域（320）から個々のソースフレームを周期的に選択する。フレームがエンコーダ（340）に対する入力のためにフレーム選択部（330）により選択される順序は、フレームがビデオソース（310）により作成される順序と異なってよく、例えば、或るフレームが、時間的に後方の予測を容易にするために、順序において前方にあってよい。エンコーダシステム（300）は、エンコーダ（340）の前に、選択されたフレーム（331）の前処理（例えば、フィルタリング）をエンコーディングの前に行うプリプロセッサ（図示せず）を含んでもよい。

エンコーダ（340）は、選択されたフレーム（331）をエンコードして符号化されたフレーム（341）を作成し、さらにメモリ管理制御オペレーション（MMCO）信号（342）又は参照ピクチャセット（RPS）情報も作成する。現在のフレームがエンコードされる最初のフレームではない場合、そのエンコーディング処理を行うとき、エンコーダ（340）は、デコード済みフレーム一時メモリ記憶領域（360）に記憶された、1又は複数のこれまでにエンコードされた／デコードされたフレーム（369）を使用することができる。こうした記憶されたデコードされたフレーム（369）は、現在のソースフレーム（331）の内容のフレーム間予測のための参照フレームとして使用される。概して、エンコーダ（340）は、動き推定及び補償と周波数変換と量子化及びエントロピー符号化となどのエンコーディングタスクを行う複数のエンコーディングモジュールを含む。エンコーダ（340）により行われる正確なオペレーションは、圧縮フォーマットに依存して変わり得る。出力されるエンコードされたデータのフォーマットは、Windows（登録商標） Media Videoフォーマット、VC-1フォーマット、MPEG-xフォーマット（例えば、MPEG-1、MPEG-2又はMPEG-4)、H.26xフォーマット（例えば、H.261、H.262、H.263、H.264)、HEVCフォーマット又は他のフォーマットであってよい。

例えば、エンコーダ（340）内で、インター符号化された（inter-coded）予測されたフレームが、参照フレームからの予測の観点から表される。動き推定部は、1又は複数の参照フレーム（369）に関して、ソースフレーム（341）のサンプルのマクロブロック、ブロック又は他のセットの動きを推定する。複数の参照フレームが使用されるとき、この複数の参照フレームは、異なる時間方向又は同一の時間方向からのものであってよい。動き推定部は、エントロピー符号化された、動きベクトル情報などの動き情報を出力する。動き補償部は、参照フレームに動きベクトルを適用して、動き補償された予測値を決定する。エンコーダは、ブロックの動き補償された予測値と対応する元の値との間の差分を（もしあれば）決定する。これらの予測残差値は、周波数変換、量子化及びエントロピーエンコーディングを用いてさらにエンコードされる。同様にして、イントラ予測に関して、エンコーダ（340）は、ブロックのためのイントラ予測値を決定し、予測残差値を決定し、この予測残差値をエンコードすることができる。具体的には、エンコーダ（340）のエントロピー符号化部は、量子化された変換係数値と特定の付帯情報（例えば、動きベクトル情報、量子化パラメータ値、モード判断、パラメータ選択）とを圧縮する。典型的なエントロピー符号化手法には、Exp-Golomb符号化、算術符号化、差分符号化、ハフマン符号化、ランレングス符号化、可変長から可変長への（variable-length-to-variable-length；V2V）符号化、可変長から固定長への（variable-length-to-fixed-length；V2F）符号化、LZ符号化、辞書符号化、確率区間分割エントロピー符号化（probability interval partitioning entropy coding；PIPE）及び上記の組み合わせを含む。エントロピー符号化部は、種々の種類の情報に対して種々の符号化手法を使用することができ、特定の符号化手法内の複数の符号テーブルの中から選ぶことができる。

符号化されたフレーム（341）とMMCO/RPS情報（342）とは、デコーディング処理エミュレータ（350）によって処理される。デコーディング処理エミュレータ（350）は、デコーダの機能性のうちいくつか、例えば、動き推定及び補償においてエンコーダ（340）により使用される参照フレームを再構成するデコーディングタスクを実施する。デコーディング処理エミュレータ（350）は、MMCO/RPS情報（342）を使用して、エンコードすべき後続フレームのフレーム間予測において参照フレームとして使うために、所与の符号化されたフレーム（341）を再構成及び記憶する必要があるかどうかを判定する。符号化されたフレーム（341）が記憶される必要があることをMMCO/RPS情報（342）が示す場合、デコーディング処理エミュレータ（350）は、符号化されたフレーム（341）を受信するデコーダにより行われるであろうデコーディング処理をモデル化し、対応するデコードされたフレーム（351）を作成する。こうする場合、エンコーダ（340）が、デコード済みフレーム記憶領域（360）に記憶された（1又は複数の）デコードされたフレーム（369）を使用したとき、デコーディング処理エミュレータ（350）もまた、デコーディング処理の一部として記憶領域（360）から（1又は複数の）デコードされたフレーム（369）を使用する。

デコード済みフレーム一時メモリ記憶領域（360）は、複数のフレームバッファ記憶領域（361、362、…、36n）を含む。デコーディング処理エミュレータ（350）は、エンコーダ（340）がもはや参照フレームとして使用する必要がないフレームを有する任意のバッファ（361、362など）を識別するために、MMCO/RPS情報（342）を使用して記憶領域（360）の内容を管理する。デコーディング処理をモデル化した後、デコーディング処理エミュレータ（350）は、この方法で識別されたフレームバッファ（361、362など）に、新たにデコードされたフレーム（351）を記憶する。

符号化されたフレーム（341）とMMCO/RPS情報（342）ともまた、一時的な符号化済みデータ領域（370）にバッファリングされる。符号化済みデータ領域（370）に集められる、符号化されたデータは、基本の符号化されたビデオビットストリームのシンタックスの一部として、セクションV、VI及びVIIに説明される戦略的制約及び／又はユニットタイプを有するRAPピクチャのための符号化されたデータを包含することができる。符号化済みデータ領域（370）に集められる、符号化されたデータは、符号化されたビデオデータに関連するメディアメタデータも（例えば、1又は複数の補助的拡張情報（SEI）メッセージ又はビデオユーザビリティ情報（VUI）メッセージの中の1又は複数のパラメータとして）含むことができる。

一時的な符号化済みデータ領域（370）から集められたデータ（371）は、チャネルエンコーダ（380）によって処理される。チャネルエンコーダ（380）は、集められたデータを送信のためメディアストリームとして（例えば、ISO/IEC 14496-12などのメディアコンテナフォーマットに従って）パケット化することができ、この場合、チャネルエンコーダ（380）は、シンタックス要素を、メディア送信ストリームのシンタックスの一部として追加することができる。あるいは、チャネルエンコーダ（380）は、集められたデータを記憶のためファイルとして（例えば、ISO/IEC 14496-12などのメディアコンテナフォーマットに従って）統合することができ、この場合、チャネルエンコーダ（380）は、シンタックス要素を、メディア記憶ファイルのシンタックスの一部として追加することができる。あるいは、より一般的に、チャネルエンコーダ（380）は、1又は複数のメディアシステム多重化プロトコル又はトランスポートプロトコルを実施することができ、この場合、チャネルエンコーダ（380）は、シンタックス要素を、（1又は複数の）プロトコルのシンタックスの一部として追加することができる。チャネルエンコーダ（380）は、チャネル（390）に対して出力を行い、チャネル（390）は、出力のための記憶装置、通信接続、又は別のチャネルを表す。

IV. 例示的なデコーダシステム
図4は、一例示的デコーダシステム（400）のブロック図であり、このデコーダシステムと連動していくつかの説明される実施形態を実施することができる。デコーダシステム（400）は、リアルタイム通信のための低レイテンシデコーディングモード、及びファイル又はストリームからのメディアプレイバックのための通常エンコーディングモードなどの複数のデコーディングモードのうち任意のものにおいて動作する能力がある汎用目的のデコーディングツールであってよく、あるいは、1つのこうしたデコーディングモードのために構成された特別目的のデコーディングツールであってよい。デコーダシステム（400）は、オペレーティングシステムモジュールとして、アプリケーションライブラリの一部として、又は標準アプリケーションとして実施することができる。全体として、デコーダシステム（400）は、チャネル（410）から符号化されたデータを受信し、再構成されたフレームを出力宛先（490）に対する出力として作成する。符号化されたデータは、セクションV、VI及びVIIに説明される戦略的制約及び／又はユニットタイプを有するRAPピクチャのための符号化されたデータを含むことができる。

デコーダシステム（400）は、チャネル（410）を含み、チャネル（410）は、符号化されたデータについて、入力として、記憶装置、通信接続又は別のチャネルを表し得る。チャネル（410）は、チャネル符号化された、符号化されたデータをもたらす。チャネルデコーダ（420）は、この符号化されたデータを処理することができる。例えば、チャネルデコーダ（420）は、送信のためメディアストリームとして（例えば、ISO/IEC 14496-12などのメディアコンテナフォーマットに従って）集められたデータをパケット分解し（de-packetizes）、この場合、チャネルデコーダ（420）は、メディア送信ストリームのシンタックスの一部として追加されたシンタックス要素を解析することができる。あるいは、チャネルデコーダ（420）は、記憶のためファイルとして（例えば、ISO/IEC 14496-12などのメディアコンテナフォーマットに従って）集められた符号化されたビデオデータを分け、この場合、チャネルデコーダ（420）は、メディア記憶ファイルのシンタックスの一部として追加されたシンタックス要素を解析することができる。あるいは、より一般的に、チャネルデコーダ（420）は、1又は複数のメディアシステム多重化プロトコル又はトランスポートプロトコルを実施することができ、この場合、チャネルデコーダ（420）は、（1又は複数の）プロトコルのシンタックスの一部として追加されたシンタックス要素を解析することができる。

チャネルデコーダ（420）から出力される符号化されたデータ（421）は、十分な量のこうしたデータが受信されるまで、一時的な符号化済みデータ領域（430）に記憶される。符号化されたデータ（421）は、符号化されたフレーム（431）とMMCO/RPS情報（432）とを含む。符号化済みデータ領域（430）内の符号化されたデータ（421）は、基本の符号化されたビデオビットストリームのシンタックスの一部として、セクションV、VI及びVIIに説明される戦略的制約及び／又はユニットタイプを有するRAPピクチャのための符号化されたデータを包含することができる。符号化済みデータ領域（430）内の符号化されたデータ（421）は、エンコードされたビデオデータに関連するメディアメタデータも（例えば、1又は複数のSEIメッセージ又はVUIメッセージの中の1又は複数のパラメータとして）含むことができる。概して、符号化済みデータ領域（430）は、こうした符号化されたデータ（421）がデコーダ（450）により使用されるまで、符号化されたデータ（421）を一時的に記憶する。その時点で、符号化されたフレーム（431）とMMCO/RPS情報（432）とのための符号化されたデータが、符号化済みデータ領域（430）からデコーダ（450）に転送される。デコーディングが続くにつれ、新しく符号化されたデータが符号化済みデータ領域（430）に追加され、符号化済みデータ領域（430）に残っている最も古い符号化されたデータが、デコーダ（450）に転送される。

デコーダ（450）は、符号化されたフレーム（431）を周期的にデコードして、対応するデコードされたフレーム（451）を作成する。必要に応じて、デコーダ（450）は、そのデコーディング処理を行うとき、フレーム間予測のため参照フレームとして1又は複数のこれまでにデコードされたフレームを使用してよい。デコーダ（450）は、こうしたこれまでにデコードされたフレーム（469）を、デコード済みフレーム一時メモリ記憶領域（460）から読み出す。一般に、デコーダ（450）は、エントロピーデコーディング、逆量子化、逆周波数変換及び動き補償などのデコーディングタスクを行う複数のデコーディングモジュールを含む。デコーダ（450）により行われる正確なオペレーションは、圧縮フォーマットに依存して変わり得る。

例えば、デコーダ（450）は、圧縮されたフレーム又はフレームのシーケンスについてのエンコードされたデータを受信し、デコードされたフレーム（451）を含む出力を作成する。デコーダ（450）において、バッファが、圧縮されたフレームについてのエンコードされたデータを受信し、受信したエンコードされたデータをエントロピーデコーダが利用できるようにする。エントロピーデコーダは、エントロピー符号化された量子化されたデータとエントロピー符号化された付帯情報とを、通常はエンコーダ内で行われたエントロピーエンコーディングの逆を適用して、エントロピーデコードする。セクションV、VI及びVIIは、デコーダ450がデコードすることができるRAPピクチャ、戦略的制約及び／又はユニットタイプのための符号化されたデータの例を説明する。動き補償部は、動き情報を1又は複数の参照フレームに適用して、再構成されているフレームのサブブロック、ブロック及び／又はマクロブロック（概して、ブロック）の動き補償された予測を形成する。イントラ予測モジュールは、現在のブロックのサンプル値を、近隣のこれまでに再構成されたサンプル値から空間的に予測することができる。デコーダ（450）は、予測残差も再構成する。逆量子化部は、エントロピーデコードされたデータを逆量子化する。逆周波数変換部は、量子化された周波数ドメインデータを空間ドメイン情報に変換する。予測されたフレームについて、デコーダ（450）は、再構成された予測残差を、動き補償された予測と組み合わせて、再構成されたフレームを形成する。デコーダ（450）は、同様にして、予測残差を、イントラ予測からの空間的な予測と組み合わせることができる。ビデオデコーダ（450）内の動き補償ループは、デコードされたフレーム（451）内のブロック境界行及び／又は列にわたる不連続性を平滑化するための適応的なデブロッキングフィルタを含む。

デコード済みフレーム一時メモリ記憶領域（460）は、複数のフレームバッファ記憶領域（461、462、…、46n）を含む。デコード済みフレーム記憶領域（460）は、DPBの一例である。デコーダ（450）は、MMCO/RPS情報（432）を使用して、デコードされたフレーム（451）を記憶することができるフレームバッファ（461、462など）を識別する。デコーダ（450）は、デコードされたフレーム（451）を上記フレームバッファ内に記憶する。

出力シーケンサ（480）は、MMCO/RPS情報（432）を使用して、出力順序において作成すべき次フレームがデコード済みフレーム記憶領域（460）内でいつ利用可能になるのかを識別する。出力順序において作成すべき次フレーム（481）がデコード済みフレーム記憶領域（460）内で利用可能になるとき、この次フレーム（481）は、出力シーケンサ（480）により読み出され、出力宛先（490）（例えば、ディスプレイ）に出力される。概して、フレームがデコード済みフレーム記憶領域（460）から出力シーケンサ（480）により出力される順序は、フレームがデコーダ（450）によりデコードされる順序と異なってよい。

V. CRAピクチャを有するビットストリームに対する改良
このセクションは、クリーンランダムアクセス（CRA）ピクチャを有するビットストリームをエンコードする及び／又はデコードするためのいくつかのバリエーションを説明する。特に、このセクションは、CRAピクチャを有するビットストリームが、1又は複数のデコード不能リーディングピクチャを潜在的に有するビットストリーム中間（mid-bitstream）CRAピクチャを有することが可能にされる例を提示する。上記で説明されたエンコーダ又はデコーダのいずれも、開示されるエンコーディング手法及びデコーディング手法を使用するように構成することができる。

JCTVC-I1003_d5によれば、CRAピクチャは、Iスライス（イントラ予測だけを用いてデコードされるスライス）だけを包含する符号化されたピクチャである。さらに、デコーディング順序及び出力順序の双方においてCRAピクチャの後に続くすべての符号化されたピクチャは、デコーディング順序又は出力順序においてCRAピクチャの前に来るいかなるピクチャからもインター予測を使用してはならない。さらに、デコーディング順序においてCRAピクチャの前に来るいかなるピクチャも、出力順序においてCRAピクチャの前に来る。「リーディングピクチャ（leading picture）」は、デコーディング順序においていくつかの他の特定のピクチャの後に続き、出力順序においてその前に来る符号化されたピクチャである。リーディングピクチャがCRAピクチャに関連付けられるとき、このリーディングピクチャは、デコーディング順序においてCRAピクチャの後に続き、しかし出力順序においてCRAピクチャの前に来る符号化されたピクチャとなる。CRAピクチャに関連付けられたリーディングピクチャは、CRAピクチャのピクチャ順序カウントより小さいピクチャ順序カウントを有する。

JCTVC-I1003_d5によれば、「即時デコーディングリフレッシュ（instantaneous decoding refresh）ピクチャ」又は「IDRピクチャ」は、デコーディング処理に、すべての参照ピクチャを「参照に使用されていない」とマーク付けさせる符号化されたピクチャである。デコーディング順序においてIDRピクチャの後に続くすべての符号化されたピクチャは、デコーディング順序においてIDRピクチャの前に来るいかなるピクチャからもインター予測なしにデコードすることができる。デコーディング順序における各々の符号化されたビデオシーケンスの最初のピクチャは、IDRピクチャ又はCRAピクチャである。

図5は、3つのCRAピクチャと双方向に予測されたスライス（“B”ピクチャ）を含む複数のピクチャと単方向に予測されたスライス（“P”ピクチャ）を含む複数のピクチャとを含むひと続きのピクチャを例示するブロック図（500）である。図5内の矢印を使用して、BピクチャとPピクチャとが動き補償を目的としてどのピクチャに依存するかを（例えば、1又は複数の動きベクトルに従って）例示する。図5はさらに、ピクチャの出力順序とデコード順序とを例示する。図5に示されるひと続きの中の第1のCRAピクチャは、デコード順序においてビットストリームの始めにあり、残りの2つのCRAピクチャは、ビットストリームの中間（すなわち、デコード順序においてビットストリームの始めの後）にある。第2のCRAピクチャ（デコード順序において、ピクチャ5）又は第3のCRAピクチャ（デコード順序において、ピクチャ11）について、デコード順序においてCRAピクチャの後に続くが出力順序においてその前に来るリーディングピクチャがいくつか存在する。これらのCRAピクチャの各々について、下記で説明されるとおり、フラグが、CRAピクチャの後に続き得るリーディングピクチャに関する情報を示す。

これまでのHEVCサブミッションJCTVC-H0496によれば、ビットストリームは、IDRピクチャでないCRAピクチャで始まることが許されていた。例えば、図5に示されるひと続きは、CRAピクチャで始まっている。さらに、こうしたCRAピクチャは、デコード不能リーディングピクチャ（ビットストリーム内に実際に存在しない参照ピクチャに対する参照を包含する、デコーディング順序においてCRAピクチャの後に続くが出力／表示順序においてその前に来るピクチャ）を有することが許されていた。JCTVC-H0496によれば、ビットストリームがCRAピクチャで開始される場合、このCRAピクチャに関連付けられたリーディングピクチャは、ビットストリーム内に存在する場合、無視される（ビットストリームから取り除かれ、あるいは破棄される）（図5は、1番目のCRAピクチャの後に上記のようなリーディングピクチャを示しておらず、1番目のCRAピクチャが、デコード順序においてピクチャ1である）。

ビットストリームがIDRピクチャでないCRAピクチャで始まることを可能にすることは、編集の柔軟性を増加させることを目的としている。JCTVC-I1003_d5は、ビットストリームの中間に存在するCRA接合（splice）ポイントが「感知可能（sensible）」であることを要求した。すなわち、JCTVC-I1003_d5は、デコーダが現在のCRAピクチャより早いIDR又はCRAにおいてビットストリームのデコーディングを開始するとき、CRAピクチャのリーディングピクチャのすべてが十分にデコード可能であることを要求した。デコード済みピクチャバッファ（DPB）は、リーディングピクチャのシンタックスにより参照されるピクチャのすべてを包含するように要求された（DPBピクチャセット説明シンタックス内に、又はインター予測のために参照される）。したがって、ビットストリームの開始の後のCRAピクチャがリーディングピクチャを有した場合、このピクチャはデコード可能であると解されていた。例えば、図5において、第3のCRAピクチャ（デコード順序において11番目のピクチャ）は、デコード順序において2つのピクチャ（デコード順序におけるピクチャ12及び13）が後に続き、これら2つのピクチャは、出力順序において第3のCRAピクチャの前に来る。これら2つのリーディングピクチャは、第3のCRAピクチャにのみ依存する。この理由のため、これらは、デコーディングがランダムアクセスポイントとして第3のCRAポイントで開始されるとしてもデコード可能となる。しかしながら、CRAピクチャの配置が、任意のリーディングピクチャがデコード可能であることが保証されるように制約される場合、エンコーダは、ピクチャをCRAピクチャとして指定することができるところに関して厳しく制限される可能性がある。

開示されるテクノロジーの特定の実施形態に従い、CRAピクチャのリーディングピクチャのデコード能力に関する要件が、不必要であり所望されないとして取り除かれる。開示されるテクノロジーの実施形態は、さらに、ビットストリームの始まりにないCRAピクチャが、ストリーム中間のCRAピクチャに関連付けられたリーディングピクチャの存在とタイプとを示す情報をデコーダに提供することを可能にする。以下でより十分に説明されるとおり、こうしたCRAピクチャは、本明細書においてBLAピクチャと呼ばれることがあり、複数のブロークンリンクアクセスピクチャタイプのうち1つを有することができる。したがって、こうした実施形態を用いるエンコーダ又はビデオ処理装置は、図5に例示されるとおり、BLAタイプのCRAピクチャをビットストリーム内により柔軟に配置することができる。図5において、第2のCRAピクチャ（デコード順序において、ピクチャ5）は、デコード順序において2つのリーディングピクチャ（デコード順序において、ピクチャ6及び7）が後に続き、これら2つのリーディングピクチャは、出力順序において第2のCRAピクチャより前に来る（出力順序におけるピクチャ5及び6 対 出力順序におけるピクチャ7）。従前のアプローチでは、ビットストリーム中間CRAピクチャを接合ポイントとして又はランダムアクセスポイントとして使用してスキャン、早送り、巻き戻し又はビットストリーム切り替えオペレーションの一部としてデコーディングを開始することができなかった。なぜならば、第2のCRAの有するリーディングピクチャが、デコーディングにおいてこのCRAピクチャの前の参照ピクチャに対する動き補償依存性を有し、こうした参照ピクチャは、利用可能であることが保証されていなかったからである。図5において、例えば、デコード順序において6番目及び7番目であるリーディングピクチャは、デコード順序において2番目であるピクチャに依存している。しかしながら、開示されるテクノロジーの実施形態を用いて、接合オペレーション又はランダムアクセスオペレーション又はビットストリーム切り替えオペレーションが発生したとき、第2のCRAピクチャは、BLAタイプのピクチャとして（例えば、ピクチャをBLAタイプのCRAピクチャ（本明細書において単に「BLAピクチャ」と呼ばれることがある）として識別したフラグ又はシンタックス要素を用いて）指定されることができる。こうした指標をデコーダが使用して、BLAに関連付けられた任意のデコード不能リーディングピクチャを（例えば、デコード不能リーディングピクチャをデコードしないことによって、デコード不能リーディングピクチャを出力しないことによって、あるいはその他の方法でデコード不能ピクチャを廃棄することによって）適切に処理することができる。さらに、いくつかの実装において、以下でより十分に説明されるとおり、複数のタイプのBLAピクチャを規定することができ、これにより、リーディングピクチャがBLAピクチャに関連し得るかどうかとどのタイプのリーディングピクチャがBLAピクチャに関連し得るかとに関する追加情報をデコーダに提供することができる。これらの複数のBLAタイプは、デコーダが適切にビットストリームをデコードし、デコード可能ピクチャだけを出力することができるように、追加情報を提供する。

特定の実装において、CRAピクチャのためのシンタックス要素は、このCRAピクチャについてのリーディングピクチャがこれらリーディングピクチャのデコードに必要とされる参照ピクチャを欠いている可能性がある点で、「ブロークンリンク」の潜在的な存在を示す。例えば、デコード不能リーディングピクチャが潜在的に存在するかどうかを合図する（signalling）フラグが、CRAピクチャのピクチャレベル情報に追加される。このフラグは、スライスヘッダに、又は確立することができる別のシンタックス箇所（例えば、APSなどの、ピクチャレベル情報のための別の適切な場所）に追加してもよい。1つの特定の実装において、このフラグが“1”に等しいとき、ビットストリームは、前に来る参照ピクチャの欠如に起因してデコード可能でないCRAピクチャのリーディングピクチャを包含することが許される（現在の、ビットストリームを開始するCRAピクチャのリーディングピクチャの場合と同様に）。したがって、デコーディングの間、このフラグは、CRAピクチャに関連付けられたリーディングピクチャ（デコード可能であり得るリーディングピクチャを含む）を無視又は破棄するようにデコーダに合図する。

特定の実装において、“1”に等しいブロークンリンクフラグを有するCRAピクチャは、以下の場合を除き、IDRピクチャと本質的に同様に作用することになる。

CRAピクチャの後に（ビットストリーム順序において）、ビットストリーム内に存在しないピクチャを参照する可能性があるリーディングピクチャが続くことが許されることになる。CRAピクチャのリーディングピクチャは、デコーダによって無視され、破棄されることになる。例えば、デコーダの標準は、デコーダがCRAピクチャのすべてのリーディングピクチャについてデコーディング処理をスキップし、これらを出力しないと規定することになる（既出の、ビットストリームの始めにおけるCRAピクチャの場合のように）。ゆえに、ブロークンリンクフラグは、リーディングピクチャのうち1又は複数が実際はデコード可能であり得るとしても、CRAピクチャに関連付けられたリーディングピクチャが無視され破棄されるべきであるとデコーダに示す。

さらに、CRAのピクチャ順序カウントは、“0”に等しいことを要求されないことになる。代わって、1つの例示的な実装において、ピクチャ順序カウントMSBは、“0”に設定されることになり、LSBは、CRAピクチャ内で送信されるLSB値に設定されることになる（ビットストリームの始めにおいてCRAピクチャについて既に規定されたとおり）。さらに、いくつかの実装において、IDRピクチャのピクチャ順序カウントは、非ゼロであることが許される。換言すると、IDRピクチャのピクチャ順序カウントは、“0”に等しくなることが要求されない。

特定の実装において、“1”に等しいブロークンリンクフラグ（例えば、broken_link_flag）を有するCRAピクチャは、IDRピクチャの場合と同様に作用するno_output_of_prior_pics_flagと、IDRピクチャのidr_pic_idと同様に作用するrandom_access_pic_idとをさらに包含する。いくつかの実装において、現在のidr_pic_idは、random_access_pic_idに名前を変更され、その制約は、単にIDRピクチャだけにではなく、CRAピクチャとIDRピクチャとの双方に適用される。さらに、IDRピクチャと同様に、“1”に等しいブロークンリンクフラグを有するCRAピクチャは、異なるSPSを有効にし、ピクチャサイズを変更することなどができる。

この実装において、ブロークンリンクフラグの値がCRAピクチャについて“0”であるとき、ビットストリームは、このCRAピクチャが（デコード順序において）ビットストリーム内の最初のピクチャでない限り、前に来る参照ピクチャの欠如に起因してデコード可能でない可能性があるこのCRAピクチャのリーディングピクチャを包含することが許されない。すなわち、ビットストリームは、デコーディングがデコード順序においてより早いCRA又はIDRピクチャで開始されるときにリーディングピクチャが十分にデコード可能でない限り、デコード順序において“0”のブロークンリンクフラグを有するCRAピクチャの後にこうしたリーディングピクチャを包含しない。このようにして、デコーディングの間、フラグは、CRAピクチャに関連付けられたリーディングピクチャをデコードするようにデコーダに合図する。しかしながら、CRAピクチャがビットストリーム内の最初のピクチャであり、“0”のブロークンリンクフラグを有するとき、フラグは無視されることができ、CRAピクチャはブロークンリンクフラグが“1”であるかの「ように」処理されることができる。

図5に示される例において、第2のCRAピクチャ（デコード順序において、ピクチャ5）について、フラグの値は、いくつかのリーディングピクチャがランダムアクセスにおいて参照ピクチャを欠いている可能性があるため、“1”であり得る。これは、図5内の第2のCRAピクチャがこれまでに可能であったよりも高いランダムアクセス機能性のために使用されることを可能にする。例えば、第2のCRAピクチャは、今度は、開始ピクチャとして、スキャン、早送り、巻き戻しオペレーション又はビットストリーム切り替えオペレーションの一部として使用することができる。さらに、第2のCRAピクチャは、ビットストリームが第2のピクチャで始まるように切り出され、それから別のビットストリームの終端に付加されるところの接合ポイントとして使用することができる。第2のCRAピクチャはBLAピクチャ（“1”のブロークンリンクフラグ値）として識別されるため、結果的に生じるビットストリームは適切にデコードすることができ、有効なビットストリームを表す。さらに、特定の実装において、ビデオエンコーダ又はビデオ処理装置は、BLAピクチャになるようにCRAピクチャのステータスを変えることができる。例えば、接合オペレーションの一部として、ビデオ処理装置は、結果的に生じる接合されたビットストリームが有効になるように、CRAピクチャの指定を、それがBLAピクチャであると示すように変更することができる。第3のCRAピクチャ（デコード順序において、ピクチャ11）について、ランダムアクセスにおいて参照ピクチャを欠くことになるリーディングピクチャがないため、フラグの値は“0”になる。

上述された実施形態は、デコーダがCRAピクチャに関連付けられたデコード不能リーディングピクチャをスキップすべきかどうかを合図する「フラグ」に言及したが、任意の適切なインジケータが使用されてよい。例えば、いくつかの実装において、ピクチャの様々な特性を規定する別のピクチャレベルのインジケータ又はシンタックス要素が使用される。いくつかの実装において、この目的のために使用されるシンタックス要素は、所与のCRAピクチャに関連付けられたネットワーク抽象化レイヤ（“NAL”）ユニットタイプとして知られるシンタックスインジケータ（又は、ビットストリーム内のピクチャに関連付けられた他のインジケータ）であってよい。例えば、1つのNALユニットタイプ値が、潜在的な「ブロークンリンク」ステータスを有すると示されるCRAピクチャに使用されてよく、別のNALユニットタイプ値が、こうした潜在的な「ブロークンリンク」ステータスを有さないと示されるCRAピクチャに使用されてよい。さらに、上述された実施形態は「クリーン」ランダムアクセスピクチャに言及しているが、本明細書に開示されるイノベーションは、任意のランダムアクセスピクチャ又は同等のもの（回復フレーム、又はビットストリームを始めるのに使用される可能性がある他のピクチャなど）と関連して使用されてよい。さらに、代替的なこうした実施形態において、インジケータを使用して、任意のタイプの関連するデコード不能ピクチャの確率（時間的な出力順序に基づいて識別されるリーディングピクチャだけでなく、例えば、何らかの他の方法で識別されるリーディングピクチャを含む）を合図することができる。

上述された実施形態は、ピクチャがCRAピクチャのリーディングピクチャであるか否かの判定によって（すなわち、デコーディング順序においてCRAピクチャの後に続くピクチャが出力順序においてその前に来るかどうかを識別することによって）、潜在的にデコード不能なピクチャを識別することに言及しているが、他の又は追加の分類ルール又はインジケータが潜在的にデコード不能なピクチャを識別するために使用されてよい。例えば、「フラグ」若しくはシンタックス要素値又はビットストリーム内のピクチャに関連付けられた他のインジケータが各ピクチャと共に送信されて、関連するCRAピクチャの出力順序位置に対する各ピクチャの出力順序位置にかかわらず、各ピクチャが潜在的にデコード不能なピクチャであるのか否かを示すことができる。換言すると、インジケータは、潜在的にデコード不能であるピクチャについて合図される。いくつかの実装において、この目的のために使用されるシンタックス要素は、NALユニットタイプとして知られるシンタックスインジケータであってよい。例えば、CRAピクチャでないと示されるピクチャについて、ランダムアクセスデコーディング処理がCRAピクチャの場所で始まるとき、あるいは「ブロークンリンク」CRAピクチャが示されるときに、1つのNALユニットタイプ値が、潜在的にデコード不能なピクチャとして破棄されるべきピクチャにより使用されてよく、別のNALユニットタイプ値が、デコード可能であると示されるピクチャにより使用されてよい。潜在的にデコード不能なピクチャとして破棄されるべきリーディングピクチャは、破棄用タグ付き（tagged-for-discard；TFD）ピクチャ又はランダムアクセススキップトリーディング（random access skipped leading；RASL）ピクチャと本明細書において呼ばれることがある（あるいは、ビットストリーム内で示されることがある）。デコード可能であるリーディングピクチャは、ランダムアクセスデコード可能リーディング（random access decodable leading；RADL）ピクチャ（又は、デコード可能リーディングピクチャ（decodable leading picture；DLP））と呼ばれることがある（あるいは、ビットストリーム内で示されることがある）。

いくつかの実施形態において、ピクチャをデコードすることができるか否かの判定は、ピクチャのデコーディング処理が、ビットストリーム順序において1つのCRAピクチャの前に現れるいくつかのピクチャに依存し得るかどうかの識別を含むことができるだけでなく、ピクチャのデコーディング処理が、ビットストリーム順序において2つ以上のCRAピクチャの前に現れるいくつかのピクチャに依存し得るかどうかの識別を含むこともできる。この判定は、有用であり得る。というのは、例えば、通常、デコーダは、ランダムアクセスデコーディング処理が開始された後に直面する2つ以上のCRAピクチャの後に続くピクチャをデコードすることができるかどうかを識別できる必要があるからである。こうしたシナリオにおいて、参照ピクチャ選択を下記のとおり制約することは有用であり得る ‐ ピクチャは、ビットストリーム内の、デコーディング順序においてx個より多くのCRAピクチャの前に来るいかなるピクチャも、ピクチャ間予測のための参照として使用してはならない。例えば、xは2である。こうした制約なしに、複数のCRAピクチャに直面した後でさえ、デコーダがランダムアクセスを行うとき、回復が保証されてよい。

多くの点において、いくつかの環境下で破棄されるべきピクチャが明示的に示される場合、IDRピクチャの使用は不要である。IDRピクチャの後に、ビットストリーム順序において、リーディングピクチャ（出力順序において）が続くことができ、このリーディングピクチャは、デコーダがランダムアクセスを行うとき、デコードされ出力されることになる。ピクチャがデコードされるべきか否かの分類が、ピクチャ順序カウントにより暗に判定されるのではなく、明示的なシンタックスインジケータ（NALユニットタイプなど）により判定される場合、CRAピクチャは、IDRピクチャのすべての機能性を有することができる。例えば、特定の具体的な実装において、ビットストリーム内のピクチャに関連付けられるシンタックス要素値又は他のインジケータ（NALユニットタイプ値など）を使用して、少なくとも下記の4タイプのピクチャを識別することができる：
・ピクチャを、「ブロークンリンク」なしのCRAピクチャであると識別するタイプ、
・ピクチャを、「ブロークンリンク」ありのCRAピクチャであると識別するタイプ、
・ピクチャを、デコーディング処理がビットストリーム順序において任意の先行するCRAピクチャの場所で始まるときに常にデコードすべきピクチャであると識別するタイプ、
・ピクチャを、ランダムアクセスがビットストリーム順序において先行するCRAピクチャのランダムアクセスポイントで行われたとき、あるいはビットストリーム順序において先行するCRAピクチャが「ブロークンリンク」として示されるときに、デコードすべきでないピクチャであると識別するタイプ。

VI. RAPピクチャのための戦略的制約及びユニットタイプ
HEVCドラフトJCTVC-I1003_d5において、RAP（「ランダムアクセスポイント」）ピクチャは、NALユニットタイプ4乃至8により表される。RAPピクチャの特性に依存して、いくつかのタイプのメディアコンテナフォーマットについて、ユニットタイプは、下記に説明される3つのSAP（「ストリームアクセスポイント」）タイプのうち1つにマップすることができ、このSAPタイプは、ISO/IEC 14496-12 4^th Edition、“Information technology − Coding of audio-visual objects − Part 12：ISO base media file format”、w12640、100^th MPEG meeting、Geneva、2012年4月にも定義されている。合計6つのSAPタイプが定義されているが、RAPピクチャは上記文献のSAPタイプのうち3つにのみマップすることができる。利用可能なSAPタイプには、タイプ1、タイプ2及びタイプ3を含む。

タイプ1は、「クローズドGOPランダムアクセスポイント」の数例に対応し（この場合、デコーディング順序において、ポイントI_SAPから開始されるすべてのアクセスユニットは正しくデコードすることができ、ギャップのない、正しくデコードされたアクセスユニットの連続的な時間シーケンスをもたらす）、これら数例について、デコーディング順序におけるアクセスユニットは、提示順序における最初のアクセスユニットでもある。

タイプ2は、「クローズドGOPランダムアクセスポイント」の他の例に対応し、これら例について、ポイントI_SAUから開始されるメディアストリーム内のデコーディング順序における最初のアクセスユニットは、提示順序における最初のアクセスユニットではない。

タイプ3は、「オープンGOPランダムアクセスポイント」の例に対応し、この場合、正しくデコードされない可能性があって、提示時刻が時刻T_SAPより小さく、デコーディング順序においてポイントI_SAUの後に続くいくつかのアクセスユニットが存在する。

システム視点から、可能なかぎり多くのタイプの使用を可能にしながら、可能なかぎりSAPマッピングを簡素化することが望ましい。開示されるテクノロジーのいくつかの実施形態において、RAPピクチャは、許容されるユニットタイプに対する下記の制約及び調整のうち1又は複数を含む。

下記の例において、RAPピクチャはさらに、NALユニットタイプに依存して、CRAピクチャ、BLA（「ブロークンリンクアクセス」）ピクチャ又はIDRピクチャに分類することができる。JCTVC-11003_d5のHEVCデザインにおいて、CRAピクチャは、NALユニットタイプ4及び5により表され、BLAピクチャは、NALユニットタイプ6及び7により表され、IDRピクチャは、NALユニットタイプ8により表される。NALユニットタイプ5及び7は、それぞれ、CRAピクチャとBLAピクチャとがいかなる関連するTFD（「破棄用タグ付き」）ピクチャも有さない場合に限りCRAピクチャとBLAピクチャとに対してのみ使用することができる。

A. IDRピクチャの除去又はIDRピクチャにおける制約
上記セクションVに開示された実施形態のいくつかと一致し、BLAピクチャのコンセプトは、提案JCTVC-I0404（G.J.Sullivan、“CRA pictures with broken links”、JCTVC-I0404、9^th meeting、Geneva、2012年4月）からJCTVC-I1003_d5のHEVCデザインに採用されている。上記提案は、CRA/BLAピクチャがIDRピクチャの機能性（及び、それ以上）を達成できることを指摘し、ゆえにIDRピクチャのコンセプトはHEVCデザインから落とされるべきであると推奨したが、IDRピクチャは、JCTVC-I1003_d5のHEVCデザインに残った。

開示されるテクノロジーの特定の実施形態において、IDRピクチャはなお使用されているが、エンコーディングは、IDRピクチャのSAPタイプについてのマッピングを簡素化するさらなる制約に従う。

JCTVC-I1003のHEVCデザインにおいて、IDRピクチャは、SAPタイプ1又は2にマップすることができる。IDRピクチャが、リーディングピクチャ（デコーディング順序において現在のピクチャの後に続くが出力順序においてその前に来る符号化された（及びデコード可能な）ピクチャ）を有する場合、このIDRピクチャは、SAPタイプ2にマップされることになる。IDRピクチャがリーディングピクチャを有さない場合、このIDRピクチャは、SAPタイプ1にマップされることになる。ゆえに、システムがIDRピクチャに直面するとき、システムは、SAPタイプについての正しいマッピングを決定するためにリーディングピクチャが存在するか否かをチェックしなければならず、このことは、まれなケースをチェックするために計算リソース及び記憶リソースを不必要に消費させる可能性がある。

開示されるテクノロジーの1つの例示的な実施形態に従い、IDRピクチャは、リーディングピクチャを有さないように制約される。この制約を備えると、IDRピクチャは、常に、SAPのタイプ1にマップされる。

B. CRA/BLAピクチャのためのNALユニットタイプ
開示されるテクノロジーの特定の実装において、TFDピクチャが存在しないとき、CRAピクチャの機能性はBLAピクチャの機能性と同一になる。ゆえに、この目的のために2つのNALユニットタイプを定義する必要性は回避することができ、単一のタイプ値が、関連するTFDピクチャを有さないCRAピクチャ又はBLAピクチャを示すことができる。

その上、関連するTFDピクチャを有さないCRA/BLAピクチャは、それ自体がリーディングピクチャを有するか否かに依存して、SAPタイプ1又は2にマップすることができる。特定の実装において、冗長なNALユニットタイプのうち1つを使用して、CRA/BLAピクチャがSAPタイプ1に直接マップする場合を示すことができる（これは、CRA/BLAピクチャがリーディングピクチャを有さないときに生じる）。このことは、リーディングピクチャを有さないCRA/BLAの一般的ケースについて、適切なSAPタイプへのマッピングを簡素化する。

1つの具体的な例示的な実装が、下記表1に定義されるNALユニットタイプ（この例において、NALユニットタイプは4乃至7）を含む。

別の具体的な例示的な実装が、下記に定義されるとおりNALユニットタイプ（この例において、NALユニットタイプは16乃至21）を含む。この例において、TFDリーディングピクチャは、ランダムアクセススキップトリーディング（「RASL」）ピクチャと呼ばれる。特定の実装において、すべてのRASLピクチャは、関連するBLAピクチャ又はCRAピクチャのリーディングピクチャである。関連するRAPピクチャがBLAピクチャである、あるいはビットストリーム内の最初の符号化されたピクチャであるとき、RASLピクチャはビットストリーム内に存在しないピクチャに対する参照を含む可能性があるため、RASLピクチャは出力されず、正しくデコード可能でない可能性がある。さらに、RASLピクチャは、非RASLピクチャのデコーディング処理のための参照ピクチャとして使用されない。特定の例示的な実装において、RASLピクチャが存在する場合、すべてのRASLピクチャは、デコーディング順序において、同一の関連するRAPピクチャのすべてのトレイリングピクチャ（trailing pictures）の前に来る。さらに、下記の例において、デコード可能リーディングピクチャは、ランダムアクセスデコード可能リーディング（RADL）ピクチャと呼ばれる。特定の実装において、すべてのRADLピクチャはリーディングピクチャであり、RADLピクチャは、同一の関連するRAPピクチャのトレイリングピクチャのデコーディング処理のための参照ピクチャとして使用されない。特定の例示的な実装において、RADLピクチャが存在する場合、すべてのRADLピクチャは、デコーディング順序において、同一の関連するRAPピクチャのすべてのトレイリングピクチャの前に来る。さらに、特定の実装において、BLAピクチャは、（a）Iスライスのみを包含し、デコーディング順序においてビットストリーム内の最初のピクチャであってよく、あるいはビットストリーム内で後で表れてよく、（b）新しい符号化されたビデオシーケンスを始め、デコーディング処理においてIDRピクチャと同じ効果を有し、（c）空でない参照ピクチャセットを規定するシンタックス要素を包含する。

別法として、他のタイプ値が、RAPにおける上記制約とピクチャのタイプの許容される組み合わせとのうち1又は複数に一致するビデオ基本ビットストリームデータ（例えば、他のNALユニットタイプ値、又は他のビデオタイプ値）及び／又はメディアコンテナフォーマットデータ（例えば、他のSAPタイプ値又は他のコンテナフォーマット値）に対して使用される。

C. リーディングピクチャのビットストリーム順序における制約
エンコーディングシステムがRAPピクチャをとり得るSAPタイプのうち1つにマップするとき、エンコーディングシステムは、リーディングピクチャの存在をチェックし、もし存在する場合、ピクチャのいずれかがTFDピクチャであるかどうかをチェックする。JCTVC-I1003_d5のHEVCデザイン内のピクチャ間依存性における制約に従い、現在のRAPピクチャのリーディングピクチャは、現在のRAPピクチャとその次のRAPピクチャとの後、ビットストリーム内のどこに存在してもよい。リーディングピクチャを検索する範囲は、潜在的に非常に長くなる。

この検索をより簡素にするために、開示されるテクノロジーの特定の実装に従い、RAPピクチャについて、ビットストリーム内のすべてのリーディングピクチャ（すなわち、デコーディング順序）がいかなる非リーディングピクチャよりも前に出現することを保証するように、制約が存在する。すなわち、所与のRAPピクチャについて、ビットストリームは、このRAPピクチャについてのすべてのリーディングピクチャがビットストリーム内で（すなわち、デコーディング順序において）このRAPピクチャについてのいかなる非リーディングピクチャよりも前に生じるように制約される。

VII. 開示されるテクノロジーの態様を実施するための一般的実施形態
図6〜図11は、開示されるテクノロジーに従う例示的な実施形態を示すフローチャートである。図6〜図11に示される方法は、上記及び下記に開示される具体的な態様のうち任意の1又は複数を含み得る。さらに、図6〜図11に示される方法は、その中に示される方法動作のうち任意の1又は複数を単体で、又は互いの様々な組み合わせ若しくは部分的組み合わせで使用することができるため、限定的と見なされるべきではない。さらに、方法動作のシーケンスは、いくつかの場合、再配置することができ、あるいは少なくとも部分的に同時に行うことができる。さらに、上記で述べられたとおり、図6〜図11に開示される方法は、コンピュータ読取可能記憶媒体に記憶されたコンピュータ実行可能命令として（この場合、上記記憶媒体は伝搬波を含まない）、又はデジタルメディア処理システムによって実施することができる。

図6は、エンコーダ又はデジタルメディア処理ツール若しくは装置が行うことができる一例示的方法600である。

610において、ピクチャ（例えば、ビデオシーケンス内のピクチャのグループからのピクチャ）が、複数のピクチャタイプのうちの1つであるとして指定される。特定の実施形態において、ピクチャタイプは、下記の（1）ピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、ピクチャがいかなる関連するデコード不能リーディングピクチャも有さないが1又は複数の関連するデコード可能リーディングピクチャを有し得ることをさらに示すタイプ、（2）ピクチャがRAPピクチャとして使用できるBLAピクチャであることを示し、ピクチャがいかなる関連するリーディングピクチャも有さないことをさらに示すタイプ、（3）ピクチャがRAPピクチャとして使用できるBLAピクチャであることを示し、ピクチャが1又は複数の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示すタイプ、（4）エンコードされたピクチャが関連するRADLピクチャを有し得る即時デコーディングリフレッシュ（IDR）ピクチャであることを示すタイプ、（5）エンコードされたピクチャがいかなる関連するリーディングピクチャも有さないIDRであることを示すタイプ、及び／又は（6）エンコードされたピクチャがRAPピクチャとして使用できるクリーンランダムアクセス（CRA）ピクチャであることを示すタイプのうち、任意の1又は複数を含む。

上記で述べられたとおり、タイプのうち1又は複数は、ピクチャがBLAピクチャであることを示す。特定の実施形態において、BLAピクチャは、Iスライスのみを包含し、デコーディング順序においてビットストリーム内の最初のピクチャであってよく、あるいはビットストリーム内で後で表れてよい。さらに、これらの実施形態において、BLAピクチャは、新しい符号化されたビデオシーケンスを始め、デコーディング処理においてIDRピクチャと同じ効果を有する。しかしながら、BLAピクチャは、空でない参照ピクチャセットを規定するシンタックス要素を包含する（デコーディングの間、無視することができる）。

いくつかの実施形態において、上記で述べられた第1のBLAタイプは、BLAピクチャが、関連するランダムアクセススキップトリーディング（RASL）ピクチャを有さないが、デコードすべきであると規定された関連するランダムアクセスデコード可能リーディング（RADL）ピクチャを有し得ること示す（例えば、NALユニットタイプを使用して、リーディングピクチャをRASLピクチャ又はRADLピクチャとして規定することができる）。特定の実装において、すべてのRASLピクチャは、関連するBLAピクチャ又はCRAピクチャのリーディングピクチャである。関連するRAPピクチャがBLAピクチャであり、あるいはビットストリーム内の最初の符号化されたピクチャであるとき、RASLピクチャがビットストリーム内に存在しないピクチャに対する参照を包含する可能性があるため、RASLピクチャは正しくデコード可能でない可能性があり、デコーダにより出力されない。RASLピクチャは、非RASLピクチャのデコーディング処理のための参照ピクチャとして使用されない。さらに、特定の実装において、RASLピクチャが存在する場合、すべてのRASLピクチャは、デコーディング順序において、同一の関連するRAPピクチャのすべてのトレイリングピクチャの前に来る。さらに、いくつかの実装において、すべてのRADLピクチャがリーディングピクチャである。RADLピクチャは、同一の関連するRAPピクチャのトレイリングピクチャのデコーディング処理のための参照ピクチャとして使用されない。さらに、特定の実装において、RADLピクチャが存在する場合、すべてのRADLピクチャは、デコーディング順序において、同一の関連するRAPピクチャのすべてのトレイリングピクチャの前に来る。このタイプは様々な名前を有することができるが、1つの特定の実装においてこのタイプは「BLA_W_DLP」と名付けられる。

いくつかの実施形態において、上記で述べられた第2のBLAタイプは、BLAピクチャがいかなる関連するリーディングピクチャも有さないことを示す。このタイプは様々な名前を有することができるが、1つの特定の実装において、このタイプは「BLA_N_LP」と名付けられる。

特定の実施形態において、上記で述べられた第3のBLAタイプは、RASLピクチャがビットストリーム内に存在しないピクチャに対する参照を包含する可能性があるため、BLAピクチャが、デコード可能でない可能性があってデコーダにより出力されない関連するRASLピクチャを有し得ることを示す。このタイプは、BLAピクチャが、デコードすべきであると規定された関連するRADLピクチャも有し得ることをさらに示す。このタイプは様々な名前を有することができるが、1つの特定の実装においてこのタイプは「BLA_W_LP」と名付けられる。

いくつかの実施形態において、上記で述べられた第4のタイプは、ピクチャが、現在ビットストリーム内に関連するRASLピクチャを有さないがビットストリーム内に関連するRADLピクチャを有し得るIDRピクチャであることを示す。特定の実装において、IDRピクチャは、Iスライスのみを包含し、デコーディング順序においてビットストリーム内で最初のピクチャであってよく、あるいはビットストリーム内で後に表れてよい。各IDRピクチャは、デコーディング順序において、符号化されたビデオシーケンスの最初のピクチャである。IDRピクチャは、関連するRASLピクチャを有さない。このタイプは様々な名前を有することができるが、1つの特定の実装においてこのタイプは「IDR_W_DLP」と名付けられる。

特定の実施形態において、上記で述べられた第5のタイプは、ピクチャがいかなる関連するリーディングピクチャも有さないIDRピクチャであることを示す。このタイプは様々な名前を有することができるが、1つの特定の実装においてこのタイプは「IDR_N_LP」と名付けられる。

いくつかの実施形態において、上記で述べられた第6のタイプは、ピクチャがCRAピクチャであることを示す。特定の実装において、CRAピクチャは、Iスライスのみを包含し、デコーディング順序においてビットストリーム内で最初のピクチャであってよく、あるいはビットストリーム内で後に表れてよい。さらに、CRAピクチャは、関連するRADLピクチャ又はRASLピクチャを有し得る。CRAピクチャがデコーディング順序においてビットストリーム内で最初のピクチャであるとき、このCRAピクチャは、デコーディング順序において、符号化されたビデオシーケンスの最初のピクチャであり、RASLピクチャがビットストリーム内に存在しないピクチャに対する参照を包含し得るため、いかなる関連するRASLピクチャもデコード可能でない可能性があり、デコーダにより出力されない。このタイプは様々な名前を有することができるが、1つの特定の実装において、このタイプは「CRA_NUT」と名付けられる。

612において、ビットストリームの少なくとも一部が生成される。例示されている実施形態において、ビットストリームのこの少なくとも一部には、ピクチャのために指定されたピクチャタイプを含む（例えば、NALユニットタイプなどのシンタックス要素としてなど）。

特定の実装において、方法600はエンコーダにより行われ、該方法はピクチャをエンコードすることをさらに含む。ビットストリームは、このエンコードされたピクチャをさらに含むことができる。様々なエンコーディング手法が使用されてよい。例えば、上記で説明されたエンコーディング手法のうち任意のものが使用されてよい。特定の実施形態において、BLAピクチャとして指定されたエンコードされたピクチャは、ビットストリームの最初のピクチャではない。

いくつかの実施形態において、上記方法は、エンコードされたピクチャに関連する1又は複数のリーディングピクチャと非リーディングピクチャとをエンコードすることをさらに含む。こうした実施形態において、ビットストリームの上記少なくとも部分を生成する動作は、ビットストリームの少なくとも部分の中ですべてのエンコードされたリーディングピクチャがすべてのエンコードされた非リーディングピクチャの前に来るように、エンコードされたリーディングピクチャとエンコードされた非リーディングピクチャとを順序付けることをさらに含むことができる。リーディングピクチャは、（例えば、NALユニットタイプ値を用いて、）RADLピクチャ又はRASLピクチャのいずれかとして指定されることもできる。

図7は、デコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法700である。概して、方法700を行って、例えば図6の方法600から生成されたビットストリームをデコードすることができる。

710において、ビットストリームの少なくとも一部が受信される（例えば、さらなる処理のため、バッファリングされ、アクセスされ、ロードされ、あるいはその他の方法で準備される）。例示されている実施形態において、ビットストリームの少なくとも一部は、エンコードされたピクチャと、このエンコードされたピクチャのために指定されたピクチャタイプとを含む。ピクチャタイプは、複数のピクチャタイプのうち1つから選択される。特定の実施形態において、この複数のピクチャタイプには、下記の（1）エンコードされたピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、エンコードされたピクチャがいかなる関連するデコード不能リーディングピクチャも有さないが1又は複数の関連するデコード可能リーディングピクチャを有し得ることをさらに示すタイプ、（2）エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることを示し、エンコードされたピクチャがいかなる関連するリーディングピクチャも有さないことをさらに示すタイプ、（3）エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることを示し、エンコードされたピクチャが1又は複数の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示すタイプ、（4）エンコードされたピクチャが関連するRADLピクチャを有し得る即時デコーディングリフレッシュ（IDR）ピクチャであることを示すタイプ、（5）エンコードされたピクチャがいかなる関連するリーディングピクチャも有さないIDRであることを示すタイプ、及び／又は（6）エンコードされたピクチャがRAPピクチャとして使用できるクリーンランダムアクセス（CRA）ピクチャであることを示すタイプのうち、1又は複数を含む。ピクチャタイプについての例示的な実装に関するさらなる詳細は、図6に関して上記で説明されている。

712において、エンコードされたピクチャがデコードされる。様々なデコーディング手法が使用されてよい。例えば、上記で説明されたデコーディング手法のうち任意のものが使用されてよい。

特定の実施形態において、エンコードされたピクチャは、ビットストリームの最初のピクチャではない。いくつかの実施形態において、上記方法は、710のエンコードされたピクチャに関連する1又は複数のリーディングピクチャと710のエンコードされたピクチャに関連する1又は複数の非リーディングピクチャとをデコードすることをさらに含む。こうした実施形態において、ビットストリームの少なくとも部分は、最初のピクチャに関連するすべてのエンコードされたリーディングピクチャが最初のピクチャに関連するすべてのエンコードされた非リーディングピクチャの前に来るように、順序付けされることができる。さらに、リーディングピクチャは、（例えば、NALユニットタイプ値を用いて、）RADLピクチャ又はRASLピクチャのいずれかとして指定されることができる。

図8は、エンコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法800である。

810において、ビットストリームの少なくとも部分が生成される。例示されている実施形態において、ビットストリームは、ビットストリームの最初のピクチャではないランダムアクセスポイントピクチャをビットストリーム自体が含むように（例えば、ランダムアクセスポイントピクチャが、ビットストリームの最初のピクチャの後のピクチャ順序位置に存在する）、かつランダムアクセスポイントピクチャが1又は複数の関連するデコード不能リーディングピクチャを有するように、生成される。さらに、例示されている実施形態において、ビットストリームは、デコーダのための指標を含むように生成され、この指標は、ランダムアクセスポイントピクチャが、デコーダがデコーディングを始めることができるところのピクチャであることを合図する。

特定の実施形態において、上記指標はさらなる情報を含む。例えば、指標は、RAPピクチャがいくらかの関連するリーディングピクチャを有するか否かと、エンコードされたピクチャがいくらかの関連するリーディングピクチャを有する場合、すべての関連するリーディングピクチャがデコード可能であるか否かとを、さらに示すことができる。指標は、様々なフォーマットを有することができる。例えば、1つの実装において、指標はシンタックス要素である（例えば、表2に示されたとおりのNALユニットタイプなど）。いくつかの実装において、ビットストリームの少なくとも部分は、エンコードされたピクチャのための1又は複数のリーディングピクチャとエンコードされたピクチャのための1又は複数の非リーディングピクチャとをさらに含む。こうした実装において、ビットストリームの少なくとも部分を生成する動作は、すべてのリーディングピクチャが非リーディングピクチャの前に来るように、エンコードされたピクチャのためのリーディングピクチャとエンコードされたピクチャのための非リーディングピクチャとを順序付けることを含むことができる。

812において、ビットストリームの少なくとも部分が、（例えば、コンピュータ読取可能記憶媒体に記憶すること、ファイルに書き込むこと、又は他のこうした形式の出力によって）出力される。

図9は、デコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法900である。

910において、ビットストリームの少なくとも部分が受信される。例示されている実施形態において、ビットストリームの少なくとも部分は、ビットストリームの最初のピクチャの後のピクチャ順序位置にランダムアクセスポイントピクチャを含む。さらに、ビットストリームの少なくとも部分は、ランダムアクセスポイントピクチャに関連する1又は複数のデコード不能リーディングピクチャを含む。ビットストリームの少なくとも部分は、ランダムアクセスポイントピクチャがいくらかの関連するリーディングピクチャを有するか否かの指標と、ランダムアクセスポイントピクチャがいくらかの関連するリーディングピクチャを有する場合、すべての関連するリーディングピクチャがデコード可能であるかどうかの指標とを、さらに含むことができる。指標は、様々なフォーマットを有することができる。例えば、1つの実装において、指標は、ランダムアクセスポイントピクチャがいくらかの関連するリーディングピクチャを有するか否かを合図するシンタックス要素であり（例えば、表2に示されたとおりのNALユニットタイプなど）、ランダムアクセスポイントピクチャがいくらかの関連するリーディングピクチャを有する場合、すべての関連するリーディングピクチャがデコード可能であるかどうかの指標である。

912において、ランダムアクセスポイントピクチャはデコードされる。

図10は、エンコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法1000である。

1010において、ランダムアクセスポイント（「RAP」）であると指定されたピクチャを含むビットストリームが生成される。さらに、RAPのためのいかなる及びすべてのリーディングピクチャもがデコーディング順序においてRAPのためのいかなる非リーディングピクチャよりも前に来るように、生成が行われる。1012において、ビットストリームは、（例えば、コンピュータ読取可能記憶媒体にビットストリームを記憶することによって、又はファイルにビットストリームを書き込むことによって）出力される。

図11は、デコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法1100である。

1110において、複数ピクチャのためのエンコードされたデータを含むビットストリームが受信される（例えば、さらなる処理のため、メモリにバッファリングされ、アクセスされ、ロードされ、あるいはその他の方法で入力される）。例示されている実施形態において、ビットストリームは、ランダムアクセスポイント（「RAP」）ピクチャであると指定されたピクチャを含む。さらに、例示されている実施形態において、ビットストリームは、RAPのためのいかなる及びすべてのリーディングピクチャもがデコーディング順序においてRAPのためのいかなる非リーディングピクチャよりも前に来るという制約下で生成されている。

1112において、複数ピクチャがデコードされる。

開示されるテクノロジーの実施形態を使用して、ビデオプレイバック品質に実質的に影響を与えずに、デコーダがデコーディングを始めることができるところの利用可能なランダムアクセスポイントの数を増加させることができる。したがって、開示されるテクノロジーの実施形態は、ビデオ符号化システムが動作できるスピード及び／又はシームレス性（seamlessness）を改良することができる。例えば、BLAピクチャと関連するインジケータとの使用は、デコーディング処理の開始に対して増加された数のランダムアクセスポイントを提示することによって、及びランダムアクセスポイントで（例えば、BLAピクチャで）始まるビデオを適切に処理するためにデコーダが使用できる情報を提示することによって、早送りオペレーション、巻き戻しオペレーション、スキャニングオペレーション、接合オペレーション又は複数ビデオストリーム間の切り替えオペレーションなどの様々なオペレーションの実行を改良することができる。以下の図12及び図13は、本明細書に開示されるBLA手法の利点を生かした例示的なビデオ処理方法を提示する。開示される手法をビデオエンコーディングシステム又はビデオデコーディングシステムにおいて使用して、適応的ビデオ配信、製作物編集、コマーシャル挿入及び同様のことをより柔軟に行うことができる。

図12は、メディア処理ツール又は装置により行われる一例示的方法1200である。

1210において、第1のビットストリーム部分がデコードされる。1212において、第2のビットストリーム部分内のエンコードされたピクチャがブロークンリンクアクセスピクチャであるとの指標が、（例えば、ピクチャのためのNALユニットタイプ値を解析及び処理することによって）検出される。1214において、ブロークンリンクアクセスピクチャで始まる第2のビットストリーム部分の少なくともいくらかが、デコードされる。特定の実装において、デコーディングは、ブロークンリンクアクセスピクチャに関連する第2のビットストリームの1又は複数のピクチャをスキップすること（例えば、デコードしないこと、又は出力しないこと）をさらに含む。例えば、デコーダは、RADLピクチャとして指定されたリーディングピクチャをデコードし、RASLピクチャとして指定されたピクチャのデコーディングをスキップすることができる。1216において、第1のビットストリーム部分からデコードされたピクチャが出力され、第2のビットストリーム部分からデコードされたピクチャが後に続く。

例示的な方法1200は、メディア処理装置（例えば、ビデオプレイバックツール又は装置）により実装された早送りオペレーション、巻き戻しオペレーション又はスキャンオペレーションの一部として行うことができる（例えば、ビデオストリーム内の特定のポイント又は時間に対してスキャンしたいユーザにより開始される）。こうした例において、ビットストリーム部分は、同一のビットストリームの一部である。例示的な方法1200は、ストリーム、ブロードキャスト又はチャネル切り替えオペレーションが行われるとき（例えば、ケーブル、衛星又はインターネットTVシステムと関連して使用されるビデオデコーダにより行われるなど）に行うこともできる。こうした例において、ビットストリーム部分は、異なるビットストリームからのものである。

さらに、特定の実装において、指標は、エンコードされたピクチャが複数のタイプのブロークンリンクアクセスピクチャの1つであることを示し、この複数のタイプには下記のうち複数を含む：1又は複数のリーディングピクチャを含み得るタイプ、1又は複数のリーディングピクチャを包含し得るがデコード不能リーディングピクチャを包含しないタイプ、リーディングピクチャを包含しないタイプ。指標は、本明細書に開示される他のタイプのうち任意の1又は複数を同様に合図してもよい。

図13は、メディア処理ツール又はアプリケーションにより行われる一例示的方法1300である。

1310において、第1のビットストリームの少なくとも部分が受信される。1312において、第2のビットストリームの少なくとも部分が受信される。1314において、第1のビットストリームの少なくとも部分が、ブロークンリンクアクセスピクチャにおいて、第2のビットストリームの少なくとも部分に接合される。特定の実施形態において、接合オペレーションは、ブロークンリンクアクセスピクチャに関連するランダムアクセススキップトリーディング（RASL）ピクチャを省略することを追加的に含む。さらに、いくつかの実施形態において、上記接合には、クリーンランダムアクセスピクチャを接合ポイントとして識別することと、接合されたビットストリーム内でクリーンランダムアクセスピクチャをブロークンリンクアクセスピクチャとして指定することとを含むことができる。さらに、特定の実施形態において、上記方法は、ブロークンリンクアクセスピクチャが複数のブロークンリンクアクセスピクチャタイプ（例えば、本明細書に開示されるタイプのうち任意のもの）のうちの1つであるという指標を（例えば、ピクチャのためのNALユニットタイプ値を解析及び処理することによって）検出することを、さらに含むことができる。

方法1300は、例えば、ビデオ編集装置又はアプリケーションによって、あるいはメディアプレイバック装置又はアプリケーションによって、行うことができる。特定の実施形態において、指標は、エンコードされたピクチャが複数のタイプのブロークンリンクアクセスピクチャのうちの1つであることを示し、この複数のタイプには、下記のうち任意の複数を含む：1又は複数のリーディングピクチャを含み得るタイプ、1又は複数のリーディングピクチャを包含し得るがデコード不能リーディングピクチャを含まないタイプ、又はリーディングピクチャを包含しないタイプ。指標は、本明細書に開示される他のタイプのうち任意の1又は複数を同様に合図してもよい。

図14は、エンコーダ又はデジタルメディア処理ツール若しくは装置が行うことができる一例示的方法1400である。

1410において、BLAピクチャがエンコードされる。1412において、BLAピクチャに関連する1又は複数のリーディングピクチャがエンコードされる。1414において、エンコードされたBLAピクチャと1又は複数のエンコードされた関連するリーディングピクチャとを含むビットストリームが生成される。さらに、例示されている実施形態において、ビットストリームを生成する動作は、1又は複数のエンコードされた関連するリーディングピクチャの各々についての明示的な指標をビットストリーム内に生成することをさらに含み、この指標は、デコーディング順序においてBLAピクチャの前にあるピクチャをデコーダが利用できないとき（例えば、接合、早送り、巻き戻し、ビットストリーム変更オペレーション又は同様のことの後に発生する可能性がある）、それぞれのリーディングピクチャがデコード可能であるかデコード可能でないかを示す。特定の実装において、指標は、それぞれのリーディングピクチャがRASLピクチャであるか又はRADLピクチャであるかを識別するNALユニットタイプ値である。

さらに、特定の実装において、ビットストリームを生成する動作は、BLAピクチャが複数のタイプのBLAピクチャのうちの1つであるという明示的な指標を生成することをさらに含むことができる。例えば、ピクチャは、1又は複数の関連するデコード可能又はデコード不能リーディングピクチャを有し得るBLAタイプ（例えば、BLA_W_LPタイプ）として指定されることができる。

図15は、デコーダ又はデジタルメディア処理ツール若しくは装置により行われる一例示的方法1500である。例えば、上記方法を行って、図14において生成されたビットストリームをデコードすることができる。

1510において、BLAピクチャとこのBLAピクチャに関連する1又は複数のエンコードされたリーディングピクチャとを含むビットストリームが受信される。例示されている例において、ビットストリームは、1又は複数のエンコードされた関連するリーディングピクチャの各々についての明示的な指標をさらに含み、この指標は、デコーディング順序においてBLAピクチャの前にあるピクチャをデコーダが利用できないとき（例えば、接合、早送り、巻き戻し、ビデオストリーム変更オペレーション又は同様のことの後に発生する可能性がある）、それぞれのリーディングピクチャがデコード可能であるか又はデコード可能でないかを示す。1512において、エンコードされたBLAピクチャと1又は複数のエンコードされた関連するリーディングピクチャとは、上記の明示的な指標に従ってデコードされる。

いくつかの例において、ビットストリームは、BLAピクチャが複数のタイプのBLAピクチャのうちの1つであるという明示的な指標をさらに含む。例えば、BLAピクチャは、1又は複数の関連するデコード可能又はデコード不能リーディングピクチャを有し得るブロークンリンクアクセスタイプとすることができる。さらに、いくつかの例において、1又は複数のエンコードされた関連するリーディングピクチャの各々のための明示的な指標が、デコーディング順序においてBLAピクチャの前にあるピクチャが利用できないとき、それぞれのリーディングピクチャがデコード可能リーディングピクチャであるか又はデコード不能ピクチャであるかを示す（例えば、リーディングピクチャがRASLピクチャ又はRADLピクチャとして指定されることができる）。

VIII. 結び
開示された発明の原理を適用することができる多くのとり得る実施形態を考えると、例示された実施形態は、単に本発明の好適な実施形態であると認識されるべきであり、本発明の範囲の限定するものと解されるべきではない。むしろ、本発明の範囲は、別記の請求項により定義される。したがって、本出願人は、こうした請求項の範囲及び主旨に入るすべてを本出願人の発明として主張する。

Claims (10)

1. ビットストリームの少なくとも一部を受信することであり、前記ビットストリームの前記少なくとも一部は、エンコードされたピクチャと前記エンコードされたピクチャのために指定されたピクチャタイプとを含み、前記ピクチャタイプは、複数のピクチャタイプのうちの1つであり、前記複数のピクチャタイプは、前記エンコードされたピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、前記エンコードされたピクチャが1以上の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示す第1のタイプを含む、ことと、
   前記エンコードされたピクチャをデコードすることと、
   を含む方法であって、
   前記エンコードされたピクチャは、第1のエンコードされたピクチャであり、前記第1のエンコードされたピクチャは、前記第1のタイプのピクチャとして指定され、前記ビットストリームの前記少なくとも一部は、前記第1のエンコードされたピクチャに関連する第2のエンコードされたピクチャと前記第2のエンコードされたピクチャのためのピクチャタイプとを含み、前記第2のエンコードされたピクチャのための前記ピクチャタイプは、前記第2のエンコードされたピクチャがランダムアクセススキップトリーディング（RASL）ピクチャ又はランダムアクセスデコード可能リーディング（RADL）ピクチャであることを示し、当該方法は、
   前記第2のエンコードされたピクチャがRADLピクチャとして指定される場合、前記第2のエンコードされたピクチャをデコードすることと、
   前記第2のエンコードされたピクチャがRASLピクチャとして指定される場合、前記第2のエンコードされたピクチャのデコーディングをスキップすることと、
   をさらに含む方法。
2. ビットストリームの少なくとも一部を受信することであり、前記ビットストリームの前記少なくとも一部は、エンコードされたピクチャと前記エンコードされたピクチャのために指定されたピクチャタイプとを含み、前記ピクチャタイプは、複数のピクチャタイプのうちの1つであり、前記複数のピクチャタイプは、
   前記エンコードされたピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、前記エンコードされたピクチャが1以上の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示す第1のタイプと、
   前記エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記エンコードされたピクチャがいかなる関連するデコード不能リーディングピクチャも有さないが1以上の関連するデコード可能リーディングピクチャを有し得ることとを示す第2のタイプと、
   前記エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記エンコードされたピクチャがいかなる関連するリーディングピクチャも有さないこととを示す第3のタイプと、
   を含む、ことと、
   前記エンコードされたピクチャをデコードすることと、
   を含む方法。
3. ピクチャを、複数のピクチャタイプのうちの1つであるとして指定することであり、前記複数のピクチャタイプは、
   前記ピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、前記ピクチャが1以上の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示す第1のタイプと、
   前記ピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記ピクチャがいかなる関連するデコード不能リーディングピクチャも有さないが1以上の関連するデコード可能リーディングピクチャを有し得ることとを示す第2のタイプと、
   前記ピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記ピクチャがいかなる関連するリーディングピクチャも有さないこととを示す第3のタイプと、
   を含む、ことと、
   ビットストリームの少なくとも一部を生成することであり、前記ビットストリームの前記少なくとも一部は、前記ピクチャのために指定されたピクチャタイプを含む、ことと、
   を含む方法。
4. 前記複数のピクチャタイプは、
   前記ピクチャがRAPピクチャとして使用できるクリーンランダムアクセス（CRA）であることを示す第4のタイプ、
   をさらに含む、請求項3記載の方法。
5. 当該方法は、前記ピクチャに関連する1以上のリーディングピクチャと1以上の非リーディングピクチャとをエンコードすることをさらに含み、前記ビットストリームの少なくとも一部を生成することは、前記のエンコードされたリーディングピクチャとエンコードされた非リーディングピクチャとを、前記のエンコードされたリーディングピクチャのすべてがビットストリームの前記少なくとも一部の中で前記のエンコードされた非リーディングピクチャのすべての前に来るように順序付けることを含む、請求項3記載の方法。
6. コンピュータにより実行される方法であって、
   エンコードされたブロークンリンクアクセス（BLA）ピクチャと前記BLAピクチャに関連する1以上のエンコードされたリーディングピクチャとを含むビットストリームを受信することであり、前記ビットストリームは、デコーディング順序において前記BLAピクチャの前にあるピクチャが利用できないとき、それぞれのエンコードされたリーディングピクチャがデコード可能であるかデコード可能でないかを示す、前記1以上のエンコードされたリーディングピクチャの各々のための明示的な指標をさらに含む、ことと、
   前記明示的な指標に従って前記1以上のエンコードされたリーディングピクチャをデコードすることと、
   を含む方法。
7. コンピュータに方法を実行させるコンピュータプログラムであって、前記方法は、
   エンコードされたブロークンリンクアクセス（BLA）ピクチャと前記BLAピクチャに関連する1以上のエンコードされたリーディングピクチャとを含むビットストリームを受信することであり、前記ビットストリームは、デコーディング順序において前記BLAピクチャの前にあるピクチャが利用できないとき、それぞれのエンコードされたリーディングピクチャがデコード可能であるかデコード可能でないかを示す、前記1以上のエンコードされたリーディングピクチャの各々のための明示的な指標をさらに含む、ことと、
   前記明示的な指標に従って前記1以上のエンコードされたリーディングピクチャをデコードすることと、
   を含む、コンピュータプログラム。
8. 前記ビットストリームは、前記BLAピクチャが複数のBLAタイプのうちの1つであるとの明示的な指標をさらに含み、前記複数のBLAタイプは、
   前記エンコードされたピクチャがランダムアクセスポイント（RAP）ピクチャとして使用できるブロークンリンクアクセス（BLA）ピクチャであることを示し、前記エンコードされたピクチャが1以上の関連するデコード可能又はデコード不能リーディングピクチャを有し得ることをさらに示す第1のタイプと、
   前記エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記エンコードされたピクチャがいかなる関連するデコード不能リーディングピクチャも有さないが1以上の関連するデコード可能リーディングピクチャを有し得ることとを示す第2のタイプと、
   前記エンコードされたピクチャがRAPピクチャとして使用できるBLAピクチャであることと、前記エンコードされたピクチャがいかなる関連するリーディングピクチャも有さないこととを示す第3のタイプと、
   を含む、請求項7記載のコンピュータプログラム。
9. 前記BLAピクチャが複数のBLAタイプのうちの1つであるとの前記明示的な指標は、前記BLAピクチャが1以上の関連するデコード可能又はデコード不能リーディングピクチャを有し得るブロークンリンクアクセスタイプであることを示す、請求項8記載のコンピュータプログラム。
10. 前記方法は、
    デコード可能であるとの指標を有する前記エンコードされたリーディングピクチャのうち1以上をデコードすることと、
    デコード可能でないとの指標を有する1以上のエンコードされたリーディングピクチャのデコーディングをスキップすることと、
    をさらに含む、請求項9記載のコンピュータプログラム。

Images