今日の作業

9:12

WMVが再生出来ない問題を、ぴろさんのパッチを参考にしながら修正。ぴろさんの方法だと多分ビッグエンディアンなマシンで壊れるので、そこは適当に。これは本家にも投げようかなぁ。

あ、再生出来ないWMVファイルを持っていないので、リリースした暁にはテストをお願いします。

10:42

352x240の動画再生などで必要になるクリッピングの作業。

ぴろさんのコードを読んでみる。……うーむ、draw_slice()にクリッピングが実装されてるけど、「1回のコールで1フレーム全体を描画する」前提でコードが書かれているような? draw_slice()はそうではなくスライスという単位で描画するメソッドで、例えば640x480のフレームだと1フレームにつき640x16のスライスが40回描画されるんです。

まぁそれはいいとして、なぜMPlayerのVideo filter(-vf crop)を使わずにVideo outで実装しようとしているか。

クリッピング無し
--codec--> BUF(352x240) --vo--> スクリーン
vfでクリッピング
--codec--> BUF(352x240) --crop--> BUF(320x240) --vo--> スクリーン
voでクリッピング
--codec--> BUF(352x240) --vo(with crop)--> スクリーン

こんな流れになると思ったから。バッファのコピーってのは結構重い処理だから無視できない。

クリッピングってのは普通はコピーなんてする必要はなくて、バッファの開始アドレスやX/Y座標をいじるだけで実現出来る。そしてふと思った。cropフィルタは本当にバッファのコピーをしているのか? コードは見てないし、ベンチマークもしていなかった。

そんなわけでコードを見てみたら……。コピーしてないっぽい??? そ、それならベンチマークは……?

$ mplayer -vo bvdd -benchmark -quiet -nosound -nodouble \
  /mnt/card/RL_XQ_480x640_1500_128.avi
BENCHMARKs: VC: 120.816s VO:   0.141s A:   0.000s Sys:   7.760s =  128.718s
$ mplayer -vo bvdd -benchmark -quiet -nosound -nodouble -vf crop=480:624 \
  /mnt/card/RL_XQ_480x640_1500_128.avi
BENCHMARKs: VC: 121.303s VO:   0.145s A:   0.000s Sys:   8.090s =  129.537s

なんてこった! ほとんどパフォーマンスロスがないじゃないか。思い込みって怖い。

結論

  • 352x240動画はフロントエンド側でcropフィルタの指定を追加する
  • 画面サイズを超える動画はエラーを吐いて再生しない

11:49

Video outドライバのconfig()に渡されるパラメータについて。

- src_width, src_height: image source size
- dst_width, dst_height: size of the requested window size, just a hint

よくわからずにsrc_/dst_を使い分けていたけど、真面目に調べた。src_にはフレームの実際のサイズ、dst_には理想的な表示サイズが入るようだ。

たとえば、352x240 アスペクト比4:3の動画のconfig()は、src(352x240)、dst(352x264)になる。352x240をそのまま表示するとアスペクト比が狂うので、voで適宜スケーリングしてね、ってことだろう。普通の用途ではハードウェアスケーラーがあるのが普通なので問題無い。

でもZaurusにはハードウェアスケーラーなんてものはない。そういう場合はdst_を無視して、src_をそのまま使うのが正解のようだ。fbdevドライバがそうなっていた。

というわけで、352x240の再生で固まる問題は無くなると思う。

12:46

352x240->320x240はcropじゃなくてscaleでもイケる。-swsは0のfast bilinearが最速。4のnearest neighbourより速いというのはどういうこっちゃ(いいことだけど)。

ちょっと雷電IIIを遊んできます。

18:20

眠い。ちなみに早朝から昼かけて更新が多いのは夜勤だからです。今は、普通の人の生活サイクルで言うところの03:00といったところかな。

眠いけど寝るのはMPlayer-1.1.1をリリースしてから。

18:51

bvddをbvddリポジトリからmplayerリポジトリのdrivers/bvddに移動させた。履歴が失なわれるのが悲しい。

リポジトリで思い出したけど、Monotoneが気になる。分散型VCSってどうなんだろう。そいや、LinusがBitKeeperにかわるVCSを探していてMonotoneが筆頭候補になったけど、それでも満足できずに自分でツールを書きはじめたとかいう話を以前に読んだ。んで、最近arm-linux-kernelを眺めてたときにLinuxのコアメンバーっぽい人が「Linusは自分のVCSを書くので忙しくてテスト出来ないけど……」なんて発言してて、本当に作ってるんだ……と驚いた。