JP6321037B2 - Ｈｔｔｐ上の動的適応ストリーミング（ｄａｓｈ）のためのライブタイミング - Google Patents

Description

関連出願

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

[0002] 本開示は、ビデオデータなどの符号化メディアデータのトランスポートに関する。

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

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

[0005] ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット、およびＡＶＣファイルフォーマットまたはＨＥＶＣファイルフォーマットなどのそれの拡張など、様々な規格のいずれか、またはＭＰＥＧ−２トランスポートストリームもしくは他のカプセル化フォーマットに準拠するビデオファイルにアセンブルされ得る。

[0006] 概して、本開示は、例えば、ＨＴＴＰ上の動的適応ストリーミング（ＤＡＳＨ：ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）を使用するライブストリーミングのための時刻情報をシグナリングすることに関する技術を説明する。ライブストリーミングを行うとき、メディアコンテンツは、コンテンツが受信され（例えば、記録され）、符号化された後にのみ、送信のために作成され得る。本開示の技法によれば、ソースデバイスは、メディアコンテンツのセグメントが利用可能になる時刻を掛け時計時刻(wall-clock time)で広告できる。ソースデバイスは、広告された掛け時計時刻でセグメントが完全に形成されることを確実にし得る。さらに、ソースデバイスは、例えば、クライアントおよびソースデバイスが同じ時刻基準で動作することを確実にするために、クライアントデバイスがそのローカルクロックを掛け時計時刻と同期させ得る同期方法を広告できる。例えば、ソースデバイスは、例えば、ＨＴＴＰプロトコルを同期プロトコルとして使用して、ネットワークタイムプロトコル（ＮＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）タイミングプロトコル（ＨＴＰ）、ＨＴＴＰ日付ヘッダまたはＲＥＳＴＦＵＬ ＡＰＩを広告できる。ソースデバイスは、時刻同期サーバのネットワークアドレスをさらに広告できる。ソースデバイスは、メディアプレゼンテーション記述（ＭＰＤ）などのマニフェストファイルでこの時刻同期情報を広告できる。

[0007] 一例では、メディアデータのストリーミングのための情報を受信する方法は、クライアントデバイスによって、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、ＭＰＤは、クライアントデバイスがソースデバイスからのメディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、データは、クライアントデバイスが掛け時計時刻をクライアントデバイスのクロックと同期させるべきである同期方法を示す、ＭＰＤによって示される方法を使用して、クライアントデバイスのクロックを掛け時計時刻と同期させることと、同期したクロックを使用して、ソースデバイスからのメディアコンテンツのデータを要求することとを含む。

[0008] 別の例では、メディアデータのストリーミングのための情報を受信するためのクライアントデバイスは、クロックと、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、ＭＰＤは、クライアントデバイスがソースデバイスからのメディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、データは、クライアントデバイスが掛け時計時刻をクロックと同期させるべきである同期方法を示す、ＭＰＤによって示される方法を使用して、クロックを掛け時計時刻と同期させることと、同期したクロックを使用して、ソースデバイスからのメディアコンテンツのデータを要求することとを行うように構成された１つまたは複数のプロセッサとを含む。

[0009] 別の例では、コンピュータ可読記憶媒体は、実行されると、クライアントデバイスのプロセッサに、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、ＭＰＤは、クライアントデバイスがソースデバイスからのメディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、データは、クライアントデバイスが掛け時計時刻をクライアントデバイスのクロックと同期させるべきである同期方法を示す、ＭＰＤによって示される方法を使用して、クライアントデバイスのクロックを掛け時計時刻と同期させることと、同期したクロックを使用して、ソースデバイスからのメディアコンテンツのデータを要求することとを行わせる命令を記憶している。

[0010] 別の例では、メディアデータのストリーミングのための情報をシグナリングする方法は、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）のためのデータを生成することと、ここにおいて、ＭＰＤは、クライアントデバイスがソースデバイスからのメディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、生成されたデータは、クライアントデバイスが掛け時計時刻をクライアントデバイスのクロックと同期させるべきである同期方法を示す、ＭＰＤをクライアントデバイスに送ることとを含む。

[0011] 別の例では、メディアデータのストリーミングのための情報をシグナリングする方法は、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）のためのデータを生成すること、ここにおいて、ＭＰＤは、クライアントデバイスが掛け時計時刻をソースデバイスのクロックと同期させ得る２つ以上の方法を示す、を含む。一例では、クライアントデバイスは、掛け時計時刻と同期させるための１つまたは複数の好適な方法を選択できる。例えば、複数の方法を選ぶことによって、掛け時計時刻との同期はより正確になり得る。

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

ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 本開示の技法を実装し得る様々なデバイスを含むシステムを示す概念図である。 クライアントデバイスのローカルクロックを掛け時計時刻と同期させ、同期したクロックを使用してセグメントを取り出す例示的な方法を示すフローチャートである。

[0017] 概して、本開示は、ＨＴＴＰ上の動的適応ストリーミング（ＤＡＳＨ）環境など、メディアデータをストリーミングするための環境において、クライアントとサーバとの間の正確なタイミングを可能にするための技法について説明する。これらの技法は、ＨＴＴＰライブストリーミング（ＨＬＳ）をサポートするために使用され得る。全体的にＤＡＳＨおよびＨＬＳに関して説明されるが、本開示の技法は、他のネットワークストリーミングプロトコルに適用可能であり得る。ＤＡＳＨは、ＩＳＯ／ＩＥＣ ２３００９−１：２０１２、ｈｔｔｐ：／／ｓｔａｎｄａｒｄｓ．ｉｓｏ．ｏｒｇ／ｉｔｔｆ／ＰｕｂｌｉｃｌｙＡｖａｉｌａｂｌｅＳｔａｎｄａｒｄｓ／ｃ０５７６２３＿ＩＳＯ＿ＩＥＣ＿２３００９−１＿２０１２．ｚｉｐで入手可能な「Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ） − Ｐａｒｔ １： Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ａｎｄ ｓｅｇｍｅｎｔ ｆｏｒｍａｔｓ」、２０１２年４月１日において規定されている。ＩＳＯ／ＩＥＣ ２３００９−１の規格についての正誤表、補正およびさらなる追加が入手可能であり得、同じ技術がこれらの拡張のいずれにも適用され得る。

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

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

[0020] メディアプレゼンテーションは、１つまたは複数の期間のシーケンスを含み得る。期間は、ＭＰＤ内のＰｅｒｉｏｄ要素によって定義され得る。各期間は、ＭＰＤ内に属性ｓｔａｒｔを有し得る。ＭＰＤは、期間ごとにａｖａｉｌａｂｌｅＳｔａｒｔＴｉｍｅ属性とｓｔａｒｔ属性とを含み得る。「動的」タイプのメディアプレゼンテーション（通常、ライブサービスに使用される）では、期間のｓｔａｒｔ属性とＭＰＤ属性ａｖａｉｌａｂｌｅＳｔａｒｔＴｉｍｅとメディアセグメントの継続時間(duration)との和が、協定世界時（ＵＴＣ：Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ）フォーマットでの期間の利用可能性時間、特に対応する期間内の各表現(representation)の第１のメディアセグメントを規定し得る。静的タイプのメディアプレゼンテーション（通常、オンデマンドサービスに使用される）では、第１の期間のｓｔａｒｔ属性は０であり得る。任意の他の期間では、ｓｔａｒｔ属性は、第１の期間の開始時期に対して、対応する期間の開始時期(start time)の間の時間オフセットを規定し得る。各期間は、次の期間の開始まで、または最後の期間の場合、メディアプレゼンテーションの終了まで継続し得る。期間開始時期は正確であり得る。それらは、全ての前の期間のメディアを再生することから得られる実際のタイミングを反映し得る。

[0021] 各期間は１つまたは複数の適応セットを含み得、適応セットの各々は同じメディアコンテンツに対する１つまたは複数の表現を含み得る。表現は、オーディオまたはビデオデータのいくつかの代替的な符号化バージョンのうちの１つであり得る。表現は、符号化タイプによって、例えば、ビデオデータの場合、ビットレート、解像度、および／もしくはコーデックによって、並びに／またはオーディオデータの場合、コーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された符号化オーディオまたはビデオデータのセクションを指すために使用され得る。

[0022] 特定の期間の適応セットは、ＭＰＤ内のｇｒｏｕｐ属性によって示されるグループに割り当てられ得る。同じグループ内の適応セットは、概して互いの代替と見なされる。例えば、特定の期間に対するビデオデータの各適応セットは、適応セットのいずれかが、対応する期間に対するマルチメディアコンテンツのビデオデータを表示するために復号のために選択され得るように、同じグループに割り当てられ得る。１期間内のメディアコンテンツは、いくつかの例では、存在する場合、グループ０からの１つの適応セットか、または各非ゼログループからの多くとも１つの適応セットの組合せのいずれかによって表され得る。期間の各表現についてのタイミングデータは、期間の開始時期に対して表現され得る。

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

[0024] 各表現はまた、１つまたは複数のメディア構成要素を含み得、各メディア構成要素は、オーディオ、ビデオ、または（例えば、クローズドキャプション用の）時限テキストなど、１つの個々のメディアタイプの符号化バージョンに対応し得る。メディア構成要素は、１つの表現内の連続するメディアセグメントの境界にわたって時間連続的であり得る。

[0025] 概して、ＤＡＳＨクライアントデバイスは、ＭＰＤにアクセスし、ＤＡＳＨサーバデバイスからダウンロードできる。すなわち、ＤＡＳＨクライアントデバイスは、ライブセッションを開始する際に使用するためにＭＰＤを取り出すことができる。このＭＰＤに基づいて、および各選択された表現について、ＤＡＳＨクライアントデバイスは、サーバデバイス上で利用可能な最新のセグメントはどれかを決定することと、次のセグメントおよび場合によっては将来のセグメントのセグメント利用可能性開始時期を決定することと、セグメントのプレイアウトをいつ、セグメント内のどのタイムラインから開始するかを決定することと、新しいＭＰＤをいつ得る／フェッチするかを決定することとを含む、いくつかの決定を行うことができる。サービスがプレイアウトされると、クライアントデバイスは、ライブサービスとそれ自体のプレイアウトとの間のドリフトを追跡することができ、このドリフトは、検出され、補償される必要がある。

[0026] ＨＴＴＰライブストリーミング（ＨＬＳ）は、これらの問題を次のように解決しようと試みる。利用可能にされる各セグメントに対して、サーバデバイスは新しいＭＰＤを発行する。クライアントデバイスは、サービスに参加した後、最新のＭＰＤを取り出し、プレイリストを解析し、次いで、最新のセグメントにアクセスできる。次いで、クライアントデバイスは、セグメントのプレイアウトを開始し、セグメントを最初からプレイするときに、クライアントデバイスが時間的に次のセグメントに継続的にアクセスできることを期待して構成される。新しいセグメントをフェッチする（またはセグメントをフェッチすることを必要とする）前に、クライアントデバイスは、最新のセグメントをどこで得るべきかのロケーションを与える新しいＭＰＤをフェッチする。

[0027] ＳｍｏｏｔｈＳｔｒｅａｍｉｎｇは、これらの問題を次のように解決しようと試みる。利用可能にされる各セグメントに対して、サーバデバイスはＭＰＤに相当する新しいマニフェストを発行する。クライアントは、サービスに参加した後、最新のマニフェストを取り出し、最新のＳ要素のＳｅｇｍｅｎｔＴｉｍｅＬｉｎｅの「＠ｒ」属性を得ることによって、利用可能である最新のセグメントを解析する。このことは、最新のセグメントをどこで得るべきかを示す情報を提供する。次いで、クライアントデバイスは、セグメントのプレイアウトを開始し、セグメントを最初からプレイするときに、次の要求がセグメント継続時間を最後の要求の時間に追加することから得られる時間の前でない限り、クライアントデバイスが時間的に次のセグメントに継続的にアクセスできることを期待して構成される。従って、クライアントは、現在のマニフェストがもはや使用できない帯域内信号をクライアントが得るまで、新しいマニフェストをフェッチすることなしに、最新のＳｅｇｍｅｎｔＴｉｍｅｌｉｎｅ．Ｓ要素に基づいてセグメントを構築し続ける。時間的にこの時点で（すなわち、現在のマニフェストがもはや使用できない信号に応答して）、クライアントデバイスは新しいマニフェストを要求する。

[0028] 本開示は、ＨＬＳおよびＳｍｏｏｔｈＳｔｒｅａｍｉｎｇの提案された解決策が類似の問題に遭遇する可能性があることを認識する。例えば、ＨＬＳとＳｍｏｏｔｈＳｔｒｅａｍｉｎｇの両方は、各新たに利用可能なセグメントを用いて、サーバデバイス上でＭＰＤ／プレイリスト／マニフェストを更新する。これは、クライアントデバイスがライブセッションに参加するときはいつでも、クライアントデバイスがＭＰＤ／プレイリスト／マニフェストをフェッチし、ＭＰＤ／プレイリスト／マニフェスト内の情報を使用することを必要とすることを意味する。言い換えれば、参加することはＭＰＤ／プレイリスト／マニフェストのフェッチを意味し、ＭＰＤ／プレイリスト／マニフェストは最新のＭＰＤ／プレイリスト／マニフェストである必要がある。従って、テンプレートが使用される場合でも、サーバは、「＠ｒ」カウントの変更について対応するためにＭＰＤ／プレイリスト／マニフェストを更新する必要がある。このアカウンティングは各表現について行われる必要がある。ＭＰＤ／プレイリスト／マニフェスト更新は、ＭＰＤ／プレイリスト／マニフェストがＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）を介して配信されるか、またはキャッシュにプッシュされる必要がある場合に特に重要である。この場合、どの各新しいセグメントに沿って、新しいＭＰＤ／プレイリスト／マニフェストがプッシュされる必要がある。

[0029] 別の例として、クライアントデバイスは、どの時間に次のセグメントがサーバデバイス上で利用可能であるか／発行されるかに関する情報を有さない。すなわち、クライアントデバイスは、次のセグメントが遅くともセグメント継続時間の後に発行されることを期待して構成される。これは、ＨＬＳに必要な、新しいセグメントをフェッチする前にＭＰＤ／プレイリストを更新することによって確認され得る。さらに、クライアントは、最新の利用可能なセグメントの最も早いプレゼンテーション時間よりも後の任意のプレゼンテーション時間が、後で再バッファすることを必要とせずにライブエッジ（ｌｉｖｅ ｅｄｇｅ）により近づくためにプレイアウトされ得るかどうかに関する情報を有さない。緩いタイミングモデルと、次のセグメントがいつ利用可能になるかに関する情報を有さないクライアントとの事実として、クライアントデバイスは、最も早いプレゼンテーション時間がプレイドできるという仮定の下で構成されなければならない。

[0030] さらに、クライアントデバイスは、同じセグメントをダウンロードする他のクライアントデバイスによるプレイアウトが同期するかどうかに関する情報を有さない。加えて、クライアントデバイスは、最新の情報を取得するためにサービスに参加するときに、新しいＭＰＤをフェッチする必要がある。この「フェッチ」は、ライブセッションを開始するための要求とクライアントデバイスがプレイアウトを開始できる時間との間に遅延を課すことができる、少なくとも１つのＭＰＤフェッチ往復時間を必要とする。

[0031] 上記で指摘された問題の主な原因は、ＨＬＳおよびＳｍｏｏｔｈＳｔｒｅａｍｉｎｇの既存の技法がＭＰＤおよびメディアセグメント作成の正確な時間スケジュールについての情報を提供しないということである。一例として、１０秒のセグメントで動作する場合、クライアントは、ＭＰＤ／プレイリスト／マニフェストが発行されたばかりであるかどうか、またはＭＰＤ／プレイリスト／マニフェストが間もなく発行されるかどうかに関する情報をほとんど有さない。そのため、タイミングは依然として最大１０ε秒だけ外れる可能性があり、εは任意に小さいが、０よりも大きい。加えて、ＨＬＳおよびＳｍｏｏｔｈＳｔｒｅａｍｉｎｇのこれらの技法は、全ての新たに生成され、発行されたセグメントを用いて、ＭＰＤ／プレイリスト／マニフェストを頻繁に更新することを必要とする。ＨＬＳおよびＳｍｏｏｔｈＳｔｒｅａｍｉｎｇの技法において、ライブエッジにより近いプレイアウトを可能にするまたは他のクライアントと同期したプレイアウトを可能にするクライアントにとって、基準クロックは利用可能ではない。

[0032] Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）ＤＡＳＨおよびＤＡＳＨ−ＩＦ ＤＡＳＨ−２６４／ＡＶＣ技法も、この問題に対処しようと試みる。例えば、これらの技法では、番号ベースのテンプレートが使用され得る。ＭＰＥＧ−ＤＡＳＨは、上述の欠点に対処しようと試みる。すなわち、ＭＰＥＧ−ＤＡＳＨは、同じメディアプレゼンテーションを消費しているクライアントのプレイアウトを同期させ、サーバ上でのＭＰＤの定期的な更新とクライアントによるフェッチとを回避し、サービスに参加するときにリアルタイムでＭＰＤをフェッチすることを回避するために、ライブエッジにより近づいて動作しようと試みる。

[0033] 詳細には、ＭＰＥＧ−ＤＡＳＨは、ライブのメディアプレゼンテーションをセットアップするＭＰＤ内に提供された(documented)掛け時計時刻を使用する。ＭＰＥＧ−ＤＡＳＨは、ＭＰＤ生成プロセスが正確なクロックにアクセスできるようにＭＰＤが生成されると仮定する。このことは、何らかの手段によって掛け時計時刻と同期したクライアントデバイスがライブエッジにより近づいて動作することを可能にする。具体的には、番号テンプレートベースの表現を使用し、＠ｄｕｒａｔｉｏｎ属性を使用することを使用するときに、ＭＰＤ内で以下の情報が利用可能である。

・ ＭＰＤ＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ：開始時期は掛け時計時刻におけるＭＰＤのアンカーである。この値はＡＳＴとして示される。

・ ＭＰＤ＠ｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄ：ＭＰＤの最小更新期間。この値はＭＵＰとして示される。

・ ＭＰＤ＠ｓｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙ：セグメント利用可能性開始時期との差分として示唆されるプレゼンテーション遅延。この値はＳＰＤとして示される。

・ ＭＰＤ＠ｍｉｎＢｕｆｆｅｒＴｉｍｅ：各表現の＠ｂａｎｄｗｉｄｔｈ属性と併せて使用される最小バッファ時間。この値はＭＢＴとして示される。

・ ＭＰＤ＠ｔｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈ：メディアプレゼンテーションの時間シフトバッファ深さ。この値はＴＳＢとして示される。

・ Ｐｅｒｉｏｄ＠ｓｔａｒｔ：ＭＰＤ利用可能性開始時期に対する期間の開始時期。この値はＰＳとして示される。

・ ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ＠ｓｔａｒｔＮｕｍｂｅｒ：期間内の最初のセグメントの番号。この値はＳＳＮとして示される。

・ ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ＠ｄｕｒａｔｉｏｎ：時間の単位でのセグメントの継続時間。＠ｔｉｍｅｓｃａｌｅの値で除算されるこの値はｄとして示される。

[0034] クライアントデバイスはフェッチ時間ＦＴでＭＰＤをフェッチしたと仮定される。

[0035] ここで、クライアントにおける掛け時計時刻がＷＴにおいて示されると仮定すると、クライアントデバイスは以下の情報を導出できる。

・ ＬＳＮとして示される最新のセグメント番号を必要とする、サーバ上で利用可能な最新のセグメントのアドレス
・ ＳＡＳＴ（ＳＮ）として示される、番号ＬＳＮ＋１を有する次のセグメントおよび任意の他のセグメントＳＮのセグメント利用可能性開始時期。ＳＮは１から始まることに留意されたい。

・ ライブエッジと最も近く同期するセグメント内のメディアプレゼンテーション時間、ＭＰＴＬ。

・ 他のクライアントと同期するセグメント内のメディアプレゼンテーション時間、ＭＰＴＳ。

・ 現在のプレゼンテーション時間に基づく、新しいＭＰＤをフェッチするべき時間。

[0036] ＭＰＥＧ−ＤＡＳＨの技法の一例が以下で説明される。この例では、ＭＰＤは以下の情報を含むものとする。

[0037] クライアントデバイスがＭＰＤをフェッチし、掛け時計時刻がＮＴＰ＝「２０１１−１２−２５Ｔ１２：３０：２７」であるとさらに仮定する。この例では、この値はＦＴとして示される。

[0038] 次いで、クライアントデバイスは最新のセグメント番号を導出する。すなわち、クライアントデバイスは、ＡＳＴ＋ＰＳ≦ＮＴＰである期間として最新の期間を取得する。ＮＴＰ≧ＡＳＴ＋ＰＳ＋ｄである場合、この期間内の少なくとも１つのセグメントが利用可能であり、クライアントデバイスはクライアント上で利用可能な最新のセグメント番号（ＬＳＮ）を

として導出する。

[0039] 、この例では、結果として生じるＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｕｄｉｏ／ｆｒ／２９．ｍｐ４として導出される。

[0040] 次いで、クライアントデバイスは、番号ＳＮを有するセグメントのセグメント利用可能性開始時期（ＳＡＳＴ）を

として導出する。

[0041] これは、この例では、ＳＮ＝３０の場合、ＳＡＳＴ（ＳＮ＝３０）＝２０１１−１２−２５Ｔ１２：３０：２８を意味する。

[0042] 次いで、クライアントデバイスは、ＭＰＤ内の利用可能な情報に基づいてプレイアウトをスケジュールする。クライアントデバイスは、各表現についての期間内のメディアプレゼンテーション時間を、存在する場合、各表現についての＠ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＯｆｆｓｅｔの値を引いた、メディアセグメント内のプレゼンテーション時間値として決定する。セグメント番号ＳＮを有する各セグメントは、ＥＰＴ（ＳＮ）として示される、最も早いプレゼンテーション時間を含む。

[0043] ＭＰＥＧ−ＤＡＳＨでは、ＭＰＤを提供することによって、以下のことが保証される。

１．この期間内の各セグメントは、その最も早いプレゼンテーション時間の前に利用可能である、すなわち、全てのＳＮについて、ＥＰＴ（ＳＮ）≧ＳＡＳＴ（ＳＮ）−（ＡＳＴ＋ＰＳＴ）である。

２．セグメント番号ＳＮを有する各セグメントが、＠ｂａｎｄｗｉｄｔｈ属性の値に等しいビットレートを有する固定ビットレートチャネル上で、ＳＡＳＴ（ＳＮ）において開始して配信される場合、各プレゼンテーション時間ＰＴは、最も遅く時間ＰＴ＋（ＡＳＴ＋ＰＳＴ）＋ＭＢＴで、クライアントにおいて利用可能である。

３．他のクライアントと同期して動作するときの、プレゼンテーション時間の推奨されるプレイアウト時間ＭＰＴＳ（ＰＴ）は、ＭＰＴＳ（ＰＴ）＝（ＡＳＴ＋ＰＳＴ）＋ＰＴ＋ＳＰＤである。

４．この期間内の各セグメントは、少なくともＳＡＳＴ（ＳＮ）＋ＴＳＢ＋ｄまで利用可能である。

[0044] この情報を使用して、クライアントデバイスは、ＭＰＤ内の情報、ダウンロード速度も考慮して、プレイアウトのスケジューリングを開始できる。好適なプレイアウト時間は、属性＠ｓｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙが存在する場合、ＰＯＴ（ＰＴ）＝ＭＰＴＳ（ＰＴ）である。＠ｓｕｇｇｅｓｔｅｄＰｒｅｓｅｎｔａｔｉｏｎＤｅｌａｙが存在しない場合、好適なプレイアウト時間は、上記の第１、第２、および第４の制約、すなわち、サーバにおけるセグメント利用可能性時間並びにメディアストリームのビットレート変動性を考慮する。

[0045] クライアントデバイスは、ＭＰＤが有効である間、セグメントを構築するためにＭＰＤを使用する。詳細には、クライアントデバイスは、メディア時間ＦＴ＋ＭＵＰまで、セグメントを構築するためにＭＰＤを使用する。すなわち、構築され得る最も大きいセグメント番号（ＧＳＮ）は、

である。

[0046] 最新のセグメントは他のセグメントよりも短くてもよいことを理解されたい。セグメント番号４５を超える任意のデータをフェッチする前に、上記の例では、クライアントデバイスはＭＰＥＧ−ＤＡＳＨに従って新しいＭＰＤをフェッチする必要がある。

[0047] より一般的には、ＤＡＳＨにおいて異なるタイミングおよびアドレス指定方式と同じ概念を使用するために、ＩＳＯ／ＩＥＣ ２３００９−１に従って以下の値が導入される。

・ ｋとして示される、期間内のセグメントの位置、ただし、ｋ＝１，２，．．．である。

・ ＭＳＴ（ｋ）と呼ばれる、位置ｋにおけるセグメントのＭＰＤ開始時期
・ ＭＤ（ｋ）と呼ばれる、位置ｋにおけるセグメントのＭＰＤ継続時間。

[0048] ここで、クライアントデバイスにおける掛け時計時刻がＷＴとして示されると仮定すると、クライアントデバイスは以下の情報を導出できる。

１．その期間開始時期ＰＳＴ^*によって示される、サーバ上での最新の利用可能な期間
２．ＳＡＳＴ（ｋ）として示される、期間内の位置ｋにおける任意のセグメントのセグメント利用可能性開始時期。

３．ｋ^*と呼ばれる、期間内のサーバ上で利用可能な最新のセグメントの位置
４．サーバ上で利用可能な最新のセグメントのアドレス
５．現在のプレゼンテーション時間に基づく、新しいＭＰＤをフェッチするべき時間、より具体的には、このＭＰＤによって構築され得る、この期間内の最も大きいセグメント位置ｋ’。

６．ライブエッジと最も近く同期する表現内のメディアプレゼンテーション時間、ＭＰＴＬ。

７．他のクライアントと同期する表現内のメディアプレゼンテーション時間、ＭＰＴＳ。

[0049] これらの時間を使用して、クライアントデバイスは以下のように上記から値を導出できる。

１．最新の期間は、ＰＳＴ≦ＮＴＰである期間として取得される。

２．セグメント利用可能性開始時期は、

として取得される。

３．この期間内では、クライアントデバイス上で利用可能な最新のセグメントは、ＳＡＳＴ（ｋ^*）の最も大きい値になると同時にＮＴＰよりも小さい、位置ｋ^*におけるセグメントである。

４．最新のセグメントのアドレスは位置情報ｋ^*を使用することによって取得され、次いで、セグメントアドレスが導出され得る。セグメントアドレスはアドレス指定方法に依存する。

５．この期間内では、このＭＰＤによって構築され得る最も大きいセグメント位置ｋ’は、ＳＡＳＴ（ｋ’）の最も大きい値になると同時にＦＴ＋ＭＵＰよりも小さいセグメント位置である。

[0050] クライアントデバイスは、このデータを使用して、ＭＰＤ時間を導出できる。例えば、＠ｄｕｒａｔｉｏｎ属性が存在し、＠ｔｉｍｅｓｃａｌｅの値によって除算される値がｄとして示される場合、クライアントデバイスは、従来のＤＡＳＨ技法を使用して、ＭＰＤ時間を

として導出する。

[0051] セグメントベース情報が、ｓ＝１，．．．，Ｎ_Sでインデックス付けされたＮ_SＳ要素を有するＳｅｇｍｅｎｔＴｉｍｅｌｉｎｅ要素を含む場合、（ＩＳＯ／ＩＥＣ ２３００９−１によるＤＡＳＨでは）
・ ｔ［ｓ]は、＠ｔｉｍｅｓｃａｌｅ属性の値によって除算されるｓ番目のＳ要素の＠ｔの値である
・ ｄ［ｓ]は、＠ｔｉｍｅｓｃａｌｅ属性の値によって除算されるｓ番目のＳ要素の＠ｄの値である
・ ｒ［ｓ]は、ｓ番目のＳ要素の＠ｒの値である（＠ｒ値が−１でない限り、これは、この値が未知であり、更新された情報が利用可能になるまで＠ｄが使用され得ることを意味する）
[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] 様々な例が説明されてきた。これらおよび他の例は、以下の特許請求の範囲の範疇である。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
メディアデータのストリーミングについての情報を受信する方法であって、
クライアントデバイスによって、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、前記ＭＰＤは、前記クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記データは、前記クライアントデバイスが前記掛け時計時刻を前記クライアントデバイスのクロックと同期させるべきである同期方法を示す、
前記ＭＰＤによって示される前記方法を使用して、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させることと、
前記同期したクロックを使用して、前記ソースデバイスからの前記メディアコンテンツのデータを要求することとを備える方法。
［Ｃ２］
前記ＭＰＤによって示される前記同期方法が、ネットワークタイムプロトコル（ＮＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＮＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＮＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１に記載の方法。
［Ｃ３］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰタイムプロトコル（ＨＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１に記載の方法。
［Ｃ４］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰを備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１に記載の方法。
［Ｃ５］
前記クロックを同期させることが、ＨＴＴＰ ＨＥＡＤ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＨＥＡＤ要求に応答して、前記ＨＴＴＰサーバのうちの少なくとも１つからのＨＴＴＰヘッダ内の日付情報を受信することとを備える、Ｃ４に記載の方法。
［Ｃ６］
前記クロックを同期させることが、ＨＴＴＰ ＧＥＴ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＧＥＴ要求に応答して、ネットワークタイムプロトコル（ＮＴＰ）および拡張マークアップ言語（ＸＭＬ）および国際標準化機構（ＩＳＯ）時刻コードのうちの１つに従ってフォーマットされた、よくフォーマットされたタイムスタンプ値を受信することとを備える、Ｃ４に記載の方法。
［Ｃ７］
前記ＭＰＤが、前記クライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、別個のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを示すデータを含み、データを要求することが、前記第１の時刻にまたは前記第１の時刻の後に前記セグメントを要求することを備える、Ｃ１に記載の方法。
［Ｃ８］
メディアデータのストリーミングについての情報を受信するためのクライアントデバイスであって、
クロックと、
メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、前記ＭＰＤは、前記クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記データは、前記クライアントデバイスが前記掛け時計時刻を前記クロックと同期させるべきである同期方法を示す、前記ＭＰＤによって示される前記方法を使用して、前記クロックを前記掛け時計時刻と同期させることと、前記同期したクロックを使用して、前記ソースデバイスからの前記メディアコンテンツのデータを要求することとを行うように構成された１つまたは複数のプロセッサとを備えるクライアントデバイス。
［Ｃ９］
前記ＭＰＤによって示される前記同期方法が、ネットワークタイムプロトコル（ＮＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＮＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させるために、前記１つまたは複数のプロセッサが、前記ＮＴＰサーバのうちの少なくとも１つからの時刻を要求するように構成される、Ｃ８に記載のクライアントデバイス。
［Ｃ１０］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰタイムプロトコル（ＨＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させるために、前記１つまたは複数のプロセッサが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求するように構成される、Ｃ８に記載のクライアントデバイス。
［Ｃ１１］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰを備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させるために、前記１つまたは複数のプロセッサが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求するように構成される、Ｃ８に記載のクライアントデバイス。
［Ｃ１２］
前記クロックを同期させるために、前記１つまたは複数のプロセッサが、ＨＴＴＰ ＨＥＡＤ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送り、前記ＨＴＴＰ ＨＥＡＤ要求に応答して、前記ＨＴＴＰサーバのうちの少なくとも１つからのＨＴＴＰヘッダ内の日付情報を受信するように構成される、Ｃ１１に記載のクライアントデバイス。
［Ｃ１３］
前記クロックを同期させるために、前記１つまたは複数のプロセッサが、ＨＴＴＰ ＧＥＴ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送り、前記ＨＴＴＰ ＧＥＴ要求に応答して、ネットワークタイムプロトコル（ＮＴＰ）および拡張マークアップ言語（ＸＭＬ）のうちの１つに従ってフォーマットされた、よくフォーマットされたタイムスタンプ値を受信するように構成される、Ｃ１１に記載のクライアントデバイス。
［Ｃ１４］
前記ＭＰＤが、前記クライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、別個のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを示すデータを含み、前記１つまたは複数のプロセッサが、前記第１の時刻にまたは前記第１の時刻の後に前記セグメントを要求するように構成される、Ｃ８に記載のクライアントデバイス。
［Ｃ１５］
実行されると、クライアントデバイスのプロセッサに、
メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、前記ＭＰＤは、前記クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記データは、前記クライアントデバイスが前記掛け時計時刻を前記クライアントデバイスのクロックと同期させるべきである同期方法を示す、
前記ＭＰＤによって示される前記方法を使用して、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させることと、
前記同期したクロックを使用して、前記ソースデバイスからの前記メディアコンテンツのデータを要求することとを行わせる命令を記憶したコンピュータ可読記憶媒体。
［Ｃ１６］
前記ＭＰＤによって示される前記同期方法が、ネットワークタイムプロトコル（ＮＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＮＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＮＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１５に記載のコンピュータ可読記憶媒体。
［Ｃ１７］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰタイムプロトコル（ＨＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１５に記載のコンピュータ可読記憶媒体。
［Ｃ１８］
前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰを備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、Ｃ１５に記載のコンピュータ可読記憶媒体。
［Ｃ１９］
前記クロックを同期させることが、ＨＴＴＰ ＨＥＡＤ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＨＥＡＤ要求に応答して、前記ＨＴＴＰサーバのうちの少なくとも１つからのＨＴＴＰヘッダ内の日付情報を受信することとを備える、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２０］
前記クロックを同期させることが、ＨＴＴＰ ＧＥＴ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＧＥＴ要求に応答して、ネットワークタイムプロトコル（ＮＴＰ）および拡張マークアップ言語（ＸＭＬ）のうちの１つに従ってフォーマットされた、よくフォーマットされたタイムスタンプ値を受信することとを備える、Ｃ１８に記載のコンピュータ可読記憶媒体。
［Ｃ２１］
前記ＭＰＤが、前記クライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、別個のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを示すデータを含み、データを要求することが、前記第１の時刻にまたは前記第１の時刻の後に前記セグメントを要求することを備える、Ｃ１５に記載のコンピュータ可読記憶媒体。
［Ｃ２２］
メディアデータのストリーミングのための情報をシグナリングする方法であって、
メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）のためのデータを生成することと、ここにおいて、前記ＭＰＤは、クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記生成されたデータは、前記クライアントデバイスが前記掛け時計時刻を前記クライアントデバイスのクロックと同期させるべきである同期方法を示す、
前記ＭＰＤを出力することとを備える方法。
［Ｃ２３］
前記ＭＰＤによって示されるセグメントの掛け時計時刻に従って、前記メディアコンテンツの前記セグメントについての要求を受信することと、
前記要求に応答して、前記セグメントを前記クライアントデバイスに送ることとをさらに備える、Ｃ２２に記載の方法。
［Ｃ２４］
前記データを生成することが、前記同期方法がネットワークタイムプロトコル（ＮＴＰ）を備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＮＴＰサーバのネットワークアドレスを示すために、前記データを生成することを備える、Ｃ２２に記載の方法。
［Ｃ２５］
前記データを生成することが、前記同期方法がＨＴＴＰタイミングプロトコル（ＨＴＰ）を備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すために、前記データを生成することを備える、Ｃ２２に記載の方法。
［Ｃ２６］
前記データを生成することが、前記同期方法がＨＴＴＰを備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すために前記データを生成することを備える、Ｃ２２に記載の方法。
［Ｃ２７］
前記クライアントデバイスが第１のクライアントデバイスを備え、前記ＭＰＤのための前記データを生成することが、前記第１のクライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、第２のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを前記データが示すような前記ＭＰＤのための前記データを生成することを備え、前記ＭＰＤを送ることが、前記ＭＰＤを前記第１のクライアントデバイスおよび前記第２のクライアントデバイスに送ることを備える、Ｃ２２に記載の方法。
［Ｃ２８］
第１の時刻にまたは前記第１の時刻の後に、第１のクライアントデバイスからの前記セグメントについての第１の要求を受信することと、
前記第１の要求に応答して、前記セグメントについてのデータを前記第１のクライアントデバイスに送ることと、
第２の時刻にまたは前記第２の時刻の後に、第２のクライアントデバイスからの前記セグメントについての第２の要求を受信することと、
前記第２の要求に応答して、前記セグメントについての前記データを前記第２のクライアントデバイスに送ることとをさらに備える、Ｃ２３に記載の方法。
［Ｃ２９］
前記データを生成することが、前記第１の時刻および前記第２の時刻についての特定の値を生成することを備える、Ｃ２８に記載の方法。
［Ｃ３０］
前記第１のクライアントデバイスの第１の優先順位と、前記第２のクライアントデバイスの第２の優先順位とを決定することをさらに備え、前記データを生成することが、前記第１の優先順位および前記第２の優先順位に基づいて、前記データを生成することを備える、Ｃ２８に記載の方法。

Claims (15)

1. Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ＨＴＴＰ上の動的適応ストリーミング（ＭＰＥＧ ＤＡＳＨ）を用いてメディアデータのストリーミングについての情報を受信する方法であって、
   クライアントデバイスによって、メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、前記ＭＰＤは、前記クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記データは、前記クライアントデバイスが前記掛け時計時刻を前記クライアントデバイスのクロックと同期させるべきである同期方法を示す、
   前記ＭＰＤによって示される前記方法を使用して、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させることと、
   前記同期したクロックを使用して、前記ソースデバイスからの前記メディアコンテンツのデータを要求することと
   を備える方法。
2. 前記ＭＰＤによって示される前記同期方法が、ネットワークタイムプロトコル（ＮＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＮＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＮＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、請求項１に記載の方法。
3. 前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰタイムプロトコル（ＨＴＰ）を備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、請求項１に記載の方法。
4. 前記ＭＰＤによって示される前記同期方法が、ＨＴＴＰを備え、前記ＭＰＤが、１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すデータを含み、前記クロックを同期させることが、前記ＨＴＴＰサーバのうちの少なくとも１つからの時刻を要求することを備える、請求項１に記載の方法。
5. 前記クロックを同期させることが、ＨＴＴＰ ＨＥＡＤ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＨＥＡＤ要求に応答して、前記ＨＴＴＰサーバのうちの前記少なくとも１つからのＨＴＴＰヘッダ内の日付情報を受信することとを備える、請求項４に記載の方法。
6. 前記クロックを同期させることが、ＨＴＴＰ ＧＥＴ要求を前記ＨＴＴＰサーバのうちの少なくとも１つに送ることと、前記ＨＴＴＰ ＧＥＴ要求に応答して、ネットワークタイムプロトコル（ＮＴＰ）および拡張マークアップ言語（ＸＭＬ）および国際標準化機構（ＩＳＯ）時刻コードのうちの１つに従ってフォーマットされたタイムスタンプ値を受信することとを備える、請求項４に記載の方法。
7. 前記ＭＰＤが、前記クライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、別個のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを示すデータを含み、データを要求することが、前記第１の時刻にまたは前記第１の時刻の後に前記セグメントを要求することを備える、請求項１に記載の方法。
8. Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ＨＴＴＰ上の動的適応ストリーミング（ＭＰＥＧ ＤＡＳＨ）を用いてメディアデータのストリーミングについての情報を受信するためのクライアントデバイスであって、
   クロックと、
   メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）を受信することと、ここにおいて、前記ＭＰＤは、前記クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記データは、前記クライアントデバイスが前記掛け時計時刻を前記クロックと同期させるべきである同期方法を示す、前記ＭＰＤによって示される前記方法を使用して、前記クロックを前記掛け時計時刻と同期させることと、前記同期したクロックを使用して、前記ソースデバイスからの前記メディアコンテンツのデータを要求することとを行うように構成された１つまたは複数のプロセッサと
   を備えるクライアントデバイス。
9. 実行されると、クライアントデバイスのプロセッサに、請求項１乃至７のうちのいずれか１項に記載の方法のステップを実行させる命令を記憶したコンピュータ可読記憶媒体。
10. Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ＨＴＴＰ上の動的適応ストリーミング（ＭＰＥＧ ＤＡＳＨ）を用いてメディアデータのストリーミングのための情報をシグナリングする方法であって、
    メディアコンテンツのメディアプレゼンテーション記述（ＭＰＤ）のためのデータを生成することと、ここにおいて、前記ＭＰＤは、クライアントデバイスがソースデバイスからの前記メディアコンテンツのデータを取り出すことができる掛け時計時刻を示すデータを含む、および、ここにおいて、前記生成されたデータは、前記クライアントデバイスが前記掛け時計時刻を前記クライアントデバイスのクロックと同期させるべきである同期方法を示す、
    前記ＭＰＤを出力することと
    を備える方法。
11. 前記ＭＰＤによって示されるセグメントの掛け時計時刻に従って、前記メディアコンテンツの前記セグメントについての要求を受信することと、
    前記要求に応答して、前記セグメントを前記クライアントデバイスに送ることと
    をさらに備える、請求項１０に記載の方法。
12. 前記データを生成することが、前記同期方法がネットワークタイムプロトコル（ＮＴＰ）を備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＮＴＰサーバのネットワークアドレスを示すために、前記データを生成することを備える、請求項１０に記載の方法。
13. 前記データを生成することが、前記同期方法がＨＴＴＰタイミングプロトコル（ＨＴＰ）を備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すために、前記データを生成することを備える、または、
    前記データを生成することが、前記同期方法がＨＴＴＰを備えることを示すために、および、前記クライアントデバイスの前記クロックを前記掛け時計時刻と同期させるためのデータを要求するための１つまたは複数のＨＴＴＰサーバのネットワークアドレスを示すために前記データを生成することを備える、請求項１０に記載の方法。
14. 前記クライアントデバイスが第１のクライアントデバイスを備え、前記ＭＰＤのための前記データを生成することが、前記第１のクライアントデバイスが第１の時刻に前記メディアコンテンツのセグメントを取り出すべきであり、第２のクライアントデバイスが前記第１の時刻とは異なる第２の時刻に前記セグメントを取り出すべきであることを前記データが示すような前記ＭＰＤのための前記データを生成することを備え、前記ＭＰＤを送ることが、前記ＭＰＤを前記第１のクライアントデバイスおよび前記第２のクライアントデバイスに送ることを備える、請求項１０に記載の方法。
15. 第１の時刻にまたは前記第１の時刻の後に、第１のクライアントデバイスからの前記セグメントについての第１の要求を受信することと、
    前記第１の要求に応答して、前記セグメントについてのデータを前記第１のクライアントデバイスに送ることと、
    第２の時刻にまたは前記第２の時刻の後に、第２のクライアントデバイスからの前記セグメントについての第２の要求を受信することと、
    前記第２の要求に応答して、前記セグメントについての前記データを前記第２のクライアントデバイスに送ることと
    をさらに備え、
    前記データを生成することが、前記第１の時刻および前記第２の時刻についての特定の値を生成することを備える、または、
    前記第１のクライアントデバイスの第１の優先順位と、前記第２のクライアントデバイスの第２の優先順位とを決定することをさらに備え、前記データを生成することが、前記第１の優先順位および前記第２の優先順位に基づいて、前記データを生成することを備える、請求項１１に記載の方法。

Images