JP2023520757A - Ｈｔｔｐを介した動的適応ストリーミングのための方法および装置 - Google Patents

Abstract

本開示の態様は、メディアデータを受信するための方法、装置、および非一時的なコンピュータ可読記憶媒体を提供する。1つの装置は、ハイパーテキストトランスファープロトコルを介した動的適応ストリーミング（DASH）動作のための必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信する処理回路を含む。必須プロパティ記述子は、第1のセッションベースの記述（SBD）ファイルに関連付けられており、ユニフォームリソースロケータ（URL）の一部分が第1のSBDファイルに基づいて修正されることを示している。URLの部分は、第2のSBDファイルに基づいて生成されている。処理回路は、第1のSBDファイルに基づいてURLの部分を修正し、URLの修正部分に基づいてメディアデータを受信する。

Description

関連出願の相互参照
本出願は、2021年1月6日に出願された米国仮出願第63/134,518号「CASCADED SESSION-BASED DASH OPERATIONS」に対する優先権の利益を主張する、2021年9月23日に出願された米国特許出願第17/483,334号「METHODS AND APPARATUSES FOR DYNAMIC ADAPTIVE STREAMING OVER HTTP」に対する優先権の利益を主張する。先行出願の開示は、参照によりその全体が本明細書に組み込まれる。

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

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

ムービングピクチャエクスパーツグループ（moving picture expert group：MPEG）は、インターネットプロトコル（Internet Protocol：IP）ネットワークにわたってマルチメディアコンテンツをストリーミングするための規格を提供している。この規格は、ハイパーテキストトランスファープロトコルを介した動的適応ストリーミング（DASH）規格と呼ばれる。DASH規格は、セッションベースのDASH動作のための部分を含む。セッションベースのDASH動作において、メディアプレゼンテーションファイル（MPD）はすべてのクライアントに汎用であるが、クライアントはサイドファイルを取得することができ、これは、クライアントがMPDファイルをクライアントのセッションに固有にするための命令を提供することができる。サイドファイルは、セッションベースの記述（SBD）ファイルと呼ばれる。

本開示の態様は、メディアデータを受信するための装置を提供する。1つの装置は、ハイパーテキストトランスファープロトコルを介したセッションベースの動的適応ストリーミング（DASH）動作のための必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信する処理回路を含む。必須プロパティ記述子は、第1のセッションベースの記述（SBD）ファイルに関連付けられており、ユニフォームリソースロケータ（URL）の一部分が第1のSBDファイルに基づいて修正されることを示している。URLの部分は、第2のSBDファイルに基づいて生成されている。処理回路は、第1のSBDファイルに基づいてURLの部分を修正する。処理回路は、URLの修正部分に基づいてメディアデータを受信する。

一実施形態では、URLの部分は、URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つである。

一実施形態では、URLの複数の部分の各々について、必須プロパティ記述子は、URLのそれぞれの部分が第1のSBDファイルに基づいて修正されるべきか否かを示す、異なる属性を含む。

一実施形態では、処理回路は、URLの部分に対応する属性の1つに含まれる第2のSBDファイルの識別情報に基づいて、URLの部分を修正する。

一実施形態では、URLの部分は、URLの修正部分を生成するためのテンプレートとして使用される。

一実施形態では、必須プロパティ記述子は、第1のSBDファイルの識別情報を示す属性を含む。

一実施形態では、URLの修正部分は、第1のSBDファイルに含まれる第1のキー値ペアに基づいて生成され、URLの部分は、第2のSBDファイルに含まれる第2のキー値ペアに基づいて生成され、第1のキー値ペアと第2のキー値ペアの両方は同じキーを有する。

本開示の態様は、メディアデータを受信するための方法を提供する。方法は、装置によって実行されるステップの1つまたは組合せを含むことができる。1つの方法では、MPDファイルが受信される。MPDファイルは、セッションベースのDASH動作のための必須プロパティ記述子を含む。必須プロパティ記述子は、第1のSBDファイルに関連付けられており、URLの一部分が第1のSBDファイルに基づいて修正されることを示している。URLの部分は、第2のSBDファイルに基づいて生成されている。URLの部分は、第1のSBDファイルに基づいて修正される。メディアデータは、URLの修正部分に基づいて受信される。

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

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

本開示の一実施形態による例示的なハイパーテキストトランスファープロトコルを介した動的適応ストリーミング（DASH）システムを示す図である。 本開示の一実施形態による別の例示的なセッションベースのDASHシステムを示す図である。 本開示の一実施形態による例示的なDASHクライアントアーキテクチャを示す図である。 本開示の一実施形態による例示的なカスケードされたセッションベースのDASH動作を示す図である。 いくつかの実施形態によるプロセス例の概要を示すフローチャートである。 一実施形態によるコンピュータシステムの概略図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本開示の態様によれば、複数のSBDをMPDにリンクするために、セッションベースのDASHのための1つ以上の必須プロパティ記述子はMPDレベルで使用することができ、セッションベースのDASHのための各必須プロパティ記述子は、同様のまたは同じ必須プロパティ記述子属性を含む。なお、プレゼンテーション記述子は、必須プロパティ記述子または補足プロパティ記述子のいずれかであり得ることに留意されたい。必須プロパティについて、メディアプレゼンテーション作成者は、要素が他の必須プロパティ要素と同じ@idを共有しない限り、この記述子を含む親要素内の情報を適切に使用するには記述子の処理の成功が不可欠であると表現する。対照的に、補足プロパティでは、メディアプレゼンテーション作成者は、記述子が、処理を最適化するためにDASHクライアントによって使用され得る補足情報を含むことを表現する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

III．カスケードされたセッションベースのDASH動作
セッションベースのDASH動作は、セッションごと、および場合によりクライアントごとにMPDをカスタマイズするための重要なアプローチである。セッションベースのDASH動作では、DASHアクセスクライアント（203）などのDASHアクセスクライアントは、メディアセグメントなどのリソースを要求するために、コンテンツサーバ（202）などのサーバにURLを送信することができる。場合によっては、URLは、サーバに送信される前に、1つ以上のSBDファイルに基づいて修正することができる。しかしながら、いくつかの関連する例では、1つ以上のSBDファイルは、（1つまたは複数の）加法演算を使用することによってURLに適用されることのみが可能とされ得る。1つの関連する例では、1つ以上のSBDファイルの各々は、URLのクエリに新しい別個のコンテンツ部分を追加するためにのみ使用することができ、クエリの既存のコンテンツ部分を修正するためには使用することができない。たとえば、URLのクエリの既存のコンテンツ部分は、第1のSBDファイル内の1つ以上の第1のキー値ペアに基づいて生成される。次いで、第2のSBDファイルがURLのクエリに適用されると、1つ以上の第1のキー値ペアに基づいて生成されたクエリの既存のコンテンツ部分は、第2のSBDファイルに基づいて修正することができない。代わりに、第2のSBDファイル内の1つ以上の第2のキー値ペアは、URLのクエリの最後に追加される新しいコンテンツ部分を生成することのみが可能とされ得る。

本開示は、カスケードされたセッションベースのDASH動作を使用して、URLのクエリ（またはホストなどどの別の部分）の既存のコンテンツ部分を修正する方法を含む。カスケードされたセッションベースのDASH動作では、URLは、複数の段階で修正され得る。複数の段階のうちの1つでは、1つ以上のSBDファイルは、複数の段階のうちの1つよりも前の前段階で生成されたクエリの既存のコンテンツ部分を含むURL全体に適用することができる。

図4は、本開示の一実施形態による例示的なカスケードされたセッションベースのDASH動作を示す。図4において、URL1は、URL2をもたらすために第1のSBDファイルSBD1に基づいて修正することができる。たとえば、SBD1内の1つ以上の第1のキー値ペアは、URL2をもたらすためにURL1のクエリの最後に追加される第1のコンテンツ部分を生成するために使用することができる。次に、URL2は、URL3をもたらすために、第2のSBDファイルSBD2および第3のSBDファイルSBD3に基づいて修正することができる。なお、（SBD1から生成された第1のコンテンツ部分を含む）URL2全体は、SBD2およびSBD3に基づいて修正され得ることに留意されたい。一例では、SBD2およびSBD3をURL2に適用する順序は、記述子を含むMPDファイル内のSBD2およびSBD3に関連付けられた記述子の出現順序に基づいて決定することができる。たとえば、SBD2に関連付けられた必須プロパティ記述子が、これら2つの必須プロパティ記述子を含むMPDファイル内のSBD3に関連付けられた必須プロパティ記述子の前に出現する場合、SBD2は、SBD3の前にURLに適用することができる。

一実施形態では、URL3をもたらすために、SBD2内の1つ以上の第2のキー値ペアまたはSBD3内の1つ以上の第3のキー値ペアを使用して、SBD1内の1つ以上の第1のキー値ペアに基づいて生成された第1のコンテンツ部分を修正することができる。この実施形態では、第1のコンテンツ部分がSBD2に基づいて修正される場合、修正された第1のコンテンツ部分をSBD3に基づいてさらに修正することができず、またはその逆も同様である。

一実施形態では、URL3をもたらすために、SBD2内の1つ以上の第2のキー値ペアを使用して、SBD1内の1つ以上の第1のキー値ペアに基づいて生成された第1のコンテンツ部分を修正することができる。SBD3内の1つ以上の第3のキー値ペアは、URL2のクエリの修正された第1のコンテンツ部分の最後に追加される第2のコンテンツ部分を生成するために使用することができる。あるいは、SBD3内の1つ以上の第3のキー値ペアは、URL2のホスト部分、ポート部分、パス部分、またはフラグメント部分のうちの1つなど、URL2の別の部分を修正するために使用することができる。

一実施形態では、URL3をもたらすために、SBD3内の1つ以上の第3のキー値ペアを使用して、SBD1内の1つ以上の第1のキー値ペアに基づいて生成された第1のコンテンツ部分を修正することができる。SBD2内の1つ以上の第2のキー値ペアは、URL2のクエリの修正された第1のコンテンツ部分の最後に追加される第2のコンテンツ部分を生成するために使用することができる。あるいは、SBD2内の1つ以上の第2のキー値ペアは、URL2のホスト部分、ポート部分、パス部分、またはフラグメント部分のうちの1つなど、URL2の別の部分を修正するために使用することができる。

カスケードされたセッションベースのDASH動作を使用することによって、URLのクエリの修正処理は、加法演算を使用することによってSBD1、SBD2、およびSBD3のすべてがURL1のクエリに適用されるいくつかの関連する例とは異なり得る。すなわち、SBD1、SBD2、およびSBD3内のキー値ペアは、特定の順序でURL1のクエリの最後にそれぞれ追加される。関連する例では、SBD1の1つ以上の第1のキー値ペアが最初にURL1のクエリの最後に追加され、次いでSBD2の1つ以上の第2のキー値ペアが1つ以上の第1のキー値ペアの最後に追加され、最後にSBD3の1つ以上の第3のキー値ペアが1つ以上の第2のキー値ペアの最後に追加される。

図4では、URL3をもたらすために、2つのSBDファイル（SBD2およびSBD3）がURL2に適用される。別の実施形態では、1つのみのSBDファイル、または3つ以上のSBDファイルなど、任意の他の数のSBDファイルを、URL3をもたらすためにURL2に適用することができる。一実施形態では、2つ以上のSBDファイルがURL2に適用される場合、2つ以上のSBDファイルをURL2に適用する順序は、記述子を含むMPDファイル内の2つ以上のSBDファイルに関連付けられた記述子の出現順序に基づいて決定することができる。たとえば、3つのSBDファイル（たとえば、第1のSBDファイル、第2のSBDファイル、および第3のSBDファイル）がURL2に適用される場合、第1のSBDファイルに関連付けられた第1の必須プロパティ記述子は第2のSBDファイルに関連付けられた第2の必須プロパティ記述子よりも前に出現し、第2の必須プロパティ記述子は第3のSBDファイルに関連付けられた第3の必須プロパティ記述子よりも前に出現し、次いで第1のSBDファイルは、第3のSBDファイルの前にURL2に適用される第2のSBDファイルの前にURL2に適用される。

いくつかの実施形態では、URLは、ホスト部分、ポート部分、パス部分、パス部分、および／またはフラグメント部分を含むことができる。たとえば、典型的なURLは、URI=scheme:[//authority]path[?query][#fragment]として表すことができ、権限部分はauthority=[userinfo@]host[:port]として表すことができる。

本開示の態様によれば、カスケードされたセッションベースのDASH動作では、SBDファイルは、URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つ以上に適用することができる。

本開示の態様によれば、SBDファイルに関連付けられた必須プロパティ記述子は、カスケードされたセッションベースのDASH動作をシグナリングするために使用することができる。表1は、カスケードされたセッションベースのDASH動作をシグナリングするために使用される例示的な必須プロパティ記述子を示す。表1において、SBDファイル（たとえば、第1のSBDファイル）の識別情報を示すために、@idなどの識別属性を使用することができる。加えて、カスケードされたセッションベースのDASH動作をシグナリングするために、@cascade、@hostCascade、@portCascade、@pathCascade、または@fragmentCascadeのうちの1つなどのカスケード属性を使用することができる。たとえば、第1のカスケード値@cascadeが別のSBDファイル（たとえば、第2のSBDファイル）のインデント情報を表し、これを含む場合、すなわち第1のSBDファイルの@cascade＝第2のSBDファイルの@idである場合、第2のSBDファイルに基づいて生成されたURLのクエリ部分は、第1のSBDファイルに基づいて修正することができる。第2のSBDファイルに基づいて生成されたクエリ部分は、第1のSBDファイル内の第1のテンプレート属性@templateに示されるテンプレートの代わりに、変形例におけるテンプレートとして使用することができる。この場合、第2のSBDファイルをカスケード元SBDファイルと呼ぶことができ、第1のSBDファイルをカスケード先SBDファイルと呼ぶことができる。第1のカスケード属性@cascadeが存在しないか、または第1のSBDファイル内の第1のカスケード属性@cascadeの値と同一の識別情報を有するSBDファイルがない場合、第1のSBDファイルは、URLのクエリ部分に適用されない。

同様に、第2のカスケード属性@hostCascadeが別のSBDファイル（たとえば、第2のSBDファイル）のインデント情報を表し、これを含む場合、すなわち第1のSBDファイルの@hostCascade＝第2のSBDファイルの@idである場合、第2のSBDファイルに基づいて生成されたURLのホスト部分は、第1のSBDファイルに基づいて修正することができる。第2のSBDファイルに基づいて生成されたホスト部分は、第1のSBDファイル内の第2のテンプレート属性@hostTemplateに示されるテンプレートの代わりに、変形例におけるテンプレートとして使用することができる。第2のカスケード属性@hostCascadeが存在しないか、または第1のSBDファイル内の第2のカスケード属性@hostCascadeの値と同一の識別情報を有するSBDファイルがない場合、第1のSBDファイルは、URLのホスト部分に適用されない。

同様に、第3のカスケード属性@portCascadeが別のSBDファイル（たとえば、第2のSBDファイル）のインデント情報を表し、これを含む場合、すなわち第1のSBDファイルの@portCascade＝第2のSBDファイルの@idである場合、第2のSBDファイルに基づいて生成されたURLのポート部分は、第1のSBDファイルに基づいて修正することができる。第2のSBDファイルに基づいて生成されたポート部分は、第1のSBDファイル内の第3のテンプレート属性@portTemplateに示されるテンプレートの代わりに、変形例におけるテンプレートとして使用することができる。第3のカスケード属性@portCascadeが存在しないか、または第1のSBDファイル内の第3のカスケード属性@portCascadeの値と同一の識別情報を有するSBDファイルがない場合、第1のSBDファイルは、URLのポート部分に適用されない。

同様に、第4のカスケード属性@pathCascadeが別のSBDファイル（たとえば、第2のSBDファイル）のインデント情報を表し、これを含む場合、すなわち第1のSBDファイルの@pathCascade＝第2のSBDファイルの@idである場合、第2のSBDファイルに基づいて生成されたURLのパス部分は、第1のSBDファイルに基づいて修正することができる。第2のSBDファイルに基づいて生成されたパス部分は、第1のSBDファイル内の第4のテンプレート属性@pathTemplateに示されるテンプレートの代わりに、変形例におけるテンプレートとして使用することができる。第4のカスケード属性@pathCascadeが存在しないか、または第1のSBDファイル内の第4のカスケード属性@pathCascadeの値と同一の識別情報を有するSBDファイルがない場合、第1のSBDファイルは、URLのポート部分に適用されない。

同様に、第5のカスケード属性@fragmentCascadeが別のSBDファイル（たとえば、第2のSBDファイル）のインデント情報を表し、これを含む場合、すなわち第1のSBDファイルの@fragmentCascade＝第2のSBDファイルの@idである場合、第2のSBDファイルに基づいて生成されたURLのフラグメント部分は、第1のSBDファイルに基づいて修正することができる。第5のSBDファイルに基づいて生成されたフラグメント部分は、第1のSBDファイル内の第5のテンプレート属性@fragmentTemplateに示されるテンプレートの代わりに、変形例におけるテンプレートとして使用することができる。第5のカスケード属性@fragmentCascadeが存在しないか、または第1のSBDファイル内の第5のカスケード属性@fragmentCascadeの値と同一の識別情報を有するSBDファイルがない場合、第1のSBDファイルは、URLのフラグメント部分に適用されない。

本開示は、カスケードされたセッションベースのDASH動作のための方法を含む。方法では、カスケード元SBDファイルに基づいて生成されたURLの一部分（たとえば、クエリ部分）に、カスケード先SBDファイルを適用することができる。カスケード元SBDファイルに基づいて生成されたURLの部分は、カスケード先SBDファイルにおけるテンプレートとして使用することができる。カスケード元SBDの識別情報をカスケード先SBDに含めることができる。このように使用することにより、URLのクエリ部分または様々な部分に対して2つ以上のカスケードされたセッションベースのDASH動作を実行することができる。

IV．フローチャート
図5は、本開示の一実施形態によるプロセス（500）の概要を示すフローチャートを示す。様々な実施形態において、プロセス（500）は、DASHクライアント（102）の処理回路などの処理回路によって実行される。いくつかの実施形態では、プロセス（500）はソフトウェア命令で実施され、したがって、処理回路がソフトウェア指示を実行するときに処理回路がプロセス（500）を実行する。

プロセス（500）は、一般に（S510）で開始され、プロセス（500）は、セッションベースのDASH動作のための必須プロパティ記述子を含むMPDファイルを受信する。必須プロパティ記述子は、第1のSBDファイルに関連付けられており、URLの一部分が第1のSBDファイルに基づいて修正されることを示している。URLの部分は、第2のSBDファイルに基づいて生成されている。次に、プロセス（500）はステップ（S520）に進む。

ステップ（S520）において、プロセス（500）は、第1のSBDファイルに基づいてURLの部分を修正する。次に、プロセス（500）はステップ（S530）に進む。

ステップ（S530）において、プロセス（500）は、URLの修正部分に基づいてメディアデータを受信する。

次に、プロセス（500）は終了する。

一実施形態では、URLの部分は、URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つである。

一実施形態では、URLの複数の部分の各々について、必須プロパティ記述子は、URLのそれぞれの部分が第1のSBDファイルに基づいて修正されるべきか否かを示す、異なる属性を含む。

一実施形態では、プロセス（500）は、URLの部分に対応する属性の1つに含まれる第2のSBDファイルの識別情報に基づいて、URLの部分を修正する。

一実施形態では、URLの部分は、URLの修正部分を生成するためのテンプレートとして使用される。

一実施形態では、必須プロパティ記述子は、第1のSBDファイルの識別情報を示す属性を含む。

一実施形態では、URLの修正部分は、第1のSBDファイルに含まれる第1のキー値ペアに基づいて生成され、URLの部分は、第2のSBDファイルに含まれる第2のキー値ペアに基づいて生成され、第1のキー値ペアと第2のキー値ペアの両方は同じキーを有する。

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

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

命令は、たとえばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーミングデバイス、およびモノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはその構成要素上で実行され得る。

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

コンピュータシステム（600）は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、たとえば触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）を用いた1人以上の人間のユーザによる入力に応答し得る。ヒューマンインターフェースデバイスは、オーディオ（音声、音楽、環境音など）、画像（走査画像、写真画像は静止画像カメラから取得など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）などの、必ずしも人間による意識的な入力に直接関連しない特定の媒体を取り込むためにも使用され得る。

入力ヒューマンインターフェースデバイスは、キーボード（601）、マウス（602）、トラックパッド（603）、タッチスクリーン（610）、データグローブ（図示せず）、ジョイスティック（605）、マイクロフォン（606）、スキャナ（607）、およびカメラ（608）（それぞれの1つのみが示されている）のうちの1つ以上を含み得る。

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

コンピュータシステム（600）はまた、CD／DVDまたは同様の媒体（621）を伴うCD／DVD ROM／RW（620）を含む光学媒体、サムドライブ（622）、取り外し可能なハードドライブまたはソリッドステートドライブ（623）、テープおよびフロッピー（登録商標）ディスクなどのレガシー磁気媒体（図示せず）、ならびにセキュリティドングル（図示せず）などの専用のROM／ASIC／PLDベースのデバイスなど、人間がアクセス可能な記憶デバイスおよびこれに関連する媒体を含み得る。

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

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

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム（600）のコア（640）に接続され得る。

コア（640）は、1つ以上の中央処理ユニット（CPU）（641）、グラフィックス処理ユニット（GPU）（642）、フィールドプログラマブルゲートエリア（FPGA）の形態の専用プログラマブル処理ユニット（643）、特定のタスク用のハードウェアアクセラレータ（644）などを含むことができる。これらのデバイスは、読出し専用メモリ（ROM）（645）、ランダムアクセスメモリ（646）、内蔵されてユーザによる取扱いが不能なハードディスク、SSDなどの内部大容量ストレージ（647）とともに、システムバス（648）を通じて接続されてもよい。一部のコンピュータシステムでは、システムバス（648）は、追加のCPUおよびGPUなどによる拡張を可能にするために1つ以上の物理プラグの形式でアクセス可能であり得る。周辺デバイスは、コアのシステムバス（648）に直接取り付けることも、周辺バス（649）を介して取り付けることもできる。周辺バスのアーキテクチャは、PCIおよびUSBなどを含む。

CPU（641）、GPU（642）、FPGA（643）、およびアクセラレータ（644）は、組み合わせて前述のコンピュータコードを構成することができる特定の命令を実行することができる。このコンピュータコードは、ROM（645）またはRAM（646）に記憶され得る。RAM（646）には一時的なデータも記憶され得る一方、恒久的なデータは、たとえば内部大容量ストレージ（647）に記憶され得る。メモリデバイスのいずれかへの高速記憶および検索は、1つ以上のCPU（641）、GPU（642）、大容量ストレージ（647）、ROM（645）、およびRAM（646）などに密接に関連付けられ得るキャッシュメモリの使用によって可能になり得る。

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

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

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

100 DASHシステム
101 DASHサーバ
102 DASHクライアント
200 DASH動作アーキテクチャ
201 コンテンツ生成デバイス、HTTPプロトコルスタック
202 コンテンツサーバ
203 DASHアクセスクライアント
204 SBDクライアント
205 セッションコントローラ
206 セッションコントローラ
302 DASHアクセスAPI
303 インバンドイベントおよび「moof」パーサ
304 時限メタデータトラックパーサ
305 ファイルフォーマットパーサ
306 イベントおよび時限メタデータバッファ
307 メディアバッファ
308 シンクロナイザ／ディスパッチャモジュール
309 メディアデコーダ
310 マニフェストパーサ
311 DASH論理
312 アプリケーション
500 プロセス
600 コンピュータシステム
601 キーボード
602 マウス
603 トラックパッド
605 ジョイスティック
606 マイクロフォン
607 スキャナ
608 カメラ
609 オーディオ出力デバイススピーカ
610 視覚出力デバイススクリーン、タッチスクリーン
620 CD／DVD ROM／RW
621 CD／DVDまたは同様の媒体
622 サムドライブ
623 取り外し可能なハードドライブまたはソリッドステートドライブ
640 コア
641 中央処理ユニット（CPU）
642 グラフィックス処理ユニット（GPU）
643 専用プログラマブル処理ユニット
644 ハードウェアアクセラレータ
645 読出し専用メモリ（ROM）
646 ランダムアクセスメモリ
647 内部大容量ストレージ
648 システムバス
649 周辺バス
650 グラフィックアダプタ
654 ネットワークインターフェース
655 通信ネットワーク

Claims (20)

1. メディアデータを受信するための方法であって、
   ハイパーテキストトランスファープロトコルを介したセッションベースの動的適応ストリーミング（DASH）動作のための必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信するステップであって、前記必須プロパティ記述子は、第1のセッションベースの記述（SBD）ファイルに関連付けられ、ユニフォームリソースロケータ（URL）の一部分が前記第1のSBDファイルに基づいて修正されることを示しており、前記URLの前記部分は第2のSBDファイルに基づいて生成されている、ステップと、
   前記第1のSBDファイルに基づいて前記URLの前記部分を修正するステップと、
   前記URLの修正部分に基づいて前記メディアデータを受信するステップと
   を含む方法。
2. 前記URLの前記部分は、前記URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つである、請求項1に記載の方法。
3. 前記URLの複数の部分の各々について、前記必須プロパティ記述子は、前記URLのそれぞれの部分が前記第1のSBDファイルに基づいて修正されるべきか否かを示す、異なる属性を含む、請求項2に記載の方法。
4. 修正する前記ステップは、前記URLの前記部分に対応する前記属性の1つに含まれる前記第2のSBDファイルの識別情報に基づいて、前記URLの前記部分を修正するステップを含む、請求項3に記載の方法。
5. 前記URLの前記部分は、前記URLの前記修正部分を生成するためのテンプレートとして使用される、請求項1に記載の方法。
6. 前記必須プロパティ記述子は、前記第1のSBDファイルの識別情報を示す属性を含む、請求項1に記載の方法。
7. 前記URLの前記修正部分は、前記第1のSBDファイルに含まれる第1のキー値ペアに基づいて生成され、前記URLの前記部分は、前記第2のSBDファイルに含まれる第2のキー値ペアに基づいて生成され、前記第1のキー値ペアと前記第2のキー値ペアの両方は同じキーを有する、請求項1に記載の方法。
8. メディアデータを受信するための装置であって、
   ハイパーテキストトランスファープロトコルを介したセッションベースの動的適応ストリーミング（DASH）動作のための必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信することであって、前記必須プロパティ記述子は、第1のセッションベースの記述（SBD）ファイルに関連付けられ、ユニフォームリソースロケータ（URL）の一部分が前記第1のSBDファイルに基づいて修正されることを示しており、前記URLの前記部分は第2のSBDファイルに基づいて生成されている、ことと、
   前記第1のSBDファイルに基づいて前記URLの前記部分を修正することと、
   前記URLの修正部分に基づいて前記メディアデータを受信することと
   を行うように構成された処理回路を含む装置。
9. 前記URLの前記部分は、前記URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つである、請求項8に記載の装置。
10. 前記URLの複数の部分の各々について、前記必須プロパティ記述子は、前記URLのそれぞれの部分が前記第1のSBDファイルに基づいて修正されるべきか否かを示す、異なる属性を含む、請求項9に記載の装置。
11. 前記修正することは、前記URLの前記部分に対応する前記属性の1つに含まれる前記第2のSBDファイルの識別情報に基づいて、前記URLの前記部分を修正することを含む、請求項10に記載の装置。
12. 前記URLの前記部分は、前記URLの前記修正部分を生成するためのテンプレートとして使用される、請求項8に記載の装置。
13. 前記必須プロパティ記述子は、前記第1のSBDファイルの識別情報を示す属性を含む、請求項8に記載の装置。
14. 前記URLの前記修正部分は、前記第1のSBDファイルに含まれる第1のキー値ペアに基づいて生成され、前記URLの前記部分は、前記第2のSBDファイルに含まれる第2のキー値ペアに基づいて生成され、前記第1のキー値ペアと前記第2のキー値ペアの両方は同じキーを有する、請求項8に記載の装置。
15. 命令を記憶した非一時的なコンピュータ可読記憶媒体であって、
    前記命令は、メディアデータを受信するためのコンピュータによって実行されると、前記コンピュータに、
    ハイパーテキストトランスファープロトコルを介したセッションベースの動的適応ストリーミング（DASH）動作のための必須プロパティ記述子を含むメディアプレゼンテーション記述（MPD）ファイルを受信することであって、前記必須プロパティ記述子は、第1のセッションベースの記述（SBD）ファイルに関連付けられ、ユニフォームリソースロケータ（URL）の一部分が前記第1のSBDファイルに基づいて修正されることを示しており、前記URLの前記部分は第2のSBDファイルに基づいて生成されている、ことと、
    前記第1のSBDファイルに基づいて前記URLの前記部分を修正することと、
    前記URLの修正部分に基づいて前記メディアデータを受信することと
    を実行させる、非一時的なコンピュータ可読記憶媒体。
16. 前記URLの前記部分は、前記URLのホスト部分、ポート部分、パス部分、フラグメント部分、またはクエリ部分のうちの1つである、請求項15に記載の方法。
17. 前記URLの複数の部分の各々について、前記必須プロパティ記述子は、前記URLのそれぞれの部分が前記第1のSBDファイルに基づいて修正されるべきか否かを示す、異なる属性を含む、請求項16に記載の方法。
18. 前記修正することは、前記URLの前記部分に対応する前記属性の1つに含まれる前記第2のSBDファイルの識別情報に基づいて、前記URLの前記部分を修正することを含む、請求項17に記載の方法。
19. 前記URLの前記部分は、前記URLの前記修正部分を生成するためのテンプレートとして使用される、請求項18に記載の方法。
20. 前記必須プロパティ記述子は、前記第1のSBDファイルの識別情報を示す属性を含む、請求項8に記載の方法。

Images