特許 7392171 メディア・ストリーミング方法及び装置

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

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

(11)【特許番号】

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

(45)【発行日】2023-12-05

(54)【発明の名称】メディア・ストリーミング方法及び装置

(51)【国際特許分類】

   H04N 21/438 20110101AFI20231128BHJP

   H04N 21/462 20110101ALI20231128BHJP

【ＦＩ】

H04N21/438

H04N21/462

【請求項の数】 12

(21)【出願番号】P 2022557748

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

(65)【公表番号】

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

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

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

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

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

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

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

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

(31)【優先権主張番号】17/447,920

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

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

(73)【特許権者】

【識別番号】520353802

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

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】ソダガァ，イラジ

【審査官】醍醐 一貴

(56)【参考文献】

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

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

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

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

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

【請求項1】

ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）プレーヤによるメディア再生方法であって：
独立したタイムラインによる第1メディア・コンテンツと第2メディア・コンテンツとに基づいてメディア・ソース拡張（MSE）ソース・バッファを設定するステップ；
前記MSEソース・バッファに付加された前記第1メディア・コンテンツのセグメントに基づいて再生を行うステップ；及び
前記第1メディア・コンテンツの最終セグメントの後に、前記MSEソース・バッファに付加された前記第2メディア・コンテンツの第1セグメントに移行するステップ；
を含む方法。

【請求項2】

請求項1に記載の方法において：
前記第1メディア・コンテンツと前記第2メディア・コンテンツとに基づいて前記MSEソース・バッファにおけるアペンド・ウィンドウを設定するステップ；
を更に含む、方法。

【請求項3】

請求項2に記載の方法において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記方法は：
前記ライブ・コンテンツの最大継続時間と最大時間シフト・バッファ・デプスとの合計に基づいて、前記アペンド・ウィンドウの終点を決定するステップ；
を更に含む、方法。

【請求項4】

請求項3に記載の方法において：
前記プリロール・コンテンツの可能な最大継続時間と前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとのうちの大きい方に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を更に含む、方法。

【請求項5】

請求項4に記載の方法において：
前記プリロール・コンテンツが再生された後に、前記プリロール・コンテンツの時間範囲を取り除くステップ；及び
前記最大時間シフト・バッファ・デプスと前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとに基づいて、前記アペンド・ウィンドウの始点を更新するステップ；
を含む、方法。

【請求項6】

請求項4に記載の方法において：
少なくとも、前記プリロール・コンテンツの可能な最大継続時間と、前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとの合計に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を含む方法。

【請求項7】

請求項6に記載の方法において：
前記プリロール・コンテンツ以前の前記ライブ・コンテンツの部分について前記MSEソース・バッファにおける時間範囲を設定するステップ；
を含む方法。

【請求項8】

請求項1に記載の方法において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記方法は：
最大時間シフト・バッファ・デプスと、前記プリロール・コンテンツの可能な最大継続時間と、前記プリロール・コンテンツのプレゼンテーション時間オフセットとに基づいて、前記プリロール・コンテンツのセグメントに対する第1タイムスタンプ・オフセットを決定するステップ；
を含む方法。

【請求項9】

請求項8に記載の方法において：
前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定するステップ；
を含む方法。

【請求項10】

請求項9に記載の方法において：
前記ライブ・コンテンツと前記プリロール・コンテンツに対する同じ初期化セグメントに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間の下限とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
シーケンス・モードに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；及び
前記ライブ・コンテンツに対する再初期化の条件に応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
のうちの少なくとも1つを更に含む方法。

【請求項11】

ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）プレーヤによるメディア再生装置であって、当該装置に備わる処理回路は：
請求項1ないし10のうち何れか1項に記載の方法を行うように構成されている、装置。

【請求項12】

請求項1ないし10のうち何れか1項に記載の方法をコンピュータに実行させるコンピュータ・プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

[0001] 参照による援用
本願は、2021年9月16日付で出願された米国特許出願第17/447,920号「メディア・ストリーミングのための方法及び装置」に対する優先権を主張しており、同出願は2021年1月6日付で出願された米国仮特許出願第63/134,525号「w3cメディア拡張を用いるhttpにおける動的適応ストリーミング・プレーヤ／ライブ・コモン・メディア・アプリケーション・フォーマットに対するプリロール」に対する優先権を主張している。先の出願の開示全体は、参照により全体的に本件に援用される。

【0002】

[0002] 技術分野
本開示は、ストリーミング・メディアを再生するための方法及び装置に一般的に関連する実施形態を述べている。

【背景技術】

【0003】

[0003] ここに記載される背景の説明は、本開示の背景を一般的に提示するためのものである。目下の発明者の仕事は、その仕事がこの背景のセクションだけでなく、出願時における従来技術としての適格性を有しない可能性のある説明の態様にも及ぶ範囲内において、本開示に対する従来技術として明示的にも黙示的にも認められていない。

【0004】

[0004] ハイパーテキスト・トランスファ・プロトコルによる動画エキスパート・グループ（MPEG）の動的適応ストリーミング（DASH）は、インターネット・プロトコル（IP）ネットワークを介するマルチメディア・コンテンツをストリーミングするための規格を提供する。メディア・プレーヤは、プリロール・コンテンツ（preroll content）（例えば、広告）及びライブ・コンテンツ（例えば、フットボール・ゲーム）等のような、様々なソースからのメディア・コンテンツを再生することができる。

【発明の概要】

【0005】

[0005] 本開示の態様はメディア再生方法及び装置を提供する。幾つかの例において、ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）プレーヤによるメディア再生装置は処理回路を含む。処理回路は、独立したタイムラインによる第1メディア・コンテンツと第2メディア・コンテンツとに基づいてメディア・ソース拡張（MSE）ソース・バッファを設定する。次いで、処理装置は、MSEソース・バッファに付加された第1メディア・コンテンツのセグメントに基づいて再生を行い、第1メディア・コンテンツの最終セグメントの後に、MSEソース・バッファに付加された第2メディア・コンテンツの第1セグメントに移行する。

【0006】

[0006] 幾つかの実施形態において、処理回路は、第1メディア・コンテンツと第2メディア・コンテンツとに基づいてMSEソース・バッファにおけるアペンド・ウィンドウ（append window）を設定する。幾つかの例において、第1メディア・コンテンツはプリロール・コンテンツであり、第2メディア・コンテンツはライブ・コンテンツであり、処理回路は、ライブ・コンテンツの最大継続時間と最大時間シフト・バッファ・デプス（maximum time shift buffer depth）との合計に基づいて、アペンド・ウィンドウの終点を決定する。

【0007】

[0007] 一例において、処理回路は、プリロール・コンテンツの可能な最大継続時間とライブ・コンテンツの所望の時間シフト・バッファ・デプスとのうちの大きい方に基づいて、最大時間シフト・バッファ・デプスを決定する。更に、処理回路は、プリロール・コンテンツが再生された後に、プリロール・コンテンツの時間範囲を除外し、最大時間シフト・バッファ・デプスとライブ・コンテンツの所望の時間シフト・バッファ・デプスとに基づいて、アペンド・ウィンドウの始点を更新する。

【0008】

[0008] 別の例において、処理回路は、少なくとも、プリロール・コンテンツの可能な最大継続時間と、ライブ・コンテンツの所望の時間シフト・バッファ・デプスとの合計に基づいて、最大時間シフト・バッファ・デプスを決定する。更に、処理回路は、プリロール・コンテンツ以前のライブ・コンテンツの部分についてMSEソース・バッファにおける時間範囲を設定することが可能である。

【0009】

[0009] 幾つかの例において、第1メディア・コンテンツはプリロール・コンテンツであり、第2メディア・コンテンツはライブ・コンテンツであり、処理回路は、最大時間シフト・バッファ・デプスと、プリロール・コンテンツの可能な最大継続時間と、プリロール・コンテンツのプレゼンテーション時間オフセットとに基づいて、プリロール・コンテンツのセグメントに対する第1タイムスタンプ・オフセットを決定する。更に、処理回路は、最大時間シフト・バッファ・デプスと、ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定する。

【0010】

[0010] 一例において、処理回路は、ライブ・コンテンツとプリロール・コンテンツに対する同じ初期化セグメントに応じて、最大時間シフト・バッファ・デプスと、ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間の下限（lower-bound）とに基づいて、ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定する。別の例において、処理回路は、シーケンス・モードに応じて、最大時間シフト・バッファ・デプスと、ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定する。別の例において、処理回路は、ライブ・コンテンツに対する再初期化の条件に応じて、最大時間シフト・バッファ・デプスと、ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定する。

【0011】

[0011] 本開示の態様はまた、命令を記憶する非一時的なコンピュータ読み取り可能な媒体も提供し、命令は、コンピュータにより実行されると、メディアを再生する方法をコンピュータに実行させる。

【図面の簡単な説明】

【0012】

[0012] 開示される対象事項の更なる特徴、性質、及び種々の利点は、以下の詳細な説明及び添付の図面から更に明らかになるであろう。

【図1】[0013] 図1は、本開示の幾つかの実施形態によるメディア・システムを示す。

【図2】[0014] 図2は、本開示の幾つかの実施形態によるメディア・クライアント・デバイスのブロック図を示す。

【図3】[0015] 図3は、幾つかの例におけるソース・バッファのタイミング・モデルを示す。

【図4】[0016] 図4は、本開示の幾つかの実施形態による非線形動作のためのメディア・クライアント・デバイスにおけるソース・バッファを使用するためのプロセスの概略を示すフロー・チャートを示す。

【図5】[0017] 図5は、実施形態によるコンピュータ・システムの概略図を示す。

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

【0013】

[0018] 本開示の態様は、プリロール・コンテンツ、ライブ・コンテンツ等のような複数のメディア・コンテンツを再生するためにメディア・プレーヤにおいて単一のソース・バッファを使用し、あるメディア・コンテンツから別のメディア・コンテンツへの切り替えに対処する技術を提供する。

【0014】

[0019] 本開示の幾つかの態様によれば、メディア・プレーヤは、共通メディア・アプリケーション・フォーマット規格、ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）等のような、特定のプロトコル及び規格に従って構成されている。

【0015】

[0020] ハイパーテキスト・トランスファ・プロトコルによる動的適応ストリーミング（DASH）は、ウェブ・サーバー、コンテンツ配信ネットワーク（CDN）、各種プロキシ及びキャッシュなどのハイパーテキスト・トランスファ・プロトコル（HTTP）インフラストラクチャを使用してメディア・コンテンツのストリーミングを可能にする適応ビットレート・ストリーミング技術である。DASHは、DASHサーバーからDASHクライアントへのオン・デマンド及びライブ・ストリーミングの両方をサポートし、DASHクライアントがストリーミング・セッションを制御できるようにし、その結果、DASHサーバーは、大規模な配備において、ストリーム適応管理の追加的な負荷に対処することを要しない。また、DASHは、DASHクライアントが様々なDASHサーバーからストリーミングを選択できるようにし、従って、DASHクライアントの利益に関し、ネットワークの更なるロード・バランシングを達成することが可能である。DASHは、例えば、ネットワーク条件に適応するためにビットレートを変化させることによって、異なるメディア・トラック間の動的なスイッチングを提供する。

【0016】

[0021] DASHでは、メディア・プレゼンテーション記述（MPD）ファイルは、DASHサーバーからメディア・セグメントをダウンロードすることにより、メディア・コンテンツを適応的にストリーミングするための情報をDASHクライアントに提供する。MPDファイルは、分割され、部分的に配信されて、セッションのスタート・アップ遅延を減らすことが可能である。MPDファイルはまた、ストリーミング・セッション中に更新されることも可能である。幾つかの例では、MPDファイルは、コンテンツ・アクセシビリティ機能、レーティング、及びカメラ視野の表現をサポートする。DASHはまた、マルチ・ビュー及びスケーラブルなコーディングされたコンテンツの配信もサポートする。

【0017】

[0022] MPDファイルは、1つ以上のピリオド（period）のシーケンスを含むことが可能である。1つ以上のピリオドのそれぞれは、MPDファイルにおけるピリオド要素によって定義することが可能である。MPDファイルは、MPDに対するavailableStartTime属性と各ピリオドに対するスタート（start）属性とを含むことが可能である。動的なタイプ（例えば、ライブ・サービスに使用されるもの）のメディア・プレゼンテーションの場合、ピリオドのスタート属性とMPD属性availableStartTimeの合計、及びメディア・セグメントの継続時間は、ピリオドの利用可能時間を協定世界時（UTC）の形式で、特に対応するピリオドにおける各リプリゼンテーション（representation）の第1メディア・セグメントを示すことが可能である。静的なタイプ（例えば、オン・デマンド・サービスに使用されるもの）のメディア・プレゼンテーションの場合、第1ピリオドのスタート属性は0であるとすることが可能である。その他の何らかのピリオドに関し、スタート属性は、第1ピリオドのスタート時間に対する、対応するピリオドのスタート時間の間の時間オフセットを指定することが可能である。各ピリオドは、次のピリオドのスタートまで、又は最後のピリオドの場合はメディア・プレゼンテーションの終了まで延長することが可能である。ピリオドのスタート時間は正確であり、過去の全てのピリオドのメディアを再生した結果生じる実際のタイミングを反映することが可能である。

【0018】

[0023] 各ピリオドは、1つ以上のアダプテーション・セット（adaptations sets）を含むことが可能であり、アダプテーション・セットの各々は、同一のメディア・コンテンツに対する1つ以上のリプリゼンテーションを含むことが可能である。リプリゼンテーションは、オーディオ又はビデオ・データの多数の代替的な符号化されたバージョンのうちの1つであるとすることが可能である。リプリゼンテーションは、符号化するタイプによって、例えばビットレート、解像度、及び／又はビデオ・データやビットレートのコーデック、及び／又はオーディオ・データのコーデックによって、相違する可能性がある。リプリゼンテーションという用語は、マルチメディア・コンテンツの特定のピリオドに対応する符号化されたオーディオ又はビデオ・データのセクションであって特定の方法で符号化されたものを指すために使用することが可能である。

【0019】

[0024] 特定のピリオドのアダプテーション・セットは、MPDファイルのグループ（group）属性で示されたグループに割り当てることが可能である。同じグループ内のアダプテーション・セットは、一般に、互いに代替的であると考えられる。例えば、特定のピリオドのビデオ・データの各アダプテーション・セットは同じグループに割り当てることが可能であり、その結果、対応するピリオドのマルチメディア・コンテンツのビデオ・データを表示するために、任意のアダプテーション・セットが復号化のために選択されることが可能である。1つのピリオド内のメディア・コンテンツは、もし存在するならば、グループ0からの1つのアダプテーション・セット、又は幾つかの例では、非ゼロの各グループからの多くとも1つのアダプテーション・セットの組み合わせのうちの何れかによって表現することが可能である。ピリオドの各リプリゼンテーションのタイミング・データは、ピリオドのスタート時間に対して表現されることが可能である。

【0020】

[0025] リプリゼンテーションは1つ以上のセグメントを含むことが可能である。各リプリゼンテーションは初期化セグメントを含むことが可能であり、あるいはリプリゼンテーションの各セグメントは自己初期化（self-initializing）することが可能である。存在する場合、初期化セグメントは、リプリゼンテーションにアクセスするための初期化情報を含むことが可能である。場合によっては、初期化セグメントはメディア・データを含まない。セグメントは、ユニフォーム・リソース・ロケータ（URL）、ユニフォーム・リソース・ネーム（URN）、又はユニフォーム・リソース識別子（URI）のような識別子によって一意に参照することが可能である。MPDファイルは各セグメントの識別子を提供することが可能である。幾つかの例では、MPDファイルは、URL、URN、又はURIによってアクセス可能なファイル内のセグメントのデータに対応することが可能なレンジ（range）属性の形式で、バイト範囲を提供することも可能である。

【0021】

[0026] 各リプリゼンテーションは、1つ以上のメディア・コンポーネントを含むことも可能であり、各メディア・コンポーネントは、オーディオ、ビデオ、又は（例えば、クローズド・キャプショニングなどの）タイムド・テキストのような、1つの個別的なメディア・タイプの符号化されたバージョンに対応することが可能である。メディア・コンポーネントは、1つのリプリゼンテーション内で連続したメディア・セグメントの境界を横切って、時間的に連続であるとすることが可能である。

【0022】

[0027] 幾つかの実施形態では、DASHクライアントは、DASHサーバーにアクセスし、DASHサーバーからMPDファイルをダウンロードすることが可能である。即ち、DASHクライアントは、ライブ・セッションを開始する際に使用するMPDファイルを取り出すことが可能である。MPDファイルに基づいて、そして選択された各リプリゼンテーションに対して、DASHクライアントは幾つかの決定を行うことが可能であり、決定は、サーバー上で利用可能な最新セグメントは何であるかを決定すること、次のセグメント及び可能性のある将来のセグメントのセグメント利用可能なスタート時間を決定すること、セグメントの再生をスタートさせる時点及びセグメント中のどのタイムラインからかを決定すること、及び新しいMPDファイルをいつ取得／獲得するかを決定することを含む。いったんサービスが再生されると、クライアントは、ライブ・サービスとそれ自身の再生との間のドリフトを追跡することが可能であり、これは検出されて補償されることを要する。

【0023】

[0028] 幾つかの例（例えば、 国際標準化機構（ISO）／国際電気標準会議（IEC）23009-1のDASH規格）においては、メディア・セグメントとともにイベントを搬送するためのイベント・メッセージ・ボックスが使用されている。一例（例えば、ISO/IEC 23000-19共通メディア・アプリケーション・フォーマット（CMAF））においては、各CMAFチャンクの始まりに、イベント・メッセージ・ボックスが含まれるように許容されている。

【0024】

[0029] イベント情報は、メディア・プレゼンテーションにおける時点又は期間に関連するメディア・タイムド・イベント（例えば、連続的なオーディオ及び／又はビデオ・プレゼンテーション）に対応することが可能である。例えば、イベント情報は、動的コンテンツの再配置、広告の挿入、オーディオ及び／又はビデオと並行する補足コンテンツの提示、ウェブページに変更を加えること、及びメディア・プレゼンテーションのメディア・タイムライン（例えば、オーディオ及び／又はビデオ・メディア・ストリーム）における特定の地点でトリガされたアプリケーション・コードを実行すること、のために使用することが可能である。

【0025】

[0030] メディア・タイムド・イベントは、メディア・ストリームと同期するように意図される情報を搬送するために使用することが可能である。例えば、イベント情報は、番組や章のタイトル、又は地理的な位置情報のようなメディア・プレゼンテーションの内容を記述するメタデータ（又は、タイムド・メタデータ）を含むことが可能である。更に、イベント情報は、広告挿入キューのような、メディア・プレゼンテーション再生中の特定の時間に関連付けられたメディア・プレーヤに関する制御メッセージを含むことが可能である。

【0026】

[0031] 本開示の幾つかの態様によれば、DASH規格は、単一の線形タイムライン（single linear timeline）を使用し、単一の線形タイムラインは、単一のタイムライン内で互いに連続するコンテンツを伴う複数のピリオド（幾つかの例では、コンテンツを伴うピリオドは、セグメントと言及される）を含み、互いに連続するメディア・コンテンツの再生は、線形なオペレーション又は線形な再生と言及される可能性がある。幾つかの例において、再生するメディアは、互いに独立した複数の部分を含む可能性があり、複数の部分は、各自のタイムラインを有することが可能であり、互いに独立した複数の部分の再生は、非線形なオペレーション（nonlinear operation）又は非線形な再生と言及される可能性がある。

【0027】

[0032] 幾つかの例において、メディア再生デバイス（幾つかの例では、メディア・プレーヤ、メディア・クライアント・デバイスと言及される）は、W3Cメディア・ソース拡張（Media Source Extensions, MSE）を使用して実装することが可能であり、メディア再生のためのメディア・セグメント処理経路を使用することが可能である。動作中に、アプリケーションは、データ・セグメントをメディア・セグメント処理経路へ処理のために送信することが可能である。例えば、データ・セグメントは、メディア・セグメント処理経路によって分析及び復号化され、次いで、メディア再生デバイスによって再生されることが可能である。幾つかの例において、メディア・セグメント処理経路は、パイプライン・アーキテクチャを使用して実装され、MSEパイプラインと言及される。幾つかの例において、メディア・セグメント処理経路は、W3C MSEに従ってデータ・セグメントをバッファリングするように構成された単一のソース・バッファを含み、単一のソース・バッファは、幾つかの例では単一のMSEソース・バッファと言及することが可能である。

【0028】

[0033] 本開示の幾つかの態様は、非線形オペレーションに関して単一のMSEソース・バッファのような単一のソース・バッファを使用する技術を提供する。以下の説明は、2つの独立したメディア・ソースの例として、プリロール要素（プリロール・コンテンツとも言及される）とライブ番組（ライブ・コンテンツとも言及される）とを2つの独立したメディア・ソースの例として使用して、非線形オペレーションに関して単一のMSEソース・バッファを使用する技術を説明する。この技術は、他の数のメディア・ソース及び他のタイプのメディア・ソースに使用されることが可能であることに留意されたい。

【0029】

[0034] 図1は、本開示の幾つかの実施形態による媒体システム（100）を示す。幾つかの例では、メディア・システム（100）は、DASH規格に従って実装され、DASHシステムと言及される。メディア・システム（100）は、例えばネットワーク（不図示）を介する通信において適切に構成されたメディア・サーバー（101）（例えば、コンテンツ・サーバー）とメディア・クライアント（102）を含む。メディア・システム（100）では、MPDファイルが、メディア・サーバー（101）からメディア・クライアント（102）へ送信される。メディア・クライアント（102）は、MPDファイルに基づいてメディア・サーバー（101）からメディア・セグメントを受信することができる。メディア・クライアント（102）は、MPDファイルを更新するためにリクエストをメディア・サーバー（101）へ送信することができる。メディア・サーバー（101）は、プライマリ・コンテンツ（例えば、メイン番組）と1つ以上のタイムド・メタデータ・トラック（timed metadata track）とを含むコンテンツ・ストリームを提供することができる。

【0030】

[0035] メディア・クライアント（102）は、メディア処理能力を有するように構成された適切な任意のデバイスであるとすることが可能である。例えば、メディア・クライアント（102）は、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、スマートフォン、ヘッド・マウント・ディスプレイ、メディア・プレーヤなどであるとすることが可能である。メディア・クライアント（102）は、幾つかの例では、DASHクライアント又はDASHプレーヤとも言及される。

【0031】

[0036] 図2は、本開示の幾つかの実施形態によるメディア・クライアント・デバイス（200）のブロック図を示す。幾つかの例において、メディア・クライアント・デバイス（200）は、図1のメディア・クライアント（102）として使用される。メディア・クライアント・デバイス（200）は、メディア・セグメント処理のためのメディア・セグメント処理経路（250）を含む。幾つかの例では、メディア・セグメント処理経路（250）は、パイプライン・アーキテクチャで構成される構成要素を含む。

【0032】

[0037] メディア・クライアント・デバイス（200）は、メディア・ウェア・アプリケーションであるアプリケーション（212）を実行することができる。アプリケーション（212）は、（i）MPDイベント、（ii）インバンド・イベント、及び（iii）タイムド・メタデータ・イベントを含む様々なタイプのイベントをメディア・クライアント・デバイス（200）に処理させることができる。

【0033】

[0038] 図2の例において、メディア・クライアント・デバイス（200）は、マニフェスト（例えば、MPD）を分析するマニフェスト・パーサー（210）を含む。マニフェストは例えばDASHサーバー（101）によって提供することが可能である。マニフェスト・パーサー（210）は、MPDイベント、インバンド・イベント、及びタイムド・メタデータ・イベントに関する、タイムド・メタデータ・トラックに埋め込まれたイベント情報を抽出することが可能である。抽出されたイベント情報は、DASHロジック（211）（例えば、DASHプレーヤ制御、選択、及び発見的ロジック）に提供されることが可能である。DASHロジック（211）は、イベント情報に基づいて、マニフェストでシグナリングされたイベント・スキームを、アプリケーション（212）に通知することが可能である。

【0034】

[0039] イベント情報は、異なるイベント・ストリームを区別するためのイベント・スキーム情報を含むことが可能である。アプリケーション（212）は、イベント・スキーム情報を使用して、関心のあるイベント・スキームに加入することが可能である。アプリケーション（212）は、更に、1つ以上のサブスクリプション・アプリケーション・プログラミング・インターフェース（API）を介して、加入したスキームの各々に対して所望のディスパッチ・モードを指定することが可能である。例えば、アプリケーション（212）は、サブスクリプション・リクエストをメディア・サーバー（101）へ送信することが可能であり、そのリクエストは、関心のある1つ以上のイベント・スキーム及び任意の所望の対応するディスパッチ・モードを識別することが可能である。

【0035】

[0040] 幾つかの例において、アプリケーション（212）は、1つ以上のタイムド・メタデータ・トラックの一部として配信される1つ以上のイベント・スキームに加入することが可能であり、インバンド・イベント＆‘moof’パーサー（203）は、1つ以上のタイムド・メタデータ・トラックを、タイムド・メタデータ・トラック・パーサー（204）にストリーミングすることが可能である。例えば、インバンド・イベント＆‘moof’パーサー（203）は、DASHロジック（211）からの制御情報に基づいて、ムービー・フラグメント・ボックス（“moof”）を分析し、その後にタイムド・メタデータ・トラックを分析する。

【0036】

[0041] タイムド・メタデータ・トラック・パーサー（204）は、タイムド・メタデータ・トラックに埋め込まれたイベント・メッセージを抽出することが可能である。抽出されたイベント・メッセージは、イベント＆タイムド・メタデータ・バッファ（206）に格納されることが可能である。シンクロナイザ／ディスパッチャ・モジュール（208）（例えば、イベント及びタイムド・メタデータ・シンクロナイザ及びディスパッチャ）は、加入済みイベントを、アプリケーション（212）に対してディスパッチ（又は送信）することが可能である。

【0037】

[0042] 幾つかの例において、MPDに記述されるMPDイベントは、マニフェスト・パーサー（210）によって分析され、イベント＆タイムド・メタデータ・バッファ（206）に格納されることが可能である。例えば、マニフェスト・パーサー（210）は、MPDの各イベント・ストリーム・エレメントを分析し、各イベント・ストリーム・エレメントに記述された各イベントを分析する。MPDでシグナリングされる各イベントに関し、プレゼンテーション時間及びイベント継続時間のようなイベント情報は、イベント＆タイムド・メタデータ・バッファ（206）に、イベントと関連付けて格納することが可能である。

【0038】

[0043] インバンド・イベント＆‘moof’パーサー（203）は、インバンド・イベント・メッセージを抽出するためにメディア・セグメントを分析することが可能である。このように識別されたインバンド・イベント並びに関連するプレゼンテーション時間及び継続時間は、イベント＆タイムド・メタデータ・バッファ（206）に格納されることが可能である。

【0039】

[0044] 従って、イベント＆タイムド・メタデータ・バッファ（206）は、MPDイベント、インバンド・イベント、及び／又はタイムド・メタデータ・イベントをそこに格納することが可能である。イベント＆タイムド・メタデータ・バッファ（206）は、例えば、先入れ先出し（FIFO）バッファであるとすることが可能である。イベント＆タイムド・メタデータ・バッファ（206）は、メディア・バッファ（207）と通信可能に管理されることが可能である。例えば、メディア・セグメントがメディア・バッファ（207）に存在する限り、そのメディア・セグメントに対応する任意のイベント又はタイムド・メタデータを、イベント＆タイムド・メタデータ・バッファ（206）に格納することが可能である。

【0040】

[0045] DASHアクセスAPI（202）は、HTTPプロトコル・スタック（201）を介して、メディア・コンテンツ及び様々なメタデータを含むコンテンツ・ストリーム（又はデータフロー）の取得と受信を管理することが可能である。DASHアクセスAPI（202）は、受信したコンテンツ・ストリームを、異なるデータフローに分離することが可能である。インバンド・イベント＆‘moof’パーサー（203）に提供されるデータフローは、メディア・セグメント、1つ以上のタイムド・メタデータ・トラック、及びメディア・セグメントに含まれるインバンド・イベント・シグナリングを含むことが可能である。実施形態では、マニフェスト・パーサー（210）に提供されるデータフローは、MPDを含むことが可能である。

【0041】

[0046] DASHアクセスAPI（202）はマニフェストをマニフェスト・パーサー（210）へ転送することが可能である。イベントを記述する以外に、マニフェストはメディア・セグメントに関する情報を、DASHロジック（211）に提供することが可能であり、DASHロジック（211）は、アプリケーション（212）及びインバンド・イベント＆‘moof’パーサー（203）と通信することが可能である。アプリケーション（212）は、DASHクライアントによって処理されるメディア・コンテンツに関連付けることが可能である。アプリケーション（212）、DASHロジック（211）、マニフェスト・パーサー（210）、及びDASHアクセスAPI（202）の間でやり取りされる制御／同期信号は、マニフェストで提供されるメディア・セグメントに関する情報に基づいて、HTTPスタック（201）からのメディア・セグメントの取得を制御することが可能である。

【0042】

[0047] 幾つかの例では、インバンド・イベント＆‘moof’パーサー（203）は、メディア・データフローをメディア・セグメントに分析することが可能であり、メディア・セグメントは、メディア・コンテンツと、タイムド・メタデータ・トラック内のタイムド・メタデータと、メディア・セグメント内の何らかのシグナリングされるインバンド・イベントとを含む。幾つかの例において、インバンド・イベント＆‘moof’パーサー（203）は、プリロール・コンテンツやライブ・コンテンツ等のようなメディア・コンテンツを複数のソースから受信して分析し、メディア・セグメントを抽出することができる。複数のソースの媒体セグメントは、更なる処理のために媒体セグメント処理経路（250）に供給される。

【0043】

[0048] 図2の例では、メディア・セグメント処理経路（250）は、メディア・セグメント処理のためのパイプライン・アーキテクチャで結合された複数の構成要素を含む。具体的には、幾つかの例において、メディア・セグメント処理経路250は、ファイル・フォーマット・パーサー（205）と、メディア・バッファ（207）と、メディア・デコーダ（209）とを含み、これらはメディア・セグメントを処理するための3つの処理ステージであるとすることが可能である。ファイル・フォーマット・パーサー（205）と、メディア・バッファ（207）と、メディア・デコーダ（209）とは、異なるメディア・セグメントに関して同時に動作することが可能である。

【0044】

[0049] ファイル・フォーマット・パーサー（205）は、メディア・セグメントを受信し、メディア・セグメントを分析することができる。メディア・バッファ（207）は、バッファ・スペースの適切な部分の中に、メディア・セグメントを付加（append）することが可能である。メディア・デコーダ（209）は、メディア・セグメントを復号化し、復号化されたメディア・コンテンツを再生のために送り出すことが可能である。

【0045】

[0050] イベント＆タイムド・メタデータ・バッファ（206）に格納されているイベントは、シンクロナイザ／ディスパッチャ（208）が、イベント／メタデータAPIを介して、アプリケーション（212）に関連する利用可能なイベント（又は関心のあるイベント）をアプリケーション（212）に伝えることを許容することができる。アプリケーション（212）は、利用可能なイベント（例えば、MPDイベント、インバンド・イベント、又はタイムド・メタデータ・イベント）を処理し、シンクロナイザ／ディスパッチャ（208）に通知することによって、特定のイベント又はタイムド・メタデータに加入するように構成されることが可能である。アプリケーション（212）には関係しないがDASHクライアント自体には関係する、イベント＆タイムド・メタデータ・バッファ（206）に格納されたイベントは、シンクロナイザ／ディスパッチャ（208）によってDASHロジック（211）へ更なる処理のために転送されることが可能である。

【0046】

[0051] 特定のイベントに加入するアプリケーション（212）に応答して、シンクロナイザ／ディスパッチャ（208）は、アプリケーション（212）が加入しているイベント・スキームに対応するイベント・インスタンス（又はタイムド・メタデータ・サンプル）を、アプリケーション（212）に伝えることが可能である。イベント・インスタンスは、加入リクエストによって指定されるディスパッチ・モード（例えば、特定のイベント・スキームに対するもの）又はデフォルトのディスパッチ・モードに従って、伝達されることが可能である。例えば、オン－レシーブ（on-receive）ディスパッチ・モードでは、イベント・インスタンスは、イベント＆タイムド・メタデータ・バッファ（206）での受信の際に、アプリケーション（212）へ送信されることが可能である。一方、オン－スタート・ディスパッチ・モードでは、イベント・インスタンスは、例えばメディア・デコーダ（209）からのタイミング信号に同期して、それらの関連するプレゼンテーション時間でアプリケーション（212）に送信されることが可能である。

【0047】

[0052] 図2の例では、太いデータフロー・ラインはメディア・データフローを示し、細いデータフロー・ラインはイベント及びタイムド・メタデータ・データフローを示し、破線のデータフロー・ラインは制御及び同期を示すことに留意すべきである。更に、同じ処理モデルがCMAFイベントに使用されることが可能である。

【0048】

[0053] 本開示の幾つかの態様は、メディア・クライアント・デバイス（200）のようなメディア・プレーヤのためにタイミング・モデルを提供し、MSEソース・バッファ内のメディア・セグメントを処理する。幾つかの例において、単一のMSEソース・バッファが、プリロール・コンテンツ及びライブ・コンテンツのような複数のメディア・コンテンツのメディア・セグメントをバッファリングするために使用される。更に、バッファリングされたメディア・セグメントを有する単一のMSEソース・バッファが、プリロール・コンテンツとライブ・コンテンツの再生に使用される。

【0049】

[0054] 本開示の一態様によれば、MSEソース・バッファは、時間シフト機能を提供する時間シフト・バッファを含むように構成される。幾つかの例では、時間シフト・バッファは、「ウォール・クロック（wall clock）」に従って現時点で提示されることが可能なメディア・セグメントのセットを定義するMPDタイムラインにおける時間スパンに対応するように構成される。ウォール・クロックは幾つかの例ではメディア・クライアント決定のタイミング基準として使用される。一例では、ウォール・クロックはメディア・クライアント及びメディア・サーバーにより共有される同期したクロックである。

【0050】

[0055] 本開示の一態様によれば、MPDは、1つ以上の連続する重複しないピリオドの順序付けられたリストを定義することができる。ピリオドは、MPDタイムライン上の時間スパンと、この時間スパンの間に提示されるべきデータの定義の両方である。ピリオド・タイミングは、MPDタイムラインのゼロ点に対して相対的に表現することが可能であり、以前のピリオドに対するものとして間接的に表現されることが可能である。例えば、ピリオドの開始は、MPDタイムラインのゼロ点からのオフセットとして明示的に指定されることが可能であるし、あるいは以前のピリオドの終了によって暗黙的に表現されることが可能である。ピリオドの継続時間は、以前のピリオドの終了と次のピリオドの開始に基づいて、明示的に指定されることも暗黙的に指定されることも可能である。

【0051】

[0056] 幾つかの例では、MPDタイムラインのピリオドは自己完結的（self-contained）であり、従って、メディア・クライアント・デバイスは、別のピリオドの内容を知ることなく、ピリオドのうちのメディア・コンテンツを提示することができる。しかしながら、ピリオドの移行を達成するために、異なるピリオドのコンテンツの知識がメディア・クライアント・デバイスによって使用されてもよい。

【0052】

[0057] 幾つかの例では、メディア・クライアント・デバイスは、静的プレゼンテーション及び動的プレゼンテーションとそれぞれ言及される2つのタイプのプレゼンテーションを使用して提示されることが可能である。静的プレゼンテーションでは、どのセグメントもどの時点で提示されてもよい。メディア・クライアント・デバイスは、どのセグメントが何時提示されるかを支配することが可能であり、プレゼンテーション全体が任意の時点において、例えばプリロール・コンテンツ等の場合において利用可能である。動的なプレゼンテーションでは、MPDタイムラインはウォール・クロック時間にマッピングされ、MPDタイムラインにおける各メディア・セグメントは、特定の時点で提示されるように意図されている（一部のメディア・クライアント・デバイスは許容される時間シフトを選択する）。

【0053】

[0058] 幾つかの例では、動的な提示において、MPDタイムラインのゼロ点は、有効な利用可能な開始時間によって示されるウォール・クロック時間内の時点にマッピングされる。従って、各々のメディア・セグメントは、メディア・セグメントが提示されるように意図されている瞬間を示すウォール・クロック時間に関連付けられる。

【0054】

[0059] 本開示の一態様によれば、時間シフトは、ダイナミック・プレゼンテーションを提示する場合の、ウォール・クロック時間とMPDタイムラインとの間のオフセットとして定義される。幾つかの例では、メディア・クライアント・デバイスが、時間シフト・バッファの終点でメディア・セグメントを提示している場合に、時間シフトはゼロである。更に過去からメディア・セグメントを再生することにより、正の時間シフトが導入される。例えば、30秒の時間シフトは、メディア・クライアント・デバイスが、MPDタイムライン上での位置が時間シフト・バッファの終わりから30秒の距離に達した時点で、メディア・セグメントを提示し始める、ということを意味する。幾つかの例では、時間シフト・バッファ・デプス（time shift buffer depth）と言及されるパラメータが、時間シフト・バッファの開始からウォール・クロックまで（現在まで）の時間範囲として定義される。MSEソース・バッファは、必要とされる時間シフト・バッファ・デプスをサポートするように構成される。

【0055】

[0060] 一例では、プリロール・コンテンツとライブ・コンテンツは単一のマスター初期化セグメントを有することが可能であり、MSEソース・バッファは、再初期化を行うことなく、プリロール・コンテンツからライブ・コンテンツへに移行することが可能であるように構成される。

【0056】

[0061] 幾つかの例では、プリロール・コンテンツとライブ・コンテンツは異なる初期化セグメントを有することが可能である。例えば、プリロール・コンテンツとライブ・コンテンツは、異なるコーデック又は異なるプロファイル又は異なるレベルを有し、従って、異なる初期化セグメントを必要とすることがある。MSEソース・バッファは、追加された再初期化セグメントでメディア・コンテンツを再生することができるように構成される。

【0057】

[0062] 幾つかの例では、MSEソース・バッファは、プリロール・コンテンツを時間シフト・バッファ内に保持するように構成され、その結果、メディア・プレーヤは、プリロール・コンテンツまで戻って探索することが可能である。幾つかの例では、MSEソース・バッファは、プリロール・コンテンツをライブ・・コンテンツに置き換えるように構成され、その結果、プレーヤは時間シフト・バッファ内でライブ・コンテンツを探索することが可能である。

【0058】

[0063] 以下の説明では、MSEソース・バッファで使用される技術を説明するために、プリロール・コンテンツとライブ・コンテンツが使用されている。

【0059】

[0064] プリロール・コンテンツは、再生前に全てのメディア・セグメントが利用可能であるオン・デマンド・コンテンツを指す。幾つかの例において、プリロール・コンテンツの正確な継続時間は不明であるが、可能な最大継続時間（D_MAXと表記される）は既知である。プリロール・コンテンツのプレゼンテーション時間オフセットは既知であり、タイムスケールT_PでPTO_Pによって示される。

【0060】

[0065] ライブ・コンテンツの場合、ライブ・コンテンツの利用可能開始時間と現在のピリオドの開始時間とは分かっている。ウォール・クロック時間におけるピリオドの開始時間は、PStart_Lで表記されることが可能である。プレゼンテーション時間オフセットは既知であり、時間スケールT_LでPTO_Lによって示される。ライブ番組を開始するセグメント・アドレスは分かっているが、そのセグメントの正確な最先のプレゼンテーション時間（EPT_Lによって表記される）は不明である。しかしながら、EPT_Lの下限値（lower-bound value）は分かっており、EPT_minによって表記される。ライブ・コンテンツの所望の時間シフト・バッファ・デプスは、TSBD_Lとして分かっている。

【0061】

[0066] 図3は、幾つかの例におけるMSEソース・バッファのタイミング・モデルを示す。

【0062】

[0067] 幾つかの実施形態では、アペンド・ウィンドウが定義され、これは、最小限、プリロール・コンテンツと時間シフト・バッファ・デプスを含むことが可能である。一般に、アペンド・ウィンドウは、付加する一方で、コーディングされたフレームをフィルタリングするために使用されるプレゼンテーション・タイムスタンプ範囲である。アペンド・ウィンドウは、単一の開始時間と終了時間を有する単一の連続時間範囲を表す。MSEアペンド・ウィンドウ内にプレゼンテーション・タイムスタンプを有するコーディングされたフレームは、MSEソース・バッファに付加されることが可能である一方、この範囲の外にあるコーディングされたフレームはフィルタリングされる。

【0063】

[0068] 幾つかの実施形態では、MSEソース・バッファのタイムラインは、メディア・コンテンツの時間範囲（複数）に分けられる。図3の例では、MSEソース・バッファのタイムラインは、プリロール・コンテンツ（例えば、プリロール・セグメント）のための第1時間範囲と、ライブ・コンテンツ（例えば、ライブ・セグメント）のための第2時間範囲とを含む。第1時間範囲は（Pstart, Pend）によって示され、第2時間範囲は（Lstart, Lend）によって示される。Pstartはプリロール・コンテンツの開始時間であり、Pendはプリロール・コンテンツの終了時間であり、Lstartはライブ・コンテンツの開始時間であり、Lendはライブ・コンテンツの終了時間である。

【0064】

[0069] 幾つかの例では、タイムスタンプ・オフセット（TSO）は、MSEソース・バッファに付加される後続のメディア・セグメント内のタイムスタンプに適用されるオフセットを制御するために使用されるパラメータである。TSOが0であることは、オフセットが適用されないことを示す。図3の例では、プレゼンテーション時間開始時間は0であるように仮定されている（例えば、PT=0）。MSEソース・バッファは、プリロール・コンテンツの再生位置が、プレゼンテーション時間の後であって、第1時間範囲の前であることを可能にする。タイミング・ギャップg0は、プリロール・コンテンツの最初のセグメントからプレゼンテーション開始時間までであり；タイミング・ギャップg1は、プリロール・コンテンツの最後のセグメントとライブ・コンテンツの最初のセグメントとの間である。一例では、タイムスタンプ・オフセットTSO_Pは、プリロール・セグメントのタイムスタンプに適用するために決定することが可能であり、タイムスタンプ・オフセットTSO_Lは、ライブ・セグメントのタイムスタンプに適用するために決定することが可能である。

【0065】

[0070] 幾つかの例では、第1時間範囲のプリロール・コンテンツの最後のメディア・セグメントが再生される場合に、メディア・クライアント・デバイスは、第2時間範囲の開始を探し求めることが可能である。

【0066】

[0071] 幾つかの例において、プリロール・コンテンツが一度再生されるように予定されるならば、第1時間範囲は、プリロール・コンテンツが再生された後に除去されることが可能である。幾つかの例では、メディア・クライアント・デバイスが、より早期の時間シフトされたライブ・コンテンツを探索する場合、より早期の時間シフトされたライブ・コンテンツのための第3時間範囲は、プリロール・コンテンツが再生されるように予定されるならば、第1時間範囲より前に作成されることが可能である。

【0067】

[0072] 図4は、本開示の幾つかの実施形態による非線形オペレーションのために、メディア・クライアント・デバイス（200）におけるMSEソース・バッファのような、メディア・クライアント・デバイスにおけるソース・バッファを使用するためのプロセス（400）の概略を示すフロー・チャートを示す。

【0068】

[0073] （S410）では、ソース・バッファが、プリロール・コンテンツとライブ・コンテンツの情報に基づいて設定される。幾つかの例では、プリロール・コンテンツは一度再生され、その後、ソース・バッファから削除することが可能である。幾つかの例では、プリロール・コンテンツが一度再生された後、プリロール・コンテンツはミッドロール（midroll）としてソース・バッファに残る。ソース・バッファは、様々な例において適切にセットアップされることが可能である。ソース・バッファの設定は、2つの特定のケースを参照して詳細に説明される。

【0069】

[0074] （S420）において、プリロール・セグメントの再生が実行される。再生については、2つの具体的なケースを参照しながら詳細に説明される。

【0070】

[0075] （S430）において、ライブ・セグメントへの移行は、再－初期化条件（re-initialization requirement）に応答して実行されることが可能である。幾つかの例において、ライブ・コンテンツは、プリロール・コンテンツと同じプロファイルとレベルを有し、従って、ライブ・コンテンツの再生は、プリロール・セグメント及びライブ・セグメントの両方について、同じマスター初期化セグメントを使用して実行することが可能である。幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツとは異なるコーデックを使用するか、ライブ・コンテンツは、プリロール・コンテンツとは異なるプロファイルを有するか（例えば、メディア・コンテンツの種類、メディア・フォーマット、コーデック、保護フォーマット、ビットレート、セグメント継続時間、サイズなどに関する特定の制限を定義するために、プロファイルを使用することができる）、又はライブ・コンテンツは、プリロール・コンテンツとは異なるレベル（例えば、適応セット、リプリゼンテーション、プレセレクション）を有する場合、ライブ・セグメントの再生には再－初期化が必要とされる。移行については、2つの具体的なケースを参照しながら詳細に説明する。

【0071】

[0076] 第1ケースでは、プリロール・コンテンツは一度再生され、その後、ソース・バッファから削除されることが可能である。

【0072】

[0077] ソース・バッファをセットアップするために、一部の例では、メディア・クライアント・デバイスが、メディア・ソースはプリロール・ビデオ・コーデックとプロファイルをサポートしていることをチェックした後に、メディア・クライアント・デバイスはソース・バッファを作成することが可能である。次いで、メディア・クライアント・デバイスは、ソース・バッファのアペンド・ウィンドウを設定する。一例において、最大時間シフト（TSB_MAXによって表記される）は、例えば、Eq.（1）を用いて、プリロール・コンテンツの最大継続時間（D_MAXによって表示される）、及びライブ・コンテンツの所望の時間シフト・バッファ・デプス（TSBD_L）深さ、のうちの何れか大きい方として決定される。

【0073】

【数1】

[0078] 更に、パラメータL_Maxは、ライブ・コンテンツの最長継続時間を示すために使用される。幾つかの例では、ライブ・コンテンツ（例えば、ライブ番組）の最長継続時間は分かっており、従ってそれに応じてパラメータL_Maxを決定することができる。次いで、アペンド・ウィンドウの開始は0に設定され、アペンド・ウィンドウの終了は、TSB_MAXとL_Maxの合計に設定される。幾つかの例では、ライブ番組の継続時間は不明であり、アペンド・ウィンドウの終了は、大きな数又は無限大となる可能性がある。

【0074】

[0079] プリロール・コンテンツの再生を実行するために、幾つかの例では、メディア・クライアント・デバイスは、Eq.（2）に従ってプリロール・セグメントのTSO_Pを設定する：

【0075】

【数2】

[0080] 次いで、メディア・クライアント・デバイスは、最初のプリロール・セグメントをフェッチし、最初のプリロール・セグメントをソース・バッファに追加する。更に、メディア・クライアント・デバイスは、最後のプリロール・セグメントになるまで、残りのプリロール・セグメントをフェッチし続け、フェッチしたプリロール・セグメントを連続順序でソース・バッファに追加する。最後のプリロール・セグメントを追加した後、メディア・クライアント・デバイスは、再－初期化条件に応じてライブ・セグメントに移行する。

【0076】

[0081] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツと同じプロファイルとレベルを有し、従って、同じ初期化セグメント（幾つかの例では、マスター初期化セグメントと言及される）が、ライブ・コンテンツとプリロール・コンテンツの両方に使用されることが可能であり、再－初期化は不要である。ライブ・セグメントに移行するために、メディア・クライアント・デバイスは、Eq.（3）に従ってライブ・セグメントのTSO_Lを設定する：

【0077】

【数3】

[0082] 次いで、メディア・クライアント・デバイスは、最初のライブ・セグメントをフェッチし、最初のライブ・コンテンツをソース・バッファに追加する。メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし続け、フェッチしたライブ・セグメントを連続順序でソース・バッファに追加する。

【0078】

[0083] プリロール・コンテンツの最後のセグメントが復号化されて再生されると、メディア・クライアント・デバイスは、ライブ・コンテンツの時間範囲の開始時間を探し求めて、ライブ・コンテンツの最初のセグメントを復号化して再生することができる。

【0079】

[0084] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツと同じプロファイルとレベルを有し、従って、同じ初期化セグメント（幾つかの例では、マスター初期化セグメントと言及される）が、ライブ・コンテンツとプリロール・コンテンツの両方に使用されることが可能であり、再－初期化は不要である。しかしながら、一例では、ソース・バッファはシーケンス・モードを設定することが可能であり、シーケンス・モードは、メディア・セグメントが、前のメディア・セグメントの直後に配置されることを許容する。

【0080】

[0085] ライブ・セグメントに移行するために、シーケンス・モードでは、メディア・クライアント・デバイスは、最初のライブ・セグメントをフェッチし、最初のライブ・セグメントをソース・バッファにシーケンス・モードで（例えば、プリロール・コンテンツの最後のセグメントの後に隣接して）追加することが可能である。一例では、TSO_Lは、Eq.（4）に従って設定することができる：

【0081】

【数4】

[0086] ライブ・コンテンツに関する最先のプレゼンテーション時間EPT_Lは、バッファリングされたプリロール・セグメントに基づいて決定することが可能である。一例では、ライブ・セグメントが、プリロール・コンテンツの第1時間範囲に追加されることに留意されたい。従って、メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし続け、フェッチしたライブ・セグメントをソース・バッファに追加することが可能である。

【0082】

[0087] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツとは異なるコーデック又は異なるプロファイル（例えば、より高いプロファイル）又は異なるレベル（例えば、より高いレベル）を有し、従って、ライブ・コンテンツは、プリロール・コンテンツとは異なるマスター初期化セグメントを有し、再－初期化が必要とされる。

【0083】

[0088] ライブ・セグメントに移行するために、メディア・クライアント・デバイスは、Eq.（4）に従ってTSO_Lを更新することが可能である。その後、再－初期化を実行することが可能である。例えば、メソッドchangeType()は、ライブ・コンテンツのコーデック/プロファイル/レベルと共に発行されることが可能である。メディア・クライアント・デバイスは、ライブ・セグメントに対して新しい時間範囲を生成することが可能である。その後、メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし始め、ライブ・セグメントをソース・バッファに追加することができる。再生中に、プリロール時間範囲の終了に達した場合、メディア・クライアント・デバイスは、ライブ・コンテンツ時間範囲の開始時間を探し求めることが可能である。

【0084】

[0089] 第1ケースでは、メディア・クライアント・デバイスは、時間シフト・バッファリング管理を実行することが可能である。時間シフト・バッファリングは：第1時間範囲（Pstart, Pend）と第2時間範囲（Lstart, Lend）という2つの範囲を含むことが可能である。一般的なケースでは、タイミング・ギャップg0は、プレゼンテーション開始時間から、プリロール・コンテンツの最初のセグメントまでであり（例えば、g0 = （0, Pstart））；タイミング・ギャップg1は、プリロール・コンテンツの最後のセグメントと、ライブ・コンテンツの最初のセグメントとの間にある（例えば、g1 = （Pend, Lstart））。一例において、TSB_MAX = D_MAXであるならば、g0 = 0である。別の例において、プリロール・コンテンツの継続時間Dp = D_MAX及びEPT_min = EPT_L ならば、g1 = 0 である。

【0085】

[0090] 幾つかの例では、メディア・クライアント・デバイスは、プリロール・コンテンツの再生後に、プリロール・コンテンツを時間シフト・バッファから削除する。時間シフト・バッファリングからプリロール・コンテンツを削除するために、メディア・クライアント・デバイスは、先ず、時間範囲（Pstart, Pend）を削除する可能性がある。従って、ソース・バッファは（0, TSB_MAX）において空になる。その後、メディア・クライアント・デバイスは、アペンド・ウィンドウの開始を、0からTSB_MAX - TSBD_Lに変更することが可能である。従って、時間シフト・バッファ・デプスはTSBD_Lとなり、メディア・クライアント・デバイスが時間シフト・バッファを探し求める場合に、適切なセグメントがフェッチされる。

【0086】

[0091] 第2ケースでは、プリロール・コンテンツは1回再生され、ミッドロールとしてソース・バッファに残る。

【0087】

[0092] ソース・バッファをセットアップするために、幾つかの例では、メディア・クライアント・デバイスが、メディア・ソースはプリロール・ビデオ・コーデックとプロファイルをサポートしていることをチェックした後に、メディア・クライアント・デバイスは、ソース・バッファを作成することが可能である。次いで、メディア・クライアント・デバイスは、ソース・バッファのアペンド・ウィンドウを設定する。一例において、最大時間シフト（TSB_MAXにより表示される）は、プリロール・コンテンツの最大継続時間（D_MAXにより表示される）、ライブ・コンテンツの所望時間シフト・バッファ・デプス（TSBD_L）、EPDP_L、及びEDP_minに基づいて、例えばEq.（5）を用いて決定される：

【0088】

【数5】

[0093] 更に、パラメータL_Maxは、ライブ・コンテンツの最長継続時間を示すために使用される。幾つかの例では、ライブ・コンテンツ（例えば、ライブ番組）の最長継続時間は分かっており、従ってそれに応じてパラメータL_Maxを設定することができる。次いで、アペンド・ウィンドウの開始は0に設定され、アペンド・ウィンドウの終了はTSB_MAXとL_Maxの合計に設定される。幾つかの例では、ライブ・コンテンツの継続時間は不明であり、アペンド・ウィンドウの終了は、大きな数又は無限大となる可能性がある。

【0089】

[0094] プリロール・コンテンツの再生を実行するために、幾つかの例では、メディア・クライアント・デバイスは、Eq.（6）に従ってプリロール・セグメントのTSO_Pを設定する：

【0090】

【数6】

[0095] 次いで、メディア・クライアント・デバイスは、最初のプリロール・セグメントをフェッチし、最初のプリロール・セグメントをソース・バッファに追加する。更に、メディア・クライアント・デバイスは、最後のプリロール・セグメントになるまで、残りのプリロール・セグメントをフェッチし続け、フェッチしたプリロール・セグメントを連続順序でソース・バッファに追加する。最後のプリロール・セグメントを追加した後、メディア・クライアント・デバイスは、再－初期化条件に応じてライブ・セグメントに移行する。

【0091】

[0096] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツと同じプロファイルとレベルを有し、従って、同じ初期化セグメント（幾つかの例では、マスター初期化セグメントと言及される）が、ライブ・コンテンツとプリロール・コンテンツの両方に使用されることが可能であり、再－初期化は不要である。ライブ・セグメントに移行するために、メディア・クライアント・デバイスは、Eq.（7）に従ってライブ・セグメントのTSO_Lを設定する：

【0092】

【数7】

[0097] 次いで、メディア・クライアント・デバイスは、最初のライブ・セグメントをフェッチし、最初のライブ・コンテンツをソース・バッファに追加する。メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし続け、フェッチしたライブ・セグメントを連続順序でソース・バッファに追加する。

【0093】

[0098] プリロール・コンテンツの最後のセグメントが復号化されて再生されると、メディア・クライアント・デバイスは、ライブ・コンテンツの時間範囲の開始時間を探し求めて、ライブ・コンテンツの最初のセグメントを復号化して再生することができる。

【0094】

[0099] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツと同じプロファイルとレベルを有し、従って、同じ初期化セグメント（幾つかの例では、マスター初期化セグメントと言及される）が、ライブ・コンテンツとプリロール・コンテンツの両方に使用されることが可能であり、再－初期化は不要である。しかしながら、一例では、ソース・バッファはシーケンス・モードを設定することが可能であり、シーケンス・モードは、メディア・セグメントが、前のメディア・セグメントの直後に配置されることを許容する。

【0095】

[0100] ライブ・セグメントに移行するために、シーケンス・モードでは、メディア・クライアント・デバイスは、最初のライブ・セグメントをフェッチし、最初のライブ・セグメントをソース・バッファにシーケンス・モードで（例えば、プリロール・コンテンツの最後のセグメントの後に隣接して）追加することが可能である。一例では、TSO_Lは、Eq.（8）に従って設定することができる：

【0096】

【数8】

[0101] ライブ・コンテンツに関する最先のプレゼンテーション時間EPT_Lは、バッファリングされたプリロール・セグメントに基づいて決定することが可能である。一例では、ライブ・セグメントが、プリロール・コンテンツの第1時間範囲に追加されることに留意されたい。従って、メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし続け、フェッチしたライブ・セグメントをソース・バッファに追加することが可能である。

【0097】

[0102] 幾つかの例では、ライブ・コンテンツは、プリロール・コンテンツとは異なるコーデック又は異なるプロファイル（例えば、より高いプロファイル）又は異なるレベル（例えば、より高いレベル）を有し、従って、ライブ・コンテンツは、プリロール・コンテンツとは異なるマスター初期化セグメントを有し、再－初期化が必要とされる。

【0098】

[0103] ライブ・セグメントに移行するために、メディア・クライアント・デバイスは、Eq.（4）に従ってTSO_Lを更新することが可能である。その後、再－初期化を実行することが可能である。例えば、メソッドchangeType()は、ライブ・コンテンツのコーデック/プロファイル/レベルと共に発行されることが可能である。メディア・クライアント・デバイスは、ライブ・セグメントに対して新しい時間範囲を生成することが可能である。その後、メディア・クライアント・デバイスは、ライブ・セグメントをフェッチし始め、ライブ・セグメントをソース・バッファに追加することができる。再生中に、プリロール時間範囲の終了に達した場合、メディア・クライアント・デバイスは、ライブ・コンテンツ時間範囲の開始時間を探し求めることが可能である。

【0099】

[0104] 第2ケースでは、メディア・クライアント・デバイスは、時間シフト・バッファリング管理を実行することが可能である。時間シフト・バッファリングは：第1時間範囲（Pstart, Pend）と第2時間範囲（Lstart, Lend）という2つの範囲を含むことが可能である。一般的なケースでは、タイミング・ギャップg0は、プレゼンテーション開始時間から、プリロール・コンテンツの最初のセグメントまでであり（例えば、g0 = （0, Pstart））；タイミング・ギャップg1は、プリロール・コンテンツの最後のセグメントと、ライブ・コンテンツの最初のセグメントとの間にある（例えば、g1 = （Pend, Lstart））。一例において、プリロール・コンテンツの継続時間Dp = D_MAX及びEPT_min = EPT_L ならば、g1 = 0 である。

【0100】

[0105] 第2ケースでは、プリロール・コンテンツは再生された後にソース・バッファに残り、メディア・クライアント・デバイスは、プリロール・コンテンツより前の、ライブ・コンテンツの部分のタイムシフト・バッファリングのための第3時間範囲を設定することが可能である。幾つかの例では、プリロール・コンテンツより前にライブ・コンテンツの部分を、タイムシフト・バッファリングのためのソース・バッファに充填するために、メディア・クライアント・デバイスは、プリロール・コンテンツより前のライブ・コンテンツの部分に対するタイムスタンプ・オフセットTSO_LBPを例えばEq.（9）に従って決定する：

【0101】

【数9】

ここで、MSDは、ライブ・コンテンツにおけるセグメントの最大継続時間を示す。

【0102】

[0106] 次いで、メディア・クライアント・デバイスは、(EPTmin-TSBD_L)からEPTminまでの範囲内にあるライブ・コンテンツのセグメントをフェッチし、フェッチしたセグメントをソース・バッファに追加することが可能である。メディア・クライアント・デバイスは、EPTminより前のセグメントまで、セグメントを追加し続けることが可能である。

【0103】

[0107] 本開示の態様に従って、上記の技術はMPDチェイニング（MPD chaining）に使用することが可能である。MPDチェイニングとは、あるメディア・プレゼンテーションの最後に、新たなメディア・プレゼンテーションが始まることを指示する仕組みを指す。幾つかの例において、第1メディア・プレゼンテーションが最後まで再生され、いったん第1メディア・プレゼンテーションが終了すると、新しいチェーン化されたメディア・プレゼンテーション（第2メディア・プレゼンテーションとも言及される）が速やかに再生される。連鎖元MPD（chained-from MPD）（第1メディア・プレゼンテーション）を受信するメディア・クライアント・デバイスは、連鎖元MPDの直後に連鎖先MPD（chained-to MPD）（第2メディア・プレゼンテーション）を再生するように構成されている。各MPDは自身の独立したメディア・タイムラインを有するが、メディア・クライアント・デバイスは、そのプレゼンテーションを続けて、シーケンシャルなプレゼンテーションを作成することが可能である。連鎖元MPDは静的又は動的なタイプのものであってよい。連鎖先MPDも静的なタイプであっても動的なタイプであってもよい。

【0104】

[0108] 幾つかの例では、第1メディア・プレゼンテーションは、プリロール・コンテンツとして再生されるオン・デマンドMPDであり、その後、ライブMPDである第2メディア・プレゼンテーションにチェーン化される。幾つかの例では、上述の技術を用いて、ソース・バッファは、プリロール時間範囲とライブ・コンテンツ時間範囲を含むように構成することが可能である。プリロール時間範囲は、オン・デマンドMPDで記述されるコンテンツをバッファリングするために使用され、ライブ・コンテンツ時間範囲はライブMPDに使用される。プリロール・コンテンツ及びライブ・コンテンツを処理するための上記の技術、例えば、タイミング・モデル、ソース・バッファの構築、時間シフト・バッファリングの管理、及び時間範囲の間の探索のようなものは、オン・デマンドMPDやライブMPDに等しく適用することが可能である。

【0105】

[0109] 上述した技術は、コンピュータ読み取り可能な命令を用いるコンピュータ・ソフトウェアであって、1つ以上のコンピュータ読み取り可能な媒体に物理的に記憶されるものとして実装することが可能である。例えば、図5は、開示される対象事項の特定の実施形態を実施するのに適したコンピュータ・システム（500）を示す。

【0106】

[0110] コンピュータ・ソフトウェアは、直接的に又は解釈やマイクロコード実行等を介して、1つ以上のコンピュータ中央処理ユニット（CPU）、グラフィックス処理ユニット（GPU）等によって実行されることが可能な命令を含むコードを生成するために、アセンブリ、コンパイル、リンク等のメカニズムの影響を受ける可能性のある、任意の適切なマシン・コード又はコンピュータ言語を使用してコーディングされることが可能である。

【0107】

[0111] 命令は、例えば、パーソナル・コンピュータ、タブレット・コンピュータ、サーバー、スマートフォン、ゲーミング・デバイス、モノのインターネット（IoT）デバイス等を含む、種々の種類のコンピュータ又はその構成要素において実行されることが可能である。

【0108】

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

【0109】

[0113] コンピュータ・システム（500）は、特定のヒューマン・インターフェース入力デバイスを含んでもよい。このようなヒューマン・インターフェース入力デバイスは、例えば、触覚入力（例えば、キーストローク、スワイプ、データ・グローブの動き）、オーディオ入力（例えば、声、拍手）、視覚入力（例えば、ジェスチャ）、嗅覚入力（図示せず）を介して、1人以上の人間ユーザーによる入力に応答することができる。また、ヒューマン・インターフェース・デバイスは、オーディオ（例えば、会話、音楽、周囲の音）、画像（例えば、スキャンされた画像、静止画像カメラから得られる写真画像）、ビデオ（例えば、2次元ビデオ、立体ビデオを含む3次元ビデオ）のような、人間による意識的入力に必ずしも直接的に関係しない特定のメディアを捕捉するために使用することも可能である。

【0110】

[0114] 入力ヒューマン・インターフェース・デバイスは、キーボード（501）、マウス（502）、トラックパッド（503）、タッチ・スクリーン（510）、データ・グローブ（図示せず）、ジョイスティック（505）、マイクロホン（506）、スキャナ（507）、カメラ（508）のうちの1つ以上を（各々1つしか描いていないが）含んでもよい。

【0111】

[0115] コンピュータ・システム（500）は、特定のヒューマン・インターフェース出力デバイスを含むことも可能である。このようなヒューマン・インターフェース出力デバイスは、例えば、触覚出力、音、光、及び匂い／味を通じて、1人以上の人間ユーザーの感覚を刺激することができる。このようなヒューマン・インターフェース出力デバイスは、触覚出力デバイス（例えば、タッチ・スクリーン（510）、データ・グローブ（図示せず）、ジョイスティック（505）による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバック・デバイスであるとすることも可能である）、オーディオ出力デバイス（例えば、スピーカー（509）、ヘッドフォン（図示せず））、視覚的出力デバイス（CRTスクリーン、LCDスクリーン、プラズマ・スクリーン、OLEDスクリーンを含むスクリーン（510）であって、各々はタッチ・スクリーン入力機能を備えているか又は備えておらず、各々は触覚フィードバック能力を備えているか又は備えておらず、それらの内の一部は、ステレオ投影出力のような手段を介して、2次元視覚出力又は3次元以上の次元の出力を出力することが可能であるもの；仮想現実眼鏡（図示せず）、ホログラフィック・ディスプレイ及びスモーク・タンク（図示せず））、及びプリンタ（図示せず）を含むことができる。

【0112】

[0116] コンピュータ・システム（500）は、CD／DVD又は類似の媒体（521）を有するCD／DVD ROM／RW（520）を含む光媒体、サム・ドライブ（522）、取り外し可能なハード・ドライブ又はソリッド・ステート・ドライブ（523）、テープ及びフロッピー・ディスク（図示せず）のようなレガシー磁気媒体、セキュリティ・ドングル（図示せず）のような特殊化されたROM／ASIC／PLDベースのデバイスなどのような、人間がアクセスできる記憶デバイス及びそれらの関連媒体を含むことも可能である。

【0113】

[0117] 当業者は、本開示の対象事項に関連して使用される用語「コンピュータ読み取り可能な媒体」は、伝送媒体、搬送波、又はその他の一時的な信号を包含しないことも理解するはずである。

【0114】

[0118] コンピュータ・システム（500）は、1つ以上の通信ネットワーク（555）に対するインターフェース（554）を含むことも可能である。ネットワークは、例えば、無線、有線、光であるとすることが可能である。ネットワークは、更に、ローカル、ワイド・エリア、メトロポリタン、車両及びインダストリアル、リアルタイム、遅延耐性などであるとすることが可能である。ネットワークの例は、イーサーネット、無線LAN、セルラー・ネットワーク（GSM、3G、4G、5G、LTEなどを含む）、TV有線又は無線ワイド・エリア・デジタル・ネットワーク（ケーブルTV、衛星TV、地上放送TVを含む）、CANBusを含む車両及びインダストリアル等を含む。特定のネットワークは、一般に、特定の汎用データ・ポート又は周辺バス（549）に接続される外部ネットワーク・インターフェース・アダプタ（例えば、コンピュータ・システム（500）のUSBポート）を必要とし；他のネットワークは、一般に、後述するようなシステム・バスへの接続によって、コンピュータ・システム（500）のコアに組み込まれる（例えば、イーサーネット・インターフェースはPCコンピュータ・システムに組み込まれ、セルラー・ネットワーク・インターフェースはスマートフォン・コンピュータ・システムに組み込まれる）。これらの任意のネットワークを使用して、コンピュータ・システム（500）は、他のエンティティと通信することができる。このような通信は、片－方向性、受信専用（例えば、放送TV）、片－方向性送信専用（例えば、特定のCANbusデバイスに対するCANbus）、又は、双－方向性、例えばローカル又はワイド・エリア・デジタル・ネットワークを使用するその他のコンピュータ・システムに対するものであるとすることが可能である。特定のプロトコル及びプロトコル・スタックは、上述のように、それらのネットワーク及びネットワーク・インターフェースの各々で使用されることが可能である。

【0115】

[0119] 前述のヒューマン・インターフェース・デバイス、人間がアクセス可能な記憶デバイス、及びネットワーク・インターフェースは、コンピュータ・システム（500）のコア（540）に取り付けることが可能である。

【0116】

[0120] コア（540）は、1つ以上の中央処理ユニット（CPU）（541）、グラフィックス処理ユニット（GPU）（542）、フィールド・プログラマブル・ゲート・エリア（FPGA）（543）の形式における特殊なプログラマブル処理ユニット、特定のタスクのためのハードウェア・アクセラレータ（544）、グラフィックス・アダプタ（550）などを含むことが可能である。これらのデバイスは、リード・オンリ・メモリ（ROM）（545）、ランダム・アクセス・メモリ（RAM）（546）、内部大容量ストレージ、例えば内部のユーザー・アクセス不能なハード・ドライブ、SSD、及び類似のもの（547）と共に、システム・バス（548）を介して接続されてもよい。幾つかのコンピュータ・システムでは、システム・バス（548）は、追加のCPU、GPUなどによる拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能であるとすることが可能である。周辺デバイスは、コアのシステム・バス（548）に直接的に或いは周辺バス（549）を介して取り付けることが可能である。一例において、スクリーン（510）はグラフィックス・アダプタ（550）に接続されることが可能である。周辺バスのアーキテクチャは、PCI、USB等を含む。

【0117】

[0121] CPU（541）、GPU（542）、FPGA（543）、及びアクセラレータ（544）は、組み合わされて、上述のコンピュータ・コードを構築することが可能な特定の命令を実行することが可能である。そのコンピュータ・コードは、ROM（545）又はRAM（546）に記憶することが可能である。また、一時的なデータはRAM（546）に記憶することが可能である一方、永続的なデータは、例えば内部大容量ストレージ（547）に記憶することが可能である。1つ以上のCPU（541）、GPU（542）、大容量ストレージ（547）、ROM（545）、RAM（546）などと密接に関連付けることが可能なキャッシュ・メモリを使用することによって、任意のメモリ・デバイスに対する高速な記憶及び検索を可能にすることができる。

【0118】

[0122] コンピュータ読み取り可能な媒体は、様々なコンピュータ実装動作を実行するためのコンピュータ・コードをそこに有することが可能である。媒体及びコンピュータ・コードは、本開示の目的のために特別に設計及び構築されたものであるとすることが可能であり、或いはそれらは、コンピュータ・ソフトウェア分野の当業者に周知で利用可能な種類のものであるとすることが可能である。

【0119】

[0123] 限定ではなく一例として、アーキテクチャ（500）、具体的にはコア（540）を有するコンピュータ・システムは、1つ以上の有形のコンピュータ読み取り可能な媒体に具現化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータ等を含む）に由来する機能を提供することができる。そのようなコンピュータ読み取り可能な媒体は、コア内部大容量ストレージ（547）又はROM（545）のような非一時的な性質のコア（540）の特定のストレージと同様に、上述したようなユーザー・アクセス可能な大容量ストレージに関連する媒体であるとすることが可能である。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア（540）によって実行されることが可能である。コンピュータ読み取り可能な媒体は、特定のニーズに応じて、1つ以上のメモリ・デバイス又はチップを含むことが可能である。ソフトウェアは、コア（540）、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）が、RAM（546）に記憶されたデータ構造を定め、そのようなデータ構造をソフトウェアによって定められたプロセスに従って修正することを含む、本願で説明される特定のプロセス又は特定のプロセスの特定の一部分を実行することを引き起こすことが可能である。更に又は代替として、コンピュータ・システムは、回路（例えば、アクセラレータ（544））内に配線されたロジック又はその他の方法で組み込まれたものに由来する機能を提供することが可能であり、回路は、本願で説明される特定のプロセス又は特定のプロセスの特定の一部分を実行するために、ソフトウェアの代わりに又はソフトウェアと共に動作することが可能である。ソフトウェアに対する言及は、ロジックを含むことが可能であり、必要に応じてその逆も可能である。コンピュータ読み取り可能な媒体に対する参照は、実行用のソフトウェアを記憶する回路（例えば、集積回路（IC））、実行用のロジックを具現化する回路、又は適切な場合にはそれら両方を含むことが可能である。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

【0120】

[0124] 本開示は、幾つかの例示的な実施形態を説明しているが、本開示の範囲内に該当する変更、置換、及び種々の代替的な均等物が存在する。従って、本願で明示的には図示も説明もされていないが、本開示の原理を具現化し、従って本願の精神及び範囲内にある多くのシステム及び方法を、当業者は案出することが可能であろうということが、認められるであろう。

【0121】

[0125] 付記
（付記１）
ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）プレーヤによるメディア再生方法であって：
独立したタイムラインによる第1メディア・コンテンツと第2メディア・コンテンツとに基づいてメディア・ソース拡張（MSE）ソース・バッファを設定するステップ；
前記MSEソース・バッファに付加された前記第1メディア・コンテンツのセグメントに基づいて再生を行うステップ；及び
前記第1メディア・コンテンツの最終セグメントの後に、前記MSEソース・バッファに付加された前記第2メディア・コンテンツの第1セグメントに移行するステップ；
を含む方法。

【0122】

（付記２）
付記1に記載の方法において：
前記第1メディア・コンテンツと前記第2メディア・コンテンツとに基づいて前記MSEソース・バッファにおけるアペンド・ウィンドウを設定するステップ；
を更に含む、方法。

【0123】

（付記３）
付記2に記載の方法において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記方法は：
前記ライブ・コンテンツの最大継続時間と最大時間シフト・バッファ・デプスとの合計に基づいて、前記アペンド・ウィンドウの終点を決定するステップ；
を更に含む、方法。

【0124】

（付記４）
付記3に記載の方法において：
前記プリロール・コンテンツの可能な最大継続時間と前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとのうちの大きい方に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を更に含む、方法。

【0125】

（付記５）
付記4に記載の方法において：
前記プリロール・コンテンツが再生された後に、前記プリロール・コンテンツの時間範囲を除外するステップ；及び
前記最大時間シフト・バッファ・デプスと前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとに基づいて、前記アペンド・ウィンドウの始点を更新するステップ；
を含む、方法。

【0126】

（付記６）
付記4に記載の方法において：
少なくとも、前記プリロール・コンテンツの可能な最大継続時間と、前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとの合計に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を含む方法。

【0127】

（付記７）
付記6に記載の方法において：
前記プリロール・コンテンツ以前の前記ライブ・コンテンツの部分について前記MSEソース・バッファにおける時間範囲を設定するステップ；
を含む方法。

【0128】

（付記８）
付記1に記載の方法において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記方法は：
最大時間シフト・バッファ・デプスと、前記プリロール・コンテンツの可能な最大継続時間と、前記プリロール・コンテンツのプレゼンテーション時間オフセットとに基づいて、前記プリロール・コンテンツのセグメントに対する第1タイムスタンプ・オフセットを決定するステップ；
を含む方法。

【0129】

（付記９）
付記8に記載の方法において：
前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定するステップ；
を含む方法。

【0130】

（付記１０）
付記9に記載の方法において：
前記ライブ・コンテンツと前記プリロール・コンテンツに対する同じ初期化セグメントに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間の下限とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
シーケンス・モードに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；及び
前記ライブ・コンテンツに対する再初期化の条件に応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
のうちの少なくとも1つを更に含む方法。

【0131】

（付記１１）
ハイパーテキスト転送プロトコルによる動的適応ストリーミング（DASH）プレーヤによるメディア再生装置であって、当該装置に備わる処理回路は：
独立したタイムラインによる第1メディア・コンテンツと第2メディア・コンテンツとに基づいてメディア・ソース拡張（MSE）ソース・バッファを設定するステップ；
前記MSEソース・バッファに付加された前記第1メディア・コンテンツのセグメントに基づいて再生を行うステップ；及び
前記第1メディア・コンテンツの最終セグメントの後に、前記MSEソース・バッファに付加された前記第2メディア・コンテンツの第1セグメントに移行するステップ；
を行うように構成されている、装置。

【0132】

（付記１２）
付記11に記載の装置において、前記処理回路は：
前記第1メディア・コンテンツと前記第2メディア・コンテンツとに基づいて前記MSEソース・バッファにおけるアペンド・ウィンドウを設定するステップ；
を行うように更に構成されている、装置。

【0133】

（付記１３）
付記12に記載の装置において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記処理回路は：
前記ライブ・コンテンツの最大継続時間と最大時間シフト・バッファ・デプスとの合計に基づいて、前記アペンド・ウィンドウの終点を決定するステップ；
を行うように更に構成されている、装置。

【0134】

（付記１４）
付記13に記載の装置において、前記処理回路は：
前記プリロール・コンテンツの可能な最大継続時間と前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとのうちの大きい方に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を行うように更に構成されている、装置。

【0135】

（付記１５）
付記14に記載の装置において、前記処理回路は：
前記プリロール・コンテンツが再生された後に、前記プリロール・コンテンツの時間範囲を除外するステップ；及び
前記最大時間シフト・バッファ・デプスと前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとに基づいて、前記アペンド・ウィンドウの始点を更新するステップ；
を行うように更に構成されている、装置。

【0136】

（付記１６）
付記14に記載の装置において、前記処理回路は：
少なくとも、前記プリロール・コンテンツの可能な最大継続時間と、前記ライブ・コンテンツの所望の時間シフト・バッファ・デプスとの合計に基づいて、前記最大時間シフト・バッファ・デプスを決定するステップ；
を行うように更に構成されている、装置。

【0137】

（付記１７）
付記16に記載の装置において、前記処理回路は：
前記プリロール・コンテンツ以前の前記ライブ・コンテンツの部分について前記MSEソース・バッファにおける時間範囲を設定するステップ；
を行うように更に構成されている、装置。

【0138】

（付記１８）
付記11に記載の装置において、前記第1メディア・コンテンツはプリロール・コンテンツであり、前記第2メディア・コンテンツはライブ・コンテンツであり、前記処理回路は：
最大時間シフト・バッファ・デプスと、前記プリロール・コンテンツの可能な最大継続時間と、前記プリロール・コンテンツのプレゼンテーション時間オフセットとに基づいて、前記プリロール・コンテンツのセグメントに対する第1タイムスタンプ・オフセットを決定するステップ；
を行うように更に構成されている、装置。

【0139】

（付記１９）
付記18に記載の装置において、前記処理回路は：
前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する第2タイムスタンプ・オフセットを決定するステップ；
を行うように更に構成されている、装置。

【0140】

（付記２０）
付記19に記載の装置において、前記処理回路は：
前記ライブ・コンテンツと前記プリロール・コンテンツに対する同じ初期化セグメントに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間の下限とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
シーケンス・モードに応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；及び
前記ライブ・コンテンツに対する再初期化の条件に応じて、前記最大時間シフト・バッファ・デプスと、前記ライブ・コンテンツの第1セグメントの最先のプレゼンテーション時間とに基づいて、前記ライブ・コンテンツのセグメントに対する前記第2タイムスタンプ・オフセットを決定するステップ；
のうちの少なくとも1つを行うように更に構成されている、装置。

【図1】

【図2】

【図3】

【図4】

【図5】