B地区ex｜お勉強：マルチメディア

お勉強：マルチメディア - 動画規格あれこれ

世に出回ってる動画ファイルはずいぶんいい加減なものが多い。

初稿：2005年くらい 2013-03-06 大幅加筆修正最終更新：2021-04-18

字幕についてもここで取り上げます。

前置き

インターネットと DVD によってデジタルメディアが一気に浸透した 2000年代はブームと呼べるほど新コーデックや新バージョンが次々と現れる過渡期だったが、2010年代に入ってからはひと段落し大幅な動向の変化はない。用途によって MPEG-2、H.264/AVC、WMV、WebM にほぼ収束し OS のサポートも広がったため、かつてと比べて再生に躓くケースは減ったと思われる※。次世代動向も軸は 4K/8K と H.265/HVEC に落ち着きそうで混乱は避けられそう（注意する必要がありそうなのは概念の幅が広い VR 動画くらいか）。ただ過渡期に作られたファイルは未だにネットのあちこちを漂ってるし、主流から外れたコーデックを使い続ける人もいるので安心はできない。

そもそもライトユーザーの鑑賞がデスクトップなどのローカル環境で DVD や単体ファイルを再生するスタイルから YouTube などのストリーミングやストアで購入したコンテンツをスマホやタブレットでオンライン再生するスタイルへと移り、コーデック云々の違いを意識する必要がなくなったのが大きい。

Windows 95 / 98 時代からパソコン触ってる人なら、動画ファイルの移り変わりをある程度は感覚的に把握していると思われるが、拡張子とコンテナとコーデックの区別があいまいな人は意外と多い。オレもそうだったし（だからこうやってまとめてるわけだ）。

現在、動画の主流コーデックはすべて前後のフレーム（コマ）との差分情報を考慮したフレーム間圧縮を用いるため 1コマを取り出すのが本質的に向いていない。早送りや巻き戻しなどのサーチ/シークがビデオのようになかなかスムースにならないのもこれが原因で、そのためポスプロの制作現場では DV コーデックなどフレーム圧縮だけに留まるフォーマットが用いられる（もちろんデータサイズは大きい）。

以下、MMname2 を参考にオレ様がわかりやすいよう勝手に分類してみた。まめに手直しはしてるつもりだけど、コンテナとコーデック混在してる部分もあるのでややこしいかもしれない。用語がわかんなかったら~~読み飛ばせ~~都度調べると勉強になるよ。音声規格も必要に応じて取り上げてみる。再生できないファイルがあったらまずはスプリッタかコーデック（ Windows なら DirectShow Filter ）が不足してないか調べること。

もともと動画再生で躓かないための知識とその手助けを趣旨としてお勉強コーナーで最初に書いたのがこのページ（と「ポート開放とはなんぞや」、すでに廃稿）で、初稿からかなりボリュームが増えてしまったけど「なぜそうなってるのか」まで踏み込むとこうなってしまうのよね。そんなわけで、本稿を理解すればコンテナとコーデックに関する悩みはずいぶん減るのではないかと。

…わしにもうちょい画力があれば、「図解：マルチメディア規格」みたいな感じで仕上げるんだけどねえ。

がんばってマインドマップで書いてみたよ！クリックするとサブトピック展開。関係の近いものがなるべく隣になるようにしたらこうなったけど、けっこう適当。

主なコンテナ/ファイルフォーマットとコーデック

全部をきっちり覚えずとも成り立ちとおおまかな概要、誤解しがちなポイントがわかればよし。

成り立ちや主要プラットフォームなどから Legacy MPEG系、ISO MPEG-4系、ポストH.264、QuickTime 系、AVI 系、Windows Media 系、RealMedia 系、Ogg / Matroska 系、Flash 系、On2 系、その他に分類してみたが、わしはこれが把握しやすかっただけなので、あとは各自の好きにするがよし。

※全部覚えなくてもざっくり

ASF → WMV + WMA
MP4 → H.264/AVC or H.265/HEVC + AAC-LC
MKV → それ以外
PS / TS → DVD-Video, BDMV , 地デジ
MOV → Mac, ポスプロ
AVI → 非推奨

な感じでとらえておけばだいたいおｋ

Legacy MPEG 系

最も汎用的な動画規格。今となっては枯れ果てた技術であるが、MPEG-1 / 2 がその後の規格に与えた影響は計り知れない。MPEG 用語集も参照のこと。

国際標準の安心感は他にはないもの。ハードウェアサポートも他の規格に比べて圧倒的。唯一にして最大の弱点は権利問題。MPEG-4 も含め特許はメーカー多国籍軍による MPEG-LA によってガッチガチに管理されている。お金を気にしない立場なら MPEG 系列はいつの時代も最強。

本稿では便宜上 MPEG-4 以前の DVD 世代までの技術を Legacy MPEG 系としている。大半がうんちくなので MPEG-2 以外は吹っ飛ばしてもおｋ。

H.261: “プレ MPEG ”ともいうべきデジタル動画圧縮における初の標準規格。ITU-T の VCEG によって 1990年に制定された。普及規格としては後述する MPEG-1 を待つことになるが、動画圧縮の根本となる技術の確立と映像規格を標準化する上での課題の洗い出し（たとえば画面解像度ひとつとっても統一水準が存在しなかった）という2つの側面で大きな役割を果たした。; たぶん放送や通信業界くらいしかまともに触れる機会なんてなかったと思われる規格なので薀蓄として知っておく程度でよいかと。実装の際は Video codec for audiovisual services at p x 64 kbit/s、オーディオビジュアルサービス用ビデオ符号化方式なんて名称だった（ひょっとしたらコーデックという言葉が用いられたのはこれが初めてだったりする？）。64kbit は ISDN のこと。最初は INS 上で動画を扱う実験だった*。
MPEG-1（ ISO/IEC 11172 ）: 制定は 1993年、正式には ISO/IEC 11172 だが Video-CD で採用された方式といったほうが手っ取り早いだろう。Part 1 の Systems、Part 2 の Video、Part 3 の Audio、Part 4 の Compliance testing などから構成されている。; 後述の Video for Windows がサポートしているので OS インストール直後の Windows 環境でも再生できた。拡張子は MPG。映像のみの場合は M1V が正しい拡張子だが Video-CD 格納時には拡張子が DAT となっている。多重化は後述する MPEG-2 PS に近い。解像度 352 x 240 、転送レートは約 1.5Mbps≒200KB/秒で画質はせいぜい VHS 程度。これは当時主流だった Windows 3.1～95 のマシンスペックでは仕方のないところ。; 今となっては新規で使うことはまずないが、今日でも根幹技術となっているフレーム間予測とこれに伴う動き補償やマクロブロックの概念、離散コサイン変換( DCT )、量子化、エントロピー符号化などを映像規格としてまとめた H.261 の直系であり、その後の動画規格の方向性を決めた重要な存在。また MP3 も MPEG-1 の産物（ISO/IEC 11172-3）である。; MPEG-1 と Video-CD はマルチメディアにおける技術的な道しるべであると同時にデジタルコンテンツの有用性、特にアダルトビデオとパソコンの親和性の高さも示した。ひとは MPEG-1 によって初めてパソコンでエロ動画を楽しむことができるようになったのだ。
MPEG-2（ ISO/IEC 13818 ）: 初版は 1994年。正式には ISO/IEC 13818 だが DVD で採用された方式といったほうが手っ取り早いだろう。別名を H.262 というのだが、後輩である H.263 や H.264 ほどは知られてないようだ。拡張子は M2P だけど再生互換の関係上 MPG としているものが多い。これだけ DVD が普及していると困ることなんてなさそうに感じるけど、DirectShow は MPEG-2 のデコードをサポートしていないため、XP までは OS がまっさらだと DVD を再生できなかった（理由は巨額のライセンス費用）。Vista は Microsoft DTV-DVD Video Decoder が MPEG-2 のデコードをサポートしているので標準再生できたが、7 以降は再びノンサポートに戻っている。また Windows 7 / 8 は基本的に Windows Media Center がプリインストールされていたので結果的に問題なかったが、Windows 10 では Windows Media Center を利用できない。替わりに Windows DVD プレーヤーが有償で提供されている（ Blu-ray には未対応）。; H.262 などの ITU-T 系の規格名称は、“えいちぽいんとにーろくに”と発音するのが正しい、とネットワークエンジニア時代に教わった。今は“ぽいんと”をすっ飛ばすのが一般的みたいだけど。; M2P は映像と音声両方を含む MPEG-2 PS（ Program Stream ）を指し、映像単体の MPEG-2 Video Stream は M2V となる。また M2P は DVD における標準コンテナであるが、デジタル放送や Blu-ray などの次世代メディアでは MPEG-2 TS（Transport Stream）の M2T/M2TS となっている。TS はその名の通り、トランスポートパケットと呼ばれる固定長データの集まりであることが特徴で、MPEG-1 との互換性の確保や記録メディアでの再生を前提として規格された PS と比較して、不安定な経路を想定して誤り訂正が備わっていること、複数のストリームを扱うことが容易なこと（これはデジタル放送を行ううえで実に重要なポイントだ）、ストリーム内のフォーマットを限定しないことなど、メリットが大きい。; なお MPEG-2 PS / TS のように音声と映像を同一のコンテナorストリームに格納することを多重化という。多重化される前の、符号化されたナマの状態の MPEG-2 が MPEG-2 ES（Elementary Stream）。; ※ MPEG-2 TS / PSはコンテナであると同時に多重化方式でもあるが、H.264 AVC と AAC を MPEG-2 TS で多重化して AVCHD コンテナに格納、といった具合に、多重化方式とコンテナは同一である場合と異なる場合があることに注意。; 鑑賞に耐え得る画質という点において MPEG-2 は動画規格のマイルストーンであろう。実際ビットレートを上げれば上げただけ画質は向上するし（ FHD 以上の高解像度では H.264/AVC Main Profile よりも再現性が高い）、何より枯れた技術なので再生でトラブることもないからストレージに余裕があればマスターとして用いてもまったく問題ない。また多重化方式など現在においても MPEG-2 を基盤とした技術は盛んに利用されている。ちなみに MPEG-3 は策定段階で MPEG-2 に吸収されたため規格としては存在しない。
VOB: DVD-Video に格納されている映像と音声のデータ形式で、中身は MPEG-2 Program Stream 。拡張子は VOB だが単体で配布されているものは再生互換のため MPG 等にしていることも多い。また DVD-Video で VOB とセットになってる IFO と BUP は、IFO がチャプターやタイトル、字幕情報などが格納されているファイル。BUP は IFO のバックアップ。; なお DVD-Video の VIDEO_TS フォルダに格納する際、VOB ファイルはほぼ 1GB ごとに分割する必要がある。その理由はあまり知られていないが、DVD-ROM のファイルシステムである UDF における制限で、Extent Length ～同一データとして連続するブロックの長さ～が 30bit 以下という縛りに由来するもの。DVD-ROM に採用された頃の UDF Revision 1.02 はともかく、Blu-Ray 対応な最近の Revision 2.50/2.60 でもしっかり残ってる。この先の大容量メディアとかどうすんだってな（どのみち ISO9660 との互換性を引きずっているうちは 4GB の壁が存在するが）。; 分割された VOB ファイルは VobEdit や VOBMerge などのツールを使えば 1つに連結可能なので、リッピングの際は特に手を加えないのがセオリー。

DVDメディアの商品化は 1996年だが、本格的に普及するのは 2000年 3月に PlayStation 2 が発売された以降…つまり 21世紀に入ってからとなる。このためリマスター化されていない 20世紀の映像作品は画質が悪いものが目立つ。

MP2: MPEG-1 Audio Layer 2。DVD で扱える MP なんたら（但しオプション扱い、DVD-Video 規格で必須対応となっているのはリニア PCM と AC3 ）。MP3 よりも性能は低いが、動画用音声として不満に感じるほどでもない。MPEG-2 Audio Stream 単体の場合の拡張子は MP2。M2P と間違えないこと。
MP3: MPEG-1 Audio Layer 3。MP2 より性能は上だが仕様策定時期の関係で DVD には採用されなかった。拡張子はご存知 MP3。音声に MP3 を使用して作られた DVD は仕様に準拠していないため、再生の際に環境依存の問題があることに注意（不安なら AC3 で作るのが無難）。詳しくは音声エンコードと MP3 を参照。
AC3: ドルビーシステムによる音声コーデック、Audio Codec Ver.3 だったかな。ドルビーデジタルと呼ばれることもある。マルチチャンネルに対応しているのが特徴。DVD-Video 規格でのリニア PCM は 2 チャンネルどまりなので、5.1 サラウンド対応は自ずと AC3 となる。MPEG-2 Audio Stream 単体の場合の拡張子は AC3。; DVD の登場に合わせサラウンド対応のために作られたある意味間に合わせの規格（ LPCM で5.1 チャンネルだとデータサイズが大きすぎて 2時間映画とかに使えない）だけに、圧縮率や音質は MP3 にも及ばず、今となっては DVD-Video の音声以外に出番はない。
Musepack: MP2 をベースに VBR に特化したオープンソースの音声コーデック。160Kbps 以上のビットレートであれば非可逆圧縮中コーデックの中で最も音質がよいという噂。; 音質は目に見える映像と違って主観に左右されやすいので、本気で聴き比べをするのなら、オリジナル音源と比較対象をブラインドテストすること。ソースにもよるだろうが、個人的には 192Kbps 以上ならコーデックによる違いはプラシーボ扱いできると思ってる。; 参考：ハイレゾ音源は人間の耳で聴き分けられるか？禁断のブラインドテストで検証！; ちなみに MP3 にしても AAC にしても、MPEG 系音声圧縮は Fraunhofer IIS 製エンコーダの評判がすこぶるよい（ただし有償である）。TVMW5 も Ver5.2.0.62 のアップデートで内蔵 AAC エンコーダを Fraunhofer IIS に刷新している。
DVR-MS: Microsoft Digital Video Recording の略だったような。その名の通りマイクロソフトのフォーマットで XP の Media Center Edition とかで録画するとこの形式で保存される。拡張子的に再生互換を考慮して DivX なりに変換されてしまうことが多い。もっとも中身はただの MPEG-2＆MP2 or AC3･･･早い話が DVD-Video なので取り扱いは特に面倒でもない。
HD DVD: 再生機器が広く浸透し十分枯れたメディアの DVD をベースに、ハイビジョンやフル HD といった次世代規格への対応を盛り込んで策定された光ディスクの記録フォーマット。次世代メディア争いの趨勢が決した直接の原因は配給会社など大手コンテンツホルダーが Blu-ray を選んだ結果だが、HD DVD の敗因の本質は BD と比較して技術的にどうこうではなく、単に DVD の名称を引きずったのがまずかったんじゃないだろか。“ DVD 互換”は普及スピードなどのメリットがある反面、いかにも“繋ぎの技術”という印象も与える諸刃の剣だったように思う（それに引き換え Blu-ray は名前からして新しい技術っぽいもんな）。; ただ製品展開が進む前に撤退を表明したことで、この手の業界標準争いでありがちな市場の混乱はほとんどなかった。その点は東芝の見切りの良さを褒めたいところ。いずれこんな規格があったことなど忘れ去られていくかと思いきや、HD DVD のノウハウは海を渡り中華 DVDに引き継がれ、新たな黒歴史を紡いでいる。; なお HD DVD も BD もメディアの大きさは CD / DVD と同じ 12cm の円盤だが、BD 規格は CD や DVD との互換性をまったく考慮しておらず再生のサポートもない。ただ BD 対応機器のほとんどは CD / DVD コンパチブルを想定した設計（3波長化）となっているので、事実上再生互換は保たれている。

ISO MPEG-4系

MPEG4＝MP4 とは限りません。

MPEG-4 の規定はものすごく広範囲＆高度で多種多様なパートに分かれているのだが、すべての要件を満たす必要はないため（つか無理）、様々な実装形態が存在する。逆にどれかひとつでも満たしていれば MPEG-4 と呼んでいいわけで、それが MPEG-4 に関する幾多の誤解を生んでいるほか“ MPEG-4 対応のプレイヤー”が存在しない理由でもある（対応を謳っても相互運用性が確実に保証されているわけではない）。

そんなわけで、MPEG-4 はコンテナ、多重化、映像と音声それぞれのコーデック、DRM と様々な側面を持ちつつ拡張も盛んに行われている。いや器も中身もすべて総括しひと括りに扱っている、とするのが適切か。とにかく MP4 ファイルは MPEG-4 だけど MPEG-4 は MP4ファイルとは限らない。MPEG-4 の混乱や誤解の核心はこのへんにあるんだと思う。

他にも MPEG では B フレーム、QPEL（ 1/4 ピクセル精度の動き補償）、GMC（グローバル動き補償）、MPEG 量子化マトリクス、適応的量子化など符号化に用いる技術をツールとし、用途に応じたいくつかのツールの組み合わせをプロファイルとして定義している。いってしまえばこのプロファイルに準拠していれば他にどんな独自技術を使おうが MPEG（ぶっちゃけ MPEG-4 Part2 ASP ）を名乗れることが「MPEG-4 は互換性があるんだかないんだかわかんねーよ！」とこれまた初心者（誰）を惑わす障壁となった。

MPEG-4（ISO 14496）の主な規定
部	内容	備考
Part 1	システム	多重化方式など
Part 2	動画	Advanced Simple Profile、準拠コーデック多数
Part 3	音声	AAC
Part 10	動画	H.264/AVC
Part 12	コンテナ	ISO ベースメディアファイルフォーマット
Part 14	コンテナ	いわゆる MP4
Part 15	コンテナ	Part 14 の H.264 向け拡張仕様

※こんな調子で Part 23 まであるが頭に入れとくのはせいぜい上の7つで十分。

亜流である DivX や Windows Media などのほうが先に普及してしまったが、Mac では MPEG-4 成立の背景事情の関係でむしろ主流（お手本にしたのが QuickTime なので基本的にほぼ同じ）。以下、ISO 標準ではなくても MPEG-4 と関連性の高い規格も含めピックアップ。

ISO MPEG-4（ ISO/IEC 14496 ）: ストリームの多重化とフォーマット形式、映像と音声にまつわる様々な規格。; 前述のように ISO MPEG-4 は Part という単位で様々な規定が存在するが、ISO MPEG-4 といった場合、初期に策定された多重化などシステムの基本仕様である Part 1（ISO/IEC 14496-1 System）に映像と音声の規格である Part 2（ISO/IEC 14496-2 ASP）と Part 3（ISO/IEC 14496-3 AAC）の組み合わせを指すことが多い。ちなみに DivX も Xvid も MP43 も WMV9 も VP62 も RM40 も Part 2 準拠（H.264/AVC は Part 10）。; 本稿ではこれらをひっくるめて MPEG-4（Part 2）系アルゴリズムとして扱っているが、コーデックチェックで ISO MPEG-4/ASP と判定されるものは基本的に QuickTime でエンコードした FourCC が MP4V の MPEG-4/ASP。; MPEG-4 の本来のねらいとして、必要な要件をプロファイルとしてまとめることで再生互換性の確保を目指している。ただ初期の規定は携帯機器などローレベルな対応に追われたためか高画質化があまり考慮されておらず、さらに策定に時間を要し機器の性能や帯域の向上で実態が規格を追い越してしまった。広範囲の環境をカバーし汎用性を高めつつ画質の向上も達成した H.264/AVC が浸透した今となっては純然たる ISO MPEG-4（後述の MPEG-4 ASP ）は事実上役目を終えたと思う。
MPEG-4 ASP（ ISO/IEC 14496-2 ）: 初期の MPEG-4 の映像パート。この Part 2 準拠のコーデックは多数存在するが、事実上 ISO MPEG-4 ASP≒QuickTime と考えてよい。コンセプト※はよかったのだが主に低ビットレートでの利用に重点が置かれていたことが災いし、テレビや PC などの家庭鑑賞では MPEG-2 を置き換えるほどの魅力に欠けていた。自炊ブームにあっても DivX や Xvid、On2 などの高性能コーデックに押されっぱなしで、肝心の配信でもストリーミング大手の Microsoft や RealNetworks は（ Part 2 準拠とはいえ）自社コーデックを持っていたし Flash がサポートしたのも VP62 に H.264/AVC とさしたる出番もなかった。; ※様々な用途や将来性を考慮した結果、Part 2 のボリュームは桁違いに大きなものになった。規定されたプロファイル/レベルは聞いたことのないようなものも含め相当な数にのぼるほか、プロファイルに存在しない符号化ツールもいろいろあるらしい（実は MPEG-2 も膨大な特許で溢れかえってるけど実際に必要なものは1割にも満たない数で、あわよくばのライセンスゴロと特許プールの延命が狙いなのは明白だ）。その結果 Part 2 は誰も全体を把握できない非現実的なシロモノになってしまい準拠コーデックの乱立や相互運用の困難さへと繋がったわけだ（その反省から生まれたのがご存じ Part 10 の H.264/AVC ）。すべての要望に応えようとするとかえって混乱を招くだけ、というよい教訓。
AAC（ ISO/IEC 14496-3 ）: 最近の主流音声コーデック、Advanced Audio Coding の略。MP3 の半分のレートで同等以上の性能、らしい。実際、MP3 は低ビットレートでの性能が悪い（ 64Kbps を切ると正直使い物にならない）ので、128Kbps 程度で聴き比べれば素人でも違いはわかる（つまり 320Kbps で比較するのはナンセンス）。; 通常利用されているのは AAC-LC（Low Complexity）で、MPEG-4 やデジタル放送なんかで採用されている。さらに圧縮率を高めた HE-AAC（High-Efficiency）もあるが、高音域と中低音域を分離して符号化する方式のためビットレートを上げてもたいして高音質にはならない。反面、低ビットレートでの破綻が少ないため音質を犠牲にしても映像にデータを振り分けたい、そんなケースに向く。目安としては 64Kbps 以上なら AAC-LC、64Kbps 以下なら HE-AAC。; なお AAC には MPEG-2 AAC（ISO/IEC 13818-7）と MPEG-4 AAC（ISO/IEC 14496-3）の 2種類が存在する。主流は後者で圧縮時の機能の違いによりさらに細分化されているが、AAC-LC 以外は環境によって再生できないケースが多々あるので注意。; 参考：2014年4月15日の屁理屈｜AACといっても実はけっこう種類がある; たまにコーデック判定で ADTS と検出されることもある。どうやら放送向けのヘッダ形式らしい。
H.264（ ISO/IEC 14496-10 ）: MPEG-4 の真打、高画質かつ高圧縮の映像コーデック。H.264 は通信業界の標準化機構 ITU-T の規格名称で、MPEG-4 的には MPEG-4 Part 10 AVC なのだけど、MPEG-4 があまりに多岐に渡るせいかこちらで呼ぶ人は少ない（本稿では H.264/AVC で統一する）。AVC は Advanced Video Coding の略。FourCC は AVC1 だが AVI（VfW）コンテナに格納した場合など一部に H264 表記も見られる（ FourCC の H260～H269 は Intel によって申請済み）。ベースになったのは ITU-T の映像専門チーム VCEG が MPEG-2 や MPEG-4 ASP に対し最低でも倍の効率を目標に検討していた次世代コーデックの H.26L。その後 VCEG と MPEG のエンジニアで結成された JVT に開発が引き継がれ、ITU-T と ISO/IEC それぞれの標準化に至った。; Part 2（ISO 14496-2 ASP）同様にプロファイルとレベルによってポータブル機器から HDTV まであらゆる用途に対応するフレキシブルさはそのままに、高画質＆高圧縮を達成して現在の主流となった。既存の動画コーデックと同様の基本アルゴリズムを継承しつつ個々の符号化ツールの改良により高い効率を実現している。反面、圧縮/伸長に必要な演算量は従来の数倍から数十倍と極めて多い。後述する ffdshow あたりだと再生負荷がやや高めなのが難点か。仕様が一本化されてるぶん互換性も高いが、エンコード時にプロファイル＆レベルを無闇に上げすぎると再生可能な機器が激減する恐れがある。逆にフル HD など高解像度のエンコードを低いプロファイルのままがんばっても画像破綻が起きやすくなる。なお当初の規格には Baseline / Extended と Main Prifile しか存在しなかったが、MPEG-2 との HD エンコード比較で Main Profile の画質に納得いかなかった PHL（パナソニックハリウッド研究所）副所長の柏木吉一郎氏により High Profile が加わることになった。; Part 2 も Part 10 も映像に関する規定だが、利用者視点でみると前者は見境なく要件を並べたためプロファイルの違いが不明瞭でどれに対応すればよいのかわかりにくい。後者は実装を前提に要件を絞り込んだため定義が明確である。言葉を変えれば前者はプロファイルがメーカー別、後者は目的別に規定されているので、再生機器も対応するプロファイルがどれかを明示するのが容易になった。; ~~FLV5~~ F4V フォーマットで Flash も採用。日本ではその Flash を除き MPEG-4 の標準コンテナ MP4 に格納する人が多いが、海外では自炊を中心に MKV の人気も高い。これはエンコード環境（使うソフトとかね）や技術に対する思想の違いが大きいと思われる。エンコーダも多数存在するけど、オープンソースの x264 の評判がよい。ペガシスも MainConcept エンジンを諦め x264 に乗り換えた。~~なお Windows は最新の 10 も含め H.264/AVC をサポートしていない。~~サポートしてないのは MP4 コンテナだった。H.264/AVC はサポートしているので、MKV に格納された H.264/AVC とかは普通に再生できる（つまり必要なのは MP4 Splitter 。; なお MPEG-4 系コーデックの中でも B フレームの扱いがかなり特殊で、あとからストリームコピーで別コンテナに無劣化変換すると音ズレが起きてたりすることが多いため、AVI コンテナへの格納は可能であってもやめたほうがよい。; 参考：Xia's | H.264 動画を AVI コンテナに入れた際の問題点とか
MP4（ ISO/IEC 14496-14 ）: MPEG-4 の標準コンテナ。MPEG-4 Part 12 及び Part 14 で規定されている（ Part 15 も拡張仕様の規格だけどとりあえず忘れていい）。より厳密には Part 12 の ISO ベースメディアファイルフォーマット（ISO/IEC 14496-12）の格納を前提にマルチメディアコンテナとしての拡張が施されたものが Part 14 の MP4 コンテナ。正式名称は ISO/IEC 14496-14:2003 と長ったらしい。標準拡張子は .mp4。; Part 12 をサブコンテナとし中身が Part 12 準拠であればなんでもつっこめるのが MP4、ともいえる（少なくとも過去すべての MPEG 系規格との後方互換がある）。映像や音声ストリームそのものは Part 12 に格納しつつ、Part 12 だけでは満たせなかったタイムコードやオブジェクト符号化などストリームのメタ情報を記述できるのが特徴。MP4 が QuickTime（MOV）のスーパーセットと呼ばれる理由もここにある。; ちなみに Microsoft も MPEG-4 特許連合の仲間ではあるが、大人の事情（何）により DirectShow は MP4 コンテナをサポートしていない。おかげで Windows XP の Windows Media Player も MP4 の標準再生ができなかった。Vista 以降は DirectShow の後継 API、Media Foundation が MP4 コンテナをサポートしている。

ISO MPEG-4 と関連の深いもの、似て非なるもの

M4A / M4V / M4P: .m4a や .m4p、.m4v などそれっぽい拡張子がいくつかあるが、いずれもアップルが iTunes でコンテンツ配信する際に勝手に拡張したもので ISO規格ではない。 MPEG の慣例に倣うと m4a は MPEG-4 Audio Stream、m4v は MPEG-4 Vieo Stream、m4p は MPEG-4 Program Stream 以外考えられないわけで、それを DRM まで組み込んだ自社の独自規格に使うとか正気を疑うわ。
ALAC: アップルロスレスオーディオーデック（ Apple Lossless Audio Codec ）。単に Apple ロスレス、あるいは ALAC と呼ばれる。圧縮率はオリジナルの 50～70％程度。その名の通りアップル独自のロスレス音声圧縮方式で MPEG-4 とはまったく関係はないが、格納コンテナに M4A を用いることから誤解されやすい（ M4A も MPEG-4 の規格ではない）。対応ツールがあるかわからんが MKV にもたぶん突っ込めるだろう。; ロスレス圧縮は FLAC がよく知られていたが Apple には音楽配信で市場の 6割を超える圧倒的シェアを持つ iTunes という強みがある。iTunes Store での採用と同時に ALAC がロスレスの双璧となったのも当然の成り行きだろう。ロスレス自体が世代交代の緩やかな方式なので当面は FLAC と ALAC の時代が続くと思われる。なお当初非公開だった仕様はリバースエンジニアリングによるエンコーダやデコーダが登場したことによりオープンソース化された。
3GPP: MP4 派生コンテナ。ドコモ/ソフトバンク系の第三世代携帯電話で使われている。拡張子は 3GP。動画に H.263 か H.264、音声は AMR か AAC を格納できる。
3GPP2: MP4 派生コンテナ。au 系の第三世代携帯電話で使われている。拡張子は 3G2。当初 3GPP との違いは TCP ストリーミング対応及びムービーフラグメントの採用だったが、3GPP ものちにムービーフラグメントを導入したため機能面の差は事実上ないに等しい。; だがしかし、コンテナの互換性はない。どっちも MP4 のサブセットみたいなものだからボックス構造で、入れる中身も映像が H.263、MPEG-4、H.264 の音声が AAC か AMR なんだけどねえ。
AVCHD: ハイビジョン映像をビデオカメラで記録する際に用いられるフォーマット。パナソニックとソニーの共同開発（！！！！！）だけあって瞬く間に普及した。VHC-C、8mm、miniDV に続く現在の民生用ビデオカメラにおける事実上の標準記録方式といってもよい。中身は H.264/AVC と AC3 だが、1920ｘ1080 のフル HD 記録を考慮しハイプロファイル＆レベル 4.0 以上と規定されている。また多重化も MPEG-2-TS（ゆえに拡張子は .ts や .m2t ）と既存の標準化技術の組み合わせで、早い話が DVD の映像パートを H.264/AVC に変えたようなものである。ともあれこれまでのビデオカメラの記録方式とくらべて格段に品質が向上しているので、民生用のビデオ/デジカメのみならず業務用カムコーダなのでの採用もある（高品位な音声向けにリニア PCMを用いることもできる）。難点はビットレートの上限が 28Mbps（3.5MB/秒）に留まっていることで、フルHD程度の再生であれば十分でも、オール I ピクチャ記録や 4K/8K といった高解像度での記録ではビットレート不足となってしまう点だろう（この解消を図ったのがソニーの提唱する XAVC）。; 現在は AVCHD Ver.2.0 となり、フルHD の 60fps プログレッシブや 3D 記録に対応している。
AVCREC: ハイビジョン映像を DVD メディアに記録する際に用いられるフォーマット。Blu-ray Disc Associationによって規格化された。映像コーデックは H.264/AVC で、著作権保護機能も組み込まれているため品質を落とさずに地デジ放送を記録できるのがポイント※。DVD-Video の規格に準拠しているわけではないことに注意（論理構造は BDMV フォーマットに則っているものの Blu-Ray との互換性も当然ない）。; ※先行した地デジの録画方式 DVD-VR の映像コーデックは H.262 …いわゆる MPEG-2 なので、メディアの記録容量や著作権保護の関係から SD 品質に落とさざるを得なかった。
AVC-Intra: パナソニックの策定した業務用コーデック。ベースは H.264 で、その名の示す通りイントラフレームのみ用いるため編集性に優れる。ビットレートは 100 ないし 50Mbps なのでプログレッシブ映像だと 300KB 程度（ IJG 画質で 60～70 くらい）だが、それでも通常の H.264 /AVC に比べればはるかに高画質。

フォーマットとリビジョン、記録メディア

※執筆中（コーデックやコンテナと記録メディアの関係は深い、ただ独立した記事にしたほうがいいかもしんない）

CD / DVD / BD はそれぞれいくつかの規格を内包しているが、MPEG-4 とかかわりが深いのは BD 。

BDMV / BDAV: どちらもハイビジョン映像の記録フォーマットで、端的にいえば DVD-Video や DVD-VR のようなもの。いや“BD-ROM に記録する規格が BDMV ”で、“ BD-R や BD-RE に記録する規格が BDAV ”といったほうがわかりやすいか。立ち位置的に BDMV は BD-Video と呼ばれることも。AVCHD 同様、多重化には MPEG-2-TS を採用している。中身は事実上 H.264/AVC と AAC で、この組み合わせが MPEG-4 の標準セットなのだろう。

ほかMPEGにどんな技術や規定があるかは、公式サイトのSearch all MPEG standardsをご覧あれ（要英語力）。

ポストH.264 ～オーバー 2K 時代～

2010年代に入り H.264/AVC は完全にスタンダードとなったけど、その次･･･家電・映像業界の後押しする 4K/8K に向けての動きも活発になってきた。とはいえそんな高解像度にコンシューマのニーズがどれほどあるのか怪しいものだしコンテンツ供給がまったくおいついていない状況だが、ここではひとまず策定段階から 4K/8K を想定した規格を中心に取り上げることにした。

H.265（ ISO/IEC 23008-2 HEVC ）: またの名を HEVC。番号からわかるように現在の主流映像コーデックである H.264/AVC･･･つまり MPEG-4の後継規格。当初は H.264 とは別物として開発される予定だったが、結局 H.264 の発展系に収まった。4K/8K を想定し同画質での圧縮効率は H.262（DVD）の 4倍、H.264 の 2倍とされている。ただし H.264 がかつてそうであったようにエンコード＆デコードの負荷がかなり高い。エンコード / デコードともに Core 2 時代のマシーンではほぼ不可能、Core i7 でも最低限第三世代以降でないと実用レベルに達しない（ Haswell 以降はハードウェアデコーダーを搭載しているので、これに対応するプレイヤーであれば低負荷で処理可能。; ちなみに ISO/IEC 23008 は MPEG-H と呼ばれ、多重化方法 MMT の Part 1（ISO/IEC 23008-1）、映像コーデック HEVC の Part 2、3D オーディオ向け音声コーデックの Part 3（ISO/IEC 23008-3）が規定されている。23008 群の規格が増え採用が目立ち始めたら MPEG-H 系として独立させるが当面はこのままでよいだろう。; HEVC 採用のパッケージメディアはまだアダルト配信の一部で見かけるくらいだけど、4K の試験放送はすでに行われているし 2014 年モデルの 4K テレビから HEVC のハードウェアデコーダを搭載した製品もぼちぼち登場している。スマホなんかを想定したハードデコードチップの出荷が 2014年内から 2015年にかけてと噂されてるので、ブレイクは 2015年中旬あたりか。なお FourCC は HEVC と H265 の2つを確認している（マイクロソフトに登録されているのは H265 のようで）。H.264 の後継なら AVC2 とか EVC1 にすれば整合性取れていいのにね。確認できるコンテナは今のところ MKV と MP4。前者はさすが、後者は HEVC 格納の場合は MP5 とかでよかったんじゃないの。; ソフトエンコーダは早くに x265 が登場し、商用も含め採用が多い（ TMPGEnc Ver.6 のエンジンも x265 だ）。フリーのデコーダーもボチボチ見かけるようになった。主要なプレイヤーはおおむねサポートしてるし ffdshow、DivX あたりもフォローしてるので利用者は増えつつある。ハードウェアエンコーダ/デコーダーでは Intel Media SDK に HEVC Pack があり、GOM Player などが再生サポートに利用しているほか、グラフィックチップベンダー NVIDIA のハードウェアエンコーダー、NVENC も Maxwell 第二世代で H.265/HEVC に対応している。; 2020年を目処に予定されている 124/128度CS の 4K や 110度CS の 8K といった次世代放送で、圧縮方式に HEVC が採用される見込み。また MMT や TLV など新たな多重化方式を標準採用することも決定している。4K はフル HD の4倍、8K では16倍の面積比なので情報量も当然すさまじいことになる。確かにスループット的に H.264/AVC では厳しい。むしろ圧縮効率が倍でも苦しいんじゃないかと思うのだが、さて。
XAVC / XAVC S: ソニーが提唱する、60fps フルHD を超えるような記録を想定したカムコーダー及びノンリニア編集向け動画記録フォーマットの規格。解像度は 3840ｘ1920 の ITU 4K と 4096ｘ2160 の DCI 4K 双方に対応、H.264/AVC で 4:4:4 の 12bit 記録をサポートしているように AVCHD に比べて高解像度や高ビットレートの映像を格納可能となっている。4K 記録でのビットレート上限は 960Mbps（120MB/秒）、フルHD でも 440Mbps（55MB/秒）を確保している。格納には汎用性や拡張性に優れた業務用コンテナの MXF が採用された。; ほぼギガビットの領域となる 960Mbps を 60fps で割ると1コマあたり 2MB（オール I ピクチャの場合）で、これは ITU 4K サイズであれば品質80程度の画質で保存した JPEG に相当し（参考：JPEG の圧縮率と画質の詳細比較）、スチルの画質としては物足りないが動画切り出しなら申し分ない水準といえる。; 上記の通り XAVC は 4K 動画記録の要件を市場のニーズを汲み取りつつオープンな規格としてまとめただけでソニー独自の技術や基準を用いているわけではない。すでに放送業界では浸透しつつあるが、~~ソニーの規格というとベータに始まって市場を二分した挙句に敗北するイメージがどうしても付きまとう~~ AVCHD の時とは違ってパナに声掛けてないのが気がかり（ HDCAM からの転換期で一気に勝負をつけようとしているのかも。; XAVC S は XAVC のコンテナ（カムの連中はラッパーって呼ぶよね）を MP4 として民生用に扱い易くしたものと思えばよい。コンテナ以外にも Long GOP のみで IntraFrame の非サポート、上限ビットレートや記録ビットを抑えカラーサンプリングも 4：2：0 のみに留めるなど XAVC よりも控えめの仕様となっているが、それでも AVCHD に比べればずっと高画質の記録が可能となっている。ちなみに MP4 準拠といってもすべての MP4 が XAVC S 機器で取り扱えるわけでもないが、受け入れプロファイルやレベルの不一致をはじめこのへんは動画で当たり前に発生する話なので安易にソニー叩きとかの根拠にしないよーに。; 参考：XAVC | Sony
MXF（ SMPTE-377M～）: 業務用途での映像や音声の格納を想定して作られたコンテナで Material eXchange Format の略。Pro-MPEG フォーラムにより開発され AAF アソシエーション、EBU との共同開発プロジェクトを経て SMPTE 規格として標準化された。イメージとしては MKV コンテナのプロ仕様だろう。おそらく放送業界における事実上の標準フォーマットで、特徴的なのは映像や音声はもとより、放送業界で必須のタイムコードをはじめ様々なメタデータ、画像や台本のような関連ファイルなど番組や作品にまつわるすべての情報を包含することを目的としている点にある。; ペイロードに既定はなく映像や音声の圧縮方式に依存しないが、圧縮方式毎に具体的な格納方法についての取り決めが規約化されている。メタデータについても標準メタデータ（DMS-1）とそれ以外のダークメタデータに区分し、標準メタデータは必須扱いでダークメタデータについては未対応のアプリケーションはスルーすることで全体の互換性を保つようになっている。; すでに XDCAM をはじめ MXF フォーマットをトランスコードやフォーマット変換することなくネイティブに扱えるデバイスの浸透は進んでいる。米 CNN や英 BBC などの大手放送メディアでもシステムの基本フォーマットとしての運用が進んでいる（既存ソースの絡みもあって MPEG-2 SD でスタートし、新規ソースから徐々に MPEG-2 HD に。やがて MPEG-4 や H.265/HEVC の 4K/8K も増えるのだろう）。国内も NHK やフジテレビがデジタルアーカイブの保存フォーマットとして導入し、現在ではごく当たり前に運用されている。; 基本文書の SMPTE 377M（オーバービュー）に始まり、操作方法やコンテナの詳細仕様、メタデータの詳細など関連ドキュメントは多く現在も増え続けている。何しろ従来の VTR テープ＋記録表による運用を置き換える業界の将来を見据えたプロ用途だけあって非常に汎用性や拡張性に優れている反面、一般人におよそ縁の無い複雑な機能も盛りだくさんで、一次記録や完パケの器として使うにはちょっいとヘヴィすぎるシロモノ。XAVC S が MP4 にコンテナを変更したのも当然といえる。; 参考：Sony ProMedia｜放送業界用語：MXF
MPEG-DASH（ISO/IEC 23001-6）: DASH は Dynamic Adaptive Streaming over HTTP の略。文字通り HTTP プロトコル上でストリーミングを行うためのプロトコルでコンテナやコーデックではない。プログレッシブダウンロードのようなこれまでの HTTP ストリーミングとの最大の違いは動的ビットレート制御で、あらかじめ異なるビットレートのソースを用意しておくことで帯域状況に応じてこれを切り替えることにある。また専用の配信サーバ（ソフトウェア）が不要なためコストメリットに優れる。; 解像度やビットレートなど配信ソースのメタ情報は MPD として定義され、XML で記述される。Windows Media における ASX や WVX に moov atom を組み込んだと考えてよく、クライアントは MPD を読み込むことで必要なソースにアクセスする。動画のほか、ペアレンタルコントロール、広告挿入、DRM 制御なども可能。わかりやすい例としてはすでに YouTube で実装されているアレ。YouTube 等でサーチ/シーク不可の動画を保存すると DASH-VIDEO 形式で保存されることがあるが、中身はたいてい AVC1＆AAC なので VLC などを使ってコンテナを MP4 なりに変換すればよい。; 参考：簡単な MPEG-DASH ストリーミングプレーヤーの構築

QuickTime系

Mac では圧倒的に強いものの Windows ではイマイチ。きっと QuickTimePlayer のせいだろう。QuickTime 自体はライブラリというかマルチメディアのフレームワーク。オレは Mac 持ってないから細かいことはよくわからんけど、マルチメディアに対するアプローチの中で時間軸の概念や位置づけが Mac と Windows では決定的に違う気がする（名前からして QuickTime だもんな。取り扱いはその QuickTime ライブラリに依存するところが強い。

なおMPEG 系規格との関係が非常に強い。というか MPEG-4 の策定に Apple が強く関与しているので自ずと QuickTime との共通点も多いわけ。

MOV: Mac の標準マルチメディアフォーマット。拡張子は MOV だけど QT になってるときもある。Microsoft における AVI のような位置づけ、つまるところファイルコンテナなので中身は（QuickTime のライブラリにあれば）なんでもよいのだが、最近はほぼ H.264/AVC 。ぶっちゃけ MOV は ISO ベースメディアファイルフォーマットそのものなので、MP4 は MOV のスーパーセットという扱いになる。; なお D810 をはじめ、二コンのデジ一眼は MOV コンテナを標準採用している（映像は H.264/AVC だが音声がリニア PCM 記録なので MP4 コンテナだとプレイヤーによっては支障をきたすからだろう）。再生環境の幅はあまり広くないが、ポスプロ現場での運用実績は豊富でぶっちゃけ AVCHD よりも後処理での融通は利く。
Apple Intermediate Codec: Mac 環境専用のノンリニア編集ソフト Final Cut Pro で中間ソース保存のために開発された非可逆コーデック。通称 AIC 。非可逆だが時間軸圧縮は行わずイントラフレームのみで構成されるため、劣化が少なく編集性も高い。そのぶんデータレートは最大 80Mbps と DVD-Video のMPEG-2 Stream とは桁違いで BD 並みかそれ以上の容量を消費するが、それでも非圧縮 RAW の2割程度で済む。処理負荷も非常に少ない。動画の高解像度化に伴い後述する ProRes に引き継がれたが、現在でも HDV ソースを直接編集する程度であれば AIC で十分賄える。; なお Mac 環境で AVCHD ファイルを取り込むと iMovie によって勝手に AIC に変換されてしまい、Windows で再生できない MOV ファイルを生み出すこととなった。デコーダーが QuickTime のライブラリに組み込まれているので iTunes なりをインストールしていれば Windows でも再生可能だったのだが…。
Apple ProRes: 2007年に Final Cut Studio 2 の登場とともに発表された、ポスプロ編集向け中間コーデック。読みは“プロレズ”と濁る。使いどころは AIC と同じだがプロファイルが多様化し ProRes 4444（ 330Mbps ）/ ProRes 4444 XQ（ 500Mbps ）では YUV 444 及び RGB をサポート（ロスレス）。XQ は 1時間で 225GB に達するが、それでも非圧縮 RAW に比べれば（ｒｙ映像制作現場では（特に ProRes 422 HQ, 220Mbps が）納品メディアの主要コーデックとして映像業界では広く浸透しているほか、業務用カムコーダーやシネマカメラ、Panasonic LUMIX DH4 など一部のデジタル一眼の記録方式にも採用されている。; 難点は書き出し可能なツールが Final Cut 系などごく限られていること。Windows 環境、特にノンリニア編集では非常に扱いづらい。さらに脆弱性を抱えたまま QuickTime for Windows サポートをアップルがひっそり（というわけにはいかなかったがｗ）終了したため今やデコードすら危うい。Adobe や EDIUS など定番の動画編集ツールは QT ライブラリなしでの ProRes デコードにネイティブ対応したが、 Adobe はけっこうおかんむりでもう ProRes やめようぜと代替の中間コーデックに SMPTE VC-3 として標準化された Avid DNxHD / DNxHR や同じく SMPTE 標準 VC-5 のベースとなった GoPro CineForm を推奨している。

そんなわけで、Apple のこういうところが嫌いなのよね。

業務用の一次記録や中間記録コーデックとして ProRes の競合にあたるのは Avid の DNxHD / DNxHR、アドビの CinemaDNG、ソニーの XAVC などで、テープやディスクメディアも含めると HDCAM SR（ MPEG-4 SStP ） / XDCAM HD422、DVCPRO HD といったあたりも入る。いずれも 2K やそれ以上の解像度を想定した数百 Mbps の高データレート、YUV 422 / 444 やオール I ピクチャ記録による高品質・高編集性といった特徴があり、後述する可逆圧縮系コーデックの延長にあるものと思ってよい。

そんなわけで、一般人…とりわけ自分で動画撮影しないひとにはほとんど関係ないので ProRes のことは忘れていい。

AVI系

AVI は Audio-Video Interleaved の略で、映像と音声を同一のファイル（コンテナ）に格納するための仕組み。ここではデフォルトの拡張子を AVI とする方式を含めたが、AVI 自体はコーデックを特定しない。コーデックごとに VCM / ACM を用意してやればなんでも格納できてしまう。

なおインターリーブ（ Interleave ）とはコンテナ内でのデータの配置のことで、映像データの後ろに音声を持ってくるか（ノンインターリーブ）、映像と音声を同時に配置するかの2種類があり、再生時に同期を取りやすいことから主流は後者。AVI の場合 RIFF を利用して同期を取っているが、正確さに欠けるので音ズレを引き起こしやすい。

参考：pfsource - AVIフォーマットの違い

… AVI のツラいところは、その登場がマルチメディアコンテンツが加速度的な成長を見せ Windows と The Internetによりコンピューティングが社会基盤として確立するタイミングと重なったことで、見切り発車な規格に器を超えたアイディアを背負わされたことにあるんだと思う。

AVI: 元祖AVI、マイクロソフトの標準動画フォーマットというかファイルコンテナ。Windows3.1 で動画を再生するにあたって、API である Video for Windows とともに Windows MME の一部として発表された。1992年のことである。; ベースとなっているのは RIFF フォーマットで格納できるのは Video for Windows が扱えるもの。AVI の限界はこの RIFF 形式や Video for Windowws の制約に由来するものが多い。ファイルサイズの上限は 2GB。コンテナを 2GB 単位に分割することでこの制約を乗り越えた参照 AVI という形式もあるが（考えたのはアイ･オー･データ）、参照先ファイルの場所を変更すると再生できなかったりで使い勝手はイマイチ。; 時代的に仕方ないとはいえ、Video for Windows は“ 1 frame in 1 frame Out ”、デコードバッファに入ってきた順番に1フレーム単位での出力が基本であり、前後フレーム参照ができないので B フレームをまともに扱えないのがかなり痛い。さらにタイムコードの概念がなく VBR / VFR にも未対応など時間軸の絡む要素にはてんで弱い。ハッキングによる機能拡張も盛んなようだが、どうしても AVI コンテナに格納するなら映像も音声も CBR / CFR で。とまあ前世紀の遺産に等しいが、枯れ果てたフォーマットなのでとりあえず AVI をコンテナにするケースは今でも多い。; XviD など B フレームを用いるコーデックでストリームを AVI コンテナに格納する ≒ Video for Windows で扱う場合フレームをニコイチにする packed bitstream が一般的だが規格に則ったデコーダが packed bitstream を解釈してくれる保障はない。また VBR の格納はダミーデータでレートの谷を埋める 0 padding で擬似的に CBR に見せかけているが、MP4 コンテナは 0 padding を認めていないし多重化の際にパディングされたデータを除去する（のが既定の処理）ので、これまた規格に則ったデコーダが正しく扱えない可能性がある。; なおコンテナとは別の側面として、ソースをフレーム単位でそのまま保存する無圧縮 AVI と呼ばれるものもある。前記事で触れた RAW Video がこれに相当する。オリジナルを符号化していないので再生に特にコーデックが必要とはならないが、早い話1フレームごとにビットマップ形式で保存するようなもので、とにかくサイズがバカでかいからスループットべらぼうに食うし長時間の記録では HDD 容量がいくらあっても足りないし、特別な目的でもない限り使うことはまずない。んまあ動画記録の原点ってことで頭の隅にでも置いとけばよし。
AVI2 （ OpenDML ）: API を Video for Windows から DirectShow に変更することで 2GB の制約を越えた AVI。正式には OpenDML AVI File Format Extensions だが忘れていい。参照 AVI と違い、RIFF 形式のデータを複数連結することで互換性を保ちつつ2GB超えを可能にした。最近の大容量 AVI は基本的にこっち。; ぶっちゃけ AVI と AVI2 はまるで別物なのだが、拡張子が同じ AVI であること、DirectShow が 2GB 未満の AVI ファイルを事実上 Video for Windows 互換として扱うことから、視聴者がどちらなのかを意識する必要はほとんどない。
DivX: OS 標準形式は別にして、追加コーデックという点でいっときはたぶん世界で一番普及した映像コーデック。アルゴリズムは MPEG-4 系（ Part 2 ）で標準コンテナの DIVX は実質 AVI。バージョンアップも盛んに行われたが、DivX 3 時代には Microsoft コーデックのパクリ疑惑※、DivX 5 時代には無料版にスパイウェアの Gator を仕込んだりで何かと問題になったりもした。デコーダーは無償配布、エンコーダーも期間限定で無料で使える。純粋な DivX の最終バージョンは 6.8.2 かな。FourCC はその DIV3 やら DX50 やらいろいろ。時代的に音声は CBR の MP3 を用いることが多い。; ※当初格納コンテナに制約のあった MS-MPEG4 をクラックし、ASF（ Windows Media ）以外のフォーマット･･･要するに AVI コンテナでも利用できるようパッチをあてたのが DivX3、という認識で落ち着いてる。パクリ自体は褒められた行為ではないのだが、DVD を鑑賞画質を保ったまま CD-R に焼ける 700MB まで圧縮できるとあって DivX＋MP3 in AVI の組み合わせが大流行したほか、AVI コンテナの各種ハックも DivX3 以降盛んに行われるようになるなど、自炊ブームの盛り上がりに大きく寄与したのは間違いない。; 2009年1月に発表された Ver.7 は映像 H.264、音声 AAC、コンテナはなんと MKV と、全くの別物に生まれ変わってしまった。日本ではあまり浸透していない MKV だけど、海外ではむしろメインストリームになりつつあることを受けてか。ただアイデンティティと呼べるものが無くなってしまったのも事実で、Ver.7 以降は DivX を積極的に使う理由がいまいち見あたらない。強いて挙げるならハードウェアの再生互換性を確保するなら DivX7 に準じておくといいのかもしれない。んまあ動画普及に大きく貢献したのでいつの間にかいなくなっても忘れずにいてあげて。; ･･･オワコンとばかり思っていたのだが、DivX9 で MP4、さらに DivX10 でいち早く HEVC をサポートし再び脚光を浴びる。老兵はなかなか死なずというか、独自コーデックの開発からマルチメディアプラットフォームへと早々と業態をシフトチェンジしたのは正解だったのかもしれない。
XviD / Xvid: DVD ハックの総本山、Doom9 から誕生したライセンスフリーのコーデック（現在は XviD.org ）。DivX に対抗した有志（というか DivX の商用化に伴い切り捨てられたエンジニアたち）を中心に作られた。FourCC は XVID。アルゴリズムは MPEG-4 系（ Part 2 ）で、Part 2 の多種多様な符号化ツールを数多くサポートしている。格納コンテナは特に定義されていないものの、DivX 対抗馬であり他に有力な選択肢がなかったことからほとんど AVI だったが、Vorbis の登場以降は OGM や MKV も増えた。発表時はそれなりに注目されたけど、ベースが DivX4 で他のコーデックの性能アップが著しいため積極的に使っているのはオープンソースにこだわる人種という印象。; エンコードが速い特徴があるが、AVI コンテナに格納した場合 B フレームを扱うことができないためシーク性が大幅に落ちる。そのため現在 Xvid を使う職人（誰）は MKV コンテナに格納する人が多い。ここんとこまた採用例が増えてる気がする。
3ivx: やはり DivX に触発されたコーデック。画質は当時の平均水準だが AAC 音声や MP4 コンテナのサポートなど、Part 2 準拠だけではなく ISO-MPEG4 そのものを強く意識しているのが先進的だった（ DivX が枯れた技術である MP3 と AVI コンテナに固執したのとは対照的）。Windows Media Player で MP4 を再生する手軽な手段だったが、長いことデコーダーにも試用期限を設定していたため後になって再生できない人が続出。QuickTime アーキテクチャのサポートにより Mac ではそれなりに人気を得たが、他の MPEG-4 Part 2 系アルゴリズムを採用したコーデック同様 H.264/AVC の普及により姿を消した。; FourCC は 3IV1/ 3IV2/ 3IVX だがエンコーダーに互換性があるため DX50 となっているケースもある。すでに開発元の 3ivx Technologies は解散しているが現在 3ivx のデコードをサポートするコーデックは多いので特に困ることもないだろう。
DV: MPEG-2 の次くらいに登場したデジタルビデオ規格。据え置き型よりもむしろビデオカメラでの採用が圧倒的に多く、AVCHD が登場し HD 記録が一般化するまで民生用ビデオカメラのスタンダードだった。H.264 が普及した現在でも規格は DVCAM や DVCPRO、HDV などに受け継がれ、業務用カムではまだまだ現役である。; そもそも業務用カムでは高圧縮なんかよりも高画質・高音質・高編集性のほうが重要なわけで、となると H.264 のメリットがあまり生きてこない。また記録媒体もオールオアナッシングの危険を秘めたシリコンメディアや光磁気ディスクよりもテープのほうがずっと信頼性が高かったり。; コーデックは DV 圧縮（ DV codec ）と呼ばれメーカー独自のものが多数存在するが Canopus を使うケースが多いような気がする。時間軸圧縮を行わないため性質は非圧縮 AVI に近く（拡張子も AVI、圧縮率は 1/5 程度）、コマ単位での編集が容易であるためポスプロ現場や一般家庭でのノンリニア編集を加速させる要因となった。半面圧縮率は低いので、用途は主に作品化前の映像ソースであり、観賞用は別途エンコードするのが一般的。また音声はリニア PCM で記録されるため品質は極めて高い。なお可逆圧縮ではない。; 欠点としては、記録媒体が磁気テープであるが故にドロップアウトの問題が常に付きまとうことか。塗布テープを採用している DVCAM や DVCPRO はヘッド素材やエラー訂正などで極力抑えているが、テープメディアである以上ドロップアウトは宿命的な課題といえる。もっとも、適切に管理されたメディアの保存期間は 30年以上と、CD や DVD よりも長かったりするのだが･･･。

可逆圧縮系

ロスレス圧縮とも呼ばれる、符号化（エンコード）の際に情報の欠落のない圧縮方式。復号（デコード）するとオリジナルと等価の情報を得られる。不可逆圧縮方式のコーデックと比較して

保存時に劣化しない
圧縮率が低いので高い転送レートが必要
処理負荷が低いのでエンコード / デコードともに速い

といった特徴がある。このため観賞用途ではまず見かけないが、映像制作における高品位な一次ソースやこれを編集した中間クリップの保存などに用いられている。なおコーデック自体は可逆でも色空間の変換（ RGB → YUV ）などエンコード時の設定で不可逆な処理が加われば当然オリジナルを復元できない。

処理負荷が最も低いのは非圧縮 AVI だが（そりゃ処理してないからなｗ）、VGA 程度であればともかく HDMI2.0 の対応している 4K / 60fps / 12bit DeepColor を非圧縮で記録しようもんならファイルサイズ云々よりも必要な転送レートにバスの帯域が負けてしまいかねない（フレームあたりの情報量は 3840 x 2160 [解像度] x 2¹² [色深度] x 3 [RGB] bit ≒ 35.6MB で、60fps なら PCIe Gen2 4x の 2GB/s を超える）。

基本的にフレーム間圧縮を行わない“ 1 frame in 1 frame Out ”処理で AVI コンテナとの相性も良いためここで取り上げる。

HuffYUV: ハフワイユーブイと読む（ Huff はハフマン圧縮の意味）。仕組みとしては“ DCT を DPCM に置き換えた Motion JPEG ”に近い。圧縮率は 1/2～1/3 程度とたいしたことないがそのぶん処理速度は速い。FourCC は HFYU。; 登場したのが 2000年と古く、かつて可逆圧縮といえばこれで、開発者は早々とメンテナンスを放棄したものの可逆圧縮総合スレの 459氏によりマルチスレッド化されたことで高解像度のキャプチャ界隈が大いに盛り上がった。難点は対応カラースペースが RGA / YUV422 / RGBA のみと寂しいところか。; 参考：HuffYUVの詳細仕様について - Qiita
Lagarith Lossless Video Codec: HuffYUV からフォークされたコーデック。圧縮率が 1/4～1/5 と大幅に改善されたことで鑑賞用ファイルのエンコードとして使うひともいる。もっとも非圧縮 AVI や HuffYUV と比べての話なのでせいぜいショートクリップ程度だが。また圧縮率と引き換えに処理負荷は若干増えた。やはりマルチスレッド化されている。FourCC は LAGS。; 参考：さまよう金の髭｜可逆圧縮コーデック「Lagarith」の設定や仕様、使い方等について
Ut Video Codec Suite: Takeshi Umezawa氏の開発した国産コーデック。HuffYUV より圧縮率に優れ Lagarith よりも処理が速いため汎用性が高く、特に日本では利用者が多い。; Four CC は ULY0 / ULY2 / ULRA / ULRG。
AMV Video Codec: amaman氏の開発したシェアウェアの国産コーデック。同氏によるキャプチャソフト・アマレコ用に開発されたため、実況界隈では下手するとそこらの不可逆コーデックより名が通っているかも。速度優先の設定では HD キャプチャーで 2000 fps を超えるいっぽう、不可逆圧縮によるファイルサイズ優先のエンコードにも対応しているように柔軟性が高い。; なお AMV2/3 はデスクトップキャプチャのアマレココ、AMV4 は外部映像キャプチャのアマレコTV 用となっている。Four CC は AMM2 / AMV3 / AMV4。

…映像制作や自炊、ゲーム実況といったエンコードの機会のない再生専門のひとは特に可逆圧縮コーデックのことは気にしないでよいと思う。あと重量級の PC ゲーム実況はシャドウプレイ（ H.264/H.265 リアルタイムエンコード）のようにハード支援も盛んだけど、B フレームが使えないので画質に対する圧縮率で不利だったり、可変フレームレートなので後編集性が悪かったり（何がよいかは何に比重を置くのかに依るかと。

Windows Media 系

Windows Media Video 9＝VC-1 ではありません。

AVI に限界を感じたマイクロソフトが次世代の覇権を握るべく開発した規格（ ASF もその産物）。Windows では何も考えなくても再生できる。商用利用を想定しているのでストリーミングや DRM といったコンテンツホルダーが喜びそうな機能に積極的。また商用コンテンツでの利用においては公式サポートの存在もありがたいと思われる。

MS-MPEG4

マイクロソフトのプレ MPEG-4 的コーデック。その名の通りアルゴリズムは MPEG-4 系（ Part 2 ）で、この発展系が Windows Media Video である。本来コンテナは ASF なのだが事実上 AVI。今となっては P2P を漂っている古いファイルで見かける程度に過ぎないが、MPEG-2 と比べてはるかに高圧縮＆高画質（もちろん当時としては）なコーデックを無料で使えることから世紀の変わり目くらいに職人の間で大ブレイクした。ある意味、自炊ブームを作ったコーデックともいえる。

最終バージョンの Ver.3（ FourCC が MP43 のもの）をまんまパクったのが DivX ;-) というのは有名な話。

ASF

Advanced Systems Format。映像と音声のほか副音声や字幕、チャプターも格納可能なマルチトラックの高機能コンテナ。当初の名は Advanced Streaming Format で、ストリーミングで先行する RealMedia の対抗馬として開発されたが、業務分野で実績のある QuickTime も参考にしているため完成度は高い。ただし著作権管理やシーク制御などウザい機能がついてくることが多い。

AVI の後継規格であり後述する Windows Media の標準コンテナだが MPEG-4 ASP や MP3 などを格納することもできる（フォーマットタグの番号さえマクロソフトに登録されていればなんでも格納できる）。ただし拡張子を WMV としてよいのは映像・音声ともに WindowsMedia でエンコードしたものに限り、音声に MP3 など WindowsMedia 以外のコーデックも使用した場合は拡張子は ASF にしないといけない。が守ってる人あんまりいない気がする。商用ストリーミングで広く採用されているがたいてい著作権管理やシーク制御もくっついてくるのでウザい。それがウリだから当然といえば当然か。

また標準規格である MP4 コンテナが QuickTime ベース、つまり Apple 由来だけに対抗意識は強く、B フレーム対応、VBR / VFR 対応、チャプタ/タイムコード対応、字幕を含むマルチトラックなど AVI の欠点だった点を解消しつつ、ストリーミングで先行していた RealMedia を参考にしたこともあり、コンテナ自体はかなり優秀。なんだけど、せっかくコンテナをサポートした VirtualDub にクレームつけたりとＭ＄さんがいろいろライセンスにうるさいおかげで有志からはハブられ気味（これはほんとうに、痛恨のミス）。

Windows Media Video

現在の Microsoft の主流映像コーデック（ OS 標準フォーマットはあくまでも AVI と思う）。初期の Windows Media Videp 7 は MS-MPEG4 の流れを汲む Part 2 の ASP 系に属するコーデックだが、Windows Media Videp 9 では Part 10（ H.264/AVC ）に含まれる圧縮技術も多い。性能は優秀で画質に対する処理負荷と圧縮率のバランスがよい。特に Windows Media Videp 9 は登場から実に13年が経過した Windows 10 時代を迎えてもバリバリの現役で、それだけ素性のよいコーデックといえる（ただし SDK のバージョンはそれなりに上がっている）。欠点はエンコードがやや遅いことか。

なにしろ Windows のデフォルトなので浸透率は高いというか、再生環境面で有利かもしれない。ピュアストリーミングにも対応。むしろ ASF も含めたストリーミングフォーマットとしての完成度はかなり高いと思うのだが、いかんせん配信に必要な設備投資が高くつくのが難点（一般ピープルには関係ないね）。拡張子は WMV が一般的だがコンテナそのものは ASF。ストリーミング時は WMV / ASF のままではなく後述する ASX や WVX 経由とするのが基本。

画質面での不満は少ないものの、可変フレームレートのせいかシークがぎこちない、という欠点が。ビットレートもわかりにくい。DRM 付きの場合、Windows Media Player 以外での再生ができない（ DRM 解除すれば別）。Windows Media Player をインストールすればデコーダは勝手についてくるんだけど（厳密には Windows Media Format SDK の一部）、バージョンによって微妙な差があって WMP8 環境ではアップデートしないと VC-1 のデコードができないし、WMP11 環境で WMV1 や WMV2 の再生に不具合が出ることもある。9 なのに FourCCが 1 だったり 3 だったりする理由は後述。

想像はつくだろうけど可変フレームレートは動きの激しいシーンで画質と圧縮効率のバランスを高めるための工夫で、VFR とも呼ばれている。CBR とかホンダが喜びそうな略称だわね。俺はヤマハ党だったので TZR とか FZR がなくて悲しい。そんなことより、ストリームのデコード自体はコーデックがやるにしても、プレイヤーにとってシークの大変さは同じ。Wikipedia の WMV 見ると包含先に AVI も書いてあるけど自殺行為としか思えん（ VCM のことをいってるんだろうか？）。

Windows Media Video 9 のデコード規格に家庭用 TV での再生を考慮してインタレース対応を加えたものが VC-1 として標準化され、Blu-ray や HD-DVD での必須コーデックとして採用されている（ただ互換性で微妙な問題あり）。その際のコンテナは ASF もしくは M2TS 。

なお WMV9 でもエンコーダにより FourCC に下記のような違いがある。

FourCC:WMV3 ※VC-1: WMP9 系エンコーダ（Windows Media Format 9 SDK？）で圧縮した WMV9
Windows Media Video Simple Profile/Main Profile
FourCC:WMVA ※鬼子: WMP10 系エンコーダ（Windows Media Format 9.5 SDK？）で圧縮した WMV9
Windows Media Video Advanced Profile
FourCC:WVC1 ※VC-1: WMP11 系エンコーダ（Windows Media Format 11 SDK？）で圧縮した WMV9
Windows Media Video Advanced Profile

VC-1 として扱われるものは WMV3 と WVC1 で、Main Profile と Adovanced Profile の違いは前述したインターレース対応の有無と考えてよい。問題は WMVA で、WMV3 や WVC1 との互換性がなく Micorosoft 自身も利用を推奨していない。WMP10 系環境の人が Blu-ray や HD-DVD 再生機器に対応したエンコードを行う場合（そんなケースあるのか知らんが）は注意が必要。無劣化結合などでも WMVA は厄介者である。

WMV9 以前について少し触れておくと、20世紀末にストリーミングシェア最大手だった RealMedia に対抗すべく、いくつかの試行錯誤ののち、ようやく形になったのが Windows Media 7、追いついたのが Windows Media 8、突き放したのが Windows Media 9 という具合に配信サーバとセットで進化した印象で、実際 Windows Media が爆発的に普及したのは 8 以降のお話。7 以前は試験的な存在として MS-MPEG4 コーデックによる NetShow だったような気がする。NetShow ＆ MS-MPEG4 ＆ MediaPlayer 6.4 の完成形が Windows Media、というわけ。それゆえ FourCC も Windows Media 7 ＝ WMV1、Windows Media 8 ＝ WMV2、Windows Media 9 ＝ WMV3 と変移している。

以上を踏まえもう一度整理すると、Windows Media Video は次の 5種類となる（2014年4月現在）。

Windows Media 7 ＝ FourCC：WMV1
Windows Media 8 ＝ FourCC：WMV2
Windows Media 9 ＝ FourCC：WMV3, WMVA, WVC1

FourCC：WMV3 ＝ Windows Media Format 9 SDK, WMV Simple Profile/Main Profile
FourCC：WMVA ＝ Windows Media Format 9.5 SDK, WMV Advanced Profile
FourCC：WVC1 ＝ Windows Media Format 11 SDK, WMV Advanced Profile

VC-1：WMV3 ＆ WVC1

ああ、ややこしい。とにかく WMVA は親にも見捨てられたいろいろ残念な子なので見つけ次第撲滅せよ、というお話。

参考：Windows Media コーデックのバージョン一覧 | Windows Multimedia Hacks

ソースフィルタの相性がけっこうあり、特に VC-1（ Windows Media 9系）以前の WMV1 や WMV2 （ Windows Media 7 や 8 ）で再生にもたつく場合、プレイヤー内蔵のフィルタではなく純正の WM ASF Reader を使って開くと解決することがある。

Windows Media Audio

現在の Microsoft の主流音声コーデック（ OS 標準はあくまでも WAV と思う）。意外と性能はよく、同ビットレートの MP3 より高音質なのはもちろん Lossless 圧縮にも対応しているけど、なんとなく Microsoft 独自規格ってのが嫌で WMV にエンコするときくらいしか使ってない。拡張子は WMA、一時期無理やり「ウマ」と読んでる人もいたけど、今もいるんだろうか。~~Video と違い、WMV7 の頃から大きな変化はない。~~

WMA9 までは音声コーデックの識別子である FormatTag や DirectShow における識別子の GUID（映像コーデックでいうところの FourCC に相当するもの）に変化がなかったのだが、それ以降は WMP のリリースバージョンと発表されたコーデック名と識別子と SDK の関係が非常にめんどくさいことになっている（バージョンが一致しないというかいろんなパターンが混在してて手に負えない）。正直俺もまだ把握しきってないがこれまで見た限りだと FromatTag は 0x0161 と 0x0162 の2種類しかないようだ。

ASX、WAX、WVX、WMX、WPL

全部 Windows メタファイル。中身は一般的なテキストなのでメモ帳で開ける。ASX はストリーミング向け、WAX は Windows Media オーディオ専用、WVX は Windows Media ビデオ専用、WMX は兼用、WPL はクライアント再生リスト。それぞれ XML 構文で対象ファイルや再生情報が書かれているだけのテキストファイルで、マルチメディアデータの実体は別にある。考え方は ReadMedia の SMIL に近いような気もする。

VCM / ACM

それぞれ“ Video Compression Manager ”と“ Audio Compression Manager ”、Windows におけるビデオ/オーディオ圧縮の標準インターフェイス。っていわれてもピンとこないわな。ひとことでいえば Video for Windows で利用できる形式のコーデック。どういうことかというと、Video for Windows は AVI のための API なので、VCM / ACM に対応するコーデックを用意してやればなんでも AVI に格納可能になっちゃうわけ。たとえば単体コーデックとして配布されている Windows Media Video 9 VCM をインストールすると、AVI の映像コーデックに WMV3 を利用できるようになる。もっとも、本来 AVI には不向きなコーデックのせいで再生が不安定になったり、FourCC は同一の DirectShow Filter がインストール済みでも互換性に問題が生じてエンコードに使った VCM / ACM がデコードでも必要になったり、そもそも VfW が AVI 1.0 コンテナしか扱えないので 2GB の壁が存在したり、と落とし穴もいっぱいある。今となっては再生互換のために入れるのはともかく VCM / ACM を用いてのエンコードはメリットよりデメリットが大きい。見かけるのたいてい映像の WMV9 VCM か音声の Vorbis ACM （というか他は見たことない）。

※ VCM / ACM コーデックを AVI 以外のコンテナで用いてはいけないのだが、たまに MKV とかに入っててトラブルのもとになっている。

WM ASF Reader と Windows Media Source Filter について

これについてちゃんと書いてるサイトがあんまりない。どちらも ASF 向けの Microsoft 純正ソースフィルタ･･･要するにスプリッタだが、DirectShow 向けに用意された Windows Media Format SDK のラッパーが WM ASF リーダーで普通はこっちを使う。Windows Media ソースフィルタは DirectShow 登場前の MediaPlayer 6.4 で使われてたもので、下位互換として残してあるらしい。ASF リーダーは配信ソースのプログレッシブダウンロード再生時のシークができないとかそもそもストリーミングをサポートしてないとか、Windows Media ソースフィルタはシーク及びレート制御ができないとか、Media Foundation 版の非同期ファイルソースフィルタはなんでもシーク可能だとか、OS や Windows Media SDK のバージョンによって機能がいろいろ異なるようだ。

参考：MSDN Blogs｜プログレッシブダウンロードのシークとソースフィルタの関係

で、ローカルファイルの再生は基本的に WM ASF リーダーを使えば問題ないが、古い WMV ファイルなどには Windows Media ソースフィルタのほうが適している場合もある。シーク性がガラリと変わることはよくあるので、いろいろ試してみると面白いかも。

※ Windows 10 には Windows Media ソースフィルタが組み込まれてない。7 あたりから移植できないこともないけど、ややこしくなるのでそのままにしとくほうがよい。

N / KN Eddition と Media Feature Pack

ほとんどの日本人には関係ありません。

ブラウザ戦争やオープンソース運動などマイクロソフトは何かと目の敵にされることが多いが、Windows XP におけるメディアプレイヤーのバンドルについても欧州委員会（The European Commission）や韓国公正取引委員会（KFTC）から独占禁止法違反にあたるとされた。そのため欧州や韓国向けにメディア関連のコンポーネントを廃した Windows XP N Eddition 及び KN Eddition を用意、その後の Windows についてもこの処置は引き継がれている。

このような非バンドル版の Windows で各種メディアファイルを再生するために用意されたのが Media Feature Packで、通常のバンドル版には不要というかインストールできない（逆に非バンドル版は Windows Media Player をインストールできない）。

…マイクロソフトは Windows Media 関連だけで4億9700万ユーロの制裁金を払ったが※、引き続き通常版（バンドル版）も併売されたためほとんどの消費者はこちらを選んだ（そりゃそうだろうな）。日本円にして約600億円はどこに消えたのやら。ちなみに韓国では通常版の発売はない。

※ Windows Server 絡みでは合計 8億9900万ユーロ（約1400億円）の追加制裁金を課されている。現在の欧州委員会の標的は天下の Google 大先生。

RealMedia系

RealMedia といえばかつてのストリーミングの代名詞であり、21世紀に入り WindowsMedia や Flash による動画配信が普及するまでストリーミングといえば RealMedia 一色であった。そのため低ビットレートでの安定性に重点が置かれている傾向にある。現在は明確な理由が無い限り積極的に使う人はほとんどいない。ちなみに、どういうわけか中華圏で人気が高かった。素性は悪くないのだが歴代の RealPlayer が胸糞悪いせいで実力を過小評価されている。

RealVideo

RealNetworks 社の映像コーデック。エンコード / デコードともに RealPlayer をインストールすることでコーデックが利用可能になる。この稀にみるウンコ仕様のプレイヤーに反してコーデックはなかなか優秀で、ネット配信黎明期こそナローバンドに最適化した H.263 ベースだったが、今世紀に入ってリリースされた RV30 / RV40 は MPEG-4、それも Part 10 AVC ライクなアルゴリズムを採用、同一ビットレートにおける画質の高さからいっときは自炊での利用が目立った。

FourCC は Real Player の世代によって RV10 から RV40 まで存在する。

RV10 : RealPlayer 5 , RealVideo codec 1.0 , H.263 ベース
RV13 : RealPlayer 5 , RealVideo codec 1.3 , H.263 ベース
RV20 : RealPlayer 6 (a.k.a. RealPlayer G2), RealVideo 2.0 , H.263 ベース
RV30 : RealPlayer 8 , RealVideo codec 3.0 , 独自開発
RV40 : RealPlayer 9 (a.k.a. RealOne Player), RealVideo codec 4.0 , 独自開発
RV40 : RealPlayer 10 , RV9 EHQ

※ RV40 は RealPlayer 9 と 10 でエンコーダの仕様が異なり、後者は標準設定で RV9 の EHQ 相当の画質で人気を評した（デコードは共通）。

なお拡張子は固定ビットレート（ CBR ）で RM、可変ビットレート（ VBR ）では RMVB という珍しい仕様。最近は MKV コンテナへの格納がほとんど。

RealAudio

RealNetworks 社の音声コーデック。拡張子は RA。Video とは違い自炊で用いる人は少ないが、かつて音声ストリーミングで一世を風靡した時期もあった。

今となっては積極採用する意味は薄れてしまったが、RealMedia、というよりも Real Networks 最大の功績はストリーミングプロトコル RTSP の開発であろう。1998年に IETF で RFC2326 として標準化され、以後何度も改定された。Microsoft の MMS や Adobe （もとは Macromedia だけどな）の RTMP などにも大きな影響を与えている。また SMIL というインタラクティブな実装など、配信において Real Media が先駆けたものは多岐に渡る。なお RealMedia のコーデックとストリーミングに関する特許や技術の大半は 2012年にインテルに売却されている。ほんと栄枯盛衰の激しい業界よね。

Ogg系

OGG＝Vorbisではありません。

Xiph.Org Foundation による Ogg プロジェクトの成果物で、数あるコンテナ/フォーマットの中でもかなり異色の存在。音声コーデックの Vorbis は成立事情が事情だけに海外でブレイクし現在でも利用者は多い。日本でもマニアの間では期待の声が高かったのだが、オープンフォーマットにそれほど情熱を感じない国民性や情報不足が祟って今では初心者の壁みたいになってる。

.ogg にしても .ogm にしても OS 標準では対応していないフォーマットだが、現在は Ogg 系のコーデックの格納には MKV を使うのが一般的。

Ogg: 正式名称は Ogg bitstream format。Xiph.Org 最初の成果物である、音声コーデックの Vorbis を格納するために作られたコンテナ。当初拡張子は OGG だったが、格納コーデックが増えてからは OGX / OGV / OGA（汎用/映像/音声）となっている。機能はわりと豊富なのだが対応しているのは基本的に Xiph.Org 関連のコーデックなので汎用性がいまひとつ。まあ Xiph.Org 関連のコーデックを使う場合には Ogg コンテナがベスト、ということでもある。名称の扱いもちょっと変わってるので混乱を招いたり、そもそも理想の先走った見切り発車的なところがあったため、次世代コンテナ開発の流れは MCF を経て MKV にシフトしてしまった。; 実のところ Ogg ファイルのほとんどは中身が Theora＋Vorbis か Vorbis オンリーとかなりマニアックなので、初心者が困ることは事実上あんまりないと思う。
Vorbis: 特許問題を抱えることになった MP3 を置き換えるべく誕生したロイヤリティフリーの音声フォーマット。あらゆる点で MP3 を超えることを目標に作られただけあって音質とファイルサイズのバランスもよく、特に低ビットレートでも劣化が少ないことから、個人ベースのエンコードを中心に海外で根強い人気がある。; Ogg / MKV コンテナで扱うのがセオリーだが、Ogg Vorbis CODEC for MSACM を使うことで AVI コンテナへの格納も可能。ただ Vorbis は VBR が前提なので本質的に相性が悪い（ ACM での AVI コンテナ格納時はビットレートの谷間をダミー（ 0 パディング）で埋めて CBR に見せかけている）。; 参考：vorbis.acm作者のリリースノート; ※ディレクトリ削ればあれこれ出てくる。; なお Ogg プロジェクトのコーデックは Ogg Vorbis といった感じで格納したコンテナも合わせた名称で呼ぶ、ちょっと変わった決まりがある（コンテナに MKV を使った場合は MKV Vorbis ）。ただ Ogg コンテナの正式リリースよりも先に Vorbis が有名になったことで Ogg＝Ogg Vorbis という誤解も広まってしまった。これも Ogg に関する混乱のひとつ（そもそもコンテナに格納するストリームが音声だけとは限らないんだから、なんでこんな命名ルールにしたのか理解できん）。そんなわけで、性能自体はよいのだが、変なところにこだわるあまり活躍の場をかえって狭めてしまった印象。
Theora: On2 TureCast 社の VP3 をベースに Xiph.Org プロジェクトの標準映像コーデックとして開発された。FourCC は THEO。Vorbis 同様、Ogg コンテナと合わせて Ogg Theora と呼ぶ。登場時はともかく今となってはそれほど優秀なコーデックでもない（画質で妥協できたとしてもエンコード時間が掛かりすぎる）。なお MPEG-4 系（ Part 2 ）だが B フレームをサポートしないため AVI コンテナとの親和性も保っている。; のちに HTML5 の標準映像コーデックとして、プロプライエタリが憎くてたまらない連中に担ぎ上げられ一時期注目されかけたけど、結局それほど性能向上が望めず、VP8 というか WebM に取って替わられた。あの頃さんざん Theora を持ち上げてた（そして執拗なまでに H.264 を叩きまくってた）連中も、当然今は WebM マンセーに夢中なのだろう。
Ogg Media: Ogg ベースのマルチメディアコンテナ。通称は OGM。Ogg Media を名乗ってはいるものの、当初プロジェクトと無関係だった Tobias Waldvogel 氏が趣味で勝手に作ったものなので公式な Ogg プロジェクトの産物ではない。が、本家の映像コーデック Theora のリリースが遅れたこともあり、お馴染みの DivX や Xvid といっしょに Vorbis を格納できるコンテナの登場に、しびれを切らしていた Vorbis 派が飛びついたのはいうまでもない。こと動画においては本家 OGG よりもにこちらのほうが浸透してしまった。そんな経緯ゆえ、中身は MPEG-4 系コーデック＋Vorbis がほとんど。; とっくに開発は終了し OGM の役目は MKV に引き継つがれたんだけど、現在までにけっこうな量の OGM ファイルが作られた。その中には～.ogm.avi のような拡張子偽装で AVI に見せかけてるものがけっこうあったりするけど、普通にスプリッタ入れるべき。策定の経緯上、スプリッタは Ogg 公式のものではなく OGM 用のもの（ OggDS ）を使う。; 参考：Tobias' DirectShow Filter（OggDS）; OGM が話題を呼んだのは待望の Vorbis 対応動画コンテナだったのはもちろんだが、音声の多重化、字幕ストリームの格納、チャプターの実装など先進的な機能に取り組んだことも大きな理由だろう。もっとも個人ベースの開発では限界があり完全な実装は難しくトラブルに事欠かなかったのだが、その思想は MKV に引き継がれている。
FLAC: 可逆圧縮を採用した音声コーデックで、何かと面倒なことになってる Ogg 系としてはかなりの優等生。例によってコンテナくっつけて Ogg FLAC で、拡張子は FLA または FLAC。破損に強く目立つ欠点もなかったため商用配信でも採用されるなど、日本も含め広く浸透、登場からそれなりに時間が経った現在でもロスレスの主流方式となっている。なお圧縮率を処理負荷の軽い Level 0 からで複雑な処理で高負荷負荷の Level 8 まで9段階から選べるが、処理時間の長さに見合うほどの圧縮率は得られないし複雑な処理はデコードの負荷にもなるので Level 3 から 5 を用いるのが一般的。; 動画の不可逆コーデックとは異なり、ロスレスは原理的にはクオリティの劣化がないと同時に劇的な圧縮率の改善を望めないため、世代間で顕著なスペックの差がない。FLAC をベースに圧縮率と処理速度の向上を目指した TAK も先行する FLAC と ALAC を脅かすには至っていない。; Matroska コンテナであれば複数の曲をまとめてアルバム化することも可能。ファイルサイズを気にしなければ動画の音声としても使えるが、音楽のみで扱われることがほとんど。
Daala: Xiph と Mozilla の共同開発で進められている次世代コーデック。H.265/HEVC や VP9 を上回る品質をオープンソースで実現することを目標としている。大きな特徴は符号化に重複変換を採用している点で、JPEG でおなじみの離散コサイン変換、いわゆる DCT から脱却することで既存特許に抵触しないライセンスフリーでの提供が期待されている。; 多くの記事では符号化方式が Lapped Transform としか紹介されていないが重複変換といってもいろいろな方法がある。また符号化方式としては古くから存在するものであり新技術でもなんでもないが、映像コーデックとして実装されたケースはこれまでない。映像以外では画像フォーマットの JPEG XR が重複双直交変換（ Lapped Biorthogonal Transform, LBT ）を採用している。; 肝心の性能だが開発初期に比べると着実に進歩しているものの、今のところ HEVC の代表エンコーダ x265 には及んでいないようだ。特に高ビットレートでの画質がいまひとつで x264 にも劣るのは、JPEG XR が低～中圧縮時の画質に優れ高圧縮時は劣る傾向にあるのとは逆で面白い。また実用的なコーデックとなるには圧縮比と画質のバランスだけでなく処理負荷や処理時間も大事な要素なので、そのあたりがどうなってるかも気になる。

そんなわけで、版権フリーの高性能コーデックとして期待されたものの、呼び方の誤解に始まり、OS 標準でのサポートがなく、かつ馴染みの薄い形式なのでスプリッタやコーデックを導入していなかったり、拡張子を AVI に偽装することで問題が悪化したり、音声 VBR なのに AVI コンテナに格納したり、おまけに映像も DivX で B フレームの処理でまた躓いたり、コーデック足りてるはずなのに再生できないと思ったら必要なのは Vorbis ACM のほうだったり、HTML5 の標準ビデオフォーマットに混乱を招いたり、と踏んだり蹴ったりなのである。

Ogg 系の DirectShow Filter はセットで提供されているのでまとめて入れておくとよいかも（ OggDS と Vorbis for MSACM も忘れずに）。ちなみに Vorbis が WebM の音声コーデックに採用された関係で、WebM の DirectShow Filter や VIDEO 要素による HTML5 のブラウザ埋め込みコンテンツのプラグインもキットに含まれている。

参考：Xiph.Org | DirectShowFilter（Ver0.84より名称がopencodecsに）

Matroska 系

正式には Matroska Media Container、自由度の高さと豊富な機能が自慢のマルチメディアコンテナ。海外で人気が高く、日本でも利用者は徐々に増えギガ男爵も標準コンテナに採用している。ただ自由度≠難易度なので Ogg 同様かつては初心者にとって壁となっていた。つまり XP 時代以前の Windows Media Player で標準再生できないのが弱点だが、Vista 以降は対応プレイヤーが一気に増えたので何も考えなくても使えるようになりつつある。最近は 3D 対応までしてる。

Matroska そのものは開発をコンテナ一本に絞り DivX や CoreCodec、VirtualDubMod、Google など他のメディア系企業やコミュニティと親密な関係にあるが、成立の経緯的に Ogg と同系列に扱うのが妥当か。

MKV: Matroska Video。マルチメディアの標準コンテナを目指して作られたオープンソースの汎用マルチメディアフォーマットで、XML の派生言語 EBML に基づいて記述されている（ EBML 自体、Matroska のために作られたのだが）。MKV は映像＋音声の場合で、音声だけなら MKA（ Matroska Audio ）、字幕ストリームは MKS、3D映像は MK3D となる。再生には MKV スプリッタが必要。拡張子はまんま MKV だが Windows Media Player での再生のためやむなく AVI にする人もいる。もちろん下策だが。; 完全フリーに固執した Ogg とは対照的に、既存の様々なコンテナを置き換えることを想定しあらゆるコーデックをサポートできるよう設計されている。ペイロードは柔軟でトラック数に制限はなく、VBR / VFR はもちろん多重音声や多重字幕、メニューやチャプター、タイムコード、ファイル添付、字幕、はては字幕用フォントの埋め込みにも対応と後発なだけあって非常に多機能かつ汎用性に富んでおり、さらに下位互換性を保ったまま機能を拡張できるので HEVC のような最新のコーデックのサポートも早い。; 難点は利用がほぼ PC に限られスマホやゲーム機器など非 PC デバイスのフォローが弱いところだが、MKV のサブセットである WebM のように派生コンテナが普及する可能性は秘めている。; 単純に DVD-Video を自分の環境向けにエンコードするだけなら AVI なり MP4 でほとんど事足りるだろうけど、字幕や音声多重、メニューなどいろいろ凝るようになるとこんな便利なフォーマットはない、って感じ（ DVD でできることをそのまま単一のコンテナで実現するのが開発目標だからね）。そんなわけでエンコ文化の進んでる海外では当たり前に使われているのだけれども、歴史的経緯から P2P に出回ってるようなファイルはたいてい音声に Vorbis が使われてるものが多く、さらに DirectShow も標準では未対応ということもあり、再生に支障をきたしたりシークがぎこちなかったりで敬遠してる人はけっこういるのでは。DivX7 が MKV コンテナを採用したことで転機となるかと思ったけど、DivX 自体がオワコンみたいな状態だったので相変わらず日本では少数派。; 日本であまりオープンソース系の規格やツールが根付かないのは思想の違いのほか、やっぱり言語の壁が大きいんだろうな。オレもエンジニアの下地がなかったらいろいろ敬遠してたと思うもん。; OGG / OGM ちっくなコーデックの組み合わせが多いのは OGG / OGM 以外に Vorbis を格納できるコンテナが未だ MKV しかないため。そもそも MKV は Ogg の反省から生まれたコンテナ規格 MCF プロジェクトのメンバーが独立して作り上げたものだから、Ogg マンセーだった版権フリー＆オープンソース派の自炊野郎どもがそのまま流れてくるのも当然というか。それはともかく、OGG / OGM の抱えていたテクニカルな問題や不具合、汎用性の低さを踏まえての規格だけに、完成度が高く不具合も少ない。フリーの動画編集ツールの代表格、VirtualDubMod が開発に携わっていることも自炊派にとっては心強い。コンテナ操作ツールの MKVtoolnix も公式に開発・提供されている。
PGMX: TMPGEnc シリーズでおなじみのペガシス社が提唱する、多機能なシングルファイルフォーマット。DVD や BD をメニューまで含めてシングルファイルに格納しましょー、って発想なのだが、実体はまんま MKV コンテナでトラックのひとつにメニュー構成要素を格納しただけである。拡張子は .pgmx だが .mkv に変えるだけで普通に再生できる。もちろんメニューまでは再現されないが。オーサリング環境は TMPGEnc PGMX CREATOR で、メニューなども含めた完全な再生には PGMX PLAYER を必要とする。; 着眼点は悪くないものの、ぶっちゃけ MKV がここまでくるのだってけっこうな道のりだったわけで、独自拡張子なんて MS みたいにプラットフォームの支配力があってナンボだろ、と思うのだが。まあ MKV コンテナを扱うツールとしては PGMX CREATOR の使い勝手はまずまずで、出力にノーマルの MKV も加えてやれば多少はニーズがあるかもしれない。一発保存的な点では MakeMKV のほうが楽だけど、円盤以外のファイルを扱えるのは便利かも。
WebM: コンテナは Matroska 系なのだが映像コーデックは On2 系なので、そっちで扱うことにする。

断言してもいい、機能と拡張性において MKV に敵はない。用途が PC オンリーなら迷わず MKV を選ぶべきだ。ぶっちゃけ対抗できるのは業務規格の MXF くらいじゃないだろか。MKV の普及を妨げているのはサポートしても利益にならない既得権益者の都合なのだよ（ MPEG 連合の、な。

俺が自炊動画を MKV 化したい理由はいくつもあるけど、決定的なのはチャプター挿入。抜きどころを GOM のブックマークファイルで管理するのはそろそろ限界なので。

Flash系

説明のいらないくらい普及している Macromedia（現 Adobe ）の開発したマルチメディア規格。いわゆる RIA の走りで、ウェブ埋め込み動画の事実上のスタンダードとなった。拡張子は SWF。データと各種再生制御情報をひとつのファイルに埋め込む方法と別途実体ファイルを参照する方法があるが、汎用性の高さから配信で用いられるのはほぼ後者。

ちなみに Flash のデスクトップ実行環境が Adobe AIR。Flash の大成功に心底ビビったマイクロソフトが対抗馬として作ったのが Silverlight で、パテントフリーを口実として割り込んできた Google が担ぎ上げたのが WebM。

FLV（ Flash Video ）: YourTubeで一躍有名になった、Flashの動画フォーマットというかファイルコンテナ。一般に映像コーデックとして用いられるのは H.263（ Sorenson Spark ）で、低解像度、低ビットレートでの再生に適している。裏を返せば、高解像度の映像には向かない。~~Flash の本質からするとあまり意味があるようには思えないが~~ブロードバンド化が進んで高品質の Flash Video が求められ、後述する VP6 も格納できるようになった。; 拡張子は FLV。Flash 仕様書における codecID は H.263 が 1 で VP6 が 4 となっているが、FourCC は Registration された中には存在しない。強いていうなら H263 と VP62 なのだが、若干仕様が異なるため FLV1 と FLV4 として再定義されたものが事実上浸透している。
F4V: H.264/AVC＋AAC を格納した FlashVideo。拡張子は F4V となった。Flash 仕様書における codecID は 7、FourCC は AVC1。なお Flash Player 9 以降（ Flash のパブリッシュバージョン 9 以降）は MP4 コンテナの直接読み込みに対応しているため、H.264 エンコードを用いた Flash 向け動画は F4V ではなく MP4 をコンテナとするケースも多い。; なお、H.264 採用の FLV は FLV5 という誤解が一時期広まりかけたが、わしと Golden Hige 氏によって食い止められた（わし偉い）。格納内容や FLV5 についての幾多の混乱については、FLV 動画のエンコードを参照されたし。

On2系

On2 Technologies, Inc は1989年創業の北米の IT ベンチャー企業。映像コーデックとしては後発ながら瞬く間に性能アップを遂げ、一時期は DivX をも凌ぐ勢いで MPEG 直系を脅かす最有力の存在だった。2009年8月、Google に買収される。

守備範囲はあくまでも映像コーデックの開発と提供であり、音声コーデックはおろかコンテナも自社では直接関与しなかった。なおコーデック及び FourCC は VP＋メジャーバージョン＋枝番で表記される。

VP3: VP5 以前の重要なバージョン。VP3.2 をオープンソースとして公開しストリーミング標準化団体の ISMA に対し採用を働きかけた。結果採用は見送られたものの、VP32 は先の Theora のベースになるなど、コーデックベンダーとして On2 が世に知れ渡るきっかけとなった。
VP6: On2 の名声を高めた映像コーデック。エンコーダーも個人利用の場合フリーで使える。特に VP62 は同時期の MPEG-4 系の中でも一番高性能な部類と思う。FourCC もその VP62 が一番浸透してる。; コンテナは AVI や MKV だが、のちに Flash（ FLV4 ）でも採用され Flash の常識を変える高画質っぷりにニコ動などでも利用者が一気に増えたが、ほどなくして H.264/AVC を採用した F4V コンテナが登場、主流もそちらに移った。
VP7: On2 の映像コーデック最新版。画質はともかくちょっとエンコード時間かかりすぎ。VP6 同様、枝番つくまでは静観が無難かと。
VP8 （ WebM ）: その後 On2 は Google 大先生に買収され、開発中だった VP8 が HTML5 時代の標準動画規格を狙う WebM の映像コーデックに採用された。FourCC は VP80。執筆時点では画質はともかく、エンコード性能がいまいち（クソ長い）。すでにソフトウェアのみならず、ハードウェアによるリアルタイムエンコード環境などが整っているライバル H.264/AVC と比べて劣勢なのは否めないが、無償利用を前提とすることで新規コンテンツビルダーなどの賛同を得て取り込みを図ろうとしているようだ。なお、WebM 自体は MKV 互換のコンテナである。; 最大の特徴は無償利用できることであるが、H.264/AVC のライセンスフィーが MPEG-2 より高いといっても、画質と再生環境の普及度、オーサリングの利便性などを考えると今から WebM に乗り換えるメリットというのはさしてないように思える（そもそも無料のウェブ配信での H.264/AVC は恒久的にライセンスフリー化された）。というか、F4V や MP4 のFlash配信で何が不満なんだ？って話。HTML5 を機に主導権を握りたい Google の思惑以上のものを感じないし、俺は XHTML 信者なので HTML5 嫌いだし。そもそも名前が悪い。ついには Mozilla にも見切られた。; MPEG 批判者はすぐにライセンスや既得権益云々の話を持ち出すけど、Google だってどこまで信用できるんだ？ Google のいうオープンっていったい何だ？って話でもあるんだよ。オレは Google と MPEG だったら MPEG のほうがずっと健全に営利活動やってるように思うがね。; ちなみに、WebM の音声パートは Vorbis、コンテナは MKV（サブセットのためチャプターなど一部の機能に制限がある）。エンコードは今のところパッチ適用した ffmpeg と Flix WebM くらいで、あとはよくわからない。再生は Chrome や Firefox などの WebM 対応版のブラウザ（ IE と Safari は非対応を表明）か、VP8 と Vorbis のコーデックがあれば可能と思われ。 TVMW5 も読み込みのみ対応してる。; 現在は WebM 公式において DirectShow Filter が公開されているので、これを導入すれば普通に見れると思う。WebM エンコーダーである makewebm.exe 及び WebM プレイヤーの playwebm.exe も同梱されている。; ･･･WebM と同時に画像フォーマット WebP も発表されたが、WebM の I フレームを規格としてまとめただけなので、圧縮率はともかく画質面では疑問が残る。次世代フォーマットに期待するのはファイルサイズの節約だけじゃないだろうに、JPEG を置き換えようって規格の色深度が 8bit でどうするのかと（最低でも 12bit は確保しないと話にならん。このあたりに“森を見て木を見ない Google ”がよく現れてると思う。
VP9: Google 完全主導で進められている VP8 の後継規格にして生まれながらの PS H.265の対抗馬。FourCC は VP90。ブラウザ上での再生を想定してるため最新版の Chrome や Firefox、Opera にはあらかじめデコーダーが組み込まれているほか、FFmpeg の開発した ffvp9 が本家版（ libvpx ）よりも高速とかなんとか。コンテナは引き続き WebM を使用。; WebM に対する理解がある程度進んでいること、少なくともデコードにおいて H.265 よりも一歩先をいってることから、VP8 よりは普及を期待できるのではないかと。それでも、ようやく H.264 で一本化しかけたウェブ埋め込み動画のスタンダードを再び混乱の渦に巻き込んだ罪は重い、というのがオレ判決。

XVD: BHA と IOデータが躍起になってた動画フォーマット。映像に VGM Video、音声に VGM Audio を用いる。FourCC は VGMV、拡張子は VGM か VG2。リアルタイムエンコード性能を重視して設計されているため、画質に対してエンコード負荷が少なく配信時の遅延もほとんどないが、高画質を狙うにはあまり向いていないため個人で使ってる人を見かけたことがない。リアルタイム配信などの業務用途で地道にがんばってるようだ。ちなみに日本上陸当時、製品開発を手伝わないかと誘われたことがあった。いい思い出だ（ピュア。
G.726: 低ビットレートでの使用を想定した音声コーデック。基本は PCM なのだけど、MPEG のように前後の情報を利用した時間軸圧縮も行う。PHS で使われてる。
Nancy Codec: 21世紀初頭、まだ J-Phone（携帯で写真を撮ることを一般化させた功績は極めてデカい）が存在した頃に軽負荷を売りに登場したコーデック。開発は OFFICE NOA。結局ムービー写メールくらいしか採用例がなく携帯端末以外にはまるで普及することはなかったけれども、計算量の少ない独自の圧縮アルゴリズムで勝負したこと自体はわりと評価できる。んまあ、今となっては携帯端末であろうがプロセッサの処理能力が飛躍的に向上しちゃったし、再生支援チップのコストダウンも進んでるので、軽負荷が武器になった古き良き時代を懐かしむ以外に使い道はないかと。なおコーデックの仕様が非公開のため、変換に苦しむ人がけっこう存在するようだ。
Cinepak: Windows 3.1 くらいの時代に QuickTime や Video for Windows で採用されてたコーデック。FourCC は CVID。セガサターンのゲーム動画でも使われてた。想定解像度は QVGA、まだ離散コサイン変換アルゴリズムがマルチメディア圧縮に用いられる前で、代表的な VQ（ベクトル量子化）コーデックのひとつでもある。当時はごく一般的なコーデックだったため現在でも特に意識しなくてもほぼすべてのプレイヤーで再生できる。
モバイルムービー/メモリースティックビデオ: SONY のやっちゃったフォーマット。モバイルムービーの中身は MPEG-4、コンテナが QuickTime なのでいちおう PC でも普通に扱える。対してメモリースティックビデオは H.264 AVC＋AAC と汎用的にみえつつコンテナは独自とか相変わらずの無茶ぶり。また著作権管理を盛り込んだメモリースティックセキュアビデオフォーマットは MagicGate を採用してるのでさらに厄介。んまああまり使われてないけど。
Motion JPEG: その名の通り、JPEG で記録された画像をパラパラ漫画方式で動画として保存するための規格。FourCC は MJPG でコンテナは AVI や MOV。音声は特に規定されていないが LPCM が多い。MPEG でいうオール I ピクチャの 1pass VBR に近いが、GOP の概念がないため MPEG の VBR のような AVI での相性問題は生じない。; デジカメのムービー機能ではごく一般的に採用されていたけれども　AVCHD　にお株を奪われた。DV Codec　と同じくコマ単位の編集が容易なので、主に編集前のソース映像記録として用いられるが、これもオール I ピクチャでの　MPEG　記録に侵食されつつある。規格そのものはオープンで汎用デコーダーも存在するが、コーデックの互換性が保証されておらず、記録に用いたデジカメ等のメーカーが提供するデコーダー以外では正常に再生できないケースも多いので扱いには注意する必要がある。; 原理上、オール I ピクチャでの記録はビットレートを大幅に増やしてやらないと情報量不足で映像が破綻しやすい（たとえば AVCHD のビットレート上限 28Mbps で 30fps だと1コマあたりの割り当ては 100KB 程度で鑑賞画質に見合うのはせいぜい VGA レベルまで、フルHD ならその4倍は欲しい）。というか Motion JPEG としてコマ単位で一次圧縮された映像をさらに時間軸方向で差分やオブジェクト化による二次圧縮を施したものが MPEG-2 であり MPEG-4、ってのは覚えておいて損はない（ Motion JPEG は最初から二次圧縮を想定していないぶんファイルサイズは肥大化するものの、記録・再生ともに MPEG ほど処理パワーを必要としない）。ついでに二次圧縮における効率化もそろそろ頭打ちなので、一次圧縮を JPEG から何に置き換えるかが 4K/8K 時代の課題のひとつ。; YUV を 4:1:1, 4:2:2, 4:4:4 で圧縮できる LEAD MJPEG、コマ圧縮に JPEG 2000 を用いる Motion JPEG 2000 など実はけっこう派生規格がある。

･･･他にもあるけど、見かけるのはだいたいこんなところかねえ。

字幕（subtitles、sub）について

どうしてもレイザーラモンっぽい感じがするのは正常な反応だから気にするな。

ハードサブとソフトサブ

DVD の字幕は別途用意された字幕のデータを再生時にオーバーレイ表示することで実現している。これに対し動画ファイルとして単一化する場合、AVI など制約の厳しいコンテナはエンコード時に字幕もいっしょに符号化して画像のいい部にしてしまうか（ハードサブ）、再生時に字幕データのファイルを別途読み込んで音声に合わせたタイミングでレンダリングするか（ソフトサブ）のいずれかになる。ASF や MKV、MP4 など最近のコンテナであれば字幕ストリームの多重化にも対応しているので、ソフトサブを字幕データを外部ファイルにするかストリームとして格納するかを選べるが、コンテナに格納すると若干エンコード時間が伸びる。

前者はなにしろ直接映像に埋め込むわけだからエンコ後にミスを発見したら最初からやり直しだし、鑑賞中に邪魔に感じても位置の調整やオンオフの切り替えなんてできるはずもない。あんまりいいことなさそうだが、再生環境やフォーマットを選ばないというのは大きなメリット。後者はまんまその逆だわな。映像に手を加えないから品質面（精神面？）も安心だし表示の融通も利く。データを入れ替えれば複数言語の字幕切り替えだってできる。ただ動画ファイル向けソフトサブに関する標準規格・仕様といったものが存在しないので、利用するソフトウェアや環境によって保存形式や実装方法がまちまちだったり、そもそも非対応だったりすることが（例：PS3でMP4を再生する際にソフトサブは使えません）。あとは再生に必要なファイル数が増えるので取り回しやフォルダの見通しが悪くなるのも難点か。やっぱり多重化に勝る方法はないと思うんだけどねえ。

P2Pに転がってる動画は基本的にハードサブ。再生時に悩まなくて済むからだろうね。ソフトサブの場合、MKVなどで多重化されているケースよりもたいていアーカイブ（圧縮ファイル）の中に動画本体に混じって拡張子idx＋sub（VobSub形式）か拡張子SRT＋srt.style（SRT形式）の字幕ファイルも混ざってるか、ダウンロードリンク周辺に“sub”なんてリンクがあると思う。再生は動画本体と同じファイル名＆同じフォルダに字幕ファイルがあればOK。仮にプレイヤーが未対応だったとしても（いまどきそんなのないとは思うんだが･･･）Vobsub for DirectShowをインストールすれば使えるようになるはず。ただしストリーミングでのソフトサブ対応はまだまだ怪しい状況で、配信フォーマット標準のプレイヤーでないとちゃんと再生されないことが多いので注意。

なおMP4の字幕対応に関しては調査中。そもそも情報が乏しいのだが、仕様には盛り込まれているもののストリームとして多重化する難易度が高いようで、Handbrakeなど字幕編集可能なツールでもMKVに比べて制限がみられる。

字幕とファンサブ

多重化やら埋め込みやらよりも、字幕そのものを作るほうがはるかに大変だ。少なくとも2つの言語に精通している必要があるし、台詞の量やタイミングに合わせて訳文を調節するセンスも大事。ボランティア？で字幕制作にいそしむ人たちはファンサブと呼ばれ、中には公式字幕よりも高い評判の者もいる。日本でもアナル男爵/戸田アナル子が有名（ギガ男爵とは何の繋がりもありません）。

日本での字幕需要は、極論すればせいぜいハリウッド映画がDVD化されるまで。そりゃコアなニーズが一部にはあるのかもしれんが、むしろ日本はコンテンツ供給側であり、特にアニメとアダルトに関しては圧倒的。日本で字幕制作のノウハウや人的リソースがあまり高まらなかったのも仕方ないといえる。逆にコンテンツに最も飢えている中華圏でファンサブ活動が活発なのもまた当然といえよう。

参考：ビジネスモデルとしてのファンサブ

『海賊版ダメ！ゼッタイ！』のCMを映画館で流すような国ですからねえ、日本は。

雑感

ファミリーツリーにでもすれば各コーデックの関係がもっとわかりやすくなるんだろうけど、オレ様はそこまで詳しくない。とにかくファイルコンテナとコーデックの違いさえ理解できれば、動画再生でトラブルことは減るのでは。それとCBR前提のAVIに対してVorbisのようなVBR前提の規格はすこぶる相性が悪いのも覚えておくこと。ハッキングを前提とするようなエンコードは職人の趣味の範疇に留めるべきで、他社と共有する可能性があるものに対してやるべきではない。

新しいコーデックの性能がいいのは当然であるが、中でもH.264が性能と利用のしやすさで頭ふたつくらいリードしているような状況。動画撮影においてもH.264（＋AAC）対応機種は増加の一途だがメーカーや機種によって保存形式に違いが見られる。PC環境の場合、依然としてAVIコンテナが主流の一角を占めているがもはやデメリットばかりが目立つので、今後のエンコードは再生環境の多様性を重視するならH.264 AVC＋AACのMP4、それ以外のコーデックの組み合わせであればMKVという方向になりそう。ネットで拾えるようなファイルもMP4/MKV/FLVコンテナのH.264＋AACが目立つし、この組み合わせにおける再生トラブルも少ない。こと字幕をソフトサブとして埋め込むなら、実装に問題のありそうなMP4よりもMKVで多重化したほうが無難。自分でエンコードをしない人でもMKVの再生はちゃんとできるようにしておくべきだろう。YouTubeやニコ動のおかげでウェブ埋め込み動画はFlashVideoがすっかり定着、googleの進めるwebmへの置き換えはブラウザサポートの壁に阻まれ苦戦。有料配信などでDRMが必要なケースだとWindowsMediaの絶対王者は当面揺るぎそうも無いが、googleはMP4のDRM化にご熱心。音楽はAppleのお目こぼしを各社が奪い合ってる中、着うたが確実に浸透している状況か。

変わり目があるとすれば4K/8Kだけど、すでにCS放送でH.265とMMT/TLVの採用が確定してるし、プレイヤーやエンコーダーのHEVCサポートもずいぶん浸透してきた。来年中には当記事でもISO/IEC 23008 MPEG-Hが独立項目に昇格するくらい活性化してるんじゃないかな。

参考情報

uguisu.skr.jp｜画像、音楽、映像フォーマット・コンテナ一覧: コンテナとフォーマット、格納コーデックが一覧になっていて非常に見やすい。当ページとあわせて読むと理解が深まると思う。でも JPEG のコンテナは JFIF で、その発展系がいわゆる EXIF だよ。
OTFE - Open the File Extension: 不明な種類のファイルを開くためのヘルプとあるように、動画に限らず様々なファイルを開く方法を提示している。独特の文体でちょっととっつきにくいかも。
DVDなToolsたち - Backup: 〝 DVD の基礎知識”と〝 DVD 構造の解説”で DVD （及び DVD-Video ）の仕様を事細かく親切丁寧に解説している。

フォーラム

英語だけどわかりそうなところ読むだけでもいろいろ勉強になると思うよ。

Doom9's Forum: いたちごっこが大好きな、そっち系ハッカーの溜まり場みたいなところ。
VideoHelp: 似たような場所。

なるべく一次情報かそれに準ずるソースに基づいて記述するよう心がけてるけど、間違ってたら教えて。

脚注

VR動画: 90年代にセガサターンとプレイステーション登場して以来、仮想現実を意味するバーチャルリアリティという言葉はすっかり馴染みのものとなったが、映像の主流は主にポリゴンや 3D レンダリング CG だった。近年注目を集めているのは実写の VR 化で、2016年は VR 元年と呼べるほどハードウェア製品やコンテンツにおけるバーチャルリアリティへの取り組みが盛んになっており、国内でもすでに VR アダルトコンテンツが制作され配信もスタートしている（流石というかなんというか。; VR18 - 18禁アダルト VRコンテンツを紹介するサイト; こうしたサービスや製品も含め「そもそも VR 動画とは何ぞや？」という話が置いてけぼりにされてる感で、実写ベースという共通点はあるが Oculus Rift や Cardboard といった HMD を併用する立体視の疑似3D映像も、RICOH の THETA S などで撮影した 360度全方位パノラマ映像も、Microsoft や Intel が躍起になって開発中の現実の上にさらに別の現実を重ねる AR もごちゃまぜになっている現状である。ゆえに当記事としても項目にしづらいのだが、3D 立体視映像（ひとまず 3D VR とする）と 360度全方位映像（同じく 360 VR ）はきっちり分けておきたい。ま、VR 動画といってもたとえば YouTube の 360 VR 動画の実体は MP4 で中身も H.264/AVC とお馴染みの規格である（ 360 VR のコアは 360 Video Metadata のフレームワーク）。これは 3D VR にしても同じ話。; AR は、何気に我らが“広報ふちゅう”が採用していた！; 広報ふちゅうの写真が動く！ＡＲ動画の導入　東京都府中市ホームページ; なお DVD-VR とは何の関係もないしもう忘れていい。
Linear PCM, L-PCM: アナログ信号をデジタル信号に置き換える、パルス符号変調の主方式。単に PCM と呼んだ場合、リニア PCM を意味することが多い。標本化（サンプリング）と量子化のみで圧縮を伴わないため、データサイズは非常に大きいがオリジナルからの劣化は最小限※で済む。CD-DA や DVD-Audio、Blu-ray Audio など高音質を求められるケースのほか、デジタル一眼や業務用 CAM など高級機の動画記録で採用されている。; 原理上、サンプリング時の折り返しノイズや量子化歪みが発生するため劣化がないわけではない。またサンプリング周波数や量子化ビット数を超える情報は劣化というよりも欠損と呼んだほうが正しい（逆にサンプリング周波数と量子化ビット数を上げれば上げただけオリジナルに忠実になるので、音質にこだわるなら事実上 LPCM 一択）。; なお量子化幅を適応的に変化させることでデータサイズを抑えた ADPCM もある。非可逆圧縮だが損失が少なく処理負荷もほとんどないのでテレビ電話などに用いられている。; ※誤解すひとが後を絶たないが、PCM 自体は符号化方式で音声圧縮に限らない。たとえば HuffYUV の静止画圧縮では DPCM が用いられてたり。
CBHD: 中国では今世紀に入ってSVCD、EVD、HDV、NVD、CH-DVDと独自仕様の光ディスクがこれでもかと登場し、そのすべてが黒歴史と化した。これらをひっくるめて中華DVDと勝手に呼んでる（ CH-DVD にHD DVD の技術を突っ込んだものが CBHD（China Blue High Definition）、その名もズバリ中華 BD である）。; 中華円盤のブームはどうも知財で一儲けするのが魂胆だったようなのだが、あちらさんは潜在市場はデカいのもののソフトに関しては筋金入りの海賊版天国なわけで、正規盤普及のため規格にきついコピーガードを盛り込んだことがかえって普及の妨げとして立ちはだかったようだ。国をあげてのウケ狙い、というあちらではよくあるお話。; 参考：ASCII.jp｜山谷剛史の「アジアIT小話」
4K/8K: 面積比が Full HD の約4倍、総ピクセル数 800万程度の解像度の総称で幅が 4000 ピクセル前後のため 4K と呼ばれる。中でも ITU の 3840ｘ2160（ 4K UHD / QFHD ）と DCI の 4096×2160（ 4K デジタルシネマ）が主流。というか DCI 4K を使ってるのは映画業界で、残りはだいたい ITU 4K。DCI 4K は基準アスペクト比が 256：135≒17：9 という家電や IT 業界からするとけったいな比率で、こんなものシネコン以外のニーズがあるわけない。対して ITU 4K は縦横それぞれ FHD のちょうど2倍だからほとんど人間や業界にとってこっちのほうが扱いやすいのは当然である。8K も事情は同じで、ITU の 7680×4320 と DCI の 8192×4320 が存在するが、映画関係以外は ITU 8K を基準にするほうが無難。; まあ民放連会長の口から｢4K 放送録画禁止｣などというおよそ正気の沙汰とは思えない発言が飛び出る有様だけに、どこまで普及するかどうかは、なんとも。過去の VHS や DVD のようにアダルトビデオが積極採用したら一気に浸透する可能性はあるかもしれないけど、ただでさえ業界が冷え切って Blu-Ray すら足踏みしてる状況なのにさらに高解像度の 4K なんて女優のアラが目立ってばかりのような。
BPP: Bit Per Pixel。1ピクセルあたりのbit数で圧縮率の指標として用いられる。フレーム間圧縮が常識となっている動画で画質の物差しとして使うのは数字に踊らされる不安はあるものの、量子化の直感的指標としてビットレート算出の目安にはなる。; 求め方はビットレート ÷ （幅ｘ高さｘコマ数）。4MbpsのDVD-Video（NTSC-D1）を基準画質とした場合、MPEG-2はBPP0.4、MPEG-4 Part2系はBPP0.2前後、H.264/AVCはBPP0.12～0.15が個人的なボーダーライン。ソースの内容次第ではもっと高いほうがよいことや低くて済むことも当然ある。
moov atom: moov は ISO ベースマルチメディアコンテナにおけるメタデータ、atom は QuickTime や MPEG-4 におけるボックスを意味する。平たくいえば再生に必要なインデックス情報を格納したメタ情報のためのサブコンテナで、MPEG などでプログレッシブダウンロードを行うにはファイルの先頭に moov atom すなわちインデックス情報が配置されている必要がある。
IJG 画質: JPEG における画質とファイルサイズのバランスを示す指標。フリーの JPEG のエンコード/デコードライブラリである libjpeg を開発した Independent JPEG Group が圧縮（ JPEG は保存≒圧縮）の際に用いるパラメータ（ quality ）及びその値で、値が大きいほど高画質＝低圧縮となる。多くの JPEG を扱うソフトウェアがこの指標を採用し保存オプションの画質や品質として実装されているが、中には Paint Shop のように IJG 画質とは逆パターン（値が小さいほど高画質）のものもある。; 値は 0～100 の範囲。100 を指定しても必ず不可逆圧縮が行われるため再保存するたびに徐々に劣化することになる。また 95 以上はファイルサイズの肥大化に見合うだけの画質向上を伴わず、45 以下は画質の劣化に見合うほどファイルサイズを節約できないため、利用形態に応じて 50～90 前後で調節することになる。; デジカメ等の画質設定ではおおむね Fine が 95～96、Standard / Normal が 90、Basic が 75 程度（ JPEG 圧縮率の値を任意に設定できる機種ってあるんだろうか？）。; 参考：最も劣化が少なくファイルサイズを小さくできる画像形式が判明 - GIGAZINE; GIGAZINE は圧縮率重視で考えた場合、ポスト JPEG を巡る争いでは HEVC-MSP が一歩リードしているようですと結論付けてるけど、実際の運用で優劣を判断する材料は処理に必要な演算量、色深度、可逆圧縮の可否、パテント料などいろいろ絡んでくるので鵜呑みにしないこと（ JPEG 2000 がポスト JPEG 足り得なかった理由もそのへんにあるわけで）。
API: 異なるプログラムに機能を提供するための仕組み。具体的には命令や関数、手順の取りまとめ。多くのソフトウェアが共通して利用するするような汎用的の高い処理をあらかじめ用意しておくことで、ゼロからすべて作らなくても必要な機能を呼び出すだけで済み、開発者の負担を軽減できる。また余計なバグの発生を抑える意味でも効果的。Windows のマルチメディア関連の API は、 Video for Windows → ActiveMovie → DirectShow → MediaFoundation と発展してきた。
MP3 の特許問題: MP3 の特許問題は GIF の LZW 特許と並ぶ業界最大級の衝撃で、午後のこ～だをはじめフリーのエンコーダが軒並み開発終了に追い込まれてしまった（ついでに様々な特許ゴロを促すことにもなったわけで、この2つのケースが後世に与えた悪影響は非常に大きい）。このような想定していなかった特許問題･･･いわゆるサブマリン特許は、現在のように技術が多方面に渡る状況では完全に回避するのはもはや不可能であろう。特許関連の法制度をグローバルに見直さないといけない時期ではないかと思うのだが、きれいごとベースではなかなか話は進まないよねえ。; なお LZW 特許はアメリカで2003年、日本でも2004年に失効しているので現在は問題なく GIF を使える。MP3 に関しては日本では2017年に失効予定で、延長申請がなければライセンスフリーとなる。ちなみに Nero AG の主張よると、MPEG-2 は必須の特許53個は既に特許が切れているのに、800以上の関係ない特許によってパテントプールの延命が行われているらしい。先のサブマリン特許と同じに扱う類の話ではないが、こうした技術発展を阻害し消費者の利益を侵害する特許システムの悪用は後を絶たない。IT 業界が頭を抱えた特許問題としては Eolas のプラグイン特許が有名だけど、2013年7月23日に無事？無効判決が下されるまでに14年もの無駄な月日と多大な労力を費やした。
プロプライエタリ: ソースコードが非公開もしくは利用に制限のある形態、要するに商用ソフト・フォーマット全般を指す。オープンソースの正反対の言葉。別に悪いことでも何でもないのだが、やりようによっては特定ベンダーによる独占を生む。そのためたいてい叩かれる。結果、損なわれるのは大多数の消費者の利便性、という笑えないオチもままある。行き過ぎた嫌儲思想そのものが権利の複雑さを増したりサブマリン特許みたいな騙し討ちを生んでるとなぜ気づかない？というお話。; つまり MPEG-LA がクソの集まりで MPEG の規格自体に問題があるわけじゃない、ってこと。