JP2006518127A - ピクチャ復号化方法 - Google Patents

Abstract

本発明は符号化済みピクチャの順序付けを行う方法に関し、該方法は、エンコーダにおいて符号化済みピクチャを形成する符号化ステップから成る。少なくとも１つのピクチャグループが上記ピクチャから形成され、上記ピクチャグループの個々のピクチャに対してピクチャＩＤが定義される。上記方法では、上記符号化済みピクチャをデコーダへ送信する送信ステップが実行される。上記符号化済みピクチャは復号化順に再構成され、復号化済みピクチャを形成するために復号化される。上記符号化ステップでは、上記ピクチャＩＤから分離されたビデオシーケンスＩＤが上記符号化済みピクチャに対して定義される。上記ビデオシーケンスＩＤは同じピクチャグループの個々のピクチャに対して同一である。上記復号化ステップでは、どのピクチャが同じピクチャグループに属するかを決定するために上記ビデオシーケンスＩＤが用いられる。本発明はまた、システム、エンコーダ、デコーダ、電子装置、ソフトウェアプログラムおよび記憶媒体にも関する。

Description

本発明は、符号化済みピクチャの順序付けを行う方法に関し、該方法は、エンコーダにおいて符号化済みピクチャを形成する符号化ステップと、エンコーダにおいて符号化済みのピクチャを復号化するオプションの仮想の復号化ステップと、符号化済みピクチャをデコーダへ送信する送信ステップと、復号化順に復号化ピクチャを構成するステップとから成る。本発明はまたシステム、エンコーダ、デコーダ、装置、コンピュータプログラム、信号、モジュール並びにコンピュータプログラム製品にも関する。

公開されているビデオ符号化規格には、ＩＴＵ−Ｔ Ｈ．２６１、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−２およびＩＳＯ／ＩＥＣ ＭＰＥＧ−４パート２が含まれている。本明細書ではこれらの規格を従来のビデオ符号化規格と呼ぶことにする。

ビデオ通信システム
ビデオ通信システムは会話システムと非会話システムとに分けることができる。会話システムには、テレビ会議およびビデオ電話が含まれる。このようなシステムの例には、ＩＳＤＮ、ＩＰ、ＰＳＴＮ通信網でそれぞれ動作するテレビ会議／電話システムを指定するＩＴ−ＵＴ勧告Ｈ．３２０、Ｈ．３２３、Ｈ．３２４が含まれる。会話型システムは、ユーザの経験を改善するために、（オーディオ／ビデオキャプチャから遠端オーディオ／ビデオプレゼンテーションまでの）終端間遅延を最小化する意図を特徴とするものである。

非会話システムには、再生装置の大容量記憶装置に蓄えられたデジタル多用途ディスク（ＤＶＤ）やビデオファイル、デジタルＴＶおよびストリーミングなどの蓄えられたコンテンツの再生が含まれる。これらの技術領域における最も重要な規格についての短いレビューを以下に示す。

今日、デジタルビデオの消費者用電子装置において支配的な規格はＭＰＥＧ−２であり、この規格には、ビデオ圧縮、オーディオ圧縮、蓄積およびトランスポートを対象とする仕様が含まれる。符号化済みビデオの蓄積並びにトランスポートは基本ストリームというコンセプトに基づいて行われる。基本ストリームは、ソース情報の同期、特定、並びに、特性分析を行うのに必要な単一ソース（ビデオなど）プラス補助データから得られる符号化済みデータから構成される。基本ストリームはパケット化されて、固定長のパケットまたは変動長のパケットのいずれかのパケットにされ、パケット化された基本ストリーム（ＰＥＳ）が形成される。個々のＰＥＳパケットはペイロードと呼ばれるストリームデータが後続するヘッダから構成される。種々の基本ストリームから得られるＰＥＳパケットが組み合わされて、プログラムストリーム（ＰＳ）かトランスポートストリーム（ＴＳ）かのいずれかのストリームが形成される。ＰＳは、ストア・アンド・プレイ（ｓｔｏｒｅ−ａｎｄ−ｐｌａｙ）タイプのアプリケーションのような、無視できる送信エラーを含むアプリケーションを目的とするものである。ＴＳは、送信エラーに対する感受性が強いアプリケーションを目的とするものである。しかし、ＴＳは、ネットワークスループットが一定になるように保証されることを想定するものである。

ＩＴＵ−ＴとＩＳＯ／ＩＥＣとのジョイントビデオチーム（ＪＶＴ）において標準化のための努力が続けられている。ＪＶＴの作業はＨ．２６Ｌと呼ばれるＩＴＵ−Ｔの以前の標準化プロジェクトをベースとして行われる。ＪＶＴ標準化の目標は、ＩＴ−ＵＴ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６−１０（ＭＰＥＧ−４パート１０）として同一規格のテキストを公開することである。ドラフトの規格は上記文書でＪＶＴ符号化規格と呼ばれているものであり、このドラフト規格に準拠するコーデックはＪＶＤコーデックと呼ばれている。

上記コーデックの仕様自体では、ビデオ符号化層（ＶＣＬ）とネットワーク抽象化層（ＮＡＬ）とは概念的に区別される。ＶＣＬには、変換、量子化、動き探索／補償、ループフィルタなどのようなコーデックの信号処理機能性が含まれる。この信号処理機能性は、今日のビデオコーデックのほとんどの一般的コンセプトと、動き補償によるインタピクチャ予測（ｉｎｔｅｒ ｐｉｃｔｕｒｅ ｐｒｅｄｉｃｔｉｏｎ）を利用するマクロブロックベースの符号器と、残差信号の変換符号化とに従うものである。ＶＣＬエンコーダの出力は以下のスライスとなる：整数個のマクロブロックからなるマクロブロックデータを含むビット列と、スライスヘッダ情報（スライス内の第１のマクロブロックの空間アドレスと、初期の量子化パラメータなどを含む）。異なるマクロブロック割当てが指定されない限り、スライス内のマクロブロックは、弾力的なマクロブロック順序付けシンタックスを用いて走査順に連続的に順序付けられる。イントラ予測および動きベクトル予測などのようなピクチャ内予測はスライスの中だけで用いられる。

ＮＡＬは、ＶＣＬのスライス出力をネットワーク抽象化層ユニット（ＮＡＬユニットまたはＮＡＬＵ）の中へカプセル化するものである。これらのユニットはパケットネットワークでの送信やパケット指向型の多重化環境で使用するのに適している。ＪＶＴの添付資料Ｂには、バイト・ストリーム指向型のネットワーク上でこのようなＮＡＬＵを送信するカプセル化処理が定義されている。

Ｈ．２６３のオプションの基準ピクチャ選択モードおよびＭＰＥＧ−４パート２のＮＥＷＰＲＥ符号化ツールによって、Ｈ．２６３における個々のスライス当たりのような個々のピクチャセグメント毎の動き補償に対する基準フレームの選択が可能となる。さらに、Ｈ．２６３とＪＶＴ符号化規格とのオプションの拡張型基準ピクチャ選択モードによって、個々のマクロブロックに対する基準フレームの選択が個別に可能となる。

基準ピクチャの選択によって多くのタイプの時間階層符号化方式が可能となる。図１は時間階層符号化方式の１例を示す図であり、この符号化方式は本願明細書では再帰時間階層符号化と呼ばれている。３つの一定のフレームレートを用いてこの例示の方式を復号化することができる。図２はビデオ冗長符号化と呼ばれる方式を描く図であり、この方式では、一連のピクチャが、インタリーブされた態様で２または３以上の独立に符号化されたスレッドに分割される。これらの図内および後続するすべての図内の矢印は動き補償の方向を示し、フレームの下の値はフレームの相対的取得時間および表示時間に対応する。

パラメータセット・コンセプト
ＪＶＤコーデックの１つの基本設計コンセプトとして、ヘッダ複製などのメカニズムを不要にする自給型パケットの生成がある。この自給型パケットの生成を達成した方法として、２以上のスライスに関係する情報を媒体ストリームから分離する方法がある。この上位層メタ情報は、高い信頼性で、非同期で、かつ、スライスパケットＲＴＰを含むパケットストリームから送られることが望ましい。上記目的のために適切な帯域外トランスポートチャネルが設けられていないようなアプリケーションでは、上記メタ情報を帯域内で送ることも可能である。より高レベルのパラメータの組み合わせはパラメータセットと呼ばれる。このパラメータセットには、ピクチャサイズ、表示ウィンドウ、採用されているオプションの符号化モード、マクロブロック割当てマップ、その他の情報が含まれる。

スライスパケットストリームと同期してパラメータセットの更新値を送信する必要なく、（ピクチャサイズなどの）ピクチャパラメータを変更できるようにするために、エンコーダとデコーダとは２以上のパラメータセットのリストを保持することができる。個々のスライスヘッダには使用対象のパラメータセットを示すコードワードが含まれる。

このメカニズムによって、上記パラメータセットの送信をパケットストリームから分離し、機能交換の副作用として、あるいは、（信頼性の高いまたは信頼性の高くない）制御プロトコルを介するなどの外部手段によってこれらのパラメータセットの送信が可能となる。アプリケーションの設計仕様によって、上記パラメータセットが一度も送信されず、固定される場合さえある。

送信順序
従来のビデオ符号化規格では、ピクチャの復号化順序はＢピクチャを除いて表示順序と同じである。従来方式のＢピクチャ内のブロックは、２つの基準ピクチャからの双方向の時間的予測を行うことが可能であり、その場合、表示順序において、一方の基準ピクチャが時間的に先行し、他方の基準ピクチャは時間的に後続する。復号化順序で最新の基準ピクチャだけが、表示順序でＢピクチャの後に続くことができる（例外：Ｈ．２６３でインターレースされた符号化。この場合、時間的に後続する基準フレームの双方のフィールドピクチャが復号化順にＢピクチャに先行する場合がある）。従来方式のＢピクチャは、時間的予測を行うための基準ピクチャとして用いることはできない。したがって従来方式のＢピクチャは他のいずれのピクチャの復号化にも影響を与えることなく配置することが可能となる。

ＪＶＴ符号化規格には、以前の規格と比べて以下の新規の技術的特徴が含まれている：
・ ピクチャの復号化順序が表示順序から分離される。ｆｒａｍｅ＿ｎｕｍシンタックス要素の値が復号化順序を示し、ピクチャ順序のカウント値が表示順序を示す。
・ Ｂピクチャでのブロックに対する基準ピクチャは、表示順序においてＢピクチャの前または後のいずれかに存在することができる。したがってＢピクチャは双方向ピクチャの代わりに双予測（ｂｉ−ｐｒｅｄｉｃｔｉｖｅ）ピクチャを表すことになる。
・ 基準ピクチャとして使用しないピクチャは明示的にマークされる。任意のタイプ（イントラ、インタ、Ｂ、など）のピクチャを基準ピクチャか非基準用ピクチャかのいずれかのピクチャにすることができる（したがって、別のピクチャの時間的予測に対する基準ピクチャとしてＢピクチャの使用が可能となる）。
・ ピクチャは、異なる符号化タイプを用いて符号化されたスライスを含むことができる。言い換えれば、符号化ピクチャは、例えば、イントラ符号化スライスとＢ符号化スライスとから構成したものであってもよい。

復号化順序からの表示順序の分離は、圧縮効率およびエラー復元力という点から見て有利なものになる可能性がある。

圧縮効率の潜在的改善を図る予測構造の１例が図３に示されている。ボックスはピクチャを示し、ボックス内の大文字は符号化タイプを示し、ボックス内の数字はＪＶＴ符号化規格に準拠するピクチャ番号であり、矢印は予測依存状態を示す。Ｂ１７がピクチャＢ１８に対する基準ピクチャであることに留意されたい。圧縮効率は従来方式の符号化と比べると潜在的に改善されている。というのは、ピクチャＢ１８に対する基準ピクチャの方が、ＰＢＢＰまたはＰＢＢＢＰ符号化ピクチャパターンを用いる従来方式の符号化と比べると時間的に近くなるからである。圧縮効率は、従来方式のＰＢＰ符号化ピクチャパターンと比べると潜在的に改善される。というのは、基準ピクチャの一部が双方向に予測されるからである。

図４は、エラー復元力の改善を図るために利用可能なイントラピクチャ延期法の１例を示す図である。従来の方式では、イントラピクチャは、例えば、シーンのカットの直後に、あるいは、イントラピクチャリフレッシュ時間の時間切れに対する応答として符号化される。イントラピクチャ延期法では、イントラピクチャは、イントラピクチャを符号化する必要性が生じた直後には符号化されず、逆に時間的に後続するピクチャがイントラピクチャとして選択される。符号化済みイントラピクチャと、従来方式のイントラピクチャ位置との間の個々のピクチャは次の時間的に後続するピクチャから予測される。図４が示すように、イントラピクチャ延期法が２つの独立したインタピクチャ予測チェーンを生成するのに対して、従来方式の符号化アルゴリズムでは単一のインタピクチャチェーンが生成される。従来方式の１チェーン・アプローチよりも２チェーン・アプローチの方が消去エラーに対してロバストであることは直感的に明瞭である。一方のチェーンがパケット紛失を被っても、他方のチェーンはまだ正しく受信されている可能性がある。従来方式の符号化では、パケット紛失によって、残りのインタピクチャ予測チェーンに対するエラー拡散が常に引き起こされる。

２つのタイプの順序付け情報と時間情報とは、従来、デジタルビデオ、すなわち復号化順序およびプレゼンテーション順序と関連づけられてきた。これに関連する技術を以下さらに綿密に見てみよう。

復号化タイムスタンプ（ＤＴＳ）は、符号化されたデータ単位の復号化を行うために想定されている基準クロックに対する相対的な時間を示すものである。ＤＴＳが符号化され、送信される場合、ＤＴＳは２つの目的のために機能する：第１に、ピクチャの復号化順序が該ピクチャの出力順序と異なる場合、ＤＴＳは復号化順序を明示的に示す。第２に、もし受信レートが任意の時点で送信レートに接近したものであれば、ＤＴＳは、或る一定の前置復号器バッファリング（デコーダ用として符号化されたデータ単位のバッファリング）の振舞いを保証するものとなる。エンドツーエンドの待ち時間が変動するネットワークでは、ＤＴＳの第２の利用はまったくあるいはほとんど役割を果たさなくなる。その代わり、もし（復号化ピクチャのバッファリング用の）後置復号器バッファ内に未圧縮ピクチャ用の余地があれば、受信データは可能な限り高速に復号化されることになる。

ＤＴＳの搬送は使用中の通信システムとビデオ符号化規格とに依存する。ＭＰＥＧ−２システムでは、ＤＴＳは、ＰＥＳパケットのヘッダ内の１つの項目としてオプションとして送信することができる。ＪＶＴ符号化規格では、補足の拡張機能情報（ＳＥＩ）の一部として、オプションとしてＤＴＳの搬送が可能であり、さらに、ＤＴＳはオプションの仮想基準デコーダの操作時に使用される。ＩＳＯベースのメディアファイルフォーマットでは、ＤＴＳはそれ自身のボックスタイプ（サンプルボックスに対する復号化時間）専用となる。ＲＴＰベースのストリーミングシステムなどの多くのシステムでは、ＤＴＳが搬送されることは全くない。というのは、復号化順序が送信順序と同じであると想定されていて、正確な復号化時間は重要な役割を果たしていないからである。

Ｈ．２６３のオプションの添付資料Ｕおよび添付資料Ｗ．６．１２には、復号化順に前回の基準ピクチャに対して１だけ増分されるピクチャ番号が指定されている。ＪＶＴ符号化規格では、ｆｒａｍｅ＿ｎｕｍシンタックス要素（本明細書では以後フレーム番号とも呼ぶ）は、Ｈ．２６３のピクチャ番号に対しても同様に指定される。ＪＶＴ符号化規格は、同時的復号化リフレッシュ（ＩＤＲ）ピクチャと呼ばれる特別タイプのイントラピクチャを指定している。後続するピクチャは、復号化順にＩＤＲピクチャよりも前にあるピクチャを参照することはできない。ＩＤＲピクチャはシーンチェインジに対する応答として符号化される場合が多い。ＪＶＴ符号化規格では、フレーム番号はＩＤＲピクチャにおいて０にリセットされ、このリセットによって、ＩＤＲピクチャが紛失した場合、図５ａと５ｂに示されているように、状況によってはエラー復元力の改善を図ることが可能となる場合もある。しかし、ＪＶＴ符号化規格のシーン情報ＳＥＩメッセージをシーンチェインジの検出にも利用できることに留意されたい。

Ｈ．２６３ピクチャ番号を用いて、基準ピクチャの復号化順序を回復することができる。同様に、ＪＶＴフレーム番号を用いて、復号化順にＩＤＲピクチャ（このピクチャを含む）と次のＩＤＲピクチャ（このピクチャを除く）との間でフレームの復号化順序を回復することができる。しかし、相補的参照フィールドの対（異なるパリティからなるフィールドとして符号化された連続的ピクチャ）が同じフレーム番号を共有しているため、フレーム番号からフレームの復号化順序を再構成することはできない。

Ｈ．２６３ピクチャ番号または非基準用ピクチャのＪＶＴフレーム番号は、復号化順序で、前の基準ピクチャのピクチャ番号またはフレーム番号＋１に等しくなるように指定される。いくつかの非基準用ピクチャが復号化順に連続していれば、それらのピクチャは同じピクチャ番号またはフレーム番号を共有する。非基準用ピクチャのピクチャ番号またはフレーム番号も、復号化順序で次の基準ピクチャのピクチャ番号またはフレーム番号と同じである。Ｈ．２６３における時間参照値（ＴＲ）符号化エレメントまたはＪＶＴ符号化規格のピクチャ順序カウント値（ＰＯＣ）というコンセプトを用いて、連続する非基準用ピクチャの復号化順序の回復が可能となる。

ピクチャの表示が仮定されているとき、プレゼンテーション用タイムスタンプ（ＰＴＳ）は基準クロックに対する時間を示す。プレゼンテーション用タイムスタンプは表示タイムスタンプ、出力用タイムスタンプ、構成タイムスタンプとも呼ばれる。

ＤＴＳの搬送は使用中の通信システムとビデオ符号化規格とに依存する。ＭＰＥＧ−２システムでは、ＰＴＳはＰＥＳパケットのヘッダ内の１つの項目として、オプションとして送信することができる。ＪＶＴ符号化規格では、補足拡張機能情報（ＳＥＩ）の一部として、オプションとしてＰＴＳを運ぶことが可能であり、さらに、ＰＴＳは仮想基準デコーダの操作時に使用される。ＩＳＯベースのメディアファイルフォーマットでは、ＰＴＳは、プレゼンテーション用タイムスタンプが復号化タイムスタンプに対して符号化されるそれ自身のボックスタイプ（サンプルボックスに対する構成時間）専用となる。ＲＴＰでは、ＲＴＰパケットヘッダ内のＲＴＰタイムスタンプはＰＴＳに対応するものとなる。

多くの従来のビデオ符号化規格は、多くの面でＰＴＳの場合と類似している時間参照値（ＴＲ）符号化エレメントを特徴付けるものである。ＭＰＥＧ−２ビデオなどの従来の符号化規格のいくつかの符号化規格では、ＴＲは１グループのピクチャ（ＧＯＰ）の開始部で０にリセットされる。ＪＶＴ符号化規格では、ビデオ符号化層における時間というコンセプトは存在しない。ピクチャ順序カウント値（ＰＯＣ）は個々のフレームとフィールドとに対して指定され、さらに、このピクチャ順序カウント値は、例えば、Ｂスライスの直接時間予測の形でＴＲに対しても同様に使用される。ＰＯＣはＩＤＲピクチャで０にリセットされる。

ＲＴＰシーケンス番号は通常、ＲＴＰヘッダ内の１６ビットの無符号値であり、このＲＴＰシーケンス番号は、個々のＲＴＰ送信データパケットに対して１だけ増分され、さらに、受信機により用いられて、パケット紛失を検出し、パケットシーケンスを復元することができる。

マルチメディアストリームの送信
マルチメディア・ストリーミングシステムは、ストリーミングサーバおよびネットワークを介してサーバにアクセスする複数のプレイヤから構成される。ネットワークは一般にパケット指向型であり、保証されたサービス品質に対する手段をほとんどあるいはまったく提供しない。プレイヤは、予め蓄えられたマルチメディアコンテンツか、ライブのマルチメディアコンテンツかのいずれかのコンテンツをサーバからフェッチし、このコンテンツをダウンロードしながら、コンテンツをリアルタイムで再生する。通信のタイプは、ポイント・トゥー・ポイントか、マルチキャストかのいずれかであってもよい。ポイント・トゥー・ポイントストリーミングでは、サーバによって、個々のプレイヤ用の個別の接続が行われる。マルチキャストストリーミングでは、サーバは、単一のデータストリームを複数のプレイヤへ送信し、次いで必要な場合にのみネットワークエレメントはストリームの複製を行う。

プレイヤがサーバとの接続を確立し、マルチメディアストリームを要求したとき、サーバは所望のストリームの送信を開始する。プレイヤはストリームの再生をすぐに開始せず、代わりに、数秒の間着信データのバッファを行うのが一般的である。本明細書では、このバッファリングを初期バッファリングと呼ぶ。初期バッファリングはポーズのない再生の保持に役立つものである。というのは、時折送信遅延が長くなった場合や、ネットワークスループットが低下した場合に、プレイヤはバッファ済みデータを復号化し、このデータを再生することができるからである。

制限のない送信遅延を避けるために、信頼性の高いトランスポートプロトコルがストリーミングシステムにおいて特に好まれることは稀である。むしろ、システムが、一方でより安定した送信遅延を受け継ぎながら、他方で、データ破損や紛失を被るＵＤＰのような信頼性の高くないトランスポートプロトコルの方を好むことがある。

ＵＤＰの上位でＲＴＰとＲＴＣＰプロトコルとを使用して、リアルタイムの通信制御することができる。ＲＴＰは、送信パケットの紛失を検出し、受信端においてパケットの正しい順序を再構成し、サンプリングタイムスタンプを個々のパケットと関連づける手段を提供するものである。ＲＴＣＰは、どのくらいの大きさのパケット部分を正しく受信したかに関する情報を送るものであり、したがって、フロー制御を行う目的で使用することが可能である。

送信エラー
主要な２つのタイプの送信エラーおよびパケットエラーが存在する。ビットエラーは、一般に、移動通信における無線アクセスネットワーク接続などのような回線交換型チャネルと関連づけられ、これらのビットエラーは、電波妨害などの物理チャネルの不完全さに起因して生じる。このような不完全さの結果、送信データの中にビット反転、ビット挿入並びにビット削除が生じる可能性がある。パケットエラーは一般にパケット交換ネットワーク内のエレメントに起因して生じるものである。例えば、パケットルータは輻輳状態になる可能性がある。すなわちパケットルータが入力としてあまりに多くのパケットを取得したため、同一レートでそれらの多くのパケットを出力できなくなる場合がある。この状況で、当該バッファがオーバーフローし、いくつかのパケットが紛失する。パケットの複製、および、送信時とは異なる順序でのパケットの配信も可能ではあるが、一般に、これらはパケット紛失ほどありふれたものではないと考えられている。パケットエラーは、使用するトランスポートプロトコルスタックの実施構成に起因して生じる場合もある。例えば、送信機で計算され、ソース符号化データと共にカプセル化されるチェックサムを使用するいくつかのプロトコルもある。データの中でビット反転エラーが生じた場合、受信機は最後に同じチェックサムの中へ入ることができなくなり、受信パケットを破棄しなければならなくなる場合がある。

ＧＰＲＳ、ＵＭＴＳ、およびＣＤＭＡ−２０００を含む第２世代（２Ｇ）及び第３世代（３Ｇ）のモバイルネットワークは、確認応答型と非確認応答型の２つの基本タイプの無線リンク接続を提供する。確認応答型接続とは、受け手側（移動局ＭＳ、基地局サブシステム、ＢＳＳのいずれか）が無線リンクフレームの完全性のチェックを行うようにするものであり、送信エラーが生じた場合、再送要求が無線リンクの他方の終端部へ与えられる。リンク層再送信に起因して、フレームに対する肯定の確認応答が受信されるまで、発信者は無線リンクフレームのバッファを行う必要がある。過酷な無線条件では、このバッファがオーバーフローして、データ損失を引き起こす可能性がある。それにもかかわらず、ストリーミングサービス用として確認型無線リンクプロトコルモードの利用が有利であることが示されている。非確認応答型接続とは、一般にエラーを含む無線リンクフレームを破棄するためのものである。

パケット紛失に対して、修正か、隠蔽かのいずれかを行うことができる。紛失の修正は、あたかも紛失が生じなかったかのように紛失データを完全に復元する能力を意味する。紛失の隠蔽は、送信紛失の影響が再構成されたビデオシーケンスの中で見えないように、これらの影響を隠蔽する能力を意味するものである。

プレイヤは、パケットの紛失を検出したとき、パケットの再送信を要求することができる。初期バッファリングに起因して、再送パケットのスケジュール済みの再生時刻の前に、この再送パケットを受信してもよい。市販のインターネットストリーミングシステムのなかには、独自のプロトコルを用いて再送要求を実行するものもある。ＲＴＣＰの一部として選択的再送要求メカニズムを標準化する作業がＩＥＴＦにおいて続けられている。

これらの再送要求プロトコルのすべてに対する共通の特徴として、ネットワークトラフィックが著しく増加する場合があるため、これらの特徴が多数のプレイヤにとってマルチキャストに適したものではないという点が挙げられる。その結果、マルチキャストストリーミング・アプリケーションは非双方向型のパケット紛失制御に依拠する必要がある。

ポイント・トゥー・ポイントストリーミングシステムは非双方向型のエラー制御技法から利益を得ることができる。第１に、システムのなかには双方向型エラー制御メカニズムをまったく含まないものもあるし、あるいは、システムを単純化するために、プレイヤからのフィードバックをまったく受け取らない方を好むものもある。第２に、紛失パケットの再送信および別の形の双方向型エラー制御は、一般に、非双方向型のエラー制御方法よりも大きな部分の送信データの転送レートを必要とする。ストリーミングサーバは、双方向型エラー制御方法が利用可能なネットワークスループットの主要部分を予約しないことを保証しなければならない。実際には、サーバが双方向型エラー制御動作の量に限度を設けなければならない場合がある。第３に、データサンプルを再生する前に、或る特定のデータサンプルに対するすべての双方向型エラー制御動作を好適に行うことが望ましいため、送信遅延によってサーバとプレイヤ間でのインタラクション回数に限度を設けるようにしてもよい。

非双方向型のパケット紛失制御メカニズムは、順方向型エラー制御と、後処理による紛失隠蔽とに類別することができる。順方向型エラー制御とは、たとえ送信紛失が生じた場合であっても、受信機が送信データの少なくとも一部を回復できるような冗長性を送信機がその送信データに付加する技法を意味するものである。後処理によるエラー隠蔽は全く受信機指向型のものである。これらの方法は誤って受信したデータの正しい表現の推定を試みるものである。

ほとんどのビデオ圧縮アルゴリズムは、時間的に予測が行われるＩＮＴＥＲピクチャまたはＰピクチャを生成するものである。その結果、１つのピクチャにおけるデータ損失は、破損したピクチャからの時間的予測の結果得られるピクチャの目に見える劣化を引き起こす原因になる。ビデオ通信システムは、破損フレームに依存しないフレームが受信されるまで、表示画像での紛失を隠蔽するか、最新の正しいピクチャをスクリーン上へフリーズさせるかのいずれかを行うことができる。

従来のビデオ符号化規格では、復号化順序は出力順序と結合される。換言すれば、ＩピクチャとＰピクチャとの復号化順序はこれらのピクチャの出力順序と同じであり、Ｂピクチャの復号化順序は、出力順序でＢピクチャの後の基準ピクチャの復号化順序の直後に続くことになる。この結果、所定の出力順序に基づいて復号化順序の回復が可能となる。出力順序は一般に、時間参照値（ＴＲ）フィールド内の基本ビデオビットストリームの形で送信され、さらにＲＴＰヘッダにおける場合のようにシステム多重化層内の基本ビデオビットストリームの形でも送信される。したがって、従来のビデオ符号化規格では、復号化の順序とは異なる送信順序に関連する上記提示した問題は存在しなかったことになる。

（ＪＶＴ符号化規格で行われるように）ＩＤＲピクチャにおいて０にリセットすることなく、Ｈ．２６３のピクチャ番号の場合と同様に、ビデオビットストリームの範囲内でフレームカウンタ値に基づいて符号化ピクチャの復号化順序の再構成が可能であることは、当分野の専門家には自明であるかもしれない。しかし、この種の解決方法を利用する場合、２つの問題が生じる可能性がある。

第１に、図５ａは、連続する番号付け方式を利用する状況を示す図である。例えば、ＩＤＲピクチャＩ３７が紛失した（受信／復号化を行うことができない）場合、デコーダは後続ピクチャの復号化を続けるが、デコーダは間違った基準ピクチャを用いることになる。これによって、破損フレームに依存しない次のフレームが受信され、正しく復号化されるまで、後続フレームへのエラー拡散が引き起こされる。図５ｂの例では、フレーム番号はＩＤＲピクチャで０にリセットされる。次に、ＩＤＲピクチャＩ０が紛失した状況で、デコーダは、一番最近正しく復号化されたピクチャＰ３６の後にピクチャ番号付けの大きな空隙が生じている旨を通知する。この時、デコーダはエラーが生じたことを想定することができ、破損フレームに依存しない次のフレームが受信され、復号化が行われるまで、ピクチャＰ３６に対して表示をフリーズさせることが可能となる。

第２に、受信機によって、個々の基準ピクチャに対して復号化順に１だけ増分を行うなどの予め定義された番号付け方式が想定されている場合、スプライシングおよびサブシーケンスの除去に関連する問題点が存在することは明らかである。受信機は、紛失検出用として予め定義された番号付け方式を利用することができる。スプライシングとは、別の符号化済みシーケンスの中央の中へ符号化済みシーケンスを挿入する処理を意味する。スプライシングの実用の１例として、デジタルＴＶ放送における広告の挿入がある。受信機によって予め定義された番号付け方式が予想される場合、送信機は、フレームカウント値に基づいて、スプライスされたシーケンスの位置と送信中のフレームカウンタ番号との更新を行う必要がある。同様に、例えば、送信機がいくつかのサブシーケンスの送信を決定しない場合、ＩＰパケットネットワークにおいてネットワークの輻輳状態を避けるために、送信機は配置されたサブシーケンスの位置とフレームカウント値とに基づいて送信中フレームカウンタ番号の更新を行う必要がある。サブシーケンス・コンセプトの詳細については後程本解説で説明する。

ＲＴＰシーケンス番号に類似しているが、送信順序の代わりにＮＡＬユニットの復号化順序を示す、ＮＡＬユニットのシーケンス番号に基づいてＮＡＬユニットの復号化順序の再構成を行うことも可能であることは、当分野の専門家には自明であるかもしれない。しかし、この種の解決方法を利用する場合、２つの問題が生じる可能性がある。

第１に、場合によっては、完全な回復復号化順序が必要ではないことがある。例えば、ピクチャに対するＳＥＩメッセージは、一般に任意の順序で復号化が可能である。デコーダが任意のスライス順序付けをサポートしていれば、ピクチャのスライスは任意の順序で復号化を行うことができる。したがって、ネットワークエレメントにおける意図しないパケットスケジューリングの相違に起因して生じるＮＡＬユニットシーケンス番号の順序からＮＡＬユニットが受信され、たとえ後続のＮＡＬユニットシーケンス番号を持つＮＡＬユニットの復号化が実際に可能である場合であっても、受信機は、脱落しているＮＡＬユニットシーケンス番号に対応するＮＡＬユニットを不必要に待つことになる場合がある。この追加遅延によって、使用中のビデオ通信システムにおいて経験される主観的品質が低下する場合がある。さらに、上記追加遅延によって、紛失の修正あるいは隠蔽処理の利用が不必要にトリガされる場合もある。

第２に、別のＮＡＬユニットの復号化処理に影響を与えることなく、ネットワークエレメントによって非基準用ピクチャのスライスおよびＳＥＩ＿ＮＡＬＵユニットなどのいくつかのＮＡＬユニットを破棄してもよい場合がある。ＮＡＬユニットのこのような廃棄処分はＮＡＬユニットシーケンス番号の受信シーケンスに空隙を生じさせることになる。従来、ＲＴＰシーケンス番号の場合と同様、受信機は、復号化順に個々のＮＡＬユニットに対して１だけ増分するような予め定義された番号付け方式を想定し、紛失検出を行うためにシーケンス番号におけるこの空隙を利用している。ＮＡＬユニットシーケンス番号の上記のような利用は、他のＮＡＬユニットの復号化に影響を与えることなくＮＡＬユニットを配置できる可能性と矛盾するものである。

サブシーケンス
ＪＶＴ符号化規格には、符号化済みストリームの残りのストリームの復号化の可能性に影響を与えることなく、ピクチャのインタ予測（ｉｎｔｅｒ−ｐｒｅｄｉｃｔｅｄ）チェーンを全体として配置できるように、非基準用ピクチャの利用と比較して時間階層符号化を改善できるサブシーケンス・コンセプトも含まれている。

サブシーケンスはサブシーケンス層内の符号化ピクチャの集合である。ピクチャは、１つのサブシーケンス層内および１つのサブシーケンス内にのみ存在する。サブシーケンスは、同じサブシーケンス層内の、または、それより上位のサブシーケンス層内の他のいずれのサブシーケンスにも依存しない。層０内のサブシーケンスは、他のいずれのサブシーケンスおよび前回の長期基準ピクチャから独立に復号化を行うことができる。図６ａは、層１にサブシーケンスを含むピクチャストリームの１例を開示する図である。

サブシーケンス層には、サブセットの符号化ピクチャが順番に含まれる。サブシーケンス層には非負数の整数で番号が付けられる。大きな層番号を持つ層は、小さな層番号を持つ層よりも上位の層となる。層はその依存状態に基づいて相互に階層的に順序付けられ、それによっていずれの上位層にも依存しないようにされ、下位層に依存できるようにされる。換言すれば、層０は独立に復号化可能であり、層１内のピクチャを層０から予測することができ、層２内のピクチャを層０および層１から予測することができる、など。主観的品質は復号化された層の数と共に上昇する。

サブシーケンス・コンセプトは以下のようにＪＶＴ符号化規格の中に含まれている：シーケンスパラメータセット内の１に等しいｒｅｑｕｉｒｅｄ＿ｆｒａｍｅ＿ｎｕｍ＿ｕｐｄａｔｅ＿ｂｅｈａｖｉｏｕｒ＿ｆｌａｇは、符号化済みシーケンスがすべてのサブシーケンスを含まない場合もある旨を信号で送信する。ｒｅｑｕｉｒｅｄ＿ｆｒａｍｅ＿ｎｕｍ＿ｕｐｄａｔｅ＿ｂｅｈａｖｉｏｕｒ＿ｆｌａｇの使用状況によって、個々の基準フレームに対するフレーム番号の１の増分値の必要条件が解除される。代わりに、特に、復号化ピクチャバッファ内のフレーム番号の空隙にはマークが付けられる。インタ予測時に“脱落”フレーム番号を参照する場合、ピクチャの紛失が推論される。“脱落”フレーム番号を参照しない場合、“脱落”フレーム番号に対応するフレームは、あたかもスライディングウィンドウバッファリングモードを用いて、復号化ピクチャバッファへ挿入される正常なフレームであるかのように処理される。配置されたサブシーケンス内のすべてのピクチャに復号化ピクチャバッファ内の“脱落”フレーム番号が割り当てられるが、これらのピクチャは他のサブシーケンスに対するインタ予測時には決して使用されない。

ＪＶＴ符号化規格には、オプションのサブシーケンス関連ＳＥＩメッセージも含まれる。サブシーケンス情報ＳＥＩメッセージは復号化順に次のスライスと関連づけられる。このサブシーケンス情報ＳＥＩメッセージは、サブシーケンス層およびスライスが属するサブシーケンスのサブシーケンス識別子（ｓｕｂ＿ｓｅｑ＿ｉｄ）を信号で伝える。

個々のＩＤＲピクチャのスライスヘッダには識別子（ｉｄｒ＿ｐｉｃ＿ｉｄ）が含まれる。２つのＩＤＲピクチャが、ピクチャが中間に介在せずに復号化順序で連続している場合、ｉｄｒ＿ｐｉｃ＿ｉｄの値は第１のＩＤＲピクチャから別のＩＤＲピクチャへ変化する。現在の画像がサブシーケンス内に存在し、該サブシーケンスの復号化順で第１のピクチャがＩＤＲピクチャである場合、ｓｕｂ＿ｓｅｑ＿ｉｄの値はＩＤＲピクチャのｉｄｒ＿ｐｉｃ＿ｉｄの値と同じ値となる。

ＪＶＴ符号化規格における符号化ピクチャの復号化順序は、一般に、フレーム番号およびサブシーケンス識別子に基づいて再構成することはできない。送信順序が復号化順序と異なり、符号化ピクチャがサブシーケンス層１の中に存在すれば、サブシーケンス層０内のピクチャに対するこれら符号化ピクチャの復号化順序をサブシーケンス識別子およびフレーム番号に基づいて結論を下すことはできないであろう。例えば、図６ｂに示される以下の符号化方式について考えることにする。図６ｂでは、出力順序が左から右へ動き、ボックスがピクチャを示し、ボックス内の大文字が符号化タイプを示し、アンダーライのついたキャラクタが非基準用ピクチャを示し、矢印が予測依存状態を示す。ピクチャがＩ０、Ｐ１、Ｐ３、Ｉ０、Ｐ１、Ｂ２、Ｂ４、Ｐ５の順に送信される場合、ピクチャＢ２がどの独立ピクチャグループ（独立ＧＯＰ）に属するかについて結論を下すことはできない。独立ＧＯＰは、別のピクチャグループから得られる他のいずれのピクチャも用いることなく、正しく復号化を行うことができる１グループのピクチャである。

前回の例示では、ピクチャＢ２用の正しい独立ＧＯＰをその出力用タイムスタンプに基づいて結論を下すこともできると主張することもできよう。しかし、出力用タイムスタンプとピクチャ番号とに基づいてピクチャの復号化順序を回復することはできない。というのは、復号化順序と出力順序とが分離されているからである。以下の例（図６ｃ）について考えることにする。この例では、出力順序が左から右へ動き、ボックスがピクチャを示し、ボックス内の大文字が符号化タイプを示し、ボックス内の数字はＪＶＴ符号化規格に準拠するフレーム番号であり、矢印が予測依存状態を示している。ピクチャが復号化順序から送信される場合、出力順序で第１または第２の独立ＧＯＰのＰ３の後でピクチャＰ４を復号化すべきかどうかを高い信頼性で検出することはできない。

主要ピクチャおよび冗長ピクチャ
主要符号化済みピクチャはピクチャの主要な符号化表現である。復号化された主要符号化済みピクチャは、ピクチャ領域全体をカバーする。すなわち、主要符号化済みピクチャには、ピクチャのすべてのスライスおよびマクロブロックが含まれる。冗長符号化済みピクチャは、主要符号化済みピクチャが脱落していたり、破損したりしていない限り、復号化用として使用されることはないピクチャまたはピクチャの一部の冗長な符号化表現である。冗長符号化済みピクチャは主要符号化済みピクチャ内のすべてのマクロブロックを含む必要はない。

バッファリング
ストリーミングクライアントは、一般に、比較的多量のデータを格納する能力を持つ受信バッファを備えている。最初に、ストリーミングセッションが確立されると、クライアントはストリームの再生をすぐには開始せず、数秒の間着信データのバッファを行うのが一般的である。このバッファリングは連続する再生の保持に役立つものである。というのは、時折送信遅延が長くなったり、ネットワークスループットが低下したりした場合、クライアントはバッファ済みデータを復号化し、再生できるからである。上記のような受信バッファを備えていない場合、クライアントは、初期バッファリングを行うことなく、表示をフリーズさせ、復号化を停止して、着信データを待たなければならない。バッファリングは、任意のプロトコルレベルにおける自動再送信あるいは選択再送信のいずれかの再送信を行うためにも必要である。ピクチャのいずれかの一部が紛失した場合、再送信メカニズムを用いて紛失データの再送信を行うことが可能である。再送データがそのスケジュールされた復号化時刻あるいは再生時刻前に受信されれば、紛失は完全に回復される。

符号化ピクチャは、復号化済みシーケンスの主観的品質に関して、該シーケンスの重要度に基づいてランク付けを行うことができる。例えば、従来方式のＢピクチャのような非基準用ピクチャは主観的に最も重要度の低いものである。というのは、これらのＢピクチャが存在しないことによって他のいずれのピクチャの復号化にも影響が生じないからである。データ・パーティションまたはスライスグループに基づいて主観的ランク付けを行うことも可能である。最も重要度の高い符号化済みスライス並びにデータ・パーティションはそれらの復号化順序が示す順序よりも前に送ることができるのに対して、主観的に最も重要度の低い符号化済みスライスおよびデータ・パーティションをそれらの自然な符号化順序が示すよりも後に送ることができる。したがって、最も重要度の低いデータ・パーティションと比べて、最も重要なスライスおよびデータ・パーティションの任意の再送済み部分の方が、該部分のスケジュールされた復号化時刻よりも前に受信される可能性がより大きくなる。

本発明によって、復号化順序からデータの送信を行うことが有利なビデオ通信方式において、送信順序から復号化順序へのビデオデータの再順序化が可能となる。

本発明では、復号化順序のシグナリングが送信機から受信機へ伝えられる。このシグナリングは、ＪＶＴ符号化規格におけるフレーム番号のような、復号化順序の回復に利用可能なビデオビットストリーム内での任意のシグナリングに対する相補シグナリングまたは置換シグナリングであってもよい。

ＪＶＴ符号化規格におけるフレーム番号に従う相補シグナリングを以下に示す。本明細書では以後、復号化順にＩＤＲピクチャ（このピクチャを含む）から次のＩＤＲピクチャ（このピクチャを除く）までのピクチャから独立ＧＯＰを構成するものとする。ビットストリーム内の個々のＮＡＬユニットは、独立ＧＯＰ内のすべてのＮＡＬユニットに対して不変の状態のままであるビデオシーケンスＩＤを含むか、該ビデオシーケンスＩＤと関連づけられる。

独立ＧＯＰのビデオシーケンスＩＤは、復号化順序に関して前回の独立ＧＯＰのビデオシーケンスＩＤとは自由に異なるものである。あるいは上記独立ＧＯＰのビデオシーケンスＩＤは、前回のビデオシーケンスＩＤと比べて（モジュロ演算で）増分される。前者の場合、独立ＧＯＰの復号化の順序は独立ＧＯＰの受信順序によって決定される。例えば、最小のＲＴＰシーケンス番号を持つＩＤＲピクチャから始まる独立ＧＯＰが第１に復号化される。後者の場合、独立ＧＯＰはビデオシーケンスＩＤの昇順に復号化される。

以下の説明では、エンコーダ・デコーダベースのシステムを用いることにより、本発明について説明するが、ビデオ信号が格納されるシステムおいても本発明が実現可能であることは自明である。格納されるビデオ信号は、符号化後に格納される符号化信号同様、符号化前に格納される未符号化信号か、符号化処理および復号化処理後に格納される復号化信号かのいずれかの信号とすることができる。例えば、エンコーダは復号化順にビットストリームを生成する。ファイルシステムはオーディオビットストリームおよび／またはビデオビットストリームを受け取り、これらのビットストリームを復号化順にカプセル化し、ファイルとして格納する。さらに、エンコーダおよびファイルシステムはメタデータの生成が可能であり、このメタデータは、ピクチャとＮＡＬユニットとの主観的重要度を知らせ、特にサブシーケンスに関する情報を含むものである。上記ファイルはデータベースの中へ格納することが可能であり、このデータベースから、再生用サーバがＮＡＬユニットを直接読み取り、これらのＮＡＬユニットをＲＴＰパケットの中へカプセル化することが可能である。使用中のオプションのメタデータおよびデータ接続に従って、再生用サーバは、パケットの送信順序を復号化の順序とは異なる順序に変更し、サブシーケンスを取り除き、もし何らかのＳＥＩメッセージが存在すれば、どのようなＳＥＩメッセージを送信するかを決定するかの決定を行うことができる。受信端では、ＲＴＰパケットが受信され、バッファされる。典型的には、ＮＡＬユニットが正しい順序でまず再順序化され、その後、ＮＡＬユニットはデコーダへ配信される。

Ｈ．２６４規格に準拠して、ＶＣＬ＿ＮＡＬユニットは、１〜５（５を含む）に等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを持つ当該ＮＡＬユニットとして指定される。この規格では、ＮＡＬユニットタイプ１〜５は以下のように定義される：
１．非ＩＤＲピクチャの符号化済みスライス
２．符号化済みスライスデータ・パーティションＡ
３．符号化済みスライスデータ・パーティションＢ
４．符号化済みスライスデータ・パーティションＣ
５．ＩＤＲピクチャの符号化済みスライス

本発明の好適な実施形態に従って、ビデオビットストリームでの任意の復号化順序情報への置換シグナリングを以下に示す。復号化順序番号（ＤＯＮ）は、ＮＡＬユニットの復号化順序、すなわちデコーダへのＮＡＬユニットの送出順序を示す。本明細書では以後、ＤＯＮは、一般性を失うことなく、１６ビットの無符号の整数をとるものと仮定する。１つのＮＡＬユニットのＤＯＮをＤ１とし、別のＮＡＬユニットのＤＯＮをＤ２とする。Ｄ１＜Ｄ２でかつＤ２−Ｄ１＜３２７６８、または、Ｄ１＞Ｄ２でかつＤ１−Ｄ２≧３２７６８ならば、Ｄ１に等しいＤＯＮを持つＮＡＬユニットは、ＮＡＬユニットの送出順序でＤ２に等しいＤＯＮを持つＮＡＬユニットに先行する。Ｄ１＜Ｄ２でかつＤ２−Ｄ１≧３２７６８、または、Ｄ１＞Ｄ２でかつＤ１−Ｄ２＜３２７６８ならば、Ｄ２に等しいＤＯＮを持つＮＡＬユニットは、ＮＡＬユニットの送出順序でＤ１に等しいＤＯＮを持つＮＡＬユニットに先行する。異なる主要符号化済みピクチャと関連づけられたＮＡＬユニットは同じＤＯＮ値を持たない。同じ主要符号化済みピクチャと関連づけられたＮＡＬユニットは同じＤＯＮ値を持つものであってもよい。主要符号化済みピクチャのすべてのＮＡＬユニットが同じＤＯＮ値を持てば、主要符号化済みピクチャと関連づけられる冗長符号化済みピクチャのＮＡＬユニットは、主要符号化済みピクチャのＮＡＬユニットとは異なるＤＯＮ値を持つことができる。例えば、同じＤＯＮ値を持つＮＡＬユニットのＮＡＬユニット送出順序は以下のようにすることができる：
１． ピクチャ・デリミタＮＡＬユニット（存在する場合）
２． シーケンスパラメータセットＮＡＬユニット（存在する場合）
３． ピクチャパラメータセットＮＡＬユニット（存在する場合）
４． ＳＥＩ＿ＮＡＬＵユニット（存在する場合）
５． 符号化済みスライスおよび主要符号化済みピクチャのスライスデータ・パーティションＮＡＬユニット（存在する場合）
６． 符号化済みスライスおよび冗長符号化済みピクチャのスライスデータ・パーティションＮＡＬユニット（存在する場合）
７． フィラデータＮＡＬユニット（存在する場合）
８． シーケンスＮＡＬユニットの終端部（存在する場合）
９． ストリームＮＡＬユニットの終端部（存在する場合）

本発明の第１の態様によれば、符号化ステップにおいて、ピクチャＩＤから分離されたビデオシーケンスＩＤを符号化済みピクチャに対して定義することを主たる特徴とする方法が提供される。

本発明の第２の態様によれば、ピクチャを符号化するための、並びに、符号化済みピクチャの順序付けを行うためのエンコーダであって、上記符号化済みピクチャからなる少なくとも１つのピクチャグループを形成し、上記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義する構成装置（ａｒｒａｎｇｅｒ）を具備するエンコーダにおいて、上記符号化済みピクチャ用の上記ピクチャＩＤから分離されたビデオシーケンスＩＤを定義する定義装置（ｄｅｆｉｎｅｒ）をさらに具備し、上記ビデオシーケンスＩＤが、同じピクチャグループの個々のピクチャに対して同一となるように構成されるエンコーダが提供される。

本発明の第３の態様によれば、復号化済みピクチャを形成するための、上記符号化済みピクチャ用デコーダであって、復号化順に上記符号化済みピクチャを構成する再構成装置（ｒｅａｒｒａｎｇｅｒ）を具備するデコーダにおいて、どのピクチャが同じピクチャグループに属するかを上記ビデオシーケンスＩＤによって決定するプロセッサをさらに具備するデコーダが提供される。

本発明の第４の態様によれば、符号化済みピクチャの順序付けを行う方法を実行する機械で実行可能なステップを具備するソフトウェアプログラムであって、上記方法が、エンコーダにおいて符号化済みピクチャを形成するための符号化ステップであって、少なくとも１つのピクチャグループを形成し、上記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義する符号化ステップと、上記符号化済みピクチャをデコーダへ送信する送信ステップと、上記符号化済みピクチャを復号化順に構成する再構成ステップとから成るソフトウェアプログラムにおいて、上記符号化ステップにおいて、上記ピクチャＩＤから分離されたビデオシーケンスＩＤを上記符号化済みピクチャに対して定義するソフトウェアプログラムが提供される。

本発明の第５の態様によれば、符号化済みピクチャを含む信号であって、少なくとも１つのピクチャグループを上記符号化済みピクチャから形成し、上記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義するように成す信号において、上記ピクチャＩＤから分離されたビデオシーケンスＩＤを上記符号化済みピクチャに対して上記信号で定義し、上記ビデオシーケンスＩＤが同じピクチャグループの個々のピクチャに対して同一となるように成す信号が出力される。

本発明の第６の態様によれば、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法であって、上記第１の符号化済みピクチャに基づいて少なくとも第１の送信単位を形成し、上記第２の符号化済みピクチャに基づいて少なくとも第２の送信単位を形成し、上記第１の送信単位に対して第１の識別子を定義し、次いで、上記第２の送信単位に対して第２の識別子を定義し、上記第１および上記第２の識別子が、上記第１の送信単位に含まれる情報、並びに、上記第２の送信単位に含まれる情報のそれぞれの復号化順序を示すように成す方法が提供される。

本発明の第７の態様によれば、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う装置であって、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を備えた装置において、上記第１の送信単位に対しては第１の識別子を定義し、上記第２の送信単位に対しては第２の識別子を定義する定義装置をさらに具備し、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように成す装置が提供される。

本発明の第８の態様によれば、ピクチャを符号化し、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行うエンコーダであって、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを対象とする構成装置を具備するエンコーダにおいて、上記第１の送信単位用の第１の識別子と、上記第２の送信単位用の第２の識別子とを対象とする定義装置をさらに具備し、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すエンコーダが提供される。

本発明の第９の態様によれば、復号化済みピクチャを形成するために上記符号化済みピクチャを復号化するデコーダであって、上記符号化済みピクチャが、上記第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位で、並びに、上記第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位で送信される第１および第２の符号化済みピクチャを具備するデコーダにおいて、上記第１の送信単位に対して定義された第１の識別子と、上記第２の送信単位に対して定義された第２の識別子とに基づいて、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報との復号化順序を決定するプロセッサをさらに具備するデコーダが提供される。

本発明の第１０の態様によれば、第１および第２の符号化済みピクチャを含むピクチャを符号化し、符号化済みピクチャの順序付けを行うエンコーダであって、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を具備するエンコーダと、上記符号化済みピクチャを復号化するデコーダと、を具備するシステムであって、上記第１の送信単位用の第１の識別子並びに上記第２の送信単位用の第２の識別子であって、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示す上記第１と第２の識別子とを定義する定義装置を上記エンコーダの中に具備するシステムにおいて、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報との復号化順序を上記第１の識別子および上記第２の識別子に基づいて決定するプロセッサを上記デコーダの中にさらに具備するシステムが提供される。

本発明の第１１の態様によれば、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法を実行し、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する機械で実行可能なステップを含むコンピュータプログラムであって、上記第１の送信単位用の第１の識別子と、上記第２の送信単位用の第２の識別子とを定義する機械で実行可能なステップを含むコンピュータプログラムにおいて、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すコンピュータプログラムが提供される。

本発明の第１２の態様によれば、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法を実行し、さらに、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する機械で実行可能なステップを含むコンピュータプログラムを格納するコンピュータプログラム製品であって、上記コンピュータプログラムが、上記第１の送信単位用の第１の識別子と、上記第２の送信単位用の第２の識別子とを定義する機械で実行可能なステップをさらに含み、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように構成されるコンピュータプログラム製品が提供される。

本発明の第１３の態様によれば、第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位と、第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位とを含む信号であって、上記第１の送信単位用として第１の定義された識別子と、上記第２の送信単位用として定義された第２の識別子とをさらに含む信号において、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すようにする信号が出力される。

本発明の第１４の態様によれば、送信用の符号化済みピクチャであって、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行うモジュールであって、上記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、上記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を具備するモジュールにおいて、上記第１の送信単位用の第１の識別子と、上記第２の送信単位用の第２の識別子とを定義する定義装置をさらに具備し、上記第１および第２の識別子が、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように構成されるモジュールが提供される。

本発明の第１５の態様によれば、復号化のために符号化済みピクチャを再順序化するモジュールであって、上記符号化済みピクチャが第１および第２の符号化済みピクチャを含み、上記第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位で、並びに、上記第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位で上記符号化済みピクチャを送信するように成すモジュールにおいて、上記第１の送信単位用の第１の定義された識別子と、上記第２の送信単位用の第２の定義された識別子とに基づいて、上記第１の送信単位に含まれる情報と、上記第２の送信単位に含まれる情報との復号化順序を決定するプロセッサをさらに具備するモジュールが提供される。

本発明は符号化システムの信頼性を改善するものである。本発明を利用することにより、たとえビデオストリームのいくつかのパケットがデコーダで利用できなくなった場合であっても、従来技術によるシステムの場合よりも高い信頼性でピクチャの正しい復号化順序を決定することが可能となる。

以下、図８のシステムと、図９のエンコーダ１およびオプションの仮想基準デコーダ（ＨＲＤ）５と、図１０のデコーダ２とを参照しながら本発明についてさらに詳細に説明する。例えば、符号化対象ピクチャはカメラ、ビデオレコーダなどのビデオソース３から得られるビデオストリームのピクチャであってもよい。ビデオストリームのピクチャ（フレーム）はスライスなどのさらに小さな部分に分けることができる。スライスはさらにブロックに分割することができる。エンコーダ１では、ビデオストリームが符号化されて、情報が減らされ、送信チャネル４を介して送信されたり、記憶媒体（図示せず）へ送信されたりする。ビデオストリームのピクチャはエンコーダ１へ入力される。エンコーダは、符号化対象ピクチャのいくつかを一時的に記憶する符号化用バッファ１．１（図９）を備えている。エンコーダ１はメモリ１．３およびプロセッサ１．２も備え、本発明に基づく符号化タスクを行うことができる。メモリ１．３とプロセッサ１．２とは送信装置６に対して共通のものであってもよい。あるいは送信装置６は、送信装置６の別の機能のための別のプロセッサおよび／またはメモリ（図示せず）を備えたものであってもよい。エンコーダ１は動き予測および／または何らかの別のタスクを実行して、ビデオストリームの圧縮を行う。符号化対象ピクチャ（現在の画像）間の動き予測における類似性に関して以前および／または以後のピクチャの探索が行われる。類似性が発見された場合、符号化対象ピクチャの基準ピクチャとして比較済みピクチャまたはピクチャの一部を利用することができる。ＪＶＴでは、ピクチャの表示順序および復号化順序は必ずしも同じであるとはかぎらず、ピクチャが基準ピクチャとして使用される限り、基準ピクチャをバッファ（符号化用バッファ１．１など）に格納する必要がある。エンコーダ１はピクチャの表示順序に関する情報も送信ストリームの中へ挿入する。実際には、時間情報ＳＥＩメッセージか、ＪＶＴシンタックス（ＲＴＰタイムスタンプなど）の外部のタイムスタンプかのいずれかの利用が可能である。

必要に応じて符号化済みピクチャは符号化処理から符号化済みピクチャバッファ１．２へ移動される。符号化済みピクチャは送信チャネル４を介してエンコーダ１からデコーダ２へ送信される。デコーダ２では、符号化済みピクチャが復号化され、符号化済みピクチャに対応する未圧縮ピクチャが可能なかぎり形成される。個々の復号化ピクチャは、個々の復号化ピクチャが復号化のほぼ直後に表示されない限り、また、基準ピクチャとして使用されない限り、デコーダ２の復号化ピクチャバッファ（ＤＰＢ）２．１にバッファされる。本発明に準拠するシステムでは、基準用ピクチャバッファリングと表示ピクチャバッファリングの双方が組み合わされ、同じ復号化ピクチャバッファ２．１を使用する。これによって、２つの異なる場所に同じピクチャを格納する必要がなくなり、したがって、デコーダ２の必要メモリが減ることになる。

デコーダ１もメモリ２．３とプロセッサ２．２とを備え、これらメモリ２．３とプロセッサ２．２において本発明に基づく復号化タスクの実行が可能となる。メモリ２．３とプロセッサ２．２とは受信装置８に対して共通のものであってもよいし、あるいは受信装置８の別の機能用として別のプロセッサおよび／またはメモリ（図示せず）を備えたものであってもよい。

ＲＴＰパケットのペイロードフォーマットは、必要に応じて複数の異なるペイロード構造として定義される。しかし、受信したＲＴＰパケットがどの構造を含むかはペイロードの第１のバイトから明らかである。このバイトは常にＮＡＬユニットのヘッダとして構造化される。ＮＡＬユニットタイプフィールドは、どの構造が存在しているかを示すものである。可能な構造として、単一ＮＡＬユニットパケット、アグリゲーションパケット（総計パケット）および断片化ユニットがある。単一ＮＡＬユニットパケットはペイロード内に単一ＮＡＬユニットのみを含む。ＮＡＬヘッダタイプフィールドは、最初のＮＡＬユニットタイプに等しくなる。すなわち、１〜２３（２３を含む）の範囲にある。アグリゲーションパケットタイプを利用してマルチＮＡＬユニットが総計され、単一のＲＴＰペイロードにされる。このパケットは、４つのバージョンすなわち、シングルタイム・アグリゲーションパケットタイプＡ（ＳＴＡＰ−Ａ）、シングルタイム・アグリゲーションパケットタイプＢ（ＳＴＡＰ−Ｂ）、１６ビットオフセット値（ＭＴＡＰ１６）を持つマルチタイム・アグリゲーションパケット（ＭＴＡＰ）および２４ビットオフセット値（ＭＴＡＰ２４）を持つマルチタイム・アグリゲーションパケット（ＭＴＡＰ）の形で存在する。ＳＴＡＰ−Ａ、ＳＴＡＰ−Ｂ、ＭＴＡＰ１６、ＭＴＡＰ２４に対して割り当てられるＮＡＬユニットタイプ番号はそれぞれ、２４、２５、２６、２７である。断片化ユニットを利用してマルチＲＴＰパケットにわたって単一ＮＡＬユニットの断片化が行われる。断片化ユニットはＮＡＬユニットタイプ番号２８と２９とによって特定される２つのバージョンと共に存在する。

ＲＴＰパケット送信用として定義される３つのケースのパケット化モードが存在する：
・ 単一ＮＡＬユニットモード
・ 非インタリーブモード
・ インタリーブモード

単一ＮＡＬユニットモードは、ＩＴ−ＵＴ勧告Ｈ．２４１に準拠する会話型システムをターゲットとするものである。非インタリーブモードは、ＩＴ−ＵＴ勧告Ｈ．２４１に準拠しなくてもよい会話型システムをターゲットとするものである。非インタリーブモードでは、ＮＡＬユニットはＮＡＬユニットの復号化順に送信される。インタリーブモードは非常に短いエンドツーエンド待ち時間を必要としないシステムをターゲットとするものである。このインタリーブモードによってＮＡＬユニットの復号化順序からＮＡＬユニットへの送信が可能となる。

オプションのパケット化−モードＭＩＭＥパラメータあるいは外部手段によって使用中のパケット化モードを信号で送信してもよい。使用するパケット化モードによって、どのＮＡＬユニットタイプがＲＴＰペイロードで許されるかが決定される。

インタリーブパケット化モードでは、ＮＡＬユニットの送信順序をＮＡＬユニットの復号化順序とは異なるものにすることが許される。復号化順序番号（ＤＯＮ）はペイロード構造内のフィールドあるいはＮＡＬユニットの復号化順序を示す導出変数である。

送信順序および復号化順序の結合は以下のように、オプションのインタリービング・デプスＭＩＭＥパラメータによって制御される。オプションのインタリービング・デプスＭＩＭＥパラメータの値が０に等しいとき、ＮＡＬユニットの復号化順序からのＮＡＬユニットの送信は禁じられており、ＮＡＬユニットの送信順序はＮＡＬユニットの復号化順序に従うことになる。オプションのインタリービング・デプスＭＩＭＥパラメータの値が０よりも大きいとき、またはそれらの復号化順序からのＮＡＬユニットの送信が特に許されるとき、
・ マルチタイム・アグリゲーションパケット１６（ＭＴＡＰ１６）およびマルチタイム・アグリゲーションパケット２４（ＭＴＡＰ２４）内でのＮＡＬユニットの順序は、ＮＡＬユニットの復号化順序では不要となる。
・ ２つの連続するパケット内のシングルタイム・アグリゲーションパケットＢ（ＳＴＡＰ−Ｂ）、ＭＴＡＰおよび断片化ユニットＢ（ＦＵ−Ｂ）のカプセル開放を行うことにより構成されるＮＡＬユニットの順序は、ＮＡＬユニットの復号化順序では不要となる。

単一ＮＡＬユニットパケット用のＲＴＰペイロード構造（ＳＴＡＰ−ＡおよびＦＵ−Ａ）にはＤＯＮは含まれない。ＳＴＡＰ−ＢおよびＦＵ−Ｂ構造にはＤＯＮが含まれ、ＭＴＡＰの構造によってＤＯＮの導出が可能となる。

送信機がパケット毎に１つのＮＡＬユニットをカプセル化し、パケットの復号化順序からパケットの送信を望む場合、ＳＴＡＰ−Ｂパケットタイプの利用が可能となる。

単一ＮＡＬユニットパケット化モードでは、ＮＡＬユニットの送信順序はそれらのＮＡＬユニットの復号化順序と同じである。非インタリーブパケット化モードでは、単一ＮＡＬユニットパケットとＳＴＡＰ−Ａ並びにＦＵ−ＡにおけるＮＡＬユニットの送信順序はそれらのＮＡＬユニットの復号化順序と同じである。ＳＴＡＰ内のＮＡＬユニットはＮＡＬユニットの復号化順に出現する。

Ｈ．２６４が表示順序とは異なる復号化順序を可能にするという事実に起因して、ＲＴＰタイムスタンプの値は、ＲＴＰシーケンス番号の関数として単調に非減少するものでなくてもよい。

送信順序での第１のＮＡＬユニットのＤＯＮ値は任意の値に設定してもよい。ＤＯＮ値は０〜６５５３５（６５５３５を含む）の範囲内に存在する。最大値に達した後ＤＯＮ値は０までラップアラウンドする。

任意のＳＴＡＰ−Ｂ、ＭＴＡＰあるいはＦＵ−Ｂから始まる一連の断片化ユニットに含まれる２つのＮＡＬユニットの復号化順序は以下のように決定される。一方のＮＡＬユニットのＤＯＮ値をＤ１とし、次いで、他方のＮＡＬユニットのＤＯＮ値をＤ２とする。Ｄ１がＤ２に等しければ、２つのＮＡＬユニットのＮＡＬユニットの復号化順序はいずれであってもよい。Ｄ１＜Ｄ２でかつＤ２−Ｄ１＜３２７６８、または、Ｄ１＞Ｄ２でかつＤ１−Ｄ２≧３２７６８ならば、Ｄ１に等しいＤＯＮ値を持つＮＡＬユニットは、ＮＡＬユニットの復号化順にＤ２に等しいＤＯＮ値を持つＮＡＬユニットに先行する。Ｄ１＜Ｄ２でかつＤ２−Ｄ１≧３２７６８、または、Ｄ１＞Ｄ２でかつＤ１−Ｄ２＜３２７６８ならば、Ｄ２に等しいＤＯＮ値を持つＮＡＬユニットはＮＡＬユニットの復号化順にＤ１に等しいＤＯＮ値を持つＮＡＬユニットに先行する。ＤＯＮ関連フィールドの値は、上記に指定したようなＤＯＮ値によって決定される復号化順序がＮＡＬユニットの復号化順序に従うような値をとる。ＮＡＬユニットストリーム内の２つの連続するＮＡＬユニットの順序が切り替えられ、それでもまだ新たな順序がＮＡＬユニットの復号化順序に従う場合、ＮＡＬユニットは同じＤＯＮ値を持つことができる。例えば、使用中のビデオ符号化プロファイルによって任意のスライス順序が許されるとき、符号化ピクチャのすべての符号化済みスライスＮＡＬユニットは同じＤＯＮ値を持つことを許される。したがって、同じＤＯＮ値を持つＮＡＬユニットの任意の順序での復号化が可能となり、上記指定した順序で異なるＤＯＮ値を持つ２つのＮＡＬユニットをデコーダへ渡すことが望ましいことになる。ＮＡＬユニットの復号化順序で２つの連続するＮＡＬユニットが異なるＤＯＮ値を持つとき、復号化順に第２のＮＡＬユニットに対するＤＯＮ値は、復号化順に１だけ増分される、第１のＮＡＬユニットに対するＤＯＮ値となることが望ましい。受信機は、エラーのない送信の場合でも、２つの連続するＮＡＬユニットに対するＤＯＮ値の絶対差がＮＡＬユニットの復号化順序で１に等しくなると予想すべきではない。１の増分値は必要ではない。というのは、ＤＯＮ値がＮＡＬユニットと関連づけられる時点で、すべてのＮＡＬユニットが受信機へ配信されたかどうかがわからない場合があるからである。例えば、ゲートウェイは、パケットの転送先であるネットワークにおいてビットレートが不足すると、非基準用ピクチャの符号化済みスライスＮＡＬユニットやＳＥＩ＿ＮＡＬＵユニットを転送しない場合もある。別の例では、ライブの放送がコマーシャルなどの予め符号化されたコンテンツによって時々中断されることがある。予め符号化されたクリップの第１のイントラピクチャが予め送信され、該イントラピクチャが受信機ですぐに利用可能となることが保証される。第１のイントラピクチャの送信時点で、予め符号化されたクリップの第１のイントラピクチャが復号化順に後続するまで、発信者は符号化の対象となるＮＡＬユニットの個数を正確には知らない。したがって、予め符号化されたクリップの第１のイントラピクチャのＮＡＬユニットに対するＤＯＮ値をこれらの値を送信する時点で推定する必要があり、ＤＯＮ値の空隙が生じる可能性がある。

符号化
次に、符号化／復号化処理についてさらに詳細に考えることにしよう。ビデオソース３から得られるピクチャがエンコーダ１へ入力され、好適にはプレエンコーディング用（ｐｒｅ−ｅｎｃｏｄｉｎｇ）バッファ１．１に格納される。符号化処理は必ずしも第１のピクチャがエンコーダへ入力された直後に開始されるとはかぎらず、或る一定量のピクチャが符号化用バッファ１．１で利用可能になった後に開始されることもある。次いで、エンコーダ１は、基準フレームとして利用するためにエンコーダ１はピクチャから適切な候補を発見しようと試みる。次いで、エンコーダ１は符号化済みピクチャを形成するために符号化を実行する。例えば、符号化済みピクチャは、予測ピクチャ（Ｐ）、双予測ピクチャ（Ｂ）および／またはイントラ符号化ピクチャ（Ｉ）となる可能性がある。他のいずれのピクチャも用いることなく、イントラ符号化ピクチャの復号化を行うことも可能ではあるが、別のタイプのピクチャでは、それらのピクチャの復号化が可能になる前に少なくとも１つの基準ピクチャが必要となる。上述のピクチャタイプのうちのいずれかのピクチャは基準ピクチャとして使用することができる。

エンコーダは、好適には、２つのタイムスタンプ、すなわち復号化用タイムスタンプ（ＤＴＳ）と出力用タイムスタンプ（ＯＴＳ）とをピクチャに付けることが望ましい。デコーダはこれらのタイムスタンプを利用して、正しい復号化タイムおよびタイム出力（表示）ピクチャを決定することができる。しかし、これらのタイムスタンプは必ずしもデコーダへ送信されるとはかぎらず、また、デコーダがこれらのタイムスタンプを利用しない場合もある。

エンコーダはまた最下位層０の上方の１または２以上の層上にサブシーケンスも形成する。層０上のサブシーケンスは、独立に復号化が可能であるが、上位層上のピクチャはいくつかの低位層または複数の層上のピクチャに依存する場合もある。図６ａの例では２つの層、層０と層１とが存在する。ピクチャＩ０、Ｐ６およびＰ１２は層０に属し、一方、図６ａに図示の別のピクチャＰ１〜Ｐ５、Ｐ７〜Ｐ１１は層１に属する。好適には、エンコーダがピクチャグループ（ＧＯＰ）を形成し、同じＧＯＰ内の唯一のピクチャを用いることにより１つのＧＯＰの個々のピクチャを再構成できるようにすることが望ましい。換言すれば、１つのＧＯＰには少なくとも１つの独立に復号化可能なピクチャ、並びに、その他すべてのピクチャが含まれ、その他すべてのピクチャに対して上記独立に復号化が可能なピクチャは、基準ピクチャのチェーンの形で基準ピクチャまたは第１の基準ピクチャとなる。図７の例では、２つの独立ピクチャグループが存在する。第１の独立ピクチャグループは、層０上にピクチャＩ０（０）、Ｐ１（０）、Ｐ３（０）を含み、層１上にピクチャＢ２（０）、２ｘＢ３（０）、Ｂ４（０）、２ｘＢ５（０）、Ｂ６（０）、Ｐ５（０）、Ｐ６（０）を含む。第２の独立ピクチャグループは層０上にピクチャＩ０（１）とＰ１（１）とを含み、層１上にピクチャ２ｘＢ３（１）とＢ２（１）とを含む。個々の独立ピクチャグループからなる層１上のピクチャはサブシーケンスとしてさらに構成される。第１の独立ピクチャグループの第１のサブシーケンスは、ピクチャＢ３（０）、Ｂ２（０）、Ｂ３（０）を含み、第２のサブシーケンスはピクチャＢ５（０）、Ｂ４（０）、Ｂ５（０）を含み、第３のサブシーケンスはピクチャＢ６（０）、Ｐ５（０）、Ｐ６（０）を含む。第２の独立ピクチャグループのサブシーケンスはピクチャＢ３（１）、Ｂ２（１）、Ｂ３（１）を含む。括弧内の数字は当該ピクチャが属する独立ピクチャグループに対して定義されるビデオシーケンスＩＤを示す。

ビデオシーケンスＩＤは個々のピクチャ用として転送される。補足拡張機能情報データでの場合のように、ビデオビットストリーム内でビデオシーケンスＩＤを送ることができる。ＪＶＴ符号化規格のＲＴＰペイロードヘッダでの場合のように、トランスポートプロトコルのヘッダフィールドの形でもビデオシーケンスＩＤを送信することができる。ＭＰＥＧ−４ＡＶＣファイルフォーマットの場合のように、上記提示した独立ＧＯＰへのパーティションに基づいてビデオシーケンスＩＤをビデオファイルフォーマットのメタデータに格納することができる。

ビデオビットストリームにおける復号化順序情報の別の好適なシグナリング方法を以下手短に開示する。エンコーダは復号化順序番号（ＤＯＮ）を０などの適切な初期値に初期化する。ラップアラウンドを用いる増加番号方式は本方法では或る一定の最大値をとるものと仮定する。例えば、復号化順序番号が１６ビットの無符号の整数であれば、最大値は６５５３５となる。エンコーダは個々の主要符号化済みピクチャから１または２以上のＮＡＬユニットを形成する。エンコーダは同じピクチャの個々のＮＡＬユニットに対して同じ復号化順序番号を定義することが可能であり、冗長符号化済みピクチャ（上位層でのサブシーケンス）が存在する場合、エンコーダは、当該冗長符号化済みピクチャのＮＡＬユニット用として異なるＤＯＮを割り当てることができる。主要符号化済みピクチャ全体および該ピクチャの生じる可能性のある冗長符号化済みピクチャを符号化するとき、エンコーダは、復号化順に次の主要符号化済みピクチャの処理を開始する。復号化順序番号の値が上記最大値よりも小さければ、エンコーダは復号化順序番号を１だけ増分することが望ましい。復号化順序番号が最大値を持つ場合、エンコーダは復号化順序番値を最小値（好適には０）にセットする。次いで、エンコーダは上記次の主要符号化済みピクチャからＮＡＬユニットを形成し、復号化順序番号の現在値を割り当てる。それぞれ別々に、同じ主要符号化済みピクチャの任意の冗長符号化済みピクチャが存在する場合、それらのピクチャもＮＡＬユニットに変換される。すべての主要符号化済みピクチャ並びにそれぞれの冗長符号化済みピクチャが何か存在する場合、処理は、それらのピクチャが処理されるまで続く。送信装置は、すべてのピクチャが処理される前にＮＡＬユニットの送信を開始することができる。

遠端デコーダが任意の順序（すなわちラスタスキャンの順序からの順序）で受信スライスを処理する能力がないことがエンコーダによって認知された場合、エンコーダは、主要符号化済みピクチャの個々のスライスに対してラスタスキャン順にＤＯＮの昇順値を割り当てることが望ましい。すなわち、単一ＮＡＬユニットの形でスライスが送信された場合、個々の連続するＮＡＬユニットは異なるＤＯＮ値を持つことになる。スライスがデータ・パーティションＮＡＬユニットとして送信された場合、個々のデータ・パーティションスライスのＮＡＬユニットは同じＤＯＮ値の共有が可能となる。冗長符号化済みピクチャのスライスの場合、エンコーダは、対応する主要符号化済みピクチャ内の対応するスライスのＤＯＮ値よりも大きなＤＯＮ値を割り当てる。

受信機では、復号化順序番号を用いて符号化済みピクチャの正しい復号化順序を決定することができる。

図１１ａと１１ｂとは、本発明と共に用いることができるＮＡＬパケットフォーマットの例を開示するものである。このパケットにはヘッダ１１とペイロード部１２とが含まれる。ヘッダ１１は、好適にはエラー表示フィールド１１．１（Ｆ、禁止）、優先フィールド１１．２およびタイプフィールド１１．３を含むことが望ましい。エラー表示フィールド１１．１はビットエラー未使用ＮＡＬユニットを示す。好適には、エラー表示フィールドが設定されているとき、ペイロードまたはＮＡＬＵタイプ・オクテットの中にビットエラーが存在する可能性がある旨のアドバイスをデコーダが受けることが望ましい。次いで、ビットエラーの処理能力がないデコーダは上記のようなパケットを破棄することができる。パケットのペイロード部１２の中にカプセル化されたピクチャの重要度を示すために優先フィールド１１．２が用いられる。例示の実施構成では、優先フィールドは以下のように４つの異なる値を持つことができる。００の値は、（将来参照するのに利用可能な）基準ピクチャを再構成するためにＮＡＬＵの内容が用いられていないことを示す。このようなＮＡＬＵは基準ピクチャの完全性に対するリスクを伴うことなく破棄することができる。上記値００は、ＮＡＬＵの復号化が基準ピクチャの完全性の保持に必要であることを示す値である。さらに、上記値００は、エンコーダによって決定されるように、相対的トランスポート優先順位を示す値である。インテリジェントネットワークエレメントは、上記情報を用いて、より低い重要度のＮＡＬＵよりも良好な、より重要なＮＡＬＵを保護することができる。１１は最も高いトランスポート優先順位であり、その後に１０が続き、次いで０１が続き、最後に００が最も低い優先順位である。

ＮＡＬＵのペイロード部１２には、少なくともビデオシーケンスＩＤフィールド１２．１、フィールド・インジケータ１２．２、サイズフィールド１２．３、タイミングＩＮＦＯ１２．４および符号化済みピクチャ情報１２．５が含まれる。ピクチャが属するビデオシーケンスの番号を格納するためにビデオシーケンスＩＤフィールド１２．１が用いられる。２フレームピクチャフォーマットを用いる場合、フィールド・インジケータ１２．２を利用して、ピクチャが第１のフレームであるか、第２のフレームであるかが信号で送信される。別個のピクチャとして第１および第２の双方のフレームを符号化してもよい。１に等しい第１のフィールド・インジケータによって、ＮＡＬＵが符号化済みフレームに属するか、復号化順に同じフレームの第２の符号化済みフィールドに先行する符号化済みフィールドに属するかを信号で送信することが望ましい。０に等しい第１のフィールド・インジケータは、ＮＡＬＵが、復号化順に同じフレームの第１の符号化済みフィールドに後続する符号化済みフィールドに属することを信号で送信する。時間関連情報を変換するために必要に応じてタイミングＩＮＦＯフィールド１１．３が使用される。

様々な種類のパケットでＮＡＬユニットの配信を行うことが可能である。この好適な実施形態では、異なるパケットフォーマットには、簡易パケットおよびアグリゲーションパケットが含まれる。アグリゲーションパケットは、さらに、シングルタイム・アグリゲーションパケットとマルチタイム・アグリゲーションパケットとに分けることができる。

本発明に基づく簡易パケットは１つのＮＡＬＵから構成される。ＲＴＰシーケンス番号の順序でカプセル開放を行うことにより、カプセル開放用簡易パケットによって構成されるＮＡＬユニットストリームは、ＮＡＬユニットの送出順序に従うことが望ましい。

アグリゲーションパケットは上記ペイロード仕様のパケットアグリゲーション方式である。この方式が導入されるのは、非常に異なるＭＴＵサイズの２つの異なるタイプのネットワーク、すなわち、有線ＩＰネットワーク（イーサネット（登録商標）ＭＴＵサイズによって限定される場合が多いＭＴＵサイズ――ほぼ１５００バイトを持つ）、および、２５４バイト以内の好適な送信単位サイズを持つＩＰまたは非ＩＰ（例えばＨ．３２４／Ｍ）ベースの無線ネットワークを反映するようにするためである。これら２つのネットワーク世界の間でのメディアトランスコーディングを防ぐために、並びに、望ましくないパケット化オーバヘッドを避けるためにパケットアグリゲーション方式が導入される。

シングルタイム・アグリゲーションパケット（ＳＴＡＰ）は同一のＮＡＬＵタイムを持つＮＡＬＵを総計するものである。それぞれ別々に、マルチタイム・アグリゲーションパケット（ＭＴＡＰ）は潜在的に異なるＮＡＬＵタイムと共にＮＡＬＵを総計する。ＮＡＬＵタイムスタンプオフセット値の長さの点で異なる２つの異なるＭＴＡＰが定義される。ＮＡＬＵタイムという用語は、ＮＡＬＵ自身のＲＴＰパケットでＮＡＬＵをトランスポートする場合、ＲＴＰタイムスタンプがとる値として定義される。

ＭＴＡＰとＳＴＡＰとは、本発明の好適な実施形態に基づく、本発明を限定するものではない以下のパケット化規則を共有するものである。総計の対象とするすべてのＮＡＬＵのＮＡＬＵタイムの最小値にＲＴＰタイムスタンプをセット設定する必要がある。ＮＡＬＵタイプ・オクテットのタイプフィールドは表１に示すように適正な値に設定する必要がある。総計されたＮＡＬＵのすべてのエラー表示フィールドが０であれば、エラー表示フィールド１１．１を消去し、０でなければ、表示フィールド１１．１をセットする必要がある。

アグリゲーションパケットのＮＡＬＵペイロードは１または２以上のアグリゲーションユニットから構成される。アグリゲーションパケットは、必要に応じて、同数のアグリゲーションユニットを運ぶことができる。しかし、アグリゲーションパケット内の総データ量はＩＰパケットに適合させなければならないことは明らかであり、ＩＰパケットがＭＴＵサイズよりも小さくなるようにサイズを選択することが望ましい。

同じＮＡＬＵタイムを共有するＮＡＬＵを総計するときはいつでも、シングルタイム・アグリゲーションパケット（ＳＴＡＰ）を使用することが望ましい。ＳＴＡＰのＮＡＬＵペイロードは、ビデオシーケンスＩＤフィールド１２．１（７ビットなど）、および、単一ピクチャ・アグリゲーションユニット（ＳＰＡＵ）を後に伴うフィールド・インジケータ１２．２から構成される。シングルタイム・アグリゲーションパケットタイプＢ（ＳＴＡＰ−Ｂ）にはＤＯＮも含まれる。

本明細書に基づくビデオシーケンスは、ＮＡＬＵストリームの別の部分から独立に復号化できるＮＡＬＵストリームの任意の一部とすることができる。

１フレームは、別々のピクチャとして符号化できる２つのフィールドから構成される。１に等しい第１のフィールド・インジケータは、ＮＡＬＵが符号化済みフレームに属するか、または復号化順に同じフレームの第２の符号化済みフィールドに先行する符号化済みフィールドに属する旨を信号で送信する。０に等しい第１のフィールド・インジケータは、復号化順に同じフレームの第１の符号化済みフィールドに後続する符号化済みフィールドにＮＡＬＵが属する旨を信号で送信する。

シングルピクチャ・アグリゲーションユニットは、次のＮＡＬＵのサイズがバイトで示される１６ビットの無符号サイズ情報などから構成され（上記２つのオクテットは除かれるが、ＮＡＬＵのＮＡＬＵタイプ・オクテットは含まれる）、ＮＡＬＵタイプバイトを含むＮＡＬＵ自身が後続する。

マルチタイム・アグリゲーションパケット（ＭＴＡＰ）はＳＴＡＰと類似のアーキテクチャを備えたパケットである。マルチタイム・アグリゲーションパケットは、ＮＡＬＵヘッダバイトおよび１または２以上のマルチピクチャ・アグリゲーションユニットから構成される。異なるＭＴＡＰフィールド間での選択はアプリケーションに依存し、タイムスタンプオフセット値が大きければ大きいほどＭＴＡＰの適応性も高くなるが、オーバヘッドもより高くなる。

本明細書では２つの異なるマルチタイム・アグリゲーションユニットが定義される。これらユニットの双方は、次のＮＡＬＵの１６ビット無符号サイズ情報などから構成される（ＳＴＡＰの場合のサイズ情報と同じ）。これら１６ビットに加えて、ビデオシーケンスＩＤフィールド１２．１（７ビットなど）、フィールド・インジケータ１２．２およびこのＮＡＬＵに関連する時間情報のｎビットも存在する。ここでｎは１６または２４であってもよい。時間情報フィールドを設定して、ＭＴＡＰのＲＴＰタイムスタンプから時間情報を追加することにより、ＭＴＡＰ内の個々のＮＡＬＵのＲＴＰパケットのＲＴＰタイムスタンプ（ＮＡＬＵタイム）を生成できるようにする必要がある。

別の代替実施形態では、マルチタイム・アグリゲーションパケット（ＭＴＡＰ）は、ＮＡＬＵヘッダバイト、復号化順序番号ベース（ＤＯＮＢ）フィールド１２．１（１６ビットなど）、および１または２以上のマルチピクチャ・アグリゲーションユニットから構成される。この場合、２つの異なるマルチタイム・アグリゲーションユニットが以下のように定義される。これらユニットの双方は、次のＮＡＬＵの１６ビット無符号サイズ情報などから構成される（ＳＴＡＰの場合のサイズ情報と同じ）。これら１６ビットに加えて、復号化順序番号デルタ（ＤＯＮＤ）フィールド１２．５（７ビットなど）、およびこのＮＡＬＵに関連する時間情報のｎビットも存在する。ここでｎは１６または２４であってもよい。以下のＮＡＬＵのＤＯＮはＤＯＮＢ＋ＤＯＮＤに等しい。ＭＴＡＰのＲＴＰタイムスタンプから時間情報を追加することにより、ＭＴＡＰ（ＮＡＬＵタイム）内の個々のＮＡＬＵのＲＴＰパケットのＲＴＰタイムスタンプを生成できるようにフィールドを設定する必要がある。ＤＯＮＢは、ＭＴＡＰのＮＡＬユニット間のＤＯＮの最小値を含むものであってもよい。

送信
第１の符号化済みピクチャの準備ができた直後に符号化済みピクチャの送信および／または格納（オプションのバーチャルな復号化）を開始することができる。このピクチャは、必ずしもデコーダ出力順序で第１のピクチャであるとはかぎらない。というのは、復号化順序および出力順序が同じではない場合もあるからである。

ビデオストリームの第１のピクチャが符号化されると、符号化済み送信を開始することができる。符号化済みピクチャはオプションとして符号化済みピクチャバッファ１．２へ格納される。例えば、ビデオストリームの或る一定部分が符号化された後、後半の段階で送信を開始することも可能である。

例えば、ピクチャ順序カウント値の順序付けを用いることによりデコーダ２も正しい順序で復号化ピクチャの出力を行うことが望ましい。したがって再順序化処理を明瞭かつ規範的に定義する必要がある。

脱パケット化処理（ｄｅ−ｐａｃｋｅｔｉｚｉｎｇ）
脱パケット化（ｄｅ−ｐａｃｋｅｔｉｚａｔｉｏｎ）処理は実施構成に依存する。したがって、以下の説明は好適な実施構成の１例であるが発明を限定するものではない。同様に別の方式を用いることも可能である。説明したアルゴリズムに関連する最適化が可能であることが予想される。

これらの脱パケット化（ｄｅ−ｐａｃｋｅｔｉｚａｔｉｏｎ）規則の背後にある一般的コンセプトとして送信順序からＮＡＬユニットの送出順序へのＮＡＬユニットの再順序化がある。

復号化
次に、受信機８の動作について説明する。受信機８はピクチャに属するすべてのパケットを収集し、これらのパケットを合理的な順序に変える。順序の厳密さは、採用するプロファイルに依存する。受信パケットは受信用バッファ９．１（プレデコーディングバッファ）の中へ好適に格納される。受信機８は使用不可のものをすべて破棄し、残りをデコーダ２へ渡す。アグリゲーションパケットは、個々のＲＴＰパケット搬送用ＮＡＬＵの中へ上記アグリゲーションパケットのペイロードをアンロードすることにより処理される。当該ＮＡＬＵは、あたかも別々のＲＴＰパケットで受信されたかのように、アグリゲーションパケットの中で並べられた順序で処理される。

バッファに格納された個々のＮＡＬユニットの場合、ＮＡＬユニットを含んだパケットのＲＴＰシーケンス番号が好適に格納され、格納済みＮＡＬユニットと関連づけられる。さらに、ＮＡＬユニットを含んだパケットタイプ（簡易パケットまたはアグリゲーションパケット）が格納され、個々の格納済みＮＡＬユニットと関連づけられる。

本明細書では以後、ＮをＶＣＬ ＮＡＬユニットの最大量を指定するオプションのｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔパラメータ（インタリービング深さパラメータ）の値とし、該パラメータは、ＮＡＬユニットの送出順序でパケットストリーム内の任意のＶＣＬ ＮＡＬユニットに先行し、ＲＴＰシーケンス番号の順序で、若しくは、ＶＣＬ ＮＡＬユニットを含むアグリゲーションパケットの構成順序でＶＣＬ ＮＡＬユニットに後続する。パラメータが存在しない場合、０値の数値が必然的に含まれているものと考えることができる。ビデオストリーム転送セッションが初期化されると、受信機は、任意のパケットをデコーダ２へ渡す前に、少なくともＮ個のピースのＶＣＬ ＮＡＬユニットを受信用バッファ９．１の中へバッファする。

受信バッファ９．１が少なくともＮ個のＶＣＬ ＮＡＬユニットを含むとき、ＮＡＬユニットは受信バッファ９．１から除去され、バッファがＮ−１個のＶＣＬ ＮＡＬユニットを含むまで以下に指定する順序でデコーダ２へ渡される。

本明細書では以後、ＰＶＳＩＤを、デコーダへ渡された最新のＮＡＬユニットのビデオシーケンスＩＤ（ＶＳＩＤ）とする。ＳＴＡＰ内のすべてのＮＡＬユニットは同じＶＳＩＤを共有する。ＮＡＬユニットがデコーダへ渡される順序は以下のように指定される：バッファ内の最も古いＲＴＰシーケンス番号が簡易パケットに対応すれば、簡易パケット内のＮＡＬＵはＮＡＬユニットの送出順序で次のＮＡＬＵである。バッファ内の最も古いＲＴＰシーケンス番号がアグリゲーションパケットに対応すれば、ＮＡＬユニットの送出順序は、ＲＴＰシーケンス番号順にアグリゲーションパケットで送信されるＮＡＬＵ間で次の簡易パケット（このパケットを除く）まで回復される。本明細書では以後、このセットのＮＡＬＵを候補ＮＡＬＵと呼ぶ。バッファ内に存在する簡易パケットでＮＡＬＵが送信されない場合、すべてのＮＡＬＵは候補ＮＡＬＵに属する。

候補ＮＡＬＵの間個々のＮＡＬユニットの場合、ＶＳＩＤの距離は以下のように計算される。ＮＡＬユニットのＶＳＩＤがＰＶＳＩＤよりも大きければ、ＶＳＩＤの距離はＶＳＩＤ−ＰＶＳＩＤに等しい。ＮＡＬユニットのＶＳＩＤがＰＶＳＩＤよりも大きくなければ、ＶＳＩＤの距離は２＾（ＶＳＩＤを信号で送るのに用いるビット数）−ＰＶＳＩＤ＋ＶＳＩＤに等しくい。ＮＡＬユニットはＶＳＩＤの距離の昇順にデコーダへ配信される。いくつかのＮＡＬユニットが同じＶＳＩＤの距離を共有する場合、デコーダへＮＡＬユニットを渡す順序は本明細書ではＮＡＬユニットの送出順序に従うものとする。ＮＡＬユニットの送出順序は以下に記載のように回復することができる。

上記では、用語ＰＶＳＩＤとＶＳＩＤとを使用した。用語ＰＤＯＮ（ＮＡＬユニットの送出順序での、アグリゲーションパケットの前回のＮＡＬユニットの復号化順序番号）とＤＯＮ（復号化順序番号）とを代わりに使用できることは言うまでもない。

第１に、スライスとデータ・パーティションが、それらのフレーム番号と、ＲＴＰタイムスタンプと、第１のフィールドフラグとに従ってピクチャと関連づけられ、フレーム番号、ＲＴＰタイムスタンプおよび第１のフィールドフラグの同じ値を共有するすべてのＮＡＬＵは同じピクチャに属することになる。ＳＥＩ ＮＡＬＵ、シーケンスパラメータセットＮＡＬＵ、ピクチャパラメータセットＮＡＬＵ、ピクチャ・デリミタＮＡＬＵ、シーケンスＮＡＬＵの終端部、ストリームＮＡＬＵの終端部およびフィラデータＮＡＬＵは、送信順序で次のＶＣＬ ＮＡＬユニットのピクチャに属する。

第２に、ピクチャの送出順序は、ｎａｌ＿ｒｅｆ＿ｄｉｃと、フレーム番号と、第１のフィールドフラグと、個々のピクチャのＲＴＰタイムスタンプとに基づいて結論を下される。ピクチャの送出順序はフレーム番号の昇順になっている（モジュロ演算で）。いくつかのピクチャが同じ値のフレーム番号を共有する場合、０に等しいｎａｌ＿ｒｅｆ＿ｉｄｃを持つピクチャが第１に配信される。いくつかのピクチャが同じ値のフレーム番号を共有し、かつ、それらピクチャのすべてが、０に等しいｎａｌ＿ｒｅｆ＿ｄｉｃを持つ場合、ピクチャは昇順のＲＴＰタイムスタンプの順序で配信される。２つのピクチャが同じＲＴＰタイムスタンプを共有する場合、１に等しい第１のフィールドフラグを持つピクチャが第１に配信される。主要符号化済みピクチャと、対応する冗長符号化済みピクチャとは本願では１つの符号化ピクチャと考えられていることに留意されたい。

第３に、使用中のビデオデコーダが任意のスライス順序付けをサポートしていない場合、スライスの送出順序およびデータ・パーティションは、スライスヘッダのｆｉｒｓｔ＿ｍｂ＿ｉｎ＿ｓｌｉｃｅシンタックス要素の昇順になる。さらに、ＢとＣのデータ・パーティションは、対応するＡデータ・パーティションの直後に送出順序で続く。

以下の脱パケット化追加規則を用いて、操作可能なＪＶＴ脱パケット化装置（ｄｅ−ｐａｃｋｅｔｉｚｅｒ）を実現することができる：ＮＡＬＵはＪＶＴデコーダに対してＲＴＰシーケンス番号順に示される。アグリゲーションパケットで搬送されるＮＡＬＵは、アグリゲーションパケットではＮＡＬＵの順に提示される。アグリゲーションパケットのすべてのＮＡＬＵは、次のＲＴＰパケットが処理される前に処理される。

（ゲートウェイ内などの）インテリジェントＲＴＰ受信機が紛失ＤＰＡを特定できる場合もある。紛失ＤＰＡが発見された場合、ＤＰＢおよびＤＰＣパーティションの情報がＪＶＴデコーダにとって意味がないため、ゲートウェイはＤＰＢおよびＤＰＣパーティションを送信しない旨の決定を行う。このようにして、ネットワークエレメントは、無用のパケットを破棄することにより複雑なビットストリームの構文解析を行うことなく、ネットワーク負荷を減らすことができる。

インテリジェント受信機は０のＮＡＬ基準ＩＤＣを持つすべてのパケットを破棄することができる。しかし、インテリジェント受信機は、可能な場合、当該パケットを処理することが望ましい。というのは、パケットを破棄した場合、ユーザの経験が損害を受ける可能性があるからである。

ＤＰＢ２．１には複数のピクチャを格納するためのメモリの場所が含まれる。これらの場所は本説明ではフレーム格納部と呼ばれる。デコーダ２は正しい順序で受信されたピクチャの復号化を行う。この復号化を行うために、デコーダは受信済みピクチャのビデオシーケンスＩＤ情報をチェックする。エンコーダが個々の独立ピクチャグループ用としてビデオシーケンスＩＤを自由に選択した場合、デコーダは、独立ピクチャグループのピクチャを受信した順序でこれらのピクチャの復号化を行う。エンコーダが、増分（または減分）による番号付け方式を用いることにより、個々の独立ピクチャグループに対してビデオシーケンスＩＤを定義した場合、デコーダはビデオシーケンスＩＤの順序で独立ピクチャグループの復号化を行う。換言すれば、最小（または最大）のビデオシーケンスＩＤを持つ独立ピクチャグループが第１に復号化される。

本発明は、多くの種類のシステムと装置において適用が可能である。エンコーダ１とオプションとしてＨＲＤ５とを備えた送信装置６は好適には、符号化済みピクチャを送信チャネル４へ送信する送信機７も備えることが望ましい。受信装置８は符号化済みピクチャを受け取る受信機９と、デコーダ２と、復号化ピクチャを表示できる表示装置１０とを備える。送信チャネルは、例えば、陸線通信チャネルおよび／または無線通信チャネルであってもよい。送信装置と受信装置とは、本発明に基づくビデオストリームの符号化／復号化処理の制御に必要なステップを実行できる１または２以上のプロセッサ１．２、２．２も備える。したがって、本発明に準拠する方法は、主として機械で実行可能なプロセッサのステップとして実現可能である。ピクチャのバッファリングは装置のメモリ１．３、２．３で実現することができる。エンコーダのプログラムコード１．４はメモリ１．３内へ格納することができる。それぞれ別々に、デコーダのプログラムコード２．４をメモリ２．３内へ格納することができる。

再帰時間階層符号化方式の１例を示す。 一連のピクチャは、インタリーブされた態様で２または３以上の独立に符号化されたスレッドに分けられるビデオ冗長符号化と呼ばれる方式を描く。 圧縮効率の潜在的改善を図る予測構造の１例を示す。 エラー復元力の改善を図るために使用可能なイントラピクチャ延期法の１例を示す。 符号化された符号化済みビデオストリームのピクチャに対する従来技術による異なる番号付け方式を開示する。 符号化された符号化済みビデオストリームのピクチャに対する従来技術による異なる番号付け方式を開示する。 層１においてサブシーケンスを含むピクチャストリームの１例を開示する。 層１においてサブシーケンスを含む２つの独立ピクチャグループを含むピクチャストリームの１例を開示する。 異なる独立ピクチャグループのピクチャストリームの１例を開示する。 層１にサブシーケンスを含むピクチャストリームの別の例を開示する。 本発明に準拠するシステムの好適な実施形態を描く。 本発明に基づくエンコーダの好適な実施形態を描く。 本発明に基づくデコーダの好適な実施形態を描く。 本発明で使用できるＮＡＬパケット化フォーマットの１例を開示する。 本発明で使用できるＮＡＬパケットフォーマットの別の例を開示する。

Claims (28)

1. 符号化済みピクチャの順序付けを行う方法であって、エンコーダにおいて符号化済みピクチャを形成し、少なくとも１つのピクチャグループを形成し、前記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義する符号化ステップと、前記符号化済みピクチャをデコーダへ送信する送信ステップと、前記符号化済みピクチャを復号化順に構成する再構成ステップとから成る方法において、前記符号化ステップで、前記ピクチャＩＤから分離されたビデオシーケンスＩＤを前記符号化済みピクチャに対して定義する方法。
2. 前記ビデオシーケンスＩＤが同じピクチャグループの個々のピクチャに対して同一であり、前記復号化ステップで、どのピクチャが同じピクチャグループに属するかを決定するために前記ビデオシーケンスＩＤを用いるように構成される請求項１に記載の方法。
3. ２以上のピクチャグループを形成し、前記２以上のピクチャグループに対して異なるビデオシーケンスＩＤを定義する請求項１に記載の方法。
4. 前記ビデオシーケンスＩＤに基づいて前記ピクチャの復号化順序を決定する請求項３に記載の方法。
5. 前記ビデオシーケンスＩＤの復号化順序を送信層で送信し、前記ピクチャＩＤをビデオ層で送信する請求項３に記載の方法。
6. デコーダで符号化済みピクチャストリームを復号化する方法であって、前記ストリームが少なくとも１つのピクチャグループを含み、前記ピクチャグループの個々のピクチャに対してピクチャＩＤが定義されていて、前記ピクチャＩＤから分離されたビデオシーケンスＩＤを前記ピクチャグループに対して定義する方法において、前記復号化時に、どのピクチャが同じピクチャグループに属するかを決定するために前記ビデオシーケンスＩＤを用いる方法。
7. 個々のピクチャグループの１つのピクチャが、前記ビデオシーケンスＩＤを定義している独立に復号化可能なピクチャであり、少なくとも１つのサブシーケンスを前記ピクチャグループの前記ピクチャから形成し、さらに、前記サブシーケンスの個々のピクチャが同じピクチャグループの前記独立に決定可能なピクチャと同じビデオシーケンスＩＤを有する請求項６に記載の方法。
8. ピクチャを符号化するための、並びに、符号化済みピクチャの順序付けを行うためのエンコーダであって、前記符号化済みピクチャからなる少なくとも１つのピクチャグループを形成し、前記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義する構成装置（ａｒｒａｎｇｅｒ）を具備するエンコーダにおいて、前記符号化済みピクチャ用の前記ピクチャＩＤから分離されたビデオシーケンスＩＤを定義する定義装置（ｄｅｆｉｎｅｒ）をさらに具備し、前記ビデオシーケンスＩＤが、同じピクチャグループの個々のピクチャに対して同一となるように構成されるエンコーダ。
9. 復号化済みピクチャを形成するための、前記符号化済みピクチャ用デコーダであって、復号化順に前記符号化済みピクチャを構成するための再構成装置（ｒｅａｒｒａｎｇｅｒ）を具備するデコーダにおいて、どのピクチャが同じピクチャグループに属するかを前記ビデオシーケンスＩＤによって決定するプロセッサをさらに具備するデコーダ。
10. 符号化済みピクチャの順序付けを行う方法を実行する機械で実行可能なステップを具備するコンピュータプログラムであって、前記方法が、エンコーダにおいて符号化済みピクチャを形成するための符号化ステップであって、少なくとも１つのピクチャグループを形成し、前記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義する符号化ステップと、前記符号化済みピクチャをデコーダへ送信する送信ステップと、前記符号化済みピクチャを復号化順に構成する再構成ステップとから成るコンピュータプログラムにおいて、前記符号化ステップにおいて、前記ピクチャＩＤから分離されたビデオシーケンスＩＤを前記符号化済みピクチャに対して定義するコンピュータプログラム。
11. 符号化済みピクチャを含む信号であって、少なくとも１つのピクチャグループを前記符号化済みピクチャから形成し、前記ピクチャグループの個々のピクチャに対してピクチャＩＤを定義するように成す信号において、前記ピクチャＩＤから分離されたビデオシーケンスＩＤを前記符号化済みピクチャに対して前記信号で定義し、前記ビデオシーケンスＩＤが同じピクチャグループの個々のピクチャに対して同一となるように成す信号。
12. 第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法であって、前記第１の符号化済みピクチャに基づいて少なくとも第１の送信単位を形成し、前記第２の符号化済みピクチャに基づいて少なくとも第２の送信単位を形成し、前記第１の送信単位に対して第１の識別子を定義し、次いで、前記第２の送信単位に対して第２の識別子を定義し、前記第１および前記第２の識別子が、前記第１の送信単位に含まれる情報、並びに、前記第２の送信単位に含まれる情報のそれぞれの復号化順序を示すように成す方法。
13. 前記識別子が整数として定義される請求項１２に記載の方法。
14. ラップアラウンドを持つさらに大きな整数が将来の復号化順序を示す請求項１３に記載の方法。
15. 前記第１の送信単位が第１のスライスを含み、前記第２の送信単位が第２のスライスを含む請求項１２に記載の方法。
16. 第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う装置であって、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を備えた装置において、前記第１の送信単位に対しては第１の識別子を定義し、前記第２の送信単位に対しては第２の識別子を定義する定義装置をさらに具備し、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように成す装置。
17. ゲートウェイ装置である請求項１６に記載の装置。
18. 移動通信装置である請求項１６に記載の装置。
19. ストリーミングサーバである請求項１６に記載の装置。
20. ピクチャを符号化し、第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行うエンコーダであって、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを対象とする構成装置を具備するエンコーダにおいて、前記第１の送信単位用の第１の識別子と、前記第２の送信単位用の第２の識別子とを対象とする定義装置をさらに具備し、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すエンコーダ。
21. 前記構成装置が、第１のスライスを前記第１の送信単位の中へ含むように構成され、第２のスライスを前記第２の送信単位の中へ含むように構成される請求項２０に記載のエンコーダ装置。
22. 復号化済みピクチャを形成するために前記符号化済みピクチャを復号化するデコーダであって、前記符号化済みピクチャが、前記第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位で、並びに、前記第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位で送信される第１および第２の符号化済みピクチャを具備するデコーダにおいて、前記第１の送信単位に対して定義された第１の識別子と、前記第２の送信単位に対して定義された第２の識別子とに基づいて、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報との復号化順序を決定するプロセッサをさらに具備する前記デコーダ。
23. 第１および第２の符号化済みピクチャを含むピクチャを符号化し、符号化済みピクチャの順序付けを行うエンコーダであって、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を具備するエンコーダと、前記符号化済みピクチャを復号化するデコーダと、を具備するシステムであって、前記第１の送信単位用の第１の識別子並びに前記第２の送信単位用の第２の識別子であって、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示す前記第１と第２の識別子とを定義する定義装置を前記エンコーダの中に具備するシステムにおいて、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報との復号化順序を前記第１の識別子および前記第２の識別子に基づいて決定するプロセッサを前記デコーダの中にさらに具備するシステム。
24. 第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法を実行し、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する機械で実行可能なステップを含むコンピュータプログラムであって、前記第１の送信単位用の第１の識別子と、前記第２の送信単位用の第２の識別子とを定義する機械で実行可能なステップを含むコンピュータプログラムにおいて、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すコンピュータプログラム。
25. 第１および第２の符号化済みピクチャを含む符号化済みピクチャの順序付けを行う方法を実行し、さらに、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する機械で実行可能なステップを含むコンピュータプログラムを格納するコンピュータプログラム製品であって、前記コンピュータプログラムが、前記第１の送信単位用の第１の識別子と、前記第２の送信単位用の第２の識別子とを定義する機械で実行可能なステップをさらに含み、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように構成されるコンピュータプログラム製品。
26. 第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位と、第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位とを含む信号であって、前記第１の送信単位用として第１の定義された識別子と、前記第２の送信単位用として定義された第２の識別子とをさらに含む信号において、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように成す信号。
27. 第１および第２の符号化済みピクチャを含む送信用符号化済みピクチャの順序付けを行うモジュールであって、前記第１の符号化済みピクチャに基づく少なくとも第１の送信単位と、前記第２の符号化済みピクチャに基づく少なくとも第２の送信単位とを形成する構成装置を具備するモジュールにおいて、前記第１の送信単位用の第１の識別子と、前記第２の送信単位用の第２の識別子とを定義する定義装置をさらに具備し、前記第１および第２の識別子が、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報とのそれぞれの復号化順序を示すように成すモジュール。
28. 復号化のために符号化済みピクチャを再順序化するモジュールであって、前記符号化済みピクチャが第１および第２の符号化済みピクチャを含み、前記第１の符号化済みピクチャに基づいて形成される少なくとも第１の送信単位で、並びに、前記第２の符号化済みピクチャに基づいて形成される少なくとも第２の送信単位で前記符号化済みピクチャを送信するように成すモジュールにおいて、前記第１の送信単位用の第１の定義された識別子と、前記第２の送信単位用の第２の定義された識別子とに基づいて、前記第１の送信単位に含まれる情報と、前記第２の送信単位に含まれる情報との復号化順序を決定するプロセッサをさらに具備するモジュール。

Images