02

14 NHK技研 R&D/No.177/2019.9

１．まえがき近年，放送システムのファイルベース化＊１が進み，2Kおよび4K（以下，2K/4Kと略記）

のファイルベースシステムでは，制作フローの管理や送出の自動化などにより，効率的な番組制作が可能となった。また，さまざまな映像圧縮技術が利用できるようになり，最新の圧縮技術を用いることで，映像ビットレートの低減やファイルサイズの抑制が可能となり，現行のネットワークでも使い勝手のよいシステムが構築できるようになった。

一般に，動画ファイルは，映像・音声の符号化されたストリームとその他の付随データを，コンテナフォーマット＊２でラッピング＊３して作成される。動画ファイルのコンテナフォーマットには，さまざまな種類のものが使われている。パソコンによる閲覧にはAVI（Audio Video Interleave）やMOVなどのコンテナフォーマットが，放送用途にはMXF（Material eXchange Format）コンテナフォーマットが用いられる。

2K/4Kのファイルベースシステムでは，放送送出用のコンテナフォーマットが規定されており，このフォーマットを用いて，送出サーバーへの番組の登録と自動送出が実現されている。一方，8Kでは，まだ標準フォーマットが策定されていないこともあり，ファイルベースの運用に対応できていない。そのため，8Kの番組交換や番組送出に利用できる8Kファイルフォーマットの策定が求められている。

本稿では，8Kを扱えるファイルフォーマットと映像圧縮方式の動向について述べるとともに，ファイルベースシステムで利用できる8Kファイルフォーマットの標準化への取り組みについて解説する。

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

当所では，将来の8Kファイルベースシステムを実現するために，高効率な符号化方式

やそれを用いたファイルフォーマットの研究を進めている。2018年12月に開始された

新4K8K衛星放送では，高精細映像の放送を実現するために，最新の映像圧縮方式で

あるHEVC（High Efficiency Video Coding）が用いられている。また，2Kおよび

4Kの番組制作では，現在，AVC（Advanced Video Coding）による圧縮フォーマッ

トを用いて，ファイルベースの番組制作が行われている。一方，8Kではファイルベー

スの番組制作がまだ実現できていないが，より高効率でビットレートを低減できるファイ

ルフォーマットの実現が求められている。本稿では，8Kを扱うことができるファイルフォー

マットと映像圧縮方式の動向，および8Kファイルベースシステムを実現するための取り

組みについて解説する。

＊1映像・音声素材をパソコンで取り扱えるデジタルデータ形式のファイルに変換することで，収録，編集，送出，およびアーカイブ業務を効率化すること。

＊2映像，音声，メタデータなどのさまざまな形式のデータを保持するファイルフォーマット。

＊3映像，音声，メタデータなどのさまざまな形式のデータを，コンテナフォーマットで規定された形式で取りまとめること。

15NHK技研 R&D/No.177/2019.9

２．動画用のコンテナフォーマット動画ファイルは，符号化された映像・音声などのストリームと，それを格納するため

のコンテナで構成される。コンテナフォーマットには映像の解像度や音声のチャンネル数などによる制約がないため，符号化方式がサポートする解像度に応じて，4Kや8Kへの拡張が可能となる。

動画用のコンテナフォーマット（以下，動画コンテナフォーマット）にはさまざまな形式が存在するが，本章では，代表的な動画コンテナフォーマットであるAVI，MOV，MP4，MXFについて，それぞれの特徴を示す。

２．１　AVIAVIは，Windows OSで主に用いられる動画コンテナフォーマット1）で，RIFF

（Resource Interchange File Format）形式＊４をとっており，１図に示すようなチャンクと呼ばれる単位で構成される。チャンクは，内部にさらにチャンクあるいはサブチャンクを含むことができる。

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

AVIファイルの基本構造を２図に示す。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）チャ

＊4映像と音声のような形式が異なるリソースを１つのファイルにまとめるために，タグ付きのデータを格納する形式。

（a） AVIチャンク

（b） AVIサブチャンク

ID（4Byte）

サイズ（4Byte）

データ（（サイズ－4）Byte）

FourCC（4Byte）

サイズ（4Byte）

データ（（サイズ）Byte）

FourCC（4Byte）

１図　AVI のチャンク構造

・・・

RIFFチャンクRIFFチャンクRIFFチャンク

LISTチャンク

LISTチャンク

LIST（hdrl）チャンク

LIST（movi）チャンク

JUNKサブチャンク

Idx1サブチャンク

２図　AVI ファイルの基本構造

NHK技研 R&D/No.177/2019.916

ンクには，ヘッダチャンク，フォーマットチャンク，オプションデータチャンクの３つのサブチャンクが含まれる。ヘッダチャンク，フォーマットチャンク，オプションデータチャンクには，それぞれストリーム情報，ストリーム構造，必須でないオプション情報が格納される。

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

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

ス情報）が記載される。RIFFチャンクのサイズは，４バイトの符号なし整数で規定される。１つのRIFFチャ

ンクのサイズがこの整数値の上限より小さい２GB以内となるように，AVIファイルが分割されて記録される。

２．２　MOVMOVファイルは，ISO/IEC 14496 part 12 2）で「ISO Base Media File Format」

として標準化されている。主にMac OSで用いられるQuicktime形式3） ＊５ のファイルフォーマットであり，３図に示すようなatomと呼ばれる基本単位で構成される。atomの最初の４バイトはatomサイズを示し，次の４バイトは４文字のatomタイプを示す。９バイト目以降はデータであり，データのサイズはatomサイズから８バイトを引いた値となる。atomは入れ子構造にすることが可能であり，通常は，いくつかのatomが束ねられた構造が用いられる。

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

データを格納するmovie data atomのサイズは，長尺のコンテンツや4K/8Kのような高精細映像のコンテンツでは，４バイトの符号なし整数で定義できるサイズを超えてしまうため，８バイトのLong型符号なし整数でサイズを定義するオプションが用意されている。movie data atomには，フレーム単位やGOP（Group of Pictures）単位で符号化された映像などのデータが格納される。データの格納単位をチャンクと呼び，１フレームまたは数フレームのデータを１つのチャンクに格納する。音声についても，１フ

＊5Apple Quicktimeフォーマットで規定された形式。動画再生ソフトのQuicktimeで再生できる。

atomタイプ

（4Byte）

atomサイズ

（4Byte）

atomデータ

３図　atom の構造

movieatom

movie data atom（映像・音声データ）

ファイルタイプ

４図　MOV ファイルの基本構造

17NHK技研 R&D/No.177/2019.9

解説　02

レームあるいは複数フレームのデータをチャンクに格納する。また，時間を表すデータなどもチャンクとして格納される。５図に示すように，通常，movie data atomにはデータチャンクが時系列で格納される。個々のチャンクには，異なる数のデータが入っても構わない。チャンクごとのデータサンプル数（フレーム数など）はsample to chunk atom（６図参照）にテーブルの形で保存される。

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

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

から各チャンク先頭へのオフセット値）を定義する。これらのテーブルを基に，映像・音声データにアクセスすることができる。

２．３　MP4MP4は，ISO/IEC 14496のpart 14 4）として，MOVファイル形式を拡張する形で標

準化されたファイルフォーマットである。現在，パソコンやインターネットなどで標準的に用いられているフォーマットであり，MOVファイルのatomをboxと言い換えてい

movie data atom

チャンク1

チャンク2

チャンク3

チャンク4

チャンク チャンクn

…

５図　movie data atom の基本構造

movie atom

movieheaderatom

track atom

media atom

media information atom

・time to sample atom・sample description atom・sample size atom・sample to chunk atom・chunk offset atom

sample table atom

６図　movie atom の基本構造

NHK技研 R&D/No.177/2019.918

る。MOVファイルと互換性のあるファイル形式となっている。

２．４　MXFMXF（Material eXchange Format）は，放送用のファイル交換などを想定した

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

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

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

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

＊6画像圧縮で選択できる画像サイズなどを規定したパラメーターセット。

Key部分（16 Byte）

Length部分（可変 Byte）

Value部分（可変 Byte）

７図　KLV 形式

HeaderPartition Pack

Essence Container

ファイルヘッダー ファイルボディー ファイルフッター

HeaderMetadata

FooterPartition Pack

８図　MXF ファイルの基本構造

19NHK技研 R&D/No.177/2019.9

解説　02

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

３．8Kをサポートする映像圧縮方式ファイルフォーマットで用いられる，映像の圧縮方式についても，さまざまなものが

標準化されている。番組制作用のカメラやレコーダーなどで用いられる圧縮方式では，小型・低消費電

力，信頼性などが求められ，符号化処理はハードウェアで実装される。一方，編集用途で用いられる圧縮方式では，圧縮率はそれほど高くないが，さまざまなファイルフォーマットへ対応するために，ソフトウェアによる実装が可能で，CPUやGPU（Graphics Processing Unit）による高速処理ができる方式となっている。編集の複雑さに応じて，素材を元の圧縮方式のままダイレクトに編集する場合と，編集用圧縮方式などの編集に適した方式に変換して編集する場合とがある。番組制作用と編集用のいずれの用途においても，各装置メーカーや編集ソフトメーカーから独自の圧縮方式が提案されている。本章では，8Kの編集に対応した圧縮方式について解説する。

３．１　DNxHRAvid社が編集用として定めた圧縮方式で，SMPTEでVC-3として標準化され7），

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

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

３．２　ProResApple社が編集用として開発した圧縮方式で，SMPTE RDD 36 8）として標準化され

ており，MOV，MP4，MXFなどの動画コンテナフォーマットで広く利用されている。DNxHRと同様にDCTベースの圧縮方式であり，ソフトウェアによる高速処理が可能である。扱える画像フォーマットは，画素構造についてはアルファチャンネルを含む4:2:2および4:4:4，色差信号についてはYCbCrおよびRGBとなっている。ビットレートについ

＊7色差信号の水平および垂直の画素数が輝度信号と等しいものを4:4:4，水平方向に半分に間引いたものを4:2:2，水平方向と垂直方向ともに半分に間引いたものを4:2:0と呼ぶ。

＊8主に画素の不透明度を表すのに利用される補助データ。

NHK技研 R&D/No.177/2019.920

ても，用途に応じていくつかの値を選択できる。解像度については，フレーム当たりのライン数，およびライン当たりのサンプル数を，２バイトの符号なし整数で規定できる。

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

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

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

３．３　HEVCHEVC 9）は，国際標準となっている最新の圧縮方式であり，8Kまでの解像度に対応し，

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

３．４　その他の圧縮方式上記以外に，8K解像度まで対応できる編集用圧縮方式として，HQxとCineformがある。HQxは，DNxHRやProResと同様にDCTベースの圧縮方式であり，ビットレートを

＊10フレーム内の相関を用いて，フレームごとに映像を圧縮する方式。

＊11フレーム間の相関を用いて映像を圧縮する方式。

＊9イメージセンサーの画素値を加工せずに，生データのまま保存するための形式。実際の画像として見るためには現像処理が必要となる。

slice header

DC AC1

…

Y data Cb data Cr data

…AC2

AC3

AC63

DC1DC2DC3

DCn

９図　ProRes のスライス構成

21NHK技研 R&D/No.177/2019.9

解説　02

任意に可変できるという特徴がある。HQxは，通常，AVIコンテナフォーマットで利用される。

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

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

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

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

４．２　NHKにおける2K/4Kファイルフォーマットの課題2K番組の番組交換用のファイルフォーマットは，MXFコンテナフォーマットであり，

圧縮方式にはAVCが用いられる。制作機器については，これまでに各メーカーから独自の圧縮方式を実装したレコーダーが製品化され，放送局は必要に応じてメーカーの機器を利用してきた。しかしながら，例えば同じAVC I100（AVCベースのIntra圧縮方式）でも，メーカーごとに圧縮パラメーターが最適化されているため，メーカー間の互換性は担保されていなかった。また，送出サーバーについては，機器を製作したメーカーのフォーマットしか受け付けないものが多く，そのフォーマット以外で持ち込まれた素材

＊13いろいろな記録メディアで持ち込まれた素材をファイルベースシステムへ入力するためのサーバー。

＊14文字スーパーやナレーションなどが入れられた完成形式のプログラム（完プロ）。

＊12各フレームをJPEG圧縮することで動画を圧縮する方式。

リムーバブルメディアにより持ち込まれた番組素材

外部回線受け素材スタジオ収録素材

素材サーバー

高速ネットワーク インジェストサーバー

編集機1

素材収録レコーダー

送出サーバー１

番組送出

編集機2 編集機

3

送出サーバー2

10図　ファイルベースシステムの概要

NHK技研 R&D/No.177/2019.922

は，一度デコードした後に再エンコードする作業が必要となり，運用上の課題となっている。

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

５．8Kのファイルフォーマット５．１　現行の8K制作と送出

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

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

＊154K対応のLSIを４並列させ，４分割した8K映像を圧縮・復号する8K収録装置。収録はP2メディアで行われる。

送出収録 編集

メディア運搬 メディア運搬ベースバンド取込

11図　現行の8K制作のワークフロー

映像素材

回線受け

編集

素材サーバー

送出サーバー

アーカイブ

素材レコーダー

8K番組制作用フォーマット

インジェストサーバー

素材交換

記録メディア

8K基幹フォーマット

12図　8Kファイルベースシステム

23NHK技研 R&D/No.177/2019.9

解説　02

５．２　8KファイルベースNHKが実現を目指している8Kファイルベースシステムを12図に示す。現行の2K/4K

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

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

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

５．３　8Kファイルフォーマットの標準化への対応現行の2K/4Kファイルフォーマットが抱える課題を解消するとともに，機器を製作

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

１表　8K ファイルフォーマット案

パラメーター 規定値

画素数 / フレーム周波数 7,680×4,320 / 59.94Hz，119.88Hz

カラーサンプリング / ビット深度 4:2:2 / 10bit

色域・伝達関数 BT.2020 / BT.2100（HLG※１）

符号化方式 H.265

画面分割法 スライス分割 / 位置は固定

GOP構成 Long GOP（Closed GOP※２）

GOP長 0.5秒程度

音声サンプリング周波数 48kHz

音声ビット深度 / チャンネル数 24bit / 32ch

※１ Hybrid Log-Gamma※２ 参照フレームがGOP内で閉じた構造。

NHK技研 R&D/No.177/2019.924

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

６．むすび本稿では，8Kファイルフォーマットの動向と，8Kファイルベースシステムを実現す

るための取り組みについて述べた。前述のように，現行の8Kの番組送出は，P2メディアの受け渡しを前提としているた

め，まずは8Kファイルフォーマットを標準化し，標準規格に準拠した送出サーバーによる8K番組の送出の実現を目指したい。また，標準化された4K/8Kファイルフォーマットに準拠した素材レコーダーが多くのメーカーにより製品化され，より効率的な8K番組制作が実現できるように，8Kファイルベースの研究を進めていきたい。

番組交換用ファイルフォーマットとしては，MXF以外では，IMF（Interoperable Mastering Format）14）が標準化されている。これはデジタルシネマパッケージ（DCP）規格＊16をベースにしたファイル受け渡しの標準規格であり，Netflixをはじめ，FOX，ディズニー，ソニーピクチャーズなどが，このIMFを納品ファイル形式として採用している15）。最近，放送局でもIMFの採用が検討され始めたため，今後の動向を注視したい。

＊16フィルムの代わりにデジタルデータで映画を上映する方式に関する規格。上映に必要な素材が，１つのパッケージにまとめられている。

25NHK技研 R&D/No.177/2019.9

解説　02

宮み や

下し た

英え い

一い ち

1987年入局。宮崎放送局を経て，1990年から放送技術研究所において，デジタルVTR，垂直磁気記録，スーパーハイビジョン記録装置の研究に従事。現在，（一財）NHKエンジニアリングシステムに勤務。博士（工学）。

参考文献1） MicrosoftAVIFileFormat，https://docs.microsoft.com/en-us/windows/desktop/directshow/avi-file-format

2） ISO/IEC14496-12，“InformationTechnology-CodingofAudio-visualObjects-Part12:ISOBaseMediaFileFormat”

3） AppleQuicktimeFormat，https://developer.apple.com/standards/qtff-2001.pdf

4） ISO/IEC14496-14，“InformationTechnology-CodingofAudio-visualObjects-Part14:MP4FileFormat”

5） 成見：“MXF規格の概要，”映情学誌，Vol.61，No.6，pp.746-751（2007）

6） 中野：“SMPTE等のMXFファイルフォーマット標準化，”映情学誌，Vol.64，No.8，pp.1224-1226（2010）

7） SMPTEST2019-1:2014，“VC-3PictureCompressionandDataStreamFormat”

8） SMPTERDD36:2015，“AppleProResBitstreamSyntaxandDecodingProcess”

9） ISO/IEC23008-2，“HighEfficiencyCodingandMediaDeliveryinHeterogenousEnvironments-HighEfficiencyVideoCoding¦RecommendationITU-TH.265，“HighEfficiencyVideoCoding”

10）XAVCSpecificationOverview，https://www.xavc-info.org/xavc/share/data/XAVC_SpecificationOverview_Rev2_2.pdf

11）ARIBTR-B31，“ファイルベースによる番組交換方式”

12）AVC-ULTRAOverview，https://panasonic.biz/cns/sav/p2/AVC-ULTRAoverview_j.pdf

13）8KスーパーハイビジョンレコーダAJ-ZS0580，https://panasonic.biz/cns/sav/broch_bdf/aj-zs0580_urd100.pdf

14）SMPTEST2067-5:2013，“InteroperableMasterFormat-EssenceComponent”

15）フォトロン：“徹底解説！Netflix用「IMF」コンテンツ作成方法，”https://www.photron-digix.jp/column/2016/09.html