特許7407308セッションベースＤＡＳＨ動作を使用したセッションベース記述ＵＲＬのカスタマイズ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-20
(45)【発行日】2023-12-28
(54)【発明の名称】セッションベースＤＡＳＨ動作を使用したセッションベース記述ＵＲＬのカスタマイズ
(51)【国際特許分類】
H04N 21/235 20110101AFI20231221BHJP
H04N 21/6332 20110101ALI20231221BHJP
【ＦＩ】
H04N21/235
H04N21/6332
【請求項の数】
11
(21)【出願番号】P 2022564775
(86)(22)【出願日】2022-03-25
(65)【公表番号】
(43)【公表日】2023-06-19
(86)【国際出願番号】 US2022021885
(87)【国際公開番号】W WO2022225644
(87)【国際公開日】2022-10-27
【審査請求日】2022-10-25
(31)【優先権主張番号】63/177,788
(32)【優先日】2021-04-21
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/702,874
(32)【優先日】2022-03-24
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ソダガァ，イラジ
【審査官】富樫 明
(56)【参考文献】
【文献】米国特許出願公開第２０２１／００９９５１０（ＵＳ，Ａ１）
【文献】特表２０１５－５３０００２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１９／０３９４５３７（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
(57)【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサが実行する、DASH(Dynamic Adaptive Streaming over Hypertext Transfer Protocol)ストリーミングセッションにおけるビデオコンテンツを提供するための方法であって、前記DASHストリーミングセッションの複数のセッションベース記述(SBD)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL)を生成するように先行セッションベース記述(PreSBD)クライアントに命令する前記DASHストリーミングセッションのPreSBD情報を取得するステップと、
前記PreSBDクライアントをインスタンス化し、PreSBD記述子情報を渡すステップと、
前記DASHストリーミングセッションの前記複数のSBD記述子からの第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成を制御するステップと、
前記カスタマイズされたSBDドキュメントURLに基づいて第1のSBDクライアントを起動し、前記第1のSBD記述子を前記第1のSBDクライアントに渡すステップと
を含む方法。
【請求項2】
前記第1のSBD記述子及び前記カスタマイズされたSBDドキュメントURLに基づいてセグメントユニフォームリソースロケータ(URL)の生成を制御し、少なくとも前記セグメントURLを変更することによって、前記ビデオコンテンツのセグメントの要求を処理するステップと、前記変更されたセグメントURLに基づいて前記ビデオコンテンツの前記セグメントを提供するステップと
を更に含む、請求項１に記載の方法。
【請求項3】
前記DASHストリーミングセッションの前記複数のSBD記述子は、PreSBD記述子情報を有する同じメディアプレゼンテーション記述(MPD)要素内のSBD記述子、又は前記PreSBD記述子情報を有する前記MPD要素よりも下位レベルのMPD要素内のSBD記述子を含む、請求項１又は２に記載の方法。
【請求項4】
前記PreSBD記述子情報は、「sbd」の値を有する@urlclass属性を含む、請求項１乃至３のうちいずれか１項に記載の方法。
【請求項5】
前記PreSBD記述子情報は、前記カスタマイズされたSBDドキュメントURLの生成の対象となる一種のハイパーテキスト転送プロトコル(HTTP)GET要求を含む、請求項１乃至４のうちいずれか１項に記載の方法。
【請求項6】
複数のPreSBD記述子情報は、メディアプレゼンテーション記述(MPD)要素に存在しない、請求項１乃至５のうちいずれか１項に記載の方法。
【請求項7】
前記PreSBD記述子情報は、前記PreSBD記述子情報を有するメディアプレゼンテーション記述(MPD)要素の下位レベルの要素に存在しない、請求項１乃至６のうちいずれか１項に記載の方法。
【請求項8】
前記PreSBDクライアントは、前記第1のSBDクライアントを起動する前又はいずれかの非PreSBDクライアントを起動する前にインスタンス化される、請求項１乃至７のうちいずれか１項に記載の方法。
【請求項9】
前記DASHストリーミングセッションの前記複数のSBD記述子に関連するそれぞれのSBDドキュメントURLは、前記ビデオコンテンツのセグメントのそれぞれの要求を処理する前に、前記PreSBDクライアントに送信される、請求項１乃至８のうちいずれか１項に記載の方法。
【請求項10】
コンピュータプログラムコードを記憶するように構成された少なくとも1つのメモリと、前記コンピュータプログラムコードにアクセスして前記コンピュータプログラムコードにより命令される通り動作するように構成された少なくとも1つのプロセッサと
を含む装置であって、
前記コンピュータプログラムコードは、
前記少なくとも1つのプロセッサに、請求項１乃至９のうちいずれか１項に記載の方法を実行させる、装置。
【請求項11】
少なくとも1つのプロセッサによって実行されると、前記少なくとも1つのプロセッサに、請求項１乃至９のうちいずれか１項に記載の方法を実行させるコンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【0001】
［関連出願への相互参照］
本出願は、2021年4月21日に出願された米国仮特許出願第63/177,788号に基づくものであり、その優先権を主張しており、その開示の全内容を参照により援用する。
本出願は、2021年4月21日に出願された米国仮特許出願第63/177,788号に基づくものであり、その優先権を主張しており、その開示の全内容を参照により援用する。
【0002】
近年、MPEG(Moving Picture Experts Group)は、セッションベースDASH動作のためのDASH(Dynamic Adaptive Streaming over HTTP)標準化への関心の高まりを示している。DASHの標準化を議論するセッションの中で、メディアプレゼンテーション記述(MPD, media presentation description)は全てのクライアントについて一般的であるが、クライアントはセッションベース記述(SBD, session-based description)として知られるサイドファイルを取得することがあり、これはクライアントがそのセッションに特有のMPDを作成するための指示を提供する。
【0003】
セッションベースDASH動作は、セッション毎に、場合によってはクライアント毎にMPDをカスタマイズするための重要な手法である。現在の設計は、1つ以上のSBDドキュメントが様々な要求のユニフォームリソースロケータ(URL, Uniform Resource Locator)部分又はクエリに適用されることを可能にする。しかし、現在の設計は、SBDドキュメントがSBDドキュメントを要求するクエリに適用されることを可能にしていない。すなわち、現在の設計は、SBD記述子において使用され得るSBDドキュメントURLのカスタマイズを可能にしていない。同じマニフェスト内でSBDドキュメントURLをカスタマイズできる必要がある。
【発明の概要】
【0004】
本開示の実施形態によれば、ビデオコンテンツを提供するための方法は、セッションの複数のセッションベース記述(SBD, session-based description)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL, uniform resource locator)を生成するように先行セッションベース記述(PreSBD, pre-session-based description)クライアントに命令するセッションのPreSBD情報を取得するステップと、PreSBDクライアントをインスタンス化し、PreSBD記述子情報を渡すステップと、セッションの複数のSBD記述子からの第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成を制御するステップと、カスタマイズされたSBDドキュメントURLに基づいて第1のSBDクライアントを起動し、第1のSBD記述子を渡すステップとを含んでもよい。
【0005】
実施形態によれば、当該方法は、第1のSBD記述子及びカスタマイズされたSBDドキュメントURLに基づいてセグメントユニフォームリソースロケータ(URL, Uniform Resource Locator)の生成を制御し、少なくともセグメントURLを変更することによって、ビデオコンテンツのセグメントの要求を処理するステップと、変更されたセグメントURLに基づいてビデオコンテンツのセグメントを提供するステップとを更に含んでもよい。
【0006】
実施形態による方法では、セッションの複数のSBD記述子は、PreSBD記述子情報を有する同じメディアプレゼンテーション記述(MPD, media presentation description)要素内のSBD記述子、又はPreSBD記述子情報を有するMPD要素よりも下位レベルのMPD要素内のSBD記述子を含む。
【0007】
実施形態による方法では、PreSBD記述子情報は、「sbd」の値を有する@urlclass属性を含む。
【0008】
実施形態による方法では、PreSBD記述子情報は、カスタマイズされたSBDドキュメントURLの生成の対象となる一種のハイパーテキスト転送プロトコル(HTTP, hypertext transfer protocol)GET要求を含む。
【0009】
実施形態による方法では、複数のPreSBD記述子情報は、メディアプレゼンテーション記述(MPD, media presentation description)要素に存在しない。
【0010】
実施形態による方法では、PreSBD記述子情報は、PreSBD記述子情報を有するメディアプレゼンテーション記述(MPD, media presentation description)要素の下位レベルの要素に存在しない。
【0011】
実施形態による方法では、PreSBDクライアントは、第1のSBDクライアントを起動する前又はいずれかの非PreSBDクライアントを起動する前にインスタンス化される。
【0012】
実施形態による方法では、セッションの複数のSBD記述子に関連するそれぞれのSBDドキュメントURLは、ビデオコンテンツのセグメントのそれぞれの要求を処理する前に、PreSBDクライアントに送信される。
【0013】
本開示の実施形態によれば、ビデオコンテンツを提供するための装置は、コンピュータプログラムコードを記憶するように構成された少なくとも1つのメモリと、コンピュータプログラムコードにアクセスしてコンピュータプログラムコードにより命令される通り動作するように構成された少なくとも1つのプロセッサとを含んでもよい。コンピュータプログラムコードは、少なくとも1つのプロセッサに、セッションの複数のセッションベース記述(SBD, session-based description)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL, uniform resource locator)を生成するように先行セッションベース記述(PreSBD, pre-session-based description)クライアントに命令するセッションのPreSBD情報を取得させるように構成された取得コードと、少なくとも1つのプロセッサに、PreSBDクライアントをインスタンス化させ、PreSBD記述子情報を渡すようにさせるように構成されたインスタンス化コードと、少なくとも1つのプロセッサに、セッションの複数のSBD記述子からの第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成を制御させるように構成された第1の制御コードと、少なくとも1つのプロセッサに、カスタマイズされたSBDドキュメントURLに基づいて第1のSBDクライアントを起動し、第1のSBD記述子を渡すようにさせるように構成された起動コードとを含んでもよい。
【0014】
本開示の実施形態によれば、ビデオコンテンツを提供するための非一時的なコンピュータ読み取り可能媒体は、少なくとも1つのプロセッサによって実行されると、少なくとも1つのプロセッサに、セッションの複数のセッションベース記述(SBD, session-based description)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL, uniform resource locator)を生成するように先行セッションベース記述(PreSBD, pre-session-based description)クライアントに命令するセッションのPreSBD情報を取得させ、PreSBDクライアントをインスタンス化させ、PreSBD記述子情報を渡すようにさせ、セッションの複数のSBD記述子からの第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成を制御させ、カスタマイズされたSBDドキュメントURLに基づいて第1のSBDクライアントを起動させ、第1のSBD記述子を渡すようにさせてもよい命令を記憶する。
【図面の簡単な説明】
【0015】
本開示の例示的な実施形態の特徴、利点及び意義について、添付の図面を参照して以下に説明する。添付の図面において、同様の符号は同様の要素を示す。
【図1】実施形態による通信システムの簡略化された概略図である。
【図2】実施形態による、ストリーミング環境におけるコンポーネントの簡略化された概略図である。
【図3】実施形態による例示的なデコーダの簡略化されたブロック図である。
【図4】実施形態による例示的なエンコーダの簡略化されたブロック図である。
【図5】実施形態による、セッションベースDASH動作のための例示的なアーキテクチャの簡略化されたブロック図である。
【図6】実施形態による、セッションベース記述URLのカスタマイズのプロセスを示す簡略化されたフローチャートである。
【図7】実施形態による、セッションベース記述URLのカスタマイズのコールフローの簡略化された図である。
【図8】実施形態によるコンピュータシステムに従った概略図である。
【発明を実施するための形態】
【0016】
以下に議論される提案される特徴は、別々に使用されてもよく、或いは、いずれかの順序で組み合わせてもよい。さらに、実施形態は、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実施されてもよい。一例では、1つ以上のプロセッサは、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。
【0017】
図１は、本開示の一実施形態による通信システム100の簡略化したブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102及び103を含む。データの一方向伝送のために、第1の端末103は、ネットワーク105を介して他の端末102に伝送するために、ローカル位置のビデオデータを符号化してもよい。第2の端末102は、ネットワーク105から他の端末の符号化ビデオデータを受信し、符号化データを復号し、復元されたビデオデータを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
【0018】
図１は、例えば、テレビ会議中に発生し得る符号化ビデオの双方向伝送をサポートするために設けられた第2の対の端末101及び104を示す。データの双方向伝送のために、各端末101及び104は、ネットワーク105を介して他の端末に伝送するために、ローカル位置でキャプチャされたビデオデータを符号化してもよい。また、各端末101及び104は、他の端末によって送信された符号化ビデオデータを受信してもよく、符号化データを復号してもよく、復元されたビデオデータをローカルディスプレイデバイスに表示してもよい。
【0019】
図１において、端末101、102、103及び104は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク105は、例えば、有線及び/又は無線通信ネットワークを含む、端末101、102、103及び104の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク105は、回線交換チャネル及び/又はパケット交換チャネルにおいてデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク105のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
【0020】
図２は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
【0021】
ストリーミングシステムはキャプチャサブシステム203を含んでもよく、例えば、当該キャプチャサブシステム203は、例えば、非圧縮のビデオピクチャのストリーム213を生成するデジタルカメラを含んでもよい。そのサンプルストリーム213は、符号化ビデオビットストリームと比較したときに高いデータ量であるとして強調されてもよく、カメラ201に結合されたエンコーダ202によって処理されてもよい。エンコーダ202は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。符号化ビデオデータ204は、サンプルストリームと比較したときにより低いデータ量として強調されてもよく、将来の使用のためにストリーミングサーバ205に記憶されてもよい。1つ以上のストリーミングクライアント212及び207は、ストリーミングサーバ205にアクセスして符号化ビデオデータ204のコピー208及び206を取得してもよい。クライアント212は、ビデオデコーダ211を含んでもよく、ビデオデコーダ211は、符号化ビデオビットストリーム208の入力コピーを復号し、ディスプレイ209又は他のレンダリングデバイス(図示せず)上にレンダリングされ得る出力ビデオサンプルストリーム210を生成する。いくつかのストリーミングシステムでは、ビデオビットストリーム204、206及び208は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は上記に記載されており、ここで更に説明する。
【0022】
図３は、本発明の一実施形態によるビデオデコーダ300の機能ブロックでもよい。
【0023】
受信機302は、デコーダ300によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル301から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機302は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機302は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ302は、受信機302とエントロピーデコーダ/パーサ304(以下、「パーサ」という)との間に結合されてもよい。受信機302が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファ303は必要なくてもよく或いは小さくてもよい。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファ303が必要とされてもよく、比較的大きくてもよく、有利には適応的なサイズとしてもよい。
【0024】
ビデオデコーダ300は、エントロピー符号化ビデオシーケンスからシンボル313を復元するためのパーサ304を含んでもよい。これらのシンボルのカテゴリは、デコーダ303の動作を管理するために使用される情報を含み、デコーダの一体的な部分ではないがデコーダに結合され得るディスプレイ312のようなレンダリングデバイスを制御するための情報を潜在的に含む。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI, Supplementary Enhancement Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI, Video Usability Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ304は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む、当業者に周知の原理に従ってもよい。パーサ304は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP, Group of Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU, Coding Unit)、ブロック、変換ユニット(TU, Transformation Unit)、予測ユニット(PU, Prediction Unit)等を含んでもよい。また、エントロピーデコーダ/パーサは、符号化ビデオシーケンスから、変換係数、量子化パラメータ値、動きベクトル等のような情報を抽出してもよい。
【0025】
パーサ304は、シンボル313を生成するために、バッファ303から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。パーサ304は、符号化データを受信し、特定のシンボル313を選択的に復号してもよい。さらに、パーサ304は、特定のシンボル313が動き補償予測ユニット306、スケーラ/逆変換ユニット305、イントラ予測ユニット307又はループフィルタ311に提供されるべきか否かを決定してもよい。
【0026】
シンボル313の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ304によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ304と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
【0027】
上記の機能ブロックの他に、デコーダ300は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
【0028】
第1のユニットは、スケーラ/逆変換ユニット305である。スケーラ/逆変換ユニット305は、パーサ304からシンボル313として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニットは、アグリゲータ310に入力され得るサンプル値を含むブロックを出力してもよい。
【0029】
場合によっては、スケーラ/逆変換305の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用し得るブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット307によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット307は、(部分的に復元された)カレントピクチャ308から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。場合によっては、アグリゲータ310は、サンプル毎に、イントラ予測ユニット307が生成した予測情報を、スケーラ/逆変換ユニット305によって提供された出力サンプル情報に追加する。
【0030】
他の場合には、スケーラ/逆変換ユニット305の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット306は、参照ピクチャメモリ308にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル313に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ/逆変換ユニットの出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償ユニットに利用可能な、動き補償ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有し得るシンボル313の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリから取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
【0031】
アグリゲータ310の出力サンプルは、ループフィルタユニット311内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオビットストリームに含まれるパラメータによって制御され、パーサ304からシンボル313としてループフィルタユニット311に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答すると共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
【0032】
ループフィルタユニット311の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス312に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ557に記憶されてもよい。
【0033】
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ304によって)参照ピクチャとして識別されると、カレント参照ピクチャ309は参照ピクチャバッファ308の一部となってもよく、新たなカレントピクチャメモリが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
【0034】
ビデオデコーダ300は、ITU-T Rec. H.265のような標準に文書化され得る所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術又は標準に指定されており、特にそのプロファイル文書に指定されているように、ビデオ圧縮技術又は標準のシンタックスに従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD, Hypothetical Reference Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
【0035】
一実施形態では、受信機302は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ300によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号雑音比(SNR, signal-to-noise ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
【0036】
図４は、本開示の一実施形態によるビデオエンコーダ400の機能ブロック図でもよい。
【0037】
エンコーダ400、ビデオソース401(エンコーダの一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース401は、エンコーダ400によって符号化されるべきビデオ画像をキャプチャしてもよい。
【0038】
ビデオソース401は、デジタルビデオサンプルストリームの形式でエンコーダ303によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601 Y CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)でもよい。メディア提供システムにおいて、ビデオソース401は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース401は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解し得る。以下の説明は、サンプルに焦点を当てる。
【0039】
一実施形態によれば、エンコーダ400は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス410に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ402の1つの機能である。コントローラは、以下に説明するように、他の機能ユニットを制御し、これらの機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値等)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。当業者は、特定のシステム設計のために最適化されたビデオエンコーダ400に関連し得るようなコントローラ402の他の機能を容易に認識し得る。
【0040】
いくつかのビデオエンコーダは、当業者が「符号化ループ」として容易に認識するもので動作する。非常に簡略化した説明として、符号化ループは、エンコーダ402の符号化部分(ここでは「ソースコーダ」という)(符号化されるべき入力ピクチャ及び参照ピクチャに基づいてシンボルを生成することを担う)と、エンコーダ400に埋め込まれた(ローカル)デコーダ406とで構成されてもよい。デコーダ406は、(リモート)デコーダが生成するのと同様に(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、サンプルデータを生成するようにシンボルを復元する。その復元されたサンプルストリームは、参照ピクチャメモリ405に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャバッファの内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、当業者に周知である。
【0041】
「ローカル」デコーダ406の動作は、「リモート」デコーダ300と同じでもよく、これは、図３に関連して上記において既に詳細に説明した。しかし、図４を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ408及びパーサ304による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、チャネル301、受信機302、バッファメモリ303及びパーサ304を含むデコーダ300のエントロピー復号部分は、ローカルデコーダ406に完全には実装されなくてもよい。
【0042】
この時点で行い得る考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略されてもよい。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
【0043】
その動作の一部として、ソースコーダ403は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照フレーム」として指定されたビデオシーケンスからの1つ以上の前に符号化されたフレームを参照して入力フレームを予測的に符号化する。このように、符号化エンジン407は、入力フレームの画素ブロックと、入力フレームに対する予測参照として選択され得る参照フレームの画素ブロックとの間の差を符号化する。
【0044】
ローカルビデオデコーダ406は、ソースコーダ403によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータを復号してもよい。符号化エンジン407の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図４に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ406は、参照フレームに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照フレームを参照ピクチャキャッシュ405に記憶させてもよい。このように、エンコーダ400は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照フレームとして、共通の内容を有する復元された参照フレームのコピーをローカルに記憶してもよい。
【0045】
予測器404は、符号化エンジン407のための予測探索を実行してもよい。すなわち、符号化されるべき新たなフレームについて、予測器404は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ405を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器404は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample block-by-pixel block)に動作してもよい。場合によっては、予測器404によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ405に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
【0046】
コントローラ402は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ403の符号化動作を管理してもよい。
【0047】
全ての上記の機能ユニットの出力は、エントロピーコーダ408におけるエントロピー符号化を受けてもよい。エントロピーコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化等のような当業者に既知の技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
【0048】
送信機409は、エントロピーコーダ408によって生成された符号化ビデオシーケンスをバッファして、通信チャネル411を介した送信の準備をしてもよく、当該通信チャネル411は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機409は、ビデオコーダ403からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
【0049】
コントローラ402は、エンコーダ400の動作を管理してもよい。符号化中に、コントローラ405は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のフレームタイプのうち1つとして割り当てられてもよい。
【0050】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のピクチャを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。
【0051】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。
【0052】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。
【0053】
一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。
【0054】
ビデオコーダ400は、ITU-T Rec. H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオコーダ400は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
【0055】
一実施形態では、送信機409は、符号化ビデオと共に更なるデータを送信してもよい。ソースコーダ403は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、補足エンハンスメント情報(SEI, Supplementary Enhancement Information)メッセージ、ビジュアルユーザビリティ情報(VUI, Visual Usability Information)パラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。
【0056】
図５は、実施形態による、セッションベースDASH動作のための例示的なアーキテクチャ500の簡略化されたブロック図を示す。
【0057】
ストリーミングメディア又はビデオコンテンツは、発信元501で発生してもよく、MPD/セグメントをDASHアクセスクライアント503に提供し得るコンテンツ配信ネットワーク(CDN, content delivery network)502に提供されてもよい。セッションクライアント506は値(value)を要求するように制御されてもよく、DASHアクセスクライアント503によって値がセッションクライアント506からDASHアクセスクライアント503に提供されてもよい。一例として、getValue(key,time)のような値がDASHアクセスクライアント503によって要求されてもよく、値は、セッションクライアント506からDASHアクセスクライアント503に提供されてもよい。セッションクライアント506は、図６及び７の例示的な実施形態のように、セッションコントローラ504及び505からの制御及びSBD[0]及びSBD[1]のようなこれらのそれぞれのSBDデータと共に、値をDASHアクセスクライアント503に提供してもよい。
【0058】
一例として、URLテンプレートのための要素がSBD記述子に導入され、実施形態によれば、より具体的には、SBD動作(例えば、クエリ又はURLのカスタマイズ)は、セッションクライアント506がDASHアクセスクライアント503におけるMPDから十分な情報を取得した後に、DASHアクセスクライアント503によって生成されたセグメントURLにその処理を適用し得るようにするべきである。しかし、SBD動作は、例示的な実施形態ではDASHアクセスクライアント503動作を妨害しないものとし、例示的な実装はMPDとSBD処理とを組み合わせてもよいが、他の実施形態は、このような特徴は結果として行われ得るものとする。この観点で、その利点は、SBD動作がDASHクライアントのロジックと統合されるのではなく、アプリケーションとしていずれかのDASHアクセスクライアントに追加され得ることである。したがって、実施形態によってURLを新たな値に変更してもよい。
【0059】
本開示の実施形態によれば、SBDに関連するセッションベースDASH動作の標準(例えば、ISO/IEC 23009-8)は、SBDドキュメントURL又はSBD URLのカスタマイズを可能にするように拡張されてもよい。すなわち、複数のドキュメントが様々な要求のURL又はクエリに適用されることを可能にするSBD標準は、他のSBD URL要求を要求及び適用するように拡張されてもよい。
【0060】
MPD要素は、1つ以上のSBD記述子を有してもよい。しかし、上記のように、URL及び要求はSBD記述子を使用して変更されてもよいが、SBD記述子のSBDドキュメントURLは利用可能な標準を使用して変更されないことがある。したがって、この技術的問題を解決し、カスタマイズにおいてより柔軟性を提供するために、本開示の実施形態は、先行セッション記述(PreSBD, pre-session-description)と呼ばれるSBD記述子を追加する。PreSBDは他のSBD URL要求をカスタマイズするために使用されてもよい。
【0061】
本開示の実施形態によれば、PreSBD記述子は、その@urlclass属性に「sbd」の値が割り当てられた「通常の」SBD記述子と同じシンタックスを有してもよい。@urlclass属性は、どのHPPT GET要求がSBD処理の対象となり得るかを指定してもよい。@urlclass属性は、どのHPPT GET要求がSBD処理の対象となり得るかを指定するので、「sbd」の値は、PreSBD記述子情報がカスタマイズされたSBDドキュメントURLの生成の対象となる一種のハイパーテキスト転送プロトコル(HTTP, hypertext transfer protocol)GET要求を含んでもよいことを示してもよい。
【0062】
@urlclassに関連する値は、許容可能なキーの連結リストのリストでもよい。PreSBD記述子について、@urlclass属性値は少なくとも「sbd」を含む連結リストでもよい。連結リストに含まれ得る他の可能な値は、「segment」、「xlink」、「mpd」、「callback」、「chaining」及び「fallback」である。
【0063】
PreSBD記述子の属性は、@urlclass属性に限定されなくてもよい。表１は、PreSBD記述子を使用したセッションベースDASH処理のMPD EssentialProperty記述子属性の例を示す。
【0064】
【表1】
【0065】
MPDは1つ以上のPreSBD記述子を有してもよいが、いくつかの実施形態によれば、MPD要素は最大でも1つのPreSBD記述子のみを有してもよい。いくつかの実施形態では、MPDは1つよりも多くのPreSBDを有してもよく、複数のPreSBD記述子情報は1つのメディアプレゼンテーション記述(MPD, media presentation description)要素に存在しなくてもよい。一実施形態では、PreSBDを有するMPD要素の下位レベル要素は、PreSBD記述子を有さなくてもよい。したがって、PreSBD記述子情報は、PreSBD記述子情報を有するメディアプレゼンテーション記述(MPD, media presentation description)要素の下位レベル要素に存在しなくてもよい。したがって、いくつかの実施形態によれば、MPD要素は最大でも1つのPreSBD記述子を有してもよい。
【0066】
本開示の実施形態によれば、MPD要素について、PreSBD記述子は、そのMPD要素内の「通常の」SBD記述子のいずれかが処理される前に処理されてもよい。この開示は、他のSBD URLを使用してSBDドキュメントURLをカスタマイズすることを対象とする。このような階層構造を可能にし、「通常の」SBD記述子がSBDドキュメントURLをカスタマイズすることを可能にするために、PreSBD記述子は、MPD要素内のいずれかの他の記述子の前に処理されてもよい。したがって、MPD要素のいずれかの他のSBDクライアントのインスタンス化の前に、PreSBDクライアントがインスタンス化されてもよい。
【0067】
本開示の実施形態によれば、いずれかのSBD記述子のSBDドキュメントURLは、SBDドキュメントの要求が行われる前に、カスタマイズのために対応するPreSBDクライアントに送信されてもよい。いくつかの実施形態では、いずれかのSBD記述子のSBDドキュメントURLは、SBDドキュメントの要求が行われ、それぞれのSBDクライアントがビデオコンテンツのセグメントのセグメントURLを生成及び/又は変更する前に、カスタマイズのために対応するPreSBDクライアントに送信されてもよい。したがって、セッションの同じMPD要素内の複数のSBD記述子に関連するそれぞれのSBDドキュメントURLは、ビデオコンテンツのセグメントのそれぞれの要求を処理する前に、PreSBDクライアントに送信されてもよい。
【0068】
次に図６及び７を参照すると、図６は、セッションベース記述URLのカスタマイズのプロセス600を示すフローチャートである。図７は、実施形態による、セッションベース記述URLのカスタマイズのためのコールフロー700の例示的な図である。
【0069】
図６に示すように、動作610において、セッションの複数のセッションベース記述(SBD, session-based description)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL, uniform resource locator)を生成するように先行セッションベース記述(PreSBD, pre-session-based description)クライアントに命令するセッションのPreSBD情報が取得されてもよい。一例として、DASHアクセスクライアント503のようなDASHクライアントは、CDN502等からのMPDを解析し、セッションの複数のセッションベース記述(SBD, session-based description)記述子についてのカスタマイズされたSBDドキュメントユニフォームリソースロケータ(URL, uniform resource locator)を生成するように先行セッションベース記述(PreSBD, pre-session-based description)クライアントに命令するセッションのPreSBD情報を取得してもよい。
【0070】
動作620において、PreSBDクライアントがインスタンス化されてもよく、PreSBD記述子情報がPreSBDクライアントに渡されてもよい。一例として、DASHクライアント705のようなDASHクライアントは、PreSBDクライアント710のようなPreSBDクライアントをインスタンス化し得るPreSBD記述子の検索を実行してもよい。いくつかの実施形態では、PreSBD記述子情報は、DASHクライアント705によって使用され得る「sbd」の値を有する@urlclass属性を含んでもよい。いくつかの実施形態では、PreSBD記述子情報は、カスタマイズされたSBDドキュメントURL生成の対象となり得る一種のハイパーテキスト転送プロトコル(HTTP, hypertext transfer protcol)GET要求を含んでもよく、このような情報はDASHクライアント705によるものでもよい。
【0071】
実施形態によれば、PreSBDクライアントは、第1のSBDクライアントを起動する前又はMPD要素内のいずれかの非PreSBDクライアントを起動する前にインスタンス化されてもよい。一例として、図７を参照すると、コールフロー700の動作755において、DASHクライアント705は、PreSBDクライアント710のようなPreSBDクライアントをインスタンス化し得るPreSBD記述子の検索を実行し、PreSBD記述子をPreSBDクライアント710に渡してもよい。
【0072】
プロセス600の動作630において、セッションの複数のSBD記述子からの第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成が制御されてもよい。一例として、コールフロー700の動作760において、DASHクライアント705は、SBD1記述子のような第1のSBD記述子に関連するカスタマイズされたSBDドキュメントURLの生成を制御してもよい。動作765において、DASHクライアント705は、第1のSBD記述子SBD1に関連するカスタマイズされたSBDドキュメントURLを受信してもよい。いくつかの実施形態では、PreSBDクライアント710は、DASHクライアント705の指示の下で、カスタマイズされたSBDドキュメントを生成してもよい。
【0073】
実施形態によれば、カスタマイズされたSBDドキュメントURLが生成され得るセッションの複数のSBD記述子は、PreSBD記述子情報を有する同じメディアプレゼンテーション記述(MPD, media presentation description)要素内のSBD記述子、又はPreSBD記述子情報を有するMPD要素よりも下位レベルのMPD要素内のSBD記述子を含んでもよい。上記のように、PreSBDプロセスは、複数のPreSBD記述子情報がメディアプレゼンテーション記述(MPD, media presentation description)要素に存在しなくてもよいこと、PreSBD記述子情報がPreSBD記述子情報を有するメディアプレゼンテーション記述(MPD media presentation description)要素の下位レベルの要素に存在しなくてもよいことを含む、いくつかの制限を有してもよい。
【0074】
PreSBD記述子は、PreSBDクライアントをインスタンス化し、セッションの複数のSBD記述子からのSBD記述子に関連するカスタマイズされたSBDドキュメントURLを生成するために必要であるので、実施形態によれば、PreSBDクライアントは、第1のSBDクライアントを起動する前又はいずれかの非PreSBDクライアントを起動する前にインスタンス化されてもよい。同様に、実施形態によれば、セッションの複数のSBD記述子に関連するそれぞれのSBDドキュメントURLは、ビデオコンテンツのセグメントのそれぞれの要求を処理する前に、PreSBDクライアントに送信される。
【0075】
プロセス600の動作640において、第1のSBDクライアントは、カスタマイズされたSBDドキュメントURLに基づいて起動されてもよく、第1のSBD記述子は、第1のSBDクライアントに渡されてもよい。一例として、コールフロー700の動作770において、DASHクライアント705は、動作765において受信した第1のSBD記述子SBD1に関連するカスタマイズされたSBDドキュメントURLに基づいてSBD1クライアント715を起動してもよい。
【0076】
プロセス600の動作650において、セグメントユニフォームリソースロケータ(URL, Uniform Resource Locator)の生成は、第1のSBD記述子及びカスタマイズされたSBDドキュメントURLに基づいて制御されてもよく、少なくともセグメントURLを変更することによって、ビデオコンテンツのセグメントの要求が処理されてもよい。一例として、動作770及び775において、DASHクライアント705は、PreSBD記述子及びSBD1記述子に基づいてセグメントユニフォームリソースロケータ(URL, Uniform Resource Locator)の生成を制御してもよい。いくつかの実施形態では、SBD1クライアント715は、DASHクライアント705の指示の下で、セグメントユニフォームリソースロケータ(URL, Uniform Resource Locator)を生成してもよい。
【0077】
さらに、動作650において、少なくともセグメントURLを変更することによって、ビデオコンテンツのセグメントの要求が処理されてもよい。実施形態によれば、セッションの複数のSBD記述子に関連するそれぞれのSBDドキュメントURLは、ビデオコンテンツのセグメントのそれぞれの要求を処理する前に、PreSBDクライアントに送信されてもよい。
【0078】
動作660において、変更されたセグメントURLに基づいてビデオコンテンツのセグメントが提供されてもよい。一例として、DASHクライアント705は、コールフロー700の動作780において、SBD1クライアント715から受信した変更されたセグメントURLに基づいて、ビデオコンテンツのセグメントを提供してもよい。いくつかの実施形態では、DASHクライアント705は、コールフロー700の動作780において、少なくともSBD1クライアント715から受信したセグメントURLを変更することによって、ビデオコンテンツのセグメントの要求を処理し、変更されたセグメントURLに基づいてビデオコンテンツのセグメントを提供してもよい。
【0079】
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよく、或いは、特に構成された1つ以上のハードウェアプロセッサにより実装されてもよい。例えば、図８は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム800を示す。
【0080】
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、コンピュータ中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, Graphics Processing Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
【0081】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
【0082】
コンピュータシステム800について図８に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム800の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
【0083】
コンピュータシステム800は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像等)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
【0084】
入力ヒューマンインタフェースデバイスは、キーボード801、マウス802、トラックパッド803、タッチ画面810、ジョイスティック805、マイクロフォン806、スキャナ808、カメラ807のうち1つ以上を含んでもよい。
【0085】
また、コンピュータシステム800は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面810又はジョイスティック805による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ809、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよいCRT画面、LCD画面、プラズマ画面、OLED画面を含む画面810、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。
【0086】
また、コンピュータシステム800は、CD/DVD811又は同様の媒体を有するCD/DVD ROM/RW820を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ822、取り外し可能ハードドライブ又はソリッドステートドライブ823、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。
【0087】
また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。
【0088】
また、コンピュータシステム800は、1つ以上の通信ネットワーク898へのインタフェース899を含んでもよい。ネットワーク898は、例えば、無線、有線、光でもよい。ネットワーク898は、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。ネットワーク898の例は、イーサネット、無線LAN、セルラネットワーク(GSM、3G、4G、5G、LTE等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワーク898は、一般的に、特定の汎用データポート又は周辺バス(850及び851)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム800のUSBポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム800のコアに統合される。これらのネットワーク898のいずれかを使用して、コンピュータシステム800は、他のエンティティと通信してもよい。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
【0089】
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム800のコア840に取り付けられてもよい。
【0090】
コア840は、1つ以上の中央処理装置(CPU)841、グラフィックス処理ユニット(GPU)842、グラフィックスアダプタ817、フィールドプログラマブルゲートアレイ(FPGA, Field Programmable Gate Area)843の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ844等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)845、ランダムアクセスメモリ846、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、SSD等)847と共に、システムバス848を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス848は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス848に直接取り付けられてもよく、或いは、周辺バス851を通じて取り付けられてもよい。周辺バスのアーキテクチャは、PCI、USB等を含む。
【0091】
CPU841、GPU842、FPGA843及びアクセラレータ844は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM845又はRAM846に記憶されてもよい。また、一時的なデータは、RAM846に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置847に記憶されてもよい。1つ以上のCPU841、GPU842、大容量記憶装置847、ROM845、RAM846等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。
【0092】
コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。
【0093】
限定ではなく一例として、アーキテクチャ800、具体的には、コア840を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供してもよい。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置847又はROM845のような非一時的な性質のコア840の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア840によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア840、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM846に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ844)内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。
【0094】
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案し得ることが認識される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】