X
【Youtube】WebM・WebPを見守るスレ【Chrome】
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
垢版 |
2010/10/05(火) 05:54:08ID:R+5QJCFh
HTML5への採用を目指し開発が進むオープンな動画規格「WebM」と、
そこから派生してJPEGの後継を狙う静止画規格「WebP」ほか、
ChromeやらYoutubeやらHTML5の対応状況などの周辺事情などについて見守るスレです。

WebM本家
http://www.webmproject.org/
WebP本家
http://code.google.com/intl/ja/speed/webp/
0056名無しさん＠お腹いっぱい。
垢版 |
2011/03/10(木) 12:13:24.62ID:oAMJ78Et
グーグル、動画コーデック「VP8」の新版「Bali」を発表--次期版の計画も明らかに
ttp://japan.cnet.com/news/service/35000325/
やっとこ出た
エンコード速度が前バージョンにくらえて1.35倍速いそうだ

次バージョンはQ2の後半だってさ
0058名無しさん＠お腹いっぱい。
垢版 |
2011/03/21(月) 19:38:53.78ID:D+gXBRAM
ffmpegでVP8のconstant qualityをやるにはどうすればいいんだろう
best やgoodの指定の仕方も変わっちゃって以前のやりかたじゃエラー出るし
よくわからん
0059名無しさん＠お腹いっぱい。
垢版 |
2011/04/01(金) 22:50:39.29ID:1pjsTvFV
x264、WebM、Theora比較検証
http://webscaws.x10.mx/?p=100

SSIMとエンコ時間を見る限り、
x265のベースラインプロファイルと画質＆エンコ速度でほぼ互角レベル。
WebMのほうが指定ビットレート厳守な傾向

さすがにTheoraは圧倒してるが、x264のメインプロファイル、ハイプロファイル
には全然叶わないね

0060名無しさん＠お腹いっぱい。
垢版 |
2011/04/02(土) 09:01:49.67ID:wWN8o8QG
>>59
いや、x264と同じ品質（SSIM）で見たとき、エンコード時間が段違いなんだが？
というより横軸の取り方が酷すぎるだろｗｗｗ

x264 BL vs vpxenc の 1 pass 比較のグラフの１メモリが +43.2, +136.8, +432.5, +15367.5 ってどうよ。

WebMの一番エンコ速度が速い結果とSSIMが近い x264 BL エンコ速度の差が 100 秒近いんだけど。
WebMの一番品質が良い結果とSSIMが近い x264 BL エンコ速度の差が 10 分程度なんだけど。
0061名無しさん＠お腹いっぱい。
垢版 |
2011/04/02(土) 09:06:18.57ID:wWN8o8QG
ミス。
x264 BL vs vpxenc の 1 pass 比較のグラフの１メモリが +15.6, +27.6, +49.3, +87.5, +155.7, +276.8, +492.2, +875.3 ってどうよ。
0062名無しさん＠お腹いっぱい。
垢版 |
2011/04/02(土) 11:18:18.72ID:tkOxJ2gr
どうもこうも、横軸が対数なだけでしょ？
目盛の数字をどこに置こうが、そんなの本質じゃないし。

いずれにしろ、
「当面、WebMはx264のベースラインプロファイルとの戦い」
「WebMはまだまだだね」
という結論は動かないでしょ

まだ伸び代はありそうだが、
Googleがこれをメインに使うだけのクォリティにはまだ達してない。
0063名無しさん＠お腹いっぱい。
垢版 |
2011/04/02(土) 18:26:47.53ID:wWN8o8QG
対数でグラフ化してるから「エンコ速度は互角」なんて見えるわけで。
他に適切な見せ方があるとは思えないが。

WebMはストリーム配信向けの高速モードが無いのがWEB専用コーデックとしては致命的だよなぁ
0064名無しさん＠お腹いっぱい。
垢版 |
2011/04/02(土) 20:39:54.40ID:tkOxJ2gr
>対数でグラフ化してるから「エンコ速度は互角」なんて見えるわけで。

対数グラフにしたところでエンコ速度が互角な事実は動かないわけで。
縦軸対数じゃなくて横軸対数だぞ？

ストリーム配信向けの高速モードって、reamtimeモードでしょ？
普通にあるが。
0065名無しさん＠お腹いっぱい。
垢版 |
2011/04/03(日) 00:06:49.01ID:CBLhKFMG
WebMの一番エンコ速度が速い結果とSSIMが近い x264 BL エンコ速度の差が 100 秒近いんだけど。
WebMの一番品質が良い結果とSSIMが近い x264 BL エンコ速度の差が 10 分程度なんだけど。
0066名無しさん＠お腹いっぱい。
垢版 |
2011/04/04(月) 00:38:32.84ID:hqod+uBF
というか元々VP8はエンコード負荷が高い／より時間が掛かる技術でしょ
（エンコードは重くてもいいからその分デコードはより軽くという設計思想）
0067名無しさん＠お腹いっぱい。
垢版 |
2011/04/04(月) 01:42:18.47ID:OY1mLSCv
VP8とH.264 BLで前者が特別デコード負荷が軽いとは思えないんだが。
そこそこ高速化された現時点でもまだ自分の環境だとH.264 BLの方がソフトウェアでのデコード負荷は軽い。
0071名無しさん＠お腹いっぱい。
垢版 |
2011/04/20(水) 09:51:30.58ID:8YahKeSL
その閉じたサービスがGoogleの画像検索であったりしたら
それで十分なんだけどｗ

既にChrome、Firefox、Operaが対応してんだから
0076名無しさん＠お腹いっぱい。
垢版 |
2011/04/21(木) 08:47:50.19ID:hGIeilQY
HTML5上でもどっち使うか
手動で切り替えられるようにしてほしいな
HTML5はそもそも誰も使わないモードだから力入ってないんだろうが
0077名無しさん＠お腹いっぱい。
垢版 |
2011/04/21(木) 08:51:45.97ID:wqsaGJLp
HTML5モードにして、検索条件の「WebM」をチェックして
適当な動画を再生してみたけど、1080Pのものがないねぇ
画質はH264よりちょっと落ちるかなというくらいだな
0078名無しさん＠お腹いっぱい。
垢版 |
2011/04/21(木) 09:09:12.50ID:hGIeilQY
1080pは今のところH.264にしか対応してない
chromeとかだとそこまで行くとH.264に自動的に切り替わる
まだWebMじゃ低負荷再生できないってことなんだろう
0079名無しさん＠お腹いっぱい。
垢版 |
2011/04/21(木) 14:05:34.51ID:ZkeV6tVs
WebMだとハードウェア支援してくれるグラボやチップセットが存在してないからなぁ。

YouTubeだとH.264動画の多くがBaselineプロファイルだから画質はあまり変わらないね。
ニコニコ動画だと逆に動画の多くがHighプロファイルだからWebMに移行したら画質がだいぶ落ちる。

>>76
YouTubeに限ればGoogleにとってWebMが再生できる環境でH.264動画を見せてやる義理はない。
0081名無しさん＠お腹いっぱい。
垢版 |
2011/04/21(木) 21:02:32.98ID:5kK90oa9
>>80
つ スマートフォン
まあ、YoutubeはH.264をサポートし続けるというし、通常は
ブラウザからではなくYoutube専用アプリでのアクセスなので
HTML5がどうなろうが実はあんまり関係なかったりするけど。
0083名無しさん＠お腹いっぱい。
垢版 |
2011/04/23(土) 06:51:56.95ID:murv/Gzw
H.264でもVP8でもどっちでもいいから、少なくとも低解像度（360p/480p）においては60p/50pサポートしてくれたらなあ…
正直ネット動画で1080pとかそれ以上の解像度の動画なんて要らない
0086名無しさん＠お腹いっぱい。
垢版 |
2011/04/23(土) 16:42:54.98ID:WmZlL6RW
WebMはちょっと試せないけどH.264なら、実際にIE9上で
HTML5の<video>タグで720p 60fpsの動画が再生できてるけど？
0088名無しさん＠お腹いっぱい。
垢版 |
2011/04/23(土) 17:35:58.80ID:WmZlL6RW
あれ？　YouTube限定の話だったのか。
自鯖で試したら普通に行けたからH.264でもWebMでも別にfps制限なんてHTML5で規定されてないよね？って思ってしまった。

ごめん
0089名無しさん＠お腹いっぱい。
垢版 |
2011/04/24(日) 00:19:23.83ID:twOeND1S
しかし>>73の発表って一体何のつもりなのか意味が分からん
基本的にはどれも去年5月の登場時点で言ってたことばかりで今更感全開

「youtube新規投稿分全てのwebMでの公開」も去年の時点で約束しておきながら
実際は全然実行出来てなかったのは周知の事実だから
これからは反省して真面目にやりますよと言う意味での再表明か？
0091名無しさん＠お腹いっぱい。
垢版 |
2011/04/24(日) 18:48:03.80ID:nddNV70m
エンコーダーが遅すぎて間に合ってなかっただけじゃないの？
Baliになってずいぶん高速化されたから、それでやっとめどがついた、
とかそんなとこと予想
0092名無しさん＠お腹いっぱい。
垢版 |
2011/04/24(日) 19:10:57.37ID:VUSFLe0J
まあ海外のフォーラムでも2chのDTV板でも自分でエンコしてもこの品質出せない
設定どうなってんのとか言われてたから
エンコ時間は半端なかったんだろうな
0093名無しさん＠お腹いっぱい。
垢版 |
2011/04/24(日) 21:31:19.37ID:nddNV70m
WebMはVorbisだから音がいいのかと思いきや、なんかCBRだねこれ。
せっかくVorbisなのに損してるなぁ
0095名無しさん＠お腹いっぱい。
垢版 |
2011/04/26(火) 09:03:16.18ID:RXk9slgN
グーグル、WebM関連特許を共有するイニシアチブを発表--16の組織が参加
ttp://japan.cnet.com/news/business/35002148/
Googleは米国時間4月25日、「WebM Community Cross License」イニシアチブと
いうプログラムを発表した。無償で利用可能なウェブ用ビデオ技術にのしかかる
特許関連の脅威を取り除くことを目的とする。

このプログラムに参加する企業は、「WebM」関連の任意の特許を互いにライセン
スすることで合意する。同技術が実際にロイヤルティフリーであり、またGoogle
もそれを強く希望していることを相互に再確認するための動きである。

Googleはこれまでに、16の組織と同プログラムに関する契約を交わしている。
その中には、ブラウザメーカーであるMozillaやOpera Softwareなど、参加が自明
な組織もある一方で、サムスンやLG Electronicsなど、WebMと競合する最大のビ
デオエンコーディング技術である「H.264」と関連するため、商業的利益を生み出
すことができるとみなされるビデオ関連特許を保有する企業もある。
0097名無しさん＠お腹いっぱい。
垢版 |
2011/04/26(火) 16:02:10.25ID:re7+1OMS
Webの世界がRFであるべきという主張には共感するが
動画に対してもその単純なルールを押し付けて適用することの是非は
全く別物だと思うんだがなー
0104名無しさん＠お腹いっぱい。
垢版 |
2011/05/09(月) 09:48:02.71ID:hItiHIok
vpxencで2パスエンコしてVLCで再生したらVP7よりましな物が出来るようになった…
まさか腐ってたのがGoogleのDirectshowフィルタでのデコードの方だったとは…
低ビットレートVP8マンセー
0109名無しさん＠お腹いっぱい。
垢版 |
2011/05/11(水) 09:41:42.89ID:NygMOWgl
VP9はまだ？
0112名無しさん＠お腹いっぱい。
垢版 |
2011/05/11(水) 16:38:39.11ID:j+jML2I0
バイトパフォーマンスならJPEG2000がダンチ。
全体的なバランスならJPEG XRがかなり優秀。

WebPはいろいろと残念すぎる。
バイトパフォーマンスならJ2Kにボロ負けだし、
回路規模あたりのパフォーマンスはJXRの足元にも及ばない。
0114名無しさん＠お腹いっぱい。
垢版 |
2011/05/22(日) 05:32:42.52ID:MNQKWn+b
WebP
上のOperaの例のような閉鎖系のサービス内限定の利用でなら比較的に採用し易いけど
オープンなWebのほうに普及させるのは容易ではないと思う

Jpegが余りに広く深く浸透し過ぎているし、
動画と違って静止画では画質面で不満を持ってる人もそう多くはないから
0115名無しさん＠お腹いっぱい。
垢版 |
2011/05/22(日) 08:56:37.57ID:ix3qpGp8
>>113
http://www.gazo.cc/up/38762.png

その画像を元に JPEG, J2K, JXR, WebP で比較してみた。
個人的に画質がマシだと感じる順は Jpeg XR > Jpeg 2000 > WebP > Jpeg か。

WebPはパッと見は綺麗に見えるけどブロックノイズが出てるから低解像度に見える。
0119名無しさん＠お腹いっぱい。
垢版 |
2011/05/24(火) 00:42:16.57ID:lsHZuoyQ
http://www.itmedia.co.jp/news/articles/1105/23/news019.html
>Googleが、Web画像の読み込み高速化を目指すオープンソースのフォーマット「WebP」のアルゴリズムを改良した。
>また、Chrome、Opera、Gmail、Picasa Web AlbumsでWebP画像の表示が可能になった。
>2011年05月23日 07時52分 更新
>
>　米Googleは5月20日（現地時間）、オープンソースのWeb向け画像フォーマット「WebP（ウェッピーと読む）」の改良と、
0121名無しさん＠お腹いっぱい。
垢版 |
2011/05/24(火) 10:38:50.38ID:B5UDrhRL
自分の動画がVP8でエンコされてた
思ったより全然綺麗だった
0125名無しさん＠お腹いっぱい。
垢版 |
2011/05/25(水) 18:32:24.30ID:ObdkwLMp
αチャンネルは可逆圧縮してくれるのだろうか？
αチャンネルもVP8で非可逆圧縮するとは考えにくいけど…ZIP圧縮かな？
0128名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 12:54:36.10ID:R2D4IM4Y
Firefox、Google提案画像フォーマット「WebP」のサポートは消極的
ttp://journal.mycom.co.jp/news/2011/05/27/023/index.html
Googleの提案している新しい画像フォーマット「WebP」はChromeがサポートし
ているほか、Operaも対応している。どちらもWebPの圧縮率の高さに魅力を感じ、
閲覧のみならずサービスの中でもWebPを活用するなど積極的な姿勢を見せている。

一方Mozillaは、FirefoxにおけるWebPのサポートに否定的な姿勢を見せている。
0129名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 14:19:26.62ID:84Dvsoi0
JPEG XRがVista以降のOSで標準サポートされているのにもかかわらず
全く普及していないことを考えると、たとえFirefoxがサポートしたところで
WebPなんて…
0130名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 15:04:05.24ID:R2D4IM4Y
いや、JPEG XRが普及しないのは、キラーが無いからだよ。
使う必要性が皆無なんだ

ところがGoogleは、Google検索、Google画像検索を有してる。
そのシェアと使用頻度は圧倒的だ。
しかも既にChrome、Operaは対応済み
他ブラウザだってGoogleがプラグイン出せば済む話だ(WebMはプラグイン出してる）

重要なのは、Google側がWebPをGoogle検索やGoogle画像検索に使うことで
帯域削減という実益があることだ。

普及するしないはもはやどうでもいいんだよ
使用頻度の高いキラー用途を既に有してるいじょう、提案し、実装し、実益をえる。
それだけの話だ。
他サイトが使うかどうかはどうでもいいんだよ

これはWebMも同じこと。
キラー用途であるYourubeを有してるいじょう、Googleが実益を得てGoogleだけ
でも継続使用されるだろう
0131名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 15:05:55.74ID:R2D4IM4Y
それとスマフォの台頭が後押しする

スマフォでは3G回線を使った場合、パケット量で課金される。
帯域も限られているし、スマフォ側のメモリ容量も制限がある。

そんななかでは、同じ画質ならより小さくできる高圧縮フォーマットは需要がある。
0134名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 19:28:38.10ID:BXKmwhSH
帯域削減とスマホでの利用ならパフォーマンス・バランスの良いJPEG XRでしょ
WebPと違ってちゃんと標準化団体によって規格化されているからWWWの精神にもあう。
0135名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 19:33:18.09ID:BXKmwhSH
というか「ICCカラープロファイル未対応」って広色域モニタが普及しだした昨今では致命的じゃね？
今の最新ブラウザは基本的にカラーマッチングに対応しているのに逆走もいいところ。

JPEGもJ2KもJXRもPNGも当然のように対応しているのに……
0136名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 20:22:25.96ID:OVegLtkg
>>128のニュースは正直意外だったな
モジラはグーグルから多額の資金援助を受けていて、実質べったりのずぶずぶだと思ってたから
0137名無しさん＠お腹いっぱい。
垢版 |
2011/05/27(金) 20:52:41.88ID:OVegLtkg
>>130
そう単純でもないだろう
まず主要ブラウザ／モバイルや情報家電などの各種デバイスの大半が
WebPに正式対応しない限りは一本化は無理でJPEGとの両対応になるし、
Web上にアップされてる元画像のほぼ全てはjpgかpngだからそれらからの変換コスト
必要ストレージ容量増加のコスト、などなどコスト増の要因が有る

普及途上の段階では相応のコスト増を覚悟した上での推進政策でしょ
0140名無しさん＠お腹いっぱい。
垢版 |
2011/05/28(土) 02:58:33.13ID:g7xl4+s7
>>130
動画のトラフィックは膨大だから、将来的なライセンスフィーが問題になりうる
H.264への対抗としてWebMは重要だけど、Googleの画像検索でのトラフィック
なんて気にする必要あるのかいなって感じだけどなぁ。

しかも、WebMはJPEG XRどころかJPEGよりも機能的に劣っている部分が多々
あるのだし。

規格策定プロセスがあまりにもクローズなのはWebM/WebPの大きな弱点だし、
これはAndroidなどにも共通して言えるんだよなぁ。こと規格策定に関しては
MSはもちろん、クローズの権化と言われつつあるAppleよりもさらに
クローズ。この辺どうにかならないもんか。
0142名無しさん＠お腹いっぱい。
垢版 |
2011/05/28(土) 12:19:40.47ID:/gnoinCp
>>137
いや、それはキミが問題を複雑化してるだけ。
Googleが狙ってるのはWeb標準や皆に使ってもらうことでは無い。

Googleが狙ってるのは、自社のネットサービスの低コスト化なんだよ。
Googleからしてみれば、WebPを表示できるブラウザを少しでも増やせればいいだけ。
増やせれば増やせるほど、Google検索やGoogle画像検索の消費帯域が下がり
コストが下がり、利益が上がる。

業界標準にしようだなんてことは本心では考えてない
他のWebサイトはJPG使ってりゃいいのよ。
そこがJPGでもGoogleの収益構造に影響しないしどうでもいいこと。

しかしGoogleがWebPを多用することで収益構造を改善でき始めたら
＝対応ブラウザが増えてきたら、
画像を多く扱う会社はWebP使い始めるところも出るだろうね。
帯域削減になるから。
0143名無しさん＠お腹いっぱい。
垢版 |
2011/05/28(土) 12:26:30.53ID:/gnoinCp
>>140
WebPとWebMは本質的に同じ。
WebMのIフレームがWebPだからね。
だからWebPの普及はWebMの普及にリンクしてる。

WebMにはH264という強敵がいて、今のところH264コンテンツを持ってる
ところがWebMに替える魅力はない。
しかしサイトのJPGをWebPに替えることに抵抗のある人は少ない。
画質を重視してJPGにしてるサイトは既に少なく、そこにWebPが入る隙がある。
省サイズが売りになるわけだ

すると問題になるのが対応ブラウザだが、
そこはGoogle検索、Google画像検索、Android、Chromeいう
シェアトップサービスに伸び盛りOS、伸び盛りブラウザのトライアングルで
WebPワールドを固めれば、自動的に対応ブラウザが増えることに繋がる
0145名無しさん＠お腹いっぱい。
垢版 |
2011/05/28(土) 16:19:55.21ID:um8P5E5I
>>142
>>137をもう一度読み直してくれ

サービスを二重化するのだからGoogleに相応のコスト負担が生じ
即コスト削減には繋がらない、というのが主旨なのだが

そして一元化しない限りその状況は続く
ググルは広告屋なのだからその広告を見る事の出来る機会を自ら減らしたりはしない
0147名無しさん＠お腹いっぱい。
垢版 |
2011/06/02(木) 08:11:27.95ID:5Crxktt+
普通に「ウェブエム」でしょう。ウェブピーが発音しにくいからウェッピーになっただけで
VP8は日本語と英語の交ぜ読みの「ブイピーはち」って呼んでしまうｗ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況