【Youtube】WebM・WebPを見守るスレ【Chrome】
■ このスレッドは過去ログ倉庫に格納されています
HTML5への採用を目指し開発が進むオープンな動画規格「WebM」と、
そこから派生してJPEGの後継を狙う静止画規格「WebP」ほか、
ChromeやらYoutubeやらHTML5の対応状況などの周辺事情などについて見守るスレです。
WebM本家
http://www.webmproject.org/
WebP本家
http://code.google.com/intl/ja/speed/webp/ 画像の世界がbmp、Jpg、gifで長期停滞してようやくPNGが市民権得てきた間に、
動画の世界ではH264が制して、更に次世代のH265、VP9、Daalaとか出てきてる
で、動画の圧縮には必ず静止画の可逆圧縮がIピクチャとして使われるので
可逆圧縮という点では動画側のほうが技術革新が進んだ
WebPはVP8のIピクチャ部分の技術を抜き出しただけだからな VP8のエンコデコードともopencl版あるようだ
ttp://wiki.webmproject.org/vp8-implementations
VP9に対応してデコードをブラウザに組み込めたら割と面白い存在になりそうではある。
Firefoxも28だったかなでVP9対応って話は聞いた Google、モバイル版Chromeのデータ圧縮機能を公式にリリース―データ量を最大50%節減
http://jp.techcrunch.com/2014/01/16/20140115google-adds-optional-data-compression-feature-to-chrome-for-mobile-reducing-your-data-usage-by-up-to-50/
>ユーザーがChromeのデータ圧縮/最適化オプションをオンにすると、Android版でもiOS版でも、
>最大で50%もデータ量を削減できるという。
>前に述べたように、PageSpeedライブラリーを利用して画像ファイルをJPEGやPNGから
>GoogleのWebPフォーマットに変換するだけでも大きな効果がある。
>というのはウェブページでは平均してデータ転送量の60%が画像だからだ。 OperaのOpera Turboの丸パクリやな
Opera Turboも、画像フォーマットにWebP使ってるんやで Intel, NVIDIA, ARM, Broadcom, LG, Philips, Samsung,
and Realtek are among the many companies that have agreed to incorporate VP9 codec support
割といい感じではあるがAMDがねぇw
265はブラウザ対応遅れるだろうからこっちのほうが早いだろうけど
エンコ周り265と比べて遅れてるのが気になるが・・・ 利用自由なHSAがあるんだから、HSAを使ったVPデコーダエンコーダを誰かが作ればいいだけ。
VP9を普及させたいGoogleの役目だろう Googleにやる気を感じないのは気のせいか?
VP8の改良も実質他所任せだったし VP8って、2年2回の大幅アップデートでx264に迫るとか言ってたのに
全然アップデートしなくなって久しい。 ARM Mali T604でVP9でもopenclでデコードできるようだ モバイルでのGPGPUは消費電力的に動画のエンコードやデコードに向いてないよ
GPUは浮動小数点演算器の塊だが最新のコーデックは整数演算しか使わない 現行機種がopenclに対応してるのか
ハードデコードは対応してないだろうけど
そこらの按配だろうね MulticoreWare Accelerates VP9, Google’s Next-Generation Open Video Codec
http://www.prweb.com/releases/2014/02/prweb11612574.htm
openclでのデコードらしい
Android用っぽいけど webp形式とか馬鹿じゃね?
まず拡張子の法則通り3文字にまとめて出直せ
グーグル調子乗りすぎ >>748
長大なレジスタを分割して、複数の値を一括で処理できるのがベクトル命令の売りで、
それが整数だろうが浮動小数点だろうが関係ないんだけど。
>>752
.z .gz .c .pl .py .sh… 拡張子はそれよりも、パレットカラーなのかフルカラーなのか、静止画なのか動画なのか、可逆圧縮なのか非可逆圧縮なのか、αchがあるのか無いのか、
を拡張子で明示してほしい(´・ω・`) >>755
MPC-BEではWebP lossless ということでwebpllの拡張子をつけてるな >>123
おいおい…自分と違う考えを持つ奴はみんなアトムの回し者ですか?
まず、自分が今ヒステリックになってる事をきちんと理解して落ち着け。
>過ぎたるは猶及ばざるが如しって諺知らない馬鹿だな!!
全然過ぎたことじゃない。相談窓口に連絡するというのは、ごく当たり前のことだよ。
アプリでも、不具合が起きたら、調べられる程度の状況を調査してバグレポート書いて送信するだろ?全然日常的なことだろ。
それに、今回の場合明らかに接客に問題があったんだろ?それなら問題があったことをきちんと教えてあげたほうがいいよね。
そもそも、テーブルにアンケート用紙を置くくらいなんだから、そういった不満があったことをアトムは普段から知りたがってるわけじゃない?
そうした、問題が起きたことを認識させることで、再発防止のためにマニュアルの修正や、問題店舗の改善・指導を行うことが出来る。
これは、ここに愚痴をこぼす事より、よっぽど生産的なことだと思うのですが、どうでしょう?
あと、ここに書き込むのと同じノリで、店員にもヒステリックに食って掛かったら、大抵のやつはビビってパニクるぞ。
ちょっと煽った文章にしただけで、3レス連続で書き込むくらいだから、普段からキレる癖ついてるだろ。注意した方がいいよ 長文誤爆したorz むちゃくちゃ恥ずかしい、穴があったら入れたい WEBPへの一括変換でいいソフトなイカな
いまんとこIrfanView(但しサブフォルダ階層には未対応)くらい? ImageMagic使えば
>convert image.jpg image.webp
>mogrify -format webp *.jpg
とかで変換できる >>763
とは言っても、ちょっと定番から外れたことしようと思うとmp4はとたんに使いにくくなってマトリョーシカ使いたくなる
mp4にhevc入れると、mpc-beでは再生できないし。これは時間の問題だけどさ 仕事で社内webシステムに動画を配置することがあったんですが、
最初mp4だったのが「再生出来ない」という問い合わせ多数で結局wmvになった。
業務用はIEとWindowsしか使わないから。
すべてのmp4というわけではないけど、Google Chrome単体でmp4が再生出来ることを初めて知った。 >>765
Winも7ならシステム標準でH.264なmp4を再生出来たような VP8なWebMもMF用のデコーダーさえ有ればIEで再生できるんだっけ W杯のゴールシーンをgifじゃなくてwebmにしてるのを見かける
サイズがでか過ぎるgifの代わりとして普及してくれるとありがたい HTML5のvideoタグでautoplayとloopを記述すればgif感覚で使えるのかな と思ったらTwitterがgif対応としてmp4にエンコードして>>770してた http://jp.techcrunch.com/2014/06/20/20140619facebook-for-android/
>Android版Facebookアプリのデータ効率をできるだけ高くするために、
>同社は異なる画像圧縮技術を試し、WebPに切り替えることを決めた。 >>772
あれ?評判悪いんで、辞めましたって話無かったっけ?
ちなみに現状だとアップロード、つまり読み込みすら対応してない >>772-773
ttp://japan.cnet.com/news/commentary/35031278/
過去に一回導入に失敗してるけど、再トライするっぽいね
ttps://code.facebook.com/posts/485459238254631/improving-facebook-on-android/
取り敢えずはアンドロイド向け限定の様子
ttp://html5experts.jp/jxck/2550/
JPEGとwebpの比較
PC上のChromeで閲覧してみたけど、結構良いね なぜかどこも大変良い出来のWebPとOpusを採用しないなあ
携帯電話、デジカメ、小型音楽プレーヤー、テレビ、デジタルラジオ辺りに使えそうだけど 919 名前:名無しさん@編集中[sage] 投稿日:2014/07/07(月) 12:34:13.09 ID:zm/1emx0
【速報】YoutubeのWebMの中身がVP9になっとる
920 名前:名無しさん@編集中[sage] 投稿日:2014/07/07(月) 14:49:03.51 ID:J8aZHzYg
速報というほどでもないかと。5月頃から順次VP9に切り替わってましたよ。
対応OSとブラウザで再生時に右クリックで詳細統計情報を開くと
その動画がCodecにVP9を使ってるかどうか確認出来ます。 5月どころか去年10月には始まってたし
>>672以降でやり取り有る通りだよ 前から変化があるわけではないな。
FirefoxもVP9対応したけどyoutubeでの再生は難有っていうかconfigいじらないとできないのな。 FirefoxのMediaSourceExtensionsはまだ難ありと言うかyoutubeに対応してないと言うかそんな感じ。だからデフォルトではMSEオフ。 ffmpagでVP9のエンコをいろいろ試してるんだけれど、
パラメーターの意味がさっぱりわかんないね
bitrateとcrfはいいとして、quality、speed、cpu-usedってなんじゃ
まともに解説してるサイトも無いしなぁ
あと、4コアCPU使っているけど、どうやってもCPU負荷30-40%くらいにしかならない
全コア平等に使われているようだが、全コア空いてる状態
何なんだこれ Google主導の割には、情報が少なすぎてなんとも
本当にやる気あるのか クラウドの多CPUをフル回転してなるべく速くエンコしたいはずなのに、
こんなにマルチスレッド化が遅れてるようなエンコーダーをGoogleがほ
んとに使ってるのかね?
何か設定間違えてるのかな 実際に運用するときにはファイル単位で並列化してるようなもんだし
下手にマルチスレッドに最適化して、圧縮率を犠牲にするより良いんじゃね?
まあ、単純に開発が進んでないだけな気もするけどね >>782
>>723-728の(VP8での)オプション設定の方法は参考になったりしない? >>783
いままで20点だった画質がやっと50点になったってだけで、所詮再エンコのクソ画質だし
やる気ないんじゃね?
再エンコなしのh.264にはまったく歯がたたないし YouTubeってH.264でも問答無用で再エンコしてると思ってた 再エンコ無しってFC2(2chのFC2スレ以外にソース無し)とニコニコしかないんじゃないの
なぜか海外の動画サイトは問答無用で再エンコするのな 今のYoutubeは1ファイル20GBまでアップロードできるから
H.264 lossless/リニアPCMで編集してそのまま上げれば再エンコ無いんやで(にっこり) いや、その20GBを俺らは見れないわけでw
せいぜい数Mbpsに再エンコされた動画をストリーミングで見てるんだよ
もっとも、Youtube側がエンコーダーの仕様やエンコーダーそのものを入れ替えた時、
もとの20GBから再エンコされるという強みはあるけどね ニコニコ動画なんかだとユーザーが再生環境の事考えてないようなすごい設定で投稿してることもあるから
Youtubeみたいに動画サイト側で一律の設定でエンコードするのは妥当といえば妥当かと。 汎用性の高いPCならともかく、
仕様決めうちであとから変更しにくいネット機能付きTVやSTBとかで観る場合なんかは
一律設定の方が都合良いからね 2GB以上ある元の1080pゲーム動画と、VP9変換後のもの(約600MB)を比較したら
見るに耐えないレベルだったw
ほぼ720p以下相当の画質まで落ちてるわ >>794
比較の仕方がおかしい
同ビットレートのH.265、H.264とVP9を比較するか
元の動画とエンコード後の動画を比べて、違いを認識できるビットレートを調べるとかならわかるが
非可逆でエンコかけたら画質が落ちましたって言われても >>795
ただ単に上のレスからの流れで、Youtubeにアップする前とYoutubeで再エンコされたVP9の比較しただけ。
VP9がクソといってるわけじゃないっす。スマソ そもそもYoutubeが高画質だったことなど無いわけで。
常に速度優先のクソ設定でエンコしてくれるからな。 よううつべでVP9が普及してWebPもバージョンアップしてくれると良いな WebPはGoogle検索や画像検索に勝手に使われてどんどんVerUpしてるし
VP9もYoutubeに勝手に使われてどんどん鍛えられてってるね ついでにPicasa/Google+の写真もWebPに自動変換して欲しい Chromeで画像検索した時の表示が軒並みJPGなんだが、webp用に何かの設定が居るの? >>800
ダウンサンプリングせず4:4:4変換になってくれたら同意 AviUtlのL-SMASH Worksという入力プラグインの動作を調べていた過程で、WebMについて
いくつか疑問が出てきたのですが、詳しい方がいたらわかる部分だけでも教えていただけないでしょうか。
1.YoutubeのVP8のWebMについて
1−1.mkvinfoで見ると、コンテナの「デフォルトのフレーム持続期間(DefaultDuration)」が
1msに設定されているせいか、真空波動研などは1000fpsと判定してしまうようです。
なぜYoutubeではこのような設定がされているのでしょうか?
1−2.mkvextractでタイムコードv2を抜き出してみると、複数のタイムコード重複が見られます。
おそらくはAltRefフレームのタイムコードが他のフレームと重複しているのだろうと
推測していますが、これは正しいでしょうか?
1−3.1−2に関連しますが、ffmpegもVP8で -auto-alt-ref 1 の場合は重複タイムコードがつきます。
しかし、vpxencの場合は重複しないようになっています。
ttp://www.webmproject.org/docs/container/#vp8-alternate-reference-frames
を見ると重複させないことが望ましい(タイムベースの粒度が荒い場合は重複可?)ように
読み取れるのですが、重複させることに問題は無いのでしょうか?
2.AltRefが有効なVP9-WebMについて
2−1.AltRefが有効なVP8-WebMの場合、mkvextract timecodes_v2でタイムコードv2を取ると、
本来のフレーム数にAltRefフレームを足した数のタイムコードが取れますが、
AltRefが有効なVP9-WebMの場合は、本来のフレーム数分のタイムコードだけが取れます。
ttps://groups.google.com/a/webmproject.org/forum/#!topic/webm-discuss/hQAGZeKQK-E
を見ると、VP9のAltRefフレームの扱いはVP8とは変わっているようなのですが、
VP9-WebMでは「AltRefフレームのタイムコードはmkvextractでは取れない」というのが仕様なのでしょうか?
2−2.2−1に関連しますが、YoutubeのVP9-WebMをffmpegで
ffmpeg.exe -i YoutubeVP9.webm -c:v copy RemuxVP9.webm
として素通しで再muxし、mkvextractでRemuxVP9.webmからタイムコードを取ると、
YoutubeVp9.webmから取った時と異なり、VP8と同様に本来のフレーム数に
AltRefフレームを足した数のタイムコードが取れます。
このffmpegの再Muxの挙動は、VP9のWebMのMux仕様として正しい挙動なのでしょうか?
2−3.Mkvtoolnix 7.2.0のmmg.exeで、「WebMの規格に準拠したファイルを作成する」にチェックを入れると、
「このトラックはWebMと互換性がないため、有効化することはできません。」と言われ、
VP9のトラックがMuxできなくなります。MkvtoolnixはまだVP9のWebM準拠Muxに対応していないのでしょうか?
2−4.VP9のWebM-Mux仕様について、解説しているページなどがありましたら教えていただけないでしょうか?
上記プラグインの調査報告に使ったものですが、サンプルファイル等はこちらにまとめています。(76MB。10月末に消えます。)
ttp://www1.axfc.net/u/3340179?key=aviutl
よろしくお願いいたします。 Firefox33がリリースされ、CiscoのOpenH264をサポート。
OpenH264 Now in Firefox | Andreas Gal
ttp://andreasgal.com/2014/10/14/openh264-now-in-firefox/
>Mozilla continues to support the VP8 video format,
>but we feel that VP8 has failed to gain sufficient adoption to replace H.264.
(MozillaはVP8のサポートを継続するが、VP8はH.264を置き換えるには至らなかった)
まあ今更だけど・・・。 そういえばFirefoxでYoutube(HTML5)を見るとVP8で再生されるんだけど、
VP9の対応はまだなんだっけか vp9が出てきたらwebpもそれベースのやつになるのかな。
それとも違う規格として出直すのかな。 about:configでmedia.mediasource.enabledをtrueに変えたら良いみたいね >>808
やめとけ。更新されたばかりのFirefox33で試してみたけど、状況は>>780-781と同じでまともに動かない。
シークで反応しなくなったり、Firefoxのプロセスが残りっぱなしになって
タスクマネージャーからの強制終了が必要になったりする。 >>809
了解。元々不完全だからデフォで有効化されていないのだろうし、
まだ当面は待った方が良さそうだね。アドバイスサンキュー VP9が見たいならChome使ってHTML5プレイヤーをenableにしろ
動画のほとんどがVP9だ ARM、ハイエンド向けGPUのMali-T860などを発表
ttp://pc.watch.impress.co.jp/docs/news/20141031_673992.html
ttp://www.arm.com/ja/products/multimedia/mali-video/mali-v550.php
VP9無いん? まあ、jpeg xrとかjpeg 2000もないみたいだしよく使われている奴だけ
対応してるって感じじゃないの。vp8には対応してるのにね。
普及してない無駄な回路を積めるほどの余裕は今のarmにはないって感じなのかな。 Fx36:VP8ビデオコーデックを用いたWebM形式の動画を再生する際、Intel CPUの動画再生支援機能を利用できるようになったようだ。
ttps://twitter.com/rockridge07/status/538707853641396225
モバイル向けはVP8ハードデコードサポートしてるようだね 仕事でwebmファイル使うようになったよ。
PC用がmp4、Android用がwebm。 >>816
VP8なんて誰も使ってないのに。
Youtubeで使われてるのもVP9だし。 Chromeは9だろうけどFirefoxはまだ8だな
IEは対応してるかどうか不明だけど >>818-819
YoutubeはVP8の動画も生成してるけど、FirefoxでもChromeでも使われてない。
使われることってあるのかな?
IEはWebM(VP8,VP9)には対応してない。IE用のWebMプラグインはあったが
放置されてるっぽいし、試してはいないがVP9は再生できないような気がする。
The WebM Project | WebM Components for IE
http://www.webmproject.org/ie/ >>820
FirefoxでHTML5優先+MSEを有効化してない時(デフォ状態)ではVP8で再生されるよ >>823
Win8.1+Firefox34.0だけど、VP8は使われてないよ。
360pで右クリックから詳細統計情報を見るとAVC(MP4)になってる。 デフォがオンに代わってて264使うように変わってるのか。
36でオンになるとみたからまだだと思ってたわ
VP捨てたんかな >>825-826
いや、34.0ではまだMSEはデフォでOFFでしょ。
ttps://www.youtube.com/html5
で、「HTMLVideoElement」「H.264」「WebM VP8」の3つだけ青チェック、
「Media Source Extensions」「MSE & H.264」「MSE & WebM VP9」は「!」という
デフォのMSEオフ状態で動画を見るとavcになってるけど。
ちょっと思いついて
media.windows-media-foundation.enabled
をデフォのtrueからfalseに変えてみたら、H.264が再生できなくなるせいかVP8になったから、
そっちの環境でこれをfalseにしちゃってんじゃないかな? >>827
OSX10.10.1+Firefox34.0.5 :確認したところH.264未対応だった
Lubuntu14.04+Firefox33.0 :H.264対応済み
前者では>>822,後者ではそちらと同じ動作になったので
FirefoxのH.264対応状況がプラットフォームごとに異なるのが原因だった模様
前者でも時間の問題で対応すると思うので(元々システムレベルでのH.264ライブラリも有るし)
>>820のYoutubeのVP8に関しては「以前はFirefoxでHTML5視聴の際に使われていた」という感じになるかな 無料でH.265以上のクオリティを実現できる次世代ビデオコーデック「Daala」の開発は順調
http://gigazine.net/news/20141224-daala/ 問題ないでしょ。
YouTubeが見れないなら大問題だけど、そういう話も聞かないし。 事実上youtube専用という時点で問題あると思うけど
普及はもう諦めたのか むかしは拡張子戦争だったけど、今は規格だよね。主要ブラウザーで見れるかどうか。
Googleはカネにならないと判断すると、すぐに捨てるからな〜 【VP8・VP9】Windows2000でWebMを再生してみた。
http://www.nico video.jp/watch/sm26627739 >>834
主要ブラウザで見れるかどうかはGoogleにとってはどうでもいい
Chromeという主要ブラウザを抑えてるからな
だからVP9なんていう変な形式をおおっぴらに使ってられる androidのシェアもでかいだろうなー
PCもVP9のハードウェアデコードができるオンボードグラフィック増えてるし PCだとOS側の対応が進まないと使えないような気が ■ このスレッドは過去ログ倉庫に格納されています