(57)【要約】  クライアントデバイスが、リアルタイム制約を有するデータをバッファリングするためのバッファを備えるメモリと、デジタル論理回路機構を備えるハードウェアベースのプロセッサとを含む。プロセッサは、データがダウンロードのために利用可能である時間を判断し、バッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断し、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るように構成されたリアルタイムのアプリケーションを実行するように構成される。このようにして、送付デバイスは、クライアントデバイスのためにバッファアンダーランを防止するために、要求されたデータの配信を優先することができる。
2018532334.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイム制約を有するデータを取り出す方法であって、クライアントデバイスのデジタル論理回路機構を備えるハードウェアベースのプロセッサによって実行されるリアルタイムのアプリケーションによって、
前記データがダウンロードのために利用可能である時間を判断するステップと、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断するステップと、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るステップとを含む方法。
【請求項２】
前記データが利用可能である前記時間を判断するステップは、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断するステップを含む、請求項1に記載の方法。
【請求項３】
前記マニフェストファイルは、動的適応ストリーミングオーバーHTTP(DASH)メディアプレゼンテーション記述(MPD)を含む、請求項2に記載の方法。
【請求項４】
前記要求および前記デッドライン情報を送るステップは、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するステップを含む、請求項1に記載の方法。
【請求項５】
前記要求および前記デッドライン情報を送るステップは、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
【請求項６】
前記要求を送るステップは、ストリーミングアウェアネットワーク要素、DASHアウェアネットワーク要素(DANE)、DASHサーバ、モバイルセルサイト、またはワイヤレスアクセスポイントのうちの少なくとも1つに前記要求を送るステップを含む、請求項1に記載の方法。
【請求項７】
前記デッドライン情報を判断するステップをさらに含み、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項８】
前記デッドライン情報を判断するステップをさらに含み、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項９】
プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るステップをさらに含む、請求項1に記載の方法。
【請求項１０】
前記要求を送るステップは、前記要求をストリーミングアウェアネットワーク要素に送るステップを含み、前記方法は、前記要求および前記デッドライン情報を送ったことに応答して、前記データが必要とされる前記時間に、またはその前に、前記ストリーミングアウェアネットワーク要素から前記データを受信するステップをさらに含む、請求項1に記載の方法。
【請求項１１】
前記データは、リアルタイムのメディアデータ、ストリーミングメディアデータ、メディアセグメント、またはメディアサブセグメントのうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項１２】
前記データはメディアセグメントを含み、前記デッドライン情報を送るステップは、前記データがフルセグメントとして、それとも複数のメディア配信イベント(MDE)として受信されるべきかを表すデータを送るステップを含む、請求項1に記載の方法。
【請求項１３】
前記デッドライン情報を送るステップは、前記ストリーミングサーバに、前記デッドライン情報をストリーミングアウェアネットワーク要素へフォワードさせるために、ハイパーテキスト転送プロトコル(HTTP)によりストリーミングサーバに前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
【請求項１４】
前記デッドライン情報を送るステップは、無線アクセスネットワーク(RAN)を介して直接、ストリーミングアウェアネットワーク要素に前記デッドライン情報を送るステップを含む、請求項1に記載の方法。
【請求項１５】
リアルタイム制約を有するデータを取り出すためのクライアントデバイスであって、
前記リアルタイム制約を有する前記データをバッファリングするためのバッファを備えるメモリと、
デジタル論理回路機構を備えるハードウェアベースのプロセッサとを備え、前記プロセッサは、リアルタイムのアプリケーションを実行するように構成され、前記アプリケーションは、
前記データがダウンロードのために利用可能である時間を判断し、
前記バッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断し、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るように構成される、クライアントデバイス。
【請求項１６】
前記リアルタイムのアプリケーションは、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから、前記データがダウンロードのために利用可能である前記時間を判断するように構成される、請求項15に記載のクライアントデバイス。
【請求項１７】
前記リアルタイムのアプリケーションは、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するように構成される、請求項15に記載のクライアントデバイス。
【請求項１８】
前記リアルタイムのアプリケーションは、前記デッドライン情報を、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で送るように構成される、請求項15に記載のクライアントデバイス。
【請求項１９】
前記リアルタイムのアプリケーションは、前記デッドライン情報を判断するように構成され、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項15に記載のクライアントデバイス。
【請求項２０】
前記リアルタイムのアプリケーションは、前記デッドライン情報を判断するように構成され、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項15に記載のクライアントデバイス。
【請求項２１】
前記リアルタイムのアプリケーションは、プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るようにさらに構成される、請求項15に記載のクライアントデバイス。
【請求項２２】
リアルタイム制約を有するデータを取り出すためのデバイスであって、
前記データがダウンロードのために利用可能である時間を判断するための手段と、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断するための手段と、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送るための手段とを備えるデバイス。
【請求項２３】
前記データが利用可能である前記時間を判断するための前記手段は、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断するための手段を備える、請求項22に記載のデバイス。
【請求項２４】
前記要求および前記デッドライン情報を送るための前記手段は、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定するための手段を備える、請求項22に記載のデバイス。
【請求項２５】
前記要求および前記デッドライン情報を送るための前記手段は、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送るための手段を備える、請求項22に記載のデバイス。
【請求項２６】
前記デッドライン情報を判断するための手段をさらに備え、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項22に記載のデバイス。
【請求項２７】
前記デッドライン情報を判断するための手段をさらに備え、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項22に記載のデバイス。
【請求項２８】
プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送るための手段をさらに備える、請求項22に記載のデバイス。
【請求項２９】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されると、クライアントデバイスのプロセッサに、
前記データがダウンロードのために利用可能である時間を判断させ、
前記クライアントデバイスのバッファのためにバッファアンダーランを防止するために前記データが必要とされる時間を判断させ、
前記データが利用可能なとき、前記データについての要求、および前記バッファアンダーランを避けるために前記データが必要とされる前記時間を表すデッドライン情報を送らせる、コンピュータ可読記憶媒体。
【請求項３０】
前記プロセッサに、前記データが利用可能である前記時間を判断させる前記命令は、前記プロセッサに、前記データについてのマニフェストファイルまたは前に受信されたデータのうちの少なくとも1つから前記時間を判断させる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３１】
前記プロセッサに、前記要求および前記デッドライン情報を送らせる前記命令は、前記プロセッサに、前記デッドライン情報を前記要求のHTTPヘッダ拡張中で指定させる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３２】
前記プロセッサに、前記要求および前記デッドライン情報を送らせる前記命令は、前記プロセッサに、HTTP GETまたは部分GET要求のユニフォームリソースロケータ(URL)の照会パラメータ中で前記デッドライン情報を送らせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３３】
前記プロセッサに前記要求を送らせる前記命令は、前記プロセッサに、ストリーミングアウェアネットワーク要素、DASHアウェアネットワーク要素(DANE)、DASHサーバ、モバイルセルサイト、またはワイヤレスアクセスポイントのうちの少なくとも1つへ前記要求を送らせる命令を含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３４】
前記プロセッサに前記デッドライン情報を判断させる命令をさらに含み、前記デッドライン情報は、前記要求中で指定された前記データが受信される必要がある壁時計時間または前記要求を発行してから、前記要求中で指定された前記データが受信される必要があるまでの最大ラウンドトリップ時間のうちの少なくとも1つを表す情報のうちの少なくとも1つを含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３５】
前記プロセッサに前記デッドライン情報を判断させる命令をさらに含み、前記デッドライン情報は、前記クライアントデバイスのバッファについてのバッファレベルを表すデータ、前記バッファレベル情報が生成された時間を表すタイムスタンプ、または前記データが前記クライアントデバイスによって再生されているレートを表すプレイアウトデータレートのうちの少なくとも1つを含む、請求項29に記載のコンピュータ可読記憶媒体。
【請求項３６】
前記プロセッサに、プレイアウト曲線または前記デッドライン情報をもつ前記プレイアウト曲線のサブサンプリングされたバージョンのうちの少なくとも1つを表すデータを送らせる命令をさらに含む、請求項29に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、その内容全体が参照により本明細書に組み込まれる、2015年10月16日に出願されたPCT出願第PCT/CN2015/092095号の優先権を主張する。
【０００２】
本開示は、メディアデータの搬送に関する。
【背景技術】
【０００３】
デジタルメディア能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込むことができる。
【０００４】
デジタルメディアは、送信に先立って圧縮されてよい。たとえば、ビデオデータは、空間的予測および/または時間的予測を実施し、ビデオシーケンスに固有の冗長性を低減または除去するビデオ圧縮技法を使って圧縮され得る。
【０００５】
メディアデータが符号化された後、メディアデータは送信または記憶のためにパケット化され得る。メディアデータは、国際標準化機構(ISO)ベースメディアファイルフォーマットおよびその拡張などの、様々な規格のいずれかに準拠するメディアファイルへと、アセンブルされ得る。メディアデータはさらに、動的適応ストリーミングオーバーHTTP(DASH)などのストリーミングプロトコルにより、コンピュータベースのネットワークを使って送信され得る。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】R. Fielding他、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月
【非特許文献２】T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月
【非特許文献３】DASH-IF IOP v3.1、セクション4.3.4
【発明の概要】
【課題を解決するための手段】
【０００７】
概して、本開示は、メディアデータについてのデッドライン情報をシグナリングするための技法について記載する。つまり、クライアントデバイスは、DASHセグメントなどのメディアファイルが受信されなければならない時間を表すデータをシグナリングし得る。この時間は、クライアントデバイスによる平滑な、連続したプレイアウトを保証するために(たとえば、バッファアンダーランを防止するために)メディアファイルが受信されなければならない時間を表し得る。
【０００８】
一例では、リアルタイム制約を有するデータを取り出す方法が、リアルタイムのアプリケーションを実行するデジタル論理回路機構を備えるハードウェアベースのプロセッサを有するクライアントデバイスによって実施される。方法は、データがダウンロードのために利用可能である時間を判断するステップと、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するステップと、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るステップとを含む。
【０００９】
別の例では、リアルタイム制約を有するデータを取り出すためのクライアントデバイスは、リアルタイム制約を有するデータをバッファリングするためのバッファを備えるメモリと、デジタル論理回路機構を備えるハードウェアベースのプロセッサとを含む。プロセッサは、データがダウンロードのために利用可能である時間を判断し、バッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断し、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るように構成されたリアルタイムのアプリケーションを実行するように構成される。
【００１０】
別の例では、リアルタイム制約を有するデータを取り出すためのクライアントデバイスは、データがダウンロードのために利用可能である時間を判断するための手段と、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するための手段と、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るための手段とを含む。
【００１１】
別の例では、コンピュータ可読記憶媒体(つまり、非一時的コンピュータ可読記憶媒体)は、プロセッサに、データがダウンロードのために利用可能である時間を判断させ、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断させ、データが利用可能なとき、データについての要求、およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送らせる命令を記憶している。
【００１２】
1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１３】
【図１】ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。
【図２】取出しユニットの構成要素の例示的なセットを示すブロック図である。
【図３】例示的なマルチメディアコンテンツの要素を示す概念図である。
【図４】表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。
【図５】HTTP適応ストリーミングの共通理解を示す概念図である。
【図６】「スマート」クライアントデバイスの責任を示す概念図である。
【図７】MPEG DASHのスコープを示す概念図である。
【図８】本開示の技法による例示的なアーキテクチャを示す概念図である。
【図９】単純なクライアントモデルを示す概念図である。
【図１０】サーバおよびクライアントの視点からのセグメントを示す概念図である。
【図１１】ビデオオブジェクトデッドラインアウェアスケジューリングについての一例を示す概念図である。
【図１２】図11の例による例示的な実装形態の概念図である。
【図１３】ビデオオブジェクトデッドラインアウェアスケジューリングに基づく別の例示的なソリューションを示す概念図である。
【図１４】図13の技法による例示的な実装形態を示す概念図である。
【図１５】本開示の技法によるパケット化の例を示す概念図である。
【図１６】初期化セグメント(IS)および複数のメディアセグメント(MS)を含む一連のセグメントを示す概念図である。
【図１７Ａ】メディアセグメントについてのプレイアウト曲線を表す概念図である。
【図１７Ｂ】メディアセグメントについてのプレイアウト曲線を表す概念図である。
【図１８】セグメントのデータを配信するためのメディア配信イベント(MDE)の概念図である。
【図１９】起こり得る簡略化として使うことができる別の例を示す概念図である。
【図２０】本開示の技法による例示的な配信アーキテクチャの概念図である。
【図２１】本開示の技法による受信機モデルの概念図である。
【図２２】本開示の技法を実施するための例示的な方法を示すフローチャートである。
【発明を実施するための形態】
【００１４】
概して、本開示は、ハイパーテキスト転送プロトコル(HTTP)を使うメディアデータのストリーミング中にデッドライン情報をシグナリングするための技法について記載する。そのようなストリーミング技法は、本明細書ではHTTPストリーミングとも呼ばれる。特に、以下で説明するように、本開示は、クライアントデバイスのストリーミングクライアントが、それぞれのデッドラインまでにセグメントの迅速な配信を保証することを試みるために、ストリーミングアウェアネットワーク要素にデッドライン情報をシグナリングすることができるようにするための技法について記載する。同様に、ストリーミングアウェアネットワーク要素は、これらの技法を、セグメントがそれぞれのデッドラインまでにクライアントデバイスに届くように、クライアントデバイスにセグメントを配信するのに使うことができる。
【００１５】
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からの1つの表現、または各非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
【００２０】
表現は1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでよく、または表現の各セグメントは、自己初期化するものであってよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)のような、識別子によって一意に参照され得る。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
【００２１】
異なるタイプのメディアデータに関して実質的に同時に取り出すために異なる表現を選択することができる。たとえば、クライアントデバイスは、セグメントを取り出すオーディオ表現、ビデオ表現、および時限のテキスト表現を選択することができる。いくつかの例では、クライアントデバイスは、帯域幅適応を実施するために特定の適応セットを選択することができる。すなわち、クライアントデバイスは、ビデオ表現を含む適応セット、オーディオ表現を含む適応セット、および/または時限のテキストを含む適応セットを選択することができる。代替として、クライアントデバイスは、あるタイプのメディア(たとえば、ビデオ)に関する適応セットを選択し、他のタイプのメディア(たとえば、オーディオおよび/または時限のテキスト)に関する表現を直接選択することができる。
【００２２】
DASHは、オブジェクトベースのリアルタイムのストリーミング配信を可能にする。基本動作モードにおいて、クライアントは、サーバに対してデータを要求し、プレイアウトをスケジュールする。DASHクライアントは、プレイアウトを最適化し、バッファアンダーランを避けるために、バッファを使う。また、クライアントは、適切なプレイアウトを保証するためにセグメントがクライアントに到着することを保証するために、セグメントについての要求を適切にスケジュールする。基本動作では、全制御およびタイミングがクライアントにかかっている。
【００２３】
ただし、いくつかのシナリオでは、具体的には、サーバおよびネットワーク支援型DASH(SAND)において考慮されるケースでは、サーバおよびネットワークは、配信を主にネットワーク効率ならびにユーザエクスペリエンスの点で最適化するために、クライアントと協力し、クライアントを支援する。さらに、HTTP要求は通常、状態をもたない、時間に関係のない要求としてネットワークにおいて扱われるので、クライアントは、特にネットワークが配信についてのデッドラインを認識している場合、HTTPを介したオブジェクトの配信においてネットワークをサポートすることができる。そのような技術は特に、ネットワークがそのようなデッドラインを配信において利用することができるケースにおいて適している。
【００２４】
このコンテキストにおいて、本開示は、SANDのコンテキストにおける以下のメッセージの追加を提案する。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。
●要求されたオブジェクトについての最大RTT(持続時間)を提供するための状況メッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。
【００２５】
本開示の技法は、いくつかの利点をもたらし得る。たとえば、本開示の技法は、DASHアウェアネットワーク要素(DANE)またはメディアアウェアネットワーク要素(MANE)などのネットワーク要素に、データがクライアントデバイスに配信されるための、クライアントデバイスのタイミング要件の情報を提供することができる。これは、データがクライアントデバイスによって必要とされるときにクライアントデバイスがデータを受信することを保証することができ、このことは、データについてのクライアントデバイスのリアルタイム制約を満足し得る。たとえば、DASHのコンテキストでは、メディアデータは、いくつかの時間において、バッファアンダーフロー(つまり、クライアントデバイスが、すべてのバッファリングされたデータを消費する)を避けることを求められる場合がある。バッファアンダーフローは、バッファアンダーランとも呼ばれ得る。バッファアンダーフローは概して、結果として、追加データの受信を待ち受けることを必要とするものであり、このことが、再生における望ましくない一時停止を引き起こし得る。これらの技法は、バッファアンダーフローを避けることによって、そのような一時停止を避けることができる。
【００２６】
図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)に変換され得る。同じ表現内で、ストリーム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)のサイズ、コード化ピクチャバッファ(CPB)のサイズ、垂直方向の運動ベクトルの範囲、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(アドバンストビデオコーディング)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用を実現する。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は、マルチキャストグループに加わるための要求を提出することができる。この要求は、ルータがマルチキャストグループに関連付けられたIPアドレス宛のトラフィックをクライアントデバイス40などの加入クライアントデバイスに向けるように、ネットワーク74中、たとえば、ネットワーク74を構成するルータに伝搬され得る。
【００４７】
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、品質が異なるビデオサービス)の記述を包含してよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を含み得る。クライアントデバイス40は、表現68のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを取り出し得る。
【００４８】
具体的には、取出しユニット52は、ビデオデコーダ48の復号能力とビデオ出力44のレンダリング能力とを決定するために、クライアントデバイス40の構成データ(図示せず)を取り出し得る。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GETおよび部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを備え得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能性のすべてまたは一部は、ハードウェア、または、ハードウェア、ソフトウェア、および/もしくはファームウェアの組合せにおいて実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
【００４９】
取出しユニット52は、クライアントデバイス40の復号およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は、表現68の特性を決定するために、マニフェストファイル66の少なくとも一部分を最初に取り出し得る。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性について説明する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40の復号およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内の表現に対するビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
【００５０】
概して、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになる場合がある。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このように、クライアントデバイス40は、ネットワーク74の変化するネットワーク帯域幅の利用可能性にも適応しながら、ネットワーク74を介してマルチメディアデータをストリーミングし得る。
【００５１】
追加または代替として、取出しユニット52は、ブロードキャスト、またはeMBMSもしくはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加わるための要求を提出することができる。取出しユニット52は、マルチキャストグループに加わった後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を発行することなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、たとえば、再生を停止するために、または、チャネルを異なるマルチキャストグループに変更するために、マルチキャストグループのデータがもはや必要とされないとき、マルチキャストグループを出るための要求を提出することができる。
【００５２】
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部それともビデオストリームの一部であるかに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送る一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力44に送る。
【００５３】
図1には示さないが、ネットワーク74は、DASHアウェアネットワーク要素(DANE)またはメディアアウェアネットワーク要素(MANE)などのストリーミングアウェアネットワーク要素をさらに含み得る。取出しユニット52は、後でより詳細に記載される、ネットワーク74のストリーミングアウェアネットワーク要素にデッドライン情報を広告するための本開示の技法を実装することができる。
【００５４】
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理回路機構、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路機構のいずれかとして実装され得る。いくつかの例では、ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50のうちの1つまたは複数が、「システムオンチップ」(または「SoC」)と呼ばれる、単一の製造されたチップに統合され得る。ビデオエンコーダ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に対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに対する符号化ピクチャ(または、フレーム)を含み得る。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
【００５９】
メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を包含し得るメディアプレゼンテーション記述(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とをさらに含む。この例では、eMBMS受信ユニット106は、たとえば、http://tools.ietf.org/html/rfc6726において入手可能な、T. Paila他、「FLUTE-File Delivery over Unidirectional Transport」、Network Working Group、RFC 6726、2012年11月に記述されたFile Delivery over Unidirectional Transport(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に提供することができる。
【００６７】
図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は、図2の表現68に対応し得る。一般に、MPD122は、復号およびレンダリング特性、適応セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的サブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへのターゲティング広告の挿入のため)のような、表現124の特性を一般に表すデータを含んでよい。
【００６９】
ヘッダデータ126は、存在するとき、セグメント128の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間的ロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むのか、セグメント128内のランダムアクセスポイントへのバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在するとき、セグメント132の同様の特性を記述し得る。追加または代替として、そのような特性はMPD122内に完全に含まれ得る。
【００７０】
セグメント128、132は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD122のデータによって記述され得るが、そのようなデータは図3の例には示されていない。MPD122は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
【００７１】
セグメント128、132の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、別個に取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント128または132を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント128または132の特定のバイト範囲を取り出すことができる。
【００７２】
図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更新ボックスに関する追加の情報を提供する。
【００７５】
図4の例では、MOOVボックス154は、ムービーヘッダ(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(図3)がビデオファイル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つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)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は、SAPのビデオファイル150内の位置の指示を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号され得るように、セグメント内に並べられ得る。たとえば、データの階層的構成において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
【００８６】
図5は、HTTP適応ストリーミングセッションに参加するように構成されたデバイスを含むシステム200を示す概念図である。この例では、システム200は、キャプチャデバイス202、符号化および暗号化デバイス204、メディアオリジンサーバデバイス206A〜206N(メディアオリジンサーバデバイス206)、HTTPキャッシュサーバデバイス208A〜208N(HTTPキャッシュサーバデバイス208)、クライアントデバイス210A〜210N(クライアントデバイス210)、ならびにデジタル著作権管理(DRM)ライセンスサーバデバイス212A〜212N(DRMライセンスサーバデバイス212)を含む。概して、キャプチャデバイス202は図1のオーディオソース22とビデオソース24のいずれかまたは両方に対応してよく、符号化および暗号化デバイス204は図1のオーディオエンコーダ26、ビデオエンコーダ28、および/またはカプセル化ユニット30に対応してよく、メディアオリジンサーバデバイス206および/またはHTTPキャッシュサーバデバイス208のいずれかまたはすべては図1のサーバデバイス60に対応してよく、クライアントデバイス210は図1のクライアントデバイス40に対応してよい。
【００８７】
この例では、キャプチャデバイス202は、メディアデータ(たとえば、オーディオおよび/またはビデオデータ)をキャプチャする。符号化および暗号化デバイス204は、メディアデータの複数のセット(たとえば、複数の表現)を形成するために、メディアデータを複数のビットレートで符号化する。符号化および暗号化デバイス204のセットの各々は、メディアデータを、図4のビデオファイル150などの小さいセグメントに分裂させることができる。さらに、符号化および暗号化デバイス204は、各セグメントを暗号化し、各セグメントを、HTTP URLを介して、メディアオリジンサーバデバイス206およびHTTPキャッシュサーバデバイス208により利用可能にすることができる。クライアントデバイス210のうちの1つまたは複数などのクライアントデバイスは、どのセグメントをダウンロードするか判断し、暗号化コンテンツ用のライセンスをDRMライセンスサーバデバイス212のうちの1つから獲得し、次いで、コンテンツをつなぎ合わせ、プレイバックする。
【００８８】
図6は、「スマート」クライアントデバイスの責任を示す概念図である。図6の例は、コンテンツ分配ネットワーク(CDN)220および例示的な「スマート」クライアントデバイスを表すクライアントデバイス222の例を示す。この例では、クライアントデバイス222は、1つまたは複数のマニフェストファイル(たとえば、1つまたは複数のMPD)、HTTPトランスポート、および1つまたは複数のTCP接続を管理する。クライアントデバイス222は、プレイアウトバッファ、セグメントのダウンロード時間およびスループット、(CPU、メモリ、スクリーンなどのような)ローカルリソース、ならびにドロップされたフレームを監視し、または測定する。クライアントデバイス222は、帯域幅適応も実施する。
【００８９】
図7は、HTTPサーバ232およびDASHクライアント240を含むシステム230を示す概念図である。システム230は、そのようなシステムにおけるMPEG DASHのスコープについて説明するために示されている。特に、この例では、HTTPサーバ232は、メディアコンテンツ234Aおよびメディアコンテンツ234Bなど、メディアコンテンツの様々なセットを記憶する。メディアコンテンツ234Aは、MPD236Aおよびセグメント238Aを含む。メディアコンテンツ234Bは、MPD236Bおよびセグメント238Bを含む。DASHクライアント240は、制御エンジン242、メディアエンジン244、MPDパーサ246、セグメントパーサ248、およびHTTPクライアント250を含む。概して、制御エンジン242、HTTPクライアント250、およびMPDパーサ246は図1の取出しユニット52に対応してよく、セグメントパーサ248は図1のカプセル化解除ユニット50に対応してよく、メディアエンジン244はオーディオデコーダ46および/またはビデオデコーダ48に対応してよい。MPEG DASHのスコープ内の、システム230の要素は、グレーシェーディングを使ってハイライトされている。この例では、MPEG DASHは、MPD236、セグメント238、MPDパーサ246、およびセグメントパーサ248を含むスコープを有する。
【００９０】
図8は、本開示の技法による例示的なシステム260を示す概念図である。図8の例に示すように、システム260はHTTPサーバ262およびDASHクライアント270を含み、これらは、それぞれ図7のHTTPサーバ232およびDASHクライアント240と同様である。つまり、HTTPサーバ262は、MPD266Aおよびセグメント268Aを含むメディアデータ264Aと、MPD266Bおよびセグメント268Bを含むメディアデータ264Bとを記憶する。同様に、DASHクライアント270は、制御エンジン272、メディアエンジン274、MPDパーサ276、セグメントパーサ278、およびHTTPクライアント280を含む。ただし、システム260は、下位レイヤトランスポート284を介してDASHクライアント270に結合されたDASHアウェアネットワーク要素(DANE)デバイス282をさらに含む。
【００９１】
図8は、考慮されるメッセージフローのハイレベルアーキテクチャを提供する。DASHメディアが、HTTPサーバ262上に記憶され、HTTP-CDNを通して配信される。DASHクライアント270は、セッションを制御し、適切な時間にHTTP要求を発行する。HTTP接続を終端する中間ノード(たとえば、DANE282)は、DASHアンアウェアな場合はキャッシュとして、またはDASHアウェアな場合はDANEとして作用し得る。DANE282は、たとえば、下位レイヤトランスポート284を介してデッドライン情報を提供することによって、配信を最適化するために、HTTPサーバ262および/またはDASHクライアント270から情報を受信することができ、そうすることによって、DANE282または下位レイヤトランスポート284にのっとった他のデバイスは、メディアデータがDASHクライアント270に配信されるための配信決定において、デッドライン情報を利用することができる。
【００９２】
図9は、単純なクライアントモデル290を示す概念図である。図1のクライアントデバイス40、図5のクライアントデバイス210、図6のクライアントデバイス222、図7のDASHクライアント240、および図8のDASHクライアント270は概して、クライアントモデル290に従って構成され得る。クライアントモデル290の例において、クライアントは、ダウンロードエンジン292、バッファ294、ならびにメディアデコーダおよびレンダラ296を含む。図1のクライアントデバイス40に関して、たとえば、ダウンロードエンジン292およびバッファ294は取出しユニット52に含まれてよく、メディアデコーダおよびレンダラ296は、オーディオデコーダ46、ビデオデコーダ48、オーディオ出力42、およびビデオ出力44に対応してよい。
【００９３】
DASH-IF IOP v3.1、セクション4.3.4の記述によると、DASHクライアントは次のように作用する。DASHクライアントは、MPD中で提供される情報によって、たとえば、図9に示すクライアントモデル290に従って案内される。
【００９４】
DASHクライアントは、MPDへのアクセスを有し、各セグメントについてのセグメント利用可能性時間をMPDから導出することができると仮定する。簡単のために、MPDは、期間開始時間PSwc[i]をもつ単一の期間を含むだけであり、MPD-URLはいかなるフラグメントパラメータも含まないと仮定される。以下の例示的なクライアント挙動は、連続したストリーミングエクスペリエンスをユーザに提供する。
1.DASHクライアントは、MPDを解析し、その環境に適した適応セットの集合体を、AdaptationSet要素の各々の中で提供される情報に基づいて選択する。
2.各適応セット内で、DASHクライアントは、通常は@bandwidth属性の値に基づいて、ただしクライアントの復号およびレンダリング能力も考慮に入れて、1つの表現を選択する。
3.DASHクライアントは、MPD中の情報およびDASHクライアントにおける現在時間JOIN、ならびに、特に、ライブエッジセグメントと呼ばれるライブエッジに最も近いセグメントを考慮に入れて、少なくとも各選択された表現についてのアクセス可能セグメントのリストを作成する。
4.DASHクライアントは、選択された表現の初期化セグメントをダウンロードし、次いで、セグメント全体またはセグメントのバイト範囲を要求することによって、コンテンツにアクセスする。通常、いつでも、DASHクライアントは、(i)現在のセグメントのダウンロードの完了、または(ii)次のセグメントのセグメント利用可能性開始時間のうちのより大きい方において、次のセグメントをダウンロードする。@availabilityTimeOffsetが存在する場合、セグメントは、より早く、すなわち、調節されたセグメント利用可能性開始時間にダウンロードされ得る。バッファフルネスおよび他の基準に基づいて、レート適応が検討される。通常、ダウンロードされる第1のメディアセグメントはライブエッジセグメントであるが、スタートアップ待ち時間を最小限にするために、他の決定が行われる場合がある。
5.図9の例によると、ダウンロードエンジン292は、取り出されたメディアデータをバッファ294中に供給し、どこかの時点で、メディアデコーダおよびレンダラ296が、メディアデータを復号し、レンダリングし始める。各選択された適応セットの選択された表現を、ダウンロードエンジン292がダウンロードし、メディアデコーダおよびレンダラ296が提示する。同期は、MPD中でシグナリングされる期間情報中のプレゼンテーション時間を使って行われる。同期されたプレイアウトのために、メディアにおける正確なプレゼンテーション時間が使われるものとする。
a.プレゼンテーションが始まると、プレイアウトプロセスは絶え間なく続く。プレイアウトプロセスは、メディアデータがバッファ294中に絶えず存在するという仮定に基づく。MPD中にMPD@suggestedPresentationDelayが存在する場合、この値はプレゼンテーション遅延、すなわちPDとして使われ得る。MPD中にMPD@suggestedPresentationDelayが存在しないが、DASHクライアントが、ライブエッジにおいてサービスを消費すると予想される場合、適切なプレゼンテーション遅延が、通常は@minBufferTimeの値と@timeShiftBufferDepthの値との間で選択されるべきである。DASHクライアントは、ダウンロードされたメディアセグメントkの第1のサンプルを、最も早いプレゼンテーション時間EPT(k)で、PSwc[i]+(EPT(k)-o[r,i])+PDにおいてレンダリングし始めることが推奨される。
6.DASHクライアントは、利用可能性時間ウィンドウ中に、生成されたセグメントリストを使うことによって、選択された表現のメディアセグメントを要求することができる。
7.プレゼンテーションが始まると、DASHクライアントは、ダウンロードエンジン292がメディアセグメントまたはメディアセグメントのいくつかの部分を連続的に要求するという点で、メディアコンテンツを消費し続け、メディアデコーダおよびレンダラ296は、メディアプレゼンテーションタイムラインに従ってコンテンツを再生する。DASHクライアントは、その環境からの更新された情報を考慮に入れて、表現を切り替えることができるが、この態様は、本文書における考察には比較的関連性がない。
8.壁時計時間NOWが進むと、DASHクライアントは利用可能セグメントを消費する。NOWが進むと、クライアントは可能性として、利用可能セグメントのリストを、期間中の各表現について拡大する。
【００９５】
いくつかの態様が、上の黒丸5〜7に要約されている。DASHクライアントは、要求のスケジューリングおよびプレイアウトスケジューリングを制御する。同時に、DASHクライアントは、バッファアンダーフローを避けるために、表現の次のセグメントが利用可能になる必要がある最新の時間についての知識を有する。情報は、少なくとも、MPDからの良好な正確さで(期間タイムラインからメディアタイムラインへのマッピングを使う)、ただし、前のセグメントがダウンロードされると、一層良好な正確さで利用可能である。さらなる詳細が、以下の図10に示されている。
【００９６】
図10は、サーバデバイスおよびクライアントデバイスの視点からのセグメントを示す概念図である。サーバデバイスは、データ(たとえば、セグメント)を利用可能にし、一定の時間(特定のセグメントがサーバからの取出しのために利用可能である時間期間は、「セグメント利用可能性ウィンドウ」と呼ばれ得る)までデータを利用可能なままにしておく。DASHクライアントは、この情報(すなわち、利用可能性の時間またはセグメント利用可能性ウィンドウ)をMPDから判断する。
【００９７】
DASHクライアントがMPDを初めてダウンロードした(図10のFetchMPD(1))後、DASHクライアントは、セグメント1および2が利用可能であると判断する。さらに、時間とともに、ますます多くのセグメントが、MPD中で提供される情報に基づいて利用可能になる。ある程度のプレゼンテーション遅延(提案されたプレゼンテーション遅延またはクライアントが選択したものを使う)の後のどこかの時点で、DASHクライアントは、プレイアウトをスケジュールし、取り出されたセグメントのメディアデータを復号およびレンダリングし始める。始まると、クライアントは、MPDと、セグメントが要求されたときとに基づいて、平滑なプレイアウトを保証するために、DASHクライアント中でセグメントがいつ利用可能にならなければならないかを判断することができる。同時に、DASHクライアントは、セグメントがサーバ上で依然として利用可能である最新の時間を判断することができる。
【００９８】
本開示の技法によると、DASHクライアント(図8のDASHクライアント270など)は、デッドライン情報(つまり、バッファアンダーランなどのリアルタイム制約を満足するために特定のセグメントまたは他のデータが受信されなければならないときを表す情報)を生成し、要求をどのようにスケジュールするかをネットワークが決めるために、デッドライン情報をネットワークに返送することができる。以下でいくつかの例について説明する。さらに、DASHクライアントは、いくつかの状況では、比較的良好なネットワーク時間プロトコル(NTP)同期クロックに従い得る。他の状況では、同期ははるかに緩くてよい。さらに、利用可能性時間およびスケジューリングは、静的タイプコンテンツ、たとえば、オンデマンドコンテンツにも関わる。
【００９９】
デッドライン情報を使うための様々な使用ケースが企図される。そのようなデッドライン情報を使うためのいくつかの例には、以下のものがある。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインについての情報は、緊急オブジェクトの適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。
【０１００】
関連ソリューションを作成する際、以下の基準が考慮される。
●ソリューションは単純でよい。
●ソリューションは好ましくは、DASHに依存せずに働き得る。
●ソリューションは、SAND状況メッセージフレームワークの一部であり得る。
●ソリューションは、DASHクライアント用に実装可能であり得る。
●ソリューションは、絶対値または相対値としてのデッドライン情報の提供を可能にし得る。
●ソリューションは、正規セグメント要求ならびにバイト範囲要求(たとえば、HTTP GETまたは部分GET要求)とともに働き得る。
●ソリューションは、最適化であり、後方互換方式で働き得る。
【０１０１】
概して、いくつかのシナリオでは、DASHクライアントが、要求されたメディアデータを適時に受信していないので、バッファアンダーランが起こり得るという問題が生じ得る。つまり、様々な理由により、DASHクライアントがメディアデータを要求するのにもかかわらず、メディアデータは時間内に配信されない場合があり、したがって、DASHクライアントのバッファの内容は、新規メディアデータが利用可能になり、復号およびレンダリングの用意ができる前に空にされ得る。
【０１０２】
本開示の技法は、DASHクライアントが、タイミング情報を十分に認識しているという基本的考え方を前提とする。つまり、DASHクライアントは、マニフェストファイル(たとえば、MPD)から、壁時計時間で以下の情報、すなわち、ネットワーク上でセグメントがいつ利用可能であるか、および平滑なプレイアウトを続けることが可能である(たとえば、バッファアンダーランを防止する)ために、各セグメントが受信機において利用可能である必要がある時間を判断することができる。DASHクライアントが、この情報の一部をDANEに提供した場合、DANEは、セグメントが時間内に受信機において利用可能になることを保証するために、配信を最適化することができる。説明の目的で、本技法は、DASHクライアントおよびDANEに関して記載されるが、これらの技法は、他のストリーミングデバイス(たとえば、他の任意のストリーミングクライアントおよびストリーミングアウェアネットワーク要素)によって実施されてよい。
【０１０３】
ユーザ機器(UE)(つまり、クライアントデバイス)は、DANEなどのストリーミングアウェアネットワーク要素に、以下の情報を報告し得る。
●HTTPストリーミングプレイアウトバッファ状況:
○バッファレベル(ms)。
○タイムスタンプ:UEがバッファ状況情報を生成する時間。
○プレイアウトデータレート:eNBがDASHアウェアでない場合、eノードB(eNB)がUEのバッファレベルを推定するため。
●セグメント全体(オブジェクト)についての壁時計時間でのデッドラインまたは最大RTT。
○UEは、この時間を各HTTP GET要求中で指定することができる。
●より詳細な情報。たとえば、セグメントの初期部分が、後半部分とは異なるデッドラインを有するということであってよい。
○クライアントは、初期パケットのデッドラインを報告する。
○オブジェクトは、中間ノードが各バイト範囲の配信をDASHクライアントからの情報およびプレイアウト曲線に従ってスケジュールすることができるように、各バイト範囲についてのプレイアウトスケジュールを含む。
●また、受信モード、すなわちフルセグメントモードまたはメディア配信イベント(MDE)モードを報告する。
【０１０４】
クライアントデバイスは、追加または代替として、プレイアウト情報を報告することができる。
●プレイアウトスケジュールは、以下のようであり得る。
○デフォルトでステップ関数となり、すなわち、セグメント全体が、利用可能である必要がある。
○プレイアウト曲線(時間によるバイト範囲)として、メディア/DASHサーバから補足情報として報告される。
○クライアントが、スケジューリングにおいて使われ得るそのような情報を(たとえば、セグメントインデックスによって)有する場合、クライアントからDANEに返送する。
●そのような情報は、スケジューラによって、バイト範囲の配信を最適化するのに使われ得る。
【０１０５】
図11は、ビデオオブジェクトデッドラインアウェアスケジューリングを実施するための1つの例示的な方法を示す概念図である。この例では、方法は、クライアントデバイス302、DASHサーバデバイス304、およびDANE306を含むシステム300によって実施される。DANE306は、次に、パケットゲートウェイ(PGW)デバイス308およびeノードB310を含む。この例では、クライアントデバイス302は、デッドライン情報を、HTTP要求によりDASHサーバ304に配信する(312)。特に、クライアントデバイス302(UEの例)は、HTTPによりデッドライン情報をDASHサーバに報告する。DASHサーバ304は次いで、デッドライン情報をDANE306のPGWデバイス308に送る(314)。さらに、PGWデバイス308は、デッドライン情報をeノードB310に送る(316)。次いで、eノードB310は、デッドライン情報を使って、DASHサーバデバイス304へのメディアデータ(たとえば、セグメントまたはMDE)の配信をスケジュールし(318)、デバイス304は次いで、メディアデータをクライアントデバイス302に送って(320)、メディアデータが、デッドライン情報に従って、クライアントデバイス302のバッファのバッファアンダーランを防止するためにメディアデータが必要とされる時間に、またはその前に、クライアントデバイス302に到着することを保証することができる。代替として、eノードB310は、メディアデータをクライアントデバイス302に直接配信してよい。
【０１０６】
一例では、PGWデバイス308とDASHサーバデバイス304(プロキシサーバデバイスに対応し得る)との間には、ネットワークトンネルがある。デッドライン情報は、マルチプロトコルラベルスイッチング(MPLS)などのネットワークトンネルプロトコルに従って送られるトンネル化パケットのヘッダ中で搬送され得る。
【０１０７】
別の例では、PGWデバイス308は、DASHサーバデバイス304から受信されたパケットに対して選択的ディープパケット検査(DPI)を実施することができる。つまり、HTTPサーバデバイス304は、HTTPメッセージ中にデッドライン情報を含めることができる。PGWデバイス308は、デッドライン情報を取り出すために、DASHサーバデバイス304からのパケットに対してDPIを実施することができる。
【０１０８】
PGWデバイス308は、eノードB310(つまり、基地局)に送られる各ダウンリンクパケットのGPRSトンネリングプロトコルU(GTP-U)ヘッダ中にデッドライン情報を含めればよい。eノードB310は次いで、これらのパケットの送信をデッドライン情報ごとにスケジュールすればよい。
【０１０９】
別の例では、クライアントデバイス302は、HTTPによりデッドライン情報をDANE306に報告することができる。DANE306は、各セグメントのプレイアウト曲線を解釈することもできる。DANE306は次いで、この情報を、eノードB310のスケジューラにとって利用可能にしてよい。eノードB310は次いで、この情報を、プレイアウトスケジューリング(たとえば、パケット配信)を最適化するのに使うことができる。
【０１１０】
HTTPベースのデッドライン情報配信において、クライアントデバイス302によって実行されるストリーミングクライアントからDANE306に送られる情報(たとえば、メディアデータについての要求に対応するパケット)は、デッドライン情報を含み得る。デッドライン情報は、シンタックスおよびプロトコルオプションを含み得る。これらのオプションは、HTTPヘッダ拡張中に、および/または照会パラメータの一部として要求中に含まれ得る。追加または代替として、デッドライン情報は、既存の展開に、たとえば、HTTP/1.1ベースの配信またはHTTP/2.0ベースの配信にマップされ得る。DASHサーバデバイス304からDANE306への情報およびこの例におけるデッドライン情報の使用は、リアルタイムオブジェクト配信オーバー単方向トランスポート(ROUTE:Real-Time Object Delivery over Unidirectional Transport)トランスポートプロトコルおよびMDEを含み得る。
【０１１１】
様々な例において、これらの様々なデバイスの間で交換される情報は、様々な問題に対するソリューションを定義し得る。たとえば、セグメント全体(オブジェクト)についての、壁時計時間でのデッドライン、セグメント全体(オブジェクト)についての、ミリ秒での最大RTT、クライアントにおける現在利用可能なバッファ、および/またはより詳細な情報(たとえば、セグメントの初期部分が、後半部分とは違うデッドラインを有するということであってよい)を含み得る、どのような情報がクライアントからネットワークに送られるかという意味論的問題である。同様に、シンタックスおよびプロトコルオプションが、要求における照会パラメータの一部としての、要求におけるHTTPヘッダ拡張、またはDASHクライアントとDANEとの間の他の制御チャネル中で交換され得る。さらに、そのような情報から、HTTP/1.1ベースの配信、HTTP/2.0ベースの配信、またはROUTEトランスポートプロトコルおよびMDEなど、既存の展開へのマッピングがあり得る。
【０１１２】
図12は、図11の方法を実施することができるシステム330の例示的な実装形態の概念図である。この例では、システム330は、この例ではパケットゲートウェイ(PGW)/サービングゲートウェイ(SGW)342であるゲートウェイ(GW)の上にHTTPプロキシ/キャッシュ344を含む。さらに、システム330は、クライアントデバイス332、eノードB340、およびCDN346を含む。PGW/SGW342とHTTPプロキシ/キャッシュ344は、この例では、Gi-LANインターフェース348によって結合される。その上、クライアントデバイス332はモデム336を含み、モデム336は、eノードB340と通信するように構成され得る。クライアントデバイス332はHTTPクライアント334も含み、クライアント334は、クライアントデバイス332のデジタル論理回路機構(図12には示さず)を備える、ハードウェアベースのプロセッサによって実行されるストリーミングアプリケーションであってよい。クライアントデバイス332はキャッシュ338も含み、キャッシュ338は、取り出されたメディアコンテンツをバッファリングするための、様々なランダムアクセスメモリ(RAM)、ハードディスク、フラッシュドライブなどのいずれかのような、物理的、非一時的コンピュータ可読媒体の一部分を表し得る。
【０１１３】
クライアントデバイス332およびHTTPプロキシ/キャッシュ344は、本開示の技法に従ってデッドライン情報を交換するように構成され得る。つまり、クライアントデバイス332は、デッドライン情報報告技法を実装することができ、HTTPプロキシ/キャッシュ344は、報告されたデッドライン情報に従ってメディアデータがクライアントデバイス332において利用可能であることを保証するために、デッドラインベースのスケジューリング技法を実装することができる。クライアントデバイス332およびHTTPプロキシ/キャッシュ344は、HTTPプロキシ/キャッシュ344からPGW/SGW342への無線アクセスネットワーク(RAN)を介して、デッドライン情報を、eノードB340へのGTP-Uヘッダ中で交換することができる。
【０１１４】
たとえば、クライアントデバイス332のHTTPクライアント334は、HTTPプロキシ/キャッシュ344を介してCDN346から取り出されるメディアデータのプレイアウトレートを判断するように構成され得る。HTTPクライアント334は、キャッシュ338の充填レベル(つまり、キャッシュ338中に記憶されたメディアデータの量)も判断することができる。キャッシュ338の充填レベルおよびプレイアウトレートに基づいて、HTTPクライアント334は、キャッシュ338のバッファアンダーランを防止するために、要求されたメディアデータが受信されなければならないデッドラインを判断することができる。HTTPクライアント334は、デッドラインを表すデッドライン情報を、たとえば、メディアデータについての要求中で広告してよく、要求は最終的に、HTTPプロキシ/キャッシュ344および/またはCDN346に配信される。HTTPプロキシ/キャッシュ344は、クライアントデバイス332のキャッシュ338のバッファアンダーランを防止するために、デッドライン情報に従って、要求されたメディアデータの配信を優先してよい。追加または代替として、eノードB340が、クライアントデバイス332のキャッシュ338のバッファアンダーランを防止するために、デッドライン情報に従って、要求されたメディアデータの配信を優先してよい。
【０１１５】
図13は、メディアオブジェクトデッドラインアウェアスケジューリングのための本開示の技法を実装し得る別の例示的なシステム350を示す概念図である。システム350は、DASHサーバ352、PGW354、eノードB356、およびクライアントデバイス358を含む。やはり、クライアントデバイス358は、図1のクライアントデバイス40と同様の構成要素を含んでよく、DASHサーバ352は、図1のサーバデバイス60と同様の構成要素を含んでよい。この例では、クライアントデバイス358は、DANE固有デッドライン情報を、たとえば、eノードB356に配信する。特に、クライアントデバイス358は、たとえば、パケットデータコンバージェンスプロトコル(PDCP)または無線リソース制御(RRC)プロトコルを使って、RANシグナリングによりデッドライン情報をeノードB356に報告する。クライアントデバイス358はDASHクライアントを実行することができ、DASHクライアントは、アプリケーションプログラミングインターフェース(API)により、デッドライン情報をクライアントデバイス358のモデムに報告してよい。
【０１１６】
デッドライン情報を受信した後、eノードB356は、デッドライン情報ごとに、クライアントデバイス358とDASHサーバ352との間のHTTPストリーミングセッション用の送信をスケジュールすることができる。つまり、DASHサーバ352は、メディアデータ(たとえば、適応セットの表現のセグメントの全部または一部分)についての要求をクライアントデバイス358から受信し、要求されたメディアデータを、PGW354およびeノードB356を介してクライアントデバイス358に送ればよい。次いで、eノードB356は、クライアントデバイス358から前に受信されたデッドライン情報に従って、要求されたメディアデータの配信を優先してよい。
【０１１７】
デッドライン情報は、様々なやり方でダウンリンク(DL)パケットに関連付けられ得る。一例では、HTTPプロキシが、eノードB356に論理的に統合され得る。したがって、HTTPプロキシは、特定のデッドラインを要求されたメディアデータ(たとえば、セグメント番号)に関連付けるテーブルまたは他のデータ構造を記憶することができる。つまり、テーブルは、メディアデータ(特定のセグメント番号など)のセットを表す第1の列、および対応するセグメントに関連付けられたデッドライン情報中で指定されたデッドラインを表す第2の列を含み得る。したがって、HTTPプロキシが、第1の列中で識別されたセグメントをキャッシュしているとき、HTTPプロキシは、テーブルの第2の列中で指定されたデッドラインに、またはその前にセグメントがクライアントデバイス358に配信されることを保証するために、クライアントデバイス358へのセグメントの配信を優先してよい。別の例では、専用ベアラチャネルが、HTTPストリーミングセッション用に確立され得る。
【０１１８】
図14は、図13に関して上で論じた方法を実施することができる例示的なシステム360を示す概念図である。この例では、システム360は、クライアントデバイス362、eノードB370、PGW/SGW376、およびCDN378を含む。クライアントデバイス362は、HTTPクライアント364、モデム366、およびキャッシュ368を含み、eノードB370はHTTPプロキシ/キャッシュ372を含む。したがって、eノードB370のHTTPプロキシ/キャッシュ372は、RANキャッシングと呼ばれるHTTPキャッシングを実施する。したがって、eノードB370は、コンテンツを論理的にキャッシュすることができる。モデム366、キャッシュ368、eノードB370、およびHTTPプロキシ/キャッシュ372はまとめて、HTTPプロキシ374と呼ばれ得る。
【０１１９】
物理的に、HTTPプロキシ/キャッシュ372およびキャッシュ用のメモリは、eノードB370の外にあってよい(たとえば、以下の図15に示すように)。ローカルに、物理的にキャッシュされない場合、eノードB370は、CDN378またはコンテンツサーバからPGW/SGW376を介してコンテンツをフェッチする。これは、eノードB370をインターネットに直接曝すのを避け、HTTPによるサービス継続性も保証する。モバイルネットワークオペレータは、予測に基づいてeノードB370にコンテンツをプッシュしてもよい。クライアントデバイス362は、PDCP、HTTP、またはRRCを介して、デッドライン情報をeノードB370に報告すればよい。
【０１２０】
図15は、本開示の技法によるパケット化の例を示す概念図である。この例では、プレイアウト曲線メタデータが、送付機によって、データを適切にパケット化し、スケジュールするのに使われ得る。
【０１２１】
図16は、初期化セグメント(IS)382および複数のメディアセグメント(MS)384A〜384G(MS384)を含む一連のセグメント380を示す概念図である。IS382は、1つの構成要素に対して、すべての関連メタデータ、ならびにメディアデータを包含し、ファイルフォーマットレベルでランダムアクセスポイントを提供し、バイトでのサイズ、ファイルフォーマットでの最も早いプレゼンテーション時間(期間の開始に相対したISO BMFFタイムライン内)および持続時間情報、すなわち、それが(「期間/MPU」内で)またがるサンプルの持続時間を提供する。セグメント382、384の順序連結の結果、ISO BMFF用の適合ビットストリームが生じる。
【０１２２】
図17Aおよび図17Bは、メディアセグメントについてのプレイアウト曲線を表す概念図である。プレイアウト曲線は、一定の時間まで存在するのに必要なバイトの量を表す。曲線の形状は、メディアエンコーダ/準備によって決定される。例は、サンプル境界および時間における線形増加を含む。完全なセグメントが、プレイアウトのために必要である。プレイアウト曲線は、トランスポートによって、配信に使われ得る。より多くのメタデータが、トランスポート用に追加され、または使われてよい。
【０１２３】
いくつかの例では、適切なプレイアウトのために、セグメント全体が受信機において利用可能である必要がある。そのようなモデルは、いくつかの受信機実装形態には適しているが、多くのケースでは、セグメントは「プログレッシブに」、すなわち、同時に再生し、ダウンロードすることによって再生され得る。そのような特徴は特に、低遅延シナリオに適している。情報は、単純なデッドライン状況メッセージへの拡張として、クライアントからDANEに提供されてよく、またはPEDとしてDASHサーバからDANEに提供されてよい。
【０１２４】
メディアセグメントは、再生可能プレフィックスに下位分割され得る。セグメント中で最も早いプレゼンテーション時間を仮定すると、プレイアウト曲線は、一定の時間まで存在するのに必要なバイトの量を表す。「最悪ケース」では、すべてのバイトが、最も早いプレゼンテーション時間を再生するのに必要である。このケースでは、セグメント全体が一度利用可能になるだけで、データが再生され得る。ただし、通常、セグメント全体のプレフィックスのみがあれば、セグメントは、提示され始めることができ、連続的により多くのバイトがプレフィックスに追加されると、ますます多くのプレゼンテーション時間が再生され得る。プレイアウト曲線の形状は、メディアエンコーダ/準備によって決定される。いくつかの例は、以下を含む。
●サンプル境界および時間における線形増加(たとえば、図17Aに示すように)
●完全なセグメントが、プレイアウトのために必要である。
●復号およびプレゼンテーション順序のためのより複雑な構造は、たとえば、階層状のBピクチャが使われるとき、同一でない。
【０１２５】
2つの異なるプレイアウト曲線を、図17Bに示す。x軸は、プレゼンテーション時間(PT)から、セグメントの最も早いプレゼンテーション時間(EPT)を引いたものを示す。EPTを再生するために、一定の量のバイトが必要である。破線曲線は、EPTをもつサンプルを再生するのにセグメントのすべてのバイトを求めるが、実線曲線は、再生し始めるのに、小さい部分を必要とするだけであり、幾分多くのデータが続く。プレイアウト曲線は、典型的な階段ケースである。
【０１２６】
ネットワークは、曲線を認識している場合、ネットワークが、クライアントがいつEPTを受信する必要があるかも知っていると仮定すると、データの適時受信を保証するために、関連するバイト範囲の配信を最適化することができる。これは、たとえば、図9および図10に関して上で論じた技法によって遂行され得る。
【０１２７】
図18は、セグメントのデータを配信するためのメディア配信イベント(MDE)の概念図である。IP/UDP/ROUTE中にカプセル化されているランダムアクセスポイント(RAP)で始まるMDEは、T-RAPで始まるT-MDEになる。
【０１２８】
図19は、起こり得る簡略化した例において本開示の技法を実施するのに使われ得る別の例示的なシステム390を示す概念図である。この例では、システム390は、ROUTE受信機および出力バッファ392、ISO BMFFバッファ396、ISO BMFFデコーダ398、DASHクライアント394、ならびにCDN404を含む。概して、ROUTE受信機および出力バッファ392は、RAPパケット400およびメディアデータを含むパケット402A、402Bを、ROUTEを介して受信する。追加または代替として、DASHクライアント394は、HTTPなどのユニキャストプロトコルにより、CDN404からセグメントを取り出す。したがって、特定のセグメントを受信する、ROUTE受信機および出力バッファ392またはDASHクライアント394のうちの1つが、ISO BMFFバッファ396にセグメントを提供する。ISO BMFFデコーダ398は、ISO BMFFレベルでの復号のために、たとえば、オーディオデコーダまたはビデオデコーダなど、対応するメディアデコーダによって復号されるべきPESパケットを抽出するために、ISO BMFFバッファ396からセグメントを取り出す。この例では、下位レイヤシグナリングが、MPD406なしでサービスを開始するのに十分な情報を提供する。ユニキャストが追加された場合のみ、またはより豊富な選択が必要な場合、MPD406が照会される。依然として、統合MPD406が存在するが、MPD406は、スタートアップおよび/またはブロードキャストのみのために必要なわけではない。
【０１２９】
図20は、本開示の技法による例示的な配信アーキテクチャ410の概念図である。この例では、配信アーキテクチャ410は、ISO BMFFおよびビデオエンコーダ412、セグメンタおよびROUTE送付機412、ならびに送付スケジューラ414をサーバ/送付機側に、ROUTE受信機および出力バッファ416、ISO BMFFバッファ418、ならびにISO BMFFデコーダ420をクライアント/受信機側に含む。概して、ISO BMFFおよびビデオエンコーダ412は、セグメンタおよびROUTE送付機412にISO BMFFストリーム422を送る。セグメンタおよびROUTE送付機412は、ISO BMFFストリーム422をそれぞれのパケット426A、426B(パケット426)およびランダムアクセスポイント(RAP)パケット424に分割し、パケット424、426を送付スケジューラ414に送る。
【０１３０】
送付スケジューラ414は、ROUTE受信機および出力バッファ416にパケット424、426をいつ送るかを判断する。パケットを送った後、ROUTE受信機および出力バッファ416は、送付スケジューラ414からパケット424、426を受信する。ROUTE受信機および出力バッファ416は、復号およびプレゼンテーションを始動し、スケジュールするための情報430をISO BMFFデコーダ420に送る。ROUTE受信機および出力バッファ416はまた、パケット424、426からISO BMFFストリーム422を再構築し、ISO BMFFストリーム422をISO BMFFバッファ418に送る。ISO BMFFデコーダ420は、たとえば、たとえばオーディオおよびビデオデコーダ(図20には示さず)によって復号されるべきメディアデータを含むPESパケットを抽出するために、ISO BMFFレベルで復号されるべきメディアデータ428を、ISO BMFFバッファ418からフェッチする。
【０１３１】
プログレッシブプレイアウトを使うための使用ケースの様々な例について、以下で論じる。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。プログレッシブプレイアウトについての情報は、無線スケジューラによって、TCP/IPを使って、対応するセル中で配信を最適化するのに使われ得る。
●DANEが、ホームゲートウェイとコロケートされる。可能性としては異なるユーザからの、デッドラインとともにプログレッシブプレイアウトについての情報は、いくつかのオブジェクトの緊急部分の適時配信を保証するために、ネットワークへの要求を最適化するのに使われ得る。
●DANEが、モバイル基地局(PGWと一緒に)、たとえばeNBとコロケートされる。デッドラインおよびプログレッシブプレイアウトについての情報は、無線スケジューラによって、TCPとは異なる配信プロトコル、たとえばパケットベースのプロトコルを使って、対応するセル中で配信を最適化するのに使われ得る。図20は、そのようなケースのための起こり得る配信アーキテクチャを示す。セグメンタおよびROUTE送付機412は、パケッタイザとして作用し得る。さらに、この例では、セグメンタおよびROUTE送付機412は、ATSCにおいて定義されているROUTEを使い、パケットがROUTE受信機および出力バッファ416に送られ/それによって受信される目標時間を追加するために、送付機からの(プログレッシブプレイアウト)、および可能性としては受信機からの情報(デッドライン情報)を使うことができる。こうすることにより、ネットワークは、この情報を、たとえば、ISO BMFFバッファ418についてバッファアンダーランがないことを保証するのに使うことができる。
【０１３２】
図21は、本開示の技法による受信機モデルの例の2つの概念図を示す。モデル440の例は、ROUTE受信機および出力バッファ442、ISO BMFFバッファ444、ならびにISO BMFFデコーダ446を含む。ROUTE受信機および出力バッファ442は、パケット448、450を受信する。ROUTE受信機および出力バッファ442は、復号およびプレゼンテーションを始動し、スケジュールするための情報456をISO BMFFデコーダ446に送る。ROUTE受信機および出力バッファ442はまた、パケット448、450からISO BMFFストリーム452を再構築し、ISO BMFFストリーム452をISO BMFFバッファ444に送る。ISO BMFFデコーダ446は、たとえば、たとえばオーディオおよびビデオデコーダ(図21のモデル440には示さず)によって復号されるべきメディアデータを含むPESパケットを抽出するために、ISO BMFFレベルで復号されるべきメディアデータ454を、ISO BMFFバッファ444からフェッチする。
【０１３３】
モデル460の例は、ROUTE受信機および出力バッファ462、MSEバッファ464、ブラウザおよびJava(登録商標)スクリプトユニット478、ならびにプレイアウトユニット466を含む。ROUTE受信機および出力バッファ462は、パケット468、470を受信する。ROUTE受信機および出力バッファ462は、復号およびプレゼンテーションを始動し、スケジュールするための情報476をISO BMFFデコーダ446に送る。Java(登録商標)スクリプトを(たとえば、ブラウザ478へのプラグインとして)も実行するプロセッサによって実行されるブラウザ478は、ROUTE受信機および出力バッファ462からメディアユニットを抽出し、メディアユニットをMSEバッファ464に配信する。プレイアウトユニット466は、復号され、提示されるべきメディアデータ474を、ISO BMFFバッファ444からフェッチする。
【０１３４】
上記使用ケースおよびシナリオに対処するために、以下の拡張が提供され、本開示の様々なユニットおよび構成要素によって使われ得る。
●受信機における、要求されたオブジェクトについての絶対デッドライン(壁時計)を提供するための状況メッセージ。つまり、受信機(特に、受信機のプロセッサ)は、状況メッセージ中で、絶対デッドラインを壁時計時間で指定し、この状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●要求されたオブジェクトについての最大ラウンドトリップ時間(RTT)(持続時間)を提供するための状況メッセージ。つまり、受信機は、状況メッセージ中で、最大RTTを指定し、このメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するためのPEDメッセージ。つまり、受信機は、1つまたは複数のPEDメッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらのPEDメッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
●セグメントの異なるバイト範囲の相対デッドラインを提供するための状況メッセージ。つまり、受信機は、1つまたは複数の状況メッセージ中で、セグメントの異なるバイト範囲の相対デッドラインを指定し、これらの状況メッセージを、たとえば、eノードB、HTTPプロキシ、DANEなどに送ることができる。
【０１３５】
AbsoluteDeadlineパラメータが、デッドライン情報中で指定され得る。このパラメータにより、DASHクライアントは、セグメントが受信される必要がある、壁時計時間での絶対デッドラインをDANEキャッシュに指示することができる。
【０１３６】
AbsoluteDeadlineパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
【０１３７】
以下のテーブルは、AbsoluteDeadlineパラメータ用の例示的なデータ表現を表す。
【０１３８】
【表１】
2018532334.tif 000003
【０１３９】
絶対的な時間のフォーマット用に、基本的には、以下のフォーマットのうちのどれが使われてもよい。絶対的な時間のフォーマットについての例は、以下を含む。
●xsdateフォーマット
●ISOタイミングフォーマット
●NTPフォーマット
【０１４０】
要求中で拡張ヘッダ(またはヘッダ拡張)を定義するための例示的なやり方は、次のようになる。
X-Dash-Deadline-ISO:<ISOフォーマットでの時間>
【０１４１】
一例は次の通りである。
X-Dash-Deadline-ISO:2015-10-11T17:53:03Z
【０１４２】
追加または代替として、最大ラウンドトリップ時間(MaxRTT)パラメータが、デッドライン情報中で指定され得る。このパラメータにより、DASHクライアントは、要求が発行された時間から、要求されたデータがDASHクライアントにおいて完全に利用可能になる必要があるときまでの、要求の最大ラウンドトリップ時間をDANEキャッシュに指示することができる。時間はmsで表され得る。
【０１４３】
MaxRTTパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
【０１４４】
以下のテーブルは、MaxRTTパラメータ用の例示的なデータ表現を表す。
【０１４５】
【表２】
2018532334.tif 000004
【０１４６】
要求中で拡張ヘッダを定義するための例示的なやり方は、次のようになる。
X-Dash-MaxRTT:<msでの最大ラウンドトリップ時間>
【０１４７】
一例は次の通りである。
X-Dash-MaxRTT:2345
【０１４８】
この例は、バッファアンダーフローを避けるために、クライアントが、要求を発行してから2.345秒後に、セグメントの利用可能性を要求することを表す。
【０１４９】
追加または代替として、デッドライン情報は、プログレッシブプレイアウトプロファイルメトリック(ProgressivePlayout)パラメータを含み得る。このパラメータにより、DASHクライアントは、セグメントのプログレッシブプレイアウトプロファイルをDANEキャッシュに指示することができる。
【０１５０】
ProgressivePlayoutパラメータ用のソースおよび宛先は、次のようになり得る。
●タイプ:メトリック
●送付機:DASHクライアント
●受信機:DANE
【０１５１】
以下のテーブルは、ProgressivePlayoutパラメータ用の例示的なデータ表現を表す。
【０１５２】
【表３】
2018532334.tif 000005
【０１５３】
要求中で拡張ヘッダを定義するための例示的なやり方は、次のようになる。
X-Dash-Progressive-Playout:<バイトおよびmsでの時間のタプル>
【０１５４】
一例は次の通りである。
X-Dash-Progressive-Playout:<4321,0;62345,200;82220,400;1010101,600;121212,800;1313131;1000>
【０１５５】
この例は、プレイアウトを始動するために、4321バイトが配信される必要があることと、次いで、プレイアウト時間の各々についてのバイトの総量とを表す。ステップは、デルタとしても表され得ることに留意されたい。
【０１５６】
ProgressivePlayout情報は、追加または代替として、応答とともに拡張ヘッダとして配信され得る。
【０１５７】
デッドライン情報をこのようにしてシグナリングすると、メディアデータなど、リアルタイム制約を有するデータの適時配信を保証することができる。たとえば、デッドライン情報をDANEに提供することによって、DANEは、リアルタイム制約に従ってクライアントデバイスにデータが配信されることを保証することができる。したがって、DASHまたはメディアデータの他のストリーミングに関して、クライアントデバイスはバッファアンダーフローを避けることができ、これは、連続した、平滑なプレイアウトを保証することができる。
【０１５８】
図22は、本開示の技法を実施するための例示的な方法を示すフローチャートである。図22の技法は、図1のサーバデバイス60およびクライアントデバイス40に関して記載される。ただし、これらまたは同様の技法は、たとえば、図5のクライアントデバイス210およびメディアオリジンサーバデバイス206またはHTTPキャッシュサーバデバイス208、図6のクライアントデバイス222およびCDN220のサーバ、図7のDASHクライアント240およびHTTPサーバ232、図8のDASHクライアント270およびHTTPサーバ262またはDANE282、図9のダウンロードエンジン292、図11のクライアントデバイス302およびDASHサーバデバイス304またはDANE306、図12のクライアントデバイス332およびeノードB340またはHTTPプロキシ/キャッシュ344、図13のクライアントデバイス358およびeノードB356またはDASHサーバ352、図14のクライアントデバイス362およびeノードB370/HTTPプロキシ/キャッシュ372、図19のシステム390に従って構成されたクライアントデバイス、図20の、セグメンタおよびROUTE送付機412と送付スケジューラ414とを含むサーバデバイスならびにROUTE受信機および出力バッファ416と、ISO BMFFバッファ418と、ISO BMFFデコーダ420とを含むクライアントデバイス、または図21のモデル440もしくは460のいずれかの、構成要素を含むクライアントデバイスなど、本明細書に示す他のデバイスによって実施され得ることを理解されたい。
【０１５９】
この例では、サーバデバイス60が、セグメントが利用可能になる壁時計時間を指定する情報を含むメディアプレゼンテーション記述(MPD)(または、他の例では他のマニフェストファイル)を最初に準備し、または受信すると推定される。したがって、クライアントデバイス40は、サーバデバイス60に対してMPDを要求する(480)。サーバデバイス60は、MPDについての要求を受信し(482)、それに応答して、クライアントデバイス40にMPDを送る(484)。したがって、クライアントデバイス40はMPDを受信する(486)。
【０１６０】
クライアントデバイス40は、たとえば、クライアントデバイス40の復号およびレンダリング能力(たとえば、オーディオデコーダ46およびビデオデコーダ48の復号能力、オーディオ出力42およびビデオ出力44のレンダリング能力、ならびにたとえば、様々な適応セットについてのプロファイル、ティア、および/またはレベルシグナリング情報中で指定された復号およびレンダリング要件)に従って、メディアデータをそこから取り出すべき1つまたは複数の適応セットを判断するのに、MPDを使う。クライアントデバイス40は次いで、セグメントをそれに対して要求するべき適応セットの各々の表現を、たとえば、ネットワーク帯域幅の利用可能量に基づいて選択すればよい。クライアントデバイス40は次いで、選択された表現のセグメントを要求し始め、セグメントを受信し、受信されたときにセグメントをバッファリングしてよい。
【０１６１】
さらに、本開示の技法によると、クライアントデバイス40は、MPDからセグメント利用可能性時間を判断することができる(488)。クライアントデバイス40は、まだ利用可能でないセグメントを要求するのを避けるために、セグメントが取出しのためにいつ利用可能であるかを判断するのに、セグメント利用可能性時間を使うことができる。さらに、クライアントデバイス40は、プレイアウトレートおよびバッファ充填レベルを判断することができる(490)。つまり、クライアントデバイス40は、メディアデータの再生により、どれだけ急速にバッファが空にされているかを追跡し、また、バッファの現在の充填レベルを監視することができる。この情報に基づいて、クライアントデバイス40は、バッファアンダーランを避けるために、次のセグメントが受信されなければならないときを判断することができる(492)。他の例では、クライアントデバイス40は、バイト範囲など、セグメントのある部分が受信されなければならないときを判断することができ、セグメントの異なる部分(たとえば、バイト範囲)について異なる値を判断する場合がある。概して、クライアントデバイス40は、セグメント(またはその部分)が受信されなければならない時間を、公式
Deadline=CurrentTime-FillLevel/PlaybackRate
に従って算出することができ、上式で、Deadlineは、次のセグメントが受信されなければならない、壁時計時間での時間であり、CurrentTimeは、壁時計時間での現在時間であり、FillLevelは、バッファに記憶されたデータの量であり、PlaybackRateはメディアデータの再生レートである。
【０１６２】
したがって、次のセグメントが利用可能なとき、クライアントデバイス40は、(たとえば、HTTP GETまたは部分GET要求を使って)次のセグメントを要求してよく、バッファアンダーランを避けるためにセグメント(またはその部分)が受信されなければならない時間を表すデッドライン情報をさらに送ることができる(494)。いくつかの例では、クライアントデバイス40は、要求自体にデッドライン情報を、たとえば、上述したように、属性としてHTTPヘッダ拡張中に、またはセグメント用のURLの引数もしくは要素として、要求を含むパケットのヘッダ中などに含めてよい。代替として、クライアントデバイス40は、やはり上で論じたように、デッドライン情報をサイド情報として指定してよい。さらに、デッドライン情報は、上で論じた値「Deadline」であってよく、または単に、サーバデバイス60(DANE、eノードB、HTTPプロキシ/キャッシュなどのような中間デバイスを表し得る)がデッドライン値を、たとえば、上の公式に従って算出することができるように、クライアントデバイス40によって判断されたバッファ充填レベル、現在時間用のタイムスタンプ、および/もしくは再生レート情報を含んでよい。
【０１６３】
サーバデバイス60は次いで、セグメントについての要求を受信し得る(496)。サーバデバイス60は次いで、たとえば、要求自体から、またはクライアントデバイス40から受信されたサイド情報から、セグメントについてのデッドライン情報を判断することができる(498)。サーバデバイス60は次いで、要求されたセグメント(またはその部分、たとえば、セグメントの要求されたバイト範囲)の配信を、デッドライン情報に従って優先してよい(500)。たとえば、サーバデバイス60は、データがクライアントデバイス40に到着するためのラウンドトリップ時間を判断し、要求されたセグメント(またはそのバイト範囲)の配信を、データが受信されなければならないデッドラインに先んじてラウンドトリップ時間の少なくとも半分であるときにスケジュールすることができる。サーバデバイス60は次いで、要求されたセグメント(またはその部分)を、デッドライン情報(つまり、優先度付け)に従って送ってよい(502)。
【０１６４】
最終的に、クライアントデバイス40は、バッファアンダーランを避けるためにセグメントが必要とされるデッドラインに、またはその前にセグメントを受信し得る(504)。したがって、クライアントデバイス40は、後続プレイアウトのために、セグメントをバッファに追加することができる(506)。後で、セグメントよりも前の、バッファ中のデータがバッファから抽出されてから、セグメントは、抽出され、復号され、プレイアウトされ、そのときまでに追加データが(たとえば、ステップ488〜504の技法に従って)取り出されてしまってよく、やはりバッファアンダーランを防止するために、バッファリングされる。
【０１６５】
このように、図22は、データがダウンロードのために利用可能である時間を判断するステップと、クライアントデバイスのバッファのためにバッファアンダーランを防止するためにデータが必要とされる時間を判断するステップと、データが利用可能であるとき、データについての要求およびバッファアンダーランを避けるためにデータが必要とされる時間を表すデッドライン情報を送るステップとを含む方法の例を表す。
【０１６６】
1つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して送信され、ハードウェアベース処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含み得る。このように、コンピュータ可読媒体は、一般に、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コード、および/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品が、コンピュータ可読媒体を含む場合がある。
【０１６７】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、レーザーを用いてデータを光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
【０１６８】
命令は、1つもしくは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路機構もしくは個別論理回路機構などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、または本明細書で説明する技法の実装に適した任意の他の構造のいずれかを指すことがある。加えて、いくつかの態様では、本明細書で説明された機能性は、符号化および復号のために構成された専用のハードウェアモジュールおよび/もしくはソフトウェアモジュール内で提供され得、または複合コーデックに組み込まれ得る。また、技法は、1つまたは複数の回路または論理要素で完全に実装され得る。
【０１６９】
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)または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受信ユニット
110  DASHクライアント
112  メディアアプリケーション
120  マルチメディアコンテンツ
122  メディアプレゼンテーション記述(MPD)
124  表現
124A  表現
124N  表現
126  ヘッダデータ
128  セグメント
128A〜128N  セグメント
130  ヘッダデータ
132  セグメント
132A〜132N  セグメント
150  ビデオファイル
152  ファイルタイプ(FTYP)ボックス
154  ムービー(MOOV)ボックス
156  ムービーヘッダ(MVHD)ボックス
158  トラック(TRAK)ボックス
160  ムービー延長(MVEX)ボックス
162  セグメントインデックス(sidx)ボックス
164  ムービーフラグメント(MOOF)ボックス
166  ムービーフラグメントランダムアクセス(MFRA)ボックス
200  システム
202  キャプチャデバイス
204  符号化および暗号化デバイス
206  メディアオリジンサーバデバイス
206A〜206N  メディアオリジンサーバデバイス
208  HTTPキャッシュサーバデバイス
208A〜208N  HTTPキャッシュサーバデバイス
210  クライアントデバイス
210A〜210N  クライアントデバイス
212  デジタル著作権管理(DRM)ライセンスサーバデバイス
212A〜212N  デジタル著作権管理(DRM)ライセンスサーバデバイス
220  コンテンツ分配ネットワーク(CDN)
222  クライアントデバイス
230  システム
232  HTTPサーバ
234A  メディアコンテンツ
234B  メディアコンテンツ
236  MPD
236A  MPD
236B  MPD
238  セグメント
238A  セグメント
238B  セグメント
240  DASHクライアント
242  制御エンジン
244  メディアエンジン
246  MPDパーサ
248  セグメントパーサ
250  HTTPクライアント
260  システム
262  HTTPサーバ
264A  メディアデータ
266A  MPD
268A  セグメント
264B  メディアデータ
266B  MPD
268B  セグメント
270  DASHクライアント
272  制御エンジン
274  メディアエンジン
276  MPDパーサ
278  セグメントパーサ
280  HTTPクライアント
282  DASHアウェアネットワーク要素(DANE)デバイス、DANE
284  下位レイヤトランスポート
290  クライアントモデル
292  ダウンロードエンジン
294  バッファ
296  メディアデコーダおよびレンダラ
300  システム
302  クライアントデバイス
304  DASHサーバデバイス
306  DANE
308  パケットゲートウェイ(PGW)デバイス
310  eノードB
330  システム
332  クライアントデバイス
334  HTTPクライアント
336  モデム
338  キャッシュ
340  eノードB
342  パケットゲートウェイ(PGW)/サービングゲートウェイ(SGW)
344  HTTPプロキシ/キャッシュ
346  CDN
348  Gi-LANインターフェース
350  システム
352  DASHサーバ
354  PGW
356  eノードB
358  クライアントデバイス
360  システム
362  クライアントデバイス
364  HTTPクライアント
366  モデム
368  キャッシュ
370  eノードB
372  HTTPプロキシ/キャッシュ
374  HTTPプロキシ
376  PGW/SGW
378  CDN
380  セグメント
382  初期化セグメント(IS)、セグメント
384  メディアセグメント(MS)、セグメント
384A〜384G  メディアセグメント(MS)
390  システム
392  ROUTE受信機および出力バッファ
394  DASHクライアント
396  ISO BMFFバッファ
398  ISO BMFFデコーダ
400  RAPパケット
402A  パケット
402B  パケット
404  CDN
406  MPD
410  配信アーキテクチャ
412  ISO BMFFおよびビデオエンコーダ
412  セグメンタおよびROUTE送付機
414  送付スケジューラ
416  ROUTE受信機および出力バッファ
418  ISO BMFFバッファ
420  ISO BMFFデコーダ
422  ISO BMFFストリーム
424  ランダムアクセスポイント(RAP)パケット、パケット
426  パケット
426A  パケット
426B  パケット
428  メディアデータ
430  情報
440  モデル
442  ROUTE受信機および出力バッファ
444  ISO BMFFバッファ
446  ISO BMFFデコーダ
448  パケット
450  パケット
452  ISO BMFFストリーム
454  メディアデータ
456  情報
460  モデル
462  ROUTE受信機および出力バッファ
464  MSEバッファ
466  プレイアウトユニット
468  パケット
470  パケット
474  メディアデータ
476  情報
478  ブラウザおよびJava(登録商標)スクリプトユニット、ブラウザ
466  プレイアウトユニット
【図１】
2018532334.tif 000006
【図２】
2018532334.tif 000007
【図３】
2018532334.tif 000008
【図４】
2018532334.tif 000009
【図５】
2018532334.tif 000010
【図６】
2018532334.tif 000011
【図７】
2018532334.tif 000012
【図８】
2018532334.tif 000013
【図９】
2018532334.tif 000014
【図１０】
2018532334.tif 000015
【図１１】
2018532334.tif 000016
【図１２】
2018532334.tif 000017
【図１３】
2018532334.tif 000018
【図１４】
2018532334.tif 000019
【図１５】
2018532334.tif 000020
【図１６】
2018532334.tif 000021
【図１７Ａ】
2018532334.tif 000022
【図１７Ｂ】
2018532334.tif 000023
【図１８】
2018532334.tif 000024
【図１９】
2018532334.tif 000025
【図２０】
2018532334.tif 000026
【図２１】
2018532334.tif 000027
【図２２】
2018532334.tif 000028
【国際調査報告】
2018532334.tif 000029
2018532334.tif 000030