お勉強：マルチメディア - MPEGのきほん
駄文が見つかりました。あんまり更新してないのでかなり雑多な記述。初稿は2005年くらい。文中の表記は MPEG2, MPEG 2 ではなく MPEG-2 で統一した。他の MPEG○ についても同様。
そもそもMPEGとは
Moving Picture Experts Group、直訳するとパラパラマンガ研究会。動画が Movie で通用しないこともないだろうにわざわざ Moving Picture なんてもったいぶった言い方してるのは JPEG との対比もあるんだろうけど、略称 MEG でもいいぢゃねーか、と meg 萌えなオレは思う。どうでもいいか。
MPEG | The Moving Picture Experts Group website
つまり、MPEG は動画の規格であるが、そもそもが組織名称なので、ひとえに MPEG といってもいろんな種類が、解釈がある。Video-CD に用いられる初代 MPEG-1 は画質と圧縮率（ファイルサイズ）のバランスが悪すぎて長時間や高画質動画の保存にはおよそ適さなかった。
鳴り物入りだった MPEG-4 は要件を満たす規格の乱立でわけのわからないことになっている。DivX も Xvid も WindowsMedia も QuickTime も ReadMedia も MKV も ASF も PSP も iPod もスマホもみーんな MPEG-4 だけど、コーデックの互換性は皆無に等しい。拡張子も統一されてないのでファイル名だけでは見分けがつかないことが多くて困る。
デジタルメディアとして最初に浸透した DVD-Video に採用されたことで初稿の時点では MPEG といえば MPEG-2 （正しくはハイフンが入る）という認識が圧倒的主流だった。
追記：2009-04-24
次世代 DVD の Blu-Ray が採用したことやデジタル放送の本格化で、さすがに MPEG-4 もずいぶん浸透してきた。
追記：2013-03-08
MP4 はすっかり定着したが、コーデックが H.264/AVC ということもあり MPEG と呼ぶ人はほとんどいない。コーデックとコンテナの組み合わせがシンプルでわかりやすいぶん、MPEG≒MPEG-2 という図式にはあまり変化がないように感じる。まあ略さずにちゃんと MPEG-2 と呼ぶ人のほうが多いが。
追記：2016-03-28
いい加減に個々のコーデックやコンテナを指して MPEG と呼ぶようなことはなくなり、ようやく MPEG＝MPEG-1 / 2 / 4 ASP / 4 AVC / H HEVC で定着したように思う。ちなみに MPEG-5 とか誤解してる人もいそうだけど、H.265/HEVC＝MPEG-H だからな。
以下、MPEG 系動画圧縮の共通技術やポイントを取り上げてみる。なお個々の MPEG 系の規格については主な動画規格を参照。
MPEG とフレーム間圧縮
MPEG というか最近の動画圧縮技術を理解するうえで最も大事な概念が、時間軸方向の差分情報を利用したフレーム間圧縮である。具体的にはこんな感じ。
フレーム1には都心の光景が保存されている。そこに突如、クシャトリアが出現したとしよう。情報量を節約するためフレーム2にはフレーム1との差分にあたるクシャトリアだけが保存される。よって本来のフレーム2で映し出すべき画像を復元するにはフレーム1とフレーム2両方の情報が必要になってくるわけよ。
もちろん実際にはもっと複雑な処理があれこれなされてるけど、ベースと差分の組み合わせ、これがフレーム間圧縮の基本中の基本。動画の再生中にフレーム2のポイントで一時停止しようとしても、実際にはフレーム1の情報も必要なので一瞬もたついたり、そこでうまく止まってくれなかったりする。一般に差分情報のフレームのほうが圧倒的に多いので、ビデオテープのようなスムースなサーチができないのはこのへんが理由なのね。
もっというとどの圧縮規格も基本的に順次再生とスキップしか想定してないから任意のポイントにサーチしたり再生速度をランダムに変化させたり逆転したりなんてのはプレイヤー自身でどうにかするしかないのよ。
そんなわけで、例にあげた基点となるフレーム1に相当するのがIピクチャ、フレーム2に相当する差分のフレームがPピクチャ/Bピクチャで、以下もう少し詳しく説明する。
GOP と I / P / B フレーム
現在の動画圧縮の基本中の基本なのでこれだけはちゃんと覚えておけよ！
- GOP
- Group Of Picture、ゴップ。I ピクチャを基点に構成される差分情報（ B ピクチャ、P ピクチャ）のまとまり。MPEG における静止画像を構成する最小単位で、再エンコードや特殊な操作なしに画像を取り出したり映像どうしを繋ぎ合わせたりは GOP ごとになる（ P / B フレームの画像を取り出すのに必要になってくる範囲、という感じ）。
- MPEG 系（DivX や WMV など ASP 準拠も含む）の動画圧縮はすべて GOP 構造を取っている。むしろ時間軸圧縮をするコーデックで GOP でないものを探すほうが大変と思う。
GOP はこんな感じで構成される。
ひとまず I が先の説明でいう都心の光景、 P や B がクシャトリアとその動き、くらいに思ってくれれば。
- I ピクチャ / I フレーム
- イントラブロックピクチャの略と思われる。わかっているのかハリー・オード（それは i フィールド。依存関係がなく自身の情報のみで画像を復元できる。中身は限りなく JPEG。キーフレームに用いられ、I フレームだけで GOP を構成することもできるが圧縮効果は当然下がる（というかフレーム圧縮のみなのでパラパラマンガの Motion JPEG に近い）。ちなみにイントラブロックは単一フレームのみで符号化を行い動き予測を使っていない、という意味。逆はノンイントラブロック。
- H.264/AVC では後述する IDR フレームが新たに導入されたけど、役割が若干変わっただけで中身はまんま I フレームである。
- P ピクチャ / P フレーム
- “直前の” I フレームを参照し差分だけを記録することでサイズの縮小を図ったもの。 I フレームと P フレームを組み合わせることで圧縮効果を高めることができるが、単体では画像として復元できず直前の I フレーム / P フレームが必要となる。P はプレ（ Predicted … 前方向予測）のことかな。ちなみに GOP 内は I P B B の順で記録されるが、出力は I B B P の順になる。
- B ピクチャ / B フレーム
- “前後の” I フレームや P フレームを参照し差分を記録したもの。自分の情報を前後に分担してもらうのだからサイズはもっとも小さく圧縮効果は非常に高いのだが、割り充てるビットレートが少ないと動きの多いシーンでの画質の劣化が激しくなる。MPEG-2 に限らず現在のエンコードは B フレームをいかにうまく処理するかが画質と圧縮率のバランスを取る上でのキモ。B はびんぼうひまなしの B （なわけあるか、Bi-directional Predicted …両方向予測か。
- ※一部の解説で“MPEG-1 / 2 は B フレームを扱えない”とするものがあるけど、そんなこたーない。制約があるならエンコーダーなりの機種依存 / 環境依存である。
1つの GOP を構成するコマ数（ I P B の依存関係が完結する範囲）が GOP 長。原則として GOP の先頭は I フレームで始まり、並びは IBBPBBPBBPBBPBB･･･のようになる。一般に
- GOP が短いほどシーク性が向上し編集もしやすいが I フレームの数が増えるのでデータ量が増え、より多くのビットレートを必要とする。
- GOP が長いほどシーク性は落ちるが P や B フレームに割り当てるデータ量が増えるので同一ビットレートにおける画質は向上する。
DVD では GOP は最大 18 コマとなっており、多くの MPEG-2 でもそうなっている。なお H.264/AVC では B フレームやフレーム参照の扱いがそれまでの MPEG 系規格とは大きく異なり、あるコマを取り出すのに必要なフレームの参照範囲が GOP に依存しないことからデコード処理を複雑・煩雑なものとしている。
Open GOP と Closed GOP
B フレームや P フレームの参照範囲を変え差分に前後の GOP の情報も含めることができるようにしたのが Open GOP で、前後の GOP に依存しない Closed GOP とは区別される。Open GOP は参照範囲が広いのでより圧縮率を稼げるが、GOP の先頭が I フレームとは限らず、また論理的な GOP の境界が個々のフレームによって異なるため任意のフレームをデコードする際の依存関係の範囲を特定しにくい（極論すると GOP 長 108,000 の1時間動画みたいなものだ）。そのためシーケンシャルな読み込みだけで済む通常の再生は安定するものの、ランダムシークや編集性はすこぶる悪い。Open GOP はニコ動のようにファイルサイズやビットレートの制約が厳しいケースで有効だが一般的な用途では利便性が悪いのであまり用いられない。また MPEG-2 はそもそも Open GOP をサポートしていない。
Open GOP と Closed GOP の図（出典：Compressor 3 User Manual: MPEG-2 Reference Information）
...最初に触れたように、MPEG-2 をはじめとする“時間軸方向の画像圧縮アルゴリズム”を使っている映像は、特に双方向予測を行う B フレームの使用が前提であるためパラパラ漫画のようにフレーム単位で静止画像にバラすのをものすごく苦手としている。具体的には個々のフレームのデコードは GOP 単位なので、GOP 長が 300 の場合は GOP の最後の B フレームをデコードするために 10秒前の I フレームまでバッファに留めておく必要がある。かといって GOP を短くしたり B フレームの数を減らすと画質や圧縮率が犠牲になる。極端な話、全て I フレームにすれば画質はよいし編集も容易だけど、それなら何も MPEG である必要が無い。
オール I ピクチャ記録（ ALL I ）に関する注意
オプション等でオール I ピクチャとして記録できるソフトや機材もあるが、そこまで画質にこだわるのであればハナから MPEG ではなく AVI や DV のような RAW かそれに近い記録をすべきなのである。なぜ？ I ピクチャだって不可逆圧縮＝劣化してるんだよ！編集マスターにする際も MPEG より DV など AVI 系のほうが圧倒的に扱いやすい。
そもそも MPEG は編集ソース記録のための規格ではなく、配信や鑑賞といった最終出力に向けて最適化する際の規格なのだ。よってオール I ピクチャ＝画質がいい、と考えるのではなく RAW 記録ができない場合の暫定手段であることを忘れてはならない。
とにかく DVD を含む近年の動画がコマ送りを苦手とするのはフレームどうしの依存関係が原因で、特に B フレームの機能上の理由で先読みのできない逆方向が苦しく、さらに Open GOP では絶望的。動画編集ソフトにはあらかじめプリレンダリング（依存関係を解消し復元された個々のフレーム）をキャッシュ化し、DV 等と比べても謙遜のないコマ単位での移動や編集を実現しているものもあるが、一般的なプレイヤーの場合スムースなシークは順方向は I フレーム＆ P フレーム単位、逆方向は I フレーム単位のみが基本になる。これはもう諦めるというかそういうものだと受け入れるしかない。
1枚の絵を表示するのに他にどれだけのフレームを読みこむ必要があるかという点では、再生時のシークのスムースさはバッファリングに依存する、と受け取ってもらっても構わない（まあそれだけじゃないんだけどね）。おそらく数 GOP くらいのフレームは常にバッファリングしているのだろうが、これを数千フレームまで増やせばだいぶカクカクは収まるはずである。もっともプレイヤーがいちいち起動や読み込みだけで時間食うわけにはいかんし、組み込みだとそこまでバッファの余裕がない。
なお MPEG-4 も時間軸圧縮アルゴリズムを用いているのは MPEG-2 と同じだが、MPEG-2 がコマ単位、画面全体での差分情報しか考慮しないのに対し、MPEG-4 では画面内の様々な要素をオブジェクトとして捉えることができる。つまり背景と人物を分けて考えることができるのだ（背景が静止した状態で人物が動き回るような動画を想像してみてほしい）。
また H.264/AVC は先述したように従来の GOP 構造と異なり、P フレームの参照可能な I フレームが直前のフレーム以外でも可能になった（ Multiple Reference Pictures ）。結果、GOP と I フレームの関係が崩れプレイヤーも制御が複雑になってしまうため、P フレームの参照範囲を制限する IDR という仕組みが組み込まれている。H.264/AVC のシークはこの IDR フレーム単位となり、エンコード時の IDR フレーム間隔によってシーク位置が決まる。B フレームの機能も前方・後方 2 枚の参照が可能なほか、使用頻度をエンコーダが任意に決める adaptive B フレームやフレームの順をエンコーダが自由に変更できる arbitrarily frame order など、かなり扱いがややこしい。各種エンコードツールがこれらの仕様をすべて実装しているわけではないが、おおむね GOP で完結していた MPEG-2 と比べて参照範囲が不規則かつストリーム内のデータの並びと実際の出力順が複雑化したことも、H.264 デコーダーの処理の重さに繋がっている。
その他の避けて通れない技術
レート絡みでホンダっぽい用語が多い。
DCT とマクロブロック
夢は叶うんです！動画エンコードの第一歩は静止画の圧縮だが、中でも最重要の技術が実数信号の座標変換を行う符号化アルゴリズムのひとつ、離散コサイン変換（ Discrete Cosine Transform ）。元になったのは離散フーリエ変換（ DFT ）だが、DFT が「実数に複素数を返す」のに対し DCT では「実数に実数を返す」のが特徴。さらに座標変換後の周波数成分が特定の低い領域に集中する特性があり、これによりエネルギー効率の良い量子化…つまりは圧縮効果を得られる。
出典：Q＆Aで学ぶH.264/AVC（12）：圧縮技術の基本的な技術「DCT（離散コサイン変換）」とは？
DCT では画面を 8ｘ8 を最小単位とする区画に細分化し、一つの区画ごとにデータ変換を行う。この区画をマクロブロックと呼んでいる。DCT のアルゴリズムを理解する必要はまったくないが、マクロブロックが 8ｘ8 のため出力後の解像度も 8 ピクセル単位でないと効率が極端に悪化したり、最悪の場合処理がエラーとなるので、現状はコンピュータが扱いやすい 16 ピクセル単位にするのがセオリー、ということは覚えておくべきだろう。
高い圧縮効果にもかかわらず演算量は比較的少なく済むため※、DCT はMPEG 及び JPEG 圧縮における根幹技術…別の言い方をするなら MPEG/JPEG 特許のキモの部分であり、新しいコーデックを開発するなら DCT から脱却しない限りライセンス問題から逃れられない、というのがオトナの事情。
※MPEG-2 は DCT と MC （ Motion Compensation, 動き補償）が演算の中心。
ビットレートと CBR / VBR / ABR / MBR
ビットレートは単位時間あたりの記録密度をあらわすのに使う用語で、記録量一定なのが CBR、変化するのが VBR。わしも昔は TZR でレーサー気取り出力サイズを予測できる CBR でエンコードしてたけど、GOP の構造を考えたら VBR であるべきなんだよね。だって基準画像と差分情報を同じ情報量で記録するってなんかおかしいじゃん。差分に合わせたら基準画像は情報不足で画質粗くなっちゃうし、基準画像に合わせたら差分が情報過剰でファイルサイズ無駄じゃん。よって画質にこだわるなら VBR は絶対といっていいし、そもそも MP4 コンテナはパディングを許可していないので 0 パディングによる擬似 CBR は規定に反するのだ。別にコンテナハックを否定する気はない。知らずにやるなというだけ（開き直るな、ともいう。
限られたりソースの範囲で最高画質を求めるなら VBR、ということ。湯水のようにビットレートを使えるなら CBR というよりも無圧縮の AVI（ RAW Video ）最強で FA。
AVI コンテナみたいにフレーム間圧縮を想定していなかったフォーマットだと VBR は非常に扱いがめんどくさいシロモノだったりするんで何が何でも VBR というわけにもいかないけど、MP4 や MKV や ASF なら VBR にしない手は無い。今さら前世紀の遺産のような AVI コンテナを使う理由もなかろう。ただストリーミングのように帯域幅に制約のある用途では VBR エンコード時の上限ビットレートが高すぎると帯域が追い付かず再生に支障をきたす可能性がある（バッファリングするのは画像復元に必要な範囲すべてのフレームだからね）。
映像や音声のエンコードはオリジナルのアナログ情報を標本化→量子化→符号化という過程を経ている。CBR といっても MPEG などでは量子化された情報をそのまま記録する RAW Video や CD-DA などのリニア PCM と違い、指定した値どおりに均一なビットレートを実現するのは難しい。そこで実際の CBR はビットレートを一定に保つために谷間をパディング･･･ダミーで埋めるほか、レートの不足分は量子化の精度を落とす可変量子化（ VQ ）で吸収している。
VBRでもVQが基本だけど映像品質を一定に保つ固定量子化（ CQ ）を行うこともできる。ただ CQ はビットレート変動が激しく出力ファイルサイズの予測が難しいというか係数下げる≒品質重視にすると笑っちゃうくらいバカでかくなるので、視覚的に劣化を認識しづらい動きの激しい部分の画質を下げ変化の少ないシーンの画質を優先することで少しでも圧縮率を高める固定品質（ CRF ）に置き換わりつつある。
品質と評価について
同じビットレートでも解像度によって得られるクオリティは変化するため、解像度に依存しないビットレートの指標として1ピクセルあたりのビット数を表す BPP（ Bit / Pixel ）がある。確かに便利な指標でちょっと前まではそれなりにもてはやされていたが、BPP によって判断できるのは圧縮率であってクオリティではない。同じ BPP でもシーンによって画質は変化するし、解像度が大きいほうが圧縮効果が高まるコーデックもある。
もともと研究分野では圧縮した画像などを復元した際、元の画像よりどの程度劣化したかを示す指標として MSE（ Mean Square Error ）や PSNR（ Peak Signal-to-Noise Ratio ）、VSNR（ Visual Signal-to-Noise Ratio ）などが存在するが、見た目には大きな差のある全体で少しずつ違う画像と局所的に大きく違う画像とで大差ない結果を返すこともあった。人間の視覚が感じる違いを判断ための指標としては SSIM（ Structural SIMilarity , 構造的類似性）が現在の主流になっている。
ただし SSIM は評価手法を示したものであり具体的な実装はプログラムに依存するため、同じ値でも同じクオリティが保証されるとは限らない。また PSNR にしても SSIM にしても静止画像の指標であり、動的に変化する映像コンテンツ全体のクオリティを示すものではないことにも注意したい。映像の評価方法は ITU 勧告で様々なものが考案されているので気になる人は自分で調べてみては。
参考：NTT 通信トラヒック品質プロジェクト｜技術解説 – 映像品質評価法
ニコンシステム｜分析的画質評価ツール VQ-1200
ニコンはこうした分野にも精力的に取り組んでいる。当たり前か。
VBR でもファイルサイズ予測をしやすくするために全体平均が CBR のビットレート指定と等しくなるよう調整された VBR を ABR と呼ぶ。現在の VBR 実装の大半は平均値の指定及びピーク制限をする方式を採用しているので、VBR と ABR を明示的に分けるケースは少なくなっている。ABR は先読みしながらエンコードを行うシングルパス方式（ 1pass ）と先にデータ全体の分析を行い状況に応じた最適なビットレートの割り当てを行うマルチパス方式がある。シングルパスは短い処理時間で済む反面ストリームのレート変動予測が外れると大幅な品質劣化を伴うので、ライブ配信などリアルタイムエンコードが必要なケースでないならマルチパスを基本とすべきだろう。マルチパスは分析とエンコードそれぞれ1回ずつの 2pass が一般的。3回以上やったところで処理時間に見合うほど画質が向上するとは限らないが、低ビットレートならパスの回数を増やせば増やすほど効果があるのでヒマな人は 100pass とかやってみると面白いかも（できるツールは限られてるが）。
とまあ VBR はトライアンドエラーを繰り返すことでクオリティを追求できるけれども、得られた成果が費す時間や労力に見合うものかどうかは人によって変わってくると思われる。わしは MPEG-2 の DVD 品質を割らなければ別にいいやという考え。
このほか視聴帯域の異なる環境向けに複数のビットレートを出力する方式が MBR で、主にストリーミング向けコンテンツで採用される。
フレームレートと CFR / VFR
1秒間に表示されるコマ数。歴史的な経緯で映画やアニメは 24 コマ、TV（NTSC-SD）は 29.97 コマ。TV の走査線は秒 59.94 コマだけどインターレースなので実質は 29.97 と同じになる。
一般的な動画は固定（一定）フレームレートの CFR だが、VFR はビットレートだけでなく状況に応じてフレームレートも可変にしてしまおう、という発想。たとえばタイトルの表示みたいに変化のない状態と激しい格闘シーンのように、演算に必要な処理量の違いに応じてフレームレートを変動させるわけ。
もっともフレームレートが変化しちゃうとそのフレームの画像を取り出すのはまあいいんだけどタイムコードの算出や映像と音声の同期がやたらめんどうになるしシーク性にも影響を及ぼす。再エンコードなどの際に VFR ソースを正しく扱えないソフトもあり、積極的に採用するエンコーダーは少ない。
Windows Media と疑似 VFR
この、リアルタイムでフレームレートを変化させる狭義の VFR をエンコードに用いるのは今んとこ Windows Media Video くらい。それも指定できるフレームレートは 1 つで、動きの激しいシーンなどで指定ビットレートでは品質に破たんをきたす場合の辻褄を合わせるためにビットレート不足を判断すると自動的にフレームレートを落とす、いわばネガティブな実装となっている。なお再生時に VFR かどうかを意識する必要はない。
そのほか 24 fps の映画やアニメと 29.97 fps の TV のように、複数の固定フレームレート映像を同一ファイルに混在させるようなケースも、広義では VFR として扱われる。というか自炊界隈で VFR といえばこっちを指すことのほうが圧倒的に多い。ピュア VFR も WMV も、自炊では用いるメリットが見当たらないからね（強いてあげるならライブチャットなどの配信くらいじゃろ。
追記
可変フレームレートの最も身近な例はレンダリングする画像を演算で都度生成しているゲームなどの 3DCG 映像で、可能な限りフレームレートを高く保ちつつ情報量の多いシーンで処理負荷が高くなると画質ではなくフレームレートが落ちる、いわばポジティブな実装となっている。また NVIDIA のグラフィックボードで採用されているゲーム実況機能“ Shadow Play ”（現在は Share ）のリアルタイムエンコードもピュア VFR だが、ゲームとは異なり設定したフレームレート（今回は 60fps ）を基準に変動する、いわばニュートラルな実装となっている。
※右下の数字がグラフィックチップによって生成された映像のリアルタイムフレームレートだが、Share によって記録された映像のフレームレートはまた別だからな
･･･ところで TVMW5 は WMV のフレームレート解析機能があるんだけど、たいていの WMV が 1～30fps くらいをうろうろしてるのがわかって面白い。これまで 1fps 以下には出会ったことが無いけど、そういう決まり（最低フレームレート保証？）でもあるのかな。あるいは 1 つの I ピクチャで 5 秒ぶん表示しても fps 的には 1 以下をカウントしないとか。このへんはまだ調査不足。
タイムコードとタイムスケールについて
フレームレートをもう少し突っ込むと、fps は単位時間あたりのフレーム数であると同時に映像出力のタイミングと考えることもできる。
このタイミングを絶対時間としてフレーム単位で記録したものがタイムコード。常にソースの絵を目視しながら作業するノンリニア編集のワークフローだとありがたみは少ないが、テープほか様々なソースが入り乱れ、かつ厳密な時刻同期を求められる放送業界では必須の概念。本番放送はもちろん、粗編集（オフライン編集）したデータをオンラインに反映する際にもタイムコードは欠かせない。
NTSC 方式では SMPTE タイムコード、PAL / SECAM 方式では EBU タイムコードが用いられてきた。書式は SMPTE タイムコードの場合は“ HH：MM：SS：FF（時間：分：秒：フレーム数）”で、値は“ 00：00：00：00～23:59:59:29 ”の範囲となっている。NTSC 方式の秒間フレーム数は 29.97 と整数値を取っていないためこのままだと次第にタイムコードと映像にズレが生じるので、編集ソフトでは一定時間ごとにタイムコードの値を間引いて帳尻を合わせるドロップフレームタイムコードが利用されている（ソースのタイムコードをそのまま用いるのがノンドロップフレームタイムコード）。
厳密には NTSC 方式のコマ数は 30 / 1.001 秒（循環小数 29.970029 ）なのだが、慣例的に 29.97 となっている。
PC など自己完結する環境や閉じた系の範囲であればタイムコードの記述に厳密な決まりはないというか標準は存在しない。コンテナによって書式に差異があるが、1 行ごとに映像のフレーム番号に対応する時間を記録するのが基本で、さらにフレームレートや持続時間を記録しVFRに対応できるものもある。
参考：テレビ就職＆テレビ局転職支援サイト｜タイムコードについて
株式会社ブレーンズシステム｜タイムコード信号について
MKV コンテナを例にするとタイムコードは timecode.txt に記録され、フォーマットは v1～v4 の4種類がある。既存動画からの抽出は gMKVExtractGUI、timecode.txt の埋め込みは mkvmerge GUI で可能。MP4 なら MP4Box 系のツールならたぶんおｋ。
参考：Linux Certif - Man mkvmerge(1)
タイムスケールは定規でいう最少目盛りで、単位時間をどれくらい細かく区切るかを指定する。タイムコードとして刻まれる単位となる。つまりタイムコード（記録頻度、fps）よりもタイムスケールが粗いとフレームの正確な位置は指定できない（そんな設定はほぼ考えられないが）。ミリ秒が一般的。
分解能と量子化
人間の視覚と聴覚は識別のロジックが本質的に異なり、前者は空間分解能、後者は時間分解能に優れる。視覚、つまり映像の時間分解能は 60fps＝1/60 秒が一般的な限界で、TV 放送が 29.97fps のインターレースなのもこのためだ（これは蛍光灯とフリッカーの関係にもいえる話で、60Hz の西日本に比べて 50Hz の東日本のほうがちらつきを感じやすい）。対して音声はミリ秒レベル（ 1/1000 秒）の違いを聞き分けることができるらしい（目が2つあるのは対象までの距離を判断するためだが、耳が2つあるのは音源の方向を判断するため）。なおトンボなど複眼が万単位に発達した生物は動体視力がとても高いが、個々の分解能そのものはたいしたことないらしい。コンピュータで喩えるなら人間の目は様々な処理をこなす CPU 、トンボの目は一定の目的に特化した GPGPU なのだろう。
ちなみに格闘ゲームは 60 fps が基本。コマンドの入力から発生までの最小単位は 1 fps 、つまり1/60 秒だが反射神経の限界速度はおおむね 1/10 秒とされるので、5fps 以下を見て反応するのは事実上不可能となる（もちろん CPU なら 1 fps に割り込むことも可能だが無理ゲー化する ）。FPS などのシューティング系では 60 fps を超えハード性能の許す上限まで細分化するが、これは視覚情報のみならず聴覚情報が敵の察知に重要になってくるためだろう。あとは単純にハードスペック競争の副産物的なものか。
音声は時間的に連続して変化する量なので“静止音”などというものは存在しえないが、そのかわり識別可能な低音と高音の限界があり、年齢によって変化するが一般的に可聴範囲は 100～20000Hz とされている（サンプリング周波数と可聴域の周波数は出発点が異なるのだが表記単位や結果が同じなのでややこしい）。CD-DA のサンプリング周波数は 44.1KHz＝1秒間に 44100 回の標本化を行っているが、音波の折り返しのぶん実際に記録できるのは半分の 22.05KHz となる。最近流行のハイレゾ音源では 192KHz なんてのもあるが、感知できない領域までサンプリングするよりも 24bit なり量子化ビット数を上げるほうがよさそうな。
分解能は標本化（サンプリング）の頻度で決定するが、サンプリングしたデータをどこまで細かく分解するかという精度に影響するのが量子化で、単位は bit。1bit なら2段階、8bit なら256、16bit なら65536、32bit なら4294967296。バイト換算すると 16bit は 2バイトなのでサンプリング周波数が 48KHz なら1秒間のデータは約 94KB。ステレオ音声ならこの倍、5.1サラウンドなどのマルチチャンネルではさらにそのぶん必要。
映像（画像）の場合サンプリングという言葉が使われるケースはほとんどないが、1秒間に何枚の絵を表示するかの頻度を示す fps が事実上の分解能となる。で、1枚の絵につき必要な情報量は「量子化ビット数ｘ三原色ｘ解像度」と音声に比べ桁違いに大きい。たとえば JPEG で使われる 8bit でも Full HD（ 1920ｘ1080 ）なら 8ｘ3ｘ1920ｘ1080 でバイトにすると約 6MB、分解能を 60fps のプログレッシブとすると非圧縮のままなら1秒でなんと 356MB にもなってしまう。こんなの現在の一般的な機材では CPU の処理もデータを送る帯域も保存するストレージもおぼつかない。そりゃ圧縮の技術も進むわけだ。
ただでさえ映像と音声とでは時間軸の分解能が大きく異なるのに、それが VFR ともなると映像と音声の同期を手作業でやるのは CFR に比べてはるかに面倒で、タイムコードやタイムスケールがどうしても必要になってくる。だがしかし、けっこう重要な概念なのにググってもヒットするのはタイムコードについて知ってる前提の解説ばっかりで、ちゃんと説明してるサイトがあんまりないのよね。
レベルとプロファイル
※この項 加筆中
MPEG では様々な伝送路やターゲットに対応できるよう、圧縮パターンを任意に変えることができる。というよりも再生環境によって受け入れ可能なパターンはおおむね決まっているのでエンコード時に適切に設定する必要があるのだが、ターゲットに応じた再生互換性の範囲を決めるのがレベルとプロファイルである。
レベルは解像度の目安で必要となるリソースの量や処理負荷を、プロファイルは機能性を示し圧縮に利用するアルゴリズム（ツール）を定義している。これを切り替えることで再生環境に応じたクオリティの差別化が可能となり、またプロファイルを限定することで再生するアプリケーションや機器の構成を簡略化することができる。
MPEG-2 ( H.262 ) のレベルとプロファイル
十分枯れている。SD 解像度であれば Main
| 呼称 | 内訳 | 例 |
|---|---|---|
| Low | MPEG-1相当の解像度 | Video-CD |
| Main | VGA相当の解像度 | DVD、アナログ放送 |
| High | HDやFHD | デジタル放送、次世代DVD |
| 呼称 | 内訳 |
|---|---|
| Simple | 通信向けに符号化遅延を抑えるようツールを絞ったもの |
| Main | 標準的なプロファイル |
| 4:2:2 | Mainを拡張し高品位な輝度信号を扱えるようにしたもの |
別項でも軽く触れてるけど、
MPEG-4 ( H.264/AVC ) のレベルとプロファイル
MPEG-H ( H.265/HEVC ) のレベルとプロファイル
音声、ほか
もう気力が尽きかけている。
- MPEG-1 Audio Layer
- 名のとおり、MPEG-1 の音声規格。有名なのは Layer 3 だが、MPEG-2 の規格では Layer 2 が用いられる。しかしDVD-Video（NTSC）の再生要件には存在しない。理由はいろいろ考えられるが。ともあれ DVD-Video 用にエンコードするなら音声は AC3 か L-PCM にしておくのが無難。
よく知られていることだが、かつてプレーンな状態の Windows Media Player は MPEG-2 や AC3 のライセンスの関係で DVD を再生できなかった。さすがにもうこの問題で困ってる人はいないだろう。
- AC3
- ノイズリダクションで有名なドルビーによるマルチチャンネル対応オーディオコーデック。AC3 は AudioCodec Ver.3 の略。
- リニア PCM
- 非圧縮音声フォーマット。サンプリングされた情報をそのまま記録するのでファイルサイズは大きいが映像ほど深刻じゃないのは先述のとおり。高音質にこだわるなら 96KHz＆24bit 程度のリニア PCM にでもすりゃいいんじゃないの。
- YUV
- YUV は色空間を表す形式のひとつ。輝度（Y）、赤の色差（U）、青の色差（V）で表す。多くの場合 YUV が 4：1：1 と Y（輝度）4 に対し U と V がそれぞれ 1 で記録されるので色情報の欠落がある。
- なんでこんなことするのかというと、人間の目が輝度の変化には敏感だが色の変化を識別しにくい。また三原色のうち緑の感度がもっとも高い。これを利用して違和感のない程度にデータを間引き情報量を減らすためである。
- インターレースとプログレッシブ
- 映像と走査線を交互に出力するのがインターレース、一気に映像を描画するのがプログレッシブ。TV は前者、パソコンは後者。動画ファイルの解像度表示に 720ｘ480 i もしくは 1920ｘ1080 p と末尾に記号がある場合、映像がインターレースかプログレッシブかを示している。
- インターレースの映像をそのままパソコンで見ると横に線が入って見えるのでエンコードの際にインターレース解除を行うか、再生時にソフトウェアで処理する。