8Kファイルフォーマットの動向と標準化への取り組み

２．１　AVI

AVIは，Windows OSで主に用いられる動画コンテナフォーマット¹⁾ で，RIFF（Resource Interchange File Format）形式^*4 をとっており，1図に示すようなチャンクと呼ばれる単位で構成される。チャンクは，内部にさらにチャンクあるいはサブチャンクを含むことができる。

1図に示すように，AVIチャンクは，４文字のID，チャンクサイズ，データ形式を表す４文字のFourCC，チャンクデータで構成される。また，AVIサブチャンクは，データ形式を表す４文字のFourCC，チャンクサイズ，チャンクデータで構成される。

AVIファイルの基本構造を2図に示す。AVIファイルを構成するチャンクには，RIFFチャンクとLISTチャンクの２種類がある。RIFFチャンクはAVIファイルの基本チャンクであり，LISTチャンクはRIFFチャンク内のデータを格納するチャンクである。AVIファイルはRIFFチャンクを数珠つなぎにしたような構造となっている。RIFFチャンクには，LIST（hdrl）チャンク，JUNKサブチャンク，LIST（movi）チャンク，Idx1サブチャンクなどが含まれる。

LIST（hdrl）チャンクは，映像および音声のヘッダー情報を保有し，avihサブチャンクと，映像・音声などのストリームと同じ数のLIST（strl）チャンクを含む。avihサブチャンクには，AVIファイル全体に関する情報が格納される。またLIST（strl）チャンクには，ヘッダチャンク，フォーマットチャンク，オプションデータチャンクの３つのサブチャンクが含まれる。ヘッダチャンク，フォーマットチャンク，オプションデータチャンクには，それぞれストリーム情報，ストリーム構造，必須でないオプション情報が格納される。

JUNKサブチャンクは，データの境界を2,048Byte単位にするためのダミーデータである。

LIST（movi）チャンクには，映像・音声の実データが入る。

Idx1サブチャンクには，映像・音声データへアクセスするためのIndex情報（アドレス情報）が記載される。

RIFFチャンクのサイズは，４バイトの符号なし整数で規定される。１つのRIFFチャンクのサイズがこの整数値の上限より小さい２GB以内となるように，AVIファイルが分割されて記録される。

２．２　MOV

MOVファイルは，ISO/IEC 14496 part 12²⁾ で「ISO Base Media File Format」として標準化されている。主にMac OSで用いられるQuicktime形式^3)*5 のファイルフォーマットであり，3図に示すようなatomと呼ばれる基本単位で構成される。atomの最初の４バイトはatomサイズを示し，次の４バイトは４文字のatomタイプを示す。９バイト目以降はデータであり，データのサイズはatomサイズから８バイトを引いた値となる。atomは入れ子構造にすることが可能であり，通常は，いくつかのatomが束ねられた構造が用いられる。

MOVファイルの基本構造を4図に示す。MOVファイルは，ファイルタイプを表すatom，データを格納するmovie data atom，動画の構造を定義するmovie atomから構成される。

データを格納するmovie data atomのサイズは，長尺のコンテンツや4K/8Kのような高精細映像のコンテンツでは，４バイトの符号なし整数で定義できるサイズを超えてしまうため，８バイトのLong型符号なし整数でサイズを定義するオプションが用意されている。movie data atomには，フレーム単位やGOP（Group of Pictures）単位で符号化された映像などのデータが格納される。データの格納単位をチャンクと呼び，１フレームまたは数フレームのデータを１つのチャンクに格納する。音声についても，１フレームあるいは複数フレームのデータをチャンクに格納する。また，時間を表すデータなどもチャンクとして格納される。5図に示すように，通常，movie data atomにはデータチャンクが時系列で格納される。個々のチャンクには，異なる数のデータが入っても構わない。チャンクごとのデータサンプル数（フレーム数など）はsample to chunk atom（6図参照）にテーブルの形で保存される。

movie atomの基本構造を6図に示す。movie atomには，movie data atomのデータにアクセスするためのテーブルデータや，映像・音声の解像度やビット深度などを表すデータが格納されている。movie atomは，ファイル中に必ず１つは存在し，6図に示すように，movie header atom（ストリームのヘッダー情報を格納），track atom（ストリームのトラック構造を表す），media atom（映像，音声などのメディアタイプなどを表す），media information atom（メディア構造を表す），sample table atom（サンプルサイズやオフセットアドレスなどのサンプル構造を格納する）などから構成される。

6図のsample table atomには，以下に示すようなテーブルデータが格納されている。time to sample atom：映像・音声の各サンプルにおけるサンプリング間隔を定義する。sample size atom：サンプルサイズ（各サンプルのデータのサイズ）を定義する。sample to chunk atom：各チャンクに含まれるサンプル数を定義する。chunk offset atom： MOVファイル中の，各チャンクのオフセット位置（ファイル先頭から各チャンク先頭へのオフセット値）を定義する。

これらのテーブルを基に，映像・音声データにアクセスすることができる。

２．３　MP4

MP4は，ISO/IEC 14496のpart 14⁴⁾ として，MOVファイル形式を拡張する形で標準化されたファイルフォーマットである。現在，パソコンやインターネットなどで標準的に用いられているフォーマットであり，MOVファイルのatomをboxと言い換えている。MOVファイルと互換性のあるファイル形式となっている。

２．４　MXF

MXF（Material eXchange Format）は，放送用のファイル交換などを想定したファイルフォーマットであり，SMPTE（Society of Motion Picture and Television Engineers）で標準化されている。MXFの規格は，ファイル構造を規定するSMPTE 377-1，エッセンス（映像・音声・データ）コンテナを規定するSMPTE 379-1とSMPTE 379-2，および各種のマッピング（各圧縮方式ごとのプロファイル^*6 などを示す）の規定などによって構成される⁵⁾⁶⁾。MXFは放送用ファイルフォーマットの標準として策定されているため，放送の素材収録（カメラやレコーダー）から送出に至るまでの幅広い用途で活用されている。

MXFファイルは，7図に示すようなKLV（Key Length Value）形式を単位として構成されている。7図のKey部分は，SMPTEで規定されたユニバーサルラベル（識別のための固有のラベル）であり，Value部分に格納されるデータが何であるかを示す。Length部分は，Value部分に格納されるデータのサイズを示す。Length部分の最初のバイトの８ビット目が０の場合は，そのバイトの第１～第７ビットがデータサイズを表す。最初のバイトの８ビット目が１の場合は，そのバイトの第１～第７ビットはデータサイズを格納する領域のバイト数を表し，２バイト目以降がデータサイズの値を表す。Value部分には，Key部分で示された内容，Length部分で示されたサイズのデータが格納される。

MXFファイルの基本構造を8図に示す。MXFファイルは，ファイルヘッダー，ファイルボディー，ファイルフッターから成る。ファイルヘッダーは，ヘッダー構造などを格納したHeader Partition Packと，一連のメタデータを格納したHeader Metadataから成る。ファイルボディーは，映像・音声・データなどが格納された０個または１個以上のEssence Containerを含む。ファイルフッターは，ヘッダー構造などが格納されたFooter Partition Packを含む。

Header Metadataに格納されるメタデータには，画像サイズやビットレート，時間軸上のフレーム位置など，映像ファイルの構造を規定するStructural Metadataと，シーンや登場人物など，コンテンツの内容を記述するDescriptive Metadataの２種類がある。

また，MXFファイルでは，含まれるクリップ（映像などの素材）の数などにより，ファイルの複雑さのレベルを表す「オペレーショナルパターン」が規定されている。最もシンプルなオペレーショナルパターンであるOP-1aは，１つのストリームに映像と音声がインターリーブされた構成である。最も複雑なOP-3cまで，９つのオペレーショナルパターンが規定されている。このほかに，映像と音声を別々にラッピングする構成のOPATOMとよばれるオペレーショナルパターンも規定されている。

３．１　DNxHR

Avid社が編集用として定めた圧縮方式で，SMPTEでVC-3として標準化され⁷⁾，AVI，MXFなどの動画コンテナフォーマットで利用されている。JPEG（JointPhotographic Experts Group）方式と同様に，DCT（Discrete Cosine Transform）をベースにした圧縮方式であり，ソフトウェア処理を高速に行えるような構成となっている。4:2:0，4:2:2，4:4:4^*7，アルファチャンネル^*8 などの画素構造に対応し，画質に応じていくつかのビットレートが選択できる。ビット深度については12bitまで，解像度については，1フレーム当たりのライン数，および1ライン当たりのサンプル数が，それぞれ16,384まで選択可能となっている。

DNxHRでは，画像を16×16画素のマクロブロックに分割して符号化を行う。符号化されたデータの構成は，最初にヘッダー情報があり，次にマクロブロックの符号化データが順に並び，最後に４バイトのEOF（End of File）でフレームの終了を示す。ヘッダーには，各マクロブロックラインの開始オフセットアドレスが記載されており，マクロブロックラインごとの並列処理が可能となっている。

３．２　ProRes

Apple社が編集用として開発した圧縮方式で，SMPTE RDD 36⁸⁾ として標準化されており，MOV，MP4，MXFなどの動画コンテナフォーマットで広く利用されている。DNxHRと同様にDCTベースの圧縮方式であり，ソフトウェアによる高速処理が可能である。扱える画像フォーマットは，画素構造についてはアルファチャンネルを含む4:2:2および4:4:4，色差信号についてはYCbCrおよびRGBとなっている。ビットレートについても，用途に応じていくつかの値を選択できる。解像度については，フレーム当たりのライン数，およびライン当たりのサンプル数を，２バイトの符号なし整数で規定できる。

カメラのRAW収録^*9 に対応したProRes RAWが2018年に追加され，用途が拡大されている。プロファイルについては8K解像度まで規定されており，ProRes RAWを含め，8Kに完全に対応している。

ProRes においてもDNxHRと同様に，16×16画素のマクロブロック単位で符号化が行われるが，ProResでは，8×1個のマクロブロックで構成されたスライスという単位を規定し，スライスごとの圧縮データがコンテナに格納される。

ProResのスライスには，9図に示すように，slice header，Y data，Cb data，Cr dataの順にデータが格納される。9図のACは符号化ブロック中の空間周波数のAC成分を，DCはDC成分を表す。ストリームの先頭にあるProResヘッダーには，各スライスの先頭へアクセスするためのオフセットアドレスが格納され，スライス単位での並列処理が可能となっている。Y data，Cb data，Cr dataには，DCTの周波数ごとに，スライス内の符号化ブロックのデータが格納される。これにより，デコードを適当な周波数で打ち切ることで縮小画像を高速に出力できる「スケーラブルデコード」が可能となっている。

３．３　HEVC

HEVC⁹⁾ は，国際標準となっている最新の圧縮方式であり，8Kまでの解像度に対応し，MOV，MP4などの動画コンテナフォーマットで利用されている。HEVCでは，編集用の圧縮方式にはない高度な予測技術やフィルターが採用され，高画質を保ちつつ，より低ビットレートとなる符号化を実現できる。Intra圧縮^*10 とともにInter圧縮^*11 が可能であり，Inter圧縮を採用することで，Intra圧縮に比べてビットレートをさらに低減することができる。HEVCについては，8Kファイルベースで利用できるファイルフォーマット用の圧縮方式として，検討が進められている。

３．４　その他の圧縮方式

上記以外に，8K解像度まで対応できる編集用圧縮方式として，HQxとCineformがある。HQxは，DNxHRやProResと同様にDCTベースの圧縮方式であり，ビットレートを任意に可変できるという特徴がある。HQxは，通常，AVIコンテナフォーマットで利用される。

CineformはWaveletベースの圧縮方式であり，AVI，MOVなどのコンテナフォーマットで利用される。

さらに，静止画用の圧縮方式であるJPEGやJPEG2000も8Kに対応可能であり，AVI，MOVなどのコンテナフォーマットで，motion JPEG^*12 として利用できる。

４．１　2K/4Kのファイルベースシステム

ファイルベースシステムの概要を10図に示す。ファイルベースの番組制作においては，各制作機器は高速ネットワークに接続され，映像素材ファイルはネットワーク経由で転送される。リムーバブルメディアにより持ち込まれた番組素材は，インジェストサーバー^*13 経由で素材サーバーへ取り込まれ，編集機により編集される。また，外部回線からの受け素材やスタジオ収録素材は，素材収録レコーダーで収録され，必要な素材は素材サーバーへ転送され，適時編集される。編集された素材は，完成プログラム^*14 として送出サーバーに登録され，送出サーバーから自動送出される。このように，ネットワークで各制作機器を接続し，番組素材をファイルとして取り扱うことで，効率的な番組制作が可能となっている。現行の2Kおよび4Kの番組は，このようなファイルベースシステムで制作されている。

４．２　NHKにおける2K/4Kファイルフォーマットの課題

2K番組の番組交換用のファイルフォーマットは，MXFコンテナフォーマットであり，圧縮方式にはAVCが用いられる。制作機器については，これまでに各メーカーから独自の圧縮方式を実装したレコーダーが製品化され，放送局は必要に応じてメーカーの機器を利用してきた。しかしながら，例えば同じAVC I100（AVCベースのIntra圧縮方式）でも，メーカーごとに圧縮パラメーターが最適化されているため，メーカー間の互換性は担保されていなかった。また，送出サーバーについては，機器を製作したメーカーのフォーマットしか受け付けないものが多く，そのフォーマット以外で持ち込まれた素材は，一度デコードした後に再エンコードする作業が必要となり，運用上の課題となっている。

4K番組の番組交換用のファイルフォーマットは，AVCベースのXAVC¹⁰⁾ という圧縮方式を用いたMXFコンテナフォーマットであり，ARIB（Association of Radio Industries and Businesses：電波産業会）のTR-B31¹¹⁾ で規定されている。しかしながら，XAVCもメーカーが独自に開発したフォーマットであるため，他のメーカーでは機器製作が困難であることが課題となっている。

５．１　現行の8K制作と送出

8Kの番組制作は，AVC-Ultra¹²⁾ という圧縮方式の4K用LSIを４つ並列動作させた8KP2^*15 レコーダー¹³⁾ を用いて行われている。最新の8K P2では，8K画像を単純に田の字に４分割して圧縮しており，編集機にファイルを入力して直接編集することも可能であるが，その場合，ソフトウェアによるデコード処理の負荷が大きくなるため，実際には，編集機へはベースバンドでリアルタイム入出力を行っている。編集後の完プロ素材は，編集機から8K P2レコーダーへベースバンドで出力され，P2メディア（P2の記録媒体）に書き込まれる。番組送出も8K P2レコーダーを用いて行われ，8K P2レコーダーにおいてP2メディアを掛け替えることで，8K送出に対応している。

現行の8K制作のワークフローを11図に示す。P2メディアの受け渡しを前提としたワークフローとなっており，8Kでもファイルベースシステムの実現が求められている。

５．２　8Kファイルベース

NHKが実現を目指している8Kファイルベースシステムを12図に示す。現行の2K/4Kファイルベースシステムの課題を解決し，同等以上の運用性を持つシステムを実現するためには，ファイルベースで利用できる8K基幹フォーマットを策定する必要がある。番組制作の途中では，必要に応じてさまざまな8K番組制作用フォーマットが利用されるが，最終的には8K基幹フォーマットを用いて完成プログラムが作成され，素材サーバーに保存される。完成プログラムを送出サーバーへ登録することで，自動送出を行うことができる。送出された番組は，そのままアーカイブに保存される。標準化された8Kファイルフォーマットを8K基幹フォーマットとすることで，外部との8K番組の素材交換が可能となる。

8K P2では，記録ビットレートが3.6Gbpsとなり，4Kに比べてかなり大きくなっている。ネットワークの負荷やコピーの高速化などを考慮すると，8K基幹フォーマットは，最新の圧縮方式を用いて高画質を保ちつつ，可能な限りビットレートを下げられることが望ましい。

当所で現在検討している8Kファイルフォーマット案の一部を1表に示す。このフォーマットは，将来8K対応の圧縮LSIが実現できたときにも陳腐化しないこと，現行のハードウェアでも実現可能なことなどを考慮して検討が進められている。

５．３　8Kファイルフォーマットの標準化への対応

現行の2K/4Kファイルフォーマットが抱える課題を解消するとともに，機器を製作する意欲を持つすべてのメーカーにおいて製品化が可能となるように，ARIBにおける8Kファイルフォーマットの標準化の検討をNHKから提案した。それを受けて，2018年10月にARIBの「放送素材ファイルフォーマット検討作業班」と「映像符号化方式作業班」を親会とするジョイントタスクグループ「4K8KファイルフォーマットJTG」が設立され，4Kを含む形で，HEVCを用いた4K/8Kファイルフォーマットの標準化の検討が始まった。本JTGでは，2019年1月に要求条件を確定し，３月に各社からのフォーマットの提案を受け付け，今後，具体的なフォーマット案の策定を進める予定となっている。また，必要に応じて映像の主観評価実験を行い，2019年12月を目途にパラメーターを確定する予定である。

一方，8Kファイルフォーマットの策定にあたり，これに必要なMXFでのHEVCのマッピングは標準化されていない。このため，MXFでのHEVCのマッピングに関する標準化の検討を，NHKからSMPTE に提案し，承認された。ARIBで標準化される4K/8Kファイルフォーマットは，SMPTEで標準化されるHEVCマッピング規定を引用する形となる予定である。