特表 2022-525166 ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-05-11

(54)【発明の名称】ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム

(51)【国際特許分類】

   H04N 19/70 20140101AFI20220428BHJP

   H04N 19/33 20140101ALI20220428BHJP

   H04N 21/234 20110101ALI20220428BHJP

【ＦＩ】

H04N19/70

H04N19/33

H04N21/234

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021555286

(86)(22)【出願日】2020-02-19

(85)【翻訳文提出日】2021-09-13

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

(87)【国際公開番号】W WO2020183055

(87)【国際公開日】2020-09-17

(31)【優先権主張番号】20195187

(32)【優先日】2019-03-14

(33)【優先権主張国・地域又は機関】FI

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．３ＧＰＰ

(71)【出願人】

【識別番号】515076873

【氏名又は名称】ノキア テクノロジーズ オサケユイチア

(74)【代理人】

【識別番号】100094569

【弁理士】

【氏名又は名称】田中 伸一郎

(74)【代理人】

【識別番号】100103610

【弁理士】

【氏名又は名称】▲吉▼田 和彦

(74)【代理人】

【識別番号】100109070

【弁理士】

【氏名又は名称】須田 洋之

(74)【代理人】

【識別番号】100067013

【弁理士】

【氏名又は名称】大塚 文昭

(74)【代理人】

【識別番号】100086771

【弁理士】

【氏名又は名称】西島 孝喜

(74)【代理人】

【識別番号】100109335

【弁理士】

【氏名又は名称】上杉 浩

(74)【代理人】

【識別番号】100120525

【弁理士】

【氏名又は名称】近藤 直樹

(74)【代理人】

【識別番号】100139712

【弁理士】

【氏名又は名称】那須 威夫

(72)【発明者】

【氏名】ハヌクセラ ミスカ

(72)【発明者】

【氏名】クルチオ イゴール

(72)【発明者】

【氏名】メイト スジット シャイアンスンダー

(72)【発明者】

【氏名】アクス エムレ

(72)【発明者】

【氏名】ホウルンランタ アリ

【テーマコード（参考）】

5C159

5C164

【Ｆターム（参考）】

5C159MA04

5C159MA05

5C159MA21

5C159MA32

5C159MC11

5C159ME01

5C159PP03

5C159PP13

5C159RC11

5C159UA02

5C159UA05

5C164SA32S

5C164SB01P

(57)【要約】

少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードすることを含み、第１の表現が、切替え可能相互コード化画像を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能画像が有し、第２の表現が、第１の表現の切替え可能画像と適合した１つまたは複数のデコーダリセット画像を含み、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１および第２の表現の分解能が等しい、方法。

【特許請求の範囲】

【請求項1】

少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードするステップ
を含み、
前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能相互コード化画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能画像が有し、
前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、
方法。

【請求項2】

少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードするための手段
を備え、
前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能相互コード化画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能画像が有し、
前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、
装置。

【請求項3】

前記切替え可能相互コード化画像が、デコード順でゼロ個以上前の切替え可能相互コード化画像から、および／または前のランダムアクセス画像からのみ、前記切替え可能相互コード化画像が予測されるという第２の特性を有する、請求項２に記載の装置。

【請求項4】

前記表現に対応する前記ビットストリームの中でまたはそれとともに、デコード時に前記表現の間の切替えに対する前記表現のコンテンツの適性を示すための手段
をさらに備える、請求項２または３に記載の装置。

【請求項5】

前記切替え可能相互コード化画像を周期的にコード化するための手段
をさらに備える、請求項２～４のいずれかに記載の装置。

【請求項6】

前記デコーダリセット画像が、ブロークンリンクアクセス（ＢＬＡ）画像の後に先頭画像がない前記ＢＬＡ画像タイプとして、または、インデペンデントデコーディングリフレッシュ（ＩＤＲ）画像としてエンコードされるように構成される、請求項２～５のいずれかに記載の装置。

【請求項7】

エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取るステップであって、前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能相互コード化画像が有する、ステップと、
前記少なくとも１つのビットストリームからまたはそれとともに、デコード時に前記第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取るステップであって、前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、ステップと、
前記第２の表現の少なくとも１つのデコーダリセット画像を受け取るステップと、
前記第１の表現の画像の前の前記第２の表現の前記少なくとも１つのデコーダリセット画像をデコードするステップと
を含む、方法。

【請求項8】

エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取るための手段であって、前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能相互コード化画像が有する、受け取るための手段と、
前記少なくとも１つのビットストリームからまたはそれとともに、デコード時に前記第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取るための手段であって、前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、受け取るための手段と、
前記第２の表現の少なくとも１つのデコーダリセット画像を受け取るための手段と、
前記第１の表現の画像の前の前記第２の表現の少なくとも１つのデコーダリセット画像をデコードするための手段と
を備える、装置。

【請求項9】

前記切替え可能相互コード化画像が、デコード順でゼロ個以上前の切替え可能相互コード化画像から、および／または前のランダムアクセス画像からのみ、前記切替え可能相互コード化画像が予測されるという第２の特性を有する、請求項８に記載の装置。

【請求項10】

前記デコードされた第１の表現の再生時の休止に応答して、前記第２の表現の前記少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項８または９に記載の装置。

【請求項11】

ビューポート切替えに応答して、前記第２の表現の前記少なくとも１つのデコーダリセットをリクエストするための手段
をさらに備える、請求項８または９に記載の装置。

【請求項12】

前記ビューポート切替えが、第１のビューポートから第２のビューポートへと行われ、前記第１の表現が、前記第１のビューポートをカバーし、前記装置が、
エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、前記第３の表現が、前記第２のビューポートを表す、受け取るための手段
をさらに備える、
請求項１１に記載の装置。

【請求項13】

視点切替えに応答して、前記第２の表現の前記少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項８または９に記載の装置。

【請求項14】

前記視点切替えが、第１の視点から第２の視点へと行われ、前記第１の表現が、前記第１の視点をカバーし、前記装置が、
エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、前記第３の表現が、前記第２の視点を表す、受け取るための手段
をさらに備える、請求項１３に記載の装置。

【請求項15】

前記再生の再開に応答して、前記再開に実質的にタイムリに対応するデコーダリセット画像をデコードするための手段と、
前記再開に実質的にタイムリに対応する前記デコーダリセット画像と一時的に適合した、前記第１の表現の切替え可能相互コード化画像の、デコード順で後にある前記第１の表現の画像をデコードすることに切り替えるための手段と
をさらに備える、請求項８～１４のいずれかに記載の装置。

【請求項16】

前記デコードされた第１の表現の再生時の休止に応答して、デコーダバッファサイズおよび／または利用可能な帯域幅の制限に応じて、前記第２の表現の複数のデコーダリセット画像をリクエストするための手段
をさらに備える、請求項８～１５のいずれかに記載の装置。

【請求項17】

前記第１の表現と第３の表現との間のビットレート適合を実行するために、前記第２の表現の少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項８～１６のいずれかに記載の装置。

【請求項18】

前記ビットレート切替えが、第１のビットレートから第２のビットレートへと行われ、前記第１の表現が前記第１のビットレートをカバーし、前記装置が、
エンコードされたビデオメディアコンテンツの前記第３の表現に対応する第２のビットストリームを受け取るための手段であって、前記第３の表現が、前記第２のビットレートを表す、受け取るための手段
をさらに備える、
請求項１７に記載の装置。

【請求項19】

第１のエクストラクタトラックまたは表現から前記少なくとも１つの切替え可能相互コード化画像を抽出するための手段と、
第２のエクストラクタトラックまたは表現から前記少なくとも１つのデコーダリセット画像を抽出するための手段と
をさらに備える、請求項８～１８のいずれかに記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラムに関する。

【背景技術】

【0002】

最近、様々なマルチメディアストリーミングアプリケーション、特に３６０度ビデオまたは仮想現実（ＶＲ：ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ）アプリケーションの開発は、大きく進歩してきた。ビューポート対応ストリーミングでは、例えば、主要なビューポート（すなわち、現在の鑑賞方向）が、最高品質／分解能で伝送される一方で、３６０度ビデオの残りが、より低い品質／分解能で伝送されるように、ビットレートを低減することを目標とする。鑑賞方向が変わるとき、例えば、ヘッドマウントディスプレイ（ＨＭＤ：ｈｅａｄ－ｍｏｕｎｔｅｄ ｄｉｓｐｌａｙ）でコンテンツを鑑賞しているときに、ユーザが自分の頭を回転させると、新しい鑑賞方向にマッチするコンテンツの別のバージョンをストリームする必要がある。

【0003】

ストリーミングセッション中、ユーザは、いつでも再生を休止することができる。再生を休止したとき、再生を休止した後、ユーザは辺りを見回し、ビューポートの外側に行くことができる。このようなケースでは、ビューポート外の領域は、より低い品質／分解能になる。この現象は、ユーザ体感をかなり悪化させる。休止状態にある間、全３６０度球体を高品質に表示するのに十分な帯域幅および時間があるが、現在の３６０度球体のフレームインスタンスを効率的に検索／デコード／再生するためのシグナリングメカニズムがない。その上、高分解能の完全な３６０度画像は、デコード能力を超える可能性がある。

【発明の概要】

【0004】

ここで、上記の問題を少なくとも緩和するために、デコーダの再生休止中のコンテンツ検索のための拡張された方法を本明細書で紹介する。

【0005】

第１の態様による方法は、少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードすることを含み、第１の表現が、切替え可能相互コード化画像（ｓｗｉｔｃｈａｂｌｅ ｉｎｔｅｒ－ｃｏｄｅｄ ｐｉｃｔｕｒｅ）を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能画像が有し、第２の表現が、第１の表現の切替え可能画像と適合した１つまたは複数のデコーダリセット画像を含み、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１と第２の表現の分解能が等しい。

【0006】

第２の態様による装置は、少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードするための手段を備え、第１の表現が、切替え可能相互コード化画像を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能画像が有し、第２の表現が、第１の表現の切替え可能画像と適合した１つまたは複数のデコーダリセット画像を含み、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１と第２の表現の分解能が等しい。

【0007】

１つの実施形態によれば、切替え可能画像は、デコード順でゼロ個以上前の切替え可能相互コード化画像から、および／または前のランダムアクセス画像からのみ、切替え可能画像が予測されるという第２の特性を有する。

【0008】

１つの実施形態によれば、装置は、表現を含むビットストリームの中でまたはそれとともに、デコード時に表現の間の切替えに対する表現のコンテンツの適性を示すための手段をさらに備える。

【0009】

１つの実施形態によれば、装置は、切替え可能相互コード化画像を周期的にコード化するための手段をさらに備える。

【0010】

１つの実施形態によれば、デコーダリセット画像は、ブロークンリンクアクセス（ＢＬＡ：Ｂｒｏｋｅｎ Ｌｉｎｋ Ａｃｃｅｓｓ）画像の後に先頭画像がないＢＬＡ画像タイプとして、または、インデペンデントデコーディングリフレッシュ（ＩＤＲ：Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｃｏｒｄｉｎｇ Ｒｅｆｒｅｓｈ）画像としてエンコードされるように構成される。

【0011】

第３の態様による方法は、エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取ることであって、第１の表現が、切替え可能相互コード化画像を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能画像が有する、受け取ることと、少なくとも１つのビットストリームからまたはそれとともに、デコード時に第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取ることであって、第２の表現が、第１の表現の切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１と第２の表現の分解能が等しい、受け取ることと、第２の表現の少なくとも１つのデコーダリセット画像を受け取ることと、第１の表現の画像の前の第２の表現の少なくとも１つのデコーダリセット画像をデコードすることと、を含む。

【0012】

第４の態様による装置は、エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取るための手段であって、第１の表現が、切替え可能相互コード化画像を含み、デコード順で切替え可能画像の前にある画像が、デコード順で切替え可能画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能画像が有する、受け取るための手段と、少なくとも１つのビットストリームからまたはそれとともに、デコード時に第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取るための手段であって、第２の表現が、第１の表現の切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１と第２の表現の分解能が等しい、受け取るための手段と、第２の表現の少なくとも１つのデコーダリセット画像を受け取るための手段と、第１の表現の画像の前の第２の表現の少なくとも１つのデコーダリセット画像をデコードするための手段と、を備える。

【0013】

１つの実施形態によれば、装置は、デコードされた第１の表現の再生時の休止に応答して、第２の表現の少なくとも１つのデコーダリセット画像をリクエストするための手段をさらに備える。

【0014】

１つの実施形態によれば、装置は、ビューポート切替えに応答して、第２の表現の少なくとも１つのデコーダリセットをリクエストするための手段をさらに備える。

【0015】

１つの実施形態によれば、ビューポート切替えは、第１のビューポートから第２のビューポートへと行われ、第１の表現は、第１のビューポートをカバーし、装置は、エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、第３の表現が、第２のビューポートを表す、受け取るための手段をさらに備える。

【0016】

１つの実施形態によれば、装置は、視点切替えに応答して、第２の表現の少なくとも１つのデコーダリセットをリクエストするための手段をさらに備える。

【0017】

１つの実施形態によれば、視点切替えは、第１の視点から第２の視点へと行われ、第１の表現が、第１の視点をカバーし、装置は、エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、第３の表現が、第２の視点を表す、受け取るための手段をさらに備える。

【0018】

１つの実施形態によれば、装置は、再生の再開に応答して、再開に実質的にタイムリに対応するデコーダリセット画像をデコードするための手段と、再開に実質的にタイムリに対応するデコーダリセット画像と一時的に適合した、第１の表現の切替え可能相互コード化画像の、デコード順で後にある第１の表現の画像をデコードすることに切り替えるための手段とをさらに備える。

【0019】

１つの実施形態によれば、装置は、デコードされた第１の表現の再生時の休止に応答して、デコーダバッファサイズおよび／または利用可能な帯域幅の制限に応じて、第２の表現の複数のデコーダリセット画像をリクエストするための手段をさらに備える。

【0020】

１つの実施形態によれば、装置は、第１の表現と第３の表現との間のビットレート適合を実行するために、第２の表現の少なくとも１つのデコーダリセット画像をリクエストするための手段をさらに備える。

【0021】

１つの実施形態によれば、ビットレート切替えは、第１のビットレートから第２のビットレートへと行われ、第１の表現が第１のビットレートをカバーし、装置は、エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、第３の表現が、第２のビットレートを表す、受け取るための手段をさらに備える。

【0022】

１つの実施形態によれば、装置は、第１のエクストラクタトラックまたは表現から少なくとも１つの切替え可能相互コード化画像を抽出するための手段と、第２のエクストラクタトラックまたは表現から少なくとも１つのデコーダリセット画像を抽出するための手段とをさらに備える。

【0023】

さらなる態様は、上記の方法、および上記の方法に関する実施形態の１つまたは複数を実行するように配置された装置、およびコードを格納したコンピュータ可読ストレージ媒体に関する。

【0024】

本発明のより良い理解のために、添付の図面を例としてここで参照する。

【図面の簡単な説明】

【0025】

【図1】本発明の実施形態を採用する電子デバイスを概略的に示す図である。

【図2】本発明の実施形態を採用するのに適したユーザ機器を概略的に示す図である。

【図3】ワイヤレスおよび有線ネットワーク接続を使用して接続された、本発明の実施形態を採用する電子デバイスをさらに概略的に示す図である。

【図4】本発明の実施形態を実行するのに適したエンコーダを概略的に示す図である。

【図5】ＭＰＥＧ全方向メディアフォーマット（ＯＭＡＦ：Ｏｍｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｅｄｉａ Ｆｏｒｍａｔ）概念の例を示す図である。

【図6a】エンコーディングのために２Ｄパック画像に３６０度ビデオコンテンツをパッキングするための２つの代替方法を示す図である。

【図6b】エンコーディングのために２Ｄパック画像に３６０度ビデオコンテンツをパッキングするための２つの代替方法を示す図である。

【図7】モノスコーピックエクイレクタングラパノラマ画像を形成する処理を示す図である。

【図8】ＯＭＡＦの座標系の例を示す図である。

【図9】パック２Ｄ画像に球体画像をコンバートする例を示す図である。

【図10】本発明の１つの実施形態によるエンコード方法の流れ図である。

【図11】本発明の１つの実施形態によるエンコード制限の例を示す図である。

【図12】本発明の１つの実施形態に、表現間の切替えポイントをシグナリングする例を示す図である。

【図13】本発明の１つの実施形態によるデコード方法の流れ図である。

【図14】本発明の実施形態を実行するのに適したデコーダの概略図である。

【図15】様々な実施形態を実行することができる実例のマルチメディア通信システムの概略図である。

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

【0026】

以下は、ビューポート対応ストリーミングのための適切な装置および可能なメカニズムをさらに詳細に説明する。この点に関して、図１および図２を最初に参照し、ここで、図１は、本発明の１つの実施形態によるコーデックを組み込むことができる、例示的な装置または電子デバイス５０の概略ブロック図として、実例の実施形態によるビデオコーディングシステムのブロック図を示す。図２は、実例の実施形態による装置のレイアウトを示す。図１および図２の要素を次に説明する。

【0027】

電子デバイス５０は、例えば、ワイヤレス通信システムのモバイル端末またはユーザ機器であってもよい。それでも、本発明の実施形態は、ビデオイメージをエンコードおよびデコードすること、またはエンコードもしくはデコードすることを必要とし得る任意の電子デバイスまたは装置内で実行できることが理解されよう。

【0028】

装置５０は、デバイスを組み込み、保護するための筐体３０を備えることができる。装置５０は、液晶ディスプレイの形のディスプレイ３２をさらに備えることができる。本発明の他の実施形態では、ディスプレイは、イメージまたはビデオを表示するのに適した任意の適切なディスプレイ技術であってもよい。装置５０は、キーパッド３４をさらに備えることができる。本発明の他の実施形態では、任意の適切なデータまたはユーザインターフェースメカニズムを採用することができる。例えば、ユーザインターフェースは、タッチセンサ式ディスプレイの一部として仮想キーボードまたはデータエントリシステムとして実行することができる。

【0029】

装置は、デジタルまたはアナログ信号入力であってもよいマイクロフォン３６または任意の適切なオーディオ入力を備えることができる。装置５０は、オーディオ出力デバイスをさらに備えることができ、オーディオ出力デバイスは、本発明の実施形態では、イヤホン３８、スピーカ、または、アナログオーディオもしくはデジタルオーディオ出力接続のいずれかの１つであってもよい。装置５０は、バッテリも備えることができる（または本発明の他の実施形態では、デバイスは、太陽電池、燃料電池、もしくはクロックワークジェネレータなどの、任意の適切なモバイルエネルギーデバイスで電力供給することができる）。装置は、イメージおよび／またはビデオを記録またはキャプチャできるカメラをさらに備えることができる。装置５０は、他のデバイスへの短距離見通し内通信のための赤外線ポートをさらに備えることができる。他の実施形態では、装置５０は、例えば、Ｂｌｕｅｔｏｏｔｈワイヤレス接続またはＵＳＢ／ファイヤワイヤ有線接続などの、任意の適切な短距離通信ソリューションをさらに備えることができる。

【0030】

装置５０は、装置５０を制御するためのコントローラ５６、プロセッサ、またはプロセッサ回路機器を備えることができる。コントローラ５６は、メモリ５８に接続することができ、メモリ５８は、本発明の実施形態では、イメージデータとオーディオデータの形で両方のデータを格納することができ、かつ／または、コントローラ５６での実行のための命令も格納することができる。コントローラ５６は、オーディオおよび／もしくはビデオデータのコーディングおよびデコーディングを実行すること、または、コントローラによって実行されるコーディングおよびデコーディングを支援することに適したコーデック回路機器５４にさらに接続することができる。

【0031】

装置５０は、ユーザ情報を提供するための、ならびに、ネットワークにおけるユーザの認証および権限付与のための認証情報を提供するのに適した、例えば、ＵＩＣＣおよびＵＩＣＣリーダといった、カードリーダ４８およびスマートカード４６をさらに備えることができる。

【0032】

装置５０は、コントローラに接続され、例えば、セルラー通信ネットワーク、ワイヤレス通信システム、またはワイヤレスローカルエリアネットワークとの通信のための、ワイヤレス通信信号を生成するのに適した、無線インターフェース回路機器５２を備えることができる。装置５０は、無線インターフェース回路機器５２で生成された無線周波数信号を他の装置に伝送するための、および、他の装置から無線周波数信号を受け取るための、無線インターフェース回路機器５２に接続されたアンテナ４４をさらに備えることができる。

【0033】

装置５０は、個々のフレームを記録または検出できるカメラを備えることができ、個々のフレームは、その後、処理のためにコーデック５４またはコントローラに渡される。装置は、伝送および／または格納の前に、別のデバイスから、処理のためのビデオイメージデータを受け取ることができる。装置５０は、コーディング／デコーディングのためのイメージも、ワイヤレスで、または有線接続で受け取ることができる。上記で説明された装置５０の構造要素は、対応する機能を実施するための手段の例を表す。

【0034】

図３について、本発明の実施形態を利用できるシステムの例を示す。システム１０は、１つまたは複数のネットワークを通じて通信できる複数の通信デバイスを備える。システム１０は、（ＧＳＭ、ＵＭＴＳ、ＣＤＭＡネットワーク等などの）ワイヤレスセルラー電話ネットワーク、ＩＥＥＥ８０２．ｘ規格のいずれかによって定義されたものなどのワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、Ｂｌｕｅｔｏｏｔｈパーソナルエリアネットワーク、イーサネットローカルエリアネットワーク、トークンリングローカルエリアネットワーク、広域ネットワーク、およびインターネットを含むがこれらに限定されない、有線またはワイヤレスネットワークの任意の組合せを備えることができる。

【0035】

システム１０は、本発明の実施形態を実行するのに適した有線とワイヤレス両方の通信デバイス、および／または装置５０を含むことができる。

【0036】

例えば、図３に示されているシステムは、携帯電話ネットワーク１１、およびインターネット２８の表現を示す。インターネット２８への接続は、長距離ワイヤレス接続、短距離ワイヤレス接続、ならびに、電話線、ケーブル線、電力線、および同様の通信経路を含むがこれらに限定されない様々な有線接続を含むことができるがこれらに限定されない。

【0037】

システム１０に示した実例の通信デバイスは、電子デバイスまたは装置５０、パーソナルデジタルアシスタント（ＰＤＡ）と携帯電話１４の組合せ、ＰＤＡ１６、統合型メッセージングデバイス（ＩＭＤ）１８、デスクトップコンピュータ２０、ノートブックコンピュータ２２を含むことができるがこれらに限定されない。装置５０は、据置型、または、移動している個人によって搬送されるとき、モバイルであってもよい。装置５０は、車、トラック、タクシー、バス、列車、ボート、飛行機、自転車、モータサイクル、または、輸送の任意の同様の適切なモードを含むがこれらに限定されない輸送のモードでも位置することができる。

【0038】

実施形態は、ディスプレイまたはワイヤレス能力を備えても備えなくてもよいセットトップボックス、すなわちデジタルＴＶ受像器でも、エンコーダ／デコーダ実装形態のハードウェアもしくはソフトウェア、または組合せを備えるタブレットまたは（ラップトップ）パーソナルコンピュータ（ＰＣ）でも、様々なオペレーティングシステムでも、ならびに、ハードウェア／ソフトウェアベースのコーディングを提供するチップセット、プロセッサ、ＤＳＰ、および／または組込型システムでも、実行することができる。

【0039】

いくつかのまたはさらなる装置は、コールおよびメッセージを送ること、および受け取ること、ならびに、基地局２４へのワイヤレス接続２５を通じて、サービスプロバイダと通信することができる。基地局２４は、携帯電話ネットワーク１１とインターネット２８との間の通信を可能にするネットワークサーバ２６に接続することができる。システムは、追加の通信デバイス、および様々なタイプの通信デバイスを含むことができる。

【0040】

通信デバイスは、符号分割多元接続（ＣＤＭＡ）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）、ユニバーサル移動体通信システム（ＵＭＴＳ）、時間分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、トランスミッションコントロールプロトコル－インターネットプロトコル（ＴＣＰ－ＩＰ）、ショートメッセージングサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、ｅメール、インスタントメッセージングサービス（ＩＭＳ）、Ｂｌｕｅｔｏｏｔｈ、ＩＥＥＥ８０２．１１、および任意の同様のワイヤレス通信技術を含むがこれらに限定されない様々な伝送技術を使用して通信することができる。様々な本発明の実施形態を実行するのに関与する通信デバイスは、無線、赤外線、レーザ、ケーブル接続、および任意の適切な接続を含むがこれらに限定されない様々な媒体を使用して通信することができる。

【0041】

テレコミュニケーションおよびデータネットワークでは、チャネルは、物理チャネルまたは論理チャネルを指すことができる。物理チャネルは、ワイヤなどの物理伝送媒体を指すことができ、その一方で、論理チャネルは、いくつかの論理チャネルを伝えることができる多重化媒体での論理接続を指すことができる。チャネルは、１つまたはいくつかのセンダ（またはトランスミッタ）から１つまたはいくつかのレシーバに、例えばビットストリームといった情報信号を伝えるために使用することができる。

【0042】

ＭＰＥＧ－２トランスポートストリーム（ＴＳ：ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）は、ＩＳＯ／ＩＥＣ１３８１８－１で、または同等に、ＩＴＵ－Ｔ勧告Ｈ．２２２．０で指定され、多重化ストリームで、オーディオ、ビデオ、および他のメディア、ならびに、プログラムメタデータまたは他のメタデータを搬送するためのフォーマットである。パケット識別子（ＰＩＤ：ｐａｃｋｅｔ ｉｄｅｎｔｉｆｉｅｒ）は、ＴＳ内のエレメンタリストリーム（別名、パケット化エレメンタリストリーム）を識別するために使用される。したがって、ＭＰＥＧ－２ ＴＳ内の論理チャネルは、固有のＰＩＤ値に対応するものとみなすことができる。

【0043】

利用可能なメディアファイルフォーマット規格は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ １４４９６－１２、これは、ＩＳＯＢＭＦＦと略すことができる）、および、ＩＳＯＢＭＦＦから導出するＮＡＬユニット構造化ビデオ（ＩＳＯ／ＩＥＣ １４４９６－１５）のためのファイルフォーマットを含む。

【0044】

コンテナファイルフォーマットの例として、ＩＳＯＢＭＦＦのいくつかの概念、構造、および仕様を下記で説明し、コンテナファイルフォーマットに基づいて、実施形態を実行することができる。本発明の態様は、ＩＳＯＢＭＦＦに限定されず、むしろ、本発明を部分的または完全に実現できる１つの可能な基礎について説明される。

【0045】

ＩＳＯベースメディアファイルフォーマットにおける基本的なビルディングブロックは、ボックスと呼ばれる。各ボックスは、ヘッダおよびペイロードを含む。ボックスヘッダは、ボックスのタイプ、およびバイトでのボックスのサイズを示す。ボックスは、他のボックスを含めることができ、ＩＳＯファイルフォーマットは、一定のタイプのボックス内でどのボックスタイプが許容されるかを指定する。さらに、いくつかのボックスの存在は、各ファイルにおいて必須であってもよい一方で、他のボックスの存在は、任意選択であってもよい。追加として、いくつかのボックスタイプについて、ファイル内に存在する２つ以上のボックスを含むことを許容できる。このように、ＩＳＯベースメディアファイルフォーマットは、ボックスの階層構造を指定するものとみなすことができる。

【0046】

ファイルフォーマットのＩＳＯファミリによれば、ファイルは、ボックスにカプセル化されたメディアデータおよびメタデータを含む。各ボックスは、４キャラクタコード（４ＣＣ）で識別され、ボックスのタイプおよびサイズを知らせるヘッダで始まる。

【0047】

ＩＳＯベースメディアファイルフォーマットに準拠するファイルでは、メディアデータは、メディアデータ‘ｍｄａｔ’ボックス内で提供することができ、ムービー‘ｍｏｏｖ’ボックスは、メタデータを含めるために使用することができる。場合によっては、ファイルを動作可能にするために、‘ｍｄａｔ’ボックスと‘ｍｏｏｖ’ボックスの両方が存在することが必要になることがある。ムービー‘ｍｏｏｖ’ボックスは、１つまたは複数のトラックを含むことができ、各トラックは、１つの対応するトラック‘ｔｒａｋ’ボックス内にあってもよい。トラックは、メディア圧縮フォーマット（および、ＩＳＯベースメディアファイルフォーマットへのメディア圧縮フォーマットのカプセル化）に応じてフォーマットされたサンプルを指すメディアトラックを含む多くのタイプの１つであってもよい。

【0048】

ムービーフラグメントは、例えば、レコーディングアプリケーションがクラッシュする、メモリ空間を使い果たす、または他の何らかの事故が発生した場合に、データを失わないように、例えばＩＳＯファイルにコンテンツを記録するときに、使用することができる。ムービーフラグメントがないと、ファイルの１つの連続エリア内に、例えばムービーボックスといった、全てのメタデータが書かれることをファイルフォーマットが必要とする可能性があるので、データ喪失が発生する可能性がある。さらに、ファイルを記録するとき、利用可能なストレージのサイズに対してムービーボックスをバッファするのに十分な量のメモリ空間（例えば、ランダムアクセスメモリＲＡＭ）がないことがあり、ムービーを閉じたときにムービーボックスのコンテンツの再計算が、非常に遅くなることがある。その上、ムービーフラグメントは、通常のＩＳＯファイルパーサを使用して、ファイルの同時の記録および再生を可能にすることができる。さらに、最初のバッファ期間が短くなると、ムービーフラグメントが使用されるときに、例えばファイルの同時受信および再生といった、先行ダウンロードが必要になることがあり、最初のムービーボックスは、同じメディアコンテンツを含むが、ムービーフラグメントなしで構築されたファイルと比較して、小さくなる。

【0049】

ムービーフラグメント機能は、そうでなければムービーボックスの中にある可能性があるメタデータを、複数の部分に分割することを可能にすることができる。各部分は、トラックの一定期間に対応させることができる。言い換えれば、ムービーフラグメント機能は、ファイルメタデータおよびメディアデータをインターリーブすることを可能にすることができる。必然的に、ムービーボックスのサイズを制限し、上記で言及したユースケースを実現することができる。

【0050】

いくつかの例では、ムービーフラグメントについてのメディアサンプルは、ｍｏｏｖボックスと同じファイル内にある場合、ｍｄａｔボックス内にあってもよい。それでも、ムービーフラグメントのメタデータに、ｍｏｏｆボックスが提供されてもよい。ｍｏｏｆボックスは、以前、ｍｏｏｖボックス内にあった、一定期間の再生時間についての情報を含むことができる。ｍｏｏｖボックスは、有効なムービーをそれ自体でさらに表すことができるが、さらに、同じファイル内の、ムービーフラグメントが続くことを示すｍｖｅｘボックスを含むことができる。ムービーフラグメントは、結局ｍｏｏｖボックスに関連付けられる存在を拡張することができる。

【0051】

ムービーフラグメント内には、トラックあたりゼロから複数までのどこにでも含むトラックフラグメントのセットがあってもよい。トラックフラグメントは、今度は、実行するゼロから複数のトラックまでのどこにでも含むことができ、このドキュメントのそれぞれが、このトラックについてのサンプルの連続した実行である。これらの構造内で、多くのフィールドが任意選択であり、デフォルトにすることができる。ｍｏｏｆボックスに含むことができるメタデータは、ｍｏｏｖボックスに含むことができるメタデータのサブセットに限定することができ、場合によっては、それぞれにコード化することができる。ｍｏｏｆボックスに含むことができるボックスに関する詳細は、ＩＳＯベースメディアファイルフォーマット仕様から見つけることができる。自己完結型ムービーフラグメントは、ファイル順で連続的なｍｏｏｆボックスおよびｍｄａｔボックスからなるように定義することができ、ここで、ｍｄａｔボックスは、（ｍｏｏｆボックスがメタデータを提供する）ムービーフラグメントのサンプルを収め、他の任意のムービーフラグメントのサンプル（すなわち、他の任意のｍｏｏｆボックス）を収めない。

【0052】

トラック参照メカニズムは、トラックを互いに関連付けるために使用することができる。ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘは、ボックスを含み、ボックスのそれぞれは、収めるトラックから他のトラックのセットへの参照を提供する。これらの参照は、収められたボックスのボックスタイプ（すなわち、ボックスの４キャラクタコード）でラベル付けされる。シンタックスは、以下のように指定することができる。
ａｌｉｇｎｅｄ（８） ｃｌａｓｓ ＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘ ｅｘｔｅｎｄｓ Ｂｏｘ（‘ｔｒｅｆ’） ｛
ＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘ ［］；
｝
ａｌｉｇｎｅｄ（８） ｃｌａｓｓ ＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘ （ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ） ｅｘｔｅｎｄｓ Ｂｏｘ（ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｔｒａｃｋ＿ＩＤｓ［］；
｝

【0053】

ｔｒａｃｋ＿ＩＤｓは、参照トラックのトラック識別子、または参照トラックグループのｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値を提供する整数の配列として指定することができる。ｉがｔｒａｃｋ＿ＩＤｓ［］配列に対する有効なインデックスであるｔｒａｃｋ＿ＩＤｓ［ｉ］の各値は、収めるトラックから、ｔｒａｃｋ＿ＩＤｓ［ｉ］に等しいｔｒａｃｋ＿ＩＤのトラックへの、または、ｔｒａｃｋ＿ＩＤｓ［ｉ］に等しいｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄと、１に等しいＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘのｆｌａｇｓフィールドの特定のビット（例えば最下位ビット）との両方を伴うトラックグループへの、参照を提供する整数である。ｔｒａｃｋ＿ｇｒｏｕｐ＿ｉｄ値が参照されるとき、トラック参照は、特定のトラック参照タイプの意味で別途述べられない限り、参照トラックグループの各トラックに個別に適用される。値０は、存在を許容されないこともある。

【0054】

トラックグルーピングメカニズムは、トラックのグループの指示を可能にし、ここで、各グループは、特定の特性を共有するか、またはグループ内のトラックには、特定の関係がある。ＴｒａｃｋＧｒｏｕｐＢｏｘは、ＴｒａｃｋＢｏｘに収めることができる。ＴｒａｃｋＧｒｏｕｐＢｏｘは、ＴｒａｃｋＧｒｏｕｐＴｙｐｅＢｏｘから導出されたゼロ個以上のボックスを収める。特定の特性または関係は、収められたボックスのボックスタイプによって示される。収められたボックスは、識別子を含み、識別子は、同じトラックグループに属すトラックを推論するために使用することができる。収められたボックスの同じタイプをＴｒａｃｋＧｒｏｕｐＢｏｘ内に収め、これらの収められたボックス内に同じ識別子の値を保持するトラックは、同じトラックグループに属す。

【0055】

ＩＳＯベースメディアファイルフォーマットは、サンプルグループ、時限メタデータトラック、およびサンプル補助情報という、特定のサンプルに関連付けることができる時限メタデータについての３つのメカニズムを収める。導出された仕様は、これらの３つのメカニズムの１つまたは複数を同様の機能に提供することができる。

【0056】

ＡＶＣファイルフォーマットおよびＳＶＣファイルフォーマットなどの、ＩＳＯベースメディアファイルフォーマットおよびその派生語におけるサンプルグルーピングは、グルーピング基準に基づいて、１つのサンプルグループのメンバになるようなトラック内の各サンプルの割当てと定義することができる。サンプルグルーピングにおけるサンプルグループは、連続サンプルであることに限定されず、非隣接サンプルを収めることができる。トラック内のサンプルに対して、２つ以上のサンプルグルーピングであり得るので、各サンプルグルーピングは、グルーピングのタイプを示すためにｔｙｐｅフィールドを含むことができる。サンプルグルーピングは、２つのリンクしたデータ構造によって表すことができ、すなわち、（１）ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘ（ｓｂｇｐボックス）は、サンプルグループへのサンプルの割当てを表し、（２）ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘ（ｓｇｐｄボックス）は、グループのプロパティを記述する各サンプルグループについてのサンプルグループエントリを収める。異なるグルーピング基準に基づいた、ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘおよびＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＢｏｘの複数のインスタンスがあり得る。これらは、グルーピングのタイプを示すために使用されるｔｙｐｅフィールドで区別することができる。ＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘは、例えばグルーピングのサブタイプを示すために、使用することができるｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒフィールドを含むことができる。

【0057】

ＩＳＯベースメディアファイルフォーマット規格に対する修正案は、以下のようなコンパクトなサンプル対グループのマッピングを説明する。

【0058】

ボックスタイプ：‘ｃｓｇｐ’
コンテナ：ＳａｍｐｌｅＴａｂｌｅＢｏｘまたはＴｒａｃｋＦｒａｇｍｅｎｔＢｏｘ
必須：なし
量：ゼロ以上

【0059】

コンパクトなサンプル対グループボックスは、特に、繰り返しているパターンがある場合、および、特定のタイプのサンプルグループがほとんどないとき、サンプルからグループへのマッピングを表すための、よりコンパクトな方式を提供する。

【0060】

設計は、それぞれがマッピング配列によって一回使用される、結合されたパターンのベクトルを使用し、マッピング配列は、このパターンの繰返しにサンプルの実行を関連付ける。これは、以下の例で示される。以下では、各文字は、異なるサンプルグループ記述インデックス値（場合によっては０）を表す。

【0061】

トラックに以下の関連付けがある場合、第１のサンプルから始まる。

【0062】

ａ ｂ ｃ ｂ ａ ｂ ｃ ｂ ａ ｂ ｃ ｘ ｘ ａ ｂ ｃ ｂ ａ ｂ ｄ ｂ

【0063】

これらの関連付けは、以下で表されてもよい。
１． ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ＝４；ｓａｍｐｌｅ＿ｃｏｕｎｔ＝１１；
２． ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ＝１；ｓａｍｐｌｅ＿ｃｏｕｎｔ＝２；
３． ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ＝４；ｓａｍｐｌｅ＿ｃｏｕｎｔ＝６；
４． ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ＝２；ｓａｍｐｌｅ＿ｃｏｕｎｔ＝２；
ｐａｔｔｅｒｎ＝［
ａ ｂ ｃ ｂ ／／長さ４のパターン１
ｘ ／／長さ１のパターン２
ａ ｂ ｃ ｂ ／／長さ４のパターン３
ｄ ｂ ／／長さ２のパターン４
］ ／／ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈは、したがって、４＋１＋４＋２＝１１である。

【0064】

ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］がｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｉ］に等しいとき、パターンは、繰り返されない。

【0065】

ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］が、ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｉ］より大きいとき、ｉ番目のパターンのｓａｍｐｌｅ＿ｇｒｏｕｐ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｉｎｄｅｘ値が、ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］値をマップするために繰り返し使用される。これは、必ずしも、ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］がｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｉ］の倍数であるケースではなく、サイクルは、パターンの途中で終了してもよい。

【0066】

１以上ｐａｔｔｅｒｎ＿ｃｏｕｎｔ以下の範囲内でのｉの全ての値についてのｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］値のトータルが、トータルサンプルカウントより小さいとき、リーダは、もしあれば、ＳａｍｐｌｅＤｅｓｃｒｉｐｔｉｏｎＧｒｏｕｐＢｏｘにおいて定義されたデフォルトグループとの明示的なグループの関連付けのないサンプルを関連付けるべきであり、なければグループと関連付けない。

【0067】

ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］値のトータルが、包含するＴｒａｃｋＢｏｘまたはＴｒａｃｋＦｒａｇｍｅｎｔＢｏｘによって記述された実際のサンプルのトータルカウントより大きいのはエラーであり、リーダの挙動は、その後、定義されない。

【0068】

シンタックス：
ａｌｉｇｎｅｄ（８） ｃｌａｓｓ ＣｏｍｐａｃｔＳａｍｐｌｅＴｏＧｒｏｕｐＢｏｘ
ｅｘｔｅｎｄｓ ＦｕｌｌＢｏｘ（‘ｃｓｇｐ’， ｖｅｒｓｉｏｎ， ０）
｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ； ｕｎｓｉｇｎｅｄ ｉｎｔ（１） ｉｎｄｅｘ＿ｍｓｂ＿ｉｎｄｉｃａｔｅｓ＿ｆｒａｇｍｅｎｔ＿ｌｏｃａｌ＿ｄｅｓｃｒｉｐｔｉｏｎ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（１） ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒ＿ｐｒｅｓｅｎｔ；
ｕｎｓｉｇｎｅｄ ｉｎｔ（６） ｆｉｅｌｄ＿ｓｉｚｅ＿ｍｉｎｕｓ＿１；
ｉｆ （ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒ＿ｐｒｅｓｅｎｔ ＝＝ １） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｇｒｏｕｐｉｎｇ＿ｔｙｐｅ＿ｐａｒａｍｅｔｅｒ；
｝
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｐａｔｔｅｒｎ＿ｃｏｕｎｔ；
ｔｏｔａｌＰａｔｔｅｒｎＬｅｎｇｔｈ＝０；
ｆｏｒ （ｉ＝１； ｉ ＜＝ ｐａｔｔｅｒｎ＿ｃｏｕｎｔ； ｉ＋＋） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｉ］；
ｕｎｓｉｇｎｅｄ ｉｎｔ（３２） ｓａｍｐｌｅ＿ｃｏｕｎｔ［ｉ］；
ｔｏｔａｌＰａｔｔｅｒｎＬｅｎｇｔｈ ＋＝ ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｉ］；
｝
ｆｏｒ （ｊ＝１； ｊ ＜＝ ｐａｔｔｅｒｎ＿ｃｏｕｎｔ； ｊ＋＋） ｛
ｆｏｒ （ｋ＝１； ｋ ＜＝ ｐａｔｔｅｒｎ＿ｌｅｎｇｔｈ［ｊ］； ｋ＋＋） ｛
ｕｎｓｉｇｎｅｄ ｉｎｔ（ｆｉｅｌｄ＿ｓｉｚｅ） ｓａｍｐｌｅ＿ｇｒｏｕｐ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｉｎｄｅｘ［ｊ］［ｋ］；
／／このｍｓｂは、ｆｒａｇｍｅｎｔ＿ｌｏｃａｌまたはｇｌｏｂａｌを示すことができる。
｝
｝
｝

【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】

ＨＥＶＣでは、画像は、タイルに区画化することができ、長方形であり、整数のＬＣＵを収める。ＨＥＶＣでは、タイルへの区画化は、規則的なグリッドを形成し、ここで、タイルの高さおよび幅は、最大で１つのＬＣＵごとに互いに異なる。ＨＥＶＣでは、スライスは、１つの独立スライスセグメントと、同じアクセスユニット内の（もしあれば）次の独立スライスセグメントの前にある（もしあれば）全てのその後の従属スライスセグメントと、に収められた整数のコーディングツリーユニットであると定義される。ＨＥＶＣでは、スライスセグメントは、タイル走査時に連続して並べられ、単一のＮＡＬユニットに収められた、整数のコーディングツリーユニットであると定義される。スライスセグメントへの各画像の分割は、区画化である。ＨＥＶＣでは、独立スライスセグメントは、スライスセグメントヘッダのシンタックス要素の値が、前にあるスライスセグメントについて値から推測されないスライスセグメントであると定義され、従属スライスセグメントは、スライスセグメントヘッダのいくつかのシンタックス要素の値が、デコード順で前にある独立スライスセグメントについての値から推測されるスライスセグメントであると定義される。ＨＥＶＣでは、スライスヘッダは、現在のスライスセグメントであるか、または現在の従属スライスセグメントの前にある独立スライスセグメントである、独立スライスセグメントのスライスセグメントヘッダであると定義され、スライスセグメントヘッダは、スライスセグメント内で表された第１または全てのコーディングツリーユニットに関するデータ要素を収めるコード化したスライスセグメントの一部であると定義される。ＣＵは、タイルが使用中でない場合、タイル内または画像内のＬＣＵのラスター走査順で走査される。ＬＣＵ内に、ＣＵは、固有の走査順を保持する。

【0111】

ＨＥＶＣにおけるスライスセグメントレイヤＲＢＳＰは、以下のシンタックスを有する。

【表1】

【0112】

ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ（）シンタックスは、以下のように始まる。

【表2】

【0113】

本明細書では、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ａｄｄｒｅｓｓは、画像内のスライスセグメントの位置によって決まるが、他のシンタックス要素の値は、同じコード化画像の全ての独立スライスセグメントにおいて何度も変化しない。

【0114】

運動制約タイルセット（ＭＣＴＳ：ｍｏｔｉｏｎ－ｃｏｎｓｔｒａｉｎｅｄ ｔｉｌｅ ｓｅｔ）は、運動制約タイルセットの外側にあるサンプル値、および、運動制約タイルセットの外側にある１つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約タイルセット内の任意のサンプルの相互予測のために使用されないように、エンコード時に相互予測処理が制限されるようなものである。追加として、ＭＣＴＳのエンコーディングは、ＭＣＴＳの外側にあるブロックから運動ベクトル候補が導出されないという手法で制約される。これは、ＨＥＶＣの時間運動ベクトル予測を止めることによって、あるいは、ＴＭＶＰ候補、または、マージ時のＴＭＶＰ候補、もしくは、ＭＣＴＳの右下の最後の１つを除くＭＣＴＳの右側のタイル境界の直接左に位置するＰＵについてのＡＭＶＰ候補リストの後にある任意の運動ベクトル予測候補、をエンコーダが使用できないようにすることによって、強制することができる。一般に、ＭＣＴＳは、ＭＣＴＳの外側にある、運動ベクトルなどの、任意のサンプル値およびコード化データから独立したタイルセットであると定義することができる。場合によっては、ＭＣＴＳは、長方形エリアを形成するために必要とされることがある。文脈に応じて、ＭＣＴＳは、画像内のタイルセットを、または、画像のシーケンス内のそれぞれのタイルセットを指すことがあることを理解されたい。それぞれのタイルセットは、画像のシーケンス内に配置されてもよいが、一般に、そうである必要はない。

【0115】

相互予測で使用されるサンプル位置は、画像の対応する境界サンプルを指すために、画像の外側にある位置を別途満たすようなエンコードおよび／またはデコード処理によって満たせることに留意されたい。したがって、タイル境界が画像境界でもある場合、いくつかのユースケースでは、エンコーダは、サンプル位置を境界上に飽和させるので、運動ベクトルがこの境界を効果的に横切ること、または、この境界の外側にある位置を指す断片的サンプル補間を運動ベクトルが効果的に行うこと、を可能にすることができる。他のユースケースでは、特に、画像境界に隣接した場所に位置するビットストリームから、画像境界に隣接していない場所にタイルが位置する別のビットストリームに、コード化タイルを抽出できる場合、エンコーダは、いずれかのＭＣＴＳ境界と同様に画像境界に運動ベクトルを制約することができる。

【0116】

ＨＥＶＣの時間運動制約タイルセットＳＥＩメッセージは、ビットストリーム内の運動制約タイルセットの存在を示すために使用することができる。

【0117】

ＭＣＴＳについて、いくつかの例および実施形態を説明したものの、これらは、独立してデコード可能な時空ユニットの他の同様の概念を用いて同様に実現することができることを理解する必要がある。その上、このような時空ユニットのための運動制約は、上記のＭＣＴＳと同様に指定することができる。このような時空ユニットの例は、運動制約スライスおよび運動制約画像を含むがこれらに限定されない。運動制約スライスは、運動制約スライスの外側にあるシンタックスまたは導出された変数、運動制約スライスの外側にあるサンプル値、および運動制約スライスの外側にある１つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約スライス内の任意のサンプルの相互予測のために使用されないように、エンコード時に相互予測処理が制約されるようなものである。運動制約画像は、画像境界を特別に考慮しない運動制約画像の外側にあるシンタックスまたは導出された変数、画像境界を特別に考慮しない運動制約画像の外側にあるサンプル値、および画像境界を特別に考慮しない運動制約画像の外側にある１つまたは複数のサンプル値を使用して導出された断片的サンプル位置におけるサンプル値が、運動制約画像内の任意のサンプルの相互予測のために使用されないように、エンコード時に相互予測処理が制約されるようなものである。画像境界についてのこのような特別な考慮は、例えば、画像境界内にあるはずの座標を満たすこと、および、予測処理時に利用不可能であるはずの画像境界の外側にあるブロックまたは運動ベクトルを推測すること、であってもよい。単一の時間インスタンスまたは単一の画像の文脈で句時空ユニットが使用されるとき、これは、コード化画像の一定のサブセット、および、デコードされたとき、デコード画像エリアの一定のサブセットに対応する空間ユニットとみなすことができる。

【0118】

デコーダは、（エンコーダによって作り出され、圧縮表現で格納された動き情報または空間情報を使用して）ピクセルブロックの予測表現を形成するために、エンコーダと同様の予測手段、および、予測誤差デコーディング（空間ピクセルドメインにおける量子化された予測誤差信号を回復する予測誤差コーディングの逆の動作）、を適用することによって出力ビデオを再構築する。予測および予測誤差デコード手段を適用した後、デコーダは、出力ビデオフレームを形成するために、予測および予測誤差信号（ピクセル値）を合計する。デコーダ（およびエンコーダ）は、ビデオシーケンスにおけるこの次のフレームのための予測基準として、ディスプレイに出力ビデオを渡すこと、および／または出力ビデオを格納することを行う前に、出力ビデオの品質を改善するために、追加のフィルタリング手段も適用することができる。

【0119】

フィルタリングは、例えば、非ブロック化、サンプルアダプティブオフセット（ＳＡＯ：ｓａｍｐｌｅ ａｄａｐｔｉｖｅ ｏｆｆｓｅｔ）、および／またはアダプティブループフィルタリング（ＡＬＦ）のもう１つを含むことができる。Ｈ．２６４／ＡＶＣは、非ブロック化を含み、その一方で、ＨＥＶＣは、非ブロック化とＳＡＯの両方を含む。

【0120】

典型的なビデオコーデックでは、動き情報は、予測ユニットなどの、各動き補償後のイメージブロックに関連付けられた運動ベクトルで示される。これらの運動ベクトルのそれぞれは、（エンコーダ側で）コード化される、または、（デコーダ側で）デコードされることになる画像内のイメージブロック、および、以前にコード化またはデコードされた画像のうちの１つにおける予測ソースブロックの変位を表す。運動ベクトルを効率的に表すために、これらは、典型的には、ブロック固有の予測運動ベクトルについて差別的にコード化される。典型的なビデオコーデックでは、予測運動ベクトルは所定の方式で作り出され、例えば、隣接ブロックのエンコードまたはデコードされた運動ベクトルのメジアンを計算する。運動ベクトル予測を作り出すための別の方法は、時間基準画像における隣接ブロックおよび／または同じ場所に位置するブロック、ならびに、運動ベクトル予測器として選ばれた候補のシグナリングから、候補予測のリストを生成することである。運動ベクトル値の予測に加えて、動き補償型予測のために、どの基準画像が使用されるかを予測することができ、この予測情報は、例えば、以前にコード化／デコードされた画像の参照インデックスによって、表すことができる。参照インデックスは、典型的には、時間基準画像内の隣接ブロックおよび／または同じ場所に位置するブロックから予測される。その上、典型的な高効率ビデオコーデックは、しばしば、マージング／マージモードと呼ばれる、追加の動き情報コーディング／デコーディングメカニズムを採用し、ここで、各利用可能な基準画像リストについての運動ベクトルおよび対応する基準画像インデックスを含む動きフィールド情報の全てが、どのような修正／訂正もなく、予測され、使用される。同様に、動きフィールド情報の予測は、時間基準画像内の隣接ブロックおよび／または同じ場所に位置するブロックの動きフィールド情報を使用して実行され、使用される動きフィールド情報は、利用可能な隣接ブロック／同じ場所に位置するブロックの動きフィールド情報で満たされた動きフィールド候補リストのリスト間でシグナリングされる。

【0121】

典型的なビデオコーデックでは、動き補償後の予測残差は、最初に、（ＤＣＴのような）変換カーネルで変換され、次に、コード化される。この理由は、残差の間にいくつかの相関関係が依然として存在していることが多く、多くの場合、この相関関係を低減させ、より効率的なコーディングを提供するのに変換を役立てることができることである。

【0122】

典型的なビデオエンコーダは、ラグランジュコスト関数を利用して、例えばブロックおよび関連付けられた運動ベクトルのための所望のコーディングモードといった、最適なコーディングモードを見つける。この種類のコスト関数は、重み係数λを使用して、不可逆コーディング方法による（正確なまたは推定される）イメージ歪み、および、イメージエリア内のピクセル値を表すのに必要な（正確なまたは推定される）量の情報を一緒に結びつける。
Ｃ＝Ｄ＋λＲ、 （１）
ここで、Ｃは、最小化されることになるラグランジュコストであり、Ｄは、モードおよび運動ベクトルを考慮したイメージ歪み（例えば平均２乗誤差）であり、および、Ｒは、（候補運動ベクトルを表すためのデータの量を含む）デコーダでイメージブロックを再構築するのに必要なデータを表すのに必要なビットの数である。

【0123】

ビデオコーディング規格および仕様は、コード化スライスまたは同様のものにコード化画像をエンコーダが分割できるようにすることができる。スライス境界をまたぐ画像内予測は、典型的には、無効にされる。このように、スライスは、独立してデコード可能な部分にコード化画像を分けるための方式とみなすことができる。Ｈ．２６４／ＡＶＣおよびＨＥＶＣでは、スライス境界をまたぐ画像内予測を無効にすることができる。このように、スライスは、独立してデコード可能な部分にコード化画像を分けるための方式とみなすことができ、スライスは、したがって、しばしば、伝送のための基本ユニットとみなされる。多くの場合、エンコーダは、スライス境界をまたぐ画像内予測のどのタイプを止めるかをビットストリームで示すことができ、デコーダ動作は、例えば、どの予測ソースが利用可能であるかを推論するとき、この情報を考慮する。例えば、隣のＣＵからのサンプルは、隣のＣＵが異なるスライス内にある場合、内部予測に対して利用不可能とみなすことができる。

【0124】

Ｈ．２６４／ＡＶＣまたはＨＥＶＣエンコーダの出力、およびＨ．２６４／ＡＶＣまたはＨＥＶＣデコーダの入力についての基本ユニットは、それぞれ、ネットワーク抽象化レイヤ（ＮＡＬ：Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニットである。パケット指向ネットワークでのトランスポート、または構造化ファイルへの格納のために、ＮＡＬユニットをパケットまたは同様の構造にカプセル化することができる。フレーム構造を提供しない伝送またはストレージ環境のために、バイトストリームフォーマットがＨ．２６４／ＡＶＣおよびＨＥＶＣで指定されている。バイトストリームフォーマットは、各ＮＡＬユニットの前にスタートコードを取り付けることによってＮＡＬユニットを互いに分離する。ＮＡＬユニット境界の偽検出をなくすために、エンコーダは、バイト指向スタートコードエミュレーション防止アルゴリズムを実行し、このアルゴリズムは、スタートコードが別途発生した場合、ＮＡＬユニットペイロードにエミュレーション防止バイトを追加する。パケットシステムとストリーム指向システムとの間の単純なゲートウェイ動作を可能にするために、バイトストリームフォーマットが使用中であるか否かに関わらず、スタートコードエミュレーション防止を常に実施することができる。ＮＡＬユニットは、後に続くデータのタイプの指示を収めるシンタックス構造、および、エミュレーション防止バイトとともに必要に応じて散りばめられたＲＢＳＰの形のこのデータを収めるバイト、と定義することができる。ローバイトシーケンスペイロード（ＲＢＳＰ：ｒａｗ ｂｙｔｅ ｓｅｑｕｅｎｃｅ ｐａｙｌｏａｄ）は、ＮＡＬユニット内にカプセル化された整数のバイトを収めるシンタックス構造と定義することができる。ＲＢＳＰは空であるか、またはＲＢＳＰストップビットの前の、および０に等しいゼロ個以上のその後のビットの前の、シンタックス要素を収めるデータビットの文字列の形をしている。

【0125】

ＮＡＬユニットは、ヘッダおよびペイロードからなる。Ｈ．２６４／ＡＶＣおよびＨＥＶＣでは、ＮＡＬユニットヘッダは、ＮＡＬユニットのタイプを示す。

【0126】

ＨＥＶＣでは、２バイトのＮＡＬユニットヘッダが、全ての指定のＮＡＬユニットタイプのために使用される。ＮＡＬユニットヘッダは、１つの予約ビット、６ビットのＮＡＬユニットタイプ指示、時間レベルについての３ビットのｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１指示（１以上であることを要求することができる）、および６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス要素を収める。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１シンタックス要素は、ＮＡＬユニットについての時間識別子とみなすことができ、ゼロベースのＴｅｍｐｏｒａｌＩｄ変数は、ＴｅｍｐｏｒａｌＩｄ＝ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１－１のように導出することができる。省略形ＴＩＤは、ＴｅｍｐｏｒａｌＩｄ変数と区別なく使用することができる。０に等しいＴｅｍｐｏｒａｌＩｄは、最小時間レベルに対応する。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値は、２つのＮＡＬユニットヘッダバイトを伴うスタートコードエミュレーションを避けるために、ゼロ以外である必要がある。選択値以上のＴｅｍｐｏｒａｌＩｄを有する全てのＶＣＬ ＮＡＬユニットを除外し、他の全てのＶＣＬ ＮＡＬユニットを含めることによって作り出されたビットストリームは、相変わらず適合する。必然的に、ｔｉｄ＿ｖａｌｕｅに等しいＴｅｍｐｏｒａｌＩｄを保持する画像は、相互予測基準としてｔｉｄ＿ｖａｌｕｅより大きいＴｅｍｐｏｒａｌＩｄを保持するどの画像も使用しない。サブレイヤまたはテンポラルサブレイヤは、ＴｅｍｐｏｒａｌＩｄ変数の特定の値を伴うＶＣＬ ＮＡＬユニット、および関連付けられた非ＶＣＬ ＮＡＬユニットからなる、時間スケーラブルビットストリームの時間スケーラブルレイヤ（または時間レイヤ、ＴＬ）であると定義することができる。ｎｕｈ＿ｌａｙｅｒ＿ｉｄは、スケーラビリティレイヤ識別子とみなすことができる。

【0127】

ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ：Ｖｉｄｅｏ Ｃｏｄｉｎｇ Ｌａｙｅｒ）ＮＡＬユニット、および非ＶＣＬ ＮＡＬユニットにカテゴライズすることができる。ＶＣＬ ＮＡＬユニットは、典型的には、コード化スライスＮＡＬユニットである。ＨＥＶＣでは、ＶＣＬ ＮＡＬユニットは、１つまたは複数のＣＵを表すシンタックス要素を収める。

【0128】

ＨＥＶＣでは、画像タイプについての省略形は、トレーリング（ＴＲＡＩＬ）画像、テンポラルサブレイヤアクセス（ＴＳＡ）、ステップワイズテンポラルサブレイヤアクセス（ＳＴＳＡ）、ランダムアクセスデコーダブルリーディング（ＲＡＤＬ）画像、ランダムアクセススキップリーディング（ＲＡＳＬ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）画像、ブロークンリンクアクセス（ＢＬＡ）画像、インスタントデコーディングリフレッシュ（ＩＤＲ：Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｉｎｇ Ｒｅｆｒｅｓｈ）画像、クリーンランダムアクセス（ＣＲＡ：Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）画像と定義することができる。いくつかの画像タイプは、上記のテーブルで示されるように、よりきめ細かくなる。例えば、ＢＬＡ画像の３つのタイプ、すなわち、先頭画像のないＢＬＡ、デコード可能先頭画像のある（すなわちＲＡＳＬ画像のない）ＢＬＡ、および、何らかの先頭画像があるＢＬＡが指定される。

【0129】

ランダムアクセスポイント（ＲＡＰ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）画像は、ランダムアクセス画像または内部ランダムアクセスポイント（ＩＲＡＰ：ｉｎｔｒａ ｒａｎｄｏｍ ａｃｃｅｓｓ ｐｏｉｎｔ）画像と呼ばれることもあるが、内部コード化イメージセグメントだけを含むことができる。さらに、ＲＡＰ画像は、デコード順でＲＡＰ画像の前にあるどの画像のデコード処理も実施せずに正しくデコードできるようなものになるように、出力順でその後の画像を制約することができる。ＨＥＶＣでは、ＩＲＡＰ画像は、ＢＬＡ画像、ＣＲＡ画像、またはＩＤＲ画像であってもよい。ＨＥＶＣでは、活性化される必要があるときに必要なパラメータセットを利用できるという条件で、独立レイヤにおけるＩＲＡＰ画像、および、デコード順で独立レイヤにおける全てのその後の非ＲＡＳＬ画像を、デコード順でＩＲＡＰ画像の前にあるどの画像のデコード処理も実施せずに正しくデコードすることができる。ＩＲＡＰ画像ではない内部コード化スライスだけを収めるビットストリーム内の画像があってもよい。

【0130】

ＨＥＶＣでは、ＣＲＡ画像が、デコード順でビットストリーム内の第１の画像であってもよく、または、ビットストリーム内の後の方に現れてもよい。ＨＥＶＣにおけるＣＲＡ画像は、デコード順でＣＲＡ画像の後にあるが、出力順でＣＲＡ画像の前にある、いわゆる先頭画像を可能にする。先頭画像、いわゆるＲＡＳＬ画像のいくつかは、ＣＲＡ画像の前にデコードされた画像を、基準として使用することができる。デコード順と出力順の両方でＣＲＡ画像の後にある画像は、ＣＲＡ画像においてランダムアクセスが実施される場合、デコード可能であり、したがって、ＩＤＲ画像のクリーンランダムアクセス機能と同様に、クリーンランダムアクセスが達成される。

【0131】

ＣＲＡ画像は、関連付けられたＲＡＤＬまたはＲＡＳＬ画像を保持することができる。ＣＲＡ画像が、デコード順でビットストリーム内の第１の画像であるとき、ＣＲＡ画像は、デコード順で、コード化ビデオシーケンスの第１の画像であり、ビットストリーム内に存在しない画像への参照を、関連付けられたＲＡＳＬ画像が収めることができるので、どの関連付けられたＲＡＳＬ画像もデコーダによって出力されず、デコード可能でなくてもよい。

【0132】

先頭画像は、出力順で、関連付けられたＲＡＰ画像の前にある画像である。関連付けられたＲＡＰ画像は、（存在する場合）デコード順で、前のＲＡＰ画像である。先頭画像は、ＲＡＤＬ画像またはＲＡＳＬ画像である。

【0133】

全てのＲＡＳＬ画像は、関連付けられたＢＬＡまたはＣＲＡ画像の先頭画像である。関連付けられたＲＡＰ画像がＢＬＡ画像であるか、またはビットストリーム内の第１のコード化画像であるとき、ビットストリーム内に存在しない画像への参照を、ＲＡＳＬ画像が収めることができるので、ＲＡＳＬ画像は出力されず、正しくデコード可能でなくてもよい。それでも、ＲＡＳＬ画像は、ＲＡＳＬ画像の関連付けられたＲＡＰ画像の前のＲＡＰ画像からデコードが始まった場合、正しくデコードすることができる。ＲＡＳＬ画像は、非ＲＡＳＬ画像のデコード処理のための基準画像として使用されない。存在するとき、全てのＲＡＳＬ画像が、デコード順で、同じ関連付けられたＲＡＰ画像の全てのトレーリング画像の前にある。ＨＥＶＣ規格のいくつかの草案では、ＲＡＳＬ画像は、タグドフォーディスカード（ＴＦＤ）画像と呼ばれた。

【0134】

全てのＲＡＤＬ画像は、先頭画像である。ＲＡＤＬ画像は、同じ関連付けられたＲＡＰ画像のトレーリング画像のデコード処理のための基準画像として使用されない。存在するとき、全てのＲＡＤＬ画像は、デコード順で、同じ関連付けられたＲＡＰ画像の全てのトレーリング画像の前にある。ＲＡＤＬ画像は、デコード順で、関連付けられたＲＡＰ画像の前にあるどの画像も参照せず、したがって、関連付けられたＲＡＰ画像からデコードが始まるとき、正しくデコードすることができる。

【0135】

ＣＲＡ画像から始まるビットストリームの一部が別のビットストリームに含まれるとき、ＣＲＡ画像に関連付けられたＲＡＳＬ画像は、ＲＡＳＬ画像の基準画像のいくつかが、結合されたビットストリーム内にない可能性があるので、正しくデコードできない可能性がある。このような接合動作を単純にするために、ＮＡＬユニットタイプのＣＲＡ画像は、これがＢＬＡ画像であることを示すように変更することができる。ＢＬＡ画像に関連付けられたＲＡＳＬ画像は、正しくデコード可能でなくてもよく、したがって、出力／表示されない。さらに、ＢＬＡ画像に関連付けられたＲＡＳＬ画像は、デコードから省略されてもよい。

【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】

両方のビューが同じパック画像にマッピングされる立体コンテンツのための画像ステッチ、投影、および領域単位パッキング処理の内訳が、図６ｂで示され、以下のように説明される。入力イメージ（Ｂｉ）は、１つが各目のためのものである、２つの３次元投影構造にステッチされ、投影される。各投影構造上のイメージデータは、球体全体をカバーする２次元投影画像上にさらに配置される（左目のためのＣ_L、右目のためのＣ_R）。左ビュー画像および右ビュー画像を同じ投影画像にパッキングするために、フレームパッキングが適用される。任意選択として、次に、パック画像に投影画像をパッキングするために領域単位パッキングが適用され、パック画像（Ｄ）は、イメージ／ビデオエンコーディングへの入力として与えられる。領域単位パッキングが適用されない場合、パック画像は投影画像と同一であり、この画像は、イメージ／ビデオエンコーディングへの入力として与えられる。

【0183】

画像ステッチ、投影、および領域単位パッキング処理は、例えば、投影構造の異なる方向に対して、同じコンテンツの異なるバージョンを作り出すために、同じソース画像に対して何度も実行することができる。同様に、領域単位パッキング処理は、エンコードされることになるパック画像の２つ以上のシーケンスを作り出すために、同じ投影画像から何度も実施することができる。

【0184】

３６０度パノラマコンテンツ（すなわち、イメージおよびビデオ）は、イメージングデバイスのキャプチャ位置の周囲の完全な３６０度視野を水平にカバーする。垂直視野は変化してもよく、例えば１８０度であってもよい。３６０度視野を水平に、および１８０度視野を垂直にカバーするパノラマイメージは、２Ｄ画像を形成するために垂直にカットすることができる境界シリンダにマップすることができる球体で表すことができる（このタイプの投影は、エクイレクタングラ投影として知られる）。モノスコーピックエクイレクタングラパノラマ画像を形成する処理が、図７に示されている。複数のレンズおよびセンサを伴うカメラアレイまたはカメラデバイスのフィッシュアイイメージなどの入力イメージのセットが、球体イメージ上にステッチされる。球体イメージは、（上面および下面のない）シリンダ上にさらに投影される。シリンダは、２次元投影フレームを形成するために展開される。実際には、本ステップの１つまたは複数はマージすることができ、例えば、入力イメージは、球体上への中間投影なく、シリンダ上に直接投影することができる。エクイレクタングラパノラマのための投影構造は、単一の表面を備えるシリンダとみなすことができる。

【0185】

一般に、３６０度コンテンツは、多面体（すなわち、平らな多角形の面、一直線の縁、およびシャープな角または頂点を収める３次元固体オブジェクト、例えば、キューブまたは角錐）、シリンダ（エクイレクタングラ投影を用いて上記で説明したような、シリンダ上に球体イメージを投影することによる）、シリンダ（球体上に最初に投影することなく直接的に）、円錐等などの、種々のタイプの固体の幾何学構造にマップし、その後、２次元イメージ平面に広げることができる。

【0186】

場合によっては、３６０度水平視野を伴うが、１８０度未満の垂直視野を伴うパノラマコンテンツは、パノラマ投影の特殊なケースとみなすことができ、ここで、球体の極エリアは、２次元イメージ平面にマップされてこなかった。場合によっては、パノラマイメージは、３６０度未満の水平視野および１８０度までの垂直視野を保持することができるが、パノラマ投影フォーマットの特性を別途保持する。

【0187】

領域単位パック情報は、ビットストリーム内の、またはビットストリームに伴うメタデータとしてエンコードすることができる。例えば、パック情報は、初めの方で説明したように、例えば投影画像からパック画像へなど、事前定義されるか、示されたソースフォーマットから、パッキングされたフレームフォーマットへの、領域単位マッピングを含むことができる。

【0188】

長方形領域単位パッキングメタデータを次に説明する。各領域について、メタデータは、投影画像内の長方形、パック画像内のそれぞれの長方形、ならびに、９０度、１８０度、もしくは２７０度ごとの回転の任意選択の変換、ならびに／または、水平および／もしくは垂直ミラーリングを定義する。長方形は、例えば、左上隅および右下隅の位置で示すことができる。マッピングは、リサンプリングを含むことができる。それぞれの長方形のサイズは、投影画像およびパック画像で異なってもよいので、メカニズムは、領域単位リサンプリングを暗示する。

【0189】

数ある中でも、領域単位パッキングは、以下の使用シナリオのためのシグナリングを提供する。
－ ビューポート独立型投影のための追加の圧縮は、球体全体にわたる、より大きい統一性を達成するために、種々の領域のサンプリングの密度を高めることによって達成される。例えば、ＥＲＰの上部および下部をオーバーサンプリングし、領域単位パッキングを適用して、これらを水平にダウンサンプリングすることができる。
－ 適応性のある手法で、キューブマップ投影などの平面ベースの投影フォーマットの面を配置すること。
－ ビューポート独立型投影フォーマットを使用して、ビューポート依存型ビットストリームを生成すること。例えば、ＥＲＰの領域、またはＣＭＰの面は、異なるサンプリング密度を有することができ、基礎をなす投影構造は、異なる方向を有することができる。
－ エクストラクタトラックで表されたパック画像の領域を示すこと。これは、異なる分解能のビットストリームからタイルをエクストラクタトラックが収集するときに必要である。

【0190】

ＯＭＡＦは、画像ステッチ、投影、および領域単位パッキングの省略を可能にし、これらのキャプチャされたフォーマットでイメージ／ビデオデータをエンコードする。この場合、イメージＤは、イメージＢｉと同じとみなされ、時間インスタンスあたりの限られた数のフィッシュアイイメージがエンコードされる。

【0191】

オーディオについて、キャプチャされた信号が本来、没入型および全方向型なので、ステッチ処理は不要である。

【0192】

ステッチされた画像（Ｄ）は、コード化イメージ（Ｅｉ）、またはコード化ビデオビットストリーム（Ｅｖ）としてエンコードされる。キャプチャされたオーディオ（Ｂａ）は、オーディオビットストリーム（Ｅａ）としてエンコードされる。コード化イメージ、ビデオ、および／またはオーディオは、次に、特定のメディアコンテナファイルフォーマットに応じて、ファイル再生のためのメディアファイル（Ｆ）、またはストリーミングのための初期化セグメントおよびメディアセグメントのシーケンス（Ｆｓ）に構成される。本明細書では、メディアコンテナファイルフォーマットは、ＩＳＯベースメディアファイルフォーマットである。ファイルエンカプスレータは、デコードされたパック画像のレンダリングを支援する投影および領域単位パック情報などの、ファイルまたはセグメントへのメタデータも含む。

【0193】

ファイル内のメタデータは、以下を含むことができる。
－ 投影画像の投影フォーマット、
－ フィッシュアイビデオパラメータ、
－ パック画像でカバーされる球体表面のエリア、
－ グローバル座標軸に対する投影画像に対応する投影構造の方向、
－ 領域単位パック情報、および
－ 領域単位品質ランキング（任意選択）。

【0194】

セグメントＦｓは、プレーヤへの配信メカニズムを使用して配信される。

【0195】

ファイルエンカプスレータが出力するファイル（Ｆ）は、ファイルデカプスレータが入力するファイル（Ｆ’）と同一である。ファイルデカプスレータは、ファイル（Ｆ’）または受け取ったセグメント（Ｆ’ｓ）を処理し、コード化ビットストリーム（Ｅ’ａ、Ｅ’ｖ、および／またはＥ’ｉ）を抽出し、メタデータをパースする。オーディオ、ビデオ、および／または画像は、次に、デコードされた信号（オーディオのためのＢ’ａ、およびイメージ／ビデオのためのＤ’）にデコードされる。デコードされたパック画像（Ｄ’）は、現在鑑賞方向またはビューポート、ならびに、ファイルからパースされた投影、球体カバレッジ、投影構造方向、および領域単位パッキングメタデータに基づいて、ヘッドマウントディスプレイまたは他の任意の表示デバイスの画面に投影される。同様に、デコードされたオーディオ（Ｂ’ａ）は、現在鑑賞方向に応じて、例えばヘッドホンを通じて、レンダリングされる。現在鑑賞方向は、ヘッドトラッキングによって、および、また、場合によっては、視線追跡機能によって判定される。デコードされたビデオおよびオーディオ信号の適切な部分をレンダリングするためのレンダラによって使用されるのに加えて、現在鑑賞方向は、デコード最適化のためにビデオおよびオーディオデコーダによっても使用され得る。

【0196】

上記で説明した処理は、ライブユースケースとオンデマンドユースケースの両方に適用可能である。

【0197】

人間の目は、３６０度空間全体を鑑賞することができず、最大水平および垂直ＦｏＶ（ＨＨＦｏＶ、ＨＶＦｏＶ）に限定される。また、ＨＭＤデバイスには、水平および垂直方向の３６０度空間全体のサブセット（ＤＨＦｏＶ、ＤＶＦｏＶ）を鑑賞することしかできないという技術的限界がある。

【0198】

任意の時点で、ＨＭＤ上のアプリケーションでレンダリングされたビデオが、３６０度ビデオの一部をレンダリングする。この部分は、ここでは、ビューポートと定義される。ビューポートは、レンダリングディスプレイによって表示された全方向ビデオ内に表された３６０世界上のウィンドウである。ビューポートは、代替として、表示およびユーザによる鑑賞に適した全方向イメージまたはビデオの領域と定義することができる。

【0199】

ビューポートサイズは、ＨＭＤの視野に対応させることができるか、またはアプリケーションに応じて、より小さいサイズを保持することもできる。分かりやすくするために、任意の所与の時点にユーザが鑑賞する３６０度空間の一部を、１次ビューポートと定義する。

【0200】

ＯＭＡＦの座標系は、ユニット球体、および３つの座標軸、すなわち、Ｘ（後ろから前の）軸、Ｙ（横方向、片側から片側の）軸、およびＺ（垂直、上方への）軸からなり、ここで、３つの軸は、球体の中心で交差する。球体上の点の位置は、１組の球体座標の方位（φ）および高度（θ）で識別される。図８は、Ｘ、Ｙ、およびＺ座標軸と、球体座標の方位（φ）および高度（θ）との関係を指定する。

【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】

ＯＭＡＦ ｖ２は、異なる全方向コンテンツソースを定義するための関係メカニズムも提供し、これは、視点と呼ばれる。格納およびエンコードの効率のために、時間単位の長いメディア（サブ）セグメントが好ましいと仮定すると、ユーザが１つの視点から別の視点に切り替えるとき、新しい視点コンテンツへの切替え動作を実施する前に、プレーヤが完全なメディアセグメントをダウンロードする必要があるので、帯域幅が無駄になる。

【0258】

ここで、上記の問題を少なくとも部分的に回避するための、デコーダの再生休止中のコンテンツ検索のための改善された方法を紹介する。

【0259】

図１０に示すような、一態様による方法は、少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードすること（１０００）を含み、第１の表現が、１つまたは複数の切替え可能相互コード化画像を含むようにエンコードされ（１００２）、デコード順で切替え可能相互コード化画像の前にある画像が、デコード順で切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を切替え可能相互コード化画像が有し、第２の表現が、第１の表現の切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含むようにエンコードされ（１００４）、第２の表現のフレームレートが、第１の表現のフレームレート以下であり、第１および第２の表現の分解能が等しい。

【0260】

実施形態において、表現という用語は、ビットストリームという用語と交換可能に用いることができるか、または送達および／もしくは記憶のためのビットストリームのカプセル化とみなすことができる。

【0261】

１つの実施形態によれば、切替え可能画像は、デコード順でゼロ個以上前の切替え可能相互コード化画像および／または前のランダムアクセス画像からのみ切替え可能画像が予測されるという第２の特性を有することができる。

【0262】

１つの実施形態によれば、デコード順で前の切替え可能相互コード化画像および／または前のランダムアクセス画像のうち、デコード順で後ろにある方からのみ切替え可能相互コード化画像が予測されるという第２の特性を切替え可能相互コード化画像が有することは、例えばコーディング規格において予め定義されており、かつ／またはビットストリームの中でもしくはそれとともに（例えば、エンコーダによって）示され、かつ／またはビットストリームからもしくはそれとともに（例えば、デコーダによって）デコードされる。第２の特性は、切替え可能相互コード化画像をデコーダリセット画像と置き換え、デコーダリセット画像から開始して第１の表現をデコードすることを可能にする。

【0263】

１つの実施形態によれば、前の切替え可能相互コード化画像または前のランダムアクセス画像のうち、レコード順で後ろにある方における、またはその後の、デコード順でゼロ個以上前の画像からのみ切替え可能相互コード化画像が予測されるという第２の特性を切替え可能相互コード化画像が有することは、例えばコーディング規格において予め定義されており、かつ／またはビットストリームの中でもしくはそれとともに（例えば、エンコーダによって）示され、かつ／またはビットストリームからもしくはそれとともに（例えば、デコーダによって）デコードされる。第２の特性は、切替え可能相互コード化画像をデコーダリセット画像と置き換え、デコーダリセット画像から開始して第１の表現をデコードすることを可能にする。

【0264】

１つの実施形態によれば、デコード順でゼロ個以上前の切替え可能相互コード化画像および／または前のランダムアクセス画像からのみ切替え可能相互コード化画像が予測されるという第２の特性を切替え可能相互コード化画像が有することは、例えばコーディング規格において予め定義されており、かつ／またはビットストリームの中でもしくはそれとともに（例えば、エンコーダによって）示され、かつ／またはビットストリームからもしくはそれとともに（例えば、デコーダによって）デコードされる。第２の特性は、切替え可能相互コード化画像を対応するデコーダリセット画像と置き換えることによって第１の表現をデコードすることを可能にし、置き換えは、少なくとも、基準画像のうちの１つまたは複数がデコードされていない切替え可能相互コード化画像について実行される。

【0265】

このため、切替え可能相互コード化画像を第１の表現に導入し、デコーダリセット画像を第２の表現に導入する等の特定のエンコーダ制約を有する同じコンテンツ表現の複数のエンコードされた表現を提供する、新規のビデオエンコーディング方法を紹介する。デコーダリセット画像を切替え可能画像と適合させることは、多くのコーディングシステムにおいて、それらの画像について同じ画像オーダーカウント（ＰＯＣ）またはＰＯＣの同じ下位ビットを示すことを含むことができ、それによって、それらの画像はいずれも、デコード順で後ろにある画像からの相互予測において交換可能に参照することができる。

【0266】

１つの実施形態によれば、デコード順で切替え可能相互コード化画像の前にある全ての画像が、デコード順で切替え可能相互コード化画像の後にある全ての画像に対し、出力順で前にあるという第３の特性を切替え可能相互コード化画像が有することは、例えばコーディング規格において予め定義されており、かつ／またはビットストリームの中でもしくはそれとともに（例えば、エンコーダによって）示され、かつ／またはビットストリームからもしくはそれとともに（例えば、デコーダによって）デコードされる。第３の特性は、切替え可能相互コード化画像に対応するデコーダリセット画像からデコーディングが開始するとき、「全」達成可能画像レートが、画像のフリーズまたはスタッタリングなしで達成されることを暗に意味する。

【0267】

１つの実施形態によれば、切替え可能相互コード化画像自体、およびデコード順で切替え可能相互コード化画像の前にある全ての画像の双方が、デコード順で切替え可能相互コード化画像の後にある全ての画像に対し、出力順で前にあるという第３の特性を切替え可能相互コード化画像が有することは、例えばコーディング規格において予め定義されており、かつ／またはビットストリームの中でもしくはそれとともに（例えば、エンコーダによって）示され、かつ／またはビットストリームからもしくはそれとともに（例えば、デコーダによって）デコードされる。第３の特性は、切替え可能相互コード化画像に対応するデコーダリセット画像からデコーディングが開始するとき、「全」達成可能画像レートが、画像のフリーズまたはスタッタリングなしで達成されること、およびデコーダリセット画像が出力順において第１の画像であることを暗に意味する。

【0268】

１つの実施形態によれば、画像が切替え可能相互コード化画像であるという指示を、エンコーダはビットストリームの中でもしくはそれとともに指示し、および／またはデコーダはビットストリームからもしくはそれとともにデコードする。指示は、例えば、限定ではないが、特定のＮＡＬユニットタイプ値および／または特定のＳＥＩメッセージとすることができる。特定のＮＡＬユニットタイプ値は、例えば、関連画像がトレーリング画像であること、ならびに、上記で説明した、第１の特性と第２および第３の特性のうちのゼロ個以上とがビットストリームにおいて守られることを示す。

【0269】

１つの実施形態によれば、特定の画像に関連付けられた第１、第２および第３の特性のうちの１つまたは複数を示す１つまたは複数の指示を、エンコーダはビットストリームの中でもしくはそれとともに指示し、および／またはデコーダはビットストリームからもしくはそれとともにデコードする。指示は、例えば、特定のＳＥＩメッセージ内に含めることができる。

【0270】

１つの実施形態によれば、方法は、切替え可能相互コード化画像を周期的にコード化することをさらに含む。例えば、ネスト化された時間スケーラビリティを用いた階層的相互コーディングにおいて、各グループオブピクチャ（ＧＯＰ）におけるキー画像（すなわち、０に等しいＴｅｍｐｏｒａｌＩｄを有する画像）は、切替え可能画像としてエンコードすることができる。

【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】

このため、プレーヤは、休止状態中に、利用可能なバッファサイズに基づいて、または定義された帯域幅利用ポリシに基づいて、コンテンツカバレッジ全体（例えば、３６０°）をカバーする高品質タイルをフェッチすることによって、休止持続時間を利用することができる。高品質タイルは、表現の第２のセットに含めることができる。高品質タイルは、例えば、表現の第２のセットにカプセル化されたサブ画像トラックにおけるランダムアクセス画像とすることができるか、または例えば、表現の第２のセットにカプセル化されたタイルトラックに封入されたランダムアクセス画像のタイルもしくはタイルセットとすることができる。プレーヤは、まず、高品質のプリフェッチされたタイルをデコードおよび再生し、特定のビューポートを有する通常の再生動作を再開するとき、プレーヤは、ビューポートについて高品質コンテンツをリクエストし、ビューポートに基づく３６０°球体の残りの部分について低品質をリクエストすることを開始する。

【0298】

休止状態中、プレーヤは、以下のポリシを用いてプリフェッチを開始することもできる。
－ まず、現在のビューポートについて高品質タイルをプリフェッチし、次に、休止されたビューポートの周りの、閾値によって定義することができる拡大されたエリアについてプリフェッチする。
－ ＨＭＤ／注視方向に対応する、または例えば休止状態中の何気ない動き（ｃａｓｕａｌ ｍｏｔｉｏｎ）の後の「着陸方向（ｌａｎｄｉｎｇ ｏｒｉｅｎｔａｔｉｏｎ）」における、ビューポートの「低速プリフェッチ」。これは、ユーザが着陸方向点から再生を開始することを予期することができるため、ユーザの動きを追跡し、低速でデータをプリフェッチすることを可能にする。

【0299】

１つの実施形態によれば、方法は、ビューポート切替えに応答して、第２の表現の少なくとも１つのデコーダリセット画像をリクエストすることをさらに含む。リクエストすることは、例えば、第２の表現の少なくとも１つのデコーダリセット画像を含む（サブ）セグメントのためのＨＴＴＰ ＧＥＴリクエストを発行することを含むことができる。

【0300】

１つの実施形態によれば、方法は、第１のビューポートから第２のビューポートへの切替え時に第１の表現から第２の表現への切替えを適用することをさらに含む。このため、プレーヤが１つのビューポートから別のビューポートに切り替えるとき、ＤＡＳＨシグナリングメカニズム等の上述したシグナリング、およびプレーヤ動作を適用することができる。デコーダリセット画像は、ビューポートの１つのメディア（サブ）セグメントから別のビューポートの別のメディア（サブ）セグメントへの高速な遷移を可能にし、このため、ビューポート切替え処理中の低レイテンシで効率的な帯域幅利用を可能にする。この実施形態は、例えば、比較的頻繁なデコーダリセット画像を有する第２の表現を提供することによってビューポート依存のストリーミングにおけるビュー方向切替えへの高速なレスポンスを達成できるようにしながら、例えば、第１の表現における比較的大きなランダムアクセス画像間隔を用いてより良好な圧縮性能を達成することを可能にすることができる。別のビューポートに切り替えるとき、そのビューポートをカバーするデコーダリセット画像が最初に受け取られ、デコードされ、その後に、デコード順でデコーダリセット画像に続く第１の表現（表現の第１のセット）の画像が続く。

【0301】

１つの実施形態によれば、方法は、視点切替えに応答して、第２の表現の少なくとも１つのデコーダリセット画像をリクエストすることをさらに含む。リクエストすることは、例えば、（切替え先の）宛先視点の第２の表現の少なくとも１つのデコーダリセット画像を含む（サブ）セグメントのためのＨＴＴＰ ＧＥＴリクエストを発行することを含むことができる。プレーヤは、デコーダリセット画像に対応する切替え可能相互コード化画像に後続する宛先視点の第１の表現のコード化画像をカバーする別のリクエストを発行することができる。

【0302】

１つの実施形態によれば、方法は、第１の視点から第２の表現の視点への切替え時に第１の表現から第２の表現への切替えを適用することをさらに含む。このため、プレーヤが１つの視点から別の視点に切り替えるとき、ＤＡＳＨシグナリングメカニズム等の上述したシグナリング、およびプレーヤ動作を適用することができる。デコーダリセット画像は、１つの視点のメディアセグメントから別の視点の別のメディアセグメントへの高速な遷移を可能にし、このため、視点切替え処理中の低レイテンシで効率的な帯域幅利用を可能にする。

【0303】

実施形態は、例えばＩＳＯ／ＩＥＣ１４４９６－１５においてＨＥＶＣについて定義されているように、エクストラクタと結合することができるが、エクストラクタは切替え可能画像およびリセット画像のイメージセグメント（例えばスライス）の混合を必ずしも可能にしないという制約を伴う。なぜなら、前記画像タイプのイメージセグメントヘッダ（例えばスライスヘッダ）が互いに異なるためである。実施形態によるシグナリングは、それぞれ、従来の画像およびリセット画像から、サブ画像トラック／表現を抽出する、従来の画像およびリセット画像のものであるエクストラクタトラック／表現の対間で示すことができる。

【0304】

いくつかのビデオコーディングフォーマットまたは規格は、切替え可能画像およびリセット画像から生じるイメージセグメントの混合を可能にすることができる。そのような場合、表現の第１の組および表現の第２の組から生じる、一緒に並んだタイルトラック、サブ画像トラック等の各セットは、例えば上記の‘ａｌｔｅ’トラックグループを用いて互いの代わりになるように示すことができる。エクストラクタトラックは、表現の第１のセットおよび第２のセットからの、一緒に並べられたイメージセグメントのトラックグループを指すことができる。プレーヤは、イメージセグメントベースで（例えばサブ画像またはタイルベースで）、イメージセグメントが切替え可能相互コード化画像から生じるか、または対応するデコーダリセット画像から生じるかを選択することができる。

【0305】

１つの実施形態によれば、ネットワークに基づくメディア処理エンティティは、ストリーミングセッション中に実質的に瞬時に（すなわち、オンザフライで）デコーダリセット画像を生成し、異なる表現間のシームレスな切替えを可能にすることができる。そのようなエンティティは、ＭＰＥＧ ＮＢＭＰまたは同様の規格に準拠することができる。そのような場合、ＤＡＳＨ＠ｄｅｃｏｄｅｒＲｅｓｅｔＥｎａｂｌｅフラグは、表現におけるそのようなデコーダリセット画像の存在を示すことができる。実施形態は、大きな利点を提供することができる。例えば、プレーヤは、説明された実施形態を利用し、休止状態中の高品質な３６０°ビデオ画像ディスプレイを可能にし、また、デコーダリソースおよびバッファに対する影響を最小限にしながら再生を開始することに成功することができる。説明された実施形態を実現するには単一のデコーダインスタンスで十分とすることができ、この際、＠ｄｅｃｏｄｅｒＲｅｓｅｔＥｎａｂｌｅＤＡＳＨ属性のパースおよび解釈等、シグナリングを解釈する能力を除いて、プレーヤ側に追加のデコーダ制約はセットされない。＠ｄｅｃｏｄｅｒＲｅｓｅｔＥｎａｂｌｅ等の適切なシグナリングを用いて、プレーヤは、非ストリームアクセスポイント位置において、関連する表現が、示された従来の表現のデコーディングの開始のためにデコーディングをリセットするのに適していることを理解することができる。さらに、実施形態は、全方向ビデオ再生が休止され、次に再開されるときの、より良好なユーザ体験を提供する。また、デコーダ状態適合のために不要なメディアデータ転送を削除することによって、ネットワークリソースがより良好に利用される。

【0306】

図１４は、本発明の実施形態を用いるのに適したビデオデコーダのブロック図を示す。図１４は、２層デコーダの構造を示すが、デコーディング動作は、単層デコーダにおいて同様に用いることができることが理解されよう。

【0307】

ビデオデコーダ５５０は、ベースレイヤのための第１のデコーダセクション５５２と、予測レイヤのための第２のデコーダセクション５５４を含む。ブロック５５６は、ベースレイヤ画像に関する情報を第１のデコーダセクション５５２に送達し、予測レイヤ画像に関する情報を第２のデコーダセクション５５４に送達するためのデマルチプレクサを示す。参照符号Ｐ’ｎは、イメージブロックの予測表現を表す。参照符号Ｄ’ｎは、再構築された予測誤差信号を表す。ブロック７０４、８０４は、事前再構築イメージ（Ｉ’ｎ）を示す。参照符号Ｒ’ｎは、最終再構築イメージを表す。ブロック７０３、８０３は、逆変換（Ｔ^-1）を示す。ブロック７０２、８０２は、逆等化（Ｑ^-1）を示す。ブロック７０１、８０１は、エントロピデコーディング（Ｅ^-1）を示す。ブロック７０５、８０５は、参照フレームメモリ（ＲＦＭ）を示す。ブロック７０６、８０６は、予測（Ｐ）（相互予測または内部予測）を示す。ブロック７０７、８０７は、フィルタリング（Ｆ）を示す。ブロック７０８、８０８を用いて、デコードされた予測誤差情報を予測ベースレイヤ／予測レイヤイメージと組み合わせて、事前再構築イメージ（Ｉ’ｎ）を取得することができる。予備の再構成およびフィルタリングされたベースレイヤイメージを第１のデコーダセクション５５２から出力することができ（７０９）、予備の再構成およびフィルタリングされたベースレイヤイメージを第１のデコーダセクション５５４から出力することができる（８０９）。

【0308】

ここで、デコーダは、プレーヤ、レシーバ、ゲートウェイ、デマルチプレクサおよび／またはデコーダ等のデコーディング動作を実行することが可能な任意の動作ユニットをカバーするように解釈されるべきである。

【0309】

図１５は、様々な実施形態を実施することができる例示的なマルチメディア通信システムのグラフィック表現である。データソース１５１０は、アナログ、非圧縮デジタル、もしくは圧縮デジタルフォーマット、またはこれらのフォーマットの任意の組合せでソース信号を提供する。エンコーダ１５２０は、データフォーマット変換および／またはソース信号のフィルタリング等の前処理を含むかまたはこれと接続することができる。エンコーダ１５２０は、ソース信号を、コード化されたメディアビットストリームにエンコードする。デコードされるビットストリームは、仮想的に任意のタイプのネットワーク内に位置するリモートデバイスから直接または間接的に受信することができることに留意されたい。さらに、ビットストリームは、ローカルハードウェアまたはソフトウェアから受信することができる。エンコーダ１５２０は、オーディオおよびビデオ等の２つ以上のメディアタイプをエンコードすることが可能である場合があるか、または異なるメディアタイプのソース信号をコード化するために２つ以上のエンコーダ１５２０が必要とされる場合がある。エンコーダ１５２０は、グラフィックおよびテキスト等の、合成して生成された入力を得る場合もあり、または合成メディアのコード化ビットストリームを生成することが可能である場合がある。以下において、説明を簡単にするために、１つのメディアタイプの１つのコード化されたメディアビットストリームの処理のみが検討される。しかしながら、通常、リアルタイムブロードキャストサービスは、いくつかのストリーム（通常、少なくとも１つのオーディオ、ビデオ、およびテキスト字幕ストリーム）を含むことに留意されたい。また、システムは、多くのエンコーダを含むことができるが、図において、一般性を損なうことなく、説明を簡単にするために１つのエンコーダ１５２０のみが表されることを理解されたい。さらに、本明細書に含まれる本文および例は、エンコーディング処理を詳細に説明する場合があるが、当業者であれば、同じ概念および原理が対応するデコーディング処理にも当てはまり、逆もまた同様であることを理解するであろうことを理解されたい。

【0310】

コード化されたメディアビットストリームは、ストレージ１５３０に転送することができる。ストレージ１５３０は、コード化されたメディアビットストリームを記憶するための任意のタイプのマスメモリを備えることができる。ストレージ１５３０におけるコード化されたメディアビットストリームのフォーマットは、基本的な自己完結型のビットストリームフォーマットとすることができるか、または１つもしくは複数のコード化されたメディアビットストリームは、コンテナファイル内にカプセル化することができるか、またはコード化されたメディアビットストリームは、ＤＡＳＨ（または類似のストリーミングシステム）に適したセグメントフォーマット内にカプセル化し、セグメントのシーケンスとして記憶することができる。１つまたは複数のメディアビットストリームがコンテナファイル内にカプセル化される場合、ファイル生成器（図に示されていない）を用いて、１つまたは複数のメディアビットストリームをファイルに記憶し、ファイルフォーマットメタデータを生成することができ、ファイルフォーマットメタデータもファイルに記憶することができる。エンコーダ１５２０もしくはストレージ１５３０はファイル生成器を備えることができるか、またはファイル生成器はエンコーダ１５２０もしくはストレージ１５３０のいずれかに作動的に取り付けることができる。いくつかのシステムは、「ライブ」動作し、すなわち、ストレージを省き、コード化されたメディアビットストリームをエンコーダ１５２０からセンダ１５４０に直接転送する。次に、コード化されたメディアビットストリームは、必要に応じてサーバとも呼ばれるセンダ１５４０に転送することができる。伝送において用いられるフォーマットは、基本的な自己完結型のビットストリームフォーマット、パケットストリームフォーマット、ＤＡＳＨ（または類似のストリーミングシステム）に適したセグメントフォーマットとすることができるか、または１つもしくは複数のコード化されたメディアビットストリームがコンテナファイル内にカプセル化されてもよい。エンコーダ１５２０、ストレージ１５３０、およびサーバ１５４０は、同じ物理的デバイス内に存在してもよく、または別個のデバイスに含まれてもよい。エンコーダ１５２０およびサーバ１５４０は、ライブリアルコンテンツとともに動作することができ、この場合、コード化されたメディアビットストリームは、通常、永久的に記憶されるのではなく、処理遅延、転送遅延、およびコード化されたメディアビットレートの変動を平滑化するために、短い期間コンテンツエンコーダ１５２０および／またはサーバ１５４０にバッファリングされる。

【0311】

サーバ１５４０は、通信プロトコルスタックを用いてコード化されたメディアビットストリームを送信する。スタックは、限定ではないが、リアルタイムトランスポートプロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、ハイパーテキストトランスファプロトコル（ＨＴＴＰ）、伝送制御プロトコル（ＴＣＰ）、およびインターネットプロトコル（ＩＰ）のうちの１つまたは複数を含むことができる。通信プロトコルスタックがパケット指向であるとき、サーバ１５４０は、コード化されたメディアビットストリームをパケット内にカプセル化する。例えば、ＲＴＰが用いられるとき、サーバ１５４０は、ＲＴＰペイロードフォーマットに従って、コード化されたメディアビットストリームをＲＴＰパケット内にカプセル化する。通常、各メディアタイプは、専用のＲＴＰペイロードフォーマットを有する。ここでもまた、システムは、２つ以上のサーバ１５４０を含むことができるが、簡単にするために、以下の説明は、１つのサーバ１５４０のみを検討することに留意されたい。

【0312】

メディアコンテンツがストレージ１５３０のために、またはデータをセンダ１５４０に入力するためにコンテナファイル内にカプセル化される場合、センダ１５４０は、「送信ファイルパーサ」（図には示されていない）を含むことができるか、またはこれに作動的に取り付けることができる。特に、コンテナファイルがそのまま送信されるのではなく、含まれるコード化されたメディアビットストリームのうちの少なくとも１つが通信プロトコルを介したトランスポートのためにカプセル化される場合、送信ファイルパーサは、通信プロトコルを介して伝達されることになるコード化されたメディアビットストリームの適切な部分を特定する。送信ファイルパーサは、パケットヘッダおよびペイロード等の通信プロトコルのための正しいフォーマットの生成も支援することができる。マルチメディアコンテナファイルは、通信プロトコルにおける、含まれるメディアビットストリームのうちの少なくとも１つのカプセル化のための、ＩＳＯＢＭＦＦにおけるヒントトラック等のカプセル化命令を含むことができる。

【0313】

サーバ１５４０は、通信ネットワークを通じてゲートウェイ１５５０に接続される場合もまたは接続されない場合もあり、通信ネットワークは、例えば、ＣＤＮ、インターネットおよび／または１つもしくは複数のアクセスネットワークの組合せとすることができる。ゲートウェイは、さらにまたは代替的に、中央ボックスと呼ばれる場合がある。ＤＡＳＨについて、ゲートウェイは、（ＣＤＮの）エッジサーバまたはウェブプロキシとすることができる。システムは、通常、任意の数のゲートウェイ等を含むことができるが、簡単にするために、以下の説明は、１つのゲートウェイ１５５０のみを検討することに留意されたい。ゲートウェイ１５５０は、１つの通信プロトコルスタックに従うパケットストリームの別の通信プロトコルスタックへの変換、データストリームのマージおよびフォーキング、ならびにダウンリンクおよび／またはレシーバ能力に従ったデータストリームの操作、例えば、優勢なダウンリンクネットワーク条件に従った転送ストリームのビットレートの制御等の様々なタイプの機能を実行することができる。様々な実施形態において、ゲートウェイ１５５０はサーバーエンティティとすることができる。

【0314】

システムは、通常、送信された信号を受信し、復調し、脱カプセル化（ｄｅ－ｃａｐｓｕｌａｔｉｎｇ）してコード化されたメディアビットストリームに入れることが可能な１つまたは複数のレシーバ１５６０を備える。コード化されたメディアビットストリームは、記録ストレージ１５７０に転送することができる。記録ストレージ１５７０は、コード化されたメディアビットストリームを記憶するための任意のタイプのマスメモリを備えることができる。記録ストレージ１５７０は、代替的にまたはさらに、ランダムアクセスメモリ等の計算メモリを備えることができる。記録ストレージ１５７０におけるコード化されたメディアビットストリームのフォーマットは、基本的な自己充足型のビットストリームフォーマットとすることができるか、または１つもしくは複数のコード化されたメディアビットストリームは、コンテナファイル内にカプセル化することができる。互いに関連付けられたオーディオストリームおよびビデオストリーム等の複数のコード化されたメディアビットストリームが存在する場合、コンテナファイルが通常用いられ、レシーバ１５６０は、入力ストリームからコンテナファイルを生成するコンテナファイル生成器を含むかまたはこれに取り付けられる。いくつかのシステムは、「ライブ」で動作し、すなわち、記録ストレージ１５７０を省き、コード化されたメディアビットストリームをレシーバ１５６０からデコーダ１５８０に直接転送する。いくつかのシステムでは、記録されたストリームのうちの最も近時の部分、例えば、記録されたストリームのうちの最も近時の１０分の抜粋のみが記録ストレージ１５７０に維持されるのに対し、任意のより早期に記録されたデータは、記録ストレージ１５７０から破棄される。

【0315】

コード化されたメディアビットストリームは、記録ストレージ１５７０からデコーダ１５８０に転送することができる。互いに関連付けられ、コンテナファイル内にカプセル化された、オーディオストリームおよびビデオストリーム等の多くのコード化されたメディアビットストリームが存在する場合、または単一のメディアビットストリームが、より容易なアクセスのためにコンテナファイル内にカプセル化される場合、ファイルパーサ（図には示されていない）を用いて、コンテナファイルから、各コード化されたメディアビットストリームを脱カプセル化する。記録ストレージ１５７０またはデコーダ１５８０は、ファイルパーサを備えることができるか、またはファイルパーサは、記録ストレージ１５７０またはデコーダ１５８０のいずれかに取り付けられる。また、システムは、多くのデコーダを含むことができるが、ここでは、一般性を損なうことなく、説明を簡単にするために１つのデコーダ１５７０のみが論じられることを理解されたい。

【0316】

コード化されたメディアビットストリームは、デコーダ１５７０によってさらに処理することができ、デコーダ１５７０の出力は、１つまたは複数の非圧縮メディアストリームである。最終的に、レンダラ１５９０は、例えば、ラウドスピーカまたはディスプレイを用いて、非圧縮メディアストリームを再現することができる。レシーバ１５６０、記録ストレージ１５７０、デコーダ１５７０およびレンダラ５９０は、同じ物理的デバイス内に存在してもよく、または別個のデバイスに含まれてもよい。

【0317】

センダ１５４０および／またはゲートウェイ１５５０は、例えば、３６０°ビデオコンテンツの異なるビューポート間の切替え、ビュー切替え、ビットレート適合および／または高速始動のために異なる表現間の切替えを行うように構成することができ、および／またはセンダ１５４０および／もしくはゲートウェイ１５５０は、送信された表現を選択するように構成することができる。異なる表現間での切替えは、レシーバ１５６０のリクエストに対する応答、またはビットストリームが伝達されるネットワークのスループット等の優勢な条件等の複数の理由で行うことができる。換言すれば、レシーバ１５６０は、表現間の切替えを始動することができる。レシーバからのリクエストは、例えば、以前と異なる表現からのセグメントまたはサブセグメントのリクエスト、送信されたスケーラビリティレイヤおよび／もしくはサブレイヤの変更のリクエスト、または従来のものと比較して異なる能力を有するレンダリングデバイスの変更とすることができる。セグメントのためのリクエストは、ＨＴＴＰ ＧＥＴリクエストとすることができる。セグメントのためのリクエストは、バイト範囲を有するＨＴＴＰ ＧＥＴリクエストとすることができる。さらにまたは代替的に、ビットレート調節またはビットレート適合は、例えば、ストリーミングサービスのいわゆる高速始動を提供するために用いることができ、ここで、送信されるストリームのビットレートは、再生を即座に開始し、偶発的なパケット遅延および／または再送信を許容するバッファ占有レベルを達成するために、ストリーミングの開始後またはランダムアクセス後のチャネルビットレートよりも低い。ビットレート適合は、様々な順序で生じる複数の表現またはレイヤアップスイッチングおよび表現またはレイヤダウンスイッチング動作を含むことができる。

【0318】

デコーダ１５８０は、例えば、３６０°ビデオコンテンツの異なるビューポート間の切替えのための異なる表現間の切替え、視点切替え、ビットレート適合および／または高速始動を行うように構成することができ、および／またはデコーダ１５８０は、送信された表現を選択するように構成することができる。異なる表現間での切替えは、高速デコーディング動作の達成、または例えばビットレートの観点での、ビットストリームが伝達されるネットワークのスループット等の優勢な条件への送信ビットストリームの適合等の複数の理由で行うことができる。このため、デコーダは、第１の表現と第３の表現との間のビットレート適合を実行するために、第２の表現の少なくとも１つのデコーダリセット画像をリクエストするための手段をさらに備えることができる。デコーダ１５８０を備えるデバイスがマルチタスクを行っており、ビデオビットストリームをデコードする以外の目的で計算リソースを使用する場合、より高速なデコーディング動作が必要とされ得る。別の例では、コンテンツが、通常の再生速度よりも高速なペースで、例えば従来のリアルタイム再生レートよりも２倍または３倍高速で再生されるとき、より高速なデコーディングが必要とされ得る。

【0319】

上記において、例えば、セグメントフォーマットに関して、ＩＳＯＢＭＦＦに関連するいくつかの実施形態が説明された。実施形態は、ＩＳＯＢＭＦＦと類似の能力および／または構造を有するＭａｔｒｏｓｋａ等の任意の他のファイルフォーマットで同様に実現され得ることを理解する必要がある。

【0320】

上記において、エンコーダを参照して例示的な実施形態が説明されたが、結果として得られるビットストリームおよびデコーダは、それらの中に対応する要素を有することができることが理解される必要がある。同様に、デコーダを参照して例示的な実施形態が説明されたが、エンコーダは、デコーダによってデコードされるビットストリームを生成するための構造および／またはコンピュータプログラムを有することができることが理解される必要がある。

【0321】

上記で説明された本発明の実施形態は、関与する処理の理解を助けるために、別個のエンコーダおよびデコーダ装置の観点でコーデックを説明している。しかしながら、装置、構造および動作は、単一のエンコーダ－デコーダ装置／構造／動作として実施することができることが理解されよう。さらに、コーダおよびデコーダは、いくつかまたは全ての共通要素を共有し得ることが可能である。

【0322】

上記の例は、電子デバイス内のコーデック内で動作する本発明の実施形態を記載しているが、特許請求の範囲において定義される発明は、任意のビデオコーデックの一部として実施することができることが理解されよう。このため、例えば、本発明の実施形態は、固定のまたは有線通信経路を介したビデオコーディングを実施することができるビデオコーデックにおいて実施することができる。

【0323】

このため、ユーザ機器は、上記の本発明の実施形態において説明されたもの等のビデオコーデックを含むことができる。ユーザ機器という用語は、携帯電話、携帯データ処理デバイス、または携帯ウェブブラウザ等の任意の適切なタイプの無線ユーザ機器をカバーするように意図されることが理解されるべきである。

【0324】

さらに、公衆陸上移動体ネットワーク（ＰＬＭＮ）の要素は、上記で説明したビデオコーデックも含むことができる。

【0325】

一般に、本発明の様々な実施形態は、ハードウェアもしくは専用回路、ソフトウェア、ロジック、または、それらの任意の組合せにおいて実施することができる。例えば、いくつかの態様は、ハードウェアで実施されてもよく、一方、他の態様は、コントローラ、マイクロプロセッサ、または他のコンピューティングデバイスによって実行することができるファームウェアまたはソフトウェアにおいて実施されてもよい。しかしながら、本発明は、これらに限定されない。本発明の様々な態様は、ブロック図、フローチャート、または他の図表現を使用して図示および説明される場合があるが、ここに記載されたこれらのブロック、装置、システム、技術または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路もしくはロジック、汎用ハードウェアもしくはコントローラまたは他のコンピューティングデバイス、あるいは、それらのいくつかの組合せにおいて実施することができることがよく理解される。

【0326】

本発明の実施形態は、プロセッサエンティティ内等のモバイルデバイスのデータプロセッサにより実行可能なコンピュータソフトウェアによって、もしくはハードウェアによって、またはソフトウェアおよびハードウェアの組合せによって実施することができる。さらに、これに関して、図のような論理フローの任意のブロックがプログラムステップ、もしくは相互接続された論理回路、ブロックおよび機能、またはプログラムステップおよび論理回路、ブロックおよび機能の組合せを表すことができることに留意されたい。ソフトウェアは、メモリチップ、またはプロセッサ内で実施されたメモリブロック等の物理媒体、ハードディスクまたはフロッピーディスク等の磁気媒体、ならびに例えばＤＶＤおよびそのデータバリアント、ＣＤ等の光学媒体に格納することができる。

【0327】

メモリは、ローカル技術環境に適している任意のタイプのものとすることができ、半導体ベースのメモリデバイス、磁気メモリデバイスおよびシステム、光メモリデバイスおよびシステム、固定メモリならびにリムーバブルメモリ等の任意の適切なデータストレージ技術を用いて実施することができる。データプロセッサは、ローカル技術環境に適している任意のタイプのものとすることができ、非限定的な例として、汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）およびマルチコアプロセッサアーキテクチャに基づくプロセッサのうちの１つまたは複数を含むことができる。

【0328】

本発明の実施形態は、集積回路モジュール等の様々なコンポーネントで実施することができる。集積回路の設計は、概して高度に自動化された処理である。ロジックレベルの設計を、半導体基板にエッチングして形成される準備ができた半導体回路設計に変換するために複雑で処理能力の高いソフトウェアツールが利用可能である。

【0329】

カリフォルニア州マウンテンビューのシノプシス社（Ｓｙｎｏｐｓｙｓ，Ｉｎｃ．）、カリフォルニア州サンノゼのケイデンスデザイン社（ＣａｄｅｎｃｅＤｅｓｉｇｎ）等が提供するプログラムは、十分に確立された設計ルールおよび事前に保存された設計モジュールのライブラリを使用して、半導体チップ上で、自動的に導体を配線し、部品を配置する。半導体回路の設計が完了すると、標準化された電子フォーマット（例えば、Ｏｐｕｓ、ＧＤＳＩＩ等）の結果として得られる設計を、製造のための半導体製造施設または「ファブ」に送信することができる。

【0330】

前述の説明は、例示的かつ非限定的な例として、本発明の例示的な実施形態の十分かつ詳細な説明を提供するものである。しかしながら、添付の図面および添付の特許請求の範囲と併せて読めば、上記の説明を考慮して、当業者には様々な修正および適合が明らかになるであろう。しかしながら、本発明の教示の全てのそのような変更および類似の変更は、依然として本発明の範囲内に含まれる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6a】

【図6b】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【手続補正書】

【提出日】2021-09-13

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードするステップ
を含み、
前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能相互コード化画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能画像が有し、
前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、
方法。

【請求項2】

少なくとも第１の表現および第２の表現にビデオメディアコンテンツをエンコードするための手段
を備え、
前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能相互コード化画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能画像が有し、
前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、
装置。

【請求項3】

前記デコーダリセット画像が、ブロークンリンクアクセス（ＢＬＡ）画像の後に先頭画像がない前記ＢＬＡ画像タイプとして、または、インデペンデントデコーディングリフレッシュ（ＩＤＲ）画像としてエンコードされるように構成される、請求項２に記載の装置。

【請求項4】

エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取るステップであって、前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能相互コード化画像が有する、ステップと、
前記少なくとも１つのビットストリームからまたはそれとともに、デコード時に前記第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取るステップであって、前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、ステップと、
前記第２の表現の少なくとも１つのデコーダリセット画像を受け取るステップと、
前記第１の表現の画像の前の前記第２の表現の前記少なくとも１つのデコーダリセット画像をデコードするステップと
を含む、方法。

【請求項5】

エンコードされたビデオメディアコンテンツの第１の表現に対応する少なくとも１つのビットストリームを受け取るための手段であって、前記第１の表現が、切替え可能相互コード化画像を含み、デコード順で前記切替え可能画像の前にある画像が、デコード順で前記切替え可能相互コード化画像の後にあるどの切替え不能画像に対する基準画像としても使用されないという第１の特性を前記切替え可能相互コード化画像が有する、受け取るための手段と、
前記少なくとも１つのビットストリームからまたはそれとともに、デコード時に前記第１の表現と第２の表現との間で切り替えることの適性についての指示を受け取るための手段であって、前記第２の表現が、前記第１の表現の前記切替え可能相互コード化画像と適合した１つまたは複数のデコーダリセット画像を含み、前記第２の表現のフレームレートが、前記第１の表現のフレームレート以下であり、前記第１および前記第２の表現の分解能が等しい、受け取るための手段と、
前記第２の表現の少なくとも１つのデコーダリセット画像を受け取るための手段と、
前記第１の表現の画像の前の前記第２の表現の少なくとも１つのデコーダリセット画像をデコードするための手段と
を備える、装置。

【請求項6】

前記切替え可能相互コード化画像が、デコード順でゼロ個以上前の切替え可能相互コード化画像から、および／または前のランダムアクセス画像からのみ、前記切替え可能相互コード化画像が予測されるという第２の特性を有する、請求項５に記載の装置。

【請求項7】

前記デコードされた第１の表現の再生時の休止に応答して、前記第２の表現の前記少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項５または６に記載の装置。

【請求項8】

ビューポート切替えに応答して、前記第２の表現の前記少なくとも１つのデコーダリセットをリクエストするための手段
をさらに備える、請求項５または６に記載の装置。

【請求項9】

前記ビューポート切替えが、第１のビューポートから第２のビューポートへと行われ、前記第１の表現が、前記第１のビューポートをカバーし、前記装置が、
エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、前記第３の表現が、前記第２のビューポートを表す、受け取るための手段
をさらに備える、
請求項８に記載の装置。

【請求項10】

視点切替えに応答して、前記第２の表現の前記少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項５または６に記載の装置。

【請求項11】

前記視点切替えが、第１の視点から第２の視点へと行われ、前記第１の表現が、前記第１の視点をカバーし、前記装置が、
エンコードされたビデオメディアコンテンツの第３の表現に対応する第２のビットストリームを受け取るための手段であって、前記第３の表現が、前記第２の視点を表す、受け取るための手段
をさらに備える、請求項１０に記載の装置。

【請求項12】

前記再生の再開に応答して、前記再開に実質的にタイムリに対応するデコーダリセット画像をデコードするための手段と、
前記再開に実質的にタイムリに対応する前記デコーダリセット画像と一時的に適合した、前記第１の表現の切替え可能相互コード化画像の、デコード順で後にある前記第１の表現の画像をデコードすることに切り替えるための手段と
をさらに備える、請求項５から１１のいずれか１項に記載の装置。

【請求項13】

前記デコードされた第１の表現の再生時の休止に応答して、デコーダバッファサイズおよび／または利用可能な帯域幅の制限に応じて、前記第２の表現の複数のデコーダリセット画像をリクエストするための手段
をさらに備える、請求項５から１２のいずれか１項に記載の装置。

【請求項14】

前記第１の表現と第３の表現との間のビットレート適合を実行するために、前記第２の表現の少なくとも１つのデコーダリセット画像をリクエストするための手段
をさらに備える、請求項５から１３のいずれか１項に記載の装置。

【請求項15】

第１のエクストラクタトラックまたは表現から前記少なくとも１つの切替え可能相互コード化画像を抽出するための手段と、
第２のエクストラクタトラックまたは表現から前記少なくとも１つのデコーダリセット画像を抽出するための手段と
をさらに備える、請求項５から１４のいずれか１項に記載の装置。

【国際調査報告】