JP7177285B2 - メディアデータを受信するための方法、装置、およびプログラム - Google Patents

Description

参照による組み込み
本出願は、2019年10月1日に出願された米国仮出願第62/908,964号「INTERACTIVE STORYLINE DASH STREAMING」に対する優先権の利益を主張する、2020年9月24日に出願された米国特許出願第17/031,314号「METHODS AND APPARATUSES FOR DYNAMIC ADAPTIVE STREAMING OVER HTTP」に対する優先権の利益を主張する。先行する出願の開示全体は、参照によりその全体が本明細書に組み込まれる。

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

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

MPEG（Moving Picture Expert Group）ハイパーテキスト転送プロトコルを介した動的適応ストリーミング（dynamic adaptive streaming over hypertext transfer protocol:DASH）は、IPネットワークを介してマルチメディアコンテンツをストリーミングするための規格を提供する。MPEG DASHでは、単一のマニフェストがストーリーマップの単一のストーリーラインを表すことができる。マニフェストを更新して、ストーリーラインを変更することができる。しかし、ストーリーマップは、アプリケーションによってマニフェストの外部に維持される必要がある。

本開示の態様は、メディアデータを受信するための装置を提供する。1つの装置は、ストーリーマップの複数の分岐を示すメディアプレゼンテーション記述（MPD）イベントを含むMPDファイルを受信する処理回路を含む。処理回路は、MPDイベントのアクティブ期間中にストーリーマップの複数の分岐のうちの1つのユーザの選択を受信する。ユーザが選択した分岐は、現在の期間に接続されている次の期間に対応する。処理回路は、サーバから、ユーザが選択した分岐に対応する次の期間のメディアデータを受信する。

一実施形態では、MPDイベントは、アクティブ期間の開始時間を含む。

一実施形態では、処理回路は、ユーザが選択した分岐を示す選択情報をサーバに送信する。

一実施形態では、選択情報は、ユーザが選択した分岐に対応する次の期間の期間識別情報（ID）を含む。

一実施形態では、処理回路は、MPDイベントに含まれるユニフォーム・リソース・ロケータ（URL）情報および期間IDに基づいて選択情報をコンテンツサーバに送信する。

一実施形態では、MPDファイルは、次の期間の期間情報を含むように更新される。

一実施形態では、処理回路は、MPDイベントによって示される複数の分岐のそれぞれについての期間の期間情報を記憶し、受信されたMPDファイルとユーザが選択した分岐とに基づいてローカルMPDファイルを生成する。

本開示の態様は、メディアデータを受信するための方法を提供する。1つの方法では、ストーリーマップの複数の分岐を示すメディアプレゼンテーション記述（MPD）イベントを含むMPDファイルが受信される。ストーリーマップの複数の分岐のうちの1つのユーザの選択は、MPDイベントのアクティブ期間中に受信される。ユーザが選択した分岐は、現在の期間に接続されている次の期間に対応する。ユーザが選択した分岐に対応する次の期間のメディアデータがサーバから受信される。

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

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

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

I．ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）およびメディアプレゼンテーション記述（MPD）
ハイパーテキスト転送プロトコルを介した動的適応ストリーミング（DASH）は、ウェブサーバ、コンテンツ配送ネットワーク（CDN）、様々なプロキシおよびキャッシュなどのハイパーテキスト転送プロトコル（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属性と、期間ごとのstart属性とを含むことができる。動的様式（例えば、ライブサービスに使用される）のメディアプレゼンテーションの場合、期間の開始属性、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ストリーミング
本開示は、ストーリーライン・イベントに関する実施形態を含み、DASHメディアストリーミングにおいて対話型のストーリーラインを伝達するための方法を提示する。ストリーミングサービスは、ストーリーの複数のストーリー分岐をユーザに提供することができる。ユーザは、複数のストーリー分岐のうちの1つを選択し、その選択をストリーミングサービスに戻すことができ、ストリーミングサービスは、ストーリーの選択された分岐を継続することができる。

対話型のストーリーラインでは、ストーリーラインの提示の特定の時点において、ユーザは、ストーリーマップによって提供される可能な分岐選択肢の中から選択を行うことができる。そして、ユーザの選択に応じてストーリーラインが変化する。対話型のストーリーラインの使用事例の一例は、2018年に公開されたNetflixのBlack Mirrorである。

DASH規格では、マニフェストを更新することができる。したがって、アプリケーションがユーザに選択肢を提供することができる単一の期間を有するマニフェストを作成することが可能である。一例では、選択は、期間の終わりまたは終わり近くに提供することができる。選択は、複数の異なるストーリー分岐をユーザに提供することができ、各分岐は期間に対応する。そして、ユーザは、複数のストーリー分岐のうちの1つを選択することができる。ユーザの選択に応じて、マニフェストは、ユーザの選択に対応するストーリーのコンテンツを担持する新たな期間で更新され得る。そのようなマニフェストは、動的マニフェストと呼ぶことができる。コンテンツはオンデマンドであるため、全ての期間要素はサーバに記憶され、ユーザの選択に従ってこれらの期間を次々に追加することによって動的マニフェストを作成することができる。しかしながら、この解決策では、ストーリーマップは提供されず、ユーザが戻って別の選択を行うことを決定した場合、サーバは、所望の点にナビゲートし、別のマニフェストを作成しなければならない。ストーリーを提示するクライアントシステムは、ストーリーのストーリーマップのビューを有していない。

本開示は、マニフェストとともにストーリーマップを提供する実施形態を提示する。そのため、ユーザが選択を行うと、クライアントシステムはストーリーマップを維持し、ストーリーラインの異なる分岐をナビゲートすることができる。

図1は、本開示の一実施形態による例示的なDASHシステム（100）を示している。DASHシステム（100）では、DASHサーバ（101）（例えば、コンテンツサーバ）からDASHクライアント（102）にMPDファイルが送られる。DASHクライアント（102）は、MPDファイルに基づいて、DASHサーバ（101）からメディアセグメントを受信することができる。MPDファイルは、ユーザがユーザインターフェース（103）を介して現在の期間の次の関心期間を選択するための選択肢を提供することができる。一例では、次の関心期間の選択は、コールバック関数を使用してDASHサーバ（101）に送り返すことができる。DASHサーバ（101）は、MPDを更新し、次の注目期間に対応するメディアコンテンツをDASHクライアント（102）に送ることができる。

一実施形態では、DASHサーバ（101）は、初期MPDおよびMPD更新ならびにメディアセグメントをDASHクライアントに提供する。他の実施形態では、初期MPD、MPD更新、および／またはメディアセグメントは、異なるサーバによって提供することができる。DASHクライアント（102）がMPD更新の一部としてストーリーライン・イベントを受信するときはいつでも、DASHクライアント（102）は、ユーザインターフェース（103）を介してストーリーライン・イベントをユーザに提供することができる。次いで、ユーザインターフェース（103）は、DASHクライアント（102）に、関心のあるストーリー分岐のユーザの選択を通知し、DASHクライアント（102）は、DASHサーバ（101）がそれに応じてMPDを更新できるように、DASHサーバ（101）にユーザの選択を提供することができる。

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

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

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

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

時限メタデータトラックパーサー（204）は、時限メタデータトラックに埋め込まれたイベントメッセージを抽出することができる。抽出されたイベントメッセージは、イベントおよび時限メタデータバッファ（206）に記憶され得る。同期装置／ディスパッチャモジュール（208）（例えば、イベントおよび時限メタデータ同期装置およびディスパッチャ）は、配信を受けるイベントをアプリケーション（212）にディスパッチ（または送信）することができる。

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

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

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

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

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

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

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

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

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

図3は、本開示の一実施形態によるストーリーの例示的なストーリーマップを示す。ストーリーマップにおいて、ストーリーは、期間P0から始まる。期間P0の終わりに、ストーリーマップは、ストーリーが3つの分岐P1、P2、およびP3を有することを示す選択点S0を提供する。期間P1の終わりに、ストーリーマップは、ストーリーが2つの分岐P4およびP5を有することを示す選択点S1を提供する。ストーリーP6およびP7の残りの部分は、様々な分岐の合流において生じる。

なお、各選択点における選択肢の数は、2以上とすることができる。各分岐の持続時間は、必ずしも互いに等しくない。分岐の一部または全部は、ある瞬間にマージすることができ、マージされた分岐は、異なる持続時間を有することができる。さらに、ストーリーは、1つまたは複数の終点を有することができる。

本開示の態様によれば、MPDストーリーライン・イベントは、ストーリーマップ内の1つまたは複数の選択点を示すMPDイベントとすることができる。MPDイベントのイベント方式は、例えば「urn:mpeg:dash:manifest-storyline-event:2020」のようなschemeIdUriにより識別することができる。MPDファイルでは、1期間につき1つのEventStream要素のみが許容され、したがって、1つのEventStream要素のみで搬送されるイベントは、それらの方式属性に同じURIを使用する必要がある（例えば、＠schemeIdUri）。また、EventStreamにおけるこれらのイベントのサブ方式属性（例えば、＠value）は、DASHクライアント（102）では無視することができる。すなわち、EventStreamのイベントには、サブ方式は定義されていない。

例示的なMPDイベント要素を表1に示す。表1において、属性＠presentationTimeなどの開始時間情報は、MPDイベントの開始時間を示し、属性＠durationなどの持続時間情報は、MPDイベントの持続時間を示す。開始時間および持続時間の間、ユーザは選択を行うことができる。また、MPDイベント要素には、クライアントシステム（102）がリクエスト（例えば、HTTP GET要求）を行うためのURLを提供する属性＠callbackUrl等のURL情報が含まれる。クライアントシステム（102）は、ユーザの選択に基づいてURLにクエリを追加することができる。例えば、クエリは、「nextPeriod＝id」とすることができ、idは、ユーザインターフェース（103）を介してユーザによって選択された期間識別情報（ID）（例えば、＠id）値である。MPDイベント要素には、属性＠replaceなどの置換情報が含まれる。属性＠replaceが「真」に設定されている場合、MPDイベントは、このセッションにおける全ての以前のイベントの更新であり、接続マップ（またはストーリーマップ）は、以前の接続マップを置き換える。MPDイベントは、接続マップを指定する接続要素を含む。接続要素は、接続マップ内の単純なリンクのセットを含むことができる。例えば、1つのリンクは、図3に示されるストーリーマップにおけるP0からP1への接続とすることができ、別のリンクは、P0からP2への接続またはP0からP3への接続とすることができる。

表2は、例示的な接続要素を示す。例示的な接続要素では、第1の期間から1つまたは複数の第2の期間への1つまたは複数のリンクを示すことができる。例えば、リンクは、属性＠fromおよび属性＠toによって示すことができる。属性＠fromは、リンクを開始する期間を示す。属性＠toは、リンクが接続可能な1つまたは複数の期間を示す。属性＠fromおよび＠toの値は、期間IDとすることができる。属性＠toは、それぞれが異なるリンクに対応する1つ以上の期間IDを含むことができることに留意されたい。また、属性＠fromのデフォルト値は、イベントの親期間の期間IDとすることができる。例えば、図3に示す例示的なストーリーマップにおける期間P0におけるストーリーラインのイベントの接続要素は、＜Connection to＝"1 2 3"＞または＜Connection from＝"0" to＝"1 2 3"＞によって表すことができる。この例では、P0＠id＝"0"、P1＠id＝"1"、P2＠id＝"2"、P3＠id＝"3"とする。

本開示の態様によれば、1つまたは複数の接続要素を1つのストーリーライン・イベントに含めることができる。複数の接続要素は、現在のセッションの接続マップの一部または全体を提供することができる。しかしながら、現在の期間要素の終わりまたはその近くの接続マップの部分のみが、イベントの持続時間中の選択のためにアクティブであることに留意されたい。例えば、図3に示すストーリーマップ全体を表3に表すことができる。この例では、Pi＠id＝"i"とする。現在の期間がP1である場合、イベントの持続時間中、接続要素＜Connection from＝"1" to＝"4 5"＞のみがアクティブである。したがって、ユーザは、次の期間としてP4またはP5を選択することができる。

本開示の態様によれば、マニフェスト（例えば、MPD）は、ユーザの選択に基づいて更新することができる。ユーザの選択は、帯域外方式またはコールバック関数を使用してDASHサーバ（101）に提供することができる。帯域外方式は、DASH規格に基づかない方式とすることができる。このコールバック関数により、DASHクライアント（102）は、所与のURLに対してHTTP GETリクエストを発行することができる。例えば、ユーザが選択を行った後に、DASHクライアント（102）は、MPDイベント要素のコールバック属性（例えば、＠callbackUrl）によって示されるURLアドレスに対してHTTP GETリクエストを発行することができる。選択された期間IDは、要求のクエリパラメータに含めることができる。表4は、例示的なコールバック関数を示す。

本開示では、解析してアプリケーション／ユーザインターフェースに渡すのが簡単なMPDイベントを使用して選択肢を提供することができる。また、今後の選択肢、部分ストーリーマップ、またはストーリーマップ全体を設けることもでき、ストーリーマップを更新することもできる。ストーリーマップが、他の選択点によって選択点までDASHクライアント（102）に配送される場合、DASHクライアント（102）は、一度に一つの選択しか行うことができず、ストーリーマップ全体を有することができない。ストーリーマップは、各イベントにおいて（例えば、過去および将来の接続を含めることによって）更新され得る。イベントは、ユーザが選択を行うことができる開始時間および持続時間（例えば、イベントアクティブ期間）を提供することができる。ユーザが選択を行わない場合、提示はデフォルトの分岐ストーリーラインで継続することができる。イベントアクティブ期間は、次の期間への遷移の前に設定することができるため、クライアントシステム（102）は、連続再生のために次の期間のコンテンツをバッファリングする時間を有することができる。クライアントシステム（102）は、ストーリーマップならびに全ての期間の期間情報を記憶することができ、再生のための対話型のローカルMPDを構築することができることに留意されたい。

本開示は、対話型のストーリーラインのストリーミングコンテンツを配送するための方法を提示する。ストーリーのタイムライン内のある瞬間に複数の選択肢をユーザに提供することができる。ユーザは、提供された選択肢の中から選択して、ストーリーの方向を変更することができる。MPDイベントを使用して、期間ごとに複数の選択肢を伝達することができる。MPDイベントは、現在の期間から次の期間へ実際に遷移する前に起動することができる。MPDイベントは、クライアントシステム（102）が選択された次の期間をバッファリングし、中断または再バッファリングなしにコンテンツを再生するための持続時間を有することができる。ストーリーマップにおける選択点は、MPDイベントごとに1以上設けることができるし、ストーリーマップ全体を任意のMPDイベントで設けることもできる。ストーリーマップの一部または全体は、各MPDイベントまたは一部のMPDイベントによって更新され得る。MPDイベントはまた、クライアントシステム（102）がユーザの選択を返送するためのURLを提供することができる。MPDは、ユーザが選択した次の期間を加算することで、各期間の最後に更新することができる。DASHクライアント（102）は、ストーリーマップを徐々に、またはストーリーマップが完全に提供されている場合には一段階で構築することができる。DASHクライアント（102）はまた、対応する期間を記憶することができ、したがって、MPDのためにDASHサーバ（101）に連絡する必要なく、対話型ストーリーライン全体を構築し、MPD更新をローカルに製造することができる。DASHサーバ（101）は、DASHクライアント（102）が対話型ストーリーを再生している間にのみ、メディアコンテンツをストリーミングすることができる。

III．フローチャート
図4は、本開示の実施形態による処理（400）を概説するフローチャートを示す。様々な実施形態において、処理（400）は、DASHクライアント（102）の処理回路などの処理回路によって実行される。いくつかの実施形態では、処理（400）はソフトウェア命令で実装され、したがって、処理回路がソフトウェア命令を実行すると、処理回路は処理（400）を実行する。処理（400）は、当該処理（400）が、ストーリーマップの複数の分岐を示すMPDイベントを含むMPDファイルを受信すること（S410）から開始される。そして、処理（400）は、ステップ（S420）に進む。

ステップ（S420）において、処理（400）は、情報処理装置の処理回路から、MPDイベントのアクティブ期間中にストーリーマップの複数の分岐のうちの1つのユーザの選択を受信する。ユーザが選択した分岐は、現在の期間に接続されている次の期間に対応する。そして、処理（400）は、ステップ（S430）に進む。

ステップ（S430）において、処理（400）は、サーバから、ユーザが選択した分岐に対応する次の期間のメディアデータを受信する。そして、処理（400）は終了する。

一実施形態では、MPDイベントは、アクティブ期間の開始時間を含む。

一実施形態では、処理（400）は、ユーザが選択した分岐を示す選択情報をサーバに送信する。

一実施形態では、選択情報は、ユーザが選択した分岐に対応する次の期間の期間IDを含む。

一実施形態では、処理（400）は、MPDイベントに含まれるURL情報および期間IDに基づいて選択情報をコンテンツサーバに送信する。

一実施形態では、MPDファイルは、次の期間の期間情報を含むように更新される。

一実施形態において、処理（400）は、MPDイベントによって示される複数の分岐のそれぞれについての期間の期間情報を記憶し、受信されたMPDファイルおよびユーザが選択した分岐に基づいてローカルMPDファイルを生成する。

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

コンピュータソフトウェアは、任意の適切な機械コードまたはコンピュータ言語を使用してコード化でき、アセンブリ、コンパイル、リンク、または同様のメカニズムの対象となり、1つまたは複数のコンピュータ中央処理装置（CPU）、グラフィック処理装置（GPU）などによる直接、または解釈、マイクロコードの実行などを通じて実行できる命令を含むコードを作成する。

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

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

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

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

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

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

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

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

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

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

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

コンピュータ可読媒体は、様々なコンピュータ実施操作を実行するためのコンピュータコードをその上に有することができる。メディアおよびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、またはそれらは、コンピュータソフトウェア技術の当業者に周知であり利用可能な種類のものであり得る。

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

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

100 DASHシステム
101 DASHサーバ
102 DASHクライアント
103 ユーザインターフェース
201 HTTPスタック
202 DASHアクセスAPI
203 インバンドイベントおよび「moof」パーサー
204 時限メタデータトラックパーサー
205 ファイルフォーマットパーサー
206 イベントおよび時限メタデータバッファ
207 メディアバッファ
208 同期装置／ディスパッチャモジュール
209 メディアデコーダ
210 マニフェストパーサー
211 DASHロジック
212 アプリケーション
400 処理
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 スピーカ
510 タッチスクリーン
520 CD／DVD ROM／RW
521 光学メディア
522 サムドライブ
523 SSD
540 コア
541 CPU
542 GPU
543 FPGA
544 特定のタスクのハードウェアアクセラレータ
545 ROM
546 RAM
547 内部大容量記憶装置
548 システムバス
549 周辺バス
550 グラフィックスアダプタ
554 ネットワークインターフェース
555 通信ネットワーク

Claims (9)

1. メディアデータを受信するための方法であって、
   ストーリーマップの複数の分岐を示すメディアプレゼンテーション記述（MPD）イベントを含むMPDファイルを受信するステップと、
   情報処理装置の処理回路により、前記MPDイベントのアクティブ期間中に前記ストーリーマップの前記複数の分岐のうちの1つのユーザの選択を受信するステップであって、前記ユーザが選択した分岐が、現在の期間に接続される次の期間に対応する、ステップと、
   サーバから、前記ユーザが選択した分岐に対応する前記次の期間のメディアデータを受信するステップと、
   を含む方法。
2. 前記MPDイベントは、前記アクティブ期間の開始時間を含む、請求項1に記載の方法。
3. 前記ユーザが選択した分岐を示す選択情報を前記サーバに送信するステップ
   をさらに含む、請求項1または2に記載の方法。
4. 前記選択情報は、前記ユーザが選択した分岐に対応する前記次の期間の期間識別情報（ID）を含む、請求項3に記載の方法。
5. 送信する前記ステップは、
   前記MPDイベントに含まれるユニフォーム・リソース・ロケータ（URL）情報および前記期間IDに基づいて前記選択情報を前記サーバに送信するステップ
   をさらに含む、請求項4に記載の方法。
6. 前記MPDファイルが、前記次の期間の期間情報を含むように更新される、請求項1から5のいずれか一項に記載の方法。
7. 前記MPDイベントによって示される前記複数の分岐のそれぞれについての期間の期間情報を記憶するステップと、
   前記受信したMPDファイルと前記ユーザが選択した分岐とに基づいてローカルMPDファイルを生成するステップと、
   をさらに含む、請求項1から6のいずれか一項に記載の方法。
8. 請求項1から7のいずれか一項に記載の方法を実行するように構成された装置。
9. コンピュータに請求項1から7のいずれか一項に記載の方法を実行させるプログラム。

Images