【コーデック】グーグル、動画コーデック「VP8」の大幅改良への取り組みを早くも開始（10/06/21）

　Googleがオープンソースでロイヤリティフリーの動画圧縮技術「VP8」をリリースしてから1カ月が過ぎたが、同社は早くも
VP8の大幅な改良に取り組んでいる。

　VP8は、音声コーデック「Vorbis」との組み合わせで「WebM」というコーデックを構成している。GoogleはWebMにより、
競合する「H.264」コーデックにまとわりつく特許とロイヤリティのしがらみからウェブ動画を解放しようとしている。WebMの
競争力を高めるために、同社はVP8のエンコード／デコードを高速化する方法だけではなく、フォーマットそのものに
対するさらに根本的な改良にも取り組み始めている。

　この実験的な取り組みは、ビットストリームにも影響を及ぼす。ビットストリームというのは、ビデオストリームを表す
符号化情報の並びそのものだ。したがって、その設計を変更すれば、実験用フォーマットを表示できるよう特別に
設定された互換性のあるデコーダでない限り、読み込んだ情報を復号できず、動画の再生は不可能となる。

　ソフトウェアデコーダは比較的簡単にアップデートできるが、VP8は、ハードウェアのサポートによってフレームレート
や解像度といった動画の性能特性を向上させ、消費電力を削減するということも明言している。だが、ハードウェアは
ソフトウェアよりも変更に時間がかかる。

　「多くのハードウェアベンダーは、現行のビットストリームに基づくVP8対応製品を2011年に出荷することになっている。
動画のハードウェアアクセラレーションを採用している機器がウェブトラフィックに占める割合は、今のところごくわずか
だが、こうした機器は市場シェアを急速に伸ばしており、われわれのプロジェクトはこうしたベンダーのニーズに留意する
必要がある」とBankoski氏は述べている。

　だが、Googleとその協力企業は、競争にも注意を払う必要がある。VP8は、H.264との競争で品質の問題に直面している。
ウェブビデオストリーミング用としてだけでなく、何よりも動画を録画するカメラへの組み込みでH.264と互角に戦おうとする
なら、この点は特に大きな問題だ。

http://japan.cnet.com/news/service/story/0,3800104747,20415462,00.htm

取り敢えずブラウザに載せるソフトデコーダの改良を急いで進めないと駄目だな

どうせ普及した後に権利を主張するんだろ？

権利は現時点でも主張してるだろw

解き放つといいながら囲い込むんですねｗ

欠陥コーデックだからやり直します、ってはっきり言えば良いのに
何この妙に前向きに解釈した提灯記事

現状は
x264(ffdshow)>libvpx>wmp11標準のh264>win版chrome内臓のh264>win版quicktime
libvpxは書き下ろしたばかりなのでこれから高速化していく
アホはh264対vp8と勘違いしているけど、実はコーデックの性能競争
理論上はh264とvp8にほとんど差は無く、プログラマの腕勝負にかかってる

今現在YouTubeはwebm->h264->flvの優先度で送ってくる
webmが在ればwebm、無ければh264、html5非対応のクソブラウザ向けはflv
買収からたったの5ヶ月でwenm配信を始めるGoogleの行動力はすごい

>>7
試した範囲だと大差の最下位だよ＞libvpx

特許を回避しながら動くアルゴリズムが一番低品質になるのは必然だけどね。
さあ、どうするつもりかな。

VP系コーデックは生い立ちからして「代替品」ではある訳だけれど、
本流技術のH.264に対してそこそこの性能出れば桶ってスタンスじゃないかな

YouTubeで試した限りではlibvpx>Chrome内臓h264
画質はh264より上だけどGoogleはaoTuVを知らないらしい

OSX10.5.8＠C2D 2GHz、再生支援無しのiMac Mid2007だと

YoutubeのWebMはどれも同一解像度(720p)でH.264よりかなり重い

WebMはMozilla DP 3.7a5, Chromium6.0.415.0 (48127)
（両者共に内蔵のffmpeg経由でlibvpxを使ってるっぽい）
H.264はSafari5.0でQuickTime経由(AppleのH.264デコーダ）
(ちなみにOSX10.6.4+Safari5だと更に軽い)

比較すると最大で2-3倍近いCPU使用率の差が付いてる
WebMの720pよりH.264の1080pのほうが軽いくらい
試したのは例えば↓こんなの
ttp://www.youtube.com/watch?v=XnKqupdYE20
WebMはCPU使用率150%、H.264は50%前後＠アクティビティモニタ

ローカルに落としてVLC1.10で再生させるとかなり軽いがH.264にはまだ及ばない
また自分でffmpegでビットレート揃えてエンコしたテスト動画でも同様の結果だった

>>13
なぜ同じChromeで比較しないの?
Safariでh264だと再生支援が効いてしまうから不公平過ぎるよ
どうだろうがユーザーに選択権は無いしね
WebMが送られてきたらWebMを再生するだけだよ

AMDとNvidiaのドライバがvp8に対応すれば一気にvp8が普及する可能性もある
h264とvp8の優劣を徹底的に調べてくれるのはp2pら棲息するエンコ職人達だ
wmvはあっという間にh264に駆逐された、性能が全ての世界
専門家先生の分析よりも確実で嘘が無い

>>14
一行目ちゃんと読もうよ
再生支援は効いてないんだってば。機種&OS的にね
効いてたらこの程度の差じゃ済まないよ
あくまでCPUによるソフトデコーダ同士の比較です

ChromeとChromium共に最新版入れてるから
ご承知の通りYoutubeで両方用意されてる場合はH.264ではテスト出来ない
だからH.264はSafariでしか試せないってだけのこと
そしてこれまたご承知の通りApple純正のH.264は
他の実装と比べて特に性能面で優れてはいないので不公平でもない

>>16
ならばオマエは嘘つきだ
嘘つく前にググれよ
そんな大差の報告は無い

反論したいならまずchromeでh264を再生してね
わざわざブラウザをょ変える時点でインチキがミエミエだよ
chromeはvp8もh264も再生できる

>>17
実際に試した結果だよ。自前の一次情報だから嘘つき呼ばわりは心外だ。
単に君が何らかの感情的な理由で認めたくないってだけの話だろ。
理由は容易に想像付くが。

>>18
だから、両方の形式が用意されてる動画で、且つ両対応のChrome6.xを入れてると
Youtube HTML5側の優先順位で自動的にWebMのページに飛ばされるんだってば。
強制的にH.264を選べる方法有るなら教えてくれ。

と言ってても仕方が無いんで
H.264のみ対応のChrome5.0.375.86に落として試してみた。動画は同じ奴。

結果はChrome RendererとChrome本体のプロセスの合計で90%くらい。
>>13の結果と比べると確かにSafari5より負荷高いが、やはりWebMよりは軽い。
ブラウズでは全体的にChromeは速い部類の体感だから予想外だった。

>>15
ドライバの前に物理的なロジック回路の設計と実装が先だよ
その対応は来年以降と言われているから、
OSとアプリの対応に掛かる時間を含めて再生支援環境が整うのは
最短でも再来年以降だろうね

んでLinuxやAndroidなら比較的速やかに対応するだろうが、
WinやMacならMSやAppleがシステムレベルでVP8の再生支援対応を
追加してくれるかどうかはまだ全く不透明

せっかく.H264の再生支援環境になったのにVP8が重いと困るな

HTML5自体まだ草案段階だってのに気の早い話だ

WebKitだけがHTML5だよ

WebKitは糞

WebKitは脆弱性のｶﾏﾀﾘ

IEは不具合のカタマリ

止められないこの胸の高鳴り