(57)【要約】      （修正有）【課題】伝送の際にパケット損失があった場合、特に関連するアプリケーションの面で、失われたデータの型について、早期に詳細な情報をデコーダに提供する。【解決手段】パケットが多層アプリケーション・デコーダに供給される前にRTPパケット間の関係とそれらが担持するアプリケーション層データを識別および指示することに基づく、パケット・ベースの枠組における特殊なシンタックスが提供される。データ・ストリームが多層アプリケーションのアプリケーション・データを含むRTPパケットを有する。RTPパケット（ｐ２）は、次のRTPパケット（ｐ３）に関係する物と直前のRTPパケット（ｐ１）に関係する物とで二種のアプリケーション層情報（NBf、NBn）を含む。パケット損失があった場合、デコーダはすぐに欠けているデータの量および型（VCLx）を決定できる。【選択図】図１
2010045775.tif 000002
【特許請求の範囲】
【請求項１】
多層アプリケーションのアプリケーション・データを含むRTPパケットを有するデータ・ストリームであって、RTPパケットは、次のRTPパケットの内容に関係する第一のアプリケーション層情報と、直前のRTPパケットの内容に関係する第二のアプリケーション層情報とを含む、データ・ストリーム。
【請求項２】
前記アプリケーション・データがスケーラブル・ビデオ・データであり、前記アプリケーション層がスケーラブル・ビデオ層である、請求項１記載のデータ・ストリーム。
【請求項３】
前記アプリケーション層情報が、NAL型指示、品質情報、依存性情報、IDR番号およびピクチャー順カウント（picture  order  count）情報のうちの少なくとも一つを含む、請求項１または２記載のデータ・ストリーム。
【請求項４】
次のRTPパケットに関係するアプリケーション層情報および直前のRTPパケットに関係するアプリケーション層情報が当該RTPパケットのパディング・バイト内に記憶される、請求項１ないし３のうちいずれか一項記載のデータ・ストリーム。
【請求項５】
RTPパケットを使って多層アプリケーション・データをエンコードする方法であって、
・前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングする段階であって、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照する、段階と；
・少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケット内に加える段階と；
・前記第一、第二および第三のRTPパケットをこの順序で送信する段階とを有する、
方法。
【請求項６】
前記第一のデータおよび前記第二のデータが前記第二のパケットのパディング・バイト内に加えられる、請求項５記載の方法。
【請求項７】
前記アプリケーションの前記第一の層を定義する前記第一のデータおよび前記アプリケーションの前記第三の層を定義する第二のデータが、NAL型指示、品質情報、依存性情報、IDR番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、請求項５または６記載の方法。
【請求項８】
前記第一のデータまたは前記第二のデータが、直前または直後のパケットのアプリケーション・データが一つまたは複数の特定のNAL型を参照することを示すフラグを含む、請求項７記載の方法。
【請求項９】
前記第一、第二および第三のパケットが直接相続くシーケンスで送信される、請求項５ないし８のうちいずれか一項記載の方法。
【請求項１０】
多層アプリケーション・データを含むRTPパケットの復号の用意をする方法であって、
・少なくとも第一およびその後の第二のRTPパケットを受信する段階と；
・前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出する段階と；
・前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出する段階と；
・前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別する段階と；
・前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較する段階と；
・前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する段階と；
・前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する段階と；
・抽出および比較する前記諸段階の結果を前記多層アプリケーションのためのデコーダに提供する段階とを有する、
方法。
【請求項１１】
前記第一及び第二のRTPパケット内の隣接情報が、NAL型指示、品質情報、予測依存性情報、IDR番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、請求項１０記載の方法。
【請求項１２】
RTPパケットを使って多層アプリケーション・データをエンコードする装置であって、
・前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングする挿入手段であって、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照する、手段と；
・少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケット内に加える挿入手段と；
・前記第一、第二および第三のRTPパケットをこの順序で送信する送信手段とを有する、
装置。
【請求項１３】
前記第一のデータおよび前記第二のデータが前記第二のパケットのパディング・バイト内に加えられる、請求項１２記載の装置。
【請求項１４】
多層アプリケーション・データを含むRTPパケットの復号の用意をする装置であって、
・少なくとも第一およびその後の第二のRTPパケットを受信する受信手段と；
・前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出する第一の抽出手段と；
・前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出する第二の抽出手段と；
・前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別する判別手段と；
・前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較する第一の比較手段と；
・前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する第二の比較手段と；
・前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する第三の比較手段と；
・前記第一および第二の抽出手段ならびに前記第一、第二および第三の比較手段の結果を前記多層アプリケーションのためのデコーダに向けて提供する提供手段とを有する、
装置。
【請求項１５】
前記第一および第二のRTPパケット内の隣接情報が、NAL型指示、品質情報、予測依存性情報、IDR番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、請求項１４記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多層（multi-layer）アプリケーションのアプリケーション・データを含むパケット化されたリアルタイム・プロトコル（RTP:  real-time  protocol）・データ・ストリームに関する。特に、本発明はRTPベースのスケーラブルなビデオ伝送に関する。
【背景技術】
【０００２】
スケーラブル・ビデオ、スケーラブル・オーディオなどといったさまざまな多層マルチメディア・アプリケーションが存在している。マルチメディア・データはしばしばパケット化されたデータ・ストリームを通じて伝送され、それにより別個の層のマルチメディア・データが単一のデータ・ストリームに時間多重化される。具体的には、H.264/AVC規格のスケーラブル・ビデオ符号化（SVC:  Scalable  Video  Coding）拡張は、時間的、空間的および品質の三つの種類のスケーラビリティを用いる。時間的スケーラビリティはH.264/AVCにおいてよくサポートされており、SVCの基本層はH.264/AVCに準拠するよう入念に設計されている。
【０００３】
典型的には、インターネットおよび移動ネットワークを通じたリアルタイム・ビデオ伝送はRTP/IPに基づく。IETFはSVCビデオについてのRTPペイロード・フォーマットを提案している。しかしながら、RTPベースのSVCビット・ストリームのデコードおよびレンダリングを容易にするためにさらなる改善をすることができ、伝送方式は一般的な規格のデコーダに準拠したままにできる。
【０００４】
デコーダは何らかの初期情報、たとえばスケーラブル・ビデオの場合には全体の空間的および品質スケーラビリティ層の数を必要としてもよい。この初期情報は、デコーダが、たとえばメモリ割り当ておよび関係したパラメータ構成設定を初期化することを助けうる。層の依存性またはフレーム型のような他の情報もデコーダがより効率的かつ堅牢であることを助けうる。
【０００５】
しかしながら、伝送チャネルは通例誤りを生じやすい。そのような誤りを生じやすいチャネルを通じた伝送の際のパケット損失の場合、デコーダによっては誤り隠蔽プロセスを実行することがある。だが、デコーダはしばしば、RTPのような転送ストリームのフォーマットに頼る。たとえば標準的なRTPヘッダはタイミング情報およびRTPパケット番号を含み、これらがパケットが正しい順序でデコードされることを保証するために使用できる。しかしながら、パケットが失われているかどうかを検出するためにはさらなるプロトコルが必要である。一般的なインターネット・アプリケーションについてはTCPが使われるが、TCPはリアルタイム・アプリケーションのためには遅すぎる。したがって、リアルタイム機能のあるシステムでは、アプリケーション・デコーダはデータ損失状況に対処しなければならず、どのデータが欠けているかを独力で見出さねばならない。これはアプリケーション・デコーダを攪乱することがあり、場合によってはその再初期化を要求することさえありうる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
多層アプリケーションについて、アプリケーション・デコーダには、データ損失に際して反応するために、失われたデータ・パケットの型および関連するアプリケーション層に依存して複数の異なるオプションがあることが見出されている。しかしながら、欠けているパケットがどのアプリケーション層に属するかは通例未知である。通常の多層アプリケーション・デコーダは、そのような状況を回復させるためにいくらかの処理時間を必要とする。失われたデータの型がわかるのが迅速であるほど、デコーダはよく反応できる。本発明によって解決されるべき一つの課題は、転送パケット損失の場合に、特に関連するアプリケーションの面で、失われたデータの型についてのより早期のかつより詳細な情報をデコーダに提供することである。
【課題を解決するための手段】
【０００７】
本発明は、パケットが多層アプリケーション・デコーダに与えられる前にRTPパケットとそれが担持するアプリケーション層／フレームとの間の関係を識別および指示することに基づく、パケット・ベースのフレームワーク内での特別なシンタックスを提供する。これはデコーダが適時に適正な誤り隠蔽技術を適用することを助け、デコーダ内での不必要な処理を防止する。
【０００８】
本発明は、上述の問題を解決するデータ・ストリーム・フォーマット、エンコード方法および装置ならびにデコード方法および装置を提供する。
【０００９】
本発明のある側面によれば、データ・ストリームは、多層アプリケーションのアプリケーション・データを含むRTPパケットを有する。ここで、少なくとも一つのRTPパケットは、次のRTPパケットの内容に関係する第一のアプリケーション層情報と、（送信順において）直前のRTPパケットの内容に関係する第二のアプリケーション層情報とを含む。
【００１０】
本発明のもう一つの側面によれば、RTPパケットを使って多層アプリケーション・データをエンコードする方法は、
前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングし、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照し、
少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケット内に加え、前記第一、第二および第三のRTPパケットを（この送信順序で）送信する、段階を有する。
【００１１】
RTPパケットを使って多層アプリケーション・データをエンコードする関連する装置は、前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングする挿入手段を有し、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照し、当該装置はさらに、少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケット内に加える挿入手段と、前記第一、第二および第三のRTPパケットを（この送信順序で）送信する送信手段とを有する。前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにパッキングする前記挿入手段は、一つ、二つまたは三つ全部のRTPパケットを逐次的にまたは同時に処理しうる。データを前記第二のRTPパケット内に加える前記挿入手段は、前記第一のデータおよび前記第二のデータを逐次的にまたは同時に処理し、前記第二のパケット内に挿入しうる。
【００１２】
本発明のさらにもう一つの側面によれば、多層アプリケーション・データを含むRTPパケットの復号（あるいはある意味では該復号の準備）の方法が、
少なくとも第一およびその後の第二のRTPパケットを受信し、前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出し、前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出し、
前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別し、
前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較するか、あるいは前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較するか、あるいはその両方の比較をし、
前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較し、
抽出および比較する前記諸段階の結果を前記多層アプリケーション用のデコーダに提供する、
段階を有する。
【００１３】
多層アプリケーション・データを含むRTPパケットの復号（の準備）をする関連する装置は、
少なくとも第一およびその後の第二のRTPパケットを受信する受信手段と、
前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出する第一の抽出手段と、
前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出する第二の抽出手段と、
前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別する判別手段と、
前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較するか、あるいは前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較するか、あるいはその両方の比較をする第一の比較手段と、
前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する第二の比較手段と、
前記第一および第二の抽出手段ならびに前記第一および第二の比較手段の結果を前記多層アプリケーション用のデコーダに提供する提供手段とを有する。
【００１４】
例示的に、前記多層アプリケーション・データは基本層および一つまたは複数の向上層をもつ階層的データであってもよい。
【００１５】
本発明の有利な実施形態は従属請求項、以下の記述および図面において開示される。
【００１６】
本発明の例示的な実施形態は付属の図面を参照して記述される。
【図面の簡単な説明】
【００１７】
【図１】本発明に基づくデータ・ストリームの構造を示す図である。
【図２】パディング・バイトをもつRTPパケットのフォーマットを示す図である。
【図３】エンコードのブロック図である。
【図４】デコード準備のブロック図である。
【図５】本発明のある側面に基づくRTCPパケットのフォーマットを示す図である。
【発明を実施するための形態】
【００１８】
図１は、パケット化されたデータ・ストリームの構造を示している。データ・ストリーム中の一連のパケットｐ１、ｐ２、ｐ３は多層アプリケーションのアプリケーション・データを含む：第一のパケットｐ１は第一のアプリケーション層VCLpのアプリケーション・データを含み、その後の第二および第三のパケットｐ２、ｐ３はそれぞれ第二のアプリケーション層VCLcおよび第三のアプリケーション層VCLnのアプリケーション・データを含む。描かれているように、これらのパケットは直接的なシーケンスにおいて送信／受信される。たとえばリアルタイム・プロトコル（RTP）が転送プロトコルとして使われる場合、パケットはRTPパケット番号をもつ。したがって、受信機はそれらのパケットをその正しいシーケンス順にすることができる。しかし、たとえば第二のパケットｐ２が伝送中に失われる場合、デコーダは欠けているデータがどのアプリケーション層に属するかがわからないであろう。本発明では、復号および誤り隠蔽の効率を改善するために、転送パケットのオーバーヘッドにより多くの情報を加える方式が提案される。これは、デコーダがより柔軟な仕方で反応することを可能にする。たとえば、デコーダは欠けているパケットが多層アプリケーションの向上層に属することを見出すことができ、その結果、基本層の復号を続けることができる。こうして、ユーザーは品質の一時的な損失を経験しうるのである。一方、従来ではアプリケーションが中断されたであろう。そうではなく、本アプリケーションは基本モード、たとえばより低解像度で実行を続ける。
【００１９】
図１に示されるように、本発明は多層アプリケーションのアプリケーション・データをもつ転送パケットが、それ自身の層だけでなく二種類の隣接情報をも指定する情報を含むことを含む。二種類の隣接情報（neighbor  information）とは、直前の（f＝former［前］）転送パケット中のアプリケーション・データの層VCLfを指定する一つのNBfと、後続の（n＝next［次］）転送パケット中のアプリケーション・データの層VCLnを指定する一つのNBnとである。こうして、最もありそうなケースである一つまたは二つのRTPパケットが失われた場合には、どの型のアプリケーション・データが欠けているかを見出すことが可能である。
【００２０】
以下では、SVCベースの実施形態が記載される。上で説明したように、本発明は他の多層マルチメディア・アプリケーションにも適用可能である。他のどんなビデオ・デコーダとも同様、SVCデコーダは伝送エラーに敏感である。RTPに基づくSVCビデオ伝送にとって、パケット損失は、有効な誤り隠蔽技術が使われなければデコーダにとって致命的となりうる。ほとんどどんな誤り隠蔽方法にとっても、失われたデータがどのスライス／層〔レイヤー〕／フレームに属しているかを迅速に知ることが非常に重要である。これは伝統的には受信パケットを復号することによって決定できるが、これは不必要なまでに複雑な手法と思われる。さらに、それはデコーダにおけるソフトウェア問題、たとえばクラッシュの危険を誘発する。その問題のさらなる側面は、RTPのような既存のシステムのための、パケット・フォーマットの変更を要求しない解決策が必要とされているということである。
【００２１】
本発明によれば、データがSVCデコーダに供給される前に受信機が失われたパケットの識別情報を得るのを助けるために、RTPパケットのパディング・バイト中に何らかのオーバーヘッド情報が挿入される。結果として、デコーダは、種々の解決策をどのように進めるかを、通常の方法よりも早期に決定できる。たとえば、一つの可能な反応は、失われたパケットが関係しているスライス全体を放棄し、代わりに前のピクチャーの同位置のスライスを使う、たとえばそれを現在のピクチャー・バッファにコピーするということである。
【００２２】
有利なことに、これはデコーダの安定した処理および無用な計算の削減を意味する。
【００２３】
識別情報をパディング・バイト中に入れることによって、本方式は、パディング・バイトを、よって識別情報を完全に無視する一般的な標準的SVCデコーダに準拠したままに保つことができる。提案される方法は、多層デコーダにおける誤り隠蔽をサポートできる。原理的には、現在のRTPパケットの後および前の、次および直前のRTPパケットの基本SVC情報が現在のRTPパケット内に保存される。この方法では、SVCデコーダは、誤り隠蔽処理をより早期にかつより簡単に実行できる。
【００２４】
図２ａ）は、本発明に基づくRTPパケットの構造についての概観を示している。図２ｂ）およびｃ）は同じパケットのさらなる詳細を示す。図２の各行は、32ビットをもつパケットの１ワードである。第１〜第５ワードは、下記に示されるように、一般的なヘッダ情報を含む。
【００２５】
H.264およびSVCは、いわゆるネットワーク抽象化層（NAL:  network  abstraction  layer）を使い、エンコードされたビデオ・データを処理およびフォーマット整形してNAL単位と呼ばれるパケットにする。NAL単位は、伝送のために、通例復号順にRTPパケットのような転送パケットにマッピングされる。種々の型のNAL単位が定義されている。NAL単位は、そのnal_typeが1、5または20に等しい場合、マクロブロックから生成される実際のピクチャー・データを担持する。nal_typeがそれらの値に等しくない場合、NALはシーケンス・パラメータ・セット（SPS:  sequence  parameter  set）またはピクチャー・パラメータ・セット（PPS:  picture  parameter  set）のような制御情報を担持する。各フレームは、SVCでは、1、5または20に等しいnal_typeの一つまたは複数のNAL単位にエンコードされる。この種のRTPパケット、よってNAL単位が送達中に失われる場合、対応するフレームは正しく復号されないことになる。これは重要な情報なので、我々はデコーダにnal_type＝1、5または20をもつNALの損失があったことを前もって知らせるために別個のフラグを加える。
【００２６】
Vはバージョン・フィールドである。例示的に、Vは図２ではV＝2に設定されている。PはRTPパケットの末尾の追加的なパディング・バイトを示す１ビットのフラグである。P＝1であれば、パケットは末尾に一つまたは複数の追加的なパディング・バイトを含む。MはRTPパケットが特殊であるかどうか、たとえば現在のスライスの最後のRTPパケットであるかどうかを示す１ビットのフラグである。RTPパケット・ヘッダ内の他の通常のフィールドはペイロード型、タイムスタンプ、同期ソース（synchronization  source）ID（SSRC）および寄与ソース（contributing  sources）（CSRC）フィールドである。ペイロードは実際のビデオ・データを含む。例示的に２ペイロード・ワードが示されているが、パケットは通例より多くのペイロードを担持する。ペイロードの後には、Pフラグによって示されるようなパディング・バイトが続く。
【００２７】
本発明によれば、前および次のRTPパケットについての追加的なアプリケーション関係の情報がパディング・バイトに記憶される。たとえば、SVCは表１に示される構造および対応する構造関係のパラメータを定義する。
【００２８】
【表１】
2010045775.tif 000003
表１に示される構造は例である。全部でA〜Fの７つの層がある。基本層はA、D、Eである。品質層B、C、Fはすべてそれぞれの基本層と同じ空間解像度をもつ。空間的層D、Eはその基本層とは異なる空間解像度をもつ。
【００２９】
「品質層（quality  layer）」と名付けられた層は、SVCにおけるスケーラビリティの一つの種類である品質スケーラビリティ（quality  scalability）によって生成される。SVCは、品質層がその基本層と同じ空間解像度をもつことを要求する。品質スケーラビリティ層のエンコード型は空間的スケーラビリティ層とは異なる。よって、品質層データについての復号手法およびNAL単位損失の対処方法は、空間的スケーラビリティ・データについてのものとは異なる。「quality_id」〔品質ID〕は、SVCビット・ストリームにおける各品質層のIDを示すシンタックス要素である。
【００３０】
「dependency_id」〔依存性ID〕は、SVCにおいて空間的層を示すために使われる。８つの空間的層が許される。空間的層は、基本層が存在する場合、その基本層（または基準層）とは異なる空間解像度をもつ。シンタックス要素「dependency_id」を用いて、現在の層がどの空間的層に属するかがわかる。quality_id＝0であれば、これは現在の層が空間的層であり、空間的層として復号されるべきであることを意味する。そうでなければ、現在の層は品質層として復号されるべきである。
【００３１】
原則として、「dependency_id」は空間解像度の変化を示し、「quality_id」はエンコード手法の変化を示す。
【００３２】
SVCデコーダにおいて、この情報をもつことが有用となる。
【００３３】
本発明のある実施形態では、以下の情報がパディング・バイトに含まれる（添え字nおよびfはそれぞれ次（next）または前（former）のパケットを指す）：
Vn:  １ビットのフラグ。Vn＝1は（送信順で）次のRTPパケットによって担持されるNAL単位のnal_typeが1、5または20に等しいことを示す。これは、次のパケットがマクロブロック・データ、すなわち実際のピクチャー・データを含んでいることを意味する。各ビデオ・フレームはnal_type＝1、5または20の一つまたは複数のNALユニットにエンコードされる。
Qn:  １ビットのフラグ。Qn＝1は、後続のRTPパケットによって担持される次のNAL単位が品質層に属する（quality_id＞0）ことを示す。そうでなければQn＝0であり、次のRTPパケットは空間的層に属する。
Dn:  １ビットのフラグ。Dn＝1は、後続のRTPパケットによって担持される次のNALが現在のNALと同じdependency_idの値をもつことを示す。そうでなければDn＝0である。
POCn:  10ビット符号なし整数で、後続のRTPパケットによって担持される次のNALのPOC番号を示す。
PIC_idxn:  10ビット符号なし整数で、後続のRTPパケットによって担持される次のNALのIDR番号を示す。nal_type＝5をもつ新しいNALが処理されるときに1ずつインクリメントされる。最大値1023に達すると、0に戻る。
【００３４】
Vn＝1のとき、これは（送信順で）次のRTPパケットによって担持されるNALのnal_typeが1、5または20に等しく、Vn、Qn、Dn、POCnおよびPIC_idxnフラグのすべての値は次のRTPパケット内のNALに関係することを示す。そうでなくて、Vn＝0の場合、これらの値はすべて、より後のRTPパケット内にある次のNAL（SVCビット・ストリームにおける保存順）に関係する。
【００３５】
Vf:  １ビットのフラグ。Vf＝1は前のRTPパケット（すなわち、送信順で直前のパケット）によって担持されるNALのnal_typeが1、5または20に等しいことを示す。
Qf:  １ビットのフラグ。Qf＝1は、前のRTPパケットによって担持されるNALが品質層に属する（quality_id＞0）ことを示す。そうでなければQf＝0である。
Df:  １ビットのフラグ。Df＝1は、前のRTPパケットによって担持されるNALが現在のNALと同じdependency_idの値をもつことを示す。そうでなければDf＝0である。
POCf:  10ビット符号なし整数で、前のRTPパケットによって担持されるNALのPOC番号を示す。
PIC_idxf:  10ビット符号なし整数で、前のRTPパケットによって担持されるNALのIDR番号を示す。nal_type＝5をもつ新しいNALが処理されるたびに1インクリメントされる。最大値1023に達すると、0に戻る。
【００３６】
もう一つの任意的なパラメータはパディング長である。これは、それ自身を含め、パディング・バイトの数である。パディング・バイトは必ずしも32ビットの境界に整列されていない。
【００３７】
フラグVx（x＝nまたはf）は、次／前のRTPパケットのNALがVCL  NALであるかどうかを示す。フラグQxによって提供される情報を用いて、デコーダは簡単に、次／前のRTPパッケージ内のNALが品質層に属するかどうかを知ることができる。フラグDxを用いて、空間的／CGS層が簡単に得られる。
【００３８】
単一のRTPパケットが失われる場合、Vn＝1かつQn＝0（すなわちピクチャー・データをもつ空間的層）であれば、誤り隠蔽がSVCデコーダによって実行されるべきである。この場合、必要とされるピクチャー・データが欠けている。失われたNALが属するフレームはPOCnに従って判別でき、SVCデコーダにおいて単純かつ高速な誤り隠蔽アルゴリズムが利用できる。
【００３９】
いくつかの相続くRTPパケットが失われる場合、SVCデコーダはVn＝1かつQn＝0またはVf＝1かつQf＝1の場合、誤り隠蔽を実行すべきである。最初の失われたRTPパケットより前のRTP内のDn、POCnおよびPIC_idxnの情報と最後の失われたRTPパケットより後のRTP内のDf、POCfおよびPIC_idxfの情報を用いて、失われたピクチャーの数およびそのGOPおよび層情報が決定でき、次いでSVCデコーダに提供されることができる。この情報はSVCデコーダが単純かつ高速な誤り隠蔽を実行することを助ける。
【００４０】
図３は、本発明のある側面に基づく、エンコードのためのブロック図である。ある実施形態では、本エンコード方法は、多層アプリケーション・データの少なくとも第一、第二および第三の相続く部分をそれぞれ第一、第二および第三のRTPパケットｐ１、ｐ２、ｐ３にパックするまたは挿入する（３０５）ステップを含む。上記のように、アプリケーション・データの前記種々の部分は該アプリケーションの第一、第二および第三の層VCLf、VCLc、VCLnを指す。これらの層は異なっていてもよいし、あるいはどれか二つまたは三つすべてのパケットが同じ層を指していてもよい。
【００４１】
次のステップ３２０では、少なくとも、前記アプリケーションの第一の層（前の第一のパケットが参照する層）を定義する第一のデータVfおよび前記アプリケーションの第三の層（次の第三のパケットが参照する層）を定義する第二のデータVnが第二のRTPパケット中に加えられる。具体的には、この情報は、上記したようなパディング・バイト内に加えられる。第三のステップでは、第一、第二および第三のRTPパケットが（この順に）送信される（３２５）。
【００４２】
しかしながら、もう一つの実施形態では、一時に単一のパケットをエンコードすることが、一時的にバッファリングされうるそれぞれの前および次のパケットについてのアプリケーション層情報が該パケットに挿入される限り、十分である。
【００４３】
図３は、本発明のある側面に基づくエンコーダの一般的な構造を示すものとして理解することもできる。RTPパケットを使って多層アプリケーション・データをエンコードするそのようなエンコーダは、多層アプリケーション・データの第一、第二および第三の部分をそれぞれ第一、第二および第三のRTPパケットｐ１、ｐ２、ｐ３にパックする挿入手段３０５を有する。ここで、アプリケーション・データの前記第一、第二および第三の部分は第一、第二および第三のアプリケーション層を参照する。本エンコーダは、少なくとも、第一の（＝前の）パケットを指す第一のアプリケーション層データおよび第三の（＝次の）パケットに関係する第二のアプリケーション層データを、第二のRTPパケット中に加える挿入手段３２０と、前記第一、第二および第三のRTPパケットを（この順に）送信する送信手段３４０とを有する。
【００４４】
図４は、実際のアプリケーション層復号の前に実行されるべき、復号準備の原理のブロック図を示している。実際の実装はより洗練されていても、あるいはデコーダに組み込まれていてもよい。
【００４５】
本方法は、多層アプリケーション・データを含むRTPパケットの復号を準備するためのものであって、少なくとも第一およびその後の第二のRTPパケットを受信し（４０１）、前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分（４１５）を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報NBnを抽出し（４１０）、同様にして、前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分（４２５）を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報NBfを抽出する（４２０）ステップを含む。上記のように、隣接情報は、次のパケットに関しては前記Vn、Qn、Dn、POCnおよびPIC_idxnの少なくとも一つを含み、前のパケットに関してはVf、Qf、Df、POCfおよびPIC_idxfの少なくとも一つを含む。
【００４６】
次のステップでは、前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型typnおよびtypn+1が決定される（４３０、４４０）。
【００４７】
次のステップは、前記第二のRTPパケット内の多層アプリケーション・データの判別された型typn+1を前記第一のRTPパケットから抽出された前記第一の隣接情報NBnと比較する（４５０）か、および／または、前記第一のRTPパケット内の多層アプリケーション・データの判別された型typnを前記第二のRTPパケットから抽出された前記第二の隣接情報NBfと比較する（４６０）かする。両方の比較が実行される場合、のちに述べるように、それらは三つの異なる結果をもたらすことができる。
【００４８】
次のステップでは、前記第一のRTPパケットから抽出された前記第一の隣接情報NBnと前記第二のRTPパケットから抽出された前記第二の隣接情報NBfとが比較される（４７０）。両者が等しく、かつパケットの欠失があれば、一つのパケットのみが欠けていると結論できる。両者が異なっており、パケットの欠失がある場合には、二つ以上のパケットが欠けていると結論できる。
【００４９】
次いで、前記抽出および比較の結果が前記多層アプリケーション用のデコーダに提供される。該デコーダは、欠けている情報の長時間の解析を実行する必要がないので、非常に高速に適切な仕方で反応できる。
【００５０】
一つの比較結果信号４５５は、現在のパケットの型が次のパケットにおいて示されているとおりであるかどうかを示す。一つの比較結果信号４６５は、現在のパケットのパケット型が前のパケットにおいて示されているとおりであるかどうかを示す。これら二つの信号４５５、４６５は、データが欠けているかどうかを示すので、一次比較結果と見なされる。一つの比較結果信号４７５は前のパケットにおいて「次」と示されているパケット型と現在パケットにおいて「前」と示されているパケット型とが等しいかどうかを示す。これは、データが欠けている場合にのみ有意であるので、二次比較結果である。
【００５１】
ある実施形態では、これらすべての比較結果信号が、期待される次および前のパケット型typn、typn+1とともに多層アプリケーション・デコーダに送達される。デコーダは該情報をのちに述べるように利用できる。
【００５２】
例示的に、二つだけの相続くパケットの受信および評価について述べる。二つの受信パケットがあれば三つの異なる状況が起こりうる：
ケース１では、第一のパケット中の「次」の情報は第二のパケットのパケット型に等しく、第二のパケット中の「前」の情報が第一のパケットのパケット型に等しい。この場合、一次比較結果信号４５５および４６５はすべて大丈夫であり、パケットは失われていないことを示す。
【００５３】
ケース２では、第一のパケット中の「次」の情報は第二のパケットの実際のパケット型と異なっており（あるいは、第二のパケット中の「前」の情報が第一のパケットの実際のパケット型と異なっており）、さらに第一のパケット中の「次」の情報は第二のパケット中の「前」の情報と等しい。換言すれば、一次信号４５５、４６５の少なくとも一つが、データが欠けていることを示し、二次信号４７５が、両方のパケットが同じ型の欠けているデータを示していることを示す。この場合、第一のパケットと第二のパケットとの間で一つのパケットだけが欠けていると結論でき、その型は「次」および「前」の情報からわかる。
【００５４】
ケース３では、第一のパケット中の「次」の情報は第二のパケットの実際のパケット型と異なっており（あるいは、第二のパケット中の「前」の情報が第一のパケットの実際のパケット型と異なっており）、さらに第二のパケット中の「前」の情報が第一のパケット中の「次」の情報と異なっている。換言すれば、一次信号４５５、４６５の少なくとも一つが、データが欠けていることを示し、二次信号４７５が、両方のパケットが異なる型の欠けているデータを示していることを示す。この場合、第一のパケットと第二のパケットとの間で少なくとも二つのパケットが欠けていると結論できる。
【００５５】
この情報が与えられれば、多層アプリケーション・デコーダは非常に高速に現在の状況に従って反応できる。
【００５６】
ある実施形態では、追加的なパケットによってデコーダにさらなる助けが与えられる。RTPプロトコルでは、RTCPパケットがこの目的のために使用できる。図５は、デコーダに追加的な情報を送信するためにどのようにして効果的にRTCPパケットを利用するかを示している。有利なことに、このようにして、より高速なデコーダ初期化を許容する構造情報が送信されることができる。
【００５７】
ある実施形態では、（空間および／または品質）層の数が、アプリケーションによって定義されたRTCPパケット内で、受信機に送られる。デコーダの初期化を容易にすることが意図され、ランダム・アクセスのために、その情報は周期的に、たとえばIDRフレームまたはSPSと同じ頻度で送出されることができる。図５はそのようなRTCPパケットのフォーマットを示している。いくつかのフィールドについて以下に説明する。
「Subtype」〔サブタイプ〕：「Name」フィールドとともに、パケットの内容を識別するために使うことができる。
「Length」〔長さ〕：ヘッダを含め32ビット・ワードでのこのRTCPパケットの長さから1を引いたものを与える。
「Name」〔名前〕：４つのASCIIキャラクタのシーケンスと解釈される。大文字と小文字は区別して扱われる。「Name」はSVC関係のRTPベースのアプリケーションを示すために使用されることができる。SVCデコーダまたは復号手順を初期化するために、受信機は迅速に、受信されたSVCビット・ストリームの全体論的情報（holistic  information）を得てもよい。SVCデコーダ初期化のための情報をRTCPパケット内に挿入するために、二つの種類の方法が可能である。
【００５８】
ケース１：「Subtype」フィールドは、パケットの内容を識別するに、常に「Name」フィールドと一緒に使われる。「Name」フィールドがRTPパッケージ内のペイロードがSVCビット・ストリームであることを示す場合、任意の３ビットが、SVCビット・ストリーム中のシンタックス要素「dependency_id」の最大値を示すために使われることができる。例示的に、図５ｂ）に示されるように、最初の３ビットをこの値を保存するために使う。maxD_idは、送られるSVCビット・ストリーム中の「dependency_id」の最大値を示す符号なしの３ビットの整数である。「dependency_id」の最大値は、SVCビット・ストリーム中の空間的／CGS層の合計を示す。この値はSVCデコーダの基本的初期化のために非常に重要である。ローカルなビット・ストリーム再生のためには、この値はSVCビット・ストリーム依存性を検査することによって得ることができる。だが、誤りを生じやすい（たとえばネットワーク・ベースの）SVCアプリケーションについては、SVCビット・ストリームの依存性を検査することによって得られる「dependency_id」の最大値はパケット損失のために間違っていることがありうる。maxD_idの値は、SVCデコーダを初期化するために受信機よって使用されることができる。
【００５９】
層情報を初期に送達するためのもう一つの方法は、図５ｃ）に示されるように、「Name」フィールドの末尾に追加的なペイロードを加えることである。maxD_idは上記の通りである。maxT_idはSVCビット・ストリーム中のシンタックス要素「temporal_id」の最大値を示すために３つのビットをもつ。maxQ_idは、SVCビット・ストリーム中のシンタックス要素「quality_id」の最大値を示すために４つのビットをもつ。
【００６０】
「length」のデフォルト値は2である。「Name」がSVC関係のアプリケーションを示し、「Length」が前記デフォルト値に等しくないとき、「Name」フィールドの次の10ビットがmaxD_id、maxT_idおよびmaxQ_idを保存する。受信機側では、maxD_idはSVCデコーダの基本的な初期化のために使用されることができ、maxT_idおよびmaxQ_idは向上されたSVCデコーダ初期化のために使用されることができる。デコーダのための利点は、実際の復号が始まる前にパラメータを決定するためにデータ・ストリームを解析する必要がないということである。したがって、初期化はより高速になり、復号はより早期に開始できる。
【００６１】
本発明はあくまでも例として記載されてきたこと、本発明の範囲から外れることなく詳細の修正がなしうることは理解されるであろう。本記載ならびに（適切なところでは）請求項および図面に開示されている各特徴は、独立して設けられてもよいし、あるいは任意の適切な組み合わせにおいて設けられてもよい。諸特徴は、適切なところでは、ハードウェア、ソフトウェアまたは両者の組み合わせにおいて実装されてもよい。該当するところでは、接続は無線接続または有線接続として実装されてもよく、有線接続が必ずしも直接接続や専用接続でなくてもよい。
【００６２】
請求項に参照符号があったとしても例示のためのみであり、請求項の範囲にいかなる限定する効果ももたないものとする。
【符号の説明】
【００６３】
３００  エンコードまたはエンコーダ
３０５  多層アプリケーション・データの少なくとも第一、第二および第三の相続く部分をそれぞれ第一、第二および第三のRTPパケットにパックするまたは挿入する
３２０  前の第一のパケットが参照する層を定義する第一のデータVfおよび次の第三のパケットが参照する層を定義する第二のデータVnが第二のRTPパケット中に加えられる
３２５  第一、第二および第三のRTPパケットが（この順に）送信される
４００  復号準備の原理
４０１  少なくとも第一およびその後の第二のRTPパケットを受信
４１０  第一のRTPパケットのボディから多層アプリケーション・データの第一の部分を、第一のRTPパケットのパディング・バイトから第一の隣接情報NBnを抽出
４２０  第二のRTPパケットのボディから多層アプリケーション・データの第二の部分を、第二のRTPパケットのパディング・バイトから第二の隣接情報NBfを抽出
４３０  第一のRTPパケット内の多層アプリケーション・データの型typnを決定
４４０  第二のRTPパケット内の多層アプリケーション・データの型typn+1を決定
４５０  第一のRTPパケット内の多層アプリケーション・データの判別された型typnを第二のRTPパケットから抽出された第二の隣接情報NBfと比較
４５５  比較結果信号
４６０  第二のRTPパケット内の多層アプリケーション・データの判別された型typn+1を第一のRTPパケットから抽出された第一の隣接情報NBnと比較
４６５  比較結果信号
４７０  第一のRTPパケットから抽出された第一の隣接情報NBnと第二のRTPパケットから抽出された第二の隣接情報NBfとを比較
４７５  比較結果信号
【図１】
2010045775.tif 000004
【図２】
2010045775.tif 000005
【図３】
2010045775.tif 000006
【図４】
2010045775.tif 000007
【図５】
2010045775.tif 000008
【外国語明細書】
2010045775000001.pdf