特表2024-542607代替メディアプレゼンテーション記述を処理するための方法、デバイス、およびコンピュータ可読媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-11-15
(54)【発明の名称】代替メディアプレゼンテーション記述を処理するための方法、デバイス、およびコンピュータ可読媒体
(51)【国際特許分類】
H04N 21/84 20110101AFI20241108BHJP
H04N 21/437 20110101ALI20241108BHJP
【ＦＩ】
H04N21/84
H04N21/437
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024531533
(86)(22)【出願日】2023-04-18
(85)【翻訳文提出日】2024-05-27
(86)【国際出願番号】 US2023065870
(87)【国際公開番号】W WO2023205620
(87)【国際公開日】2023-10-26
(31)【優先権主張番号】63/332,590
(32)【優先日】2022-04-19
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】18/135,250
(32)【優先日】2023-04-17
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】イーラジ・ソダガー
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164MB13P
5C164UB26P
5C164UB41S
5C164YA21
(57)【要約】
本開示は、一般に、メディアストリーミング技術に関し、さらに詳しくは、コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するための方法および装置に関する。本方法は、HTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスによってコンテンツサーバから代替MPDのマニフェストを受信するステップと、マニフェストを構文解析して代替MPDの一組のパラメータを抽出するステップであって、一組のパラメータは、DASHイベントストリームの値、プレゼンテーション時間、または持続時間のうちの少なくとも1つを含む、ステップと、プレゼンテーション時間に基づいてメイン・メディア・プレゼンテーションから代替メディアプレゼンテーションに切り替えるステップと、代替メディアプレゼンテーションの終了に応じて、DASHイベントストリームの値に従ってリターンポイントにおいてメイン・メディア・プレゼンテーションを再生するステップと、を含む。
【特許請求の範囲】
【請求項1】
コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのHTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスによる方法であって、前記方法は、前記DASHメディア・ストリーミング・デバイスにより前記コンテンツサーバから前記代替MPDのためのマニフェストを受信するステップと、
前記マニフェストを構文解析して前記代替MPDのための一組のパラメータを抽出するステップであって、前記一組のパラメータは、DASHイベントストリームの値、プレゼンテーション時間、または持続時間のうちの少なくとも1つを含み、前記プレゼンテーション時間は、メイン・メディア・プレゼンテーションのタイムラインにおいて代替メディアプレゼンテーションが開始するオフセットを示し、前記持続時間は、前記代替メディアプレゼンテーションがアクティブである期間を示す、ステップと、
前記プレゼンテーション時間に基づいてメイン・メディア・プレゼンテーションから代替メディアプレゼンテーションに切り替えるステップと、
前記代替メディアプレゼンテーションの終了に応じて、前記DASHイベントストリームの前記値に従ってリターンポイントにおいて前記メイン・メディア・プレゼンテーションを再生するステップと、
を含む、方法。
【請求項2】
前記プレゼンテーション時間は、実際の切り替え時間とは異なるパラメータである、請求項1に記載の方法。
【請求項3】
前記持続時間は、前記代替メディアプレゼンテーションの実際の持続時間とは異なるパラメータである、請求項1に記載の方法。
【請求項4】
前記DASHイベントストリームの前記値は、タイムシフトを示す第1の値を含み、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションが前記代替メディアプレゼンテーションに切り替えられる時点まで再生される、
請求項1から3のいずれか一項に記載の方法。
【請求項5】
前記DASHイベントストリームの前記値は、置換を示す第2の値を含み、動的を示す第1のMPDタイプに応じて、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションのライブエッジまで再生され、
静的を示す第2のMPDタイプに応じて、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションが前記代替メディアプレゼンテーションに切り替えられた時点に、前記代替メディアプレゼンテーションの実際の持続時間を加えたときまで再生される、
請求項1に記載の方法。
【請求項6】
前記代替MPDは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）イベント処理に従って処理され、ディスパッチされる、請求項1に記載の方法。
【請求項7】
前記代替メディアプレゼンテーションを終了するステップは、前記持続時間の終わりに前記代替メディアプレゼンテーションの再生を終了するステップ、または
停止命令を受信したときに前記代替メディアプレゼンテーションの再生を停止するステップ、
のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項8】
動的を示すMPDタイプに応じて、置換を示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、前記メイン・メディア・プレゼンテーションのライブエッジであり、
タイムシフトを示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するための前記リターンポイントは、実際の切り替え時間またはそれ以降に利用可能な最も早いセグメントである、
請求項1から7のいずれか一項に記載の方法。
【請求項9】
静的を示すMPDタイプに応じて、置換を示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、前記代替メディアプレゼンテーションの実際の切り替え時間と実際の持続時間との合計であり、
タイムシフトを示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するための前記リターンポイントは、前記実際の切り替え時間である、
請求項1から7のいずれか一項に記載の方法。
【請求項10】
コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのHTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスであって、前記DASHメディア・ストリーミング・デバイスは、命令を記憶するためのメモリと、請求項1から9のいずれか一項に記載の方法を行うために前記命令を実行するためのプロセッサと、を含む、DASHメディア・ストリーミング・デバイス。
【請求項11】
命令を記憶するための非一時的コンピュータ可読記憶媒体であって、前記命令は、コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのHTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスのプロセッサによって実行されると、前記DASHメディア・ストリーミング・デバイスに、請求項1から9のいずれか一項に記載の方法を行わせるように構成される、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2022年4月19日に出願された米国仮特許出願第63／332，590号に基づいており、その優先権の利益を主張し、その全体が参照により本明細書に組み込まれる。本出願はまた、2023年4月17日に出願された米国非仮特許出願第18／135，250号に基づいており、その優先権の利益を主張し、その全体が参照により本明細書に組み込まれる。
本出願は、2022年4月19日に出願された米国仮特許出願第63／332，590号に基づいており、その優先権の利益を主張し、その全体が参照により本明細書に組み込まれる。本出願はまた、2023年4月17日に出願された米国非仮特許出願第18／135，250号に基づいており、その優先権の利益を主張し、その全体が参照により本明細書に組み込まれる。
【0002】
本開示は、一般に、メディアストリーミング技術に関し、さらに詳しくは、適応型ストリーミングにおいて代替メディアプレゼンテーション記述（MPD）を処理するための方法および装置に関する。
【背景技術】
【0003】
本明細書で提供されるこの背景技術の説明は、本開示の文脈を一般的に提示するためのものである。本背景技術の節に記載されている限りにおいて、本明細書に記載されている発明者の研究、ならびに本出願の有効な出願時に先行技術として認められない可能性がある説明の態様は、本開示に対して先行技術として明示的にも暗示的にも認められない。
【0004】
MPEG（Moving picture expert group）ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）は、IPネットワークを介してマルチメディアコンテンツをストリーミングするための標準規格を提供する。DASH標準規格において、メディアプレゼンテーション記述（MPD）は、DASHクライアントがDASHサーバからメディアセグメントをダウンロードすることによってメディアコンテンツを適応的にストリーミングするための情報を提供するために使用される。DASH標準規格によってマルチレートコンテンツのストリーミングが可能になる。DASH標準規格の一態様には、MPDイベントおよびインバンドイベントの搬送と、当該イベントの当該取り扱いに用いられるクライアント処理モデルとが含まれる。
【0005】
共通メディアアプリケーションフォーマット（CMAF）は、ハイパーテキスト転送プロトコル（HTTP）ベースのメディアの様々な形式をパッケージ化して配信するのに用いられる標準規格である。この標準規格は、例えば、均一なトランスポートコンテナファイルの下でデータをパッケージ化するためにHTTPライブストリーミング（HLS）およびDASHプロトコルと協働することによって、再生デバイスへのメディアの配信を簡素化する。それはまた、レイテンシを低下させるためにチャンク化されたエンコーディングおよびチャンク化された転送エンコーディングを使用する。
【0006】
MPEG DASHは、IPネットワークを介してマルチメディアコンテンツをストリーミングするためのいくつかの手段を、2つのタイムライン間のメディアプレゼンテーションをシグナリングするための代替MPDイベントと共に提供することができる。代替MPDイベントをどのように処理するかには様々な問題／問題がある。
【0007】
本開示は、問題／課題の少なくとも1つに対処し、メディアストリーミングの技術分野を進歩させる、代替MPDイベントを処理するための様々な実施形態を説明する。
【発明の概要】
【課題を解決するための手段】
【0008】
本開示は、一般に、メディアストリーミング技術に関し、より具体的には、動的適応型ストリーミングにおいて代替MPDイベントを処理するための方法および装置に関する。代替MPDイベントは、メディアコンテンツサーバによってメディアストリーミングクライアントに送信されてもよく、次いでメディアストリーミングクライアントによって処理される。
【0009】
一態様によれば、本開示の一実施形態は、コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのメディア・ストリーミング・デバイスによる方法を提供する。本方法は、メディア・ストリーミング・デバイスによりコンテンツサーバから代替MPDのためのマニフェストを受信するステップと、マニフェストを構文解析して代替MPDのための一組のパラメータを抽出するステップであって、一組のパラメータは、イベントストリームの値、プレゼンテーション時間、または持続時間のうちの少なくとも1つを含み、プレゼンテーション時間は、メイン・メディア・プレゼンテーションのタイムラインにおいて代替メディアプレゼンテーションが開始するオフセットを示し、持続時間は、代替メディアプレゼンテーションがアクティブである期間を示す、ステップと、プレゼンテーション時間に基づいてメイン・メディア・プレゼンテーションから代替メディアプレゼンテーションに切り替えるステップと、代替メディアプレゼンテーションの終了に応じて、イベントストリームの値に従ってリターンポイントにおいてメイン・メディア・プレゼンテーションを再生するステップと、を含む。メディア・ストリーミング・デバイスは、HTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスを含み、イベントストリームはDASHイベントストリームを含む。
【0010】
他の態様によれば、本開示の一実施形態は、メインメディアプレゼンテーション記述（MPD）を用いて代替MPDを構成し、代替MPDをメディア・ストリーミング・デバイスに送信するための、メディア・ストリーミング・コンテンツ・サーバによる方法を提供する。構成されたMPDは、メディア・ストリーミング・デバイスに、本開示に記載された方法実施態様のいずれか1つを実行させるように構成される。メディア・ストリーミング・デバイスは、HTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスを含む。
【0011】
本開示の態様はまた、上記の方法実施態様のいずれか1つを実行するように構成された回路を含むメディア・ストリーミング・デバイスまたは装置を提供する。
【0012】
本開示の態様はまた、命令を記憶する非一時的コンピュータ可読媒体を提供し、命令は、メディア・ストリーミング・デバイスによって実行されると、メディア・ストリーミング・デバイスに、上記の方法実施態様のいずれか1つを行わせるように構成される。
【0013】
上記および他の態様ならびにそれらの実施態様は、図面、明細書、および特許請求の範囲においてさらに詳細に説明される。
【0014】
開示される主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。
【図面の簡単な説明】
【0015】
【図1】本開示の一実施形態によるシステムを示す図である。
【図2】本開示の一実施形態によるHTTPを介した動的適応型ストリーミング（DASH）システムを示す図である。
【図3A】本開示の一実施形態によるDASHクライアントアーキテクチャを示す図である。
【図3B】本開示の一実施形態による他のDASHクライアントアーキテクチャを示す図である。
【図4】本開示における例示的な実施形態のフロー図を示す図である。
【図5】本開示の例示的な実施形態によるコンピュータシステムの概略図である。
【発明を実施するための形態】
【0016】
以下、本発明の一部をなし、図示例として実施形態の特定の例を示す添付の図面を参照して本発明を詳細に説明する。しかしながら、本発明は、様々な異なる形態で具体化されてもよく、したがって、カバーされるまたは特許請求される主題は、以下に記載される実施形態のいずれにも限定されないと解釈されることが意図されることに留意されたい。本発明は、方法、デバイス、構成要素、またはシステムとして具体化され得ることにも留意されたい。したがって、本発明の実施形態は例えばハードウェア、ソフトウェア、ファームウェアやこれらの任意の組合せの形態をとってもよい。
【0017】
本明細書および特許請求の範囲全体を通して、用語は、明示的に記載される意味を超えて文脈内で示唆または暗示される微妙な意味を有する場合がある。本開示で用いられている語句「一実施形態では」または語句「いくつかの実施形態では」は必ずしも同じ実施形態を指さず、本開示で用いられている語句「別の実施形態では」または「他の実施形態では」は必ずしも異なる実施形態を指さない。同様に、本明細書で使用される「一実施態様では」または「いくつかの実施態様では」という語句は、必ずしも同じ実施態様を指すものではなく、本明細書で使用される「別の実施態様では」または「他の実施態様では」という語句は、必ずしも異なる実施態様を指すものではない。例えば、特許請求される主題は、例示的な実施形態／実施態様の全部または一部の組合せを含むことを意図している。
【0018】
一般に、専門用語は、文脈における使用法から少なくとも部分的に理解される場合がある。例えば、本明細書で使用される「および」、「または」、または「および／または」などの用語は、そのような用語が使用される文脈に少なくとも部分的に依存する場合がある様々な意味を含んでもよい。典型的には、A、B、またはCなどのリストを関連付けるために使用される場合の「または」は、ここでは包括的な意味で使用されるA、B、およびC、ならびにここでは排他的な意味で使用されるA、B、またはCを意味することを意図している。加えて、本明細書で使用される「1つまたは複数」または「少なくとも1つ」という用語は、文脈に少なくとも部分的に依存して、単数の意味で任意の特徴、構造、もしくは特性を記述するために使用されてもよく、または複数の意味で特徴、構造、もしくは特性の組合せを記述するために使用されてもよい。同様に、「a」、「an」、または「the」などの用語もやはり、文脈に少なくとも部分的に依存して、単数形の使用法を伝えるか、または複数形の使用法を伝えると理解されてもよい。加えて、「に基づいて」または「によって決定される」という用語は、必ずしも排他的な一組の要因を伝えることを意図していないと理解されてもよく、代わりに、やはり文脈に少なくとも部分的に依存して、必ずしも明示的に記述されていないさらなる要因の存在を可能にする場合もある。
【0019】
ハイパーテキスト転送プロトコル（HTTP）を介したストリーミング
図1は、リモート情報処理装置120が通信ネットワーク130を介して1つまたは複数の集中型または分散型コンテンツサーバ110からコンテンツを要求するように構成されている、例示的なコンテンツ配信システム100を示す。特に、情報処理装置120は、コンテンツ消費アプリケーションとして機能する、専用のハードウェアコンポーネント、汎用ハードウェア上で動作するソフトウェアコンポーネント、またはそれらの組合せを含むことができる。コンテンツ消費アプリケーションは、要求されているコンテンツおよび要求されたコンテンツの特性を指定する1つまたは複数の要求を生成することができる。各要求は、ネットワークプロトコルのスタックに基づいて構築され、通信ネットワーク130を介してコンテンツサーバ110に通信され得る。それに応じて、コンテンツサーバは、要求に従ってビットストリームを生成し、ネットワークプロトコルのスタックを使用してビットストリームをパッケージ化し、ビットストリームパッケージをコンテンツ消費アプリケーションに通信することができる。
図1は、リモート情報処理装置120が通信ネットワーク130を介して1つまたは複数の集中型または分散型コンテンツサーバ110からコンテンツを要求するように構成されている、例示的なコンテンツ配信システム100を示す。特に、情報処理装置120は、コンテンツ消費アプリケーションとして機能する、専用のハードウェアコンポーネント、汎用ハードウェア上で動作するソフトウェアコンポーネント、またはそれらの組合せを含むことができる。コンテンツ消費アプリケーションは、要求されているコンテンツおよび要求されたコンテンツの特性を指定する1つまたは複数の要求を生成することができる。各要求は、ネットワークプロトコルのスタックに基づいて構築され、通信ネットワーク130を介してコンテンツサーバ110に通信され得る。それに応じて、コンテンツサーバは、要求に従ってビットストリームを生成し、ネットワークプロトコルのスタックを使用してビットストリームをパッケージ化し、ビットストリームパッケージをコンテンツ消費アプリケーションに通信することができる。
【0020】
いくつかの例示的な実施態様では、コンテンツは一度に要求されてもよい。言い換えれば、メディアコンテンツの全体が、コンテンツ消費アプリケーションによって要求され、受信され、ローカルに記憶され得る。ローカルに記憶されたコンテンツは、コンテンツ消費アプリケーションの一部であるか、またはコンテンツ消費アプリケーションから分離されているかのいずれかで、例えばメディアプレーヤによって必要に応じて（例えば、抽出、デコーディング、再生）処理および消費され得る。このような処理は、ダウンロードと呼ばれることがある。
【0021】
いくつかの他の実施態様では、コンテンツは、後の消費のためにダウンロードされるのではなく、消費されているときにストリーミングされてもよい。そのような実施態様では、要求されたコンテンツの全体がコンテンツ消費アプリケーションに記憶される必要はない場合がある。むしろ、限られた量のコンテンツのみが、ローリングベースでコンテンツサーバ110から連続的に受信され、コンテンツ処理および再生のための入出力ローカルバッファによって管理される。そのような実施態様は、ストリーミングと呼ばれることがある。巻き戻し、早送り、およびシークなどのいくつかのメディア再生機能は、複雑なメディアビットストリーム制御およびバッファリングを含むことができるが、メディアストリーミングは、通常、より汎用的であり、繰り返し消費されないメディアのタイムドシーケンスを含むコンテンツの配信により適している。
【0022】
以下の開示では、「コンテンツ」および「メディア」という用語は互換的に使用され得る。要求されたコンテンツは、それだけに限らないが、コンテンツ自体および様々なメタデータを含む、その消費に必要な様々な情報項目を含むことができる。コンテンツ自体は、ビデオコンポーネント／トラック、オーディオコンポーネント／トラック、字幕などを含むがこれらに限定されない異なるトラックなどの様々なメディアコンポーネントをさらに含むことができる。メディアコンテンツを記述し、または追加の処理情報を提供するためのメタデータは、1つまたは複数の別個のトラックとして扱われてもよい。そのメタデータを有するそのようなコンテンツは、コンテンツ消費アプリケーションに知られている一組のプロトコルまたは規則に従って構文解析およびデコーディングされ得るビットストリームとしてコンテンツサーバ120によって生成され得る。単数形の「コンテンツサーバ」という用語は、中央位置に配置された、または様々な地理的位置に分散された単一のサーバまたは複数のサーバを表すために使用される。そのようなコンテンツサーバは、専用コンピューティングマシンとして実装されてもよく、あるいは、仮想マシンとして、および／またはクラウドコンピューティング環境に仮想的に収容されて構築されてもよい。さらに、以下の開示において、「情報処理装置」（図1の120を参照）という用語および「コンテンツ消費アプリケーション」という用語は、互換的に使用され得る。あるいは、これらの用語は、「クライアント」、「クライアントデバイス／装置」、「再生デバイス／装置／クライアント」などと呼ばれることもある。なお、図1では、情報処理装置120が1つのみ示されているが、独立した情報処理装置が複数存在することができる。言い換えれば、一組のコンテンツサーバ110は、複数のコンテンツ消費アプリケーションにストリーミングサービスを同時に独立して提供するように構成されてもよい。
【0023】
いくつかの例示的な実施態様では、コンテンツサーバ110による配信のために生成されたコンテンツは、それらのストリーミングを容易にするためにセグメント化されることができる。例えば、映画などのメディアコンテンツのタイムドシーケンスは、各々がいくつかのメディアフレームを含む時間セグメントにチョップすることができる。各メディアセグメントは、例えば構文解析、デコーディング、および再生を含むその処理が他のメディアセグメントのための情報を必要としないように自己完結型であり得る。メディアコンテンツは事前にセグメント化されてもよい。したがって、メディアコンテンツは、セグメントごとにコンテンツサーバ120によって記憶および管理され得る。あるいは、メディアセグメントは、ストリーミングプロセス中に要求されているように、隣接して記憶されたメディアコンテンツからリアルタイムで生成されてもよい。いくつかのさらなる実施態様では、メディアのセグメント化は、複数のレベルのセグメント化を含む階層的であってもよい。
【0024】
ストリーミングのためのいくつかの特定の実施態様では、コンテンツサーバ110からどのメディアセグメントまたはメディアセグメントのどの部分を要求するかに関する決定は、ユーザアプリケーションインターフェースを介したユーザ再生命令によって制御されるように、リアルタイムでコンテンツ消費アプリケーションによって決定することができる。このようにして、コンテンツサーバは、要求に応答し、要求に従ってそれらのメタデータを有するコンテンツのセグメントまたはセグメントの部分を生成または検索し、セグメントまたはセグメントの部分を、ネットワーク130を介して要求しているコンテンツ消費アプリケーションに配信するように構成され得る。
【0025】
いくつかの例示的な実施態様では、メディアコンテンツの同じメディアトラックを異なるバージョンとして準備することができる。例えば、同じムービートラックが、異なる解像度および／またはフレームレートで準備されてもよい。他の例として、同じムービートラックが異なるビットレートで準備されてもよい。他の例として、同じオーディオムービーが、異なる音質および／または異なる数の音声チャネル（例えば、5チャネルの音、または7チャネルの音）で準備されてもよい。したがって、コンテンツ消費アプリケーションは、どのバージョンのメディアトラックをストリーミングするかを決定し、そのような選択をメディアコンテンツの要求に含めることができる。コンテンツ消費アプリケーションによるそのような決定は、情報処理装置120の再生能力（例えば、表示解像度、デコーディング速度、処理能力、バッファサイズなど）、ネットワーク帯域幅およびスループットなどを含むがこれらに限定されない、いくつかの例示的な要因のうちの1つまたは複数に基づいて行われ得る。したがって、ストリーミングセッションは、それらのデバイス能力に応じて異なるメディア消費アプリケーション間で適合させることができる。そのように構成されたストリーミングアーキテクチャは、適応型ストリーミングと呼ばれることがある。ストリーミングプロセスは、メディアトラックの異なるバージョンが、例えばリアルタイムネットワーク条件（例えば、帯域幅およびスループット、ならびにネットワーク帯域幅によってサポートされるビットレート）に従って、ストリーミングセッション中の異なる時間に選択および要求され得るという点で、各メディア消費アプリケーション内でさらに適応的であり得る。そのように構成されたストリーミングアーキテクチャは、動的適応型ストリーミングとさらに呼ばれることがある。特に、メディアコンテンツのビットレートに適応するように構成されたストリーミングアーキテクチャは、動的適応型ビットレートストリーミングと呼ばれることがある。
【0026】
いくつかの例示的な実施態様では、動的適応型ストリーミングにおけるコンテンツ消費アプリケーションによるメディアコンテンツのセグメントの特定のバージョンまたはセグメントの一部に対する要求は、ストリーミングセッションの進行に従ってメディアマニフェストに基づいて構築されてもよい。「マニフェスト」という用語は、セグメント化、バージョン、ネットワークロケーション、およびストリーミングセッション中の異なる時間に要求する方法および内容を決定するためにコンテンツ消費アプリケーションに必要とされ得る任意の他の情報を含む、メディアコンテンツを記述する情報項目の任意の集合を表すために使用され得る。マニフェストは、一般に、「メディアプレゼンテーション記述」（MPD）と呼ばれることがある。
【0027】
そのようなマニフェストは、特定のメディアコンテンツが作成または生成されるときにコンテンツサーバ側で準備されてもよい。そのようなマニフェストは、コンテンツ消費アプリケーションによって要求され、ストリーミングセッションの開始時にコンテンツサーバから受信されてもよい。コンテンツ消費アプリケーションは、ストリーミングセッション中にマニフェストの任意の更新をさらに要求することができる。そのようなマニフェストは、ストリーミングセッション中にメディアコンテンツのセグメントまたはセグメントの一部の特定のバージョンの後続の要求を構築するための青写真としてコンテンツ消費デバイスによって使用され得る。
【0028】
いくつかの例示的な実施態様では、メディアサーバは、外部アプリケーションのスタンドポイントからウェブサーバと同様に機能するように構成されてもよい。したがって、コンテンツ消費アプリケーションによるメディアマニフェストおよび／またはメディアセグメントもしくはメディアセグメントの一部に対する要求は、例えば、ハイパーテキスト転送プロトコル（HTTP）に基づいて行うことができる。このように、要求をURLとして構築し、要求されたコンテンツをコンテンツサーバからのHTTP要求に対する応答として配信してもよい。
【0029】
マニフェストが指定され、コンテンツがセグメント化され、編成され、バージョン管理され、HTTP要求が構築される方法の詳細は、HTTPを介した動的適応型ストリーミング（DASH）、HTTPライブストリーミング（HLS）、スムース・ストリーミング・トランスポート・プロトコル（SSTP）などの特定の適応型ストリーミングプロトコルに依存し得る。以下の様々な追加の例示的な実施態様は、DASHの文脈で説明することができる。しかしながら、基礎となる原理は、任意のタイプのHTTP上の適応型ストリーミングに適用可能である。さらに、基礎となる原理は、HTTP以外のネットワークプロトコルに基づくメディアコンテンツ要求メカニズムに適用可能である。
【0030】
HTTPを介した動的適応型ストリーミング（DASH）
適応型メディアストリーミングを実施するための1つの例示的なプロトコルは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）を含む。上述したように、DASHは、様々なプロキシおよびキャッシュを有するウェブサーバとして構成されたコンテンツサーバなどを含む、ハイパーテキスト転送プロトコル（HTTP）インフラストラクチャに基づくコンテンツ配信ネットワーク（CDN）を使用してメディアコンテンツのストリーミングを可能にする適応型ビットレートストリーミング実装の1つを表す。このようなコンテンツサーバは、DASHサーバと称される場合がある。したがって、上述したコンテンツ消費アプリケーションは、DASHクライアントと呼ぶことができる。
適応型メディアストリーミングを実施するための1つの例示的なプロトコルは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）を含む。上述したように、DASHは、様々なプロキシおよびキャッシュを有するウェブサーバとして構成されたコンテンツサーバなどを含む、ハイパーテキスト転送プロトコル（HTTP）インフラストラクチャに基づくコンテンツ配信ネットワーク（CDN）を使用してメディアコンテンツのストリーミングを可能にする適応型ビットレートストリーミング実装の1つを表す。このようなコンテンツサーバは、DASHサーバと称される場合がある。したがって、上述したコンテンツ消費アプリケーションは、DASHクライアントと呼ぶことができる。
【0031】
DASHは、DASHサーバからDASHクライアントへのライブストリーミングをサポートし、DASHクライアントがストリーミングセッションを制御することを可能にするので、DASHサーバは、大規模展開におけるストリームアダプテーション管理のさらなる負荷に対処する必要がない。上述したように、DASHはまた、DASHクライアントが様々なDASHサーバからストリーミングを選択することを可能にし、それによってDASHクライアントの利益のためにネットワークのさらなる負荷分散を達成する。DASHは、例えば、DASHクライアントのネットワーク条件および処理能力に適応するようにビットレートを変えることによって、メディアトラックの異なるメディアバージョン間の動的な切り替えをさらに提供する。
【0032】
DASHでは、上記のメディアマニフェストは、特にMPDと呼ばれる場合がある（ただし、MPDという用語は、DASHに基づくもの以外の適応型ストリーミングシステムにおける任意のタイプのマニフェストを指すために一般的に使用される場合がある）。例えば、DASHにおけるMPDは、DASHクライアントによって完全にまたは部分的にダウンロード可能であり、DASHサーバからストリーミングメディアセグメントを選択的かつ適応的に要求することによってメディアコンテンツをストリーミングするためにDASHクライアントによって使用される情報項目を提供するファイルとして構築されてもよい。
【0033】
MPDは、様々なフォーマットで構成され得る。例えば、MPDは、拡張マークアップ言語（XML）文書またはファイルの形式で構築されてもよい。MPDファイルが要求され、DASHクライアントに配信されてもよい。MPDファイルは、例えばHTTP GET要求を介してHTTPにより要求されてもよい。MPDファイルは、ストリーミングセッションの開始時に完全に配信されてもよい。あるいは、MPDファイルは断片化されて部分的に配信され得る。このように、MPDファイルの一部は、ストリーミングの開始前に要求および配信されてもよく、MPDファイルの他の部分は、セッション開始遅延を低減するために要求および配信されてもよい（これにより、ストリーミングは、メディアの後のセグメントに関係する情報項目を待つ必要なく、前のメディアセグメントから開始することができる）。MPDファイルは、（例えば、必要であるがまだ取得されていないセグメント情報を用いて）ストリーミングセッション中に更新することもできる。
【0034】
いくつかの例示的な実施態様では、MPDファイルは、メディアコンテンツのセグメント化、セグメントの編成、およびセグメントの利用可能なバージョンを記述する。MPDは、コンテンツのアクセシビリティ機能、レーティング、カメラビュー、メタデータなどの表現をサポートしてもよい。DASHはまた、マルチ・ビューおよびスケーラブルなコーディングされたコンテンツの配信をサポートしてもよい。
【0035】
いくつかの例示的な実施態様では、MPDファイルは、メディア消費タイムライン（例えば、ビデオコンテンツの再生時間）に沿った1つまたは複数の期間についての一連の記述を含むことができる。1つまたは複数のピリオドのそれぞれは、例えば、MPDファイル内の「ピリオド」の情報要素タグにより定義されるようにしてもよい。メディアコンテンツは、複数の連続した期間にまとめられたMPDファイルによって示されてもよい。MPDファイルは、再生タイムラインにおける期間の各々の開始時間を識別することができる。開始時間は、メディアコンテンツの先頭からの絶対開始時間として、または再生タイムラインにおける他の参照点からの相対オフセットとして定義されてもよい。
【0036】
いくつかの例示的な実施態様では、メディア期間ごとに、MPDファイルは、1つまたは複数の適応セットをさらに指定することができる。メディアコンポーネントのうちの1つまたは複数の異なる組合せ（またはサブセット）を取り込むために、異なるアダプテーションセットを指定することができる。例えば、ビデオとオーディオは異なるアダプテーションセットとすることができる。オーディオの異なるバージョン（ステレオオーディオまたはマルチチャネルオーディオ）は、異なるアダプテーションセットであってもよい。異なる言語のオーディオは、異なるアダプテーションセットであってもよい。特定の一例では、MPDファイルは、各期間が1つのビデオアダプテーションセット、複数のオーディオアダプテーションセット、サポートされている言語ごとに1つを含むことを指定することができる。また、アダプテーションセットは、字幕や任意のメタデータを含むことができる。
【0037】
いくつかの例示的な実施態様では、特定の周期のアダプテーションセットは、MPDファイル内のグループ属性によって示されるグループに割り当てられ得る。同じグループ内のアダプテーションセットは、一般に、互いに代替と見なされる。例えば、特定の期間のビデオデータの各アダプテーションセットは同じグループに割り当てられ得、その結果、対応する期間のマルチメディアコンテンツのビデオデータに対して任意のアダプテーションセットが選択され得る。1つの期間内のメディアコンテンツは、各グループが最大で1つのアダプテーションセットに寄与する、1つのアダプテーションセット、またはアダプテーションセットの組合せのいずれかからのものとすることができる。
【0038】
いくつかの例示的な実施態様では、各アダプテーションセットは、対応する期間の同じメディアコンポーネントの1つまたは複数の表現を含むものとしてMPDファイルによって指定されてもよい。例えば、表現は、オーディオまたはビデオデータのいくつかの代替的なエンコーディングされたバージョンのうちの1つであり得る。表現は、エンコーディングタイプ、例えば、ビデオデータのビットレート、解像度、および／またはコーデック、ならびにオーディオデータのビットレート、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の範囲の平均ビットレートを達成するために特定の方法でエンコーディングされた、エンコーディング済メディアデータのセクションを指すために使用され得る。いくつかの例示的な実施態様では、アダプテーションセット内の各表現について、MPDファイルは、ビデオ／オーディオタイプ、ビデオ／オーディオコーデック、画素単位のビデオフレーム幅、画素単位のビデオフレーム高さ、ビデオ／オーディオフレームレート、および帯域幅（平均エンコーディング済ビットレートを表す）を含むがこれらに限定されない表現の属性を指定することができる。
【0039】
アダプテーションセットの各表現はまた、アダプテーションセットに含まれるメディアコンポーネントの組合せに応じて、1つまたは複数のメディアコンポーネントを含むことができる。表現内の各メディアコンポーネントは、オーディオ、ビデオ、またはタイムドテキスト（例えば、クローズドキャプション用）などの1つの個々のメディアタイプのエンコーディング済バージョンに対応することができる。メディアコンポーネントは、1つの表現内の連続するメディアセグメントの境界にわたって時間的に連続的であり得る。
【0040】
いくつかの例示的な実施態様では、表現は1つまたは複数のセグメントを含むことができる。各表現は初期化セグメントを含むことができ、または表現の各セグメントは自己初期化され得る。存在する場合、初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。場合によっては、初期化セグメントはメディアデータを含まない。メディアデータを含むセグメントは、時間セグメント化コンテンツを表すことができる。異なる表現間のセグメントは、時間的に位置合わせされてもよい。メディアセグメントごとに、MPDファイルは一意の識別子を含むことができる。そのような識別子は、ベースURL、ベースURN、またはベース統一リソース識別子（URI）と組み合わされると、メディアセグメントのネットワーク位置を表す一意のURL、URN、またはURIを形成することができ、これはこのメディアセグメントのHTTP要求に含まれ、配信のために要求されたセグメントを見つけるためにコンテンツサーバによって使用され得る。
【0041】
例えば、メディアセグメントを要求するためのURLは、「http」または「https」の固定スキームで＜absolute－URI＞として定義され得、場合によってはURLと共に範囲属性が提供される場合にバイト範囲によってさらに補足される。バイト範囲は、セグメント内の連続したバイト範囲を識別するように表現され得る。
【0042】
いくつかのさらなる例示的な実施態様では、サブ表現は、例えばサブ表現要素／インジケータを使用して、通常の表現に埋め込まれる（または含まれる）ものとしてMPDファイルに指定および記述されてもよい。サブ表現要素は、表現に埋め込まれた1つまたは複数のメディアコンテンツ構成要素のプロパティを記述するために使用され得る。例えば、サブ表現要素は、埋め込みオーディオコンポーネント（例えば、コーデック、サンプリングレートなど）、埋め込みサブタイトル（例えば、コーデック）のプロパティを記述するために使用されてもよく、またはサブ表現要素は、いくつかの埋め込み低品質ビデオ層（例えば、いくつかのより低いフレームレートなど）を記述するために使用されてもよい。サブ表現および表現要素は、いくつかの共通の属性および要素を共有することができる。
【0043】
いくつかの例示的な実施態様では、DASHクライアントは、DASHサーバからMPDファイルの全体または一部にアクセスし、ダウンロードし、要求するように構成することができる。すなわち、DASHクライアントは、ライブストリーミングセッションの開始に用いられるMPDファイルを取得することができる。MPDファイルおよび表現の選択に基づいて、DASHクライアントは、サーバ上で利用可能な最新のセグメントが何であるかを判定すること、次のセグメントおよび場合によっては将来のセグメントのセグメント可用性開始時間を判定すること、セグメントの再生をいつ開始するかを判定すること、および新しいMPDファイルをいつ取得／フェッチ／要求するかを判定することを含む、いくつかのさらなる判定を行うことができる。
【0044】
いくつかの例示的な実施態様では、MPDは、非周期的な情報をDASHクライアントまたはDASHアプリケーションにシグナリングするために、DASHイベントに関する情報をさらに含むことができる。イベントは、持続時間を有する特定のメディアプレゼンテーション時間から開始して、時間調整されてもよい。追加的または代替的に、イベント情報は、広告挿入キューなどのメディアプレゼンテーションの再生中の特定の時間に関連付けられたメディアプレーヤ用の制御メッセージを含むことができる。ストリーミング中に挿入され得るメディアは、広告サーバなどの別個のサーバから提供されてもよい。メディア表現とは別にMPDによってイベントをシグナリングすることに加えて、イベントは、1つまたはいくつかの選択されたアダプテーションセットのみ、またはすべての表現において、選択されたメディア表現内で帯域内多重化されてもよい。
【0045】
例示的なDASHシステム200が図2に示されている。DASHシステム200は、ネットワーク250によって接続された、1つまたは複数の集中型または分散型のコンテンツサーバ210および情報処理装置230を含んでもよい。DASHシステム（200）はまた、1つまたは複数の広告サーバ220などの1つまたは複数の補足コンテンツサーバを含むことができる。
【0046】
コンテンツサーバ210は、プライマリコンテンツ（例えば、メインプログラム）とそのMPDを情報処理装置230に提供してもよい。マニフェストファイルは、MPDジェネレータ214で生成され得る。プライマリコンテンツおよびマニフェストファイルは、同じサーバまたは異なるサーバによって提供され得る。
【0047】
情報処理装置230は、コンテンツサーバ210と直接通信するDASHクライアント232を含んでもよい。DASHクライアント232は、情報処理装置230のDASHアプリケーション234により制御され、MPDを要求および／または受信してもよいし、MPDに基づいてコンテンツサーバ210のHTTPサーバ212にプライマリコンテンツを要求して取得してもよい。MPDは、DASHクライアント232により処理されてもよい。さらに、DASHクライアント232は、DASHイベントに応じて、広告サーバ220から広告コンテンツを取得してもよく、または1つまたは複数の補足コンテンツサーバから他のコンテンツ（例えば、対話型コンテンツ）を取得してもよい。メインコンテンツや広告コンテンツは、DASHクライアント232やDASHアプリケーション234により処理され、情報処理装置230の表示デバイス236に表示出力され得る。表示デバイス236は、情報処理装置230と一体であってもよいし、情報処理装置の外部にあってもよい。さらに、DASHクライアント232は、1つまたは複数のタイムドメタデータトラックから他のイベント情報を抽出し、抽出したイベント情報をさらなる処理のためにDASHアプリケーション234に送信することができる。DASHアプリケーション234は、例えば、イベント情報に基づいて補足コンテンツを表示するように構成されてもよい。
【0048】
DASHクライアント232の例を図3Aに示す。例示的なDASHクライアント232は、DASHアクセスエンジン304、選択ロジック302、ならびにメディアエンジン306および308を含むことができる。DASHアクセスエンジン302は、例えば、ストリーミングメディアのMPDの一部または全部を取得し、動的に要求されるストリーミングメディアのセグメントデータを要求および取得し、ならびにMPD DASHイベントに従って補足メディア（広告）を要求するために、コンテンツサーバと通信するように構成することができる。選択ロジック304は、アダプテーションセットおよび表現の選択を含む、要求する次の1つまたは複数のセグメントを決定するように構成することができる。そのような決定は、例えば、ユーザ命令、ならびにネットワーク帯域幅およびスループットなどの他のリアルタイム情報によって決定することができる。メディアエンジン306は、DASHアクセスエンジン302によって受信されたセグメントデータを、メディアセグメントのフォーマット（例えば、MPEG）およびメディアセグメントのタイミングに従って処理してメインメディア出力を生成するように構成することができる。メディアエンジン308は、例えば、メインメディア出力に挿入することができる補足メディア出力（広告など）を生成するために、DASHアクセスエンジン302からのタイムドDASHイベントに関連付けられたメディアコンテンツを処理するように構成することができる。
【0049】
図3Bは、本開示の一実施形態による、DASHおよび／またはCMAFイベントを処理するための他の例示的なDASH／CMAFクライアントアーキテクチャを示す。DASH／CMAFクライアント（またはDASH／CMAFプレーヤ）は、アプリケーション（390）と通信し、（i）MPDイベント、（ii）インバンドイベント、および（iii）タイムドメタデータイベントを含む様々なタイプのイベントを処理するように構成され得る。
【0050】
マニフェストパーサ（305）はマニフェスト（例えば、MPD）を構文解析する。マニフェストは、例えば、コンテンツサーバ（110、210）により提供される。マニフェストパーサ（305）は、タイムドメタデータトラックに埋め込まれたMPDイベント、インバンドイベントおよびタイムドメタデータイベントに関するイベント情報を抽出する。抽出されたイベント情報は、DASH論理（310）（例えば、DASHプレーヤの制御、選択、および発見的論理）に提供され得る。DASH論理（310）は、イベント情報に基づいて、マニフェスト内でシグナリングされたイベントスキームをアプリケーション（390）に通知することができる。
【0051】
イベント情報は、異なるイベントストリームを区別するためのイベントスキーム情報を含むことができる。アプリケーション（390）は、イベント方式情報を使用して関心のあるイベント方式にサブスクライブすることができる。アプリケーション（390）は、1つまたは複数のサブスクリプション用APIを介してサブスクライブされたスキームの各々の所望の発信モードをさらに示すことができる。例えば、アプリケーション（390）は、関心のある1つまたは複数のイベントスキームおよび任意の所望の対応発信モードを識別するサブスクリプション要求をDASHクライアントに送信することができる。
【0052】
アプリケーション（390）が、1つまたは複数のタイムドメタデータトラックの一部として配信される1つまたは複数のイベントスキームにサブスクライブする場合、インバンドイベントおよび「moof」パーサ（325）は、1つまたは複数のタイムドメタデータトラックをタイムドメタデータトラックパーサ（330）にストリーミングすることができる。例えば、インバンドイベントおよび「moof」パーサ（325）は、ムービーフラグメントボックス（「moof」）を構文解析し、続いて、DASH論理（310）からの制御情報に基づいてタイムドメタデータトラックを構文解析する。
【0053】
タイムドメタデータトラックパーサ（330）は、タイムドメタデータトラックに埋め込まれたイベントメッセージを抽出することができる。抽出されたイベントメッセージは、イベントバッファ（335）（例えば、イベントバッファ）に格納され得る。シンクロナイザ／ディスパッチャモジュール（340）（例えば、イベントおよびタイムドメタデータのシンクロナイザおよびディスパッチャ）は、サブスクライブされたイベントをアプリケーション（390）に発信（または送信）することができる。
【0054】
MPDに記述されたMPDイベントは、マニフェストパーサ（305）によって構文解析されて、バッファ（335）に記憶され得る。例えばマニフェストパーサ（305）は、MPDの各イベントストリーム要素を構文解析し、かつ各イベントストリーム要素に記述された各イベントを構文解析する。MPD内でシグナリングされた各イベントについて、プレゼンテーション時間およびイベント持続時間などのイベント情報は、イベントに関連付けられたバッファ（335）に記憶され得る。
【0055】
インバンドイベントおよび「moof」パーサ（325）は、メディアセグメントを構文解析して、インバンドイベントメッセージを抽出することができる。任意のこのような識別されたインバンドイベントおよび関連するプレゼンテーション時間および持続時間は、バッファ（335）に記憶され得る。
【0056】
したがって、バッファ（335）は、その中にMPDイベント、インバンドイベントおよび／またはタイムドメタデータイベントを記憶することができる。バッファ（335）は、例えば、先入れ先出し（FIFO）バッファであり得る。バッファ（335）は、メディアバッファ（350）に対応して管理され得る。例えば、メディアセグメントがメディアバッファ（350）内に存在する限り、そのメディアセグメントに対応する任意のイベントまたはタイムドメタデータはバッファ（335）に記憶され得る。
【0057】
DASHアクセス・アプリケーション・プログラミング・インターフェース（API）（315）は、HTTPプロトコルスタック（320）を介したメディアコンテンツや各種メタデータを含むコンテンツストリーム（あるいはデータフロー）のフェッチや受信を管理することができる。DASHアクセスAPI（315）は、受信したコンテンツストリームを異なるデータフローに分離することができる。インバンドイベントおよびmoofパーサに提供されるデータフローは、メディアセグメント、1つまたは複数のタイムドメタデータトラック、およびメディアセグメントに含まれるインバンドイベントシグナリングを含むことができる。一実施形態では、マニフェストパーサ（305）に提供されるデータフローはMPDを含むことができる。
【0058】
DASHアクセスAPI（315）は、マニフェストをマニフェストパーサ（305）に転送することができる。イベントを記述することに加えて、マニフェストは、アプリケーション（390）ならびにインバンドイベントおよび「moof」パーサ（325）と通信することができるDASH論理（310）にメディアセグメントに関する情報を提供することもできる。アプリケーション（390）を、DASHクライアントによって処理されるメディアコンテンツに関連付けられ得る。アプリケーション（390）と、DASH論理（310）と、マニフェストパーサ（305）と、DASHアクセスAPI（315）との間でやりとりされる制御・同期信号は、マニフェストに記述されたメディアセグメントに関する情報に基づいて、HTTPスタック（320）からのメディアセグメントのフェッチを制御することができる。
【0059】
インバンドイベントおよびmoofパーサ（325）は、メディアデータフローを構文解析して、メディアコンテンツ、タイムドメタデータトラック内のタイムドメタデータ、およびメディアセグメント内の任意のシグナリングされたインバンドイベントを含むメディアセグメントにすることができる。メディアコンテンツを含むメディアセグメントは、ファイルフォーマットパーサ（345）によって構文解析されて、メディアバッファ（350）に記憶され得る。
【0060】
バッファ（335）に記憶されたイベントは、シンクロナイザ／ディスパッチャ（340）が、イベント／メタデータAPIを介してアプリケーションに関連する利用可能なイベント（または関心のあるイベント）をアプリケーションに通信することを可能にすることができる。利用可能なイベント（例えば、MPDイベント、インバンドイベントまたはタイムドメタデータイベント）を処理し、かつシンクロナイザ／ディスパッチャ（340）に通知することによって特定のイベントまたはタイムドメタデータにサブスクライブするように、アプリケーションが構成され得る。アプリケーションに関連しないがその代わりにDASHクライアント自体に関連するバッファ（335）に記憶された任意のイベントは、さらなる処理のためにシンクロナイザ／ディスパッチャ（340）によってDASH論理（310）に転送され得る。
【0061】
特定のイベントにサブスクライブするアプリケーション（390）に応じて、シンクロナイザ／ディスパッチャ（340）は、アプリケーションがサブスクライブしているイベントスキームに対応するアプリケーションのイベントインスタンス（またはタイムドメタデータのサンプル）と通信することができる。イベントインスタンスは、（例えば、特定のイベントスキームについて）サブスクリプション要求によって示される発信モードまたはデフォルトの発信モードに従って通信され得る。例えば受信時発信モードでは、イベントインスタンスは、バッファ（335）での受信時にアプリケーション（390）に送信されてもよい。一方、開始時発信モードでは、イベントインスタンスは、例えばメディアデコーダ（355）からのタイミング信号と同期して、それらの関連付けられたプレゼンテーション時間にアプリケーション（390）に送信されてもよい。
【0062】
いくつかの実施態様では、メディアセグメントエンジン（MSE）（395）は、ファイルフォーマットパーサ（345）、メディアバッファ（350）、およびメディアデコーダ（355）を含むことができる。MSEは、メディアセグメントを受信し、デコーディングされたメディア出力を生成することができる。
【0063】
代替MPDの構成と処理
いくつかの実施態様では、マルチレートコンテンツのストリーミングを可能にし、2つのタイムライン間、すなわち、メイン・メディア・プレゼンテーション用のメインMPDイベントのための1つのタイムラインと、代替メディアプレゼンテーション用の代替MPDイベントのための他のタイムラインとの間で、メディアプレゼンテーションを切り替えるために代替MPDイベントを利用する。クライアントの後処理モデルを提供する方法には、いくつかの問題／問題があり得る。
いくつかの実施態様では、マルチレートコンテンツのストリーミングを可能にし、2つのタイムライン間、すなわち、メイン・メディア・プレゼンテーション用のメインMPDイベントのための1つのタイムラインと、代替メディアプレゼンテーション用の代替MPDイベントのための他のタイムラインとの間で、メディアプレゼンテーションを切り替えるために代替MPDイベントを利用する。クライアントの後処理モデルを提供する方法には、いくつかの問題／問題があり得る。
【0064】
例えば、DASH設計を用いたいくつかの実施態様は、以下の問題／課題、すなわち、オンデマンドコンテンツのためのリターンポイントがないこと、切り替え時間がイベント開始時間と同一であるという仮定、および／または、広告（ad）持続時間がイベント持続時間と同じであるという仮定、のうちの1つまたは複数を含み得る。
【0065】
様々な実施形態は、代替MPDイベントを提供、ディスパッチ、および後処理するためのDASHクライアントの処理モデルを説明する。いくつかの実施態様は、例えば、プレロールおよび／またはミッドロール広告を効率的かつ効果的に可能にするなど、代替MPDイベントを正しく処理する異なるシグナリングおよび改善された後処理モデルを提供する。
【0066】
様々な実施形態はまた、本開示に記載された1つまたは複数の問題に対処することができる。例えば、いくつかの実施形態は、オンデマンドコンテンツのリターンポイントを追加すること、プレロールおよびミッドロールを正確に達成するためにこれらの2つのパラメータ（切り替え時間およびイベント開始時間）を分離すること、および／またはこれら2つのパラメータ（広告持続時間およびイベント持続時間）を分離して、広告への切り替えおよび広告からの切り替えを正しく達成すること、のうちの1つまたは複数によってメディアストリーミングフィールドを改善することができる。
【0067】
図3Bを参照すると、クライアントは、マニフェスト内の記述されたアドレスに基づいてメディアセグメントを要求することができる。MSEバッファは、ファイルフォーマットパーサ、メディアバッファ、およびメディアデコーダのパイプラインを含むことができる。
【0068】
図4は、コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのメディア・ストリーミング・デバイス（例えば、HTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイス）による例示的な方法400の例示的なフロー図を示す。方法400は、DASHメディア・ストリーミング・デバイスによりコンテンツサーバから代替MPDのためのマニフェストを受信するステップ410、マニフェストを構文解析して代替MPDのための一組のパラメータを抽出するステップ420であって、一組のパラメータは、イベントストリーム（例えば、DASHイベントストリーム）の値、プレゼンテーション時間、または持続時間のうちの少なくとも1つを含み、プレゼンテーション時間は、メイン・メディア・プレゼンテーションのタイムラインにおいて代替メディアプレゼンテーションが開始するオフセットを示し、持続時間は、代替メディアプレゼンテーションがアクティブである期間を示す、ステップ420、プレゼンテーション時間に基づいてメイン・メディア・プレゼンテーションから代替メディアプレゼンテーションに切り替えるステップ430、および／または代替メディアプレゼンテーションの終了に応じて、DASHイベントストリームの値に従ってリターンポイントにおいてメイン・メディア・プレゼンテーションを再生するステップ440、の一部または全部を含んでもよい。
【0069】
様々な実施形態において、本開示は、メディアストリーミングコンテンツサーバがメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを構成するための方法を提供する。メディアストリーミングコンテンツサーバは、構成された代替MPDをメディア・ストリーミング・デバイスに送信することができ、方法400の一部またはすべて、または本開示に記載された任意の他の実施態様を実行するようにメディア・ストリーミング・デバイスを構成することができる。
【0070】
いくつかの実施態様では、プレゼンテーション時間は実際の切り替え時間とは異なるパラメータである。
【0071】
いくつかの実施態様では、持続時間は、代替メディアプレゼンテーションの実際の持続時間とは異なるパラメータである。
【0072】
いくつかの実施態様では、イベントストリームの値は、タイムシフトを示す第1の値を含み、および／または、メイン・メディア・プレゼンテーションが、メイン・メディア・プレゼンテーションが代替メディアプレゼンテーションに切り替えられた時点まで再生される。
【0073】
いくつかの実施態様では、イベントストリームの値は、置換を示す第2の値を含み、および／または動的を示す第1のMPDタイプに応じて、メイン・メディア・プレゼンテーションは、メイン・メディア・プレゼンテーションのライブエッジまで再生され、および／または静的を示す第2のMPDタイプに応じて、メイン・メディア・プレゼンテーションは、メイン・メディア・プレゼンテーションが代替メディアプレゼンテーションに切り替えられた時点に、代替メディアプレゼンテーションの実際の持続時間を加えたときまで再生される。
【0074】
いくつかの実施態様では、代替MPDは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）イベント処理に従って処理およびディスパッチされる。
【0075】
いくつかの実施態様では、代替メディアプレゼンテーションを終了するステップは、以下のうちの少なくとも1つ、すなわち、持続時間の終了時に代替メディアプレゼンテーションの再生を終了することを含むか、または、停止命令を受信したときに代替メディアプレゼンテーションの再生を停止する。
【0076】
いくつかの実施態様では、動的を示すMPDタイプに応じて、置換を示す値に応じて、メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、メイン・メディア・プレゼンテーションのライブエッジであり、および／またはタイムシフトを示す値に応じて、メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、実際の切り替え時間またはそれ以降に利用可能な最も早いセグメントである。
【0077】
いくつかの実施態様では、静的を示すMPDタイプに応じて、置換を示す値に応じて、メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、実際の切り替え時間と代替メディアプレゼンテーションの実際の持続時間との合計であり、および／またはタイムシフトを示す値に応じて、メイン・メディア・プレゼンテーションを再生するためのリターンポイントは実際の切り替え時間である。
【0078】
メディアセグメント要求用のパラメータ化記述子は、MPDデータ構造と呼ばれることがある。非限定的な例として、「UrlQueryInfo」と呼ばれるMPD内のそのようなタイプのインスタンス化されたデータ構造は、メディアセグメントの静的および動的パラメータ化メカニズムを提供するために使用される様々な属性または記述子を含むことができる。いくつかのさらなる例示的な実施態様では、そのような静的および動的パラメータ化機構は、メディアセグメントの要求に加えて他のタイプのHTTP要求に拡張することができる。拡張データ構造タイプの例示的なシンタックスを指定することができ、様々なタイプ（または属性または値）のパラメータ化をシグナリングおよび規定するための対応するデータ構造を含むMPDをインスタンス化するために使用することができる。
【0079】
表1は、代替MPDシグナリングのための修正されたおよび／または改善されたセマンティクスの非限定的な例を示す。
【0080】
【表1】
【0081】
表2は、代替MPDシグナリングのための修正および／または改善されたセマンティクスの他の非限定的な例を示す。
【0082】
【表2】
【0083】
様々な実施形態は、代替MPDイベントのためのクライアント後処理モデルを含む。いくつかの実施態様では、代替MPDイベントは、一般的なDASHイベント処理に従って処理およびディスパッチされる。いくつかの実施態様では、代替MPDイベントは、ディスパッチされた後に後処理されてもよい。表3は、イベントの後処理手順が依拠し得るパラメータの非限定的な例を示す。
【0084】
【表3】
【0085】
本開示では、「urn：mpeg：dash：event：alternative：2022」などの統一リソース名（URN）が、URN／URLスキームの所有者によって定義される任意の部分文字列と共に定義され、使用され得る。
【0086】
クライアントの代替MPD切り替えイベント後処理手順の1つの非限定的な例では、方法は、以下のステップのうちの1つまたは複数を含むことができる。
【0087】
ステップ1について、メディアストリーミングクライアント（またはメディア・ストリーミング・デバイス、またはクライアント）は、メッセージ内の代替MPD統一リソースロケータ（URL）がその以前に再生されたリスト（PPL）内にあるかどうかをチェックする。
【0088】
ステップ2について、クライアントが代替MPD URLがそのPPL内にあると判定した場合、クライアントはそれ以上何もアクションを起こさない可能性があり、および／または、クライアントが代替MPD URLがそのPPL内にないと判定した場合、クライアントは、以下のステップのうちの1つまたは複数を続行することができる。
【0089】
ステップ3の場合、クライアントは代替MPDをダウンロードする。
【0090】
ステップ4について、クライアントは、以下のケースのうちの1つを決定し実行する。
【0091】
ステップ4－1の場合、クライアントが現在の再生時間≧プレゼンテーション時間であると判定すると、直ちに次のステップ（ステップ5）に進む。いくつかの実施態様では、現在の再生時間は、メイン・メディア・プレゼンテーションの現在の時間を示すことができ、および／または、presentation＿timeは、代替メディアプレゼンテーションに切り替える「ターゲット」時間を示すことができる。
【0092】
ステップ4－2について、クライアントが、現在の再生時間＜プレゼンテーション時刻であると決定したとき、クライアントは、ステップ4－1を満たす現在の再生時間＝プレゼンテーション時刻までメイン・メディア・プレゼンテーションの再生を継続し、その後に、次のステップに進む。
【0093】
ステップ5について、クライアントは、switch＿time＝現在の再生時間を設定する。そして、メイン・メディア・プレゼンテーションが終了しない限り、メイン・メディア・プレゼンテーションから代替メディアプレゼンテーションに再生を切り替える。メイン・メディア・プレゼンテーションが終了すると、それは、そのswitch＿timeおよびPLLバッファを停止およびクリアする。
【0094】
ステップ6について、クライアントは、メインMPD URLおよびswitch＿timeを格納する。
【0095】
ステップ7では、クライアントはそのPPLにメッセージを追加する。
【0096】
ステップ8では、クライアントは、代替メディアプレゼンテーションの最後に、メインMPD URLからメインMPDをダウンロードする。代替メディアプレゼンテーションは、持続時間の終わりに代替メディアプレゼンテーションの再生を終了すること（すなわち、代替メディアプレゼンテーションはその構成された持続時間を完了すること）、または停止命令を受信したときに代替メディアプレゼンテーションの再生を停止すること（すなわち、ユーザまたはコンテンツサーバは、代替メディアプレゼンテーションがその構成された持続時間を完了する前に代替メディアプレゼンテーションの再生を終了すること）のうちの少なくとも一方によって終了され得る。
【0097】
ステップ9について、クライアントは、値および／またはMPDタイプに応じて以下のステップのうちの1つに基づいてメイン・メディア・プレゼンテーションを再生し続ける。
【0098】
ステップ9－1について、MPD＠type＝’動的’に応じて、値＝’置換’の場合、再生時間位置はライブエッジからのものであり、および／または値＝’タイムシフト’の場合、再生時間位置は、switch＿time以降に利用可能な最も早いセグメントからのものである。いくつかの実施態様では、再生がメイン・メディア・プレゼンテーションに戻されるときにswitch＿timeにメディアセグメントが利用可能であることを保証するために、＠timeshiftBufferDepthは、最大代替メディアプレゼンテーション持続時間以上の値に設定されてもよい。
【0099】
ステップ9－2について、MPD＠type＝’static’に応じて、値＝’replace’の場合、再生時間位置は（switch＿time＋代替メディアプレゼンテーションの持続時間）からであり、および／または値＝’タイムシフト’の場合、再生時間位置はswitch＿timeからのものである。
【0100】
いくつかの実施態様では、DASHクライアントは、メインMPDの最初の解析から開始してそのURL、switch＿time、およびPPL値をクリアし、再生全体の間それらを維持し続ける。
【0101】
いくつかの実施態様では、イベントプレゼンテーション＿時間および持続時間は、メディアプレゼンテーションが代替メディアプレゼンテーションに切り替えられるメディアプレゼンテーションのアクティブ時間間隔を示す。切り替えの正確な時間（switch＿time）は、プレーヤがアクティブ時間間隔にどのように到達するかに依存し、例えば、その開始時間までの線形再生によって、またはその途中の時点へのランダムアクセスによって決まる。
【0102】
様々な実施形態は、代替MPDイベントを処理するための方法を含むことができ、イベント開始時間およびイベント持続時間は、切り替え時間および代替広告持続時間として異なるパラメータとして維持される。イベント開始時間および持続時間は、プレーヤによるコンテンツの線形再生またはコンテンツへのランダムアクセスに応じてスイッチング時間が変化し得る間にスイッチング時間が発生し得る時間間隔を規定し、スイッチバックの時間は、イベント持続時間ではなく代替広告持続時間によって規定される。処理モデルでは、これらの値は維持され、別々に扱われ、代替MPDイベントセマンティクスのシグナリングは、記載された処理モデルを考慮して定義される。
【0103】
上述された技法は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つまたは複数のコンピュータ可読媒体に物理的に記憶され得る。例えば、図5は、開示されている主題の特定の実施形態を実施するのに適したコンピュータシステム（500）を示す。
【0104】
コンピュータソフトウェアは、1つまたは複数のコンピュータ中央処理装置（CPU）、グラフィック処理装置（GPU）などによって直接実行され得る、または解釈、マイクロコード実行などを介して実行され得る命令を含むコードを作成するために、アセンブリ、コンパイル、リンクなどの機構を受けることができる任意の適切な機械コードまたはコンピュータ言語を使用してコーディングされ得る。
【0105】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはその構成要素で実行され得る。
【0106】
コンピュータシステム（500）に関して図5に示されている構成要素は、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関する限定を示唆することを意図されていない。また、構成要素の構成は、コンピュータシステム（500）の例示的な実施形態に示されている構成要素のいずれか1つまたは組合せに関する依存性または要件を有するものとして解釈されるべきではない。
【0107】
コンピュータシステム（500）は、特定のヒューマンインターフェース入力デバイスを含み得る。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（音声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）など、1人または複数のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスを用いることで、音声（発話、音楽、周囲音など）、画像（スキャン画像、静止画像カメラから取得した写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、人間による意識的な入力に必ずしも直接関連しないなんらかの媒体を獲得することもできる。
【0108】
入力ヒューマンインターフェースデバイスは、キーボード（501）、マウス（502）、トラックパッド（503）、タッチスクリーン（510）、データグローブ（図示せず）、ジョイスティック（505）、マイク（506）、スキャナ（507）、カメラ（508）のうちの1つまたは複数を含んでもよい（それぞれ1つのみが図示されている）。
【0109】
コンピュータシステム（500）はまた、特定のヒューマンインターフェース出力デバイスを含み得る。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および嗅覚／味覚を通じて、1人または複数の人間のユーザの感覚を刺激している可能性がある。そのようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（510）、データグローブ（図示せず）、またはジョイスティック（505）による触覚フィードバックを含み得るが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、音声出力デバイス（スピーカ（509）、ヘッドホン（図示せず）など）、視覚的出力デバイス（それぞれにタッチスクリーン入力機能の有無にかかわらず、それぞれ触覚フィードバック機能の有無にかかわらず、ステレオグラフィック出力、仮想現実の眼鏡（図示せず）、ホログラフィックディスプレイおよびスモークタンク（図示せず）などの手段により、2次元の視覚的出力または3次元以上の出力を出力できるものもある、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン（510）など）、およびプリンタ（図示せず）を含み得る。
【0110】
コンピュータシステム（500）には、人間がアクセスできる記憶デバイスと、CD／DVDを含むCD／DVD ROM／RW（520）などの光学メディア（521）、サムドライブ（522）、リムーバブルハードドライブまたはソリッド・ステート・ドライブ（523）、テープおよびフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの専用のROM／ASIC／PLDベースのデバイスなどの関連媒体も含めることができる。
【0111】
ここで開示されている保護対象に関連して用いられている用語「コンピュータ可読媒体」が伝送媒体、搬送波またはその他一時的な信号を含まないことも当業者は当然理解する。
【0112】
コンピュータシステム（500）は、1つまたは複数の通信ネットワーク（555）に対するインターフェース（554）をさらに含むことができる。ネットワークは、例えば、無線、有線、光であってもよい。ネットワークはさらに、ローカル、ワイドエリア、メトロポリタン、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例には、イーサネットなどのローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、および地上波放送テレビを含む有線テレビまたは無線広域デジタルネットワーク、CAN busを含む車両用および産業用などが含まれる。特定のネットワークは、一般に、特定の汎用データポートまたは周辺バス（549）（例えば、コンピュータシステム（500）のUSBポートなど）に接続された外部ネットワークインターフェースアダプタを必要とし、他のものは一般に、以下に記載されるようにシステムバスへの接続によってコンピュータシステム（500）のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラネットワークインターフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム（500）は他のエンティティと通信できる。このような通信は、単方向、受信のみ（例えば、放送TV）、単方向送信のみ（例えば、CANbusから特定のCANbusデバイス）、または双方向、例えば、ローカルエリアデジタルネットワークまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムへの通信であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースの各々で使用され得る。
【0113】
前述のヒューマンインターフェースデバイス、ヒューマンアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム（500）のコア（540）に接続され得る。
【0114】
コア（540）は、1つまたは複数の中央処理装置（CPU）（541）、グラフィック処理装置（GPU）（542）、フィールドプログラマブルゲートエリア（FPGA）（543）の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ（544）、グラフィックアダプタ（550）などを含むことができる。このようなデバイスは、読出し専用メモリ（ROM）（545）、ランダムアクセスメモリ（546）、内部のユーザがアクセスできないハードドライブ、SSDなど（547）の内部大容量記憶装置と共に、システムバス（548）を介して接続されてもよい。いくつかのコンピュータシステムでは、システムバス（548）は、追加のCPU、GPUなどによる拡張が可能なように、1つまたは複数の物理プラグの形態でアクセス可能であり得る。周辺デバイスは、コアのシステムバス（548）に直接取り付けられ、または周辺バス（549）を介して取り付けられ得る。例では、スクリーン（510）は、グラフィックアダプタ（550）に接続され得る。周辺バス用のアーキテクチャには、PCI、USBなどが含まれる。
【0115】
CPU（541）、GPU（542）、FPGA（543）、およびアクセラレータ（544）は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行することができる。そのコンピュータコードは、ROM（545）またはRAM（546）に格納され得る。移行データはRAM（546）に格納され得るが、恒久的データは例えば内部大容量記憶装置（547）に格納され得る。1つまたは複数のCPU（541）、GPU（542）、大容量記憶装置（547）、ROM（545）、RAM（546）などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリデバイスに対する高速記憶および読み出しが可能になる。
【0116】
コンピュータ可読媒体には様々なコンピュータ実施動作を行うためのコンピュータコードを搭載することができる。メディアおよびコンピュータコードは本開示のために特別に設計および構成されたものであり得るし、コンピュータソフトウェア技術の当業者によく知られ、当業者が入手可能な種類のものであり得る。
【0117】
非限定的な例として、アーキテクチャ（500）、具体的にはコア（540）を有するコンピュータシステムは、プロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）が1つまたは複数の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行する結果として、機能を提供することができる。このようなコンピュータ可読媒体は、上で紹介したユーザがアクセス可能な大容量記憶装置、およびコア内部大容量記憶装置（547）やROM（545）などの非一時的な性質を持つコア（540）の特定の記憶装置に関連付けられた媒体であり得る。
【0118】
本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア（540）によって実行され得る。コンピュータ可読媒体は、特定のニーズに従って、1つまたは複数のメモリデバイスまたはチップを含み得る。ソフトウェアは、コア（540）、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM（546）に記憶されているデータ構造を定義すること、ソフトウェアで定義された処理に従ってそのようなデータ構造を変更することを含む、ここで説明する特定の処理または特定の処理の特定の部分を実行させることができる。これに加えて、またはこれの代わりとして、本出願で説明されている特定のプロセスまたは特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアと一緒に動作し得る回路（例えばアクセラレータ（544））における、配線された、または別の方法で具現化されたロジックの結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、論理を包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアとの任意の適切な組合せを包含する。
【0119】
本開示の実施形態および実施態様では、所望により、任意のステップおよび／または動作は、任意の量または順序で組み合わされるか、または配置されてもよい。ステップおよび／または動作の2つ以上を並列に実行してもよい。本開示の実施形態と実施態様とを個別に用いたり任意の順序で組み合わせたりしてもよい。さらに、方法（または実施形態）、クライアント、およびサーバの各々は、処理回路（例えば、1つまたは複数のプロセッサまたは1つまたは複数の集積回路）によって実施することができる。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に記憶されたプログラムを実行する。
【0120】
本開示はいくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換、および様々な代替的な均等物が存在する。したがって、当業者は、本明細書に明示的に示されていないかまたは記載されていないが、本開示の原理を具現化し、したがって本開示の趣旨および範囲内にある多数のシステムおよび方法を考案することができることが理解されよう。
【符号の説明】
【0121】
100 コンテンツ配信システム
110 コンテンツサーバ
120 情報処理装置
130 通信ネットワーク
200 DASHシステム
210 コンテンツサーバ
212 HTTPサーバ
214 MPDジェネレータ
220 広告サーバ
230 情報処理装置
232 DASHクライアント
234 DASHアプリケーション
236 表示デバイス
250 ネットワーク
302 DASHアクセスエンジン
304 選択ロジック
305 マニフェストパーサ
306 メディアエンジン
308 メディアエンジン
310 DASH論理
315 DASHアクセスAPI
320 HTTPプロトコルスタック
325 インバンドイベントおよび「moof」パーサ
330 タイムドメタデータトラックパーサ
335 イベントバッファ
340 シンクロナイザ／ディスパッチャ
345 ファイルフォーマットパーサ
350 メディアバッファ
355 メディアデコーダ
390 アプリケーション
400 方法
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 音声出力デバイススピーカ
510 タッチスクリーン
520 CD／DVD ROM／RW
521 光学メディア
522 サムドライブ
523 ソリッド・ステート・ドライブ
540 コア
541 中央処理装置（CPU）
542 グラフィック処理装置（GPU）
543 フィールドプログラマブルゲートエリア（FPGA）
544 アクセラレータ
545 読出し専用メモリ（ROM）
546 ランダムアクセスメモリ
547 大容量記憶装置
548 システムバス
549 周辺バス
550 グラフィックアダプタ
554 インターフェース
555 通信ネットワーク
110 コンテンツサーバ
120 情報処理装置
130 通信ネットワーク
200 DASHシステム
210 コンテンツサーバ
212 HTTPサーバ
214 MPDジェネレータ
220 広告サーバ
230 情報処理装置
232 DASHクライアント
234 DASHアプリケーション
236 表示デバイス
250 ネットワーク
302 DASHアクセスエンジン
304 選択ロジック
305 マニフェストパーサ
306 メディアエンジン
308 メディアエンジン
310 DASH論理
315 DASHアクセスAPI
320 HTTPプロトコルスタック
325 インバンドイベントおよび「moof」パーサ
330 タイムドメタデータトラックパーサ
335 イベントバッファ
340 シンクロナイザ／ディスパッチャ
345 ファイルフォーマットパーサ
350 メディアバッファ
355 メディアデコーダ
390 アプリケーション
400 方法
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 音声出力デバイススピーカ
510 タッチスクリーン
520 CD／DVD ROM／RW
521 光学メディア
522 サムドライブ
523 ソリッド・ステート・ドライブ
540 コア
541 中央処理装置（CPU）
542 グラフィック処理装置（GPU）
543 フィールドプログラマブルゲートエリア（FPGA）
544 アクセラレータ
545 読出し専用メモリ（ROM）
546 ランダムアクセスメモリ
547 大容量記憶装置
548 システムバス
549 周辺バス
550 グラフィックアダプタ
554 インターフェース
555 通信ネットワーク
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【手続補正書】
【提出日】2024-05-27
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
コンテンツサーバからのメインメディアプレゼンテーション記述（MPD）を用いて代替MPDを処理するためのHTTPを介した動的適応型ストリーミング（DASH）メディア・ストリーミング・デバイスが実行する方法であって、前記方法は、前記DASHメディア・ストリーミング・デバイスが前記コンテンツサーバから前記代替MPDのためのマニフェストを受信するステップと、
前記マニフェストを構文解析して前記代替MPDのための一組のパラメータを抽出するステップであって、前記一組のパラメータは、DASHイベントストリームの値、プレゼンテーション時間、または持続時間のうちの少なくとも1つを含み、前記プレゼンテーション時間は、メイン・メディア・プレゼンテーションのタイムラインにおいて代替メディアプレゼンテーションが開始するオフセットを示し、前記持続時間は、前記代替メディアプレゼンテーションがアクティブである期間を示す、ステップと、
前記プレゼンテーション時間に基づいてメイン・メディア・プレゼンテーションから前記代替メディアプレゼンテーションに切り替えるステップと、
前記代替メディアプレゼンテーションの終了に応じて、前記DASHイベントストリームの前記値に従ってリターンポイントにおいて前記メイン・メディア・プレゼンテーションを再生するステップと、
を含む、方法。
【請求項2】
前記プレゼンテーション時間は、実際の切り替え時間とは異なるパラメータである、請求項1に記載の方法。
【請求項3】
前記持続時間は、前記代替メディアプレゼンテーションの実際の持続時間とは異なるパラメータである、請求項1に記載の方法。
【請求項4】
前記DASHイベントストリームの前記値は、タイムシフトを示す第1の値を含み、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションが前記代替メディアプレゼンテーションに切り替えられる時点まで再生される、
請求項1に記載の方法。
【請求項5】
前記DASHイベントストリームの前記値は、置換を示す第2の値を含み、動的を示す第1のMPDタイプに応じて、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションのライブエッジまで再生され、
静的を示す第2のMPDタイプに応じて、前記メイン・メディア・プレゼンテーションは、前記メイン・メディア・プレゼンテーションが前記代替メディアプレゼンテーションに切り替えられた時点に、前記代替メディアプレゼンテーションの実際の持続時間を加えたときまで再生される、
請求項1に記載の方法。
【請求項6】
前記代替MPDは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）イベント処理に従って処理され、ディスパッチされる、請求項1に記載の方法。
【請求項7】
前記代替メディアプレゼンテーションを終了するステップは、前記持続時間の終わりに前記代替メディアプレゼンテーションの再生を終了するステップ、または
停止命令を受信したときに前記代替メディアプレゼンテーションの再生を停止するステップ、
のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項8】
前記動的を示す第1のMPDタイプの場合、置換を示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、前記メイン・メディア・プレゼンテーションのライブエッジであり、
タイムシフトを示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するための前記リターンポイントは、実際の切り替え時間またはそれ以降に利用可能な最も早いセグメントである、
請求項5に記載の方法。
【請求項9】
前記静的を示す第2のMPDタイプの場合、置換を示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するためのリターンポイントは、前記代替メディアプレゼンテーションの実際の切り替え時間と実際の持続時間との合計であり、
タイムシフトを示す前記値に応じて、前記メイン・メディア・プレゼンテーションを再生するための前記リターンポイントは、前記実際の切り替え時間である、
請求項5に記載の方法。
【請求項10】
請求項1～9のいずれか一項に記載の方法を行うように構成された、DASHメディア・ストリーミング・デバイス。
【請求項11】
コンピュータに、請求項1～9のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
【国際調査報告】