(57)【要約】  例示的なクライアントデバイスは、ブロードキャストサービスが利用可能であるかどうかに応じて、ブロードキャストサービスまたはユニキャストサービスのいずれかを介してメディアデータを受信するためのミドルウェアユニットを含む。また、クライアントデバイスは、動的適応ストリーミングオーバーHTTP(DASH)クライアントなどのストリーミングクライアントを含む。DASHクライアントは、メディアデータをミドルウェアユニットを介して取り出すことの要求を送信する。ブロードキャストサービスがアクティブでないときでも、ブロードキャストサービスを介して以前に受信されたメディアデータをストリーミングクライアントが要求する場合に、ミドルウェアユニットが、ストリーミングクライアントからの要求内で指定される外部サーバデバイスからメディアデータを要求するのではなく、キャッシュからストリーミングクライアントにメディアデータを提供し得るように、ミドルウェアユニットはブロードキャストサービスを介して受信されたメディアデータをキャッシュしてよい。
2018524882.tif 000002
【特許請求の範囲】
【請求項１】
クライアントデバイスのミドルウェアユニットによってメディアデータを取り出す方法であって、前記ミドルウェアユニットが前記クライアントデバイスのハイパーテキスト転送プロトコル(HTTP)プロキシユニットを制御し、前記クライアントデバイスがローカルサーバユニットを含み、前記方法が、前記ミドルウェアユニットによって、
メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信するステップと、
メディアデータの前記第1のセットを受信した後、前記ブロードキャストサービスがもはや利用可能でないと判定するステップと、
前記ブロードキャストサービスがもはや利用可能でないとの前記判定に基づいて、前記クライアントデバイスによって実行されたストリーミングアプリケーションから、ユニキャストサービスを介して前記メディアセッションのメディアデータの第2のセットを取り出すことの要求を受信するステップであって、前記要求が前記クライアントデバイスの外部のアドレスを指定する、受信するステップと、
前記要求に応答して、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されていたとき、前記クライアントデバイスの外部の前記アドレスの代わりに前記ローカルサーバユニットに前記要求をリダイレクトすることを前記HTTPプロキシユニットに行わせるステップとを含み、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されている、方法。
【請求項２】
前記ストリーミングアプリケーションからの前記要求を受信するステップが、前記ストリーミングアプリケーションからの前記要求をインターセプトするステップを含む、請求項1に記載の方法。
【請求項３】
リダイレクトすることを前記HTTPプロキシユニットに行わせるステップが、前記ローカルサーバユニットと関連付けられたローカルホストアドレスを含むHTTP300応答を前記ストリーミングクライアントに送信することを前記HTTPプロキシユニットに行わせるステップを含む、請求項1に記載の方法。
【請求項４】
前記ミドルウェアユニットに対する前記ストリーミングアプリケーションのインターフェースを、前記HTTPプロキシユニットに関するプロキシ情報を用いて構成するステップをさらに含む、請求項1に記載の方法。
【請求項５】
前記メディアセッションに対するマニフェストファイルが、前記メディアデータに対する複数の表現があることを示し、前記ユニキャストサービスが、前記複数の表現のうちの第1の表現のデータを提供し、前記ブロードキャストサービスが、前記複数の表現のうちの第2の異なる表現のデータを提供し、前記方法が、
前記ブロードキャストサービスが利用可能であるとき、前記第2の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第1のサーバ/ネットワーク支援型DASH(SAND)実施メッセージを使用するステップと、
前記ブロードキャストサービスが利用可能でないとき、前記第1の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第2のSAND実施メッセージを使用するステップとをさらに含む、請求項1に記載の方法。
【請求項６】
前記第1のSAND実施メッセージおよび前記第2のSAND実施メッセージが、
対応するマニフェストファイル内の表現を識別するユニフォームリソース識別子(URI)プレフィックスを表すベースユニフォームリソースロケータ(URL)フィールドと、
すべての関連するリソースのステータスを表すステータスフィールドと
を含むSAND実施メッセージスキーマと一致する、請求項5に記載の方法。
【請求項７】
リダイレクトすることを前記HTTPプロキシユニットに行わせるステップが、前記ストリーミングクライアントへのHTTP300応答内に前記第2の表現の識別子を含めることを前記HTTPプロキシユニットに行わせるステップを含む、請求項5に記載の方法。
【請求項８】
前記ユニキャストサービスから前記ブロードキャストサービスへの切り換えの前に、前記メディアセッションのメディアデータの第3のセットに対する前記ストリーミングクライアントからの要求に応答して、前記ユニキャストサービスを使用してメディアデータの前記第3のセットを取り出すステップと、
前記ユニキャストサービスから前記ブロードキャストサービスへの前記切り換えの後に、前記メディアセッションのメディアデータの第4のセットを前記ブロードキャストサービスを介して受信するステップとをさらに含む、請求項1に記載の方法。
【請求項９】
メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されていないとき、メディアデータの前記第2のセットに対する前記要求を前記クライアントデバイスとは別個のサーバデバイスにリダイレクトするステップをさらに含む、請求項1に記載の方法。
【請求項１０】
前記ローカルサーバユニット内にキャッシュされているセグメントに対する要求を前記ローカルサーバユニットにダイレクトすることと、
前記ローカルサーバユニットによって満足され得るセグメント識別子のリストを前記ストリーミングアプリケーションに提供することとを行うように前記HTTPプロキシユニットを構成するステップをさらに含む、請求項1に記載の方法。
【請求項１１】
前記ローカルサーバユニットによってキャッシュされているメディアデータの1つまたは複数の識別子を含むデータを前記ストリーミングクライアントへ送信させるステップをさらに含む、請求項1に記載の方法。
【請求項１２】
前記データがSANDメッセージと一致する、請求項11に記載の方法。
【請求項１３】
前記データが、前記識別子を表すカンマ区切り値のリストを含み、前記識別子が、利用可能なメディアデータの開始と前記利用可能なメディアデータの終了とを指定する、請求項11に記載の方法。
【請求項１４】
前記データがfromフィールドとtoフィールドとを含み、前記fromフィールドが利用可能なメディアデータの開始を指定し、前記toフィールドが前記利用可能なメディアデータの終了を指定する、請求項11に記載の方法。
【請求項１５】
前記データが、1つまたは複数の正規表現を含む、請求項11に記載の方法。
【請求項１６】
前記データが、メディアデータのセットに対するステータスのリストを含む、請求項11に記載の方法。
【請求項１７】
前記メディアデータが複数のセグメントを含み、前記セグメントの各々が別個のユニフォームリソースロケータ(URL)と関連付けられる、請求項1に記載の方法。
【請求項１８】
前記マニフェストファイルがメディアプレゼンテーション記述(MPD)を含む、請求項1に記載の方法。
【請求項１９】
前記ストリーミングクライアントが、動的適応ストリーミングオーバーHTTP(DASH)クライアントを含む、請求項1に記載の方法。
【請求項２０】
メディアデータを取り出すためのデバイスであって、
ハイパーテキスト転送プロトコル(HTTP)プロキシユニットと、
ローカルサーバユニットと、
前記HTTPプロキシユニットを制御するミドルウェアユニットとを備え、前記ミドルウェアユニットが、論理回路を備えるハードウェアベースの処理ユニットによって実装され、前記ミドルウェアユニットが、
メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信することと、
メディアデータの前記第1のセットを受信した後、前記ブロードキャストサービスがもはや利用可能でないと判定することと、
前記ブロードキャストサービスがもはや利用可能でないとの前記判定に基づいて、前記クライアントデバイスによって実行されたストリーミングアプリケーションから、ユニキャストサービスを介して前記メディアセッションのメディアデータの第2のセットを取り出すことの要求を受信することであって、前記要求が前記クライアントデバイスの外部のアドレスを指定する、受信することと、
前記要求に応答して、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されていたとき、前記クライアントデバイスの外部の前記アドレスの代わりに前記ローカルサーバユニットに前記要求をリダイレクトすることを前記HTTPプロキシユニットに行わせることとを行うように構成され、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されている、デバイス。
【請求項２１】
前記メディアセッションに対するマニフェストファイルが、前記メディアデータに対する複数の表現があることを示し、前記ユニキャストサービスが、前記複数の表現のうちの第1の表現のデータを提供し、前記ブロードキャストサービスが、前記複数の表現のうちの第2の異なる表現のデータを提供し、前記ミドルウェアユニットが、
前記ブロードキャストサービスが利用可能であるとき、前記第2の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第1のサーバ/ネットワーク支援型DASH(SAND)実施メッセージを使用することと、
前記ブロードキャストサービスが利用可能でないとき、前記第1の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第2のSAND実施メッセージを使用することとを行うようにさらに構成される、請求項20に記載のデバイス。
【請求項２２】
前記第1のSAND実施メッセージおよび前記第2のSAND実施メッセージが、
対応するマニフェストファイル内の表現を識別するユニフォームリソース識別子(URI)プレフィックスを表すベースユニフォームリソースロケータ(URL)フィールドと、
すべての関連するリソースのステータスを表すステータスフィールドと
を含むSAND実施メッセージスキーマと一致する、請求項21に記載のデバイス。
【請求項２３】
前記ミドルウェアユニットが、
前記ローカルサーバユニット内にキャッシュされているセグメントに対する要求を前記ローカルサーバユニットにダイレクトすることと、
前記ローカルサーバユニットによって満足され得るセグメント識別子のリストを前記ストリーミングアプリケーションに提供することとを行うように前記HTTPプロキシユニットを構成するようにさらに構成される、請求項20に記載のデバイス。
【請求項２４】
前記ミドルウェアユニットが、データを前記ストリーミングクライアントへ送信させるようにさらに構成され、前記データが、前記ローカルサーバユニットによってキャッシュされているメディアデータの1つまたは複数の識別子を含む、請求項20に記載のデバイス。
【請求項２５】
前記データが、前記識別子を表すカンマ区切り値のリストを含み、前記識別子が、利用可能なメディアデータの開始および前記利用可能なメディアデータの終了を指定し、前記データがfromフィールドおよびtoフィールドを含み、前記fromフィールドが利用可能なメディアデータの開始を指定し、前記toフィールドが前記利用可能なメディアデータの終了を指定し、前記データが1つまたは複数の正規表現を含み、前記データがメディアデータのセットに対するステータスのリストを備える、請求項24に記載のデバイス。
【請求項２６】
前記HTTPプロキシユニットが、前記ミドルウェアユニット内に含まれる、請求項20に記載のデバイス。
【請求項２７】
前記HTTPプロキシユニットが、前記ミドルウェアユニットとは別個である、請求項20に記載のデバイス。
【請求項２８】
メディアデータを取り出すためのデバイスであって、
ハイパーテキスト転送プロトコル(HTTP)プロキシユニットと、
ローカルサーバユニットと、
メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信するための手段と、
メディアデータの前記第1のセットを受信した後、前記ブロードキャストサービスがもはや利用可能でないと判定するための手段と、
前記ブロードキャストサービスがもはや利用可能でないとの前記判定に基づいて、前記クライアントデバイスによって実行されたストリーミングアプリケーションから、ユニキャストサービスを介して前記メディアセッションのメディアデータの第2のセットを取り出すことの要求を受信するための手段であって、前記要求が前記クライアントデバイスの外部のアドレスを指定する、受信するための手段と、
前記要求に応答して、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されていたとき、前記クライアントデバイスの外部の前記アドレスの代わりに前記ローカルサーバユニットに前記要求をリダイレクトすることを前記HTTPプロキシユニットに行わせるための手段とを含み、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されている、デバイス。
【請求項２９】
前記メディアセッションに対するマニフェストファイルが、前記メディアデータに対する複数の表現があることを示し、前記ユニキャストサービスが、前記複数の表現のうちの第1の表現のデータを提供し、前記ブロードキャストサービスが、前記複数の表現のうちの第2の異なる表現のデータを提供し、前記デバイスが、
前記ブロードキャストサービスが利用可能であるとき、前記第2の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第1のサーバ/ネットワーク支援型DASH(SAND)実施メッセージを使用するための手段と、
前記ブロードキャストサービスが利用可能でないとき、前記第1の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第2のSAND実施メッセージを使用するための手段とをさらに含む、請求項28に記載のデバイス。
【請求項３０】
前記第1のSAND実施メッセージおよび前記第2のSAND実施メッセージが、
対応するマニフェストファイル内の表現を識別するユニフォームリソース識別子(URI)プレフィックスを表すベースユニフォームリソースロケータ(URL)フィールドと、
すべての関連するリソースのステータスを表すステータスフィールドと
を含むSAND実施メッセージスキーマと一致する、請求項29に記載のデバイス。
【請求項３１】
前記ローカルサーバユニット内にキャッシュされているセグメントに対する要求を前記ローカルサーバユニットにダイレクトすることと、
前記ローカルサーバユニットによって満足され得るセグメント識別子のリストを前記ストリーミングアプリケーションに提供することとを行うように前記HTTPプロキシユニットを構成するための手段をさらに含む、請求項28に記載のデバイス。
【請求項３２】
前記ローカルサーバユニットによってキャッシュされているメディアデータの1つまたは複数の識別子を含むデータを前記ストリーミングクライアントへ送信させるための手段をさらに含む、請求項28に記載のデバイス。
【請求項３３】
前記データが、前記識別子を表すカンマ区切り値のリストを含み、前記識別子が、利用可能なメディアデータの開始および前記利用可能なメディアデータの終了を指定し、前記データがfromフィールドおよびtoフィールドを含み、前記fromフィールドが利用可能なメディアデータの開始を指定し、前記toフィールドが前記利用可能なメディアデータの終了を指定し、前記データが1つまたは複数の正規表現を含み、前記データがメディアデータのセットに対するステータスのリストを備える、請求項32に記載のデバイス。
【請求項３４】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令が実行されたとき、クライアントデバイスのミドルウェアユニットを備えるプロセッサであって、前記ミドルウェアユニットが前記クライアントデバイスのハイパーテキスト転送プロトコル(HTTP)プロキシユニットを制御し、前記クライアントデバイスがローカルサーバユニットを含む、プロセッサに、
メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信することと、
メディアデータの前記第1のセットを受信した後、前記ブロードキャストサービスがもはや利用可能でないと判定することと、
前記ブロードキャストサービスがもはや利用可能でないとの前記判定に基づいて、前記クライアントデバイスによって実行されたストリーミングアプリケーションから、ユニキャストサービスを介して前記メディアセッションのメディアデータの第2のセットを取り出すことの要求を受信することであって、前記要求が前記クライアントデバイスの外部のアドレスを指定する、受信することと、
前記要求に応答して、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されていたとき、前記クライアントデバイスの外部の前記アドレスの代わりに前記ローカルサーバユニットに前記要求をリダイレクトすることを前記HTTPプロキシユニットに行わせることとを行わせ、メディアデータの前記第2のセットが前記ブロードキャストサービスを介して以前に受信されている、コンピュータ可読記憶媒体。
【請求項３５】
前記メディアセッションに対するマニフェストファイルが、前記メディアデータに対する複数の表現があることを示し、前記ユニキャストサービスが、前記複数の表現のうちの第1の表現のデータを提供し、前記ブロードキャストサービスが、前記複数の表現のうちの第2の異なる表現のデータを提供し、
前記ブロードキャストサービスが利用可能であるとき、前記第2の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第1のサーバ/ネットワーク支援型DASH(SAND)実施メッセージを使用することと、
前記ブロードキャストサービスが利用可能でないとき、前記第1の表現からデータを取り出すことを前記ストリーミングクライアントに行わせるために、第2のSAND実施メッセージを使用することとを前記プロセッサに行わせる命令をさらに含む、請求項34に記載のコンピュータ可読記憶媒体。
【請求項３６】
前記第1のSAND実施メッセージおよび前記第2のSAND実施メッセージが、
対応するマニフェストファイル内の表現を識別するユニフォームリソース識別子(URI)プレフィックスを表すベースユニフォームリソースロケータ(URL)フィールドと、
すべての関連するリソースのステータスを表すステータスフィールドと
を含むSAND実施メッセージスキーマと一致する、請求項35に記載のコンピュータ可読記憶媒体。
【請求項３７】
前記ローカルサーバユニット内にキャッシュされているセグメントに対する要求を前記ローカルサーバユニットにダイレクトすることと、
前記ローカルサーバユニットによって満足され得るセグメント識別子のリストを前記ストリーミングアプリケーションに提供することとを行うように前記HTTPプロキシユニットを構成することを前記プロセッサに行わせる命令をさらに含む、請求項34に記載のコンピュータ可読記憶媒体。
【請求項３８】
前記ローカルサーバユニットによってキャッシュされているメディアデータの1つまたは複数の識別子を含むデータを前記ストリーミングクライアントへ送信させることを前記プロセッサに行わせる命令をさらに含む、請求項34に記載のコンピュータ可読記憶媒体。
【請求項３９】
前記データが、前記識別子を表すカンマ区切り値のリストを含み、前記識別子が、利用可能なメディアデータの開始および前記利用可能なメディアデータの終了を指定し、前記データがfromフィールドおよびtoフィールドを含み、前記fromフィールドが利用可能なメディアデータの開始を指定し、前記toフィールドが前記利用可能なメディアデータの終了を指定し、前記データが1つまたは複数の正規表現を含み、前記データがメディアデータのセットに対するステータスのリストを備える、請求項38に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、各々の内容全体が参照により本明細書に組み込まれている、2015年6月18日に出願した米国仮出願第62/181,684号、および2015年6月23日に出願した米国仮出願第62/183,615号の利益を主張するものである。
【０００２】
本開示は、符号化されたビデオデータの記憶および転送に関する。
【背景技術】
【０００３】
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンストビデオコーディング(AVC)によって定められた規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
【０００４】
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、隣接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームまたはスライスにおける隣接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
【０００５】
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
【０００６】
ビデオ、およびより一般的には、データは、多様な転送方法において配信され得る。1つのそのような方法は、第3世代パートナーシッププロジェクト(3GPP)ネットワークにおけるマルチメディアブロードキャスト/マルチキャストサービス(MBMS)または拡張MBMS(eMBMS)である。MBMSおよびeMBMSは、関心のあるサービスを単一の配信パイプを使用して多数の加入者に配信することを可能にする。具体的には、サーバデバイスは、たとえばMBMSまたはeMBMSを介するブロードキャストまたはマルチキャストの配信を含み得る3GPPを使用してメディアデータをクライアントデバイスに送信し得る。追加または代替として、サーバデバイスは、たとえばハイパーテキスト転送プロトコル(HTTP)または動的適応ストリーミングオーバーHTTP(DASH)に従ってユニキャストを使用してメディアデータを送信し得る。
【発明の概要】
【課題を解決するための手段】
【０００７】
概して、本出願は、ブロードキャストまたはマルチキャストメディアデータ送信技法とユニキャストメディアデータ送信技法との間の切り換えに関する技法を対象とする。具体的には、そのような切り換えは、クライアントデバイスの地理的ロケーションに従って、ブロードキャストまたはマルチキャストサービスが利用可能であるか否かに基づいて発生する場合がある。すなわち、クライアントデバイスは、メディアデータの送信のためにブロードキャストまたはマルチキャストサービスを提供することも提供しないこともある特定のサービスエリア内に配置される場合がある。ブロードキャストまたはマルチキャストサービスが利用可能であるとき、クライアントデバイスは、ブロードキャストまたはマルチキャストサービスを使用してメディアデータを受信し得る一方で、ブロードキャストまたはマルチキャストが利用可能でないとき、クライアントデバイスは、ユニキャストを使用してメディアデータを受信し得る。
【０００８】
たとえばブロードキャストまたはマルチキャストを介してメディアデータが受信されると、クライアントデバイスは、DASHクライアント(たとえば、ウェブブラウザプラグイン)などのターゲットアプリケーションによる後続の取出しのためにメディアデータをキャッシュする。時々、クライアントデバイスは、ブロードキャストまたはマルチキャストからユニキャストに切り換える場合があるが、ブロードキャストまたはマルチキャストを介して以前に受信されたメディアデータは依然としてキャッシュされている。したがって、本開示の技法は、ブロードキャストまたはマルチキャストからユニキャストへの切り換えに続いてそのようなメディアデータがキャッシュされているか否かを判定するステップと、キャッシュされている場合、ユニキャストを介して類似のメディアデータを直ちに取り出すのではなく、キャッシュされているメディアデータを使用するかどうかを判定するステップとを含む。
【０００９】
一例では、メディアデータを取り出す方法は、クライアントデバイスのミドルウェアユニットによって実行され、ミドルウェアユニットはクライアントデバイスのハイパーテキスト転送プロトコル(HTTP)プロキシユニットを制御し、クライアントデバイスはローカルサーバユニットを含む。この方法は、メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信するステップと、メディアデータの第1のセットを受信した後、ブロードキャストサービスがもはや利用可能でないと判定するステップと、ブロードキャストサービスがもはや利用可能でないとの判定に基づいて、クライアントデバイスによって実行されるストリーミングアプリケーションから、ユニキャストサービスを介してメディアセッションのメディアデータの第2のセットを取り出す要求を受信するステップであって、要求がクライアントデバイスの外部のアドレスを指定する、ステップと、要求に応答して、メディアデータの第2のセットがブロードキャストサービスを介して以前に受信されているとき、要求をクライアントデバイスの外部のアドレスの代わりにローカルサーバユニットにリダイレクトすることをHTTPプロキシユニットに行わせるステップとを含み、メディアデータの第2のセットはブロードキャストサービスを介して以前に受信されている。
【００１０】
別の例では、取り出すためのデバイスは、ハイパーテキスト転送プロトコル(HTTP)プロキシユニットと、ローカルサーバユニットと、ミドルウェアユニットとを含む。ミドルウェアユニットはHTTPプロキシユニットを制御し、ミドルウェアユニットは論理回路を備えるハードウェアベースの処理ユニットによって実装される。ミドルウェアユニットは、メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信することと、メディアデータの第1のセットを受信した後、ブロードキャストサービスがもはや利用可能でないと判定することと、ブロードキャストサービスがもはや利用可能でないとの判定に基づいて、クライアントデバイスによって実行されるストリーミングアプリケーションから、ユニキャストサービスを介してメディアセッションのメディアデータの第2のセットを取り出す要求を受信することであって、要求がクライアントデバイスの外部のアドレスを指定する、受信することと、要求に応答して、メディアデータの第2のセットがブロードキャストサービスを介して以前に受信されているとき、要求をクライアントデバイスの外部のアドレスの代わりにローカルサーバユニットにリダイレクトすることをHTTPプロキシユニットに行わせることとを行うように構成され、メディアデータの第2のセットはブロードキャストサービスを介して以前に受信されている。
【００１１】
別の例では、取り出すためのデバイスは、ハイパーテキスト転送プロトコル(HTTP)プロキシユニットとローカルサーバユニットとを含む。デバイスは、メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信するための手段と、メディアデータの第1のセットを受信した後、ブロードキャストサービスがもはや利用可能でないと判定するための手段と、ブロードキャストサービスがもはや利用可能でないとの判定に基づいて、クライアントデバイスによって実行されるストリーミングアプリケーションから、ユニキャストサービスを介してメディアセッションのメディアデータの第2のセットを取り出すことの要求を受信するための手段であって、要求がクライアントデバイスの外部のアドレスを指定する、手段と、要求に応答して、メディアデータの第2のセットがブロードキャストサービスを介して以前に受信されているとき、要求をクライアントデバイスの外部のアドレスの代わりにローカルサーバユニットにリダイレクトすることをHTTPプロキシユニットに行わせるための手段とをさらに含み、メディアデータの第2のセットはブロードキャストサービスを介して以前に受信されている。
【００１２】
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、命令は、実行されたとき、クライアントデバイスのミドルウェアユニットを備えるプロセッサであって、ミドルウェアユニットがクライアントデバイスのハイパーテキスト転送プロトコル(HTTP)プロキシユニットを制御し、クライアントデバイスがローカルサーバユニットを含む、プロセッサに、メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信することと、メディアデータの第1のセットを受信した後、ブロードキャストサービスがもはや利用可能でないと判定することと、ブロードキャストサービスがもはや利用可能でないとの判定に基づいて、クライアントデバイスによって実行されるストリーミングアプリケーションから、ユニキャストサービスを介してメディアセッションのメディアデータの第2のセットを取り出す要求を受信することであって、要求がクライアントデバイスの外部のアドレスを指定する、受信することと、要求に応答して、メディアデータの第2のセットがブロードキャストサービスを介して以前に受信されているとき、要求をクライアントデバイスの外部のアドレスの代わりにローカルサーバユニットにリダイレクトすることをHTTPプロキシユニットに行わせることとを行わせ、メディアデータの第2のセットはブロードキャストサービスを介して以前に受信されている。
【００１３】
1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１４】
【図１】ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。
【図２】図1の取出しユニットの構成要素の例示的なセットをより詳細に示すブロック図である。
【図３】例示的なマルチディアコンテンツの要素を示す概念図である。
【図４】表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。
【図５】たとえば無線アクセスネットワーク(RAN)の様々なサービスエリアを示す概念図である。
【図６】本開示の技法による、MooDサービスに対するエンドツーエンドアーキテクチャを示す概念図である。
【図７】DASH HTTP要求がHTTPプロキシにダイレクトされる本開示の技法による例示的な技法を示す概念図である。
【図８】メディアタイプ(たとえば、ビデオおよびオーディオ)当たりに1つの表現を有する例示的なメディアプレゼンテーション記述(MPD)を示す概念図である。
【図９】ユニキャストからブロードキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するための例示的な技法を示す概念図である。
【図１０】ブロードキャストからユニキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するための例示的な技法を示す概念図である。
【図１１】本開示の技法による、ブロードキャストからユニキャストへの切り換えの間のHTTPプロキシに対する例示的な構成を示す概念図である。
【図１２】MPDが複数の表現を含む例示的な使用事例を示す概念図である。
【図１３】図12に関して説明した使用事例による例示的な技法を示す概念図である。
【図１４】例示的なサーバ/ネットワーク支援型DASH(SAND)実施メッセージを示す概念図である。
【図１５】HTTP300応答を(たとえば、HTTPプロキシユニットから)受信するときのDASHクライアント挙動の一例を示す概念図である。
【図１６】ブロードキャストからユニキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するときの、図12の使用事例による例示的な技法を示す概念図である。
【図１７】SAND支援を受けるときのDASHクライアント挙動の一例を示す概念図である。
【図１８】本開示による、eMBMS DASHアウェアネットワーク要素(DANE)を使用するための例示的な技法を示す概念図である。
【図１９】本開示による、eMBMS DASHアウェアネットワーク要素(DANE)を使用するための例示的な技法を示す概念図である。
【図２０】代替ローカルセグメントを使用するためにHTTPプロキシユニットがDASHクライアントを支援する例示的な技法を示す概念図である。
【図２１】本開示による一例においてSANDメッセージ内に含まれ得るデータを示す概念図である。
【図２２】本開示によるSANDメッセージ内に含まれ得るデータの別の例示的なセットを示す概念図である。
【図２３】複数の表現を有する例示的なMPDを示す概念図である。
【図２４】図23の使用事例による、ユニキャストからブロードキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するための例示的な技法を示す概念図である。
【図２５】図23および図24の使用事例による、ユニキャストからブロードキャストへの切り換えの間の例示的なSANDメッセージを示す概念図である。
【図２６】図23〜図25の使用事例による、ブロードキャストからユニキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシを構成するための例示的な技法を示す概念図である。
【図２７】本開示の態様による、MPDのデータの例示的なセットを示す概念図である。
【図２８】図27の使用事例に対するSANDメッセージ内に含まれ得るデータの例示的なセットを示す概念図である。
【図２９】代替ローカルセグメントを使用するためにDASHクライアントを支援するためにDANEを使用するための例示的な技法を示す概念図である。
【図３０】本開示の技法による例示的な方法を示すフローチャートである。
【発明を実施するための形態】
【００１５】
本開示の技法は、ISOベースメディアファイルフォーマット、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンストビデオコーディング(AVC)ファイルフォーマット、第3世代パートナーシッププロジェクト(3GPP)ファイルフォーマット、および/もしくはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
【００１６】
HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)と関連付けられたファイルのヘッダを取り出し、この場合、URLまたはURNと関連付けられたペイロードを取り出すことはない。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、この場合、バイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、HTTPストリーミングに動画フラグメントが利用されてもよい。動画フラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在してもよい。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントがアクセス可能なデータの構造化された集合体であってもよい。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示してもよい。
【００１７】
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
【００１８】
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含んでもよい。周期は、MPDにおける周期要素によって定義されてもよい。各周期は、MPDにおける属性startを有してもよい。MPDは、周期ごとにstart属性とavailableStartTime属性とを含んでもよい。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
【００１９】
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含んでもよい。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであってもよい。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なる場合がある。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用される場合がある。
【００２０】
ある特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられてもよい。同じ適応セット内の表現は、概して、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられてもよいので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択されてもよい。いくつかの例では、1つの期間内のメディアコンテンツは、グループ0が存在する場合にはグループ0からの1つの表現によって表されてもよく、あるいは各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表されてもよい。ある期間の各表現のタイミングデータは、期間の開始時間に対して表されてもよい。
【００２１】
表現は1つまたは複数のセグメントを含んでもよい。各表現が初期化セグメントを含んでもよく、または表現の各セグメントが自己初期化するものであってもよい。初期化セグメントは、それが存在する場合、表現にアクセスするための初期化情報を含んでもよい。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照されてもよい。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
【００２２】
それぞれに異なるタイプのメディアデータに対して実質的に同時に取出しを行うためにそれぞれに異なる表現が選択されてもよい。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅に適応するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
【００２３】
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実施する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74または別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
【００２４】
図1の例では、コンテンツ準備デバイス20は、オーディオソース22とビデオソース24とを備える。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備えてもよい。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備えてもよい。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備えてもよい。コンテンツ準備デバイス20は必ずしも、すべての例において、サーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶する場合がある。
【００２５】
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含んでもよい。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化されてもよい。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を備えてもよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を備えてもよい。このようにして、本開示において説明する技法は、ライブオーディオデータおよびビデオデータ、ストリーミングオーディオデータおよびビデオデータ、リアルタイムオーディオデータおよびビデオデータに適用されてもよく、あるいは保管されたオーディオデータおよびビデオデータ、以前に記録されたオーディオデータおよびビデオデータに適用されてもよい。
【００２６】
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に包含されたビデオソース24によってキャプチャ(または、生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または、生成)されたオーディオデータを包含するオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応する場合がある。したがって、ビデオフレームに対応するオーディオフレームは、一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。当然、オーディオデータが別の言語用にダビングされる場合、またはビデオデータが取り込まれた後で音効果もしくはナレーションが付加される場合などには、オーディオおよびビデオデータは、必ずしも同時に取り込まれる必要があるとは限らない。
【００２７】
いくつかの例では、オーディオエンコーダ26は、符号化された各オーディオフレームにおいて、符号化されたオーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプを符号化してもよく、同様に、ビデオエンコーダ28は、符号化された各ビデオフレームにおいて、符号化されたビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプを符号化してもよい。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含んでもよい。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成する場合がある内部クロック、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用する場合がある内部クロックを含んでもよい。
【００２８】
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に相当するデータをオーディオエンコーダ26に送ってもよく、ビデオソース24は、ビデオデータが記録された時間に相当するデータをビデオエンコーダ28に送ってもよい。いくつかの例では、オーディオエンコーダ26は、符号化されたオーディオデータにおいて、符号化されたオーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化してもよく、同様に、ビデオエンコーダ28も、符号化されたビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用してもよい。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
【００２９】
オーディオエンコーダ26は、一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の、デジタル的にコーディングされた(場合によっては、圧縮された)単一の構成要素である。たとえば、表現のコーディングされたビデオまたはオーディオの部分は、エレメンタリストリームであってもよい。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは、一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
【００３０】
ITU-T H.264/AVCおよび来たるべき高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって指定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に対応し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。
【００３１】
たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの指定されたサイズのようなビットストリーム内のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、特定のプロファイル内のシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム内のシンタックス要素の値に課される制約の指定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であってもよい。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとってもよい。個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートしてもよいことを、H.264規格はさらに規定する。
【００３２】
プロファイルに準拠するデコーダは、普通、プロファイル内で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル内で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈可能性のために有用である場合がある。たとえば、ビデオ送信中、プロファイルおよびレベルの定義のペアが、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCでは、レベルは、処理される必要があるマクロブロックの数、復号されたピクチャバッファ(DPB:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMBあたりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを決定することができる。
【００３３】
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコーディングされたビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコーディングされたオーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化されたデータからPESパケットを形成するためのパケタイザを含む場合がある。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26の各々は、符号化されたデータからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化されたオーディオデータおよび符号化されたビデオデータからPESパケットを形成するためのパケタイザを含む場合がある。
【００３４】
ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つまたは複数のビューを有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの異なる表現を生成してもよい。本開示において使用される表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプション用の)テキストデータ、または他のそのようなデータのうちの1つを含んでもよい。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含んでもよい。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含んでもよい。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームをアセンブルする役割を担う。
【００３５】
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類されてもよい。VCLユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および/またはスライスレベルのデータを含み得る。他のNALユニットは、非VCL NALユニットであってもよい。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニット内に包含され得る。
【００３６】
非VCL NALユニットは、特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)内に)シーケンスレベルヘッダ情報を包含し、(ピクチャパラメータセット(PPS)内に)頻繁には変化しないピクチャレベルヘッダ情報を包含し得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがって、コーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を有効化することができ、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。
【００３７】
補足エンハンスメント情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに包含され得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおけるビュースケーラビリティ情報SEIメッセージなどのSEIメッセージ内に包含され得る。これらの例示的なSEIメッセージは、たとえば、動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
【００３８】
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを出力インターフェース32に与えてもよい。出力インターフェース32は、ネットワークインターフェースもしくはユニバーサルシリアルバス(USB)インターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェースのような記憶媒体へ書き込むためのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを備えてもよい。カプセル化ユニット30は、マルチメディアコンテンツの表現のそれぞれの表現のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送ることができる。図1の例では、サーバデバイス60は、それぞれのマニフェストファイル66と1つまたは複数の表現68A〜68N(表現68)とをそれぞれが含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
【００３９】
いくつかの例では、表現68は、適応セットへと分割されてもよい。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を識別する場合があるテキストタイプ情報、カメラの角度または適応セット内の表現のシーンの現実世界のカメラの視野を表す場合があるカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報のような、特性のそれぞれの共通のセットを含んでもよい。
【００４０】
マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、ならびに適応セットの共通の特性を含んでもよい。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含んでもよい。このようにして、適応セットは、簡略化されたネットワーク帯域幅適応を可能にする場合がある。適応セット内の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示されてもよい。
【００４１】
サーバデバイス60は、要求処理ユニット70とネットワークインターフェース72とを含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のうちのいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送受信するように構成される。
【００４２】
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求をクライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に記述されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する場合がある。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答して、マルチメディアコンテンツ64のデータを提供するように構成されてもよい。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。
【００４３】
追加または代替として、要求処理ユニット70は、ブロードキャストまたはeMBMSなどのマルチキャストサービス/プロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントをeMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループと関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)と関連付けられたクライアントデバイスに広告することができる。次に、クライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえば、ネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループと関連付けられたIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
【００４４】
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応する場合があるマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含んでもよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含んでもよい。クライアントデバイス40は、メディアプレゼンテーションのマニフェストファイル66(たとえば、MPD)を取り出し、表現68のセグメントにどのようにアクセスするかを判定してもよい。
【００４５】
特に、取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を決定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能のすべてまたは一部は、ハードウェア、もしくはハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
【００４６】
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定することができる。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内の表現に対するビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
【００４７】
概して、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を介してマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
【００４８】
追加または代替として、取出しユニット52は、ブロードキャスト、またはMBMS、eMBMSまたはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。
【００４９】
本開示の技法によれば、取出しユニット52は、ブロードキャスト/マルチキャストサービスが利用可能であるか否かに応じて、ブロードキャストもしくはマルチキャストサービスまたはユニキャストサービスのいずれかに従ってメディアデータを取り出す/受信することができる。具体的には、取出しユニット52は、ブロードキャスト/マルチキャストサービスが利用可能または利用不可能になるときに、ブロードキャスト/マルチキャストサービスとユニキャストサービスとの間を切り換えてよい。その上、時々、ブロードキャスト/マルチキャストサービスを介して受信されたデータはキャッシュされてよく、ブロードキャスト/マルチキャストサービスが利用不可能になった後もキャッシュされたままであってよい。したがって、取出しユニット52は、メディアデータをユニキャストサービスを介して受信する前または間に、ブロードキャスト/マルチキャストサービスを介して受信されたキャッシュされているデータを使用してよい。
【００５０】
たとえば、取出しユニット52は、メディアデータのためのキャッシュを実装するメモリを含み得る。また、取出しユニット52は、ブロードキャスト/マルチキャストユニットと、プロキシユニットと、ローカルサーバと、DASHクライアントなどのストリーミングクライアントとを含み得る。ブロードキャスト/マルチキャストユニットがブロードキャストまたはマルチキャストを介してデータを受信するとき、ブロードキャスト/マルチキャストユニットはメモリのキャッシュ内にデータをキャッシュし得る。その後、ブロードキャスト/マルチキャストサービスは、たとえばクライアントデバイス40が、ブロードキャスト/マルチキャストサービスが利用可能でない(たとえば、サーバデバイス60によって提供されない)地理的エリアに物理的に移動したので、利用不可能になる場合がある。
【００５１】
概して、ストリーミングクライアントは、HTTP GET要求または部分GET要求をローカルサーバまたは外部サーバのいずれかに送信してよいが、プロキシユニットが要求をインターセプトする場合がある。プロキシユニットは、要求されたメディアデータがローカルに(たとえば、キャッシュ内で)利用可能であるときにローカルサーバか、または要求されたメディアデータがローカルに利用可能でないときに外部サーバ(たとえば、サーバデバイス60)のいずれかに要求をリダイレクトするように構成されてよい。したがって、取出しユニット52は、ユニキャストサービスに直ちに転送するのではなく、ブロードキャスト/マルチキャストサービスを介して以前に受信されている、キャッシュからのメディアデータを配信するために、メディアデータに対する要求をローカルサーバにリダイレクトすることをプロキシユニットに行わせてよい。取出しユニット52は、切り換え点(たとえば、ビデオデータの瞬時デコーダリフレッシュ(IDR)ピクチャ)においてユニキャストを介して後続のメディアデータを取り出してよく、ブロードキャスト/マルチキャストサービスを介して受信されたキャッシュされているメディアデータがすべて消費される時点またはその前にこのデータが利用可能であるように、このデータをキャッシュしてよい。
【００５２】
マニフェストファイルは、メディアデータがそのアドレスから利用可能となるIPアドレスを示し得る。ブロードキャスト/マルチキャストサービスが利用可能であるとき、IPアドレスはローカルサーバに対応してよいが、ブロードキャスト/マルチキャストサービスが利用可能でないとき、IPアドレスはサーバデバイス60などの外部サーバデバイスに対応してよい。一般に、ストリーミングクライアント(たとえば、DASHクライアント)は、メディアデータに対する要求を公表されたIPアドレスにダイレクトするように構成されてよい。しかしながら、取出しユニット52のプロキシユニットは要求をインターセプトしてよく、たとえばメディアデータがブロードキャスト/マルチキャストサービスを介して以前に受信されているとき、要求されたメディアデータがローカルサーバから実際に利用可能であるかどうかを判定してよい。
【００５３】
すなわち、ストリーミングクライアントは、サーバデバイス60のIPアドレスを示すマニフェストファイルに基づいて、HTTP GET要求または部分GET要求をサーバデバイス60のIPアドレスにダイレクトしてよい。しかしながら、いくつかの状況では、ブロードキャスト/マルチキャストサービスが利用可能でないにもかかわらず、ブロードキャスト/マルチキャストサービスを介して受信された要求されるメディアデータがローカルサーバからキャッシュ内で利用可能であるとき、プロキシユニットは、この要求をローカルサーバ(たとえば、クライアントデバイス40のローカルホストアドレス)にリダイレクトしてもよい。たとえば、プロキシユニットは、ローカルサーバのIPアドレス(たとえば、クライアントデバイス40のローカルホストアドレス)を指定し得るHTTP3xxタイプ応答(たとえば、HTTP300応答)によってHTTP GETまたは部分GETに応答し得る。このようにして、ローカルサーバによって提供されるメディアデータがブロードキャスト/マルチキャストサービスによってメディアデータを受信する場合にブロードキャスト/マルチキャストサービスが利用可能でないときでも、プロキシユニットは、メディアデータをローカルサーバから取り出すことをクライアントデバイスに行わせることができる。
【００５４】
いくつかの例では、メディアデータに対するマニフェストファイルは、複数の表現が利用可能であることを示す場合があり、表現のうちの少なくとも1つはブロードキャスト/マルチキャストサービスを介して利用可能な表現に対応し、表現のうちの少なくとも1つの他の表現はユニキャストサービスを介して利用可能な表現に対応する。プロキシユニットは、サーバ/ネットワーク支援型DASH(SAND)実施メッセージをストリーミングクライアントに送信して、表現のうちの適切な1つからメディアデータを取り出すことをストリーミングクライアントに行わせることができる。たとえば、ブロードキャスト/マルチキャストサービスが利用可能である場合、SAND実施メッセージは、ブロードキャスト/マルチキャストサービスに対応する表現のメディアデータを取り出すことをストリーミングクライアントに行わせる命令または構成データを含み得る。同様に、ブロードキャスト/マルチキャストサービスが利用可能でないが、ブロードキャスト/マルチキャストサービスを介して以前に受信されたメディアデータが利用可能である場合、SAND実施メッセージは、ブロードキャスト/マルチキャストサービスに対応する表現のメディアデータを取り出すことをストリーミングクライアントに行わせる命令または構成データを含み得る。
【００５５】
一方、ブロードキャスト/マルチキャストサービスが利用可能でない場合(および、ブロードキャスト/マルチキャストサービスを介して以前に受信されたメディアデータが利用可能でない場合)、SAND実施メッセージは、ユニキャストサービスに対応する表現のメディアデータを取り出すことをストリーミングクライアントに行わせる命令または構成データを含み得る。
【００５６】
SAND実施メッセージのそのような命令/構成データは、たとえば、適切な表現を識別するURIプレフィックスを含むベースURLフィールドと、関連するリソース(たとえば、表現および/または表現のセグメント)のステータスを表す1つまたは複数のステータスフィールドとを含み得る。SAND実施メッセージは、ストリーミングクライアントからのHTTP GET要求に対するHTTP300応答を含んでよく、HTTP300応答は、たとえば、ブロードキャスト/マルチキャストサービスに関連する表現のうちの1つの識別子を含む。
【００５７】
上述のように、クライアントデバイス40は、サービスエリア間を地理的に移送される場合があり、いくつかのサービスエリアでは、ブロードキャスト/マルチキャストサービスは利用可能であり、他のサービスエリアでは、ブロードキャスト/マルチキャストサービスは利用可能でない。したがって、当然、取出しユニット52は、ブロードキャスト/マルチキャストサービスが利用可能でないサービスエリアに移動した後、ユニキャストサービスを使用してメディアデータを取り出す場合がある。同様に取出しユニット52は、その後ブロードキャスト/マルチキャストサービスが利用可能であるサービスエリアに戻り、再びブロードキャスト/マルチキャストサービスを介してメディアデータを受信する場合がある。
【００５８】
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力44に送る。
【００５９】
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は、各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路のいずれかとして実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダ内に含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話のようなワイヤレス通信デバイスを備え得る。
【００６０】
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法について説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりに(または、加えて)これらの技法を実行するように構成され得ることを理解されたい。
【００６１】
カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームを記述するデータを特定するヘッダを含むNALユニットを形成してもよい。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含み得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含んでもよい。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。
【００６２】
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットをアセンブルしてもよい。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含んでもよい。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが毎秒20フレーム(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応する場合がある。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされてもよい。一例では、アクセスユニットは、コーディングされた一次ピクチャとして提示される場合がある、1つの時間インスタンス内のコーディングされたピクチャを含んでもよい。
【００６３】
したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時刻Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時刻における特定のビューに対する符号化ピクチャ(またはフレーム)を含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
【００６４】
メディアプレゼンテーションは、それぞれに異なる代替表現(たとえば、それぞれに異なる品質を有するビデオサービス)の記述を含む場合があるメディアプレゼンテーション記述(MPD)を含んでもよく、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含んでもよい。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定することができる。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス(moofボックス)内に配置され得る。
【００６５】
マニフェストファイル66(たとえば、MPDを含み得る)は、表現68のセグメントの可用性を広告することができる。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス40の取出しユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になるときを決定することができる。
【００６６】
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルにアセンブルした後、カプセル化ユニット30は、ビデオファイルを出力できるように出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送る代わりに、ビデオファイルをローカルに記憶するか、または出力インターフェース32を介してビデオファイルをリモートサーバに送ることができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえば、オプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピー(登録商標)ドライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを備え得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体にビデオファイルを出力する。
【００６７】
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供する。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力44に送る。
【００６８】
図2は、図1の取出しユニット52の構成要素の例示的なセットをより詳細に示すブロック図である。この例では、取出しユニット52は、eMBMSミドルウェアユニット100と、DASHクライアント110と、メディアアプリケーション112とを含む。
【００６９】
この例では、eMBMSミドルウェアユニット100は、eMBMS受信ユニット106と、キャッシュ104と、ローカルサーバユニット102と、HTTPプロキシユニット108とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、T. Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月(http://tools.ietf.org/html/rfc6726において入手可能)に記載された単方向伝送によるファイル配信(FLUTE)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、たとえば、BM-SCとして機能し得るサーバデバイス60からブロードキャストを介してファイルを受信することができる。
【００７０】
eMBMSミドルウェアユニット100がファイルに関するデータを受信すると、eMBMSミドルウェアユニットは受信したデータをキャッシュ104内に記憶することができる。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体など、コンピュータ可読記憶媒体を含んでもよい。
【００７１】
ローカルサーバユニット102は、DASHクライアント110に関するサーバとして機能してもよい。たとえば、ローカルサーバユニット102は、MPDファイルまたは他のマニフェストファイルをDASHクライアント110に提供してもよい。ローカルサーバユニット102は、MPDファイル内、ならびにセグメントが取り出され得るハイパーリンク内のセグメントに関する利用可能時間を通知してもよい。これらのハイパーリンクは、クライアントデバイス40に対応するローカルホストアドレスプレフィックス(たとえば、IPv4に関する127.0.0.1)を含み得る。このようにして、DASHクライアント110は、HTTP GET要求または部分GET要求を使用して、ローカルサーバユニット102にセグメントを要求してもよい。たとえば、リンクhttp://127.0.0.1/rep1/seg3から利用可能なセグメントに関して、DASHクライアント110は、http://127.0.0.1/rep1/seg3に関する要求を含むHTTP GET要求を作成し、その要求をローカルサーバユニット102にサブミットしてもよい。ローカルサーバユニット102は、キャッシュ104から要求されたデータを取り出し、そのような要求に応答して、そのデータをDASHクライアント110に与えてもよい。
【００７２】
さらに、本開示の技法によれば、HTTPプロキシユニット108は、DASHクライアント110に対するプロキシとして働く場合がある。たとえば、これらの技法によれば、HTTPプロキシユニット108は、DASHクライアント110からのデータに対する要求をインターセプトする場合がある。ブロードキャスト受信モードであるとき、eMBMS受信ユニット106は、ブロードキャストを介してDASHセグメントを受信し、DASHセグメントをキャッシュ104に記憶する。ユニキャスト取出しモードでは、DASHクライアント110は、取出しユニット52を含むクライアントデバイス(たとえば、クライアントデバイス40)とは別に、コンテンツ配信ネットワーク(CDN)(図示せず)からDASHセグメントを取り出すことの要求を提出してよい。しかしながら、HTTPプロキシユニット108は、これらの要求をインターセプトし、要求されたセグメントは、以前にブロードキャスト受信モードの間に受信されているかどうかを判定し、受信されている場合、要求をローカルサーバユニット102にリダイレクトしてよい。
【００７３】
たとえば、HTTPプロキシユニット108は、要求されたセグメントをローカルサーバユニット102から取り出すことをDASHクライアント110に行わせるために、ローカルサーバユニット102と関連付けられたローカルホストアドレスを含むHTTP300応答をDASHクライアント110に送信してよい。一方、セグメントがキャッシュ104内にキャッシュされていない場合、HTTPプロキシユニット108は要求をCDNに転送してよい。これらの技法の追加の詳細について、以下でさらに詳しく説明する。
【００７４】
図3は、例示的なマルチメディアコンテンツ120の要素を示す概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数の表現124A〜124N(表現124)とを含む。表現124Aは、任意のヘッダデータ126とセグメント128A〜128N(セグメント128)とを含む一方、表現124Nは、任意のヘッダデータ130とセグメント132A〜132N(セグメント132)とを含む。文字Nが、便宜的に、表現124の各々内の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現124の間に、異なる数の動画フラグメントが存在し得る。
【００７５】
MPD122は、表現124とは別個のデータ構造を含み得る。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124は、図1の表現68に対応する場合がある。一般に、MPD122は、コーディング特性およびレンダリングの特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現124の特性を一般に表す、データを含み得る。
【００７６】
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在する場合、セグメント132の同様の特性を記述することができる。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
【００７７】
セグメント128、132は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。MPD122のデータは、図3の例には示されていないが、そのような特性は、MPD122のデータによって記述され得る。MPD122は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
【００７８】
セグメント128、132の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント128または132を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント128または132の特定のバイト範囲を取り出すことができる。
【００７９】
本開示の技法によれば、MPD122は、以下、たとえば、図8、図12、図17、図23、および/または図27に示すようなデータを含み得る。
【００８０】
図4は、図3のセグメント128、132のうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイル150の要素を示すブロック図である。セグメント128、132の各々は、図4の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図4の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、動画(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と動画フラグメント(MOOF)ボックス164と、動画フラグメントランダムアクセス(MFRA)ボックス166とを含む。図4は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従ってビデオファイル150のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、時限のテキストデータなど)を含み得る。
【００８１】
ファイルタイプ(FTYP)ボックス152は一般に、ビデオファイル150のファイルタイプを表す。ファイルタイプボックス152は、ビデオファイル150の最良の使用法を表す仕様を特定するデータを含んでもよい。ファイルタイプボックス152は、代替的には、MOOVボックス154、ムービーフラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
【００８２】
いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル150のセグメントタイプを定義し得る。以下でより詳細に論じる図7は、MPD更新ボックスに関する追加の情報を提供する。
【００８３】
MOOVボックス154は、図4の例では、動画ヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数の動画延長(MVEX)ボックス160とを含む。一般に、MVHDボックス156は、ビデオファイル150の一般的な特性を表してもよい。たとえば、MVHDボックス156は、ビデオファイル150がいつ最初に作成されたかを表すデータ、ビデオファイル150がいつ最後に修正されたかを表すデータ、ビデオファイル150のタイムスケールを表すデータ、ビデオファイル150の再生の長さを表すデータ、または、ビデオファイル150を全般的に表す他のデータを含んでもよい。
【００８４】
TRAKボックス158は、ビデオファイル150のトラックのデータを含んでもよい。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を記述する、トラックヘッダ(TKHD)ボックス(図示せず)を含んでもよい。いくつかの例では、TRAKボックス158は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは、TRAKボックス158のデータおよび/またはsidxボックス162のデータによって参照され得る動画フラグメント164内に含まれ得る。
【００８５】
いくつかの例では、ビデオファイル150は、2つ以上のトラックを含み得る。したがって、MOOVボックス154は、ビデオファイル150中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を記述する場合がある。たとえば、TRAKボックス158は、対応するトラックの時間情報および/または空間情報を表す場合がある。MOOVボックス154のTRAKボックス158と同様のTRAKボックスは、カプセル化ユニット30(図1)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を記述してもよい。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングしてもよい。
【００８６】
MVEXボックス160は、たとえば、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150がムービーフラグメント164を含むことをシグナリングするために、対応するムービーフラグメント164の特性を記述し得る。ストリーミングビデオデータの文脈では、コード化ビデオピクチャは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。したがって、すべてのコード化ビデオサンプルは、MOOVボックス154の中ではなくムービーフラグメント164の中に含まれ得る。
【００８７】
MOOVボックス154は、ビデオファイル150の中のムービーフラグメント164の数に等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、ムービーフラグメント164の対応する1つの特性を記述し得る。たとえば、各MVEXボックスは、ムービーフラグメント164の対応する1つの持続時間を記述するムービー延長ヘッダ(MEHD)ボックス(図示せず)を含み得る。
【００８８】
上述したように、カプセル化ユニット30は、実際のコード化ビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶してもよい。ビデオサンプルは、一般に、アクセスユニットに対応してもよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を包含する、1つまたは複数のVCL NALユニットをコード化ピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、ムービーフラグメント164のうちの1つの中に含み得る。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、ムービーフラグメント164の1つに対応するMVEXボックス160の1つの中のムービーフラグメント164の1つの中に存在するものとして、シグナリングすることができる。
【００８９】
SIDXボックス162は、ビデオファイル150の任意の要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含むとは限らない。3GPPファイルフォーマットの例によれば、SIDXボックスは、セグメント(たとえば、ビデオファイル150内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「メディアデータボックスに対応する1つまたは複数の連続するムービーフラグメントボックスの自己完結型セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスが、そのムービーフラグメントボックスに続き、同じトラックについての情報を包含する次のムービーフラグメントボックスに先行する」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を包含する。参照されるサブセグメントは、プレゼンテーション時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照される材料におけるバイトの数のカウントを与える。」ことを示す。
【００９０】
SIDXボックス162は、一般に、ビデオファイル150内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、(1)サブセグメントが開始および/または終了する再生時間、(2)サブセグメントに関するバイトオフセット、(3)サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、(4)SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、(5)サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。
【００９１】
ムービーフラグメント164は、1つまたは複数のコード化ビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント164は、1つまたは複数のピクチャのグループ(GOP)を含んでよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含み得る。加えて、上記で説明したように、ムービーフラグメント164は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント164の各々は、ムービーフラグメントヘッダボックス(MFHD、図4には示されない)を含み得る。MFHDボックスは、ムービーフラグメントのシーケンス番号などの、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント164は、ビデオファイル150の中でシーケンス番号の順番に含まれ得る。
【００９２】
MFRAボックス166は、ビデオファイル150のムービーフラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)の探索を実行するなど、トリックモードを実行することを支援し得る。MFRAボックス166は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正確に復号し表示するために、MFRAボックス166を必ずしも参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでよく、またはいくつかの例では、ビデオファイル150のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでよい。
【００９３】
いくつかの例では、ムービーフラグメント164は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SPAのビデオファイル150内の位置の指標を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
【００９４】
図5は、たとえば無線アクセスネットワーク(RAN)の様々なサービスエリアを示す概念図である。サービスエリアの一部または全部は、たとえば、www.3gpp.org/DynaReport/26849.htmにおいて利用可能な「3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS) improvements; MBMS operation on demand (Release 12)」、3GPP TR 26.849バージョン12.0.0、2014年12月12日、に従ってMBMSオペレーションオンデマンド(MooD)サービスを提供し得る。クライアントデバイス40(図1)などのクライアントデバイスは、サービスエリア識別子(SAI)、SAI1、SAI2およびSAI3によってここで識別されるサービスエリア、または他のサービスエリアの間を移動する場合がある。いくつかのサービスエリアがMooDサービスを提供するが、他のサービスエリアが提供しない場合があるので、クライアントデバイスは、ブロードキャスト(たとえば、eMBMS)を介してデータを受信すること、またはユニキャストを使用してメディアデータを取り出すことのいずれかを行うように構成されてよい。具体的には、クライアントデバイス40は、MooDサービスが提供されるサービスエリア内でMooDサービスを介してメディアデータを受信してよく、かつMooDサービスが提供されないサービスエリア内でユニキャストサービスを介してメディアデータを取り出してもよい。
【００９５】
本開示の技法による一使用事例は、ネットワーク事業者がサービスエリア、SAI1、SAI2およびSAI3(会場近傍、駐車場、など)内でMooDサービスを提供することを計画しているときを対象とする。サービスは、ユーザサービス記述(USD)内で完全に記述されてよく、したがってUSD更新はカバレージ内の変更をシグナリングするために必要でない。USDは、たとえば計画されたカバレージに関するサービスエリア情報、サービスに対する一時的モバイルグループ識別情報(TMGI)を記述してよく、単一のMPDがすべてのブロードキャストおよび/またはユニキャスト表現を記述してよい。
【００９６】
この例では、MooDサービスに対するTMGIアクティブ化は、以下を含み得る。ネットワークは、最初にSAI1内のTMGIをアクティブ化してよい。SAI2において特定されるユーザ機器(UE)(すなわち、クライアントデバイス40などのクライアントデバイス)に対して、TMGIはアクティブでない。クライアントデバイス40は、最初に、ユニキャストを使用するサービスを消費することを開始してよい。ユニキャスト負荷(消費報告を介する)に基づいて、ネットワークは、その後、SAI2におけるTMGIをアクティブ化してよい。次いで、クライアントデバイス40は、それの現在のサービスエリア(たとえば、SAI2)内でTMGIがアクティブであるとき、ブロードキャストに切り換えてよい。
【００９７】
図6は、本開示の技法による、MooDサービスに対するエンドツーエンドアーキテクチャ180を示す概念図である。この例では、アーキテクチャ180は、ユーザ機器(UE)182と、無線エリアネットワーク/発展型パケットコア(RAN/EPC)190と、コンテンツ配信ネットワーク(CDN)192と、DASHエンコーダ194と、ブロードキャストマルチキャストサービスセンター(BMSC)196とを含む。UE182は、図1のクライアントデバイス40に対応し得る。DASHエンコーダ194は、図1のコンテンツ準備デバイス20の要素に対応し得る。
【００９８】
DASHエンコーダ194は、ユニキャスト(UC)を介してセグメントを提供し得るCDN192を介して利用可能なセグメントと、MBMSまたはeMBMSなどのブロードキャストまたはマルチキャストサービスを提供するBMSC196を介して利用可能なセグメントとを作成し得る。
【００９９】
UE182は、DASHクライアント184と、HTTPプロキシ186と、eMBMSミドルウェアユニット188とを含む。この例では、HTTPプロキシ186は、DASHクライアント184からHTTP GET要求をインターセプトし、それらのHTTP GET要求をCDN192またはミドルウェアユニット188にリダイレクトする。DASHクライアント184は、セグメントがUE182に、ユニキャストまたはブロードキャストを介して配信されるかどうかにとらわれない。
【０１００】
BMSC196は、消費報告ユニット198と、FLUTEユニット200と、取り込みインターフェース202とを含む。一般に、BMSC196は、メディアデータを取り込みインターフェース202を介してDASHエンコーダ194から受信し、そのメディアデータをFLUTEユニット200を介してFLUTEプロトコルに従って送信する。
【０１０１】
この例では、UE182は、消費報告をBMSC196内で示す消費報告ユニット198に送信する。UE182は、サービス、たとえばブロードキャストまたはマルチキャストサービスに従ってメディアデータを消費するときの周期的消費報告だけでなく、メディアデータ再生の開始および停止も報告する。BMSC196は、ブロードキャストが利用可能でないときにユニキャストを介してDASHコンテンツを消費するUEをカウントする。ユニキャスト負荷が何らかのしきい値を超えるとき、BMSC196はブロードキャスト配信を有効にしてよい。BMSC196は、ブロードキャストサービスが利用可能になると、ブロードキャストを介してDASHコンテンツを消費するUEをカウントする。ブロードキャストサービスを介してメディアデータを消費するUEの数が何らかのしきい値を下回るとき、BMSC196はブロードキャスト配信を無効にしてよい。
【０１０２】
図7は、DASH HTTP要求がHTTPプロキシにダイレクトされる本開示の技法による例示的な方法を示す概念図である。図7の方法は、図2の例示的な構成要素に関して説明される。しかしながら、図6のUE182などの他のデバイスが、同様に、図7の方法を実行するように構成されてもよいことを理解されたい。概して、この例示的な方法では、HTTPプロキシユニット108は、DASHクライアント110からのDASH要求をインターセプトし、これらの要求をローカルホスト(たとえば、ローカルサーバユニット102)または外部ユニキャストサーバに転送するように構成される。
【０１０３】
この例では、eMBMSミドルウェアユニット100は、HTTPプロキシユニット108を使用するために必要なサービスに関するHTTPプロキシ情報を含む。eMBMSミドルウェアユニット100に対するアプリケーションインターフェースは、プロキシ情報を含む。メディアアプリケーション112は、HTTPプロキシユニット108を使用するために(DASHクライアント110によって使用される)メディアプレーヤインターフェースを構成し得る。
【０１０４】
最初に、メディアアプリケーション112は、サービスリスト(たとえば、ユーザサービス記述(USD))をeMBMSミドルウェアユニット100から取り出す(210)。次いで、メディアアプリケーション112は、DASHサービス(たとえば、MooD)を開始するために命令を送信する(212)。eMBMSミドルウェアユニット100は、メディアデータを消費するためにブロードキャストもしくはマルチキャストを使用するかまたはユニキャストを使用するかを判定するために、MooDサービスが利用可能でかつアクティブであるかどうかを判定する(214)。いずれの場合も、この例では、eMBMSミドルウェアユニット100は、サービス開始通知をメディアアプリケーション112に送信する(216)。
【０１０５】
この例では、メディアアプリケーション112はHTTPプロキシユニット108を有効にし(218)、HTTPプロキシユニット108を使用するようにDASHクライアント110を構成する(220)。DASHクライアント110は、HTTPプロキシユニット108を使用するための構成が有効にされると、メディアアプリケーション112に応答する(222)。次いで、メディアアプリケーション112は、たとえばMPD内で公表されたURLに対応する再生を開始するための命令をDASHクライアント110に送信する(224)。DASHクライアント110は、次に、URLから利用可能なメディアデータを取得するためにHTTP GET要求をHTTPプロキシユニット108に送信する(226)。HTTPプロキシユニット108は、次に、要求されたメディアデータをローカルサーバユニット102からまたはユニキャストを使用してCDNから取り出す。いずれの場合も、HTTPプロキシユニット108は、メディアデータをDASHクライアント110に配信し、DASHクライアント110は、メディアデータをメディアアプリケーション112に返す。
【０１０６】
図8は、メディアタイプ(たとえば、ビデオおよびオーディオ)当たりに1つの表現を有する例示的なメディアプレゼンテーション記述(MPD)を示す概念図である。Rel 12では、ユーザサービス記述(USD)要素は、deliveryMethodの下にある。USD要素は、r12:broadcastAppServiceを介するブロードキャスト表現と、r12:unicastAppServiceを介するユニキャスト表現とを記述し得る。
【０１０７】
この例では、MPDは、メディア構成要素(たとえば、オーディオおよびビデオ)当たりに1つの表現を含む。同様に、MPD@timeShiftBufferDepthは、ゼロ(0)より大きい値を有する。図8の例では、ビデオデータ(「V1」として表される)およびオーディオデータ(「A1」として表される)は、deliveryMethodType要素の、r12:broadcastAppServiceのbasePattern要素において、およびr12:unicastAppServiceのbasePattern要素において指定され得る。
【０１０８】
図9は、ユニキャストからブロードキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するための例示的な技法を示す概念図である。図9は、図1、図2および図6の同様の構成要素に全体的に対応する様々な構成要素を含むシステム230を示す。具体的には、システム230は、DASHクライアント232(それは図2のDASHクライアント110または図6のDASHクライアント184に対応し得る)と、HTTPプロキシユニット234(それは図2のHTTPプロキシユニット108または図6のHTTPプロキシユニット186に対応し得る)と、プロキシ制御ユニット236(それはHTTPプロキシ自体の一部を形成してよくまたは別個の制御ユニットであってもよい)と、ローカルサーバ238(それは図2のローカルサーバユニット102または図6のeMBMSミドルウェアユニット188に対応し得る)と、CDNエッジサーバ240(それは図1のサーバデバイス60または図6のCDN192のサーバに対応し得る)とを含む。
【０１０９】
また、図9は、図の上部におけるタイムラインと、タイムラインの間の様々な時間において実行されるアクションとを示す。時間<T1において、HTTPプロキシ234はユニキャストを使用してセグメントをフェッチし、プロキシ制御ユニット236はリダイレクションルールを構成するためにUSDおよびMPDからの情報を使用する。具体的には、時間T1の前に、eMBMSが無効にされることが仮定される。それゆえ、プロキシ制御ユニット236は、リダイレクションを実行しないようにHTTPプロキシユニット234を構成する(242)。したがって、DASHクライアント232が特定のURIを指定するHTTP GET要求を提出する(244)とき、HTTPプロキシユニット234は、要求をCDNエッジサーバ240に転送する(246)。CDNエッジサーバ240は、要求されたメディアデータをHTTPプロキシユニット234に配信することによって応答し(248)、HTTPプロキシユニット234は、メディアデータをDASHクライアント232に転送する(250)。
【０１１０】
eMBMSが有効にされると、BM-SCは、ライブエッジセグメントをブロードキャストすることになる。時間=T1において、eMBMSが有効にされ、それゆえプロキシ制御ユニット236はセグメントが利用可能であることの表示をローカルサーバ238から受信する(252)。応答して、プロキシ制御ユニット236は、メディアデータに対する要求をローカルサーバユニット238にリダイレクトする(たとえば、DASHクライアント232およびHTTPプロキシ234を含むクライアントデバイスのローカルホストアドレスを指定する)ようにHTTPプロキシユニット234を構成する(254)。時間T1に続いて、ブロードキャストセグメントSNは利用可能であり、ローカルサーバにリダイレクトすることが有効にされる。したがって、DASHクライアント232がセグメントSNのURIを指定するHTTP GET要求をHTTPプロキシユニット234に送信する(256)とき、HTTPプロキシユニット234は、要求をローカルサーバ238にリダイレクトする(258)。要求されたセグメントが利用可能である場合、ローカルサーバ238はセグメントをHTTPプロキシユニット234に配信することになり(266)、HTTPプロキシユニット234はセグメントをDASHクライアント232に転送する(268)。
【０１１１】
DASHクライアントは、(時間シフトバッファ(TSB)窓内の)非ライブエッジセグメントを要求する場合がある。したがって、ローカルサーバユニット238は、要求されたセグメントは利用可能でないと判定してよく、HTTP404エラーをトリガする(260)。そのようなHTTP404エラーは、(たとえば、CDNエッジサーバから)ユニキャストフェッチを使用してローカルサーバ内で取り扱われ得る。すなわち、ローカルサーバ238は、セグメントをCDNエッジサーバ240から要求してよく(262)、CDNエッジサーバ240は、要求されたセグメントをローカルサーバ238に送信してよい(264)。次いで、ローカルサーバ238は、上記で説明したように、セグメントをHTTPプロキシユニット234に送信することを継続してよい。
【０１１２】
図10は、ブロードキャストからユニキャストへの切り換えの間にDASHクライアント232をダイレクトするようにHTTPプロキシユニット234を構成するための例示的な技法を示す概念図である。この例は、図9の例とのつながりであり得る。すなわち、図9および図10におけるタイムラインは同じものである。しかしながら、たとえば図9に関して上記で説明したように、ユニキャストからブロードキャストへの前のおよび/または後続の切り換えもまた行われてよいことを理解されたい。
【０１１３】
この例では、時間T2の前に、ブロードキャストサービスが利用可能である。したがって、システム230の構成要素は、図9に関して上記で説明したように動作し得る。すなわち、ブロードキャストサービスが利用可能であるとき、プロキシ制御ユニット236は、メディアデータに対する要求をローカルサーバユニット238にリダイレクトする(たとえば、DASHクライアント232およびHTTPプロキシ234を含むクライアントデバイスのローカルホストアドレスを指定する)ようにHTTPプロキシユニット234を構成する(270)。したがって、DASHクライアント232がセグメントのURIを指定するHTTP GET要求をHTTPプロキシユニット234に送信する(272)とき、HTTPプロキシユニット234は、要求をローカルサーバ238にリダイレクトする(274)。要求されたセグメントが利用可能である場合、ローカルサーバ238はセグメントをHTTPプロキシユニット234に配信することになり(282)、HTTPプロキシユニット234はセグメントをDASHクライアント232に転送する(284)。要求されたセグメントが利用可能でない場合、ローカルサーバ238は、セグメントをCDNエッジサーバ240からさらに要求してよく(278)、CDNエッジサーバ240は、要求されたセグメントをローカルサーバ238に配信してよい(280)。
【０１１４】
この例では、時間=T2において、ブロードキャストサービスはもはや利用可能でない。したがって、ローカルサーバ238は、セグメントがプロキシ制御ユニット236に対してもはや利用可能でないことを示すデータ、たとえば最後に受信されたセグメントの表示を送信してよい(286)。応答して、プロキシ制御ユニット236は、後続のセグメント要求を満足するためにユニキャストを使用するようにHTTPプロキシユニット234を構成してよい(286)。次いで、HTTPプロキシユニット234は、ローカルサーバ238にリダイレクトすることを停止する。従来、これは、DASHクライアント232がTSB窓内のセグメント(たとえば、セグメントSM-2)を要求した(290)場合、HTTPプロキシユニット234は要求をCDNエッジサーバ240に転送し、CDNエッジサーバ240はセグメントをHTTPプロキシユニット234に配信し(294)、HTTPプロキシユニット234はセグメントをDASHクライアント232に転送する(296)ことを意味することになる。しかしながら、1つまたは複数のセグメントは、ローカルに利用可能であるが配信可能でない場合がある。問題は、このことが、ユニキャストに遷移した後、ローカルにキャッシュされているセグメントの利用があまり効率的でないことである。本開示の技法によれば、以下でより詳細に説明するように、システム230は、ローカルサーバユニット238のキャッシュされているセグメントを従来の技法より効率的に使用するように構成され得る。
【０１１５】
図11は、本開示の技法による、ブロードキャストからユニキャストへの切り換えの間のHTTPプロキシユニット234に対する例示的な構成を示す概念図である。概して、プロキシ制御ユニット236は、[N_start、N_end]の間のセグメント番号を有するセグメントURLに対する要求をローカルサーバユニット238にダイレクトするようにHTTPプロキシユニット234を構成し、ローカルサーバユニット238から満足され得るセグメントURLのリストを提供する。この例では、N_startはローカルサーバ内でキャッシュされている最古のセグメントのセグメント番号を表し、一方N_endはローカルサーバ内でキャッシュされている最新のセグメントのセグメント番号を表す。ローカルサーバユニット238がキャッシュされているセグメントを除去すると、プロキシ制御ユニット236はリダイレクションルールを更新する。
【０１１６】
具体的には、この例では、ローカルサーバユニット238は、利用可能なセグメントのリストをプロキシ制御ユニット236に、たとえば初期リストの形態(300A)およびリストに対する周期的更新の形態(300B)で送信する。それゆえ、プロキシ制御ユニット236は、ローカルサーバ238から利用可能な特定のセグメントに対する要求をローカルサーバ238にリダイレクトすることをHTTPプロキシ234に行わせるリダイレクションルール(302A、302B)を用いてHTTPプロキシユニット234を構成する。したがって、DASHクライアント232がローカルサーバユニット238から利用可能なセグメントのリスト内のセグメントのうちの1つに対する要求を送信する(304)と、HTTPプロキシユニット234は要求をローカルサーバユニット238にリダイレクトし(306)、ローカルサーバユニット238は要求されたセグメントをHTTPプロキシユニット234に配信することによって応答する(308)。一方、DASHクライアント232が利用可能なセグメントのリスト内にないセグメントを要求する(312)と、HTTPプロキシユニット234は要求をCDNエッジサーバ240に転送し(314)、CDNエッジサーバ240は要求されたセグメントをHTTPプロキシユニット234に配信し(316)、HTTPプロキシユニット234はセグメントをDASHクライアント232に転送する(318)。
【０１１７】
図12は、MPDが複数の表現を含む例示的な使用事例を示す概念図である。この例では、ビデオ表現だけが示されるが、複数のオーディオ表現もまたMPD内に含まれてよいことを理解されたい。この例では、MPDは、メディア構成要素当たりに複数の表現を含み、すべての表現はユニキャスト上で利用可能であり、MPD@timeShiftBufferDepth>0であり、ブロードキャストが利用可能である(RepID=V1)とき、DASHクライアントはユニキャストのみの表現(RepID=V2, V3)を消費することはできない。
【０１１８】
図12の例では、異なるタイプのビデオデータ(「V1」、「V2」および「V3」として表される)は、deliveryMethodType要素のr12:unicastAppServiceのbasePattern要素内で指定され得る。しかしながら、ビデオデータ「V1」はまた、ブロードキャストを介して利用可能であり、それゆえ、V1はまたdeliveryMethodType要素のr12:broadcastAppServiceのbasePattern要素内で指定され得る。
【０１１９】
図13は、図12に関して説明した使用事例による例示的な技法を示す概念図である。時間<T1において、表現2のセグメントは、ユニキャストを使用してフェッチされる。具体的には、時間T1の前に、プロキシ制御ユニット236は、リダイレクションを実行しないようにHTTPプロキシユニット234を構成する(320)。したがって、DASHクライアント232が時間T1の前にセグメントに対するHTTP GET要求を送信する(322)とき、HTTPプロキシユニット234は、要求をCDNエッジサーバ240に転送する(324)。CDNエッジサーバ240は、要求されたメディアデータをHTTPプロキシユニット234に送信することによって要求に応答し(326)、HTTPプロキシユニット234は、メディアデータをDASHクライアント232に転送する(328)。
【０１２０】
eMBMSが有効にされると、BM-SCは、表現1のライブエッジセグメントをブロードキャストすることになる。時間=T1において、ブロードキャストセグメントXNはローカルサーバ238において利用可能であり、それゆえローカルサーバ238は、セグメントXNの利用可能性を示すデータをプロキシ制御ユニット236に送信する(330)。したがって、プロキシ制御ユニット236は、表現2または表現3の代わりに表現1のデータを要求することをDASHクライアント232に教示するようにHTTPプロキシユニット234を構成する。サーバ/ネットワーク支援型DASH(SAND)実施メッセージは、表現1(この例では、ブロードキャスト表現)に変更することをDASHクライアント232に行わせるために使用され得る。
【０１２１】
すなわち、DASHクライアント232が表現2または表現3のデータに対する要求を送信する(334)とき、HTTPプロキシユニット234は、代わりに表現1を指定するHTTPリダイレクト(たとえば、HTTP300応答)を用いて応答する(336)。したがって、DASHクライアント232は表現1のセグメントを要求し(338)、そのセグメントをHTTPプロキシユニット234はインターセプトしてローカルサーバ238にリダイレクトする(340)。要求されたセグメントが利用可能である場合、ローカルサーバ238はそのセグメントをHTTPプロキシ234に転送する(348)。DASHクライアント232は、TSB窓内の表現1の非ライブエッジセグメントを要求してよい。そのような場合、ローカルサーバ238は、セグメントに対するHTTP404エラーが存在すると判定してよく(342)、応答して、CDNエッジサーバ240からのセグメントを要求し(344)、CDNエッジサーバ240は応答してセグメントをローカルサーバ238に送信してよい(346)。いずれの場合も、HTTPプロキシユニット234は、受信されたセグメントをDASHクライアント232に返す(350)。
【０１２２】
図14は、例示的なSAND実施メッセージを示す概念図である。SANDスキーマはMPEGにおいて規定される。SANDスキーマと同様に、SAMMOスキーマは、www.3gpp.org/DynaReport/26946.htmで入手可能な、「3rd Generation Partnership Project、Technical Specification Group Services and System Aspects、Multimedia Broadcast/Multicast Service (MBMS) User service guidelines (Release 12)」、TR 26.946、2015年3月において規定される。
【０１２３】
SANDメッセージは、以下の要素: @baseURL 348はMPD内の表現を識別するURIプレフィックスを搬送するために使用される、Status 350は(利用可能な、利用不可能な、またはキャッシュされた)すべての関連するリソースのステータスを与える、Reasons:理由のテキスト情報、を含み得る。同様に、MPEGは、同様の情報を含み得るSANDメッセージを規定している。
【０１２４】
図15は、HTTP300応答を(たとえば、HTTPプロキシユニットから)受信するときのDASHクライアント挙動の一例を示す概念図である。図15の方法は、図9〜図11および図13のDASHクライアント232およびHTTPプロキシユニット234に関して説明される。しかしながら、図6のDASHクライアント184およびHTTPプロキシユニット186または図2のDASHクライアント110およびHTTPプロキシユニット108はまた、図15の方法を実行するように構成され得ることを理解されたい。
【０１２５】
この例では、DASHクライアント232は、ブロードキャストサービスが利用可能になる前に1つまたは複数のGET要求をHTTPプロキシユニット234に送信し、HTTPプロキシユニット234は、ユニキャストに従って要求をサーバデバイスに転送し、また要求に対する応答をDASHクライアント232に提供する(360A〜360N)。ブロードキャストサービスが利用可能になった後、DASHクライアント232がメディアデータに対する要求を送信すると、HTTPプロキシユニット234は、リダイレクションアドレス(たとえば、ローカルホストアドレス)および異なる表現(たとえば、セグメントがローカルにキャッシュされているブロードキャスト表現)に対する識別子を含むHTTP300応答を用いて返答してよい(362)。これは、表現を変更する(364)こと、および次いで新しく選択された表現を指定する後続のHTTP GET要求を送信することをDASHクライアント232に行わせてよく、後続のHTTP GET要求を、HTTPプロキシユニット234はローカルサーバ(たとえば、ローカルサーバユニット102)にリダイレクトし、要求されたメディアデータを含む返答をDASHクライアント232に返す(366A〜366B)。
【０１２６】
図16は、ブロードキャストからユニキャストへの切り換えの間にDASHクライアントをダイレクトするようにHTTPプロキシユニットを構成するときの、図12の使用事例による例示的な技法を示す概念図である。すなわち、この例では、ブロードキャストサービスは、最初に時間T2の前に利用可能であり、時間T2において利用不可能になる。図16の例は、図13に関して説明した例の続きを表すことができる。
【０１２７】
時間T2の前に、プロキシ制御ユニット236は、表現2または表現3を指定する要求を表現1に(およびCDNエッジサーバ240の代わりにローカルサーバ238に)リダイレクトするようにHTTPプロキシユニット234を構成する(370)。この例では、DASHクライアント232は、事前に表現1を選択したことが仮定されている。したがって、DASHクライアント232は表現1のセグメントを要求し(372)、そのセグメントをHTTPプロキシユニット234はインターセプトしてローカルサーバ238にリダイレクトする(374)。要求されたセグメントが利用可能である場合、ローカルサーバ238はそのセグメントをHTTPプロキシ234に転送する(382)。DASHクライアント232は、TSB窓内の表現1の非ライブエッジセグメントを要求してよい。そのような場合、ローカルサーバ238は、セグメントに対するHTTP404エラーが存在すると判定してよく(376)、応答して、CDNエッジサーバ240からのセグメントを要求し(378)、CDNエッジサーバ240は応答してセグメントをローカルサーバ238に送信してよい(380)。いずれの場合も、HTTPプロキシユニットは、受信されたセグメントをDASHクライアント232に返す(384)。
【０１２８】
時間=T2において、ローカルサーバ238は、ブロードキャストサービスがもはや利用可能でないことの表示をプロキシ制御ユニット236に送信する(386)。したがって、プロキシ制御ユニット236は、要求をローカルサーバ238にリダイレクトしないようにHTTPプロキシユニット234を構成する(388)。したがって、DASHクライアント232が時間T2に続いて、セグメントXMなどのセグメントを要求した(390)後、HTTPプロキシユニット234は、ユニキャストを使用してセグメントXM要求を満足し得る。すなわち、HTTPプロキシユニット234は、セグメントXMに対する要求をCDNエッジサーバ240に提出してよく(392)、CDNエッジサーバ240は、要求されたメディアデータを含む応答を送信してよい(394)。HTTPプロキシユニット234は、受信されたメディアデータを、他のユニキャスト表現が同様にSAND支援メッセージを使用して利用可能であることを示すデータとともにDASHクライアント232に転送してよい(396)。たとえば、HTTPプロキシユニット234は、図14に従ってSANDメッセージを送信してよい。時間T2の後、ユニキャスト帯域幅に基づいて、DASHクライアント232は表現2(または表現3)に変更してよい。潜在的な問題は、ユーザはTSB窓内の表現2のセグメントSM-2に戻る場合があり、ユニキャスト配信は使用され得るが、表現1の同様のセグメントSM-2は、すでにローカルサーバ238においてキャッシュされている場合があることである。
【０１２９】
図17は、SAND支援を受けるときのDASHクライアント挙動の一例を示す概念図である。図17の方法は、図9〜図11、図13および図16のDASHクライアント232およびHTTPプロキシユニット234に関して説明される。しかしながら、図6のDASHクライアント184およびHTTPプロキシユニット186または図2のDASHクライアント110およびHTTPプロキシユニット108はまた、図17の方法を実行するように構成され得ることを理解されたい。
【０１３０】
この例では、DASHクライアント232は、ブロードキャストサービスが利用可能である間に1つまたは複数のGET要求をHTTPプロキシユニット234に送信し、HTTPプロキシユニット234は要求をローカルサーバにリダイレクトし、また要求に対する応答をDASHクライアント232に提供する(400A〜400N)。ブロードキャストサービスが利用不可能になった後、DASHクライアント232がメディアデータに対する要求を送信すると、HTTPプロキシユニット234は、異なる表現(たとえば、ユニキャスト表現)に対するURLを指定するSAND(またはSAMMO)メッセージを含むHTTP20x応答を用いて返答してよい(402)。これは、表現を変更する(404)こと、および次いで新しく選択された表現を指定する後続のHTTP GET要求を送信することをDASHクライアント232に行わせてよく、後続のHTTP GET要求を、HTTPプロキシユニット234は別個のサーバデバイスに転送し、要求されたメディアデータを含む返答をDASHクライアント232に返す(406A〜406B)。
【０１３１】
図18は、本開示による、eMBMS DASHアウェアネットワーク要素(DANE)を使用するための例示的な技法を示す概念図である。すなわち、図18のシステム420は、DASHクライアント428と、CDNエッジサーバ430と、eMBMS DANE424およびローカルサーバ246を含むeMBMSミドルウェアユニット422とを含む。図18による例が以下で説明される。
【０１３２】
時間<T1において、表現2のセグメントは、ユニキャストを使用してフェッチされる。すなわち、最初に、eMBMS DANE424は、リダイレクションを使用しないように構成される(440)。したがって、DASHクライアント428が表現2のセグメントを要求する(442)とき、eMBMS DANE424は、要求をCDNエッジサーバ430に転送する(444)。CDNエッジサーバ430は、要求されたメディアデータを含む応答をeMBMS DANE424に送信し(446)、その応答を、eMBMS DANE424はDASHクライアント428に転送する(448)。
【０１３３】
eMBMSが有効にされると、BM-SC(図示せず)は、表現1のライブエッジセグメントをローカルサーバ426にブロードキャストすることになる。したがって、ローカルサーバ426は、ブロードキャスト表現、すなわち表現1のセグメントは利用可能であると判定する(450)。したがって、eMBMSミドルウェアユニット422は、表現2および3に対する要求を表現1にリダイレクトすることと、表現1に対する要求をローカルサーバ246にリダイレクトすることとを行うようにeMBMS DANE424を構成する(452)。したがって、DASHクライアント428がたとえば表現2のセグメントを要求し(454)、このセグメントに対して表現1の対応するセグメントがブロードキャストサービスを介してローカルサーバ426によって受信されているとき、eMBMS DANE424は、リダイレクションを指定するSAND実施メッセージを表現2の代わりに表現1に送信してよい(456)。これは、表現1に切り換えることと、表現2に代わって表現1からセグメントを要求することとをDASHクライアント428に行わせ得る(458)。次いで、eMBMS DANE424は、要求をローカルサーバ426に転送してよく、ローカルサーバ426は、応答してセグメントをeMBMS DANE424に送信してよく(468)、セグメントはローカルにキャッシュされることが仮定される。セグメントがローカルにキャッシュされていない場合、ローカルサーバ426は、HTTP404エラーが発生したと判定してよく(462)、したがってセグメントをCDNエッジサーバ430から要求し(464)、CDNエッジサーバ430はセグメントをローカルサーバ426に送信してよく(466)、ローカルサーバ426はセグメントをeMBMS DANE424に送信してよい(468)。いずれの場合も、eMBMS DANE424は、セグメントをDASHクライアント428に送信してよい(470)。
【０１３４】
図19は、本開示による、eMBMS DASHアウェアネットワーク要素(DANE)を使用するための例示的な技法を示す概念図である。この例は、図18の例とのつながりであり得る。すなわち、図18および図19におけるタイムラインは同じものである。しかしながら、たとえば図18に関して上記で説明したように、ユニキャストからブロードキャストへの後続の切り換えもまた行われてよいことを理解されたい。
【０１３５】
最初に、eMBMS DANE424は、表現2および3に対する要求を表現1にリダイレクトすることと、表現1に対する要求をローカルサーバ426に送信することとを行うように構成される(480)。また、この例では、DASHクライアント428は、時間T2の前に、表現1を選択するように構成されることが仮定されている。したがって、DASHクライアント428は、表現1からのセグメントに対する要求を送信する(482)。eMBMS DANE424は、この要求をローカルサーバ426に転送する(484)。この例では、ローカルサーバ426は、HTTP404エラーがあること(486)、および要求されたセグメントは利用可能でないこと(488)を決定する。これは、表現1に対する要求を表現2または表現3のいずれかにリダイレクトするようにeMBMS DANE424を構成することをeMBMSミドルウェアユニット422に行わせる(490)。
【０１３６】
また、ローカルサーバ426は、この例では、HTTP404エラーをeMBMS DANE424に返す(492)。したがって、eMBMS DANE424は、DASHクライアント428は異なる表現、たとえば表現2または3を選択すべきであることを示すリダイレクションメッセージをDASHクライアント428に返す(494)。このリダイレクションメッセージは、SAND実施メッセージを含んでよい。この例では、DASHクライアント428は(帯域幅利用可能性に基づいて)表現2を選択し、したがって表現2からの対応するセグメントに対する要求をeMBMS DANE424に送信する(496)。eMBMS DANE424は要求をCDNエッジサーバ430に転送し(498)、CDNエッジサーバ430は要求されたセグメントによってeMBMS DANE424に応答する(500)。したがって、eMBMS DANE424は、セグメントをDASHクライアント428に転送する(502)。ユーザは、TSB窓内の表現2のセグメントSM-2に戻ってよい。ユニキャスト配信は使用され得るが、表現1の同様のセグメントSM-2は、すでにローカルサーバ426においてキャッシュされている場合がある。
【０１３７】
図20は、代替のローカルにキャッシュされているセグメントを、そのようなセグメントが利用可能であるときに使用するために、HTTPプロキシユニット234がDASHクライアント232を支援する例示的な技法を示す概念図である。この例では、ローカルサーバ238は、更新された利用可能なセグメントを示す更新メッセージ(510B)だけでなく、利用可能なセグメントを示す初期のメッセージをもプロキシ制御ユニット238に送信する(510A)。プロキシ制御ユニット236は、キャッシュされている表現1のセグメント(たとえば、[N_start、N_end]の間のセグメント番号を有するセグメント)に対するセグメントURLをローカルサーバ238にダイレクトする(512A)こと、およびローカルサーバ238から満足され得るセグメントURLの更新されたリストを周期的に提供する(512B)ことを行うようにHTTPプロキシユニット234を構成する。この例では、N_startはローカルサーバ238内でキャッシュされている最古のセグメントのセグメント番号を表し、一方N_endはローカルサーバ238内でキャッシュされている最新のセグメントのセグメント番号を表す。
【０１３８】
ローカルサーバユニットがキャッシュされているセグメントを除去すると、プロキシ制御ユニット236はリダイレクションルールを更新する(512B)。DASHクライアント232は、キャッシュされていないセグメントを要求する場合があり(514)、その場合、HTTPプロキシユニット234は要求をCDNエッジサーバ240に転送してよく(516)、CDNエッジサーバ240はセグメントをHTTPプロキシユニット234に送信することによって応答してよく(518)、HTTPプロキシユニット234はセグメントをDASHクライアント232に転送してよい(520)。しかしながら、DASHクライアント232が、キャッシュされていないが異なる表現のキャッシュされたセグメントに対応する表現のセグメントに対する要求を送信する場合、HTTPプロキシユニット234は、N_startからN_endまでの表現1に対するセグメントがすでにキャッシュされていることをDASHクライアント232に通知するために、SAND支援メッセージを送信してよい。たとえば、DASHクライアント232は、表現2のセグメントN_startをHTTPプロキシユニット234に要求してよく、HTTPプロキシユニット234は、表現1のセグメントN_startが利用可能である(たとえば、ローカルサーバ238によってキャッシュされている)ことを示すSANDメッセージによって応答してよい。
【０１３９】
応答して、DASHクライアント232は、代わりにすでにキャッシュされている表現1からのセグメントを要求してよい(522)。したがって、HTTPプロキシユニット234は、セグメントに対する要求をローカルサーバ238にリダイレクトしてよく(524)、ローカルサーバ238は、セグメントをHTTPプロキシユニット234に提供してよく(526)、HTTPプロキシユニット234は、セグメントをDASHクライアント232に転送してよい(528)。
【０１４０】
SANDメッセージは、以下の例に示すように、セグメントURLを識別するために@baseURLを使用してよい。
<SANDMessage xmlns=..><ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/V1/seg-(N_start).mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/V1/seg-(N_start+1).mp4"> </ResourceStatus>
...
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/V1/seg-(N_end-1).mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/V1/seg-(N_end).mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/A1/seg-(N_start).mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/A1/seg-(N_start+1).mp4"> </ResourceStatus>
...
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/A1/seg-(N_end-1).mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL="http://www.example.com/A1/seg-(N_end).mp4"> </ResourceStatus>
</SANDMessage>
【０１４１】
追加または代替として、そのようなデータは、ブロードキャストからユニキャストへの遷移の間に(たとえば、図16の時間=T2において)送信されたより古いSAND支援メッセージとマージされてよい。
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/V2"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/V3"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/A1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/A2"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" baseURL="http://www.example.com/A3"> </ResourceStatus>
</SANDMessage>
【０１４２】
図21は、本開示による一例においてSANDメッセージ内に含まれ得るreasonデータ530を示す概念図である。この例では、status=cachedを有するリソースに対して、属性「reason」530は、N_startおよびN_endを表すカンマ区切り文字列(すなわち、カンマ区切り値)を搬送することができる。たとえば、
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="cached" reason=''10,100''baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" reason=''10,100''baseURL="http://www.example.com/A1"> </ResourceStatus>
</SANDMessage>
【０１４３】
図22は、本開示によるSANDメッセージ内に含まれ得るデータ532の別の例示的なセットを示す概念図である。図21に示す「reason」フィールド530にデータを追加することとは対照的に、この例では、データ532は、2つのフィールド、「from」フィールドおよび「end」フィールドを有するメッセージを含んでよい。すなわち、2つの特別な属性、「From」および「To」が、N_startおよびN_endをそれぞれ識別するためにResouceStatusに追加される。以下はその一例である。
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="cached" From=10 To=100 baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" From=10 To=100 baseURL="http://www.example.com/A1"> </ResourceStatus>
</SANDMessage>
【０１４４】
代替として、「From」はseg(N_start)の利用可能開始時間を識別してよく、「To」はseg(N_end)の利用可能開始時間を識別してよい。
【０１４５】
本開示の技法による一例では、正規表現が使用され得る。status=cachedを有するリソースに対して、属性baseURLは、N_start(=10)とN_end(=100)との間のセグメントURLの範囲を識別するための正規表現を搬送し得る。たとえば、
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="cached" baseURL=" http:\/\/www\.example\.com\/V1\/seg-(([1-9][0-9])|100)\.mp4"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" baseURL=" http:\/\/www\.example\.com\/A1\/seg-(([1-9][0-9])|100)\.mp4"> </ResourceStatus>
</SANDMessage>
【０１４６】
本開示の技法による一例では、セグメントリスト内のステータスの順序は、SANDスキーマ内の要素DaneResourceStatusを使用することによって変更され得る。上述のように、正規表現は、SANDメッセージのコンパクト表現に対する「resource」セクション内で使用され得る。この例では、セグメントは、セグメントライブエッジタイムラインの間に要求されたときにHTTPステータス200 OKを有して戻されることになるか、またはMPD内に示されるTSBタイムライン窓内で要求されたときにHTTPステータス200 OKを有して戻されることになることを示すために、新しいステータス「available/cached」が使用され得る。以下はその一例である。
<SANDMessage xmlns=..>
<DaneResourceStatus messageId="1" status="cached">
<resource>http://www.example.com/V1/seg-(N_start).mp4</resource>
<resource>http://www.example.com/V1/seg-(N_start+1).mp4</resource>
...
<resource>http://www.example.com/V1/seg-(N_end-1).mp4</resource>
<resource>http://www.example.com/V1/seg-(N_end).mp4</resource>
<resource>http://www.example.com/A1/seg-(N_start).mp4 </resource>
<resource>http://www.example.com/A1/seg-(N_start+1).mp4</resource>
...
<resource>http://www.example.com/A1/seg-(N_end-1).mp4</resource>
<resource>http://www.example.com/A1/seg-(N_end).mp4</resource>
</ DaneResourceStatus >
</SANDMessage>
【０１４７】
図23は、複数の表現を有する例示的なMPDを示す概念図である。この例では、ビデオ表現だけが示されているが、複数のオーディオ表現もまたMPD内に含まれてよいことを理解されたい。この例による使用事例は、MPDがメディア構成要素当たりに複数の表現を含むこと、ブロードキャスト表現がユニキャスト上で利用可能でないこと(たとえば、ブロードキャスト表現はユニキャスト接続上で満足され得ない高ビットレートを用いて符号化される)、MPD@timeShiftBufferDepth>0であること、およびブロードキャストが利用可能である(RepID=V1)ときにDASHクライアントはライブエッジユニキャスト表現(RepID=V2, V3)を消費できないことである。
【０１４８】
図23の例では、異なるタイプのビデオデータ(「V1」、「V2」および「V3」として表される)は、deliveryMethodType要素のr12:unicastAppServiceのbasePattern要素かまたはdeliveryMethodType要素のr12:broadcastAppServiceのbasePattern要素のいずれかの中で指定され得る。この例では、「V1」は、ブロードキャストを介して利用可能であり、それゆえ、「V1」は、r12:broadcastAppServiceのbasePattern要素の中で指定され得る。同様に、この例では、「V2」および「V3」はユニキャストを介して利用可能であり、それゆえ、「V2」および「V3」は、r12:unicastAppServiceのbasePattern要素の中で指定され得る。
【０１４９】
図24は、図23の使用事例による、ユニキャストサービスからブロードキャストサービスへの切り換えの間にDASHクライアント232をダイレクトするようにHTTPプロキシユニット234を構成するための例示的な技法を示す概念図である。eMBMSが有効にされると、BM-SC(図示せず)は、表現1のライブエッジセグメントをローカルサーバ238にブロードキャストすることになる。プロキシ制御ユニット236は、[N_start]より大きいセグメント番号を有する表現1を指定するURLを要求するセグメントをローカルサーバ238にダイレクトすることと、[N_start]より小さいセグメント番号を有する表現2および表現3に対するセグメントURLをCDNエッジサーバ240にダイレクトすることとを行うようにHTTPプロキシユニット234を構成する(542)。
【０１５０】
時間<T1において、表現2のセグメントは、ユニキャストを使用してフェッチされる。たとえば、ローカルサーバ238は、利用可能なセグメントのリストをプロキシ制御ユニット236に公表してよい(540)。このリストは、セグメントNを含むセグメントおよびセグメントNに続くセグメントを含んでよい。プロキシ制御ユニット236は、リスト内のメディアデータに対する要求をローカルサーバ238にリダイレクトするようにHTTPプロキシユニット234を構成する(542)。したがって、DASHクライアント232がセグメントNより前のセグメントを要求する(544)場合、HTTPプロキシユニット234は、要求をCDNエッジサーバ240に転送してよい(546)。CDNエッジサーバは、要求されたセグメントをHTTPプロキシユニット234に送信してよく(548)、HTTPプロキシユニット234は、セグメントをDASHクライアント232に転送してよい(550)。
【０１５１】
この例では、N_startは、ローカルサーバ内でキャッシュされている最古のセグメントのセグメント番号を表す。SAND実施は、DASHクライアント232が、表現1のセグメントをブロードキャストするように変化することを可能にするために使用され得る。すなわち、DASHクライアント232が、表現1のセグメントに対応する表現2のセグメントを要求する(552)場合、HTTPプロキシユニット234は、表現1の対応するセグメントが利用可能であることを示すSAND実施メッセージをDASHクライアント232に送信してよい(554)。したがって、DASHクライアント232は、表現1に切り換えてよく、表現1からのセグメントを要求してよい(556)。HTTPプロキシユニット234は、要求をローカルサーバ238にリダイレクトしてよい(558)。ローカルサーバ238は、応答してセグメントをHTTPプロキシユニット234に送信してよく(560)、HTTPプロキシユニット234は、セグメントをDASHクライアント232に転送してよい(562)。
【０１５２】
図25は、図23および図24の使用事例による、ユニキャストサービスからブロードキャストサービスへの切り換えの間に使用され得る例示的なSANDメッセージを示す概念図である。この例では、SANDメッセージは、ブロードキャスト表現に対する「From」属性およびユニキャスト表現に対する「To」属性を指定するデータ564を含む。以下はその一例である。
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="available" From=100 baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" To=100 baseURL="http://www.example.com/V2"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" To=100 baseURL="http://www.example.com/V3"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" From=100 baseURL="http://www.example.com/A1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" To=100 baseURL="http://www.example.com/A2"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" To=100 baseURL="http://www.example.com/A3"> </ResourceStatus>
</SANDMessage>
【０１５３】
図26は、図23〜図25の使用事例による、ブロードキャストサービスからユニキャストサービスへの切り換えの間にDASHクライアント232をダイレクトするようにHTTPプロキシユニット234を構成するための例示的な技法を示す概念図である。図26に対するタイムラインは図24のタイムラインと同じであり得るが、図26の技法は、図24の例において実行される技法に倣うように説明される。
【０１５４】
プロキシ制御ユニット236は、セグメントNの前のセグメントに対する要求を、ユニキャストサービスと関連付けられた表現(たとえば、表現2または表現3)にリダイレクトするようにHTTPプロキシ234を構成してよいが、セグメントNを含むセグメントおよびセグメントNに続くセグメントをブロードキャストサービスと関連付けられた表現(たとえば、表現1)にリダイレクトするようにHTTPプロキシ234を構成してもよい(570)。したがって、DASHクライアント232がローカルサーバ238においてキャッシュされている表現1からのセグメントを要求する(572)とき、HTTPプロキシユニット234は、要求をローカルサーバ238にリダイレクトしてもよい(574)。ローカルサーバ238は、セグメントをHTTPプロキシユニット234に送信することによって応答してよく(576)、HTTPプロキシユニット234は、セグメントをDASHクライアント232に転送してよい(578)。
【０１５５】
また、ローカルサーバ238は、どのセグメントがローカルにキャッシュされているかを示すデータをプロキシ制御ユニット236に送信してよい(580)。この例では、時間T2において、ブロードキャストサービスがもはや利用可能でないことが仮定されている。したがって、プロキシ制御ユニット236は、利用可能である表現1のセグメントに対する要求をローカルサーバ238にリダイレクトするが、他の要求をCDNエッジサーバ240に転送するようにHTTPプロキシユニット234を構成する(582)。したがって、DASHクライアント232がローカルサーバ238から利用可能でない表現1のセグメント(たとえば、セグメントMおよびそれ以降)を要求する(584)場合、HTTPプロキシユニット234は、このセグメントは利用可能でないが、対応するセグメントが異なる表現から利用可能であることを示すSAND実施メッセージを送信する(586)。
【０１５６】
したがって、DASHクライアント232は、たとえば表現2からセグメントMに続くセグメントを要求してよく(588)、HTTPプロキシユニット234は、要求をCDNエッジサーバ240に転送してよい(590)。次いで、CDNエッジサーバは、要求されたセグメントをHTTPプロキシユニット234に送信することによって応答してよく(592)、HTTPプロキシユニット234は、セグメントをDASHクライアント232に転送してよい(594)。T2以降の時間において、ユーザは、表現1から受信されたセグメントのTSB窓の中にある、より早いセグメント(たとえば、表現2のセグメントSM-2)に戻ってよい。この場合、ユニキャスト配信は使用され得るが、表現1の同様のセグメントXM-2は、すでにキャッシュされている場合がある。したがって、プロキシ制御ユニット236は、ローカルサーバ238のキャッシュされているセグメントのURL範囲内の表現1に対する要求をローカルサーバ238にダイレクトするようにHTTPプロキシユニット234を構成してよい。同様に、SAND支援は、DASHクライアントが、(表現1の)キャッシュされているブロードキャストセグメントに変化することを可能にするために使用され得る。
【０１５７】
図27は、本開示の技法による、MPDのデータの例示的なセットを示す概念図である。この例は、本開示の技法による別の使用事例を表す。この使用事例では、MPDは、メディア構成要素当たりに複数の表現を含み、ブロードキャスト表現はユニキャスト上で利用可能でなく、MPD@timeShiftBufferDepth>>0(large)であり、UEはブロードキャストカバレージの中および外で移動し続ける。生ずる問題は、ローカルサーバ内のキャッシュされているセグメントの不連続なシーケンスである。
【０１５８】
図27の例では、異なるタイプのビデオデータ(「V1」、「V2」および「V3」として表される)は、deliveryMethodType要素のr12:unicastAppServiceのbasePattern要素かまたはdeliveryMethodType要素のr12:broadcastAppServiceのbasePattern要素のいずれかの中で指定され得る。この例では、「V1」は、ブロードキャストを介して利用可能であり、それゆえ、「V1」は、r12:broadcastAppServiceのbasePattern要素の中で指定され得る。同様に、この例では、「V2」および「V3」はユニキャストを介して利用可能であり、それゆえ、「V2」および「V3」は、r12:unicastAppServiceのbasePattern要素の中で指定され得る。
【０１５９】
図28は、図27の使用事例に対するSANDメッセージ内に含まれ得るデータ596の例示的なセットである。具体的には、データ596は、「from」属性(ローカルサーバの利用可能なキャッシュされているセグメントの開始を示す)と「to」属性(ローカルサーバの利用可能なキャッシュされているセグメントの終了を示す)とを指定する。複数のエントリが、たとえば以下の例に示すブロードキャスト表現のためのSANDメッセージ内に含まれ得る。
<SANDMessage xmlns=..>
<ResourceStatus messageId="1" status="cached" From=10 To=20 baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" From=30 To=40 baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" From=50 To=60 baseURL="http://www.example.com/V1"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" From=10 To=20 baseURL="http://www.example.com/A1"> </ResourceStatus>
<ResourceStatus messageId="1" status="available" From=30 To=40 baseURL="http://www.example.com/A1"> </ResourceStatus>
<ResourceStatus messageId="1" status="cached" From=50 To=60 baseURL="http://www.example.com/A1"> </ResourceStatus>
</SANDMessage>
【０１６０】
図29は、同様のセグメントをCDNエッジサーバ430から取り出す代わりに、代替のローカルセグメントを使用するようにDASHクライアント428を支援するためにeMBMS DANE424を使用するための例示的な技法を示す概念図である。図29に示していないが、eMBMSミドルウェアユニット422は、上記の他の例に示すように、プロキシ制御ユニットをさらに含んでよく、プロキシ制御ユニットは、たとえばeMBMSミドルウェアユニット422のeMBMS DANE424を構成してよい。一例によれば、
プロキシ制御ユニットは、以下を行うようにeMBMS DANE424を構成する。
[N_start、N_end]の間のセグメント番号を有する表現1に対するセグメントURLに対する要求をローカルサーバ426にダイレクトすること。
N_startは、ローカルサーバ内でキャッシュされている最古のセグメントのセグメント番号を表す。
N_endは、ローカルサーバ内でキャッシュされている最新のセグメントのセグメント番号を表す。
ローカルサーバ426から満足され得るセグメントURLのリストを提供すること。
ローカルサーバ426がキャッシュされているセグメントを除去するとき、プロキシ制御ユニットはeMBMS DANE424のリダイレクションルールを更新してよい。
SAND支援メッセージは、N_startからN_endまでの表現1に対するセグメントはすでにローカルサーバ426においてキャッシュされていることをDASHクライアント428に通知するために使用され得る。
【０１６１】
具体的には、ローカルサーバ426は、どのセグメントが利用可能であるかを最初に(600A)、およびセグメントがキャッシュから除去されるときに周期的に(600B)判定してよい。したがって、eMBMSミドルウェアユニット422は、初期に利用可能なセグメント(602A)に基づいて、およびローカルサーバ426からの更新に応答して(602B)、リダイレクションルールを用いてeMBMS DANE424を構成してよい。具体的には、eMBMSミドルウェアユニット422は、ユニキャスト表現からのセグメント番号に対する要求を、対応するブロードキャスト表現のセグメントがローカルサーバ426においてローカルにキャッシュされている場合、それらのセグメントにリダイレクトするようにeMBMS DANE424を構成してよい。
【０１６２】
したがって、DASHクライアント428が、対応するブロードキャスト表現からのキャッシュされているセグメントを持たないユニキャスト表現からのセグメントを要求する(604)場合、eMBMS DANE424は、要求をCDNエッジサーバ430に転送してよい(606)。CDNエッジサーバ430は、要求されたセグメントをeMBMS DANE424に送信することによって応答してよく(608)、eMBMS DANE424は、セグメントをDASHクライアント428に転送してよい(610)。一方、DASHクライアント428が、対応するブロードキャスト表現からのキャッシュされているセグメントを有するユニキャスト表現からのセグメントを要求する(612)場合、eMBMS DANE424は、対応するブロードキャスト表現のセグメントを取り出すために要求をローカルサーバ426にリダイレクトしてよい(614)。次いで、ローカルサーバ426は、要求されたセグメントをeMBMS DANE424に送信することによって応答してよく(616)、eMBMS DANE424は、セグメントをDASHクライアント428に転送してよい(618)。
【０１６３】
その上、本開示の技法によれば、DaneResourceStatusパラメータなどのパラメータは、DANEが、利用可能な、および場合によっては利用可能であるものと予期されるデータ構造をDASHクライアントにシグナリングすることと、同じくどのデータ構造が利用不可能であるかをシグナリングすることとを可能にするために使用されてよい。この方法は、ステータスメッセージの時点で利用可能なセグメントの表現を可能にするので、上述のリソースステータスと補完関係にある。リソースは、リストとして明示的にリストアップされるかもしくは提供されてよく、またはリソースは、何らかの短縮されたメッセージフォーマットによって提供されてもよい。典型的な使用事例は以下のとおりである。
DANEは、セグメント利用可能時間に近いセグメントを配信するアップストリームマルチキャスト/ブロードキャストサービスを結合してよい。これは、セグメントが、キャッシュ内で特定の時間以降からのみ利用可能であることを意味する。
いくつかのセグメントは失われ、そのことは、失われており利用不可能であるとDANEによって検出される。
【０１６４】
この問題に対処するために、既存のSANDメッセージの拡張が考察される。いくつかのさらなる詳細が、以下で説明される。
【０１６５】
ソースおよび宛先のデータが、以下のようにシグナリングされ得る。
タイプ:PER
送信側:キャッシュするDANE
受信側:DASHクライアント(および介在するDANE)
【０１６６】
データ表現、それは表のフォーマットにおけるものであってよい。表は、以下の表によるものであり得る。
【０１６７】
【表１】
2018524882.tif 000003
【０１６８】
ステータスインジケータ(@statusによる)およびステータスインジケータに対するセマンティクスは以下のとおりであり得る。
【０１６９】
【表２】
2018524882.tif 000004
【０１７０】
上記の表のリソースグループ要素は、複数のセグメントを有する文字列を規定し得る。異なるタイプの使用事例を表現するためおよびメッセージサイズを圧縮するために、いくつかの簡略化された正規表現パターンが許可される。リソースグループは、このパターンによって生成され得るすべてのリソースに対してステータスが適用されることを示さないが、メディアプレゼンテーション内で参照されるリソースと表現パターンによって生成されるリソースとの交差に対してのみ、ステータスが適用されることを示す。
【０１７１】
正規表現パターンは、POSIX規格(ポータブルオペレーティングシステムインターフェース)に従うことができる。概観として、以下のメタ文字が、リソースのグループを表現するために使用され得る。
【０１７２】
【表３】
2018524882.tif 000005
2018524882.tif 000006
【０１７３】
送信側の論理は以下の擬似コードに従うことができる。
// DANE挙動
// 第1の例: キャッシュされたリソースを生成
{
結果 = []
ステータスをキャッシュ済みに設定
ステータス内のすべてのオブジェクトについて
このオブジェクトのURLを有する行リソースをメッセージに追加
}
【０１７４】
図30は、本開示の技法による例示的な方法を示すフローチャートである。図30の方法は、クライアントデバイスのHTTPプロキシユニットを制御するクライアントデバイスのミドルウェアユニットによって実行され得る。たとえば、図30の方法は、図2のeMBMSミドルウェアユニット100、図6のeMBMSミドルウェアユニット188、たとえば図9のプロキシ制御ユニット236、またはたとえば図18のミドルウェアユニット422によって実行され得る。例および説明として、図30の方法については、図2のミドルウェアユニット100によって実行されるものとして説明する。図2に示すように、ミドルウェアユニット100は、HTTPプロキシユニット108とローカルサーバユニット102とを含む。
【０１７５】
最初に、ミドルウェアユニット100は、メディアセッションのメディアデータの第1のセットをブロードキャストサービスを介して受信する(630)。ミドルウェアユニット100は、後で(すなわち、メディアデータの第1のセットを受信した後)、ブロードキャストサービスがもはや利用可能でないと判定してよい(632)。ブロードキャストサービスがもはや利用可能でないと判定することに基づいて、ミドルウェアユニット100は、クライアントデバイスによって実行されるストリーミングアプリケーション(たとえば、DASHクライアント110)からユニキャストサービスを介してメディアセッションのメディアデータの第2のセットを取り出すことの要求を受信してよく、要求はクライアントデバイスの外部のアドレスを指定する(634)。メディアデータの第2のセットは、ブロードキャストサービスを介して以前に受信されたメディアデータの第1のセット内に含まれてよい。したがって、要求に応答して、メディアデータの第2のセットがブロードキャストサービスを介して以前に受信されていたとき、ミドルウェアユニット100は、要求をローカルサーバユニット、たとえばローカルサーバユニット102(図2)にリダイレクトすることをHTTPプロキシユニット(たとえば、図2のHTTPプロキシユニット108)に行わせてよい(636)。
【０１７６】
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得、またはコンピュータ可読媒体を介して送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、一般に、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号または搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明する技法の実装のための命令、コードおよび/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品がコンピュータ可読媒体を含んでもよい。
【０１７７】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続も適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)およびBlue-rayディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生する一方、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せはまた、コンピュータ可読媒体の範囲内に同じく含まれるものとする。
【０１７８】
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサによって実行されてよい。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指し得る。さらに、いくつかの態様では、本明細書で説明する機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に設けられてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素において全体的に実施されてよい。
【０１７９】
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、また1組のIC(たとえば、チップセット)を含む、様々なデバイスまたは装置において実施され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的側面を強調するために、様々な構成要素、モジュール、またはユニットが説明されているが、それらは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットは、コーデックハードウェアユニットにおいて結合されることがあり、または適切なソフトウェアおよび/もしくはファームウェアとともに、上で説明されたような1つもしくは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって提供されることがある。
【０１８０】
種々の例について説明した。これらの例および他の例は以下の特許請求の範囲内に入る。
【符号の説明】
【０１８１】
10  システム
20  コンテンツ準備デバイス
22  オーディオソース
24  ビデオソース
26  オーディオエンコーダ
28  ビデオエンコーダ
30  カプセル化ユニット
32  出力インターフェース
40  クライアントデバイス
42  オーディオ出力
44  ビデオ出力
46  オーディオデコーダ
48  ビデオデコーダ
50  カプセル化解除ユニット
52  取出しユニット
54  ネットワークインターフェース
60  サーバデバイス
62  記憶媒体
64  マルチメディアコンテンツ
66  マニフェストファイル
68  表現
68A  表現
68N  表現
70  要求処理ユニット
72  ネットワークインターフェース
74  ネットワーク
100  eMBMSミドルウェアユニット
102  ローカルサーバユニット
104  キャッシュ
106  eMBMS受信ユニット
108  HTTPプロキシユニット
110  DASHクライアント
112  メディアアプリケーション
120  マルチメディアコンテンツ
122  メディアプレゼンテーション記述(MPD)
124A  表現
124N  表現
126  ヘッダデータ
128  セグメント
128A  セグメント
128N  セグメント
130  ヘッダデータ
132A  セグメント
132N  セグメント
150  ビデオファイル
152  ファイルタイプ(FTYP)ボックス
154  動画(MOOV)ボックス
156  動画ヘッダ(MVHD)ボックス
158  トラック(TRAK)ボックス
160  動画延長(MVEX)ボックス
162  セグメントインデックス(sidx)ボックス
164  ムービーフラグメントボックス
166  動画フラグメントランダムアクセス(MFRA)ボックス
180  エンドツーエンドアーキテクチャ
182  ユーザ機器(UE)
184  DASHクライアント
186  HTTPプロキシ
188  eMBMSミドルウェアユニット
190  無線エリアネットワーク/発展型パケットコア(RAN/EPC)
192  コンテンツ配信ネットワーク(CDN)
194  DASHエンコーダ
196  ブロードキャストマルチキャストサービスセンター(BMSC)
198  消費報告ユニット
200  FLUTEユニット
202  取り込みインターフェース
230  システム
232  DASHクライアント
234  HTTPプロキシユニット
236  プロキシ制御ユニット
238  ローカルサーバ、ローカルサーバユニット
240  CDNエッジサーバ
300A  初期リストの形態
300B  周期的更新の形態
302A  リダイレクションルール
302B  リダイレクションルール
420  システム
422  eMBMSミドルウェアユニット
424  eMBMS DANE
426  ローカルサーバ
428  DASHクライアント
430  CDNエッジサーバ
530  reasonデータ、属性「reason」、「reason」フィールド
532  データ
564  データ
596  データ
【図１】
2018524882.tif 000007
【図２】
2018524882.tif 000008
【図３】
2018524882.tif 000009
【図４】
2018524882.tif 000010
【図５】
2018524882.tif 000011
【図６】
2018524882.tif 000012
【図７】
2018524882.tif 000013
【図８】
2018524882.tif 000014
【図９】
2018524882.tif 000015
【図１０】
2018524882.tif 000016
【図１１】
2018524882.tif 000017
【図１２】
2018524882.tif 000018
【図１３】
2018524882.tif 000019
【図１４】
2018524882.tif 000020
【図１５】
2018524882.tif 000021
【図１６】
2018524882.tif 000022
【図１７】
2018524882.tif 000023
【図１８】
2018524882.tif 000024
【図１９】
2018524882.tif 000025
【図２０】
2018524882.tif 000026
【図２１】
2018524882.tif 000027
【図２２】
2018524882.tif 000028
【図２３】
2018524882.tif 000029
【図２４】
2018524882.tif 000030
【図２５】
2018524882.tif 000031
【図２６】
2018524882.tif 000032
【図２７】
2018524882.tif 000033
【図２８】
2018524882.tif 000034
【図２９】
2018524882.tif 000035
【図３０】
2018524882.tif 000036
【国際調査報告】
2018524882.tif 000037
2018524882.tif 000038
2018524882.tif 000039