特表2024-542586適応型ストリーミングパラメータ化のための拡張可能要求シグナリング
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-11-15
(54)【発明の名称】適応型ストリーミングパラメータ化のための拡張可能要求シグナリング
(51)【国際特許分類】
H04N 21/6587 20110101AFI20241108BHJP
H04N 21/434 20110101ALI20241108BHJP
【ＦＩ】
H04N21/6587
H04N21/434
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024531372
(86)(22)【出願日】2023-04-18
(85)【翻訳文提出日】2024-05-24
(86)【国際出願番号】 US2023065886
(87)【国際公開番号】W WO2023205634
(87)【国際公開日】2023-10-26
(31)【優先権主張番号】63/332,600
(32)【優先日】2022-04-19
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】18/301,826
(32)【優先日】2023-04-17
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】イーラジ・ソダガー
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA06
5C164MA02S
5C164MB13S
5C164MB44S
5C164SB15S
5C164SC03S
5C164TA08S
5C164TC13P
5C164UB11P
5C164UB26S
(57)【要約】
本開示は、一般に、メディアストリーミング技術に関し、より具体的には、動的適応型ストリーミングでのメディアの要求のための拡張可能パラメータ化シグナリングのための方法および装置に関する。本明細書に開示される様々な例示的な実装形態は、メディアサーバがストリーミングクライアントに、メディアサーバへのどの要求がパラメータ化され、どのようにパラメータ化されるかをシグナリングするメカニズムを可能にする。パラメータ化に対する特異性は、サービスプロバイダによって定義されてもよく、したがって拡張可能とされる。
【特許請求の範囲】
【請求項1】
メディアストリーミングデバイスによるコンテンツサーバからのHTTPを介した動的適応型ストリーミング（DASH）ストリーミングメディアのHTTP要求の拡張可能パラメータ化のための方法であって、DASHサービスプロバイダに、前記DASHストリーミングメディアの初期要求を送信するステップと、
前記コンテンツサーバから前記DASHストリーミングメディアのマニフェストを受信するステップと、
前記マニフェストを解析し、前記HTTP要求に関連付けられたパラメータ化記述子を抽出するステップと、
前記パラメータ化記述子から、ユニフォームリソース識別子およびキーのセットのうちの1つ以上を識別するステップであって、前記ユニフォームリソース識別子は前記HTTP要求のための前記拡張可能パラメータ化のパラメータ化スキームとリンクしている、ステップと、
前記パラメータ化スキームおよび前記キーのセットのうちの前記1つ以上に従って前記拡張可能パラメータ化に対応する1つ以上のタイプのHTTP要求を決定するステップと、
前記コンテンツサーバ宛てであり、前記1つ以上のタイプのHTTP要求に属するHTTP要求について、前記マニフェストに従ってパラメータのセットを構築するステップと、
前記HTTP要求に前記パラメータのセットを挿入するステップと
を含む、方法。
【請求項2】
前記HTTP要求はHTTP GET要求を含む、請求項1に記載の方法。
【請求項3】
前記ユニフォームリソース識別子は、ユニフォームリソースロケータ（URL）またはユニフォームリソース名（URN）を含む、請求項2に記載の方法。
【請求項4】
前記1つ以上のタイプのHTTP要求は、メディアセグメントHTTP要求タイプ、
マニフェストHTTP要求タイプ、
xlink HTTP要求タイプ、
コールバックイベントをトリガするコールバックHTTP要求タイプ、または
マニフェストチェーニングのためのチェーニングHTTP要求、のうちの少なくとも1つを含む、請求項3に記載の方法。
【請求項5】
前記パラメータ化スキームは、前記キーのセットの定義を含む、請求項2に記載の方法。
【請求項6】
パラメータ化を必要とする前記1つ以上のタイプのHTTP要求を決定するステップは、前記1つ以上のタイプのHTTP要求を識別するために、前記マニフェストに含まれる前記キーのセットのうちの前記1つ以上および前記キーのセットの前記定義を使用するステップを含む、請求項5に記載の方法。
【請求項7】
前記パラメータ化記述子は第1のパラメータ化選択文字列を含み、前記第1のパラメータ化選択文字列は、前記ユニフォームリソース識別子およびこれに続く前記キーのセットのうちの前記1つ以上を含む、請求項2～6のいずれか一項に記載の方法。
【請求項8】
前記パラメータ化記述子は第2のパラメータ化選択文字列をさらに含み、前記第2のパラメータ化選択文字列は、パラメータ化の事前定義されたタイプのHTTP GET要求の選択を表すハードコードされた識別文字列を含む、請求項7に記載の方法。
【請求項9】
前記パラメータのセットのうちの少なくとも1つは、動的なものとして前記マニフェストによって指定される、請求項2～6のいずれか一項に記載の方法。
【請求項10】
動的であると指定された前記パラメータのセットのうちの前記少なくとも1つは、前記メディアストリーミングデバイスによる適応計算を必要とする、請求項9に記載の方法。
【請求項11】
コンテンツサーバからのDASHストリーミングメディアの適応型ストリーミングのHTTP要求の拡張可能パラメータ化を実施するためのメディアストリーミングデバイスであって、前記メディアストリーミングデバイスは、命令を記憶するためのメモリと、DASHサービスプロバイダに、前記DASHストリーミングメディアの初期要求を送信し、
前記コンテンツサーバから前記DASHストリーミングメディアのマニフェストを受信し、
前記マニフェストを解析し、前記HTTP要求に関連付けられたパラメータ化記述子を抽出し、
前記パラメータ化記述子から、ユニフォームリソース識別子およびキーのセットのうちの1つ以上を識別し、前記ユニフォームリソース識別子は前記HTTP要求のための前記拡張可能パラメータ化のパラメータ化スキームとリンクしており、
前記パラメータ化スキームおよび前記キーのセットのうちの前記1つ以上に従って前記拡張可能パラメータ化に対応する1つ以上のタイプの要求を決定し、
前記コンテンツサーバ宛てであり、前記1つ以上のタイプの要求に属するHTTP要求について、前記マニフェストに従ってパラメータのセットを構築し、
前記HTTP要求に前記パラメータのセットを挿入する、前記命令を実行するためのプロセッサと
を備える、メディアストリーミングデバイス。
【請求項12】
前記HTTP要求はHTTP GET要求を含む、請求項11に記載のメディアストリーミングデバイス。
【請求項13】
前記ユニフォームリソース識別子は、ユニフォームリソースロケータ（URL）またはユニフォームリソース名（URN）を含む、請求項12に記載のメディアストリーミングデバイス。
【請求項14】
前記1つ以上のタイプのHTTP要求は、メディアセグメントHTTP要求タイプ、
マニフェストHTTP要求タイプ、
xlink HTTP要求タイプ、
コールバックイベントをトリガするコールバックHTTP要求タイプ、または
マニフェストチェーニングのためのチェーニングHTTP要求、のうちの少なくとも1つを含む、請求項13に記載のメディアストリーミングデバイス。
【請求項15】
前記パラメータ化スキームは、前記キーのセットの定義を含む、請求項12～14のいずれか一項に記載のメディアストリーミングデバイス。
【請求項16】
パラメータ化を必要とする前記1つ以上のタイプのHTTP要求を決定することは、前記1つ以上のタイプのHTTP要求を識別するために、前記マニフェストに含まれる前記キーのセットのうちの前記1つ以上および前記キーのセットの前記定義を使用することを含む、請求項15に記載のメディアストリーミングデバイス。
【請求項17】
前記パラメータ化記述子は第1のパラメータ化選択文字列を含み、前記第1のパラメータ化選択文字列は、前記ユニフォームリソース識別子およびこれに続く前記キーのセットのうちの前記1つ以上を含む、請求項12～14のいずれか一項に記載のメディアストリーミングデバイス。
【請求項18】
前記パラメータ化記述子は第2のパラメータ化選択文字列をさらに含み、前記第2のパラメータ化選択文字列は、パラメータ化の事前定義されたタイプのHTTP GET要求の選択を表すハードコードされた識別文字列を含む、請求項17に記載のメディアストリーミングデバイス。
【請求項19】
前記パラメータのセットのうちの少なくとも1つは、動的なものとして前記マニフェストによって指定され、動的であると指定された前記パラメータのセットのうちの前記少なくとも1つは、前記メディアストリーミングデバイスによる適応計算を必要とする、請求項12～14のいずれか一項に記載のメディアストリーミングデバイス。
【請求項20】
命令を記憶するための非一時的コンピュータ可読記憶媒体であって、前記命令は、コンテンツサーバからのDASHストリーミングメディアの適応型ストリーミングのHTTP要求の拡張可能パラメータ化を実施するためのメディアストリーミングデバイスのプロセッサによって実行されると、前記メディアストリーミングデバイスに、DASHサービスプロバイダに、前記DASHストリームメディアの初期要求を送信させ、
前記コンテンツサーバから前記DASHストリーミングメディアのマニフェストを受信させ、
前記マニフェストを解析させ、前記HTTP要求に関連付けられたパラメータ化記述子を抽出し、
前記パラメータ化記述子から、ユニフォームリソース識別子およびキーのセットのうちの1つ以上を識別させ、前記ユニフォームリソース識別子は前記HTTP要求のための前記拡張可能パラメータ化のパラメータ化スキームとリンクしており、
前記パラメータ化スキームおよび前記キーのセットのうちの前記1つ以上に従って前記拡張可能パラメータ化に対応する1つ以上のタイプのHTTP要求を決定させ、
前記コンテンツサーバ宛てであり、前記1つ以上のタイプのHTTP要求に属するHTTP要求について、前記マニフェストに従ってパラメータのセットを構築させ、
前記HTTP要求に前記パラメータのセットを挿入させる
ように構成された、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2023年4月17日に出願された米国非仮出願第18／301，826に基づき、その優先権の利益を主張し、これは、2022年4月19日に出願された米国仮出願第63／332，600号に基づき、その優先権の利益を主張する。これらの先行特許出願の各々は、その全体が参照により本明細書に組み込まれる。
本出願は、2023年4月17日に出願された米国非仮出願第18／301，826に基づき、その優先権の利益を主張し、これは、2022年4月19日に出願された米国仮出願第63／332，600号に基づき、その優先権の利益を主張する。これらの先行特許出願の各々は、その全体が参照により本明細書に組み込まれる。
【0002】
本開示は、一般に、メディアストリーミング技術に関し、より具体的には、適応型ストリーミングでのメディアの要求のための拡張可能パラメータ化のための方法および装置に関する。
【背景技術】
【0003】
本明細書で提供されるこの背景技術の説明は、本開示の文脈を一般的に提示するためのものである。本発明者らの研究は、その研究がこの背景技術の項に記載されている限りにおいて、またそれ以外の本出願の有効な出願時に先行技術として認められない可能性のある説明の態様と共に、本開示に対する先行技術としては明示的にも暗示的にも認められない。
【0004】
ハイパーテキスト転送を介した動的適応型ストリーミング（DASH）は、IPネットワークを介したマルチメディアコンテンツの柔軟なストリーミングを可能にする。DASHでは、動的適応型ストリーミングの機能および制御の様々な態様を実現するために、DASHクライアントからDASHサーバへの様々なタイプの要求が行われ得る。これらのタイプの要求のいくつかは、DASHクライアントからこれらの要求が行われるときにDASHサーバが受信すると予想されるパラメータのセットに関連付けられてもよい。これらのタイプの要求の各々について予想されるパラメータのセットは、メディアサーバ側から指定され得る。このようなパラメータ化に関連付けられた情報は、要求を作成するときにDASHクライアントが従うために、DASHサーバからDASHクライアントにシグナリングされてもよい。現在の実装形態では、要求のためのパラメータ化のこのようなシグナリングは、拡張可能ではなかった。
【発明の概要】
【発明が解決しようとする課題】
【0005】
本開示は、一般に、メディアストリーミング技術に関し、より具体的には、動的適応型ストリーミングでのメディアの要求のための拡張可能パラメータ化シグナリングのための方法および装置に関する。本明細書に開示される様々な例示的な実装形態は、メディアサーバがストリーミングクライアントに、メディアサーバへのどの要求がパラメータ化され、どのようにパラメータ化されるかをシグナリングするメカニズムを可能にする。パラメータ化に対する特異性は、サービスプロバイダによって定義されてもよく、したがって拡張可能とされる。
【課題を解決するための手段】
【0006】
いくつかの例示的な実装形態では、メディアストリーミングデバイスによるコンテンツサーバからのHTTPを介した動的適応型ストリーミング（DASH）ストリーミングメディアのHTTP要求の拡張可能パラメータ化のための方法が開示される。本方法は、DASHサービスプロバイダに、DASHストリーミングメディアの初期要求を送信するステップと、コンテンツサーバからDASHストリーミングメディアのマニフェストを受信するステップと、HTTP要求に関連付けられたパラメータ化記述子を抽出するためにマニフェストを解析するステップと、パラメータ化記述子から、ユニフォームリソース識別子およびキーのセットのうちの1つ以上を識別するステップであって、ユニフォームリソース識別子はHTTP要求のための拡張可能パラメータ化のためのパラメータ化スキームとリンクしている、ステップと、パラメータ化スキームおよびキーのセットのうちの1つ以上に従って拡張可能パラメータ化に対応する1つ以上のタイプのHTTP要求を決定するステップと、コンテンツサーバ宛てであり、1つ以上のタイプのHTTP要求に属するHTTP要求について、マニフェストに従ってパラメータのセットを構築するステップと、HTTP要求にパラメータのセットを挿入するステップと、を含み得る。
【0007】
上記の例示的な実装形態では、HTTP要求はHTTP GET要求を含む。
【0008】
上記の例示的な実装形態のいずれか1つでは、ユニフォームリソース識別子は、ユニフォームリソースロケータ（URL）またはユニフォームリソース名（URN）を含む。
【0009】
上記の例示的な実装形態のいずれか1つでは、1つ以上のタイプのHTTP要求は、メディアセグメントHTTP要求タイプ、マニフェストHTTP要求タイプ、xlink HTTP要求タイプ、コールバックイベントをトリガするコールバックHTTP要求タイプ、またはマニフェストチェーニングのためのチェーニングHTTP要求を含む。
【0010】
上記の例示的な実装形態のいずれか1つでは、パラメータ化スキームは、キーのセットの定義を含む。
【0011】
上記の例示的な実装形態のいずれか1つでは、パラメータ化を必要とする1つ以上のタイプのHTTP要求を決定するステップは、1つ以上のタイプのHTTP要求を識別するために、マニフェストに含まれるキーのセットのうちの1つ以上およびキーのセットの定義を使用するステップを含む。
【0012】
上記の例示的な実装形態のいずれか1つでは、
パラメータ化記述子は第1のパラメータ化選択文字列を含み、第1のパラメータ化選択文字列は、ユニフォームリソース識別子およびこれに続くキーのセットのうちの1つ以上を含む。
パラメータ化記述子は第1のパラメータ化選択文字列を含み、第1のパラメータ化選択文字列は、ユニフォームリソース識別子およびこれに続くキーのセットのうちの1つ以上を含む。
【0013】
上記の例示的な実装形態のいずれか1つでは、パラメータ化記述子は第2のパラメータ化選択文字列をさらに含み、第2のパラメータ化選択文字列は、パラメータ化の事前定義されたタイプのHTTP GET要求の選択を表すハードコードされた識別文字列を含む。
【0014】
上記の例示的な実装形態のいずれか1つでは、パラメータのセットのうちの少なくとも1つは、動的なものとしてマニフェストによって指定される。
【0015】
上記の例示的な実装形態のいずれか1つでは、
動的であると指定されたパラメータのセットのうちの少なくとも1つは、メディアストリーミングデバイスによる適応計算を必要とする。
動的であると指定されたパラメータのセットのうちの少なくとも1つは、メディアストリーミングデバイスによる適応計算を必要とする。
【0016】
本開示の態様はまた、上記の方法実装形態のいずれか1つを実行するように構成された回路を含むメディアストリーミングデバイスまたは装置も提供する。
【0017】
本開示の態様はまた、メディアストリーミングデバイスによって実行されると、メディアストリーミングデバイスに上記の方法実装形態のいずれか1つを行わせるように構成された命令を記憶する非一時的コンピュータ可読媒体も提供する。
【0018】
開示される主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。
【図面の簡単な説明】
【0019】
【図1】本開示の一実施形態によるシステムを示す。
【図2】本開示の一実施形態によるHTTPを介した動的適応ストリーミング（DASH）システムを示す。
【図3】本開示の一実施形態によるDASHクライアントアーキテクチャを示す。
【図4】要求パラメータ化のためのストリーミングメディアデバイスにおける例示的なロジックおよびデータフローを示す。
【図5】本開示の例示的な実施形態によるコンピュータシステムの概略図を示す。
【発明を実施するための形態】
【0020】
ハイパーテキスト転送プロトコル（HTTP）を介したストリーミング
図1は、リモート情報処理装置120が通信ネットワーク130を介して1つ以上の集中型または分散型コンテンツサーバ110からコンテンツを要求するように構成された、例示的なコンテンツ配信システム100を示す。具体的には、情報処理装置120は、コンテンツ消費アプリケーションとして機能する、専用ハードウェアコンポーネント、汎用ハードウェア上で動作するソフトウェアコンポーネント、またはこれらの組み合わせを含み得る。コンテンツ消費アプリケーションは、要求されているコンテンツおよび要求コンテンツの特性を指定する1つ以上の要求を生成し得る。各要求は、ネットワークプロトコルのスタックに基づいて構築され、通信ネットワーク130を介してコンテンツサーバ110に伝達されてもよい。これに応答して、コンテンツサーバは、要求に従ってビットストリームを生成し、ネットワークプロトコルのスタックを使用してビットストリームをパッケージ化し、ビットストリームパッケージをコンテンツ消費アプリケーションに伝達してもよい。
図1は、リモート情報処理装置120が通信ネットワーク130を介して1つ以上の集中型または分散型コンテンツサーバ110からコンテンツを要求するように構成された、例示的なコンテンツ配信システム100を示す。具体的には、情報処理装置120は、コンテンツ消費アプリケーションとして機能する、専用ハードウェアコンポーネント、汎用ハードウェア上で動作するソフトウェアコンポーネント、またはこれらの組み合わせを含み得る。コンテンツ消費アプリケーションは、要求されているコンテンツおよび要求コンテンツの特性を指定する1つ以上の要求を生成し得る。各要求は、ネットワークプロトコルのスタックに基づいて構築され、通信ネットワーク130を介してコンテンツサーバ110に伝達されてもよい。これに応答して、コンテンツサーバは、要求に従ってビットストリームを生成し、ネットワークプロトコルのスタックを使用してビットストリームをパッケージ化し、ビットストリームパッケージをコンテンツ消費アプリケーションに伝達してもよい。
【0021】
いくつかの例示的な実装形態では、コンテンツは一度に要求されてもよい。言い換えると、メディアコンテンツ全体がコンテンツ消費アプリケーションによって要求され、受信され、ローカルに記憶されてもよい。ローカルに記憶されたコンテンツは、例えば、コンテンツ消費アプリケーションの一部であるかまたはこれと別個であるメディアプレーヤによって、必要に応じて処理および消費（例えば、抽出、デコード、および再生）され得る。このようなプロセスは、ダウンロードと呼ばれてもよい。
【0022】
いくつかの他の実装形態では、コンテンツは、後の消費のためにダウンロードされるのではなく、消費されているときにストリーミングされてもよい。このような実装形態では、要求コンテンツ全体がコンテンツ消費アプリケーションに記憶される必要はない場合がある。むしろ、限られた量のコンテンツが、ローリングベースでコンテンツサーバ110から連続的に受信され、コンテンツ処理および再生のために入出力ローカルバッファによって管理される。このような実装形態は、ストリーミングと呼ばれてもよい。巻き戻し、早送り、および検索などのいくつかのメディア再生機能は、複雑なメディアビットストリーム制御およびバッファリングを含み得るが、メディアストリーミングは通常、より汎用的であり、繰り返し消費されないメディアの時刻指定されたシーケンスを含むコンテンツの配信により適している。
【0023】
以下の開示では、「コンテンツ」および「メディア」という用語は、交換可能に使用され得る。要求コンテンツは、コンテンツ自体および様々なメタデータを含むがこれらに限定されない、その消費に必要とされる様々な情報項目を含み得る。コンテンツ自体は、ビデオコンポーネント／トラック、音声コンポーネント／トラック、字幕などを含むがこれらに限定されない、異なるトラックなどの様々なメディアコンポーネントをさらに含んでもよい。メディアコンテンツを記述するため、または追加の処理情報を提供するためのメタデータは、1つ以上の別個のトラックとして扱われてもよい。そのメタデータを有するこのようなコンテンツは、コンテンツ消費アプリケーションに知られているプロトコルまたは規則のセットに従って解析およびデコードされることが可能なビットストリームとして、コンテンツサーバ120によって生成され得る。単数形の「コンテンツサーバ」という用語は、単一のサーバ、または中央の位置に配置された、もしくは様々な地理的位置に分散された複数のサーバを表すために使用される。このようなコンテンツサーバは、専用の計算機械として実装されてもよく、あるいは、仮想機械として、および／またはクラウドコンピューティング環境に仮想的に収容された状態で、構築されてもよい。さらに以下の開示では、「情報処理装置」（図1の120参照）および「コンテンツ消費アプリケーション」という用語は、交換可能に使用されてよい。あるいは、これらの用語はまた、「クライアント」、「クライアントデバイス／装置」、「再生デバイス／装置／クライアント」などと呼ばれてもよい。図1には単一の情報処理装置120のみが示されているが、複数の独立した情報処理装置が存在することができる。言い換えると、コンテンツサーバ110のセットは、複数のコンテンツ消費アプリケーションにストリーミングサービスを同時に独立して提供するように構成されてもよい。
【0024】
いくつかの例示的な実装形態では、コンテンツサーバ110による配信のために生成されたコンテンツは、それらのストリーミングを容易にするためにセグメント化され得る。例えば、映画などのメディアコンテンツの時刻指定されたシーケンスは、各々がいくつかのメディアフレームを含む時間セグメントに細分され得る。各メディアセグメントは、例えば解析、デコーディング、および再生を含むその処理が他のメディアセグメントの情報を必要としないように、自己完結型であってもよい。メディアコンテンツは、事前にセグメント化されてもよい。したがって、メディアコンテンツは、セグメントごとにコンテンツサーバ120によって記憶および管理され得る。あるいは、メディアセグメントは、ストリーミングプロセス中に要求されているときに、近接して記憶されたメディアコンテンツからリアルタイムで生成されてもよい。いくつかのさらなる実装形態では、メディアのセグメント化は階層的であってもよく、複数のレベルのセグメント化を含む。
【0025】
ストリーミングのためのいくつかの特定の実装形態では、どのメディアセグメント、またはメディアセグメントのどの部分をコンテンツサーバ110から要求するかに関する決定は、ユーザアプリケーションインターフェースを通じたユーザの再生命令によって制御されるように、リアルタイムでコンテンツ消費アプリケーションによって決定されてもよい。このようにして、コンテンツサーバは、要求に応答し、要求に従ってそれらのメタデータを有するコンテンツのセグメントまたはセグメントの一部を生成および取得し、ネットワーク130を介して要求しているコンテンツ消費アプリケーションにセグメントまたはセグメントの一部を配信するように構成され得る。
【0026】
いくつかの例示的な実装形態では、メディアコンテンツの同じメディアトラックは、異なるバージョンとして準備されてもよい。例えば、同じムービートラックが、異なる解像度および／またはフレームレートで準備されてもよい。他の例として、同じムービートラックが異なるビットレートで準備されてもよい。他の例として、同じ音声ムービーが異なる音質および／または異なる音声チャネル（例えば、5チャネル音声、または7チャネル音声）で準備されてもよい。したがって、コンテンツ消費アプリケーションは、どのバージョンのメディアトラックをストリーミングすべきかを決定し、このような選択をメディアコンテンツのその要求に含めてもよい。コンテンツ消費アプリケーションによるこのような決定は、情報処理装置120の再生能力（例えば、表示解像度、デコーディング速度、処理能力、バッファサイズなど）、ネットワーク帯域幅およびスループットなどを含むがこれらに限定されない、いくつかの例示的な要因のうちの1つ以上に基づいて行われ得る。したがって、ストリーミングセッションは、それらのデバイス能力に応じて異なるメディア消費アプリケーション間で適合され得る。このように構成されたストリーミングアーキテクチャは、適応型ストリーミングと呼ばれてもよい。ストリーミングプロセスは、異なるバージョンのメディアトラックが、例えばリアルタイムネットワーク条件（例えば、帯域幅およびスループット、ならびにネットワーク帯域幅によってサポートされるビットレート）に従って、ストリーミングセッション中の異なる時点で選択および要求され得るという点で、各メディア消費アプリケーション内でさらに適応的であり得る。このように構成されたストリーミングアーキテクチャは、動的適応型ストリーミングとさらに呼ばれてもよい。特に、メディアコンテンツのビットレートに適応するように構成されたストリーミングアーキテクチャは、動的適応型ビットレートストリーミングと呼ばれてもよい。
【0027】
いくつかの例示的な実装形態では、動的適応型ストリーミングにおけるコンテンツ消費アプリケーションによるメディアコンテンツの特定のバージョンのセグメントまたはセグメントの一部の要求は、ストリーミングセッションの進行に従ってメディアマニフェストに基づいて構築されてもよい。「マニフェスト」という用語は、セグメント化、バージョン、ネットワークの場所、および任意のコンテンツ消費アプリケーションがストリーミングセッション中の異なる時点で何をどのように要求すべきかを決定するために必要とされ得る任意の他の情報を含む、メディアコンテンツを記述する情報項目の任意の集合を表すために使用され得る。マニフェストは、一般に、「メディア表現記述」（MPD）と呼ばれてもよい。
【0028】
このようなマニフェストは、特定のメディアコンテンツが作成または生成されるときに、コンテンツサーバ側で準備されてもよい。このようなマニフェストは、コンテンツ消費アプリケーションによって要求され、ストリーミングセッションの開始時にコンテンツサーバから受信されてもよい。コンテンツ消費アプリケーションは、ストリーミングセッション中にマニフェストの任意の更新をさらに要求してもよい。このようなマニフェストは、ストリーミングセッション中のメディアコンテンツの特定のバージョンのセグメントまたはセグメントの一部の後続の要求を構築するための青写真として、コンテンツ消費デバイスによって使用されてもよい。
【0029】
いくつかの例示的な実装形態では、メディアサーバは、外部アプリケーションの観点からウェブサーバと同様に機能するように構成されてもよい。したがって、コンテンツ消費アプリケーションによるメディアマニフェストおよび／またはメディアセグメントまたはメディアセグメントの一部の要求は、例えば、ハイパーテキスト転送プロトコル（HTTP）に基づいて行われてもよい。したがって、要求はURLとして構築されてもよく、要求コンテンツは、コンテンツサーバからのHTTP要求への応答として配信されてもよい。
【0030】
マニフェストが指定され、コンテンツがセグメント化、編成、およびバージョン化され、HTTP要求が構築される方法の詳細は、HTTPを介した動的適応型ストリーミング（DASH）、HTTPライブストリーミング（HLS）、スムースストリーミング転送プロトコル（SSTP）などの特定の適応型ストリーミングプロトコルに依存し得る。以下の様々な追加の例示的な実装形態は、DASHの文脈で説明され得る。しかしながら、基礎となる原理は、HTTPを介した任意のタイプの適応型ストリーミングに適用可能である。さらに、基礎となる原理は、HTTP以外のネットワークプロトコルに基づくメディアコンテンツ要求メカニズムに適用可能である。
【0031】
HTTPを介した動的適応型ストリーミング（DASH）
適応型メディアストリーミングを実施するための1つの例示的なプロトコルは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）を含む。上述のように、DASHは、様々なプロキシおよびキャッシュを有するウェブサーバとして構成されたコンテンツサーバなどを含む、ハイパーテキスト転送プロトコル（HTTP）インフラストラクチャに基づくコンテンツ配信ネットワーク（CDN）を使用するメディアコンテンツのストリーミングを可能にする適応型ビットレートストリーミング実装形態の1つを表す。このようなコンテンツサーバは、DASHサーバと呼ばれてもよい。したがって、上述のコンテンツ消費アプリケーションは、DASHクライアントと呼ばれてもよい。
適応型メディアストリーミングを実施するための1つの例示的なプロトコルは、ハイパーテキスト転送プロトコルを介した動的適応型ストリーミング（DASH）を含む。上述のように、DASHは、様々なプロキシおよびキャッシュを有するウェブサーバとして構成されたコンテンツサーバなどを含む、ハイパーテキスト転送プロトコル（HTTP）インフラストラクチャに基づくコンテンツ配信ネットワーク（CDN）を使用するメディアコンテンツのストリーミングを可能にする適応型ビットレートストリーミング実装形態の1つを表す。このようなコンテンツサーバは、DASHサーバと呼ばれてもよい。したがって、上述のコンテンツ消費アプリケーションは、DASHクライアントと呼ばれてもよい。
【0032】
DASHは、DASHサーバからDASHクライアントへのライブストリーミングをサポートし、DASHサーバが大規模な展開におけるストリーム適応管理の追加の負荷に対処する必要がないように、DASHクライアントがストリーミングセッションを制御することを可能にする。上述のように、DASHはまた、DASHクライアントが様々なDASHサーバからのストリーミングを選択することを可能にし、これにより、DASHクライアントの利益のためにネットワークのさらなる負荷分散を達成する。DASHは、例えば、DASHクライアントのネットワーク条件および処理能力に適合するようにビットレートを変更することによって、メディアトラックの異なるメディアバージョン間での動的な切替をさらに提供する。
【0033】
DASHでは、上述のメディアマニフェストは、特にMPDと呼ばれてもよい（ただし、MPDという用語は、DASHに基づくもの以外の適応型ストリーミングシステムにおける任意のタイプのマニフェストを指すために一般に使用される）。例えば、DASHにおけるMPDは、DASHクライアントによって完全にまたは部分的にダウンロード可能であり、DASHサーバからストリーミングメディアセグメントを選択的かつ適応的に要求することによってメディアコンテンツをストリーミングするためにDASHクライアントによって使用される情報項目を提供するファイルとして構築されてもよい。
【0034】
MPDは、様々なフォーマットで構築され得る。例えば、MPDは、拡張マークアップ言語（XML）文書またはファイルの形態で構築されてもよい。MPDファイルが要求され、DASHクライアントに配信されてもよい。MPDファイルは、例えば、HTTP GET要求を介して、HTTPによって要求されてもよい。MPDファイルは、ストリーミングセッションの開始時に完全に配信されてもよい。あるいは、MPDファイルは、断片化されて部分的に配信されることが可能である。したがって、MPDファイルの一部は、ストリーミングの開始前に要求および配信されてもよく、MPDファイルの他の部分は、セッション立ち上げ遅延を低減するために、後に要求および配信されてもよい（これにより、ストリーミングは、メディアの後のセグメントに関する情報項目を待つ必要なく、より早いメディアセグメントで開始することができる）。MPDファイルはまた、ストリーミングセッション中に（例えば、必要であるがまだ取得されていないセグメント情報と共に）更新されることも可能である。
【0035】
いくつかの例示的な実装形態では、MPDファイルは、メディアコンテンツのセグメント化、セグメントの編成、およびセグメントの利用可能なバージョンを記述する。MPDは、コンテンツのアクセシビリティ機能、評価、カメラビュー、メタデータなどの表現をサポートする。DASHはまた、マルチビューのスケーラブルなコーディングされたコンテンツの配信をサポートしてもよい。
【0036】
いくつかの例示的な実装形態では、MPDファイルは、メディア消費タイムライン（例えば、ビデオコンテンツの再生時間）に沿った1つ以上の期間にわたる一連の記述を含んでもよい。1つ以上の期間の各々は、例えば、MPDファイル内の「期間」情報要素タグによって定義されてもよい。メディアコンテンツは、複数の連続する期間に編成されたMPDファイルによって示されてもよい。MPDファイルは、再生タイムラインにおける期間の各々について開始時間を識別し得る。開始時間は、メディアコンテンツの開始からの絶対開始時間として、または再生タイムラインにおける他の基準点からの相対オフセットとして定義されてもよい。
【0037】
いくつかの例示的な実装形態では、メディア期間ごとに、MPDファイルは、1つ以上の適応セットをさらに指定してもよい。メディアコンポーネントの1つ以上の異なる組み合わせ（またはサブセット）を取り込むために、異なる適応セットが指定されてもよい。例えば、ビデオと音声は異なる適応セットであり得る。異なるバージョンの音声（ステレオ音声またはマルチチャネル音声）は、異なる適応セットであってもよい。異なる言語の音声は、異なる適応セットであってもよい。特定の一例では、MPDファイルは、各期間が、1つのビデオ適応セット、およびサポートされる言語ごとに1つずつの複数の音声適応セットを含むと指定してもよい。適応セットはまた、字幕または任意のメタデータを含んでもよい。
【0038】
いくつかの例示的な実装形態では、特定の期間の適応セットは、MPDファイル内の任意の属性によって示されるグループに割り当てられてもよい。同じグループ内の適応セットは、一般に、互いに対する代替と見なされる。例えば、対応する期間のマルチメディアコンテンツのビデオデータのために任意の適応セットが選択され得るように、特定の期間のビデオデータの各適応セットは、同じグループに割り当てられることが可能である。1つの期間内のメディアコンテンツは、1つの適応セット、または適応セットの組み合わせのいずれかからのものであり得、各グループは、最大で1つの適応セットに寄与する。
【0039】
いくつかの例示的な実装形態では、各適応セットは、対応する期間の同じメディアコンポーネントの1つ以上の表現を含むとして、MPDファイルによって指定されてもよい。表現は、例えば、音声またはビデオデータのいくつかの代替的なエンコードされたバージョンのうちの1つであり得る。表現は、エンコードされたタイプによって、例えば、ビデオデータのビットレート、解像度、および／またはコーデック、ならびに音声データのビットレート、および／またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の範囲の平均ビットレートを達成するために特定の方法でエンコードされた、エンコードされたメディアデータのセクションを指すために使用され得る。いくつかの例示的な実装形態では、適応セット内の表現ごとに、MPDファイルは、ビデオ／音声タイプ、ビデオ／音声コーデック、画素単位のビデオフレーム幅、画素単位のビデオフレーム高さ、ビデオ／音声フレームレート、および帯域幅（平均エンコード済みビットレートを表す）を含むがこれらに限定されない、表現の属性を指定し得る。
【0040】
適応セットの各表現はまた、適応セットに含まれるメディアコンポーネントの組み合わせに応じて、1つ以上のメディアコンポーネントを含んでもよい。表現内の各メディアコンポーネントは、音声、ビデオ、または時刻指定テキスト（例えば、クローズドキャプション用）などの1つの個々のメディアタイプのエンコードされたバージョンに対応し得る。メディアコンポーネントは、1つの表現内の連続するメディアセグメントの境界にわたって時間的に連続的であり得る。
【0041】
いくつかの例示的な実装形態では、表現は、1つ以上のセグメントを含み得る。各表現は初期化セグメントを含むことができ、または表現の各セグメントは自己初期化されることが可能である。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含むことができる。場合によっては、初期化セグメントはメディアデータを含まない。メディアデータを含むセグメントは、時間セグメント化されたコンテンツを表し得る。異なる表現間のセグメントは、時間的に整合されてもよい。メディアセグメントごとに、MPDファイルは固有の識別子を含み得る。このような識別子は、ベースURL、ベースURN、またはベースユニフォームリソース識別子（URI）と組み合わされると、メディアセグメントのネットワークの場所を表す固有のURL、URN、またはURIを形成してもよく、これは、このメディアセグメントのHTTP要求に含まれる場合があり、配信のために要求されたセグメントを位置特定するためにコンテンツサーバによって使用され得る。
【0042】
例えば、メディアセグメントを要求するためのURLは、「http」または「https」の決まったスキームで＜absolute－URI＞として定義されることが可能であり、ことによると、URLと一緒に範囲属性が提供される場合、バイト範囲によってさらに補完され得る。バイト範囲は、セグメント内のバイトの連続する範囲を識別するために表現されることが可能である。
【0043】
いくつかのさらなる例示的な実装形態では、サブ表現は、例えばサブ表現要素／インジケータを使用して、通常の表現に埋め込まれる（または含まれる）ものとしてMPDファイルにおいて指定または記述されてもよい。サブ表現要素は、表現に埋め込まれた1つまたはいくつかのメディアコンテンツコンポーネントの特性を記述するために使用され得る。例えば、サブ表現要素は、埋め込み音声コンポーネント（例えば、コーデック、サンプリングレートなど）、埋め込み字幕（例えば、コーデック）の特性を記述するために使用されてもよく、またはサブ表現要素は、何らかの埋め込み低品質ビデオ層（例えば、何らかのより低いフレームレートなど）を記述するために使用されてもよい。サブ表現および表現要素は、いくつかの共通の属性および要素を共有することができる。
【0044】
いくつかの例示的な実装形態では、DASHクライアントは、DASHサーバからMPDファイルの全体または一部にアクセスし、ダウンロードし、要求するように構成されてもよい。すなわち、DASHクライアントは、ライブストリーミングセッションを開始する際に使用するためのMPDファイルを取得し得る。MPDファイル、および表現の選択に基づいて、DASHクライアントは、サーバ上で利用可能な最新のセグメントが何かを判定することと、次のセグメントおよび場合により将来のセグメントのセグメント可用性開始時間を判定することと、セグメントの再生をいつ開始するかを判定することと、新しいMPDファイルをいつ取得／フェッチ／要求するかを判定することと、を含むいくつかのさらなる決定を行うことができる。
【0045】
いくつかの例示的な実装形態では、MPDは、非周期的な情報をDASHクライアントまたはDASHアプリケーションにシグナリングするために、DASHイベントに関する情報をさらに含んでもよい。イベントは、ある持続時間を有する特定のメディア表現時間で開始して、時刻指定されてもよい。追加的または代替的に、イベント情報は、広告挿入キューなど、メディア表現の再生中の特定の時間に関連付けられたメディアプレーヤのための制御メッセージを含んでもよい。ストリーミング中に挿入され得るメディアは、広告サーバなどの別個のサーバから提供され得る。メディア表現とは別にMPDによってイベントをシグナリングすることに加えて、イベントはまた、1つまたはいくつかの選択された適応セット内の選択されたメディア表現のみにおいて、またはすべての表現において、帯域内で多重化されてもよい。
【0046】
例示的なDASHシステム200が図2に示されている。DASHシステム200は、ネットワーク250によって接続された、1つ以上の集中型または分散型コンテンツサーバ210および情報処理装置230を含み得る。DASHシステム（200）はまた、1つ以上の広告サーバ220などの1つ以上の補足コンテンツサーバも含み得る。
【0047】
コンテンツサーバ210は、主要コンテンツ（例えば、メインプログラム）およびコンテンツのためのMPDを情報処理装置230に提供し得る。マニフェストファイルは、MPD生成器214によって生成されることが可能である。主要コンテンツおよびマニフェストファイルは、同じサーバまたは異なるサーバから提供されることが可能である。
【0048】
情報処理装置230は、コンテンツサーバ210と直接通信するDASHクライアント232を含み得る。情報処理装置230のDASHアプリケーション234によって制御されるDASHクライアント232は、MPDを要求および／または受信してもよく、MPDに基づいてコンテンツサーバ210のHTTPサーバ212からメインコンテンツを要求および取得してもよい。MPDは、DASHクライアント232によって処理され得る。さらに、DASHクライアント232は、広告サーバ220から広告コンテンツを、またはDASHイベントに応じて1つ以上の補足コンテンツサーバから他のコンテンツ（例えば、インタラクティブコンテンツ）を取得してもよい。メインコンテンツおよび広告コンテンツは、DASHクライアント232およびDASHアプリケーション234によって処理され、情報処理装置230の表示デバイス236上の表示のために出力されることが可能である。表示デバイス236は、情報処理装置230に組み込まれてもよく、または外付けであってもよい。さらに、DASHクライアント232は、1つ以上の時刻指定メタデータトラックから他のイベント情報を抽出し、抽出されたイベント情報をさらなる処理のためにDASHアプリケーション234に送信してもよい。DASHアプリケーション234は、例えば、イベント情報に基づいて補足コンテンツを表示するように構成されてもよい。
【0049】
DASHクライアント232のための一例が図3に示されている。図3に示されるように、例示的なDASHクライアント232は、DASHアクセスエンジン304と、選択ロジック302と、メディアエンジン306および308とを含み得る。DASHアクセスエンジン302は、例えば、ストリーミングメディアのMPDの一部または全体を取得し、動的に要求されたストリーミングメディアのセグメントデータを要求および取得し、MPD DASHイベントに従って補足メディア（広告）を要求するために、コンテンツサーバと通信するように構成されてもよい。選択ロジック304は、適応セットおよび表現の選択を含む、要求すべき次の1つ以上のセグメントを決定するように構成されてもよい。このような決定は、例えば、ユーザ命令によって、ならびにネットワーク帯域幅およびスループットなどの他のリアルタイム情報によって、決定され得る。メディアエンジン306は、メディアセグメントのフォーマット（例えば、MPEG）およびメインメディア出力を生成するためのメディアセグメントのタイミングに従って、DASHアクセスエンジン302によって受信されたセグメントデータを処理するように構成され得る。メディアエンジン308は、例えばメインメディア出力に挿入され得る補足メディア出力（広告など）を生成するために、DASHアクセスエンジン302からの時刻指定DASHイベントに関連付けられたメディアコンテンツを処理するように構成されてもよい。
【0050】
要求のパラメータ化
上述のように、動的適応型ストリーミングでは、DASHクライアントなどのストリーミングクライアントとコンテンツサーバとの間の相互作用は、HTTPを介して通信ネットワークを通じて通信され得る。したがって、コンテンツサーバは本質的に、ストリーミングクライアントによってウェブサーバと見なされ得る。例えば、ストリーミングクライアントによるコンテンツサーバからの様々な情報項目の要求は、URLの宛先にアドレス指定されたHTTP GETメソッドを使用して行われてもよい。
上述のように、動的適応型ストリーミングでは、DASHクライアントなどのストリーミングクライアントとコンテンツサーバとの間の相互作用は、HTTPを介して通信ネットワークを通じて通信され得る。したがって、コンテンツサーバは本質的に、ストリーミングクライアントによってウェブサーバと見なされ得る。例えば、ストリーミングクライアントによるコンテンツサーバからの様々な情報項目の要求は、URLの宛先にアドレス指定されたHTTP GETメソッドを使用して行われてもよい。
【0051】
ストリーミングクライアントによるこのような要求は、様々な異なる目的のために行われ、別個の情報項目を要求するように設計されてもよい。例えば、HTTP GET要求は、1つ以上のメディアセグメントまたは1つ以上のメディアセグメントの一部を取得するために使用されてもよい。他の例として、HTTP GET要求は、MPD情報を（例えば、フェッチ時に、またはその後ストリーミング中に）取得するため、チェーニングされたMPDを判定するため、代替MPDの予備を要求するため、Xlink解決策を要求するため、様々なDASHコールバックイベントをトリガするため、および／またはセッションベース文書（SBD）を要求するために、使用され得る。
【0052】
メディアセグメントのHTTP GET要求のいくつかの実装形態では、例えば、MPDは、適応セットから特定のメディアセグメントを要求するためにベースURLからURLを構築するためのテンプレートを提供してもよい。このようなテンプレートは、例えば、特定のメディアセグメントまたは特定のメディアセグメントのバイト範囲を要求するためのより完全なURLを生成するためにベースURLが追加される方法を指定し得る。例えば、テンプレートは、ベースURLに、セグメントインデックス、バイト範囲、および／またはビットレート（適応セット内のメディアの特定の表現と相関する）が特定の順序およびフォーマットで追加されることを指定してもよい。
【0053】
いくつかのさらなる例示的な実装形態では、HTTP GET要求は、コンテンツサーバがその反応／応答を要求に適合させることができるように、HTTP要求にさらに挿入され得るパラメータのセットに関連付けられてもよい。パラメータのセットが挿入されるべきか否か、およびどのパラメータが挿入されるべきかもまた、MPDにおいて指定され、ストリーミングクライアントにシグナリングされ得る。
【0054】
例えば、メディアセグメントのHTTP要求では、パラメータ化記述子は、メディアセグメントのためにストリーミングクライアントがHTTP GET要求に挿入するとコンテンツサーバが予想するパラメータのセットにメディアセグメント要求が関連付けられ得ることをストリーミングクライアントにシグナリングするために、MPDに任意選択的に含まれてもよい。パラメータ化記述子は、どのパラメータがストリーミングクライアントによって（1つまたは複数の）メディアセグメントのHTTP GET要求に挿入されると予想されるか、これらのパラメータがどのように生成されるべきか、およびパラメータ挿入のフォーマットならびに順序を指定するようにMPD内で構成され得る1つ以上の要素を含み得る。
【0055】
これらのパラメータのいくつかは静的であり得るが、いくつかの実装形態では、MPD内のパラメータ記述子において指定されたいくつかの他のパラメータは動的であり得、その生成のためにクライアント側の計算を必要とする。したがって、このようなタイプの動的パラメータは、ストリーミングのためのさらなる適応性を提供する。例えば、MPDは、ストリーミングクライアントの地理的位置を表すメディアセグメント要求のためのパラメータを指定してもよい。このようなパラメータは、メディアセグメントのHTTP GET要求に挿入されると、要求されたメインメディアセグメントおよび適切な適応的に挿入可能なローカルメディア（例えば、ローカル広告）の最も近いコンテンツリポジトリを識別するために、コンテンツサーバによって有利に使用され得る。こうして、柔軟で動的なパラメータ化メカニズムが提供され得る。このような要求パラメータは、ストリーミングクライアントによって名－値ペアとしてインスタンス化および構築されてもよい。
【0056】
上記のメディアセグメント要求のためのパラメータ化記述子は、「UrlQueryInfoType」のMPDデータ構造と呼ばれてもよい。「UrlQueryInfo」と呼ばれる、MPDにおけるこのようなタイプのインスタンス化されたデータ構造は、メディアセグメントのHTTP GET要求において上述されたような静的および動的パラメータ化メカニズムを提供するために使用される、様々な属性または記述子を含み得る。いくつかのさらなる例示的な実装形態では、このような静的および動的パラメータ化メカニズムは、メディアセグメントの要求に加えて、他のタイプのHTTP要求にも拡張され得る。拡張データ構造タイプの例示的な構文が指定されてもよく、様々なタイプのHTTP GET要求のパラメータ化をシグナリングおよび記述するための対応するデータ構造を含むMPDをインスタンス化するために使用されてもよい。このような拡張データ構造タイプは、「ExtendedUrlInfoType」と呼ばれてもよい。「ExtendedUrlInfo」と呼ばれるこのようなタイプのデータ構造は、インスタンス化されてMPDに含まれる場合、拡張パラメータ化が適用されることをストリーミングクライアントにシグナリングしてもよい。「ExtendedUrlInfoType」のデータ構造の例示的な構文は、表1に示されるような様々な例示的な属性または記述子を含み得る。
【0057】
【表1-1】
【表1-2】
【0058】
表1の例示的な構文では、「ExtendedUrlInfoType」のMPDデータ構造は、MPDでインスタンス化されてもよい。「ExtendedUrlInfo」と呼ばれるこのようなインスタンス化されたデータ構造は、様々なタイプのHTTP Get要求のパラメータ化記述子としてMPDにおいて使用されてもよく、表1に従って、いくつかのデータ要素または記述子を含み得る。「＠include InRequests」と呼ばれる第1のデータ要素は、ストリーミングクライアントによって提出されたときに、HTTP GET要求のタイプの事前定義されたリストのうちのどれがパラメータに挿入されるコンテンツサーバによって予想されるかをストリーミングクライアントに通知するために含まれ得る。要求タイプのリストは、パラメータ化されることが可能なすべてのHTTP GET要求タイプを含み得る。例えば、リストは、（1）メディアセグメント要求、（2）xlink要求タイプ（情報をフェッチするための遠隔位置の参照のため）、（3）MPD要求タイプ（MPDをフェッチするため）、（4）コールバック要求タイプ（コールバックイベントをトリガするため）、（5）チェーニング要求タイプ（MPDチェーニングを要求するため）、および（6）予備要求タイプ（代替MPDを要求するため）を含み得る。
【0059】
表1で指定された例示的なフォーマットでは、インスタンス化されたパラメータ化記述子の「＠includeInRequests」要素の値は、様々なタイプのHTTP GET要求を表すキー文字列（またはキー）の任意の組み合わせの余白付き連結リストであってもよい。例示的な実装形態では、上記の6つのパラメータ化されたHTTP GET要求タイプは、「segment」、「xlink」、「mpd」、「callback」、「chaining」、および「fallback」のキー文字列によって表され得る。例えば、「＠include InRequests＝segment mpd」として指定されたインスタンス化された「ExtendedUrlInfo」の下のデータ要素は、様々なHTTP GET要求タイプのうち、セグメント要求およびMPD要求がそれに関連付けられたパラメータと共に挿入されるべきであることをストリーミングクライアントにシグナリングする。「＠includeInRequests」のデフォルト値は、「ExtendedUrlInfo」はインスタンス化されるが「＠includeInRequests」データ要素は存在しないときに提供される（例えば、「segment」）。
【0060】
「＠headerParamSource」および「＠sameOriginOnly」など、「ExtendedUrlInfo」の他のデータ要素も含まれ得る。上記の「UrlQueryInfo」パラメータ化記述子の他のデータ要素と共に、ストリーミングに対して、パラメータのソース、および特定の要求の最終パラメータがどのように構築されるべきかを指定する。いくつかの例示的な詳細が、上記の表1に提供されている。
【0061】
表1で指定された例示的な実装形態では、特定の要求のパラメータは、ストリーミングクライアントによって生成または出力されると、HTTP GET要求におけるクエリパラメータとして使用され得る。いくつかの他の実装形態では、「ExtHttpHeaderInfoType」と呼ばれる、「ExtendedUrlInfoType」と並列の他のパラメータ化記述子タイプが指定されてもよい。このようなタイプのパラメータ化記述がインスタンス化されると、様々な要求のパラメータは、上述のように同様に構築され得るが、ストリーミングクライアントでHTTPヘッダに出力されてもよい。
【0062】
やはり表1の例示的な実装形態に示されるように、「＠includeInRequests」の値としての選択肢は、特定の文字列、例えばセグメントHTTP GET要求の「segment」およびxlink HTTP GET要求の「xlink」でハードコードされる。追加のタイプの要求がリストに追加されるたびに、表1の構文指定が更新される必要があるだろう。例えば、パラメータ化がSBD文書のHTTP要求に拡張されるとき、表1の構文定義は、表2に示されるように更新される必要があり得る。
【0063】
【表2-1】
【表2-2】
【0064】
したがって、表1および表2によって示される上記の実装形態は、拡張可能ではない場合がある。いくつかの他の例示的な実装形態では、表3に示されるように、拡張可能なアプローチが採用され得る。新しいタイプの要求が導入されるとき、上記の文脈では、アプローチまたはスキームは拡張可能と見なされ、パラメータ化構文は更新される必要がない。表3に示されるように、拡張可能パラメータ化を実現するために、「＠includeInRequests」のハードコードされた文字列値を使用するのではなく、URI文字列が代わりに使用されてもよい。
【0065】
【表3-1】
【表3-2】
【0066】
表3に示されるように、「urn：mpeg：dash：annexi：parameters：2022」などのURNは、URN／URLスキームの（1人または複数の）オーナーによって定義された任意の部分文字列と共に定義および使用され得る。例えば、以下の文字列は、パラメータ化の所望のHTTP GET要求をシグナリングするために、URN／URLと共にURN／URLオーナーによって定義されてもよい。
1）「segment」（全セグメント要求）、
2）「xlink」（全XLink解決策要求）、
3）「mpd」（全MPD要求）、
4）「callback」（DASHコールバックイベントによってトリガされる全要求）、
5）「chaining」（MPDチェーニングの要求）、
6）「fallback」（代替MPDの要求）、
7）「sbd」（SBD文書の要求）。
1）「segment」（全セグメント要求）、
2）「xlink」（全XLink解決策要求）、
3）「mpd」（全MPD要求）、
4）「callback」（DASHコールバックイベントによってトリガされる全要求）、
5）「chaining」（MPDチェーニングの要求）、
6）「fallback」（代替MPDの要求）、
7）「sbd」（SBD文書の要求）。
【0067】
例えば、セグメントおよびMPDのHTTP GET要求にパラメータを追加するための属性の値は以下としてもよい。＠includeInRequests＝
"urn：mpeg：dash：annexi：parameters：2022 segment mpd"
"urn：mpeg：dash：annexi：parameters：2022 segment mpd"
【0068】
文字列定義のリストは、表3の仕様を修正する必要なく、URN／URLオーナーによって異なるタイプのHTTP GET要求に拡大または拡張されることが可能である。
【0069】
表3と表2との互換性を維持するための他の例示的な実装形態が、表4に示されている。
【0070】
【表4-1】
【表4-2】
【0071】
表4の例示的なスキームでは、表2のものなどのパラメータ化のための一般的なHTTP GET要求タイプを表す「＠ includeInRequests」のハードコードされた文字列値が指定され得る。加えて、「urn：mpeg：dash：annexi：parameters：2022」などのURNは、新しいタイプのHTTP GET要求を表すURN／URLスキームの（1人または複数の）オーナーによって定義された任意の部分文字列と共に定義および使用されてもよい。例えば、セグメントおよびMPDのHTTP GET要求ならびにパラメータ化を必要とすると指定された新しいタイプのHTTP GET要求（「newRequest」）にパラメータを追加するための属性／記述子の値は、以下としてもよい。
＠includeInRequests＝「segment」"mpd"
"urn：mpeg：dash：annexi：parameters：2022 newReques"
＠includeInRequests＝「segment」"mpd"
"urn：mpeg：dash：annexi：parameters：2022 newReques"
【0072】
図4は、コンテンツサーバからのDASH適応型ストリーミングメディアのHTTP要求の拡張可能パラメータ化のための例示的なデータおよび論理フロー400を示す。ステップ402において、ストリーミングメディアデバイスは、DASHサービスプロバイダに、DASHストリーミングメディアの初期要求を送信し、コンテンツサーバからDASHストリーミングメディアのマニフェストを受信し得る。ステップ404において、ストリーミングメディアデバイスは、マニフェストを解析し、HTTP要求に関連付けられたパラメータ化記述子を抽出し得る。ステップ406において、ストリーミングメディアデバイスは、パラメータ化記述子から、ユニフォームリソース識別子と、キーのセットのうちの1つ以上とを識別してもよく、ユニフォームリソース識別子は、HTTP要求の拡張可能パラメータ化のためのパラメータ化スキームにリンクしている。ステップ408において、ストリーミングメディアデバイスは、パラメータ化スキームおよびキーのセットのうちの1つ以上に従って、拡張可能パラメータ化に対応する1つ以上のタイプのHTTP要求を決定し得る。ステップ410において、コンテンツサーバ宛ての、1つ以上のタイプのHTTP要求に属するHTTP要求について、ストリーミングメディアデバイスは、マニフェストに従ってパラメータのセットを構築し得る。最後に、ステップ412において、ストリーミングメディアデバイスは、パラメータのセットをHTTP要求に挿入し得る。
【0073】
上述された技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実装され、1つ以上のコンピュータ可読媒体に物理的に記憶されることが可能である。例えば、図5は、開示されている主題の特定の実施形態を実施するのに適したコンピュータシステム（500）を示す。
【0074】
コンピュータソフトウェアは、1つ以上のコンピュータ中央処理装置（CPU）およびグラフィック処理装置（GPU）などによって直接的に、または解釈およびマイクロコードの実行などを通して実行され得る命令を含むコードを生成するために、アセンブリ、コンパイル、リンキング、または同様のメカニズムを受け得る任意の適切なマシンコードまたはコンピュータ言語を使用してコーディングされ得る。
【0075】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはコンピュータのコンポーネント上で実行されることが可能である。
【0076】
コンピュータシステム（500）に関して図5に示されているコンポーネントは、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関する限定を示唆することを意図されていない。また、コンポーネントの構成は、コンピュータシステム（500）の例示的な実施形態に示されているコンポーネントのいずれか1つまたは組み合わせに関する依存性または要件を有するものとして解釈されるべきではない。
【0077】
コンピュータシステム（500）は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、オーディオ入力（声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）を介した、1人以上の人間ユーザによる入力に応答し得る。ヒューマンインターフェースデバイスはまた、オーディオ（例えば、音声、音楽、周囲音）、画像（例えば、走査画像、静止画像カメラから取得される写真画像）、ビデオ（二次元ビデオ、立体ビデオを含む三次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアを取り込むために使用されることも可能である。
【0078】
入力ヒューマンインターフェースデバイスは、キーボード（501）、マウス（502）、トラックパッド（503）、タッチスクリーン（510）、データグローブ（図示せず）、ジョイスティック（505）、マイク（506）、スキャナ（507）、カメラ（508）のうちの1つ以上を含んでもよい（それぞれ1つのみが図示されている）。
【0079】
コンピュータシステム（500）はまた、特定のヒューマンインターフェース出力デバイスを含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、および匂い／味を介して、1人以上の人間のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン（510）、データグローブ（図示せず）、またはジョイスティック（505）による触覚フィードバック、ただし入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、音声出力デバイス（例えば、スピーカ（509）、ヘッドフォン（図示せず））、視覚出力デバイス（例えば、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含み、それぞれがタッチスクリーン入力機能を有するかまたは有さず、それぞれが触覚フィードバック機能を有するかまたは有さず、これらのうちのいくつかは、ステレオ出力などの手段を介して二次元視覚出力または三次元超出力を出力可能であるスクリーン（510）、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ、およびスモークタンク（図示せず））、およびプリンタ（図示せず）を含んでもよい。
【0080】
コンピュータシステム（500）はまた、人間がアクセス可能なストレージデバイス、およびそれらに関連した媒体、例えば、CD／DVDなどの媒体（521）を伴うCD／DVD ROM／RW（520）を含む光学媒体、サムドライブ（522）、リムーバブルハードドライブまたはソリッドステートドライブ（523）、テープやフロッピーディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの特殊なROM／ASIC／PLDベースのデバイスなどを含むこともできる。
【0081】
当業者はまた、本開示の主題に関連して使用される「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、または他の一時的な信号を包含しないことも理解すべきである。
【0082】
コンピュータシステム（500）は、1つ以上の通信ネットワーク（555）に対するインターフェース（554）をさらに含むことができる。ネットワークは、例えば、無線、有線、光であってもよい。ネットワークはさらに、ローカル、ワイドエリア、メトロポリタン、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワークの例は、イーサネットなどのローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルテレビ、衛星テレビ、および地上波放送テレビを含む有線テレビまたは無線広域デジタルネットワーク、CAN busを含む車両用および産業用などを含む。特定のネットワークは一般に、特定の汎用データポートまたは周辺バス（549）（例えば、コンピュータシステム（500）のUSBポートなど）に取り付けられた外部ネットワークインタフェースアダプタを必要とし、他のものは一般に、以下に説明するようなシステムバスへの取り付けによってコンピュータシステム（500）のコアに統合される（例えば、PCコンピュータシステムへのイーサネットインタフェースまたはスマートフォンコンピュータシステムへのセルラネットワークインタフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム（500）は他のエンティティと通信することができる。このような通信は、例えば、ローカルもしくは広域デジタルネットワークを使用して、他のコンピュータシステムに対して、一方向、受信専用（例えば、テレビ放送）、一方向送信専用（例えば、CANbusデバイスから特定のCANbusデバイス）、または双方向であり得る。特定のプロトコルおよびプロトコルスタックは、上述したように、それらのネットワークおよびネットワークインターフェースの各々で使用され得る。
【0083】
前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム（500）のコア（540）に接続されることが可能である。
【0084】
コア（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などを含む。
【0085】
CPU（541）、GPU（542）、FPGA（543）、およびアクセラレータ（544）は、前述したコンピュータコードを作成できるいくつかの命令を、組み合わせて実行することができる。そのコンピュータコードは、ROM（545）またはRAM（546）に記憶されることが可能である。移行データはRAM（546）に記憶され得るが、恒久的データは、例えば内部大容量ストレージ（547）に記憶され得る。キャッシュメモリを使用することによって、任意のメモリ装置に素早く記憶し検索することが可能になり、1つ以上のCPU（541）、GPU（542）、大容量ストレージ（547）、ROM（545）、RAM（546）などに密接に関連付けられることが可能である。
【0086】
コンピュータ可読媒体は、様々なコンピュータ実装動作を行うためのコンピュータコードを有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものとすることができ、またはコンピュータソフトウェア技術の当業者に周知の利用可能な種類のものとすることができる。
【0087】
非限定的な例として、アーキテクチャ、具体的にはコア（540）を有するコンピュータシステム（500）は、プロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）が1つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行する結果として、機能を提供することができる。このようなコンピュータ可読媒体は、前述のようなユーザアクセス可能な大容量ストレージ、ならびにコア内部大容量ストレージ（547）またはROM（545）などの非一時的な性質のものであるコア（540）の特定のストレージと関連付けられた媒体とすることができる。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶され、コア（540）によって実行され得る。コンピュータ可読媒体は、特定の必要性に応じて、1つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア（540）、特にその中のプロセッサ（CPU、GPU、FPGAなどを含む）に、RAM（546）に記憶されているデータ構造を定義すること、ソフトウェアで定義された処理に従ってそのようなデータ構造を変更することを含む、本明細書で説明された特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。これに加えて、または代替として、コンピュータシステムは、回路においてハードワイヤードされるか、または他の方法で具現化された論理の結果として機能を提供することができ（例えば、アクセラレータ（544））、この回路は、ソフトウェアの代わりに、またはソフトウェアと共に動作して、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行することができる。ソフトウェアへの言及は、必要に応じて、論理を包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のための論理を具体化する回路、またはその両方を包含することができる。本開示は、ハードウェアとソフトウェアの任意の適切な組合せを包含する。
【0088】
本開示はいくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換、および様々な代替の均等物が存在する。したがって、当業者は、本明細書に明示的に示されていないかまたは記載されていないが、本開示の原理を具現化し、したがって本開示の趣旨および範囲内にある多数のシステムおよび方法を考案することができることが理解されよう。
【符号の説明】
【0089】
100 コンテンツ配信システム
110 コンテンツサーバ
120 情報処理装置
130 通信ネットワーク
200 DASHシステム
210 コンテンツサーバ
212 HTTPサーバ
214 MPD生成器
220 広告サーバ
230 情報処理装置
232 DASHクライアント
234 DASHアプリケーション
236 表示デバイス
250 ネットワーク
302 選択ロジック
304 DASHアクセスエンジン
306 メディアエンジン
308 メディアエンジン
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 スピーカ
510 タッチスクリーン
520 CD／DVD ROM／RW
521 CD／DVD
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 選択ロジック
304 DASHアクセスエンジン
306 メディアエンジン
308 メディアエンジン
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
505 ジョイスティック
506 マイク
507 スキャナ
508 カメラ
509 スピーカ
510 タッチスクリーン
520 CD／DVD ROM／RW
521 CD／DVD
522 サムドライブ
523 リムーバブルハードドライブまたはソリッドステートドライブ
540 コア
541 中央処理装置（CPU）
542 グラフィックス処理ユニット（GPU）
543 フィールドプログラマブルゲートエリア（FPGA）
544 ハードウェアアクセラレータ
545 読出し専用メモリ（ROM）
546 ランダムアクセスメモリ
547 内部大容量ストレージ
548 システムバス
549 周辺バス
550 グラフィックスアダプタ
554 インターフェース
555 通信ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【手続補正書】
【提出日】2024-05-24
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
メディアストリーミングデバイスが実行する、コンテンツサーバからのHTTPを介した動的適応型ストリーミング（DASH）ストリーミングメディアのHTTP要求の拡張可能パラメータ化のための方法であって、DASHサービスプロバイダに、前記DASHストリーミングメディアの初期要求を送信するステップと、
前記コンテンツサーバから前記DASHストリーミングメディアのマニフェストを受信するステップと、
前記マニフェストを解析し、前記HTTP要求に関連付けられたパラメータ化記述子を抽出するステップと、
前記パラメータ化記述子から、ユニフォームリソース識別子およびキーのセットのうちの1つ以上を識別するステップであって、前記ユニフォームリソース識別子は前記HTTP要求のための前記拡張可能パラメータ化のパラメータ化スキームとリンクしている、ステップと、
前記パラメータ化スキームおよび前記キーのセットのうちの前記1つ以上に従って前記拡張可能パラメータ化に対応する1つ以上のタイプのHTTP要求を決定するステップと、
前記コンテンツサーバ宛てであり、前記1つ以上のタイプのHTTP要求に属するHTTP要求について、前記マニフェストに従ってパラメータのセットを構築するステップと、
前記HTTP要求に前記パラメータのセットを挿入するステップと
を含む、方法。
【請求項2】
前記HTTP要求はHTTP GET要求を含む、請求項1に記載の方法。
【請求項3】
前記ユニフォームリソース識別子は、ユニフォームリソースロケータ（URL）またはユニフォームリソース名（URN）を含む、請求項2に記載の方法。
【請求項4】
前記1つ以上のタイプのHTTP要求は、メディアセグメントHTTP要求タイプ、
マニフェストHTTP要求タイプ、
xlink HTTP要求タイプ、
コールバックイベントをトリガするコールバックHTTP要求タイプ、または
マニフェストチェーニングのためのチェーニングHTTP要求、のうちの少なくとも1つを含む、請求項3に記載の方法。
【請求項5】
前記パラメータ化スキームは、前記キーのセットの定義を含む、請求項2に記載の方法。
【請求項6】
パラメータ化を必要とする前記1つ以上のタイプのHTTP要求を決定するステップは、前記1つ以上のタイプのHTTP要求を識別するために、前記マニフェストに含まれる前記キーのセットのうちの前記1つ以上および前記キーのセットの前記定義を使用するステップを含む、請求項5に記載の方法。
【請求項7】
前記パラメータ化記述子は第1のパラメータ化選択文字列を含み、前記第1のパラメータ化選択文字列は、前記ユニフォームリソース識別子およびこれに続く前記キーのセットのうちの前記1つ以上を含む、請求項2に記載の方法。
【請求項8】
前記パラメータ化記述子は第2のパラメータ化選択文字列をさらに含み、前記第2のパラメータ化選択文字列は、パラメータ化の事前定義されたタイプのHTTP GET要求の選択を表すハードコードされた識別文字列を含む、請求項7に記載の方法。
【請求項9】
前記パラメータのセットのうちの少なくとも1つは、動的なものとして前記マニフェストによって指定される、請求項2に記載の方法。
【請求項10】
動的であると指定された前記パラメータのセットのうちの前記少なくとも1つは、前記メディアストリーミングデバイスによる適応計算を必要とする、請求項9に記載の方法。
【請求項11】
請求項1～10のいずれか一項に記載の方法を行うように構成された、メディアストリーミングデバイス。
【請求項12】
コンピュータに、請求項1～10のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。
【国際調査報告】