JP5686506B2 - Ｒｔｐパケットを含むデータ・ストリームならびにそのようなデータ・ストリームをエンコード／デコードする方法および装置 - Google Patents

Ｒｔｐパケットを含むデータ・ストリームならびにそのようなデータ・ストリームをエンコード／デコードする方法および装置 Download PDF

Info

Publication number
JP5686506B2
JP5686506B2 JP2009174653A JP2009174653A JP5686506B2 JP 5686506 B2 JP5686506 B2 JP 5686506B2 JP 2009174653 A JP2009174653 A JP 2009174653A JP 2009174653 A JP2009174653 A JP 2009174653A JP 5686506 B2 JP5686506 B2 JP 5686506B2
Authority
JP
Japan
Prior art keywords
packet
information
rtp
layer
rtp packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2009174653A
Other languages
English (en)
Other versions
JP2010045775A (ja
Inventor
ウェン ウー ユ
ウェン ウー ユ
ボ チェン ジ
ボ チェン ジ
ジン シア ジ
ジン シア ジ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of JP2010045775A publication Critical patent/JP2010045775A/ja
Application granted granted Critical
Publication of JP5686506B2 publication Critical patent/JP5686506B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、多層（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は表１に示される構造および対応する構造関係のパラメータを定義する。
Figure 0005686506
 表１に示される構造は例である。全部で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パケットを有するデータ・ストリームであって、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番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、付記１４記載の装置。
３００ エンコードまたはエンコーダ
３０５ 多層アプリケーション・データの少なくとも第一、第二および第三の相続く部分をそれぞれ第一、第二および第三の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とを比較
４７５ 比較結果信号

Claims (9)

  1. ネットワークを介した伝送のためのワイヤフォーマットを有し、多層アプリケーションのアプリケーション・データを含むRTPパケットを有するデータ構造であって、RTPパケットは、次のRTPパケットの内容に関係する第一のアプリケーション層情報と、直前のRTPパケットの内容に関係する第二のアプリケーション層情報とを含み、
    次のRTPパケットに関係するアプリケーション層情報および直前のRTPパケットに関係するアプリケーション層情報が当該RTPパケットのパディング・バイト内に記憶され、
    次のRTPパケットに関係する前記第一のアプリケーション層情報は、RTPパケットの復号の用意をする装置の第一の抽出手段によって抽出されることができ、前記装置の第一の比較手段によって、前記装置の判別手段によって判別される次のRTPパケットに含まれる前記多層アプリケーションのアプリケーションデータの型と比較されることができ、
    直前のRTPパケットに関係する前記第二のアプリケーション層情報は、前記装置の第二の抽出手段によって抽出されることができ、前記装置の第二の比較手段によって、前記装置の判別手段によって判別される直前のRTPパケットに含まれる前記多層アプリケーションのアプリケーションデータの型と比較されることができ、
    前記第一および第二の抽出手段および前記第一および第二の比較手段の結果は前記多層アプリケーションのためのデコーダに提供されることができ、
    前記アプリケーション層情報が、次のRTPパケットおよび直前のRTPパケットのそれぞれについて、NAL型指示、品質情報、依存性情報、IDR番号およびピクチャー順カウント（picture order count）情報を含む、
    データ構造。
  2. 前記アプリケーション・データがスケーラブル・ビデオ・データであり、前記アプリケーション層がスケーラブル・ビデオ層である、請求項１記載のデータ構造。
  3. RTPパケットを使って多層アプリケーション・データをエンコードする方法であって、
    ・前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングする段階であって、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照する、段階と；
    ・少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケットのパディング・バイト内に加える段階であって、前記第一のデータおよび前記第二のデータが、前記第一のパケットのNAL型指示、前記第三のパケットのNAL型指示、
    前記第一のパケットの品質情報、前記第三のパケットの品質情報、前記第一のパケットの依存性情報、前記第三のパケットの依存性情報、前記第一のパケットのIDR番号、前記第三のパケットのIDR番号、前記第一のパケットのピクチャー順カウント情報および前記第三のパケットのピクチャー順カウント情報を含む、段階と；
    ・前記第一、第二および第三のRTPパケットをこの順序で送信する段階とを有する、
    方法。
  4. 前記第一のデータまたは前記第二のデータが、直前または直後のパケットのアプリケーション・データが一つまたは複数の特定のNAL型を参照することを示すフラグを含む、請求項３記載の方法。
  5. 多層アプリケーション・データを含むRTPパケットの復号の用意をする方法であって、
    ・少なくとも第一およびその後の第二のRTPパケットを受信する段階と；
    ・前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出する段階と；
    ・前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出する段階と；
    ・前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別する段階と；
    ・前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較する段階と；
    ・前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する段階と；
    ・前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する段階と；
    ・抽出および比較する前記諸段階の結果を前記多層アプリケーションのためのデコーダに提供する段階とを有する、
    方法。
  6. 前記第一及び第二のRTPパケット内の隣接情報が、NAL型指示、品質情報、予測依存性情報、IDR番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、請求項５記載の方法。
  7. RTPパケットを使って多層アプリケーション・データをエンコードする装置であって、
    ・前記多層アプリケーション・データの第一、第二および第三の部分を第一、第二および第三のRTPパケットにそれぞれパッキングする挿入手段であって、ここで、アプリケーション・データの前記第一、第二および第三の部分は前記アプリケーションの第一、第二および第三の層を参照する、手段と；
    ・少なくとも、前記第一のパケットが参照する前記アプリケーションの前記第一の層を定義する第一のデータおよび前記第三のパケットが参照する前記アプリケーションの前記第三の層を定義する第二のデータを前記第二のRTPパケットのパディング・バイト内に加える挿入手段であって、前記第一のデータおよび前記第二のデータが、前記第一のパケットのNAL型指示、前記第三のパケットのNAL型指示、前記第一のパケットの品質情報、前記第三のパケットの品質情報、前記第一のパケットの依存性情報、前記第三のパケットの依存性情報、前記第一のパケットのIDR番号、前記第三のパケットのIDR番号、前記第一のパケットのピクチャー順カウント情報および前記第三のパケットのピクチャー順カウント情報を含む、手段と；
    ・前記第一、第二および第三のRTPパケットをこの順序で送信する送信手段とを有する、
    装置。
  8. 多層アプリケーション・データを含むRTPパケットの復号の用意をする装置であって、
    ・少なくとも第一およびその後の第二のRTPパケットを受信する受信手段と；
    ・前記第一のRTPパケットのボディから前記多層アプリケーション・データの第一の部分を、前記第一のRTPパケットのパディング・バイトから第一の隣接情報を抽出する第一の抽出手段と；
    ・前記第二のRTPパケットのボディから前記多層アプリケーション・データの第二の部分を、前記第二のRTPパケットのパディング・バイトから第二の隣接情報を抽出する第二の抽出手段と；
    ・前記第一のRTPパケット内および前記第二のRTPパケット内の多層アプリケーション・データの型を判別する判別手段と；
    ・前記第二のRTPパケット内の多層アプリケーション・データの判別された型を前記第一のRTPパケットから抽出された前記第一の隣接情報と比較する第一の比較手段と；
    ・前記第一のRTPパケット内の多層アプリケーション・データの判別された型を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する第二の比較手段と；
    ・前記第一のRTPパケットから抽出された前記第一の隣接情報を前記第二のRTPパケットから抽出された前記第二の隣接情報と比較する第三の比較手段と；
    ・前記第一および第二の抽出手段ならびに前記第一、第二および第三の比較手段の結果を前記多層アプリケーションのためのデコーダに向けて提供する提供手段とを有する、
    装置。
  9. 前記第一および第二のRTPパケット内の隣接情報が、NAL型指示、品質情報、予測依存性情報、IDR番号およびピクチャー順カウント情報のうちの一つまたは複数を含む、請求項８記載の装置。
JP2009174653A 2008-07-28 2009-07-27 Ｒｔｐパケットを含むデータ・ストリームならびにそのようなデータ・ストリームをエンコード／デコードする方法および装置 Expired - Fee Related JP5686506B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08305424A EP2150022A1 (en) 2008-07-28 2008-07-28 Data stream comprising RTP packets, and method and device for encoding/decoding such data stream
EP08305424.7 2008-07-28

Publications (2)

Publication Number Publication Date
JP2010045775A JP2010045775A (ja) 2010-02-25
JP5686506B2 true JP5686506B2 (ja) 2015-03-18

Family

ID=40220088

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009174653A Expired - Fee Related JP5686506B2 (ja) 2008-07-28 2009-07-27 Ｒｔｐパケットを含むデータ・ストリームならびにそのようなデータ・ストリームをエンコード／デコードする方法および装置

Country Status (6)

Country Link
US (1) US20100020865A1 (ja)
EP (2) EP2150022A1 (ja)
JP (1) JP5686506B2 (ja)
KR (1) KR101650571B1 (ja)
CN (1) CN101640640B (ja)
TW (1) TWI497982B (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090161762A1 (en) * 2005-11-15 2009-06-25 Dong-San Jun Method of scalable video coding for varying spatial scalability of bitstream in real time and a codec using the same
CN102752670B (zh) * 2012-06-13 2015-11-25 广东威创视讯科技股份有限公司 减少网络视频传输中马赛克现象的方法、装置及系统
US20150288975A1 (en) * 2012-09-28 2015-10-08 Samsung Electronics Co., Ltd. Method and apparatus for encoding video and method and appartaus for decoding video for random access
US8959414B2 (en) * 2013-06-13 2015-02-17 Lsi Corporation Systems and methods for hybrid layer data decoding
CN105141961B (zh) * 2015-08-03 2017-12-22 中国人民解放军信息工程大学 一种基于视频隐写的空间数据双协议传输方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09247131A (ja) * 1996-03-07 1997-09-19 Toshiba Corp データ通信装置
CN1207860C (zh) * 1997-08-01 2005-06-22 Ntt移动通信网株式会社 数据序列发生器、发射机、信息数据解码器、接收机、发送－接收机、数据序列产生方法、信息数据解码方法
US20070192863A1 (en) * 2005-07-01 2007-08-16 Harsh Kapoor Systems and methods for processing data flows
KR100591350B1 (ko) * 2001-03-06 2006-06-19 가부시키가이샤 엔.티.티.도코모 오디오 데이터 보간장치 및 방법, 오디오 데이터관련 정보작성장치 및 방법, 오디오 데이터 보간 정보 송신장치 및방법, 및 그 프로그램 및 기록 매체
CN1602614A (zh) * 2001-12-11 2005-03-30 皇家飞利浦电子股份有限公司 通过网络发送附加信息的系统
US7061942B2 (en) * 2002-05-31 2006-06-13 Skystream Networks Inc. Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
JP2004056169A (ja) * 2002-07-16 2004-02-19 Matsushita Electric Ind Co Ltd 画像データ受信装置、画像データ送信装置
US20050275752A1 (en) * 2002-10-15 2005-12-15 Koninklijke Philips Electronics N.V. System and method for transmitting scalable coded video over an ip network
JP4336792B2 (ja) * 2003-03-13 2009-09-30 日本電気株式会社 パケット送信方法および無線アクセスネットワーク
JP4078544B2 (ja) * 2003-03-31 2008-04-23 サクサ株式会社 音声データの伝送装置および音声データの受信装置
US7447978B2 (en) * 2004-11-16 2008-11-04 Nokia Corporation Buffering packets of a media stream
DE102005001286A1 (de) * 2005-01-11 2006-07-20 Siemens Ag Verfahren und Vorrichtung zur Übertragung von skalierbaren Daten
AU2006223287C1 (en) * 2005-03-10 2010-10-21 Qualcomm Incorporated A decoder architecture for optimized error management in streaming multimedia
EP1773063A1 (en) * 2005-06-14 2007-04-11 Thomson Licensing Method and apparatus for encoding video data, and method and apparatus for decoding video data
EP1742476A1 (en) * 2005-07-06 2007-01-10 Thomson Licensing Scalable video coding streaming system and transmission mechanism of the same system
FR2898754B1 (fr) * 2006-03-17 2008-06-13 Thales Sa Procede de protection de donnees multimedia au moyen de couches d'abstraction reseau (nal) supplementaires
WO2008094279A1 (en) * 2006-06-06 2008-08-07 Cts Media A method and system for dynamic management of multiple media data streams
WO2008013528A1 (en) * 2006-07-25 2008-01-31 Thomson Licensing Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction
US20080040498A1 (en) * 2006-08-10 2008-02-14 Nokia Corporation System and method of XML based content fragmentation for rich media streaming
JP2009065259A (ja) * 2007-09-04 2009-03-26 Sanyo Electric Co Ltd 受信装置
JP2009118151A (ja) * 2007-11-06 2009-05-28 Fujitsu Ltd 通信システム、送信装置、中継装置、受信装置及び送信プログラム
WO2009127961A1 (en) * 2008-04-16 2009-10-22 Nokia Corporation Decoding order recovery in session multiplexing

Also Published As

Publication number Publication date
KR20100012830A (ko) 2010-02-08
TWI497982B (zh) 2015-08-21
US20100020865A1 (en) 2010-01-28
TW201006255A (en) 2010-02-01
CN101640640A (zh) 2010-02-03
CN101640640B (zh) 2014-01-29
EP2150022A1 (en) 2010-02-03
EP2150024B1 (en) 2016-05-18
EP2150024A1 (en) 2010-02-03
JP2010045775A (ja) 2010-02-25
KR101650571B1 (ko) 2016-08-23

Similar Documents

Publication Publication Date Title
TWI325706B (en) Method and apparatus for processing multimedia data
US10321200B2 (en) Transmission method, reception method, transmission apparatus, and reception apparatus
US7447978B2 (en) Buffering packets of a media stream
JP5296123B2 (ja) 帯域外ディレクトリ情報を使用するエラー耐性の改良
van der Meer et al. RTP payload format for transport of MPEG-4 elementary streams
US8432937B2 (en) System and method for recovering the decoding order of layered media in packet-based communication
US20090177952A1 (en) Transcoder and receiver
JP2003023413A (ja) システムデコーダ装置及びパケットデータの修正方法
KR20070083855A (ko) 내손실성 멀티미디어 멀티캐스팅 방법 및 시스템
JP5686506B2 (ja) Ｒｔｐパケットを含むデータ・ストリームならびにそのようなデータ・ストリームをエンコード／デコードする方法および装置
US9392082B2 (en) Communication interface and method for robust header compression of data flows
KR20050085247A (ko) 계층화된 미디어 비트스트림의 패킷화
US20230254546A1 (en) Transmission method, reception method, transmission apparatus, and reception apparatus
US7839925B2 (en) Apparatus for receiving packet stream
US8514887B2 (en) Method and apparatus for repairing samples included in container files having lost packets
US20090003429A1 (en) Apparatus And Method For Processing A Bitstream
US7428246B2 (en) Apparatus and method of packetizing data stream
Westin et al. RTP payload format for vp8 video
JP2007208418A (ja) 検査情報生成装置、送信装置及び中継装置
Meer et al. RFC3640: RTP Payload Format for Transport of MPEG-4 Elementary Streams
Weaver RTP Payload Format for VC-2 High Quality (HQ) Profile
Westin et al. RFC 7741: RTP Payload Format for VP8 Video
Downs et al. RFC 6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data
Downs et al. RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data
Hatanaka et al. RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120719

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130912

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20131001

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131226

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140724

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141224

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150120

R150 Certificate of patent or registration of utility model

Ref document number: 5686506

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees