JP2009124748A - ピクチャの符号化方法 - Google Patents

Abstract

【課題】マルチメディア情報をバッファリングする方法であって、デコーダへの受信バッファのサイズの伝達を可能とすることを目的とする。
【解決手段】パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータが定義される。
【選択図】図５

Description

発明の分野
本発明は、マルチメディア情報をバッファリングする方法に関する。本発明はまた、符号化されたピクチャストリームを、マルチメディアデータを含む送信ユニットとして受信し、このピクチャストリームをデコーダで復号化する方法に関する。本発明は、システムと、送信装置と、受信装置と、符号化されたピクチャをバッファリングするためのコンピュータプログラムプロダクトと、符号化されたピクチャストリームを復号化するためのコンピュータプログラムプロダクトと、信号と、モジュールと、送信装置内でメディアデータを処理するためのプロセッサと、受信装置内でメディアデータを処理するためのプロセッサと、エンコーダと、デコーダとにさらに関する。

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

ビデオ通信方式
ビデオ通信方式は、対話型方式と非対話型方式とに分けることができる。対話型方式は、テレビ会議とテレビ電話とを含む。このような方式の例として、ＩＳＤＮ、ＩＰ、およびＰＳＴＮネットワークでそれぞれ運用されるテレビ会議／電話方式を規定するＩＴＵ−Ｔ勧告Ｈ．３２０、Ｈ．３２３、およびＨ．３２４が挙げられる。対話型方式は、ユーザエクスペリエンスを向上するために、エンドツーエンド（オーディオ・ビデオのキャプチャから遠端でのオーディオ・ビデオのプレゼンテーションまで）の遅延の最小化を目することを特徴とする。

非対話型方式は、再生装置、デジタルＴＶ、およびストリーミングの大容量メモリに格納されているビデオファイルやデジタル多用途ディスク（ＤＶＤ）など、記憶されているコンテンツの再生を含む。これらの技術分野における最も重要な規格について以下に概説する。

今日のデジタルビデオ家庭用電子機器において主流をなす１つの規格は、ビデオの圧縮、オーディオの圧縮、記憶、およびトランスポートに関する仕様を含むＭＰＥＧ−２である。符号化されたビデオの記憶およびトランスポートは、エレメンタリストリームの概念に基づく。１つのエレメンタリストリームは、単一ソース（たとえば、ビデオ）からの符号化されたデータと、このソース情報の同期化、特定、および特徴付けに必要な補助データとで構成される。エレメンタリストリームは、固定長または可変長の複数のパケットにパケット化され、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）を形成する。各ＰＥＳパケットは、ヘッダと、これに続くペイロードと称されるストリームデータとから成る。さまざまなエレメンタリストリームからのＰＥＳパケットが組み合わされて、ＰＳ（Ｐｒｏｇｒａｍ Ｓｔｒｅａｍ）またはＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）のどちらかを形成する。ＰＳは、蓄積再生型のアプリケーションなど、無視しうる送信誤りを有するアプリケーションを対象としている。ＴＳは、送信誤りを許容するアプリケーションを対象としている。ただし、ＴＳは、ネットワークの一定スループットが保証されることを想定している。

ＩＴＵ−ＴとＩＳＯ／ＩＥＣとのジョイントビデオチーム（ＪＶＴ）は、ＩＴＵ−Ｔ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６−１０（ＭＰＥＧ−４パート１０）と同じ規格本文を含む規格草案を公開した。本文書では、この規格草案をＪＶＴ符号化規格と称し、この規格草案によるコーデックをＪＶＴコーデックと称する。

このコーデック仕様自体は、ビデオ符号化層（ＶＣＬ）とネットワーク抽象化層（ＮＡＬ）とを概念的に区別する。ＶＣＬは、コーデックの信号処理機能として、変換、量子化、動き検出／補償、ループフィルタなどを含む。これは、今日のビデオコーデックの大半、動き補償のあるインタピクチャ予測を用いるマクロブロックベースのコーダ、および残余信号の変換符号化の一般概念に従っている。ＶＣＬの出力は複数のスライスである。つまり、整数個数のマクロブロックから成るマクロブロックデータと、スライスヘッダの情報（スライス内の最初のマクロブロックの空間アドレスや初期量子化パラメータなどを含む情報）を含むビットストリングである。スライス内のマクロブロックはスキャン順に順序付けられるが、いわゆる可変マクロブロック順序付け構文を用いて異なるマクロブロック割り当てが指定される場合はこの限りでない。ピクチャ内予測は、スライス内においてのみ用いられる。

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

Ｈ．２６３のオプションの参照ピクチャ選択モードおよびＭＰＥＧ−４パート２のＮＥＷＰＲＥＤ符号化ツールは、動き補償をピクチャセグメントごと、たとえば、Ｈ．２６３のスライスごと、に行うための参照フレームの選択を可能にする。さらに、Ｈ．２６３のオプションの拡張参照ピクチャ選択モードおよびＪＶＴ符号化規格は、各マクロブロック別の参照フレームの選択を可能にする。

参照ピクチャの選択は、多くの種類の時間スケーラビリティ方式を可能にする。図１は、時間スケーラビリティ方式の一例を示すが、本願明細書ではこの方式を再帰的時間スケーラビリティと称する。この例の方式は、３種類の一定フレームレートでの復号化が可能である。図２は、ビデオ冗長符号化と称される方式を示す。この方式では、複数のピクチャから成る１つのシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される。これらの図および以降のすべての図における矢印は、動き補償の方向を示し、各フレームの下の数字は、各フレームのキャプチャおよび表示の相対時刻に対応する。

送信順
従来のビデオ符号化規格では、Ｂピクチャの場合を除いて、ピクチャの復号化順は表示順と同じである。従来のＢピクチャ内の１つのブロックは、２つの参照ピクチャから時間的に双方向に予測できるが、これらの参照ピクチャの一方は、表示順において時間的に先行するピクチャであり、他方は時間的に後続するピクチャである。復号化順で最後の参照ピクチャのみが表示順においてＢピクチャに後続するるとができる（例外：Ｈ．２６３の飛越し符号化では、時間的に後続する１つの参照フレームの両フィールドピクチャが復号化順においてＢピクチャに先行することができる）。従来のＢピクチャは、時間予測のための参照ピクチャとして使用できないので、従来のＢピクチャは、他のどのピクチャの復号化にも影響を及ぼさずに、配置できる。

ＪＶＴ符号化規格は、これ以前の規格に比べ、以下の新規の技術的特徴を含む。
・ピクチャの復号化順が表示順から切り離される。ピクチャ番号が復号化順を示し、ピクチャ順カウントが表示順を示す。
・Ｂピクチャ内の１つのブロックの複数の参照ピクチャを表示順でＢピクチャの前にすることも、後にすることもできる。この結果、Ｂピクチャは、双方向ピクチャではなく、双予測ピクチャを表す。
・参照ピクチャとして使用されないピクチャには明示的に印が付けられる。どの種類（イントラ、インタ、Ｂなど）のピクチャでも、参照ピクチャまたは非参照ピクチャにすることができる。（したがって、Ｂピクチャは、他のピクチャの時間予測のための参照ピクチャとして使用できる。）
・ピクチャは、異なる符号化種別によって符号化された複数のスライスを含むことができる。すなわち、符号化ピクチャを、たとえば、イントラ符号化スライスとＢ符号化スライスとから構成しうる。

表示順を復号化順から切り離すと、圧縮効率および誤り耐性の点から好ましい場合がある。

圧縮効率を向上しうる予測構造の一例を図３に示す。四角形はピクチャを示し、四角形の中の大文字は符号化種別を示し、四角形の中の数字はＪＶＴの符号化規格によるピクチャ番号であり、矢印は予測依存性を示す。なお、ピクチャＢ１７は、ピクチャＢ１８の参照ピクチャである。符号化ピクチャパターンＰＢＢＰまたはＰＢＢＢＰによる従来の符号化に比べ、ピクチャＢ１８の参照ピクチャが時間的に近いので、従来の符号化に比べ圧縮効率が向上しうる。参照ピクチャの一部が双方向に予測されるので、従来の符号化ピクチャパターンＰＢＰに比べ、圧縮効率が向上しうる。

図４は、誤り耐性向上のために使用できるイントラピクチャ先送り方法の一例を示す。従来、イントラピクチャの符号化は、たとえば、シーンカットの直後やイントラピクチャのリフレッシュ期間の終了に対する応答として行われていた。イントラピクチャ先送り方法においては、イントラピクチャの符号化が必要になったときに直ちにイントラピクチャの符号化が行われず、代わりに時間的に後のピクチャがイントラピクチャとして選択される。符号化イントラピクチャとイントラピクチャの従来位置との間の各ピクチャは、時間的に次の後続ピクチャから予測される。図４に示すように、イントラピクチャ先送り方法では独立した２つのインタピクチャ予測チェーンが生成されるが、従来の符号化アルゴリズムでは単一のインタピクチャチェーンが生成される。２つのチェーンによるアプローチは、従来の単一チェーンによるアプローチに比べ、消去誤りに対してより堅牢であることは直観的に明らかである。一方のチェーンでパケット損失が発生しても、他方のチェーンは正しく受信されうる。従来の符号化においては、パケットの損失は、インタピクチャ予測チェーンの残りの部分に誤りを必ず伝播させる。

従来、デジタルビデオには、復号化順とプレゼンテーション順という２種類の順序付けおよびタイミング情報が対応付けられていた。以下に、関連技術をより詳しく見てゆく。

復号化タイムスタンプ（ＤＴＳ）は、符号化されたデータユニットを復号化すべき時刻を参照クロックを基準として示す。ＤＴＳを符号化して送信すると、ＤＴＳが２つの目的に役立つ。第１に、ピクチャの復号化順がその出力順と異なる場合は、復号化順がＤＴＳによって明示的に示される。第２に、受信レートがどの時点においても送信レートに近い場合は、一定のプリデコーダバッファリング動作がＤＴＳによって保証される。エンドツーエンドレイテンシが変動するネットワークにおいては、ＤＴＳの第２の用途は役に立たないか、またはほとんど役に立たない。代わりに、非圧縮ピクチャのための空間がポストデコーダバッファにあれば、受信されたデータができるだけ高速で復号化される。

ＤＴＳの移送は、使用される通信システムおよびビデオ符号化規格に依存する。ＭＰＥＧ−２方式においては、ＤＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＤＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできるので、オプションのハイポセティカルレファレンスデコーダの動作に用いられる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＤＴＳはその固有のボックス種別であるＤｅｃｏｄｉｎｇ Ｔｉｍｅ ｔｏ Ｓａｍｐｌｅ Ｂｏｘのみをサポートする。ＲＴＰによるストリーミング方式など、多くの方式においてＤＴＳがまったく運ばれない理由は、復号化順が送信順と同じであると想定されるので、正確な復号化時刻が重要な役割を果たさないからである。

Ｈ．２６３のオプションの付属書Ｕおよび付属書Ｗ．６．１２は、復号化順においてピクチャ番号を前の参照ピクチャから１だけ増加するように規定している。ＪＶＴ符号化規格においては、Ｈ．２６３のピクチャ番号と同様に、フレーム番号の符号化要素が規定されている。ＪＶＴ符号化規格は、瞬間デコーダリフレッシュ（ＩＤＲ）ピクチャと呼ばれる特定のイントラピクチャ種別を規定している。復号化順において後続のピクチャは、ＩＤＲピクチャより前のピクチャを参照することができない。ＩＤＲピクチャは、シーンチェンジに対する応答として符号化されることが多い。ＪＶＴ符号化規格においては、図５ａおよび図５ｂに示されるように、ＩＤＲピクチャ損失時の誤り耐性を向上するために、フレーム番号がＩＤＲピクチャで０にリセットされる。ただし、シーンチェンジの検出には、ＪＶＴ符号化規格のシーン情報ＳＥＩメッセージも使用できることは言うまでもない。

参照ピクチャの復号化順を復元するために、Ｈ．２６３のピクチャ番号を使用することができる。同様に、あるＩＤＲピクチャと復号化順で次のＩＤＲピクチャとの間（後者のＩＤＲピクチャは含まれない）のフレームの復号化順を復元するために、ＪＶＴフレーム番号を使用することができる。ただし、相補型参照フィールド対（それぞれのパリティが異なるフィールドとして符号化された連続ピクチャ）はフレーム番号が同一であるので、これらの復号化順をフレーム番号から再構成することはできない。

非参照ピクチャのＨ．２６３ピクチャ番号またはＪＶＴフレーム番号は、復号化順で前の参照ピクチャのピクチャ番号またはフレーム番号に１を加えた値に等しくすると規定されている。いくつかの非参照ピクチャが復号化順で連続している場合、これらのピクチャのピクチャ番号またはフレーム番号は同一である。非参照ピクチャのピクチャ番号またはフレーム番号は、復号化順で次の参照ピクチャのピクチャ番号またはフレーム番号とも同じである。連続する非参照ピクチャの復号化順は、Ｈ．２６３の時間参照（ＴＲ）符号化要素またはＪＶＴ符号化規格のピクチャ順カウント（ＰＯＣ）の概念を用いて復元することができる。

プレゼンテーションタイムスタンプ（ＰＴＳ）は、ピクチャを表示すべき時刻を参照クロックを基準として示す。プレゼンテーションタイムスタンプは、表示タイムスタンプ、出力タイムスタンプ、および合成タイムスタンプとも呼ばれる。

ＰＴＳの移送は、使用される通信システムおよびビデオ符号化標準に依存する。ＭＰＥＧ−２方式においては、ＰＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＰＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＰＴＳはその固有のボックス種別であるＣｏｍｐｏｓｉｔｉｏｎ Ｔｉｍｅ ｔｏ Ｓａｍｐｌｅ Ｂｏｘのみをサポートし、プレゼンテーションタイムスタンプは、対応する復号化タイムスタンプを基準として符号化される。ＲＴＰでは、ＲＴＰパケットヘッダ内のＲＴＰタイムスタンプは、ＰＴＳに対応する。

従来のビデオ符号化規格は、多くの側面においてＰＴＳと同様の時間参照（ＴＲ）符号化要素を特徴とする。ＭＰＥＧ−２ビデオなど従来の符号化標準によっては、グループオブピクチャ（ＧＯＰ）の先頭でＴＲをゼロにリセットするものもある。ＪＶＴ符号化規格においては、時間の概念がビデオ符号化層に存在しない。ピクチャ順カウント（ＰＯＣ）が各フレームおよび各フィールドに対して指定され、たとえばＢスライスの直接時間予測におけるＴＲと同様に使用される。ＰＯＣは、ＩＤＲピクチャでゼロにリセットされる。

バッファリング
ストリーミングのクライアントは、一般に、比較的大量のデータを格納できる受信バッファを有す。ストリーミングセッションが確立された初期状態において、クライアントはストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。このバッファリングは連続再生の維持に役立つが、その理由は送信遅延の増加またはネットワークのスループット低下が発生した場合でも、クライアントはバッファリングされたデータの復号化および再生を行えるからである。初期バッファリングを行わないと、クライアントは表示をフリーズし、復号化を停止し、着信データを待たねばならない。このバッファリングは、どのプロトコルレベルにおいても自動再送または選択的再送のためにも必要である。ピクチャの何れかの部分が失われた場合、損失データを再送するために再送機構を使用してもよい。予定された復号化時刻または再生時刻より前に再送データが受信されれば、損失は完全に復元される。

符号化されたピクチャは、復号化シーケンスの主観的品質における重要度に応じてランク付けすることができる。たとえば、従来のＢピクチャなどの非参照ピクチャは、損失しても他のどのピクチャの復号化にも影響しないので、主観的に最も重要でない。データパーティションまたはスライスグループ単位で主観的順位付けを行うこともできる。主観的に最も重要度が高い符号化スライスおよびデータパーティションをそれぞれの復号化順が示す順序より早く送信し、一方、主観的に最も重要度が低い符号化スライスおよびデータパーティションをそれぞれの本来の符号化順が示す順序より後に送信することができる。この結果、最も重要度が高いスライスおよびデータパーティションが部分的に再送される場合でも、最も重要度が低いスライスおよびデータパーティションに比べ、予定されているそれぞれの復号化時刻または再生時刻より前に受信される可能性が高い。

プリデコーダバッファリング
プリデコーダバッファリングとは、符号化されたデータを復号化する前にバッファリングすることをいう。初期バッファリングとは、ストリーミングセッションの先頭で行われるプリデコーダバッファリングをいう。従来、初期バッファリングは以下に示す２つの理由のために行われていた。

たとえばＩＰによるテレビ会議システムなどの対話型パケット交換マルチメディアシステムでは、種類の異なるメディアは通常それぞれ別のパケットで運ばれる。さらに、パケットは、一定の送信遅延を保証できず、遅延がパケットごとに変動しうるベストエフォート型ネットワークの上を運ばれるのが一般的である。この結果、同じプレゼンテーション（再生）タイムスタンプを有する複数のパケットが同一時刻に受信されず、２つのパケットの受信間隔がそれぞれのプレゼンテーションの間隔（時間）と異なることもありうる。したがって、異なるメディア種別間で再生の同期を維持し、正しい再生レートを維持するために、マルチメディア端末は、一般に受信データを短期間（たとえば、２分の１秒未満）バッファリングすることによって遅延変動を均す。本願明細書において、この種のバッファ構成要素を遅延ジッタバッファと称する。バッファリングは、メディアデータの復号化の前および／または後に行うことができる。

遅延ジッタバッファリングは、ストリーミングシステムでも利用される。ストリーミングは非対話型アプリケーションであるので、必要な遅延ジッタバッファは対話型アプリケーションよりはるかに大きなものとなりうる。ストリーミングプレーヤがサーバへの接続を確立し、マルチメディアストリームのダウンロードを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはストリームの再生を直ちには開始せず、一般に着信データをある時間、一般には２〜３秒間、バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングでは、対話型アプリケーションでの遅延ジッタバッファリングによる方法と同様の方法で、送信遅延の変動を均すことができる。さらに、失われたプロトコルデータユニット（ＰＤＵ）の再送をリンク層、トランスポート層、および／またはアプリケーション層で行える。プレーヤがバッファリングされたデータを復号化および再生している間に、再送されたＰＤＵが予定の復号化時刻および再生時刻に間に合うように受信されうる。

ストリーミングクライアントにおける初期バッファリングは、対話型システムでは実現できないさらに別の利点をもたらす。つまり、サーバから送信されるメディアのデータレートを変えることができる。すなわち、受信バッファがオーバフローまたはアンダーフローしない限り、メディアパケットの送信レートをその再生レートより一時的に高速化または低速化することができる。データレートの変動は、２つのソースから発生しうる。

第１に、ビデオなど、一部のメディア種別で達成可能な圧縮効率は、ソースデータの内容に応じて決まる。したがって、安定した品質が所望される場合は、圧縮されたビットストリームのビットレートが変動する。一般に、オーディオ・ビジュアル品質は、変動する品質より安定した品質の方が主観的に好ましい。したがって、初期バッファリングのないテレビ会議システムなどのシステムに比べ、より好ましいオーディオ・ビジュアル品質を初期バッファリングによって達成することができる。

第２に、固定ＩＰネットワークにおいてはパケット損失が集中的に発生することが一般に公知である。集中的な誤りの発生および高いピークビットレートおよびパケットレートを回避するために、適切に設計されたストリーミングサーバがパケットの送信を綿密にスケジューリングする。パケットは受信端での再生レートと正確に同じレートで送信されないこともあるが、サーバが送信パケット間の間隔の安定化を試みうる。サーバはまた、その時点のネットワーク条件に応じてパケットの送信レートを調整しうる。たとえば、ネットワーク輻輳時はパケットの送信レートを下げ、ネットワーク条件が許す場合はパケット送信レートを上げうる。

マルチメディアストリームの送信
１つのマルチメディアストリーミングシステムは、１つのストリーミングサーバと、ネットワーク経由でこのサーバにアクセスするいくつかのプレーヤとで構成される。ネットワークは、一般にパケット指向であり、サービス品質を保証するための手段は皆無か、またはほとんどない。プレーヤは、事前に格納されているマルチメディアコンテンツをフェッチするか、またはライブのマルチメディアコンテンツをサーバからフェッチし、ダウンロードされたコンテンツをリアルタイムで再生する。この通信種別は、ポイントツーポイントかマルチキャストのどちらかにしうる。ポイントツーポイントストリーミングでは、サーバはプレーヤごとにそれぞれ別の接続を設ける。マルチキャストストリーミングにおいては、サーバは単一のデータストリームをいくつかのプレーヤに送信し、必要に応じてネットワーク要素がストリームを複製する。

プレーヤがサーバへの接続を確立し、マルチメディアストリームを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはこのストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングは、切れ目のない再生の維持に役立つが、その理由は、送信遅延の増加またはネットワークのスループット低下が発生した場合でも、プレーヤはバッファリングされたデータの復号化および再生を行えるからである。

無制限の送信遅延を回避するために、信頼性の高いトランスポートプロトコルを採用することはストリーミングシステムにおいては一般的でない。代わりに、ストリーミングシステムは、より安定した送信遅延を継承する一方で、データの破損または損失も蒙る、ＵＤＰなどの信頼性の低いトランスポートプロトコルを使用する。

リアルタイム通信を制御するために、ＲＴＰおよびＲＴＣＰプロトコルをＵＤＰの上で使用することができる。ＲＴＰは、送信パケットの損失を検出し、受信端で正しいパケット順を再構築し、標本化タイムスタンプを各パケットに対応付ける手段を提供する。ＲＴＣＰは、正しく受信されたパケット部分の大きさに関する情報を伝えるので、フロー制御に用いることができる。

従来のビデオ符号化規格では、復号化順は出力順に結び付けられている。すなわち、ＩおよびＰピクチャの復号化順はそれぞれの出力順と同じであり、Ｂピクチャの復号化順は、出力順でそのＢピクチャに後続する参照ピクチャの復号化順の直後である。この結果、出力順がわかれば、復号化順の復元が可能である。出力順は、一般には基本ビデオビットストリームの時間参照（ＴＲ）フィールドで運ばれ、またシステム多重層でもＲＴＰヘッダなどで運ばれる。

一部のＲＴＰペイロード仕様では、復号化順以外の順序による符号化データの送信を可能にしている。順序移動量は、多くの関連仕様において同様に定義されている１つの値によって特徴付けるのが一般的である。たとえば、ＭＰＥＧ−４エレメンタリストリームのトランスポート用ＲＴＰペイロードフォーマット草案では、ｍａｘＤｉｓｐｌａｃｅｍｅｎｔパラメータを次のように指定する。

アクセスユニット（ＡＵ、符号化された１つのピクチャに対応）の最大移動時間は、パターン内のＡＵのタイムスタンプとまだ存在しない最先ＡＵのタイムスタンプとの間の最大の差である。すなわち、複数のＡＵがインタリーブされたシーケンスを考えると、次のようになる。
何れのｉおよび何れのｊ＞ｉについても、最大移動量＝最大｛ＴＳ（ｉ）−ＴＳ（ｊ）｝
但し、ｉおよびｊは、インタリーブパターン内のＡＵのインデックスを示し、ＴＳはＡＵのタイムスタンプを示す。

この方法にはいくつかの問題があり、バッファに対して大きすぎる値を付与することが本発明で認められた。

ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６１、Ｖｉｄｅｏ ｃｏｄｅｃ ｆｏｒ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ ａｔ ｐ×６４ｋｂｉｔｓ ＩＴＵ−Ｔ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６３、Ｖｉｄｅｏ ｃｏｄｉｎｇ ｆｏｒ ｌｏｗ ｂｉｔ ｒａｔｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ＩＳＯ／ＩＥＣ、ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ−１、 Ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｆｏｒ ｄｉｇｉｔａｌ ｓｔｏｒａｇｅ ｍｅｄｉａ ａｔ ｕｐ ｔｏ ａｂｏｕｔ １．５ Ｍｂｉｔ／ｓ ＩＳＯ／ＩＥＣ、ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ−２、 Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ ＩＳＯ／ＩＥＣ、ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ−４ Ｐａｒｔ ２、 Ｃｏｄｉｎｇ ｏｆ ａｕｄｉｏ−ｖｉｓｕａｌ ｏｂｊｅｃｔｓ

発明の要約
最大移動量の定義によってバッファリング要件（バッファ空間および初期バッファリング期間）をまったく指定できない方式の一例を次に示す。シーケンスを１５個のＡＵにスプライシングし、このような１５個のＡＵにおいて復号化および出力順が最後のＡＵを最初に送信し、他の全てのＡＵを復号化および出力順で送信する。したがって、ＡＵの送信シーケンスは次のようになる。
１４ ０ １ ２ ３ ４ ５ ６ ７ ８ ９ １０ １１ １２ １３ ２９ １５ １６ １７ １８ １９ ．．．
このシーケンスにおけるＡＵの最大移動量は１４である（１４＋ｋ＊１５）（ｋはすべて負でない整数値）。

ただし、このシーケンスに必要なバッファ空間および初期バッファリングは、１つのＡＵ分だけである。

Ｈ．２６４のＲＴＰペイロードフォーマット草案（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔ）においては、パラメータｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓは、ＮＡＬユニットストリームの特性または実装されている送信器または受信器の機能を伝えるために使用しうると規定されている。このパラメータは、ＮＡＬユニットストリーム内でＶＣＬ ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつＲＴＰシーケンス番号順、またはＶＣＬ ＮＡＬユニットを含む集約パケットの合成順でこのＶＣＬ ＮＡＬユニットに後続するＶＣＬ ＮＡＬユニットの最大数を指定する。このパラメータがない場合は、０に等しいｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓを暗黙で指定する必要がある。ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓの値は、０から３２７６７までの（両端の値を含む）範囲内の整数とする。

Ｈ．２６４規格によると、ＶＣＬ ＮＡＬユニットは、１から５までの数に等しい値を有するｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＮＡＬユニットとして指定する。この規格では、次のＮＡＬユニット種別１〜５が定義されている。
１ 非ＩＤＲピクチャの符号化スライス
２ 符号化スライスデータパーティションＡ
３ 符号化スライスデータパーティションＢ
４ 符号化スライスデータパーティションＣ
５ ＩＤＲピクチャの符号化スライス

ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは、上記の最大移動量パラメータと同様の問題を引き起こす。つまり、このパラメータに基づきバッファリング空間および初期バッファリング時間の要件を判定することは不可能である。

本発明は、デコーダへの受信バッファのサイズの伝達を可能にする。

以下において、独立した１つのＧＯＰは、あるＩＤＲピクチャから復号化順で次のＩＤＲピクチャまでのピクチャから成る（後者のＩＤＲピクチャは含まれない）。

本発明においては、従来技術のシステムに比べ、バッファリングの必要最大量を伝達するパラメータがより正確に定義される。次の説明において、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、ビデオ信号を格納するシステムにも本発明を実装できることは言うまでもない。格納されるビデオ信号は、符号化前に格納される符号化されていない信号、符号化後に格納される符号化された信号、または符号化および復号化処理の後に格納される復号化された信号の何れでもよい。たとえば、エンコーダは、ビットストリームを送信順に出力する。ファイルシステムは、たとえば復号化順にカプセル化され、ファイルとして格納されたオーディオおよび／またはビデオビットストリームを受信する。このファイルは、データベースに格納でき、このデータベースからストリーミングサーバがＮＡＬユニットを読み出し、ＲＴＰパケットにカプセル化することができる。

さらに、次の説明では、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、エンコーダが符号化されたデータを出力し、ストリーミングサーバなどの別の構成要素に第１の順で送信し、この別の構成要素がこの符号化されたデータを第１の順から別の順に並べ替え、この新しい順に必要なバッファサイズを定義し、この符号化されたデータを並べ替えられた形式でデコーダに転送するシステムにも本発明を実装できることは明らかである。

本発明の第１の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられている複数のデータ送信ユニットに含まれているメディアデータをバッファにバッファリングする方法において、パケットストリーム内のいずれかの送信ユニットに送信順で先行し、かつその送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータが定義されることを特徴とする方法が提供される。

本発明の第２の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信およびバッファリングし、デコーダで復号化する方法において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータとして、バッファリング要件が復号化プロセスに示されることを特徴とする方法が提供される。

本発明の第３の態様によると、ピクチャを符号化するエンコーダと、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファリングするバッファとを含むシステムにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするシステムが提供される。

本発明の第４の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを送信するための送信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とする送信装置が提供される。

本発明の第５の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含むデータ送信ユニットとして、符号化されたピクチャストリームを受信するための受信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを使用してバッファリング要件を判定する手段を含むことを特徴とする受信装置が提供される。

本発明の第６の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャをバッファにバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するために機械が実行可能なステップをさらに含むことを特徴とするコンピュータプログラムプロダクトが提供される。

本発明の第７の態様によると、マルチメディアデータを含む複数の送信ユニットとして受信された符号化されたピクチャストリームをデコーダで復号化するために機械が実行可能なステップと、送信ユニットをバッファリングするために機械が実行可能なステップと、を含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する送信ユニットの最大量を示すパラメータを用いて、復号化プロセスに対するバッファリング要件を判定するために機械が実行可能なステップを含むことを特徴とするコンピュータプログラムプロダクトが提供される。

本発明の第８の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを運ぶ信号において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを含むことを特徴とする信号が提供される。

本発明の第９の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するためのモジュールにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを使用してバッファリング要件を判定する手段を含むことを特徴とするモジュールが提供される。

本発明の第１０の態様によると、送信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを定義するようになっているデファイナを含むことを特徴とするプロセッサが提供される。

本発明の第１１の態様によると、符号化されたピクチャストリームをスライスデータを含む送信ユニットとして受信する受信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするプロセッサが提供される。

本発明の第１２の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを符号化するためのエンコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするエンコーダが提供される。

本発明の第１３の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットに含まれている符号化されたピクチャストリームを復号化するためのデコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするデコーダが提供される。

本発明の一実施例において、マルチメディアデータを含む送信単位は、ＶＣＬ ＮＡＬ単位である。

本発明は、符号化システムのバッファリング効率を向上させる。本発明を用いると、実際に必要な適量のバッファリングの使用が可能になる。したがって、符号化装置内の符号化バッファおよび復号化装置内の復号化前バッファに必要以上のメモリを割り当てる必要がない。また、復号化前バッファのオーバフローを回避できる。

再帰的時間スケーラビリティ方式の一例を示す。 １つのピクチャシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される、ビデオ冗長符号化と称される方式を示す。 圧縮効率を向上しうる予測構造の一例を示す。 誤り耐性の向上のために使用できるイントラピクチャ先送り方法の一例を示す。 本発明によるシステムの好都合な実施形態を示す。 本発明によるエンコーダの好都合な実施形態を示す。 本発明によるデコーダの好都合な実施形態を示す。

発明の詳細な記述
次に、図５のシステム、図６のエンコーダ１、および図７のデコーダ２を参照しながら、本発明をより詳細に説明する。符号化するピクチャは、たとえば、カメラやビデオレコーダなどのビデオソース３からのビデオストリームのピクチャとすることができる。ビデオストリームの各ピクチャ（フレーム）は、スライスなどのより小さな複数の部分に分割することができる。スライスは、さらにブロックに分割することができる。送信チャネル４を介して、または記憶メディア（図示せず）に送信される情報を減らすために、ビデオストリームはエンコーダ１において符号化される。ビデオストリームの各ピクチャは、エンコーダ１に入力される。エンコーダは、符号化するピクチャの一部を一時的に格納するための符号化バッファ１．１（図６）を有する。エンコーダ１は、本発明による符号化タスクを適用できるプロセッサ１．２とメモリ１．３とをさらに含む。メモリ１．３およびプロセッサ１．２を送信装置６と共通にすることも、送信装置６の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を送信装置６に設けることもできる。ビデオストリームを圧縮するために、エンコーダ１は、動きの推定および／または他のいくつかのタスクを実行する。動きの推定においては、符号化するピクチャ（現在のピクチャ）と前および／または後のピクチャとの間の類似点が探される。類似点が見つかると、比較したピクチャまたはその一部を符号化対象ピクチャの参照ピクチャとして用いる。ＪＶＴでは、ピクチャの表示順と復号化順とが必ずしも同じではないので、参照ピクチャが参照ピクチャとして使われる限りは、参照ピクチャをバッファ（たとえば、符号化バッファ１．１）に格納する必要がある。また、エンコーダ１はピクチャの表示順に関する情報を送信ストリームに挿入する。

必要であれば、符号化されたピクチャは、符号化プロセスから符号化ピクチャバッファ５．２に移動される。符号化されたピクチャは、エンコーダ１から送信チャネル４を介してデコーダ２に送信される。デコーダ２では、符号化されたピクチャが復号化され、符号化ピクチャにできる限り対応する非圧縮ピクチャが形成される。

デコーダ１は、本発明による復号化タスクを適用できるプロセッサ２．２とメモリ２．３とをさらに含む。プロセッサ２．２とメモリ２．３とは受信装置８と共通にすることも、または受信装置８の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を受信装置８に設けることもできる。

符号化
次に、符号化・復号化プロセスをより詳細に考えてみよう。ビデオソース３からのピクチャはエンコーダ１に入力され、さらに符号化バッファ１．１に格納されるので都合がよい。符号化プロセスは最初のピクチャがエンコーダに入力された直後に必ずしも開始されず、符号化バッファ１．１内の利用可能なピクチャが一定量になってから開始される。次に、エンコーダ１は、参照フレームとして使用する適切な候補をこれらのピクチャから見つけようとする。次に、エンコーダ１は符号化を実行して、符号化されたピクチャを形成する。符号化されたピクチャは、たとえば、予測ピクチャ（Ｐ）、双予測ピクチャ（Ｂ）、および／またはイントラ符号化ピクチャ（Ｉ）である。イントラ符号化ピクチャの復号化は他のどのピクチャも使用せずに行えるが、他の種類のピクチャの復号化には少なくとも１つの参照ピクチャが必要である。上記のどのピクチャ種別のピクチャでも参照ピクチャとして使用できる。

エンコーダは、復号化タイムスタンプ（ＤＴＳ）および出力タイムスタンプ（ＯＴＳ）の２つのタイムスタンプをピクチャに添付するので都合がよい。デコーダはこれらのタイムスタンプを使用して正しい復号化時刻とピクチャの出力（表示）時刻とを判定する。ただし、これらのタイムスタンプはデコーダに必ずしも送信されず、あるいはデコーダが使用しないこともある。

ＮＡＬユニットは、異なる種類のパケットで配信することができる。この好都合な実施形態においては、複数の異なるパケットフォーマットとして、単純パケットと集約パケットとが挙げられる。集約パケットは、シングルタイム集約パケットとマルチタイム集約パケットとにさらに分割することができる。

ＲＴＰパケットのペイロードフォーマットは、必要に応じて、いくつかの異なるペイロード構造として定義される。ただし、受信されるＲＴＰパケットがどの構造を含むかは、ペイロードの先頭バイトから明らかである。このバイトは、ＮＡＬユニットヘッダとして必ず構成される。ＮＡＬユニットタイプフィールドは、どの構造が存在するかを示す。ありうる構造は、単一ＮＡＬユニットパケット、集約パケット、およびフラグメントユニットである。単一ＮＡＬユニットパケットは、ペイロード中にＮＡＬユニットを１つだけ含む。ＮＡＬヘッダタイプフィールドは本来のＮＡＬユニットタイプに等しい、すなわち１から２３までの範囲に含まれる。集約パケットタイプは、複数のＮＡＬユニットを単一のＲＴＰペイロードに集約するために使用される。このパケットは４つのバージョンがある。すなわち、シングルタイム集約パケットタイプＡ（ＳＴＡＰ−Ａ）、シングルタイム集約パケットタイプＢ（ＳＴＡＰ−Ｂ）、マルチタイム集約パケット（ＭＴＡＰ）の１６ビットオフセット版（ＭＴＡＰ１６）、およびマルチタイム集約パケット（ＭＴＡＰ）の２４ビットオフセット版（ＭＴＡＰ２４）が存在する。ＳＴＡＰ−Ａ、ＳＴＡＰ−Ｂ、ＭＴＡＰ１６、およびＭＴＡＰ２４に割り当てられたＮＡＬユニットタイプ番号は、それぞれ２４、２５、２６、および２７である。フラグメントユニットは、単一のＮＡＬユニットを複数のＲＴＰパケットにわたってフラグメント化するために使用する。フラグメントユニットは２つのバージョンが存在し、それぞれＮＡＬユニットタイプ番号２８および２９で識別される。

ＲＴＰパケット送信のために定義されるパケット化モードとして、次の３つのケースがある。
・単一ＮＡＬユニットモード
・非インタリーブドモード
・インタリーブドモード

単一ＮＡＬユニットモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠した対話型システムを対象とする。非インタリーブドモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠しない場合もある対話型システムを対象とする。非インタリーブドモードでは、ＮＡＬユニットはＮＡＬユニットの復号化順で送信される。インタリーブドモードは、エンドツーエンドレイテンシを極めて小さくする必要がないシステムを対象とする。インタリーブドモードでは、ＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が可能である。

使用されているパケット化モードは、パケット化モードを指定するオプションのＭＩＭＥパラメータの値または外部手段によって通知しうる。使用されているパケット化モードに応じて、ＲＴＰペイロードで使用しうるＮＡＬユニットタイプが決まる。

インタリーブドパケット化モードでは、ＮＡＬユニットの送信順をＮＡＬユニットの復号化順と同じにする必要がない。復号化順序号（ＤＯＮ）は、ペイロード構造内のフィールド、またはＮＡＬユニットの復号化順を示す派生変数である。

送信順と復号化順との結合は、次のようにインタリーブ深さを指定するオプションのＭＩＭＥパラメータによって制御する。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０に等しく、復号化順以外でのＮＡＬユニットの送信が外部手段によって禁止されている場合、ＮＡＬユニットの送信順はＮＡＬユニットの復号化順に従う。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０より大きい場合、またはＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が外部手段によって許容されている場合は、
・マルチタイム集約パケット１６（ＭＴＡＰ１６）およびマルチタイム集約パケット２４（ＭＴＡＰ２４）内のＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がなく、また
・２つの連続するパケット内のシングルタイム集約パケットＢ（ＳＴＡＰ−Ｂ）、ＭＴＡＰ、およびフラグメントユニット（ＦＵ）のデカプセル化によって合成されるＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がない。

単一ＮＡＬユニットパケット、ＳＴＡＰ−Ａ、およびＦＵ−ＡのＲＴＰペイロード構造は、ＤＯＮを含まない。ＳＴＡＰ−Ｂ構造およびＦＵ−Ｂ構造はＤＯＮを含み、ＭＴＡＰの構造はＤＯＮの派生を可能にする。

送信器がパケットごとに１つのＮＡＬユニットをカプセル化し、ＮＡＬユニットの復号化順以外でパケットを送信する必要がある場合は、ＳＴＡＰ−Ｂパケットタイプを使用することができる。

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

Ｈ．２６４では、表示順と異なる復号化順が許容されるので、ＲＴＰタイムスタンプの値がＲＴＰシーケンス番号に応じて単調非減少とならない場合もある。

送信順で最初のＮＡＬユニットのＤＯＮ値は次の何れかの値に設定しうる。ＤＯＮの値は、０から６５５３５までの（両端の値を含む）範囲内の何れかである。最大値に達すると、ＤＯＮの値は０に折り返す。

この仕様によるビデオシーケンスは、ＮＡＬＵストリームの他の部分から独立して複合化可能なＮＡＬＵストリームのどの部分でもよい。

堅牢なパケットスケジューリングの一例を以下に示す。

次の例の図では、時間は左から右へ流れ、ＩはＩＤＲピクチャを示し、Ｒは参照ピクチャを示し、Ｎは非参照ピクチャを示し、数字は復号化順で前のＩＤＲピクチャに比例する相対的な出力時刻を示す。ピクチャシーケンスの下の値は、システムクロックのタイムスタンプ目盛りを示し、この例ではこれらの目盛りは適宜初期化される。Ｉ、Ｒ、およびＮピクチャは、符号化、送信、および復号化にかかる時間が皆無であると仮定して、前の処理ステップがある場合は前のステップに比べて同じ時系列にマッピングされる。

複数のビデオシーケンス内のピクチャのサブセットを以下に出力順に示す。

これらのピクチャの符号化（および復号化）順は、次のように左から右への順である。

１つのピクチャの復号化順序号（ＤＯＮ）は、復号化順で前のピクチャのＤＯＮ値に１を加えた値に等しい。

単純化するために、次のように仮定してみよう。
・シーケンスのフレームレートは一定である。
・各ピクチャは単一のスライスで構成される。
・各スライスは単一のＮＡＬユニットパケットにカプセル化される。
・ピクチャは復号化順で送信される。
・ピクチャは一定間隔で送信される（つまり、１／フレームレートに等しい）。

したがって、ピクチャは次のように復号化順で受信される。

送信（または受信順）から正しい復号化順を復元するためにバッファリングする必要がないので、ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは０に設定される。

以下に示すようにピクチャを復号化順から出力順に編成するために、デコーダは初めに１つのピクチャ間隔をその復号化ピクチャバッファにバッファリングする必要がある。

復号化ピクチャバッファに必要な初期バッファリング量は、バッファリング期間ＳＥＩメッセージによって通知することも、Ｈ．２６４のビデオユーザビリティ情報のｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ構文要素の値によって通知することもできる。ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは、シーケンス内で何れかのフレーム、相補型フィールド対、または非対フィールドに復号化順先行し、出力順で後続するフレーム、相補型フィールド対、または非対フィールドの最大数を示す。

単純化するために、復号化ピクチャバッファ内の初期バッファを示すために、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓが使用されると仮定する。この例では、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは１に等しい。

ＩＤＲピクチャ１００が送信中に失われ、システムクロックの値が６２のときに再送要求が発行された場合、再送されたＩＤＲピクチャ１００を受信する時間として１つのピクチャ間隔（システムクロックがタイムスタンプ６３に達するまでの時間）しかないことがわかる。

次に、各ＩＤＲピクチャの送信位置がそれぞれの復号化位置よりフレーム間隔２つ分だけ前である、すなわち、ピクチャが次の順に送信される、と仮定してみよう。

変数ｉｄ１を従来技術（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔに開示）に従って指定してみよう。つまり、ＮＡＬユニットストリーム内で何れかのＶＣＬ ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつこのＶＣＬ ＮＡＬユニットを含む集約パケットの合成順またはＲＴＰシーケンス番号順でこのＶＣＬ ＮＡＬユニットに後続するＶＣＬ ＮＡＬユニットの最大量を指定する。変数ｉｄ２を本発明に従って指定してみよう。つまり、ＮＡＬユニットストリーム内の何れかのＶＣＬ ＮＡＬユニットに送信順で先行し、かつそのＶＣＬ ＮＡＬユニットに復号化順で後続するＶＣＬ ＮＡＬユニットの最大量を指定する。

この例では、ｉｄ１の値は２に等しく、ｉｄ２の値は１に等しい。第２節で既に見たように、ｉｄ１の値は、受信順から復号化順にパケットを並べ替えるための初期バッファリングに必要なバッファリング空間または時間に比例しない。この例では、以下に図示するように（この図は受信器のバッファリング処理の出力を表す）、復号化順を復元するには、１ピクチャ間隔に等しい初期バッファリング時間が必要である。この例はまた、本発明によると、初期バッファリング時間およびバッファリング空間の値を割り出せることを実証する。

以下に示すように、ピクチャを復号化順から出力順に編成するために必要な初期バッファリング遅延もまた、１ピクチャ間隔である。

アプリケーション層、トランスポート層、またはリンク層での再送を含む送信中にＩＤＲピクチャが蒙りうる最大遅延はｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ＋ｉｄ２に等しいことが観察される。したがって、ＩＤＲピクチャの損失耐性は、再送をサポートするシステムで向上される。

受信器は、各ピクチャに対応付けられているＤＯＮの値に基づき、ピクチャを復号化順に編成することができる。

送信
最初の符号化ピクチャが用意されると直ちに符号化ピクチャの送信および／または格納（およびオプションの仮想復号化）を行うことができる。復号化順と出力順とが必ずしも同じではないので、このピクチャがデコーダ出力順で最初のピクチャになるとは限らない。

ビデオストリームの最初のピクチャが符号化されたら、送信を開始できる。符号化ピクチャは、符号化ピクチャバッファ１．２に格納することもできる。送信をこれより後の段階で開始することもでき、たとえばビデオストリームの一定部分が符号化された後に開始することもできる。

デコーダ２は、復号化されたピクチャを、たとえばピクチャ順カウントの順序付けを用いて、正しい順で出力するはずである。

デパケット化
デパケット化処理は実装依存である。したがって、以下の説明は適切な一実装例に関するものであり、実装をこれだけに限定するものではない。他の方式も使用しうる。記載のアルゴリズムに対する最適化も可能である。

これらのデパケット化規則の背後にある一般概念は、ＮＡＬユニットの送信順からＮＡＬユニットの配信順への並べ替えである。

復号化
次に、受信器８の動作を説明する。受信器８は１つのピクチャに属する全てのパケットを収集し、これらを１つの妥当な順に並べる。順序の厳密性は使用するプロファイルによって異なる。受信パケットは受信バッファ９．１（プリデコーディングバッファ）に格納される。受信器８は使用不能なものをすべて廃棄し、残りをデコーダ２に送る。集約パケットは、それぞれのペイロードをＮＡＬＵを運ぶ個々のＲＴＰパケットに書き出すことによって処理される。これらのＮＡＬＵは、それぞれ別のＲＴＰパケットとして受信されたかのように、集約パケット内の配置順で処理される。

次に、パケットストリーム内で何れかのＶＣＬ ＮＡＬユニットにＮＡＬユニット送信順で先行し、そのＶＣＬ ＮＡＬユニットに復号化順で後続するＶＣＬ ＮＡＬユニットの最大量を指定する、オプションのｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータ（ｉｎｔｅｒｌｅａｖｉｎｇ−ｄｅｐｔｈパラメータ）の値をＮにしてみよう。このパラメータがない場合は、０値の数を暗示しうる。

このビデオストリーム転送セッションを初期化すると、受信器８は、少なくともＮ個のＶＣＬ ＮＡＬユニットを格納するためのメモリを受信バッファ９．１に対して割り当てる。次にこの受信器は、ビデオストリームの受信を開始し、受信したＶＣＬ ＮＡＬユニットを受信バッファに格納する。初期バッファリングは、次の何れかの条件が満たされるまで続く。
・少なくともＮ個のＶＣＬ ＮＡＬユニットが受信バッファ９．１に格納される。
・ＭＩＭＥパラメータｍａｘ−ｄｏｎ−ｄｉｆｆが存在する場合は、関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の値がｍａｘ−ｄｏｎ−ｄｉｆｆの値を超える。ここで、ｎは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応し、ｍは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最小のＮＡＬユニットに対応する。
・初期バッファリングの継続時間がＭＩＭＥのオプションパラメータｉｎｉｔ−ｂｕｆ−ｔｉｍｅの値に等しくなるか、またはこれを超える。

関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）は次のように指定する。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝０
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。

ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の正の値は、送信順インデックスｎのＮＡＬユニットが送信順インデックスｍのＮＡＬユニットに復号化順で後続することを示す。

ＡｂｓＤＯＮは、ＮＡＬユニットのこのような復号化順序号が６５５３５の後で０に折り返されないことを示す。すなわち、ＡｂｓＤＯＮは次のように計算される。

ｍとｎとが送信順で連続するＮＡＬユニットであるとする。送信順で先頭（インデックス０）のＮＡＬユニットは、ＡｂｓＤＯＮ（０）＝ＤＯＮ（０）である。他のＮＡＬユニットのＡｂｓＤＯＮは、次のように計算される。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。

受信バッファ９．１が少なくともＮ個のＶＣＬ ＮＡＬユニットを収容すると、ＮＡＬユニットは受信バッファ９．１から１つずつ取り出され、デコーダ２に送られる。ＮＡＬユニットが受信バッファ９．１から取り出される順は必ずしも格納された順ではなく、以下に説明するようにＮＡＬユニットのＤＯＮに従う。デコーダ２へのパケットの配信は、バッファ内のＶＣＬ ＮＡＬユニットの数がＮ個より少なくなるまで、すなわちＶＣＬ ＮＡＬユニットがＮ−１個になるまで続く。

受信バッファから取り出されるＮＡＬユニットの数は次のように決められる。
・受信バッファが少なくともＮ個のＶＣＬ ＮＡＬユニットを収容すると、バッファ内のＶＣＬ ＮＡＬユニットがＮ−１個になるまで、以下に示す順でＮＡＬユニットが受信器のバッファから取り出され、デコーダに送られる。
・ｍａｘ−ｄｏｎ−ｄｉｆｆがある場合は、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）のｍがｍａｘ−ｄｏｎ−ｄｉｆｆより大きいすべてのＮＡＬユニットが以下の指定順で受信バッファから取り出され、デコーダに送られる。ここで、ｎは、受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応する。
・変数ｔｓを、ＮＡＬユニットストリームの最初のパケットが受信されたときに０に初期化されたシステムタイマの値に設定する。受信時刻ｔｒが条件ｔｓ−ｔｒ＞ｉｎｉｔ−ｂｕｆ−ｔｉｍｅの条件を満たすＮＡＬユニットが受信バッファにある場合は、受信時刻ｔｒがこの指定条件を満たすＮＡＬユニットが受信バッファ内になくなるまで、ＮＡＬユニットが指定順にデコーダに送られる（および受信バッファから取り出される）。

ＮＡＬユニットをデコーダに送る順は次のように指定する。

ＲＴＰセッションの開始時に０に初期化される変数をＰＤＯＮとする。１つのＤＯＮ値に対応するＮＡＬユニットごとに、ＤＯＮ距離を次のように計算する。ＮＡＬユニットのＤＯＮ値がＰＤＯＮ値より大きい場合は、ＤＯＮ距離はＤＯＮ−ＰＤＯＮに等しい。その他の場合は、ＤＯＮ距離は６５５３５−ＰＤＯＮ＋ＤＯＮ＋１に等しい。

ＮＡＬユニットは、ＤＯＮ距離の昇順でデコーダに配信される。ＤＯＮ距離の値が同じＮＡＬユニットがいくつかある場合は、これらのＮＡＬユニットはどのような順でデコーダに送られてもよい。所望数のＮＡＬユニットがデコーダに送られたら、ＰＤＯＮの値をデコーダに最後に送られたＮＡＬユニットのＤＯＮ値に設定する。

いくつかのピクチャを格納するために、ＤＰＢ２．１は複数のメモリ位置を含む。本明細書では、これらの位置をフレームストアとも呼ぶ。デコーダ２は受信ピクチャを正しい順で復号化する。

本発明は、多くの種類のシステムおよび装置に適用できる。エンコーダ１を含む送信装置６は、符号化されたピクチャを送信チャネル４に送信するための送信器７をさらに含むので都合がよい。受信装置８は符号化されたピクチャを受信する受信器９と、デコーダ２と、復号化されたピクチャを表示できる表示装置１０とを含む。送信チャネルは、たとえば、有線通信チャネルおよび／または無線通信チャネルとしうる。送信装置と受信装置とは、本発明によるビデオストリームの符号化／復号化処理を制御するために必要なステップを実行できる１つまたは複数のプロセッサ１．２、２．２をさらに含む。したがって、本発明による方法は、これらのプロセッサの機械が実行可能なステップとして主に実装することができる。ピクチャのバッファリングは、装置のメモリ１．３、２．３で実現することができる。エンコーダのプログラムコード１．４はメモリ１．３に格納することができる。また、デコーダのプログラムコード２．４は、メモリ２．３に格納することができる。

Claims (31)

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. 請求項２６に記載のエンコーダにおいて、メディアデータを含む前記送信ユニットがＶＣＬ ＮＡＬユニットであることを特徴とするエンコーダ。
29. データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれている符号化されたピクチャストリームを復号化するためのデコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示す、該ピクチャストリームの符号化において定義されるパラメータを用いて、該複数のデータ送信ユニットをバッファリングするバッファのサイズに関する要件を判定する手段を含むことを特徴とするデコーダ。
30. 請求項２９に記載のデコーダにおいて、前記デコーダが、メモリを備え、パラメータを使用する前記手段が、前記パラメータを調べ前記パラメータに応じて前記メモリからバッファリング用のメモリ位置を予約するプロセッサからなることを特徴とするデコーダ。
31. 請求項３０に記載のデコーダにおいて、前記符号化されたピクチャをバッファリングするために該予約されたメモリ位置を用いる手段を含むことを特徴とするデコーダ。

Images