最適化
INTRAブロックの逆量子化がコード量のわりにかなり重く、なおかつ最適化されたMMX版があったので、iWMMXtに移植していた。半分くらい終わったとこで、IPPで同等の関数が提供されていることに気づいた。ショック。
% cumulative self self total
time seconds seconds calls s/call s/call name
3.33 172.43 11.57 6853500 0.00 0.00 dct_unquantize_h263_intra_c
これが、
% cumulative self self total
time seconds seconds calls s/call s/call name
0.30 310.35 0.96 6853500 0.00 0.00 dct_unquantize_h263_intra_iwmmxt
0.28 313.15 0.91 IPP_IQ_INTRA_ZERO
0.23 314.75 0.75 IPP_IQ_INTRA
0.15 317.55 0.48 ippiQuantInvIntra_Compact_H263_16s_I
0.02 323.77 0.05 IPP_IQ_INTRA_END
こんなに速くなるんだけど、画像に緑が掛かかるようになってしまった。渡すパラメータが違うのかなぁ。
うーん、わからん。そもそもMPlayerのC版とIPPのドキュメントに書かれているアルゴリズムを比較すると、似ているんだけど微妙に違う気がする。自分で書くか。
% cumulative self self total
time seconds seconds calls s/call s/call name
0.92 284.75 2.94 6853500 0.00 0.00 dct_unquantize_h263_intra_iwmmxt
よっしゃ。正常にデコードできる状態でIPPより速くなった。
Result Latencyを考えながら命令をスケジューリングするともの凄く可読性が低くなる。とりあえず可読性優先で書くかなぁ。
- -
ドライバやIPPを使うプログラムを書いてるとよくOSごと固まるので、SL-C3000から追加されたリセットボタンが便利。
- -
ふぅ。RL_XQ_480x640_1500_128.aviが-framedrop無し(すなわち強制的に全フレーム再生)で音声との同期が取れるほどになった。動きの激しいシーンで0.3秒程度ずれることがあるけど、すぐに追い付く。まだ最適化の余地があるので、それで少しデコードに余裕を持たせてその時間をローテート処理にまわせば640x480もいけるように……。
ぴろさんの日記のデータに加えるとこんな感じ。
| kernel glibc | normal | soft-float | mplayer-w100 | fastfpe | fastfpe | fastfpe | fastfpe | bvdd | iwmmxt-ipp | C700 | iwmmxt-ipp | core freq | 416MHz | 416MHz | 471MHz | 416MHz | 624MHz | 520MHz | 624MHz | 624MHz | memoly controller freq (PX bus) | 204MHz | 204MHz | 132.7MHz | 204MHz | 204MHz | 260MHz | 312MHz | 312MHz | time | 6分10秒 | 5分26秒 | 5分39秒 | 6分03秒 | 5分16秒 | 4分50秒 | 4分04秒 | 2分27秒 |
- -
あと画面の書き換えがモロに見えて汚ないので、ダブルバッファリングをサポートしないとなぁ。
OSDをどうするか。ハードウェア側でOSDと映像の合成処理が出来そうなので、そのうち試してみたい。
- -
まぁこれでVGAなDivXが実用になったとしても、現実的にはザウルスじゃどう足掻いてもWMV9は見られないので*1、そういうのを求める方はPocketPCを使うのが正解だと思います。僕はWMV/WMAは一切使わないし使いたくないので、全然構わないんですが。
