19/12/08 08:29:09.41 CaG1sq6d0.net
H.264/AVC->2003年規格化
H.265/HEVC->2013年規格化
H.266/VVC->2020年規格化予定
CPUやGPUもそうだったけど
やっぱ競争があると性能が上がるのも早いな
x266はx265みたいにパテントでいつ潰されるかビクビクせずに使いたいわ
622:名無しさん＠編集中
19/12/08 13:23:52.92 EVrDoL7j0.net
>>612
x265のveryslowより何倍も遅いから一般人が使うものじゃないと思う
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
URLﾘﾝｸ(pbs.twimg.com)
初期と比べたら一応速くはなってはいるけど
URLﾘﾝｸ(i.imgur.com)
x軸のSPFは1フレームエンコードするのに何秒かかったという事
y軸は圧縮率で上に行くほど良い
623:名無しさん＠編集中
19/12/08 14:24:38.83 VK3lgY0IM.net
>>622
こうしていろいろデータを見ると、libaomのVP9の良さがますます浮き彫りになっているようにも思える…
VP9ならば既にハードウェア再生支援も使えるわけだし
libaomのVP9は、どうやったら使えるの？
624:名無しさん＠編集中
19/12/08 14:27:59.22 0A33H+G50.net
実用範囲じゃなさすぎるな
x265でもまだまだなのに
625:名無しさん＠編集中
19/12/08 14:28:49.20 VK3lgY0IM.net
AviUtlとかでlibaom版VP9が簡単に使えるようになったら、フリーコーデック界のパワーバランスが変わるような気もしてきた…
626:名無しさん＠編集中
19/12/08 14:42:02.88 T1o7rnTJF.net
VP9なんてGoogleからするとオワコンだろうに
もはや広める気もないと思われる
627:名無しさん＠編集中
19/12/08 14:54:00.73 EVrDoL7j0.net
>>623
libaomじゃなくてlibvpxのVP9ね
AviUtlから使いたいならrigaya氏のFFmpeg出力プラグインを使えばいいんじゃないかな
628:名無しさん＠編集中
19/12/08 15:26:28.35 GwYqJuD+F.net
>>614
>待て待て待て…
>x265のveryslow設定の7000kbpsとlibaomの2pass設定の4200kbpsが同等品質ならば大きな違いだろ
その比較の仕方は意味なくね？
同じビットレートで比較しないと
1000kbpsのとき、H.265のvery slowはおそらくVMAF82%程度。
一方、libaomの2passは87.5％なので、劇的な差はないと言えなくもない。
629:名無しさん＠編集中
19/12/08 15:33:25.14 Qdn1BZm20.net
保存用高画質エンコしたい勢と
配信用に画質保ちつつ容量削りたい勢で感じ方が違うと思われ
630:名無しさん＠編集中
19/12/08 15:39:12.25 mvLzToO20.net
>>626
AV1がスマホでスムーズに再生されるようになるまでのつなぎにはなるんじゃね？＞VP9
631:名無しさん＠編集中 (ｱｳｱｳｸｰ MM41-+jgB)
19/12/08 16:25:31 VK3lgY0IM.net
>>627
そんなのがあるんだ!
年末年始の休みにでも試してみるかな
そろそろ貯まってきた4K放送の録画番組を再圧縮してある程度のサイズに収めたいので
632:名無しさん＠編集中
19/12/08 19:48:03.30 +46we6Op0.net
>>622
AV1ってx265の32倍くらい時間掛かるイメージだったけど
veryslowでも6倍程度で済むのか
3950Xが届いたら試しに使ってみるか
633:名無しさん＠編集中
19/12/08 20:22:54.80 am5UoeA80.net
URLﾘﾝｸ(code.videolan.org)
>dav1d 0.5.2 'Asiatic Cheetah', the fast and small AV1 decoder
>
>This is a minor update of the 0.5.x version of dav1d, the fast and small AV1 decoder,
>codename 'Asiatic Cheetah'.
>It supports all the AV1 features and all bitdepths.
>
>0.5.2 brings improvements in speed for ARMv7 CPUs (a few % speedup),
>on top of the already big speedups of 0.5.1. It should also improve the speed for large videos on all platforms.
>
>It also fixes minor issues, brings stability and introduces an OBU demuxer.
634:名無しさん＠編集中
19/12/08 21:38:06.01 OgEyi3zTM.net
>>633
「already big speedups of 0.5.1. 」
ホンマかいな…
635:名無しさん＠編集中 (ｱｳｳｨﾌW FFa9-gL3d)
19/12/11 14:42:44 GqpQHXBmF.net
ここにいる人はコーデック好きみたいだけど何に使っているのですか？
636:名無しさん＠編集中
19/12/11 15:06:54.12 9h2kjqa70.net
ご自分からどうぞ
637:名無しさん＠編集中
19/12/11 15:08:22.56 GqpQHXBmF.net
自分はYOUTUBEみているだけなので普段は気にしていないのよね
638:名無しさん＠編集中
19/12/12 08:45:40.47 6OyhHLhLa.net
webRTC周りの開発してるからそれに関連してコーデックも調べてるだけよ
639:名無しさん＠編集中
19/12/13 21:54:05.52 D5M5oBtg0.net
ふたば常駐なのとAV1/VVC待ちなのもあって最近は2MB以下でブラウザ表示できるVP9がメインだな
URLﾘﾝｸ(f.easyuploader.app)
ただaviutlのL-SMASH-WorksでVP9が正常に読み込めないのがつらい
調べたら一年以上問題放置されてた
URLﾘﾝｸ(github.com)
640:名無しさん＠編集中
19/12/14 01:01:26.49 SinY0dJl0.net
AV1はもうブラウザ表示できるやろ
641:
19/12/17 13:16:46.62 CSnefgsHM.net
>>454
別に8k自体は余裕だろう
そこにどれほどの情報を詰め込めるか
8kのビットマップが出せようとそれが8kないと表現できない絵かは別
>>557
研究はすでに十分に行われてる
開発が致命的
画期的な新技術も研究だけされて良い成果が出ても論文ぽいっと投げ出されて終わり
それを誰も読まない
開発者はほとんどいないし、その僅かな開発者もすごい研究成果があったことには気づかずすでに知られた技術でつまらないものを作って終わり
>>599
PGFはどうなった？
>>601
PDFの画像を表示できることからも分かる通り、すでにブラウザにはJPEG 2000デコーダがある
URLﾘﾝｸ(github.com)
JPEG 2000に対応しない今の理由は知らない