1分30秒のPNG動画を考える

実用的なのか?

  • 動画(1280x720)
    非圧縮AVI6.95 GB(7,472,661,012 バイト)100%
    MP430.0MB(31528283Bytes)0.49%
    MPG-II20.8 MB(21,827,584 バイト)0.34%
    MPG-II(音声なし)19.4 MB(20,359,168 バイト)0.31%
    MPG-I(半分サイズ)13.8 MB(14,497,792 バイト)0.22%
  • 音声のみ
WAV15.1 MB(15,881,760 バイト)100%
MP31.37 MB(1,440,738 バイト)9%

画像に変換(動画は29FPS)

  • AVIからBMPに変換して2697枚の画像になった
  • 2697枚 / 29FPS = 93秒 = 約90秒の動画と一致
    • 1枚あたり0.034秒で29FPSの動画ができるハズ
フォーマット総枚数1枚あたりのサイズサイズ総量圧縮率
非圧縮AVIx16.95 GB (7,472,661,012 バイト)100%
BMP(音声なし)x 26972.63 MB (2,764,854 バイト)6.94 GB (7,456,811,238 バイト)99%
BMP(リサイズ4%)x 2697108 KB (110,646 バイト)284 MB (298,412,262 バイト)3.9%

なんかAVIよりBMPの方がサイズ減ってる、謎。
[リサイズ4%]は1280x720の解像度を256x144の実用サイズ(実サイズの4%)にして、かなり小さいサイズにする
これで高速性とファイルサイズの小ささを確保できるか?

  • 画像サイズを4%と小さくした分、ファイルサイズもピッタり4%程度(3.9%)になった。

動画をリサイズする

フォーマット総枚数1枚あたりのサイズサイズ総量圧縮率
BMP(リサイズ4%)x 2697108 KB (110,646 バイト)284 MB (298,412,262 バイト)100%
BMPをZIP圧縮x 1164 MB (172,859,929 バイト)57%
PNGフォルダx 26979~91KB144 MB (151,703,806 バイト)50%
PNGをZIP圧縮x1145 MB (152,210,893 バイト)50%
PNGを7z圧縮x1129 MB (136,191,909 バイト)45%
M4Vx17.59 MB (7,967,835 バイト)2%

AVIをBMPに変換するとほぼぴったり同じサイズ。
PNGフォルダをZIP圧縮すると微妙に増えた。
もともとPNGが圧縮されてるので似たようなアルゴリズムではこれ以上減らない
フルサイズの音付きMP4が30MB程度なのに4%の画面サイズのPNG連番が150MB(5倍!)ってMP4すげえ!

音無しのM4Vだと圧縮率2%!!!一体どんな技術なんだ!?

ざっくり見て1秒間29コマ、1.6MB程度 、かなり効率が悪い

  • 1コマ ((145MB) / 2967枚 ) = 55KB
  • 1秒 = 55KB * 29コマ = 約1.6MB
    • ちなみにM4Vは0.082MB(84KB)

じゃあ利用価値はないのか?

  • M4Vのいいところ
    • M4Vなどはゲームで使われることは想定外のはずなのでアルファチャンネルの対応などが出来ない
    • M4Vはキーフレームからの差分データとなるので再生開始フレームの頭出しに時間が掛かる(GOP構造)
    • M4Vはデコードに時間がかかるのでリアルタイムで処理すると重たくなる
    • Cで使えるいい感じのデコーダーがないので画像を取り出してテクスチャ化するとかしにくい
  • PNGムービーのいいところ
    • 自前のPNGムービーならアルファチャンネルを含んだデータを作ることができる
    • PNGムービーは全フレームがキーフレームなので頭出しが簡単、処理時間も食わない
    • PNGムービーはデータ構造が単純なのでデコードが速いので軽い
    • 中身がPNGなのでデコーダーを好きに作れる、テクスチャ化も余裕
    • アルファチャンネル情報をもったゲーム画面を1枚ずつPNGデータとして出力することでアルファチャンネルムービーが作れる!
    • プログラムでムービーを作ることができる

PNGムービーの限界

圧縮に特化したZIPで圧縮しても、M4Vに勝てない。これはなぜか?
すべての動画をフルサイズで格納しているからに他ならない。じゃあ、MP4とかどうなってんの?っていうと、直前の画面との差分をデータとして保持しているため、実質小さい画面の集まりになっているのでサイズを小さくできるのである。

じゃあPNGファイルの1枚1枚を小さくすればいいよね?となるのでその方法を考えてみると、
1枚の基準になる絵(Iフレームとする)
その絵からの差分の小さい絵(Bフレーム)
その前後フレームからの差分の小さい絵(Pフレーム)に分けて保存したりすると良さそうですよね?

そうやって、小さく区切ってグループ化した構造をGOP構造(Group of Picture)といってMPEGで行っている圧縮方法となる。
http://tmpgenc.pegasys-inc.com/ja/support/labo/gop.html
じゃあ僕がMPEGと戦ってより小さいフォーマットを策定できるか?となるわけ。

そもそもMPEGって誰が作ってんの?

MPEGを知るには、まず作ってるヒトを知ってみる。
Mpegとは「Moving Picture Expert Group」の略。ようは「動画つくるの専門グループ」が作ってる。

そのグループが策定したMPEGの歴史を見るとWikiによるとこうなってる

MPEG-1:最初のビデオ・オーディオ圧縮基準。その後、ビデオCD用基準として使用、著名なMP3(Layer 3)オーディオ圧縮フォーマットを含んでいる。
MPEG-2:テレビジョン放送向けの伝送に使用するビデオおよびオーディオ基準。
そして少し修正されてDVDビデオディスクにも使用されている。
MPEG-3:もともとはHDTV用の規格として設計されたが、MPEG-2がHDTVに十分だったことが判明したためMPEG-2に吸収された。
MPEG-4:MPEG-1を拡張して、3D・低ビットレート符号化およびデジタル権利管理をサポートするために規格化されたビデオ・オーディオオブジェクトである。MPEG-2ビデオより新しく高い効率ビデオ規格が設定されており、プロファイルの単純化を進めて、ビデオ・コーディングの効率化を図った。
MPEG-7、MPEG-21:MPEGはこの将来の基準をマルチメディア・フレームワークと評している。

なので、これらを突き詰めていくと、仕事帰りに最適なGOPデータを生み出すアルゴリズムを考える僕と、毎日汗水垂らしてファイルサイズを小さくして高画質化している動画専門家集団(略してMPEG)に「勝てない」

http://itpro.nikkeibp.co.jp/members/ITPro/USURA/20020314/1/?rt=nocnt

つまり

  • たれながすならmpeg!
  • ゲームで利用したり加工したりするならpngムービー!

bsf形式などmpegデータを簡単に扱えるAPIがあるコンシューマーゲーム機は最強。
RenderWareなどのアルファチャンネルムービー機能を持つミドルウェアもいい。
金もプラットフォームもなければ自作PNGになるしかない?

かというと、そうでもない

MPEGではゲームで使える加工はできないのか?というとそうでもなかった。OpenCVというカメラを扱うオープンプロジェクトがある、カメラから画像を入力して画像解析して解析結果を出力できるらしい。カメラ画像の代わりに既に撮り終えた動画データを読み込ませて、解析なしに出力すれば、動画を読み込んでピクセル情報を取り出せるかもしれない??

対応プラットフォームが限られてしまうがOpenCVを使った動画再生できる
環境ならこれを使うのが確実。

OpenCVにチャレンジ