libtheora実装日記その3

というわけでテクスチャへの直接展開側の処理もほぼくみ終わってとりあえず一段落、というところでしょうか。

通常の再生だけならバグもなく普通にループ再生ができるようになりました。

で、昨日の記事で書いていた問題点

  1. デコードにCPU処理がかかりすぎている
  2. シーク処理がうまくいかない

ですが、これらについてちょっと解説を。

libtheoraのデコーダの処理負荷設定には注意を

libtheoraではPostProcessingの負荷率を変更することができる設定があります。[TH_DECCTL_SET_PPLEVEL]

デフォルト値では0(PostProcessingを行わない)ですが、これを変更することで負荷が大きくなる代わりにtheoraの処理に有利な点(画質の向上?)が現れます。

で、これがかなり処理をとるらしく、昨日は最大値にしたままデコードしていたんですが、今日の実装終了時にはデフォルト値のままデコードさせることで

普通の負荷率で再生させることができるようになりました。昨日のCPUの負荷率は1コア換算で80%[2GHz]相当でした。

・・・1GHz分くらいのクロックをとる処理って何なんだろうかと思っていますが・・・

シーク処理はストリームのリセットと位置の把握が重要

libtheoraのplayerサンプルにはシーク処理が書いていないのでちょっと難しいです。

基本はlibvorbisとvorbisfileで実装されているシーク処理が参考になります。ただし、シークポイントを探すためにoggのコンテナを直読み出しする必要がある場合があります。

前後のoggストリームに移動して、oggの同期ポイントを調べるという処理ですが・・・。この辺は詳しく説明してもどうしようもないので。

vorbis側の同期はそれほど難しくないですが、theora側の同期がちょっとやっかいで、キーフレームが来るまでフレームを出力しないようにしないとよくないです。

theoraのフレームはIFrameとPFrameだけで作られているので、PFrameから開始する(シークした時点で状態をリセットするためにシーク前のデコーダを破棄している)と、

グレイの絵を基準フレームとしてとりあえず処理を開始するらしく、しばらく灰色+動き補償の絵という状態になります。

私はこの部分を無視(表示されてもいいや・・・)しましたが、シーク処理を完全にするならこの処理をちゃんと実装しないとだめですね。

ということで、シーク処理がかなり不完全なので微妙ですが、ゲームの背景動画やイベント動画として使う分には十分な速度と画質だろうと思い、

このまま組み込んでおくことにしました。先頭に巻き戻す分にはシーク処理は問題なく動くので。

libtheoraはlibvorbisなどと同じでBSDライセンスのフリーコーデックなので組み込んでおくと後々楽だと思います。

特にほかのプラットフォームに移植する可能性がある(linux系だけではなくMac系にも)場合はこういうのをあらかじめ採用しておくとやりやすいですからね。


コメントを残す

メールアドレスが公開されることはありません。

*

この記事のトラックバック用URL