Mozilla Flux

Mozilla関係の情報に特化したブログです。

Ogg形式のビデオ再生機能がBeta 4でパフォーマンスアップ

Firefox 3.5は、Ogg Theora/Vorbis形式のビデオファイル(含音声)を、プラグインなしで再生することができる。HTML5のvideo要素もサポートしているため、videoタグ内にOgg形式のファイルが指定されていれば、それを読み取って適切に処理してくれる。

しかし、Firefox 3.1 Beta 3のビデオ再生処理は、お世辞にも優れているとは言えなかった。そのことは開発者たちも認識しており、既知の問題として、「古いコンピューターあるいは遅いインターネット回線のユーザーは、Ogg形式のビデオ/オーディオを再生する際、途切れ途切れになることがある」と注意を促していたほどだ。

具体的な問題点を挙げてみよう。「GNOME Live!」の『GnomeShell/Screencasts』に同形式の動画があるので、試してみようと思われる方は、そちらを参照してほしい。

まず、動画再生にかかるCPU負荷は、動画サイズやユーザーの環境にかなり依存する。Flash形式のビデオとあまり変わらないときもあるが、Ogg形式の動画再生に支障をきたすケースもある。これに対し、メモリ使用量の問題は常に悩ましい。データを読み込みながら、デコード済みの情報をメモリに保持する仕様のため、ファイルの大きさ次第では、Firefoxの使用メモリ量が急激に増える。タブを一つしか開いていないのに、200MBや300MBといった数字になることさえある。

再生中、この使用メモリ量が減っていくので、視聴が終わったデータをメモリから追い出しているのがわかる。この挙動から予想されるのは、シークバーをずらして巻き戻しにするとデータの再読込が必要になるが、早送りならそれは起きないだろうということ。ところが、早送りしても再読込が行われる。しかも、せっかくデコードした情報は完全にクリアされ、サーバーから再び全データを受け取るのだ。その間、帯域幅を消費し、いったん激減したメモリ使用量がまたどんどん増えていく。そして、巻き戻しの場合も同じ現象が起きる。

video要素で埋め込まれた動画の場合、問題はさらに深刻だ。上に挙げた読み込み処理と使用メモリの急増が、動画の再生ボタンを押す前に発生する。そればかりか、動画の元サイズよりも拡大・縮小された枠を指定した場合、その処理が加わってパフォーマンスがかなり悪くなる。皮肉なことに、Mozilla関係者がFirefox 3.5のビデオ再生機能をアピールした動画を視聴すると、その低パフォーマンスぶりを体感できてしまう。ちなみに、この動画は同じ内容でFlash形式のものがVimeoにあるため、比較が可能なのだが、Flash版の再生はスムーズだ。

このように、Firefox 3.1 Beta 3は、ビデオ再生機能に関して課題が山積みの状態だった。たとえば、Makoto Kato氏は、『Firefox 3.1/3.5 のVIDEO再生のパフォーマンス』の中で、次のように指摘している。

Firefoxに内蔵されたビデオ再生機能のパフォーマンスは非常に良くない。

動画系のコードをみればわかるけど、iDCT (逆離散コサイン変換) やYUV->RGB変換など、SIMDで高速化できるような処理をMMXやSSE2を使わずに処理しているので、パフォーマンスが悪くて当然 (oggを扱えるアプリケーションは、本家のライブラリを使わずにチューニングした別のライブラリを使っているのが見受けられるくらい、本家のライブラリはチューニング不足)。最新のliboggplayとかであれば、YUV->RGB変換などをMMXやSSE2等を利用してスピードを稼いでいるので、Firefoxで利用している各ライブラリがバージョンアップされれば、ある程度はパフォーマンスが向上するとは思う。

そのほか、Chris Double氏の『liboggplay playback performance』も、サイズの大きなビデオでパフォーマンスが悪くなる点を指摘している。

しかし、Shiretoko Nightly(3.5b4pre, ID:20090410053901)以降では、再生パフォーマンスやキャッシュの問題が大幅に改善された。パフォーマンス面では、liboggplayが最新版にアップデートされたことが大きい(Bug 485291)。これによって、YUV->RGB変換の処理が強化された。また、ビデオフレームのレンダリングおよび描画に関する処理も最適化した(Bug 474748)。開発者のコメントによれば、YUV->RGB変換が処理時間の19%を占めるのに対し、ビデオフレームのレンダリングと描画に関する処理も14%を占めているので、これを最適化すると効果が大きいのだそうだ。

そのほか、読み込みのアルゴリズムを新しくし(Bug 479859)、ビデオコントロール機能のパフォーマンスもチューニングした(Bug 483841Bug 484935)ほか、シーク処理にも手を入れた(Bug 477899)。

キャッシュの問題については、メディアデータに専用キャッシュを用意する(Bug 475441)という抜本的な対策が取られた。Firefox 3.5の開発責任者に名を連ねるRobert O'Callahan氏が、『Media Cache』で解説を加えているが、ネットワークライブラリ (Necko) のキャッシュから分離することで、スマートな管理が可能になったのである。

メディアキャッシュは、4KBの固定ブロックで構成され、デフォルトでは50MBの上限が定められている。これだけでも、上で挙げた問題が大きく改善されるのがわかるだろう。大きな動画ファイルを先読みするときでも、Firefoxのメモリ使用量は+50MBで止まってくれるのだから。また、既にキャッシュ済みのデータについて再度ダウンロードすることはなくなったほか、再生済みのデータもキャッシュするようになった。前者は早送りのケース、後者は巻き戻しのケースで、それぞれ無駄な再読込がなくなったことを意味する。さらに、キャッシュの置き換えは最も重要なデータが残る形でなされるなど、メディアキャッシュは多数の改善ポイントを含んでいる。

以上のような強化によって、ようやくFirefox 3.5のビデオ再生機能は実用的なものになってきた。筆者の環境では、さすがに軽快とまではいかないが、再生が途切れ途切れになる現象には遭わなくなった。Beta 3で再生が重いと感じたなら、Firefox 3.5 Beta 4のリリース後にもう一度試してみてほしい。きっと違いを実感できるはずだ。

なお、Blockerバグのリストを眺めると、さらなる修正が施されるようなので、最終的なパフォーマンスはもう少し上がると見ていいだろう。