JP2011199899A - エンコーダ及びデコーダにおけるバッファのサイズ再設定 - Google Patents

Abstract

【課題】符号化システムのバッファリング効率を改善する。
【解決手段】本発明は、符号化ピクチャをバッファリングする方法に関する。前記方法は、符号化ピクチャをエンコーダにて形成する符号化ステップを含む。前記方法は、前記符号化ピクチャを伝送ユニットとしてデコーダに伝送する伝送ステップと、デコーダに伝送された伝送ユニットをバッファにバッファリングするバッファリングステップと、復号化ピクチャを形成するため、前記符号化ピクチャを復号化する復号化ステップと、を更に含む。少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズが規定される。
【選択図】図８

Description

本発明は、符号化ピクチャをバッファリングする方法であって、エンコーダにおいて符号化ピクチャを形成する符号化ステップと、前記符号化ピクチャをデコーダに伝送する伝送ステップと、復号化ピクチャを形成するため符号化ピクチャを復号化する復号化ステップと、復号化ピクチャを復号化順序に配置する再配置ステップとを含む方法に関する。本発明は、システム、伝送装置、受信装置、エンコーダ、デコーダ、電子装置、ソフトウェアプログラム及び記憶媒体にも関する。

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

ビデオ通信システム

ビデオ通信システムを対話型システム及び非対話型システムに分けることができる。対話型システムはテレビ会議及びテレビ電話を含む。このようなシステムの例として、ＩＳＤＮ、ＩＰ及びＰＳＴＮネットワークでそれぞれ動作するテレビ会議／電話システムを指定するＩＴＵ‐Ｔ勧告Ｈ．３２０、Ｈ．３２３及びＨ．３２４が挙げられる。対話型システムは、（オーディオ‐ビデオ獲得から遠端オーディオ‐ビデオ表示までの）エンドツーエンド遅延を最小限に抑えてユーザ体験を改善する目的により特徴付けられている。

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

今日のデジタルビデオ民生電子機器で支配的な規格は、ビデオ圧縮、オーディオ圧縮、ストレージ及びトランスポートの仕様を含むＭＰＥＧ‐２である。符号化ビデオのストレージ及びトランスポートはエレメンタリストリームの概念に基づく。エレメンタリストリームは、単一のソース（例えば、ビデオ）からの符号化データと、ソース情報の同期化、識別及び特徴付けに必要とされる補助データとから成る。エレメンタリストリームは、パケット化エレメンタリストリーム（ＰＥＳ）を形成するように固定長または可変長パケットにパケット化される。各ＰＥＳパケットは、ヘッダと、これに続くペイロードと呼ばれているストリームデータとから成る。様々なエレメンタリストリームからのＰＥＳパケットは、プログラムストリーム（ＰＳ）またはトランスポートストリーム（ＴＳ）を形成するように結合される。ＰＳは、蓄積再生型のアプリケーションのような、無視できる伝送エラーを有するアプリケーションを対象としている。ＴＳは、伝送エラーを許容するアプリケーションを対象としている。しかし、ＴＳは、ネットワーク処理能力が一定であると保証されていると仮定する。

ＩＴＵ‐Ｔ及びＩＳＯ／ＩＥＣのジョイントビデオチーム（ＪＶＴ）において標準化活動が進行中である。ＪＶＴの作業は、Ｈ．２６Ｌと呼ばれているＩＴＵ‐Ｔの初期標準化プロジェクトに基づく。ＪＶＴ標準化の目標は、ＩＴＵ‐Ｔ勧告Ｈ．２６４及びＩＳＯ／ＩＥＣ国際標準１４４９６‐１０（ＭＰＥＧ‐４パート１０）と同じ標準テキストを公開することにある。草案規格を本明細書でＪＶＴ符号化規格と称し、草案規格に準じるコーデックをＪＶＴコーデックと称する。

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

ＮＡＬは、パケットネットワーク上の伝送に適し、または、パケット指向の多重環境の使用に適するネットワーク抽象化層ユニット（ＮＡＬＵ）内にＶＣＬのスライス出力をカプセル化する。ＪＶＴのアネックスＢは、このようなＮＡＬＵをバイトストリーム指向のネットワーク上に伝送するカプセル化処理を規定する。

Ｈ．２６３の随意の参照ピクチャ選択モード及びＭＰＥＧ‐４パート２のニュープレッド符号化ツールは、Ｈ．２６３において各ピクチャセグメント当たり例えば各スライス当たりの動き補償に対する参照フレームの選択を可能にする。更に、Ｈ．２６３の随意の拡張参照ピクチャ選択モード及びＪＶＴ符号化規格は、各マクロブロックに対する別々の参照フレームの選択を可能にする。

参照ピクチャ選択は、多くの種類の時間スケーラビリティ方式を可能にする。図１には、再帰的な時間スケーラビリティと本明細書で称する時間スケーラビリティ方式の一例を示す。この例示的な方式を３つの固定フレームレートで復号化することができる。図２には、一連のピクチャが、２つ以上の独立して符号化されたスレッドにインターリーブ形式に分割されるビデオ冗長符号化と称する方式を示す。これらの図面及びこれらに続くすべての図面の矢印は動き補償の方向を示し、フレームの下にある値は、フレームの相対的な獲得及び表示時間に対応する。

パラメータセットの概念

ＪＶＴコーデックの１つの極めて基本的な設計概念は、ヘッダ重複不要のような機構を形成するため自己充足型のパケットを生成することにある。これを達成する方法は、２つ以上のスライスに関する情報をメディアストリームから分離することである。この上層メタ情報を、スライスパケットを含むＲＴＰパケットストリームから確実に非同期的に前もって送信する必要がある。この情報を、目的に適する帯域外のトランスポートチャネルを持たないアプリケーションに帯域内で送信することもできる。ハイレベルパラメータの組み合わせはパラメータセットと呼ばれている。パラメータセットは、ピクチャサイズ、表示ウィンドウ、用いられる随意の符号化モード、マクロブロック割り当てマップなどのような情報を含む。

スライスパケットストリームに同調してパラメータセット最新情報を伝送することを必要とせず、（ピクチャサイズのような）ピクチャパラメータを変更できるように、エンコーダ及びデコーダは２つ以上のパラメータセットのリストを維持することができる。各スライスヘッダは、用いられるパラメータセットを示す符号語を含む。

この機構により、パラメータセットの伝送をパケットストリームから分離し、パラメータセットを外部手段により、例えば、機能交換の副次的影響として、または（信頼できる、または信頼できない）制御プロトコルを介して伝送することができる。パラメータセットが全く伝送されず、アプリケーション設計仕様により固定されることさえも可能である。

伝送順序

従来のビデオ符号化規格では、Ｂピクチャを除いてピクチャの復号化順序は表示順序と同じである。表示順序において一方の参照ピクチャが時間的に先行し、他方の参照ピクチャが時間的に後に続いている２つの参照ピクチャから従来のＢピクチャのブロックを双方向に時間予測することができる。復号化順序で最後の参照ピクチャのみ、表示順序でＢピクチャの後に続くことができる（例外：Ｈ．２６３におけるインタレース符号化では、時間的に後に来る参照フレームの双方のフィールドピクチャが、復号化順序でＢピクチャに先行することができる）。時間予測に対して従来のＢピクチャを参照ピクチャとして用いることができない。従って、他のいかなるピクチャの復号化にも影響を及ぼすことなく従来のＢピクチャを配列することができる。

ＪＶＴ符号化規格は、初期の規格と比べて下記の新規な技術的特徴を含む。
− ピクチャの復号化順序は表示順序から分離されている。ピクチャ番号は復号化順序を示し、ピクチャオーダカウントは表示順序を示す。
− Ｂピクチャのブロックの参照ピクチャを、表示順序でＢピクチャの前または後とすることができる。従って、Ｂピクチャは、双方向ピクチャというよりは双予測ピクチャを表している。
− 参照ピクチャとして用いられないピクチャには明白に印が付けられる。いかなる種類のピクチャ（イントラピクチャ、インターピクチャ、Ｂピクチャなど）も参照ピクチャまたは非参照ピクチャとすることができる。（従って、他のピクチャの時間予測に対してＢピクチャを参照ピクチャとして用いることができる。）
− ピクチャは、異なる符号化タイプで符号化されているスライスを含むことができる。言い換えれば、符号化ピクチャは、例えばイントラ符号化スライス及びＢ符号化スライスから成ることができる。

復号化順序から表示順序を分離することは、圧縮効率及び誤り耐性の観点から有益である。

圧縮効率を改善する可能性を秘めている予測構造の一例を図３に示す。ボックスはピクチャを示し、ボックス内の大文字は符号化タイプを示し、ボックス内の数字はＪＶＴ符号化規格によるピクチャ番号を示し、矢印は予測依存性を示す。ピクチャＢ１７がピクチャＢ１８の参照ピクチャであることに留意すべきである。ＰＢＢＰまたはＰＢＢＢＰ符号化ピクチャパターンを含む従来の符号化に比べてピクチャＢ１８の参照ピクチャが時間的に近いので、圧縮効率は従来の符号化に比べて改善される可能性を秘めている。参照ピクチャの一部が双方向に予測されるので、圧縮効率は従来のＰＢＰ符号化ピクチャパターンに比べて改善される可能性を秘めている。

図４には、誤り耐性の改善に用いることができるイントラピクチャの後回し方式の一例を示す。通常、イントラピクチャは、例えば、シーンが切れた直後に、または、イントラピクチャリフレッシュ期間の終了に応答して符号化される。イントラピクチャの後回し方式では、イントラピクチャは、イントラピクチャを符号化する必要性が生じた直後に符号化されるのではなくむしろ、時間的に後に来るピクチャがイントラピクチャとして選択された直後に符号化される。符号化されたイントラピクチャと、イントラピクチャの従来の位置との間の各ピクチャは、時間的に後に来るピクチャから予測される。図４に示すように、イントラピクチャの後回し方式は、２つの独立したインターピクチャ予測チェーンを発生するのに対して、従来の符号化アルゴリズムは、１つのインターピクチャチェーンを発生する。２つのチェーンのアプローチが１つのチェーンの従来アプローチよりも消失エラーに耐えうることは直感的に明らかである。一方のチェーンがパケット損失を被る場合、他方のチェーンを依然として正確に受信することができる。従来の符号化では、パケット損失は、イントラピクチャ予測チェーンの残りの部分へエラー伝播を常に生じさせる。

２つの種類の順序付け及びタイミング情報は、通常、デジタルビデオすなわち符号化及び表示順序のデジタルビデオと関連している。下記で関連技術を詳しく検討する。

復号化タイムスタンプ（ＤＴＳ）は、符号化データユニットを復号化することになっている、参照クロックに相対する時間を示す。ＤＴＳが符号化され伝送されれば、２つの目的に役立つ。すなわち、第１に、ピクチャの復号化順序が出力順序と異なれば、ＤＴＳは復号化順序を明白に示す。第２に、ＤＴＳは、受信レートが伝送レートに常に近いならば特定のプリデコーダのバッファリング動作を保証する。エンドツーエンドレイテンシが変化するネットワークでは、ＤＴＳの第２の用途は、ほとんど何の役割も果たさない。その代わり、受信データは、ポストデコーダのバッファに非圧縮ピクチャのための空間があれば、可能な限り高速に復号化される。

ＤＴＳの伝達は、使用される通信システム及びビデオ符号化規格に依存する。ＭＰＥＧ‐２システムでは、ＰＥＳパケットのヘッダの一項目としてＤＴＳを随意に伝送することができる。ＪＶＴ符号化規格では、追加拡張情報（ＳＥＩ）の一部としてＤＴＳを随意に伝達することができ、ＤＴＳが随意の仮想参照デコーダの動作に用いられる。ＩＳＯベースメディアファイル形式では、ＤＴＳは、それ自体のボックスタイプであるＤｃｏｄｉｎｇ Ｔｉｍｅ ｔｏ Ｓａｍｐｌｅ Ｂｏｘ（サンプルボックスに対する復号化時間）専用とされている。ＲＴＰに基づくストリーミングシステムのような多くのシステムでは、復号化順序が、伝送順序と同じであると推測され、正確な復号化時間が重要な役割を果たさないので、ＤＴＳは全く伝達されない。

Ｈ．２６３の随意のアネックスＵ及びアネックスＷ．６．１２は、復号化順序で前にある参照ピクチャに対して１だけ増加されるようにピクチャ番号を指定する。ＪＶＴ符号化規格では、フレーム番号の符号化要素はＨ．２６３のピクチャ番号と類似して指定される。ＪＶＴ符号化規格は、瞬間デコーダリフレッシュ（ＩＤＲ）ピクチャと呼ばれている特定タイプのイントラピクチャを指定する。後に続くいかなるピクチャも、復号化順序でＩＤＲピクチャよりも先行するピクチャを参照することができない。ＩＤＲピクチャは、しばしば、シーンチェンジに応答して符号化される。ＪＶＴ符号化規格では、図５ａ及び５ｂに示すようなＩＤＲピクチャの損失の場合に誤り耐性を改善するため、フレーム番号はＩＤＲピクチャで零に再設定される。しかし、ここで留意すべきは、シーンチェンジを検出するのにＪＶＴ符号化規格のシーン情報ＳＥＩメッセージも使用できることである。

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

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

プレゼンテーションタイムスタンプ（ＰＴＳ）は、ピクチャを表示することになっている、参照クロックに相対する時間を示す。プレゼンテーションタイムスタンプは、表示タイムスタンプ、出力タイムスタンプ及び作成タイムスタンプとも呼ばれている。

ＰＴＳの伝達は、使用される通信システム及びビデオ符号化規格に依存する。ＭＰＥＧ‐２システムでは、ＰＥＳパケットのヘッダの一項目としてＰＴＳを随意に伝送することができる。ＪＶＴ符号化規格では、追加拡張情報（ＳＥＩ）の一部としてＰＴＳを随意に伝達することができ、ＰＴＳが仮想参照デコーダの動作に用いられる。ＩＳＯベースメディアファイル形式では、ＰＴＳは、それ自体のボックスタイプであるＣｏｍｐｏｓｉｔｉｏｎ Ｔｉｍｅ ｔｏ Ｓａｍｐｌｅ Ｂｏｘ（サンプルボックスに対する作成時間）専用とされ、プレゼンテーションタイムスタンプは対応の復号化タイムスタンプに対して符号化される。ＲＴＰでは、ＲＴＰパケットヘッダのＲＴＰタイムスタンプはＰＴＳに対応する。

従来のビデオ符号化規格は、多くの点でＰＴＳに類似する時間参照（ＴＲ）符号化要素を特徴付ける。ＭＰＥＧ‐２ビデオのような従来の符号化規格の幾つかには、ＴＲは、グループオブピクチャ（ＧＯＰ）の初めで零に再設定される。ＪＶＴ符号化規格では、ビデオ符号化層において時間の概念がない。ピクチャオーダカウント（ＰＯＣ）は各フレーム及びフィールドに対して指定され、例えば、Ｂスライスの直接時間予測でＴＲに類似して用いられる。ＰＯＣはＩＤＲピクチャで零に再設定される。

マルチメディアストリームの伝送

マルチメディアストリーミングシステムは、ストリーミングサーバと、ネットワークを介してサーバにアクセスする多数のプレーヤとから成る。ネットワークは典型的にパケット指向であり、サービスの品質を保証するのにほとんど何の手段も具えない。プレーヤは、予め格納されているマルチメディアコンテンツか生のマルチメディアコンテンツのどちらかをサーバからフェッチし、コンテンツがダウンロードされる間、リアルタイムでコンテンツを再生する。通信の種類を、ポイントツーポイントまたはマルチキャストとすることができる。ポイントツーポイントストリーミングでは、サーバは各プレーヤに対して別々の接続を行う。マルチキャストストリーミングでは、サーバは単一のデータストリームを多数のプレーヤに伝送し、必要である場合のみ、ネットワーク要素はストリームを複製する。

プレーヤがサーバへの接続を確立し、メディアストリームを要求したら、サーバは所望のストリームを伝送し始める。プレーヤはストリームを直ちに再生し始めるのではなくむしろ、典型的に受信データを数秒間バッファリングする。本明細書では、このバッファリングを初期バッファリングと称する。伝送遅延が時折増大するか、またはネットワーク処理能力が落ちた場合、プレーヤが、バッファに格納されたデータを復号化し再生できるので、初期バッファリングは、一時停止なしの再生を維持するのに役立つ。

無制限の伝送遅延を回避するため、ストリーミングシステムにおいて信頼できるトランスポートプロトコルを好むことはまれである。その代わり、システムは、一方で、安定した伝送遅延を継承するが他方ではデータ破損または損失をも被るＵＤＰのような信頼できないトランスポートプロトコルを好む。

リアルタイム通信を制御するため、ＵＤＰの上部にＲＴＰ及びＲＴＣＰプロトコルを用いることができる。ＲＴＰは、伝送パケットの損失を検出し、受信端でパケットの正しい順序を再構築し、サンプリングタイムスタンプを各パケットと関連付ける手段を具える。ＲＴＣＰは、正確に受信されたパケットの部分がどのくらい大きいかに関する情報を伝達し、従って、フロー制御の目的にＲＴＣＰを用いることができる。

伝送エラー

２つの主な種類の伝送エラーすなわちビットエラー及びパケットエラーがある。典型的にビットエラーは、移動通信における無線アクセスネットワーク接続のような回線交換チャネルと関連し、これらビットエラーは、無線干渉のような物理チャネルの不完全性により引き起こされる。このような不完全性は、伝送データにビット反転、ビット挿入及びビット削除を生じさせるおそれがある。パケットエラーは典型的にパケット交換ネットワークの要素により引き起こされる。例えば、パケットルータが過密するようになる可能性がある。すなわち、パケットルータは、多すぎるパケットを入力として獲得するおそれがあり、それらを同じ速度で出力することができない。この状況では、バッファはオーバフローし、幾つかのパケットが失われる。伝送と異なる順序でのパケット複製及びパケット配信も可能であるが、それらは、典型的にパケット損失よりも一般的ではないと考えられている。用いられるトランスポートプロトコルスタックの実施によってもパケットエラーを引き起こす可能性がある。例えば、幾つかのプロトコルは、送信機で計算されソース符号化データと共にカプセル化されるチェックサムを用いる。データ内にビット反転エラーがあれば、受信機は、同一のチェックサムになることができず、受信したパケットを廃棄しなければならない可能性がある。

ＧＰＲＳ、ＵＭＴＳ及びＣＤＭＡ‐２０００を含む第２世代（２Ｇ）及び第３世代（３Ｇ）移動ネットワークは、２つの基本的な種類の無線リンク接続、すなわち、確認接続及び非確認接続を行う。確認接続では、無線リンクフレームの完全性が送信先（移動局すなわちＭＳ、または、基地局サブシステムすなわちＢＳＳのどちらか）によりチェックされ、伝送エラーの場合、再伝送要求が無線リンクの他端に与えられる。リンク層再伝送のため、フレームに対する肯定応答が受信されるまで、発信元は無線リンクフレームをバッファに格納しなければならない。悪化した無線状態では、このバッファはオーバフローし、データ損失を引き起こすおそれがある。それにもかかわらず、ストリーミングサービスに確認無線リンクプロトコルモードを用いることは有益であることが示されている。非確認接続では、誤りのある無線リンクフレームが典型的に廃棄される。

パケット損失を補正または隠匿することができる。損失補正は、いかなる損失も持ち込まれたことがなかったかのように、失ったデータを完全に復元する機能を意味する。損失の隠匿は、再構築されたビデオシーケンス内に伝送損失が現われないように伝送損失の影響を隠匿する機能を意味する。

プレーヤがパケット損失を検出すれば、プレーヤはパケットの再伝送を要求することができる。初期バッファリングのため、再伝送されるパケットを、予定した再生時間より前に受信することができる。幾つかの市販のインターネットストリーミングシステムは、専用プロトコルを用いて再伝送要求を実施する。ＲＴＣＰの一部として選択的な再伝送要求機構を標準化する作業がＩＥＴＦにおいて始まっている。

これら再伝送要求プロトコルのすべてに対する共通の特徴は、ネットワークトラヒックが急激に増大するおそれがあるので、これら再伝送要求プロトコルが、多数のプレーヤに対しマルチキャストするのに適さないということである。結果として、マルチキャストストリーミング分野は非双方向性パケット損失制御に依存しなければならない。

ポイントツーポイントストリーミングシステムも、非双方向性エラー制御技術により利益を得ることができる。第１に、幾つかのシステムは、いかなる双方向性エラー制御機構も含まなくて良く、または、これらシステムは、システムを単純化するためプレーヤからのいかなるフィードバックも望まない。第２に、双方向性エラー制御の損失パケット及び他の形態の再伝送は、典型的に非双方向性エラー制御方法よりも大きい伝送データレート部分を取る。ストリーミングサーバは、双方向性エラー制御方法が、使用できるネットワーク処理能力の大部分を蓄えておかないようにしなければならない。実際には、サーバは、双方向性エラー制御動作の量を制限しなければならない場合がある。第３に、特定のデータサンプルに対してすべての双方向性エラー制御動作を、好ましくはデータサンプルが再生される前に行うべきなので、伝送遅延はサーバとプレーヤとの間の相互作用の数を制限することができる。

非双方向性パケット損失制御機構を、前方のエラー制御及び後処理による損失の隠匿に分類することができる。前方のエラー制御は、伝送損失がある場合であっても受信機が伝送データの少なくとも一部分を回復できる冗長性を送信機が伝送データに加える技術を意味する。後処理によるエラーの隠匿は全体として受信機指向である。これらの方法は、誤って受信されたデータの正しい表現を推定しようとする。

大部分のビデオ圧縮アルゴリズムは、時間的に予測されたインターまたはＰピクチャを生成する。結果的には、１つのピクチャのデータ損失は、破損したものから時間的に予測され結果として生じたピクチャに、目に見える劣化を生じさせる。ビデオ通信システムは、表示される画像の損失を隠匿するか、または、破損したフレームから独立しているフレームを受信するまで、画面上で誤りのない最後のピクチャを凍結する。

従来のビデオ符号化規格では、復号化順序は出力順序と結合されている。言い換えれば、Ｉ及びＰピクチャの復号化順序は出力順序と同じであり、Ｂピクチャの復号化順序は、出力順序でＢピクチャの後にある参照ピクチャの復号化順序のすぐ後に続く。その結果として、既知の出力順序に基づいて復号化順序を回復することが可能である。出力順序は典型的に時間参照（ＴＲ）フィールドとＲＴＰヘッダのようなシステム多重層との双方にエレメンタリビデオビットストリームで伝達される。従って、従来のビデオ符号化規格では、提示された問題は存在しない。

当該技術分野の専門家にとって明らかである１つの解決策は、（ＪＶＴ符号化規格において行われるように）ＩＤＲピクチャで零に再設定することなく、Ｈ．２６３のピクチャ番号に類似するフレームカウンタを用いることである。しかし、この種の解決策が用いられるとき、幾つかの問題が生じるおそれがある。図５ａには、連続番号付け方式が用いられている状況を示す。例えば、ＩＤＲピクチャＩ３７が損失したら（ＩＤＲピクチャＩ３７を受信／復号化できなかったら）、デコーダは後続のピクチャを復号化し続けるが、誤った参照ピクチャを用いる。このことは、破損したフレームから独立する次のフレームが正確に受信され復号化されるまで、後続のフレームへエラー伝播を生じさせる。図５ｂの例では、フレーム番号はＩＤＲピクチャで零に再設定される。次に、ＩＤＲピクチャＩ０が損失した状況では、デコーダは、最後に正確に復号化されたピクチャＰ３６の後にピクチャ番号付けで大きな隔たりがあることを報告する。デコーダは次に、エラーが生じたことを想定することができ、破損したフレームから独立する次のフレームが受信され復号化されるまでピクチャＰ３６に対して表示を凍結することができる。

サブシーケンス

ＪＶＴ符号化規格は、符号化ストリームの残りの部分のデコーダビリティに影響を及ぼすことなくインター予測ピクチャチェーンを全体として配列することができるように、非参照ピクチャの使用に比べて時間スケーラビリティを改良できるサブシーケンス概念をも含む。

サブシーケンスはサブシーケンス層内の一連の符号化ピクチャである。ピクチャは１つのサブシーケンス層内に、且つ、１つだけのサブシーケンス内に存在すべきである。サブシーケンスは、同一または上位のサブシーケンス層内の他のいかなるサブシーケンスにも依存すべきでない。層０内のサブシーケンスを、他のあらゆるサブシーケンスと、前の長期にわたる参照ピクチャとに無関係に復号化することができる。図６ａには、層１にサブシーケンスを含むピクチャストリームの一例を表す。

サブシーケンス層はシーケンスに符号化ピクチャの一部を含む。サブシーケンス層は、負でない整数で番号付けられている。大きい層番号を有する層は、小さい層番号を有する層よりも高い層である。ある層がこの層よりも高い層のいずれにも依存せず、この層よりも低い層に依存できるように、層は相互依存性に基づいて階層的に順序付けられている。言い換えれば、層０を独立して復号化することができ、層０から層１のピクチャを予測することができ、層０及び１から層２のピクチャを予測することができる。主観的品質は復号化層の数と共に増大することが見込まれる。

サブシーケンス概念はＪＶＴ符号化規格に次の通りに含まれている。すなわち、符号化シーケンスがすべてのサブシーケンスを含まない場合があるシーケンスパラメータセット信号においてｒｅｑｕｉｒｅｄ＿ｆｒａｍｅ＿ｎｕｍ＿ｕｐｄａｔｅ＿ｂｅｈａｖｉｏｕｒ＿ｆｌａｇは１に等しい。ｒｅｑｕｉｒｅｄ＿ｆｒａｍｅ＿ｎｕｍ＿ｕｐｄａｔｅ＿ｂｅｈａｖｉｏｕｒ＿ｆｌａｇの使用は、各参照フレームに対してフレーム番号を１だけ増大することに関する要件を免除する。その代わり、フレーム番号の隔たりは、復号化ピクチャバッファ内に明確に印を付けられる。「欠けている」フレーム番号がインター予測で言及されれば、ピクチャの損失が推測される。そうでなければ、「欠けている」フレーム番号に対応するフレームは、これらフレームが、スライディングウィンドウバッファリングモードを含む復号化ピクチャバッファに挿入された正常なフレームであるかのように処理される。従って、配列されたサブシーケンス内のすべてのピクチャには、「欠けている」フレーム番号が復号化ピクチャバッファ内で割り当てられるが、それらは決して他のサブシーケンスのインター予測に用いられない。

ＪＶＴ符号化規格は、随意のサブシーケンス関連のＳＥＩメッセージをも含む。サブシーケンス情報ＳＥＩメッセージは、復号化順序で次のスライスに関連する。サブシーケンス情報ＳＥＩメッセージは、サブシーケンス層と、スライスが属するサブシーケンスのサブシーケンス識別子（ｓｕｂ＿ｓｅｑ＿ｉｄ）とを信号で伝える。

各ＩＤＲピクチャは識別子（ｉｄｒ＿ｐｉｃ＿ｉｄ）を含む。２つのＩＤＲピクチャが、いかなるピクチャも介在せずに復号化順序で連続していれば、ｉｄｒ＿ｐｉｃ＿ｉｄの値は最初のＩＤＲピクチャから他のＩＤＲピクチャに変更すべきである。復号化順序で最初のピクチャがＩＤＲピクチャであるサブシーケンス内に現在のピクチャが存在していれば、ｓｕｂ＿ｓｅｑ＿ｉｄの値は、ＩＤＲピクチャのｉｄｒ＿ｐｉｃ＿ｉｄの値と同じにすべきである。

いかなるデータもサブシーケンス層１以上に存在しない場合に限り、ＪＶＴ‐Ｄ０９３の解決策は正確に機能する。伝送順序が復号化順序と異なり、符号化ピクチャがサブシーケンス層１に存在した場合、サブシーケンス層０のピクチャに対する復号化順序を、サブシーケンス識別子及びフレーム番号に基づいて推論することができない。出力順序が左から右に流れ、ボックスがピクチャを表し、ボックス内の大文字が符号化タイプを示し、ボックス内の数字はＪＶＴ符号化規格によるフレーム番号を示し、下線の文字が非参照ピクチャを示し、矢印が予測依存性を示す図６ｂに示す次の符号化方式を例えば検討する。ピクチャがＩ０、Ｐ１、Ｐ３、Ｉ０、Ｐ１、Ｂ２、Ｂ４、Ｐ５の順序に伝送される場合、Ｂ２が属する独立したＧＯＰがどれかを推論することができない。

前の例において、ピクチャＢ２の正確な独立したＧＯＰを出力タイムスタンプに基づいて推論することができると主張するかもしれない。しかし、復号化順序及び出力順序が切り離されているので、出力タイムスタンプ及びピクチャ番号に基づいてピクチャの復号化順序を回復することができない。出力順序が左から右に流れ、ボックスがピクチャを表し、ボックス内の大文字が符号化タイプを示し、ボックス内の数字はＪＶＴ符号化規格によるフレーム番号であり、矢印が予測依存性を示す次の例（図６ｃ）を検討する。復号化順序が狂ってピクチャが伝送される場合、出力順序で１番目または２番目の独立したＧＯＰのＰ３の後にピクチャＰ４を復号化すべきかを確実に検出することができない。

バッファリング

典型的にストリーミングクライアントは、比較的大量のデータを格納できる受信機バッファを有する。初めに、ストリーミングセッションが確立されると、クライアントはストリームを直ちに再生し始めるのではなくむしろ、典型的に受信データを数秒間バッファリングする。伝送遅延が時折増大するか、またはネットワーク処理能力が落ちた場合、クライアントが、バッファに格納されたデータを復号化し再生するので、このバッファリングは連続再生を維持するのに役立つ。そうでなければ、初期バッファリングなしに、クライアントは表示を凍結し、復号化を停止し、受信データを待たなければならない。また、バッファリングは任意のプロトコルレベルに自動的または選択的な再伝送を必要とする。ピクチャのどこか一部が損失した場合、損失したデータを再送信するのに再伝送機構を用いることができる。予定した復号化または再生時間前に再送信データが受信された場合、損失は完全に回復される。

復号化シーケンスの主観的品質の重要性に従って符号化ピクチャをランク付けすることができる。例えば、従来のＢピクチャのような非参照ピクチャは主観的に最も重要でない。その理由は、それらの不在が他のいかなるピクチャの復号化にも影響を及ぼさないためである。データパーティションまたはスライス群に基づいても主観的ランク付けを行うことができる。主観的に最も重要である符号化スライス及びデータパーティションを、復号化順序が示すよりも前に送信することができるのに対して、主観的に最も重要でない符号化スライス及びデータパーティションを、本来の符号化順序が示すよりも後に送信することができる。その結果として、最も重要でないスライス及びデータパーティションに比べて、最も重要なスライス及びデータパーティションの再伝送部分のいずれかを、予定した復号化または再生時間の前に受信する可能性が高い。

プリデコーダバッファリング

プリデコーダバッファリングは、符号化データを復号化する前の符号化データのバッファリングを意味する。初期バッファリングは、ストリーミングセッションの初めのプリデコーダバッファリングを意味する。初期バッファリングは、下記に説明する２つの理由により従来通りに行われる。

従来のパケット切り替えマルチメディアシステムでは、例えば、ＩＰに基づくテレビ会議システムでは、異なる種類のメディアは通常、別々のパケットで伝達される。更に、パケットは、一定の伝送遅延を保証できるのではなくむしろ遅延がパケットごとに変化する場合のあるベストエフォートネットワークの上部に典型的に伝達される。その結果として、同一のプレゼンテーション（再生）タイムスタンプを有するパケットを同時に受信することができず、２つのパケットの受信間隔が（時間の点から見て）表示間隔と同じでないおそれがある。従って、異なるメディアタイプ間で再生の同期化を維持するため、且つ、正確な再生レートを維持するため、マルチメディア端末は、典型的に受信データを短期間（例えば、１／２秒未満）バッファリングして遅延変動を取り除く。本明細書では、この種のバッファ要素を遅延ジッタバッファと称する。メディアデータの復号化前及び／または後にバッファリングを行うことができる。

遅延ジッタバッファリングはストリーミングシステムでも適用される。ストリーミングが非対話型アプリケーションであるため、必要とされる遅延ジッタバッファを対話型アプリケーションの場合よりもかなり大きくする場合がある。ストリーミングプレーヤがサーバへの接続を確立し、ダウンロードすべきマルチメディアストリームを要求したら、サーバは所望のストリームを伝送し始める。プレーヤがストリームを直ちに再生し始めるのではなくむしろ、典型的に受信データを特定の期間、代表的には数秒間バッファリングする。本明細書では、このバッファリングを初期バッファリングと称する。初期バッファリングは、対話型アプリケーションにおける遅延ジッタバッファリングにより行われる機能に類似して伝送遅延変動を取り除く機能を具える。その上、損失したプロトコルデータユニット（ＰＤＵ）の再伝送をリンク層、トランスポート層及び／またはアプリケーション層の使用により可能にする。復号化され再生されるために予定した時刻に間に合うように再伝送ＰＤＵを受信することができるが、プレーヤは、バッファに格納されたデータを復号化し再生することができる。

ストリーミングクライアントにおける初期バッファリングは、対話型システムで達成することができない更なる別の利点を具える。すなわち、これにより、サーバから伝送されたメディアのデータレートを変更することができる。言い換えれば、受信機バッファがオーバフローまたはアンダーフローしない限り、メディアパケットを一時的に再生レートよりも速く、または遅く伝送することができる。データレートの変動は２つの原因から生じる。

第１には、ビデオのような幾つかのメディアタイプにおいて達成できる圧縮効率はソースデータのコンテンツに依存する。従って、安定した品質が望まれれば、結果として生じた圧縮ビットストリームのビットレートは変化する。典型的には、安定したオーディオビジュアル品質は、変化する品質よりも主観的に多く喜ばれる。それ故に、初期バッファリングにより、ビデオ会議システムのように初期バッファリングを用いないシステムに比べて多く喜ばれるオーディオビジュアル品質を達成することができる。

第２には、固定ＩＰネットワーク内のパケット損失が集中的に生じるということが一般に知られている。集中的なエラーと、高いピークのビットレート及びパケットレートとを回避するため、適切に設計されたストリーミングサーバはパケットの伝送を慎重にスケジューリングする。パケットが受信端で再生されるレートでパケットを正確に送信できるのではなくむしろ、サーバは、安定した間隔を伝送パケット間で達成しようとすることができる。優勢なネットワーク状態に従ってサーバはパケット伝送のレートを調節することもできる。例えば、ネットワークが混雑するようになると、パケット伝送レートを減少させ、ネットワーク状態に余裕があれば、パケット伝送レートを増大させる。

仮想参照デコーダ（ＨＲＤ）／ビデオバッファリングベリファイア（ＶＢＶ）

多くのビデオ符号化規格は、規格の不可欠な部分としてＨＲＤ／ＶＢＶ仕様を含む。ＨＲＤ／ＶＢＶ仕様は、入力（プリデコーダ）バッファを含む仮想デコーダモデルである。符号化データは典型的に一定のビットレートで入力バッファに流れる。出力タイムスタンプと同じにすることができる復号化タイムスタンプ時に符号化ピクチャは入力バッファから取り出される。入力バッファは、使用されるプロファイル及びレベルに依存する特定サイズを有する。ＨＲＤ／ＶＢＶモデルは、処理及びメモリ要件の観点からインターオペラビリティポイントを指定するのに用いられる。符号化は、生成されたビットストリームが特定のプロファイル及びレベルのＨＲＤ／ＶＢＶパラメータ値に従ってＨＲＤ／ＶＢＶ仕様に一致することを保証すべきである。特定のプロファイル及びレベルの支援を要求するデコーダは、ＨＲＤ／ＶＢＶモデルに一致するビットストリームを復号化できなければならない。

ＨＲＤは、符号化データストリームを格納する符号化ピクチャバッファと、復号化参照ピクチャを格納し、復号化ピクチャを表示順序に再順序付けする復号化ピクチャバッファとを含む。復号化装置のデコーダが行うのに類似してＨＲＤはデータをバッファ間で移動する。しかし、ＨＲＤは符号化ピクチャを完全に復号化するかまたは復号化ピクチャを出力する必要がないが、ＨＲＤは、符号化規格に与えられた制約の下でピクチャストリームの復号化を実行できることのみ検査する。ＨＲＤが動作中であるとき、ＨＲＤは符号化データストリームを受信し、それを符号化ピクチャバッファに格納する。更に、ＨＲＤは符号化ピクチャバッファから符号化ピクチャを取り出し、対応の仮想復号化ピクチャの少なくとも幾つかを復号化ピクチャバッファに格納する。ＨＲＤは、符号化データが符号化ピクチャバッファに流れる入力レートと、符号化ピクチャバッファからのピクチャの取り出しレートと、復号化ピクチャバッファからのピクチャの出力レートとを知っている。ＨＲＤは符号化または復号化ピクチャバッファのオーバフローについて検査し、復号化が現在の設定で可能でなければ指摘する。次に、ＨＲＤはバッファリング違反についてエンコーダに知らせる。バッファリング違反を回避するため、エンコーダは、例えば、参照フレームの数を減少させることにより符号化パラメータを変えることができる。その代わりに、または、それに加えて、エンコーダは、新たなパラメータを有するピクチャを符号化し始め、符号化ピクチャをＨＲＤに送信し、ＨＲＤは、ピクチャの復号化及び必要な検査を再び実行する。更なる別の代わりとして、いかなるバッファリング違反も起こらないように、エンコーダは最後の符号化フレームを廃棄し、フレームを後で符号化することができる。

２種類のデコーダ適合性、すなわち、出力順序適合性（ＶＣＬ適合性）及び出力時間適合性（ＶＣＬ‐ＮＡＬ適合性）はＪＶＴ符号化規格で指定されている。これらの種類の適合性はＨＲＤ仕様を用いて指定されている。出力順序適合性は、ピクチャの出力順序を正確に回復するデコーダの能力を意味する。ＨＲＤ仕様は、ピクチャに新しいストレージスペースが必要とされるときに、出力順序で最も早い非圧縮ピクチャを出力する「バンピングデコーダ」モデルを含む。出力時間適合性は、ＨＲＤモデルが行うのと同じ速度でピクチャを出力するデコーダの能力を意味する。ピクチャの出力タイムスタンプを常に、「バンピングデコーダ」から取り出される時間以下にする必要がある。

インターリービング

フレームインターリービングは、オーディオストリーミングにおいて一般に使用される技術である。フレームインターリービング技術では、１つのＲＴＰパケットは、復号化または出力順序で連続していないオーディオフレームを含む。オーディオパケットストリームにおいて１つのパケットが損失した場合、正確に受信されたパケットは、損失したオーディオパケットを（何らかの補間により）隠匿するのに用いることができる隣接したオーディオフレームを含む。多くのオーディオ符号化ＲＴＰペイロード及びＭＩＭＥタイプの仕様は、オーディオフレームに関して１つのパケットに最大量のインターリービングを信号送信する可能性を含む。

幾つかの従来技術の符号化／復号化方法では、必要とされるバッファのサイズが伝送ユニット数として知らされる。

デコーダのプリデコーディングバッファの最大サイズをバイトとしてデコーダに知らせることができる。バイトに基づく方式が用いられ、デコーダに対して再順序付け処理が規定されていなければ、バッファリングモデルは明確に規定されなければならない。その理由は、エンコーダ及びデコーダが異なるバッファリング方式を用いる場合があるためである。バッファに対してバイト単位で特定サイズが規定され、デコーダは、バッファが一杯になるまで、また、最も古いデータがバッファから取り出され復号化された後だけに伝送ユニットがバッファに格納されるバッファリング方式を用いるとする。このようなバッファリングは、復号化が開始される前に必要以上に長く続くことがある。

プリデコーディングバッファの最大サイズを知らせる別の実現性は伝送ユニットを用いることであり、この点、バッファのサイズは、バッファリングされる最大量の伝送ユニットとして知らされる。しかし、伝送ユニットの最大サイズは規定されておらず、伝送ユニットのサイズが変化するおそれがある。最大サイズが規定され、特定のデータユニットに対してサイズが小さすぎれば、データユニットを２つの以上の伝送ユニットに分割しなければならず、これによって符号化及び伝送オーバヘッドを増大させ、すなわち、圧縮効率を減少させ、且つ／または、システムの複雑性を増大させる。伝送ユニットの最大サイズは充分に大きくなければならず、バッファの合計サイズを不必要に大きくするおそれがある。

本発明では、少なくとも２つの伝送ユニットの合計サイズが規定され、この合計サイズに基づいて最大バッファサイズが規定されるように、バッファサイズが規定される。合計サイズに加えて、ネットワーク伝送ジッタを考慮することが必要である場合がある。

本発明の別の態様によれば、合計サイズの計算に用いられる伝送ユニットの数は、伝送ユニットの数に関して必要なバッファサイズの分数である。

本発明の更なる別の態様によれば、合計サイズの計算に用いられる伝送ユニットの数は、伝送ユニットの数に関して必要なバッファサイズの分数であり、分数は１／Ｎの形態を持っている。ここで、Ｎは整数である。

本発明の更に別の態様によれば、合計サイズの計算に用いられる伝送ユニットの数は、伝送ユニットの数に関して必要なバッファサイズと同じである。

本発明の実施形態では、合計サイズの計算に用いられる伝送ユニットの数は、伝送ユニットのバッファリング順序として表現される。バッファリング順序は、伝送ユニットが復号化のためにデコーダにバッファリングされる順序、すなわち、プリデコーダバッファにおけるバッファリング順序に関連する。

本発明は、デコーダに受信バッファのサイズを規定することができる。

以下では、独立したＧＯＰは、あるＩＤＲピクチャ（これを含む）から復号化順序で次のＩＤＲピクチャ（これを含まない）までのピクチャより成る。

本発明では、所要バッファの最大量を信号送信するパラメータを提案する。このようなパラメータの幾つかの単位すなわち、継続期間、バイト、符号化ピクチャ、フレーム、ＶＣＬ ＮＡＬユニット、あらゆるタイプのＮＡＬユニット、並びに、ＲＴＰパケットまたはペイロードが検討されている。不規則の量を継続期間で指定することは、伝送ビットレートと、指定された継続期間との間に依存関係を生じさせて、バイトでバッファリングの所要量を断定する。伝送ビットレートが一般に知られていないので、継続期間に基づくアプローチは用いられない。不規則の量をバイト数で指定することは、信号送信限度を超えないように、伝送されるストリームを慎重に検査する送信機を必要とする。このアプローチは、すべてのサーバから多くの処理能力を要求する。このアプローチは、サーバに対してバッファリングベリファイアを指定することも要求する。不規則の量を符号化ピクチャまたはフレームで指定することは、単位を粗くしすぎる。その理由は、任意スライス順序をサポートしないデコーダのための単一スライスインターリービング方法が、復号化順序の回復のためにバッファリングの最小レイテンシを達成するサブピクチャ分解を必要とするためである。異なるタイプの集約パケットが優勢なネットワーク状態に依存して存在する場合があるため、不規則の量をＲＴＰパケットの数で指定することは、適切であると考えられなかった。従って、あるＲＴＰパケットは、変化する量のデータを含む場合がある。異なるＳＥＩメッセージを優勢なネットワーク状態に依存して伝送する場合がある。例えば、比較的悪い状態では、シーン情報ＳＥＩメッセージのような、誤り耐性を対象としているＳＥＩメッセージを伝送するのが有益である。従って、あらゆるタイプのＮＡＬユニットの数で指定された不規則の量すなわち、順番が狂って伝送されるＳＥＩ及びパラメータセットＮＡＬユニットの量は優勢なネットワーク状態に依存する。従って、「あらゆるタイプのＮＡＬユニット」も良好な単位と考えられなかった。故に、不規則の量をＶＣＬ ＮＡＬユニットの数で指定することは最善の選択肢と考えられた。ＶＣＬ ＮＡＬユニットは、符号化スライス、符号化データパーティションまたはシーケンス終了マーカであるとＪＶＴ符号化規格に規定されている。

提案したパラメータはｎｕｍ‐ｒｅｏｒｄｅｒ‐ＶＣＬ‐ＮＡＬ‐ｕｎｉｔｓである。このパラメータは、ＮＡＬユニット配信順序においてパケットストリーム内のいかなるＶＣＬ ＮＡＬユニットにも先行し、ＲＴＰシーケンス番号順において、または、ＶＣＬ ＮＡＬユニットを含む集約パケットの作成順においてＶＣＬ ＮＡＬユニットの後に続くＶＣＬ ＮＡＬユニットの最大量を指定する。

ＭＩＭＥタイプの通知における随意のパラメータとして、または随意のＳＤＰフィールドとして、提案したパラメータを伝達することができる。提案したパラメータは、セッション設定手続きの段階及びプロトコルに応じてデコーダ機能またはストリーム特性またはその双方を示すことができる。

パラメータｎｕｍ‐ｒｅｏｒｄｅｒ‐ＶＣＬ‐ＮＡＬ‐ｕｎｉｔｓに従って構成されたバッファのバッファサイズをバイトで正確に指定することができない。バッファリングメモリ要件が正確に知られる受信機の設計を可能にするため、復号化時間適合性の指定を提案する。復号化時間適合性は仮想バッファリングモデルを用いて指定される。この仮想バッファリングモデルは一定の入力ビットレートをとるのではなくむしろ、伝送されたパケットストリームがモデルに整合することを保証するため、ストリーミングサーバがモデルを含むことを要求する。指定された仮想バッファモデルは場合によって集中的なパケットレートを防止し、結果として生じたビットストリームを一定のビットレートで仮想デコーダに入力できるようにＮＡＬユニットを伝送順序から復号化順序へ再順序付けする。

下記の記載では、エンコーダ‐デコーダに基づくシステムを用いることにより本発明を説明するが、ビデオ信号が格納されるシステムでも本発明を実装できること明らかである。格納されたビデオ信号を、符号化前に格納された符号化されていない信号、または、符号化後に格納された符号化信号、または、符号化及び復号化処理後に格納された復号化信号とすることができる。例えば、エンコーダは復号化順序でビットストリームを生成する。ファイルシステムは、例えば復号化順序にカプセル化されファイルとして格納されたオーディオ及び／またはビデオビットストリームを受信する。更に、エンコーダ及びファイルシステムは、ＮＡＬユニット及びピクチャの主観的な重要性を知らせ、特にサブシーケンスに関する情報を含むメタデータを生成することができる。ファイルをデータベースに格納することができ、このデータベースからストリーミングサーバがＮＡＬユニットを読み取り、これらＮＡＬユニットをＲＴＰパケットにカプセル化することができる。使用されるデータ接続及び随意のメタデータに従って、ストリーミングサーバは、例えば、復号化順序と異なるパケットの伝送順序を変更し、サブシーケンスを取り除き、ＳＥＩメッセージがあれば、何のＳＥＩメッセージを伝送するかを決定することができる。受信端では、ＲＴＰパケットは受信され、バッファリングされる。典型的に、ＮＡＬユニットがまず正確な順序に再順序付けされ、その後、ＮＡＬユニットがデコーダに配信される。

更に、下記の記載では、エンコーダ‐デコーダに基づくシステムを用いることにより本発明を説明するが、エンコーダが符号化データをストリーミングサーバのような他の構成要素に復号化順序で出力し伝送するシステムでも本発明を実装できること明らかである。他の構成要素は、符号化データを復号化順序から他の順序へ再順序付けし、再順序付けした形態の符号化データをデコーダに転送する。

本発明による方法は、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズが規定されることを主として特徴とする。本発明によるシステムは、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズを規定するデファイナをシステムが更に含むことを主として特徴とする。本発明によるエンコーダは、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズを規定するデファイナをエンコーダが更に含むことを主として特徴とする。本発明によるデコーダは、デコーダが、バッファサイズを示す受信パラメータに従ってプリデコーディングバッファのためにメモリを割り当てるプロセッサを更に含み、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファサイズが規定されることを主として特徴とする。本発明による伝送装置は、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズを規定するデファイナを伝送装置が更に含むことを主として特徴とする。本発明による受信装置は、デコーダが、バッファサイズを示す受信パラメータに従ってプリデコーディングバッファのためにメモリを割り当てるプロセッサを更に含み、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファサイズが規定されることを主として特徴とする。本発明によるソフトウェアプログラムは、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズが規定されることを主として特徴とする。本発明による記憶媒体は、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズが規定されることを主として特徴とする。本発明による電子装置は、少なくとも２つの伝送ユニットの合計サイズが規定され、合計サイズに基づいて最大バッファサイズが規定されるように、バッファのサイズを規定するデファイナを電子装置が更に含むことを主として特徴とする。

本発明の有利な実施形態に従っていかなる復号化順序情報にもビデオビットストリームで信号送信する代替案を下記に提示する。復号化順序番号（ＤＯＮ）は、デコーダへのＮＡＬユニットの配信順序と異なるＮＡＬユニットの復号化順序を示す。以下、一般性を失わずに、ＤＯＮを１６ビット符号なし整数であると仮定する。あるＮＡＬユニットのＤＯＮがＤ１であり、別のＮＡＬユニットのＤＯＮがＤ２であるとする。Ｄ１＜Ｄ２かつＤ２−Ｄ１＜３２７６８であれば、または、Ｄ１＞Ｄ２かつＤ１−Ｄ２≧３２７６８であれば、Ｄ１に等しいＤＯＮを有するＮＡＬユニットは、ＮＡＬユニット配信順序において、Ｄ２に等しいＤＯＮを有するＮＡＬユニットに先行する。Ｄ１＜Ｄ２かつＤ２−Ｄ１≧３２７６８であれば、または、Ｄ１＞Ｄ２かつＤ１−Ｄ２＜３２７６８であれば、Ｄ２に等しいＤＯＮを有するＮＡＬユニットは、ＮＡＬユニット配信順序において、Ｄ１に等しいＤＯＮを有するＮＡＬユニットに先行する。異なる１次符号化ピクチャと関連するＮＡＬユニットは同一値のＤＯＮを持たない。同一の１次符号化ピクチャと関連するＮＡＬユニットは同一値のＤＯＮを持つことができる。１次符号化ピクチャのＮＡＬユニットすべてが同一値のＤＯＮを持っていれば、１次符号化ピクチャと関連する冗長符号化ピクチャのＮＡＬユニットは、１次符号化ピクチャのＮＡＬユニットと同じ値のＤＯＮを持つべきである。同一値のＤＯＮを有するＮＡＬユニットのＮＡＬユニット配信順序が次の通りであるのが好ましい。
１． ピクチャ区切りＮＡＬユニットがあるとすれば、ピクチャ区切りＮＡＬユニット
２． シーケンスパラメータセットＮＡＬユニットがあるとすれば、シーケンスパラメータセットＮＡＬユニット
３． ピクチャパラメータセットＮＡＬユニットがあるとすれば、ピクチャパラメータセットＮＡＬユニット
４． ＳＥＩ ＮＡＬユニットがあるとすれば、ＳＥＩ ＮＡＬユニット
５． １次符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニットがあるとすれば、１次符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニット
６． 冗長符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニットがあるとすれば、冗長符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニット
７． フィラーデータＮＡＬユニットがあるとすれば、フィラーデータＮＡＬユニット
８． シーケンス終了ＮＡＬユニットがあるとすれば、シーケンス終了ＮＡＬユニット
９． ストリーム終了ＮＡＬユニットがあるとすれば、ストリーム終了ＮＡＬユニット

本発明は符号化システムのバッファリング効率を改善する。本発明を用いることにより、どのくらいプリデコーディングバッファリングが必要とされるかを復号化装置に知らせることができる。従って、復号化装置でプリデコーディングバッファに対して必要以上多くのメモリを割り当てる必要がない。しかも、プリデコーディングバッファのオーバフローを回避することができる。

再帰的な時間スケーラビリティ方式の一例を示す図である。 一連のピクチャが、２つ以上の独立して符号化されたスレッドにインターリーブ形式に分割されるビデオ冗長符号化と称する方式を示す図である。 圧縮効率を改善する可能性を秘めている予測構造の一例を示す図である。 誤り耐性の改善に用いることができるイントラピクチャの後回し方式の一例を示す図である。 符号化ビデオストリームのピクチャに対する異なる従来技術の番号付け方式を示す図である。 符号化ビデオストリームのピクチャに対する異なる従来技術の番号付け方式を示す図である。 層１にサブシーケンスを含むピクチャストリームの一例を表す図である。 層１にサブシーケンスを有する２つのグループオブピクチャを含むピクチャストリームの一例を表す図である。 異なるグループオブピクチャのピクチャストリームの一例を表す図である。 層１にサブシーケンスを含むピクチャストリームの他の例を表す図である。 本発明によるシステムの有利な実施形態を表す図である。 本発明によるエンコーダの有利な実施形態を表す図である。 本発明によるデコーダの有利な実施形態を表す図である。 本発明と用いることができるＮＡＬパケットフォーマットの一例を表す図である。 本発明と用いることができるＮＡＬパケットフォーマットの他の例を表す図である。 プリデコーダバッファにおける伝送ユニットのバッファリングの一例を表す図である。

デパケット化ルールの背後にある一般概念は、ＮＡＬユニットのような伝送ユニットを伝送順序からＮＡＬユニット復号化順序に再順序付けすることにある。

受信機は、パケットを伝送順序からＮＡＬユニット復号化順序に再順序付けするのに用いられる受信機バッファ（またはプリデコーダバッファ）を含む。本発明の例示的な一実施形態では、受信機バッファサイズは、バイト数の観点から、ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅパラメータの値以上に、例えば、値１．２×ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅ ＭＩＭＥパラメータの値に設定されている。受信機は伝送遅延ジッタのバッファリングも考慮に入れて、別々のバッファを伝送遅延ジッタバッファリングのために取っておくか、または、伝送遅延ジッタのバッファを受信機バッファと結合する（従って、受信機バッファ内に幾つかの追加のスペースを遅延ジッタバッファリングのために取っておく）ことができる。

受信機は次の通りに受信ＮＡＬユニットを受信順に受信機バッファ内に格納する。集約パケットのＮＡＬユニットを受信機バッファ内に個々に格納する。すべてのＮＡＬユニットについてＤＯＮの値を計算し、格納する。

ここで、Ｎは、ＮＡＬユニット伝送順序においてパケットストリーム内のいかなるＶＣＬ ＮＡＬユニットにも先行し、復号化順序においてＶＣＬ ＮＡＬユニットの後に続くＶＣＬ ＮＡＬユニットの最大量を指定する随意のパラメータｎｕｍ‐ｒｅｏｒｄｅｒ‐ＶＣＬ‐ＮＡＬ‐ｕｎｉｔｓ（インターリーブ深さパラメータ）の値であるとする。パラメータが存在しない場合、０値の数であることを暗黙的に示す。

ビデオストリーム転送セッションが初期化されると、受信機８は、少なくともＮ個のＶＣＬ ＮＡＬユニットを格納するため、メモリを受信バッファ９．１に割り当てる。次に、受信機はビデオストリームを受信し始め、受信したＶＣＬ ＮＡＬユニットを受信バッファに格納する。初期バッファリングは、
‐ 少なくともＮ個のＶＣＬ ＮＡＬユニットが受信バッファ９．１に格納されるまで、または、
‐ ｎが、受信したＮＡＬユニットのうちでＡｂｓＤＯＮの最大値を有するＮＡＬユニットに対応し、ｍが、受信したＮＡＬユニットのうちでＡｂｓＤＯＮの最小値を有するＮＡＬユニットに対応し、ｍａｘ‐ｄｏｎ‐ｄｉｆｆ ＭＩＭＥパラメータが存在すれば、関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の値がｍａｘ‐ｄｏｎ‐ｄｉｆｆの値よりも大きくなるまで、または、
‐ 初期バッファリングが随意のｉｎｉｔ‐ｂｕｆ‐ｔｉｍｅ ＭＩＭＥパラメータの値以上の期間経過するまで
持続する。

関数ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）は次の通りに指定されている。すなわち、
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）であれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝０
ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）且つ ＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８であれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）且つ ＤＯＮ（ｍ）−ＤＯＮ（ｎ）≧３２７６８であれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）且つ ＤＯＮ（ｎ）−ＤＯＮ（ｍ）≧３２７６８であれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）且つ ＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８であれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）＝−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、伝送順序でインデックスｉを有するＮＡＬユニットの復号化順序番号である。

ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）の正の値は、伝送順序インデックスｎを有するＮＡＬユニットが復号化順序において、伝送順序インデックスｍを有するＮＡＬユニットの後に来るということを示す。

ＡｂｓＤＯＮは、６５５３５の後で０にラップアラウンドしないＮＡＬユニットの復号化順序番号を意味する。言い換えれば、ＡｂｓＤＯＮは次の通りに計算される。

ｍ及びｎが、伝送順序に連続したＮＡＬユニットであるとする。（０であるインデックスを有する）伝送順序でまさしく最初のＮＡＬユニットに対して、ＡｂｓＤＯＮ（０）＝ＤＯＮ（０）である。他のＮＡＬユニットに対して、ＡｂｓＤＯＮは次の通りに計算される。すなわち、
ＤＯＮ（ｍ）＝＝ＤＯＮ（ｎ）であれば、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）
ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）且つ ＤＯＮ（ｎ）−ＤＯＮ（ｍ）＜３２７６８であれば、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋ＤＯＮ（ｎ）−ＤＯＮ（ｍ）
ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）且つ ＤＯＮ（ｍ）−ＤＯＮ（ｎ）≧３２７６８であれば、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｍ）＋ＤＯＮ（ｎ）
ＤＯＮ（ｍ）＜ＤＯＮ（ｎ）且つ ＤＯＮ（ｎ）−ＤＯＮ（ｍ）≧３２７６８であれば、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）＋６５５３６−ＤＯＮ（ｎ））
ＤＯＮ（ｍ）＞ＤＯＮ（ｎ）且つ ＤＯＮ（ｍ）−ＤＯＮ（ｎ）＜３２７６８であれば、ＡｂｓＤＯＮ（ｎ）＝ＡｂｓＤＯＮ（ｍ）−（ＤＯＮ（ｍ）−ＤＯＮ（ｎ））
ここで、ＤＯＮ（ｉ）は、伝送順序でインデックスｉを有するＮＡＬユニットの復号化順序番号である。

受信機において通常２つのバッファリング状態すなわち初期バッファリングと再生中のバッファリングとがある。ＲＴＰセッションが初期化されると、初期バッファリングが起こる。初期バッファリングの後、復号化及び再生が開始され、再生中バッファリングモードが用いられる。

受信機バッファ９．１が少なくともＮ個のＶＣＬ ＮＡＬユニットを含む場合、ＮＡＬユニットは受信機バッファ９．１から１つずつ取り出され、デコーダ２に移される。ＮＡＬユニットは必ずしも、ＮＡＬユニットが格納された順序と同じ順序で受信機バッファ９．１から取り出されるとは限らないが、下記に説明するようにＮＡＬユニットのＤＯＮに従って取り出される。バッファがＮ個のＶＣＬ ＮＡＬユニット未満すなわち（Ｎ−１）個のＶＣＬ ＮＡＬユニットを含むまでデコーダ２へのパケットの供給は継続する。

受信機バッファから取り出されるＮＡＬユニットは以下の通りに決定される。すなわち、
− 受信機バッファが少なくともＮ個のＶＣＬ ＮＡＬユニットを含めば、ＮＡＬユニットは受信機バッファから取り出され、バッファが（Ｎ−１）個のＶＣＬ ＮＡＬユニットを含むまで、下記に指定される順序でデコーダに移される。
− ｍａｘ‐ｄｏｎ‐ｄｉｆｆが存在すれば、ｄｏｎ＿ｄｉｆｆ（ｍ，ｎ）がｍａｘ‐ｄｏｎ‐ｄｉｆｆよりも大きいすべてのＮＡＬユニットｍが受信機バッファから取り出され、下記に指定される順序でデコーダに移される。ここで、ｎは、受信したＮＡＬユニットのうちでＡｂｓＤＯＮの最大値を有するＮＡＬユニットに対応する。
− ＮＡＬユニットストリームの第１パケットが受信されたときに０に初期化されたシステムタイマの値に変数ｔｓが設定される。受信機バッファが、ｔｓ−ｔｒ＞ｉｎｉｔ‐ｂｕｆ‐ｔｉｍｅという条件を満たす受信時間ｔｒを有するＮＡＬユニットを含めば、ＮＡＬユニットは、指定された条件を満たす受信時間ｔｒを有するＮＡＬユニットのいずれをも受信機バッファが含まなくなるまで、下記に指定される順序でデコーダに移され（受信機バッファから取り出され）る。

ＮＡＬユニットがデコーダに移される順序は次の通りに指定される。

ＰＤＯＮが、ＲＴＰセッションの初めで０に初期化される変数であるとする。ＤＯＮの値と関連する各ＮＡＬユニットに対して、ＤＯＮ間隔は以下の通りに計算される。ＮＡＬユニットのＤＯＮの値がＰＤＯＮの値よりも大きければ、ＤＯＮ間隔はＤＯＮ−ＰＤＯＮに等しい。そうでなければ、ＤＯＮ間隔は６５５３５−ＰＤＯＮ＋ＤＯＮ＋１に等しい。

ＮＡＬユニットはＤＯＮ間隔の昇順でデコーダに供給される。幾つかのＮＡＬユニットがＤＯＮ間隔の同一値を共有すれば、それらを任意の順序でデコーダに移すことができる。所望の数のＮＡＬユニットがデコーダに移されていれば、ＰＤＯＮの値は、デコーダに移された最後のＮＡＬユニットのＤＯＮの値に設定される。

追加のデパケット化の指針

下記の追加のデパケット化ルールを用いて、操作可能なＨ．２６４デパケッタイザを実装することができる。

（例えば、ゲートウェイにおける）知的ＲＴＰ受信機は、損失した符号化スライスデータパーティションＡ（ＤＰＡ）を識別することができる。損失したＤＰＡが検出されれば、ゲートウェイは、対応の符号化スライスデータパーティションＢ及びＣを送信しないと決定することができる。その理由は、それら情報がＨ．２６４デコーダにとって意味のないものであるからである。このように、ネットワーク要素は、複雑なビットストリームを解析することなく、無駄なパケットを廃棄することによりネットワーク負荷を減少させることができる。

（例えば、ゲートウェイにおける）知的ＲＴＰ受信機は、損失した部分的なユニット（ＦＵ）を識別することができる。損失したＦＵが検出されれば、ゲートウェイは、同一のＮＡＬユニットのうちで次に来るＦＵを送信しないと決定することができる。その理由は、それら情報がＨ．２６４デコーダにとって意味のないものであるからである。このように、ネットワーク要素は、複雑なビットストリームを解析することなく、無駄なパケットを廃棄することによりネットワーク負荷を減少させることができる。

パケットまたはＮＡＬＵを廃棄する必要がある知的受信機は、ＮＡＬユニットタイプオクテットのＮＲＩフィールドの値が０に等しいすべてのパケット／ＮＡＬＵを最初に廃棄することができる。このことは、ユーザ体験に与える影響を最小限に抑えることができる。

以下では、デコーダにおいて最大のバッファサイズを示すのに用いられるパラメータについて説明する。パケット化モードを表すパケット化モードパラメータが存在しないときか、または、パケット化モードパラメータの値が０または１に等しいときには通常、パラメータｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅは存在しない。このパラメータは、パケット化モードパラメータの値が２に等しいときには存在しなければならない。

パラメータｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅの値は、以下の仮想デインターリービングバッファモデルと関連して指定される。最初に、仮想デインターリービングバッファは空であり、最大バッファ占有値ｍは０に設定されている。このモデルにおいて、以下の処理が用いられる。すなわち、
ｉ）伝送順序で次のＶＣＬ ＮＡＬユニットを仮想デインターリービングバッファに挿入する。
ｉｉ）ｓが、バイト単位で表すバッファにおけるＶＣＬ ＮＡＬユニットの合計サイズであるとする。
ｉｉｉ）ｓがｍよりも大きければ、ｍはｓに等しく設定される。
ｉｖ）仮想デインターリービングバッファにおけるＶＣＬ ＮＡＬユニットの数がインターリーブ深さの値以下であれば、段階ｖｉｉから処理を継続する。
ｖ）仮想デインターリービングバッファにおけるＶＣＬ ＮＡＬユニットのうち復号化順序で最も早いＶＣＬ ＮＡＬユニットを、ＲＦＣ ＸＸＸＸのセクション５．５に従ってＶＣＬ ＮＡＬユニットのＤＯＮの値から決定する。
ｖｉ）最も早いＶＣＬ ＮＡＬユニットを仮想デインターリービングバッファから取り出す。
ｖｉｉ）伝送順序においてそれ以上ＶＣＬ ＮＡＬユニットがなければ、処理を終了する。
ｖｉｉｉ）処理を段階ｉから継続する。

このパラメータは、ＮＡＬユニットストリームのプロパティまたは受信機実行の可能性を通知する。パラメータがＮＡＬユニットストリームのプロパティを通知するのに用いられるとき、パラメータＶの値は、
ａ）ＮＡＬユニットストリームが仮想デインターリービングバッファモデルにより完全に処理されたときに生じるｍの値は、ｖ以下である。または、
ｂ）バッファオーバフローがある限り、最も早いＶＣＬ ＮＡＬユニットをデインターリービングバッファから取り出すことにより決定されたＶＣＬ ＮＡＬユニットの順序は、仮想デインターリービングバッファからＶＣＬ ＮＡＬユニットを取り出す順序と同じである。

その結果として、ＶＣＬ ＮＡＬユニット復号化順序回復のバッファサイズが、バイト単位で表す少なくともｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅの値であるとき、受信機がＶＣＬ ＮＡＬユニット復号化順序を再構築できることが保証される。

パラメータが、受信機実行の可能性を通知するのに用いられる場合、受信機は、ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅの同一値により特徴付けられるあらゆるＮＡＬユニットストリームのＶＣＬ ＮＡＬユニット復号化順序を正確に再構築することができる。受信機が、ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅの値以上であるこのようなバイト数をバッファリングする場合、ＶＣＬ ＮＡＬユニット復号化順序を伝送順序から再構築することができる。

デインターリービングバッファのサイズを決定するときに非ＶＣＬ ＮＡＬユニットをも考慮すべきである。このパラメータが存在する場合、すべてのＮＡＬユニットに対してデインターリービングバッファの充分なサイズは、このパラメータの値よりも２０％大きい値以下である。

このパラメータが存在しなければ、ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅに０の値が用いられる。ｄｅｉｎｔ‐ｂｕｆ‐ｓｉｚｅの値は、例えば０〜４２９４９６７２９５の範囲内にある整数である。

以下では、図８のシステムと、図９のエンコーダ１及び仮想参照デコーダ（ＨＲＤ）５と、図１０のデコーダ２とを参照して本発明を詳細に説明する。符号化されるピクチャを、例えば、ビデオ源３例えばカメラやビデオレコーダなどからのビデオストリームのピクチャとすることができる。ビデオストリームのピクチャ（フレーム）をスライスのような細かい部分に分割することができる。スライスを更にブロックに分割することができる。エンコーダ１では、ビデオストリームは、伝送チャネル４を介して伝送されるか、または記憶媒体（図示せず）へ伝送される情報を減少させるように符号化される。ビデオストリームのピクチャはエンコーダ１に入力される。エンコーダは、符号化されるピクチャの幾つかを一時的に格納する符号化バッファ１．１（図９）を有する。エンコーダ１は、本発明による符号化タスクを適用できるメモリ１．３及びプロセッサ１．２をも含む。メモリ１．３及びプロセッサ１．２は伝送装置６と共通化することができる。または、伝送装置６は、伝送装置６の他の機能のために他のプロセッサ及び／またはメモリ（図示せず）を有することができる。エンコーダ１は、ビデオストリームを圧縮するために動き補償及び／または他のタスクを実行する。動き推定では、符号化されるピクチャ（現在のピクチャ）と、前及び／または後のピクチャと間の類似点を検索する。類似点が検出されれば、比較されたピクチャまたはその一部を、符号化されるピクチャ用の参照ピクチャとして用いることができる。ＪＶＴでは、ピクチャの表示順序と復号化順序とが同一とは限らない。参照ピクチャとして用いられる限り、参照ピクチャをバッファ内（例えば、符号化バッファ１．１）に格納しなければならない。また、エンコーダ１は、ピクチャの表示順序に関する情報を伝送ストリームに挿入する。

必要ならば、符号化ピクチャは符号化処理から符号化ピクチャバッファ５．２に移動される。符号化ピクチャは、伝送チャネル４を介してエンコーダ１からデコーダ２に伝送される。デコーダ２では、符号化ピクチャは、可能な限り符号化ピクチャに一致する伸長ピクチャを形成するように復号化される。復号化ピクチャが復号化のほとんど直後に表示されず、参照ピクチャとして用いられる限り、各復号化ピクチャはデコーダ２のＤＰＢ２．１にバッファリングされる。本発明によるシステムでは、参照ピクチャバッファリング及び表示ピクチャバッファリングの双方は結合され、それらは同一の復号化ピクチャバッファ２．１を用いる。このことは、２つの異なる場所に同一のピクチャを格納する必要性を削減し、従って、デコーダ２のメモリ要件を減少させる。

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

符号化

次に、符号化‐復号化処理を詳細に検討する。ビデオ源３からのピクチャはエンコーダ１に入力され、有利には、符号化バッファ１．１に格納される。符号化処理は、最初のピクチャがエンコーダに入力された直後に開始されるとは限らないが、符号化バッファ１．１内に特定量のピクチャが利用できるようになってから開始される。次に、エンコーダ１は、参照フレームとして用いられるピクチャから適切な候補を検出しようとする。次に、エンコーダ１は、符号化ピクチャを形成するように符号化を実行する。符号化ピクチャを、例えば、予測ピクチャ（Ｐ）、双予測ピクチャ（Ｂ）及び／またはイントラ符号化ピクチャ（Ｉ）とすることができる。他のいかなるピクチャをも用いず、イントラ符号化ピクチャを復号化することができるが、他のタイプのピクチャは、それらを復号化できる前に少なくとも１つの参照ピクチャを必要とする。上述したピクチャタイプのいずれかのピクチャを参照ピクチャとして用いることができる。

エンコーダは、２つのタイムスタンプすなわち復号化タイムスタンプ（ＤＴＳ）及び出力タイムスタンプ（ＯＴＳ）をピクチャに添付するのが有利である。デコーダは、正確な復号化時間及びピクチャの出力（表示）時間を決定するのにタイムスタンプを用いることができる。しかし、これらタイムスタンプはデコーダに伝送されるとは限らず、または、デコーダがこれらタイムスタンプを用いない場合がある。

また、エンコーダは、最下の層０よりも上にある１つ以上の層でサブシーケンスを形成する。層０のピクチャを独立して復号化することができるが、上位の層のピクチャは、ある下位の層または幾つかの下位の層のピクチャに依存することができる。図６ａの例では、２つの層すなわち層０及び層１がある。図６ａに示すように、ピクチャＩ０、Ｐ６及びＰ１２が層０に属するのに対して、他のピクチャＰ１〜Ｐ５及びＰ７〜Ｐ１１は層１に属する。有利には、エンコーダは、同一のグループオブピクチャ（ＧＯＰ）のピクチャのみを用いることにより１つのＧＯＰの各ピクチャを再構築できるようにＧＯＰを形成する。言い換えれば、１つのＧＯＰは、少なくとも１つの独立して復号化できるピクチャを含み、他のすべてのピクチャに対して、独立して復号化できるピクチャが参照ピクチャである。図７の例では、２つのグループオブピクチャがある。第１グループオブピクチャは、層０のピクチャＩ０（０），Ｐ１（０），Ｐ３（０）と層１のピクチャＢ２（０），２×Ｂ３（０），Ｂ４（０），２×Ｂ５（０），Ｂ６（０），Ｐ５（０），Ｐ６（０）とを含む。第２グループオブピクチャは、層０のピクチャＩ０（１），Ｐ１（１）と層１のピクチャ２×Ｂ３（１），Ｂ２（１）とを含む。各グループオブピクチャの層１のピクチャはサブシーケンスとして更に配置されている。第１グループオブピクチャの第１サブシーケンスはピクチャＢ３（０），Ｂ２（０），Ｂ３（０）を含み、第２サブシーケンスはピクチャＢ５（０），Ｂ４（０），Ｂ５（０）を含み、第３サブシーケンスはピクチャＢ６（０），Ｐ５（０），Ｐ６（０）を含む。第２グループオブピクチャのサブシーケンスはピクチャＢ３（１），Ｂ２（１），Ｂ３（１）を含む。かっこの中の数字は、ピクチャが属するグループオブピクチャに対して規定されているビデオシーケンスＩＤを示す。

ビデオシーケンスＩＤは各ピクチャについて転送される。ビデオシーケンスＩＤを追加拡張情報データの場合のようにビデオビットストリームで伝達することができる。ＪＶＴ符号化規格のＲＴＰペイロードヘッダでのようなトランスポートプロトコルのヘッダフィールドでもビデオシーケンスＩＤを伝送することができる。独立したＧＯＰに与えられた分割によるビデオシーケンスＩＤを、ＭＰＥＧ‐４ ＡＶＣファイルフォーマットのようなビデオファイルフォーマットのメタデータに格納することができる。図１１ａ及び図１１ｂには、本発明と用いることができるＮＡＬパケットフォーマットの例を表す。パケットは、ヘッダ１１及びペイロード部１２を含む。ヘッダ１１は、エラー表示子フィールド１１．１（Ｆ，Ｆｏｒｂｉｄｄｅｎ（禁制））、優先フィールド１１．２及びタイプフィールド１１．３を含むのが有利である。エラー表示子フィールド１１．１は、ビットエラーのないＮＡＬユニットを示す。エラー表示子フィールドが設定されている場合、デコーダは、ビットエラーがペイロードまたはＮＡＬＵタイプオクテットに存在するおそれがあることを忠告するのが有利である。ビットエラーを処理できないデコーダは次に、このようなパケットを廃棄することができる。優先フィールド１１．２は、パケットのペイロード部１２にカプセル化されたピクチャの重要性を示すのに用いられる。例示的な実施形態では、優先フィールドは、次の通りに４つの異なる値を有することができる。００の値は、（将来の参照ピクチャとして用いることができる）格納されたピクチャを再構築するのにＮＡＬＵの内容が用いられないということを示す。参照ピクチャの整合性を危うくすることなく、このようなＮＡＬＵを廃棄することができる。００よりも上の値は、参照ピクチャの整合性を維持するのにＮＡＬＵの復号化が必要とされるということを示す。更に、００よりも上の値は、エンコーダにより決定されるような相対移送優先順位を示す。この情報を用いて、知的ネットワーク要素は、重要性の低いＮＡＬＵよりも重要性の高いＮＡＬＵを保護することができる。１１は、最も高い移送優先順位を示し、その後に１０であって、次に０１が続き、最後に、００が最も低い。

ＮＡＬＵのペイロード部１２は、少なくともビデオシーケンスＩＤフィールド１２．１、フィールド表示子１２．２、サイズフィールド１２．３、タイミング情報１２．４及び符号化ピクチャ情報１２．５を含む。ビデオシーケンスＩＤフィールド１２．１は、ピクチャが属するビデオシーケンスの数を格納するのに用いられる。フィールド表示子１２．２は、２フレームピクチャ形式が用いられる場合にピクチャが第１フレームであるか第２フレームであるかを信号送信するのに用いられる。双方のフレームを別々のピクチャとして符号化することができる。１に等しい第１フィールド表示子は、同一フレームのうち復号化順序で第２の符号化フィールドに先行する符号化フィールドまたは符号化フレームにＮＡＬＵが属することを通知するのが有利である。０に等しい第１フィールド表示子は、同一フレームのうち復号化順序で第１の符号化フィールドの後に続く符号化フィールドにＮＡＬＵが属することを通知する。タイミング情報フィールド１１．３は、必要に応じ、時間に関する情報を変換するのに用いられる。

異なる種類のパケットでＮＡＬユニットを配信することができる。この有利な実施形態では、異なるパケットフォーマットは、単純パケット及び集約パケットを含む。集約パケットをシングルタイム集約パケット及びマルチタイム集約パケットに更に分割することができる。

本発明による単純パケットは１つのＮＡＬＵから成る。単純パケットをＲＴＰシーケンス番号順にデカプセル化することにより構成されたＮＡＬユニットストリームはＮＡＬユニット配信順序に合致しなければならない。

集約パケットは、このペイロード仕様のパケット集約方式である。この方式は、２つの異なるタイプのネットワークすなわち（Ｅｔｈｅｒｎｅｔ（登録商標）ＭＴＵサイズによりしばしば制限されるＭＴＵサイズ‐‐約１５００バイトを有する）有線ＩＰネットワークと、２５４バイト以下の好ましい伝送ユニットサイズを有するＩＰまたは非ＩＰ（例えば、Ｈ．３２４／Ｍ）ベースの無線ネットワークとの劇的に異なるＭＴＵサイズを反映するように導入されている。２つの世界間のメディアトランスコーディングを防止するため、また、不所望なパケット化オーバヘッドを回避するため、パケット集約方式は導入されている。

シングルタイム集約パケット（ＳＴＡＰ）は、同一のＮＡＬＵタイムでＮＡＬＵを集約する。マルチタイム集約パケット（ＭＴＡＰ）は、異なる可能性を秘めているＮＡＬＵタイムでＮＡＬＵを集約する。ＮＡＬＵタイムスタンプオフセットの長さの点で異なる２つの異なるＭＴＡＰが規定されている。ＮＡＬＵタイムなる用語は、ＮＡＬＵがそれ自体のＲＴＰパケットで移送される場合にＲＴＰタイムスタンプが有する値として定義されている。

ＭＴＡＰ及びＳＴＡＰは、本発明の有利な実施形態による下記の限定されないパケット化ルールを共有する。ＲＴＰタイムスタンプを、集約されるすべてのＮＡＬＵのＮＡＬＵタイムの最小値に設定しなければならない。ＮＡＬＵタイプオクテットのタイプフィールドを、表１に示すような適切な値に設定しなければならない。集約されたＮＡＬＵのすべてのエラー表示子フィールドが零であれば、エラー表示子フィールド１１．１を消去しなければならず、そうでなければ、設定しなければならない。

集約パケットのＮＡＬＵペイロードは１つ以上の集約ユニットから成る。集約パケットは、必要な限り多くの集約ユニットを伝達できるが、集約パケットのデータの総量は、当然ＩＰパケットに合致しなければならなく、結果として生じたＩＰパケットがＭＴＵサイズよりも小さくなるようにサイズを選択しなければならない。

同一のＮＡＬＵタイムを共有するＮＡＬＵを集約するときはいつでもシングルタイム集約パケット（ＳＴＡＰ）を用いなければならない。ＳＴＡＰのＮＡＬＵペイロードは、ビデオシーケンスＩＤフィールド１２．１（例えば、７ビット）と、シングルピクチャ集約ユニット（ＳＰＡＵ）が後に続くフィールド表示子１２．２とから成る。

他の代替の実施形態では、シングルピクチャ集約パケット（ＳＴＡＰ）のＮＡＬＵペイロードは、シングルピクチャ集約ユニット（ＳＰＡＵ）が後に続く１６ビット符号なし復号化順序番号（ＤＯＮ）から成る。

この仕様に準じるビデオシーケンスを、ＮＡＬＵストリームの他の部分から独立して復号化できるＮＡＬＵストリームのいずれかの部分とすることができる。

フレームは、別々のピクチャとして符号化できる２つのフィールドから成る。１に等しい第１フィールド表示子は、同一フレームのうち復号化順序で第２の符号化フィールドに先行する符号化フィールドまたは符号化フレームにＮＡＬＵが属することを信号送信する。０に等しい第１フィールド表示子は、同一フレームのうち復号化順序で第１の符号化フィールドの後に続く符号化フィールドにＮＡＬＵが属することを信号送信する。

シングルピクチャ集約ユニットは、（２つのオクテットを除くが、ＮＡＬＵのＮＡＬＵタイプオクテットを含む）後に続くＮＡＬＵのサイズをバイトで示す例えば１６ビット符号なしサイズ情報から成り、この後には、ＮＡＬＵタイプバイトを含むＮＡＬＵ自体が続く。

マルチタイム集約パケット（ＭＴＡＰ）は、ＳＴＡＰと類似する構造を有する。マルチタイム集約パケット（ＭＴＡＰ）は、ＮＡＬＵヘッダバイト及び１つ以上のマルチピクチャ集約ユニットから成る。異なるＭＴＡＰフィールド間の選択は用途に依存する。すなわち、タイムスタンプオフセットが大きい程、ＭＴＡＰのフレキシビリティが高くなるが、オーバヘッドも大きくなる。

２つの異なるマルチタイム集約ユニットは、この仕様に規定されている。これら双方は、（ＳＴＡＰでのサイズ情報と同じ）後に続くＮＡＬＵの例えば１６ビット符号なしサイズ情報から成り、これら１６ビットに加えて、ビデオシーケンスＩＤフィールド１２．１（例えば、７ビット）と、フィールド表示子１２．２と、このＮＡＬＵに関するｎビットのタイミング情報をも含む。ここで、ｎを、例えば１６または２４とすることができる。ＭＴＡＰのＲＴＰタイムスタンプからのタイミング情報を加えることによりＭＴＡＰにおける各ＮＡＬＵのＲＴＰパケットのＲＴＰタイムスタンプ（ＮＡＬＵタイム）を生成できるようにタイミング情報フィールドを設定しなければならない。

他の代替の実施形態では、マルチタイム集約パケット（ＭＴＡＰ）は、ＮＡＬＵヘッダバイト、復号化順序番号ベース（ＤＯＮＢ）フィールド１２．１（例えば、１６ビット）及び１つ以上のマルチピクチャ集約ユニットから成る。この場合、２つの異なるマルチタイム集約ユニットは次の通りに規定される。これら双方は、（ＳＴＡＰでのサイズ情報と同じ）後に続くＮＡＬＵの例えば１６ビット符号なしサイズ情報から成り、これら１６ビットに加えて、復号化順序番号デルタ（ＤＯＮＤ）フィールド１２．５（例えば、７ビット）と、このＮＡＬＵに関するｎビットのタイミング情報をも含む。ここで、ｎを、例えば１６または２４とすることができる。後に続くＮＡＬＵのＤＯＮは、ＤＯＮＢ＋ＤＯＮＤに等しい。ＭＴＡＰのＲＴＰタイムスタンプからのタイミング情報を加えることによりＭＴＡＰにおける各ＮＡＬＵのＲＴＰパケットのＲＴＰタイムスタンプ（ＮＡＬＵタイム）を生成できるようにタイミング情報フィールドを設定しなければならない。ＤＯＮＢは、ＭＴＡＰのＮＡＬユニットのうちで最も小さいＤＯＮの値を含めるべきである。

本発明によるバッファリングモデルの動作は、次のパラメータすなわち初期入力期間（例えば、９０ｋＨｚクロックのクロックチック単位）及び仮想パケット入力バッファのサイズ（例えば、バイト単位）を用いて制御されるのが有利である。好ましくは、初期設定の初期入力期間及び仮想パケット入力バッファの初期設定サイズを０とする。ＰＳＳクライアントは、大きいバッファを機能交換過程で用いる機能を信号送信することができる。

最大ビデオビットレートを、例えば、ＳＤＰのメディアレベル帯域幅特性で、または、専用のＳＤＰパラメータで信号送信することができる。ビデオレベル帯域幅特性がプレゼンテーション記述に存在しなかったなら、最大ビデオビットレートは、使用されているビデオ符号化プロファイル及びレベルに従って規定される。

例えばＭＩＭＥタイプパラメータまたは類似の非規格ＳＤＰパラメータを用いて、各ストリームの初期パラメータ値をストリームのＳＤＰ記述に信号送信することができる。通知されたパラメータ値は対応の初期設定パラメータ値をオーバライドする。（一定遅延の信頼できる伝送チャネルを仮定すれば、）ＳＤＰ記述に信号送信された値はストリームの最初からストリームの最後まで一時停止なしの再生を保証する。

ＰＳＳサーバは、ＲＴＳＰ再生要求に応答してパラメータ値を更新することができる。更新されるパラメータ値が存在すれば、ＳＤＰ記述に信号送信された値、または、初期設定のパラメータ値をＰＳＳバッファリングモデルの動作中に置き換えなければならない。更新されるパラメータ値は、指示された再生範囲のみに有効であり、その後、何の効果もない。一定遅延の信頼できる伝送チャネルを仮定すれば、更新されるパラメータ値は、再生要求に応答して、指示された実際の範囲で一時停止なしの再生を保証する。指示された仮想入力パケットバッファのサイズ及び初期入力期間は、どちらも有効であるＳＤＰ記述での対応値または対応の初期設定値に等しいかそれ以下でなければならない。

サーババッファリングベリファイアは、指定のバッファリングモデルに従って指定される。このモデルは仮想パケット入力バッファに基づく。

バッファリングモデルを次に提示する。最初、バッファは空である。ＲＴＰパケットが伝送されるとすぐに、ＰＳＳサーバは、ビデオペイロードを有して各々伝送されたＲＴＰパケットを仮想パケット入力バッファ１．１に加える。ＲＴＰまたはあらゆる下位層のすべてのプロトコルヘッダが取り除かれる。初期入力期間と呼ばれている期間中、仮想パケット入力バッファからデータは取り出されない。第１ＲＴＰパケットが仮想パケット入力バッファに加えられたときに初期入力期間は開始する。初期入力期間が終了したとき、仮想パケット入力バッファからのデータの取り出しが開始される。仮想パケット入力バッファ１．１が空でない限り、データの取り出しは最大ビデオビットレートで起こるのが好ましい。仮想パケット入力バッファ１．１から取り出されたデータは仮想参照デコーダ５に入力される。仮想参照デコーダ５は、設定パラメータに従って符号化ビデオストリームを確実に復号化できるようにする仮想復号化処理を実行する。または、例えば、仮想参照デコーダ５のピクチャバッファ５．２がオーバフローしていることに仮想参照デコーダ５が気付けば、バッファパラメータを変更することができる。この場合、新しいパラメータも受信装置８に伝送され、これに応じてバッファは再初期化される。

ＰＳＳサーバのような符号化及び伝送装置１は、伝送されるＲＴＰパケットストリームが下記の要件に従うことを検証しなければならない。
− バッファリングモデルを初期設定パラメータ値で、または、信号送信されたバッファリングパラメータ値で用いるものとする。信号送信されたパラメータ値は対応の初期設定パラメータ値をオーバライドする。
− 仮想パケット入力バッファの占有値は、初期設定または信号送信されたバッファサイズを超えないものとする。
− 仮想パケット入力バッファの出力ビットストリームは仮想参照デコーダの規定に合致するものとする。

バッファリングモデルが用いられていれば、ＲＴＰパケットストリームが一定遅延の信頼できる伝送チャネルに伝達されるとき、ＰＳＳクライアントは、ＰＳＳサーババッファリングベリファイアに従うＲＴＰパケットストリームを受信できなければならない。更に、ＰＳＳクライアントのデコーダは、受信されたパケットストリームのＲＴＰタイムスタンプにより規定された正確なレートでフレームを出力しなければならない。

伝送

最初の符号化ピクチャが準備されると直ちに符号化ピクチャの伝送及び／または格納（及び随意の仮想復号化）を開始することができる。このピクチャは、デコーダ出力順序で最初のものとは限らない。その理由は、復号化順序及び出力順序が同じでない場合があるためである。

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

デコーダ２も、例えばピクチャオーダカウントの順序付けを用いることにより正確な順序で復号化ピクチャを出力すべきである。従って、再順序付け処理を明瞭にかつ標準的に規定する必要がある。

デパケット化

デパケット化処理は実装に依存する。従って、以下の説明は、適切な実装の非限定的な例である。他の方式も用いることができる。記載のアルゴリズムに関する最適化も可能である。

これらデパケット化ルールの背後にある一般概念は、ＮＡＬユニットを伝送順序からＮＡＬユニット配信順序に再順序付けすることにある。

復号化

次に、受信機８の動作を説明する。受信機８は、ピクチャに属するすべてのパケットを収集して、これらを適切な順序の状態にする。順序の正確性は、用いられるプロファイルに依存する。受信されたパケットは受信バッファ９．１（プリデコーディングバッファ）に格納される。受信機８は、使用できないものを廃棄し、残りの部分をデコーダ２に移す。集約パケットは、ＮＡＬＵを伝達する個々のＲＴＰパケットにペイロードをアップロードすることにより処理される。これらＮＡＬＵは、それらが別々のＲＴＰパケットで受信されたかのように、それらが集約パケットに配置された順序で処理される。

以後、Ｎは、パケットストリームにおいてＮＡＬユニット配信順序でいかなるＶＣＬ ＮＡＬユニットにも先行し、ＲＴＰシーケンス番号順序で、または、ＶＣＬ ＮＡＬユニットを含む集約パケットの生成順序でＶＣＬ ＮＡＬユニットの後に続くＶＣＬ ＮＡＬユニットの最大量を指定する随意のｎｕｍ‐ｒｅｏｒｄｅｒ‐ＶＣＬ‐ＮＡＬ‐ｕｎｉｔｓ ＭＩＭＥタイプのパラメータ値であるとする。パラメータが存在しなければ、０値の数であることを意味することができる。

ビデオストリーム転送セッションが初期化されるとき、受信機８は、少なくともＮ個のＶＣＬ ＮＡＬユニットを格納するため受信バッファ９．１にメモリを割り当てる。次に、受信機はビデオストリームを受信し始め、少なくともＮ個のＶＣＬ ＮＡＬユニットが受信バッファ９．１に格納されるまで、受信したＶＣＬ ＮＡＬユニットを受信バッファに格納する。

受信バッファ９．１が少なくともＮ個のＶＣＬ ＮＡＬユニットを含めば、ＮＡＬユニットは受信バッファ９．１から１つずつ取り出され、デコーダ２に移される。ＮＡＬユニットは、それらが格納された順序と同じ順序で受信バッファ９．１から取り出されるとは限らないが、下記に説明するようにＮＡＬユニットのビデオシーケンスＩＤに従って取り出される。バッファがＮ個のＶＣＬ ＮＡＬユニット未満すなわち（Ｎ−１）個のＶＣＬ ＮＡＬユニットを含むまでデコーダ２へのパケットの供給は継続する。

図１２では、デコーダのプリデコーダバッファにおける伝送ユニットのバッファリングの一例を表す。伝送ユニットが並ぶ順序が伝送順序（しかも、受信順序）を意味するが、数字は復号化順序を意味する。

以後、ＰＶＳＩＤは、デコーダに移された最後のＮＡＬユニットのビデオシーケンスＩＤ（ＶＳＩＤ）であるとする。ＳＴＡＰのすべてのＮＡＬユニットは、同一のＶＳＩＤを共有する。ＮＡＬユニットがデコーダに移される順序は次の通りに指定される。すなわち、バッファで最も古いＲＴＰシーケンス番号が単純パケットに対応すれば、単純パケットのＮＡＬＵは、ＮＡＬユニット配信順序で次のＮＡＬＵである。バッファで最も古いＲＴＰシーケンス番号が集約パケットに対応すれば、次の単純パケット（これを含まない）までＲＴＰシーケンス番号順序で集約パケットに運ばれたＮＡＬＵの間でＮＡＬユニット配信順序が回復される。この一連のＮＡＬＵは、以後、候補ＮＡＬＵと称する。単純パケットで運ばれたＮＡＬＵのいずれもバッファ内に存在しなければ、すべてのＮＡＬＵは候補ＮＡＬＵに属する。

候補ＮＡＬＵの各ＮＡＬユニットに対して、ＶＳＩＤ間隔は次の通りに計算される。ＮＡＬユニットのＶＳＩＤがＰＶＳＩＤよりも大きければ、ＶＳＩＤ間隔は、ＶＳＩＤ−ＰＶＳＩＤに等しい。そうでなければ、ＶＳＩＤ間隔は、２＾（ＶＳＩＤを信号送信するのに用いられたビット数）−ＰＶＳＩＤ＋ＶＳＩＤに等しい。ＮＡＬユニットはＶＳＩＤ間隔の昇順でデコーダに配信される。幾つかのＮＡＬユニットが同一のＶＳＩＤ間隔を共有すれば、これらをデコーダに移す順序は、この仕様に規定されたＮＡＬユニット配信順序に合致すべきである。下記に説明するようにＮＡＬユニット配信順序を回復することができる。

第１に、スライス及びデータパーティションは、フレーム番号、ＲＴＰタイムスタンプ及び第１フィールドフラグに従ってピクチャと関連付けられている。すなわち、同一値のフレーム番号、ＲＴＰタイムスタンプ及び第１フィールドフラグを共有するすべてのＮＡＬＵは、同一のピクチャに属する。ＳＥＩ ＮＡＬＵ、シーケンスパラメータセットＮＡＬＵ、ピクチャパラメータセットＮＡＬＵ、ピクチャ区切りＮＡＬＵ、シーケンス終了ＮＡＬＵ、ストリーム終了ＮＡＬＵ及びフィラーデータＮＡＬＵは、伝送順序で次のＶＣＬ ＮＡＬユニットのピクチャに属する。

第２に、ピクチャの配信順序は、各ピクチャのｎａｌ＿ｒｅｆ＿ｉｄｃ、フレーム番号、第１フィールドフラグ及びＲＴＰタイムスタンプに基づいて判断される。ピクチャの配信順序は、（モジュロ演算の）フレーム番号の昇順である。幾つかのピクチャが同一値のフレーム番号を共有すれば、０に等しいｎａｌ＿ｒｅｆ＿ｉｄｃを有する（複数の）ピクチャは最初に配信される。幾つかのピクチャが同一値のフレーム番号を共有し、それらすべてが、０に等しいｎａｌ＿ｒｅｆ＿ｉｄｃを有すれば、ピクチャは昇順のＲＴＰタイムスタンプ順序に配信される。２つのピクチャが同一のＲＴＰタイムスタンプを共有すれば、１に等しい第１フィールドフラグを有するピクチャは最初に配信される。留意すべきは、本明細書では、１次符号化ピクチャ及び対応の冗長符号化ピクチャが１つの符号化ピクチャと見なされるということである。

第３に、使用しているビデオデコーダが任意スライス順序をサポートしていなければ、スライス及びＡデータパーティションの配信順序は、スライスヘッダのｆｉｒｓｔ＿ｍｂ＿ｉｎ＿ｓｌｉｃｅ構文要素の昇順である。更に、Ｂ及びＣデータパーティションは、配信順序で対応のＡデータパーティションのすぐ後に続く。

上記では、ＰＶＳＩＤ及びＶＳＩＤなる用語が用いられた。その代わりに、ＰＤＯＮ（集約パケットのうちＮＡＬユニット配信順序で前のＮＡＬユニットの復号化順序番号）及びＤＯＮ（復号化順序番号）なる用語を次の通りに用いることができる。デコーダに移される最初のＮＡＬユニットのＰＤＯＮは０であるとする。ＮＡＬユニットがデコーダに移される順序は次の通りに指定される。すなわち、バッファ内で最も古いＲＴＰシーケンス番号が単純パケットに対応すれば、単純パケットのＮＡＬＵは、ＮＡＬユニット配信順序で次のＮＡＬＵである。バッファ内で最も古いＲＴＰシーケンス番号が集約パケットに対応すれば、次の単純パケット（これを含まない）までＲＴＰシーケンス番号順に集約パケットで運ばれたＮＡＬＵ間でＮＡＬユニット配信順序が回復される。この一連のＮＡＬＵを、以後、候補ＮＡＬＵと称する。単純パケットで運ばれたＮＡＬＵのいずれもバッファ内に存在しなければ、すべてのＮＡＬＵは候補ＮＡＬＵに属する。

候補ＮＡＬＵの各ＮＡＬユニットに対して、ＤＯＮ間隔は次の通りに計算される。ＮＡＬユニットのＤＯＮがＰＤＯＮよりも大きければ、ＤＯＮ間隔は、ＤＯＮ−ＰＤＯＮに等しい。そうでなければ、ＤＯＮ間隔は、２＾（符号なしの整数としてＤＯＮ及びＰＤＯＮを表すビット数）−ＰＤＯＮ＋ＤＯＮに等しい。ＮＡＬユニットはＤＯＮ間隔の昇順にデコーダに配信される。

幾つかのＮＡＬユニットが同一のＤＯＮ間隔を共有すれば、これらをデコーダに移す順序は、
１． ピクチャ区切りＮＡＬユニットがあるとすれば、ピクチャ区切りＮＡＬユニット
２． シーケンスパラメータセットＮＡＬユニットがあるとすれば、シーケンスパラメータセットＮＡＬユニット
３． ピクチャパラメータセットＮＡＬユニットがあるとすれば、ピクチャパラメータセットＮＡＬユニット
４． ｓＥＩ ＮＡＬＵがあるとすれば、ＳＥＩ ＮＡＬＵ
５． １次符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニットがあるとすれば、１次符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニット
６． 冗長符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニットがあるとすれば、冗長符号化ピクチャの符号化スライス及びスライスデータパーティションＮＡＬユニット
７． フィラーデータＮＡＬユニットがあるとすれば、フィラーデータＮＡＬユニット
８． シーケンス終了ＮＡＬユニットがあるとすれば、シーケンス終了ＮＡＬユニット
９． ストリーム終了ＮＡＬユニットがあるとすれば、ストリーム終了ＮＡＬユニット
である。

使用しているビデオデコーダが任意スライス順序をサポートしていなければ、スライス及びＡデータパーティションの配信順序は、スライスヘッダのｆｉｒｓｔ＿ｍｂ＿ｉｎ＿ｓｌｉｃｅ構文要素の昇順である。更に、Ｂ及びＣデータパーティションは、配信順序で対応のＡデータパーティションのすぐ後に続く。

動作可能なＪＶＴデパケッタイザを実装するのに下記の追加のデパケット化ルールを用いることができる。すなわち、ＮＡＬＵはＲＴＰシーケンス番号順でＪＶＴデコーダに与えられる。集約パケットに運ばれるＮＡＬＵはそれらの順序で集約パケットに与えられる。集約パケットのすべてのＮＡＬＵは、次のＲＴＰパケットが処理される前に処理される。

（例えば、ゲートウェイにおける）知的ＲＴＰ受信機は、損失したＤＰＡを識別することができる。損失したＤＰＡが検出されれば、ゲートウェイは、ＤＰＢ及びＤＰＣを送信しないと決定することができる。その理由は、それら情報がＪＶＴデコーダにとって意味のないものであるからである。このように、ネットワーク要素は、複雑なビットストリームを解析することなく、無駄なパケットを廃棄することによりネットワーク負荷を減少させることができる。

知的受信機は、０のＮＡＬ参照Ｉｄｃを有するすべてのパケットを廃棄することができる。しかし、パケットが廃棄されれば、ユーザが不快な体験をするおそれがあるので、可能であれば、知的受信機はこれらパケットを処理しなければならない。

ＤＰＢ２．１は、多くのピクチャを格納する記憶箇所を含む。本明細書では、これら箇所をフレームストアとも称する。デコーダ２は、受信したピクチャを正確な順序で復号化する。そうするため、デコーダは、受信したピクチャのビデオシーケンスＩＤ情報を検査する。エンコーダが各グループオブピクチャに対して自由にビデオシーケンスＩＤを選択していたら、デコーダはグループオブピクチャのピクチャを、それらが受信された順序で復号化する。エンコーダが、インクリメント（またはデクリメント）番号付け方式を用いることにより各グループオブピクチャに対してビデオシーケンスＩＤを規定していたら、デコーダはビデオシーケンスＩＤの順序でグループオブピクチャを復号化する。言い換えれば、最小（または最大）のビデオシーケンスＩＤを有するグループオブピクチャが最初に復号化される。

本発明を多くの種類のシステム及び装置に適用することができる。エンコーダ１を含み随意にＨＲＤ５を含むのが有利である伝送装置６は、符号化ピクチャを伝送チャネル４に伝送する送信機７をも含む。受信装置８は、符号化ピクチャを受信するための受信機９と、デコーダ２と、復号化ピクチャを表示できる表示装置１０とを含む。伝送チャネルを、例えば、有線通信チャネル及び／または無線通信チャネルとすることができる。伝送装置及び受信装置は、本発明によるビデオストリームの符号化／復号化処理を制御する必要なステップを実行できる１つ以上のプロセッサ１．２，２．２をも含む。従って、本発明による方法を主にプロセッサのマシン実行可能ステップとして実装することができる。ピクチャのバッファリングを装置のメモリ１．３，２．３に実装することができる。エンコーダのプログラムコード１．４をメモリ１．３に格納することができる。また、デコーダのプログラムコード２．４をメモリ２．３に格納することができる。

仮想参照デコーダ５をエンコーダ１の後に位置付けすることができ、これによって、仮想参照デコーダ５が必要に応じて符号化ピクチャを再配置し、受信機８のプリデコーディングバッファがオーバフローしないことを保証できること明らかである。

仮想参照デコーダ５の一部とすることができ、または、仮想参照デコーダ５から分離することができるバッファリングベリファイアに本発明を実装することができる。

Claims (15)

1. 符号化ピクチャをバッファリングする方法であって、符号化ピクチャをエンコーダにおいて形成する符号化ステップと、前記符号化ピクチャを伝送ユニットとしてデコーダに伝送する伝送ステップと、前記デコーダに伝送された伝送ユニットをバッファにバッファリングするバッファリングステップと、復号化ピクチャを形成するため、前記符号化ピクチャを復号化する復号化ステップとを含む方法において、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズが規定される方法。
2. 前記合計サイズの計算に用いられる伝送ユニット数が、前記伝送ユニット数に関して必要なバッファサイズの分数である、請求項１に記載の方法。
3. 前記合計サイズの計算に用いられる伝送ユニット数が、前記伝送ユニット数に関して必要なバッファサイズの分数であり、前記分数は１／Ｎの形態を持ち、ここで、Ｎは整数である、請求項１に記載の方法。
4. 前記合計サイズの計算に用いられる伝送ユニット数が、前記伝送ユニット数に関して必要なバッファサイズと同じである、請求項１に記載の方法。
5. 前記合計サイズの計算に用いられる伝送ユニット数が、前記伝送ユニットのバッファリング順序として表現される、請求項１に記載の方法。
6. ピクチャを符号化するエンコーダと、前記符号化されたピクチャをＶＣＬ ＮＡＬユニットとしてデコーダに伝送する送信機と、前記符号化されたピクチャを復号化して復号化ピクチャを形成するデコーダとを含むシステムであって、前記デコーダが、前記デコーダに伝送された伝送ユニットをバッファリングするバッファを含むシステムにおいて、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズを規定するデファイナを更に含むシステム。
7. ピクチャを符号化するエンコーダであって、バッファにバッファリングし復号化するために、前記符号化されたピクチャを伝送ユニットとしてデコーダに伝送する送信機を含むエンコーダにおいて、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズを規定するデファイナを更に含むエンコーダ。
8. 前記エンコーダが、前記符号化されたピクチャをバッファリングするバッファと、前記符号化されたピクチャを復号化するためのバッファリング要件を決定する仮想参照デコーダと含む、請求項７に記載のエンコーダ。
9. 復号化ピクチャを形成するため符号化ピクチャを復号化するデコーダであって、復号化のために、受信した符号化ピクチャをバッファリングするプリデコーディングバッファを含むデコーダにおいて、前記デコーダが、バッファサイズを示す受信パラメータに従って前記プリデコーディングバッファのためにメモリを割り当てるプロセッサを更に含み、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファサイズが規定されるデコーダ。
10. 符号化ピクチャをバッファリングする方法を実行するマシン実行可能ステップを含むソフトウェアプログラムであって、前記方法が、符号化ピクチャをエンコーダに形成する符号化ステップと、前記符号化ピクチャを伝送ユニットとしてデコーダに伝送する伝送ステップと、前記デコーダに伝送された伝送ユニットをバッファにバッファリングするバッファリングステップと、復号化ピクチャを形成するため、前記符号化ピクチャを復号化する復号化ステップとを含むソフトウェアプログラムにおいて、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズが規定されるソフトウェアプログラム。
11. 符号化ピクチャをバッファリングする方法を実行するマシン実行可能ステップを含むソフトウェアプログラムを格納する記憶媒体であって、前記方法が、符号化ピクチャをエンコーダに形成する符号化ステップと、前記符号化ピクチャを伝送ユニットとしてデコーダに伝送する伝送ステップと、前記デコーダに伝送された伝送ユニットをバッファにバッファリングするバッファリングステップと、復号化ピクチャを形成するため、前記符号化ピクチャを復号化する復号化ステップとを含む記憶媒体において、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズが規定される記憶媒体。
12. ピクチャを符号化するエンコーダと、バッファにバッファリングし復号化するために、前記符号化されたピクチャを伝送ユニットとしてデコーダに伝送する送信機とを含む電子装置において、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズを規定するデファイナを更に含む電子装置。
13. 伝送ユニットとして符号化ピクチャを含む信号であって、前記符号化ピクチャを復号化するためのバッファリング要件が決定される信号において、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるようにパラメータがバッファサイズを示し、前記パラメータが前記信号に添付される信号。
14. ピクチャを符号化するエンコーダであって、バッファにバッファリングし復号化するために、前記符号化されたピクチャを伝送ユニットとしてデコーダに伝送する送信機を含むエンコーダを有する伝送装置において、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファのサイズを規定するデファイナを更に含む伝送装置。
15. 復号化ピクチャを形成するため符号化ピクチャを復号化するデコーダであって、復号化のために、受信した符号化ピクチャをバッファリングするプリデコーディングバッファを含むデコーダを有する受信装置において、前記デコーダが、バッファサイズを示す受信パラメータに従って前記プリデコーディングバッファのためにメモリを割り当てるプロセッサを更に含み、少なくとも２つの伝送ユニットの合計サイズが規定され、前記合計サイズに基づいて最大バッファサイズが規定されるように、前記バッファサイズが規定される受信装置。

Images