特許 7387209 ＨＴＴＰ上の動的適応ストリーミングのための方法および装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-17

(45)【発行日】2023-11-28

(54)【発明の名称】ＨＴＴＰ上の動的適応ストリーミングのための方法および装置

(51)【国際特許分類】

   H04N 21/437 20110101AFI20231120BHJP

   H04N 21/434 20110101ALI20231120BHJP

   H04N 21/84 20110101ALI20231120BHJP

   H04L 67/02 20220101ALI20231120BHJP

【ＦＩ】

H04N21/437

H04N21/434

H04N21/84

H04L67/02

【請求項の数】 9

(21)【出願番号】P 2022556616

(86)(22)【出願日】2021-09-24

(65)【公表番号】

(43)【公表日】2023-05-17

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

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

(87)【国際公開日】2022-07-14

【審査請求日】2022-09-20

(31)【優先権主張番号】63/134,049

(32)【優先日】2021-01-05

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

(31)【優先権主張番号】17/477,288

(32)【優先日】2021-09-16

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100150197

【弁理士】

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

(72)【発明者】

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

【審査官】鈴木 隆夫

(56)【参考文献】

【文献】特表２０１５－５３０００２（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２０／０２５０８９１（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０３７４４２９（ＵＳ，Ａ１）

【文献】国際公開第２０１６／０７６１３７（ＷＯ，Ａ１）

【文献】特表２０２２－５２６８０７（ＪＰ，Ａ）

【文献】特表２０２２－５２６００４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００－２１／８５８

Ｈ０４Ｌ ６７／０２

(57)【特許請求の範囲】

【請求項1】

メディアデータを受信する方法であって、前記方法は、
セッションを基にした記述（SBD）ファイルを示す必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信するステップであって、前記必須プロパティ記述子は、リソースを要求するために使用されるユニフォーム・リソース・ロケータ（URL）要求のクラスを示す属性を含み、前記クラスは前記要求されたリソースのタイプを識別する、ステップと、
前記SBDファイル、および前記必須プロパティ記述子に含まれる前記属性で示された前記クラスに基づいて、前記URL要求を生成するステップと、
前記URL要求の前記クラスに基づいて前記タイプが識別された前記リソースを要求するために、サーバに前記URL要求を送信するステップと、
を含む、方法。

【請求項2】

前記URL要求の前記クラスは、前記URL要求が、メディアセグメント要求、拡張マークアップ言語リンク付け言語（XLink）解決要求、MPD要求、コールバックイベントによってトリガされるコールバック要求、チェイニング先MPDへのチェイニング要求、またはフォールバックMPDへのフォールバック要求のうちの1つであることを示す、請求項1に記載の方法。

【請求項3】

生成する前記ステップは、
前記SBDファイルに含まれる複数のキー値ペアの中から第1のキー値ペアを選択するステップと、
前記第1のキー値ペアに基づいて、前記URL要求を生成するステップと、
を含む、請求項1または2に記載の方法。

【請求項4】

前記複数のキー値ペアは、前記SBDファイル内で順に配置され、前記複数のキー値ペアのそれぞれが、それぞれの順序番号を有し、前記SBDファイルは、前記複数のキー値ペアの中から前記第1のキー値ペアを選択する前記ステップが前記URL要求の前記クラスに基づいているかどうかを示す属性を含む、請求項3に記載の方法。

【請求項5】

前記SBDファイルに含まれる前記属性は、前記複数のキー値ペアの中から前記第1のキー値ペアを選択する前記ステップが、前記URL要求の前記クラスに基づいていることを示し、選択する前記ステップは、
前記複数のキー値ペアの中から第2のキー値ペアを決定するステップであって、前記第2のキー値ペアは、前記URL要求と同じクラスを有する、前のURL要求を生成するために使用される、ステップと、
前記第2のキー値ペアの順序番号に基づいて、前記複数のキー値ペアの中から前記第1のキー値ペアを選択するステップと、
を含む、請求項4に記載の方法。

【請求項6】

前記SBDファイルに含まれる前記属性は、前記複数のキー値ペアの中から前記第1のキー値ペアを選択する前記ステップが、前記URL要求の前記クラスに基づいていないことを示し、選択する前記ステップは、
前記複数のキー値ペアの中から第3のキー値ペアを決定するステップであって、前記第3のキー値ペアは直前のURL要求を生成するために使用される、ステップと、
前記第3のキー値ペアの順序番号に基づいて、前記複数のキー値ペアの中から前記第1のキー値ペアを選択するステップと、
を含む、請求項4に記載の方法。

【請求項7】

前記必須プロパティ記述子に含まれる前記属性のデフォルト値が、前記URL要求の前記クラスがメディアセグメント要求クラスであることを示す、請求項1から6のいずれか一項に記載の方法。

【請求項8】

請求項1から7のいずれか一項に記載の方法を実行するように構成された装置。

【請求項9】

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

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2021年1月5日に出願された米国仮出願第63/134,049号「A METHOD FOR EXTENDING THE SESSION-BASED DASH OPERATIONS TO DIFFERENT URL CLASSES」への優先権の利益を主張する、2021年9月16日に出願された米国特許出願第17/477,288号「METHODS AND APPARATUSES FOR DYNAMIC ADAPTIVE STREAMING OVER HTTP」への優先権の利益を主張する。先行する出願の開示は、その全体が参照によりここに組み込まれる。

【0002】

本開示は、一般に、ハイパーテキスト転送プロトコル上の動的適応ストリーミング（dynamic adaptive streaming over hypertext transfer protocol：DASH）のための方法および装置に関する実施形態を記載する。

【背景技術】

【0003】

本明細書で提供される背景技術の説明は、本開示の文脈を一般的に提示することを目的としている。この背景技術の項に記載されている限りにおいて、本明細書に記載されている発明者の研究、ならびに出願時に先行技術として認められない可能性がある説明の態様は、本開示に対する先行技術として明示的にも暗示的にも認められない。

【0004】

ハイパーテキスト転送プロトコル上の動画専門家集団（moving picture expert group, MPEG）動的適応ストリーミング（dynamic adaptive streaming over hypertext transfer protocol：DASH）は、IPネットワーク上でマルチメディアコンテンツをストリーミングするための規格を提供する。DASH規格は、メディアセグメント内でイベントメッセージボックスを搬送することを可能にする。

【発明の概要】

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

【0005】

本開示の態様は、メディアデータを受信するための装置を提供する。1つの装置は、セッションを基にした記述（SBD）ファイルを示す必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信する処理回路を含む。必須プロパティ記述子は、リソースを要求するために使用されるユニフォーム・リソース・ロケータ（URL）要求のクラスを示す属性を含む。クラスは、要求されたリソースのタイプを識別する。処理回路は、SBDファイル、および必須プロパティ記述子に含まれる属性で示されたクラスに基づいて、URL要求を生成する。処理回路は、URL要求のクラスに基づいてタイプが識別されたリソースを要求するために、サーバにURL要求を送信する。

【0006】

一実施形態では、URL要求のクラスは、URL要求が、メディアセグメント要求、XLink解決要求、MPD要求、コールバックイベントによってトリガされるコールバック要求、チェイニング先MPDへのチェイニング要求、またはフォールバックMPDへのフォールバック要求のうちの1つであることを示す。

【0007】

一実施形態において、処理回路は、SBDファイルに含まれる複数のキー値ペアの中から第1のキー値ペアを選択し、第1のキー値ペアに基づいてURL要求を生成する。

【0008】

一実施形態において、複数のキー値ペアは、SBDファイル内で順に配置される。複数のキー値ペアのそれぞれは、それぞれの順序番号を有する。SBDファイルは、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいているかどうかを示す属性を含む。

【0009】

一実施形態では、SBDファイルに含まれる属性は、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいていることを示す。処理回路は、複数のキー値ペアの中から第2のキー値ペアを決定する。第2のキー値ペアは、URL要求とクラスが同じである、前のURL要求の生成に使用される。処理回路は、第2のキー値ペアの順序番号に基づいて、複数のキー値ペアの中から第1のキー値ペアを選択する。

【0010】

一実施形態では、SBDファイルに含まれる属性は、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいていないことを示す。処理回路は、複数のキー値ペアの中から第3のキー値ペアを決定し、第3のキー値ペアは、直前のURL要求の生成に使用される。処理回路は、第3のキー値ペアの順序番号に基づいて、複数のキー値ペアの中から第1のキー値ペアを選択する。

【0011】

一実施形態では、必須プロパティ記述子に含まれる属性のデフォルト値は、URL要求のクラスがメディアセグメント要求クラスであることを示す。

【0012】

本開示の態様は、メディアデータを受信するための方法を提供する。本方法は、装置によって行われる1つのステップ、またはステップの組み合わせを含むことができる。1つの方法では、メディアプレゼンテーション記述（MPD）ファイルが受信される。MPDファイルは、セッションを基にした記述（SBD）ファイルを示す必須プロパティ記述子を含む。必須プロパティ記述子は、リソースを要求するために使用されるユニフォーム・リソース・ロケータ（URL）要求のクラスを示す属性を含む。クラスは、要求されたリソースのタイプを識別する。URL要求は、SBDファイル、および必須プロパティ記述子に含まれる属性で示されたクラスに基づいて生成される。URL要求のクラスに基づいてタイプが識別されたリソースを要求するために、URL要求がサーバに送信される。

【0013】

本開示の態様はまた、メディアデータを受信するためのコンピュータによって実行されると、コンピュータに、メディアデータを受信するための方法のいずれか1つまたは組み合わせを実行させる命令を記憶した非一時的コンピュータ可読媒体を提供する。

【0014】

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

【図面の簡単な説明】

【0015】

【図1】本開示の一実施形態による例示的なハイパーテキスト転送プロトコル上の動的適応ストリーミング（DASH）システムを示す図である。

【図2】本開示の一実施形態による別の例示的なセッションを基にしたDASHシステムを示す図である。

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

【図4】いくつかの実施形態による処理例の概要を示すフローチャートである。

【図5】一実施形態によるコンピュータシステムの概略図である。

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

【0016】

I．ハイパーテキスト転送プロトコル上の動的適応ストリーミング（dynamic adaptive streaming over hypertext transfer protocol, DASH）およびメディアプレゼンテーション記述（MPD）
ハイパーテキスト転送プロトコル上の動的適応ストリーミング（DASH）は、ウェブサーバ、コンテンツ配信ネットワーク（CDN）、様々なプロキシおよびキャッシュなどのハイパーテキスト転送プロトコル（HTTP）インフラストラクチャを使用してメディアコンテンツのストリーミングを可能にする適応ビットレートストリーミング技術である。DASHは、DASHサーバからDASHクライアントへのオンデマンドストリーミングとライブストリーミングの両方をサポートし、DASHクライアントがストリーミングセッションを制御することを可能にするので、DASHサーバは、大規模展開におけるストリーム適合化管理の追加負荷に対処する必要がない。DASHはまた、DASHクライアントが様々なDASHサーバからのストリーミングを選択することを可能にし、したがって、DASHクライアントの利益のためにネットワークのさらなる負荷分散を達成する。DASHは、例えば、ネットワーク状況に適応するようにビットレートを変えることによって、異なるメディアトラック間の動的切り替えを提供する。

【0017】

DASHにおいて、メディアプレゼンテーション記述（MPD）ファイルは、DASHクライアントがDASHサーバからメディアセグメントをダウンロードすることによってメディアコンテンツを適応的にストリーミングするための情報を提供する。MPDファイルは、セッション開始遅延を低減するために断片化され、部分的に配信され得る。MPDファイルは、ストリーミングセッション中に更新することもできる。いくつかの例では、MPDファイルは、コンテンツのアクセシビリティ機能、評価、およびカメラビューの表現をサポートする。DASHはまた、多視点でスケーラブルな符号化コンテンツの配信をサポートする。

【0018】

MPDファイルは、1つまたは複数の期間のシーケンスを含むことができる。1つまたは複数の期間のそれぞれは、MPDファイル内の期間要素により定義することができる。MPDファイルは、MPDのavailableStartTime属性と、期間ごとのstart属性とを含むことができる。（例えば、ライブサービスに使用される）動的タイプのメディアプレゼンテーションの場合、期間のstart属性とMPD属性availableStartTimeとメディアセグメントの持続時間との合計は、協定世界時（UTC）フォーマットにおける期間、特に、対応する期間における各表現の第1のメディアセグメントの利用可能時間を示すことができる。静的タイプ（例えば、オンデマンドサービスに使用される）でのメディアプレゼンテーションの場合、第1の期間のstart属性は0とすることができる。任意の他の期間について、start属性は、第1の期間の開始時間に対する対応する期間の開始時間の間の時間オフセットを指定することができる。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで延長することができる。期間開始時間は正確であり得、すべての前の期間のメディアの再生から生じる実際のタイミングを反映することができる。

【0019】

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

【0020】

MPDファイルのグループ属性が示すグループには、特定の期間のアダプテーションセットを割り当てることができる。同じグループ内のアダプテーションセットは、一般に、互いに代替と見なされる。例えば、特定の期間のビデオデータの各アダプテーションセットを同じグループに割り当てることができ、その結果、対応する期間のマルチメディアコンテンツのビデオデータを表示するために、いずれかのアダプテーションセットを復号のために選択することができる。1つの期間内のメディアコンテンツは、存在する場合、グループ0からの1つのアダプテーションセット、またはいくつかの例では、各非ゼログループからの最大1つのアダプテーションセットの組み合わせのいずれかによって表すことができる。期間の表現ごとのタイミングデータは、期間の開始時間に対して表現することができる。

【0021】

表現は、1つまたは複数のセグメントを含むことができる。各表現は初期化セグメントを含むことができ、または表現の各セグメントは自己初期化することができる。存在する場合、初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。場合によっては、初期化セグメントはメディアデータを含まない。セグメントは、ユニフォーム・リソース・ロケータ（URL）、ユニフォームリソース名（URN）、またはユニフォームリソース識別子（URI）などの識別子によって一意に参照することができる。MPDファイルは、セグメントごとに識別子を提供することができる。いくつかの例では、MPDファイルは、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのデータに対応することができる範囲属性の形式のバイト範囲を提供することもできる。

【0022】

各表現はまた、1つまたは複数のメディアコンポーネントを含むことができ、各メディアコンポーネントは、オーディオ、ビデオ、または時限テキスト（例えば、クローズドキャプション用）などの1つの個々のメディアタイプの符号化バージョンに対応することができる。メディアコンポーネントは、1つの表現内の連続するメディアセグメントの境界にわたって時間的に連続的であり得る。

【0023】

いくつかの実施形態では、DASHクライアントは、DASHサーバからMPDファイルにアクセスしてダウンロードすることができる。すなわち、DASHクライアントは、ライブセッションの開始に用いられるMPDファイルを取得することができる。MPDファイルに基づいて、および選択された各表現について、DASHクライアントは、サーバ上で利用可能な最新のセグメントが何であるかを判定すること、次のセグメントおよび場合によっては将来のセグメントのセグメント可用性開始時間を判定すること、セグメント内のどのタイムラインから、セグメントの再生をいつ開始するかを判定すること、ならびに新しいMPDファイルをいつ取得／フェッチするかを判定することを含む、いくつかの決定を行うことができる。サービスが再生されると、クライアントはライブサービスとそれ自体の再生との間のドリフトを追跡することができ、それは検出および補償される必要がある。

【0024】

II．セッションを基にしたDASH動作およびセッションを基にした記述（SBD）
MPDファイルは、すべてのDASHクライアントに対して汎用であり得ることに留意されたい。MPEG（Moving Picture Expert Group）は、DASHクライアントのセッション固有のMPDファイルとするために、セッションを基にしたDASH動作を提供する。セッションを基にしたDASH動作では、DASHクライアントは、DASHクライアントがセッションごとに、場合によってはクライアントごとにMPDファイルをカスタマイズするための命令を提供する、セッションを基にした記述（SBD）ファイルなどのサイドファイルを受信することができる。しかしながら、いくつかの関連する例では、セッションを基にしたDASH動作はアプリケーション固有である。すなわち、新しいアプリケーションごとに、新しいSBDフォーマットが必要である。

【0025】

本開示は、SBD情報を使用して、セグメントURLだけでなくクラスが異なるURLをカスタマイズするために、SBDセッションを拡張する方法を含む。

【0026】

図1は、本開示の一実施形態による例示的なDASHシステム（100）を示している。DASHシステム（100）では、DASHサーバ（101）（例えば、コンテンツサーバ）からDASHクライアント（102）にMPDファイルが送られる。DASHクライアント（102）は、MPDファイルに基づいて、DASHサーバ（101）からメディアセグメントを受信することができる。DASHクライアント（102）は、MPDファイルの更新要求をDASHサーバ（101）に送信することができる。DASHサーバ（101）は、主コンテンツ（例えば、メインプログラム）、および1つ以上の時限メタデータトラックを含む、コンテンツストリームを提供することができる。また、DASHクライアント（102）は、DASHサーバ（101）や第三者（例えば、セッションコントローラ）からSBDファイルを受信することができる。

【0027】

本開示の態様によれば、SBDファイルは、追加のメタデータと共に、複数の時間範囲および対応するキー値ペア（または名前と値のペア）を含むことができる。SBDファイルは、例えばURLによってMPDファイル内で参照することができる。SBDファイルを使用して、DASHクライアント（102）によって受信されたMPDファイルをDASHクライアント（102）のセッション固有のものであるようにカスタマイズすることができる。例えば、SBDファイルは、一意のセッションごとのMPDを生成することなく、セッション固有の要素をセグメントURLに追加することを可能にすることができる。

【0028】

図2は、本開示の一実施形態による別の例示的なセッションを基にしたDASH動作アーキテクチャ200を示す。セッションを基にしたDASH動作アーキテクチャ 200 では、オーディオソース（例えば、マイクロフォン）およびビデオソース（例えば、ビデオカメラ）を含むことができるコンテンツ生成デバイス（201）（例えば、スマートフォン）によってマルチメディアコンテンツが準備され、生成される。マルチメディアコンテンツは、コンテンツ生成デバイス（201）によって記憶することができ、または様々なマルチメディアコンテンツを記憶することができるコンテンツサーバ（202）に送信することができる。コンテンツサーバ（202）は、マルチメディアコンテンツの1つまたは複数のメディアセグメントに対する、DASHアクセスクライアント（203）などのクライアントデバイスからの要求を受信することができる。マルチメディアコンテンツは、MPDファイルによって記述され、MPDファイルは、コンテンツサーバ（202）によって記憶および更新され、メディアセグメントを取得するためにDASHアクセスクライアント（203）を含むクライアントデバイスによってアクセスされることができる。

【0029】

セッション固有のメディアセグメントを取得するために、DASHアクセスクライアント（203）は、SBDクライアント（204）によって受信された、現在のセッションについての複数の時間範囲および対応するキー値ペアを含むSBDファイルにアクセスするための要求をSBDクライアント（204）（例えば、セッションクライアント）に送信することができる。例えば、DASHアクセスクライアント（203）は、キー名および時間範囲をSBDクライアント（204）に送信することができ、次いで、SBDクライアントは、キー名および時間範囲を解析し、キー名および時間範囲に対応する値をDASHアクセスクライアント（203）に返す。DASHアクセスクライアント（203）は、セグメント要求がHTTP GETまたは部分GET要求である場合に、セッション固有のメディアセグメントを要求するためにコンテンツサーバ（202）に送信することができるセグメントURLのクエリに値を含めることができる。

【0030】

SBDクライアント（204）は、セッションコントローラ（205）およびセッションコントローラ（206）などの異なるセッションコントローラから複数のSBDファイルを受信することができることに留意されたい。

【0031】

本開示の態様によれば、コンテンツサーバ（202）（例えば、DASHサーバ）の機能のうちのいずれかまたはすべては、ルータ、ブリッジ、プロキシデバイス、スイッチ、またはその他のデバイスなどの、コンテンツ配信ネットワーク（CDN）の1つまたは複数のデバイスにおいて実施され得る。コンテンツサーバ（202）は、クライアントデバイス（例えば、DASHアクセスクライアント（203））からネットワーク要求を受信するように構成された要求処理ユニットを含むことができる。例えば、要求処理ユニットは、HTTP GET要求または部分GET要求を受信し、要求に応答してマルチメディアコンテンツのデータを提供するように構成することができる。要求は、セグメントのURLを使用してセグメントを指定することができる。いくつかの例では、要求はセグメントの1つまたは複数のバイト範囲を指定することもでき、したがって部分GET要求を含む。要求処理ユニットは、セグメントのヘッダデータを提供するためにHTTP HEAD要求を処理するようにさらに構成することができる。

【0032】

いくつかの実施形態では、コンテンツ生成デバイス（201）およびコンテンツサーバ（202）は、無線ネットワークもしくは有線ネットワークによって結合することができ、または直接通信可能に結合することができる。

【0033】

いくつかの実施形態では、コンテンツ生成デバイス（201）およびコンテンツサーバ（202）は、同じデバイスに含まれ得る。

【0034】

いくつかの実施形態では、コンテンツサーバ（202）およびセッションコントローラ（205）～（206）は、同じデバイスに含まれ得る。

【0035】

いくつかの実施形態では、コンテンツサーバ（202）およびDASHアクセスクライアント（203）は、無線ネットワークまたは有線ネットワークによって結合することができる。

【0036】

いくつかの実施形態では、SBDクライアント（204）およびセッションコントローラ（205）～（206）は、無線ネットワークもしくは有線ネットワークによって結合することができ、または直接通信可能に結合することができる。

【0037】

いくつかの実施形態では、DASHアクセスクライアント（203）およびSBDクライアント（204）は、同じデバイスに含めることができる。

【0038】

本開示の態様によれば、複数のSBDをMPDにリンクさせるために、セッションを基にしたDASH用の1つ以上の必須プロパティ記述子をMPDレベルで使用でき、セッションを基にしたDASH用の各必須プロパティ記述子は、同様または同一の必須プロパティ記述子属性を含む。

【0039】

図3は、本開示の一実施形態による例示的なDASHクライアントアーキテクチャを示す図である。DASHクライアント（またはDASHプレーヤ）は、アプリケーション（312）と通信し、（i）MPDイベント、（ii）インバンドイベント、および（iii）時限メタデータイベントを含む様々な様式のイベントを処理するように構成することができる。

【0040】

マニフェストパーサ（310）はマニフェスト（例えば、MPD）を解析することができる。例えばDASHサーバ（101）によってマニフェストを提供することができる。マニフェストパーサ（310）は、時限メタデータトラックに埋め込まれたMPDイベント、インバンドイベントおよび時限メタデータイベントに関するイベント情報を抽出することができる。抽出されたイベント情報を、DASHロジック（311）（例えば、DASHプレーヤの制御、選択、および発見的ロジック）に提供することができる。DASHロジック（311）は、イベント情報に基づいて、マニフェスト内でシグナリングされたイベントスキームをアプリケーション（312）に通知することができる。

【0041】

イベント情報は、異なるイベントストリームを区別するためのイベントスキーム情報を含むことができる。アプリケーション（312）は、イベントスキーム情報を使用して関心のあるイベントスキームにサブスクライブすることができる。アプリケーション（312）は、1つまたは複数のサブスクリプション用アプリケーション・プログラミング・インターフェース（API）を介してサブスクライブされたスキームの各々の所望の発信モードをさらに示すことができる。例えば、アプリケーション（312）は、関心のある1つまたは複数のイベントスキームおよび任意の所望の対応発信モードを識別するサブスクリプション要求をDASHクライアントに送信することができる。

【0042】

アプリケーション（312）が、1つまたは複数の時限メタデータトラックの一部として配信される1つまたは複数のイベントスキームにサブスクライブする場合、インバンドイベントおよび「moof」パーサ（303）は、1つまたは複数の時限メタデータトラックを時限メタデータトラックパーサ（304）にストリーミングすることができる。例えば、インバンドイベントおよび「moof」パーサ（303）は、ムービーフラグメントボックス（「moof」）を解析し、続いて、DASHロジック（311）からの制御情報に基づいて時限メタデータトラックを解析する。

【0043】

時限メタデータトラックパーサ（304）は、時限メタデータトラックに埋め込まれたイベントメッセージを抽出することができる。抽出されたイベントメッセージを、イベントおよび時限メタデータバッファ（306）に記憶することができる。シンクロナイザ／ディスパッチャモジュール（308）（例えば、イベントおよび時限メタデータのシンクロナイザおよびディスパッチャ）は、サブスクライブされたイベントをアプリケーション（312）に発信（または送信）することができる。

【0044】

MPDに記述されたMPDイベントを、マニフェストパーサ（310）によって解析し、かつイベントおよび時限メタデータバッファ（306）に記憶することができる。例えばマニフェストパーサ（310）は、MPDの各イベントストリーム要素を解析し、かつ各イベントストリーム要素に記述された各イベントを解析する。MPD内でシグナリングされた各イベントについて、プレゼンテーション時間およびイベント持続時間などのイベント情報を、イベントに関連付けられたイベントおよび時限メタデータバッファ（306）に記憶することができる。

【0045】

インバンドイベントおよび「moof」パーサ（303）は、メディアセグメントを解析して、インバンドイベントメッセージを抽出することができる。任意のこのような識別されたインバンドイベントおよび関連するプレゼンテーション時間および持続時間を、イベントおよび時限メタデータバッファ（306）に記憶することができる。

【0046】

したがって、イベントおよび時限メタデータバッファ（306）は、その中にMPDイベント、インバンドイベントおよび／または時限メタデータイベントを記憶することができる。イベントおよび時限メタデータバッファ（306）を、例えば先入れ先出し（FIFO）バッファとすることができる。イベントおよび時限メタデータバッファ（306）を、メディアバッファ（307）に対応して管理することができる。例えば、メディアセグメントがメディアバッファ（307）内に存在する限り、そのメディアセグメントに対応する任意のイベントまたは時限メタデータをイベントおよび時限メタデータバッファ（306）に記憶することができる。

【0047】

DASHアクセスAPI（302）は、HTTPプロトコルスタック（201）を介したメディアコンテンツや各種メタデータを含むコンテンツストリーム（あるいはデータフロー）のフェッチや受信を管理することができる。DASHアクセスAPI（302）は、受信したコンテンツストリームを異なるデータフローに分離することができる。インバンドイベントおよび「moof」パーサ（303）に提供されるデータフローは、メディアセグメント、1つまたは複数の時限メタデータトラック、およびメディアセグメントに含まれるインバンドイベントシグナリングを含むことができる。一実施形態では、マニフェストパーサ（310）に提供されるデータフローはMPDを含むことができる。

【0048】

DASHアクセスAPI（302）は、マニフェストをマニフェストパーサ（310）に転送することができる。イベントを記述することに加えて、マニフェストは、アプリケーション（312）およびインバンドイベントおよび「moof」パーサ（303）と通信することができるDASHロジック（311）にメディアセグメントに関する情報を提供することもできる。アプリケーション（312）を、DASHクライアントによって処理されるメディアコンテンツに関連付けることができる。アプリケーション（312）と、DASHロジック（311）と、マニフェストパーサ（310）と、DASHアクセスAPI（302）との間でやりとりされる制御・同期信号は、マニフェストに記述されたメディアセグメントに関する情報に基づいて、HTTPスタック（201）からのメディアセグメントのフェッチを制御することができる。

【0049】

インバンドイベントおよび「moof」パーサ（303）は、メディアデータフローを解析して、メディアコンテンツ、時限メタデータトラック内の時限メタデータ、およびメディアセグメント内の任意のシグナリングされたインバンドイベントを含むメディアセグメントにすることができる。メディアコンテンツを含むメディアセグメントを、ファイルフォーマットパーサ（305）によって解析し、メディアバッファ（307）に記憶することができる。

【0050】

イベントおよび時限メタデータバッファ（306）に記憶されたイベントは、シンクロナイザ／ディスパッチャ（308）が、イベント／メタデータAPIを介してアプリケーション（312）に関連する利用可能なイベント（または関心のあるイベント）をアプリケーション（312）に通信することを可能にすることができる。アプリケーション（312）は、利用可能なイベント（例えば、MPDイベント、インバンドイベント、または時限メタデータイベント）を処理し、シンクロナイザ／ディスパッチャ（308）に通知することによって特定のイベントまたは時限メタデータにサブスクライブするように構成することができる。アプリケーション（312）に関連しないがその代わりにDASHクライアント自体に関連するイベントおよび時限メタデータバッファ（306）に記憶された任意のイベントを、さらなる処理のためにシンクロナイザ／ディスパッチャ（308）によってDASHロジック（311）に転送することができる。

【0051】

特定のイベントにサブスクライブするアプリケーション（312）に応答して、シンクロナイザ／ディスパッチャ（308）は、アプリケーション（312）がサブスクライブしているイベントスキームに対応するアプリケーション（312）のイベントインスタンス（または時限メタデータのサンプル）と通信することができる。イベントインスタンスは、（例えば、特定のイベントスキームについて）サブスクリプション要求によって示される発信モードまたはデフォルトの発信モードに従って通信され得る。例えば受信時発信モードでは、イベントインスタンスは、イベントおよび時限メタデータバッファ（306）での受信時にアプリケーション（312）に送信されてもよい。一方、開始時発信モードでは、イベントインスタンスは、例えばメディアデコーダ（309）からのタイミング信号と同期して、それらの関連付けられたプレゼンテーション時間にアプリケーション（312）に送信されてもよい。

【0052】

DASHクライアントアーキテクチャでは、太いデータフロー線はメディアデータフローを示し、狭いデータフロー線は偶数および時限メタデータデータフローを示し、破線データフロー線は制御および同期を示すことに留意されたい。さらに、同じ処理モデルをCMAFイベントに使用することができる。

【0053】

III．URLに対するURLクラスのシグナリング
セッションを基にしたDASH動作は、MPDをセッションごとに、あるいはクライアントごとにカスタマイズするための重要な手法である。しかしながら、いくつかの関連する例では、SBDセッションではセグメント要求URLのみがカスタマイズされることを許容され得る。

【0054】

本開示は、SBD情報を使用して、セグメント要求URLだけでなくクラスが異なるURLをカスタマイズするために、SBDセッションを拡張する方法を含む。

【0055】

本開示の態様によれば、カスタマイズされるURLのクラスは一般化され得る、あるいはSBD動作（クエリまたはURLカスタマイズあるいはその両方）から、セグメント要求以外にクラスが異なるURL要求まで拡張することができる。

【0056】

したがって、SBD動作は、（i）セグメント要求、（ii）拡張マークアップ言語リンク付け言語（XLink）解決要求、（iii）MPD要求、（iv）DASHコールバックイベントによってトリガされた全要求、（v）チェイニング先MPDへの全ての要求、（vi）フォールバックMPDへの全ての要求、といったURL要求のうちの1つ以上に適用できるようにすることができる。

【0057】

各URLクラスは、セグメント、XLink解決などの同じ目的を持つリソースを要求するためにDASHクライアントによって使用される、1つ以上のURLを定義することができる。

【0058】

DASHコールバックイベントは、所与のURLにHTTP GET要求を出し、HTTP応答を無視することをDASHクライアントによって期待される、コンテンツ内の指示である。コンテンツ作成者は、メディアパスに含まれていないサーバでの特定のコンテンツの再生を追跡するために、このようなイベントを使用する場合がある。

【0059】

MPDチェイニングは、1つのメディアプレゼンテーションの終了において、新しいメディアプレゼンテーションが開始することを示すためのメカニズムを提供する。終了は通常の終了であってよく、あるいはエラー状態のために早期終了になってもよい。このメカニズムを可能にするために、「チェイニング元」MPDは、「チェイニング先」MPDの位置を指す必須記述子または補足記述子を含んでよい。

【0060】

MPDチェイニングは、通常チェイニングおよびフォールバックチェイニングの2つを含むことができる。通常チェイニングは、「チェイニング先」MPDが「チェイニング元」MPDの終了において再生される動作のことをいう。フォールバックチェイニングは、「チェイニング先」MPDがエラー状態のために早期に終了したときにのみ、「チェイニング元」MPDが再生される動作のことをいう。

【0061】

本開示の態様によれば、URLのURLクラスは、MPDファイルに含まれる必須プロパティ記述子内に示すことができる。必須プロパティ記述子はセッションを基にしたDASH動作に使用され、SBDセッション用のSBDファイルを示す。プレゼンテーション記述子は、必須プロパティ記述子または補足プロパティ記述子のいずれかであってよいことに留意されたい。必須プロパティの場合、メディアプレゼンテーション作成者は、この記述子を含む親要素内の情報を適切に使用するためには、要素が別のEssentialProperty要素と同じ＠idを共有していない限り、記述子の処理の成功が必須であることを表している。これとは対照的に、補足プロパティの場合は、メディアプレゼンテーションの作成者は、記述子が、処理の最適化のためにDASHクライアントによって使用され得る補足情報を含んでいることを表している。

【0062】

表1は、適用可能なURLクラスを指定する属性を含む、例示的な必須プロパティ記述子を示す。表において、属性＠urlClassは、どのURLクラスがSBD処理の対象になるかを指定することができる。属性＠urlClassの値が異なれば、別の許容されるURLクラスを示すことができる。例えば、属性＠urlClassの値「xlink」は、URLのクラスがXLink解決要求であることを示す。属性＠urlClassのデフォルト値は「segment」であり、URLのクラスがメディアセグメント要求であることを示す。

【0063】

【表1A】

【表1B】

【表1C】

【0064】

本開示の態様によれば、SBDファイルはそのタイムラインの2つのモデルを含むことができ、それは時間を基にしたおよび順序を基にしたものである。各SBDファイルは時間を基にした、または順序を基にした、のいずれかのタイムラインを使用でき、両方を使用することはできない。順序を基にしたタイムラインは、オーダーラインとも称される。SBDクライアントは、SBDファイルのタイムラインまたはオーダーラインに基づいてSBD処理を実行することができる。

【0065】

時間を基にしたタイムラインの場合、SBDファイルに含まれる複数のキー値ペアのうちの1つを識別するために、時間範囲を使用することができる。したがって、SBDクライアントがURL要求を処理するときは、URL要求のURLクラスは、URL要求処理にいかなる影響も及ぼさない。つまり、様々なURLクラスが混合していても、SBDクライアントによって実行されるURL処理にいかなる影響も及ぼさない。

【0066】

しかしながら、順序を基にしたタイムラインの場合は、SBDファイルに含まれる複数のキー値ペアのうちの1つを識別するために、順序番号が使用される。複数のキー値ペアのうちの1つの順序番号は、URL要求のURLクラスに依存する場合がある。したがって、URL要求のSBD処理には2つのシナリオがあり得る。

【0067】

第1のシナリオは、個別URLクラス処理と称することができ、URLのURLクラスに基づいてURLを処理することができる。SBD処理は、同じクラスに属するURLのオーダーライン（順序を基にしたタイムライン）のみを進め、他のクラスに対しては進めない。一実施形態において、各URLクラスは、それぞれのURLクラスのキー値ペアを指す、分離した仮想ポインタに対応することができる。例えば、メディアセグメントURLクラスは、メディアセグメントURLクラスに属する、第1の前のURLクラスに使用される第1のキー値ペアを指す、第1の仮想ポインタを有することができ、XLink解決URLクラスは、XLink解決URLクラスに属する、第2の前のURLクラスに使用される第2のキー値ペアを指す、第2の仮想ポインタを有することができる。現在のURLクラスがメディアセグメントURLクラスに属する場合は、第1の仮想ポインタは、オーダーラインに従って第1のキー値ペアの次の第3のキー値ペアに移動し、第1のキー値ペアに指された第3のキー値ペアを現在のURLクラスに使用することができる。現在のURLクラスがXLink解決URLクラスに属する場合は、第2の仮想ポインタは、オーダーラインに従って第2のキー値ペアの次の第4のキー値ペアに移動し、第2のキー値ペアに指された第4のキー値ペアを現在のURLクラスに使用することができる。したがって、このようにして、現在のURLのSBD処理は、次のURLが現在のURLとは異なるクラスからのものであれば、次のURLのSBD処理に影響を及ぼさない。

【0068】

第2のシナリオは、一括URLクラス処理と称することができ、URLは、URLのURLクラスにかかわらず順に処理することができる。一実施形態では、全URLクラスが、直前のURLのキー値ペアを指す、同じ仮想ポインタを共有することができる。例えば、直前のURLに1つのキー値ペアが使用される場合は、現在のURLと直前のURLとが同じURLクラスに属しているかどうかに関係なく、オーダーラインに従って、1つのキー値ペアの次にある、別のキー値ペアを現在のURLに使用することができる。したがって、このようにして、現在のURLのSBD処理によって、次のURLのURLクラスにかかわらず、次のURLのSBD処理の結果が変わり得る。これは、URLクラスを考慮することのない、各URL処理の順序を基にしたタイムラインの進歩による。

【0069】

表2は、SBD処理の個別処理または一括処理を示す属性を含む、例示的なオーダーラインモデルを示している。表2において、一括の属性が「真」に設定されると、URLは、一括URLクラス処理に基づいて処理することができる。一括の属性が「偽」に設定されると、URLは、個別URLクラス処理に基づいて処理することができる。一括の属性のデフォルト値は「偽」に設定される。

【0070】

【表2】

【0071】

本開示の態様によれば、SBD処理を、セグメント要求以外にURL要求の別のクラスまで拡張する方法が提供される。本方法では、拡張されたクラスは、セグメント要求、XLink解決要求、MPD要求、DASHコールバックイベントによってトリガされる要求、チェイニング先MPDへの要求、およびフォールバックMPDへの要求を含むことができる。MPDファイルに含まれる必須プロパティ記述子などのマニフェストでは、1つ以上のURLクラスをシグナリングでき、その結果、SBDクライアントは、このようなクラスに属するURLにSBD処理を適用することができる。SBD処理は、URLのカスタマイズ、およびURLクエリの追加を含む。

【0072】

本開示の態様によれば、URLクラスをオーダーライン処理する第1の方法が提供される。第1の方法において、受信したURLはいずれもオーダーラインテーブルを使用して処理することができる。テーブルは、URLクラスにかかわらず次のエントリに進めることができる。処理する第1の方法は、SBDファイル内の属性などのフラグを使用してシグナリングすることができる。

【0073】

本開示の態様によれば、URLクラスをオーダーライン処理する第2の方法が提供される。第2の方法では、受信した個別のクラスのURLはいずれも、他のクラスから分離されたオーダーラインテーブルを使用して処理することができる。テーブルは、同じクラスに属している（かつ他のクラスに属していない）受信URLに対してのみ、次のエントリに進めることができる。第2の処理方法は、SBDファイル内の属性などのフラグを使用してシグナリングすることができる。

【0074】

IV．フローチャート
図4は、本開示の一実施形態による処理（400）の概要を示すフローチャートを示している。様々な実施形態において、処理（400）は、DASHクライアント（102）の処理回路などの処理回路によって実行される。いくつかの実施形態では、処理（400）はソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路は処理（400）を実行する。処理（400）は、当該処理（400）が、SBDファイルを示す必須プロパティ記述子を含む、MPDファイルを受信すること（S410）から開始される。必須プロパティ記述子は、リソースを要求するために使用される、URL要求のクラスを示す属性を含む。クラスは、要求されたリソースのタイプを識別する。そして、処理（400）は、ステップ（S420）に進む。

【0075】

ステップ（S420）において、処理（400）は、SBDファイル、および必須プロパティ記述子に含まれる属性で示されたクラスに基づいて、URL要求を生成する。そして、処理（400）は、ステップ（S430）に進む。

【0076】

ステップ（S430）において、処理（400）は、URL要求のクラスによってタイプが識別されたリソースを要求するために、サーバにURL要求を送信する。そして、処理（400）は終了する。

【0077】

一実施形態では、URL要求のクラスは、URL要求のタイプが、メディアセグメント要求、XLink解決要求、MPD要求、コールバックイベントによってトリガされるコールバック要求、チェイニング先MPDへのチェイニング要求、またはフォールバックMPDへのフォールバック要求のうちの1つであることを示す。

【0078】

一実施形態において、処理（400）は、SBDファイルに含まれる複数のキー値ペアの中から第1のキー値ペアを選択し、第1のキー値ペアに基づいてURL要求を生成する。

【0079】

一実施形態において、複数のキー値ペアは、SBDファイル内で順に配置される。複数のキー値ペアのそれぞれは、それぞれの順序番号を有する。SBDファイルは、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいているかどうかを示す属性を含む。

【0080】

一実施形態では、SBDファイルに含まれる属性は、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいていることを示す。処理（400）は、複数のキー値ペアから第2のキー値ペアを決定する。第2のキー値ペアは、URL要求とクラスが同じである、前のURL要求の生成に使用される。処理（400）は、第2のキー値ペアの順序番号に基づいて、複数のキー値ペアの中から第1のキー値ペアを選択する。

【0081】

一実施形態では、SBDファイルに含まれる属性は、複数のキー値ペアの中から第1のキー値ペアを選択することが、URL要求のクラスに基づいていないことを示す。処理（400）は、複数のキー値ペアの中から第3のキー値ペアを決定し、第3のキー値ペアは、直前のURL要求の生成に使用される。処理（400）は、第3のキー値ペアの順序番号に基づいて、複数のキー値ペアの中から第1のキー値ペアを選択する。

【0082】

一実施形態では、必須プロパティ記述子に含まれる属性のデフォルト値は、URL要求のクラスがメディアセグメント要求クラスであることを示す。

【0083】

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

【0084】

コンピュータソフトウェアは、1つ以上のコンピュータ中央処理装置（CPU：central processing unit）およびグラフィック処理装置（GPU：Graphics Processing Unit）などによって直接的に、または解釈およびマイクロコードの実行などを通して実行され得る命令を含むコードを作成するために、アセンブリ、コンパイル、リンキング、または同様のメカニズムを受け得る任意の適切な機械コードまたはコンピュータ言語を使用してコード化され得る。

【0085】

命令は、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネット装置などを含む、様々な種類のコンピュータまたはその構成要素で実行することができる。

【0086】

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

【0087】

コンピュータシステム（500）は、特定のヒューマンインターフェース入力装置を含み得る。そのようなヒューマンインターフェース入力装置は、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（音声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）など、1人以上のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスは、音声（発話、音楽、周囲音など）、画像（走査画像、静止画カメラで取得される写真画像など）、ビデオ（二次元ビデオ、立体ビデオを含む三次元ビデオなど）などの人による意識的な入力に必ずしも直接関与しない、いくつかの媒体の捕捉にさらに使用することができる。

【0088】

入力ヒューマンインターフェース装置には、キーボード（501）、マウス（502）、トラックパッド（503）、タッチスクリーン（510）、データグローブ（図示せず）、ジョイスティック（505）、マイク（506）、スキャナ（507）、カメラ（508）のうち1つまたは複数（それぞれ1つのみ図示される）が含まれ得る。

【0089】

コンピュータシステム（500）はまた、特定のヒューマンインターフェース出力装置を含み得る。そのようなヒューマンインターフェース出力装置は、例えば、触覚出力、音、光、および嗅覚／味覚を通じて、1人または複数の人間のユーザの感覚を刺激している可能性がある。そのようなヒューマンインターフェース出力装置は、触覚出力装置（例えば、タッチスクリーン（510）、データグローブ（図示せず）、またはジョイスティック（505）による触覚フィードバックを含み得るが、入力装置として機能しない触覚フィードバック装置もあり得る）、音声出力装置（スピーカ（509）、ヘッドホン（図示せず）など）、視覚的出力装置（それぞれにタッチスクリーン入力機能の有無にかかわらず、それぞれ触覚フィードバック機能の有無にかかわらず、ステレオグラフィック出力、仮想現実の眼鏡（図示せず）、ホログラフィックディスプレイおよびスモークタンク（図示せず）などの手段により、2次元の視覚的出力または3次元以上の出力を出力できるものもある、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン（510）など）、およびプリンタ（図示せず）を含み得る。これらの視覚的出力装置（スクリーン（510）など）は、グラフィックスアダプタ（550）を介してシステムバス（548）に接続することができる。

【0090】

コンピュータシステム（500）には、人間がアクセスできる記憶装置と、CD／DVDを含むCD／DVD ROM／RW（520）などの光学メディア（521）、サムドライブ（522）、リムーバブルハードドライブまたはソリッド・ステート・ドライブ（523）、テープおよびフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの専用のROM／ASIC／PLDを基にした装置などの関連媒体も含めることができる。

【0091】

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

【0092】

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

【0093】

前述のヒューマンインターフェース装置、ヒューマンアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム（500）のコア（540）に接続することができる。

【0094】

コア（540）には、1つまたは複数の中央処理装置（CPU）（541）、グラフィックス処理装置（GPU）（542）、フィールド・プログラマブル・ゲート・エリア（FPGA）（543）、特定のタスクのハードウェアアクセラレータ（544）などの形式の特殊なプログラマブル処理装置を含めることができる。これらの装置は、読み取り専用メモリ（ROM）（545）、ランダムアクセスメモリ（546）、ユーザがアクセスできない内部ハードドライブ、SSDなどの内部大容量記憶装置（547）と共に、システムバス（548）を介して接続され得る。いくつかのコンピュータシステムでは、システムバス（548）に1つまたは複数の物理プラグの形でアクセスして、追加のCPU、GPUなどによる拡張を可能にすることができる。周辺機器は、コアのシステムバス（548）に直接、または周辺バス（549）を介して接続できる。周辺バスのアーキテクチャは、PCIおよびUSBなどを含む。

【0095】

CPU（541）、GPU（542）、FPGA（543）、およびアクセラレータ（544）は、組み合わせて前述のコンピュータ符号を構成できる特定の命令を実行できる。そのコンピュータ符号は、ROM（545）またはRAM（546）に記憶できる。移行データはRAM（546）に格納することもできるが、恒久的データは例えば内部大容量記憶装置（547）に格納できる。1つまたは複数のCPU（541）、GPU（542）、大容量記憶装置（547）、ROM（545）、RAM（546）などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリ装置に対する高速記憶および読み出しが可能になる。

【0096】

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

【0097】

限定ではなく例として、アーキテクチャを有するコンピュータシステム（500）、特にコア（540）は、1つまたは複数の有形のコンピュータ可読媒体に組み込まれたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供できる。このようなコンピュータ可読媒体は、上で紹介したユーザがアクセス可能な大容量記憶装置、およびコア内部大容量記憶装置（547）やROM（545）などの非一時的な性質を持つコア（540）の特定の記憶装置に関連付けられた媒体であり得る。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に記憶され、コア（540）によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリ装置またはチップを含み得る。ソフトウェアは、コア（540）、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM（546）に記憶されているデータ構造を定義すること、ソフトウェアで定義された処理に従ってそのようなデータ構造を変更することを含む、ここで説明する特定の処理または特定の処理の特定の部分を実行させることができる。加えて、または代替として、コンピュータシステムは、ここで説明する特定の処理または特定の処理の特定の部分を実行するためにソフトウェアの代わりに、またはソフトウェアと一緒に動作できる、回路（例：アクセラレータ（544））に組み込まれたまたは他の方法で実装されたロジックの結果として機能を提供できる。ソフトウェアへの参照はロジックを含むことができ、その逆も適宜可能である。適切な場合には、コンピュータ可読媒体への言及は、実行のためのソフトウェアを記憶する回路（集積回路（IC：integrated circuit）など）、実行のためのロジックを具現化する回路、またはこれらの両方を包含し得る。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含する。

【0098】

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

【符号の説明】

【0099】

100 DASHシステム
101 DASHサーバ
102 DASHクライアント
200 DASH動作アーキテクチャ
201 コンテンツ生成デバイス
202 コンテンツサーバ
203 DASHアクセスクライアント
204 SBDクライアント
205 セッションコントローラ
206 セッションコントローラ
301 HTTPスタック
302 DASHアクセスAPI
303 インバンドイベントおよび「moof」パーサ
304 時限メタデータトラックパーサ
305 ファイルフォーマットパーサ
306 イベントおよび時限メタデータバッファ
307 メディアバッファ
308 シンクロナイザ／ディスパッチャ
309 メディアデコーダ
310 マニフェストパーサ
311 DASHロジック
312 アプリケーション
400 処理
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 音声出力装置
510 タッチスクリーン
520 光学メディア
521 CD／DVDなどのメディア
522 サムドライブ
523 ドライブ
540 コア
541 CPU
542 GPU
543 FPGA
544 アクセラレータ
545 読み取り専用メモリ（ROM）
546 ランダムアクセスメモリ（RAM）
547 大容量記憶装置
548 システムバス
549 周辺バス
550 グラフィックスアダプタ
554 ネットワークインターフェース
555 通信ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】