10/06/23 00:54:21
欠陥コーデックだからやり直します、ってはっきり言えば良いのに
何この妙に前向きに解釈した提灯記事
7:名無しさん＠お腹いっぱい。
10/06/24 20:32:44
現状は
x264(ffdshow)>libvpx>wmp11標準のh264>win版chrome内臓のh264>win版quicktime
libvpxは書き下ろしたばかりなのでこれから高速化していく
アホはh264対vp8と勘違いしているけど、実はコーデックの性能競争
理論上はh264とvp8にほとんど差は無く、プログラマの腕勝負にかかってる
8:名無しさん＠お腹いっぱい。
10/06/24 20:36:05
今現在YouTubeはwebm->h264->flvの優先度で送ってくる
webmが在ればwebm、無ければh264、html5非対応のクソブラウザ向けはflv
買収からたったの5ヶ月でwenm配信を始めるGoogleの行動力はすごい
9:名無しさん＠お腹いっぱい。
10/06/24 21:02:37
>>7
試した範囲だと大差の最下位だよ＞libvpx
10:名無しさん＠お腹いっぱい。
10/06/24 22:51:10
特許を回避しながら動くアルゴリズムが一番低品質になるのは必然だけどね。
さあ、どうするつもりかな。
11:名無しさん＠お腹いっぱい。
10/06/25 01:36:38
VP系コーデックは生い立ちからして「代替品」ではある訳だけれど、
本流技術のH.264に対してそこそこの性能出れば桶ってスタンスじゃないかな
12:名無しさん＠お腹いっぱい。
10/06/25 02:34:45
YouTubeで試した限りではlibvpx>Chrome内臓h264
画質はh264より上だけどGoogleはaoTuVを知らないらしい
13:名無しさん＠お腹いっぱい。
10/06/25 03:15:25
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のほうが軽いくらい
試したのは例えば↓こんなの
URLﾘﾝｸ(www.youtube.com)
WebMはCPU使用率150%、H.264は50%前後＠アクティビティモニタ
ローカルに落としてVLC1.10で再生させるとかなり軽いがH.264にはまだ及ばない
また自分でffmpegでビットレート揃えてエンコしたテスト動画でも同様の結果だった
14:名無しさん＠お腹いっぱい。
10/06/25 04:37:42
>>13
なぜ同じChromeで比較しないの?
Safariでh264だと再生支援が効いてしまうから不公平過ぎるよ
どうだろうがユーザーに選択権は無いしね
WebMが送られてきたらWebMを再生するだけだよ
15:名無しさん＠お腹いっぱい。
10/06/25 04:42:23
AMDとNvidiaのドライバがvp8に対応すれば一気にvp8が普及する可能性もある
h264とvp8の優劣を徹底的に調べてくれるのはp2pら棲息するエンコ職人達だ
wmvはあっという間にh264に駆逐された、性能が全ての世界
専門家先生の分析よりも確実で嘘が無い
16:名無しさん＠お腹いっぱい。
10/06/25 05:42:45
>>14
一行目ちゃんと読もうよ
再生支援は効いてないんだってば。機種&OS的にね
効いてたらこの程度の差じゃ済まないよ
あくまでCPUによるソフトデコーダ同士の比較です
ChromeとChromium共に最新版入れてるから
ご承知の通りYoutubeで両方用意されてる場合はH.264ではテスト出来ない
だからH.264はSafariでしか試せないってだけのこと
そしてこれまたご承知の通りApple純正のH.264は
他の実装と比べて特に性能面で優れてはいないので不公平でもない
17:名無しさん＠お腹いっぱい。
10/06/25 06:49:17
>>16
ならばオマエは嘘つきだ
嘘つく前にググれよ
そんな大差の報告は無い
18:名無しさん＠お腹いっぱい。
10/06/25 06:52:48
反論したいならまずchromeでh264を再生してね
わざわざブラウザをょ変える時点でインチキがミエミエだよ
chromeはvp8もh264も再生できる
19:13
10/06/25 14:49:21
>>17
実際に試した結果だよ。自前の一次情報だから嘘つき呼ばわりは心外だ。
単に君が何らかの感情的な理由で認めたくないってだけの話だろ。
理由は容易に想像付くが。
>>18
だから、両方の形式が用意されてる動画で、且つ両対応のChrome6.xを入れてると
Youtube HTML5側の優先順位で自動的にWebMのページに飛ばされるんだってば。
強制的にH.264を選べる方法有るなら教えてくれ。
と言ってても仕方が無いんで
H.264のみ対応のChrome5.0.375.86に落として試してみた。動画は同じ奴。
結果はChrome RendererとChrome本体のプロセスの合計で90%くらい。
>>13の結果と比べると確かにSafari5より負荷高いが、やはりWebMよりは軽い。
ブラウズでは全体的にChromeは速い部類の体感だから予想外だった。
20:名無しさん＠お腹いっぱい。
10/06/26 06:52:23
>>15
ドライバの前に物理的なロジック回路の設計と実装が先だよ
その対応は来年以降と言われているから、
OSとアプリの対応に掛かる時間を含めて再生支援環境が整うのは
最短でも再来年以降だろうね
んでLinuxやAndroidなら比較的速やかに対応するだろうが、
WinやMacならMSやAppleがシステムレベルでVP8の再生支援対応を
追加してくれるかどうかはまだ全く不透明
21:名無しさん＠お腹いっぱい。
10/06/26 08:12:51
せっかく.H264の再生支援環境になったのにVP8が重いと困るな
22:名無しさん＠お腹いっぱい。
10/06/26 16:32:29
HTML5自体まだ草案段階だってのに気の早い話だ
23:名無しさん＠お腹いっぱい。
10/06/26 17:15:40
WebKitだけがHTML5だよ
24:名無しさん＠お腹いっぱい。
10/06/26 17:35:06
WebKitは糞
25:名無しさん＠お腹いっぱい。
10/06/26 21:15:16
WebKitは脆弱性のｶﾏﾀﾘ
26:名無しさん＠お腹いっぱい。
10/06/26 21:20:19
IEは不具合のカタマリ