知財求人 - 知財ポータルサイト「IP Force」
▶ インターデジタル シーイー パテント ホールディングスの特許一覧
特表2024-514060ストリーミングアプリケーションにおけるビデオデータの微調整
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-03-28
(54)【発明の名称】ストリーミングアプリケーションにおけるビデオデータの微調整
(51)【国際特許分類】
H04N 21/6379 20110101AFI20240321BHJP
H04N 19/70 20140101ALI20240321BHJP
H04N 21/442 20110101ALI20240321BHJP
H04N 21/2343 20110101ALI20240321BHJP
【ＦＩ】
H04N21/6379
H04N19/70
H04N21/442
H04N21/2343
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023558749
(86)(22)【出願日】2022-03-29
(85)【翻訳文提出日】2023-10-25
(86)【国際出願番号】 EP2022058318
(87)【国際公開番号】W WO2022214364
(87)【国際公開日】2022-10-13
(31)【優先権主張番号】21305454.7
(32)【優先日】2021-04-08
(33)【優先権主張国・地域又は機関】EP
(31)【優先権主張番号】21306518.8
(32)【優先日】2021-10-28
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＡＮＤＲＯＩＤ
２．３ＧＰＰ
３．ＨＤＭＩ
(71)【出願人】
【識別番号】518341334
【氏名又は名称】インターディジタル・シーイー・パテント・ホールディングス・ソシエテ・パ・アクシオンス・シンプリフィエ
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(74)【代理人】
【識別番号】100108213
【弁理士】
【氏名又は名称】阿部 豊隆
(72)【発明者】
【氏名】マルタン－コシェル，ガエル
(72)【発明者】
【氏名】ル リアンネック，ファブリス
(72)【発明者】
【氏名】グドゥマス，スリニバス
【テーマコード（参考）】
5C159
5C164
【Ｆターム（参考）】
5C159MA04
5C159MA05
5C159MC11
5C159ME01
5C159PP04
5C159RB09
5C159RC11
5C159UA02
5C159UA05
5C164FA22
5C164MB13S
5C164PA31
5C164SB02P
5C164SB15S
5C164SB29S
5C164TB36P
5C164UB26S
5C164UB41P
5C164YA11
(57)【要約】
低遅延ストリーミングアプリケーションにおいて、ビデオデータを微調整するための方法であって、体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、識別子が、関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、識別子をサーバに送信することと、識別子に準拠するビデオストリームをサーバから受信することと、を含む、方法。
【選択図】図２
【選択図】図２
【特許請求の範囲】
【請求項1】
方法であって、体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、前記識別子が、前記関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、
前記識別子をサーバに送信することと、
前記識別子に準拠するビデオストリームを前記サーバから受信することと、を含む、方法。
【請求項2】
前記識別子は、ビデオデコーダが、前記ビデオストリームにおいて指定された少なくとも１つの復号プロセスをスキップするように、又は前記ビデオデコーダが、前記ビデオストリームにおいて指定された復号プロセスに少なくとも１つの追加の復号プロセスを追加するように、前記ビデオデコーダを調整することを可能にする復号決定を定義するために更に使用される、請求項１に記載の方法。
【請求項3】
前記識別子が、セッション記述プロトコルを使用して送信される、請求項１又は２に記載の方法。
【請求項4】
前記識別子が、アクティブ化若しくは非アクティブ化され得る符号化ツール、又は選択され得る体験品質のセットを指定するセッション記述プロトコルメッセージの前記サーバからの受信を含む、前記サーバとの能力交換の段階の後に取得される、請求項３に記載の方法。
【請求項5】
前記識別子を取得する前に、前記方法が、ＳＥＩメッセージで選択され得る体験品質のセットの記述を取得することを含む、請求項１、２、又は３に記載の方法。
【請求項6】
前記セットのうちの各体験品質が、制約フラグの対応するグループ、及び／又は少なくとも１つの符号化決定、及び／又は少なくとも１つの復号決定に関連付けられる、請求項５に記載の方法。
【請求項7】
方法であって、体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、前記識別子が、前記関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、
前記識別子に準拠する符号化されたビデオストリームを取得することと、
前記符号化されたビデオストリームを遠隔システムに送信することと、を含む、方法。
【請求項8】
前記符号化されたビデオストリームが、前記識別子に基づいてビデオエンコーダを調整することによって取得される、請求項７に記載の方法。
【請求項9】
前記調整することが、前記識別子によって指定された前記値に応じて、前記制約フラグのグループと関連付けられた符号化ツールをアクティブ化又は非アクティブ化することを含む、請求項８に記載の方法。
【請求項10】
前記識別子が、前記制約フラグ及び任意のプロファイルとは無関係に、ビデオエンコーダの特定の実装を定義することを可能にする、少なくとも１つの符号化決定を指定するために更に使用される、請求項７、８、又は９に記載の方法。
【請求項11】
前記識別子が、セッション記述プロトコルメッセージにおいて、前記遠隔システムから取得される、請求項７～１０のいずれか一項に記載の方法。
【請求項12】
前記識別子が、アクティブ化若しくは非アクティブ化され得る符号化ツール、又は選択され得る体験品質のセットを指定するセッション記述プロトコルメッセージの前記遠隔システムへの送信を含む、前記遠隔システムとの能力交換の段階の後に取得される、請求項７～１１のいずれか一項に記載の方法。
【請求項13】
前記識別子を取得する前に、前記方法が、ＳＥＩメッセージで選択され得る体験品質のセットの記述を前記遠隔システムに送信することを含む、請求項７～１１のいずれか一項に記載の方法。
【請求項14】
前記セットのうちの各体験品質が、制約フラグの対応するグループ、及び／又は少なくとも１つの符号化決定、及び／又は少なくとも１つの復号決定に関連付けられる、請求項１３に記載の方法。
【請求項15】
体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を含む信号であって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、前記識別子が、前記関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、信号。
【請求項16】
電子回路を備えるデバイスであって、前記電子回路が、体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、前記識別子が、前記関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、
前記識別子をサーバに送信することと、
前記識別子に準拠するビデオストリームを前記サーバから受信することと、を行うように適合されている、デバイス。
【請求項17】
前記識別子は、ビデオデコーダが、前記ビデオストリームにおいて指定された少なくとも１つの復号プロセスをスキップするように、又は前記ビデオデコーダが、少なくとも１つの追加の復号プロセスを前記ビデオストリームにおいて指定された復号プロセスに追加するように、前記ビデオデコーダを調整することを可能にする復号決定を定義するために更に使用される、請求項１６に記載のデバイス。
【請求項18】
前記識別子が、セッション記述プロトコルを使用して送信される、請求項１６又は１７に記載のデバイス。
【請求項19】
前記識別子が、アクティブ化若しくは非アクティブ化され得る符号化ツール、又は選択され得る体験品質のセットを指定するセッション記述プロトコルメッセージの前記サーバからの受信を含む、前記サーバとの能力交換の段階の後に取得される、請求項１８に記載のデバイス。
【請求項20】
前記電子回路が、前記識別子を取得する前に、ＳＥＩメッセージで選択され得る体験品質のセットの記述を取得するように更に適合されている、請求項１６、１７、又は１８に記載のデバイス。
【請求項21】
前記セットのうちの各体験品質が、制約フラグの対応するグループ、及び／又は少なくとも１つの符号化決定、及び／又は少なくとも１つの復号決定に関連付けられる、請求項２０に記載のデバイス。
【請求項22】
電子回路を備えるデバイスであって、前記電子回路が、体験品質を取得するために関与する制約フラグのグループを定義する体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、前記識別子が、前記関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、
前記識別子に準拠する符号化されたビデオストリームを取得することと、
前記符号化されたビデオストリームを遠隔システムに送信することと、を行うように適合されている、デバイス。
【請求項23】
前記符号化されたビデオストリームが、前記識別子に基づいてビデオエンコーダを調整することによって取得される、請求項２２に記載のデバイス。
【請求項24】
前記調整することが、前記識別子によって指定された前記値に応じて、前記制約フラグのグループと関連付けられた符号化ツールをアクティブ化又は非アクティブ化することを含む、請求項２３に記載のデバイス。
【請求項25】
前記識別子が、前記制約フラグ及び任意のプロファイルとは無関係に、ビデオエンコーダの特定の実装を定義することを可能にする、少なくとも１つの符号化決定を指定するために更に使用される、請求項２２、２３、又は２４に記載のデバイス。
【請求項26】
前記識別子が、セッション記述プロトコルメッセージにおいて、前記遠隔システムから取得される、請求項２２～２５のいずれか一項に記載のデバイス。
【請求項27】
前記識別子が、アクティブ化若しくは非アクティブ化され得る符号化ツール、又は選択され得る体験品質のセットを指定するセッション記述プロトコルメッセージの前記遠隔システムへの送信を含む、前記遠隔システムとの能力交換の段階の後に取得される、請求項２２～２６のいずれか一項に記載のデバイス。
【請求項28】
前記識別子を取得する前に、前記方法が、ＳＥＩメッセージで選択され得る体験品質のセットの記述を前記遠隔システムに送信することを含む、請求項２２～２６のいずれか一項に記載のデバイス。
【請求項29】
前記セットのうちの各体験品質が、制約フラグの対応するグループ、及び／又は少なくとも１つの符号化決定、及び／又は少なくとも１つの復号決定に関連付けられる、請求項２８に記載の方法。
【請求項30】
請求項１～１４のいずれか一項に記載の方法を実装するためのプログラムコード命令を含む、コンピュータプログラム。
【請求項31】
請求項１～１４のいずれか一項に記載の方法を実装するためのプログラムコード命令を記憶する、非一時的情報記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本実施形態のうちの少なくとも１つは、概して、低遅延ストリーミングアプリケーションにおけるビデオデータの微調整を可能にする方法、装置、及び信号に関する。
【背景技術】
【0002】
ストリーミングアプリケーションは、近年非常に成長している。当初、ストリーミングアプリケーションは、純粋なオーディオ及び／又はビデオアプリケーションに対処していたが、それらは、現在、ゲームアプリケーションの領域などの新しい領域に及んでいる。
【0003】
ゲームアプリケーションは、実際に、オンデバイスからクラウドホスト型アプリケーションに移行している。クラウドゲーミングは、ゲームレンダリングプロセスをクラウド内に位置するいくつかの遠隔ゲームサーバに部分的にオフロードすることを可能にする。
【0004】
図１Ａは、クラウドゲーミングシステムを概略的に表す。基本的に、高価かつ電力を消費するデバイスを必要とするゲームエンジン１０及び３Ｄグラフィックスレンダリング１１が、クラウド内のサーバ１によって実装される。次いで、生成されたピクチャが、通常／標準ビデオエンコーダ１２を用いてビデオストリームに古典的に符号化され、ネットワーク３を介してユーザゲームシステム２に送信される。ユーザゲームシステム２は、例えば、ＰＣ又はゲームコンソールである。ここでは、本発明者らは、ユーザゲームシステムが入力デバイス（ジョイパッド又はキーボードなど）を備えると仮定する。ビデオストリームは、次いで、ディスプレイデバイス上でレンダリングするために、通常／標準ビデオデコーダ２０を用いてユーザゲームシステム２側で復号される。以下で登録モジュールと呼ばれる追加の軽量モジュール２１は、ゲーマ対話コマンドの管理を担当する（すなわち、ユーザアクションの登録を担当する）。
【0005】
ゲームアプリケーションにおけるユーザの快適さのための１つの重要な因子は、モーションツーフォトンと呼ばれるレイテンシ、すなわち、ユーザアクション（モーション）と、ディスプレイデバイス上のこのアクションの結果の表示（フォトン）との間のレイテンシである。
【0006】
図１Ｂは、クラウドゲームアプリケーションにおける典型的なモーションツーフォトン経路を概略的に説明する。
【0007】
【0008】
ステップ１００では、ゲームシステム２側で、ユーザアクションが入力デバイスによって登録され、メイン処理モジュールに送信される。
【0009】
ステップ１０１では、ユーザアクションを表す情報が、ネットワーク３を介してサーバ１に送信される。
【0010】
ステップ１０２では、登録されたアクションは、次のゲーム状態（又は複数の次のゲーム状態）を計算するためにゲームエンジン１０によって使用される。ゲーム状態は、ユーザ状態（位置など）、及びゲームエンジン１０によって計算され得る全ての他のエンティティ状態、又はマルチプレーヤゲームの場合には外部状態を含む。
【0011】
ステップ１０３では、ゲーム状態から、ピクチャレンダリングが計算される。
【0012】
レンダリングの後に、ステップ１０４で、ビデオエンコーダ１２による、ビデオストリーム内のレンダリングされたピクチャのビデオ符号化が続く。
【0013】
ビデオエンコーダ１２によって生成されたビデオストリームは、次いで、ステップ１０５で、ネットワーク３を介してユーザゲームシステム２に送信され、ステップ１０６で、ビデオデコーダ２０によって復号される。
【0014】
次いで、結果的に得られたピクチャが、ステップ１０７で、ディスプレイデバイス上に表示される。
【0015】
上記のステップの各々は、処理レイテンシを導入する。図１Ｂでは、ドット付き背景を有するボックスは、ハードウェア計算に起因するレイテンシを導入するステップを表す。一般に、このレイテンシは固定されており、小さく、容易に変更され得る。白い背景を有するボックスは、ソフトウェア計算に起因するレイテンシを導入するステップを表す。一般に、このレイテンシは、より長く、動的に適合され得る。
【0016】
図１Ｂのモーションツーフォトン経路では、符号化及び復号プロセスが顕著なレイテンシを導入する。しかしながら、これらのレイテンシは、アプリケーション制約又はユーザの希望に応じて動的に適合され得る典型的なレイテンシである。
【0017】
ゲームは、ユーザ（ゲーマ）が、可能な限り高い品質でゲームを楽しむために、又は最も反応性が高く高速なユーザ体験を得るために、ユーザに利用可能にされた任意のパラメータを調整するために使用される領域である。ゲーマは、一般に、より少ないゲーム遅延のために視覚品質を引き換えにしている。しかしながら、クラウドゲーミングでは、非常に限られた量のパラメータがエンドユーザに利用可能にされる。クラウドゲーミングアプリケーションにおけるビデオコーデックの計算コスト、レイテンシ、及びレンダリングを細かく制御することを目的とするツールが有益であろう。同様に、ヘッドマウントディスプレイ（head mounted display、ＨＭＤ）ベースのアプリケーション、又は拡張現実／仮想現実（augmented reality/virtual reality、ＡＲ／ＶＲ）眼鏡ベースのアプリケーションなどの他のアプリケーション、更には任意の低遅延ストリーミングアプリケーションは、ビデオコーデックのこの細かい制御／調整の恩恵を受けることになる。
【0018】
上記問題を克服することを可能にする解決策を提案することが望ましい。特に、ストリーミングアプリケーションにおけるコーデックの微調整を可能にする解決策を提案することが望ましい。この解決策は、ゲーマが、ゲームの応答性とゲーマに最良に適しているディスプレイの品質との間の最良の妥協点を見つけることを可能にするために、クラウドゲーミングコンテキストに特に適合されることになる。
【発明の概要】
【0019】
第１の態様では、本発明の実施形態のうちの１つ以上は、方法であって、所望の体験品質を取得するために関与する制約フラグのグループを定義する所望の体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、識別子が、関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、識別子を遠隔サーバに送信することと、識別子に準拠するビデオストリームを遠隔サーバから受信することと、を含む、方法を提供する。
【0020】
一実施形態では、識別子は、ビデオデコーダが、ビデオストリームにおいて指定された少なくとも１つの復号プロセスをスキップするように、又はビデオデコーダが、少なくとも１つの追加の復号プロセスをビデオストリームにおいて指定された復号プロセスに追加するように、ビデオデコーダを調整することを可能にする復号決定を定義するために更に使用される。
【0021】
一実施形態では、識別子が、セッション記述プロトコルを使用して送信される。
【0022】
一実施形態では、識別子が、アクティブ化若しくは非アクティブ化され得る符号化ツール、又は選択され得る体験品質のセットを指定するセッション記述プロトコルメッセージの遠隔サーバからの受信を含む、遠隔サーバとの能力交換の段階の後に取得される。
【0023】
一実施形態では、識別子を取得する前に、方法が、ＳＥＩメッセージで選択され得る体験品質のセットの記述を取得することを含む。
【0024】
一実施形態では、セットのうちの各体験品質が、制約フラグの対応するグループ、及び／又は少なくとも１つの符号化決定、及び／又は少なくとも１つの復号決定に関連付けられる。
【0025】
第２の態様では、本発明の実施形態のうちの１つ以上は、方法であって、所望の体験品質を取得するために関与する制約フラグのグループを定義する所望の体験品質の識別子を取得することであって、各制約フラグが、ビデオエンコーダの関連付けられた符号化ツールをアクティブ化又は非アクティブ化するために使用され、識別子が、関連付けられた符号化ツールのアクティブ化又は非アクティブ化を示す各制約フラグに対する値を指定する、取得することと、識別子に準拠する符号化されたビデオストリームを取得することと、符号化されたビデオストリームを遠隔システムに送信することと、を含む、方法を提供する。
【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】
【図1A】いくつかの実施形態が実施され得るコンテキストの一例を説明する。
【図1B】モーションツーフォトン経路の概念を例解する。
【図2】ストリーミングアプリケーションにおけるコーデックの微調整を可能にする方法の第１の実施形態を概略的に例解する。
【図3】ストリーミングアプリケーションにおけるコーデックの微調整を可能にする方法の第２の実施形態を概略的に描示する。
【図4】ストリーミングアプリケーションにおけるコーデックの微調整を可能にする方法の第３の実施形態を概略的に描示する。
【図5A】様々な態様及び実施形態が実装される処理モジュールのハードウェアアーキテクチャの一例を概略的に例解する。
【図5B】様々な態様及び実施形態が実装されるゲームシステムの一例のブロック図を例解する。
【図5C】様々な態様及び実施形態が実装されるサーバの一例のブロック図を例解する。
【図6】元のビデオのピクセルのピクチャが受ける分割の一例を例解する。
【図7】符号化モジュールによって実行されるビデオストリームを符号化するための方法を概略的に描示する。
【図8】復号モジュールによって実行されるビデオストリームを復号するための方法を概略的に描示する。
【図9】一実施形態による、ＲＴＰ／ＲＴＳＰセッションベースのストリーミングを使用する、クライアントとサーバとの間のストリーミングセッション確立プロセスを例解する。
【発明を実施するための形態】
【0051】
以下では、本発明者らは、ストリーミングアプリケーションにおけるコーデックの微調整を可能にする実施形態の例を提示し、これらの解決策は、クラウドゲーミングアプリケーションなどの低遅延ストリーミングアプリケーションに特に適合される。ストリーミング及び／又はゲーミングの文脈では、以下の調整解決策に言及することができる。
● デバイス及びネットワーク設定の調節：ゲーマによって一般的に調節されるデバイス設定の例は、グラフィックカードドライバを更新すること、より高性能なグラフィックカードがデバイス上で利用可能であるときにネイティブグラフィックカードを無効化すること、ハードウェア（ＰＣ及びルータ）を最適化すること、ＷｉＦｉではなくイーサネットに接続すること、ルータパラメータを調節すること、ネットワークを変更すること、ユーザにより近いサーバを選択することである。
● ゲーム設定の調節：調節され得るゲーム内設定の例（一般的に、１秒当たりのフレーム数（frame per second、ｆｐｓ）を増加させるために）：
○ 解像度を低下させること、
○ ピクチャ内の詳細の量を低下させること、
○ アンチエイリアシング、モーションブラーモード、及びデバイス上で実施され得る他の高度なレンダリングパラメータを無効化又は変更すること。
● 開発者設定：ゲーム開発者がそのゲーム及び開発を適合させるためにゲーマ体験を監視するためのツールが出現している。デバイス上のｆｐｓ及びＣＰＵ使用量は、開発者によってゲームプレイに組み込まれた注釈（アンカー）に基づいて追跡及び集計される。そのようなツールの一例は、ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ｇａｍｅｓ／ｓｄｋ／ｐｅｒｆｏｒｍａｎｃｅ－ｔｕｎｅｒで説明されるＡｎｄｒｏｉｄ Ｐｅｒｆｏｒｍａｎｃｅ Ｔｕｎｅｒである。
● ビデオコーデックプロファイル：ビデオコーデックプロファイルは、ビデオエンコーダによって使用され得、かつビデオデコーダによってサポートされるものとする固定されたツールのセットを定義する。これらのプロファイルは、多数のサービスにわたるデバイスの相互運用性を確保するのに有用である。クローズドＯＴＴ（オーバザトップ）エコシステムでは、プライベートコーデック又はプライベートプロファイルが、エンドポイント上のアプリケーションとともにロードされ得る。しかしながら、他のサービスとの相互運用性は要件ではなく、それは、ハードウェア実装から恩恵を受けないエンドデバイス上で計算コストがかかるため、クラウドゲーミングなどの要求の厳しいアプリケーションにとって、阻害要因、又は更には技術的負担となり得る。
● ＶＶＣフラグ：ＶＶＣ（Ｈ．２６６、ＩＳＯ／ＩＥＣ２３０９０－３、ＭＰＥＧ－Ｉ Ｐａｒｔ３（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ））と呼ばれる最近のビデオコーデックでは、コーディングツールは、ハイレベルシンタックス要素（制約フラグと呼ばれる）によって有効化／無効化されて、特定の符号化ツールが所与のビットストリームに対するエンコーダによって使用されなかったことを示し得る。ＶＶＣでは、制約フラグは、ｇｅｎｅｒａｌ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｉｎｆｏと呼ばれるデータ構造に集められる。これによると、ビットストリームは、特定のツールを使用しないものとしてラベル付けされ得、これは、とりわけ、デコーダ実装におけるリソース割り当てを可能にする。
● 能力交換：ストリーミングサービス及びファイルダウンロードのために、マルチメディア能力情報の交換がエンドデバイスとサーバとの間で行われる。これは、体験品質（Ｑｕａｌｉｔｙ Ｏｆ Ｅｘｐｅｒｉｅｎｃｅ、ＱｏＥ）の使用によって、コンテンツをデバイス及び／又はネットワーク能力に適合させることを可能にする。これらのデバイス能力情報は、通常、ハンドシェイクプロトコル及びトランスポートプロトコルフォーマットの一部として指定される。例：
○ ３ＧＰＰ ＴＳ ２３．２３４「Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ－ｔｏ－ｅｎｄ Ｐａｃｋｅｔ－ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）」は、デバイス能力が交換され、サーバがこれらのデバイスに好適なコンテンツを広範囲のデバイスに提供することを可能にするＳＤＰ（セッション記述プロトコル）ベースの通信がそれに続く、セッション確立プロセスを指定する。しかしながら、能力情報のこれらの交換は、ＶＶＣ制約フラグにも、所望のユーザ体験品質設定にも関連しない。
○ ３ＧＰＰ ＳＡ４ ＭＴＳＩ仕様（ＴＳ２６．１１４）は、メディアデータをトランスポートするためのＲＴＰ（リアルタイムトランスポートプロトコル（Ｒｅａｌ－Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ））、並びにＲＴＰ／ＡＶＰＦ（ＲＦＣ４５８５）及びＳＤＰＣａｐＮｅｇ（ＲＦＣ５９３９）において定義されたＳＤＰ機構を使用する。所望のユーザ体験品質に関連する情報交換は、ほとんどない。
○ ３ＧＰＰ ５ＧＭＳ仕様（５Ｇマルチメディアストリーミング）は、ＨＴＴＰを介してメディアを送信するために、ＭＰＥＧ ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ／ＩＳＯ／ＩＥＣ ２３００９－１：２０１ｘ）又はＩＳＯファイルフォーマットに依存する。したがって、コンテンツ選択が調整され得る一方で、５ＧＭＳ仕様におけるこれらのトランスポートプロトコルの使用は、現時点では、ゲーミングアプリケーションなどのレイテンシアプリケーションにおいて低いコーデックの微調整には適していない。
● デバイス及びネットワーク設定の調節：ゲーマによって一般的に調節されるデバイス設定の例は、グラフィックカードドライバを更新すること、より高性能なグラフィックカードがデバイス上で利用可能であるときにネイティブグラフィックカードを無効化すること、ハードウェア（ＰＣ及びルータ）を最適化すること、ＷｉＦｉではなくイーサネットに接続すること、ルータパラメータを調節すること、ネットワークを変更すること、ユーザにより近いサーバを選択することである。
● ゲーム設定の調節：調節され得るゲーム内設定の例（一般的に、１秒当たりのフレーム数（frame per second、ｆｐｓ）を増加させるために）：
○ 解像度を低下させること、
○ ピクチャ内の詳細の量を低下させること、
○ アンチエイリアシング、モーションブラーモード、及びデバイス上で実施され得る他の高度なレンダリングパラメータを無効化又は変更すること。
● 開発者設定：ゲーム開発者がそのゲーム及び開発を適合させるためにゲーマ体験を監視するためのツールが出現している。デバイス上のｆｐｓ及びＣＰＵ使用量は、開発者によってゲームプレイに組み込まれた注釈（アンカー）に基づいて追跡及び集計される。そのようなツールの一例は、ｈｔｔｐｓ：／／ｄｅｖｅｌｏｐｅｒ．ａｎｄｒｏｉｄ．ｃｏｍ／ｇａｍｅｓ／ｓｄｋ／ｐｅｒｆｏｒｍａｎｃｅ－ｔｕｎｅｒで説明されるＡｎｄｒｏｉｄ Ｐｅｒｆｏｒｍａｎｃｅ Ｔｕｎｅｒである。
● ビデオコーデックプロファイル：ビデオコーデックプロファイルは、ビデオエンコーダによって使用され得、かつビデオデコーダによってサポートされるものとする固定されたツールのセットを定義する。これらのプロファイルは、多数のサービスにわたるデバイスの相互運用性を確保するのに有用である。クローズドＯＴＴ（オーバザトップ）エコシステムでは、プライベートコーデック又はプライベートプロファイルが、エンドポイント上のアプリケーションとともにロードされ得る。しかしながら、他のサービスとの相互運用性は要件ではなく、それは、ハードウェア実装から恩恵を受けないエンドデバイス上で計算コストがかかるため、クラウドゲーミングなどの要求の厳しいアプリケーションにとって、阻害要因、又は更には技術的負担となり得る。
● ＶＶＣフラグ：ＶＶＣ（Ｈ．２６６、ＩＳＯ／ＩＥＣ２３０９０－３、ＭＰＥＧ－Ｉ Ｐａｒｔ３（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ））と呼ばれる最近のビデオコーデックでは、コーディングツールは、ハイレベルシンタックス要素（制約フラグと呼ばれる）によって有効化／無効化されて、特定の符号化ツールが所与のビットストリームに対するエンコーダによって使用されなかったことを示し得る。ＶＶＣでは、制約フラグは、ｇｅｎｅｒａｌ＿ｃｏｎｓｔｒａｉｎｔｓ＿ｉｎｆｏと呼ばれるデータ構造に集められる。これによると、ビットストリームは、特定のツールを使用しないものとしてラベル付けされ得、これは、とりわけ、デコーダ実装におけるリソース割り当てを可能にする。
● 能力交換：ストリーミングサービス及びファイルダウンロードのために、マルチメディア能力情報の交換がエンドデバイスとサーバとの間で行われる。これは、体験品質（Ｑｕａｌｉｔｙ Ｏｆ Ｅｘｐｅｒｉｅｎｃｅ、ＱｏＥ）の使用によって、コンテンツをデバイス及び／又はネットワーク能力に適合させることを可能にする。これらのデバイス能力情報は、通常、ハンドシェイクプロトコル及びトランスポートプロトコルフォーマットの一部として指定される。例：
○ ３ＧＰＰ ＴＳ ２３．２３４「Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ－ｔｏ－ｅｎｄ Ｐａｃｋｅｔ－ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）」は、デバイス能力が交換され、サーバがこれらのデバイスに好適なコンテンツを広範囲のデバイスに提供することを可能にするＳＤＰ（セッション記述プロトコル）ベースの通信がそれに続く、セッション確立プロセスを指定する。しかしながら、能力情報のこれらの交換は、ＶＶＣ制約フラグにも、所望のユーザ体験品質設定にも関連しない。
○ ３ＧＰＰ ＳＡ４ ＭＴＳＩ仕様（ＴＳ２６．１１４）は、メディアデータをトランスポートするためのＲＴＰ（リアルタイムトランスポートプロトコル（Ｒｅａｌ－Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ））、並びにＲＴＰ／ＡＶＰＦ（ＲＦＣ４５８５）及びＳＤＰＣａｐＮｅｇ（ＲＦＣ５９３９）において定義されたＳＤＰ機構を使用する。所望のユーザ体験品質に関連する情報交換は、ほとんどない。
○ ３ＧＰＰ ５ＧＭＳ仕様（５Ｇマルチメディアストリーミング）は、ＨＴＴＰを介してメディアを送信するために、ＭＰＥＧ ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ／ＩＳＯ／ＩＥＣ ２３００９－１：２０１ｘ）又はＩＳＯファイルフォーマットに依存する。したがって、コンテンツ選択が調整され得る一方で、５ＧＭＳ仕様におけるこれらのトランスポートプロトコルの使用は、現時点では、ゲーミングアプリケーションなどのレイテンシアプリケーションにおいて低いコーデックの微調整には適していない。
【0052】
ビデオコーデックプロファイル及び制約フラグに関して上記で見られるように、コーデックを制御するための解決策が存在する。しかしながら、それらの現在の形態では、これらの解決策は、クラウドゲーミングアプリケーションなどの低遅延ストリーミングアプリケーションにおいてユーザがコーデックを微調整することを可能にするように適合されていない。
【0053】
図５Ａは、例えば、ビデオエンコーダ１２及び／若しくはゲームエンジン１０及び／若しくは３Ｄグラフィックスレンダラ１１などのサーバ１のモジュール、又は、例えば、ビデオデコーダ２０及び／又は登録モジュール２１などのゲームシステム２のモジュールを実装することができる処理モジュール５００のハードウェアアーキテクチャの一例を概略的に例解する。
【0054】
処理モジュール５００は、非限定的な例として、通信バス５００５によって接続された、１つ以上のマイクロプロセッサ、汎用コンピュータ、専用コンピュータ、及びマルチコアアーキテクチャに基づくプロセッサを包含するプロセッサ又はＣＰＵ（中央処理ユニット）５０００と、ランダムアクセスメモリ（random access memory、ＲＡＭ）５００１と、リードオンリーメモリ（read only memory、ＲＯＭ）５００２と、電気的消去可能プログラマブルリードオンリーメモリ（Electrically Erasable Programmable Read-Only Memory、ＥＥＰＲＯＭ）、リードオンリーメモリ（ＲＯＭ）、プログラマブルリードオンリーメモリ（Programmable Read-Only Memory、ＰＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（Dynamic Random Access Memory、ＤＲＡＭ）、スタティックランダムアクセスメモリ（Static Random Access Memory、ＳＲＡＭ）、フラッシュ、磁気ディスクドライブ、並びに／又は光ディスクドライブ、又は、ＳＤ（セキュアデジタル、ｓｅｃｕｒｅ ｄｉｇｉｔａｌ）カードリーダ及び／若しくはハードディスクドライブ（hard disc drive、ＨＤＤ）などの記憶媒体リーダ及び／若しくはネットワークアクセス可能な記憶デバイスを含むがこれらに限定されない不揮発性メモリ及び／若しくは揮発性メモリを含むことができる記憶ユニット５００３と、データを他のモジュール、デバイス、又は機器と交換するための少なくとも１つの通信インターフェース５００４と、を備える。通信インターフェース５００４は、限定されるものではないが、通信チャネル（又はネットワーク）３を介してデータを送信及び受信するように構成された送受信機を含み得る。通信インターフェース５００４は、モデム又はネットワークカードを含むことができるが、これらに限定されない。
【0055】
処理モジュール５００がビデオデコーダ２０を実装する場合、通信インターフェース５００４は、例えば、処理モジュール５００が、符号化されたビデオストリームを受信し、復号されたピクチャのシーケンスを提供することを可能にする。
【0056】
処理モジュール５００が登録モジュール２１を実装する場合、通信インターフェース５００４は、例えば、処理モジュール５００が、ユーザによって選択されたユーザアクション又はパラメータを受信し、これらのユーザアクション及びパラメータを表すデータをゲームエンジン１０及び／又はビデオデコーダ２０に提供することを可能にする。
【0057】
処理モジュール５００がビデオエンコーダ１２を実装する場合、通信インターフェース５００４は、例えば、処理モジュール５００が、３Ｄグラフィックスレンダラ１１によって生成されたピクチャを受信し、かつこれらのピクチャを表す符号化されたビデオストリームを提供することを可能にする。
【0058】
処理モジュール５００がゲームエンジン１０を実装する場合、通信インターフェース５００４は、例えば、処理モジュール５００が、ユーザアクション及び選択されたパラメータを表すデータを受信し、かつこれらのデータを３Ｄグラフィックスレンダラ及び／又はビデオエンコーダ１２に提供することを可能にする。
【0059】
処理モジュール５００が３Ｄグラフィックスレンダラ１１を実装する場合、通信インターフェース５００４は、例えば、処理モジュール５００が対応するピクチャを生成することができるように、ユーザアクション及び／又は選択されたパラメータを表すデータを受信し、かつ生成されたピクチャをビデオエンコーダ１２に送信することを処理モジュール５００に可能にする。
【0060】
プロセッサ５０００は、ＲＯＭ５００２、外部メモリ（図示せず）、記憶媒体、又は通信ネットワークからＲＡＭ５００１にロードされた命令を実行することができる。処理モジュール５００の電源が投入されると、プロセッサ５０００は、ＲＡＭ５００１から命令を読み出し、それらを実行することができる。これらの命令は、例えば、復号方法、符号化方法、ゲームエンジン１０、３Ｄグラフィックスレンダラ１１、登録モジュール２１によって実行されるプロセス、並びに本明細書で以下に説明される図２、図３、及び図４に関連して説明されるプロセスの一部のプロセッサ５０００による実装を引き起こすコンピュータプログラムを形成する。
【0061】
符号化又は復号方法のアルゴリズム及びステップの全て又は一部は、ＤＳＰ（デジタル信号プロセッサ、ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）若しくはマイクロコントローラなどのプログラマブルマシンによる命令セットの実行によってソフトウェア形態で実装され得るか、又はＦＰＧＡ（フィールドプログラマブルゲートアレイ、ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）若しくはＡＳＩＣ（特定用途向け集積回路、ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）などのマシン若しくは専用コンポーネントによってハードウェア形態で実装され得る。
【0062】
図５Ｃは、様々な態様及び実施形態が実装されているシステム２の一例のブロック図を例解する。ゲームシステム２は、上記に説明された様々な構成要素（すなわち、登録モジュール２１及びビデオデコーダ２０）を含むデバイスとして具現化され得、本明細書に説明される態様及び実施形態のうちの１つ以上を実施するように構成されている。そのようなデバイスの例としては、限定されるものではないが、パーソナルコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、ヘッドマウントディスプレイ、及びゲームコンソールなどの様々な電子デバイスが挙げられる。ゲームシステム２の要素は、単独で又は組み合わせて、１つの集積回路（integrated circuit、ＩＣ）、複数のＩＣ、及び／又は別個の構成要素において具現化され得る。例えば、少なくとも１つの実施形態では、ゲームシステム２は、ビデオデコーダ２０及び登録モジュール２１を実装する１つの処理モジュール５００を備える。様々な実施形態では、ゲームシステム２は、例えば、通信バスを介して、又は専用の入力ポート及び／若しくは出力ポートを通して、１つ以上の他のシステム又は他の電子デバイスに通信可能に結合される。様々な実施形態では、ゲームシステム２は、本明細書に説明される態様のうちの１つ以上を実装するように構成されている。
【0063】
処理モジュール５００への入力は、ブロック５３１に示すように様々な入力モジュールを介して提供することができる。そのような入力モジュールは、限定されるものではないが、（ｉ）例えば、無線で送信される無線周波数（radio frequency、ＲＦ）信号を受信するＲＦモジュールを含む。
【0064】
様々な実施形態では、ブロック５３１の入力モジュールは、当技術分野で既知のように、関連するそれぞれの入力処理要素を有する。例えば、ＲＦモジュールは、（ｉ）所望の周波数を選択する（信号を選択する、又は信号を周波数帯域に帯域制限するとも称される）、（ｉｉ）選択された信号をダウンコンバートする、（ｉｉｉ）特定の実施形態で、（例えば）チャネルと称され得る信号周波数帯域を選択するために、再びより狭い周波数帯域に帯域制限する、（ｉｖ）ダウンコンバート及び帯域制限された信号を復調する、（ｖ）誤り訂正を実施する、並びに（ｖｉ）データパケットの所望のストリームを選択するために多重分離する、ために好適な要素と関連付けられ得る。様々な実施形態のＲＦモジュールは、これらの機能を実行する１つ以上の要素、例えば、周波数セレクタ、信号セレクタ、バンドリミッタ、チャネルセレクタ、フィルタ、ダウンコンバータ、復調器、エラー訂正器、及びデマルチプレクサを含む。ＲＦ部分は、例えば、受信信号をより低い周波数（例えば、中間周波数又はベースバンドに近い周波数）又はベースバンドにダウンコンバートすることを含む、これらの機能のうちの様々な機能を実行するチューナを含むことができる。一実施形態では、ＲＦモジュール及びその関連付けられた入力処理要素は、有線（例えば、ケーブル）媒体を介して送信されるＲＦ信号を受信し、所望の周波数帯域にフィルタリング、ダウンコンバート、及び再フィルタリングすることによって周波数選択を実施する。様々な実施形態では、上で説明される（及び他の）要素の順序を並べ替える、これらの要素の一部を削除する、並びに／又は、類似若しくは異なる機能を実行する他の要素を追加する。要素を追加することは、例えば、増幅器及びアナログ－デジタル変換器を挿入するなど、既存の要素間に要素を挿入することを含み得る。様々な実施形態では、ＲＦモジュールは、アンテナを含む。
【0065】
ゲームシステム２の様々な要素は、一体型ハウジング内に提供され得る。一体型ハウジング内で、様々な要素は、好適な接続配置、例えば、ＩＣ間（Ｉ２Ｃ）バス、配線、及びプリント回路基板を含む、当該技術分野で既知の内部バスを使用して、相互接続され、それらの間でデータを送信し得る。例えば、ゲームシステム２では、処理モジュール５００は、バス５００５によってゲームシステム２の他の要素に相互接続される。
【0066】
処理モジュール５００の通信インターフェース５００４は、ゲームシステム２が通信チャネル３上で通信することを可能にする。上で既に言及されているように、通信チャネル３は、例えば、有線及び／又は無線媒体内に実装され得る。
【0067】
データは、様々な実施形態では、Ｗｉ－Ｆｉネットワーク、例えば、ＩＥＥＥ８０２．１１（ＩＥＥＥは、米国電気電子技術者協会（Institute of Electrical and Electronics Engineers）を指す）などの無線ネットワークを使用して、ゲームシステム２にストリーミングされるか、又は別様に提供される。これらの実施形態のＷｉ－Ｆｉ信号は、Ｗｉ－Ｆｉ通信に適合されている通信チャネル３及び通信インターフェース５００４を介して受信される。これらの実施形態の通信チャネル３は、典型的には、ストリーミングアプリケーション及び他のオーバザトップ通信を可能にするために、インターネットを含む外部ネットワークへのアクセスを提供するアクセスポイント又はルータに接続される。他の実施形態では、入力ブロック５３１のＲＦ接続を使用して、ゲームシステム２にストリーミングされたデータを提供する。追加的に、様々な実施形態は、Ｗｉ－Ｆｉ以外の無線ネットワーク、例えば、セルラネットワークを使用する。
【0068】
ゲームシステム２は、ディスプレイシステム５５、スピーカ５６、及び他の周辺デバイス５７を含む様々な出力デバイスに出力信号を提供することができる。様々な実施形態のディスプレイシステム５５は、例えば、タッチスクリーンディスプレイ、有機発光ダイオード（organic light-emitting diode、ＯＬＥＤ）ディスプレイ、湾曲ディスプレイ、及び／又は折り畳み可能なディスプレイのうちの１つ以上を含む。ディスプレイシステム５５は、テレビジョン、タブレット、ラップトップ、携帯電話（移動電話）、ヘッドマウントディスプレイ、又は他のデバイス用とすることができる。ディスプレイシステム５５はまた、例えば、スマートフォンのように、他の構成要素と統合され得るか、又は別個、例えば、ラップトップ用の外部モニタとすることができる。他の周辺デバイス５７としては、実施形態の様々な実施例において、スタンドアロンデジタルビデオディスク（又はデジタル多用途ディスク）（両方の用語について、digital versatile disc、ＤＶＲ）、ディスクプレーヤ、ステレオシステム、及び／又は照明システム、のうちの１つ以上が挙げられる。様々な実施形態は、ゲームシステム２の出力に基づいて機能を提供する１つ以上の周辺デバイス５７を使用する。例えば、ディスクプレーヤは、ゲームシステム２の出力を再生する機能を実施する。
【0069】
様々な実施形態では、制御信号が、ゲームシステム２と、ディスプレイシステム５５、スピーカ５６、又は他の周辺デバイス５７との間で、ＡＶ．Ｌｉｎｋ、家庭用電子制御（Consumer Electronics Control、ＣＥＣ）、又はユーザ介入の有無にかかわらずデバイス間の制御を可能にする他の通信プロトコルなどのシグナリングを使用して通信される。出力デバイスは、それぞれのインターフェース５３２、５３３、及び５３４を通した専用接続を介して、ゲームシステム２に通信可能に結合され得る。代替的に、出力デバイスは、通信インターフェース５００４を介して通信チャネル３を使用して、又は通信インターフェース５００４を介して専用通信チャネルを使用して、ゲームシステム２に接続され得る。ディスプレイシステム５５及びスピーカ５６は、例えば、ゲームコンソールなどの電子デバイスにおいてゲームシステム２の他の構成要素と１つのユニットに一体化され得る。様々な実施形態では、ディスプレイインターフェース５３２は、例えば、タイミングコントローラ（timing controller、Ｔ Ｃｏｎ）チップなどのディスプレイドライバを含む。
【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】
ピクチャは、複数のコーディングエンティティに分割される。まず、図６の参照番号６３によって表されるように、ピクチャがコーディングツリーユニット（coding tree unit、ＣＴＵ）と呼ばれるブロックのグリッドに分割される。ＣＴＵは、輝度サンプルのＮ×Ｎブロックと、クロミナンスサンプルの２つの対応するブロックとで構成される。Ｎは、一般に、例えば、「１２８」の最大値を有する２のべき乗である。第二に、ピクチャは、ＣＴＵの１つ以上のグループに分割される。例えば、ピクチャは、１つ以上のタイル行及びタイル列に分割することができ、タイルは、ピクチャの矩形領域をカバーするＣＴＵのシーケンスである。場合によっては、タイルは、１つ以上のブリックに分割され得、その各々は、タイル内の少なくとも１つのＣＴＵ行からなる。特定タイプのタイルは、他のタイルのサンプルからの空間的予測及び時間的予測を妨げる。これらのタイルは、サブピクチャと呼ばれる。タイル及びブリックの概念の上には、ピクチャの少なくとも１つのタイル又はタイルの少なくとも１つのブリックを含むことができるスライスと呼ばれる別の符号化エンティティが存在する。
【0095】
図６の例では、参照番号６２によって表されるように、ピクチャ６１は、各々が複数のタイル（図示せず）を含むラスタスキャンスライスモードの３つのスライスＳ１、Ｓ２、及びＳ３に分割され、各タイルは、１つのブリックのみを含む。
【0096】
図６の参照番号６４によって表されるように、ＣＴＵは、コーディングユニット（ＣＵ）と呼ばれる１つ以上のサブブロックの階層ツリーの形態に分割され得る。ＣＴＵは、階層ツリーのルート（すなわち、親ノード）であり、複数のＣＵ（すなわち、子ノード）に分割され得る。各ＣＵは、より小さいＣＵに更に分割されていない場合は階層ツリーのリーフになり、更に分割されている場合はより小さいＣＵ（すなわち、子ノード）の親ノードになる。
【0097】
図６の例では、ＣＴＵ１４は、四分木タイプの分割を使用して、最初に「４」つの方形ＣＵに分割される。左上のＣＵは、更に分割されていないため、階層ツリーのリーフであり、すなわち、他のＣＵの親ノードではない。右上のＣＵは、やはり四分木タイプの分割を使用して、「４」つのより小さい正方形ＣＵに更に分割される。右下のＣＵは、二分木タイプの分割を使用して「２」つの矩形ＣＵに垂直に分割される。左下のＣＵは、三分木タイプの分割を使用して「３」つの矩形ＣＵに垂直に分割される。
【0098】
ピクチャのコーディング中、分割は、適合的であり、各ＣＴＵは、ＣＴＵ基準の圧縮効率を最適化するように分割される。
【0099】
ＨＥＶＣでは、予測ユニット（prediction unit、ＰＵ）及び変換ユニット（transform unit、ＴＵ）の概念が登場した。実際、ＨＥＶＣでは、予測（すなわち、ＰＵ）及び変換（すなわち、ＴＵ）に使用される符号化エンティティは、ＣＵの部分であり得る。例えば、図６に表されるように、サイズ２Ｎ×２ＮのＣＵは、サイズＮ×２Ｎ又はサイズ２Ｎ×ＮのＰＵ６４１１に分割され得る。更に、当該ＣＵは、サイズＮ×Ｎの「４」個のＴＵ６４１２又はサイズ
【0100】
【数1】
の「１６」個のＴＵに分割され得る。
【0101】
ＶＶＣでは、いくつかの特定の場合を除いて、ＴＵ及びＰＵのフロンティアが、ＣＵのフロンティアに位置合わせされることが留意され得る。したがって、ＣＵは、一般に、１つのＴＵ及び１つのＰＵを含む。
【0102】
本出願では、「ブロック」又は「ピクチャブロック」という用語は、ＣＴＵ、ＣＵ、ＰＵ、及びＴＵのうちのいずれか１つを指すために使用することができる。更に、「ブロック」又は「ピクチャブロック」という用語は、Ｈ．２６４／ＡＶＣ又は他のビデオ符号化規格で指定されているようなマクロブロック、パーティション、及びサブブロックを指すために使用することができ、より一般的には、多数のサイズのサンプルのアレイを指すために使用することができる。
【0103】
本出願では、「再構成された」及び「復号された」という用語は互換的に使用することができ、「ピクセル」及び「サンプル」という用語は互換的に使用することができ、「画像」、「ピクチャ」、「サブピクチャ」、「スライス」、及び「フレーム」という用語は互換的に使用することができる。通常、必ずしもそうではないが、「再構成された」という用語は、エンコーダ側で使用される一方で、「復号された」という用語は、デコーダ側で使用される。
【0104】
図７は、符号化モジュールによって実行されるビデオストリームを符号化するための方法を概略的に描示する。符号化のためのこの方法の変形例が企図されるが、以下では、明確さを目的として、予想される全ての変形例について説明することなく、図７の符号化のための方法が説明される。図７に関連して説明される全てのステップは、例えば、処理モジュール５００によって、この処理モジュールがビデオエンコーダ１２を実装するときに実行される。
【0105】
符号化される前に、元のビデオシーケンスの現在の元の画像は、前処理を経得る。例えば、ステップ７０１では、色変換が現在の元のピクチャ（例えば、ＲＧＢ４：４：４からＹＣｂＣｒ４：２：０への変換）に適用されるか、又は再マッピングが現在の元のピクチャ成分に適用されて、（例えば、色成分のうちの１つのヒストグラム均等化を使用して）圧縮に対してより弾力的な信号分布が得られる。加えて、前処理６０１は、再サンプリング（ダウンサンプリング又はアップサンプリング）を含み得る。再サンプリングは、生成されたビットストリームが元の解像度のピクチャと別の解像度のピクチャとを（又は、少なくとも２つの異なる解像度の少なくともピクチャを）含み得るように、いくつかのピクチャに適用され得る。再サンプリングは、一般的にダウンサンプリングからなり、生成されたビットストリームのビットレートを低減するために使用される。それにもかかわらず、アップサンプリングも可能である。前処理によって取得されたピクチャは、以下では前処理済みピクチャと呼ばれる。
【0106】
前処理されたピクチャを符号化することは、図６に関連して説明されたように、ステップ７０２中に前処理されたピクチャの分割から始まる。したがって、前処理されたピクチャは、ＣＴＵ、ＣＵ、ＰＵ、ＴＵなどに分割される。各ブロックについて、符号化モジュールは、イントラ予測とインター予測との間のコーディングモードを判定する。
【0107】
イントラ予測は、イントラ予測方法に従って、ステップ７０３中に、コーディングされる現在のブロックの因果的近傍に位置する再構成ブロックのピクセルから導出された予測ブロックから現在のブロックのピクセルを予測することからなる。イントラ予測の結果は、近傍のブロックのどのピクセルを使用するかを示す予測方向と、現在のブロックと予測ブロックとの差の計算から生じる残差ブロックである。最近、新しいイントラ予測モードが提案され、ＶＶＣに導入された。これらの新しいイントラ予測モードは、以下を含む。
● 予測するブロックの左上の再構成された隣接境界サンプルからイントラ予測子を生成するために行列を使用することからなるＭＩＰ（行列ベースのイントラ予測、Ｍａｔｒｉｘ ｗｅｉｇｈｔｅｄ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ）。
● 輝度イントラ予測ブロックを、ブロックサイズに応じて垂直又は水平に２個又は４個のサブパーティションに分割するＩＳＰ（イントラサブパーティション、Ｉｎｔｒａ Ｓｕｂ－Ｐａｒｔｉｔｉｏｎ）。
● ＣＵの彩度サンプルが、線形モデルを使用することによって同一ＣＵの再構成された輝度サンプルに基づいて予測される、ＣＣＬＭ（クロスコンポーネントリニアモデル、Ｃｒｏｓｓ－ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）予測。
● 同一ピクチャの別のブロックからピクチャ内のブロックを予測することからなるＩＢＣ（イントラブロックコピー、Ｉｎｔｒａ Ｂｌｏｃｋ Ｃｏｐｙ）。
● イントラ予測に使用された参照サンプルをフィルタリングすることからなる、イントラエリアにおける参照サンプルフィルタリング。
● 予測するブロックの左上の再構成された隣接境界サンプルからイントラ予測子を生成するために行列を使用することからなるＭＩＰ（行列ベースのイントラ予測、Ｍａｔｒｉｘ ｗｅｉｇｈｔｅｄ Ｉｎｔｒａ Ｐｒｅｄｉｃｔｉｏｎ）。
● 輝度イントラ予測ブロックを、ブロックサイズに応じて垂直又は水平に２個又は４個のサブパーティションに分割するＩＳＰ（イントラサブパーティション、Ｉｎｔｒａ Ｓｕｂ－Ｐａｒｔｉｔｉｏｎ）。
● ＣＵの彩度サンプルが、線形モデルを使用することによって同一ＣＵの再構成された輝度サンプルに基づいて予測される、ＣＣＬＭ（クロスコンポーネントリニアモデル、Ｃｒｏｓｓ－ｃｏｍｐｏｎｅｎｔ ｌｉｎｅａｒ ｍｏｄｅｌ）予測。
● 同一ピクチャの別のブロックからピクチャ内のブロックを予測することからなるＩＢＣ（イントラブロックコピー、Ｉｎｔｒａ Ｂｌｏｃｋ Ｃｏｐｙ）。
● イントラ予測に使用された参照サンプルをフィルタリングすることからなる、イントラエリアにおける参照サンプルフィルタリング。
【0108】
インター予測は、現在のピクチャの前又は後のピクチャ（このピクチャは参照ピクチャと呼ばれる）のピクセルのブロック（参照ブロックと呼ばれる）から現在のブロックのピクセルを予測することからなる。インター予測方法による現在のブロックのコーディング中に、類似性基準に従って現在のブロックに最も近い参照ピクチャのブロックが、動き推定ステップ７０４によって判定される。ステップ７０４中に、参照ピクチャ内の参照ブロックの位置を示す動きベクトルが判定される。動き推定は、概して、サブピクセル精度で実行され、すなわち、現在のピクチャ及び参照ピクチャが補間される。動き推定によって判定された動きベクトルは、動き補償ステップ３０５中に使用され、その間に残差ブロックは、現在のブロックと参照ブロックとの間の差の形態で計算される。
【0109】
第１のビデオ圧縮規格では、上述した一方向インター予測モードが利用可能な唯一のインターモードであった。ビデオ圧縮規格が進化するにつれて、インターモードのファミリーは著しく成長しており、現在は多くの異なるインターモードを含む。これらのインター予測モードは、例えば、以下を含む。
● 双予測において、精密化された動きベクトルが各初期動きベクトルの周りで探索される、ＤＭＶＲ（デコーダ側の動き精密化、ｄｅｃｏｄｅｒ ｓｉｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｆｉｎｅｍｅｎｔ）。精密化は、エンコーダ及びデコーダによって対称的に実行される。
● オプティカルフローの概念に基づいており、物体の動きが滑らかであることを前提とする、ＢＤＯＦ（双方向オプティカルフロー、ｂｉ－ｄｉｒｅｃｔｉｏｎａｌ ｏｐｔｉｃａｌ ｆｌｏｗ）。ＢＤＯＦは、４×４サブブロックレベルでＣＵの双方向予測信号を精密化するために使用される。ＢＤＯＦは輝度成分にのみ適用される。
● ＰＲＯＦ（オプティカルフローを用いた予測精密化、ｐｒｅｄｉｃｔｉｏｎ ｒｅｆｉｎｅｍｅｎｔ ｗｉｔｈ ｏｐｔｉｃａｌ ｆｌｏｗ）：サブブロックベースのアフィン動き補償は、予測精度ペナルティを犠牲にして、ピクセルベースの動き補償と比較して、メモリアクセス帯域幅を節約し、計算の複雑度を低減することができる。動き補償のより細かい粒度を達成するために、オプティカルフローを用いた予測精密化（ＰＲＯＦ）が使用されて、動き補償のためにメモリアクセス帯域幅を増加させることなく、サブブロックベースのアフィン動き補償予測を精密化する。
● インター予測信号をイントラ予測信号と組み合わせる、ＣＩＩＰ（組み合わされたイントラ及びインター予測、Ｃｏｍｂｉｎｅｄ ｉｎｔｅｒ ａｎｄ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）。
● 幾何学的に位置する直線によってＣＵを２つの部分に分割するＧＰＭ（幾何学的分割モード、ｇｅｏｍｅｔｒｉｃ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅ）。ＣＵ内の幾何学的区画の各部分は、それ自体の動きを使用してインター予測され、各区画に対して、単一予測のみが許可される。
● 双予測において、精密化された動きベクトルが各初期動きベクトルの周りで探索される、ＤＭＶＲ（デコーダ側の動き精密化、ｄｅｃｏｄｅｒ ｓｉｄｅ ｍｏｔｉｏｎ ｖｅｃｔｏｒ ｒｅｆｉｎｅｍｅｎｔ）。精密化は、エンコーダ及びデコーダによって対称的に実行される。
● オプティカルフローの概念に基づいており、物体の動きが滑らかであることを前提とする、ＢＤＯＦ（双方向オプティカルフロー、ｂｉ－ｄｉｒｅｃｔｉｏｎａｌ ｏｐｔｉｃａｌ ｆｌｏｗ）。ＢＤＯＦは、４×４サブブロックレベルでＣＵの双方向予測信号を精密化するために使用される。ＢＤＯＦは輝度成分にのみ適用される。
● ＰＲＯＦ（オプティカルフローを用いた予測精密化、ｐｒｅｄｉｃｔｉｏｎ ｒｅｆｉｎｅｍｅｎｔ ｗｉｔｈ ｏｐｔｉｃａｌ ｆｌｏｗ）：サブブロックベースのアフィン動き補償は、予測精度ペナルティを犠牲にして、ピクセルベースの動き補償と比較して、メモリアクセス帯域幅を節約し、計算の複雑度を低減することができる。動き補償のより細かい粒度を達成するために、オプティカルフローを用いた予測精密化（ＰＲＯＦ）が使用されて、動き補償のためにメモリアクセス帯域幅を増加させることなく、サブブロックベースのアフィン動き補償予測を精密化する。
● インター予測信号をイントラ予測信号と組み合わせる、ＣＩＩＰ（組み合わされたイントラ及びインター予測、Ｃｏｍｂｉｎｅｄ ｉｎｔｅｒ ａｎｄ ｉｎｔｒａ ｐｒｅｄｉｃｔｉｏｎ）。
● 幾何学的に位置する直線によってＣＵを２つの部分に分割するＧＰＭ（幾何学的分割モード、ｇｅｏｍｅｔｒｉｃ ｐａｒｔｉｔｉｏｎｉｎｇ ｍｏｄｅ）。ＣＵ内の幾何学的区画の各部分は、それ自体の動きを使用してインター予測され、各区画に対して、単一予測のみが許可される。
【0110】
選択ステップ７０６中に、レート／歪み最適化基準（すなわち、ＲＤＯ基準）に従って、試験された予測モード（例えば、イントラ予測モード、インター予測モード）の中から圧縮性能を最適化する予測モードが符号化モジュールによって選択される。
【0111】
予測モードが選択されると、残差ブロックはステップ７０７中に変換され、ステップ７０９中に量子化される。逆変換も進化しており、新しいツールが最近提案された。これらの新しいツールは以下のものを含む。
● 彩度残差が一緒にコーディングされる、ＪＣＣＲ（彩度残差のジョイントコーディング、Ｊｏｉｎｔ ｃｏｄｉｎｇ ｏｆ ｃｈｒｏｍａ ｒｅｓｉｄｕａｌｓ）。
● 水平変換及び垂直変換のためにＤＣＴ－２、ＤＳＴ－７及びＤＣＴ－８の間で選択が行われる、ＭＴＳ（複数変換選択、ｍｕｌｔｉｐｌｅ ｔｒａｎｓｆｏｒｍ ｓｅｌｅｃｔｉｏｎ）。
● ＬＦＮＳＴ（低周波数非分離型変換、Ｌｏｗ－ｆｒｅｑｕｅｎｃｙ ｎｏｎ－ｓｅｐａｒａｂｌｅ ｔｒａｎｓｆｏｒｍ）：ＬＦＮＳＴは、順方向一次変換と量子化との間（エンコーダにおける）、及び逆量子化と逆方向一次変換との間（デコーダ側における）に適用される。４×４非分離型変換又は８×８非分離型変換は、ブロックサイズに従って適用される。
● ＢＤＰＣＭ（ロック差動パルスコード化変調、Ｂｌｏｃｋ ｄｉｆｆｅｒｅｎｔｉａｌ ｐｕｌｓｅ ｃｏｄｅｄ ｍｏｄｕｌａｔｉｏｎ）。ＢＤＰＣＭは、通常イントラモードの競合相手とみなされ得る。ＢＤＰＣＭが使用されるとき、ＢＤＰＣＭ予測方向フラグは、予測が水平であるか垂直であるかを示すために送信される。次いで、ブロックは、フィルタリングされていない参照サンプルを用いて、通常の水平イントラ予測プロセス又は垂直イントラ予測プロセスを使用して予測される。残差は量子化され、量子化された各残差とその予測子、すなわち（ＢＤＰＣＭ予測方向に応じて）水平又は垂直の隣接位置の前にコーディングされた残差との間の差がコーディングされる。
● 残差ブロックのサブ部分のみがＣＵのためにコーディングされる、ＳＢＴ（サブブロック変換、Ｓｕｂｂｌｏｃｋ ｔｒａｎｓｆｏｒｍ）。
● 彩度残差が一緒にコーディングされる、ＪＣＣＲ（彩度残差のジョイントコーディング、Ｊｏｉｎｔ ｃｏｄｉｎｇ ｏｆ ｃｈｒｏｍａ ｒｅｓｉｄｕａｌｓ）。
● 水平変換及び垂直変換のためにＤＣＴ－２、ＤＳＴ－７及びＤＣＴ－８の間で選択が行われる、ＭＴＳ（複数変換選択、ｍｕｌｔｉｐｌｅ ｔｒａｎｓｆｏｒｍ ｓｅｌｅｃｔｉｏｎ）。
● ＬＦＮＳＴ（低周波数非分離型変換、Ｌｏｗ－ｆｒｅｑｕｅｎｃｙ ｎｏｎ－ｓｅｐａｒａｂｌｅ ｔｒａｎｓｆｏｒｍ）：ＬＦＮＳＴは、順方向一次変換と量子化との間（エンコーダにおける）、及び逆量子化と逆方向一次変換との間（デコーダ側における）に適用される。４×４非分離型変換又は８×８非分離型変換は、ブロックサイズに従って適用される。
● ＢＤＰＣＭ（ロック差動パルスコード化変調、Ｂｌｏｃｋ ｄｉｆｆｅｒｅｎｔｉａｌ ｐｕｌｓｅ ｃｏｄｅｄ ｍｏｄｕｌａｔｉｏｎ）。ＢＤＰＣＭは、通常イントラモードの競合相手とみなされ得る。ＢＤＰＣＭが使用されるとき、ＢＤＰＣＭ予測方向フラグは、予測が水平であるか垂直であるかを示すために送信される。次いで、ブロックは、フィルタリングされていない参照サンプルを用いて、通常の水平イントラ予測プロセス又は垂直イントラ予測プロセスを使用して予測される。残差は量子化され、量子化された各残差とその予測子、すなわち（ＢＤＰＣＭ予測方向に応じて）水平又は垂直の隣接位置の前にコーディングされた残差との間の差がコーディングされる。
● 残差ブロックのサブ部分のみがＣＵのためにコーディングされる、ＳＢＴ（サブブロック変換、Ｓｕｂｂｌｏｃｋ ｔｒａｎｓｆｏｒｍ）。
【0112】
符号化モジュールは、変換をスキップして、変換されていない残差信号に量子化を直接適用することができることに留意されたい。現在のブロックがイントラ予測モードに従ってコーディングされると、予測方向と、変換され量子化された残差ブロックとは、ステップ７１０中にエントロピーエンコーダによって符号化される。現在のブロックがインター予測に従って符号化されると、適切な場合には、ブロックの動きベクトルは、符号化されるブロックの近くに位置する再構成されたブロックに対応する動きベクトルのセットから選択された予測ベクトルから予測される。次に、動き情報は、ステップ７１０中にエントロピーエンコーダによって、動き残差と予測ベクトルを識別するためのインデックスとの形態で符号化される。変換され量子化された残差ブロックは、ステップ７１０中にエントロピーエンコーダによって符号化される。符号化モジュールは、変換及び量子化の両方をバイパスすることができ、すなわちエントロピー符号化は、変換処理又は量子化処理を適用することなく残差に適用されることに留意されたい。エントロピー符号化の結果は、符号化ビデオストリーム７１１に挿入される。
【0113】
量子化ステップ７０９の後、現在のブロックは、当該ブロックに対応するピクセルが将来の予測に使用され得るように再構成される。この再構成段階は、予測ループとも呼ばれる。したがって、逆量子化は、ステップ７１２中に変換され、量子化された残差ブロックに適用され、ステップ７１３中に逆変換が適用される。ステップ７１４中に取得されたブロックに使用される予測モードによって、ブロックの予測ブロックが再構成される。現在のブロックがインター予測モードに従って符号化される場合、符号化モジュールは、適切な場合には、ステップ７１６中に、現在のブロックの参照ブロックを識別するために、現在のブロックの動きベクトルを使用する動き補償を適用する。現在のブロックがイントラ予測モードに従って符号化される場合、ステップ７１５中に、現在のブロックに対応する予測方向が、現在のブロックの参照ブロックを再構成するために使用される。再構成された現在のブロックを取得するために、参照ブロック及び再構成された残差ブロックが追加される。
【0114】
再構成後、ステップ７１７中に、符号化アーチファクトを低減することを意図したループ内ポストフィルタリングが、再構成ブロックに適用される。このフィルタリングは、エンコーダにおいてデコーダと同じ参照画像を取得し、したがって符号化プロセスと復号プロセスとの間のドリフトを回避するために予測ループで行われるので、ループ内ポストフィルタリングと呼ばれる。先で言及されているように、ループ内フィルタリングツールは、デブロッキングフィルタリング、ＳＡＯ（サンプル適応オフセット、Ｓａｍｐｌｅ Ａｄａｐｔｉｖｅ Ｏｆｆｓｅｔ）、ＡＬＦ（適応ループフィルタ、Ａｄａｐｔｉｖｅ Ｌｏｏｐ Ｆｉｌｔｅｒ）、及びＣＣ－ＡＬＦ（クロスコンポーネントＡＬＦ、Ｃｒｏｓｓ Ｃｏｍｐｏｎｅｎｔ ＡＬＦ）を含む。ＣＣ－ＡＬＦは、輝度サンプル値を使用して、適応線形フィルタを輝度チャネルに適用し、次いで、このフィルタリング動作の出力を使用して彩度を精密化することによって、各彩度成分を精密化する。ＬＭＣＳ（彩度スケーリングを伴う輝度マッピング、Ｌｕｍａ Ｍａｐｐｉｎｇ ｗｉｔｈ Ｃｈｒｏｍａ Ｓｃａｌｉｎｇ）と呼ばれる新しいツールも、ループ内フィルタリングとみなされ得る。他のループフィルタの前の新たな処理ブロックとして、ＬＭＣＳが追加される。ＬＭＣＳは、２つの主要成分、すなわち、適応区分線形モデルに基づく輝度成分のループ内マッピングと、彩度成分に対して適用される、輝度依存彩度残差スケーリングと、を有する。
【0115】
ブロックは、再構成されると、ステップ７１８中に、一般に復号ピクチャバッファ（Decoded Picture Buffer、ＤＰＢ）と呼ばれる、再構成画像のメモリ７１９に記憶された再構成されたピクチャに挿入される。そのように記憶された再構成画像は、コーディングされる他の画像の参照画像として機能することができる。
【0116】
参照ピクチャ再サンプリング（Reference Picture Resampling、ＲＰＲ）と呼ばれるＶＶＣの新しいツールは、コーディングされたピクチャの解像度をオンザフライで変更することを可能にする。ピクチャは、ＤＰＢに、ビットストリームの高レベルシンタックス（high-level syntax、ＨＬＳ）でシグナリングされるビデオ空間解像度よりも低い可能性がある実際の符号化／復号解像度で記憶される。所与の解像度でコーディングされているピクチャが、時間的予測について、同じ解像度ではない参照ピクチャを使用するとき、テクスチャの参照ピクチャ再サンプリングが、予測ピクチャと参照ピクチャとが同じ解像度を有するように適用される（図７のステップ７２０によって表される）。実装形態に応じて、再サンプリングプロセスは、必ずしも参照ピクチャ全体に適用されるわけではなく（参照ピクチャ全体再サンプリング）、現在ピクチャの復号及び再構成を実行するときに参照ブロックとして識別されたブロックのみに適用され得る（ブロックベース参照ピクチャ再サンプリング）ことに留意されたい。この場合、現在のピクチャ中の現在のブロックが現在のピクチャとは異なる解像度を有する参照ピクチャを使用するとき、現在のブロックの時間的予測について使用される参照ピクチャ中のサンプルは、現在のピクチャ解像度と参照ピクチャ解像度との間の比として計算された再サンプリング比に従って再サンプリングされる。
【0117】
符号化されたビデオストリーム３１１には、ＳＥＩ（補足拡張情報、Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージなどのメタデータを付加することができる。例えば、ＡＶＣ、ＨＥＶＣ、又はＶＶＣなどの規格において定義されるＳＥＩ（補足拡張情報）メッセージは、ビデオストリームに関連付けられ、ビデオストリームに対する情報を提供するメタデータを含むデータコンテナ又はデータ構造である。
【0118】
図８は、復号モジュールによって実行される、図８に関連して説明された方法に従って符号化された符号化ビデオストリーム７１１を復号するための方法を概略的に描示する。復号するためのこの方法の変形例が企図されるが、明確さを目的として、以下では予想される全ての変形例を説明することなく、図８の復号するための方法について説明される。図８に関連して説明される全てのステップは、例えば、処理モジュール５００によって、この処理モジュールがビデオデコーダ２０を実装するときに実行される。
【0119】
復号は、ブロックごとに行われる。現在のブロックの場合、復号はステップ８１０中に現在のブロックをエントロピー復号することから始まる。エントロピー復号は、ブロックの予測モードを取得することを可能にする。
【0120】
ブロックがインター予測モードに従って符号化されている場合、エントロピー復号は、適切な場合には、予測ベクトルインデックス、動き残差、及び残差ブロックを取得することを可能にする。ステップ８０８中に、予測ベクトルインデックス及び動き残差を使用して、現在のブロックに対して動きベクトルが再構成される。
【0121】
ブロックがイントラ予測モードに従って符号化されている場合、エントロピー復号は、予測方向及び残差ブロックを取得することを可能にする。復号モジュールによって実装されるステップ８１２、８１３、８１４、８１５、８１６及び８１７は、全て、符号化モジュールによって実装されるステップ７１２、７１３、７１４、７１５、７１６、及び７１７とそれぞれ同一である。ステップ８１８では、復号されたブロックは、復号されたピクチャに保存され、復号されたピクチャは、ＤＰＢ８１９に記憶される。復号モジュールが所与のピクチャを復号するとき、ＤＰＢ８１９に記憶されたピクチャは、所与のピクチャの符号化中に符号化モジュールによってＤＰＢ７１９に記憶されたピクチャと同一である。復号されたピクチャはまた、例えば表示のために復号モジュールによって出力され得る。ＲＰＲが起動されると、参照ピクチャとして使用されるピクチャ（の少なくとも一部）のサンプルは、ステップ８２０において、予測ピクチャの解像度に再サンプリングされる。再サンプリングステップ（８２０）及び動き補償ステップ（８１６）は、いくつかの実装形態では、１つの単一サンプル補間ステップに組み合わせられ得る。
【0122】
復号された画像は更に、ステップ８２１において後処理を受けることができる。後処理は、逆色変換（例えば、ＹＣｂＣｒ ４：２：０からＲＧＢ ４：４：４への変換）、ステップ７０１の前処理において実行された再マッピングプロセスの逆を実行する逆マッピング、例えば、ＳＥＩメッセージにおいて提供されるフィルタパラメータに基づいて再構成されたピクチャを改善するためのポストフィルタリング、及び／又は、例えば、出力画像をディスプレイ制約に調整するための再サンプリングを含むことができる。
【0123】
先で言及されているように、ＶＶＣの符号化方法において定義される多くの符号化ツールは、表ＴＡＢ１に表されるようなデータ構造ｇｅｎｅｒａｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｉｎｆｏに記憶される制約フラグを使用してアクティブ化又は非アクティブ化され得る。
【0124】
【表1-1】
【0125】
【表1-2】
【0126】
【表1-3】
【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】
第１の実施形態では、低遅延ストリーミングアプリケーションに適合された新しいプロファイルが定義される。以下では、ＶＶＣに適合された、低レイテンシグラフィック（Low Latency Graphic、ＬＬＧ）プロファイルと呼ばれるプロファイルが提案される。ＬＬＧプロファイルは、低い符号化性能及び高い計算コストを有する符号化ツールを無効化する。同様のＬＬＧプロファイルは、ＥＶＣ、ＨＥＶＣ、ＡＶＣ、ＶＰ９、及びＡＶ１などの他のビデオコーディング規格に対して定義され得る。
【0161】
表ＴＡＢ２は、ＶＶＣのためのＬＬＧプロファイルの定義の例を提供する（Ｍａｉｎ １０ ＬＬＧプロファイルと呼ばれる）。Ｍａｉｎ １０ ＬＬＧプロファイルに準拠するビットストリームは、以下の制約のうちの少なくともいくつかに従うものとする。
【0162】
【表2】
【0163】
識別子によって表されるデータの第２の実施形態では、識別子は、制約フラグのグループを表す。
【0164】
以下は、ＶＶＣで説明されるような制約フラグが、どのようにユーザＱｏＥに関連し得るか、及びユーザフレンドリな選択設定にどのようにマッピングされ得るかの例である。
【0165】
以下の例示的な体験品質が定義され得る。
〇 非アクティブ化されるツールがレイテンシを増加させるが、視覚品質が改善する（そのツールを無効化することによって、又は代替的なツールを使用することによって）とき、レイテンシ増加を伴う高い視覚品質（High visual quality with latency increase、ＨＶＱＬＩ）、
〇 高速（Fast、Ｆ）：非アクティブ化されるツールは、視覚品質に影響を与えながら、符号化／復号処理時間を減少させることになる。ツールの非アクティブ化は、圧縮利得の著しい損失を誘発する場合又は誘発しない場合もある。
〇 中間（Intermediate、Ｉ）：非アクティブ化されるツールは、符号化／復号処理時間を減少させるが、高速設定未満であり、一方で、視覚品質にあまり影響を与えない
〇 彩度（Chroma、Ｃ）：彩度に特定の処理を適用するツールが非アクティブ化される。輝度から導出されたプロセスのみが適用される。代替的に、輝度成分のみが符号化／レンダリングされるグレーレベルＱｏＥが定義され得る。
〇 非アクティブ化されるツールがレイテンシを増加させるが、視覚品質が改善する（そのツールを無効化することによって、又は代替的なツールを使用することによって）とき、レイテンシ増加を伴う高い視覚品質（High visual quality with latency increase、ＨＶＱＬＩ）、
〇 高速（Fast、Ｆ）：非アクティブ化されるツールは、視覚品質に影響を与えながら、符号化／復号処理時間を減少させることになる。ツールの非アクティブ化は、圧縮利得の著しい損失を誘発する場合又は誘発しない場合もある。
〇 中間（Intermediate、Ｉ）：非アクティブ化されるツールは、符号化／復号処理時間を減少させるが、高速設定未満であり、一方で、視覚品質にあまり影響を与えない
〇 彩度（Chroma、Ｃ）：彩度に特定の処理を適用するツールが非アクティブ化される。輝度から導出されたプロセスのみが適用される。代替的に、輝度成分のみが符号化／レンダリングされるグレーレベルＱｏＥが定義され得る。
【0166】
これらの識別子の各々は、このＱｏＥを達成することを可能にする制約フラグのグループに関連付けられる。表ＴＡＢ３は、ＶＶＣで定義された制約フラグのサブセットをＱｏＥに関連付ける。この表に言及されていない他の制約フラグは、選択され得る任意のＱｏＥによって影響されないとみなされ、対応するツールは、自由に使用され得る。上記で定義されたＱｏＥのサブセットのみが制約フラグについて言及されるとき、制約フラグに対応するツールは、言及されないＱｏＥについて自由に使用され得る。
【0167】
【表3】
【0168】
表ＴＡＢ３において：
〇 ＱｏＥ ＨＶＱＬＩは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｊｏｉｎｔ＿ｃｂｃｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｆは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｐａｌｅｔｔｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｓｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｍｒｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｍｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｅｐ＿ｑｕａｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ａｌｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｃａｌｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｉは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｅｐ＿ｑｕａｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｃは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｊｏｉｎｔ＿ｃｂｃｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ ＨＶＱＬＩは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｊｏｉｎｔ＿ｃｂｃｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｆは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｐａｌｅｔｔｅ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｓｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｍｒｌ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｍｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｅｐ＿ｑｕａｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ａｌｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｃａｌｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｉは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｅｐ＿ｑｕａｎｔ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
〇 ＱｏＥ Ｃは、ｇｃｉ＿ｎｏ＿ｌｍｃｓ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓａｏ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｊｏｉｎｔ＿ｃｂｃｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｔｒａｎｓｆｏｒｍ＿ｓｋｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｐｍ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｉｉｐ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｃｗ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｄｍｖｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｓｍｖｄ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｂｄｏｆ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｇｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｃｒａ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｎｏ＿ｉｄｒ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇ、ｇｃｉ＿ｉｎｔｒａ＿ｏｎｌｙ＿ｃｏｎｓｔｒａｉｎｔ＿ｆｌａｇを含む制約フラグのグループに関連付けられる。
【0169】
ユーザがＱｏＥを選択するとき、間接的に、ユーザは、制約フラグのグループ、及びこのセット内の制約フラグに対する値を選択する。
【0170】
識別子によって表されるデータの第１及び第２の実施形態の第１の変形形態では、識別子に応じてサーバ１側で追加の符号化決定が行われ得る。符号化決定は、制約フラグ及びプロファイルとは無関係に、ビデオエンコーダの特定の実装を定義する。
【0171】
例えば、Ｆ（高速）ＱｏＥが選択された場合、ビデオエンコーダ１２は、何らかの反復プロセスを必要とするツールを使用しない（並列動作がサポートされないときとしても知られる）。一例は、並列化可能ではない場合、ＲＤＯＱ（レート歪み最適化量子化）の使用を防止することである。
【0172】
ＨＶＱＬＩ ＱｏＥが選択された場合、ビデオエンコーダ１２は、例えば、前処理を適用することによって、ビットストリームの主観的な品質又は全体的なＲＤ性能を改善するために追加の動作を実施する。
【0173】
加えて、増加したレイテンシモード（より遅いペースを有するゲームのための、又はビデオ広告、休止などの、ゲーム中のビデオ中断のための）が、使用され得、ＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ、グループオブピクチャ）サイズを１より大きい値に増加させることによって達成され得、これは、品質と所望されるレイテンシとの間のトレードオフに依存する。増加したＧＯＰサイズは、ビデオエンコーダのレート歪み性能を大幅に増加させることになる。
【0174】
識別子によって表されるデータの第１及び第２の実施形態の第２の変形形態では、識別子に応じてゲームシステム２側で追加の復号決定が行われ得る。復号決定は、制約フラグ及びプロファイルとは無関係に、ビデオデコーダ２０の特定の実装を定義する。
【0175】
この第２の変形形態は、図３の方法に準拠している。
【0176】
例えば、Ｆ（高速）ＱｏＥが選択された場合、ゲームシステム２の処理モジュール５００は、例えば、他のピクチャの時間的予測のための参照ピクチャとして使用されない、いくつかのピクチャの復号をスキップすることによって、復号されたビデオのフレームレートを低減することをビデオデコーダ２０に課す。
【0177】
ＨＶＱＬＩ ＱｏＥの選択は、ビデオデコーダによって出力されるピクチャに対する後処理（雑音除去フィルタ、輪郭改善など）の適用につながる。
【0178】
一実施形態では、ＱｏＥ識別子（ＨＶＱＬＩ、Ｆ、Ｉ、Ｃなど）は、特定のＳＥＩメッセージを介して提供される。
【0179】
例示的なＳＥＩメッセージが提供される。
【0180】
【表4】
【0181】
ｕｅ＿ｑｏｅ＿ｔｙｐｅは、表ＴＡＢ５で指定されるような所望のエンドユーザＱｏＥのタイプを識別する。ｕｅ＿ｑｏｅ＿ｔｙｐｅの値は、０～ｙの両端を含む範囲内にあるものとする。
【0182】
【表5】
【0183】
ｕｅ＿ｑｏｅ＿ｔｙｐｅ値＝０である場合、上記に定義された全ての制約フラグは、ＨＶＱＬＩに対してそれらの対応する値に設定される（値が１であるときＦ、値が２であるときＩ、値が３であるときＣについて同じ）。
【0184】
別の実施形態では、ＱｏＥ識別子（ＨＶＱＬＩ、Ｆ、Ｉ、Ｃなど）とそれらの対応する制約フラグ／符号化決定／復号決定のセットとの間のマッピングが、表ＴＡＢ６に説明されている特定のＳＥＩメッセージを介して帯域外で提供される。
【0185】
【表6】
【0186】
上記の段落に従って設定される全てのフラグを含むか、又は１に設定される必要がある全てのフラグのみを含む。
【0187】
別の実施形態では、ゲームシステム２は、ＳＥＩメッセージにおいて、ユーザによって選択され得るＱｏＥのセットの記述を受信する。
【0188】
エンドツーエンドレイテンシが重要な因子である場合、クラウドゲーミングなどのいくつかの低遅延アプリケーションは、ＩＰネットワークを介したストリーミングメディアのエンドツーエンドのリアルタイム転送のために設計されたリアルタイムトランスポートプロトコル（Real-time Transport Protocol、ＲＴＰ）を使用する。これらのアプリケーションは、情報のタイムリーな配信を必要とし、ある程度のパケット損失を許容し得る。ＲＴＰセッションは、典型的には、シグナリングプロトコルを使用して２つ以上のエンドポイント間で開始される。セッション記述プロトコル（Session Description Protocol、ＳＤＰ）が、セッションに対するパラメータを指定し、セッション、タイミング、及びセッション内のメディアを記述するために使用され得る。以下の実施形態のうちのいくつかがＲＴＰを使用するものとして説明される場合であっても、ＲＴＰは、ＳＲＴＰ、ｗｅｂｒｔｃなどの、他のトランスポートプロトコルによって置き換えられ得ることに留意されたい。
【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】
例えば、以下の符号化設定（encoding setting、ＥＳ）に対する属性ＡＣＡＰ及び属性ＰＣＦＧは、ＳＤＰを介して提供されるオファーに含められる。
ｍ＝ｖｉｄｅｏ ４９１７０ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６６／９００００
ａ＝ｔｃａｐ：１ ＲＴＰ／ＳＡＶＰＦ
ａ＝ａｃａｐ：１ ＥＳ：ＨＶＱＬＩ
ａ＝ａｃａｐ：２ ＥＳ：Ｆａｓｔ
ａ＝ｐｃｆｇ：１ ｔ：１ ａ：２
ａ＝ｐｃｆｇ：８ ａ：１
この例では、オファーは、ｍライン上のＲＴＰ／ＡＶＰ（ＲＦＣ３５５１：最小制御によるオーディオ及びビデオ会議のためのＲＴＰプロファイル）セッションと、セキュアＲＴＰ／ＳＡＶＰ（リアルタイムトランスポートプロトコル／セキュアオーディオビデオプロファイル）を有する１つのトランスポートオプションｔｃａｐと、を提案する。このオファーは、ＨＶＱＬＩ及びＦＡＳＴに対するエンコーダ能力を有する２つの潜在的な属性能力（ａｃａｐ：１及びａｃａｐ：２）を提案する。好ましい潜在的な構成は、セキュアなトランスポート（ｔ：１）及びＥＳ Ｆａｓｔ（ａ：２）を含むｐｃｆｇ：１によって示される。最も好ましくない潜在的構成は、ＥＳ ＨＶＱＬＩ（ａ：１）を含むｐｃｆｇ：８によって示される。
ｍ＝ｖｉｄｅｏ ４９１７０ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６６／９００００
ａ＝ｔｃａｐ：１ ＲＴＰ／ＳＡＶＰＦ
ａ＝ａｃａｐ：１ ＥＳ：ＨＶＱＬＩ
ａ＝ａｃａｐ：２ ＥＳ：Ｆａｓｔ
ａ＝ｐｃｆｇ：１ ｔ：１ ａ：２
ａ＝ｐｃｆｇ：８ ａ：１
この例では、オファーは、ｍライン上のＲＴＰ／ＡＶＰ（ＲＦＣ３５５１：最小制御によるオーディオ及びビデオ会議のためのＲＴＰプロファイル）セッションと、セキュアＲＴＰ／ＳＡＶＰ（リアルタイムトランスポートプロトコル／セキュアオーディオビデオプロファイル）を有する１つのトランスポートオプションｔｃａｐと、を提案する。このオファーは、ＨＶＱＬＩ及びＦＡＳＴに対するエンコーダ能力を有する２つの潜在的な属性能力（ａｃａｐ：１及びａｃａｐ：２）を提案する。好ましい潜在的な構成は、セキュアなトランスポート（ｔ：１）及びＥＳ Ｆａｓｔ（ａ：２）を含むｐｃｆｇ：１によって示される。最も好ましくない潜在的構成は、ＥＳ ＨＶＱＬＩ（ａ：１）を含むｐｃｆｇ：８によって示される。
【0224】
上記の実施形態では、コーデックは、プロファイルを表す識別子、又は制約フラグ若しくは制約フラグのグループを表す識別子に主に基づいて制御された。この識別子は、プロファイル又は制約フラグによって制御されることができないコーデックの特徴を制御するために使用され得る。
【0225】
コーデックを制御するための他の解決策が存在する。例えば、文書ＲＦＣ５１０４（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５１０４）では、コーデック制御メッセージのセットが定義され、それらのうちのいくつかは、ＨＥＶＣ ＲＴＰ ＲＦＣ及びＶＶＣ ＲＴＰ ＲＦＣに含められる。特に、これらの制御メッセージは、ＦＩＲ（フルイントラ要求）コマンドを定義する。ＦＩＲコマンドがエンコーダに提供されるとき、エンコーダは、可能な限り早く瞬時復号リフレッシュ（instantaneous decoding refresh、ＩＤＲ）ピクチャを送信することが予想される。ＩＤＲピクチャは、全てのスライスがＩスライスである符号化されたピクチャである。ＩＤＲピクチャを復号するとき、復号プロセスは、ＩＤＲピクチャを復号した直後に全ての参照ピクチャを「参照のために未使用」としてマークする。ＦＩＲコマンドを受信すると、送信側は、ＩＤＲピクチャを送信しなければならない。ＩＤＲピクチャの１つの制限は、その送信が、ストリーミングアプリケーションにおいて管理することが困難であるビットレートの一時的な高いピークを生成することである。
【0226】
ＶＶＣでは、漸進的デコーダリフレッシュ（Gradual Decoder Refresh、ＧＤＲ）機能が規範的に定義され、イントラ符号化ブロックの列を送信することによって漸進的リカバリポイントを作成することを可能にする。したがって、ＦＩＲコマンドよりも高い柔軟性を提供し、かつＩＤＲピクチャを送信するときよりも平滑なビットレートの変化を取得することを可能にするために、新しいコーデック制御メッセージを定義することが有益である。
【0227】
ＳＤＰにおけるコーデック制御メッセージ（codec control message、ＣＣＭ）のためのサポートを示し、ネゴシエートするためのＳＤＰ手順を定義する文書ＲＦＣ５１０４のセクション７によると、漸進的デコーダリフレッシュ要求（Gradual Decoder Refresh request、ＧＤＲＲ）は、以下のように定義され得る。
ｒｔｃｐ－ｆｂ－ｃｃｍ－ｐａｒａｍ＝／ＳＰ“ＧＤＲＲ”、漸進的デコーダリフレッシュ要求
ｒｔｃｐ－ｆｂ－ｃｃｍ－ｐａｒａｍ＝／ＳＰ“ＧＤＲＲ”、漸進的デコーダリフレッシュ要求
【0228】
ＧＤＲＲコマンドの目的は、エンコーダに可能な限り早く漸進的デコーダリフレッシュポイントを送信させることである。図１～図４の例では、ＧＤＲＲコマンドを受信すると、サーバ１は、ＧＤＲポイントの送信を開始しなければならない。
【0229】
ＲＦＣ５１０４は、特定の使用事例について、「エラーから復旧するためにＦＩＲコマンドを使用することは明示的に許可されず、代わりに、ＡＶＰＦ［ＲＦＣ４５８５］で定義されたＰＬＩメッセージが使用されるべきである。ＰＬＩメッセージは、失われたピクチャを報告し、精密にその目的のためにＡＶＰＦに含められている」と記載している。
【0230】
しかしながら、ＧＤＲコマンドの送信は、ピクチャ損失又はスライス損失指示に先立って（例えば、帯域幅輻輳の蓄積の監視時に）行われ得、依然として他の使用事例に対して許可されることになる。加えて、ＲＦＣ４５８５は、ＰＬＩメッセージの受信が、典型的には、フルイントラピクチャの送信をトリガするが、一方で、目的は、精密に、漸進的リフレッシュを可能にし、フルイントラピクチャを送信しないことであると記載している。
【0231】
ＲＦＣ４５８５によって指定されるように、ペイロード固有フィードバック（Payload-Specific feedback、ＰＳＢＦ）メッセージは、ＲＴＣＰパケットタイプ値ＰＳＦＢによって識別される。ＧＤＲＲメッセージは、ＲＴＣＰパケットタイプ値ＰＴ＝ＰＳＦＢ及びＦＭＴ＝ｘｘｘによって識別される。値は、ＧＤＲＲ ＦＭＴに帰属する必要があることになる。
【0232】
ＶＶＣでは、ＲＰＲが定義され、いくつかの帯域幅又は輻輳問題に対処するために有利に使用され得る。ＡＯＭ ＡＶ１は、同様の機能を有し、提案されたコマンドは、両方のコーデックに適用されることになる。
【0233】
一実施形態では、ＲＦＣ５１０４のセクション７に従って、ＲＰＲ要求（RPR request、ＲＲＰＲ）は、以下のように定義される。
ｒｔｃｐ－ｆｂ－ｃｃｍ－ｐａｒａｍ＝／ＳＰ“ＲＲＰＲ”、参照ピクチャ再サンプリング要求
ｒｔｃｐ－ｆｂ－ｃｃｍ－ｐａｒａｍ＝／ＳＰ“ＲＲＰＲ”、参照ピクチャ再サンプリング要求
【0234】
ＲＲＰＲ要求の目的は、より低い空間解像度を有するピクチャを可能な限り早く送信するようにエンコーダに命令することである。図１～図４の例では、ＲＲＰＲを受信すると、サーバ１は、再サンプリングされたピクチャを送信しなければならない。追加のパラメータが送信されないとき、エンコーダ／サーバは、どの空間解像度を送信するかを自由に決定する。例えば、ＦＣＩ（フィードバック制御情報（Feedback Control Information））フィールド内の追加のパラメータが、水平若しくは垂直スケーリング、又は増分ダウン／アップスケーリングサイズ、若しくは所望のダウン／アップスケーリングサイズに対するインジケータを要求するために使用され得る。
【0235】
ＲＦＣ４５８５のセクション６．１によって指定されるように、ペイロード固有フィードバックメッセージは、ＲＴＣＰパケットタイプ値ＰＳＦＢによって識別される。ＧＤＲＲメッセージは、ＲＴＣＰパケットタイプ値ＰＴ＝ＰＳＦＢ及びＦＭＴ＝ｘｘｘによって識別される。値は、そのＧＤＲＲ ＦＭＴに帰属する必要があることになる。
【0236】
一例では、本発明者らは、オーディオ（例えば、Ｇ．７１１）及びビデオ（Ｈ．２６３）コーデックを含む、コーデック制御メッセージのためのオファー／アンサーの一部として、ＲＲＰＲ及びＧＤＲＲ能力交換のためのサポートを有するＲＦＣ５１０４のセクション７．３における例を拡張する。オファー側は、「ｔｓｔｒ（時間空間的トレードオフ（Temporal Spatial Trade-off））」、「ｆｉｒ（フルイントラ要求（Full Intra Request））」、「ｇｄｒｒ」、及び「ｒｒｐｒ」をサポートすることを希望する。オファーされるＳＤＰは、以下のとおりである。
－－－－－－－－－－－－－＞Ｏｆｆｅｒ
ｖ＝０
ｏ＝ａｌｉｃｅ ３２０３０９３５２０ ３２０３０９３５２０ ＩＮ ＩＰ４ ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
ｓ＝Ｏｆｆｅｒ／Ａｎｓｗｅｒ
ｃ＝ＩＮ ＩＰ４ １９２．０．２．１２４
ｍ＝ａｕｄｉｏ ４９１７０ ＲＴＰ／ＡＶＰ ０
ａ＝ｒｔｐｍａｐ：０ ＰＣＭＵ／８０００
ｍ＝ｖｉｄｅｏ ５１３７２ ＲＴＰ／ＡＶＰＦ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６３－１９９８／９００００
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｔｓｔｒ
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｆｉｒ
ａ＝ｒｔｃｐ－ｆｂ：＊ｃｃｍ ｔｍｍｂｒ ｓｍａｘｐｒ＝１２０
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｇｄｒｒ
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｒｒｐｒ
－－－－－－－－－－－－－＞Ｏｆｆｅｒ
ｖ＝０
ｏ＝ａｌｉｃｅ ３２０３０９３５２０ ３２０３０９３５２０ ＩＮ ＩＰ４ ｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
ｓ＝Ｏｆｆｅｒ／Ａｎｓｗｅｒ
ｃ＝ＩＮ ＩＰ４ １９２．０．２．１２４
ｍ＝ａｕｄｉｏ ４９１７０ ＲＴＰ／ＡＶＰ ０
ａ＝ｒｔｐｍａｐ：０ ＰＣＭＵ／８０００
ｍ＝ｖｉｄｅｏ ５１３７２ ＲＴＰ／ＡＶＰＦ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６３－１９９８／９００００
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｔｓｔｒ
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｆｉｒ
ａ＝ｒｔｃｐ－ｆｂ：＊ｃｃｍ ｔｍｍｂｒ ｓｍａｘｐｒ＝１２０
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｇｄｒｒ
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｒｒｐｒ
【0237】
アンサー側は、追加能力の一部としてＧＤＲＲメッセージのみをサポートすることを希望し、アンサーされるＳＤＰは、以下のとおりである。
＜－－－－－－－－－－－－－－－－Ａｎｓｗｅｒ
ｖ＝０
ｏ＝ａｌｉｃｅ ３２０３０９３５２０ ３２０３０９３５２４ ＩＮ ＩＰ４ ｏｔｈｅｒｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
ｓ＝Ｏｆｆｅｒ／Ａｎｓｗｅｒ
ｃ＝ＩＮ ＩＰ４ １９２．０．２．３７
ｍ＝ａｕｄｉｏ ４７１９０ ＲＴＰ／ＡＶＰ ０
ａ＝ｒｔｐｍａｐ：０ ＰＣＭＵ／８０００
ｍ＝ｖｉｄｅｏ ５３２７３ ＲＴＰ／ＡＶＰＦ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６３－１９９８／９００００
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｇｄｒｒ
＜－－－－－－－－－－－－－－－－Ａｎｓｗｅｒ
ｖ＝０
ｏ＝ａｌｉｃｅ ３２０３０９３５２０ ３２０３０９３５２４ ＩＮ ＩＰ４ ｏｔｈｅｒｈｏｓｔ．ｅｘａｍｐｌｅ．ｃｏｍ
ｓ＝Ｏｆｆｅｒ／Ａｎｓｗｅｒ
ｃ＝ＩＮ ＩＰ４ １９２．０．２．３７
ｍ＝ａｕｄｉｏ ４７１９０ ＲＴＰ／ＡＶＰ ０
ａ＝ｒｔｐｍａｐ：０ ＰＣＭＵ／８０００
ｍ＝ｖｉｄｅｏ ５３２７３ ＲＴＰ／ＡＶＰＦ ９８
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６３－１９９８／９００００
ａ＝ｒｔｃｐ－ｆｂ：９８ ｃｃｍ ｇｄｒｒ
【0238】
以上、いくつかの実施形態について説明した。これらの実施形態の特徴は、単独で、又は任意の組み合わせで提供することができる。更に、実施形態は、様々な特許請求の範疇及びタイプにわたって、以下の特徴、デバイス、又は態様のうちの１つ以上を、単独で、又は任意の組み合わせにおいて、含むことができる。
● 記載されるシンタックス要素、又はその変形形態のうちの１つ以上を含むビットストリーム又は信号。
● 記載されるシンタックス要素、又はその変形形態のうちの１つ以上を含むビットストリーム又は信号を作り出しかつ／又は送信しかつ／又受信しかつ／又は復号する。
● 説明された実施形態のうちの少なくとも１つを実行するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子デバイス。
● 説明された実施形態のうちの少なくとも１つを実行し、結果的に得られたピクチャを（例えば、モニタ、スクリーン、又は他のタイプのディスプレイを使用して）表示するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子デバイス。
● 符号化ビデオストリームを含む信号を受信するために（例えば、チューナを使用して）チャネルをチューニングし、説明した実施形態のうちの少なくとも１つを実行するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子機器。
● 符号化ビデオストリームを含む信号を（例えば、アンテナを使用して）無線で受信し、説明した実施形態のうちの少なくとも１つを実行するテレビ、セットトップボックス、携帯電話、タブレット、又は他の電子デバイス。
● 記載されるシンタックス要素、又はその変形形態のうちの１つ以上を含むビットストリーム又は信号。
● 記載されるシンタックス要素、又はその変形形態のうちの１つ以上を含むビットストリーム又は信号を作り出しかつ／又は送信しかつ／又受信しかつ／又は復号する。
● 説明された実施形態のうちの少なくとも１つを実行するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子デバイス。
● 説明された実施形態のうちの少なくとも１つを実行し、結果的に得られたピクチャを（例えば、モニタ、スクリーン、又は他のタイプのディスプレイを使用して）表示するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子デバイス。
● 符号化ビデオストリームを含む信号を受信するために（例えば、チューナを使用して）チャネルをチューニングし、説明した実施形態のうちの少なくとも１つを実行するテレビ、ゲームコンソール、携帯電話、タブレット、又は他の電子機器。
● 符号化ビデオストリームを含む信号を（例えば、アンテナを使用して）無線で受信し、説明した実施形態のうちの少なくとも１つを実行するテレビ、セットトップボックス、携帯電話、タブレット、又は他の電子デバイス。
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】