(57)【要約】一例では、メディアコンテンツを処理するためのデバイスは、メディアコンテンツを記憶するように構成されたメモリと、回路においてインプリメントされた１つまたは複数のプロセッサとを含み、その１つまたは複数のプロセッサは、メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、第１のパッキングされた領域を処理するために、１つまたは複数のプロセッサは、第１のアンパッキングされた領域を作り出すために、第１のパッキングされた領域をアンパッキングすることと、第１のアンパッキングされた領域から第１の投影された領域を形成することとを行うように構成される、メディアコンテンツの第２のパッキングされた領域を処理することと、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップし、ここにおいて、第２のパッキングされた領域を処理するために、１つまたは複数のプロセッサは、第２のアンパッキングされた領域を作り出すために、第２のパッキングされた領域をアンパッキングすることと、第２のアンパッキングされた領域から第２の投影された領域を形成することとを行うように構成される、を行うように構成される。【選択図】図８
2020526982.tif 000002
【特許請求の範囲】
【請求項１】
メディアコンテンツを処理する方法であって、前記方法は、
メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、前記第１のパッキングされた領域を処理することは、
第１のアンパッキングされた領域を作り出すために、前記第１のパッキングされた領域をアンパッキングすることと、
前記第１のアンパッキングされた領域から第１の投影された領域を形成することとを備える、
前記メディアコンテンツの第２のパッキングされた領域を処理することと、前記第２のパッキングされた領域は、少なくとも部分的に前記第１のパッキングされた領域とオーバーラップし、ここにおいて、前記第２のパッキングされた領域を処理することは、
第２のアンパッキングされた領域を作り出すために、前記第２のパッキングされた領域をアンパッキングすることと、
前記第２のアンパッキングされた領域から第２の投影された領域を形成することとを備え、前記第２の投影された領域は、前記第１の投影された領域とは異なる、
を備える、方法。
【請求項２】
前記第１のパッキングされた領域を処理することは、
第１の幅値から前記第１のパッキングされた領域の第１の幅を決定することと、
第１の高さ値から前記第１のパッキングされた領域の第１の高さを決定することと、
第１の上部値から前記第１のパッキングされた領域の第１の上部オフセットを決定することと、
第１の左値から前記第１のパッキングされた領域の第１の左オフセットを決定することと
を備え、前記第１のパッキングされた領域を処理することは、
第２の幅値から前記第２のパッキングされた領域の第２の幅を決定することと、
第２の高さ値から前記第２のパッキングされた領域の第２の高さを決定することと、
第２の上部値から前記第２のパッキングされた領域の第２の上部オフセットを決定することと、
第２の左値から前記第２のパッキングされた領域の第２の左オフセットを決定することと
を備える、請求項１に記載の方法。
【請求項３】
前記第１の幅値は、packed_reg_width[i]値を備え、前記第１の高さ値は、packed_reg_height[i]値を備え、前記第１の上部値は、packed_reg_top[i]値を備え、前記第１の左値は、packed_reg_left[i]を備え、前記第２の幅値は、packed_reg_width[j]値を備え、前記第２の高さ値は、packed_reg_height[j]値を備え、前記第２の上部値は、packed_reg_top[j]値を備え、および前記第２の左値は、packed_reg_left[j]値を備える、請求項２に記載の方法。
【請求項４】
前記第２のパッキングされた領域を処理することは、
前記第１のパッキングされた領域とオーバーラップする前記第２のパッキングされた領域の一部分を決定することと、
前記第２のパッキングされた領域の前記一部分とオーバーラップする前記第１のパッキングされた領域の対応する一部分で、前記第２のパッキングされた領域の前記一部分を充填することと、
ここにおいて、前記第２のパッキングされた領域をアンパッキングすることは、前記第２のアンパッキングされた領域を作り出すために、前記充填された一部分を含む前記第２のパッキングされた領域をアンパッキングすることを備える、
をさらに備える、請求項１に記載の方法。
【請求項５】
前記メディアコンテンツは、平面視である、請求項１に記載の方法。
【請求項６】
前記メディアコンテンツは、立体視である、請求項１に記載の方法。
【請求項７】
前記第１のパッキングされた領域は、前記メディアコンテンツの第１のピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの第２のピクチャに対応する、請求項６に記載の方法。
【請求項８】
前記第１のパッキングされた領域は、前記メディアコンテンツのピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの前記ピクチャに対応する、請求項６に記載の方法。
【請求項９】
前記第１のパッキングされた領域および前記第２のパッキングされた領域を定義するマニフェストファイルのデータを処理することをさらに備える、請求項１に記載の方法。
【請求項１０】
前記マニフェストファイルは、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）を備える、請求項９に記載の方法。
【請求項１１】
前記メディアコンテンツの事前選択レベルでコンテンツカバレッジ記述を処理することをさらに備える、請求項１に記載の方法。
【請求項１２】
前記コンテンツカバレッジ記述を処理することは、前記コンテンツカバレッジ記述を備えるマニフェストファイルを処理することを備える、請求項１１に記載の方法。
【請求項１３】
前記マニフェストファイルは、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）を備える、請求項１２に記載の方法。
【請求項１４】
前記メディアコンテンツについてのＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）データのFramePacking要素のビデオフレームパッキングタイプ値を処理することと、
前記ＤＡＳＨデータの前記FramePacking要素の五点形サンプリングフラッグ値を処理することと
をさらに備える、請求項１に記載の方法。
【請求項１５】
前記ＤＡＳＨデータは、ＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）を備える、請求項１４に記載の方法。
【請求項１６】
メディアコンテンツを処理するためのデバイスであって、前記デバイスは、
メディアコンテンツを記憶するように構成されたメモリと、
回路においてインプリメントされた１つまたは複数のプロセッサと
を備え、前記１つまたは複数のプロセッサは、
前記メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、前記第１のパッキングされた領域を処理するために、前記１つまたは複数のプロセッサは、
第１のアンパッキングされた領域を作り出すために、前記第１のパッキングされた領域をアンパッキングすることと、
前記第１のアンパッキングされた領域から第１の投影された領域を形成することとを行うように構成される、
前記メディアコンテンツの第２のパッキングされた領域を処理することと、前記第２のパッキングされた領域は、少なくとも部分的に前記第１のパッキングされた領域とオーバーラップし、ここにおいて、前記第２のパッキングされた領域を処理するために、前記１つまたは複数のプロセッサは、
第２のアンパッキングされた領域を作り出すために、前記第２のパッキングされた領域をアンパッキングすることと、
前記第２のアンパッキングされた領域から第２の投影された領域を形成することとを行うように構成される、
を行うように構成される、デバイス。
【請求項１７】
前記第１のパッキングされた領域を処理するために、前記１つまたは複数のプロセッサは、
第１の幅値から前記第１のパッキングされた領域の第１の幅を決定することと、
第１の高さ値から前記第１のパッキングされた領域の第１の高さを決定することと、
第１の上部値から前記第１のパッキングされた領域の第１の上部オフセットを決定することと、
第１の左値から前記第１のパッキングされた領域の第１の左オフセットを決定することと
を行うように構成され、前記第２のパッキングされた領域を処理するために、前記１つまたは複数のプロセッサは、
第２の幅値から前記第２のパッキングされた領域の第２の幅を決定することと、
第２の高さ値から前記第２のパッキングされた領域の第２の高さを決定することと、
第２の上部値から前記第２のパッキングされた領域の第２の上部オフセットを決定することと、
第２の左値から前記第２のパッキングされた領域の第２の左オフセットを決定することと
を行うように構成される、請求項１６に記載のデバイス。
【請求項１８】
前記第１の幅値は、packed_reg_width[i]値を備え、前記第１の高さ値は、packed_reg_height[i]値を備え、前記第１の上部値は、packed_reg_top[i]値を備え、前記第１の左値は、packed_reg_left[i]を備え、前記第２の幅値は、packed_reg_width[j]値を備え、前記第２の高さ値は、packed_reg_height[j]値を備え、前記第２の上部値は、packed_reg_top[j]値を備え、および前記第２の左値は、packed_reg_left[j]値を備える、請求項１７に記載のデバイス。
【請求項１９】
前記第２のパッキングされた領域を処理するために、前記１つまたは複数のプロセッサは、
前記第１のパッキングされた領域とオーバーラップする前記第２のパッキングされた領域の一部分を決定することと、
前記第２のパッキングされた領域の前記一部分とオーバーラップする前記第１のパッキングされた領域の対応する一部分で、前記第２のパッキングされた領域の前記一部分を充填することと、
ここにおいて、前記第２のパッキングされた領域をアンパッキングために、前記１つまたは複数のプロセッサは、前記第２のアンパッキングされた領域を作り出すために、前記充填された一部分を含む前記第２のパッキングされた領域をアンパッキングするように構成される、
を行うようにさらに構成される、請求項１６に記載のデバイス。
【請求項２０】
前記メディアコンテンツは、平面視である、請求項１６に記載のデバイス。
【請求項２１】
前記メディアコンテンツは、立体視である、請求項１６に記載のデバイス。
【請求項２２】
前記第１のパッキングされた領域は、前記メディアコンテンツの第１のピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの第２のピクチャに対応する、請求項２１に記載のデバイス。
【請求項２３】
前記第１のパッキングされた領域は、前記メディアコンテンツのピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの前記ピクチャに対応する、請求項２１に記載のデバイス。
【請求項２４】
前記１つまたは複数のプロセッサは、前記第１のパッキングされた領域および前記第２のパッキングされた領域を定義するマニフェストファイルのデータを処理するようにさらに構成される、請求項１６に記載のデバイス。
【請求項２５】
前記マニフェストファイルは、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）を備える、請求項２４に記載のデバイス。
【請求項２６】
前記１つまたは複数のプロセッサは、前記メディアコンテンツの事前選択レベルでコンテンツカバレッジ記述を処理するようにさらに構成される、請求項１６に記載のデバイス。
【請求項２７】
前記コンテンツカバレッジ記述を処理することは、前記コンテンツカバレッジ記述を備えるマニフェストファイルを処理することを備える、請求項２６に記載のデバイス。
【請求項２８】
前記マニフェストファイルは、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）を備える、請求項２７に記載のデバイス。
【請求項２９】
前記１つまたは複数のプロセッサは、
前記メディアコンテンツについてのＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）データのFramePacking要素のビデオフレームパッキングタイプ値を処理することと、
前記ＤＡＳＨデータの前記FramePacking要素の五点形サンプリングフラッグ値を処理することと
を行うようにさらに構成される、請求項１６に記載のデバイス。
【請求項３０】
前記ＤＡＳＨデータは、ＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）を備える、請求項２９に記載のデバイス。
【請求項３１】
前記デバイスは、
集積回路と、
マイクロプロセッサと、
ワイヤレス通信デバイスと
のうちの少なくとも１つを備える、請求項１６に記載のデバイス。
【請求項３２】
前記デバイスは、クライアントデバイスを備える、請求項１６に記載のデバイス。
【請求項３３】
メディアコンテンツを処理するためのデバイスであって、前記デバイスは、
メディアコンテンツの第１のパッキングされた領域を処理するための手段と、ここにおいて、前記第１のパッキングされた領域を前記処理するための手段は、
第１のアンパッキングされた領域を作り出すために、前記第１のパッキングされた領域をアンパッキングするための手段と、
前記第１のアンパッキングされた領域から第１の投影された領域を形成するための手段とを備える、
前記メディアコンテンツの第２のパッキングされた領域を処理するための手段と、前記第２のパッキングされた領域は、少なくとも部分的に前記第１のパッキングされた領域とオーバーラップし、ここにおいて、前記第２のパッキングされた領域を前記処理するための手段は、
第２のアンパッキングされた領域を作り出すために、前記第２のパッキングされた領域をアンパッキングするための手段と、
前記第２のアンパッキングされた領域から第２の投影された領域を形成するための手段とを備え、前記第２の投影された領域は、前記第１の投影された領域とは異なる、
を備える、デバイス。
【請求項３４】
前記第１のパッキングされた領域を前記処理するための手段は、
第１の幅値から前記第１のパッキングされた領域の第１の幅を決定するための手段と、
第１の高さ値から前記第１のパッキングされた領域の第１の高さを決定するための手段と、
第１の上部値から前記第１のパッキングされた領域の第１の上部オフセットを決定するための手段と、
第１の左値から前記第１のパッキングされた領域の第１の左オフセットを決定するための手段と、
を備え、前記第１のパッキングされた領域を前記処理するための手段は、
第２の幅値から前記第２のパッキングされた領域の第２の幅を決定するための手段と、
第２の高さ値から前記第２のパッキングされた領域の第２の高さを決定するための手段と、
第２の上部値から前記第２のパッキングされた領域の第２の上部オフセットを決定するための手段と、
第２の左値から前記第２のパッキングされた領域の第２の左オフセットを決定するための手段と
を備える、請求項３３に記載のデバイス。
【請求項３５】
前記第１の幅値は、packed_reg_width[i]値を備え、前記第１の高さ値は、packed_reg_height[i]値を備え、前記第１の上部値は、packed_reg_top[i]値を備え、前記第１の左値は、packed_reg_left[i]を備え、前記第２の幅値は、packed_reg_width[j]値を備え、前記第２の高さ値は、packed_reg_height[j]値を備え、前記第２の上部値は、packed_reg_top[j]値を備え、および前記第２の左値は、packed_reg_left[j]値を備える、請求項３４に記載のデバイス。
【請求項３６】
前記第２のパッキングされた領域を前記処理するための手段は、
前記第１のパッキングされた領域とオーバーラップする前記第２のパッキングされた領域の一部分を決定するための手段と、
前記第２のパッキングされた領域の前記一部分とオーバーラップする前記第１のパッキングされた領域の対応する一部分で、前記第２のパッキングされた領域の前記一部分を充填するための手段と、
ここにおいて、前記第２のパッキングされた領域を前記アンパッキングするための手段は、前記第２のアンパッキングされた領域を作り出すために、前記充填された一部分を含む前記第２のパッキングされた領域をアンパッキングするための手段を備える、
をさらに備える、請求項３３に記載のデバイス。
【請求項３７】
前記メディアコンテンツは、立体視である、請求項３３に記載のデバイス。
【請求項３８】
前記第１のパッキングされた領域は、前記メディアコンテンツの第１のピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの第２のピクチャに対応する、請求項３７に記載のデバイス。
【請求項３９】
前記第１のパッキングされた領域は、前記メディアコンテンツのピクチャに対応し、および前記第２のパッキングされた領域は、前記メディアコンテンツの前記ピクチャに対応する、請求項３７に記載のデバイス。
【請求項４０】
前記第１のパッキングされた領域および前記第２のパッキングされた領域を定義するマニフェストファイルのデータを処理するための手段をさらに備える、請求項３３に記載のデバイス。
【請求項４１】
前記メディアコンテンツの事前選択レベルでコンテンツカバレッジ記述を処理するための手段をさらに備える、請求項３３に記載のデバイス。
【請求項４２】
前記メディアコンテンツについてのＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）データのFramePacking要素のビデオフレームパッキングタイプ値を処理するための手段と、
前記ＤＡＳＨデータの前記FramePacking要素の五点形サンプリングフラッグ値を処理するための手段と
をさらに備える、請求項３３に記載のデバイス。
【請求項４３】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、前記プロセッサに、前記第１のパッキングされた領域を処理することを行わせる前記命令は、前記プロセッサに、
第１のアンパッキングされた領域を作り出すために、前記第１のパッキングされた領域をアンパッキングすることと、
前記第１のアンパッキングされた領域から第１の投影された領域を形成することとを行わせる命令を備える、
前記メディアコンテンツの第２のパッキングされた領域を処理することと、前記第２のパッキングされた領域は、少なくとも部分的に前記第１のパッキングされた領域とオーバーラップし、ここにおいて、前記プロセッサに、前記第２のパッキングされた領域を処理することを行わせる前記命令は、前記プロセッサに、
第２のアンパッキングされた領域を作り出すために、前記第２のパッキングされた領域をアンパッキングすることと、
前記第２のアンパッキングされた領域から第２の投影された領域を形成することとを行わせる命令を備え、前記第２の投影された領域は、前記第１の投影された領域とは異なる、
を行わせる、コンピュータ可読記憶媒体。
【請求項４４】
前記プロセッサに、前記第１のパッキングされた領域を処理することを行わせる前記命令は、前記プロセッサに、
第１の幅値から前記第１のパッキングされた領域の第１の幅を決定することと、
第１の高さ値から前記第１のパッキングされた領域の第１の高さを決定することと、
第１の上部値から前記第１のパッキングされた領域の第１の上部オフセットを決定することと、
第１の左値から前記第１のパッキングされた領域の第１の左オフセットを決定することと
を行わせる命令を備え、前記プロセッサに、前記第１のパッキングされた領域を処理することを行わせる前記命令は、前記プロセッサに、
第２の幅値から前記第２のパッキングされた領域の第２の幅を決定することと、
第２の高さ値から前記第２のパッキングされた領域の第２の高さを決定することと、
第２の上部値から前記第２のパッキングされた領域の第２の上部オフセットを決定することと、
第２の左値から前記第２のパッキングされた領域の第２の左オフセットを決定することと
を行わせる命令を備える、請求項４３に記載のコンピュータ可読記憶媒体。
【請求項４５】
前記第１の幅値は、packed_reg_width[i]値を備え、前記第１の高さ値は、packed_reg_height[i]値を備え、前記第１の上部値は、packed_reg_top[i]値を備え、前記第１の左値は、packed_reg_left[i]を備え、前記第２の幅値は、packed_reg_width[j]値を備え、前記第２の高さ値は、packed_reg_height[j]値を備え、前記第２の上部値は、packed_reg_top[j]値を備え、および前記第２の左値は、packed_reg_left[j]値を備える、請求項４４に記載のコンピュータ可読記憶媒体。
【請求項４６】
前記プロセッサに、前記第２のパッキングされた領域を処理することを行わせる前記命令は、前記プロセッサに、
前記第１のパッキングされた領域とオーバーラップする前記第２のパッキングされた領域の一部分を決定することと、
前記第２のパッキングされた領域の前記一部分とオーバーラップする前記第１のパッキングされた領域の対応する一部分で、前記第２のパッキングされた領域の前記一部分を充填することと、
ここにおいて、前記プロセッサに、前記第２のパッキングされた領域をアンパッキングすることを行わせる前記命令は、前記プロセッサに、前記第２のアンパッキングされた領域を作り出すために、前記充填された一部分を含む前記第２のパッキングされた領域をアンパッキングすることを行わせる命令を備える、
を行わせる命令をさらに備える、請求項４３に記載のコンピュータ可読記憶媒体。
【請求項４７】
前記メディアコンテンツは、立体視である、請求項４３に記載のコンピュータ可読記憶媒体。
【請求項４８】
前記プロセッサに、前記メディアコンテンツについてのマニフェストファイルを処理することを行わせる命令をさらに備え、前記マニフェストファイルは、前記マニフェストファイルメディアコンテンツの事前選択レベルのコンテンツカバレッジ記述を備える、請求項４３に記載のコンピュータ可読記憶媒体。
【請求項４９】
前記プロセッサに、
前記メディアコンテンツについてのＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）データのFramePacking要素のビデオフレームパッキングタイプ値を処理することと、
前記ＤＡＳＨデータの前記FramePacking要素の五点形サンプリングフラッグ値を処理することと
を行わせる命令をさらに備える、請求項４３に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
[0001]  本願は、２０１７年７月１４日に出願された米国仮特許出願第６２／５３２，８６２号と、２０１８年７月５日に出願された米国特許出願第１６／０２８，２５５号の利益を主張し、それらの内容全体は、これにより参照によって組み込まれる。
【技術分野】
【０００２】
[0002]  この開示は、符号化されたビデオデータ（encoded video data）の記憶およびトランスポートに関する。
【背景技術】
【０００３】
[0003]  デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラ無線電話または衛星無線電話、ビデオテレビ会議デバイス、および同様のものを含む、幅広い範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３またはＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、アドバンストビデオコーディング（ＡＶＣ：Advanced Video Coding）、（高効率ビデオコーディング（ＨＥＶＣ：High Efficiency Video Coding）とも呼ばれる）ＩＴＵ−Ｔ Ｈ．２６５、およびそのような規格の拡張によって定義される規格に説明されているもののような、ビデオ圧縮技法（video compression technique）をインプリメントする。
【０００４】
[0004]  ビデオデータが符号化された後に、ビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット、およびＡＶＣのようなその拡張のような、多様な規格のうちの任意のものに準拠するビデオファイル（video file）へとアセンブルされ得る。
【発明の概要】
【０００５】
[0005]  一般に、この開示は、メディアデータ（media data）を処理することに関する技法を説明する。特に、それら技法は、ビットを節約するための、別のエリアと同じであるピクチャエリアの送信の防止を可能にするリージョンワイズパッキング（region-wise packing）を含む。ビットの節約は、平面視（monoscopic）仮想現実（ＶＲ：virtual reality）ビデオコンテンツのピクチャ内、または立体視（stereoscopic）ＶＲビデオコンテンツのビュー内の両方で達成されることができる。これらの技法は、コンテナファイル中およびビデオビットストリーム（video bitstream）中の両方でのリージョンワイズパッキングのシグナリングに適用される。それら技法はまた、ビデオコンテンツが複数の適合セット（adaptation set）中で搬送されるメディアプレゼンテーション（media presentation）のＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）メディアプレゼンテーション記述（ＭＰＤ：Media Presentation Description）中のコンテンツカバレッジ（）全体のシグナリングを可能にするコンテンツカバレッジシグナリング（content coverage signaling）を含む。それら技法はまた、各構成要素（constituent）フレームの各色成分平面がフレームパッキングされたビデオコンテンツ（frame packed video content）のために五点形（quincunx）（チェッカーボード（checkerboard））サンプリングされているかどうかのシグナリングを可能にするＤＡＳＨ ＭＰＤ中のフレームパッキング情報をシグナリングすることを含む。この情報は、フレームパッキングタイプに加えて、受信機がビデオコンテンツを適正にデフレームパッキング（de-frame-pack）およびレンダリング（render）するための能力を有しているかどうかを決定するために使用され得る。
【０００６】
[0006]  一例では、メディアコンテンツ（media content）を処理する方法は、メディアコンテンツの第１のパッキングされた領域（first packed region）を処理することと、ここにおいて、第１のパッキングされた領域を処理することは、第１のアンパッキングされた領域（first unpacked region）を作り出すために、第１のパッキングされた領域をアンパッキング（unpack）することと、第１のアンパッキングされた領域から第１の投影された領域（first projected region）を形成することとを備える、メディアコンテンツの第２のパッキングされた領域（second unpacked region）を処理することと、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップ（overlap）し、ここにおいて、第２のパッキングされた領域を処理することは、第２のアンパッキングされた領域（second unpacked region）を作り出すために、第２のパッキングされた領域をアンパッキングすることと、第２のアンパッキングされた領域から第２の投影された領域（second projected region）を形成することとを備え、第２の投影された領域は、第１の投影された領域とは異なる、を含む。
【０００７】
[0007]  別の例では、メディアコンテンツを処理するためのデバイスは、メディアコンテンツを記憶するように構成されたメモリと、回路においてインプリメントされた１つまたは複数のプロセッサとを含み、その１つまたは複数のプロセッサは、メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、第１のパッキングされた領域を処理するために、１つまたは複数のプロセッサは、第１のアンパッキングされた領域を作り出すために、第１のパッキングされた領域をアンパッキングすることと、第１のアンパッキングされた領域から第１の投影された領域を形成することとを行うように構成される、メディアコンテンツの第２のパッキングされた領域を処理することと、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップし、ここにおいて、第２のパッキングされた領域を処理するために、１つまたは複数のプロセッサは、第２のアンパッキングされた領域を作り出すために、第２のパッキングされた領域をアンパッキングすることと、第２のアンパッキングされた領域から第２の投影された領域を形成することとを行うように構成される、を行うように構成される。
【０００８】
[0008]  別の例では、メディアコンテンツを処理するためのデバイスは、メディアコンテンツの第１のパッキングされた領域を処理するための手段と、ここにおいて、第１のパッキングされた領域を処理するための手段は、第１のアンパッキングされた領域を作り出すために、第１のパッキングされた領域をアンパッキングするための手段と、第１のアンパッキングされた領域から第１の投影された領域を形成するための手段とを備える、メディアコンテンツの第２のパッキングされた領域を処理するための手段と、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップし、ここにおいて、第２のパッキングされた領域を処理するための手段は、第２のアンパッキングされた領域を作り出すために、第２のパッキングされた領域をアンパッキングするための手段と、第２のアンパッキングされた領域から第２の投影された領域を形成するための手段とを備え、第２の投影された領域は、第１の投影された領域とは異なる、を含む。
【０００９】
[0009]  別の例では、コンピュータ可読記憶媒体（computer-readable storage medium）は、プロセッサに、メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、プロセッサに、第１のパッキングされた領域を処理することを行わせる命令は、プロセッサに、第１のアンパッキングされた領域を作り出すために、第１のパッキングされた領域をアンパッキングすることと、第１のアンパッキングされた領域から第１の投影された領域を形成することとを行わせる命令を備える、メディアコンテンツの第２のパッキングされた領域を処理することと、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップし、ここにおいて、プロセッサに、第２のパッキングされた領域を処理することを行わせる命令は、プロセッサに、第２のアンパッキングされた領域を作り出すために、第２のパッキングされた領域をアンパッキングすることと、第２のアンパッキングされた領域から第２の投影された領域を形成することとを行わせる命令を備え、第２の投影された領域は、第１の投影された領域とは異なる、を行わせる命令を記憶している。
【００１０】
[0010]  １つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点は、説明および図面から、そして特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【００１１】
【図１】[0011]  ネットワークを通してメディアデータをストリーミング（stream）するための技法をインプリメントする実例的なシステムを例示するブロック図である。
【図２】[0012]  取り出しユニット（retrieval unit）のコンポーネントの実例的なセットを例示するブロック図である。
【図３】[0013]  全方位メディアフォーマット（ＯＭＡＦ：Omnidirectional MediA Format）のためのリージョンワイズパッキング（ＲＷＰ：region-wise packing）の２つの例を例示する概念図である。
【図４】[0014]  実例的な投影された領域（projected region）とガードバンド（guard band）を有する対応するパッキングされた領域（packed region）とを例示する概念図である。
【図５】[0015]  実例的なマルチメディアコンテンツ（multimedia content）の要素を例示する概念図である。
【図６】[0016]  実例的なビデオファイルの要素を例示するブロック図である。
【図７】[0017]  この開示の技法にしたがった、ビデオデータを生成する実例的な方法を例示するフローチャートである。
【図８】[0018]  この開示の技法にしたがった、ビデオデータを受信および処理する実例的な方法を例示するフローチャートである。
【詳細な説明】
【００１２】
[0019]  この開示の技法は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ISO base media file format）、ＩＳＯＢＭＦＦへの拡張、スケーラブルビデオコーディング（ＳＶＣ：Scalable Video Coding）ファイルフォーマット、アドバンストビデオコーディング（ＡＶＣ）ファイルフォーマット、高効率ビデオコーディング（ＨＥＶＣ）ファイルフォーマット、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））ファイルフォーマット、および／またはマルチビュービデオコーディング（ＭＶＣ：Multiview Video Coding）ファイルフォーマット、または他のビデオファイルフォーマットのうちの任意のものにしたがってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。ＩＳＯ ＢＭＦＦのドラフトは、ＩＳＯ／ＩＥＣ１４４９６−１２に規定されており、phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zipから入手可能である。別の実例的なファイルフォーマットであるＭＰＥＧ−４ファイルフォーマットのドラフトは、ＩＳＯ／ＩＥＣ１４４９６−１５に規定されており、wg11.sc29.org/doc_end_user/documents/115_Geneva/wg11/w16169-v2-w16169.zipから入手可能である。
【００１３】
[0020]  ＩＳＯＢＭＦＦは、ＡＶＣファイルフォーマットのような多くのコーデックカプセル化フォーマット（codec encapsulation format）の、ならびに、ＭＰＥＧ−４ファイルフォーマット、３ＧＰＰファイルフォーマット（３ＧＰ）、およびデジタルビデオブロードキャスティング（ＤＶＢ：digital video broadcasting）ファイルフォーマットのような多くのマルチメディアコンテナフォーマット（multimedia container format）の基礎として使用される。
【００１４】
[0021]  オーディオおよびビデオのような連続メディアに加えて、画像のような静的メディア、ならびにメタデータ（metadata）が、ＩＳＯＢＭＦＦに準拠するファイル中に記憶されることができる。ＩＳＯＢＭＦＦにしたがって構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード（progressive downloading）、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）のためのセグメント（segment）、ストリーミングされることになるコンテンツのためのコンテナおよびそのパケット化命令、および受信されるリアルタイムメディアストリーム（real-time media stream）の記録を含む、多くの目的のために使用され得る。
【００１５】
[0022]  ボックス（box）は、ＩＳＯＢＭＦＦにおけるエレメンタリシンタックス構造（elementary syntax structure）であり、４文字のコーディングされたボックスタイプ、ボックスのバイトカウント、およびペイロードを含む。ＩＳＯＢＭＦＦファイルは、ボックスのシーケンスを含み、およびボックスは、他のボックスを包含し得る。ＩＳＯＢＭＦＦによると、ムービーボックス（「ｍｏｏｖ」）は、ファイル中に存在する連続メディアストリームについてのメタデータを包含し、各々は、トラックとしてファイル中に表される。ＩＳＯＢＭＦＦによれば、トラックについてのメタデータは、トラックボックス（「ｔｒａｋ」）中にエンクローズされる（enclosed）が、その一方でトラックのメディアコンテンツは、メディアデータボックス（「ｍｄａｔ」）中にエンクローズされるか、または別個のファイル中に直接提供されるかのいずれかである。トラックについてのメディアコンテンツは、オーディオまたはビデオアクセスユニットのようなサンプルのシーケンスを含む。
【００１６】
[0023]  ＩＳＯＢＭＦＦは、次のタイプのトラックを指定する：エレメンタリメディアストリームを包含するメディアトラック、メディア送信命令を含むか、または受信されたパケットストリームを表すかのいずれかであるヒントトラック（hint track）、および時間同期されたメタデータ（time-synchronized metadata）を備える時間指定されたメタデータトラック（timed metadata track）。
【００１７】
[0024]  当初は記憶のために設計されたにも関わらず、ＩＳＯＢＭＦＦは、ストリーミングに、例えば、プログレッシブダウンロードまたはＤＡＳＨに非常に有益であることが証明されている。ストリーミングの目的のために、ＩＳＯＢＭＦＦで定義されたムービーフラグメント（movie fragment）が使用されることができる。
【００１８】
[0025]  各トラックについてのメタデータは、サンプル記述エントリ（sample description entry）のリストを含み、各々は、そのトラック中で使用されるコーディングまたはカプセル化フォーマット、およびそのフォーマットを処理するために必要とされる初期化データを提供する。各サンプルは、トラックのサンプル記述エントリのうちの１つに関連付けられる。
【００１９】
[0026]  ＩＳＯＢＭＦＦは、様々なメカニズムを用いてサンプル固有メタデータ（sample-specific metadata）を指定することを可能にする。サンプルテーブルボックス（「ｓｔｂｌ」）内の特定のボックスは、共通のニーズに応えるために標準化されている。例えば、同期サンプルボックス（「ｓｔｓｓ」）は、トラックのランダムアクセスサンプルをリストするために使用される。サンプルグルーピングメカニズムは、ファイル中にサンプルグループ記述エントリとして指定された同じプロパティを共有するサンプルのグループへの４文字のグルーピングタイプにしたがったサンプルのマッピングを可能にする。いくつかのグルーピングタイプが、ＩＳＯＢＭＦＦで指定されている。
【００２０】
[0027]  仮想現実（ＶＲ）は、仮想の非物理的世界とのインタラクションを可能にする没入したユーザの動きによって相関された自然および／または合成イメージおよびサウンドのレンダリングによって作成されたその仮想世界の中に仮想的に存在するための能力である。ヘッドマウントディスプレイ（ＨＭＤ：head mounted display）のようなレンダリングデバイスと、（３６０度ビデオと呼ばれることも多い）ＶＲビデオ作成とにおいてなされた近年の進歩により、有意な品質のエクスペリエンス（experience）が提供されることができる。ＶＲアプリケーションは、ゲーミング、トレーニング、教育、スポーツビデオ、オンラインショッピング、エントレインメント（entrainment）、等を含む。
【００２１】
[0028]  典型的なＶＲシステムは、以下のコンポーネントおよびステップを含む：  
１）カメラセット、それは、異なる方向に向いており、理想的には集合的にそのカメラセットの周囲の全てのビューポイント（viewpoint）をカバーしている複数の個々のカメラを典型的に含む。  
２）イメージスティッチング（Image stitching）、ここで、その複数の個々のカメラによって撮られたビデオピクチャは、時間ドメイン中で同期され、および空間ドメイン中で繋ぎ合わされ、球面ビデオ（spherical video）になるが、（世界地図のような）正距円筒図法（equi-rectangular）または立方体地図（cube map）のような長方形フォーマットにマッピングされる。  
３）そのマッピングされた長方形フォーマットのビデオは、ビデオコーデック、例えば、Ｈ．２６５／ＨＥＶＣまたはＨ．２６４／ＡＶＣ、を使用して符号化／圧縮される。  
４）その圧縮されたビデオビットストリーム（１つ以上）は、メディアフォーマットで記憶および／またはカプセル化され、および受信機（例えば、クライアントデバイス（client device））にネットワークを通じて送信され得る（ことによると、ビューポート（viewport）と呼ばれることもある、ユーザによって見られているエリアをカバーするサブセットのみ）。  
５）その受信デバイスは、ことによるとあるファイルフォーマットでカプセル化されたビデオビットストリーム（video bitstream）（１つ以上）またはその一部を受信し、および（その受信デバイスと同じクライアントデバイス中に含まれ得る）レンダリングデバイスに復号されたビデオ信号またはその一部を送る。  
６）そのレンダリングデバイスは、例えば、ヘッドマウントディスプレイ（ＨＭＤ）であることができ、それは、頭の動きおよび目の動きの瞬間さえもトラックすることができ、および没入型のエクスペリエンスがユーザに配信されるようにビデオの対応する部分をレンダリングし得る。
【００２２】
[0029]  全方位メディアフォーマット（ＯＭＡＦ：Omnidirectional MediA Format）は、全方位メディアアプリケーションを可能にするメディアフォーマットを定義するために、ムービングピクチャ専門家グループ（ＭＰＥＧ：the Moving Pictures Experts Group）によって開発されており、３６０度ビデオおよび関連するオーディオを伴うＶＲアプリケーションに重点を置いている。ＯＭＡＦは、球面または３６０度ビデオの２次元長方形ビデオへの変換のために使用されることができる投影法（projection method）のリストを、それに続いてＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ：ISO base media file format）を使用して全方位メディアおよび関連するメタデータをどのように記憶するかと、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）を使用して全方位メディアをどのようにカプセル化、シグナリング、およびストリーミングするかと、そして最後に、全方位メディア信号の圧縮および再生のためにどのビデオおよびオーディオコーデックならびにメディアコーディング構成が使用されることができるかとを指定する。ＯＭＡＦは、ＩＳＯ／ＩＥＣ２３０９０−２になる予定であり、およびドラフト仕様書は、wg11.sc29.org/doc_end_user/documents/119_Torino/wg11/m40849-v1-m40849_OMAF_text_Berlin_output.zipから入手可能である。
【００２３】
[0030]  ＤＡＳＨのようなＨＴＴＰストリーミングプロトコルでは、頻繁に使用される動作は、ＨＥＡＤ、ＧＥＴ、および部分的ＧＥＴを含む。ＨＥＡＤ動作は、所与のユニフォームリソースロケータ（ＵＲＬ：uniform resource locator）またはユニフォームリソース名（ＵＲＮ：uniform resource name）に関連付けられたファイルのヘッダを、そのＵＲＬまたはＵＲＮに関連付けられたペイロードを取り出すことなしに、取り出す。ＧＥＴ動作は、所与のＵＲＬまたはＵＲＮに関連付けられたファイル全体を取り出す。部分的ＧＥＴ動作は、入力パラメータとしてバイト範囲を受信し、およびファイルの連続数のバイトを取り出し、ここで、バイトの数は、受信されるバイト範囲に対応する。このことから、ムービーフラグメントは、部分的ＧＥＴ動作が１つまたは複数の個々のムービーフラグメントを得ることができることから、ＨＴＴＰストリーミングのために提供され得る。ムービーフラグメントでは、異なるトラックのいくつかのトラックフラグメント（track fragment）が存在することができる。ＨＴＴＰストリーミングでは、メディアプレゼンテーション（media presentation）は、クライアントにとってアクセス可能であるデータの構造化された集合であり得る。クライアントは、ユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。
【００２４】
[0031]  ＤＡＳＨは、ＩＳＯ／ＩＥＣ２３００９−１に規定されており、およびＨＴＴＰ（適応型）ストリーミングアプリケーションのための規格である。ＩＳＯ／ＩＥＣ２３００９−１は主に、マニフェストまたはマニフェストファイル（manifest file）としても知られるメディアプレゼンテーション記述（ＭＰＤ）のフォーマット、およびメディアセグメントフォーマットを指定する。ＭＰＤは、サーバ上で利用可能なメディアを記述し、およびＤＡＳＨクライアントが、適切なメディア時間において適切なメディアバージョンを自律的にダウンロードすることを可能にする。
【００２５】
[0032]  ＨＴＴＰストリーミングを使用して３ＧＰＰデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび／またはオーディオデータについての複数の表現（representation）が存在し得る。以下に説明されるように、異なる表現は、異なるコーディング特性（例えば、ビデオコーディング規格の異なるプロファイルまたはレベル）、異なるコーディング規格または（マルチビューおよび／またはスケーラブル拡張のような）コーディング規格の拡張、あるいは異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述（ＭＰＤ）データ構造で定義され得る。メディアプレゼンテーションは、ＨＴＴＰストリーミングクライアントデバイスにとってアクセス可能であるデータの構造化された集合に対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。メディアプレゼンテーションは、ＭＰＤデータ構造で記述され得、それは、ＭＰＤの更新を含み得る。
【００２６】
[0033]  メディアプレゼンテーションは、１つまたは複数の期間のシーケンスを包含し得る。各期間は、次の期間の開始まで、また最後の期間のケースではメディアプレゼンテーションの終了まで拡張し得る。各期間は、同じメディアコンテンツについての１つまたは複数の表現を包含し得る。表現は、オーディオ、ビデオ、時間指定されたテキスト、または他のそのようなデータのいくつかの代替の符号化されたバージョンのうちの１つであり得る。表現は、符号化タイプによって、例えば、ビデオデータについてのビットレート、解像度、および／またはコーデックと、オーディオデータについてのビットレート、言語、および／またはコーデックとによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、且つ特定の方法で符号化された、符号化されたオーディオまたはビデオデータのセクションを指すために使用され得る。
【００２７】
[0034]  特定の期間の表現は、それら表現が属する適合セットを示すＭＰＤ中の属性によって示されるグループに割り当てられ得る。同じ適合セット中の表現は概して、クライアントデバイスが、例えば、帯域幅適合を実行するためにこれらの表現間を動的およびシームレスに切り替えることができるという点において、互いに対して代替であると考えられる。例えば、特定の期間についてのビデオデータの各表現は、同じ適合セットに割り当てられ得、それにより、表現のうちの任意のものが、対応する期間についてのマルチメディアコンテンツの、ビデオデータまたはオーディオデータのようなメディアデータを提示するための復号のために選択され得る。１つの期間内のメディアコンテンツは、存在する場合には、グループ０からの１つの表現か、またはいくつかの例では、各非ゼログループからの多くとも１つの表現の組み合わせ、のいずれかによって表され得る。ある期間の各表現についてのタイミングデータは、その期間の開始時間に相対的に表され得る。
【００２８】
[0035]  表現は、１つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含み得る、または表現の各セグメントは、自己初期化し得る。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソース名（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ：uniform resource identifier）のような識別子によって一意に参照され得る。ＭＰＤは、各セグメントに対する識別子を提供し得る。いくつかの例では、ＭＰＤはまた、範囲属性の形態でバイト範囲を提供し得、それは、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能であるファイル内のセグメントについてのデータに対応し得る。
【００２９】
[0036]  異なる表現は、異なるタイプのメディアデータについての実質的に同時の取り出しのために選択され得る。例えば、クライアントデバイスは、それらからセグメントを取り出すためのオーディオ表現、ビデオ表現、および時間指定されたテキスト表現を選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適合を実行するための特定の適合セットを選択し得る。すなわち、クライアントデバイスは、ビデオ表現を含む適合セット、オーディオ表現を含む適合セット、および／または時間指定されたテキストを含む適合セットを選択し得る。代替として、クライアントデバイスは、ある特定のタイプのメディア（例えば、ビデオ）についての適合セットを選択し、および他のタイプのメディア（例えば、オーディオおよび／または時間指定されたテキスト）についての表現を直接選択し得る。
【００３０】
[0037]  ＤＡＳＨベースのＨＴＴＰストリーミングのための典型的なプロシージャは、以下のステップを含む：  
１）ＤＡＳＨクライアントは、ストリーミングコンテンツ、例えば、ムービー、のＭＰＤを取得する。ＭＰＤは、ストリーミングコンテンツの異なる代替の表現に関する情報、例えば、ビットレート、ビデオ解像度、フレームレート、オーディオ言語、ならびにＨＴＴＰリソース（初期化セグメントおよびメディアセグメント）のＵＲＬを含む。  
２）ＭＰＤ中の情報およびＤＡＳＨクライアントに利用可能なローカル情報、例えば、ネットワーク帯域幅（network bandwidth）、復号／表示能力、およびユーザ選好（user preference）に基づいて、ＤＡＳＨクライアントは、所望される表現（１つ以上）を一度に１セグメント（またはその一部）要求する。  
３）ＤＡＳＨクライアントがネットワーク帯域幅の変更を検出すると、それは、理想的にはランダムアクセスポイントで開始するセグメントから開始する、より良くマッチするビットレート（better-matching bitrate）を有する異なる表現のセグメントを要求する。
【００３１】
[0038]  ＨＴＴＰストリーミング「セッション」中に、過去の位置への後方にシーク（seek）すること、または将来の位置への前方にシークすることを求めるユーザ要求に応答するために、ＤＡＳＨクライアントは、所望される位置に近く且つ理想的にはランダムアクセスポイントで開始するセグメントから開始する過去または将来のセグメントを要求する。ユーザはまた、コンテンツを早送りすることを要求し得、それは、ビデオストリームの時間的サブセットのみを、またはイントラコーディングされたビデオピクチャのみを復号するのに十分なデータを要求することによって実現され得る。
【００３２】
[0039]  ＤＡＳＨ仕様書のセクション５．３．３．１は、次のように事前選択（Preselection）を説明している：
【００３３】
[0040]  事前選択の概念は、異なる適合セット中で提供されるオーディオ要素の適した組み合わせをシグナリングするために、次世代オーディオ（ＮＧＡ：Next Generation Audio）コーデックを目的として主に動機付けられる。しかしながら、事前選択の概念は、それが他のメディアタイプおよびコーデックのためにも拡張および使用されることができるような包括的な方式で導入される。
【００３４】
[0041]  各事前選択は、バンドル（bundle）に関連付けられる。バンドルは、単一の復号器インスタンス（single decoder instance）によって一緒に消費され得る要素のセットである。要素は、バンドルのアドレス可能および分離可能な要素であり、および事前選択の使用によって直接的にまたは間接的に、のいずれかで、アプリケーションによって動的に選択または非選択され得る。要素は、１対１マッピングまたは単一の適合セット中に複数の要素を含めることのいずれかによって、適合セットにマッピングされる。さらに、１つの適合セット中の表現は、エレメンタリストリームレベルで、またはファイルコンテナレベルで多重化される複数の要素を包含し得る。多重化のケースでは、各要素が、ＤＡＳＨセクション５．３．４に定義されているようなメディアコンテンツコンポーネントにマッピングされる。バンドル中の各要素はしたがって、メディアコンテンツコンポーネントの@idによって、または、単一の要素のみが適合セット中に包含されている場合には、適合セットの@idによって、識別および参照される。
【００３５】
[0042]  各バンドルは、復号器固有の情報を包含し、および復号器をブートストラップする主要素を含む。主要素を包含する適合セットは、主適合セットと呼ばれる。主要素は、バンドルに関連付けられたどの事前選択中にも常に含まれるべきである。加えて、各バンドルは、１つまたは複数の部分的適合セットを含み得る。部分的適合セットは、主適合セットと組み合わせてのみ処理され得る。
【００３６】
[0043]  事前選択は、一緒に消費されることを予期されるバンドル中の要素のサブセットを定義する。事前選択は、復号器に向けての一意のタグによって識別される。複数の事前選択インスタンスは、バンドル中のストリームの同じセットを参照することができる。同じバンドルの要素のみが、事前選択の復号およびレンダリングに寄与することができる。
【００３７】
[0044]  次世代オーディオのケースでは、事前選択は、完全なオーディオエクスペリエンスを作り出すために、利得、空間的ロケーションのような１つプラス追加のパラメータからの１つまたは複数のオーディオ要素に関連付けられたパーソナライゼーション（personalization）のオプションである。事前選択は、従来のオーディオコーデックを使用する完全なミックスを包含する代替のオーディオトラックのＮＧＡ同等物（NGA-equivalent）と見なされることができる。
【００３８】
[0045]  バンドル、事前選択、主要素、主適合セットおよび部分的適合セットは、２つの手段のうちの１つによって定義され得る：  
・事前選択記述子は、ＤＡＳＨセクション５．３．１１．２に定義されている。そのような記述子は、単純なセットアップおよび後方互換性を可能にするが、高度な使用ケースには適さないことがあり得る。  
・ＤＡＳＨセクション５．３．１１．３および５．３．１１．４に定義されているような事前選択要素。事前選択要素のセマンティクス（semantics）は、ＤＡＳＨセクション５．３．１１．３における表１７ｃに提供されており、ＸＭＬシンタックスは、ＤＡＳＨセクション５．３．１１．４に提供されている。
【００３９】
[0046]  両方の方法を使用する導入された概念のインスタンス化が、以下に提供される。
【００４０】
[0047]  両方のケースで、適合セットが主適合セットを含んでいない場合、必須記述子（the Essential descriptor）が、ＤＡＳＨセクション５．３．１１．２に定義されているような@schemeIdURIとともに使用されるべきである。
【００４１】
[0048]  ＤＡＳＨ仕様書はまた、次のように事前選択記述子を説明している：
【００４２】
[0049]  スキームが、「urn:mpeg:dash:preselection:2016」としての必須記述子とともに使用されるように定義される。その記述子の値は、コンマによって区切られた２つのフィールドを提供する：  
・事前選択のタグ  
・処理順序の空白で区切られたリストとしてのこの事前選択リストの包含された要素／コンテンツコンポーネントのＩＤ。第１のＩＤは、主要素を定義する。
【００４３】
[0050]  適合セットが主要素を含む場合、補足記述子（Supplemental descriptor）が、適合セット中の包含された事前選択を記述するために使用され得る。
【００４４】
[0051]  適合セットが主要素を包含しない場合、必須記述子が使用されるべきである。
【００４５】
[0052]  バンドルは、同じ主要素を含む全ての事前選択中に含まれる全ての要素によって本質的に定義される。事前選択は、事前選択中に含まれる要素の各々に割り当てられるメタデータによって定義される。このシグナリングは、基本的な使用ケースの場合は単純であり得るが、全ての使用ケースに対する完全なカバレッジを提供するわけではないことを予期されていることに留意されたい。したがって、事前選択要素は、より高度な使用ケースをカバーするために、ＤＡＳＨセクション５．３．１１．３に導入されている。
【００４６】
[0053]  ＤＡＳＨ仕様書はまた、次のように事前選択要素のセマンティクス（semantics）を説明している：
【００４７】
[0054]  事前選択記述子への拡張として、事前選択はまた、表１７ｄに提供されているような事前選択要素を通じて定義され得る。事前選択の選択は、事前選択要素中の包含された属性および要素に基づく。  
【表１】
2020526982.tif 000003
2020526982.tif 000004
2020526982.tif 000005
【００４８】
[0055]  フレームパッキング（Frame Packing）に関して、ＤＡＳＨのセクション５．８．４．６は、次のように事前選択を規定している：
【００４９】
[0056]  要素FramePackingの場合、@schemeIdUri属性が、用いられるフレームパッキング構成スキーム（frame-packing configuration scheme）を識別するために使用される。
【００５０】
[0057]  複数のFramePacking要素が存在し得る。存在する場合、各要素は、記述された表現を選択または拒否するのに十分な情報を包含するべきである。
【００５１】
[0058]  注記 全てのFramePacking要素についてのスキームまたは値が認識されない場合、ＤＡＳＨクライアントは、記述された表現を無視することを予期される。クライアントは、FramePacking要素を観測することに基づいて適合セットを拒否し得る。
【００５２】
[0059]  記述子は、ＩＳＯ／ＩＥＣ２３００１−８におけるVideoFramePackingTypeについて定義されたＵＲＮラベルおよび値を使用して、フレームパッキングスキームを搬送し得る。
【００５３】
[0060]  注記：ＩＳＯ／ＩＥＣ２３００９のこの部分はまた、ＤＡＳＨセクション５．８．５．６におけるフレームパッキングスキームを定義している。これらのスキームは、後方互換性のために維持されるが、ＩＳＯ／ＩＥＣ２３００１−８に定義されているようなシグナリングを使用することを推奨される。
【００５４】
[0061]  ビデオデータは、多様なビデオコーディング規格にしたがって符号化され得る。そのようなビデオコーディング規格は、ＩＴＵ−Ｔ Ｈ．２６１と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌと、ＩＴＵ−Ｔ Ｈ．２６３と、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌと、そのスケーラブルビデオコーディング（ＳＶＣ）およびマルチビュービデオコーディング（ＭＶＣ）拡張を含むＩＴＵ−Ｔ Ｈ．２６４またはＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣと、そのスケーラブルコーディング拡張（すなわち、スケーラブル高効率ビデオコーディング、ＳＨＶＣ）およびマルチビュー拡張（すなわち、マルチビュー高効率ビデオコーディング、ＭＶ−ＨＥＶＣ）を含む、ＩＴＵ−Ｔ Ｈ．２６５およびＩＳＯ／ＩＥＣ ２３００８−２としても知られる高効率ビデオコーディング（ＨＥＶＣ）とを含む。
【００５５】
[0062]  図１は、ネットワークを通してメディアデータをストリーミングするための技法をインプリメントする実例的なシステム１０を例示するブロック図である。この例では、システム１０は、コンテンツ準備デバイス（content preparation device）２０、サーバデバイス（server device）６０、およびクライアントデバイス（client device）４０を含む。クライアントデバイス４０およびサーバデバイス６０は、ネットワーク７４によって通信可能に結合され、それは、インターネットを備え得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０もまた、ネットワーク７４または別のネットワークによって結合され得るか、あるいは直接通信可能に結合され得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０は、同じデバイスを備え得る。
【００５６】
[0063]  図１の例におけるコンテンツ準備デバイス２０は、オーディオソース２２およびビデオソース２４を備える。オーディオソース２２は、例えば、オーディオ符号化器（audio encoder）２６によって符号化されることになるキャプチャされたオーディオデータを表す電気信号を生じさせるマイクロフォンを備え得る。代替として、オーディオソース２２は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース２４は、ビデオ符号化器（video encoder）２８によって符号化されることになるビデオデータを生じさせるビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス２０は、必ずしも全ての例においてサーバデバイス６０に通信可能に結合されるわけではなく、サーバデバイス６０によって読み取られる別個の媒体にマルチメディアコンテンツを記憶し得る。
【００５７】
[0064]  生オーディオおよびビデオデータ（Raw audio and video data）は、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオ符号化器２６および／またはビデオ符号化器２８によって符号化される前にデジタル化され得る。オーディオソース２２は、話す参加者から、その話す参加者が話している間にオーディオデータを取得し得、およびビデオソース２４は、その話す参加者のビデオデータを同時に取得し得る。他の例では、オーディオソース２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、およびビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、この開示に説明される技法は、ライブの、ストリーミングの、リアルタイムのオーディオおよびビデオデータに、またはアーカイブされ、事前に記録されたオーディオおよびビデオデータに適用され得る。
【００５８】
[0065]  ビデオフレームに対応するオーディオフレームは概して、ビデオフレーム内に包含される、ビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時にオーディオソース２２によってキャプチャされた（または生成された）オーディオデータを包含するオーディオフレームである。例えば、話す参加者が概して話すことによってオーディオデータを生じさせる間、オーディオソース２２は、オーディオデータをキャプチャし、およびビデオソース２４は、同時に、すなわち、オーディオソース２２がオーディオデータをキャプチャしている間に、その話す参加者のビデオデータをキャプチャする。故に、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。それ故に、ビデオフレームに対応するオーディオフレームは概して、オーディオデータとビデオデータとが同時にキャプチャされた状況に対応し、およびそれについて、オーディオフレームとビデオフレームとは、同時にキャプチャされたオーディオデータとビデオデータとをそれぞれ備える。
【００５９】
[0066]  いくつかの例では、オーディオ符号化器２６は、符号化されたオーディオフレームについてのオーディオデータが記録された時間を表す各符号化されたオーディオフレーム中のタイムスタンプを符号化し得、および同様に、ビデオ符号化器２８は、符号化されたビデオフレームについてのビデオデータが記録された時間を表す各符号化されたビデオフレーム中のタイムスタンプを符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ準備デバイス２０は、オーディオ符号化器２６および／またはビデオ符号化器２８がそれからタイムスタンプを生成し得る、あるいは、オーディオソース２２とビデオソース２４とが、オーディオデータとビデオデータとをそれぞれタイムスタンプに関連付けるために使用し得る、内部クロックを含み得る。
【００６０】
[0067]  いくつかの例では、オーディオソース２２は、オーディオデータが記録された時間に対応するデータをオーディオ符号化器２６に送り得、およびビデオソース２４は、ビデオデータが記録された時間に対応するデータをビデオ符号化器２８に送り得る。いくつかの例では、オーディオ符号化器２６は、符号化されたオーディオデータの相対時間的順序（relative temporal ordering）を示すために、しかしオーディオデータが記録された絶対時間を必ずしも示すことなしに、符号化されたオーディオデータ中のシーケンス識別子を符号化し得、および同様に、ビデオ符号化器２８もまた、符号化されたビデオデータの相対時間的順序を示すために、シーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、マッピングされ得るか、またはそうでない場合は、タイムスタンプと相関され得る。
【００６１】
[0068]  オーディオ符号化器２６は概して、符号化されたオーディオデータのストリームを生じさせ、その一方でビデオ符号化器２８は、符号化されたビデオデータのストリームを生じさせる。（オーディオであれビデオであれ）データの各個々のストリームは、エレメンタリストリーム（elementary stream）と呼ばれ得る。エレメンタリストリームは、表現の単一のデジタルにコーディングされた（ことによると圧縮された）コンポーネントである。例えば、表現のコーディングされたビデオまたはオーディオ部分は、エレメンタリストリームであることができる。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム（ＰＥＳ：packetized elementary stream）へとコンバートされ得る。同じ表現内で、ストリームＩＤは、ある１つのエレメンタリストリームに属するＰＥＳパケットを他のものと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム（ＰＥＳ）パケットである。このことから、コーディングされたビデオデータは概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、１つまたは複数のそれぞれのエレメンタリストリームに対応する。
【００６２】
[0069]  コンテンツ準備デバイス（Content preparation device）２０は、ビデオソース２４を使用して球面ビデオデータ（spherical video data）を、例えば、その球面ビデオデータをキャプチャおよび／または生成（例えば、レンダリング）することによって、取得し得る。球面ビデオデータはまた、投影されたビデオデータ（projected video data）と呼ばれ得る。コンテンツ準備デバイス２０は、符号化（encoding）、処理（processing）、およびトランスポート（transport）を容易にするために、投影されたビデオデータ（または球面ビデオデータ）からパッキングされたビデオデータを形成し得る。例が、以下の図３に示されている。この開示の技法にしたがって、ビデオデータの２つ以上のパッキングされた領域は、リージョンワイズパッキング情報によって示されるように、オーバーラップし得る。コンテンツ準備デバイス２０は、様々なパッキングされた領域の位置およびサイズを定義するリージョンワイズパッキングボックス（ＲＷＰＢ：a region-wise packing box）を生成し得、それはこのことから、２つ以上のパッキングされた領域間のオーバーラップを示し得る。ある１つのパッキングされた領域が別のパッキングされた領域とオーバーラップするとき、コンテンツ準備デバイス２０は、帯域幅消費、処理サイクル、メモリ消費、および同様のものを低減するために、オーバーラップされた領域についてのデータを１回よりも多く符号化および記憶／トランスポートすることを避け得る。クライアントデバイス４０は、ある１つのパッキングされた領域のオーバーラップされた一部分についてのデータを、そのオーバーラップされた一部分が提供およびコーディングされた別のパッキングされた領域から取り出し得る。
【００６３】
[0070]  ＩＴＵ Ｈ．２６４／ＡＶＣおよび今後の高効率ビデオコーディング（ＨＥＶＣ）規格のような多くのビデオコーディング規格は、誤りのないビットストリームのためのシンタックス（syntax）、セマンティクス（semantics）、および復号処理（decoding process）を定義し、それらのうちのいずれも、ある特定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は典型的に、符号化器を指定しないが、符号化器は、生成されるビットストリームが復号器に対して規格準拠（standard-compliant）であることを保証するタスクを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能（feature）、またはツールのサブセット、およびそれらに適用される制約に対応する。Ｈ．２６４規格によって定義されているように、例えば、「プロファイル」は、Ｈ．２６４規格によって指定されているビットストリームシンタックス全体のサブセットである。「レベル」は、例えば、復号器メモリおよび消費のような復号器リソース消費の制限に対応し、それらは、ピクチャの解像度、ビットレート、およびブロック処理レートに関連する。プロファイルは、profile_idc（プロファイルインジケータ）値でシグナリングされ得、その一方でレベルは、level_idc（レベルインジケータ）値でシグナリングされ得る。
【００６４】
[0071]  Ｈ．２６４規格は、例えば、所与のプロファイルのシンタックスによって課せられる限度（bound）内で、復号されたピクチャの指定されたサイズのような、ビットストリーム中のシンタックス要素によって取られる値に依存して、符号化器と復号器との性能において大きな変動を要求することは依然として可能であることを認識している。Ｈ．２６４規格はさらに、多くのアプリケーションで、特定のプロファル内のシンタックスの全ての仮定的な使用に対処することが可能である復号器をインプリメントすることは実用的でも経済的でもないことを認識している。それ故に、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に対して課せられる制約の指定されたセットとして「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。代替として、これらの制約は、値の算術的組み合わせ（例えば、ピクチャ幅にピクチャの高さ（height）を乗算したものに、毎秒復号されるピクチャの数を乗算したもの）に対する制約の形態を取り得る。Ｈ．２６４規格はさらに、個々のインプリメンテーションが各サポートされるプロファイルについて異なるレベルをサポートし得ることを規定する。
【００６５】
[0072]  プロファイルに準拠する復号器は通常、プロファイル中に定義された全ての機能をサポートする。例えば、コーディング機能として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイル中でサポートされていないが、Ｈ．２６４／ＡＶＣの他のプロファイル中でサポートされている。あるレベルに準拠する復号器は、そのレベル中で定義された制限を超えるリソースを必要としないあらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈可能性（interpretability）に役に立ち得る。例えば、ビデオ送信中に、プロファイルおよびレベル定義のペアが、送信セッション全体についてネゴシエートおよび同意され得る。より具体的には、Ｈ．２６４／ＡＶＣでは、レベルは、処理される必要があるマクロブロックの数、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）サイズ、コーディングピクチャバッファ（ＣＰＢ：coded picture buffer）サイズ、垂直動きベクトル範囲（vertical motion vector range）、２つの連続するＭＢあたりの動きベクトルの最大数、およびＢブロックが８ｘ８ピクセル未満のサブマクロブロック区分を有することができるかどうか、に対する制限を定義し得る。このように、復号器は、復号器がビットストリームを適正に復号することが可能であるかどうかを決定し得る。
【００６６】
[0073]  図１の例では、コンテンツ準備デバイス２０のカプセル化ユニット（encapsulation unit）３０は、ビデオ符号化器２８からのコーディングされたビデオデータを備えるエレメンタリストリームと、オーディオ符号化器２６からのコーディングされたオーディオデータを備えるエレメンタリストリームとを受信する。いくつかの例では、ビデオ符号化器２８およびオーディオ符号化器２６は各々、符号化されたデータからＰＥＳパケットを形成するためのパケタイザ（packetizer）を含み得る。他の例では、ビデオ符号化器２８およびオーディオ符号化器２６は各々、符号化されたデータからＰＥＳパケットを形成するためのそれぞれのパケタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化されたオーディオおよびビデオデータからＰＥＳパケットを形成するためのパケタイザを含み得る。
【００６７】
[0074]  ビデオ符号化器２８は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格についての様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（例えば、２次元または３次元再生のための）１つまたは複数のビューを有する表現、あるいは他のそのような特性のような様々な特性を有する、および様々なビットレートにおける、マルチメディアコンテンツの異なる表現を生じさせるために、多様な方法でマルチメディアコンテンツのビデオデータを符号化し得る。この開示に使用されているような表現は、オーディオデータ、ビデオデータ、（例えば、クローズドキャプションのための）テキストデータ、または他のそのようなデータのうちの１つを備え得る。表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームのようなエレメンタリストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するstream_idを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々な表現のビデオファイル（例えば、セグメント）へとアセンブルすることを担う。
【００６８】
[0075]  カプセル化ユニット３０は、オーディオ符号化器２６およびビデオ符号化器２８から表現のエレメンタリストリームについてのＰＥＳパケットを受信し、およびＰＥＳパケットから対応するネットワーク抽象化レイヤ（ＮＡＬ：network abstraction layer）ユニットを形成する。コーディングされたビデオセグメントは、ＮＡＬユニットへと編成され得、それは、ビデオ電話通信、記憶、ブロードキャスト、またはストリーミングのようなアプリケーションを扱う「ネットワークフレンドリーな」ビデオ表現を提供する。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ：Video Coding Layer）ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットにカテゴリ化されることができる。ＶＣＬユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および／またはスライスレベルのデータを含み得る。他のＮＡＬユニットは、非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では、プライマリのコーディングされたピクチャとして通常提示される１つの時間インスタンス中のコーディングされたピクチャは、アクセスユニット（access unit）中に包含され得、それは、１つまたは複数のＮＡＬユニットを含み得る。
【００６９】
[0076]  非ＶＣＬ ＮＡＬユニットは、中でもとりわけ、パラメータセットＮＡＬユニットおよびＳＥＩ ＮＡＬユニットを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ：sequence parameter set）中に）シーケンスレベルヘッダ情報、および（ピクチャパラメータセット（ＰＰＳ：picture parameter set）中に）まれに変化するピクチャレベルヘッダ情報を包含し得る。パラメータセット（例えば、ＰＰＳおよびＳＰＳ）では、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、故に、コーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信（out-of-band transmission）を可能にし得、誤り耐性のための冗長送信の必要性を避ける。帯域外送信の例では、パラメータセットＮＡＬユニットは、ＳＥＩ ＮＡＬユニットのような他のＮＡＬユニットとは異なるチャネル上で送信され得る。
【００７０】
[0077]  補足エンハンスメント情報（ＳＥＩ：Supplemental Enhancement Information）は、ＶＣＬ ＮＡＬユニットからのコーディングされたピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、誤り耐性、および他の目的に関連したプロセスを支援し得る。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニット中に包含され得る。ＳＥＩメッセージは、いくつかの規格仕様書（standard specification）の規範的部分であり、およびこのことから、規格準拠の復号器インプリメンテーションのために常に必須なわけではない。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージ（sequence level SEI message）またはピクチャレベルＳＥＩメッセージであり得る。何らかのシーケンスレベル情報が、ＳＶＣの例におけるスケーラビリティ情報ＳＥＩメッセージ、およびＭＶＣにおけるビュースケーラビリティ情報ＳＥＩメッセージのようなＳＥＩメッセージ中に包含され得る。これらの実例的なＳＥＩメッセージは、例えば、動作点の抽出および動作点の特性に関する情報を伝達し得る。加えて、カプセル化ユニット３０は、表現の特性を記述するメディアプレゼンテーション記述子（ＭＰＤ：a media presentation descriptor）のようなマニフェストファイルを形成し得る。カプセル化ユニット３０は、拡張可能マークアップ言語（ＸＭＬ：extensible markup language）にしたがってＭＰＤをフォーマットし得る。
【００７１】
[0078]  カプセル化ユニット３０は、出力インターフェース３２に、マニフェストファイル（例えば、ＭＰＤ）とともに、マルチメディアコンテンツの１つまたは複数の表現についてのデータを提供し得る。出力インターフェース３２は、ユニバーサルシリアルバス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライタまたはバーナ、磁気またはフラッシュ記憶媒体に対するインターフェース、あるいはメディアデータを記憶または送信するための他のインターフェースのような、記憶媒体に書き込むためのインターフェースまたはネットワークインターフェースを備え得る。カプセル化ユニット３０は、出力インターフェース３２にマルチメディアコンテンツの表現の各々のデータを提供し得、それは、ネットワーク送信または記憶媒体を介してサーバデバイス６０にデータを送り得る。図１の例では、サーバデバイス６０は、それぞれのマニフェストファイル６６と１つまたは複数の表現６８Ａ〜６８Ｎ（表現６８）とを各々が含む様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含む。いくつかの例では、出力インターフェース３２はまた、ネットワーク７４に直接データを送り得る。
【００７２】
[0079]  いくつかの例では、表現６８は、適合セットに分けられ得る。すなわち、表現６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、復号され、且つ、例えば、スピーカによって提示されるべきオーディオデータおよび／または表現とともに表示されるべきテキストの言語または他の特性を識別し得るテキストタイプ情報、適合セット中の表現についてのシーンの実世界カメラパースペクティブ（real-world camera perspective）またはカメラアングルを記述し得るカメラアングル情報、特定のオーディエンスに対するコンテンツ適性を記述するレーティング情報、または同様のもののような、特性のそれぞれの共通セットを含み得る。
【００７３】
[0080]  マニフェストファイル６６は、特定の適合セットに対応する表現６８のサブセット、ならびにその適合セットについての共通特性、を示すデータを含み得る。マニフェストファイル６６はまた、適合セットの個々の表現についての、ビットレートのような個々の特性を表すデータを含み得る。このように、適合セットは、簡略化されたネットワーク帯域幅適合を提供し得る。適合セット中の表現は、マニフェストファイル６６の適合セット要素の子要素を使用して示され得る。
【００７４】
[0081]  サーバデバイス６０は、要求処理ユニット７０とネットワークインターフェース７２とを含む。いくつかの例では、サーバデバイス６０は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス６０の機能のうちの任意のものまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上でインプリメントされ得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ６４のデータをキャッシュし得、およびサーバデバイス６０のものと実質的に一致するコンポーネントを含み得る。一般に、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送受信するように構成される。
【００７５】
[0082]  要求処理ユニット７０は、記憶媒体６２のデータを求めるネットワーク要求をクライアントデバイス４０のようなクライアントデバイスから受信するように構成される。例えば、要求処理ユニット７０は、RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” by R. Fielding et al, Network Working Group, IETF, June 1999に説明されているようなハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１をインプリメントし得る。すなわち、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を受信し、およびそれら要求に応答してマルチメディアコンテンツ６４のデータを提供するように構成され得る。それら要求は、例えば、セグメントのＵＲＬを使用して、表現６８のうちの１つのセグメントを指定し得る。いくつかの例では、それら要求はまた、セグメントの１つまたは複数のバイト範囲を指定し得、このことから、部分的ＧＥＴ要求を備える。要求処理ユニット７０はさらに、表現６８のうちの１つのセグメントのヘッダデータを提供するために、ＨＴＴＰ ＨＥＡＤ要求をサービスするように構成され得る。いずれのケースでも、要求処理ユニット７０は、クライアントデバイス４０のような要求しているデバイスに要求されたデータを提供するために、それら要求を処理するように構成され得る。
【００７６】
[0083]  加えてまたは代替として、要求処理ユニット７０は、ｅＭＢＭＳのようなブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス２０は、説明されたのと実質的に同じ方法でＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用してこれらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット７０は、クライアントデバイス４０からマルチキャストグループ参加要求（multicast group join request）を受信するように構成され得る。すなわち、サーバデバイス６０は、特定のメディアコンテンツ（例えば、ライブイベントのブロードキャスト）に関連付けられた、クライアントデバイス４０を含むクライアントデバイスに、マルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ）アドレスをアドバタイズし得る。クライアントデバイス４０は次に、マルチキャストグループに加わるための要求をサブミットし得る。この要求は、ネットワーク７４、例えば、ネットワーク７４を構成するルータ、の全体を通じて伝搬され得、それにより、それらルータは、クライアントデバイス４０のような加入しているクライアントデバイスに、マルチキャストグループに関連付けられたＩＰアドレスに宛てられたトラフィックを向けさせられる（caused to direct）。
【００７７】
[0084]  図１の例に例示されているように、マルチメディアコンテンツ６４は、マニフェストファイル６６を含み、それは、メディアプレゼンテーション記述（ＭＰＤ）に対応し得る。マニフェストファイル６６は、異なる代替の表現６８の記述を包含し得（例えば、異なる品質を有するビデオサービス）、および記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現６８の他の記述的特性を含み得る。クライアントデバイス４０は、表現６８のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを取り出し得る。
【００７８】
[0085]  特に、取り出しユニット５２は、ビデオ復号器（video decoder）４８の復号能力とビデオ出力４４のレンダリング能力とを決定するために、クライアントデバイス４０の構成データ（図示せず）を取り出し得る。構成データはまた、クライアントデバイス４０のユーザによって選択された言語選好、クライアントデバイス４０のユーザによって設定された奥行き選好（depth preferences）に対応する１つまたは複数のカメラパースペクティブ、および／またはクライアントデバイス４０のユーザによって選択されたレーティング選好のうちの任意のものまたは全てを含み得る。取り出しユニット５２は、例えば、ＨＴＴＰ ＧＥＴおよび部分的ＧＥＴ要求をサブミットするように構成されたメディアクライアントまたはウェブブラウザを備え得る。取り出しユニット５２は、クライアントデバイス４０の１つまたは複数のプロセッサあるいは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取り出しユニット５２に関して説明された機能のうちの全てまたは一部分は、ハードウェア、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組み合わせにおいてインプリメントされ得、ここで、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
【００７９】
[0086]  取り出しユニット５２は、クライアントデバイス４０の復号およびレンダリング能力を、マニフェストファイル６６の情報によって示される表現６８の特性と比較し得る。取り出しユニット５２は初めに、表現６８の特性を決定するために、マニフェストファイル６６の少なくとも一部分を取り出し得る。例えば、取り出しユニット５２は、１つまたは複数の適合セットの特性を記述するマニフェストファイル６６の一部分を要求し得る。取り出しユニット５２は、クライアントデバイス４０のコーディングおよびレンダリング能力によって満たされることができる特性を有する表現６８（例えば、適合セット）のサブセットを選択し得る。取り出しユニット５２はその後、適合セット中の表現についてのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、およびネットワーク帯域幅によって満たされることができるビットレートを有する表現のうちの１つからセグメントを取り出し得る。
【００８０】
[0087]  一般に、より高いビットレート表現（higher bitrate representation）は、より高品質のビデオ再生をもたらし得、その一方でより低いビットレート表現（lower bitrate representation）は、利用可能なネットワーク帯域幅が減少したときに十分な品質のビデオ再生を提供し得る。それ故に、利用可能なネットワーク帯域幅が比較的高いとき、取り出しユニット５２は、比較的高いビットレート表現からデータを取り出し得るのに対して、利用可能なネットワーク帯域幅が低いとき、取り出しユニット５２は、比較的低いビットレート表現からデータを取り出し得る。このように、クライアントデバイス４０は、ネットワーク７４の変化するネットワーク帯域幅の利用可能性に適合もしながら、ネットワーク７４を通してマルチメディアデータをストリーミングし得る。
【００８１】
[0088]  加えてまたは代替として、取り出しユニット５２は、ｅＭＢＭＳまたはＩＰマルチキャストのようなブロードキャストまたはマルチキャストネットワークプロトコルにしたがってデータを受信するように構成され得る。そのような例では、取り出しユニット５２は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加わるための要求をサブミットし得る。マルチキャストグループに加わった後に、取り出しユニット５２は、サーバデバイス６０またはコンテンツ準備デバイス２０に発行されるさらなる要求なしに、マルチキャストグループのデータを受信し得る。取り出しユニット５２は、例えば、再生を停止するために、または異なるマルチキャストグループにチャネルを変更するために、マルチキャストグループのデータがもはや必要とされないときに、マルチキャストグループを去るための要求をサブミットし得る。
【００８２】
[0089]  ネットワークインターフェース５４は、選択された表現のセグメントのデータを受信し、およびそれを取り出しユニット５２に提供し得、それは次に、非カプセル化ユニット（decapsulation unit）５０にそれらセグメントを提供し得る。非カプセル化ユニット５０は、構成要素ＰＥＳストリームへとビデオファイルの要素を非カプセル化し、符号化されたデータを取り出すためにそれらＰＥＳストリームを非パケット化（depacketize）し、および、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器（audio decoder）４６またはビデオ復号器４８のいずれかにその符号化されたデータを送り得る。オーディオ復号器４６は、符号化されたオーディオデータを復号し、およびオーディオ出力４２にその復号されたオーディオデータを送り、その一方でビデオ復号器４８は、符号化されたビデオデータを復号し、およびビデオ出力４４にその復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
【００８３】
[0090]  ビデオ符号化器２８、ビデオ復号器４８、オーディオ符号化器２６、オーディオ復号器４６、カプセル化ユニット３０、取り出しユニット５２、および非カプセル化ユニット５０は各々、適宜、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせのような、多様な適した処理回路のうちの任意のものとしてインプリメントされ得る。ビデオ符号化器２８およびビデオ復号器４８の各々は、１つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたビデオ符号化器／復号器（ＣＯＤＥＣ）の一部として統合され得る。同様に、オーディオ符号化器２６およびオーディオ復号器４６の各々は、１つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたＣＯＤＥＣの一部として統合され得る。ビデオ符号化器２８、ビデオ復号器４８、オーディオ符号化器２６、オーディオ復号器４６、カプセル化ユニット３０、取り出しユニット５２、および／または非カプセル化ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラ電話のようなワイヤレス通信デバイスを備え得る。
【００８４】
[0091]  クライアントデバイス４０、サーバデバイス６０、および／またはコンテンツ準備デバイス２０は、この開示の技法にしたがって動作するように構成され得る。例を目的として、この開示は、クライアントデバイス４０およびサーバデバイス６０に関するこれらの技法を説明している。しかしながら、コンテンツ準備デバイス２０が、サーバデバイス６０の代わりに（またはそれに加えて）、これらの技法を実行するように構成され得ることが理解されるべきである。
【００８５】
[0092]  カプセル化ユニット３０は、ＮＡＬユニットが属するプログラムを識別するヘッダ、ならびにペイロード、例えば、オーディオデータ、ビデオデータ、あるいはＮＡＬユニットが対応するトランスポートまたはプログラムストリームを記述するデータ、を備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは、１バイトのヘッダと変動するサイズのペイロードとを含む。そのペイロード中にビデオデータを含むＮＡＬユニットは、様々な粒度（granularity）レベルのビデオデータを備え得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を備え得る。カプセル化ユニット３０は、エレメンタリストリームのＰＥＳパケットの形状で、ビデオ符号化器２８から符号化されたビデオデータを受信し得る。カプセル化ユニット３０は、各エレメンタリストリームを対応するプログラムと関連付け得る。
【００８６】
[0093]  カプセル化ユニット３０はまた、複数のＮＡＬユニットからアクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのフレームに対応するオーディオデータが利用可能であるときにはそのようなオーディオデータ、を表すための１つまたは複数のＮＡＬユニットを備え得る。アクセスユニットは概して、１つの出力時間インスタンスについての全てのＮＡＬユニット、例えば、１つの時間インスタンスについての全てのオーディオおよびビデオデータ、を含む。例えば、各ビューが２０フレーム／秒（ｆｐｓ）のフレームレートを有する場合、各時間インスタンスは、０．０５秒の時間間隔に対応し得る。この時間間隔中に、同じアクセスユニット（同じ時間インスタンス）の全てのビューについての特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、１つの時間インスタンス中にコーディングされたピクチャを備え得、それは、プライマリのコーディングされたピクチャとして提示され得る。
【００８７】
[0094]  それ故に、アクセスユニットは、共通の時間的インスタンスの全てのオーディオおよびビデオフレーム、例えば、時間Ｘに対応する全てのビュー、を備え得る。この開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント（view component）」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューについての符号化されたピクチャ（またはフレーム）を備え得る。それ故に、アクセスユニットは、共通の時間的インスタンスの全てのビューコンポーネントを備えるものとして定義され得る。アクセスユニットの復号順序は、出力または表示順序とは必ずしも同じである必要はない。
【００８８】
[0095]  メディアプレゼンテーションは、メディアプレゼンテーション記述（ＭＰＤ）を含み得、それは、異なる代替の表現（例えば、異なる品質を有するビデオサービス）の記述を包含し、および記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。ＭＰＤは、マニフェストファイル６６のようなマニフェストファイルの一例である。クライアントデバイス４０は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを取り出し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス（ｍｏｏｆボックス）中にロケートされ得る。
【００８９】
[0096]  （例えば、ＭＰＤを備え得る）マニフェストファイル６６は、表現６８のセグメントの利用可能性をアドバタイズし得る。すなわち、ＭＰＤは、表現６８のうちの１つの第１のセグメントが利用可能になるウォールクロック時間（wall-clock time）を示す情報、ならびに表現６８内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス４０の取り出しユニット５２は、特定のセグメントに先行するセグメントの持続時間ならびに開始時間に基づいて、各セグメントがいつ利用可能になるかを決定し得る。
【００９０】
[0097]  カプセル化ユニット３０が受信されたデータに基づいてＮＡＬユニットおよび／またはアクセスユニットをビデオファイルへとアセンブルした後に、カプセル化ユニット３０は、出力のために出力インターフェース３２にそのビデオファイルを渡す。いくつかの例では、カプセル化ユニット３０は、クライアントデバイス４０に直接ビデオファイルを送るというよりはむしろ、出力インターフェース３２を介してリモートサーバにビデオファイルを送り得るか、またはビデオファイルをローカルに記憶し得る。出力インターフェース３２は、例えば、送信機、トランシーバ、例えば、光学ドライブ、磁気媒体ドライブ（例えば、フロッピー（登録商標）ドライブ）、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースのような、コンピュータ可読媒体にデータを書き込むためのデバイスを備え得る。出力インターフェース３２は、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体のようなコンピュータ可読媒体にビデオファイルを出力する。
【００９１】
[0098]  ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し、および取り出しユニット５２を介して非カプセル化ユニット５０にＮＡＬユニットまたはアクセスユニットを提供し得る。非カプセル化ユニット５０は、構成要素ＰＥＳストリームへとビデオファイルの要素を非カプセル化し、符号化されたデータを取り出すためにそれらＰＥＳストリームを非パケット化し、および、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器４６またはビデオ復号器４８のいずれかにその符号化されたデータを送り得る。オーディオ復号器４６は、符号化されたオーディオデータを復号し、およびオーディオ出力４２にその復号されたオーディオデータを送り、その一方でビデオ復号器４８は、符号化されたビデオデータを復号し、およびビデオ出力４４にその復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
【００９２】
[0099]  ＯＭＡＦドラフトテキストでは、パッキングされた領域をオーバーラップすることは、許容されていない。これは、１つのパッキングされた領域の、複数の投影された領域へのマッピングを許容しない。ＭＰＥＧ入力ドキュメントｍ４１５５８は、パッキングされた領域を、それらが立体視ビデオコンテンツの異なる構成要素ピクチャ（すなわち、異なるビュー）にマッピングする限り、オーバーラップすることを許容することを提案しており、それにより、１つのビューのうちのいくつかの領域の送信を、それらが他のビューからコピーされることができるときに、避けることが可能である。しかしながら、これは、立体視ビデオコンテンツのピクチャの１つのビュー内のいくつかの領域の送信を避けることと、平面視コンテンツの１つのピクチャ内のいくつかの領域の送信を避けることとの両方を許容しない。
【００９３】
[0100]  この開示の技法によると、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、コンテンツが立体視であるかまたは平面視であるかにかかわらず、パッキングされた領域をオーバーラップすることが許容されるように構成され得る。コンテンツが立体視であるとき、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、パッキングされた領域をオーバーラップすることが、それらオーバーラップする領域が異なる構成要素ピクチャにマッピングするかどうかにかかわらず、許容されるように構成され得る。
【００９４】
[0101]  コンテナファイルフォーマットおよびビデオビットストリームの両方について、これは、ＯＭＡＦドラフトテキストにおけるリージョンワイズパッキング（ＲＷＰ）ボックスのセマンティクスから、およびＪＣＴ−ＶＣドキュメントＪＣＴＶＣ−ＡＡ００２６における全方位リージョンワイズパッキングＳＥＩメッセージ（omnidirectional region-wise packing SEI message）のセマンティクスから、以下の制約を取り除くことによって達成される：  
packed_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]によって指定された長方形は、ｊが両端値を含む０〜ｉ−１の範囲中のどの値であっても、packed_reg_width[ j ]、packed_reg_height[ j ]、packed_reg_top[ j ]、およびpacked_reg_left[ j ]によって指定された長方形とオーバーラップしていないべきである。
【００９５】
[0102]  このことから、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、上記に示されているように制約されていないＲＷＰボックスを使用するように構成され得る。代わりに、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、パッキングされた領域をオーバーラップすることがこれらの状況において許容されるように構成され得る。このことから、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、これらの状況においてパッキングされた領域をオーバーラップする際にデータを処理するように構成され得る。
【００９６】
[0103]  さらに、コンテンツ準備デバイス２０および／またはサーバデバイス６０は、パッキングされた領域の境界を決定することと、それに応じてpacked_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]についての値を設定することとを行うように構成され得る。同様に、クライアントデバイス４０は、packed_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]の値からパッキングされた領域の境界（およびしたがって、サイズおよび位置）を決定し得る。これらの値を使用してパッキングされた領域の境界および位置を決定することによって、クライアントデバイス４０は、２つ以上のパッキングされた領域が少なくとも部分的にオーバーラップすると決定し、およびさらに、２つ以上のパッキングされた領域間のオーバーラップされた一部分の位置を決定し得る。さらに、クライアントデバイス４０は、２つのパッキングされた領域についてのpacked_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]の値を使用して、別のパッキングされた領域のオーバーラップされた一部分を充填（fill）するためのビデオデータをそれから取り出すためのパッキングされた領域を決定し得る。
【００９７】
[0104]  この開示はまた、メディアコンテンツ全体が複数の適合セット中で搬送されるとき、ＭＰＤ中のコンテンツ全体に対するコンテンツカバレッジをシグナリングするためのメカニズムが欠けていることを認識している。このことから、この開示の技法にしたがって、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、ＯＭＡＦにおけるコンテンツカバレッジ（ＣＣ：content coverage）記述子が適合セットレベルおよび事前選択レベル（Preselection level）で存在し得るように構成され得る。すなわち、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、適合セットレベルおよび／または事前選択レベルのいずれかまたは両方でＯＭＡＦのＣＣ記述子を処理するように構成され得る。ＣＣ記述子のロケーションは、カバレッジが（適合セット中にあるときに）ローカルであるか、または（事前選択中にあるときに）グローバルであるかを決定し得る。
【００９８】
[0105]  ＤＡＳＨ FramePacking要素は、ＩＳＯ／ＩＥＣ２３００１−８のQuincunxSamplingFlagを搬送しない。しかしながら、この開示は、このフラッグ（flag）が、各構成要素フレームの各色成分平面が五点形サンプリングされているかどうかをそれがシグナリングすることから、必要とされることを認識している。この情報は、フレームパッキングタイプに加えて、受信機がビデオコンテンツを適正にデフレームパッキングし、且つレンダリングするための能力を有しているかどうかの決定のために必要とされ得る。五点形サンプリング（Quincunx sampling）は概して、「チェッカーボード（checkerboard）」サンプリングと見なされ得、それにおいて、行の１つおきのサンプルおよび列の１つおきのサンプルは、異なるピクチャに属する。このことから、左目ピクチャに属するフレームの位置（ｘ，ｙ）におけるサンプルの場合、位置（ｘ−１，ｙ）、（ｘ＋１，ｙ）、（ｘ，ｙ＋１）、および（ｘ，ｙ−１）におけるサンプルは、右目ピクチャに属する（そのようなサンプルがそのフレームの境界内にあると想定する）。
【００９９】
[0106]  クライアントデバイス４０のようなクライアントデバイスは、クライアントデバイス４０が対応するメディアコンテンツをレンダリングすることが可能であるかどうかを決定するために、五点形サンプリングフラッグ（quincunx sampling flag）を使用し得る。例えば、ビデオ出力４４が五点形パッキングされたフレームをレンダリングすることが可能である場合、取り出しユニット５２は、クライアントデバイス４０が、五点形パッキングされていることを五点形サンプリングフラッグが示すメディアデータのフレームをレンダリングすることが可能であると決定し得る。その一方で、ビデオ出力４４が五点形パッキングされたフレームをレンダリングすることができない場合、取り出しユニット５２は、クライアントデバイス４０が、五点形パッキングされていることを五点形サンプリングフラッグが示すメディアデータのフレームをレンダリングすることができないと決定し、およびこのことから、五点形パッキングされていないことを五点形サンプリングフラッグが示す代替のメディアデータ（例えば、表現６８のうちの異なるもの）を選択し得る。
【０１００】
[0107]  それ故に、準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、コンマで区切られたフォーマットで、FramePacking要素の@valueがVideoFramePackingType値およびQuincunxSamplingFlag値の両方を搬送し得るように構成され得る。すなわち、準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０は、FramePacking要素の@valueを処理し得、それは、コンマによって区切られた値である、VideoFramePackingType値およびQuincunxSamplingFlag値の両方を処理することを含み得る。ＤＡＳＨ規格への提案された変更は、以下の通りである（イタリック体のテキストは、ＤＡＳＨの現在のバーションに対する追加を表す）：  
要素FramePackingの場合、@schemeIdUri属性が、用いられるフレームパッキング構成スキームを識別するために使用される。  
複数のFramePacking要素が存在し得る。存在する場合、各要素は、記述された表現を選択または拒否するのに十分な情報を包含するべきである。  
注記 全てのFramePacking要素についてのスキームまたは値が認識されない場合、ＤＡＳＨクライアントは、記述された表現を無視することを予期される。クライアントは、FramePacking要素を観測することに基づいて適合セットを拒否し得る。  
記述子は、ＩＳＯ／ＩＥＣ２３００１−８におけるコンマで区切られたVideoFramePackingTypeおよびQuincunxSamplingFlagについて定義されたＵＲＮラベルおよび値を使用して、フレームパッキングスキームを搬送し得る。  
注記：ＩＳＯ／ＩＥＣ２３００９のこの部分はまた、５．８．５．６におけるフレームパッキングスキームを定義している。これらのスキームは、後方互換性のために維持されるが、ＩＳＯ／ＩＥＣ２３００１−８に定義されているようなシグナリングを使用することを推奨される。
【０１０１】
[0108]  この開示の技法にしたがって、マニフェストファイル６６は、適合セットレベルまたは事前選択レベルでコンテンツカバレッジ記述子をシグナリングするデータを含み得る。マニフェストファイル６６は加えてまたは代替として、この開示の技法にしたがって領域をオーバーラップすることを定義するリージョンワイズパッキングボックスを含み得る。マニフェストファイル６６は加えてまたは代替として、コンマによって区切られた、ビデオフレームパッキングタイプ（VideoFramePackingType）値および五点形サンプリング値（QuincunxSamplingFlag）の両方を有するFramePacking要素を含み得、ここで、五点形サンプリング値は、１つまたは複数の対応するフレームが五点形（チェッカーボード）（quincunx (checkerboard)）パッキングされているかどうかを示し得る。
【０１０２】
[0109]  図２は、より詳細に図１の取り出しユニット５２のコンポーネントの実例的なセットをより例示するブロック図である。この例では、取り出しユニット５２は、ｅＭＢＭＳミドルウェアユニット１００、ＤＡＳＨクライアント１１０、およびメディアアプリケーション１１２を含む。
【０１０３】
[0110]  この例では、ｅＭＢＭＳミドルウェアユニット１００はさらに、ｅＭＢＭＳ受信ユニット１０６、キャッシュ１０４、およびプロキシサーバユニット（proxy server unit）１０２を含む。この例では、ｅＭＢＭＳ受信ユニット１０６は、例えば、tools.ietf.org/html/rfc6726において利用可能である、T. Paila et al., “FLUTE--File Delivery over Unidirectional Transport,” Network Working Group, RFC 6726, Nov. 2012に説明されている単方向トランスポートを通したファイル配信（ＦＬＵＴＥ：File Delivery over Unidirectional Transport）にしたがって、ｅＭＢＭＳを介してデータを受信するように構成される。すなわち、ｅＭＢＭＳ受信ユニット１０６は、例えば、ＢＭ−ＳＣとして機能し得るサーバデバイス６０から、ブロードキャストを介してファイルを受信し得る。
【０１０４】
[0111]  ｅＭＢＭＳミドルウェアユニット１００がファイルについてのデータを受信するとき、ｅＭＢＭＳミドルウェアユニットは、キャッシュ１０４中にその受信されたデータを記憶し得る。キャッシュ１０４は、フラッシュメモリ、ハードディスク、ＲＡＭ、または任意の他の適した記憶媒体のようなコンピュータ可読記憶媒体を備え得る。
【０１０５】
[0112]  プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０のためのサーバとして機能し得る。例えば、プロキシサーバユニット１０２は、ＤＡＳＨクライアント１１０にＭＰＤファイルまたは他のマニフェストファイルを提供し得る。プロキシサーバユニット１０２は、ＭＰＤファイル中のセグメントについての利用可能性時間（availability times）、ならびにそれらセグメントがそれから取り出されることができるハイパーリンクをアドバタイズし得る。これらのハイパーリンクは、クライアントデバイス４０に対応するローカルホストアドレスプレフィックスを含み得る（例えば、ＩＰｖ４についての１２７．０．０．１）。このように、ＤＡＳＨクライアント１１０は、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を使用して、プロキシサーバユニット１０２にセグメントを要求し得る。例えば、リンク127.0.0.1/rep1/seg3から利用可能なセグメントの場合、ＤＡＳＨクライアント１１０は、127.0.0.1/rep1/seg3を求める要求を含むＨＴＴＰ ＧＥＴ要求を構築し得、およびプロキシサーバユニット１０２にその要求をサブミットし得る。プロキシサーバユニット１０２は、そのような要求に応答して、キャッシュ１０４から要求されたデータを取り出し得、およびＤＡＳＨクライアント１１０にそのデータを提供し得る。
【０１０６】
[0113]  図３は、ＯＭＡＦのためのリージョンワイズパッキング（ＲＷＰ）の２つの例を例示する概念図である。ＯＭＡＦは、リージョンワイズパッキング（ＲＷＰ）と呼ばれるメカニズムを指定する。ＲＷＰは、投影されたピクチャの任意の長方形領域の操作（サイズ変更、再位置付け、回転、およびミラーリング）を可能にする。ＲＷＰは、特定のビューポートの向きを強調するか、またはＥＲＰにおいて極に向かってオーバーサンプリングするといったような投影の弱点を回避するために使用されることができる。後者は、図３の上部の例に図示されており、ここで、球面ビデオの極に近いエリアは、解像度が低減されている。図３の下部の例は、強調されたビューポートの向きを図示している。ＲＷＰに関する情報は、ＲＷＰボックス中でシグナリングされ、それは、次のように、ＯＭＡＦドラフトテキストの第７．２．５項に規定されている：
【０１０７】
[0114]  ２．５．１ リージョンワイズパッキングボックス（Region-wise packing box）
【０１０８】
[0115]  ２．５．１．１ 定義  
ボックスタイプ：「ｒｗｐｋ」
コンテナ：スキーム情報ボックス（「ｓｃｈｉ」）
必須：いいえ
量：０または１
【０１０９】
[0116]  RegionWisePackingBoxは、投影されたピクチャがリージョンワイズパッキングされており、およびレンダリングより前にアンパッキングを必要とすることを示す。投影されたピクチャのサイズは、このボックス中で明示的にシグナリングされる。パッキングされたピクチャのサイズは、それぞれ、PackedPicWidthおよびPackedPicHeightとして表されているVisualSampleEntryの幅シンタックス要素および高さシンタックス要素によって示される。
【０１１０】
[0117]  注記１：ピクチャがフレームピクチャの代わりにフィールドピクチャであるとき、パッキングされたピクチャの実際の高さは、PackedPicHeightの半分に過ぎないであろう。
【０１１１】
[0118]  ２．５．１．２ シンタックス（Syntax）  
aligned(8) class RegionWisePackingBox extends FullBox('rwpk', 0, 0) {
RegionWisePackingStruct();
}
aligned(8) class RegionWisePackingStruct {
unsigned int(8) num_regions;
unsigned int(16) proj_picture_width;
unsigned int(16) proj_picture_height;
for (i = 0; i < num_regions; i++) {
bit(3) reserved = 0;
unsigned int(1) guard_band_flag[i];
unsigned int(4) packing_type[i];
if (packing_type[i]== 0) {
RectRegionPacking(i);
if (guard_band_flag[i]) {
unsigned int(8) left_gb_width[i];
unsigned int(8) right_gb_width[i];
unsigned int(8) top_gb_height[i];
unsigned int(8) bottom_gb_height[i];
unsigned int(1) gb_not_used_for_pred_
flag[i];
unsigned int(3) gb_type[i];
bit(4) reserved = 0;
}
}
}
}
aligned(8) class RectRegionPacking(i) {
unsigned int(16) proj_reg_width[i];
unsigned int(16) proj_reg_height[i];
unsigned int(16) proj_reg_top[i];
unsigned int(16) proj_reg_left[i];
unsigned int(3)  transform_type[i];
bit(5) reserved = 0;
unsigned int(16) packed_reg_width[i];
unsigned int(16) packed_reg_height[i];
unsigned int(16) packed_reg_top[i];
unsigned int(16) packed_reg_left[i];
}
【０１１２】
[0119]  ２．５．１．３ セマンティクス（Semantics）
【０１１３】
[0120]  num_regionsは、パッキングされた領域の数を指定する。値０は、リザーブされる。
【０１１４】
[0121]  proj_picture_widthおよびproj_picture_heightは、ルーマサンプル（luma sample）の単位で、投影されたピクチャの幅および高さをそれぞれ指定する。proj_picture_widthおよびproj_picture_heightは両方とも、０より大きくあるべきである。
【０１１５】
[0122]  ０に等しいguard_band_flag[i]は、ｉ番目のパッキングされた領域がガードバンドを有していないことを指定する。１に等しいguard_band_flag[i]は、ｉ番目のパッキングされた領域がガードバンドを有していることを指定する。
【０１１６】
[0123]  packing_type[i]は、リージョンワイズパッキングのタイプを指定する。０に等しいpacking_type[i]は、長方形リージョンワイズパッキングを示す。他の値は、リザーブされる。
【０１１７】
[0124]  left_gb_width[i]は、２つのルーマサンプルの単位で、ｉ番目のパッキングされた領域の左側上のガードバンドの幅を指定する。
【０１１８】
[0125]  right_gb_width[i]は、２つのルーマサンプルの単位で、ｉ番目のパッキングされた領域の右側上のガードバンドの幅を指定する。
【０１１９】
[0126]  top_gb_height[i]は、２つのルーマサンプルの単位で、ｉ番目のパッキングされた領域の上部のガードバンドの高さを指定する。
【０１２０】
[0127]  bottom_gb_height[i]は、２つのルーマサンプルの単位で、ｉ番目のパッキングされた領域の下部のガードバンドの高さを指定する。
【０１２１】
[0128]  guard_band_flag[i]が１に等しいとき、left_gb_width[i]、right_gb_width[i]、top_gb_height[i]、またはbottom_gb_height[i]は、０より大きくあるべきである。
【０１２２】
[0129]  このRegionWisePackingStructによって指定されたようなｉ番目のパッキングされた領域は、同じRegionWisePackingStructによって指定された任意の他のパッキングされた領域または同じRegionWisePackingStructによって指定された任意のガードバンドとオーバーラップするべきではない。
【０１２３】
[0130]  このRegionWisePackingStructによって指定されたようなｉ番目のパッキングされた領域に関連付けられたガードバンドは、ある場合には、同じRegionWisePackingStructによって指定された任意のパッキングされた領域または同じRegionWisePackingStructによって指定された任意の他のガードバンドとオーバーラップするべきではない。
【０１２４】
[0131]  ０に等しいgb_not_used_for_pred_flag[i]は、ガードバンドがインター予測プロセスにおいて使用されることも使用されないこともあり得ることを指定する。１に等しいgb_not_used_for_pred_flag[i]は、ガードバンドのサンプル値がインター予測プロセスにないことを指定する。
【０１２５】
[0132]  注記１：gb_not_used_for_pred_flag[i]が１に等しいとき、復号されたピクチャ中のガードバンド内のサンプル値は、それら復号されたピクチャが復号されることになる後続のピクチャのインター予測のための参照として使用された場合であっても、書き換えられることができる。例えば、パッキングされた領域のコンテンツは、別のパッキングされた領域の復号され、且つ再投影されたサンプルで、そのガードバンドにシームレスに拡張されることができる。
【０１２６】
[0133]  gb_type[i]は、次のように、ｉ番目のパッキングされた領域についてのガードバンドのタイプを指定する：
【０１２７】
[0134]  ０に等しいgb_type[i]は、パッキングされた領域のコンテンツに対するガードバンドのコンテンツが指定されていないことを指定する。gb_not_used_for_pred_flagが０に等しいとき、gb_typeは、０に等しくあるべきではない。
【０１２８】
[0135]  １に等しいgb_type[i]は、ガードバンドのコンテンツがパッキングされた領域内のサブピクセル値の補間に十分であり、およびパッキングされた領域の境界から１ピクセル未満外側であることを指定する。
【０１２９】
[0136]  注記２：１に等しいgb_typeは、パッキングされた領域の境界サンプルがガードバンドに水平または垂直にコピーされているときに使用されることができる。
【０１３０】
[0137]  ２に等しいgb_type[i]は、ガードバンドのコンテンツがパッキングされた領域のピクチャ品質から球面状に隣接するパッキングされた領域のピクチャ品質に徐々に変化する品質で実際の画像コンテンツを表すことを指定する。
【０１３１】
[0138]  ３に等しいgb_type[i]は、ガードバンドのコンテンツがパッキングされた領域のピクチャ品質で実際の画像コンテンツを表すことを指定する。
【０１３２】
[0139]  ３より大きいgb_type[i]値は、リザーブされる。
【０１３３】
[0140]  proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]およびproj_reg_left[i]は、幅および高さがそれぞれproj_picture_widthおよびproj_picture_heightに等しい投影されたピクチャ中のルーマサンプルの単位で示される。
【０１３４】
[0141]  proj_reg_width[i]は、ｉ番目の投影された領域の幅を指定する。proj_reg_width[i]は、０より大きくあるべきである。
【０１３５】
[0142]  proj_reg_height[i]は、ｉ番目の投影された領域の高さを指定する。proj_reg_height[i]は、０より大きくあるべきである。
【０１３６】
[0143]  proj_reg_top[i]およびproj_reg_left[i]は、投影されたピクチャ中のｉ番目の投影された領域の上部ルーマサンプル行および最左ルーマサンプル列をそれぞれ指定する。値は、投影されたピクチャの左上角を示す０から、それぞれ、proj_picture_height−１まで（両端値を含む）、およびproj_picture_width−１まで（両端値を含む）の範囲内にあるべきである。
【０１３７】
[0144]  proj_reg_width[i]およびproj_reg_left[i]の合計は、proj_picture_width未満であるべきである。
【０１３８】
[0145]  proj_reg_height[i]およびproj_reg_top[i]の合計は、proj_picture_height未満であるべきである。
【０１３９】
[0146]  投影されたピクチャが立体視であるとき、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]およびproj_reg_left[i]は、これらのフィールドによって識別された投影された領域が投影されたピクチャの単一の構成要素ピクチャ内にあるようなものであるべきである。
【０１４０】
[0147]  transform_type[i]は、ｉ番目の投影された領域に適用されている回転およびミラーリングを、符号化前にパッキングされたピクチャにそれをマッピングするために指定する。transform_type[i]が回転およびミラーリングの両方を指定するとき、回転は、符号化前に投影されたピクチャからパッキングされたピクチャへのリージョンワイズパッキングにおいてミラーリングした後に適用されている。以下の値が指定される：  
０：変換なし  
１：水平にミラーリング  
２：１８０度の回転（反時計回り）  
３：水平にミラーリングした後に１８０度の回転（反時計回り）  
４：水平にミラーリングした後に９０度の回転（反時計回り）  
５：９０度の回転（反時計回り）  
６：水平にミラーリングした後に２７０度の回転（反時計回り）  
７：２７０度の回転（反時計回り）
【０１４１】
[0148]  注記３：第５．４項は、パッキングされたピクチャ中のパッキングされた領域のサンプルロケーションを投影されたピクチャ中の投影された領域のサンプルロケーションにコンバートするためのtransform_type[i]のセマンティクスを規定している。
【０１４２】
[0149]  packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]およびpacked_reg_left[i]は、幅（width）および高さが、それぞれPackedPicWidthおよびPackedPicHeightに等しいパッキングされたピクチャ中のルーマサンプルの単位で示される。
【０１４３】
[0150]  packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]、およびpacked_reg_left[i]は、パッキングされたピクチャ中のパッキングされた領域の幅、高さ、上部ルーマサンプル行および最左ルーマサンプル列をそれぞれ指定する。
【０１４４】
[0151]  packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]、およびpacked_reg_left[i]の値は、以下のように制約される：  
・packed_reg_width[i]およびpacked_reg_height[i]は両方とも、０より大きくあるべきである。  
・packed_reg_top[i]およびpacked_reg_left[i]は、パッキングされたピクチャの左上角ルーマサンプルを示す０から、それぞれ、PackedPicHeight−１まで（両端値を含む）、およびPackedPicWidth−１まで（両端値を含む）の範囲内にあるべきである。  
・packed_reg_width[i]およびpacked_reg_left[i]の合計は、PackedPicWidth未満であるべきである。  
・packed_reg_height[i]およびpacked_reg_top[i]の合計は、PackedPicHeight未満であるべきである。  
・packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]、およびpacked_reg_left[i]によって指定された長方形は、ｊが０〜ｉ−１の範囲（両端値を含む）内のどの値であっても、packed_reg_width[j]、packed_reg_height[j]、packed_reg_top[j]、およびpacked_reg_left[j]によって指定された長方形とオーバーラップしていないべきである。
【０１４５】
[0152]  図４は、実例的な投影された領域とガードバンドを有する対応するパッキングされた領域とを例示する概念図である。ＪＣＴ−ＶＣドキュメント
ＪＣＴＶＣ−ＡＡ００２６（phenix.int-evry.fr/jct/doc_end_user/documents/28_Torino/ wg11/JCTVC-AB0026-v3.zipから入手可能）は、例えば、ＨＥＶＣにしたがって、ビデオビットストリーム中でのＲＷＰ情報のシグナリングのための全方位リージョンワイズパッキングＳＥＩメッセージを含む。全方位リージョンワイズパッキングＳＥＩメッセージのシンタックスおよびセマンティクスは、以下の通りである。  
【表２】
2020526982.tif 000006
【０１４６】
[0153]  全方位リージョンワイズパッキングＳＥＩメッセージは、投影されたピクチャ上への出力復号されたピクチャの色サンプルの再マッピングを可能にするための情報を提供する。「投影されたピクチャ（projected picture）」および「パッキングされたピクチャ（packed picture）」の定義は、最新のＯＭＡＦドラフトテキストに定義されている通りである。ＪＣＴＶＣ−ＡＡ００２６は、上記のシンタックス要素についてのセマンティクスを以下のように定義している：
【０１４７】
[0154]  １に等しいomni_region_wise_packing_cancel_flagは、ＳＥＩメッセージが出力順序で任意の以前の全方位リージョンワイズパッキングＳＥＩメッセージの持続性を取り消すことを示す。０に等しいomni_region_wise_packing_cancel_flagは、全方位リージョンワイズパッキング情報が後続することを示す。
【０１４８】
[0155]  omni_region_wise_packing_persistence_flagは、現在のレイヤのための全方位リージョンワイズパッキングＳＥＩメッセージの持続性（persistence）を指定する。
【０１４９】
[0156]  ０に等しいomni_region_wise_packing_persistence_flagは、全方位リージョンワイズパッキングＳＥＩメッセージが現在の復号されたピクチャのみに適用されることを指定する。
【０１５０】
[0157]  picAが現在のピクチャであるとする。１に等しいomni_region_wise_packing_persistence_flagは、以下の条件のうちの１つまたは複数が真となるまで、全方位リージョンワイズパッキングＳＥＩメッセージが出力順序で現在のレイヤのために持続することを指定する：  
−現在のレイヤの新しいＣＬＶＳが始まる。  
−ビットストリームが終了する。  
−現在のレイヤに適用可能である全方位リージョンワイズパッキングＳＥＩメッセージを包含するアクセスユニット中の現在のレイヤ中のピクチャpicBは、picBについてのピクチャ順序カウントのための復号プロセスの呼び出し直後の、PicOrderCnt( picB )がPicOrderCnt( picA )より大きい出力であり、ここで、PicOrderCnt( picB )およびPicOrderCnt( picA ) は、それぞれpicBおよびpicAのPicOrderCntVal値である。
【０１５１】
[0158]  ０に等しいomni_projection_information_cancel_flagを有する全方位投影インジケーションＳＥＩメッセージ（omnidirectional projection indication SEI message）が現在のピクチャに適用されるＣＬＶＳにおいて存在せず、且つ復号順序で全方位リージョンワイズパッキングＳＥＩメッセージに先行するとき、０に等しいomni_region_wise_packing_persistence_flagを有する全方位リージョンワイズパッキングＳＥＩメッセージは、現在のピクチャに適用されるＣＬＶＳにおいて存在するべきではない。復号器は、現在のピクチャに適用されるＣＬＶＳにおいて０に等しいomni_projection_information_cancel_flagを有する全方位投影インジケーションＳＥＩメッセージに復号順序で後続しない、０に等しいomni_region_wise_packing_persistence_flagを有する全方位リージョンワイズパッキングＳＥＩメッセージを無視するべきである。
【０１５２】
[0159]  rwp_reserved_zero_6bitsは、この仕様のこのバージョンに準拠するビットストリーム中で０に等しくあるべきである。rwp_reserved_zero_6bits[ i ]についての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のためにリザーブされる。復号器は、rwp_reserved_zero_6bits[ i ]の値を無視するべきである。
【０１５３】
[0160]  num_packed_regionsは、パッキングされた領域の数を指定する。num_packed_regionsの値は、０より大きくあるべきである。
【０１５４】
[0161]  proj_picture_widthおよびproj_picture_heightは、投影されたピクチャの幅および高さをそれぞれ指定する。proj_picture_widthおよびproj_picture_heightの値は両方とも、０より大きくあるべきである。
【０１５５】
[0162]  rwp_reserved_zero_4bitsは、この仕様のこのバージョンに準拠するビットストリーム中で０に等しくあるべきである。rwp_reserved_zero_4bits[ i ]についての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のためにリザーブされる。復号器は、rwp_reserved_zero_4bits[ i ]の値を無視するべきである。
【０１５６】
[0163]  packing_type[ i ]は、リージョンワイズパッキングのタイプを指定する。０に等しいpacking_type[ i ]は、長方形リージョンワイズパッキングを示す。他の値は、リザーブされる。packing_type[ i ]の値は、この仕様のこのバーションで０に等しくあるべきである。復号器は、iがどの値であっても、０より大きいpacking_type[ i ]の値を許容するべきであり、および０より大きいpacking_type[ i ]を有する全ての全方位リージョンワイズパッキングＳＥＩメッセージを無視するべきである。
【０１５７】
[0164]  proj_reg_width[ i ]、proj_reg_height[ i ]、proj_reg_top[ i ]、およびproj_reg_left[ i ]は、幅および高さがそれぞれproj_picture_widthおよびproj_picture_heightに等しい投影されたピクチャ中のルーマサンプルの単位で示される。
【０１５８】
[0165]  proj_reg_width[ i ]は、ｉ番目の投影された領域の幅を指定する。proj_reg_width[ i ]は、０より大きくあるべきである。
【０１５９】
[0166]  proj_reg_height[ i ]は、ｉ番目の投影された領域の高さを指定する。proj_reg_height[ i ]は、０より大きくあるべきである。
【０１６０】
[0167]  proj_reg_top[ i ]およびproj_reg_left[ i ]は、投影されたピクチャ中の上部ルーマサンプル行および最左ルーマサンプル列をそれぞれ指定する。proj_reg_top[ i ]およびproj_reg_left[ i ]の値は、投影されたピクチャの左上角を示す、両端値を含む０から、それぞれ両端値を含むproj_picture_height−１および両端値を含むproj_picture_width−１までの範囲中にあるべきである。
【０１６１】
[0168]  合計proj_reg_width[ i ]およびproj_reg_left[ i ]は、proj_picture_width未満であるべきである。proj_reg_height[ i ]およびproj_reg_top[ i ]の合計は、proj_picture_height未満であるべきである。
【０１６２】
[0169]  投影されたピクチャが立体視であるとき、proj_reg_width[ i ]、proj_reg_height[ i ]、proj_reg_top[ i ]およびproj_reg_left[ i ]は、これらのフィールドによって識別された投影された領域が投影されたピクチャの単一の構成要素ピクチャ内にあるようなものであるべきである。
【０１６３】
[0170]  transform_type[ i ]は、ｉ番目の投影された領域に適用されている回転およびミラーリングを、符号化前にパッキングされたピクチャにそれをマッピングするために指定する。transform_type[ i ]が回転およびミラーリングの両方を指定するとき、回転は、符号化前に投影されたピクチャからパッキングされたピクチャへのリージョンワイズパッキングにおいてミラーリングした後に適用されている。transform_type[ i ]の値は、以下の表に指定されている：  
【表３】
2020526982.tif 000007
【０１６４】
[0171]  rwp_reserved_zero_5bitsは、この仕様のこのバージョンに準拠するビットストリーム中で０に等しくあるべきである。rwp_reserved_zero_5bits[ i ]についての他の値は、ＩＴＵ−Ｔ｜ＩＳＯ／ＩＥＣによる将来の使用のためにリザーブされる。復号器は、rwp_reserved_zero_5bits[ i ]の値を無視するべきである。
【０１６５】
[0172]  packed_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]は、パッキングされたピクチャ中のパッキングされた領域の幅、高さ、上部ルーマサンプル行および最左ルーマサンプル列をそれぞれ指定する。
【０１６６】
[0173]  packedPicWidthおよびpackedPicHeightを、パッキングされたピクチャの幅および高さとし、それは、適合性クロッピングウィンドウ（the conformance cropping window）と同じサイズを有する。packed_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]の値は、以下のように制約される：  
・packed_reg_width[ i ]およびpacked_reg_height[ i ]は両方とも、０より大きくあるべきである。  
・packed_reg_top[ i ]およびpacked_reg_left[ i ]の値は、パッキングされたピクチャの左上角ルーマサンプルを示す、０から、それぞれ、packedPicHeight−１まで（両端値を含む）、およびpackedPicWidth−１まで（両端値を含む）の範囲内にあるべきである。  
・packed_reg_width[ i ]およびpacked_reg_left[ i ]の合計は、packedPicWidth未満であるべきである。  
・packed_reg_height[ i ]およびpacked_reg_top[ i ]の合計は、packedPicHeight未満であるべきである。  
・packed_reg_width[ i ]、packed_reg_height[ i ]、packed_reg_top[ i ]、およびpacked_reg_left[ i ]によって指定された長方形は、ｊが０〜ｉ−１の範囲（両端値を含む）内のどの値であっても、packed_reg_width[ j ]、packed_reg_height[ j ]、packed_reg_top[ j ]、およびpacked_reg_left[ j ]によって指定された長方形とオーバーラップしていないべきである。
【０１６７】
[0174]  ＯＭＡＦはまた、コンテンツカバレッジシグナリングを説明している。ＯＭＡＦドラフトテキストの第７．２．７項は、グローバルカバレッジ情報ボックス（global coverage information box）を規定している。このボックスは、コンテンツ全体によってカバーされた球面上のエリアに関する情報を提供する。このトラックがサブピクチャ合成トラックグループ（sub-picture composition track group）に属する場合、コンテンツ全体が、同じサブピクチャ合成トラックグループに属する全てのトラックによって表されたコンテンツを参照し、およびこれらのトラックから合成された合成ピクチャは、コンテンツ全体のパッキングされたピクチャと呼ばれる。そうでない場合は、コンテンツ全体が、このトラック自体によって表されたコンテンツを参照し、およびこのトラック中のサンプルのピクチャは、コンテンツ全体のパッキングされたピクチャと呼ばれる。
【０１６８】
[0175]  ＯＭＡＦドラフトテキストの第７．２．７項は、トラックカバレッジ情報ボックス（track coverage information box）を規定している。このボックスは、このトラックによって表されたコンテンツによってカバーされた球面上のエリアに関する情報を提供する。
【０１６９】
[0176]  ＯＭＡＦドラフトテキストの第８．２．３項は、次のようにコンテンツカバレッジ（ＣＣ）記述子を規定している：  
「urn:mpeg:omaf:cc:2017」に等しい@schemeIdUri属性を有するコンテンツカバレッジ（ＣＣ）SupplementalProperty要素は、適合セットレベルで（すなわち、AdaptationSet要素中に直接）存在し得、および他のレベルでは存在するべきではない（すなわち、ＭＰＤレベルで、またはいかなる表現要素中にも直接存在するべきではない）。「urn:mpeg:omaf:cc:2017」に等しい@schemeIdUriを有するＣＣ記述子の@valueは、以下の表に指定されているような値のコンマで区切られたリストである。ＣＣ記述子は、各表現がＣＣ記述子中に含まれるようなSphereRegionStruct中のshape_typeおよびシンタックス要素center_yaw、center_pitch、center_roll、hor_range、およびver_rangeによって、第７．４項に規定されているような球面領域をカバーする。  
【表４】
2020526982.tif 000008
【０１７０】
[0177]  ＣＣ記述子の不在は、ＲＦ記述子が表現中または包含適合セット中のいずれかに存在するときに各表現が球面全体をカバーすることを示す。
【０１７１】
[0178]  図５は、実例的なマルチメディアコンテンツ１２０の要素を例示する概念図である。マルチメディアコンテンツ１２０は、マルチメディアコンテンツ６４（図１）、または記憶媒体６２中に記憶された別のマルチメディアコンテンツに対応し得る。図５の例では、マルチメディアコンテンツ１２０は、メディアプレゼンテーション記述（ＭＰＤ）１２２と複数の表現１２４Ａ〜１２４Ｎ（表現１２４）とを含む。表現１２４Ａは、オプションのヘッダデータ１２６とセグメント１２８Ａ〜１２８Ｎ（セグメント１２８）とを含み、その一方で表現１２４Ｎは、オプションのヘッダデータ１３０とセグメント１３２Ａ〜１３２Ｎ（セグメント１３２）とを含む。Ｎの文字は、便宜上、表現１２４の各々中の最後のムービーフラグメントを指定するために使用されている。いくつかの例では、表現１２４間に異なる数のムービーフラグメントが存在し得る。
【０１７２】
[0179]  ＭＰＤ１２２は、表現１２４とは別個のデータ構造を備え得る。ＭＰＤ１２２は、図１のマニフェストファイル６６に対応し得る。同様に、表現１２４は、図２の表現６８に対応し得る。一般に、ＭＰＤ１２２は、コーディングおよびレンダリング特性、適合セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（例えば、時間的サブシーケンスを含む表現を示す情報）、および／または（例えば、再生中におけるメディアコンテンツへのターゲット広告の挿入のための）リモート期間を取り出すための情報のような、表現１２４の特性を概して記述するデータを含み得る。
【０１７３】
[0180]  ヘッダデータ１２６は、存在するとき、セグメント１２８の特性、例えば、ランダムアクセスポイント（ＲＡＰ、ストリームアクセスポイント（ＳＡＰ： stream access point）とも呼ばれる）の時間的ロケーションを記述し得、セグメント１２８のそれは、ランダムアクセスポイント、セグメント１２８内のランダムアクセスポイントへのバイトオフセット、セグメント１２８のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１２８の他の態様を含む。ヘッダデータ１３０は、存在するとき、セグメント１３２についての同様の特性を記述し得る。加えてまたは代替として、そのような特性は、ＭＰＤ１２２内に完全に含まれ得る。
【０１７４】
[0181]  セグメント１２８、１３２は、１つまたは複数のコーディングされたビデオサンプルを含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント１２８のコーディングされたビデオサンプルの各々は、同様の特性、例えば、高さ、幅、および帯域幅要件を有し得る。そのような特定は、ＭＰＤ１２２のデータによって記述され得るが、そのようなデータは、図５の例には例示されていない。ＭＰＤ１２２は、この開示に説明されるシグナリングされる情報のうちの任意のものまたは全てを追加して、３ＧＰＰ仕様書によって説明されるような特性を含み得る。
【０１７５】
[0182]  セグメント１２８、１３２の各々は、一意のユニフォームリソースロケータ（ＵＲＬ）に関連付けられ得る。このことから、セグメント１２８、１３２の各々は、ＤＡＳＨのようなストリーミングネットワークプロトコルを使用して、独立して取り出し可能であり得る。このように、クライアントデバイス４０のような宛先デバイスは、セグメント１２８または１３２を取り出すために、ＨＴＴＰ ＧＥＴ要求を使用し得る。いくつかの例では、クライアントデバイス４０は、セグメント１２８または１３２の特定のバイト範囲を取り出すために、ＨＴＴＰ部分的ＧＥＴ要求を使用し得る。
【０１７６】
[0183]  この開示の技法にしたがって、ＭＰＤ１２２は、適合セットレベルまたは事前選択レベルでコンテンツカバレッジ記述子をシグナリングするデータを含み得る。ＭＰＤ１２２は加えてまたは代替として、この開示の技法にしたがって領域をオーバーラップすることを定義するリージョンワイズパッキングボックスを含み得る。ＭＰＤ１２２は加えてまたは代替として、コンマによって区切られた、ビデオフレームパッキングタイプ（VideoFramePackingType）値および五点形サンプリング値（QuincunxSamplingFlag）の両方を有するFramePacking要素を含み得、ここで、五点形サンプリング値は、１つまたは複数の対応するフレームが五点形（チェッカーボード）パッキングされているかどうかを示し得る。
【０１７７】
[0184]  図６は、実例的なビデオファイル１５０の要素を例示するブロック図であり、それは、図５のセグメント１２８、１３２のうちの１つのような、表現のセグメントに対応し得る。セグメント１２８、１３２の各々は、図６の例に例示されているデータの配列に実質的に一致するデータを含み得る。ビデオファイル１５０は、セグメントをカプセル化すると言われ得る。上述されたように、ＩＳＯベースメディアファイルフォーマットおよびその拡張にしたがったビデオファイルは、「ボックス（box）」と呼ばれる一連のオブジェクト中にデータを記憶する。図６の例では、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２、ムービー（ＭＯＯＶ）ボックス１５４、セグメントインデックス（ｓｉｄｘ）ボックス１６２、ムービーフラグメント（ＭＯＯＦ）ボックス１６４、およびムービーフラグメントランダムアクセス（ＭＦＲＡ：movie fragment random access）ボックス１６６を含む。図６は、ビデオファイルの例を表しているが、他のメディアファイルが、ＩＳＯベースメディアファイルフォーマットおよびその拡張にしたがった、ビデオファイル１５０のデータと同様に構造化された他のタイプのメディアデータ（例えば、オーディオデータ、時間指定されたテキストデータ、または同様のもの）を含み得ることが理解されるべきである。
【０１７８】
[0185]  ファイルタイプ（ＦＴＹＰ）ボックス１５２は概して、ビデオファイル１５０についてのファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０についての最良の使用を記述する仕様書を識別するデータを含み得る。ファイルタイプボックス１５２は代替として、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に配置され得る。
【０１７９】
[0186]  いくつかの例では、ビデオファイル１５０のようなセグメントは、ＦＴＹＰボックス１５２の前にＭＰＤ更新ボックス（MPD update box）（図示せず）を含み得る。ＭＰＤ更新ボックスは、ビデオファイル１５０を含む表現に対応するＭＰＤが更新されるべきであることを示す情報を、そのＭＰＤを更新するための情報とともに、含み得る。例えば、ＭＰＤ更新ボックスは、ＭＰＤを更新するために使用されるべきリソースについてのＵＲＩまたはＵＲＬを提供し得る。別の例として、ＭＰＤ更新ボックスは、ＭＰＤを更新するためのデータを含み得る。いくつかの例では、ＭＰＤ更新ボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示せず）の直後に後続し得、ここで、ＳＴＹＰボックスは、ビデオファイル１５０についてのセグメントタイプを定義し得る。以下により詳細に論述される図７は、ＭＰＤ更新ボックスに関する追加の情報を提供する。
【０１８０】
[0187]  ＭＯＯＶボックス１５４は、図６の例では、ムービーヘッダ（ＭＶＨＤ）ボックス１５６、トラック（ＴＲＡＫ）ボックス１５８、および１つまたは複数のムービー拡張（ＭＶＥＸ）ボックス１６０を含む。一般に、ＭＶＨＤボックス１５６は、ビデオファイル１５０の一般の特性を記述し得る。例えば、ＭＶＨＤボックス１５６は、いつビデオファイル１５０が当初に作成されたか、いつビデオファイル１５０が最後に修正されたか、ビデオファイル１５０についての時間スケール、ビデオファイル１５０についての再生の持続時間、またはビデオファイル１５０を概して記述する他のデータ、を記述するデータを含み得る。
【０１８１】
[0188]  ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックについてのデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を記述するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例では、ＴＲＡＫボックス１５８は、コーディングされたビデオピクチャを含み得、その一方で他の例では、トラックのコーディングされたビデオピクチャは、ムービーフラグメント１６４中に含まれ得、それは、ＴＲＡＫボックス１５８および／またはｓｉｄｘボックス１６２のデータによって参照され得る。
【０１８２】
[0189]  いくつかの例では、ビデオファイル１５０は、１つより多くのトラックを含み得る。それ故に、ＭＯＯＶボックス１５４は、ビデオファイル１５０中のトラックの数に等しいいくつかのＴＲＡＫボックスを含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。例えば、ＴＲＡＫボックス１５８は、対応するトラックについての時間的および／または空間的情報を記述し得る。ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様なＴＲＡＫボックスは、カプセル化ユニット３０（図５）がビデオファイル１５０のようなビデオファイル中にパラメータセットトラックを含めるときに、パラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットトラックを記述するＴＲＡＫボックス内で、パラメータセットトラック中のシーケンスレベルＳＥＩメッセージの存在をシグナリングし得る。
【０１８３】
[0190]  ＭＶＥＸボックス１６０は、例えば、ある場合には、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、ビデオファイル１５０がムービーフラグメント１６４を含むことをシグナリングするために、対応するムービーフラグメント１６４の特性を記述し得る。ビデオデータをストリーミングすることのコンテキストでは、コーディングされたビデオピクチャは、ＭＯＯＶボックス１５４中というよりはむしろムービーフラグメント１６４中に含まれ得る。それ故に、全てのコーディングされたビデオサンプルは、ＭＯＯＶボックス１５４中というよりはむしろ、ムービーフラグメント１６４中に含まれ得る。
【０１８４】
[0191]  ＭＯＯＶボックス１５４は、ビデオファイル１５０中のムービーフラグメント１６４の数に等しいいくつかのＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６４のうちの対応するものの特性を記述し得る。例えば、各ＭＶＥＸボックスは、ムービーフラグメント１６４のうちの対応するものについての時間的持続時間（temporal duration）を記述するムービー拡張ヘッダボックス（ＭＥＨＤ：movie extends header）ボックスを含み得る。
【０１８５】
[0192]  上述されたように、カプセル化ユニット３０は、実際のコーディングされたビデオデータを含まないビデオサンプル中にシーケンスデータセットを記憶し得る。ビデオサンプルは概して、アクセスニットに対応し得、それは、特定の時間インスタンスにおけるコーディングされたピクチャの表現である。ＡＶＣのコンテキストでは、コーディングされたピクチャは、アクセスユニットの全てのピクセルを構築するための情報を包含する１つまたは複数のＶＣＬ ＮＡＬユニットと、ＳＥＩメッセージのような他の関連する非ＶＣＬ ＮＡＬユニットとを含む。それ故に、カプセル化ユニット３０は、ムービーフラグメント１６４のうちの１つ中にシーケンスデータセットを含め得、それは、シーケンスレベルＳＥＩメッセージを含み得る。カプセル化ユニット３０はさらに、ムービーフラグメント１６４のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内で、ムービーフラグメント１６４のうちの１つ中に存在するものとして、シーケンスレベルＳＥＩメッセージおよび／またはシーケンスデータセットの存在をシグナリングし得る。
【０１８６】
[0193]  ＳＩＤＸボックス１６２は、ビデオファイル１５０のオプションの要素である。すなわち、３ＧＰＰファイルフォーマット、または他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもＳＩＤＸボックス１６２を含むわけではない。３ＧＰＰファイルフォーマットの例にしたがって、ＳＩＤＸボックスは、セグメント（例えば、ビデオファイル１５０内に包含されるセグメント）のサブセグメントを識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを、「対応するメディアデータボックス（１つ以上）を有する１つまたは複数の連続するムービーフラグメントボックスの内蔵された（self-contained）セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスは、そのムービーフラグメントボックスに後続し、および同じトラックについての情報を包含する次のムービーフラグメントボックスに先行しなければならない」と定義している。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが、「ボックスによってドキュメントされる（サブ）セグメントのサブセグメントへの参照のシーケンスを包含する。参照されるサブセグメントは、提示時間において連続している。同様に、セグメントインデックスボックスによって参照されるバイトは常に、セグメント内で連続している。参照されるサイズは、参照されるマテリアル中のバイトの数のカウントを示す（gives）」ことを示す。
【０１８７】
[0194]  ＳＩＤＸボックス１６２は概して、ビデオファイル１５０中に含まれるセグメントの１つまたは複数のサブセグメントを表す情報を提供する。例えば、そのような情報は、サブセグメントが始まるおよび／または終了する再生時間、サブセグメントについてのバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（例えば、それから開始する）かどうか、ＳＡＰについてのタイプ（例えば、ＳＡＰが瞬時復号器リフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャ、クリーンランダムアクセス（ＣＲＡ：clean random access）ピクチャ、ブロークンリンクアクセス（ＢＬＡ：broken link access）ピクチャ、または同様のものであるか）、サブセグメント中の（再生時間および／またはバイトオフセットの観点からの）ＳＡＰの位置、および同様のもの、を含み得る。
【０１８８】
[0195]  ムービーフラグメント１６４は、１つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント１６４は、１つまたは複数のピクチャのグループ（ＧＯＰ：group of pictures）を含み得、それらの各々は、いくつかのコーディングされたビデオピクチャ、例えば、フレームまたはピクチャを含み得る。加えて、上述されたように、ムービーフラグメント１６４は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント１６４の各々は、ムービーフラグメントヘッダボックス（ＭＦＨＤ、図６には図示せず）を含み得る。ＭＦＨＤボックスは、ムービーフラグメントについてのシーケンス番号のような、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント１６４は、ビデオファイル１５０中にシーケンス番号の順序で含まれ得る。
【０１８９】
[0196]  ＭＦＲＡボックス１６６は、ビデオファイル１５０のムービーフラグメント１６４内のランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０によってカプセル化されたセグメント内の特定の時間的ロケーション（すなわち、再生時間）に対してシークを実行するといったような、トリックモードを実行することを支援し得る。ＭＦＲＡボックス１６６は概してオプションであり、およびいくつかの例では、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス４０のようなクライアントデバイスは、ビデオファイル１５０のビデオデータを正しく復号および表示するために、必ずしもＭＦＲＡボックス１６６を参照する必要はない。ＭＦＲＡボックス１６６は、ビデオファイル１５０のトラックの数に等しいか、またはいくつかの例では、ビデオファイル１５０のメディアトラック（例えば、非ヒントトラック）の数に等しい、いくつかのトラックフラグメントランダムアクセス（ＴＦＲＡ：track fragment random access）ボックス（図示せず）を含み得る。
【０１９０】
[0197]  いくつかの例では、ムービーフラグメント１６４は、ＩＤＲピクチャのような１つまたは複数のストリームアクセスポイント（ＳＡＰ）を含み得る。同様に、ＭＦＲＡボックス１６６は、ＳＡＰのビデオファイル１５０内のロケーションのインジケーションを提供し得る。それ故に、ビデオファイル１５０の時間的サブシーケンスは、ビデオファイル１５０のＳＡＰから形成され得る。時間的サブシーケンスはまた、ＳＡＰに従属する（depend from）Ｂフレームおよび／またはＰフレームのような他のピクチャを含み得る。時間的サブシーケンスのフレームおよび／またはスライスは、サブシーケンスの他のフレーム／スライスに依存する時間的サブシーケンスのフレーム／スライスが適正に復号されることができるように、セグメント内に配列され得る。例えば、データの階層的配列では、他のデータについての予測のために使用されるデータもまた、時間的サブシーケンス中に含まれ得る。
【０１９１】
[0198]  この開示の技法にしたがって、ビデオファイル１５０はさらに、例えば、ＭＯＯＶボックス１５４内に、上述されたような情報を含むリージョンワイズパッキングボックス（ＲＷＰＢ）を含み得る。ＲＷＰＢは、パッキングされた領域のロケーション、および球面ビデオ投影における対応する投影された領域を定義するＲＷＰＢ構造体（RWPB struct）を含み得る。この開示の技法にしたがって、ＲＷＰＢのデータは、パッキングされた領域がオーバーラップすることを示し得る。このように、クライアントデバイス４０のようなクライアントデバイスは、ＲＷＰＢ情報を使用し、ある１つのパッキングされた領域のデータを再使用し、別のパッキングされた領域のオーバーラップされた一部分を充填し得る。
【０１９２】
[0199]  図７は、この開示の技法にしたがった、ビデオデータを生成する実例的な方法を例示するフローチャートである。一般に、図７の方法は、コンテンツ準備デバイス２０（図１）に関して論述される。しかしながら、サーバデバイス６０のような他のデバイスがこのまたは同様の方法を実行するように構成され得ることは理解されるべきである。
【０１９３】
[0200]  初めに、コンテンツ準備デバイスは、ビデオソース２４からビデオデータを含むメディアコンテンツを受信する。ビデオデータは、例えば、ＶＲ、拡張現実、または同様のものにおいて使用するための球面ビデオデータを表し得る。このことから、コンテンツ準備デバイス２０は、メディアコンテンツの第１の投影された領域を決定し得る（２００）。第１の投影された領域は、図３に示されているもののような、球面データ（spherical data）の一部分に対応し得る。
【０１９４】
[0201]  コンテンツ準備デバイス２０はその後、第１の投影された領域から第１のパッキングされた領域を形成し得る（２０４）。例えば、コンテンツ準備デバイス２０は、第１のパッキングされた領域を形成するために、第１の投影された領域の水平および／または垂直寸法に沿ってデシメーション（decimation）を実行し得る。コンテンツ準備デバイス２０はその後、ビデオ符号化器２８に第１のパッキングされた領域を符号化することを行わせるために、ビデオ符号化器２８に第１のパッキングされた領域を提供し得る（２０６）。
【０１９５】
[0202]  コンテンツ準備デバイス２０はその後、受信されたメディアコンテンツから第２の投影された領域を決定し得る（２０６）。コンテンツ準備デバイス２０は、第２の投影された領域から第２のパッキングされた領域を形成し得る（２０８）。例えば、コンテンツ準備デバイス２０は、第２のパッキングされた領域を形成するために、第２の投影された領域の水平および／または垂直寸法に沿ってデシメーションを実行し得る。このケースでは、コンテンツ準備デバイス２０はさらに、第１のパッキングされた領域と第２のパッキングされた領域との間にオーバーラップが存在すると決定する（２１０）。このことから、コンテンツ準備デバイス２０は、ビデオ符号化器２８に第２のパッキングされた領域を符号化することを行わせるために、ビデオ符号化器２８に第２のパッキングされた領域のオーバーラップしていない一部分を提供し、第１のパッキングされた領域とのオーバーラップを除外する（２１２）。
【０１９６】
[0203]  加えて、コンテンツ準備デバイス２０は、第１および第２のパッキングされた領域の位置を定義する、上述されたようなリージョンワイズパッキングボックス（ＲＷＰＢ）を符号化し得る（２１４）。このように、クライアントデバイス４０のようなクライアントデバイスは、第１のパッキングされた領域の対応するオーバーラップされた一部分から第２のパッキングされた領域のオーバーラップされた一部分についてのデータを抽出するために、ＲＷＰＢ情報を使用し得る。このことから、コンテンツ準備デバイス２０は、オーバーラップされた一部分を再符号化することを避け得、それにより、オーバーラップされた一部分を処理、符号化、およびトランスポートすることに関連付けられた記憶、処理、およびネットワーク帯域幅を節約する。
【０１９７】
[0204]  図８は、この開示の技法にしたがった、ビデオデータを受信および処理する実例的な方法を例示するフローチャートである。一般に、図８の方法は、クライアントデバイス４０（図１）に関して論述される。しかしながら、他のデバイスが、この方法または類似の方法を実行するように構成され得ることは理解されるべきである。
【０１９８】
[0205]  初めに、クライアントデバイス４０は、メディアコンテンツのビデオデータを復号し得る。クライアントデバイス４０はその後、メディアコンテンツの復号されたビデオデータの第１のパッキングされた領域を決定し得る（２５０）。例えば、クライアントデバイス４０は、メディアコンテンツの復号されたビデオデータの第１のパッキングされた領域および第２のパッキングされた領域の位置を表す、上述されたような情報を含むリージョンワイズパッキングボックス（ＲＷＰＢ）を受信し得る。
【０１９９】
[0206]  クライアントデバイス４０はその後、第１のパッキングされた領域をアンパッキングし（２５２）、および第１のアンパッキングされた領域から第１の投影された領域を形成し得る（２５４）。例えば、クライアントデバイス４０は、第１の投影された領域を形成するために第１のパッキングされた領域のデータを補完し、その後ＲＷＰＢ情報にしたがって第１の投影された領域を再位置付けし得る。
【０２００】
[0207]  クライアントデバイス４０はその後、メディアコンテンツの復号されたビデオデータの第２のパッキングされた領域を決定し得る（２５６）。ＲＷＰＢ情報の位置情報を使用して、例えば、クライアントデバイス４０は、第２のパッキングされた領域が第１のパッキングされた領域とオーバーラップすると決定し得る（２５８）。このことから、クライアントデバイス４０は、第１のパッキングされた領域のデータで第２のパッキングされた領域のオーバーラップされた一部分を充填するために、第１のパッキングされた領域の対応するオーバーラップされた一部分のビデオデータを取り出し得る（２６０）。
【０２０１】
[0208]  クライアントデバイス４０はその後、第２のパッキングされた領域をアンパッキングし（２６２）、および第２のアンパッキングされた領域から第２の投影された領域を形成し得る（２６４）。例えば、クライアントデバイス４０は、第２の投影された領域を形成するために第２のパッキングされた領域のデータを補完し、その後ＲＷＰＢ情報にしたがって第２の投影された領域を再位置付けし得る。
【０２０２】
[0209]  このような、図８の方法は、メディアコンテンツの第１のパッキングされた領域を処理することと、ここにおいて、第１のパッキングされた領域を処理することは、第１のアンパッキングされた領域を作り出すために、第１のパッキングされた領域をアンパッキングすることと、第１のアンパッキングされた領域から第１の投影された領域を形成することとを備える、メディアコンテンツの第２のパッキングされた領域を処理することと、第２のパッキングされた領域は、少なくとも部分的に第１のパッキングされた領域とオーバーラップし、ここにおいて、第２のパッキングされた領域を処理することは、第２のアンパッキングされた領域を作り出すために、第２のパッキングされた領域をアンパッキングすることと、第２のアンパッキングされた領域から第２の投影された領域を形成することとを備え、第２の投影された領域は、第１の投影された領域とは異なる、を含む方法の例を表す。
【０２０３】
[0210]  １つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせにおいてインプリメントされ得る。ソフトウェアにおいてインプリメントされる場合、それら機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得るか、またはコンピュータ可読媒体を通して送信され得、およびハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルにしたがって、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む通信媒体、またはコンピュータ可読記憶媒体を含み得、それは、データ記憶媒体のような有形媒体に対応する。このように、コンピュータ可読媒体は概して、（１）非一時的である有形コンピュータ可読記憶媒体（tangible computer-readable storage media）、あるいは（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、この開示に説明された技法のインプリメンテーションのための命令、コード、および／またはデータ構造を取り出すために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされることができる任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【０２０４】
[0211]  限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいはデータ構造もしくは命令の形態で所望されるプログラムコードを記憶するために使用されることができ、且つコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ可読媒体と称される。例えば、命令が、ウェブサイト、サーバ、あるいは同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：digital subscriber line）、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用する他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義中に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象にすることが理解されるべきである。ディスク（disk）およびディスク（disc）は、ここに使用される場合、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピーディスク（disk）、およびＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ここで、ディスク（disk）は通常、磁気的にデータを再生し、その一方でディスク（disc）は、レーザーを用いて光学的にデータを再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
【０２０５】
[0212]  命令は、１つまたは複数のデジタルシグナルプロセッサ(ＤＳＰ)、汎用マイクロプロセッサ、特定用途向け集積回路(ＡＳＩＣ)、フィールドプログラマブルロジックアレイ(ＦＰＧＡ)、あるいは他の同等な集積またはディスクリートロジック回路のような１つまたは複数のプロセッサによって実行され得る。それ故に、「プロセッサ（processor）」という用語は、ここに使用される場合、前述の構造のうちの任意のものまたはここに説明された技法のインプリメンテーションに適した任意の他の構造を指し得る。加えて、いくつかの態様では、ここに説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内で提供され得るか、あるいは組み合わされたコーデック中に組み込まれ得る。また、それら技法は、１つまたは複数の回路またはロジック要素において十分にインプリメントされることができる。
【０２０６】
[0213]  この開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い多様なデバイスまたは装置においてインプリメントされ得る。様々なコンポーネント、モジュール、またはユニットは、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するためにこの開示に説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上述されたように、様々なユニットは、コーデックハードウェアユニット中で組み合わされ得るか、あるいは、適したソフトウェアおよび／またはファームウェアと併せて、上述されたような１つまたは複数のプロセッサを含む、相互運用ハードウェアユニットの集合によって提供され得る。
【０２０７】
[0214]  様々な例が説明されてきた。これらおよび他の例は、次の特許請求の範囲内にある。
【図１】
2020526982.tif 000009
【図２】
2020526982.tif 000010
【図３】
2020526982.tif 000011
【図４】
2020526982.tif 000012
【図５】
2020526982.tif 000013
【図６】
2020526982.tif 000014
【図７】
2020526982.tif 000015
【図８】
2020526982.tif 000016
【国際調査報告】
2020526982.tif 000017
2020526982.tif 000018