
世界最速というVP8デコーダ「ffvp8」登場 18
ストーリー by hylom
はやっ 部門より
はやっ 部門より
あるAnonymous Coward 曰く、
Googleが提供するVP8デコーダよりも高速というVP8デコーダ「ffvp8」が登場した。ffvp8はFFmpegのSVNリポジトリにすでに投入されているとのこと(x264開発者のブログ)。
ブログ上にある性能比較結果を見る限り、Googleのlibvpxと比較して最大で1.5倍以上高速、という結果が得られたようだ。特に64ビット環境で大きく性能が向上している。
エンコーダじゃなくてデコーダ、デコーダ (スコア:3, すばらしい洞察)
編集しっかり
Re:エンコーダじゃなくてデコーダ、デコーダ (スコア:1)
「Googleのlibvpxと比較して最大で1.5倍以上高速」に再生されるんですね、わかります。
-------- tear straight across --------
Re:エンコーダじゃなくてデコーダ、デコーダ (スコア:1)
20~25fpsなシステムが30fpsでデコード可能になるとか、
ぎりぎり30fpsでも余裕が出来て安定して30fpsをキープ出来るようになるとか、
CPU利用実時間が減るなら軽くなるので素晴らしいですな。
# H.264ならVGAにお任せという解もあるけど、VP8はそうもいかないしね。
Re: (スコア:0)
Re: (スコア:0)
> # H.264ならVGAにお任せという解もあるけど、
またおじいちゃんたら、いい年して恥ずかしいんだからまったくもう、夏厨じゃあるまいし…
#VGAはビデオカードやグラフィックボードの略称じゃないんだぜ
Re:エンコーダじゃなくてデコーダ、デコーダ (スコア:1)
これは失礼。
正しくはVGAでなく、GPUですね。
GPU以外ではBCM70010/BCM70012 [broadcom.com]とかもあります。
「登場」? (スコア:1, 参考になる)
> Googleが提供するVP8エンコーダよりも高速というVP8エンコーダ「ffvp8」が登場した。
これ、関連ストーリーFFmpegがVP8のネイティブデコードに対応 [srad.jp]で紹介されているもののアップデートですから、既に「登場」済みの物ですよね。
前回の「登場」段階で既にlibvpxよりも高速だったわけで、「世界最速」といっても今回はせいぜい自己更新。
前回リリース時点でもlibvpxよりも40~50%速かったようですし、「劇的に更新」というほどでもなく、
チューニング後の安定化版に近い位置付けかも。
ということで、今回のストーリーで「登場」「世界最速」をアピールするのは非常に違和感が。
# まあ、デコーダとエンコーダの間違いすら気づかない「確認」なので
# 編集側は素で「今度はエンコーダ登場だ」と思っていたのかもしれませんが...
そんなわけで、今回目新しいところとしてはx264のJason Garrett-Glaser氏協力の下で
高速化取り組みの第一段階が完了、彼自身による評価レポートが出てきたってところかな。
コーデックマニア :-) には興味深いです話題ですが、利用者視点では目新しい話題ではなさそう。
Re: (スコア:0)
>前回リリース時点でもlibvpxよりも40~50%速かったようですし
前回のそれはSIMD無しで比べたときのものという話だったような。
色んな対決が見たい (スコア:0)
ところで出来上がった動画ファイルはバイナリレベルで一致するんだろか?どこか手抜きして速くなったーとかじゃないよね
Re:色んな対決が見たい (スコア:3, すばらしい洞察)
>ところで出来上がった動画ファイルはバイナリレベルで一致するんだろか?
誤差の2乗和とかで品質の優劣を判断するならともかく、
バイナリレベルの一致なんて何の意味があるの?
Re:色んな対決が見たい (スコア:3, 参考になる)
> A few weeks ago the decoder was complete enough to be bit-exact with libvpx
ということで、libvpx (Googleオリジナルのデコーダ)と
ビットレベルで一致するところまで来たとあります。
補足すると、VP8やH.264のデコードアルゴリズムは
同一の圧縮済みストリームをデコードさせる限り、
どんなデコーダでも全く同一の結果が得られる
ように規格が設計されていて、リファレンスデコーダ
(ここではlibvpx)のデコード結果と比較することで、
デコーダの規格適合性を簡単に判定できるように
なっています。
ちなみに、MPEG-2 は、DCTの実数演算の丸め誤差の
処理の方法に差が発生し得る規格なので、
正しいデコーダ同士でもデコード結果が同一に
なるとは限らず、そういう検証のしかたはできませんでした。
Re: (スコア:0)
すでに指摘がありますが、これは「デコーダができた」という話ですね。
もちろん、エンコーダの場合は、同じ映像を入れてもエンコーダが違えば
同一のストリームになるとは限りません。デコードされたときに、
いかにきれいな画にデコードされるようなストリームを生成できるか
というのがエンコーダの腕の見せ所なわけです。
デコーダよりも実装が難しいですし計算量が大きいのが普通です。
VP8 のデコードって重いの? (スコア:0)
結構重いんじゃないかと感じさせてくれますけど、どう
なのでしょうか?
Re:VP8 のデコードって重いの? (スコア:1)
むしろ軽いが為にHWデコーダが開発されなかったりしないかな。
まあHWデコーダはvlcとかでは使われないんだろうけど。
Re: (スコア:0)
んなこたないでしょ。
携帯デバイスではmp3ですらハードウェアでデコードされてるのに。
Re: (スコア:0)
HD動画とか考えるとGPUサポートは必須ですし、デコード回路もある程度は使いまわせるのでいずれは搭載されてくると思いたいですが・・・
問題は、VP8のデコーダをGPUメーカが積む気になって、開発して、量産して、普及して、その後ようやく利用可能になるってことです。
当分は難しいんじゃないでしょーか。
64ビットで (スコア:0)
64ビットで恩恵があるソフトって嬉しいね。
64ビット環境への移行のためにも、これからもっと増えていって欲しい。