350:名無しさん＠編集中
18/03/28 22:45:45.37 DkDQClUJ0.net
AV1始動アナウンス来たみたいだ。
URLﾘﾝｸ(twitter.com)
We’re excited to announce the launch of #AV1!
#AOMedia is ushering in the royalty-free, UHD web video era.
22:05 - 2018年3月28日
The Alliance for Open Media Kickstarts Video Innovation Era with “AV1” Release ? Alliance for Open Media
URLﾘﾝｸ(aomedia.org)
351:名無しさん＠編集中
18/03/28 22:48:29.37 DkDQClUJ0.net
Introducing the Industry’s Next Video Codec: AV1
URLﾘﾝｸ(blogs.cisco.com)
352:名無しさん＠編集中
18/03/28 22:52:36.11 KWy8aHMRp.net
なんかロゴが折り紙のように見える
もしかして折り紙的な技術が使われてるとか？
353:名無しさん＠編集中
18/03/28 22:52:50.57 1p2enfpya.net
放送に採用されないコーデックは、どこまでいっても中途半端
ライセンス逃れを開発理由の一つにしている時点で、自ずと限界は来る
354:名無しさん＠編集中
18/03/28 22:54:26.95 DkDQClUJ0.net
Google, Microsoft, Amazon release AV1 compression technology for better streaming video - CNET
URLﾘﾝｸ(www.cnet.com)
355:名無しさん＠編集中
18/03/28 23:03:54.41 DkDQClUJ0.net
aomのコードはまだリリースタグはついてないのか。
356:名無しさん＠編集中
18/03/28 23:37:59.33 FSdNM0II0.net
標準品質で同じ動画を変換するとx264よりx265はどんだけ遅いんだ？
357:名無しさん＠編集中
18/03/28 23:54:01.29 tB8dFHAWd.net
ストリーミング時代に放送がどこまで生き残れるかっていう問題が
358:名無しさん＠編集中
18/03/28 23:57:41.47 DkDQClUJ0.net
>>342
そんなんソースや設定とかによるからなあ。
とりあえずベンチマークスレで色々な環境での結果を見てくるといいんじゃないだろうか。
【x264/x265】実用エンコベンチ Part6
ｽﾚﾘﾝｸ(jisaku板)
359:名無しさん＠編集中
18/03/29 00:40:49.60 wfTjtMTVd.net
俺のRyzen3 2200GだとフルHDの30fpsの動画でx264で20fps、x265だと5fpsくらいしか出なかった記憶がある。まあ普段はHWエンコードしてるんだけど
360:名無しさん＠編集中
18/03/29 01:31:18.21 yJcJr/Yv0.net
もう、昔より半導体の微細化のペースとか遅いんだから、
解像度上げるペースとか新しいコーデック開発するペースも遅くしろよ。
361:名無しさん＠編集中
18/03/29 01:40:01.16 3HDmcthRM.net
>>342
同等の量子化係数でブン回しても6倍以上は重くて、売り文句みたいに2倍も縮むのは希で2/3ぐらい
362:名無しさん＠編集中
18/03/29 08:11:10.11 aTEBv0AB0.net
>>336
Appleからの歓迎コメントがない・・・
363:名無しさん＠編集中
18/03/29 09:23:09.44 /JmJOkBAM.net
>>347
自分環境かつ自分がよくエンコするソースでベンチ取った時
x264のslow?slower?よりx265のfastの方が1.3倍速くて1.6倍程度ビットレート比で綺麗だったから重用してる。
ソース次第やね
364:名無しさん＠編集中
18/03/29 11:50:46.91 Sz3XH2/20.net
>>348
Founding Membersの中ではIBMのコメントも無いね。
Appleは入ったのが今年１月だし、まだ様子見ってのもあるのかもね。
365:名無しさん＠編集中
18/03/29 11:59:27.77 Sz3XH2/20.net
366:https://twitter.com/tmvn/status/979038621746413568 > Also, @JonatanDivideon made a mistake on his chart, and everyone keeps reprinting it. > The Fraunhofer HEVC patents were purchased by GE Licensing. They're in the HEVC Advance pool. >>340の記事でも引用されてるHEVCのパテントライセンス図に Tom Vaughan 氏がコメントしてた。 FraunhoferのパテントはHEVC Advanceに参加してるGE Licensingに買収されてるそうだ。
367:名無しさん＠編集中
18/03/29 12:29:54.99 IEct+tAwMNIKU.net
>>349
そりゃプロファイル変えていればね
プリセットを変えればH265のコア部以外の「x265やx264が実装している工夫の部分」で重さが大きく変わる
368:名無しさん＠編集中
18/03/29 12:30:54.42 IEct+tAwMNIKU.net
>>352
プロファイルじゃないや、プリセットだね
369:名無しさん＠編集中
18/03/29 13:04:48.16 51r+c9a8MNIKU.net
x265については、プリセットから速い方から2つめのsuperfastと3目のveryfastの間で、3割ぐらいと大きく画質容量比が悪化するので、
有る程度処理の速さを求める場合でもultrafast～superfastは止めて、veryfast以上、出来ればfaster以上を設定ベースにするといいと思う
crfベースでx264とx265のSSIMを比較した場合、crf 23あたりからSSIMの開きが広がる
画質劣化が知覚できるとされるSSIM 0.985を割り込まなず直近上位になるcrfは、x264はcrf 26、x265ならcrf 28になる
x264でcrf 25、x265でcrf 27の場合だと双方ともギリギリでSSIM 0.985を下回るぐらいになるので
放送波ソースで画質保持ならcrfの設定はここらへんが妥協の境界になりそう
370:名無しさん＠編集中
18/03/29 13:48:04.34 2l+rGyKqMNIKU.net
QSVの場合だと、SSIMの0.985挟むcrf（ICQ）がH264でICQ 20～21、HEVCでICQ 22～23あたり
もちろんソースの動きや画の内容で左右される部分は有るけど、うちのところで基準にしてるソースでSSIM拾った感じはこんな感じになってる
371:名無しさん＠編集中
18/03/29 14:14:56.73 F3GGU69n0NIKU.net
>>354
こういう理論的なものと経験則が合致してたらちょった嬉しい
ちなみにx265は --rect --limit-modes を付けたときの画質向上率が凄いと思う
372:名無しさん＠編集中
18/03/29 16:12:48.52 caRlMFDo0NIKU.net
ようやくAV1が表に出てきたと聞いて飛んできました
自分の使い方だと265は264比で大体エンコ時間3倍強でサイズ3割減ぐらいかなぁ
コーデック乗り換えって労力大きいから、ここから乗り換えるとなると
AV1には相当頑張ってもらわないとならない
373:名無しさん＠編集中
18/03/29 17:31:38.63 uSRvzlAxMNIKU.net
>>356
rectはブロックサイズのパターン増えるから捜査処理増えるるけど縮むよね
個人的にはrect入れるならampも入れちまう様にしてる（更に遅くなるけど
※両方とも初期値で無効、ampはrect有効時のみ使用可
あとは--limit-modesはplaceboプリセットじゃないと有効になっていないはずなんで記述する必要は無いかも
比較測定値的なSSIMは下がるけど、人間の知覚的判別しづらいところで圧縮稼ぐpsy系オプションも面白い
psy-rd（デフォルト0.3）とか、表示環境のパネルサイズや解像度に合わせてとかで上げてやると量子化が捗る
374:名無しさん＠編集中
18/03/29 18:06:51.46
375:F3GGU69n0NIKU.net
376:名無しさん＠編集中
18/03/29 18:41:24.30 Sz3XH2/20NIKU.net
>>358
--limit-modesはslow～veryslowで有効、それ以外はplaceboも含めて無効。
(というかここまで詳細な話はx265スレでやった方が良い気も)
URLﾘﾝｸ(x265.readthedocs.io)
URLﾘﾝｸ(bitbucket.org)
377:名無しさん＠編集中
18/03/29 19:20:41.29 0fgUeEol0NIKU.net
HEVC/H.265対抗の動画コーデック「AV1」が正式リリース
～ロイヤリティフリーで利用可能、HEIF対抗も登場か
URLﾘﾝｸ(pc.watch.impress.co.jp)
378:名無しさん＠編集中
18/03/29 21:55:48.46 r/53oFMMMNIKU.net
>>343
いまどき同軸ケーブルだの分波器だの時代錯誤だわな
B-CASカードの次はACASチップ内蔵で利権ウマウマ
379:名無しさん＠編集中
18/03/29 22:15:44.03 5siG2sKR0NIKU.net
バイナリ置いとくわ
URLﾘﾝｸ(www.axfc.net)
380:名無しさん＠編集中
18/03/29 22:21:41.76 Vw8NIuSYHNIKU.net
ACAS＋HEVC＋ACASで海外家電メーカーの参入妨害
利権大国日本
381:名無しさん＠編集中
18/03/29 22:28:23.96 zuIbo6KKMNIKU.net
>>360
なるほど、支障が無い限り更新していないから自分バイナリはプリセットが古いのかもしれない、thx
psy-rdは処理的にピクセル単位の径なんで1.0以下が良いね
動きに対する対応考えればそこから1/2なり1/3するイメージで、逆に動きが無ければバイピクセルな1.0にという感じかと
…とここらへんにしとくか
382:名無しさん＠編集中
18/03/30 00:08:19.72 KTEhNckb0.net
将来、「放送」で生き残るのはＮＨＫだけかな
民放は系列がだんだん減っていくね。
特に危ないのは、フジ系とテレ朝系
383:名無しさん＠編集中
18/03/30 00:43:07.92 mF7ijfowM.net
HM比でMH並みの標準実装・最適化で1.3倍の圧縮効率なんだろうし
H264比で約2倍を謳っていたH265/HEVCが、実効ではアベレージ1.6倍程度な事考えると
エンコーダがより重くなるのは確かだし、実質ライセンス料の影響が殆ど無い、個人運用の自炊エンコ用途で何処まで期待して良いものか
x265水準で作り込まれたとしは重くなりそう
上の方で有るみたいに、x264で重いプリセット使うよりはx265で軽めのプリセット使う方が軽くて縮むみたい範囲で使える範囲なら良いけどな
384:名無しさん＠編集中
18/03/30 01:03:24.41 +cp2612r0.net
逆に同じビットレートなら、x264よりx265の方が高画質になる？
その時もやっぱりx265の方が、1.4倍くらい時間かかるかな？
385:名無しさん＠編集中
18/03/30 03:44:46.29 wQ7yBQFy0.net
>>303
すまん、例のフィルタって何？
386:名無しさん＠編集中
18/03/30 03:47:04.23 wQ7yBQFy0.net
あ、>>308か
387:名無しさん＠編集中
18/03/30 06:40:08.64 jiYPersza.net
逆にってなんだよ
388:名無しさん＠編集中
18/03/30 09:56:17.54 8ShvYluz0.net
個人的にはx265から1割削れて時間5割り増しぐらいに収まれば御の字だと思って居る
389:名無しさん＠編集中
18/03/30 11:50:29.53 56xXezFGa.net
5割増なんかﾑﾘﾑﾘﾑﾘ、
390:ｶﾀﾂﾑﾘよ
391:名無しさん＠編集中
18/03/30 12:13:54.84 ns1V5Mltp.net
符号化性能うんぬんより、特許料ってそんなに重かったのね。新興のコーデックIP会社が中国、アメリカからたくさん出てきて、技術的に枯れるといいなぁー。
392:名無しさん＠編集中
18/03/30 12:19:52.31 HxLVTXPU0.net
圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
と、最近ファイル圧縮のZstandard型式ってのを知って思った
いや、ハードウェアエンコードすりゃいいってなるけどそれじゃつまんないし…
設定次第で早さか圧縮率かを上下幅広く調節できるようなのが見てみたい
393:名無しさん＠編集中
18/03/30 12:24:35.80 I+cSUfY10.net
>圧縮率はそこそこに、よりエンコード速度を早くするアプローチが合っても良い
それだと旧規格のh.264で十分ってなる
394:名無しさん＠編集中
18/03/30 14:56:53.02 5XG6WxmW0.net
2018/03/29時点のAV1エンコーダー/デコーダー(aomenc.exe/aomdec.exe)のヘルプ
URLﾘﾝｸ(pastebin.com)
395:名無しさん＠編集中
18/03/30 16:40:42.73 5XG6WxmW0.net
AV1でね・・・1920x1080の10フレームだけをi7-4702MQでエンコードしてみたんです。
全然結果が返ってこなかったのでそのまま寝て翌日確認するとそこには・・・
気になる結果は以下のリンクをクリック！
URLﾘﾝｸ(2sen.dip.jp)
-cpu-usedを0～8に変えてみたけど、
エンコード速度は0.00253～0.06101(fps)という結果に。
本領を発揮するのは -cpu-used 0 or 1 だと思うけど、
-cpu-used 0 だと、10フレームエンコードするだけで66分。
1分半のソースをエンコードしようとすると10日かかる計算になった・・・。
396:名無しさん＠編集中
18/03/30 17:45:06.52 56xXezFGa.net
非現実的すぎる処理時間に見合う価値は今のところ存在しないな
397:名無しさん＠編集中
18/03/30 18:17:44.92 lNA8QDqbd.net
スピードは結局改善しないままリリースしたんだな、HWエンコでどこまで早くなるかにもよるけどかなり厳しいだろこれ
YouTubeとか、これから新規にアップされる動画のエンコとか出来るのか？さらに既存の動画をエンコするのとか不可能に近いのでは
398:名無しさん＠編集中
18/03/30 18:26:36.87 M/tVUrz7a.net
ワロタ
何をそんなに計算しているのか
399:名無しさん＠編集中
18/03/30 18:54:53.75 B0XZfDV10.net
最適化やってないからまだ改善もクソもないよ
400:名無しさん＠編集中
18/03/30 19:17:06.49 KbyNBHD+0.net
動画エンコードは、GPUとかの超並列化の恩恵受けられないんですかね
401:名無しさん＠編集中
18/03/30 19:25:43.85 O43nmN/P0.net
>>383
ハードウェアエンコードもGPGPU（シェーダ）ではなくて動画処理専用固定回路でやってるから、
GPGPUだとやりにくいんじゃないの
402:名無しさん＠編集中
18/03/30 19:47:40.55 K8WvML30M.net
中身的にはSIMD頼みの力押しでマルチスレッド化が進んでない感じ
デコーダも同様というか、H265以上に設計レベルで再生に掛かる演算負荷軽減する気無さそう
最初っからハード屋抱き込んだアライアンスになる訳だわこりゃ
403:名無しさん＠編集中
18/03/30 19:54:46.49 /P9igK1z0.net
だから何としか
404:名無しさん＠編集中
18/03/30 22:49:19.58 m5K5pN7rH.net
x264 mediumくらい縮んでx264 mediumより速くて使用料タダ
のが欲しい
405:名無しさん＠編集中
18/03/30 23:26:32.20 Dpl0S177a.net
x264でもopenCL使えるやん
SIMD使うより速いぞ
406:名無しさん＠編集中
18/03/31 00:53:14.67 hznG5K140.net
AV1にライセンス疑惑あり
407:名無しさん＠編集中
18/03/31 00:56:57.23 It4c3/iy0.net
GPGPUの話は前スレでバトルあったのでそれ参照。
結論としては、
x264やx265の開発に実際に関わってる人の話を聞ければ信憑性高いが、
現状このスレにいる人の知識では何を信じていいのかわからんってことにww
408:名無しさん＠編集中
18/03/31 01:43:45.77 QxlbXBFG0.net
AV1のエンコってwaifu2Xくらいかかんのか…いやニューラルエンジンがある今はAV1の方が…
409:名無しさん＠編集中
18/03/31 02:03:48.32 odEcJpjT0.net
各エンコーダのプリセット毎に、VMAFスコア、SSIM、エンコード速度を計測して図にしたので置いときますね。
対象はQSVEnc(H.264)、x264、x265、VP9。速度のとこだけAV1も。
VMAFやSSIMはただの指標なので、最終的に信じるべきなのは自分の目と感覚だということを忘れずに。
VMAFスコア/ビットレート図
URLﾘﾝｸ(2sen.dip.jp)
SSIM/ビットレート図
URLﾘﾝｸ(2sen.dip.jp)
エンコード速度と設定等
URLﾘﾝｸ(2sen.dip.jp)
410:名無しさん＠編集中
18/03/31 03:56:08.25 7Lq4pL0rM.net
適したスレが無さそうなのでここで聞くけど
BRAVIAで再生する時、XAVC S 30p 100Mbpsと60p 150Mbpsってどちらが高画質だと思う？
モーションフローで30pも60p化されて再生されるとして
30pは60pの半分しかフレーム数/秒がないけど、ビットレートは2/3あるから1フレーム当たりの情報量は30pの方が33%多い
パッと見モーションフローは、かなりきれいに中割りコマ生成してる、時々破綻してるけどw
411:名無しさん＠編集中
18/03/31 06:04:46.28 gfuajWwSa.net
画質なら30のほうが良いだろうよ
24にすればもっと画質は良くなるぞ
412:名無しさん＠編集中
18/03/31 08:15:06.95 hdFdnZ7Ya.net
どこが次世代の話だよ
413:名無しさん＠編集中
18/03/31 08:20:23.08 28VsBo+5a.net
昨日今日規格が固まって普及はこれから、ってのが次世代じゃなきゃどんなのが次世代なんだ
規格が決まった瞬間あらゆるデバイスやサービスに浸透するわけじゃ無いんだぜ？
414:名無しさん＠編集中
18/03/31 08:24:17.82 28VsBo+5a.net
ああXAVCの話か
HEVCもこのスレの対象なんで仲間にいれてあげてもいいんじゃない？
415:名無しさん＠編集中
18/03/31 08:30:57.34 ZmwRNZhu0.net
>>393
解像度が書かれてないと思うけど
フルHDならHEVC, h.264ともに10Mbpsあれば十分なことを考えると
両者ともに高画質だと思う
416:名無しさん＠編集中
18/03/31 08:32:22.51 GgHgjFx90.net
HEVC専用スレの方ももうちょっと活用されてもいいのにとは思う
417:名無しさん＠編集中
18/03/31 08:50:46.11 vFJMFRqxM.net
>>393
ソースが30pかどうかにもよる
418:名無しさん＠編集中
18/03/31 10:03:57.04 70L+3RS5p.net
>>393
でも60pの方がフレーム間の差が小さいから、圧縮効率良さそうじゃない？
419:名無しさん＠編集中
18/03/31 10:18:31.32 hznG5K140.net
こんなスレで業務用途のコーデックの話なんか聴いても、まともに答えられるやつなんかほとんどいないだろ
このスレにいる奴の大半はアニメのエンコードばかりしているようなのばかりだ
420:名無しさん＠編集中
18/03/31 10:20:54.96 8ECVPH3aM.net
いきなり自己紹介されても
421:名無しさん＠編集中
18/03/31 10:30:15.52 isuj0kQw0.net
単純に考えて、100Mbpsで30pなら60pの場合は200Mbpsで同等画質じゃないのか？そんな簡単な話でもないんかね？
422:名無しさん＠編集中
18/03/31 11:13:30.34 K2NT3dmHd.net
GOP的な圧縮は画像シーケンスと違って差が小さければ圧縮効率良くなるなら60pはその分圧縮率上がるのでは？
190Mbpsになるのか150Mbpsになるかは知らんが。
423:名無しさん＠編集中
18/03/31 11:36:50.39 RvXB0Q6+0.net
30→60だとフレーム間予測が効いて、順当には必要ビットレートは増えないと思うけど
ビデオカメラのリアルタイムエンコードだと、そうでもないのかもしれない
424:名無しさん＠編集中
18/03/31 11:42:39.82 ykF7JQcmM.net
元ソースが30pとして、単に補完フレームの破綻防止に同じ画の繰り返しでもフレームレート有った方が良いのなら意義はあるのだろうけど
データ容量的に1.5倍の価値が有るかの判断は視覚評価だし、基準は当人であって他人じゃ無いしな
再生するデータの動き内容とか、そのTVの性能に依存するものだし、そもそも他人が容易に判断付くものじゃない
こんな事他人に頼る個人が生成出来るソース規模でも無いし、著作権的にアレな4Kデータとかじゃねーの？
スルーで良いと思う
425:名無しさん＠編集中
18/03/31 11:53:37.40 s8TNa5OjM.net
XAVC Sって半民生向けよね
426:名無しさん＠編集中
18/03/31 12:01:54.84 YdOGGYyO0.net
確かに30pより60pの方が差分が小さくて、処理も軽くなりGOP圧縮効率上がる
QFHD150Mbps 60pってのは、LongGOPならなかなかいい線かも？
30p 1/60シャッター、24p 1/48シャッターでパラパラ撮ってるものがほとんどで、TVのように再生側ハードで倍速や4倍速120pなんてのも普通にある現状
圧縮効率とコマ数とビットレートと3つの相関を知り尽くしてる人なんて、メーカー技術者の上位数人くらいか
427:名無しさん＠編集中
18/03/31 12:11:37.95 jy+pD5jF0.net
>>393
正直コーデック関係ないし、モノによる。
カメラスレかHTPCあたりで聞いた上で自分の目で判断すればいいんじゃないの。
【4K30P】ビデオカメラに60Pは必要か？【FHD60P】
ｽﾚﾘﾝｸ(vcamera板)
【HTPC】動画を高画質に再生しよう Part10
ｽﾚﾘﾝｸ(software板)
428:名無しさん＠編集中
18/03/31 12:30:19.71 70L+3RS5p.net
>>408
半というか完全に民生向けじゃないの？
でも4K 60p 150Mbps で撮影できるカメラって民生用であったっけ？
ハンディカムやαシリーズでも4K 30p 100Mbpsまでしか対応してなかったような
429:名無しさん＠編集中
18/03/31 17:15:06.54 YdOGGYyO0.net
>>411
そう民生向けだけど、FDR-AX1だとXAVC SでQFHD 60p 150Mbps XQDに撮れるから、この構成や性能は業務機
URLﾘﾝｸ(www.sony.jp)
430:名無しさん＠編集中
18/04/02 17:13:28.56 oPPos9Iy0.net
AV1 Is Finally Here, but Intellectual Property Questions Remain
URLﾘﾝｸ(www.streamingmedia.com)
> According to the AOM representatives, at NAB several members will show
> 30-40% better quality for UHD 4K videos than VP9/HEVC.
> Encoding times are currently about 100X slower than VP9, which they feel will drop to 5X by the end of the year.
> For decode, AOM is currently about 5X slower then VP9 on the x86 platform,
> which should drop to 2X by the end of 2018.
・AV1ではUHD 4Kの品質(圧縮効率)がVP9/HEVCと比べて30-40%向上する。
・エンコード速度は現状ではVP9の100倍遅いが、2018年末には5倍くらいにまで下がると思われる。
・デコード速度はx86環境だとVP9の5倍遅いくらいだが、こちらも2018年末には2倍程度に下がると思われる。
その他、特許面の話なども含む良記事。
431:名無しさん＠編集中
18/04/02 17:13:37.45 9gr2nxn90.net
4KをQFHDと呼ぶのが主流なの？
それはさておき、そもそも補完される画は完璧じゃない(当然破綻もある)から、それ考えると60pの方がいいとは思う。
破綻しないような簡単な映
432:像なら30pも60pも差は出ないだろうし。複雑で破綻するような映像ならば60p一択だろ。 蛇足だが、フレーム補完は無視して、フレームレートは30pでいいというなら、単純に考えて画質は30pの方がいい。
433:名無しさん＠編集中
18/04/02 17:21:35.97 ZeLxJCDAa.net
VP9の100倍ワロタ
434:名無しさん＠編集中
18/04/02 18:47:58.74 osbzaKkp0.net
100by遅い→使いものにならないと自白
年末まで待て。それでもかったるい結果が予想される
435:名無しさん＠編集中
18/04/02 18:54:52.32 Sc8XCrCD0.net
x265もリリースしたての時は全然速度出なかったろ
いきなり最適化されたものが出てくるわけない
436:名無しさん＠編集中
18/04/02 19:16:00.41 1iHpNus20.net
ハードエンコの有無っぽい数字だな
VP9はある程度立ち上がって
誰でも効果を確認出来るし…
決まったかな？
437:名無しさん＠編集中
18/04/02 21:10:47.61 ggAtiSao0.net
30%程度の効率改善程度では、コーデックを切り替えるほどの意味はない
せめて平均で50%の改善がないとな
438:名無しさん＠編集中
18/04/02 21:56:53.59 oPPos9Iy0.net
>>413の記事から更に抜粋。
> According our conversations, AOM expects AV1 decode in several browsers
> and some content from member companies over the next few months.
> This will be followed by hardware implementations in about 12 months
> that can be integrated into devices that will ship in early to mid-2020.
>
> Given the AOM membership, AV1's success in the streaming marketplace seems almost assured,
> particularly given that HEVC has made little progress to date in markets other than streaming to Smart TVs.
数か月以内に複数のブラウザでAV1のデコードがサポートされ、対応コンテンツが出てくることが期待される。
その後約12か月でHW実装され2020年半ばまでには製品が登場するだろう。
HEVCは(主にクソライセンスのせいで)ストリーミング市場ではスマートTVへの配信に使われてる程度で
それ以外はプゲラッチョだし、AOMの参加メンツは豪華すぎてやべーので、
AV1のストリーミング市場での成功は約束されたようなものだ。
439:名無しさん＠編集中
18/04/02 22:05:12.36 ggAtiSao0.net
UHD-BDだけならともかく、放送にも採用されたHEVCをプゲラッチョとか、頭悪いにもほどがある
440:名無しさん＠編集中
18/04/02 22:29:51.94 oPPos9Iy0.net
いや、ストリーミング市場限定の話として書いてあることくらいわかるだろ・・・
441:名無しさん＠編集中
18/04/02 23:09:39.49 EF/PBVqKM.net
記事の紹介や和訳には感謝だけど、個人の主観混ぜ込むのは誘導にも似た効果も含むから控えた方が良いと思う
442:名無しさん＠編集中
18/04/02 23:26:26.38 w08Zt+n5a.net
結局、延々と264が続くことになる
まで読んだ
443:名無しさん＠編集中
18/04/02 23:31:33.78 /LEGdCOu0.net
そもそも、ライセンス料払いたくないストリーミング業者向け作った規格だから
444:名無しさん＠編集中
18/04/02 23:36:23.24 oPPos9Iy0.net
>>423
原文は示してあるし特に主観ってわけでもないんだけど、ややふざけすぎた感はあるので気を付けます。
445:名無しさん＠編集中
18/04/02 23:57:19.16 osbzaKkp0.net
>>426
気にすんな。全然OK。このくらい�
446:ｪむしろ好ましい 細かいことに突っ込んでくる神経質なやつは必ずいるものだからな
447:名無しさん＠編集中
18/04/03 00:25:03.29 72Pkn5C60.net
VP9で充分やん
448:名無しさん＠編集中
18/04/03 00:37:22.30 2F/e5DdnM.net
個人運用の範囲じゃライセンス問題の影響極小だし
コンテンツ提供側は金儲けに直結してる分ライセンス料取られるから必死だけどね
HEVCはコンテンツ当たりにのライセンスフィーはディスク1枚当たり$0.0225、データで1タイトル当たりなら更に半額で、ストリーム配信なら無料
ハードウェアもライセンスが一番高い4Kテレビで1台で$2以下、モバイル端末は$1しない
安価なセットトッブボックスで価格の～1.6%程度
大抵は対応プロファイルの範囲が限られるのでもっと安くなる
消費者の立場として、コンテンツの消費に掛かる額は数円とか、再生機器でも4Kテレビや高価な機器でも2百数十円で、消費意欲を左右するレベルじゃ無い
代理店や問屋の流通での中抜きの方が遙かに影響が大きい
扱い量が大きい事業者側はそれなりに纏まった額になるから、払わないで済むなら払いたくないから、単価の具体額示さず「ライセンスガー」と後押しを求める方向の風潮を作りたがる
事業者は最低$25000/年取られるが、$4000万/年の支払額上限もあるうえ
更に多くの場合は現地の源泉税の控除分が適応した分の実質支払いで済んでたりもする
449:名無しさん＠編集中
18/04/03 00:53:24.91 +IqN0nMh0.net
でも、そもそもパテントのことをぎゃーぎゃいうなら最初からvp9でよくね?仕切り直して新しいコーデック作りゃなんとかなると思ってんのか。googleは孤軍奮闘で今まで頑張ってたが。他の配信企業なんなんよ。
450:名無しさん＠編集中
18/04/03 01:22:44.42 vkTvpMzh0.net
VP9は悪くはないが4K8K時代に使うには圧縮効率が物足りないし、
Googleが孤軍奮闘してるだけじゃ普及も進まないからアライアンス組んで新規開発したんだと思うけど。
451:名無しさん＠編集中
18/04/03 01:32:14.06 gUqfHQrn0.net
4K8K放送のcodecって決まってるんだっけ？
今年12月だからあと8ヶ月か
452:名無しさん＠編集中
18/04/03 03:44:39.98 Ausww4X10.net
>>432
放送ならHEVCに決まってる
453:名無しさん＠編集中
18/04/03 03:46:14.32 ryppP+Nj0.net
あと8ヶ月で決まってないとかありえないだろｗ
454:名無しさん＠編集中
18/04/03 06:19:37.35 D/KfabLY0.net
Software Infrastructure Global Viewpoint – March 2018
Assessing HEVC Versus AV1: Round 1
URLﾘﾝｸ(www.thebroadcastbridge.com)
455:名無しさん＠編集中
18/04/03 09:03:12.78 L7yuzpKm0.net
Netflixとかはやっぱオリジナルコンテンツだけでも全部4kで配信したい！って考えてるんじゃないかな、そうなるとVP9やHEVCでは足りないのかもね。日本の平均ネット速度は17Mbpsらしいけど世界平均は6Mbpsらしいし
456:名無しさん＠編集中
18/04/03 09:19:42.50 j00SyjWW0.net
>>430
ネットを主軸に活動してる主要企業が集まることのほうが重要なんでは
457:名無しさん＠編集中
18/04/03 09:26:18.94 WshddpOhM.net
放送波のTSを4:2:0の無圧縮720p化したものをソースにして、AV1のサンプルエンコーダ（自前ビルド）とx265
458:比較してみたが VBR 2Mbps（ピーク4Mbps）でエンコした結果でSSIMの差がどれほどになるか拾ったらこんな感じになった AV1 VBR 2Mbps 2pass SSIM : 0.994955 x265 VBR 2Mbps 2pass medium SSIM : 0.995126 x265 VBR 2Mbps 1pass medium SSIM : 0.994888 x265 VBR 2Mbps 2pass fast SSIM : 0.993843 今のところAV1の2passはx265 mediumプリセットの1passと2passの中間の品質にしかならんかった（あくまでSSIM基準でだけど ただしエンコーダのソース読んでる訳じゃないので、もしかすると画質のわりにSSIMが下がりやすくなる視覚的圧縮みたいなものが有効になっている可能性があるのと VBRでの比較なんでビットレート配分のロジック出来とか、方式的にHEVC同様ブロック配置の決定ロジックとかの作り込み具合にも大きく左右されたりもするんで あくまで現状でのサンプルエンコーダでの参考値として留意しておいて欲しい やっぱx265が変態過ぎるんだな
459:名無しさん＠編集中
18/04/03 09:52:27.94 WshddpOhM.net
まぁそれでもUltraFast～FastプリセットよりSSIMが上にはなってることは確かだから、素のHEVCだけよりは高画質なのは確かなんだろうけどね
x265相手でコレなら、x264にすらオプション巧く使われたら追いつかれるかもしれない
OpenSourceのプロジェクト化されて、x264やx265の開発やってる連中がソフトエンコーダ開発に参画してくれば化けるかもだけど、x265でも手が回ってない部分も有るし難しいかなぁ
460:名無しさん＠編集中
18/04/03 11:01:39.67 hboypAjzM.net
>>437
ネット主軸の事業者は、貧乏なところが多いし、事業自体が短命に終わっているケースが多いから、数を集めることに意味はない
461:名無しさん＠編集中
18/04/03 12:25:45.97 j00SyjWW0.net
>>440
Google, NetFlix, Amazonが貧乏で短命とな
462:名無しさん＠編集中
18/04/03 13:15:40.31 uy28RzoC0.net
日本語の読解力なんとかしなよ…
463:名無しさん＠編集中
18/04/03 13:43:01.90 RUFJesKM0.net
主要の2文字を見ていないとすれば話は通る
464:名無しさん＠編集中
18/04/03 14:00:17.99 5gh3/G+j0.net
まあ意味の取り違えとかには気を付けるとして．．．
H.265/HEVC特許暗黒時代 - Qiita
URLﾘﾝｸ(qiita.com)
Twitterによると、FAQとかが更新されたそうだ。
・・・そして３月頭にTechnicolorがInterDigitalっていうパテントトロールっぽいところに
特許を売り飛ばしたそうで、HEVCの特許問題の状況は更に悪化したそうだ・・・。
Technicolor Agrees to Sell to InterDigital its Patent Licensing Business | Technicolor
URLﾘﾝｸ(www.technicolor.com)
【トロール動向ウォッチ】 トップ11社提訴件数推移｜知財情報｜日本技術貿易株式会社
URLﾘﾝｸ(www.ngb.co.jp)
開発企業が特許で利益を得ようとするのは当然のことで仕方ないとは思うんだけど、なんともなあ・・・。
465:名無しさん＠編集中
18/04/03 14:26:17.23 wCoYoMR7d.net
売って開発企業が利益を上げたところでトロールだけ制裁加えれば問題無い
466:名無しさん＠編集中
18/04/03 18:43:38.38 mSfnhtwEM.net
トロールなんかに金払う必要ないわ
とっくに消尽されてる特許に値札なんかつかない
467:名無しさん＠編集中
18/04/03 20:37:18.45 OgIkUsW5M.net
パテントの一次受けが決まっているんだから、それを飛び越してライセンシーに請求しても、HEVC Advanceと契約してパテント料支払っているんだから、HEVC Advanceに請求しろとなる
トロールの連中が勝手に関連特許のライセンス�
468:変えても、それを監視して対応するのはHEVC Advanceだからな ライセンサーのHEVC Advanceには請求通るかもだが、関連特許保有者がHEVCライセンシーへの直接請求を通すのは難しい
469:名無しさん＠編集中
18/04/03 20:53:07.75 g84DrQPB0.net
>>438
激遅な上に画質も大したことない
完全な死に規格だな…
470:名無しさん＠編集中
18/04/03 21:09:08.35 GqRPacca0.net
早漏かよ
471:名無しさん＠編集中
18/04/04 13:55:49.56 axCfnGfR00404.net
HEVC Advance、更に新規ライセンサー、ライセンシーを加え、その推進力を強調
URLﾘﾝｸ(kyodonewsprwire.jp)
一部抜粋
> 独立系ライセンス アドミニストレータであるHEVC Advanceは、増大するライセンサー及びライセンシーリストに
> さらに新規企業が加わったことを発表した。AcTi、EverFocus Electronics、Fraunhofer、GoPro、日立工機、
> Humax、KAIST、Korean Aerospace University、Korean Broadcast System、TechniSat、
> Telestar及びWestern Digital社が含まれている。この発表は、HEVC Advanceの最近の決定である、
> インターネットストリーミング、ケーブル、無線通信放送や衛星を介した、非物理的HEVCコンテンツ配信に対して
> ライセンス及び実施料の徴取を行わないという同社の決定に対する市場からの好意的な反応の中行われた。
472:名無しさん＠編集中
18/04/04 18:38:12.46 y23XsAPx00404.net
え？ HEVC>VP9だろ？
世代的にもVP9の方が一つ遅いって認識なんだが…
VP9→HEVC→AV1なのでは…
473:名無しさん＠編集中
18/04/04 20:49:00.02 GGoNjvcpM0404.net
早い遅いはコードの差も有るから、コーデック自体の比較では何とも言えないでは？
画質容量比的なものなら、H264＜VP9≦HEVC≦AV1 ぐらいで、あとはエンコーダ実装次第で前後するだろうけど
474:名無しさん＠編集中
18/04/05 00:36:47.46 E/6Z4gwq0.net
>>378ですが、現在のffmpegのlibaom-av1は、-tile-columnsに未対応だったので、
それが使えるaomenc.exeも使って測りなおしました。
ソース： 1920x1080 10フレームだけ。-cpu-used毎に計測。
●自ビルドしたaomenc.exe で --tile-columns=3 をつけてタイル分割エンコードした場合
エンコーダ： aomenc.exe-20180401-0.1.0-9011-g0ec805145
結果： 0.0054～0.1046fps
URLﾘﾝｸ(2sen.dip.jp)
●自ビルドしたffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180403-N-90590-g197a4e8fee (libaom 0.1.0-9028-geeda6d2de)
結果： 0.0029～0.0597fps
URLﾘﾝｸ(2sen.dip.jp)
●Zeranoe ffmpegでエンコードした場合 （現時点では-tile-columns指定不可）
エンコーダ： ffmpeg x64 20180402-N-90578-g02ae52db87 (libaom 0.1.0-9012-ge83c6624f)
結果： 0.0004～0.0275fps
URLﾘﾝｸ(2sen.dip.jp)
475:名無しさん＠編集中
18/04/05 00:39:31.08 E/6Z4gwq0.net
>>453まとめ
●--tile-columns=3をつけることでエンコード速度は2倍くらいになる。
ただ、無しの場合に12%程度だったCPU使用率が100%くらいになるのに2倍程度にしかならないとも言える。
●Zeranoe版ffmpegのエンコード速度がやけに遅い。MABSで57.5分だったのがZeranoeだと378.2分。
libaomのビルドをミスってる可能性があるので連絡済み。反応待ち。
ちなみに自ビルドにはmedia-autobuild_suiteを利用。
ffmpegは--enable-libvmafにしたので自動的に--disable-w32threadsに。
jb-alvarado/media-autobuild_suite
URLﾘﾝｸ(github.com)
実行して質問に答えるだけでMSYS2/MINGW-w64/GCCのビルド環境を構築して、
最新のffmpeg/aomenc/x264/x265などを自動ビルドしてくれるのでありがたい。
L-SMASH（-Works）の自ビルドにも流用できる。
476:名無しさん＠編集中
18/04/05 01:56:11.81 VVbezlj2M.net
再度の検証お疲れ様
気になる点
何で一般的なGOP長に満たないフレーム数を使用しているのか
一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
あと、SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
477:名無しさん＠編集中
18/04/05 02:52:00.40 E/6Z4gwq0.net
>>455
> 何で一般的なGOP長に満たないフレーム数を使用しているのか。
> 一般での長めなGOP長の数倍（例えば300の数倍）分フレームは用意しないと、コーデックの評価は難しいのでは？
そうなんだけど、見てわかるとおり、今のAV1エンコードは死ぬほど時間がかかるから。
とりあえずFHDのエンコード時間の目安を知りたかったというのが今回の一番の目的。
VMAFやSSIM等はついでに測っただけ。
次は長めのサンプルも試したいが・・・時間かかるのを覚悟でFHDに挑むべきか、妥協して解像度を下げるべきか・・・。
> SSIMのどれか1つ拾うにしても、ALL拾わずY成分だけ拾う意味が解らない
x264やx265の--ssimで出力されるのが SSIM Mean Y なのでなんとなく。Allを拾った方がいいかな？
478:名無しさん＠編集中
18/04/05 03:59:11.36 sX2SJznGM.net
>>456
ffmpegでSSIM拾うとか
479:名無しさん＠編集中
18/04/05 15:58:43.97 ACap5gLC0.net
適当なスレというか板がないのでお知らせ程度に
・ロスレス圧縮技術MPEG-4ALSを用いたコンサートホール演奏の
ハイレゾライブ配信サービス商用化に向けた説明会について
URLﾘﾝｸ(ottava.jp)
HEVCと同じく次世代放送にて採用決定済みのMPEG-4 ALSを使ったライブ配信に関する話題
480:名無しさん＠編集中
18/04/05 16:37:44.71 QNV9ilhrM.net
場所が無いにしても、不可逆それも画質容量比と効率が主題の次世代ビデオコーデックのスレでも板違い
情報提供で投下スレ無いならニュース行きか、ピュアAUかAV機器で捨てスレ起こせ
481:名無しさん＠編集中
18/04/05 16:57:34.66 9t7ueEo80.net
ハイフレームレート4Kライブ伝送を実現するHEVCコーデック。NTTが開発
URLﾘﾝｸ(av.watch.impress.co.jp)
>>457
ffmpegでやってるよ。
>>453補足
aomenc.exeの設定はffmpegとあわせたつもりだったんだけど、aomenc.exeで--tile-colunmnsを外してみたら
自ビルドffmpegの1.5倍くらいの時間がかかったので、何か見逃してる設定があるのかもしれない。
482:名無しさん＠編集中
18/04/06 00:35:49.06 By9McdF70.net
URLﾘﾝｸ(developer.nvidia.com)
What's New in Video Codec SDK 8.1
・Completely re-designed modular sample applications for easier integration into target applications
・New feature enabling the use of B-frames as reference frames to improve overall encoding quality for H.264
・Added support for real-time HEVC 4K@60fps with recommended drivers
・New API to specify region-of-interest for applications having prior knowledge of video frame.
This feature works well in conjunction with image area classification feature (part of Capture SDK 7.0)
483:名無しさん＠編集中
18/04/06 02:50:12.05 FCIj/N0QM.net
>>461 ビデオコーデックSDK 8.1の新機能 完全に再設計されたモジュール式サンプルアプリケーションにより、対象アプリケーションへの実装が容易になりました H.264のエンコード品質を全体的に向上させる新機能として、Bフレームを参照フレームとして使用できる様になりました （効果としてフレームの差分データ量がより節約出来るので、画質容量比が向上すると思われる） 推奨ドライバでリアルタイムHEVC 4K@60fpsのサポートが追加されました アプリケーションから、先行取得されたビデオフレームにおいてマクロブロックに品質指定を行う新しいAPIを実装しました この機能はイメージ領域の分類機能（Capture SDK 7.0の一部）と連携して使用出来ます （マクロブロック単位の可変品質エンコードを可能にする実装っぽい、手間が増えるがCBRやVBR、固定品質で画質容量比の改善が望める）
485:名無しさん＠編集中
18/04/06 02:57:02.11 +HIdoxMtM.net
最後については、手法的には前からある（x264とかには既に有る）実装
AV1対応の過程でAV1の標準エンコーダに有る機能で既存コーデックに使える機能は、出来た分は先に出したよ感がｗ
486:名無しさん＠編集中
18/04/06 03:08:35.18 f7T0X8b4M.net
Bフレームの参照の方は、Bフレームが続く場合にPフレームからの差分では無くBフレームからの差分参照出来る様になるんで、動きが少ないとか、ブロック単位でズレるだけみたいな場面でより縮む様になる
Bフレーム使う話なんで、Bフレームが使えないNVEncのHEVCには関係無し（ぉ
487:名無しさん＠編集中
18/04/06 10:05:41.45 cVa47tLH0.net
このSDKを使うのはNLEやエンコーダ各社？
NVEncはBフレーム使えないのは、このSDK過去版が使えなかったからではなくて？
>>464
488:名無しさん＠編集中
18/04/06 10:56:17.84 F4bKu/VH0.net
>>465
NVEncではH264なら元からBフレームも使えていて
HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる（それでも当社比でH264より縮むんだけどね）
NVEncのHEVCでBフレームも有効になっていたら、SDKとしてデカいトピックすぎて書かない訳がないぐらいのネタだし、関連設定に関わる資料が追加されてるはず
489:名無しさん＠編集中
18/04/06 11:50:55.91 YeX5u0A00.net
>>463
> 最後については、手法的には前からある（x264とかには既に有る）実装
AV1のROI Mapや今回のNVEncのEmphasis Mapはフレーム内の領域を直接指定して
そこの品質を調整する機能だと理解してるのだけど、x264にそれに該当する機能ってあるっけ？
--zonesや--cqmとは違うし、それ以外にそれっぽい機能が見当たらない気が。
あとドキュメント読んだら、Emphasis Mapはレート制御後にターゲット領域の品質調整を行うから
VBV違反のリスクがあるって書いてあった。
>>466
> HEVCだとマクロブロック捜査の方に手間食われて低レイテンシ維持出来ないから、
> HEVC対応したNVEnc積んだGefoce出た時からずっとBフレーム無しで、それが仕様とされてきてる
その説明ってどこでされてたんだろ？情報源あれば教えてほしい。
遅延が問題なら低遅延が求められる時だけBフレームを切ればいいだけだと思うんだけど・・・。
2015年のロードマップだとHEVCのBフレーム対応も予定されてたみたいだけどどうなったんだろね。
URLﾘﾝｸ(nico-lab.net)
490:名無しさん＠編集中
18/04/06 11:58:40.99 0hBfnBa7M.net
要するにハードウェア的にはBフレームに対応してるんだけど、それを動かすソフトウェアの開発部隊がカスしかいなかったんだろ
で、やっとまともに扱える奴が入ってきたから、まずH.264で使えるようにしたと
この流れならばいず
491:れHEVCもやるでしょ あとは画質次第 いくらオプション対応しても画質が伴わなければ意味はないから もっとも、NVIDIAを語れるような目利きがいた試しはないが
492:名無しさん＠編集中
18/04/06 12:00:24.43 0hBfnBa7M.net
最後、「NVIDIAに画質を語れるような目利きがいた試しはないが」に訂正
493:名無しさん＠編集中
18/04/06 12:08:20.30 hl9eRboSM.net
>>466
勉強になった、ありがとう
494:名無しさん＠編集中
18/04/06 12:10:20.58 YeX5u0A00.net
>>468
>>466も言ってるけど、NVEncではH.264なら元からBフレーム自体は使えていたよ。
HEVCの場合だけ「最大Bフレーム数はゼロだよー」と返してくるので使えなかったというだけのはず。
今回のSDK8.1での変更は、「（H.264で）Bフレームを参照フレームとして扱えるようになった」というもの。
H.264ではBフレームは元から使えてたけど、更に機能追加したよという話。
495:名無しさん＠編集中
18/04/06 12:13:53.13 lHWnPzdj0.net
>>464
Bフレームを参照フレームとしてというのはいわゆるb-pyramidのことでは
>>467
（下段について）
たぶんASICとかの作りこみを省いてるんだと思う
機能的には充実してるAMDより断然早かったし
h.264対応済みハードをできる限りいじらずに実装したのが今のNVEncだと思う
496:名無しさん＠編集中
18/04/06 12:55:24.08 YeX5u0A00.net
>>472
> 機能的には充実してるAMD
AMDのVCEEnc(AMF)は
・HEVC main10に非対応 (QSVとNVEncは対応済み)
・Polarisでは何故かH.264でもBフレームが使えなくなった
・QSVスレで行ったSSIM/ビットレート図による比較では最下位
ｽﾚﾘﾝｸ(avi板:335番)
と、一番酷い状態のような・・・。
>>122で書いたようにVP9のHWデコードも迷走してたし、大丈夫なんだろうかって感じがする。
RavenRidgeはちゃんとVP9のDXVAデコードができるらしいけど。
497:名無しさん＠編集中
18/04/06 12:56:37.93 0hBfnBa7M.net
>>471
だからそれ、ソフトウェア開発部隊が使えるはずの機能を使えない状態にして放置してたからだろ
結局、カスであったことに変わりはない
498:名無しさん＠編集中
18/04/06 13:00:24.52 YeX5u0A00.net
>>474
勘違いしてたっぽいから指摘しただけ。
499:名無しさん＠編集中
18/04/06 13:19:52.27 0hBfnBa7M.net
おまえがな
500:名無しさん＠編集中
18/04/06 14:56:30.70 lHWnPzdj0.net
>>473
だから「機能的には」って「には」を付けたんだな
501:名無しさん＠編集中
18/04/06 15:11:30.34 YeX5u0A00.net
>>477
なるほど。（ただ、エンコード機能的に何か充実してるんだっけ？という素朴な疑問はある。エンコード以外の機能込み？）
502:名無しさん＠編集中
18/04/06 16:17:19.62 lHWnPzdj0.net
>>478
2Pass（おそらく先読み）によるレート制御とかBフレーム使える（Polarisでは無効化されてる？）とか機能的には充実してると言ってもいいのでは
それらを実装してるから高画質とは限らないだけで・・
ま、EU（GPUコア）使って柔軟に進化してるQSVは別格として
nvidia、AMDともにゲームの配信とかゲーム画面のキャプチャ向けの高ビットレート録画って割り切ってる感はある
503:名無しさん＠編集中
18/04/07 12:04:04.25 ZS0HPDpc0.net
ｽﾚﾘﾝｸ(software板:568番)-571
Zeranoe版ffmpegでlibaomのビルドミスがあったので、
AV1の検証をするなら20180405-e54679b以降のバージョンか、自ビルドのffmpegやaomenc.exeで。
libaomの方も頻繁に更新されてて、原因はよくわからないけど同じ設定で前より遅くなったりもしてる。
aom 0.1.0-9082-gab1e1db19のaomenc.exeでクラッシュするケースもあったし、安定するのはまだまだ先かな。
504:名無しさん＠編集中
18/04/10 13:29:00.05 mvAZrsZe0.net
xiphmont | next generation video: Introducing AV1, part1: Chroma from Luma
505: https://xiphmont.dreamwidth.org/91643.html next generation video: Introducing AV1 https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml
506:名無しさん＠編集中
18/04/11 16:49:17.77 VM1ZiLn00.net
facebookの人（？）によるAV1、x264、libvpx-vp9の比較
AV1 beats x264 and libvpx-vp9 in practical use case
URLﾘﾝｸ(code.facebook.com)
507:名無しさん＠編集中
18/04/11 16:56:10.44 7cYhFyubM.net
>>482
画質は上々そうやね
x264のデフォルトの1万倍近く遅いみたいに見えるけど。
英語はよく分からないので100倍であって欲しい。
508:名無しさん＠編集中
18/04/11 17:53:39.39 eo9l3iNh0.net
>>483
x264のデフォルト(--preset medium)ではなく、--preset veryslowと比較して、
AV1は品質指定モードで平均5869.9倍、ビットレート指定モードで平均8139.2倍のエンコード時間だね。
ただし、
●テスト環境のスペックが書かれていない。
●x264はスレッドを活用してるけど、AV1は --tile-columns 0 なので
タイル分割エンコーディングを行っておらず、スレッドをほぼ活用できていない。
●当然ながらAV1のリファレンスエンコーダであるaomencはまだ最適化もされてない。
といった点には留意する必要があるかな。
VP9の方も同じ --tile-columns 0 でやってるので、品質指定モードでVP9の658.5倍、
ビットレート指定モードでVP9の667.1倍のエンコード時間という方が目安としてはいいかも。
まあ普段自分でVP9エンコードしてる人ってほぼいないだろうからわかりにくいけど・・・。
509:名無しさん＠編集中
18/04/11 18:01:26.52 7cYhFyubM.net
>>484
veryslowと比較してなのか…スレッド数で1桁速度が変わったとして現状x264 midiumとの比較で2000倍程度速度差があるという認識でいいのかな
x264やx265は発表から数年で速度はもとより画質も素晴らしく伸びたように思うので少なくとも今年の終わりまで気絶してから評価した方が良さそうですね
510:名無しさん＠編集中
18/04/11 18:10:29.71 OUJRzihv0.net
AOMのソースのところに書いてあるのと同じサンプルだね
URLﾘﾝｸ(media.xiph.org)
解像度は各種あるけど、ニュース番組並に情報量低いのばっかりで、マクロブロックサイズのサイズデカいコーデックがそりゃ縮むわなという感じのばっかりなんだよな
x265との比較しないのが謎だし、AOMの中の人なんじゃないかと思ってしまう
511:名無しさん＠編集中
18/04/11 19:07:34.65 eo9l3iNh0.net
>>486
記事をちゃんと読んだ方がいいよ。
>>482のFacebookの実験ではderfのサンプル群は使っていない。
Facebookでよく見られてるトップ400のビデオを使っていて、
それらに関する説明（スマホで撮影したSD/HDが多いとか）も書いてる。
x265との比較が無いのは俺も残念。なんでだろね。
HEVCのライセンス料って、調査研究目的であっても請求されたりするもんなんだっけ？
あとFacebookはAOMのFounding memberだよ。
x264も0.148-snapshot-20161114-2245って書いてるけど日付からするとr2727かな。
ちょっと古いけど、まあこれはあまり影響なさそうか。
snapshotの末尾の数字ってずっと前から2245みたいだけど、何を表してるんだろ。
512:名無しさん＠編集中
18/04/11 19:40:14.73 jzIik2pxM.net
8000倍とかw
513:名無しさん＠編集中
18/04/11 21:53:41.24 oBNaTspA0.net
エンコードにH.264の10000倍かかったとしてもエンコした動画を1回しか見ないような俺らに対して
1回エンコするだけで100万再生スタートという次元の配信業者からすれば
俺らより環境にもネットの帯域にも優しい�
514:ｨ釣りが出るほどのリターンがあるということ
515:名無しさん＠編集中
18/04/12 09:11:54.62 q5iqQV/z0.net
>>489
意味が分からない。10000倍では釣り合いが取れないだろ
ネット帯域が主要命題だったのは10年～20年前だし
516:名無しさん＠編集中
18/04/12 10:13:17.37 VfB7DrWl0.net
x264やx265みたいな魔改造エンコーダがまだ無いからな
対応ハード出るまで1年有るし、配信事業者側が使い始めるのも2年は先だろう
nvidiaがNVEncとCUDAの連携追加し始めていてAV1にも使えそうな実装をSDKでして来てるし
AV1の方がHEVCより物量的処理での圧縮してるから、NVEnc+CUDAの実装で何かしら出してくるかもな
有る程度纏まった形にしてるのはDGX-2みたいなTeslaを使ったコンポーネントとセットで事業者用
GeforceとかはNVEncのみでは最小限で、あとはSDK使って手前らで巧く纏めなさいよとかだろうなぁ
517:名無しさん＠編集中
18/04/12 10:45:25.96 WANQhGIfM.net
NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような画質水準には達していない）しか作れないみたいだから、アテにならんと思うがねぇ
518:名無しさん＠編集中
18/04/12 12:08:55.54 L/MKuORZM.net
NETFLIXなど大手の配信業者も多く絡んでるし可能な限りハードウェア処理し易い設計になってる可能性はまたあるとは思う
519:名無しさん＠編集中
18/04/12 12:54:15.28 VfB7DrWl0.net
>>492
リアルタイム配信向けの実装なだけでしょ
短時間に出来る範囲でしかやっていない
同様の事をQSVでやらせると、H264でしか出来ないうえ、NVEncのH264より汚いって知ってた？
520:名無しさん＠編集中
18/04/12 13:09:36.05 SxbRi3C8M.net
>>494
そんな話していないし、したいとも思わん
521:名無しさん＠編集中
18/04/12 13:20:02.82 VfB7DrWl0.net
NVEnc自体は、nvidiaのGRIDみたいなクラウドや、LAN内でのゲームのリモート操作のためのもので
それ自体はH264なりHEVCだから、GPUのバッファから生成する以外にも、デコーダからGPUに映像与えてやれば、任意の映像データもトランスコードしてファイルとして保存できるってだけ
ただ要望もあるから、あとからSDK7.x世代以降にCUDA使ってGPGPU的に拡張出来る様になってる
もちろんSDKでのAPI実装やサンプルに頼らず独自でやっても良いんだけど
CUDAエンコーダの頃から独自に拡張する人が殆ど現れない
エンコーダの拡張自体が糞難易度高くて、数学者的な人が実装サンプルや設計組んで、コーディングに特化した連中が最適化を進めるパターンが多い
そういう方々は既にx264やx265の方に集中しちまってる
522:名無しさん＠編集中
18/04/12 14:05:52.16 ZcyNWyhH0.net
>>489
趣旨はともかく、さすがに10000倍のままってことはないでしょｗ
>>490
>ネット帯域が主要命題だったのは10年～20年前だし
そんなことないよ。流れるデータ量も激増してるし、世界にはまだまだ帯域不足のところもあるし、
配信業者にとってデータ量の削減は今も昔も極めて重要な課題。
523:名無しさん＠編集中
18/04/12 14:19:48.64 ZcyNWyhH0.net
>>492
> NVIDIAのエンコーダーって、とりあえず実装しましたレベル（この板の住人が求めているような
> 画質水準には達していない）しか作れないみたいだから
それを言うなら
・GPUのHWエンコーダはどれも高圧縮/高画質を求める人には向いていない（特に実写等）
・QSVとNVEncは圧縮/画質面では同程度(QSVの方がやや上？)。
エンコード速度はNVEncが圧倒。
・AMFはQSVやNVEncと比較すると一段下のレベル。
AMDのエンコード/デコード機能の出遅れはちょっと心配になるレベルでもある・・・。
という感じだと思うけどな。（根拠は>>473
524:とか） IntelもNVIDIAもAOMのFounding Memberだし、それなりに期待はできると思う。 AMDはPromotor Memberだけど、エンコード/デコード部門は頑張れるのだろうか・・・。
525:名無しさん＠編集中
18/04/12 15:01:48.50 O/DjZzsid.net
画質重視でもYoutubeに上げる為にロスレスで圧縮するときはNVEnc使ってる
526:名無しさん＠編集中
18/04/12 15:19:04.50 ZcyNWyhH0.net
NVEncのロスレスって4:4:4だと聞いたけど、Youtubeはそれも受け付けてくれるのか。
なんとなく弾かれるもんだと思ってた。
527:名無しさん＠編集中
18/04/12 15:34:47.41 n+ScPlN90.net
そういえばx265のCUSA版があったな
URLﾘﾝｸ(bitbucket.org)
長いこと更新されてないみたいだから
非主流アーキテクチャ向けの設計は広がらないみたいね
528:名無しさん＠編集中
18/04/12 15:52:32.56 ZcyNWyhH0.net
H.265の v5 (Approved in 2018-02-13) の規格書が発行された。
現時点ではダウンロードできるのはTIES userのみ。
H.265?:?High efficiency video coding
URLﾘﾝｸ(www.itu.int)
529:名無しさん＠編集中
18/04/12 16:24:41.39 PMHfI71Jd.net
詳しくは知らないというか知る由もないんだけど、NetflixとかYoutube（Google）みたいな資本力のあるところでもHWエンコしてるのか？ああいうところって一般人じゃ到底手に入らないようなスペックのコンピューターでSWエンコしてると思ってたんだが
530:名無しさん＠編集中
18/04/12 19:00:41.89 VfB7DrWl0.net
>>501
全てがGPGPUでCPUより効率良く処理出来る訳じゃない
x264やx265が高画質化するため手法の極一部だけなんで
大半を処理するCPUが結局ボトルネックになる
それでも僅かにCPUの負担が減るから、その分は微妙に早くはなるけど何割も早くはならない
531:名無しさん＠編集中
18/04/12 22:23:26.00 pGR5LOdp0.net
>>503
ああいう規模だからこそ逆に専用のASICボードとか用意してガリガリやるんじゃねーの？
532:名無しさん＠編集中
18/04/13 00:01:29.18 ciNufoQ0a.net
お前ら何学部卒？
533:名無しさん＠編集中
18/04/13 03:54:06.59 d42zSzX20.net
人に聞くなら自分から
534:名無しさん＠編集中
18/04/13 04:26:47.71 5+mGH86Kd.net
医学部
だからGPGPUとかチンプンカンプン
535:名無しさん＠編集中
18/04/13 09:43:04.68 Iy839CtQ0.net
>>503
SWでの高画質エンコードがされるなら
○○向け高画質エンコード（配信サイトで再エンコードされない）設定なんてのに意味がないから
ASICもしくはx264 --tune very fastレベルの高速SWエンコだと思う
536:名無しさん＠編集中
18/04/13 11:45:08.54 +CW60tiR0.net
>>509
> ○○向け高画質エンコード（配信サイトで再エンコードされない）設定
これが何のことを指してるのかよくわからない。Youtubeでそんなことできるんだっけ？
あとつっこんでおくと --preset veryfastじゃね。
537:名無しさん＠編集中
18/04/13 12:18:13.13 Sg2lKLiA0.net
GoogleのサービスでH.264トランスコードはx264だっけか
538:名無しさん＠編集中
18/04/13 12:38:58.40 6eRFP0ta0.net
配信サイトで再エンコードされない設定って言うのはよく聞く誤解だね
YouTubeだとどんな動画を上げても再エンコードされる
アップロードしたあと手元の動画とSSIMなりで比較してみたら分かる
539:名無しさん＠編集中
18/04/13 13:23:15.76 Sg2lKLiA0.net
昔の実装そのまま今でも一緒だと思っていたり
ニコニコの体の良いシステム負荷軽減手法と同じだと思っているんじゃないかな
540:名無しさん＠編集中
18/04/13 17:18:55.93 Iy839CtQ0.net
そりゃyoutubeへのアップロードに関する話題とか昔の流行だもの
541:名無しさん＠編集中
18/04/13 18:12:08.90 qCymtqNK0.net
よくわからんがYoutubeで再エンコードされないようにする設定があると勘違いしてたってことか。
542:名無しさん＠編集中
18/04/14 14:03:51.15 89UFyH020.net
16Kまだ？
543:名無しさん＠編集中
18/04/14 15:38:58.48 JUsY
544:ulE3d.net
545:名無しさん＠編集中
18/04/14 16:34:42.61 yQp2n2100.net
>>517
基本ではないでしょ。可逆はサイズもでかくなって面倒だし、
「可逆で上げた場合」と「十分高画質な非可逆で上げた場合」とで
生成された動画に目立った違いは出ないと思うし、後者で上げる人がほとんどだと思うよ。
546:名無しさん＠編集中
18/04/14 16:48:12.43 W4h1IMs60.net
自分はx264 crf12ぐらいで上げてるな 16と程度と比較するどちらが綺麗かは分かるレベルだったし意味なくは無いと思う。
生成後の動画比較すると画質毎に設定やビットレート多少違うかもね
547:名無しさん＠編集中
18/04/14 17:48:50.77 EMVmu1/I0.net
低いcrfほどエンコーダの差が画質に出てこなくなるから、QSVやNVEncでササッと処理済ませてアップロードし始めた方が手早いかも
放置で下準備させておく時間があるならx264だけど
548:名無しさん＠編集中
18/04/14 20:01:48.20 yQp2n2100.net
1080pの335フレームでAV1をテストしてみた。
ソースは進撃の巨人１期OPのサビの立体機動シーン～大砲発射まで。
結果： URLﾘﾝｸ(2sen.dip.jp)
--cpu-used 3 でx265のveryslowと同程度の品質で、かかる時間は17倍。
--cpu-used 2 だとそれ以上の品質で、かかる時間は100倍。
--cpu-used 1 だと更にそれ以上の品質で、かかる時間は170倍。
(ただしどれも--tile-columns未使用。使えばこの半分くらいにはなるかも。)
--cpu-used 1 だと、x264 veryslowで7Mbps、
x265veryslowで5Mbpsくらいかかるのを、4Mbps弱にするくらいの圧縮効率。
VMAF/SSIMに基づいた評価としてはこんな感じになった。
549:名無しさん＠編集中
18/04/14 20:14:36.49 NsXr+PVe0.net
>>521
乙乙
参考になる
550:名無しさん＠編集中
18/04/14 22:12:23.37 +/qR7O9Z0.net
>>521
これを維持してどんだけ高速化できるかだなぁ
551:名無しさん＠編集中
18/04/14 23:21:16.52 5o34rogK0.net
実用になる時間じゃないね
552:名無しさん＠編集中
18/04/15 02:31:59.29 3zo9kCKG0.net
libaomはリファレンスみたいなもんだし、まだ最適化もされてないから
今のlibaomのエンコード速度/時間を見てAV1の実用度を判断してはダメだよ。
libaom自体はどこまで最適化されてどれくらい速くできるのかわからんけど、
商用ではベンダーが開発したエンコーダ(SW/HW)が使われるんだろうし。
ちなみに>>521のサンプルでは-cpu-used 3 -crf20で335フレームのエンコードが約3時間4分だったけど、
crowd_run(1920x1080、500frames)は同じ設定で6時間30分かけて100フレームしか進まなかったので中止した・・・。
553:名無しさん＠編集中
18/04/15 21:39:15.37 wDrk/oMp0.net
very slowの17倍って今の段階なら悪く無いじゃんって思ったけどx264ならmidiumの数倍程度だけどx265だと凄いんやね
554:名無しさん＠編集中
18/04/17 08:58:23.81 G8gaxn+mM.net
話題が無いので間潰しにNVEncネタ
NVEncでの同時エンコードは基本的に2つまでと言われているが、実はQuadro 2000番以上とTeslaは制限が無い
あとNVEncエンジンの搭載数にも違いがあり
GK世代、GM107やGM206、GP107～106 は1基
GM204～GM200、GP104～102 は2基、GP100やGV100は3基搭載されていて
搭載エンジン数分までは同時処理をしても処理速度が殆ど落ちない様になっている
例外的なのがGTXGTX1070で、GP104自体は2基搭載だがエンジンが1つ無効化されている
GTX1070TiについてはGTX1080と同じく2基とも有効
なので同じ世代ならNVEnc自体の処理性能自体に大差は無いけど、
エンジンの搭載数によって同時処理（多くの場合は2ウェイ処理）時
555:の処理速度低下具合が変わってくる
556:名無しさん＠編集中
18/04/17 09:06:44.92 7Ja6+jKC0.net
それ知ってたら1080買ってたわ
557:名無しさん＠編集中
18/04/17 09:25:46.28 G8gaxn+mM.net
NVEncの処理速度的については、固定量子化でブン回す場合には、FHDでの出力ならピーク値でH264で600～650fps、HEVCで400fps前後ぐらい（NVEncのHEVCはBフレーム省略仕様なので速度低下が少ない）
NVDecのデコードはFHDで600～650fpsぐらいがピーク値になる
あと実行環境（NVEncを呼び出すアプリ）によってピーク値近くで動作させられるかが変わってくるので留意
例えばTVMW6だと、エンコードの前段がボトルネックで2つ同時のバッチエンコにしないとエンジンを回しきれない
お陰でエンジン2基環境の場合はどちらも回し切ることが出来ない
558:名無しさん＠編集中
18/04/17 09:50:40.44 UuaDiTHp0.net
はぁ、1080並の値段でELSAの1070なんてかわなければよかったｗ
559:名無しさん＠編集中
18/04/17 10:28:31.86 G8gaxn+mM.net
捕捉
上の速度はPascal世代の速度で、1つ前のMaxwell第2世代だとH264なら2/3、HEVCなら1/2ぐらいの性能になる
Pascal世代でのNVEncのトピックは、HEVC速度低下が少なくなっている事なんだけど、公式なトピックに記述は無いけど、Pascalで動作クロック自体が大きく向上しているので、結果的にH264も含めた全体的なパフォーマンスも相当上がってる
Pascal世代のHEVCについては、性能低下緩和も含めてマクロブロックの捜査ロジックの改善もされている様で、Maxwell第2世代のHEVCより地味に画質が向上されている
NVEncの速度はデフォルトの動作クロックに依存（ツールによるソフトウェアでのOCはCUDAコア側のクロックが上がる仕様）なので、NVEnc目的でグラボ購入する場合には、製品の公称クロック基準で購入した方が良い
ファームウェア操作ツールでクロック上げた場合はそのまま性能に反映される
560:名無しさん＠編集中
18/04/17 11:01:56.07 G8gaxn+mM.net
NVEncの性能で考えれば、リファレンスクロックが高く、エンジン2基のGTX1080が最良
次点で僅かにクロックが低いGTX1070Ti
GTX1070はリファレンスクロックはGTX1070Tiと同じだけど前記の通りエンジン1基なので、NVEnc狙いではお勧め出来ない
GTX1080Tiはエンジン2基だけど、動作クロックがGTX1050並なのでEVEncの性能は落ちるし単価が高い
エンジンの単価で考えれば、GTX1050無印が安価
CUDAコア数が少ない分、GTX1050Tiよりクロックで性能稼いでいるので、
動作クロックも高めになっているが、クロックは1つ上のGTX1060より1割落ちる
高いクロックでエンジンを含むGPUコア部（否CUDAコア）を回せるかは、TSMC16nmFF製造かSAMSUNG14nmFF製造（16nmより回らない）か、グラボの電源部の影響が大きい
（それでもGTX1050をファーム改造でGTX1080のリファレンス並ぐらい回す事は不可能じゃ無い
561:名無しさん＠編集中
18/04/17 11:41:12.03 ipT4+ZwS0.net
GK208はNVEnc乗ってるのにGP108がなぁ
562:名無しさん＠編集中
18/04/17 13:13:22.45 l5bingFq0.net
こういうGeForceの型番ごとにおける機能の制限/無効化ってどこかにドキュメントとしてまとまってるの？
QuadroとTeslaはHTML上に一覧表が出来てるけど
563:名無しさん＠編集中
18/04/17 13:37:31.07 G8gaxn+mM.net
nvidiaのdeveloperにあるみたいな一覧は無いね
海外フォーラムでは日本よりNVEncについて掘り下げてスレが意外にあって
エンジン数についても話題に上がる
GTX1070Tiなんかも、リリース後エンジン数についてスレ立ってた
対応SDKから実機確認すれば解るんで、同時処理数も同様やね
564:名無しさん＠編集中
18/04/17 13:38:28.10 7Ja6+jKC0.net
そういう情報出さないで売ってるの、なんだかなって思うわ
565:名無しさん＠編集中
18/04/17 14:03:08.33 tPz+M+Wh0.net
NVIDIAにとっては、エンコーダーの価値はその程度にしか見ていないということ
566:名無しさん＠編集中
18/04/17 15:04:10.48
567:g34xNThwa.net
568:名無しさん＠編集中
18/04/17 15:07:05.87 Ev+v4bJ00.net
なんでAMDは動画最弱になっちゃったんだろ
動画ならRadeonなんて時代もあったのにね
569:名無しさん＠編集中
18/04/17 15:11:14.83 GjWzJu8g0.net
というか、実用面からすると
・NVEncを保存用エンコードに使う人はあまりいない
・NVEncで並列エンコードをする人もあまりいない
・全体的に十分以上に高速なので、高速域での速度差を気にする人もあまりいない
ということで、一般ユーザー的にはエンジン数やエンコード速度の差を重要視する人は少ないのでは。
（「実際に使うわけじゃないけど最高の機能が載っててほしい」という気持ちはよくわかるけど）
570:名無しさん＠編集中
18/04/17 15:18:43.64 G8gaxn+mM.net
公表されてる範囲の機能的なスペックはエンジン1基有れば実現出来るからね
571:名無しさん＠編集中
18/04/17 15:37:01.40 G8gaxn+mM.net
NVDec/NVEncのSDKもnvidia的にはターゲットはTeslaやQuadroで、Geforceでも一応使えるという感じだからね
Geforceだからと全モデル1基とかにされなかっただけでも良かったとする鹿
GTX1070の1基のみ有効になってる事ネタにして、nvidiaに纏まった数の直訴なんかしたら、あの会社なら次世代からGeforceグレードは統一仕様として一律1基にしてとかやりかねんｗ
572:名無しさん＠編集中
18/04/17 15:44:43.10 ipT4+ZwS0.net
>>539
ip変換の質とエフェクトが充実してたって話でデコードエンジン自体はずっとnvidiaの一周遅れだよ
573:名無しさん＠編集中
18/04/17 15:51:52.91 m7y6f3bl0.net
Netflix: AV1 is our primary next-gen codec
URLﾘﾝｸ(www.csimagazine.com)
574:名無しさん＠編集中
18/04/17 16:11:49.90 YX1SzvXBM.net
アムドの寝言はVP9有効にして
公約果たしてからにしてほしいなw
575:名無しさん＠編集中
18/04/17 16:40:17.77 G8gaxn+mM.net
デコーダはVega世代で載ってなかったっけ？
576:名無しさん＠編集中
18/04/17 17:56:50.23 kpSfcMeTa.net
xiphがRustで作ってるav1のエンコーダって話題出てる？
リファレンスより速いって書いてあるけど
577:名無しさん＠編集中
18/04/17 19:02:38.88 G8gaxn+mM.net
これか
URLﾘﾝｸ(github.com)
国内で話題にしてる人は少なさそう、自分も今知ったわ
libaomのコードをベースに入れてるのかな？
他方の資料で
libaomのアセンブラ化で4倍は速くなる、多分100倍速く出来そうだけど、アルゴリズムの書き換えが膨大すぎるわい！
みたいな事書いてあった
578:名無しさん＠編集中
18/04/17 19:41:01.17 QtBc3OjV0.net
>>545 >>546
>>122でも書いたけどPolaris/VegaはVP9のDXVAデコードに対応していない。
当初は隠し機能として存在していたそうだが、それも後になって消された。
ただしDXVAとは別にOpenCLによる再生支援が利用できるMFTフィルタがあり、
ChromeやFirefoxはそれを使ってVP9再生支援を利用することができる、という状況らしい。
なおRavenRidgeはVP9のDXVAに対応している。
>>547-548
>>89で出てるね。限定的な実装みたいだし、試したことはない。
579:名無しさん＠編集中
18/04/17 19:59:42.94 AV9r83+30.net
ビルドして試そうかと思ったけどビルドできなくて放置してた
580:名無しさん＠編集中
18/04/17 21:09:13.49 aZh6iL+w0.net
これcじゃなくてrustなん？
時代はrustなのか？
581:名無しさん＠編集中
18/04/17 21:13:46.15 0c2uycJlM.net
RustもC言語の派生の一種と言えなくもない
582:名無しさん＠編集中
18/04/19 22:57:58.69 hZLV04Fua.net
Rustは並列化が前提の設計されてるからC++より高速化できるのかもしれないね
583:名無しさん＠編集中
18/04/20 02:37:09.78 zIebTadQ0.net
Mozilla�
584:ﾌDaalaで使ってたから親和性は折り紙付きだろう
585:名無しさん＠編集中
18/04/20 04:41:34.60 3IIJGeeBM.net
吐かれるバイナリの並列化の高さと、複雑なコード管理に向いてるとかだろうね
代わりに習得がえらい難しいらしいけど
使用者に最も愛されている言語とか言うけど
愛が無ければやってられない習得難易度の裏返しだったり
586:名無しさん＠編集中
18/04/20 05:30:27.07 HD+81Fzka.net
>>554
Daala作ってたのはXiphだけどな
Xiphは半分Mozillaみたいなものだけど
587:名無しさん＠編集中
18/04/20 07:18:32.61 N1qeHIsf0.net
Daala作ってたのは誰あぁぁぁぁ
588:名無しさん＠編集中
18/04/21 12:52:16.94 tM5w7H6r0.net
xiphってflac作ったところなんだな
知らなかったわ
589:名無しさん＠編集中
18/04/21 13:21:10.75 Qy2Pbsrq0.net
ハイレゾは全く無意味とバッサリ切ったのが爽快だった
590:名無しさん＠編集中
18/04/21 19:19:53.26 BSwSpyS80.net
ハイレゾは無意味じゃないから間違ってるな
591:名無しさん＠編集中
18/04/21 20:42:38.58 mCJYRNDS0.net
URLﾘﾝｸ(people.xiph.org)
592:名無しさん＠編集中
18/04/21 23:18:19.11 6E+waUvMa.net
いや無意味だから
593:名無しさん＠編集中
18/04/21 23:40:10.60 vIk2JOlP0.net
そういうのはピュアAU板ってのがあるからそっちで存分にやればいいと思うよ。
ハイレゾの良さを追求するスレ ★1
ｽﾚﾘﾝｸ(pav板)
594:名無しさん＠編集中
18/04/21 23:54:04.88 BSwSpyS80.net
耳に聴こえなくても脳に影響してるんだよ
聴覚が全てではない
595:名無しさん＠編集中
18/04/22 00:05:32.14 qoqXsoAZa.net
悪影響かな
596:名無しさん＠編集中
18/04/22 00:30:07.28 dppkcbl/0.net
音痴なんだろ
597:名無しさん＠編集中
18/04/22 12:34:11.98 OUHz0R6x0.net
違いが分かる人と分からない人が
居るだけの話なのに
実際に目の前で見ないと信じられないのが人間
598:名無しさん＠編集中
18/04/22 15:46:11.93 MAIw05DH0.net
その帯域の音が聴こえるかどうかは別にしてハイレゾを売りにするような音楽は
ちゃんとマスタリングしてる物がほとんどだから20khz以上が切れてようがそうで無いものより綺麗っていうのはあるね
599:名無しさん＠編集中
18/04/22 18:57:13.36 17JCXUuud.net
URLﾘﾝｸ(encrypted-tbn3.gstatic.com)
600:名無しさん＠編集中
18/04/22 20:19:04.53 NF+KmVz0a.net
精神論は他板でやれ
601:名無しさん＠編集中
18/04/22 20:27:09.28 Itj5Wijm0.net
(´・ω・`)
602:名無しさん＠編集中
18/04/22 20:33:15.85 eWH2rYSA0.net
(´・ω・`)
603:名無しさん＠編集中
18/04/23 16:17:13.95 BRPMKJ720.net
自分で4K動画作ってつべにアップするようになって初めてVP9なんて意識するようになったんだけど
なにこれつべのVP9の4K十分綺麗じゃん
なんでこのVP9ってのはH.264やHx265以上に流行らないの？ 俺が事情を理解できてないだけだが理由がわからない
しかもつべの4K VP9ってビットレートたかだが12Mbps程度でこの画質なんでしょ？
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
604:名無しさん＠編集中
18/04/23 16:36:36.95 sukaORLRM.net
ググレカス
605:名無しさん＠編集中
18/04/23 17:45:49.03 2g6F1r+U0.net
>>573
x265@フルHDなら1～3Mbpsでそれなりに見れる画質になるんだから
4ｋで12Mbpsってのは少ないわけじゃない
606:名無しさん＠編集中
18/04/23 19:12:20.92 hFr3woIv0.net
h264とVP9を比べるなよ
607:名無しさん＠編集中
18/04/23 20:07:51.31 fgZBGlO6M.net
比べてん�
608:ﾌはH265とじゃねえの？
609:名無しさん＠編集中
18/04/23 20:20:41.65 sDC0ee320.net
つべに揚げる為に4K動画をH.264でビットレート60Mbpsで作ってる自分が馬鹿みたいに感じるんだが
610:名無しさん＠編集中
18/04/23 21:52:47.76 z48p7vFc0.net
YouTube推奨ビットレート
URLﾘﾝｸ(vook.vc)
611:名無しさん＠編集中
18/04/23 22:33:19.70 xaUnJI540.net
>>573
やってみれば分かる。264や265に比べて死ぬ程遅い
特にx265と比較するとビットレート比画質負けるのは勿論デフォ設定同士の比較で1桁以上、下手すれば2桁が見えてくるぐらい遅い
612:名無しさん＠編集中
18/04/23 23:00:31.33 qgLqyElT0.net
,．-─ ─-､─-､
, イ)ィ -─ ─- ､ﾐヽ
ノ ／,．-‐'"´ ｀ヾj ii / Λ
,ｲ／／ ^ヽj(二ﾌ'"´￣｀ヾ､ﾉｲ{
ノ/,／ミ三ﾆｦ´ ﾞ､ﾉi!
{V /ミ三二,ｲ , -─ Yｿ
ﾚ'/三二彡ｲ .:ィこﾗ ;:こﾗ j{
V;;;::. ;ｦヾ!V ｰ '′ i ｰ ' ｿ
Vﾆﾐ( 入 ､ r j ,′
ヾﾐ､｀ゝ ｀ ｰ--‐'ゞﾆ<‐-イ
ヽ ヽ -''ﾆﾆ‐ / ググレカス [ gugurecus ]
| ｀､ ⌒ ,/ （西暦一世紀前半～没年不明）
| ＞ ---- r‐'´
ヽ＿ |
ヽ ＿ ＿ 」
613:名無しさん＠編集中
18/04/23 23:29:52.22 2kQ4iN3t0.net
>>580
なんか>>361のリンク先読むとVP9の方がHEVCより縮むと読み取れるんだけど…、
x265ならVP9より縮むって事なんかね？
＞AOMediaのメンバー企業であるBitmovinの検証によれば、同じ画質で比較したさい、AV1はVP9比で22～27%、HEVC比で30～43%ほどビットレートを削減できるという。
614:名無しさん＠編集中
18/04/24 00:12:35.33 e84XDnmq0.net
計算量がね
615:名無しさん＠編集中
18/04/24 01:36:38.43 4wh5n1kV0.net
>>579
つべあげるのに4k60pは60Mbpsあったほうがええのか。。
616:名無しさん＠編集中
18/04/24 02:57:28.71 Cv2UDVgJa.net
vp系はバッファ少なくても縮むからストリーミングに向いてて良いわ
mpeg系は再生できるようになるまでが長い
617:名無しさん＠編集中
18/04/24 21:19:53.63 TErN/BXE0.net
Advanced Media Framework (AMF) SDK Version 1.4.7
URLﾘﾝｸ(github.com)
Version 1.4.7: AMD Radeon Software Adrenalin Edition 18.3.4 (17.50.33) or newer
New features are available in
Driver: Radeon Software Adrenalin Edition 18.3.4 Software: 17.50 and later
1.4.7.0 (04.12.2018) version
--------------------------
- 360 video stitch sample
4/12って書いてるのは4/24の間違いだな。
618:名無しさん＠編集中
18/04/25 07:58:12.15 Dw16c1DhM.net
要はbuildコードが4/12って事でしょ
チェックか何かでゴタついたんでしょ
619:名無しさん＠編集中
18/04/25 20:34:00.59 vBxpOWXf0.net
URLﾘﾝｸ(code.facebook.com)
gop単位で分割してエンコードしてるみたいなこと書いてるな
>>111のYouTubeと一緒か
620:名無しさん＠編集中
18/04/25 21:10:56.23 +uyVIJ620.net
Facebook video adds AV1 support | Engineering Blog | Facebook Code | Facebook
URLﾘﾝｸ(code.facebook.com)
去年11月下旬時点のlibaomをChrome Canaryに盛り込
621:んで FacebookビデオでAV1のお試しサポートをしてみたよって話。 ブラウザ側で正式バージョンの実装がされたら、そっちに切り替えていくとのこと。
622:名無しさん＠編集中
18/04/26 03:03:05.56 cCy6wkiya.net
今canaryに来たってことはstableに来るのは4ヶ月後くらいかな
firefoxもchromeと同時期くらいには実装されるだろうか
一番の問題はスマホの対応だけどね
623:名無しさん＠編集中
18/04/26 03:53:50.73 jGFgkYoTM.net
静止画はまだ出てこないのかな
624:名無しさん＠編集中
18/04/26 04:37:58.48 gpsPqjL70.net
>>591
まだ仕様決まってないけど開発中らしい
AV1 Still Image File Format (AVIF)
URLﾘﾝｸ(aomediacodec.github.io)
実際の画像での比較
URLﾘﾝｸ(people.xiph.org)
SSIM Yでの比較
URLﾘﾝｸ(i.imgur.com)
625:名無しさん＠編集中
18/04/26 04:42:11.54 gpsPqjL70.net
ただし、性能いいけど最適化されてない今だと画像一枚変換するのに60秒くらい平気でかかる
626:名無しさん＠編集中
18/04/26 06:03:36.45 jGFgkYoTM.net
ありがと、これで電子書籍の容量減ってくれると助かるなあ
雑誌DLしたら500Mとか食ってるからはやく普及してほしい
627:名無しさん＠編集中
18/04/26 07:01:58.96 gpsPqjL70.net
そういえばハードウェアのエンコードって動画の場合ではソフトウェアよりかなり画質が落ちるけど静止画の場合だとどうなんだろう
628:名無しさん＠編集中
18/04/26 09:09:52.33 WbUdhyf6M.net
>>592
ssim0.985辺りで見てみるとjpegに対してのwebmに近い比率でwebmに対してのAVIFは縮むんやね
BPGはエンコードは兎も角デコード重過ぎ&対応ソフト少な過ぎで使い物にならなかったけどwebmの倍までのデコード速度と同程度の普及にはなって欲しいなぁ
629:名無しさん＠編集中
18/04/26 21:50:44.86 9dHHlQgGM.net
Appleは最近画像フォーマットにHEVCベースのHEIFを使ってるけど、
AVIF完成したらAVIFに移行するんかな。
もしそうなったらスマホ用サイトの画像フォーマットにAVIF普及しそう。
>>595
動画ほどソフトとハードでの画質の差は出ないと思うよ。
一枚絵の画像だとソフトとハードの差が出やすいフレーム間予測による圧縮がないので。
630:名無しさん＠編集中
18/04/27 08:29:46.56 1O42is100.net
ソフトとハードでどのくらい違うか気になったので>>592のグラフにx264とh264_qsvを追加(項目名クリックで表示切り替え可能)
URLﾘﾝｸ(plot.ly)
まあ少し落ちるけどこれくらいなら許容範囲かな
631:名無しさん＠編集中
18/04/27 14:06:31.54 9FN5TERTM.net
Next-Generation Image Compression (JPEG XL) Final Call for Proposals
URLﾘﾝｸ(jpeg.org)
これAV1じゃないの
632:名無しさん＠編集中
18/04/27 14:19:08.92 9FN5TERTM.net
JPEG-XL >60% over JPEG-1
MPEG-H(HEVC) >60% over MPEG-1
WebP2(≒AVIF) >15% over HEIC
633:名無しさん＠編集中
18/04/27 14:43:01.24 9FN5TERTM.net
姉妹規格のJPEG XSは来年完成らしい
ビジュアルロスレスというとDisplayPortのDSCコーデックみたいなやつだな
オープンフォーマットJPEG XS、画像符号化史上初のパラダイムシフト
URLﾘﾝｸ(this.kiji.is)
JPEG XS標準化プロセスの開始は、2016年のJPEG 71回目の会合にて承認された。JPEG XSは、超低遅延、電力、帯域幅の要件だけでなく、実装が簡単な
634:アルゴリズム、少ないメモリでも動作し、そして長いケーブルランをサポートすることを目的にしている。 コアコーディングシステムは2018年7月に完成予定で、リファレンスソフトウェアを含んだ全体の完成は、来年2019年4月に予定されている。
635:名無しさん＠編集中
18/04/27 15:00:41.15 9FN5TERTM.net
JPEG XSコーデックメモ
URLﾘﾝｸ(qiita.com)
JPEG XSコーデックは、低計算量・低レイテンシが要求されるアプリケーションにおいて、主に「Mezzanine(舞台下の)コーデック」としての利用が期待されている。
ライブ・プロダクション
放送・デジタルシネマ ワークフロー
プロ向け映像市場
KVM1アプリケーション
VRゲーム など
JPEG XSは、従来の(無印)JPEG, JPEG2000, JPEG XR, WebP, HEIFといった大量データ保存・WEB配信向けコーデックを 置き換える技術ではない。
636:名無しさん＠編集中
18/04/27 17:19:20.66 bi0qElbcM.net
HDMI2.1もVESAが規格化したDSCを採用するみたいだな。もうDPと統一しろよ
URLﾘﾝｸ(av.watch.impress.co.jp)
DSC(Display Stream Compression)はDPCM(Delta Pulse Code Modulation)とICH(Indexed Color History)をベースにしたリアルタイム性に優れた圧縮技術で、設定した圧縮率で安定した圧縮結果が得られる特徴を持つ。
ただし、圧縮したデータは元のデータには戻らない、いわゆるロッシーな(ある程度の劣化を許容した上で活用する)映像信号圧縮技術になる。
MPEG系のような、過去から現在の映像フレーム同士の相関関係を利用した圧縮技術は、元のデータに対して数百分の1にまで圧縮が可能だが、DSCは時間方向に伝送されててくる一次元データストリームの圧縮なのでたかだか数分の1程度の圧縮率に留まる。
その代わり、低遅延で高速リアルタイムに圧縮展開できる利点がある。
ちなみに、このDSCロジックのIPコアを開発したのは半導体IPメーカーのHardentだ。
637:名無しさん＠編集中
18/04/27 17:47:07.69 gEcmA/z6a.net
jpegの牙城はH.264より堅いだろうから新画像コーデックを広めるのは厳しいだろうな…
MSとAppleとGoogleが足並み揃えてゴリ押ししたらいけるかも？って感じ
638:名無しさん＠編集中
18/04/27 19:05:47.95 EWvTPi2GM.net
ありゃJPEG XLの技術公募締切が9月に延期されてる
公開目標時期は2019年10月か
AV1採用してくれ
639:名無しさん＠編集中
18/04/27 19:18:04.15 diV9ARYpM.net
>>604
そのメンバー全員Alliance for Open Mediaに加盟してるし、MozillaやFacebookやNetflixもいる。
Appleしか推してないHEIFやGoogleしか推してないWebP、Microsoftしか推してないJPEG-XR
とはかなり状況違うから今度は期待できそう。
640:名無しさん＠編集中
18/04/27 23:11:06.12 +UMyqfuU0.net
VP9は画質で判断するとたまにH264よりサイズでかくなるから困る。圧縮するなら相応の力を見せてくれないと
中途半端だ
641:名無しさん＠編集中
18/04/28 04:17:32.25 vQv5IYZY0.net
>>603
HDMIがロッシーになるのか
マウスカーソルの周りにブロックノイズとか出たら嫌だな
642:名無しさん＠編集中
18/04/28 04:45:52.04 iRXtwpm2a.net
8Kくらいまで解像度を上げない限りは非可逆にはならないと思うぞ
643:名無しさん＠編集中
18/04/28 10:49:22.34 rp64
644:VJ9F0.net
645:名無しさん＠編集中
18/04/28 10:51:51.61 rp64VJ9F0.net
>>606
基本的にアプリケーションの内部処理やサービスとセットで消費者側はデコード主体使う事になるだろうから、個人で生成する事は余り考えなくて良いと思う
646:名無しさん＠編集中
18/04/28 22:36:34.23 tYs2/UtdM.net
たしかtwitterはgifをアップロードするとmp4(h.264)に変換される仕様だったような
google photoもwebpに変換されてるんだっけ？
全モダンブラウザが対応するweb標準の次世代画像規格さえできたら
あらゆるサイトでjpeg/png/gifが変換されるようになるはず
運営側もユーザー側もトラフィック削減パケット節約でwin-win
647:名無しさん＠編集中
18/04/29 13:51:15.35 o99M7JsiMNIKU.net
AV1が一般人にストレスなく利用できるようになるのは、いつ頃だろうか？
音声の圧縮音声コーデックは、今後MPEG4-ALS（品質重視の用途）かOpus（可聴帯域のみを扱う一般的な用途とリアルタイム通話向き）に収束していくのだろうけど
ところで、音声コーデックの話をするスレ、どこかあるのかな？
648:名無しさん＠編集中
18/04/29 13:57:23.74 hhx87O280NIKU.net
ストレスなく利用っていうのが視聴の事なら1、2年で可能だろうけどエンコードの事なら一生来なさそう
649:名無しさん＠編集中
18/04/29 16:31:01.59 o99M7JsiMNIKU.net
>>614
アカンがな、それ…
となると、やはり映像はHEVCベースで運用しておくか
音声はフリーのくせにと言ったらおこられそうだが、日常使いではOpusでいいかなと最近は思っている
新しくYouTubeにアップされてる高解像度のものは、元からOpusでエンコードされているから聴き取りやすくていいし
音声メインの素材をアップする人は、積極的に高解像度（フレームレートは1fpsとかにできるのならば、それでいい）でアップしてもらいたい
650:名無しさん＠編集中
18/04/29 16:44:59.29 rFAS4HxrMNIKU.net
>>612
AVIFはアルファチャンネルやアニメーションにも対応するそうだし、
AVIFに使用されてるAV1は可逆圧縮にも対応してるから、
うまく行けばjpg/png/gif全部置き換えられそう。
651:名無しさん＠編集中
18/04/29 18:01:51.92 E3c9gHljMNIKU.net
>>613
ここかな
【Opus/Vorbis/FLAC】Ogg統合20【AV1/Theora】
ｽﾚﾘﾝｸ(software板)
652:名無しさん＠編集中
18/04/29 19:45:07.16 o99M7JsiMNIKU.net
>>617
ソフトウェア板にあったのか
DTM板かと思ってたよ
Thx.
653:名無しさん＠編集中
18/04/29 21:14:36.62 TSyBLkXS0NIKU.net
>>615
Opus気になって調べてみた
で、YouTubeに4K動画でMISIAの音源にいいのがあったので試してみた
確かにいい
ただし、手元のPCで再生するよりスマホのXperiaで再生したほうが高音質だった（泣
PCの音声環境見直すか・・・
654:名無しさん＠編集中
18/04/29 21:32:14.56 mEIjwYB6aNIKU.net
>>619
それわかるw
Opusをもっと試したかったらサカナクションの「多分、風」という曲もOpusの入ってるファイルで聴くといいと思う
655:名無しさん＠編集中
18/04/29 22:04:22.84 1hLNpWuo0NIKU.net
>>616
可逆圧縮をなめてはいけない。
可逆画像圧縮のアルゴリズムをを不可逆画像圧縮から流用するアプローチが
いくつかあるけど、普通にPNGより性能悪い。
WebPは可逆不可逆両対応だけど、それぞれ別のアルゴリズムを使ってる
656:。 可逆か不可逆かぱっと見で区別できないのも困るし、今までどおり別の型式のがいいと思う。 可逆画像圧縮はzstdのアルゴリズムベースのが出てきてくれたら嬉しいけどなぁ。
657:名無しさん＠編集中
18/04/29 23:37:02.55 RFC43lfy0NIKU.net
お前ら可逆不可逆って続けて何回言える？
俺は1回すら怪しいんだけど
658:名無しさん＠編集中
18/04/29 23:39:32.57 xjjdisQZ0NIKU.net
最初の3文字までは読めた
659:名無しさん＠編集中
18/04/30 00:03:24.95 8vT42dcVM.net
>>619
YouTube動画の音声サンプリング周波数は
AACが41.1kHzでOpusは48kHzだったような
だから例えばiPhoneシリーズなら6s以降スピーカーが48kHzしか対応していないらしいからAACだと多少音質変化するかも
逆に44.1kHzのみ対応のイヤホンとかもあったり
なんか深淵を覗いた心地に
660:名無しさん＠編集中
18/04/30 00:09:31.52 8vT42dcVM.net
>>621
そういやFLIFとかいうFLACの親戚みたいな名前の可逆圧縮画像規格あったけど最近は音沙汰無しだな
いつかリリースされる日は来るのだろうか
661:名無しさん＠編集中
18/04/30 00:34:28.89 8vT42dcVM.net
最近は写真や動画を撮ったらすぐにクラウドストレージに投げることが増えてきたから
元ファイルを(ビジュアル)ロスレス圧縮してアップロードした後、クラウド上で再エンコードする時代になったりしないかな
ロスレスHEVCかロスレスAV1かVESAのDSCかどれでもいいけど
662:名無しさん＠編集中
18/04/30 00:51:03.48 8vT42dcVM.net
FLACをアップロードできてOpusがストリーミング配信されているSoundCloudはすごいな
無料だし
663:名無しさん＠編集中
18/04/30 01:56:05.01 g5bwX14t0.net
>>627
SoundCloud、これいいね！
スマホにアプリ入れてGoogleのアカウントでサインインしてみたけど、操作が少し独特だけどいいよこれ
日本人の曲もあるし、音も素材が良ければいい感じだね
これはいいの教えてもらったよ
ありがとう！
664:名無しさん＠編集中
18/04/30 15:02:47.73 K2+Kaxf4M.net
PNGのほうがwebp可逆より縮む？
665:名無しさん＠編集中
18/04/30 23:11:45.40 1+hf/BtW0.net
>>629
WebP可逆は不可逆とは別のアルゴリズムだから殆どの画像でPNGより縮む
BPGの可逆圧縮を調べてみたけどやっぱり微妙だった
PNGが苦手な画像だとPNGより縮んだり縮まなかったり
PNGが得意な画像だとPNGに引き離される
AV1の可逆圧縮も似たようなもんになる気がする。
666:名無しさん＠編集中
18/05/01 02:14:16.26 HX1oXWc70.net
PNGは最適化を掛けるとかなり縮むけど、
マルチスレッドすら対応してない古いプログラムばかりで遅いのがな
その辺をちゃんと最適化してくれればPNGで十分そうな気がする
667:名無しさん＠編集中
18/05/01 02:25:48.52 vXYkO7J+0.net
とりあえずWindows 10の最新アップデートを適用すると、HEIFの表示のみOS標準で対応だとさ
※保存はダメ
668:名無しさん＠編集中
18/05/01 05:30:37.42 os57il8aa.net
結局OSの対応よりブラウザの対応のほうが大切なんだよね
669:名無しさん＠編集中
18/05/01 05:31:42.05 8wdpRSsu0.net
>>630
BPGの可逆圧縮はエンコーダーにx265を使うと縮まないけどjctvcなら結構縮む
jctvcは0.9.6以降は搭載されてないから試すなら0.9.5を使ってね
670:名無しさん＠編集中
18/05/01 12:32:13.70 8wdpRSsu0.net
AV1の可逆圧縮、相当無理矢理だけどこんな感じで出来た
ffmpeg -y -i "%~1" -
671:filter_complex "extractplanes=r+g+b[r][g][b],[r][g][b]mergeplanes=0x001020:yuv444p" -strict -1 -f yuv4mpegpipe - | aomenc.exe --passes=1 --i444 --lossless=1 -o "%~dpn1_av1_lossless.webm" - ffmpeg -y -i "%~dpn1_av1_lossless.webm" -filter_complex "extractplanes=y+u+v[r][g][b],[g][b][r]mergeplanes=0x001020:gbrp" "%~dpn1_av1_lossless.png"
672:名無しさん＠編集中
18/05/01 13:29:55.47 56CftVddM.net
>>635
AV1可逆の圧縮性能はPNGに比べてどうだった？
673:630
18/05/01 23:33:58.50 47AIvuLn0.net
>>634
jctvcを使ったら可逆ですげー縮んだ。勉強不足すぎてた。
これだと大方の画像ではPNGより小さくなりそう。
ただ、PNGが得意な画像で、差は縮まれど追いつけないままな物もまだあるから
PNGを全部置き換えるにはまだ不足してるって感想はそのままかな。
（一番手ごろなものだと、wikipediaのページのスクショ画像がそうなった）
674:名無しさん＠編集中
18/05/02 05:56:13.66 D0yOygKta.net
deflateという圧縮技術のデファクトスタンダードを使っているpngが置き換わることはそうそう無いと思うけどね
675:名無しさん＠編集中
18/05/02 06:31:48.11 cWA+EDYk0.net
>>636
ほい、調べた
AV1はかなり変なやり方で変換しているので効率が悪くなっている可能性もある
画像はpixivデイリーランキングから100枚
pngと比べて何パーセント縮んだか
BPG x265 4.23%
AV1 12.3%
webp 24.16%
BPG jctvc 26.72%
FLIF 31.45%
平均処理時間
BPG x265 1.449秒
PNG 2.439秒
webp 3.353秒
FLIF 7.301秒
BPG jctvc 13.9324秒
AV1 93.8216秒
ベンチマークに使用したbatも上げておくので設定とか検証が適切に行われたかが気になる人は見て
URLﾘﾝｸ(www.dropbox.com)
676:名無しさん＠編集中
18/05/02 07:05:18.55 Ssad5kFU0.net
webp優秀やな
677:名無しさん＠編集中
18/05/02 08:22:59.93 /Hb8IfCSM.net
>>639
ありがとー
AV1縮んでないね、可逆だとwebpに劣るなんて
得意な？非可逆だとどうなるんだろ
678:名無しさん＠編集中
18/05/02 17:47:43.70 uSkAIMzQ0.net
>>5の情報更新
●JVETで検討が進められていた、HEVCの後継コーデックは、FVCではなく
VVC （Versatile Video Coding）
という名前になった模様。
●先月のMPEGミーティングで報告された、360度ビデオやHDRも含めた主観評価のテスト結果では
HEVC比で40%以上の改善が見られ、特にUHDで効果があった。
●参考リンク
Beyond HEVC: Versatile Video Coding project starts strongly in Joint Video Experts Team
URLﾘﾝｸ(news.itu.int)
MPEG 122 - San Diego | MPEG
URLﾘﾝｸ(mpeg.chiariglione.org)
MPEG 122 Meeting Report - Bitmovin
URLﾘﾝｸ(bitmovin.com)
679:名無しさん＠編集中
18/05/02 18:20:31.86 /KuL0s/FM.net
40％！
素晴らしい！素晴らしいですよ！
680:名無しさん＠編集中
18/05/02 20:01:38.55 q+VeS0Up0.net
>>639
AV1本当何やってもトロくて駄目なやつだな…
ここまで糞だと改善の見込みも無さそう <
681:br> AV1を今より遥かに速く改善できるなら他のコーデックなら更に改善できるだろ
682:名無しさん＠編集中
18/05/02 20:06:23.69 j0vNwcLd0.net
それが出来ないからVVC等の新しいコーデックが開発されてるんだろ
683:名無しさん＠編集中
18/05/02 20:18:05.23 EaTyxjPAM.net
Googleが画像フォーマット「WebP」向けライブラリ「libwebp 1.0.0」をリリース
URLﾘﾝｸ(mag.osdn.jp)
WebPはWeb向けの画像フォーマットで、ロスレスおよび不可逆圧縮の両方に対応する。
拡張子は「.webp」。不可逆圧縮では、VP8動画コーデックが動画のキーフレームを圧縮するのと同じ手法で、プレディクティブ（予測）コーディングを使って画像をエンコードする。
ロスレス圧縮ではPNGと比較して26％小さく、不可逆圧縮ではJPEGより25～34％小さいとしている。
WebPファイルはVP8とVP8L画像データ、RIFFベースのコンテナで構成される。
libwebpではWebP仕様のリファレンス実装で軽量のエンコード/デコードライブラリに加え、WebPフォーマットへの変換などを行えるコマンドラインツールcwebp/dwebp、WebPイメージの閲覧やmux、アニメーション作成のためのツールを備える。
本バージョンはこれまでのバージョンとバイナリ互換があるとのことで、フォーマットとAPIが安定していることから1.0として公開したという。不可逆圧縮などが強化されツールもアップデートされている。
684:名無しさん＠編集中
18/05/02 20:18:41.81 EaTyxjPAM.net
>>646
WebP
URLﾘﾝｸ(developers.google.com)
libwebp
URLﾘﾝｸ(github.com)
685:名無しさん＠編集中
18/05/02 21:34:36.25 Ssad5kFU0.net
webpはデコード早いから良い
686:名無しさん＠編集中
18/05/02 21:37:53.46 8dHE9Ib0M.net
これでwebpがもっと普及するといいなあ
687:名無しさん＠編集中
18/05/02 22:00:46.77 TPiWhDTo0.net
なおFirefox
688:名無しさん＠編集中
18/05/02 23:40:55.87 /Hb8IfCSM.net
>>650
ブラウザ識別して火狐には重いデータを送ってやろう
689:名無しさん＠編集中
18/05/03 00:20:58.06 ag9sCIyxM.net
ChromeがAPNG対応したんだから
FirefoxはWebP対応するのが🍣
690:名無しさん＠編集中
18/05/03 02:42:42.99 qLoEKbqla.net
firefoxはwebp対応してるだろ
safariと勘違いしてるのか？
691:名無しさん＠編集中
18/05/03 10:10:30.36 uRMPloV+M.net
>>653
URLﾘﾝｸ(caniuse.com)
😿
692:名無しさん＠編集中
18/05/04 06:39:59.54 lkzBO84x0.net
4K放送は265HEVC？
693:名無しさん＠編集中
18/05/07 10:46:58.51 lWAiBYbLM.net
>>655
新4K8K衛星放送開始に向けた取り組み - 総務省（PDF）
URLﾘﾝｸ(www.soumu.go.jp)
URLﾘﾝｸ(i.imgur.com)
新4K8KはH.265だね
H.265が特許料で揉めてるって最近知ったからあまり詳しくないんだけど
特許料の高さがBS契約料とかNHK受信料とかに（無駄に）上乗せされないといいんだがなぁ
かと言って機動力のない放送団体が状況に応じてコーデック入れ替えなんかできるとも思えないし
694:名無しさん＠編集中
18/05/07 12:20:32.32 QSFqJxGb0.net
何を今更…
695:名無しさん＠編集中
18/05/07 12:25:34.52 mN4HSZiPM.net
>>656
対応profileのオプションにもよるけど、TV1台当たりライセンス料300円しないぞ
696:名無しさん＠編集中
18/05/07 13:26:33.16 mN4HSZiPM.net
今年の2月に特許切れたMPEG2にもライセンス料掛かってたしな
録画の圧縮機能やMPEG4/AVCの再生機能持ってる機器なら、未だにMPEG4/AVCのライセンス料も掛かってるし
今まで金銭的にそれらの上乗せを負担と意識して無かった奴が、今更HEVCのライセンス料で騒いでるのも可笑しいんだけどね
実効でその程度のものだったり
697:名無しさん＠編集中
18/05/07 13:38:03.21 mN4HSZiPM.net
映像コンテンツなら殆ど2円未満、高くても3円にもならないとかだし、
パッケージの流通コストや小売り・事業者の粗利の方が遙かに影響デカくて、個人単位で年間ナンボよって感じなのよね
そんな額気にするなら、家電品の消費電力気にしていた方がマシだったりな
自販機で飲料買ったり、コンビニで買い物する方が遙かに無駄という
698:名無しさん＠編集中
18/05/07 16:43:37.96 2gi9rWInM.net
「GIMP 2.10」リリース
URLﾘﾝｸ(mag.osdn.jp)
WebPサポート
699:名無しさん＠編集中
18/05/07 18:11:36.96 jxsmP9bbM.net
寧ろ今まで対応してなかったのか
700:名無しさん＠編集中
18/05/07 18:16:47.63 CavlMB6C0.net
GIMPは亀の歩みだし……
対応してくれただけでも喜ぶべき
701:名無しさん＠編集中
18/05/07 20:38:05.43 ZtP2jiNr0.net
昔はPhotoshopの代わりにGIMPでも頑張れば行けるかもって時期があったけど、
今は完全に突き放されて背中すら見えなくなってしまったなあ
702:名無しさん＠編集中
18/05/07 21:56:46.76 CavlMB6C0.net
今のフォトショってそんなにすごいんか（時代遅れ）
703:名無しさん＠編集中
18/05/08 00:22:38.74 ZanT8rbB0.net
GIMPはリリース間隔が空きすぎて開発者のほとんどがKritaとかDarktableに行っちゃったから…
704:名無しさん＠編集中
18/05/08 00:35:32.05 7ccNxeIra.net
GIMPの前回のリリースって5年以上前だろう
webpその頃あったのかな
705:名無しさん＠編集中
18/05/08 16:29:53.58 vgWy5NipM.net
Kritaは3年前からWebPサポートしてたのか
URLﾘﾝｸ(krita.org)
706:名無しさん＠編集中
18/05/10 21:28:35.09 YxvK1ObZH.net
androidのゲームでwebp義務化すればかなり通信料減らせそう
707:名無しさん＠編集中
18/05/11 07:42:07.81 HL2toN7BM.net
結局webpが流行ることは無かったな
コーデックもVP8のままだし
708:名無しさん＠編集中
18/05/11 10:06:37.10 G39yR8Av0.net
よくわからんけどAndroidのゲームはETC1かETC2が主流じゃないの？
多分DXT同様固定の容量圧縮比の方がメモリ消費量の把握しやすいだろうし
709:名無しさん＠編集中
18/05/11 22:50:53.49 XObC1OA70.net
>>670
JPEGから移行するにはショボすぎた
HEIFでやっとって感じ