動画のデータ圧縮は考え方がまるで違う（389号）

前回までは、ランレングス圧縮、モールス信号、ハフマン符号化といったデータ圧縮技術についてお話をしました。

ですが、世の中には、全く違ったアプローチでのデータ圧縮技法があります。
動画や写真のデータ圧縮技術です。

特に動画の利用が急激に増えてきています。
Youtubeが始まったのが2005年で、ニコニコ動画が2006年だそうですから、一般的になったのはここ15年ほどでしょうか。

当初は粗くて見づらい映像が多く、とてもテレビやDVDビデオの代用にはなりませんでしたが、10年ほど前からはDVDに匹敵するレベルとなり、2025年現在ではDVDを上回るクオリティの動画もごく普通に見られるようになりました。

今回は、ハフマン符号化とはまた違った技法が駆使されている動画データの圧縮技術についてお話をします。

動画はデカイ

動画データというのはどうしても巨大なものになります。

例えば地上波デジタル放送を考えてみます。
その多くは1440×1080ドットで放送されています（本来のHDである1920×1080は少数派らしい）１ドットあたりのデータ量を4バイト（光の三原色の赤、青、緑＋透明度）とすると、1440x1080x4＝6,220,800バイトですので、約6MBです。
1秒間にほぼ30回の書き直し（秒あたりの画面数：以降フレームと言います）をしますので、1秒で6×30＝180MBとなり、1分で180MB×60秒＝10800MB＝10.8GBとなります。

なんと、地デジサイズの画像を1分間受信するだけで、10GBのデータ容量が必要となります。
30分番組（実質23分程度）なら230GB、2時間スペシャル（実質90分程度）ですと900GBの容量が必要です。

スマホなどで、最少のデータ通信プランは月に1GB程度でしょうから、2時間番組で900GBというのは明らかに非現実的で、実用とは程遠い数字です。

ですが、動画サイトで何時間も見ていても900GBもの通信は発生しません。

もちろん、これは動画データが非常に高度な圧縮技術を用いているからです。

動画の圧縮技術

おおざっぱに言って、動画の場合は2つのアプローチでデータ圧縮を行います。
　A. フレーム内圧縮
　B. フレーム間圧縮

このうち、Aのフレーム内圧縮については、次回に予定しているJPEGの解説で詳しくお話しますので、今回は触れません。

もう一つのフレーム間圧縮というのが今回のメインテーマとなります。

フレーム間圧縮というのは、動画ならではの圧縮方法です。

動画というのはご存知の通り、パラパラ慢画みたいなもので複数の静止画を連続表示すれば動いてみえるというものです。

動画を構成する各フレームは、ほぼほぼ同じデータの連続です。

例えば、主人公が部屋を右から左へ移動するシーンを思い浮かべてください。
この時、部屋の様子はずっと同じです。変化するのは主人公の位置だったり、体の動きだけです。

こういった場合、シーンが変わった最初のフレームでは全体のデータが必要ですが、その後は主人公の動き分（差分）データだけを送れば、かなりデータ送信量を節約できそうですよね。

動画データの場合、送信するデータ量を減らすための技術がたくさん開発されています。

これはデータ圧縮というより、データ削減技術となります。
前回までにお話したハフマン符号化などとは全く違ったアプローチであることがわかると思います。

そういったデータ量の削減技法を二つご紹介します。

差分フレーム（Pフレーム）

上で書いたような同じ部分を再送しない工夫として複数のフレームの使い分けが行われています。

とはいえ、フレーム間圧縮を行うにしても、全体を送り直した方が良い場合があります。
ドラマのシーン切り換え直後や、ニュースの現場映像への切り換え直後がそうです。

この場合、上で書いたような再利用できる場所がほとんどありませんから、全体を再送する必要があります。

これをIフレーム（アイフレーム）と呼びます。（IはIntracodeとかInformationの略号です）

一方で、直前の情報を利用した方がデータ量を少なくできる場合は、Pフレーム（Predicted：予測）を使います。これは直前のフレームと違った部分だけを覚えておこうという方式です。
上で書いた、部屋の中を移動するようなシーンではPフレームが有効です。

また、Pフレームと似たような形式としてBフレーム（Bi-predicted：双方向予想）というのもあります。こちらはPフレームが過去のフレームとの差分を送るのに対して、Bフレームでは過去と未来の両方のフレームから情報を持ってくるのです。

ですが、受信もしていないはずの未来のフレームをどうやって得るのでしょうか？

実は、Iフレームから始まる一連のフレーム（例えば5秒とか10秒分）はサーバの中で個別のファイルとして保管しています。
再生依頼が来ると、サーバはこま切れのファイルを次々と依頼元に送り込んで、再生をするのです。
ですので、再生しているデータよりも数十秒後のデータまでは既に受信済ですので、未来のフレームを参照するBフレームが成立するのです。

Youtubeなどで動画再生していると、バッファリング済みのデータ位置がいきなりジャンプするように増える場合があります。これは上記のようにファイルをこま切れにして送信しているから起きる現象です。

IフレームとPフレーム、Bフレームをうまく使うことで、最大90％のデータを削減できるといわれています。

動き補償

PフレームとBフレームにも弱点があります。
物体が移動するシーンなどでは、毎回データを送る必要があるという点です。

上で、書いた部屋を移動するシーンでも、人物の全てを全て書き直す必要がない場合もたくさんあります。
例えば主人公が帽子をかぶっている場合、手足や服のシワはフレーム毎に違いがあるでしょうが、帽子は右から左へ動くだけで、ほぼ同じデータが使えるはずです。
この場合、どの部分のデータがどれくらい（何ドット）右から左に動いたか、という情報だけを送ることで、さらにデータ量を節約できます。

動き補償を最大に利用できるのがパンニング（右から左へとカメラがゆっくり動いて風景などを映すこと）です。
パンニングでは、ほぼ画面全体を動き補償によって再現でき、送信が必要なデータはごくわずかになります。

動き補償による削減量は、動画によってまちまちですが、動きの激しい動画ほど動き補償による効果は大きいようです。

ビデオコーデック

動画を実現する方式はたくさん開発されています。
その圧縮方式やデータフォーマットの規定のことをビデオコーデックと言います。
ここでは、その代表的なものをいくつか紹介します。

MPEG-2：
かつては動画といえば、MPEG-2形式でした。DVDの多くがPEG-2でエンコードされています。とはいえ、かなり古い（1995年制定）形式ですので、新たに採用されることはほぼありません。

MPEG-4：
上記のMPEG-2の後継規格。例えばブルーレイのコーデックにはMPEG-4が採用されています。
これの初版は1999年と決して新しくないのですが、MPEG-4は今も現役です。
これには少々事情があります。
それまでは、MPEGのチームでは1→2→4 と順調に番号を増やしてきたのですが、4に来て採番方針を変えたようです。
新しいコーデックを採用してもMPEG-5やMPEG-6といった名前にはせず、MPEG-4 AVC や MPEG-4 HEVC みたいにMPEG-4の派生形であるかのような表記となっています。
表記だけ見るとマイナーチェンジっぽいですが、実際には後述の H.264やH.265がMPEG-4として採択されており、MPEG-4は今も最新の規格として生き続けています。

H.264：
現在はH.265という後継のコーデックに譲りつつありますが、ここ10年で最も利用されているビデオコーデックの一つ。Youtubeやニコニコ動画もH.264を利用しています。
ややこしい話ですが、H.264は ITU-Tという団体が規定した規約で、それがMPEG-4に採択されています。そのため、MPEG-4で規定されているAVC（Advanced Video Codec）を付けて、H.264/AVCと書かれることも多いようです。

H.265：
名前の通り、H.264の後継規格。H.264よりさらに高圧縮化のための手法をいろいろと取り入れており、今後10年の主流コーデックの一つです。
こちらもMPEG-4に採択されており、HEVC（High Efficiency Video Codec）を付けて H.265/HEVCと呼ばれることもあります。

VP9：
Googleが開発したビデオコーデック。MPEGなどに比べると国際規約でない点が弱みですが、ロイヤリティ（使用料）不要なのが大きな特徴です。
H.264やH.265はロイヤリティもさることながら、特許を複数の企業が保有していて、契約などの事務作業が大変だそうです。

（余談：MP3)
これはビデオではなく音声用のコーデックです。
これは MPEG-2 Audio Layer 3を略して、MP3と呼んでいるものです。（なんてまぎらわしい）
ごく稀にこれをMPEG-3と書いていることがありますが、誤記です。
ちなみに、MPEG-3という規格は実在しましたが、検討中にキャンセルされ廃番となっています。

動画圧縮での課題

これは動画に限った話ではありませんが、データ圧縮には時間がかかります。

通常のZIPやgzipによる文書の圧縮も、H.264による動画圧縮もその点は同じなのですが、動画ならではの悩みというものがあります。

一つは、通常の文書に比べて動画が巨大なものになりがちだという点です。

ExcelやWordといったオフィス文書で1GBを越えるケールは少数ですが、動画の場合はむしろ数GB以下になることの方が珍しいくらいです。

ということは、データ圧縮に時間を要します。
さらに、動画の場合は、上述のように、前後のフレーム間の差異をチェックしたり、動き補償といった特別な処理が必要ですが、これにも時間がかかりますので、さらにデータ圧縮が大変です。

もう一点、これは動画ならではの難しさがあります。
ライブ配信です。

上記の通り、動画圧縮には時間がかかります。
ですが、ライブ配信ではそんなことは許されません。

では、どうするのか？
端的に言えば力でゴリ押しします。
性能の高い専用機を使ってエンコード（データ圧縮すること。動画は習慣的にエンコードと言います）をさせるのです。１台で足りない場合は、複数を並行稼動させます。
さらに、処理時間短縮優先なので、敢えて高度なデータ圧縮をさせない場合もあります。

まとめ

今回は、データ圧縮の続きとして、動画のデータ圧縮のお話をしました。

動画の場合は、文書などと異なり、動画ならではの圧縮技法というか、データの削減技法が開発されています。
動画の圧縮技法は、世の中の要請も多いため、複数のコーデック（データ圧縮技法）が並存しています。

今回はデータ圧縮（削減）技法としてのPフレームと動き補償をお話しました。

次回はフレーム内圧縮の技法としてJPEGのデータ圧縮についてお話します。

データ圧縮のお話も今回で４回目。そろそろ食傷ぎみの方もおられるかもですが、次回で終わりですので、もう少しだけおつきあいください。

次回もお楽しみに。

（この記事は2025年1月に執筆しました）

このNoteは私が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
https://www.mag2.com/m/0001678731.html
弊社の窓口（ info@egao-it.com ) にメールをお送りいただいてもOKです。