2011-12-05 (月)
*mp4とかH.264とか
そろそろ，mp4とかH.264とかを読めるようになっておきたい．
規格書見ないとちゃんと分からない気もするけど，ぐぐってみる．
mp4は track(音声，映像)のストリームが，chunkというものに分割されていて，chunk内に複数のsampleが入っているということまでは理解．sampleが何の単位なのかまだいまいち分からない．映像の場合はフレームと1対1と考えていいのかな．aviのRIFFより少し面倒だけど難しくはなさそう．
せめてH.264のNAL構造が見えるところまでたどり着きたい．
http://up-cat.net/H%252E264%252FAVC%2528NAL%2529.html
http://d.hatena.ne.jp/SofiyaCat/20080430
[Android] Androidで作ったH.264のmp4動画を眺めたメモ
機種やAndroidのバージョンによっては，カメラで撮った動画をH.264+AACなmp4(m4v)で保存できるけど，ついでなので色々見てみる．
眠いのでコード追うのは諦めてしまった．あと，動画ファイルとかの知識がほとんど無いので意味不明なこと書いてるかも．なので，これ読んでも何かの参考にはしないほうが良いです．
アプリによって，moovがmdatより前にくるものと，後にくるものがあるっぽい．3gpファイルは後みたいなので，MediaRecorderに渡すOutputFormatの違いかな．挙動を観察していると，m4v形式でも撮影中はmoovがある位置はfreeになっていて，あとからmoovを書き込むっぽい．まぁ，stblを事前に作るのは無理なので仕方ない．ことのき400KBくらいのfree atomを作るみたいなので，mdat atomは毎回62E20h付近になる．でも，3gpでも謎の3KBくらいのfree atomが存在している．
AndroidアプリでMediaRecorderからストリームを横取りして，ファイルを介さずにmp4をごにょごにょしたい場合，moovの情報は入って無いわけか．ここは自分で設定したパラメータが分かってれば問題ないのかな．
このあたりからは必ずそうなのかかなり怪しいけど，オーディオトラックのstszを見る限りsampleあたり768バイト固定っぽい．１つのオーディオchunk内に固定長のsampleが並ぶので，バイナリエディタで眺めたときにmdatのところどころに縞模様が見える．で，その間にあるでかい塊がビデオストリームの1チャンク分のデータ．stcoのテーブルを見る限り大体それであってそう．
chunkのoffsetは，mp4ファイル内での絶対位置っぽい．mdatの特定の場所を指していて，いかにもそこから意味のあるデータが始まってますって感じのバイト列．
ビデオトラックのchunkはぱっと見は一様なランダムなビット列に見えてしまうけど，よく見ると，一定間隔で 00 00 があるように見えるような気がする．この間隔がstszに書かれたsampleのサイズと一致しているのが分かる．さらによく見ると，00 00 を含めた 32ビット が stszのサンプルサイズ-4バイトなので，sample自体が サイズ+データの構造になってるわけか．数えてみると，sample数はフレーム数にかなり正確に一致している気がする．あといくつかデータが大きいsampleがあるけどこれがIフレームかな．
ずっとバイナリエディタはBzを愛用してるのだけど，扱うデータは大きくなる一方なので，自分用のを作っておきたい．
あと，前にも書いた気がするけどWindows7についてる電卓はひどい．「プログラマ」を選ぶと16進や2進表記で計算できるのだけど，ほとんどの関数が使えないどころか，整数しか使えない．プログラマは離散世界に住む生物なので実数は不要だと思われたんでしょうか．そして関数電卓に切り替えると入力中の数値や式が消えるので，途中で実数や関数が必要になった場合はクリップボードを経由するしかない．ペイントはちゃんと進化してるのになぁ．残念．
あれ…何の話だっけか．