特表 2025-505218 メディアコンテナファイルおよびストリーミングマニフェストにおけるピクチャインピクチャのためのシグナリング

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

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

(11)【公表番号】

(43)【公表日】2025-02-21

(54)【発明の名称】メディアコンテナファイルおよびストリーミングマニフェストにおけるピクチャインピクチャのためのシグナリング

(51)【国際特許分類】

   H04N 21/434 20110101AFI20250214BHJP

【ＦＩ】

H04N21/434

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024547121

(86)(22)【出願日】2023-06-29

(85)【翻訳文提出日】2024-08-07

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

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

(87)【国際公開日】2024-01-18

(31)【優先権主張番号】63/388,555

(32)【優先日】2022-07-12

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

(31)【優先権主張番号】63/417,103

(32)【優先日】2022-10-18

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

(31)【優先権主張番号】18/341,471

(32)【優先日】2023-06-26

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】イーラジ・ソダガー

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

5C164

【Ｆターム（参考）】

5C164FA06

5C164MB13S

5C164SB11S

5C164UB11P

5C164UB21S

5C164UB85S

(57)【要約】

本開示は、メディアコンテナファイルおよびストリーミングメディアマニフェストにおけるピクチャインピクチャ（PiP）のシグナリングに関する。一態様では、コンテナファイルにおけるPiP体験のシグナリングが開示され、PiP体験は2つ以上のメディアトラックからなる。ピクチャインピクチャ体験を定義するためにメディアトラックグループが使用され、1つまたは複数のメインメディアトラックおよび代替／オーバーレイメディアトラックが定義される。PiP体験は、役割方式で識別される。PiPにおけるメディアトラックは、独立してデコードされることが可能であり、またはコーディング方式がサポートする場合、代替のコーディングされたストリームは、マージモードでメインピクチャストリーム内の対応する領域に置き換わることができ、このために、代替ピクチャの重要性の順序およびメインピクチャの特定の領域もまたシグナリングされる。他の態様では、ピクチャインピクチャ体験は、ストリーミングマニフェストでシグナリングされてもよい。このようなシグナリングは、ピクチャインピクチャ記述子を用いて適応セットを識別するステップ、ならびにPiP体験を識別するために役割記述子を使用するステップ、さらに1つ以上のサブピクチャが置換のための1つ以上の領域として識別されるマニフェストにおいてサブピクチャに注釈を付けるステップを含み得る。

【特許請求の範囲】

【請求項1】

（ピクチャインピクチャ）PiP情報を取得する方法であって、
ISOベースメディアファイルフォーマット（ISOBMFF）で構築されたメディアコンテナファイルを取得するステップであって、前記メディアコンテナファイルは、PiPモードで表されるメインメディアトラックおよび少なくとも1つのサブメディアトラックを含む、ステップと、
前記メディアコンテナファイルを解析し、メディアトラックグループ定義のための事前選択トラックグループエントリ（Prse）ボックス構文要素を介してPiP体験のためのメディアトラックグループを識別するステップと、
前記メディアコンテナファイルを解析し、前記メディアコンテナファイル内の複数のメディアトラック定義内の事前選択グループ（Pres）ボックス構文要素を介して前記メディアトラックグループに属する前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックを識別するステップと、
前記メディアコンテナファイルを解析し、前記少なくとも1つのサブメディアトラックのコーディングされたデータユニットが、前記メインメディアトラックまたは前記少なくとも1つのサブメディアトラックの前記Presボックス構文要素のコンポーネント内のサンプルフラグマージ構文要素の存在または値に応じてデコードされる前に前記メインメディアトラックのコーディングされたデータユニットとマージされるか否かを示すマージモードを決定するステップと、
前記マージングモードに従って前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップと
を含む、方法。

【請求項2】

前記Prseボックス構文要素は、メディアトラックグループを定義するように構成された前記メディアコンテナファイル内の第1の事前定義されたタイプの構文要素に属する、請求項1に記載の方法。

【請求項3】

前記第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプタグ要素を各々含み、
前記メディアトラックグループタイプタグ要素は、事前定義された目的キーワードのセットを使用して、前記PiP体験を含む、前記対応するメディアトラックグループの意図される体験を示す、
請求項2に記載の方法。

【請求項4】

前記第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプ記述子を各々含み、
前記メディアトラックグループタイプ記述子は、事前定義された役割を有する役割方式を使用して、前記PiP体験を含む、前記対応するメディアトラックグループの意図される体験を指定するように構成される、
請求項2に記載の方法。

【請求項5】

前記メディアコンテナファイル内の前記第1の事前定義されたタイプの構文要素の各々は、前記対応するメディアトラックグループのいくつかのトラックを含む、請求項2に記載の方法。

【請求項6】

前記Presボックス構文要素は、対応するメディアトラックグループ識別子を使用してメディアトラックグループとのメディアトラックの関連付けを指定するように構成された前記メディアトラックの定義内の第2の事前定義されたタイプの構文要素に属する、請求項1～5のいずれか一項に記載の方法。

【請求項7】

前記第2の事前定義されたタイプの構文要素の各々は、前記メディアトラックグループに対する前記メディアトラックのPiP処理を指定するためのメディアトラックグループ処理記述子（prsp）を含む、請求項6に記載の方法。

【請求項8】

前記メディアトラックグループ処理記述子は、前記メディアトラックグループ内の他のメディアトラックに対する前記メディアトラックの優先順位を示すための優先度パラメータを含む、請求項7に記載の方法。

【請求項9】

前記PiP体験の前記メインメディアトラックの前記優先度パラメータは、PiP処理のための最も高い優先度の値を含む、請求項8に記載の方法。

【請求項10】

前記PiP体験の前記少なくとも1つのサブメディアトラックの前記優先度パラメータは、PIP処理のための最も低い優先度の値を含む、請求項9に記載の方法。

【請求項11】

前記サンプルフラグマージ構文要素は、メインメディアトラックに関連付けられた前記メディアトラックグループ処理記述子に相応に含まれる第3の事前定義されたタイプの構文要素に属する、請求項8に記載の方法。

【請求項12】

事前定義された値を有する前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素は、前記メインメディアトラックがデコードされる前に前記サブメディアトラックとマージ可能であることを示す、請求項11に記載の方法。

【請求項13】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値であるとき、前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップは、単一のデコーディングのために前記メインメディアトラックの前記コーディングされたデータユニットおよび前記少なくとも1つのサブメディアトラックの前記コーディングされたデータユニットをマージするステップを含む、請求項12に記載の方法。

【請求項14】

前記メディアトラックグループ処理記述子は、対応するメディアトラックのコーディングされたストリーム内の、デコーディングの前に他のメディアトラックのコーディングされたストリームとマージされる領域のリストを示すための領域識別パラメータを含む、請求項12に記載の方法。

【請求項15】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値であるとき、前記メインメディアトラックに関連付けられた前記領域識別パラメータは非NULLである、請求項14に記載の方法。

【請求項16】

前記メディアトラックの前記優先順位が最も高くないとき、前記メディアトラックのための前記領域識別パラメータは、存在したとしても無視される、請求項14に記載の方法。

【請求項17】

前記メディアトラックのための前記領域識別パラメータが非NULLであるとき、前記メディアトラックの前記優先順位はこれに対応して最も高い、請求項14に記載の方法。

【請求項18】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値ではないとき、前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップは、別々の独立したデコーディングによって前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックを処理するステップを含む、請求項12に記載の方法。

【請求項19】

前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックのいずれかは、前記メディアコンテナファイル内の他のPrseボックス構文要素によって示されるように、他のメディアトラックグループに属する、請求項1～5のいずれか一項に記載の方法。

【請求項20】

命令を記憶するためのメモリと、
ISOベースメディアファイルフォーマット（ISOBMFF）で構築されたメディアコンテナファイルを取得し、前記メディアコンテナファイルは、PiPモードで表されるメインメディアトラックおよび少なくとも1つのサブメディアトラックを含み、
前記メディアコンテナファイルを解析し、メディアトラックグループ定義のための事前選択トラックグループエントリ（Prse）ボックス構文要素を介してピクチャインピクチャ（PiP）体験のためのメディアトラックグループを識別し、
前記メディアコンテナファイルを解析し、前記メディアコンテナファイル内の複数のメディアトラック定義内の事前選択グループ（Pres）ボックス構文要素の構文要素を介して前記メディアトラックグループに属する前記メインメディアトラックおよび少なくとも1つのサブメディアトラックを識別し、
前記メディアコンテナファイルを解析し、前記少なくとも1つのサブメディアトラックのコーディングされたデータユニットが、前記メインメディアトラックまたは前記少なくとも1つのサブメディアトラックの前記Presボックス構文要素のコンポーネント内のサンプルフラグマージ構文要素の存在または値に応じてデコードされる前に前記メインメディアトラックのコーディングされたデータユニットとマージされるか否かを示すマージモードを決定し、
前記マージングモードに従って前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードする、前記命令を実行するためのプロセッサと、
を備える、メディア処理デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2023年6月26日に出願された米国非仮出願第18／341，471号に基づき、その優先権の利益を主張し、これは、2022年7月12日に出願された米国仮出願第63／388，555号および2022年10月18日に出願された米国仮出願第63／417，103号に基づき、その優先権の利益を主張し、これらは、参照によりその全体が本明細書に組み込まれる。

【0002】

本開示は、メディアコンテナファイルおよびストリーミングメディアマニフェストにおけるピクチャインピクチャ（PiP）のシグナリングに関する。

【背景技術】

【0003】

メディアコンテンツは、所定のフォーマットを有するコンテナファイルで編成され得る。このようなメディアコンテンツは、画像またはビデオなどの視覚情報を含み得る。例えば、ピクチャインピクチャ（PiP）モードで、異なるセットの視覚情報が同時に表示されてもよい。メディアコンテナファイルは、ローカル再生のためにダウンロードされてもよく、またはサーバからストリーミングされてもよい。ダウンロードメディアおよびストリーミングメディアの両方とも、PiPモードを呼び出し得る。PiP使用のためのメディアコンテンツに関する情報および構成は、メディアコンテナファイルまたはビットストリームで、ならびに適応型ストリーミングを行うためにストリーミングアプリケーションによって使用されるメディアマニフェストで、シグナリングされる必要があり得る。

【発明の概要】

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

【0004】

本開示は、メディアコンテナファイルおよびストリーミングメディアマニフェストにおけるピクチャインピクチャ（PiP）のシグナリングに関する。

【0005】

一態様では、コンテナファイルにおけるPiP体験のシグナリングが開示され、PiP体験は2つ以上のメディアトラックからなる。ピクチャインピクチャ体験を定義するためにメディアトラックグループが使用され、1つまたは複数のメインメディアトラックおよび代替／オーバーレイメディアトラックが定義される。PiP体験は、役割方式で識別される。PiPにおけるメディアトラックは、独立してデコードされることが可能であり、またはコーディング方式がサポートする場合、代替のコーディングされたストリームは、マージモードでメインピクチャストリーム内の対応する領域に置き換わることができ、このために、代替ピクチャの重要性の順序およびメインピクチャの特定の領域もまたシグナリングされる。

【0006】

他の態様では、ピクチャインピクチャ体験は、ストリーミングマニフェストでシグナリングされてもよい。このようなシグナリングは、ピクチャインピクチャ記述子を用いて適応セットを識別するステップ、ならびにPiP体験を識別するために役割記述子を使用するステップ、さらに1つ以上のサブピクチャが置換のための1つ以上の領域として識別されるマニフェストにおいてサブピクチャに注釈を付けるステップを含み得る。

【0007】

いくつかの例示的な実装形態では、（ピクチャインピクチャ）PiP情報を取得する方法が開示される。本方法は、ISOベースメディアファイルフォーマット（ISOBMFF）で構築されたメディアコンテナファイルを取得するステップであって、メディアコンテナファイルは、PiPモードで表されるメインメディアトラックおよび少なくとも1つのサブメディアトラックを含む、ステップと、メディアコンテナファイルを解析し、メディアトラックグループ定義のための事前選択トラックグループエントリ（Prse）ボックス構文要素を介してPiP体験のためのメディアトラックグループを識別するステップと、メディアコンテナファイルを解析し、メディアコンテナファイル内の複数のメディアトラック定義内の事前選択グループ（Pres）ボックス構文要素を介してメディアトラックグループに属するメインメディアトラックおよび少なくとも1つのサブメディアトラックを識別するステップと、メディアコンテナファイルを解析し、少なくとも1つのサブメディアトラックのコーディングされたデータユニットが、メインメディアトラックまたは少なくとも1つのサブメディアトラックのPres構文ボックス要素のコンポーネント内のサンプルフラグマージ構文要素の存在または値に応じてデコードされる前にメインメディアトラックのコーディングされたデータユニットとマージされるか否かを示すマージモードを決定するステップと、マージングモードに従ってPiPモードでメインメディアトラックおよび少なくとも1つのサブメディアトラックをデコードするステップと、を含み得る。

【0008】

上記の例示的な実装形態では、Prseボックス構文要素は、メディアトラックグループを定義するように構成されたメディアコンテナファイル内の第1の事前定義されたタイプの構文要素に属する。

【0009】

上記の例示的な実装形態のいずれか1つでは、第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプタグ要素を各々含み、メディアトラックグループタイプタグ要素は、事前定義された目的キーワードのセットを使用して、PiP体験を含む、対応するメディアトラックグループの意図される体験を示す。

【0010】

上記の例示的な実装形態のいずれか1つでは、第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプ記述子を各々含み、メディアトラックグループタイプ記述子は、事前定義された役割を有する役割方式を使用して、PiP体験を含む、対応するメディアトラックグループの意図される体験を指定するように構成される。

【0011】

上記の例示的な実装形態のいずれか1つでは、メディアコンテナファイル内の第1の事前定義されたタイプの構文要素の各々は、対応するメディアトラックグループのいくつかのトラックを含む。

【0012】

上記の例示的な実装形態のいずれか1つでは、Presボックス構文要素は、対応するメディアトラックグループ識別子を使用してメディアトラックグループとのメディアトラックの関連付けを指定するように構成されたメディアトラックの定義内の第2の事前定義されたタイプの構文要素に属する。

【0013】

上記の例示的な実装形態のいずれか1つでは、第2の事前定義されたタイプの構文要素の各々は、メディアトラックグループに対するメディアトラックのPiP処理を指定するためのメディアトラックグループ処理記述子（prsp）を含む。

【0014】

上記の例示的な実装形態のいずれか1つでは、メディアトラックグループ処理記述子は、メディアトラックグループ内の他のメディアトラックに対するメディアトラックの優先順位を示すための優先度パラメータを含む。

【0015】

上記の例示的な実装形態のいずれか1つでは、PiP体験のメインメディアトラックの優先度パラメータは、PiP処理のための最も高い優先度の値を含む。

【0016】

上記の例示的な実装形態のいずれか1つでは、PiP体験の少なくとも1つのサブメディアトラックの優先度パラメータは、PIP処理のための最も低い優先度の値を含む。

【0017】

上記の例示的な実装形態のいずれか1つでは、サンプルフラグマージ構文要素は、メインメディアトラックに関連付けられたメディアトラックグループ処理記述子に相応に含まれる第3の事前定義されたタイプの構文要素に属する。

【0018】

上記の例示的な実装形態のいずれか1つでは、事前定義された値を有するメインメディアトラックに関連付けられた第3の事前定義されたタイプの構文要素は、メインメディアトラックがデコードされる前にサブメディアトラックとマージ可能であることを示す。

【0019】

上記の例示的な実装形態のいずれか1つでは、メインメディアトラックに関連付けられた第3の事前定義されたタイプの構文要素が事前定義された値であるとき、PiPモードでメインメディアトラックおよび少なくとも1つのサブメディアトラックをデコードするステップは、単一のデコーディングのためにメインメディアトラックのコーディングされたデータユニットおよび少なくとも1つのサブメディアトラックのコーディングされたデータユニットをマージするステップを含む。

【0020】

上記の例示的な実装形態のいずれか1つでは、メディアトラックグループ処理記述子は、対応するメディアトラックのコーディングされたストリーム内の、デコーディングの前に他のメディアトラックのコーディングされたストリームとマージされる領域のリストを示すための領域識別パラメータを含む。

【0021】

上記の例示的な実装形態のいずれか1つでは、メインメディアトラックに関連付けられた第3の事前定義されたタイプの構文要素が事前定義された値であるとき、メインメディアトラックに関連付けられた領域識別パラメータは非NULLである。

【0022】

上記の例示的な実装形態のいずれか1つでは、メディアトラックの優先順位が最も高くないとき、メディアトラックのための領域識別パラメータは、存在したとしても無視される。

【0023】

上記の例示的な実装形態のいずれか1つでは、メディアトラックのための領域識別パラメータは非NULLであり、メディアトラックの優先順位はこれに対応して最も高い。

【0024】

上記の例示的な実装形態のいずれか1つでは、メインメディアトラックに関連付けられた第3の事前定義されたタイプの構文要素が事前定義された値ではないとき、PiPモードでメインメディアトラックおよび少なくとも1つのサブメディアトラックをデコードするステップは、別々の独立したデコーディングによってメインメディアトラックおよび少なくとも1つのサブメディアトラックを処理するステップを含む。

【0025】

上記の例示的な実装形態のいずれか1つでは、メインメディアトラックおよび少なくとも1つのサブメディアトラックのいずれかは、メディアコンテナファイル内の他のPrseボックス構文要素によって示されるように、他のメディアトラックグループに属する。

【0026】

いくつかの他の例示的な実装形態では、ストリーミングメディアマニフェストからピクチャインピクチャ（PiP）シグナリング情報を取得する方法が開示される。本方法は、ストリーミングサーバからストリーミングメディアマニフェストを取得するステップと、ストリーミングメディアマニフェストを解析し、ストリーミングメディアコンテンツのセットに関連付けられたPiPシグナリング情報項目のセットを識別するステップと、PiPシグナリング情報項目に従ってストリーミングメディアコンテンツのセットの適応的な要求を構築するステップと、ストリーミングメディアコンテンツのセットを受信するステップと、PiPシグナリング情報項目に従ってストリーミングメディアコンテンツのセットをデコードおよび表示するステップと、を含み得る。

【0027】

上記の例示的な実装形態では、PiPシグナリング情報項目は、ストリーミングメディアマニフェスト内の複数の適応セットから抽出されてもよい。

【0028】

上記の例示的な実装形態のいずれか1つでは、複数の適応セットは、PiPグループを形成する。

【0029】

上記の例示的な実装形態のいずれか1つでは、複数の適応セットの各々は、対応する適応セットの役割を指定するための補足記述子を含む。

【0030】

上記の例示的な実装形態のいずれか1つでは、補足記述子は、役割値および識別子を含む。

【0031】

上記の例示的な実装形態のいずれか1つでは、役割値は、事前定義された役割方式で定義された役割値のセットの中にある。

【0032】

上記の例示的な実装形態のいずれか1つでは、事前定義された役割方式は、事前定義された役割方式のユニバーサルリソース名（URN）を使用して、複数の適応セットで示される。

【0033】

上記の例示的な実装形態のいずれか1つでは、役割値は、対応する適応セットがPiP向けであることを示し、識別子は、PiPグループの複数の適応セットについて同じであり、他のPiP適応グループを含む他の適応グループからPiPグループを識別するために割り当てられる。

【0034】

上記の例示的な実装形態のいずれか1つでは、役割値は、PiPグループ内の対応する適応セットの役割をさらに示すか、またはPiPグループ内にメイン適応またはサブ適応のうちの1つを含む。

【0035】

上記の例示的な実装形態のいずれか1つでは、複数の適応セットのうちの最大で1つが、PiPグループ内のメイン適応セットの役割に関連付けられる。

【0036】

上記の例示的な実装形態のいずれか1つでは、複数の適応セットのうちの適応セットがメイン適応セットであり、PiPグループ内のサブ適応セットによってマージ可能であるとき、メイン適応セットのコンテンツコンポーネント記述子は、デコードされる前のPIPグループのコーディングされたサブ適応セットの置き換えに適したメイン適応セットのコーディングされたサブコンポーネントのリストをさらに含む。

【0037】

上記の例示的な実装形態のいずれか1つでは、PiPグループ内の複数の適応セットのうちの少なくとも1つは、複数の適応セットのうちの1つが第2のPiPグループにも属することを示す第2の補足記述子を含む。

【0038】

本開示の態様は、上記の方法実装形態のうちのいずれか1つを実行するように構成された回路を含むメディアストリーミングデバイスまたは装置も提供する。

【0039】

本開示の態様はまた、メディアストリーミングデバイスによって実行されると、メディアストリーミングデバイスに、上記の方法実装形態のいずれか1つを実行させるように構成された命令を記憶する非一時的コンピュータ可読媒体も提供する。

【0040】

開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。

【図面の簡単な説明】

【0041】

【図1】本開示の一実施形態によるコンテンツ配信システムを示す。

【図2】本開示の一実施形態によるHTTP（DASH）システムを介した動的適応型ストリーミングを示す。

【図3】本開示の一実施形態によるDASHクライアントアーキテクチャを示す。

【図4】例示的なピクチャインピクチャアプリケーションを示す。

【図5】メディアコンテナファイルにおける例示的なシグナリング方式を示す。

【図6】図5のシグナリング方式の例示的なデータおよび論理フローを示す。

【図7】例示的なデータおよび論理フローを示す。

【図8】本開示の例示的な実施形態によるコンピュータシステムの概略図を示す。

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

【0042】

ハイパーテキスト転送プロトコル（HTTP）を介したストリーミング
図1は、リモート情報処理装置120が通信ネットワーク130を介して1つ以上の集中型または分散型コンテンツサーバ110からコンテンツを要求するように構成されている、例示的なコンテンツ配信システム100を示す。具体的には、情報処理装置120は、コンテンツ消費アプリケーションとして機能する、専用ハードウェアコンポーネント、汎用ハードウェア上で動作するソフトウェアコンポーネント、またはこれらの組み合わせを含み得る。コンテンツ消費アプリケーションは、要求されているコンテンツおよび要求コンテンツの特性を指定する1つ以上の要求を生成し得る。各要求は、ネットワークプロトコルのスタックに基づいて構築され、通信ネットワーク130を介してコンテンツサーバ110に伝達されてもよい。これに応答して、コンテンツサーバは、要求に従ってビットストリームを生成し、ネットワークプロトコルのスタックを使用してビットストリームをパッケージ化し、ビットストリームパッケージをコンテンツ消費アプリケーションに伝達してもよい。

【0043】

いくつかの例示的な実装形態では、コンテンツは一度に要求されてもよい。言い換えると、メディアコンテンツ全体がコンテンツ消費アプリケーションによって要求され、受信され、ローカルに記憶されてもよい。ローカルに記憶されたコンテンツは、例えば、コンテンツ消費アプリケーションの一部であるかまたはこれと別個であるメディアプレーヤによって、必要に応じて処理および消費（例えば、抽出、デコード、および再生）され得る。このようなプロセスは、ダウンロードと称され得る。

【0044】

いくつかの他の実装形態では、コンテンツは、後の消費のためにダウンロードされるのではなく、消費されているときにストリーミングされてもよい。このような実装形態では、要求コンテンツ全体がコンテンツ消費アプリケーションに記憶される必要はない場合がある。むしろ、限られた量のコンテンツが、ローリングベースでコンテンツサーバ110から連続的に受信され、コンテンツ処理および再生のために入出力ローカルバッファによって管理される。このような実装形態は、ストリーミングと称され得る。巻き戻し、早送り、および検索などのいくつかのメディア再生機能は、複雑なメディアビットストリーム制御およびバッファリングを含み得るが、メディアストリーミングは通常、より汎用的であり、繰り返し消費されないメディアの時刻指定されたシーケンスを含むコンテンツの配信により適している。

【0045】

以下の開示では、「コンテンツ」および「メディア」という用語は、交換可能に使用され得る。要求コンテンツは、コンテンツ自体および様々なメタデータを含むがこれらに限定されない、その消費に必要とされる様々な情報項目を含み得る。コンテンツ自体は、ビデオコンポーネント／トラック、音声コンポーネント／トラック、字幕などを含むがこれらに限定されない、異なるトラックなどの様々なメディアコンポーネントをさらに含んでもよい。メディアコンテンツを記述するため、または追加の処理情報を提供するためのメタデータは、1つ以上の別個のトラックとして扱われてもよい。そのメタデータを有するこのようなコンテンツは、コンテンツ消費アプリケーションに知られているプロトコルまたは規則のセットに従って解析およびデコードされることが可能なビットストリームとして、コンテンツサーバ120によって生成され得る。単数形の「コンテンツサーバ」という用語は、単一のサーバ、または中央の位置に配置された、もしくは様々な地理的位置に分散された複数のサーバを表すために使用される。このようなコンテンツサーバは、専用の計算機械として実装されてもよく、あるいは、仮想機械として、および／またはクラウドコンピューティング環境に仮想的に収容された状態で、構築されてもよい。さらに以下の開示では、「情報処理装置」（図1の120参照）および「コンテンツ消費アプリケーション」という用語は、交換可能に使用されてよい。あるいは、これらの用語はまた、「クライアント」、「クライアントデバイス／装置」、「再生デバイス／装置／クライアント」などと称され得る。図1には単一の情報処理装置120のみが示されているが、複数の独立した情報処理装置が存在することができる。言い換えると、コンテンツサーバ110のセットは、複数のコンテンツ消費アプリケーションにストリーミングサービスを同時に独立して提供するように構成されてもよい。

【0046】

いくつかの例示的な実装形態では、コンテンツサーバ110による配信のために生成されたコンテンツは、それらのストリーミングを容易にするためにセグメント化され得る。例えば、映画などのメディアコンテンツの時刻指定されたシーケンスは、各々がいくつかのメディアフレームを含む時間セグメントに細分され得る。各メディアセグメントは、例えば解析、デコーディング、および再生を含むその処理が他のメディアセグメントの情報を必要としないように、自己完結型であってもよい。メディアコンテンツは、事前にセグメント化されてもよい。したがって、メディアコンテンツは、セグメントごとにコンテンツサーバ120によって記憶および管理され得る。あるいは、メディアセグメントは、ストリーミングプロセス中に要求されているときに、近接して記憶されたメディアコンテンツからリアルタイムで生成されてもよい。いくつかのさらなる実装形態では、メディアのセグメント化は階層的であってもよく、複数のレベルのセグメント化を含む。

【0047】

ストリーミングのためのいくつかの特定の実装形態では、どのメディアセグメント、またはメディアセグメントのどの部分をコンテンツサーバ110から要求するかに関する決定は、ユーザアプリケーションインターフェースを通じたユーザの再生命令によって制御されるように、リアルタイムでコンテンツ消費アプリケーションによって決定されてもよい。このようにして、コンテンツサーバは、要求に応答し、要求に従ってそれらのメタデータを有するコンテンツのセグメントまたはセグメントの一部を生成および取得し、ネットワーク130を介して要求しているコンテンツ消費アプリケーションにセグメントまたはセグメントの一部を配信するように構成され得る。

【0048】

いくつかの例示的な実装形態では、メディアコンテンツの同じメディアトラックは、異なるバージョンとして準備されてもよい。例えば、同じムービートラックが、異なる解像度および／またはフレームレートで準備されてもよい。他の例として、同じムービートラックが異なるビットレートで準備されてもよい。他の例として、同じ音声ムービーが異なる音質および／または異なる音声チャネル（例えば、5チャネ音声、または7チャネル音声）で準備されてもよい。したがって、コンテンツ消費アプリケーションは、どのバージョンのメディアトラックをストリーミングすべきかを決定し、このような選択をメディアコンテンツのその要求に含めてもよい。コンテンツ消費アプリケーションによるこのような決定は、情報処理装置120の再生能力（例えば、表示解像度、デコーディング速度、処理能力、バッファサイズなど）、ネットワーク帯域幅およびスループットなどを含むがこれらに限定されない、いくつかの例示的な要因のうちの1つ以上に基づいて行われ得る。したがって、ストリーミングセッションは、それらのデバイス能力に応じて異なるメディア消費アプリケーション間で適合され得る。このように構成されたストリーミングアーキテクチャは、適応型ストリーミングと称され得る。ストリーミングプロセスは、異なるバージョンのメディアトラックが、例えばリアルタイムネットワーク条件（例えば、帯域幅およびスループット、ならびにネットワーク帯域幅によってサポートされるビットレート）に従って、ストリーミングセッション中の異なる時点で選択および要求され得るという点で、各メディア消費アプリケーション内でさらに適応的であり得る。このように構成されたストリーミングアーキテクチャは、動的適応型ストリーミングとさらに称され得る。特に、メディアコンテンツのビットレートに適応するように構成されたストリーミングアーキテクチャは、動的適応型ビットレートストリーミングと称され得る。

【0049】

いくつかの例示的な実装形態では、動的適応型ストリーミングにおけるコンテンツ消費アプリケーションによるメディアコンテンツの特定のバージョンのセグメントまたはセグメントの一部の要求は、ストリーミングセッションの進行に従ってメディアマニフェストに基づいて構築されてもよい。「マニフェスト」という用語は、セグメント化、バージョン、ネットワークの場所、および任意のコンテンツ消費アプリケーションがストリーミングセッション中の異なる時点で何をどのように要求すべきかを決定するために必要とされ得る任意の他の情報を含む、メディアコンテンツを記述する情報項目の任意の集まりを表すために使用され得る。マニフェストは、一般に、「メディア表現記述」（MPD）と称され得る。

【0050】

このようなマニフェストは、特定のメディアコンテンツが作成または生成されるときに、コンテンツサーバ側で準備されてもよい。このようなマニフェストは、コンテンツ消費アプリケーションによって要求され、ストリーミングセッションの開始時にコンテンツサーバから受信されてもよい。コンテンツ消費アプリケーションは、ストリーミングセッション中にマニフェストの任意の更新をさらに要求してもよい。このようなマニフェストは、ストリーミングセッション中のメディアコンテンツの特定のバージョンのセグメントまたはセグメントの一部の後続の要求を構築するための青写真として、コンテンツ消費デバイスによって使用されてもよい。

【0051】

いくつかの例示的な実装形態では、メディアサーバは外部アプリケーションの観点からウェブサーバと同様に機能するように構成されてもよい。したがって、コンテンツ消費アプリケーションによるメディアマニフェストおよび／またはメディアセグメントまたはメディアセグメントの一部の要求は、例えば、ハイパーテキスト転送プロトコル（HTTP）に基づいて行われてもよい。したがって、要求はURLとして構築されてもよく、要求コンテンツは、コンテンツサーバからのHTTP要求への応答として配信されてもよい。

【0052】

マニフェストが指定され、コンテンツがセグメント化、編成、およびバージョン化され、HTTPが要求される方法の詳細は、HTTPを介した動的適応型ストリーミング（DASH）、HTTPライブストリーミング（HLS）、スムースストリーミング転送プロトコル（SSTP）などの特定の適応型ストリーミングプロトコルに依存し得る。以下の様々な追加の例示的な実装形態は、DASHの文脈で説明され得る。しかしながら、基礎となる原理は、HTTPを介した任意のタイプの適応型ストリーミングに適用可能である。さらに、基礎となる原理は、HTTP以外のネットワークプロトコルに基づくメディアコンテンツ要求メカニズムに適用可能である。

【0053】

HTTPを介した動的適応型ストリーミング（DASH）
適応型メディアストリーミングを実施するための1つの例示的なプロトコルは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）を含む。上述のように、DASHは、様々なプロキシおよびキャッシュを有するウェブサーバとして構成されたコンテンツサーバなどを含む、ハイパーテキスト転送プロトコル（HTTP）インフラストラクチャに基づくコンテンツ配信ネットワーク（CDN）を使用するメディアコンテンツのストリーミングを可能にする適応型ビットレートストリーミング実装形態の1つを表す。このようなコンテンツサーバは、DASHサーバと称され得る。したがって、上述のコンテンツ消費アプリケーションは、DASHクライアントと称され得る。

【0054】

DASHは、DASHサーバからDASHクライアントへのライブストリーミングをサポートし、DASHサーバが大規模な展開におけるストリーム適応管理の追加の負荷に対処する必要がないように、DASHクライアントがストリーミングセッションを制御することを可能にする。上述のように、DASHはまた、DASHクライアントが様々なDASHサーバからのストリーミングを選択することを可能にし、これにより、DASHクライアントの利益のためにネットワークのさらなる負荷分散を達成する。DASHは、例えば、DASHクライアントのネットワーク条件および処理能力に適合するようにビットレートを変更することによって、メディアトラックの異なるメディアバージョン間での動的な切替をさらに提供する。

【0055】

DASHでは、上述のメディアマニフェストは、特にMPDと称され得る（ただし、MPDという用語は、DASHに基づくもの以外の適応型ストリーミングシステムにおける任意のタイプのマニフェストを指すために一般に使用される）。例えば、DASHにおけるMPDは、DASHクライアントによって完全にまたは部分的にダウンロード可能であり、DASHサーバからストリーミングメディアセグメントを選択的かつ適応的に要求することによってメディアコンテンツをストリーミングするためにDASHクライアントによって使用される情報項目を提供するファイルとして構築されてもよい。

【0056】

MPDは、様々なフォーマットで構築され得る。例えば、MPDは、拡張マークアップ言語（XML）文書またはファイルの形態で構築されてもよい。MPDファイルが要求され、DASHクライアントに配信されてもよい。MPDファイルは、例えば、HTTP GET要求を介して、HTTPによって要求されてもよい。MPDファイルは、ストリーミングセッションの開始時に完全に配信されてもよい。あるいは、MPDファイルは、断片化されて部分的に配信されることが可能である。したがって、MPDファイルの一部は、ストリーミングの開始前に要求および配信されてもよく、MPDファイルの他の部分は、セッション立ち上げ遅延を低減するために、後に要求および配信されてもよい（これにより、ストリーミングは、メディアの後のセグメントに関する情報項目を待つ必要なく、より早いメディアセグメントで開始することができる）。MPDファイルはまた、ストリーミングセッション中に（例えば、必要であるがまだ取得されていないセグメント情報と共に）更新されることも可能である。

【0057】

いくつかの例示的な実装形態では、MPDファイルは、メディアコンテンツのセグメント化、セグメントの編成、およびセグメントの利用可能なバージョンを記述する。MPDは、コンテンツのアクセシビリティ機能、評価、カメラビュー、メタデータなどの表現をサポートする。DASHはまた、多視点でスケーラブルなコーディングされたコンテンツの配信をサポートしてもよい。

【0058】

いくつかの例示的な実装形態では、MPDファイルは、メディア消費タイムライン（例えば、ビデオコンテンツの再生時間）に沿った1つ以上の期間にわたる一連の記述を含んでもよい。1つ以上の期間の各々は、例えば、MPDファイル内の「期間」情報要素タグによって定義されてもよい。メディアコンテンツは、複数の連続する期間に編成されたMPDファイルによって示されてもよい。MPDファイルは、再生タイムラインにおける期間の各々について開始時間を識別し得る。開始時間は、メディアコンテンツの開始からの絶対開始時間として、または再生タイムラインにおける他の基準点からの相対オフセットとして定義されてもよい。

【0059】

いくつかの例示的な実装形態では、メディア期間ごとに、MPDファイルは、1つ以上の適応セットをさらに指定してもよい。メディアコンポーネントの1つ以上の異なる組み合わせ（またはサブセット）を取り込むために、異なる適応セットが指定されてもよい。例えば、ビデオと音声は異なる適応セットであり得る。異なるバージョンの音声（ステレオ音声またはマルチチャネル音声）は、異なる適応セットであってもよい。異なる言語の音声は、異なる適応セットであってもよい。特定の一例では、MPDファイルは、各期間が、1つのビデオ適応セット、およびサポートされる言語ごとに1つずつの複数の音声適応セットを含むと指定してもよい。適応セットはまた、字幕または任意のメタデータを含んでもよい。

【0060】

いくつかの例示的な実装形態では、特定の期間の適応セットは、MPDファイル内の任意の属性によって示されるグループに割り当てられてもよい。同じグループ内の適応セットは、一般に、互いに対する代替と見なされる。例えば、対応する期間のマルチメディアコンテンツのビデオデータのために任意の適応セットが選択され得るように、特定の期間のビデオデータの各適応セットは、同じグループに割り当てられることが可能である。1つの期間内のメディアコンテンツは、1つの適応セット、または適応セットの組み合わせのいずれかからのものであり得、各グループは、最大で1つの適応セットに寄与する。

【0061】

いくつかの例示的な実装形態では、各適応セットは、対応する期間の同じメディアコンポーネントの1つ以上の表現を含むとして、MPDファイルによって指定されてもよい。表現は、例えば、音声またはビデオデータのいくつかの代替的なエンコードされたバージョンのうちの1つであり得る。表現は、エンコードされたタイプによって、例えば、ビデオデータのビットレート、解像度、および／またはコーデック、ならびに音声データのビットレート、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の範囲の平均ビットレートを達成するために特定の方法でエンコードされた、エンコードされたメディアデータのセクションを指すために使用され得る。いくつかの例示的な実装形態では、適応セット内の表現ごとに、MPDファイルは、ビデオ／音声タイプ、ビデオ／音声コーデック、画素単位のビデオフレーム幅、画素単位のビデオフレーム高さ、ビデオ／音声フレームレート、および帯域幅（平均エンコード済みビットレートを表す）を含むがこれらに限定されない、表現の属性を指定し得る。

【0062】

適応セットの各表現はまた、適応セットに含まれるメディアコンポーネントの組み合わせに応じて、1つ以上のメディアコンポーネントを含んでもよい。表現内の各メディアコンポーネントは、音声、ビデオ、または時刻指定テキスト（例えば、クローズドキャプション用）などの1つの個々のメディアタイプのエンコードされたバージョンに対応し得る。メディアコンポーネントは、1つの表現内の連続するメディアセグメントの境界にわたって時間的に連続的であり得る。

【0063】

いくつかの例示的な実装形態では、表現は、1つ以上のセグメントを含み得る。各表現は初期化セグメントを含むことができ、または表現の各セグメントは自己初期化されることが可能である。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。場合によっては、初期化セグメントはメディアデータを含まない。メディアデータを含むセグメントは、時間セグメント化されたコンテンツを表し得る。異なる表現間のセグメントは、時間的に整合されてもよい。メディアセグメントごとに、MPDファイルは固有の識別子を含み得る。このような識別子は、ベースURL、ベースURN、またはベースユニフォームリソース識別子（URI）と組み合わされると、メディアセグメントのネットワークの場所を表す固有のURL、URN、またはURIを形成してもよく、これは、このメディアセグメントのHTTP要求に含まれる場合があり、配信のために要求されたセグメントを位置特定するためにコンテンツサーバによって使用され得る。

【0064】

例えば、メディアセグメントを要求するためのURLは、「http」または「https」の決まった方式で＜absolute－URI＞として定義されることが可能であり、ことによると、URLと一緒に範囲属性が提供される場合、バイト範囲によってさらに補完され得る。バイト範囲は、セグメント内のバイトの連続する範囲を識別するために表現されることが可能である。

【0065】

いくつかのさらなる例示的な実装形態では、サブ表現は、例えばサブ表現要素／インジケータを使用して、通常の表現に埋め込まれる（または含まれる）ものとしてMPDファイルにおいて指定または記述されてもよい。サブ表現要素は、表現に埋め込まれた1つまたはいくつかのメディアコンテンツコンポーネントの特性を記述するために使用され得る。例えば、サブ表現要素は、埋め込み音声コンポーネント（例えば、コーデック、サンプリングレートなど）、埋め込み字幕（例えば、コーデック）の特性を記述するために使用されてもよく、またはサブ表現要素は、何らかの埋め込み低品質ビデオ層（例えば、何らかのより低いフレームレートなど）を記述するために使用されてもよい。サブ表現および表現要素は、いくつかの共通の属性および要素を共有することができる。

【0066】

いくつかの例示的な実装形態では、DASHクライアントは、DASHサーバからMPDファイルの全体または一部にアクセスし、ダウンロードし、要求するように構成されてもよい。すなわち、DASHクライアントは、ライブストリーミングセッションを開始する際に使用するためのMPDファイルを取得し得る。MPDファイル、および表現の選択に基づいて、DASHクライアントは、サーバ上で利用可能な最新のセグメントが何かを判定することと、次のセグメントおよび場合により将来のセグメントのセグメント可用性開始時間を判定することと、セグメントの再生をいつ開始するかを判定することと、新しいMPDファイルをいつ取得／フェッチ／要求するかを判定することと、を含むいくつかのさらなる決定を行うことができる。

【0067】

いくつかの例示的な実装形態では、MPDは、非周期的な情報をDASHクライアントまたはDASHアプリケーションにシグナリングするために、DASHイベントに関する情報をさらに含んでもよい。イベントは、ある持続時間を有する特定のメディア表現時間で開始して、時刻指定されてもよい。追加的または代替的に、イベント情報は、広告挿入キューなど、メディア表現の再生中の特定の時間に関連付けられたメディアプレーヤのための制御メッセージを含んでもよい。ストリーミング中に挿入され得るメディアは、広告サーバなどの別個のサーバから提供され得る。メディア表現とは別にMPDによってイベントをシグナリングすることに加えて、イベントはまた、1つまたはいくつかの選択された適応セット内の選択されたメディア表現のみにおいて、またはすべての表現において、帯域内で多重化されてもよい。

【0068】

例示的なDASHシステム200が図2に示されている。DASHシステム200は、ネットワーク250によって接続された、1つ以上の集中型または分散型コンテンツサーバ210および情報処理装置230を含み得る。DASHシステム（200）はまた、1つ以上の広告サーバ220などの1つ以上の補足コンテンツサーバも含み得る。

【0069】

コンテンツサーバ210は、メインコンテンツ（例えば、メインプログラム）およびコンテンツのためのMPDを情報処理装置230に提供し得る。マニフェストファイルは、MPD生成器214によって生成されることが可能である。メインコンテンツおよびマニフェストファイルは、同じサーバまたは異なるサーバから提供されることが可能である。

【0070】

情報処理装置230は、コンテンツサーバ210と直接通信するDASHクライアント232を含み得る。情報処理装置230のDASHアプリケーション234によって制御されるDASHクライアント232は、MPDを要求および／または受信してもよく、MPDに基づいてコンテンツサーバ210のHTTPサーバ212からメインコンテンツを要求および取得してもよい。MPDは、DASHクライアント232によって処理され得る。さらに、DASHクライアント232は、広告サーバ220から広告コンテンツを、またはDASHイベントに応じて1つ以上の補足コンテンツサーバから他のコンテンツ（例えば、インタラクティブコンテンツ）を取得してもよい。メインコンテンツおよび広告コンテンツは、DASHクライアント232およびDASHアプリケーション234によって処理され、情報処理装置230の表示デバイス236上の表示のために出力されることが可能である。表示デバイス236は、情報処理装置230に組み込まれてもよく、または外付けであってもよい。さらに、DASHクライアント232は、1つ以上の時刻指定メタデータトラックから他のイベント情報を抽出し、抽出されたイベント情報をさらなる処理のためにDASHアプリケーション234に送信してもよい。DASHアプリケーション234は、例えば、イベント情報に基づいて補足コンテンツを表示するように構成されてもよい。

【0071】

DASHクライアント232のための一例が図3に示されている。図3に示されるように、例示的なDASHクライアント232は、DASHアクセスエンジン304と、選択ロジック302と、メディアエンジン306および308とを含み得る。DASHアクセスエンジン302は、例えば、ストリーミングメディアのMPDの一部または全体を取得し、動的に要求されたストリーミングメディアのセグメントデータを要求および取得し、MPD DASHイベントに従って補足メディア（広告）を要求するために、コンテンツサーバと通信するように構成されてもよい。選択ロジック304は、適応セットおよび表現の選択を含む、要求すべき次の1つ以上のセグメントを決定するように構成されてもよい。このような決定は、例えば、ユーザ命令によって、ならびにネットワーク帯域幅およびスループットなどの他のリアルタイム情報によって、決定され得る。メディアエンジン306は、メディアセグメントのフォーマット（例えば、MPEG）およびメインメディア出力を生成するためのメディアセグメントのタイミングに従って、DASHアクセスエンジン302によって受信されたセグメントデータを処理するように構成され得る。メディアエンジン308は、例えばメインメディア出力に挿入され得る補足メディア出力（広告など）を生成するために、DASHアクセスエンジン302からの時刻指定DASHイベントに関連付けられたメディアコンテンツを処理するように構成されてもよい。

【0072】

メディアコンテナファイル
メディアコンテンツは、様々な事前定義されたフォーマットを有するファイルに記憶され得る。メディア格納ファイルは、ビデオ、音声、およびビデオならびに音声に関連付けられた他のデータなどの時間ベースのマルチメディアデータを含むファイルのための一般的な構造を定義するために使用され得る。ISOベースメディアファイルフォーマット（ISOBMFF）は、1つの例示的なマルチメディアコンテナファイルである。これは、マルチメディアの交換、管理、編集、およびプレゼンテーションを容易にする柔軟で拡張可能なフォーマットとして設計された。以下の開示では、「ISOBMFF」という用語は特定のコンテナファイルフォーマットを指すが、以下の基礎となる原理が適用される任意のメディアコンテナファイルフォーマットを表すためにも以下で使用される。

【0073】

ISOBMFFは、オーディオビジュアルプレゼンテーションなどのメディアデータの時刻指定されたシーケンスのためのタイミング、構造、およびメディア情報を含み得る。ファイル構造は、オブジェクト指向として設計されてもよい。ISOBMFFは、例えば、簡単な方法で基本オブジェクトに分解されることが可能である。オブジェクトの構造は、定義されたそれらのタイプから暗示および導出され得る。

【0074】

ISOBMFFに準拠するファイルは、「ボックス」と称される一連のオブジェクトとして形成され得る。すべてのデータは、ボックス内に格納され得る。ボックスは、階層的にカスケードされてもよく、ファイル内に他のデータがなくてもよい。プレゼンテーション（例えば、動きシーケンス）は、いくつかのファイル内に格納され得る。すべてのタイミングおよびフレーミング情報はISOBMFFファイルに含まれてもよく、補助ファイルは本質的に任意のフォーマットを使用してよい。

【0075】

例えば、ISOBMFFファイルの先頭に、ファイルタイプボックス（「ftyp」）が配置されてもよい。ファイルタイプボックス内で、使用されるエンコーディングのタイプ、各エンコーディングのデータがどのように記憶されるか、ファイルに適用される制約および拡張子、互換性および／またはファイルの意図される用途を含むがこれらに限定されない、一般的な情報が指定され得る。他の例として、ファイルタイプボックスの後には、コンテンツの様々なトラックを定義するカスケードボックスを格納するムービーボックスが続いてもよい。

【0076】

ISOBMFFは、ネットワークを介したメディアデータのストリーミング、ならびにローカル再生をサポートし得る。ストリーミングをサポートするISOBMFFファイルは、ストリーミングするデータユニットに関する情報（例えば、ファイル内の基本的なストリーミングデータがストリーミングプロトコルを介してどのように提供されるべきか）を含み得る。

【0077】

いくつかの例示的な実装形態では、コンテナファイルは、ストリーミングマニフェスト内の特定の表現に対応するメディアコンテンツを記述するために使用され得る。このような実装形態では、マニフェストに記述された各表現は、メディアコンテナファイルに関連付けられてもよい。

【0078】

ピクチャインピクチャ
いくつかの例示的な実装形態では、視覚メディアコンテンツは、ピクチャインピクチャ（PiP）モードでオーバーレイされ得る。ピクチャインピクチャのユースケースが図4に示されている。図4に示されるように、PiPビューは、メインピクチャおよびPiPを含む。メインピクチャは画面全体を撮影するが、オーバーレイピクチャは画面の一部を撮影し、メインピクチャの対応するエリアをカバーする。PiPの座標はx、y、高さ、および幅で示され、これらのパラメータは、これに対応して、メインピクチャ座標に対するPiPの位置（例えば、左上コーナー画素座標）およびサイズを定義する。

【0079】

ストリーミングメディアの場合、メインビデオおよびPiPビデオは、2つの別々のストリームとして配信され得る。これらが独立したストリームである場合、これらは別々のデコーダによってデコードされ、次いでレンダリングのために一緒に構成され得る。いくつかの例示的な実装形態では、ビデオコーデックがストリームのマージをサポートする場合、PiPビデオストリームはメインビデオストリームと組み合わされてもよく、場合によってはメインビデオのカバーエリアを表すストリーミングをPiPビデオに置き換え、次いで、デコーディングおよびその後のレンダリングのために単一のストリームがデコーダに送信され得る。

【0080】

したがって、効率的なPiP処理を提供するために、PiP体験における様々なメディアコンテンツの可能な役割および関係を指定するための様々なシグナリング情報が、メディアコンテナファイルに含まれ得る。このようなシグナリングはその後、意図されるPiP体験のために再生デバイスによって解釈される。同様に、このようなシグナリングはまた、ストリーミングクライアントに様々なPiPの可能性を示すために、ストリーミングのためのマニフェスト（例えば、DASH MPD）に含まれてもよい。するとストリーミングクライアントは、マニフェストを解析し、いつどのようにしてPiP体験を使用し、ユーザに提供するかを決定することができる。ストリーミングマニフェストにおけるこのようなPiPシグナリングは、例えば、ストリーミングメディアに関連付けられた基礎となるメディアコンテナファイル内のPiPシグナリングから導出され得る。

【0081】

一般的なPiPシグナリングの解決策は、例えば、2つ以上のトラックがPiP体験のためにどのように使用され得るかを示すことができ、すなわち、トラックのデコードされたピクチャは、（1つまたは複数の）他のトラックのデコードされたピクチャの領域の上にオーバーレイされることが可能である。直接シグナリングされ得るか、または少なくともシグナリングから導出され得る例示的な情報は、以下を含み得るがこれらに限定されない。
・ PiP体験を作り出すことができるメディアコンテンツ（例えば、トラック）の可能な組み合わせ。
・ PiP体験におけるメインおよびオーバーレイコンテンツまたはトラックの識別。
・ PiP体験におけるオーバーレイコンテンツまたはトラックの位置の指示。

【0082】

以下の例示的な実装形態は、包括的で柔軟なPiP体験を可能にするPiPシグナリングをサポートするためのいくつかの既存のISOBMFF およびDASHマニフェストフレームワークの修正／拡張を提供する。

【0083】

例えば、開示された方式は、PiP体験を提供するためのグループとしてメディアトラックを定義およびシグナリングするために、トラックグループの概念を使用する。例示的な方式は、一意に識別される複数の異なるPiPメディアトラックグループ化を可能にする。PiP体験トラックグループ内のメディアトラックは、独立してデコード可能であってもよく、またはデコーディングのために一緒にマージされてもよい。例示的な方式は、これに対応して、PiP体験トラックグループの各々におけるこのようなマージ能力を示すシグナリングを含む。

【0084】

他の例として、ピクチャインピクチャ体験は、ストリーミングマニフェストでシグナリングされてもよい。このようなシグナリングは、ピクチャインピクチャ記述子を用いて適応セットを識別するステップ、ならびにPiP体験を識別するために役割記述子を使用するステップ、さらに1つ以上のサブピクチャが置換のための1つ以上の領域として識別されるマニフェストにおいてサブピクチャに注釈を付けるステップを含み得る。

【0085】

メディアコンテナファイル内の例示的なPiPシグナリング
いくつかの例示的な実装形態では、PiP体験を指定するために、トラック事前選択グループが使用され得る。図5の501に示されるように、例えばISOBMFFのメディアコンテナファイルは、図5の502において「moov」と称されるメタデータボックスを含み得る。例示的な「moov」ボックス5020は、メディアコンテナファイルに含まれるメディアコンテンツのための一般情報を含み得る。「moov」ボックスは、「moov」ボックスに関連付けられたプレゼンテーションの作成および修正時間などの情報を含む、図5の504において「mvhd」と称されるムービーヘッダボックスを含み得る。

【0086】

「moov」ボックス502は、図5の506において「tkgd」と称されるトラックグループ記述ボックスを追加で含み得る。「tkgd」ボックスは、その下に、様々なメディア体験のためのトラックグループの1つ以上の記述を指定し得る。トラックグループの各々の仕様または記述は、図5の508において「prse」と称される事前選択トラックグループエントリボックスに含まれ得る。これらの事前選択グループの各々は、特定のメディア体験を共に達成するメディアトラックの集まりとして識別され得る。図5の例では、2つの別々の「prse」ボックスに対応する2つのトラックグループが指定される。

【0087】

事前選択トラックグループエントリ「prse」ボックスの各々は、トラックの対応する事前選択グループの固有の識別を指定するための「track＿group＿id」要素を含み得る。図5で指定された2つの例示的なトラックグループは、track＿group＿id＝1および2に対応する。事前選択トラックグループエントリ「prse」ボックスの各々はまた、トラックの事前選択グループ内のいくつかのトラックを指定する「num＿tracks」要素も含む。「prse」ボックスの各々は、1つ以上の「preselection＿tag」を任意選択的に含んでもよく、これは、事前選択体験の性質に関してメディア内のいくつかの事前選択から1つを一意に識別するために再生システムがデコーダに提供することができるコーデック固有値であり得る。図5の例では、事前選択トラックグループ1は、その「preselection＿tag」によってPiP体験のための事前選択であるとして識別される。「事前選択タグ」要素がPiPをシグナリングするために「pip」値を使用する識別は、単なるオプションである。後述のように、PiP体験は、「prse」ボックス内（例えば、以下に記載される「種類」ボックス内）の他の代替要素を使用してシグナリングされ得る。例えば、図5の例では、「track＿group＿id」＝2を有する事前選択グループは、PIP事前選択グループでもある。ここで、PIPの指示は「事前選択タグ」に提供されなくてもよく、むしろ「種類」ボックスにおいて提供され得る。いくつかの例示的な実装形態では、両方のシグナリングオプションが提供されてもよく、「prse」ボックス（または各事前選択グループ）の各々は、PiP体験をシグナリングするために異なるオプションを使用してもよい。

【0088】

事前選択トラックグループエントリ「prse」の各々は、「種類」ボックスをさらに含んでもよく、これは、対応する事前選択トラックグループの役割を指定するために代替的に使用されてもよい。例えば、事前定義された役割方式がトラックグループ事前選択のために定義されてもよい。事前定義された役割方式は、トラックグループ事前選択のための役割のセットを指定し得る。「prse」によって指定された特定の事前選択グループのための「種類」ボックスは、事前定義された役割のうちの1つを示すデータ項目を含み得る。例えば、「種類」ボックスは、メインピクチャの1つ以上のエリアが1つ以上の代替ピクチャでオーバーレイされ得る事前定義された役割のうちの1つとしてピクチャインピクチャ体験をシグナリングしてもよい。事前定義された役割方式は、例えば、以下でさらに詳細に記載されるようにDASH Role schemeIdURIによって指定されてもよく、事前定義された役割値のうちの1つは、PiP体験を示すために、「pip」であってもよい。他の代替的な役割方式が使用されてもよい。

【0089】

「moov」ボックス内で別々に、様々なメディアトラックは、図5の510において「trak」と称されるトラックボックスによって各々記述されてもよい。図5に示されるように、複数のメディアトラックがメディアコンテナファイル内に記述／定義されてもよい。これに対応してコンテナファイルに含まれる複数の「trak」ボックス510があってもよい。図5は、それらの固有の識別子trak＿id＝1、2、および3によって識別される、3つのこのような例を示す。

【0090】

「trak」ボックスの各々は、対応するメディアトラックの基本情報を提供する。例えば、メディアトラック識別子が指定されてもよい（「trak＿id」）。「trak」ボックスの各々は、図5の512において「trgr」と称される任意選択的なトラックグループボックスをさらに含み得る。メディアトラックの各々のトラックグループ「trgr」ボックスは、メディアトラックが属する1つ以上の事前選択トラックグループを指定する。メディアトラックが属する1つ以上のトラックグループの各々は、図5の514において「pres」と称される1つの事前選択ボックスによって指定され得る。したがって、メディアトラックのトラックグループ「trgr」ボックスは、この特定のメディアトラックがいくつの（上述の「tkgd」ボックス506の「prse」ボックス508において定義されるような）事前選択グループに関連付けられるかに応じて、1つ以上の事前選択ボックス「pres」を含み得る。

【0091】

1つ以上の事前選択「pres」ボックス514の各々は、図5の516に示されるように、事前選択グループIDによって対応するトラックグループを識別してもよく、一例として、図5の518において「prsp」と称される事前選択処理ボックスを介して対応する体験のために事前選択トラックグループ内の他のメディアトラックに対してこの特定のメディアトラックがどのように使用されるかをさらに任意選択的に指定してもよい。「prsp」ボックスは、トラックの特定のグループ事前選択のために任意選択的であってもよく、必要に応じて含まれてもよい。例えば、図5において、trak＿id＝1、2、および3を有するメディアトラックの各々は、「prsp」ボックスを含めて、上記の「tkgd」ボックス506内の2つの「prse」ボックス508によって定義された2つの例示的な事前選択トラックグループの一方または両方に関連付けられるかまたはこれらに属してもよい。

【0092】

track＿group＿idを有する特定の事前選択グループに関するtrak＿id＝1を有するメディアトラックのための例示的な事前選択処理「prsp」ボックス518は、図5の520または521において「track＿order」と称されるトラック順序パラメータを指定し得る。トラック順序パラメータは、事前選択グループ内のメディアトラックの中の優先順位を指定するために使用され得る。例えば、トラック順序パラメータの値が低いほど、高い優先度を示し得る。特に、例示的なPiP事前選択グループでは、PiP体験のメインピクチャの一部であるトラックは、track＿id＝1を有するトラックについて520で示されるように、track＿order＝0に設定され得る。メインピクチャの1つ以上の領域のオーバーレイまたは代替として使用されるように意図されるピクチャインピクチャ体験のためのPiP事前選択グループの任意の他のメディアトラックは、track＿id＝1および2を有するトラックについて521で示されるように、0より大きいtrack＿order値に設定され得る。事前選択グループの代替トラック内で、より低いtrack＿order値は、他のメディアトラックに対するメディアトラックの代替ピクチャの優先度を示す。

【0093】

例示的な事前選択処理「prsp」ボックス518は、図5の522および523において「sample＿merge＿flag」と称されるサンプルマージフラグをさらに任意選択的に指定し得る。サンプルマージフラグは、2進値として指定され得る。例えば、2進値1を有する「sample＿merge＿flag」は、このトラックがマージトラックグループに属し、マージデコーディング（デコーディング前のメインおよびサブピクチャのビットストリームのマージ）のためにこのトラックグループ内の1つ以上の他のトラックとマージ可能となり得ることを示してもよい。このマージトラックグループ内のメディアトラックは、事前選択グループ（図5の520および521）に関して指定され、上述されたような、それらの「track＿order」値に従ってソートされ得る。マージグループは、例えば、sample＿merge＿flag＝1を有する1つのメディアトラックを含んでもよく、sample＿merge＿flag＝0を有するかまたはsample＿merge＿flag のない（この場合、デフォルトで0）1つ以上のメディアトラックがこれに続く。例えば、マージグループのすべてのトラックは、同じメディアタイプであってもよく、すべてのサンプルが時間整合されていてもよい。PiP事前選択グループでは、sample＿merge＿flag＝1を有するトラックは、他のトラックがマージされ、次いでPiP体験を形成するためにマージされたとおりにデコードされ得るメインピクチャであってもよく、sample＿merge＿flagが1であるメイントラックを有するグループ内のsample＿merge＿flag＝0を有するメディアトラックは、代替ピクチャであり得る。

【0094】

図5の例では、track＿group Id＝2を有するPiPグループは、マージ可能なメイントラック（523で示されるように、track＿id＝1を有し、そのsample＿merge＿flag＝1を有する）と、このPiPグループ内のメインピクチャ（track＿id＝1）にマージされることが可能なtrack＿id＝3を有するサブピクチャトラックとを有するが、単独では、その「prsp」ボックスにsample＿merge＿flagを含めないことによって、他のトラックに含むようにマージ可能ではない。この例では、sample＿merge＿flagがグループ2に対してトラック3について含まれる場合、0値を有するものとして含まれる。

【0095】

さらに図5の例において、track＿group Id＝1を有するPiPグループは、マージ不可能なメイントラック（522で示されるように、track＿id＝1を有し、そのsample＿merge＿flag＝0を有する）を有する。したがって、このPiPは、デコーディングの前にマージされるべきではない。むしろ、各トラックは、別々にデコードされ、次いでデコーディング後に結合されたピクチャを形成するためにPiP構成に従ってマージされる。このPiPグループは、サブピクチャとしてトラック2を含む。そのsample＿merge＿flagは、有無にかかわらず、このPiPグループに関して重要ではない。

【0096】

PiP事前選択グループに参加するメディアトラックでは、例えば、PiP事前選択グループに対応するその「prsp」ボックス内に、図5の524および525において「region＿ids」と称される、領域の識別子のリストをさらに任意選択的に含んでもよい。領域IDのリストは、PiP事前選択グループ内の他のメディアトラックがオーバーレイすることができるこのメディアトラック内のコーディングされたビデオデータユニットの余白領域のリストを識別し得る。このフィールドは、デコーダがデコーディングのためにマージされたビットストリームを適切に組み立てることができるように、マージが行われ得るマージ可能なトラックのデコーディング前のビデオビットストリーム内の領域の位置を示す。NULL文字列または「region＿ids」の不在は、この対応するメディアトラックのこの領域のないことが、コーディングされたビットストリーム内で交換可能または置換可能であることを示し得る。したがって、「sample＿merge＿flat」は、「region＿ids」がNULL文字列またではないときに1（デコーディング前にマージ可能）に設定されるべきであり、したがってsample＿merge＿flag＝1と非NULL「region＿ids」との組み合わせは、この対応するトラックの「region＿ids」によって表されるコーディングされたデータユニットが、0より大きいtrack＿order値を有する他のトラックに置き換わることが可能であることを示し得る。さらにいくつかの例示的な実装形態では、非NULL「region＿ids」を有するメディアトラックはまた、0の「track＿order」を有するべきであり、PiP体験におけるメインピクチャとしてメディアトラックを示す。

【0097】

上記の例示的な構成方式では、メディアコンテナファイル内のPiPをシグナリングするための例示的な方法が構築され得る。このような例示的な方法では、
・ コンテナファイル内の事前選択トラックグループエントリボックス、例えば「prse」ボックスは、PiP体験を提供するように構成されたトラックグループを定義するために使用され得る。
・ トラックグループ識別子、例えば「track＿group＿id」は、例示的なPiP体験に関連付けられた例示的なメディアトラックグループのための識別子を指定するために、事前選択トラックグループエントリボックス内で使用され得る。
・ 整数要素、例えば「Num＿tracks」は、PiP事前選択グループ内のコンポーネントトラックの総数を示すために、トラックグループ定義における事前選択トラックグループエントリボックス内に含まれ得る。
・ 情報ボックス、例えば「種類」ボックスは、PiPを含む役割の事前定義されたセットの中の事前選択グループの役割を指定するために、事前選択トラックグループエントリボックス内に含まれ得る。
・ メディアトラックグループを指定し、トラックが、PiP体験を提供するように構成され得るグループ（PiP事前選択グループ）の一部であることを示すための、トラックボックス内の事前選択ボックス、例えば「pres」ボックス。
・ 対応するトラックグループを識別するためのメディアトラックの事前選択ボックス（「pres」）内のトラックグループ事前選択識別子であって、これは上記の「prse」ボックス内のトラックグループの定義と組み合わせて、トラックグループがPiP体験用であるか否かを判定する。
・ PiP体験選択グループに対するメディアトラックの処理方法を定義するための、メディアトラックの事前選択ボックス（「pres」）内の事前選択処理ボックス、例えば「prsp」ボックス。
・ このメディアトラックがPiP体験のメインピクチャ（例えば、track＿order＝0）であるか、またはPiP体験の代替ピクチャ（例えば、track＿order＝1）であるかを示すための、メディアトラックのPiP事前選択グループに関連付けられたメディアトラックの事前選択処理ボックス（「prsp」）の一部としての優先度の値、例えば「track＿order」。メインPiPが複数のトラックからなる場合には、これらの複数のトラックは、track＿orderが0である同じtrack＿group＿idを有する「pres」ボックスの下に「prsp」ボックスを含む。
・ PiP体験内のコーディングされたメディアトラックが、コーディング前にグループ内の他のコーディングされたトラックによってマージ可能であるか否かを示すための、メディアトラックのPiP事前選択グループに関連付けられたメディアトラックの事前選択処理ボックス（「prsp」）の一部としてのマージ指示、例えば「sample＿merge＿flag」、例えば、sample＿merge＿flag＝1は、トラックがマージ可能であることを示し得る。
・ デコーディング前にPiP体験のためのメディアトラックの交換可能な領域の識別子のリストを指定するための、メディアトラックのPiP事前選択グループに関連付けられたメディアトラックの事前選択処理ボックス（「prsp」）の一部としての領域リスト、例えば「region＿ids」。

【0098】

ここでも単なる例として、上述のシグナリング原理の応用として示されているにすぎないが、図5のコンテナファイルは、グループ1およびグループ2の2つのトラック事前選択グループと、トラック1、トラック2、およびトラック3の3つのメディアトラックとを含む。事前選択トラックグループ1はメディアトラック1およびトラック2を含み、事前選択トラックグループ2はメディアトラック1およびトラック3を含む。両方の事前選択トラックグループは、「種類」ボックスにおいて指定されるように、値「pip」を有する「preselection＿tag」によって、またはその両方で、PiP体験を提供する（「種類」ボックスのコンテンツは図5に示されないが、上記で記載されている）。

【0099】

図5の事前選択トラックグループ2については、PiP体験は、メインPiPピクチャのサブピクチャストリームをデコーディングのために代替ピクチャストリームで置換する可能性を用いて定義される。この例示的なPiP体験選択グループ（track＿group＿id＝2）の2つのメディアトラック（メディアトラック1およびトラック3）のうち、メディアトラック1には、他のメディアトラックであるメディアトラック3に関するPiP体験においてトラック1がどのように使用されるかを示すための「prsp」ボックスが提供される。具体的には、trak＿id＝1を有するメディアトラックは、（0の「track＿order」によって示されるように）メインピクチャを形成する。メインピクチャとしてのメディアトラック1は、メディアトラック1について「1」に設定されたその「sample＿merge＿flag」によって示されるように、他のメディアトラック（例えば、メディアトラック3）からのコンテンツによってマージ可能である。さらに、メディアトラック1内の「1」の領域ID値を有する領域は、単一のデコーディングの前にメディアトラック3のコンテンツと置換可能である。

【0100】

図5の事前選択トラックグループ1については、PiP体験は、メインピクチャトラック1に関連付けられたsample＿merge＿flagが0に設定されるので、（マージストリームの単一のデコーディングではなく）2つの独立したデコーディングを用いて定義される。

【0101】

以下では、上述のメディアコンテナファイル内のPiPシグナリング方式における要素のための構文が指定され得る方法をさらに説明する。

【0102】

事前選択処理ボックス定義：
ボックスタイプ：‘prsp’
コンテナ：事前選択グループボックス（「pres」）
必須：いいえ（任意選択）
数量：ゼロまたは1（ありまたはなし）

【0103】

上述のように、ならびに一例として、このボックスは、「moov」ボックス内にある、メディアトラックの「trak」ボックス内にある、「trgr」ボックス内にある、「pres」ボックス内にある。これは、事前選択に寄与するトラックがどのように処理され得るかに関する情報を含み得る。いくつかの例示的な実装形態では、メディアタイプ固有のボックスは、「prsp」内のさらなる処理を記述するために使用されてもよい。このボックスは、トラック内の事前選択ボックス内に存在するかまたはしないかのいずれかである。

【0104】

事前選択処理ボックス構文
aligned（8）class PreselectionProcessingBox
extends FullBox（’prsp’，version＝0，flags）｛
unsigned int（8）track＿order；
unsigned int（1）sample＿merge＿flag；
unsigned int（7）reserved；
utf8string region＿ids；
／／以下の追加処理を定義するさらなる属性およびボックス
／／事前選択に寄与するトラック
｝

【0105】

事前選択処理ボックスの様々な構文要素の意味論が、以下でさらに説明される。

【0106】

事前選択処理ボックス意味論
・ 「track＿order」は、以下に記載されるように、事前選択グループ内の他のトラックに対するこのトラックの順序を定義する。
・ 1に等しい「sample＿merge＿flag」は、このトラックがデコーディング前に他のトラックとマージ可能となり得ることを示す。
・ 「region＿ids」は、デコーディング前にそれらの対応する代替ストリームがこの事前選択において他のコーディングされたトラックと置き換わることができるコーディングされたビデオデータユニットのための余白IDのリストを指定する。NULL文字列は、交換可能な領域がないことを意味する。例えば、このフィールドは、track＿order＝0の場合にのみ非NULL値を有することができる。PiP体験のためのこのフィールドの使用は、上記および下記に記載され、下記でさらに詳細に記載される。

【0107】

例えば、ピクチャインピクチャアプリケーションでは、メインピクチャの一部であるすべてのトラックは、そのtrack＿order＝0を有することになる。（代替ピクチャとして知られる）メインピクチャの1つ以上の領域のオーバーレイまたは代替として使用されるように意図されるピクチャインピクチャアプリケーション内の任意のトラックは、そのtrack＿orderを0より大きい値で設定させる。より低いtrack＿order値は、代替ピクチャの優先度を示す。

【0108】

サンプルエントリ固有の仕様は、事前選択用のトラックが特定の順序でそれぞれのデコーダインスタンスに提供されることを必要とする場合がある。track＿idなどの他の手段はこの目的のために信頼できないので、互いに対して事前選択においてトラックを順序付けるために、track＿orderが使用され得る。より低い数字は、所与の時刻において、対応するトラックのサンプルが、より高いトラック順序番号を有するトラックのサンプルよりも前にデコーダに提供されることを示す。事前選択における2つのトラックがそのtrack＿orderを同じ値に設定している場合、または事前選択処理ボックスがトラックのうちの少なくとも1つについて存在しない場合、これらのトラックの順序は事前選択に関係なく、サンプルは任意の順序でデコーダに提供されることが可能である。

【0109】

マージグループは、track＿orderに従ってソートされたトラックのグループとして定義されてもよく、1に設定されたsample＿merge＿flagを有する1つのトラックの後に、0に設定されたsample＿merge＿flagを有する連続するとラックのグループが続く。マージグループのすべてのトラックは、同じメディアタイプであり、すべてのサンプルが時間整合されるものとする。

【0110】

サンプルエントリタイプが事前選択のサンプルをマージするためのコーデック固有のプロセスに関連付けられている場合、このプロセスが使用される。

【0111】

sample＿merge＿flag＝1とNULLでないregion＿idsとの組み合わせは、region＿ids内のidsによって表されるコーディングされたデータユニットが、0より大きいtrack＿order値を有する他のトラックに置き換わることが可能であることを示し得る。領域IDの具体的な意味論は、特定のコーデックに対して明示的に指定される必要がある。

【0112】

いくつかの例示的な実装形態では、マージグループ内のトラックがすべて「mhm2」（MPEG－H 3D Audio）のサンプルエントリタイプである場合、マージプロセスは、例えば、ISO／IEC 23008－3：2019の14．6項に定義され得る。

【0113】

いくつかの例示的な実装形態では、マージグループ内のトラックは、異なるサンプルエントリタイプを有してもよい。

【0114】

いくつかの例示的な実装形態では、サンプルエントリタイプが事前選択のサンプルをマージするためのコーデック固有のプロセスに関連付けられていない場合、およびregion＿idsがNULLであるときには、以下のプロセスが使用されるものとする。マージグループ内のマージは、寄与するトラックにわたって同じタイムスタンプを有するトラックサンプルのタプルを形成することによって進行し得る。タプル内のサンプルの順序は、track＿orderによって決定され得る。これらのタプルは、サンプルのバイト単位の連結によって形成されてもよく、それぞれのタイムスタンプが割り当てられた単一のサンプルをもたらす。新しいトラックの生成が目標とされる場合、各マージグループは、マージされたトラックのメディアタイプから導出されたメディアタイプに適合する別々の出力トラックをもたらし得る。マージグループの一部ではないトラックでは、マージプロセスは、本開示によって特に限定されない。

【0115】

事前選択トラックグループエントリボックス定義
ボックスタイプ：’prse’
コンテナ：TrackGroupDescriptionBox
必須：いいえ
数量：ゼロ以上

【0116】

上述のように、「prse」ボックスは、「moov」ボックス内にあるトラック事前選択グループボックス「tkgd」内にあってもよい。これは、様々な事前選択トラックグループの定義に関する情報を含み得る。

【0117】

事前選択は、例えば、オーディオレンダリング指示、オーディオインタラクティビティ、またはチャネルレイアウトなどの言語、種類、またはメディア固有の属性によって承認されることが可能である。事前選択トラックグループエントリボックスでシグナリングされた属性は、寄与するトラックでシグナリングされた属性よりも優先され得る。

【0118】

事前選択トラックグループエントリボックスは、「prse」に等しいtrack＿group＿typeによって識別されたトラックグループのみを記述するように構成され得る。

【0119】

いくつかの例示的な実装形態では、1に設定されたtrack＿in＿movieフラグを有する少なくとも1つの寄与するトラックを有するすべての事前選択は、事前選択トラックグループエントリボックスによって承認され得る。そうでなければ、事前選択トラックグループエントリボックスの存在は任意選択的であってもよい。

【0120】

いくつかの例示的な実装形態では、事前選択を一意に承認するすべての属性は、事前選択の事前選択トラックグループエントリボックス内に存在するものとする。

【0121】

事前選択トラックグループエントリボックス構文
aligned（8）class PreselectionTrackGroupEntryBox
extends TrackGroupEntryBox（’prse’，version＝0，flags）
｛
unsigned int（8）num＿tracks；
utf8string preselection＿tag；
if（flags＆1）｛
unsigned int（8）selection＿priority；
｝
if（flags＆2）｛
unsigned int（8）segment＿order；
｝
／／事前選択を記述するボックス
｝

【0122】

事前選択処理ボックスの様々な構文要素の意味論が、以下でさらに説明される。

【0123】

事前選択トラックグループエントリボックス意味論
事前選択トラックグループエントリボックス「prse」は、対応する事前選択グループが選択されるときにどの体験が利用可能であるかに関する情報を含み得る。事前選択を記述するのに適したボックスは、本明細書で定義されるボックスの以下のリストを含むが、これらに限定されない。
・ オーディオ要素を定義したボックス：AudioElementBox
・ オーディオ要素選択を提供するボックス：AudioElementSelectionBox
・ 拡張言語を指定するボックス：ExtendedLanguageBox
・ 他のユーザデータを指定するボックス：UserDataBox
・ 事前選択タイプおよび情報を指定するボックス：KindBox
・ ラベリング情報を提供するボックス：LabelBox
・ オーディオレンダリングを示すボックス：AudioRenderingIndicationBox
・ チャネルレイアウトを指定するボックス：ChannelLayout

【0124】

いくつかの例示的な実装形態では、UserDataBoxが事前選択トラックグループエントリボックスに含まれる場合には、これは上記のボックスのいずれも担持しない。

【0125】

いくつかの例示的な実装形態では、num＿tracksは、この事前選択トラックグループによってグループ化された非代替トラックの数を指定する。

【0126】

いくつかの例示的な実装形態では、事前選択トラックグループによってグループ化されたトラックは、この事前選択のIDに等しいtrack＿group＿idを有する「pres」トラックグループを有するトラックであってもよい。

【0127】

いくつかの例示的な実装形態では、この事前選択トラックグループによってグループ化された非代替トラックの数は、以下の合計であってもよい。
・ 0に等しいalternate＿groupを有し、この事前選択トラックグループによってグループ化されたトラックの数、
・ この事前選択トラックグループによってグループ化されたすべてのトラック内の一意の非ゼロalternate＿group値の数。

【0128】

いくつかの例示的な実装形態では、num＿tracksの値は、このファイル内のこの事前選択トラックグループによってグループ化された非代替トラックの数以上であってもよい。0に等しい値は、このトラックグループによってグループ化されたトラックの数が未知であるか、またはトラックグループを処理するのに不可欠ではないことを示し得る。

【0129】

いくつかの例示的な実装形態では、num＿tracksの値は、事前選択が複数のファイルに分割されるときにこのライフ内に同じtrack＿group＿idを有する事前選択グループボックス（「pres」）を含む非代替トラックの数よりも大きくすることができる。

【0130】

いくつかの例示的な実装形態では、プレーヤが、num＿tracksによって示されるよりも少ない、この事前選択トラックグループによってグループ化された非代替トラックへのアクセスを有するとき、プレーヤは、この事前選択トラックグループによってグループ化されたトラックを省略する必要があり得る。

【0131】

いくつかの例示的な実装形態では、preselection＿tagは、メディア内のいくつかの事前選択から1つを一意に識別するために再生システムがデコーダに提供することができるコーデック固有値であってもよい。

【0132】

いくつかの例示的な実装形態では、selection＿priorityは、ディア言語などによる他の区別が可能ではない場合に事前選択の優先度を宣言する整数であってもよい。数字が小さいほど、高い優先度を示す。

【0133】

いくつかの例示的な実装形態では、segment＿orderは、存在する場合、事前選択の受信したセグメントを順序付けするために従うように提案されるセグメントの順序規則を指定する。以下の値は、一例として、ISO／IEC 23009－1：2022の5．3．11．5項による意味論を用いて指定される。
0：未定義
1：時系列
2：完全な順序付け

【0134】

いくつかの例示的な実装形態では、他の値が予約されてもよい。segment＿orderが存在しない場合、その値は0に等しいと推測される。

【0135】

いくつかの例示的な実装形態では、事前選択の再生に寄与するすべてのトラックが同じファイルで配信されるとは限らない。

【0136】

いくつかの例示的な実装形態では、上述のように、種類ボックスは、事前選択の特性を記述するために一般に使用される方式を提供するので、ISO／IEC 23009－1：2022の5．8．5．5項で定義される役割方式を利用してもよい。

【0137】

いくつかの例示的な実装形態では、事前選択トラックグループエントリボックスは、参照トラック内の事前選択の初期体験に関する情報を担持してもよい。事前選択体験は、これらのトラックの再生中に変化する可能性があり、例えば、音声言語が再生中に変化する可能性がある。これらの変化は、事前選択トラックグループエントリボックス内に表示される情報の影響を受けない。

【0138】

いくつかの例示的な実装形態では、事前選択の特性を記述するために、さらなるメディアタイプ固有のボックスが使用されてもよい。読者は、認識されないボックスを無視してスキップしてもよい。

【0139】

いくつかの例示的な実装形態では、上述のように、Kind Boxは、ピクチャインピクチャ体験をシグナリングするために使用されてもよく、メインピクチャの1つ以上のエリアは、DASH Role schemeIdURIおよび値「pip」を使用して1つ以上の代替ピクチャでオーバーレイされ得る。

【0140】

事前選択トラックグループエントリボックス設計：利点
上記の事前選択トラックグループエントリボックスの上記のこの設計は、いくつかの利点を提供し得る。
・ PiPシグナリングのために既存の事前選択トラックグループボックスを使用する。
・ PiPの複数のグループがトラックを共有することを可能にする。
・ PiP体験において2つ以上の代替ピクチャを可能にする。
・ いくつかのトラックからなるメインピクチャを可能にする。
・ PiPにおけるすべてのトラックの単一のデコードのためにメインピクチャサブピクチャ／領域と代替ストリームとの置き換えを可能にする。

【0141】

ストリーミングマニフェストにおける例示的なPiPシグナリング
上述のように、PiP体験における様々なメディアコンテンツの可能な役割および関係を指定するためにメディアコンテナファイルに様々なシグナリング情報を含めることに加えて、このようなシグナリングは、ストリーミングクライアントに様々なPiPの可能性を示すために、ストリーミングアプリケーションのためのマニフェスト（例えば、DASH MPD）にも含まれ得る。するとストリーミングクライアントは、マニフェストを解析し、コンテンツサーバへのメディア要求を適応的に構築することによって、PiP体験をいつどのように使用および提供するかを決定することができる。ストリーミングマニフェスト内のこのようなPiPシグナリングは、例えば、上述のように、ストリーミングメディアに関連付けられた基礎となるメディアコンテナファイル内のPiPシグナリングから導出され得る。一般に、コンテナファイルなどのメディアファイルおよびメディアに関連付けられたマニフェストは、生成時に調和され得る。

【0142】

いくつかの例示的な実装形態では、PiP体験は、既存の役割方式を介して追加の役割として提供されてもよい。このような役割は、様々なレベルでストリーミングマニフェストとしてシグナリングされ得る。例えば、このような役割は、適応セットレベルでシグナリングされてもよい。

【0143】

例示的な一実装形態では、urn：mpeg：dash：role：2011で指定されたDASH Role方式の例示的な値は、マニフェスト内のPiPシグナリングをサポートするために、以下の値を含み得る。

【0144】

【表1A】

【表1B】

【0145】

値「PIP－main」および「PIP－sub」は、ストリーミングマニフェスト（例えば、DASH MPD）におけるPiP関連情報のシグナリングのために特に含まれる。したがって、適応レベルにおいて、MPD内の適応セットのための「PIP－main」として指定されたRole＠valueは、ストリーミングクライアントに、対応する適応セットがPiP体験のメインピクチャを提供する際のPiP体験の一部であり得ることをシグナリングするが、MPD内の適応セットのための「PIP－sub」として指定されたRole＠valueは、ストリーミングクライアントに、対応する適応セットがPiP体験におけるメインピクチャの代替ピクチャを提供する際のPiP体験の一部であり得ることをシグナリングする。

【0146】

例えば、役割方式におけるこのような役割値は、PIPコンテンツおよびそれらの構成をシグナリングするためのストリーミングマニフェスト内のピクチャピクチャ記述子に含まれてもよい。このようなPiP記述子は、様々なレベルで指定され得る。例えば、このようなPiP記述子は、ストリーミングマニフェスト内の適応セットレベルで指定されてもよい。

【0147】

例えば、適応セット内のSupplementalProperty要素は、PiP値を含む上記の役割方式を指定する事前定義されたurnに等しい＠schemeIdUri属性を含んでもよい。

【0148】

例示的な適応セットレベルでは、同じ記述子およびSupplementalProperty記述子について同一の＠idでシグナリングされた適応セットは、1つのPiP体験で使用されるように意図されていると見なされる。上述のように、PiP体験は、1つ以上のメインプレゼンテーションからなってもよい。各メインプレゼンテーションの任意の適応セットは、＠value＝’pip－main’を有する役割記述子で注釈を付けられてもよい。PiP体験はまた、1つ以上の代替プレゼンテーションを含んでもよく、そのうちの1つ以上が、メインプレゼンテーションのうちの1つの上にオーバーレイされ得る。各代替プレゼンテーションの任意の適応セットは、SupplementalProperty記述子内の＠value＝’pip－sub’を有する役割記述子で注釈を付けられてもよい。

【0149】

いくつかの例示的な実装形態では、適応セットは、2つ以上のPiP体験を表現するために異なる＠idを有する2つ以上のPiP記述子を含み得る。言い換えると、適応セットは、異なる＠id値を有する適応セット内の異なるPiP記述子によって識別される複数の異なるPiP体験の一部であり得る。同じ適応セットは、複数のPiP体験のうちのいくつかにおけるメインピクチャ（したがって対応する＠id値の記述子について「pip－main」の＠valueを有する）であってもよいが、複数のPiP体験のうちのいくつかの他のものにおけるサブピクチャ（したがって「pip－sub」の＠valueを有する）であってもよい。

【0150】

具体的には、例示的なマニフェストメインは、以下を含む。
AdaptationSet｛
AdaptationSet－id＝1
SupplementalProperty｛
＠id＝1
＠value＝"pip－main"
．．．
｝
SupplementalProperty｛
＠id＝2
＠value＝"pip－main"
．．．
｝
SupplementalProperty｛
＠id＝3
＠value＝"pip－sub"
．．．
｝
｝
AdaptationSet｛
AdaptationSet－id＝2
SupplementalProperty｛
＠id＝1
＠value＝"pip－sub"
．．．
｝
SupplementalProperty｛
＠id＝3
＠value＝"pip－main"
．．．
｝
｝
AdaptationSet｛
AdaptationSet－id＝3
SupplementalProperty｛
＠id＝1
＠value＝"pip－sub"
．．．
｝
SupplementalProperty｛
＠id＝2
＠value＝"pip－sub"
．．．
｝
｝

【0151】

この例では、各々がPiP体験を表す3つのSupplementalProperty ID：1、2、および3がある。1のSupplementalProperty IDを有する最初のPiP体験では、適応セット1がメインピクチャであるのに対して、適応セット2および3はサブピクチャである。2のSupplementalProperty IDを有する2回目のPiP体験では、適応セット1がメインピクチャであるのに対して、適応セット3はサブピクチャである。3のSupplementalProperty IDを有する3回目のPiP体験では、適応セット2がメインピクチャであるのに対して、適応セット1はサブピクチャである。

【0152】

上記の記述子は、適応セットレベル以外のレベルで使用されてもよい。これらの記述子は、様々な適応セットの任意の組み合わせをPiP体験内にシグナリングする柔軟な方法を提供する。適応セットは複数のPIP体験で使用されることが可能であり、これらはメインピクチャまたはサブピクチャであり得る。各PiP体験は、メイン適応セットおよび1つ以上のサブ適応セットを有し得る。PiP体験は、SupplementalProperty記述子の＠idによって識別される。

【0153】

いくつかのさらなる例示的な実装形態では、「ContentComponent」要素は、メインピクチャの一部と置き換わるために、コーディングされたストリームの様々なサブピクチャの特性を記述するために定義および使用されてもよい。

【0154】

具体的には、PiPメインプレゼンテーションの適応セットは、1つ以上のPIP代替プレゼンテーションに置き換わるように意図されるコーディングされたメインプレゼンテーションのコンテンツコンポーネント部分を識別するために、1つのContentComponent要素を使用し得る。したがって、ContentComponent＠tagは、置換プロセスのためのデコーダ用の情報を含み得る。例えば、ContentComponentは、ビデオデコーダに送信する前に、PiPビデオの対応するコーディングされたビデオデータユニットと置き換わるメインビデオ内の目標PiP領域を表すコーディングされたビデオデータユニットを示してもよい。このようにして、PiPのコーディングされたストリームは、メインビデオおよびPiPビデオの単一のデコーディングおよび別々のデコーディングが回避され得る前にマージされることが可能である。メインビデオ内の特定のピクチャでは、PiPビデオの対応するビデオデータユニットは、補足ビデオ表現におけるデコーディング時間同期サンプル内のすべてのコーディングされたビデオデータユニットであり得る。いくつかの例示的な実装形態では、ContentComponent＠tagのフォーマットおよび意味論は、対応するコーディングされたビデオ仕様によって定義されてもよい。

【0155】

特定の例示的なコーディングされたビデオ仕様では、PiPのためのサブピクチャは、サブピクチャidで識別され得る。ContentComponent＠tagのための以下の例示的な構文が使用され得る。
subpic1 subpic2 …．
ここで、Subpic 1、subpic 2．．．は、コーディングされたビデオビットストリームの領域の空白で区切ったサブピクチャidであり、各々が1つのサブピクチャを定義し、グループがピクチャインピクチャオーバーレイに使用され得る全体的な領域を定義する。

【0156】

いくつかの例示的な実装形態では、ContentComponent＠idは、このコンテンツコンポーネントの領域idを識別するために使用されてもよく、上述のようなコンテナファイルフォーマットなどの他の方式で識別された領域idと等しく設定されてもよい。

【0157】

ContentComponentの様々な例示的なフィールドが、以下の表2に示されている。

【0158】

【表2】

【0159】

上記の例示的なConentComponent要素は、適応セットまたは表現において指定されることが可能であり、そのサブピクチャに注釈を付ける。ストリーミングクライアント（例えば、DASHクライアント）は、デコーディングの前に所望のサブピクチャストリームをピクチャインピクチャビデオストリームで置き換え、次いで操作されたビットストリームを適切なデコーダに供給するために、ビットストリームマニピュレータに注釈を提供することができる。

【0160】

図6は、メディアコンテナファイル内のPiPシグナリングのための例示的なデータおよび論理フロー600を示す。ステップ602において、ISOベースメディアファイルフォーマット（ISOBMFF）で構築されたメディアコンテナファイルが受信される。メディアコンテナファイルは、PiPモードで表されるメインメディアトラックおよび少なくとも1つのサブメディアトラックを含む。ステップ604において、メディアコンテナファイルは解析され、メディアトラックグループ定義のための事前選択トラックグループエントリ（Prse）ボックス構文要素を介してピクチャインピクチャ（PiP）体験のためのメディアトラックグループを識別する。ステップ606において、メディアコンテナファイルはさらに解析され、メディアコンテナファイル内の複数のメディアトラック定義内の事前選択グループ（Pres）ボックス構文要素を介してメディアトラックグループに属するメインメディアトラックおよび少なくとも1つのサブメディアトラックを識別する。ステップ608において、メディアコンテナファイルはさらに解析され、メインメディアトラックまたは少なくとも1つのサブメディアトラックのPresボックス要素のコンポーネント内のサンプルフラグマージ構文要素の構文要素の存在または値に応じてデコードされる前にサブメディアトラックのコーディングされたデータユニットがメインメディアトラックのコーディングされたデータユニットとマージされるか否かを示すマージモードを決定する。ステップ610において、メインメディアトラックおよび少なくとも1つのサブメディアトラックは、マージングモードに従ってPiPモードでデコードされる。

【0161】

図7は、ストリーミングメディアマニフェスト内のPiPシグナリングのための他の例示的なデータおよび論理フロー700を示す。ステップ702において、ストリーミングサーバからのストリーミングメディアマニフェストが受信される。ステップ704において、ストリーミングメディアマニフェストは解析され、ストリーミングメディアコンテンツのセットに関連付けられたPiPシグナリング情報項目のセットを識別する。ステップ706において、PiPシグナリング情報項目に従って、ストリーミングメディアコンテンツのセットのために適応的な要求が構築される。ステップ708において、ストリーミングメディアコンテンツのセットが受信される。ステップ710において、ストリーミングメディアコンテンツのセットは、PiPシグナリング情報項目に従ってデコードおよび表示される。

【0162】

上述された技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つ以上のコンピュータ可読媒体に物理的に記憶されることが可能である。例えば、図8は、開示されている主題の特定の実施形態を実施するのに適したコンピュータシステム（800）を示す。

【0163】

コンピュータソフトウェアは、アセンブリ、コンパイル、リンクなどのメカニズムを受けることができる任意の適切な機械コードまたはコンピュータ言語を使用してコーディングされ、1つ以上のコンピュータ中央処理装置（CPU）、グラフィックス処理装置（GPU）などによって直接、または解釈、マイクロコード実行などを介して、実行されることができる命令を含むコードを作成することができる。

【0164】

命令は、例えばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーミングデバイス、およびモノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはそのコンポーネント上で実行されることが可能である。

【0165】

コンピュータシステム（800）に関して図8に示されているコンポーネントは、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関する限定を示唆することを意図するものではない。また、コンポーネントの構成は、コンピュータシステム（800）の例示的な実施形態に示されている構成要素のいずれか1つまたは組み合わせに関する依存性または要件を有するものとして解釈されるべきではない。

【0166】

コンピュータシステム（800）は、特定のヒューマンインターフェース入力デバイスを含んでもよい。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（音声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）を介して、1人以上の人間のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスは、オーディオ（例えば、音声、音楽、周囲音）、画像（例えば、走査画像、写真画像は静止画像カメラから取得する）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアを取り込むために使用することもできる。

【0167】

入力ヒューマンインターフェースデバイスは、キーボード（801）、マウス（802）、トラックパッド（803）、タッチスクリーン（810）、データグローブ（図示せず）、ジョイスティック（805）、マイクロフォン（806）、スキャナ（807）、カメラ（808）の1つ以上（各々の1つのみが図示されている）を含んでもよい。

【0168】

コンピュータシステム（800）はまた、特定のヒューマンインターフェース出力デバイスを含んでもよい。このようなヒューマンインターフェース出力デバイスは、例えば触覚出力、音、光、および匂い／味を介して1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（810）、データグローブ（図示せず）、またはジョイスティック（805）による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る）、音声出力デバイス（例えば、スピーカ（809）、ヘッドホン（図示せず））、視覚出力デバイス（例えば、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン（810）、それぞれがタッチスクリーン入力機能を有するかまたは有さず、それぞれが触覚フィードバック機能を有するかまたは有さず、その一部は、ステレオ出力などの手段を介して2次元視覚出力または3次元以上の出力を出力可能であってもよい）、仮想現実眼鏡（図示せず）、ホログラフィックディスプレイ、および発煙タンク（図示せず））、およびプリンタ（図示せず）を含んでもよい。

【0169】

コンピュータシステム（800）はまた、人間がアクセス可能な記憶デバイスおよびそれらの関連媒体、例えば、CD／DVDなどの媒体（821）を含むCD／DVD ROM／RW（820）を含む光学媒体、サムドライブ（822）、リムーバブルハードドライブまたはソリッドステートドライブ（823）、テープおよびフロッピーディスク（図示せず）などの旧来の磁気媒体、セキュリティドングル（図示せず）などの専用ROM／ASIC／PLDベースのデバイスなどを含むことができる。

【0170】

当業者はまた、本開示の主題に関連して使用される「コンピュータ可読媒体」という用語が、送信媒体、搬送波または他の一時的信号を包含しないことを理解すべきである。

【0171】

コンピュータシステム（800）はまた、1つ以上の通信ネットワーク（855）へのインターフェース（854）を含むことができる。ネットワークは例えば、無線ネットワーク、有線ネットワーク、光学ネットワークであり得る。ネットワークはさらに、ローカル、ワイドエリア、メトロポリタン、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネットなどのローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラネットワーク、ケーブルテレビ、衛星テレビおよび地上波テレビを含むテレビの有線または無線広域デジタルネットワーク、CAN busを含む車両用および産業用などを含む。特定のネットワークは一般に、特定の汎用データポートまたは周辺バス（849）（例えば、コンピュータシステム（800）のUSBポートなど）に取り付けられた外部ネットワークインタフェースアダプタを必要とし、他のものは一般に、以下に説明するようなシステムバスへの取り付けによってコンピュータシステム（800）のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインタフェースまたはスマートフォンコンピュータシステムへのセルラネットワークインタフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム（800）は、他のエンティティと通信することができる。例えばローカルまたは広域のデジタルネットワークを使用する他のコンピュータシステムに対して、このような通信は、単方向、受信のみ（例えば、テレビ放送）、単方向送信のみ（例えば、特定のCANbusデバイスへのCANbus）、または双方向であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースの各々で使用され得る。

【0172】

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム（800）のコア（840）に取り付けられることが可能である。

【0173】

コア（840）は、1つ以上の中央処理装置（CPU）（841）、グラフィックス処理装置（GPU）（842）、フィールドプログラマブルゲートエリア（FPGA）（843）の形態をとる特化型プログラム可能処理装置、特定のタスク用のハードウェアアクセラレータ（844）、グラフィックアダプタ（850）などを含むことができる。これらのデバイスは、読み取り専用メモリ（ROM）（845）、ランダムアクセスメモリ（846）、ユーザがアクセス不可能な内部ハードドライブ、SSDなどの内部大容量ストレージ（847）などと共に、システムバス（848）を介して接続されてもよい。いくつかのコンピュータシステムでは、システムバス（848）を1つ以上の物理プラグの形態でアクセス可能として、追加のCPU、GPUなどによる拡張を可能にすることができる。周辺デバイスは、コアのシステムバス（848）に直接取り付けられるか、または周辺バス（849）を介して取り付けられることも可能である。一例では、スクリーン（810）は、グラフィックアダプタ（850）に接続されることが可能である。周辺バス用のアーキテクチャは、PCI、USBなどを含む。

【0174】

CPU（841）、GPU（842）、FPGA（843）およびアクセラレータ（844）は、組み合わせて前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ROM（845）またはRAM（846）に記憶されることが可能である。一時データもまたRAM（846）に記憶され得るが、永久データは、例えば内部大容量ストレージ（847）に記憶され得る。1つ以上のCPU（841）、GPU（842）、大容量ストレージ（847）、ROM（845）、RAM（846）などと密接に関連付けられ得るキャッシュメモリの使用によって、メモリデバイスのいずれかへの高速記憶および検索が可能になり得る。

【0175】

コンピュータ可読媒体は、様々なコンピュータ実装動作を行うためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得、またはコンピュータソフトウェア技術の当業者に周知の利用可能な種類のものであり得る。

【0176】

非限定的な例として、アーキテクチャ、具体的にはコア（840）を有するコンピュータシステム（800）は、プロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）が1つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行する結果として、機能を提供することができる。このようなコンピュータ可読媒体は、上述のようなユーザがアクセス可能な大容量ストレージ、およびコア内部大容量ストレージ（847）またはROM（845）などの非一時的な性質のコア（840）の特定のストレージに関連付けられた媒体であってもよい。本開示の様々な実施形態を実施するソフトウェアは、このようなデバイスに記憶され、コア（840）によって実行され得る。特定の必要性に応じて、コンピュータ可読媒体は、1つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア（840）、および具体的にはその中の（CPU、GPU、FPGAなどを含む）プロセッサに、RAM（846）に記憶されたデータ構造を定義すること、およびソフトウェアによって定義されたプロセスに従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。これに加えて、またはこれの代わりとして、コンピュータシステムは、本明細書で説明する特定のプロセスまたは特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアと一緒に動作し得る回路（例えば、アクセラレータ（844））における、配線された、または他の方法で具現化されたロジックの結果として、機能を提供し得る。ソフトウェアへの言及は、必要に応じて、論理を包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。

【0177】

本開示はいくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換、および様々な代替の均等物が存在する。したがって、当業者は、本明細書に明示的に図示または記載されていないが、本開示の原理を具現化し、したがって本開示の趣旨および範囲内にある多数のシステムおよび方法を考案することができることが理解されよう。

【符号の説明】

【0178】

100 コンテンツ配信システム
110 コンテンツサーバ
120 リモート情報処理装置
130 通信ネットワーク
200 DASHシステム
210 コンテンツサーバ
212 HTTPサーバ
214 MPD生成器
220 広告サーバ
230 情報処理装置
232 DASHクライアント
234 DASHアプリケーション
236 表示デバイス
250 ネットワーク
302 選択ロジック
304 DASHアクセスエンジン
306 メディアエンジン
308 メディアエンジン
800 コンピュータシステム
801 キーボード
802 マウス
803 トラックパッド
805 ジョイスティック
806 マイクロフォン
807 スキャナ
808 カメラ
809 スピーカ
810 スクリーン
820 CD／DVD ROM／RW
821 CD／DVDなどの媒体
822 サムドライブ
823 リムーバブルハードドライブまたはソリッドステートドライブ
840 コア
841 中央処理装置（CPU）
842 グラフィックス処理装置（GPU）
843 フィールドプログラマブルゲートエリア（FPGA）
844 ハードウェアアクセラレータ
845 読み取り専用メモリ（ROM）
846 ランダムアクセスメモリ
847 内部大容量ストレージ
848 システムバス
849 周辺バス
850 グラフィックアダプタ
854 インターフェース
855 通信ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【手続補正書】

【提出日】2024-08-07

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

メディア処理デバイスが実行するピクチャインピクチャ(PiP)情報を取得する方法であって、
ISOベースメディアファイルフォーマット（ISOBMFF）で構築されたメディアコンテナファイルを取得するステップであって、前記メディアコンテナファイルは、PiPモードで表されるメインメディアトラックおよび少なくとも1つのサブメディアトラックを含む、ステップと、
前記メディアコンテナファイルを解析し、メディアトラックグループ定義のための事前選択トラックグループエントリ（Prse）ボックス構文要素を介してPiP体験のためのメディアトラックグループを識別するステップと、
前記メディアコンテナファイルを解析し、前記メディアコンテナファイル内の複数のメディアトラック定義内の事前選択グループ（Pres）ボックス構文要素を介して前記メディアトラックグループに属する前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックを識別するステップと、
前記メディアコンテナファイルを解析し、前記少なくとも1つのサブメディアトラックのコーディングされたデータユニットが、前記メインメディアトラックまたは前記少なくとも1つのサブメディアトラックの前記Presボックス構文要素のコンポーネント内のサンプルフラグマージ構文要素の存在または値に応じてデコードされる前に前記メインメディアトラックのコーディングされたデータユニットとマージされるか否かを示すマージモードを決定するステップと、
前記マージモードに従って前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップと
を含む、方法。

【請求項2】

前記Prseボックス構文要素は、メディアトラックグループを定義するように構成された前記メディアコンテナファイル内の第1の事前定義されたタイプの構文要素に属する、請求項1に記載の方法。

【請求項3】

前記第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプタグ要素を各々含み、
前記メディアトラックグループタイプタグ要素は、事前定義された目的キーワードのセットを使用して、前記PiP体験を含む、対応するメディアトラックグループの意図される体験を示す、
請求項2に記載の方法。

【請求項4】

前記第1の事前定義されたタイプの構文要素は、メディアトラックグループタイプ記述子を各々含み、
前記メディアトラックグループタイプ記述子は、事前定義された役割を有する役割方式を使用して、前記PiP体験を含む、対応するメディアトラックグループの意図される体験を指定するように構成される、
請求項2に記載の方法。

【請求項5】

前記メディアコンテナファイル内の前記第1の事前定義されたタイプの構文要素の各々は、対応するメディアトラックグループのいくつかのトラックを含む、請求項2に記載の方法。

【請求項6】

前記Presボックス構文要素は、対応するメディアトラックグループ識別子を使用してメディアトラックグループとのメディアトラックの関連付けを指定するように構成された前記メディアトラックの定義内の第2の事前定義されたタイプの構文要素に属する、請求項1に記載の方法。

【請求項7】

前記第2の事前定義されたタイプの構文要素の各々は、前記メディアトラックグループに対する前記メディアトラックのPiP処理を指定するためのメディアトラックグループ処理記述子（prsp）を含む、請求項6に記載の方法。

【請求項8】

前記メディアトラックグループ処理記述子は、前記メディアトラックグループ内の他のメディアトラックに対する前記メディアトラックの優先順位を示すための優先度パラメータを含む、請求項7に記載の方法。

【請求項9】

前記PiP体験の前記メインメディアトラックの前記優先度パラメータは、PiP処理のための最も高い優先度の値を含む、請求項8に記載の方法。

【請求項10】

前記PiP体験の前記少なくとも1つのサブメディアトラックの前記優先度パラメータは、PiP処理のための最も低い優先度の値を含む、請求項9に記載の方法。

【請求項11】

前記サンプルフラグマージ構文要素は、メインメディアトラックに関連付けられた前記メディアトラックグループ処理記述子に相応に含まれる第3の事前定義されたタイプの構文要素に属する、請求項8に記載の方法。

【請求項12】

事前定義された値を有する前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素は、前記メインメディアトラックがデコードされる前に前記サブメディアトラックとマージ可能であることを示す、請求項11に記載の方法。

【請求項13】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値であるとき、前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップは、単一のデコーディングのために前記メインメディアトラックの前記コーディングされたデータユニットおよび前記少なくとも1つのサブメディアトラックの前記コーディングされたデータユニットをマージするステップを含む、請求項12に記載の方法。

【請求項14】

前記メディアトラックグループ処理記述子は、対応するメディアトラックのコーディングされたストリーム内の、デコーディングの前に他のメディアトラックのコーディングされたストリームとマージされる領域のリストを示すための領域識別パラメータを含む、請求項12に記載の方法。

【請求項15】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値であるとき、前記メインメディアトラックに関連付けられた前記領域識別パラメータは非NULLである、請求項14に記載の方法。

【請求項16】

前記メディアトラックの前記優先順位が最も高くないとき、前記メディアトラックのための前記領域識別パラメータは、存在したとしても無視される、請求項14に記載の方法。

【請求項17】

前記メディアトラックのための前記領域識別パラメータが非NULLであるとき、前記メディアトラックの前記優先順位はこれに対応して最も高い、請求項14に記載の方法。

【請求項18】

前記メインメディアトラックに関連付けられた前記第3の事前定義されたタイプの構文要素が前記事前定義された値ではないとき、前記PiPモードで前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックをデコードするステップは、別々の独立したデコーディングによって前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックを処理するステップを含む、請求項12に記載の方法。

【請求項19】

前記メインメディアトラックおよび前記少なくとも1つのサブメディアトラックのいずれかは、前記メディアコンテナファイル内の他のPrseボックス構文要素によって示されるように、他のメディアトラックグループに属する、請求項1に記載の方法。

【請求項20】

請求項１～19のいずれか一項に記載の方法を実施する、メディア処理デバイス。

【請求項21】

コンピュータに、請求項1～19のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【国際調査報告】