今のところどれぐらい進んでいるかというと、ようやくブロック層まで降りてきて、量子化された DCT 係数を逆量子化するところまで進んでいる。
まあ、順調……なのかな？
というわけで、MPEG-2 VIDEO デコーダを書いていての愚痴を二つ
まず、前回に MSSG の MPEG2DEC はグローバル変数を多く使っているので下手に手をつけられないと書いたが、あれは MSSG が悪いわけではなく、MPEG-2 VIDEO の構造じたいが悪いようだ。うん。グローバル変数多用する気持は良く判る。
つーか、規格書の中で「これはここでしか使われないローカルな変数だ」とかいうのがわざわざ出てくるところを見ると、規格的には、名前をつけてある変数は原則的にすべてグローバルだぐらいのつもりで書いているのだろう。
とんでもない話だとは思うが、そーなってる以上は仕方がない……。
……意地でもグローバル変数なんて使うもんか。
で、もひとつの愚痴。今デコーダを書くのに参考にしている規格書は Wotsit's Format に流出してた ITU-T H.262 なんだけど……、ど・う・し・て、規格書を MS-Word DOC Ver.6 フォーマットで配布するのかな〜（怒）
う〜、Word 98 で読ませてみたら、案の定、図は全部消えてるし、罫線は楽しいことになってるし……。やってられん。
とりあえず MPEG-2 VIDEO VFAPI Plug-In は何とか動くところまで漕ぎ着け、いちおうリリースしておおむね好評のようなので、盆の間やら m2v.vfp のデバッグで死んでた時のメールの返事を書いたり、MO に追放したり DM を消したりしてる。
うーん、3 M も良く溜めたよな〜。まず ML からのメールを一通り目を通してから MO に追放。この時点で 2M ほど消えて、あと DM を消すので 100K 程度。返事を書かなきゃいけないメールは 4 通程なので、さくっと片付けて……といかないのが悲しいところ。無い頭を絞って文面を考える。考える……。考えた。
あんまり良い文章じゃ無いな〜。最低限、意図は通じるはずだけど、なんか、こう。ま、いいか出しちゃえ。
んーと、だれも見てないだろうけど、もう少ししたらページのデザイン変えます。（ああ、語尾が変わってる）
今トップに置いてある、ここ３年ほどまったく更新してないページはすべて……まあ、消すまでもないか、ファイルは置いときますけど、トップからのリンクを切ります。
んで、今の所独立して運営してる ここ とか ここ とか、ここ とか、ここ なんかをまとめて、動画系の人柱情報＆ツールのページにしようかと。
まあこんなことしても、卒業すれば消えてしまうわけですが、いちおう卒業後に管理する予定のページの下拵え程度はしておこうかと考えて。
というわけで、そんな人は居ないだろうけれども、このページチェックしてる方いましたら、そーゆー事ですので。コンゴトモヨロシク。
んと、Intel から libjpeg 用の MMX 版 IDCT 関数を入手することはできた。MSSG の idct 関数は libjpeg の LLM 版を参考にかかれたのみたいだから、多分ちょこちょこといじればそのまま使えるようになると思う。
あと、高速 DCT のアルゴリズムとしては LLM の他に AAN というすごく高速な（ただし誤差が比較的大きい）アルゴリズムがあるらしく、それのソースも手に入ったのだけど……なぜ、日本人が考案して、日本語で原論文が発表されてるのを、日本人がわざわざ英語で書かれた解説を読みながら勉強しなきゃいけないのか悲しくなってきてしまった。
いや、まあ、私の探し方が悪いだけなのかもしれないけど、IEICE（電子情報通信学会論文誌） Vol. 71 はこの大学の図書館には無いだろうし……うん、検索してみたら所蔵してるのは Vol. 72 からだった。
GOO やら Infoseek やらで AAN DCT で検索してもまともな情報は全然でてこない。一番参考になるのは intel.co.jp だっつ〜から嫌になる。
日本語の技術情報ってどうしてこう貧弱なんだろうと悲しくなってしまう。
んーと、m2v.vfp の評判はどんな感じかな〜というわけで先週末から昨日の２４時までのアクセスログを眺めてみた。
意外にも結構 co.jp からのアクセスが多いのが驚き。駄目じゃん、仕事中にこんなの落としてちゃ。
でも、fw1.iodata.co.jp とかはひょっとしたらお仕事なのかも。う〜んご苦労様です。WEB での評判をこんなにも気にするぐらいならもう少しきっちりテストして最初からバグの少いドライバリリースすれば良いのに。GV-MPEG2/PCI だとどんな感じになるのだろう（わくわく）
あと、もひとつ気になるところとして、ps.melco.co.jp からの m2v.vfp へのアクセスがこの３日間だけで 25 回もあることなんだよね〜。なんでこんなに頻繁にアクセスしてるんだろう。MEG-VC2 の方は大丈夫なのかな？
そんなこと言ってるくせに、m2v.vfp はバグだらけでこの３日間で４回もアーカイブ更新してるだろ？ いいじゃん、個人開発のフリーソフトなんだから、十分なテスト体制が取れないのは当然でしょ。問題はバグ報告にどれだけすばやく対処できるかだよね。（開きなおり）
アクセスログの方に戻るけど、何故そんなところから……と言いたくなってしまうのが .lt ドメイン。.lt ってどこだろう？ 何度もリトライしてやっと落とせたみたい（ごめんね回線細くて、読んでないだろうけど）無事に使えたのかな〜。
でリトライとかも含めてるけど３日間で大体 600 件のダウンロード。う〜ん、流石 mv300 の linux 用ドライバとは桁が違うと感動。（あっちは月に１件ぐらいしかアクセスないからな〜）
出会わなければ仕合せでいられたのに……。
MPEG.ORG のリンク先から落とせるデコーダテスト用の M2V のサンプルビットストリームを m2v.vfp に入れてテストしていたところ、絶対に存在しないだろうと期待していた GOP 内に複数の I フレームがある MPEG-2 VIDEO ストリームに出会ってしまった。
あ〜、見つけた以上対応しなきゃまずいよな〜。
いちおう、m2v.vfp の目標はプロファイルもレベルも関係無く、有効な M2V ならば全てデコードできるようにしとくことだから（ただし、M2V が複数必要なスケーラビリティについては対応する気がない）
しかし、GOP 内に複数の I フレーム入れられたのか、確かに規格読んだ限りじゃ入れちゃダメとは書いてなかったけど。
う〜、どうしてくれよう。この場合ピクチャヘッダの temporal_reference は使えなくなるから……。picture_coding_type 見ながら一ずつフレーム数えるしかないか〜。
あぁぁ、どんどんコードが汚くなっていく（涙）
師よ、少なくとも規格どおりに書けばデコーダは完成すると言っても、規格がワケワカなほどにこんがらがってるのはどう対処すれば良いのでしょう？
とりあえず、高速化よりも先にバグ修正だよなぁ、一般的な優先順位としては。済みません、MMX/SSE 対応はさらに先になりそうです。
実に汚いコードになってしまったが、なんとか例の GOP 内に複数の I フレームを持つストリームに対応させる事ができた。
ただし、GOP ヘッダを持たない I ピクチャにたいしてのタイムコードを利用したシークが発生すると、例によって例のごとく悶死してしまうはず。（というわけで、GOP を入れるなら入れる、入れないならいれないでどちらかのみにしてください）
本当は何とかしたいのだけど、私のスキルでは今の所解決策が思い浮かばないので仕方がない。
で、もう一つ良い情報として、MSSG.ORG からリンクされてるテスト用のサンプルビットストリームの中にフィールド構造ピクチャを持つビットストリームを発見することができた。
とりあえず Ver. 0.1.5 では予想どおり壊れたデコードしかできなかったのだけれども、多分そのうちまともにデコードできるようになるはず（多分）
昨日見つけたバグが３＋α匹、捕まえたバグが３匹、潰したバグが３匹。
まだまだ問題が残ってるところが悲しい。次のバグが最後だと良いのだけど、それも望み薄だったりする。
多分 MC で VLC のデコードを間違えてるとか動きベクトルの解釈を間違えてるとかだと思うのだけど、これ以外にも虫が入っていそうなので……今日中に片付くかどうか。
MMX 化に取り掛かれるのは何時になるのかな〜といった状況なので、システムストリームに対応するなんてのは遥か先の話。悲しいけどこれが現実。
う〜、虫を捕まえる事ができない。デバッガで動作をトレースしていても、虫が発生しているはずのところで MPEG2DEC の -t -v5 の出力と同じ PMV が得られているのが謎。
16x16 で片フィールドにのみ問題が発生してるから 16x8 MC の扱いに失敗しているのだろうと推測していたのだけれども、quantiser_scale_code が 1 で、かなり DCT 係数が振られているマクロブロックで問題が発生しているようなので、逆量子化とかミスマッチコントロールとか、あとは IDCT 後のブロックデータをフレームに書き出す時点でバグを入れていたのかもしれない。
とりあえず、その辺について今日トレースする予定。
あと、まだ潰していないけれども、もう一匹バグを発見して、こちらは捕獲することができた。余裕ができればすぐに直せるはず。
バグの内容は、ある特殊なビットストリームで総フレーム数を算出する際に無限ループに入る事があるというもの。GOP が一つしかない短いビットストリームでしか発生しないから滅多に発生しないはず。
フィールドピクチャのデコードでのバグだが、ようやく解決する事ができた。まあ判ってしまえば馬鹿なバグで MC の参照フィールドと出力フィールドを選択する際 motion_vetical_field_select だけを見ていて picture_structure を考慮していなかったという内容。
しかも後方参照での動き補償時でのみバグを入れていたというのだから嫌になる。フィールドピクチャの動き補償書いてたとき、一体何を考えていたのだろうとつっこみをいれたくなってしまう。（そういえば、フィールドピクチャってどのエンコーダが使うんだよ、作れるの見たことないぞ、こんなものがあるせいで規格がややこしくなってるんだよな〜とか考えていた記憶が……うむ、入れてるバグが多いのも納得してしまう）
しかし、ここまでやってもまだバグを出すテスト用ビットストリームがあるのには嫌になってくる。まだ詳しく調べてはいないのだが、今回エラーを出してくれたのは Sony の CT-1 ビットストリームだったかな〜。
そういえば前回 422-Profile なデータを入れたときにも大量のバグを出してくれたっけ（Sony のは鬼門だな）と思いだし、昨日はその時点で沈没。今日もう少し追求してみる予定。
で、そろそろデコーダのバグも少くなってきた気がするので、最適化とか高速化について考えはじめている。目標は 720x480 を P-III 500 で 15 fps（現在よりも 3 倍高速化しなければいけないというのはかなり無謀かも）
まずは SIMD などというややこしい手法を使わずにどこまで行けるかということで、DCT 係数を逆量子化する際に -2048 〜 2048 のクリッピングおよびミスマッチコントロールをしていたのをバッサリとコメントアウトしてみる
うむ、ちょっぴり（5% 程度）速くなった。やはり DCT 係数一つにつき一回の比較はかなり遅いらしい。しかしクリッピングはともかく、ミスマッチコントロールをやらないのは問題があるだろうというわけで、現在の非効率的な逆量子化方法をもう少し効率的なものに変更する必要がある。
あと SIMD を使わずに高速化できそうなのというと、YUV 420 -> YUV 422 への補完ぐらいで、MC とか IDCT の高速化は SIMD を使うしかなさそう。VLC のデコードは SIMD 化は無理だろうし、YUV -> RGB 変換も SIMD 使えばもう少し速くなるかな。