(57)【特許請求の範囲】
【請求項１】
メディアデータを取り出す方法であって、
サーバデバイスから、メディアコンテンツの表現内に含まれる複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを示す情報を含むマニフェストファイルを受信するステップであって、前記複数のメディアセグメントのタイプが、
配信ユニットメディアセグメントフォーマットであって、前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数の自己完結型ムービーフラグメントを含む、配信ユニットメディアセグメントフォーマットと、
ランダムアクセスメディアセグメントフォーマットであって、前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、前記メディアセグメントの前記自己完結型ムービーフラグメントの各々における1番目のアクセスユニットが、タイプ1、2、または3のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、ランダムアクセスメディアセグメントフォーマットと、
重複なしメディアセグメントフォーマットであって、前記重複なしメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、かつ前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しない、重複なしメディアセグメントフォーマットと、
切替えメディアセグメントフォーマットであって、前記切替えメディアセグメントフォーマットに準拠するメディアセグメントが、前記ランダムアクセスメディアセグメントフォーマットに準拠し、1番目のムービーフラグメントの1番目のサンプルが、タイプ1または2のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、切替えメディアセグメントフォーマットとを含む、ステップと、
前記情報から、前記メディアコンテンツの表現内に含まれる前記複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを決定するステップと、
前記サーバデバイスからメディアコンテンツストリームのメディアセグメントを取り出すために、前記決定されたタイプを使用するステップとを含む、
方法。 
【請求項２】
メディアコンテンツのメディアセグメントを取り出すために、メディア情報をシグナリングする方法であって、
前記メディアコンテンツの表現内に含まれる複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを示すマニフェストファイルを構築するステップであって、前記複数のメディアセグメントのタイプが、
配信ユニットメディアセグメントフォーマットであって、前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数の自己完結型ムービーフラグメントを含む、配信ユニットメディアセグメントフォーマットと、
ランダムアクセスメディアセグメントフォーマットであって、前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠するランダムアクセスメディアセグメントフォーマットであって、
前記メディアセグメントの前記自己完結型ムービーフラグメントの各々における1番目のアクセスユニットが、タイプ1、2、または3のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、ランダムアクセスメディアセグメントフォーマットと、
重複なしメディアセグメントフォーマットであって、前記重複なしメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、かつ前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しない、重複なしメディアセグメントフォーマットと、
切替えメディアセグメントフォーマットであって、前記切替えメディアセグメントフォーマットに準拠するメディアセグメントが、前記ランダムアクセスメディアセグメントフォーマットに準拠し、1番目のムービーフラグメントの1番目のサンプルが、タイプ1または2のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、切替えメディアセグメントフォーマットとを含む、ステップと、
前記マニフェストファイルをクライアントデバイスに送信するステップと、
前記複数のメディアセグメントのタイプのうちの1つに準拠するメディアセグメントに対する前記クライアントデバイスからの要求に応答して、前記メディアセグメントのタイプに準拠するメディアセグメントを前記クライアントデバイスに送信するステップとを含む、
方法。 
【請求項３】
前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、前記メディアセグメントのセグメントタイプボックス内に「dums」の値を包含し、前記自己完結型ムービーフラグメントの各々が、ムービーフラグメント(「moof」)ボックスと、自己完結型ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備え、moofボックスの各々が少なくとも1つのトラックフラグメントを含み、前記moofボックスの各々が外部参照を使用せず、前記メディアセグメントの「default-base-is-moof」フラグが真に設定され、前記メディアセグメントの「base-data-offset-present」フラグが偽に設定される、
請求項1または2に記載の方法。 
【請求項４】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、メディアデータにアクセスするためのすべての必要な情報を前記メディアセグメントに続くビットストリーム内に含む、
請求項1または2に記載の方法。 
【請求項５】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備える、
請求項4に記載の方法。 
【請求項６】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数のセグメントインデックス(「sidx」)ボックスを含み、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、かつメディアセグメント全体を記述する、
請求項1または2に記載の方法。 
【請求項７】
メディアデータを取り出すクライアントデバイスであって、
サーバデバイスから、メディアコンテンツの表現内に含まれる複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを示す情報を含むマニフェストファイルを受信する手段であって、前記複数のメディアセグメントのタイプが、
配信ユニットメディアセグメントフォーマットであって、前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数の自己完結型ムービーフラグメントを含む、配信ユニットメディアセグメントフォーマットと、
ランダムアクセスメディアセグメントフォーマットであって、前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、前記メディアセグメントの前記自己完結型ムービーフラグメントの各々における1番目のアクセスユニットが、タイプ1、2、または3のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、ランダムアクセスメディアセグメントフォーマットと、
重複なしメディアセグメントフォーマットであって、前記重複なしメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、かつ前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しない、重複なしメディアセグメントフォーマットと、
切替えメディアセグメントフォーマットであって、前記切替えメディアセグメントフォーマットに準拠するメディアセグメントが前記ランダムアクセスメディアセグメントフォーマットに準拠し、1番目のムービーフラグメントの1番目のサンプルが、タイプ1または2のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、切替えメディアセグメントフォーマットとを含む、手段と、
前記情報から、前記メディアコンテンツの表現内に含まれる前記複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを決定する手段と、
前記サーバデバイスからメディアコンテンツストリームのメディアセグメントを取り出すために、前記決定されたタイプを使用する手段とを備える、
クライアントデバイス。 
【請求項８】
メディアコンテンツのメディアセグメントを取り出すためにメディア情報をシグナリングするサーバデバイスであって、
前記メディアコンテンツの表現内に含まれる複数のメディアセグメントのタイプのうちのどのタイプに準拠するかを示すマニフェストファイルを構築する手段であって、前記複数のメディアセグメントのタイプが、
配信ユニットメディアセグメントフォーマットであって、前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数の自己完結型ムービーフラグメントを含む、配信ユニットメディアセグメントフォーマットと、
ランダムアクセスメディアセグメントフォーマットであって、前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、前記メディアセグメントの前記自己完結型ムービーフラグメントの各々における1番目のアクセスユニットが、タイプ1、2、または3のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、ランダムアクセスメディアセグメントフォーマットと、
重複なしメディアセグメントフォーマットであって、前記重複なしメディアセグメントフォーマットに準拠するメディアセグメントが、前記配信ユニットメディアセグメントフォーマットに準拠し、かつ前記表現内の他のセグメントおよび前記表現を含む適応セット内の他の表現内の他のセグメントの開始時間および終了時間に重複しない、重複なしメディアセグメントフォーマットと、
切替えメディアセグメントフォーマットであって、前記切替えメディアセグメントフォーマットに準拠するメディアセグメントが、前記ランダムアクセスメディアセグメントフォーマットに準拠し、1番目のムービーフラグメントの1番目のサンプルが、タイプ1または2のISOベースのメディアファイルフォーマットのストリームアクセスポイント(SAP)のISAUである、切替えメディアセグメントフォーマットとを含む、手段と、
前記マニフェストファイルをクライアントデバイスに送信する手段と、
前記複数のメディアセグメントのタイプのうちの1つに準拠するメディアセグメントに対する前記クライアントデバイスからの要求に応答して、前記メディアセグメントのタイプに準拠するメディアセグメントを前記クライアントデバイスに送信する手段とを備える、
サーバデバイス。 
【請求項９】
前記配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントが、前記メディアセグメントのセグメントタイプボックス内に「dums」の値を包含し、前記自己完結型ムービーフラグメントの各々が、ムービーフラグメント(「moof」)ボックスと、自己完結型ムービーフラグメントボックス内のトラックによって参照される外部データ参照を使用しないメディアサンプルを含むメディアデータ(「mdat」)ボックスとを備え、moofボックスの各々が少なくとも1つのトラックフラグメントを含み、前記moofボックスの各々が外部参照を使用せず、前記メディアセグメントの「default-base-is-moof」フラグが真に設定され、前記メディアセグメントの「base-data-offset-present」フラグが偽に設定される、
請求項7または8に記載のデバイス。 
【請求項１０】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、メディアデータにアクセスするためのすべての必要な情報を前記メディアセグメントに続くビットストリーム内に含む、
請求項7または8に記載のデバイス。 
【請求項１１】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、瞬時デコーダリフレッシュ(IDR)ピクチャ、切断リンクアクセス(BLA)ピクチャ、またはクリーンランダムアクセス(CRA)ピクチャのうちの少なくとも1つを備える、
請求項7または8に記載のデバイス。 
【請求項１２】
前記ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントが、1つまたは複数のセグメントインデックス(「sidx」)ボックスを含み、順序を示す第1のsidxボックスが、前記メディアセグメントのすべてのmoofボックスに先行し、かつメディアセグメント全体を記述する、
請求項7または8に記載のデバイス。 
【請求項１３】
実行されたとき、請求項1〜6のいずれか一項に記載の方法をプロセッサに行わせる命令を記憶した、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、各々の内容全体が参照によって本明細書に組み込まれている、2015年2月10日に出願した米国仮出願第62/114,423号、および2015年6月22日に出願した米国仮出願第62/183,054号の利益を主張するものである。
【０００２】
本開示は、符号化ビデオデータの記憶および転送に関する。
【背景技術】
【０００３】
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263、ITU-T H.264/MPEG-4、Part10、アドバンストビデオコーディング(AVC:Advanced Video Coding)、ITU-T H.265/高効率ビデオコーディング(HEVC:High Efficiency Video Coding)により定義されている規格、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
【０００４】
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行し、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームまたはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
【０００５】
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化されてもよい。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】第3世代パートナシッププロジェクト、Technical Specification Group Services and System Aspects、Transparent end-to-end packet switched streaming service(PSS)、3GPPファイルフォーマット(3GP)(リリース12)V12.2.0、2013年12月
【非特許文献２】R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月
【発明の概要】
【課題を解決するための手段】
【０００７】
一般に、本開示は、低レイテンシビデオ(および/または、他のメディアデータ)ストリーミングを実現するために使用され得る技法について説明する。たとえば、メディアコンテンツは、互いの代替物として働く様々な表現を含み得る。本開示の技法によれば、1つの表現は周波数が比較的に高いストリーミングアクセスポイント(SAP)を含むことができる一方、もう1つの代替表現は周波数が比較的に低いSAPを含むことができる。マニフェストファイル(動的適応ストリーミングオーバーHTTP(DASH:Dynamic Adaptive Streaming over HTTP)のメディアプレゼンテーション記述(MPD)など)は、セグメントのタイプ(または、セグメントが準拠するフォーマット)、ならびにそのようなセグメントのロケーション(または、そのようなセグメントが対応する表現の中で生じる相対的周波数)をシグナリングすることができる。クライアントデバイスは、マニフェストファイルを使用して、周波数が比較的高いSAPを有する表現のうちの1つを決定し、次いで、異なるターゲット表現からSAPが利用可能になるまで、その表現からセグメントまたはセグメントの部分を取り出すことができる。ターゲット表現は、より少ない(すなわち、より低い周波数の)SAPを有するため、比較的より高い品質を有し得る。いくつかの例では、ユニキャストまたはブロードキャストなど、種々の取出しを機構によって種々の表現が利用可能であり得る。たとえば、初期表現はユニキャストを介して利用可能であり得る一方、ターゲット表現はブロードキャストを介して利用可能であり得る。
【０００８】
一例では、方法は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するステップと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するステップと、決定されたセグメントをその表現から取り出すステップとを含む。
【０００９】
別の例では、メディアデータを取り出すためのクライアントデバイスは、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととを行うように構成された1つまたは複数のプロセッサを含む。
【００１０】
別の例では、メディアデータを取り出すためのクライアントデバイスは、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するための手段であって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するための手段と、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するための手段と、決定されたセグメントをその表現から取り出すための手段とを含む。
【００１１】
別の例では、コンピュータ可読記憶媒体は、実行されると、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととをプロセッサに行わせる命令を記憶している。
【００１２】
別の例では、メディア情報をシグナリングする方法は、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するステップと、そのマニフェストファイルをクライアントデバイスに送るステップと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るステップとを含む。
【００１３】
別の例では、メディア情報をシグナリングするためのサーバデバイスは、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることと行うように構成された1つまたは複数のプロセッサを含む。
【００１４】
別の例では、メディア情報をシグナリングするためのサーバデバイスは、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するための手段であって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するための手段と、そのマニフェストファイルをクライアントデバイスに送るための手段と、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るための手段とを含む。
【００１５】
別の例では、コンピュータ可読記憶媒体は、実行されると、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることとをサーバデバイスのプロセッサに行わせる命令を記憶している。
【００１６】
1つまたは複数の例の詳細が、以下の添付の図面および説明で述べられる。他の特徴、目的、および利点は、説明、および図面、ならびに特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【００１７】
【図１】ストリームに迅速に加わるための例示的な使用事例を示す概念図である。
【図２】様々なタイプのメディアセグメント同士の間の関係を示すベン図である。
【図３】表現およびISOベースのメディアファイルフォーマット(BMFF)ファイルの例示的な構造を示す概念図である。
【図４】ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。
【図５Ａ】例示的なマルチメディアコンテンツの要素を示す概念図である。
【図５Ｂ】本開示の技法による、メディアプレゼンテーション記述の例示的なコンテンツを示す概念図である。
【図６】図5Aのセグメントのうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。
【図７】本開示の技法による、使用事例に関して提供される例示的なセグメントを示す概念図である。
【図８】本開示の技術による、スケーラブルHEVC(SHVC)との高速同調を含む使用事例を示す概念図である。
【図９】本開示の技術による、ストリームアクセスポイント(SAP)タイプ3との高速同調を含む例示的な使用事例を示す概念図である。
【図１０】高速同調およびハイブリダイゼーションを含む例示的な使用事例を示す概念図である。
【図１１】高速同調、ハイブリダイゼーション、およびオープンGOPを含む例示的な使用事例を示す概念図である。
【図１２】オープンGOPとの高速同調およびハイブリダイゼーションを含む別の例示的な使用事例を示す概念図である。
【図１３】高速同調および超低レイテンシを含む例示的な使用事例を示す概念図である。
【図１４】高速同調および超低レイテンシを含む別の例示的な使用事例を示す概念図である。
【図１５】本開示のいくつかの技法による、メディアコンテンツの表現のセグメントを取り出すための例示的な方法を示すフローチャートである。
【発明を実施するための形態】
【００１８】
一般に、本開示は、たとえば、ISOベースのメディアファイルフォーマット(ISOBMFF:ISO base media file format)および動的適応ストリーミングオーバーHTTP(DASH)に従ってフォーマットされたメディアコンテンツに基づく、低レイテンシビデオストリーミングのための技法について説明する。DASHは、たとえば、第3世代パートナシッププロジェクト、Technical Specification Group Services and System Aspects、Transparent end-to-end packet switched streaming service(PSS)、3GPPファイルフォーマット(3GP)(リリース12)V12.2.0、2013年12月において記述される。本開示は、同時に高効率ビデオコーディング構造を潜在的に有効化しながら、新しいDASHプロファイル(たとえば、アドバンストライブプロファイル)およびブロードキャストおよびマルチキャストにおける低減されたチャネル獲得およびチャネル変更回数を含む、低レイテンシビデオストリーミングを可能にし得るメディアセグメントのいくつかの新しいタイプに準拠し得るデータを定義およびシグナリングするための様々な方法について説明する。
【００１９】
ビデオコーディング規格は、ITU-T H.261と、ISO/IEC MPEG-1 Visualと、ITU-T H.262またはISO/IEC MPEG-2 Visualと、ITU-T H.263と、ISO/IEC MPEG-4 Visualと、そのスケーラブルビデオコーディング(SVC:Scalable Video Coding)およびマルチビュービデオコーディング(MVC:Multiview Video Coding)拡張を含むITU-T H.264またはISO/IEC MPEG-4 AVCと、そのスケーラブルコーディング拡張(すなわち、スケーラブル高効率ビデオコーディング、SHVC)およびマルチビュー拡張(すなわち、マルチビュー高効率ビデオコーディング、MV-HEVC)を含む、ITU-T H.265およびISO/IEC 23008-2としても知られている高効率ビデオコーディング(HEVC:High-Efficiency Video Coding)とを含む。
【００２０】
ランダムアクセスは、ビットストリーム内の第1のコード化ピクチャではない、コード化ピクチャから開始するビデオストリームの復号を指す。ビットストリームに対するランダムアクセスは、たとえば、ユーザが、いつでもプログラムに同調するために、異なるチャネル間を切り替えるために、ビデオの特定の部分にジャンプするために、または(ビットレート、フレームレート、空間分解度などの)ストリーム適合のために異なるビットストリームに切り替えるためになど、ブロードキャストおよびストリーミングなどの多くのビデオアプリケーションにおいて使用され得る。この特徴は、ランダムアクセスピクチャまたはランダムアクセスポイントを規則的な間隔で何回もビデオビットストリーム内に挿入することによって有効化にされ得る。
【００２１】
ビットストリームスプライシングは、2つ以上のビットストリームまたはその部分の連結を指す。たとえば、スプライスされたビットストリームを生成するために、第1のビットストリームを、第2のビットストリームによって、場合によっては、何らかの修正を用いて、ビットストリームのいずれか1つまたは両方に追加することができる。第2のビットストリーム内の第1のコード化ピクチャは、スプライシングポイントと呼ばれることもある。したがって、スプライスされたビットストリーム内のスプライシングポイントに続くピクチャは第2のビットストリームから発生し、スプライスされたビットストリーム内のスプライシングポイントに先行するピクチャは第1のビットストリームから発生する。
【００２２】
ビットストリームのスプライシングはビットストリームスプライサによって実行され得る。ビットストリームスプライサは、軽量であり、エンコーダよりもはるかに知的ではないことが多い。たとえば、ビットストリームスプライサは、エントロピー復号および符号化能力を備えていない場合がある。
【００２３】
ビットストリーム切替えは、適応ストリーミグ環境において使用され得る。切替え先ビットストリーム内で特定のピクチャにおいて実行されるビットストリーム切替え動作は、事実上、スプライシングポイントがビットストリームスイッチポイント、すなわち、切替え先ビットストリームからの第1のピクチャであるビットストリームスプライシング動作である。別個の表現は、それぞれのビットストリームと呼ばれる(または、それを提供する)場合もある。
【００２４】
ITU-T H.264/AVC(アドバンストビデオコーディング)または高効率ビデオコーディング(HEVC)において指定された瞬時復号リフレッシュ(IDR:Instantaneous decoding refresh)をランダムアクセスのために使用することができる。しかしながら、復号順序でIDRピクチャに続くピクチャは参照のために(ピクチャ間予測のために)IDRピクチャに先立って復号されたピクチャを使用することができないため、ランダムアクセスのためにIDRピクチャに依存するビットストリームは、かなり低いコーディング効率を有し得る。
【００２５】
コーディング効率を改善するために、クリーンランダムアクセス(CRA)ピクチャの概念がHEVCにおいて導入され、復号順序ではCRAピクチャに続くが、出力順序ではそれに先行するピクチャが、参照として、CRAピクチャの前に復号されたピクチャを使用することを可能にした。復号順序でCRAピクチャに続くが、出力順序ではCRAピクチャに先行するピクチャは、CRAピクチャに関連付けられたリーディングピクチャ(またはCRAピクチャのリーディングピクチャ)と呼ばれる。復号が現在のCRAピクチャの前にIDRピクチャまたはCRAピクチャから開始する場合、CRAピクチャのリーディングピクチャは正確に復号可能である。しかしながら、CRAピクチャからランダムアクセスが生じるとき、CRAピクチャのリーディングピクチャは復号可能でない場合がある。したがって、リーディングピクチャは、一般に、ランダムアクセス復号中に廃棄される。復号がどこで開始するかに応じて利用可能でない場合がある参照ピクチャからの誤り伝搬を防止するために、復号順序と出力順序の両方でCRAピクチャに続くすべてのピクチャは、参照として、復号順序または出力順序のいずれでもCRAピクチャに先行する(リーディングピクチャを含む)任意のピクチャを使用するべきでない。
【００２６】
CRAピクチャの導入後、CRAピクチャの概念に基づいて、切断リンクアクセス(BLA:broken link access)ピクチャの概念がHEVCにさらに導入された。BLAピクチャは、一般に、CRAピクチャの位置におけるビットストリームスプライシングから発生し、スプライスされたビットストリーム内で、スプライシングポイントCRAピクチャはBLAピクチャに変更される。
【００２７】
IDRピクチャ、CRAピクチャ、およびBLAピクチャは、集合的にランダムアクセスポイント(RAP)ピクチャと呼ばれる。IDRピクチャは、いわゆる、クローズドピクチャグループ(GOP:group of pictures)ベースのRAPに対応し、CRAピクチャおよびBLAピクチャは、通常、いわゆる、オープンピクチャグループ(GOP)ベースのRAPに対応する。
【００２８】
BLAピクチャとCRAピクチャとの間の1つの違いは次の通りである。CRAピクチャの場合、関連付けられたリーディングピクチャは、復号が復号順序でCRAピクチャの前にRAPピクチャから開始する場合、正確に復号可能であり、CRAピクチャからのランダムアクセスが生じるとき(すなわち、復号がCRAピクチャから開始するとき、または言い換えると、CRAピクチャがビットストリーム内の第1のピクチャであるとき)、正確に復号可能でない場合がある。BLAピクチャの場合、関連付けられたリーディングピクチャは、復号が復号順序でBLAピクチャの前にRAPピクチャから開始するときですら、すべての場合において復号可能でない場合がある。
【００２９】
ファイルフォーマット規格は、ISOベースのメディアファイルフォーマット(ISOBMFF, ISO/IEC 14496-12)と、MPEG-4ファイルフォーマット(ISO/IEC 14496-14)、3GPPファイルフォーマット(3GPP TS 26.244)、およびAVCファイルフォーマット(ISO/IEC 14496-15)を含めて、ISOBMFFから導出された他のメディアファイルフォーマットとを含む。
【００３０】
ISOBMFFは、AVCファイルフォーマットなど、多くのコーデックカプセル化フォーマット用の、ならびにMPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GP)、およびDVBファイルフォーマットなど、多くのマルチメディアコンテナフォーマット用の基礎として使用される。
【００３１】
オーディオおよびビデオなど、連続的なメディアに加えて、画像、ならびにメタデータなどの静的メディアをISOBMFFに準拠するファイル内に記憶することができる。ISOBMFFに従って構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、動的適応ストリーミングオーバーHTTP(DASH)のためのセグメント、ストリームされることになるコンテンツ用のコンテナおよびそのパケット化命令、ならびに受信されたリアルタイムメディアストリームの記録を含めて、多くの目的で使用され得る。
【００３２】
ボックスは、4文字のコード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む、ISOBMFF内のエレメンタリシンタックス構造である。ISOBMFFファイルは、ボックスのシーケンスからなり、ボックスは他のボックスを包含し得る。ムービーボックス(「moov」)は、各々がトラックとしてファイル内に表される、ファイル内に存在する連続的なメディアストリーム用のメタデータを包含する。トラック用のメタデータはトラックボックス(「track」)内に密閉される一方、トラックのメディアコンテンツはメディアデータボックス(「mdat」)内にまたは別個のファイル内に直接的にのいずれかで密閉される。トラック用のメディアコンテンツは、オーディオアクセスユニットまたはビデオアクセスユニットなど、サンプルのシーケンスからなる。
【００３３】
ISOBMFFは次のタイプのトラックを規定する:すなわち、エレメンタリメディアストリームを包含するメディアトラック、メディア送信命令を含むか、または受信されたパケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備えた時限メタデータトラックである。
【００３４】
当初は記憶のために設計されたが、ISOBMFFは、ストリーミングのために、たとえば、プログレッシブダウンロードまたはDASHのために、非常に貴重であることが証明されている。ストリーミングのために、ISOBMFFにおいて定義されるムービーフラグメントを使用することができる。
【００３５】
各トラック用のメタデータは、各々が、トラックにおいて使用されるコーディングフォーマットまたはカプセル化フォーマットと、そのフォーマットを処理するために必要とされる初期化データとを提供するサンプル記述エントリのリストを含む。各サンプルは、トラックのサンプル記述エントリのうちの1つに関連付けられる。
【００３６】
ISOBMFFは、様々な機構を用いてサンプル固有のメタデータの規定を有効化にする。サンプルテーブルボックス(「stbl」)内の固有のボックスは共通のニーズに応じるために規格化されている。たとえば、トラックのランダムアクセスサンプルを列挙するために、シンタックスサンプルボックス(「stss」)が使用される。サンプルグルーピング機構は、4文字グルーピングタイプによるサンプルのファイル内でサンプルグループ記述エントリとして指定された同じ属性を共有するサンプルのグループへのマッピングを有効化にする。いくつかのグルーピングタイプがISOBMFFにおいて指定されている。
【００３７】
本開示の技法は、ISOBMFF、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンストビデオコーディング(AVC)ファイルフォーマット、第3世代パートナシッププロジェクト(3GPP)ファイルフォーマット、および/もしくはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
【００３８】
ISO/IEC23001-7は、ISOベースのメディアファイルフォーマットのための共通の暗号化を定義する。この規格の場合、暗号化はエレメンタリストリームに基づく。さらに、この規格は、AES-128のCTRモードおよびCBCモードを可能にする。ランダムアクセスポイントにおいてメディアを解読するために、保護方式固有情報ならびに初期化ベクトルを含めて、すべてのDRM関連情報が必要とされる。
【００３９】
ISO/IEC 23009-1において指定される動的適応ストリーミングオーバーHTTP(DASH)は、HTTP(適応)ストリーミングアプリケーションに関する規格である。これは主に、一般に、マニフェストファイルも呼ばれるメディアプレゼンテーション記述(MPD)のフォーマット、およびメディアセグメントフォーマットを指定する。MPDは、サーバ上で利用可能なメディアを記述し、DASHクライアントにそのDASHクライアントが関心をもつメディア時間にメディアバージョンを自律的にダウンロードさせる。
【００４０】
DASHベースのHTTPストリーミングのための例示的な手順は次のステップを含む。
1)クライアントはストリーミングコンテンツ、たとえば、ムービーのMPDを取得する。MPDは、ストリーミングコンテンツの様々な代替表現、たとえば、ビットレート、ビデオ解像度、フレームレート、オーディオ言語に関する情報、ならびにHTTPリソースのURL(初期化セグメントおよびメディアセグメント)を含む。
2)MPD内の情報、およびクライアントのローカル情報、たとえば、ネットワーク帯域幅、復号/ディスプレイ能力、およびユーザの選好に基づいて、クライアントは、所望の表現を一度に1つのセグメント(または、その一部)ずつ要求する。
3)クライアントがネットワーク帯域幅変化を検出したとき、クライアントは、理想的には、ランダムアクセスポイントから開始するセグメントから開始する、より良好に一致するビットレートを有する異なる表現のセグメントを要求する。
【００４１】
HTTPストリーミング「セッション」中に、過去の位置に戻ること、または将来の位置に進むことを求めるユーザ要求に応じて、クライアントは、所望の位置に近く、理想的には、ランダムアクセスポイントから開始する過去または将来のセグメントを要求する。ユーザは、コンテンツを早送りすることを要求することもでき、これは、イントラコード化ビデオピクチャだけ、またはビデオストリームの時間サブセットだけを復号するために十分なデータを要求することによって実現可能である。
【００４２】
最後のISOBMF仕様書は、DASHとともに使用するための6つのタイプのストリームアクセスポイント(SAP)を指定している。第1の2つのSAPタイプ(タイプ1および2)は、H.264/AVCおよびHEVCにおけるIDRピクチャに対応する。第3のSAP(タイプ3)は、オープンGOPランダムアクセスポイント、したがって、HEVCにおけるBLAピクチャまたはCRAピクチャに対応する。
【００４３】
HTTPストリーミングにおいて、たとえば、DASHに従って、頻繁に使用される動作には、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技法において様々な問題が生じる。たとえば、低レイテンシライブサービスの配布など、低レイテンシビデオストリーミングサービスの場合、オリジンサーバ上で利用可能にされるように各セグメントを可能な限り迅速に生成することができることは重要である。言い換えれば、そのようなシナリオでは短いセグメントが必要である。現在、短いセグメントを作成するための2つのオプションが存在する。
1)ISOBMFFライブプロファイルの使用。これは、各セグメントは、タイプ1または2のSAPから開始しなければならないが、セグメントはすべて1つの適応セット内で同じ持続時間のものでなければならないことを意味する。言い換えれば、RAPを提供するために、IDRピクチャを使用しなければならず、SAPタイプ3に対応するオープンGOP RAPを使用することはできない。結果として、ビデオコーディング効率を損なわざるを得ない。
2)ISOBMFFメインプロファイルの使用。しかしながら、これは、スイッチポイント(SAPタイプ1または2)上で何のMPDベースのシグナリングも可能でなく、クライアントは、サンプルにどのようにアクセスするかを見出すためにそれらのセグメントをパースする必要があることを意味する。
【００５１】
さらに、セグメントオーバーローディング問題が生じ得る。すなわち、コアDASH仕様書では、セグメントは、整数のムービーフラグメントを含まなければならない配信ユニットである。一般性を失わずに、セグメントは単一のムービーフラグメントを包含すると仮定する。ムービーフラグメント自体は、復号順序で整数のサンプルを提供するという点でのみ制約を有する。
【００５２】
コアDASHでは、セグメントは、さらなる制限なしに、アドレス可能および配信可能なユニットを作成するために生成され得る。しかしながら、制限されたプロファイル(たとえば、ISOライブプロファイル)では、セグメントは同時に表現切替えを可能にするために使用され得る。後者はかなりの制限を加える。
各セグメントはクローズドGOPから開始しなければならない。
セグメントは1つの表現内のプレゼンテーション時間が重複してはならない。
【００５３】
これらの2つの制限は、特に、セグメントが比較的短い場合、コーディング効率を低減させる。
【００５４】
さらに、ブロードキャストアプリケーションの場合、配信ユニットへのランダムアクセスは重要である。セグメントの持続時間は、チャネル獲得およびチャネル変更に関連するランダムアクセス時間を決定する。ランダムアクセスの場合、より効率的なオープンGOPが十分であり、セグメントは、ある程度までプレゼンテーション時間重複すら有する場合があり、これはアクセスにおいてプレイアウト品質の低減(フレームの何らかのドロップ)をもたらし得るが、依然として、ストリームへの高速アクセスを可能にする。
【００５５】
本開示の技法は、下記で論じるように、セグメントの異なる機能的態様に対処し、セグメントを様々なクラスに区分することができる。
【００５６】
図1は、ストリームに迅速に加わるための例示的な使用事例を示す概念図である。この例では、いくつかのセグメントはブロードキャストを介して利用可能である一方、他のセグメントはユニキャストを介して利用可能である。具体的には、ラベル「8」および「9」と標示されたセグメントはブロードキャストを介して利用可能である一方、7A〜7D、8A〜8D、および9A〜9Dと標示されたセグメントはユニキャストを介して利用可能である。この使用事例では、クライアントデバイスは、ユニキャストを介してセグメント7Dおよび8A〜8Dを取り出し(ここで、セグメント8A〜8Dはブロードキャストを介して利用可能なセグメント8と同じメディアデータを含む)、次いで、ブロードキャストを介してセグメント9を取り出す。具体的には、クライアントデバイスは、ブロードキャストを介したセグメント8の送信中である同調時間2においてブロードキャストに同調する。したがって、クライアントデバイスは、ブロードキャストを介してセグメント8を受信することができず、代わりに、クライアントデバイスは、ブロードキャストを介してセグメント9を受信する前に、セグメント7Dおよび8A〜8Dを取り出す。したがって、クライアントデバイスは、セグメント8Dを取り出した後で、ブロードキャストからユニキャストに切り替える。したがって、メディアデータをプレイアウトするとき、クライアントデバイスは、(ユニキャストを介して受信された)セグメント7Dおよび8A〜8Dからメディアデータをプレイアウトし、次いで、(ブロードキャストを介して受信された)セグメント9からプレイアウトするように切り替える。
【００５７】
この使用事例は、ユニキャストとの「高速同調」を実証する。この場合、サービスプロバイダは、迅速にアクセスするために、高SAP周波数(典型的には、タイプ3が可能である)を有する1つの表現を配布することを望む。しかしながら、同調の後で、クライアントは、より効率的であり、IDRフレームがより少ない表現に切り替えることを望む。切替え先表現は異なるセグメントサイズを有することすら可能である。このシナリオは、ユニキャストにおける事例であってよいが、ハイブリッド事例であってもよい。このシナリオを図1に示す。この図では、より短いセグメントはユニキャストを介して可能にされ、各セグメントはIDRフレームを含む。クライアントがある時間にユニキャストサポートなしにプログラムに加わる場合、セグメントが受信され、再生が開始され得るまである程度の時間がかかることになる(図1のセグメント9)。これは、(たとえば、セグメントのメディアデータを復号するためのメディアデコーダを適切に初期化するために)セグメント全体が受信される必要があることによる。
【００５８】
この場合、ユニキャスト表現は、セグメント持続時間の4分の1で提供される。クライアントは、効率的な(長いセグメント、長いIDRフレーム距離)ブロードキャスト表現がブロードキャストを介して到着するまで、ユニキャスト短セグメントをプレイアウトすることを速やかに選ぶことができる。MPDにおけるこれらの能力(ランダムアクセスポイントおよびスイッチポイントの位置)のシグナリングは重要であるが、今日、不可能である。
【００５９】
別の同様の使用事例は、SHVCとの高速同調に関連する。低RAP周波数およびさらに小さなセグメントサイズを有するベースレイヤ、ならびにより大きなGOP周波数を有するエンハンスメントレイヤの提供が存在し得る。その場合、図1に関して論じるのと同じことを実現することができる。これらの特徴をシグナリングすることは、今日、不可能である。
【００６０】
別の望ましい使用事例は、効果的な時間シフトバッファの使用である。場合によっては、表現は、小さなセグメントを有するライブエッジにおいて提供され得るが、クライアントが時間シフトバッファに移動するとすぐに、そのセグメントサイズは増大する。表現は依然としてシームレスな切替え能力を表すための1つの適応セットの形であり得るが、これらの表現は、同じセグメントサイズおよび/または同じスイッチポイント/ランダムアクセスポイント周波数を有することを強制されるべきではない。同じことは、将来のオンデマンド使用のためのライブイベントの記録にも当てはまる。
【００６１】
別の使用事例は、オープンGOPとの高速同調に関連する。オープンGOPは、一般に、GOPの外部のピクチャに対して予測され得るピクチャを含むGOPに対応し得る。これは、GOPのすべてのピクチャがGOP内の他のピクチャから予測される自己完結型であるクローズドGOPと対照的である。たとえば、オープンGOPはインター予測されたピクチャ(または、インター予測されたキーフレーム)から開始し得るが、クローズドGOPはイントラ予測されたピクチャから開始し得る。
【００６２】
オープンGOPとの高速同調の事例は、ブロードキャスト高速同調に関する典型的な事例であり得る。問題は、迅速に同調し、表現にわたって切り替え、場合によっては、低レイテンシを提供することを望む場合が存在することである。これは、シグナリング、すなわち、セグメント、オープンGOP、クローズドGOP、セグメントアラインメントなどのシグナリングに関して複雑な使用事例を生じ得る。
【００６３】
別の使用事例は、連続性のための高速スイッチダウン(switch down)に関連する。この事例はまた、ブロードキャスト高速同調シナリオに関して一般的であり得る。問題は、迅速に同調し、表現にわたって切り替え、場合によっては、低レイテンシを提供することを望む場合が存在することである。これは、シグナリング、すなわち、セグメント、オープンGOP、クローズドGOP、セグメントアラインメントなどのシグナリングに関して複雑な使用事例をも生じ得る。
【００６４】
別の使用事例は、セグメント可用性に関連する。レイテンシを低減するために、セグメントは短い必要があるだけでなく、セグメントの生成と公開との間の時間も短い必要がある。HTTP404エラーを回避するために、セグメント可用性時間が受信機に利用可能にされる(たとえば、シグナリングされる)必要がある。セグメントテンプレートは可用性時間を告知するためのパターンを提供するが、これは、セグメントが正確な時間に利用可能であることを必要とし、したがって、セグメント可用性開始時間を告知するとき、セグメント持続時間における変化を考慮に入れる必要があり、エンコーダはこのパターンに従う必要がある。コンテンツプロバイダがセグメント可用性時間にIDRフレームを生成することを強制される場合、それは、IDRフレーム配置をより容易に変化させることができ、セグメント可用性時間はより正確に告知され得る。この態様は、セグメントシグナリング持続時間において考慮されるべきである。
【００６５】
様々な使用事例において、切替え、配信、およびランダムアクセスの様々な特徴の関連性はより高いか、または低いが、これらの特徴は1つのコンテンツ提供内で提供される必要があり得る。考慮されるべきいくつかのシナリオが存在する。
より低い周波数においてユニキャスト表現に切り替える能力とともに、低チャネル獲得時間を用いたブロードキャスト配布の展開。
ブロードキャストと同期するユニキャストを介したライブエッジにおける低レイテンシバージョンの配信。
配信ユニットよりも長いランダムアクセル周波数だけを用いたブロードキャストを介した低レイテンシバージョンの配信。
考慮する必要がある様々なセグメント持続時間。
【００６６】
本開示の技法は、これらの様々な使用事例を、単独で、または任意の組合せで可能にすることができ、上記で論じた問題のうちのいずれかまたはすべてを克服することができる。
【００６７】
図2は、様々なタイプのメディアセグメント同士の間の関係を示すベン図200である。メディアセグメントは、次のように、DASHにおいて様々な目的のうちのいずれかまたはすべてに関して使用され得る。
表現切替え
クローズドGOPが一般に必要である。
セグメントは1つの表現内で時間的に重複してはならない。
セグメントは1つの適応セット内の異なる表現にわたって整合されなければならない。
ランダムアクセス
オープンGOPが一般に必要である。
オープンGOPランダムアクセスが許可される場合、セグメントは1つの表現内で時間的に重複してよい。
配信ユニット
ランダムアクセスまたは切替えに関して何の要件もない。
セグメントは整数のムービーセグメントを含まなければならない。
【００６８】
様々な態様に対処するために、図2に従って、4つの異なるセグメントタイプ(または、フォーマット)を考慮することができる。
配信ユニットセグメントフォーマット202:何の制約もないフラグメントのみ。(図2において実線の輪郭を用いて楕円によって表現されている)。
ランダムアクセスセグメントフォーマット204:同調のためのオープンGOP。(図2において破線の輪郭を用いて楕円によって表現されている)。
非重複セグメントフォーマット206:クライアントデバイスは、何の問題もなしに、このフォーマットのセグメントに切り替えることができる。(図2において点線の輪郭を用いて楕円によって表現されている)。
切り替えセグメントフォーマット208:クライアントデバイスは、このフォーマットのセグメントに切り替えることができる。(図2において二重点線の輪郭を用いて楕円によって表現されている)。
【００６９】
図3は、表現210およびISO BMFFファイル212A〜212Cの例示的な構造を示す概念図である。図3はまた、(ムービーフラグメント)ボックスとムービーデータ(mdat)ボックスとを含む、ISO BMFFファイル212Aの分解図を示す。図3の例示的なISO BMFFファイル212Aは、下でより詳細に説明する、図6のムービーフラグメント164に概念的に類似する。ムービーフラグメントはメディアデータのための配信ユニットであると考えることが重要である。ムービーフラグメントは、たとえば、図3に示すように、それらのムービーフラグメントがmoofボックスおよびmdatボックスのシーケンスを包含するように生成される。
【００７０】
図4は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてもよく、または直接通信可能に結合されてもよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
【００７１】
図4の例では、コンテンツ準備デバイス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ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを決定することができる。
【００８０】
図4の例では、コンテンツ準備デバイス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ユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(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:Supplemental Enhancement Information)は、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に送ることができる。図4の例では、サーバデバイス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などの加入側クライアントデバイスに向けさせることができる。
【００９１】
図4の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、品質が異なるビデオサービス)の記述を包含してよく、この記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を包含し得る。クライアントデバイス40は、メディアプレゼンテーションの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は、ブロードキャスト、またはeMBMSまたはIPマルチキャストなどのマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば、再生を中断すること、または異なるマルチキャストグループにチャネルを変えることを求める要求を提出することができる。
【００９６】
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に、取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かまたはビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送ることができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送信する一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号ビデオデータをビデオ出力44に送信する。
【００９７】
本開示の技法によれば、マニフェストファイル66は、(本明細書において、セグメントのタイプとも呼ばれる)セグメントが準拠し得る様々なセグメントフォーマットをシグナリングすることができる。マニフェストファイル66は、各フォーマットに準拠するセグメントのロケーション(すなわち、セグメントの様々なタイプの各々のロケーション)をシグナリングすることもできる。たとえば、マニフェストファイル66は、セグメントの様々なタイプの各々が表現68の各々の中で生じる周波数をシグナリングする。
【００９８】
マニフェストファイル66を使用して、クライアントデバイス40は、メディアデータの低レイテンシ再生を実現することができる。たとえば、表現68のうちの1つ(たとえば、表現68A)は、マニフェストファイル66によって示されるように、比較的高い周波数のSAPを含むことができ、表現68の別の表現(たとえば、表現68N)は、比較的低い周波数のSAPを含むことができる。具体的には、SAPは特定のフォーマット、たとえば、ランダムアクセスメディアセグメントフォーマットおよび/または切替えメディアセグメントフォーマットに準拠するセグメントの部分を形成することができる。さらに、表現68は、異なる送信サービスを介した取出しのために利用可能であり得る。たとえば、表現68Aはユニキャストを介して利用可能であり得る一方、表現68Nはブロードキャストを介して利用可能であり得る。
【００９９】
本開示の技法のいくつかの例によれば、クライアントデバイス40は、上記の例によれば、表現68Aが、マニフェストファイル66によって示されるように、比較的高い周波数のSAP(たとえば、非常に高い周波数のランダムアクセスメディアセグメントおよび/または非常高い周波数の切替えメディアセグメント)を示すと決定することができる。さらに、クライアントデバイス40は、表現68Nが、比較的低い周波数のSAPを含むが、比較的高い品質も含むと決定することができる。したがって、メディアデータ取出しを開始するために、クライアントデバイス40は、クライアントデバイス40が、マニフェストファイル66によって示されるように、たとえば、68Nのランダムアクセスメディアセグメントまたは切替えメディアセグメントにおいて、クライアントデバイス40が表現68Nに切り替えることができるまで、表現68Aからメディアセグメントを取り出すことによって開始することができる。これらの技法の例を説明する様々な詳細な使用事例について、たとえば、図7〜図14に関して下記で説明する。
【０１００】
ビデオエンコーダ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に送る。
【０１０９】
本開示の技法によれば、コンテンツ準備デバイス20、サーバデバイス60、および/またはクライアントデバイス40のうちのいずれかまたはすべては、新しいDASHプロファイル(たとえば、アドバンストライブプロファイル)に従って、メディアデータを定義、シグナリング、および/または処理するための様々な方法を実行するように構成され得る。同様に、これらのデバイスのうちのいずれかまたはすべては、同時に高効率ビデオコーディング構造を有効化しながら、ブロードキャストおよびマルチキャストにおける低減されたチャネル変更時間を含めて、レイテンシビデオストリーミングを有効化し得る新しいタイプのメディアセグメントを処理するように構成され得る。一般に、単独で、または任意の組合せで実行され得る次の態様について論じる。
様々なメディアセグメントタイプおよびその構造の定義。
現在の属性の検討。
ソリューション考慮。
MPDシグナリング。
セグメント内のタイプのシグナリング。
MPD内のタイプのシグナリング。
様々な使用事例に関する適応セットの有効化。
【０１１０】
いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40は、次のフォーマットのうちのいずれかに準拠するメディアセグメントを利用するように構成され得る。すなわち、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、および/または切替えメディアセグメントフォーマットである。これらのフォーマットについて、下記でより詳細に説明する。
【０１１１】
配信ユニットメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る:
各メディアセグメントは、1つまたは複数の自己完結型ムービーフラグメントを含むべきである。自己完結型ムービーフラグメント全体はムービーフラグメント(「moof」)ボックスであり、トラックによって参照される外部データ参照を使用しないすべてのメディアサンプルを含むメディアデータ(「mdat」)ボックスはムービーフラグメントボックス内で実行する。
各「moof」ボックスは少なくとも1つのトラックフラグメントを包含すべきである。
「moof」ボックスは外部データ参照を使用すべきではなく、フラグ「default-base-is-moof」が設定されるべきであり、データオフセットが使用されるべき、すなわち、「base-data-offset-present」は使用されるべきではない。設定のこの組合せは、メディアデータに関するムービーフラグメント相対アドレッシングと呼ばれる場合がある。
各メディアセグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「dums」を搬送することができる。このブランドの準拠要件は本開示において定義される通りであり得る。
【０１１２】
ランダムアクセスメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義される:
メディアセグメントは、上記で指定したように、配信ユニットメディアセグメントフォーマットに準拠すべきである。
ランダムアクセスメディアセグメント内の各ムービーフラグメント内の第1のアクセスユニットは、(たとえば、IDRピクチャ、CRAピクチャ、またはBLAピクチャを含む)タイプ1、2、または3のSAPのISAUに対応すべきである。
メディアセグメントは、ストリーム内のメディアにアクセスするために十分な情報、たとえば、利用可能な場合、初期化セグメントとの組合せですべての必要な暗号を搬送すべきである。
各「traf」ボックス(トラックフラグメントボックス)は「tfdt」ボックス(トラックフラグメント復号時間ボックス)を含むべきである。
各メディアセグメントは、互換性のあるブランドとして、セグメントタイプボックス(「styp」)内で「rams」を搬送することができる。このブランドの準拠要件は本下位条項において定義される通りである。
各メディアセグメントは、1つまたは複数の「sidx」ボックスを含み得る。存在する場合、第1の「sidx」ボックスはいずれの「moof」ボックスの前に配置されるべきであり、第1のセグメントインデックスボックスはセグメント全体を文書化すべきである。
【０１１３】
重複なしセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る:
メディアセグメントは、上記で指定したように、配信ユニットメディアセグメントフォーマットに準拠すべきである。
セグメントおよびその先行するセグメントは非重複属性を満たすという意味で、セグメントはISO/IEC23009-1の4.5.3において定義されるように非重複属性を満たすべきである。
【０１１４】
切替えメディアセグメントフォーマットに準拠するメディアセグメントは次のように定義され得る。
メディアセグメントは、上記で指定したように、ランダムアクセスメディアセグメントフォーマットに準拠すべきである。
切替えメディアセグメント内の第1のムービーフラグメント内の第1のサンプルは、タイプ1または2のSAPのISAUに対応すべきである(たとえば、IDRピクチャ)。
各メディアセグメントは、互換性があるブランドとして、セグメントタイプボックス内で「swms」を搬送する。このブランドの準拠要件は本下位条項において定義される通りである。
【０１１５】
様々なフォーマットのセグメントが異なる機能を実行し得る。たとえば、配信ユニットメディアセグメントは、一般に、メディアデータを配信する機能を実行する。別のデータとして、ランダムアクセスメディアセグメントは、ランダムアクセスメディアセグメントを含む表現に(初期化データを含む)ランダムアクセスポイントを提供する機能を実行する。重複なしセグメントは、単純な表現切替えを有効化し得る、表現同士の間のセグメントアラインメントを示す機能を実行し得る。切替えメディアセグメントは、ランダムアクセスメディアセグメントに関して必要とされることになる余分な初期化データを含まずに、表現切替えを可能にする機能を実現する。
【０１１６】
さらに、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40は、上記で論じたフォーマットを表すデータおよび/または、たとえば、マニフェストファイル66内の、本開示の技法による他のデータ(MPDなど)を処理するように構成され得る。次の特徴は、単独で、または何らかの組合せで、マニフェストファイル66内でシグナリングされ得る。
明示的にシグナリングされるか、またはパターンを通してシグナリングされる、表現内の各メディアセグメントのタイプ。
1つの適応セット内に異なるセグメントサイズを有するが、依然として、整合された切替えポイントを有する能力、すなわち、切替えメディアセグメントは同時に開始する。
minBufferTimeおよび帯域幅の計算に関する結果(ランダムアクセスポイントから開始すべき)。
【０１１７】
表現68の各々に関して、かつ場合によっては、デフォルト設定された適応セットレベルにおいて、以下がマニフェストファイル66内でシグナリングされ得る。
表現内のパターン。
すべてのセグメントは配信ユニットメディアタイプのセグメントのものであり、すべてのN番目のセグメントはランダムアクセスメディアセグメントであり、すべてのM番目のセグメントはM>=Nである切替えセグメントである。一部の省略およびデフォルトは実行可能であり得る。
これは新しい属性、rams-frequencyおよびswmg-frequencyを用いてシグナリングされ得る。
MPDを更新せずにパターンの表現を可能にする他の省略パターン。
タイムラインセグメント内のパターン
各要素に関するタイムラインセグメント内のオプションのタイプフィールドの追加。
セグメントタイプ。
タイプフィールドはまた上記のパターンのようにパターンを表すこともできる。
タイムラインセグメント内のS要素の更新に伴う不規則性のシグナリングを有効化する。
明示的
場合によっては、いくつかのパターンを交互させて、明示的なリスト内でセグメントパターンをシグナリングすることを可能にするフィールドを追加する。
これはセグメント持続時間のシグナリングも含み得る。
【０１１８】
共通の適応セット内の表現は異なるセグメント持続時間を有することが可能であり得る。しかしながら、切替えに関する問題は、シームレスな切替えを有効化するために、表現にわたる切替えポイントがシグナリングされる必要があるということである。切替えポイントの位置は上記で論じたようにシグナリングされ得る。以下のシグナリングを考慮することもできる。
すべての表現は同じ位置に切替えポイントを有し、すべての表現は整合される。これは単一のフラグを用いてシグナリングされ得る。
切替えポイントが特定の時間(この場合、複雑であり得るMPD時間)にシグナリングされるとき、これは、表現内のすべての他の切替えポイントに整合される。これはまた、単一のフラグを用いてシグナリング可能であり、上記で論じたのと同じフラグを使用することができる。
いくつかの例では、続く切替えメディアセグメントが存在しない場合ですら、クライアントデバイス40が重複なしポイントから切替えメディアセグメントに切り替えることができるように、依然として重複は存在しない。
切替えポイントの他のより明示的なシグナリングをマニフェストファイル66内でさらにシグナリングすることができる。
【０１１９】
上述のように、いくつかの例では、コンテンツ準備デバイス20、サーバデバイス60、および/またはクライアントデバイス40は、DASHのアドバンストライブプロファイルを利用するように構成され得る。アドバンストライブプロファイルは、上記で定義されたすべての特徴およびセグメント「タイプ」を含み得る。アドバンストライブプロファイルは、ユニフォームリソースネーム(URN)「"urn:mpeg:dash:profile:advanced-live:2015」によって特定され得る。
【０１２０】
いくつかの例では、適応セット内でアドバンストライブプロファイルが使用される場合:
すべての切替えメディアセグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「swms」を搬送すべきである。
「swms」を搬送しないすべての「ランダムアクセスメディア」セグメントは、互換性があるブランドとして、セグメントタイプボックス(「styp」)内で「rams」を搬送すべきである。
【０１２１】
本開示は、MPD属性に関する従来のシグナリングに関する次の問題および限界を認識する:
1.セグメント可用性時間のシグナリング
@durationまたはセグメントタイムラインのいずれか:
提案は、新しいプロファイル内で簡素化し、この目的でセグメントタイムラインだけを使用するが、これは、セグメントタイムラインは@durationのスーパーセットであるためである。
しかしながら、セグメントタイムラインは例外を認めるため、セグメントタイムラインはより複雑である。
セグメントライムライン内の時間が正確なセグメント持続時間であるか(コンテンツオーサリングにおいてより低いフレキシビリティを許可するか)またはドリフトフリー(drift-free)持続時間であり、セグメント可用性時間だけをシグナリングするかどうかを明らかにする必要もある。
@timecaleの適切な適用によって、この問題を解決することができることに留意することが重要である。
2.属性、すなわち、重複なしからの切替えのシグナリング
セグメントアラインメントが適応セット内で真に設定されていることによる。
問題は、これは各セグメントが同じ持続時間を有する必要があることである。
重複なしは、より蜜な粒度で表される必要がある。
3.ランダムアクセスのシグナリング
SAPを1、2、または3に設定することから開始する:
問題は、これはあまり明示的に示されないことである。
他の要件も設定されなければならない。ランダムアクセスセグメントの拡張された定義を参照。
4.切替えポイントのシグナリング。
SAPを1または2に設定することから開始する:
問題は、これはあまり明示的に示されないことである。
他のタイプの切替えを適用することができるが、これはさらなる考えを必要とする。何らかのフレキシビリティを追加すべきである。
5.セグメントURLのシグナリング
数ベースのテンプレート
問題は基本的に、各セグメントが各適応セット内の各表現内に同じ数を有するという仮定が存在することである。これは要件ではないが、実装において仮定される可能性が高いことに留意されたい。1つの適応セット内で異なるサイズのセグメントを有するように変更する場合、番号付けの対応はもはや存在しない。
差し当たり、簡素化するために、番号を使用しない。
時間ベースのテンプレート
問題は基本的に、各セグメントが各適応セット内の各表現内に同じ時間を有するという仮定が存在することである。これは要件ではないが、実装において仮定される可能性が高いことに留意されたい。
しかしながら、これは共通のタイムラインに関して表され得ることにも留意されたい。さらに、異なる表現にわたる関係を表すために、タイムラインは番号付けよりも適切である。
「セグメント」のリスト
問題は、ここで、リスト位置はセグメントに整合し、これはネーミングが任意である場合に当てはまる可能性があることである。クライアントは、適応セット内の各表現のリストの正確なマッピングおよび順序を維持する必要がある。
【０１２２】
異なる部分を割り当てるために本開示の技法が必要とされる。サーバデバイス60およびクライアントデバイス40は、いくつかの例において、次の手法に従って構成され得る。
持続時間/セグメントタイムラインは配信ユニットに割り当てられるが、これは、セグメントがサーバにおいて利用可能であるとき、持続時間/セグメントタイムラインは時間を表すためである。
時間は、メディア時間の点で正確でない可能性があるが、セグメント可用性開始時間を計算するために使用される。
このタイミングは1つの適応セット内の異なる表現に対して異なり得る。たとえば、他の表現よりもより多くの配信ユニットを有する、利用可能な「表現」が存在し得る。使用事例の議論を参照されたい。
上記の信号に基づいてセグメント可用性開始時間をどのように計算するかに関する明瞭な命令が必要とされる。既存のモデルは効果的であるが、本開示の技法に従ってセグメント可用性開始時間の計算について既存のモデルが使用される場合、その実務家は既存のモデルを適切に使用することが確実であるべきである。
これは、セグメント可用性時間はいくつかの表現に関して調整され得るか、または可用性時間オフセットによってbaseURLに関して調整され得ることを含む。
明瞭にすべきもう1つの重要な問題は、セグメント持続時間が可用性開始時間およびシグナリングに与える影響がどの程度不規則であるかである。一般に、セグメントは同じサイズのものであるべきである。
ランダムアクセスは異なる表現内で異なり得る。
ランダムアクセスがセグメントの開始時においてだけタイミングワイズ(timing wise)であるか、またはランダムアクセスがやはりセグメントの中央にあるかを明らかにする必要がある。
4.2.2.によれば、これは、現在、セグメントの開始にあるが、ランダムアクセスポイントが不規則に配置される場合、これは不規則なセグメントをもたらし得る。
セグメント可用性の予測可能性は低いため、これはレイテンシにも影響を及ぼす。
しかしながら、作業仮説として、「ランダムアクセス」はセグメントの開始時であるという4.2.2モデルを維持すべきである。
「ランダムアクセス」は、2つの領域、すなわち、時間、またはセグメント番号付けにおいてシグナリングされ得る。
一般的なツールに達するために、時間ベースの手法を使用することができる。
核心となる実験において、少なくとも2つの切替え手法が論じられた。
ビットストリーム切替え:
DASHクライアントは、表現の内部構造に気づかない。DASHクライアントは、表現をどこでスプライスできるかを単に知っており、これを単一のビットストリームとしてメディアデコーダに供給する。エンコーダは、この属性がカプセル化およびメディアストリームレベルで満たされるように、表現が符号化されることを確実にする。
これは、基本的に、クライアントが次のようにシーケンス/ビットストリームを作成することを許可することになる:
適応セットに関する初期化セグメント
表現1のメディアセグメント1
...
表現1のメディアセグメントX
表現2のメディアセグメントX+1
...
切替えは、メディア内の特定の属性によって有効化される。これはDASHにおいて行われたことである。切替えがファイルプレイアウトレベルにおいてどのように行われ得るかについて何らかの規則が作成された。基本的な規則は、当然、セグメントアラインメントが真に設定され、SAPからの開始が1または2である場合、次のシーケンスがシームレスな切替えを実現することである:
初期化セグメント表現1
表現1のメディアセグメント1
...
表現1のメディアセグメントX
初期化セグメント表現2
表現2のメディアセグメントX+1
...
オープンGOPにおける切替え、またはメディア処理のより詳細な理解を必要とする他の態様。
【０１２３】
上記の議論に基づいて、マニフェストファイル66(たとえば、MPD)に拡張および制限を適用することができ、拡張および制限は新しいツールに適用され得る。たとえば、次の拡張を、単独で、または何らかの組合せで適用することができる。
表現レベルで@timescaleの規模で表される新しい属性@randomAccessPeriod(または、ランダムアクセス期間を表すための何らかの他の手段)を追加する。$Time$が@timescaleおよび@randomAccessPeriodの積の整数倍になる任意のセグメントは、ランダムアクセスセグメントであり、すなわち、これは、この表現の適応セットへのアクセスを許可する。
ランダムアクセスをさらに条件付けることができる。たとえば、何の期間に何のSAPタイプ、すなわち、SAPタイプ1、2、または3が利用可能であるか。3は受けたSAPタイプはまた1または2であり得ることを意味することに留意されたい。
適応セットレベル(1つまたは複数が存在し得る)に関する2つの属性を有する新しい切替えメディアセグメント要素(または、切替えを表すための何らかの他の手段)を追加する。
@timescaleの尺度での@period表現。$Time$が@timescaleとの積の整数倍になる任意の時間位置は、切替え機会を提供し、すなわち、これはこの表現への切替えを許可する。
切替えのタイプを表す@typeが有効化される。少なくとも2つのタイプ、すなわち、ビットストリーム切替えおよびメディアレベル切替えが定義され得る。オープンGOP切替えなど、他のタイプが定義され得る。
そのような切替えを表す別の方法は、記述子を使用することであり、記述子は、切替えのタイプおよび切替え周波数の値を表す。
セグメントタイムラインおよびS要素において、デフォルト設定によって偽に設定する追加の属性@resetを提供する。リセットは、ランダムアクセス期間および切替え期間の周期性がこの時点でリセットされることを意味する。これは、IDRが追加され、セグメントタイムラインが基本的により任意の時間にリセットされることを可能にする。
【０１２４】
上記のシナリオは、セグメントテンプレートが上記で論じたセグメント可用性を提供する使用事例を必ずしもサポートするとは限らない。やはりこの使用事例に対処するために、次の拡張を追加することができる。
表現レベル(1つまたは複数が存在し得る)に関する2つの属性を有する新しい切替え要素(または、切替えを表すための何らかの他の手段または要素)を追加する:
@timescaleの尺度での@period表現。$Time$が@timescaleとの積の整数倍になる任意の時間位置は、切替え機会を提供し、すなわち、これはこの表現への切替えを許可する。
切替えのタイプを表す@typeが有効化される。少なくとも2つのタイプ、すなわち、ビットストリーム切替えおよびメディアレベル切替えが定義され得る。オープンGOP切替えなど、他のタイプが定義され得る。
【０１２５】
より高度な使用事例を有効化するために、アドバンストライブプロファイルに次の制限を適用することが提案される。
1つの適応セット内のすべての表現に関して単一の@timescaleを使用する。
(簡単のために)セグメント持続時間のシグナリングのためにセグメントタイムラインを使用する。
(簡単のために)URLのシグナリングのために$Time$だけを使用する。
セグメント持続時間に関するタイミングは正確である(作業仮定、その結果を理解する必要がある)。
セグメント持続時間の精度は、使用中の@timescaleによって制御可能であり(留意)、たとえば、タイムスケールが実際のサンプリングレートの1/5だけである場合、正確なサンプリングレートに関して何らかのフレキシビリティを有する。
異なる表現内の異なるセグメント持続時間を可能にするために、セグメントタイムラインは表現単位である。しかしながら、セグメントタイムラインは適応セットレベルにおいてデフォルトであり得る。
セグメントタイムラインは、終端開放型@r(-1)または閉鎖型@r(>=0)を使用することができる。
セグメントアラインメントおよびSAPからの開始は、後方互換性の開発に関して使用され得るが、一般に、使用すべきではない。シグナリングは常に@randomAccess Periodおよび切替え要素によって提供されなければならない。
適応セットが2つ以上の「表現」を含む場合、適応セットレベルの表現に関して切替え論理が提供されることを確実にする必要がある。
【０１２６】
DASHに関して主に説明するが、本開示の技法は、MPEG-2 TS(トランスポートストリーム)、またはWebMなど、他のメディアフォーマットのために使用されてもよい。
【０１２７】
このようにして、クライアントデバイス40は、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、または切替えメディアセグメントフォーマットのうちの少なくとも1つに準拠するメディアセグメントを取り出し、メディアセグメントが配信ユニットメディアセグメントフォーマットに準拠するか、ランダムアクセスメディアセグメントフォーマットに準拠するか、重複なしセグメントフォーマットに準拠するか、または切替えメディアセグメントフォーマットに準拠するかに少なくとも部分的に基づいて、メディアセグメントを処理するように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
【０１２８】
クライアントデバイス40はまた、表現内の様々なタイプのメディアセグメントに関するパターンを示すデータを含むマニフェストファイルを受信し、そのパターンに少なくとも部分的に基づいて、メディアセグメントのうちの1つまたは複数を取り出すように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
【０１２９】
さらに、クライアントデバイス40は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定することと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定することと、決定されたセグメントをその表現から取り出すこととを行うように構成された1つまたは複数のプロセッサを備えるメディアデータを取り出すためのデバイスの一例を表す。
【０１３０】
同様に、サーバデバイス60およびコンテンツ準備デバイス20は、配信ユニットメディアセグメントフォーマット、ランダムアクセスメディアセグメントフォーマット、重複なしセグメントフォーマット、または切替えメディアセグメントフォーマットのうちの少なくとも1つに準拠するメディアセグメントを形成し、メディアセグメントをクライアントデバイスに送るように構成された1つまたは複数のプロセッサを備えるメディアデータを送るためのデバイスの例を表す。
【０１３１】
サーバデバイス60またはコンテンツ準備デバイス20はまた、表現内の様々なタイプのメディアセグメントに関するパターンを示すデータを含むマニフェストファイルをクライアントデバイスに送り、1つまたは複数の要求に応じて、そのパターンに少なくとも部分的に基づいて、メディアセグメントのうちの1つまたは複数をクライアントデバイスに送るように構成された1つまたは複数のプロセッサを備えるメディアデータを送るためのデバイスの例を表す。
【０１３２】
サーバデバイス60およびコンテンツ準備デバイス20は、メディア情報をシグナリングするためのデバイスであって、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築することであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築することと、そのマニフェストファイルをクライアントデバイスに送ることと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送ることと行うように構成された1つまたは複数のプロセッサを含むデバイスの例を表す。
【０１３３】
図5Aは、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図4)、または記憶媒体62内に記憶された別のマルチメディアコンテンツに対応し得る。図5Aの例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104と複数の表現110A〜110N(表現110)とを含む。表現110Aは、任意のヘッダデータ112とセグメント114A〜114N(セグメント114)とを含む一方、表現110Nは、任意のヘッダデータ122とセグメント124A〜124N(セグメント124)とを含む。文字Nが、便宜的に、表現110の各々の最後のムービーフラグメントを指定するために使用される。いくつかの例では、表現110同士の間で異なる数のムービーフラグメントが存在し得る。
【０１３４】
MPD104は、表現110とは別個のデータ構造を含んでもよい。MPD104は、図4のマニフェストファイル66に対応し得る。同様に、表現110は、図4の表現68に対応し得る。一般に、MPD104は、コーディングおよびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を`検索するための情報(たとえば、再生中のメディアコンテンツへのターゲティング広告の挿入)のような、表現110の特性を一般に記述するデータを含んでもよい。
【０１３５】
ヘッダデータ112は、存在するとき、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在のロケーション、セグメント114のうちのどれがランダムアクセスポイントを含むのか、セグメント114内のランダムアクセスポイントへのバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の態様を記述し得る。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を記述することができる。追加または代替として、そのような特性はMPD104内に完全に含まれ得る。
【０１３６】
セグメント114、124は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。MPD104のデータは、図5Aの例には示されていないが、そのような特性は、MPD104のデータによって記述され得る。MPD104は、本開示で説明するシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
【０１３７】
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)と関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
【０１３８】
図5Bは、本開示の技法による、メディアプレゼンテーション記述(MPD)104の例示的なコンテンツを示す概念図である。一般に、MPD104内でシグナリングされるデータの中でも、図5Bの例では、MPD104は、期間情報130と、適応セット情報132と、表現情報134A〜134N(表現情報134)とを含む。適応セット情報132の単一のセットだけがこの例に示されるが、一般に、適応セット情報の複数のセットが含まれてよいことを理解されたい。同様に、期間情報130の単一のセットだけがこの例に示されるが、一般に、期間情報の複数のセットが含まれてよいことを理解されたい。
【０１３９】
本開示の技法によれば、表現情報134Aは、セグメントタイプ情報136Aと、セグメント機能情報138Aと、セグメントロケーション140Aとを含む。同様に、表現情報134Nは、セグメントタイプ情報136Nと、セグメント機能情報138Nと、セグメントロケーション140Nとを含む。一般に、セグメントタイプ情報136A、136Nは、それぞれ、表現情報134A、134Nに対応する表現内に含まれたセグメントの様々なタイプを記述する。たとえば、セグメントタイプ136A、136Nは、配信ユニットメディアセグメントタイプ(または、フォーマット)、ランダムアクセスメディアセグメントタイプ(または、フォーマット)、重複なしセグメントタイプ(または、フォーマット)、および切替えメディアセグメントタイプ(または、フォーマット)のうちのいずれかまたはすべてを含み得る。
【０１４０】
セグメント機能情報138A、138Nは、一般に、様々なセグメントタイプによって実行される機能を記述する。たとえば、対応するセグメントタイプ情報136A、136Nに配信ユニットメディアセグメントタイプ(または、フォーマット)、ランダムアクセスメディアセグメントタイプ(または、フォーマット)、重複なしセグメントタイプ(または、フォーマット)、および切替えメディアセグメントタイプ(または、フォーマット)が存在すると仮定すると、セグメント機能情報138A、138Nは、それらのタイプ/フォーマットのうちのいずれかまたはすべてによって実行される機能を記述し得る。セグメント機能情報138A、138Nは、配信ユニットメディアセグメントタイプが一般にメディアデータを搬送するために使用され、ランダムアクセスメディアセグメントタイプが(初期化情報を含む)ランダムアクセスポイントを提供するために使用され、重複なしセグメントタイプが、そのようなセグメントが同じ表現または他の表現の他のセグメントに重複しないことを示し、切替えメディアセグメントタイプが適応セット内の表現同士の間の切替えを可能にすることを示し得る。
【０１４１】
セグメントロケーション情報140A、140Nは、一般に、対応する表現内の様々なタイプのセグメントのロケーション(または、位置)をシグナリングすることができる。たとえば、セグメントロケーション情報140A、140Nは、配信ユニットメディアセグメントタイプ、ランダムアクセスメディアセグメントタイプ、重複なしセグメントタイプ、および/または切替えメディアセグメントタイプの各々内のセグメントが対応する表現内で生じる周波数をシグナリングすることができる。セグメントロケーション情報140A、140Nは、そのような情報をパターンの形態で(たとえば、第N番目ごとのセグメントがタイプXのセグメントであることを)示し得る。追加または代替として、セグメントロケーション情報140A、140Nは、個々のセグメントのロケーションを明示的に列挙することができる。
【０１４２】
図6は、図5Aのセグメント114、124のうちの1つなど、表現のセグメントに対応し得る例示的なビデオファイル150の要素を示すブロック図である。セグメント114、124の各々は、図6の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト内にデータを記憶する。図6の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、ムービー(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と、ムービーフラグメント(MOOF)ボックス164と、ムービーフラグメントランダムアクセス(MFRA)ボックス166とを含む。図6は、ビデオファイルの例を表すが、他のメディアファイルは、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更新ボックスに関する追加の情報を提供する。
【０１４５】
図6の例では、MOOVボックス154は、ムービーヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数のムービー延長(MVEX:movie extends)ボックス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(図4)がビデオファイル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、図6には示されない)を含み得る。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フレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
【０１５６】
アドバンストライブプロファイルは、ライブサービス配布に重点を置く予想される新しいプロファイルである。予想されるプロファイルは、必ずしも拡張された共通プロファイルに対して後方互換性があると見なされるとは限らない。しかしながら、コンテンツプロバイダは、必須と見なされる場合、コンテンツの後方互換性があるバージョンを生成することができる。下記で論じる図は、本開示の技法を適用することができる様々な使用事例を表す。
【０１５７】
図7は、本開示の技法による、使用事例に関する例示的なセグメント提供を示す概念図である。具体的には、図7は、表現232と表現234とを含む適応セット230を示す。表現232は、IDRセグメント236AとIDRセグメント236Eとを含むセグメント236A〜236Eを含み、表現234は、IDRセグメント238AとIDRセグメント238Eとを含むセグメント238A〜238Eを含む。
【０１５８】
この使用事例は、低レイテンシビデオストリーミングサービスおよび切替えを含む。セグメントは(再生時間の点で)0.5秒の持続時間であり、フレームレートは50フレーム毎秒(FPS)であると仮定する。この例では、本開示の技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
4つごとのセグメントが切替え/IDR(瞬時デコーダリフレッシュ)セグメントである。
すべてのセグメントが配信ユニットである。
【０１５９】
図7によれば、適応セット230に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=100
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=232
表現:@id=234
【０１６０】
低レイテンシビデオストリーミングサービスおよび切替えを含む、本開示の技法による別の使用事例について図1を参照して説明する。図1は、この使用事例の場合のセグメント提供を示す。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、この使用事例に関するセットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現内のセグメントは、ユニキャスト表現内のセグメントのサイズの4倍である。
ブロードキャスト/ユニキャスト重複の位置におけるセグメントは切替えセグメントである。
【０１６１】
図7によれば、適応セット230に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=1, @randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=2、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
【０１６２】
図8は、本開示の技術による、スケーラブルHEVC(SHVC)との高速同調を含む使用事例を示す概念図である。図8の例は、ベースレイヤ(ユニキャスト)表現242と、エンハンスメントレイヤ(ブロードキャスト)表現244とを含む適応セット240を示す。ベースレイヤ表現242はセグメント246A〜246E(セグメント246)を含む一方、エンハンスメントレイヤ表現244はセグメント248A、248B(セグメント248)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で説明した技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
セグメント246、248の各々はランダムアクセスセグメントである。(セグメント246Aは図8においてIDRを含むとして示されているが、他の機能的エントリポイントが存在し得るため、ランダムアクセスポイントは必ずしもIDRに制約されるとは限らない。オープンGOPは十分であり得る。)
エンハンスメントレイヤ表現244(すなわち、ブロードキャスト表現)内のセグメント248は、ベースレイヤ表現242(すなわち、ユニキャスト表現)内のセグメント246の持続時間の4倍である。
【０１６３】
図8の例によれば、適応セット240に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=242、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
表現:@id=244、@randomAccessPeriod=100、@dependencyID=242
SegmentTimeline.S:@t=0、@d=100、@r=-1
【０１６４】
図9は、本開示の技術による、ストリームアクセスポイント(SAP)タイプ3との高速同調を含む例示的な使用事例を示す概念図である。具体的には、図9の例では、適応セット254は、その各々がオープンGOPを含むセグメント252A〜252Eを含む表現250を含む。図9には示されないが、適応セット254は表現250に加えて複数の表現を含み得る。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。図9の例によれば、適応セット254に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=250
【０１６５】
図10は、高速同調およびハイブリダイゼーションを含む例示的な使用事例を示す概念図である。具体的には、この例では、適応セット260は、表現262と表現264とを含む。表現262は、セグメント266A〜266F(セグメント266)を含む一方、表現264は、セグメント268A〜268F(セグメント268)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
4つごとのセグメントはメディア切替えのための切替えセグメントである。
【０１６６】
図10によれば、適応セット260に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=25
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=262
表現:@id=264
【０１６７】
図11は、高速同調、ハイブリダイゼーション、およびオープンGOPを含む例示的な使用事例を示す概念図である。図10のセグメント提供と同じセグメント提供を図11に示す。さらに、図11の例は、クライアントデバイス40(図1)などのクライアントデバイスによって取り出されるセグメントを表すセグメントトラバーサル270を示す。すなわち、クライアントデバイス40は、最初に、表現262のセグメント266Aを取り出し、次いで、(たとえば、利用可能なネットワーク帯域幅の変更により)表現264に切り替えることができる。切り替えるために、クライアントデバイス40はセグメント268Bを取り出すことができる。この例では、セグメント266AはIDRセグメントである一方、セグメント268BはオープンGOPセグメントである。本開示の技法によれば、セグメント268BはオープンGOPセグメントであるため、クライアントデバイス40は、表現264のIDRセグメント(たとえば、セグメント268E)を待たずに、268Bにおいて切替えを実現することができる。クライアントデバイス40はまた、表現264のセグメント268Cを取り出す。その後、クライアントデバイス40は、表現を、このとき表現262に再び切替え、やはりオープンGOPセグメントであるセグメント266Dを取り出す。この例では、クライアントデバイス40は、セグメントトラバーサル270に従って、表現262からセグメント266Eおよび266Fを取り出す。
【０１６８】
切替えはタイプ3のSAPにおいて生じ得る。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
4つごとのセグメントはメディア切替えのための切替えセグメントである。
すべてのセグメントはオープンGOP切替えのための切替えセグメントである。
【０１６９】
図11によれば、適応セット260に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
@randomAccessPeriod=25
Switching:@period=100、@type=「media」
Switching:@period=25、@type=「open GOP」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=262
表現:@id=264
【０１７０】
図12は、オープンGOPとの高速同調およびハイブリダイゼーションを含む別の例示的な使用事例を示す概念図である。この例では、適応セット280は、ユニキャスト表現282とブロードキャスト表現284とを含む。ユニキャスト表現282は、セグメント286A〜286F(セグメント286)を含む一方、ブロードキャスト表現284は、セグメント288A、288B(セグメント288)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現284内のセグメント288は、ユニキャスト表現282内のセグメント286の持続時間の4倍である。
ブロードキャスト/ユニキャスト重複の位置にあるセグメント(たとえば、セグメント286A、286E、288A、288B)は切替えセグメントである。
【０１７１】
図12によれば、適応セット280に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=282、@randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=284、@randomAccessPeriod=25
SegmentTimeline.S:@t=0、@d=25、@r=-1
【０１７２】
図13は、高速同調および超低レイテンシを含む例示的な使用事例を示す概念図である。この例では、適応セット290は、ユニキャスト表現292とブロードキャスト表現294とを含む。ユニキャスト表現292は、セグメント296A〜296F(セグメント296)を含む一方、ブロードキャスト表現294は、セグメント298A、298B(セグメント298)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
各セグメントはランダムアクセスセグメントである。
ブロードキャスト表現294内のセグメント298は、ユニキャスト表現292内のセグメント296の持続時間の4倍である。
ブロードキャスト/ユニキャスト重複の位置にあるセグメント(たとえば、セグメント296A、296E、298A、298B)は切替えセグメントである。
【０１７３】
さらに、表現292のすべてのセグメント296が切替えのための情報を提供するわけではない。たとえば、セグメント296Cはブロードキャスト表現294からユニキャスト表現292への切替えを可能にする(たとえば、ブロードキャストサービスが利用不可能になる場合)。しかしながら、セグメント296B、296D、および296Fは、配信ユニットメディアセグメントフォーマットに準拠し、切替えポイントを含まない。これは、たとえば、非イントラ予測フレーム(たとえば、インター予測フレーム)がより高い品質でコーディングされ得るように、セグメント296B、296D、および296Fのより多くのビットがこれらのフレームに割り振られることを可能にする。
【０１７４】
図13によれば、適応セット290に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=292、@randomAccessPeriod=100
SegmentTimeline.S:@t=0、@d=100、@r=-1
表現:@id=294、@randomAccessPeriod=50
SegmentTimeline.S:@t=0、@d=25、@r=-1
【０１７５】
図14は、高速同調および超低レイテンシを含む別の例示的な使用事例を示す概念図である。この例では、適応セット300は、表現302と表現304とを含む。表現302は、セグメント306A〜306F(セグメント306)を含む一方、表現304は、セグメント308A〜308F(セグメント308)を含む。短いセグメントは0.5秒の持続時間であり、フレームレートは50FPSであると仮定する。上記で論じた技法に基づいて、セットアップおよびシグナリングは次の通りであり得る:
表現302内のセグメント306の各々はランダムアクセスセグメントである。
【０１７６】
すなわち、図14に示すように、セグメント306の各々はIDRピクチャを含む。しかしながら、表現304のセグメント308Aおよび308EはIDRピクチャを含むが、セグメント308B、308C、308D、および308FはIDRピクチャを含まない。これは、クライアントデバイス40(図1)などのクライアントデバイスが、セグメント306のうち最近利用可能なセグメントを取り出し、次いで、IDRを含むセグメント308の次のセグメントが利用可能になるとき、表現304に切り替えることによって、適応セット300のメディアコンテンツに迅速に同調することを可能にする。
【０１７７】
図14によれば、適応セット300に関するシグナリングは次の通りであり得る:
AdaptationSet
@timescale=50
Switching:@period=100、@type=「media」
SegmentTimeline.S:@t=0、@d=25、@r=-1
SegmentTemplate@media=「http://example.com/$RepresentationID$」/segment_$Time$.mp4
表現:@id=302、@randomAccessPeriod=25
Switching:@period=25、@type=「media」
表現:@id=304、@randomAccessPeriod=100
Switching:@period=100、@type=「media」
【０１７８】
このようにして、本開示の技法は以下を含む。
追加の新しいセグメントタイプ。
切替えおよび@randomAccessPeriodのための追加のMPDシグナリング。
異なるタイプの切替えに関する定義。
メディア切替え:セグメントアラインメントおよびSAPタイプ1または2。
ビットストリーム切替え:連結が許可される。
オープンGOP切替え。
拡張および制限を文書化するプロファイルを追加する。
後方互換性に関するいずれの問題も文書化する。
より詳細な例を提供する。
【０１７９】
未解決の問題および代替案が残る。次の問題が未解決のまま残る。
本開示の技法に加えて、またはその代替として、ある種の影響および利益をもたらし得る番号ベースのシグナリングが可能である。
本開示の技法に加えて、またはその代替として、リサンプリングおよび非リサンプリングを並行させることが可能な、異なるタイプのオープンGOP切替えも可能である。
上記で論じたメディアフォーマットに関して、追加または代替のメディアフォーマットを使用することができる。
いくつかの例では、フルセグメントに加えて、またはその代替として、サブセグメントを使用することもできる。図6に示したようなセグメントインデックスボックス(SIDX)は、サブセグメントのロケーションをシグナリングすることができ、かつ/または(たとえば、ファイルメタデータ内で、および/またはMPDなどのマニフェストファイル内で)追加の情報がシグナリングされ得る。
【０１８０】
図15は、本開示のいくつかの技法による、メディアコンテンツの表現のセグメントを取り出すための例示的な方法を示すフローチャートである。図15の方法は、図4のサーバデバイス60およびクライアントデバイス40によって実行されるとして説明される。しかしながら、この方法は、他のデバイスによって実行され得ることを理解されたい。たとえば、サーバデバイスに帰属する方法のすべてまたは部分は、(たとえば、図4のサーバデバイス60に加えて、またはその代替として)図4のコンテンツ準備デバイス20によって実行され得る。同様に、クライアントデバイスに帰属する方法のすべてまたは部分は、ブロードキャストおよび/またはユニキャスト送信を介してメディアデータを受信するように構成されたクライアントデバイスのミドルウェアユニットによって実行され得る。
【０１８１】
この例では、サーバデバイス60は最初に、コード化メディアストリームを受信する(320)。いくつかの例では、サーバデバイス60は、コード化メディアストリームをコンテンツ準備デバイス20から受信する一方、他の例では、サーバデバイス60は、コード化メディアストリームを形成するための1つまたは複数の符号化生メディアデータを含み得る。
【０１８２】
サーバデバイス60は、その場合、この例では、コード化メディアストリーム内のセグメントのタイプおよびロケーションを決定する(322)。いくつかの例では、サーバデバイス60は、セグメント(すなわち、独立して取出し可能なファイル)を形成することができる一方、他の例では、サーバデバイス60は、コード化メディアストリームの一部としてセグメントを受信および分析し、その特性に基づいて、セグメントのタイプを決定することができる。配信ユニットメディアセグメント、ランダムアクセスメディアセグメント、重複なしセグメント、および切替えメディアセグメントなど、セグメントの様々なタイプの特性について上記で論じた。このようにして、サーバデバイス60は、各セグメントを分析して、これらのセグメントタイプのうちどれが分析されているセグメントの特性に一致するかを決定することができる。さらに、サーバデバイス60は、コード化メディアストリーム内の各タイプのセグメントの位置を決定することができる。たとえば、サーバデバイス60は、各セグメントタイプが生じる周波数を決定することができる。一例として、図7に関して、IDRを含むセグメント(すなわち、ランダムアクセスメディアセグメント)は、表現232、234の各々の4つのセグメントごとに生じる。
【０１８３】
この例では、サーバデバイス60は、次いで、セグメントのタイプおよびロケーションをシグナリングする(MPDなどの)マニフェストファイルを構築する(324)。代替として、サーバデバイス60は、コンテンツ準備デバイス20から、本開示の技法に従って部分的または完全に構築されたマニフェストファイルを受信することができる。サーバデバイス60は、マニフェストファイルによって表された各適応の各対応する表現内のセグメントのタイプおよびロケーションに関する情報(すなわち、信号)を含めるようにマニフェストファイルを構築することができる。サーバデバイス60は、図7〜図14の例に関して上記で論じたデータと同様のデータを含めるようにマニフェストファイルを構築することができる。マニフェストファイルは、表現および表現自体のメディアデータとは別であることを理解されたい。たとえば、マニフェストファイルは、マニフェストファイルによって記述されたメディアデータ(たとえば、セグメントまたはセグメントの部分)に関して行われる要求とは別の要求に関して利用可能であり得る。
【０１８４】
サーバデバイス60は、次いで、マニフェストファイルを、たとえば、クライアントデバイス40に出力することができる(326)。いくつかの例では、クライアントデバイス40は、最初に、たとえば、マニフェストファイルに関するユニキャスト要求によって、マニフェストファイルを要求することができる。他の例では、クライアントデバイス40は、ブロードキャスト送信に加入することができ、サーバデバイス60はブロードキャストを介してマニフェストファイルを周期的に出力することができる。いずれの場合も、クライアントデバイス40はサーバデバイス60によって出力されたマニフェストファイルを受信することができる(328)。
【０１８５】
クライアントデバイス40は、次いで、マニフェストファイルからセグメントのタイプおよびロケーションを決定することができる(330)。たとえば、クライアントデバイス40は、マニフェストファイルが、特定の適応セットが、たとえば、配信ユニットメディアセグメント、ランダムアクセスメディアセグメント、重複なしセグメント、および切替えメディアセグメントを含む表現を含むことを示すと決定することができる。クライアントデバイス40はまた、セグメントのこれらのタイプの各々のロケーションを決定することができる。たとえば、クライアントデバイス40はセグメントのこれらのタイプのすべてまたは一部が生じる周波数をマニフェストファイルから決定することができる。
【０１８６】
クライアントデバイス40は、メディアデータの取出しを開始する表現のうちの1つを決定することができる。クライアントデバイス40は、上記で論じた様々な使用事例のうちのいずれかを実行することができる。低レイテンシ再生を実現するために、クライアントデバイス40は、もしあれば、表現のうちのどれが、ストリームアクセスポイント(SAP)、たとえば、IDRフレームを含む頻度が最も高いセグメントを有するかを決定することができる。そのような表現は、ユニキャストを介した取出しのために利用可能なセグメントを含み得る。クライアントデバイス40は、そのようなセグメントをユニキャスト表現から最初に取り出し、次いで、(この場合も、マニフェストファイルによって示された)ブロードキャスト表現の次に利用可能なSAPにおいてブロードキャスト表現に切り替えるように構成され得る。
【０１８７】
いずれの場合にも、クライアントデバイス40は、開始ポイントを提供する表現のセグメントを決定することができる(332)。上記で論じたように、セグメントは、ランダムアクセスメディアセグメントを含むことができ、すなわち、ランダムアクセスメディアセグメントフォーマットに準拠し得る。同様に、クライアントデバイス40は、たとえば、マニフェストファイルによって指定されたテンプレートに従って、決定されたセグメントに関するユニフォームリソースロケータ(URL)を決定することができる。次いで、クライアントデバイス40は、たとえば、サーバデバイス60に対してURLに関するHTTP Get要求または部分Get要求を発行することによって、決定されたセグメントを要求することができる(334)。
【０１８８】
次いで、サーバデバイス60は、要求を受信し(336)、要求に応じて、要求されたセグメントをクライアントデバイス40に送信する(338)ことができる。セグメントを受信した(340)後で、クライアントデバイス40は、受信されたセグメントのデータを最初にバッファし、次いで、受信されたセグメントのデータを最終的に復号し、提示することができる(342)。
【０１８９】
上記で論じたように、表現の決定されたセグメントを最初に取り出した後で、クライアントデバイス40は、異なる表現に切り替えるかどうか、およびいつ切り替えるかを決定することができる。たとえば、初期表現は、周波数が非常に高いSAPを含むことができ、ターゲット表現は周波数が比較的に低いSAPを含むことができる。クライアントデバイス40は、ターゲット表現のSAPを含むセグメント(たとえば、ランダムアクセスメディアセグメントまたは切替えメディアセグメント)に達するまで、初期表現からセグメントを要求し続けることができる。その場合、クライアントデバイス40は、(ターゲット表現がユニキャストを介して利用可能である場合)ターゲット表現からセグメントの要求を開始すること、または(ターゲット表現がブロードキャストを介して利用可能である場合)ターゲット表現のメディアデータをトランスポートしているブロードキャストサービスに加入することのいずれかが可能である。
【０１９０】
このようにして、図15は、マニフェストファイルから、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を決定するステップであって、それらのタイプのセグメントのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイントを提供する、決定するステップと、マニフェストファイルから、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを決定するステップと、決定されたセグメントをその表現から取り出すステップとを含む方法の一例を表す。
【０１９１】
図15はまた、メディアコンテンツの表現内に含まれたセグメントの複数のタイプ、セグメントのそれらのタイプの各々によって提供される1つまたは複数の機能、およびその表現内のセグメントのそれらのタイプの各々に準拠するセグメントの位置を示すマニフェストファイルを構築するステップであって、セグメントのそれらのタイプのうちの少なくとも1つが、その表現からのデータの取出しを開始するポイント、およびその表現からのデータの取出しを開始するポイントを提供するタイプに準拠する表現のセグメントを提供する、構築するステップと、そのマニフェストファイルをクライアントデバイスに送るステップと、その表現からのデータの取出しを開始するポイントを提供するタイプに準拠するセグメントに対するクライアントデバイスからの要求に応じて、その表現からのデータの取出しを開始するポイントを提供するセグメントをクライアントデバイスに送るステップとを含む方法の一例を表す。
【０１９２】
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  マニフェストファイル
68A〜68N  表現
70  要求処理ユニット
72  ネットワークインターフェース
74  ネットワーク
102  マルチメディアコンテンツ
104  メディアプレゼンテーション記述(MPD)
110A〜110N  表現
112  ヘッダデータ
114  セグメント114A〜114N
122  ヘッダデータ
124A〜124N  セグメント
130  期間情報
132  適応セット情報
134A〜134N  表現情報
136A  セグメントタイプ情報
136N  セグメントタイプ情報
138A  セグメント機能情報
138N  セグメント機能情報
140A  セグメントロケーション
140N  セグメントロケーション
150  ビデオファイル
152  ファイルタイプ(FTYP)ボックス
154  ムービー(MOOV)ボックス
156  ムービーヘッダ(MVHD)ボックス
158  トラック(TRAK)ボックス
160  ムービー延長(MVEX:movie extends)ボックス
162  セグメントインデックス(SIDX)ボックス
164  ムービーフラグメント(MOOF)ボックス、ムービーフラグメント
166  ムービーフラグメントランダムアクセス(MFRA)ボックス
200  ベン図
202  配信ユニットセグメントフォーマット
204  ランダムアクセスセグメントフォーマット
206  非重複セグメントフォーマット
208  切替えセグメントフォーマット
210  表現
212A〜212C  ISO MBFFファイル
230  適応セット
232  表現
234  表現
236A〜236E  IDRセグメント
238A〜238E  セグメント
240  適応セット
242  ベースレイヤ(ユニキャスト)表現
244  エンハンスメントレイヤ(ブロードキャスト)表現
246A〜246E  セグメント
248A  セグメント
248B  セグメント
250  表現
252A〜252E  セグメント
254  適応セット
260  適応セット
262  表現
264  表現
266A〜266F  セグメント
268A〜268F  セグメント
270  セグメントトラバーサル
280  適応セット
282  ユニキャスト表現
284  ブロードキャスト表現
286A〜286F  セグメント
288A  セグメント
288B  セグメント
290  適応セット
292  ユニキャスト表現
294  ブロードキャスト表現
296A〜296F  セグメント
298A  セグメント
298B  セグメント
300  適応セット
302  表現
304  表現
306A〜306F  セグメント
308A〜308F  セグメント
【図１】
0006655091.tif 000002
【図２】
0006655091.tif 000003
【図３】
0006655091.tif 000004
【図４】
0006655091.tif 000005
【図５Ａ】
0006655091.tif 000006
【図５Ｂ】
0006655091.tif 000007
【図６】
0006655091.tif 000008
【図７】
0006655091.tif 000009
【図８】
0006655091.tif 000010
【図９】
0006655091.tif 000011
【図１０】
0006655091.tif 000012
【図１１】
0006655091.tif 000013
【図１２】
0006655091.tif 000014
【図１３】
0006655091.tif 000015
【図１４】
0006655091.tif 000016
【図１５】
0006655091.tif 000017