JP6073527B2

JP6073527B2 - ビデオコーディングのための復号順序番号を有するシングルネットワークアブストラクションレイヤユニットパケット

Info

Publication number: JP6073527B2
Application number: JP2016517055A
Authority: JP
Inventors: コバン、ムハンメド・ゼイド; ワン、イェ−クイ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2013-05-31
Filing date: 2014-05-30
Publication date: 2017-02-01
Anticipated expiration: 2034-05-30
Also published as: CN105230016B; KR20160016937A; EP3005700A1; US9350781B2; ES2734551T3; HUE044189T2; WO2014194243A1; EP3005700B1; KR101739682B1; CN105230016A; JP2016526350A; US20140355616A1

Description

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

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

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

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

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

[0006]ビデオデータは、１つまたは複数のプロトコルを使用して送信および受信され得る。各プロトコルは、プロトコルを使用するときにデータの送信および／または受信に対する様々なコンテンツおよびフォーマットの要件を指定し得る。たとえば、いくつかのプロトコルは、１つまたは複数のネットワークを介するトランスポートのために、データのストリームまたはセットをチャンクに分離し得る。いくつかのプロトコルでは、この分離手順は、パケット化またはフレーミングと呼ばれることがある。

[0007]本開示の技法は、リアルタイムトランスポートプロトコル（ＲＴＰ：Real-time Transport Protocol）などのネットワークプロトコルを使用して送られ受信されるビデオデータを処理するための方法と装置とを提供する。より具体的には、本明細書で説明される技法は、様々な送信パラメータおよびモードとともに使用可能なシングルＮＡＬユニットパケットフォーマットを提供する。

[0008]本開示の一例では、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法は、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ：single network abstraction layer）ユニットを含むシングルＮＡＬユニットパケット内にビデオデータをカプセル化することと、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいてシングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することとを含む。

[0009]本開示の別の例では、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法は、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むシングルＮＡＬユニットパケット内にカプセル化されたビデオデータをカプセル化解除することと、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、シングルＮＡＬユニットパケット内にカプセル化された復号順序番号情報をカプセル化解除することとを含む。

[0010]本開示の別の例では、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置は、ビデオデータを記憶するように構成されたメモリと、プロセッサとを含み、プロセッサは、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内で、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むシングルＮＡＬユニットパケット内にビデオデータをカプセル化することと、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいてシングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することとを行うように構成される。

[0011]本開示の別の例では、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置は、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むシングルＮＡＬユニットパケット内にビデオデータをカプセル化するための手段と、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあることまたは受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいてシングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化するための手段とを含む。

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

[0013]本開示で説明される技法を利用し得る例示的なビデオ符号化および復号システムを示す概念図。 [0014]ＨＥＶＣネットワークアブストラクションレイヤ（ＮＡＬ）ユニットヘッダの構造を示す概念図。 [0015]アグリゲーションパケットに対するリアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットの構造を示す概念図。 [0016]アグリゲーションパケット内の第１のアグリゲーションユニットの構造を示す概念図。 [0017]シングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットの構造を示す概念図。 [0018]本開示の技法によるシングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットの一例を示す概念図。 [0019]本開示の技法によるシングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットの別の例を示す概念図。 [0020]本開示で説明される技法を実施し得る例示的なビデオエンコーダを示す概念図。 [0021]本開示で説明される技法を実装し得る例示的なビデオデコーダを示すブロック図。 [0022]ネットワークの一部を形成するデバイスの例示的なセットを示すブロック図。 [0023]本開示の技法によるＲＴＰペイロードフォーマット内にビデオデータをカプセル化するための例示的な動作を示すフロー図。 [0024]本開示の技法によるＲＴＰペイロードフォーマット内にカプセル化されたビデオデータをカプセル化解除するための例示的な動作を示すフロー図。

[0025]本開示は、ビデオデータをパケット化するための様々な技法とデバイスとを導入する。１つまたは複数の例では、本開示は、ビデオデータをトランスポートするためのリアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットの改善された設計を提示する。詳細には、本開示は、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットのＲＴＰパケットに対する復号順序番号（ＤＯＮ）をシグナリングするための技法を提示する。シングルＮＡＬユニットパケットを送信するための以前の技法は、いくつかの送信モードおよび送信パラメータと適合しなかった。代わりに、以前の技法は、シングルＮＡＬユニットが、アグリゲーションパケット内で送信されることを必要とし、オーバーヘッドの増加とスループットの減少とを招いた。柔軟なシングルＮＡＬユニットパケット内に復号順序番号情報を含むことによって、本明細書で説明される技法は、シングルＮＡＬユニットのより効率的な送信を可能にし、様々な送信モードと送信パラメータとを有するシングルＮＡＬユニットパケットの使用を可能にし得る。

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

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

[0028]さらに、ＩＴＵ−Ｔビデオコーディングエキスパートグループ（ＶＣＥＧ）とＩＳＯ／ＩＥＣモーションピクチャエキスパートグループ（ＭＰＥＧ：Motion Picture Experts Group）とのビデオコーディング共同研究部会（ＪＣＴ−ＶＣ：Joint Collaboration Team on Video Coding）によって開発された新しいビデオコーディング規格、すなわち、高効率ビデオコーディング（ＨＥＶＣ）規格がある。「ＨＥＶＣＷｏｒｋｉｎｇＤｒａｆｔ１０」または「ＷＤ１０」と呼ばれるＨＥＶＣ規格の１つのドラフトは、文書ＪＣＴＶＣ−Ｌ１００３ｖ３４、Ｂｒｏｓｓら、「Ｈｉｇｈｅｆｆｉｃｉｅｎｃｙｖｉｄｅｏｃｏｄｉｎｇ（ＨＥＶＣ）ｔｅｘｔｓｐｅｃｉｆｉｃａｔｉｏｎｄｒａｆｔ１０」、ＩＴＵ−ＴＳＧ１６ＷＰ３とＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１とのビデオコーディング共同研究部会（ＪＣＴ−ＶＣ）、第１２回会合：スイス、ジュネーブ、２０１３年１月１４〜２３日に記載されており、この文書は、２０１４年４月３０日現在、ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ／ｊｃｔ／ｄｏｃ＿ｅｎｄ＿ｕｓｅｒ／ｄｏｃｕｍｅｎｔｓ／１２＿Ｇｅｎｅｖａ／ｗｇ１１／ＪＣＴＶＣ−Ｌ１００３−ｖ３４．ｚｉｐからダウンロード可能である。ＨＥＶＣＷＤ１０の内容全体は参照により本明細書に組み込まれる。

[0029]説明の目的で、ビデオエンコーダ２０およびビデオデコーダ３０については、ＨＥＶＣ規格またはＨ．２６４規格およびそのような規格の拡張のコンテキストにおいて説明される。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオ圧縮規格の他の例には、ＭＰＥＧ−２およびＩＴＵ−ＴＨ．２６３がある。Ｏｎ２ＶＰ６／ＶＰ７／ＶＰ８と呼ばれるものなど、プロプライエタリなコーディング技法もまた、本明細書で説明される技法のうちの１つまたは複数を実施し得る。本開示の技法は、ＨＥＶＣ他を含むいくつかのビデオコーディング規格に、潜在的に適用可能である。

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

[0031]代替的に、符号化されたデータは、出力インターフェース２２からストレージデバイス２７に出力され得る。同様に、符号化されたデータは、入力インターフェースによってストレージデバイス２７からアクセスされ得る。ストレージデバイス２７は、ハードドライブ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性のメモリ、あるいは符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体のような、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイス２７は、ソースデバイス１２によって生成された符号化されたビデオを保持し得る、ファイルサーバまたは別の中間ストレージデバイスに対応し得る。

[0032]宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイス２７から記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶し、その符号化されたビデオデータを宛先デバイス１４に送信することができる任意のタイプのサーバであり得る。例示的なファイルサーバとしては、（たとえば、ウェブサイト用の）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブがある。宛先デバイス１４は、インターネット接続を含むいずれかの標準データ接続を通して符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化されたビデオデータにアクセスするのに適しているワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含むことができる。ストレージデバイス２７からの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、または両方の組合せであり得る。ストレージデバイス２７から取り出されたビデオデータは、ＭＡＮＥ２９などの１つまたは複数のＭＡＮＥを使用して宛先デバイス１４にルーティングされ得る。

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

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

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

[0036]宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。場合によっては、入力インターフェース２８は受信機および／またはモデムを含み得る。たとえば、入力インターフェース２８は、本明細書で説明される技法に従ってＲＴＰペイロード内にカプセル化されたデータをカプセル化解除するように動作可能なＲＴＰパケット化解除ユニットを含み得る。宛先デバイス１４の入力インターフェース２８は、リンク１６を介して符号化ビデオデータを受信する。リンク１６を介して通信され、またはストレージデバイス２７上に提供された符号化されたビデオデータは、ビデオデータを復号する際にビデオデコーダ３０などのビデオデコーダが使用するための、ビデオエンコーダ２０によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信され、記憶媒体上に記憶される符号化されたビデオデータとともに含まれ得、またはファイルサーバを記憶した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0053]ＨＥＶＣ規格または他の規格に従って符号化されたビデオデータなどの符号化されたビデオデータは、様々な方法を使用して２つのデバイス間（たとえば、ソースデバイス１２と宛先デバイス１４との間）で送信され得る。たとえば、ビデオデータは、様々なネットワークプロトコルを使用して１つまたは複数のネットワークを介して送信され得る。いくつかのプロトコルは、送信のための様々なパラメータおよび／またはルールを指定し得る。たとえば、いくつかのプロトコルは、ネットワークを介して送信する前にデータを処理し、受信すると、そのデータを再処理することができ得る。いくつかの例では、データ（たとえば、符号化されたビデオデータ）を処理することは、データをいくつかのチャンクに分離すること（たとえば、データをパケット化またはフレーミングすること）を含み得る。リアルタイムストリーミング用途に対するビデオデータを送信するためのプロトコルの一例が、リアルタイムトランスポートプロトコル（ＲＴＰ）である。

[0054]ＲＴＰは、２０１４年４月３０日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５５０．ｔｘｔから入手可能であり、その全体が参照により本明細書に組み込まれる、ＩＥＴＦＲＦＣ３５５０において規定されたトランスポートプロトコルである。概して、ＲＴＰは、ＩＰネットワークを介してオーディオおよび／またはビデオを配信するための規格化されたパケットフォーマットを定義する。ＲＴＰは、テレフォニーサービス、ビデオ遠隔会議、テレビジョンサービス、他など、様々なストリーミングメディアを提供するために使用され得る。

[0055]ビデオコーデックによって符号化されたビデオデータをＲＴＰを介してトランスポートするために、ビデオコーデックに対するＲＴＰペイロードフォーマットが規定される必要がある。たとえば、ＲＦＣ６１８４（２０１４年４月３０日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ６１８４．ｔｘｔにおいて入手可能）は、Ｈ．２６４ビデオに対するＲＴＰペイロードフォーマットを規定し、ＲＦＣ６１９０（２０１４年４月３０日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ６１９０．ｔｘｔにおいて入手可能）は、ＳＶＣビデオに対するＲＴＰペイロードフォーマットを規定する。ＲＦＣ６１８４とＲＦＣ６１９０の両方は、それらの全体が参照により本明細書に組み込まれる。ＲＦＣ４６２９は、ＩＴＵ−ＴＲｅｃ．Ｈ．２６３に対するＲＴＰペイロードフォーマットを規定する。

[0056]加えて、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）、オーディオ／ビデオトランスポートペイロードワーキンググループによって開発されている新しいＲＴＰペイロード仕様、すなわち高効率ビデオコーディング（ＨＥＶＣ）に対するＲＴＰペイロードフォーマットがある。ＨＥＶＣビデオに対するＲＴＰペイロードフォーマットの最近のドラフトは、２０１４年４月３０日現在、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｉｅｔｆ−ｐａｙｌｏａｄ−ｒｔｐ−ｈ２６５−０２．ｔｘｔから入手可能であり、その全体が参照により本明細書に組み込まれる。

[0057]その全体が参照により本明細書に組み込まれる、２１０３年３月２９日に出願された米国仮出願第６１／８０６，７０５号に記載される改善を含む、ＨＥＶＣＲＴＰペイロードフォーマットの最新の設計は、単一のＲＴＰセッション（たとえば、単一のＲＴＰストリーム）または複数のＲＴＰセッション（たとえば、複数のＲＴＰストリーム）を介するＨＥＶＣビットストリームの送信を可能にする。ＲＴＰストリームは、単一のＲＴＰセッション内で搬送されるＲＴＰパケットのシーケンスであり得る。ＲＴＰセッションは、ＩＰアドレスと、ＲＴＰおよびＲＴＰ制御プロトコル（ＲＴＣＰ）データを受信するためのポートのペアとに対応し得る。ＲＴＣＰは、概して、関連付けられたＲＴＰストリームに対する帯域外統計と制御情報とを提供し得る。

[0058]ＨＥＶＣＲＴＰペイロードフォーマットのいくつかの概念および動作原理は、ＲＦＣ６１９０から受け継がれ、同様の設計を採用する。唯一のＲＴＰセッション（たとえば、１つのＲＴＰストリーム）がＨＥＶＣビットストリームの送信に使用される場合、送信モードは、シングルセッション（または、シングルストリーム）送信（ＳＳＴ）と呼ばれ、そうでない場合（たとえば、２つ以上のＲＴＰセッションがＨＥＶＣビットストリームの送信に使用される場合）、送信モードは、マルチセッション（または、マルチストリーム）送信（ＭＳＴ）と呼ばれる。ＳＳＴは、一般的に、ポイントツーポイントユニキャストのシナリオに対して使用され、一方、ＭＳＴは、帯域幅利用効率を改善するために、異なる受信機が同じＨＥＶＣビットストリームの異なる動作ポイントを要求する、ポイントツーマルチポイントマルチキャストのシナリオに対して使用される。ＳＳＴまたはＭＳＴのいずれが使用されようと、送信モードは、（たとえば、ＲＴＰセッションのセットアップの間に）セッション記述プロトコル（ＳＤＰ：Session Description Protocol）パラメータとして表現され得るメディアタイプパラメータ、ｔｘ−ｍｏｄｅによってシグナリングされる。

[0059]ＳＤＰパラメータとして指定され得る別のパラメータは、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータである。ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓは、受信順序においてパケット化解除バッファ（たとえば、ＲＴＰ受信機バッファ）内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数を指定するセッションパラメータである。復号順序は、概して、ＮＡＬユニットがビデオデコーダによって復号されるべき順序を示し得る。したがって、ビデオデコーダおよび／またはパケット化解除ユニットは、ＮＡＬユニットを処理する順序を決定するために受信されたＮＡＬユニットの復号順序を利用し得る。したがって、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓの値は、復号順序を外れて送信および／または受信され得るＮＡＬユニットの最大数を示し得る。

[0060]一例では、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値は、両端値を含む０〜３２７６７の範囲内の整数である。存在しないとき、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値は、０に等しくなると推論される。ＲＴＰセッションが１つまたは複数の他のＲＴＰセッションに依存するとき（この場合、送信モードは「ＭＳＴ」に等しい）、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値は、０より大きくなる。ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータに対するゼロより大きい値は、セッションがインタリーブされたパケット化を可能にすることを示す。言い換えれば、データユニットを送信するために複数のストリームを使用するとき、受信機バッファおよび／またはパケット化解除バッファは、インタリーブされたパケット化を処理する（たとえば、復号順序を外れて送信および／または受信されたデータユニットを処理する）ことができ得る。

[0061]ＲＴＰパケットは、１つのデバイスから別のデバイスに情報（たとえば、符号化されたビデオデータ）を搬送するためにセッションを介して送信される。ＲＴＰパケットは、ＲＴＰヘッダとＲＴＰペイロードとを含む。ＲＴＰヘッダは、ペイロード識別子を指定するためのＰａｙｌｏａｄＴｙｐｅフィールドを含む。ペイロード識別子は、対応するＲＴＰペイロードのフォーマットを示す。ＲＴＰ規格によって規定されるように、ペイロード識別子９６〜１２７が、セッションの間に動的に規定されるＲＴＰペイロードのために確保される。すなわち、９６〜１２７のペイロード識別子の値が、ＲＴＰペイロードを対応するＲＴＰセッションの持続時間の間に指定されたフォーマット（またはプロファイル）にマッピングし得る。いくつかの例では、セッションのＲＴＰペイロードに対する指定されたフォーマットは、ＳＤＰパラメータを使用して規定され得る。たとえば、ＳＤＰパラメータは、特定のセッションに対して、９８のペイロード識別子の値がＲＴＰペイロードに対するＨＥＶＣプロファイルを示すことを指定し得る。したがって、セッションを介して送られたＲＴＰパケットは、ＨＥＶＣ規格を使用して符号化されたビデオデータを含むＲＴＰペイロードを含み得る。このため、ＲＴＰペイロードは、ＮＡＬユニットを含み得る。

[0062]ＲＴＰペイロードに対するＨＥＶＣプロファイルの一例では、ＲＴＰペイロードの最初の２バイトは、ＲＴＰペイロードヘッダを表し得る。ＨＥＶＣに対するＲＴＰペイロードフォーマットに準拠するいくつかのＲＴＰペイロードに対して、ＲＴＰペイロードヘッダは、ＨＥＶＣに対するＮＡＬユニットヘッダと同じフィールドから成る。

[0063]図２は、ＨＥＶＣＮＡＬユニットヘッダの構造を示す概念図である。概して、ＨＥＶＣは、Ｈ．２６４のＮＡＬユニット概念を、いくぶんかの修正を伴いながら維持する。ＮＡＬユニットヘッダ内のフィールドのセマンティクスは、ＨＥＶＣＷＤ１０に指定されるとおりであり、便宜上以下に簡単に説明される。各フィールドの名称およびサイズに加えて、ＨＥＶＣＷＤ１０における対応するシンタックス要素名もまた提供される。説明のために、ＮＡＬユニットのペイロードデータは、本明細書では、ＮＡＬユニットヘッダを除外したＮＡＬユニットの部分を指す。すなわち、ＮＡＬユニットは、ＮＡＬユニットヘッダ（たとえば、ＮＡＬユニットのバイト１および２）およびＮＡＬユニットペイロード（たとえば、ＮＡＬユニットのバイト３〜Ｎ）から成り得る。

[0064]図１の例に示すシンタックス要素Ｆはシングルビットであり、ｆｏｒｂｉｄｄｅｎ＿ｚｅｒｏ＿ｂｉｔと呼ばれる。ＨＥＶＣＷＤ１０によれば、Ｆはゼロの値を有する。すなわち、ＨＥＶＣＷＤ１０は、シンタックス要素Ｆに対する１の値がシンタックス違反を構成することを規定する。ＮＡＬユニットヘッダ内にこのビットを包含することは、（たとえば、スタートコードエミュレーションを回避するために）ＭＰＥＧ−２トランスポートシステムを介するＨＥＶＣビデオのトランスポートを可能にするためである。

[0065]図２の例に示すように、ＮＡＬユニットヘッダはまた、シンタックス要素Ｔｙｐｅを含む。Ｔｙｐｅシンタックス要素は、６ビット長であり、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅと呼ばれる。このフィールドは、ＮＡＬユニットタイプを、ＨＥＶＣＷＤ１０の表７−１において規定されるように指定する。現在規定されているＮＡＬユニットタイプおよびそれらのセマンティクスのすべての参考文献として、ＨＥＶＣＷＤ１０のセクション７．４．１を参照されたい。

[0066]図２の例に示すシンタックス要素ＬａｙｅｒＩＤもまた、ＮＡＬユニットヘッダ内に含まれる。ＬａｙｅｒＩＤシンタックス要素は、６ビット長であり、ｎｕｈ＿ｌａｙｅｒ＿ｉｄと呼ばれる。現在、ＨＥＶＣＷＤ１０は、ＬａｙｅｒＩＤがゼロの値に等しくあるべきであることを指定する。ＨＥＶＣの将来のスケーラブルまたは３Ｄビデオコーディング拡張において、ＬａｙｅｒＩＤシンタックス要素は、空間スケーラブルレイヤ、品質スケーラブルレイヤ、テクスチャビューまたは深度ビューなど、コーディングされたビデオシーケンス中に存在し得る追加のレイヤを識別するために使用され得る。

[0067]図２の例に示すように、ＮＡＬユニットヘッダはまた、シンタックス要素ＴＩＤを含む。ＴＩＤシンタックス要素は、３ビット長であり、ｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１と呼ばれる。ＴＩＤシンタックス要素は、ＮＡＬユニットプラス１の時間識別子を指定する。したがって、ＴｅｍｐｏｒａｌＩＤの値は、ＴＩＤマイナス１に等しい。ＮＡＬユニットヘッダ内のスタートコードエミュレーションを防止するために、ＮＡＬユニットヘッダ内に１に等しいビットが少なくとも１ビット存在することを確実にするために、０のＴＩＤ値は、ＨＥＶＣＷＤ１０において許容されない。

[0068]ＲＴＰに対するＨＥＶＣペイロード仕様において、４つの異なるタイプのＲＴＰペイロード構造が指定される。受信機は、ＲＴＰペイロードヘッダ内のＴｙｐｅフィールドを介してＲＴＰペイロードのタイプを識別し得る。

[0069]ＨＥＶＣに対する４つの異なるＲＴＰペイロード構造は、以下のとおりである。

ｏシングルＮＡＬユニットパケット：シングルＮＡＬユニットパケットは、ＲＴＰペイロード内にシングルＮＡＬユニット（たとえば、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータと）を含む。以前は、ＮＡＬユニットのＮＡＬユニットヘッダもまた、ＲＴＰペイロードヘッダとして働いた。すなわち、シングルＮＡＬユニットパケットから成るＲＴＰペイロードは、ＲＴＰペイロードヘッダを含まず、代わりに、ＲＴＰペイロードヘッダとして働くことをＮＡＬユニットヘッダに依存した。

ｏアグリゲーションパケット（ＡＰ）：以前は、ＡＰは、ＲＴＰペイロード内に１つまたは複数のＮＡＬユニットを含んだ。ＡＰのＮＡＬユニットは、１つのアクセスユニット内から来る。ＨＥＶＣＷＤ１０によって規定されるアクセスユニットは、指定された分類ルールに従って互いに関連し、復号順序において連続し、ちょうど１つのコード化ピクチャを含む、ＮＡＬユニットのセットである。

ｏフラグメンテーションユニット（ＦＵ）：ＦＵは、シングルＮＡＬユニットのサブセットを含む。

ｏＲＴＰパケットを搬送するペイロードコンテンツ情報（ＰＡＣＩ：Payload Content Information）：ＲＴＰパケットを搬送するＰＡＣＩは、（効率に対して他のペイロードヘッダと異なる）ＲＴＰペイロードヘッダと、ペイロードヘッダ拡張構造（ＰＨＥＳ）と、ＰＡＣＩペイロードとを含む。

[0070]以前は、以下のパケット化ルールが指定された。送信モード（たとえば、ｔｘ−ｍｏｄｅ）が「ＭＳＴ」に等しいか、またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０より大きいとき、シングルＮＡＬユニットパケットは使用されない。言い換えれば、ＲＴＰデータがＭＳＴを介して受信されていたとき、および／またはパケット化解除バッファが順序を外れてＲＴＰパケットを受信することを許可されたとき、対応する復号順序番号なしにＲＴＰペイロードにパケット化されたＮＡＬユニットは許可されず、シングルＮＡＬユニットパケットに対する以前のＲＴＰパケットフォーマットは、復号順序番号情報を含まなかった。復号順序番号がないので、ＮＡＬユニットが、ＲＴＰ受信機によって正しい順序に戻されることは不可能である。シングルＮＡＬユニットがＭＳＴモードで送信されるべきであった場合、またはパケット化解除バッファが（たとえば、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータによって）指定されたとき、ＡＰが、シングルＮＡＬユニットを１つのＲＴＰパケットにカプセル化するために使用された。しかしながら、ＡＰは、シングルＮＡＬユニットを送信するときに不必要な４バイトの情報（すなわちＮＡＬユニットＳｉｚｅフィールドとＲＴＰペイロードヘッダと）を含むので、ＡＰ内にシングルＮＡＬユニットをカプセル化することは、オーバーヘッドの増加と帯域幅の減少とをもたらす。

[0071]図３は、アグリゲーションパケットに対するリアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットの構造を示す概念図である。アグリゲーションパケット（ＡＰ）は、しばしば数オクテットのサイズにすぎない大半の非ＶＣＬ（ビデオコーディングレイヤ）ＮＡＬユニットなど、小さいＮＡＬユニットに対するパケット化オーバーヘッドの低減を可能にする。

[0072]図３の例に示すように、ＡＰは、ＲＴＰペイロードヘッダと、アグリゲーションユニットと、随意のＲＴＰパディングとを含む。ＡＰのＲＴＰペイロードヘッダは、図２で説明されるＮＡＬユニットヘッダと同じフォーマットに従う。すなわち、ＡＰのＲＴＰペイロードヘッダは、Ｆフィールドと、Ｔｙｐｅフィールドと、ＬａｙｅｒＩＤフィールドと、ＴＩＤフィールドとを含む。ＡＰのＲＴＰペイロードヘッダでは、ＡＰ内の各アグリゲートされたＮＡＬユニットのＦビットがゼロに等しい場合、Ｆビットは０に等しい。そうでない場合、Ｆビットは１に等しい。ＡＰのＲＴＰペイロードヘッダ内のＴｙｐｅフィールドの値は４８に等しい。ＡＰのＲＴＰペイロードヘッダ内のＬａｙｅｒＩＤフィールドの値は、ＡＰ内のアグリゲートされたＮＡＬユニットすべての中のＬａｙｅｒＩＤの最小値に等しい。ＡＰのＲＴＰペイロードヘッダ内のＴＩＤフィールドの値は、アグリゲートされたＮＡＬユニットすべての中のＴＩＤフィールドの最小値に等しい。

[0073]ＡＰは、１つのアクセスユニット内のＮＡＬユニットをアグリゲートする。すなわち、ＡＰは、同じアクセスユニットからの１つまたは複数のＮＡＬユニットを含み得る。ＡＰ内で搬送されるべき各ＮＡＬユニットは、アグリゲーションユニット内にカプセル化される。１つのＡＰ内にアグリゲートされたＮＡＬユニットは、ＮＡＬユニット復号順序にある。ＡＰは、必要な数のアグリゲーションユニットを搬送することができ得る。

[0074]図４は、アグリゲーションパケット内の第１のアグリゲーションユニットの構造を示す概念図である。ＡＰ内の第１のアグリゲーションユニットは、随意の１６ビットの復号順序番号下位（ＤＯＮＬ：Decoding Order Number Lower）フィールドを（ネットワークバイト順序で）含む。ＤＯＮＬフィールドのセマンティクスは、２０１４年３月２７日に出願された米国特許出願第１４／２２８，１６４号に提示されるセマンティクスと同じであってよい。より具体的には、ＤＯＮＬフィールドの値は、ＲＴＰパケットペイロード内に存在するとき、対応するＮＡＬユニットの復号順序番号の最下位の１６ビットの値に等しい。

[0075]図４に示すように、ＡＰ内の第１のアグリゲーションユニットはまた、ＮＡＬユニットのサイズをバイトで示す（ネットワークバイト順序における）サイズ情報を含む１６ビットの符号なしフィールド（「ＮＡＬＵＳｉｚｅ」フィールド）を含む。ＮＡＬＵＳｉｚｅフィールド内のサイズ情報は、ＮＡＬＵＳｉｚｅフィールドと関連付けられた２オクテットのビットを除外するが、ＮＡＬユニット自体の中のＮＡＬユニットヘッダと関連付けられたビットを含む。

[0076]図４に示すように、ＮＡＬＵＳｉｚｅフィールドは、上述のようにＮＡＬユニットヘッダとＮＡＬユニットペイロードとを含むＮＡＬユニット自体によって後続される。すなわち、アグリゲーションユニットは、含まれるＮＡＬユニットの復号順序番号を示すＤＯＮＬフィールドと、含まれるＮＡＬユニットのサイズを示すサイズフィールド（たとえば、ＮＡＬＵＳｉｚｅフィールド）と、ＮＡＬユニット自体とから成る。

[0077]送信モードが「ＭＳＴ」に等しい場合、および／またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０より大きい場合、ＤＯＮＬフィールドは、ＡＰ内の第１のアグリゲーションユニット内に存在する。さらに、送信モードが「ＭＳＴ」に等しい場合、および／またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０より大きい場合、ＡＰ内の後続のアグリゲーションユニットの各々は、復号順序番号差分（ＤＯＮＤ：Decoding Order Number Difference）フィールドを含むことになる。ＡＰの後続のアグリゲーションユニット内に存在するとき、ＤＯＮＤフィールドの値は、現在のアグリゲートされたＮＡＬユニット（たとえば、現在のアグリゲーションユニット内のＮＡＬユニット）の復号順序番号の値と、同じＡＰ内の先行するアグリゲートされたＮＡＬユニット（たとえば、先行するアグリゲーションユニット内のＮＡＬユニット）の復号順序番号の値との間の差分を示す。

[0078]一般的にはＲＴＰペイロードフォーマット、または具体的にはＨＥＶＣＲＴＰペイロードフォーマットに対するそのような設計は、下記の問題を有する。マルチストリーム送信（ＭＳＴ）が使用されるとき、および／または、たとえばｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータによって示されるようにインタリーブされたパケット化が（たとえば、ＳＳＴまたはＭＳＴのいずれかにおいて）使用中であるときにシングルＮＡＬユニットをＲＴＰパケット内にカプセル化するために、ＡＰが使用されなければならない（たとえば、シングルＮＡＬユニットパケットは使用され得ない）。すなわち、ＲＴＰ受信機は、復号順序番号に少なくとも部分的に基づいて、ＮＡＬユニットをビデオ復号ユニットに供給するので、復号順序番号を外れて送られたＮＡＬユニットは、対応する復号順序番号とともに送られるべきである。しかしながら、ＲＴＰペイロードに対するシングルＮＡＬユニットパケットフォーマットは、復号順序番号の指示を含まない。したがって、シングルＮＡＬユニットは、ＡＰとして構成されるＲＴＰペイロードを有するＲＴＰパケット内で送られなければならない。

[0079]ＲＴＰパケット内でシングルＮＡＬユニットを送るためにＡＰを使用することは、ＮＡＬユニットサイズフィールド（たとえば、図４のＮＡＬＵＳｉｚｅフィールド）と関連付けられた２バイトを含むこと、ならびに２バイトのＮＡＬユニットヘッダを繰り返すことを必要とする。ＡＰが単一のアグリゲーションユニットだけを含むとき、アグリゲートされたＮＡＬユニットのサイズは不必要である。すなわち、パケット化解除モジュールは、（たとえば、アグリゲーションユニットは１つだけしかないので）ＡＰ内の複数のアグリゲーションユニットの間で区別する必要はないので、アグリゲートされたＮＡＬユニットの長さを指定する必要はない。さらに、ＲＴＰペイロードヘッダ（図３に示すペイロードヘッダ）とＮＡＬユニットヘッダ（図４に示すＦフィールド、Ｔｙｐｅフィールド、ＬａｙｅｒＩＤフィールド、およびＴＩＤフィールド）の両方を含むことは冗長である。すなわち、シングルＮＡＬユニットを含むＡＰは、唯一のアグリゲートされたＮＡＬユニットのＮＡＬユニットヘッダとほとんど同じＲＴＰペイロードヘッダを有することになる。唯一の違いは、Ｔｙｐｅフィールドの値である。ＲＴＰペイロードヘッダにおいて、Ｔｙｐｅフィールドの値は（たとえば、ＲＴＰペイロードがＡＰであることを表明するために）４８となり、一方、ＮＡＬユニットヘッダにおいて、Ｔｙｐｅフィールドの値は（たとえば、ＮＡＬユニットタイプを示すために）異なることがある。したがって、インタリービングパケット化(interleaving packetization)が可能にされるとき、および／またはマルチストリーム送信モードで動作するとき（たとえば、ＲＴＰにおけるＭＳＴモードにあるとき）、シングルＮＡＬユニットを含む各パケットに対して４バイトが浪費される。言い換えれば、単一のアグリゲーションユニットだけを含んで送られるあらゆるＡＰに対して、４バイトのデータは不要である。

[0080]このようにして、ＲＴＰペイロードフォーマットに対するこの設計に伴う問題は、ＭＳＴモードの下でおよび／またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０より大きいときならびにシングルＮＡＬユニットに対するＲＴＰペイロードが送信されるとき、ＲＴＰパケットに対するペイロードは、シングルＮＡＬユニットを含むＡＰとしてカプセル化されなければならないことである。これは、１６ビット長を有するＲＴＰペイロードヘッダと、１６ビット長を有するＤＯＮＬフィールドと、ＮＡＬユニットによって後続される１６ビット長を有するＮＡＬＵＳｉｚｅフィールドとを有するＲＴＰペイロードをもたらす（ＮＡＬユニット自体は別個の（すなわち、ＲＴＰペイロードヘッダとは別個の）１６ビットのＮＡＬユニットヘッダを含む）。対照的に、（ＨＥＶＣに対する以前のＲＴＰペイロードフォーマットに従って）ＳＳＴモードにおいて可能にされるシングルＮＡＬユニットパケットと関連付けられたＲＴＰペイロードは、ＤＯＮＬフィールドまたはＮＡＬＵＳｉｚｅフィールドを含まない。そうではなく、上記のように、シングルＮＡＬユニットパケットのＲＴＰペイロードヘッダは、含まれるＮＡＬユニットの最初の２バイト（たとえば、ＮＡＬユニットヘッダ）である。ＭＳＴモードが送信に利用されるシナリオでは、および／またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータが０より大きい値を有するとき、４バイト（すなわち、ＡＰのＲＴＰペイロードヘッダの２バイトおよびＡＰ内の単一のアグリゲーションユニットのＮＡＬＵＳｉｚｅフィールドの２バイト）が不必要にカプセル化され、送信されるので、シングルＮＡＬユニットを送ることは、帯域幅を阻害することおよび／または送信効率を低下させることをもたらすことがある。

[0081]これらの問題に鑑みて、本開示は、ＭＳＴモードにおいておよび／またはｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータが０より大きい値を有するときに、シングルＮＡＬユニットパケットが使用され得るように、修正されたシングルＮＡＬユニットパケットのＲＴＰペイロード構造を提供する。すなわち、修正されたシングルＮＡＬユニットパケット構造は、インタリーブされたパケット化が無効にされながらＳＳＴモードで動作するときのシングルＮＡＬユニットの効率的な送信を維持しながら、マルチストリーム送信モード（ＲＴＰに対するＭＳＴモードなど）を実施するとき、および／またはインタリーブされたパケット化が可能にされるときに、シングルＮＡＬユニットのより効率的な送信を可能にし得る。より一般的には、シングルＮＡＬユニットパケットが、復号順序カウントまたは復号順序番号（ＤＯＮ）情報（たとえば、２バイトのＤＯＮＬフィールド）を含み得る技法が開示される。

[0082]一例として、ＤＯＮＬフィールドは、２バイトのＮＡＬユニットヘッダの直後でＮＡＬユニットペイロードの直前に含まれ得る。ＤＯＮ情報は、マルチストリーム送信を実施する場合（たとえば、ＲＴＰ送信モードが「ＭＳＴ」に等しい場合）および／またはインタリーブすることが可能にされる場合（たとえば、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータが０より大きい場合）に各シングルＮＡＬユニットパケット内に存在し、そうでない場合には存在しない。シングルＮＡＬユニットパケット構造に対するそのような変更によって、シングルＮＡＬユニットパケットは、ユニキャストモード（インタリーブすることを伴うか否かにかかわらず）とマルチストリーム送信モードにおける中の両方において使用され得る。このようにして、ＮＡＬユニットに対するＤＯＮ情報の指示は、必要なときに、送られる情報量を低減しながらＮＡＬユニットと一緒に送られ得る。すなわち、シングルＮＡＬユニットパケット内に随意のＤＯＮＬフィールドを含むことは、（たとえば、ＲＴＰを使用するときに）ビデオデータ送信の効率を向上させ得る。

[0083]ＨＥＶＣに対する以前のＲＴＰペイロードフォーマットに従ってインタリーブすることを伴わないＳＳＴの間にのみ使用され得るシングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットが、図５に示されている。図５においてわかるように、ＲＴＰペイロード内にＤＯＮ情報は存在しない。

[0084]図６は、本開示の技法によるシングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットの一例を示す概念図である。図６に示すように、修正されたシングルＮＡＬユニットパケットのＲＴＰペイロード構造は、ＤＯＮＬフィールドを含む。ＤＯＮＬフィールドは、マルチストリーム送信を実施するとき（たとえば、送信モードが「ＭＳＴ」に等しいとき）および／またはインタリーブすることが可能にされる（たとえば、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータが０より大きい値を有する）ときにシングルＮＡＬユニットパケットに対してシグナリングされるという点において、ＤＯＮＬフィールドは「随意的」である。すなわち、ＲＴＰに対して、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０より大きい場合、および／または送信モードが「ＭＳＴ」に等しい場合、ＤＯＮＬフィールドは、ＲＴＰペイロード内に含まれる。そうでない場合、ＤＯＮＬは存在しない。言い換えれば、ＤＯＮＬフィールドは、送信モードが「ＳＳＴ」に等しく、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０に等しいとき、修正されたシングルＮＡＬユニットパケット内に存在しない。

[0085]図６の例に示すように、随意のＤＯＮＬフィールドは、ＮＡＬユニット自体の中にカプセル化され得る。すなわち、修正されたシングルＮＡＬユニットパケット内に存在するとき、ＤＯＮＬフィールドは、ＮＡＬユニットヘッダの直後でＮＡＬユニットペイロードの直前にカプセル化され得る。このようにして、ＮＡＬユニットヘッダ内の情報は、ＲＴＰペイロードヘッダとＮＡＬユニットヘッダの両方として機能し得る。

[0086]図７は、本開示の技法によるシングルＮＡＬユニットパケットに対するＲＴＰペイロードフォーマットの別の例を示す概念図である。図７の例に示すシングルＮＡＬユニットパケットもまた、随意のＤＯＮＬフィールドを含む。すなわち、図７に示すＤＯＮＬフィールドは、マルチストリーム送信を実施する（たとえば、送信モードが「ＭＳＴ」に等しい）とき、および／またはインタリーブすることが可能にされる（たとえば、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値が０に等しくない）ときに存在し得る。図７に示すＤＯＮＬフィールドは、そうでない場合には存在し得ない。

[0087]図７の例では、シングルＮＡＬユニットは、ＤＯＮＬフィールドに続くＲＴＰペイロードの一部である。この場合、ＮＡＬユニットの最初の２バイト（たとえば、ＮＡＬユニットヘッダ）がＤＯＮＬフィールドの前に（たとえば、ＲＴＰペイロードヘッダとして）繰り返され、それによって、シングルＮＡＬユニットを送るためにＡＰを使用することと比較すると、２バイトを節約している。図７の例示的なシングルＮＡＬユニットはまた、ＮＡＬユニットの最初の２バイトを、ＤＯＮＬフィールドを有するＮＡＬデータの残部から中間で分離しないという利点を提供する。言い換えれば、修正されたシングルＮＡＬユニットパケットは、様々なロケーションにおいて復号順序番号情報を含み得る。図６の例示的なシングルＮＡＬユニットパケットは、ＮＡＬユニットヘッダとＮＡＬユニットペイロードとの間にＤＯＮＬフィールドを含む。図７の例示的なシングルＮＡＬユニットパケットは、ＮＡＬユニットヘッダの前（たとえば、ＮＡＬユニットの前）にＤＯＮＬフィールドを含み、ＤＯＮＬフィールドの前にＮＡＬユニットヘッダ（たとえば、ＮＡＬユニットの最初の２バイト）の複製を含む。図７の例に示すように、ＲＴＰペイロードヘッダを作成するためにＮＡＬユニットヘッダの情報を複製することは、ＮＡＬユニットヘッダとＮＡＬユニットペイロードとの分離を回避しながら必要なＲＴＰペイロードヘッダを提供し得る。

[0088]本開示のＲＴＰペイロードフォーマットにおけるシングルＮＡＬユニットコーディングのための技法は、ビデオエンコーダ、ビデオデコーダ、メディアアウェアネットワーク要素（ＭＡＮＥ）、ならびに他のビデオおよび／またはネットワーク処理ハードウェアによって実施され得る。以下の図は、本開示の技法を実装し得るビデオエンコーダ２０と、ビデオデコーダ３０と、ＭＡＮＥ２９と、サーバデバイス１５２と、ルーティングデバイス１５４Ａと、トランスコーディングデバイス１５６と、ルーティングデバイス１５４Ｂと、クライアントデバイス１５８とを含む例示的な構造を説明する。

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

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

[0091]ビデオデータメモリ３４は、ビデオエンコーダ２０の構成要素によって符号化されるべきビデオデータを記憶し得る。ビデオデータメモリ３４に記憶されたビデオデータは、たとえば、ビデオソース１８から取得され得る。ピクチャメモリ６４は、たとえば、イントラコーディングモードまたはインターコーディングモードでビデオエンコーダ２０によってビデオデータを符号化する際に使用するための、参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ３４およびピクチャメモリ６４は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ（登録商標））、または他のタイプのメモリデバイスを含む、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）など、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ３４およびピクチャメモリ６４は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ３４は、ビデオエンコーダ２０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。

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

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

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

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

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

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

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

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

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

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

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

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

[0104]本明細書で説明する技法によれば、ビデオエンコーダ２０および／または後処理デバイス５７は、（たとえば、ＲＴＰを使用して）１つまたは複数の他のデバイスに送信するための符号化されたビデオデータをカプセル化し得る。たとえば、後処理デバイス５７は、符号化されたＨＥＶＣビデオデータ（たとえば、ＮＡＬユニット）を受信し、（たとえば、ＲＴＰセッションに対して）ビデオデータをシングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケットにカプセル化することによって、ＨＥＶＣに対する特定のペイロードフォーマット（たとえば、ＨＥＶＣに対するＲＴＰペイロードフォーマット）に準拠するペイロードを有するパケット（たとえば、ＲＴＰパケット）を生成することができ得る。後処理デバイス５７はまた、セッションがマルチストリーム送信であること（たとえば、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること）、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、シングルＮＡＬユニットパケット内に復号順序番号情報（たとえば、ＤＯＮＬ）をカプセル化し得る。

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

[0106]ビデオデータメモリ８３は、ビデオデコーダ３０の構成要素によって復号されるべき、符号化されたビデオビットストリームなどのビデオデータを記憶し得る。ビデオデータメモリ８３に記憶されるビデオデータは、たとえばコンピュータ可読媒体から、たとえばビデオデータのワイヤードもしくはワイヤレスなネットワークの通信を介するかまたは物理的なデータ記憶媒体にアクセスすることによってカメラなどのローカルビデオソースから、取得され得る。ビデオデータメモリ８３は、符号化されたビデオビットストリームからの符号化されたビデオデータを記憶するコード化ピクチャバッファ（ＣＰＢ）を形成し得る。ピクチャメモリ９２は、いくつかの例では、たとえばイントラコーディングモードまたはインターコーディングモードでビデオデコーダ３０によってビデオデータを復号する際に使用するための、参照ビデオデータを記憶する参照ピクチャメモリであり得る。ビデオデータメモリ８３およびピクチャメモリ９２は、同期ＤＲＡＭ（ＳＤＲＡＭ）、磁気抵抗ＲＡＭ（ＭＲＡＭ）、抵抗ＲＡＭ（ＲＲＡＭ）、または他のタイプのメモリデバイスを含む、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）など、様々なメモリデバイスのいずれかによって形成され得る。ビデオデータメモリ８３およびピクチャメモリ９２は、同じメモリデバイスまたは別個のメモリデバイスによって提供され得る。様々な例では、ビデオデータメモリ８３は、ビデオデコーダ３０の他の構成要素とともにオンチップであるか、またはそれらの構成要素に対してオフチップであり得る。

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

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

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

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

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

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

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

[0114]本明細書で説明する技法によれば、ネットワークエンティティ７９および／またはビデオデコーダ３０は、（たとえば、ＲＴＰを使用して）１つまたは複数の他のデバイスに送信するためにカプセル化された符号化されたビデオデータをカプセル化解除し得る。たとえば、ネットワークエンティティ７９は、符号化されたＨＥＶＣビデオデータ（たとえば、ＮＡＬユニット）を含む１つまたは複数のパケット（たとえば、ＲＴＰパケット）を受信し得る。パケットは、ＨＥＶＣに対する特定のペイロードフォーマット（たとえば、ＨＥＶＣに対するＲＴＰペイロードフォーマット）に準拠するペイロードを有し得る。ビデオデータを処理するために、ネットワークエンティティ７９は、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケットにカプセル化されたビデオデータをカプセル化解除し得る。ネットワークエンティティ７９および／またはビデオデコーダ３０はまた、セッションがマルチストリーム送信であること（たとえば、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること）、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、シングルＮＡＬユニットパケット内にカプセル化された復号順序番号情報（たとえば、ＤＯＮＬ）をカプセル化解除し得る。ビデオデータ（たとえば、ＮＡＬユニット）およびＤＯＮ情報が取得された後、ビデオデコーダ３０は、符号化されたビデオデータを処理し得る。

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

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

[0117]たとえば、サーバデバイス１５２、ルーティングデバイス１５４、トランスコーディングデバイス１５６、またはクライアントデバイス１５８のうちの１つまたは複数は、（たとえば、ＲＴＰセッションに対して）シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化することによって、およびセッションがマルチストリーム送信であること（たとえば、ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること）、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいてシングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することによって、データユニットペイロード内（たとえば、リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内）のビデオデータを処理し得る。

[0118]シングルＮＡＬユニットパケットは、ＲＴＰセッションの一部として、サーバデバイス１５２、ルーティングデバイス１５４、トランスコーディングデバイス１５６、またはクライアントデバイス１５８のうちの１つまたは複数の他のデバイスに送信され得る。シングルＮＡＬユニットパケットとしてフォーマットされたＲＴＰペイロードを含むＲＴＰパケットを受信すると、受信デバイスは、シングルＮＡＬユニットパケット内にカプセル化されたビデオデータをカプセル化解除することによって、およびＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいてシングルＮＡＬユニットパケット内にカプセル化された復号順序番号情報をカプセル化解除することによって、ビデオデータを処理し得る。

[0119]図１１は、本開示の技法によるＲＴＰペイロードフォーマット内にビデオデータをカプセル化するための例示的な動作を示すフロー図である。単に例示のために、図１１の例示的な動作が、図１のコンテキストにおいて以下で説明される。

[0120]図１１の例では、ＲＴＰカプセル化ユニット（たとえば、出力インターフェース２２）が、ビデオデータを受信し得る（１８０）。たとえば、ビデオデータは、ＨＥＶＣ規格または別のビデオコーディング方式に従って、（たとえば、ビデオエンコーダ２０によって）シングルＮＡＬユニットに符号化され得る。いくつかの例では、ＮＡＬユニットは、ＮＡＬユニットペイロードデータとＮＡＬユニットヘッダとを含み得る。ＲＴＰペイロードを生成するために、出力インターフェース２２は、シングルＮＡＬユニットパケット内にビデオデータをカプセル化し得る（１８２）。

[0121]出力インターフェース２２は、ＲＴＰ送信がＭＳＴモードにあるかどうかを決定し得る（１８４）。送信がＭＳＴモードにある（１８４の「はい」分岐）場合、出力インターフェース２２は、受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数がゼロに等しいかどうかを決定し得る（１８６）。たとえば、出力インターフェース２２は、ＲＴＰ送信のｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値がゼロに等しいかどうかを決定し得る。その値がゼロに等しい（１８６の「はい」分岐）場合、出力インターフェース２２は、シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することを控え得る（１８８）。

[0122]図１１の例では、ＲＴＰ送信がＭＳＴモードにある（１８４の「いいえ」分岐）場合、および／または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数がゼロより大きい（１８６の「はい」分岐）場合、出力インターフェース２２は、シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化し得る（１９０）。いくつかの例では、シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化するために、出力インターフェース２２は、シングルＮＡＬユニットパケット内でＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとの間に復号順序番号情報をカプセル化し得る。いくつかの例では、出力インターフェース２２は、シングルＮＡＬユニットパケット内でＮＡＬユニットの前に復号順序番号情報をカプセル化し、復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化し得る。カプセル化されたＲＴＰペイロードヘッダは、ＮＡＬユニットヘッダ内に含まれる情報を備え得る。

[0123]図１２は、本開示の技法によるＲＴＰペイロードフォーマット内にカプセル化されたビデオデータをカプセル化解除するための例示的な動作を示すフロー図である。単に例示のために、図１２の例示的な動作が、図１のコンテキストにおいて以下で説明される。

[0124]図１２の例では、ＲＴＰカプセル化解除ユニット（たとえば、入力インターフェース２８）が、ＲＴＰパケットを受信し得る（２００）。たとえば、ＲＴＰパケットは、シングルＮＡＬユニットパケットとしてフォーマットされたＲＴＰペイロードを含み得る。すなわち、ＲＴＰペイロードは、ＲＴＰペイロード内にシングルＮＡＬユニットを含み得る。いくつかの例では、ＮＡＬユニットは、ＮＡＬユニットペイロードデータとＮＡＬユニットヘッダとを含み得る。パケット内にカプセル化されたビデオデータを取得するために、入力インターフェース２８は、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にカプセル化されたビデオデータをカプセル化解除し得る（２０２）。

[0125]入力インターフェース２８は、ＲＴＰ送信がＭＳＴモードにあるかどうかを決定し得る（２０４）。送信がＭＳＴモードにある（２０４の「はい」分岐）場合、入力インターフェース２８は、受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数がゼロに等しいかどうかを決定し得る（２０６）。たとえば、入力インターフェース２８は、ＲＴＰ送信のｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータの値がゼロに等しいかどうかを決定し得る。その値がゼロに等しい（２０６の「はい」分岐）場合、入力インターフェース２８は、シングルＮＡＬユニットパケットからの復号順序番号情報をカプセル化解除することを控え得る（２０８）。

[0126]図１２の例では、ＲＴＰ送信がＭＳＴモードにある（２０４の「いいえ」分岐）場合、および／または受信順序においてパケット化解除バッファ内のＮＡＬユニットに先行し、復号順序においてＮＡＬユニットに後続し得るＮＡＬユニットの最大数がゼロより大きい（２０６の「はい」分岐）場合、入力インターフェース２８は、シングルＮＡＬユニットパケット内にカプセル化された復号順序番号情報をカプセル化解除し得る（２１０）。いくつかの例では、復号順序番号情報は、シングルＮＡＬユニットパケット内でＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとの間にカプセル化され得る。シングルＮＡＬユニットパケット内の復号順序番号情報をカプセル化解除するために、入力インターフェース２８は、シングルＮＡＬユニットパケット内でＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとの間にカプセル化された復号順序番号情報をカプセル化解除し得る。いくつかの例では、復号順序番号情報は、シングルＮＡＬユニットパケット内でＮＡＬユニットの前にカプセル化され、ＲＴＰペイロードヘッダは、シングルＮＡＬユニットパケット内で復号順序番号情報の前にカプセル化され得る。カプセル化されたＲＴＰペイロードヘッダは、ＮＡＬユニットヘッダ内に含まれる情報を備え得る。シングルＮＡＬユニットパケット内でＮＡＬユニットの前にカプセル化された復号順序番号情報をカプセル化解除するために、入力インターフェース２８は、シングルＮＡＬユニットパケット内でＮＡＬユニットの前にカプセル化された復号順序番号情報をカプセル化解除し、シングルＮＡＬユニットパケット内で復号順序番号情報の前にカプセル化されたＲＴＰペイロードヘッダをカプセル化解除し得る。

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

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

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

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

[0131]種々の例が記載された。これらおよび他の例は、以下の特許請求の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法であって、
ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化することと、ここで、前記シングルＮＡＬユニットパケットは、シングルＮＡＬユニットを含み、および、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいこと、のうちの少なくとも一方に基づいて、前記シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することと、
を備える、方法。
［Ｃ２］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化することが、前記シングルＮＡＬユニットパケット内で前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化することを備える、Ｃ１に記載の方法。
［Ｃ３］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化することが、前記シングルＮＡＬユニットパケット内で前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化することを備え、前記方法が、
前記シングルＮＡＬユニットパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化することをさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、
Ｃ１に記載の方法。
［Ｃ４］
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいこと、とに基づいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化することを控えることをさらに備える、Ｃ１に記載の方法。
［Ｃ５］
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、Ｃ１に記載の方法。
［Ｃ６］
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、Ｃ５に記載の方法。
［Ｃ７］
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法であって、
ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にカプセル化されたビデオデータをカプセル化解除することと、ここで、前記シングルＮＡＬユニットパケットは、シングルＮＡＬユニットを含み、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、前記シングルＮＡＬユニットパケット内にカプセル化された復号順序番号情報をカプセル化解除することとを備える、方法。
［Ｃ８］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内にカプセル化された前記復号順序番号情報をカプセル化解除することが、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間にカプセル化された前記復号順序番号情報をカプセル化解除することを備える、Ｃ７に記載の方法。
［Ｃ９］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内にカプセル化された前記復号順序番号情報をカプセル化解除することが、前記シングルＮＡＬユニットの前にカプセル化された前記復号順序番号情報をカプセル化解除することを備え、前記方法が、
前記シングルＮＡＬユニットパケット内で前記復号順序番号情報の前にカプセル化されたＲＴＰペイロードヘッダを、前記シングルＮＡＬユニットパケットからカプセル化解除することをさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、Ｃ７に記載の方法。
［Ｃ１０］
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記シングルＮＡＬユニットパケットから復号順序番号情報をカプセル化解除することを控えることをさらに備える、Ｃ７に記載の方法。
［Ｃ１１］
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、Ｃ７に記載の方法。
［Ｃ１２］
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、Ｃ１１に記載の方法。
［Ｃ１３］
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置であって、
ビデオデータを記憶するように構成されたメモリと、
プロセッサとを備え、前記プロセッサが、
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内で、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化することと、ここで、前記シングルＮＡＬユニットパケットは、シングルＮＡＬユニットを含み、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、前記シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化することとを行うように構成される、装置。
［Ｃ１４］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記プロセッサが、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化するように構成される、Ｃ１３に記載の装置。
［Ｃ１５］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化するように構成された前記プロセッサが、前記シングルＮＡＬユニットパケット内で前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化するように構成され、および、ここにおいて、前記プロセッサが、
前記シングルＮＡＬユニットパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化するようにさらに構成され、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、Ｃ１３に記載の装置。
［Ｃ１６］
前記プロセッサが、
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内で前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化することを控えるようにさらに構成される、Ｃ１３に記載の装置。
［Ｃ１７］
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、Ｃ１３に記載の装置。
［Ｃ１８］
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、Ｃ１７に記載の装置。
［Ｃ１９］
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置であって、
ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化するための手段と、ここで、前記シングルＮＡＬユニットパケットは、シングルＮＡＬユニットを含み、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内で前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、前記シングルＮＡＬユニットパケット内に復号順序番号情報をカプセル化するための手段とを備える、装置。
［Ｃ２０］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化するための前記手段が、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化するための手段を備える、Ｃ１９に記載の装置。
［Ｃ２１］
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化するための前記手段が、前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化するための手段を備え、前記装置が、
前記シングルＮＡＬユニットパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化するための手段をさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれた情報を備える、Ｃ２０に記載の装置。
［Ｃ２２］
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記シングルＮＡＬユニットパケット内に前記復号順序番号情報をカプセル化することを控えるための手段をさらに備える、Ｃ１９に記載の装置。
［Ｃ２３］
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、Ｃ１９に記載の装置。
［Ｃ２４］
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、Ｃ１９に記載の装置。

Claims

リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法であって、
ＲＴＰセッションに対して、ＲＴＰパケット内にビデオデータをカプセル化することと、ここにおいて、前記ＲＴＰパケットのためのタイプフィールドは、前記ＲＴＰパケットがビデオコーディングレイヤデータのシングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含むことを示し、および、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいこと、のうちの少なくとも一方に基づいて、ビデオコーディングレイヤデータの前記シングルＮＡＬユニットを含む前記ＲＴＰパケット内に復号順序番号情報をカプセル化することと、
を備える、方法。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化することが、前記ＲＴＰパケット内で前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化することを備える、請求項１に記載の方法。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化することが、前記ＲＴＰパケット内で前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化することを備え、前記方法が、
前記ＲＴＰパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化することをさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、
請求項１に記載の方法。
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいこと、とに基づいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化することを控えることをさらに備える、請求項１に記載の方法。
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、請求項１に記載の方法。
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、請求項５に記載の方法。
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理する方法であって、
ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にカプセル化されたビデオデータをカプセル化解除することと、ここにおいて、前記ＲＴＰパケットのためのタイプフィールドは、前記ＲＴＰパケットがビデオコーディングレイヤデータのシングルＮＡＬユニットを含むことを示し、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、ビデオコーディングレイヤデータの前記シングルＮＡＬユニットを含む前記ＲＴＰパケット内にカプセル化された復号順序番号情報をカプセル化解除することと
を備える、方法。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内にカプセル化された前記復号順序番号情報をカプセル化解除することが、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間にカプセル化された前記復号順序番号情報をカプセル化解除することを備える、請求項７に記載の方法。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内にカプセル化された前記復号順序番号情報をカプセル化解除することが、前記シングルＮＡＬユニットの前にカプセル化された前記復号順序番号情報をカプセル化解除することを備え、前記方法が、
前記ＲＴＰパケット内で前記復号順序番号情報の前にカプセル化されたＲＴＰペイロードヘッダを、前記ＲＴＰパケットからカプセル化解除することをさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、請求項７に記載の方法。
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記ＲＴＰパケットから復号順序番号情報をカプセル化解除することを控えることをさらに備える、請求項７に記載の方法。
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、請求項７に記載の方法。
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、請求項１１に記載の方法。
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置であって、
ビデオデータを記憶するように構成されたメモリと、
１つまたは複数のプロセッサと
を備え、前記１つまたは複数のプロセッサが、
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内で、ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化することと、ここにおいて、前記ＲＴＰパケットのためのタイプフィールドは、前記ＲＴＰパケットがビデオコーディングレイヤデータのシングルＮＡＬユニットを含むことを示し、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、ビデオコーディングレイヤデータの前記シングルＮＡＬユニットを含む前記ＲＴＰパケット内に復号順序番号情報をカプセル化することとを行うように構成される、装置。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記プロセッサが、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化するように構成される、請求項１３に記載の装置。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化するように構成された前記プロセッサが、前記ＲＴＰパケット内で前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化するように構成され、および、ここにおいて、前記プロセッサが、
前記ＲＴＰパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化するようにさらに構成され、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれる情報を備える、請求項１３に記載の装置。
前記プロセッサが、
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内で前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化することを控えるようにさらに構成される、請求項１３に記載の装置。
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、請求項１３に記載の装置。
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、請求項１７に記載の装置。
リアルタイムトランスポートプロトコル（ＲＴＰ）ペイロード内のビデオデータを処理するように構成された装置であって、
ＲＴＰセッションに対して、シングルネットワークアブストラクションレイヤ（ＮＡＬ）ユニットパケット内にビデオデータをカプセル化するための手段と、ここにおいて、前記ＲＴＰパケットのためのタイプフィールドは、前記ＲＴＰパケットがビデオコーディングレイヤデータのシングルＮＡＬユニットを含むことを示し、
前記ＲＴＰセッションがマルチストリーム送信（ＭＳＴ）モードにあること、または受信順序においてパケット化解除バッファ内で前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの最大数が０より大きいことのうちの少なくとも一方に基づいて、ビデオコーディングレイヤデータの前記シングルＮＡＬユニットを含む前記ＲＴＰパケット内に復号順序番号情報をカプセル化するための手段とを備える、装置。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化するための前記手段が、前記ＮＡＬユニットヘッダと前記ＮＡＬユニットペイロードデータとの間に前記復号順序番号情報をカプセル化するための手段を備える、請求項１９に記載の装置。
前記シングルＮＡＬユニットが、ＮＡＬユニットヘッダとＮＡＬユニットペイロードデータとを備え、および、ここにおいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化するための前記手段が、前記シングルＮＡＬユニットの前に前記復号順序番号情報をカプセル化するための手段を備え、前記装置が、
前記ＲＴＰパケット内で、前記復号順序番号情報の前にＲＴＰペイロードヘッダをカプセル化するための手段をさらに備え、ここにおいて、前記ＲＴＰペイロードヘッダが、前記ＮＡＬユニットヘッダ内に含まれた情報を備える、請求項１９に記載の装置。
前記ＲＴＰセッションがシングルストリーム送信（ＳＳＴ）モードにあること、および受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が０に等しいことに基づいて、前記ＲＴＰパケット内に前記復号順序番号情報をカプセル化することを控えるための手段をさらに備える、請求項１９に記載の装置。
受信順序において前記パケット化解除バッファ内の前記ＮＡＬユニットに先行し、および復号順序において前記ＮＡＬユニットに後続し得るＮＡＬユニットの前記最大数が、前記ＲＴＰセッションのセットアップの間に指定されたシンタックス要素の値によって表される、請求項１９に記載の装置。
前記シンタックス要素が、ｓｐｒｏｐ−ｄｅｐａｃｋ−ｂｕｆ−ｎａｌｕｓパラメータを備える、請求項２３に記載の装置。