【WebM】VP8(VPx)総合スレ4【Google/On2】

VP8/WebMについて語るスレです

WebM公式サイト
ttp://www.webmproject.org/
FFmpegパッチ
ttp://www.webmproject.org/tools/#ffmpeg_patches

関連スレ
【On2】VPx (VP3-VP6・VP7等)総合スレッド3
ttp://pc11.2ch.net/test/read.cgi/avi/1201491441/
ffmpegならこちらへ
ttp://pc12.2ch.net/test/read.cgi/software/1270542020/
エンコードソフト ffmpeg のスレ
ttp://pc11.2ch.net/test/read.cgi/linux/1232095273/

Google、オープンウェブ動画規格 WebM を発表
http://japanese.engadget.com/2010/05/19/google-webm/

Google I/O イベントより。Google がウェブ向けのオープン動画規格 WebMを発表しました。
WebMは Googleが2月に買収したOn2 のビデオコーデック VP8 をオープンソース化して採用することで、
だれでも利用料なしで使えるオープンかつ先進的なウェブ動画規格、およびそれを推進するプロジェクトの名称。

具体的にはビデオにVP8、音声にオープン&ロイヤルティフリーの既存コーデック Ogg Vorbisを使い、
それらを収めるMatroskaベースのコンテナ規格 が WebM となります。ファイル拡張子は .webm。

（中略）

WebMはこの現状に対して、フリーなVP8とVorbisを組み合わせてBSDスタイルのライセンスで提供することにより、
誰でも制限なく動画を扱えることを目的としています。また技術的な優位としては：

・ネットブックや携帯端末、タブレットでも扱えるほど再生が軽い。
・コンテナ規格 .webm は VP8+Vorbisだけでシンプル。( おなじ「.AVIファイル」だけれど中身は
ビデオがMPEG-2で音声が〜だからプレーヤによって再生不可、といった問題がない)。
・リアルタイムストリーミングでの高い品質。
・エンコードがシンプル。コーデックのプロファイルは最小限に抑えられており、
手動でパラメータやプロファイルを調節することなくベストの結果が得られる。

といった点が挙げられています。

■対応可能ブラウザ

・IE（FlashがVP8対応）
Firefox, YouTube and WebM ? Mozilla Hacks ? the Web developer blog
http://hacks.mozilla.org/2010/05/firefox-youtube-and-webm/

>4. Every video on YouTube will be transcoded into WebM.
>They have about 1.2 million videos available today and will be working
>through their back catalog over time. But they have committed to supporting everything.

4.　Youtubeにおける全ての動画はWebMへとトランスコードされます
現在、およそ120万に及ぶ膨大な数の動画があり、時間をかけてそれを処理することになります。
しかしながらYoutubeはその全てでサポートすることを表明しました。

コンテナ、mp4に比べて明らかにメモリ喰いなmkvベースなのが、
組み込み向けを考えると心配だなぁ。mp4はQuicktime関連の
特許を使いまくっているであろうことを考えると、mp4の採用を
避けるのは当然だとはいえ。

Diary Of An x264 Developer ≫ The first in-depth technical analysis of VP8　Dark_Shikari（VP8についての技術評価）
ttp://x264dev.multimedia.cx/?p=377
Firefox WebMビルド
ttp://nightly.mozilla.org/webm/
Opera WebM
ttp://labs.opera.com/news/2010/05/19/
Haali Media Splitter（WebMサポート）
ttp://haali.su/mkv/

引用元
■Web動画オープン規格「WebM」に追い風は吹くか
ttp://resic.laburec.net/archives/2010_05.html#20100520a

mkvベースなのか？mkvそのものじゃなくて
mkvにvp8+vorbisの組み合わせに.webmとかいう拡張子が付くだけで
コーデックとmkvスプリッタが入っていれば拡張子をmkvにしても再生可とかいう話ではないのか

比較
ttp://planar-studios.com/bin/vp8/1-500kbps-h264.png
ttp://planar-studios.com/bin/vp8/1-500kbps-vp8.png
ttp://planar-studios.com/bin/vp8/2-500kbps-h264.png
ttp://planar-studios.com/bin/vp8/2-500kbps-vp8.png
設定
ttp://planar-studios.com/bin/vp8/vp8test.txt

>>7
ソースがクソすぎるwwwwwwwwwwwww

動画(前スレから)
ttp://www.youtube.com/watch?v=H_mU7lkE-sA&html5=True
ttp://www.youtube.com/watch?v=tQxbpryKKQo&html5=True
Firefox WebMビルドで再生できた。

次スレを立てるときは、「WebM」スレとして立てた方がいいんじゃないかな
確かに中身はVP8+Vorbisなんだけど、動画フォーマットとしてはWebMだしさ

とりあえずはこのまま出発進行して、テンプレを構築していけばいいと思う
まだ立ち上がったばかりだから情報が少ないのは当然なんだし
じきに詳しい解説や公式なドキュメントとか、必要なものが揃うだろう

Microsoft to support VP8 video codec with Internet Explorer 9, after all?
ttp://www.zdnet.com/blog/microsoft/microsoft-to-support-vp8-video-codec-with-internet-explorer-9-after-all/6264

IE9はVP8を別途インストールすることで対応可能。

あ、言いそびれたけど>>1乙
そういえばAppleの態度表明はまだなのかな？
空気読まずに独自フォーマット出したら笑えるｗ

再生負荷がどれくらいなのか気になるところ・・・
H,264のMain Profileよりは軽いといいな

立ててからであれだけど次スレはWebMメインにしたほうがよさそうだね。
再生負荷は264と比較しても軽いわけではないらしい。

軽く技術的な文章も目を通したけど
原理的には処理が単純になった分だけ
H.264よりは軽くなるはずなんだが・・・
出たばかりだから改良が進むと思いたいね

atomD510なんだけど
chromeでOSはXP
ttp://www.youtube.com/watch?v=tQxbpryKKQo&html5=True
1080は途中で止まった
720はOKだった
あまり軽いというわけでもなさそうです

総合3を使ってからがいいってのが俺の提案
理由はあっちに書いた

でも論争までする気はないから雰囲気でこっちが伸びるならこっちで仕方ないしこっちでいいけどね

VP9ﾏﾀﾞｰ

俺自身はラデ使ってるので別に困らないが、intelが支持に回ってないのは地味に痛いかも

>>7
画質に関しては細部が甘くなる傾向にあるのが
ちょっと気になるけど、その分ノイズは抑え目かな
デコード・エンコードの負荷が軽くなれば悪くないかも

いずれにせよ各ブラウザで正式に実装されたら
Youtubeも対応するし勝手に普及するのかもなぁ・・・
ニワトリが先かタマゴが先か、みたいな話で

>>7
2個目、背景の壁がVP8はツルツルになっちゃってるな

アニメにはそれなりに良さそう、実写は駄目かな

>>17
VP8と下位互換性あるか気になるね

>>12
ひとのためになる事をするAppleなんて居ません！

とりあえず
ttp://code.google.com/p/webm/downloads/listの
libvpx 0.9.0 visual studio build落として
\bin\Win32のivfencでエンコできるっぽい
エンコパラメーターはここに書いてる
http://www.webmproject.org/tools/encoder-parameters/

>>15
h.264の方で再生されてるというオチじゃないのか
webmとやらは対応したブラウザとwebmでエンコードされたビデオしか表示できんぞ

chromeはまだっぼいね
chromiumならできるっぽい

逆にchromiumはデフォの状態だとH.264は駄目ならしい

こんな糞画質がWeb標準になるなんて悲劇としか言いようがない。

youtube(x264のメインプロファイルらしい)の画質なら変わらない

H.264のHigh Profileの代替ではなくMain Profileの代替だとすれば、
現状、この程度でもいいんじゃない? ヌルッとした画質傾向はチューニング
次第でどうにでもなりそうだし。

ちなみにmozilla関係の人のブログでは、x264の人がいろいろディスってるけど
その彼でもmain profileよりは上だと認めているし、それはほぼすべてのウェブ上の
H.264よりも全ての家電で動く設定のH.264よりも上だということなんだといっている

>>30
>VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1.
>It’s not even close to competitive with H.264 Main or High Profile.

http://x264dev.multimedia.cx/?p=377

http://weblogs.mozillazine.org/roc/archives/2010/05/its_a_relief_to.html
There's a lot of noise from H.264 proponents about Dark Shikari's analysis of VP8, but
even he agrees it's better than H.264 Baseline, which is
ああごめんbaselineの間違いだ
つーことは現在のyoutubeよりは落ちるとみていいのかな

Bフレームも使えない様な規格だし、H.264 Mainに勝てる訳はない。

VP8は、Bフレーム無し+CAVLCのH.264 Baselineと比較するべき。

ワンセグよりマシとか駄目じゃんｗ

http://x264dev.multimedia.cx/?p=292
再び訂正
youtubeはbaselineらしい
しかしiPhoneのためにこのクオリティなのに、iPhoneで再生できない
VP8にかえるというのはどういうことなんだろう

オープンでフリーな方が普及すべき
H.264厨は使用料徴収の当てがハズレそうだね
ざまぁｗ

appleの推進するH.264(baseline profile)もVP8もどっちも糞だから画質厨は
ウェブ標準に関してはあきらめろということだ

>>5の下のところが更新されてた。
でエンコは出来たけどコンテナが作れないという。
一応2passだと1pass目はx264のターボモードって感じで1pass目は早く終るのがデフォルトになってるのはいいね。

>>37
待て。HTML5のvideoタグでH.264のプロファイルまでは定められていないと思ったが。

規格がどうあれyoutubeがそうであるように、iPhoneで見るためにはそういうものしか存在できないんだろ

VP8を試したいのなら、avs2yuv -raw input.avs -o output.yuv として、
SDKのivfencでエンコードするのが楽。

http://akuvian.org/src/avisynth/avs2yuv/
http://code.google.com/p/webm/downloads/list
http://www.webmproject.org/tools/encoder-parameters/

できたファイルはivfdec --i420 -o vp8.yuv vp8.ivf としてデコードして、
RawSource(file="vp8.yuv", width=width, height=height, pixel_type="I420") とする。

>>40
完全に意味不明。せめて、Youtubeが複数解像度のストリームを
用意していることぐらい理解しとけ。

・Theoraよりは高画質
・オープンでフリー
・プラグインインスコやFlashを使わずにブラウザで再生可能
　　例外 IEだけはプラグインかFlashが必須
・WebMコンテナはVP8＋OggVorbisと決め打ちされてるので、再生出来ないことがない
・エンコ設定がシンプル
・再生負荷云々はGPUサポートなどもあるしこれから

とにかくエンコ、デコードともに使いやすさと混乱しないことを重視してるね
これはこれでいいんでない？

一般人がするエンコでこれを選ぶ必要ないしなぁ
ブラウザ標準対応が完全なら問題ないや

>>15
それH264で再生されてるってｗ
WebMで再生すると360pと720pしか選べないはず。

確かに、決してベストな選択肢ではないかもしれないけれど
ベターな選択肢ではあるよね。H.264の抱える問題をクリアしてるので
結果としてはデファクトスタンダードになって普及する可能性はある。

これ、ソースコードが公開されるのか。
企業や有志の手によってより高画質化できるエンコーダが開発されるという可能性もあるのかな？

今すぐ既存コーデックにとってかわるものではないけど、
数年がかりで洗練されていきそうな感じはある。

公式のDirectShowフィルターを入れたら
　　WebM Muxer Filter
　　WebM Source Filter
　　WebM Splitter Filter
　　WebM VP8 Decoder Filter
　　WeM VP8 Encoder Filter
が登録されるので、GraphStudioでこんな感じでEncoderとMuxerを使ってwebmファイルを作ってみました。
　　ttp://www1.axfc.net/uploader/Img/so/82889.jpg　←GraphStudioのスクショと簡単な説明
　　ttp://www1.axfc.net/uploader/File/so/44030.zip　←作成したwebmファイル
VP8 Encoderは詳細設定とかどうやるのかわからんかったのでそのまま使用。
音声も入れたかったけど、Vorbisのエンコード経験がないので省略。

とりあえず作成されたwebmファイルをMPC-HCで再生すると、
WebM File SourceとWebM VP8 Decoderによって再生されることを確認。

知識が半端なんで、ivfencで好みのパラメータ設定で作ったivfファイルを
どうやってMuxerにもってけばいいのかわかんねっすorz どなたか教えてくんなまし。

あとはVorbisについて勉強しておかねば・・・。おすすめのエンコツールとかあればそちらも是非。

GraphStudio使えるならVorbisはXiph公式のDirectshowFilter使えばよくね？

http://www.xiph.org/dshow/downloads/

と、ここまで書いて気付いたが、音声は別でエンコしてMuxするのが普通か。
コマンドラインエンコーダはAoTuV使っとけば良いんじゃないかな。

>>47
Vorbisはかなり高音質化されたけど、TheoraはOn2が提供したコードがアレだったのと
そもそもの規格がプアーだったせいか高画質化できなかったので、VP8の高画質化は
良くわからない。ただ、画質の傾向を変えることはできると思う。

VP8がVP6のようにウェーブレット変換を使っているのなら、まだその辺は未成熟なので、
実装の改善だけで画質の改善はありえるかな。

>>48
GUIが欲しいならoggdropXPd ttp://www.rarewares.org/ogg-oggdropxpd.php が無難かな
foobar2000等の音楽プレーヤーはコマンドラインエンコーダを通してエンコできるからそれを使うのもいい

>>50
VP6は8x8のDCTで、VP8は4x4のDCT。

DWTを使う規格にはDiracがあるけど、DCTの規格よりデコードが遅くて画質が悪い。

>>52
ありゃ、かつてVP6はウェーブレット変換使っているという話だったし、
wikipedia日本語版にもそう書いてあったけど、ウェーブレット変換使って
なかったのか…。

DCTベースという同じ土俵の上では、H.264よりも高画質というのはまず無理だなぁ。

>>53
VP6は大分前に解析されて、libavcodecで扱える様になった。

http://www.dspdesignline.com/211100053?printableArticle=true
http://wiki.multimedia.cx/index.php?title=On2_VP6

Dark Shikariが言うには、VP8のDCTは4x4だけで、8x8は無いそうだ。
変換だけでも8x8を使えるH.264 Highと比較すれば、VP8にとって不利になる。

ソース見た。既にある程度のSSEによる最適化はなされていた。
気になったんだけどVorbisって人の声のみの音はあんまり得意じゃないと思っていたんだけど改善されたのかな？

>>49
＞GraphStudio使えるならVorbisはXiph公式のDirectshowFilter使えばよくね？

デコーダーのみだと思い込んでて後回しにしてました。VorbisのEncoderフィルターも入ってるんですね。
さっそく最新のoggcodecs_0.83.17220-win32.exeを入れて試してみましたが、何やらエラーが出ますね・・・。
「PCM音声→Xiph.Org Vorbis Encoder→WebM Muxer」と単純につないでみましたが、Muxでエラーが起きてる模様。
環境や使い方が悪いのかな・・・。

>>51
ありがとうございます。色々試してみたいと思います。

このコーデックの利点て、

・フリーである
・再生の軽さの割には画質が良い
・オープンソースである
・単純で扱いやすい

短所は

・画質はH.264に劣る
・圧縮率もH.264に劣る

こんなとこ？

>>53
ウェーブレット使ってるのはSNOWだったかな
これはオープンソース

>>57
デコードは今の所、ffmpeg等の最適化された実装があるH.264の方が速い。

特許の心配をせずに使える規格の中では、VP8がベストと言うのは事実だから、
H.264に負けるからといって、悲観することはない。

結局は安かろう悪かろうが標準になってしまうのか・・・

最適化が進んで、H.264よりずっと負荷が軽くなるなら悪くは無いと思う。
そうならないならちょっと・・・とは思う。

>>55
Vorbisについては蒼弓さんに直接聞いてみるとか
ttp://www2.atword.jp/aooa/

オープンソースでロイヤルティフリーだから
何にでも実装できるのは大きいだろうね
既にYoutubeも対応してるんからなし崩し的に普及しそう

>>55
特段の改善はされていないと思う。
超低ビットレートでなければ大丈夫だと思うけどね。

問題は速度がどれくらい実用的かだよな
実装を見た限り複雑な処理を要求する要素は
省略してるから重くはならなさそうだが・・・

>>55
もしかしたら人声用にCELTも使えるようにしてくれっていう話も将来は出てくるかもしれないが、
まあ64の言うとおり超低ビットレートでなければVorbisでも大丈夫だと思う

Grapheditはエンコ設定不明で音は不可
ivfencはエンコはできるけどマージ方法が不明
makewebmでできそうだけどやり方不明だし色々と厳しい

Ptalarbvormとかvp8にフィードバックしたりしないの？

>>55
>>62にも出ているけど、蒼弓さんがガシガシ音質改善のためのパラメータ調整
したので、平均64kbpsぐらいまでならAAC並に高音質。

I, FOR ONE, WELCOME OUR NEW WEBM OVERLORDS
http://xiphmont.livejournal.com/50239.html

Xiph.Org press release about WebM
http://xiphmont.livejournal.com/50683.html


自然な成り行きだが、Xiph.Orgも全面的にWebMを支援していくとのこと
というか、既に数週間前からVP8のソースコードに関わってたらしいｗ

パッチ当てたffmpegバイナリはない？

Googleって、まだ完成して無い技術やコードをさも凄いもののようにしてオープンソースにするところがちょっとダメなところだと思う。

>>57
短所に
既存のハードでは再生支援が効かない（将来は可）
も追加で

はぁ？既にx86のSSEやARMのNEONも効くだろ
これだから情弱は（ｒｙ

いつからSIMD命令セットへの対応をハードでの再生支援って言うようになったんだ？

あとGPUについても言いたいんだろうが
あくまでも「Webでのビデオフォーマット」に関して言えば
FLV上のH.264ですらようやくリリースされる予定のFlash 10.1で
正式にサポートするって段階なんだから理解力不足の上に
本質を見極めるピントがずれてるとしか言いようが無い。

しかもFlashという閉じた枠内。単純にローカルで再生するのなら
WebMを（VP8も）わざわざ用意する必要なかっただろうに。

そういう話じゃない
既存のGPUの大部分の製品にはH.264の再生支援を
ハードウエア的なロジック回路として実装しているが
VP8についてはこれからの対応になる、という話

現状では 「Flash + H.264 + DXVA」
という三重の閉塞した規格内でしか受けられんよ。
しかもDXVAに関してはWindows限定の規格。

他のプラットホームでは最近になってようやくMacでも
「Flashの」GPUによるH.264デコード対応が始まった程度。
スマートフォンに至っては更に後回しだ。

なんか技術的な部分を全く理解して無いようだが
GPUさえあればなんでも再生支援できるって
そんな生易しい話じゃねーよタコ。

Mac？
あれに関しても既にFlashの枠外でも有効化されている
既にHTML5 video/H.264はSafariで再生支援を受けられる

WinのDXVAは汎用のものであって特定のセットでしか使えない物ではない
OSXに最近追加された再生支援用のフレームワークも同様
使いたければ基本的にどのサードパーティでも使える

HD動画の再生支援はユーザーに取って関心の有る話題だし効果も大きい
それを「本質的でない」と断じる姿勢はおかしい

少なくとも現在既に実装されて使える環境がほぼ整っているH.264と
まだこれからのWebM/VP8、という状況を指摘をすることに問題が有るとは思えない

だからさ、PC向けのGPUに限った話だって言ってるだろ？
WebM/VP8はローカルではない、web上の動画フォーマットだから
あらゆるインターネット接続できるデバイスで再生できるのが目的だ。

だから処理を端折って、H,264比で画質を犠牲にする代わりに
再生の負荷を軽く留めてるわけだ。逆に言えば、H.264の再生支援を
受けられるデバイスがPC以外でどれだけあるんだという話になる。

GPUさえあればH,264は再生支援が絶対受けられる〜みたいな解釈が
根本的に間違えてるし、WebM/VP8の設計思想を理解できていない。

PC向けGPUはH.264の符号化処理などをハードワイヤードで処理するために
専用のユニットを装備しているが、当然全てのGPUに備わってはいない。
処理させるにはシェーダーを動かして肩代わりさせるといった手法もある。

ただ実際にGPUを叩いたことある人なら分かるけど、クソめんどくさい。
CPUのSIMDユニットにやらせる方が遥かに楽だしスマートなやり方。
GPGPUなんぞ謳われてきたが、現状ではろくに普及して無い現実見りゃ分かる。

DXVAって何の略か分かってるのか？
「Direct X Video Acceleration 」だぞ
どこをどう読んだら他のOSに移植できるんだよ。

無論GPU側のハードウェアユニットは他のOSでも使えるが
DXVA自体は完全にWindowsのみのAPIなのは文字通り。

もちろん、H,264そのものはそりゃもう誰もが認める
超優秀なコーデックで比類なき完成度だが
現実問題としてWeb標準として採用するには
看過できない欠点が多くてどうしようもないよ。

ハードワイヤードで処理できるのはH,264の利点の一つだが
といっても限られたデバイスなのが問題。そもそもCPUですら
十分に処理できないようなコーデックはWebビデオに向いてるのか？

勘違いしないで欲しいけど、自分が言いたいのは適材適所で
H.264とVP8は完全にベクトルが違うからGPU再生支援云々を
欠点として指摘された所であんまり意味が無い。ねるぽ。

曲解してあれこれ叫ぶのは結構だが、こちらの書いたことを踏まえた上で
>>73が果たしてwebMの「現時点での状況」を説明するものとして
間違っているのか否か、をまず考えてくれ。シンプルに、ロジカルに、脱線せずに。

理解力不足、本質、ピントのズレ、そっくりお返しするよ。
事実関係の間違いも多いし、特に>>78の後半3行は単に君の読み間違いでしかない。
誰もどんなGPUでも再生支援が有効だなどと言ってない。
DXVAが他のプラットフォームに移植出来るなどとも言っていない。

単に現状を踏まえて事実として一つの事柄を>>73で述べているだけだ。
そして「将来は可能になる」ともちゃんと書いている。

WebM/VP8の役割とメリットのことは十分理解しているので君の稚拙な解説など必要無い。

軽いフォーマットだから再生支援なんて要らないのが利点
処理が軽いから性能の低いマシンでも、バッテリ重視のモバイルでもOK
何をそんな必死になって言い張ってるのかよく分からんのだが

揚げ足取りが早速湧いてるとしたらそれだけ注目度高いのか
嬉しいやら悲しいやらｗ

まぁ、まだ未完成のコーデックだよ。これ。

>>82
おっと読んでなかった、失礼。
前半部分の「読み間違い」は除くと、後半部は特に異論無いよ。

こちらも別に元々事実の一つを書いただけでしかないので、
それぞれのメリットは十分に理解してるよ。

でもこれは（特にこの板的にも）結構無視出来ない話だよ。
将来でなく、今既に手元に有るハード資産を活かす上ではね。
H.264なFlash動画やYoutube,VimeoのHTML5 videoなH.264でも、
実際にその恩恵を受けてる人達も既にかなり居るんだし。

また最良の再生品質／パフォーマンスを得るには例えwebM/VP8でも
再生支援が有った方が望ましいのは確か。
元々のこちらの意図は主にPC向けの話だが、そちらが話に含めようとしたモバイル関連でも
VP8のハードウエアデコーダーを載せる方向で一部ベンダが既に動き出してる。

あと君の噛み付き方は何度読み返しても色々おかしいと思う。
色々と勝手に読み違えて明後日の方向に反論されても困るよ。

言っていることは所々正しいので全否定などする気もないが、
相手が何をどこまで言っているのかをちゃんと読み取るべき。

ID:D1XB8m8vの認識が圧倒的に正しいな

今知った
音声Vorbisなんか
蒼弓氏今もまだファインチューニングしてるのかな

WebM ffmpeg build
http://micksam7.com/blog/index.php/?p=743

ID:ZjKi4CGAアホすぎてワロタ

>>89のところに書いてるやつ。フロントエンド
ttp://www.wildform.com/flixwebm/downloadsite/
Wildform4Flix
これでwebmは作成できた。

>>91
ttp://www.wildform.com/products/flix/

VP8と対応FME配布ﾏﾀﾞｰ？

>>88
蒼弓さんのチューニングがマージされたのってlibVorbis 1.1.0でもう5年前か。
最近の蒼弓さんのチューニングってマージされたのかな?

ttp://www2.atword.jp/aooa/2010/05/17/libvorbis-131-aotuv/

VP8がフリー化されたからTheora (VP3)涙目じゃね？
・・・どうせならVP6もフリー化すればよかったのに。

エンコの負荷と時間がH264に劣ってないかいorz

>>88
一人でやっているよ。それと一緒に開発をしてくれる人を募集してる。
http://www2.atword.jp/aooa/2009/09/16/aotuv-beta6/
誰かソースを見て弄ってみたい方がいれば早めにリリースしたいところですが、
そうした積極的な方はいらっしゃるでしょうか？（新しい開発者はWelcomeです！）

>>94
libVorbis 1.3.0でマージされる予定だったけど流れて現在の1.3.1の
次の公式リリースでマージされるという話です。

>>91
たかだか5分の動画のエンコードに3時間もかかったけど設定間違ってるかな
といってもほとんど設定が見当たらないね・・・

.ivfが謎過ぎる、、デコードできるけど、muxできない、、。
Googleは何を思ってリファレンスエンコーダの出力にこんな謎な形式を選んだんだ。
せめてＭＫＶで出力してほしかった。

ttp://resic.laburec.net/archives/2010_05.html#20100520a

>>99
デフォルトだとアホみたいに時間かかる。
-level 300 を指定してやると、CPUがQ6600で640x480の動画が45fpsくらいでエンコードできたよ。
-level 100 とか-level 200 だと何故か遅すぎ（1fps）なので諦めた。

ivfっつーか生のVP8じゃね？

ivfはIndeo Video Formatらしい
VP8のRAWデータって訳では無い様だ

単に名前被っちゃっただけじゃないだろうか＜Indeo Video Format
生のVP8で合ってると思う。

http://wiki.multimedia.cx/index.php?title=IVF

ffmpeg-develにDemuxerのパッチ投稿されてるね。

http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/109802

>>105
ivfdec.cに対する差分ファイルのコメント欄見てないの？
+/*
+ * Indeo Video File Format
+ * Copyright (c) 2010 David Conrad
ってバリバリ書いてあるじゃん

ちなみにこれ当てたffmpegで実験してみてるけど、-i hoge.ivf -vcodec copy out.webm とするとハング(無限ループ?)状態になる
追加で -i hoge.ogg -acodec copy -map 1.0:0.1 とかすると#0.1のsyncが見つからないとか言われて変換できなかった

画質がどうこう以前に特許はほんとに大丈夫なんだろうか？
googleはそこをハッキリしてくれないとソース公開されても怖くて使えない

>>105
すまん、読んでなかった。確かにそう書いてあるね。

>>107
Googleはロイヤリティフリーって言ってるけど特許フリーとは言ってないんじゃね？

世間の反応だとGoogleは資金豊富だから、
例えそうなっても金の力でねじ伏せるだろう、みたいなこと言ってるね

個人的にはGoogleはその純粋な技術力はさておき訴訟には強そうな印象

ttp://www.on2.com/index.php?599
左どこのエンコーダ使ってんねん

VP8のライセンスｗ
ttp://d.hatena.ne.jp/edvakf/20100521/1274414815

＞「もしあなたがこの特許使用権を行使したことにより、他者があなたを訴えたり
＞クロスライセンスを結ぼうとした場合、その者はこの条文により許諾されたすべての権利を失う」

VP8と対応FME配布ﾏﾀﾞｰ？

>>104-108
たしかにパッチにはIndeo Video Fileと書いてるけど、まだ鵜呑みにしないほうがいいような気がする。
パッチについて否定的なコメントもついてるように見えるけど。
　　ttp://comments.gmane.org/gmane.comp.video.ffmpeg.devel/109802

Indeo Video Formatとやらの資料を探したけどよくわからんかった。
MSのサポートサイトで拡張子ivfのサンプルを見つけたんだけど、中身はIV50+PCMのAVI 2.0なんだよね・・・。
　　ttp://support.microsoft.com/?scid=kb;en-us;q316992

WebMのIVFは、>>105のWikiにあるように、生のVP8データを格納するシンプルな独自コンテナのような気が。
コメントについてるように"idiotic video frames"だとか"internet video file"だとか、そんな感じじゃないのかなあ。

>>113
コメントにIndeoって書いてあったからそう思ったんけど違うのか・・・

パッチに関しては既にbugらしきものを見つけた
ivfdec.cの56行目で av_q2d(st->time_base); を掛けてるけど、これ不要
単に
st->duration = get_le64(s->pb);
としないと値がおかしくなる

Wikiの方はbytes 16-23がframe rateである事が抜けてるね
16-19が分子で20-24が分母の二つで構成されている模様

せかにゅ：Googleのオープン動画フォーマット「WebM」、Appleは不支持か
ttp://www.itmedia.co.jp/news/articles/1005/21/news048.html

>>113
"idiotic video frames"の方は揶揄じゃね？ｗ

今Googleのトップ画面でパックマン遊べるぜ。

>>117
スレチだが懐かしいな。

うーん・・・>>89にあるffmpegで音声つきのwebmファイルが作れたのはいいんですが
再生時にWebM公式のWebM Source FilterやWebM Splitter Filter、
それにWebM対応した最新のHaali Media Splitterのどれを使っても、
Xiph.OrgのVorbis Decoderと接続できないのはなんでだろう。
GraphStudioで直接つなげてやろうとしてもつながんない。
　ttp://www.webmproject.org/tools/
を見ると、VorbisについてはXiph.OrgのDirectShowフィルタ入れろとなってるから
つながらないわきゃないと思ってたんですが・・・。うちだけでしょうか？

最新のoggcodecs_0.83.17220-win32.exeを入れたらOgg再生時にアプリが落ちるようになってしまったので
１つ前のoggcodecs_0.82.16930-win32.exeを入れたのですけど、そのせいでしょうか？

とりあえずffdshowのオーディオデコーダーでVorbis有効にしたり、
MPC-HCの内蔵Vorbisデコーダーを使えば問題はないのですが・・・。

22 5 月 GoogleがWebMを公開
ttp://www2.atword.jp/aooa/

バカポさんの記事に
　＞そのほか、これらオプションスイッチの指定が不要な simple_encoder.exe や、
　＞その2pass版と思われる twopass_encoder.exe も同じディレクトリにあります。
とあったので試しにこれでivfを作ってみたのだけど、出来上がるivfがおかしくなってる気がする。
>>41の方法で、「ivfdec --i420　〜」でデコードしたうえでRawSoure(pixel_type="I420")で見ると、
赤色色差と青色色差が逆になってる模様。pixel_type="YV12"にすると正しい色に見える。
ivfencを使った場合は問題ないので、simple_encoderとtwopass_encoderのバグってことになるのだろうか？

公式の
　　http://www.webmproject.org/tools/encoder-parameters/
にある「1-Pass, Faster Encoding」のパラメータでivfエンコしてみたら、

　　Warning: option minsection-pct=20 ignored in one-pass mode.
　　Warning: option maxsection-pct=800 ignored in one-pass mode.

って警告が出ました。何故２pass用のオプションを指定しているのだろう・・・。

http://www.mirovideoconverter.com/
エンコおそろしく遅いんだけどこんなもん？

mpeg2→webm
Q9400で実時間の5倍かかった
これは・・・

>>124
x264の1080p30と良い勝負かw

>>119
そのffmpegのVorbisエンコーダがlibavcodec由来のものだからかも。
これは音質がかなり悪いので、どちらにせよ使わない方がいいと思う。

もっと遅くねーか
x264の6倍ぐらい時間かかるな

いきなり死亡したな

普及せずに終わった

-level 300でも遅いのか？

>>126
その後、
　　１．oggcodecs_0.82.16930のVorbisEncoderフィルタとOggMuxフィルタで作ったOggVorbisを
　　　　>>89のffmpegで-acodec copyで映像とMuxしたwebm
　　２．aoTuV post-beta5.7[20100516]で作ったOggVorbisを
　　　　>>89のffmpegで-acodec copyで映像とMuxしたwebm
　　３．>>91にあるWildform4Flix（FlixWebM）で作ったwebm （MediaInfoで見るとlibVorbis20100325を利用）
でも試してみましたけど、どれもffdshowでしか再生できないようです。
詳しい仕組みはよくわかんないけど、Xiph.OrgのVorbis DecoderフィルタはOgg専用なんですかねえ・・・？

それと、>>91にあるWildform4Flix（FlixWebM）ですが、インストールすると
WebM公式のDirectShowフィルター（v0.9.5）よりも少し古いもの（v0.9.3）をsystem32に登録するようです。
アンインストールしても登録されたまま残ります。
別の場所に0.9.5を置いて使ってたのにいきなり0.9.3になってたのでなんでだろうと思った・・・。
0.9.3と0.9.5の違いは不明ですが、最新のフィルタを使いたい人はちょっと注意が必要かも。

あとFlixWebMで入力にHuffyuv+PCMのAVIを使おうとしたら映像がうまく読めないようで画面が真っ黒に。
色々試してみたところ同じHuffyuvでもRGBで圧縮したものなら読めましたが、YUY2圧縮したものは真っ黒になるようでした。
他にも読めるもの、読めないものがあるようで、よくわからないっす。一応参考までに。

グーグルは、未完成品をさもすごいもののようにして出すのはやめて欲しい。

秒速５センチメートル公式サイトにある8Mbpsのwmv（ファイルサイズ24MBちょい）を
いったんHuffyuvRGB+PCMのAVIに変換してから、
FlixWebMで映像2000kbps、音声128kbpsという設定でwebmにエンコしてみたら、
映像5196kbps、音声500kbps（MediaInfo調べ）の32MBのファイルが出来上がったでござる・・・。

今試してみてるけどこれエンコに時間掛かりすぎだろ
これ開発してる連中は一体どんなスペックのPCで開発してるんだ？

すでにつべで公開始めてる訳だから、
鯖で公開する用の専用エンコーダ？はちゃんとしたの完成してる筈だが
こっちのは当然別扱いだろうし、荒削りのまま出しちまったのかな

当然別扱いって・・・なんてクローズドなって事だよね

Googleがエンコーダ公開するときは普通の技術者じゃない人もある程度使いやすいように、
GUIを持ったエンコーダを公開するものだと思ってたんだ。
プリセットの設定を含みつつアドバンスモードとかで細部を設定できるＧＵＩをもったのを。
蓋をあけてみればエンコーダとＦＦＭＰＥＧパッチ以外ほとんど開発者に丸投げだった。
普及を考えるならGoogle製の登録の要らないフロントエンドくらい用意しようよ。

137追記：Wildform4Flixは登録が簡易なＧＵＩエンコーダだけど、設定できる項目が少なすぎる。

ffmpegのr3ビルドが公開されてた。
　　http://micksam7.com/blog/index.php/?p=743

>>15
現時点では、再生支援が効くなら1080pはh.264の方が実質的に軽いと言うことか。

落ちを読んでいなかったorz

ようつべどこにwebmの動画あるの？

>>142
対応するブラウザの開発版を落として、
そのブラウザでつべのHTML5テスト版を有効にしてから
ここ数日にアップされたHD動画を探すと観れるよ
つべの「検索オプション」で「今日」「HD」とか指定すると大抵確実
（中にはFlashのが混ざることも有るから、右クリで確認）
昨日位からプレーヤーの表示が変っぽい、崩れたり直ったりしてる
ちゃんとしてるときは動画の下に「HTML5 WebM」ってマークが入る

プロジェクトのサイト（手順の説明）
ttp://www.webmproject.org/users/

一例
ttp://www.youtube.com/watch?v=aMF0B2poQBk&hd=1&webm=1

&webm=1を付けて検索

http://www.youtube.com/results?search_query=trailers&aq=f&webm=1

あ、そっちだと確実か
というか公式の説明の通りだね

なんか不定期にプレーヤー部分の表示崩れない？
正しいときとそうでないときが有る
（FirefoxのwebMナイトリーで試してる）

>>145
うちもFilreFoxのWebM対応版で試したけど、ボリュームのスライダとかが変になってるときがあるな。

>>146
やっぱそうか、レスサンキュ
まだ色々弄ってる最中なのかもね
画質は結構良い感じかな

>>143-144
ありがとう
対応版落として試してみたけどHTML5では表示されてるけどHTML5 WebMでは表示されないなあ
ようつべ側で調整してるのかな？

ファイルが用意されてはいても再生されないものがあるね
広告付きとかかな

H.264と比較するのは間違いじゃね？
theoraよりマシってことで当て馬的存在なわけで。

一般向けじゃなくて動画サイト側で使うものって感じなんだろうね。こちら側で使うメリットはあまりないし。

>>150
x264開発者のDark_Shikari氏いわく

　　http://x264dev.multimedia.cx/?p=377

　　With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264.
　　Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.

　　　　訳：これら（※１）を考えるとVP8はH.264そのものと比べるよりも、VC-1やH.264のBaselineProfileと比べたほうがよさげ。
　　　　　　　当然だがVP8は明らかにTheoraより優れているし、私のテストではDiracよりも優れているようだ。

　　　　※１・・・前の文章にあるが、Bフレーム等の重要機能がないといったことを考えるとってこと。

　　VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1.
　　It’s not even close to competitive with H.264 Main or High Profile.

　　　　訳：VP8はH.264のBaseline Profileや、VC-1よりちょっとマシなくらいの位置づけ。
　　　　　　　H.264のMain ProfileやHigh Profileにはとても及ばない。

オープンソースなら各ブラウザがライセンスを気にせずに再生エンジンを実装できるから、
コンテンツ提供者が視聴環境（Flashが入ってるかどうかとか）を気にせずに動画を提供できるようになるだけだね。

ざっとソースやドキュメントに目を通してみたが
原理的にはH.264と比べて複雑な処理を省いてるから
確実に軽くなる（ならないとおかしい）と思われ

さすがに年数積み重ねてきたコーデックと比べると
不利なのは否めんと思うが、可能性には期待してる

“WebM”形式に対応した動画変換ソフト「Miro Video Converter」v2.0が公開
ttp://www.forest.impress.co.jp/docs/news/20100524_369130.html

>>148
今出てるwebM対応版の開発版ブラウザ(Fx,Chromium,Opera)は
H.264の方には対応してない筈だから、読み込み時に"HTML5"と表示されたなら
多分それはwebM動画だよ。選べる解像度は現状360pと720pHDの２つ。

またFirefoxならTools/MediaからType=Videoな構成ファイルを探すと
webmかどうか確認出来るよ

本当はH.264のときは"HTML5"、webMなら"HTML5・webM"ってマークが
プレーヤー表示の下の方に出る筈なんだけど、表示が崩れるとそのマークも消えちゃう
今その状態みたい、時々直ったりまた壊れたりしてる

ivfencで作ったivfファイルをなんとかwebmにできないかいろいろ試してみた
結果からいうとwebm化はできたけど、使い物にならなかったorz

ivfencへは420rawなデータを使用したけど、この段階でivfが60fpsで作成され、フレーム数が何故か増えた
このivfをaviへ無理やり変換するプログラムを書きavi化し、fps値を調整
mkvmergeを使って、上記のaviと別途作成したoggを使って通常のmkv化
上記のmkv内のCodecIDをバイナリエディタでV_VP8に変更した後、再度mkvmergeを使ってwebm化
# V_VP8に変更しないとVfW compatible videoはwebMediaに使えないとエラーが出る

webm対応firefoxで再生できたけど、ivfencでの謎のフレーム数増加が原因(?)でリップシンクが合わない状態に・・・

せかにゅ：Googleの「WebM」に特許問題か　MPEG LAが特許料要求の可能性
特許管理団体MPEG LAが、Googleが「ロイヤルティーフリー」とうたうVP8とWebMに対し、特許料を請求するためのライセンス作成を検討している。
http://www.itmedia.co.jp/news/articles/1005/24/news047.html

こりゃ終わったかもな。

連中の難癖は想定の内だろ

あんだけシンプルで使いやすくてパフォーマンスの高いアプリを
出してくれるGoogleなのに、何のアプリもなし、ソースのみってなんだよ
普及させる気ねーのか

権利関係を探っってるんじゃないの

VP8がライセンスでつぶされたら、GoogleがOn2社を１億ドル以上で買収した意味がなくなるよな・・・。
大枚はたいて貧乏神スカウトしてきたみたいな・・・。

訴訟でぐだぐだになって
HTML5 videoの正式規格化が遅れるのだけは避けて欲しいところだ

併存で良いよ併存で、争ってないで実利をとれ
ぐだぐだやってたら遅れるだけだしHTML5 video自体が廃れるだけだ

>>161
当然そこは想定の上だと思うのだが
どうするつもりなんだろうな

そりゃGoogleの資金力をもってして全面的に争うでしょ
法廷で勝てると見積もったからこそ買ったんだろうし

>>157
どう見ても権利ゴロが難癖つけて金をせしもうと画策中ってだけだｗ

＞MPEG LAのラリー・ホーンCEOは、VP8とWebMで使われている特許技術群について、
＞パテントプールライセンスを作成することを検討していると話す。

＞「VP8などのコーデックの特許権を利用するために、個々の特許保有者と個別にライセンス交渉せずに済む
＞便利なワンストップライセンスの作成を求められている。われわれはその可能性を検討している」

＞Googleは、VP8の開発元であるOn2 Technologiesを買収する前に「徹底的な分析を行った」としており、
＞「VP8には非常に自信を持っている。だからオープンソース化した」と述べている。
＞WebMはMozilla、Opera、Adobeなどが支持を表明している。

プリセットを参考にしたりパッチファイルのぞいて対応オプションしらべて設定して
いろいろ数値変えたら、
きしめんの映像５３０ｋである程度画質のいい物が出来上がるようになってきた。
まあ、、エンコードがとてつもなく遅いのがアレだけど、そこら辺は今後の改善に期待。

付け込まれる隙を作ったGoogleと元凶のOn2も相当なアホだと思う
どのみち動画再生なんてどれも似たような技術要素の集まりなんだから
完全に既存技術と別の物だなんて言える訳無いのに

ちょっと意味がわからない

まあこっちにはあまり関係のないことだし正直どうでもいいな

x264の開発者がソースコードみて、「この仕様では訴えられる可能性大」だと言ってるが、
Google もそんなことはわかっていて、わざわざ GPL と互換性なさげな BSDライセンス＋特許条項で公開してる。
http://www.webmproject.org/about/faq/#licensing

WebM 利用の権利を剥奪されてまで訴えるやつはいないだろうとタカをくくっていたわけだ。
でも、H264側からすれば、すでに完成された技術をもってるわけだから、
VC-1と同じくここで VP8 そのものを潰しておけば、あとあと楽だよねって考えるだろうさ。

訴訟のごたごたは止めて欲しい
しかしwebMのライセンス条項は果たして社会通念として通るのだろうか
訴訟相手の利用権を剥奪する正当性に若干疑問を感じる

法律詳しくないから良く分からんけど、どんな既存のライセンスでも社会通念で
それなりに正当性が認められるから通用してきたんじゃないかと思うのだが

>>170-171
他のライセンスと比較してからモノを言えよ。特許条項なんて
Apache License 2.0やGPL 3.0にも盛り込まれているものなんだぞ。
つまり、一般的なフリーソフトウェアライセンスだ。

JASRACと一緒でMPEG LAが金を稼ごうとしてるなの丸分かり
特許持ってる家電関係の連中からしたらWeb動画を潰せたら一石二鳥

本気でH.264を普及させたいならWeb限定で永久フリーにすれば済む
が、それをやらないからWebMが誕生したし、他に選択肢はなかった

24 5 月 WebMとYouTubeとVorbis
ttp://www2.atword.jp/aooa/2010/05/24/webm%e3%81%a8youtube%e3%81%a8vorbis/
ttp://www2.atword.jp/aooa/
このページを参考に YouTubeで「&webm=1」をURLの後に付けてWebM動画を検索してみる。そして見てみて聞いてみて最初に感じたこと、、、

･･･なんだ？　この音の悪さ


同じURLのFlashで再生される動画では全く問題無いのですが、WebM動画のほうはあまりに酷いです。
ファイルをダウンロードして確認、などはしていないので憶測になりますが、libvorbisやその派生ではなく、
多分libavcodecのVorbisエンコーダ(ffmpeg vorbis [注1])を使っています。
高域のエネルギーコントロールが適切に行えていないために、激しい金属サウンドが生じています。
なんというか、ISO由来のmp3エンコーダ群を思い出させる音です。

一応最近のffmpegをビルドして、デフォルトのVorbisエンコーダの音を確かめてみましたが、非常に似た音がしていました。
なんというか厳しいです。

これではVorbisは音が悪い、という評判が立っても仕方がないような状態です。非常に残念です。

（注１　このエンコーダについてのディスカッションは過去の Hydrogenaudioにありました）

つべはAACだろうがVorbisだろうがクソ音質

> 一応最近のffmpegをビルドして、デフォルトのVorbisエンコーダの音を確かめてみましたが、非常に似た音がしていました。
> なんというか厳しいです。
Vorbisの音質のチューニングをしてる蒼弓氏が嘆くくらいだからffmpegのは相当酷いみたいだね

外野が騒いでる間に、対応は着々と進んでいるようだ

VP8対応ブラウザ、Firefox/Opera/Chromium開発版
http://journal.mycom.co.jp/news/2010/05/24/005/index.html

Chromium開発版/Ubuntu 10.04
http://j.mycom.jp/news/2010/05/24/005/images/002l.jpg

Firefox開発版/Windows 7
http://j.mycom.jp/news/2010/05/24/005/images/003l.jpg

>>176
まあ、その辺はffmpegにlibvorbis 1.3の蒼弓さんチューン版コードを
コミットすればいいわけだし、それこそがオープンソースのメリットだしね。

>>177
WebMが発表された時点でOperaだのFirefoxだのffmpegだのHaali Media Splitter
だので対応版がドカンと出たわけだけど、なにをいまさら…

>>172
その台詞と全く同じのをネット上で見掛けた気がするけど
（スラドのフォーラム辺りで）

特許条項と非係争条項がその度ごとに物議を醸したのはご承知の通り。
んで今回のはそちらの挙げたどちらとも異なるように思えるが。
（条文を読み比べた限り。ライセンサとライセンシの捉え方が異なる）

今回みたいなのは他のライセンスで過去にも検討されてたそうだが、
全く同じ例は無いはず。webMのは他より一歩踏み込んでるっぽい。
もしくは、他と同じにするつもりが言うべきことを省いてしまって
意味合いが変わっているように思う。

現時点でYoutubeのエンコーダに蒼弓さんのチューンがコミットされてないなら、今後ffmpegにコミットされてもそれがYoutubeにも反映されるのは厳しそう。

>>177
ピッチャーがボークしてるんじゃないかって話してるときに
外野がどうとか、ほんと話の本質みえてないやっちゃなぁ

しかも情報遅いし

ttp://slashdot.jp/it/comments.pl?sid=495847&cid=1767883
バカ発見

>>173
国外の話になんでJASRACが関係すんだよ
あと、MPEG LAと一緒にすんな

>>180
なんでコミットされる話とYouTubeで使用される話が同じなんだか
コミットソースを使うとなんかの特典でもあるわけ？
オープンソースを使ってサービス提供してるなら、何らかのパッチぐらい当てるぐらい普通の事だろ

mkvtoolnixの次のバージョンでivfの入力をサポートする予定のようだ。
ttp://forum.doom9.org/showthread.php?p=1401291

2ちゃんはびっくりするほど頭が悪いやつ多いし慣れてるつもりだったが
ここまで日本語が出来ないやつは初めて見たかもしれん…

>>155
ttp://skm.vip2ch.com/-/hirame/hirame095358.jpg
ありがとう今確認したらHTML･WEBMって表示されてたからちゃんと再生されてたみたい

HTML5･WEBMだった

先に書いた件は、海外だとこんな感じで話題になってる。

元SUNでオプソに関わった人の意見
ttp://www.computerworlduk.com/community/blogs/index.cfm?entryid=2973&blogid=41
付帯条項の部分がOSIの承認を受けていないことを疑問視してる。

別の人の意見
ttp://www.robglidden.com/2010/05/how-googles-open-sourcing-of-vp8-harms-the-open-web/
標準化を重視する立場からGoogleのやり方に意見している。

他
ttp://www.zdnet.com/blog/open-source/fud-pushing-back-hard-against-google-webm/6548

特に過去SUNでオプソに関わった人達の意見は、プロプラな製品をOSS化することの
専門家だから、それなりに説得力有ると思われ。

スレチ気味なんで自分はここら辺で。
エンコードに関してテクニカルで実践的な話をしてた人達の邪魔をしてごめん。

わかってるなら他でやってくれ。

映像も音も駄目とかいきなり死亡したな

VC-1 (WMV9+α) よりはマシらしいからそれを潰す程度ならできるんじゃね？

>>190
別に死んでないだろ。まあ現時点での出来はいまいちだろうけど、
音についてはAoTuVレベルのものが使われるようになればいいだろうし、
VP8もVorbisもこれからそれなりに改良が加速するだろ。

>>191
VC-1をつぶす意味ってなんも無いような・・・。そもそも土俵が違うだろ。
VP8はHTML5のvideoタグのコーデックとして使われればいいだけだろうし。

WebM試してみたいけどFirefoxの開発版とかいれたら今使ってる正式版と競合が起きたりしそうでいやだなあ
とかいうニッチなすきまをchromeとoperaが狙っている気がする

>>193
インスコ先とプロファイル分けれ

バカポさんが、WebM rev3と、libVorbis 1.3.1を使ってビルドしたffmpegをツイッターで公開してくれてる。

　ttp://twitter.com/POP_bakapo/status/14656104457

これならlibavcodecのVotbisエンコーダを使わずに済むので音質がまともになるそうな。

WebM/VP8 DirectShow Filters v0.9.6.0
ttp://code.google.com/p/webm/downloads/list
install_webmdshow.exeとvbsmakewebm.vbsが追加されてる

>>196
あと、ちゃんとしたReadmeが追加されてますね。

0.9.5.0ではXiph.orgのVorbis EncoderフィルターをWebM Muxer FilterにつないでMuxすると
Muxerでエラーが出てたけど、0.9.6.0では問題なくMuxできることは確認しました。（GraphStudio使用）

makewebm.exeで、これらのDirectShowフィルタを使ってwebmへのエンコードが可能。
　　makewebm.exe　source.avi
って感じでやると、source.webmの出来上がり。その他オプションについてはReadmeなどを確認。
ただしコーデックによってはDirectShowのピン接続に失敗してエンコード不可となります。
（UtVideoやHuffyuvはデコータがRGB出力するので不可。
　VP6やDivXはデコーダがYUY2で出力するのでセーフ。
　WebM VP8 Encoderの入力がYUVに限られているため。）
YV12にしたavsをくわせてやるのが確実かと。
また、音声もエンコードするならXiph.orgのoggcodecs（に含まれるXiph.Org Vorbis Encoder）が必要。
・・・まあ>>195のffmpegのほうが細かい設定ができるし音質もいいだろうからmakewebmを使う必要はほぼありませんが。

Readmeを見ると、webmの音声再生にはWindowsEssentialsCodecPackに入ってるffdshowを使ってるぜ☆と
書いてあるけど、WECPって個人的にはあまり好きじゃないんだけどなあ・・・。
自動更新が売りのはずなのに去年７月のリリース以降まったく更新されてないような。
おまけにFLV Splitteｒが古いせいでH.264+AACのFLVが再生できないとかなんとか。
まあVorbisとは関係ないけども。
とりあえず自分の環境に入ってるffdshowのVorbisデコーダーは有効にしておきましょう。

ところで質問なのですが、>>195でlibVorbis系でエンコードしたVorbis音声って、
ffdshowのVorbisデコーダーで再生した場合も綺麗に聞こえるんでしょうか？
今のところXigh.OrgのVorbisデコーダーはWebM用には使えないようなのですが・・・。

>>197
>ところで質問なのですが、>>195でlibVorbis系でエンコードしたVorbis音声って、
>ffdshowのVorbisデコーダーで再生した場合も綺麗に聞こえるんでしょうか？

libavcodecが不安なら、XiphのTremorをそれの代わりに選ぶ事ができる。

手持ちの洋画DVDからリッピングしたソースからavs作って
（DGIndex+vobsub+audiodub、720x480、PAR 40:33、23.976fps)
>>195のffmpegでWebM作ってみた。コマンドラインは以下。

ffmpeg -i INPUT.avs -aspect 20:11 -qmin 22 -qmax 22 -level 100 -acodec libvorbis -ab 96000 -threads 8 OUTPUT.webm

-qmin 22 -qmax 22で固定量子化になるのかは分からないけど、とりあえずエンコードはできた。
固定画質(に近い状態)でエンコードしたい時は、このオプションで良いのですかね？
>>139のffmpegだと、-level 100で1fps@core i7 860 cpu使用率 70%しかでなかったのが、
>>195のffmpegだと、15fps@cpu使用率 50%くらい出た。cpu使用率が低いのに一桁も速度が速いのはなんでだろう…。


出来上がったファイルはVLC 1.1.0 WebMで再生できた。この情報って既出だっけ？
http://people.videolan.org/~jb/webm/

Aspect Ratioが反映されて再生できたのは良かった。
音も>>139のffmpegで金属音山盛りだったのが
全く問題なくなっててすばらしい。
蒼弓さんとバカポさんに感謝。

肝心の画質は、x264(Main Profile) > WebM > VC-1&その他大勢のコーデックって感じかなぁ。
暗所のブロックノイズが目立つ。VP8って、デブロックフィルタってあるのかな？
まだオープンソース化されたばかりだし、今後の画質向上に期待。
H.264もx264があったから、あれだけ画質向上できたわけだし、
VP8も同じようになって欲しい。

>>199

>H.264もx264があったから、あれだけ画質向上できたわけだし

おいおいｗｗ
なに勘違いしてるんだｗｗｗ

q値は1〜51っぽいな。

>>121です。
simple_encoderやtwopass_encoderの件ですが、docsの下にあるhtmlでの説明を見ると、
入力ファイルはYV12にする必要があるようです。I420のデータを渡していたのでおかしくなってた模様。
ivfencはデフォルトではI420入力なので、てっきり同じと思い込んでしまいました。失礼しました。

>>201
公式サイトにある、エンコードパラメータの説明が大幅に更新されて、細かい説明が出てました。

　　The WebM Project : tools : VP8 Encoder Parameter Guidelines
　　ttp://www.webmproject.org/tools/encoder-parameters/

--min-qとかの説明を見ると0-63みたいですね。

公式のFAQって以前からありましたっけ？見逃してたかな？

　The WebM Project : about : Frequently Asked Questions
　ttp://www.webmproject.org/about/faq/

Microsoft、IE9でVP8のサポートに言及
http://journal.mycom.co.jp/news/2010/05/26/041/index.html

＞MicrosoftからIE9におけるH.264とVP8のサポートに関する補足情報が
＞Another Follow-up on HTML5 Video in IE9 - IEBlogとして公開された。
＞Microsoftの立場を明確にする狙いがあるとみられる。（中略）

＞しかし、H.264に限定されることなく、ユーザに対してはすべての主要なコーデックを
＞サポートするとしており、VP8に関してもその枠組みでの対応になるという。

＞具体的にはWindowsにVP8のコーデックがインストールされていれば、
＞IE9でも再生できるという方法になるという。

これでFlash追い出し、HTML5で全て済ますプランは消滅か。

IE9が別途CODECインスコとFlashでのVP8対応になると
Flashが延々と残り続けて、サイト主はFlashとHTML5の
両対応を余儀なくされる

もしかしたら、IEようのTheoraコーデックとか出てくるんじゃないか？
----------------------------------------------------------------------
Flashを使うならFlash、HTML5を使うならHTML5でいいと思う。
----------------------------------------------------------------------
それともvideo要素内にFlash用のプレイヤーのタグを入れるとか？

>>205
Flash入れるのもWebMコーデック入れるのも手間は変わらないでしょ
なにをそんなに悲観的になってるの？

Google が言っているように、Flash はなくてはならないもだよ。DRMの観点からもね。

Flash嫌いのAppleはWebMに参加してないしな

>>204
それ、もとになったMSのblog記事は5/19のものだからWebMリリース直後に判明してる。
　　ttp://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
でも、それに対するコメントでも「ああん？IE9にVP8バンドルしろやゴルァ！」っつう声も出てるから、
MSが考えなおしてVP8をバンドルサポートしてくれるのを期待したいところだねえ。
　　ttp://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx#comments

>>207
HTML5のvideoタグについては
　　・映像再生をAdobeっつう１社の製品であるFlashに依存するのは嫌だ
　　・そもそもユーザーにわざわざFlashを入れさせる手間をかけてしまうのも嫌だ
　　・もちろんユーザに別途コーデックを入れさせるなんて手間をかけさせるのも嫌だ
　　・H.264っつうライセンス料がかかる技術を利用するのは嫌だ
　　・映像コンテンツ提供するほうとしても、どんなユーザ（ブラウザ）でも見れるように
　　　１つの動画についてH.264とかTheoraとか色々なコーデックで作ったものを
　　　別々に用意するのは大変なので嫌だ
っつうことで、
　　「ユーザがわざわざプラグインとかコーデックを用意することなく、どのブラウザでも再生できて
　　　ライセンス料もかからないコーデックがあればそれで解決じゃね？」
ということでVP8がオープンソースになったわけで・・・。
とりあえず>>204の記事からたどれる以下の記事だけでも見ておくといいんじゃないかな。

　　HTML5 video、ブラウザ対応状況とコーデックまとめ
　　ttp://journal.mycom.co.jp/news/2010/01/27/033/index.html

　　IE9がサポートするビデオ形式はH.264のみ!?
　　ttp://journal.mycom.co.jp/news/2010/05/06/010/index.html

　　IE9、H.264がベストな選択肢だが、ほかのコーデックの可能性も
　　ttp://journal.mycom.co.jp/news/2010/05/10/004/index.html

どうせ誰かWqaMっての作るだろww

雑談は出来れば他所で。

【開発】Googleがフリー動画フォーマット「WebM」を公開、MozillaやAdobeも支持 （10/05/20）
http://pc11.2ch.net/test/read.cgi/pcnews/1274358898/

【製品】Googleのオープン動画フォーマット「WebM」、Appleは不支持か（10/05/21）
http://pc11.2ch.net/test/read.cgi/pcnews/1274445388/

他所はApple信者の荒らしがひどいんだよね

アホン信者しかり、どこでもapple信者は大概酷い。

>>213,214
自演までしてそういう事を書くのは楽しいですか？

webmdshow-0.9.7.0-20100526

WebMこと"VP8"サポートを巡る業界動向 - Safariサポートは? 特許問題は?
http://journal.mycom.co.jp/articles/2010/05/26/google_vp8/index.html

>>216
お、DirectShowフィルタのソースが入ってますね。

>>216
インストーラーだけでax同梱しなくなったんだな

axじゃなくdllだった

>>216のv0.9.7.0から、makewebmでVP8のエンコードパラメータが指定できるようになってるっぽい。
詳細は makewebm.exe -h -v で確認できる。
ivfencで指定できてたものはあらかた指定できるのかな、これは。

Here's a mkvtoolnix build with support for reading VP8 from and writing them to IVF files:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe

テスト用

ffmpegにlibvorbis1.3マージというのはとりあえず実装がこのスレでも出てきたから、
今度はlibavcodecのVorbis周りのコードをlibvorbisベースに書き換える人が出てくれば、
ffmpegのVorbisの音質がデフォルト状態でも向上するし、libavcodec使ういろいろな
プロダクトにも好影響が出てくるので期待したいところ…

>>223
マージというか、libavcodecのVorbisエンコーダが開発される以前から
ffmpegでlibvorbisを使うことは出来たし、普通にリンクして配布している人もいた。
それでもあえて、自前の（質の悪い）エンコーダをデフォルトにしてるんだから
確信犯だと思うけどね。
基本的に自前で実装していく、というのが基本方針のようだし。

まあ、もうすぐmkvmergeが正式にwebmでの出力に対応するだろうから、ffmpeg等使わず、
ivfencで映像、oggenc(aoTuV)で音声を、それぞれエンコードしたら良い。

ivfencは謎のフレーム水増しがあるからなぁ・・・

IVFフォーマットはVP8エンコーダーのサンプル実装を開発者に提示するために作った
簡易ファイルフォーマットのようだから、実用的に使われることは無いと思うけどね。
あくまでも現時点で一番細かくパラメータを指定できるのがivfencだというだけで。

FAQにもあるようにエンコーダーのチューニングはこれからだということだし、
これから開発されていくなかで、webmへのMuxerつきのVP8エンコーダーとか、
各種ツールが出てくる可能性が高いのでは。

1fpsのAVIをAVISource()で読み込んだYV12のsource.avsをソースとして、>>89や>>195のffmpegを使って
　ffmpeg -i source.avs -vcodec libvpx -b 512k -level 300 -acodec vorbis -ab 128000 dest.webm
でwebmに変換した上で、AvsPから
　DirectShowSource("dest.webm")
で読み込んでプレビューしようとすると、"I can't determine the frame rate of the video・・・"というエラーが出ます。
また、dest.webmをplaywebmで再生すると、再生が早送り状態です。

同じsource.avsを使って
　makewebm.exe -i source.avs -o dest.webm
でwebmを作った場合はDirectShowSource()でもエラーは出ませんし、playwebmでの再生も正常です。

DirectShowSource("dest.webm",fps=1)としてやればよいのはわかるのですが、
makewebmとffmpegとで違いが出てしまうのは、ffmpegでのコマンドの指定方法がおかしいのでしょうか？
それとも他に原因があるのでしょうか？分かる方がいらっしゃいましたら教えていただければ幸いです。

なお、DirectShowフィルタは>>216のwebmdshow-0.9.7.0-20100526をインストールしています。

>>228
ffmpegに、-r 1を付けてFPSを指定したらどうか。

>>229
ありがとうございます。
　　ffmpeg -i source.avs -vcodec libvpx -r 1 -b 512k -level 300 -acodec vorbis -ab 128000 dest.webm
であってますでしょうか？
これで試してみたのですが、状況は変わらないようです。

>>230
それで駄目なら、ちょっとどうして良いのか分からない。
結局、libvpxのフロントエンドとしてのffmpegは、今ひとつなのだろう。

http://ja.wikipedia.org/wiki/WebM
http://ja.wikipedia.org/wiki/VP8

>>232
やっとできたか。

援軍ｸﾙ━━━━━━(ﾟ∀ﾟ)━━━━━━ !?
Intelに加えてBroadcomも

インテル、グーグルのWebM用ハードウェア・アクセラレーション搭載を示唆
http://www.computerworld.jp/topics/google/182889.html

＞「これまで、MPEG2、H.264やVC1といったコーデック方式に対応してきたのと同じことだ。
＞VP8がスマートTVの分野で一般的になれば、われわれもハードウェア・デコーダーを提供することになる」と、
＞Intelのデジタル・ホーム・グループでリテール・コンシューマー・エレクトロニクスの
＞ゼネラル・マネージャーを務めるウィルフリッド・マーティス（Wilfred Martis）氏は語る。
（略）
＞マーティス氏によれば、IntelのCE4100 TVチップはデコードが可能になるほか、
＞ソフトウェアによるWebMファイルの再生もサポートする。ただし、ハードウェア・アクセラレーションがあれば、
＞もっと少ない消費電力でさらに高速なデコードを高品質ビデオに提供できる。
（略）
＞多くのハードウェアとソフトウェアベンダーが、WebMファイル形式のサポートを発表しているが、
＞Intelからはまだ発表がない。Mozilla、Microsoft、Opera Softwareは、極めて初期にサポートを表明している。
＞チップ・メーカーのBroadcomは、同社のVideoCore IVスマートフォン・プロセッサに
＞WebMビデオ・ファイルのためのハードウェア・アクセラレーションを搭載する予定と語っている。

ハードウェアデコードするならH264でいいんじゃ・・・
CPU負荷関係なくなるからな。

しかもGoogleTVだと、Youtubeを想定してるでしょ？
なおさらH264のハードウェアデコードだけでいいような。

くやしいの

何も分かっていないだけでしょ。

WebMが必要になった経緯は散々書かれてるわけだし、
それを理解してるなら>>235みたいな発言は出ないはずなんだけどな。

Boradcomのは5/19の発表時点で既に判明してるよ。
Intelの表明も妥当かな。ハードの再生支援は電力効率でメリット多大だから。

youtubeの新規投稿分のHTML5 videoが1080pから720pに
ダウンしてるのが個人的にイヤンな感じ。
過去動画のトランスコード負荷が掛かってるだろうから仕方ないけど。

>>238
sono

>>238
その、WebMが必要になった経緯そのものが、
GoogleTVでは全く意味ないわけで。

GoogleのOS、Googleの提供するサービス、そしてYoutube。
どこにも「多くのOSで」「多くのブラウザで」「Web標準で」「ライセンスフリー」
という条件など必要とされない

>>241
Googleにとって必要だからやってんでしょ。
内実は分からんがね。

興味無い人は単に無視してりゃいいんじゃね？

蒼弓ノート 5/29 「FFmpeg で Vorbis のエンコードをする場合の注意点」
　ttp://www2.atword.jp/aooa/

＞なお、特別な理由が無い限り"-ab"オプション(ビットレート指定)ではなく
＞"-aq"オプション(クオリティ指定)を使用してください。

思いっきり-abで指定してた　／(＾o＾)＼

>>156や>>226が言ってる、ivfencでの謎のフレーム水増しっていうのは、
VP8の「Alternate Reference Frames （AR）」ってやつなのかな。

　Inside WebM Technology: The VP8 Alternate Reference Frame - The WebM Open Media Project Blog
　http://webmproject.blogspot.com/2010/05/inside-webm-technology-vp8-alternate.html

　The WebM Project : code : WebM Container Guidelines
　http://www.webmproject.org/code/specs/container/

このあたりで説明されてるけど、BフレームのないVP8において画質を上げるための特徴的な技術の１つらしい。
エンコーダーが複数のフレームを参照して任意にARフレームを作り出す(追加する)けど、
ARフレームはデコード時に参照されるだけのデータであって、表示はされない模様。
また、この仕組みを利用したノイズ低減（ARNR）もできるらしい。
ivfencなら--auto-alt-ref=1、ffmpegなら-altref 1 にすれば、ARフレームが有効になるのかな。

画質が上がるのは分かるが
圧縮率や配信での占有帯域の面ではむしろ不利に作用する気が

表示はされないのかもしれないが、webmコンテナーのフィルタ側からは
通常フレームかARフレームかは分からないのでは？
表示する時にカクつくか、音との同期がどんどんズレていきそうな希ガス

The AR will be marked with the invisible flag by the codec SDK.
って有るからそこは大丈夫じゃないかと。

ivfdecを使ってデコードすれば、フレーム数は元と同じ。

>>247
ttp://www.webmproject.org/code/specs/container/
をみると、ARフレームでもPTS増えているんだよね
説明のところを読むとARのデコード時間をPTSに加えるのが望ましいみたいな書かれ方だし
表示しないのにPTSが増えるのは音ズレの原因になるんじゃないかと・・・

あと、ivf形式には当然そんなフラグは無いから、ivf経由のwebm化は間違いなくズレるね
# VP8デコーダ(パーサーでも可)が組み込まれていて、ARフレームかどうかを判断しつつtimecodeを生成してるなら話は別だけど

>>249
＞説明のところを読むとARのデコード時間をPTSに加えるのが望ましいみたいな書かれ方だし

そうは書いてないと思う。該当の文を訳すなら
　　Dの表示にはARのデコードが必要だから、ARのタイムスタンプはなるべく"D-1"に近づけるべき。
だと思う。"D-1"ってのが、「ARの前にあるI/Pのこと」なのか「Dの手前のARのこと」なのかは
ちょっとわからないけど、どちらにせよ、早めにしとこうぜってことかと。

あと、PTSが増えてるっていうけど、その上の文でタイムベース(タイムスケール？)の粒度を２倍にするという説明がある。
x264の初期ディレイカットとかで使われてる「タイムスケール４倍精度」と同じ考え方じゃないかな。

タイムスタンプに詳しくないので正しい書き方かどうかはわからないけど、例えば29.97fps（1001/30000）の場合、

　AR無しの場合：
　　　timescale＝30000
　　　表示フレーム１　1001
　　　表示フレーム２　2002

　ARありの場合：
　　　timescale＝60000
　　　表示フレーム１　2002
　　　ARフレーム　3003
　　　表示フレーム２　4004

みたいなイメージになるということじゃないだろうか。こうすることにより、表示フレームに影響は出ないということでは。
"D-1"がI/Pのことだとしたら、ARのスタンプは2003とかでもいいのだろうか。そのへんはよくわからない。

>>250
説明を少し端折り過ぎた(増減逆)

あの説明が言いたいことは、ARフレームは次のDフレームのPTSになるべく近づけるべきだが、ARフレームのデコード時間を考えて、その時間を引いた値をPTSとして設定した方が良いという事だと思う
で、説明を単純化する為にあの表はARフレームのPTSをDフレームより1少ない値として設定ってしたって事じゃないかと
ARフレーム有り無しでタイムスタンプが増えるのはちとありえないかと思われ

orz
タイムスタンプが増える ×
タイムスタンプが増え方が変わる ○

訳してみた。

VP8 Alternate Reference Frames
When enabled, the VP8 encoder will at its discretion inject a new frame 〜 the alternate reference (AR) 〜
into the output prior to the frame that depends on it. There will be at MOST 1 frame added between I/P-frames.
The dependent frame (D) will always be a P-frame. The AR will be marked with the invisible flag
by the codec SDK. This frame must be decoded before D, but will produce no output on its own.

ARフレームが有効な場合、VP8エンコーダーは、「ARフレームに依存するフレーム（D）の１つ前」に、
任意に「相互参照フレーム(AR)」という新しいフレームを挿入する。
ARフレームはI/Pフレームの間に最大１枚追加される。
依存フレームDは、必ずPフレームである。ARフレームはコーデックSDKにより、不可視フラグがつけられる。
ARフレームは依存フレームDの前にデコードされなければならない(訳注：DのデコードにはARフレームの
情報が必要なため。)が、ARフレーム自身はデコードされても何も出力しない。

To satisfy the monotonically-increasing requirement, the encoder will currently set the AR’s timestamp
to 1 less than D’s. This means the time base given to the encoder at configure time must be granular
enough to allow this, e.g., at least 2X framerate.

単調増加という条件を満たすため、エンコーダーは現在ARフレームのタイムスタンプとして
依存フレームDのタイムスタンプより１小さな値を設定している。
そうするためには、設定時にエンコーダーに与えられるタイムベースは、十分な粒度を持つ必要がある。
たとえば、最低でもフレームレートの２倍にする必要がある。

Ideally the AR’s timestamp should be as close as possible to frame D-1 to allow the decoder
as much time as possible to decode AR before needing to display D.

Dの表示前になるべく多くの時間をARのデコードにまわせるよう、
理想としては、ARフレームのタイムスタンプは、可能な限り「フレームD-1（※１）」に近いほうがよい。

あ、ID変わってるけど>>250です。

>>250では、>>253の最後にある※１の「フレームD-1」を、「フレームDの１つ前のフレーム」と
解釈しちゃったけど、きっちり訳してみると、この解釈はおかしいですね。
>>251の言うように、
　　「フレームDのタイムスタンプから１引いた値(つまりフレームDになるべく近づける)」
という解釈が正しそうですね。

で、タイムスタンプの話について。かなり書き方を変えて自分の考えを説明。
相変わらず変なこと言ってたらごめん。

例えばAR無しで30fps丁度の場合は、1/30秒を１単位としてタイムスタンプを増やしていけばいいことになる。
　　表示フレーム０：　0/30秒　＝0秒
　　表示フレーム１：　1/30秒　＝0.033秒
　　表示フレーム２：　2/30秒　＝0.066秒

でも、AR有りになると、1/30秒単位では、表示フレーム０と表示フレーム１の間に
ARフレームを入れるためのスキマがない。そのため、1/60秒単位でタイムスタンプを考える。
　　表示フレーム０：　0/60秒　＝0秒
　　スキマ１(AR)　：　1/60秒　＝0.0166秒
　　表示フレーム１：　2/60秒　＝0.033秒
こうすれば、各表示フレームについてはタイムスタンプの値を変えることなく、
かつARフレームを各表示フレームの間に入れるためのスキマ１ができる。
「粒度を最低でもフレームレートの２倍」というのはこういう意味かと。

更に言うと、1/120秒単位でタイムスタンプをつけれるようにすると、
　　表示フレーム０：　0/120秒　＝0秒
　　スキマ１　　　　：　1/120秒
　　スキマ２　　　　：　2/120秒
　　スキマ３(AR)　：　3/120秒　＝0.025秒
　　表示フレーム１：　4/120秒　＝0.033秒
となり、スキマ３をAR用として使えば、ARのタイムスタンプを、よりＤフレームの
タイムスタンプに近づけることが可能になる。（この例ではＤフレーム＝表示フレーム１）
でもまあ細かくしすぎても問題があると思うので、「なるべく近づける」という表現なのかなあと。

>>251の言う「ARフレーム有り無しでタイムスタンプが増えるのはちとありえない」という言葉の意味が
よくわかってないので変なこと言ってるかもしれないけど、概念的にはこんな感じではないだろうか？

>>255
解説乙

でも"D-1"は「Dフレームとして一つ前」を意味すると思うので、
その例だとそれは表示フレーム0のことを指し、
ARを差し込むのはスキマ1の位置が推奨されているのではないかと思う
表示フレームDを作るのに必要なARを早めに準備するという意図の筈だし

タイムスタンプに基づいてイタレーションの逐次処理を行う上で、
Dの前に出来るだけ早くARを読み込んだ方が処理時間を稼げるから

>>256
ああああ、やっぱそっちなのかなあ・・・。
書いたあと、やっぱり最後の英文の訳がしっくりこなくて、どっちなんだああと悶えてた自分がいるｗｗｗ
なんかDTSとかCTSとかPTSとか交えて話せばいいのかと思って調べてたら
余計色々ゴッチャになってきてよくわからなくなってきましたですorz

ごめん、自分も正直そんなに自信無いw

the encoder will currently set the AR’s timestamp to 1 less than D’s
ってなってるから、素直に読むならそちらや>>251氏が正しい気もする。

ソースコードと実際の出力から判断するのがベストかな？
というか実用上はさほど気にする必要は無いかも。スキマのどの位置に挟むべきか云々は。

mkvtoolnix公式にはないけどdoom9にivf対応版があったので、
エンコードしたivfをVorbisを合わせてwebmで出力してみた。
なぜかi420動画で--i420オプションつけてエンコードしてみたデータでは、
色が変で画面も変なので、（avsでyuvの色に変換するスクリプト打って開いたらなぜかYV12なっているのでこっちの問題かもしれないけど）
avs製yv12をffmpegのvcodec copyにして作った拡張子yuvデータに、
--yv12とつけてエンコードしたらmux後、色は正しいけど音が出ず、高速再生された。
で、mkvで変換すると普通に再生された。
ffmpegのほうでmkvからwebmに変換すると、再生はされるけどカクカクした感じになった。

>>241
googleは広告屋なんだから、自分が何かを独占するよりも裾野が広がった方が結果的に
自分も得をするという考え方なんだろ

WebMってSEO的にイマイチなネーミングだな。

There's probably loads of ways to test this easily on windows, but in case anyone finds it useful:

http://nic.dnsalias.com/ivfenc.zip <-- is ivfenc that can take an AviSynth script
http://nic.dnsalias.com/AVSVorbis.zip <-- is aoTuV B5.7 Vorbis Encoder that can take an AVISynth script

And of course:
http://www.bunkus.org/videotools/mkv...-255-setup.exe <-- Mosu's mkvmerge that can mux to WebM
http://code.google.com/p/webm/downlo...0-20100526.zip <-- Latest DirectShow filters for playback

Then you can encode with an AVS Script like:
AVISource("YourFile.avi").ConvertToYV12()

AVSVorbis -q -2 in.avs out.ogg
ivfenc --target-bitrate=100 in.avs out.ivf
mkvmerge --timecode-scale 1000000 --disable-lacing out.ivf out.ogg -o out.webm

http://forum.doom9.org/showpost.php?p=1404210&postcount=142

なかなか便利そうだ。

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.4.0-build20100527-255-setup.exe
http://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.7.0-20100526.zip

上の二つはこうしないとおかしいな。

あとこれも。
http://nic.dnsalias.com/WebMx64.zip

bat処理で作れるようになったのは便利かな

Firefox正式版へ統合されるのは何時頃になるんだろうね
現状だとローカルなビデオコーデックの域を越えないけど
Webブラウザで自由に扱えるようになったら面白いだろうなー

VP8と対応FME配布ﾏﾀﾞｰ？

VP8と対応FME配布ﾏﾀﾞﾃﾞｨｽｶｰ？

ブラウザのVP8デコーダーも、VP8エンコーダーも全然チューンしてなくて
とっても遅いデースな現状なんだから正式版やら配布やらは当面は期待薄だと思ふんだ。

そのうちVP8/webMデコーダの性能向上を
各ブラウザが宣伝文句にする日が来るのかもしれない

>>268
Firefox 3.7alphaのnightlyには入ってきているのだから、3.7の正式版には
入ってくるんじゃない? デコーダの重さの話をすれば、Flash内蔵のH.264
デコーダだって、とても褒められたもんじゃないのだし。

ハードデコード効く相手と比べるのは酷以外の何者でもない
ソフトデコードでも現状で再生負荷はつべの720p同士で1.5倍くらい余計に掛かる
デコーダの改良は急務だよ

急務って・・・誰も困ってねーよｗ

wwww

普及目指すなら軽いに超した事はない

VP8と対応FME配布ﾏﾀﾞｰ？

ﾏﾀﾞｰ？ﾏﾀﾞｰ？ﾏﾀﾞﾅﾉｶｼﾗｰ？早くしてよまじでｷｭｰﾑﾀﾞﾖｰ今週中にﾅﾝﾄｶｼﾃｰ

No real difference, but http://nic.dnsalias.com/ivfenc.zip (v1.2)

* Updated to latest git version (with added .avs support)
* Doesn't crash when you ctrl+c to quit early now
* --timebase= doesn't do anything, but doesn't crash it now
* ARCH_X86 isn't set in vpx_encoder.c which means FLOATING_POINT_INIT/RESTORE isn't getting called (bug in the git repo code?)
* Defaulted cpu to 16 and threads to 4 - just runs faster that way, why wouldn't you want it

-Nic

デコーダ重いね、VP6時は軽いのが売りの一つだったのにVP8はh.264より重い。
普及考えたらせめてh.264レベルにもっていかないとキツイね。
Flashに実装することも考えたら今のままではカクカクになってしまう。
特にandroidモバイルで再生がキツイことになる、というか実用レベルではない。
>>271の人が言うようにデコーダの改良は急務。

そこでtheoraですよ

重いというかシングルスレッドなのがなぁ。

VP8の主要な部分は、既にSIMDアセンブリコードで十分に最適化されているから、
これ以上はたいして速くならないだろうと、Dark Shikariは言っているね。

H.264より重いとか、死亡決定だな

x264 Developerの言うことを鵜呑みにするのもどうだろう
VP8をこき下ろしたいはずだし

まだ出てきたばかりで発展途上のコーデックと
年数積んで成熟したコーデックと比べるのは酷

VP8自体の実装としてはH.264より処理が簡素だから
最適化が進めば軽くなるのは確実なので、今後の開発次第

H.264に携わってる側からしたらVP8は目障りなので
粗を探してはこき下ろすのは立場として当然ではある
彼らの主張は話半分に聞いておくべき

そもそもH.264がWeb上の標準ビデオコーデックとして
不十分だったからこそWebMが誕生した経緯があるわけで
世に出てからそれこそ何年経ってるんだという話になる

VP8はベストな選択肢じゃないが、他よりマシな選択肢

あれ？
x264 DeveloperのDark Shikariってグーグルから開発参加してくれって打診されたんじゃなかったっけ？
どっかで見た気がするんだが記憶違いか？

特許が無効になるまで、H.264が無料で使える事はないし、VP8には私も期待している。

ただ、DSが言っていることはおそらく正しいと思うし、VP8に過剰な期待はしない。

VP8の存在意義は「ロイヤリティフリーであること」、これに尽きる

逆に言えばweb配信の標準コーデックとしてH.264に足りなかったのは
その1点だけで有って、他に特に重大な欠点がある訳じゃないと思う
配信用途にも使われる事は仕様策定時に十二分に考慮されてる訳だし
むしろ「ちゃんとした標準化手順を踏んでいる」という点では上

VP8は仮にも実績の有る企業が代を重ねて作り上げた有償の技術がベースなのだから
改善の余地に関してはそうそう楽観視も出来ないと思う
今有るブラウザ内蔵のソフトデコーダ同士で2-3倍近い負荷の差は
そう簡単に埋まるとも思えない

ところでffmpegでARフレーム（altref）オプションの有無を試してみたんだが、
出力されるファイルサイズがごく僅かしか変化しない。なんでだろ？
途中結果を見るとfpsが倍の値に設定されたり適切に変化してるんで
全く働いていない訳では無さそうなんだが…

著作権程度の意味合いでロイヤリティフリーであっても
パテントフリーかどうかは未確定だ

そこら辺がどうなるかはまだ分かんないね。
Mpeg LAも遠回しにパテントプールの用意云々言ってるだけで、
具体的な特許侵害の有無に関しては何も触れてないから。

ARフレームの有無でファイルサイズにわずかな変化しかないと言うことは、結局のところ、
20%以上の圧縮率の向上が見込めるBフレームと比べたら、効率が悪いやり方なのだろう。

>>291
う、その結論はちと待ってくれ。正しく比較できてるかどうかすらまだ自信が無い。
だから他に試した人の話が聞きたかったんだ。

一応フォローしとくと、
原理上はBフレームには及ばないのは確かだろうけど、
再生負荷と画質向上のトレードオフでは
適度にバランスした技術の可能性は有ると思う。

>>292
ARフレーム有り・無しを同じビットレートでエンコードして、
これを使ってSSIMを比較する事ができる。無料版はSDまでしか使えない。

x264の--tune ssimと比較しても面白い。

http://www.compression.ru/video/quality_measure/video_measurement_tool_en.html

test

>>293
情報サンキュ。

>I've released mkvtoolnix v4.0.0. This release features full support for the WebM variant
>of the Matroska container format, VP8 video tracks, the IVF container format.

http://www.bunkus.org/videotools/mkvtoolnix/

おおお・・・地味にサポートが広がってるな

webmがLGPL/GPL互換ライセンスに変更されたらしい。

Changes to the WebM Open Source License
>ttp://webmproject.blogspot.com/2010/06/changes-to-webm-open-source-license.html

ライセンス上はPure BSDだそうだ。特殊条項が無いけど、パテント周りで
ホントにGPL互換って言っていいのかな。

ﾏﾀﾞｰ？ﾓｳ･･･ﾏﾃﾅｲﾖ・・・

>>296
糞重くてDLできねー

>>300
CRC32: 3F4BDC2E
MD5: 7EDB99C79952CFDDB1D25816274DD749
SHA-1: 8078971EC14F2573666A746F92DCE9240FA1B822

http://www.mediafire.com/file/zjdmmyky1w3/mkvtoolnix-unicode-4.0.0-setup.exe

>>298
例の「採用したら訴訟すんなよ！」の条項は削除されて
完全にBSDライセンス準拠になったということらしい

Google自身が訴訟のリスクを背負うことにはなるが
業務用途含め、普及を考えたら妥当な判断かもしれない

>>298

>>188や下記にあるようにOSI未承認な部分が問題視されてたから
その対策だと思う

Google open codec 'not open,' says OSI man
ttp://www.theregister.co.uk/2010/05/24/osi_board_member_on_google_webm/

WebM: Missing The Assurances Open Source Needs?
ttp://www.computerworlduk.com/community/blogs/index.cfm?entryid=2973

他のオープンソースのプロジェクトで
WebM関連のサポートを取り込むのに
ライセンス上の問題が懸念されてたから
これで解決して開発も加速しそうだな

VP3が元のTheolaハブってんじゃねーぞクズ共！！！！！！１１１１

吠えるならスペルくらいちゃんとしなよ、お猿さん

しかも、激昂し過ぎて後ろの方、SHIFTキーから指離れちゃってるしｗ

いや・・・１１１はネタだから
って説明した俺南無

07 6 月 Rockbox 3.6　他雑記
ttp://www2.atword.jp/aooa/
/Tremor

Rockboxにも使われているXiph.orgのTremorライブラリ(整数演算OggVorbisデコーダ)ですがこちらも独自にARMアーキテクチャ向けの最適化が進んでいます。
メイン開発者はTremolo/theorarmの作者で、もとは趣味で独自に開発されていたようですが、Googleがスポンサーに付いたことで本格的に開発が進んでいます。
同時にライセンスはGPLからBSDスタイルライセンス(修正BSD)に変更になりました。

どのくらい高速化するのか楽しみですね。

/WebM

ライセンスと言えば、一部で物議を醸していたWebMのVP8コーデックのソフトウェアライセンスですが、特許周りの条項が削除されました。
新しいライセンスはほぼ修正BSDライセンスです。そのため、GPLなプログラムとリンクして配布できるようになります。

Googleは現実的な対応をしてきた感じです。法的なリスクも大事ですが、敷居を下げることも同じくらい大事です。
使う人がいなければ絵に描いた餅になりかねませんから。
これで対応ソフトが増えるといいなあ。

MiiroコンバーターがこまめにVerUpしてるな
簡単にWebMエンコしたいならおすすめ

>>310
シンプルでいいなこれ

WebM/VP8 DirectShow Filters v0.9.8.1
ttp://code.google.com/p/webm/downloads/detail?name=webmdshow-0.9.8.1-20100608.zip

あんまりダウンロード数多くないね。ライセンスの問題がネックだったのかな？
変更してから急に伸び始めた。

DirectShow更新か。しかしまだChangelogがついてないから何が変わったのかわからんな・・・。

DSFはffdshow待ちの人も多そうだ。にしても、ffdshowのchangelogにはupdate ffmpegとか
頻繁にあるのに、まだVP8に対応していないのはどういうこっちゃ。

　　　　　　ﾌﾞｲﾋﾟｰｴｲﾄﾏﾀﾞｯﾏﾀﾞｯ?♪
　　　　　　＼　　　ﾌﾞﾌﾞﾌﾞﾌﾞｲﾋﾟｰｴｲﾄﾏﾀﾞｯﾏﾀﾞｯ?／
　　　　　　　　　♪＼(^o^)　♪
　　　　　　　　　 ＿　 ) 　> ＿ ｷｭｯｷｭ♪
　　　　　　　　／.◎。／◎｡／|
　 ＼(^o^)／.|￣￣￣￣￣|　 | 　＼(^o^)／
　　　 )　 )　 .|　　　　　　 　|／　　　ノ　ノ
((((　 >￣ > ))))　＼(^o^)／　(((　<￣<　))))
　　　　　　　　　 　 　 )　　)
　　　　　　　　　(((　　>￣ > ))))

>>314
Changelog:

*Fixed bug when webmmux filter not connected to file writer.
*VP8 encoder filter now has a preview pin.
*VP8 encoder filter now supports FORMAT_VideoInfo2.
*VP8 encoder filter now allows you to set config on-the-fly, while
graph is running.
*VP8 encoder filter added support for spatial and temporal resampling config.

K-Liteの方にVP8サポート入ってるね
バージョン6.0.0で追加ってのが…明らかに狙っただろう？ｗ

SolveigMM MatroskaSplitter/Muxerも、WebMに対応した。
http://forum.doom9.org/showpost.php?p=1407145&postcount=65

>>317
うお、ありがとうございます。このChangelogってどこに載ってるんでしょう？

>>320
https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/0472d4ee2e2dd0ba#

>>321
ありがとうございます。

7-Zip File ManagerでWebM/VP8 DirectShow Filtersのインストーラーからdll取り出すことが出来た
mpchcとかでフィルタだけ登録したい人はこれでどうぞ

>>323
5つほどあるんだけど次のうちどれ？
vp8decoder.dll
vp8encoder.dll
webmmux.dll
webmsource.dll
webmsplit.dll

普通に考えてvp8decoder.dllじゃねーの

>>324-325
いや、どれもなにも全部がそれぞれ名前どおりのフィルタだから。必要なもんだけ使えばいいんじゃねえの。
ちなみにインストーラでインストールすると、これらのDLLが
　　C:\Program Files\Common Files\WebM Project\webmdshow
に置かれる。

http://get.adobe.com/jp/flashplayer/

10.1来たぞクズ共

全くこのスレと関係ない話題だな

複数の動画ファイルを“WebM”形式へ手軽に一括変換「Free WebM Encoder」
AVI/MP4/FLV/WMV/MOV形式の動画を変換可能
ttp://www.forest.impress.co.jp/docs/review/20100611_373436.html

細かい出力設定などは一切なく、変換元の動画を解像度などを保ったまま
“WebM”形式へ変換できる。利用方法も簡単で、動画ファイルを本ソフト
のリスト画面へドラッグ＆ドロップなどで登録し、出力先を指定したあと
で［Convert to WebM］ボタンを押すだけでよい。

リスト画面には複数の動画ファイルを登録可能で、一括変換にも対応している。
手持ちの動画ファイルを手っ取り早く“WebM”形式へ変換したい場合に活躍
するだろう。


設定一切無しという漢っぷり

>>328
FlashでWebM対応するのは11以降だろうからねい。

>>329
自分で試しに使って見てるけど、恐ろしいほどエンコが遅い
普通にffmpeg.exeでエンコしてるようだが、
エンコのオプション設定(設定項目さえなし)が高画質側になってるんだろうか

マルチコアは使ってくれるがCPU負荷は100%にならず50%程度でふらふら

これとかMiroとか正直クソだと思う・・・

OSXだとMiroの中のffmpegをコマンドラインから直接叩いて使うと楽

>マルチコアは使ってくれるがCPU負荷は100%にならず50%程度でふらふら

それシングルコアや

>>334
クアッドコアなんだろう。

>>332
お前的クソじゃないのは何がある？

実用的なのはffmpegしかないだろ

そのffmpegでも音声エンコードをlibavcodecではなくlibvorbis使うようにしないと
悲惨なことになるしなぁ。

　　　　　　　　　　,;r'"´;;;;;;;;;;;;;;;;;;;;;;;;;;｀ヽ、
　　　　　　　 　,r'";;;;:::::;彡-＝―-=:､;;;;;;ヽ、
　　　　　　　　/;;ィ''"´　 _,,,,....ﾆ、 ,.,_ ｀ヾ;;;;〉
　　　　　　　　 `i!::　,rﾆ彡三=､' ﾞ''ﾆ≧=､!´　　VP8対応FMEまだかよ･･････
　　　　　　　　r'ﾆヽ, 　 （　・ｿ,;　（､・')　　i'
　　　　　　 　 ll' 'ﾞ　,;:'''"´~~,f_,,j　　ヾ~`''ヾ.　　久しぶりに･･････
　　　　　　　　ヽ) , :　　　 ''"　`ー''^ﾍ　　 i!
　　　　　　　　ll`7´　　　 _,r''二ニヽ. 　 　 l　　キレちまったよ･･････
　　　　　　　　!:::　　　　 ^''"''ー-=ﾞゝ　 　 ﾘ
　　　　　　　　l;:::　　　　　 ヾﾞﾞ`^''ﾌ　　　 /
　　　　　　　　人、　　　　　 ｀ﾞ’ﾞ::.　　　ｲ

>>334
うちはクァッドコアだけど、全コアCPU負荷50%前後で推移。
恐らくエンコ中にあるシングルタスク何かが足引っ張ってるんだろう

でもFree WebM Encoderは、画質はなかなかいいな

Nicのivfenc + mkvmergeが使いやすい。

ivfdecって、オプションでデブロックとかノイズ付加とかを指定できますけど、
デブロックはともかくノイズ付加（--noise-level）って、どういった目的に使うものなのでしょう？

>>342
VP8だと、Psy-RDを使えるx264とは違って、フィルムグレインを保持する事は無理だから、
エンコードで潰れてしまった物を、デコーダで再現させると言うことじゃないの。

ivfdec -y -o output.y4m input.ivf とすれば、YUV4MPEG2で出力できるので、
RawSourceで読む場合に、解像度やフレームレートの指定が不要になって便利。

http://www.mediafire.com/file/nywzdln4ouu/ivfdec-win32.7z

>>343
ありがとん。しかし聞いておきながら知識が及ばずよくわからないバカなオイラ。勉強しときます。

>>344
そのファイル、出所はどこ？

>>345
gitで取得したソースを、私がコンパイルした。

>>346
オリジナルでしたか。失礼しました。Doom9あたりと思い込んでしまった・・・。

mkvtoolnix 4.0.0を使ってみたのですが、なんだか音声の再生がうまくいきません。
状況は下記のとおりです。おかしな点があればご指摘いただけないでしょうか。

　１．音声つきのAVIをAVISource()で読み込んでConvertToYV12()して、
　　　そのavsをWebM DirectShow Filter 0.9.8.1のmakewebm.exeにD&Dしてwebmファイルを作成。
　　　　　→playwebm.exeで映像も音声も問題なく再生される。

　２．mkvtoolnix 4.0.0のmmg.exeでGUIを起動。
　　　入力タブに１のwebmファイルをD&D。映像トラックと音声トラックにチェックがついていることを確認。
　　　グローバルオプションタブで、「WebMの規格に準拠したファイルを作成する」にチェックを入れたうえでMux開始。
　　　出力ファイル名も変えてあるので、とくに警告等は表示されず、webmファイルが作成される。
　　　　　→MediaInfoで見ると、映像トラックも音声トラックも存在する。
　　　　　→playwebmで再生すると、音声が出ず、映像も後半が早送り状態になる。
　　　　　→GraphEditでフィルタの組み合わせをテスト。
　　　　　　　・公式のWebM Source FilterやWebM Splitter Filterを使った場合は、
　　　　　　　　映像も音声もちゃんとグラフ構築されるものの、音が出ず映像も後半早送り。
　　　　　　　・Haali Media Splitter(2010/5/20版)を使った場合は音も映像も問題なく再生される。

　参考：mkvtoolnixのメニューから表示したコマンドライン

　　　　"mkvmerge" -o "D:\\output.webm" "--webm" "--language" "1:eng" "--default-track" "1:no"
　　　　　　"--forced-track"　"1:no" "--display-dimensions" "1:512x384" "--language" "2:eng" "--default-track" "2:no"
　　　　　　"--forced-track" "2:no" "-a" "2" "-d" "1" "-S" "-T" "--no-global-tags" "--no-chapters"
　　　　　　"D:\\input.webm" "--track-order" "0:1,0:2"

　　　　※デフォルトトラックを両方「はい」にしたりもしてみたのですが駄目でした。

元々はmkvtoolnixでivfファイルとaoTuVの音声をマージしてみたかったのですが、
それも同様の現象だったため、正常なwebmファイルをソースとしてやってみました。
単に自分がmkvtoolnixの使い方を間違えているのでしょうか。

よくわかってませんが、自己解決したっぽいです。

>>262を見て、mmg.exeのメニューの「Mux→コマンドラインオプションを追加」で
--disable-lacingを追加したら問題なく再生されるようになりました。

オプション追加時の--disable-lacingの説明を見ると、
　　「全てのトラックで複数のフレームを1つのブロックにまとめません。
　　　これは特に多数のオーディオトラックがある場合に、ファイルサイズを増大させます。
　　　テスト目的でのみ使用してください。」
と書いてあるのですが、webmの場合はmkvmergeで--disable-lacingをつけるのは
必須ということになるのでしょうか？

>>349
Haaliのスプリッタでは、--disable-lacingは不要だが、公式のwebmsource.dllは、それを必要とする様だ。
互換性を重視するのなら、--disable-lacingをつけておくのが無難じゃないだろうか。

regsvr32 /u "C:\Program Files\Common Files\WebM Project\webmdshow\webmsource.dll"

再生にHaaliを使いたい場合は、こうして外す事もできる。

>>350
なるほど。重ね重ねありがとうございます。

Opera10.6ベータがHTLM5+WebM対応

Firefoxは3.7待ちだけど、3.6.4のリリースすら遅れに遅れている現状、
いったいいつになることやら…

最近、Firefoxの開発ペースの遅さが目立つよね
なんかトラブル抱えてるんだろうか

3.7（実質4.0）alpha 5は公開されてるね
webMの再生負荷は特に変化無しかな

WebM/VP8に対応、「FFmpeg 0.6」がリリース
ttp://sourceforge.jp/magazine/10/06/17/0953209

FFmpeg 0.6
ttp://ffmpeg.org/

>>355
いまやアドオンのためにFirefox使っている人がほとんどだろうから、
ほとんどのアドオンが対応していないalpha版じゃ意味が無いんだよなぁ。
正式リリースされてさえ、メジャーバージョンアップ後だと1ヶ月ぐらいは
アドオンが対応しきれないし。

この辺、アドオンはJavaScriptベースなのでやれることは限られているけど
互換性はいいGoogle Chromeとは違うところ。

と、スレ違いの話題はさておき、ブラウザ内蔵のVP8デコーダは当分は
再生負荷が下がるようなことはないだろうなぁ。

Nightly使ったことないんだけどFirefoxってOggも含めて再生品質は向上してるの？

H.264の様に、GPUを使ったVP8のデコードができる様になると良いのだけどね。
たくさんのベンダーがハードウェア支援に取り組んでいると書いてあるが、いつになることやら。

あと、VP8のビットストリームは、今後変更されると言うし、
今指摘されている欠点の幾つかも直されるのだろう。

http://webmproject.blogspot.com/2010/06/future-of-vp8-bitstream.html

>>359
GPU使おうとしても、現状DXVAでは当然対応していないから、CUDAのように
GPUを汎用コンピューティングに使う方面でやるしかない。NVIDIAのGPUを
載せているような環境ならCPUデコードでもスカスカ行く場合がほとんどだろうし、
そもそもサポートプラットホームがあまりにも限られすぎちゃって無意味に近い。

ってことで、MSがDXVA decoder profileにVP8を入れ、GPUベンダーがそれに対応
したドライバを作るまでは、PCでのハードウェア再生支援は考えない方がいいと思う。

>>360
>CUDAのように
>GPUを汎用コンピューティングに使う方面でやるしかない

それはエンコード支援には良いだろうが、
デコード支援としては正直あまり向かないと思われ。
汎用ユニットをそちらに割り当ててしまうと、
その分本来のGPUとしての能力が低下するから。
PCだと動画見ながら他にも色々する訳だし。

別に用意してある専用ロジック回路で得られる高効率性こそが
ハードデコードの真価であって、GPGPUで代用は出来ない。

今時のPCのスペックなら再生支援不要だしな。
必要なのはスマートフォントかモバイル機器だな。

libvpx 0.9.1が来てた。

　　Downloads - webm - Project Hosting on Google Code
　　ttp://code.google.com/p/webm/downloads/list

2010-06-17 v0.9.1
- Enhancements:
* ivfenc/ivfdec now support YUV4MPEG2 input and pipe I/O
* Speed optimizations
- Bugfixes:
* Rate control
* Prevent out-of-bounds accesses on invalid data
- Build system updates:
* Detect toolchain to be used automatically for native builds
* Support building shared libraries
* Better autotools emulation (--prefix, --libdir, DESTDIR)
- Updated LICENSE
* http://webmproject.blogspot.com/2010/06/changes-to-webm-open-source-license.html

>>344でも書かれているように、ivfencとivfdecでYUV4MPEG2が使えるようになってますね。

WebM形式へ動画を変換可能になった動画一括変換ソフト「XMedia Recode」v2.2.3.9
ttp://www.forest.impress.co.jp/docs/news/20100618_375377.html

で、どのくらい速くなったの？

avs2yuv source.avs -o video.y4m
ivfenc video.y4m video.ivf --target-bitrate=1000
wavi source.avs - | venc -q0 - audio.ogg
mkvmerge --disable-lacing --webm video.ivf audio.ogg -o output.webm

http://akuvian.org/src/avisynth/avs2yuv/
http://code.google.com/p/webm/downloads/detail?name=vpx-vp8-debug-src-x86-win32mt-vs8-v0.9.1.zip&can=2&q=
http://sourceforge.net/projects/wavi-avi2wav/
http://www.geocities.jp/aoyoume/aotuv/index.html
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows

Nicの物ではなく、公式バージョンのivfenc(libvpx-0.9.1)でやるとすると、こんな感じか。

>>361
今のGPUが専用回路でデコードしている、というソースある？
普通にシェーダでやってると思っていたんだが

Google Chrome Ver 6.0.437.3 devってやつでyoutubeのwebm動画みてみた
他のwebm対応ブラウザよりCPU負荷が低くてFlash動画より負荷が高い感じだった

>>367
UVD（再生支援回路）の位置に注目
ttp://pc.watch.impress.co.jp/img/pcw/docs/317/271/fig02.jpg

そういうわけで専用回路でデコードしてるために、
再生支援の性能は3D（シェーダ）の性能じゃなくて専用回路の世代に左右される
一シリーズ前のハイエンドより現行シリーズのミドルレンジの方が
再生支援性能が高いって事も結構あるしね

ただし同じ世代なら必ず性能が一緒ではなく、
機能が制限されていたり（ダイナミックコントラスト等）、スループットが異なっていたりするのがややこしい

【笠原一輝のユビキタス情報局】 Blu-ray 3DをPCで楽しむための要件
ttp://pc.watch.impress.co.jp/docs/column/ubiq/20100122_343853.htm
＞VP4でもすべての製品で大丈夫かと言えばそうではないようだ。
＞「GeForce GT 210に関してはスループットが足りないので、
＞Blu-ray 3Dの再生には対応することができないだろう」(Beaulieu氏)と、
＞GT21xのシリーズでも上位SKU(GT240/220)と
＞今後リリースされるGF100ファミリーが現時点ではBlu-ray 3Dでサポートされる可能性が高いという。

サイバーリンク、3D動画再生に対応した「PowerDVD 10」 -AV Watch
ttp://av.watch.impress.co.jp/docs/news/20100315_354931.html
＞NVIDIAのGPUを使ったハードウェアアクセラレーションを利用するためには、
＞GT21xまたはGF100のVP4以降のGPU(96基以上のピクセルシェーダコア)が必要で、
＞要求GPUとしては、GeForce 240GT以上のVP4世代GPUを挙げている。

結局GT215コア以上のVP4じゃないとBlu-ray 3Dのスループットは満たせないようだ。

Nvidia PureVideo - Wikipedia, the free encyclopedia
ttp://en.wikipedia.org/wiki/Nvidia_PureVideo
＞GT 210　GT218
＞GT 220　GT216
＞GT 240　GT215

Unified Video Decoder - Wikipedia, the free encyclopedia
ttp://en.wikipedia.org/wiki/Unified_Video_Decoder

>>367
汎用シェーダ＋ソフトウエアでは専用回路と比べて効率が著しく低いし、
現状のCUDAの例だとGPGPUとしてユニットを使ってしまうと
GPU本来の性能が激減する（再描画が遅くなる）から現実的でないよ

エンコなら別に構わないけどデコードでの利用は難しい
また電力効率の観点から見ても厳しい

>>369
ごめん。ゲフォユーザなんだ。ゲフォのブロック図見ても、それらしいのが無くて。
…と思ったけどあった。PVP。
http://www.nvidia.co.jp/page/purevideo.html
GPUでVP8デコーダ書こうと思ったけど早速雲行が悪くなってきた…

まずGPGPU対応のエンコーダを書いてくれた方が需要有ると思う

>>373
ん？昔書いたけど使いもんにならなかったが、何か？

>>373
GPGPUでエンコードが凄い加速する！
というのはnVidiaが付き続けてる嘘の一つ

実際は、多くのフォーマットでGPUはエンコには使えない
無理に使ってもスピードでないし

>>371
効率が低いと言ってもGPUのシェーダーパワーはどんどん上がって
きてるから、最近ではシェーダ使っちまえという流れになってる。

RADEONの今月のドライバでは、
モスキートノイズ軽減、ブロックノイズ軽減にGPUのシェーダーを
積極的に使うようになって、動画再生品質が向上してる。
FlashでH264再生するときも勝手に効いてる

そもそも動画再生とGPU負荷の高いゲームを同時にやるとか
意味不明なシチュエーションを持ち出して否定するのって、なんか意味あんの？

>>375
それ専用回路でデコードの大半の処理をした上で更に追加でやる処理でしょ。
再生支援のメリットの一つで有る電力効率の高さは
専用回路がベストなのは間違いないし。

＞意味不明なシチュエーションを持ち出して否定
意味不明。流石にそこまでのシチュは想定してないよ。

>>375
> RADEONの今月のドライバでは、
> モスキートノイズ軽減、ブロックノイズ軽減にGPUのシェーダーを
> 積極的に使うようになって、動画再生品質が向上してる。

それは再生支援じゃなくて画像処理だが

CUDAでVP8デコーダを実装出来るほどのコーディングスキルの有る人なら
今有るCPUベースのソフトデコーダのアルゴリズムの改良や最適化を進める方が
現状ではより優先度高いし歓迎されると思うよ

それじゃ夢がない

HPC市場でも大惨敗中のnVidiaのCUDAとかどうでもいいよ

惨敗中なのに東工大はTSUBAME2.0でCUDA使うの？ｗ

あそこのスパコン責任者がnVidia教だからな
わざわざ東工大で高校生向けnVidia CUDA講座とかやってんだぜ？

無理やりFermi使ってTSUBAME2造ったのはいいけど、水冷だもんなｗ

よそでやってくれ

>>375を改めて読むと支離滅裂だな

>実際は、多くのフォーマットでGPUはエンコには使えない
>無理に使ってもスピードでないし

CPUの方が速い場合が多いからね。
でもそれならさ、

>効率が低いと言ってもGPUのシェーダーパワーはどんどん上がって
>きてるから、最近ではシェーダ使っちまえという流れになってる。

そっちもCPUでやるべきだよね。

えっ

>>384
普通の読解力なら、「前半はエンコの話、後半は動画再生支援の話」
くらいは読み取れるもんだ

>>386
読み取った上での話。
その二つの話で自分の意見に都合の良いように別々の状況を前提に考えてるから。
しかも後半は間違いも含んでるしね。

グーグル、動画コーデック「VP8」の大幅改良への取り組みを早くも開始
ttp://japan.cnet.com/news/service/story/0,3800104747,20415462,00.htm

Googleのこういうアグレッシブな面は評価できる

ブランチ作っただけでニュースになるGoogle

このままでは到底使い物にならないとはいえ、早くも動いたか。

オープンソースになったのにオープンソースコミュニティの動きが鈍いんじゃないの？
しょうがないからGoogle自ら動かざるを得なかったと。

コミュニティと言ってもWebM/VP8に関わってるのはほとんどがGoogle社員でしょ？

アグレッシブと言うよりは、元々のローンチ時の問題に思う
出たばかりなのにもう仕様変更の話が出てしまうのは
問題の多さを物語ってるようなもので良い事じゃない

こういう風に見切り発車で完成度が低いまま投入→短期間で仕様変更
っていうのは、特にハードベンダーに取っては迷惑な話でしかないし
Fixされた仕様を待つのが得策と判断してずるずると計画が先送りされかねない

元々は標準化に必要なオープンな場での仕様策定過程を経ずに
私企業が独自開発したクローズドなコーデックを買い取ってOSS化した
その経緯自体がそもそもの問題の根源だと思われ

本来は有る程度の準備期間を設けてブラッシュアップに取り組むべきだったと思うが
2012年に予定してるHTML5勧告までの残り時間が少ないから急いだのだろうな
ハードデコード有効化への準備期間としてはぎりぎりのラインだろうし

ひとりひっしなひとがいます

ハードのサポートなんて最後だろ
最初にブラウザに搭載されて地雷発動しない事を確認するまでは
専用ハードなんて危なっかしくて開発できないと思う

その辺の不安を取り除く意味で
最初の発表時に「これが正式な仕様です」と明言していた訳だが…
この流れだとその発言自体微妙になるな

ttp://japan.cnet.com/news/media/story/0,2000056023,20413691,00.htm

Bフレーム無し、AQが困難な量子化、強度を変えられないループフィルター等、
今のビットストリームの欠点が改良されるのは、私としては歓迎したいところ。

VLC 1.1.0正式版リリース
WebMコンテナ、Vorbis、VP8のデコード＆エンコード対応

VP8/WebM標準対応の「FFmpeg 0.6」(Works with HTML5)が公開
http://journal.mycom.co.jp/news/2010/06/22/069/index.html

FFmpegプロジェクトは、最新版にあたる「FFmpeg 0.6」を公開した。
開発コード名「Works with HTML5」が示すように、同バージョン最大のアップデート内容は
VP8/WebMのサポートと、Ogg TheoraやH.264といったHTML5動画で使用されるコーデックの高速処理化だ。

FFmpegは、動画フォーマット変換機能を持ったオープンソースのツール。
libavcodecなどの各種ライブラリから構成されており、VLCやMPlayer、Perianなど、
さまざまなオープンソースの動画再生プレイヤーなどで利用されている。

5月下旬のGoogle I/OでVP8の「WebM」としてのオープンソース化が発表された際、
FFmpegのWebM対応パッチの提供が行われていたが、最新バージョンの0.6ではこれに標準で対応したことになる。

また、前述のようにTheoraやH.264の処理速度が大幅に向上しているほか、
Vorbisデコーダに関してメジャーアップデートが加えられているという。
詳細についてはFFmpeg 0.6のリリースノートを参照のこと。

例のVorbisエンコードがおかしかった問題も修正されてるっぽいですね

>>400
>>356でｶﾞｲｼｭﾂ

アホン信者は敵へのネガキャンが凄いからなぁ。

mpchcもWebMとVP8に対応したね
フィルタ登録する必要が無くなった

FFmpegがVP8のネイティブデコードに対応
http://slashdot.jp/it/article.pl?sid=10/06/24/0452249

＞またx264のJason Garrett-Glaser氏もSIMD最適化の面で協力している
批評だけじゃなくて協力もしてるのか
偉いな

ほんとすごい大学生だ

dark shikariはVP8そのものは糞扱いしてたけど、HTML5に使えるフリーライセンスな
コーデックを開発しているGoogleの試みに対しては好意的だったし、
引用されて光栄に思えばいいのかむかついたらいいのかわからないとか言ってて
ジョブズのことは大嫌いみたいだからな

jobsがどうとかは
このスレ的にどうでも良い話なんで出来れば止めて頂きたい

こういう開発の柔軟性は、オープンソースのいいところだな
FFmpegへ正式に統合されたから二次利用で採用が加速しそう

MPEG-LAによるパテントプール作成、急いでほしいよね
オレ様認定特許フリー宣言だと、ちょっと不安だよね

ffmpegが対応したとなるとffdshowにも反映されるかな？

>>412
MPC-HCはすでにffmpegのVP8デコーダーを内蔵デコーダーに取り込み済みだから
ffdshowもすぐにやると思う
あの２つは開発者が結構かぶってるし

このまま順調にいけば知らず知らずのうちに対応が進んでそうだな
というか各種オープンソースプロジェクトでの対応完了が早すぎｗ

その為のオープンソースだろ〜

「Opera 10.60」正式版公開、「WebM」動画フォーマットに対応
ttp://internet.watch.impress.co.jp/docs/news/20100701_377992.html

異常なまでにどうでもいいニュースだな

>>417
サードのサポってかなり重要な話だぜ

Opera最強伝説

>>417
めちゃくちゃ重要だが・・・
携帯機含めるとOperaのシェアってめちゃくちゃでかいぞ

YouTube、当面はFlash Playerをメインに――HTML5はまだ発展途上と説明 - ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1007/01/news024.html

あんま関係ないけど一応。

ということはOperaが正式版でWebMをサポートした最初のブラウザになるのか。

いくらブラウザ側がサポートしようと
Youtubeみたいな大御所が動かないとほとんど意味ないな

「この先大御所が動くことはない」とも100%言い切れない

VP8とYouTubeの両方ともが、Googleの所有するサービス

Youtubeはもう一部の動画はWebMで見れるよ

ffdshow tryoutがr3493でVP8デコード対応した

WebMの本格的な普及はIE9用のコーデック待ちかもしれない。

今んとこMSはWebMに興味ないからなぁ
MSはH264派だし

いやVC-1派だろう

IE9のHTML5動画再生、H.264に加えオープンソースのVP8もサポート - ITmedia News
http://www.itmedia.co.jp/news/articles/1005/20/news050.html

別途コーデックをインストールする必要があるがIE9でもサポートするってさ。

だから、別途コーデックをインストール必要があるというのは
WebM非サポートと同じなんだってｗ

プラグイン無し、ブラウザ単体でデコード出来るのがWebMの最大の売り
なんだから。

じゃあ非対応ということでいいや。
ところで、SafariはコーデックをインストールするとWebMが見れるってことはないよね？

>>432
じゃあ世の中の全てのブラウザは「Flashに対応していない」てことになるぞ
ニコニコ動画とかは「プラグインで見る」わけか
そんな言い方するやつは誰もいないけどな

FlashならH.264とWebM（予定）を両方見れるが
html5だとブラウザごとに両方用意しないといけなくなる

MSのWebMに対する態度は
現状では「消極的対応」と言ったところ

IE9のGPU活用による高速化の一環として
DxVA経由でのH.264再生支援も効くようになるから
サポートレベルや注力度合いではそちらの方が扱いとして上なのは確か
Win7でも既にH.264は標準コーデックの一つのような扱いだし

今のブラウザ戦線はHTML5など標準技術への対応度の高さと
JSエンジンの高速化などを軸に争ってる
MSはIE9でその舞台に再び上がって汚名挽回＆性能面でのガチンコ勝負を仕掛ける…筈

WebMはこのまま行けばHTML5 videoに採用される可能性が高いし、
標準対応の一環として
その有力候補に対して一定のサポートを表明するのは自然な事だと思う
実際の対応内容はともかく、イメージ戦略的にも

>>435
そんなにいやか
そんなに面倒か

汚名挽回・・・IE6の再来ということか

MSはサービスパックに最新のIEを入れておいて欲しい
そうすれば古いIEが居残ることがなくなるのに

あとの問題はAppleか

>>437
動画サイトでストレージを倍用意しないといけなくなる
もちろん動画形式変換もしないといけなくなる
コストは莫大だと思うが？

>>433
Quicktime丸投げだからXiphQT入れてればOgg再生できるよ。
ただWebMはQTコンポーネントがまだ存在しないけど。

>>434
ChromeはFlashが組み込まれたからインストール不要

>>434
＞じゃあ世の中の全てのブラウザは「Flashに対応していない」てことになるぞ

話の本質をなんにも理解してないんだな。。。

Flashなどの1社のプラグインに頼る現状を打破しよう、
Web標準技術だけで完結できるようにしよう。
業界が目指してるのはそこなわけで。

だからWeb標準のHTML5を使いましょう、
パテントフリーのビデオとしてVP8、サウンドとしてVorbis、
コンテナとしてWebMを作りました、
他者の追加プラグインなどなしで、Web標準に即したブラウザだけで
全てが完結するようにしましょう。
と、Googleなどが主張してるわけ。

>世の中の全てのブラウザは「Flashに対応していない」てことになるぞ

Flashを「使わないですむ」ようにするのが目的なのに

ひとりひっしなひとがいる

余裕で正論を述べてるだけなのに、それが必死に見えてしまう層がいる

どれだけ能力が低いんだろうか

どっちもどっちなんだろう

正論だろうとそうでなかろうと、「だから結論はこうだ」「だからこうすべき」の部分が抜けているのだから、ただのアンチに見られても文句は言えない
議論のレベルがゲハとどっこいどっこい

金もない、権力もない、W3Cに対しての発言権もないんだから、
２chで議論しても始まらん罠

議論するだけ時間の無駄。帯に短し襷に長し。

というか話が本筋からどんどん遠ざかっているような…ｗ

ここはDTM板なのだから、いかに美しくエンコードできるかを語り合おうではないか。

webmdshow-0.9.9.0-20100702 released

Here are a few of the changes in this release:

(1) two-pass VP8 encoding is now fully implemented

(2) makewebm now supports reading and writing GraphEdit (*.grf) files

(3) source filter now uses Cues element, for more efficient seeking

(4) webmmux filter now allows you to specify WritingApp element

(5) VP8 encoder filter now allows you to force a keyframe to be
created immediately

https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/faeb4377f7856166#

>>450
打ち込みするのか

ffdshowのrev3495でついに対応。
http://sourceforge.jp/projects/ffdshow-tryout/releases/?file_id=2632277
デフォルトで無効になってる。
自分の環境では公式directshow入れてないとＷＭＰで再生できなかった。
公式directshowに入ってるスプリッターが要るのだと思う。

>>453
haaliのスプリッタでいけないかい？

以前公式のソースフィルタやスプリッタを外して試したときはMPC-HCならHaali使ってくれたけど
WMP11はHaaliを使ってくれなかったなあ。理由はよくわかってないけども。最近は試してない。


別件だけど、Xiph.orgのDirectShowフィルタのほうもVersion 0.84.17315でWebM対応されたみたい。
これまでOggだけだったけど、これからはwebmのVorbis音声の再生にも使えるということかな。
ただ、うちの環境だとインストーラー落とそうとするとNorton先生が攻撃と判断して通信遮断する・・・。

MPC-HCのスプリッター+ffdshowでは再生できなかった。
MPC-HCがクラッシュする。

やっぱスプリッターが別に必要みたいね。今の段階では。

>>456
MPC-HC(1.3.2100.0)の内蔵フィルター（matroskaスプリッター+VP8デコーダー+vorbisデコーダー）で再生できてるし
デコーダーをffdshow(ｒ3493)に切り替えても問題は出ていない
サンプルあるなら上げてくれ
確認取れたらMPC-HCの開発チームに提出するから

VP8のハードウェア支援使えるの？

Firefox 次期バージョンのテスター向けベータ版第 1 弾、Firefox 4 Beta 1 を公開しました
http://mozilla.jp/blog/entry/5648/

・HD 動画: ハードウェアアクセラレーションが有効になった、非常にスムーズな HD 品質の
HTML5 動画を YouTube で楽しめるようになりました。
これは、先日発表された 新しい WebM 形式 によるものです。

ためしてみたけど、YoutubeをHTML5モードにして720PのWebM動画
を適当に再生してみたら、普通にCPUバリバリつかって高負荷再生でした

ハードウェアアクセラレート効いてないんじゃｗ

タスクマネージャ見ると、Firefoxともう一つの別プロセスにもCPU負荷
がかかってる。
内部で分散処理してるのかな

Mozilla、UIを刷新した「Firefox」の次期バージョンv4.0のベータ版を公開
ttp://www.forest.impress.co.jp/docs/news/20100707_379045.html
機能面ではHTML5のビデオ機能への対応を強化し、今後Webでの標準的な動画フォーマットになることが期待されている“WebM”形式の動画再生に対応。
GPUのハードウェアアクセラレーションを活用した再生が可能で、HD品質の動画もスムーズに再生される。
対応してるんだろうね。βだから正式版はかなり先の話だけどFlashは対応したのつい最近の話だしx64対応してないのを考えると早いね。

GPUによるハードウェアアクセラレートと言っても色々有るから
この話はデコードの事じゃなくてそれ以降の表示に関わる処理（スケーラ等）の話だと思われ

VP8のハードデコーダはそもそもまだ存在してないし、
OS側の仕組み（ドライバの対応とWinならDxVAでのWebM対応等）も整ってないから
今の段階ではブラウザ側だけでは対応のさせようが無い
実現はまだ先の話

×DxVAでのWebM対応
○DxVAでのVP8対応

そういえば、winampでWebMが再生できる様になったらしいが誰も興味ないのなｗ

もはやWinAmpなんて使ってる人いないのでは。
しかも動画再生になんてｗ

小さな一歩ずつだけど、着実に前進してるね
エンコーダが充実したらかなり実用的になりそう

何を夢見てるんだかか
画質悪いのに流行る訳ないじゃん
DTV板的には不要なcodecだろう

vp8はh264より画質が良くてエンコードも早いって触れ込みだったから
すごい期待してたのに外人はやっぱ口だけだな。

外人つーよりon2だろ
VP6のころから「H.264より高画質」とか吹きまくってたじゃん
もはや「だまされるやつのほうが悪い」レベル

Google「・・・・・」

Flashのせいでブラウザがx64に移行できないでいるからもっと進めて欲しいんだけどね。

H.264では不十分だからこそ登場したのに
ケチつける奴はピントがずれた批判ばかりだなｗ
こういう何もわかってない頭の悪い連中が足を引っ張るわけだ

MP3よりも優れた規格もあったがどれも普及しなかったように
技術上の優劣を語ったところで実際はさして意味はない

H.264はもちろん優れたフォーマットであるのは言うまでもないが
一方でWebのオープンな文化に馴染みにくく時には不都合も生じる
VP8(WebM)はその補完であって根本的に取って代わるものではない

その辺をきちんと理解せずに揚げ足を取るような批判は目につく
もし望まれない存在であるならOperaにしてもFirefoxにしても
これほど早期にサポートはしなかっただろう

Webのオープンな文化になじまないなんていってるのはMozzila儲とOpera儲だけだろ

「H.264こそが今までもこれからも史上最高の動画フォーマット」でないと困る層が抵抗してるんだよ

HTML5はH.264標準で再生出来るじゃん
ただこれはブラウザ作ってる側がライセンス料払わないといけないから
貧乏なFirefoxとかが困ってたところにWebMが出て乗っかっただけ
VP8なんて画質でもデコード負荷でもH.264に及ばないんだから個人が使う意味ないだろ
x264でフリーでH.264動画作れるんだから

H.264より優れてるならいいんだけど、すべての面で劣ってるもの。

H.264がWebのオープンな文化に馴染みにくい？H.264に対応できないFirefoxが涙目なだけだろ(笑)

>>475-476
2015年にはVP8が滅亡して、H.264様のお布施要求を邪魔をするものがいなくなるといいですね

>>477
そんな無駄なことよりH.264より良い動画形式ができることを祈るわ

俺はH.264より良いものを望んでいるだけ。

WebMは「H.264より良いもの」という条件にあらゆる面で当てはまらないだけで、
H.264自体に固執しているわけではないんだがね。

ID:DKoo/VGZの馬鹿はそこのところを理解出来ていない。

割れ厨にとってライセンスや特許なんて関係ないからな

H264より画質がいいかどうかなんてどうでもいいんだよ

・各社がフリーで使える
・追加アドイン無しでブラウザのHTML5で再生できる

この2個が最も重要。
H.264は素晴らしいがパテントフリーじゃない。

あと画質さえ良ければ文句なしなんだが…

出来悪過ぎだわな。WMV / VC-1同様不要な存在。

WebM嫌ってるApple信者が沸いてきたな

AppleはiPhoneやiPodにH.264のHWデコーダ搭載してるし、
AppleStoreも全部H.264だし、今更WebMなんて普及されても困るからな

出来が悪っていってるだけなのに信者脳って怖いね

なんか荒れてるな。

>>485
マカ死ね！

>>487
マカみたいな基地外と一緒にすんな！

>>478
2012年の7月頃までにH.265が標準化されるらしいね。
H.264の2〜10倍の計算コストが掛かるけど、H.264と同画質でさらに半分まで
圧縮できるらしい。本当かどうか分からんけど。

>>472
音声圧縮は、128kbpsあれば非圧縮と区別できない領域に達してしまって
それよりビットレートを上げても劇的に音質は改善しない。
それから、現在のインターネット回線速度とデータストレージサイズ
からすると、音声ファイルというのは十分小さいサイズになっている。
だから、MP3より圧縮率が向上しても普及しなかったと思う。

一方映像圧縮は、音声と違ってデータサイズが巨大でデータストレージ
の問題や回線速度の問題は完全には解決出来ていない。しかも画素数を
増やせば増やしただけ高画質になるため、それ以上ビットレートを上げても
画質が向上しないというサチュレートラインが存在しない。
だから、今後も映像の圧縮率というのは、普及の上で最も重要な要素に
なると思う。

H.265が本当に2倍の圧縮率を達成できるなら、Youtubeなどのデータ保存
サーバーや回線帯域のコストを半分にできることになる。もしかしたら
そのコスト低下分がH.265のライセンス料より安くなるかもしれない。

個人的にはVP8にBフレとかAQとかを導入してH.264と同等画質、出来れば
より高画質になってほしいと思ってる。少なくともそうすればH.264と
すべての面で同等以上になると思う。H.264に負けているのは圧縮率だけ
だから。

ちょっと古いけど、たぶん未出だよね？

VP8, x264 and XviD comparison
http://www.compression.ru/video/codec_comparison/h264_2010/appendixes.html#Appendix_8

ID:F/z3Xtac = ID:PcpzF6h+ = ID:CJcG0uGt か?レスからも恥垢臭がしているぐらいに
臭いぞ。その狂った頭はもう治らないけど、せめて包茎ぐらいは治せよ。

>>491
そりゃおまえ自身のことだろ

Apple製品をひとつでも買えば…

WebMを叩く奴はH.264の欠点にはまず言及しない
H.264とは完全に用途・目的は別物にも関わらず
そこを理解できてないバカが暴れるから困ったもんだ

H.264では不十分だからこそWebMが存在している
互いに棲み分けする（できる）フォーマットなんだと
頭が足りなくて理解できない人は可哀想ですらある

x264より画質悪いから使わない
ただそれだけの話です

なら当然音質の悪いMP3なんて使いませんよね？

>>495
規格と実装の区別すらつかないバカが煽っているのか…

>>496
使わないよ。

MP3なんてもう意味ないだろｗ
2Mbpsもあれば、無劣化のWavで保存できるんだから

そのうちmpeg系コーデック（フレーム間圧縮）も意味がなくなるよ
200-300Mbpsもあれば、フレーム内圧縮のみ（動き補償による劣化なし）でフルHDの高画質記録ができるから

APE、FLAC、TAKだろ

>>499
じゃ、お前は20年後にまたきてくれ。
今現在ではお前はゴミだ。

mp3はsn比的に他のcodecに十分肩を並べれると思うけどなー
主観的にも十分聞けるし

h.264のhtml上での使い方ってほとんど、baselineじゃなかったっけ？？
あれって計算量の割にそんなに画質よくないから、vp8で置き換えれるなら期待できると思うんだが。。。

>>111
この条文でどこも訴えられなくなったな

>>499
サーバ側の帯域の問題を知らない人乙。

サーバ側の問題だと、帯域以外でもMPEG2のパッケージソフト向け
ライセンスみたいに1つの動画あたりいくらなんていう体系になったら
動画投稿サイトとかだと死ねる。H.264は今はサイト単位で非常に安価に
ライセンスされているけど、H.264で独占されるようだと将来的に不安
というのはこのスレでもさんざガイシュツ。

なので、Googleが高い金払ってOn2を買収してでもそこそこ高性能な
コーデックをフリーで公開して広める意味がある。

>>502
SDならそうだけど、HDもあるからなぁ。

>>503
その条項が変わったことがこのスレにも書いてあるというのに、
いまさらなにいってんだこいつ。

>>472
＞MP3よりも優れた規格もあったがどれも普及しなかった

AACが普及してるじゃん、嘘つき

>>496
今時非可逆はAAC一択だろjk

AAC信者が沸いてるな。

基地外オタ論じゃなくて一般論なら汎用性まだMP3のほうが全然上だろ

あと非可逆圧縮コーデックのどれがいいかなんて主観が大きいだろ。
低ビットレートの話なら変わるが。

MP3信者が沸いてるな。

AACの再生できないオンボロ環境なんだろうか

なんだ、たけのこ軍vsきのこ軍みたいなもんか

VP8は性能悪いから広まってほしくないが、Vorbisとmkvはもっと広まってもいいと思う

>>505
AACが普及したのは音質がいいからではなく、
mp3のライセンスを払いたくないAppleがipodでの音楽配信用に
AACを採用し、ipodが音楽配信で天下とったからに過ぎない。

実際、AACの音質はmp3に劣り、
「音質よりも扱いやすさ」で天下を取ったのがApple。

>>510
ttp://www.hydrogenaudio.org/forums/index.php?showtopic=66949
NeroとQT AACの比較@90-95kbps

QT AACが非常に優秀。平均的にLAMEの-V5(150kbps)より良い(!)

>>510
これからトリップつけて書き込んでね

MP3 vs AACはよそでやれよ。

http://doom10.org/compare/vp8.png
http://doom10.org/compare/ptalabvorm.png
http://doom10.org/compare/dirac.png

H.264には負けるにしても、無料で使える他の規格(Theora, Dirac)よりはVP8の方が優れているのだから、
それで良しとしておかないと。

H.264といってもプロファイルがBaseline,Main,Highとあって
VP8はBaseline以上Main以下だから
VP8も改良して上位のプロファイルを作れば一緒かもしれない

ogg厨が参戦！

>>514
ウェブ動画にどこまでの画質を求めるか、だね。
まぁ、画質面ではこれから改善されていくとは思うけど。

>>515
Bフレームが無いのが辛い…。

>>510
＞「音質よりも扱いやすさ」
mp3cutに相当するAACのツールもないのにｗ

ipodアホンきたー

圧縮したままのくせに扱いやすさも糞もねえよ

なんで無価値な議論続けようとするの？ヒマなの？バカなの？

>>510
すべて間違ってるよw

>>459
それ動画の方が対応してない
別のプロセス使うのはFlashの動画だから
Youtubeの動画の8割ぐらいがまずHTML5に対応してないし、
WebMに対応してるのはその半分ぐらいだと思う
モードオンにするだけでなく、WebMの動画探してこないとダメ
検索のオプションで選べられるよ
間にストリーミングをスキャンするセキュリティソフトをかませたりしなければ
C2Dの下位で720pの動画再生して、だいたい20%から30%代だよ

ttp://japan.cnet.com/news/commentary/story/0,3800104752,20416591-4,00.htm

>Adobeの最高技術責任者（CTO）Kevin Lynch氏は、FlashはGoogleの「VP8」ビデオ圧縮テクノロジを
>サポートすると約束し、そのバージョンは、VP8がリリースされた5月から 1年以内に登場すると約束した。

私的には脱FlashのためのWebMだと思ったんだけど、なんか滑稽だわ
ブラウザがWebM対応がんばれよー

脱Appleだな

・SafariはWebMをサポートしない
・IE9はCodecインストールでWebMサポートするか、問題はWindowsXPではIE9は使えないこと
やっぱ利害関係や利権がからんでくると、足並みそろわないよなぁ……
主要ブラウザがHTML5 + WebMで統一できるように今後に期待しとくわ

XP使いは7にアップグレードするか他のブラウザに乗り換えろってことだろ

乗り換えなくてもFlash-playerでFLV見れるだろ
IE使うような人種はそれで満足するんじゃないか？

>>525
こういう話があるよね。
http://jp.techcrunch.com/archives/20100629youtube-weighs-in-on-flash-vs-html5-video/

今更ですがノートン先生の誤警告も消えたので、Xiph.orgのDirectShowフィルタを試してみました。
6月末のVersion 0.84.17315でWebMに対応したということで、名前もoggcodecsからopencodecsに変わったんですね。
インストール時にwebaやwebmへの関連付けも選べるようになっています。
インストールしてみると、webmdshowのDirecShowフィルタが一緒にインストールされました。
ただしソースフィルタ（webmsource）は入っていないようです。
また、webmsplitは、Xiph.Org Vorbis Decoderフィルタと接続できるよう、独自に手が加わっているようです。
公式にある最新のwebmdshow 0.9.9.0のwebmsplitだと、Xiph.Org Vorbis Decoderとは接続できないようです。

残念ながらうちでは、以前Oggスレの
　ttp://pc12.2ch.net/test/read.cgi/software/1246816098/463
に書いたのと同様に、何故かOggやWebMで落ちるようになってしまったので、使うのは断念しましたが・・・。
何故うちの環境は最近のXiph.Orgと相性が悪いのだろう・・・。
OSはXP Home SP3なんですが、他の方は普通に動いてるようなんですよね。orz
まあ公式webmdshowと,ffdshowのVorbisとで再生できるから問題は無いのですけれども。
ffdshowのVP8デコーダーも試しましたが、webmdshowでの再生と比べると重いようですね。

ソースはガイシュツながら、どう見てもゴミです。

>VP8ムービ処理: x264と比較して5倍から25倍遅く、平均で20%から30%ほど品質が悪い。
http://journal.mycom.co.jp/articles/2010/07/13/vp8-vs-x264/index.html

現時点の性能がゴミなのは誰もが承知してると思うけど。

「今後の速度向上」「今後の品質向上」「本当にパテントフリーでいけるのか」
このあたりでバランスがとれていくならある程度メジャーになる可能性も高いが、
もしどこかでつまずくようなら結局はマイナーなまま消えていく可能性もある。
成功したとしても、「ネットの動画はVP8で統一」などという世界はこない。
「動画の品質」は、今後ますます重要になっていくだろうから、
正直なところH.264を置き換えるような形で成長していくことはないだろう。
特許問題に不安が残る技術を使うよりは、有料でも安定した鉄板技術である
H.264を使ったほうがいいんじゃないかという判断もあるだろう。
HTML5もまだ弱点が色々あるらしいし、今後どうなるのかもよくわからない。（知らないだけだけど）
「FlashPlayerがそれなりに進化すれば、結局はFlashでええやん」という意見も根強い。
１社の製品に依存しすぎるのは確かに危険だが、ユーザに大した負担をかけず
安定して広く提供できるのであれば、現実問題としては十分だからだ。
AppleのようにFlashを締め出そうとしているところもあるが、戦略だかなんだか知らんが
今の段階から選択肢せばめてユーザに不便さをおしつけてんじゃねえよって思う。

まあそんなこんなで課題は多いけど、「パテントフリーでかなり高画質」なコーデックは
少なくともそれなりの需要が見込めるわけだからそのへんの夢を追っていこうぜみたいな。
過度な期待はしないけど過小評価もしないってスタンスでいいんじゃないだろか。

それにしてもきもちわるいひとがずっといるな

Dark ShikariによるVP8評　第2弾
http://x264dev.multimedia.cx/?p=486

>>532
画質はTheora超えてればいいし、エンコ速度は今後のアップ期待で終わる話。

そもそも、最高画質のH264が問題になってる事実からめを逸らすなよｗ

少なくとも今の10倍にスピード上げなきゃ始まりもしない

ソースがmpeg系じゃなきゃもっといけるよとかいわれても
HDカムもTVもmpeg系だな

マジレスすると金が絡む規格じゃないと普及しない。MP3しかりH.264しかり

あとMPEG2とAACか

WMAとWMVか

wav

au

>>539
静止画圧縮のPNGは? ZIP・7Zなどのファイル圧縮は? 音声圧縮だと
OggVorbisはそれなりに普及しているぞ?

VP8も画質についてネチネチ言われ続けていると、
そのうちBフレームやインタレース対応のProfile作るかもしれんよな

VP8.1はまだか

Directshow Filters for Ogg Vorbis, Speex, Theora, FLAC, and WebM
ttp://xiph.org/dshow/
Version 0.84.17338 - 20.07.2010

* Updated webmdshow to 0.9.9.0
* Fixed installer script regarding URL registration
(fixes "Open URL..." in Windows Media Player)
* Fixed Vorbis URL playback which was broken in previous version
* Installer uses localised "Open" and "Play" shell commands

Inside WebM Technology: VP8 Intra and Inter Prediction
ttp://webmproject.blogspot.com/2010/07/inside-webm-technology-vp8-intra-and.html

http://git.ffmpeg.org/?p=ffmpeg;a=shortlog;pg=0
ここ二日ほどのDark Shikariの活躍がすごい
もはやWebM本家のデコーダーの存在価値は...

>>549
http://forum.doom9.org/showpost.php?p=1414330&postcount=320

libvpxよりも性能の良いFFmpegのデコーダを広める事で、
GoogleがVP8の仕様を勝手に変えたりしない様にやっていると、彼は言っているね。

FFmpegがVP8のネイティブデコードに対応
ttp://slashdot.jp/it/article.pl?sid=10/06/24/0452249
libvpxよりも高速らしく、イントラのみの動画において最大10%、一般的な動画においては40〜50%も早いという。
一月前でこれらしいからさらに早くなってると・・・
大分軽くなってるのかな。

>>550
何だかさあれほど否定的な立場だったDark Shikariががんばっているのを見ると
x264(h.264)擁護のためにこれ以上のVP8の画質アップを阻もうとしていると穿った見方してしまうわ

>>552
DSは、libvpxにまだまだ画質を改良できる余地が残っていると言っているし、そこまで言うのはどうかと。
彼は他人に厳しいことを言うけれど、フェアな人物だと思う。

大体今夏はgoogleに頼まれてバイトするんだしなｗ

今年のバイト先はgaikaiだと言ってたぞ

Dark Shikariたん愛してる

勝利宣言？
http://x264dev.multimedia.cx/?p=499

>>557
最適化されたデコーダ + Core i7 620QMでも、ParkJoyをリアルタイムで再生できないとは、
やはりVP8はデコードが遅い規格なのだろうか。

FFmpegがwin64に対応すれば、多少ましになるのかもしれないが。

>>558
1080pだし、ハードウェアアクセラレータ をOFFしたらH.264でもきついと思うぞ。
ATI/nVidia/Freescale/Qualcom/TI 他がハードウエアで一応対応しようとしてる。
USB3みたいにRenesas Ele(旧NEC Ele)による半年でパッケージ化はさすがに無いだろうが
ソフトウエアと言い、あと1年〜2年くらいしたらこなれてくるんじゃないかな？

今はじわじわソフトウエアが良くなっていくのをワクテカしてようぜっ！

1.6GじゃH264ですら無理じゃない？
この成果がYoutubeとかに使われるんなら安心してH264も使い続けれるだろうし
ユーザーとしてはいいことだと思うよ

同じビットレートで比べた場合、VP8ほどには重くはないが、[email protected]になるのでDXVA非対応だったり、
再生できない環境が多数存在するのも分かる。

http://www.mediafire.com/file/rnqvtr85hy42amk/ParkJoy_50fps_x264.mkv

DXVAで余裕だな

WebMの画質は思いのほか良いということがわかったのが収穫

ハードウェア支援の有無に関わらず現状H.264より重い
これからどうなるかだな

>>562
いつの間にDXVAで4.2再生できるようになったのねね
昔は4.1までで4.2はコマ落ちした気がするんだけど
>561の動画、Celeron1.2GHz＋GS45のCULVノートでも滑らかに再生できた

再生支援切ってFFmpegデコードにしたら超スローになって吹いたがｗ
さすがに1.2GHzでCPUデコードで[email protected]は無理かｗ

># Anonymous Says:
>July 25th, 2010 at 4:46 am

>Dark Shikari is tsundere for VP8.

># Dark Shikari Says:
>July 25th, 2010 at 5:50 am

>@Anonymous{65}

>I di–didn’t mean to do this for you. I just h-had an extra bit of asm lying around, th-that’s all.


微笑ましいな。

なんでh-hadとth-thatは子音のみでつっかえてるのにdidn'tはd-didn'tじゃないの

非常に分かりやすい。

【レポート】VP8技術インサイド、VP8を特徴づける2つの圧縮技術を知る
http://journal.mycom.co.jp/articles/2010/07/27/wemb-vp8-codec-techs/index.html

上で記事になってる、改善されたffmpegのVP8デコーダーを
試してみたいんだが、ffmpeg.exeのバイナリがみつからん。
というか、どこもかなり長い間バイナリだしてないね。

VLCはffmpegのデコーダーを使っているからいずれ改善された
VP8デコーダーを搭載したビルドのffmpegが使われるだろうと
と書かれているけど、最新のナイトリービルドでもそのffmpeg
が使われてるかどうかわからん・・・

http://x264.nl/developers/Dark_Shikari/parkjoy.png
http://x264.nl/developers/Dark_Shikari/sintel.png

Google純正のlibvpxに比べてffmpegのffvp8が
これだけ早いのなら、Chromeにも使えばいいのにね

しかもDark Shikariのコメントだともっと速くなるのか
この人はあれだけケチつけてたのにすごい気合入れてるねｗ

さすがツンデレだ。h264が今のまま使えるようにするためにがんばってるのかな。
VP8が遅すぎると対抗馬にもなれないし。

規格としてやっていくには、複数の実装が出ることは重要だしねい

>>569
さっきビルドしたやつ(GCC4.4.4)
32bitね
configureオプションとかは自分でチェックしてちょ
http://www.mediafire.com/?wxfx9xyi3bhom5l

>>569
バイナリ出す人がいなくなったのは
Ramiroさん（ffmpegのメンテナーの一人）がAutomated buildを始めたから
http://ffmpeg.arrozcru.org/autobuilds/

>>574
>>575
ありがとう〜

>>552
以前MozillaやOperaが協力しないh.264じゃvideoタグの標準は無理って書いてたから、
純粋にVP8に力貸したいだけだと思うよ

>>552
彼は厳しい事言ってるけど、単に「その時点での事実」を述べてるだけかと。
アンチが都合よく切り張りした最初の発言↓を鵜呑みにしてる人が多いだけでしょ。
http://x264dev.multimedia.cx/?p=377

>>535で張られてる↓見てもメリットもデメリットもあるってこと言ってるし。
http://x264dev.multimedia.cx/?p=486
インターレースをサポートしない事を大歓迎してるしね。

エンコーダ？

世界最速というVP8エンコーダ「ffvp8」登場 (スラッシュドット・ジャパン)
http://news.livedoor.com/article/detail/4912278/

>>578
DSのインターレース嫌いのせいでx264のインターレース周りが遅れる遅れる…
パッチなしでまともなインタレースエンコが出来るようになったのは半年前だし、
MBAFFはサポートの予定がないし。

もちろん、YUV420もフレーム間差分を使う圧縮方式もインターレースとの
相性は最悪だし、液晶・プラズマといった表示デバイスがインターレースを
サポートしてない以上、いまやインターレースが無意味なのは確か。とはいえ、
1080iで放送している国は多いからなぁ。

>>580
インターレスなんて適当にフィルタで解除してエンコーダーに食わせればいいだけ
インターレスエンコに拘ってるほうが異常者だわ

>>580
放送に限らず、BDも60は1080iばかりで720pは見ないな

>>581
インタレース解除の品質はTGMC＞ビデオカード＞＞＞適当なフィルタ

>>580
インタレが好きなコーデック開発者なんているのか？
そもそもD_Sどころかpengvado、さらにはffmpeg/mplayer開発者にいたるまで
みんな嫌ってるだろ
libswscaleはインタレ対応まったくしてないし

>>582
TGMCなんて、アニオタがテロップ処理に使うくらいしか用がねえよ

>>580
一部のプラズマはインターレース表示だよ
今はもう作って居る所無いけど

まあ、MSもインターレース嫌いだし、アメリカのHDは720Pが多いって聞くし
インターレースにこだわってるのは日本の放送局(特に某協会)だけだねぇ？

>>581
24fや30fを24p/30pにするのならともかく、60fをインターレース解除して
60pとしてエンコするのはちょっとなぁ。

>>583
実装めんどうだから開発者は当然嫌うだろうねい。

>>584
ABCとFOXが720pだけど、それ以外は1080i
720pはヨーロッパに多いと聞いた。

>>584
アメリカは他国に比べて720pが多いみたいだけど、それでも主流は1080iのようだ

高精細度ビデオ - Wikipedia
ttp://ja.wikipedia.org/wiki/%E9%AB%98%E7%B2%BE%E7%B4%B0%E5%BA%A6%E3%83%93%E3%83%87%E3%82%AA
＞北米では、FOX、ABC、およびESPN（ABCとESPNはディズニー傘下）は720p番組を放送している。
＞PBS、NBC、Universal-HD（以上ゼネラル・エレクトリック傘下）、 CBS、UPN、Showtime、INHD、HDNet、
＞およびタイム・ワーナー傘下のHBO-HD、the WBおよびTNTは1080i番組を放送している。

更に調べたらヨーロッパはほとんどが1080iみたい
ttp://www.digitalbitrate.com/dbr.php?link=0&sat=1&mux=&pid=&live=¬e=0&lang=en
ttp://www.digitalbitrate.com/dbr_hd.php

これってヨーロッパはPALだから、720pだと縦解像度のアップが少ないって事なのかねえ？
1280x1080iなんて解像度まであるし…
アメリカはNTSCだから、720pでも十分アップになると考えたとか？

まあ理由はともあれ、解像度に関しては日本はメジャー側のようだ
考えてみればアメリカはATSCなんてのも作ったし、デジタル放送ではマイナー側なのか？

>>586
あ、ヨーロッパでも1080iなのか。

考えてみると、洋の東西を問わず、フルHD解像度=1920x1080と
認識されているものなぁ。

インターレスが主流だと力説する馬鹿は、
そのインターレス主流地域の開発者達が一律にインターレスを排除
しようとしている事実から目を背けるなよ

インタレがまだいっぱい使われている証拠かき集めても
なんの反論にもなってないことに気づけ。

インタレは放送初期の帯域不足から生まれた苦肉のデータ削減法に過ぎない

>>588
お前がものすごく頭が悪いのは理解してあげたから、消えること

このスレでもDTV板にありがちなインタレvsプログレ戦争が起きてるのか？
勘弁してくれ

ウェブ向けのオープン動画規格 WebMファイルの再生に対応！

Google社の提唱するWEB向けのオープンソース動画規格WebMファイルを、
TMPGEnc KARMA.Plusに実装されているペガシス独自のファイルリーダーで読み込むことを
可能としました。これにより、非常に安定した再生、シーク、映像同期をWebMファイルでも変わらず
楽しむことができます。また、Vorbis音声の再生においてもGoogle社から公開されてい
るデコーダを使用せず、自前のデコーダーを使用することで、最適な再生と音質を実現
いたします。

つまりmatroskaスプリッターとVP8デコーダーとVorbisデコーダーを
全部自前で書いたってこと？

自前なのはVorbisデコーダだけじゃない？
Matroska SplitterとVP8 DecoderはGoogleのSDKをDirectShowフィルタのGUID変えて実装、みたいな感じだと思うわ

Free WebM Encorderがいつのまにかバージョナップして1.0→1.2になってた

何が変わったのかはどこにも書いてないから不明。
ffmpeg.exeが新しくなっただけかな？

なんであれ使えるツールじゃないよな・・・

ffmpegのめんどくさいオプションとか無しに使えるから楽でいいよ

Miro Video Converterとかもね

hosyu

webmをGPUエンコードできたら面白そうだけど難しいかな

http://github.com/rbultje/x264/commits/xvp8

Dark Shikariが今度はxvp8を始めたようです

>>599
なんだか凄そうだがこれはなんなの

>--vp8 Encode as VP8 instead of H.264

x264を使って、H.264の代わりにVP8を出力できる様になるんじゃないの。

手広いな

デコーダの次はエンコーダか

FFdshowはいつになったらVP8デコーダとしてffmpegを使うんだろうか。
今は重すぎだわ

え？　もともとlibavcodecしか選択は出来ないような
libvpxに変わったの？

>>599
うおおおなんだこりゃあああ！！！
このままx264にVP8も仕込むつもりか
DarkShikari はあれだけ辛口だったのに
この力の入れようは一体何なんだよｗ

>>605
まだじゃなかったっけ？

>>601
これが可能ならマジ神だな

8/13の#x264devのログより
(Alex_W) also i take it from the discussion here yesterday that support for encoding to vp8 will be coming to x264 soon right?
(Dark_Shikari) hopefully
(Dark_Shikari) it will be a tack-on, that is, it'll be a hack to output vp8 from x264, not modify x264 to be more like vp8
(Dark_Shikari) so it'll continue to use h264 terminology and structure
(Dark_Shikari) vp8 is basically an h264 subset, so it's easy

x264の機能を制限して少し手を加えれば出来るらしい
実現すればエンコードはlibx264、デコードはffvp8で、XiphはVorbisだけいじってろってことになるか

MV検索やレートコントロール、最外部の入出力モジュールなんかは殆どそのまま使える
これはVP8というよりもピクセルの表現形式(YV12とか)が同じなら殆どの映像コーデックで同じ

そしてVP8がH.264に比べると機能が少ないのが幸いする
Bフレームとweightpを禁止、パーティションタイプを減らし、refを3に制限するとかなり近くなる
中規模の違いとしてはDCTとIntraPredictionだが、これらはH.264や信号処理をやってる人間には簡単
大きなものでは実際にビットストリームを作成する部分（エントロピー符号化含む）と
デブロックフィルタの部分を作りこめば、あとは細かな違いしか無い

アセンブラ部分は良く解らんけどC言語の部分だけなら
大雑把に言ってx264の50%程度はそのまま再利用で済むと思われる
残りもワークフローとしては同じなのだから、設計が流用できるのが大きいし、
基本的にVP8はH.264より簡単なので、流用できない50%の全て作り直す必要はない
結果としてx264の20%程度をつくり直すつもりでいれば、とりあえず動くものは作れるだろう

>>609
まったくわからんが出来そうなんですねｗｋｔｋ

googleとしてはVP8は264とは別ものでロイヤリティフリーと強調してたが
x264でエンコードできちゃうと説得力が無くなるな

ますます普及しないお…

というか、モダンなビデオコーデックは大体同じ仕組みだと思うけど

おいらは逆に広告バナーの類にやたら使われて公害みたいになると予想

てｓｔ

VLC 1.1.3で、今までクラッシュしてた.webm動画も
画像が崩れながらもクラッシュはしなくなったｗ

>>608
デコードもエンコードもx264に占拠されそうだなｗ

>>609
詳しい解説乙、是非また頼むよ！

Media Player Classic Homecinemaの内蔵VP8デコーダーが
先日のビルドから劇的に軽くなった
ffmpegの最新デコーダーが導入されたのかな

WebM終了
http://www.businesswire.com/news/home/20100825006629/en

あー、著作権ヤクザのMPEG LAがこういう形で反撃するとは思わなかったわ……
でもこれで全ブラウザがHTML5 VideoタグのH264サポートをする可能性が出てきたね

はぁ？
エンドユーザーのライセンスが無料になる事が確約されただけじゃん？
ブラウザーにデコーダを組み込むライセンスとは別物だろ〜
# 製品についてのライセンスは有料って書いてあるし

とりあえず手軽で何でも高画質にwebM動画にエンコード出来るソフトを教えてくださいコノヤロー

>>619
WebMは単なるGoogle謹製WMVだわな。

無料でH.264のデコーダを配布できるようになればVP8は不必要になるが、
>>619では十分だと言えない。

というかこれは完全に予測の範囲内だから驚きは無い

・WebMという対抗馬の存在
・他に十分な収入を得る手段が確保されている
ことから考えると当然

>>622
Free WebM Encorder

ffmpeg.exeは最新のを自分で持ってきて差し替えるといい

H.264のライセンス料、無料ネット動画は恒久的に不要に
http://www.itmedia.co.jp/news/articles/1008/27/news021.html

＞有料配信動画などには引き続きライセンス料が課される。

ニコ動は有料に入るんだろか。

VP8のVFWコーデックはでねーのかな

MPEG-LA、AVC特許ポートフォリオライセンスを一部で永久無料化 - CNET Japan
http://japan.cnet.com/news/service/story/0,3800104747,20419036,00.htm

＞Googleは5月、オープンソースでありロイヤリティフリーである競合ビデオフォーマット「WebM」を発表した。
＞当時はWebMのビデオ符号化規格「VP8」が、MPEG-LAの特許プールを侵害するのではないかという
＞憶測が飛び交ったが、そのような正式な申し立てはなかった。


MPEG-LAの告訴やるやる詐欺でしたｗｗｗ

>>627
＞ライセンス料免除の対象は「エンドユーザーが無料で視聴できるインターネットビデオ（インターネット放送AVCビデオ）」。

>>629
＞声明には、インターネット放送AVCビデオ以外の製品およびサービスには、今後もロイヤリティを適用すると記されている。


ネット上の無料ストリーミング「だけ」免除だから何の意味もないわな
今までは期間限定と言ってたのをWebM登場に慌てて恒久化した
FireFoxやOperaがこれに満足して対応するとは思えん

FirefoxとOperaがこれまでH.264非対応の理由に挙げていたのが
まさに今回の部分(2016年以降の配信課金の可能性）なので、
口実の一つが潰れた形になるのは確か

Firefoxはコーデック利用料で年間500万ドル掛かると言ってるが、
Googleからその10倍の資金提供を受けてるんだから口実としては弱い

それにデコーダに関しては
・WinやMacの商用OSならシステム標準のコーデックを
・LinuxやAndroidならffmpeg等のOSS実装を
それぞれ呼び出して使えば良いだけだから
（実際に多くの汎用動画再生アプリはそうしてる）
現実的には対応するのに問題は殆ど残ってないはず

Webの世界はプロプラとOSSの両方が共存してるのだから、
Web動画でもWebMとH.264の両方が共存し競合するのが双方に取って良い事だよ
ライバル不在では進化が鈍化するだけで良い事は無い

ニコ動はアウトだな
ライセンス料を払わなきゃ犯罪者の仲間入りだ

いずれにせよパテントフリーからは程遠いな
特許をプールして対抗するとか結局は脅しだけか

>>632
小用だから当然だろ。
糞でかい癖にここをケチるGoogleがおかしい。

Firefoxは金の問題ではなく、オープンソースじゃないから対応しないんじゃなかったか

>>635
ffmpegもx264もオープンソースだが

ネット参入に“料金所”は要らない、Mozilla
http://www.atmarkit.co.jp/news/201001/25/video.html

無料動画サイトである限りライセンスも無料
何か有料サービスを始めたとたん、ライセンス料の請求が飛んでくるのか

微妙なところだな

Googleは金でH.264の無料ライセンス勝ち取ったんだから満足じゃない？
VP8終了なんて全く気にしてないよ。ライセンスも泥沼だし。

むしろMPEGLAを脅迫するネタとしてVP8を使ってるだけのような

>>636
H.264自体はオープンソースじゃないし、パテントフリーでもない
MPEG-LAに管理され、「無料のWebストリーミング」以外は全て有料

>>638
無料化と言っても範囲は限定的なので大して意味が無い
基本的にクローズドソースでパテント料金がかかることに変わりはない

Googleの「WebM」に特許問題か　MPEG LAが特許料要求の可能性
http://www.itmedia.co.jp/news/articles/1005/24/news047.html

＞MPEG LAのラリー・ホーンCEOは、VP8とWebMで使われている特許技術群について、
＞パテントプールライセンスを作成することを検討していると話す。
＞「VP8などのコーデックの特許権を利用するために、個々の特許保有者と個別に
＞ライセンス交渉せずに済む便利なワンストップライセンスの作成を求められている。
＞われわれはその可能性を検討している」

↓　↓　↓　↓　↓

MPEG-LA、AVC特許ポートフォリオライセンスを一部で永久無料化
http://japan.cnet.com/news/service/story/0,3800104747,20419036,00.htm

＞Googleは5月、オープンソースでありロイヤリティフリーである競合ビデオフォーマット「WebM」を発表した。
＞当時はWebMのビデオ符号化規格「VP8」が、MPEG-LAの特許プールを侵害するのではないかという
＞憶測が飛び交ったが、そのような正式な申し立てはなかった。



どっちがカスなのかは一目瞭然

>>640,641
WebMとH.264、両方併存が望ましいので「どっちがカス」とかに付き合う気はないが
目立つ間違いの指摘はしときたい

Webの動画に求められてたのは課金免除の「ロイヤリティフリー(RF)」であって
「パテントフリー」ではないので誤解しないように

またオープンソースである事も別に必要ではなく、
より大事なのが「正しい手順で標準化されている事」

ttp://blogs.computerworlduk.com/simon-says/2010/05/webm-missing-the-assurances-open-source-needs/index.htm

あと>>641の前後の話は基本的に全く別
本来は特許権侵害の有無そのものが争点なのだから
その前にパテントプールがどうこうってのは
そもそも話の順序としておかしいってのは有るんだが
取り敢えずそこは置いとくとして

後者に関しては「現時点ではまだ」ってだけでしかない
訴訟を諦めたのかどうか正式なコメントは無いし
仮に訴訟を起こす場合でも準備期間は相当掛かる筈だから
現時点ではまだ不明確

＃私見では訴訟は行わないと思うけどね。利益と不利益の両方発生するから。

また出てきたよ

心の病気を治そうね

結局金払ってるGoogleもオープンソースなChromiumにはH.264のデコード機能を組み込まなかったように、
Firefoxも無理なんじゃないの
Operaは喜んでるかもしれないけど

とりあえずシステム標準でH.264のデコーダを備えてるWin7とOSXなら
即座に対応出来る訳なんだけど

あとはポリシーの問題でしかないよ

>>646
対応できるわけないだろｗ

ライブラリを呼び出してデコードしても、H.264を使っているのはあくまでもアプリケーションなんだから
当然、アプリごとに使用料を払わないといけない

OSのライブラリは「使用者にライセンスを与える」ものではないのだから
GIF問題でもそうだっただろ？

その論法だと、例えば既にH.264に対応していて実際に動画サイトでも
広く使われているFlash Pluginを読み込んで利用しているブラウザ側にも
支払義務が発生するってことにならないか？

それならFirefoxやOperaももう既にMPEG LAに支払い義務を負ってることになるが
そうではなく実際はAdobeが一括して支払ってる訳でしょ？

アプリを構成している各要素群のうちのどこかが支払っていれば良い、
という考え方だと思うけどな

>>648
GIF特許の際はOSのライブラリ利用しても>>647のようにUNISYSは
徴収しようとしていたけど、一般的な意見では>>648のように
二重取りになるという見解だった。ただ、この件で訴訟になって
判例がでたわけじゃないので、実際にどうなるのかは不明。

それにしてもネガキャンに必死な人だ

ライブラリとプラグインを混同するなよ

Theoraの今後について

>>649
解説サンキュ

Win7でサードパーティアプリからシステム標準のH.264コーデックを呼ぶ場合の
対応を調べて見たが、やはり大丈夫だった

"Third-party applications that simply make calls to the H.264 code in Windows (and which
do not incorporate any H.264 code directly) are covered by Microsoft’s license of H.264. "

ttp://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx

OSXでもQuickTimeフレームワーク経由でアプリから利用する場合は同様の筈

>>626
遅くなったがありがとう

t

libvpx 0.9.2 released
http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/affaf0069c199ca4#

WebM QuickTime Components initial alpha release

ttps://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/2d363cfefa447298?fwc=2

WebM Decoding Improvements in Google Chrome 6
ttp://blog.webmproject.org/2010/09/webm-decoding-improvements-in-google.html

Chrome6で速くなったって言ってるけど、正直ぜんぜんまだまだだと思う

ffmpegからライブラリ借用すりゃいいのに・・・

Chromeもffmpegを使ってるよ

でも例えばVLCとChrome6とで
ローカル保存した.webmファイルを開いた時の再生負荷を比較すると
Chromeのほうがかなり重い

ffvpxはまだ使ってないっぽい

webmに関してはFirefoxもChromeも変わらないんだな

>>661
そりゃ、ffmpeg任せだもの

最近目立った動きが無いな…

画質を酷評されたので根本的に作り直してます。

ニコニコ動画がHTML5に対応、iPadでの動画再生が可能に
ttp://internet.watch.impress.co.jp/docs/news/20100929_396805.html

ニコニコ動画がHTML5サポート、iPadでも視聴・コメント入力が可能に
ttp://journal.mycom.co.jp/news/2010/09/29/059/index.html

JPEGより約40％コンパクト：Google、Web高速化を目指し新画像フォーマット「WebP」を発表
http://www.itmedia.co.jp/news/articles/1010/01/news027.html

＞GoogleがJPEGに代わる画像フォーマットとしてVP8技術を応用した「WebP」を発表。

JPEG2000…

WebPはVP8のキーフレームを圧縮に使ってるとか？

ウェピー？

WebMとかWebPとかネーミングセンスはいまいちだな。
てかWebPの方はプロジェクト専用のサイトは立ち上げてないんだな。

＞WebPはアルファチャンネルがない、4:2:0のみ、ロスレスが無い、最大が16383x16383

登場前から終わってたｗ

WebPはweb上で使われるjpegの代替が目的であって、pngの代替にするなんて誰も言ってないだろ
それともお前はjpegにアルファやロスレスを求めてるのか？

>>670
動画ならともかく、静止画で420のみって痛すぎる
JPEGは420、411、422、444使えるのに
特にアニメ絵や2DCGが多い日本じゃ劣化が目立って見向きされなさそうｗ

>>671
アルファやロスレスはJPEGの代替には要らんと思うが、420のみは痛いな
WebMベースだから420しか使えないのか？
H.264なら422も444も使えるのに

うーむ、別にweb上の一般的なjpegの代替なら別に420だけでもいいんじゃないかと思ってたんだが…
そもそも性能自体があれらしい

毎度おなじみD_Sの評論
http://x264dev.multimedia.cx/?p=541
翻訳
http://cpplover.blogspot.com/2010/10/darkshikariwebp.html

>>667
そのようだね。

Diary Of An x264 Developer ≫ H.264 and VP8 for still image coding: WebP?
ttp://x264dev.multimedia.cx/?p=541

静止画比較のPSNR最適化の所はx264の説明にも使えそう。

>>670-673
Webで使われてるサイズの静止画は動画よりも空間周波数が高いというか、
縮小されててクッキリしてるから色情報の劣化が目立ちやすいからなあ。
JPEGも使われてるのは4:2:2が一番多い感じ（デジカメも大抵そう、RAW現像だと4:4:4だけど）。

まぁ普及しないだろうね。アドバンテージがファイルサイズくらいで、
JPEGがそのファイルサイズで重荷になるケースが稀だし。

>>674
あー、確かにWebPギャラリーにあるような実写画像なら420で問題ないと思う

しかし微妙な性能だな…

画質を犠牲にすることなくファイルサイズを圧縮！「Caesium」。
ttp://www.gigafree.net/tool/graphiccomp/caesium.html
日本語サイト
ttp://tiltstr.seesaa.net/
圧縮率見るとこれと変わらない気がする
WebPは微妙っぽいね

JPEGとかPNGの圧縮率の最適化を広めた方が良さそうだな
JPEGの圧縮って結構いい加減な処理が多いから、
心理的な最適化を行えばまだまだ圧縮理を向上できるだろうし
あとはポストプロセッシング（デブロック、デリンギング）を付けるとか

つかJPEG2000でいいやん。

>>680
買収した手前、ソースから何らかの派生技術を作っておかないと株主に叩かれるからでしょ。

ホント文句しか言わねー奴らだな

>>678
http://slashdot.jp/~bero/journal/516425

>>682
とりあえず否定しとけば、「俺は分かってる」感が出るだろ。

今までのlibvpxの開発は、PSNRを重視した結果、人間の視覚にとっては、ぼけすぎとなってしまっている。
これをx264の様に、SSIM重視にでも変更してくれたら、少なくともIフレームの品質が、
JPEGに負けてしまうと言うことはなくなるだろう。

DWTのJPEG 2000もPSNRは良いが、DCTと比較すれば実際の画質はあまり良くない。

正直この程度の小幅なメリットなら、種類が増える事のデメリットの方が上回ると思う

まあ静止画じゃいくらイントラ予測やっても出来る事は限られてるしな

っ JPEG XR

てかVP8のデコードってJPEGと比較して
回路規模やメモリ使用量は何倍になっているんだろう？

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

>>688
JPEG2000ってそんなに重いのか
通りでデジカメで見向きもされなかったわけだ
1000万画素を1-2秒で圧縮しなきゃならんしねえ

Motion WebPなんてのを妄想してみたがそれWebMじゃないかと脳内で突っ込まれた

>>671
ゴミはゴミ箱へ

>>691
え？

最新情報
http://x264dev.multimedia.cx/archives/541
http://x264.nl/developers/Dark_Shikari/imagecoding/theora.png

WebPはtheoraよりもさらにボケボケでした、とさ

またH264か

>>689
JPEG策定時とJPEG2000の策定時のスペック差は100倍どころじゃないから
正常進化と言ってもいいんだけどデジカメは連射速度をウリにしちゃったからｗ

JPEG2000でも1000万画素を1秒で圧縮するぐらい問題ないが
JPEGなら連射速度が10倍とか言われると画質が悪くても流れていく。

そんな性能を一般人が本当に必要としているかはさておきｗ

>>693
サザエさんですね

>>695
いや、ASICの処理速度的には十分に足りてる。なんせ、いまはH.264 1080/60iの
動画をコンデジで撮れるような時代だもの。あと、JPEG圧縮処理よりも
NRやRAW現像処理のほうが重いし。

単に互換性の低いJPEG2000やJPEG XRを使いたがらないだけ。

特に一眼レフの場合は高画質が欲しければRAW現像すればいいでしょっていう世界だから。

現像すんの面倒だからPNGに対応して欲しいわ

TIFF対応してるのはあるな

TIFFは互換性がややこしいな

せめて32ビットBMP（RGB各10ビット）に対応してくれ

圧縮動画でyuvカラースペースじゃないフォーマットは
あり得んだろ。今時。

Gifは廃れたけどサイズは少なかったなぁ。
WebPも素人目に差がわからない程度なら使うんだけどね。
バイナリってないんだろうか・・・

gifは256色の時点で論外

>>703
PNG 8bitパレットは同じ256色でGIFよりもサイズが小さいよ。
WebPよりもJPEG XRの方が（現時点では）より綺麗で、より小さくなるよ。

てか、ここDTV板でっせ

【Youtube】WebM・WebPを見守るスレ【Chrome】
http://hibari.2ch.net/test/read.cgi/google/1286225648/

VP8 in AVIなファイルは作れますか？

>>707
http://www.mediafire.com/download.php?71jj973zncf85yd

ffmpegで作れるし、そもそもBフレ使わないから別に問題もないかな

あれ？ゴールデンなんちゃらフレームの関係でAVIは厳しいかと思ってたけど、どうなんだろう？

ゴールデンなんちゃらはVP6とかVP7でも使ってなかったか

Skype 5.0でついにH.264積んだな

* Windows Vista認定 システム要件
* WindowsR 2000、XP、Vista、7、32ビットおよび64ビット版オペレーティングシステム。（Windows 2000をお使いの場合は、ビデオ通話でDirectX 9.0が必要となります。）
* インターネット接続 − ブロードバンドを推奨（GPRSでの音声通話はサポートされません）。
* スピーカーおよびマイク（内蔵と外付けのいずれでも可能です）。
* 音声およびビデオ通話には、1GHz以上のプロセッサ、256MB以上のRAM、そしてもちろんWebカメラが付いたコンピュータが必要。
* グループビデオベータ版で最高の通話品質を実現するには、通話参加者を5人以下に制限することをお勧めします。
* グループビデオが機能するには、通話の参加者全員がSkype for Windows 5.0またはSkype for Mac 5.0ベータ版、およびWebカメラを使用している必要があります。
また、高速ブロードバンド接続（持続的な512kbit/s以上の速度を推奨）、および1GHz 以上のプロセッサまたはCore 2 Duo 1.8GHz（推奨）が必要です。

技術仕様
バージョン 5.0.0.152 ファイルサイズ20 MB. 公式リリース。リリース日：October 14, 2010. ファイル名： SkypeSetup.exe

H.264 Codec is Copyright c 2008, SPIRIT

SkypeってVP7使ってたっけ

AMDやる気ないな
HD 6000シリーズでDivXやXvidの再生支援に対応する一方VP8はなしだって

MPEG-4 part 2（旧DivXやXvid）やMPEG-2（IDCTには対応済みだった）は
今更対応するのかよ、ってぐらい一般的な動画フォーマットだからな。

WebM発表までドマイナーだったVP8とはユーザー数も必要性も格が違う。

VP8のビットストリームに、今の物とは互換性のない変更がされるとも言っているし、
まだハードウェアは作りにくいだろう。

http://blog.webmproject.org/2010/06/future-of-vp8-bitstream.html
http://review.webmproject.org/#change,56

>>714
ttp://www.4gamer.net/games/110/G011065/20101022090/SS/025.jpg

スレチだがこのMPEG2がよくわからないんだけど、iDCTじゃないMPEG2なんてあるの？
Entropy Decodeが書いてないからVLDに対応してないのかと思ったけど、
うちにあるHD4でもVLD・IDCT・MC全部対応してるし。

>>713
5月に突然発表されて、10月に間に合うわけねーじゃん
1秒でそのくらい理解しろ

>>717
GPGPU使えば3日で対応できるだろ
1msでそのくらい理解しろ

再生支援がGPGPUで実装できると思っているとは・・・

「GPGPUならなんでも速い！」と思ってるバカが多いからな。
得意なもんとそうじゃねえもんがあるってことくらい理解しろや。

って知り合いが言ってた。

>>718
あのさ、再生支援機能はハードウェアで実装されてんですよ・・・
専用回路積んでるの。

モノによってはGPGPUで実装されていて、再生支援効かせると利用可能な
シェーダーユニットが減るなんていうのもあった気が。

RadeonのUVD（再生支援）は専用回路だが、
ポストプロセッシング（画質調整）にシェーダ利用してるね。

つーか似たような話を見たと思ったら、>>369-で出てるじゃん。

GPGPUで再生支援は可能

可能だがAMDのウリは普通のアプリケーションを動かしながら(x86 CPU)
動画を再生しながら(UVD)、GPGPUで大規模計算（エンコード等）が出来ることだから
再生支援の為にGPGPUを活用する理由がない。


それにミニノートなどでも省電力かつ低温な再生支援が求められているのに
IntelやNVIDIAを含むGPUメーカーが高コストなGPGPUで再生支援を積むわけがない。
効率がいいのは3Dでも再生支援でも 固定回路 ＞ プログラマブルシェーダ なのは変わらない。

7000系が来年4月だかの割と早めに出るらしいけど、
そっちでもまだ無理かね

ISO, ITU-T, SMPTEの様に、GoogleがVP8の規格を凍結してくれないと駄目だと思う。

>>725
ところがAMDは１月のCESで、従来のAvivoの次世代版である
コード名「VPP(Video Power Pack/Video Processing Pack)」を
発表予定。

再生支援にはUVD3を使い、ポストロセスの高画質化には、
OpenCLを介してGPUのシェーダーを使うというもの。

CPU内蔵GPUのパワーを生かしたGPGPU利用例を自らまず出すということだろうな。
ちなみにOntarioでTDP9W、ZacateでTDP18W

VPP: AMD Prepares New Video Processing Engine
http://www.brightsideofnews.com/news/2010/10/20/vpp-amd-prepares-new-video-processing-engine.aspx
CES2011でAMDはBarzosプラットフォームのZacateを発表しそうだ。
しかし、AMDはそれらを更に強化する新ソフトウェアもまた準備している。

コード名「VPP(Video Power Pack/Video Processing Pack)」
主な目的は、ビデオ品質とトランスコードの劇的向上により、
コンシューマ経験を向上させること。

Avivo HDは古く、柔軟性のないソフトウェアであり、Dx11世代のハードを
きちんと利用出来ず、しばしば不可解なエラーが出るのが問題だった。
また古いソフトウェはスケーラビリティにも影響を与えており、
二つの400ドルカードより二つの200ドルカードのほうが上などの状況をがあった。

GPGPUについての認識が数年前で止まってる奴がいるな

>>729
一番いい解説を頼む

>>728
高画質化にGPGPUなんて使わない、なんか誰も言ってないよ
「再生支援には省電力＆低発熱の専用回路（AMDではUVD）が大前提」って言ってるだけ

しかも引用したFusion系はCPUにGPUが統合されたものだから
ノートパソコン用でもCPUクーラーで冷却できるという大前提により
CPU内にAvivoなんて化石載せるよりもGPGPUでのプログラマブル化が有利になっただけ

話がすりかわってるんだよね
再生支援には何が一番有利かという話をしてるのに、
GPGPUの活用法みたいな話を持ち出してる人がいるだけ

>>731
> 高画質化にGPGPUなんて使わない、なんか誰も言ってないよ

>>719-721は言ってるようだが

>>733
おいおい、高画質化（画像処理）と再生支援（デコード）は別物だぞ

>>733
せめて２行目を読めよ…

>>731
既に公開されてる実働デモから、動画再生にUVDを使ってることは明白。
CPU内に「Avivoなんていう化石を載せる」云々という君の論理は完全崩壊

言い訳できなくなったら話題逸らしですか？

vfw
ttp://www.optimasc.com/products/vp8vfw/index.html

Medi Player Classic Homecinemaの内蔵VP8デコーダーがかなり軽い。
ffmpeg使ってるはずなのに、なぜかGPU利用してるようだ。

GPU負荷を表示するウィジェットでGPU負荷を見てるんだが、
WebM動画再生中にGPU負荷が跳ね上がる。
そして、実際に再生も軽いしCPU負荷も前より下がってる。

>>739
勘違いじゃないか？

は？

madVRとかを使っているオチとかじゃないよね。
内蔵デコーダーならコーデック名の後に（DXVA）って書いてあった場合に再生支援有効。

Dark Shikari(ffvp8の作者)が、GPUのコードを書いたりはしないだろう。

http://x264dev.multimedia.cx/archives/499

ffvp8の作者はRonald Bultjeではないか？
Dark Shikariが書いたのはasmだけだろ
xvp8だって基本的にはBultjeのプロジェクトだし

いずれにせよGPUコードは書いてないな

>>742
使ってるのはEVRだよ。
OSはWin7 64bitだけど、使ってるのは32bit版MPC-HC

EVRはDXVA2.0を活用し、DXVA2.0はデコード以外でもGPUを活用する。

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"。
開発テーマはエンコーダの高速化

26番目のリリースで終焉の予定か？

PSNRを指標にしてもダメだとWebPの時に指摘されているのにｗ　＞PSNRが7%以上向上

開発スケジュールが明示されたのは良い事だけど

５月の時点の初期駄目っ子状態から
まだこれっぽちしか改善されていないのかと思うと少し気が遠くなる

この改善率だとffvp8の改善点を取り込んだりとかしてなさそう

四半期ごとにリリースとは開発速いな
とはいえそれこそが強みか

明らかにffmpegのデコーダのほうが速いんじゃね、これ

SDKをアップデートするのはいいけど、
GoogleはYoutubeで最新のを使ってるのかね？

最新のffvp8を使っています

ffvp8はデコーダだからWebブラウザ側だよ

Android 2.3ではWebM対応になるらしいぞー

VP8、普及状況
http://journal.mycom.co.jp/news/2010/11/15/066/index.html

ビデオコーデックVP8がオープンソースソフトウェアとして
公開されてから半年が経過しようとしている。
この半年でVP8は大きく成長した。どういった状況にあるかが
WebM - Open video for the web [PDF]において報告されている。
報告内容からいくつか特徴的な部分をまとめると次のとおり。

・Firefox 4、Opera 10、Chrome 6においてVP8コーデックを使ったVideo機能を実装
・IE9、Safari5でVP8コーデックに対応(システムにWebMコーデックを別途インストールすることで対応)
・Skype 5のグループビデオ機能でVP8を採用
・YouTube HTML5 betaでVP8を採用 (ビデオの80%でVP8が使われている)
・FFmpeg VP8ネイティブデコーダの実装
・そのほか各種ソフトウェアでVP8を採用
・最初のVP8 SDK libvpx 'Aylesbury'を公開
・開発コミュニティの成長
・パートナーの増加

今後の予定として次の取り組みも紹介されている。

・2011年第1四半期にVP8 ASICチップや関連H/W登場予定
・2011年第1四半期にVP8 SDKの2つ目のリリースlibvpx 'Bali'登場予定。エンコーディングの高速化目指す

VP8はブロックベースのコーデックで、比較的古典的でシンプルな設計を採用している。
ASICとしてチップに実装して組み込みデバイスや家電機器などで利用するのもそう難しい取り組みではないようだ。
2011年はソフトウェアのみならず、ハードウェアでの採用普及も進むことになるとみられる。

楽観的すぎないか
ビットストリームレベルの変更の可能性をチラつかせられてしまった以上、
そうそうほいほいとハードサポートにGoサイン出せないと思うけどな

エンコードの基本アルゴリズムが変更にならない限り関係ないだろ
ハードウェアで実装って言ったって各処理をブロック毎に実装していてそれを呼びだしているだけだろ？
だったら、ビットストリームレベルが変わったって、そこだけ変更すれば使えるのでは？

リコンフィギュアなハード実装でならね

マイクロソフト、「Firefox」用H.264ビデオプラグインをリリース
http://japan.cnet.com/news/service/story/0,3800104747,20424162,00.htm

Win7必須らしい

FirefoxでH.264形式のHTML5動画を再生できるアドオン、Microsoftから
http://www.itmedia.co.jp/news/articles/1012/16/news042.html

そりゃWin7以降じゃないとコーデックを標準で積んでないからな。

Direct2D、OpenGLでのHW描画支援の時にそろって後追いサポートしたみたいに
ffdshow辺りを使って実現する同様のプラグインが公開されたりするんじゃないか？

実際はWMP12無くても動くみたい
たぶん既定のデコーダ使うようになってるんだろうな

動画の部分がWMPのプレーヤーになってしまうな

ただ単にvideoタグの動画をwmpプラグインで再生するための拡張っぽい

もっともシンプルで確実な方法だね

FirefoxのWMPプラグインは大昔からMSが出していてたしねい。
それをちょっといじるだけでいい。

MPEG-4 AVC/H.264 総合スレ Part8
http://hibari.2ch.net/test/read.cgi/avi/1263983676/
こっちにかくべきじゃね

HTML5からH.264を排除

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

爆弾投下ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

http://hibari.2ch.net/test/read.cgi/software/1293031596/594

ずいぶん思い切った手を打ってきたなあ。
しかしWebMって本当に定着するんだろか・・・。

GoogleがAdobe買収してWebMとTheora乗っけて「次の版でH.264削る」と言えば定着する
それが出来なきゃChromeともども消滅

Youtubeブラウザ上のhtml5で見る酔狂な奴なんてほとんどいないんだから何の影響もないだろ

つiPhone/iPad

Youtubeのhtml5モードがあまりにもひどいんでiPhone使うやつらはこんなので我慢できるのかって聞いたときに
そのてのってもともとブラウザじゃなく専用ソフト使うって聞いたけど

酷いってのはhtml5で再生できる動画が全然少ないってことね
Flashでしかブラウザ上では再生できない動画も、再生できるYoutube専用アプリがiPhoneにはあるって聞いた
iPhone持ってないんで全く的外れなこと書いてたらごめん

iPhoneは最初からYoutube専用アプリが有るからFlashなくてもOKだったよ

派手な特殊効果のある企業サイトとかはflashからhtml5に置き換わりそうだが動画は当分ないんじゃないの
携帯なら専用ソフト使ってPC用のウェブブラウザならflashかそれに代わるプラグイン使うって感じになる
入れ替わるころにはH.264もVP8も使われなくなってるだろう

H.265が本命か

今はそれとVPxの前哨戦だろうね
本命はまだまだ先

そっか、adobeがH.264を切ったら
ネットでの死亡フラグだな。
アホン信者が色々吼えそうで面白い。

普及率的にも互換性の観点からもFlashがH.264を切る理由がない。
今でもVP6(FLV)をサポートしているように選択肢が増えるだけ　＞WebMサポート以後

>>780
動画はDRM周りの問題があるので圧倒的にFlash有利だしねい。

んで、スマートフォンやタブレットのような非力な環境だと、Flashで
重いのなら専用アプリ使えやって感じなのでHTML5の出る幕は正直ない。

こういうこと書くとWebMの存在意義まで否定することになりかねないが、
動画周りのHTML5凄いねキャンペーンってなんだったんだろうなと思う
iPhone使いのジョブズ信者も含めて、誰も使っちゃいなかったというのに

> 動画周りのHTML5凄いねキャンペーン
FLASHが嫌がられていたことの裏返し以上ものではなかったのかも。

Flash無しでもブラウザ単体で動画再生可能！とか言ってたけど
結局Google ChromeにFlash同梱しちゃうしねｗ
なんだそりゃって感じ

WebMの画質って公開当初より上がってるの？

いいえ
十年後にまた質問してください

公式じゃなければ良くなってる。
まだまだH.264の方が小さく高画質（＆高負荷）だな

公式のWebMエンコーダーは酷いよね。
Youtubeに使われてるエンコーダーなんて発表以来アップデートされてないし。
oggの音質も悲惨。aoTuVの人が嘆いてたね

ffmpeg.exeのWebMエンコーダーはかなり良い。
プロファイルで簡単に品質選べるのもいいな。
oggの音質もいい。

M$

PSNRマンセーなのを何とかしてくれ
一昔前の最適化手法だろう…

TheoraですらPsy最適化してるのにな

>>786
アポ信者が教祖のFlash憎しを後追いしてhtml5キャンペを張っただけ。
もちろん、アポ信者の戯言なんぞなんの効果も無し。Flashはスタンダード。
今回の件、FirefoxでもH.264がサポートされない件を合わせれば
アポは袋小路になってFlash/WebMの二択を迫られる。
videoタグにH.264は認めないという強力な意思をGoogleが持った。
youtubeを使って締め出すこともありうる。

現在までのモバイル機器でのH.264ハードウェアサポートの普及度を考えると、
個人的には正直余り歓迎出来ない決定だな
オープンなWebの理念は良く分かるし賛同もするが、現実としてどうかと思う

しかしこれで更にVP8の普及進むのだろうか
MPEG LAが計画してるロイヤリティフリー(RF)コーデックも気になる

>>797
Google TV以外の民生機器じゃ通用しない。

普及に関してはFlashにいつのるかということの方が大きいと思う
そしてYoutubeのHTML5の場合はH.264とWebMの両方が使えるブラウザと動画の場合
WebMが優先されることになってるが、Flashの場合どうなるか

モバイル機器で思い出した。

http://pc.watch.impress.co.jp/docs/news/event/20110113_419932.html
　RK29xxシリーズはプロセスシュリンクだけでなく、CPUコアもARM9から
Cortex A8ベースへと変更。動作クロックは1.2GHzとなる。
メディア処理エンジンは強化され、1080pまでの解像度や、
VP8コーデックのデコードをサポート。
GPUはOpenGL ES 2.0やOpenVGをサポートする。


CES: Rockchip gives Google's WebM a hardware boost
http://ces.cnet.com/8301-32254_1-20027785-283.html

>>797
今回のは力の使い方を間違ってるとしかね。
"Don't be evil" ってだけに、本来のevilがもたげてきた。

MozillaやOperaはevilなの

>>799
FlashにVP8が載るのは確かに普及率の面では影響大だね

この先暫くは家電系（カメラや情報家電やゲーム機等）でのH.264
対するWebの世界はVP8/WebM
っていう並立／共存／棲み分けの流れに成るのかな

取り敢えずWebMのエンコーダ／デコーダの改良をがんがん進めて欲しい

WebでもWindows（7以降）とMacOSXが標準でH.264に対応しているし
家電系でもWebが一般的になってきていると考えるとWebMに軍配が上がるとは思えない。

MSにすら茶化されるんだからマジで誰の目から見ても？な判断だったんだな

VP8よりもTheora載せてFLV1を駆逐して欲しいわ

GoogleがTheoraを拒否したのは回線代が高くなるからだぞ

取り敢えずぐぐる先生には、よつべに関して
去年5月の発表以降の「今後は全部webmでもエンコするよ」の約束を
さっぱり守れてない事を早急になんとかすべき

過去投稿分の遡及再エンコに時間掛かるのは分かるが、最近の投稿分でも
またFlashオンリーばかりになってる

今Youtubeで使われてるGoogleのWebMエンコーダーは
遅いうえに画質もクソという酷いもんだからな。

Googleが四半期ごとにリリースすると約束したVP8エンコーダーが
順調に育っていけば、今後エンコードが加速するとは思うが。

10月の記事
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"。
開発テーマはエンコーダの高速化 　　←まもなく出る予定のコレに期待

ホントに四半期毎にリリース出来るんだろうか
ちょっとスケジュール楽観的過ぎな気がするよ

AviUtlでWebMエンコが出来るようになるまで日本では普及しない。

x264が対応する予定じゃなかった？

Google I/Oまでには、GoogleでのWebMまわりの具体的成果が出てくるといいんだけど。
現状、ffmpegではx264とVorbis開発者のおかげで改善されましたよ〜って程度の
話しかでておらず、ぢゃあGoogleはなにやったの?って感じなので。

ぶっちゃけGoogleってほとんど買収だからねえ

GoogleはもうHTML5 videoについてはオープンスタンダード以上のものを
目指していないというか見切りをつけてる気がする。DRMとか絶対入って
こないだろうしね。

googleがアメリカ版livedoorていう評価はあながち間違いでは無かったのかな

Appleはアメリカ版オウム真理教か

オウムVSライブドアか。ワイドショーが賑わいそうだなあ（笑

>>797
RFコーデックが出ればグーグル大勝利じゃね？
グーグルとしては検索人口が増えればいいんだし。

>>817
オウムの教祖が死にそうｗｗ

ジョブズが逮捕されると聞いて来ました！

ジョブズ膵臓移植で治ったんじゃなかったの？
ガン細胞転移しちゃったの？

信者の膵臓を金で奪い取った容疑で死刑

appleはジョブズ教祖が居なくなったら終わりだろうな

世界最高とも言われるCEOをオウム真理教みたいな犯罪教祖と比較するあたり
日本から世界に通用する「個人」がなかなか出てこれない理由かも知れないな

林檎教の信者が何言ってんだか

反林檎教の信者が何を言ってるんだか

企業とは名ばかりの犯罪者集団Apple社

ゴキジルシ乳業

みんなでジョブズをはげまそうよ

麻原が死んだら教団は暴走するとか言われてる。
ちゃんと警視庁はリンゴ教の信者を監視しないと･･･

つか、Apple信者もAppleを頑なに否定する信者も同じだぞ？
どちらも客観的な意見も聞かず、自分の選んだものを絶対的に信じ、敵対する相手を貶貶して布教活動している点で全く同じ。
違いは、自分が教祖か他人が教祖かだけしかない。　気づいてるのか気づいて無いのか、アホなのか・・・。

WebM支持者の本性 = 基地外っぷりが垣間見えて良いじゃんw

Appleはオープンソースの敵

WebMもH.264も取り入れるという選択肢はないのか

つか、WebM(コーデックとしてのVP6)はH.264のサブセットなんだから、H.264に対応して置けばちょっとの修正で両方行けるだろ〜

頑なに否定する信者ってなんだ？

Appleに過剰反応してすぐに信者のレッテル張る奴の事じゃね？

やっぱ教祖が死にそうなんで殺気立ってるなｗ
三度目か四度目くらいのガンなんだから
もうだめぽ。麻原が死刑になるように
あの教祖も死ぬよ。

>>838
オープンソース信者だかなんだか知らんが、いい加減スレ違いの話題蒸し返すのやめてくれ
ただでさえオワコンの2chが誰も見なくなったら本当にゴミになるだろｗ

>>834
その選択肢を選んでるのはMSだけ。

MS・・・IE9のハードウェア支援最強ｗH264どんとこい。ライセンス料も問題なし。
　　　　　WebM？プラグインで対応。あ、FirefoxさんにWin用H264プラグイン提供しちゃうよ
Apple・・・QuicktimeはH264だし。WebMイラネ。HTML5マンセー、Flash氏ね。
Forefox、Opera・・・Web標準主義。H264はイラン。Theora、Ogg、WebM歓迎。Flashは徐々に排除

Google・・・H264排除。WebMゴリ押し。

adobe・・・Flashは両方対応しますんで。分裂バンザーイｗ

何がなんでもH.264をHTML5 videoに押しこみたいAppleの方が無理があると思うが。
プラグインでやればいいじゃんｗ

Google、SafariとIE9向けWebM対応プラグインをリリースする計画を発表
http://www.itmedia.co.jp/news/articles/1101/17/news027.html
Google、IE9とSafariにWebM(VP8)プラグインを提供と発表
http://journal.mycom.co.jp/news/2011/01/20/013/

iPhoneならつべ動画とかどうせ専用アプリで見るしね。

AppleはFirefoxとChromeとOpera向けにQuickTime使うH.264プラグインを作ればいい

WebM = キチガイ

狂信者がスレに住み着いてしまったな。

Appleはオープンソースの敵だからね

いつからオープンソースの敵になったんだよ
MacOS自体、オープンソースのFreeBSDがベースなのになｗ

敵というかフリーライダー

良いと思ったから使う、それだけじゃね？

>>846
たしかにApple狂信者は厄介だね

>>842
CPUパワーの有り余ってるPCならプラグインで良いけど、
携帯機器は専用ハードウェアデコーダを使って再生してるから、
Apple的にはWebMなんか普及して今までの機器が使えなくなると困るのよ。

>>851
あの教祖実際信仰するに値する才能持ってるだけにしゃれにならない

やっぱ教祖が死にそうなんで殺気立ってるなｗ
三度目か四度目くらいのガンなんだから
もうだめぽ。麻原が死刑になるように
あの教祖も死ぬよ。

教祖死亡するとApple信者によるテロが心配だな

彼のプロダクトは信用に値してきたが、宗教とは違い心の支えにはなり得ないから心配は無いだろう
ジョブズ信者でもApple製品をあえて使わない人も少なくないように、総合的に考えて良い物を選んで使うだけ

それより、VP6よりもVP8の方が画質が劣るって話はエンコーダーの質がまだ低いって事なのか？

>>856
教祖死亡で焦ってるApple信者がディスってるだけ

x264のVP8向け派生エンコーダが出れば・・・最近どうなったんだ？

>>852
VP8をハードウェアデコードすればいいじゃん。
どうせ古い端末で新しいiOSを動かしたら重くて使いものにならんし。

どうせWebMはデモ動画とかの低解像度しか使わないでしょ
Youtubeでさえ1080pは存在しないし

>>859
ハードウェアデコードをするならH.264の方が高画質・低ビットレートだから
通信速度の遅い携帯機器でWebMを積極的に支持する要因にはなりにくい。

ライセンス料も性能比や訴訟リスクを考えれば法外に高いわけでもないしね。
そもそもAppleはH.264に関してはライセンス料をもらう側なわけだし。

>>861
Appleは払わなくていいとでも思ってるのか？
払う額ともらう額では払う額のほうがはるかに多いだろ

AACデコーダのライセンス料は、H.264(US$ 0.20/unit)よりも高額になっている。

http://www.vialicensing.com/licensing/aac-fees.aspx

パテントが絡むものをオープンスタンダードの枠外で広めるぶんには誰も文句言わないと思うよ。

AACなんかよりOgg Vorbisのほうが音質もいいしパテント問題もない。
こればっかりはどう見てもAACよりいい

そもそもAACが出張ってきたのはAppleがiTunesでの音楽配信に採用したからで
全くWeb側の理論は無いからな

>>862
Appleが自社製のH.264再生機器台数を元に払う必要がある金額と
全世界、全メーカーのH.264再生機器が払った金額からAppleに支払われる金額、
どっちの方が金額が大きいんだろうね。

WindowsもAdobe FlashもBlu-ray関連機器もYouTubeもパテント料を支払っているわけで

とりあえずMSがもらう金額よりは少ないだろうな
Appleって、名前は載ってるけどほとんど貢献してないだろ

>>865
前から言われてるけど、いくら質が良くても無料で使えてしまうようなフォーマットが常識的に考えて普及するわけがない
黎明期と違って今更mp3のようなケースは出てこないだろうよ
どうやって商用利用出来るか考えるというか、とにかく利益に絡めていかない限りはどうしようもないだろう
WebMの場合だととにかく後押ししてるところはあるんだから後は質の確保が出来ればいいのかもしれないが

>>868
> >>865
> 前から言われてるけど、いくら質が良くても無料で使えてしまうようなフォーマットが常識的に考えて普及するわけがない

どこの常識？

>>865
典型的なWebM脳だね。

やっぱ教祖が死にそうなんで殺気立ってるなｗ
三度目か四度目くらいのガンなんだから
もうだめぽ。麻原が死刑になるように
あの教祖も死ぬよ。

868=870=ただの基地外

糞
http://respic.net/item/410717

>>873
現状、静止画としてはTheoraの方がリードしてるからなぁ

個人的にはISO/IECやITU-Tが標準化してくれるならWebMでも文句ないけど
WEBで標準化団体による勧告等がされてないファイルフォーマットを使う気にはならない。

HTMLもJPEGもPNGもMP3もMIDIも標準化されてきているわけで……

ogg関係のことがいっぱい書いてあるブログで見たが、theoraはDark Shikariの協力を得て
現状でxvidと同等でDark Shikariは将来的にVC-1と同じところまで行くとか言ってるんだろ
theoraで良かったんじゃねって思うが

Googleが言ってる高画質化、エンコ速度向上がどこまで進むのかで、ずいぶん変わってくる話だ。

>>869
どこかの業界とかではなく、普通の人の常識だろう
コピーやデコードを無制限で行えるフォーマットだとメジャーなデータ販売・ネット販売等にまず採用されないと言う常識
業界大手による力づくの普及活動がないんだから一気に広まるわけはないし、
mp3という強力なデファクトスタンダードが存在する以上、個人の中でもちびちびとしか広まらない
無期限無制限でどんな利用でもしほうだいな音楽や動画データを客にコピーさせて、
それで十分利益を出せるビジネスモデルが常識になってきたら変わるだろうけど、現状だとまだまだ一般的ではないよ
基本的に金が絡んでこないものが一気に広まる事はない


個人的には手持ちのCDをよくVorbisでエンコしてたけど、他所からVorbis物を手に入れることはまずなかったなあ
最近だと汎用性やHDDの容量を考えると音楽なんて可逆圧縮とmp3だけで十分だと思えてきた

NHK（だけじゃないけど）みたいに動画サイトで自社の番組を公式に視聴させてるところもあるし、
これからはまた違ってくるのかもしれないけどね
http://internet.watch.impress.co.jp/docs/news/20101206_412181.html
今まで無料のフォーマットだとその無料と言う点が重い足枷になっていたのは間違いない

コピーやデコードを無制限で行える事とライセンス料が有料であることの関係が分からんのだが

俺にはむしろライセンス料が有料と無料の場合の違いがわからない
>>879売手と買手を明確にしろという話か？

D:jMLdDoGxはキチガイ
ただそれだけのことだ

無料だと普及しないとかそんな常識初めて聞いた

>>880
まず、>>869に対して>>877で「どこかの業界とかではなく、普通の人の常識だろう」
と言っていたから無料で使えるフォーマットは普及しないという立場だと解釈した
さらに>>877の2行目以降で「コピーやデコードを無制限で行えるフォーマット〜」と展開してたから
ライセンス無料のフォーマットとコピーやデコード〜を絡めて話してるんだと思ったんだけど
1行目と2行目以降は全然別の話なの？

ライセンスの話は知らんよ？
専門家じゃないんで
技術的に制限をかけてないフォーマットで意味があるとはあまり思えないけど、技術論とライセンス料の設定は本来なら無関係じゃない？

>>882
それはお前がモノを知らないだけかと
現にVorbisなんてAACに勝るとも劣らない物なのに実際それ程普及してない
一方AACは世界中に溢れてるし日本だと四六時中TVから流れてるくらいに普及してる
品質さえよければ広まるってものじゃないのは確かだよ
趣味で使う人間からすればそこそこ一定の割合で利用者や開発者がいてくれれば万々歳だけどね
スポーツが大好きだからといって拝金主義のオリンピックが大好きとは限らないのと同じようなもの

>>884
お前がモノを知らないだけだろ

VorbisがWMAやAACに勝てないのは無料だからじゃない。
普及促進する大きな後ろ盾が存在しないからだ。

Vorbisをハードウェア再生支援・エンコード支援するチップの開発利点をプレゼンするヤツがいたか？
パソコンで簡単に再生・エンコードするための環境を普及させられるようなヤツがいたか？

MicrosoftもAppleもそこに重点を置いて投資したから現在の立ち位置にいるだけで有料コーデックだからじゃない。
フリーコーデックであるVorbisだってMSなんかに負けない普及活動を行っていたらAACに勝てた可能性は十分ある。

Vorbisの再生に対応した再生機なんて韓国製ぐらいだしね

スマホで聴けばいいんだよ

無料のフォーマットでも実はライセンス的に不味いコードや、特許技術が混入してたりって不安があると
採用しづらい。突然訴えられたり、ライセンス料払え何て言われると困るから。
逆に言えば、そんな不安が無くて出所がはっきりしてれば、無料でも普及する可能性はある。
無料とか有料とか関係無いよ。

結局ID:ZO0A+WeQが何を言いたいのかさっぱり分からないので俺は引っ込みます
スレ汚してすまん

>>885
なんか基本的な部分では>>877と同意見に見えるな
金が取れるのなら企業が後ろ盾に付きやすいが、無料でコンテンツを大々的に配布する企業は少ない
普及促進する為には確実に課金できるものじゃないと厳しいからこそ企業側から無料は嫌われたんだろう
個人で使うならたとえメジャーじゃなくても無料の方がありがたいけどw

逆に言えば金のかかった創作物を無料コピーし放題にしても利益をあげられる仕組みを作ることが出来ればいいということか

>>890
なんか話がごっちゃになってると思うのは俺だけか？

ライセンスとDRMがごっちゃになってる。

一切DRMの話題なんて出てきていないんだがｗ

コピー云々はDRMだろ。

コピーやデコードを無制限で行えるフォーマット云々言っておいて
mp3が存在する以上っていう時点で理論破綻
mp3にDRM追加した拡張規格が普及して無いのが何よりの翔子

本田雅一氏がWebMについておもしろいことつぶやいてる。
何かGoogle、ヤクザだなぁ。
ttp://twitter.com/#!/rokuzouhonda
エグイというのは、VP8のライセンス条件において、あらかじめMPEG-LAの存在を想定した上で
サブライセンス権を持つ法人が訴訟した場合、ライセンス元もソースコードライセンスを失う条件が
付けられてます。このためMPEG-LAがパテントプールを集めてライセンスを支払えとやった時点
で、MPEGの権利者たちはソースコードライセンスを失います。
つまるところ、最初から特許侵害している事を解った上で無料にするためにあらかじめAndroidを
フックに罠を張ったということですな。2.3でのWebM統合では必須コーデックではないけど、
ChromeとYouTubeでWebMが必須になる罠もかけてあるので使わないと競争力がなくなる。
この方法がまかり通るとパテントプールが意味をなさなくなり、以前と同じようにライセンスが複雑
になる。あるいはパテントトロールに売り払って、ゲリラ的に取れるところから取りまくるとかが
横行することになるのでは、とある知財の専門家は話していました。なおGoogle自身はMPEG-LAに
対して、まったくライセンスを支払う意志がないと伝えている、と漏れ伝わってきている（口伝ですが）
ので、たぶん裁判引き伸ばしで係争が無意味化するまで無視し続けるのでは？

何かと独善的立ち振る舞いを指摘されるGoogleとApple（昔のMSみたい）だけど、実はAppleは
知財に関してきちんと調べてライセンスした上で製品化する。彼らは品質や納期、守秘義務などを
担保するために部品代を必要以上に値切らないし、そういうところはきちんとしてる

>>895
大昔とは違うんだから二匹目のドジョウはいないって話だろ
最近は、特に海外だとDRM制約のないネット販売が積極的に広める動きになってるからそんな時代すらまた過ぎるのかもしれないけど

>>895
逆に素のAAC自体にもDRMは無いもんね。
AppleがDRMを被せたのがFairPlay、国内TVならSTD-B25。

商業利用だからDRM必須というのはわかるが、
各社のパテント等の思惑からたまたまAACが採用されただけでしょ。
どのフォーマットを採用するかにDRMは関係ない。必要なら被せればいいだけ。

>エグイというのは、VP8のライセンス条件において、あらかじめMPEG-LAの存在を想定した上で
>サブライセンス権を持つ法人が訴訟した場合、ライセンス元もソースコードライセンスを失う条件が
>付けられてます。このためMPEG-LAがパテントプールを集めてライセンスを支払えとやった時点
>で、MPEGの権利者たちはソースコードライセンスを失います。
その条項って削除されたんじゃ？

Appleは他者の知財は無いものとして行動する
自社の知財は暴力に訴えてでも守る

MSがどんどん健全化するに従って競争力を減らしていったのをみんな見てるからな。
競争力維持のためには、MS帝国時代の横暴政策が必要だと気づいたんだろ
AppleもGoogleもAdobeもね

>899
削除されてないよ。今でもアグリーメントに書かれてる。VP8はAndroidとは切り離された
特殊ライセンス。サブライセンサーが訴えると自動的にライセンサーのソースコード使用権
が失効するから、MPEG特許を活かしておきたい場合、端末機器メーカーは泣き寝入りする
か、中華・半島メーカーとVP8サポートなし端末で競合する以外に道はありません

ていうか前に出ていた話を情弱が蒸し返しただけに見える。