特許 6800747 改善されたＲＴＰペイロードフォーマット設計

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6800747

(24)【登録日】2020年11月27日

(45)【発行日】2020年12月16日

(54)【発明の名称】改善されたＲＴＰペイロードフォーマット設計

(51)【国際特許分類】

   H04N 21/438 20110101AFI20201207BHJP

   H04L 12/70 20130101ALI20201207BHJP

   H04L 12/953 20130101ALI20201207BHJP

   H04N 19/70 20140101ALI20201207BHJP

【ＦＩ】

   H04N21/438

   H04L12/70 E

   H04L12/953

   H04N19/70

【請求項の数】14

【全頁数】36

(21)【出願番号】特願2016-505609(P2016-505609)

(86)(22)【出願日】2014年3月28日

(65)【公表番号】特表2016-519887(P2016-519887A)

(43)【公表日】2016年7月7日

(86)【国際出願番号】US2014032235

(87)【国際公開番号】WO2014160971

(87)【国際公開日】20141002

【審査請求日】2017年2月28日

【審判番号】不服2019-7650(P2019-7650/J1)

【審判請求日】2019年6月10日

(31)【優先権主張番号】61/806,705

(32)【優先日】2013年3月29日

(33)【優先権主張国】US

(31)【優先権主張番号】14/228,139

(32)【優先日】2014年3月27日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(72)【発明者】

【氏名】ワン、イェ−クイ

【合議体】

【審判長】 清水 正一

【審判官】 川崎 優

【審判官】 樫本 剛

(56)【参考文献】

【文献】 Ｔ．Ｓｃｈｉｅｒｌ，ｅｔ ａｌ．，ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ ｄｒａｆｔ−ｓｃｈｉｅｒｌ−ｐａｙｌｏａｄ−ｒｔｐ−ｈ２６５−０１．ｔｘｔ，Ａｕｄｉｏ／Ｖｉｄｅｏ Ｐａｙｌｏａｄ ＷＧ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ Ｏｃｔｏｂｅｒ ２２， ２０１２

【文献】 Ｙ．−Ｋ．Ｗａｎｇ，ｅｔ ａｌ．，ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｈ．２６４ Ｖｉｄｅｏ， Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ：６１８４， Ｍａｙ ２０１１

【文献】 Ｓ．Ｗｅｎｇｅｒ，ｅｔ ａｌ．， ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒｍａｔ ｆｏｒ Ｓｃａｌａｂｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ， Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ） Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ：６１９０， Ｍａｙ ２０１１

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04N 19/00-19/98,21/00-858,H04L 12/70-955

(57)【特許請求の範囲】

【請求項1】

ビデオデータを処理する方法であって、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、前記第１のＲＴＰパケットは、ＲＴＰヘッダとペイロードとを含み、前記ペイロードは、ＲＴＰパケットの相対的重要度を示すＴＩＤ値を備えるペイロードヘッダを含み、より重要なＮＡＬユニットは、より重要でないＮＡＬユニットよりも、送信ロスに対してより良く保護され、 前記ＲＴＰパケットに関する送信モードを示す送信モードパラメータを受信することと、
第１のパラメータが第１の値に等しいかどうかを決定することと、ここにおいて、前記第１のパラメータは、受信順序においてパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序において前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定し、
前記第１のＲＴＰパケットに関する前記送信モードがシングルセッション送信モードであることおよび前記第１のパラメータが前記第１の値に等しいことに応答して、前記第１のＮＡＬユニットの送信順序に基づいて前記第１のＮＡＬユニットに関する復号順序番号を決定することと、
を備える、方法。

【請求項2】

前記復号順序番号が、送信順序番号に等しい、請求項１に記載の方法。

【請求項3】

第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＮＡＬユニットに関する復号順序番号が前記第１のＮＡＬユニットに関する前記復号順序番号に等しいことに応答して、前記第１のＮＡＬユニットを復号する前に前記第２のＮＡＬユニットを復号することと、
をさらに備える、請求項１に記載の方法。

【請求項4】

前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、請求項１に記載の方法。

【請求項5】

ビデオデータを処理する方法であって、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを生成することと、前記第１のＲＴＰパケットは、ＲＴＰヘッダとペイロードとを含み、前記ペイロードは、ＲＴＰパケットの相対的重要度を示すＴＩＤ値を備えるペイロードヘッダを含み、より重要なＮＡＬユニットは、より重要でないＮＡＬユニットよりも、送信ロスに対してより良く保護され、
前記ＲＴＰパケットに関する送信モードを示す送信モードパラメータを送信することと、
第１のパラメータが第１の値に等しいかどうかを決定することと、ここにおいて、前記第１のパラメータは、受信順序においてパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序において前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定し、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットに関する復号順序に基づいて前記第１のＮＡＬユニットに関する送信順序を設定することと、
を備える、方法。

【請求項6】

前記第１の値が０に等しい、請求項１または請求項５に記載の方法。

【請求項7】

前記最大数が３２７６７に等しい、請求項１または請求項５に記載の方法。

【請求項8】

前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、請求項５に記載の方法。

【請求項9】

ビデオデータを処理するためのデバイスであって、装置が、
メモリと、
リアルタイムトランスポートプロトコル（ＲＴＰ）パケットのために構成された受信機と、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、前記第１のＲＴＰパケットは、ＲＴＰヘッダとペイロードとを含み、前記ペイロードは、ＲＴＰパケットの相対的重要度を示すＴＩＤ値を備えるペイロードヘッダを含み、より重要なＮＡＬユニットは、より重要でないＮＡＬユニットよりも、送信ロスに対してより良く保護され、
前記ＲＴＰパケットに関する送信モードを示す送信モードパラメータを受信することと、
第１のパラメータが第１の値に等しいかどうかを決定することと、ここにおいて、前記第１のパラメータは、受信順序においてパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序において前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定し、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットの送信順序に基づいて前記第１のＮＡＬユニットに関する復号順序番号を決定することと、
を行うように構成された１つまたは複数のプロセッサと、
を備える、デバイス。

【請求項10】

前記第１の値が０に等しい、請求項９に記載のデバイス。

【請求項11】

前記最大数が３２７６７に等しい、請求項９に記載のデバイス。

【請求項12】

前記復号順序番号が、送信順序番号に等しい、請求項９に記載のデバイス。

【請求項13】

前記デバイスが、
集積回路と、
マイクロプロセッサと、
ビデオコーダを備えるワイヤレス通信デバイスと、
のうちの少なくとも１つを備える、請求項９に記載のデバイス。

【請求項14】

命令を記憶するコンピュータ可読記憶媒体であって、前記命令が、１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、請求項１乃至８のいずれか１項に従う方法を行わせる、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

[0001]本出願は、内容全体が参照により本明細書に組み込まれる、２０１３年３月２９日に出願された米国仮出願第６１／８０６，７０５号の利益を主張する。

【0002】

[0002]本開示は、ビデオデータの処理に関する。

【背景技術】

【0003】

[0003]デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップコンピュータまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話または衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、現在開発中の高効率ビデオコーディング（ＨＥＶＣ）規格によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。

【0004】

[0004]ビデオ圧縮技法は、ビデオシーケンス内で固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を実行する。ブロックベースのビデオコーディングの場合、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部分）が、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコーディングされた（Ｉ）スライス内のビデオブロックは、同じピクチャにおける隣接ブロック（neighboring blocks）内の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス内のビデオブロックは、同じピクチャの中の隣接ブロック内の参照サンプルに対する空間的予測、または他の参照ピクチャの中の参照サンプルに対する時間的予測を使用することができる。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

【0005】

[0005]空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトル、およびコーディングされたブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて残差変換係数をもたらすことができ、その残差変換係数が、次いで量子化され得る。最初に２次元アレイで構成される量子化変換係数は、変換係数の１次元ベクトルを生成するために走査されてよく、なお一層の圧縮を達成するためにエントロピーコーディングが適用されてよい。

【発明の概要】

【0006】

[0006]概して、本開示では、ビデオデータを処理するための技法について説明する。詳細には、本開示では、改善されたリアルタイムトランスポートプロトコル（ＲＴＰ：real-time transport protocol）ペイロードフォーマット設計について説明する。

【0007】

[0007]一例では、ビデオデータを処理する方法は、第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットの送信順序に基づいて第１のＮＡＬユニットに関する復号順序番号を決定することと、を含む。

【0008】

[0008]別の例では、ビデオデータを処理するためのデバイスは、メモリと；リアルタイムトランスポートプロトコル（ＲＴＰ）パケットのために構成される受信機と；第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットの送信順序に基づいて第１のＮＡＬユニットに関する復号順序番号を決定することと、を行うように構成された１つまたは複数のプロセッサと、含む。

【0009】

[0009]別の例では、コンピュータ可読記憶媒体は命令を記憶し、命令は、１つまたは複数のプロセッサによって実行されたとき、１つまたは複数のプロセッサに、第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットの送信順序に基づいて第１のＮＡＬユニットに関する復号順序番号を決定することと、を行わせる。

【0010】

[0010]別の例では、ビデオデータを処理するための装置は、第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信するための手段と、第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットの送信順序に基づいて第１のＮＡＬユニットに関する復号順序番号を決定するための手段と、を含む。

【0011】

[0011]別の例では、ビデオデータを処理する方法は、第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを生成することと、第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットに関する復号順序に基づいて第１のＮＡＬユニットに関する送信順序を設定することと、を含む。

【0012】

[0012]１つまたは複数の例の詳細が、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、その説明および図面から、ならびに特許請求の範囲から明らかになろう。

【図面の簡単な説明】

【0013】

【図1】[0013]本開示で説明される技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。

【図2】[0014]アグリゲーションパケット構造の視覚表現を示す図。

【図3】[0015]本開示で説明される技法を実装し得る例示的なビデオエンコーダを示すブロック図。

【図4】[0016]本開示で説明される技法を実装し得る例示的なビデオデコーダを示すブロック図。

【図5】[0017]ネットワークの一部を形成するデバイスの例示的なセットを示すブロック図。

【図6】[0018]本開示の技法によるＮＡＬユニットをパケット化解除する（depacketizing）例示的な方法を示す図。

【図7】[0019]本開示の技法によるＮＡＬユニットをパケット化する例示的な方法を示す図。

【図8】[0020]本開示の技法によるＮＡＬユニットをパケット化解除する例示的な方法を示す図。

【図9】[0021]本開示の技法によるＮＡＬユニットをパケット化する例示的な方法を示す図。

【図10】[0022]本開示の技法によるＮＡＬユニットをパケット化解除する例示的な方法を示す図。

【図11】[0023]本開示の技法によるＮＡＬユニットをパケット化する例示的な方法を示す図。

【発明を実施するための形態】

【0014】

[0024]本開示は、符号化されたビデオデータをＲＴＰを介してトランスポートするためのリアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットの改善された設計に関する様々な技法を導入する。ＲＴＰは、２０１３年３月２９日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５５０．ｔｘｔから入手可能であり、その全体が参照により本明細書に組み込まれる、ＩＥＴＦ ＲＦＣ ３５５０において規定されたトランスポートプロトコルである。ＩＥＴＦ ＲＦＣ ３５５０によれば、ＲＴＰは、インタラクティブなオーディオおよびビデオなど、リアルタイム特性を有するデータに関するエンドツーエンド配信サービスを提供することを意図して開発された。ＲＴＰによってトランスポートされるデータは、ＲＴＰパケット内にパケット化される。ＲＴＰパケットは、ＲＴＰヘッダとペイロードデータとを含むデータパケットである。ＲＴＰパケットのペイロードデータは、符号化されたビデオデータであり得る。符号化されたビデオデータは、たとえば、１つまたは複数のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットの形式であり得る。

【0015】

[0025]ビデオコーデックによって符号化されたビデオデータをＲＴＰを介してトランスポートするために、ビデオコーデックに関するＲＴＰペイロードフォーマットが規定される必要があることがある。たとえば、ＲＦＣ ６１８４（２０１３年３月２９日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ６１８４．ｔｘｔにおいて入手可能）は、Ｈ．２６４ビデオに関するＲＴＰペイロードフォーマットを規定し、ＲＦＣ ６１９０（２０１３年３月２９日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ６１９０．ｔｘｔにおいて入手可能）は、ＳＶＣビデオに関するＲＴＰペイロードフォーマットを規定し、それらの両方は、その全体が参照により本明細書に組み込まれる。ＨＥＶＣビデオに関するＲＴＰペイロードフォーマットの最近のドラフトは、２０１３年３月２９日現在、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｓｃｈｉｅｒｌ−ｐａｙｌｏａｄ−ｒｔｐ−ｈ２６５−０１から入手可能であり、その全体が参照により本明細書に組み込まれる。これらの様々な規格は、コーディングされたビデオデータ（たとえば、コーディングされたＮＡＬユニット）が、どのようにしてＲＴＰパケット内にパケット化されるかを記載する。

【0016】

[0026]ＨＥＶＣ規格によれば、ＮＡＬユニットは、後続すべきデータのタイプのインジケーション（indication）を含んでいるシンタックス構造として、および、エミュレーション防止バイトを用いて必要に応じて点在させられた（interspersed）未加工バイトシーケンスペイロード（ＲＢＳＰ：raw byte sequence payload）の形式でそのデータを含んでいるバイトとして定義される。ＶＣＬ ＮＡＬユニットは、ビデオコーディングレイヤデータを含む一方で、非ＶＣＬ ＮＡＬユニットは、ビデオコーディングレイヤデータについてのいくつかの他のデータを含み得る。ＨＥＶＣによれば、アクセスユニットは、指定された分類ルールに従って互いに関連し、復号順序で連続しており、およびちょうど１つのコード化ピクチャを含んでいる、ＮＡＬユニットのセットとして定義される。コード化ピクチャのＶＣＬ ＮＡＬユニットを含むことに加えて、アクセスユニットはまた、非ＶＣＬ ＮＡＬユニットを含み得る。アクセスユニットの復号は常に、復号されたピクチャをもたらす。ＲＴＰパケットは、ＮＡＬユニットをトランスポートするために使用されるパケットである。

【0017】

[0027]ＲＦＣ ６１８４およびＲＦＣ ６１９０におけるＲＴＰペイロードフォーマットの設計ならびにＨＥＶＣに関する既存のドラフトＲＴＰペイロードフォーマットは、いくつかの潜在的な問題または欠点に関連する。一例として、複数のパケット化モードが規定され、多くのタイプのパケットが規定されており、使用すべきパケット化モードおよびパケットタイプを選択することを潜在的に困難にしている。別の例として、１つのアクセスユニットのネットワークアブストラクションレイヤ（ＮＡＬ）ユニットをインタリーブすることは、ＲＦＣ ６１８４およびＲＦＣ ６１９０において定義されるマルチタイムアグリゲーションパケット（ＭＴＡＰ）を使用することによってのみ可能である。しかしながら、唯一のアクセスユニットのＮＡＬユニットが１つのＲＴＰパケットにアグリゲートされるとき、それらのすべては、同じタイムスタンプを有する。したがって、単にＲＴＰパケットのＲＴＰタイムスタンプに依存することは十分ではあるが、ＲＦＣ ６１８４およびＲＦＣ ６１９０によって要求される追加の時間情報を送ることは、潜在的に帯域幅を浪費する。１つのアクセスユニットのＮＡＬユニットをインタリーブすることは、異なるパケット内で１つのピクチャのインタリーブされたコード化スライスのトランスポートを可能にし、したがって、１つのパケットが失われたとき、受信された隣接するスライスが、より良い隠蔽のために利用され得る。

【0018】

[0028]上記で紹介した潜在的な問題および欠点に対処するために、本開示は、改善されたＲＴＰペイロードフォーマット設計のためにいくつかの技法を導入する。一技法によれば、パケット化モードは区別されず（is not differentiated）、それによって、インタリーブされないパケット化とインタリーブされたパケット化の両方が可能であり、シングルセッション送信とマルチセッション送信の両方が可能であり、統合されたパケット化解除プロセスが、パケットペイロード内でシグナリングされる随意の情報から導出され得る、ＮＡＬユニットの絶対的な復号順序番号の値に基づいて規定される。

【0019】

[0029]別の技法によれば、アグリゲーションパケットの設計は、冗長な時間情報を送ることを要求することなく、１つのアクセスユニットのＮＡＬユニットをインタリーブすることを可能にする。本開示で説明するアグリゲーションパケットは、複数の小さいスライスがトランスポートされているとき、ビデオコーディングを改善し得る。本開示の技法に従ってＮＡＬユニットをインタリーブすることを可能にすることは、全体的な再構成画像の品質を改善し得る。たとえば、アグリゲーションパケットがインタリーブされたＮＡＬユニットを含み、１つのアグリゲーションパケットが失われた場合、インタリーブされたＮＡＬユニットは、隣接するビデオブロックの代わりにビデオブロックの分散したグループに対応する可能性がある。エラー隠蔽技法は、一般的に、より小さいエリアのロスに対してより有効であり、したがって、隣接するビデオブロックのグループのロスを隠蔽することに比較して、ビデオブロックの分散したグループのロスを隠蔽することが、より効果的であり得る。

【0020】

[0030]図１は、本開示で説明される技法とともに使用され得る例示的なビデオ処理システム１０を示すブロック図である。システム１０は、たとえば、本開示で説明されるＲＴＰ技法を使用してビデオデータを生成し、処理し、送信することができる。図１に示されるように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化されたビデオデータを生成するソースデバイス１２を含む。符号化ビデオデータは、メディアアウェアネットワーク要素（ＭＡＮＥ：media aware network element）２９によってソースデバイス１２から宛先デバイス１４にルーティングされ（be routed）得る。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信のために装備され得る。

【0021】

[0031]システム１０は、異なるビデオコーディング規格、プロプライエタリ規格もしくは技法、またはマルチビューコーディングの任意の他の方法に従って動作し得る。たとえば、ビデオエンコーダ２０およびビデオデコーダ３０は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、およびそのスケーラブルビデオコーディング（ＳＶＣ：Scalable Video Coding）拡張とマルチビュービデオコーディング（ＭＶＣ：Multiview Video Coding）拡張とを含む（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られている）ＩＴＵ−Ｔ Ｈ．２６４などを含むビデオ圧縮規格に従って動作し得る。ＭＶＣ拡張の最近の公的に入手可能な共同ドラフトは、「Ａｄｖａｎｃｅｄ ｖｉｄｅｏ ｃｏｄｉｎｇ ｆｏｒ ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ」、ＩＴＵ−ＴレコメンデーションＨ．２６４、２０１０年３月に記載されている。ＭＶＣ拡張のさらに最近の公的に入手可能な共同ドラフトは、「Ａｄｖａｎｃｅｄ ｖｉｄｅｏ ｃｏｄｉｎｇ ｆｏｒ ｇｅｎｅｒｉｃ ａｕｄｉｏｖｉｓｕａｌ ｓｅｒｖｉｃｅｓ」、ＩＴＵ−ＴレコメンデーションＨ．２６４、２０１１年６月に記載されている。ＭＶＣ拡張の現在の共同ドラフトは、２０１２年１月時点で承認されている。

【0022】

[0032]さらに、ＩＴＵ−Ｔビデオコーディングエキスパーツグループ（ＶＣＥＧ）とＩＳＯ／ＩＥＣモーションピクチャエキスパーツグループ（ＭＰＥＧ）とのビデオコーディングにおける共同研究部会（ＪＣＴ−ＶＣ）によって現在開発中の新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）規格がある。ＨＥＶＣ ＷＤ９と呼ばれる、ＨＥＶＣの最近のワーキングドラフト（ＷＤ）が、２０１３年３月１５日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１１＿Ｓｈａｎｇｈａｉ／ｗｇ１１／ＪＣＴＶＣ−Ｋ１００３−ｖ１０．ｚｉｐから入手可能である。説明の目的で、ビデオエンコーダ２０およびビデオデコーダ３０については、ＨＥＶＣ規格またはＨ．２６４規格およびそのような規格の拡張のコンテキストにおいて説明される。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。Ｏｎ２ ＶＰ６／ＶＰ７／ＶＰ８と呼ばれるものなど、プロプライエタリなコーディング技法もまた、本明細書で説明される技法のうちの１つまたは複数を実施し得る。本開示の技法は、ＨＥＶＣおよびその他のものを含むいくつかのビデオコーディング規格に、潜在的に適用可能である。

【0023】

[0033]宛先デバイス１４は、リンク１６を介して、復号されるべき符号化されたビデオデータを受信し得る。リンク１６は、符号化されたビデオデータをソースデバイス１２から宛先デバイス１４に移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、リンク１６は、ソースデバイス１２が、符号化されたビデオデータをリアルタイムで宛先デバイス１４に直接送信することを可能にするための通信媒体を備え得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルあるいは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。リンク１６は、ソースデバイス１２から宛先デバイス１４にビデオデータをルーティングする、ＭＡＮＥ ２７などの１つまたは複数のＭＡＮＥを含み得る。

【0024】

[0034]代替的に、符号化されたデータは、出力インターフェース２２からストレージデバイス２５に出力され得る。同様に、符号化されたデータは、入力インターフェースによってストレージデバイス２５からアクセスされ得る。ストレージデバイス２５は、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性のメモリ、あるいは符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス２５は、ソースデバイス１２によって生成された符号化されたビデオを保持し得る、ファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイス２５から記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス１４に送信することができる任意のタイプのサーバであり得る。例示的なファイルサーバとしては、（たとえば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブがある。宛先デバイス１４は、インターネット接続を含むいずれかの標準データ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバ上に記憶された符号化されたビデオデータにアクセスするのに適している、ワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含むことができる。ストレージデバイス２５からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。ストレージデバイス２５から取り出されたビデオデータは、ＭＡＮＥ ２７などの１つまたは複数のＭＡＮＥを使用して宛先デバイス１４にルーティングされ得る。

【0025】

[0035]本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえば、インターネットを介したストリーミングビデオ送信、データ記憶媒体上に記憶するためのデジタルビデオの符号化、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の用途のような、種々のマルチメディア用途のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの用途をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

【0026】

[0036]図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、パケッタイザ２１と、出力インターフェース２２とを含む。場合によっては、出力インターフェース２２は変調器／復調器（モデム）および／または送信機を含み得る。ソースデバイス１２において、ビデオソース１８は、たとえばビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および／もしくはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムなどのソース、またはそのようなソースの組合せを含み得る。一例として、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き携帯電話またはビデオ電話を形成し得る。ただし、本開示で説明される技法は、概してビデオコーディングに適用可能であり得、ワイヤレスおよび／またはワイヤード適用例に適用され得る。

【0027】

[0037]キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオデータは、ソースデバイス１２の出力インターフェース２２を介して宛先デバイス１４に直接送信され得る。符号化されたビデオデータは、さらに（または代替的に）、復号および／または再生のための宛先デバイス１４または他のデバイスによる後のアクセスのためにストレージデバイス２５上に記憶され得る。

【0028】

[0038]宛先デバイス１４は、入力インターフェース２８と、デパケッタイザ２９と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。場合によっては、入力インターフェース２８は受信機および／またはモデムを含み得る。宛先デバイス１４の入力インターフェース２８は、リンク１６を介して符号化ビデオデータを受信する。リンク１６を介して通信され、またはストレージデバイス２５上に提供された符号化されたビデオデータは、ビデオデータを復号する際にビデオデコーダ３０などのビデオデコーダが使用するための、ビデオエンコーダ２０によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信され、記憶媒体上に記憶される符号化されたビデオデータとともに含まれ得、またはファイルサーバに記憶され得る。

【0029】

[0039]ディスプレイデバイス３２は、宛先デバイス１４と一体化されること、またはその外部に存在することがある。いくつかの例では、宛先デバイス１４は、一体型ディスプレイデバイスを含むことができ、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス１４はディスプレイデバイスであり得る。一般に、ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

【0030】

[0040]図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含んでもよい。適用可能な場合、いくつかの例では、ＭＵＸ−ＤＥＭＵＸユニットはＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠することができる。

【0031】

[0041]ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの様々な適切なエンコーダ回路のいずれかとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、本開示の技法を実行するために１つまたは複数のプロセッサを使用してハードウェアでその命令を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。

【0032】

[0042]ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発について作業中である。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、たとえば、ＩＴＵ−Ｔ Ｈ．２６４／ＡＶＣに従う既存のデバイスに対してビデオコーディングデバイスのいくつかの追加の能力を仮定する。たとえば、Ｈ．２６４は９つのイントラ予測符号化モードを提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。

【0033】

[0043]概して、ＨＭの作業モデルは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方のブロックを含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ）に分割され得ることを記述する。ツリーブロックは、Ｈ．２６４規格のマクロブロックと同様の目的を有する。スライスは、コーディング順序でいくつかの連続するツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、４分木に従ってコーディングユニット（ＣＵ）に分割され得る。たとえば、４分木のルートノードとしてのツリーブロックは、４つの子ノードに分割される場合があり、各子ノードは、次に、親ノードとなり、別の４つの子ノードに分割される場合がある。４分木のリーフノードとしての最終的な分割されていない子ノードは、コーディングノード、すなわち、コード化ビデオブロックを備える。コード化ビットストリームに関連付けられるシンタックスデータは、ツリーブロックが分割され得る最大回数を定義し得、コーディングノードの最小サイズをも定義し得る。ツリーブロックの分割は、ルーマドメイン内で発生し得、場合によってはリーフノードのさらなるサブサンプリングを用いて、クロマドメイン内で模倣され得る。

【0034】

[0044]ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ）および変換ユニット（ＴＵ）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、形状が正方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルをもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含み得る。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵが、スキップモード符号化もしくはダイレクトモード符号化されるか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかによって異なり得る。ＰＵは、形状が非正方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が正方形または非正方形であり得る。

【0035】

[0045]ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従った変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、通常、ＰＵと同じサイズであるか、またはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、「残差４分木」（ＲＱＴ：residual quad tree）として知られる４分木構造を使用して、より小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれることがある。ＴＵに関連するピクセル差分値は、変換されて変換係数が生成され得、その変換係数は量子化され得る。

【0036】

[0046]概して、ＰＵは、予測処理に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵは、ＰＵについてのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための動きベクトルを定義するデータを含み得る。ＰＵのための動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルについての分解能（たとえば、１／４ピクセル精度もしくは１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトル用の参照ピクチャリスト（たとえば、リスト０、リスト１、もしくはリストＣ）を記述することができる。

【0037】

[0047]概して、ＴＵは、変換プロセスと量子化プロセスとのために使用される。１つまたは複数のＰＵを有する所与のＣＵは、１つまたは複数の変換ユニット（ＴＵ）を含む場合もある。予測の後に、ビデオエンコーダ２０は、ＰＵに対応する残差値を計算し得る。残差値は、エントロピーコーディングのためのシリアル化変換係数を生成するために、ＴＵを使用して変換係数に変換され、量子化され、走査され得るピクセル差分値を備える。本開示は、一般に、ＣＵのコーディングノードを指すために「ビデオブロック」という用語を使用する。いくつかの特定の場合において、本開示は、コーディングノードとＰＵとＴＵとを含む、ツリーブロック、すなわち、ＬＣＵまたはＣＵを指すために「ビデオブロック」という用語を使用する場合もある。

【0038】

[0048]ビデオシーケンスは、通常、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、一般に、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックはＣＵ内のコーディングノードに対応し得る。ビデオブロックは、固定サイズまたは可変サイズを有し得、指定のコーディング規格に従ってサイズが異なり得る。

【0039】

[0049]一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示とによって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５ＮのＰＵおよび下部の２Ｎ×１．５ＮのＰＵで水平方向に区分された２Ｎ×２ＮのＣＵを指す。

【0040】

[0050]本開示では、たとえば１６×１６ピクセルまたは１６かける１６ピクセルなど、「Ｎ×Ｎ」および「ＮかけるＮ（Ｎ ｂｙ Ｎ）」は、垂直および水平の次元に関して、ビデオブロックのピクセルの次元を示すために交換可能に使用され得る。一般的に、１６×１６ブロックは、垂直方向に１６個のピクセルを有し（ｙ＝１６）、水平方向に１６個のピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、Ｎは非負整数値を表す。ブロック内のピクセルは行と列に構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要はない。たとえば、ブロックはＮ×Ｍピクセルを備えてよく、この場合に、Ｍは必ずしもＮに等しいとは限らない。

【0041】

[0051]ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後に、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域においてピクセルデータを備え得、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後に、変換領域において係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵのための残差データを含むＴＵを形成し、次いで、ＣＵ用の変換係数を生成するために、ＴＵを変換することができる。

【0042】

[0052]変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実施し得る。量子化は、概して、係数を表すために使用されるデータの量をできるだけ低減するために変換係数が量子化され、さらなる圧縮を行うプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。たとえば、量子化中にｎビット値がｍビット値に切り捨てられ（be rounded down）てよく、ただし、ｎはｍよりも大きい。

【0043】

[0053]いくつかの例では、ビデオエンコーダ２０は、あらかじめ定義された走査順序を利用して、量子化された変換係数を走査し、エントロピー符号化され得るシリアライズされたベクトルを生成し得る。他の例では、ビデオエンコーダ２０は適応走査を実施し得る。量子化された変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディング、または別のエントロピー符号化方法に従って、１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。

【0044】

[0054]ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が０ではないかどうかに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルの可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードがより確からしいシンボル（more probable symbols）に対応し、より長いコードがより確からしくないシンボル（less probable symbols）に対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率決定は、シンボルに割り当てられたコンテキストに基づくことができる。

【0045】

[0055]本開示で説明する技法は、独立してまたは共同で適用され得る。これらの技法の態様は、パケッタイザ２１およびデパケッタイザ２９によって実行され得る。いくつかの例では、パケッタイザ２１は、ＲＴＰ送信者または単に送信者と呼ばれることがあり、一方、デパケッタイザ２９は、ＲＴＰ受信者または単に受信者と呼ばれることがある。これらの技法の態様は、次のように要約される。
− フラグメントユニット（ＦＵ）内でトランスポートされるコード化タイルの第１のコーディングツリーユニット（ＣＴＵ）の第１のアドレスのシグナリング
タイルＩＤ（または２つのタイルＩＤ値の差分（delta））は、ＦＵペイロードの前にＦＵ構造内でシグナリングされる。このシグナリングは、タイル内の第１のＣＴＵのタイル走査におけるＣＴＵアドレス（ならびにラスタ走査（raster scan）におけるアドレス）を指定するかまたは示す。
代替として、ＦＵ内でトランスポートされるコード化タイル内の第１のＣＴＵのタイル走査におけるＣＴＵアドレス（または２つのそのような値の差分）が、ＦＵペイロードの前にＦＵ構造内でシグナリングされる。
代替として、ＦＵ内でトランスポートされるコード化タイル内の第１のＣＴＵのラスタ走査におけるＣＴＵアドレス（または２つのそのような値の差分）が、ＦＵペイロードの前にＦＵ構造内でシグナリングされる。
代替として、シグナリング（上記の形式のいずれかにおいて）は、シグナリングの存在を示すインジケーション（たとえば、メディアタイプパラメータ）が存在するときだけ存在する。そのようなメディアタイプパラメータは、単に、上記のシグナリングの存在を示し得るか、またはタイルの使用を示し得る（およびタイルが使用されないことを示される場合は、上記のシグナリングは存在しない）。
− タイルが複数のＦＵ内でトランスポートされるとき、
フラグメント化されたタイルの開始を示すためにＦＵヘッダ内のＳフラグを使用／追加する。
・これを用いて、タイル内の第１のＣＴＵのＣＴＵアドレスを導出するための上記の任意のシグナリングの存在は、Ｓフラグが０に等しいことが（さらに）要件とされる。
フラグメント化されたタイルの終了を示すためにＦＵヘッダ内のＥフラグを使用／追加する。
− パケット内のすべてのＮＡＬユニットが従属スライスセグメントを含むかどうかを示すために、ＲＴＰパケットペイロードヘッダ内のフラグを使用／追加する。
代替として、ＲＴＰパケットヘッダ内の２ビットが、以下のうちの１つを示す。
・パケット内のすべてのＮＡＬユニットは、従属スライスセグメントである。
・パケット内のＮＡＬユニットのうちの少なくとも１つは従属スライスセグメントであり、そのセグメントに対して対応する独立スライスセグメントは、同じパケット内にない。
・パケット内のＮＡＬユニットのうちの少なくとも１つは、独立スライスセグメントである。
・パケット内のすべてのＮＡＬユニットは、独立スライスセグメントである。
唯一のＮＡＬユニットを含むパケットにおいて、ＮＡＬユニットが従属スライスセグメントを含むかどうかを示すために、１ビットだけが必要とされる。
代替として、シグナリング（上記の形式のいずれかにおいて）は、シグナリングの存在を示すインジケーション（たとえば、メディアタイプパラメータ）が存在するときだけ存在する。そのようなメディアタイプパラメータは、単に、上記のシグナリングの存在を示し得るか、または従属スライスセグメントの使用を示し得る（および従属スライスセグメントが使用されないことを示される場合は、上記のシグナリングは存在しない）。

【0046】

[0056]ペイロード構造の態様が、次に説明される。これらのペイロード構造が、パケッタイザ２１によって生成され得、デパケッタイザ２９によって解析され得る。ＲＴＰパケットのペイロードの第１の２バイトが、ペイロードヘッダを定義し得る。ペイロードヘッダは、ペイロード構造のタイプに関わりなく、ＨＥＶＣ ＮＡＬユニットヘッダ（ＨＥＶＣ ＷＤ １０のセクション７．３．１．２に規定されるシンタックス要素ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔ、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ、ｎｕｈ＿ｌａｙｅｒ＿ｉｄ、およびｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１に対応する、Ｆ、Ｔｙｐｅ、ＬａｙｅｒＩｄ、およびＴＩＤ）と同じフィールドから成り得る。

【0047】

[0057]ＲＴＰパケットペイロード構造の３つの異なるタイプが指定される。受信機は、ペイロードヘッダ内のＴｙｐｅフィールドを介してＲＴＰパケットペイロードのタイプを識別し得る。受信機は、ビデオデコーダを含むデバイスのデパケッタイザであってよく、またはＭＡＮＥもしくは他のネットワークエンティティの一部を形成してもよい。３つの異なるペイロード構造は、以下のとおりである。
シングルＮＡＬユニットパケット：ペイロード内にシングルＮＡＬユニットを含み、ＮＡＬユニットのＮＡＬユニットヘッダもまた、ペイロードヘッダとして働く。シングルＮＡＬユニットパケットは、ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きいときに使用されてはならない。
アグリゲーションパケット（ＡＰ）：１つのアクセスユニット内に１つまたは複数のＮＡＬユニットを含む。以下を参照。
フラグメンテーションユニット（ＦＵ）：シングルＮＡＬユニットのサブセットを含む。以下を参照。

【0048】

[0058]パケッタイザ２１およびデパケッタイザ２９によってサポートされる送信モードが、次に説明される。本開示の技法は、シングルＲＴＰセッションまたはマルチプルＲＴＰセッションを介するＨＥＶＣビットストリームの送信を可能にし得る。概念および作動原理はＲＦＣ６１９０と一致し、類似の、しかし潜在的により簡素な設計に従う（follows）。唯一のＲＴＰセッションがＨＥＶＣビットストリームの送信に使用される場合、送信モードは、シングルセッション送信（ＳＳＴ）と呼ばれ、そうでない（２つ以上のＲＴＰセッションがＨＥＶＣビットストリームの送信に使用される）場合、送信モードは、マルチセッション送信（ＭＳＴ）と呼ばれる。

【0049】

[0059]ＳＳＴは、ポイントツーポイントユニキャストのシナリオに対して使用されるべきであり、一方、ＭＳＴは、帯域幅利用効率を改善するために異なる受信機が同じＨＥＶＣビットストリームの異なる動作ポイントを要求する、ポイントツーマルチポイントマルチキャストのシナリオに対して使用されるべきである。

【0050】

[0060]ｔｘ−ｍｏｄｅが「ＳＳＴ」に等しい場合、ＳＳＴが使用されなければならない。そうでない（ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しい）場合、ＭＳＴが使用されなければならない。

【0051】

[0061]次に、復号順序番号の態様が、説明される。各ＮＡＬユニットに対して、変数ＡｂｓＤｏｎが導出され、ＮＡＬユニット復号順序を示す復号順序番号を表す。

【0052】

[0062]ＮＡＬユニットｎを、ＲＴＰセッション内の送信順序におけるｎ番目のＮＡＬユニットとする。

【0053】

[0063]ｔｘ−ｍｏｄｅが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０に等しい場合、ＮＡＬユニットｎに対するＡｂｓＤｏｎの値であるＡｂｓＤｏｎ［ｎ］は、ｎに等しいとして導出される。

【0054】

[0064]そうでない（ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きい）場合、ＡｂｓＤｏｎ［ｎ］は次のように導出され、ここでＤＯＮ［ｎ］は、ＮＡＬユニットｎに対する変数ＤＯＮの値である：
− ｎが０に等しい（すなわち、ＮＡＬユニットｎは送信順序におけるまさに最初のＮＡＬユニットである）場合、ＡｂｓＤｏｎ［０］はＤＯＮ［０］に等しく設定される。
− そうでない（ｎは０より大きい）場合、ＡｂｓＤｏｎ［ｎ］の導出に対して下記が適用される：

【数1】

【0055】

[0065]任意の２つのＮＡＬユニットｍおよびｎに対して、下記が適用される：
− ＡｂｓＤｏｎ［ｍ］より大きいＡｂｓＤｏｎ［ｎ］は、ＮＡＬユニット復号順序において、ＮＡＬユニットｎがＮＡＬユニットｍに続くことを示す。
− ＡｂｓＤｏｎ［ｎ］がＡｂｓＤｏｎ［ｍ］に等しいとき、２つのＮＡＬユニットのＮＡＬユニット復号順序は、いずれの順序であってもよい。
− ＡｂｓＤｏｎ［ｍ］より小さいＡｂｓＤｏｎ［ｎ］は、復号順序において、ＮＡＬユニットｎがＮＡＬユニットｍに先行することを示す。

【0056】

[0066]ＮＡＬユニット復号順序において２つの連続するＮＡＬユニットがＡｂｓＤｏｎの異なる値を有するとき、復号順序において第２のＮＡＬユニットに対するＡｂｓＤｏｎの値は、第１のＮＡＬユニットに対するＡｂｓＤｏｎの値より大きくなければならず、２つのＡｂｓＤｏｎの値の間の絶対差分は、１以上であり得る。

【0057】

[0067]アグリゲーションパケット（ＡＰ）が、次に説明される。図２は、アグリゲーションパケット構造の視覚表現を示す。アグリゲーションパケット１２０は、ペイロードデータ１２４に後続されるペイロードヘッダ１２２（ＰａｙｌｏａｄＨｄｒで示される）を含む。ペイロードデータは、１つまたは複数のアグリゲーションユニットを含み、図２においてアグリゲーションパケット０〜Ｎとして示される。各アグリゲーションユニットは、ＮＡＬユニットを含み得る。たとえば、アグリゲーションユニット０はＮＡＬユニット０を含み、アグリゲーションユニット１はＮＡＬユニット１を含み、アグリゲーションユニットＮはＮＡＬユニットＮを含む。図２はまた、Ｆビットと、ＴＹＰＥフィールドと、Ｒフィールド（時々、ＬａｙｅｒＩｄフィールドとも呼ばれる）と、ＴＩＤフィールドとを含む、ペイロードヘッダの最初の１６ビットを示す。

【0058】

[0068]ＡＰは、しばしば数オクテットのサイズにすぎない大半の非ＶＣＬ ＮＡＬユニットなど、小さいＮＡＬユニットに対するパケット化オーバーヘッドの低減を可能にするために導入された。ＡＰは、１つのアクセスユニット内のＮＡＬユニットをアグリゲートする。ＡＰ内で搬送されるべき各ＮＡＬユニットは、アグリゲーションユニット内にカプセル化される。１つのＡＰ内にアグリゲートされたＮＡＬユニットは、ＮＡＬユニット復号順序にある。ＡＰは、１つまたは複数のアグリゲーションユニットに後続されるペイロードヘッダ（ＰａｙｌｏａｄＨｄｒとして示される）から成ることができる。

【0059】

[0069]ペイロードヘッダ内のフィールドは、次のように設定される。アグリゲートされたＮＡＬユニットの各々のＦビットがゼロに等しい場合、Ｆビットは０に等しくなければならず、そうでない場合は、Ｆビットは１に等しくなければならない。Ｔｙｐｅフィールドは、４８に等しくなければならない。ＬａｙｅｒＩｄの値は、すべてのアグリゲートされたＮＡＬユニットのＬａｙｅｒＩｄの最小の値に等しくなければならない。ＴＩＤの値は、すべてのアグリゲートされたＮＡＬユニットのＴＩＤの最小の値でなければならない。

【0060】

[0070]ＡＰは、必要なだけ多くのアグリゲーションユニットを搬送し得るが、ＡＰ内のデータの総量は、明確にＩＰパケット内にフィットしなければならず、サイズは、ＩＰレイヤフラグメンテーションを回避するために、得られたＩＰパケットがＭＴＵサイズより小さいように選択されるべきである。ＡＰは、ＦＵを含んではならない。ＡＰは、ネストされてはならず（MUST NOT be nested）、すなわち、ＡＰは、別のＡＰを含んではならない。

【0061】

[0071]ＡＰ内の第１のアグリゲーションユニットは、（ネットワークバイト順における）１６ビットの符号なしのサイズ情報に後続される（ネットワークバイト順における）随意の１６ビットＤＯＮＬフィールドから成り得、符号なしのサイズ情報は、（これらの２オクテットを除くがＮＡＬユニットヘッダを含む）ＮＡＬユニットのサイズをバイトで示し、ＮＡＬユニットヘッダを含むＮＡＬユニット自体に後続される。

【0062】

[0072]ＤＯＮＬフィールドは、存在するとき、アグリゲートされたＮＡＬユニットの復号順序番号の１６の最下位ビットの値を指定する。

【0063】

[0073]ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きい場合、ＤＯＮＬフィールドは、ＡＰ内の第１のアグリゲーションユニットであるアグリゲーションユニット内に存在しなければならず、アグリゲートされたＮＡＬユニットに対する変数ＤＯＮは、ＤＯＮＬフィールドの値に等しいとして導出される。そうでない（ｔｘ−ｍｏｄｅが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０に等しい）場合、ＤＯＮＬフィールドは、ＡＰ内の第１のアグリゲーションユニットであるアグリゲーションユニット内に存在してはならない。

【0064】

[0074]ＡＰ内の第１のアグリゲーションユニットでないアグリゲーションユニットは、（ネットワークバイト順において）１６ビットの符号なしのサイズ情報に後続される随意の８ビットＤＯＮＤフィールドから成り得、符号なしのサイズ情報は、（これらの２オクテットを除くがＮＡＬユニットヘッダを含む）ＮＡＬユニットのサイズをバイトで示し、ＮＡＬユニットヘッダを含むＮＡＬユニット自体に後続される。

【0065】

[0075]存在するとき、ＤＯＮＤフィールド＋１は、現在のアグリゲートされたＮＡＬユニットの復号順序番号の値と、同じＡＰ内の先行するアグリゲートされたＮＡＬユニットの復号順序番号の値との間の差分を指定し得る。ＮＡＬユニットがＲＴＰパケット内に現れる順序でＮＡＬユニットが復号される必要があるペイロード構造とは対照的に、本開示で説明するＤＯＮＤおよびＤＯＮＬのパラメータの使用は、指定されるべき特定の復号順序を可能にし得る。

【0066】

[0076]ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きい場合、ＤＯＮＤフィールドは、ＡＰ内の第１のアグリゲーションユニットではないアグリゲーションユニット内に存在しなければならず、アグリゲートされたＮＡＬユニットに対する変数ＤＯＮは、同じＡＰ内の先行するアグリゲートされたＮＡＬユニットのＤＯＮ＋ＤＯＮＤフィールド＋１の値が６５５３６を法とする数）（the DON of the preceding aggregated NAL unit in the same AP plus the value of the DOND field plus 1 modulo 65536）と等しいとして導出される。そうでない（ｔｘ−ｍｏｄｅが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０に等しい）場合、ＤＯＮＤフィールドは、ＡＰ内の第１のアグリゲーションユニットではないアグリゲーションユニット内に存在してはならない。

【0067】

[0077]代替として、ＤＯＮＤフィールドは、異なる長さ、たとえば４ビットであってよい。別の代替として、２つの第１ではないアグリゲーションユニットは、ＤＯＮＤ値をシグナリングするために、各アグリゲーションユニットに対する４ビットで、１つの８ビットフィールドを共有する。さらに別の代替として、ＤＯＮＤフィールドの長さは、メディアタイプパラメータによってシグナリングされ、そのパラメータの値が０に等しいことは、ＤＯＮＤフィールドが存在しないことを意味する。

【0068】

[0078]フラグメンテーションユニット（ＦＵ）が、次に説明される。フラグメンテーションユニット（ＦＵ）は、シングルＮＡＬユニットを複数のＲＴＰパケットにフラグメント化することを可能にするために導入される。ＮＡＬユニットのフラグメントは、そのＮＡＬユニットの連続するオクテットの整数から成ることができる。同じＮＡＬユニットのフラグメントは、昇順のＲＴＰ連続番号で連続した順番で送られなければならない（同じＲＴＰパケットストリーム内の他のＲＴＰパケットが、最初のフラグメントと最後のフラグメントとの間で送られることはない）。

【0069】

[0079]ＮＡＬユニットがフラグメント化され、ＦＵ内で伝達されるとき、そのＮＡＬユニットは、フラグメント化されたＮＡＬユニットと呼ばれる。ＡＰは、フラグメント化されてはならない。ＦＵは、ネストされてはならず、すなわち、ＦＵは、別のＦＵを含んではならない。

【0070】

[0080]ＦＵを搬送するＲＴＰパケットのＲＴＰタイムスタンプは、フラグメント化されたＮＡＬユニットのＮＡＬＵ−時間に設定される。

【0071】

[0081]ＦＵは、ペイロードヘッダ（ＰａｙｌｏａｄＨｄｒとして示される）と、１オクテットのＦＵヘッダと、随意の１６ビットＤＯＮＬフィールド（ネットワークバイト順における）と、ＦＵペイロードとから成り得る。

【0072】

[0082]ペイロードヘッダ内のフィールドは、次のように設定される。Ｔｙｐｅフィールドは、４９に等しくなければならない。フィールドＦ、ＬａｙｅｒＩｄ、およびＴＩＤは、それぞれ、フラグメント化されたＮＡＬユニットのフィールドＦ、ＬａｙｅｒＩｄ、およびＴＩＤに等しくなければならない。

【0073】

[0083]ＦＵヘッダは、Ｓビット、Ｅビット、および６ビットＴｙｐｅフィールドから成ることができる。
この例では、ＦＵヘッダフィールドのセマンティクスは以下のとおりである：
Ｓ：１ビット
１に設定されるとき、Ｓビットは、フラグメント化されたＮＡＬユニットの開始を示し、すなわち、ＦＵペイロードの第１のバイトは、同じく、フラグメント化されたＮＡＬユニットのペイロードの第１のバイトである。ＦＵペイロードがフラグメント化されたＮＡＬユニットペイロードの開始でないとき、Ｓビットはゼロに設定されなければならない。
Ｅ：１ビット
１に設定されるとき、Ｅビットは、フラグメント化されたＮＡＬユニットの終了を示し、すなわち、ペイロードの最後のバイトは、同じく、フラグメント化されたＮＡＬユニットの最後のバイトである。ＦＵペイロードがフラグメント化されたＮＡＬユニットの最後のフラグメントでないとき、Ｅビットはゼロに設定されなければならない。
Ｔｙｐｅ：６ビット
フィールドＴｙｐｅは、フラグメント化されたＮＡＬユニットのフィールドＴｙｐｅに等しくなければならない。

【0074】

[0084]ＤＯＮＬフィールドは、存在するとき、フラグメント化されたＮＡＬユニットの復号順序番号の１６の最下位ビットの値を指定することができる。

【0075】

[0085]ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいかまたはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きく、Ｓビットが１に等しい場合、ＤＯＮＬフィールドは、ＦＵ内に存在しなければならず、フラグメント化されたＮＡＬユニットに対する変数ＤＯＮは、ＤＯＮＬフィールドの値に等しいとして導出される。そうでない（ｔｘ−ｍｏｄｅが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０に等しいか、またはＳビットが０に等しい）場合、ＤＯＮＬフィールドは、ＦＵ内に存在してはならない。

【0076】

[0086]フラグメント化されないＮＡＬユニットは、１つのＦＵ内で送信されてはならず、すなわち、開始ビットおよび終了ビットは、いずれも、同じＦＵヘッダ内で１に設定されてはならない。

【0077】

[0087]１に等しいＳビットを有するＦＵで開始し、１に等しいＥビットを有するＦＵで終了する連続したＦＵのＦＵペイロードが順次連結される場合、フラグメント化されたＮＡＬユニットのペイロードが再構成され得るように、ＦＵペイロードは、フラグメント化されたＮＡＬユニットのペイロードのフラグメントから成ることができる。フラグメント化されたＮＡＬユニットのＮＡＬユニットヘッダは、それ自体、ＦＵペイロードに含まれるのではなく、フラグメント化されたＮＡＬユニットのＮＡＬユニットヘッダの情報が、ＦＵのＦＵペイロードヘッダのＦ、ＬａｙｅｒＩｄ、およびＴＩＤのフィールド、ならびにＦＵのＦＵヘッダのＴｙｐｅフィールドの中に伝達される。ＦＵペイロードは、任意の数のオクテットを有し得、および空であり得る。

【0078】

[0088]ＦＵが失われた場合、受信機内のデコーダが、不完全なＮＡＬユニットを適切に取り扱うように準備されていることが知られていない場合、受信機は、同じフラグメント化されたＮＡＬユニットに対応する、送信順におけるすべての後続のフラグメンテーションユニットを破棄すべきである。

【0079】

[0089]エンドポイントまたはＭＡＮＥにおける受信機は、ＮＡＬユニットのフラグメントｎが受信されない場合でも、ＮＡＬユニットの最初のｎ−１個のフラグメントを１つの（不完全な）ＮＡＬユニットにアグリゲートすることができる。この場合、ＮＡＬユニットのｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔは、シンタックス違反（syntax violation）を示すために１に設定されなければならない。

【0080】

[0090]パケット化のルールが、次に説明される。以下のパケット化ルールが適用される：
− ＲＴＰセッションに対してｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大きい場合、ＲＴＰセッション内で搬送されるＮＡＬユニットの送信順序は、ＮＡＬユニット復号順序と異なってよい。そうでない（ＲＴＰセッションに対してｔｘ−ｍｏｄｅが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０に等しい）場合、ＲＴＰセッション内で搬送されるＮＡＬユニットの送信順序は、ＮＡＬユニット復号順序と同じでなければならない。
− ｔｘ−ｍｏｄｅが「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓが０より大であるとき、シングルＮＡＬユニットのパケットは使用され得ない。この場合、ＡＰは、シングルＮＡＬユニットを１つのＲＴＰパケット内にカプセル化するために使用され得る。
− 小さいＮＡＬユニットに対する不要なパケットオーバーヘッドを回避するために、小さいサイズのＮＡＬユニットは、１つまたは複数の他のＮＡＬユニットとともにアグリゲーションパケット内にカプセル化されるべきである。たとえば、アクセスユニットデリミタ、パラメータセット、またはＳＥＩ ＮＡＬユニットなどの非ＶＣＬ ＮＡＬユニットは、一般的に、小さい。
− 非ＶＣＬ ＮＡＬユニットは、一般的に、関連するＶＣＬ ＮＡＬユニットが利用可能でなくては無意味であるので、非ＶＣＬ ＮＡＬユニットの各々は、その関連するＶＣＬ ＮＡＬユニットとともにアグリゲーションパケット内にカプセル化されるべきである。
− ＴＩＤ値は、ＲＴＰパケットの相対的重要度を示す。ＴＩＤのより低い値が、より高い重要度を示す。より重要なＮＡＬユニットは、より重要でないＮＡＬユニットよりも、送信ロスに対してより良く保護され得る。

【0081】

[0091]パケット化解除プロセスが、次に説明される。パケット化解除の一般的な概念は、ＮＡＬユニットが存在する場合、ＲＴＰセッションおよびすべての従属するＲＴＰセッション内のＲＴＰパケットからＮＡＬユニットを取り出すこと、および、それらをＮＡＬユニット復号順序でデコーダに送ることである。

【0082】

[0092]パケット化解除プロセスは、実装依存（implementation dependent）である。したがって、以下の説明は、適切な実装形態の一例と見なされるべきである。同じ入力に対する出力が、以下で説明するプロセスと同じである限り、他の方式が、同様に使用され得る。出力は、ＮＡＬユニットのセットおよびそれらの順序が、両方とも等しいことと同じ意味である。説明されるアルゴリズムに対する最適化が可能である。

【0083】

[0093]バッファ管理に対するすべての通常のＲＴＰメカニズムが適用される。詳細には、複製されたまたは古い（outdated）ＲＴＰパケット（ＲＴＰ連続番号およびＲＴＰタイムスタンプによって示される）が削除される。復号に対する正確な時間を決定するために、適切なストリーム間の同期を可能にするために可能性がある意図的な遅延などの要因が考慮されなければならない（be factored in）。

【0084】

[0094]両端値を含む０〜４７の範囲内の（in the range of 0 to 47, inclusive）ＮＡＬユニットタイプ値を有するＮＡＬユニットだけが、デコーダに送られ得る。両端値を含む４８〜６３の範囲内のＮＡＬユニットタイプ値を有するＮＡＬユニットのような構造（NAL-unit-like structures）は、デコーダに送られてはならない。

【0085】

[0095]受信機は、適用可能であるとき、ＮＡＬユニットを送信順序からＮＡＬユニット復号順序に並べ替えて、ＭＳＴにおけるＮＡＬユニット復号順序を復元するために、送信遅延ジッタ（transmission delay jitter）を補償するために使用される受信機バッファを含む。このセクションでは、受信機動作が、送信遅延ジッタがないものと仮定して説明される。送信遅延ジッタの補償のためにも使用される実際的な受信機バッファとの相違を生じさせるために、受信機バッファは、この後、このセクションにおいてパケット化解除バッファと呼ばれる。受信機はまた、送信遅延ジッタに備えるべきであり、すなわち、送信遅延ジッタバッファリングおよびパケット化解除バッファリングのために個別のバッファを確保すること、または送信遅延ジッタとパケット化解除の両方のための受信機バッファを使用することのいずれかを行うべきである。その上、受信機は、たとえば、復号および再生を開始する前の追加の初期バッファリングによって、バッファリング動作において送信遅延ジッタを考慮に入れるべきである。

【0086】

[0096]受信機には、初期バッファリングとプレイ中のバッファリングとの２つのバッファリング状態がある。初期バッファリングは、受信が初期化されるときに開始する。初期バッファリングの後、復号および再生が開始され、プレイ中のバッファリングモードが使用される。

【0087】

[0097]受信機は、着呼パケットを受信順に受信機バッファに記憶し、各セッションのＲＴＰパケット内のＮＡＬユニットをＲＴＰ連続番号順に再多重化バッファに送る。ＣＳ−ＤＯＮ値が、再多重化バッファ内の各ＮＡＬユニットに対して計算され、記憶される。

【0088】

[0098]バッファリング状態とは関係なく、受信機は、着信ＮＡＬユニットを受信順にパケット化解除バッファに記憶する。シングルＮＡＬユニットパケット、ＡＰ、およびＦＵ内で搬送されるＮＡＬユニットは、個別にパケット化解除バッファに記憶され、ＡｂｓＤｏｎの値が、各ＮＡＬユニットに対して計算され、記憶される。

【0089】

[0099]初期バッファリングは、条件Ａ（パケット化解除バッファ内のＮＡＬユニットの数が最高のＲＴＰセッションのｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓの値より大きい）が真になるまで続く。初期バッファリングの後、条件Ａが真になるとすぐに、条件Ａが偽になるまで、以下の動作が繰返し適用される：ＡｂｓＤｏｎの最小の値を有するパケット化解除バッファ内のＮＡＬユニットが、パケット化解除バッファから削除されてデコーダに送られる。

【0090】

[0100]ＮＡＬユニットが、それ以上パケット化解除バッファに流入しないとき、パケット化解除バッファに残されたすべてのＮＡＬユニットが、そのバッファから削除され、ＡｂｓＤｏｎ値が増加する順番にデコーダに送られる。

【0091】

[0101]メディアタイプ登録（Media type registration）が、次に説明される。ＨＥＶＣコーデックに対するメディアサブタイプが、ＩＥＴＦツリーから割り振られる。
受信機は、すべての指定されていないパラメータを無視しなければならない。
メディアタイプ名：ビデオ
メディアサブタイプ名：Ｈ２６５
要求されるパラメータ：なし
オプションのパラメータ：
ｔｘ−ｍｏｄｅ：
このパラメータは、送信モードがＳＳＴまたはＭＳＴのいずれであるかを示す。このパラメータは、１つの特定のセッション内のすべてのパケットに適用されるメディアタイプパラメータであり得る。言い換えれば、その値は、そのセッションのすべてのパケットに対して固定され得る。
ｔｘ−ｍｏｄｅの値は、「ＭＳＴ」または「ＳＳＴ」のいずれかに等しくなければならない。存在しないとき、ｔｘ−ｍｏｄｅの値は、「ＳＳＴ」に等しくなると推論される。
値が「ＭＳＴ」に等しい場合、ＭＳＴが使用されていなければならない。そうでない（値が「ＳＳＴ」に等しい）場合、ＳＳＴが使用されていなければならない。
ｔｘ−ｍｏｄｅの値は、ＭＳＴにおけるすべてのＲＴＰセッションに対して「ＭＳＴ」に等しくなければならない。
ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓ：
このパラメータは、受信順序におけるパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序におけるＮＡＬユニットに続く、ＮＡＬユニットの最大数を指定し得る。このパラメータは、１つの特定のセッション内のすべてのパケットに適用されるメディアタイプパラメータであり得る。言い換えれば、その値は、そのセッションのすべてのパケットに対して固定され得る。
ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓの値は、両端値を含む０〜３２７６７の範囲内の整数でなければならない。
存在しないとき、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓの値は、０に等しくなると推論される。
ＲＴＰセッションが１つまたは複数の他のＲＴＰセッションに依存するとき（この場合には、ｔｘ−ｍｏｄｅは「ＭＳＴ」に等しくなければならない）、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓの値は、０より大きくなければならない。
ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｂｙｔｅｓ：
このパラメータは、パケット化解除バッファの要求されるサイズをバイトの単位でシグナリングする。パラメータの値は、セクション６で指定されるパケット化解除バッファの最大バッファ占有（バイトの単位で）以上でなければならない。
ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｂｙｔｅｓの値は、両端値を含む０〜４２９４９６７２９５の範囲内の整数でなければならない。
ｄｅｐａｃｋ−ｂｕｆ−ｃａｐ：
このパラメータは、受信機実装形態の能力をシグナリングし、ＮＡＬユニット復号順序を再構成するために利用可能な、受信機が有するバイトの単位におけるパケット化解除バッファ空間の量を示す。受信機は、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｂｙｔｅｓパラメータの値が、このパラメータ以下である任意のストリームを取り扱うことができる。
存在しないとき、ｄｅｐａｃｋ−ｂｕｆ−ｒｅｑの値は０に等しくなると推論される。ｄｅｐａｃｋ−ｂｕｆ−ｃａｐの値は、両端値を含む０〜４２９４９６７２９５の範囲内の整数でなければならない。

【0092】

[0102]図３は、本開示で説明する技法を実装し得る例示的なビデオエンコーダ２０を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングとインターコーディングとを実施することができる。イントラコーディングは、空間的予測に依存し、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去する。インターコーディングは、時間的予測に依存し、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード（Ｉモード）は、いくつかの空間ベースの圧縮モードのいずれかを指す場合がある。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースの圧縮モードのいずれかを指す場合がある。

【0093】

[0103]図３の例では、ビデオエンコーダ２０は、区分ユニット３５と、予測処理ユニット４１と、フィルタユニット６３と、ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。予測処理ユニット４１は、動き推定ユニット４２と、動き補償ユニット４４と、イントラ予測処理ユニット４６とを含む。ビデオブロックの再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換処理ユニット６０と、加算器６２とを含む。フィルタユニット６３は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ）、およびサンプル適応オフセット（ＳＡＯ）フィルタなど、１つまたは複数のループフィルタを表すように意図されている。図３では、フィルタユニット６３はループ内フィルタであるとして示されているが、他の構成では、フィルタユニット６３はポストループフィルタとして実装され得る。図３はまた、ビデオエンコーダ２０によって生成された符号化ビデオデータに対して追加の処理を実行し得る後処理デバイス５７を示す。ある事例では、本開示の技法は、ビデオエンコーダ２０によって実装され得る。しかしながら、他の事例では、本開示の技法は後処理デバイス５７によって実装され得る。たとえば、ある事例では、図１のパケッタイザ２１に関して説明された技法は、後処理デバイス５７のパケッタイザによって実行され得る。

【0094】

[0104]図３に示されているように、ビデオエンコーダ２０はビデオデータを受信し、区分ユニット３５はデータをビデオブロックに区分する。この区分は、たとえば、ＬＣＵおよびＣＵの４分木構造に従って、スライス、タイル、または他のより大きいユニットへの区分、ならびにビデオブロック区分をも含み得る。ビデオエンコーダ２０は、一般に、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに（および、場合によっては、タイルと呼ばれるビデオブロックのセットに）分割され得る。予測処理ユニット４１は、誤差結果（たとえばコーディングレートおよびひずみのレベル）に基づいて現在のビデオブロックについて、複数のイントラコーディングモードの１つ、または複数のインターコーディングモードの１つなど、複数の可能なコーディングモードの１つを選択することができる。予測処理ユニット４１は、得られたイントラコード化ブロックまたはインターコード化ブロックを、残差ブロックデータを生成するために加算器５０に与え、参照ピクチャとして使用するための符号化ブロックを再構成するために加算器６２に与え得る。

【0095】

[0105]予測処理ユニット４１内のイントラ予測処理ユニット４６は、空間圧縮を行うために、コーディングされるべき現在ブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して現在ビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット４１内の動き推定ユニット４２および動き補償ユニット４４は、時間圧縮を行うために、１つまたは複数の参照ピクチャ中の１つまたは複数の予測ブロックに対する現在のビデオブロックのインター予測コーディングを実行する。

【0096】

[0106]動き推定ユニット４２は、ビデオシーケンスの所定のパターンに従ってビデオスライスのためのインター予測モードを決定するように構成され得る。所定のパターンは、シーケンス中のビデオスライスをＰスライス、ＢスライスまたはＧＰＢスライスに指定し得る。動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実施される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する現在ビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。

【0097】

[0107]予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのＰＵにぴったり一致することがわかるブロックである。いくつかの例では、ビデオエンコーダ２０は、ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実施し、分数ピクセル精度で動きベクトルを出力し得る。

【0098】

[0108]動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライスにおけるビデオブロックのＰＵのための動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択されてよく、それらの参照ピクチャリストの各々は、ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。

【0099】

[0109]動き補償ユニット４４によって実行される動き補償は、動き推定によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを伴い得る。現在ビデオブロックのＰＵについての動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいて指す予測ブロックの位置を特定し得る。ビデオエンコーダ２０は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって残差ビデオブロックを形成する。ピクセル差分値は、ブロックの残差データを形成し、ルーマとクロマの両方の差分成分を含み得る。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。動き補償ユニット４４はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するための、ビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。

【0100】

[0110]イントラ予測処理ユニット４６は、前述のように、動き推定ユニット４２と動き補償ユニット４４とによって実行されるインター予測の代替として、現在のブロックをイントラ予測し得る。特に、イントラ予測処理ユニット４６は、現在のブロックを符号化するために使用するようにイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット４６は、たとえば、別個の符号化パス中において、様々なイントラ予測モードを使用して現在のブロックを符号化することができ、イントラ予測処理ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択することができる。たとえば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化されたブロックと、符号化されたブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化されたブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを決定するために、様々な符号化されたブロックのひずみおよびレートから比率を計算し得る。

【0101】

[0111]いずれかの場合においても、ブロックのためのイントラ予測モードを選択した後に、イントラ予測処理ユニット４６は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット５６に与え得る。エントロピー符号化ユニット５６は、本開示の技法に従って選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ２０は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブルおよび複数の変更されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々について使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および変更されたイントラ予測モードインデックステーブルのインジケーションとを含み得る、構成データを含み得る。

【0102】

[0112]予測処理ユニット４１が、インター予測またはイントラ予測のいずれかを介して、現在のビデオブロックのための予測ブロックを生成した後、ビデオエンコーダ２０は、現在のビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロック中の残差ビデオデータは、１つまたは複数のＴＵ中に含まれ、変換処理ユニット５２に適用され得る。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ）または概念的に同様の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット５２は、残差ビデオデータをピクセル領域から周波数領域などの変換領域に変換し得る。

【0103】

[0113]変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送ることができる。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行することができる。代替的に、エントロピー符号化ユニット５６が走査を実行してよい。

【0104】

[0114]量子化の後、エントロピー符号化ユニット５６は、量子化された変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピー符号化方法または技法を実行し得る。エントロピー符号化ユニット５６によるエントロピー符号化の後に、符号化ビットストリームは、ビデオデコーダ３０に送信され得るか、またはビデオデコーダ３０が後で送信するかもしくは取り出すためにアーカイブされ得る。エントロピー符号化ユニット５６はまた、コード化されている現在のビデオスライスのための動きベクトルと他のシンタックス要素とをエントロピー符号化し得る。

【0105】

[0115]逆量子化ユニット５８および逆変換処理ユニット６０は、参照ピクチャの参照ブロックとして後で使用するために、ピクセル領域において残差ブロックを再構成するために、それぞれ逆量子化および逆変換を適用する。動き補償ユニット４４は、残差ブロックを参照ピクチャリストのうちの１つ内の参照ピクチャのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、再構成された残差ブロックに１つまたは複数の補間フィルタを適用し得る。加算器６２は、再構成された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、ピクチャメモリ６４に記憶するための参照ブロックを生成する。参照ブロックは、後続のビデオフレームまたはピクチャ中のブロックをインター予測するために動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。

【0106】

[0116]図４は、本開示で説明する技法を実装し得る例示的なネットワークエンティティ７９とビデオデコーダ３０とを示すブロック図である。図４の例では、ビデオデコーダ３０は、エントロピー復号ユニット８０と、予測処理ユニット８１と、逆量子化ユニット８６と、逆変換処理ユニット８８と、加算器９０と、フィルタユニット９１と、ピクチャメモリ９２とを含む。予測処理ユニット８１は、動き補償ユニット８２と、イントラ予測処理ユニット８４とを含む。ビデオデコーダ３０は、いくつかの例では、図３のビデオエンコーダ２０に関して説明された符号化パスとは概して逆の復号パスを実行し得る。

【0107】

[0117]復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化されたビデオスライスのビデオブロックと、関連付けられるシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオデコーダ３０は、ネットワークエンティティ７９から符号化されたビデオビットストリームを受信することができる。ネットワークエンティティ７９は、たとえば、上記で説明した技法のうちの１つまたは複数を実装するように構成されたサーバ、ＭＡＮＥ、ビデオエディタ／スプライサ（splicer）、または他のそのようなデバイスであり得る。ネットワークエンティティ７９は、ビデオエンコーダ２０を含むことも、含まないこともある。上記で説明したように、本開示で説明する技法のいくつかは、ネットワークエンティティ７９が符号化ビデオビットストリームをビデオデコーダ３０に送信するより前にネットワークエンティティ７９によって実装され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ７９およびビデオデコーダ３０は別個のデバイスの一部であり得るが、他の事例では、ネットワークエンティティ７９に関して説明する機能は、ビデオデコーダ３０を備える同じデバイスによって実行され得る。図１は、宛先デバイス１４の一部としてデパケッタイザ２９を示すが、デパケッタイザ２９に関して上記で説明した技法は、同じく、ネットワークエンティティ７９内のデパケッタイザによって実行されてもよい。

【0108】

[0118]復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化されたビデオスライスのビデオブロックと、関連付けられるシンタックス要素とを表す符号化されたビデオビットストリームを受信する。ビデオブロックは、たとえば、図１のＭＡＮＥ ２７または図４のネットワークエンティティ７９など、１つまたは複数のＭＡＮＥを介してビデオエンコーダ２０からビデオデコーダ３０にルーティングされ得る。ビデオデコーダ３０のエントロピー復号ユニット８０は、量子化された係数と、動きベクトルと、他のシンタックス要素とを生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット８０は、動きベクトルと他のシンタックス要素とを予測処理ユニット８１に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。

【0109】

[0119]ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされたとき、予測処理ユニット８１のイントラ予測処理ユニット８４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（すなわち、Ｂ、ＰまたはＧＰＢ）スライスとしてコーディングされたとき、予測処理ユニット８１の動き補償ユニット８２は、エントロピー復号ユニット８０から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャのうち１つから生成され得る。ビデオデコーダ３０は、ピクチャメモリ９２に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト０とリスト１とを構成し得る。

【0110】

[0120]動き補償ユニット８２は、動きベクトルと他のシンタックス要素とを解析することによって現在のビデオスライスのビデオブロックについての予測情報を決定し、復号されている現在のビデオブロックのための予測ブロックを生成するために予測情報を使用する。たとえば、動き補償ユニット８２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、Ｂスライス、Ｐスライス、またはＧＰＢスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数のための構成情報と、スライスの各インター符号化ビデオブロックのための動きベクトルと、スライスの各インターコーディングビデオブロックのためのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを決定するために、受信されたシンタックス要素のいくつかを使用する。

【0111】

[0121]動き補償ユニット８２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット８２は、参照ブロックのサブ整数ピクセルのための補間された値を計算するために、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用し得る。この場合、動き補償ユニット８２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。

【0112】

[0122]逆量子化ユニット８６は、ビットストリーム中で与えられ、エントロピー復号ユニット８０によって復号された量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ２０によって計算される量子化パラメータの使用を含み得る。逆変換処理ユニット８８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。

【0113】

[0123]動き補償ユニット８２が、動きベクトルと他のシンタックス要素とに基づいて現在ビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換処理ユニット８８からの残差ブロックを動き補償ユニット８２によって生成された対応する予測ブロックと加算することによって、復号されたビデオブロックを形成する。加算器９０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ピクセル遷移を平滑化するために、または場合によってはビデオ品質を改善するために、（コーディングループ内またはコーディングループ後のいずれかの）ループフィルタも使用され得る。フィルタユニット９１は、デブロッキングフィルタ、適応ループフィルタ（ＡＬＦ）、およびサンプル適応オフセット（ＳＡＯ）フィルタなど、１つまたは複数のループフィルタを表すように意図されている。図４では、フィルタユニット９１はループ内フィルタであるとして示されているが、他の構成では、フィルタユニット９１はポストループフィルタとして実装され得る。所与のフレームまたはピクチャ中の復号されたビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶するピクチャメモリ９２に記憶される。ピクチャメモリ９２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上での後の提示のために、復号されたビデオを記憶する。

【0114】

[0124]図５は、ネットワーク１５０の一部を形成するデバイスの例示的なセットを示すブロック図である。この例では、ネットワーク１５０は、ルーティングデバイス１５４Ａ、１５４Ｂ（ルーティングデバイス１５４）と、トランスコーディングデバイス１５６とを含む。ルーティングデバイス１５４およびトランスコーディングデバイス１５６は、ネットワーク１５０の一部を形成し得る少数のデバイスを表すことが意図される。スイッチ、ハブ、ゲートウェイ、ファイアウォール、ブリッジ、および他のそのようなデバイスなどの他のネットワークデバイスも、ネットワーク１５０内に含まれ得る。その上、サーバデバイス１５２とクライアントデバイス１５８との間にネットワーク経路に沿って追加のネットワークデバイスが提供され得る。いくつかの例では、サーバデバイス１５２はソースデバイス１２（図１）に対応し得る一方、クライアントデバイス１５８は宛先デバイス１４（図１）に対応し得る。ルーティングデバイス１５４は、たとえば、メディアデータをルーティングするように構成されたＭＡＮＥであり得る。

【0115】

[0125]概して、ルーティングデバイス１５４は、ネットワーク１５０を介してネットワークデータを交換するための１つまたは複数のルーティングプロトコルを実装する。概して、ルーティングデバイス１５４は、ネットワーク１５０を介したルートを発見するためにルーティングプロトコルを実行する。そのようなルーティングプロトコルを実行することによって、ルーティングデバイス１５４Ｂは、それ自体からルーティングデバイス１５４Ａを介してサーバデバイス１５２へ至るネットワークルートを発見し得る。図５の様々なデバイスは、本開示の技法を実装し得、本開示の技法に従ってＲＴＰデータを処理するように構成され得るデバイスの例を表す。

【0116】

[0126]図６は、本開示の技法によるビデオデータを処理する方法の一例を示す。図６の技法は、たとえば、宛先デバイス１４などのデバイスによって実行され得、より詳細には、宛先デバイス１４のデパケッタイザ２９によって実行され得る。デパケッタイザ２９は、ＲＴＰプロトコルに従って第１のアグリゲーションパケットを受信する（１６０）。第１のアグリゲーションパケットは、たとえば、ペイロードヘッダと１つまたは複数のアグリゲーションユニットとを含み得る。デパケッタイザ２９は、第１のパラメータに関する値を決定するために第１のアグリゲーションユニットを解析し得る（１６２）。第１のパラメータは、たとえば、上記で説明したＤＯＮＬパラメータに対応し得、復号順序番号を指定し得る。デパケッタイザ２９は、第２のパラメータに関する値を決定するために第２のアグリゲーションユニットを解析し得る（１６４）。第２のアグリゲーションユニットは、第１のアグリゲーションユニットに後続し得、第２のパラメータは、たとえば、上記で説明したＤＯＮＤパラメータに対応し得る。第１のパラメータおよび第２のパラメータに基づいて、デパケッタイザ２９は、第２のアグリゲーションユニットに対する復号順序を決定する。

【0117】

[0127]図７は、本開示の技法によるビデオデータを処理する方法の一例を示す。図７の技法は、たとえば、ソースデバイス１２などのデバイスによって実行され得、より詳細には、ソースデバイス１２のパケッタイザ２１によって実行され得る。パケッタイザ２１は、１つまたは複数のＮＡＬユニットを受信し、ＲＴＰプロトコルに従って１つまたは複数のＮＡＬユニットを第１のアグリゲーションパケット内にパケット化する（１７０）。第１のアグリゲーションパケットは、たとえば、ペイロードヘッダと１つまたは複数のアグリゲーションユニットとを含み得る。パケッタイザ２１は、第１のアグリゲーションユニット内に含まれるＮＡＬユニットに関する復号順序番号に基づいて、第１のアグリゲーションユニットの第１のパラメータに関する値を設定する（１７２）。第１のパラメータは、たとえば、上記で説明したＤＯＮＬパラメータに対応し得、復号順序番号を指定し得る。第１のパラメータは、たとえば、復号順序番号の最下位ビットの数の値を指定し得る。第２のアグリゲーションユニット内に含まれるＮＡＬユニットに関する復号順序と第１のアグリゲーションユニット内に含まれるＮＡＬユニットに関する復号順序番号との間の差分に基づいて、パケッタイザ２１は、第２のアグリゲーションユニットの第２のパラメータに関する値を設定し得る（１７４）。第２のアグリゲーションユニットは、第１のアグリゲーションユニットに後続し得、第２のパラメータは、たとえば、上記で説明したＤＯＮＤパラメータに対応し得る。第２のパラメータは、たとえば、第１のパラメータと復号順序番号との間の差分を識別し得る。

【0118】

[0128]図８は、本開示の技法によるビデオデータを処理する方法の一例を示す。図８の技法は、たとえば、宛先デバイス１４などのデバイスによって実行され得、より詳細には、宛先デバイス１４のデパケッタイザ２９によって実行され得る。デパケッタイザ２９は、フラグメント化されたＮＡＬユニットのサブセットを含む第１のフラグメンテーションユニットを受信する（１８０）。デパケッタイザ２９は、第１のフラグメンテーションユニットがフラグメント化されたＮＡＬユニットの開始を含むかどうかを決定するために、フラグメンテーションユニットの開始ビットを解析する（１８２）。開始ビットは、たとえば、上記で説明したＳビットであり得る。第１のフラグメンテーションユニットがフラグメント化されたＮＡＬユニットの開始を含むことと、第１のフラグメンテーションユニットに関する送信モードがマルチセッション送信モードであることおよび第１のパラメータが第１の値より大きいことの一方または両方とに応答して、デパケッタイザ２９は、フラグメント化されたＮＡＬユニットに関する復号順序を決定するために第２のパラメータを解析する。第１のパラメータは、たとえば、上記で説明したｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータであり得、第１の値はゼロであり得る。第２のパラメータは、たとえば、上記で説明したＤＯＮＬパラメータであり得る。宛先デバイス１４は、決定された復号順序に基づいてフラグメント化されたＮＡＬユニットを復号し得る（１８６）。

【0119】

[0129]図９は、本開示の技法によるビデオデータを処理する方法の一例を示す。図９の技法は、たとえば、ソースデバイス１２などのデバイスによって実行され得、より詳細には、ソースデバイス１２のパケッタイザ２１によって実行され得る。パケッタイザ２１は、フラグメント化されたＮＡＬユニットのサブセットを備える第１のフラグメンテーションユニットを生成する（１９０）。第１のフラグメンテーションユニットは、たとえば、フラグメント化されたＮＡＬユニットの開始を含む。パケッタイザ２１は、第１のフラグメンテーションユニットがフラグメント化されたＮＡＬユニットの開始を含むことを示すために、フラグメンテーションユニットの開始ビットを設定する（１９２）。開始ビットは、たとえば、上記で説明したＳビットであり得る。第１のフラグメンテーションユニットがフラグメント化されたＮＡＬユニットの開始を含むことと、第１のフラグメンテーションユニットに関する送信モードがマルチセッション送信モードであることおよび第１のパラメータが第１の値より大きいことの一方または両方とに応答して。パケッタイザ２１は、フラグメント化されたＮＡＬユニットに関する復号順序を示すために、第２のパラメータを設定する。第１のパラメータは、たとえば、上記で説明したｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータであり得、第１の値はゼロであり得る。第２のパラメータは、たとえば、上記で説明したＤＯＮＬパラメータであり得る。パケッタイザ２１は、フラグメント化されたＮＡＬユニットを送信し得る（１９６）。第１のパラメータは、たとえば、受信順序におけるパケット化解除バッファ内の第１のＮＡＬユニットに先行し、復号順序における第１のＮＡＬユニットに後続するＮＡＬユニットの最大数を指定し得、第２のパラメータは、復号順序番号の最下位ビットの数の値を指定し得る。

【0120】

[0130]図１０は、本開示の技法によるビデオデータを処理する方法の一例を示す。図８の技法は、たとえば、宛先デバイス１４などのデバイスによって実行され得、より詳細には、宛先デバイス１４のデパケッタイザ２９によって実行され得る。デパケッタイザ２９は、第１のＮＡユニットを備える第１のＲＴＰパケットを受信する（２００）。第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、デパケッタイザ２９は、第１のＮＡＬユニットの送信順序に基づいて第１のＮＡＬユニットに関する復号順序番号を決定する（２０２）。第１のパラメータは、たとえば、上記で説明したｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータであり得、その値はゼロに等しくてよい。

【0121】

[0131]図１１は、本開示の技法によるビデオデータを処理する方法の一例を示す。図９の技法は、たとえば、ソースデバイス１２などのデバイスによって実行され得、より詳細には、ソースデバイス１２のパケッタイザ２１によって実行され得る。第１のＮＡ）ユニットを備えるＲＴ）パケットを生成するパケッタイザ２１（２１０）。第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、第１のＮＡＬユニットに関する復号順序に基づいて第１のＮＡＬユニットに関する送信順序を設定すること（２１２）。第１のパラメータは、たとえば、上記で説明したｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータであり得る。

【0122】

[0132]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実現され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されてよく、あるいは、コンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する任意の媒体を含む、データ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法を実装するための命令、コードおよび／またはデータ構造を取り出すために、１つもしくは複数のコンピュータ、または１つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含む場合がある。

【0123】

[0133]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時の媒体を含まないが、代わりに非一時の有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、この場合、ディスク（disk）は、通常、データを磁気的に再生し、一方、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

【0124】

[0134]命令は、１つもしくは複数のデジタルシグナルプロセッサ（ＤＳＰ）などの１つもしくは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路によって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明された技法の実施に適した任意の他の構造のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明された機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に設けられる場合があるか、または複合コーデックに組み込まれる場合がある。また、本技法は、１つまたは複数の回路または論理要素に完全に実装され得る。

【0125】

[0135]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置の中に実装される場合がある。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットが説明されたが、それらの構成要素、モジュール、またはユニットは、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、前述のように、適切なソフトウェアおよび／またはファームウェアとともに、様々なユニットがコーデックハードウェアユニットにおいて組み合わせられ得るか、または前述のような１つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合体によって設けられ得る。

【0126】

［0136]種々の例が記載された。これらおよび他の例は、以下の特許請求の範囲内にある。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ビデオデータを処理する方法であって、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットの送信順序に基づいて前記第１のＮＡＬユニットに関する復号順序番号を決定することと、
を備える、方法。
［Ｃ２］前記第１のパラメータが、受信順序におけるパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序における前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定する、Ｃ１に記載の方法。
［Ｃ３］前記第１の値が０に等しい、Ｃ２に記載の方法。
［Ｃ４］前記最大数が３２７６７に等しい、Ｃ２に記載の方法。
［Ｃ５］前記復号順序番号が、送信順序番号に等しい、Ｃ１に記載の方法。
［Ｃ６］第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＲＴＰパケットに関する送信モードがマルチセッション送信モードであることに応答して、および前記第２のＮＡＬユニットが送信順序における第１のＮＡＬユニットであることに応答して、前記第２のＮＡＬユニットが復号順序において最初であることを決定することと、
をさらに備える、Ｃ１に記載の方法。
［Ｃ７］第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＮＡＬユニットに関する復号順序番号が前記第１のＮＡＬユニットに関する前記復号順序番号に等しいことに応答して、前記第１のＮＡＬユニットを復号する前に前記第２のＮＡＬユニットを復号することと、
をさらに備える、Ｃ１に記載の方法。
［Ｃ８］前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、Ｃ１に記載の方法。
［Ｃ９］ビデオデータを処理するためのデバイスであって、装置が、
メモリと、
リアルタイムトランスポートプロトコル（ＲＴＰ）パケットのために構成された受信機と、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットの送信順序に基づいて前記第１のＮＡＬユニットに関する復号順序番号を決定することと、
を行うように構成された１つまたは複数のプロセッサと、
を備える、デバイス。
［Ｃ１０］前記第１のパラメータが、受信順序におけるパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序における前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定する、Ｃ９に記載のデバイス。
［Ｃ１１］前記第１の値が０に等しい、Ｃ１０に記載のデバイス。
［Ｃ１２］前記最大数が３２７６７に等しい、Ｃ１０に記載のデバイス。
［Ｃ１３］前記復号順序番号が、送信順序番号に等しい、Ｃ９に記載のデバイス。
［Ｃ１４］前記１つまたは複数のプロセッサが、
第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＲＴＰパケットに関する送信モードがマルチセッション送信モードであることに応答して、および前記第２のＮＡＬユニットが送信順序における第１のＮＡＬユニットであることに応答して、前記第２のＮＡＬユニットが復号順序において最初であることを決定することと、
を行うようにさらに構成される、Ｃ９に記載のデバイス。
［Ｃ１５］前記１つまたは複数のプロセッサが、
第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＮＡＬユニットに関する復号順序番号が前記第１のＮＡＬユニットに関する前記復号順序番号に等しいことに応答して、前記第１のＮＡＬユニットを復号する前に前記第２のＮＡＬユニットを復号することと、
を行うようにさらに構成される、Ｃ９に記載のデバイス。
［Ｃ１６］前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、Ｃ９に記載のデバイス。
［Ｃ１７］前記デバイスが、
集積回路と、
マイクロプロセッサと、
ビデオコーダを備えるワイヤレス通信デバイスと、
のうちの少なくとも１つを備える、Ｃ９に記載のデバイス。
［Ｃ１８］命令を記憶するコンピュータ可読記憶媒体であって、前記命令が、１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを受信することと、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットの送信順序に基づいて前記第１のＮＡＬユニットに関する復号順序番号を決定することと、
を行わせる、コンピュータ可読記憶媒体。
［Ｃ１９］前記第１のパラメータが、受信順序におけるパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序における前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定する、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２０］前記第１の値が０に等しい、Ｃ１９に記載のコンピュータ可読記憶媒体。
［Ｃ２１］前記最大数が３２７６７に等しい、Ｃ１９に記載のコンピュータ可読記憶媒体。
［Ｃ２２］前記復号順序番号が、送信順序番号に等しい、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２３］前記１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＲＴＰパケットに関する送信モードがマルチセッション送信モードであることに応答して、および前記第２のＮＡＬユニットが送信順序における第１のＮＡＬユニットであることに応答して、前記第２のＮＡＬユニットが復号順序において最初であることを決定することと、
を行わせるさらなる命令を記憶する、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２４］前記１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
第２のＮＡＬユニットを備える第２のＲＴＰパケットを受信することと、
前記第２のＮＡＬユニットに関する復号順序番号が前記第１のＮＡＬユニットに関する前記復号順序番号に等しいことに応答して、前記第１のＮＡＬユニットを復号する前に前記第２のＮＡＬユニットを復号することと、
を行わせるさらなる命令を記憶する、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２５］前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２６］ビデオデータを処理する方法であって、
第１のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備える第１のリアルタイムトランスポートプロトコル（ＲＴＰ）パケットを生成することと、
前記第１のＲＴＰパケットに関する送信モードがシングルセッション送信モードであることおよび第１のパラメータが第１の値に等しいことに応答して、前記第１のＮＡＬユニットに関する復号順序に基づいて前記第１のＮＡＬユニットに関する送信順序を設定することと、
を備える、方法。
［Ｃ２７］前記第１のパラメータが、受信順序におけるパケット化解除バッファ内の前記第１のＮＡＬユニットに先行し、復号順序における前記第１のＮＡＬユニットに後続する、ＮＡＬユニットの最大数を指定する、Ｃ２６に記載の方法。
［Ｃ２８］前記第１の値が０に等しい、Ｃ２７に記載の方法。
［Ｃ２９］前記最大数が３２７６７に等しい、Ｃ２７に記載の方法。
［Ｃ３０］前記ＲＴＰパケットが、単一のＮＡＬユニットパケットを備える、Ｃ２６に記載の方法。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】