02
１．まえがき
近年，放送システムのファイルベース化＊１が進み，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 映像，音声，メタデータなどの さまざまな形式のデータを，コ ンテナフォーマットで規定され た形式で取りまとめること。２．動画用のコンテナフォーマット
動画ファイルは，符号化された映像・音声などのストリームと，それを格納するため のコンテナで構成される。コンテナフォーマットには映像の解像度や音声のチャンネル 数などによる制約がないため，符号化方式がサポートする解像度に応じて，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サブチャンク サイズ （4Byte） （（サイズ）Byte）データ FourCC （4Byte） １図 AVI のチャンク構造 ・・・ RIFFチャンク RIFFチャンク RIFFチャンク LIST チャンク LIST チャンク LIST （hdrl） チャンク LIST （movi） チャンク JUNK サブ チャンク Id x1 サブ チャンク ２図 AVI ファイルの基本構造
ンクには，ヘッダチャンク，フォーマットチャンク，オプションデータチャンクの３つ のサブチャンクが含まれる。ヘッダチャンク，フォーマットチャンク，オプションデー タチャンクには，それぞれストリーム情報，ストリーム構造，必須でないオプション情 報が格納される。 JUNKサブチャンクは，データの境界を2,048Byte単位にするためのダミーデータで ある。 LIST（movi）チャンクには，映像・音声の実データが入る。 Idx1サブチャンクには，映像・音声データへアクセスするためのIndex情報（アドレ ス情報）が記載される。 RIFFチャンクのサイズは，４バイトの符号なし整数で規定される。１つのRIFFチャ ンクのサイズがこの整数値の上限より小さい２GB以内となるように，AVIファイルが 分割されて記録される。 ２．２ MOV
MOVファイルは，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）単位で符 号化された映像などのデータが格納される。データの格納単位をチャンクと呼び，１フ レームまたは数フレームのデータを１つのチャンクに格納する。音声についても，１フ ＊5 Apple Quicktimeフォーマット で規定された形式。動画再生ソ フトのQuicktimeで再生できる。 atom タイプ （4Byte） atom サイズ （4Byte） atom データ ３図 atom の構造 movie atom movie data atom
（映像・音声データ） ファイル
タイプ
レームあるいは複数フレームのデータをチャンクに格納する。また，時間を表すデータ などもチャンクとして格納される。５図に示すように，通常，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ファイル中の，各チャンクのオフセット位置（ファイル先頭 から各チャンク先頭へのオフセット値）を定義する。
これらのテーブルを基に，映像・音声データにアクセスすることができる。
２．３ MP4
MP4は，ISO/IEC 14496のpart 14 4）として，MOVファイル形式を拡張する形で標 準化されたファイルフォーマットである。現在，パソコンやインターネットなどで標準 的に用いられているフォーマットであり，MOVファイルのatomをboxと言い換えてい
movie data atom
チャンク 1 チャンク 2 チャンク 3 チャンク 4 チャンク チャンク
…
５図 movie data atom の基本構造
movie atom movie header atom 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
る。MOVファイルと互換性のあるファイル形式となっている。
２．４ MXF
MXF（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） （可変 Byte）Length部分 （可変 Byte）Value部分
７図 KLV 形式
Header
Partition Pack Essence Container
ファイルヘッダー ファイルボディー ファイルフッター
Header
Metadata Partition PackFooter
また，MXFファイルでは，含まれるクリップ（映像などの素材）の数などにより，ファ イルの複雑さのレベルを表す「オペレーショナルパターン」が規定されている。最もシ ンプルなオペレーショナルパターンであるOP-1aは，１つのストリームに映像と音声が インターリーブされた構成である。最も複雑なOP-3cまで，９つのオペレーショナルパ ターンが規定されている。このほかに，映像と音声を別々にラッピングする構成のOP-ATOMとよばれるオペレーショナルパターンも規定されている。
３．8Kをサポートする映像圧縮方式
ファイルフォーマットで用いられる，映像の圧縮方式についても，さまざまなものが 標準化されている。 番組制作用のカメラやレコーダーなどで用いられる圧縮方式では，小型・低消費電 力，信頼性などが求められ，符号化処理はハードウェアで実装される。一方，編集用途 で用いられる圧縮方式では，圧縮率はそれほど高くないが，さまざまなファイルフォー マットへ対応するために，ソフトウェアによる実装が可能で，CPUやGPU（Graphics Processing Unit）による高速処理ができる方式となっている。編集の複雑さに応じて， 素材を元の圧縮方式のままダイレクトに編集する場合と，編集用圧縮方式などの編集に 適した方式に変換して編集する場合とがある。番組制作用と編集用のいずれの用途にお いても，各装置メーカーや編集ソフトメーカーから独自の圧縮方式が提案されている。 本章では，8Kの編集に対応した圧縮方式について解説する。 ３．１ DNxHR Avid社が編集用として定めた圧縮方式で，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）でフレームの終了を示す。ヘッダー には，各マクロブロックラインの開始オフセットアドレスが記載されており，マクロブ ロックラインごとの並列処理が可能となっている。 ３．２ ProRes Apple社が編集用として開発した圧縮方式で，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 主に画素の不透明度を表すのに 利用される補助データ。ても，用途に応じていくつかの値を選択できる。解像度については，フレーム当たりの ライン数，およびライン当たりのサンプル数を，２バイトの符号なし整数で規定できる。
カメラの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の周波数ごとに，ス ライス内の符号化ブロックのデータが格納される。これにより，デコードを適当な周波 数で打ち切ることで縮小画像を高速に出力できる「スケーラブルデコード」が可能となっ ている。 ３．３ HEVC HEVC 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
…
AC 2 AC 3 AC 63 DC 1 DC 2 DC 3 DC ９図 ProRes のスライス構成任意に可変できるという特徴がある。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図 ファイルベースシステムの概要は，一度デコードした後に再エンコードする作業が必要となり，運用上の課題となって いる。
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でもファイルベースシステムの実現が求められている。 ＊15 4K対応のLSIを４並列させ，４ 分割した8K映像を圧縮・復号 する8K収録装置。収録はP2メ ディアで行われる。 送出 収録 編集 メディア運搬 ベースバンド取込 メディア運搬 11図 現行の8K制作のワークフロー 映像素材 回線受け 編集 素材 サーバー 送出サーバー アーカイブ 素材レコーダー 8K番組制作用フォーマット インジェストサーバー 素材交換 記録メディア 8K基幹フォーマット 12図 8Kファイルベースシステム５．２ 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
一方，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 フィルムの代わりにデジタル データで映画を上映する方式に 関する規格。上映に必要な素材 が，１つのパッケージにまとめ られている。宮み や下し た 英え い一い ち 1987年入局。宮崎放送局を経 て，1990年から放送技術研 究所において，デジタルVTR， 垂直磁気記録，スーパーハイビ ジョン記録装置の研究に従事。 現在，（一財）NHKエンジニア リングシステムに勤務。博士（工 学）。
