JP2022551436A - Ｄａｓｈセグメントの再同期点におけるランダムアクセス - Google Patents

Abstract

メディアを取り出すためのデバイスは、メディアプレゼンテーションのメディアデータを記憶するように構成されたメモリと、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、再同期点において開始する表現のメディアデータを取り出す要求を形成するためにマニフェストファイルを使用することと、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送ることと、取り出されたメディアデータを提示することとを行うように構成される、回路内に実装された１つまたは複数のプロセッサとを含む。

Description

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

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

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

[0004]ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために、空間的予測および／または時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスは、マクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化（Ｉ）フレームまたはスライス中のマクロブロックは、隣接マクロブロックに関する空間的予測を使用して符号化される。インターコード化（ＰまたはＢ）フレームまたはスライス中のマクロブロックは、同じフレームもしくはスライス中の隣接マクロブロックに関する空間的予測、または他の参照フレームに関する時間的予測を使用し得る。

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

[0006]概して、本開示は、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）および／または共通メディアアクセスフォーマット（ＣＭＡＦ）において、セグメントの開始時だけでなく、セグメント内の他の場所で（たとえば、ランダムアクセスのために）セグメントのデータにアクセスするための技法について説明する。本開示はまた、セグメント内でランダムアクセスを実行する能力をシグナリングすることに関する技法について説明する。本開示は、これらの技法に関する様々な使用事例について説明する。たとえば、本開示は、ＤＡＳＨおよびＩＳＯベースメディアファイルフォーマット（ＢＭＦＦ）における再同期（ｒｅｓｙｎｃ）点と再同期点のシグナリングとを定義する。

[0007]一例では、メディアデータを取り出す方法は、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、マニフェストファイルを使用して、再同期点において開始する表現のメディアデータを取り出す要求を形成することと、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送ることと、取り出されたメディアデータを提示することとを含む。

[0008]別の例では、メディアデータを取り出すためのデバイスは、メディアプレゼンテーションのメディアデータを記憶するように構成されたメモリと、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、再同期点において開始する表現のメディアデータを取り出す要求を形成するためにマニフェストファイルを使用することと、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送ることと、取り出されたメディアデータを提示することとを行うように構成される、回路内に実装された１つまたは複数のプロセッサとを含む。

[0009]別の例では、コンピュータ可読記憶媒体は、実行されたとき、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、再同期点において開始する表現のメディアデータを取り出す要求を形成するためにマニフェストファイルを使用することと、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送ることと、取り出されたメディアデータを提示することとをプロセッサに行わせる命令をその上に記憶した。

[0010]別の例では、メディアデータを取り出すためのデバイスは、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すための手段と、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、マニフェストファイルを使用して、再同期点において開始する表現のメディアデータを取り出す要求を形成するための手段と、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送るための手段と、取り出されたメディアデータを提示するための手段とを含む。

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

[0012]ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図。 [0013]取出しユニットの構成要素の例示的なセットを示すブロック図。 [0014]例示的なマルチメディアコンテンツの要素を示す概念図。 [0015]表現のセグメントに対応し得る、例示的なビデオファイルの要素を示すブロック図。 [0016]本開示による、第１の使用事例において使用され得る例示的な低レイテンシアーキテクチャを示す概念図。 [0017]図５に関して説明された使用事例の一例をさらに詳細に示す概念図。 [0018]ブロードキャストプロトコルのコンテキストにおいてＤＡＳＨおよびＣＭＡＦランダムアクセスを使用する例示的な第２の仕様事例を示す概念図。 [0019]マニフェストファイル中のストリームアクセスポイント（ＳＡＰ）の例示的なシグナリングを示す概念図。 [0020]本開示の技法による、メディアデータを取り出す例示的な方法を示すフローチャート。

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

[0022]ＨＴＴＰストリーミングでは、頻繁に使用される動作は、ＨＥＡＤと、ＧＥＴと、部分ＧＥＴとを含む。ＨＥＡＤ動作は、所与のユニフォームリソースロケータ（ＵＲＬ）またはユニフォームリソースネーム（ＵＲＮ）に関連付けられたペイロードを取り出すことなく、ＵＲＬまたはＵＲＮに関連付けられたファイルのヘッダを取り出す。ＧＥＴ動作は、所与のＵＲＬまたはＵＲＮに関連付けられたファイル全体を取り出す。部分ＧＥＴ動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続するいくつかのバイトを取り出し、バイトの数は、受信されたバイト範囲に対応する。したがって、部分ＧＥＴ動作は１つまたは複数の個々のムービーフラグメントを得ることができるので、ＨＴＴＰストリーミングのためのムービーフラグメントが与えられ得る。ムービーフラグメント中に、異なるトラックのいくつかのトラックフラグメントが存在し得る。ＨＴＴＰストリーミングでは、メディアプレゼンテーションは、クライアントがアクセス可能であるデータの構造化された集合であり得る。クライアントは、ストリーミングサービスをユーザに提示するために、メディアデータ情報を要求し、ダウンロードし得る。

[0023]ＨＴＴＰストリーミングを使用して３ＧＰＰデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび／またはオーディオデータに関する複数の表現が存在し得る。以下で説明されるように、異なる表現は、異なるコーディング特性（たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル）、異なるコーディング規格もしくはコーディング規格の拡張（マルチビューおよび／またはスケーラブル拡張など）、または異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述（ＭＰＤ）データ構造において定義され得る。メディアプレゼンテーションは、ＨＴＴＰストリーミングクライアントデバイスがアクセス可能であるデータの構造化された集合に対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、ストリーミングサービスをクライアントデバイスのユーザに提示するために、メディアデータ情報を要求し、ダウンロードし得る。メディアプレゼンテーションは、ＭＰＤの更新を含み得るＭＰＤデータ構造中に記述され得る。

[0024]メディアプレゼンテーションは、１つまたは複数の期間のシーケンスを含み得る。各期間は、次の期間の開始まで、または最後の期間の場合、メディアプレゼンテーションの終了まで継続し得る。各期間は、同じメディアコンテンツにおいて１つまたは複数の表現を含み得る。表現は、オーディオ、ビデオ、タイムドテキスト、または他のそのようなデータのいくつかの代替的な符号化バージョンのうちの１つであり得る。表現は、符号化タイプによって、たとえば、ビデオデータの場合、ビットレート、解像度、および／またはコーデックによって、オーディオデータの場合、ビットレート、言語、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された符号化オーディオデータまたはビデオデータのセクションを指すために使用され得る。

[0025]特定の期間の表現は、表現が属する適応セットを示すＭＰＤ中の属性によって示されるグループに割り当てられ得る。同じ適応セット中の表現は、一般に、クライアントデバイスが、たとえば、帯域幅適応を実行するために、これらの表現の間で動的におよびシームレスに切り替えることができるという点で、互いに代替物と見なされる。たとえば、特定の期間のビデオデータの各表現は、対応する期間のマルチメディアコンテンツのビデオデータまたはオーディオデータなどのメディアデータを提示するために復号するのに表現のいずれかが選択され得るように、同じ適応セットに割り当てられ得る。１期間内のメディアコンテンツは、いくつかの例では、存在する場合、グループ０からの１つの表現、または各非ゼログループからの多くとも１つの表現の組合せのいずれかによって表され得る。期間の各表現についてのタイミングデータは、期間の開始時間に対して表現され得る。

[0026]表現は、１つまたは複数のセグメントを含み得る。各表現は初期化セグメントを含むことがあり、または表現の各セグメントは自己初期化していることがある。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含み得る。概して、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソースネーム（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ）などの識別子によって一意に参照され得る。ＭＰＤは、各セグメントに識別子を与え得る。いくつかの例では、ＭＰＤはまた、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能なファイル内のセグメントのためのデータに対応し得るバイト範囲をｒａｎｇｅ属性の形態で与え得る。

[0027]異なる表現は、異なるタイプのメディアデータの実質的に同時の取出しのために選択され得る。たとえば、クライアントデバイスは、セグメントを取り出す、オーディオ表現と、ビデオ表現と、タイムドテキスト表現とを選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適応を実行するための特定の適応セットを選択し得る。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および／またはタイムドテキストを含む適応セットを選択し得る。代替的に、クライアントデバイスは、あるタイプのメディア（たとえば、ビデオ）の適応セットを選択し、他のタイプのメディア（たとえば、オーディオおよび／またはタイムドテキスト）の表現を直接選択し得る。

[0028]低レイテンシ動的適応ストリーミングオーバーＨＴＴＰ（ＬＬ－ＤＡＳＨ）は、低レイテンシでＤＡＳＨクライアントにメディアデータを提供することを試みるＤＡＳＨのためのプロファイルである。ＬＬ－ＤＡＳＨのためのいくつかの技術が、以下に簡単に要約される。
・符号化は断片化されたＩＳＯ ＢＭＦＦファイルに基づき、典型的には、ＣＭＡＦフラグメントおよびＣＭＡＦチャンクが仮定される。
・各チャンクは、ＤＡＳＨパッケージャによって個々にアクセス可能であり、オリジンサーバにアップロードされるＨＴＴＰチャンクにマッピングされる。この１対１マッピングは、低レイテンシ動作のための推奨であるが、要件ではない。クライアントは、この１対１マッピングがクライアントに保存されていると決して仮定すべきでない。
・セグメントが完成される前にクライアントがセグメントにアクセスすることができるように、部分的に利用可能なセグメントの低遅延プロトコル、たとえばＨＴＴＰチャンク転送符号化が使用される。利用可能開始時間は、この機能を利用することができるクライアントのために調整される。
・次の２つの動作モードが許可される。

○簡単なライブ提供物が、＠ｄｕｒａｔｉｏｎシグナリングおよび＄Ｎｕｍｂｅｒ＄ベースのテンプレート化を適用することによって使用される。

○＄Ｎｕｍｂｅｒ＄または＄Ｔｉｍｅ＄のいずれかとしてＳｅｇｍｅｎｔＴｉｍｅｌｉｎｅを有するメインライブ提供物は、ＤＡＳＨ第４版において提案された更新によってサポートされる。
・ＭＰＤ有効性満了イベントは、使用され得るが、クライアントによって理解されるのに必須ではない。
・一般に、帯域内イベントメッセージは存在し得るが、クライアントは、任意のチャンクにおいてではなく、セグメントの開始時にそれらを回復することのみが期待される。ＤＡＳＨパッケージャは、チャンク境界において、またはタイムドメタデータトラックを使用して完全に非同期的に、エンコーダから通知を受信し得る。
・単一のメディアプレゼンテーションにおいて、メディアプレゼンテーションの１期間内に、チャンク化された低レイテンシモードを使用している適応セットと、異なるメディアタイプに短いセグメントを使用する適応セットとを有することが許可される。
・メディアパイプライン上のＤＡＳＨクライアントの一定量の再生制御は、利用可能であり得、ＤＡＳＨクライアントのロバスト性のために使用されるべきである。たとえば、再生は、ある時間期間の間、加速または減速され得るか、またはＤＡＳＨクライアントは、セグメントへのシークを実行し得る。
・システムは、標準ＨＴＴＰ／１．１で実行可能であるように設計されるが、低レイテンシ動作の改善のためにＨＴＴＰ拡張および他のプロトコルにも適用可能であるべきである。
・ＭＰＤは、サービス構成およびサービスプロパティ（たとえば、サービスのターゲットレイテンシを含む）における明示的なシグナリングを含む。
・ＭＰＤおよび場合によってはセグメントも、ＤＡＳＨクライアントが、ライブと比較して現在のレイテンシを測定し、サービス期待値を満たすように調整することを可能にするアンカー時間を含む。
・たとえば、動作上のロバスト性は、たとえば、エンコーダ故障の場合に対象とされる。
・既存のＤＲＭおよび暗号化モードは、提案された低レイテンシ動作に適合する。

[0029]上記の高レベルの概要に基づいて、次のものが定義される。セグメントは、セグメント境界だけでなく、セグメント内でも表現にランダムにアクセスするために使用され得る。そのようなランダムアクセスが与えられる場合、これは、ＭＰＤにおいてシグナリングされるべきである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0066]本開示の技法によれば、コンテンツ作成デバイス２０および／またはサーバデバイス６０は、ＤＡＳＨ／ＣＭＡＦセグメント中に追加のランダムアクセスポイントを追加し得る。ランダムアクセスは、ファイルフォーマット解析時に再同期のみを与えるまでずっと、クリーンランダムアクセスと、オープンなまたは漸進的なデコーダリフレッシュとを含む。これは、再同期および復号がこの時点で開始され得るという情報を提供するチャンク境界と、以下のランダムアクセスポイントのタイプに関するシグナリングとを提供することによって対処され得る。ｔｆｄｔの利用可能性は、ｍｏｏｆヘッダ情報および場合によっては初期化セグメントの使用とともに、プレゼンテーション時間レベルでの時間再同期を可能にする。本開示では、この新しい点を「再同期点」と呼ぶ。すなわち、再同期点は、ファイルレベルコンテナ（たとえば、ＩＳＯ ＢＭＦＦ中のボックス）が適切に解析され得る点を表し、それに続いて、メディアデータ中のランダムアクセスポイント（たとえば、Ｉフレーム）が発生する。したがって、クライアントデバイス４０は、たとえば、これらのランダムアクセスポイントのうちの１つにおいて、マルチメディアコンテンツ６４にランダムにアクセスし得る。

[0067]コンテンツ作成デバイス２０および／またはサーバデバイス６０はまた、各ＤＡＳＨセグメントにおけるランダムアクセスポイントと再同期との利用可能性を示すとともに、ランダムアクセスポイントのロケーションと、タイプと、タイミングとに関する情報を提供する、マニフェストファイル６６（たとえば、ＭＰＤ）中に適切なシグナリングを追加し得る。コンテンツ作成デバイス２０および／またはサーバデバイス６０は、場合によっては、ランダムアクセスの位置、タイミング、タイプ、ならびに、情報が正確であるかまたは推定であるかに関する特性を追加して、追加の再同期点がセグメント中で利用可能であることを示す、マニフェストファイル６６（ＭＰＤ）中のシグナリングを提供し得る。したがって、クライアントデバイス４０は、そのようなランダムアクセスポイントが利用可能であるかどうかを決定し、それに応じて取出しと再生とを再同期させるために、このシグナリングされたデータを使用し得る。

[0068]クライアントデバイス４０は、任意の開始点の場合、再同期点を見つけることによって、カプセル化解除と、解読と、復号とに再同期する能力を用いて構成され得る。コンテンツ作成デバイス２０および／またはサーバデバイス６０は、ＣＭＡＦ ＴＵＣにおいて対処される上記の要件を満たす適切なチャンクを提供し得る。異なるタイプが、後に定義され得る。

[0069]クライアントデバイス４０は、たとえば、ＨＴＭＬ－５／ＭＳＥベースの再生において利用可能であるように、制限された受信機環境において処理を開始するように構成され得る。この問題は、受信機実装形態を通して対処され得る。しかしながら、データ構造、タイミング、およびタイプにおける再同期点のマップを得る能力を有する受信機パイプラインに再同期トリガおよび情報を提供することが適切であり、それは、復号パイプラインのユーザがランダムアクセスポイントにおいて再生を初期化することを可能にする。

[0070]さらに、後方互換性があるマニフェストファイル６６中のシグナリングが提供され得る。シグナリングを解析する能力を用いて構成されないクライアントデバイスは、シグナリングを無視し、上記で説明した方法を実行し得る。さらに、マニフェストファイル６６は、適応セットレベルでのシグナリングを可能にするために、位置を＠ｂａｎｄｗｉｄｔｈの値に関連付けるシグナリングを含み得る。

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

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

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

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

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

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

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

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

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

[0080]本開示の技法によれば、ＭＰＤ１２２（同じく、図１のマニフェストファイル６６に対応し得る）は、上記で説明した問題に対処するためのシグナリングを含み得る。たとえば、表現１２４（および場合によっては適応セットレベルでデフォルト設定される）の各々に関して、ＭＰＤ１２２は、（後方互換性を可能にし得る）１つまたは複数の再同期要素を含み得る。各再同期要素は、表現１２４のうちの対応する１つの中のセグメント１２８、１３２の各々について、以下が成り立つことを示し得る。
・＠ｔｙｐｅまたはそれよりも小さい（しかし０よりも大きい）ストリームアクセスポイント（ＳＡＰ）タイプの再同期点は、＠ｄＴによってシグナリングされる最大デルタＴと、＠ｄＩｍａｘによってシグナリングされる最大バイトオフセット差と、＠ｄＩｍｉｎによってシグナリングされる最小バイトオフセット差とを有する各セグメント内に存在し、＠ｄＩｍａｘおよび＠ｄＩｍｉｎの値の両方は、値を得るために、この表現に割り当てられた＠ｂａｎｄｗｉｄｔｈ属性の値によって乗算される必要がある。「デルタＴ」は、表現の＠ｔｉｍｅｓｃａｌｅの単位での再同期点に続く任意のデータの最も早いプレゼンテーション時間の差を指す。＠ｔｙｐｅが０に設定される場合、コンテナおよび解読レベルに関する再同期のみが保証される。
・再同期マーカーフラグ＠ｍａｒｋｅｒは、使用中のセグメントフォーマットによって定義される再同期パターンを使用して、再同期点ごとに再同期点が含まれることを示すように設定され得る。
・複数の再同期要素が、異なるＳＡＰタイプに関して存在し得る。
・再同期点は、メディアの処理が、ＣＭＡＦヘッダ／初期化セグメントとの組合せで、ＩＳＯ ＢＭＦＦおよび解読情報上で起こり得ることを要求する。

[0081]再同期点の例示的な使用は、以下の図８に関して説明される。

[0082]再同期要素がＭＰＤ１２２において提供され、セグメントがＩＳＯ ＢＭＦＦまたはＣＭＡＦに基づくセグメント１２８、１３２のいずれかに関して、以下が成立し得る。
・セグメントは、以下に定義される１つまたは複数のチャンクのシーケンスであり得る。
・さらに、要素において指定された＠ｔｙｐｅのセグメント中の任意の２つの連続する再同期点に関して、以下が成立し得る。
○２つのうちの最も早いプレゼンテーション時間の差は、多くとも＠ｄＴの値であり得る。

○開始からのバイトオフセットの差は、多くとも、＠ｂａｎｄｗｉｄｔｈ値で正規化された＠ｄＩｍａｘであり得る。

○開始からのバイトオフセットの差は、少なくとも、＠ｂａｎｄｗｉｄｔｈ値で正規化された＠ｄＩｍｉｎであり得る。
・再同期マーカーフラグが設定される場合、各再同期点は、再同期ボックス／ｓｔｙｐを含み得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0097]一例では、本開示は、下記の表において次のように「チャンク」を定義する。この表は、チャンクの基数と順序性の両方の例示的な定義を提供する。

[0098]一例では、本開示は、再同期点をチャンクの開始として定義する。さらに、再同期点は、以下のプロパティを割り当てられ得る。
・それは、チャンクの第１のバイトを指す、セグメントの開始からのバイトオフセットを有する。
・それは、ｍｏｏｆ中の情報と、場合によってはそれに割り当てられたムービーヘッダとから導出される最も早いプレゼンテーション時間を有する。
・それは、ＩＳＯ／ＩＥＣ１４４９６－１２において定義されているように、それに割り当てられたＳＡＰタイプを有する。
・チャンクが再同期ボックス（上記のｓｔｙｐ）を含むか否かの指示がある。
・再同期点から開始して、ムービーヘッダ中の情報とともに、ファイルフォーマット解析および解読が行なわれ得る。

[0099]いくつかの例では、マーカーのバイトストリームをスキャンすることによってセグメント（たとえば、ビデオファイル１５０）の開始への同期を可能にする再同期マーカーボックスが定義され得る。この再同期ボックスは、以下のプロパティを有し得る。
・それは、極めて高い尤度で再同期のための一意のパターンを定義する。
・それは、ＳＡＰタイプを定義する。

[0100]再同期マーカーボックスは新しいボックスであってもよいし、ｓｔｙｐボックスなどの既存のボックスを再利用してもよい。本開示では、特定の制限をもつｓｔｙｐが再同期マーカーボックスとして使用され得ることが、仮定される。この手法のロバスト性に関する研究が進行中である。

[0101]以下の図５～図７は、セグメントの開始以外の点におけるＤＡＳＨセグメントへのランダムアクセスが有用であり得るいくつかの使用事例を説明するために使用される。

[0102]図５は、本開示による、第１の使用事例において使用され得る例示的な低レイテンシアーキテクチャ２００を示す概念図である。すなわち、図５は、ＤＡＳＨ－ＩＦ ＩＯＰによって低レイテンシＤＡＳＨサービスを動作させるための情報の基本的な流れを示す。低レイテンシアーキテクチャ２００は、ＤＡＳＨパッケージャ２０２と、エンコーダ２１６と、コンテンツ配信ネットワーク（ＣＤＮ）２２０と、通常のＤＡＳＨクライアント２３０と、低レイテンシＤＡＳＨクライアント２３２とを含む。エンコーダ２１６は、概して、図１のオーディオエンコーダ２６とビデオエンコーダ２８とのいずれかまたは両方に対応し得るが、ＤＡＳＨパッケージャ２０２は、図１のカプセル化ユニット３０に対応し得る。

[0103]この例では、エンコーダ２１６は、ＣＨ２０８、ＣＭＡＦ初期チャンク２０６Ａ、２０６Ｂ（ＣＩＣ２０６）、およびＣＭＡＦ非初期チャンク２０４Ａ～２０４Ｄ（ＣＮＣ２０４）などのＣＭＡＦヘッダ（ＣＨ）を形成するために、受信されたメディアデータを符号化する。エンコーダ２１６は、ＤＡＳＨパッケージャ２０２に、ＣＨ２０８と、ＣＩＣ２０６と、ＣＮＣ２０４とを提供する。ＤＡＳＨパッケージャ２０２はまた、サービスの一般的な記述とエンコーダ２１６のエンコーダ構成とに関する情報を含むサービス記述を受信する。

[0104]ＤＡＳＨパッケージャ２０２は、メディアプレゼンテーション記述（ＭＰＤ）２１０と初期化セグメント２１２とを形成するために、サービス記述と、ＣＨ２０８と、ＣＩＣ２０６と、ＣＮＣ２０４とを使用する。ＤＡＳＨパッケージャ２０２はまた、セグメント２１４Ａ、２１４Ｂ（セグメント２１４）内にマップＣＨ２０８と、ＣＩＣ２０６と、ＣＮＣ２０４とを生成し、ＣＤＮ２２０に増分方式でセグメント２１４を提供する。ＤＡＳＨパッケージャ２０２は、セグメント２１４を、それらが生成されるときにチャンクの形態で配信し得る。ＣＤＮ２２０は、ＭＰＤ２１０と、ＩＳ２１２と、セグメント２１４とを記憶するためのセグメントストレージ２２２を含む。ＣＤＮ２２０は、たとえば、通常のＤＡＳＨクライアント２３０および低レイテンシＤＡＳＨクライアント２３２からのＨＴＴＰ Ｇｅｔまたは部分Ｇｅｔ要求に応答して、通常のＤＡＳＨクライアント２３０に完全なセグメントを配信するが、低レイテンシＤＡＳＨクライアント２３２に個々のチャンク（たとえば、ＣＨ２０８、ＣＩＣ２０６、およびＣＮＣ２０４）を配信する。

[0105]図６は、図５に関して説明された使用事例の一例をさらに詳細に示す概念図である。図６の例は、チャンク２５２Ａ～２５２Ｅ（チャンク２５２）のそれぞれのセットを含むセグメント２５０Ａ～２５０Ｅ（セグメント２５０）を示す。図１のクライアントデバイス４０などのクライアントデバイスは、完全なセグメント２５０または個々のチャンク２５２のいずれかを取り出し得る。たとえば、図５に示すように、通常のＤＡＳＨクライアント２３０は、セグメント２５０を取り出し得るが、低レイテンシＤＡＳＨクライアント２３２は、個々のチャンク２５２を（少なくとも最初に）取り出し得る。

[0106]図６は、完全なセグメント２５０ではなく個々のチャンク２５２を取り出すことによってレイテンシが低減され得る方法をさらに示す。たとえば、現在時間において完全なセグメントを取り出すことは、より高いレイテンシを引き起こし得る。直近の完全に利用可能なセグメントを単に取り出すことは、レイテンシを低減するが、依然として比較的高いレイテンシを生じさせ得る。

[0107]代わりにチャンクを取り出すことによって、これらのレイテンシが大幅に低減され得る。たとえば、図６において「今」によって示される現在時間において、セグメント２５０Ｅは、完全には形成されていない。それでも、クライアントデバイスは、チャンク２５２Ｅ－１および２５２Ｅ－２が形成され、取り出すために利用可能であると仮定すると、セグメント２５０Ｅが完全に形成される前であっても、セグメント２５０Ｅのチャンク２５２Ｅ－１および２５２Ｅ－２などの形成されたチャンクを取り出すことができる。

[0108]ライブストリームに参加するとき、典型的には、低レイテンシと高速始動の両方が達成されるべきである。しかしながら、これは自明ではなく、数個の戦略が、図６に基づいて以下に説明される。
・第１の事例では、ライブエッジにおいて、時間履歴が３セグメント（すなわち、セグメント２５０Ｂ、２５０Ｃ、および２５０Ｄ）後ろにあるセグメントがバッファにロードされる。１つのセグメントが利用可能になると、再生が開始される。これはかなりのレイテンシをもたらすが、再生は、セグメントの開始時におけるランダムアクセスがロードされるので、比較的迅速に開始することができる。
・第２の事例では、３セグメント古いセグメントの代わりに、最新の利用可能なセグメントであるセグメント２５０Ｄが選択される。この事例における再生レイテンシは、少なくともセグメント持続時間であるが、より長くてもよい。始動は、上記の事例と同様である可能性がある。
・他の３つの事例では、複数のチャンクを含むセグメント（たとえば、セグメント２５０Ｅ）が、まだ生成されている間に再生される。これはレイテンシを低減するが、特に最新の公開されたセグメントのセグメント利用可能開始時間と壁時計時間との差がターゲットレイテンシよりも大きい場合、再生の開始が影響を受け得るという問題が存在する。この事例では、クライアントデバイスは、次の秒が発出されるまで待たなければならない場合がある。６秒セグメントの事例では、これは、４～５秒の始動レイテンシをもたらし得る。
・他の技法および使用事例が存在する。たとえば、クライアントは、開始時に古いセグメントにアクセスし、すべてをダウンロードし、再生を加速し、早送り復号を行うことができる。しかしながら、そのような手法は、加速された復号が起こり得る前に有意なデータがダウンロードされる必要があるという欠点を有する。さらに、それは、デコーダインターフェースにおいて広くサポートされていない。

[0109]適切な解決策は、以下のものであり得る。
・適応セットの少なくとも１つの表現は、セグメント／フラグメント中に、より頻度が高いランダムアクセスポイントと非初期チャンクとを含む。
・ＤＡＳＨクライアントは、ＭＰＤからの情報を使用して、そのようなランダムアクセス方法が存在すると決定し得るが、ランダムアクセスポイントのロケーション／バイトオフセットは、正確にシグナリングされない場合がある。
・ＤＡＳＨクライアントは、始動時にこの表現にアクセスすることができるが、最新の利用可能な非初期チャンクのバイト範囲または少なくともそれに近いバイト範囲から開始してダウンロードするだけである。
・ＤＡＳＨクライアントは、ダウンロードされると、ランダムアクセスポイントを決定し、同じくダウンロードされた同じ表現の初期化セグメント／ＣＭＡＦヘッダとともにデータの処理を開始し得る。ランダムアクセスポイントの位置特定については、以下で説明される。

[0110]しかしながら、後者の手法は、以下に要約されるように、様々な問題に遭遇し得る。

[0111]したがって、図６の例に示され、以下で説明されるように、本開示で説明されるチャンクの使用は、レイテンシを実質的に低減し得る。チャンクの開始を事前にシグナリングすることは、頻繁な更新を必要としないが、チャンク内のストリームアクセスポイント（ＳＡＰ）の概略的なロケーションを依然として示すことができるマニフェストファイルが前もって生成されることを可能にし得る。このようにして、クライアントデバイスは、連続的なマニフェストファイル更新を必要とせず、マニフェストファイルを使用してチャンク境界のロケーションを決定することができるが、クライアントデバイスがチャンク境界の始めに、たとえば再同期点においてメディアストリーミングを開始することを依然として可能にする。すなわち、クライアントデバイスは、マニフェストファイルから、セグメントが完全に形成される前でも、再同期点を含むセグメントのバイト範囲を決定することができるが、それは、マニフェストファイルが、セグメント中の再同期点の概略的なロケーションを表すバイト範囲または他のデータをシグナリングすることができるからである。

[0112]図７は、ブロードキャストプロトコルのコンテキストにおいてＤＡＳＨおよびＣＭＡＦランダムアクセスを使用する例示的な第２の仕様事例を示す概念図である。図７は、メディアエンコーダ２８０と、ＣＭＡＦ／ファイルフォーマット（ＦＦ）パッケージャ２８２と、ＤＡＳＨパッケージャ２８４と、ＲＯＵＴＥセンダー２８６と、ＣＤＮオリジンサーバ２８８と、ＲＯＵＴＥ受信機２９０と、ＤＡＳＨクライアント２９２と、ＣＭＡＦ／ＦＦパーサ２９４と、メディアデコーダ２９６とを含む例を示す。メディアエンコーダ２８０は、オーディオデータまたはビデオデータなどのメディアデータを符号化する。メディアエンコーダ２８０は、図１のオーディオエンコーダ２６もしくはビデオエンコーダ２８、または図５のエンコーダ２１６に対応し得る。メディアエンコーダ２８０は、ＣＭＡＦ／ＦＦパッケージャ２８２に符号化メディアデータを提供し、ＣＭＡＦ／ＦＦパッケージャ２８２は、ＣＭＡＦとＩＳＯ ＢＭＦＦまたはその拡張などの特定のファイルフォーマットとに従って、符号化メディアデータをファイル内にフォーマットする。

[0113]ＣＭＡＦ／ＦＦパッケージャ２８２は、これらのファイル（たとえば、チャンク）をＤＡＳＨパッケージャ２８４に提供し、ＤＡＳＨパッケージャ２８４は、ファイル／チャンクをＤＡＳＨセグメント内にアグリゲートする。ＤＡＳＨパッケージャ２８４はまた、ファイル／チャンク／セグメントを記述するデータを含む、ＭＰＤなどのマニフェストファイルを形成し得る。さらに、本開示の技法によれば、ＤＡＳＨパッケージャ２８４は、将来のストリームアクセスポイント（ＳＡＰ）またはランダムアクセスポイント（ＲＡＰ）の近似的なロケーションを決定し、ＭＰＤ中で近似的なロケーションをシグナリングし得る。ＣＭＡＦ／ＦＦパッケージャ２８２およびＤＡＳＨパッケージャ２８４は、図１のカプセル化ユニット３０または図５のＤＡＳＨパッケージャ２０２に対応し得る。

[0114]ＤＡＳＨパッケージャ２８４は、ＭＰＤとともに、セグメントをＲＯＵＴＥセンダー２８６とＣＤＮオリジンサーバ２８８とに提供する。ＲＯＵＴＥセンダー２８６およびＣＤＮオリジンサーバ２８８は、図１のサーバデバイス６０または図５のＣＤＮ２２０に対応し得る。概して、ＲＯＵＴＥセンダー２８６は、この例では、ＲＯＵＴＥに従ってＲＯＵＴＥ受信機２９０にメディアデータを送ることができる。他の例では、ＦＬＵＴＥなどの、他のファイルベースの配信プロトコルが、ブロードキャストまたはマルチキャストのために使用され得る。追加または代替として、ＣＤＮオリジンサーバ２８８は、たとえば、ＨＴＴＰに従って、メディアデータをＲＯＵＴＥ受信機２９０に、および／または直接ＤＡＳＨクライアント２９２に送ることができる。

[0115]ＲＯＵＴＥ受信機２９０は、図２のｅＭＢＭＳミドルウェアユニット１００などのミドルウェア中に実装され得る。ＲＯＵＴＥ受信機２９０は、たとえば、図２に示されたキャッシュ１０４中で、受信されたメディアデータをバッファリングすることができる。ＤＡＳＨクライアント２９２（図２のＤＡＳＨクライアント１１０に対応し得る）は、ＨＴＴＰを使用してＲＯＵＴＥ受信機２９０から、キャッシュされたメディアデータを取り出すことができる。代替的に、ＤＡＳＨクライアント２９２は、上記で説明したように、ＨＴＴＰに従ってＣＤＮオリジンサーバ２８８から直接メディアデータを取り出し得る。

[0116]さらに、本開示の技法によれば、ＤＡＳＨクライアント２９２は、たとえば、マニフェストファイル中でシグナリングされた再同期点に続いて、ＳＡＰまたはＲＡＰのロケーションを決定するために、ＭＰＤなどのマニフェストファイルを使用し得る。ＤＡＳＨクライアント２９２は、次の最も早い再同期点から開始するメディアプレゼンテーションの取出しを始め得る。再同期点は、概して、ファイルコンテナレベルデータが正しく解析され得るビットストリームのロケーションを示し得る。したがって、ＤＡＳＨクライアント２９２は、再同期点において開始するストリーミングを始め、ＣＭＡＦ／ＦＦパーサ２９４に、再同期点から開始する受信されたメディアデータを配信し得る。

[0117]ＣＭＡＦ／ＦＦパーサ２９４は、再同期点から開始するメディアデータの解析を始めることができる。ＣＭＡＦ／ＦＦパーサ２９４は、図１のカプセル化解除ユニット５０に対応し得る。さらに、ＣＭＡＦ／ＦＦパーサ２９４は、解析されたデータから復号可能なメディアデータを抽出し、図１のオーディオデコーダ４６またはビデオデコーダ４８に対応し得るメディアデコーダ２９６に、復号可能なメディアデータを配信し得る。メディアデコーダ２９６は、メディアデータを復号し、復号されたメディアデータを、図１のオーディオ出力４２またはビデオ出力４４などの対応する出力デバイスに配信し得る。

[0118]ブロードキャストの事例では、ＤＡＳＨ／ＣＭＡＦとＲＯＵＴＥとの組合せの例が図７に示される。低レイテンシＤＡＳＨモードとＲＯＵＴＥとの組合せで（たとえば、ＡＢＲマルチキャストにおけるＤＶＢ ＴＭ－ＩＰＩタスクフォースと、ＡＴＳＣプロファイルとについて考慮されるように）、以下の問題が生じ得る。ＲＯＵＴＥ受信機２９０は、ＤＡＳＨ／ＣＭＡＦ低レイテンシセグメントの途中で参加する場合、同期が利用可能でなく、他の目的のためのランダムアクセスも存在しないので、データの処理を開始することができない。したがって、セグメントの途中でより頻度が高いランダムアクセスが提供される場合でも、始動は遅延される。

[0119]適切な解決策は、以下のものであり得る。
・ブロードキャスト／マルチキャスト表現は、セグメント／フラグメント中に、より頻度が高いランダムアクセスポイントと非初期チャンクとを含む。
・ＤＡＳＨクライアント２９２は、ＭＰＤの情報を使用して、および／または場合によってはＲＯＵＴＥ受信機２９０からの情報によって、そのようなランダムアクセス方法が存在すると決定する。ＤＡＳＨクライアント２９２は、そのような情報を正確に使用してランダムアクセスポイントの位置を特定し得るが、場合によってはそうしない。
・ＤＡＳＨクライアント２９２は、始動時にこの表現にアクセスすることができるが、開始からすべての情報にはアクセスできない場合がある。
・セグメントの受信された部分へのアクセスを開始すると、ＤＡＳＨクライアント２９２は、ランダムアクセスポイントを見つけ、同じ表現の同じくダウンロードされた初期化セグメント／ＣＭＡＦヘッダとともにデータの処理を開始し得る。ランダムアクセスポイントの位置特定については、以下で説明される。

[0120]しかしながら、後者の手法は、以下に要約されるように、様々な問題に遭遇し得る。

[0121]上記の第２の使用事例において説明したものと同様の事例では、ランダムアクセス再同期時だけでなく、パケットの損失も問題となり得る。この例示的な第３の使用事例では、上記で説明したものと同様の手順が適用され得る。これ以外に、クリーンランダムアクセスが試みられるだけでなく、十分なボックス解析が可能になった後に、非ランダムアクセスチャンク（たとえば、ＩＤＲフレームなし）におけるイベント、復号、およびプレゼンテーションが試みられ得る場合もあり得る。したがって、クリーンランダムアクセスへの再同期だけでなく、ファイルフォーマット解析へのランダムアクセスへの再同期も重要である。

[0122]さらに別の第４の使用事例は、典型的には、ライブメディアコンテンツが低レイテンシで配信されるが、次いで同じメディアコンテンツが遅延再生のために時間シフトして使用される場合に生じ得る。クライアントは、特定の時間にメディアプレゼンテーションにアクセスしたい場合があるが、この時間は、セグメント／ＣＭＡＦフラグメント開始と一致しない場合がある（一般には、一致しない）。

[0123]適切な解決策は、以下のものであり得る。
・適応セットの少なくとも１つの表現は、セグメント／フラグメント中に、より頻度が高いランダムアクセスポイントと非初期チャンクとを含み得る。
・ＤＡＳＨクライアント２９２は、ＭＰＤからの情報を使用して、そのようなランダムアクセス方法が存在すると決定し得るが、ランダムアクセスポイントのロケーション／バイトオフセットは、正確には知られていない場合がある。
・ＤＡＳＨクライアント２９２は、シーク時にこの表現にアクセスすることができるが、最新の利用可能な非初期チャンクのバイト範囲または少なくともそれに近いバイト範囲から開始するダウンロードだけが許可され得る。
・ＤＡＳＨクライアント２９２は、ダウンロードされると、ランダムアクセスポイントを見つけ、同じくダウンロードされた同じ表現の初期化セグメント／ＣＭＡＦヘッダとともにデータの処理を開始し得る。ランダムアクセスポイントの位置特定については、以下で説明される。

[0124]しかしながら、後者の手法は、以下に要約されるように、様々な問題に遭遇し得る。

[0125]ＩＳＯ ＢＭＦＦ／ＤＡＳＨ／ＣＭＡＦセグメントの事例の再同期は、一般に、以下に要約される複数のプロセスを含む。
１）ボックス構造を見つけること。
２）すべての関連情報を有するＣＭＡＦチャンク／フラグメントを見つけること。
３）ｍｄａｔおよびｔｆｄｔを介してタイミングを見つけること。
４）適用可能な場合、すべての解読関連情報を取得すること。
５）場合によってはイベントメッセージを処理すること。
６）エレメンタリストリームレベルで復号を開始すること。

[0126]特定の時間にボックス構造中の再同期点を見つける例示的な方法が、以下に要約される。
・セグメントインデックス（ＳＩＤＸボックス）がある場合、そのような再同期点は、プレゼンテーション時間およびバイトオフセットとして提供される。しかしながら、事前にセグメントが完全には形成されていないので、セグメントインデックスは、典型的には、低レイテンシライブのために利用可能ではない。
・セグメントの開始が利用可能である場合、クライアントは、ボックス構造が処理され得るように、バイト範囲の最小セットをダウンロードし得る。
・再同期は、たとえばチャンクの境界がシグナリングされ、クライアントが解析を開始し得ることを提供する基礎をなすプロトコルによって提供される。
・セグメントの開始が、シグナリングされたデータを通して容易に決定されることができない場合、クライアントは、クライアントがデータにランダムにアクセスすることを可能にする同期パターンを見つけることができる。次いで、クライアントは、解析を開始し、たとえば、ｅｍｓｇ、ｐｒｆｔ、ｍｄａｔ、ｍｏｏｆ、および／またはｍｄａｔなどの処理を可能にする適切なボックス構造を見つけることができる。

[0127]本開示は、上記の第４の例に適用され得る技法について説明する。最初の３つは、対応する情報が利用可能である場合の例示的な単純化を表す。

[0128]本開示は、上記の説明に基づく以下の問題と、これらの問題が解決策を必要とすることとを認識する。
１）ＤＡＳＨ／ＣＭＡＦセグメント中に追加のランダムアクセスポイントを追加すること。ランダムアクセスは、ファイルフォーマット解析時に再同期のみを与えるまでずっと、クリーンランダムアクセスと、オープンなまたは漸進的なデコーダリフレッシュとを含み得る。
２）各ＤＡＳＨセグメントにおけるランダムアクセスポイントと再同期との利用可能性を示すとともに、ランダムアクセスポイントのロケーションと、タイプと、タイミングとに関する情報を提供する、ＭＰＤ（または他のマニフェストファイル）中に適切なシグナリングを追加すること。情報は、正確であるか、または、ある範囲内であり得る。
３）任意の開始点の場合、再同期点を見つけることによって、カプセル化解除と、解読と、復号とに再同期する能力。
４）たとえば、ＨＴＭＬ－５／ＭＳＥベースの再生において利用可能であるように、制限された受信機環境において処理を開始する能力。

[0129]図８は、マニフェストファイル中のストリームアクセスポイント（ＳＡＰ）の例示的なシグナリングを示す概念図である。特に、図８は、ＳＡＰ３０２Ａ～３０２Ｄ（ＳＡＰ３０２）およびセグメント３０４Ａ～３０４Ｄ（セグメント３０４）を含むビットストリーム３００と、ＳＡＰ３１２Ａ～３１２Ｄ（ＳＡＰ３１２）、ＳＡＰ３１６Ａ～３１６Ｄ（ＳＡＰ３１６）、およびセグメント３１４Ａ～３１４Ｄ（セグメント３１４）を含むビットストリーム３１０とを示す。すなわち、この例では、ビットストリーム３１０のセグメント３１４は、ビットストリーム３００のセグメント３０４よりも頻度が高いＳＡＰ３１２、３１６を含む。ＳＡＰ３０２、３１２の各々は、セグメント３０４、３１４のうちの対応する１つの両方の開始と、これらのセグメントの第１のチャンクに対応し得る。ＳＡＰ３１６は、対応するセグメント３１６内のチャンクの開始には対応し得るが、対応するセグメント３１６の始めには対応しない。

[0130]１０００個のサンプルの等距離のチャンク（およびサンプル持続時間における＠ｔｉｍｅｓｃａｌｅ＝１０００）と、ＳＡＰタイプ１（これは、たとえばオーディオ表現であり得る）とを用いて一定のビットレート表現を達成するための単純な技法を提供するために、再同期要素は、以下を追加され得る。

[0131]そのような情報を受信するクライアント、たとえば、図１のクライアントデバイス４０は、＠ｄｕｒａｔｉｏｎ＝１００００のセグメントについて、ランダムアクセスポイントが正確なバイト範囲において毎秒アクセスされ得ることを識別することができない場合がある。ビットレートが可変である場合、受信機（たとえば、クライアントデバイス４０）は、ランダムアクセスポイントを見つけるべき範囲を識別するために、＠ｄＩＭｉｎと＠ｄＩＭａｘとを使用し得る。最大値をシグナリングする＠ｄＴの代替として、それはまた、公称チャンク持続時間をシグナリングし得る。

[0132]マニフェストファイルの再同期要素はまた、通常のセグメントと同じテンプレート関数を使用して、各セグメント中の再同期点のバイナリ再同期インデックスを指すＵＲＬ＠ｉｎｄｅｘを含み得る。この再同期は、存在する場合、セグメントインデックスと同様に、セグメント中のすべての再同期点の正確な位置を提供することができる。このインデックスが存在する場合、再同期インデックスは、マニフェストファイル／ＭＰＤの発出時間において利用可能である期間のすべてのセグメントについて利用可能であり得る。

[0133]１つの手法では、再同期インデックスは、セグメントインデックスと同一であり得るが、変更されてもよい。

[0134]図１のクライアントデバイス４０は、メディアファイル（たとえば、セグメントであり得る、図４のビデオファイル１５０）に再同期するための基礎としてＩＳＯ ＢＭＦＦ ４文字ボックスタイプを使用し得る。一例では、選択されたボックスタイプは、「ｓｔｙｐ」ボックスであるが、「ｍｏｏｆ」ボックス自体であってもよい。ボックス列タイプのランダムエミュレーションは、極めてまれである。ｓｔｙｐエミュレーションのテストレポートが、以下で説明される。次いで、このエミュレーションは、既知の予想されるボックスタイプに対してチェックすることによって回避される。クライアントデバイス４０は、次のように概説される再同期メカニズムを実行し得る。
１）たとえばバイトオフセットＢ１において、セグメント中の「ｓｔｙｐ」バイト列の出現を見つける。
２）次のようにランダムエミュレーションに対して検証する。次のボックスタイプが、予想されるボックスタイプのリスト、すなわち、「ｓｔｙｐ」、「ｓｉｄｘ」、「ｓｓｉｘ」、「ｐｒｆｔ」、「ｍｏｏｆ」、「ｍｄａｔ」、「ｆｒｅｅ」、「ｍｆｒａ」、「ｓｋｉｐ」、「ｍｅｔａ」、「ｍｅｃｏ」と比較される。

ａ．既知のボックスタイプのうちの１つが見つけられた場合、バイトオフセットＢ１－４バイトは、再同期点のバイトオフセットである。

ｂ．これが前述の既知のボックスタイプのうちの１つでない場合、ｓｔｙｐボックスのこの出現は、無効な同期点と見なされ、無視される。上記のステップ１から再開する。

[0135]本開示の技法は、スキャンされたＤＡＳＨ－ＩＦテストアセットからの３０，２８２個のセグメントにおいてテストされた。このスキャンは、ファイル中の「ｓｔｙｐ」列の２８，４０８回の出現を明らかにし、これらの２８，４０８回の出現のうちの１０回（２８４０回の出現のうちの約１回）のみは、次のボックスが予想されるボックスタイプ、すなわち、「ｓｔｙｐ」、「ｓｉｄｘ」、「ｓｓｉｘ」、「ｐｒｆｔ」、「ｍｏｏｆ」、「ｍｄａｔ」、「ｆｒｅｅ」、「ｍｆｒａ」、「ｓｋｉｐ」、「ｍｅｔａ」、「ｍｅｃｏ」のうちの１つではないと決定されると、破棄されるエミュレーションであった。

[0136]これらの結果に基づいて、チャンク構造とともにｓｔｙｐ再同期点検出を使用すれば十分であると考えられる。ｐｒｆｔ、ｅｍｓｇ、ｆｒｅｅ、ｓｋｉｐ、およびｍｏｏｆなどの、ｓｔｙｐに続き得るボックスのサブセットのみに制限することが適切である。

[0137]残りの問題は、ＳＡＰタイプと最も早いプレゼンテーション時間との決定である。後者は、ｔｆｄｔおよびムービーフラグメントヘッダ中の他の情報の使用によって容易に達成される。アルゴリズムを文書化することが適切である。

[0138]下記のように、ＳＡＰタイプを決定するためのいくつかのオプションがある。
・ｍｏｏｆ中の情報に基づく検出。簡単な技法が、文書化され実行され得る。
・ＳＡＰタイプにおける互換性ブランドの使用。すでにＣＭＡＦを使用することによって、以下のことが推論され得る。

○ｃｍｆｆ：ＳＡＰが１または２であることを示す
○ｃｍｆｌ：ＳＡＰが０であることを示す（これは解読に関して正しいか？）
○ｃｍｆｒ：ＳＡＰが１、２、または３であることを示す
・このシグナリングは、一貫して使用される場合、十分であり得る。他のＳＡＰタイプに対する互換性ブランドが定義され得る。
・ＳＡＰタイプを示すために、他の技法が使用され得る。

[0139]ＳＡＰタイプを決定するために、既存のオプションが使用され得る。

[0140]このようにして、本開示の技法は、次のように要約され得、上記で説明したように、図１のコンテンツ作成デバイス２０、サーバデバイス６０、および／またはクライアントデバイス４０などのデバイスによって実行され得る。

[0141]ＤＡＳＨコンテキストでは、ある事例では、セグメントは、ダウンロード、メディアプレゼンテーションへのアクセスのための単一のユニットとして扱われ、アドレス指定されたＵＲＬによっても扱われる。しかしながら、セグメントは、コンテナレベルでの再同期化と、セグメント内でもそれぞれの表現へのランダムアクセスとを可能にするように構造化され得る。再同期メカニズムは、再同期要素によってサポートされ、シグナリングされる。

[0142]再同期要素は、セグメント中の再同期点をシグナリングする。再同期点は、（バイト位置における）チャンクの開始であり、チャンクは、特定のプレゼンテーション持続時間のメディアデータを含むセグメント内の構造化された連続するバイト範囲として定義され、解読の可能性を含むコンテナフォーマット上で独立してアクセスされ得る。セグメント中の再同期点は、次のように定義され得る。
・再同期点は、チャンクの開始である。
・さらに、再同期点は、以下のプロパティを割り当てる。

○それは、チャンクの第１のバイトを指す、セグメントの開始からのバイトオフセットまたはインデックス値を有する。

○それは、表現において割り当てられた最も早いプレゼンテーション時間を有する。

○それは、たとえばＩＳＯ／ＩＥＣ１４４９６－１２におけるＳＡＰタイプによって定義された、割り当てられたＳＡＰタイプを有する。

○それは、特定のマーカーを通してセグメントを解析する間に再同期点が検出され得るかどうか、または再同期点が外部手段によってシグナリングされる必要があるかどうかを示すマーカープロパティを割り当てた。
・再同期点から処理を開始することは、初期化セグメント中の情報とともに、存在する場合、コンテナ解析および解読を可能にする。含まれるエレメンタリビデオストリームにアクセスすべきかどうか、および、それにどのようにアクセスすべきかの能力は、ＳＡＰタイプによって定義される。

[0143]ＭＰＤ中で各再同期点をシグナリングすることは、再同期点がＭＰＤ更新とは無関係にセグメントパッケージャによって追加され得るので、因果性の理由で困難であり得る。たとえば、再同期点は、ＭＰＤとは無関係にエンコーダとパッケージャとによって生成され得る。また、低レイテンシでは、ＭＰＤシグナリングは、ＤＡＳＨクライアント、たとえば、図２のＤＡＳＨクライアント１１０または図７のＤＡＳＨクライアント２９２にとって利用可能でない場合がある。したがって、ＭＰＤ中のセグメントにおいて提供される再同期点をシグナリングする２つの方法が存在する。
・各セグメントの再同期インデックスセグメント中の再同期点に関するバイナリマップを提供することによる。これは、ネットワーク上で完全に利用可能なセグメントに最も容易に使用される。
・セグメント中の再同期点の存在と、また、バイト位置およびプレゼンテーション時間に関して再同期点を容易に見つけることを可能にするいくつかの追加情報とをシグナリングすることによる。

[0144]上記の特性をシグナリングするために、再同期要素は、ＤＡＳＨ仕様の第５．３．１２．２節においてより詳細に説明される異なる属性を有する。

[0145]ランダムアクセスは、存在する場合、初期化セグメントを用いて表現を初期化し、シグナリングされたセグメント以降から表現を復号および提示することによって、時間ｔ以降のランダムアクセスポイントから表現の処理、復号、および提示を開始することを指す。ランダムアクセスポイントは、以下の表１０において定義されるように、ＲａｎｄｏｍＡｃｃｅｓｓ要素を用いてシグナリングされ得る。

[0146]表１１は、様々なランダムアクセスポイントタイプを提供する。

[0147]再同期インデックスセグメントは、メディアセグメントに関連する情報を含む。再同期インデックスセグメントは、セグメントインデックスと同様に、セグメント中のすべての再同期点の正確な位置を提供する。再同期点は、ＤＡＳＨ仕様の第５．３．１２．１節に定義されている。

[0148]ＩＳＯ ＢＭＦＦの再同期点は、基数と順序性の両方に関して以下の制限を有するＩＳＯ ＢＭＦＦセグメントの開始として定義され得る。

[0149]ＩＳＯ ＢＭＦＦベースの再同期点の場合、プロパティは、次のように定義され得る。
・インデックスＩｎｄｅｘは、上記の制約されたＩＳＯ ＢＭＦＦセグメントの第１のバイトのオフセットとして定義される。
・最も早いプレゼンテーション時間Ｔｉｍｅは、チャンク中の任意のサンプルの復号時間と、構成オフセットと、エディットリストとの組合せの最小時間として定義される。
・ＳＡＰタイプは、ＤＡＳＨ仕様の第４．５．２節に従って定義される。
・ｓｔｙｐが主な互換性ブランドとして「ｃｍｆｌ」とともに存在する場合、マーカーは存在する。

[0150]再同期インデックスセグメントは、１つの表現の１つのメディアセグメントをインデックス付けすることができ、次のように定義され得る。
・各表現インデックスセグメントは「ｓｔｙｐ」ボックスで始まるべきであり、ブランド「ｒｉｓｇ」は「ｓｔｙｐ」ボックス中に存在すべきである。ブランド「ｒｉｓｇ」の適合要件は、この下位条項によって定義される。
・各メディアセグメントは、１つまたは複数のセグメントインデックスボックスによってインデックス付けされ、所与のメディアセグメントのボックスは連続している。

[0151]図９は、本開示の技法による、メディアデータを取り出す例示的な方法を示すフローチャートである。図９の方法が、図１のクライアントデバイス４０に関して説明される。しかしながら、図５の低レイテンシＤＡＳＨクライアント２３２、または、図７のメディアデコーダ２９６と、ＣＭＡＦ／ＦＦパーサ２９４と、ＤＡＳＨクライアント２９２と、ＲＯＵＴＥ受信機２９０とを含むクライアントデバイスはまた、この方法または同様の方法を実行するように構成され得る。

[0152]最初に、クライアントデバイス４０は、メディアプレゼンテーションのＭＰＤなどのマニフェストファイルを取り出すことができる（３５０）。クライアントデバイス４０は、たとえばサーバデバイス６０からマニフェストファイルを取り出すことができる。マニフェストファイルは、メディアプレゼンテーションがメディアプレゼンテーションの表現のセグメント内のチャンク境界における再同期点を含むことを示すデータを含み得る。したがって、クライアントデバイス４０は、メディアプレゼンテーションの再同期点、たとえば、直近に利用可能な再同期点を決定することができる（３５２）。概して、再同期点は、チャンク境界の開始を示すことができ、ファイルレベルコンテナ（たとえば、上記で説明したように、ボックスなどのデータ構造）が適切に解析され得る表現のランダムアクセス可能な点である。

[0153]特に、マニフェストファイルは、セグメントの開始からのバイトオフセットなどの、再同期点の位置を示すことができる。この情報は、セグメント中の再同期点のロケーションを正確に識別することはできないが、再同期点がバイトオフセットからのバイト範囲内で利用可能であることを保証することができる。したがって、クライアントデバイス４０は、再同期点において取出しを始めるために、示されたバイトオフセットを指定する、ＨＴＴＰ部分Ｇｅｔ要求などの要求を形成することができる（３５４）。クライアントデバイス４０は、次いで、サーバデバイス６０に要求を送ることができる（３５６）。

[0154]要求に応答して、クライアントデバイス４０は、再同期点を含む要求されたメディアデータを受信することができる（３５８）。上述のように、バイトオフセットは、再同期点のロケーションを正確に識別しない場合があり、したがって、クライアントデバイス４０は、再同期点の実際の位置を検出するまでデータを解析し得る。クライアントデバイス４０は、取り出されたメディアデータの対応するチャンクのメディアデータのロケーションを決定するために、再同期点で開始して、ファイルフォーマットボックスなどのファイルレベルデータ構造を解析し得る。詳細には、クライアントデバイス４０は、たとえば、セグメントタイプ値と、発生器基準時間値と、イベントメッセージと、ムービーフラグメントと、メディアデータコンテナボックスとを検出することによって、再同期点をチャンクの開始として識別し得る。ムービーフラグメントは、符号化メディアデータを含み得る。

[0155]カプセル化解除ユニット５０は、たとえば、ムービーフラグメントから、対応するチャンクの符号化メディアデータを抽出し（３６０）、たとえば、ビデオデコーダ４８に符号化メディアデータを提供することができる。チャンクは、ビデオデータのイントラ予測フレーム（Ｉフレーム）などのランダムアクセスポイント（ＲＡＰ）で開始し得る。マニフェストファイルは、ＲＡＰがクローズドピクチャグループ（ＧＯＰ）またはオープンＧＯＰの開始であるかどうかをさらに示し、それによって、ＲＡＰで開始して実行され得るランダムアクセスのタイプ（たとえば、Ｉフレームのリーディングピクチャが復号可能であるか、または復号不可能でないか）を示すことができる。ビデオデコーダ４８は、次に、符号化メディアデータを復号し（３６２）、復号されたメディアデータを提示する（３６４）ために、たとえばビデオ出力４４にメディアデータを送ることができる。

[0156]このようにして、図９の方法は、ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点はセグメントの開始以外の位置にあり、ビットストリームのメディアデータのコンテナ解析が開始され得る点を表す、マニフェストファイルを使用して、再同期点において開始する表現のメディアデータを取り出す要求を形成することと、再同期点において開始するメディアプレゼンテーションのメディアデータの取出しを開始する要求を送ることと、取り出されたメディアデータを提示することとを含む、メディアデータを取り出す方法の一例を表す。

[0157]本開示のいくつかの技法は、以下の例において要約される。

[0158]例１：メディアデータを取り出す方法であって、メディアプレゼンテーションの表現の再同期点において再同期および解読が開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すことと、再同期点において開始する表現のメディアデータを取り出すことと、取り出されたメディアデータを提示することとを備える、方法。

[0159]例２：再同期点はチャンク境界の開始を備える、例１の方法。

[0160]例３：チャンク境界は、０個または１個のセグメントタイプ値と、０個または１個の発生器基準時間値と、０個以上のイベントメッセージと、少なくとも１つのムービーフラグメントボックスと、少なくとも１つのメディアデータコンテナボックスとを備えるチャンクの開始を備える、例２の方法。

[0161]例４：マニフェストファイルは、表現のセグメント中の再同期点の利用可能性を示す、例１から３のいずれかの方法。

[0162]例５：再同期点は、セグメントの開始以外の位置にある、例４の方法。

[0163]例６：マニフェストファイルは、再同期点において実行され得るランダムアクセスのタイプを示す、例４および５のいずれかの方法。

[0164]例７：マニフェストファイルは、再同期点の位置およびタイミングと、位置およびタイミング情報が正確であるかまたは推定であるかとを示す、例４から６のいずれかの方法。

[0165]例８：マニフェストファイルはメディアプレゼンテーション記述（ＭＰＤ）を備える、例１から７のいずれかの方法。

[0166]例９：メディアデータを取り出すためのデバイスであって、例１から８のいずれかの方法を実行するための１つまたは複数の手段を備える、デバイス。

[0167]例１０：１つまたは複数の手段は、回路内に実装された１つまたは複数のプロセッサと、メディアデータを記憶するように構成されたメモリとを備える、例９のデバイス。

[0168]例１１：集積回路、マイクロプロセッサ、またはワイヤレス通信デバイスのうちの少なくとも１つを備える、例９のデバイス。

[0169]例１２：実行されたとき、例１から８のいずれかの方法をプロセッサに実行させる命令を記憶したコンピュータ可読記憶媒体。

[0170]例１３：メディアデータを取り出すためのデバイスであって、メディアプレゼンテーションの表現の再同期点において再同期および解読が開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを取り出すための手段と、再同期点において開始する表現のメディアデータを取り出すための手段と、取り出されたメディアデータを提示するための手段とを備える、デバイス。

[0171]例１４：メディアデータを送る方法であって、メディアプレゼンテーションの表現の再同期点において再同期および解読が開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを、クライアントデバイスに送ることと、クライアントデバイスから再同期点において開始するメディアデータの要求を受信することと、要求に応答して、再同期点において開始する表現の要求されたメディアデータを、クライアントデバイスに送ることとを備える、方法。

[0172]例１５：マニフェストファイルを生成することをさらに備える、例１４の方法。

[0173]例１６：再同期点はチャンク境界の開始を備える、例１４および１５のいずれかの方法。

[0174]例１７：チャンク境界は、０個または１個のセグメントタイプ値と、０個または１個の発生器基準時間値と、０個以上のイベントメッセージと、少なくとも１つのムービーフラグメントボックスと、少なくとも１つのメディアデータコンテナボックスとを備えるチャンクの開始を備える、例１６の方法。

[0175]例１８：マニフェストファイルは、表現のセグメント中の再同期点の利用可能性を示す、例１４から１７のいずれかの方法。

[0176]例１９：再同期点は、セグメントの開始以外の位置にある、例１８の方法。

[0177]例２０：マニフェストファイルは、再同期点において実行され得るランダムアクセスのタイプを示す、例１８および１９のいずれかの方法。

[0178]例２１：マニフェストファイルは、再同期点の位置およびタイミングと、位置およびタイミング情報が正確であるかまたは推定であるかとを示す、例１８から２０のいずれかの方法。

[0179]例２２：マニフェストファイルはメディアプレゼンテーション記述（ＭＰＤ）を備える、例１４から２１のいずれかの方法。

[0180]例２３：メディアデータを送るためのデバイスであって、例１４から２２のいずれかの方法を実行するための１つまたは複数の手段を備える、デバイス。

[0181]例２４：１つまたは複数の手段は、回路内に実装された１つまたは複数のプロセッサと、メディアデータを記憶するように構成されたメモリとを備える、例２３のデバイス。

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

[0183]例２６：実行されたとき、例１から８のいずれかの方法をプロセッサに実行させる命令を記憶したコンピュータ可読記憶媒体。

[0184]例２７：メディアデータを送るためのデバイスであって、メディアプレゼンテーションの表現の再同期点において再同期および解読が開始され得ることを示すメディアプレゼンテーションのマニフェストファイルを、クライアントデバイスに送るための手段と、クライアントデバイスから再同期点において開始するメディアデータの要求を受信するための手段と、要求に応答して、再同期点において開始する表現の要求されたメディアデータを、クライアントデバイスに送るための手段とを備える、デバイス。

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

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

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

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

[0189]様々な例について説明してきた。これらおよび他の例は、以下の特許請求の範囲内に入る。

Claims (29)

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. メディアデータを取り出すためのデバイスであって、
    ビットストリームのメディアデータのコンテナ解析がメディアプレゼンテーションの表現のセグメントの再同期点において開始され得ることを示す前記メディアプレゼンテーションのマニフェストファイルを取り出すための手段と、前記再同期点は前記セグメントの開始以外の位置にあり、前記ビットストリームの前記メディアデータの前記コンテナ解析が開始され得る点を表す、
    前記マニフェストファイルを使用して、前記再同期点において開始する前記表現の前記メディアデータを取り出す要求を形成するための手段と、
    前記再同期点において開始する前記メディアプレゼンテーションの前記メディアデータの取出しを開始する前記要求を送るための手段と、
    前記取り出されたメディアデータを提示するための手段と
    を備える、デバイス。

Images