(57)【特許請求の範囲】
【請求項１】
パケットベースの通信ネットワーク上の送信側エンドポイント又はサーバと、少なくとも1つの受信側エンドポイント又はサーバとの間のメディア通信のためのシステムであって、
送信されるメディアを、最下位の時間レイヤを含むいくつかの異なるレイヤを有するスレッド化コーディング構造に於けるピクチャとして符号化するように構成されるエンコーダを含み、
各ピクチャには、ピクチャインデックス番号が関連付けられ、
ピクチャのそれぞれに対応するデータは、１つ又は複数の個別データパケットに分割して送信されるように構成されており、
個別データパケットのそれぞれは、データ要素を含み、
前記データ要素は、最下位の時間レイヤの各ピクチャのそれぞれの個別データパケットに対しては、前記ピクチャを識別するピクチャインデックス番号を示し、
他の時間レイヤの各ピクチャの個別データパケットのそれぞれに対しては、復号順に於いて前記最下位の時間レイヤの最新のピクチャのピクチャインデックス番号を示し、
各ピクチャの個別データパケットのそれぞれに対しては、前記個別データパケットを識別するシーケンス番号と、前記個別データパケットがピクチャの最初のデータ部分又は最後のデータ部分を含むかどうかをそれぞれ示す‘開始’フラグ及び‘最終’フラグと、を示し、
前記少なくとも1つの受信側エンドポイント又はサーバは、
受信された個別データパケットのピクチャインデックス番号のリストを保持し、
個別データパケットのそれぞれの受信時に、前記個別データパケットの前記ピクチャインデックス番号と前記リストを比較することにより、前のピクチャの消失を検出し、
個別データパケットのそれぞれの受信時に、前記ピクチャインデックス番号に対応する受信された個別データパケットのシーケンス番号が欠落しているか否か、及び前記ピクチャインデックス番号に対応する最初のシーケンス番号を有する個別データパケットが開始フラグセットを有し、前記ピクチャインデックス番号に対応する最後のシーケンス番号を有する個別データパケットが最終フラグセットを有するかどうかを調べることによって、前記ピクチャインデックス番号に対応する最下位の時間レイヤのピクチャ部分の消失を検出する、
ように構成される、
システム。
【請求項２】
前記スレッド化コーディング構造は、さらに、空間レイヤと品質レイヤとを含み、
個別データパケットのそれぞれについての前記データ要素は、さらに、各空間レイヤ又は品質レイヤに関連付けられたシリーズ番号を示し、
前記少なくとも1つの受信側エンドポイント又はサーバは、さらに、前記シリーズ番号及びピクチャインデックス番号に対応するピクチャが受信されているかを判定することによって、特定の空間レイヤ又は品質レイヤに関連する最下位の時間レイヤのピクチャの消失を検出するように構成される、請求項１に記載のシステム。
【請求項３】
前記システムは、H.264に準拠するコーデックを含み、
前記最下位の時間レイヤのピクチャは、長期基準ピクチャとしてマークされているピクチャを含み、
前記デコーダによる、最下位の時間レイヤのピクチャに基づく、前記受信メディアの少なくとも一部の復号が、MMCOコマンドによって制御される、請求項１に記載のシステム。
【請求項４】
前記通信ネットワークは、インターネットプロトコルを使用し、
メディア転送は、実時間プロトコル(RTP)を使用して実行され、
前記データ要素は、前記パケットに最下位の時間レイヤフレーム又はフレームのフラグメントが存在することを示すデータを含む、請求項１に記載のシステム。
【請求項５】
前記少なくとも1つの受信側エンドポイント又はサーバは、前記少なくとも1つの受信側エンドポイント又はサーバによる最下位の時間レイヤのピクチャ又はそのようなピクチャの一部の消失の検出を受けて、前記送信側エンドポイント又はサーバに対して、否定応答メッセージを送る、請求項４に記載のシステム。
【請求項６】
前記送信側エンドポイント又はサーバは、前記否定応答メッセージを受信して、前記消失ピクチャ又はその一部を再送信する、請求項５に記載のシステム。
【請求項７】
前記エンコーダは、H.264SVCに準拠し、
前記データ要素は、SVC要素のためのNALユニットヘッダー拡張で搬送される、請求項１に記載のシステム。
【請求項８】
前記エンコーダは、H.264SVCに準拠し、
前記データ要素は、SEIメッセージで搬送される、請求項１に記載のシステム。
【請求項９】
パケットベースの通信ネットワーク上の送信側エンドポイント又はサーバと、少なくとも1つの受信側エンドポイント又はサーバとの間のメディア通信のための方法であって、
エンコーダは、送信されるメディアを、最下位の時間レイヤを含むいくつかの異なるレイヤを有するスレッド化コーディング構造に於けるピクチャとして符号化し、
ピクチャのそれぞれに対応するデータは、１つ又は複数の個別データパケットに分割して送信され、
個別データパケット毎に、データ要素を配置することを含み、
前記データ要素は、
最下位の時間レイヤの各ピクチャの個別データパケットのそれぞれに対しては、前記ピクチャを識別するピクチャインデックス番号を示し、
他の時間レイヤの各ピクチャの個別データパケットのそれぞれに対しては、復号順に於いて前記最下位の時間レイヤの最新のピクチャのピクチャインデックス番号を示し、
各ピクチャの個別データパケットのそれぞれに対しては、前記個別データパケットを識別するシーケンス番号と、前記個別データパケットがピクチャの最初のデータ部分又は最後のデータ部分を含むかどうかをそれぞれ示す‘開始’フラグ及び‘最終’フラグと、を示し、
前記少なくとも1つの受信側エンドポイント又はサーバは、
受信された個別データパケットのピクチャインデックス番号のリストを保持し、
個別データパケットのそれぞれの受信時に、前記個別データパケットの前記ピクチャインデックス番号と前記リストを比較することにより、前のピクチャの消失を検出し、
個別データパケットのそれぞれの受信時に、前記ピクチャインデックス番号に対応する受信された個別データパケットのシーケンス番号が欠落しているか否か、及び前記ピクチャインデックス番号に対応する最初のシーケンス番号を有する個別データパケットが開始フラグセットを有し、前記ピクチャインデックス番号に対応する最後のシーケンス番号を有する個別データパケットが最終フラグセットを有するかどうかを調べることによって、前記ピクチャインデックス番号に対応する最下位の時間レイヤのピクチャ部分の消失を検出する、
ように構成される、
方法。
【請求項１０】
前記スレッド化コーディング構造は、さらに、空間レイヤと品質レイヤとを含み、
個別データパケットのそれぞれについての前記データ要素は、さらに、各空間レイヤ又は品質レイヤに関連付けられたシリーズ番号を示し、
前記少なくとも1つの受信側エンドポイント又はサーバは、さらに、前記シリーズ番号及びピクチャインデックス番号に対応するピクチャが受信されているかを判定することによって、特定の空間レイヤ又は品質レイヤに関連する最下位の時間レイヤのピクチャの消失を検出するように構成される、請求項９に記載の方法。
【請求項１１】
前記送信されるメディアは、H.264に準拠するコーデックを使用してコーディングされ、
前記最下位の時間レイヤのピクチャは、長期基準ピクチャとしてマークされているピクチャを含み、
前記デコーダによる、最下位の時間レイヤのピクチャに基づく、前記受信メディアの少なくとも一部の復号が、MMCOコマンドによって制御される、請求項９に記載の方法。
【請求項１２】
前記通信ネットワークは、インターネットプロトコルを使用し、
メディア転送は、実時間プロトコル(RTP)を使用して実行され、
前記データ要素は、前記パケットに最下位の時間レイヤピクチャ又はピクチャのフラグメントが存在することを示すデータを含む、請求項９に記載の方法。
【請求項１３】
前記少なくとも1つの受信側エンドポイント又はサーバは、前記少なくとも1つの受信側エンドポイント又はサーバによる最下位の時間レイヤのピクチャ又はそのようなピクチャの一部の消失の検出を受けて、前記送信側エンドポイント又はサーバに対して、否定応答メッセージを送る、請求項１２に記載の方法。
【請求項１４】
前記否定応答メッセージを受信した前記送信側エンドポイント又はサーバは、前記消失ピクチャ又はその一部を再送信する、請求項１３に記載の方法。
【請求項１５】
前記エンコーダは、H.264SVCに準拠し、
前記データ要素は、SVC要素のためのNALユニットヘッダー拡張で搬送される、請求項１４に記載の方法。
【請求項１６】
前記エンコーダは、H.264SVCに準拠し、
前記データ要素は、SEIメッセージで搬送される、請求項９に記載の方法。
【請求項１７】
請求項９から１６の何れか１項に記載の方法を実行するようにプロセッサに指示するための命令一式を含むコンピュータ可読なメディア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はビデオデータ通信システムに関する。特に、本発明は、テレビ会議アプリケーションにおいてエラー耐性を提供する技術に関する。
本出願は、2007年１月９日出願の米国特許仮出願第60/884,148号の利益を主張する。さらに本出願は、国際特許出願第PCT/US06/028365号、第PCT/US06/028366号、第PCT/US06/061815号、第PCT/US06/062569号、第PCT/US07/080089号、第PCT/US07/062357号、第PCT/US07/065554号、第PCT/US07/065003号、第PCT/US06/028367号、第PCT/US07/063335号、第PCT/US07/081217号、第PCT/US07/080089号、第PCT/US07/083351号、第PCT/US07/086958号、および第PCT/US07/089076号に関連している。上記のすべての出願は、同一出願人によるものであるが、ここに参照により全体を組み込んだものとする。
【背景技術】
【０００２】
パケットベースの現代通信ネットワーク（例えば、インターネットプロトコル（IP）によるネットワーク）上の送信側と受信側間の高品質デジタルビデオ通信を提供することが、少なくとも、このようなネットワーク上のデータ転送が通常はベストエフォート・ベースで行われるために、技術的には課題となっている。現代通信ネットワークに於ける送受信エラーは概してパケットの消失として現われ、以前の通信システムに特徴的であったビットエラーとしては現われない。パケットの消失は、しばしば中継のルーターに於ける輻輳の結果であり、物理層のエラー結果ではない。
【０００３】
デジタルビデオ通信システムで送受信エラーが発生した場合、受信側がエラーから迅速に回復し、入力ビデオ信号のエラーのない表示に復帰することを保証することが重要である。しかし、典型的なデジタル通信システムに於いては、受信側の堅牢性は、帯域幅を節約するために入力データが大幅に圧縮されているために、低下している。さらに、通信システムで採用されているビデオ圧縮技術（例えば、最新のコーデックITU-T H.264とH.263，又はISO MPEG-2とMPEG-4コーデック）では、連続するビデオパケット又はフレーム間に強い時間依存性を作り出している可能性がある。特に、動き補償予測コーデックの使用（例えば、Ｐ又はＢフレームの使用を含む）は、表示フレームが過去のフレームに依存するというフレーム依存性の連鎖を作り出す。依存性の連鎖は、ビデオシーケンスの初めまでに亘っている可能性がある。依存性の連鎖の結果、特定パケットの消失は、受信側での多くの後続のパケットの復号に影響を与え得る。特定パケットの消失によるエラーの伝播は、「イントラ」(I)リフレッシュ・ポイント又は時間的予測を全く使用しないフレームに於いてのみ終結する。
【０００４】
デジタルビデオ通信システムに於けるエラー耐性は、送信される信号に於いて少なくともある程度の冗長性があることを必要とする。しかし、この要件は、送信信号に於ける冗長性を除去する又は最小限にすることを目指すビデオ圧縮技術の目標に反するものである。
【０００５】
差別化サービスを提供するネットワーク（例えば、DiffServ IPベースのネットワーク、専用回線のプライベート・ネットワークなど）上では、ビデオデータ通信アプリケーションは、ネットワーク機能を活用して、ビデオ信号データの一部又は全てを受信側に対して無損失に又は殆ど損失無しに配信することができる。差別化サービスに対する備えを持たない、任意のベストエフォート・ネットワーク（インターネットなど）に於いては、データ通信アプリケーションは、エラー耐性を達成するためには、自らの機能に頼る必要がある。テキスト又は英数字データ通信に於いて有用である既知の技術（例えば、伝送制御プロトコル- TCP）は、ビデオ又はオーディオ通信には適していない。これらの通信には、ヒューマンインタフェース要件から生じる低エンドツーエンド遅延という付加制約がある。例えば、TCP技術は、テキスト又は英数字データの転送に於けるエラー耐性のために使用してよい。TCPは、例え、数秒の遅延があったとしても、全てのデータが受信されたという確認があるまで、データを再送し続ける。しかし、TCPは、ライブ又は双方向のテレビ会議アプリケーションに於けるビデオデータの転送には、適さない。なぜなら、際限のないエンドツーエンド遅延は、参加者には、受け入れ難いものとなるからである。
【０００６】
ビデオ通信システムのエラー耐性の一態様は、ランダムアクセス（例えば、受信側が、ビデオ信号の現行の送信に参加する時）に関する。このアクセスは、圧縮効率に相当なインパクトを与える。ランダムアクセスの例は、たとえば、テレビ会議に参加するユーザ、又は放送にチャネルを合わせるユーザである。このようなユーザは、入力ビットストリーム信号上の適切なポイントを見つけて、復号を開始し、エンコーダに同期しなければならない。ランドムアクセス・ポイントでは、エラー伝播は終結するので、そのポイントは、事実上、エラー耐性の特徴点である（又はエラー回復ポイントである）。ランダムアクセスの良好なサポートを提供する特定のコーディング(coding)方式は、一般に、より高速なエラー回復を提供するエラー耐性技術を持つだろう。しかし、逆のことは、エラー耐性技術が対処するように設計されているエラーの持続期間と範囲についての具体的な仮定に依存する。エラー耐性技術は、エラー発生時、ある状態情報が受信側で利用できると仮定する場合がある。このような場合、エラー耐性技術は、ランダムアクセスの良好なサポートを保証しない。
【０００７】
デジタルテレビシステム（デジタルケーブルTV又は衛星TV）用のMPEG-2ビデオコーディクに於いては、Ｉピクチャが周期的な間隔（普通、0.5秒）で使用され、ストリームへの高速な切り替りを可能にしている。しかし、Ｉピクチャは、片われのＰ又はＢより相当大きく（通常、３〜６倍）、従って、特に小さい帯域幅及び／又は低遅延アプリケーションに於いては避けるべきである。
【０００８】
テレビ会議などの双方向アプリケーションでは、イントラ更新の要求という概念が、エラー耐性のためによく使用される。動作では、更新は、受信側から送信側に対してイントラピクチャの送信の要請を伴い、それによって、デコーダは、同期を取ることができる。この動作の帯域オーバヘッドは大きい。さらに、パケットエラーが発生した時も、このオーバヘッドを被る。パケットの消失が輻輳によって生じる場合、イントラピクチャの使用は、輻輳問題を悪化させるだけである。
【０００９】
エラーロバスト性の別の従来技術、これは、従来、IDCT実装に於けるミスマッチによるドリフトを緩和するために使用されているが（例えばH.261規格）、イントラモードで、各マクロブロックを周期的にコーディングするものである。H.261規格では、マクロブロックが１３２回送信される毎に、強制的なイントラコーディングが必要になる。
【００１０】
コーディング効率は、所定フレームに於いて、イントラとして強制的にコーディングされるマクロブロックの割合が増えるにつれて、減少する。逆に、この割合が低い場合、パケットの消失からの回復に要する時間は増加する。強制的イントラコーディングプロセスは、動きに関するドリフトを避けるために余分な配慮を必要とし、これがさらにエンコーダの性能を制限する。ある動きベクトル値は例え最も効果的であったとしても、避ける必要があるものがあるからである。
【００１１】
従来の単一レイヤコーデックのほかに、階層化又はスケーラブル・コーディングは、マルチメディアデータ符号化に於いて周知の技術である。スケーラブル・コーディングは、全体で所定のメディアをバンド幅効率よく表す２個以上の「スケールされた」ビットストリームを生成するのに用いられる。スケーラビリティは、いくつかの異なる次元で、即ち時間的、空間的、及び品質的（SNR「信号対雑音比」スケーラビリティと呼ばれる）に提供することができる。例えばビデオ信号は、CIFとQCIFの解像度で、かつ7.5、15、及び30のフレーム／秒（fps）のフレームレートで、異なるレイヤにおいてスケーラブルコーディングできる。コーデックの構造によるが、空間解像度とフレームレートの任意の組み合わせをコーデック・ビットストリームより得ることができる。異なるレイヤに対応するビットは、別々のビットストリーム（即ち、レイヤ当り１ビットストリーム）として送信してよく、または１つ又は複数のビットストリームに多重化してもよい。この明細書では、便宜上、特定のレイヤに対応するコーディングされたビットは、例え様々なレイヤが多重化して単一ストリームで送信されるとしても、そのレイヤのビットストリームと呼ぶ場合がある。スケーラビリティ機能を提供するように特に設計されたコーデックには、例えばMPEG-2（ISO/IEC 13818-2，又ITU-T H.262として知られている）及び現在開発中のH.264スケーラブルビデオコーディング拡張（ITU-T H.264 Annex G又はMPEG-4 Part10 SVCとして知られている）が含まれる。ビデオ通信用に特別に考案されたスケーラブルビデオコーディング（SVC）技術が、同一出願人による国際特許出願第PCT/US06/028365号「SYSTEM AND METHOD FOR SCALABLE AND LOW-DELAY VIDEOCONFERENCING USING SCALABLE VIDEO CODING」に説明されている。特にスケーラブルであるように設計されていないコーデックでも、時間の次元ではスケーラビリティ特性を持ち得ることに留意されたい。例えば、DVD及びデジタルTV環境で使用される、非スケーラブルコーデックであるMPEG-2 メインプロファイル・コーデックを考える。さらにコーデックは、30fpsで動かされ、IBBPBBPBBPBBPBB（周期N=15フレーム）というGOP構成が使用されると仮定する。Ｂピクチャを順に削除し、続いてＰピクチャを削除することによって、合計３個の時間解像度：30fps（すべてのピクチャタイプが含まれる）、10fps（ＩとＰのみ）、及び２fps（Ｉのみ）を得ることができる。この順次削除プロセスによって復号可能なビットストリームが得られる。なぜなら、MPEG-2 メインプロファイル・コーデックは、ＰピクチャのコーディングがＢピクチャに依存せず、同様にＩピクチャのコーディングが他のＰ又はＢピクチャに依存しないように、設計されているからである。以下では、時間スケーラビリティ機能をもつ単一レイヤのコーデックは、スケーラブルビデオコーディングの特別な場合と考え、従って、明確にそうでないと述べない限り、スケーラブルビデオコーディングという用語に含まれる。
【００１２】
スケーラブルコーデックは、通常は、ピラミッド・ビットストリーム構造を持っており、構成要素のビットストリームの１つ（「基本レイヤ」と呼ぶ）は、元のメディアをある基本品質で復元するのに不可欠である。１つ又は複数の残りのビットストリーム（「拡張レイヤ」と呼ばれる）は、基本レイヤと共に使用することによって、復元されるメディアの品質が向上する。拡張レイヤに於けるデータ損失は、容認できるが、基本レイヤに於けるデータ損失は、大幅な歪みを起こす又は復元されるメディアの完全な消失を招くことがある。
【００１３】
スケーラブルコーデックは、エラー耐性及びランダムアクセスに対して、単一レイヤコーデックが提起する課題と同様の課題をもたらす。しかし、スケーラブルコーデックのコーディング構造は、単一レイヤビデオコーデックにはない固有の特徴を持っている。さらに、単一レイヤコーディングと違って、スケーラブル・コーディングは、１つのスケーラビリティレイヤから別のレイヤへの切り替え（例えば、CIF解像度とQCIF解像度間の交互の切り替え）を含んでよい。
【００１４】
同時放送は、テレビ会議に対するコーディング解決策の１つであり、スケーラブルビデオコーディングより複雑ではないが、スケーラブルビデオコーディングの利点の一部を持っている。同時放送では、情報源の異なる２つのバージョンが符号化（例えば、２つの異なる空間解像度で）され、送信される。各バージョンは、その復号が他のバージョンの受信に依存しないという点で独立である。スケーラブル・コーディング及び単一レイヤコーディングと同様に、同時放送は、同様のランダムアクセス及び堅牢性の問題を提起する。以下では、同時放送は、スケーラブル・コーディングの特別な場合（レイヤ間の予測が行われない）と考え、明示しない限り、両方とも単にスケーラブルビデオコーディング技術と呼ぶ。
【００１５】
ビデオ通信システムに於けるエラー耐性及びランダムアクセスを提供する具体的技術が同一出願人による国際特許出願第PCT/US06/061815号「SYSTEMS AND METHODS FOR ERROR RESILIENCE AND RANDOM ACCESS IN VIDEO COMMUNICATIONS SYSTEMS」及び第PCT/US07/063335号「SYSTEM AND METHOD FOR PROVIDING ERROR RESILIENCE, RANDOM ACCESS, AND RATE CONTROL IN SCALABLE VIDEO COMMUNICATIONS」に記載されている。特に、これらの特許出願は、LRピクチャの概念を開示している。このピクチャは、スケーラブルにコーディングされたビデオ信号の（最も低い空間解像度又は品質解像度の）最下位の時間レイヤを構成し、送信側から受信側へ確実に伝送されるものである。LRピクチャの確実な送信は、受信側デコーダに於ける品質の最低水準を保証する。受信側は、例えば、「キーピクチャインデックス」方法を使って、LRピクチャが消失されたかを直ちに検出し、消失ピクチャの入手の対策を（例えば、送信側にその再送を要求することによって）行うことができる。その機構も国際特許出願第PCT/US06/061815号に開示されている。送信側と受信側は、必ずしもそれぞれエンコーダとデコーダである必要はなく、同一出願人による国際特許出願第PCT/US06/028366号に開示されているスケーラブルビデオ通信サーバ（SVCS）、同一出願人による国際特許出願第PCT/US06/62569号に開示されている複合SVCS（CSVCS）、又は同一出願人による国際特許出願第PCT/US07/80089号に開示されているマルチキャストSVCS（MSVCS）であってよいことに留意されたい。
【００１６】
最下位の時間レベルのピクチャが２個以上のパケットに亙って転送される場合、国際特許出願第PCT/US06/061815号に記載のシステム及び方法の潜在的限界が現われる。これは、例えば、高品位ビデオのコーディングに於いて各フレームが２個以上のトランスポート層パケットを使って転送される場合、又はピクチャが２個以上のスライスを使ってコーディングされ各スライスがそれぞれのパケットで転送される時、現われる可能性がある。これらの場合、同一フレームに属するパケットは、同じキーピクチャインデックスを持つことになる。ネットワークに於けるパケットの消失で、すべてのスライスが消失されるなら、受信側は、ピクチャ全体の消失を適切に検出し、是正処置を開始できる。しかし、スライスのわずか又はすべてが受信されると、受信側は、スライスデータの復号に進まない限り、受信スライスがピクチャ全体を含むかピクチャの一部しか含まないか直ちには察することはできない。この推測は、受信データを復号する受信側では容易であるが、通常、ビデオデータの復号を行うようになっていない中間の受信側（例えば、SVCS，CSVCS，又はMSVCS，或いはメディア認識ネットワーク要素(Media-Aware Network Element)−MANE）にとってはかなり複雑なものとなる。
【００１７】
これより、ビデオ通信システムに於いてコーディングされるビットストリームに対してエラー耐性の向上が検討される。エンドツーエンド遅延とシステムに使用される帯域幅に対して僅かな影響しか与えず、かつコーディングされるビデオデータの複数のスライスへの分断化の可能性に対処するエラー耐性技術の開発に注意を向ける。望ましいエラー耐性技術は、スケーラブルビデオコーディングと単一レイヤビデオコーディングに適用可能である。
【発明の概要】
【課題を解決するための手段】
【００１８】
本発明は、スケーラブルビデオコーディングのみならず単一レイヤコーディングに基づいて、ビデオ通信システムに於けるエラー耐性を強化するシステム及び方法を提供する。特に本発明は、受信側に対して、確実に送信されることを意図されたピクチャの一部が、パケットの消失が原因で消失されたか否かを検出し、最少遅延で是正処置が開始できる機構を提供する。具体的技術が、H.264 Annex G(SVC) NALユニットを使用する場合とRTPによる送信に対して提供される。
【図面の簡単な説明】
【００１９】
【図１】本発明の原理による、スケーラブルにコーディングされたビデオデータを配信する例示的テレビ会議システムを示すブロック図である。
【図２】本発明の原理による、単一レイヤビデオコーディングの使用に適合する例示的エンドユーザ端末を示すブロック図である。
【図３】本発明の原理による、スケーラブルコーディング又は同時放送コーディングの使用に適合する例示的エンドユーザ端末を示すブロック図である。
【図４】本発明の原理による、マルチポイントSVCSの内部スイッチング構造を示すブロック図である。
【図５】SVCSの動作原理を示すブロック図である。
【図６】本発明の原理による、例示的ビデオエンコーダの構造を示すブロック図である。
【図７】本発明の原理による、基本レイヤ及び時間拡張レイヤを符号化するビデオエンコーダの例示的アーキテクチャを示すブロック図である。
【図８】本発明の原理による、空間拡張レイヤ用ビデオエンコーダの例示的アーキテクチャを示すブロック図である。
【図９】本発明の原理による、例示的階層化ピクチャコーディング構造を示すブロック図である。
【図１０】本発明の原理による、別の例示的階層化ピクチャコーディング構造を示すブロック図である。
【図１１】本発明の原理による、時間及び空間スケーラビリティを含む例示的ピクチャコーディング構造を示すブロック図である。
【図１２】本発明の原理による、エラー耐性ビデオ通信に用いられる例示的階層化ピクチャコーディング構造を示すブロック図である。
【図１３】本発明の原理による、空間／品質スケーラビリティを有するエラー耐性ビデオ通信に用いられる例示的ピクチャコーディング構造を示すブロック図である。
【図１４】本発明の原理による、Ｒパケット技術がRTPによる送信に使用される場合の送信側端末のLRP(Snd)モジュールの例示的アーキテクチャを示すブロック図である。
【図１５】本発明の原理による、Ｒパケット技術がRTPによる送信に使用される場合の受信側端末のLRP(Rcv)モジュールの例示的アーキテクチャを示すブロック図である。
【図１６】本発明の原理による、Ｒパケット技術がRTPによる送信に使用される場合のサーバのLRP Snd及びRcvモジュールの例示的アーキテクチャを示すブロック図である。
【図１７】本発明の原理による、RTPパケット用名前付きRTP ヘッダー拡張の例示的構造を図示している。
【図１８】本発明の原理による、RNACKパケットのフィードバック制御情報フィールドの例示的構造を図示している。
【図１９】本発明の原理による、フレームインデックス及び開始／最終フラグを有する修正H.264 Annex G (SVC) NAL ヘッダー拡張シンタックスを図示している。
【００２０】
図面全体を通じて、同一の符号および文字は、そうではないと述べない限り、図示の実施形態の同じ特徴、要素、構成要素、または部分を示すのに使用されている。さらに、これから、図を参照して、本発明を詳細に説明するが、これは、例示的実施形態に関して行われる。
【発明を実施するための形態】
【００２１】
本発明は、ビデオ通信システムに於けるエラー耐性のある送信のシステム及び方法を提供する。その仕組みは、ビデオ通信システムで使用できる時間スケーラビリティを持つ単一レイヤ且つ同時放送コーディングのみならず、スケーラブルビデオコーディング技術にも適合する。
【００２２】
システム及び方法は、受信側への確実な配信又は保証付き配信のためにビデオ信号送信に於けるビデオフレーム又はピクチャのセットを指定することを含む。指定のビデオフレームセットの確実な配信は、セキュアリンク又は高信頼性リンクを使用することによって、又は再送信技術によって実現してよい。確実に配信されたビデオフレームは、エラー発生後の受信側を送信ビデオ信号に対して再同期するために、又はランダムアクセスのために、基準ピクチャとして使用される。
【００２３】
好適な実施形態に於ける例示的ビデオ通信システムは、パケットベースのネットワーク上で動作するマルチポイント・テレビ会議システム10としてよい（例えば図１を参照）。マルチポイント・テレビ会議システムは、ネットワーク上のエンドポイント（例えば、ユーザ1-kと1-m）間のスケーラブルなマルチレイヤ又は単一レイヤのビデオ通信を仲介する、任意選択のブリッジ120aと120b（例えばマルチポイント制御ユニット(MCU)又はスケーラブルビデオ通信サーバ(SVCS)）を含んでもよい。例示的ビデオ通信システムの動作は、任意選択のブリッジ120aと120bの使用を伴う、伴わないに関わらず同じであり、ポイントツーポイント接続に対して有利である。
【００２４】
スケーラブルビデオコーディング技術及び、スケーラブルビデオコーディングに基づくテレビ会議システムについての詳細な説明が、同一出願人による国際特許出願第PCT/US06/028365号「SYSTEM AND METHOD FOR SCALABLE AND LOW-DELAY VIDEOCONFERENCING USING SCALABLE VIDEO CODING」、第PCT/US06/028266号「SYSTEM AND METHOD FOR A CONFERENCE SERVER ARCHITECTURE FOR LOW DELAY AND DISTRIBUTED CONFERENCING APPLICATIONS」、第PCT/US06/062569号「SYSTEM AND METHOD FOR VIDEOCONFERENCING USING SCALABLE VIDEO CODING AND COMPOSITING SCALABLE VIDEO SERVERS」、及び第PCT/US07/80089号「SYSTEM AND METHOD FOR MULTIPOINT CONFERENCING WITH SCALABLE VIDEO CODING SERVERS AND MULTICAST」に与えられている。さらに、エラー耐性、ランダムアクセス、及びレート制御技術の説明が、同一出願人による国際特許出願第PCT/US06/061815号「SYSTEMS AND METHODS FOR ERROR RESILIENCE AND RANDOM ACCESS IN VIDEO COMMUNICATION SYSTEMS」及び第PCT/US07/063335号「SYSTEM AND METHOD FOR PROVIDING ERROR RESILIENCE, RANDOM ACCESS, AND RATE CONTROL IN SCALABLE VIDEO COMMUNICATIONS」に与えられている。上記国際特許出願の全ては、参照により全体としてここに組み込んだものとする。本発明のシステム及び方法は、国際特許出願第PCT/US06/061815号に記載のシステム及び方法を改良するものである。
【００２５】
図１は、テレビ会議システム10の概略構成を示している。テレビ会議システム10は、LAN1と２及びサーバ120aと120bを介してネットワーク100上で接続されている複数のエンドユーザ端末（例えば、ユーザ1-kと1-m）を含む。サーバは、従来のMCU、スケーラブルビデオ通信サーバ(SVCS)、複合スケーラブルビデオ通信サーバ(CSVCS)、又はマルチキャストスケーラブルビデオ通信サーバ(MSVCS)であってよい。後のサーバ達は、従来のMCUと同じ目的を有するが、複雑さが著しく低減され、機能が向上している（例えば、国際特許出願第PCT/US06/28366号を参照）。明細書の説明では、用語「サーバ」はSVCSタイプのものを総称的に示すのに使用される。
【００２６】
図２は、単一レイヤコーディングに基づくテレビ会議システム（例えば、システム100）とともに使用するために設計されているエンドユーザ端末140のアーキテクチャを示す。同様に図３は、マルチレイヤコーディングに基づくテレビ会議システム（例えば、システム10）とともに使用するために設計されているエンドユーザ端末140のアーキテクチャを示す。端末140は、ヒューマン・インターフェース入出力デバイス（例えば、カメラ210A、マイクロフォン210B、ビデオディスプレイ250C、スピーカ250D）と、入力及び出力信号のマルチプレクサユニット及びデマルチプレクサユニット（たとえば、パケットMUX 220AとパケットDMUX 220B）に結合された1つ又は複数のネットワークインターフェース制御カード(NIC)230とを含む。NIC 230は、イーサネット（登録商標）LANアダプタなどの標準ハードウェア構成要素、任意の他の適切なネットワークインターフェースデバイス、又はこれらの組合せとしてよい。
【００２７】
カメラ210A及びマイクロフォン210Bは、他の会議参加者に送信するために参加者ビデオ信号及び参加者オーディオ信号をそれぞれ取り込むように設計される。逆に、ビデオディスプレイ250C及びスピーカ250Dは、他の参加者から受信したビデオ信号及びオーディオ信号をそれぞれ表示および再生するように設計される。ビデオディスプレイ250Cは、参加者/端末140自身のビデオを任意選択で表示するように構成することもできる。カメラ210A及びマイクロフォン210Bの出力は、それぞれ、アナログーデジタル変換器210Eと210Fを介してビデオエンコーダ210G及びオーディオエンコーダ210Hに結合される。ビデオエンコーダ210G及びオーディオエンコーダ210Hは、電子通信ネットワーク上の信号送信に必要な帯域幅を削減するために、入力ビデオ及びオーディオデジタル信号を圧縮するように設計される。入力ビデオ信号は、ライブビデオ信号でよく、または事前記録し格納されたビデオ信号でよい。エンコーダは、信号の送信に必要な帯域幅を最小限に抑えるためにローカルデジタル信号を圧縮する。
【００２８】
本発明の例示的実施形態では、当技術分野で周知の適切な技術（例えば、G.711、G.729、G.729EV、MPEG-1など）を使用してオーディオ信号を符号化してよい。本発明の好ましい実施形態では、スケーラブルオーディオコーデックG.729EVがオーディオエンコーダ210Gで用いられオーディオ信号が符号化される。オーディオエンコーダ210Hの出力はマルチプレクサMUX220Aに送られ、NIC230を介してネットワーク100上を送信される。
【００２９】
パケットMUX220Aは、RTPプロトコルを使用して従来の多重化を実施してよい。パケットMUX220Aは、ネットワーク100で提供される関連するクオリティ・オブ・サービス(QoS)処理を実施してよい。端末140からのデータの各ストリームが、それ自体の仮想チャネル、またはIP用語では「ポート番号」で送信される。
【００３０】
図３は、スケーラブル又は同時放送のビデオコーディングが使用されるテレビ会議システムとともに使用するように構成されているエンドユーザ端末 140を示す。この場合は、ビデオエンコーダ 210Gは、複数の出力を持っている。図３は、例えば、２つのレイヤの出力を示しており、「基本」及び「拡張」と名前が付けられている。端末140の出力（即ち、単一レイヤ出力（図２）又は複数のレイヤ出力（図３））は、LRP処理モジュール270A経由でパケットMUX220Aに接続される。LRP処理モジュール270A（とモジュール270B）は、ビデオシーケンスヘッダーデータのような確実な送信を必要とする他の情報のみならず特別なタイプのフレーム（例えば、図１２と１３の「Ｒ」フレーム）の送信を処理することによって、エラー耐性通信(「エラー耐性LRP動作」)に合うように設計されている。ビデオエンコーダ210Gが複数の拡張レイヤ出力を生成する場合、図３に示されるのと同様に、それぞれをLRP処理モジュール270Aに接続することができる。同様に、この場合、LRP処理モジュール270Bを介してビデオデコーダ230Aに対して追加の拡張レイヤが提供される。あるいは、拡張レイヤ出力のうちの１つ又は複数を、LRP処理モジュール270Aを介さずにパケットMUX220Aに直接に接続してもよい。
【００３１】
端末140は、テレビ会議の端末140で見られ、又は聴かれる参加者に対してビデオ及びオーディオデコーダ230Aと230B 対１組みずつを用い、ビデオ及びオーディオデコーダ230Aと230B 対の組み一式で構成することができる。デコーダ230Aと230Bのいくつかの例が図２及び３に示されているが、デコーダ230Aと230Bの対１組を使用して、複数の参加者からの信号を順次処理することが可能であることが理解されよう。したがって、端末140は、デコーダ230Aと230Bの対１組み又は参加者数よりも少ない数の組で構成してもよい。
【００３２】
オーディオデコーダ230Bの出力はオーディオミキサ240に接続され、オーディオミキサ240は、デジタルーアナログ変換器(DA/C)250Aに接続され、デジタルーアナログ変換器(DA/C)250Aはスピーカ250Bを駆動する。オーディオミキサは、個々の信号を再生用の単一の出力信号に合成する。オーディオ信号が事前混合されて到来する場合、オーディオミキサ240は不要となり得る。同様に、ビデオデコーダ230Aの出力を、コンポジタ260を介してビデオディスプレイ250Cのフレームバッファ250B内で結合してよい。コンポジタ260は、各復号済みピクチャを出力ピクチャディスプレイの適切なエリアに配置するように設計される。例えば、ディスプレイが４つのより小さいエリアに分割される場合、コンポジタ260は、各ビデオデコーダ230Aからピクセルデータを取得し、（例えば右下のピクチャを埋めることによって）それを適切なフレームバッファ位置に配置する。二重バッファリング（例えばデコーダ230Aの出力で１回、フレームバッファ250Bで１回）を回避するために、デコーダ230Aの出力ピクセルの配置を駆動するアドレス発生器としてコンポジタ260を実現してよい。同様の効果のために、ディスプレイ250Cへの個々のビデオ出力の配置を最適化する他の技術も使用してよい。
【００３３】
例えば、H.264標準規格では、フレキシブルマクロブロック順序付け(FMO)方式を使用することにより、複数の参加者のビューを単一のコーディングされたピクチャに合成することが可能である。この方式では、各参加者が、コーディングされたイメージのスライスのうちの１つを含む、コーディングされたイメージの一部を占有する。概念的には、単一のデコーダを使用してすべての参加者信号を復号することができる。しかし、現実には、受信側/端末は、４つのより小さな独立にコーディングされたスライスを復号しなければならない。したがって、デコーダ230Aを持つ図２と３に示される端末140は、H.264規格のアプリケーションで使用してよい。スライスを転送するサーバはCSVCSであることに留意されたい。
【００３４】
端末140では、デマルチプレクサDMUX220BがNIC320からパケットを受信し、それを、図２および３に示されているように受信側LRPモジュール270Bを介して適切なデコーダユニット230Aにリダイレクトする。ビデオデコーダ230Aの入力にあるLRPモジュール270Bは、受信側終端でのエラー耐性LRPオペレーションを終了させる。
【００３５】
MCU又はSERVER CONTROLブロック280は、サーバ(SVCS/CSVCS)とエンドユーザ端末との間の対話を調整する。中間サーバのないポイントツーポイント通信システムでは、SERVER CONTROLブロックは不要である。同様に、非会議アプリケーションでは、受信側エンドユーザ端末では単一デコーダが必要なだけである。格納されたビデオに関係するアプリケーションでは（例えば事前記録され、事前にコーディングされた資料のブロードキャスト）、送信側エンドユーザ端末は、オーディオ及びビデオの符号化ブロックの機能全体、又はそれらのブロックに先行する端末ブロック（例えばカメラ、マイクロフォンなど）すべての機能全体を含まなくてよい。具体的には、以下で説明するビデオパケットの選択的送信に関係する部分のみを設ける必要がある。
【００３６】
端末140の様々な構成要素は、相互接続されている物理的に別々のソフトウェア及びハードウェア装置又はユニット（例えばパーソナルコンピュータとして一体化された）でよく、又はそれらの任意の組合せでよいことを理解されよう。
【００３７】
図４は、エラー耐性のある処理アプリケーションで使用される例示的SVCS 400の構造を示す。SVCS 400のコアは、可能な各送信元からのどのパケットがどの宛先に、どのチャネルを介して送信されるかを判定する交換機410である（例えばPCT/US06/028366を参照）。
【００３８】
例示的SVCS 400の動作原理は、図５を参照して理解することができる。この例での送信側端末またはエンドポイントのSVCエンコーダ 510が、いくつかの時間レイヤに加えて３つの空間レイヤを生成する（図示せず）。個々のコーディングされたビデオレイヤが、個々のパケットの中に入れて送信側エンドポイント（SVCエンコーダ）からSVCS 400に送信される。SVCS 400は、ネットワーク条件又はユーザ好みに応じて、図示される３つの受信側/デコーダ520のそれぞれにどのパケットを転送するかを判定する。図５に示される例では、SVCS 400は、第1及び第２空間レイヤのみをSVCデコーダ 520(0)に転送し、３つのすべての空間レイヤをSVCデコーダ 520(1)に転送し、第１（基本）レイヤのみをSVCデコーダ 520(2)に転送する。
【００３９】
再び図４を参照すると、PCT/US06/028366に記載されている交換機に加えて、SVCS 400は、交換機の入力と出力にそれぞれ配置されたLRPユニット470Aと470Bを含む。SVCS 400は、その着信交換機接続でエラー耐性LRP処理を終了させ、その発信交換機接続でエラー耐性LRP処理を開始するように構成される。SVCS 400を使用する本発明の実施例では、エラー耐性LRP処理は、ネットワーク上のエンドツーエンドで実施されず、それぞれの個々の接続セグメント（例えば送信側とSVCS、SVCSとSVCS、及びSVCSと受信側）上でのみ実施される。しかし、SVCSを使用して、又はSVCSを使用せずに、ネットワーク上エンドツーエンドで本発明のエラー耐性LRP処理を実行してよいことが理解されよう。SVCSが使用されるネットワークでのエンドツーエンドLRP処理のために、LRPユニット470Aと470Bを有しないSVCS 400を使用してよい。さらに、SVCS 400が様々なネットワークを介してユーザを接続する場合に一般的であるように、SVCS 400は、複数のNIC230を備えてよい。
【００４０】
図６は、エラー耐性のあるビデオ通信システムで使用することのできる例示的ビデオエンコーダ600のアーキテクチャを示す。ビデオエンコーダ600は、例えば、動き補償のブロックベースの変換コーダでよい。H.264設計はビデオエンコーダ600についての好ましい設計である。しかし、他のコーデック設計を使用してよい。例えば、図７は、SVC設計に基づいて基本レイヤ及び時間拡張レイヤを符号化する例示的ビデオエンコーダ600’のアーキテクチャを示し、図８は、空間拡張レイヤを符号化する例示的ビデオエンコーダ600”のアーキテクチャを示す（例えばPCT/US06/28365とPCT/US06/028366を参照）。ビデオエンコーダ600’と600”は、空間スケーラビリティを使用するシステムで入力解像度を低減する（例えばCIFからCIFに）のに使用することのできる任意選択の入力ダウンサンプラ640を含む。
【００４１】
図６は、ビデオエンコーダ600を使用して実施できるコーディングプロセスを示す。エンコーダ600内のENC REF CONTROL 620が、「スレッド化」コーディング構造を生成するのに使用される（例えば、PCT/US06/28365とPCT/US06/028366を参照）。標準のブロックベースの動き補償コーデックは、Ｉ、Ｐ、及びＢフレームの通常の構造を有する。例えば、IBBPBBPなどのピクチャシーケンス（表示順）では、‘Ｐ’フレームが前のＰ又はＩフレームから予測されるのに対して、Ｂピクチャは前と次のＰ又はＩフレームの両方を使用して予測される。Ｉピクチャが現れるレートが変化し得るのと同様に、連続するＩ又はＰピクチャ間のＢピクチャの数は、変化する可能性があるが、例えばＰピクチャが、最新のものよりも時間的に前の別のＰピクチャを予測のための基準として使用することは不可能である。H.264は、エンコーダ及びデコーダが２つの基準ピクチャリストを維持する点で例外である。基準のためにどのピクチャが使用されるか、さらに、コーディングされるべき特定のピクチャについてどの基準が使用されるかを選択することが可能である。図６のFRAME BUFFERSブロック610は基準ピクチャリストを格納するメモリを表すのに対して、ENC REF CONTROL 620は、現ピクチャに対してどの基準ピクチャを使用すべきかを、エンコーダ側で判定する。
【００４２】
例示的階層化ピクチャコーディング構造900を示す図９を参照すると、ENC REF CONTROL 620の動作をより良く理解することができる。複数の時間解像度を可能にするために、ビデオ通信システムで使用されるコーデックは、いくつかの別々のピクチャ「スレッド」を生成してよい。所与のレベルのスレッドが、同じスレッドからのピクチャ、又はより低いレベルのスレッドからのピクチャを使用して、動き補償される一連のピクチャとして定義される。任意の数のトップレベルスレッドを、残りのスレッドの復号プロセスに影響を与えることなく除外できるので、スレッドの使用により、時間スケーラビリティの実現が可能となる。
【００４３】
本発明の好ましい実施形態では、３つのスレッドからなる組を有するコーディング構造が使用される（例えば、図９の構造900）。図９では、ピクチャのラベル文字‘Ｌ’は任意のスケーラビリティレイヤを示す。Ｌの後に続く数字(０、１、及び２)は時間レイヤを特定し、例えば「０」が最下位の時間レイヤまたは最も粗い時間レイヤに対応し、「２」が最高位の時間レイヤまたは最も細かい時間レイヤに対応する。図９に示される矢印は、予測の方向、ソース、及びターゲットを示す。Ｂピクチャの使用によって、Ｂピクチャのために使用される基準ピクチャを取り込み、符号化するのにかかる時間だけコーディング遅延が増加するので、大部分のアプリケーションでは、Ｐピクチャのみが使用される。しかし、遅延に敏感ではないアプリケーションでは、L0ピクチャはあり得る例外として、ピクチャの一部又はすべてがBピクチャである可能性がある。同様に、L0ピクチャは、従来のGroup of Pictures(GOP)を形成するＩピクチャであってよい。
【００４４】
引き続き図９を参照するに、レイヤL0は単に、４ピクチャの間隔を空けて配置された一連の規則的Ｐピクチャである。レイヤL1は、L0と同じフレームレートを有するが、予測は、前のL0フレームのみから許される。レイヤL2フレームは、最新のL0又はL1フレームから予測される。L0は、全時間解像度のうちの1/4(1:4)を提供し、L1はL0フレームレートの２倍であり(1:2)、L2は、L0+L1フレームレートの２倍である(1:1)。
【００４５】
上記で論じた３つのL0、L1、及びL2レイヤより多いレイヤまたは少ないレイヤを、本発明の特定の実施の異なる帯域幅/スケーラビリティ要件に適合するように設計されたコーディング構造として同様に構築することができる。図１０は、２つのレイヤL0及びL1のみを有するスレッド化コーディング構造1000の一例を示す。さらに、図１１は、空間スケーラビリティに関するスレッド化コーディング構造1100の一例を示す。コーディング構造1100は拡張レイヤに関するスレッドを含み、それが文字‘Ｓ’で示される。拡張レイヤフレームが基本レイヤフレームとは異なるスレッド化構造を有してよいことに留意されたい。
【００４６】
時間レイヤを符号化するビデオエンコーダ600’（図７）を増強して、空間拡張レイヤ及び/又は品質拡張レイヤを符号化してもよい（例えば,PCT/US06/028365とPCT/US06/028366を参照）。図８は、空間拡張レイヤに関する例示的エンコーダ600”を示す。エンコーダ600”の構造及び機能は、基本レイヤ情報もエンコーダ600”にとって利用可能であることを除いて、基本レイヤコーデック600’のものと同様である。この情報は、動きベクトルデータ、マクロブロックモードデータ、コーディング予測誤差データ、又は再構成ピクセルデータからなってよい。エンコーダ600”は、拡張レイヤＳに関するコーディング判定を行うために、このデータの一部又はすべてを再利用することができる。データを拡張レイヤのターゲット解像度に対してスケーリングしなければならない（例えば、基本レイヤがQCIFであり、拡張レイヤがCIFである場合は２の倍数（factor of 2））。空間スケーラビリティは通常、２つのコーディングループを維持することを必要とするが、例えばH.264 Annex G (SVC)ドラフト標準では、拡張レイヤコーディングのために使用される基本レイヤのデータを、現ピクチャの基本レイヤに符号化された情報から計算可能である値のみに限定することによって、単一ループ復号を実施することが可能である。（例えば、T. Wiegand, G. Sullivan, J. Reichel, H. Schwarz, M. Wien, eds.,”Joint Draft 8 of SVC Amendment”,Joint Video Team, Doc. JVT-U201,  Hangzhou, October 2006を参照。本文献は、参照によりここに全体を組み込んだものとする。）例えば、基本レイヤ・マクロブロックがインターコーディングされる場合、拡張レイヤは、そのマクロブロックの再構成ピクセルを予測のための基礎として使用することができない。しかし、拡張レイヤは、その動きベクトル及び予測誤差値を使用することができる。それらは、現基本レイヤピクチャ内に含まれる情報を単に復号することによって得ることができるからである。単一ループ復号は、デコーダの複雑さが著しく低減されるので、望ましい。
【００４７】
空間スケーラビリティコーデックと同様に、品質又はSNRスケーラビリティ拡張レイヤコーデックを構成できる。品質スケーラビリティについては、入力のより高い解像度バージョン上に拡張レイヤを構築するのではなく、コーデックは、同じ空間解像度で残余予測誤差をコーディングする。空間スケーラビリティの場合と同じく、単一または２重ループコーディング構成に於いて、基本レイヤのすべてのマクロブロックデータを拡張レイヤで再利用することができる。話を簡潔にするために、本明細書での説明は一般に、空間スケーラビリティを使用する技術を対象とする。しかし、品質スケーラビリティに対して同一の技術が適用可能であることが理解されよう。
【００４８】
国際特許出願第PCT/US06/028365号は、送信エラーの存在に対する堅牢性に関してスレッド化コーディング構造（例えばコーディング構造900）が有する明確な利点を記載している。動き補償予測に基づく従来の最新ビデオコーデックには、時間的依存関係が内在している。所与のピクチャでのパケット消失は、その特定のピクチャの品質に影響を与えるだけでなく、その所与のピクチャが直接的または間接的に基準の役を果たすすべての将来のピクチャにも影響を与える。これは、デコーダが将来の予測のために構築することのできる基準フレームは、エンコーダで使用されるものとは同じではないからである。結果として生じる差、すなわちドリフトは、従来の最新ビデオコーデックによって生成される視覚的品質に大きな影響を与える可能性がある。
【００４９】
対照的に、図９に示されるスレッド化構造は、３つの自己完結したスレッドまたは依存関係の連鎖を作り出す。L2ピクチャについて生じるパケット消失は、L2ピクチャに影響を与えるだけであり、L0及びL1ピクチャは、なお復号し表示することができる。同様に、L1ピクチャで生じるパケット消失は、L1及びL2ピクチャに影響を与えるだけであり、L0ピクチャは、なお復号し表示することができる。さらに、Ｓピクチャに関するスレッドまたは依存関係の連鎖を含むようにスレッド化構造を作成することができる（例えば図１１を参照）。図１１に示される例示的Ｓパケットスレッド化構造1100は、図９に示されるＬピクチャスレッド化構造900と同様の特性を有する。S2ピクチャで生じる消失は、その特定のピクチャに影響を与えるだけであるのに対して、S1ピクチャで生じる消失は、続くS2ピクチャにも影響を与える。どちらの場合にも、ドリフトは、次のS0ピクチャの復号時に終了する。
【００５０】
図９を新たに参照すると、L0ピクチャで生じるパケット消失は、すべてのピクチャタイプが影響を受けるので、ピクチャ品質に関して壊滅的となる可能性がある。上述のように、この問題に対する従来の解決策は、L0ピクチャをイントラピクチャすなわちＩピクチャとして周期的にコーディングすることである。しかし、Ｉピクチャは一般にＰピクチャよりも３〜６倍大きいので、この解決策を実現するための帯域幅オーバヘッドはかなりのものとなる可能性がある。さらに、Ｉピクチャを使用する必要が生じるパケット消失は、ネットワーク輻輳の結果である場合が多い。パケット消失を改善するためにネットワークを介してＩピクチャを送る試みは、輻輳問題を悪化させるだけである。
【００５１】
基本レイヤL0及びいくつかの拡張レイヤピクチャが、その配信を保証する方法で送信される場合、パケット消失の場合の壊滅的な結果を伴うことなく、残りのレイヤをベストエフォート・ベースで送信することができる。そのような保証された送信は、DiffServ、FECなどの周知の技術を使用して行ってよい。本明細書の説明では、高信頼性チャネル（HRC）及び低信頼性チャネル(LRC)を、そのような差異化サービス品質（図１）を提供する２つの実際のチャネルまたは仮想チャネルとして参照することもある（例えば、PCT/US06/028365とPCT/US06/028366を参照）。スケーラブルビデオコーディング構造を使用するビデオ通信システム（例えば、図１１の構造1100）では、例えば、レイヤL0〜L2及びS0をHRC上で確実に送信し、S1及びS2はLRC上で送信してよい。S1又はS2パケットの消失は限定されたドリフトを引き起こすが、情報の損失を可能な限り隠すことができることがやはり望ましい。
【００５２】
国際特許出願第PCT/US06/061815号に記載されているエラー耐性技術は、L0レイヤのサブセットまたはL0レイヤ全体の確実な送信を利用することによって、パケット消失を補償する従来技術の上述の制限を克服する。エラー耐性又は信頼性が再送信によって保証される。これらのエラー耐性技術は、表示のために消失ピクチャを単に回復するだけでなく、消失パケットに（全体または一部が）含まれていたピクチャに依存する将来のピクチャの復号のための正しい基準ピクチャを作成するように設計される。本発明は、ピクチャが複数のトランスポートレイヤ（例えば、RTP）パケット上で送信される場合に、再送信の適切な動作を保証することによってこれらの技術を改良する。本発明のシステム実装では、適切な保護プロトコルによる送信側と受信側との間の肯定応答または否定応答を使用するLRPモジュール（例えば、図２のモジュール270Aと270B、及び図４のモジュール470Aと470B）によってL0ピクチャの確実な送信を行うことができる。
【００５３】
図１２は、一の例示的ピクチャコーディング構造1200を示しており（これは、また国際特許出願第PCT/US06/061815号に説明されている）、エラー耐性のあるビデオ通信のために、L0基本及びL1〜L2時間拡張レイヤが少なくとも１つの確実に送信される基本レイヤピクチャと連結されている。コーディング構造1200では、L0〜L2ピクチャと呼ばれる従来の基本及び拡張ピクチャタイプに加えて、LR（‘Ｒ’は高信頼性を表す）と呼ばれる新しいピクチャタイプがある。図１２に示されるコーディング構造1200では、LRピクチャは常にコーディングされたビデオ信号の最下位の時間レイヤであるので、レイヤLR及びL0〜L2は、それぞれL0〜L3と等価的に分類（label）ことができたものである。エラー耐性のあるビデオ通信のための本発明によれば、LRピクチャは、Ｐピクチャでよく、受信側宛先に確実に配信されるように指定される。
【００５４】
L0ピクチャのうちの１つがパケット消失のために損傷を受け、又は消失する一例を考慮することにより、本発明のエラー耐性のある技術の作用を理解することができる。前述のように、従来の通信システムでは、L0ピクチャの消失の影響は、すべての後続のL0〜L2ピクチャに対して重大である。本発明のピクチャコーディング構造1200では、消失したL0ピクチャの後の次の「確実に配信される」LRピクチャが再同期ポイントを提供し、その再同期ポイントの後、受信側/デコーダは、ひずみなしに復号し表示を続行することができる。
【００５５】
図１２に示されるコーディング構造1200では、LRピクチャ間の時間間隔は、例えば12フレームである。LRピクチャの確実な配信には、非常に長い時間間隔（６フレーム以上）を有するＰピクチャがＩピクチャのサイズの約半分であり、確実な配信は、関連するピクチャの適時な表示を保証することを目的としておらず、将来使用するための適切な基準ピクチャの作成を目的としていることを利用する。結果として、連続するLRピクチャ間の期間に於けるシステムの非常にわずかな帯域幅の増加で、LRピクチャの配信を遂行することができる。
【００５６】
コーディング構造1200は、既存のH.264標準規格を用いて実現することができ、その標準規格の下では、LRピクチャを例えばデコーダに長期基準ピクチャとして格納して、MMCOコマンドを使用して置き換えることができる。
【００５７】
図１３は、一の例示的ピクチャコーディング構造1300を示し、そこでは、LRピクチャ概念が拡張レイヤピクチャ（空間か品質のいずれかのスケーラビリティ）に適用されている。ここでは、確実に送信すべきピクチャは、SRと分類（label）され、LRピクチャの場合と同じく、空間又は品質拡張レイヤの最下位の時間レイヤを構成する。
【００５８】
本明細書では、例示のために、LRピクチャ概念が一般に、コーディングされたビデオ信号の最下位の時間レイヤに適用されるものとして説明されるが、本発明の原理に従って、この概念を拡張して追加のレイヤに適用してよいことも留意されたい。この拡張適用の結果、追加のピクチャが確実に転送されることになる。例えば、図１２を参照すると、LRピクチャに加えて、L0ピクチャも確実な(再)送信の仕組み内に含めることができる。同様に、（最下位の時間レイヤまたは追加の時間レイヤからの）任意の空間／品質の拡張レイヤのピクチャを含めることができる。さらに、ビデオシーケンスヘッダーまたは他のデータをシステムのLRピクチャと同等に扱い、又は同等と見なしてよく、それによって、それら（ヘッダーまたは他のデータ）が確実に送信される。以下では、話を簡単にするために、明示的な指定がない限り、LRピクチャのみが確実に送信されると仮定する。しかし、追加のレイヤ又はデータをまったく同様に確実に送信することができることが容易に理解されよう。
【００５９】
パケット消失がないとき、LRフレームの確実な配信のための帯域幅オーバヘッドはゼロか、又は無視できることが望ましい。このことは、確実な配信方法に対して動的なクローズドループ・アルゴリズムが使用されるべきであることを示唆している。例えばLRフレームが事前に何回か再送信される場合、オープンループ・アルゴリズムを使用することも可能である。
【００６０】
国際特許出願第PCT/US06/061825号には、特定のLRピクチャが所望の受信側によって受け取られたことを送信側（例えば、SENDER, SVCS1, 又はSVCS2）に通知する幾つかの方法と、LRピクチャを動的に設定する技術が記載されている。RTCP又は他のフィードバック方法を使用して、特定の受信側がパケットの消失を受けていることを、例えば上述の肯定及び否定応答技法を使用して送信側に通知することができる。フィードバックは、個々のパケットについての個々のACK/NACKメッセージと同程度にきめ細かくてよい。フィードバックの使用により、エンコーダがデコーダの状態を（正確に又は近似的に）予測し、それに応じて動作することが可能となる。このフィードバックは、信頼性及びランダムアクセス制御(RRC)モジュール530（図６）で作成され収集される。
【００６１】
これらの送信側への通知方法の重要な特徴は、受信側(受信側エンドポイント又はSVCS)がLRピクチャの消失を最少遅延で検出する技術である。上記の特許出願で使用されている技術は、LRピクチャ番号及びピクチャ番号参照に依拠している。
【００６２】
このLRピクチャ番号技法は、LRピクチャに連続番号を割り振ることによって機能し、その番号は、LRピクチャパケットと共に搬送される。受信側は、受信したLRピクチャの番号のリストを維持する。一方、非LRピクチャは、復号順に於ける最新のLRピクチャのシーケンス番号を含む。このシーケンス番号を参照することにより、受信側は、消失LRピクチャを、後続のLRピクチャの受信前であっても検出することが可能となる。受信側は、LRピクチャを受信すると、受信LRピクチャのピクチャ番号を、受信側が保持するピクチャ番号のリストと比較することにより、前のLRピクチャのうちの１つ又は複数を消失したかどうか（即ち、受信しなかったか）を検出することができる。受信したLRピクチャのピクチャ番号は前のピクチャの番号より1つ大きいはずであり、カウントが再スタートした場合、０であるはずである。受信側が非LRピクチャを受信したとき、受信側は、その参照LRピクチャ番号が受信側の番号リスト内にあるかどうかを確認するために調べる。参照LRピクチャ番号が番号リスト内に存在しない場合、参照されているLRピクチャは消失したと想定され、是正処置を開始することができる(例えば、NACKメッセージが送信側に送り返される)。LRピクチャ番号技法の使用による消失LRピクチャの検出は、受信側エンドポイントと中間SVCSの両方で実施できることに留意されたい。この操作は、例えば、図２と３のLRP(Rcv)モジュール270B、又は図４の470Bで行われる。
【００６３】
１個のLRピクチャが２個以上のパケットを用いて転送される時、ピクチャ番号技法の潜在的限界が現われる。このような転送は、例えば、符号化が複数のスライスを使って行われる場合、発生してよいが、所与のピクチャのコーディングされたビットが最大のトランスポートレイヤ・パケットサイズを超える時はいつでも発生し得る。１個のピクチャを転送するのに複数のパケットが使用される場合、それらのパケットは同一のピクチャに属するので、パケットすべては、同じピクチャインデックス値を有することになる。このようなパケットすべてが送信中に消失されるなら、受信側は、ピクチャデータを次に無事に受信した時に消失を正しく検出できる。しかし、ピクチャの一部のパケットだけが失われる（しかし、パケットのいくらかは受信される）一部のデータの受信の場合、受信側は、データを調べて、ピクチャに含まれるすべてのマクロブロックが受信したデータに含まれているか判定しない限り、消失を検出できないだろう。この判定には、受信側がコーディングされたビデオデータを解析する必要があり、計算負荷の重い仕事である。H.264又はH.264 SVCの場合、例えば、スライス一式が１個のパケット全体のデータを含んでいるか判定することは、スライスヘッダー全体の解析を必要とする。解析操作は、デコーダを備える受信側に於いては、実行できる。しかし、受信側がSVCS又は他のタイプのMANEの場合、これは当てはまらない。
【００６４】
一部のデータの受信の場合に於けるエラー耐性に対応するためには、受信側は、すべてのパケットに付随するシーケンス番号（例えば、トランスポートプロトコルとしてRTPが使用される好適な実施形態に於けるRTPシーケンス番号）を使用して、パケットの消失を検出できることに留意されたい。１個のLRピクチャの連続するパケットは、連続するRTPシーケンス番号を含むことになる。部分データが受信された場合、受信側は、受信したRTPシーケンス番号の間の欠落から消失したデータがあることが判るが、消失データがLRピクチャの部分に対応するものか後続のピクチャのデータに対応するものか判定することはできない。従って、RTPシーケンス番号だけからでは、受信データがLRピクチャ全体を含んでいるかどうか検出することはできない。受信側が、ピクチャ全体の受信を検出できるように、本発明は、２つのフラグ、開始ビットフラグと最終ビットフラグを導入する。これらは、それぞれ、１つのLRピクチャのデータを含む最初と最後のパケットを示す。
【００６５】
LRピクチャのパケットを受信すると、受信側は、そのRTPシーケンス番号を調べ、同じピクチャインデック値を持ち‘開始’ビットがセットされているパケットに達するまで、連続してより小さいRTPシーケンス番号を持つすべての先行パケットを受信したかをチェックできる。同様に、同じピクチャインデックス値を持ち‘最終’ビットがセットされているパケットに達するまで、連続して大きいRTPシーケンス番号を持つ連続するパケットが受信されているかのチェックし続けることができる。この変更により、フレームインデックスを使用して、データが全く受信されない場合と一部のデータが受信される場合の両方に於いて、最下位の時間レベルのピクチャの消失を検出することができる。
【００６６】
２つのフラグを、最下位の時間レベルより高位の時間レベルに導入し、より高位の時間レベルに属するピクチャに対する完全性の検出を可能としてもよい。RTPシーケンス番号と合わせて、これによって、受信側は、時間レベルに関わらず、特定のピクチャの必要なすべてのデータを受信したかを迅速に判定することが可能になる。
【００６７】
RTPマーカビットは、ビデオ転送で用いる、「ピクチャの最後のパケット」という通常の定義付けを有していることに留意されたい。‘最終’フラグの代わりに、RTPマーカビットの使用を考慮してもよい。しかし、SVCのコンテクストでは、RTPマーカビットのそのような使用は、本発明が扱う課題を解決するのには十分ではない。１つのピクチャは、幾つかの‘ピクチャ’（基本レイヤと拡張レイヤ）を含んでよいからである。さらに、このような変更は、RTPマーカビットの通常の解釈を既に利用している既存のRTPシステムに於いて、問題を引き起こすだろう。
【００６８】
改良されたLRピクチャ番号付け技術の２つの異なる実施形態についてここで説明する。一の実施形態（以後‘Ｒパケット’技法と呼ぶ）は、送信のためにRTPプロトコルがシステムで使用されるときに適切である。他の実施形態は、システムに対してH.264 SVCドラフト標準規格が使用されるときに適用可能である。
【００６９】
Ｒパケット技法に関し、恐らくは１つ又は複数の中間サーバを介する２つの端末間の通信のために、(UDPとIP上の)RTPプロトコルが使用されることを仮定する。メディア送信側端末は、リアルタイム符号化を行う、又はローカルストレージまたは他のストレージ(RAM、ハードディスク、記憶域ネットワーク、ファイルサーバなど)のメディアデータにアクセスすることができることとする。同様に、受信側端末はリアルタイム復号を行い、受信データを将来の再生のためにローカルストレージ又は他のストレージに、あるいはその両方に格納していてよい。本明細書の説明では、限定はしないが、リアルタイム符号化及び復号が行われていると仮定する。
【００７０】
図１４は、送信側端末のLRP Sndモジュール(例えば、図２のモジュール270A)のアーキテクチャを示す。LRP Sndモジュールは、再送信を必要とする可能性のあるパケットのためにローカルストレージ（例えば、バッファ1605）を有するパケットプロセッサ(Ｒパケットコントローラ 1610)を含む。Ｒパケットコントローラ 1610はＲパケットをマークし、さらにはRNACKに応答する。Ｒパケットコントローラは、RTP/UDP/IPプロトコルスタックを実装するマルチプレクサMUX1620及びデマルチプレクサDMUX1630に接続されている。図１４ではMUX1620及びDMUX1630が別々の実体として示されているが、これらを同一ユニットに一体化してよい。MUX1620及びDMUX1630は、物理層インターフェースを提供する１つ又は複数のネットワークインターフェースコントローラ(NIC)に接続される。好ましい実施形態では、NICはイーサネット（登録商標）アダプタであるが、当業者には明らかであろうが、他のどんなNICも使用してよい。
【００７１】
同様に、図１５は、受信側端末のLRP Rcvモジュール（例えば、図２のモジュール270B）の例示的アーキテクチャを示す。ここでは、Ｒパケットコントローラ（例えば、コントローラ1610'）は、パケット消失の検出と、適切なNACKメッセージの作成の任を担う。さらに、図１６は、サーバのLRP Snd及びRcvモジュール（例えば、図４のモジュール470Aと470B）の構造を示し、サーバのLRP Snd及びRcvモジュールは、背中合わせに接続された、受信側端末の構成要素及び送信側端末の構成要素と同じでよい。
【００７２】
好ましい実施形態では、送信側端末は、RTP仕様に従ってメディアデータをパケット化する。RTPに対して様々なパケット化(「ペイロード」と呼ばれる)フォーマットが定義されるが、それらは同じの共通ヘッダーを持つことに留意されたい。本発明は、Ｒパケットを適切に処理することができるように、RTPパケットに対して名前付きヘッダー拡張方法(Singer,D., “A general mechanism for RTP Header Extensions”, draft-ietf-avt-rtp-hdrext-01（work in progress）, February 2006を参照)を導入する。
【００７３】
本発明によれば、Ｒパケットを含むRTPセッションでは、個々のパケットは、名前付きヘッダー拡張方法を用いてマークされる。Ｒパケットヘッダー拡張要素は、Ｒパケット自体と、以前に送られたＲパケットの両方を識別する。このヘッダー拡張要素は、「com.layeredmedia.avt.r-packet/200606」という名前を有する。あらゆるＲパケットは、この形態のヘッダー拡張要素を含み、あらゆる非Ｒパケットはこの形態のヘッダー拡張要素を含むべきである。
【００７４】
図１７は、本発明の名前付きヘッダー拡張の例示的データフィールドのフォーマットを示し、その中のフィールドは以下のように定義される。
【００７５】
ID:４ビット
例えばSinger,D., “A general mechanism for RTP Header Extensions”, draft-ietf-avt-rtp-hdrext-01(work in progress), February 2006で定義された、このヘッダー拡張要素に対して取り決められたローカル識別子。
【００７６】
長さ(len):４ビット
ヘッダーバイト(IDとlen)をカウントしない、このヘッダー拡張要素のデータバイトの長さから１を引いたもの。これは、第２のワード(置換範囲)が存在する場合に値６を有し、第２ワードが存在しない場合に２を有する。したがって、この値は２又は６でなければならない。
【００７７】
Ｒ:１ビット
このヘッダー拡張要素を含むパケットがＲシーケンス番号RSEQを有する系列SER中の１つのＲパケットであることを示すビット。このビットがセットされていない場合、その代わりに、ヘッダー拡張要素は、メディアストリームの系列SER中の最新のＲパケットがＲシーケンス番号RSEQを有していたことを示す。このビットがセットされていない場合、置換範囲が存在すべきではなく(すなわち、lenフィールドは２であるべきである)、存在する場合、無視されなければならない。
【００７８】
予約済み、ゼロでなければならない(0):１ビット
予約済みビット。これは送信時にゼロにセットされなければならず、受信時には無視される。
【００７９】
開始（Ｓ）：１ビット
パケットが特定のピクチャのデータを含む最初のパケットの場合、これは、１に設定されなければならない。
【００８０】
最終（Ｅ）：１ビット
パケットが特定のピクチャのデータを含む最後のパケットの場合、これは、１に設定されなければならない。
【００８１】
系列ID(SER):４ビット
このヘッダー拡張要素で記述されているＲパケットの系列の識別子。メディアエンコーダが単一の系列のＲパケットを記述している場合、これは値０を持つべきである。例えば、図１３に示されるスケーラブルビデオピクチャコーディング構造を使用して、Ｌパケット(基本空間拡張レイヤ、全スレッド)では、SERは、例えば０にセットされ、Ｓパケット(空間拡張レイヤ、全スレッド)では、SERは１にセットされることになる。
【００８２】
Ｒパケットシーケンス番号(RSEQ):16ビット
系列SER内のこのＲパケットの番号を示す符号なしシーケンス番号。この値は、所与の系列で送られるＲパケット毎に２16を法として１だけ増分される。個々の系列についてのRSEQ値は独立である。
【００８３】
置換範囲の開始(SUPERSEDE_START):16ビット
２16を法として計算される、このＲパケットによって置換される、包含的な、最も早期のＲパケットのＲシーケンス番号(この値は剰余演算を使用するので、置換範囲の終わりより前のすべてのＲパケットが置換されていることを示すためには、SUPERSEDE_STARTに対して値RSEQ+1を使用してよい)。このフィールドはオプションであり、len=6であるときにのみ存在する。
【００８４】
置換範囲の終わり(SUPERSEDE_END):16ビット
２16を法として計算される、このＲパケットによって置換される、包含的な、最後のＲパケットのＲシーケンス番号。この値は、２16を法として閉じた範囲[SUPERSEDE_START..RSEQ]内になければならない。このフィールドはオプションであり、len=6であるときにのみ存在する。
【００８５】
本発明によるエラー耐性ビデオ通信システムの動作は、‘Ｓ’と‘Ｅ’フラグの使用を除いて、国際特許出願第PCT/US06/061815号に記載の動作と同じ又は類似している。これらのフラグは受信側で、RTPシーケンス番号と組み合わせて使用され、特定のピクチャの全体が受信されたか（この場合、是正処置は不要）又は一部が受信されたか（この場合、是正処置が開始される）を検出する。様々な再送技術（例えば、肯定応答又は否定応答）を含め、システム動作の他のすべての態様は同じである。
【００８６】
１つのRTPパケットは、Ｒパケットマーク要素のそれぞれがSERについて異なる値を有する限り、複数のＲパケットマーク要素を含むことができる。しかし、RTPパケットは、Ｒビットがセットされたこうしたヘッダー拡張要素の複数を含むことはできない、すなわち１つのＲパケットは、複数の系列に属することはできない。
【００８７】
Ｒパケットを使用するメディアストリーム中のすべてのRTPパケットは、すべてのアクティブな系列についてマーク要素を含むべきである。
【００８８】
このヘッダー拡張要素の第２ワードが存在するとき、このＲパケットが以前に受信されたＲパケットのいくつかを置換することを示し、これらのパケットはストリーム状態を再構築するのにもはや必要ではないことを意味する。この第２ワードは、そのＲビットがセットされたヘッダー拡張要素内のみに現れなければならない。
【００８９】
Ｒパケットは、要素のSERフィールドで識別される系列のＲパケットを置換することができるだけである。Ｒパケットは、他の系列のパケットを置換することはできない。
【００９０】
置換要素がSUPERSEDE_END=RSEQを有することは有効である。このことは、Ｒパケットがそれ自体を置換すること、すなわち、このＲパケットがストリーム状態と直ちに無関係となることを示す。実際には、これを行う最も一般的な理由は、系列を終了させることであり、このことは、置換範囲(SUPERSEDE_START,SUPERSEDE_END)=(RSEQ+1,RSEQ)を有する空パケットを送ることによって行うことができ(例えば，RTP No-opパケット。Andreasen, F.,”A No-Op Payload Format for RTP”, draft-ietf-avt-rtp-no-op-00(work in progress), May 2005を参照)、その結果、その系列は、置換されないパケットをもはや含まない。
【００９１】
系列に於いて送られる最初のＲパケットは、他のＲパケットがその範囲内に存在しないことを明らかにするために、置換範囲(SUPERSEDE_START,SUPERSEDE_END)=(RSEQ+1,RSEQ-1)で送られるべきである。
【００９２】
Ｒパケットは、置換されるべきパケットの範囲内に、既に置換されたパケットを冗長的に含んでよい。
【００９３】
Ｒパケットの消失が受信側で検出され、その消失が、受信側によってRTCPフィードバック・メッセージを使用して送信側に示される。Ｒパケット否定応答(RNACK)メッセージは、例えばPT=RTPFB及びFMT=4で識別されるRTCPフィードバック・メッセージである(例えば、Ott,J. et al.,”Extended RTP Profile for RTCP-based Feedback(RTP/AVPF)”, RFC 4585, July 2006を参照)。本発明に従って他の値を選ぶこともできる。FCIフィールドは、少なくとも１つのRNACK含まなければならず、複数のRNACKを含んでよい。
【００９４】
RNACKパケットは、１つ又は複数のＲパケットの消失を示すのに使用される。消失パケットは、パケットシーケンス番号、系列の識別子、及びビットマスクによって識別される。
【００９５】
RNACKメッセージの構造及びセマンティクスは、AVPF Generic NACKメッセージのものと同様である。
【００９６】
図１８は、RNACKフィードバック制御情報(FCI)フィールドの例示的シンタックスを示し、個々のフィールドは以下のように定義される。
【００９７】
Ｒパケットシーケンス番号(RSEQ):16ビット
RSEQフィールドは受信側が受信していないRSEQ値を示す。
【００９８】
系列ID(SER):４ビット
このヘッダー拡張要素によってどの系列のＲパケットが消失していると記述されているかについての識別子。
【００９９】
後に続く消失Ｒパケットのビットマスク(BLR):12ビット
BLRは、RSEQによって示されるRTPパケットの直後の12個のRパケットのいずれかの消失を報告することを可能にする。BLRの最下位ビットをビット１と表し、BLRの最上位ビットをビット12と表すと、受信側が系列SER内のＲパケット番号(RSEQ+i) (２16を法として)を受信していない場合にビットマスクのビットｉが１にセットされ、このパケットが消失していることを示す。そうでない場合、ビットｉは０にセットされる。Ｒパケットのビットマスクが０にセットされていたからといって、送信側は、受信側がＲパケットを受信したことを仮定してはならないことに留意されたい。例えば、RSEQに対応するパケットと、系列内の後に続くＲパケットとが消失した場合、BLRの最下位ビットが１にセットされる。しかし、送信側は、BLRのビット２から12が０であるというだけでの理由でパケットRSEQ+2からRSEQ+12が受信されたことを推測することはできず、送信側が判ることは、受信側がこの時点で消失したと送信側に報告していないことだけである。
【０１００】
図１８に示すRNACKメッセージの構造は、国際特許出願第PCT/US06/061815号に記載されているものと同一である。
【０１０１】
受信側が最少遅延で、LRピクチャ(SRピクチャを含む)が消失したことを検出することを可能にする第２の例示的検出技法は、H.264 SVCドラフト標準規格に基づくシステムに適用可能である。このような場合、H.264 SVC NALユニットが、伝送のための基礎として使用される。国際特許出願第PCT/US06/061815号には、LRピクチャインデックス技法が、このような場合にもどのように適用できるかを記載している。RTP実施形態と同様に、本発明は、２つの単一ビットフラグを導入し、所与のLRピクチャの転送に複数のパケットが使用される場合に対処する。
【０１０２】
図１９は、H.264 SVCドラフトのシンタックスをベースに使用して開始及び最終フラグを含むように変更した、本発明のH.264 SVC NALヘッダー拡張の構造を示している（例えば、T. Wiegand, G. Sullivan, J. Reichel, H. Schwarz, M. Wien, eds.,”Joint Scalable Video Model 8: Joint Draft 8 with proposed changes”,Joint Video Team, Doc. JVT-U202,  Hangzhou, October 2006を参照。本文献は、参照によりここに全体を組み込んだものとする）。  開始及び最終フラグは、pic_start_flagとpic_end_flagであり、ピクチャインデックスは、tl0_pic_idxパラメータである。dependency_id(D)、temporal_level(T)、及びquality_level(Q)フィールドは、それぞれ空間/粗粒度品質(spatial/coarse grain quality)次元、時間次元、及び細粒度品質(fine-grain quality)次元を示す。言い換えれば、これらは、スケーラブルエンコーダによって与えられる解像度の組に於けるNALのペイロードの位置を示す。この方式での基本レイヤはD=Q=T=0で識別されることに留意されたい。
【０１０３】
本発明の好適な実施形態と思われるものを説明したが、同業者は、それらに対して、他の変更及び修正が、発明の精神から逸脱することなく可能であり、発明の正確な範囲内に入るそのようなすべての変更及び修正を特許請求することが目的とされていることを理解されよう。例えば、LRピクチャフレームインデックス値を表示し、非LRピクチャで参照する代わりの機構が、本発明に従い、RTP送信コンテクストとH.264 SVC NAL送信コンテクスト内で使用できる。同様に、開始及び最終フラグを表示する代わりの機構が、RTPとH.264 SVCに於いて使用できる。例えば、tl0_pic_idxパラメータ及び関連するpic_start_flagとpic_end_flagは、SEIメッセージで伝えてよい。
【０１０４】
本発明のシステム及び方法は、ハードウエアとソフトウエアの適切な組み合わせを使用して実現できることも理解される。上記のシステム及び方法を実現し動作させるソフトウエア（即ち、命令達）は、コンピュータ可読なメディアで提供することが可能であり、メディアには、ファームウエア、メモリ、記憶装置、マイクロコントローラ、マイクロプロセッサ、IC、ASICS、オンラインダウンロード可能なメデイア、及び他の利用可能なメデイアを含めてよく、これらに限定されるものではない。
【図１】
0005455648.tif 000002
【図２】
0005455648.tif 000003
【図３】
0005455648.tif 000004
【図４】
0005455648.tif 000005
【図５】
0005455648.tif 000006
【図６】
0005455648.tif 000007
【図７】
0005455648.tif 000008
【図８】
0005455648.tif 000009
【図９】
0005455648.tif 000010
【図１０】
0005455648.tif 000011
【図１１】
0005455648.tif 000012
【図１２】
0005455648.tif 000013
【図１３】
0005455648.tif 000014
【図１４】
0005455648.tif 000015
【図１５】
0005455648.tif 000016
【図１６】
0005455648.tif 000017
【図１７】
0005455648.tif 000018
【図１８】
0005455648.tif 000019
【図１９】
0005455648.tif 000020