【Youtube】WebM・WebPを見守るスレ【Chrome】

HTML5への採用を目指し開発が進むオープンな動画規格「WebM」と、
そこから派生してJPEGの後継を狙う静止画規格「WebP」ほか、
ChromeやらYoutubeやらHTML5の対応状況などの周辺事情などについて見守るスレです。

WebM本家
http://www.webmproject.org/
WebP本家
http://code.google.com/intl/ja/speed/webp/

関連スレ
【WebM】VP8(VPx)総合スレ4【Google/On2】
http://hibari.2ch.net/test/read.cgi/avi/1274325583/
【Vorbis/FLAC】Ogg統合17【Theora/etc...】
http://hibari.2ch.net/test/read.cgi/software/1246816098/
JPEGの後継画像フォーマットについて議論するスレ
http://hibari.2ch.net/test/read.cgi/cg/1148854872/

その他いろいろな専門板にスレがあるのでそちらでもどうぞ。
WebMでエンコードするだとか専門的なのは得意な板でやるのが一番かと思われますが、
こちらではGoogleのWeb戦略など話題を選ばず使ってもらえばいいかなと。

とりあえずgoogleの日本社員が20%ルールでsusieプラグイン作れば多少は普及するんじゃね?

…っていうか、作ってください、お願いします

日本のデジカメメーカーが採用しない限りWebPは失敗規格だな。
てかJpeg XRだっけ？そんな感じの規格を押すべきだろって意見を前に見た。

静止画はMSのJPEG XRに統一すべきだろ。

http://hibari.2ch.net/test/read.cgi/avi/1274325583/688

>【参考】
>JPG　　メモリ：×１　回路：×１
>J2K　　メモリ：×９４　回路：×１５
>JXR　　メモリ：×１２　回路：×６

WebPはどうなんだ

推すならpngもお願いします

ffmpegでのWebMのエンコ、デコードは初期に比べたらかなり良くなった

>>6
何度も何度もガイシュツだけど、デジカメではJPEG圧縮よりもRAW現像・
NR・HDRといった画像処理のほうがはるかに処理が重くメモリも食うので、
いくらJPEG2000やJPEG XRがJPEGより重くても、ほとんど問題にならない。

それどころか、今はコンデジでH.264 1080/60i動画を撮れる時代なんだから。

H264で動画エンコするチップ搭載してるなら、
H264のIフレーム圧縮使った画像形式のほうが低コストで実装できるよな
しかも画質も圧縮率もjpegより上。

メーカーそろそろ気づけよｗ

色空間YUVが嫌いなんじゃない？

ならVP8も使わないだろう

JPEG2000かJPEG XRとPNGはそろそろデジカメに搭載して欲しいな。
ここはWebM・WebPスレだけどねｗ

>>4
MSの規格なんてサブマリン特許で後で泣くことになる

http://webp.googlecode.com/files/webp-samples.zip

>>12
流れ的にデジカメの話だろう
VP8使ってるデジカメがあるかよ

>>14
いちおう標準化を通ったからそう決めつけることもないと思うけどね。
XRで重複双直交変換を採用した理由は特許避けじゃないかという話もあるし。
(blog.livedoor.jp/abars/archives/50472037.html)
MSもさすがにVC-1の一件で懲りてるんじゃないかなww

むしろくすぶっているVP8の特許問題がWebPに関係してくるかが気になる。
だけどさ、もうJPEG2000もXRもWebPも全部実装してほしいよ主なブラウザは。
そしてみんな好きなのつかえばいいじゃんよもう。

>>16
WebPを搭載するってことはVP8（の一部）を搭載するのと同義だろう

YUVが嫌いだからH.264のキーフレームを使わないなら
VP8のキーフレームであるWebPだって使われないでしょ、っていう

それを言うならJPEGだって基本的にYUVなんだがｗ

JPEG XR早く普及してくれ

xvp8ってどうなったんだ？8月以来全くコミットされてないみたいだが

VP8コーデックSDK、初のメジャーリリース登場
ttp://journal.mycom.co.jp/news/2010/10/29/065/index.html
VP8コーデックSDKの初のメジャーリリースとなるVP8 Codec SDK "Aylesbury"が公開された

デコーダの高速化とエンコーダの改善の2つに注目して開発された。
デコードの速度が20%から40%、平均で28%高速化している。
またベストクォリティエンコーディングモードにおけるPSNRが7%以上向上、
静止画やゆっくりとしか動かないビデオ、
またはノイズをともなうビデオでは60%以上の改善が実現されている。

開発チームは今後四半期ごとに名前付きのメジャーリリースを実施
次のリリースは2011年第1四半期。SDK "Bali"。
開発テーマはエンコーダの高速化

PSNRだけ向上しても見た目が良くならなければ意味ないぞ
あとコードネームはAndroidのパクリか？ (頭文字がABC...と進んでいく)

同じ開発元なんだからポリシーであってパクリじゃない

スタートダッシュの5ヶ月でこれっぽちしか改善出来なかった割には
随分と景気の良い開発スケジュールだと思う

>>24
Googleよりもx264系面子による開発のほうがはるかに進んだというのも
面白いというかなんというか。にしても、バイナリフォーマット変わる
という話はどうなったんだ?

無いだろ。
変えたら組み込み向けには絶望になっちまうし。

それよりもGoogleは、Youtubeで新しいWebMの威力をまず実践してみせろと。

YoutubeのHtml5・WebM動画は5月スタートの時点で既に結構綺麗だったと思う
ローカルでは未だあのレベルでのエンコが出来ないから設定のポイントを公開して欲しい

三浦璃那

Google、ChromeブラウザでのH.264サポート終了へ
http://www.itmedia.co.jp/news/articles/1101/12/news034.html

「Google Chrome」におけるH.264サポート終了へ
http://internet.watch.impress.co.jp/docs/news/20110112_419750.html

デファクト・スタンダードを採用することが普及の要ってのに…

5〜6年前なら手放しで支持出来たんだけどねえ

Best設定でWebMエンコすると、H264と戦える画質出てると思うんだが
いかんせんエンコ遅いよな。
しかも、CPU全然使ってくれないし。

Phenom II X4 955でCPUがフル稼働しないどころか、3コアは殆ど遊んでる状態。
これじゃエンコスピード出るわけがない。

今年Q1に出るという新バージョンで、どんだけ改善するんだろうな。

つべのwebMもそこそこ綺麗だし、潜在能力自体はそこそこ有りそうな印象
後は実用面で言えばエンコとデコのコーデックの改良次第だね

でも今持ってるハードじゃ、永遠に再生支援は効かないんだよな…

再生不可はH264より軽いんじゃないかと思うけどなー

ブラッシュアップの圧倒的な差で現状ではwebMの方がまだ負荷高いよ

再生負荷はH.264のBaseline相当だから大半のニコ動や一部のつべ動画より大分軽い。
ただH.264は現行のGPUならほぼ100%再生支援が効くのが大きい。

古いPCだと再生支援が効かないがその場合もH.264 Baselineでエンコすれば画質も負荷も大差ないのがなぁ

ttp://japanese.engadget.com/2011/02/03/ms-chrome-h-264/

MSがWindows版Chrome用のExtensionの発表と
公開質問を出したらしい。
オラ何だかワクワクしてきた。

Firefoxと同じ手法ならHTMLVideoElementのプロパティやメソッドは使えないのかな

youtubeの代わりが出てきたらwebMはもちろんgoogleなんか消えてもらって結構

MSがVimeo買収とかか

まさかMSがChrome用にH.264 extensionを出すとは思わなかった

元々OSもブラウザも有る程度は拡張可能な仕組みを持ってる訳だから、
こうなるのは当然と言うか予想通りかな＞互いに相手用の拡張を出し合う展開

しかし来年正式策定になるHTML5 video、果たして成功するのかね？
権威所がお墨付きを与えた特定のコーデック／フォーマットを決めて従うより、
動画に関してだけはこれまで通りの自由競争の方が良いと思うんだけどな

別にブラウザのネイティブサポートでなく、従来通りのプラグイン方式で構わないし
そっちの方が変化に対して柔軟でしょ

問題は標準タグをプラグインで肩代わりすることだけどな。

しかも原理はHTMLのレンダリング前に横取りして<video>タグを
WMPプラグイン呼び出しに書き換えるなんて悪意のあるプログラムまがいの手法みたいだし。

ChromeなりFirefoxなりが未対応形式動画だった場合はプラグインに引き渡す、って形なら問題ないんだけど

>>38
※ただしWindowsに限る
って意味ねえ。
MicrosoftってH.264の特許を保持している会社の一つなんだよね。
そういうところが公開質問状出してもな

>>44
そういう事するとChrome Frameを非難できないよね。

>>45
ライセンスを持っている会社だからこそ公開質問状を出せるんだと思う。
なにせ H.264 を普及させる側の会社なんだから反撃ぐらいするさ。

かたや有償とはいえ標準化団体による標準化を終えている規格と
かたや無償とはいえ標準化も特許問題の可能性もクリアしていない規格があるなかで
普及の観点から見て劣勢側の当事者が多数派を追い出す決定をしたんだしね。

しかも相手はネット世界の帝国ときたらＭＳも無視できないでしょ。

ふだんWindowsしか使わないから頭が働かなかったが
たしかにlinux版やMac版も出してくれないと意味ないよな

だがな、LinuxやMacにはDirectShowもWMPもないんだ。

そもそもWindowsではIEでもFirefoxでもChromeでもH.264とWebM両方再生できますよって
セールスポイントなんだから他OSのサポートしても逆効果なだけだから。

別にH.264が普及してもライセンス料はMSが払う金額の方が多いわけだし、他OSまでサポートする旨みが無い。

でもgoogle非難する資格はないんじゃね

皮肉と公開質問状を出すことに資格云々は関係ないと思うんだけど

てか、なぜ自社 OS や自社ブラウザ以外での H.264 サポートを全てMSがしないと「非難の資格なし」になるのかが判らないんだが。
本来ならユーザーが選んでインストールした H.264、WebM を自社製品で使用可能、排除しないだけでよくね？

そして公開質問状も WebM と HTML5 の今後への Google の対応策についてであって H.264 とは直接関係ない。

MSがChrome用H.264プラグインをリリース、Googleへ公開質問も
ttp://japanese.engadget.com/2011/02/03/ms-chrome-h-264/

>>50
お前がバカなのは分かったよ

ブクマの反応も含めて面白いな

3月で2011年Q1は終わっちゃうわけだが・・・
Googleさん、速くバージョンアップしてよ

Google様がバーションアップしたらQ1が終わります。

Google暦の導入か

グーグル、動画コーデック「VP8」の新版「Bali」を発表--次期版の計画も明らかに
ttp://japan.cnet.com/news/service/35000325/
やっとこ出た
エンコード速度が前バージョンにくらえて1.35倍速いそうだ

次バージョンはQ2の後半だってさ

四半期毎なんて無理有るスケジュールは諦めれば良いのに

ffmpegでVP8のconstant qualityをやるにはどうすればいいんだろう
best やgoodの指定の仕方も変わっちゃって以前のやりかたじゃエラー出るし
よくわからん

x264、WebM、Theora比較検証
http://webscaws.x10.mx/?p=100

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

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

>>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 分程度なんだけど。

ミス。
x264 BL vs vpxenc の 1 pass 比較のグラフの１メモリが +15.6, +27.6, +49.3, +87.5, +155.7, +276.8, +492.2, +875.3 ってどうよ。

どうもこうも、横軸が対数なだけでしょ？
目盛の数字をどこに置こうが、そんなの本質じゃないし。

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

まだ伸び代はありそうだが、
Googleがこれをメインに使うだけのクォリティにはまだ達してない。

対数でグラフ化してるから「エンコ速度は互角」なんて見えるわけで。
他に適切な見せ方があるとは思えないが。

WebMはストリーム配信向けの高速モードが無いのがWEB専用コーデックとしては致命的だよなぁ

>対数でグラフ化してるから「エンコ速度は互角」なんて見えるわけで。

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

ストリーム配信向けの高速モードって、reamtimeモードでしょ？
普通にあるが。

WebMの一番エンコ速度が速い結果とSSIMが近い x264 BL エンコ速度の差が 100 秒近いんだけど。
WebMの一番品質が良い結果とSSIMが近い x264 BL エンコ速度の差が 10 分程度なんだけど。

というか元々VP8はエンコード負荷が高い／より時間が掛かる技術でしょ
（エンコードは重くてもいいからその分デコードはより軽くという設計思想）

VP8とH.264 BLで前者が特別デコード負荷が軽いとは思えないんだが。
そこそこ高速化された現時点でもまだ自分の環境だとH.264 BLの方がソフトウェアでのデコード負荷は軽い。

うん、確かにそこも大問題w

謳い文句の割には残念な出来

OperaがOpera TurboでWebPを使い始めた

かなり効果高いねこれ

そういう閉じたサービス限定で生き延びそうな予感

その閉じたサービスがGoogleの画像検索であったりしたら
それで十分なんだけどｗ

既にChrome、Firefox、Operaが対応してんだから

WebPはFirefox 6.0a1 (2011-04-19)の時点では対応されてないようだが

YouTube、全動画をWebM形式に変換すると発表
http://www.itmedia.co.jp/enterprise/articles/1104/20/news065.html

どうやってYoutubeからWebM動画を再生するの？
普通に見るとH264がDLされて再生されるよね

対応しているならHTML5モードでWebMが優先して再生される

HTML5上でもどっち使うか
手動で切り替えられるようにしてほしいな
HTML5はそもそも誰も使わないモードだから力入ってないんだろうが

HTML5モードにして、検索条件の「WebM」をチェックして
適当な動画を再生してみたけど、1080Pのものがないねぇ
画質はH264よりちょっと落ちるかなというくらいだな

1080pは今のところH.264にしか対応してない
chromeとかだとそこまで行くとH.264に自動的に切り替わる
まだWebMじゃ低負荷再生できないってことなんだろう

WebMだとハードウェア支援してくれるグラボやチップセットが存在してないからなぁ。

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

>>76
YouTubeに限ればGoogleにとってWebMが再生できる環境でH.264動画を見せてやる義理はない。

つべで動画再生しながら他のことやらんし
C2DでもCPUパワーが余ってるからWebMでいいや

>>80
つ スマートフォン
まあ、YoutubeはH.264をサポートし続けるというし、通常は
ブラウザからではなくYoutube専用アプリでのアクセスなので
HTML5がどうなろうが実はあんまり関係なかったりするけど。

720P程度の解像度でYoutubeのビットレート程度なら、
WebM再生のCPU負荷って問題ないレベルだわ

H.264でもVP8でもどっちでもいいから、少なくとも低解像度（360p/480p）においては60p/50pサポートしてくれたらなあ…
正直ネット動画で1080pとかそれ以上の解像度の動画なんて要らない

別に60fpsだろうが50fpsだろうが対応してるでしょ

してないよ

WebMはちょっと試せないけどH.264なら、実際にIE9上で
HTML5の<video>タグで720p 60fpsの動画が再生できてるけど？

気のせいでは？
youtubeの動画自体は必ず30fps固定でしょ

あれ？　YouTube限定の話だったのか。
自鯖で試したら普通に行けたからH.264でもWebMでも別にfps制限なんてHTML5で規定されてないよね？って思ってしまった。

ごめん

しかし>>73の発表って一体何のつもりなのか意味が分からん
基本的にはどれも去年5月の登場時点で言ってたことばかりで今更感全開

「youtube新規投稿分全てのwebMでの公開」も去年の時点で約束しておきながら
実際は全然実行出来てなかったのは周知の事実だから
これからは反省して真面目にやりますよと言う意味での再表明か？

こういう発表見るとgoogleって全然WebMにやる気ないんだなあと今更ながら思う

エンコーダーが遅すぎて間に合ってなかっただけじゃないの？
Baliになってずいぶん高速化されたから、それでやっとめどがついた、
とかそんなとこと予想

まあ海外のフォーラムでも2chのDTV板でも自分でエンコしてもこの品質出せない
設定どうなってんのとか言われてたから
エンコ時間は半端なかったんだろうな

WebMはVorbisだから音がいいのかと思いきや、なんかCBRだねこれ。
せっかくVorbisなのに損してるなぁ

VorbisでCBRとかねーよ・・・

グーグル、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」と関連するため、商業的利益を生み出
すことができるとみなされるビデオ関連特許を保有する企業もある。

つまり特許フリーではないことを認めたと？

Webの世界がRFであるべきという主張には共感するが
動画に対してもその単純なルールを押し付けて適用することの是非は
全く別物だと思うんだがなー

サムスン辺りは参加しないとAndroidを提供しないと脅しをかけられたと予想

iPhone・iPad関連でAppleと争訟中だからGoogleと仲良くしないとなｗ

>>97
つまるところvideoタグの標準化なんて無理だってことだ

swf以外ならなんでもいいよ、もう('A`)

WebM Video for Microsoft Internet Explorer 9 (Preview)
https://tools.google.com/dlpage/webmmf

「for IE9」だけどMedia Foundation APIで使えるようにコンポーネット登録するから
同APIを使用するソフト全般（WMPなど）でもWebMが再生可能になるようだ。

IE9上で“WebM”形式の動画を再生可能にするプラグイン「WebM for IE9」
OSのコンポーネントとして動作するため「WMP」などでもWebM動画を再生可能に
http://www.forest.impress.co.jp/docs/review/20110428_443025.html

vpxencで2パスエンコしてVLCで再生したらVP7よりましな物が出来るようになった…
まさか腐ってたのがGoogleのDirectshowフィルタでのデコードの方だったとは…
低ビットレートVP8マンセー

Googleのコードの品質は全体的に低めに感じる

Linux陣営の中ではわりと高めってイメージ
そりゃBSD系に比べたらアレだけども

オワコン

つべ専用コーデック

VP9はまだ？

OperaのOpera Turboが神過ぎる
WebPのクォリティ/容量 比は素晴らしいね

かなり古い形式であるJPEGよりはな
JPEG 2000やJPEG XRと比べるとどうなんだろう

バイトパフォーマンスならJPEG2000がダンチ。
全体的なバランスならJPEG XRがかなり優秀。

WebPはいろいろと残念すぎる。
バイトパフォーマンスならJ2Kにボロ負けだし、
回路規模あたりのパフォーマンスはJXRの足元にも及ばない。

http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:JPEG_JFIF_and_2000_Comparison.png
これを見るかぎりはJPEG 2000の方が画質がいいとは思えないな

WebP
上のOperaの例のような閉鎖系のサービス内限定の利用でなら比較的に採用し易いけど
オープンなWebのほうに普及させるのは容易ではないと思う

Jpegが余りに広く深く浸透し過ぎているし、
動画と違って静止画では画質面で不満を持ってる人もそう多くはないから

>>113
http://www.gazo.cc/up/38762.png

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

WebPはパッと見は綺麗に見えるけどブロックノイズが出てるから低解像度に見える。

CD以上の音質どころかMP3で満足する人がほとんど
画質もJPEGで十分

速いだけじゃちょっと弱い

既にウェッピーが使われてる有名サイトってある？

略すな

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（ウェッピーと読む）」の改良と、

嘘だッ！！

＿|￣|○　変な名前つけるなよ…

自分の動画がVP8でエンコされてた
思ったより全然綺麗だった

H.264 HP よりも？

WebPアルファチャンネル対応すんのか
おもしれー

>>123
VP8.1にも反映されるのかな

αチャンネルは可逆圧縮してくれるのだろうか？
αチャンネルもVP8で非可逆圧縮するとは考えにくいけど…ZIP圧縮かな？

jpeg=VHS
WebP=β

WebP=ブルーレイ

Firefox、Google提案画像フォーマット「WebP」のサポートは消極的
ttp://journal.mycom.co.jp/news/2011/05/27/023/index.html
Googleの提案している新しい画像フォーマット「WebP」はChromeがサポートし
ているほか、Operaも対応している。どちらもWebPの圧縮率の高さに魅力を感じ、
閲覧のみならずサービスの中でもWebPを活用するなど積極的な姿勢を見せている。

一方Mozillaは、FirefoxにおけるWebPのサポートに否定的な姿勢を見せている。

JPEG XRがVista以降のOSで標準サポートされているのにもかかわらず
全く普及していないことを考えると、たとえFirefoxがサポートしたところで
WebPなんて…

いや、JPEG XRが普及しないのは、キラーが無いからだよ。
使う必要性が皆無なんだ

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

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

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

これはWebMも同じこと。
キラー用途であるYourubeを有してるいじょう、Googleが実益を得てGoogleだけ
でも継続使用されるだろう

それとスマフォの台頭が後押しする

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

そんななかでは、同じ画質ならより小さくできる高圧縮フォーマットは需要がある。

Androidで利用者増やすしかないな

最低限JPEGと同等以上の画質にしてから普及させてくれよ。

帯域削減とスマホでの利用ならパフォーマンス・バランスの良いJPEG XRでしょ
WebPと違ってちゃんと標準化団体によって規格化されているからWWWの精神にもあう。

というか「ICCカラープロファイル未対応」って広色域モニタが普及しだした昨今では致命的じゃね？
今の最新ブラウザは基本的にカラーマッチングに対応しているのに逆走もいいところ。

JPEGもJ2KもJXRもPNGも当然のように対応しているのに……

>>128のニュースは正直意外だったな
モジラはグーグルから多額の資金援助を受けていて、実質べったりのずぶずぶだと思ってたから

>>130
そう単純でもないだろう
まず主要ブラウザ／モバイルや情報家電などの各種デバイスの大半が
WebPに正式対応しない限りは一本化は無理でJPEGとの両対応になるし、
Web上にアップされてる元画像のほぼ全てはjpgかpngだからそれらからの変換コスト
必要ストレージ容量増加のコスト、などなどコスト増の要因が有る

普及途上の段階では相応のコスト増を覚悟した上での推進政策でしょ

Chromeがある今、GoogleがMozillaに出資する意味ってあるの

mozilla「今後も金出すって確約すれば採用してやってもいいよ」

>>130
動画のトラフィックは膨大だから、将来的なライセンスフィーが問題になりうる
H.264への対抗としてWebMは重要だけど、Googleの画像検索でのトラフィック
なんて気にする必要あるのかいなって感じだけどなぁ。

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

規格策定プロセスがあまりにもクローズなのはWebM/WebPの大きな弱点だし、
これはAndroidなどにも共通して言えるんだよなぁ。こと規格策定に関しては
MSはもちろん、クローズの権化と言われつつあるAppleよりもさらに
クローズ。この辺どうにかならないもんか。

既に悪の帝国2.0と呼ばれている会社だからなぁ

>>137
いや、それはキミが問題を複雑化してるだけ。
Googleが狙ってるのはWeb標準や皆に使ってもらうことでは無い。

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

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

しかしGoogleがWebPを多用することで収益構造を改善でき始めたら
＝対応ブラウザが増えてきたら、
画像を多く扱う会社はWebP使い始めるところも出るだろうね。
帯域削減になるから。

>>140
WebPとWebMは本質的に同じ。
WebMのIフレームがWebPだからね。
だからWebPの普及はWebMの普及にリンクしてる。

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

すると問題になるのが対応ブラウザだが、
そこはGoogle検索、Google画像検索、Android、Chromeいう
シェアトップサービスに伸び盛りOS、伸び盛りブラウザのトライアングルで
WebPワールドを固めれば、自動的に対応ブラウザが増えることに繋がる

単に血迷って大枚はたいてOn2買ってしまった失敗をごまかそうと必死になってるだけのような

>>142
>>137をもう一度読み直してくれ

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

そして一元化しない限りその状況は続く
ググルは広告屋なのだからその広告を見る事の出来る機会を自ら減らしたりはしない

WebMは？ウェッムー？

普通に「ウェブエム」でしょう。ウェブピーが発音しにくいからウェッピーになっただけで
VP8は日本語と英語の交ぜ読みの「ブイピーはち」って呼んでしまうｗ

うぇぶまぞ

WebM→ウェブム

ウェベム

ウェッピーってヒッピーみたいだよな

Webおしっこ

test

HTML5とJavascrioptで実装するビデオチャット機能の
動画部分にVP8を使うそうじゃないか

そういえばSkypeは既にグループビデオ機能でVP8使ってたはずだけど
MS買収後はどうなるんだろ？

test

別にMSはVP8そのものに反対しているわけじゃないから別にそのままなんじゃね？
もしかしたらVC-1コーデックをLinuxやポータブル機にも移植するかもしれないがｗ

>>157
逆に言うと他所が勝手にやるのは構いませんよ、うちは邪魔しません（当然）
というスタンスでしかないからな

一応はH.264のライセンサーでもあるし、買い取ったSkypeの為だけに
自ら進んでググルの非係争条項を飲むとは思えないな

VP8 Codec SDK "Cayuga" Released
ttp://blog.webmproject.org/2011/08/vp8-codec-sdk-cayuga-released.html
前バージョンからは10〜20％のエンコスピードアップ

正直期待はずれ・・・

Skype、1対1のビデオ通話機能にビデオコーデックVP8を採用
http://journal.mycom.co.jp/news/2011/08/05/038/index.html

以前からグループチャットではVP8だったが
このたび1vs1もVP8になった

また、Youtubeの仕様変更で、アップした動画はWebM化されるようになったね

Skype、買収元のＭＳがWindows Phoneへ搭載するビデオコーデック開発者を募集してたけど
つまりは現時点でサポートしているVC-1（WMV9）やMPEG4 AVC/H.264ではなくVP8を載せるつもりなんだろうか。

Googleタンが勝手にCODEC改良してくれるからお得なのかもｗ

四半期ごとに、っていうリリーススケジュールは順当に遅れてるみたいだね
年3回出せれば御の字か

WMVとWebMだとどっちの方が低負荷で高画質なんだろうか

画質は迷うこと無く現時点でもWebMだろう

エンコ負荷も、WMVのエンコーダーがコア数制限あるのに比べれば
WebMのほうがマルチコアで有利やな

流石に登場時期が違いすぎるからな…
比較自体が酷

WebMの画質評価ってVC-1やH.264 Baselineレベルって話なかったっけ？

youtube動画をhtml5モードで見れば、WebMって言うかVP8の画質はわかる。
おれは画質に関しては不満はない

された
http://www.youtube.com/watch?v=B8vQZuX_rHI&sns=em
カワタツ

JPEG2000はどうなったん？

>>159
これ試してみたけど、品質Good以上なら結構イケてるほうじゃないかな

Youtubeも最近真面目にWebM化進んでるねぇ

WebPのsusieプラグインが出てたの知らなかった

WebPはとにかく早くICCカラープロファイルに対応してくれないかな
可逆圧縮なんてpngにまかせておけばいいし3Dなんて後回しでいい
ま、chromeにカラーマネジメントが実装されてないことを考えると優先度低そうだが……

http://www.slideshare.net/touradj_ebrahimi/rate-distortion-performance-of-vp8-webp-and-webm-when-compared-to-standard-image-and-video-compression-techniques

WebP, WebMと他のコーデックとの比較対照

>>175
ブラインドテストは珍しいね。興味深かった。

WebP、WebMって意外とやるじゃん

特に低ビットレートでのWebMはクォリティ高いな

WebP 0.1.3 RC

We posted a 0.1.3 release candidate to the downloads page [1]. Please
let us know if you find any regressions from 0.1.2 or new bugs.

From the NEWS file for v0.1.3:
* Advanced decoding APIs.
* On-the-fly cropping and rescaling of images.
* SSE2 instructions for decoding performance optimizations on x86
based platforms.
* Support Multi-threaded decoding.
* 40% improvement in Decoding performance.
* Add support for RGB565, RGBA4444 & ARGB image colorspace.
* Better handling of large picture encoding.

アルファチャンネル対応来たか

WebPに対応してるビデオカードってあんの？

画像１枚表示するのに対応も非対応もあるのか

すまんＰとＭ勘違いした

>>171
映画館では大活躍です

ロスレスは？

android ICS(4.0) で mkv サポートだってよ！！
http://developer.android.com/guide/appendix/media-formats.html

あと、やっと WebP サポート。

あたらしい画像フォーマットの主戦場はスマフォだとおもうが、どうだろう。

仕様が流行らん事には何とも

久しぶりにChromeでYoutubeをHTML5 Video有効で見てみたが
前より使える機能が増えてた

一応ちゃんとやってるのね

　

WebP-Mux (RIFF based container) framework
https://groups.google.com/a/webmproject.org/group/webp-discuss/browse_thread/thread/4ab76cbde89e6ade#

これでメタデータやカラープロファイル未対応の問題も前進かな？

WebPロスレスけっこう縮むおおおおおおおおおおおお

圧縮が結構ってレベルじゃなく遅いけど。

http://code.google.com/intl/ja/speed/webp/gallery.html

>>191
圧縮はまだ遅くてもいいけど、伸張が遅かったら使いものにならないな

よく読んでみたら圧縮時間を調節するオプションあったわ。常識的な圧縮時間でそこそこの縮み具合になったわ。

PNGよりコンパクトに：Google、画像フォーマット「WebP」に可逆圧縮と透明度を追加
http://www.itmedia.co.jp/news/articles/1111/21/news020.html

　米Googleは11月18日（現地時間）、オープンソースのWeb向け画像フォーマット「WebP（ウェッピーと読む）」に、
可逆圧縮（ロスレス圧縮）モードと透過度を設定できるアルファチャンネルを追加したと発表した。
＜中略＞
10月にはアニメーション、ICCプロファイル、XMPメタデータをサポートした。

>>185
VP8とVorbisのところにしかないからWebM(Matroskaコンテナ)の拡張子変えただけじゃね

アニメーションなんてあったんだ

>>195
はてなブックマーク見ると結構冷たい反応も多いね。
ブロードバンド大国日本の感覚だと必要性を感じないのはわかるんだが
他の国では必ずしもそうではないからなあ。
別にWebPでなければならないということもないが
いつまでも枯れ果てたJPEGを使い続けるというのもねえ…

モバイルではデータ量は少ない方が良いのにね

既にGoogleでWebP使いまくりですよ
検索画面でマウスオーバーするとリンク先サイトの縮小画像出るけど
あれ全部WebPだし
Googleはあれで相当帯域節約できてるはず

>>200
WEBPで保存してるけど、ブラウザに表示する際にはJPEGに変換されるから、
帯域は関係ないと思われ。

JPEGの置き換えって言われてたけどGIF・PNGの用途もカバーするな

JPEG XRとWebPは競合するの？

http://code.google.com/p/webp/downloads/detail?name=libwebp-experimental-linux-x86-64.tar.gz

使い方わからねえｵﾜﾀ

>>203
する
ただXRはHDRがあるからデジカメ向きでWebPはウェブでデータを削減するのに向いてる

JPEG XRは規格普及が下手くそな（もしくは嫌われている）MS発の技術らしく、普及の見込みが乏しい
また、エンコード・デコード速度や圧縮効率の改善といった実装の改良がないのが残念

WebPはグーグルが実装を日々改善しているのが魅力だけど
VP8のパテント紛争の結果次第ではオシャカになる可能性も否定できない

@echo off
for %%a in (z:\folder\*.jpg) do (
cwebp -q 80 %%a -o z:\save\%%~na.webp
)
拾い物だけどbatで保存してcwebpのところにおいてz:\〜を2つ置き換えて実行でいけると思う
80ほど変換したけどCaesiumデフォjpgから1/3くらいに減った
Windows Photo Viewerで表示はされるけど進むが押せないなwin7x64
後はブラウザが対応してくれれば言うことはないんだけど

おお、batよくわかんないからありがたい

-q 80 って部分が画質の指定やね。数字がでかいほど画質が良くなる。最大100。

品質マネジメントの革新

（↑）革新→核心

SSIM
Caesium 80 JPEG
アニメBMP 7627.55>485.26KB
RGB　97.491067%
YUV　97.838774%
風景BMP 2880.05>82.49KB
RGB　98.686127%
YUV　99.208449%

WebP 90
アニBMPメ 7627.55>489.68KB
RGB　99.118730%
YUV　99.022315%
風景BMP 2880.05>84.43KB
RGB　99.008507%
YUV　99.517995%

WebP 80
アニメBMP 7627.55>328.70KB
RGB　98.545852%
YUV　98.578536%
風景BMP 2880.05>49.83KB
RGB　98.335742%
YUV　99.215040%

0.98 以上オリジナルと区別がつかない。らしい
WebP 80なら優秀かな？
Firefoxのプラグインはmacはあるっぽいからwindows用もできんかな
画像サイトが対応しなきゃそんなに恩恵ないだろうけど

WebPって圧縮するときに色々オプション付けられるけど、こういうのって好みに近い気がするからなー。

圧縮時に-af オプションつけたり、-sns 100 オプションつけたりした画像ってみんなどういうふうに感じるんだろう

SSIM
WebP Q50 -sns 70 -f 50 -strong -af
アニメBMP 7627.55>221.21KB
RGB　97.726735%
YUV　97.815162%

WebP Q75 m6
288.54>282,70KB
WebP Q50 m6
221.21>220.74KB

PASSは意味なかった
-m6オプションは重いからデフォルトでいい気も
q50でも凝視・拡大しなければ使えなくもないのかな

フィルター類はどうなんだろサイズ減らしてる場合は使ったほうがいいのかな

グーグル、画像フォーマット「WebP」を改良--可逆圧縮とアルファチャンネルに対応
http://japan.cnet.com/news/service/35010971/

>GoogleはWebPを広く普及させようと意欲を見せている。だがMozillaは、
「『ウェブプラットフォームの一部』となるすべての画像フォーマットからは常にコストが発生する」
懸念があるとして、Googleより慎重な姿勢を示している。

それはそうかもしれないけどさ、だったら標準化されないことが決定している
APNGをなんで実装したのよ、ともいいたくなる件。

可逆も出来て、アニメーションも出来て、アルファチャンネルもサポートし、不可逆でも今までより縮み、赤も劣化しない。
普通に考えて最高やん。
少なくともjpeg gif pngはもう用済みなことに

縮むが圧縮にシャレにならないほど時間が掛かるし、展開も重めだからなぁ
というか、１形式に何でもかんでもつぎ込むとバグの温床だしサポートが大変すぎる。

赤が劣化しないっていうけどYUV4:4:4に対応したっけ？　＞WebP

それに軽量でバランスのよい可逆、α、高圧縮対応の JPEG XR がすでに標準化されているからなぁ。

JPEG XRやJPEG2000の可逆はPNGの代替にはならないよ。縮まなすぎる。

なんだ？器用貧乏なの？

元々可逆を重視してないフォーマットなだけよ

WebPはそこにめをつけて、可逆のメリットを強調してるんでしょう

>>215
> 縮むが圧縮にシャレにならないほど時間が掛かるし

>>194

デジカメ分野は早くJPEG XRに移行してほしい。

>>220　移行で一般ユーザが受けるメリットとデメリットって何だろうな

ああいう小型機器の場合、圧縮展開に必要なCPUパワーやメモリが
コストに見合うかどうか、不満のないスピードを実現できるかどうか
が問題なんだよね

とりあえずプロとかハイアマでもない人達がRAWを扱わなくて済むようになる。
逆に今までJPEGしか使って来なかった層でも加工の自由度が上がる。

今の低品質なJPGと、高機能すぎるRAWとの間を埋めるモノとして期待なんだよね。
JPEG 2000と比較して半分の回路規模、メモリ使用量も1/8だからハードルも低い。

あとJPEG2kの致命的な欠点が画像によって圧縮所要時間が無視できないほどバラつくことだったらしい。

ウェッムーってどこでみられるん？

http://www.youtube.com/html5

>>222
CPUなんか使うか？ハードでやるんじゃないの？

>>226　小型機器って言ってるからどっちもあるんじゃね

gitでcloneしたlibvpxのexampleにあるgen_example_code.shが使いものにならなすぎワロタ
自分でマージしたわ。

http://www.gstatic.com/webp/gallery/1.webp
http://www.gstatic.com/webp/gallery/2.webp
http://www.gstatic.com/webp/gallery/3.webp
http://www.gstatic.com/webp/gallery/4.webp
http://www.gstatic.com/webp/gallery/5.webp
専用ブラウザだと見れるのかちょっとテスト

webpに対応したSusie Plug-inがあれば可能では？

おお、専ブラで見れた。susieプラグイン便利。

しかし、>>229みたいな写真だとJPEGにたいする画質面での優位性はわかりにくいな。
拡大したり凝視すれば確かに良くなってるんだけど。

これがイラストとかだと等倍ではっきりわかるレベルで違うんだが。

気になったのでググってみました。
やっぱり先駆者はいるもんですね、SPIすぐに見つかりました。

しかし利点が無い。
jpgやgifやpngで十分じゃん、としか思えない。

WebMは定期的にアップデートするとか言ってたけど、
完全に停滞しちゃったな

>>234
たぶん、webpからバックポートする感じでwebmにも異様に綺麗なフレームを
生成するメソッドができたりするんじゃない?

WebMの課題はエンコスピードだからなぁ
画質は現時点でも結構イケてると思うよ

Flashなくなったらh264再生不可ブラウザばかりになるからどうにかしてもらいたいところではあるけど
Flashは次でマルチスレッドデコード対応するけどこれどうだったっけ・・・
ハードウェア再生支援も対応はないだろうし

まぁ、Flash撤退はモバイルだけの話だし
モバイルWEBブラウザのメインであるWebKit（iOS、Android）や
IE9（WP7.5）はH.264/AVCに対応しているから大して困らないよね。

YouTubeやニコ動、その他一般的な動画サイトは再生プレイヤーが有ったりするし

うｐろだどっとねっとか極一部のろだがWebPに対応してた

Janeとか画像ビューアならSusie入れて見られるが、やっぱりFirefoxで見られないと困るな

FirefoxはChromeの躍進に焦って、頻繁VerUpに変えてしまって自爆だね。
豊富な拡張がウリだったのに、VerUpのたびに殆ど使えなくなる
結局Chromeに抜かれてしまったし、衰退著しい

>>240　まぁたまには良いとこも見つけてやれよん
ttp://www.fastpic.jp/images/752/5245678685.png

スレ汚しすまん、こっちだった
ttp://miyahan.com/me/report/computer/070125_WUXGA_LCD/ColorManagement_test.html#Test_CMS

>>240
FFにしか無い拡張機能あるからGCに完全移行出来ない＿|￣|○

移行する必要は別にないだろｗ
シェアでChromeが勝ってるからChromeのほうが機能が多いかっていうとそんなことはない

ChromeはFirefoxと違って、速いし64bit対応だしマルチプロセス対応だけど
拡張で基幹部分までイジれる作りじゃないからなぁ

64bit対応してたっけ？今のgoogleはスパイウェア化してるからな・・・

>>244
プロセス数制限があるので、タブを30個以上開く人には使いものにならないしねい

>>245
してない

Chromeが速いっていうのもタブ数が少ない時限定だね
タブ数が10個超えてくると明らかにChromeは遅くなる
もともとGoogle自身がそう言ってる当前なんだけどね

”グーグル、ブラウザ「ファイアフォックス」の支援停止か” だってさ
http://www.j-cast.com/2011/12/05115282.html

WebPを実装しないことへの脅しも含まれてたりして

どう考えても“今の”MSよりも悪の帝国だよな

>>248
さすがにそこまで了見が狭いとは思わないwww

ただGoogleからすればChromeのシェアが広がれば広がるほど
Mozillaに対して強気に出られる面はあるだろうね。契約の価格交渉とかでも。

まあ、あからさまにMozillaに泥を引っ掛けるような真似をすれば
FLOSSに理解があります！的なアピールも真に受けてもらえなくなるだろうが。

Mozilla と Google との検索契約は、終わってはいなかった - インターネットコム
http://japan.internet.com/busnews/20111206/5.html

Firefoxネガキャン期間おわり

>>251
やっぱり独禁法なのね…
かつてのMSとappleみたい。

>>252
今もMSは独禁法を恐れてアップル支援してる側面があるね
やっぱり競争相手がいないとダレたり杭を打たれたりで良いことが無いな

h.264のCBPってのが出るみたいだが
それよりも使えるのかね？

いい加減、ハードウェアエンコードのチップとかが
出て欲しいわ。H.264の当て馬で終わってしまうのかね。

h.264のCBPってのが出るみたいだが
それよりも使えるのかね？

いい加減、ハードウェアエンコードのチップとかが
出て欲しいわ。H.264の当て馬で終わってしまうのかね。

最近画像をダウンロードしても見れなくておかしいと思ったら、拡張子が変わってたのね（オペラ）
マジ基地なんだけど・・・閲覧ソフトもねえし

>>256
operaturbo切ればいいだけじゃねーの？

>>257
産業で

切ってみた
普通にダウンロードされた
ありがとう　そして　すんませんでしたああああああああああああ

IrfanViewがWEBPの表示と保存に対応

WebMのエンコーダー更新が止まってんなぁ

ブログを見るかぎりハードウェアのエンコーダーやデコーダーの開発をやってるみたいね

しかしChromeのH.264サポ止めますアナウンスとは一体なんだったのか
最新版でつべのHTML5ページ開くと相変わらずサポートされたまんまなんだが

止める予定ってどんなスケジュールで予定されてんの？

そのスケジュール自体が全くもって不明なのだが、
もうそろそろで発表からはかれこれ一年近く経つから
ホントに止める気有るのか疑い始めてる

ウェッムーって言いづらい

>>251
むしろH.264に対してさえこの手の嫌がらせをしないgoogleがFirefoxを潰すわけはないと思ってたので
>>249
こういう印象を振りまくためのgoogleに対するネガキャンとしか思えなかった

国際標準化機構に嫌がらせをしないからといって、１企業であるMozillaに嫌がらせをしないとする根拠にはならん
GoogleはFirefoxに資金を支援しているけど、MPEG（ISO/IEC）とITU-Tに対しては利用以外の権利に関しては何もないぞ？

一時期firefoxのネガキャンひどかったけどすぐに収まるよな2chは荒れたままだが

Firefoxのメモリー馬鹿食い問題が解決して何よりだった。
そういう意味でも数ヶ月に1回メジャーバージョンアップを強いるのも悪くないかな、と思った1年。

ZiiLABS
http://www.ziilabs.com/products/processors/zms40.aspx
Wide range of accelerated video codecs including H.264, VC1 and VP8
Android 4.0 Tabletsらしいけど

http://webp.googlecode.com/files/WebpCodecSetup.exe

公式コーデックkt

来てない？

“WebP”形式の画像を表示するためのコーデック「WebP Codec for Windows」

WIC準拠の各種ソフトでWebP画像を表示可能に

＞ただし、現在のところ対応するのはデコードのみで、エンコードには対応
していない。そのため、WIC準拠ソフトでWebP画像を表示することはできるが
編集・保存・変換することはできない。将来的にはエンコードおよびメタデ
ータの取り扱いに対応する予定とのことなので期待したい。

http://www.forest.impress.co.jp/docs/review/20120119_505505.html

10/8のもの今更書いてどうすんだよ

それよりWebM進めろよGoogle

もうjpgとpngでいいよ…
動画はmp4でじゅうぶんだし

動画はH.264のほうが性能が上。ただし有料。
これはお金の問題なんだからじゅうぶんというのはおかしい。

>>276
いや全然よくないけど

Firefox、はやく対応しておくれ

いろんな所で明らかに圧縮しすぎなJPEG画像を見るたびに
せめてWEBPなら…といつも思う。

http://ja.wikipedia.org/wiki/WebP
IrfanView - Version 4.32からネイティブ対応し、読み書き共に可能になった。


プラグイン入れないと保存できないんだけど

ほっほー、ちょっと試してくるかな

日本語版まだか・・・

I beg your pardon ?

同じサイズでWebPや、jpeg jpeg2000,jpegXRなんかに圧縮して、
WebPが他に比べて明らかに画質で劣ってしまう画像ってどんなのだろう。

>>2
【JPEG/TIFF】新フォーマット【jpeg2000/WMP/WebP】
http://toro.2ch.net/test/read.cgi/dcamera/1287382410/

VP8 Codec SDK "Duclair" Released
http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released.html

なんか名前がどこぞの歯ブラシみたいだな

>>285
少なくともWebPがJPEGに劣るというケースはまず無いと思う

だからといってすんなり普及しそうにも無いのが難しいところ

動画と比べてWebの静止画に対する画質面での不満ってさほど無いし

WebPに対応したうｐろだって何で出てこないんだろうな
運営側からしたらトラフィック軽減するメリットでかいんじゃないの？

まだまだ知名度低過ぎだから…

cwebpのフロントエンドがほとんどないのも困りものだよね。
俺も携帯動画変換君を使っている状態だし。
XnConvertだと今度は最新のライブラリが使えないし。

今年末ぐらいまでにはFirefoxにも対応して欲しいなとおもうけど、
メンテナーは嫌がってるみたいだしなあ。

>>291
いやー、画像はローカルでいつでも見れて初めて普及と言えるでしょ

とりあえずサムネイル関連はさっさとJPEG卒業してくれ。

デジカメなんかのハードが対応してない機器で
普及が遅れるとかなら分かるんだけれども
PCなんてさっさと次世代フォーマット移行しちゃえば
いいと思うんだけどなぁ。
もう出揃ってから何年だ？

JPEG 2000が出てから10年以上たちました。
それよりも先にJPEG XRが普及しだしそうな雰囲気です。

少なくともWebPが普及するためにはJPEG2kよりもかなり高速で保存でき、
メモリ使用量がかなり小さく、回路規模もかなり小さくなる必要があるだろうね。

JPEG 2000は、JPEGの約94倍のメモリ領域、約15倍の回路規模で約２倍の圧縮効率。
JPEG XRは、JPEGの約11倍の計算処理、約６倍の回路規模で２倍近くの圧縮効率。

WebPはビデオコーデックであるVP8そのものだからJ2kよりも軽いとは考えにくいがJPEGとの比較ってある？

>>297
JPEG XRは明らかにデジカメ向きだし、その用途でもっと流行ってもいいだろうとは思うんだけどね。
まあ、それならDNGでもいいだろうけど。

>>298
体感ではJ2KよりWebPの方が軽いんだけどね。なんでだろう。

あと、枯れ果てたJPEGよりWebPの方が軽いということはないと思う。

あ、JPEGよりWebPの方が軽いとかそういうことではなくてJ2KやXRとの比較をしたかったのね。
体感では軽さでXR=WebP>J2Kいう印象だけど、数字での比較ってあるんだろうか。

JPEG 2000、JPEG XR、WebP、最重量はJPEG 2000

Comparison: WebP, JPEG and JPEG XR
http://goldfishforthought.blogspot.com/2010/10/comparison-webp-jpeg-and-jpeg-xr.html

>>302
ううむ。JPEG XRに対するネガキャンってぐらいにアレな結果だなぁ。
というか、マヂでこれネガキャンでそ。

というかJPEG XRだけHDRモードとか高速モードとかになってるんじゃね？ってカンジ

どれでもいいからブラウザ標準化して画像サイトに対応してくれりゃどっちもありがたいんだけどな

あっちはcssとhtml5の規格話でそれどころではない。

>>302の検証が妥当かはわからんけど、
実際JPEGXRって、いろいろ魅力的だけど圧縮性能的にはブロックノイズがでないJPEGって感じで
イマイチなんだよなー。

WEBPとか、あとx264でも試してみたけど、最近の画像圧縮って
>>302のグーグルロゴみたいな、いままでJPEGが苦手としてきたような画像の画質が大きく向上してるんだよなー
JPEGXRはそれに追いつけてない。

JPEGXRの圧縮能力が微妙なのは特許に抵触しないようにしたからって気がする

JpegXRの圧縮法は高速省メモリでJPEGを超えるように作ったからよ
デジカメなどのメモリ、処理能力、消費電力、サイズなどに制限のあるデバイスで威力を発揮する

カメラで撮影時にXRで保存して、
そこからWEB表示用にWEBP等に変換って使い方になるのが理想か？

JPEGXRの簡単な一括変換ツール無いかな

つXnConvert
WebPにも対応してるけどいじれるオプションが画質だけってのがな(´・ω・`)

>>312
ありがとー、早速使ってみるわ

SSIM
WebP 80
アニメBMP 7627.55>328.70KB
RGB　98.545852%
YUV　98.578536%
風景BMP 2880.05>49.83KB
RGB　98.335742%
YUV　99.215040%

JPEGXR 80
アニメBMP 7627.55>504.16KB
RGB　98.124720%
YUV　99.014925%
風景BMP 2880.05>59.3KB
RGB　97.982931%
YUV　99.218508%

Caesium 80 JPEG
アニメBMP 7627.55>485.26KB
RGB　97.491067%
YUV　97.838774%
風景BMP 2880.05>82.49KB
RGB　98.686127%
YUV　99.208449%

エンコード・デコードの処理の負荷の差とかありそうだしなんとも言えない

とりあえずエロ同人を70でWebP変換したらJPEGの3/4くらいになったわ

http://www.slideshare.net/FukushimaNorishige/webp

ここにJPEGとWebPのデコード時間の比較があった。（XRはなし）
JPEGの五割増しぐらいだと。

あと画質比較にPSNR使ってるのは残念。

pdf.jsはJPEG2000をJavaScriptの力技でデコードできるそうだが
WebPをデコードするJSライブラリとかでないものか

>>317
http://webpjs.appspot.com/

>>318
Firefoxで表示できた。すごいな。Web鯖に上げないとテスト出来なかったけど。
画像はPNGに変換されるらしい。

IE9では動作しなかった。対応ブラウザらしいのに。

あ、IEだとswfも必要なのか。

Fifth Generation VP8 Hardware Encoder Released
http://blog.webmproject.org/2012/02/fifth-generation-vp8-hardware-encoder.html

Evergreenってのがまた微妙なコードネームだな
「更新されない、長期放置」という意味合いも有るから

つか第5世代って一体…1-4とか有ったのか

ハードウェアエンコーダーとかどうでもいいから
もっとソフトウェアエンコの速度あげてくれよ

まずはチップ作ってからじゃないの？こういうのって。

Codec SDK 1.0も出たのにDirectshowフィルタやQuickTime Componentが更新されんのう。

Googleの対H.264戦略

MotorolaがH.264のライセンス料を過剰に求めている？
http://ascii.jp/elem/000/000/673/673896/

　通常、特許ライセンス条項について、そのライセンス料の金額（使用料金）などの詳細が公開されることはないが、今回Heiner氏は具体的にMotorolaが求めているライセンス料について明かしている。
それによると、Motorolaは動画圧縮方式であるH.264に関連する特許を50件保有しており、Microsoftにロイヤリティーとして、1000ドルのノートPCの場合1台あたり22.5ドル、2000ドルのノートPCでは1台あたり45ドルを求めているという。

　なお、H.264を実装するには、これ以外に29社から2300件以上の特許技術が必要であり、Microsoftがこれら29社／2300件に払うライセンス料金はわずか2セント、
「Motorolaはたった50の特許を利用するのに、1000倍以上の金額を求めている」と主張している。

ヘタしたらWindows OEMバンドル料金の半分をH.264の一部の特許に支払えと言ってるのかｗ
完全に強請りレベルじゃねぇかｗ

というかパソコンの販売価格で基本特許ライセンス料を変えるのって許されるのか？
何のためのMPEGパテントプールなんだよｗ

Googleが買収した途端にこれだもんなぁ。スゲーわかりやすいけど、Googleがこんな手段を使うなんてちょっと意外。

MSはIEでH264のデフォ再生を支持しながら、ライセンス料は当分要らないと
言ってるのにねぇ

「H264はライセンス問題があるからWebに合わない！ライセンスフリーなWebM推し！」
と言ってたGoogleがトンでもないライセンス料取るとはｗ

だからフリーなWebMを強引に押すためのネガキャンだろ
「こういう要求も（フリーなコーデックじゃないと）できてしまうんですよ！」と言ってるんだろうし
あわよくば同時にお金も儲けられて一石二鳥ーとでも考えてるんじゃねーの

だからといって自ら悪役を買って出る事も無かろうにw

誰もH.264陣営でやってくれないから自演しなきゃ！

Win8 MetroのIE10でもコーデック入れればWebM使えるみたいだね

JPEG互換のHDRフォーマット、ドルビー「JPEG-HDR」の狙いとは
http://dc.watch.impress.co.jp/docs/news/trend/20120302_515882.html

ドルビーがなぜ…

>>334　長い記事だからケツだけ読んだ
＞個人的には微妙にニーズと技術のマッチが取れていないという印象を持った。

いらない子か

JPEG互換が肝なんだろうが、JPEGのままでいいやっていう人が
HDRに興味持つんだろうか

JPEG-HDRって、ダイナミックレンジ追加だけでしょ？
JpenXRならダイナミックレンジと圧縮展開メソッドでメリットあるよ？

今までのJPEG対応ソフトで8ビット深度画像は問題なく開けるというメリットがあるよ。
mp3PROやHE-AACがそれまでのmp3やAAC対応音楽プレイヤーで開くことができるのと一緒。

需要がないのも一緒。

WEBPもこんな感じでHDR拡張できたりはするんかね？

DVDやBDみたいに、まずは本ちゃん規格がしっかり普及してからでしょ。
後付け設計や拡張は、後の世の技術者が考えればいい事であって、規格のウリにはならないと思う。

>>340
互換性を守って拡張する意味が無い。WebPの普及度なら、規格自体を
拡張しちゃったほうがいい。

今ならまだその段階だな

モジラ、H.264のサポートを検討か--幹部の間で議論
http://japan.cnet.com/news/service/35015181/

>>344
完全に敗戦前の降伏を見越した議論って感じだな…もう少し粘ってくれると思っていたが。

パテントフリーでないH.264が「事実上のWeb標準」になるというのは、重大な前例になりそうだなあ。

でも最近YoutubeのWebM動画も、画質かなり良くなってきてるねぇ

自分でエンコするときはエンコ速度遅くてアレだけど

はやく「標準」を策定してくれ('A`)

>>344
Googleのオープンプロパガンダって、Googleが格好いい正義の味方というイメージを保てなかった時点で破綻してる。
Google発の規格がオープンの名の下支持される時代が終わっただけの話と、そもそもH.264が普及しすぎてたって話。

WebM結構いいよ。同配信システムに組み込んだ。
ネックはエンコ速度があんま出ない事ぐらいか。

それなりに品質は上がっているとは思うが、いかんせんAVCの先行期間が大きすぎたよねえ

しかしMozillaはパテント料を払えるだけの体力があるんだな。
http://www.atmarkit.co.jp/news/201001/25/video.htmlには五億とあるが。

だけど毎年払い続けていけるだろうかねえ。

MozillaはOS標準やFlash,QickTimeのコーデック使うみたいな感じで議論してるみたいだが

ああ、なるほど。MSがWebMに対してとった対応に似たようなことをしようということですか。

パテントフリーのために標準化surao[kon

日本語でおｋ

>>344
ポイントはここら
>>Googleは、WebMを促進するために「Google Chrome」での
>>H.264サポートを打ち切るという約束を果たしていない。

>>モバイル版FirefoxがOSに組み込まれているH.264サポートを
>>利用できるようにするべきかどうかという議論から始まった

モバイルでは専用回路での再生支援が必須なのに
結局はWebM立ち上げ時の協賛企業がそろって口だけだったいう事

そういやAdobeもFlashにVP8を実装するっていってたけど全く音沙汰なしだな

アップルってWebPには対応しないのかな

>>355
ZiiLABS ZMS-40 とか NVIDIA Tegra 3 とかVP8対応してるぞ

DLNAでことごとく動かんのもうねる

Mozilla が H.264 をサポートへ、webM 派から転向
http://japanese.engadget.com/2012/03/20/mozilla-h-264-webm/

＞Mozilla Foundation の理事長である Mitchell Baker 氏と、CTO の Brendan Eich 氏が相次ぎ、
＞ブログで H.264 サポートの意向を表明しました。
---
＞インターネット動画配信についてはライセンスが恒久的に無料で提供されるため、
＞H.264 対応ブラウザを利用するとお金がかかるということはありませんが、

有料動画はライセンス料いるんじゃなかったか？

webM終了おめ！

こんなに嬉しい日はない。今夜は祝杯だ。

おめでたいことなの？

MSのおかげでWebM駆逐できてよかった

ウェッムー終了ｗｗｗｗｗｗｗ

え？FirefoxからWebM削除されるの？と思ったら
>>360のタイトルが「webM 一本化を断念」に変わってた。
「一本化を断念」、はいここ大事。「H.264だけにします」とは誰も言っていません。
まあMozillaサイドの臥薪嘗胆ぶりは心中察するに余りあるね。

ただ、これでオープンウェブという理念に対する冷笑が広がるのは止められないだろうな。残念だが。

規格争いをしている場合ではない。

Webの寵児！オープンソースの勇！だったはずのGoogleが
今ではMSの代わりに、完全に悪の帝国二代目だからなぁ

　　　　　　　　　 从川川川川川川川川川川川|
　　 　 　 　 　 从川川川川川川川川川川川川
　　 　 　 　 从川川川川川川川川川川川川川
　　 　 　 从川川川川川川川川川川川川川川
　 　 　 从川川川川川川ﾘ　 　 　 .:::　　 ヾ川川
　　 　 从川川川川ﾙﾘ　　:::...　　 .:: 　 　 　 ヾ川
　　　从川川川川ﾘ′　　　　::::.　.::: ∧ 　 　 　 :|
　　　从川川川ｌﾘ:.　　　　 Ａ　:::.　::. |__|　　　　　|
　　　 从川川川: .　　　　 |lll|　::　 :: |llｌ|　　　　 .:|
　　 　 从川川ｌ||: : : .　 　 ∀..::::　 :::.∀　　　　.:.:|　　　　　　　
　　　 从川川川: : : :　　:::::::::: r'_　_ヽ::: 　 　 . : .:|
　　　 从川川川:. : .　　　　 　 　 　 　 　 　 　 . :|
　　　 从川川川､:. . 　 　 　 　 /ﾊヽ　　　　　　 :|
　　　　ヾ|川l川l从:.:.　　　　 　 |:|::|::|　 　 　 　 :/!
　　　　　 ヾ|川川从:.:.　　　 　 ヽv:/ 　 　 　 .:厶|
　　　　　　　ハ,r‐一ヽ:.:.:.:. .　　　　　　 .:　 .:./三|
.　　　　　　　 /:|ﾆ三三≧x､:丶.＿＿_ノ　 .:/::三:!
　　　　　　　/::/三三三三ﾆﾐ､:.　　　　　 :/三三|
.　　　　　　/::/三三三三三三ﾐ､:. . . . . :/::三三:

>>367
そもそもHTML5は過去の反省から
理念から距離を置いて複数の実例のある提案は全て丸呑みで
揉め事を避ける策定プロセスになってたのに

弱小な勢力が既に普及してる側を拒否とか正気の沙汰じゃないし
理念ガチガチで一本化を求めるとか筋違いにも程があった

んなこたない
そもそも反対派がいなきゃ2015年以降のライセンス料がどうなってたか分からんかったし
ライセンス料が恒久的に無料になったのは、HTML5がコーデックの標準を決めないとされた後だ

>>371
http://www.w3.org/2003/05/patentpolicy-pressrelease
W3Cは正気ではないと。

xiphのDirectShowのプラグインで、
YouTubeのWebM再生できないのがあるんだけどなんだろう・・

グーグルはWebMエンコードできる定番ソフトだしてくれればいいのに

ぐーぐるさんはお題目は勇ましいけど実践面はガチの現実主義だからな…

ChromeのH.264-HTML5サポがなかなか切れないから変だとは思ってたけど(>>262)、
やっぱり二枚舌戦略だったか

1億ドル払ってわざわざOn2買った以上、最初から二枚舌を予定してたとは思わないが、
やはりH.264サポートを切ると表明した時に叩かれて及び腰になったかねえ。

まー、いまや>>326だから何をかいわんやだが。

まあ、実際問題オープンソースにしたからって、すぐに良いエンコーダや
HWデコーダが生えてくるわけでもないしな。特にHWロードマップなんてのは
年単位でいつかの第なんとか四半期までにみたいなスケジュールがざらだし。

H.264Flashという名のH.264デコーダーで保険が打てなくなっては、Mozillaが日和るのもしようがない。

Flashを排除し、WebM不支持を貫いたアップルとマイクロソフト。
両社ともH.264の特許保有をしているから当然だけど、この存在だけで勝負ついてたわ。
開発元のGoogleがWebMとH.264に二刀流とかしなけりゃWebMの延命は出来たかもしれんけど。
あんなんでMozillaもよう我慢してたもんだ。

MSは、一応再生できるようにはしただけましでしょ。
アップルだよアップル。

>>379
一つのフォーマットしかサポートしないのが偉いってなんじゃそりゃ
だったらiPodもさっさとMP3排除しろって話になるわ

>>378
プラグインに頼らないのも売りのHTML5ビデオなのに
その普及までの保険にFlashプラグインに頼るって自己矛盾が。。。もうね

そこまで商業規格を嫌うならプラグインからも排除しろよっていう
途中からMozillaが日和ったというより最初から理想を語る資格が無かった

なんで日本・日本語を選択してるのに”youtubeより”とか”エンターテイメント”
に最初にあがってるコンテンツってハングルとかチョン歌手とかばかりなの？
それからYoutubeを見なくなったけどね。あれはほんとウザい。

もはやGoogleはH.264を超えるVP8を発展させた次世代コーデックを作り、
はっきりわかるレベルでの画質の違いで有効性をアピールするしかない。

追記：今でもわかるが、より鮮明にわかる感じ。PS2とPS3の違いみたいな。

うぐ、、また追記。
わかるって部分、逆の意味で。H.264が上。

H.265(HEVC)の策定が進んでいるのに対抗？して、XiphがDaalaというプロジェクトを始めてる。
https://xiph.org/daala/ https://wiki.xiph.org/Daala

>The goal of the project is to provide a free to implement, use and distribute digital media format
>and reference implementation with technical performance superior to h.265.

しかしH.265と同等かそれ以上のコーデックでかつfreeとなると、特許はどうするんだろうかね。

GPU再生支援とGPGPUによるエンコ最適化がなきゃ今後はやってけないだろ

>>387
特許を避けながら高性能コーデックを作るなんて無理ゲーだよな

全く新しいアルゴリズムでも考え出さないとな…

まだ特許取られてない新しい技術を作るのと、
すでにある技術の特許の抜け道を見つけるのはどっちが簡単なんだろう

グーグルの場合お金は有り余ってる訳だから
また他所の技術を買って来る方が早いのかも

その気になればH.265用に開発されてる各社の動画技術を
札束積み上げて片っ端から買い占めする手も有るな

>>326みたいにGoogleが特許料をふっかけてくる時点で、当初の理念自体が破綻してた。

Do evilが社是の会社だしな

MozillaはTIFF、JPEG XR、出来たらJPEG 2000もブラウザで標準対応してほしいところだ。
WebPだけでは心もとないよ

ぶっちゃけJPEGXRもJPEG2000も、画質の面ではWEBPと比べて世代が一個古いからなー

WebPって48bit画像とか保存できたっけ？
あと YCbCr 4:2:0 以外にも対応していないハズ。

小さいサイズでは画質良い、それだけな規格ってイメージだ

Web向けだよね

>>398
つまり、そういう高精度な規格に対応してて、かつ画質もいい形式がほしいってことね。

WebPはデジカメに搭載されることは無いからたいした普及はしない。
まあPNGの代わりを果たそうとしているんだろうけどさ

順調に人々の記憶から遠ざかっているからな…

話題無いな

完全に死んだな

VP8 Codec SDK "Eider" Released
http://blog.webmproject.org/2012/05/vp8-codec-sdk-eider-released.html

速度とかあがってるっぽいねwebm
x264より先にopencl対応とかすりゃ結構面白いんだけど

WebPのほうも4/11に上がってるっぽい
http://code.google.com/p/webp/downloads/list

WebM JavaScript Decoder
Ogg Vorbis JavaScript Decoder
http://webpjs.appspot.com/

>>406
可逆圧縮だいぶ圧縮速度上がったな。
圧縮率は下がったけどそれでもPNGよりは縮む

opencl云々書いてたらx264のほうが先にきたてござる

四半期ごとの更新まだ続けるの？
無理じゃね？

TrueRemoteの作者が、叢雲というリモートデスクトップアプリのβを発表したな。
使われているのはWebMベースのエンコーダーだそうだ
高速高圧縮高品質をうたっている

WebPはなかなか正式版が出ないな。
可逆とalpha channeにwebpmuxと、結構でかい更新とはいえ。生みの苦しみかな。

WebPに1.99とやらがきましたよ

0.1.99だった

可逆圧縮のオプションがあるね。

susieプラグインのも上がってた

Sample iOS client Appってのが上がってるね

>>415
-lossless で作ったファイルが開けない
可逆圧縮の伸長は対応してないのかな

lossless対応きた。これでpngから置き換えられる。

0.20.0 rc1

正式版きますた
http://code.google.com/p/webp/downloads/list

GIF「やっとオレの出番もおしまいか

だといいんだがね。MNG, APNG, どれも使われずじまいだからなあ。
Firefoxが対応してくれれば少しは可能性がありそうだが、どうなるか全くわからないし。

MもPもGoogle関係者以外で使ってる奴見たこと無いぞ。

True Remoteの作者が、新しいリモートデスクトップアプリに
WebMのコーデック使ってるようだから期待。
ただ、なかなか動きが無いのが気になるが

動画みたいな激しい動きのやつだとダメでしたで記憶は止まってるけど
それから音沙汰あるのだろうか

真空波動研で、WebMファイルを調べたところ、

[今日の日はさようなら 【ヱヴァンゲリヲン新劇場版：破 未収録ver】.webm]
1920x1080 0Bit On2 VP8 1000.00fps
Vorbis 44.10kHz 192.00kb/s VBR 2ch
[Matroska] 00:02:09.932 (129.932sec) / 8,944,265Bytes

真空波動研SuperLite 120101 / DLL 120101 Unicode

独自のコーデックとは…。FLV、MP4、WebMの3つの形式の再生ができるソフトをどうにかして手に入れるとするか。

全然独自じゃないし、FLV、MP4、WebMの3つを再生出来るソフトってどこにでもあるっしょ

K-Lite入れれば一発だな

VLCでもMedia Player Classic Homecinemaでもいいし
ブラウザのGoogle Chromeでもいいんじゃねｗ

創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね
創・価
死・ね　
創・価
死・ね
創・価
死・ね

libwebp 0.2.1 released
https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/webp-discuss/QTtgi8YfgkE

セキュリティバグ修正リリース

WebM完全に死んだな
Googleが約束してた定期リリースもなくなったし。

ご冥福をお祈りします

いよいよYoutubeも潰れ、H.264の天下だな
いや、まもなくH.265が登場してH.264も廃れるか
お金も払えない愚民はH.264で満足してろと

>>432
遅れてるだけで開発はやってるよ
http://git.chromium.org/gitweb/?a=project_list;pf=webm

遅れたらもう駄目
そもそもH264に比べて画質、エンコ速度面で圧倒的に負けてるのを
頻繁なアップデートで追いすがるプランだったろ？
それなのに歩み止めたら終わりだよ

一行目の「遅れたら〜」が四行目で「歩みを止めたら」に唐突に変わってるのはすごいな
無理やり自分の言いたい結論にもっていこうとするとこうなるのか

走り続けるウサギに亀が追いつくには、ウサギ以上に速くないといけないんですよ
亀のままでは離される一方でオシマイ
現実は童話と違ってウサギは足を止めてくれない

追いつけるかどうかという土俵の中で、ウサギ未満の速度の亀は止まってるも同じ。
ゼロか1かなんですよ

1行目と4行目に矛盾があると感じるのは、君の頭が悪いから。

H.264やH.265に愛称というか、固有名詞は無いのかい。
数字が1文字違うだけって紛らわしい

>>438
多少WebMの開発速度って遅くはなったかもしれないけど
H.264の開発速度に比べればWebMの開発速度は今でも相当早いよｗ

HTML5にWebMは採用されないのか？

HTML5ではコーデックはブラウザの政治的気分次第

>>441
videoタグに特定のコーデックを指定するということはしないかと。
ただ、Firefoxがやむを得ずハードウェアやOSのコーデックを使用するという方向性を示したことで
MP4/AVCの優位が追認され完全に不動のものとなったということ。
この優位は、かつてのGIF問題でのUnisysのように
MPEG-LAが無体な行動をとらない限りは動かないだろう。

Sixth Generation VP8 Hardware Accelerators Released
http://blog.webmproject.org/2012/11/sixth-generation-vp8-hardware.html

WebRTC向けか

>>439
それぞれMPEG4（AVC）とMPEG5と言う愛称になると思う

JPEG 2000にFirefoxが対応した上で、SafariがJPEG XRに対応したらWebpも
終わってしまうな。これは噂段階だけど将来的には対応するらしい。

265はHEVCが多いような気もするけど
画像のほうもやっとサポート増えるのか今よりよくなるならなんでもいいさ

>>446
IE & Safari : JPEG XR
Firefox : JPEG2000
Chrome : WebP

ということ？
だったらどれもウェブで普及せずJPEGが生き残ることになるな。
（つうか、JPEG2000っていまでもまだもっさりするんだが）
もうさ、各社が特許を持ち寄ってOpus Codecのように一つにまとめて
標準化してくれたほうが早いんじゃないかと思うレベルだな。

JPEG 2000やJPEG XRに関しては、WEB関連の会社だけが特許を持ってるわけじゃないからな
デジカメとか、そのあたりの会社は消極的なんだろう
（だからこそGoogleはWebPを出したわけだが）

JPEGというISO/ITUの専門家組織が標準化した規格であるJPEG 2000/XRと比較して
ただの１企業であるGoogleがすべての権限を持つローカル規格のWebPが
特許に関して、デジカメ等の会社が積極的になれる要素が一つもない気がするんだけど。

>>450が何を言ってるのか分からない。誰か解読してくれ

2000やXRは標準化の過程で特許侵害の可能性がないかどうかある程度審議されているが
WebPはそうではないということだろ。

WebMエンコーダーはとにかくCPUを使ってくれないな
エンコ中にCPU空きまくり

>>448
Safariは既にJPEG 2000に対応済みでJPEG XRにも将来対応させたいと言われている
だから噂段階をまとめると

IE : JPEG XR（対応済み）
Safari : JPEG2000（対応済み） JPEG XR（対応予定？）
Firefox : JPEG2000（対応予定？） WebP（対応予定？）
Chrome : WebP（対応済み）
Opera :　WebP（対応済み）

AppleはJpeg XRを支持してるしな。

AppleとMSの最大手二社からWebPが支持されていないのが痛いな。
Firefoxは風見鶏だから当てにならないし、MPEG4AVCにも対応するみたいだしさ

JPEG XRはHDRが魅力的でTIFFの代わりとしても使える器用な規格だけど、
圧縮性能はJPEGと大して変わらないのが痛い。JPEG2000並というのはMSの過大広告だったな。
SSIMでもそんな大きくは変わらないし、目視でJPEGより劣っているような例もあった。
実装の改善で改良の余地があるのかな？

いろんな画像形式のいいとこ取りのフォーマットできないかなぁ。

・ハイダイナミックレンジ対応
・圧縮アルゴリズムは動画圧縮のを流用
・可逆圧縮にも対応（JPEG2000みたいな手抜き可逆ではなく）

Wikimedia Launches HTML5 Media Player with WebM Support
http://blog.webmproject.org/2012/11/wikimedia-launches-html5-media-player.html

Introducing Wikipedia’s new HTML5 video player
http://blog.wikimedia.org/2012/11/08/introducing-wikipedias-new-html5-video-player/

マーケティング本部長　岩村　水樹　

この馬鹿はアドワーズ無料券を送り散らして
詐欺って金を騙し取ろうとするしか脳のない最悪極悪の無能肉便器なのだなｗ
ヤクザ組織のオレオレ詐欺と実質何も変わらない酷いクオリティ。
馬鹿女のやることは所詮こんなものか、チンパン並の倫理感しかない強欲メス豚オイ！！！！！！！
それなりの報いを受けよ報復攻撃で八つ裂きの刑。

久しぶりにyoutubeを高画質で落としたらwebmが落ちてきた
実は今日始めてみたから最初失敗したのかと思ったぞ
しっかしこいつ色々と使いにくすぎる、普通にmp4でいいのに

まあしばらくすればWebMともどもYoutubeが潰れるから見てな

webmもwebpも対抗規格が強すぎるからポシャルな

>>463
Ogg系絶滅も近いよな

いやいや、適材適所で生き残るよ
主流には成り得ないってだけで

可逆圧縮の音声ファイルフォーマットflacは細々と生き残りそうな気がする。

>>464
フリーで使えるメリットを生かして、意外なところで使われていることがある

>>466
FLACで24bit 192kHz音源を有料配信しているサイトとかあるんで、結構生き残りそう

音声の可逆圧縮は非可逆何ぞ目じゃないくらいに乱立してなかなか淘汰が進まないけど
現状の普及率ではFlacが一番じゃないかな
takが対抗馬で、apeは古株ユーザによってなんとなく使われてる感じ

ただFlacについては「細々」って認識はおかしいぐらいだと思う

>>464
WebRTCで正式採用されるOpus CodecはOggに含まれる？
Video Codecは決まってないがVP8も候補らしい

H.264→H.265のラインは崩す事は出来まい

>>469
OpusのコンテナはOgg

このまま10年位H.264の天下が続きそうな気もする

http://forum.doom9.org/showthread.php?t=165839

VPNextの開発もやってますよ的な資料

WebPとかWebMって自分のソフトに使っても特許で訴えられることはない？
WebMはGoogle、Mozilla、Adobeがこの陣営のようだが

そんなもん、訴える側次第だよ。
Googleが守ってくれるわけでもないから、自分で特許関係に問題ないか確認したうえで採用すればいい。

GIFなんかだとSonyもMicrosoftも訴えられたんだ。
VP8だけ特許政争に巻き込まれない保障なんかどこにもない。

MP4 AVC/H.264ならライセンス料に含まれるから訴えられる可能性は限りなく低いけどね。

>>472
IE6の悪夢か…

>>476
動画技術に関してはハードウェアのエンコーダー／デコーダーの普及度合いと言う面も有るから
必ずしも長期政権が悪いとは思わない

早くこの世の動画技術が一つだけになってほしい
もうこれ以上の画質向上も帯域節約も必要ない
H.265がモノになったらもう次の研究はやめてほしい
これ以上企業を振り回さないで

それ「CPUはCore i7だけになってくれ」とか「OSはWindows 8だけになってくれ」と言ってるのと一緒だからな？

>>479
喩えが極端すぎて間違ってる
CPUはIntelもAMDも十分な互換性があるからi7だけでいいなどとは思ってない
OSもWin8だけとか思ってない、まあXP・7・8だけあればいい
MacとLinuxは少数派な上に対応コストが半端ないからさっさと淘汰されてほしい

いずれにしろハードウェアメーカーは複数の規格に対応するコスト高を嫌がっているのが事実
H.264とH.265に同時に対応することになるだろうけどそれだっていやというほどコストかかるのに
WebMなんぞ相手してられんでしょ

>>480
>>479 のたとえが極端だというその発想が間違っている。
ハードウエアの進化や再生環境の変化を考えたらH.264だけでOKとかとても言えない。
そんな認識の企業がもし存在したら規格より早く淘汰されるだけだ。

>>480 の中でARMやモバイルOSについて言及されていない時点で
認識を改めるべきだと思った。

(南米のデジタル放送にH.264+ISTBではなく日本同様にMPEG-2+ISTBを
押し付けるべきだとほざいたアホを思い出す。誰が言ったのか忘れたけど)

競合相手としてのWebM/VPxは必要だと思うが
スタンダードとしてはH264とその後継で良いと思う

http://av.watch.impress.co.jp/docs/news/20130128_585298.html

Googleが独自の画像フォーマットWebPをChrome Web Storeでも使用
http://jp.techcrunch.com/archives/20130207google-now-uses-its-own-webp-format-instead-of-pngs-in-the-chrome-web-store/

http://anago.2ch.net/test/read.cgi/software/1317566046/686

http://anago.2ch.net/test/read.cgi/software/1317566046/686-

http://headlines.yahoo.co.jp/hl?a=20130221-00014694-techcr-sci
結局のところFirefoxはH.264に対応する予定みたいだな。Googleはこれで
更に苦境に陥ったな。Firefoxはやはり風見鶏だWebMに対応すると当初はGoogleと
強調していたのに。あと今頃になってMP3に標準対応とは・・・・
色々と遅れているみたいだな。
今度はJPEG XRとかJPEG 2000に対応するんじゃないかな？webpもヤバイね。
Operaだけじゃどうにもならん。

風見鶏はgoogleじゃないかという
動画のほうはもうよほどのことがない限り主流になることはないだろうし

>>487-488
へえFirefoxがWebM完全排除してH.264に対応するのか
俺の印象としては「H.264自前で対応するのはライセンスきついからDirectShowに丸投げ」て感じだったから
DirectShowでWebM再生できるんなら大丈夫なんじゃね？

この記事でWebM完全排除とか言っちゃう人って普段どういう生活してるんだろう
そんな理解力じゃ日常のちょっとした連絡すら覚束ないだろ

WebMを排除するのではなく、H.264の排除を止めたと言うだけだな。
これでもWebMにとっては打撃である事に代わりは無いが。

JPEG 2000はFirefoxがやる予定があるみたいだし。スマホの性能がもっと上がれば
採用してきそうだな。Safariも現在はJPEG 2000だけだけど多分JPEG XRに対応してくると思う。
あと動画のH.265のデファクトスタンダード化はほぼ間違い無い。
VP9をベースに新コーデック作ってもgoogleは標準規格から取り残される

>>492
予定があるというのは、bugzillaで実装の話が出てるってこと？

>>489
排除はしてない
Firefox20でH.264実装、設定で無効、21で設定有効(5月14日リリース)
再生はMedia Faundation(DirectShow後継API)を使う

googleはそれでもH.264に対応する気は無いんだろうな

>>487とか>>492とか>>495みたいにgoogleがH.264に対応してないと考えてる奴らは一度これまでの経緯を調べ直して来い……

同一人物じゃない?

次はH.265に対応する番だな

静止画はローエンド用のJPEG XRとハイエンド用のJPEG 2000と言う形でWebpも葬って
くれるとよい。
動画は当然ローエンド用のH.264とハイエンド用のH.265でWebmを葬ると

次の患者さんどうぞ

>500
GoogleはH.265に対応するだろう

JPEGXRとJPEG2000はもうオワコンだろう。圧縮性能が悪すぎる。

>>502
しかしだからと言ってTIFFやPNGはな・・・・
そこで出来たのがWebPと言うわけか
デジカメやスマホで標準で撮影できるようになった規格が勝つよ

その理屈だとJPEG2000やJPEG XRやTIFFは勝つんだな。すごいな。

コストパフォーマンス的にデジカメやスマホに載るとは思えない。

J2kですら膨大な回路規模、処理時間、メモリ使用量で普及しなかったのに
WebMなんて動画デコードと同規模の実装が必要とか気が狂っている。

では永久にJPEGにままと言うわけか・・・・

WebPは1枚画像フォーマットだから動画デコードと同規模の実装なんて要らんでしょ
それに、Jpeg2000のWavletのほうが重いし

>>504
>>505
JPEGに変わるものは二度と現れない事が決定しているんだな
50年後もJPEGは決定したわけだ

1990年レベルの画質が50年後のインターネットを苦しめるわけか

まあ画質なんて一般ユーザーは少なくとも困ってはないんだよな。
もしかしたら50年後もそうかもしれない。
Googleはたくさん広告を見せて利益にしたいからWebP開発してるわけで。
俺は新し物好きだから使えるものなら使ってみたいか思うけれども。

あとWebであのもっさりしたJPEG 2000は使いたくないわ。
XRの圧縮性能の低さが悔やまれる。

GoogleがWebPを普及させようとしているのは画質じゃなくてファイルサイズを抑えたいから。
画像検索で引っかかる画像をコンテンツのように見せている現状では少しでも小さくなってもらわないと困るわけだ。

関係ないけどWebMハードウェアデコーダってTegra3やOMAP5、Exynos5で搭載されているらしいけど使えるの？

>>510
IrfaViewにWebP変換機能があるから愛用してるけど、
WebPは圧縮率がすごい上に画質落ちにくくて素晴らしいよ

昨今、クラウドストレージが流行りだが、通信料、通信速度、ストレージ容量節約など
高圧縮画像形式は非常に意味も意義もあるよ

文字を含む画像を圧縮する時にJPEG使うと文字が破綻するけど、
WebPなら全然破綻しない。これも重宝する

JPEGに取って代わる規格は永遠に現れないわけだ。
性能は全然なのにな。悪貨が良貨を駆逐するという典型。
でもこれに変わる規格は存在しない。
動画はMPEG1→MPEG2→MPEG4AVCと置き換わったのに、静止画は無理そう。

現状で静止画は動画ほど画質面でのハッキリした差を感じにくいしな
表示デバイスの進化によってその状況が変わってくる可能性は有るけど

帯域節約は現時点で充分なメリットでは有るけど
各社思惑有ってなかなか足並み揃えるのが難しそう
どのデバイスでも表示出来る形式でないと使いにくいし

訴訟もないし、どうなってんだと思いきや、こんなことやってたんだな。
引っかかるかはmay beのままでスッキリしないが、お金より時間のほうが貴重ということか。

GoogleとMPEG LAがVP8規格について合意。Googleがライセンス取得
http://japanese.engadget.com/2013/03/07/google-mpeg-la-vp8-google/

お金払って揉め事を回避か
無難だと思う

金払うなら、H.264でよくね。

>>517
H.264みたいなコーデック開発のために特許料払わなきゃいけないクソ規格と
FLOSSで自由に実装できるVP8を一緒にすんな
何も知らないなら黙ってろよ

そもそも金を払ったというのは憶測にすぎないし
金を払ったのが真実だとしても個々に払わなきゃいけない特許料とは完全に別物
これで特許を気にせずコーデック開発できるようになったのは開発者としては本当にありがたい


一般ユーザにとっては、再びMP4とWebM、動画規格が対立する悪夢の始まりである

勝負はとっくに付いてるだろ

これ、ある意味MPEG LAは、VPxをH.264or265に対して競争力が弱いから
しゃかりきになって潰す必要もない存在とみなしたということなのかな

>>520
だろうな。いったんH.264優勢になったから手抜いたんだろ
あとはここからWebM/VP8がゾンビみたいに復活するかどうかだけど……するんだろうなあ……
今まで一番ネックだった特許問題が消えて各ベンダがVP8実装するのに何の支障も無くなったわけだし
採用実績もYouTubeで十分すぎるほどあるし……

予想に見せ掛けて願望を書いてるだけのような

>>522
>>520は中の人が明言してたしな

>>523
中の人ってどこの中の人？

廃れる廃れないにかかわらず、こういうフリー系フォーマットはゲームディベロッパーが使っていってかろうじて生き残る
OggVorbisしかりVP8しかり

それはそうなんだけど
問題はここからVP8のシェアが増えるかどうか
（adobe flashとかMS IEで実装されるかどうか）
じゃね？

AdobeもMSも実装しないだろうな（Adobeのやるやる詐欺はひどすぎwww）

GoogleはWebRTCのようなリアルタイム用途で普及させたいんじゃないかな
リアルタイムならそんなに高画質はいらないだろうし（エンコード負荷が高すぎても困るわけで）
その名前が示すように、Googleにとってはあくまで自分の庭である「ウェブ」用途なんだろうし

でも最近flashがpepperプラグインに対応したし、その後Linuxではpepperのみになっただろ
ああいうことがあるから同じようにGoogleがAdobeを金で動かすような気もするんだよな
まあ、将来どうなるかなんて俺らにゃ分からんけど

札束ではたかれていやいや重い腰を上げて対応させられるようなシロモノを誰が使うものか
MP3もAACもH.264もみんなその魅力と音質に惹かれて「何万ドルでも払いますから使わせてください」と
権利者に土下座してまで使わせていただいているのに…

Anonymousみたいな団体が法律がまともに機能していない国で特許侵害しまくりの映像コーデック
を作って、Freenet上で公開するとかそういう展開希望

結局そのソフトは法律がまともに機能してる国では商用利用できない
意味がないよ

>>529
当時はH.264が無かったし、adobeだってもともと金で叩かれたわけじゃなく自発的に対応すると言い出したんだろ
対応する！って言った矢先にMPEG LAが重い腰を上げたからなし崩しに話が止まってるだけで

×当時はH.264が無かったし
○当時はH.264しか選択肢が無かったし

自発的にというか、政治的にかな
脱Flashの流れに抗う為にはGoogleと協調関係になる必要性があった

エロゲがVorbis使うようにVP8も使うんじゃないの

例のライセンス取得で、使用側としても最後の障害がなくなったことは確かだな

でもライセンス面の潜在的な不安がどの程度の障害だったのかは分からん気がする
使わないことへの口実の一つでしか無かったとも感じる

WebM／VP8登場以来のこの1年数ヶ月は
先行技術が余りに深く広く強く浸透してしまっていたが故の苦戦であって
そう簡単にはひっくり返せないだろうと思っていたら案の定だった

個人的な意見としては
次世代で互角の戦いが出来る様にVP9以降の開発で頑張ったほうが良いと思う
VP8はWebRTCで一定の成果を挙げそうだし、それで充分かと

2010/5登場だから2年数ヶ月だった

>>537 文脈がばらばらで何が言いたいのか分からん
上から順に全然違うことを言ってるように読める↓
・「各社が」VP8コーデックを搭載しなかったのは、本当は特許のせいではない
・「ユーザの間に」先行技術が浸透していたため、VP8は勝てなかった
・「Googleは」VP9以降で開発を頑張ろう

・開発者がVP8コーデックを搭載しなかったのは本当は特許のせいではない
→じゃあ何が原因なの。需要が無かったとかそういうこと？
→特許のせいで他のソフトに組み込めなかったのに、どうやって需要喚起しろと

・結局のところ先行技術が浸透していたためVP8は勝てなかった
→先行技術が浸透していたため、という原因「も」あるだろうが
→そもそもVP8が浸透しなかったのは上で言ったようにそれ以前の問題じゃね

>>539
>→じゃあ何が原因なの
書いた通りで、「先行技術が余りに深く広く強く浸透してしまっていた」ため。

→特許のせいで他のソフトに組み込めなかった
違うと思う。Skype始め採用例は有るので。

そりゃ採用してる会社が特許をガン無視できる会社だったってだけだろ……

要するにWebM/VP8が現在当初期待されたほどには普及していない原因として、

・特許にまつわる潜在的な問題の可能性
・先行技術の圧倒的な強さ

のどちらを主として見るか、の意見の相違だね
自分の見方では前者より後者が支配的な要因と捉えているので
そのように意見したまで

一か所だけ訂正すると、特許の問題は「潜在的」でもなんでもない
2010年にMPEG LAが特許料徴収する考えを発表してから、ずっと「顕在化」してた問題だよ
ttp://www.itmedia.co.jp/news/articles/1005/24/news047.html

特許に関しては悪名高きGIFのような前例もあるから慎重になるのは当然だろ、というのが俺の意見ね

その件は当然知っているが、具体的な特許侵害の内容は
当時から一切明らかにされていなかったので「潜在的」で正しいよ
（そして具体的な事は結局最後まで伏せられた）

>>543
JPEGですら大企業が金を払わされる事例もあったしな
http://oku.edu.mie-u.ac.jp/~okumura/compression/jpegpat.html

>>544
まあでも、Googleがああいう形で手打ちにしたってことは
裁判に持ち込まれたら勝てる見込みは低かったんだろうなと

本気でGoogle ChromeのH.264サポート切る気みたいだな
ttp://internet.watch.impress.co.jp/docs/news/20130308_591073.html

これはFirefoxもH.264サポートの開発を中止するんじゃ
（といってもFirefoxのH.264サポートはたいした仕事ではなかったけど）

>>546
記事を読み違えてる。読めば分かる通りでそこに書かれているのは単なる過去の経緯。
URLのリンク先にも書かれてはいない。

ChromeでH.264のサポートを切ると発表したのは2011年1月だったが、
実行されずに現在に至ってるのは周知の通り。記事ではその事に触れていないが理由は不明。
多分単なる不勉強。

別に嘘書いてるわけじゃないから不勉強ではないね

なら読み間違えた君の国語力不足ということだね

相手にしても無駄だからスルーしたほうがいい

>>545
あと、こっから年単位で裁判やってたら、せっかく大枚はたいてOn2と資産買ったのに、
それもゴミになっちゃうからな。今はまだやりようによってはサポートするハードウェアを
作ってもらえそうな余地がまだあるけど、HEVCが本格普及しよう状態になったら誰も見向きもしなくなる。

動画はHEVC以外絶滅しそうだけど音声はいつAAC一本になるの？

どうやってマネタイズするんだろうか
リーダーみたいに消えなきゃいいけど

動画サイト閉鎖しない限り続けるとは思う。264やHEVCがいつぼったくりするかわからんし。

ところでVP9はHEVCに追いつける目処は有るのかい

>>552
なってほしいの？　AACのライセンスフィーってAVCよりも高いって知ってた？

映像がVP8のおかげで助かっているところはほぼないだろうけど、
音声はVorbisとFLACのおかげで助かっているところはめちゃくちゃ多いぞ。

音はOpusとVorbisだけで十分だけど映像はガチでカスだからこまる。圧縮・再生が猛烈に早いくらいしか利点がない

>>556
このスレの住人ならライセンスぐらいいくらでも払う覚悟はとっくにできてるだろ

そういう人はすでにH.264使ってて
品質で劣るWebMのスレなんか興味無いと思う

音声のSpeex・Opus・Vorbis・FLACは地位を確立しているし、静止画のWebPは
JPEGに取って代わることはないだろうけど、JPEGよりも明らかに高性能だし
Googleもちょこちょこ拡張して足りない機能を付け足していっているので
先行きはある。

VP8はH.264の競争相手になることでH.264のライセンス料がとんでもないことに
なるのを避けた意味は大きかったけど、ただそれだけだなぁ。

WebPはGoogleの検索のプレビューや画像検索に多用されてるから
自然と多くの人に恩恵を与えている。
Google自身のトラフィック削減にも大きく貢献しているだろう

ただ、WebMは・・・
Youtubeに使われてるけど、だれかWebMで見てる人いるの？ｗ
Skypeでは使われてるが、これは後からWebMに切り替わっただけなので
今後あっさり別に切り替わるよね
全然使われてないよなー

VP9はまだかあ

ニコニコ動画の中の人が「WebMは絶対に使いません」って宣言してたから
もう終わりだろう

映像はx264かHEVCのオープンソース実装でいいんじゃないですかね

>>562　Firefox使いだけどFlashなんて滅多に有効にしない
　　　　いつもYouTubeはWebMで再生してるぞ

>>564　それってパテントライセンスの問題がまだ残ってる時の話じゃね？
　　　状況変わったから今このスレが賑わってんのに

>>565　営利目的でそれを使うと特許ライセンスを買わないといけないので、結局その方法では何も解決しない
（VP8なら↑の問題は一応解決できるようになった）

OSXは10.3以降、Winは7以降でシステム標準のH.264ライブラリが有るから
それらを呼ぶ形で使う分には特に問題無い（ライセンス的にも）

有料配信はWebMにするメリットあんのかな
DRM要るからFlashのWebM対応が必要だな

>>567
Linuxのgstreamerはどうなのかな？

問題あるが、ブラウザ側に責任なし
…なのかな？

ffmpegみたいに簡単に扱えるVP9のエンコーダーってまだないのだろうか
最新のx264程度の性能を持っていて、それがWebRTCとかUstで使えるんだったらかなりいいな

ffmpegがVP9エンコーダーとして簡単か？
パラメーターの表記があいまいで設定しにくいぞ

2011年開発開始なら最適化が概ね終わるのは2015年くらい？
14nm世代CPUとMRAMとDDR4とGTX9xxが出てるな

VP9：pc内で完結する用途ならそれなりの地位は得られそうだけど、コンソール・スマホ・家電用となると絶望的
Opus：携帯とかデジタルラジオとかでも普通に使えそう

Opusはとにかく遅延が少ないという利点がどんな場面でも優位だよな

Androidが今のシェアを保つ限り、スマホでの採用率は上がるだろう＞VPx

例えOSSで有ろうとも、一企業の思惑で全てがひっくり返されかねない
非標準化技術など支持する気には全くならんが

「VPxはもうオワコンなので温情で赦してくださったのだ」
なんて意見が主流を占めるWebMスレ…もうアンチすれだろここ

お前の解釈が極端なだけ
復活ありうるって意見も一定数あるだろ

DaalaとVP9ってどっちに寄付すればいいの？ビデオカード利用が最初から考えられてるDaalaの方が有望に見えるけど・・・

WebMはもう駄目だな、VP9でH.265に対抗するしか方法は無い。H.264にVP8では
勝てなかったわけだし（主に普及と言う点についてだが）
WebpはデジカメでJPEG XRや2000での撮影に対応した時点でアウト
Webpがデジカメやスマホで撮影も可能になるとは思えない。
iPhoneは今よりCPUとGPUの性能が上がればJPEG 2000での撮影に対応してくるでしょう
今のところはスペック的に見ても再生にだけ対応しているけどね。

誘導
●JPEG2000(*.j2k)ってどうよ？　　　　.
ttp://toro.2ch.net/test/read.cgi/cg/990029094/
JPEGの後継画像フォーマットについて議論するスレ
ttp://toro.2ch.net/test/read.cgi/cg/1148854872/

普及で勝てなかった普及で勝てなかったって連呼してるやつらはアホ
GIFの代替としてPNGが登場したのが1996年、その後GIF相手に10年くらい頑張って今では十分PNGは普及してるだろうが

VP8も今IETFが標準化をマッハで頑張ってるところなんだから、まずそれが完成してやっとH.264と同じ土俵だろ
この時点での形勢判断はいくらなんでも話が早すぎ

コメ乞食相手にして意味があるかどうか・・・

WebPはだれがなに言おうが、検索世界最大シェアのGoogle検索で使われ続けるんだから
その時点でみんなが知らないうちに恩恵を受けてるし、Googleは帯域節約という実利を得てる。

普及しようがしまいが関係ないんだよ
Google検索でしか使われない独自形式であっても何もかなわない

WebP,Opusは普通に良いんだけど映像が・・・

Google儲かってるなら、HEVCとAACを買収してロイヤリティーフリーにすればいいのに

企業間特許の擦り合わせで誕生したHEVCとAACの買収なんて無理

ていうかHEVCの買収って要するにMPEG LAの買収と同義だろ
それができないからVP8開発して、MPEG LAからVP8やVP9に関する特許の許諾を貰う形になってんのに
本末転倒すぎる意見だわ

買収は無理だけど、Google謹製のH.264/265コーデック実装を作って
汎用ライブラリ的な形で各プラットフォーム用に配布する事は可能

元々一社当たりのMpegLAへの支払には上限規定が有るので、
枠の上限に達していると思われるMSやApple等の大手も同様の事が可能で
各社分担してそれぞれの自前のプラットフォーム分を負担すれば良いし
AndroidとLinux他のオープンソース系の「支払済みライブラリ」を
Googleが配布してカバーするというのはおそらく出来た筈だと思う

VP8に関する今回の合意もそれに近い形だしね

>VP8に関する今回の合意もそれに近い形
無知乙。全然別物だ。

>>588の言う方法では、「無償のソフトウェア」しか作れない。
MozillaとかGoogleがお題目に唱えているのは「自由なソフトウェア」だから、根本的に違う。
この二つの違い、日本語で一番わかりやすいのはWikipediaの「フリーソフトウェア」の項かな

やっと巻き添えアク禁解除…

>>589
>「無償のソフトウェア」しか作れない
>>588はロイヤリティ関連の話だよ？
VP8の「それに近い形」というのは自分の分だけでなく他者の分まで
幅広くカバーできるようにしたGoogleとMPEG LAとの契約形態のことを指してる

それにWebに必要とされてたのはロイヤリティフリー(RF)なコーデックであって、
それは必ずしもFLOSSで有る必要性は全く無い

>>588の言う方法は「自分の分だけでなく他者の分まで
幅広くカバーできるように」なってない

>>588程度が思いつく方法じゃ無理なんだって
だからGoogleは今回のような解決方法を取ったんだから

Googleの今回の解決方法は
彼らの当初思っていた形ではないけどな

>>587はその意味で間違ってるよ

つーかいつもの文盲気味なFLOSS狂信者君だろうから
付き合うのはパスさせてもらうわ

まともなツッコミなのにFLOSS狂信者というレッテル貼って逃げるだけ？
別にいいけど今後このスレで適当なデマまき散らすのはやめてくれよ

Googleが当初思ってた形かどうかは知らんが、現に今ではFLOSSで十分活用できる契約になったが
しかし>>588の方法では今ほどFLOSSで活用できないことは明らかだ

FLOSS狂信者って・・・
最初からオープンソースで活用するためのフォーマットだろ

どこがマトモな突っ込みだよ
他の人達が言っていた「Googleはお金の使い方間違えてんじゃね？」に対しての
フォローアップとしての意見追加が>>588だ
そこで問われているのはあくまでもロイアリティに関する事柄であって
>>589のフリーソフトウエアの定義云々は筋違いも良いところ
反論として明後日の方向だから文盲扱いされても当然だろうが

>>588はあくまで一つの方法論であって最善ではなかろうが
VP8に関する今回の合意は
やりようによって幅広いライセンス形態を引き出す事が可能な事を示しているんだから
お前の言い分の方が余程根拠薄いわ

デマというなら>>587のほうだろうよ

アホか。ロイヤリティ云々の問題も>>588の方法じゃ解決できねーってば
>>588の方法だとGoogleがライセンス買ったところでRedHatやCanonicalがコーデック開発したりできねーだろうが
結局各社毎にライセンス払わなきゃならん
>>588の方法とGoogleが取った方法が全然違うってのはそういうことだ


>VP8に関する今回の合意は
>やりようによって幅広いライセンス形態を引き出す事が可能な事を示しているんだから
詭弁すぎ。そもそも今回のは両社の合意であって、Googleがライセンスを買ったわけではないんだぞ
勘違いも甚だしいわ

今更十分に枯れた技術に対して新規コーデックを開発する必要性は薄いだろ？
x.264辺りの優秀なコードをベースにして主要プラットフォーム用のライブラリを整備して
その上でMoeg LAとの間でライセンス面をカバーするような契約を
結べば済む話でしか無いんだよ

「他所がコーデック開発出来ない」とかアホか
お前がFLOSS狂信者だからそういう突拍子も無い反論が出て来るんだよ

H.264は十分枯れた技術である、というのを否定はしないが
「だから新規コーデックを開発する必要がない」という主張はおかしいと気付けよ

今やスマホ全盛の時代でバンバン新しいハードウェアが出て
コーデックもどんどんプラットフォームごとに最適化が行われてるってのに
フリーの動画コーデックを完全にGoogle一社頼みにして、誰が嬉しいんだ
Google信者でさえ喜ばねーよ

HEVCがいいんでどっちもオワコン

>>599
>>588が気に入らないのは良く分かったが、そこまで拘泥されてもな
VP8の今回の契約が示す通り、OSSまでカバーする合意そのものは可能だから
お前さんが望む姿も提示金額次第では得られるだろう
お前さんに取ってはMPEG LAは悪の権化なのだろうが、
あれほど上手く現実世界で立ち回っている権利団体は他に無い

大体そこまでフリーソフトウエアの精神を尊重する立ち場なら
今回の合意とVPxの今後についてはもっと批判的になるべきだろ？

完全な意味でのロイヤリティフリー(RF)コーデックを目指しながらも
横槍が入って妥協の末の合意を強いられた今となっては
真の意味での「フリー」は既に失われてるとは思わないか？

私企業が支払を続けない限りそのRF状況は維持出来ないのだから
OSSとしてのコードの継続性が保証されたところで意味が無い
営利企業なのだから風向きが変わる事は当然有り得る

お前が頭が足りていないのは過去のやり取りで先刻承知だが
余りにも考えが甘過ぎる

>>599
>フリーの動画コーデックを完全にGoogle一社頼みにして、誰が嬉しいんだ
>Google信者でさえ喜ばねーよ

それはつまり今後WebM&VPxに期待するところは何も無いという事だな

何度も言うが>>588の言う方法ではフリーで開発できない。それをふまえて

>VP8の今回の契約が示す通り、OSSまでカバーする合意そのものは可能だから
可能かどうかは懐疑的だね
本当にH.264がFLOSSで開発できるようになる方法があれば大歓迎だけど
MPEG LAはそんな合意出さないだろうよ。それこそMPEG LAを買収するレベルの金を詰まなきゃ無理

>横槍が入って妥協の末の合意を強いられた今となっては
自由にどの企業もVP8を開発できるのに何を妥協したというの？
Googleはもしかすると金を払ったかもしれないし、それを妥協と言うならそうかもしれないが
お前の言う「FLOSS狂信者」にとっては何も問題ないんじゃね

>私企業が支払を続けない限りそのRF状況は維持出来ないのだから
どこからそんな話が出てきたんだ？
MPEG LAとGoogleとの合意について言えば、VP8のRF状況は永続的だよ
（Nokiaの例の件は除く）

いちいち突っ込みどころ満載の馬鹿な反論やめてくんねーかな
オツムが足りないのはどっちだよ

>>602
VPxは誰でも開発できることになってるよ
MozillaにもOperaにも開発できる

>>603
>MPEG LAとGoogleとの合意について言えば、VP8のRF状況は永続的だよ
根拠をplz

あのさぁ
Googleに対するMPEG LAの許諾が永続的じゃなかったら、
GoogleがW3CのRoyalty Free Licenseで公衆に対してVP8をライセンスした時点で
GoogleはMPEG LAとの合意に違反してることになるじゃねーか
それに対するツッコミがどこからも来ない時点で許諾が永続なことくらい自明だろ

だからオツムがたりねーんだよお前は

権利団体と包括的なライセンス契約を結ぶというのは
世間一般の常識においては相手を満足させる程度の支払を請け負う事と同義だろうよ

その合意内容の詳細が明らかにされていない以上お前の主張とこちらとの
どちらが正しいのかは断言出来ないが、普通に考えてお前の言ってる事は
相当突飛だと思うがな＞永続的だのなんだの

そもそもライセンスを認めるという事と
それが永続的かどうかは全く別の話だからな？

世間一般でも、金を払うだけがライセンス契約じゃねえ。クロスライセンスだって頻繁に結ばれてるだろうよ
GoogleはVP8に関する十分な量の特許を保有してると宣言してたんだし、金を払ったかどうかは怪しいね

相当突飛云々はお前個人の感想だろうから突っ込まないけど

>>608
それは全く別物だね。VP8の場合は両方満たしてるけど

>>609
>金を払ったかどうかは怪しいね
それこそ妄想だな
クロスライセンスは相互に利用可能な技術を持っている場合になされる物だから
特許で確立された権利者とそれを纏める団体に対して
一方的な侵害しか考えられない今回の場合に成り立つ訳無いだろ

>一方的な侵害しか考えられない
……お前何言ってんだ、ものすごく間抜けな主張だぞ
VP8の特許に関して少なからずMPEG側も侵害してたと考えるのがふつうだろ……
だからこそGoogleはあんなに強気だったんだし……もちろんハッタリの可能性もあるけど
少なくとも、一方的な侵害だけだったら簡単にVP8なんて潰されてたわ

お前の妄想はどうでも良いから根拠を示せよ

ごめん、ID:cCy3nQMEの主張が最終的にアホすぎて付き合うのばかばかしくなった
寝るわ

根拠もくそも、永続的な〜の根拠ならW3Cのライセンス条項9でも見とけ
じゃあのお休み

>>546の有り得ない失笑物の読み違えをして一人ではしゃいでたのはお前だろ？
お前が文盲であることと最低限の物事を理解して思考するに値する水準を満たしていないのは
このスレではお前自身の手で既に明らかになってるんだから諦めろ

>>612
Googleが当初の強気な姿勢を崩して包括ライセンスを結んだ時点で
そうでは無いのはそれこそ「自明」だよな
相変わらずの墓穴乙としか

>>615
正確に書け
RFに関するW3C Patent Policyの原文に条項9など存在していない
ttp://www.w3.org/Consortium/Patent-Policy-20040205/
そしてそれを口にするなら原文を全部ちゃんと嫁
それを行った後にならお前のような妄言は絶対に出ては来ない

付け加えるならば、W3Cが求めているのはRFで有ってFLOSSではない
動画やWebの世界はプロプラとOSSが共存して発展して来たのだから当然のこと

その意味でもお前の>>589以下のFLに拘泥した主張が如何に無意味な物かが分かるだろうよ

勝手に同一人物認定してはしゃいでたのかよｗ
ID:2XFy9i+L＝ID:LCai8AQvという意味不明な発想はどこから来たの
正しいかどうかは知らんけど、文盲っぷりから察するにID:cCy3nQME＝ID:LCai8AQv本人なんだろうな

文盲には理解できないのかもしれないけど
W3Cが求めてるものが何かなんて話はしてねーよ。あくまでVP8のライセンスがW3C RFライセンス（だから自由利用できる）って話なのに
なんでいきなりW3Cどうこうの話になってんだ。

正確に書かなかったのは悪いね。条項9ってのはこの部分だよ。ライセンス期限の話をしてるんだからふつうtermの部分読むだろ。
>License term:
>9. The RF license conforming to the requirements in 〜
全文を読んでもこれを否定する要素なんてひとっつも無いわけだがな

あと、Googleは別に強気な姿勢を崩してねーぞ。訴える訴える言ってたMPEG LAが最後に折れた形じゃねーか
MPEG LAが大好きなのは分かるけどちょっと頭悪すぎ

h264のパテントフリー化？は絶対無理でしょ
googleがどうにかvp9の特許問題を解決できたのは、対抗特許があったからでは

特許なんて気にせずにh264を使い続ける人はいるだろうけど
gifで痛い目を見た人たちもまだまだ現役だからなあ・・・

Apple,Adobe,Oracle,MS,MPEG-LA

こいつらのせいで一体何兆円の損失が生まれたのか。少なくとも誰も利益は得ていない

ISO/IECが標準化で儲けたでしょｗ

戦犯Oracle

これも全部ソフトウェア特許ってやつの仕業なんだ

>>620-621
ハードウェアメーカーはかなり助かってる
H.264・AAC・ついでにMP3の三つにだけ対応すればいいからな

>>620
問題はソフトウェア特許という制度でしょ

Software Patent is EVIL

帯域幅の節約と引き換えにする価値は？：FacebookがGoogleの「WebP」を実験的に採用したら……ユーザーの不満噴出
http://www.atmarkit.co.jp/ait/articles/1304/23/news102.html

うーん…ユーザ側のオプションで変更できるようにすればまだ混乱は生じなかったろうに

まだ本家googleが画像検索でJPEG使ってるような状態じゃなぁ。

ファイアーフォックスが今までMP3、AAC、H.264に今まで正式に対応して居なかった事が
驚きだ。いろんな意味でコーデック採用が遅れているのだな。

金かかるからねそれでWebM支持だったんだが・・・
Operaはどうなんだろ

>>630
無料ソフトなのにDLされる毎にライセンス料払わないといけないとかやってられないでしょ

MozillaはこのままJPEG 2000、JPEG XR、H.265にも対応してほしい

>>633
当然ライセンス料は全部てめえもちだぞ＞Mozilla

h265はMSかflash対応待ちなんだろうな

WMP13あたりでH.265とJPEG XRとドルビーTrueHD、DTS-HDに対応してきそう
JPEG 2000にはまだ対応しないだろうけど、デジタルシネマの事を考えたらいずれは
対応せざるを得まい

そんなの対応しないよｗ
ライセンス料無駄にかかるだけじゃん
必要な人はフリーや有料のツールを自分で入れればいいだけ

WMP13はMS規格のJPEG XRだけには対応してくるだろう、H.265はちょっと難しいかも？

よくわからんけど、
手元のwindows media player12でJPEG XRの画像を開いたら普通に表示されたけど
そういう話ではないのか。

>>639
その様子だとMotionJPEG XRの動画も再生できそうですね、WMP12で既に

MSがH.264をOSに標準で載せたのは7からで結構後だし
265も最初のうちは様子見じゃないかな

どのみち普及するのは確実だから時期の問題でしか無いけど

>>641
デコーダに関してはマシン負荷もそう上がるわけではないというし、
ライセンス料も大幅には変わらなさそうな雰囲気ではあるから、
そういう面での障害は少ないかな。

ただ、以前と違ってMSはOSに標準でCODEC載せることに積極的ではないからなぁ。
たとえばWindows8ではライセンス料の高いMPEG2のCODECは標準では載っていないし。

HTML5対応の全ブラウザに対応：OTOYとMozilla、プラグイン不要のJavaScriptライブラリ「ORBX.js」発表
http://www.atmarkit.co.jp/ait/articles/1305/07/news096.html

　ORBX.jsに含まれる独自開発のビデオコーデック「ORBX」により、HDビデオをJavaScriptにデコードして、
テレビ番組やクラウドゲーム、透かし技術入りの動画などをブラウザで再生することも可能。
H.264やFlash、Javaなどのプラグインは不要で、Firefox、Chrome、Opera、Safari、IE 10など、
HTML5対応の全ブラウザに対応する。

http://sourceforge.jp/magazine/13/05/08/151500

MozillaのCTO、Brendan Eich氏は、「圧縮効率はH.264と比べて25％改善する」と報告している。

JavaScript“に”デコードする……？

JavaScript+WebGLでデコードっすね

>>643
Webアプリ開発者がこのJavascriptを明示的に使うようにならないと
俺らには恩恵はこないなぁ

WebMの次期圧縮技術「VP9」、6月17日にコードフリーズ　YouTubeもサポートへ
http://www.itmedia.co.jp/news/articles/1305/13/news019.html

>>647
これは楽しみ。果たしてH.265やVC2と比べてどうかな？
上の方の人によるとMotion JPEG XRやMotion JPEG 2000はH.264にも
及ばないらしいので除外

http://headlines.yahoo.co.jp/hl?a=20130515-00000035-impress-sci
さすがは風見鶏のMozillaだH.264に正式に対応した。
ここには書いて無いけどMP3やAACにも正式対応するみたいだね。

WebM発表された当時はChromeにそれ期待してたんだよななぁ
MPEG-LAを札束でひっぱたける財力がGoogleにはあったわけだし
(まあVPxに口出ししないよう認めさせたのは別の意味でGJだったが)

風見鶏というならChromeがそれだよな
ChromeがH.264廃止するって言うし、AdobeがWebM対応するって言うからMozillaもしばらく頑張ってたのに
結局後発になってしまっただけという

http://gigazine.net/news/20130516-google-io-2013/
Googleは
H.264ｖｓVP9とかJPEGｖｓWebPの比較画像でドヤ顔しているけど
VP9の相手はH.265になるし、WebPの相手はJPEG XRかJPEG 2000になるんだけどな

いや普通にWebPはXRや2000より画質いいだろ。少なくとも8bit階調同士で比べたら。

webMもHEVCも円盤ソフトありきの画質上げるためのものじゃなくて
ネット動画のトラフィック抑え込むためのもんだから画質がどうこう言ってる奴はアホ

そんな建前言ったってエンドユーザは食いつかないし普及しないよ
結局トラフィックが減ることより容量当たりの画質のほうが大事

建前どおりエンドユーザーは飛びつくよｗ
今はスマフォやタブレットで携帯回線使いまくってる時代だ。
パケット通信量にはみんな敏感。

むしろ、ADSLや光で定額な時代より、従量課金や転送量制限のある今だから重要。

>>655
Webアプリ側がブラウザの対応状況を見て自動的にCODEC選ぶように
なるので、エンドユーザはCODECを意識しないんだよ。

ttp://jp.techcrunch.com/2013/05/18/20130517google-app-for-android-quietly-switched-to-webp-image-format-a-month-and-a-half-ago-saves-50-bandwidth/
FirefoxもWebP対応だそうだ

来年だと？

>>643
これ速度とかどうしてるのかと思ったらWebGLのシェーダーでデコードしてるんだな
その手があったのか

Are video codecs written in JavaScript really the future?
http://arstechnica.com/information-technology/2013/05/are-video-codecs-written-in-javascript-really-the-future/

電力効率悪そうだな

オーバーヘッド大きそうだ

>>643が何気に凄いんだが全然騒がれてないのが泣ける
Flash/H.264/AACにとって代わりそうなものなのに

主戦場のモバイルには向いてなさそうだからね

>>663
WebサイトやWebアプリ製作者がそのJavascript使わないといけないから

>>663
技術的には確かに面白そうだけど、
>>660の記事にも書かれてる通りでデメリットや問題点も山積み
”Challenges remain”以下を良く読むと良いよ

Using JavaScript for video is cool, but for most users, not using JavaScript for video will be better.
で締めてるけど、その通りだと思う

VP9とHTML5には早いとこ普及してほしいわ

確かに

足引っ張ってたIEがIE9以降、問題無くHTML5対応果たしたから、
残りはWinXPの残党だけなんだよな

VP9もHTML5もOpusも新しいニュースが全く来ないな・・・

VP9はやく・・・

ようつべにあるGoProというカメラのPVなんだけど
ttp://www.youtube.com/watch?v=3wbvpOIIBQA

1080pのファイルサイズがMP4は188.9MBだけどWebmだと200MBある
画質もWebm版の方が良いように見える

ようつべがWebmのビットレート優遇してくれるのかな?

WebmのダウンロードはGracemonkeyのYousable TubeFixというスクリプトを使うとできました

その動画、ChromeでYoutubeのHTML5試用版設定をオンにしてても
HTML5/webmで見れないのは何でだろ？
webmでDL出来るってことは用意はされてるってことの筈だが…

しかしGoProのデモ動画綺麗だね、目の保養になった

>>673を取り消し
Chrome30/HTML5/webmで無事見れた
しかも既に詳細情報でcodecs="vp9"だった

1080pはCore2Duo2GHzではスムーズに再生出来ない
ソフトウェアデコードにvp8の倍以上の負荷掛かる感じ
今のハードなら余裕だろうが数年前(Corei以前）のだと厳しいかも

本題に戻ると、>>672が落としたwebmがvp9なら、
コーデック技術の世代が違うから画質が違う、という当たり前のことかもね

色々と試してみたけど、今はYoutubeの変革期なのかな?
>>672の時点ではWebmの1080pのDLできたけど、今はできない
ちなみにダウンロードできたのはVP8でした

機能まではChromiumｄでアクセスするとVP9を見られたけど、
今日はVP8で再生される


画像と音声込みの総合ビットレートは
MP4 188MB・・・5644.6kbps
VP8 200MB・・・5992.1kbps

となってて、VP8は絵が止まってる時はMP4よりも綺麗に見れた
動くとH.264の方が破綻が少ない感じがする

それで、今日になってVP9の再生ができなくなったので
ダウンロードできないか色々やってみた

ようつべのページに行き、ソースを表示させて「codecs%3D%22」で検索すると
映像だけ、音声だけ、映像+音声の動画がそれぞれ分けられて記述されているはず

残念ながら映像+音声の「vp8.0+vorbis」「avc1+mp4a」となっているものは
これから紹介する方法ではダウンロードが上手く行かなかった

映像だけの記述は
「avc1」、「vp9」、「avc1」の順になっていて、その後のsize=に解像度が書かれているのが分かると思う
最初のavc1は何とHighプロファイルのH.264
次がVP9
最後のavc1が今まで通りのMainプロファイルのH.264

ダウンロードは、url=の後の「http〜」コピーしていく
どこまでコピーするかは、「\u0026type=」「,type=」「,init=」の手前までと
俺が試してみた限り3通りあるように思える

メモ帳とかにその超長いURLもどきを貼り付けて、
%3A → :
%2F → /
%3F → ?
%3D → =
%26 → &
%252C → ,
と置換して本当のURLにする
これをブラウザに貼り付ければ映像ファイルがダウンロードできる
オーディオはmp4aとvorbisが並んでて、同じようにしてダウンロード出来る

ただ、これでダウンロードしても何かヘッダが足りないのか普通に再生はできない
VP9はデコーダも無いしね
そこでffmpegの出番となる

ttp://ffmpeg.zeranoe.com/builds/

↑からffmpegのバイナリをダウンロードする
ffplay.exeはffmpegを使用した動画再生ソフトで、これにファイルを投げると再生できる
でもVP9デコーダが駄目でCPU使用率が高くならずにカクカクなって再生には使えない

結局VP9の画質を見るにはffmpegを使って可逆圧縮するしかない
ffmpeg -i VP9.webm -vcodec huffyuv 出力.avi
でできる


それでVP9を見てみると画質は圧倒的に綺麗
ノイズが格段に減ってて非常に良い

上の方法で拾った映像のみ、音声のみのファイルはヘッダが壊れてて
普通のプレーヤーで再生できないのでffmpegでヘッダを作ってもらう

ffmpeg -i <入力ファイル> -vcodec copy <出力ファイル>


HighプロファイルのH.264はこうやってダウンロードした音声と結合できる

ffmpeg -i Highprofile.mp4 -vcodec copy -i audio.mp4 -acodec copy 出力.mp4

これで再生できるようになるけど、ビットレート下がってるからHighプロファイルでも画質は良くなってない

>>672から映像だけダウンロードするとこうなってる

H.264 Mainプロファイル 181MB・・・5425.3kbps
H.264 Highプロファイル 125MB・・・3765.3kbps
VP9 120MB・・・3615.7kbps

従来のH.264 Mainに対して、Highプロファイルはビットレートを落としすぎて
画質が向上するどころか低下している場合もある
(>>672の動画だったら1:00〜1:10で分かりやすいと思う)

VP9の方は画質は非常に良くてさすが次世代コーデックという印象
早く単体デコーダの公開が望まれる


しかしようつべがHighプロファイルを用意したのはサーバーの転送容量の
負荷の削減のためだろうか
画質悪くなってるんだからもうちょっとビットレート上げてもらわないと・・・

>>675-678
なるほど、報告乙でした

個人的にはVP8と9の性能比較に興味有るかな
9の再生負荷が現状で高いのは仕方ないとして、
ホントに半分程度のビットレートで同等の画質を出せてるのか、とか

あとヘッダの不足等の状態では駄目かも知れないけど、
Chrome/ChromiumへのD&Dでも.webm形式のvp9を再生出来る筈なので
もしかするとチューニングの関係等でその方が軽いかも(CPUを上限付近まで使えるっぽい）

>>679
Chromeに放り込んだら再生出来ました!
ヘッダの作り替えも必要なくてダウンロードしたものをそのままで大丈夫です

でもffplayと同じく、デコーダがCPUを使いきってくれなくて
30〜40%で再生がノロノロになる状態でした

100%使いきってないのでどのくらい重いのかは分からないけど
>>672の動画ではVP9が一番画質良く
VP8の5.8Mbpsに対してVP9の3.6Mbpsの方が上だと言えますね
同等ではなく、上回ってます

画質良好ですか

デコーダのチューニングが進めば期待出来そうですね

Webp対抗規格としてHEVC-MSPもある

VP9 encoder is 20x times slower than VP8 !!!
ttp://comments.gmane.org/gmane.comp.multimedia.webm.devel/1827
ffmpegで無圧縮のy4m作って
vpxencでエンコ
ttp://x264.fushizen.eu/builds/vpx/
自力でビルドしてもいいけど
x265より遅いんじゃないかな

米CiscoがH.264コーデックのオープンソース化を計画〜米Mozillaも支持を表明
http://internet.watch.impress.co.jp/docs/news/20131031_621671.html

　Ciscoの発表によると、CiscoによるH.264実装の1つである「gratis」をオープンソース化すると同時に、
そのソースコードからコンパイルされたモジュールをCiscoにホスティングし、ダウンロードできるようにするとしている。
これに伴うMPEG LAへの特許料支払いは、Ciscoが負担する。

問題はMPEG-LAがそれを認めるかどうかだよなあ
MPEG-LAが駄目って言っただけでポシャる計画だし

形態としてはOSにH.264のライブラリを載せて
アプリから使える様にするのとさほど差は無いように思う

かつてGoogleがこうすれば良いのにと思ってた頃も有ったな
一社辺りの支払上限とかあるから

>>685
え、認めるって何？
お金払ってもダメとか言うの？

えーと、問題点が理解できてない奴らが多そうだから整理すると

・Ciscoがライセンス料を払うのは自社のバイナリに対してのみ
・Ciscoのバイナリを使う場合のみMPEG LAへのライセンス料は免除される。
・Ciscoが開発したコーデックのソースコードは公開される。
・公開されたソースコードを自前でビルドすることはできる。
・でも自前ビルドのコーデックを商用に使ったり頒布する場合はMPEG-LAに対してライセンス料を各自が支払わないといけない

というわけで、あくまで「ソースコードが公開されてるだけ」で全然自由に使えるソフトウェアじゃない。
Debianなんかのディストリだと、まず間違いなく公式リポジトリには含まれないだろうね。

>>687
当たり前だろ。ライセンス契約なんだから、100万円払いますと言ったところでMPEG LAが売らないと言えば終わり。
上に書いてるように穴が多い上に誤解も招きやすい計画だから、無事に進むかどうかは疑問だね

むしろMPEG-LAは断固拒絶してほしい
そのプライドに賭けて訴訟でも何でもして潰してほしいわ

>>687
名の通った大手企業が事前の話し合い無しに突然行ったとも思えんし、
支払滞らない限りはまず大丈夫じゃないの
Mpeg-LAってああ見えてかなり柔軟な対応する組織で
取れるところから金取るって主義だし

>>688
>・Ciscoのバイナリを使う場合のみMPEG LAへのライセンス料は免除される。
そもそもこの利用形態を前提にしたプランでしょ

>>684
これ。
このニュースを見て、真っ先にこのスレッドを思い出した。

>>691
>>588のこういう方法も有るんじゃないか？が実現したね
（グーグルじゃなく他社でだけど）
Linux版のAdobe Flashは10.2で開発が止まってるから、
Firefox/HTML5/h.264で見る事が出来るのは歓迎かな

>>692
同時に>>589以下で言われてるようなCiscoへのツッコミがLinux板のあちこちで出てるな（当然だが）

それって主に君が書き回ってるんじゃなくて？w

自由なコーデックであるべくMozillaがDaalaを作ってるから
そっちに期待するんだ
それまではタダで使えるH.264に甘んじるべし

過渡期であることをみんな理解していれば、デファクト・スタンダードになってくれるだけで助かる。

>>695
わざわざDaalaを待たずとも今自由に使えるVP8/VP9があるんだから
H.264を使わないといけない理由はないぞ

普及度合い、特にハードウェアデコーダーの搭載率で現行世代はH.264の圧勝
CiscoとMozillaの動きもそれに合わせただけ

また再スタートになる次世代で頑張るしか無かろう
VP8は惨敗だったがVP9には期待してる

今のところ糞重いけどな！w

nokiaが侵害リストがどうの言ってたのはどうなったの？

MSの説得で諦めたと想像

H.265
VP9
VC2
VC3
Daala
motionJPEG XR
motionJPEG 2000

7つの動画コーデックの戦いが始まる・・・・
果たして最も性能が高いのは？そして、一番普及するのは？

再生負荷の軽さでH.265でしょう
Daalaは出たらそこそこ普及はしそう

その7つからH.265だけ挙げて再生負荷が軽いと言い切るそのいい加減さは見習いたい
ベンチマークのベの字も知らないんだろうな

VP9信者乙
ソデにされて怒っちゃったの?


ちなみにハナから下4つは相手してません
VC2
VC3
motionJPEG XR
motionJPEG 2000

解像度やフレームレートによって負荷度が左右されるという現実

JPEG 2000はデジタルシネマでやってろ

H.265ブラウザは対応するかもしれんがyoutubeが対応するかは未知数だし・・・
そろそろクライアントじゃなく鯖側でエンコするのが主流になっていいと思うわ。

こういうので覇権を握るのは、性能ではなく支持率。

>>702はH.265ハードウェアデコーダの普及を見越しての意見だと思われ
（実質それで全て決まる）

VP9の命運もおそらくそれで決まる
さもなくば（これまで通り）つべ専用コーデックの扱いになる

H.265の再生負荷は軽い
軽いと思う
軽いんじゃないかな
ただし根拠はない

divxでデコード負荷は載ってた気はするが。
CherryTrailでVP8のハードデコード対応とハードウェアエンコーダはH.264とVP 8に対応らしいね

ttp://blog.livedoor.jp/abars/archives/52166489.html

デコーダは、マクロブロックライン単位のスレッド並列デコードが可能になったのと、
デブロッキングフィルタの演算負荷が削減された関係で、H.264と同等か、むしろ高速にデコードできるようです。

Docomoは、HEVC復号ソフトウェアにおいて、以下のような驚異的なデコード性能を出しています。

本復号ソフトウェアにて、スマートフォン上でHEVCのフルHD動画、汎用パソコン上で秒60コマの4K動画の再生が実証されています。

>>709
一世を風靡したYoutubeをH.265陣営が押しつぶす決定的瞬間が今から楽しみだな
俺らがYoutubeを壊滅させるんだぜ、武者震いが止まらんわ

こいつ何言ってるの

Divxのだとi7でも4k再生は30fps切ってたんじゃなかったっけかDocomoがすごいのか
汎用パソコンが超性能なのかどっちなんだろ

Windows 7 with i7 CPU, 3.5GHz
1080p 101.5　Average fps
4K　29.6
http://labs.divx.com/node/127935
検索したら簡単に見つかったんで一応はっておく

betaとVHS、HD DVDとBDのように規格争いに終始して消費者が混乱する状況はなるべく避けて欲しい。

FLASHに依存しない現状の路線で「コーデックは自由」くらいでいいのでは。

Vp9 vs H.264
http://digitalstudio7.blogspot.jp/2013/11/vp9-vs-h264.html

VP8はXvidの代替のようなもん？画質的に

いや、Xvidは明らかに超えてるよ
h264の1歩手前くらいの画質。
1Mbps以上でh264に比べて画質面で不満を感じることは無いんじゃないか
低ビットレートではH264のほうが明らかに優位だがね。

今度はVP8 vs VP9とかやらないかな

Kaveri以降のAPU＋GCNアーキテクチャのビデオカードの組み合わせだけでも
CPU+ビデオカードをフルに使ったエンコードができるようになればいいなあ

Xeon Phiの廉価版が24800円で出たらそんなことは一切考えなくてもいいんだけど出ないだろうしなあ

ffmpeg使ってVP8のエンコをいろいろテストしてみたんだけど、
4コアCPUでCPU使用率が各コア50%くらいしかいかないんだが、そういうものなのか？

エンコのパラメータもx264と違って意味不明すぎるしな・・・
-crfは全然効いてないみたいだし、-cpu-usedも意味わからん

https://trac.ffmpeg.org/wiki/vpxEncodingGuide
こちらを参考に

そこは当然見てますよ
他にも
https://sites.google.com/a/webmproject.org/wiki/ffmpeg
http://www.webmproject.org/docs/encoder-parameters/
等見てますが、どうもオプション説明の記述が安定してない

・bitrateとcrfを同時使用してるが、どんな意味があるのか
・-qualityや-deadlineと、-cpu-usedの指定にどんな意味があるのか

さっぱりわかりません

あ、それと
-speedオプションも意味不明ですね

x264のエンコは慣れてるしオプションの意味もわかるんですけどねぇ

少し前にVP9のデコードを報告してた人もCPU負荷上がらないと言ってたな

Google傘下のYoutubeもH.264のほうがずっと多いまま
Linux/Chrome/HTML5で観ても同様
旗ふり役からしてさっぱり力入ってないっぽい

VP8エンコのオプションが訳わかめなのは最初からだけど、
改良が進まないのは利用者が少なくてフィードバックが少ないせいだと思うよ

取り敢えずフォーラム辺りで愚痴って来たら？w

方々のWeb見つつ、試行錯誤していくつかわかったこと

・-crfと-bitrateを両方記述した時は、
　その瞬間瞬間で-bitrabeを超えない範囲で、-crfが効くことが判明。
　なのでサンプルにあるように-crf 10 -b:v 1Mと記述すると、
　まず間違いなく1Mbpsに張り付く動画が出来上がる
　なんなのこのサンプル、意味ないｗｗｗ

・-threads 0は機能していない。スレッド数を数字で指定すれば効く
　これでCPU負荷は90%くらいまで上げられた

・-quality bestと、-quality good -cpu-used 0 は、ほぼ同じ画質＆サイズになるが、
　エンコ速度は後者が30%は早い

なるほど

Zeranoe FFmpeg buildsにVP9エンコーダがexperimentalだけど入ったね
早速試してみたが、さすがにきれいだ。遅いけど。

>>728
ビットレートも何も指定せずにやったら200kbpsでエンコし始めたんだが…

VP9はシークに時間が掛かるよ〜

webpの可逆圧縮、なんでこんなに縮むんだろ
色の間引きもないみたいだしすごいな

前ちょっと調べた時は、PNGのアルゴリズムの改良版的な印象だったな。
写真の可逆圧縮に特化した画像形式には圧縮率負けてたし。
まぁほぼすべての画像でPNGより縮むから実用上問題はないのだろうけど。

＞写真の可逆圧縮に特化した画像形式
それ教えて。JPEG2000とも違うの？

Jpeg2000は不可逆圧縮だよ

PNGGauntletの強化版を使ってるようなモノと捉えればいいのかな
グラデーション多い画像に強い、っていうのもちょっと納得。
JPEG2000のロスレスよりデコード速いし、普及してGUIの一括変換ソフトが増えてくれるといいな

>>734
ここの上位陣とか。
ttp://www.imagecompression.info/gralic/
まぁ研究用みたいなもんで実用できるものじゃないよ。

画像の世界がbmp、Jpg、gifで長期停滞してようやくPNGが市民権得てきた間に、
動画の世界ではH264が制して、更に次世代のH265、VP9、Daalaとか出てきてる

で、動画の圧縮には必ず静止画の可逆圧縮がIピクチャとして使われるので
可逆圧縮という点では動画側のほうが技術革新が進んだ

WebPはVP8のIピクチャ部分の技術を抜き出しただけだからな

なるほどな

VP8のエンコデコードともopencl版あるようだ
ttp://wiki.webmproject.org/vp8-implementations
VP9に対応してデコードをブラウザに組み込めたら割と面白い存在になりそうではある。
Firefoxも28だったかなでVP9対応って話は聞いた

Google、モバイル版Chromeのデータ圧縮機能を公式にリリース―データ量を最大50%節減
http://jp.techcrunch.com/2014/01/16/20140115google-adds-optional-data-compression-feature-to-chrome-for-mobile-reducing-your-data-usage-by-up-to-50/

＞ユーザーがChromeのデータ圧縮/最適化オプションをオンにすると、Android版でもiOS版でも、
＞最大で50％もデータ量を削減できるという。
＞前に述べたように、PageSpeedライブラリーを利用して画像ファイルをJPEGやPNGから
＞GoogleのWebPフォーマットに変換するだけでも大きな効果がある。
＞というのはウェブページでは平均してデータ転送量の60%が画像だからだ。

OperaのOpera Turboの丸パクリやな

Opera Turboも、画像フォーマットにWebP使ってるんやで

Intel, NVIDIA, ARM, Broadcom, LG, Philips, Samsung,
and Realtek are among the many companies that have agreed to incorporate VP9 codec support
割といい感じではあるがAMDがねぇw
265はブラウザ対応遅れるだろうからこっちのほうが早いだろうけど
エンコ周り265と比べて遅れてるのが気になるが・・・

利用自由なHSAがあるんだから、HSAを使ったVPデコーダエンコーダを誰かが作ればいいだけ。
VP9を普及させたいGoogleの役目だろう

Googleにやる気を感じないのは気のせいか？
VP8の改良も実質他所任せだったし

VP8って、２年２回の大幅アップデートでx264に迫るとか言ってたのに
全然アップデートしなくなって久しい。

ARM Mali T604でVP9でもopenclでデコードできるようだ

モバイルでのGPGPUは消費電力的に動画のエンコードやデコードに向いてないよ
GPUは浮動小数点演算器の塊だが最新のコーデックは整数演算しか使わない

現行機種がopenclに対応してるのか
ハードデコードは対応してないだろうけど
そこらの按配だろうね

MulticoreWare Accelerates VP9, Google’s Next-Generation Open Video Codec
http://www.prweb.com/releases/2014/02/prweb11612574.htm
openclでのデコードらしい
Android用っぽいけど

無意味

webp形式とか馬鹿じゃね？
まず拡張子の法則通り３文字にまとめて出直せ
グーグル調子乗りすぎ

.htmlを認めない方でしたか。

>>748
長大なレジスタを分割して、複数の値を一括で処理できるのがベクトル命令の売りで、
それが整数だろうが浮動小数点だろうが関係ないんだけど。

>>752
.z .gz .c .pl .py .sh…

拡張子はそれよりも、パレットカラーなのかフルカラーなのか、静止画なのか動画なのか、可逆圧縮なのか非可逆圧縮なのか、αchがあるのか無いのか、
を拡張子で明示してほしい(´・ω・`)

>>755
MPC-BEではWebP lossless ということでwebpllの拡張子をつけてるな

>>123
おいおい…自分と違う考えを持つ奴はみんなアトムの回し者ですか？
まず、自分が今ヒステリックになってる事をきちんと理解して落ち着け。

>過ぎたるは猶及ばざるが如しって諺知らない馬鹿だな！！
全然過ぎたことじゃない。相談窓口に連絡するというのは、ごく当たり前のことだよ。
アプリでも、不具合が起きたら、調べられる程度の状況を調査してバグレポート書いて送信するだろ？全然日常的なことだろ。
それに、今回の場合明らかに接客に問題があったんだろ？それなら問題があったことをきちんと教えてあげたほうがいいよね。
そもそも、テーブルにアンケート用紙を置くくらいなんだから、そういった不満があったことをアトムは普段から知りたがってるわけじゃない？
そうした、問題が起きたことを認識させることで、再発防止のためにマニュアルの修正や、問題店舗の改善・指導を行うことが出来る。
これは、ここに愚痴をこぼす事より、よっぽど生産的なことだと思うのですが、どうでしょう？

あと、ここに書き込むのと同じノリで、店員にもヒステリックに食って掛かったら、大抵のやつはビビってパニクるぞ。
ちょっと煽った文章にしただけで、3レス連続で書き込むくらいだから、普段からキレる癖ついてるだろ。注意した方がいいよ

長文誤爆したorz むちゃくちゃ恥ずかしい、穴があったら入れたい

WEBPへの一括変換でいいソフトなイカな
いまんとこIrfanView（但しサブフォルダ階層には未対応）くらい？

ImageMagic使えば
>convert image.jpg image.webp
>mogrify -format webp *.jpg
とかで変換できる

一番重要なVP9が一番遅れている

普及しないな

mp4で間に合ってるし。

>>763
とは言っても、ちょっと定番から外れたことしようと思うとmp4はとたんに使いにくくなってマトリョーシカ使いたくなる
mp4にhevc入れると、mpc-beでは再生できないし。これは時間の問題だけどさ

仕事で社内webシステムに動画を配置することがあったんですが、
最初mp4だったのが「再生出来ない」という問い合わせ多数で結局wmvになった。
業務用はIEとWindowsしか使わないから。

すべてのmp4というわけではないけど、Google Chrome単体でmp4が再生出来ることを初めて知った。

IEは10なん？違うの？

>>765
Winも7ならシステム標準でH.264なmp4を再生出来たような

VP8なWebMもMF用のデコーダーさえ有ればIEで再生できるんだっけ

W杯のゴールシーンをgifじゃなくてwebmにしてるのを見かける
サイズがでか過ぎるgifの代わりとして普及してくれるとありがたい

HTML5のvideoタグでautoplayとloopを記述すればgif感覚で使えるのかな

と思ったらTwitterがgif対応としてmp4にエンコードして>>770してた

http://jp.techcrunch.com/2014/06/20/20140619facebook-for-android/

＞Android版Facebookアプリのデータ効率をできるだけ高くするために、
＞同社は異なる画像圧縮技術を試し、WebPに切り替えることを決めた。

>>772
あれ？評判悪いんで、辞めましたって話無かったっけ？
ちなみに現状だとアップロード、つまり読み込みすら対応してない

>>772-773
ttp://japan.cnet.com/news/commentary/35031278/
過去に一回導入に失敗してるけど、再トライするっぽいね
ttps://code.facebook.com/posts/485459238254631/improving-facebook-on-android/
取り敢えずはアンドロイド向け限定の様子

ttp://html5experts.jp/jxck/2550/
JPEGとwebpの比較
PC上のChromeで閲覧してみたけど、結構良いね

なぜかどこも大変良い出来のWebPとOpusを採用しないなあ
携帯電話、デジカメ、小型音楽プレーヤー、テレビ、デジタルラジオ辺りに使えそうだけど

919 名前：名無しさん＠編集中[sage] 投稿日：2014/07/07(月) 12:34:13.09 ID:zm/1emx0
【速報】YoutubeのWebMの中身がVP9になっとる

920 名前：名無しさん＠編集中[sage] 投稿日：2014/07/07(月) 14:49:03.51 ID:J8aZHzYg
速報というほどでもないかと。5月頃から順次VP9に切り替わってましたよ。
対応OSとブラウザで再生時に右クリックで詳細統計情報を開くと
その動画がCodecにVP9を使ってるかどうか確認出来ます。

遅い
とっくに知ってる

嘘だね
5月ごろの過去ログ見てもそんな記述ないし

5月どころか去年10月には始まってたし
>>672以降でやり取り有る通りだよ

前から変化があるわけではないな。
FirefoxもVP9対応したけどyoutubeでの再生は難有っていうかconfigいじらないとできないのな。

FirefoxのMediaSourceExtensionsはまだ難ありと言うかyoutubeに対応してないと言うかそんな感じ。だからデフォルトではMSEオフ。

ffmpagでVP9のエンコをいろいろ試してるんだけれど、
パラメーターの意味がさっぱりわかんないね
bitrateとcrfはいいとして、quality、speed、cpu-usedってなんじゃ
まともに解説してるサイトも無いしなぁ

あと、4コアCPU使っているけど、どうやってもCPU負荷30-40%くらいにしかならない
全コア平等に使われているようだが、全コア空いてる状態
何なんだこれ

Google主導の割には、情報が少なすぎてなんとも
本当にやる気あるのか

クラウドの多CPUをフル回転してなるべく速くエンコしたいはずなのに、
こんなにマルチスレッド化が遅れてるようなエンコーダーをGoogleがほ
んとに使ってるのかね？
何か設定間違えてるのかな

実際に運用するときにはファイル単位で並列化してるようなもんだし
下手にマルチスレッドに最適化して、圧縮率を犠牲にするより良いんじゃね？
まあ、単純に開発が進んでないだけな気もするけどね

>>782
>>723-728の（VP8での）オプション設定の方法は参考になったりしない？

>>783
いままで20点だった画質がやっと50点になったってだけで、所詮再エンコのクソ画質だし
やる気ないんじゃね？
再エンコなしのh.264にはまったく歯がたたないし

YouTubeってH.264でも問答無用で再エンコしてると思ってた

再エンコ無しってFC2（2chのFC2スレ以外にソース無し）とニコニコしかないんじゃないの
なぜか海外の動画サイトは問答無用で再エンコするのな

今のYoutubeは1ファイル20GBまでアップロードできるから
H.264 lossless/リニアPCMで編集してそのまま上げれば再エンコ無いんやで(にっこり)

いや、その20GBを俺らは見れないわけでｗ
せいぜい数Mbpsに再エンコされた動画をストリーミングで見てるんだよ

もっとも、Youtube側がエンコーダーの仕様やエンコーダーそのものを入れ替えた時、
もとの20GBから再エンコされるという強みはあるけどね

ニコニコ動画なんかだとユーザーが再生環境の事考えてないようなすごい設定で投稿してることもあるから
Youtubeみたいに動画サイト側で一律の設定でエンコードするのは妥当といえば妥当かと。

汎用性の高いPCならともかく、
仕様決めうちであとから変更しにくいネット機能付きTVやSTBとかで観る場合なんかは
一律設定の方が都合良いからね

2GB以上ある元の1080pゲーム動画と、VP9変換後のもの(約600MB）を比較したら
見るに耐えないレベルだったw
ほぼ720p以下相当の画質まで落ちてるわ

>>794
比較の仕方がおかしい
同ビットレートのH.265、H.264とVP9を比較するか
元の動画とエンコード後の動画を比べて、違いを認識できるビットレートを調べるとかならわかるが

非可逆でエンコかけたら画質が落ちましたって言われても

>>795
ただ単に上のレスからの流れで、Youtubeにアップする前とYoutubeで再エンコされたVP9の比較しただけ。
VP9がクソといってるわけじゃないっす。スマソ

そもそもYoutubeが高画質だったことなど無いわけで。
常に速度優先のクソ設定でエンコしてくれるからな。

よううつべでVP9が普及してWebPもバージョンアップしてくれると良いな

WebPはGoogle検索や画像検索に勝手に使われてどんどんVerUpしてるし
VP9もYoutubeに勝手に使われてどんどん鍛えられてってるね

ついでにPicasa/Google+の写真もWebPに自動変換して欲しい

Chromeで画像検索した時の表示が軒並みJPGなんだが、webp用に何かの設定が居るの？

>>800
ダウンサンプリングせず4:4:4変換になってくれたら同意

AviUtlのL-SMASH Worksという入力プラグインの動作を調べていた過程で、WebMについて
いくつか疑問が出てきたのですが、詳しい方がいたらわかる部分だけでも教えていただけないでしょうか。

　１．YoutubeのVP8のWebMについて
　　　１−１．mkvinfoで見ると、コンテナの「デフォルトのフレーム持続期間（DefaultDuration）」が
　　　　　　　　1msに設定されているせいか、真空波動研などは1000fpsと判定してしまうようです。
　　　　　　　　なぜYoutubeではこのような設定がされているのでしょうか？
　　　１−２．mkvextractでタイムコードv2を抜き出してみると、複数のタイムコード重複が見られます。
　　　　　　　　おそらくはAltRefフレームのタイムコードが他のフレームと重複しているのだろうと
　　　　　　　　推測していますが、これは正しいでしょうか？
　　　１−３．１−２に関連しますが、ffmpegもVP8で -auto-alt-ref 1 の場合は重複タイムコードがつきます。
　　　　　　　　しかし、vpxencの場合は重複しないようになっています。
　　　　　　　　　　　ttp://www.webmproject.org/docs/container/#vp8-alternate-reference-frames
　　　　　　　　を見ると重複させないことが望ましい（タイムベースの粒度が荒い場合は重複可？）ように
　　　　　　　　読み取れるのですが、重複させることに問題は無いのでしょうか？

　２．AltRefが有効なVP9-WebMについて
　　　２−１．AltRefが有効なVP8-WebMの場合、mkvextract timecodes_v2でタイムコードv2を取ると、
　　　　　　　　本来のフレーム数にAltRefフレームを足した数のタイムコードが取れますが、
　　　　　　　　AltRefが有効なVP9-WebMの場合は、本来のフレーム数分のタイムコードだけが取れます。
　　　　　　　　　　　ttps://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/hQAGZeKQK-E
　　　　　　　　を見ると、VP9のAltRefフレームの扱いはVP8とは変わっているようなのですが、
　　　　　　　　VP9-WebMでは「AltRefフレームのタイムコードはmkvextractでは取れない」というのが仕様なのでしょうか？
　　　２−２．２−１に関連しますが、YoutubeのVP9-WebMをffmpegで
　　　　　　　　　　　ffmpeg.exe -i YoutubeVP9.webm -c:v copy RemuxVP9.webm
　　　　　　　　として素通しで再muxし、mkvextractでRemuxVP9.webmからタイムコードを取ると、
　　　　　　　　YoutubeVp9.webmから取った時と異なり、VP8と同様に本来のフレーム数に
　　　　　　　　AltRefフレームを足した数のタイムコードが取れます。
　　　　　　　　このffmpegの再Muxの挙動は、VP9のWebMのMux仕様として正しい挙動なのでしょうか？
　　　２−３．Mkvtoolnix 7.2.0のmmg.exeで、「WebMの規格に準拠したファイルを作成する」にチェックを入れると、
　　　　　　　　「このトラックはWebMと互換性がないため、有効化することはできません。」と言われ、
　　　　　　　　VP9のトラックがMuxできなくなります。MkvtoolnixはまだVP9のWebM準拠Muxに対応していないのでしょうか？
　　　２−４．VP9のWebM-Mux仕様について、解説しているページなどがありましたら教えていただけないでしょうか？

上記プラグインの調査報告に使ったものですが、サンプルファイル等はこちらにまとめています。（76MB。10月末に消えます。）
　　ttp://www1.axfc.net/u/3340179?key=aviutl

よろしくお願いいたします。

Firefox33がリリースされ、CiscoのOpenH264をサポート。

　　OpenH264 Now in Firefox | Andreas Gal
　　ttp://andreasgal.com/2014/10/14/openh264-now-in-firefox/

　　>Mozilla continues to support the VP8 video format,
　　>but we feel that VP8 has failed to gain sufficient adoption to replace H.264.
　　（MozillaはVP8のサポートを継続するが、VP8はH.264を置き換えるには至らなかった）

まあ今更だけど・・・。

そういえばFirefoxでYoutube(HTML5)を見るとVP8で再生されるんだけど、
VP9の対応はまだなんだっけか

このスレ検索がググれ

vp9が出てきたらwebpもそれベースのやつになるのかな。
それとも違う規格として出直すのかな。

about:configでmedia.mediasource.enabledをtrueに変えたら良いみたいね

>>808
やめとけ。更新されたばかりのFirefox33で試してみたけど、状況は>>780-781と同じでまともに動かない。
シークで反応しなくなったり、Firefoxのプロセスが残りっぱなしになって
タスクマネージャーからの強制終了が必要になったりする。

>>809
了解。元々不完全だからデフォで有効化されていないのだろうし、
まだ当面は待った方が良さそうだね。アドバイスサンキュー

VP9が見たいならChome使ってHTML5プレイヤーをenableにしろ
動画のほとんどがVP9だ

それは知ってる

今更ドヤ顔で言うこっちゃないな。

ARM、ハイエンド向けGPUのMali-T860などを発表
ttp://pc.watch.impress.co.jp/docs/news/20141031_673992.html
ttp://www.arm.com/ja/products/multimedia/mali-video/mali-v550.php
VP9無いん？

まあ、jpeg xrとかjpeg 2000もないみたいだしよく使われている奴だけ
対応してるって感じじゃないの。vp8には対応してるのにね。
普及してない無駄な回路を積めるほどの余裕は今のarmにはないって感じなのかな。

Fx36：VP8ビデオコーデックを用いたWebM形式の動画を再生する際、Intel CPUの動画再生支援機能を利用できるようになったようだ。
ttps://twitter.com/rockridge07/status/538707853641396225

モバイル向けはVP8ハードデコードサポートしてるようだね

仕事でwebmファイル使うようになったよ。
PC用がmp4、Android用がwebm。

>>816
VP8なんて誰も使ってないのに。
Youtubeで使われてるのもVP9だし。

Chromeは9だろうけどFirefoxはまだ8だな
IEは対応してるかどうか不明だけど

>>818-819
YoutubeはVP8の動画も生成してるけど、FirefoxでもChromeでも使われてない。
使われることってあるのかな？

IEはWebM(VP8,VP9)には対応してない。IE用のWebMプラグインはあったが
放置されてるっぽいし、試してはいないがVP9は再生できないような気がする。

　　The WebM Project | WebM Components for IE
　　http://www.webmproject.org/ie/

　
アニメーションWebPとアニメーションPNGに対応した「FFmpeg 2.5」が公開 - 窓の杜
http://www.forest.impress.co.jp/docs/news/20141211_679903.html

>>820
FirefoxでHTML5優先＋MSEを有効化してない時（デフォ状態）ではVP8で再生されるよ

>>823
Win8.1＋Firefox34.0だけど、VP8は使われてないよ。
360pで右クリックから詳細統計情報を見るとAVC（MP4）になってる。

ミスってら。>>823は>>822宛。

MSEオフだとVP8だったわ同じ環境だが

デフォがオンに代わってて264使うように変わってるのか。
36でオンになるとみたからまだだと思ってたわ
VP捨てたんかな

>>825-826
いや、34.0ではまだMSEはデフォでOFFでしょ。
　　ttps://www.youtube.com/html5
で、「HTMLVideoElement」「H.264」「WebM VP8」の３つだけ青チェック、
「Media Source Extensions」「MSE & H.264」「MSE & WebM VP9」は「！」という
デフォのMSEオフ状態で動画を見るとavcになってるけど。

ちょっと思いついて
　　media.windows-media-foundation.enabled
をデフォのtrueからfalseに変えてみたら、H.264が再生できなくなるせいかVP8になったから、
そっちの環境でこれをfalseにしちゃってんじゃないかな？

>>827
OSX10.10.1+Firefox34.0.5 :確認したところH.264未対応だった
Lubuntu14.04+Firefox33.0 :H.264対応済み

前者では>>822,後者ではそちらと同じ動作になったので
FirefoxのH.264対応状況がプラットフォームごとに異なるのが原因だった模様

前者でも時間の問題で対応すると思うので（元々システムレベルでのH.264ライブラリも有るし）
>>820のYoutubeのVP8に関しては「以前はFirefoxでHTML5視聴の際に使われていた」という感じになるかな

無料でH.265以上のクオリティを実現できる次世代ビデオコーデック「Daala」の開発は順調
http://gigazine.net/news/20141224-daala/

vp9ベースのwebpって出てこないのかな。