Dark_Shikari、VP8について語る

Diary Of An x264 Developer » VP8: a retrospective

x264の開発者であり、ffmpegのVP8デコーダーの開発者でもあるDark_Shikariが、VP8の技術上の利点欠点について述べている。

僕はこの数週間、ffmpegのVP8デコーダーの開発を手伝ってた。On2のVP8動画フォーマットの、初の第三者による実装というわけだ。僕は数千行のアセンブリコードを書いて、さらに一部のCコードの最適化もした。そこで、VP8についていくつか意見を吐いたところ、それがネット上に広まっている。当時は正しかったが、今となっては変更されたこともある。

画質の比較という問題がある。まあこれに関しては、MSUの比較で、x264の圧勝ということが示されたわけだが、VP8の開発者はようやく、ピノキオの鼻を伸ばすのをやめることにしたらしい。まあ、x264が完膚無きにまで優れているのは当然のことなので、どうでもいいことだ。その点については、これ以上言及しない。技術的に一番でなければ役に立たないということはない。

あとちょっとのアセンブリの関数を書けば、ffmpegのVP8デコーダーが完成する。完成した暁には、libvpx（Googleに買収されたOn2自身による実装）との比較がしたいものだ。

1. 規格書、もとい、バイナリ列の説明書

Googleはようやく、規格書（spec）と呼ぶのをやめて、バイナリ列の説明書（bitstream guide）という言葉を使い始めた。これはどういうことか。自称規格書が公開されてからというもの、多くの批判がでた。そもそもが不完全な定義だらけなのだが、特にひどいのが、規格と公式のエンコーダー、デコーダーの実装が、異なっている箇所が、少なくとも数十ヶ所はあるからだ。The deblocking filter, motion vector clamping, probability tablesなどなど、多くの箇所が、規格と異なっている。幸いにして、ffmpegのVP8デコーダーの開発者の一人であるRonald Bultjeは、リバースエンジニアリングに長けているので、我々はとりあえず、実装の方を合わせることができたわけだ。

多くの差異は、それほど重要というわけではない。とくに、画質に影響を与えるものでもない。しかし、「動くVP8デコーダー」を実装するのが困難であるし、そもそも、「動く」ということに関する定義すら怪しいものになってしまう。例えば、Googleのデコーダーは、「ALTとGOLDENのリファレンスフレームを交換せよ」と命じられたならば、両方のフレームをGOLDENで上書きする。なぜならば、まず最初にGOLDEN = ALTと設定し、さらにALT = GOLDENと設定するからだ。これはバグなのか？　それとも、こう動くべきなのか？　規格では何も言及していないため、よく分からん。Googleによれば、libvpxの動作はすべて正しいとしている。しかし、これは疑問だ。

僕は、規格が書かれることを望んでいる。Googleは自前のドキュメントすら揃わぬうちに早期リリースするものだから、こういう問題が生じることになる。外部の人間もGoogle社の開発者も皆、その被害をこうむることになるのだ。

訳注：以下、2.から5.まで、規格ではなく、VP8の動画圧縮の技術上の利点と欠点に対するコメントが続く。2, 4は、利点について、3, 5は欠点について述べている。

6. インターレースをサポートしない

キタコレｗｗｗｗｗｗｗこれで勝つる！ｗｗｗｗｗｗｗｗｗｗｗｗ

インターレースはH.264の暗黒面である。インターレースは規格のあらゆる部分で首をもたげてくる。結果として、デコーダーの実装は何千行も長くなってしまうのだ。H.264はさらにものすごく複雑で、効果的な、インターレース専用のコード方法を提供している。MBAFFだ。MBAFFの存在は、いまだにアナログ時代に住人である1080i、576i、480iとかのコンテンツを提供する奴らには利点があるが、すでに過去の遺物だ。

VP8はよくぞクソ地獄から逃れた。

もしどこかのアホが、インターレースのサポートなんぞをVP8のブランチに入れようとしたならば、現実世界に被害を及ぼさないうちに、拘束具をかませて精神病棟に送り込むべきである。