JP2011503919A

JP2011503919A - 階層化マルチキャストにおける符号化アプリケーションデータユニットの順序回復

Info

Publication number: JP2011503919A
Application number: JP2010525484A
Authority: JP
Inventors: イェ‐クイワン; ミスカハンヌクセラ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2007-09-24
Filing date: 2008-09-23
Publication date: 2011-01-27
Also published as: MX2010003186A; CN101809967A; KR20100085070A; WO2009040723A2; EP2206314B1; US20090083434A1; US8352625B2; ZA201002835B; EP2206314A2; WO2009040723A3

Abstract

異なるリアルタイムプロトコル（Real Time Protocol; RTP）セッションにおいて伝達されるネットワーク抽象化層（network abstraction layer; NAL）ユニットの復号順序を受信機が回復することを可能にするシステムおよび方法が提供される。PACSI NALユニットが単一時間集合パケットタイプA（single-time aggregation packet type A; STAP-A）パケットであり、PACSI NALユニットが集合パケットにおいて最初のNALユニットである場合（例えば、受信機がNALユニットを伝達する異なるRTPセッションにサブスクライブしている場合）、各パケットにおけるアプリケーションデータユニット（application data unit; ADU）の復号順序に関する表示子は、PACSI NALユニットのパケット構造に含まれる。受信機が基層RTPセッションのみにサブスクライブしている場合、CL-DON表示子を無視することができる。
【選択図】図１

Description

本発明は、概して、ネットワークにおける階層化メディアのトランスポートに関する。より具体的には、本発明は、階層化マルチキャストトランスポートプロセスにおける復号順序情報の効果的な回復に関する。

背景

本項は、請求項に列挙する本発明の背景または内容を提供することを意図する。本項における説明は、達成し得る概念を含み得るが、必ずしも過去に着想または達成された概念ではない。したがって、本明細書において別途明示されない限り、本項に説明するものは、本出願における説明および請求項に対する従来技術ではなく、本項に含めることによって従来技術であるとは認められない。

マルチメディアアプリケーションには、ローカル再生、ストリーミングまたはオンデマンド、対話型およびブロードキャスト/マルチキャストサービス等のサービスが含まれる。マルチメディアアプリケーションに関与する技術には、とりわけ、メディア符号化、ストレージ、および伝送が含まれる。異なる技術には、異なる規格が規定されている。変動する帯域幅需要を有する映像通信システムでは、具体的には、階層符号化の使用が有益である。例えば、この特徴は、セッションのライフタイム中に接続速度の変化に対処可能である映像対応携帯電話機において特に有益であり得る。このような変化は、例えば、無線ローカルエリアネットワーク（Wireless Local Area Network; WLAN）から第3世代（third generation; 3G）ネットワーク、または3Gネットワークからモバイル通信のためのグローバルシステム（Global System for Mobile communications; GSM）ネットワークへのフォールバックに起因して必然的に生じ得る。階層符号化では、基層は、最も遅いリンク上であっても伝達可能であるように選択される。より高速のアクセス技術上で伝送される映像用の追加「エンハンスメント」層を追加することによって、映像品質の向上が可能になる。

映像規格化に関する最近の作業は、階層符号化概念によるITU-T Recommendation H.264の拡張である。この作業は、一般的に、「スケーラブル映像符号化（Scalable Video Coding; SVC）」として知られている。SVC規格に関する最新のドラフトについては、JVT-X201, 「Joint Draft 11 of SVC Amendment」, 24th JVT Meeting, Geneva, Switzerland, June- July 2007に記載されおり、
http://ftp3.itu.ch/av-arch/jvt-site/2007_06_Geneva/JVT-X201.zip
から入手でき、また、参照により本明細書にその全体が組み込まれる。

階層符号化構成では、一般的に、層の階層を観測することができる。所与の上位層では、典型的には、少なくとも1つの下位層が存在し、その上にその高位層が依存する。下位層からのデータが失われると、上位層のデータの重要度が大幅に低くなり、状況によっては全く無用になる。ゆえに、一定の層に属する層またはパケットを破棄する必要が有る場合、当然ながら、まず、上位層または上位層に属するパケットを破棄するか、または最低でも、このような破棄を下位層もしくは下位層に属するパケットを破棄する前に実行することが考えられる。

また、この階層符号化概念は、多視点映像符号化（multiview video coding; MVC）にも拡張でき、この場合、各視点を層として見なすことができ、また、各視点を複数のスケーラブル層により表すことができる。多視点映像符号化では、各々が視点に対応する異なるカメラから出力された映像シーケンスが、1つのビットストリームに符号化される。復号の後、一定の視点を表示するために、その視点に属する復号画像が表示される。MVCに関する最新のドラフトについては、http://ftp3.itu.ch/av-arch/jvt-site/2007_06_Geneva/JVT-X209.zipより入手できるJVT-X209, 「Joint Draft 4.0 on Multiview Video Coding」, Geneva, Switzerland, June- July 2007に記載されており、これは、参照により本明細書にその全体が組み込まれる。

階層化マルチキャストは、スケーラブル符号化ビットストリーム、例えば、SVCまたはMVCビットストリームのためのトランスポート技法である。インターネットプロトコル（Internet Protocol; IP）ネットワーク上のメディアのトランスポートのために一般的に使用される技法は、リアルタイムトランスポートプロトコル（Real-time Transport Protocol; RTP）として知られている。RTPを使用する階層化マルチキャストでは、スケーラブルビットストリームの層または層のサブセットは、それ自身のRTPセッションにおいてトランスポートされ、この場合、各RTPセッションは、マルチキャストグループに属する。受信機は、特定の層のビットストリームを受信するために、所望のRTPセッションまたはマルチキャストグループに参加またはサブスクライブすることができる。従来のRTPおよび階層化マルチキャストについては、例えば、http://www.ietf.org/rfc/rfc3550.txtにより入手できるH. Schulzrinne、S. Casner, S.、R. Frederick、およびV. Jacobson, 「RTP: A Transport Protocol for Real-Time Applications」, IETF STD 64, RFC 3550, July 2003、ならびにMcCanne、V. Jacobson、およびM. Vetterli, 「Receiver-driven layered multicast 」 in Proc. of ACM SIGCOMM'96, pp. 117-130, Stanford, CA, August 1996に記載されている。

H.264/AVC RTPペイロードフォーマットについては、http://www.ietf.org/rfc/rfc3984.txt.により入手できるRFC 3984に規定されている。RFC3984は、3つのパケット化モード、つまり、単一ネットワーク抽象化層（network abstraction layer; NAL）ユニットパケット化モード、非インターリーブパケット化モード、およびインターリーブパケット化モードについて規定する。インターリーブパケット化モードでは、パケットに含まれる各NALユニットは、NALユニット復号順序が導出可能になるように、復号順序番号（decoding order number; DON）関連フィールドに関連付けられる。一方、シングルNALユニットパケット化モードまたは非インターリーブパケット化モードを使用する際には、DON関連フィールドを利用することができない不可能である。SVC RTPペイロードフォーマットに関する最近のドラフトは、http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-02.txtにより入手できる。この最近のドラフトでは、ペイロードコンテンツスケーラビリティ情報（payload content scalability information; PACSI）NALユニットは、RTPパケットに含まれるNALユニットについて、他の種類の情報の中でも、スケーラビリティ情報を含むように規定される。

階層化マルチキャストでは、マルチRTPセッションにサブスクライブする受信機は、異なるRTPセッションから受信したNALユニットの復号順序を回復してから、NALユニットを復号器に伝える。しかしながら、異なるRTPセッション間のセッション開始変動、1つ以上のRTPセッション内におけるRFC3984に規定されるようなインターリーブパケット化モードの使用、ならびに出力順序または表示順序とは異なるNALユニット復号順序に起因して、NALユニット復号順序回復において複雑性が生じる。

SVC RTPペイロードフォーマットに関する最近のドラフトは、全RTPセッションにインターリーブパケット化モードの使用を求めることによって、クロスレイヤDON（CL-DON）とも呼ばれるSVCビットストリーム全体におけるDONを、NALユニット毎に確実に導出できるように試みる。さらに、最近のドラフトは、DON関連フィールドがCL-DONに基づいて導出されることを必要とする。しかしながら、現在存在しているいくつかのRFC3984型受信機は、その中にインターリーブパケット化モードが実装されていない。ゆえに、これらの受信機は、階層化マルチキャストに参加してサービスを受けることが不可能である。

種々の実施形態は、パケット構造に含まれる各パケットにおけるアプリケーションデータユニット（application data unit; ADU）のための復号順序に関する標示を提供する。例えば、PACSI NALユニットが、単一時間集合パケットタイプA（single-time aggregation packet type A; STAP-A）パケットに含まれる場合（STAP-AパケットはRFC3984に規定される）、CL-DONフィールドが、PACSI NALユニットに含められる。STAP-Aパケットの使用は、非インターリーブパケット化モードを特定のRTPセッションに使用していることを示す。受信機が、非インターリーブパケット化モードを使用するシングルRTPセッションのみにサブスクライブする場合、CL-DON表示子を無視することができる。しかし、非インターリーブパケット化モードを使用する少なくとも1つのRTPセッションを含むマルチRTPセッションに受信機が参加する場合、非インターリーブパケット化モードを使用するRTPセッションにおける各RTPパケットのCL-DON表示子を、他の（インターリーブパケット化モードを使用する）RTPセッションのパケットにおけるDONフィールドとともに利用して、全てのRTPセッションにおいて伝達されるNALユニットの復号順序を判断し、NALユニットを復号順序に適切に再順序化することができる。ゆえに、SVC RTPペイロードフォーマットに準拠して、かつ種々の実施形態に準拠して実装された受信機は、基層RTPセッションがインターリーブパケット化モードを使用しなくても、異なるRTPセッションで伝達されたNALユニットの復号順序を回復することができ、一方、基層RTPセッションのみにサブスクライブするRFC3984型受信機は、PACSI NALユニットを無視することができる。

本発明に関するこれらの利点および特徴ならびにその他の利点および特徴と、その動作の機構および方式とは、添付の図面を併用して、以下の発明を実施するための形態により明白になる。添付の図面では、いくつかの図面における同一要素は、同一の符号を付する。

種々の実施形態に従うPCSI NALユニット構造の図を示す。

種々の実施形態に従って実行されるプロセスを記述するフローチャートを示す。

種々の実施形態とともに使用するためのマルチメディア通信システムを示す。

本発明の実装に使用可能な携帯電話機の斜視図である。

図4の携帯電話機の電話機回路の略図である。

好ましい実施形態の詳細な説明

種々の実施形態は、インターリーブパケット化モード（interleaved packetization mode）を実装していない既存のRFC3984型受信機が、階層化マルチキャスト（layered multicast）に参加し、かつ基層（base layer）により提供されるサービスを受信することを可能にするシステムおよび方法を提供する。より具体的には、CL-DONフィールドが、PACSI NALユニットのヘッダに含められうる。したがって、種々の実施形態において、RTPパケット、例えば、非インターリーブパケット化モード（non-interleaved packetization mode）で使用可能なSTAP-Aパケットに含まれるNALユニットに、CL-DON情報を持たせることができる。この場合、STAP-Aは、同一のNALユニット時間でNALユニットを集合（アグリゲート）させる。ゆえに、SVC RTPペイロードフォーマットに従って、および種々の実施形態に従って構成された受信機は、基層RTPセッションがインターリーブパケット化モードを使用しない場合であっても、異なるRTPセッションにおいて伝達されるNALユニットの復号順序を回復することができ、一方、基層RTPセッションのみにサブスクライブするRFC3984型受信機は、PACSI NALユニットを無視することができる。

上述のように、CL-DONは、クロスレイヤ復号順序番号を示し、これは、例えば、SVC RTPペイロード構造におけるフィールド、またはSVCビットストリームをトランスポートするための全RTPセッションにおいてトランスポートされる全NALユニットにおけるNALユニット復号順序を表す導出変数を含むことができる。本明細書に説明する種々の実施形態が、RTPを使用するSVC技術に関連して提示されることに留意されたい。しかしながら、種々の実施形態のシステムおよび方法は、階層化マルチキャストを利用する系であって、任意の適切なトランスポートプロトコルを使用する、任意の階層化またはスケーラブルコーデックに適用できる。さらに、種々の実施形態のシステムおよび方法は、階層化マルチキャストではなくとも、別々の論理チャネルまたはパケットストリームを通ってスケーラブルメディアビットストリームの層を伝送する任意のトランスポート機構に適用できることに留意されたい。

SVCビットストリームの複数の層が、階層化マルチキャストのように複数のRTPセッション（マルチRTPセッション）でトランスポートされる場合、インターリーブパケット化モードを使用するRTPセッションにおける全NALユニットのDON値は、CL-DON値を示すことが必要とされる。さらに、SVCビットストリームの複数の層がマルチRTPセッションにおいてトランスポートされ、かつ少なくとも1つのSTAP-AパケットがRTPセッションのいずれかに存在する場合、一定の条件が適用される。

まず、PACSI NALユニットが、STAP-Aパケット毎に存在する。さらに、CL-DONフィールドが、STAP-Aパケット毎に含まれるPACSI NALユニットに存在する。さらに、STAP-Aパケット毎におけるNALユニットのためのDON値は、以下のように導出される。PACSI NALユニットにおけるCL-DONフィールドは、STAP-Aにおける、伝送順序に関して最初のNALユニットためのDONの値を規定する。（STAP-Aにおいて適切な順序で）続くNALユニットのDONの値は、それぞれ、（STAP-Aにおける前のNALユニットのDONの値+1）%65536に等しい。なお、「%」はモジュロ演算を意味する。

上述のように、PACSI NALユニットと呼ばれるNALユニットタイプは、種々の実施形態に従って達成される。PACSI NALユニットが存在する場合、それは集合パケットにおける最初のNALユニットであり、他のタイプのパケットには存在しない。PACSI NALユニットは、スケーラビリティ情報と、集合パケットのペイロードにおける残りのNALユニットに共通する他の特徴とを示す。さらに、PACSI NALユニットは、CL-DONフィールドを含むことができ、また、ゼロまたはそれ以上の追加拡張情報（supplemental enhancement information; SEI）NALユニットを含むことができる。ゆえに、PACSI NALユニットによって、メディアアウェアネットワーク要素（media aware network element; MANE）は、PACSI NALユニットを含む集合パケットを転送/処理/破棄するか否かを決定することが容易になる。例えば、送信機は、PACSI NALユニットを生成することができるが、受信機はそのユニットを無視することができる。一方、受信機は、効率的な集合パケット処理を可能にするヒントとしてPACSI NALユニットを使用することができる。PACSI NALユニットのNALユニットタイプは、SVC規格やRFC3984において規定されない値から選択することが可能であることに留意されたい。

集合パケット（aggregation packet）の最初の集合ユニット（aggregation unit）がPACSI NALユニットを含む場合、少なくとも1つの追加の集合ユニットが同一のパケットに存在するべきである。その集合パケットのRTPヘッダおよびペイロードヘッダフィールドは、その集合パケットにおける残りのNALユニットに従って設定される。PACSI NALユニットがマルチタイム集合パケット（multi-time aggregation packet; MTAP）に含まれる場合、PACSI NALユニットのDONは、集合パケット内の残りのNALユニットのうち復号順序における最初のNALユニットのDONと同一のDONを持つように設定される。

図1は、PACSI NALユニットの構造の図を示す。最初の4つのオクテット0、1、2、3は、従来の4バイトSVC NALユニットヘッダを含む最初の4つのオクテットと同一である。その後、2つの常に存在するオクテット、2つのオプショナル・オクテット、およびゼロまたはそれ以上のSEI NALユニットが続き、各SEI NALユニットに（ネットワークバイトオーダーにおいて）先行して、後続のNALユニットのサイズをバイトで標示する16ビットの符号無しサイズフィールドが存在する（それら2つのオクテットを排除し、SEI NALユニットのNALユニットタイプオクテットを含める）。図1は、例えば、2つのSEI NALユニットを含むPACSI NALユニット構造を示す。

CL-DONフィールドは、任意であり、PACSI NALユニットを含む集合パケットがSTAP-Aパケットである場合に存在する。CL-DONフィールドは、それが存在する場合、伝送順番により、STAP-Aにおける最初のNALユニットのためのCL-DONを表す。前述のように、PACSI NALユニットを含む集合パケットがSTAP-Aではない場合、CL-DONフィールドが存在する必要がないことに留意されたい。図1に示すPACSI NALユニットにおける他のフィールドの値は、最近のSVC RTPペイロードフォーマットドラフトに従って設定される。

種々の実施形態に従う符号化および/または復号に係る構成は、シングルNALユニットパケット化モードや非インターリーブパケット化モード、およびインターリーブパケット化モードのためのRFC3984において規定される共通のパケット化規則に加えて、一定のパケット化規則にも適合する。

SVCビットストリームの層がマルチRTPセッションでトランスポートされる場合、インターリーブパケット化モードを、RTPセッションの全てに使用するべきである。しかしながら、RTPセッションがインターリーブパケット化モードを使用しない場合、非インターリーブパケット化モードが使用され、すなわち、STAP-Aパケットが使用され、他のいかなるタイプのパケットも使用されない。さらに、各STAP-Aパケットは、PACSI NALユニットと、PACSI NALユニットに存在するCL-DONフィールドとを含む。ゆえに、H.264/AVC対応（完全）基層を伝達するセッションのための非インターリーブパケット化モードの使用が可能になり、結果として、インターリーブパケット化モードを実装しないRFC3984型受信機が、（完全）基層セッションにサブスクライブすることが可能になる。

別の実施形態では、RTPセッションがインターリーブパケット化モードを使用しないときはいつでも非インターリーブパケット化モードを使用する。一方で、任意のパケットタイプ、すなわち、STAP-A、分割ユニットタイプA（fragmentation unit type A; FU-A）、またはシングルNALユニットパケットが許容される。FU-AまたはシングルNALユニットパケットは、CL-DONフィールドを含まないため、FU-Aに含まれるNALユニットまたはシングルNALユニットパケットのためのCL-DONの値は、伝送順序において先行するNALユニットについて導出されたCL-DON値から、例えば、伝送順序において先行するNALユニットのためのCL-DON値に1を増分することによって計算される（65536による前述のモジュロ計算による）。別の実施形態では、STAP-Aは、CL-DONフィールドを含むことを必要とされない。代わりに、STAP-AにおけるPACSI NALユニット（該当する場合）に後続する最初のNALユニットのためのCL-DON値は、上記のFU-AまたはシングルNALユニットパケットのためのCL-DONとして導出される。

さらに、非VCL NALユニットは、その関連付けられるVCL NALユニットと同一のセッションにおいて伝達可能である。この特徴を達成するために、スケーラブルネスティングSEIメッセージに含まれ、かつ複数のセッションに適用可能なSEIメッセージは、複数のスケーラブルネスティングSEIメッセージに分離して含めることができる。したがって、CL-DON値は、最新のドラフトSVC規格において従来から規定されるように、これらのSEIメッセージの全てが別々のスケーラブルネスティングSEIメッセージに存在し、かつ対応するアクセスユニットの最初に含まれる場合に、もたらし得る値を示す。

種々の実施形態に従う符号化および/または復号に係る特徴は、RFC3984において規定される共通のパケット化規則に加え、非パケット化プロセスにも適合する。シングルRTPセッションのためには、通常、RFC3984において規定される共通の非パケット化プロセス（を少し変形して）適用可能であることに留意されたい。スケーラブルビットストリームを伝達するマルチRTPセッションを受信するための、非パケット化プロセスの適切な実装の例について、例えば、マルチRTPセッションにおいて伝達されるNALユニットのための非パケット化プロセスを用いて以下に記述する。シングルRTPセッションのシナリオと同様に、マルチRTPセッションの非パケット化によって、伝送のための順序から、NALユニットの復号のための順序に、NALユニットを再順序化することがもたらされる。ここで、「RTPセッション」は、NALユニットが非パケット化されるRTPセッションを意味する。

受信機は、受信機バッファを含み、受信機バッファを使用して、異なるセッション開始時間、伝送遅延ジッタを補償し、伝送（のための）順序からNALユニットの復号（のための）順序にNALユニットを再順序化する。RTPセッションの全てが同一時間に開始すること、ならびに伝送遅延ジッタが存在しないことを前提として、受信機動作を説明することに留意されたい。しかしながら、受信機は、異なるセッション開始時間および伝送遅延ジッタの両方が存在するシナリオにも対処可能である。例えば、受信機は、セッション開始変動バッファリング、伝送遅延ジッタバッファリング、および非セッション多重化バッファリングのために別々のバッファを備えることができ、ならびに/あるいは上述の全ての目的のために受信機バッファを使用することができる。さらに、受信機は、例えば、復号および再生の開始前に実行する追加の初期バファリングによって、セッション開始変動および伝送遅延ジッタをバッファリング動作において考慮することができる。

上述のように、マルチRTPセッションを使用してSVCビットストリームを伝達する場合、CL-DON値をNALユニット毎に導出することができる。これによって、RTPセッションがインターリーブパケット化モードを使用するか否かにかかわらず、RTPセッション毎に個々の逆インターリーブプロセスを行なわずにNALユニット復号順序回復処理を行うことが可能になる。セッション開始変動バッファおよび伝送遅延ジッタバッファを除外する場合、受信機バッファを、「非セッション多重化バッファ」（de-session-multiplexing buffer）と呼ぶことができる。残りのRTPセッションの全てにおいて伝達されるSVC層の存在を復号が必要とするSVC層を伝達するRTPセッション（逆インターリーブバッファに関連付けられる）のsprop-deint-buf-req media-typeパラメータの値以上になるように、非セッション多重化バッファのサイズをバイト数に関して設定することができる。このようなRTPセッションを「最高位RTPセッション」（highest RTP session）と呼ぶことができる。送信されるストリームの特性を受信機に提供可能なパラメータを「sprop」パラメータと呼ぶことに留意されたい。

受信機において2つのバッファリング状態、例えば、「初期バッファリング」（initial buffering）および「再生中バッファリング」（buffering while playing）が存在することに留意されたい。初期バッファリングは、RTPセッションの初期化時に発生することができる。初期バッファリングの後、復号および再生が開始し、再生中バッファリングモードを利用することができる。バッファリング状態にかかわらず、受信機は、非セッション多重化バッファにおいて、着信NALユニットを受信順序で格納することができる。すなわち、集合パケットのNALユニットは、非セッション多重化バッファに各々格納され、DONの値（この場合CL-DON）は、NALユニット毎に計算および格納される。しかしながら、DONとは異なる値を有するようにCL-DONを設定することができることに留意されたい。例えば、3つの層が存在する場合、各々は、NALユニットを1つのみ含む。この場合、3つのNALユニットのCL-DON値は、順序が正しい場合に限り{0, 1, 2}，{3, 10, 18}，・・・の値をとることができるが、任意の2つのNALユニットの間隔はフレキシブルにすることができる。

また、受信機の動作についても本明細書に説明される。この場合、初期バッファリングは、以下の条件のうちの少なくとも1つが満たされるまで続く。
・非セッション多重化バッファにおいてN個以上のVCL NALユニットが存在すること。ここで、定数Nは、1だけインクリメントされた、最高位RTPセッションの「オプションの（Optional）」sprop-interleaving-depth media typeパラメータの値を示す。
・最高位RTPセッションのsprop-max-don-diffが存在する場合、don_diff (m,n)が、最高位RTPセッションのsprop-max-don-diffの値を上回ること。ここで、nは、受信したNALユニットのうちでAbsDON（後述する）の最大値を有するNALユニットに対応し、mは、受信したNALユニットのうちでAbsDON（後述する）の最小値を有するNALユニットに対応する。
・初期バッファリングが、最高位RTPセッションの任意のsprop-init-buf-time media-typeパラメータの値以上の期間持続していること。

don_diffが、以下に規定される関数であることに留意されたい。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
DON(i)がNALユニットiの復号順序番号であるとする。

DON(m) == DON(n)である場合，don_diff(m,n) = 0

(DON(m) < DON(n)かつDON(n) - DON(m) < 32768)である場合，
don_diff(m,n) = DON(n) - DON(m)

(DON(m) > DON(n)かつDON(m) - DON(n) >= 32768)である場合，
don_diff(m,n) = 65536 - DON(m) + DON(n)

(DON(m) < DON(n)かつDON(n) - DON(m) >= 32768)である場合，
don_diff(m,n) = - (DON(m) + 65536 - DON(n))

(DON(m) > DON(n)かつDON(m) - DON(n) < 32768)である場合，
don_diff(m,n) = - (DON(m) - DON(n))
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

さらに、非セッション多重化バッファから除去されるNALユニットを、以下のように判断する。非セッション多重化バッファが少なくともN個のVCL NALユニットを含む場合、NALユニットは、非セッション多重化バッファから除去され、バッファがN-1個のVCL NALユニットを含むまで以下に規定する順序で復号器に伝えられる。最高位RTPセッションのsprop-max-don-diffが存在する場合、最高位RTPセッションのsprop-max-don-diffをdon_diff (m,n)が上回るNALユニットmの全ては、非セッション多重化バッファから除去され、かつ以下に規定の順序で復号器に伝えられる。ここで、nは、非セッション多重化バッファにおけるNALユニットのうちでAbsDONの最大値を有するNALユニットに対応する。

NALユニットが復号器に伝えられる順序は、以下のように規定される。PDONを、RTPセッションの開始時に0に初期化される変数とすると、DONの値に関連付けられるNALユニット毎に、DON間隔が計算される。NALユニットのDONの値がPDONの値を上回る場合、DON間隔は、DON-PDONに同等である。あるいは、DON間隔は、65535 - PDON + DON + 1に同等である。NALユニットは、DON間隔の昇順で復号器に引き渡される。いくつかのNALユニットがDON間隔の同一の値を共有する場合、NALユニットは、任意の順序で復号器に渡され得る。所望の数のNALユニットが復号器に渡されると、PDONの値は、復号器に渡された最終NALユニットのDONの値に設定される。

さらに、ペイロードフォーマットパラメータを使用して、ペイロードフォーマットの最適な特徴およびビットストリームの一定の特徴を選択することができる。これらのパラメータは、本明細書において、SVCコーデックのメディアタイプ登録の一部として規定されうる。また、これらのパラメータのRFC4566に規定のセッション記述プロトコル（Session Description Protocol; SDP）規格へのマッピングも、SDPを使用するアプリケーションに提供される。しかしながら、SDPを使用しない制御プロトコルと共に用いる同じようなパラメータを規定できることに留意されたい。

上述のまたは関連のメディアタイプパラメータを以下の通り規定する。
packetization-modeは、RTPパケットストリームの特性および受信機に実装された能力を伝達するパラメータである。構成ポイントを１つしか表すことができないため、複数のpacketization-modeに対応する能力が示される場合に、複数の構成ポイント（RTPペイロードタイプ）を使用しなければならないことに留意されたい。

packetization-modeの値が0に同等であるか、またはpacketization-modeが存在しない場合、RFC3984に規定されるシングルNALモードを使用しなければならない。ITU-T Recommendation H.241 [H.241]（RFC3984に記述する）を使用する規格において本モードを使用していることに留意されたい。packetization-modeの値が1に等しい場合、RFC3984に規定する非インターリーブモードを使用しなければならない。packetization-modeの値が2に等しい場合、RFC3984に規定するインターリーブモードを使用しなければならない。また、packetization-modeの値が、0から2（それぞれの値を含む）の範囲における整数でなければならないことに留意されたい。

sprop-interleaving-depthは、現在のRTPセッションが他のRTPセッションに依存せず、packetization-modeが存在しない場合は存在してはならないパラメータである。さらに、sporp-interleaving-depthパラメータは、packetization-modeの値が0または1に等しい場合は存在してはならない。このパラメータは、現在のRTPセッションが他のRTPセッションに依存する場合、またはpacketization-modeの値が2に等しい場合に存在しなければならない。さらに、sprop-interleaving-depthパラメータは、NALユニットストリームの特性を伝達する。これは、伝送における順序において、NALユニットストリームにおける任意のVCL NALユニットに先行するVCL NALユニットの最大数を規定し、また、復号における順序において、VCL NALユニットに後続するVCL NALユニットの最大数を規定する。したがって、NALユニットの復号順序回復のバッファサイズが少なくともsprop-interleaving-depth+1の値（VCL NALユニットに関する）である場合に、受信機がNALユニット復号順序を再構築することが確実になる。本明細書において、NALユニットストリームは、現在のRTPセッションにおいて伝達されるNALユニットの全てと、存在する場合に、現在のRTPセッションが依存する他のRTPセッションにおいて伝達されるNALユニットの全てとから成るNALユニットストリームを意味する。さらに、sprop-interleaving-depthの値は、0から32767（それぞれの値を含む）の範囲の整数でなければならない。

sprop-deint-buf-reqは、現在のRTPセッションが任意の他のRTPセッションに依存せず、packetization-modeが存在しない場合、またはpacketization-modeの値が0または1の場合には存在してはならないパラメータである。このパラメータは、現在のRTPセッションが任意の他のRTPセッションに依存する場合か、またはpacketization-modeの値が2に等しい場合に存在しなければならない。さらに、sprop-deint-buf-reqは、NALユニットストリームの逆インターリーブバッファの所要のサイズを伝達する。sprop-deint-buf-reqの値は、このような逆インターリーブバッファ（上述する）において必要とされる最大バッファ占有率（バイト単位）以上でなければならない。逆インターリーブバッファサイズがバイト単位で少なくともsprop-deint-buf-reqの値である場合、受信機が、インターリーブされたNALユニットをNALユニット復号順序に逆インターリーブすることを実行できることが確実になる。本明細書において、NALユニットストリームは、現在のRTPセッションにおいて伝達されるNALユニットの全てと、存在する場合、現在のRTPセッションが依存する他のRTPセッションにおいて伝達されるNALユニットの全てとから成るNALユニットストリームを意味する。sprop-deint-buf-reqの値は、0から4294967295（それぞれの値を含む）の範囲の整数でなければならない。sprop-deint-buf-reqパラメータが、逆インターリーブバッファのみの所要のサイズを標示することに留意されたい。ネットワークジッタが発生し得る場合、適切なサイズのジッタバッファも提供される。スケーラブルビットストリームがマルチRTPセッションにおいて伝達され、セッションが異なる時間に開始する場合、セッション開始変動量も、適切なサイズのバッファにより補償される。

sprop-init-buf-timeは、NALユニットストリームの特性を伝達するために使用され得るパラメータである。本明細書において、NALユニットストリームは、現在のRTPセッションにおいて伝達されるNALユニットの全てと、存在する場合、現在のRTPセッションが依存する他のRTPセッションにおいて伝達されるNALユニットの全てとから成るNALユニットストリームを意味する。本パラメータは、受信機が伝送順序からNALユニット復号順序を回復するために、その開始前に初期バッファリング時間を伝達する。本パラメータが、確実かつ瞬時に伝送され、伝送および復号が同一時系列であり、最初のパケットの到達時に復号が開始すると仮定すると、本パラメータの値は、（あるNALユニットの伝送時間-そのNALユニットの復号時間）の最大値である。sprop-init-buf-timeの値を規定する例は以下の通りである。

NALユニットストリームは、以下のインターリーブ順序で送信される。その値は、復号時間に対応し、伝送順序は左から右である。
0 2 1 3 5 4 6 8 7 ...
NALユニットの伝送速度が安定していることを仮定すると、伝送時間は、
0 1 2 3 4 5 6 7 8 ...
である。
伝送時間から復号時間を列方向で減算すると、以下の一連の結果となる。
0 -1 1 0 -1 1 0 -1 1 ...
したがって、NALユニット伝送時間の間隔に関し、本例では、sprop-init-buf-timeの値は1である。

sprop-init-buf-timeパラメータは、90-kHzクロックのクロックチックで、非負の10進法の整数表現として符号化される。当該パラメータが存在しない場合、初期バッファリング時間値は定義されない。あるいは、sprop-init-buf-timeの値は、0から4294967295（それぞれの値を含む）の範囲における整数でなければならない。伝達されたsprop-init-buf-timeに加え、受信機は、混合器、トランスレータ、ゲートウェイ、プロキシ、トラフィックシェーバ、および他のネットワーク要素に起因する遅延ジッタのためのバッファリングを含む伝送遅延ジッタバッファリングを考慮するべきである。受信機が考慮するべきさらに別の側面は、スケーラブルビットストリームが複数のセッションにおいて伝達される際のセッション開始変動量であり、当該変動量をバッファリングすることを含む。

sprop-max-don-diffパラメータを使用して、NALユニットストリームの特性を伝達することができる。しかしながら、本パラメータを、送信機または受信機またはコーデックの能力を伝えるためには使用しない。sprop-max-don-diffパラメータは、0から3267（それぞれの値を含む）の範囲における整数である。sprop-max-don-diffが存在しない場合、パラメータの値は規定されない。前述のように、本明細書において、NALユニットストリームは、現在のRTPセッションにおいて伝達されるNALユニットの全てと、存在する場合、現在のRTPセッションが依存する他のRTPセッションにおいて伝達されるNALユニットの全てとから成るNALユニットストリームを意味する。

sprop-max-don-diffパラメータは、以下のように計算される：

任意のiおよび任意のj>iに対して、sprop-max-don-diff = max{AbsDON(i) -AbsDON(j)}である。

iおよびjは伝送順序におけるNALユニットのインデックスを表し、AbsDONはNALユニットの復号順序を示す。AbsDONは、65535の後に0にラップアラウンドしない。

すなわち、AbsDONは、以下のように計算される：

mおよびnを、伝送順序における連続したNALユニットとする。伝送順序における最初のNALユニット(インデックスが0)では、AbsDON(0) = DON(0)である。他のNALユニットについては、AbsDONは以下のように計算される：

DON(m) == DON(n)の場合、AbsDON(n) = AbsDON(m)であり、

(DON(m) < DON(n)かつDON(n) - DON(m) < 32768)の場合、AbsDON(n) = AbsDON(m) + DON(n) - DON(m)であり、

(DON(m) > DON(n)かつDON(m) - DON(n) >= 32768)の場合、AbsDON(n) = AbsDON(m) + 65536 - DON(m) + DON(n)であり、

(DON(m) < DON(n)かつDON(n) - DON(m) >= 32768)の場合、 AbsDON(n) = AbsDON(m) - (DON(m) + 65536 -DON(n))であり、

(DON(m) > DON(n)かつDON(m) - DON(n) < 32768)の場合、AbsDON(n) = AbsDON(m) - (DON(m) - DON(n))である。

ここで、DON(i)は、伝送順序におけるインデックスiを有するNALユニットの復号順序番号である。

受信機がsprop-max-don-diffを使用して、受信機バッファにおいてどのNALユニットを復号器に伝えることが可能であるかをトリガすることができることに留意されたい。

図2は、スケーラブル符号化ビットストリームを送信/符号化および/または受信/復号するために、メディアストリームをトランスポートパケットにパケット化および非パケット化する方法を実現するために、種々の実施形態に従って実行されるプロセスを示すフローチャートである。200において、アプリケーションデータユニット（application data unit; ADU）のための復号順序に関する表示子が、各パケットのパケット構造に含められる。すなわち、上述のように、例えば、PACSI NALユニットがSTAP-Aパケットに含まれる場合に、CL-DONフィールドがPACSI NALユニットに含められる。受信機が、非インターリーブパケット化モードを使用するシングルRTPセッションのみにサブスクライブする場合、CL-DON表示子は、非インターリーブパケット化モードと併用する第1の非パケット化プロセスによって無視可能である（210）。第1の非パケット化プロセスは、例えば、STAP-Aに含まれる各ADUを識別し、それらをSTAP-Aから非カプセル化し、その伝送順序でADUを復号処理に渡してもよい。しかしながら、受信機が、マルチRTPセッションにサブスクライブ/参加している場合、非インターリーブパケット化モードを使用するRTPセッションにおける各RTPパケットのCL-DON表示子を、他の（インターリーブパケット化モードを利用する）RTPセッションのパケットにおけるDONフィールドともに利用して、全てのRTPセッションにおいて伝達されるNALユニットの復号順序を判断し、NALユニットを適切に再順序化することができる。

図3は、本発明とともに使用するための汎用マルチメディア通信システムを示す。図3に示すように、データソース300は、アナログフォーマット、非圧縮デジタルフォーマット、または圧縮デジタルフォーマット、あるいはこれらのフォーマットの任意の組み合わせでソース信号を提供する。符号器310は、ソース信号を、符号化メディアビットストリームに符号化する。符号器310は、音声および映像等の複数のメディアタイプを符号化可能であってもよく、または複数の符号器310が、異なるメディアタイプのソース信号を符号化するために必要とされてもよい。また、符号器310は、グラフィックスおよびテキスト等を合成して生成した入力を入手してもよく、または、合成メディアの符号化ビットストリームを生成可能であってもよい。以下において、説明を簡略化するために、1つのメディアタイプの1つの符号化メディアビットストリームの処理のみについて考察する。しかしながら、典型的には、リアルタイムブロードキャストサービスが、いくつかのストリーム（典型的には、少なくとも1つの音声、映像、およびテキストサブタイトルストリーム）を含むことに留意されたい。また、システムが、多数の符号器を含んでもよいが、以下において、一般性を欠如することなく説明を簡略化するために、考察される符号器310が1つだけであることに留意されたい。

本明細書に含まれるテキストおよび例は、符号化プロセスを具体的に説明し得るが、同一の概念および原理が、対応する復号プロセスにも適用すること、およびその逆も同様であることを当業者が理解することを理解されたい。

符号化メディアビットストリームは、ストレージ320に転送される。ストレージ320は、符号化メディアビットストリームを格納するために、任意の種類の大容量メモリを備え得る。ストレージ320における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマットであってもよく、または1つ以上の符号化メディアビットストリームは、コンテナファイルにカプセル化されてもよい。いくつかのシステムは、「ライブ」で動作し、すなわち、ストレージを省略して、符号化メディアビットストリームを符号器310から送信機330に直接転送する。次いで、符号化メディアビットストリームは、必要に応じて送信機330（サーバとも呼ばれる）に転送される。伝送に使用するフォーマットは、エレメンタリ自立型ビットストリームフォーマット、パケットストリームフォーマットであってもよく、または1つ以上の符号化メディアビットストリームは、コンテナファイルにカプセル化されてもよい。符号器310、ストレージ320、および送信機330は、同一の物理的機器に存在してもよく、または別々の機器に含まれてもよい。符号器310および送信機330は、ライブリアルタイムコンテンツと共に動作してもよく、この場合、符号化メディアビットストリームは、典型的には、永久的に格納されないが、コンテンツ符号器310および/または送信機330において短期間バッファリングされて、処理遅延、転送遅延、および符号化メディアビットレートにおける変動を平滑化する。

送信機330は、通信プロトコルスタックを使用して符号化メディアビットストリームを送信する。スタックには、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol; RTP）、ユーザデータグラムプロトコル（User Datagram Protocol; UDP）、およびインターネットプロトコル（Internet Protocol; IP）が含まれてもよいが、これらに限定されない。通信プロトコルスタックがパケット指向型である場合、送信機330は、符号化メディアビットストリームをパケットにカプセル化する。例えば、RTPを使用する場合、送信機330は、RTFペイロードフォーマットに準拠して、符号化メディアビットストリームをRTPパケットにカプセル化する。典型的には、各メディアタイプは、専用RTPペイロードフォーマットを有する。前述のように、システムが、複数の送信機330を含んでもよいが、簡略化するために、以下の説明では1つの送信機130についてのみ考察することに留意されたい。

送信機330は、通信ネットワークを介してゲートウェイ340に接続されてもよく、または接続されなくてもよい。ゲートウェイ340は、一方向通信プロトコルスタックに準拠するパケットストリームの別の通信プロトコルスタックへの変換、データストリームの統合および分岐、ならびに一般的なダウンリンクネットワーク条件に準拠して転送されるストリームのビットレートの制御等の、ダウンリンク能力および/または受信機能力に準拠するデータストリームの操作等の、異なる種類の機能を実行し得る。ゲートウェイ340の例として、多地点会議制御ユニット（multipoint conference control unit; MCU）、回路交換およびパケット交換映像電話間のゲートウェイ、プッシュトゥートークオーバーセルラ（Push-to-talk over Cellular; PoC）サーバ、デジタル映像ブロードキャストハンドヘルド（digital video broadcasting-handheld; DVB-H）システムにおけるIPエンカプスレータ、または家庭用無線ネットワークへ局所的にブロードキャスト伝送を転送するセットトップボックスが挙げられる。RTPを使用する場合、ゲートウェイ340は、RTP混合器であり、RTP接続の終点としての役割を果たし得る。

システムは、1つ以上の受信機350を含み、受信機350は、典型的には、伝送された信号を受信し、復調し、符号化メディアビットストリームを非カプセル化することができる。符号化メディアビットストリームは、典型的には、復号器360によってさらに処理され、その出力は、1つ以上の非圧縮メディアストリームである。最後に、レンダラ370は、例えば、拡声器またはディスプレイにより非圧縮メディアストリームを再現し得る。受信機350、復号器360、およびレンダラ370は、同一の物理的機器に存在してもよく、または別々の機器に含まれてもよい。

復号されるビットストリームが、事実上任意のタイプのネットワーク内に位置する遠隔機器から受信できることに留意されたい。さらに、ビットストリームは、ローカルハードウェアまたはソフトウェアから受信できる。

ビットレート、復号複雑性、およびピクチャサイズに関するスケーラビリティは、異機種環境および誤りを起こし易い環境に望ましい特性である。本特性は、受信機器におけるビットレート、ディスプレイ解像度、ネットワークスループット、および計算能力に関する拘束等の制限を無効にするために望ましい。

本発明の通信機器は、種々の伝送技術を使用して通信してもよく、この通信技術には、符号分割多元接続（Code Division Multiple Access; CDMA）、モバイル通信のためのグローバルシステム（Global System for Mobile Communications; GSM）、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System; UMTS）、時分割多元接続（Time Division Multiple Access; TDMA）、周波数分割多元接続（Frequency Division Multiple Access; FDMA）、伝送制御プロトコル/インターネットプロトコル（Transmission Control Protocol/Internet Protocol; TCP/IP）、ショートメッセージサービス（Short Messaging Service; SMS）、マルチメディアメッセージサービス（Multimedia Messaging Service; MMS）、電子メール、インスタントメッセージサービス（Instant Messaging Service; IMS）、Bluetooth、IEEE 802.11等が含まれるが、これらに限定されない。通信機器は、無線接続、赤外線接続、レーザ接続、ケーブル接続、およびその同等物を含むがこれらに限定されない種々の媒体を使用して通信し得る。

図4および図5は、本発明が実装され得る1つの代表的なモバイル機器12を示す。しかしながら、本発明が、1つの特定のタイプのモバイル機器12または他の電子機器に限定されるように意図されないことを理解されたい。図4および図5に示す特徴の一部または全部が、図1に示す機器の任意の機器または全ての機器に組み込まれ得る。

図4および図5のモバイル機器12は、ハウジング30、液晶ディスプレイ形式のディスプレイ32、キーパッド34、マイクロホン36、イヤホン38、バッテリ40、赤外線ポート42、アンテナ44、本発明の一実施形態に従うUICC形式のスマートカード46、カード読み取り器48、無線インターフェース回路52、コーデック回路54、制御器56、およびメモリ58を含む。個々の回路および要素は、全て、当技術分野において、例えば、ノキアの種類の携帯電話機において周知のタイプである。

Claims

メディアストリームをトランスポートパケットにパケット化する方法であって、
アプリケーションデータユニットが複数のトランスポートセッションにおいて伝達されるか否かを判断することと、
前記アプリケーションデータユニットが前記複数のトランスポートセッションにおいて伝達されることが判断されると、第1のトランスポートセッションのトランスポートパケットに第1の復号順序表示子を含めると共に、第2のトランスポートセッションのトランスポートパケットに第2の復号順序表示子を含めることと、
を含み、前記第1の復号順序表示子および前記第2の復号順序表示子は、前記メディアストリームにおける前記アプリケーションデータユニットの復号順序を表す少なくとも1つの値を含み、前記第1の復号順序表示子は、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションが無い場合に不必要であるように示される、方法。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項1に記載の方法。
前記トランスポートパケットは、リアルタイムトランスポートプロトコルに準拠して形成される、請求項1に記載の方法。
前記復号順序表示子は、前記少なくとも1つのトランスポートパケットのペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットに含まれる、請求項1に記載の方法。
前記ペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットは、前記少なくとも1つのトランスポートパケットにおける最初のネットワーク抽象化層ユニットであり、前記少なくとも1つのトランスポートパケットは、集合パケットを含む、請求項4に記載の方法。
前記アプリケーションデータユニットは、少なくとも部分的に、ネットワーク抽象化層ユニットから構成される、請求項1に記載の方法。
前記メディアストリームは、前記複数のトランスポートセッションのうちの単一のトランスポートセッションの1つにサブスクライブする受信機によって受信され、前記受信機は、前記復号順序表示子を無視する、請求項1に記載の方法。
前記複数のトランスポートセッションの各々は、非インターリーブパケット化モードおよびインターリーブパケット化モードのうちの1つを利用する、請求項1に記載の方法。
請求項1に記載のプロセスを実行するように構成されたコンピュータコードを備えるコンピュータ可読媒体によって具現化されるコンピュータプログラム製品。
プロセッサと、
前記プロセッサに通信可能に接続されるメモリユニットと、
を備え、前記メモリユニットが、
アプリケーションデータユニットが複数のトランスポートセッションにおいて伝達されるか否かを判断するように構成されたコンピュータコードと、
前記アプリケーションデータユニットが前記複数のトランスポートセッションにおいて伝達されることが判断されると、メディアストリームをパケット化するために、第1のトランスポートセッションのトランスポートパケットに第1の復号順序表示子を含めると共に、第2のトランスポートセッションのトランスポートパケットに第2の復号順序表示子を含めるように構成されたコンピュータコードと、
を含み、前記第1の復号順序表示子および前記第2の復号順序表示子は、前記メディアストリームにおいてトランスポートされる前記アプリケーションデータユニットの復号順序を表す少なくとも1つの値を含み、前記第1の復号順序表示子は、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションが無い場合に不必要であるように示される、
装置。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項10に記載の装置。
前記メモリユニットは、リアルタイムトランスポートプロトコルに準拠して、前記トランスポートパケットを形成するように構成されたコンピュータコードをさらに備える、請求項10に記載の装置。
前記メモリユニットは、前記少なくとも1つのトランスポートパケットのペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットに前記復号順序表示子を含めるように構成されたコンピュータコードをさらに備える、請求項10に記載の装置。
前記ペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットは、前記少なくとも1つのトランスポートパケットにおける最初のネットワーク抽象化層ユニットであり、前記少なくとも1つのトランスポートパケットは、集合パケットを含む、請求項13に記載の装置。
前記アプリケーションデータユニットは、少なくとも部分的に、ネットワーク抽象化層ユニットから構成される、請求項10に記載の装置。
前記メディアストリームは、前記複数のトランスポートセッションのうちの単一のトランスポートセッションの1つにサブスクライブする受信機によって受信され、前記受信機は、前記復号順序表示子を無視する、請求項10に記載の装置。
前記複数のトランスポートセッションの各々は、非インターリーブパケット化モードおよびインターリーブパケット化モードのうちの1つを利用する、請求項10に記載の装置。
アプリケーションデータユニットが複数のトランスポートセッションにおいて伝達されるか否かを判断する手段と、
前記アプリケーションデータユニットが前記複数のトランスポートセッションにおいて伝達されることが判断されると、メディアストリームをパケット化するために、第1のトランスポートセッションのトランスポートパケットに第1の復号順序表示子を含めると共に、第2のトランスポートセッションのトランスポートパケットに第2の復号順序表示子を含める手段と、
を有し、前記復号順序表示子は、前記メディアストリームにおいてトランスポートされる前記アプリケーションデータユニットの復号順序を表す少なくとも1つの値を含み、前記第1の復号順序表示子は、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションが無い場合に不必要であるように示される、装置。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項18に記載の装置。
トランスポートパケットをメディアストリームに非パケット化する方法であって、
第1の復号順序表示子を含む第1のトランスポートセッションのトランスポートパケットと、第2の復号順序表示子を含む第2のトランスポートセッションのトランスポートパケットとを受信することと、
前記第1のトランスポートセッションのトランスポートパケットのアプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッション無しで伝達されたことが判断されると、第1の非パケット化プロセスによって前記復号順序表示子を無視することと、
前記第1のトランスポートパケットの前記アプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションと共に伝達されたことが判断されると、第2の非パケット化プロセスにおいて前記復号順序表示子を利用して、前記メディアストリームにおいてトランスポートされた前記アプリケーションユニットの復号順序をさらに判断することと、
を含む、方法。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項20に記載の方法。
前記トランスポートパケットは、リアルタイムトランスポートプロトコルに準拠して形成される、請求項20に記載の方法。
前記復号順序表示子は、前記少なくとも1つのトランスポートパケットのペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットに含まれる、請求項20に記載の方法。
前記ペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットは、前記少なくとも1つのトランスポートパケットにおける最初のネットワーク抽象化層ユニットであり、前記少なくとも1つのトランスポートパケットは、集合パケットを含む、請求項23に記載の方法。
前記アプリケーションデータユニットは、少なくとも部分的に、ネットワーク抽象化層ユニットから構成される、請求項20に記載の方法。
前記メディアストリームは、前記複数のトランスポートセッションのうちの単一のトランスポートセッションの1つにサブスクライブする受信機によって受信され、前記受信機は、前記復号順序表示子を無視する、請求項20に記載の方法。
前記複数のトランスポートセッションは、非インターリーブパケット化モードおよびインターリーブパケット化モードを利用する、請求項20に記載の方法。
前記第1の非パケット化プロセスは、前記非インターリーブパケット化モードと併用される非パケット化プロセスを含む、請求項27に記載の方法。
前記第2の非パケット化プロセスは、前記インターリーブパケット化モードと併用される非パケット化プロセスを含む、請求項27に記載の方法。
請求項20に記載のプロセスを実行するように構成されたコンピュータコードを備えるコンピュータ可読媒体によって具現化されるコンピュータプログラム製品。
プロセッサと、
前記プロセッサに通信可能に接続されるメモリユニットと、
を備え、前記メモリユニットが、
第1の復号順序表示子を含む第1のトランスポートセッションのトランスポートパケットと、第2の復号順序表示子を含む第2のトランスポートセッションのトランスポートパケットとを受信するように構成されたコンピュータコードと、
前記第1のトランスポートセッションのトランスポートパケットのアプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッション無しで伝達されたことが判断されると、第1の非パケット化プロセスによって前記復号順序表示子を無視するように構成されたコンピュータコードと、
前記第1のトランスポートセッションのトランスポートパケットのアプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションと共に伝達されたことが判断されると、第2の非パケット化プロセスにおいて前記復号順序表示子を利用して、前記メディアストリームにおいてトランスポートされた前記アプリケーションユニットの復号順序をさらに判断するように構成されたコンピュータコードと、
を含む、装置。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項31に記載の装置。
前記メモリユニットは、リアルタイムトランスポートプロトコルに準拠して前記トランスポートパケットを形成するように構成されたコンピュータコードをさらに備える、請求項31に記載の装置。
前記メモリユニットは、前記少なくとも1つのトランスポートパケットのペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットに前記復号順序表示子を含めるように構成されたコンピュータコードをさらに備える、請求項31に記載の装置。
前記ペイロードコンテンツスケーラビリティ情報ネットワーク抽象化層ユニットは、前記少なくとも1つのトランスポートパケットにおける最初のネットワーク抽象化層ユニットであり、前記少なくとも1つのトランスポートパケットは、集合パケットを含む、請求項34に記載の装置。
前記アプリケーションデータユニットは、少なくとも部分的に、ネットワーク抽象化層ユニットから構成される、請求項31に記載の装置。
前記メディアストリームは、前記複数のトランスポートセッションのうちの単一のトランスポートセッションの1つにサブスクライブする受信機によって受信され、前記受信機は、前記復号順序表示子を無視する、請求項31に記載の装置。
前記複数のトランスポートセッションは、非インターリーブパケット化モードおよびインターリーブパケット化モードのうちの1つを利用する、請求項31に記載の装置。
前記第1の非パケット化プロセスは、前記非インターリーブパケット化モードと併用される非パケット化プロセスを含む、請求項38に記載の装置。
前記第2の非パケット化プロセスは、前記インターリーブパケット化モードと併用される非パケット化プロセスを含む、請求項38に記載の装置。
第1の復号順序表示子を含む第1のトランスポートセッションのトランスポートパケットと、第2の復号順序表示子を含む第2のトランスポートセッションのトランスポートパケットとを受信する手段と、
前記第1のトランスポートセッションのトランスポートパケットのアプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッション無しで伝達されたことが判断されると、第1の非パケット化プロセスによって前記復号順序表示子を無視する手段と、
前記第1のトランスポートパケットの前記アプリケーションデータユニットが、前記第2のトランスポートセッションのトランスポートパケットを含む第2のトランスポートセッションと共に伝達されたことが判断されると、第2の非パケット化プロセスにおいて前記復号順序表示子を利用して、前記メディアストリームにおいてトランスポートされた前記アプリケーションユニットの復号順序をさらに判断する手段と、
を備える、装置。
前記メディアストリームは、スケーラブル映像ビットストリームである、請求項41に記載の装置。