JP7378616B2 - Ｄａｓｈコンテンツのインタラクティブ再生のための用途を意図したインタラクティブな選択情報 - Google Patents

Description

関連出願の相互参照
本出願は、2020年6月23日に出願された米国仮特許出願第63／042，946号明細書に対する優先権を主張する、2021年4月28日に出願された米国特許出願第17／242，863号明細書に対する優先権を主張し、その内容は、参照によりその全体が本明細書に明示的に組み込まれる。

本開示は、インタラクティブ再生のためのHTTPを介した動的適応ストリーミング（DASH）イベントに関する。

MPEG DASHでは、1つのマニフェストが1つのストーリーラインのみを表現してもよく、たとえストーリーラインを変更するためにマニフェストを更新することが可能であっても、ストーリーマップは、アプリケーションによってマニフェストの外部に維持される必要がある。

ストーリーマップ内の接続がメディアプレゼンテーション記述（MPD）イベントを使用して配信された場合、ストーリーラインは、プレゼンテーションの再生後の特定の瞬間に選択されたユーザ決定に基づいてプレゼンテーションが継続するようにユーザ選択に変更することができる。

DASHでは、マニフェストが単一の期間で更新されるべきであった場合、その期間の近くで、またはその期間の終わりに、アプリケーションは、それに応じてストーリーを実行するために新たな期間でマニフェストを更新することを決定するためにユーザ選択を要求し、その場合、すべてのコンテンツがオンデマンドであり得、すべての期間要素がリモートサーバに記憶され得るため、たとえユーザ選択に基づいて期間を順次追加することによって動的マニフェストが作成されたとしても、マニフェストを更新するためにすべての期間の終わりにコールバックが行われ得るという技術的問題がある。これは、ユーザ選択がより早く行われた場合に発生した可能性がある、未使用のバッファリングに対するレイテンシなどのネットワークパラメータに基づいて、また少なくともそれぞれの選択時にユーザに対する視覚的ガイダンスの欠如によって妨げられるユーザ選択の実用性に関して、技術的に問題となり得る。

1つまたは複数の異なる技術的問題に対処するために、本開示は、解決された要素に様々な動作を適用するオプションを提供しながら、ネットワークオーバーヘッドおよびサーバ計算オーバーヘッドを低減するための技術的解決策を提供し、これらの動作を使用する際に、ストーリーライン映像の実用性および技術規定の一部を改善する。

コンピュータプログラムコードを記憶するように構成されたメモリと、コンピュータプログラムコードにアクセスし、コンピュータプログラムコードによって命令されるように動作するように構成された1つまたは複数のプロセッサと、を備える方法および装置が含まれる。コンピュータプログラムコードは、少なくとも1つのプロセッサに、メディアプレゼンテーション記述（MPD）イベント、およびクライアントにストリーミングされるビデオコンテンツのメディアセグメントを提供させるように構成された提供コードと、少なくとも1つのプロセッサに、MPDイベントに基づいており、複数の選択肢および選択肢の各々に対するインタラクティブデータを含むユーザインターフェースを提供するようにクライアントを制御させるように構成された制御コードと、少なくとも1つのプロセッサに、ユーザインターフェースを介した選択肢からの少なくとも1つの選択に基づいてMPDデータを更新させるように構成された更新コードと、を含み、選択肢の各々は、ビデオコンテンツの複数のストーリーラインの複数の期間のうちの異なる期間をそれぞれ示し、クライアントにユーザインターフェースを提供するように制御することは、複数の期間のうちの異なる期間の前にある少なくとも1つの他の期間のストーリーラインの再生が少なくとも完了する前にユーザインターフェースを提供することを含む。

例示的な実施形態によれば、MPDイベントを提供することは、ビデオコンテンツの1つの他の期間、複数の期間のうちの異なる期間、および少なくとも1つの後の期間を識別するストーリーマップをクライアントに提供することを含み、ストーリーマップは、ビデオコンテンツの少なくとも1つの後の期間の前にストリーミングされるようにスケジュールされた複数の期間のうちの異なる期間の前に、1つの他の期間がストリーミングされるようにスケジュールされていることを示す。

例示的な実施形態によれば、1つの他の期間、複数の期間のうちの異なる期間、および少なくとも1つの後の期間のうちの少なくとも1つは、1つの他の期間、複数の期間のうちの異なる期間、および少なくとも1つの後の期間のうちの少なくとも1つの他の期間とは異なる期間を含む。

例示的な実施形態によれば、ユーザインターフェースを提供するようにクライアントを制御することは、ストーリーマップの少なくとも一部を表示するようにユーザインターフェースを制御することを含み、ストーリーマップの一部は、1つの他の期間の表示および複数の期間のうちの異なる期間の表示を含む。

例示的な実施形態によれば、ユーザインターフェースを提供するようにクライアントを制御することは、1つの他の期間の表示と複数の期間のうちの異なる期間の表示との間の時点で少なくとも1つの選択の位置を識別するようにユーザインターフェースを制御することを含む。

例示的な実施形態によれば、ストーリーマップの少なくとも一部を表示するようにユーザインターフェースを制御することは、接続マップに基づいてストーリーマップの少なくとも一部を表示することを含み、接続マップは、1つの他の期間、複数の期間のうちの異なる期間、および少なくとも1つの後の期間の各々を含むリストを含み、接続マップは、1つの他の期間から複数の期間のうちの異なる期間の各々への各接続のための第1のそれぞれの識別子をさらに含み、接続マップは、複数の期間のうちの異なる期間のうちの少なくとも1つから少なくとも1つの後の期間への少なくとも1つの接続のための第2のそれぞれの識別子をさらに含む。

例示的な実施形態によれば、ユーザインターフェースを提供するようにクライアントを制御することは、ストーリーマップの全体を表示するようにユーザインターフェースを制御することを含み、ストーリーマップの全体は、1つの他の期間の表示、複数の期間のうちの異なる期間の表示、および少なくとも1つの後の期間の表示を含む。

例示的な実施形態によれば、ユーザインターフェースを提供するようにクライアントを制御することは、1つの他の期間の表示と複数の期間のうちの異なる期間の表示との間の時点で少なくとも1つの選択の位置を識別するようにユーザインターフェースを制御することを含み、ユーザインターフェースを提供するようにクライアントを制御することは、複数の期間のうちの異なる期間の表示のうちの少なくとも1つと少なくとも1つの後の期間の表示との間の時点で別の選択の別の位置を識別するようにユーザインターフェースを制御することをさらに含む。

例示的な実施形態によれば、ストーリーマップの全体を表示するようにユーザインターフェースを制御することは、接続マップに基づいてストーリーマップの全体を表示することを含み、接続マップは、1つの他の期間、複数の期間のうちの異なる期間、および少なくとも1つの後の期間の各々を含むリストを含み、接続マップは、1つの他の期間から複数の期間のうちの異なる期間の各々への各接続のための第1のそれぞれの識別子をさらに含み、接続マップは、複数の期間のうちの異なる期間のうちの少なくとも1つから少なくとも1つの後の期間への少なくとも1つの接続のための第2のそれぞれの識別子をさらに含む。

例示的な実施形態によれば、クライアントは、HTTPを介した動的適応ストリーミング（DASH）クライアントである。

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

実施形態による簡略化された概略図である。 実施形態による簡略化された概略図である。 実施形態によるデコーダに関する簡略ブロック図である。 実施形態によるエンコーダに関する簡略ブロック図である。 実施形態による簡略ブロック図である。 実施形態による簡略図である。 実施形態による簡略化されたフローチャートである。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による簡略図である。 実施形態による概略図である。

以下で説明する提案された特徴は、別々に使用されてもよいし、任意の順序で組み合わされてもよい。さらに、実施形態は、処理回路（例えば、1つまたは複数のプロセッサまたは1つまたは複数の集積回路）によって実施されてもよい。一例では、1つまたは複数のプロセッサは、非一時的コンピュータ可読媒体に格納されたプログラムを実行する。

図1は、本開示の一実施形態による通信システム100の簡略ブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102、103を含んでよい。データの一方向送信のために、第1の端末103は、ネットワーク105を介して他の端末102に送信するためにローカル位置でビデオデータを符号化してもよい。第2の端末102は、ネットワーク105から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、復元されたビデオデータを表示してもよい。一方向データ送信は、メディアサービング用途などで一般的であることがある。

図1は、例えばビデオ会議中に発生する可能性がある符号化されたビデオの双方向送信をサポートするために提供される端末101と104の第2のペアを示す。データの双方向送信のために、各端末101および104は、ネットワーク105を介して他の端末に送信するために、ローカル位置で取り込んだビデオデータを符号化してもよい。各端末101および104は、もう一方の端末によって送信された符号化された映像データを受信してもよく、符号化されたデータを復号してもよく、かつ回復された映像データをローカルの表示装置に表示してもよい。

図1では、端末101、102、103、および104は、サーバ、パソコン、およびスマートフォンとして示されてもよいが、本開示の原理はそのように限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、および／または専用のビデオ会議機器を伴う用途を見出す。ネットワーク105は、例えば有線および／または無線通信ネットワークを含む、端末101、102、103および104間で、符号化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回路交換および／またはパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークには、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび／またはインターネットが含まれる。本考察の目的のために、ネットワーク105のアーキテクチャおよびトポロジは、本明細書で以下に説明されない限り、本開示の動作にとって重要ではない場合がある。

図2は、開示される主題のための用途の一例として、ストリーミング環境におけるビデオエンコーダおよびビデオデコーダの配置を示す。開示される主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタルメディアへの圧縮ビデオの記憶などを含む他のビデオ対応アプリケーションに等しく適用可能であり得る。

ストリーミングシステムは、例えば非圧縮ビデオサンプルストリーム213を作成するビデオソース201、例えばデジタルカメラを含み得るキャプチャサブシステム203を含むことができる。そのサンプルストリーム213は、符号化されたビデオビットストリームと比較して高いデータ量として強調されてよく、カメラ201に結合されたエンコーダ202によって処理することができる。エンコーダ202は、以下でより詳細に説明するように、開示される主題の態様を可能にするか、または実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。符号化されたビデオビットストリーム204は、サンプルストリームと比較してより低いデータ量として強調されてよく、将来の使用のためにストリーミングサーバ205に記憶することができる。1つまたは複数のストリーミングクライアント212および207は、ストリーミングサーバ205にアクセスして、符号化されたビデオビットストリーム204のコピー208および206を取得することができる。クライアント212は、符号化されたビデオビットストリーム208の着信コピーを復号し、ディスプレイ209または他のレンダリングデバイス（図示せず）上にレンダリングすることができる発信ビデオサンプルストリーム210を形成するビデオデコーダ211を含むことができる。一部のストリーミングシステムでは、ビデオビットストリーム204、206および208は、特定のビデオ符号化／圧縮規格に従ってエンコードすることができる。これらの規格の例は、上記で言及されており、本明細書でさらに説明される。

図3は、本発明の一実施形態によるビデオデコーダ300の機能ブロック図であり得る。

受信機302は、デコーダ300によって復号されるべき1つまたは複数のコーデックビデオシーケンスを受信してよく、同じまたは別の実施形態では、一度に1つの符号化されたビデオシーケンスを受信してよく、この場合、各符号化されたビデオシーケンスの復号は、他の符号化されたビデオシーケンスから独立している。符号化されたビデオシーケンスは、チャネル301から受信されてよく、チャネルは、符号化されたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信機302は、それぞれの使用エンティティ（描かれていない）に転送され得る他のデータ、例えば符号化されたオーディオデータおよび／または補助データストリームとともに、符号化されたビデオデータを受信してもよい。受信機302は、符号化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ303が、受信機302とエントロピーデコーダ／パーサ304（以降、「パーサ」）との間に結合されてよい。受信機302が十分な帯域幅と制御性を持つ記憶／転送デバイスから、またはアイソクロナスネットワークからデータを受信している場合、バッファ303は必要ないか、または小さくてよい。インターネットなどのベストエフォートパケットネットワークで使用する場合、バッファ303が必要とされる場合があり、比較的大きくすることができ、有利には適応サイズとすることができる。

ビデオデコーダ300は、エントロピー符号化されたビデオシーケンスからシンボル313を再構築するためのパーサ304を含んでもよい。これらのシンボルのカテゴリには、デコーダ300の動作を管理するために使用される情報、および場合によっては、デコーダの不可欠な部分ではないが、それに結合することができるディスプレイ312などのレンダリングデバイスを制御するための情報が含まれる。レンダリングデバイス（複数可）の制御情報は、補足拡張情報（SEIメッセージ）またはビデオユーザビリティ情報パラメータセットの小部分（図示せず）の形式であり得る。パーサ304は、受信した符号化されたビデオシーケンスを解析／エントロピー復号してもよい。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術または規格に従うことができ、可変長符号化、ハフマン符号化、文脈依存性を伴う、または伴わない算術符号化などを含む、当業者によく知られた様々な原理に従うことができる。パーサ304は、符号化されたビデオシーケンスから、そのグループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのサブグループパラメータのセットを抽出することができる。サブグループは、画像のグループ（GOP）、画像、タイル、スライス、マクロブロック、符号化ユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを含むことができる。エントロピーデコーダ／パーサはまた、変換係数、量子化パラメータ値、動きベクトルなどの符号化されたビデオシーケンス情報から抽出することができる。

パーサ304は、シンボル313を作成するために、バッファ303から受信したビデオシーケンスに対してエントロピー復号／解析動作を実行することができる。パーサ304は、符号化されたデータを受信し、特定のシンボル313を選択的に復号してもよい。さらに、パーサ304は、特定のシンボル313が、動き補償予測ユニット306、スケーラ／逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311に提供されるべきかどうかを判定してもよい。

シンボル313の再構築には、符号化されたビデオ画像またはその一部のタイプ（インター画像およびイントラ画像、インターブロックおよびイントラブロックなど）、ならびにその他の要因に応じて、複数の異なるユニットを関与させることができる。どのユニットがどのように関与しているかは、パーサ304によって、符号化されたビデオシーケンスから解析されたサブグループ制御情報によって管理することができる。パーサ304と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。

すでに言及した機能ブロックのほかに、デコーダ300は、以下で説明するように、いくつかの機能ユニットに概念的に再分割することができる。商業的な制約の下で動作する実際の実装形態では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合させることができる。しかしながら、開示された主題を説明するために、以下の機能ユニットへの概念的な細分化が適切である。

第1のユニットは、スケーラ／逆変換ユニット305である。スケーラ／逆変換ユニット305は、量子化された変換係数、ならびに使用する変換、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報をパーサ304からシンボル（複数可）313として受け取る。スケーラ／逆変換ユニット305はサンプル値を含むブロックを出力でき、これをアグリゲータ310に入力することができる。

一部のケースでは、スケーラ／逆変換305の出力サンプルは、イントラ符号化されたブロックに関係する場合があり、つまり、以前に再構築された画像からの予測情報は使用していないが、現在の画像の以前に再構築された部分からの予測情報を使用できるブロックに関係する場合がある。そのような予測情報は、イントラ画像予測ユニット307によって提供することができる。一部のケースでは、イントラ画像予測ユニット307は、現在の（部分的に再構築された）画像309からフェッチされた周囲のすでに再構築された情報を使用して、再構築中のブロックの同一サイズおよび同一形状のブロックを生成する。アグリゲータ310は、一部のケースでは、サンプルごとに、イントラ予測ユニット307が生成した予測情報をスケーラ／逆変換ユニット305によって提供されるような出力サンプル情報に追加する。

他のケースでは、スケーラ／逆変換ユニット305の出力サンプルは、インター符号化された、および場合によっては動き補償されたブロックに関係する場合もある。そのようなケースでは、動き補償予測ユニット306は、参照画像メモリ308にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルをブロックに関連するシンボル313に従って動き補償した後、これらのサンプル（この場合、残差サンプルまたは残差信号と呼ばれる）は、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ／逆変換ユニットの出力に追加することができる。動き補償ユニットが予測サンプルをフェッチする参照画像メモリ内のアドレスは、動きベクトルによって制御することができ、例えば、X、Y、および参照画像成分を有し得るシンボル313の形態で動き補償ユニットが利用できるようにすることができる。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照画像メモリからフェッチされたサンプル値の補間、動きベクトル予測機構などを含むことができる。

アグリゲータ310の出力サンプルは、ループフィルタユニット311における様々なループフィルタリング技術の対象となり得る。ビデオ圧縮技術には、コーディングされたビデオビットストリームに含まれるパラメータによって制御され、パーサ304からのシンボル313としてループフィルタユニット311で利用できるループ内フィルタ技術を含めることができるが、コーディングされたピクチャまたはコーディングされたビデオシーケンスの以前の（デコード順で）部分のデコード中に取得されたメタ情報に応答したり、以前に再構築およびループフィルタされたサンプル値に応答したりすることもできる。

ループフィルタユニット311の出力は、レンダリングデバイス312に出力され得るだけでなく、将来のインター画像予測で使用するために参照画像メモリ557に格納されるサンプルストリームにすることもできる。

特定の符号化された画像は、完全に再構成されると、将来の予測のための参照画像として使用できる。符号化された画像が完全に再構築され、符号化された画像が（例えば、パーサ304によって）参照画像として識別されると、現在の参照画像309は、参照画像バッファ308の一部になることができ、次の符号化された画像の再構築を開始する前に、新しい現在の画像メモリを再割り当てすることができる。

ビデオデコーダ300は、ITU－T Rec．H．265などの規格で文書化され得る所定のビデオ圧縮技術に従って復号化動作を実行することができる。符号化されたビデオシーケンスは、ビデオ圧縮技術文書または規格において指定されるように、および具体的にはそこで文書化されたプロファイルにおいて指定されるように、ビデオ圧縮技術または規格の構文に準拠しているという意味において、使用されているビデオ圧縮技術または規格によって指定された構文に従ってもよい。また、コンプライアンスのために必要なのは、符号化されたビデオシーケンスの複雑さが、ビデオ圧縮技術または標準のレベルによって定義された範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒当たりのメガサンプルで測定される）、最大参照ピクチャサイズなどを、制限する。レベルによって設定される制限は、場合によっては、仮想参照デコーダ（HRD）の仕様と、符号化されたビデオシーケンスで通知されるHRDバッファ管理のメタデータによってさらに制限されることがある。

一実施形態では、受信機302は、符号化されたビデオとともに追加の（冗長な）データを受信する場合がある。追加のデータは、符号化されたビデオシーケンス（複数可）の一部として含まれる場合がある。追加のデータは、データを適切に復号する、および／または元のビデオデータをより正確に再構築するためにビデオデコーダ300によって使用されてよい。追加のデータは、例えば、時間的、空間的、または信号対雑音比（SNR）強化層、冗長スライス、冗長画像、順方向エラー訂正コードなどの形式をとることができる。

図4は、本開示の一実施形態によるビデオエンコーダ400の機能ブロック図であり得る。

エンコーダ400は、エンコーダ400によって符号化すべきビデオ画像（複数可）を取り込むことができる（エンコーダの一部ではない）ビデオソース401からビデオサンプルを受信してもよい。

ビデオソース401は、任意の適切なビット深度（例えば8ビット、10ビット、12ビット…）、任意の色空間（例えば、BT．601 Y CrCB、RGB、…）、および任意の適切なサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）であり得るデジタルビデオサンプルストリームの形態で、エンコーダ（303）によって符号化すべきソースビデオシーケンスを提供してもよい。メディア供給システムでは、ビデオソース401は、これまでに準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース401は、ローカル画像情報をビデオシーケンスとして取り込むカメラである場合もある。ビデオデータは、順番に見たときに動きを与える複数の個別の画像として提供され得る。画像自体は、画素の空間アレイとして編成することができ、各画素は、使用中のサンプリング構造、色空間などに応じて、1つまたは複数のサンプルを含み得る。当業者であれば、画素とサンプルとの関係を容易に理解することができる。以下の説明はサンプルに焦点を当てている。

一実施形態によれば、エンコーダ400は、用途によって要求されるように、リアルタイムで、または任意の他の時間制約の下で、ソースビデオシーケンスの画像を符号化し、符号化されたビデオシーケンス410に圧縮することができる。適切な符号化速度を施行することは、コントローラ402の1つの機能である。コントローラは、以下に説明するように他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、結合は描かれていない。コントローラによって設定されるパラメータには、レート制御関連パラメータ（画像スキップ、量子化、レート歪み最適化手法のラムダ値など）、画像サイズ、画像グループ（GOP）レイアウト、最大動きベクトル検索範囲などを含めることができる。当業者であれば、コントローラ402の他の機能は、それらが特定のシステム設計のために最適化されたビデオエンコーダ400に関連し得るため、容易に特定することができる。

一部のビデオエンコーダは、当業者が「符号化ループ」として容易に認識するもので動作する。過度に簡略化した説明として、コーディングループは、エンコーダ402（以降「ソースコーダ」）（コード化される入力画像と参照画像に基づいてシンボルを作成する役割を果たす）のエンコーディング部分、およびシンボルを再構築して（リモート）デコーダも作成するであろうサンプルデータを作成するエンコーダ400に組み込まれた（ローカル）デコーダ406で構成され得る（シンボルとコード化されたビデオビットストリームとの間の任意の圧縮は、開示された主題で考慮されているビデオ圧縮技術では無損失であるため）。再構築されたサンプルストリームは、参照画像メモリ405に入力される。シンボルストリームの復号は、デコーダの場所（ローカルまたはリモート）に関係なくビットイグザクト結果をもたらすため、参照画像バッファコンテンツもまた、ローカルエンコーダとリモートエンコーダとの間でビットイグザクトである。言い換えると、エンコーダの予測部分は、復号中に予測を使用するときにデコーダが「見る」のとまったく同じサンプル値を参照画像サンプルとして「見る」。参照画像の同期性（および、例えばチャネルエラーのために同期性を維持できない場合に生じるドリフト）のこの基本原理は、当業者によく知られている。

「ローカル」デコーダ406の動作は、「リモート」デコーダ300の動作と同じであってよく、これは、図3に関連して上記で詳細にすでに説明されている。しかしながら、図4も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ408およびパーサ304による符号化されたビデオシーケンスへのシンボルの符号化／復号化は可逆であり得るため、チャネル301、受信機302、バッファ303およびパーサ304を含むデコーダ300のエントロピー復号化部分は、ローカルデコーダ406に完全には実装されない場合がある。

この時点で行うことができる観察は、デコーダに存在する解析／エントロピー復号以外のデコーダ技術も、対応するエンコーダにおいて、実質的に同一の機能形式で必ず存在する必要があるということである。エンコーダ技術の説明は、包括的に説明されているデコーダ技術の逆であるため、省略できる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。

その動作の一部として、ソースコーダ403は、動き補償予測符号化を実行してよく、これは、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の以前に符号化されたフレームを参照して入力フレームを予測的に符号化する。この方法において、符号化エンジン407は、入力フレームのピクセルブロックと、入力フレームへの予測参照（複数可）として選択され得る参照フレーム（複数可）のピクセルブロックとの差を符号化する。

ローカルビデオデコーダ406は、ソースコーダ403によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータを復号してもよい。符号化エンジン407の動作は、非可逆プロセスであることが有利であり得る。符号化されたビデオデータがビデオデコーダ（図4には示されていない）で復号され得るとき、再構築されたビデオシーケンスは通常、いくつかのエラーを伴うソースビデオシーケンスの複製であり得る。ローカルビデオデコーダ406は、参照フレームに対してビデオデコーダによって実行され得る復号化プロセスを複製し、再構築された参照フレームを参照画像キャッシュ405に記憶させてよい。この方法において、エンコーダ400は、（送信エラーがない限り）遠端のビデオデコーダによって取得されるであろう再構築された参照フレームとして共通のコンテンツを有する再構築された参照フレームのコピーをローカルに記憶してもよい。

予測器404は、符号化エンジン407の予測検索を実行してもよい。すなわち、符号化すべき新しいフレームについて、予測器404は、サンプルデータ（候補参照ピクセルブロックとしての）、または新しい画像の適切な予測参照として機能し得る、参照画像の動きベクトル、ブロック形状などの特定のメタデータについて参照画像メモリ405を検索してもよい。予測器404は、適切な予測参照を見つけるために、ピクセルブロックごとのサンプルブロックに基づいて動作してもよい。一部のケースでは、予測器404によって得られた検索結果によって決定されるように、入力画像は、参照画像メモリ405に記憶された複数の参照画像から引き出された予測参照を有してもよい。

コントローラ402は、例えば、ビデオデータをエンコードするために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ403の符号化動作を管理してもよい。

すべての前述の機能ユニットの出力は、エントロピーコーダ408でエントロピー符号化を受ける場合がある。エントロピーコーダは、例えばハフマン符号化、可変長符号化、算術符号化などの当業者に知られている技術に従ってシンボルを無損失圧縮することにより、様々な機能ユニットによって生成された記号を符号化されたビデオシーケンスに変換する。

送信機409は、エントロピーコーダ408によって作成された符号化されたビデオシーケンスをバッファリングして、符号化されたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る通信チャネル411を介した送信に備えることができる。送信機409は、ビデオコーダ403からの符号化されたビデオデータを、送信すべき他のデータ、例えば符号化されたオーディオデータおよび／または補助データストリーム（ソースは図示せず）と合体させてもよい。

コントローラ402は、エンコーダ400の動作を管理してもよい。コーディング中に、コントローラ405は、各符号化画像に特定の符号化画像タイプを割り当ててよく、これは、それぞれの画像に適用され得るコーディング技術に影響を及ぼす可能性がある。例えば、画像は多くの場合、次のフレームタイプのいずれかとして割り当てられ得る。

イントラ画像（I画像）は、予測のソースとしてシーケンス内の他のフレームを使用せずに符号化および復号され得るものであり得る。一部のビデオコーデックでは、例えばIndependent Decoder Refresh Pictureなど、様々なタイプのイントラ画像を使用できる。当業者は、Iピクチャの変形、ならびに、それらのそれぞれの用途および機能を認識している。

予測画像（P画像）は、各ブロックのサンプル値を予測するために最大1つの動きベクトルおよび参照インデックスを使用するイントラ予測またはインター予測を使用して符号化および復号され得るものであり得る。

双方向予測画像（Bピクチャ）は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトルおよび参照インデックスを使用して、イントラ予測またはインター予測を用いて符号化および復号され得るものである。同様に多重予測画像は、1つのブロックを再構築するために、2つよりも多い参照画像、および関連するメタデータを使用することができる。

ソース画像は、一般に、空間的に複数のサンプルブロック（例えば、それぞれ4×4、8×8、4×8、または16×16サンプルのブロック）に細分され、ブロックごとに符号化され得る。ブロックは、ブロックのそれぞれの画像に適用されたコーディング割り当てによって決定されるように、他の（すでに符号化された）ブロックを参照して予測的にコーディングされ得る。例えば、I画像のブロックは、非予測的に符号化され得るか、または同じ画像のすでに符号化されたブロックを参照して予測的に符号化され得る（空間予測またはイントラ予測）。P画像の画素ブロックは、空間予測を介して、または以前に符号化された1つの参照画像を参照する時間予測を介して、非予測的に符号化され得る。Bピクチャのブロックは、1つまたは2つの以前に符号化された参照画像を参照して、空間予測によって、または時間予測によって、非予測的に符号化されてもよい。

ビデオエンコーダ400は、ITU－T Rec．H．265などの所定のビデオの符号化技術または規格に従って符号化動作を実行することができる。その動作において、ビデオエンコーダ400は、入力ビデオシーケンスの時間的および空間的冗長性を活用する予測符号化動作を含む、様々な圧縮動作を実行することができる。したがって、符号化されたビデオデータは、使用されているビデオ符号化技術または標準によって指定されたシンタックスに準拠していることがある。

一実施形態では、送信機409は、符号化されたビデオとともに追加のデータを送信してもよい。ソースコーダ403は、そのようなデータを、符号化されたビデオシーケンスの一部として含む場合がある。追加のデータは、時間的／空間的／SNRエンハンスメントレイヤ、冗長な画像およびスライスなどの冗長データの他の形式、補足拡張情報（SEI）メッセージ、ビジュアルユーザビリティ情報（VUI）パラメータセットフラグメントなどを含むことができる。

図5は、コンテンツサーバ502、クライアント503、およびユーザインターフェース501がある例示的な実施形態による簡略化されたブロック図500を示す。クライアント503は、後述する1つまたは複数の選択コールバック511をコンテンツサーバ502に通信し、コンテンツサーバ502は、後述するように、メディアプレゼンテーション記述（MPD）更新512および1つまたは複数のメディアセグメント513で応答する。

例えば、図5を参照した例示的な実施形態によれば、コンテンツサーバ502は、クライアント503などのDASHクライアントに初期MPDおよびMPD更新512ならびにメディアセグメント513を提供し、クライアント503がMPD更新512の一部としてストーリーラインイベントを受信するたびに、クライアント503は、このイベントをユーザインターフェース501に公開してユーザに提供することができ、それにより、ユーザが選択を決定したとき、ユーザインターフェース501はクライアント503に通知し、クライアント503は、コンテンツサーバ502がそれに応じてMPDを更新するように、その選択、1つまたは複数の選択コールバック511をコンテンツサーバ502に提供する。そのような実施形態は、以下でさらに説明するように、DASHストリーミングにおけるインタラクティブなストーリーラインの本開示のアーキテクチャを表す。

さらに、このようなストーリーラインイベントは、MPDストーリーラインイベントストリームに関して定義されてよく、それによりMPDストーリーラインイベントは、後述するストーリーマップ内の1つまたは複数の選択点を伝えるMPDイベントであってよく、イベントスキームは、「urn：mpeg：dash：manifest－storyline－event：2020」などのschemeIdUriで識別されてもよく、期間ごとに1つのイベントストリーム要素のみが許可されてよく、それらの＠schemeIdUriにおいてこのURIを使用することになるこれらのイベントを伝える。EventStream＠値は、クライアント503によって無視されてもよい、すなわち、サブスキームは、そのようなイベントストリームに対して定義されなくてもよい。

また、このようなストーリーラインのイベントは、以下の表1に示すように、接続要素を含むように、このようなMPDストーリーラインイベントストリームのイベント要素に対してさらに定義されてもよい（プレイリストイベントをサポートするための拡張イベントセマンティクス）。

さらに、例示的な実施形態による表2（プレイリストセマンティクス）の以下のような接続を示すリンクのセットを含むか、またはそれからなる相互接続要素も存在し得る。

一例として、図6、図8、図9A、および図9BのいずれかにおけるP0期間におけるストーリーラインイベントの接続要素、相互接続要素は、以下の例示的な事例のうちの1つによって表すことができる。
（ケースAの例）
＜Interconnection ＠to＝’’1’’ ＠data＝’’Bill kills Alice’’＞
＜Interconnection ＠to＝’’2’’ ＠data＝’’Bill kisses Alice’’＞
＜Interconnection ＠to＝’’3’’ ＠data＝’’Bill misses Alice’’＞
または
（ケースBの例）
＜Interconnection ＠from＝’’0’’ ＠to＝’’1’’ ＠data＝’’Bill kills Alice’’＞
＜Interconnection ＠from＝’’0’’ ＠to＝’’2’’ ＠data＝’’Bill kisses Alice’’＞
＜Interconnection ＠from＝’’0’’ ＠to＝’’3’’ ＠data＝’’Bill misses Alice’’＞

例示的な実施形態によれば、1つまたは複数の相互接続要素を1つのストーリーラインイベントに含めることができ、複数の接続要素は、現在のセッションのストーリーマップの一部または全体を提供することができ、以下でさらに説明するように、現在の期間要素の最後の相互接続マップのみが、イベントの持続期間中に選択のためにアクティブであってもよい。例えば、図6、図8、図9A、および図9Bを見ると、選択S0のみが時々選択のためにアクティブであっても、マップ600、800、900A、および900Bのいずれかは、例えばユーザおよび／またはサーバ設定として予め決定され得る様々な基準に応じてクライアントに表示され得る。

したがって、ユーザがユーザインターフェース501で選択を行った後、クライアント503は、イベント要素によって定義されたURLアドレスに対して選択コールバック511を介してHTTP GETリクエストを行い、選択されたPeriod＠to値は、そのようなリクエストのクエリパラメータに含めることができる。したがって、コンテンツサーバ502において、マニフェストは、ユーザ選択に基づいて更新されてもよく、ユーザ選択は、例示的な実施形態によれば、帯域外で、または前記コールバック機能を使用して提供されてもよい。

図6は、選択点S0で分割されるセグメント期間P0からセグメント期間P1、P2、およびP3などの様々なストーリーマップMPDセグメントが示されている実施形態によるマップ600であり、期間P1、P2、およびP3の長さによって示される持続時間は異なっていてもよい。もちろん、これらのセグメントのうちの1つまたは複数は、それぞれのMPDセグメントに応じて同じ持続時間であってもよい。さらに、セグメント期間P1は、選択点S1において、セグメント期間P4およびP5に分割することができ、セグメント期間P5およびP2はセグメント期間P6に合流することができ、セグメント期間P4、P6、およびP3はセグメント期間P7に合流することができる。前記セグメント期間P1～P7の持続時間は、同じであっても異なっていてもよい。

すなわち、図6では、ストーリーは期間P0で始まり、選択点S0での期間P0の終了時に、ストーリーは、少なくともいくつかの相対的に異なるコンテンツおよび場合によっては異なる持続時間を各々が有する期間P1、P2、またはP3に進むことができる。期間P1の終わりおよび選択点S1において、ストーリーは、図6に例示されるように、期間P4または期間P5の選択肢を有する。図示された残りのストーリー期間P6およびP7は、様々な分岐の合流後に生じる。もちろん、様々な分岐は必ずしも合流する必要はない。例示的な実施形態によれば、各選択点における選択肢の数は、2つ以上に設定されてもよい。また、各分岐の持続時間は必ずしも等しくなくてもよく、同じおよび異なる持続時間のいずれかの分岐の合流があってもよい。さらに、ストーリーは、例示的な実施形態による1つまたは複数の終点を有することができる。図6のように、期間P7は、そのMPDセグメントを再生した後にストーリーを終了させることができる終点であると考えることができる。

例示的な実施形態によれば、そのようなストーリーは、期間の接続を提供するだけでなく、接続先期間に関するインタラクティブな情報を提供することができるインタラクティブデータを有するリッチ接続マップ（例えば、表3（インタラクティブデータを有する接続マップの例））に関して定義することができ、そのようなマップは、例示的な表3として説明することができる。

この例示的な表3に示すように、図5と同様に、各接続レッグToは、1つまたは複数の期間への接続を有するだけでなく、その接続に関連付けられたインタラクティブデータ（IDX）も有し、そのようなインタラクティブデータは、接続先期間のみに依存するのではなく、接続（接続元および接続先）に依存し得る。すなわち、例示的な実施形態によれば、P2からP6に接続するためのインタラクティブデータは、例えば、ID56であるP5からP6に接続するためのインタラクティブデータとは異なる可能性があるID26である。インタラクティブな情報は、図6のS0および／またはS1などの選択ウィンドウの開始時に、コンテンツサーバ502からアプリケーションに、クライアント503において、およびそれによってユーザインターフェース501に渡されてもよく、その結果、アプリケーションは、ユーザに対して表示されるために直接使用されるデータを処理するか、またはユーザインターフェース501のユーザに関する追加情報を取得することができる。インタラクティブデータの構文は、例示的な実施形態によれば、クライアント502に対して不明瞭であってもよく、そうでなければ直接表示されなくてもよい。

図7は、例示的なフローチャート700を示しており、S701において、プロセスは、S702において、コンテンツサーバ502などのサーバからクライアント503などのクライアントデバイスにメディアセグメントデータをストリーミングすること、またはS703において、S702と並行してまたはそれに連続して、サーバが1つまたは複数のMPD更新の一部としてストーリーラインイベントをクライアントデバイスに提供したかどうかをチェックすることのいずれかによって開始することができる。S703において、そのようなストーリーラインイベントがクライアントデバイスに提供されると判定された場合、S704において、例えばサーバから提供された上記の表3のリッチ接続マップに基づいてマップ情報を判定することができ、図6に示すようなそのようなマップ情報が判定された場合、S705において、例示的な実施形態による図6と比較して、例えば図8、図9A、および図9Bに示すように、前記マップ情報を非表示にするか、そうでなければ修正するかどうかも判定することができる。ユーザインターフェースからクライアントに提供される予め設定されたユーザ設定、またはサーバからクライアントに提供される予め設定されたサーバ設定に応じてもよいS705におけるこのような判定に基づいて、図6、図8、図9A、および図9Bのいずれかのようなマップをユーザに表示することができる。例えば、図6を見ると、S706において、マップ600は、クライアント503およびユーザインターフェース501のうちの1つまたは複数を介してユーザに表示されてもよく、S706において、ユーザは、ユーザインターフェース501を介したユーザ入力に基づいて期間P1、P2、およびP3のうちの1つが選択S0に基づいて選択され、P1が選択された場合には、P4およびP5のうちの1つが選択S1において選択されるように、選択S0およびS1のうちの1つまたは複数を別々にまたは同時に入力してもよい。例えば、そのような実施形態では、S0選択が行われた後、S708において、選択S0で選択された1つまたは複数の期間のいずれかに沿って、選択S1などの別の選択点があるかどうかが判定され得る。選択点がある場合、プロセスはS706に戻ることができ、選択点がない場合、プロセスはS702に進み、ユーザによって行われた1つ
または複数の選択に基づいてストリーミングを続行するか、そうでなければストリーミングを開始することができる。

対照的に、図7のS705などの実施形態によれば、前記予め設定されたユーザおよび／またはサーバ設定によって、期間P0～P7の持続期間部分が、各期間P0～P7のサイズを互いに等しいサイズで表示することによって非表示にされるべきであると判定され得ることを除いて、図6のマップ600と同様の図8の例示的なマップ800を参照されたい。あるいは、図9Aおよびその例示的なマップ900Aを参照すると、時間的に最初の選択、例えば選択S0、およびその後のそれぞれの期間P1～P3に関する期間のみが示されている。すなわち、ストーリーラインはマップ600と同じであってもよいが、マップ900Aは、少なくとも最初は、選択S0の直後の期間P1～P3のみが表示され、他の期間P4～P7は非表示にされるユーザへの出力の実施形態を示し、そのような情報は、S705に関して上述したように判定されてもよい。同様に、図9Bのマップ900Bでは、図8と同様に、S705において、前記予め設定されたユーザおよび／またはサーバ設定によって、期間P0～P3の持続期間部分は、図9Aのマップ900Aと比較して互いに等しいサイズで各期間P0～P3のサイズを表示することによって非表示にされるべきであると判定され得る。

例示的な実施形態によれば、S707などでの各選択は、直前の期間の完了前に必要とされ得る。例えば、S0での選択は、期間P0の完了前に、またはいくつかの実施形態では、期間P0の開始前に必要とされ得る。

したがって、本出願の例示的な実施形態は、可能な選択ごとに追加のインタラクティブデータを使用してMPDイベントを使用して選択選択肢を提供することによって技術的解決策を達成し、それによってアプリケーションは、ユーザインターフェース上に様々な選択選択肢を表示する前にデータまたは情報を使用して追加のデータを取得することができる。したがって、この技術的利点は、ストーリーマップを更新することを可能にすることに加えて、ユーザ選択インターフェースにおいて、例えば、今後の選択肢、部分ストーリーマップ、またはストーリーマップ全体のいずれかをユーザに提供することを可能にする。したがって、例示的な実施形態は、少なくともマップが選択によって配信された場合に提示される技術的欠点を解決し、その結果、クライアントは、より完全なまたは全体マップなしに一度に1つの選択のみを見ることができる。さらに、実際の期間＠idをクライアントに非表示にすることもできるが、それにもかかわらず、サーバは、任意の選択された期間（複数可）のデータを提供するための操作性を維持する。したがって、マップは、過去および将来の接続を含む各イベントによって更新することができ、イベントは、ユーザが選択を行うことができる開始時間および持続時間（すなわち、イベントアクティブ期間）を提供することができる。さらに、イベントアクティブ期間が次の期間への遷移の前に設定され得る実施形態では、クライアントは、コンテンツをバッファリングし、例えばネットワークレイテンシまたはユーザ選択レイテンシ途中再生のために達成され得ない連続再生を有するのに十分な時間を有することができる。さらに、例示的な実施形態によれば、クライアントは、マップならびにすべての期間を記憶し、それに応じて再生のためのインタラクティブなローカルMPDを構築することができる。

したがって、例示的な実施形態によれば、インタラクティブなストーリーラインのストリーミングコンテンツを配信するための方法があり、ここでは、ストーリー方向を変更するために提供された選択肢の中から選択肢を選択するために特定の瞬間に選択がユーザに提供され、MPDイベントは、選択肢ならびに各期間の選択肢ごとのインタラクティブデータを伝達するために使用され、イベントは、実際の遷移前の任意の期間をアクティブ化することができ、したがって、クライアントが選択された次の期間をバッファリングし、中断または再バッファリングすることなくコンテンツを再生するのに十分な時間を提供することができ、ストーリーマップは、イベントごとに1つの選択を提供することができ、または任意のイベントで任意の数の選択を提供することができ、またはストーリーマップ全体を提供することができ、ストーリーマップまたはその一部は、各イベントでまたはいくつかのイベントで更新することができ、イベントは、対応する期間がDASHクライアントに非表示にされる選択肢を提供することができ、MPDは、ユーザによって選択された期間を追加することによって各期間の終了時に更新される。

そのような方法は、ストーリーマップが完全に提供される場合、ストーリーマップを徐々にまたは1つのステップで構築することと、対応する期間を記憶することもさらに含むことができ、したがって、MPDのためにサーバに連絡する必要なく、インタラクティブストーリーを再生しながらメディアコンテンツをストリーミングするだけで、インタラクティブなストーリーライン全体を構築し、MPD更新をローカルに作成することができる。

アプリケーションが各選択肢とともにインタラクティブデータを取得し、データを使用してインタラクティブなアプリケーションを構築することができる方法であって、インタラクティブデータは、テキストであってもよいし、バイナリデータの符号化されたベース64であってもよく、したがって、これは、ユーザインターフェースでユーザとの対話を示すためにアプリケーションによって使用され得る画像、グラフィック、GIF、比喩、アバター、アニメーション、またはプログラムデータさえも含み得る。

例示的な実施形態によれば、そのような方法は、ストーリーマップおよびそのエッジを選択に関するインタラクティブな情報でリッチ化する。選択ウィンドウ中にこの情報が提供されると、アプリケーションは、その情報を使用して、その情報またはその一部をユーザに表示し、その選択を助ける情報または視覚的ガイドラインを提供するか、またはインタラクティブな情報をさらに処理して選択プロセス中のリッチなユーザ対話を提供することができる。インタラクティブな情報は、テキスト、画像、アニメーション、プログラム、またはリッチアプリケーションを構築するための組み合わせとすることができる。

上述した技術は、コンピュータ可読命令を使用し、1つまたは複数のコンピュータ可読媒体に物理的に記憶されたコンピュータソフトウェアとして、または特別に構成された1つまたは複数のハードウェアプロセッサによって実施することができる。例えば、図10は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム1000を示している。

コンピュータソフトウェアは、コンピュータ中央処理ユニット（CPU）、グラフィックス処理ユニット（GPU）などにより、アセンブリ、コンパイル、リンク、または同様の機構の対象となり得、直接に、または翻訳、マイクロコードの実行などを通じて実行され得る命令を含むコードを作成することができる、任意の適切なマシンコードまたはコンピュータ言語を使用してコード化することができる。

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

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

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

入力ヒューマンインターフェースデバイスは、キーボード1001、マウス1002、トラックパッド1003、タッチスクリーン1010、ジョイスティック1005、マイク1006、カメラ1007、スキャナ1008のうちの1つまたは複数（各1つのみを表示）を含むことができる。

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

コンピュータシステム1000はまた、人間がアクセス可能な記憶装置と、それらに関連付けられた媒体、例えば、CD／DVD1011または同様の媒体を備えたCD／DVD ROM／RW1020、サムドライブ1022、取り外し可能なハードドライブまたはソリッドステートドライブ1023、テープおよびフロッピーディスク（描かれていない）などのレガシー磁気媒体、セキュリティドングル（描かれていない）などの専用のROM／ASIC／PLDベースのデバイスを含めた光学媒体などを含むことができる。

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

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

前述のヒューマンインターフェースデバイス、ヒューマンアクセス可能なストレージデバイス、およびネットワークインターフェースは、コンピュータシステム1000のコア1040に取り付けることができる。

コア1040は、1つまたは複数の中央処理装置（CPU）1041、グラフィック処理装置（GPU）1042、グラフィックアダプタ1017、フィールドプログラマブルゲートエリア（FPGA）1043の形態の専用プログラマブル処理装置、特定のタスク用のハードウェアアクセラレータ1044などを含むことができる。これらのデバイスは、読出し専用メモリ（ROM）1045、ランダムアクセスメモリ1046、内部のユーザがアクセスできないハードドライブ、SSDなど1047の内部大容量記憶装置とともに、システムバス1048を介して接続されてもよい。いくつかのコンピュータシステムでは、システムバス1048は、追加のCPU、GPUなどによる拡張が可能なように、1つ以上の物理プラグの形態でアクセスすることができる。周辺デバイスは、コアのシステムバス1048に直接取り付けることも、周辺機器用バス1051を介して取り付けることもできる。周辺バスのアーキテクチャには、PCI、USBなどが含まれる。

CPU1041、GPU1042、FPGA1043、およびアクセラレータ1044は、前述したコンピュータコードを作成できるいくつかの命令を、組み合わせて実行することができる。コンピュータコードは、ROM1045またはRAM1046に記憶させることができる。過渡的なデータもRAM1046に記憶でき、これに反し永続的なデータは、例えば、内部大容量記憶装置1047に記憶することができる。1つまたは複数のCPU1041、GPU1042、大容量記憶装置1047、ROM1045、RAM1046などと密接に関連付けることができるキャッシュメモリを使用することにより、メモリデバイスのいずれかへの高速記憶および高速取り出しを可能にすることできる。

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

一例として、限定としてではなく、アーキテクチャ、具体的にはコア1040を有するコンピュータシステム1000は、1つまたは複数の有形のコンピュータ可読媒体で具体化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を提供することができる。このようなコンピュータ可読媒体は、先に紹介したようなユーザがアクセス可能な大容量記憶装置、ならびにコア内部大容量記憶装置1047またはROM1045などの、非一時的な性質を持つ、コア1040のいくつかの記憶装置に関連する媒体であってもよい。本開示の様々な実施形態を実施するソフトウェアは、このような装置に記憶させて、コア1040によって実行することができる。コンピュータ可読媒体は、特定の需要に従って、1つ以上のメモリ装置またはチップを含むことができる。ソフトウェアは、コア1040および具体的にはその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM1046に記憶されているデータ構造の定義、およびソフトウェアによって定義された工程に従ったこのようなデータ構造の変更を含む、本明細書で説明する特定の工程、または特定のプロセスの特定の部分を実行させることができる。これに加えて、またはこれに代えて、コンピュータシステムは、回路（例えば、アクセラレータ1044）に配線された、あるいは回路で具体化された論理の結果としての機能性を提供でき、本明細書で説明する特定のプロセス、または特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、またはソフトウェアとともに動作させることができる。ソフトウェアに対する言及は、必要に応じて論理を包含することができ、その逆もまた可能である。コンピュータ可読媒体への言及は、適切な場合には、実行のためにソフトウェアを格納する回路（集積回路（IC）など）、実行のための論理回路を具現化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを包含する。

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

64 ベース
100 通信システム
101 端末
102 端末
103 端末
104 端末
105 通信ネットワーク
201 カメラ、ビデオソース
202 エンコーダ
203 キャプチャサブシステム
204 ビデオビットストリーム
205 ストリーミングサーバ
206 ビデオビットストリーム、コピー
207 ストリーミングクライアント
208 ビデオビットストリーム、コピー
209 ディスプレイ
210 発信ビデオサンプルストリーム
211 ビデオデコーダ
212 クライアント、ストリーミングクライアント
213 非圧縮ビデオサンプルストリーム
300 ビデオデコーダ
301 チャネル
302 受信機
303 バッファメモリ
304 パーサ
305 スケーラ／逆変換ユニット
306 動き補償予測ユニット
307 イントラ画像予測ユニット
308 参照画像メモリ、参照画像バッファ
309 参照画像
310 アグリゲータ
311 ループフィルタユニット
312 ディスプレイ、レンダリングデバイス
313 シンボル
400 ビデオエンコーダ
401 ビデオソース
402 エンコーダ、コントローラ
403 ビデオコーダ、ソースコーダ
404 予測器
405 コントローラ
405 参照画像キャッシュ、参照画像メモリ
406 ローカルビデオデコーダ
407 符号化エンジン
408 エントロピーコーダ
409 送信機
410 ビデオシーケンス
411 通信チャネル
500 ブロック図
501 ユーザインターフェース
502 クライアント、コンテンツサーバ
503 クライアント
511 選択コールバック
512 メディアプレゼンテーション記述（MPD）更新、MPD更新
513 メディアセグメント
557 参照画像メモリ
600 マップ
700 フローチャート
800 マップ
900A マップ
900B マップ
1000 コンピュータシステム
1001 キーボード
1002 マウス
1003 トラックパッド
1005 ジョイスティック
1006 マイク
1007 カメラ
1008 スキャナ
1009 スピーカ
1010 画面、タッチスクリーン
1011 CD／DVD
1017 グラフィックアダプタ
1020 CD／DVD ROM／RW
1022 サムドライブ
1023 ソリッドステートドライブ
1040 コア
1041 中央処理装置（CPU）
1042 グラフィック処理装置（GPU）
1043 フィールドプログラマブルゲートエリア（FPGA）
1044 ハードウェアアクセラレータ
1045 読出し専用メモリ（ROM）
1046 ランダムアクセスメモリ
1047 コア内部大容量記憶装置
1048 システムバス
1050 汎用目的のデータポート
1051 周辺機器用バス
1098 通信ネットワーク
1099 インターフェース

Claims (10)

1. ビデオストリーミングのための方法であって、
   メディアプレゼンテーション記述（MPD）イベント、およびクライアントにストリーミングされるビデオコンテンツのメディアセグメントを提供するステップと、
   前記MPDイベントに基づいており、複数の選択肢および前記選択肢の各々に対するインタラクティブデータを含むユーザインターフェースを提供するように前記クライアントを制御するステップと、
   前記ユーザインターフェースを介した前記選択肢からの少なくとも1つの選択に基づいてMPDデータを更新するステップと、を含み、
   前記選択肢の各々は、前記ビデオコンテンツの複数のストーリーラインのうちの異なる期間をそれぞれ示し、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、複数の期間のうちの異なる期間の前にある少なくとも1つの他の期間のストーリーラインの再生が少なくとも完了する前に前記ユーザインターフェースを提供するステップを含み、
   前記MPDイベントを提供するステップは、前記ビデオコンテンツの前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および少なくとも1つの後の期間を識別するストーリーマップを前記クライアントに提供するステップを含み、
   前記ストーリーマップは、前記ビデオコンテンツの前記少なくとも1つの後の期間の前にストリーミングされるようにスケジュールされた前記複数の期間のうちの前記異なる期間の前に、1つの他の期間がストリーミングされるようにスケジュールされていることを示し、
   前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および前記少なくとも1つの後の期間のうちの少なくとも1つは、前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および前記少なくとも1つの後の期間のうちの少なくとも1つの他の期間とは異なる期間を含み、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、前記ストーリーマップの少なくとも一部を表示するように前記ユーザインターフェースを制御するステップを含み、
   前記ストーリーマップの一部は、前記1つの他の期間の表示および前記複数の期間のうちの異なる期間の表示を含み、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、前記1つの他の期間の前記表示と前記複数の期間のうちの前記異なる期間の前記表示との間の時点で前記少なくとも1つの選択の位置を識別するように前記ユーザインターフェースを制御するステップを含む、
   方法。
2. ビデオストリーミングのための方法であって、
   メディアプレゼンテーション記述（MPD）イベント、およびクライアントにストリーミングされるビデオコンテンツのメディアセグメントを提供するステップと、
   前記MPDイベントに基づいており、複数の選択肢および前記選択肢の各々に対するインタラクティブデータを含むユーザインターフェースを提供するように前記クライアントを制御するステップと、
   前記ユーザインターフェースを介した前記選択肢からの少なくとも1つの選択に基づいてMPDデータを更新するステップと、を含み、
   前記選択肢の各々は、前記ビデオコンテンツの複数のストーリーラインのうちの異なる期間をそれぞれ示し、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、複数の期間のうちの異なる期間の前にある少なくとも1つの他の期間のストーリーラインの再生が少なくとも完了する前に前記ユーザインターフェースを提供するステップを含み、
   前記MPDイベントを提供するステップは、前記ビデオコンテンツの前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および少なくとも1つの後の期間を識別するストーリーマップを前記クライアントに提供するステップを含み、
   前記ストーリーマップは、前記ビデオコンテンツの前記少なくとも1つの後の期間の前にストリーミングされるようにスケジュールされた前記複数の期間のうちの前記異なる期間の前に、1つの他の期間がストリーミングされるようにスケジュールされていることを示み、
   前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および前記少なくとも1つの後の期間のうちの少なくとも1つは、前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および前記少なくとも1つの後の期間のうちの少なくとも1つの他の期間とは異なる期間を含み、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、前記ストーリーマップの全体を表示するように前記ユーザインターフェースを制御するステップを含み、
   前記ストーリーマップの前記全体は、前記1つの他の期間の表示、前記複数の期間のうちの前記異なる期間の表示、および前記少なくとも1つの後の期間の表示を含む、
   方法。
3. 前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、前記1つの他の期間の前記表示と前記複数の期間のうちの前記異なる期間の前記表示との間の時点で前記少なくとも1つの選択の位置を識別するように前記ユーザインターフェースを制御するステップを含み、
   前記ユーザインターフェースを提供するように前記クライアントを制御するステップは、前記複数の期間のうちの前記異なる期間の前記表示のうちの少なくとも1つと前記少なくとも1つの後の期間の前記表示との間の時点で別の選択の別の位置を識別するように前記ユーザインターフェースを制御するステップをさらに含む、
   請求項2に記載の方法。
4. 前記ストーリーマップの前記全体を表示するように前記ユーザインターフェースを制御するステップは、接続マップに基づいて前記ストーリーマップの前記全体を表示するステップを含み、
   前記接続マップは、前記1つの他の期間、前記複数の期間のうちの前記異なる期間、および前記少なくとも1つの後の期間の各々を含むリストを含み、
   前記接続マップは、前記1つの他の期間から前記複数の期間のうちの前記異なる期間の各々への各接続のための第1のそれぞれの識別子をさらに含み、
   前記接続マップは、前記複数の期間のうちの前記異なる期間のうちの少なくとも1つから前記少なくとも1つの後の期間への少なくとも1つの接続のための第2のそれぞれの識別子をさらに含む、
   請求項3に記載の方法。
5. 前記クライアントは、HTTPを介した動的適応ストリーミング（DASH）クライアントである、請求項1に記載の方法。
6. ビデオストリーミングのための装置であって、
   コンピュータプログラムコードを記憶するように構成された少なくとも1つのメモリと、
   前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサと、を含み、前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサに、請求項1に記載の方法を行わせるためのコンピュータプログラムコードである、装置。
7. コンピュータに、請求項1に記載の方法を行わせるためのコンピュータプログラム。
8. 前記クライアントは、HTTPを介した動的適応ストリーミング（DASH）クライアントである、請求項2～4のいずれか一項に記載の方法。
9. ビデオストリーミングのための装置であって、
   コンピュータプログラムコードを記憶するように構成された少なくとも1つのメモリと、
   前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令されるように動作するように構成された少なくとも1つのプロセッサと、を含み、前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサに、請求項2～4のいずれか一項に記載の方法を行わせるためのコンピュータプログラムコードである、装置。
10. コンピュータに、請求項2～4のいずれか一項に記載の方法を行わせるためのコンピュータプログラム。

Images