(57)【要約】本発明は、マルチメディア情報をバッファリングする方法であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータが定義される方法に関する。本発明はまた、システムと、送信装置と、受信装置と、コンピュータプログラムプロダクトと、信号と、モジュールとに関する。
2006515137.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア情報をバッファリングするための方法であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータが定義される方法。
【請求項２】
請求項１に記載の方法であって、前記マルチメディアデータが符号化されたピクチャのスライスを含む方法。
【請求項３】
請求項１に記載の方法であって、マルチメディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットである方法。
【請求項４】
符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信およびバッファリングし、前記符号化されたピクチャストリームをデコーダで復号化する方法であって、前記パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータとして、前記バッファリング要件が前記復号化プロセスに示される方法。
【請求項５】
ピクチャを符号化するためのエンコーダを含むシステムであって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために定義されるパラメータが用意されているシステム。
【請求項６】
請求項５に記載のシステムであって、符号化されたピクチャを復号化するためのデコーダと、復号化されたピクチャをバッファリングするためのメモリとを含み、復号化されたピクチャをバッファリングするために前記メモリから予約すべきメモリ位置の必要量を判定するために使用される前記パラメータが用意されているシステム。
【請求項７】
請求項５に記載のシステムであって、前記マルチメディアデータが符号化されたピクチャのスライスを含むシステム。
【請求項８】
請求項５に記載の方法であって、マルチメディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットである方法。
【請求項９】
送信装置であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために定義されるパラメータが用意されている送信装置。
【請求項１０】
符号化されたピクチャストリームをスライスデータを含む送信ユニットとして受信する受信装置であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために使用されるパラメータが用意されている受信装置。
【請求項１１】
請求項１０に記載の受信装置であって、メモリと、前記パラメータを調べ、バッファリング用のメモリ位置を前記パラメータに従って前記メモリから予約するデファイナとを含む受信装置。
【請求項１２】
請求項１１に記載の受信装置であって、前記受信した符号化されたピクチャストリームからピクチャを復号化するためのデコーダと、前記符号化されたピクチャをバッファリングするために前記予約されたメモリ位置を使用する手段とを含む受信装置。
【請求項１３】
符号化されたピクチャをバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトであって、前記パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを定義するために機械が実行可能なステップをさらに含むコンピュータプログラムプロダクト。
【請求項１４】
信号であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを含む信号。
【請求項１５】
符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信するモジュールであって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために使用されるパラメータが用意されているモジュール。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、マルチメディア情報をバッファリングする方法に関する。本発明はまた、符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信し、このピクチャストリームをデコーダで復号化する方法に関する。本発明はさらに、システムと、送信装置と、受信装置と、コンピュータプログラムプロダクトと、信号と、モジュールとに関する。
【背景技術】
【０００２】
発明の背景
公開されているビデオ符号化規格はＩＴＵ−Ｔ  Ｈ．２６１、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−２、およびＩＳＯ／ＩＥＣ  ＭＰＥＧ−４パート２を含む。本願明細書では、これらの規格を従来のビデオ符号化規格と称する。
【０００３】
ビデオ通信方式
ビデオ通信方式は、対話型方式と非対話型方式とに分けることができる。対話型方式は、テレビ会議とテレビ電話とを含む。このような方式の例として、ＩＳＤＮ、ＩＰ、およびＰＳＴＮネットワークでそれぞれ運用されるテレビ会議／電話方式を規定するＩＴＵ−Ｔ勧告Ｈ．３２０、Ｈ．３２３、およびＨ．３２４が挙げられる。対話型方式は、ユーザエクスペリエンスを向上するために、エンドツーエンド（オーディオ・ビデオのキャプチャから遠端でのオーディオ・ビデオのプレゼンテーションまで）の遅延の最小化を目することを特徴とする。
【０００４】
非対話型方式は、再生装置、デジタルＴＶ、およびストリーミングの大容量メモリに格納されているビデオファイルやデジタル多用途ディスク（ＤＶＤ）など、記憶されているコンテンツの再生を含む。これらの技術分野における最も重要な規格について以下に概説する。
【０００５】
今日のデジタルビデオ家庭用電子機器において主流をなす１つの規格は、ビデオの圧縮、オーディオの圧縮、記憶、およびトランスポートに関する仕様を含むＭＰＥＧ−２である。符号化されたビデオの記憶およびトランスポートは、エレメンタリストリームの概念に基づく。１つのエレメンタリストリームは、単一ソース（たとえば、ビデオ）からの符号化されたデータと、このソース情報の同期化、特定、および特徴付けに必要な補助データとで構成される。エレメンタリストリームは、固定長または可変長の複数のパケットにパケット化され、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）を形成する。各ＰＥＳパケットは、ヘッダと、これに続くペイロードと称されるストリームデータとから成る。さまざまなエレメンタリストリームからのＰＥＳパケットが組み合わされて、ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）またはＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）のどちらかを形成する。ＰＳは、蓄積再生型のアプリケーションなど、無視しうる送信誤りを有するアプリケーションを対象としている。ＴＳは、送信誤りを許容するアプリケーションを対象としている。ただし、ＴＳは、ネットワークの一定スループットが保証されることを想定している。
【０００６】
ＩＴＵ−ＴとＩＳＯ／ＩＥＣとのジョイントビデオチーム（ＪＶＴ）は、ＩＴＵ−Ｔ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６−１０（ＭＰＥＧ−４パート１０）と同じ規格本文を含む規格草案を公開した。本文書では、この規格草案をＪＶＴ符号化規格と称し、この規格草案によるコーデックをＪＶＴコーデックと称する。
【０００７】
このコーデック仕様自体は、ビデオ符号化層（ＶＣＬ）とネットワーク抽象化層（ＮＡＬ）とを概念的に区別する。ＶＣＬは、コーデックの信号処理機能として、変換、量子化、動き検出／補償、ループフィルタなどを含む。これは、今日のビデオコーデックの大半、動き補償のあるインタピクチャ予測を用いるマクロブロックベースのコーダ、および残余信号の変換符号化の一般概念に従っている。ＶＣＬの出力は複数のスライスである。つまり、整数個数のマクロブロックから成るマクロブロックデータと、スライスヘッダの情報（スライス内の最初のマクロブロックの空間アドレスや初期量子化パラメータなどを含む情報）を含むビットストリングである。スライス内のマクロブロックはスキャン順に順序付けられるが、いわゆる可変マクロブロック順序付け構文を用いて異なるマクロブロック割り当てが指定される場合はこの限りでない。ピクチャ内予測は、スライス内においてのみ用いられる。
【０００８】
ＮＡＬは、ＶＣＬから出力されたスライスを、パケットネットワーク経由の送信またはパケット指向多重環境での使用に適したネットワーク抽象化層ユニット（ＮＡＬＵ）にカプセル化する。ＪＶＴの付属書Ｂには、このようなＮＡＬＵをバイトストリーム指向のネットワークで送信するためのカプセル化処理が定義されている。
【０００９】
Ｈ．２６３のオプションの参照ピクチャ選択モードおよびＭＰＥＧ−４パート２のＮＥＷＰＲＥＤ符号化ツールは、動き補償をピクチャセグメントごと、たとえば、Ｈ．２６３のスライスごと、に行うための参照フレームの選択を可能にする。さらに、Ｈ．２６３のオプションの拡張参照ピクチャ選択モードおよびＪＶＴ符号化規格は、各マクロブロック別の参照フレームの選択を可能にする。
【００１０】
参照ピクチャの選択は、多くの種類の時間スケーラビリティ方式を可能にする。図１は、時間スケーラビリティ方式の一例を示すが、本願明細書ではこの方式を再帰的時間スケーラビリティと称する。この例の方式は、３種類の一定フレームレートでの復号化が可能である。図２は、ビデオ冗長符号化と称される方式を示す。この方式では、複数のピクチャから成る１つのシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される。これらの図および以降のすべての図における矢印は、動き補償の方向を示し、各フレームの下の数字は、各フレームのキャプチャおよび表示の相対時刻に対応する。
【００１１】
送信順
従来のビデオ符号化規格では、Ｂピクチャの場合を除いて、ピクチャの復号化順は表示順と同じである。従来のＢピクチャ内の１つのブロックは、２つの参照ピクチャから時間的に双方向に予測できるが、これらの参照ピクチャの一方は、表示順において時間的に先行するピクチャであり、他方は時間的に後続するピクチャである。復号化順で最後の参照ピクチャのみが表示順においてＢピクチャに後続するるとができる（例外：Ｈ．２６３の飛越し符号化では、時間的に後続する１つの参照フレームの両フィールドピクチャが復号化順においてＢピクチャに先行することができる）。従来のＢピクチャは、時間予測のための参照ピクチャとして使用できないので、従来のＢピクチャは、他のどのピクチャの復号化にも影響を及ぼさずに、配置できる。
【００１２】
ＪＶＴ符号化規格は、これ以前の規格に比べ、以下の新規の技術的特徴を含む。
・ピクチャの復号化順が表示順から切り離される。ピクチャ番号が復号化順を示し、ピクチャ順カウントが表示順を示す。
・Ｂピクチャ内の１つのブロックの複数の参照ピクチャを表示順でＢピクチャの前にすることも、後にすることもできる。この結果、Ｂピクチャは、双方向ピクチャではなく、双予測ピクチャを表す。
・参照ピクチャとして使用されないピクチャには明示的に印が付けられる。どの種類（イントラ、インタ、Ｂなど）のピクチャでも、参照ピクチャまたは非参照ピクチャにすることができる。（したがって、Ｂピクチャは、他のピクチャの時間予測のための参照ピクチャとして使用できる。）
・ピクチャは、異なる符号化種別によって符号化された複数のスライスを含むことができる。すなわち、符号化ピクチャを、たとえば、イントラ符号化スライスとＢ符号化スライスとから構成しうる。
【００１３】
表示順を復号化順から切り離すと、圧縮効率および誤り耐性の点から好ましい場合がある。
【００１４】
圧縮効率を向上しうる予測構造の一例を図３に示す。四角形はピクチャを示し、四角形の中の大文字は符号化種別を示し、四角形の中の数字はＪＶＴの符号化規格によるピクチャ番号であり、矢印は予測依存性を示す。なお、ピクチャＢ１７は、ピクチャＢ１８の参照ピクチャである。符号化ピクチャパターンＰＢＢＰまたはＰＢＢＢＰによる従来の符号化に比べ、ピクチャＢ１８の参照ピクチャが時間的に近いので、従来の符号化に比べ圧縮効率が向上しうる。参照ピクチャの一部が双方向に予測されるので、従来の符号化ピクチャパターンＰＢＰに比べ、圧縮効率が向上しうる。
【００１５】
図４は、誤り耐性向上のために使用できるイントラピクチャ先送り方法の一例を示す。従来、イントラピクチャの符号化は、たとえば、シーンカットの直後やイントラピクチャのリフレッシュ期間の終了に対する応答として行われていた。イントラピクチャ先送り方法においては、イントラピクチャの符号化が必要になったときに直ちにイントラピクチャの符号化が行われず、代わりに時間的に後のピクチャがイントラピクチャとして選択される。符号化イントラピクチャとイントラピクチャの従来位置との間の各ピクチャは、時間的に次の後続ピクチャから予測される。図４に示すように、イントラピクチャ先送り方法では独立した２つのインタピクチャ予測チェーンが生成されるが、従来の符号化アルゴリズムでは単一のインタピクチャチェーンが生成される。２つのチェーンによるアプローチは、従来の単一チェーンによるアプローチに比べ、消去誤りに対してより堅牢であることは直観的に明らかである。一方のチェーンでパケット損失が発生しても、他方のチェーンは正しく受信されうる。従来の符号化においては、パケットの損失は、インタピクチャ予測チェーンの残りの部分に誤りを必ず伝播させる。
【００１６】
従来、デジタルビデオには、復号化順とプレゼンテーション順という２種類の順序付けおよびタイミング情報が対応付けられていた。以下に、関連技術をより詳しく見てゆく。
【００１７】
復号化タイムスタンプ（ＤＴＳ）は、符号化されたデータユニットを復号化すべき時刻を参照クロックを基準として示す。ＤＴＳを符号化して送信すると、ＤＴＳが２つの目的に役立つ。第１に、ピクチャの復号化順がその出力順と異なる場合は、復号化順がＤＴＳによって明示的に示される。第２に、受信レートがどの時点においても送信レートに近い場合は、一定のプリデコーダバッファリング動作がＤＴＳによって保証される。エンドツーエンドレイテンシが変動するネットワークにおいては、ＤＴＳの第２の用途は役に立たないか、またはほとんど役に立たない。代わりに、非圧縮ピクチャのための空間がポストデコーダバッファにあれば、受信されたデータができるだけ高速で復号化される。
【００１８】
ＤＴＳの移送は、使用される通信システムおよびビデオ符号化規格に依存する。ＭＰＥＧ−２方式においては、ＤＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＤＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできるので、オプションのハイポセティカルレファレンスデコーダの動作に用いられる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＤＴＳはその固有のボックス種別であるＤｅｃｏｄｉｎｇ  Ｔｉｍｅ  ｔｏ  Ｓａｍｐｌｅ  Ｂｏｘのみをサポートする。ＲＴＰによるストリーミング方式など、多くの方式においてＤＴＳがまったく運ばれない理由は、復号化順が送信順と同じであると想定されるので、正確な復号化時刻が重要な役割を果たさないからである。
【００１９】
Ｈ．２６３のオプションの付属書Ｕおよび付属書Ｗ．６．１２は、復号化順においてピクチャ番号を前の参照ピクチャから１だけ増加するように規定している。ＪＶＴ符号化規格においては、Ｈ．２６３のピクチャ番号と同様に、フレーム番号の符号化要素が規定されている。ＪＶＴ符号化規格は、瞬間デコーダリフレッシュ（ＩＤＲ）ピクチャと呼ばれる特定のイントラピクチャ種別を規定している。復号化順において後続のピクチャは、ＩＤＲピクチャより前のピクチャを参照することができない。ＩＤＲピクチャは、シーンチェンジに対する応答として符号化されることが多い。ＪＶＴ符号化規格においては、図５ａおよび図５ｂに示されるように、ＩＤＲピクチャ損失時の誤り耐性を向上するために、フレーム番号がＩＤＲピクチャで０にリセットされる。ただし、シーンチェンジの検出には、ＪＶＴ符号化規格のシーン情報ＳＥＩメッセージも使用できることは言うまでもない。
【００２０】
参照ピクチャの復号化順を復元するために、Ｈ．２６３のピクチャ番号を使用することができる。同様に、あるＩＤＲピクチャと復号化順で次のＩＤＲピクチャとの間（後者のＩＤＲピクチャは含まれない）のフレームの復号化順を復元するために、ＪＶＴフレーム番号を使用することができる。ただし、相補型参照フィールド対（それぞれのパリティが異なるフィールドとして符号化された連続ピクチャ）はフレーム番号が同一であるので、これらの復号化順をフレーム番号から再構成することはできない。
【００２１】
非参照ピクチャのＨ．２６３ピクチャ番号またはＪＶＴフレーム番号は、復号化順で前の参照ピクチャのピクチャ番号またはフレーム番号に１を加えた値に等しくすると規定されている。いくつかの非参照ピクチャが復号化順で連続している場合、これらのピクチャのピクチャ番号またはフレーム番号は同一である。非参照ピクチャのピクチャ番号またはフレーム番号は、復号化順で次の参照ピクチャのピクチャ番号またはフレーム番号とも同じである。連続する非参照ピクチャの復号化順は、Ｈ．２６３の時間参照（ＴＲ）符号化要素またはＪＶＴ符号化規格のピクチャ順カウント（ＰＯＣ）の概念を用いて復元することができる。
【００２２】
プレゼンテーションタイムスタンプ（ＰＴＳ）は、ピクチャを表示すべき時刻を参照クロックを基準として示す。プレゼンテーションタイムスタンプは、表示タイムスタンプ、出力タイムスタンプ、および合成タイムスタンプとも呼ばれる。
【００２３】
ＰＴＳの移送は、使用される通信システムおよびビデオ符号化標準に依存する。ＭＰＥＧ−２方式においては、ＰＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＰＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＰＴＳはその固有のボックス種別であるＣｏｍｐｏｓｉｔｉｏｎ  Ｔｉｍｅ  ｔｏ  Ｓａｍｐｌｅ  Ｂｏｘのみをサポートし、プレゼンテーションタイムスタンプは、対応する復号化タイムスタンプを基準として符号化される。ＲＴＰでは、ＲＴＰパケットヘッダ内のＲＴＰタイムスタンプは、ＰＴＳに対応する。
【００２４】
従来のビデオ符号化規格は、多くの側面においてＰＴＳと同様の時間参照（ＴＲ）符号化要素を特徴とする。ＭＰＥＧ−２ビデオなど従来の符号化標準によっては、グループオブピクチャ（ＧＯＰ）の先頭でＴＲをゼロにリセットするものもある。ＪＶＴ符号化規格においては、時間の概念がビデオ符号化層に存在しない。ピクチャ順カウント（ＰＯＣ）が各フレームおよび各フィールドに対して指定され、たとえばＢスライスの直接時間予測におけるＴＲと同様に使用される。ＰＯＣは、ＩＤＲピクチャでゼロにリセットされる。
【００２５】
バッファリング
ストリーミングのクライアントは、一般に、比較的大量のデータを格納できる受信バッファを有す。ストリーミングセッションが確立された初期状態において、クライアントはストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。このバッファリングは連続再生の維持に役立つが、その理由は送信遅延の増加またはネットワークのスループット低下が発生した場合でも、クライアントはバッファリングされたデータの復号化および再生を行えるからである。初期バッファリングを行わないと、クライアントは表示をフリーズし、復号化を停止し、着信データを待たねばならない。このバッファリングは、どのプロトコルレベルにおいても自動再送または選択的再送のためにも必要である。ピクチャの何れかの部分が失われた場合、損失データを再送するために再送機構を使用してもよい。予定された復号化時刻または再生時刻より前に再送データが受信されれば、損失は完全に復元される。
【００２６】
符号化されたピクチャは、復号化シーケンスの主観的品質における重要度に応じてランク付けすることができる。たとえば、従来のＢピクチャなどの非参照ピクチャは、損失しても他のどのピクチャの復号化にも影響しないので、主観的に最も重要でない。データパーティションまたはスライスグループ単位で主観的順位付けを行うこともできる。主観的に最も重要度が高い符号化スライスおよびデータパーティションをそれぞれの復号化順が示す順序より早く送信し、一方、主観的に最も重要度が低い符号化スライスおよびデータパーティションをそれぞれの本来の符号化順が示す順序より後に送信することができる。この結果、最も重要度が高いスライスおよびデータパーティションが部分的に再送される場合でも、最も重要度が低いスライスおよびデータパーティションに比べ、予定されているそれぞれの復号化時刻または再生時刻より前に受信される可能性が高い。
【００２７】
プリデコーダバッファリング
プリデコーダバッファリングとは、符号化されたデータを復号化する前にバッファリングすることをいう。初期バッファリングとは、ストリーミングセッションの先頭で行われるプリデコーダバッファリングをいう。従来、初期バッファリングは以下に示す２つの理由のために行われていた。
【００２８】
たとえばＩＰによるテレビ会議システムなどの対話型パケット交換マルチメディアシステムでは、種類の異なるメディアは通常それぞれ別のパケットで運ばれる。さらに、パケットは、一定の送信遅延を保証できず、遅延がパケットごとに変動しうるベストエフォート型ネットワークの上を運ばれるのが一般的である。この結果、同じプレゼンテーション（再生）タイムスタンプを有する複数のパケットが同一時刻に受信されず、２つのパケットの受信間隔がそれぞれのプレゼンテーションの間隔（時間）と異なることもありうる。したがって、異なるメディア種別間で再生の同期を維持し、正しい再生レートを維持するために、マルチメディア端末は、一般に受信データを短期間（たとえば、２分の１秒未満）バッファリングすることによって遅延変動を均す。本願明細書において、この種のバッファ構成要素を遅延ジッタバッファと称する。バッファリングは、メディアデータの復号化の前および／または後に行うことができる。
【００２９】
遅延ジッタバッファリングは、ストリーミングシステムでも利用される。ストリーミングは非対話型アプリケーションであるので、必要な遅延ジッタバッファは対話型アプリケーションよりはるかに大きなものとなりうる。ストリーミングプレーヤがサーバへの接続を確立し、マルチメディアストリームのダウンロードを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはストリームの再生を直ちには開始せず、一般に着信データをある時間、一般には２〜３秒間、バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングでは、対話型アプリケーションでの遅延ジッタバッファリングによる方法と同様の方法で、送信遅延の変動を均すことができる。さらに、失われたプロトコルデータユニット（ＰＤＵ）の再送をリンク層、トランスポート層、および／またはアプリケーション層で行える。プレーヤがバッファリングされたデータを復号化および再生している間に、再送されたＰＤＵが予定の復号化時刻および再生時刻に間に合うように受信されうる。
【００３０】
ストリーミングクライアントにおける初期バッファリングは、対話型システムでは実現できないさらに別の利点をもたらす。つまり、サーバから送信されるメディアのデータレートを変えることができる。すなわち、受信バッファがオーバフローまたはアンダーフローしない限り、メディアパケットの送信レートをその再生レートより一時的に高速化または低速化することができる。データレートの変動は、２つのソースから発生しうる。
【００３１】
第１に、ビデオなど、一部のメディア種別で達成可能な圧縮効率は、ソースデータの内容に応じて決まる。したがって、安定した品質が所望される場合は、圧縮されたビットストリームのビットレートが変動する。一般に、オーディオ・ビジュアル品質は、変動する品質より安定した品質の方が主観的に好ましい。したがって、初期バッファリングのないテレビ会議システムなどのシステムに比べ、より好ましいオーディオ・ビジュアル品質を初期バッファリングによって達成することができる。
【００３２】
第２に、固定ＩＰネットワークにおいてはパケット損失が集中的に発生することが一般に公知である。集中的な誤りの発生および高いピークビットレートおよびパケットレートを回避するために、適切に設計されたストリーミングサーバがパケットの送信を綿密にスケジューリングする。パケットは受信端での再生レートと正確に同じレートで送信されないこともあるが、サーバが送信パケット間の間隔の安定化を試みうる。サーバはまた、その時点のネットワーク条件に応じてパケットの送信レートを調整しうる。たとえば、ネットワーク輻輳時はパケットの送信レートを下げ、ネットワーク条件が許す場合はパケット送信レートを上げうる。
【００３３】
マルチメディアストリームの送信
１つのマルチメディアストリーミングシステムは、１つのストリーミングサーバと、ネットワーク経由でこのサーバにアクセスするいくつかのプレーヤとで構成される。ネットワークは、一般にパケット指向であり、サービス品質を保証するための手段は皆無か、またはほとんどない。プレーヤは、事前に格納されているマルチメディアコンテンツをフェッチするか、またはライブのマルチメディアコンテンツをサーバからフェッチし、ダウンロードされたコンテンツをリアルタイムで再生する。この通信種別は、ポイントツーポイントかマルチキャストのどちらかにしうる。ポイントツーポイントストリーミングでは、サーバはプレーヤごとにそれぞれ別の接続を設ける。マルチキャストストリーミングにおいては、サーバは単一のデータストリームをいくつかのプレーヤに送信し、必要に応じてネットワーク要素がストリームを複製する。
【００３４】
プレーヤがサーバへの接続を確立し、マルチメディアストリームを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはこのストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングは、切れ目のない再生の維持に役立つが、その理由は、送信遅延の増加またはネットワークのスループット低下が発生した場合でも、プレーヤはバッファリングされたデータの復号化および再生を行えるからである。
【００３５】
無制限の送信遅延を回避するために、信頼性の高いトランスポートプロトコルを採用することはストリーミングシステムにおいては一般的でない。代わりに、ストリーミングシステムは、より安定した送信遅延を継承する一方で、データの破損または損失も蒙る、ＵＤＰなどの信頼性の低いトランスポートプロトコルを使用する。
【００３６】
リアルタイム通信を制御するために、ＲＴＰおよびＲＴＣＰプロトコルをＵＤＰの上で使用することができる。ＲＴＰは、送信パケットの損失を検出し、受信端で正しいパケット順を再構築し、標本化タイムスタンプを各パケットに対応付ける手段を提供する。ＲＴＣＰは、正しく受信されたパケット部分の大きさに関する情報を伝えるので、フロー制御に用いることができる。
【００３７】
従来のビデオ符号化規格では、復号化順は出力順に結び付けられている。すなわち、ＩおよびＰピクチャの復号化順はそれぞれの出力順と同じであり、Ｂピクチャの復号化順は、出力順でそのＢピクチャに後続する参照ピクチャの復号化順の直後である。この結果、出力順がわかれば、復号化順の復元が可能である。出力順は、一般には基本ビデオビットストリームの時間参照（ＴＲ）フィールドで運ばれ、またシステム多重層でもＲＴＰヘッダなどで運ばれる。
【００３８】
一部のＲＴＰペイロード仕様では、復号化順以外の順序による符号化データの送信を可能にしている。順序移動量は、多くの関連仕様において同様に定義されている１つの値によって特徴付けるのが一般的である。たとえば、ＭＰＥＧ−４エレメンタリストリームのトランスポート用ＲＴＰペイロードフォーマット草案では、ｍａｘＤｉｓｐｌａｃｅｍｅｎｔパラメータを次のように指定する。
【００３９】
アクセスユニット（ＡＵ、符号化された１つのピクチャに対応）の最大移動時間は、パターン内のＡＵのタイムスタンプとまだ存在しない最先ＡＵのタイムスタンプとの間の最大の差である。すなわち、複数のＡＵがインタリーブされたシーケンスを考えると、次のようになる。
何れのｉおよび何れのｊ＞ｉについても、最大移動量＝最大｛ＴＳ（ｉ）−ＴＳ（ｊ）｝
但し、ｉおよびｊは、インタリーブパターン内のＡＵのインデックスを示し、ＴＳはＡＵのタイムスタンプを示す。
【００４０】
この方法にはいくつかの問題があり、バッファに対して大きすぎる値を付与することが本発明で認められた。
【発明の開示】
【発明が解決しようとする課題】
【００４１】
発明の要約
最大移動量の定義によってバッファリング要件（バッファ空間および初期バッファリング期間）をまったく指定できない方式の一例を次に示す。シーケンスを１５個のＡＵにスプライシングし、このような１５個のＡＵにおいて復号化および出力順が最後のＡＵを最初に送信し、他の全てのＡＵを復号化および出力順で送信する。したがって、ＡＵの送信シーケンスは次のようになる。
１４  ０  １  ２  ３  ４  ５  ６  ７  ８  ９  １０  １１  １２  １３  ２９  １５  １６  １７  １８  １９  ．．．
このシーケンスにおけるＡＵの最大移動量は１４である（１４＋ｋ＊１５）（ｋはすべて負でない整数値）。
【００４２】
ただし、このシーケンスに必要なバッファ空間および初期バッファリングは、１つのＡＵ分だけである。
【００４３】
Ｈ．２６４のＲＴＰペイロードフォーマット草案（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔ）においては、パラメータｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓは、ＮＡＬユニットストリームの特性または実装されている送信器または受信器の機能を伝えるために使用しうると規定されている。このパラメータは、ＮＡＬユニットストリーム内でＶＣＬ  ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつＲＴＰシーケンス番号順、またはＶＣＬ  ＮＡＬユニットを含む集約パケットの合成順でこのＶＣＬ  ＮＡＬユニットに後続するＶＣＬ  ＮＡＬユニットの最大数を指定する。このパラメータがない場合は、０に等しいｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓを暗黙で指定する必要がある。ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓの値は、０から３２７６７までの（両端の値を含む）範囲内の整数とする。
【００４４】
Ｈ．２６４規格によると、ＶＣＬ  ＮＡＬユニットは、１から５までの数に等しい値を有するｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＮＡＬユニットとして指定する。この規格では、次のＮＡＬユニット種別１〜５が定義されている。
１  非ＩＤＲピクチャの符号化スライス
２  符号化スライスデータパーティションＡ
３  符号化スライスデータパーティションＢ
４  符号化スライスデータパーティションＣ
５  ＩＤＲピクチャの符号化スライス
【００４５】
ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは、上記の最大移動量パラメータと同様の問題を引き起こす。つまり、このパラメータに基づきバッファリング空間および初期バッファリング時間の要件を判定することは不可能である。
【課題を解決するための手段】
【００４６】
本発明は、デコーダへの受信バッファのサイズの伝達を可能にする。
【００４７】
以下において、独立した１つのＧＯＰは、あるＩＤＲピクチャから復号化順で次のＩＤＲピクチャまでのピクチャから成る（後者のＩＤＲピクチャは含まれない）。
【００４８】
本発明においては、従来技術のシステムに比べ、バッファリングの必要最大量を伝達するパラメータがより正確に定義される。次の説明において、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、ビデオ信号を格納するシステムにも本発明を実装できることは言うまでもない。格納されるビデオ信号は、符号化前に格納される符号化されていない信号、符号化後に格納される符号化された信号、または符号化および復号化処理の後に格納される復号化された信号の何れでもよい。たとえば、エンコーダは、ビットストリームを送信順に出力する。ファイルシステムは、たとえば復号化順にカプセル化され、ファイルとして格納されたオーディオおよび／またはビデオビットストリームを受信する。このファイルは、データベースに格納でき、このデータベースからストリーミングサーバがＮＡＬユニットを読み出し、ＲＴＰパケットにカプセル化することができる。
【００４９】
さらに、次の説明では、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、エンコーダが符号化されたデータを出力し、ストリーミングサーバなどの別の構成要素に第１の順で送信し、この別の構成要素がこの符号化されたデータを第１の順から別の順に並べ替え、この新しい順に必要なバッファサイズを定義し、この符号化されたデータを並べ替えられた形式でデコーダに転送するシステムにも本発明を実装できることは明らかである。
【００５０】
本発明の第１の態様によると、マルチメディア情報をバッファリングする方法であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータが定義される方法が提供される。
【００５１】
本発明の第２の態様によると、符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信し、符号化されたピクチャをバッファリングし、符号化されたピクチャストリームをデコーダで復号化する方法であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータとして、バッファリング要件が復号化プロセスに示される方法が提供される。
【００５２】
本発明の第３の態様によると、ピクチャの符号化のためのエンコーダと、符号化されたピクチャをバッファリングするためのバッファとを含むシステムであって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために定義されるパラメータが用意されているシステムが提供される。
【００５３】
本発明の第４の態様によると、送信装置であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために定義されるパラメータが用意されている送信装置が提供される。
【００５４】
本発明の第５の態様によると、符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信する受信装置であって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために使用されるパラメータが用意されている受信装置が提供される。
【００５５】
本発明の第６の態様によると、符号化されたピクチャをバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトであって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを定義するために機械が実行可能なステップをさらに含むコンピュータプログラムプロダクトが提供される。
【００５６】
本発明の第７の態様によると、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを含む信号が提供される。
【００５７】
本発明の第８の態様によると、符号化されたピクチャストリームをマルチメディアデータを含む送信ユニットとして受信するモジュールであって、パケットストリーム内でマルチメディアデータを含む何れかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むこの送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すために使用されるパラメータが用意されているモジュールが提供される。
【００５８】
本発明の一実施例においては、マルチメディアデータを含む送信ユニットは、ＶＣＬ  ＮＡＬユニットである。
【００５９】
本発明は、符号化システムのバッファリング効率を向上させる。本発明を用いると、実際に必要な適量のバッファリングの使用が可能になる。したがって、符号化装置内の符号化バッファおよび復号化装置内の復号化前バッファに必要以上のメモリを割り当てる必要がない。また、復号化前バッファのオーバフローを回避できる。
【発明を実施するための最良の形態】
【００６０】
発明の詳細な記述
次に、図５のシステム、図６のエンコーダ１、および図７のデコーダ２を参照しながら、本発明をより詳細に説明する。符号化するピクチャは、たとえば、カメラやビデオレコーダなどのビデオソース３からのビデオストリームのピクチャとすることができる。ビデオストリームの各ピクチャ（フレーム）は、スライスなどのより小さな複数の部分に分割することができる。スライスは、さらにブロックに分割することができる。送信チャネル４を介して、または記憶メディア（図示せず）に送信される情報を減らすために、ビデオストリームはエンコーダ１において符号化される。ビデオストリームの各ピクチャは、エンコーダ１に入力される。エンコーダは、符号化するピクチャの一部を一時的に格納するための符号化バッファ１．１（図６）を有する。エンコーダ１は、本発明による符号化タスクを適用できるプロセッサ１．２とメモリ１．３とをさらに含む。メモリ１．３およびプロセッサ１．２を送信装置６と共通にすることも、送信装置６の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を送信装置６に設けることもできる。ビデオストリームを圧縮するために、エンコーダ１は、動きの推定および／または他のいくつかのタスクを実行する。動きの推定においては、符号化するピクチャ（現在のピクチャ）と前および／または後のピクチャとの間の類似点が探される。類似点が見つかると、比較したピクチャまたはその一部を符号化対象ピクチャの参照ピクチャとして用いる。ＪＶＴでは、ピクチャの表示順と復号化順とが必ずしも同じではないので、参照ピクチャが参照ピクチャとして使われる限りは、参照ピクチャをバッファ（たとえば、符号化バッファ１．１）に格納する必要がある。また、エンコーダ１はピクチャの表示順に関する情報を送信ストリームに挿入する。
【００６１】
必要であれば、符号化されたピクチャは、符号化プロセスから符号化ピクチャバッファ５．２に移動される。符号化されたピクチャは、エンコーダ１から送信チャネル４を介してデコーダ２に送信される。デコーダ２では、符号化されたピクチャが復号化され、符号化ピクチャにできる限り対応する非圧縮ピクチャが形成される。
【００６２】
デコーダ１は、本発明による復号化タスクを適用できるプロセッサ２．２とメモリ２．３とをさらに含む。プロセッサ２．２とメモリ２．３とは受信装置８と共通にすることも、または受信装置８の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を受信装置８に設けることもできる。
【００６３】
符号化
次に、符号化・復号化プロセスをより詳細に考えてみよう。ビデオソース３からのピクチャはエンコーダ１に入力され、さらに符号化バッファ１．１に格納されるので都合がよい。符号化プロセスは最初のピクチャがエンコーダに入力された直後に必ずしも開始されず、符号化バッファ１．１内の利用可能なピクチャが一定量になってから開始される。次に、エンコーダ１は、参照フレームとして使用する適切な候補をこれらのピクチャから見つけようとする。次に、エンコーダ１は符号化を実行して、符号化されたピクチャを形成する。符号化されたピクチャは、たとえば、予測ピクチャ（Ｐ）、双予測ピクチャ（Ｂ）、および／またはイントラ符号化ピクチャ（Ｉ）である。イントラ符号化ピクチャの復号化は他のどのピクチャも使用せずに行えるが、他の種類のピクチャの復号化には少なくとも１つの参照ピクチャが必要である。上記のどのピクチャ種別のピクチャでも参照ピクチャとして使用できる。
【００６４】
エンコーダは、復号化タイムスタンプ（ＤＴＳ）および出力タイムスタンプ（ＯＴＳ）の２つのタイムスタンプをピクチャに添付するので都合がよい。デコーダはこれらのタイムスタンプを使用して正しい復号化時刻とピクチャの出力（表示）時刻とを判定する。ただし、これらのタイムスタンプはデコーダに必ずしも送信されず、あるいはデコーダが使用しないこともある。
【００６５】
ＮＡＬユニットは、異なる種類のパケットで配信することができる。この好都合な実施形態においては、複数の異なるパケットフォーマットとして、単純パケットと集約パケットとが挙げられる。集約パケットは、シングルタイム集約パケットとマルチタイム集約パケットとにさらに分割することができる。
【００６６】
ＲＴＰパケットのペイロードフォーマットは、必要に応じて、いくつかの異なるペイロード構造として定義される。ただし、受信されるＲＴＰパケットがどの構造を含むかは、ペイロードの先頭バイトから明らかである。このバイトは、ＮＡＬユニットヘッダとして必ず構成される。ＮＡＬユニットタイプフィールドは、どの構造が存在するかを示す。ありうる構造は、単一ＮＡＬユニットパケット、集約パケット、およびフラグメントユニットである。単一ＮＡＬユニットパケットは、ペイロード中にＮＡＬユニットを１つだけ含む。ＮＡＬヘッダタイプフィールドは本来のＮＡＬユニットタイプに等しい、すなわち１から２３までの範囲に含まれる。集約パケットタイプは、複数のＮＡＬユニットを単一のＲＴＰペイロードに集約するために使用される。このパケットは４つのバージョンがある。すなわち、シングルタイム集約パケットタイプＡ（ＳＴＡＰ−Ａ）、シングルタイム集約パケットタイプＢ（ＳＴＡＰ−Ｂ）、マルチタイム集約パケット（ＭＴＡＰ）の１６ビットオフセット版（ＭＴＡＰ１６）、およびマルチタイム集約パケット（ＭＴＡＰ）の２４ビットオフセット版（ＭＴＡＰ２４）が存在する。ＳＴＡＰ−Ａ、ＳＴＡＰ−Ｂ、ＭＴＡＰ１６、およびＭＴＡＰ２４に割り当てられたＮＡＬユニットタイプ番号は、それぞれ２４、２５、２６、および２７である。フラグメントユニットは、単一のＮＡＬユニットを複数のＲＴＰパケットにわたってフラグメント化するために使用する。フラグメントユニットは２つのバージョンが存在し、それぞれＮＡＬユニットタイプ番号２８および２９で識別される。
【００６７】
ＲＴＰパケット送信のために定義されるパケット化モードとして、次の３つのケースがある。
・単一ＮＡＬユニットモード
・非インタリーブドモード
・インタリーブドモード
【００６８】
単一ＮＡＬユニットモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠した対話型システムを対象とする。非インタリーブドモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠しない場合もある対話型システムを対象とする。非インタリーブドモードでは、ＮＡＬユニットはＮＡＬユニットの復号化順で送信される。インタリーブドモードは、エンドツーエンドレイテンシを極めて小さくする必要がないシステムを対象とする。インタリーブドモードでは、ＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が可能である。
【００６９】
使用されているパケット化モードは、パケット化モードを指定するオプションのＭＩＭＥパラメータの値または外部手段によって通知しうる。使用されているパケット化モードに応じて、ＲＴＰペイロードで使用しうるＮＡＬユニットタイプが決まる。
【００７０】
インタリーブドパケット化モードでは、ＮＡＬユニットの送信順をＮＡＬユニットの復号化順と同じにする必要がない。復号化順序号（ＤＯＮ）は、ペイロード構造内のフィールド、またはＮＡＬユニットの復号化順を示す派生変数である。
【００７１】
送信順と復号化順との結合は、次のようにインタリーブ深さを指定するオプションのＭＩＭＥパラメータによって制御する。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０に等しく、復号化順以外でのＮＡＬユニットの送信が外部手段によって禁止されている場合、ＮＡＬユニットの送信順はＮＡＬユニットの復号化順に従う。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０より大きい場合、またはＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が外部手段によって許容されている場合は、
・マルチタイム集約パケット１６（ＭＴＡＰ１６）およびマルチタイム集約パケット２４（ＭＴＡＰ２４）内のＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がなく、また
・２つの連続するパケット内のシングルタイム集約パケットＢ（ＳＴＡＰ−Ｂ）、ＭＴＡＰ、およびフラグメントユニット（ＦＵ）のデカプセル化によって合成されるＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がない。
【００７２】
単一ＮＡＬユニットパケット、ＳＴＡＰ−Ａ、およびＦＵ−ＡのＲＴＰペイロード構造は、ＤＯＮを含まない。ＳＴＡＰ−Ｂ構造およびＦＵ−Ｂ構造はＤＯＮを含み、ＭＴＡＰの構造はＤＯＮの派生を可能にする。
【００７３】
送信器がパケットごとに１つのＮＡＬユニットをカプセル化し、ＮＡＬユニットの復号化順以外でパケットを送信する必要がある場合は、ＳＴＡＰ−Ｂパケットタイプを使用することができる。
【００７４】
単一ＮＡＬユニットパケット化モードでは、一連のＮＡＬユニットの送信順はこれらのＮＡＬユニットの復号化順と同じである。非インタリーブドパケット化モードでは、単一ＮＡＬユニットパケットおよびＳＴＡＰ−Ａ、およびＦＵ−Ａ内のＮＡＬユニットの送信順は、これらのＮＡＬユニットの復号化順と同じである。ＳＴＡＰ内のＮＡＬユニットは、ＮＡＬユニットの復号化順に現れる。
【００７５】
Ｈ．２６４では、表示順と異なる復号化順が許容されるので、ＲＴＰタイムスタンプの値がＲＴＰシーケンス番号に応じて単調非減少とならない場合もある。
【００７６】
送信順で最初のＮＡＬユニットのＤＯＮ値は次の何れかの値に設定しうる。ＤＯＮの値は、０から６５５３５までの（両端の値を含む）範囲内の何れかである。最大値に達すると、ＤＯＮの値は０に折り返す。
【００７７】
この仕様によるビデオシーケンスは、ＮＡＬＵストリームの他の部分から独立して複合化可能なＮＡＬＵストリームのどの部分でもよい。
【００７８】
堅牢なパケットスケジューリングの一例を以下に示す。
【００７９】
次の例の図では、時間は左から右へ流れ、ＩはＩＤＲピクチャを示し、Ｒは参照ピクチャを示し、Ｎは非参照ピクチャを示し、数字は復号化順で前のＩＤＲピクチャに比例する相対的な出力時刻を示す。ピクチャシーケンスの下の値は、システムクロックのタイムスタンプ目盛りを示し、この例ではこれらの目盛りは適宜初期化される。Ｉ、Ｒ、およびＮピクチャは、符号化、送信、および復号化にかかる時間が皆無であると仮定して、前の処理ステップがある場合は前のステップに比べて同じ時系列にマッピングされる。
【００８０】
複数のビデオシーケンス内のピクチャのサブセットを以下に出力順に示す。
【数１】
2006515137.tif 000003
【００８１】
これらのピクチャの符号化（および復号化）順は、次のように左から右への順である。
【数２】
2006515137.tif 000004
【００８２】
１つのピクチャの復号化順序号（ＤＯＮ）は、復号化順で前のピクチャのＤＯＮ値に１を加えた値に等しい。
【００８３】
単純化するために、次のように仮定してみよう。
・シーケンスのフレームレートは一定である。
・各ピクチャは単一のスライスで構成される。
・各スライスは単一のＮＡＬユニットパケットにカプセル化される。
・ピクチャは復号化順で送信される。
・ピクチャは一定間隔で送信される（つまり、１／フレームレートに等しい）。
【００８４】
したがって、ピクチャは次のように復号化順で受信される。
【数３】
2006515137.tif 000005
【００８５】
送信（または受信順）から正しい復号化順を復元するためにバッファリングする必要がないので、ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは０に設定される。
【００８６】
以下に示すようにピクチャを復号化順から出力順に編成するために、デコーダは初めに１つのピクチャ間隔をその復号化ピクチャバッファにバッファリングする必要がある。
【数４】
2006515137.tif 000006
【００８７】
復号化ピクチャバッファに必要な初期バッファリング量は、バッファリング期間ＳＥＩメッセージによって通知することも、Ｈ．２６４のビデオユーザビリティ情報のｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ構文要素の値によって通知することもできる。ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは、シーケンス内で何れかのフレーム、相補型フィールド対、または非対フィールドに復号化順先行し、出力順で後続するフレーム、相補型フィールド対、または非対フィールドの最大数を示す。
【００８８】
単純化するために、復号化ピクチャバッファ内の初期バッファを示すために、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓが使用されると仮定する。この例では、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは１に等しい。
【００８９】
ＩＤＲピクチャ１００が送信中に失われ、システムクロックの値が６２のときに再送要求が発行された場合、再送されたＩＤＲピクチャ１００を受信する時間として１つのピクチャ間隔（システムクロックがタイムスタンプ６３に達するまでの時間）しかないことがわかる。
【００９０】
次に、各ＩＤＲピクチャの送信位置がそれぞれの復号化位置よりフレーム間隔２つ分だけ前である、すなわち、ピクチャが次の順に送信される、と仮定してみよう。
【数５】
2006515137.tif 000007
【００９１】
変数ｉｄ１を従来技術（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔに開示）に従って指定してみよう。つまり、ＮＡＬユニットストリーム内で何れかのＶＣＬ  ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつこのＶＣＬ  ＮＡＬユニットを含む集約パケットの合成順またはＲＴＰシーケンス番号順でこのＶＣＬ  ＮＡＬユニットに後続するＶＣＬ  ＮＡＬユニットの最大量を指定する。変数ｉｄ２を本発明に従って指定してみよう。つまり、ＮＡＬユニットストリーム内の何れかのＶＣＬ  ＮＡＬユニットに送信順で先行し、かつそのＶＣＬ  ＮＡＬユニットに復号化順で後続するＶＣＬ  ＮＡＬユニットの最大量を指定する。
【００９２】
この例では、ｉｄ１の値は２に等しく、ｉｄ２の値は１に等しい。第２節で既に見たように、ｉｄ１の値は、受信順から復号化順にパケットを並べ替えるための初期バッファリングに必要なバッファリング空間または時間に比例しない。この例では、以下に図示するように（この図は受信器のバッファリング処理の出力を表す）、復号化順を復元するには、１ピクチャ間隔に等しい初期バッファリング時間が必要である。この例はまた、本発明によると、初期バッファリング時間およびバッファリング空間の値を割り出せることを実証する。
【数６】
2006515137.tif 000008
【００９３】
以下に示すように、ピクチャを復号化順から出力順に編成するために必要な初期バッファリング遅延もまた、１ピクチャ間隔である。
【数７】
2006515137.tif 000009
【００９４】
アプリケーション層、トランスポート層、またはリンク層での再送を含む送信中にＩＤＲピクチャが蒙りうる最大遅延はｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ＋ｉｄ２に等しいことが観察される。したがって、ＩＤＲピクチャの損失耐性は、再送をサポートするシステムで向上される。
【００９５】
受信器は、各ピクチャに対応付けられているＤＯＮの値に基づき、ピクチャを復号化順に編成することができる。
【００９６】
送信
最初の符号化ピクチャが用意されると直ちに符号化ピクチャの送信および／または格納（およびオプションの仮想復号化）を行うことができる。復号化順と出力順とが必ずしも同じではないので、このピクチャがデコーダ出力順で最初のピクチャになるとは限らない。
【００９７】
ビデオストリームの最初のピクチャが符号化されたら、送信を開始できる。符号化ピクチャは、符号化ピクチャバッファ１．２に格納することもできる。送信をこれより後の段階で開始することもでき、たとえばビデオストリームの一定部分が符号化された後に開始することもできる。
【００９８】
デコーダ２は、復号化されたピクチャを、たとえばピクチャ順カウントの順序付けを用いて、正しい順で出力するはずである。
【００９９】
デパケット化
デパケット化処理は実装依存である。したがって、以下の説明は適切な一実装例に関するものであり、実装をこれだけに限定するものではない。他の方式も使用しうる。記載のアルゴリズムに対する最適化も可能である。
【０１００】
これらのデパケット化規則の背後にある一般概念は、ＮＡＬユニットの送信順からＮＡＬユニットの配信順への並べ替えである。
【０１０１】
復号化
次に、受信器８の動作を説明する。受信器８は１つのピクチャに属する全てのパケットを収集し、これらを１つの妥当な順に並べる。順序の厳密性は使用するプロファイルによって異なる。受信パケットは受信バッファ９．１（プリデコーディングバッファ）に格納される。受信器８は使用不能なものをすべて廃棄し、残りをデコーダ２に送る。集約パケットは、それぞれのペイロードをＮＡＬＵを運ぶ個々のＲＴＰパケットに書き出すことによって処理される。これらのＮＡＬＵは、それぞれ別のＲＴＰパケットとして受信されたかのように、集約パケット内の配置順で処理される。
【０１０２】
次に、パケットストリーム内で何れかのＶＣＬ  ＮＡＬユニットにＮＡＬユニット送信順で先行し、そのＶＣＬ  ＮＡＬユニットに復号化順で後続するＶＣＬ  ＮＡＬユニットの最大量を指定する、オプションのｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータ（ｉｎｔｅｒｌｅａｖｉｎｇ−ｄｅｐｔｈパラメータ）の値をＮにしてみよう。このパラメータがない場合は、０値の数を暗示しうる。
【０１０３】
このビデオストリーム転送セッションを初期化すると、受信器８は、少なくともＮ個のＶＣＬ  ＮＡＬユニットを格納するためのメモリを受信バッファ９．１に対して割り当てる。次にこの受信器は、ビデオストリームの受信を開始し、受信したＶＣＬ  ＮＡＬユニットを受信バッファに格納する。初期バッファリングは、次の何れかの条件が満たされるまで続く。
・少なくともＮ個のＶＣＬ  ＮＡＬユニットが受信バッファ９．１に格納される。
・ＭＩＭＥパラメータｍａｘ−ｄｏｎ−ｄｉｆｆが存在する場合は、関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の値がｍａｘ−ｄｏｎ−ｄｉｆｆの値を超える。ここで、ｎは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応し、ｍは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最小のＮＡＬユニットに対応する。
・初期バッファリングの継続時間がＭＩＭＥのオプションパラメータｉｎｉｔ−ｂｕｆ−ｔｉｍｅの値に等しくなるか、またはこれを超える。
【０１０４】
関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）は次のように指定する。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝０
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。
【０１０５】
ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の正の値は、送信順インデックスｎのＮＡＬユニットが送信順インデックスｍのＮＡＬユニットに復号化順で後続することを示す。
【０１０６】
ＡｂｓＤＯＮは、ＮＡＬユニットのこのような復号化順序号が６５５３５の後で０に折り返されないことを示す。すなわち、ＡｂｓＤＯＮは次のように計算される。
【０１０７】
ｍとｎとが送信順で連続するＮＡＬユニットであるとする。送信順で先頭（インデックス０）のＮＡＬユニットは、ＡｂｓＤＯＮ（０）＝ＤＯＮ（０）である。他のＮＡＬユニットのＡｂｓＤＯＮは、次のように計算される。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。
【０１０８】
受信バッファ９．１が少なくともＮ個のＶＣＬ  ＮＡＬユニットを収容すると、ＮＡＬユニットは受信バッファ９．１から１つずつ取り出され、デコーダ２に送られる。ＮＡＬユニットが受信バッファ９．１から取り出される順は必ずしも格納された順ではなく、以下に説明するようにＮＡＬユニットのＤＯＮに従う。デコーダ２へのパケットの配信は、バッファ内のＶＣＬ  ＮＡＬユニットの数がＮ個より少なくなるまで、すなわちＶＣＬ  ＮＡＬユニットがＮ−１個になるまで続く。
【０１０９】
受信バッファから取り出されるＮＡＬユニットの数は次のように決められる。
・受信バッファが少なくともＮ個のＶＣＬ  ＮＡＬユニットを収容すると、バッファ内のＶＣＬ  ＮＡＬユニットがＮ−１個になるまで、以下に示す順でＮＡＬユニットが受信器のバッファから取り出され、デコーダに送られる。
・ｍａｘ−ｄｏｎ−ｄｉｆｆがある場合は、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）のｍがｍａｘ−ｄｏｎ−ｄｉｆｆより大きいすべてのＮＡＬユニットが以下の指定順で受信バッファから取り出され、デコーダに送られる。ここで、ｎは、受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応する。
・変数ｔｓを、ＮＡＬユニットストリームの最初のパケットが受信されたときに０に初期化されたシステムタイマの値に設定する。受信時刻ｔｒが条件ｔｓ−ｔｒ＞ｉｎｉｔ−ｂｕｆ−ｔｉｍｅの条件を満たすＮＡＬユニットが受信バッファにある場合は、受信時刻ｔｒがこの指定条件を満たすＮＡＬユニットが受信バッファ内になくなるまで、ＮＡＬユニットが指定順にデコーダに送られる（および受信バッファから取り出される）。
【０１１０】
ＮＡＬユニットをデコーダに送る順は次のように指定する。
【０１１１】
ＲＴＰセッションの開始時に０に初期化される変数をＰＤＯＮとする。１つのＤＯＮ値に対応するＮＡＬユニットごとに、ＤＯＮ距離を次のように計算する。ＮＡＬユニットのＤＯＮ値がＰＤＯＮ値より大きい場合は、ＤＯＮ距離はＤＯＮ−ＰＤＯＮに等しい。その他の場合は、ＤＯＮ距離は６５５３５−ＰＤＯＮ＋ＤＯＮ＋１に等しい。
【０１１２】
ＮＡＬユニットは、ＤＯＮ距離の昇順でデコーダに配信される。ＤＯＮ距離の値が同じＮＡＬユニットがいくつかある場合は、これらのＮＡＬユニットはどのような順でデコーダに送られてもよい。所望数のＮＡＬユニットがデコーダに送られたら、ＰＤＯＮの値をデコーダに最後に送られたＮＡＬユニットのＤＯＮ値に設定する。
【０１１３】
いくつかのピクチャを格納するために、ＤＰＢ２．１は複数のメモリ位置を含む。本明細書では、これらの位置をフレームストアとも呼ぶ。デコーダ２は受信ピクチャを正しい順で復号化する。
【０１１４】
本発明は、多くの種類のシステムおよび装置に適用できる。エンコーダ１を含む送信装置６は、符号化されたピクチャを送信チャネル４に送信するための送信器７をさらに含むので都合がよい。受信装置８は符号化されたピクチャを受信する受信器９と、デコーダ２と、復号化されたピクチャを表示できる表示装置１０とを含む。送信チャネルは、たとえば、有線通信チャネルおよび／または無線通信チャネルとしうる。送信装置と受信装置とは、本発明によるビデオストリームの符号化／復号化処理を制御するために必要なステップを実行できる１つまたは複数のプロセッサ１．２、２．２をさらに含む。したがって、本発明による方法は、これらのプロセッサの機械が実行可能なステップとして主に実装することができる。ピクチャのバッファリングは、装置のメモリ１．３、２．３で実現することができる。エンコーダのプログラムコード１．４はメモリ１．３に格納することができる。また、デコーダのプログラムコード２．４は、メモリ２．３に格納することができる。
【図面の簡単な説明】
【０１１５】
【図１】再帰的時間スケーラビリティ方式の一例を示す。
【図２】１つのピクチャシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される、ビデオ冗長符号化と称される方式を示す。
【図３】圧縮効率を向上しうる予測構造の一例を示す。
【図４】誤り耐性の向上のために使用できるイントラピクチャ先送り方法の一例を示す。
【図５】本発明によるシステムの好都合な実施形態を示す。
【図６】本発明によるエンコーダの好都合な実施形態を示す。
【図７】本発明によるデコーダの好都合な実施形態を示す。
【図１】
2006515137.tif 000010
【図２】
2006515137.tif 000011
【図３】
2006515137.tif 000012
【図４】
2006515137.tif 000013
【図５】
2006515137.tif 000014
【図６】
2006515137.tif 000015
【図７】
2006515137.tif 000016
【手続補正書】
【提出日】平成17年2月18日(2005.2.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファにバッファリングする方法であって、パケットストリーム内のいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータが定義される方法。
【請求項２】
請求項１に記載の方法であって、
ビデオデータと、
オーディオデータと、のうちの少なくとも１つが前記マルチメディアデータに含まれる方法。
【請求項３】
請求項１または請求項２に記載の方法であって、前記メディアデータが符号化されたピクチャのスライスを含む方法。
【請求項４】
請求項１、請求項２、または請求項３に記載の方法であって、メディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットである方法。
【請求項５】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして受信およびバッファリングされた、符号化されたピクチャストリームをデコーダで復号化する方法であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータとしてバッファリング要件が復号化プロセスに示される方法。
【請求項６】
ピクチャを符号化するためのエンコーダと、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファリングするためのバッファとを含むシステムであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために定義されるパラメータが用意されているシステム。
【請求項７】
請求項６に記載のシステムであって、符号化されたピクチャを復号化するためのデコーダと、復号化されたピクチャをバッファリングするためのメモリとを含み、復号化されたピクチャをバッファリングするために前記メモリから予約すべきメモリ位置の必要量を判定するために前記パラメータが使われるように用意されているシステム。
【請求項８】
請求項６に記載のシステムであって、前記マルチメディアデータが符号化されたピクチャのスライスを含むシステム。
【請求項９】
請求項６に記載のシステムであって、前記データ送信ユニットがＶＣＬ  ＮＡＬユニットであるシステム。
【請求項１０】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを送信するための送信装置であって、パケットストリーム内のいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために定義されるパラメータが用意されている送信装置。
【請求項１１】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するための受信装置であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために使用されるパラメータが用意されている受信装置。
【請求項１２】
請求項１１に記載の受信装置であって、メモリと、前記パラメータを調べ、バッファリング用のメモリ位置を前記パラメータに従って前記メモリから予約するデファイナとを含む受信装置。
【請求項１３】
請求項１２に記載の受信装置であって、前記受信した符号化されたピクチャストリームからピクチャを復号化するためのデコーダと、前記符号化されたピクチャをバッファリングするために前記予約されたメモリ位置を使用する手段とを含む受信装置。
【請求項１４】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットに含まれている、符号化されたピクチャをバッファにバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するために機械が実行可能なステップをさらに含むコンピュータプログラムプロダクト。
【請求項１５】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを運ぶ信号であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを含む信号。
【請求項１６】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するためのモジュールであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために使用されるパラメータが用意されているモジュール。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００５０
【補正方法】変更
【補正の内容】
【００５０】
本発明の第１の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファにバッファリングする方法であって、パケットストリーム内のいずれかの送信ユニットに送信順で先行し、かつその送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータが定義される方法が提供される。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００５１
【補正方法】変更
【補正の内容】
【００５１】
本発明の第２の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして受信およびバッファリングされた、符号化されたピクチャストリームをデコーダで復号化する方法であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータとして、バッファリング要件が復号化プロセスに示される方法が提供される。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００５２
【補正方法】変更
【補正の内容】
【００５２】
本発明の第３の態様によると、ピクチャを符号化するためのエンコーダと、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファリングするためのバッファとを含むシステムであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために定義されるパラメータが用意されているシステムが提供される。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【００５３】
本発明の第４の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを送信するための送信装置であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために定義されるパラメータが用意されている送信装置が提供される。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
本発明の第５の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信する受信装置であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために使用されるパラメータが用意されている受信装置が提供される。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００５５
【補正方法】変更
【補正の内容】
【００５５】
本発明の第６の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれている、符号化されたピクチャをバッファにバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するために機械が実行可能なステップをさらに含むコンピュータプログラムプロダクトが提供される。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【００５６】
本発明の第７の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを運ぶ信号であって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、そのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを含む信号が提供される。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００５７
【補正方法】変更
【補正の内容】
【００５７】
本発明の第８の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するためのモジュールであって、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すために使用されるパラメータが用意されているモジュールが提供される。


【手続補正書】
【提出日】平成17年9月13日(2005.9.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファにバッファリングする方法において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すためにパラメータが定義されることを特徴とする方法。
【請求項２】
請求項１に記載の方法において、
ビデオデータと、
オーディオデータと、のうちの少なくとも１つが前記マルチメディアデータに含まれることを特徴とする方法。
【請求項３】
請求項１または請求項２に記載の方法において、前記メディアデータが符号化されたピクチャのスライスを含むことを特徴とする方法。
【請求項４】
請求項１、請求項２、または請求項３に記載の方法において、メディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットであることを特徴とする方法。
【請求項５】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信およびバッファリングし、デコーダで復号化する方法において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータとして、バッファリング要件が復号化プロセスに示されることを特徴とする方法。
【請求項６】
請求項５に記載の方法において、前記パラメータが調べられ、前記パラメータに応じてバッファリング用のメモリ位置が予約されることを特徴とする方法。
【請求項７】
請求項６に記載の受信装置において、受信した符号化されたピクチャストリームからピクチャを復号化し、符号化されたピクチャを予約されたメモリ位置を用いてバッファリングすることを特徴とする受信装置。
【請求項８】
ピクチャを符号化するためのエンコーダと、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファリングするためのバッファとを含むシステムにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするシステム。
【請求項９】
請求項８に記載のシステムにおいて、符号化されたピクチャを復号化するためのデコーダと、復号化されたピクチャをバッファリングするためのメモリとを含み、復号化されたピクチャをバッファリングするために前記メモリから予約すべきメモリ位置の必要量を判定するために前記パラメータが使われるように用意されていることを特徴とするシステム。
【請求項１０】
請求項８に記載のシステムにおいて、前記マルチメディアデータが符号化されたピクチャのスライスを含むことを特徴とするシステム。
【請求項１１】
請求項８に記載のシステムにおいて、前記データ送信ユニットがＶＣＬ  ＮＡＬユニットであることを特徴とするシステム。
【請求項１２】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを送信するための送信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とする送信装置。
【請求項１３】
請求項１２に記載の送信装置において、前記マルチメディアデータが符号化されたピクチャのスライスを含むことを特徴とする送信装置。
【請求項１４】
請求項１２に記載の送信装置において、マルチメディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットであることを特徴とする送信装置。
【請求項１５】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するための受信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続する送信ユニットの最大数を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とする受信装置。
【請求項１６】
請求項１５に記載の受信装置において、前記受信装置がメモリを含み、パラメータを使用する前記手段が前記パラメータを調べ、前記パラメータに応じて前記メモリからバッファリング用のメモリ位置を予約するためのデファイナを含むことを特徴とする受信装置。
【請求項１７】
請求項１６に記載の受信装置において、前記受信した符号化されたピクチャストリームからピクチャを復号化するためのデコーダと、前記符号化されたピクチャをバッファリングするために前記予約されたメモリ位置を使用する手段とを含むことを特徴とする受信装置。
【請求項１８】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャをバッファにバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するために機械が実行可能なステップをさらに含むことを特徴とするコンピュータプログラムプロダクト。
【請求項１９】
マルチメディアデータを含む複数の送信ユニットとして受信した符号化されたピクチャストリームを復号化するために機械が実行可能なステップと、送信ユニットをバッファリングするために機械が実行可能なステップと、を含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する送信ユニットの最大量を示すパラメータを用いて、復号化プロセスに対するバッファリング要件を判定するために機械が実行可能なステップを含むことを特徴とするコンピュータプログラムプロダクト。
【請求項２０】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを運ぶ信号において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを含むことを特徴とする信号。
【請求項２１】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するためのモジュールにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするモジュール。
【請求項２２】
送信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを定義するようになっているデファイナを含むことを特徴とするプロセッサ。
【請求項２３】
請求項２２に記載のプロセッサにおいて、前記マルチメディアデータが符号化されたピクチャのスライスを含むことを特徴とするプロセッサ。
【請求項２４】
請求項２２に記載のプロセッサにおいて、マルチメディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットであることを特徴とするプロセッサ。
【請求項２５】
符号化されたピクチャストリームをスライスデータを含む送信ユニットとして受信する受信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含む前記送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするプロセッサ。
【請求項２６】
請求項２５に記載のプロセッサにおいて、前記プロセッサがメモリを備え、パラメータを使用する前記手段が前記パラメータを調べ、前記パラメータに応じて前記メモリからバッファリング用のメモリ位置を予約するためのデファイナを備えることを特徴とするプロセッサ。
【請求項２７】
請求項２５に記載のプロセッサにおいて、前記プロセッサが受信された符号化ピクチャストリームからピクチャを復号化するためのデコーダと、前記符号化されたピクチャをバッファリングするために前記予約されたメモリ位置を使用する手段とを備えることを特徴とするプロセッサ。
【請求項２８】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを符号化するためのエンコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするエンコーダ。
【請求項２９】
請求項２８に記載のエンコーダにおいて、前記マルチメディアデータが符号化されたピクチャのスライスを含むことを特徴とするエンコーダ。
【請求項３０】
請求項２８に記載のエンコーダにおいて、マルチメディアデータを含む前記送信ユニットがＶＣＬ  ＮＡＬユニットであることを特徴とするエンコーダ。
【請求項３１】
データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれている符号化されたピクチャストリームを復号化するためのデコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつ前記データ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするデコーダ。
【請求項３２】
請求項３１に記載のデコーダにおいて、前記デコーダがメモリを備え、パラメータを使用する前記手段が前記パラメータを調べ、前記パラメータに応じて前記メモリからバッファリング用のメモリ位置を予約するためのデファイナを含むことを特徴とするデコーダ。
【請求項３３】
請求項３２に記載のデコーダにおいて、前記符号化されたピクチャをバッファリングするために予約されたメモリ位置を用いる手段を含むことを特徴とするデコーダ。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、マルチメディア情報をバッファリングする方法に関する。本発明はまた、符号化されたピクチャストリームを、マルチメディアデータを含む送信ユニットとして受信し、このピクチャストリームをデコーダで復号化する方法に関する。本発明は、システムと、送信装置と、受信装置と、符号化されたピクチャをバッファリングするためのコンピュータプログラムプロダクトと、符号化されたピクチャストリームを復号化するためのコンピュータプログラムプロダクトと、信号と、モジュールと、送信装置内でメディアデータを処理するためのプロセッサと、受信装置内でメディアデータを処理するためのプロセッサと、エンコーダと、デコーダとにさらに関する。
【背景技術】
【０００２】
発明の背景
公開されているビデオ符号化規格はＩＴＵ−Ｔ  Ｈ．２６１、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−２、およびＩＳＯ／ＩＥＣ  ＭＰＥＧ−４パート２を含む。本願明細書では、これらの規格を従来のビデオ符号化規格と称する。
【０００３】
ビデオ通信方式
ビデオ通信方式は、対話型方式と非対話型方式とに分けることができる。対話型方式は、テレビ会議とテレビ電話とを含む。このような方式の例として、ＩＳＤＮ、ＩＰ、およびＰＳＴＮネットワークでそれぞれ運用されるテレビ会議／電話方式を規定するＩＴＵ−Ｔ勧告Ｈ．３２０、Ｈ．３２３、およびＨ．３２４が挙げられる。対話型方式は、ユーザエクスペリエンスを向上するために、エンドツーエンド（オーディオ・ビデオのキャプチャから遠端でのオーディオ・ビデオのプレゼンテーションまで）の遅延の最小化を目することを特徴とする。
【０００４】
非対話型方式は、再生装置、デジタルＴＶ、およびストリーミングの大容量メモリに格納されているビデオファイルやデジタル多用途ディスク（ＤＶＤ）など、記憶されているコンテンツの再生を含む。これらの技術分野における最も重要な規格について以下に概説する。
【０００５】
今日のデジタルビデオ家庭用電子機器において主流をなす１つの規格は、ビデオの圧縮、オーディオの圧縮、記憶、およびトランスポートに関する仕様を含むＭＰＥＧ−２である。符号化されたビデオの記憶およびトランスポートは、エレメンタリストリームの概念に基づく。１つのエレメンタリストリームは、単一ソース（たとえば、ビデオ）からの符号化されたデータと、このソース情報の同期化、特定、および特徴付けに必要な補助データとで構成される。エレメンタリストリームは、固定長または可変長の複数のパケットにパケット化され、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）を形成する。各ＰＥＳパケットは、ヘッダと、これに続くペイロードと称されるストリームデータとから成る。さまざまなエレメンタリストリームからのＰＥＳパケットが組み合わされて、ＰＳ（Ｐｒｏｇｒａｍ  Ｓｔｒｅａｍ）またはＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）のどちらかを形成する。ＰＳは、蓄積再生型のアプリケーションなど、無視しうる送信誤りを有するアプリケーションを対象としている。ＴＳは、送信誤りを許容するアプリケーションを対象としている。ただし、ＴＳは、ネットワークの一定スループットが保証されることを想定している。
【０００６】
ＩＴＵ−ＴとＩＳＯ／ＩＥＣとのジョイントビデオチーム（ＪＶＴ）は、ＩＴＵ−Ｔ勧告Ｈ．２６４およびＩＳＯ／ＩＥＣ国際規格１４４９６−１０（ＭＰＥＧ−４パート１０）と同じ規格本文を含む規格草案を公開した。本文書では、この規格草案をＪＶＴ符号化規格と称し、この規格草案によるコーデックをＪＶＴコーデックと称する。
【０００７】
このコーデック仕様自体は、ビデオ符号化層（ＶＣＬ）とネットワーク抽象化層（ＮＡＬ）とを概念的に区別する。ＶＣＬは、コーデックの信号処理機能として、変換、量子化、動き検出／補償、ループフィルタなどを含む。これは、今日のビデオコーデックの大半、動き補償のあるインタピクチャ予測を用いるマクロブロックベースのコーダ、および残余信号の変換符号化の一般概念に従っている。ＶＣＬの出力は複数のスライスである。つまり、整数個数のマクロブロックから成るマクロブロックデータと、スライスヘッダの情報（スライス内の最初のマクロブロックの空間アドレスや初期量子化パラメータなどを含む情報）を含むビットストリングである。スライス内のマクロブロックはスキャン順に順序付けられるが、いわゆる可変マクロブロック順序付け構文を用いて異なるマクロブロック割り当てが指定される場合はこの限りでない。ピクチャ内予測は、スライス内においてのみ用いられる。
【０００８】
ＮＡＬは、ＶＣＬから出力されたスライスを、パケットネットワーク経由の送信またはパケット指向多重環境での使用に適したネットワーク抽象化層ユニット（ＮＡＬＵ）にカプセル化する。ＪＶＴの付属書Ｂには、このようなＮＡＬＵをバイトストリーム指向のネットワークで送信するためのカプセル化処理が定義されている。
【０００９】
Ｈ．２６３のオプションの参照ピクチャ選択モードおよびＭＰＥＧ−４パート２のＮＥＷＰＲＥＤ符号化ツールは、動き補償をピクチャセグメントごと、たとえば、Ｈ．２６３のスライスごと、に行うための参照フレームの選択を可能にする。さらに、Ｈ．２６３のオプションの拡張参照ピクチャ選択モードおよびＪＶＴ符号化規格は、各マクロブロック別の参照フレームの選択を可能にする。
【００１０】
参照ピクチャの選択は、多くの種類の時間スケーラビリティ方式を可能にする。図１は、時間スケーラビリティ方式の一例を示すが、本願明細書ではこの方式を再帰的時間スケーラビリティと称する。この例の方式は、３種類の一定フレームレートでの復号化が可能である。図２は、ビデオ冗長符号化と称される方式を示す。この方式では、複数のピクチャから成る１つのシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される。これらの図および以降のすべての図における矢印は、動き補償の方向を示し、各フレームの下の数字は、各フレームのキャプチャおよび表示の相対時刻に対応する。
【００１１】
送信順
従来のビデオ符号化規格では、Ｂピクチャの場合を除いて、ピクチャの復号化順は表示順と同じである。従来のＢピクチャ内の１つのブロックは、２つの参照ピクチャから時間的に双方向に予測できるが、これらの参照ピクチャの一方は、表示順において時間的に先行するピクチャであり、他方は時間的に後続するピクチャである。復号化順で最後の参照ピクチャのみが表示順においてＢピクチャに後続するるとができる（例外：Ｈ．２６３の飛越し符号化では、時間的に後続する１つの参照フレームの両フィールドピクチャが復号化順においてＢピクチャに先行することができる）。従来のＢピクチャは、時間予測のための参照ピクチャとして使用できないので、従来のＢピクチャは、他のどのピクチャの復号化にも影響を及ぼさずに、配置できる。
【００１２】
ＪＶＴ符号化規格は、これ以前の規格に比べ、以下の新規の技術的特徴を含む。
・ピクチャの復号化順が表示順から切り離される。ピクチャ番号が復号化順を示し、ピクチャ順カウントが表示順を示す。
・Ｂピクチャ内の１つのブロックの複数の参照ピクチャを表示順でＢピクチャの前にすることも、後にすることもできる。この結果、Ｂピクチャは、双方向ピクチャではなく、双予測ピクチャを表す。
・参照ピクチャとして使用されないピクチャには明示的に印が付けられる。どの種類（イントラ、インタ、Ｂなど）のピクチャでも、参照ピクチャまたは非参照ピクチャにすることができる。（したがって、Ｂピクチャは、他のピクチャの時間予測のための参照ピクチャとして使用できる。）
・ピクチャは、異なる符号化種別によって符号化された複数のスライスを含むことができる。すなわち、符号化ピクチャを、たとえば、イントラ符号化スライスとＢ符号化スライスとから構成しうる。
【００１３】
表示順を復号化順から切り離すと、圧縮効率および誤り耐性の点から好ましい場合がある。
【００１４】
圧縮効率を向上しうる予測構造の一例を図３に示す。四角形はピクチャを示し、四角形の中の大文字は符号化種別を示し、四角形の中の数字はＪＶＴの符号化規格によるピクチャ番号であり、矢印は予測依存性を示す。なお、ピクチャＢ１７は、ピクチャＢ１８の参照ピクチャである。符号化ピクチャパターンＰＢＢＰまたはＰＢＢＢＰによる従来の符号化に比べ、ピクチャＢ１８の参照ピクチャが時間的に近いので、従来の符号化に比べ圧縮効率が向上しうる。参照ピクチャの一部が双方向に予測されるので、従来の符号化ピクチャパターンＰＢＰに比べ、圧縮効率が向上しうる。
【００１５】
図４は、誤り耐性向上のために使用できるイントラピクチャ先送り方法の一例を示す。従来、イントラピクチャの符号化は、たとえば、シーンカットの直後やイントラピクチャのリフレッシュ期間の終了に対する応答として行われていた。イントラピクチャ先送り方法においては、イントラピクチャの符号化が必要になったときに直ちにイントラピクチャの符号化が行われず、代わりに時間的に後のピクチャがイントラピクチャとして選択される。符号化イントラピクチャとイントラピクチャの従来位置との間の各ピクチャは、時間的に次の後続ピクチャから予測される。図４に示すように、イントラピクチャ先送り方法では独立した２つのインタピクチャ予測チェーンが生成されるが、従来の符号化アルゴリズムでは単一のインタピクチャチェーンが生成される。２つのチェーンによるアプローチは、従来の単一チェーンによるアプローチに比べ、消去誤りに対してより堅牢であることは直観的に明らかである。一方のチェーンでパケット損失が発生しても、他方のチェーンは正しく受信されうる。従来の符号化においては、パケットの損失は、インタピクチャ予測チェーンの残りの部分に誤りを必ず伝播させる。
【００１６】
従来、デジタルビデオには、復号化順とプレゼンテーション順という２種類の順序付けおよびタイミング情報が対応付けられていた。以下に、関連技術をより詳しく見てゆく。
【００１７】
復号化タイムスタンプ（ＤＴＳ）は、符号化されたデータユニットを復号化すべき時刻を参照クロックを基準として示す。ＤＴＳを符号化して送信すると、ＤＴＳが２つの目的に役立つ。第１に、ピクチャの復号化順がその出力順と異なる場合は、復号化順がＤＴＳによって明示的に示される。第２に、受信レートがどの時点においても送信レートに近い場合は、一定のプリデコーダバッファリング動作がＤＴＳによって保証される。エンドツーエンドレイテンシが変動するネットワークにおいては、ＤＴＳの第２の用途は役に立たないか、またはほとんど役に立たない。代わりに、非圧縮ピクチャのための空間がポストデコーダバッファにあれば、受信されたデータができるだけ高速で復号化される。
【００１８】
ＤＴＳの移送は、使用される通信システムおよびビデオ符号化規格に依存する。ＭＰＥＧ−２方式においては、ＤＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＤＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできるので、オプションのハイポセティカルレファレンスデコーダの動作に用いられる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＤＴＳはその固有のボックス種別であるＤｅｃｏｄｉｎｇ  Ｔｉｍｅ  ｔｏ  Ｓａｍｐｌｅ  Ｂｏｘのみをサポートする。ＲＴＰによるストリーミング方式など、多くの方式においてＤＴＳがまったく運ばれない理由は、復号化順が送信順と同じであると想定されるので、正確な復号化時刻が重要な役割を果たさないからである。
【００１９】
Ｈ．２６３のオプションの付属書Ｕおよび付属書Ｗ．６．１２は、復号化順においてピクチャ番号を前の参照ピクチャから１だけ増加するように規定している。ＪＶＴ符号化規格においては、Ｈ．２６３のピクチャ番号と同様に、フレーム番号の符号化要素が規定されている。ＪＶＴ符号化規格は、瞬間デコーダリフレッシュ（ＩＤＲ）ピクチャと呼ばれる特定のイントラピクチャ種別を規定している。復号化順において後続のピクチャは、ＩＤＲピクチャより前のピクチャを参照することができない。ＩＤＲピクチャは、シーンチェンジに対する応答として符号化されることが多い。ＪＶＴ符号化規格においては、図５ａおよび図５ｂに示されるように、ＩＤＲピクチャ損失時の誤り耐性を向上するために、フレーム番号がＩＤＲピクチャで０にリセットされる。ただし、シーンチェンジの検出には、ＪＶＴ符号化規格のシーン情報ＳＥＩメッセージも使用できることは言うまでもない。
【００２０】
参照ピクチャの復号化順を復元するために、Ｈ．２６３のピクチャ番号を使用することができる。同様に、あるＩＤＲピクチャと復号化順で次のＩＤＲピクチャとの間（後者のＩＤＲピクチャは含まれない）のフレームの復号化順を復元するために、ＪＶＴフレーム番号を使用することができる。ただし、相補型参照フィールド対（それぞれのパリティが異なるフィールドとして符号化された連続ピクチャ）はフレーム番号が同一であるので、これらの復号化順をフレーム番号から再構成することはできない。
【００２１】
非参照ピクチャのＨ．２６３ピクチャ番号またはＪＶＴフレーム番号は、復号化順で前の参照ピクチャのピクチャ番号またはフレーム番号に１を加えた値に等しくすると規定されている。いくつかの非参照ピクチャが復号化順で連続している場合、これらのピクチャのピクチャ番号またはフレーム番号は同一である。非参照ピクチャのピクチャ番号またはフレーム番号は、復号化順で次の参照ピクチャのピクチャ番号またはフレーム番号とも同じである。連続する非参照ピクチャの復号化順は、Ｈ．２６３の時間参照（ＴＲ）符号化要素またはＪＶＴ符号化規格のピクチャ順カウント（ＰＯＣ）の概念を用いて復元することができる。
【００２２】
プレゼンテーションタイムスタンプ（ＰＴＳ）は、ピクチャを表示すべき時刻を参照クロックを基準として示す。プレゼンテーションタイムスタンプは、表示タイムスタンプ、出力タイムスタンプ、および合成タイムスタンプとも呼ばれる。
【００２３】
ＰＴＳの移送は、使用される通信システムおよびビデオ符号化標準に依存する。ＭＰＥＧ−２方式においては、ＰＴＳをＰＥＳパケットのヘッダ内の一項目として送信することもできる。ＪＶＴ符号化規格においては、ＰＴＳを補足的拡張情報（ＳＥＩ）の一部として運ぶこともできる。ＩＳＯの基準メディアファイルフォーマットにおいては、ＰＴＳはその固有のボックス種別であるＣｏｍｐｏｓｉｔｉｏｎ  Ｔｉｍｅ  ｔｏ  Ｓａｍｐｌｅ  Ｂｏｘのみをサポートし、プレゼンテーションタイムスタンプは、対応する復号化タイムスタンプを基準として符号化される。ＲＴＰでは、ＲＴＰパケットヘッダ内のＲＴＰタイムスタンプは、ＰＴＳに対応する。
【００２４】
従来のビデオ符号化規格は、多くの側面においてＰＴＳと同様の時間参照（ＴＲ）符号化要素を特徴とする。ＭＰＥＧ−２ビデオなど従来の符号化標準によっては、グループオブピクチャ（ＧＯＰ）の先頭でＴＲをゼロにリセットするものもある。ＪＶＴ符号化規格においては、時間の概念がビデオ符号化層に存在しない。ピクチャ順カウント（ＰＯＣ）が各フレームおよび各フィールドに対して指定され、たとえばＢスライスの直接時間予測におけるＴＲと同様に使用される。ＰＯＣは、ＩＤＲピクチャでゼロにリセットされる。
【００２５】
バッファリング
ストリーミングのクライアントは、一般に、比較的大量のデータを格納できる受信バッファを有す。ストリーミングセッションが確立された初期状態において、クライアントはストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。このバッファリングは連続再生の維持に役立つが、その理由は送信遅延の増加またはネットワークのスループット低下が発生した場合でも、クライアントはバッファリングされたデータの復号化および再生を行えるからである。初期バッファリングを行わないと、クライアントは表示をフリーズし、復号化を停止し、着信データを待たねばならない。このバッファリングは、どのプロトコルレベルにおいても自動再送または選択的再送のためにも必要である。ピクチャの何れかの部分が失われた場合、損失データを再送するために再送機構を使用してもよい。予定された復号化時刻または再生時刻より前に再送データが受信されれば、損失は完全に復元される。
【００２６】
符号化されたピクチャは、復号化シーケンスの主観的品質における重要度に応じてランク付けすることができる。たとえば、従来のＢピクチャなどの非参照ピクチャは、損失しても他のどのピクチャの復号化にも影響しないので、主観的に最も重要でない。データパーティションまたはスライスグループ単位で主観的順位付けを行うこともできる。主観的に最も重要度が高い符号化スライスおよびデータパーティションをそれぞれの復号化順が示す順序より早く送信し、一方、主観的に最も重要度が低い符号化スライスおよびデータパーティションをそれぞれの本来の符号化順が示す順序より後に送信することができる。この結果、最も重要度が高いスライスおよびデータパーティションが部分的に再送される場合でも、最も重要度が低いスライスおよびデータパーティションに比べ、予定されているそれぞれの復号化時刻または再生時刻より前に受信される可能性が高い。
【００２７】
プリデコーダバッファリング
プリデコーダバッファリングとは、符号化されたデータを復号化する前にバッファリングすることをいう。初期バッファリングとは、ストリーミングセッションの先頭で行われるプリデコーダバッファリングをいう。従来、初期バッファリングは以下に示す２つの理由のために行われていた。
【００２８】
たとえばＩＰによるテレビ会議システムなどの対話型パケット交換マルチメディアシステムでは、種類の異なるメディアは通常それぞれ別のパケットで運ばれる。さらに、パケットは、一定の送信遅延を保証できず、遅延がパケットごとに変動しうるベストエフォート型ネットワークの上を運ばれるのが一般的である。この結果、同じプレゼンテーション（再生）タイムスタンプを有する複数のパケットが同一時刻に受信されず、２つのパケットの受信間隔がそれぞれのプレゼンテーションの間隔（時間）と異なることもありうる。したがって、異なるメディア種別間で再生の同期を維持し、正しい再生レートを維持するために、マルチメディア端末は、一般に受信データを短期間（たとえば、２分の１秒未満）バッファリングすることによって遅延変動を均す。本願明細書において、この種のバッファ構成要素を遅延ジッタバッファと称する。バッファリングは、メディアデータの復号化の前および／または後に行うことができる。
【００２９】
遅延ジッタバッファリングは、ストリーミングシステムでも利用される。ストリーミングは非対話型アプリケーションであるので、必要な遅延ジッタバッファは対話型アプリケーションよりはるかに大きなものとなりうる。ストリーミングプレーヤがサーバへの接続を確立し、マルチメディアストリームのダウンロードを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはストリームの再生を直ちには開始せず、一般に着信データをある時間、一般には２〜３秒間、バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングでは、対話型アプリケーションでの遅延ジッタバッファリングによる方法と同様の方法で、送信遅延の変動を均すことができる。さらに、失われたプロトコルデータユニット（ＰＤＵ）の再送をリンク層、トランスポート層、および／またはアプリケーション層で行える。プレーヤがバッファリングされたデータを復号化および再生している間に、再送されたＰＤＵが予定の復号化時刻および再生時刻に間に合うように受信されうる。
【００３０】
ストリーミングクライアントにおける初期バッファリングは、対話型システムでは実現できないさらに別の利点をもたらす。つまり、サーバから送信されるメディアのデータレートを変えることができる。すなわち、受信バッファがオーバフローまたはアンダーフローしない限り、メディアパケットの送信レートをその再生レートより一時的に高速化または低速化することができる。データレートの変動は、２つのソースから発生しうる。
【００３１】
第１に、ビデオなど、一部のメディア種別で達成可能な圧縮効率は、ソースデータの内容に応じて決まる。したがって、安定した品質が所望される場合は、圧縮されたビットストリームのビットレートが変動する。一般に、オーディオ・ビジュアル品質は、変動する品質より安定した品質の方が主観的に好ましい。したがって、初期バッファリングのないテレビ会議システムなどのシステムに比べ、より好ましいオーディオ・ビジュアル品質を初期バッファリングによって達成することができる。
【００３２】
第２に、固定ＩＰネットワークにおいてはパケット損失が集中的に発生することが一般に公知である。集中的な誤りの発生および高いピークビットレートおよびパケットレートを回避するために、適切に設計されたストリーミングサーバがパケットの送信を綿密にスケジューリングする。パケットは受信端での再生レートと正確に同じレートで送信されないこともあるが、サーバが送信パケット間の間隔の安定化を試みうる。サーバはまた、その時点のネットワーク条件に応じてパケットの送信レートを調整しうる。たとえば、ネットワーク輻輳時はパケットの送信レートを下げ、ネットワーク条件が許す場合はパケット送信レートを上げうる。
【００３３】
マルチメディアストリームの送信
１つのマルチメディアストリーミングシステムは、１つのストリーミングサーバと、ネットワーク経由でこのサーバにアクセスするいくつかのプレーヤとで構成される。ネットワークは、一般にパケット指向であり、サービス品質を保証するための手段は皆無か、またはほとんどない。プレーヤは、事前に格納されているマルチメディアコンテンツをフェッチするか、またはライブのマルチメディアコンテンツをサーバからフェッチし、ダウンロードされたコンテンツをリアルタイムで再生する。この通信種別は、ポイントツーポイントかマルチキャストのどちらかにしうる。ポイントツーポイントストリーミングでは、サーバはプレーヤごとにそれぞれ別の接続を設ける。マルチキャストストリーミングにおいては、サーバは単一のデータストリームをいくつかのプレーヤに送信し、必要に応じてネットワーク要素がストリームを複製する。
【００３４】
プレーヤがサーバへの接続を確立し、マルチメディアストリームを要求すると、サーバは要求されたストリームの送信を開始する。プレーヤはこのストリームの再生を直ちには開始せず、一般に着信データを２〜３秒間バッファリングする。本願明細書において、このバッファリングを初期バッファリングと称する。初期バッファリングは、切れ目のない再生の維持に役立つが、その理由は、送信遅延の増加またはネットワークのスループット低下が発生した場合でも、プレーヤはバッファリングされたデータの復号化および再生を行えるからである。
【００３５】
無制限の送信遅延を回避するために、信頼性の高いトランスポートプロトコルを採用することはストリーミングシステムにおいては一般的でない。代わりに、ストリーミングシステムは、より安定した送信遅延を継承する一方で、データの破損または損失も蒙る、ＵＤＰなどの信頼性の低いトランスポートプロトコルを使用する。
【００３６】
リアルタイム通信を制御するために、ＲＴＰおよびＲＴＣＰプロトコルをＵＤＰの上で使用することができる。ＲＴＰは、送信パケットの損失を検出し、受信端で正しいパケット順を再構築し、標本化タイムスタンプを各パケットに対応付ける手段を提供する。ＲＴＣＰは、正しく受信されたパケット部分の大きさに関する情報を伝えるので、フロー制御に用いることができる。
【００３７】
従来のビデオ符号化規格では、復号化順は出力順に結び付けられている。すなわち、ＩおよびＰピクチャの復号化順はそれぞれの出力順と同じであり、Ｂピクチャの復号化順は、出力順でそのＢピクチャに後続する参照ピクチャの復号化順の直後である。この結果、出力順がわかれば、復号化順の復元が可能である。出力順は、一般には基本ビデオビットストリームの時間参照（ＴＲ）フィールドで運ばれ、またシステム多重層でもＲＴＰヘッダなどで運ばれる。
【００３８】
一部のＲＴＰペイロード仕様では、復号化順以外の順序による符号化データの送信を可能にしている。順序移動量は、多くの関連仕様において同様に定義されている１つの値によって特徴付けるのが一般的である。たとえば、ＭＰＥＧ−４エレメンタリストリームのトランスポート用ＲＴＰペイロードフォーマット草案では、ｍａｘＤｉｓｐｌａｃｅｍｅｎｔパラメータを次のように指定する。
【００３９】
アクセスユニット（ＡＵ、符号化された１つのピクチャに対応）の最大移動時間は、パターン内のＡＵのタイムスタンプとまだ存在しない最先ＡＵのタイムスタンプとの間の最大の差である。すなわち、複数のＡＵがインタリーブされたシーケンスを考えると、次のようになる。
何れのｉおよび何れのｊ＞ｉについても、最大移動量＝最大｛ＴＳ（ｉ）−ＴＳ（ｊ）｝
但し、ｉおよびｊは、インタリーブパターン内のＡＵのインデックスを示し、ＴＳはＡＵのタイムスタンプを示す。
【００４０】
この方法にはいくつかの問題があり、バッファに対して大きすぎる値を付与することが本発明で認められた。
【発明の開示】
【発明が解決しようとする課題】
【００４１】
発明の要約
最大移動量の定義によってバッファリング要件（バッファ空間および初期バッファリング期間）をまったく指定できない方式の一例を次に示す。シーケンスを１５個のＡＵにスプライシングし、このような１５個のＡＵにおいて復号化および出力順が最後のＡＵを最初に送信し、他の全てのＡＵを復号化および出力順で送信する。したがって、ＡＵの送信シーケンスは次のようになる。
１４  ０  １  ２  ３  ４  ５  ６  ７  ８  ９  １０  １１  １２  １３  ２９  １５  １６  １７  １８  １９  ．．．
このシーケンスにおけるＡＵの最大移動量は１４である（１４＋ｋ＊１５）（ｋはすべて負でない整数値）。
【００４２】
ただし、このシーケンスに必要なバッファ空間および初期バッファリングは、１つのＡＵ分だけである。
【００４３】
Ｈ．２６４のＲＴＰペイロードフォーマット草案（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔ）においては、パラメータｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓは、ＮＡＬユニットストリームの特性または実装されている送信器または受信器の機能を伝えるために使用しうると規定されている。このパラメータは、ＮＡＬユニットストリーム内でＶＣＬ  ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつＲＴＰシーケンス番号順、またはＶＣＬ  ＮＡＬユニットを含む集約パケットの合成順でこのＶＣＬ  ＮＡＬユニットに後続するＶＣＬ  ＮＡＬユニットの最大数を指定する。このパラメータがない場合は、０に等しいｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓを暗黙で指定する必要がある。ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓの値は、０から３２７６７までの（両端の値を含む）範囲内の整数とする。
【００４４】
Ｈ．２６４規格によると、ＶＣＬ  ＮＡＬユニットは、１から５までの数に等しい値を有するｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＮＡＬユニットとして指定する。この規格では、次のＮＡＬユニット種別１〜５が定義されている。
１  非ＩＤＲピクチャの符号化スライス
２  符号化スライスデータパーティションＡ
３  符号化スライスデータパーティションＢ
４  符号化スライスデータパーティションＣ
５  ＩＤＲピクチャの符号化スライス
【００４５】
ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは、上記の最大移動量パラメータと同様の問題を引き起こす。つまり、このパラメータに基づきバッファリング空間および初期バッファリング時間の要件を判定することは不可能である。
【課題を解決するための手段】
【００４６】
本発明は、デコーダへの受信バッファのサイズの伝達を可能にする。
【００４７】
以下において、独立した１つのＧＯＰは、あるＩＤＲピクチャから復号化順で次のＩＤＲピクチャまでのピクチャから成る（後者のＩＤＲピクチャは含まれない）。
【００４８】
本発明においては、従来技術のシステムに比べ、バッファリングの必要最大量を伝達するパラメータがより正確に定義される。次の説明において、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、ビデオ信号を格納するシステムにも本発明を実装できることは言うまでもない。格納されるビデオ信号は、符号化前に格納される符号化されていない信号、符号化後に格納される符号化された信号、または符号化および復号化処理の後に格納される復号化された信号の何れでもよい。たとえば、エンコーダは、ビットストリームを送信順に出力する。ファイルシステムは、たとえば復号化順にカプセル化され、ファイルとして格納されたオーディオおよび／またはビデオビットストリームを受信する。このファイルは、データベースに格納でき、このデータベースからストリーミングサーバがＮＡＬユニットを読み出し、ＲＴＰパケットにカプセル化することができる。
【００４９】
さらに、次の説明では、エンコーダ・デコーダによるシステムを用いて本発明を説明するが、エンコーダが符号化されたデータを出力し、ストリーミングサーバなどの別の構成要素に第１の順で送信し、この別の構成要素がこの符号化されたデータを第１の順から別の順に並べ替え、この新しい順に必要なバッファサイズを定義し、この符号化されたデータを並べ替えられた形式でデコーダに転送するシステムにも本発明を実装できることは明らかである。
【００５０】
本発明の第１の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられている複数のデータ送信ユニットに含まれているメディアデータをバッファにバッファリングする方法において、パケットストリーム内のいずれかの送信ユニットに送信順で先行し、かつその送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータが定義されることを特徴とする方法が提供される。
【００５１】
本発明の第２の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信およびバッファリングし、デコーダで復号化する方法において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータとして、バッファリング要件が復号化プロセスに示されることを特徴とする方法が提供される。
【００５２】
本発明の第３の態様によると、ピクチャを符号化するエンコーダと、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータをバッファリングするバッファとを含むシステムにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするシステムが提供される。
【００５３】
本発明の第４の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを送信するための送信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とする送信装置が提供される。
【００５４】
本発明の第５の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含むデータ送信ユニットとして、符号化されたピクチャストリームを受信するための受信装置において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを使用してバッファリング要件を判定する手段を含むことを特徴とする受信装置が提供される。
【００５５】
本発明の第６の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャをバッファにバッファリングするために機械が実行可能なステップを含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するために機械が実行可能なステップをさらに含むことを特徴とするコンピュータプログラムプロダクトが提供される。
【００５６】
本発明の第７の態様によると、マルチメディアデータを含む複数の送信ユニットとして受信された符号化されたピクチャストリームをデコーダで復号化するために機械が実行可能なステップと、送信ユニットをバッファリングするために機械が実行可能なステップと、を含むコンピュータプログラムプロダクトにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する送信ユニットの最大量を示すパラメータを用いて、復号化プロセスに対するバッファリング要件を判定するために機械が実行可能なステップを含むことを特徴とするコンピュータプログラムプロダクトが提供される。
【００５７】
本発明の第８の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを運ぶ信号において、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを含むことを特徴とする信号が提供される。
【００５８】
本発明の第９の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットとして、符号化されたピクチャストリームを受信するためのモジュールにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを使用してバッファリング要件を判定する手段を含むことを特徴とするモジュールが提供される。
【００５９】
本発明の第１０の態様によると、送信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを定義するようになっているデファイナを含むことを特徴とするプロセッサが提供される。
【００６０】
本発明の第１１の態様によると、符号化されたピクチャストリームをスライスデータを含む送信ユニットとして受信する受信装置でメディアデータを処理するためのプロセッサにおいて、パケットストリーム内でマルチメディアデータを含むいずれかの送信ユニットに送信ユニット送信順で先行し、かつマルチメディアデータを含むその送信ユニットに復号化順で後続する、マルチメディアデータを含む送信ユニットの最大量を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするプロセッサが提供される。
【００６１】
本発明の第１２の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた複数のデータ送信ユニットに含まれているメディアデータを符号化するためのエンコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを定義するようになっているデファイナを含むことを特徴とするエンコーダが提供される。
【００６２】
本発明の第１３の態様によると、データ送信ユニット内のメディアデータの復号化順とは少なくとも部分的に異なる送信順に並べられた、メディアデータを含む複数のデータ送信ユニットに含まれている符号化されたピクチャストリームを復号化するためのデコーダにおいて、パケットストリーム内でいずれかのデータ送信ユニットに送信順で先行し、かつそのデータ送信ユニットに復号化順で後続するデータ送信ユニットの最大数を示すパラメータを用いてバッファリング要件を判定する手段を含むことを特徴とするデコーダが提供される。
【００６３】
本発明の一実施例において、マルチメディアデータを含む送信単位は、ＶＣＬ  ＮＡＬ単位である。
【００６４】
本発明は、符号化システムのバッファリング効率を向上させる。本発明を用いると、実際に必要な適量のバッファリングの使用が可能になる。したがって、符号化装置内の符号化バッファおよび復号化装置内の復号化前バッファに必要以上のメモリを割り当てる必要がない。また、復号化前バッファのオーバフローを回避できる。
【発明を実施するための最良の形態】
【００６５】
発明の詳細な記述
次に、図５のシステム、図６のエンコーダ１、および図７のデコーダ２を参照しながら、本発明をより詳細に説明する。符号化するピクチャは、たとえば、カメラやビデオレコーダなどのビデオソース３からのビデオストリームのピクチャとすることができる。ビデオストリームの各ピクチャ（フレーム）は、スライスなどのより小さな複数の部分に分割することができる。スライスは、さらにブロックに分割することができる。送信チャネル４を介して、または記憶メディア（図示せず）に送信される情報を減らすために、ビデオストリームはエンコーダ１において符号化される。ビデオストリームの各ピクチャは、エンコーダ１に入力される。エンコーダは、符号化するピクチャの一部を一時的に格納するための符号化バッファ１．１（図６）を有する。エンコーダ１は、本発明による符号化タスクを適用できるプロセッサ１．２とメモリ１．３とをさらに含む。メモリ１．３およびプロセッサ１．２を送信装置６と共通にすることも、送信装置６の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を送信装置６に設けることもできる。ビデオストリームを圧縮するために、エンコーダ１は、動きの推定および／または他のいくつかのタスクを実行する。動きの推定においては、符号化するピクチャ（現在のピクチャ）と前および／または後のピクチャとの間の類似点が探される。類似点が見つかると、比較したピクチャまたはその一部を符号化対象ピクチャの参照ピクチャとして用いる。ＪＶＴでは、ピクチャの表示順と復号化順とが必ずしも同じではないので、参照ピクチャが参照ピクチャとして使われる限りは、参照ピクチャをバッファ（たとえば、符号化バッファ１．１）に格納する必要がある。また、エンコーダ１はピクチャの表示順に関する情報を送信ストリームに挿入する。
【００６６】
必要であれば、符号化されたピクチャは、符号化プロセスから符号化ピクチャバッファ５．２に移動される。符号化されたピクチャは、エンコーダ１から送信チャネル４を介してデコーダ２に送信される。デコーダ２では、符号化されたピクチャが復号化され、符号化ピクチャにできる限り対応する非圧縮ピクチャが形成される。
【００６７】
デコーダ１は、本発明による復号化タスクを適用できるプロセッサ２．２とメモリ２．３とをさらに含む。プロセッサ２．２とメモリ２．３とは受信装置８と共通にすることも、または受信装置８の他の機能のための別のプロセッサおよび／またはメモリ（図示せず）を受信装置８に設けることもできる。
【００６８】
符号化
次に、符号化・復号化プロセスをより詳細に考えてみよう。ビデオソース３からのピクチャはエンコーダ１に入力され、さらに符号化バッファ１．１に格納されるので都合がよい。符号化プロセスは最初のピクチャがエンコーダに入力された直後に必ずしも開始されず、符号化バッファ１．１内の利用可能なピクチャが一定量になってから開始される。次に、エンコーダ１は、参照フレームとして使用する適切な候補をこれらのピクチャから見つけようとする。次に、エンコーダ１は符号化を実行して、符号化されたピクチャを形成する。符号化されたピクチャは、たとえば、予測ピクチャ（Ｐ）、双予測ピクチャ（Ｂ）、および／またはイントラ符号化ピクチャ（Ｉ）である。イントラ符号化ピクチャの復号化は他のどのピクチャも使用せずに行えるが、他の種類のピクチャの復号化には少なくとも１つの参照ピクチャが必要である。上記のどのピクチャ種別のピクチャでも参照ピクチャとして使用できる。
【００６９】
エンコーダは、復号化タイムスタンプ（ＤＴＳ）および出力タイムスタンプ（ＯＴＳ）の２つのタイムスタンプをピクチャに添付するので都合がよい。デコーダはこれらのタイムスタンプを使用して正しい復号化時刻とピクチャの出力（表示）時刻とを判定する。ただし、これらのタイムスタンプはデコーダに必ずしも送信されず、あるいはデコーダが使用しないこともある。
【００７０】
ＮＡＬユニットは、異なる種類のパケットで配信することができる。この好都合な実施形態においては、複数の異なるパケットフォーマットとして、単純パケットと集約パケットとが挙げられる。集約パケットは、シングルタイム集約パケットとマルチタイム集約パケットとにさらに分割することができる。
【００７１】
ＲＴＰパケットのペイロードフォーマットは、必要に応じて、いくつかの異なるペイロード構造として定義される。ただし、受信されるＲＴＰパケットがどの構造を含むかは、ペイロードの先頭バイトから明らかである。このバイトは、ＮＡＬユニットヘッダとして必ず構成される。ＮＡＬユニットタイプフィールドは、どの構造が存在するかを示す。ありうる構造は、単一ＮＡＬユニットパケット、集約パケット、およびフラグメントユニットである。単一ＮＡＬユニットパケットは、ペイロード中にＮＡＬユニットを１つだけ含む。ＮＡＬヘッダタイプフィールドは本来のＮＡＬユニットタイプに等しい、すなわち１から２３までの範囲に含まれる。集約パケットタイプは、複数のＮＡＬユニットを単一のＲＴＰペイロードに集約するために使用される。このパケットは４つのバージョンがある。すなわち、シングルタイム集約パケットタイプＡ（ＳＴＡＰ−Ａ）、シングルタイム集約パケットタイプＢ（ＳＴＡＰ−Ｂ）、マルチタイム集約パケット（ＭＴＡＰ）の１６ビットオフセット版（ＭＴＡＰ１６）、およびマルチタイム集約パケット（ＭＴＡＰ）の２４ビットオフセット版（ＭＴＡＰ２４）が存在する。ＳＴＡＰ−Ａ、ＳＴＡＰ−Ｂ、ＭＴＡＰ１６、およびＭＴＡＰ２４に割り当てられたＮＡＬユニットタイプ番号は、それぞれ２４、２５、２６、および２７である。フラグメントユニットは、単一のＮＡＬユニットを複数のＲＴＰパケットにわたってフラグメント化するために使用する。フラグメントユニットは２つのバージョンが存在し、それぞれＮＡＬユニットタイプ番号２８および２９で識別される。
【００７２】
ＲＴＰパケット送信のために定義されるパケット化モードとして、次の３つのケースがある。
・単一ＮＡＬユニットモード
・非インタリーブドモード
・インタリーブドモード
【００７３】
単一ＮＡＬユニットモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠した対話型システムを対象とする。非インタリーブドモードは、ＩＴＵ−Ｔ勧告Ｈ．２４１に準拠しない場合もある対話型システムを対象とする。非インタリーブドモードでは、ＮＡＬユニットはＮＡＬユニットの復号化順で送信される。インタリーブドモードは、エンドツーエンドレイテンシを極めて小さくする必要がないシステムを対象とする。インタリーブドモードでは、ＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が可能である。
【００７４】
使用されているパケット化モードは、パケット化モードを指定するオプションのＭＩＭＥパラメータの値または外部手段によって通知しうる。使用されているパケット化モードに応じて、ＲＴＰペイロードで使用しうるＮＡＬユニットタイプが決まる。
【００７５】
インタリーブドパケット化モードでは、ＮＡＬユニットの送信順をＮＡＬユニットの復号化順と同じにする必要がない。復号化順序号（ＤＯＮ）は、ペイロード構造内のフィールド、またはＮＡＬユニットの復号化順を示す派生変数である。
【００７６】
送信順と復号化順との結合は、次のようにインタリーブ深さを指定するオプションのＭＩＭＥパラメータによって制御する。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０に等しく、復号化順以外でのＮＡＬユニットの送信が外部手段によって禁止されている場合、ＮＡＬユニットの送信順はＮＡＬユニットの復号化順に従う。インタリーブ深さを指定するオプションのＭＩＭＥパラメータが０より大きい場合、またはＮＡＬユニットの復号化順以外でのＮＡＬユニットの送信が外部手段によって許容されている場合は、
・マルチタイム集約パケット１６（ＭＴＡＰ１６）およびマルチタイム集約パケット２４（ＭＴＡＰ２４）内のＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がなく、また
・２つの連続するパケット内のシングルタイム集約パケットＢ（ＳＴＡＰ−Ｂ）、ＭＴＡＰ、およびフラグメントユニット（ＦＵ）のデカプセル化によって合成されるＮＡＬユニットの順をＮＡＬユニットの復号化順にする必要がない。
【００７７】
単一ＮＡＬユニットパケット、ＳＴＡＰ−Ａ、およびＦＵ−ＡのＲＴＰペイロード構造は、ＤＯＮを含まない。ＳＴＡＰ−Ｂ構造およびＦＵ−Ｂ構造はＤＯＮを含み、ＭＴＡＰの構造はＤＯＮの派生を可能にする。
【００７８】
送信器がパケットごとに１つのＮＡＬユニットをカプセル化し、ＮＡＬユニットの復号化順以外でパケットを送信する必要がある場合は、ＳＴＡＰ−Ｂパケットタイプを使用することができる。
【００７９】
単一ＮＡＬユニットパケット化モードでは、一連のＮＡＬユニットの送信順はこれらのＮＡＬユニットの復号化順と同じである。非インタリーブドパケット化モードでは、単一ＮＡＬユニットパケットおよびＳＴＡＰ−Ａ、およびＦＵ−Ａ内のＮＡＬユニットの送信順は、これらのＮＡＬユニットの復号化順と同じである。ＳＴＡＰ内のＮＡＬユニットは、ＮＡＬユニットの復号化順に現れる。
【００８０】
Ｈ．２６４では、表示順と異なる復号化順が許容されるので、ＲＴＰタイムスタンプの値がＲＴＰシーケンス番号に応じて単調非減少とならない場合もある。
【００８１】
送信順で最初のＮＡＬユニットのＤＯＮ値は次の何れかの値に設定しうる。ＤＯＮの値は、０から６５５３５までの（両端の値を含む）範囲内の何れかである。最大値に達すると、ＤＯＮの値は０に折り返す。
【００８２】
この仕様によるビデオシーケンスは、ＮＡＬＵストリームの他の部分から独立して複合化可能なＮＡＬＵストリームのどの部分でもよい。
【００８３】
堅牢なパケットスケジューリングの一例を以下に示す。
【００８４】
次の例の図では、時間は左から右へ流れ、ＩはＩＤＲピクチャを示し、Ｒは参照ピクチャを示し、Ｎは非参照ピクチャを示し、数字は復号化順で前のＩＤＲピクチャに比例する相対的な出力時刻を示す。ピクチャシーケンスの下の値は、システムクロックのタイムスタンプ目盛りを示し、この例ではこれらの目盛りは適宜初期化される。Ｉ、Ｒ、およびＮピクチャは、符号化、送信、および復号化にかかる時間が皆無であると仮定して、前の処理ステップがある場合は前のステップに比べて同じ時系列にマッピングされる。
【００８５】
複数のビデオシーケンス内のピクチャのサブセットを以下に出力順に示す。
【数１】
2006515137.tif 000017
【００８６】
これらのピクチャの符号化（および復号化）順は、次のように左から右への順である。
【数２】
2006515137.tif 000018
【００８７】
１つのピクチャの復号化順序号（ＤＯＮ）は、復号化順で前のピクチャのＤＯＮ値に１を加えた値に等しい。
【００８８】
単純化するために、次のように仮定してみよう。
・シーケンスのフレームレートは一定である。
・各ピクチャは単一のスライスで構成される。
・各スライスは単一のＮＡＬユニットパケットにカプセル化される。
・ピクチャは復号化順で送信される。
・ピクチャは一定間隔で送信される（つまり、１／フレームレートに等しい）。
【００８９】
したがって、ピクチャは次のように復号化順で受信される。
【数３】
2006515137.tif 000019
【００９０】
送信（または受信順）から正しい復号化順を復元するためにバッファリングする必要がないので、ｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータは０に設定される。
【００９１】
以下に示すようにピクチャを復号化順から出力順に編成するために、デコーダは初めに１つのピクチャ間隔をその復号化ピクチャバッファにバッファリングする必要がある。
【数４】
2006515137.tif 000020
【００９２】
復号化ピクチャバッファに必要な初期バッファリング量は、バッファリング期間ＳＥＩメッセージによって通知することも、Ｈ．２６４のビデオユーザビリティ情報のｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ構文要素の値によって通知することもできる。ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは、シーケンス内で何れかのフレーム、相補型フィールド対、または非対フィールドに復号化順先行し、出力順で後続するフレーム、相補型フィールド対、または非対フィールドの最大数を示す。
【００９３】
単純化するために、復号化ピクチャバッファ内の初期バッファを示すために、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓが使用されると仮定する。この例では、ｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓは１に等しい。
【００９４】
ＩＤＲピクチャ１００が送信中に失われ、システムクロックの値が６２のときに再送要求が発行された場合、再送されたＩＤＲピクチャ１００を受信する時間として１つのピクチャ間隔（システムクロックがタイムスタンプ６３に達するまでの時間）しかないことがわかる。
【００９５】
次に、各ＩＤＲピクチャの送信位置がそれぞれの復号化位置よりフレーム間隔２つ分だけ前である、すなわち、ピクチャが次の順に送信される、と仮定してみよう。
【数５】
2006515137.tif 000021
【００９６】
変数ｉｄ１を従来技術（ｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｐ−ｈ２６４−０１．ｔｘｔに開示）に従って指定してみよう。つまり、ＮＡＬユニットストリーム内で何れかのＶＣＬ  ＮＡＬユニットにＮＡＬユニット復号化順で先行し、かつこのＶＣＬ  ＮＡＬユニットを含む集約パケットの合成順またはＲＴＰシーケンス番号順でこのＶＣＬ  ＮＡＬユニットに後続するＶＣＬ  ＮＡＬユニットの最大量を指定する。変数ｉｄ２を本発明に従って指定してみよう。つまり、ＮＡＬユニットストリーム内の何れかのＶＣＬ  ＮＡＬユニットに送信順で先行し、かつそのＶＣＬ  ＮＡＬユニットに復号化順で後続するＶＣＬ  ＮＡＬユニットの最大量を指定する。
【００９７】
この例では、ｉｄ１の値は２に等しく、ｉｄ２の値は１に等しい。第２節で既に見たように、ｉｄ１の値は、受信順から復号化順にパケットを並べ替えるための初期バッファリングに必要なバッファリング空間または時間に比例しない。この例では、以下に図示するように（この図は受信器のバッファリング処理の出力を表す）、復号化順を復元するには、１ピクチャ間隔に等しい初期バッファリング時間が必要である。この例はまた、本発明によると、初期バッファリング時間およびバッファリング空間の値を割り出せることを実証する。
【数６】
2006515137.tif 000022
【００９８】
以下に示すように、ピクチャを復号化順から出力順に編成するために必要な初期バッファリング遅延もまた、１ピクチャ間隔である。
【数７】
2006515137.tif 000023
【００９９】
アプリケーション層、トランスポート層、またはリンク層での再送を含む送信中にＩＤＲピクチャが蒙りうる最大遅延はｎｕｍ＿ｒｅｏｒｄｅｒ＿ｆｒａｍｅｓ＋ｉｄ２に等しいことが観察される。したがって、ＩＤＲピクチャの損失耐性は、再送をサポートするシステムで向上される。
【０１００】
受信器は、各ピクチャに対応付けられているＤＯＮの値に基づき、ピクチャを復号化順に編成することができる。
【０１０１】
送信
最初の符号化ピクチャが用意されると直ちに符号化ピクチャの送信および／または格納（およびオプションの仮想復号化）を行うことができる。復号化順と出力順とが必ずしも同じではないので、このピクチャがデコーダ出力順で最初のピクチャになるとは限らない。
【０１０２】
ビデオストリームの最初のピクチャが符号化されたら、送信を開始できる。符号化ピクチャは、符号化ピクチャバッファ１．２に格納することもできる。送信をこれより後の段階で開始することもでき、たとえばビデオストリームの一定部分が符号化された後に開始することもできる。
【０１０３】
デコーダ２は、復号化されたピクチャを、たとえばピクチャ順カウントの順序付けを用いて、正しい順で出力するはずである。
【０１０４】
デパケット化
デパケット化処理は実装依存である。したがって、以下の説明は適切な一実装例に関するものであり、実装をこれだけに限定するものではない。他の方式も使用しうる。記載のアルゴリズムに対する最適化も可能である。
【０１０５】
これらのデパケット化規則の背後にある一般概念は、ＮＡＬユニットの送信順からＮＡＬユニットの配信順への並べ替えである。
【０１０６】
復号化
次に、受信器８の動作を説明する。受信器８は１つのピクチャに属する全てのパケットを収集し、これらを１つの妥当な順に並べる。順序の厳密性は使用するプロファイルによって異なる。受信パケットは受信バッファ９．１（プリデコーディングバッファ）に格納される。受信器８は使用不能なものをすべて廃棄し、残りをデコーダ２に送る。集約パケットは、それぞれのペイロードをＮＡＬＵを運ぶ個々のＲＴＰパケットに書き出すことによって処理される。これらのＮＡＬＵは、それぞれ別のＲＴＰパケットとして受信されたかのように、集約パケット内の配置順で処理される。
【０１０７】
次に、パケットストリーム内で何れかのＶＣＬ  ＮＡＬユニットにＮＡＬユニット送信順で先行し、そのＶＣＬ  ＮＡＬユニットに復号化順で後続するＶＣＬ  ＮＡＬユニットの最大量を指定する、オプションのｎｕｍ−ｒｅｏｒｄｅｒ−ＶＣＬ−ＮＡＬ−ｕｎｉｔｓパラメータ（ｉｎｔｅｒｌｅａｖｉｎｇ−ｄｅｐｔｈパラメータ）の値をＮにしてみよう。このパラメータがない場合は、０値の数を暗示しうる。
【０１０８】
このビデオストリーム転送セッションを初期化すると、受信器８は、少なくともＮ個のＶＣＬ  ＮＡＬユニットを格納するためのメモリを受信バッファ９．１に対して割り当てる。次にこの受信器は、ビデオストリームの受信を開始し、受信したＶＣＬ  ＮＡＬユニットを受信バッファに格納する。初期バッファリングは、次の何れかの条件が満たされるまで続く。
・少なくともＮ個のＶＣＬ  ＮＡＬユニットが受信バッファ９．１に格納される。
・ＭＩＭＥパラメータｍａｘ−ｄｏｎ−ｄｉｆｆが存在する場合は、関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の値がｍａｘ−ｄｏｎ−ｄｉｆｆの値を超える。ここで、ｎは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応し、ｍは受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最小のＮＡＬユニットに対応する。
・初期バッファリングの継続時間がＭＩＭＥのオプションパラメータｉｎｉｔ−ｂｕｆ−ｔｉｍｅの値に等しくなるか、またはこれを超える。
【０１０９】
関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）は次のように指定する。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝０
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。
【０１１０】
ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の正の値は、送信順インデックスｎのＮＡＬユニットが送信順インデックスｍのＮＡＬユニットに復号化順で後続することを示す。
【０１１１】
ＡｂｓＤＯＮは、ＮＡＬユニットのこのような復号化順序号が６５５３５の後で０に折り返されないことを示す。すなわち、ＡｂｓＤＯＮは次のように計算される。
【０１１２】
ｍとｎとが送信順で連続するＮＡＬユニットであるとする。送信順で先頭（インデックス０）のＮＡＬユニットは、ＡｂｓＤＯＮ（０）＝ＤＯＮ（０）である。他のＮＡＬユニットのＡｂｓＤＯＮは、次のように計算される。
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
（ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）、かつＤＯＮ（ｎ）−ＤＯＮ（ｍ）＞＝３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
（ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）、かつＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８）の場合、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、送信順のインデックスがｉであるＮＡＬユニットの復号化順番号である。
【０１１３】
受信バッファ９．１が少なくともＮ個のＶＣＬ  ＮＡＬユニットを収容すると、ＮＡＬユニットは受信バッファ９．１から１つずつ取り出され、デコーダ２に送られる。ＮＡＬユニットが受信バッファ９．１から取り出される順は必ずしも格納された順ではなく、以下に説明するようにＮＡＬユニットのＤＯＮに従う。デコーダ２へのパケットの配信は、バッファ内のＶＣＬ  ＮＡＬユニットの数がＮ個より少なくなるまで、すなわちＶＣＬ  ＮＡＬユニットがＮ−１個になるまで続く。
【０１１４】
受信バッファから取り出されるＮＡＬユニットの数は次のように決められる。
・受信バッファが少なくともＮ個のＶＣＬ  ＮＡＬユニットを収容すると、バッファ内のＶＣＬ  ＮＡＬユニットがＮ−１個になるまで、以下に示す順でＮＡＬユニットが受信器のバッファから取り出され、デコーダに送られる。
・ｍａｘ−ｄｏｎ−ｄｉｆｆがある場合は、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）のｍがｍａｘ−ｄｏｎ−ｄｉｆｆより大きいすべてのＮＡＬユニットが以下の指定順で受信バッファから取り出され、デコーダに送られる。ここで、ｎは、受信されたＮＡＬユニットのうち、ＡｂｓＤＯＮ値が最大のＮＡＬユニットに対応する。
・変数ｔｓを、ＮＡＬユニットストリームの最初のパケットが受信されたときに０に初期化されたシステムタイマの値に設定する。受信時刻ｔｒが条件ｔｓ−ｔｒ＞ｉｎｉｔ−ｂｕｆ−ｔｉｍｅの条件を満たすＮＡＬユニットが受信バッファにある場合は、受信時刻ｔｒがこの指定条件を満たすＮＡＬユニットが受信バッファ内になくなるまで、ＮＡＬユニットが指定順にデコーダに送られる（および受信バッファから取り出される）。
【０１１５】
ＮＡＬユニットをデコーダに送る順は次のように指定する。
【０１１６】
ＲＴＰセッションの開始時に０に初期化される変数をＰＤＯＮとする。１つのＤＯＮ値に対応するＮＡＬユニットごとに、ＤＯＮ距離を次のように計算する。ＮＡＬユニットのＤＯＮ値がＰＤＯＮ値より大きい場合は、ＤＯＮ距離はＤＯＮ−ＰＤＯＮに等しい。その他の場合は、ＤＯＮ距離は６５５３５−ＰＤＯＮ＋ＤＯＮ＋１に等しい。
【０１１７】
ＮＡＬユニットは、ＤＯＮ距離の昇順でデコーダに配信される。ＤＯＮ距離の値が同じＮＡＬユニットがいくつかある場合は、これらのＮＡＬユニットはどのような順でデコーダに送られてもよい。所望数のＮＡＬユニットがデコーダに送られたら、ＰＤＯＮの値をデコーダに最後に送られたＮＡＬユニットのＤＯＮ値に設定する。
【０１１８】
いくつかのピクチャを格納するために、ＤＰＢ２．１は複数のメモリ位置を含む。本明細書では、これらの位置をフレームストアとも呼ぶ。デコーダ２は受信ピクチャを正しい順で復号化する。
【０１１９】
本発明は、多くの種類のシステムおよび装置に適用できる。エンコーダ１を含む送信装置６は、符号化されたピクチャを送信チャネル４に送信するための送信器７をさらに含むので都合がよい。受信装置８は符号化されたピクチャを受信する受信器９と、デコーダ２と、復号化されたピクチャを表示できる表示装置１０とを含む。送信チャネルは、たとえば、有線通信チャネルおよび／または無線通信チャネルとしうる。送信装置と受信装置とは、本発明によるビデオストリームの符号化／復号化処理を制御するために必要なステップを実行できる１つまたは複数のプロセッサ１．２、２．２をさらに含む。したがって、本発明による方法は、これらのプロセッサの機械が実行可能なステップとして主に実装することができる。ピクチャのバッファリングは、装置のメモリ１．３、２．３で実現することができる。エンコーダのプログラムコード１．４はメモリ１．３に格納することができる。また、デコーダのプログラムコード２．４は、メモリ２．３に格納することができる。
【図面の簡単な説明】
【０１２０】
【図１】再帰的時間スケーラビリティ方式の一例を示す。
【図２】１つのピクチャシーケンスがそれぞれ独立した２つまたはそれ以上の符号化スレッドにインタリーブ形式で分割される、ビデオ冗長符号化と称される方式を示す。
【図３】圧縮効率を向上しうる予測構造の一例を示す。
【図４】誤り耐性の向上のために使用できるイントラピクチャ先送り方法の一例を示す。
【図５】本発明によるシステムの好都合な実施形態を示す。
【図６】本発明によるエンコーダの好都合な実施形態を示す。
【図７】本発明によるデコーダの好都合な実施形態を示す。
【国際調査報告】
2006515137.tif 000024
2006515137.tif 000025
2006515137.tif 000026