パスワードを忘れた? アカウント作成
241471 story
オープンソース

世界最速というVP8デコーダ「ffvp8」登場 18

ストーリー by hylom
はやっ 部門より

あるAnonymous Coward 曰く、

Googleが提供するVP8デコーダよりも高速というVP8デコーダ「ffvp8」が登場した。ffvp8はFFmpegのSVNリポジトリにすでに投入されているとのこと(x264開発者のブログ)。

ブログ上にある性能比較結果を見る限り、Googleのlibvpxと比較して最大で1.5倍以上高速、という結果が得られたようだ。特に64ビット環境で大きく性能が向上している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2010年07月28日 19時43分 (#1801487)

    編集しっかり

  • 「登場」? (スコア:1, 参考になる)

    by Anonymous Coward on 2010年07月29日 0時34分 (#1801605)

    > Googleが提供するVP8エンコーダよりも高速というVP8エンコーダ「ffvp8」が登場した。

    これ、関連ストーリーFFmpegがVP8のネイティブデコードに対応 [srad.jp]で紹介されているもののアップデートですから、既に「登場」済みの物ですよね。

    前回の「登場」段階で既にlibvpxよりも高速だったわけで、「世界最速」といっても今回はせいぜい自己更新。
    前回リリース時点でもlibvpxよりも40~50%速かったようですし、「劇的に更新」というほどでもなく、
    チューニング後の安定化版に近い位置付けかも。

    ということで、今回のストーリーで「登場」「世界最速」をアピールするのは非常に違和感が。
    # まあ、デコーダとエンコーダの間違いすら気づかない「確認」なので
    # 編集側は素で「今度はエンコーダ登場だ」と思っていたのかもしれませんが...

    そんなわけで、今回目新しいところとしてはx264のJason Garrett-Glaser氏協力の下で
    高速化取り組みの第一段階が完了、彼自身による評価レポートが出てきたってところかな。

    コーデックマニア :-) には興味深いです話題ですが、利用者視点では目新しい話題ではなさそう。

    • by Anonymous Coward

      >前回リリース時点でもlibvpxよりも40~50%速かったようですし
      前回のそれはSIMD無しで比べたときのものという話だったような。

  • by Anonymous Coward on 2010年07月28日 18時47分 (#1801465)
    同一PCでの32bit vs 64bitとか、同一品質?でのx264との比較とか。まあ開発者がやらんでもユーザが実験すればいんだけど。
    ところで出来上がった動画ファイルはバイナリレベルで一致するんだろか?どこか手抜きして速くなったーとかじゃないよね
    • Re:色んな対決が見たい (スコア:3, すばらしい洞察)

      by yosuke2 (30603) on 2010年07月28日 20時46分 (#1801523) ホームページ

      >ところで出来上がった動画ファイルはバイナリレベルで一致するんだろか?

      誤差の2乗和とかで品質の優劣を判断するならともかく、
      バイナリレベルの一致なんて何の意味があるの?

      親コメント
      • by Anonymous Coward on 2010年07月28日 21時50分 (#1801543)
        元のblogによれば、

        > A few weeks ago the decoder was complete enough to be bit-exact with libvpx

        ということで、libvpx (Googleオリジナルのデコーダ)と
        ビットレベルで一致するところまで来たとあります。

        補足すると、VP8やH.264のデコードアルゴリズムは
        同一の圧縮済みストリームをデコードさせる限り、
        どんなデコーダでも全く同一の結果が得られる
        ように規格が設計されていて、リファレンスデコーダ
        (ここではlibvpx)のデコード結果と比較することで、
        デコーダの規格適合性を簡単に判定できるように
        なっています。

        ちなみに、MPEG-2 は、DCTの実数演算の丸め誤差の
        処理の方法に差が発生し得る規格なので、
        正しいデコーダ同士でもデコード結果が同一に
        なるとは限らず、そういう検証のしかたはできませんでした。
        親コメント
        • by Anonymous Coward
          ああ、なぜかタレコミが「エンコーダができた」という話になっちゃってたのね。
          すでに指摘がありますが、これは「デコーダができた」という話ですね。

          もちろん、エンコーダの場合は、同じ映像を入れてもエンコーダが違えば
          同一のストリームになるとは限りません。デコードされたときに、
          いかにきれいな画にデコードされるようなストリームを生成できるか
          というのがエンコーダの腕の見せ所なわけです。
          デコーダよりも実装が難しいですし計算量が大きいのが普通です。
  • by Anonymous Coward on 2010年07月28日 21時52分 (#1801544)
    こういう記事が話題になると言うことは、VP8 デコードは
    結構重いんじゃないかと感じさせてくれますけど、どう
    なのでしょうか?
    • むしろ軽いが為にHWデコーダが開発されなかったりしないかな。
      まあHWデコーダはvlcとかでは使われないんだろうけど。

      親コメント
      • by Anonymous Coward

        んなこたないでしょ。
        携帯デバイスではmp3ですらハードウェアでデコードされてるのに。

      • by Anonymous Coward
        Windowsの話になりますが、MPC-HC辺りはDXVAなハードウェアデコードをサポートしてますし、ffdshow-tryoutsのDXVAデコーダのようなフィルタも何種類か有りますからそっち経由でデコードさせれば問題なく使えるかと思います。

        HD動画とか考えるとGPUサポートは必須ですし、デコード回路もある程度は使いまわせるのでいずれは搭載されてくると思いたいですが・・・
        問題は、VP8のデコーダをGPUメーカが積む気になって、開発して、量産して、普及して、その後ようやく利用可能になるってことです。
        当分は難しいんじゃないでしょーか。
  • by Anonymous Coward on 2010年07月29日 2時22分 (#1801629)

    64ビットで恩恵があるソフトって嬉しいね。
    64ビット環境への移行のためにも、これからもっと増えていって欲しい。

typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...