H.264の魔法（2016）
(sidbala.com)- インターネット動画やBlu-ray、携帯電話、防犯カメラ、ドローンで使われる H.264 は、フルモーション映像を現実的な帯域幅で送るために発展した動画圧縮標準である
- 1080p 60Hz の非圧縮映像は
1920×1080×60×3を基準に約 370MB/s に達し、50GB の Blu-ray ディスクにも約2分しか収められない - 圧縮の核心は 非可逆圧縮 で、目立ちにくい細部情報を減らし、周波数領域変換・量子化・クロマサブサンプリングによってデータ量を下げることにある
- 時間方向の圧縮では、フレームを I-frame、P-frame、B-frame に分け、16×16 ピクセルのマクロブロックの動きベクトルによってフレーム全体ではなく変化量から復元する
- 例では、5秒 60fps、300フレームの H.264 動画が 175KB だった一方、単一の PNG スクリーンショットは 1015KB で、元の 1.2GB の映像が 175KB まで縮小された
H.264が減らそうとしているデータ
- H.264 は、インターネット動画、Blu-ray、携帯電話、防犯カメラ、ドローンなどで広く使われている動画圧縮コーデック標準である
- 目標は、フルモーション動画の伝送に必要な帯域幅を減らすことにある
- ここで扱う概念の多くは H.264 だけでなく、動画圧縮全般にも当てはまる
非圧縮映像が大きすぎる理由
- 単純な非圧縮動画ファイルは、各フレームのピクセルデータを含む2Dバッファ配列であり、空間2次元と時間1次元を持つ3Dバイト配列と見ることができる
- 各ピクセルは、赤・緑・青の3つの基本色のために 3バイト を使う
- 1080p 60Hz 映像は、次の計算で約 370MB/s の生データを生む
1920 × 1080 × 60 × 3
- このサイズでは、50GB の Blu-ray ディスクに約2分しか収められず、移動や保存も難しくなる
PNG 1枚より小さい5秒の動画
- Apple ホームページの画面例は、H.264 圧縮の効果を直感的に示している
- 5秒 60fps の動画は 300フレーム だが、ファイルサイズは単一の PNG フレームの約5分の1である
- 見た目には300倍多くのデータを含む動画のほうが小さいため、H.264 は PNG より非常に効率的に見える
非可逆圧縮で捨てる情報
- H.264 は 非可逆圧縮 コーデックで、重要度の低いビットを捨て、重要なビットだけを維持する
- PNG は 可逆圧縮 コーデックなので、エンコードされた画像から元のソース画像をビット単位で復元できる
- H.264 は画像を切り取ったり特定の象限を捨てたりするのではなく、ほかの非可逆画像アルゴリズムのように ディテール情報 を減らす
- 例の画像では、MacBook Pro のスピーカーグリルの穴のような細部情報は消えるが、拡大しなければ違いに気づきにくい
- この段階だけでも、画像は元サイズの 7% 程度まで縮小される
エントロピーと冗長性の除去
- 情報エントロピー は、ある情報を表現するのに必要なビット数であり、データセットの単純なサイズとは異なる
- コイン投げの結果のように、あり得る状態を表現するのに必要な最小ビット数として理解できる
- 10回投げたコインがすべて表なら、
HHHHHHHHHHと書く代わりに「10回すべて表」と表現すれば、より短く表せる - この過程では情報そのものは変えず、表現だけを減らして 冗長性 を取り除く
- このような汎用の可逆エンコーダを エントロピーエンコーダ と呼ぶ
周波数領域と量子化
- 空間や時間に応じて変化するデータは、別の座標系に変換でき、画像の輝度値も 周波数領域 で表現できる
- 周波数領域では、低周波成分は中心側にあり、高周波成分は端のほうにある
- 画像の細かなグリルのような詳細なパターンは 高周波成分 に当たり、なだらかな色や明るさの変化は低周波成分に当たる
- 周波数領域画像の端をマスクすると高周波情報を捨てることができ、再び通常の x-y 座標系に変換すれば、元画像に似ているが細部情報が減った画像になる
- マスクの大きさを変えれば、出力画像のディテール量も調整できる
- 例では、情報エントロピーが元の 2% 程度でも、拡大しなければ違いに気づきにくい
- 非可逆圧縮では、この過程を 量子化（quantization） と呼ぶ
クロマサブサンプリング
- 人間の目と脳は、明るさの変化はよく検知する一方で、色の細かな違いは相対的に判別しにくい
- TV 信号では、RGB の色情報は Y+Cb+Cr に変換される
Y: 輝度、実質的には白黒の明るさCb,Cr: 色差、つまり色成分
- RGB と YCbCr は、情報エントロピーの観点では等価である
- 白黒テレビの時代には Y 信号だけがあり、カラーテレビが登場すると、色情報を Cb と Cr にエンコードして Y と一緒に送る方式が使われた
- 白黒テレビは Y 成分だけを見て、カラーテレビは色差成分まで使って内部で RGB に変換する
- H.264 で使われる方式は、Y 成分をフル解像度で保存し、C 成分は 4分の1の解像度 で保存するというものだ
- クロマサブサンプリングは、色情報の一部を捨てることで全体の帯域幅を 半分 に減らしつつ、見た目の差は小さく保つ
- この技法は H.264 固有の機能ではなく、何十年も広く使われてきた
動き補償と時間方向の圧縮
- H.264 は 動き補償 圧縮標準である
- 単一フレーム内の空間方向の圧縮を超えて、複数フレームを時間方向にまとめて扱う
- テニスの試合のようにカメラが固定され、ボールだけが動く映像では、背景全体を毎回保存する必要はない
- 画像は通常 16×16 ピクセルのマクロブロック に分けられ、このブロック単位で動きを推定する
- フレームの種類は大きく3つある
- I-frame: フレーム全体を構成するのに必要なすべてのビットを含むフレーム
- P-frame: 前のフレームから各マクロブロックの動きベクトルをエンコードする予測フレーム
- B-frame: 過去のフレームと未来のフレームの両方から予測する双方向予測フレーム
- デコーダは最後の I-frame から始め、その後のフレームの動きベクトル差分を加えながら現在のフレームを構成する
- Apple ホームページの例の動画は、実質的に3つの I-frame の間でマクロブロックが移動する形なので、非常によく圧縮される
巻き戻し後に少し止まる理由
- YouTube のような動画で、数秒前に巻き戻したときに即座に再生されず少し止まる現象は、H.264 の構造に関係している
- ユーザーが任意のフレームにジャンプすると、デコーダは近くの I-frame から再計算しなければならない
- その後のフレームまで動きベクトル差分を積み上げて現在のフレームを作る必要があるため、計算コストが高い
- この方式は空間効率が非常に高い一方で、デコードには計算が必要になる
最後の可逆圧縮段階
- 非可逆段階を経た I-frame にも、なお冗長な情報が残っている
- P-frame と B-frame のマクロブロック動きベクトルにも、同じ値を持つグループが生じうる
- 特にテスト動画のように画面がパンする場合、多くのマクロブロックが同じ量だけ動く
- エントロピーエンコーダ は、こうした冗長性を処理する
- エントロピーエンコーダは汎用の可逆エンコーダなので、入力されたデータは復元可能である
例の圧縮率
- 元の例の動画は
1232×1154という非標準的な解像度でキャプチャされている - 5秒 60fps 基準の元サイズは、次の計算で約 1.2GB になる
1232 × 1154 × 60 × 3 × 5
- 圧縮後の H.264 動画は 175KB である
- 記事の自動車の比喩で換算すると、3000ポンドの車が 0.4ポンド、つまり 6.5 オンスまで縮んだのと同じである
- この圧縮率の説明は、何十年にもわたる研究を大きく単純化したもので、さらに詳しい内容は H.264/MPEG-4 AVC Wikipedia Page で確認できる
1件のコメント
Hacker Newsのコメント
AV1 は、ライセンス面でより優れた、より魔法のようなコーデックだ。
Meta は動画ストリーミングで、段階的に VP9/AV1 ストリームをデフォルトのベースラインにしつつある: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
ビデオ通話にも AV1 を使っている: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft も Teams で AV1 を使い始めており、AV1 には画面共有で特に有用な映像符号化ツールがある: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
最近 YouTube で見る動画の大半は VP9 か AV1 で、H.264 を見るのはたまにだけだ。
H.264 はかなり長く残るだろうが、AV1 がインターネット動画の新しいベースラインになる可能性が高そうだ。
開発者の観点では誰もが利用できる必要があるが、今はその機能が大多数のユーザーに行き渡るまで待っている状態だ。
もっと多くのユーザーが AV1 のエンコード/デコードに対応したハードウェアを買ってくれるとよくて、"AV1 inside" のようなロゴが必要に思える。
たとえば iPhone のラインアップでは、まだ iPhone 15 Pro だけがハードウェアデコードを提供している。
講義動画を録画して 720p の比較的小さなファイルにしてアップロードする必要があったのだが、白いホワイトボードの細くシャープな線の前で、ゆっくり動く人物を中途半端な照明で撮った映像で、x264 のデフォルトのエンコードプロファイルはうまく合わなかった。
それでも 1〜2 日ほど設定をいじって、2014 年ごろの iGPU しかないノートPCで講義の翌日の夜に回し、その次の日に成果物をアップロードできるようにした。
一方 libaom は、3 時間の動画のレンダリングに 1 週間ほどかかるという結果になり、デフォルト値もあまりに悪くて実験する余裕がなかった。
4 年前の話なので今は改善しているかもしれないが、奇跡までは期待していない。
必ずしも致命的な問題ではないが、AV1 の本当の問題は圧縮に計算量がかかりすぎることだ。
あるいは単に自分の目がよくなっただけかもしれない。
このテーマを深く掘り下げた記事があるといいのだが。
関連記事:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - 2022年3月、コメント219件
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - 2019年5月、コメント180件
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - 2018年5月、コメント1件
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - 2016年11月、コメント219件
その記事が書かれてから 8 年が経った今、H.264 の特許 のかなりの部分がまもなく失効する予定で、およそ 1〜2 年以内だ: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
H.264 標準の最初のバージョンが 2003 年に出ており、特許の有効期間が通常 20 年であることを考えれば、驚くことではない。
前世代の H.263 と MPEG-4 ASP はすでに特許が失効しており、パブリックドメインにある。
では H.265 はどうなんだろう？ 数字が1つ大きいじゃないか？ https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
H.265 のエンコードは、節約できる容量に比べて追加の計算量が大きすぎる。
H.264 なら1時間で 1GB まで縮められるファイルが、H.265 だと12時間かけて 850MB になる、といった感じ。
用途によっては、クライアント対応がはるかに広い H.264 版が結局必要になることもある。
データセンター級の計算資源があるとか、動画1本あたり 150MB の節約が積み上がるストリーミングサービスを運営しているなら H.265 に乗るだろうが、現実的な多くのケースでは正当化が難しい。
VP9 とほぼ同じくらいの水準だが、ライセンス問題のせいで今でもどこでも採用しにくかった。
VVC/H.266 も同じ問題を抱えているようで、AV1 はほぼ同じくらい優秀なのに、すでにずっと広く採用されている。
より新しいコーデックは圧縮性能が高いが、複雑さは非線形に増えていく。
H.264 よりファイルサイズはずっと小さくなった。
標準自体も H.264 より10年新しく、H.264 は 2003 年、H.265 は 2013 年だ。
「コインを10回投げて全部表が出たなら、HHHHHHHHHH と書くのではなく『10回投げて全部表』と言えばいい」という例では、その H の文字列 には少し損失圧縮が入っている気がする。
H.264 が最初に出てきたときのことを覚えている。
当時は mplayer に夢中で、最新リリースをよく落としてビルドしていた。
初めて H.264 ファイルを入手したとき、mplayer では読めなかったので開発版を落としてビルドする必要があった。
動いたし、2つのことに気づいた。画質は驚くほど良く、自分の Athlon 1800+ では荷が重かった。
その後の mplayer や libavcodec のバージョンでは性能が大きく改善したが、あの日のことは今でも覚えている。
mplayer を使わなくなって本当に久しいが、当時は最高だった。
昔、動画系の製品を開発していた会社で働いていたのだが、ラスベガスの別の会社がうちの役員たちに「革新的なビデオコーデック」とプレーヤーを売り込み、使うには NDA への署名が必要だった。
使ってみると mplayer のように動いたが、あまりにもそっくりだった。
さらに5分ほど調べたら正体がばれ、その会社に大金を払った役員たちは赤っ恥をかいた。
技術分野でも、非技術系の意思決定者 をだますのは驚くほど簡単だ。
取り残されることへの不安が大きすぎるからだ。
賢い人は評価のために優秀なエンジニアを呼ぶが、ダニング＝クルーガーの典型は財布を持って列に並ぶ。
1999年に買収されたスタートアップを離れようとしていた時期があり、当時私はMPEGエンコーディングをしていた。
面接を受けた会社の1つが、新しい映像圧縮方式を作ったと言っており、NDAに署名した後、非リアルタイムのソフトウェアコーデックでエンコード／デコードした短いクリップを見せられた。
私はそのアルゴリズムのASIC版を作る人材として面接を受けていたのだが、出力を1〜2分見ただけで何をしているのか見当がついた。
その例はアルゴリズムの強みに合わせてあるのだろうと考え、もっと難しい場面を提案し、私にはどんな方式に見えるかも説明した。
彼らは肯定も否定もしなかったが、二次面接に呼ばれた。
二次面接では創業者夫婦のCEO/CTOと話したが、彼らの計画はASICを売ることではなく、コーデックを秘密に保ったままASICでDSLベースのケーブルネットワークを構築し、映像配信を行うことだった。
「より優れたキャブレターを発明しておいて、GMと競争するための自動車工場を建てようとしているようなものだ」と言ったが、彼らは好意的には受け取らなかった。
この話がH.264とつながる点は、彼らの主張が「既存の圧縮は限界に達しており、だからこそ自分たちのコーデックだけがDSL回線で高画質映像を送れる」というものだったことだ。
私は、圧縮技術は今後も改善し続けるし、たとえそうでなくても、より高速なインターネットが各家庭に入れば、彼らが越えられると思っている閾値そのものが消えるだろうと答えた。
彼らは、物理法則上、電線で送れるビットレートには限界があり、すでにその限界に達していると言った。
私は採用提案を受けなかったし、受けたくもなかった。
その会社はVCマネーを得たが、数年後に畳み、ほかの人たちがはるかに効率のよいコーデックを作り、2Mbpsのインターネット接続は限界ではなかった。
実際のアルゴリズムには賢い数学とアルゴリズム上の力がかなり投入されていたはずで、技術的に愚かだったわけではなく、事業感覚が足りなかったのだと思う。
こうして言い直すと、何でもわかったふうに振る舞う知ったかぶりの万能人間みたいに聞こえるが、私の人生で何かを見て数秒でシークレットソースを見抜いた2回のうちの1回だった。
私が愚かだった例は、その何倍もある。
アルゴリズムは確認されたことはないが、シルエットアーティファクトを見るとかなり明白だった。
MPEGはJPEGのように画像を小さなブロック（8x8、16x16など）に圧縮するが、これは空間的冗長性を活用できる範囲を制限する一方で、その冗長性を見つける計算コストも制限する。
彼らのコーデックは、1990年代後半にMicrosoftがTalismanグラフィックスアーキテクチャ向けに提案していたものと似ているように見えた。
固定ブロックに分ける代わりに、フレーム列を解析して、半ば任意の境界を持つ構造的に一貫した領域を見つける方式のようだった。
たとえばテニスの試合なら、背景はかなり「剛体」に近く、カメラがパンして1ピクセル動けば、周囲のピクセルも同じ空間変換をする可能性が高い。
選手はフレームごとに変化するが、その塊には照明と位置の相関がある。
こうして領域を識別した後、その領域の画像をJPEGに似た方法で圧縮し、次のフレームでは、ある領域が次のフレームでどのようなアフィン変換、あるいはより一般的な変換を受けるかを解析して、いくつかのパラメータで符号化していたのだろう。
これが次フレーム予測の基盤となり、うまく当たれば、予測誤差を補正するのに必要なビット数は多くない。
VCから3,200万ドルの投資を受け、2002年にステルスモードから出てきたという。
その後どうなったのかは見つけられなかった。
文章はとても良いが、Information Entropyという表現を別個の用語のようにくっつけて書いたのは、「ATM machine」系の表現の中でもかなり気になる部類だ。
文章自体は良いが、表現は本当に強烈だ。
02016年にはH.264は多くの国で特許に縛られた魔法だった。
今では、標準は02004年8月に1年間の公開標準化作業の後に公開され、特許は出願日から20年しか続かず、すでに公開されたものには特許を取れないのだから、その大半はすでに失効しているか、数か月以内に失効するはずだ。
米国には本人が公開した場合の1年間の猶予があるが、例外があるならぜひ知りたい。
userbinatorはhttps://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264...を示していたが、そこにある特許の大半はH.264標準確定後の優先日を持っているため、H.264自体の実装に必須であるはずがない。
もっとも、標準化当時に実装可能であることが知られていなかったと主張するなら別だが、それはかなり説得力に欠ける。
驚くべきなのは、この20年間で少しは良いと言えるものは出てきたものの、ffmpeg実装で私がテストした範囲では、はるかに優れているものはなかったという点だ。
特許のない地位が保証されれば、良くも悪くもH.264はしばらく標準コーデックとしてさらに定着する可能性が高そうだ。
AV1は同じ帯域幅で視覚品質が少し良いが、はるかに遅く、02018年のような遅い時期に出願された特許にも脆弱だ。
「デコーダに任意フレームへジャンプするよう指示したため、最も近いIフレームから始めて、動きベクトルのデルタを現在フレームまで加算する計算をやり直さなければならず、そのせいで少し止まる」というのは2016年の話だ。
今ではYouTubeが君がFirefoxを使っていると知っているからだ。