特表 2024-511948 ＨＥＩＦフォーマットされた画像をリアルタイムトランスポートプロトコル上でトランスポートすること

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

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

(11)【公表番号】

(43)【公表日】2024-03-18

(54)【発明の名称】ＨＥＩＦフォーマットされた画像をリアルタイムトランスポートプロトコル上でトランスポートすること

(51)【国際特許分類】

   H04N 21/434 20110101AFI20240311BHJP

   H04N 21/431 20110101ALI20240311BHJP

【ＦＩ】

H04N21/434

H04N21/431

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023555648

(86)(22)【出願日】2022-03-24

(85)【翻訳文提出日】2023-09-11

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

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

(87)【国際公開日】2022-10-06

(31)【優先権主張番号】63/168,157

(32)【優先日】2021-03-30

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

(31)【優先権主張番号】17/656,159

(32)【優先日】2022-03-23

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】ブアジジ、イメド

(72)【発明者】

【氏名】リョン、ニコライ・コンラド

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

5C164

【Ｆターム（参考）】

5C164MA04S

5C164MB13S

5C164SB15S

5C164UB11P

5C164UB38S

5C164UB81P

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

前記シーン画像と前記オーバーレイ画像とを提示するために、前記１つまたは複数のプロセッサは、前記データが、前記オーバーレイ画像が前記ループで繰り返し提示されるべきであることを示すとき、
前記オーバーレイ画像が画像シーケンス中にＮ個の画像を含むと決定することと、Ｎが正の整数である、
ｊが非負整数である、ループ数ｊについて、時間ｊ＊Ｎ＋ｉにおいて前記オーバーレイ画像の前記画像シーケンスの画像ｉを提示することと、ｉが前記オーバーレイ画像の前記画像シーケンスのｉ番目の画像に対応する、
を行うように構成された、請求項３０に記載のデバイス。

【請求項32】

前記ＳＤＰ画像属性は、前記オーバーレイ画像が受信の後にローカルに記憶されるべきであるかどうかを示すデータを含む、請求項２５に記載のデバイス。

【請求項33】

前記１つまたは複数のプロセッサは、前記データが、前記オーバーレイ画像が受信の後にローカルに記憶されるべきであることを示すとき、前記オーバーレイ画像を前記メモリに記憶することを行うようにさらに構成され、ここにおいて、前記シーン画像と前記オーバーレイ画像とを提示するために、前記１つまたは複数のプロセッサが、
前記メモリから前記オーバーレイ画像を取り出すことと、
前記取り出されたオーバーレイ画像を提示することと
を行うように構成された、請求項３２に記載のデバイス。

【請求項34】

前記シーン画像と前記オーバーレイ画像とを提示するために、前記１つまたは複数のプロセッサは、前記データが、前記オーバーレイ画像が再送信されることになることを示すとき、
前記オーバーレイ画像の再送信されたバージョンを受信することと、
前記オーバーレイ画像の前記再送信されたバージョンを提示することと
を行うように構成された、請求項３２に記載のデバイス。

【請求項35】

命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、プロセッサに、
ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、前記ビットストリームのためのデータを受信することと、前記オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、前記シーンデータとともに提示されるべき単一の静的画像、または、前記シーンデータの前記フレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、
前記ビットストリームから前記１つまたは複数のオーバーレイ画像を受信することと、
１つまたは複数のシーン画像を含む前記シーンデータを受信することと、
前記シーン画像と前記オーバーレイ画像とを提示することと
を行わせる、コンピュータ可読記憶媒体。

【請求項36】

メディアデータを受信するためのデバイスであって、前記デバイスは、
ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、前記ビットストリームのためのデータを受信するための手段と、前記オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、前記シーンデータとともに提示されるべき単一の静的画像、または、前記シーンデータの前記フレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、
前記ビットストリームから前記１つまたは複数のオーバーレイ画像を受信するための手段と、
１つまたは複数のシーン画像を含むシーンデータを受信するための手段と、
前記シーン画像と前記オーバーレイ画像とを提示するための手段と
を備える、デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

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

【0002】

[0002]本開示は、符号化メディアデータの記憶およびトランスポートに関する。

【背景技術】

【0003】

[0003]デジタルビデオ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲のデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するための、ＭＰＥＧ－２、ＭＰＥＧ－４、ＩＴＵ－Ｔ Ｈ．２６３またはＩＴＵ－Ｔ Ｈ．２６４／ＭＰＥＧ－４，Ｐａｒｔ１０，アドバンストビデオコーディング（ＡＶＣ）、（高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれる）ＩＴＵ－Ｔ Ｈ．２６５によって定義された規格、およびそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。

【0004】

[0004]ビデオデータなど、メディアデータが符号化された後に、メディアデータは送信または記憶のためにパケット化され得る。メディアデータは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）、およびＡＶＣなどのそれの拡張など、様々な規格のいずれかに準拠するメディアファイルにアセンブルされ得る。

【発明の概要】

【0005】

[0005]概して、本開示は、オーバーレイのためのソースとしての画像のトランスポートおよび提示をサポートするための技法について説明する。オーバーレイ、またはオーバーレイ画像が、概して、動的ビデオコンテンツ上で提示される静的画像（static image）に対応する。すなわち、静的画像オーバーレイは、フレームごとに変化し得る動的ビデオコンテンツ上で提示されるとき、変化なしのままである。代替的に、一連の画像が、たとえば、ループの形態で、オーバーレイとして提示され得る。そのような場合、オーバーレイ画像シーケンスは、たとえば、オーバーレイ画像シーケンス中に含まれる画像の数に従って、規則的周期性で繰り返し得る。オーバーレイがシーン中の多種多様なコンテンツを重畳するために使用され得るので、オーバーレイは没入型遠隔会議の重要な態様である。たとえば、オーバーレイは、スライド、ロゴ、および／または情報スクリーンをシーンに重畳することを可能にし得る。オーバーレイテクスチャは、ビデオストリーム、１つまたは複数の静止画像（still image）、または画像のシーケンスからのものであり得る。リモート端末のための没入型遠隔会議およびテレプレゼンス（ＩＴＴ４ＲＴ：Immersive Teleconferencing and Telepresence for Remote Terminals）グループは、オーバーレイのためのソースとしての画像をサポートすることに取り組んでいる。本開示は、画像オーバーレイを含むためのフォーマットとしての高効率画像ファイル（ＨＥＩＦ）フォーマットの使用について説明する。

【0006】

[0006]一例では、メディアデータを取り出す方法は、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを含む。

【0007】

[0007]別の例では、メディアデータを取り出すためのデバイスが、シーンデータと画像データとを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行うように構成される。

【0008】

[0008]別の例では、命令を記憶したコンピュータ可読記憶媒体であって、命令は、実行されたとき、プロセッサに、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行わせる、コンピュータ可読記憶媒体。

【0009】

[0009]別の例では、メディアデータを受信するためのデバイスは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信するための手段と、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信するための手段と、１つまたは複数のシーン画像を含むシーンデータを受信するための手段と、シーン画像とオーバーレイ画像とを提示するための手段とを含む。

【0010】

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

【図面の簡単な説明】

【0011】

【図1】[0011]ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図。

【図2】[0012]図１の取出しユニット５２の構成要素の例示的なセットをより詳細に示すブロック図。

【図3】[0013]例示的なマルチメディアコンテンツの要素を示す概念図。

【図4】[0014]表現のセグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図。

【図5】[0015]画像データを含むための高効率画像ファイル（ＨＥＩＦ）フォーマットの例示的な構造を示す概念図。

【図6】[0016]本開示の技法による、メディアデータを取り出す例示的な方法を示すフローチャート。

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

【0012】

[0017]概して、本開示は、画像オーバーレイを含むために、高効率画像ファイル（ＨＥＩＦ）フォーマットなど、特定のフォーマットを使用するための技法について説明する。オーバーレイ、またはオーバーレイ画像が、概して、動的ビデオコンテンツ上で提示される静的画像に対応する。すなわち、静的画像オーバーレイは、フレームごとに変化し得る動的ビデオコンテンツ上で提示されるとき、変化なしのままである。代替的に、一連の画像が、たとえば、ループの形態で、オーバーレイとして提示され得る。そのような場合、オーバーレイ画像シーケンスは、たとえば、オーバーレイ画像シーケンス中に含まれる画像の数に従って、規則的周期性で繰り返し得る。たとえば、オーバーレイ画像シーケンスがＮ個の画像を含む場合、画像シーケンス中のｉ番目の画像は、ｊ＊Ｎ＋ｉ個のフレームごとに提示されることになり、ここで、ｊは０から無限大にわたることができ、ｉは０からＮ－１にわたることができる。ＨＥＩＦフォーマットは、ＩＳＯ／ＩＥＣ２３００８－１２において定義されている。ＩＳＯ／ＩＥＣ２３００８－１２は、ＩＳＯＢＭＦＦベースコンテナファイルへの画像および画像シーケンスならびにそれらのメタデータの記憶を指定する。ＨＥＩＦは、画像の記憶のための一般的な、コーデックアグノスティック構造を定義し、また、Ｈ．２６５／ＨＥＶＣ（高効率ビデオコーディング）コーデックに基づくインスタンス化を提供する。

【0013】

[0018]ビデオテレフォニーおよびビデオ会議セッションなど、様々なコンテキストでは、参加者間で画像を共有することが望ましいことがある。しかしながら、リアルタイムトランスポートプロトコル（ＲＴＰ）など、いくつかのビデオストリーミングプロトコルでは、画像の搬送は定義されない。ＨＥＩＦは、たとえば、ＨＥＶＣまたは他のビデオコーデックを使用して符号化された、画像集合および画像シーケンスの記憶を可能にする画像フォーマットである。ＲＴＰ上での画像の搬送は現在指定されていない。本開示は、ＨＥＩＦ画像集合および画像シーケンスをＲＴＰ上で搬送および提示するための技法について説明する。これらの技法は、たとえば、ＨＥＶＣのための、ＲＴＰペイロードフォーマットに対する拡張、ならびにセッション記述プロトコル（ＳＤＰ）における画像のシグナリングについて説明する。このようにして、画像および画像シーケンスが、ビデオ会議セッション中にトランスポートされ得、そのために、データが、ＲＴＰまたは他のそのようなプロトコルを使用してトランスポートされ得る。

【0014】

[0019]本開示の技法は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）、スケーラブルビデオコーディング（ＳＶＣ）ファイルフォーマット、アドバンストビデオコーディング（ＡＶＣ）ファイルフォーマット、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））ファイルフォーマット、および／またはマルチビュービデオコーディング（ＭＶＣ）ファイルフォーマット、あるいは他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたメディアデータに準拠する、ビデオファイルなどのメディアファイルに適用され得る。

【0015】

[0020]図１は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム１０を示すブロック図である。この例では、システム１０は、コンテンツ作成デバイス２０と、サーバデバイス６０と、クライアントデバイス４０とを含む。クライアントデバイス４０とサーバデバイス６０とは、インターネットを備え得るネットワーク７４によって通信可能に結合される。いくつかの例では、コンテンツ作成デバイス２０とサーバデバイス６０とも、ネットワーク７４または別のネットワークによって結合され得るか、あるいは直接通信可能に結合され得る。いくつかの例では、コンテンツ作成デバイス２０とサーバデバイス６０とは同じデバイスを備え得る。

【0016】

[0021]コンテンツ作成デバイス２０は、図１の例では、オーディオソース２２とビデオソース２４とを備える。オーディオソース２２は、たとえば、オーディオエンコーダ２６によって符号化されるべき、キャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオソース２２は、前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化シンセサイザなどのオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース２４は、ビデオエンコーダ２８によって符号化されるべきビデオデータを生成するビデオカメラ、前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ作成デバイス２０は、必ずしもすべての例においてサーバデバイス６０に通信可能に結合されるとは限らないが、サーバデバイス６０によって読み取られる別個の媒体にマルチメディアコンテンツを記憶し得る。

【0017】

[0022]未加工オーディオおよびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオエンコーダ２６および／またはビデオエンコーダ２８によって符号化される前にデジタル化され得る。オーディオソース２２は、通話参加者が話している間、通話参加者からオーディオデータを取得し得、同時に、ビデオソース２４は、通話参加者のビデオデータを取得し得る。他の例では、オーディオソース２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このようにして、本開示で説明される技法は、ライブ、ストリーミング、リアルタイムオーディオおよびビデオデータ、またはアーカイブされた、あらかじめ記録されたオーディオおよびビデオデータに適用され得る。

【0018】

[0023]ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれているビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時に、オーディオソース２２によってキャプチャされた（または生成された）オーディオデータを含んでいるオーディオフレームである。たとえば、通話参加者が概して話すことによってオーディオデータを生成する間、オーディオソース２２はオーディオデータをキャプチャし、同時に、すなわちオーディオソース２２がオーディオデータをキャプチャしている間、ビデオソース２４は通話参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータとビデオデータとが同時にキャプチャされた状況、およびオーディオフレームとビデオフレームとが、それぞれ、同時にキャプチャされたオーディオデータとビデオデータとを備える状況に対応する。

【0019】

[0024]いくつかの例では、オーディオエンコーダ２６は、符号化オーディオフレームについてのオーディオデータが記録された時間を表す、各符号化オーディオフレームにおけるタイムスタンプを符号化し得、同様に、ビデオエンコーダ２８は、符号化ビデオフレームについてのビデオデータが記録された時間を表す、各符号化ビデオフレームにおけるタイムスタンプを符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ作成デバイス２０は、オーディオエンコーダ２６および／またはビデオエンコーダ２８がそこからタイムスタンプを生成し得るか、あるいはオーディオソース２２およびビデオソース２４がオーディオデータとビデオデータとをそれぞれタイムスタンプに関連付けるために使用し得る、内部クロックを含み得る。

【0020】

[0025]いくつかの例では、オーディオソース２２は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ２６に送出し得、ビデオソース２４は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ２８に送出し得る。いくつかの例では、オーディオエンコーダ２６は、必ずしもオーディオデータが記録された絶対時間を示すことなしに、符号化オーディオデータの相対時間的順序を示すために、符号化オーディオデータ中のシーケンス識別子を符号化し得、同様に、ビデオエンコーダ２８も、符号化ビデオデータの相対時間的順序を示すためにシーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、タイムスタンプでマッピングされるか、またはさもなければタイムスタンプと相関させられ得る。

【0021】

[0026]オーディオエンコーダ２６は概して符号化オーディオデータのストリームを生成し、ビデオエンコーダ２８は符号化ビデオデータのストリームを生成する。データの各個々のストリームは（オーディオかビデオかにかかわらず）エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現のデジタル的にコード化された（場合によっては圧縮された）単一の成分である。たとえば、表現のコード化ビデオまたはオーディオ部分はエレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化エレメンタリストリーム（ＰＥＳ）に変換され得る。同じ表現内では、１つのエレメンタリストリームに属するＰＥＳパケットを他のものから区別するためにストリームＩＤが使用され得る。エレメンタリストリームの基本データ単位はパケット化エレメンタリストリーム（ＰＥＳ）パケットである。したがって、コード化ビデオデータは、概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、１つまたは複数のそれぞれのエレメンタリストリームに対応する。

【0022】

[0027]ＩＴＵ－Ｔ Ｈ．２６４／ＡＶＣ、ＩＴＵ－Ｔ Ｈ．２６５／高効率ビデオコーディング（ＨＥＶＣ）、および来るべきＩＴＵ－Ｔ Ｈ．２６６／汎用ビデオコーディング（ＶＶＣ）規格など、多くのビデオコーディング規格は、シンタックスと、セマンティクスと、エラーのないビットストリームのための復号プロセスとを定義し、これらのいずれも、あるプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般に、エンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダについて規格に準拠することを保証するというタスクを与えられる。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、特徴、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびブロック処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはｐｒｏｆｉｌｅ＿ｉｄｃ（プロファイルインジケータ）値でシグナリングされ得るが、レベルはｌｅｖｅｌ＿ｉｄｃ（レベルインジケータ）値でシグナリングされ得る。

【0023】

[0028]Ｈ．２６４規格は、たとえば、所与のプロファイルのシンタックスによって課される限界内で、復号ピクチャの指定されたサイズなど、ビットストリーム中のシンタックス要素によってとられる値に応じて、エンコーダおよびデコーダのパフォーマンスの大きい変動を必要とする可能性が依然としてあることを認識している。Ｈ．２６４規格は、多くの適用例において、特定のプロファイル内でシンタックスのすべての仮定的使用に対処することが可能なデコーダを実装することが実際的でもなく、経済的でもないことをさらに認識している。したがって、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に課された制約の指定されたセットとして「レベル」を定義する。これらの制約は、値に関する単純な制限であり得る。代替的に、これらの制約は、値の演算の組合せ（たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数）に関する制約の形態をとり得る。Ｈ．２６４規格は、個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートし得ることをさらに規定する。

【0024】

[0029]プロファイルに準拠するデコーダは、通常、プロファイル中で定義されたすべての特徴をサポートする。たとえば、コーディング特徴として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイルではサポートされないが、Ｈ．２６４／ＡＶＣの他のプロファイルではサポートされる。レベルに準拠するデコーダは、レベルにおいて定義された制限を超えてリソースを必要としない任意のビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、説明可能性のために役立ち得る。たとえば、ビデオ送信中に、プロファイル定義とレベル定義のペアが全送信セッションについてネゴシエートされ、同意され得る。より具体的には、Ｈ．２６４／ＡＶＣでは、レベルは、処理される必要があるマクロブロックの数に関する制限と、復号ピクチャバッファ（ＤＰＢ）サイズと、コード化ピクチャバッファ（ＣＰＢ）サイズと、垂直動きベクトル範囲と、２つの連続するＭＢごとの動きベクトルの最大数と、Ｂブロックが８×８ピクセル未満のサブマクロブロック区分を有することができるかどうかとを定義し得る。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうかを決定し得る。

【0025】

[0030]図１の例では、コンテンツ作成デバイス２０のカプセル化ユニット３０は、ビデオエンコーダ２８からのコード化ビデオデータを備えるエレメンタリストリームと、オーディオエンコーダ２６からのコード化オーディオデータを備えるエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は各々、符号化データからＰＥＳパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は各々、符号化データからＰＥＳパケットを形成するためのそれぞれのパケッタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化オーディオデータと符号化ビデオデータとからＰＥＳパケットを形成するためのパケッタイザを含み得る。

【0026】

[0031]ビデオエンコーダ２８は、様々なビットレートにおいて、ならびにピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格のための様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（たとえば、２次元または３次元再生のための）１つまたは複数のビューを有する表現、あるいは他のそのような特性などの様々な特性を用いてマルチメディアコンテンツの異なる表現を生成するために、様々な方法でマルチメディアコンテンツのビデオデータを符号化し得る。本開示で使用される、表現は、オーディオデータ、ビデオデータ、（たとえば、字幕のための）テキストデータ、または他のそのようなデータのうちの１つを備え得る。表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなど、エレメンタリストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するｓｔｒｅａｍ＿ｉｄを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々な表現のビデオファイル（たとえば、セグメント）にアセンブルすることを担う。

【0027】

[0032]カプセル化ユニット３０は、オーディオエンコーダ２６とビデオエンコーダ２８とから表現のエレメンタリストリームのためのＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを形成する。コード化ビデオセグメントは、ビデオテレフォニー、記憶、ブロードキャスト、またはストリーミングなどのアプリケーションに対処する「ネットワークフレンドリ」なビデオ表現を与える、ＮＡＬユニットに編成され得る。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとに分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含んでいることがあり、ブロック、マクロブロック、および／またはスライスレベルデータを含み得る。他のＮＡＬユニットは非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では、通常は１次コード化ピクチャとして提示される、１つの時間インスタンス中のコード化ピクチャは、１つまたは複数のＮＡＬユニットを含み得るアクセスユニット中に含まれていることがある。

【0028】

[0033]非ＶＣＬ ＮＡＬユニットは、特に、パラメータセットＮＡＬユニットとＳＥＩ ＮＡＬユニットとを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）中の）シーケンスレベルヘッダ情報と、（ピクチャパラメータセット（ＰＰＳ）中の）まれに変化するピクチャレベルヘッダ情報とを含んでいることがある。パラメータセット（たとえば、ＰＰＳおよびＳＰＳ）がある場合、まれに変化する情報がシーケンスごとまたはピクチャごとに繰り返される必要はなく、したがって、コーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし、エラー耐性のための冗長送信の必要を回避し得る。帯域外送信の例では、ＳＥＩ ＮＡＬユニットなど、他のＮＡＬユニットとは異なるチャネル上でパラメータセットＮＡＬユニットが送信され得る。

【0029】

[0034]補足エンハンスメント情報（ＳＥＩ）は、ＶＣＬ ＮＡＬユニットからのコード化ピクチャサンプルを復号するためには必要でないが、復号、表示、エラー耐性、および他の目的に関係するプロセスを支援し得る情報を含んでいることがある。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニット中に含まれていることがある。ＳＥＩメッセージは、一部の規格仕様の規範的部分であり、したがって、規格に準拠するデコーダ実装のために常に必須であるとは限らない。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージまたはピクチャレベルＳＥＩメッセージであり得る。ＳＶＣの例におけるスケーラビリティ情報ＳＥＩメッセージ、およびＭＶＣにおけるビュースケーラビリティ情報ＳＥＩメッセージなどのＳＥＩメッセージ中に、何らかのシーケンスレベル情報が含まれていることがある。これらの例示的なＳＥＩメッセージは、たとえば、動作点の抽出およびそれらの動作点の特性に関する情報を伝達し得る。さらに、カプセル化ユニット３０は、表現の特性を記述するメディアプレゼンテーション記述子（ＭＰＤ）など、マニフェストファイルを形成し得る。カプセル化ユニット３０は、拡張可能マークアップ言語（ＸＭＬ）に従ってＭＰＤをフォーマットし得る。

【0030】

[0035]カプセル化ユニット３０は、マニフェストファイル（たとえば、ＭＰＤ）とともに、マルチメディアコンテンツの１つまたは複数の表現についてのデータを出力インターフェース３２に与え得る。出力インターフェース３２は、ユニバーサルシリアルバス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライターまたはバーナーなど、記憶媒体に書き込むためのネットワークインターフェースまたはインターフェース、磁気またはフラッシュ記憶媒体へのインターフェース、あるいはメディアデータを記憶または送信するための他のインターフェースを備え得る。カプセル化ユニット３０は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース３２に与え得、出力インターフェース３２は、ネットワーク送信または記憶媒体を介してそのデータをサーバデバイス６０に送出し得る。図１の例では、サーバデバイス６０は、各々がそれぞれのマニフェストファイル６６と１つまたは複数の表現６８Ａ～６８Ｎ（表現６８）とを含む、様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含む。いくつかの例では、出力インターフェース３２はまた、データをネットワーク７４に直接送出し得る。

【0031】

[0036]いくつかの例では、表現６８は適応セットに分離され得る。すなわち、表現６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、表現を用いて表示されるべきテキストおよび／または復号され、たとえばスピーカーによって提示されるべきオーディオデータの言語または他の特性を識別し得るテキストタイプ情報、適応セット中の表現のためのシーンのカメラアングルまたは現実世界のカメラパースペクティブを記述し得るカメラアングル情報、特定の視聴者についてのコンテンツ適合性を記述するレーティング情報など、特性のそれぞれの共通セットを含み得る。

【0032】

[0037]マニフェストファイル６６は、特定の適応セットに対応する表現６８のサブセットを示すデータ、ならびに適応セットについての共通の特性を含み得る。マニフェストファイル６６はまた、ビットレートなど、適応セットの個々の表現についての個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にし得る。適応セット中の表現は、マニフェストファイル６６の適応セット要素の子要素を使用して示され得る。

【0033】

[0038]サーバデバイス６０は、要求処理ユニット７０とネットワークインターフェース７２とを含む。いくつかの例では、サーバデバイス６０は複数のネットワークインターフェースを含み得る。さらに、サーバデバイス６０の特徴のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなど、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ６４のデータをキャッシュし、サーバデバイス６０の構成要素に実質的に準拠する構成要素を含み得る。概して、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送出し、受信するように構成される。

【0034】

[0039]要求処理ユニット７０は、クライアントデバイス４０などのクライアントデバイスから、記憶媒体６２のデータについてのネットワーク要求を受信するように構成される。たとえば、要求処理ユニット７０は、Ｒ．Ｆｉｅｌｄｉｎｇらによる、ＲＦＣ２６１６、「Hypertext Transfer Protocol - HTTP/1.1」、ネットワークワーキンググループ、ＩＥＴＦ、１９９９年６月に記載されている、ハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１を実装し得る。すなわち、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴ要求または部分ＧＥＴ要求を受信し、これらの要求に応答してマルチメディアコンテンツ６４のデータを与えるように構成され得る。要求は、たとえば、セグメントのＵＲＬを使用して、表現６８のうちの１つのセグメントを指定し得る。いくつかの例では、要求はまた、セグメントの１つまたは複数のバイト範囲を指定し、したがって部分ＧＥＴ要求を備え得る。要求処理ユニット７０は、表現６８のうちの１つのセグメントのヘッダデータを与えるためのＨＴＴＰ ＨＥＡＤ要求をサービスするようにさらに構成され得る。いずれの場合も、要求処理ユニット７０は、要求されたデータをクライアントデバイス４０などの要求元デバイスに与えるために要求を処理するように構成され得る。

【0035】

[0040]追加または代替として、要求処理ユニット７０は、ｅＭＢＭＳなどのブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ作成デバイス２０は、説明された方法と実質的に同じ方法でＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用して、これらのセグメントまたはサブセグメントを配信し得る。たとえば、要求処理ユニット７０は、クライアントデバイス４０からマルチキャストグループ加入要求を受信するように構成され得る。すなわち、サーバデバイス６０は、マルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ）アドレスを、クライアントデバイス４０を含む、特定のメディアコンテンツ（たとえば、ライブイベントのブロードキャスト）に関連付けられたクライアントデバイスに広告し得る。クライアントデバイス４０は、マルチキャストグループに加入するための要求をサブミットし得る。この要求は、ネットワーク７４、たとえば、ネットワーク７４を構成するルータ全体にわたって伝搬され得、その結果、ルータは、マルチキャストグループに関連付けられたＩＰアドレスに宛てられたトラフィックを、クライアントデバイス４０など、サブスクライブするクライアントデバイスに向けさせられる。

【0036】

[0041]図１の例に示されているように、マルチメディアコンテンツ６４は、メディアプレゼンテーション記述（ＭＰＤ）に対応し得るマニフェストファイル６６を含む。マニフェストファイル６６は、異なる代替表現６８（たとえば、異なる品質をもつビデオサービス）の記述を含んでいることがあり、その記述は、たとえば、表現６８のコーデック情報、プロファイル値、レベル値、ビットレート、および他の記述特性を含み得る。クライアントデバイス４０は、表現６８のセグメントにどのようにアクセスすべきかを決定するためにメディアプレゼンテーション（media presentation）のＭＰＤを取り出し得る。

【0037】

[0042]特に、取出しユニット５２は、ビデオデコーダ４８の復号能力とビデオ出力４４のレンダリング能力とを決定するために、クライアントデバイス４０の構成データ（図示せず）を取り出し得る。構成データはまた、クライアントデバイス４０のユーザによって選択された言語の選好、クライアントデバイス４０のユーザによって設定された深度の選好に対応する１つまたは複数のカメラパースペクティブ、および／またはクライアントデバイス４０のユーザによって選択されたレーティングの選好のうちのいずれかまたはすべてを含み得る。取出しユニット５２は、たとえば、ＨＴＴＰ ＧＥＴ要求と部分ＧＥＴ要求とをサブミットするように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット５２は、クライアントデバイス４０の１つまたは複数のプロセッサまたは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット５２に関して説明される機能のすべてまたは部分が、ハードウェア、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実装され得、ソフトウェアまたはファームウェアのための命令を実行するために、必須のハードウェアが与えられ得る。

【0038】

[0043]取出しユニット５２は、クライアントデバイス４０の復号能力およびレンダリング能力を、マニフェストファイル６６の情報によって示される表現６８の特性と比較し得る。取出しユニット５２は、最初に、表現６８の特性を決定するためにマニフェストファイル６６の少なくとも一部分を取り出し得る。たとえば、取出しユニット５２は、１つまたは複数の適応セットの特性を記述するマニフェストファイル６６の一部分を要求し得る。取出しユニット５２は、クライアントデバイス４０のコーディング能力およびレンダリング能力によって満たされ得る特性を有する表現６８のサブセット（たとえば、適応セット）を選択し得る。次いで、取出しユニット５２は、適応セット中の表現のためのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの１つからセグメントを取り出し得る。

【0039】

[0044]概して、より高いビットレート表現はより高品質のビデオ再生を生じ得、より低いビットレート表現は、利用可能なネットワーク帯域幅が減少したとき、十分な品質のビデオ再生を与え得る。したがって、利用可能なネットワーク帯域幅が比較的高いとき、取出しユニット５２は比較的高いビットレート表現からデータを取り出し得るが、利用可能なネットワーク帯域幅が低いとき、取出しユニット５２は比較的低いビットレート表現からデータを取り出し得る。このようにして、クライアントデバイス４０は、ネットワーク７４を介してマルチメディアデータをストリーミングしながら、ネットワーク７４の変化するネットワーク帯域幅利用可能性にも適応し得る。

【0040】

[0045]追加または代替として、取出しユニット５２は、ｅＭＢＭＳまたはＩＰマルチキャストなどのブロードキャストまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット５２は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加入するための要求をサブミットし得る。マルチキャストグループに加入した後に、取出しユニット５２は、サーバデバイス６０またはコンテンツ作成デバイス２０に発行されるさらなる要求なしに、マルチキャストグループのデータを受信し得る。取出しユニット５２は、マルチキャストグループのデータがもはや必要とされないときに、たとえば、再生を停止するために、またはチャネルを異なるマルチキャストグループに変更するために、マルチキャストグループを離れるための要求をサブミットし得る。

【0041】

[0046]ネットワークインターフェース５４は、選択された表現のセグメントのデータを受信し、取出しユニット５２に与え得、取出しユニット５２は、そのセグメントをカプセル化解除ユニット５０に与え得る。カプセル化解除ユニット５０は、ビデオファイルの要素を構成ＰＥＳストリームにカプセル化解除し、符号化データを取り出すためにＰＥＳストリームをパケット化解除し、たとえば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化データがオーディオストリームの一部であるのかビデオストリームの一部であるのかに応じて、符号化データをオーディオデコーダ４６またはビデオデコーダ４８のいずれかに送出し得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号オーディオデータをオーディオ出力４２に送出し、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力４４に送出する。

【0042】

[0047]ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、取出しユニット５２、およびカプセル化解除ユニット５０は各々、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な好適な処理回路のいずれかとして実装され得る。ビデオエンコーダ２８およびビデオデコーダ４８の各々は、１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。同様に、オーディオエンコーダ２６およびオーディオデコーダ４６の各々は、１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合コーデックの一部として統合され得る。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、カプセル化ユニット３０、取出しユニット５２、および／またはカプセル化解除ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。

【0043】

[0048]クライアントデバイス４０、サーバデバイス６０、および／またはコンテンツ作成デバイス２０は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス４０およびサーバデバイス６０に関して、これらの技法について説明する。しかしながら、コンテンツ作成デバイス２０は、サーバデバイス６０の代わりに（またはそれに加えて）これらの技法を実施するように構成され得ることを理解されたい。

【0044】

[0049]カプセル化ユニット３０は、ＮＡＬユニットが属するプログラムを識別するヘッダ、ならびにペイロード、たとえば、オーディオデータ、ビデオデータ、あるいはＮＡＬユニットが対応するトランスポートまたはプログラムストリームを記述するデータを備える、ＮＡＬユニットを形成し得る。たとえば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは、１バイトのヘッダと、変動するサイズのペイロードとを含む。それのペイロード中にビデオデータを含むＮＡＬユニットは、様々なグラニュラリティレベルのビデオデータを備え得る。たとえば、ＮＡＬユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を備え得る。カプセル化ユニット３０は、エレメンタリストリームのＰＥＳパケットの形態でビデオエンコーダ２８から符号化ビデオデータを受信し得る。カプセル化ユニット３０は、各エレメンタリストリームを対応するプログラムに関連付け得る。

【0045】

[0050]カプセル化ユニット３０はまた、複数のＮＡＬユニットからアクセスユニットをアセンブルし得る。概して、アクセスユニットは、ビデオデータのフレーム、ならびにそのフレームに対応するオーディオデータが利用可能であるとき、そのようなオーディオデータを表すための１つまたは複数のＮＡＬユニットを備え得る。アクセスユニットは、概して、１つの出力時間インスタンスについてのすべてのＮＡＬユニット、たとえば１つの時間インスタンスについてのすべてのオーディオおよびビデオデータを含む。たとえば、各ビューが２０フレーム毎秒（ｆｐｓ）のフレームレートを有する場合、各時間インスタンスは０．０５秒の時間間隔に対応し得る。この時間間隔中に、同じアクセスユニット（同じ時間インスタンス）のすべてのビューの特定のフレームは同時にレンダリングされ得る。一例では、アクセスユニットは、１次コード化ピクチャとして提示され得る、１つの時間インスタンス中のコード化ピクチャを備え得る。

【0046】

[0051]したがって、アクセスユニットは、共通の時間的インスタンスのすべてのオーディオおよびビデオフレーム、たとえば、時間Ｘに対応するすべてのビューを備え得る。本開示はまた、特定のビューの符号化ピクチャを「ビュー構成要素」と呼ぶ。すなわち、ビュー構成要素は、特定の時間における特定のビューのための符号化ピクチャ（またはフレーム）を備え得る。したがって、アクセスユニットは、共通の時間的インスタンスのすべてのビュー構成要素を備えるものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示順序と同じである必要があるとは限らない。

【0047】

[0052]メディアプレゼンテーションは、異なる代替表現（たとえば、異なる品質をもつビデオサービス）の記述を含んでいることがあるメディアプレゼンテーション記述（ＭＰＤ）を含み得、その記述は、たとえば、コーデック情報と、プロファイル値と、レベル値とを含み得る。ＭＰＤは、マニフェストファイル６６などのマニフェストファイルの一例である。クライアントデバイス４０は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスすべきかを決定するためにメディアプレゼンテーションのＭＰＤを取り出し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス（ｍｏｏｆボックス）中にあり得る。

【0048】

[0053]（たとえば、ＭＰＤを備え得る）マニフェストファイル６６は、表現６８のセグメントの利用可能性を広告し得る。すなわち、ＭＰＤは、表現６８のうちの１つの第１のセグメントが利用可能になる壁時計時間（wall-clock time）を示す情報、ならびに表現６８内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス４０の取出しユニット５２は、開始時間、ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントがいつ利用可能であるかを決定し得る。

【0049】

[0054]カプセル化ユニット３０が、受信されたデータに基づいてＮＡＬユニットおよび／またはアクセスユニットをビデオファイルにアセンブルした後に、カプセル化ユニット３０は、ビデオファイルを出力のために出力インターフェース３２に渡す。いくつかの例では、カプセル化ユニット３０は、ビデオファイルをローカルに記憶するか、または、ビデオファイルをクライアントデバイス４０に直接送出するのではなく、出力インターフェース３２を介してビデオファイルをリモートサーバに送出し得る。出力インターフェース３２は、たとえば、送信機、トランシーバ、たとえば、オプティカルドライブ、磁気メディアドライブ（たとえば、フロッピー（登録商標）ドライブ）など、コンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースを備え得る。出力インターフェース３２は、ビデオファイルを、たとえば、送信信号、磁気媒体、光媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体に出力する。

【0050】

[0055]ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し、取出しユニット５２を介してＮＡＬユニットまたはアクセスユニットをカプセル化解除ユニット５０に与え得る。カプセル化解除ユニット５０は、ビデオファイルの要素を構成ＰＥＳストリームにカプセル化解除し、符号化データを取り出すためにＰＥＳストリームをパケット化解除し、たとえば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化データがオーディオストリームの一部であるのかビデオストリームの一部であるのかに応じて、符号化データをオーディオデコーダ４６またはビデオデコーダ４８のいずれかに送出し得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号オーディオデータをオーディオ出力４２に送出し、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力４４に送出する。

【0051】

[0056]図１の例は、例としてＤＡＳＨおよびＨＴＴＰベースストリーミングの使用について説明する。しかしながら、他のタイプのプロトコルがメディアデータをトランスポートするために使用され得ることを理解されたい。たとえば、要求処理ユニット７０と取出しユニット５２とは、リアルタイムトランスポートプロトコル（ＲＴＰ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）などに従って動作し、セッション記述プロトコル（ＳＤＰ）またはセッション開始プロトコル（ＳＩＰ）など、サポートするプロトコルを使用するように構成され得る。

【0052】

[0057]図２は、図１の取出しユニット５２の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット５２は、ｅＭＢＭＳミドルウェアユニット１００と、ＤＡＳＨクライアント１１０と、メディアアプリケーション１１２とを含む。

【0053】

[0058]この例では、ｅＭＢＭＳミドルウェアユニット１００は、ｅＭＢＭＳ受信ユニット１０６と、キャッシュ１０４と、プロキシサーバユニット１０２とをさらに含む。この例では、ｅＭＢＭＳ受信ユニット１０６は、たとえば、ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６７２６において入手可能なＴ．Ｐａｉｌａら、「FLUTE-File Delivery over Unidirectional Transport」、ネットワークワーキンググループ、ＲＦＣ６７２６、２０１２年１１月に記載されている、ファイル配信オーバー単方向トランスポート（ＦＬＵＴＥ：File Delivery over Unidirectional Transport）に従って、ｅＭＢＭＳを介してデータを受信するように構成される。すなわち、ｅＭＢＭＳ受信ユニット１０６は、たとえば、ブロードキャスト／マルチキャストサービスセンター（ＢＭ－ＳＣ）として働き得るサーバデバイス６０から、ブロードキャストを介してファイルを受信し得る。

【0054】

[0059]ｅＭＢＭＳミドルウェアユニット１００がファイルについてのデータを受信したとき、ｅＭＢＭＳミドルウェアユニットは、受信されたデータをキャッシュ１０４に記憶し得る。キャッシュ１０４は、フラッシュメモリ、ハードディスク、ＲＡＭ、または任意の他の好適な記憶媒体など、コンピュータ可読記憶媒体を備え得る。

【0055】

[0060]プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０のためのサーバとして働き得る。たとえば、プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０にＭＰＤファイルまたは他のマニフェストファイルを与え得る。プロキシサーバユニット１０２は、ＭＰＤファイル中のセグメントのための利用可能性時間、ならびにセグメントがそこから取り出され得るハイパーリンクを広告し得る。これらのハイパーリンクは、クライアントデバイス４０に対応するローカルホストアドレスプレフィックス（たとえば、ＩＰｖ４についての１２７．０．０．１）を含み得る。このようにして、ＤＡＳＨクライアント１１０は、ＨＴＴＰ ＧＥＴ要求または部分ＧＥＴ要求を使用してプロキシサーバユニット１０２にセグメントを要求し得る。たとえば、リンクｈｔｔｐ：／／１２７．０．０．１／ｒｅｐ１／ｓｅｇ３から入手可能なセグメントの場合、ＤＡＳＨクライアント１１０は、ｈｔｔｐ：／／１２７．０．０．１／ｒｅｐ１／ｓｅｇ３についての要求を含むＨＴＴＰ ＧＥＴ要求を構築し、その要求をプロキシサーバユニット１０２にサブミットし得る。プロキシサーバユニット１０２は、要求されたデータをキャッシュ１０４から取り出し、そのデータを、そのような要求に応答してＤＡＳＨクライアント１１０に与え得る。

【0056】

[0061]クライアントデバイス４０は、メディアデータを取り出すためのデバイスであって、デバイスが、シーンデータと画像データとを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを含み、１つまたは複数のプロセッサは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行うように構成された、デバイスの一例を表す。

【0057】

[0062]図３は、例示的なマルチメディアコンテンツ１２０の要素を示す概念図である。マルチメディアコンテンツ１２０は、マルチメディアコンテンツ６４（図１）、または記憶媒体６２に記憶された別のマルチメディアコンテンツに対応し得る。図３の例では、マルチメディアコンテンツ１２０は、メディアプレゼンテーション記述（ＭＰＤ）１２２と複数の表現１２４Ａ～１２４Ｎ（表現１２４）とを含む。表現１２４Ａは、随意のヘッダデータ１２６とセグメント１２８Ａ～１２８Ｎ（セグメント１２８）とを含み、表現１２４Ｎは、随意のヘッダデータ１３０とセグメント１３２Ａ～１３２Ｎ（セグメント１３２）とを含む。文字Ｎは、便宜上、表現１２４の各々中の最後のムービーフラグメントを指定するために使用される。いくつかの例では、表現１２４間に異なる数のムービーフラグメントがあり得る。

【0058】

[0063]ＭＰＤ１２２は、表現１２４とは別個のデータ構造を備え得る。ＭＰＤ１２２は図１のマニフェストファイル６６に対応し得る。同様に、表現１２４は、図１の表現６８に対応し得る。概して、ＭＰＤ１２２は、コーディング特性およびレンダリング特性、適応セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（たとえば、時間サブシーケンスを含む表現を示す情報）、ならびに／または（たとえば、再生中のメディアコンテンツへのターゲット広告挿入のための）リモート期間を取り出すための情報など、表現１２４の特性を概して記述するデータを含み得る。

【0059】

[0064]ヘッダデータ１２６は、存在するとき、セグメント１２８の特性、たとえば、ランダムアクセスポイント（ＲＡＰ、ストリームアクセスポイント（ＳＡＰ）とも呼ばれる）の時間ロケーションを記述し得、セグメント１２８のランダムアクセスポイントは、ランダムアクセスポイント、セグメント１２８内のランダムアクセスポイントへのバイトオフセット、セグメント１２８のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１２８の他の態様を含む。ヘッダデータ１３０は、存在するとき、セグメント１３２についての同様の特性を記述し得る。追加または代替として、そのような特性はＭＰＤ１２２内に完全に含まれ得る。

【0060】

[0065]セグメント１２８、１３２は１つまたは複数のコード化ビデオサンプルを含み、コード化ビデオサンプルの各々はビデオデータのフレームまたはスライスを含み得る。セグメント１２８のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。そのような特性はＭＰＤ１２２のデータによって記述され得るが、そのようなデータは図３の例に示されていない。ＭＰＤ１２２は、本開示で説明されるシグナリングされた情報のいずれかまたはすべての追加を伴う、３ＧＰＰ仕様によって記述される特性を含み得る。

【0061】

[0066]セグメント１２８、１３２の各々は、一意のユニフォームリソースロケータ（ＵＲＬ）に関連付けられ得る。したがって、セグメント１２８、１３２の各々は、ＤＡＳＨなどのストリーミングネットワークプロトコルを使用して独立して取出し可能であり得る。このようにして、クライアントデバイス４０などの宛先デバイスは、セグメント１２８または１３２を取り出すためにＨＴＴＰ ＧＥＴ要求を使用し得る。いくつかの例では、クライアントデバイス４０は、セグメント１２８または１３２の特定のバイト範囲を取り出すためにＨＴＴＰ部分ＧＥＴ要求を使用し得る。

【0062】

[0067]図４は、図３のセグメント１２８、１３２のうちの１つなど、表現のセグメントに対応し得る、例示的なビデオファイル１５０の要素を示すブロック図である。セグメント１２８、１３２の各々は、図４の例に示されているデータの構成に実質的に準拠するデータを含み得る。ビデオファイル１５０は、セグメントをカプセル化すると言われることがある。上記で説明されたように、ＩＳＯベースメディアファイルフォーマットおよびそれの拡張によるビデオファイルは、データを「ボックス」と呼ばれる一連のオブジェクトに記憶する。図４の例では、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２と、ムービー（ＭＯＯＶ）ボックス１５４と、セグメントインデックス（ｓｉｄｘ）ボックス１６２と、ムービーフラグメント（ＭＯＯＦ）ボックス１６４と、ムービーフラグメントランダムアクセス（ＭＦＲＡ）ボックス１６６とを含む。図４はビデオファイルの一例を表しているが、他のメディアファイルは、ＩＳＯベースメディアファイルフォーマットおよびそれの拡張に従って、ビデオファイル１５０のデータと同様に構造化された他のタイプのメディアデータ（たとえば、オーディオデータ、タイムドテキストデータなど）を含み得ることを理解されたい。

【0063】

[0068]ファイルタイプ（ＦＴＹＰ）ボックス１５２は、概して、ビデオファイル１５０のためのファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０の最良の使用を記述する仕様を識別するデータを含み得る。ファイルタイプボックス１５２は、代替的に、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に配置され得る。

【0064】

[0069]いくつかの例では、ビデオファイル１５０など、セグメントは、ＦＴＹＰボックス１５２の前にＭＰＤ更新ボックス（図示せず）を含み得る。ＭＰＤ更新ボックスは、ＭＰＤを更新するための情報とともに、ビデオファイル１５０を含む表現に対応するＭＰＤが更新されるべきであることを示す情報を含み得る。たとえば、ＭＰＤ更新ボックスは、ＭＰＤを更新するために使用されるべきリソースについてのＵＲＩまたはＵＲＬを与え得る。別の例として、ＭＰＤ更新ボックスは、ＭＰＤを更新するためのデータを含み得る。いくつかの例では、ＭＰＤ更新ボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示せず）の直後にくることがあり、ここで、ＳＴＹＰボックスは、ビデオファイル１５０のためのセグメントタイプを定義し得る。

【0065】

[0070]ＭＯＯＶボックス１５４は、図４の例では、ムービーヘッダ（ＭＶＨＤ）ボックス１５６と、トラック（ＴＲＡＫ）ボックス１５８と、１つまたは複数のムービー拡張（ＭＶＥＸ）ボックス１６０とを含む。概して、ＭＶＨＤボックス１５６はビデオファイル１５０の一般的な特性を記述し得る。たとえば、ＭＶＨＤボックス１５６は、ビデオファイル１５０が最初に作成されたとき、ビデオファイル１５０が最後に変更されたときを記述するデータ、ビデオファイル１５０についての時間スケール、ビデオファイル１５０についての再生の持続時間、またはビデオファイル１５０を概して記述する他のデータを含み得る。

【0066】

[0071]ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックについてのデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を記述するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例では、ＴＲＡＫボックス１５８はコード化ビデオピクチャを含み得、他の例では、トラックのコード化ビデオピクチャは、ＴＲＡＫボックス１５８および／またはｓｉｄｘボックス１６２のデータによって参照され得るムービーフラグメント１６４中に含まれ得る。

【0067】

[0072]いくつかの例では、ビデオファイル１５０は２つ以上のトラックを含み得る。したがって、ＭＯＯＶボックス１５４は、ビデオファイル１５０中のトラックの数に等しいいくつかのＴＲＡＫボックスを含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。たとえば、ＴＲＡＫボックス１５８は、対応するトラックについての時間および／または空間情報を記述し得る。カプセル化ユニット３０（図１）が、ビデオファイル１５０などのビデオファイル中にパラメータセットトラックを含むとき、ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様のＴＲＡＫボックスは、パラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットトラックを記述するＴＲＡＫボックス内のパラメータセットトラック中のシーケンスレベルＳＥＩメッセージの存在をシグナリングし得る。

【0068】

[0073]ＭＶＥＸボックス１６０は、たとえば、もしあれば、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、ムービーフラグメント１６４をビデオファイル１５０が含むことをシグナリングするように、対応するムービーフラグメント１６４の特性を記述し得る。ビデオデータをストリーミングするコンテキストでは、コード化ビデオピクチャは、ＭＯＯＶボックス１５４中ではなくムービーフラグメント１６４中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、ＭＯＯＶボックス１５４中ではなくムービーフラグメント１６４中に含まれ得る。

【0069】

[0074]ＭＯＯＶボックス１５４は、ビデオファイル１５０中のムービーフラグメント１６４の数に等しいいくつかのＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６４のうちの対応する１つの特性を記述し得る。たとえば、各ＭＶＥＸボックスは、ムービーフラグメント１６４のうちの対応する１つについての持続時間を記述するムービー拡張ヘッダボックス（ＭＥＨＤ）ボックスを含み得る。

【0070】

[0075]上述のように、カプセル化ユニット３０は、シーケンスデータセットを、実際のコード化ビデオデータを含まないビデオサンプルに記憶し得る。ビデオサンプルは、概して、特定の時間インスタンスにおけるコード化ピクチャの表現である、アクセスユニットに対応し得る。ＡＶＣのコンテキストでは、コード化ピクチャは、アクセスユニットのすべてのピクセルを構築するための情報を含んでいる１つまたは複数のＶＣＬ ＮＡＬユニットと、ＳＥＩメッセージなどの他の関連する非ＶＣＬ ＮＡＬユニットとを含む。したがって、カプセル化ユニット３０は、ムービーフラグメント１６４のうちの１つ中に、シーケンスレベルＳＥＩメッセージを含み得る、シーケンスデータセットを含み得る。カプセル化ユニット３０はさらに、シーケンスデータセットおよび／またはシーケンスレベルＳＥＩメッセージの存在を、ムービーフラグメント１６４のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内のムービーフラグメント１６４のうちの１つ中に存在するものとしてシグナリングし得る。

【0071】

[0076]ＳＩＤＸボックス１６２は、ビデオファイル１５０の随意の要素である。すなわち、３ＧＰＰファイルフォーマット、または他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもＳＩＤＸボックス１６２を含むとは限らない。３ＧＰＰファイルフォーマットの例によれば、ＳＩＤＸボックスは、セグメント（たとえば、ビデオファイル１５０内に含まれているセグメント）のサブセグメントを識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを、「対応する（１つまたは複数の）メディアデータボックスと、ムービーフラグメントボックスによって参照されるデータを含んでいるメディアデータボックスとをもつ、１つまたは複数の連続するムービーフラグメントボックスの独立型セットは、そのムービーフラグメントボックスに後続し、同じトラックに関する情報を含んでいる次のムービーフラグメントボックスに先行しなければならない」と定義している。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが、「ボックスによってドキュメント化される（サブ）セグメントのサブセグメントへの参照のシーケンスを含んでいる。参照されるサブセグメントは提示時間において隣接する。同様に、セグメントインデックスボックスによって参照されるバイトは常にセグメント内で隣接する。参照されるサイズは、参照される材料中のバイト数のカウントを与える」ことを示している。

【0072】

[0077]ＳＩＤＸボックス１６２は、概して、ビデオファイル１５０中に含まれるセグメントの１つまたは複数のサブセグメントを表す情報を与える。たとえば、そのような情報は、サブセグメントが開始および／または終了する再生時間、サブセグメントについてのバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（たとえば、それで開始する）かどうか、ＳＡＰのためのタイプ（たとえば、ＳＡＰが瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャであるのか、クリーンランダムアクセス（ＣＲＡ）ピクチャであるのか、切断リンクアクセス（ＢＬＡ）ピクチャであるのかなど）、サブセグメント中の（再生時間および／またはバイトオフセットに関する）ＳＡＰの位置などを含み得る。

【0073】

[0078]ムービーフラグメント１６４は、１つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント１６４は１つまたは複数のピクチャグループ（ＧＯＰ）を含み得、ＧＯＰの各々は、いくつかのコード化ビデオピクチャ、たとえば、フレームまたはピクチャを含み得る。さらに、上記で説明されたように、ムービーフラグメント１６４は、いくつかの例では、シーケンスデータセットを含み得る。ムービーフラグメント１６４の各々は、ムービーフラグメントヘッダボックス（ＭＦＨＤ、図４に図示せず）を含み得る。ＭＦＨＤボックスは、ムービーフラグメントについてのシーケンス番号など、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント１６４は、ビデオファイル１５０中のシーケンス番号の順に含まれ得る。

【0074】

[0079]ＭＦＲＡボックス１６６は、ビデオファイル１５０のムービーフラグメント１６４内のランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０によってカプセル化されたセグメント内の特定の時間ロケーション（すなわち、再生時間）へのシークを実施することなど、トリックモードを実施するのを支援し得る。ＭＦＲＡボックス１６６は、概して随意であり、いくつかの例では、ビデオファイル中に含まれる必要がない。同様に、クライアントデバイス４０などのクライアントデバイスは、ビデオファイル１５０のビデオデータを正しく復号し、表示するために、必ずしもＭＦＲＡボックス１６６を参照する必要があるとは限らない。ＭＦＲＡボックス１６６は、ビデオファイル１５０のトラックの数に等しいか、またはいくつかの例では、ビデオファイル１５０のメディアトラック（たとえば、非ヒントトラック）の数に等しい、いくつかのトラックフラグメントランダムアクセス（ＴＦＲＡ）ボックス（図示せず）を含み得る。

【0075】

[0080]いくつかの例では、ムービーフラグメント１６４は、ＩＤＲピクチャなど、１つまたは複数のストリームアクセスポイント（ＳＡＰ）を含み得る。同様に、ＭＦＲＡボックス１６６は、ＳＡＰのビデオファイル１５０内のロケーションの指示を与え得る。したがって、ビデオファイル１５０のＳＡＰからビデオファイル１５０の時間サブシーケンスが形成され得る。時間サブシーケンスはまた、ＳＡＰに従属するＰフレームおよび／またはＢフレームなど、他のピクチャを含み得る。時間サブシーケンスのフレームおよび／またはスライスは、サブシーケンスの他のフレーム／スライスに依存する時間サブシーケンスのフレーム／スライスが適切に復号され得るように、セグメント内に構成され得る。たとえば、データの階層構成において、他のデータの予測のために使用されるデータも時間サブシーケンス中に含まれ得る。

【0076】

[0081]図５は、メディアファイル２００中に画像データを含むための高効率画像ファイル（ＨＥＩＦ）フォーマットの例示的な構造を示す概念図である。ＨＥＩＦフォーマットは、ＩＳＯ／ＩＥＣ２３００８－１２において定義されている。ＨＥＩＦは、ＩＳＯＢＭＦＦベースコンテナファイルへの画像および画像シーケンスならびにそれらのメタデータの記憶を指定する。ＨＥＩＦは、画像の記憶のための一般的なコーデックアグノスティック構造を定義するだけでなく、Ｈ．２６５／ＨＥＶＣコーデックに基づくインスタンス化をも提供する。図３のセグメント１２８、１３２は、いくつかの例では、図５のＨＥＩＦフォーマットに準拠し得る。

【0077】

[0082]ＨＥＩＦは、メディアの記憶のためにＩＳＯＢＭＦＦ設計ルールに従う。したがって、画像シーケンスがトラックに記憶され、静止画像がメタデータアイテムとして記憶される。前者では、画像は一緒にコード化される。したがって、コード化画像はいくつかの復号依存性を有する。後者では、画像は、互いから独立してコード化される。

【0078】

[0083]図５に示されているように、ＨＥＩＦフォーマットされたメディアファイル２００が、ＦＴＹＰボックス２０２と、画像シーケンス２０８中の０個以上の画像を含むＴＲＡＫボックス２０６を含み得るＭＯＯＶボックス２０４と、０個以上の画像アイテム２１８およびアイテムプロパティ（ＩＰＲＰ）ボックス２２０を含む画像ロケーション（ＩＬＯＣ）ボックス２１６を含むＭＥＴＡボックス２１４と、０個以上の画像２１２を含むＭＤＡＴボックス２１０と、０個以上の画像２２４を含むアイテムデータ（ＩＤＡＴ）ボックス２２２とを含む。

【0079】

[0084]ＨＥＶＣ符号化を用いた画像を記憶するＩＳＯＢＭＦＦコンテナファイルが、ＩＳＯＢＭＦＦボックスの最初のＦＴＹＰボックス２０２において見つけられる、「ｈｅｉｃ」または「ｈｅｖｃ」ブランドによって、対応して識別され得る。これらのファイルのＭＩＭＥタイプは、静止画像の場合「ｉｍａｇｅ／ｈｅｉｃ」または画像シーケンスの場合「ｉｍａｇｅ／ｈｅｉｃ－ｓｅｑｕｅｎｃｅ」に設定され得る。

【0080】

[0085]コンテナ中の画像は、異なる役割を割り当てられ得る。以下の役割は、画像２１２、２２４などの画像に割り当てられ得る例である。

【0081】

・ カバー画像：表示選好に関する他の情報の不在下で示されるデフォルト画像。１つのカバー画像のみがＨＥＩＦにおいて定義されていることがある。

【0082】

・ サムネイル画像：マスタ画像に対応する小さい解像度画像。

【0083】

・ 補助画像：マスタ画像を補完する、たとえば、深度マップを含んでいる画像。

【0084】

・ マスタ画像：フル解像度である、コンテナファイル中の主要な画像。

【0085】

・ 隠し画像：表示されることを意図されない画像。

【0086】

・ あらかじめ計算された導出された画像：他の画像から導出されたコード化画像。

【0087】

・ コード化画像：画像のコード化表現。

【0088】

・ 導出された画像：コンテナファイル中の他の画像に対するいくつかの動作と参照とを使用して導出されなければならい画像である。定義された動作は、クロッピングと、回転と、ミラーリングと、合成とを含む。

【0089】

[0086]画像シーケンスは、マスタ、補助、またはサムネイル画像シーケンス役割を行い得る。

【0090】

[0087]画像２１２、２２４は、それら自体のメタデータとともにコンテナファイルに記憶され得る。初期化情報は、画像シーケンスのためにサンプル記述ボックスの一部としてサンプルエントリに記憶され得る。静止画像の場合、初期化情報は、アイテムプロパティとしてＩＰＲＰコンテナボックス２２０の一部として記憶され得る。このメタデータは、画像の次元、コーデック初期化情報などの情報を含んでいることがある。

【0091】

[0088]ピクセルアスペクト比、色情報、およびビット深度など、追加のメタデータが、アイテムプロパティコンテナボックス中に存在し、アイテム参照ボックス中の「ｃｄｓｃ」参照タイプを使用して実際の画像を参照することができる。

【0092】

[0089]画像シーケンス２０８などの画像シーケンスの場合、仕様は、たとえば、以下のいずれかまたはすべてを記述するために再生制御特徴を定義する。

【0093】

・ 表示されるべきでない画像
・ スライドショー対画像集合
・ スライドショーのための再生タイミング
・ スライドショーのルーピング
・ 画像に対する変換
[0090]画像シーケンス中の特定の画像へのアクセスを容易にするために、サンプルグループ化が、その画像の復号依存性を示すために使用され得る。デコーダは、画像シーケンス２０８のすべての画像２１２を復号する必要があるとは限らない。

【0094】

[0091]ＨＥＶＣのためのリアルタイムトランスポートプロトコル（ＲＴＰ）ペイロードフォーマットは、ＩＥＴＦ ＲＦＣ７７９８、高効率ビデオコーディング（ＨＥＶＣ）のためのＲＴＰペイロードフォーマットにおいて定義されている。ＲＦＣ７７９８は、現在、ビデオストリームのトランスポートのためにＭＴＳＩによってサポートされている。ペイロードフォーマットは、ＨＥＶＣペイロードを搬送するときのＲＴＰヘッダの使用と、ＨＥＶＣコード化ＮＡＬユニットの、ＲＴＰパケットへのパケット化と、ＳＤＰ記述と、ペイロードヘッダ拡張機構とを定義する。

【0095】

[0092]ＩＴＴ４ＲＴのコンテキストでは、画像と画像シーケンスの両方がオーバーレイとして使用され得る。ＨＥＩＦフォーマットは、オーバーレイのためのソースとして使用され得る。送信はＨＥＶＣ準拠であり得、すなわち、画像アイテムおよび画像シーケンスは、ＨＥＩＦソースから抽出され、ＨＥＶＣペイロードフォーマットを使用して送信され得る。

【0096】

[0093]ＩＴＴ４ＲＴ－ｔｘクライアントは、以下の情報を受信機に示し得る。

【0097】

・ ストリームが画像オーバーレイストリームであること。

【0098】

・ ストリームが、画像シーケンスを搬送するのか静止画像を搬送するのかその両方を搬送するのか。

【0099】

・ 静止画像アイテムの数。

【0100】

・ 画像シーケンス中の画像の数。

【0101】

・ 静止画像または画像シーケンスのための送信モード。送信モードは、送信と表示との結合を示すために「結合（coupled）」に設定され得、その場合、表示時間は常に、ＲＴＰタイムスタンプによって決定される。代替的に、送信モードは、送信が提示から独立していることを示すために「分離（decoupled）」であり得、その結果、提示タイミングは、記憶およびルーピングなどの使用事例をサポートするために別々に与えられる。

【0102】

・ 送信モードが「分離」に設定された場合の、静止画像集合または画像シーケンス中の画像の表示順序。

【0103】

・ 画像次元、画像役割などを含む、画像アイテムまたはサンプルの各々のための画像メタデータ。

【0104】

[0094]このシグナリングをサポートするために、「画像」ＳＤＰ属性は、ストリームが、静止画像および／または画像シーケンスを含む１つまたは複数のオーバーレイ画像を搬送することを識別するために使用され得る。「画像」属性は、以下の拡張バッカス－ナウア記法（ＡＢＮＦ）シンタックスを有し得る。

【0105】

・ ｉｍａｇｅ＿ａｔｔｒｉｂｕｔｅ＝“ａ＝ｉｍａｇｅ：” ｐｔ ＳＰ ｔｒａｎｓｍｉｓｓｉｏｎ＿ｍｏｄｅ ＳＰ ｉｔｅｍ＿ｃｏｕｎｔ
・ ｔｒａｎｓｍｉｓｓｉｏｎ＿ｍｏｄｅ＝“ｔｍｏｄｅ＝” （”結合” ／ “分離” ［“；” ｓｔｏｒｅ］ ［“；” ｌｏｏｐ］）
・ ｉｔｅｍ＿ｃｏｕｎｔ＝“ｃｏｕｎｔ＝” １＊ＤＩＧＩＴ
・ ｍｅｔａｄａｔａ＿ｉｎｄｅｘ＝“ｍｅｔａ＝” １＊ＤＩＧＩＴ
・ ｓｔｏｒｅ＝“ｓｔｏｒｅ＝” （“０”／”１”）
・ ｌｏｏｐ＝“ｌｏｏｐ＝” （“０”／”１”）
[0095]上記のシンタックス要素についてのセマンティクスは以下のように定義され得る。

【0106】

[0096]ｐｔ：この画像集合または画像シーケンスの搬送のために使用されるペイロードタイプ。複数の画像シーケンスまたは画像集合と画像シーケンスとの混合の存在下で、異なるペイロードタイプが、異なるシーケンスまたは画像集合のために使用されるものとする。

【0107】

[0097]ｔｒａｎｓｍｉｓｓｉｏｎ＿ｍｏｄｅ：送信モード、結合は、オーバーレイがレンダリングされるべきである限り、オーバーレイ画像が連続的にストリーミングされる（再送信される）ことになることを示す。ＲＴＰタイムスタンプは、オーバーレイ画像の提示時間を決定するために使用され得る。画像は記憶されることを必要とされず、ルーピングは実施される必要がない。画像は、この場合マスタ画像であり得る。「分離」送信モードの場合、画像の提示は、画像メタデータによって上書きされ得る。ＲＴＰタイムスタンプは、画像のインデックスを決定するために使用され得る。

【0108】

[0098]ｉｔｅｍ＿ｃｏｕｎｔ：対応する画像集合または画像シーケンス中の画像の数を与える。

【0109】

[0099]ｓｔｏｒｅ：分離送信モードの場合、ｓｔｏｒｅフラグは、連続提示のために画像を記憶すべきか否かを受信機に伝える。これは、送信セッションが実際の提示よりもはるかに短くなることを可能にする。特に、静止画像オーバーレイは、一般に、オーバーレイの存続期間全体にわたって提示のために記憶される。

【0110】

[0100]ｌｏｏｐ：分離送信モードの場合、ｌｏｏｐフラグは、画像集合または画像シーケンスがループされるものとするかどうか、あるいはその集合または画像シーケンス中の最後の画像アイテムが表示中のままであるべきかどうかを示す。

【0111】

[0101]画像集合または画像シーケンス中の画像アイテムのためのメタデータの搬送は、以下のように定義され得る、「ｉｍａｇｅ－ｍｅｔａｄａｔａ」属性を使用して実施される。
ｉｍａｇｅ－ｍｅｔａｄａｔａ＝”ａ＝ｉｍａｇｅ－ｍｅｔａｄａｔａ：” ｐｔ ＳＰ ｃｏｄｅｄ－ｍｅｔａｄａｔａ
[0102]上記の例では、ｃｏｄｅｄ－ｍｅｔａｄａｔａは、対応する画像集合または画像シーケンスのためのｂａｓｅ６４コード化画像メタデータである。

【0112】

[0103]画像メタデータは、以下のフォーマットを有し得る。

【0113】

【表1】

【0114】

[0104]すべての画像プロパティは、たとえば、ＩＳＯ／ＩＥＣ２３００８－１２，ＭＰＥＧ ｓｙｓｔｅｍｓ Ｔｅｃｈｎｏｌｏｇｉｅｓ－Ｐａｒｔ１２：画像ファイルフォーマットにおいて定義されている、それらのそれぞれの定義に従ってフォーマットされ得る。

【0115】

[0105]ｄｉｓｐｌａｙ＿ｉｎｆｏ要素は、画像集合またはシーケンス中の各画像の表示順序に関する情報を与え得る。０の順序は、画像がレンダリングされるべきでないことを意味する。このことは、補助画像または隠し画像の場合、起こり得る。持続時間は、画像が９０ｋＨｚクロックの単位でどのくらい長い間レンダリングされるべきであるかを示す。

【0116】

[0106]メタデータ情報は、ｂａｓｅ６４符号化され、各画像集合または画像シーケンスについて独立してｉｍａｇｅ－ｍｅｔａｄａｔａ属性の一部として与えられ得る。

【0117】

[0107]結合送信モードは、ライブオーバーレイストリーム、たとえば、ライブスライドプレゼンテーションに好適であり得る。分離送信モードは、タイムドスライドショーなど、プリセットコンテンツに好適であり得る。

【0118】

[0108]以下の表は、画像集合および画像シーケンスの搬送のためのＳＤＰデータの例示的なセットを与える。
．
．
．
ｍ＝ｖｉｄｅｏ ４９１７０ ＲＴＰ／ＡＶＰ ９８，９９
ａ＝ｒｔｐｍａｐ：９８ Ｈ２６５／９００００
ａ＝ｆｍｔｐ：９８ ｐｒｏｆｉｌｅ－ｉｄ＝１；ｓｐｒｏｐ－ｖｐｓ＝＜ビデオパラメータセットデータ＞
ａ＝ｉｍａｇｅ：９８ ｔｍｏｄｅ＝結合 ｃｏｕｎｔ＝１４
ａ＝ｉｍａｇｅ－ｍｅｔａｄａｔａ：９８ ｃｏｄｅｄ－ｍｅｔａｄａｔａ＝＜ｂａｓｅ６４コード化メタデータ＞
ａ＝ｒｔｐｍａｐ：９９ Ｈ２６５／９００００
ａ＝ｆｍｔｐ：９９ ｐｒｏｆｉｌｅ－ｉｄ＝１；ｓｐｒｏｐ－ｖｐｓ＝＜ビデオパラメータセットデータ＞
ａ＝ｉｍａｇｅ：９９ ｔｍｏｄｅ＝分離；ｓｔｏｒｅ＝１；ｌｏｏｐ＝１ ｃｏｕｎｔ＝６
ａ＝ｉｍａｇｅ－ｍｅｔａｄａｔａ：９９ ｃｏｄｅｄ－ｍｅｔａｄａｔａ＝＜ｂａｓｅ６４コード化メタデータ＞
．
．
．
[0109]図６は、本開示の技法による、メディアデータを取り出す例示的な方法を示すフローチャートである。図６の方法は、図１および図２のクライアントデバイス４０および取出しユニット５２に関して説明される。他のデバイスが、この方法または同様の方法を実施するように構成され得る。

【0119】

[0110]上記で説明されたように、ビットストリームは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示すデータを含み得る。特に、オーバーレイ画像は、静的画像または画像シーケンスのいずれかまたはその両方を含み得る。静的画像は、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータ（たとえば、ビデオデータ、エクステンデッドリアリティ（ＸＲ）コンテンツ、拡張現実（ＡＲ）コンテンツ、仮想現実（ＶＲ）コンテンツなど）とともに提示されるべきである画像であり得る。追加または代替として、画像シーケンスは、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像のシーケンスであり得る。

【0120】

[0111]オーバーレイ画像は、全体としてのシーンデータよりも、完全なビューポート提示のより小さい領域を占有し得る。すなわち、シーンデータは、概して、ビューポートの全体（すなわち、スクリーン、レンズ、または他の表示デバイスの全体）を占有し得るが、オーバーレイ画像は、ビューポートの比較的小さい部分を占有し、シーンデータ上で（その前に）提示され得、したがって、オーバーレイ画像はシーンデータの小さい部分を遮る。

【0121】

[0112]ビットストリームのデータは、ＳＤＰ画像属性、または、たとえば、オーバーレイ画像が、静的画像を含むのか、画像シーケンスを含むのか、その両方を含むのかを示すペイロードタイプを示す他のデータを含み得る。データは、送信モード、たとえば、「結合」または「分離」をも示し得る。「結合」の送信モードは、オーバーレイ画像がビットストリーム中で連続的に送信されることを示す。「分離」の送信モードは、オーバーレイ画像が再送信されないことを示す。いくつかの例では、データは、オーバーレイ画像が記憶される（バッファされる）べきであるかどうか、および／または、オーバーレイ画像がループでプレイされるべきであるかどうかをさらに示し得る。

【0122】

[0113]したがって、図１のクライアントデバイス４０の取出しユニット５２は、たとえば、１つまたは複数のオーバーレイ画像がビットストリーム中に含まれることを示す、ビットストリームのデータを受信し得る（２５０）。取出しユニット５２は、次いで、このデータを使用して、オーバーレイ画像タイプを決定し得る（２５２）。たとえば、取出しユニット５２は、オーバーレイ画像が静的画像および／または画像シーケンスを含むかどうかを決定し得る。

【0123】

[0114]取出しユニット５２は、オーバーレイ画像のための送信モードをも決定し得る（２５４）。たとえば、取出しユニット５２は、オーバーレイ画像が、連続的に再送信されるのか、１回（あるいは、たとえば、ブロードキャストまたはマルチキャストの代わりにユニキャストを介してオンデマンドで）送出されるのかを決定し得る。したがって、取出しユニット５２は、オーバーレイ画像をいつおよびどのように抽出すべきか、オーバーレイ画像をバッファすべきかどうか、オーバーレイ画像をどのように提示すべきか（たとえば、ループにわたって、または単一の提示として）などを決定し得る。取出しユニット５２は、オーバーレイ画像の抽出を表すデータをカプセル化解除ユニット５０に与え、オーバーレイ画像の提示を、たとえば、ビデオ出力４４に与え得る。

【0124】

[0115]取出しユニット５２は、シーンのためのシーンデータを受信し（２５６）、ならびにオーバーレイ画像自体を受信し得る（２５８）。オーバーレイ画像は、図５のメディアファイル２００などのメディアファイル中に含まれ得る。取出しユニット５２は、受信されたデータが、オーバーレイ画像がバッファされるべきであることを示すと仮定して、オーバーレイ画像を、たとえば、キャッシュ１０４（図２）中にバッファし得る。

【0125】

[0116]取出しユニット５２のメディアアプリケーション１１２（図２）は、次いで、シーンデータとともにオーバーレイ画像を提示し得る（２６０）。たとえば、メディアアプリケーション１１２は、ビデオ出力４４を介してフレームごとにシーンデータを提示しながら、シーンデータ上でオーバーレイ画像を提示するように構成され得る。たとえば、メディアアプリケーション１１２は、フレームごとに提示されるシーンデータ上で単一の、静的オーバーレイ画像を提示するように構成され得る。代替的に、オーバーレイ画像が、ループされるべきである画像シーケンスを含む場合、メディアアプリケーション１１２は、オーバーレイ画像を順序通り繰り返し提示し得る。すなわち、ビデオシーケンスがＮ個の画像を含み、ここで、Ｎが正の整数である場合、ｊが非負整数である、ループｊについて、メディアアプリケーション１１２は、時間ｊ＊Ｎ＋ｉにおいて画像ｉを提示し得る。受信されたデータは、オーバーレイ画像のための提示時間を示し得、メディアアプリケーション１１２は、それに応じて、示された提示時間においてオーバーレイ画像を提示し得る。

【0126】

[0117]ＤＡＳＨクライアント１１０は、ユニキャストを使用して別個のサーバデバイスから、またはプロキシサーバ１０２からのいずれかでオーバーレイ画像を取り出すように構成され得る。特に、画像がキャッシュ１０４にローカルに記憶されるべきである場合、ＤＡＳＨクライアント１１０は、プロキシサーバ１０２を介して、キャッシュ１０４（すなわち、ローカルメモリ）からオーバーレイ画像を繰り返し取り出し得る。代替的に、メディアアプリケーション１１２は、キャッシュ１０４とは別個のストレージデバイス中のメモリを割り振られ、割り振られたメモリ中にオーバーレイ画像をバッファし得る。

【0127】

[0118]このようにして、図６の方法は、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを含む、方法の一例を表す。

【0128】

[0119]本開示の技法の様々な例は、以下の条項において要約される。

【0129】

[0120]条項１：メディアデータを取り出す方法であって、方法は、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを備える、方法。

【0130】

[0121]条項２：１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むかどうかと、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むかどうかとを示す、ビットストリームのためのデータを受信することをさらに備える、条項１に記載の方法。

【0131】

[0122]条項３：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むことを示すとき、画像シーケンスの各々中の画像の数をさらに備える、条項２に記載の方法。

【0132】

[0123]条項４：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むことを示すとき、静止画像の数をさらに備える、条項２および３のいずれかに記載の方法。

【0133】

[0124]条項５：画像シーケンスと静止画像とのための送信モードを表すデータを受信することをさらに備える、条項２から４のいずれかに記載の方法。

【0134】

[0125]条項６：送信モードのうちの１つが「結合」であるとき、ビットストリームのタイムスタンプデータからオーバーレイ画像のための表示時間を決定することをさらに備える、条項５に記載の方法。

【0135】

[0126]条項７：タイムスタンプデータが、リアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプデータを備える、条項６に記載の方法。

【0136】

[0127]条項８：送信モードのうちの１つが「分離」であるとき、オーバーレイ画像のための表示時間を表すデータを別々に受信することと、別々に受信されたデータからオーバーレイ画像のための表示時間を決定することとをさらに備える、条項５から７のいずれかに記載の方法。

【0137】

[0128]条項９：１つまたは複数のオーバーレイ画像が２つまたはそれ以上のオーバーレイ画像を含むとき、オーバーレイ画像の表示順序を表すデータを受信することをさらに備える、条項１から８のいずれかに記載の方法。

【0138】

[0129]条項１０：ビットストリームからオーバーレイ画像の各々のための画像メタデータを受信することをさらに備え、メタデータが、画像次元または画像役割のうちの１つまたは複数を示す、条項１から９のいずれかに記載の方法。

【0139】

[0130]条項１１：画像役割が、カバー画像、サムネイル画像、補助画像、マスタ画像、隠し画像、あらかじめ計算された導出された画像、コード化画像、または導出された画像のうちの少なくとも１つを備える、条項１０に記載の方法。

【0140】

[0131]条項１２：メタデータが、ｉｍａｇｅ＿ｐｒｏｐｅｒｔｉｅｓ（）要素、ｄｉｓｐｌａｙ＿ｉｎｆｏ（）要素、またはｅｘｔｅｎｓｉｏｎ＿ｉｎｆｏ（）要素のうちの１つまたは複数を含む、条項１０および１１のいずれかに記載の方法。

【0141】

[0132]条項１３：ｉｍａｇｅ＿ｐｒｏｐｅｒｔｉｅｓ（）要素が、ｉｓｐｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｐａｓｐ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｃｏｌｒ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｐｉｘｉ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｃｌａｐ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｉｒｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｉｍｉｒ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｏｔｈｅｒ＿ｐｒｏｐｅｒｔｉｅｓ（）要素、ＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙ（）要素、ＰｉｘｅｌＡｓｐｅｃｔＲａｔｉｏＢｏｘ（）要素、ＣｏｌｏｕｒＩｎｆｏｒｍａｔｉｏｎＢｏｘ（）要素、ＰｉｘｅｌＩｎｆｏｒｍａｔｉｏｎＰｒｏｐｅｒｔｙ（）要素、ＣｌｅａｎＡｐｅｒｔｕｒｅＢｏｘ（）要素、またはＩｍａｇｅＲｏｔａｔｉｏｎ（）要素のうちの１つまたは複数を含む、条項１２に記載の方法。

【0142】

[0133]条項１４：ｄｉｓｐｌａｙ＿ｉｎｆｏ（）要素は、オーバーレイ画像の提示の順序を示す順序要素、またはオーバーレイ画像のうちの対応する１つが表示されるべきである時間の量を示す持続時間要素のうちの１つまたは複数を含む、条項１２および１３のいずれかに記載の方法。

【0143】

[0134]条項１５：ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することをさらに備える、条項１から１４のいずれかに記載の方法。

【0144】

[0135]条項１６：ＳＤＰ画像属性が、ｉｍａｇｅ＿ａｔｔｒｉｂｕｔｅ、ｔｒａｎｓｍｉｓｓｉｏｎ＿ｍｏｄｅ、ｉｔｅｍ＿ｃｏｕｎｔ、ｍｅｔａｄａｔａ＿ｉｎｄｅｘ、ｓｔｏｒｅ、またはｌｏｏｐを含む１つまたは複数のシンタックス要素を含む、条項１５に記載の方法。

【0145】

[0136]条項１７：１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むかどうかと、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むかどうかとを示す、ビットストリームのためのデータを受信することをさらに備える、条項１に記載の方法。

【0146】

[0137]条項１８：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むことを示すとき、画像シーケンスの各々中の画像の数をさらに備える、条項１７に記載の方法。

【0147】

[0138]条項１９：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むことを示すとき、静止画像の数をさらに備える、条項１８に記載の方法。

【0148】

[0139]条項２０：画像シーケンスと静止画像とのための送信モードを表すデータを受信することをさらに備える、条項１８に記載の方法。

【0149】

[0140]条項２１：送信モードのうちの１つが「結合」であるとき、ビットストリームのタイムスタンプデータからオーバーレイ画像のための表示時間を決定することをさらに備える、条項２０に記載の方法。

【0150】

[0141]条項２２：タイムスタンプデータが、リアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプデータを備える、条項２１に記載の方法。

【0151】

[0142]条項２３：送信モードのうちの１つが「分離」であるとき、オーバーレイ画像のための表示時間を表すデータを別々に受信することと、別々に受信されたデータからオーバーレイ画像のための表示時間を決定することとをさらに備える、条項２０に記載の方法。

【0152】

[0143]条項２４：１つまたは複数のオーバーレイ画像が２つまたはそれ以上のオーバーレイ画像を含むとき、オーバーレイ画像の表示順序を表すデータを受信することをさらに備える、条項１に記載の方法。

【0153】

[0144]条項２５：ビットストリームからオーバーレイ画像の各々のための画像メタデータを受信することをさらに備え、メタデータが、画像次元または画像役割のうちの１つまたは複数を示す、条項１に記載の方法。

【0154】

[0145]条項２６：画像役割が、カバー画像、サムネイル画像、補助画像、マスタ画像、隠し画像、あらかじめ計算された導出された画像、コード化画像、または導出された画像のうちの少なくとも１つを備える、条項２５に記載の方法。

【0155】

[0146]条項２７：メタデータが、ｉｍａｇｅ＿ｐｒｏｐｅｒｔｉｅｓ（）要素、ｄｉｓｐｌａｙ＿ｉｎｆｏ（）要素、またはｅｘｔｅｎｓｉｏｎ＿ｉｎｆｏ（）要素のうちの１つまたは複数を含む、条項２６に記載の方法。

【0156】

[0147]条項２８：ｉｍａｇｅ＿ｐｒｏｐｅｒｔｉｅｓ（）要素が、ｉｓｐｅ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｐａｓｐ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｃｏｌｒ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｐｉｘｉ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｃｌａｐ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｉｒｏｔ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｉｍｉｒ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ、ｏｔｈｅｒ＿ｐｒｏｐｅｒｔｉｅｓ（）要素、ＩｍａｇｅＳｐａｔｉａｌＥｘｔｅｎｔｓＰｒｏｐｅｒｔｙ（）要素、ＰｉｘｅｌＡｓｐｅｃｔＲａｔｉｏＢｏｘ（）要素、ＣｏｌｏｕｒＩｎｆｏｒｍａｔｉｏｎＢｏｘ（）要素、ＰｉｘｅｌＩｎｆｏｒｍａｔｉｏｎＰｒｏｐｅｒｔｙ（）要素、ＣｌｅａｎＡｐｅｒｔｕｒｅＢｏｘ（）要素、またはＩｍａｇｅＲｏｔａｔｉｏｎ（）要素のうちの１つまたは複数を含む、条項２７に記載の方法。

【0157】

[0148]条項２９：ｄｉｓｐｌａｙ＿ｉｎｆｏ（）要素は、オーバーレイ画像の提示の順序を示す順序要素、またはオーバーレイ画像のうちの対応する１つが表示されるべきである時間の量を示す持続時間要素のうちの１つまたは複数を含む、条項２７に記載の方法。

【0158】

[0149]条項３０：ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することをさらに備える、条項１に記載の方法。

【0159】

[0150]条項３１：ＳＤＰ画像属性が、ｉｍａｇｅ＿ａｔｔｒｉｂｕｔｅ、ｔｒａｎｓｍｉｓｓｉｏｎ＿ｍｏｄｅ、ｉｔｅｍ＿ｃｏｕｎｔ、ｍｅｔａｄａｔａ＿ｉｎｄｅｘ、ｓｔｏｒｅ、またはｌｏｏｐを含む１つまたは複数のシンタックス要素を含む、条項３０に記載の方法。

【0160】

[0151]条項３２：メディアデータを取り出すためのデバイスであって、デバイスが、条項１から３１のいずれかの方法を実施するための１つまたは複数の手段を備える、デバイス。

【0161】

[0152]条項３３：１つまたは複数の手段が、回路中に実装された１つまたは複数のプロセッサを備える、条項３２に記載のデバイス。

【0162】

[0153]条項３４：デバイスが、集積回路、マイクロプロセッサ、またはワイヤレス通信デバイスのうちの少なくとも１つを備える、条項３２に記載のデバイス。

【0163】

[0154]条項３５：命令を記憶したコンピュータ可読記憶媒体であって、命令が、実行されたとき、プロセッサに、条項１から３１のいずれかに記載の方法を実施させる、コンピュータ可読記憶媒体。

【0164】

[0155]条項３６：メディアデータを受信するためのデバイスであって、デバイスは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信するための手段と、ビットストリームから１つまたは複数のオーバーレイ画像を受信するための手段と、１つまたは複数のシーン画像を含むシーンデータを受信するための手段と、シーン画像とオーバーレイ画像とを提示するための手段とを備える、デバイス。

【0165】

[0156]条項３７：メディアデータを取り出す方法であって、方法は、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを備える、方法。

【0166】

[0157]条項３８：ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することをさらに備える、条項３７に記載の方法。

【0167】

[0158]条項３９：ＳＤＰ画像属性は、１つまたは複数のオーバーレイ画像が単一の静的画像を含むのか画像シーケンスを含むのかを示すペイロードタイプを示す画像属性を含む、条項３８に記載の方法。

【0168】

[0159]条項４０：ペイロードタイプが、１つまたは複数の画像が単一の静的画像を含むことを示すとき、シーン画像とオーバーレイ画像とを提示することが、シーン画像を画像ごとに提示するときに単一の静的画像を繰り返し提示することを備える、条項３９に記載の方法。

【0169】

[0160]条項４１：ペイロードタイプが、１つまたは複数の画像が画像シーケンスを含むことを示すとき、シーン画像とオーバーレイ画像とを提示することが、画像シーケンスの画像を、シーン画像の対応する画像と一緒に順序通り提示することを備える、条項３９に記載の方法。

【0170】

[0161]条項４２：ＳＤＰ画像属性は、オーバーレイ画像がシーンデータのフレームとともに提示されるべきである限り、オーバーレイ画像が連続的に再送信されるかどうかを示す送信モード属性を含む、条項３８に記載の方法。

【0171】

[0162]条項４３：ＳＤＰ画像属性は、オーバーレイ画像がループで繰り返し提示されるべきであるかどうかを示すデータを含む、条項３８に記載の方法。

【0172】

[0163]条項４４：データが、オーバーレイ画像がループで繰り返し提示されるべきであることを示すとき、シーン画像とオーバーレイ画像とを提示することは、オーバーレイ画像が画像シーケンス中にＮ個の画像を含むと決定することと、Ｎが正の整数である、ｊが非負整数である、ループ数ｊについて、時間ｊ＊Ｎ＋ｉにおいてオーバーレイ画像の画像シーケンスの画像ｉを提示することと、ｉがオーバーレイ画像の画像シーケンスのｉ番目の画像に対応する、を備える、条項４３に記載の方法。

【0173】

[0164]条項４５：ＳＤＰ画像属性は、オーバーレイ画像が受信の後にローカルに記憶されるべきであるかどうかを示すデータを含む、条項３８に記載の方法。

【0174】

[0165]条項４６：データが、オーバーレイ画像が受信の後にローカルに記憶されるべきであることを示すとき、方法が、オーバーレイ画像をローカルメモリに記憶することをさらに備え、ここにおいて、シーン画像とオーバーレイ画像とを提示することが、ローカルメモリからオーバーレイ画像を取り出すことと、取り出されたオーバーレイ画像を提示することとを備える、条項４５に記載の方法。

【0175】

[0166]条項４７：データが、オーバーレイ画像が再送信されることになることを示すとき、シーン画像とオーバーレイ画像とを提示することが、オーバーレイ画像の再送信されたバージョンを受信することと、オーバーレイ画像の再送信されたバージョンを提示することとを備える、条項４５に記載の方法。

【0176】

[0167]条項４８：ＳＤＰ画像属性が、オーバーレイ画像中に含まれる画像の数を示すデータを含む、条項３８に記載の方法。

【0177】

[0168]条項４９：１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むかどうかと、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むかどうかとを示す、ビットストリームのためのデータを受信することをさらに備える、条項３７に記載の方法。

【0178】

[0169]条項５０：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むことを示すとき、画像シーケンスの各々中の画像の数を示す、ビットストリームのためのデータを受信することをさらに備える、条項４９に記載の方法。

【0179】

[0170]条項５１：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むことを示すとき、静止画像の数を示す、ビットストリームのためのデータを受信することをさらに備える、条項４９に記載の方法。

【0180】

[0171]条項５２：画像シーケンスと静止画像とのための送信モードを表すデータを受信することをさらに備える、条項４９に記載の方法。

【0181】

[0172]条項５３：送信モードのうちの１つが「結合」であるとき、ビットストリームのタイムスタンプデータからオーバーレイ画像のための表示時間を決定することをさらに備える、条項５２に記載の方法。

【0182】

[0173]条項５４：タイムスタンプデータが、リアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプデータを備える、条項５３に記載の方法。

【0183】

[0174]条項５５：送信モードのうちの１つが「分離」であるとき、オーバーレイ画像のための表示時間を表すデータを別々に受信することと、別々に受信されたデータからオーバーレイ画像のための表示時間を決定することとをさらに備える、条項５２に記載の方法。

【0184】

[0175]条項５６：１つまたは複数のオーバーレイ画像が２つまたはそれ以上のオーバーレイ画像を含むとき、オーバーレイ画像の表示順序を表すデータを受信することをさらに備える、条項３７に記載の方法。

【0185】

[0176]条項５７：ビットストリームからオーバーレイ画像の各々のための画像メタデータを受信することをさらに備え、メタデータが、画像次元または画像役割のうちの１つまたは複数を示す、条項３７に記載の方法。

【0186】

[0177]条項５８：画像役割が、カバー画像、サムネイル画像、補助画像、マスタ画像、隠し画像、あらかじめ計算された導出された画像、コード化画像、または導出された画像のうちの少なくとも１つを備える、条項５７に記載の方法。

【0187】

[0178]条項５９：メタデータは、オーバーレイ画像の提示の順序を示す順序要素、またはオーバーレイ画像のうちの対応する１つが表示されるべきである時間の量を示す持続時間要素のうちの１つまたは複数を含む、条項５７に記載の方法。

【0188】

[0179]条項６０：メディアデータを取り出すためのデバイスであって、デバイスが、シーンデータと画像データとを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを備え、１つまたは複数のプロセッサは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行うように構成された、デバイス。

【0189】

[0180]条項６１：１つまたは複数のプロセッサが、ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することを行うようにさらに構成された、条項６０に記載のデバイス。

【0190】

[0181]条項６２：ＳＤＰ画像属性は、１つまたは複数のオーバーレイ画像が単一の静的画像を含むのか画像シーケンスを含むのかを示すペイロードタイプを示す画像属性を含む、条項６１に記載のデバイス。

【0191】

[0182]条項６３：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、ペイロードタイプが、１つまたは複数の画像が単一の静的画像を含むことを示すとき、シーン画像を画像ごとに提示するときに単一の静的画像を繰り返し提示することを行うように構成された、条項６２に記載のデバイス。

【0192】

[0183]条項６４：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、ペイロードタイプが、１つまたは複数の画像が画像シーケンスを含むことを示すとき、画像シーケンスの画像を、シーン画像の対応する画像と一緒に順序通り提示することを行うように構成された、条項６２に記載のデバイス。

【0193】

[0184]条項６５：ＳＤＰ画像属性は、オーバーレイ画像がシーンデータのフレームとともに提示されるべきである限り、オーバーレイ画像が連続的に再送信されるかどうかを示す送信モード属性を含む、条項６１に記載のデバイス。

【0194】

[0185]条項６６：ＳＤＰ画像属性は、オーバーレイ画像がループで繰り返し提示されるべきであるかどうかを示すデータを含む、条項６１に記載のデバイス。

【0195】

[0186]条項６７：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、データが、オーバーレイ画像がループで繰り返し提示されるべきであることを示すとき、オーバーレイ画像が画像シーケンス中にＮ個の画像を含むと決定することと、Ｎが正の整数である、ｊが非負整数である、ループ数ｊについて、時間ｊ＊Ｎ＋ｉにおいてオーバーレイ画像の画像シーケンスの画像ｉを提示することと、ｉがオーバーレイ画像の画像シーケンスのｉ番目の画像に対応する、を行うように構成された、条項６６に記載のデバイス。

【0196】

[0187]条項６８：ＳＤＰ画像属性は、オーバーレイ画像が受信の後にローカルに記憶されるべきであるかどうかを示すデータを含む、条項６１に記載のデバイス。

【0197】

[0188]条項６９：１つまたは複数のプロセッサは、データが、オーバーレイ画像が受信の後にローカルに記憶されるべきであることを示すとき、オーバーレイ画像をメモリに記憶することを行うようにさらに構成され、ここにおいて、シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサが、メモリからオーバーレイ画像を取り出すことと、取り出されたオーバーレイ画像を提示することとを行うように構成された、条項６８に記載のデバイス。

【0198】

[0189]条項７０：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、データが、オーバーレイ画像が再送信されることになることを示すとき、オーバーレイ画像の再送信されたバージョンを受信することと、オーバーレイ画像の再送信されたバージョンを提示することとを行うように構成された、条項６８に記載のデバイス。

【0199】

[0190]条項７１：命令を記憶したコンピュータ可読記憶媒体であって、命令は、実行されたとき、プロセッサに、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行わせる、コンピュータ可読記憶媒体。

【0200】

[0191]条項７２：メディアデータを受信するためのデバイスであって、デバイスは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信するための手段と、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信するための手段と、１つまたは複数のシーン画像を含むシーンデータを受信するための手段と、シーン画像とオーバーレイ画像とを提示するための手段とを備える、デバイス。

【0201】

[0192]条項７３：メディアデータを取り出す方法であって、方法は、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを備える、方法。

【0202】

[0193]条項７４：ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することをさらに備える、条項７３に記載の方法。

【0203】

[0194]条項７５：ＳＤＰ画像属性は、１つまたは複数のオーバーレイ画像が単一の静的画像を含むのか画像シーケンスを含むのかを示すペイロードタイプを示す画像属性を含む、条項７４に記載の方法。

【0204】

[0195]条項７６：ペイロードタイプが、１つまたは複数の画像が単一の静的画像を含むことを示すとき、シーン画像とオーバーレイ画像とを提示することが、シーン画像を画像ごとに提示するときに単一の静的画像を繰り返し提示することを備える、条項７５に記載の方法。

【0205】

[0196]条項７７：ペイロードタイプが、１つまたは複数の画像が画像シーケンスを含むことを示すとき、シーン画像とオーバーレイ画像とを提示することが、画像シーケンスの画像を、シーン画像の対応する画像と一緒に順序通り提示することを備える、条項７５に記載の方法。

【0206】

[0197]条項７８：ＳＤＰ画像属性は、オーバーレイ画像がシーンデータのフレームとともに提示されるべきである限り、オーバーレイ画像が連続的に再送信されるかどうかを示す送信モード属性を含む、条項７４から７７のいずれかに記載の方法。

【0207】

[0198]条項７９：ＳＤＰ画像属性は、オーバーレイ画像がループで繰り返し提示されるべきであるかどうかを示すデータを含む、条項７４から７８のいずれかに記載の方法。

【0208】

[0199]条項８０：データが、オーバーレイ画像がループで繰り返し提示されるべきであることを示すとき、シーン画像とオーバーレイ画像とを提示することは、オーバーレイ画像が画像シーケンス中にＮ個の画像を含むと決定することと、Ｎが正の整数である、ｊが非負整数である、ループ数ｊについて、時間ｊ＊Ｎ＋ｉにおいてオーバーレイ画像の画像シーケンスの画像ｉを提示することと、ｉがオーバーレイ画像の画像シーケンスのｉ番目の画像に対応する、を備える、条項７９に記載の方法。

【0209】

[0200]条項８１：ＳＤＰ画像属性は、オーバーレイ画像が受信の後にローカルに記憶されるべきであるかどうかを示すデータを含む、条項７４から８０のいずれかに記載の方法。

【0210】

[0201]条項８２：データが、オーバーレイ画像が受信の後にローカルに記憶されるべきであることを示すとき、方法が、オーバーレイ画像をローカルメモリに記憶することをさらに備え、ここにおいて、シーン画像とオーバーレイ画像とを提示することが、ローカルメモリからオーバーレイ画像を取り出すことと、取り出されたオーバーレイ画像を提示することとを備える、条項８１に記載の方法。

【0211】

[0202]条項８３：データが、オーバーレイ画像が再送信されることになることを示すとき、シーン画像とオーバーレイ画像とを提示することが、オーバーレイ画像の再送信されたバージョンを受信することと、オーバーレイ画像の再送信されたバージョンを提示することとを備える、条項８１に記載の方法。

【0212】

[0203]条項８４：ＳＤＰ画像属性が、オーバーレイ画像中に含まれる画像の数を示すデータを含む、条項７４から８３のいずれかに記載の方法。

【0213】

[0204]条項８５：１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むかどうかと、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むかどうかとを示す、ビットストリームのためのデータを受信することをさらに備える、条項７３から８４のいずれかに記載の方法。

【0214】

[0205]条項８６：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の画像シーケンスを含むことを示すとき、画像シーケンスの各々中の画像の数を示す、ビットストリームのためのデータを受信することをさらに備える、条項８５に記載の方法。

【0215】

[0206]条項８７：データが、１つまたは複数のオーバーレイ画像が１つまたは複数の静止画像を含むことを示すとき、静止画像の数を示す、ビットストリームのためのデータを受信することをさらに備える、条項８５および８６のいずれかに記載の方法。

【0216】

[0207]条項８８：画像シーケンスと静止画像とのための送信モードを表すデータを受信することをさらに備える、条項８５から８７のいずれかに記載の方法。

【0217】

[0208]条項８９：送信モードのうちの１つが「結合」であるとき、ビットストリームのタイムスタンプデータからオーバーレイ画像のための表示時間を決定することをさらに備える、条項８８に記載の方法。

【0218】

[0209]条項９０：タイムスタンプデータが、リアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプデータを備える、条項８９に記載の方法。

【0219】

[0210]条項９１：送信モードのうちの１つが「分離」であるとき、オーバーレイ画像のための表示時間を表すデータを別々に受信することと、別々に受信されたデータからオーバーレイ画像のための表示時間を決定することとをさらに備える、条項８８に記載の方法。

【0220】

[0211]条項９２：１つまたは複数のオーバーレイ画像が２つまたはそれ以上のオーバーレイ画像を含むとき、オーバーレイ画像の表示順序を表すデータを受信することをさらに備える、条項７３から９１のいずれかに記載の方法。

【0221】

[0212]条項９３：ビットストリームからオーバーレイ画像の各々のための画像メタデータを受信することをさらに備え、メタデータが、画像次元または画像役割のうちの１つまたは複数を示す、条項７３から９２のいずれかに記載の方法。

【0222】

[0213]条項９４：画像役割が、カバー画像、サムネイル画像、補助画像、マスタ画像、隠し画像、あらかじめ計算された導出された画像、コード化画像、または導出された画像のうちの少なくとも１つを備える、条項９３に記載の方法。

【0223】

[0214]条項９５：メタデータは、オーバーレイ画像の提示の順序を示す順序要素、またはオーバーレイ画像のうちの対応する１つが表示されるべきである時間の量を示す持続時間要素のうちの１つまたは複数を含む、条項９３および９４のいずれかに記載の方法。

【0224】

[0215]条項９６：メディアデータを取り出すためのデバイスであって、デバイスが、シーンデータと画像データとを記憶するように構成されたメモリと、回路中に実装された１つまたは複数のプロセッサとを備え、１つまたは複数のプロセッサは、ビットストリームが１つまたは複数のオーバーレイ画像を含むことを示す、ビットストリームのためのデータを受信することと、オーバーレイ画像が、シーンデータのフレームとともにフレームごとに提示される間、不変のままである、シーンデータとともに提示されるべき単一の静的画像、または、シーンデータのフレームとともにフレームごとに提示される間、規則的周期性で繰り返す画像シーケンスのいずれかを備える、ビットストリームから１つまたは複数のオーバーレイ画像を受信することと、１つまたは複数のシーン画像を含むシーンデータを受信することと、シーン画像とオーバーレイ画像とを提示することとを行うように構成された、デバイス。

【0225】

[0216]条項９７：１つまたは複数のプロセッサが、ビットストリームを識別するセッション記述プロトコル（ＳＤＰ）画像属性を受信することを行うようにさらに構成された、条項９６に記載のデバイス。

【0226】

[0217]条項９８：ＳＤＰ画像属性は、１つまたは複数のオーバーレイ画像が単一の静的画像を含むのか画像シーケンスを含むのかを示すペイロードタイプを示す画像属性を含む、条項９７に記載のデバイス。

【0227】

[0218]条項９９：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、ペイロードタイプが、１つまたは複数の画像が単一の静的画像を含むことを示すとき、シーン画像を画像ごとに提示するときに単一の静的画像を繰り返し提示することを行うように構成された、条項９８に記載のデバイス。

【0228】

[0219]条項１００：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、ペイロードタイプが、１つまたは複数の画像が画像シーケンスを含むことを示すとき、画像シーケンスの画像を、シーン画像の対応する画像と一緒に順序通り提示することを行うように構成された、条項９８に記載のデバイス。

【0229】

[0220]条項１０１：ＳＤＰ画像属性は、オーバーレイ画像がシーンデータのフレームとともに提示されるべきである限り、オーバーレイ画像が連続的に再送信されるかどうかを示す送信モード属性を含む、条項９７から１００のいずれかに記載のデバイス。

【0230】

[0221]条項１０２：ＳＤＰ画像属性は、オーバーレイ画像がループで繰り返し提示されるべきであるかどうかを示すデータを含む、条項１０１に記載のデバイス。

【0231】

[0222]条項１０３：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、データが、オーバーレイ画像がループで繰り返し提示されるべきであることを示すとき、オーバーレイ画像が画像シーケンス中にＮ個の画像を含むと決定することと、Ｎが正の整数である、ｊが非負整数である、ループ数ｊについて、時間ｊ＊Ｎ＋ｉにおいてオーバーレイ画像の画像シーケンスの画像ｉを提示することと、ｉがオーバーレイ画像の画像シーケンスのｉ番目の画像に対応する、を行うように構成された、条項１０２に記載のデバイス。

【0232】

[0223]条項１０４：ＳＤＰ画像属性は、オーバーレイ画像が受信の後にローカルに記憶されるべきであるかどうかを示すデータを含む、条項９７から１０３のいずれかに記載のデバイス。

【0233】

[0224]条項１０５：１つまたは複数のプロセッサは、データが、オーバーレイ画像が受信の後にローカルに記憶されるべきであることを示すとき、オーバーレイ画像をメモリに記憶することを行うようにさらに構成され、ここにおいて、シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサが、メモリからオーバーレイ画像を取り出すことと、取り出されたオーバーレイ画像を提示することとを行うように構成された、条項１０４に記載のデバイス。

【0234】

[0225]条項１０６：シーン画像とオーバーレイ画像とを提示するために、１つまたは複数のプロセッサは、データが、オーバーレイ画像が再送信されることになることを示すとき、オーバーレイ画像の再送信されたバージョンを受信することと、オーバーレイ画像の再送信されたバージョンを提示することとを行うように構成された、条項１０４および１０５のいずれかに記載のデバイス。

【0235】

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

【0236】

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

【0237】

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

【0238】

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

【0239】

[0230]様々な例が説明された。これらおよび他の例は以下の特許請求の範囲内に入る。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】