特表2024-537153 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ テンセント・アメリカ・エルエルシーの特許一覧

特表2024-537153ＤＡＳＨイベント更新のハンドリングを支援するためのＤＡＳＨクライアント処理モデルの処理モデル

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5a
5b
5c
6
7

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

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

(11)【公表番号】

(43)【公表日】2024-10-10

(54)【発明の名称】ＤＡＳＨイベント更新のハンドリングを支援するためのＤＡＳＨクライアント処理モデルの処理モデル

(51)【国際特許分類】

H04N 21/435 20110101AFI20241003BHJP

【ＦＩ】

H04N21/435

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024520762

(86)(22)【出願日】2023-04-19

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

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

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

(87)【国際公開日】2023-10-26

(31)【優先権主張番号】63/332,596

(32)【優先日】2022-04-19

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

(31)【優先権主張番号】63/332,599

(32)【優先日】2022-04-19

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

(31)【優先権主張番号】18/301,596

(32)【優先日】2023-04-17

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100150197

【弁理士】

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

(72)【発明者】

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

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

5C164

【Ｆターム（参考）】

5C164FA06

5C164MB11S

5C164MB44S

5C164UB10P

5C164UB41S

5C164YA21

(57)【要約】

メディアストリームを処理するための方法、装置、およびコンピュータ可読記憶媒体。方法は、ＤＡＳＨメディアストリームに関連付けられたＤＡＳＨイベントを受信するステップと、ＤＡＳＨイベントが以前に受信したＤＡＳＨイベントへの更新であると判定するステップと、ＤＡＳＨイベントの発信モードに基づいて、ＤＡＳＨイベントを処理するステップと、を含んでもよく、ＤＡＳＨイベントは、コンテンツセット内の第１のメディアスライスと共に送信されるインバンドイベントであって、コンテンツセットが１つまたは複数のメディアスライスを含む、インバンドイベント、メディアプレゼンテーション記述（ＭＰＤ）イベント、または時限メタデータのサンプルのうちの少なくとも１つを含み、ＤＡＳＨイベントの発信モードは、受信時モードおよび開始時モードを含む。

【特許請求の範囲】

【請求項1】

メディアストリーミングシステム内のメディアストリーミングデバイスによってホストされたＨＴＴＰを介した動的適応ストリーミング（ＤＡＳＨ）クライアントによって実行されるＤＡＳＨメディアストリームを処理するための方法であって、前記方法は、
前記ＤＡＳＨメディアストリームに関連付けられたＤＡＳＨイベントを受信するステップと、
前記ＤＡＳＨイベントが以前に受信したＤＡＳＨイベントへの更新であると判定するステップと、
前記ＤＡＳＨイベントの発信モードに基づいて、前記ＤＡＳＨイベントを処理するステップと、を含み、
前記ＤＡＳＨイベントは、
コンテンツセット内の第１のメディアスライスと共に送信されるインバンドイベントであって、前記コンテンツセットが１つまたは複数のメディアスライスを含む、インバンドイベント、
メディアプレゼンテーション記述（ＭＰＤ）イベント、または
時限メタデータのサンプル
のうちの少なくとも１つを含み、
前記ＤＡＳＨイベントの前記発信モードは、受信時モードおよび開始時モードを含む、
方法。

【請求項2】

前記イベントが前記以前に受信したイベントへの前記更新であると判定するステップが、
前記イベントの状態フィールド、または前記イベントに関連付けられたフラグのうちの１つに基づいて、前記イベントが更新済バージョンであると判定するステップと、
前記以前に受信したイベントにおけるフィールドの組み合わせと一致する前記イベントにおける前記フィールドの組み合わせに応答して、前記イベントが前記以前に受信したイベントへの前記更新であると判定するステップであって、前記フィールドの組み合わせが、スキーム識別子フィールド、値フィールド、またはＩＤフィールドのうちの少なくとも１つを含む、ステップと、
を含む、請求項１に記載の方法。

【請求項3】

前記イベントが前記更新済バージョンであると判定するステップが、
前記イベントがＭＰＤイベントであることに応答して、前記イベントの状態フィールドに基づいて、前記イベントが前記更新済バージョンであると判定するステップ、または
前記イベントがインバンドイベントであることに応答して、前記イベントに関連付けられたフラグに基づいて、前記イベントが前記更新済バージョンであると判定するステップ
を含む、請求項２に記載の方法。

【請求項4】

前記イベントの前記発信モードが前記開始時モードであり、かつ
前記イベントの前記発信モードに基づいて、前記イベントを処理するステップが、
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値のペアに関連付けられたアクティブイベントリストにあることに応答して、前記アクティブイベントリストから前記以前に受信したイベントを削除するステップであって、前記アクティブイベントリストは発信されるべきイベントのリストを含む、ステップ
を含む、
請求項１または２に記載の方法。

【請求項5】

前記メディアストリームの現在のメディアプレゼンテーション時間が前記イベントの開始時間よりも小さく、前記方法が、
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた発信済イベントリストにないことに応答して、前記イベントを前記アクティブイベントリストに追加するステップであって、前記発信済イベントリストが発信されたイベントのリストを含む、ステップ
をさらに含む、請求項４に記載の方法。

【請求項6】

前記以前に受信したイベントが前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた発信済イベントリストにあることに応答して、前記イベントの処理を停止するステップ
をさらに含む、請求項４に記載の方法。

【請求項7】

前記イベントの前記開始時間に前記イベントを発信するステップと、
前記イベントを、前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた前記発信済イベントリストに追加するステップと、
をさらに含む、請求項５に記載の方法。

【請求項8】

前記イベントの前記開始時間に前記イベントを発信するステップの後、前記方法が、
前記アクティブイベントリストから前記イベントを削除するステップ
をさらに含む、請求項７に記載の方法。

【請求項9】

前記メディアストリームの現在のメディアプレゼンテーション時間が前記イベントの開始時間よりも大きく、前記方法が、
前記イベントの前記開始時間および前記イベントの持続時間に基づいて、前記イベントの終了時間を導出するステップと、
前記メディアストリームの現在のメディアプレゼンテーション時間が前記イベントの前記終了時間よりも小さく、前記以前に受信したイベントが前記イベントと同じスキーム識別子および値のペアに関連付けられた発信済イベントリストにないことに応答して、
前記イベントの前記開始時間に、前記イベントを、前記イベントが属するイベントタイプにサブスクライブされたアプリケーションに発信するステップと、
前記イベントを、前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた前記発信済イベントリストに追加するステップと、
をさらに含む、請求項４に記載の方法。

【請求項10】

前記イベントの前記開始時間に前記イベントを発信するステップの前に、前記方法が、
前記イベントを前記アクティブイベントリストに追加するステップ
をさらに含み、
前記イベントの前記開始時間に前記イベントを発信するステップの後に、前記方法が、
前記アクティブイベントリストから前記イベントを削除するステップ
をさらに含む、
請求項９に記載の方法。

【請求項11】

前記イベントの前記発信モードが前記受信時モードであり、かつ
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値のペアに関連付けられた発信済イベントリストにないことに応答して、
前記イベントを、前記イベントが属するイベントタイプにサブスクライブされたアプリケーションに発信するステップと、
前記イベントを、前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた前記発信済イベントリストに追加するステップと、を含む、
請求項１または２に記載の方法。

【請求項12】

ＤＡＳＨメディアストリームを処理するためのデバイスであって、前記デバイスは、コンピュータ命令を格納するためのメモリと、前記メモリと通信するプロセッサとを備え、前記プロセッサが前記コンピュータ命令を実行すると、前記プロセッサは、前記デバイスに、
前記ＤＡＳＨメディアストリームに関連付けられたＤＡＳＨイベントを受信させ、
前記ＤＡＳＨイベントが以前に受信したＤＡＳＨイベントへの更新であると判定させ、
前記ＤＡＳＨイベントの発信モードに基づいて、前記ＤＡＳＨイベントを処理させるように構成され、
前記ＤＡＳＨイベントは、
コンテンツセット内の第１のメディアスライスと共に送信されるインバンドイベントであって、前記コンテンツセットが１つまたは複数のメディアスライスを含む、インバンドイベント、
メディアプレゼンテーション記述（ＭＰＤ）イベント、または
時限メタデータのサンプル
のうちの少なくとも１つを含み、
前記ＤＡＳＨイベントの前記発信モードは、受信時モードおよび開始時モードを含む、
デバイス。

【請求項13】

前記プロセッサが、前記デバイスに、前記イベントが前記以前に受信したイベントへの前記更新であると判定させるように構成されている場合、前記プロセッサは、前記デバイスに、
前記イベントの状態フィールド、または前記イベントに関連付けられたフラグのうちの１つに基づいて、前記イベントが更新済バージョンであると判定させ、
前記以前に受信したイベントにおけるフィールドの組み合わせと一致する前記イベントにおける前記フィールドの組み合わせに応答して、前記イベントが前記以前に受信したイベントへの前記更新であると判定させ、前記フィールドの組み合わせが、スキーム識別子フィールド、値フィールド、またはＩＤフィールドのうちの少なくとも１つを含む、
ように構成される、請求項１２に記載のデバイス。

【請求項14】

前記プロセッサが、前記デバイスに、前記イベントが前記更新済バージョンであると判定させるように構成されている場合、前記プロセッサは、前記デバイスに、
前記イベントがＭＰＤイベントであることに応答して、前記イベントの状態フィールドに基づいて、前記イベントを前記更新済バージョンであると判定させ、または
前記イベントがインバンドイベントであることに応答して、前記イベントに関連付けられたフラグに基づいて、前記イベントが前記更新済バージョンであると判定させる
ように構成される、請求項１３に記載のデバイス。

【請求項15】

前記イベントの前記発信モードが前記開始時モードであり、かつ
前記プロセッサが、前記デバイスに、前記イベントの前記発信モードに基づいて、前記イベントを処理させるように構成されている場合、前記プロセッサは、前記デバイスに、
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値のペアに関連付けられたアクティブイベントリストにあることに応答して、前記アクティブイベントリストから前記以前に受信したイベントを削除させ、前記アクティブイベントリストは発信されるべきイベントのリストを含む、
ように構成される、
請求項１２または１３に記載のデバイス。

【請求項16】

前記メディアストリームの現在のメディアプレゼンテーション時間が前記イベントの開始時間よりも小さく、前記プロセッサが前記コンピュータ命令を実行すると、前記プロセッサは、前記デバイスにさらに、
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた発信済イベントリストにないことに応答して、前記イベントを前記アクティブイベントリストに追加させ、前記発信済イベントリストが発信されたイベントのリストを含む、
ように構成される、請求項１５に記載のデバイス。

【請求項17】

前記プロセッサが前記コンピュータ命令を実行すると、前記プロセッサは、前記デバイスにさらに、
前記以前に受信したイベントが前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた発信済イベントリストにあることに応答して、前記イベントの処理を停止させる
ように構成される、請求項１５に記載のデバイス。

【請求項18】

前記プロセッサが前記コンピュータ命令を実行すると、前記プロセッサは、前記デバイスにさらに、
前記イベントの前記開始時間に前記イベントを発信させ、
前記イベントを、前記イベントと同じスキーム識別子および値の前記ペアに関連付けられた前記発信済イベントリストに追加させる
ように構成される、請求項１６に記載のデバイス。

【請求項19】

コンピュータ可読命令を格納するための非一時的記憶媒体であって、前記コンピュータ可読命令は、ＤＡＳＨメディアストリームを処理するためのデバイス内のプロセッサによって実行されると、前記プロセッサに、
前記ＤＡＳＨメディアストリームに関連付けられたＤＡＳＨイベントを受信させ、
前記ＤＡＳＨイベントが以前に受信したＤＡＳＨイベントへの更新であると判定させ、
前記ＤＡＳＨイベントの発信モードに基づいて、前記ＤＡＳＨイベントを処理させるように構成され、
前記ＤＡＳＨイベントは、
コンテンツセット内の第１のメディアスライスと共に送信されるインバンドイベントであって、前記コンテンツセットが１つまたは複数のメディアスライスを含む、インバンドイベント、
メディアプレゼンテーション記述（ＭＰＤ）イベント、または
時限メタデータのサンプル
のうちの少なくとも１つを含み、
前記ＤＡＳＨイベントの前記発信モードは、受信時モードおよび開始時モードを含む、
非一時的記憶媒体。

【請求項20】

前記コンピュータ可読命令が、前記プロセッサに、前記イベントが前記以前に受信したイベントへの前記更新であると判定させる場合、前記コンピュータ可読命令は、前記プロセッサに、
前記イベントの状態フィールド、または前記イベントに関連付けられたフラグのうちの１つに基づいて、前記イベントが更新済バージョンであると判定させ、
前記以前に受信したイベントにおけるフィールドの組み合わせと一致する前記イベントにおける前記フィールドの組み合わせに応答して、前記イベントが前記以前に受信したイベントへの前記更新であると判定させ、前記フィールドの組み合わせが、スキーム識別子フィールド、値フィールド、またはＩＤフィールドのうちの少なくとも１つを含む、
請求項１９に記載の非一時的記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２３年４月１７日に出願された米国非仮出願第１８／３０１，５９６号に基づく優先権の利益を主張し、これは、２０２２年４月１９日に出願された米国仮出願第６３／３３２，５９９号および２０２２年４月１９日に出願された米国仮特許出願第６３／３３２，５９６号に基づく優先権の利益を主張する（これらの各々は、参照によりその全体が本明細書に組み込まれる）。

【0002】

本開示は、一般に、ハイパーテキスト転送プロトコルを介した動的適応ストリーミング（ＤＡＳＨ）を含むメディアストリーミング技術に関する。より具体的には、開示された技術は、ＤＡＳＨクライアント処理モデルの下でＤＡＳＨイベント更新をハンドリングするための方法および装置を含む。

【背景技術】

【0003】

本明細書に記載されている本背景技術の説明は開示の背景を概略的に示すためのものである。本背景技術の記載箇所で説明されている範囲において、現時点で氏名が掲載されている発明者の成果と、その他、本出願の出願時の先行技術としての地位を獲得し得ない説明の態様とは、本開示に対する先行技術として明示的にも黙示的にも自認されるものではない。

【0004】

ＭＰＥＧ（Ｍｏｖｉｎｇｐｉｃｔｕｒｅｅｘｐｅｒｔｇｒｏｕｐ）ハイパーテキスト転送プロトコルを介した動的適応ストリーミング（ＤＡＳＨ）は、ＩＰネットワークを介してマルチメディアコンテンツをストリーミングするための規格を提供する。ＤＡＳＨ規格において、メディアプレゼンテーション記述（ＭＰＤ）は、ＤＡＳＨクライアントがＤＡＳＨサーバからメディアセグメントをダウンロードすることによってメディアコンテンツを適応的にストリーミングするための情報を提供するために使用される。ＤＡＳＨ規格は、マルチレートのコンテンツのストリーミングを可能にする。ＤＡＳＨ規格の一態様は、ＭＰＤイベントおよびインバンドイベントの搬送と、これらのイベントをハンドリングするクライアント処理モデルとを含む。

【発明の概要】

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

【0005】

本開示の態様は、メディアストリーム処理のための、より具体的には、ＤＡＳＨクライアント処理モデルの下でＤＡＳＨイベント更新をハンドリングするための方法および装置を提供する。いくつかの例示的実装形態では、ＤＡＳＨメディアストリームなどのメディアストリームを処理するための方法が開示される。本方法は、ＤＡＳＨメディアストリームに関連付けられたＤＡＳＨイベントを受信するステップと、ＤＡＳＨイベントが以前に受信したＤＡＳＨイベントへの更新であると判定するステップと、ＤＡＳＨイベントの発信モードに基づいて、ＤＡＳＨイベントを処理するステップと、を含んでもよく、ＤＡＳＨイベントは、コンテンツセット内の第１のメディアスライスと共に送信されるインバンドイベントであって、コンテンツセットが１つまたは複数のメディアスライスを含む、インバンドイベント、メディアプレゼンテーション記述（ＭＰＤ）イベント、または時限メタデータのサンプルのうちの少なくとも１つを含み、ＤＡＳＨイベントの発信モードは、受信時モードおよび開始時モードを含む。

【0006】

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

【0007】

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

【0008】

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

【図面の簡単な説明】

【0009】

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

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

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

【図4】例示的なアクティブイベントテーブルおよび発信済イベントテーブルを示す。

【図5a】ＤＡＳＨイベント処理モデルにおける更新済イベントに対する例示的な共通処理を示す。

【図5b】ＤＡＳＨイベント処理モデルにおける更新済イベントに対する例示的な受信時処理を示す。

【図5c】ＤＡＳＨイベント処理モデルにおける更新済イベントに対する例示的な開始時処理を示す。

【図6】本開示の一実施形態による方法のフローチャートを示す。

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

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

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

【表1A】

【表1B】

【0052】

表２は、本開示の一実施形態による例示的なイベントセマンティクスを提供する。

【0053】

【表2A】

【表2B】

【0054】

インバンドイベントシグナリングおよびイベントメッセージボックス
いくつかの例示的実装形態では、イベントストリームは、セグメントの一部としてイベントメッセージを追加することによって表現と多重化されてもよい。イベントストリームは、選択された表現、１つまたはいくつかの選択された適応セットのみ、またはすべての表現に存在することができる。

【0055】

いくつかの例示的実装形態では、インバンドイベントストリームが表現内に存在してもよい。それがＤＡＳＨクライアントによって処理されることが期待される場合、それは適応セットまたは表現レベルのＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍ要素によって示され得る。

【0056】

ＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍは、表１に示すように、ＥｖｅｎｔＳｔｒｅａｍのセマンティクスに基づいて定義することができる。さらなる制限が、ＩｎｂａｎｄＥｖｅｎｔＳｔｒｅａｍ固有のセマンティクスに追加され得る。

【0057】

イベントメッセージボックス（「ｅｍｓｇ」）は、例えば、メディアプレゼンテーション時間に関連する一般的なイベントのシグナリングを提供するために使用され得る。表１および表２で定義されたイベントと同じセマンティクスが適用され得る。

【0058】

ＭｅｄｉａＳｅｇｍｅｎｔは、ＩＳＯＢＭＦＦコンテナに基づく場合、１つまたは複数のイベントメッセージ（「ｅｍｓｇ」）ボックスを含むことができる。存在する場合、「ｅｍｓｇ」ボックスは、以下のように配置され得る。

【0059】

セグメントの最初の「ｍｏｏｆ」ボックスの前に配置され得る、または

【0060】

任意の「ｍｄａｔ」（メディアデータ）ボックスと「ｍｏｏｆ」ボックスとの間に配置され得る。この場合、任意のセグメントの最初の「ｍｏｏｆ」ボックスの前に、同じｉｄ値を有する同等の「ｅｍｓｇ」が存在するものとする。

【0061】

いくつかの例示的実装形態では、「ｅｍｓｇ」は、以下のように定義されてもよい。
ボックスタイプ：ボックスタイプ：「ｅｍｓｇ」
コンテナ：セグメント
必須：いいえ
個数：０以上

【0062】

表３は、「ｅｍｓｇ」構文の例を示す。

【0063】

【表3】

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

１００システム
１１０コンテンツサーバ
１２０情報処理装置
２００ＤＡＳＨシステム
２１０コンテンツサーバ
２１２ＨＴＴＰサーバ
２１４ＭＰＤジェネレータ
２２０広告サーバ
２３０情報処理装置
２３２ＤＡＳＨクライアント
２３４アプリケーション
２３６表示デバイス
２５０ネットワーク
３０５マニフェストパーサ
３１０ＤＡＳＨ論理
３１５ＤＡＳＨアクセスＡＰＩ
３２０ＨＴＴＰスタック
３２５インバンドイベントおよび「ｍｏｏｆ」パーサ
３３０時限メタデータトラックパーサ
３３５イベントおよび時限メタデータバッファ
３４０イベント／メタデータのシンクロナイザ／ディスパッチャ
３４５ファイルフォーマットパーサ
３５０メディアバッファ
３５５メディアデコーダ
３９０アプリケーション
１８００コンピュータシステム
１８０１キーボード
１８０２マウス
１８０３トラックパッド
１８０５ジョイスティック
１８０６マイク
１８０７スキャナ
１８０８カメラ
１８０９スピーカ
１８１０画面
１８２０ＣＤ／ＤＶＤＲＯＭ／ＲＷ
１８２１光学媒体
１８２２サムドライブ
１８２３リムーバブルハードドライブまたはソリッドステートドライブ
１８４０コア
１８４１中央処理装置（ＣＰＵ）
１９４２グラフィックス処理装置（ＧＰＵ）
１８４３フィールドプログラマブルゲートエリア（ＦＰＧＡ）
１８４４アクセラレータ
１８４５ＲＯＭ
１８４６ＲＡＭ
１８４７大容量記憶装置
１８４９周辺バス
１８５０グラフィックアダプタ
１８５４インターフェース
１８５５ネットワークインターフェース

【図1】