特許 6483167 ビデオ・データストリーム・コンセプト

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

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

(11)【特許番号】6483167

(24)【登録日】2019年2月22日

(45)【発行日】2019年3月13日

(54)【発明の名称】ビデオ・データストリーム・コンセプト

(51)【国際特許分類】

   H04N 19/70 20140101AFI20190304BHJP

【ＦＩ】

   H04N19/70

【請求項の数】11

【全頁数】61

(21)【出願番号】特願2017-19898(P2017-19898)

(22)【出願日】2017年2月6日

(62)【分割の表示】特願2015-519177(P2015-519177)の分割

【原出願日】2013年7月1日

(65)【公開番号】特開2017-123659(P2017-123659A)

(43)【公開日】2017年7月13日

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

(31)【優先権主張番号】61/666,185

(32)【優先日】2012年6月29日

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

【前置審査】

(73)【特許権者】

【識別番号】515089080

【氏名又は名称】ジーイー ビデオ コンプレッション エルエルシー

(74)【代理人】

【識別番号】100079577

【弁理士】

【氏名又は名称】岡田 全啓

(72)【発明者】

【氏名】シーアル トーマス

(72)【発明者】

【氏名】ジョージ ヴァレーリ

(72)【発明者】

【氏名】ヘンケル アナスタージア

(72)【発明者】

【氏名】マルペ デトレフ

(72)【発明者】

【氏名】グルーエネベルク カルステン

(72)【発明者】

【氏名】スクーピン ローベルト

【審査官】 岩井 健二

(56)【参考文献】

【文献】 特開２０１３−１３２０４８（ＪＰ，Ａ）

【文献】 特開２０１０−２３２７２０（ＪＰ，Ａ）

【文献】 特表２００９−５１０８８８（ＪＰ，Ａ）

【文献】 国際公開第２０１３／１５１６３４（ＷＯ，Ａ１）

【文献】 MenHuang Lee et al.，ROI slice SEI message，Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6)，18th Meeting: Bangkok, Thailand，２００６年 １月，JVT-R024，pp.1-8

【文献】 MenHuang Lee et al.，ROI slice SEI message，Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG (ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q.6)，19th Meeting: Geneva, Switzerland，２００６年 ４月，JVT-S054r1，pp.1-13

【文献】 Ye-Kui Wang et al.，Tile groups，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11，8th Meeting: San Jose, CA, USA，２０１２年 １月，JCTVC-H0520r1，pp.1-8

【文献】 T. Schierl et al.，Slice Prefix for sub-picture and slice level HLS signalling，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，10th Meeting: Stockholm, SE，２０１２年 ７月，JCTVC-J0255，pp.1-12

【文献】 R. Skupin, V. George and T. Schierl，Tile-based region-of-interest signalling with sub-picture SEI messages，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，11th Meeting: Shanghai, CN，２０１２年１０月，JCTVC-K0218，pp.1-3

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

Ｈ０４Ｎ １９／００ − １９／９８

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

【請求項1】

ビデオコンテンツ（１６）の画像（１８）のサブポーション（２４）を単位にして前記ビデオコンテンツ（１６）が符号化されているビデオ・データストリームを復号化するために構成されるデコーダであって、
各サブポーション（２４）は、それぞれ前記ビデオ・データストリーム（２２）のパケットのシーケンス（３４）の１つ以上のペイロード・パケット（３２）に符号化され、前記パケットのシーケンス（３４）はアクセスユニット（３０）のシーケンスに分割されて、前記ビデオコンテンツ（１６）のそれぞれの画像（１８）に関連する前記ペイロード・パケット（３２）は、各アクセスユニット（３０）に属するようになっており、少なくともいくつかのアクセスユニットはＲＯＩ（関心領域）パケット（６４）が組み入れられたパケットのシーケンス（３４）を有していて、タイミング制御パケット（６４）が前記アクセスユニット（３０）を復号化ユニットに再分割するようにして、少なくともいくつかのアクセスユニット（３０）が前記それぞれのアクセスユニットの前記画像に関連するペイロード・パケット（３２）の間に組み入れられたＲＯＩパケット（６４）を有するようになっていて、前記各ＲＯＩパケットは、それぞれの前記ＲＯＩパケットに続くパケットの前記シーケンス（３４）において続く１つ以上のペイロード・パケットに関連し、それぞれのＲＯＩパケットが関連する１つ以上のペイロード・パケットのいずれかに符号化される前記サブポーション（２４）が前記ビデオコンテンツの関心領域を覆うかどうかについて確認するように構成される、デコーダ。

【請求項2】

ビデオ・データストリームを符号化するために構成されるエンコーダであって、前記ビデオ・データストリームは、ビデオコンテンツ（１６）の画像（１８）のサブポーション（２４）を単位にして前記ビデオコンテンツ（１６）を有しており、
各サブポーション（２４）は、それぞれ前記ビデオ・データストリーム（２２）のパケットのシーケンス（３４）の１つ以上のペイロード・パケット（３２）に符号化され、前記パケットのシーケンス（３４）はアクセスユニット（３０）のシーケンスに分割されて、前記ビデオコンテンツ（１６）のそれぞれの画像（１８）に関連する前記ペイロード・パケット（３２）は、各アクセスユニット（３０）に属するようになっており、少なくともいくつかのアクセスユニットはＲＯＩ（関心領域）パケット（６４）が組み入れられたパケットのシーケンス（３４）を有していて、タイミング制御パケット（６４）が前記アクセスユニット（３０）を復号化ユニットに再分割するようにして、少なくともいくつかのアクセスユニット（３０）が前記それぞれのアクセスユニットの前記画像に関連するペイロード・パケット（３２）の間に組み入れられたＲＯＩパケット（６４）を有するようになっていて、前記各ＲＯＩパケットは、それぞれの前記ＲＯＩパケットに続くパケットの前記シーケンス（３４）において続く１つ以上のペイロード・パケットに関連し、それぞれのＲＯＩパケットが関連する１つ以上のペイロード・パケットのいずれかに符号化される前記サブポーション（２４）が前記ビデオコンテンツの関心領域を覆うかどうかについて確認し、前記ビデオ・データストリームは、ＲＯＩパケットに基づいて前記ビデオコンテンツの前記ＲＯＩを確認するようにネットワーク装置を有効にする、エンコーダ。

【請求項3】

ビデオコンテンツ（１６）の画像（１８）のサブポーション（２４）を単位にして前記ビデオコンテンツ（１６）が符号化されているビデオ・データストリームを復号化するための方法であって、
各サブポーション（２４）は、それぞれ前記ビデオ・データストリーム（２２）のパケットのシーケンス（３４）の１つ以上のペイロード・パケット（３２）に符号化され、前記パケットのシーケンス（３４）はアクセスユニット（３０）のシーケンスに分割されて、前記ビデオコンテンツ（１６）のそれぞれの画像（１８）に関連する前記ペイロード・パケット（３２）は、各アクセスユニット（３０）に属するようになっており、少なくともいくつかのアクセスユニットはＲＯＩ（関心領域）パケット（６４）が組み入れられたパケットのシーケンス（３４）を有していて、タイミング制御パケット（６４）が前記アクセスユニット（３０）を復号化ユニットに再分割するようにして、少なくともいくつかのアクセスユニット（３０）が前記それぞれのアクセスユニットの前記画像に関連するペイロード・パケット（３２）の間に組み入れられたＲＯＩパケット（６４）を有するようになっていて、前記各ＲＯＩパケットは、それぞれの前記ＲＯＩパケットに続くパケットの前記シーケンス（３４）において続く１つ以上のペイロード・パケットに関連し、それぞれのＲＯＩパケットが関連する１つ以上のペイロード・パケットのいずれかに符号化される前記サブポーション（２４）が前記ビデオコンテンツの関心領域を覆うかどうかについて確認し、前記方法は、前記ビデオ・データストリームを受信し、ＲＯＩパケットに基づいて前記ビデオコンテンツの前記ＲＯＩを確認するステップを含む、方法。

【請求項4】

ビデオ・データストリームを符号化するための方法であって、前記ビデオ・データストリームは、ビデオコンテンツ（１６）の画像（１８）のサブポーション（２４）を単位にして前記ビデオコンテンツ（１６）を有しており、
各サブポーション（２４）は、それぞれ前記ビデオ・データストリーム（２２）のパケットのシーケンス（３４）の１つ以上のペイロード・パケット（３２）に符号化され、前記パケットのシーケンス（３４）はアクセスユニット（３０）のシーケンスに分割されて、前記ビデオコンテンツ（１６）のそれぞれの画像（１８）に関連する前記ペイロード・パケット（３２）は、各アクセスユニット（３０）に属するようになっており、少なくともいくつかのアクセスユニットはＲＯＩ（関心領域）パケット（６４）が組み入れられたパケットのシーケンス（３４）を有していて、タイミング制御パケット（６４）が前記アクセスユニット（３０）を復号化ユニットに再分割するようにして、少なくともいくつかのアクセスユニット（３０）が前記それぞれのアクセスユニットの前記画像に関連するペイロード・パケット（３２）の間に組み入れられたＲＯＩパケット（６４）を有するようになっていて、前記各ＲＯＩパケットは、それぞれの前記ＲＯＩパケットに続くパケットの前記シーケンス（３４）において続く１つ以上のペイロード・パケットに関連し、それぞれのＲＯＩパケットが関連する１つ以上のペイロード・パケットのいずれかに符号化される前記サブポーション（２４）が前記ビデオコンテンツの関心領域を覆うかどうかについて確認し、前記ビデオ・データストリームは、ＲＯＩパケットに基づいて前記ビデオコンテンツの前記ＲＯＩを確認するようにネットワーク装置を有効にする、方法。

【請求項5】

コンピュータ上で動作するときに、請求項３に記載の方法を実行するためのプログラムコードを有する、コンピュータプログラム。

【請求項6】

コンピュータ上で動作するときに、請求項４に記載の方法を実行するためのプログラムコードを有する、コンピュータプログラム。

【請求項7】

ビデオコンテンツ（１６）の画像（１８）のサブポーション（２４）を単位にして前記ビデオコンテンツ（１６）が符号化されているビデオ・データストリームを受信するために構成されるネットワークエンティティであって、
各サブポーション（２４）は、それぞれ前記ビデオ・データストリーム（２２）のパケットのシーケンス（３４）の１つ以上のペイロード・パケット（３２）に符号化され、前記パケットのシーケンス（３４）はアクセスユニット（３０）のシーケンスに分割されて、前記ビデオコンテンツ（１６）のそれぞれの画像（１８）に関連する前記ペイロード・パケット（３２）は、各アクセスユニット（３０）に属するようになっており、少なくともいくつかのアクセスユニットはＲＯＩ（関心領域）パケット（６４）が組み入れられたパケットのシーケンス（３４）を有していて、タイミング制御パケット（６４）が前記アクセスユニット（６４）を復号化ユニットに再分割するようにして、少なくともいくつかのアクセスユニット（３０）が前記それぞれのアクセスユニットの前記画像に関連するペイロード・パケット（３２）の間に組み入れられたＲＯＩパケット（６４）を有するようになっていて、前記各ＲＯＩパケットは、それぞれの前記ＲＯＩパケットに続くパケットの前記シーケンス（３４）において続く１つ以上のペイロード・パケットに関連し、それぞれのＲＯＩパケットが関連する１つ以上のペイロード・パケットのいずれかに符号化される前記サブポーション（２４）が前記ビデオコンテンツの関心領域を覆うかどうかについて確認し、前記ネットワークエンティティは、ＲＯＩパケットに基づいてビデオコンテンツのＲＯＩを確認するように構成された、ネットワークエンティティ。

【請求項8】

前記ネットワークエンティティは、前記ビデオ・データストリームに関連する伝送タスクを決定するために前記確認の結果を使用するように構成された、請求項７に記載のネットワークエンティティ。

【請求項9】

前記伝送タスクが不良パケットに関する再伝送要求を含む、請求項７または請求項８に記載のネットワークエンティティ。

【請求項10】

前記ネットワークエンティティは、ＲＯＩパケットが関心領域の重なりがないことの信号を送る、ＲＯＩパケット、および前記それぞれのＲＯＩパケットが関連する、前記それぞれのＲＯＩパケット（７２）に続く前記１つ以上のペイロード・パケットよりも、それぞれのＲＯＩパケットが関連する前記１つ以上のペイロード・パケットのいずれかに符号化された前記サブポーション（２４）により前記関心領域の重なりをＲＯＩパケットの信号を送る、ＲＯＩパケット（７２）、および前記それぞれのＲＯＩパケットが関連する、前記それぞれのＲＯＩパケット（７２）に続く前記１つ以上のペイロード・パケットに高い優先度を割り当てることにより関心領域（７０）を優先的に取り扱うように構成される、請求項７または請求項８に記載のネットワークエンティティ。

【請求項11】

前記ネットワークエンティティは、低い優先度が割り当てられたペイロード・パケットの再伝送の要求より前に、高い優先度が割り当てられたペイロード・パケットの再伝送を要求するように構成される、請求項１０に記載のネットワークエンティティ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、特に、低い遅延アプリケーションと関連して有利であるビデオ・データストリーム・コンセプトに関する。

【背景技術】

【0002】

ＨＥＶＣ［２］は、アプリケーション層へのＨｉｇｈ Ｌｅｖｅｌ Ｓｙｎｔａｘシグナリングの異なる手段を可能にする。この種の手段は、ＮＡＬユニットヘッダ、Ｐａｒａｍｅｔｅｒ ＳｅｔｓおよびＳｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ（ＳＥＩ）Ｍｅｓｓａｇｅｓである。後者は、復号化プロセスで使用されない。Ｈｉｇｈ Ｌｅｖｅｌ Ｓｙｎｔａｘシグナリングの他の手段は、例えばＭＰＥＧ２ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ［３］またはＲｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ［４］等のそれぞれのトランスポート・プロトコル、およびそのペイロードに特有の仕様、例えばＨ．２６４／ＡＶＣ［５］のための提案、拡張性のあるビデオ符号化（ＳＶＣ）［６］またはＨＥＶＣ［７］等が起源である。このようなトランスポート・プロトコルは、例えばＨＥＶＣ［２］のような、それぞれのアプリケーションレイヤーコーデック仕様のＨｉｇｈ Ｌｅｖｅｌシグナリングに類似の構造および機構を使用するＨｉｇｈ Ｌｅｖｅｌシグナリングを導入することができる。このようなシグナリングの１つの例は、補助情報をトランスポートレイヤーに提供する〔６〕にて説明されているようなＰａｙｌｏａｄ Ｃｏｎｔｅｎｔ Ｓｃａｌａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＰＡＣＳＩ）ＮＡＬユニットである。

【0003】

パラメータ・セットのために、ＨＥＶＣは１つのおよび中心の位置でアプリケーションレイヤーにより使用される最も重要なストリーム情報に従うＶｉｄｅｏ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ＶＰＳ）を含む。初期の方法において、この情報は、複数のＰａｒａｍｅｔｅｒ ＳｅｔｓおよびＮＡＬユニットヘッダから集められることが必要とされていた。

【0004】

本出願に先立って、Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ（ＨＲＤ）のＣｏｄｅｄ Ｐｉｃｔｕｒｅ Ｂｕｆｆｅｒ（ＣＰＢ）動作に関する標準の状態、および Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ＰＰＳ）と同様にＤｅｐｅｎｄｅｎｔ Ｓｌｉｃｅｓのサブピクチャおよび構文を表す復号化ユニットの定義とともにＳｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ（ＳＰＳ）／Ｖｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）、Ｐｉｃｔｕｒｅ Ｔｉｍｉｎｇ ＳＥＩ、Ｂｕｆｆｅｒｉｎｇ Ｐｅｒｉｏｄ ＳＥＩに存在するすべての関連した構文は、以下の通りであった。

【0005】

サブピクチャ・レベルにおける低遅延ＣＰＢ動作を可能にするために、サブピクチャＣＰＢ動作が提案され、ＨＥＶＣドラフト標準７ＪＣＴＶＣ―Ｉ１００３［２］に組み込まれた。ここでは特に、復号化ユニットは、以下のように〔２〕のセクション３において定められた：
復号化装置：アクセスユニットまたはアクセスユニットのサブセット。ＳｕｂＰｉｃＣｐｂＦｌａｇが０に等しいものである場合、復号化ユニットはアクセスユニットである。さもなければ、復号化ユニットは、アクセスユニットおよび関連する非ＶＣＬ ＮＡＬユニットにおける１つ以上のＶＣＬ ＮＡＬユニットから成る。アクセスユニットにおける第１のＶＣＬ ＮＡＬユニットのために、関連する非ＶＣＬ ＮＡＬユニットはあり、そして、フィラーＮＡＬユニットは、もしあれば、第１のＶＣＬ ＮＡＬユニットにすぐに続き、第１のＶＣＬ ＮＡＬユニットに先行するアクセスユニットにおけるすべての非ＶＣＬ ＮＡＬユニットに続く。アクセスユニットにおける第１のＶＣＬ ＮＡＬユニットでないＶＣＬ ＮＡＬユニットのために、関連する非ＶＣＬ ＮＡＬユニットは、もしあれば、ＶＣＬ ＮＡＬユニットに直ちに続くフィラーデータＮＡＬユニットである。

【0006】

その時間まで定められる基準において、「復号化ユニットの除去および復号化ユニットの復号化のタイミング」が記載されていて、Ａｎｎｅｘ Ｃ「Ｈｙｐｏｔｈｅｎｔｉａｌ
ｒｅｆｅｒｅｎｃｅ ｄｅｃｏｄｅｒ」に加えられた。ｓｕｂ−ｐｉｃｔｕｒｅ ｔｉｍｉｎｇを送るために、ＶＵＩにおけるＨＲＤパラメータとともに、ｂｕｆｆｅｒｉｎｇ
ｐｅｒｉｏｄ ＳＥＩおよびｐｉｃｔｕｒｅ ｔｉｍｉｎｇ ＳＥＩメッセージは、サブピクチャユニットとして、復号化ユニットをサポートするまで拡張されている。

【0007】

〔２〕のＢｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄ ＳＥＩメッセージ構文は、図１に示される。

【0008】

ＮａｌＨｒｄＢｐＰｒｅｓｅｎｔＦｌａｇまたはＶｃｌＨｒｄＢｐＰｒｅｓｅｎｔＦｌａｇが１に等しいときに、ｂｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄ ＳＥＩメッセージはビットストリームのいかなるアクセスユニットとも関連していることがありえる、そして、ｂｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄ ＳＥＩメッセージは、各ＲＡＰアクセス装置と、および、ｒｅｃｏｖｅｒｙ ｐｏｉｎｔ ＳＥＩメッセージと関連する各アクセスユニットと関連する。

【0009】

いくつかの適用において、ｂｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄ ＳＥＩメッセージのしばしば起こる存在は好ましい。

【0010】

ｂｕｆｆｅｒｉｎｇ ｐｅｒｉｏｄは、復号化順序におけるｂｕｆｆｅｒｉｎｇ ＳＥＩメッセージの２つのインスタンス間のアクセスユニットのセットとして規定された。

【0011】

意味論は、以下の通りだった：

【0012】

ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、シーケンスＨＲＤ属性を含むシーケンス・パラメータ・セットを規定する。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は、バッファリング期間ＳＥＩメッセージと関連した主要な符号化画像によって参照される画像パラメータ・セットにおけるｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値に等しい。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は範囲０から３１の範囲内に含まれる。

【0013】

１に等しいｒａｐ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、ｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］構文要素の存在を規定する。存在しない場合、ｒａｐ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は、０に等しいものと推測される。関連する画像がＣＲＡ画像でもＢＬＡ画像でもない場合、ｒａｐ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇの値は０に等しい。

【0014】

ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］は、ＳｃｈｅｄＳｅｌＩｄｘ−ｔｈ−ＣＰＢのための最初のＣＰＢ除去遅延を規定する。構文要素は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられるビットの長さを有し、９０ｋＨｚクロックの単位にある。構文要素の値は、０に等しいものではなくて、９０ｋＨｚクロックタイムにおけるＣＰＢサイズの時間等価である９００００＊（ＣｐｂＳｉｚｅ［ＳｃｈｅｄＳｅｌＩｄｘ］÷ＢｉｔＲａｔｅ［ＳｃｈｅｄＳｅｌＩｄｘ］）を超えるものではない。

【0015】

ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］は、ＳｃｈｅｄＳｅｌＩｄｘ−ｔｈ ＣＰＢがＣＰＢに符号化データユニットの最初の搬送時間を規定するために使用される。構文要素は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられるビットの長さを有し、９０ｋＨｚクロックの単位にある。これらの構文要素はデコーダによって使用されず、搬送スケジューラ（ＨＳＳ）のためにだけ必要とされる。

【0016】

全ての符号化ビデオ・シーケンスの上に、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］の合計はＳｃｈｅｄＳｅｌＩｄｘの値ごとに一定であり、ｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］の合計はＳｃｈｅｄＳｅｌＩｄｘの値ごとに一定である。

【0017】

〔２〕の画像タイミングＳＥＩメッセージ構文は、図２に示される。

【0018】

画像タイミングＳＥＩメッセージの構文は、画像タイミングＳＥＩメッセージに関連する符号化画像のために機能しているシーケンス・パラメータ・セットの内容に依存していた。しかしながら、ＩＤＲまたはＢＬＡアクセスユニットの画像タイミングＳＥＩメッセージに先立ってアクセスユニットの範囲内でバッファリング期間ＳＥＩメッセージがない限り、関連するパラメータ・セット（そして、ビットストリームにおける第１の画像でないＩＤＲまたはＢＬＡ画像のために、符号化画像がＩＤＲ画像またはＢＬＡ画像であることの決定）は、符号化画像の第１の符号化スライスＮＡＬユニットを復号化するまで発生しない。符号化画像の符号化スライスＮＡＬユニットがＮＡＬユニット順序における画像タイミングＳＥＩメッセージに続くので、デコーダが符号化画像のために機能するシーケンス・パラメータのパラメータを決定するまで画像タイミングＳＥＩメッセージを含んでいるＲＢＳＰを格納することが必要であるケースがあり、そうすると、画像タイミングＳＥＩメッセージの構文解析を実行する。

【0019】

ビットストリームにおける画像タイミングＳＥＩメッセージの存在は、以下のように規定された。
−ＣｐｂＤｐｂＤｅｌａｙｓＰｒｅｓｅｎｔＦｌａｇが１に等しい場合、１つの画像タイミングＳＥＩメッセージは、符号化ビデオ・シーケンスのあらゆるアクセスユニットに存在する。
−さもなければ（ＣｐｂＤｐｂＤｅｌａｙｓＰｒｅｓｅｎｔＦｌａｇが０に等しい）、画像タイミングＳＥＩメッセージは、符号化ビデオ・シーケンスのいかなるアクセスユニットにも存在しない。

【0020】

意味論は、以下の通りに定められた：

【0021】

ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、バッファから画像タイミングＳＥＩメッセージに関連するアクセスユニットデータを除去する前の先行するアクセスユニットにおけるごく最近のバッファリング期間ＳＥＩメッセージに関連するアクセスユニットのＣＰＢからの除去の後、どれくらいのクロック・ティックを待つかについて規定する。この値は、ＨＳＳのためのＣＰＢにアクセスユニットデータの出現の最も早く可能な時間を計算するためにも用いられる。構文要素は、ビットの長さがｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられる固定長コードである。ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、法としての剰余２(cpb＿removal＿delay＿length＿minus1+1)カウンタである。

【0022】

構文要素ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの（ビットにおける）長さを決定するｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値は、画像タイミングＳＥＩメッセージに関連する主要な符号化画像のために機能するシーケンス・パラメータ・セットにおいて符号化されるｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値であるが、但し、ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙはバッファリング期間ＳＥＩメッセージを含んでいる先行するアクセスユニットの除去時間に関連するクロック・ティックの数を規定し、それは異なる符号化ビデオ・シーケンスのアクセスユニットであってもよい。

【0023】

ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙは、画像のＤＰＢ出力時間を計算するために使用される。それは、ＣＰＢからアクセス装置の最後の復号化装置の除去の後、復号化画像がＤＰＢから出力される前に、どれくらいのクロック・ティックを待たせるかについて規定する。

【0024】

画像は、それがいまだに「短期参照のために使用する」または「長期参照のために使用する」ものとしてマークされているその出力時間に、ＤＰＢから取り除かれない。

【0025】

１つのｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙだけは、復号化画像のために規定される。

【0026】

構文要素ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙの長さは、ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によってビットにおいて与えられる。ｓｐｓ＿ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ［ｍａｘ＿ｔｅｍｐｏｒａｌ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１］が０に等しいときに、ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙは０に等しくなるであろう。

【0027】

出力タイミング同調デコーダから出力されるいくつかの画像のｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙから得られる出力時間は、復号化順序においていくつかの次の符号化ビデオ・シーケンスにおけるすべての画像のｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙから得られる出力時間に先行する。

【0028】

この構文要素の値によって規定される画像アウトプット順序は、ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値によって規定されるのと同じ順序である。

【0029】

復号化順序において、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが１に等しいか、または１に等しいと推測されるＩＤＲまたはＢＬＡに先行するため、「バンピング」プロセスによって出力されない画像のために、ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙから得られる出力時間は、同じ符号化ビデオ・シーケンスの中ですべての画像と関連するＰｉｃＯｒｄｅｒＣｎｔＶａｌの値の増加と共に増加している。

【0030】

ｎｕｍ＿ｄｅｃｏｄｉｎｇ＿ｕｎｉｔｓ＿ｍｉｎｕｓ１ ｐｌｕｓ１は、画像タイミングＳＥＩメッセージが関連しているアクセスユニットにおける復号化ユニットの数を規定する。ｎｕｍ＿ｄｅｃｏｄｉｎｇ＿ｕｎｉｔｓ＿ｍｉｎｕｓ１の値は、０からＰｉｃＷｉｄｔｈＩｎＣｔｂｓ＊ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓ−１の範囲内において含まれている。

【0031】

ｎｕｍ＿ｎａｌｕｓ＿ｉｎ＿ｄｕ＿ｍｉｎｕｓ１［ｉ］ｐｌｕｓ１は、画像タイミングＳＥＩメッセージが関連しているアクセスユニットのｉ番目の復号化ユニットにおけるＮＡＬユニットの数を規定する。ｎｕｍ＿ｎａｌｕｓ＿ｉｎ＿ｄｕ＿ｍｉｎｕｓ１［ｉ］の値は、０からＰｉｃＷｉｄｔｈＩｎＣｔｂｓ＊ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓ−１の範囲内に含まれている。

【0032】

アクセスユニットの第１の復号化ユニットは、アクセスユニットにおける復号化順序において第１のｎｕｍ＿ｎａｌｕｓ＿ｉｎ＿ｄｕ＿ｍｉｎｕｓ１［０］の連続的なＮＡＬユニットから成る。アクセスユニットのｉ番目（ｉは０より大）の復号化ユニットは、復号化順序において、アクセスユニットの前の復号化ユニットにおける最後のＮＡＬユニットに直ちに続くｎｕｍ＿ｎａｌｕｓ＿ｉｎ＿ｄｕ＿ｍｉｎｕｓ１［ｉ］＋１の連続的なＮＡＬユニットから成る。各復号化ユニットには、少なくとも１つのＶＣＬ ＮＡＬ装置がある。ＶＣＬ ＮＡＬユニットに関連するすべての非ＶＣＬ ＮＡＬユニットが、同じ復号化ユニットに含まれる。

【0033】

ｄｕ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ｉ］は、画像タイミングＳＥＩメッセージに関連するアクセスユニットにおけるｉ番目の復号化ユニットをＣＰＢから除去する前であって前のアクセスユニットにおいてごく最近のバッファリング期間ＳＥＩメッセージに関連するアクセスユニットにおける第１の復号化ユニットのＣＰＢからの除去の後、どれくらいのサブピクチャ・クロック・ティックを待つかについて規定する。この値は、ＨＳＳのためのＣＰＢに復号化ユニットデータの到着の最も早い可能な時間を計算するためにも用いられる。構文要素は、ビットの長さがｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられる固定長コードである。ｄｕ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ｉ］は、２(cpb＿removal＿delay＿length＿minus1+1)カウンタを法とする剰余である。

【0034】

構文要素ｄｕ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ｉ］の（ビットにおける）長さを決定するｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値は、画像タイミングＳＥＩメッセージに関連する符号化画像のために機能するシーケンス・パラメータ・セットにおいて符号化されるｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１の値であるが、ｄｕ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ｉ］はバッファリング期間ＳＥＩメッセージを含む先行するアクセスユニットにおける第１の復号化ユニットの除去時間と関連してサブピクチャ・クロック・ティックの数を特定し、それは異なる符号化ビデオ・シーケンスのアクセスユニットでもよい。

【0035】

いくつかの情報は、〔２〕のＶＵＩ構文に含まれた。〔２〕のＶＵＩパラメータ構文は、図３に示される。〔２〕のＨＲＤパラメータ構文は、図４に示される。意味論は、以下の通りに定められた：

【0036】

１に等しいｓｕｂ＿ｐｉｃ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サブピクチャ・レベルのＣＰＢ除去遅延パラメータがあり、ＣＰＢがアクセスユニットレベルまたはサブピクチャ・レベルで作動することができることを示している。０に等しいｓｕｂ＿ｐｉｃ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、サブピクチャ・レベルのＣＰＢ除去遅延パラメータがなく、ＣＰＢはアクセスユニットレベルで作動することを示している。ｓｕｂ＿ｐｉｃ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがないとき、その値は０に等しいものであると推測される。

【0037】

ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｓｕｂ＿ｔｉｃｋは、サブピクチャ・クロック・ティックカウンタの（サブピクチャ・クロック・ティックと呼ばれる）１つの増加に対応する周波数ｔｉｍｅ＿ｓｃａｌｅ Ｈｚで作動するクロックのタイムユニットの数である。ｎｕｍ＿ｕｎｉｔｓ＿ｉｎ＿ｓｕｂ＿ｔｉｃｋは、０より大きい。サブピクチャ・クロック・ティックは、ｓｕｂ＿ｐｉｃ＿ｃｐｂ＿ｐａｒａｍｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇが１に等しいときに、符号化データにおいて表されることができる時間の最小限の間隔である。

【0038】

１に等しいｔｉｌｅｓ＿ｆｉｘｅｄ＿ｓｔｒｕｃｔｕｒｅ＿ｆｌａｇは、示される場合、符号化ビデオ・シーケンスにおいて機能している各画像パラメータ・セットが、構文要素ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１、ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１、ｕｎｉｆｏｒｍ＿ｓｐａｃｉｎｇ＿ｆｌａｇ、ｃｏｌｕｍｎ＿ｗｉｄｔｈ［ｉ］ｒｏｗ＿ｈｅｉｇｈｔ［ｉ］およびｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇと同じ値を有することを示す。０に等しいｔｉｌｅｓ＿ｆｉｘｅｄ＿ｓｔｒｕｃｔｕｒｅ＿ｆｌａｇは、異なる画像パラメータ・セットのタイル構文要素が同じ値を有することができるかまたは有することができないかを示す。ｔｉｌｅｓ＿ｆｉｘｅｄ＿ｓｔｒｕｃｔｕｒｅ＿ｆｌａｇ構文要素がないときに、それは０に等しいものであると推測される。

【0039】

１に等しいｔｉｌｅｓ＿ｆｉｘｅｄ＿ｓｔｒｕｃｔｕｒｅ＿ｆｌａｇの信号伝達は、符号化ビデオ・シーケンスにおける各画像がマルチスレッドの復号化の場合作業負荷配分に役立つかもしれない同一方法で分配されるタイルと同じ数を有するというデコーダへの保証である。

【0040】

〔２〕の充填材データは、図５に示されるフィルタデータＲＢＳＰ構文を使用して信号伝達された。

【0041】

ビットストリームおよびデコーダの適合をチェックするのに用いられる〔２〕の仮想参照デコーダは以下の通りに定められた：

【0042】

２種類のビットストリームは、このリコメンデーション｜国際基準についてチェックしているＨＲＤの適合に従属する。タイプＩビットストリームと呼ばれている第１のこの種のタイプのビットストリームは、ビットストリームのすべてのアクセスユニットのためのＶＣＬ ＮＡＬユニットおよびフィラーデータＮＡＬユニットだけを含んでいるＮＡＬユニットストリームである。タイプＩＩビットストリームと呼ばれている第２のタイプのビットストリームは、ビットストリームのすべてのアクセスユニットのためのＶＣＬ ＮＡＬユニットおよびフィラーデータＮＡＬユニットに加えて、以下のうちの少なくとも１つを含む：
− フィラーデータＮＡＬユニット以外のさらなる非ＶＣＬ ＮＡＬユニット、
− ＮＡＬユニットストリームからバイトストリームを形成するすべてのｌｅａｄｉｎｇ＿ｚｅｒｏ＿８ｂｉｔｓ、ｚｅｒｏ＿ｂｙｔｅ、ｓｔａｒｔ＿ｃｏｄｅ＿ｐｒｅｆｉｘ＿ｏｎｅ＿３ｂｙｔｅｓおよびｔｒａｉｌｉｎｇ＿ｚｅｒｏ＿８ｂｉｔｓ構文要素。

【0043】

図６は、〔２〕のＨＲＤによってチェックされるビットストリーム適合ポイントのタイプを示す。

【0044】

２種類のＨＲＤパラメータ・セット（ＮＡＬ ＨＲＤパラメータおよびＶＣＬ ＨＲＤパラメータ）が用いられる。ＨＲＤパラメータ・セットはビデオ有用性情報によって信号が伝達され、それはシーケンス・パラメータ構文構造の一部である。

【0045】

ＶＣＬ ＮＡＬユニットに付託されるすべてのシーケンス・パラメータ・セットおよび画像パラメータ・セット、および対応するバッファリング期間および画像タイミングＳＥＩメッセージは、ＨＲＤに、タイムリーな方法で、ビットストリームにおいて、または、他の手段によって伝達される。

【0046】

それらのＮＡＬユニット（またはちょうどそれらのいくつか）がこのリコメンデーション｜国際基準によって規定されない他の手段によってデコーダ（またはＨＲＤに）に伝達されるときに、非ＶＣＬ ＮＡＬユニットの「存在」のための仕様も満たされる。ビットを計数するために、ビットストリームに実際に存在する適当なビットだけは計数される。

【0047】

一例として、ビットストリームにおける存在以外の方法で伝達され、ビットストリームの中に存在するＮＡＬユニットを有する、非ＶＣＬ ＮＡＬユニットの同期は、ビットストリームの中の２つのポイントを示すことによって達成され、それらの間においてビットストリーム中に非ＶＣＬ ＮＡＬユニットが存在し、ビットストリーム中でそれを伝達することを決定されるエンコーダを有していた。

【0048】

非ＶＣＬ ＮＡＬユニットの内容がビットストリームの範囲内における存在以外のいくつかの手段によってアプリケーションのために伝達されるときに、非ＶＣＬ ＮＡＬユニットの内容の表現はこの添付において特定される同じ構文を使用することを必要としない。

【0049】

ＨＲＤ情報がビットストリーム内に含まれるときに、単にビットストリームに含まれる情報に基づいてのみビットストリームとこの従属の要求との一致を確認することができる点に注意すべきである。ＨＲＤ情報がビットストリームに存在しないときに、すべての「独立型」Ｔｙｐｅ Ｉビットストリームの場合のように、ＨＲＤデータがこのＲｅｃｏｍｍｅｎｄａｔｉｏｎ｜Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄにおいて特定されないいくつかの他の手段によって提供されるときに、一致は確認されることができるだけである。

【0050】

ＨＲＤは、図７に示すように、符号化画像バッファ（ＣＰＢ）、瞬間的な復号化プロセス、復号化画像バッファ（ＤＰＢ）および出力クロッピングを含む。

【0051】

ＣＰＢサイズ（ビットの数）は、ＣｐｂＳｉｚｅ［ＳｃｈｅｄＳｅｌＩｄｘ］である。時間的レイヤーＸのためのＤＰＢサイズ（画像格納バッファの数）は、０からｓｐｓ＿ｍａｘ＿ｔｅｍｐｏｒａｌ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１を含む範囲のＸごとにｓｐｓ＿ｍａｘ＿ｄｅｃ＿ｐｉｃ＿ｂｕｆｆｅｒｉｎｇ［Ｘ］である。

【0052】

可変ＳｕｂＰｉｃＣｐｂＰｒｅｆｅｒｒｅｄＦｌａｇは外部手段によって規定されているか、または、外部手段によって規定されないときは、０に規定される。

【0053】

可変ＳｕｂＰｉｃＣｐｂＦｌａｇは、以下の通りに引き出される：
SubPicCpbFlag=SubPicCpbPreferredFlag&&sub＿pic＿cpb＿params＿present＿flag

【0054】

ＳｕｂＰｉｃＣｐｂＦｌａｇが０に等しい場合、ＣＰＢはアクセスユニットレベルで作動し、各復号化ユニットはアクセスユニットである。さもなければ、ＣＰＢはサブピクチャ・レベルで作動し、各復号化ユニットはアクセスユニットのサブセットである。

【0055】

ＨＲＤは、次のように作動する。指定された到着スケジュールに従ってＣＰＢに流れ込む復号化ユニットに関連するデータは、ＨＳＳによって分配される。各復号化ユニットに関連したデータは削除されて、ＣＰＢ除去時間に瞬間的な復号化プロセスによって即座に復号化される。各復号化画像は、ＤＰＢに置かれる。復号化画像は、後のＤＰＢ出力時またはインター・プレディクション・リファレンスのためにもはや必要でなくなった時に、ＤＰＢから取り除かれる。

【0056】

ＨＲＤは、バッファ期間ＳＥＩによって特定されるように初期化される。ＣＰＢからの復号化ユニットの除去タイミングおよびＤＰＢからの復号化画像の出力タイミングは、画像タイミングＳＥＩメッセージにおいて規定される。特定の復号化ユニットに関するすべてのタイミング情報は、復号化ユニットのＣＰＢ除去時間の前に到着する。

【0057】

ＨＲＤは、ビットストリームおよびデコーダの一致をチェックするために用いられる。

【0058】

一致が、ビットストリームを生成するために用いられるすべてのフレームレイトおよびクロックが正確にビットストリームにおいて信号を送られる値に合致するという仮定の下で保証される一方、本当のシステムにおいて、これらの各々は信号を送られたか指定された値から変化することができる。

【0059】

すべての計算は本当の値によって行われ、その結果、丸め誤差は伝搬することができない。例えば、ちょうど復号化ユニットの除去より前の、または、後のＣＰＢのビットの数が、必ずしも整数であるというわけではない。

【0060】

可変ｔcは、以下の通りに引き出されて、クロック・ティックと呼ばれている：
tc=num＿units＿in＿tick time＿scale
可変ｔc＿subは、以下の通りに引き出されて、サブピクチャ・クロック・ティックと呼ばれている：
tc＿sub=num＿units＿in＿sub＿tick time＿scale

【0061】

以下は、制約を表すために規定される：
− アクセスユニット０である第１のアクセスニットを有する復号化順序においてアクセスユニットｎをｎ番目のアクセスユニットとする。
− 画像ｎをアクセスユニットｎの符号化画像または復号化画像であるとする。
− 復号化ユニット０である第１の復号化ユニットを有する復号化順序において復号化ユニットｍをｍ番目の復号化ユニットとする。

【0062】

〔２〕において、スライス・ヘッダ構文は、いわゆる従属スライスを可能にする。

【0063】

図８は、〔２〕のスライス・ヘッダ構文を示す。

【0064】

スライス・ヘッダ意味論は、以下の通りに定められた：

【0065】

１に等しいｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、示されていない各スライス・ヘッダ構文要素の値が、符号化ツリー・ブロック・アドレスがＳｌｉｃｅＣｔｂＡｄｄｒＲＳである符号化ツリー・ブロックを含んでいる前のスライスにおける対応するスライス・ヘッダの値に等しいと推測されることを示している。示されていないとき、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は０に等しいと推測される。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は、ＳｌｉｃｅＣｔｂＡｄｄｒＲＳが０に等しいときに、０に等しくなる。

【0066】

ｓｌｉｃｅ＿ａｄｄｒｅｓｓは、スライスが始まるスライス粒状解像度のアドレスを規定する。ｓｌｉｃｅ＿ａｄｄｒｅｓｓ構文要素の長さは、（ＣＥｉｌ（Ｌｏｇ２（ＰｉｃＷｉｄｔｈＩｎＣｔｂｓ＊ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓ））＋ＳｌｉｃｅＧｒａｎｕｌａｒｉｔｙ）ビットである。

【0067】

可変ＳｌｉｃｅＣｔｂＡｄｄｒＲＳは、符号化ツリー・ブロック・ラスタ・スキャン順序においてスライスがスタートする符号化木ブロックを規定して、以下の通りに引き出される。
SliceCtbAddrRS=(slice＿address>>SliceGranularity)

【0068】

可変ＳｌｉｃｅＣｂＡｄｄｒＺＳは、ｚ−スキャン順序の最小限の符号化ブロック粒度のスライスの第１の符号化ブロックのアドレスを規定して、以下の通りに引き出される。
SliceCbAddrZS=slice＿address
<<((log2＿diff＿max＿min＿coding＿block＿size=SliceGranularity）<<1)

【0069】

スライス復号化は、スライス開始座標の可能な最大の符号化ユニットで始まる。

【0070】

ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、スライスが画像の第１のスライスであるかどうかを示す。ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しい場合、変数ＳｌｉｃｅＣｂＡｄｄｒＺＳおよびＳｌｉｃｅＣｔｂＡｄｄｒＲＳは両方とも０に設定され、画像の第１の符号化ツリー・ブロックから復号化が始まる。

【0071】

ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、組み込まれた画像パラメータを規定する。ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は、０から２５５の範囲を含んでいる。

【0072】

ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓは、スライス・ヘッダのｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｉ］構文要素の数を規定する。ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが１に等しいとき、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓの値は、０から（ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１＋１）＊（ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１＋１）の範囲を含んでいる。ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しいとき、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓの値は、０からＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓ＝１の範囲を含んでいる。示されていないとき、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓの値は、０に等しいと推測される。

【0073】

ｏｆｆｓｅｔ＿ｌｅｎ＿ｍｉｎｕｓ１ ｐｌｕｓ１は、ビットにおいて、ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｉ］構文要素の長さを規定する。

【0074】

ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｉ］は、ｉ番目のエントリポイントのオフセットをバイトで規定し、ｏｆｆｓｅｔ＿ｌｅｎ＿ｍｉｎｕｓ１ ｐｌｕｓ１ビットによって表される。スライス・ヘッダの後の符号化スライス・データは、０からｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓの範囲を含む、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ＋１サブセットから成る。サブセット０は、符号化スライス・データｋの０からｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［０］−１を含むバイトからなり、ｋは１からｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ−１の範囲を含み、符号化スライス・データのｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｋ−１］からｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｋ］+ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｋ−１］−１を含むバイトからなり、（サブセット・インデックスがｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓに等しい）最後のサブセットは、符号化スライス・データの残りのバイトから成る。

【0075】

ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが１に等しく、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓが０より大きいとき、各サブセットは正確に１つのタイルのすべての符号化ビットを含み、サブセット（すなわち、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ＋１の値）の数はスライスのタイルの数以下である。
ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが１に等しいとき、各スライスは（エントリポイントのケース・シグナリングは、不必要である）１つのタイルのサブセットか完全なタイルの整数値を含まなければならない。

【0076】

ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しく、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓが０より大きいとき、０からｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ−１の範囲を含むｋを有する各サブセットｋは、確実に符号化ツリー・ブロックの１つの行の全ての符号化ビットを含み、（ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓに等しいサブセット・インデックスを有する）最後のサブセットは、スライスに含まれる残りの符号化ブロックの全ての符号化ビットを含み、残りの符号化ブロックは符号化ツリー・ブロックの正確に１つの行か符号化ツリー・ブロックの１つの行のサブセットのいずれかから成り、サブセットの数（すなわち、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ＋１の値）はスライスの符号化ツリー・ブロックの行の数に等しく、スライスの符号化ツリー・ブロックの１つの行のサブセットも計数される。

【0077】

ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しいとき、スライスは、符号化ツリー・ブロックの多くの行および符号化ツリー・ブロックの行のサブセットを含む。例えば、スライスが符号化ツリー・ブロックの２つ半分の行を含む場合、サブセットの数（すなわち、ｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ＋１の値）は３に等しいであろう。

【0078】

図９は、［２］の画像パラメータ・セットＲＢＳＰ構文、および〔２〕の画像パラメータ・セットＲＢＳＰ意味論を示し、以下のように定義される：

【0079】

１に等しいｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、画像パラメータ・セットを参照して符号化画像のためのスライス・ヘッダの構文要素ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの存在を規定する。０に等しいｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは画像パラメータ・セットを参照して符号化画像のためのスライス・ヘッダの構文要素ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの欠如を特定する。ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが３に等しいとき、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値は１に等しいであろう。

【0080】

０に等しいｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃは、画像パラメータ・セットを参照して各画像に１つのタイルだけがあることを示し、画像パラメータ・セットの各画像における符号化ツリー・ブロックの行の第１の符号化ツリー・ブロックを復号化する前に引き起こされる文脈の変化のための特定の同期プロセスを有し、画像パラメータ・セットを参照した符号化画像のためのｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は両方とも１に等しくないであろう。

【0081】

ｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇおよびｄｅｐｅｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは両方ともスライスのための１に等しいとき、スライスはエントロピー・スライスである。］

【0082】

１に等しいｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃは、画像パラメータ・セットを参照して、各画像に１つ以上のタイルがあることが示されており、画像パラメータ・セットを参照して各画像における符号化ツリー・ブロックの行の第１の符号化ツリーボックスを復号化する前に引き出される文脈変化のための特定の同期プロセスはないであろうし、画像パラメータ・セットを参照した符号化画像のためのｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は、両方とも１に等しくはないであろう。

【0083】

２に等しいｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃは、画像パラメータ・セットを参照して各画像に１つのタイルだけがあることを示しており、画像パラメータ・セットを参照して各画像における符号化ツリー・ブロックの行の第１の符号化ツリー・ブロックを復号化する前に文脈変化のための特定の同期プロセスが引き出され、画像パラメータ・セットを参照して各画像における符号化ツリーボックスの行の２つの符号化ツリー・ブロックを復号化した後に文脈変化のための特定の記憶プロセスが引き出され、画像パラメータを参照した符号化画像のためのｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は両方とも１にならないであろう。

【0084】

３に等しいｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃは、画像パラメータ・セットを参照して各画像に１つだけのタイルがあることを明確にし、画像パラメータ・セットを参照して各画像における符号化ツリー・ブロックの行の第１の符号化ツリー・ブロックを復号化する前に引き出される文脈変化のための特定の同期プロセスがないであろうし、画像パラメータ・セットを参照した符号化画像のためのｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの値は、両方とも１に等しいであろう。

【0085】

ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが０に等しいとき、ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃは３に等しくないであろう。

【0086】

ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃの値が符号化ビデオ・シーケンスの中で起動するすべての画像パラメータ・セットに共通することは、ビットストリーム適合の要件である。

【0087】

画像パラメータ・セットを参照して各スライスのために、ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しく、スライスの第１の符号化ブロックが符号化ツリー・ブロックの行の第１の符号化ツリー・ブロックでない場合、スライスの最後の符号化ブロックは、スライスの第１の符号化ブロックと同じ符号化ツリー・ブロックの行に属する。

【0088】

ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１プラス１は、画像を分割しているタイルの列の数を特定する。

【0089】

ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１プラス１は、画像を分割しているタイルの行の数を特定する。ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１が０に等しいとき、ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１は０に等しくないであろう。

【0090】

１に等しいｕｎｉｆｏｒｍ＿ｓｐａｃｉｎｇ＿ｆｌａｇはその列境界を規定し、同様に、行境界は画像全体に一様に分布される。０に等しいｕｎｉｆｏｒｍ＿ｓｐａｃｉｎｇ＿ｆｌａｇはその列境界を規定し、同様に、行境界は画像全体に一様に分布されないが、構文要素ｃｏｌｕｍｎ＿ｗｉｄｔｈ［ｉ］およびｒｏｗ＿ｈｅｉｇｈｔ［ｉ］を使用して明確に信号を送った。

【0091】

ｃｏｌｕｍｎ＿ｗｉｄｔｈ［ｉ］は、符号化ツリー・ブロックを単位とするｉ番目のタイルの列の幅を規定する。

【0092】

ｒｏｗ＿ｈｅｉｇｈｔ［ｉ］は、符号化ツリー・ブロックを単位にするｉ番目のタイルの行の高さを特定する。

【0093】

ベクトルｃｏｌＷｉｄｔｈ［ｉ］は０からｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１にわたっている列ｉを有するＣＴＢを単位にするｉ番目のタイルの列の幅を規定し、含んでいる。

【0094】

ベクトルＣｔｂＡｄｄｒＲＳｔｏＴＳ［ｃｔｂＡｄｄｒＲＳ］は、０から（ｐｉｃＨｅｉｇｈｔＩｎＣｔｂｓ＊ｐｉｃＷｉｄｔｈＩｎＣｔｂｓ）−１にわたっているインデックスｃｔｂＡｄｄｒＲＳで、ラスタ・スキャン順序のＣＴＢアドレスからタイルスキャン順序のＣＴＢアドレスまでの会話を規定し、含んでいる
ベクトルＣｔｂＡｄｄｒＴＳｔｏＲＳ［ｃｔｂＡｄｄｒＴＳ］は、０から（ｐｉｃＨｅｉｇｈｔＩｎＣｔｂｓ＊ｐｉｃＷｉｄｔｈＩｎＣｔｂｓ）−１にわたっているインデックスｃｔｂＡｄｄｒＴＳで、タイルスキャン順序のＣＴＢアドレスからラスタ・スキャン順序のＣＴＢアドレスまでの会話を規定し、含んでいる

【0095】

ベクトルＴｉｌｅＩｄ［ｃｔｂＡｄｄｒＴＳ］は、０から（ｐｉｃＨｅｉｇｈｔＩｎＣｔｂｓ＊ｐｉｃＷｉｄｔｈＩｎＣｔｂｓ）−１にわたっているｃｔｂＡｄｄｒＴＳで、タイルスキャン順序のＣＴＢアドレスからタイルｉｄへの会話を規定し、含んでいる

【0096】

ｃｏｌＷｉｄｔｈ、ＣｔｂＡｄｄｒＲＳｔｏＴＳ、ＣｔｂＡｄｄｒＴＳｔｏＲＳおよびＴｉｌｅＩｄの値は、入力として、サブクローズ６．５．１において規定されたように、ＣＴＢラスタおよびタイルスキャニングを呼び出すことによって引き出され、出力は、ｃｏｌＷｉｄｔｈ、ＣｔｂＡｄｄｒＲＳｔｏＴＳおよびＴｉｌｅＩｄに割り当てられる。

【0097】

ｌｕｍａサンプルを単位にするｉ番目のタイルの列の幅を規定する、ＣｏｌｕｍｎＷｉｄｔｈＩｎＬｕｍａＳａｍｐｌｅｓ［ｉ］の値は、ｃｏｌＷｉｄｔｈ［ｉ］＜＜Ｌｏｇ２ＣｔｂＳｉｚｅに等しく設定される。

【0098】

０からｐｉｃＷｉｄｔｈＩｎＭｉｎＣｂｓ−１にわたっているｘ、および０からｐｉｃＨｅｉｇｈｔＩｎＭｉｎＣｂｓ−１にわたっているｙで、ｚ−スキャン順序における最小限のＣＢｓを単位にするロケーション（ｘ，ｙ）から最小限のＣＢアドレスへの会話を規定するアレイＭｉｎＣｂＡｄｄｒＺＳ［ｘ］［ｙ］は、入力および出力がＭｉｎＣｂＡｄｄｒＺＳに割り当てられるように、Ｌｏｇ２ＭｉｎＣｂＳｉｚｅ、Ｌｏｇ２ＣｔｂＳｉｚｅ、ＰｉｃＨｅｉｇｈｔＩｎＣｔｂｓ、ＰｉｃＷｉｄｔｈＩｎＣｔｂｓ、およびベクトルＣｔｂＡｄｄｒＲＳｔｏＴＳで、サブクローズ６.５.２に規定されるようなＺスキャニング順序アレイ初期化プロセスを呼び出すことによって得られる。

【0099】

１に等しいｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、インループフィルタリング動作がタイル境界全体に実行されることを示している。０に等しいｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、インループフィルタリング動作がタイル境界全体に実行されないことを示している。インループフィルタリング動作は、デブロッキング・フィルタ、サンプル適応オフセットおよび適応ループ・フィルタ動作を含む。ないときには、ｌｏｏｐ＿ｆｉｌｔｅｒ＿ａｃｒｏｓｓ＿ｔｉｌｅｓ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値は１に等しいものと推測される。

【0100】

１に等しいｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇは、スライスの符号化ブロックのＣＡＢＡＣ復号化が前に復号化されたスライスのいかなる様相からも独立していることを示している。０に等しいｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇは、スライスの符号化ブロックのＣＡＢＡＣ復号化が前に復号化されたスライスの様相に依存していることを示している。ないときには、ｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇの値は０に等しいものであると推測される。

【0101】

最小限の符号化ブロック・アドレスを有する符号化ブロックの入手可能性のための派生プロセスは、以下の通りに説明されていた：
このプロセスへの入力は、次のようなものである。
−ｚ−スキャン順序の最小限の符号化ブロック・アドレスｍｉｎＣｂＡｄｄｒＺＳ
−ｚ−スキャン順序の現在の最小限の符号化ブロック・アドレスｃｕｒｒＭｉｎＣＢＡｄｄｒＺＳ

【0102】

このプロセスの出力は、ｚ−スキャン順序ｃｂＡｖａｉｌａｂｌｅにおける最小限の符号化ブロック・アドレスｃｂＡｄｄｒＺＳを有する符号化ブロックの入手可能性である。

【0103】

このプロセスが呼び出されるときに、有効性の意味が決定されることに注意されたい。

【0104】

そのサイズに関係なく、いかなる符号化ブロックも、ｚ−スキャン順序の最小限の符号化ブロック・サイズを有する符号化ブロックのアドレスである最小限の符号化ブロック・アドレスと関係していることに注意されたい。

【0105】

−以下の状況の１つ以上が真である場合、ｃｂＡｖａｉｌａｂｌｅはＦＡＬＳＥにセットされる。
−ｍｉｎＣｂＡｄｄｒＺＳは、０未満である
−ｍｉｎＣｂＡｄｄｒＺＳは、ｃｕｒｒＭｉｎＣＢＡｄｄｒＺＳより大きい
−最小限の符号化ブロック・アドレスｍｉｎＣｂＡｄｄｒＺＳを有する符号化ブロックは、現在の最小限の符号化ブロック・アドレスｃｕｒｒＭｉｎＣＢＡｄｄｒＺＳを有する符号化ブロックに属し、現在の最小限の符号化ブロック・アドレスｃｕｒｒＭｉｎＣＢＡｄｄｒＺＳを有する符号化ブロックを含んでいるスライスのｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇと異なるスライスは０に等しい。
−最小限の符号化ブロック・アドレスｍｉｎＣｂＡｄｄｒＺＳを有する符号化ブロックは、現在の最小限の符号化ブロック・アドレスｃｕｒｒＭｉｎＣＢＡｄｄｒＺＳを有する符号化ブロックとは異なるタイルに含まれる。
−さもなければ、ｃｂＡｖａｉｌａｂｌｅは、ＴＲＵＥにセットされる。

【0106】

〔２〕のスライス・データのためのＣＡＢＡＣ構文解析プロセスは、以下の通りだった：
記述子ａｅ（ｖ）を有する構文要素を解析するときに、このプロセスは呼び出される。

【0107】

このプロセスへの入力は、構文要素の値および前に解析された構文要素の値の要求である。

【0108】

このプロセスの出力は、構文要素の値である。

【0109】

スライスのスライス・データの構文解析を始めるときに、ＣＡＢＡＣ構文解析プロセスの初期化プロセスは呼び出される。

【0110】

空間隣接ブロックＴ（図１０ａ）を含んでいる符号化ツリー・ブロックの最小限の符号化ブロック・アドレス、ｃｔｂＭｉｎＣｂＡｄｄｒＴは、以下のように現在の符号化ツリー・ブロックの左上ｌｕｍａサンプルのロケーション（ｘ０，ｙ０）を使用して引き出される。
x=x0+2<<Log2CtbSize-1
y=y0-1
ctbMinCbAddrT=MinCbAddrZS[x>>Log2MinCbSize][y>>Log2MinCbSize]

【0111】

可変ａｖａｉｌａｂｌｅＦｌａｇＴは、入力としてｃｔｂＭｉｎＣｂＡｄｄｒＴを有する符号化ブロック有効性派生プロセスを呼び出すことによって得られる。

【0112】

符号化ツリーの構文解析を始めるときに、以下の手順が適用される。
１．算術復号化エンジンは、以下のように初期化される。
−ＣｔｂＡｄｄｒＲＳがｓｌｉｃｅ＿ａｄｄｒｅｓｓに等しい場合、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは１に等しく、ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｒｅｓｅｔ＿ｆｌａｇは０に等しく、以下が適用される。
−ＣＡＢＡＣ構文解析プロセスの同期化プロセスは、入力としてのＴａｂｌｅＳｔａｔｅＩｄｘＤＳおよびＴａｂｌｅＭＰＳＶａｌＤＳによって呼び出される。
−終了の前のバイナリの決定のための復号化プロセスは呼び出され、算術復号化のための初期化プロセスが続く。
−さもなければ、ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しく、ＣｔｂＡｄｄｒＲＳ％ＰｉｃＷｉｄｔｈＩｎＣｔｂｓが０に等しい場合、以下が適用される。
−ａｖａｉｌａｂｌｅＦｌａｇＴが１に等しいとき、ＣＡＢＡＣ構文解析プロセスの同期化プロセスは、入力としてのＴａｂｌｅＳｔａｔｅＩｄｘＷＰＰおよびＴａｂｌｅＭＰＳＶａｌＷＰＰによって呼び出される。
−終了の前のバイナリの決定のための復号プロセスは呼び出され、算術復号化エンジンのための初期化プロセスが続く。

【0113】

２．ｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇが０に等しく、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが１に等しいとき、または、ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しいとき、記憶プロセスは以下のように適用される。
−ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが２に等しく、ＣｔｂＡｄｄｒＲＳ％ＰｉｃＷｉｄｔｈＩｎＣｔｂｓが２に等しいとき、ＣＡＢＡＣ構文解析プロセスの記憶プロセスは出力としてＴａｂｌｅＳｔａｔｅＩｄｘＷＰＰおよびＴａｂｌｅＭＰＳＶａｌＷＰＰによって呼び出される。
−ｃａｂａｃ＿ｉｎｄｅｐｅｎｄｅｎｔ＿ｆｌａｇが０に等しく、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが１に等しく、ｅｎｄ＿ｏｆ＿ｓｌｉｃｅ＿ｆｌａｇが１に等しいとき、ＣＡＢＡＣ構文分析プロセスの記憶プロセスは出力としてＴａｂｌｅＳｔａｔｅＩｄｘＤＳおよびＴａｂｌｅＭＰＳＶａｌＤＳによって呼び出される。

【0114】

構文要素の構文解析は、以下の通りに進行する：

【0115】

構文要素の要求された値ごとに、２値化が得られる。

【0116】

構文要素のための２値化および構文解析されたビン（ｂｉｎ）のシーケンスは、復号化プロセスフローを決定する。

【0117】

可変ｂｉｎＩｄｘによってインデックスを付けられる構文要素の２値化のビンごとに、文脈インデックスｃｔｘＩｄｘが得られる。

【0118】

ｃｔｘＩｄｘごとに、算術復号化プロセスが起動する。

【0119】

構文解析されたビンの結果として生じるシーケンス（ｂ0・・・ｂbinIdx）は、各ビンの復号化の後、２値化プロセスによって与えられるビンストリングのセットと比較される。与えられたセットにおいてシーケンスがビンに一致するときに、対応する値は構文要素に割り当てられる。

【0120】

構文要素の値の要求が構文要素ｐｃｍ−ｆｌａｇおよびｐｃｍ＿ｆｌａｇの復号化値が１に等しい場合、復号化エンジンはいかなるｐｃｍ＿ａｌｉｇｎｍｅｎｔ＿ｚｅｒｏ＿ｂｉｔも、ｎｕｍ＿ｓｕｂｓｅｑｕｅｎｔ＿ｐｃｍおよびすべてのｐｃｍ＿ｓａｍｐｌｅ＿ｌｕｍａおよびｐｃｍ＿ｓａｍｐｌｅ＿ｃｈｒｏｍａデータを復号化した後に初期化される。

【0121】

今までに記載されている設計フレームワークにおいて、以下の課題が発生した。

【0122】

復号化ユニットのタイミングは、低遅延シナリオでデータを符号化し送信する前に知られている必要があり、ＮＡＬユニットはすでにエンコーダによって送られ、その一方で、エンコーダは画像、すなわち、他のサブピクチャ復号化ユニットをまだ符号化している。これは、アクセスユニットにおけるＮＡＬユニット順序が、アクセスユニットにおけるＶＣＬ（ビデオ符号化ＮＡＬユニット）に先行するＳＥＩメッセージを許しているだけであって、そのような低遅延シナリオにおいて、エンコーダが復号化ユニットの符号化を開始している場合、非ＶＣＬ ＮＡＬユニットはすでに通信、すなわち送信されている必要があるためである。図１０ｂは、〔２〕に記載のアクセスユニットの構造を例示する。〔２〕はまだシーケンスまたはストリームの端部を特定しておらず、そのため、アクセスユニットのそれらの存在は暫定的であった。

【0123】

また、サブピクチャに関連するＮＡＬユニットの数が低遅延シナリオにおいて予め知られていなければならず、それは、画像タイミングＳＥＩがこの情報を含み、従わなければならず、エンコーダが実際の画像を符号化し始める前に送信しなければならないためである。アプリケーションデザイナーは、ＮＡＬユニットナンバーに適合するフィルタデータが潜在的に存在しないフィルタデータＮＡＬユニットをしぶしぶ挿入するが、それは、画像タイミングＳＥＩの復号化ユニットごとに送信され、サブピクチャ・レベル上のこの情報を送信する手段を必要とするからである。それは、タイミングＳＥＩメッセージにおいて与えられるパラメータによってアクセスユニットの存在で現在確定されるサブピクチャ・タイミングのために保持する。

【0124】

さらに、仕様書案［２］の更なる欠点は、例えばＲＯＩシグナリングまたはタイル次元シグナリングのように、特殊利用のために必要とされるサブピクチャ・レベルの多数のシグナリングを含む。

【先行技術文献】

【非特許文献】

【0125】

【非特許文献1】Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, Ajay Luthra, "Overview of the H.264/AVC Video Coding Standard", IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, July 2003.

【非特許文献2】JCT-VC, "High-Efficiency Video Coding (HEVC) text specification Working Draft 7", JCTVC-I1003, May 2012.

【非特許文献3】ISO/IEC 13818-1: MPEG-2 Systems specification.

【非特許文献4】IETF RFC 3550 − Real-time Transport Protocol.

【非特許文献5】Y.-K. Wang et al.,"RTP Payload Format for H.264 Video", IETF RFC6184, http://tools.ietf.org/html/

【非特許文献6】S. Wenger et al., "RTP Payload Format for Scalable Video Coding", IETF RFC6190, http://tools.ietf.org/html/rfc6190

【非特許文献7】T. Schierl et al., "RTP Payload Format for High Efficiency Video Coding", IETF internet draft, http://datatracker.ietf.org/doc/draft-schierl-payload-rtp-h265/

【発明の概要】

【発明が解決しようとする課題】

【0126】

上記の概説された課題は、ＨＥＶＣ基準に特有のものではない。むしろ、この課題は、同様に他のビデオ・コーデックと関連して発生する。さらに一般的にいえば、図１１は、短時間の端末間遅延でエンコーダ１０からデコーダ１２にビデオ１６を送信するためにネットワーク１４を介して一対のエンコーダ１０およびデコーダ１２が接続されているビデオ伝送風景を示す。すでに上で概説される課題は次のようなものである。エンコーダ１０は、必然的にではなく実質的に、フレーム１８の再現順序２０に続き、各フレーム１８内で、例えばフレーム１８のタイル−セクショニング方法を有するあるいは有していないラスタ・スキャンのようないくつかの特定の方法でフレーム１８のフレーム領域を通して伝わる特定の復号化順序に従って、ビデオ１６のフレーム１８のシーケンスを符号化する。復号化順序は、例えば予測および／またはエントロピー符号化、すなわち、予測または文脈選択の基礎として役立つ利用可能なビデオ１６の空間的および／または時間的に隣接する部分に関する情報の有効性のように、エンコーダ１０によって用いられる符号化技術のための情報の有効性を制御する。エンコーダ１０がビデオ１６のフレーム１８を符号化するために並列処理を使用することが可能かもしれない場合であっても、エンコーダ１０は必然的に、現行フレームのような特定のフレーム１８を符号化する若干の時間を必要とする。図１１は、例えば、エンコーダ１０がすでに現行フレーム１８の部分１８ａを符号化し終わった瞬間を示し、その一方で、現行フレーム１８の他の部分１８ｂはまだ符号化されなかったことを示す。エンコーダ１０が部分１８ｂをまだ符号化しなかったので、エンコーダ１０は現行フレーム１８を符号化するための利用可能なビットレートがどのように、例えば、率／歪曲認識力に関して最適条件を成し遂げるために現行フレーム１８を通じて空間的に分配されるべきかについて予測することができない。したがって、エンコーダ１０は、単に２つの選択を有するだけである：エンコーダ１０は、現在のフレーム１８が前もって空間的にさらに細かく分割されるスライス上に現在のフレーム１８のための利用可能なビットレートの最適に近い分配を推測し、したがって推測は間違っていると認めるか、または、エンコーダ１０は、エンコーダ１０からデコーダ１２にスライスを含むパケットを送信する前に現在のフレーム１８の符号化を終了させているかのどちらかである。
いずれにせよ、その符号化の終了の前に現在の符号化フレーム１８のスライス・パケットのいかなる伝送も利用することが可能であるために、ネットワーク１４は、符号化ピクチャ・バッファ検索時間の形でこの種の各スライス・パケットと関連したビットレートを知らせるべきである。しかしながら、上述のように、エンコーダ１０は、ＨＥＶＣの現在バージョンに従って、個々にサブピクチャ領域のためのデコーダバッファ検索時間を定めることを用いてフレーム１８上に分配されるビットレートを変化させることが可能であるにもかかわらず、エンコーダ１０は、現在のフレーム１８に関する全てのデータを集める各アクセスユニットの初めにおいてネットワーク１４を介してデコーダ１２にそのような情報を送信または送る必要があり、それにより、エンコーダ１０に概説した選択肢の中から選択することを促し、一方は低い遅延であるが悪い率／歪曲をリードし、他方は最適な率／歪曲であるが増加した端末間遅延をリードする。

【0127】

このように、これまで、エンコーダが現在のフレームの残りの部分１８ｂを符号化するのに先立って現在のフレームの部分１８ａに関するパケットの送信の開始を可能にし、デコーダがエンコーダ１２からデコーダ１４に送るビデオ・データストリーム内で伝達される復号化バッファ検索タイミングに従うネットワーク１６による予備部分１８ａに関してパケットのこの中間伝達を利用するような低遅延の成績を可能にしたビデオ・コーデックはなかった。例えば、見本としてこの種の低い遅延を利用するアプリケーションは、例えばオートメーションまたは点検目的等のためのワークピースまたは製作監視のような産業アプリケーションを含む。これまで、ネットワーク１６の中の中間のネットワーク存在物がパケット、すなわちスライス構文の内部を深く検査する必要のないデータストリームからこの種の情報を集めることを可能にされるように、現在のフレームが構成され、領域（関心領域）に関心を持たせるタイルへのパケットの関連上の復号化側に知らせるための十分な解決もない。

【0128】

したがって、この発明の目的は、低い端末間遅延を可能にする際により効率的でおよび／または関心領域に、または、特定のタイルにデータストリームの部分の識別がより容易になるビデオ・データストリーム符号化コンセプトを提供することである。

【課題を解決するための手段】

【0129】

この目的は、特許請求の範囲の独立請求項の主題によって達成される。

【0130】

本出願が基礎とする１つの考えは、デコーダ検索タイミング情報、ＲＯＩ情報およびタイル識別情報がＭＡＮＥｓまたはデコーダのようなネットワークエンティティによって簡単なアクセスを可能にするレベルでビデオ・データストリームの中で伝達されなければならないということであり、この種のレベルに達するために、この種のタイプの情報がビデオ・データストリームのアクセスユニットのパケットに分散するパケットを経由してビデオ・データストリームの中で伝達されなければならないということである。実施例によれば、分散型のパケットは、除去可能なパケット・タイプの中にある、すなわち、これらの分散型のパケットの除去は、完全に、ビデオ・データストリームを介して運搬されるビデオ内容を回復するデコーダの能力を維持する。

【0131】

本出願の態様によれば、低い端末間遅延の達成は、現在のアクセスユニットの範囲内でビデオ・データストリームのそれぞれのタイミング制御パケットに続くペイロード・パケットによって形成される復号化ユニットのためのデコーダバッファ検索時間に情報を伝達するために、分散型のパケットを用いることによってより効果的になる。この計測によって、エンコーダは、現在のフレームを符号化する間、その場でデコーダバッファ検索時間を決定することを可能にされ、現在のフレームを符号化する間、実はすでにペイロード・パケットに符号化され、送信された現在のフレームの部分に費やされるか、または、一方で、タイミング制御パケットによって前に置かれ、したがって、まだ符号化されていなかった現在のフレームの残りの部分上に現在のフレームに利用できる残りのビットレートの分配を適応させるビットレートを連続的に決定することができるようになる。この計測によって、利用可能なビットレートは効果的に利用され、そして、エンコーダが完全に現在のフレームを符号化し終わるために待つ必要がないため、遅延はそれにもかかわらずより短く保たれる。

【0132】

本出願の更なる態様によれば、アクセスユニットのペイロード・パケットに分散するパケットは関心領域に情報伝達するために利用され、それによって、上述したように、中間のペイロード・パケットを検査する必要がないため、ネットワークエンティティによってこの情報の簡単なアクセスが可能になる。さらに、エンコーダは、前もってサブポーションおよびそれぞれのペイロード・パケットに現在のフレームの細別を決定する必要がなく、現在のフレームを符号化する間、臨機応変にＲＯＩに属しているパケットを決定することがまだできる。さらに、分散型のパケットが移動可能なパケット・タイプである実施例によれば、ＲＯＩ情報は、ＲＯＩ情報に関心がないか、それを処理することができないビデオ・データストリームの受容者によって無視されることができる。

【0133】

類似の考えは、分散型のパケットがアクセスユニットの範囲内の特定のパケットがどのタイルに属するかについて情報伝達する他の態様に従う本出願において利用される。

【0134】

本発明の有利な実施態様は、従属クレームの主題である。
本出願の好ましい実施例は、以下の図を参照して更に詳細に記載されており、図１ないし図１０ｂはＨＥＶＣの現在の状態を示している。

【図面の簡単な説明】

【0135】

【図1】図１は、バッファ期間ＳＥＩメッセージ構文を示す。

【図2】図２は、画像タイミングＳＥＩメッセージ構文を示す。

【図3a】図３ａは、ＶＵＩパラメータ構文を示す。

【図3b】図３ｂは、ＶＵＩパラメータ構文を示す。

【図4】図４は、ＨＲＤパラメータ構文を示す。

【図5】図５は、フィラーデータＲＢＳＰ構文を示す。

【図6】図６は、ＨＲＤ一致チェックのためのバイトストリームおよびＮＡＬユニットストリームの構造を示す。

【図7】図７は、ＨＲＤバッファ・モデルを示す。

【図8】図８は、スライス・ヘッダ構文を示す。

【図9】図９は、画像パラメータ・セットＲＢＳＰ構文を示す。

【図10a】図１０ａは、場合により現在の符号化ツリー・ブロックに関連する符号化ツリー・ブロック利用誘導プロセスを起動させるために用いられる空間的に隣接する符号化ツリー・ブロックＴの図解図を示す。

【図10b】図１０ｂは、アクセスユニットの構造の定義を示す。

【図11】図１１は、図式的に、ビデオ・データストリーム伝送で起こっている課題を例示するためのネットワークを介して接続される一対のエンコーダおよびデコーダを示す。

【図12】図１２は、タイミング制御パケットを使用している実施例に従うエンコーダの概略ブロック図を示す。

【図13】図１３は、実施例に従う図１２のエンコーダの作動モードを例示しているフロー図を示す。

【図14】図１４は、図１２に従ってエンコーダによって発生するビデオ・データストリームと関連してその機能を説明するためにデコーダの実施例のブロック図を示す。

【図15】図１５は、ＲＯＩパケットを使用している更なる実施例に従ってエンコーダ、ネットワーク実体およびビデオ・データストリームを例示している概略ブロック図を示す。

【図16】図１６は、タイル識別パケットを使用している更なる実施例に従ってエンコーダ、ネットワークエンティティおよびビデオ・データストリームを例示している概略ブロック図を示す。

【図17】図１７は、実施例に従ってアクセスユニットの構造を示す。点線は、任意のスライス接頭辞ＮＡＬユニットのケースを反映する。

【図18】図１８は、関心シグナリングの領域のタイルの使用を示す。

【図19】図１９は、第１の単純な構文／バージョン１を示す。

【図20】図２０は、ＳＥＩメッセージコンセプトとは異なるｔｉｌｅ＿ｉｄ ｓｉｇｎａｌｉｎｇ、復号化ユニットスタート識別子、スライス接頭辞ＩＤおよびスライス・ヘッダデータを含む拡張した構文／バージョン２を示す。

【図21】図２１は、ＮＡＬユニットタイプ・コードおよびＮＡＬユニットタイプクラスを示す。

【図22】図２２は、スライス・ヘッダのための可能な構文を示し、現在のバージョンに従うスライス・ヘッダに存在する特定の構文要素は、ｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａと呼ばれる下部の階層構文要素へ移される。

【図23a】図２３ａは、スライス・ヘッダから離れたすべての構文要素が構文要素スライス・ヘッダデータによって信号を送られるテーブルを示す。

【図23b】図２３ｂは、スライス・ヘッダから離れたすべての構文要素が構文要素スライス・ヘッダデータによって信号を送られるテーブルを示す。

【図23c】図２３ｃは、スライス・ヘッダから離れたすべての構文要素が構文要素スライス・ヘッダデータによって信号を送られるテーブルを示す。

【図24】図２４は、補足的な強化情報メッセージ構文を示す。

【図25a】図２５ａは、新しいスライスまたはサブピクチャＳＥＩメッセージタイプを導入するために、構成されるＳＥＩペイロード構文を示す。

【図25b】図２５ｂは、新しいスライスまたはサブピクチャＳＥＩメッセージタイプを導入するために、構成されるＳＥＩペイロード構文を示す。

【図26】図２６は、サブピクチャ・バッファＳＥＩメッセージのための実施例を示す。

【図27】図２７は、サブピクチャ・タイミングＳＥＩメッセージのための実施例を示す。

【図28】図２８は、サブピクチャスライス情報ＳＥＩがどのように見えるかを示す。

【図29】図２９は、サブピクチャ・タイル情報ＳＥＩメッセージのための実施例を示す。

【図30】図３０は、サブピクチャ・タイル範囲情報ＳＥＩメッセージのための構文の例を示す。

【図31】図３１は、各ＲＯＩが個々のＳＥＩメッセージにおいて信号を送られる関心領域ＳＥＩメッセージのための構文の例の第１の変異型を示す。

【図32】図３２は、すべてのＲＯＩが単一のＳＥＩメッセージにおいて信号を送られる関心領域ＳＥＩメッセージのための構文の例の第２の変異型を示す。

【図33】図３３は、更なる実施例に従うタイミング制御パケットのための可能な構文を示す。

【図34】図３４は、実施例に従うタイル識別パケットのための可能な構文を示す。

【図35】図３５は、実施例に従う異なる細別設定に従う画像の可能な細別を示す。

【図36】図３６は、実施例に従う異なる細別設定に従う画像の可能な細別を示す。

【図37】図３７は、実施例に従う異なる細別設定に従う画像の可能な細別を示す。

【図38】図３８は、実施例に従う異なる細別設定に従う画像の可能な細別を示す。

【図39】図３９は、アクセスユニットのペイロード・パケットとの間に分散しているタイミング制御パケットを使用している実施例に従うビデオ・データストリームからの部分の例を示す。

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

【0136】

図１２に関して、本出願およびその作動モードの実施例に従うエンコーダ１０が記載されている。エンコーダ１０は、ビデオ内容１６をビデオ・データストリーム２２に符号化するように構成される。エンコーダは、ビデオ内容１６のフレーム／画像１８のサブポーションを単位にしてこれをするように構成され、サブポーションは、例えば、画像１８が分割されるスライス２４、または例えばタイル２６またはＷＰＰサブストリーム２８のようないくつかの他の空間部分でもよく、その全ては、エンコーダ１０が、例えば、タイルまたはＷＰＰ並列処理をサポートすることが可能なことを必要とする、または、サブポーションがスライスであることを必要とすることを示唆しているというよりはむしろ、図示する目的だけのために単に図１２において例示される。

【0137】

サブポーション２４を単位にするビデオ内容１６を符号化することにおいて、エンコーダ１０は、復号化順序に沿ってそのようなブロックの連続運転を示すサブポーションをもって、画像１８がラスタ・スキャン順序に従って分配される、例えば、画像１８の間で規定される再現順序２０と必ずしも一致せず、および各画像１８ブロック内で妨害される、例えば、画像復号化順序に従ってビデオ１６の画像１８を妨害するサブポーション２４内で定められる復号化順序−あるいは符号化順序−に従うことができる。特に、エンコーダ１０は、例えば、予測および／またはエントロピー文脈を決定するように、予測符号化および／またはエントロピー符号化におけるそのような隣接部分を示す特性を用いるために符号化させるべき現在の部分に空間的および／または時間的に隣接する部分の有用性を決定するこの復号化順序に従うように構成される：単にビデオの前に訪れる（符号化／復号化）だけだった部分は利用可能である。さもなければ、ちょうど言及された特性はデフォルト値に設定され、または、いくつかの他の代替手段がとられる。

【0138】

一方では、エンコーダ１０は、復号化順序に沿って連続的にサブポーション２４を符号化する必要はない。むしろ、エンコーダ１０は符号化プロセスのスピードアップを図るため並行処理を行ったり、リアルタイムでより複合的な符号化を実行することが可能である。同様に、エンコーダ１０は、復号化順序に沿ってサブポーションを符号化しているデータを伝えるかまたは送るように構成されてもよいし、構成されなくてもよい。たとえば、エンコーダ１０は、サブポーションの符号化が、並列処理により、例えば、ちょうど言及される復号化順序から逸脱することができるエンコーダ１０によって終了する順序に従うような、いくつかの他の順序で符号化されたデータを出力／送信することができる。

【0139】

サブポーション２４の符号化されたバージョンをネットワーク上の伝送に適するようにするために、エンコーダ１０は、ビデオストリーム２２のパケットのシーケンスの１つ以上のペイロード・パケットに各サブポーション２４を符号化する。サブポーション２４がスライスである場合、エンコーダ１０は、例えば、各スライス・データ、例えば、各符号化データをＮＡＬユニットなどの１つのペイロード・パケットに置き換えるように構成される。このパケット化は、ネットワークを介してビデオ・データストリーム２２が伝送に適するようになるのに役立つことができる。したがって、パケットは、ビデオ・データストリーム２２が起こる、すなわち受取人に対するネットワークを経て伝送用のエンコーダ１０によって個々に送られる最も小型のユニットを表す。

【0140】

さらに、それらの間に分散するペイロード・パケットおよびタイミング制御パケットや、以下で述べる他のパケット、例えば、まれに変化する構文要素またはＥＯＦ（ファイルの終わり）またはＡＵＥ（アクセスユニット端）パケット等の伝達するためのフィルデータ・パケット、画像またはシーケンス・パラメータのような他のタイプのパケットが存在する。

【0141】

パケットのシーケンスがアクセスユニット３０のシーケンスに分けられ、各アクセスユニットがビデオ内容１６の１つの画像１８に関するペイロード・パケット３２を集めるように、エンコーダはペイロード・パケットへの符号化を実行する。すなわち、ビデオ・データストリーム２２を形成しているパケットのシーケンス３４は、それぞれが画像１８のそれぞれの１つに関連している、アクセスユニット３０と呼ばれる重なり合わない部分に再分割される。アクセスユニット３０のシーケンスは、アクセスユニット３０が関連する画像１８の復号化順序に従う。図１２は、例えば、図示されたデータストリーム２２の部分の中央に配置されるアクセスユニット３０が、画像１８が再分割されるサブポーション２４につき１つのペイロード・パケット３２を含む。すなわち、各ペイロード・パケット３２は、対応するサブポーション２４を担持する。エンコーダ１０は、パケットタイミング制御パケット３６のシーケンス３４に分散され、それによりタイミング制御パケットがアクセスユニット３０を復号化ユニット３８に細分割し、それにより図１２の中央部に示されているように、少なくともいくつかのアクセスユニット３０は２つ以上の復号化ユニット３８に細分割され、各タイミングコントロールパケットは、そのペイロード・パケット３２がパケットのシーケンス３４におけるそれぞれのタイミング制御パケットに続く復号化ユニット３８のためのデコーダバッファ検索時間に信号を送る。換言すれば、エンコーダ１０は、それぞれのタイミング制御パケット３６によって前に置かれ、復号化ユニット３８、デコーダバッファ検索時間を形成するペイロード・パケットのそれぞれのサブシーケンスのために信号を送るそれぞれのタイミング制御パケット３６で１つのアクセスユニット３０内のペイロード・パケット３２のシーケンスのサブシーケンスの前に置く。図１２は、例えば、あらゆる第２のパケット３２がアクセスユニット３０の復号化ユニット３８の第１のペイロード・パケットを表すケースを例示する。図１２に示すように、データの量または復号化ユニット３８ごとに費やされるビットレートは変化し、そして、復号化ユニット３８のデコーダバッファ検索時間がこの直ちに前の復号化ユニット３８に費やされるビットレートに対応する時間間隔に加えて直ちに前の復号化ユニット３８のタイミング制御パケット３６によって信号を送られるデコーダバッファ検索時間に続くことができるという点で、デコーダバッファ検索時間は復号化ユニット３８の中のこのビットレートのバリエーションと相関することができる。

【0142】

すなわち、エンコーダ１０は、図１３に示すように作動することができる。特に、上述したように、エンコーダ１０は、ステップ４０において、現在の画像１８の現在のサブポーション２４を符号化させることができる。すでに述べたように、エンコーダ１０は、矢印４２で示すように、上述の復号化順序のサブポーション２４によって順次循環することができ、または、エンコーダ１０は並行していくつかの「現在のサブポーション」２４を同時に符号化するためにＷＰＰおよび／またはタイル処理のようないくらかの並列処理を使用することができる。並列処理の使用の有無にかかわりなく、エンコーダ１０は、ステップ４０およびそれに続くステップ４４において符号化される１つまたはいくつかのサブポーションから復号化ユニットを形成し、エンコーダ１０は、デコーダバッファ検索時間をこの復号化ユニットに設定して伝送し、前に置かれたこの復号化ユニットは時間制御パケットで復号化ユニットのために設定された復号化バッファ検索時間の信号を送る。たとえば、エンコーダ１０は、もしあれば、この復号化ユニット内の全ての更なる中間パケット、すなわち「接頭辞パケット」を含む現在の復号化ユニットを形成するペイロード・パケットに符号化されたサブポーションを符号化するのに費やされるビットレートに基づいてステップ４４におけるデコーダバッファ検索時間を決定する。

【0143】

それから、ステップ４６において、エンコーダ１０は、ちょうど今ステップ４４において送信されていた復号化装置に費やされるビットレートに基づいて、利用できるビットレートを適応させることができる。例えば、ステップ４４においてちょうど送信される復号化ユニット内の画像内容が圧縮率に関して非常に複雑である場合、エンコーダ１０は、例えば、ビデオ・データストリーム２２を送信しているネットワークと関連して直面される現在の帯域幅状況に基づいて、決定されていたいくつかの外部的に設定された目標ビットレートに従うように、次の復号化ユニットのために利用できるビットレートを減らすことができる。ステップ４０〜４６は、それから繰り返される。この計測によって、画像１８は符号化されて送信される、すなわち、各々対応するタイミング制御パケットによって前に置かれた、復号化ユニットを単位にして送信される。

【0144】

換言すれば、エンコーダ１０は、ビデオ内容１６の現在の画像１８を符号化する間、現在の画像１８の現在のサブポーション２４を現在の復号化ユニット２８の現在のペイロード・パケット３２に符号化４０し、最初の瞬間、データストリームの中で、現在のタイミング制御パケット（３６）によって信号を送られるデコーダバッファ検索時間で現在のタイミング制御パケット３６で前に置かれる現在の復号化ユニット３８をデータストリーム内で伝送４４し、ステップ４６から４０に回帰することにより、第１の時間的瞬間−第１の時間訪問ステップ４４より遅い第２の時間的瞬間−第２の時間訪問ステップに現在の画像１８の更なるサブポーション２４を符号化４４する。

【0145】

エンコーダはこの復号化ユニットが属する現在の画像の残りの符号化に先立って復号化ユニットを伝送することができるので、エンコーダ１０は端子間遅延を少なくすることができる。一方では、エンコーダ１０が現在の画像の内容および複雑さのその空間分布の特定の性質に反応することが可能であるため、エンコーダ１０は利用できるビットレートを浪費する必要がない。

【0146】

一方において、更にエンコーダからデコーダにビデオ・データストリームの伝送に対して重要な中間ネットワークエンティティは、エンコーダ１０による復号化ユニット的な符号化および伝送の利益を得るように、ビデオ・データストリーム２２を受信するいくつかのデコーダが時間内に復号化ユニットを受信することを保証するように、タイミング制御パケット３６を使用することができる。たとえば、ビデオ・データストリーム２２を復号化するためのデコーダを示す図１４を参照されたい。デコーダ１２は、エンコーダ１０がデコーダ１２にビデオ・データストリーム２２を伝送したネットワークを経由して符号化画像バッファＣＰＢ４８でビデオ・データストリーム２２を受信する。特に、ネットワーク１４は低遅延アプリケーションをサポートすることができるものと見なされるため、ネットワーク１０はデコーダ１２の符号化画像バッファ４８にビデオ・データストリーム２２のパケットのシーケンス３４を送るようにデコーダバッファ検索時間を検査し、それにより、各復号化ユニットはそれぞれの復号化ユニットの前におかれるタイミング制御パケットによって信号を送られるデコーダバッファ検索時間に先立って符号化画像バッファ４８内に存在する。この計測によって、デコーダは、行き詰まることなく、すなわち、符号化画像バッファ４８内で利用できるペイロード・パケットが尽きることなく、完全なアクセスユニットよりむしろ復号化ユニットを単位にするデコーダの符号化ピクチャ・バッファ４８を空にするために、タイミング制御パケットのデコーダバッファ検索時間を使用する。図１４は、例えば、符号化画像バッファ４８の出力に接続され、その入力がビデオ・データストリーム２２を受信するような処理ユニット５０を例示的に示している。エンコーダ１０と同様に、デコーダ１２は、例えばタイル並列処理／復号化および／またはＷＰＰ並列処理／復号化を用いて並列処理を実行することができる。

【0147】

以下において詳述するように、デコーダバッファ検索時間は、デコーダ１２の符号化ピクチャ・バッファ４８に関する検索時間に必ずしも関連するというわけではない。むしろ、タイミング制御パケットは、加えて、あるいは、デコーダ１２の対応する復号化ピクチャ・バッファのすでに復号化された画像データの検索を進めることができる。図１４は、例えば、処理ユニット５０によりビデオ・データストリーム２２を復号化することによって得られるビデオ内容の復号化バージョンがバッファリングされる、したがって、復号化ユニットの復号化バージョンを単位にして格納され、出力されるデコーダピクチャバッファを含むデコーダ１２を示す。デコーダの復号化ピクチャ・バッファ２２は、このようにデコーダ１２の出力および処理ユニット５０の出力の間に接続される。復号化ピクチャ・バッファ５２からユニットを復号化する復号化バージョンを出力するための検索時間を設定する能力を有することによって、エンコーダ１０は、臨機応変に、すなわち、現在の画像を符号化する間、再現を制御し、または端末間で、画像率またはフレーム率より小さい粒度でさえ復号化側のビデオ内容の再現の遅延を得る機会を与えられる。明らかに、符号化側で各画像１８を大量のサブポーション２４に過度に分割することはビデオ・データストリーム２２を送信するためのビットレートに負の影響を及ぼすが、その一方で、このような復号化ユニットを符号化し、送信し、復号化し、出力するために必要な時間が最小化されるため、端末間の遅延は最小化されることができる。一方では、サブポーション２４のサイズを増加させることは、端末間の遅延を増加させる。したがって、妥協は見つけられなければならない。復号化ユニットを単位とするサブポーション２４の復号化バージョンの出力タイミングを誘導するように言及したデコーダバッファ検索時間を使用することは、エンコーダ１０または符号化側のいくつかの他のユニットに現在の画像の内容を空間的に超えてこの妥協を適用することを可能にする。この手段によって、それが現在の画像内容全体で空間的に変化させるそのような方法における端末間遅延を制御することは可能である。

【0148】

上述のような実施例を実行する際に、タイミング制御パケットとして、除去可能なパケット・タイプのパケットを使用することが可能である。除去可能なパケット・タイプのパケットは、復号側でビデオ内容を回復するために必要でない。以下に、この種のパケットは、ＳＥＩパケットと呼ばれている。さらに、除去可能なパケット・タイプのパケット、すなわち、ストリームにおいて伝送される場合に、冗長パケットのような別のタイプの除去可能なパケットが同様に存在する。他の方法として、タイミング制御パケットは特定の除去可能なパケット・タイプのパケットでもよいが、加えて、特定のＳＥＩパケット・タイプフィールドを担持する。たとえば、タイミング制御パケットは、１つまたはいくつかのＳＥＩメッセージを担持している各ＳＥＩパケットを有するＳＥＩパケットであり、特定のタイプのＳＥＩメッセージを含むこれらのＳＥＩパケットだけが前述のタイミング制御パケットを形成する。

【0149】

このように、図１２〜１４に関して今までに記載されている実施例は、更なる実施例に従って、ＨＥＶＣ基準に適用され、それによって、より低い端末間遅延においてより効果的なＨＥＶＣを提供するための可能なコンセプトを形成する。この際、上述したパケットはＮＡＬユニットによって形成され、そして、上述したペイロード・パケットは上述したサブポーションを形成するスライスを有するＮＡＬユニットストリームのＶＣＬ ＮＡＬユニットである。

【0150】

より詳細な実施例の説明の前に、分散されたパケットが効率的な方法でビデオ・データストリームを示している情報を伝送するために用いられるという点で上述の概説された実施例と一致する更なる実施例が示されるが、情報の分類が、タイミング制御パケットがデコーダバッファ検索タイミング情報に伝送された上述の実施例と異なる。さらに以下に記載されている実施例において、アクセスユニットに属しているペイロード・パケットに分散する分散パケットを介して移される情報の種類は、関心領域（ＲＯＩ）情報および／またはタイル識別情報に関する。さらに以下で記載される実施例は、図１２〜１４に関して記載されている実施例と結合されることができるかまたは結合されることができない。

【0151】

図１５は、図１５のエンコーダ１０に対してオプションとなる、図１３に関して上述されたタイミング制御パケットおよび機能の分散を除いて、図１２に関して上で説明したものに類似の動作をするエンコーダ１０を示す。しかしながら、図１５のエンコーダ１０は、図１１に関連して上で説明したように、ビデオ内容１６の画像１８のサブポーション２４を単位とするビデオ・データストリーム２２にビデオ内容１６を符号化するように構成される。ビデオ内容１６を符号化する際に、エンコーダ１０は、ビデオ・データストリーム２２とともに、復号化側に関心領域ＲＯＩ ６０に関する情報を伝達することに興味を持っている。ＲＯＩ ６０は、デコーダが、例えば、特別に注意を払わなければならない、現在の画像１８の空間サブエリアである。ＲＯＩ ６０の空間位置は、現在の画像１８の符号化の間、ユーザーの入力などのような、点線６２で示されるような外部からエンコーダ１０に入力することができ、または、エンコーダ１０または臨機応変にいくつかの他の存在により自動的に決定されることができる。いずれにせよ、エンコーダ１０は、以下の課題に直面する：ＲＯＩ ６０の位置の表示は、原則としてエンコーダ１０にとって問題ではない。そのために、エンコーダ１０は、データストリーム２２の中でＲＯＩ ６０の位置を容易に示すことができる。しかしながら、容易にアクセスできるこの情報を示すために、図１５のエンコーダ１０はアクセスユニットのペイロード・パケットの間にＲＯＩパケットの分散を使用し、それにより、エンコーダ１０は、サブポーション２４および／またはサブポーション２４がパケット化され、ＲＯＩ ６０の空間的に外側および空間的に内側にあるペイロード・パケットの数に自由に、継続的に、現在の画像１８の区分を選択する。分散型のＲＯＩパケットを用いて、いかなるネットワークエンティティも、ＲＯＩに属するペイロード・パケットを容易に確認することができる。一方では、これらのＲＯＩパケットのための除去可能なパケット・タイプを使用する場合、それはいかなるネットワークエンティティによっても容易に無視されることができる。

【0152】

図１５は、アクセスユニット３０のペイロード・パケット３２の間にＲＯＩパケット６４を分散させるための実施例を示す。ＲＯＩパケット６４は、ビデオ・データストリーム２２内でＲＯＩ ６０に関連する、すなわち符号化する符号化データが含まれるところを示す。ＲＯＩパケット６４がＲＯＩ ６０の位置を示す方法は、多種多様な方法で行うことができる。たとえば、ＲＯＩパケット６４の純粋な存在／発生は、シーケンス３４の順次的な順序において続く、すなわち前に置かれたペイロード・パケットに属する、以下のペイロード・パケット３２の１つ以上の範囲内でＲＯＩ ６０に関する符号化データの編入を示す。あるいは、ＲＯＩパケット６４内部の構文要素は、１つ以上の次のペイロード・パケット３２がＲＯＩ ６０に関連するかどうか、すなわち少なくとも部分的に符号化するかどうかを示す。変化の多さも、それぞれのＲＯＩパケット６４の「スコープ」に関して可能なバリエーション、すなわち１つのＲＯＩパケット６４によって前に置かれる前に置かれたペイロード・パケットの数から生じる。たとえば、１つのＲＯＩパケット内でＲＯＩ ６０に関するいくらか符号化データの編入または非編入の示唆は、次のＲＯＩパケット６４の発生までシーケンス３４の順次的な順序に続き、または、単にすぐに続くペイロード・パケット３２、すなわちシーケンス３４の順次的な順序におけるそれぞれのＲＯＩパケット６４に続くペイロード・パケット３２に関連する。図１５において、グラフ６６は見本として、次のＲＯＩパケット６４の発生までそれぞれのＲＯＩパケット６４のダウンストリームを発生させる全てのペイロード・パケット３２、またはパケットのシーケンス３４に沿って早く発生するものは何でも現在のアクセスユニット３０の終わりと関連して、ＲＯＩパケット６４がＲＯＩの関連、すなわちＲＯＩ ６０に関するいかなる符号化されたデータの編入、またはＲＯＩの非関連、すなわちＲＯＩ ６０に関連するいかなる符号化データの欠如を示すケースを例示する。特に、図１５はＲＯＩパケット６４が構文要素を中で備えているケースを例示し、それはいずれにせよパケット・シーケンス３４の順次的な順序において続いているペイロード・パケット３２が中のＲＯＩ ６０に関する符号化されたデータを有するか否かを示す。このような実施例も、以下に記載する。しかしながら、他の可能性は、今述べたように、各ＲＯＩパケット６４が、それぞれのＲＯＩパケット６４の「スコープ」に属するペイロード・パケット３２がデータ内部に関連するＲＯＩ６０、すなわちＲＯＩ６０に関連するデータを有しているパケット・シーケンス３４に存在することにより示すことである。更に詳細に以下に記載する実施例によれば、ＲＯＩパケット６４は、その「スコープ」に属しているペイロード・パケット３２に符号化されるＲＯＩ ６０の部分の位置さえ示す。

【0153】

たとえば、パケットのシーケンス３４のＲＯＩ関連部分をパケット・シーケンス３４の他の部分より高い優先度で扱うためにＲＯＩパケット６４を用いて理解されるように、ビデオ・データストリーム２２を受信しているいかなるネットワークエンティティ６８もＲＯＩ関連の指し示すことを利用することができる。あるいは、ネットワークエンティティ６８は、例えば、ビデオ・データストリーム２２の伝送に関する他の作業を遂行するために、ＲＯＩ関連情報を使用することができる。ネットワークエンティティ６８は、例えば、ビデオ・データストリーム２２、２８を介して伝送されるようなビデオ内容６０の復号化および再生のためのＭＡＮＥまたはデコーダである。換言すれば、ネットワークの素材６８は、ビデオ・データストリームに関連している伝送作業を決定するために、ＲＯＩパケットの識別の結果を使用することができる。伝送作業は、欠陥パケットに関して再伝送要請を含むことができる。ネットワークエンティティ６８は、増加した優先度を有する関心領域７０を扱って、より高い優先権をＲＯＩパケット７２およびそれらの付随するペイロード・パケット、すなわちそれによって前に置かれるものに割り当てるように構成されることができ、それは、ＲＯＩを覆わないように信号を送られるＲＯＩパケットおよびそれらの付随するペイロード・パケットと比較して、関心領域を覆うように信号を送られる。それに対して割り当てられる下の優先度を有するペイロード・パケットのいくつかの転送を要請する前に、ネットワークエンティティ６８は、それに対して割り当てられるより高い優先度を有するペイロード・パケットの転送を最初に要請することができる。

【0154】

図１５の実施例は、図１２〜１４に関して以前に記載されている実施例と、容易に結合されることができる。たとえば、上述のＲＯＩパケット６４は、そこにおいて、含まれる特定のタイプのＳＥＩメッセージ、すなわちＲＯＩ ＳＥＩメッセージを有するＳＥＩパケットであってもよい。すなわち、ＳＥＩパケットは、例えば、タイミング制御パケットおよび同時にＲＯＩパケットであってもよく、すなわち、それぞれのＳＥＩパケットが両方のタイミングから成る場合、ＲＯＩ表示情報と同様に情報を制御する。あるいは、ＳＥＩパケットは、他の１つであるよりもむしろ、タイミング制御パケットおよびＲＯＩパケットのうちの１つでもよく、ＲＯＩパケットかタイミング制御パケットでなくてもよい。

【0155】

図１６において図示した実施例に従って、アクセスユニットのペイロード・パケット間へのパケットの分散は、現在のアクセスユニット３０が関連している、現在の画像１８のタイルである、ビデオ・データストリーム２２を取り扱うネットワークエンティティ６８に容易にアクセスできる方法で示すように用いられ、それぞれのパケットが接頭辞として役立つペイロード・パケット３２のいくつかに符号化されるいくつかのサブポーションによって覆われる。図１６において、例えば、見本としてここでは現在の画像１８の４つの四半部によって形成されて、現在の画像１８は４つのタイル７０に再分割されることを示す。また、例えば、パケットのシーケンス３４に分散されるＶＰＳまたはＳＰＳパケットで、タイル７０への現在の画像１８の細別は、例えば、画像のシーケンスから成るユニットのビデオ・データストリームの中で信号を送られることができる。以下において更に詳細に説明するように、現在の画像１８のタイル再分割はタイルの列および行における画像１８の規則的な再分割でもよい。タイルの列の幅および行の高さと同様に列の数および行の数は変化していてもよい。特に、タイルの列／行の幅と高さは、異なる行および異なる列でそれぞれ異なっていてもよい。図１６は、加えて、サブポーション２４が画像１８のスライスである実施例を示す。スライス２４は、画像１８を再分割する。以下において更に詳細に概説されるように、スライス２４への画像の１８の再分割は、各スライス２４が１つのタイル７０の範囲内に完全に含まれることができるか、または完全に２つ以上のタイル７０をカバーすることができるという制約に従属される。図１６は、画像１８が５つのスライス２４に再分割されるケースを例示する。上述した復号化順序におけるこれらの最初の４つのスライス２４は最初の２つのタイル７０をカバーするが、その一方で、５番目のスライスは完全に第３および第４のタイル７０をカバーする。さらに、図１６は、各スライス２４がそれぞれのペイロード・パケット３２に個々に符号化されるケースを例示する。さらに、図１６は、見本として、各ペイロード・パケット３２が先行するタイル識別パケット７２によって前に置かれるケースを例示する。各タイル識別パケット７２は、次に、このペイロード・パケット３２に符号化されるサブポーション２４がタイル７０のいずれを覆うかについてその直ちに続くペイロード・パケット３２のために指示する。したがって、現在の画像１８に関するアクセスユニット３０の範囲内の最初の２つのタイル識別パケット７２が第１のタイルを示すと共に、第３および第４のタイル識別パケット７２は画像１８の第２のタイル７０を示し、第５のタイル識別パケット７２は第３および第４のタイル７０を示す。図１６の実施例に関して、例えば、同じバリエーションは、図１５に関して上述したように可能である。すなわち、タイル識別パケット７２の「スコープ」は、例えば、単に次のタイル識別パケットの発生まで、第１の直ちに続くペイロード・パケット３２または直ちに続くペイロード・パケット３２を含むことができるだけである。

【0156】

タイルに関して、タイル境界全体に、空間予測または前後関係選択が起こらないように、エンコーダ１０は各タイル７０を符号化するように構成されることができる。エンコーダ１０は、例えば、並行してタイル７０を符号化することができる。同様に、ネットワークエンティティ６８のようないかなるデコーダも、並行してタイル７０を復号化することができる。

【0157】

ネットワークエンティティ６８はエンコーダ１０およびデコーダとの間におけるＭＡＮＥまたはデコーダまたはいくつかの他の装置でもよく、特定の伝送作業を決定するためにタイル識別パケット７２によって伝達される情報を使用するように構成することができる。たとえば、ネットワークエンティティ６８は、より高い優先度でビデオ１６の現在の画像１８の特定のタイルを扱うことができ、すなわち以前にこのようなタイルに関するかまたはより安全なＦＥＣ保護等を使用するとして示されるそれぞれのペイロード・パケットを進めることができる。換言すれば、ネットワークエンティティ６８は、ビデオ・データストリームに関係している伝送作業を決定するために、識別の結果を使用することができる。伝送作業は欠陥状態において−すなわち、もしあれば、ビデオのいかなるＦＥＣ保護も上回ることで、受け取られるパケットに関して再伝送要請を含むことができる。ネットワークエンティティは、例えば、異なる優先度で異なるタイル７０を扱うことができる。この目的で、ネットワークエンティティは識別パケット７２よびそれらのペイロード・パケット７２により高い優先度を割り当てることができる、すなわち、低い優先度に関連するタイル識別パケット７２およびそれらのペイロード・パケットよりも、前に置かれそれにより高い優先度に関連する。それに対して割り当てられる低い優先度を有するペイロード・パケットのいかなる転送を要請する前に、ネットワークエンティティ６８は、例えば、それに対して割り当てられるより高い優先度を有するペイロード・パケットの転送を最初に要請することができる。

【0158】

今までに記載されている実施例は、以下に説明するように、本出願の前置き部分にて説明したようなＨＥＶＣフレームワークに組み込まれることができる。

【0159】

特に、ＳＥＩメッセージは、サブピクチャＣＰＢ／ＨＲＤケースの復号化ユニットのスライスに割り当てられることができる。すなわち、バッファリング期間およびタイミングＳＥＩメッセージは、復号化ユニットのスライスを含んでいるＮＡＬユニットに割り当てられることができる。これは、直接復号化装置の１つ以上のスライス／ＶＣＬ ＮＡＬユニットに先行することができる非ＶＣＬ ＮＡＬユニットである新しいＮＡＬユニットタイプによって達成されることができる。この新規なＮＡＬユニットは、スライス接頭辞ＮＡＬユニットと呼ばれることができる。図１７は、シーケンスおよびストリームの端部のためのいかなる一時的なＮＡＬユニットも省略したアクセスユニットの構造を例示する。

【0160】

図１７によれば、アクセスユニット３０は、以下の通りに構成される：パケットのシーケンス３４のパケットの順次的な順序で、アクセスユニット３０は、特別なタイプのパケット、すなわち、アクセスユニットデリミタ８０の発生から始めることができる。それから、全てのアクセスユニットに関するＳＥＩパケット・タイプの１つ以上のＳＥＩパケット８２は、アクセスユニット３０内で続くことができる。両方のパケット・タイプ８０および８２は、任意である。すなわち、このタイプのパケットは、アクセスユニット３０内で発生することができない。それから、復号化ユニット３８のシーケンスは続く。各復号化ユニット３８は、例えばタイミング制御情報を含み、または図１５または１６の実施例によれば、ＲＯＩ情報またはタイル情報または、より一般的には、それぞれのサブピクチャＳＥＩメッセージ８６を含む、スライス接頭辞ＮＡＬユニット８４で任意に始まる。それから、それぞれのペイロード・パケットまたはＶＣＬ ＮＡＬユニットの実際のスライス・データ８８は、８８に示すように続く。このように、各復号化ユニット３８は、それぞれのスライス・データＮＡＬユニット８８が続くスライス接頭辞ＮＡＬユニット８４のシーケンスを含む。スライス接頭辞ＮＡＬユニットを回避する図１７のバイパス矢印９０は、現在のアクセスユニット３０の非復号化ユニット再分割の場合には、スライス接頭辞ＮＡＬユニット８４がないことを示す。

【0161】

すでに上述したように、スライス接頭辞で信号を送ったすべての情報および付随するサブピクチャＳＥＩメッセージは、スライス接頭辞ＮＡＬユニットにおいて伝えられるフラグに応じて、アクセスユニットの、または、第２の接頭辞ＮＡＬユニットの発生までのすべてのＶＣＬ ＮＡＬユニットのために、または、復号化順序において以下のＶＣＬ−ＮＡＬユニットのために効果的であってもよい。

【0162】

スライス接頭辞で信号を送られる情報が有効であるスライスＶＣＬ ＮＡＬユニットは、以下において接頭辞スライスと呼ばれる。前に置かれる単一のスライスと関連する接頭辞スライスは、完全な復号化ユニットを必ずしも構成する必要はないが、それの一部であり得る。しかしながら、単一のスライス接頭辞は並列の復号化ユニット（サブピクチャ）に有効であることができず、復号化ユニットの始まりはスライス接頭辞で信号を送られる。信号を送るための手段がスライス接頭辞構文（以下に示す「単純な構文」／バージョンのような）によって与えられない場合、スライス接頭辞ＮＡＬユニットの発生は復号化ユニットの始まりの信号を送る。特定のＳＥＩメッセージ（以下の構文説明のペイロードタイプを介して確認される）だけはスライス接頭辞ＮＡＬユニットの範囲内でサブピクチャ・レベルで送られることができ、その一方で、いくらかのＳＥＩメッセージはサブピクチャ・レベルでスライス接頭辞ＮＡＬユニットにおいて、または、アクセスユニットレベルで通常のＳＥＩメッセージとして送られることができる。

【0163】

図１６に関して上述したように、さらに、または、あるいは、タイルＩＤ ＳＥＩメッセージ／タイルＩＤシグナリングは、高水準構文において理解されることができる。ＨＥＶＣの以前のデザインにおいて、スライス・ヘッダ／スライス・データは、それぞれのスライスに含まれるタイルのための識別子を含んだ。例えば、スライス・データ意味論は示す：

【0164】

ｔｉｌｅ＿ｉｄｘ＿ｍｉｎｕｓ＿１は、ラスタ・スキャン順序のＴｉｌｅＩＤを規定する。画像の第１のタイルは、０のＴｉｌｅＩＤを有する。ｔｉｌｅ＿ｉｄｘ＿ｍｉｎｕｓ＿１の値は、０から（ｎｕｍ＿ｔｉｌｅ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１＋１）＊（ｎｕｍ＿ｔｉｌｅ＿ｒｏｗｓ＿ｍｉｎｕｓ１＋１）−１の範囲内にある。

【0165】

ｔｉｌｅｓ＿ｏｒ＿ｅｎｔｒｏｐｙ＿ｃｏｄｉｎｇ＿ｓｙｎｃ＿ｉｄｃが１に等しい場合、このＩＤがスライスアドレスから、および画像パラメータ・セットにおいて信号を送られるようなスライスディメンジョンから容易に引き出されるため、このパラメータは役立つとは認められない。

【0166】

タイルＩＤが暗に復号化プロセスの中で引き出されることができるにもかかわらず、異なるタイルがプレイバックに対して異なる優先度を有する（これらのタイルが典型的には会話形式を用いる話者を含む関心領域を形成する）ビデオ会議シナリオが別のタイルより高い優先度をもっているように、アプリケーションレイヤーにおけるこのパラメータの知識は異なる使用の場合に重要である。複数のタイルの伝送のネットワーク・パケットを失う場合には、関心領域を表しているタイルを含んでいるそれらのネットワーク・パケットは、いかなる優先度順序もない再送信タイルの場合よりも高いレシーバ端末に経験品質を保つために、より高い優先度で再送信されることができる。寸法およびそれらの位置が公知である場合、例えばテレビ会議シナリオのように、異なるスクリーンに、他の使用ケースはタイルを割り当てることができる。

【0167】

このようなアプリケーションレイヤーが伝送シナリオにおいて特定の優先度を有するタイルを扱うことができるために、ｔｉｌｅ＿ｉｄは、サブピクチャまたはスライスに特有のＳＥＩメッセージとして、または、タイルの１つ以上のＮＡＬユニットの前の特別なＮＡＬユニットにおいて、または、タイルに属しているＮＡＬユニットの特別なヘッダ部分において設けられることができる。

【0168】

図１５に関して上述したように、関心ＳＥＩメッセージの領域は、さらに、または、代わりに設けられていることもできる。このようなＳＥＩメッセージは、関心領域（ＲＯＩ）の信号を送ることを可能にし、特に、特定のｔｉｌｅ＿ｉｄ／タイルが属するＲＯＩのシグナリングにおいて感心領域（ＲＯＩ）のシグナリングを可能にすることができる。メッセージは、関心領域ＩＤに加えて関心領域の優先度を与えることを可能にすることができる。

【0169】

図１８は、関心領域シグナリングのタイルの使用を例示する。

【0170】

上で記載されていたことに加えて、スライス・ヘッダ・シグナリングが実行されることができる。スライス接頭辞ＮＡＬユニットは、以下の従属するスライス、すなわち、それぞれのスライス接頭辞によって前に置かれるスライスのためのスライス・ヘッダを含むこともできる。スライス・ヘッダがスライス接頭辞ＮＡＬユニットにおいて提供されるだけである場合、それぞれの従属するスライスを含んでいるＮＡＬユニットのＮＡＬユニットタイプによって、または次のスライス・データがランダムアクセスポイントとして働くスライスタイプに属するかどうかの信号を送るスライス接頭辞におけるフラグによって、実際のスライスタイプが引き出される。

【0171】

さらに、スライス接頭辞ＮＡＬユニットは、例えばサブピクチャ・タイミングまたはタイル識別子のような任意の情報を伝達するために、スライスまたはサブピクチャに特定のＳＥＩメッセージを持たせることができる。任意のサブピクチャの特定のメッセージ発信は、本出願の紹介の部分に記載されているＨＥＶＣの明細書においてサポートされていないが、特定のアプリケーションのために重要である。

【0172】

次に、スライスの接頭辞付加の上述の概念を実行するための可能な構文が説明される。特に、基本として本出願の明細書の紹介部分で概説されるＨＥＶＣ状況を使用するときに、どの変化がスライス・レベルに十分でありえるかが説明される。

【0173】

特に、以下において、可能なスライス接頭辞構文の２つのバージョンが与えられ、１つはＳＥＩメッセージ発信だけの機能をもつものであり、１つは次のスライスのためにスライス・ヘッダの一部の信号を送る拡張した機能をもつものである。第１の単純な構文／バージョン１は、図１９に示される。

【0174】

予備的な注釈として、図１９は、このように、図１１〜１６に関して上記の実施例のいずれかを実行するためのありうる実行を示す。その中で示される分散型のパケットは図１９に示すように解釈されることができ、以下にいて、これは特定の実施例によって更に詳細に記載されている。

【0175】

ＳＥＩメッセージ概念から離れたｔｉｌｅ＿ｉｄシグナリング、復号化ユニットスタート識別子、スライス接頭辞ＩＤおよびスライス・ヘッダデータを含む拡張した構文／バージョン２は、図２０の表において与えられる。

【0176】

意味論は、以下の通りに定められることができる：
１の値を有するｒａｐ＿ｆｌａｇは、スライス接頭辞を含むアクセスユニットがＲＡＰ画像であることを示す。０の値を有するｒａｐ＿ｆｌａｇはスライス接頭辞を含まないアクセスユニットがＲＡＰ画像でないことを示す。

【0177】

ｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｆｌａｇは、アクセスユニットの範囲内で復号化ユニットの始まりを示し、したがって、次にくるスライスは、アクセスユニットの終端まで、または同じ復号化ユニットに属する他の復号化ユニットの始まりまで続く。

【0178】

０の値を有するｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇは、接頭辞スライスＮＡＬユニットおよび付随するサブピクチャＳＥＩメッセージの範囲内で与えられる情報が次のアクセスユニット、他のスライス接頭辞の発生または他の完全なスライス・ヘッダの始まりまですべての以下のＶＣＬ−ＮＡＬユニットにあてはまることを示す。値１を有するｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇは、スライス接頭辞ＮＡＬユニットおよび付随するサブピクチャＳＥＩメッセージに示されるすべての情報が順序を復号化する際の次のＶＣＬ―ＮＡＬユニットのためにだけ有効なことを示す。

【0179】

ｔｉｌｅ＿ｉｄｃは、以下のスライスに存在するタイルの量を示す。０に等しいｔｉｌｅ＿ｉｄｃは、タイルが以下のスライスにおいて用いられないことを示す。１に等しいｔｉｌｅ＿ｉｄｃは、単一のタイルが以下のスライスにおいて用いられることを示し、したがってそのタイル識別子は信号を送られる。２の値を有するｔｉｌｅ＿ｉｄｃは、複数のタイルが以下のスライスの範囲内で用いられることを示し、したがって、タイルの数および第１のタイル識別子は信号を送られる。

【0180】

ｐｒｅｆｉｘ＿ｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、復号化順序において続くスライスに対応するスライス・ヘッダのデータが与えられたスライス接頭辞で信号を送られることを示す。

【0181】

ｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ（）は、テキストの後期に定められる。それは関連したスライス・ヘッダ情報を含み、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが１に等しく設定された場合、それはスライス・ヘッダによってカバーされない。

【0182】

スライス・ヘッダおよび実際のスライス・データを切り離すことがヘッダおよびスライス・データのより柔軟な伝送方式を可能にすることに注意されたい。

【0183】

ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｍｉｎｕｓ１は、１なしで次の復号化ユニットマイナス１において使用されるタイルの数を示す。

【0184】

ｆｉｒｓｔ＿ｔｉｌｅ＿ｉｄ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓは、次の復号化ユニットにおける第１のタイルのタイル識別子を示す。

【0185】

スライス接頭辞の単純な構文／バージョン１のために、ないときには、以下の構文要素は、以下の通りにデフォルト値に設定されることができる：
−ｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔは１に等しい、すなわち、スライス接頭辞は、常に復号化ニットのスタートを示す。
−ｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇは０に等しい、すなわち、スライス接頭辞は、復号化ユニットのすべてのスライスにあてはまる。

【0186】

スライス接頭辞ＮＡＬユニットは、２４のＮＡＬユニットタイプを有し、ＮＡＬユニットは図２１に従って延長されるテーブルを概観する。

【0187】

すなわち、簡単に図１９〜２１を要約すると、ここで見られる構文の詳細は、特定のパケット・タイプが上記の確認された分散型のパケットに起因している、ここでは見本としてＮＡＬユニットタイプ２４を公開する。さらに、特に、図２０の構文例は、分散型のパケットの「スコープ」、これらの分散型のパケット自身の範囲内でそれぞれの構文要素によって制御されるスイッチングメカニズム、ここではｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇがこのスコープを制御するために用いられること、すなわち、それぞれ、このスコープの定義のための異なる選択肢の間のスイッチングをすることの上述の選択肢が明らかにされる。さらに、それぞれの分散型のパケットの分散型のパケットの「スコープ」に属しているパケットに含まれるスライス２４のための共通のスライス・ヘッダデータを含むという点で、図１〜１６の上述した実施例が延長されることができることが明らかにされた。すなわち、共通のスライス・ヘッダデータがそれぞれの分散型のパケットの範囲内で含まれるかどうかを示すこれらの分散型のパケットの範囲内でそれぞれのフラグによって制御される機構があることができる。

【0188】

もちろん、ＨＥＶＣの現在バージョンにおいて特定されるように、スライス・ヘッダデータのどの一部がスライス・ヘッダ接頭辞に移されるかについてちょうど提示される概念がスライス・ヘッダに変化を必要とする。図２２の表は、このようなスライス・ヘッダのための可能な構文を示し、現在のバージョンに従ってスライス・ヘッダに存在する確かな構文要素がｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ（）と呼ばれる下の階層にシフトされる。スライス・ヘッダおよびスライス・ヘッダデータのこの構文は、拡張したスライス・ヘッダ接頭辞ＮＡＬユニット概念が使われるオプションに適用されるだけである。

【0189】

図２２において、ｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは、現在のスライスのためのスライス・ヘッダデータがアクセスユニット、すなわち最も最近発生しているスライス接頭辞ＮＡＬユニットの最後のスライス接頭辞ＮＡＬユニットにおいて信号を送られる値から予測されることを示す。

【0190】

スライス・ヘッダから離れたすべての構文要素は、図２３の表において与えられるように、構文要素スライス・ヘッダデータによって信号を送られる。

【0191】

すなわち、図２２および図２３の概念を図１２〜１６の実施例に移転して、その中で記載されている分散型のパケットは、これらの分散型のパケットに組み込む概念、ペイロード・パケットに符号化されるスライスのスライス・ヘッダ構文の一部（サブポーション）２４、すなわちＶＣＬ ＮＡＬユニットによって延長されることができる。編入は、任意でもよい。すなわち、分散型のパケットのそれぞれの構文要素は、このようなスライス・ヘッダ構文がそれぞれの分散型のパケットに含まれるかどうか示すことができる。組み込まれる場合、それぞれの分散型のパケットに組み込まれるそれぞれのスライス・ヘッダデータはそれぞれの分散型のパケットの「スコープ」に属しているパケットに含まれるすべてのスライスに適用されることができる。分散型のパケットに含まれるスライス・ヘッダデータがこの分散型のパケットのスコープに属するペイロード・パケットのいずれかに符号化されるスライスによって採用されるかどうかは、例えば図２２のｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ＿ｐｒｅｓｅｎｔ＿ｆｌａｇによって信号を送られることができる。この計測によって、それぞれの分散型のパケットの「スコープ」に属しているパケットに符号化されるスライスのスライス・ヘッダが小型化され、したがって、スライス内のちょうど言及したフラグを用いて、上述の図１２〜１６に見られるネットワークエンティティのようなスライス・ヘッダおよびビデオ・データストリームを受信するいずれかのデコーダは、スライスのスライス・ヘッダ内のちょうど言及したフラグに応答し、分散型のパケットに組み込まれたスライス・ヘッダデータを、スライス接頭辞へのスライス・ヘッダデータの移動の信号を送るスライスの範囲内のそれぞれのフラグ、すなわちそれぞれの分散型のパケットの場合、この分散型のパケットのスコープに属するペイロード・パケットに符号化されるスライスのスライス・ヘッダにコピーするようにしている。

【0192】

さらに、図１２〜１６の実施例を実施するための構文例を続行して、ＳＥＩメッセージ構文が、図２４に示すようにすることができる。スライスまたはサブピクチャＳＥＩメッセージタイプを導入するために、ＳＥＩペイロード構文は図２５の表に示されるように構成されることができる。１８０〜１８４の範囲のｐａｙｌｏａｄＴｙｐｅを有するＳＥＩメッセージだけは、スライス接頭辞ＮＡＬユニットの範囲内で、サブピクチャ・レベルだけ独占的に送られることができる。さらに、１４０に等しいｐａｙｌｏａｄＴｙｐｅを有する関心領域ＳＥＩメッセージは、サブピクチャ・レベル上のスライス接頭辞ＮＡＬユニットまたはアクセスユニットレベル上の定期的なＳＥＩメッセージのどちらでも送信されることができる。

【0193】

すなわち、図１２〜１６に関して上述された実施例上に図２５および２４に示される詳細を移す中で、図１２〜１６のこれらの実施例に示される分散型のパケットは、スライス接頭辞ＮＡＬユニットの範囲内で、例えば、各ＳＥＩメッセージの始めにｐａｙｌｏａｄＴｙｐｅによって信号が送られる特定のタイプのＳＥＩメッセージを含む特定のＮＡＬユニットタイプ、例えば２４、を有するスライス接頭辞ＮＡＬユニットを用いて実現されることができる。現在記載されている特定の構文例において、ｐａｙｌｏａｄＴｙｐｅ＝１８０およびｐａｙｌｏａｄＴｙｐｅ＝１８１は図１１〜１４の実施例に従うタイミング制御パケットという結果になり、その一方で、ｐａｙｌｏａｄＴｙｐｅ＝１４０は図１５の実施例に従うＲＯＩパケットという結果になり、ｐａｙｌｏａｄＴｙｐｅ＝１８２は図１６の実施例に従うタイル識別パケットという結果になる。以下において本願明細書に記載されている特定の構文例は、１つのまたはちょうど言及されたｐａｙｌｏａｄＴｙｐｅオプションのサブセットを含むことができる。これを越えて、図２５は、図１１〜１６の上述の実施例のいずれかが各々と結合されることができることを明らかにする。さらに、図２５は図１２〜１６の実施例またはそれらの組み合わせも分散型のパケットによって延長されることができることを明らかにし、その後、ｐａｙｌｏａｄＴｙｐｅ＝１８４によって説明される。すでに上述したように、ｐａｙｌｏａｄＴｙｐｅ＝１８３に関して後述する拡張はいかなる分散型のパケットもそのスコープに属しているいかなるペイロード・パケットにも符号化されるスライスのスライス・ヘッダのための共通のスライス・ヘッダデータを組み込むことができたという可能性において終わる。

【0194】

以下の表は、スライスまたはサブピクチャ・レベルに使われることができるＳＥＩメッセージを定める。サブピクチャおよびアクセスユニットレベルに使われることができる関心のあるＳＥＩメッセージの領域も示される。

【0195】

ＮＡＬユニットタイプ２４のスライス接頭辞ＮＡＬユニットが、そこに含まれるＳＥＩメッセージタイプ１８０を有するときはいつでも、図２６は、例えば、発生しているサブピクチャ・バッファＳＥＩメッセージのための実施例を示し、このように、タイミング制御パケットを形成する。

【0196】

意味論は、以下の通りに定められることができる：
ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、シーケンスＨＲＤ属性を含むシーケンス・パラメータ・セットを特定する。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は、バッファリングピリオドＳＥＩメッセージと関連した主要な符号化画像によって参照されてセットされる画像パラメータのｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値に等しい。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの値は範囲は０から３１においてあり、次を含んでいる。

【0197】

ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］
そして、ｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］は、復号化ユニット（サブピクチャ）のＳｃｈｅｄＳｅｌＩｄｘ―ｔｈ ＣＰＢのための最初のＣＰＢ除去遅延を特定する。構文要素は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられるビットの長さを有し、９０ｋＨｚクロックを単位にする。構文要素の値は、０ではなく、９００００＊（ＣｐｂＳｉｚｅ［ＳｃｈｅｄＳｅｌＩｄｘ］÷ＢｉｔＲａｔｅ［ＳｃｈｅｄＳｅｌＩｄｘ］）、９０ｋＨｚクロックユニットのＣＰＢサイズの時間相当を上回らない。

【0198】

全ての符号化ビデオ・シーケンスの上に、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］の合計および復号化ユニット（サブピクチャ）につきｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］はＳｃｈｅｄＳｅｌＩｄｘの値ごとに一定であり、そして、ｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ＳｃｈｅｄＳｅｌＩｄｘ］およびｉｎｉｔｉａｌ＿ａｌｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ＳｃｈｅｄＳｅｌＩｄｘ］の合計はＳｃｈｅｄＳｅｌＩｄｘの値ごとに一定である。

【0199】

図２７は、同様にサブピクチャ・タイミングＳＥＩメッセージのための例を示し、意味論は、以下の通りに記載されることができる：

【0200】

もしあるならば、同じ復号化ユニット（サブピクチャ）における先行するアクセスユニットの最近のサブピクチャ・バッファリングピリオドＳＥＩメッセージと関連し、さもなければ、サブピクチャ・タイミングＳＥＩメッセージと関連する復号化ユニット（サブピクチャ）データをバッファから除去する前に、先行するアクセスユニットにおける最近のバッファリングピリオドＳＥＩメッセージと関連する復号化ユニット（サブピクチャ）のＣＰＢからの除去の後、どれくらいのクロックが待つために刻んだかを特定する。この値は、ＨＳＳ（仮定的なＳｔｒｅａｍ Ｓｃｈｅｄｕｌｅｒ［２］０）のためのＣＰＢへの復号化ユニット（サブピクチャ）データの到着の最も早い可能な時間を計算するためにも用いる。構文要素は、ビットの長さがｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられる固定長符号である。ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙは、逆にｍｏｄｕｌｏ２(cpb＿removal＿delay＿length＿minus1+1)カウンタの剰余である。

【0201】

ｄｕ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙは、復号化ユニット（サブピクチャ）のＤＰＢ出力時間を計算するために用いられる。それは、画像の復号化ユニット（サブピクチャ）がＤＰＢから出力される前にＣＰＢから復号化された復号化ユニット（サブピクチャ）の除去の後、どれくらいのクロックが待つために刻むかについて特定する。

【0202】

これがサブピクチャのアップデートを可能にすることに注意されたい。このようなシナリオにおいて、アップデートしていない復号化ユニットは、最後の復号化画像の中で不変のままであり、それらは、見えるままである。

【0203】

図２６および２７を要約して、そこに含まれる具体的な詳細を図１２〜１４の実施例に転移すると、復号化ユニットのためのデコーダバッファ検索時間が、すなわち付加的に復号化バッファ検索時間と関連して、差別的に符号化方法の関連するタイミング制御パケットにおいて信号を送られることができるということができる。すなわち、特定の復号化ユニットのための復号器バッファ検索時間を得るために、ビデオ・データストリームを受信するデコーダは、特定の復号化ユニットの前に置かれるタイミング制御パケットから得られるデコーダ検索時間を直ちに先行する復号化ユニットのデコーダ検索時間、すなわち特定の復号化ユニットに先行するものおよび復号化ユニットが続くようなこの方法の手続に加える。各々いくつかの画像またはそのパーツの符号化ビデオ・シーケンスの始まりで、タイミング制御パケットは、さらに、または、代わりに、先行する復号化ユニットのデコーダバッファ検索時間と差別的に比べたよりも完全に符号化されたデコーダバッファ検索時間を含む。

【0204】

図２８は、サブピクチャスライス情報ＳＥＩメッセージがどのように見えるかを示す。意味論は、以下の通りに定められることができる：

【0205】

１の値を有するｓｌｉｃｅ＿ｈｅａｄｅｒ＿ｄａｔａ＿ｆｌａｇは、スライス・ヘッダデータがＳＥＩメッセージに存在することを示す。ＳＥＩにおいて与えられているスライス・ヘッダデータは、アクセス装置、他のＳＥＩメッセージのスライス・データの発生、スライスＮＡＬ装置またはスライス接頭辞ＮＡＬ装置の端まで復号化順序を受け継ぐすべてのスライスに有効である。

【0206】

図２９は、サブピクチャ・タイル情報ＳＥＩメッセージのための実施例を示す、意味論は、以下の通りに定められることができる：

【0207】

ｔｉｌｅ＿ｐｒｉｏｒｉｔｙは、復号化順序を引き継ぐ前に置かれたスライスのすべてのタイルの優先度を示す。ｔｉｌｅ＿ｐｒｉｏｒｉｔｙの値はすべてこみで範囲０〜７の範囲にあり、７は最高優先度を示す。

【0208】

１の値を有するｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇは、復号化順序を引き継ぐために接頭辞スライスにおける１以上のタイルを有することを示す。０の値を有するｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇは、次の接頭辞スライスが１つのタイルだけを含むことを示す。

【0209】

ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｍｉｎｕｓ１は、復号化順序を受け継ぐ接頭辞スライスのタイルの数を示す。

【0210】

ｆｉｒｓｔ＿ｔｉｌｅ＿ｉｄ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓは、復号化順序を受け継ぐ接頭辞スライスの第１のタイルのｔｉｌｅ＿ｉｄを示す。

【0211】

すなわち、図１６の実施例は、図１６において言及されるタイル識別パケットを実現するための図２９の構文を使用して実施されることができる。そこに示されるように、特定のフラグ、ここでは、ｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇは、単に１つのタイルだけか複数のタイルがそれぞれの分散型のタイル識別パケットの範囲に属しているペイロード・パケットのいずれかに符号化される現在の画像１８のサブポーションによってカバーされるかどうか分散型のタイル識別パケットの範囲内で示すために用いてもよい。フラグが複数のタイルを覆うことの信号を送る場合、更なる構文要素がそれぞれの分散型のパケット、ここでは見本として、それぞれの分散型のタイル識別パケットの範囲に属するいかなるペイロード・パケットのいかなるサブポーションによって終われるタイルの数を示すｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｍｉｎｕｓ１に含まれる。最後に、更なる構文要素、ここでは見本として、ｆｉｒｓｔ＿ｔｉｌｅ＿ｉｄ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓは、現在の分散型のタイル識別パケットによって示されるタイルの数の中のタイルのＩＤを示し、それは復号化順序に従って第１のものである。図２９の構文を図１６の実施例に転移して、第５のペイロード・パケット３２を前に置いているタイル識別パケット７２は、例えば、１にセットされているｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇ、１にセットされているｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｍｉｎｕｓ１を有するすべての３つのちょうど述べられた構文要素を備え、それによって、２つのタイルが現在のスコープに属する２つのタイル、および３にセットされるｆｉｒｓｔ＿ｔｉｌｅ＿ｉｄ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓに属することを示し、そして、現在のタイル識別パケット７２のスコープに属している復号化順序のタイルの進行が３つ目のタイル（ｔｉｌｅ＿ｉｄ＝２を有する）で始まることを示す。

【0212】

図２９も、タイル識別パケット７２がおそらくｔｉｌｅ＿ｐｒｉｏｒｉｔｙ、すなわちそのスコープに属しているタイルの優先度を示すこともできることを明らかにする。ＲＯＩ態様と同様に、ネットワークエンティティ６８は、例えば特定のペイロード・パケットの転送の要請のような伝送作業を制御するためにこのような優先度情報を使用することができる。

【0213】

図３０は、サブピクチャ・タイル範囲情報ＳＥＩメッセージのための構文例を示し、意味論は、以下として定義されることができる：

【0214】

１の値を有するｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇは、復号化順序を受け継ぐために、接頭辞スライスに１つ以上のタイルがあることを示す。０の値を有するｍｕｌｔｉｐｌｅ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｆｌａｇは、以下の接頭辞スライスが１つのタイルだけを含むことを示す。

【0215】

ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ＿ｍｉｎｕｓ１は、復号化順序を受け継ぐための接頭辞スライスのタイルの数を示す。

【0216】

ｔｉｌｅ＿ｈｏｒｚ＿ｓｔａｒｔ［ｉ］は、画像の範囲内でピクセルのｉ番目のタイルの水平方向の始まりを示す。

【0217】

ｔｉｌｅ＿ｗｉｄｔｈ［ｉ］は、画像の範囲内でピクセルのｉ番目のタイルの幅を示す。

【0218】

ｔｉｌｅ＿ｖｅｒｔ＿ｓｔａｒｔ［ｉ］は、画像の範囲内でピクセルのｉ番目のタイルの水平方向の始まりを示す。

【0219】

ｔｉｌｅ＿ｈｅｉｇｈｔ［ｉ］は、画像の範囲内でピクセルのｉ番目のタイルの高さを示す。

【0220】

タイル範囲ＳＥＩメッセージは表示操作、例えばタイルを複数の画面表示シナリオのスクリーンに割り当てるために用いられることに注意されたい。

【0221】

図３０は、このように、それぞれのタイル識別パケットのスコープに属しているタイルがそれらのタイルＩＤよりむしろ現在の画像１８の範囲内でそれらの場所によって示されるという点で、図１６のタイル識別パケットに関する図２９の実施構文例が変化に富んでもよいことを明らかにする。すなわち、それぞれの分散型のタイル識別パケットのスコープに属しているペイロード・パケットのいずれかに符号化されるそれぞれのサブポーションによってカバーされる復号化順序における第１のタイルのタイルＩＤの信号を送るよりはむしろ、現在のタイル識別パケットに属しているタイルごとに、その位置は、例えば各タイルｉの上左コーナー位置、ここでは見本としてｔｉｌｅ＿ｈｏｒｚ＿ｓｔａｒｔおよびｔｉｌｅ＿ｖｅｒｔ＿ｓｔａｒｔ、およびタイルｉの幅および高さ、ここでは見本としてｔｉｌｅ＿ｗｉｄｔｈおよびｔｉｌｅ＿ｈｅｉｇｈｔによって信号を送られることができる。

【0222】

関心領域ＳＥＩメッセージのための構文例は図３１に示される。さらに正確であるために、図３２は、第１の変形を示す。特に、関心領域ＳＥＩメッセージが、例えば、１つ以上の関心領域の信号を送るために、アクセスユニットレベルまたはサブピクチャ・レベルで使われることができる。図３２の第１の変形によれば、複数のＲＯＩが現在のスコープの中にある場合、個々のＲＯＩは、１つのＲＯＩ ＳＥＩメッセージの範囲内のそれぞれのＲＯＩパケットのスコープのすべてのＲＯＩの信号を送ることよりむしろ、ＲＯＩ ＳＥＩメッセージごとに一度信号を送られる。

【0223】

図３１によれば、関心領域ＳＥＩメッセージは、個々に各ＲＯＩの信号を送る。意味論は、以下の通りに定められることができる：

【0224】

ｒｏｉ＿ｉｄは、関心領域の識別子を示す。

【0225】

ｒｏｉ＿ｐｒｉｏｒｉｔｙは、復号化順序を受け継ぐために、ＳＥＩメッセージがサブピクチャ・レベルかアクセスユニットレベルのどちらで送られるかによって、接頭辞スライスにおいて関心領域またはすべてのスライスに属するすべてのタイルの優先度を示す。ｒｏｉ＿ｐｒｉｏｒｉｔｙの値は、包括的に０〜７の範囲であり、７は、最高優先度を示す。両方とも、ｒｏｉ情報ＳＥＩメッセージのｒｏｉ＿ｐｒｉｏｒｉｔｙおよびサブピクチャ・タイル情報ＳＥＩメッセージのｔｉｌｅ＿ｐｒｉｏｒｉｔｙが与えられる場合、両方の最も高い値は個々のタイルの優先度にあてはまる。

【0226】

ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｒｏｉ＿ｍｉｎｕｓ１は、関心領域に属する復号化順序を受け継ぐ接頭辞スライスにおけるタイルの数を示す。

【0227】

ｒｏｉ＿ｔｉｌｅ＿ｉｄ［ｉ］は、復号化順序を受け継ぐ接頭辞スライスに対する関心領域に属するｉ番目のタイルのｔｉｌｅ＿ｉｄを示す。

【0228】

すなわち、図３１は、図１５で示すようなＲＯＩパケットが、それぞれのＲＯＩパケットおよびスコープに属するペイロード・パケットが参照する関心領域のＩＤの信号を送ることができることを示す。任意には、ＲＯＩ優先度インデックスは、ＲＯＩ ＩＤとともに信号を送られることができる。しかしながら、両方の構文要素は、任意である。それから、構文要素ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｒｏｉ＿ｍｉｎｕｓ１は、それぞれのＲＯＩ ６０に属しているそれぞれのＲＯＩパケットのスコープにおけるタイルの数を示すことができる。それから、ｒｏｉ＿ｔｉｌｅ＿ｉｄは、ＲＯＩ ６０に属しているｉ番目のタイルのタイル−ＩＤを示す。例えば、画像１８が図１６に示された方法でタイル７０に再分割されることを想像すると、図１５のＲＯＩ ６０が画像１８の左側の半分に対応する画像に対応することは復号化順序における第１および第３のタイルによって形成される。それから、ＲＯＩパケットは図１６のアクセスユニット３０の第１のペイロード・パケット３２の前に配置されることができ、そして、このアクセスユニット３０の第４のおよび第５のペイロード・パケット３２の間に更なるＲＯＩパケットが続く。それから、第１のＲＯＩパケットは、ｎｕｍ＿ｔｉｌｅ＿ｉｎ＿ｒｏｉ＿ｍｉｎｕｓ１が０にセットされるとともにｒｏｉ＿ｔｉｌｅ＿ｉｄ［０］が０にセットされ、（このことにより、復号化順序において第１のタイルに注意を向ける）、第５のペイロード・パケット３２の前の第２のＲＯＩパケットは、２にセットされているｒｏｉ＿ｔｉｌｅ＿ｉｄ［０］とともに０にセットされているｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｒｏｉ＿ｍｉｎｕｓ１を有する（このことにより、画像１８の左側の底の四半期で復号化順序の第３のタイルを意味している）。

【0229】

第２の変形によれば、関心ＳＥＩメッセージの領域の構文は、図３２に示すようにすることができる。ここで、単一のＳＥＩメッセージのすべてのＲＯＩは、信号を送られる。特に、上述のように図３１に関するのと同じ構文が使われるが、構文要素、ここでは見本としてｎｕｍ＿ｒｏｉｓ＿ｍｉｎｕｓ１により信号を送られる数で、それぞれのＲＯＩ ＳＥＩメッセージまたはＲＯＩパケットが参照する多数のＲＯＩのそれぞれのＲＯＩのための構文要素を乗算する。任意に、更なる構文要素、ここでは見本として、ｒｏｉ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｏｎ＿ｓｅｐａｒａｔｅ＿ｓｃｒｅｅｎは、それぞれのＲＯＩが別々のスクリーンに示されることに適しているかどうかＲＯＩごとに示すことができる。

【0230】

意味論的なものは、以下の通りとすることができる：

【0231】

ｎｕｍ＿ｒｏｉｓ＿ｍｉｎｕｓ１は、接頭辞スライスのＲＯＩまたは復号化順序を受け継ぐ規則的なスライスの数を示す。

【0232】

ｒｏｉ＿ｉｄ［ｉ］は、ｉ番目の関心領域の識別子を示す。

【0233】

ｒｏｉ＿ｐｒｉｏｒｉｔｙ［ｉ］は、復号化順序を受け継ぐために、ＳＥＩメッセージがサブピクチャ・レベルかアクセスユニットレベルのどちらで送られるかによって、接頭辞スライスにおいてｉ番目の関心領域またはすべてのスライスに属するすべてのタイルの優先度を示す。ｒｏｉ＿ｐｒｉｏｒｉｔｙの値は、包括的に０〜７の範囲であり、７は、最高優先度を示す。両方とも、ｒｏｉ情報ＳＥＩメッセージのｒｏｉ＿ｐｒｉｏｒｉｔｙおよびサブピクチャ・タイル情報ＳＥＩメッセージのｔｉｌｅ＿ｐｒｉｏｒｉｔｙが与えられる場合、両方の最も高い値は個々のタイルの優先度にあてはまる。

【0234】

ｎｕｍ＿ｔｉｌｅｓ＿ｉｎ＿ｒｏｉ＿ｍｉｎｕｓ１［ｉ］は、ｉ番目の関心領域に属する復号化順序を受け継ぐ接頭辞スライスのタイルの数を示す。

【0235】

ｒｏｉ＿ｔｉｌｅ＿ｉｄ［ｉ］［ｎ］は、復号化順序を受け継ぐ接頭辞スライスに対する関心のｉ番目の領域に属するｎ番目のタイルのｔｉｌｅ＿ｉｄを示す。

【0236】

ｒｏｉ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｏｎ＿ｓｅｐｅｒａｔｅ＿ｓｃｒｅｅｎ［ｉ］は、ｉ番目のｒｏｉ＿ｉｄに関連した関心領域が別々のスクリーン上のプレゼンテーションに適していることを示す。

【0237】

かくして、一時的に、今までに記載されている各種実施形態を要約すると、スライス・レベル当たりのＮＡＬユニットヘッダに含まれるものを越えた更なる高水準構文アイテムと同様にＳＥＩメッセージを適用できるようにする更なる高レベルの構文シグナル伝達戦略が提示された。したがって、我々は、スライス接頭辞ＮＡＬユニットを解説した。スライス接頭辞およびｓｌｉｃｅ＿ｌｅｖｅｌ／サブピクチャＳＥＩメッセージの構文および意味論は、低い遅延／サブピクチャＣＰＢ動作、タイル・シグナリングおよびＲＯＩシグナリングのための使用事例とともに記載されていた。拡張した構文は、加えて、スライス接頭辞の以下のスライスのスライス・ヘッダの信号部分に提示された。

【0238】

完全性のために、図３３は、図１２〜１４の実施例に従ってタイミング制御パケットのために使われることができる構文のための更なる実施例を示す。意味論は以下の通りでありえる：

【0239】

現在のアクセスユニットの復号化順序の最後の復号化ユニットおよび復号化ユニット情報ＳＥＩメッセージと関連した復号化ユニットの名目上のＣＰＢ時間との間に、クロックサブティックを単位にして、ｄｕ＿ｓｐｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｉｎｃｒｅｍｅｎｔは、期間を特定する。アネックスＣで特定されるように、この値はＨＳＳのためのＣＰＢに復号化ユニットデータの到着の最も早い可能な時間を計算するためにも用いられる。構文要素は、ビットの長さがｄｕ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｉｎｃｒｅｍｅｎｔ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によって与えられる固定長コードによって表される。復号化ユニット情報ＳＥＩメッセージと関連した復号化ユニットが現在のアクセスユニットの最後の復号化ユニットであるときに、ｄｕ＿ｓｐｔ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｉｎｃｒｅｍｅｎｔの値は０に等しい。

【0240】

１に等しいｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは復号化ユニット情報ＳＥＩメッセージのｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙ構文要素の存在を特定する。０に等しいｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙ＿ｐｒｅｓｅｎｔ＿ｆｌａｇは復号化ユニット情報ＳＥＩメッセージのｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙ構文要素の欠如を特定する。

【0241】

ＳｕｂＰｉｃＨｒｄＦｌａｇが１に等しいときに、ｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙは画像のＤＰＢ出力時間を計算するために用いられる。それは、ＣＰＢからアクセスユニットの最後の復号化ユニットの除去の後復号化画像がＤＰＢから出力される前に、どれくらいのサブクロックティックを待つかについて特定する。ないときには、ｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙの値はｐｉｃ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙに等しいと推測される。構文要素ｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙの長さは、ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙ＿ｄｕ＿ｌｅｎｇｔｈ＿ｍｉｎｕｓ１＋１によってビットにおいて与えられる。

【0242】

同じアクセスユニットと関連する全ての復号化ユニット情報ＳＥＩメッセージが同じ動作点に適用され、１に等しいｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙ＿ｐｒｅｓｅｎｔ＿ｆｌａｇがｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙと同じ値を有することが、ビットストリーム一致の要件である。出力タイミング同調デコーダから出力されるいかなる画像のｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙにも由来する出力時間は、復号化順序におけるいかなる次のＣＶＳのすべての画像のｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙにも由来する出力時間に先行する。

【0243】

この構文要素の値によって決められる画像アウトプット順序は、ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値によって確立するのと同じ順序である。

【0244】

復号化順序において、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが１に等しいか１に等しいと認められるＩＲＡＰ画像に先行するため「バンピング」プロセスによって出力されない画像のために、ｐｉｃ＿ｓｐｔ＿ｄｐｂ＿ｏｕｔｐｕｔ＿ｄｕ＿ｄｅｌａｙに由来する出力時間は、同じＣＶＳ内の全ての画像に対してＰｉｃＯｒｄｅｒＣｎｔＶａｌの値の増加と共に増加している。ＣＶＳのいかなる２つの画像のためにも、ＳｕｂＰｉｃＨｒｄＦｌａｇが１に等しいときの２つの画像の出力時間の差は、ＳｕｂＰｉｃＨｒｄＦｌａｇが０に等しいときの差と同一である。

【0245】

さらに、図３４は、ＲＯＩパケットを用いてＲＯＩ領域の信号を送るための更なる実施例を示す。図３４によれば、ＲＯＩパケットの構文は、そのスコープに属するいくつかのペイロード・パケット３２に符号化された画像の全てのサブポーションがＲＯＩに属するかどうかを示す１つのフラグのみを含む。「スコープ」は、ＲＯＩパケットまたはｒｅｇｉｏｎ＿ｒｅｆｒｅｓｈ＿ｉｎｆｏ ＳＥＩメッセージの発生まで伸びる。フラグが１である場合、領域はそれぞれの次のペイロード・パケットに符号化され、０である場合、逆のものが適用される、すなわち、画像１８のそれぞれのサブポーションはＲＯＩ ６０に属しない。

【0246】

上述の実施例のいくつかを再度議論する前に、言い換えればタイル、スライス、ＷＰＰ、サブストリーム、サブディビジョニングのような上で使用されているいくつかの言葉を説明する前に、前記実施例のＨｉｇｈ Ｌｅｖｅｌシグナリングがあるいは、例えば［３−７］のような輸送仕様において定められることができる点に留意する必要がある。換言すれば、前述のパケットおよび形成シーケンス３４は、いくらかがスライスのようなアプリケーションレイヤーのサブポーションを有する転送パケットであり、全体的にまたは断片化されてそこにパケット化されるように包含され、いくらかは方法において後者と上述のような目的との間で分散される。換言すれば、上述の分散型のパケットは、アプリケーションレイヤーのビデオ・コーデックに定義付けられるが、その代わりに転送プロトコルに定義付けられた特別な転送パケットになることができる別のタイプのＳＥＩメッセージとして定義付けられるように制限されない。

【0247】

換言すれば、本願明細書の一態様によれば、前記実施例でビデオ内容の画像のサブポーション（符号化木ブロックまたはスライスを参照）を単位にしてその中で符号化されるビデオ内容を有するビデオ・データストリームがみられ、そして、各サブポーションがビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）の１つ以上のペイロード・パケット（ＶＣＬ ＮＡＬユニットを参照）にそれぞれ符号化され、パケットのシーケンスはアクセスユニットのシーケンスに分割され、それにより、各アクセスユニットはビデオ内容のそれぞれの画像に関するペイロード・パケットを集めて、パケットのシーケンスがタイミング制御パケット（スライス接頭辞）をその中に分散し、それによりタイミング制御パケットがアクセスユニットを復号化ユニットに再分割し、それにより少なくともいくつかのアクセスユニットは２つ以上の復号化ユニットに再分割され、各タイミング制御パケットは復号化ユニットのためのデコーダバッファ検索時間、パケットのシーケンスのそれぞれのタイミング制御パケットが続くペイロード・パケットの信号を送る。

【0248】

上述の通り、ビデオ内容が画像のサブポーションを単位にするデータストリームに符号化される領域は、例えば符号化モード（例えばイントラ・モード、インターモード、細別情報など）のような前兆となる符号化、予測パラメータ（例えば、動きベクトル、外挿方向等）および／または残余のデータ（例えば、変換係数等）に関する構文要素をカバーすることができ、これらの構文要素は、例えば、それぞれ、符号化ツリー・ブロック、予測ブロックおよび残余の（例えば、変換等）ブロックのような画像のローカルポーションと関係している。

【0249】

上述の通り、ペイロード・パケットは、１つ以上のスライス（完全に、それぞれ）を各々含むことができる。スライスは、それぞれに復号化可能でもよいかまたはその独立復号化を妨げる相互関係を示すことができる。たとえば、エントロピー・スライスはそれぞれにエントロピー復号化可能であるが、スライス境界を越えた予測は禁止されることができる。従属するスライスは、ＷＰＰ処理、すなわち重なり合う時間に従属するスライスを並列に符号化／復号化する能力をもってスライス境界を越えてエントロピーおよび予測符号化を用いるが、個々の従属するスライスおよび従属するスライスによって呼ばれるスライスの符号化／復号化の交互の開始の符号化／復号化を可能にすることができる。アクセスユニットのペイロード・パケットがそれぞれのアクセス装置の範囲内で配置される経時的な命令は、前もってデコーダに知られていることができる。

【0250】

アクセスユニットのペイロード・パケットがそれぞれのアクセスユニットの範囲内に配置されている順序は、前もってデコーダに知られている。たとえば、符号化／復号化順序は、例えば上記例の符号化ツリー・ブロックの中のスキャン順序などのようなサブポーションの中で定められることができる。

【0251】

例えば、以下の図を参照していただきたい。現在符号化／復号化画像１００は、図３５および３６において、見本として画像１１０の四半部に対応し、参照符号１１２ａ〜１１２ｄで示されるタイルに分けられることができる。すなわち、全部の画像１１０は、図３７の場合のような１つのタイルを形成することができるかまたは複数のタイルに分割されることができる。タイル分割は、タイルが列および行だけに配置される規則的なものに制限されることができる。異なる実施例は、以下に示される。

【0252】

見られるように、画像１１０は、更に符号化（ツリー）ブロック（図中の小さい箱で上記でＣＴＢと呼ばれている）１１４に再分割され、その中で、符号化順序１１６が定められる（ここでは、ラスタ・スキャン順序であるが、異なるものであってもよい）。タイル１１２ａ〜ｄへのブロック１１４の画像の再分割は、タイルがブロック１１４の互いに素であるように制限されることができる。さらに、ブロック１１４およびタイル１１２ａ〜ｄは、列および行の規則的配列となるように制限されることができる。

【0253】

タイル（すなわち１以上の）がある場合、符号化（復号化）順序１１６のラスタを最初に完全なタイルをスキャンし、それから−ラスタ・スキャンタイル順序で−次のタイルにタイル順序で推移する。

【0254】

タイルは空間的な隣接から推測される空間予測および文脈選択によりタイル境界の非交差のため互いに独立している符号化／復号化であるので、エンコーダ１０およびデコーダ１２は、例えばタイル境界の交差が許されているインループまたはポストフィルタリングを除いて、タイル１１２（元は７０で示された）に再分割された画像を互いに独立して並列に符号化／復号化することができる。

【0255】

画像１１０は、スライス１１８ａ〜ｄ、１８０−元は参照符号２４で示されていた−に更に再分割されることができる。スライスは、タイルの部分だけ、１つの完全なタイルまたは複数のタイルを完全に含むことができる。このように、スライスへの分割は、図３５のケースのようにタイルを再分割することもできる。各スライスは、完全に１つの符号化ブロック１１４を含み、符号化順序１１６で連続的な符号化ブロック１１４から成り、その結果、順序は図のインデックスが割り当てられたスライス１１８ａ〜ｄの中で定められる。図３５〜３７のスライス分割は、説明の便宜上選ばれたものである。タイル境界は、データストリームにおいて信号を送った。画像１１０は、図３７に図示するように、単一のタイルを形成することができる。

【0256】

空間予測がタイル境界を横断して適用されないという点で、エンコーダ１０およびデコーダ１２はタイル境界に従うように構成されることができる。文脈適応、すなわちさまざまなエントロピー（算術的）文脈の確率適応は、全てのスライスを通じて続けることができる。しかしながら、スライス１１８ａ，ｂに関して図３６に示すように、スライスは−符号化順序１１６に沿って−タイル境界線（スライスで内側にある場合）を横切るときはいつでも、スライスは、次に、各サブセクションの始まりを示しているポインタ（ｃ．ｐ．ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ）を含むスライスを有するサブセクション（サブストリームまたはタイル）に再分割される。デコーダ―ループにおいて、フィルタは、タイル境界を横切ることができる。このようなフィルタは、デブロッキング・フィルタ、Ｓａｍｐｌｅ Ａｄａｐｔｉｖｅ Ｏｆｆｓｅｔ（ＳＡＯ）フィルタおよびＡｄａｐｔｉｖｅ ｌｏｏｐフィルタ（ＡＬＦ）の１つ以上を含むことができる。起動する場合、後者はタイル／スライス境界を通じて適用されることができる。

【0257】

各任意の第２のおよび以下のサブセクションは、次のサブセクションに始めに１つのサブセクションの始まりからオフセットを示しているポインタを有するスライスの範囲内でバイト整列されて配置されるそれらの始まりを有することができる。サブセクションは、スキャン順序１１６のスライスの範囲内で配置される。図３８は、見本としてサブセクション１１９iに再分割されている図３７のスライス１８０ｃを有する実施例を示す。

【0258】

図に関して、タイルのサブパートを形成しているスライスがタイル１１２ａの行を有する端部でなければならないということではないことに注意されたい。例えば、図３７および図３８のスライス１１８ａを参照。

【0259】

以下の図は、上記の図３８の画像１１０と関連したアクセスユニットに関するデータストリームの典型的な部分を示す。ここで、各ペイロード・パケット１２２ａ〜ｄ−以前参照符号３２によって示された−は、見本として、単に１つのスライス１１８ａだけに適応する。２つのタイミング制御パケット１２４ａ，ｂ−以前示されたそばに参照記号３６−は、説明の便宜上アクセスユニット１２０に分散するとして示される：１２４ａはパケット順序１２６（復号化／符号化時間軸に対応する）のパケット１２２ａに先行し、１２４ｂはパケット１２２ｃに先行する。したがって、アクセスユニット１２０は２つの復号化ユニット１２８ａ，ｂ−以前参照符号３８によって示された−に分けられ、それの第１の１つはパケット１２２ａ，ｂ（任意のフィルタデータパケット（それぞれ、第１および第２のパケット１２２ａ，ｂに続く）およびＳＥＩパケットに続く任意のアクセスユニット（第１のパケット１２２ａに先行する））から成り、それの第２の１つはパケット１１８ｃ，ｄ（任意のフィルタデータパケット（それぞれ、パケット１２２ｃ，ｄに続く））から成る。

【0260】

上述のように、パケットのシーケンスの各パケットは、複数のパケット・タイプ（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ）から、正確に１つのパケット・タイプに割り当てられることができる。ペイロード・パケットおよびタイミング制御パケット（および、任意のフィルタデータおよびＳＥＩパケット）は、例えば、異なるパケット・タイプのものである。パケットのシーケンスの特定のパケット・タイプのパケットのインスタンス化は、特定の限界に従属してもよい。これらの限界は、アクセス装置境界１３０ａ，ｂが検出可能であるように、各アクセスユニットの範囲内でパケットによって従われることになっているパケット・タイプ（図１７を参照）の中の順序を定めることができ、いかなる除去可能なパケット・タイプのパケットがビデオ・データストリームから除去される場合であっても、パケットのシーケンス内の同じ位置に残る。たとえば、ペイロード・パケットは、除去不可能なパケット・タイプのものである。しかしながら、タイミング制御パケット、フィルタデータパケットおよびＳＥＩパケットは、上述のように、除去可能なパケット・タイプのものでもよい、すなわち、それらは、非ＶＣＬ ＮＡＬユニットでもよい。

【0261】

上記の実施例において、タイミング制御パケットは、ｓｌｉｃｅ＿ｐｒｅｆｉｘ＿ｒｂｓｐ０の構文によって、上で明確に例証された。

【0262】

このようなタイミング制御パケットの分散を用いて、エンコーダは、ビデオ内容の個々の画像を符号化する過程でデコーダ側でバッファ・スケジューリングを調整することを可能にされる。たとえば、エンコーダは、端末間の遅延を最小化するためにバッファ・スケジューリングを最適化することを可能にされる。この点に関しては、エンコーダは、ビデオ内容の個々の画像のためのビデオ内容の画像領域全体の符号化複合性の個々の配布を考慮に入れることを可能にされる。特に、エンコーダは、パケットごとに（すなわち、現在のパケットが終了するとすぐにそれは出力される）、パケット１２２、１２２ａ−ｄ、１２２ａ−ｄ1-3のシーケンスを連続的に出力することができる。タイミング制御パケットを用いて、エンコーダは、現在の画像のサブポーションのいくつかが残りのサブポーションを有するそれぞれのペイロード・パケットにすでに符号化されたが、まだ符号化されなかった場合には、復号化側で時々バッファ・スケジューリングを調整することが可能である。

【0263】

したがって、パケットのシーケンスがアクセスユニットのシーケンスに分割され、各アクセスユニットがビデオ内容のそれぞれの画像に関連するペイロード・パケットを集めるように、ビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）の１つ以上のペイロード・パケット（ＶＣＬ ＮＡＬユニット）にそれぞれ各サブポーションを符号化することで、ビデオ内容の画像のサブポーションのユニット（符号化ツリー・ブロック、タイルまたはスライスを参照）のビデオ・データストリームのビデオ内容に符号化するためのエンコーダは、パケットのシーケンスにタイミング制御パケット（スパイス接頭辞）を分散させるように構成され、それにより、タイミング制御パケットはアクセスユニットを復号化ユニットに再分割し、それにより、少なくともいくつかのアクセスユニットは複数の復号化ユニットに再分割され、各タイミング制御パケットは復号化ユニットのために復号化バッファ検索時間の信号を送り、そのペイロード・パケットはパケットのシーケンスにおけるそれぞれのタイミング制御パケットに続く。

【0264】

ちょうど概説されたビデオ・データストリームを受信しているいかなるデコーダも、タイミング制御パケットに含まれるスケジュール情報を利用するかどうかは自由である。しかしながら、デコーダが情報を利用することができる間、コーデック・レベルに従っているデコーダは示されたタイミングの後にデータを復号化することが可能でなければならない。利用される場合、デコーダはそのデコーダバッファを供給して、復号化ユニットを単位にするそのデコーダバッファを空にする。「デコーダバッファ」は、上述のように、復号化ピクチャ・バッファおよび／または符号化ピクチャ・バッファを含むことができる。

【0265】

したがって、各アクセスユニットがビデオ内容のそれぞれの画像に関連するペイロード・パケットを集めるように、ビデオ内容の画像のサブポーション（符号化ツリー・ブロック、タイルまたはスライスを参照）を単位にしてそこに符号化されるビデオ内容を有し、各サブポーションがそれぞれビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）の１つ以上のペイロード・パケット（ＶＣＬ ＮＡＬユニットを参照）に符号化されるビデオ・データストリームを復号化するためのデコーダは、アクセスユニットをタイミング制御パケットで復号化ユニットに再分割したパケットのシーケンスに分散されたタイミング制御パケットを探すように構成され、それにより、少なくともいくつかのアクセスユニットは複数の復号化ユニットに分割され、各タイミング制御パケットから復号化ユニットのためにデコーダバッファ検索時間を引き出し、そのペイロード・パケットはパケットのシーケンスのそれぞれのタイミング制御パケットに続き、復号化ユニットのためのデコーダバッファ検索時間によって規定された時間で予定されたデコーダのバッファから復号化ユニットを検索する。

【0266】

タイミング制御パケットを探すことは、このことにより含まれるＮＡＬユニットヘッダおよび構文要素を検査しているデコーダを含むことができる、すなわちｎａｌ＿ｕｎｉｔ＿ｔｙｐｅである。後のフラグの値がいくつかの値に等しい場合、すなわち、上述の例では、１２４である場合、現在検査されるパケットはタイミング制御パケットである。すなわち、タイミング制御パケットは、ｓｕｂｐｉｃ＿ｔｉｍｉｎｇと同様に疑似コードｓｕｂｐｉｃ＿ｂｕｆｆｅｒｉｎｇに関して上で説明される情報を含むかまたは伝達する。すなわち、タイミング制御パケットは、デコーダのための最初のＣＰＢ除去遅延を伝達するか特定し、またはそれぞれのデコーダユニットのＣＰＢからの除去の後、どれくらいのクロックが経過するかについて特定することができる。

【0267】

意図せずに更にアクセスユニットを復号化ユニットに分割することなくタイミング制御パケットの反復伝送を可能にするために、タイミング制御パケットの範囲内のフラグは、現在のタイミング制御パケットがアクセスユニット内において符号化ユニットに再分割されるかどうかの信号を明確に送る（復号化ユニットの始まりを示しているｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｆｌａｇ＝１および逆の状況の信号を送っているｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｆｌａｇ＝０を比較）。

【0268】

タイル識別パケットがデータストリームに分散するという点で、分散型の復号化ユニット関連のタイル識別情報を使用する態様は分散型の復号化ユニット関連のタイミング制御パケットを使用する態様と異なる。上述のタイミング制御パケットは加えて、データストリームに分散することができ、または、デコーダバッファ検索時間は共通に同じパケットの範囲内で下に説明されたタイル識別情報とともに伝達される。したがって、上述のセクションにおいて前方に持ってこられる詳細が、以下の説明における問題を明らかにするために使用されることができる。

【0269】

上記の実施例から導き出せる本願明細書の更なる態様は、そこにおいて符号化されるビデオ内容を有するビデオ・データストリームを明らかにし、ビデオ内容の画像が空間的に再分割するスライスを単位にして予測およびエントロピー符号化を用い、ビデオ内容の画像が空間的に再分割されるタイルの内部に予測符号化および／またはエントロピー符号化を制限するスライスの間で符号化順序を使用して、符号化順序におけるスライスのシーケンスは符号化順序における符号化ビデオ・データストリームのスライスのシーケンスは、符号化順序のビデオ・データストリームにおけるパケットのシーケンス（ＮＡＬユニット）のパケットをペイロードにパケット化し、パケットのシーケンスはアクセスユニットのシーケンスに分割され、その結果、各アクセスユニットはビデオ内容のそれぞれの画像に関するスライスがパケット化されたペイロード・パケットを集め、パケットのシーケンスは、パケットのシーケンスのそれぞれのタイル識別パケットの後に１つ以上のペイロード・パケットにパケット化されたスライス（潜在的にたった１つの）によってすぐ覆われるタイル（潜在的にたった１つの）を確認してそこへ分散するタイル識別パケットを有する。

【0270】

たとえば、すぐ前の図がデータストリームを示していることを参照されたい。パケット１２４ａおよび１２４ｂは、現在タイル識別パケットを表す。明確なシグナリング（ｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇ＝１を比較）によって、または、慣例につき、タイル識別パケットは、直ちに続くペイロード・パケット１２２ａにパケット化されたスライスによって覆われるタイルを確認することができるだけである。あるいは、明確なシグナリングによって、または、慣例につき、タイル識別パケット１２４ａは、現在のアクセスユニット１２０の端部１３０ｂのより初期のものまでパケットのシーケンスのそれぞれのタイル識別パケット１２４ａの後に１つ以上のペイロード・パケットにパケット化されたスライスによって覆われるタイルおよび、それぞれ、次の復号化ユニット１２８ｂを始めることを確認することができる。例えば、図３５を参照：各スライス１１８ａ−ｄ1-3が別にそれぞれのパケット１２２ａ−ｄ1-3へのパケット化である場合、復号化ユニットへの再分割は、パケットが｛１２２ａ1-3｝および｛１２２ｂ1-3｝に従って３つの復号化ユニットにグループ化されるようにされ、第３の復号化ユニットのパケット｛１２２ｃ1-3、１２２ｄ1―3｝にパケット化されるスライス｛１１８ｃ1-3、１１８ｄ1-3｝は例えばタイル１１２ｃおよび１１２ｄを覆い、対応するスライス接頭辞は例えば完全な復号化ユニットに言及するとき“ｃ”および“ｄ”、すなわちこれらのタイル１１２ｃおよび１１２ｄを示す。

【0271】

このように、更に下に記載のネットワークエンティティは、パケットのシーケンスの識別パケットの直後の１つ以上のペイロード・パケットと各タイル識別パケットを関連させるために、この明確なシグナリングまたは慣例を使用することができる。識別が信号を送られることができる方法は、疑似コードｓｕｂｐｉｃ＿ｔｉｌｅ＿ｉｎｆｏを経由して上で見本として記載されていた。関連するペイロード・パケットは、「接頭辞スライス」として前述していた。当然、実施例は、変更されることができる。例えば、構文要素「ｔｉｌｅ＿ｐｒｉｏｒｉｔｙ」は、外されることができる。さらに、構文要素の中の順序は切替えられることができ、そして、可能なビット長に関する記述子および構文要素の原則の符号化は単に図示するだけである。

【0272】

ビデオ・データストリームを受信するネットワークエンティティ（すなわち、そこにおいて符号化されるビデオ内容を有するビデオ・データストリームを明らかにし、ビデオ内容の画像が空間的に再分割するスライスを単位にして予測およびエントロピー符号化を用い、ビデオ内容の画像が空間的に再分割されるタイルの内部に予測符号化および／またはエントロピー符号化を制限するスライスの間で符号化順序を使用して、符号化順序におけるスライスのシーケンスは、符号化順序のビデオ・データストリームにおけるパケットのシーケンス（ＮＡＬユニット）のパケットをペイロードにパケット化し、パケットのシーケンスはアクセスユニットのシーケンスに分割され、その結果、各アクセスユニットはビデオ内容のそれぞれの画像に関するスライスがパケット化されたペイロード・パケットを集め、パケットのシーケンスは、その中に分散するタイル識別パケットを有する）は、タイル識別パケットに基づいて、パケットのシーケンスのそれぞれのタイル識別パケットの後に１つ以上のペイロード・パケットにスライス・パケット化によって覆われるタイルを確認するように構成することができる。ネットワークエンティティは、伝送作業を決定するために、識別結果を使用することができる。たとえば、ネットワークエンティティは、再生のための異なる優先度を有する異なるタイルを扱うことができる。たとえば、パケット損失の場合には、より高い優先度のタイルに関するそれらのペイロード・パケットは、低い優先度のタイルに関するペイロード・パケット上を再伝送されることが好ましい。すなわち、ネットワークエンティティは、より高い優先度のタイルに関する失われたペイロード・パケットの再伝送を最初に要請することができる。単に（転送率に応じて）十分な時間が残されているだけの場合には、ネットワークエンティティは、低い優先度のタイルに関する失われたペイロード・パケットの再伝送を要請することに移る。しかしながら、ネットワークエンティティは、特定のタイルに関するタイルまたはペイロード・パケットを異なるスクリーンに割り当てることが可能であるプレイバックユニットでもよい。

【0273】

分散型の関心領域情報を使用する態様に関して、以下のＲＯＩパケットが上述したタイミング制御パケットおよび／またはタイル識別パケットによって、スライス接頭辞に関して上述したように共通のパケットの範囲内でその情報内容を結合することによっても、または、別々のパケットの形で共存することができる点に留意する必要がある。

【0274】

上記の通りに分散型の関心領域情報を使用する態様で、換言すれば、ビデオ・データストリームはそこにおいて予測およびエントロピー符号化を用いて符号化されるビデオ内容を有し、スライスの間の符号化順序を用いて、ビデオ内容の画像が空間的に分割され、ビデオ内容の画像が分割されるタイルの内部への予測符号化の予測および／またはエントロピー符号化を制限し、符号化順序のスライスのシーケンスが、符号化順序のビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）のペイロード・パケットにパケット化され、各アクセスユニットがビデオ内容のそれぞれの画像に関するスライスをそこへパケット化されたペイロード・パケットを集めるようにパケットのシーケンスはアクセスユニットのシーケンスに分割され、パケットのシーケンスは、それぞれ、画像のＲＯＩに属する画像のタイルを確認してそこに分散するＲＯＩパケットを有する。

【0275】

ＲＯＩパケットに関して、類似のコメントは、タイル識別パケットに関して以前に与えられているそれらとして有効である：ＲＯＩパケットは、単にそれぞれのＲＯＩパケットがそれが「接頭辞スライス」に関して上述したように１つ以上のペイロード・パケットに直ちに先行するために関連する１つ以上のペイロード・パケットに含まれるスライスによって覆われるそれらのタイルの中だけの画像のＲＯＩに属する画像のタイルを確認することができる。

【0276】

ＲＯＩパケットは、これらのＲＯＩ（ｃ．ｐ．ｎｕｍ＿ｒｏｉｓ＿ｍｉｎｕｓ１）の各々のための関連するタイルを確認することに関する前に置かれたスライスにつき複数のＲＯＩを確認することを可能にすることができる。それから、ＲＯＩごとに、優先度（ｃ．ｐ．ｒｏｉ＿ｐｒｉｏｒｉｔｙ［ｉ］）に関してＲＯＩをランク付けすることを可能にする優先度が送信されることができる。ビデオの画像シーケンスの間、時間とともにＲＯＩの「追跡」を可能にするために、ＲＯＩパケットに示されるＲＯＩが画像の境界を越えて／全域で、すなわち時間とともに（ｃ．ｐ．ｒｏｉ＿ｉｄ［ｉ］）、互いに関連するように、各ＲＯＩは、ＲＯＩインデックスによってインデックスを付けられるようにすることができる。

【0277】

ビデオ・データストリームを受信するネットワークエンティティ（すなわち、ビデオ・データストリームはそこにおいて予測およびエントロピー符号化を用いて符号化されるビデオ内容を有し、スライスの間の符号化順序を用いて、ビデオ内容の画像が空間的に分割され、ビデオ内容の画像が分割されるタイルの内部への予測符号化の予測を制限し、符号化順序のスライスのシーケンスが、符号化順序のビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）のペイロード・パケットにパケット化され、各アクセスユニットがビデオ内容のそれぞれの画像に関するスライスをそこへパケット化されたペイロード・パケットを集めるようにパケットのシーケンスはアクセスユニットのシーケンスに分割される）は、タイル識別パケットに基づいて、画像のＲＯＩに属するタイルを覆うスライスをパケット化しているパケットを確認するように構成される。

【0278】

ネットワークエンティティは、タイル識別パケットに関して前述したように前のセクションにおいて同様の方法のＲＯＩパケットによって伝達される情報を利用することができる。以前のセクションと同様に現在のセクションに関して、上述のようにデータストリームにおいて明確に信号を送り、または慣例によりエンコーダまたはデコーダに知られる画像におけるタイルの位置に関して、単に、画像のスライスのスライス順序を調査することにより、およびこれらのスライスが覆う現在の画像の部分の進捗を調査することにより、単に以下によって、例えばＭＡＮＥまたはデコーダなどのようないかなるネットワークエンティティもどのタイルが現在検査されるペイロード・パケットのスライスによって覆われるかについて確認することが可能な点に留意する必要がある。あるいは、各スライス（スキャン順序の画像で第１のものを除いて）は、デコーダがスライス順序の方向へのこの第１の符号化ブロックから各スライス（その再建）を画像に配置することができるように、それが（同じ符号）を参照する第１の符号化ブロック（例えばＣＴＢ）の表示／インデックス（符号化ツリー・ブロックを単位にして測定されるｓｌｉｃｅ＿ａｄｄｒｅｓｓ）を備えていることができる。したがって、後のタイル識別パケットによって伝達されるインデックスが１以上の差で以前のものと異なる場合、それらの２つのタイル識別パケット間のペイロード・パケットがその間でタイル・インデックスを有するタイルをカバーすることに従って次のタイル識別パケットに遭遇すると、即座に、ネットワークエンティティに対して明らかになるので、上述したタイル情報パケットが単にそれぞれのタイル識別パケットの後に付随する１つ以上のペイロード・パケットのスライスを含む第１のタイル（ｆｉｒｓｔ＿ｔｉｌｅ＿ｉｄ＿ｉｎ＿ｐｒｅｆｉｘｅｄ＿ｓｌｉｃｅｓ）のインデックスから成るだけである場合、それは十分でありえる。スライスが符号化ブロックの中のこのラスタ・スキャン順序に沿ってスライス順序に従って各々に続くので、上記したように、細別および符号化ブロック細別が、例えば、ラスタ・スキャン順序を有する行／列−型の細別に基づいてある両方のタイルがいずれが、例えばタイルおよび符号化ブロック行型、すなわちこのラスタ・スキャン順序のタイル・インデックス増加であるかについてそれらの間で定められる場合、これは真である。

【0279】

上述の実施例から導き出される上述の信号を送るパケット化された分散型のスライス・ヘッダの態様は、記載した前記実施例から導き出せる上述した態様またはいかなるそれらの組み合わせのいずれか１つとでも結合可能である。前に明確に記載されたスライス接頭辞は、例えば、バージョン２によってすべてのこれらの態様を統一する。現在の態様の効果は、それらが前に置かれたスライス／ペイロード・パケットに対して外の自己充足的なパケットにおいて伝えられるように、より容易にスライス・ヘッダデータをネットワークエンティティに利用できるようにする可能性であり、そして、スライス・ヘッダデータの反復伝送は可能にされる。

【0280】

したがって、本願明細書の更なる態様はパケット化および分散型のスライス・ヘッダ・シグナリングの態様であって、換言すれば、ビデオ内容の画像のサブポーション（符号化ツリー・ブロックまたはスライスを参照）を単位にしてその中で符号化されるビデオ内容を有するビデオ・データストリームを公開するとみなされることができ、各サブポーションがビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）の１つ以上のペイロード・パケット（ＶＣＬ ＮＡＬユニットを参照）に符号化され、パケットのシーケンスは各アクセスユニットがビデオ内容のそれぞれの画像に関するペイロード・パケットを集めるようにアクセスユニットのシーケンスに分割され、パケットのシーケンスは、そこへ、パケットのシーケンスのそれぞれのスライス・ヘッダ・パケットに続く１つ以上のペイロード・パケット間の、および欠けているスライス・ヘッダデータを伝達しているスライス・ヘッダ・パケット（スライス接頭辞）を分散させた。

【0281】

ビデオ・データストリーム（すなわち、ビデオ内容の画像のサブポーション（符号化ツリー・ブロックまたはスライスを参照）を単位にしてその中で符号化されるビデオ内容を有するビデオ・データストリームを公開するとみなされることができ、各サブポーションがビデオ・データストリームのパケットのシーケンス（ＮＡＬユニット）の１つ以上のペイロード・パケット（ＶＣＬ ＮＡＬユニットを参照）に符号化され、パケットのシーケンスは各アクセスユニットがビデオ内容のそれぞれの画像に関するペイロード・パケットを集めるようにアクセスユニットのシーケンスに分割され、パケットのシーケンスは、そこへスライス・ヘッダ・パケットを分散させた）を受信するネットワークエンティティは、スライス・ヘッダ・パケットのスライス・ヘッダデータから引き出されるパケットのスライスのためのペイロードデータに沿って、およびパケットのシーケンスのそれぞれのスライス・ヘッダ・パケットに続くが、１つ以上のペイロード・パケットが続くスライス・ヘッダ・パケットから引き出されるスライス・ヘッダを適用する１つ以上のペイロード・パケットのためのスライス・ヘッダをスキッピング、読み込みを行って、スライス・ヘッダを読むように構成される。

【0282】

上述した態様に関して本当であったので、パケットここではスライス・ヘッダ・パケットは、ＭＡＮＥまたはデコーダのようないかなるネットワークエンティティも、復号化ユニットの始まりまたはそれぞれのパケットによって前に置かれる１つ以上のペイロード・パケットの実行の始まりに指示する機能を有することもできる。したがって、現在の態様に従うネットワークエンティティは、スライス・ヘッダを読むことがｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｆｌａｇと結合してこのパケット、すなわち、ｓｉｎｇｌｅ＿ｓｌｉｃｅ＿ｆｌａｇの上述した構文要素に基づいて、例えば、スキップされなければならないペイロード・パケットを確認することができ、その中で、後のフラグは、上述のように、復号化ユニットの範囲内で特定のスライス・ヘッダ・パケットのコピーの再伝送を可能にする。たとえば、１つの復号化ユニットの範囲内のスライスのスライス・ヘッダがスライスのシーケンスに沿って変化することができるので、これは役立ち、したがって、復号化ユニットの初めのスライス・ヘッダ・パケットが（１に等しく）設定されるｄｅｃｏｄｉｎｇ＿ｕｎｉｔ＿ｓｔａｒｔ＿ｆｌａｇを有することができると共に、その間に配置されるスライス・ヘッダ・パケットは設定されないこのフラグを有することができ、いかなるネットワークエンティティも新しい復号化ユニットを始めることとして不正にこのスライス・ヘッダ・パケットの発生を読み取ることを防止する。

【0283】

いくつかの態様が装置の前後関係に記載されていたにもかかわらず、これらの態様も対応する方法の説明を表すことは明らかであり、ブロックまたは装置は、方法ステップまたは方法ステップの特徴に対応する。同様に、方法ステップの前後関係に記載されている態様は、対応する装置の対応するブロックまたは部材または特徴の説明を表す。いくつかのまたは全ての方法のステップは、ハードウェア装置、例えばマイクロプロセッサ、プログラム可能なコンピュータまたは電子回路（を用いること）によって実行されることができる。いくつかの実施形態では、最も重要な方法ステップの一つ以上は、この種の装置によって実行されることができる。

【0284】

発明のビデオ・データストリームは、デジタル記憶媒体に保存されることができ、またはワイヤレス伝送媒体またはインターネットなどの有線の伝送媒体のような伝送媒体上に送信されることができる。

【0285】

特定の実施要件に応じて、本発明の実施例は、ハードウェアにおいて、または、ソフトウェアで実施されることができる。実施はその上に格納される電子的に読み込み可能な制御信号を有するデジタル記憶媒体、例えばフレキシブルディスク、ＤＶＤ、ブルーレイ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリを使用して実行されることができ、それぞれの方法が実行されるように、それはプログラム可能なコンピュータシステムと協働する（または協働することができる）。したがって、デジタル記憶媒体は、計算機可読でもよい。

【0286】

本発明によるいくつかの実施例は、本願明細書において記載されている方法のうちの１つが実行されるように、プログラム可能なコンピュータシステムと協働することができる、電子的に読み込み可能な制御を有するデータキャリアは信号を有するデータキャリアを含む。

【0287】

通常、本発明の実施例は、コンピュータ・プログラム製品がコンピュータで動くときに、プログラムコードが方法のうちの１つを実行するための実施プログラムコードを有するコンピュータ・プログラム製品として実施されることができる。プログラムコードは、例えば、機械読み取り可読キャリアに格納されることができる。

【0288】

他の実施例は、本願明細書において記載されていて、機械読み取り可読キャリアに格納される方法のうちの１つを実行するためのコンピュータプログラムを含む。

【0289】

換言すれば、発明の方法の実施例は、従って、コンピュータプログラムがコンピュータで動くとき、本願明細書において記載されている方法のうちの１つを実行するためのプログラムコードを有するコンピュータプログラムである。

【0290】

発明の方法の更なる実施例は、従って、その上に記録されて、本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムから成っているデータキャリア（またはデジタル記憶媒体またはコンピュータ可読媒体）である。データキャリア、デジタル記憶媒体または記録媒体は、典型的には有形でおよび／または非移行である。

【0291】

発明の方法の更なる実施例は、従って、本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムを表しているデータストリームまたは信号のシーケンスである。データストリームまたは信号のシーケンスは、データ通信接続、例えばインターネットを介して転送されるように構成されることができる。

【0292】

更なる実施例は、本願明細書の方法の１つを実行するために適用されるように構成される処理手段、例えばコンピュータまたはプログラム可能な論理装置を含む。

【0293】

更なる実施例は、本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムをインストールしたコンピュータを含む。

【0294】

本発明による更なる実施例は、レシーバに本願明細書において記載されている方法のうちの１つを実行するためのコンピュータプログラムを伝達する（例えば、電子的に、または、光学的に）ように構成される装置またはシステムを含む。レシーバは、例えば、コンピュータ、モバイル機器、メモリデバイス等でもよい。装置またはシステムは、例えば、コンピュータプログラムを受取人に譲渡するためのファイル・サーバを含む。

【0295】

いくつかの実施形態では、プログラム可能な論理装置（例えばフィールド・プログラム可能なゲート・アレイ）は、本願明細書において記載されている方法の機能のいくらかまたは全てを実行するために用いることができる。いくつかの実施形態では、フィールド・プログラム可能なゲート・アレイは、本願明細書において記載されている方法のうちの１つを実行するために、マイクロプロセッサと協働することができる。通常、方法は、いかなるハードウェア装置によっても好ましくは実行される。

【0296】

上記した実施例は、本発明の原理のために、単に図示するだけである。
配置の修正変更および本願明細書において記載されている詳細が他の当業者にとって明らかであるものと理解される。
したがって、間近に迫った特許クレームの範囲だけによって制限されることが意図するところであり、本願明細書において実施例の説明および説明として示される具体的な詳細だけによって制限されることは意図していないところである。

【0297】

参照
[1] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, Ajay Luthra, "Overview of the H.264/AVC Video Coding Standard", IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, July 2003.

[2] JCT-VC, "High-Efficiency Video Coding (HEVC) text specification Working Draft 7", JCTVC-I1003, May 2012.

[3] ISO/IEC 13818-1: MPEG-2 Systems specification.

[4] IETF RFC 3550 − Real-time Transport Protocol.

[5] Y.-K. Wang et al. ,"RTP Payload Format for H.264 Video", IETF RFC6184, http://tools.ietf.org/html/

[6] S. Wenger et al., "RTP Payload Format for Scalable Video Coding", IETF RFC6190, http://tools.ietf.org/html/rfc6190

[6] T. Schierl et al., "RTP Payload Format for High Efficiency Video Coding", IETF internet draft, http://datatracker.ietf.org/doc/draft-schierl-payload-rtp-h265/

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10a】

【図10b】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23a】

【図23b】

【図23c】

【図24】

【図25a】

【図25b】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】