次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】

1 ：名無しさん＠編集中 ：2019/01/30(水) 16:23:41.40 ID:Amc+t7YI0.net

H.264/AVCの後の様々なビデオコーデック全般について語るスレです。

■主な次世代ビデオコーデック
・H.265/HEVC
・VP9
・AV1(AOMedia Video 1)
・VVC(Versatile Video Coding)

■前スレ
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
https://mevius.5ch.net/test/read.cgi/avi/1532001049/

次スレは>>980が宣言してから立ててください。

40 ：名無しさん＠編集中 ：2019/02/02(土) 09:14:23.45 ID:ap96XOP400202.net

コーデックもそうだけど、動画まわりのAPIもどうにかしてほしい。もっと洗練されたクロスプラットホームなやつを..

41 ：名無しさん＠編集中 ：2019/02/02(土) 09:20:32.11 ID:ap96XOP400202.net

windowsにしたって>>35は古いDirect ShowフィルタじゃなくてMedia Foundation用のコーデックだろ。MS純正のアプリはMedia Foundationに移行してると思うが、サードパーティーでMedia Foundation使ってるるプレイヤーってそんなにあるのか?

42 ：名無しさん＠編集中 ：2019/02/02(土) 10:20:10.48 ID:9GtYyRas00202.net

>>41
MS純正のアプリ使わないならLAV Filtersで事足りるからなあ・・・
MediaFoundationを意識するプレーヤーなんてQonohaくらいしか知らん・・・

43 ：名無しさん＠編集中 ：2019/02/02(土) 14:10:34.69 ID:D/xLMf4k00202.net

動画APIがクロスプラットホームである必然性なんて微塵もない
何をやってもHDTVとPCのガンマを同一と見做して変換してくれない糞プレイヤーが多いままなのは永久に変わらない

44 ：名無しさん＠編集中 ：2019/02/02(土) 14:44:40.78 ID:aFta9TSt00202.net

動画がらみのAPIがクロスプラットフォームじゃなかったら、ffmpegがanroidかwindowsかどちらかでしか動かないくなるんだけど。
vlcやらも大変。
ffmpegのlibavやらlibavformatやらがクロスプラットだから、後はUIのがわをだけ作ればいいように楽できるんだけど。
libavとかカオスだし、gstreamerはまだましっぽいけど。

45 ：名無しさん＠編集中 ：2019/02/02(土) 16:53:26.63 ID:vK/dsrFX00202.net

Direct Showは、いずれ廃止になるんだから、さっさと移行しろよとは思うが、動画の世界は古い技術にしがみつきたがるやつが少なからずいるのが癌ではある

46 ：名無しさん＠編集中 ：2019/02/02(土) 17:45:38.98 ID:T79ZNPze00202.net

AV1拡張入れてもWin10のWMPでAV1動画が再生できなかったからMFとはまた別かと思ってた

47 ：名無しさん＠編集中 ：2019/02/02(土) 18:07:44.87 ID:9GtYyRas00202.net

BlueskysさんのDSF/MFT Viewer（DXVACheckerにも内蔵）を使うと
DSF(Direct Show Filter)やMFT(Media Foundation Transform)の一覧が見れるから見てみるといいかも。

　　https://bluesky23.yukishigure.com/DsfMftViewer.html
　　https://bluesky23.yukishigure.com/DXVAChecker.html

うちは>>38くらいしか入ってないけど、Media Foundationの方に
　　HEVCVideoExtension(デコーダ)
　　HEVCVideoExtensionEncoder(エンコーダ)
がある。
A's Video Converterで選べるMicrosoft H.265 Encoderは後者を使ってるのかな？

48 ：名無しさん＠編集中 ：2019/02/02(土) 19:58:30.95 ID:/bWEpySy00202.net

>>46
今は拡張でAV1をWMPで再生出来るよ

49 ：名無しさん＠編集中 ：2019/02/03(日) 18:57:43.50 ID:G3tuopsdM.net

宮廷ドラマ「H.265/HEVC華麗なる軌跡」
2014年、MPEG-LAがパテントプールのライセンスを発表
2015年、パテントプール分裂、HEVC Advanceが爆誕
2016年、Technicolor社がHEVC Advanceを脱退
2017年、第3のパテントプールVelos Mediaが爆誕
2018年、Technicolor社がパテントトロールInterDigital社に特許権売却
2019年、パテントトロールのBlackBerry社がVelos Mediaに参加←New!

50 ：名無しさん＠編集中 ：2019/02/03(日) 19:41:54.96 ID:+s7whyE60.net

こういう利権とかうるさいのって日本だけかと思ってたけど、やっぱ世界でも似たようなもんなんだなって思う

51 ：名無しさん＠編集中 ：2019/02/03(日) 19:48:22.00 ID:PcbhQglC0.net

利権じゃなくて権利でしょ

52 ：名無しさん＠編集中 ：2019/02/03(日) 19:54:37.87 ID:+s7whyE60.net

すまぬ、普通にミスった

53 ：名無しさん＠編集中 ：2019/02/03(日) 22:08:33.63 ID:NtUDTorS0.net

Intel Publishes Open-Source AV1 Video Encoder "SVT-AV1"
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-SVT-AV1
https://github.com/OpenVisualCloud/SVT-AV1

54 ：名無しさん＠編集中 ：2019/02/04(月) 00:33:40.50 ID:TmbI8WXSM.net

ライブ配信向けのエンコーダか
1080pで最低16GB必要とはなかなか重いね

55 ：名無しさん＠編集中 ：2019/02/04(月) 02:21:19.78 ID:xsb5jlVGH.net

AVIFはどうなってるのかな
なんかwebpより画質悪いみたいだけど

56 ：名無しさん＠編集中 ：2019/02/04(月) 09:28:21.48 ID:Xu3xYzG60.net

>>55
webpより画質悪いってどこの情報？

57 ：名無しさん＠編集中 ：2019/02/04(月) 10:42:54.67 ID:YcGRyN+W0.net

画質を気にするならJPEG 2000にしとけば？
HEIFもだけど動画のイントラ系は高画質寄りだとあまりメリットない

58 ：名無しさん＠編集中 ：2019/02/04(月) 14:00:27.36 ID:a6mZyw1tM.net

HEIFって4:4:4無いの?あるなら互換性を除けば非可逆で最もベターに思えるけど

59 ：名無しさん＠編集中 ：2019/02/04(月) 18:10:16.48 ID:FMV1aOYba.net

画質保ちたいならpng使うもんな
ほとんどの人はそれなりの画質で高圧縮を求めている

60 ：名無しさん＠編集中 ：2019/02/04(月) 18:13:52.22 ID:1ZEHsh7z0.net

J2Kボケボケやん

61 ：名無しさん＠編集中 ：2019/02/04(月) 20:49:39.69 ID:NDLJAyq00.net

>>55
VP8ベースのwebpよりVP9後継のAV1使ったAVIFが画質悪いの？

62 ：名無しさん＠編集中 ：2019/02/04(月) 20:57:35.55 ID:YcGRyN+W0.net

>>58
iOSで4:4:4 HEIFで保存するサードパーティアプリあるので、出来るといえば出来る
OSデフォルトのカメラは4:2:0だけど

63 ：名無しさん＠編集中 ：2019/02/04(月) 21:01:20.04 ID:YcGRyN+W0.net

何よりもクソなのはmacOS MojaveだとHEIF Losslessが追加されたのに実際は何かロスる。
たぶん4:2:0に変換された物がロスレスでコーディングされてるw

64 ：名無しさん＠編集中 ：2019/02/04(月) 21:23:33.84 ID:1ZEHsh7z0.net

4:4:4でもYUVだとロスりそうな気が
ロスレスならGBRでしょ

65 ：名無しさん＠編集中 ：2019/02/04(月) 21:56:36.06 ID:/p97F0zT0.net

>>64
10bit12bit使えるはずなのでそれら使えばロスらない
でもこの辺ちゃんと対応してるのかね

66 ：名無しさん＠編集中 ：2019/02/04(月) 22:22:30.61 ID:Wj0gSAPM0.net

>>62
そのアプリ名おせーて

67 ：名無しさん＠編集中 ：2019/02/04(月) 23:50:25.37 ID:YcGRyN+W0.net

>>66
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗

68 ：名無しさん＠編集中 ：2019/02/04(月) 23:57:07.24 ID:YcGRyN+W0.net

>>65
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける

ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ

69 ：名無しさん＠編集中 ：2019/02/05(火) 00:00:31.06 ID:qpF39z1a0.net

まだ言ってんのかよ

70 ：名無しさん＠編集中 ：2019/02/05(火) 00:12:50.73 ID:pAds7ycvM.net

>>63
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか

71 ：名無しさん＠編集中 ：2019/02/05(火) 00:16:21.96 ID:pAds7ycvM.net

>>68
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう

72 ：名無しさん＠編集中 ：2019/02/05(火) 21:39:18.83 ID:P6LvaH7m0.net

>>68
> 8bit深度のままロスレスYCoCg変換しててこれが正解

微妙な表現だけど、前スレ938での

　> ビット数増やすのも計算途中だけで良い
　> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる

といった書き込み内容も踏まえると、

　　「8bitのRGB」と「8bitのYCoCg」は相互に可逆変換できる

と考えてるように見えるけど、それは違う。

前スレが終わる直前
　　https://mevius.5ch.net/test/read.cgi/avi/1532001049/996
に書いたから見てないかもしれないけど、「8bitのRGB」を可逆変換するなら
YCoCg側は「10bitのYCoCg」か「Y8C9bitのYCoCg-R」が必要になる。

一般的に有用なのは後者の「Y8C9bitのYCoCg-R」。

73 ：名無しさん＠編集中 ：2019/02/05(火) 21:40:34.38 ID:P6LvaH7m0.net

>>68
YCoCgには、基本として「YCoCg」と「YCoCg-R」の2種類があって、FLIFが使ってるのは「YCoCg-R」。
元が「8bitのRGB」の場合は、「Yが8ビット、Co/Cgが9ビットのYCoCg-R」に変換して、それを圧縮している。
（「YCoCg-R」は、Co/Cgが1ビットずつ増えるけど、可逆性を持ち、かつ圧縮効率が良い）

YCoCg(-R)を入出力に使うH.264/H.265と違って、
FLIFは入出力はRGBで、内部計算でYCoCg-Rを使ってるだけかな。
符号なし整数にするんじゃなく、符号つき整数として扱ってるようで、
8bitRGBの場合、R/G/B/Y：0〜255、Co/Cg：-255〜255という値範囲で扱われてる模様。
　　https://flif.info/spec.html

74 ：名無しさん＠編集中 ：2019/02/05(火) 21:43:47.70 ID:P6LvaH7m0.net

>>68
H.264/H.265は「YCoCg」も「YCoCg-R」も規定されてるけど、

　　・x264/x265では
　　　　　色差の深度 = 輝度の深度 + 1
　　　というエンコード処理ができないはずなので、
　　　YCoCgの本命である「Y8C9bitのYCoCg-R」は使えない。
　　　対応しているエンコーダ/デコーダがあるかも不明。

　　・じゃあ非可逆になってしまうけど圧縮効率向上に期待して「8bitのYCoCg」を使うぜ！

　　　　　→他のYCbCrと同様に、400万色くらいしか表現できないよ。
　　　　　→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
　　　　　→4:4:4限定なら有用かもしれない。

（続く）

75 ：名無しさん＠編集中 ：2019/02/05(火) 21:44:40.11 ID:P6LvaH7m0.net

>>68
（続き）

　　・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！

　　　　　→でも8bitRGBをエンコするために10bitYCoCgを使っても
　　　　　　圧縮効率の向上はあまり期待できないらしい？
　　　　　→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
　　　　　→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
　　　　　→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
　　　　　→4:4:4限定なら有用かもしれない。

という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。

76 ：名無しさん＠編集中 ：2019/02/05(火) 21:46:56.32 ID:P6LvaH7m0.net

>>68
更に、仮に今後x264/x265で「Y8C9bitのYCoCg-R」が使えるようになったとしても、
H.264/H.265の規格では

　　・「YCoCg-R」が使えるのは4:4:4だけ。

と規定されている。

　　・4:4:4の可逆性確保および圧縮率向上

というメリットは得られるので、4:4:4のHEVCやHEIFの圧縮率の向上には有用かもしれないが、
4:2:2/4:2:0では使えないため、4:4:4動画が一般的にでもならない限り、
「YCoCg-R」が一般的に使われることもなさそう。

階調的には10bit/12bitのYCbCrで十分だし、視覚特性を踏まえたICtCpってのもあるみたいだし、
そのあたりを考えると、x264/x265等のエンコーダやデコーダが
わざわざ「YCoCg-R」に対応する可能性も低そうな気がする。
　
　
　
という感じでYCoCgについて調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。

77 ：名無しさん＠編集中 ：2019/02/05(火) 22:34:47.41 ID:kcdu/Wz7M.net

他所でやれ

78 ：名無しさん＠編集中 ：2019/02/05(火) 22:47:19.89 ID:6V1gF+qL0.net

いま他所でやるスレあるの？
立てるしかない感じ？

79 ：名無しさん＠編集中 ：2019/02/05(火) 22:48:50.52 ID:6jCbSgZp0.net

DTVなんでも雑談スレが必要やな

80 ：名無しさん＠編集中 ：2019/02/05(火) 23:42:04.96 ID:7723xQC20.net

いいよ。ここでやればいい。興味なければスルーするだけだし。

81 ：名無しさん＠編集中 ：2019/02/06(水) 03:03:43.65 ID:VH5w2eOWa.net

libvpxアップデート来てるやん
エンコードが速くなったらしい
テストはしてないけど

82 ：名無しさん＠編集中 ：2019/02/06(水) 19:52:42.18 ID:iiG25dOv0.net

>>81
https://github.com/webmproject/libvpx/blob/master/CHANGELOG

2019-01-31 v1.8.0 "Northern Shoveler Duck"

　・リアルタイムエンコやVOD用途のエンコードパフォーマンス改善を頑張ったよ。

　・VP9の制御機能の追加・改善をしたよ。主に SVC (Scalable Video Coding) 関連。

　・VP9の2パスエンコの品質が改善されたよ。--auto-alt-ref=1 で 4〜5% くらい。
　　（--auto-alt-ref=6 だと 5〜10% らしいけど、--auto-alt-ref=6 ってのはSVC関連だろうか？）

　・リアルタイムエンコードについて

　　　　・speed 7 が 5〜10% くらい改善されたよ。（速度なのか品質なのかよくわからんが多分速度？）

　　　　・スクリーンシェアリング用途で、シーンチェンジやスクロール時のエンコが改善されたよ。

　　　　・モバイルデバイス用に、新たに speed 9 が追加されたよ。speed 8 より 10-20% くらい速いよ。

　・その他のバグ修正もしたよ。

---
1.7.0 はもう1年以上前なのか。
　　2018-01-04 v1.7.0 "Mandarin Duck"

83 ：名無しさん＠編集中 ：2019/02/06(水) 19:55:49.59 ID:JqeU2ncy0.net

--auto-alt-ref=0が無効で1が有効だと思っていた。
6ってどういう意味だろう？

84 ：名無しさん＠編集中 ：2019/02/06(水) 21:53:37.56 ID:iiG25dOv0.net

>>83
自分もそう思って少しソースを調べてみたんだけど、VP8では確かにそうだった。

VP9だと、--auto-alt-ref に指定できる値の範囲が 0〜MAX_ARF_LAYERS(6) に変わって、
2以上を指定した場合は multi_layer_arf というコードが有効になるらしい。

マルチレイヤーAltRefFrameってことなんだろうけど、それがなんなのかはよくわからない。
レイヤーって概念はSVC関連のものかと思ったのだけど、コード見るとSVCでは機能しないとなってるし・・・。

vp9\encoder\vp9_encoder.c

// Is multi-arf enabled.
// Note that at the moment multi_arf is only configured for 2 pass VBR and
// will not work properly with svc.
// Enable the Jingning's new "multi_layer_arf" code if "enable_auto_arf"
// is greater than or equal to 2.
if ((oxcf->pass == 2) && !cpi->use_svc && (cpi->oxcf.enable_auto_arf >= 2))
cpi->multi_layer_arf = 1;
else
cpi->multi_layer_arf = 0;

85 ：名無しさん＠編集中 ：2019/02/07(木) 22:13:08.59 ID:iMx52KwE0.net

WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…

たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな

86 ：名無しさん＠編集中 ：2019/02/07(木) 23:26:22.97 ID:d8RmpIty0.net

他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする

87 ：名無しさん＠編集中 ：2019/02/07(木) 23:42:57.87 ID:2e3JOoGMM.net

>>85
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう

88 ：名無しさん＠編集中 ：2019/02/08(金) 01:02:09.44 ID:FaS5LOof0.net

>>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー

と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年〜2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う

89 ：名無しさん＠編集中 ：2019/02/08(金) 10:35:48.98 ID:gKQZNq7Y0.net

こっちのirfanviewとXnViewではちゃんとロスレスだった

90 ：88 ：2019/02/08(金) 12:31:27.20 ID:XHOMvMPc0.net

https://github.com/imagemin/cwebp-bin/releases
を使ってコマンドライン（-lossless -z 9 -m 6 -mt -q 100 -o）でupload.wikimedia.org/wikipedia/commons/e/e9/16777216colors.pngをlossless変換したところ
2.0.5から5.0.0まで全部同じ16777216色だった

コマンドラインでは Lossless-ARGB compressed size: ***** bytes と表示されているから
おそらくRGB32色空間での圧縮と思われる

>>89
もしやと思って管理者権限での起動でirfanview使って変換したら色数変わらずlosslessだった
windows10の変な機能で保存時に設定変えてもlossy75設定のまま保存されていたようだ

91 ：名無しさん＠編集中 ：2019/02/08(金) 14:10:24.35 ID:FV1S2pxEH.net

windowsの仕業だったのか
Macだとどうなるんだろ

92 ：名無しさん＠編集中 ：2019/02/08(金) 15:46:20.12 ID:VPVS1LK30.net

なぜに管理者・・と思ったけど
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？

93 ：88 ：2019/02/08(金) 17:55:01.22 ID:MBZGzkoC0.net

GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな

ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ

このスレ見といて本当によかった 詳しい人ありがとうございます

数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな

94 ：名無しさん＠編集中 ：2019/02/08(金) 18:21:05.40 ID:UlRVwGWHM.net

それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな…

95 ：名無しさん＠編集中 ：2019/02/08(金) 19:22:01.90 ID:2sJCbLwZ0.net

最新のAcrobat Pro DCでHEIC開けなかったわ
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`)

96 ：名無しさん＠編集中 ：2019/02/08(金) 22:12:26.58 ID:lsyg2RlG0.net

pngcrushで事足りてるな...
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全

97 ：名無しさん＠編集中 ：2019/02/09(土) 01:14:35.57 ID:Lkg2e27Z0.net

MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀)

98 ：名無しさん＠編集中 ：2019/02/09(土) 01:54:14.48 ID:zFwc7OdK0.net

PNG最適化ならzopflipngが今のところ一番縮むはず

99 ：名無しさん＠編集中 ：2019/02/09(土) 07:21:06.37 ID:SX96QM+v0.net

zopflipngのコマンドラインは残すチャンクを手動指定しないとメタデータを軒並み消される

100 ：名無しさん＠編集中 ：2019/02/09(土) 07:25:25.95 ID:SX96QM+v0.net

メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い

101 ：名無しさん＠編集中 ：2019/02/09(土) 12:01:23.04 ID:D1Bfgd9M0.net

HEIF画像拡張機能、なんかインストールできねえなと思ったら
　　Windows 10 バージョン 17763.0 以降 （October 2018 Update〜）
になっとるやないかい・・・。まだApril 2018なままのうちでは無理か・・・去年さっさといれとけばよかった。

102 ：名無しさん＠編集中 ：2019/02/09(土) 12:33:43.35 ID:zQjVjhb7a.net

>>98
ECTやpingoのほうが縮むぞ
圧縮速度も何倍も速いしメタデータも残る

103 ：名無しさん＠編集中 ：2019/02/09(土) 14:05:05.01 ID:d8jrAH5w0.net

> converted through FFmpeg v3.4.1’s use of the open source x265 HEVC encoder (MulticoreWare Inc., 2018) to a mathematically lossless bitstream with the following command:
>
> > ffmpeg -i reference.tif -preset veryslow -c:v libx265 \
> > -x265-params lossless=1 lossless_bitstream.265
>
> The x265 encoder’s lossless option disables rate control along with all quality metrics and bypasses both discrete cosine transforms (DCT) and quantization (MulticoreWare Inc., 2014). Additionally,
> it employs HEVC’s RExt Main 4:4:4 profile, Level-8.5 (Main tier).
https://journal.code4lib.org/articles/13746

https://pwiki.awm.jp/~yoya/?2018-01-25/HEIFでYUV444なら劣化しないみたいなこと書いてあったからぐぐってみたんだけど
たぶんオープンソースのFFmpegでRExt Main 4:4:4 profile, Level-8.5でlossless圧縮したら数学上で損失のない信号情報に変換されたよ〜
って書いてあると思うんだけど、YUV444ならlossless変換でも色情報間引かれたりしないんだろうか

104 ：名無しさん＠編集中 ：2019/02/09(土) 16:33:15.07 ID:C7mp2mR+0.net

>>103やってみたけどサイズがPNGより膨らむ上にirfanviewでも開けないしよくわかんないっすね…
jpeg2000より圧縮率高かったら置き換えられるかなと思ってたけど厳しそう

105 ：名無しさん＠編集中 ：2019/02/09(土) 19:50:32.09 ID:D1Bfgd9M0.net

>>103
> https://pwiki.awm.jp/~yoya/?2018-01-25/HEIFでYUV444なら劣化しないみたいなこと書いてあった

　> ・ロスレス(劣化しない圧縮)と透明度に対応してるので PNG の代わりになり得る。
>　　　ただし、YUV444 対応しないと RGB=>YUV変換で微妙に劣化する

これは、もうちょっと細かく書くと、

　・ロスレス(劣化しない圧縮)と透明度に対応してるので PNG の代わりになり得る。

　　　・ただし、8bitRGBをロスレス保存するには、
　　　　　　　　・Main4:4:4で8bitRGBを、「フルレンジ」「4:4:4」「--colormatrix gbr」 で保存。
　　　　　　　　・fullrangeフラグやcolormatrixを見て適切な色変換を行う。
　　　　　　　　・Main4:4:4は、heixブランドなのでその対応が必要。
　　　　　という条件を満たす必要がある。

　　　　・でも現時点での実装のほとんどは、heicブランド（MainおよびMain Still Pictureのみ）にしか対応していない。
　　　　　これは8bitYUV4:2:0限定なので、8bitRGBをロスレス保存することはできない。

という感じだと思う。

106 ：名無しさん＠編集中 ：2019/02/09(土) 21:44:49.69 ID:D1Bfgd9M0.net

■iPhoneのHEIFサンプル

　・形式
　　　プロファイル：　　　　　Main Still Picture(8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　 フル
　　　　fullrangeフラグ付与： あり
　　　RGB->YUV変換係数：　　　不明
　　　　colormatrix付与：　　 無し
　　　備考：
　　　　・画像は48枚の512x512のタイルに分割されて格納されており、
　　　　　そのタイルを横8枚、縦6枚で並べた4096x3072の絵を
　　　　　更にクロップして4032x3024にして1枚の画像を構成する仕組み。
　　　　・320x240のサムネイルと、Exif情報もあり。

■NOKIAのHEIFサンプル

　・形式
　　　プロファイル：　　　　　Main(8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　 リミテッド
　　　　fullrangeフラグ付与： なし
　　　RGB->YUV変換係数：　　　不明
　　　　colormatrix付与：　　 無し

107 ：名無しさん＠編集中 ：2019/02/09(土) 21:45:56.53 ID:D1Bfgd9M0.net

■GIMP v2.10.8のHEIF対応状況

　・対応しているのはheicブランド(MainまたはMain Still Picture)のみ。
　　Main4:4:4やMain10等はheixブランドなので非対応。

　・書き出し
　　　プロファイル：　　　　　Main (8bit YUV4:2:0)
　　　YUVレンジ：　　　　　　 フル
　　　　fullrangeフラグ付与： 無し　←★酷い
　　　RGB->YUV変換係数：　　　BT.601
　　　　colormatrix付与：　　 無し

　・読み出し
　　　問答無用でフルレンジBT.601だとして変換する。　←★酷い
　　　　fullrangeフラグ読み取り：　無し
　　　　colormatrix読み取り：　　　無し

　・備考
　　　・アルファチャンネルにも対応している。
　　　・NOKIAのHEIFサンプルはリミテッドレンジなので、
　　　　GIMPで読み込むとコントラストが低下した状態で読み込まれてしまう。
　
　
どいつもこいつもcolormatrixつけやしねえ・・・
デフォはBT.601として扱えとでも言うのだろうか・・・

108 ：名無しさん＠編集中 ：2019/02/09(土) 21:47:59.23 ID:PZ/1qvmK0.net

画像系のソフトって色域の管理できてないのが多いからねぇ
というか、そもそも色域管理の術を知らないんじゃないのかとさえ思う

109 ：名無しさん＠編集中 ：2019/02/09(土) 21:54:40.43 ID:7Ywj2Giu0.net

率直な質問だけどHEIXなHEIFって拡張子は.heixになるの？それとも.heif？

110 ：名無しさん＠編集中 ：2019/02/10(日) 00:05:13.79 ID:c1Tihcf60.net

次世代ビデオコーデックのスレで画像コーデックの話何時までやるの？
話題ついでレベルなら全然かまわんと思うけど
ゴリゴリ続けられてもちょっとな

111 ：名無しさん＠編集中 ：2019/02/10(日) 00:07:20.73 ID:eYWijAuK0.net

次世代画像コーデックスレが必要になってきた感じですかね

112 ：名無しさん＠編集中 ：2019/02/10(日) 00:19:13.56 ID:eskOjsHm0.net

HEIFやWEBPみたいに静止画と動画の変換コーデックに同じものが使われる傾向が続くと
将来的には「昔は静止画専用のコーデックがあってさ〜」みたいな話になるんだろうか

113 ：名無しさん＠編集中 ：2019/02/10(日) 00:19:54.07 ID:UraLMarw0.net

どんどん続けてOK。俺はどうでもいいかスルーするけど

114 ：名無しさん＠編集中 ：2019/02/10(日) 00:46:56.11 ID:4eTbMRSh0.net

>>109
.heic

　HEIF Technical Information - High Efficiency Image File Format
　https://nokiatech.github.io/heif/technical.html

115 ：名無しさん＠編集中 ：2019/02/10(日) 00:52:48.44 ID:fr2Lb9Px0.net

>>114
heixでも.heicなのか
サンクス

116 ：名無しさん＠編集中 ：2019/02/10(日) 01:22:36.25 ID:rS1Ref0Y0.net

低スペックマシン(Windows10/AMD E1-7010 APU/RAM4.0GB)でYouTubeを720p/AV1設定にして視聴したんだが感動を覚えた。
Dropped Frames 683/5960 11.5%位落ちてるけれどこんな低スペックPCでchromeブラウザのAV1デコーダー凄い軽さだなぁと。

117 ：名無しさん＠編集中 ：2019/02/10(日) 02:25:30.99 ID:KMjRffzw0.net

11.5%も落ちてたらダメだろ

118 ：名無しさん＠編集中 ：2019/02/10(日) 02:47:17.59 ID:wV54BB3g0.net

>>118のCPUってcine bench15 マルチコアで70しか出ないのかよ…ちなみに9900Kが2000ちょい
仮にスコア100でフルフレーム出るとすると4コアCPUでも4K画質のソフトウェアデコードギリギリ出来るな。
デコーダの並列度が高ければ。

119 ：名無しさん＠編集中 ：2019/02/10(日) 10:35:49.01 ID:rS1Ref0Y0.net

>>117
実際に落ちまくったのは最初の方やな。その後も落ちてたけど見られないほどひどくはない印象。

120 ：名無しさん＠編集中 ：2019/02/10(日) 10:46:48.45 ID:ItrmmZ/j0.net

シーンによって再生負荷が変動してる気がするんだが
再生負荷が高そうな動画だとどうなるんだろう

121 ：名無しさん＠編集中 ：2019/02/10(日) 13:56:38.44 ID:UraLMarw0.net

つか、デコード負荷って結構あるんだね。今まで馬鹿にしてたわ。
2Kから4Kになれば負荷4倍なのは分かりやすいけど最近2Kの30fpsのmpeg2動画とh.264の動画をFireHD10でCPUで再生したらmpeg2こんな軽いんだね...
h.264だと再生ギリだわ。

最新コーデックってのはエンコ側ですげぇ頑張って、デコード側は大した変わらないのかなと盲目的に思ってたわ。

122 ：名無しさん＠編集中 ：2019/02/10(日) 14:00:53.85 ID:KVIj63yp0.net

GPU支援とかの機能があったりするのはそういうのが有効な程度には負荷があるってことだしね

123 ：名無しさん＠編集中 ：2019/02/10(日) 14:45:02.12 ID:UraLMarw0.net

2Kの30fpsのmpeg2
HW L40% L40%
SW L50% L50% B50%
2Kの30fpsのAVC
HW L40% L40%
SW L60% L60% B70% B70%
2Kの30fpsのHEVC
HW L40% L40%
SW L90% L90% B100% B100%(かくかく)
android版VLC FireHD10 MT8173
LとかBはlittleコア、bigコアでアバウトなCPU使用率

124 ：名無しさん＠編集中 ：2019/02/10(日) 14:49:57.63 ID:rS1Ref0Y0.net

スマホにAV1/HEVC配信をするのってバッテリー面で大丈夫なのだろうか。

125 ：名無しさん＠編集中 ：2019/02/10(日) 16:11:58.54 ID:DGz5wh45d.net

HEVCは新しい比較的SoCだとAndroidでもiOSでもHWデコードできなかったっけ？AV1は負荷がかかるからバッテリー持ち悪そうではある

126 ：名無しさん＠編集中 ：2019/02/10(日) 17:11:24.75 ID:KVIj63yp0.net

なぁに糞重いゲームとかと比べると屁みたいなもんよ
まあ電気食わないに越したことはないんだけどさ

127 ：名無しさん＠編集中 ：2019/02/10(日) 17:57:13.49 ID:wV54BB3g0.net

AV1でリアルタイムエンコ出来るわけ無いだろ…

128 ：名無しさん＠編集中 ：2019/02/10(日) 18:07:19.31 ID:/y8PkD8C0.net

AV1はHWメーカーも入って検討してるんだし、HW実装さえされれば
ユーザ側は少なくともデコードについては特に心配せずに使えるんでないかい。

デコードはユーザーレベルまで普及するだろうけど、エンコードがどうなるかはまだわからんね。

129 ：名無しさん＠編集中 ：2019/02/10(日) 18:17:42.72 ID:rS1Ref0Y0.net

>>127
そこでH.264の出番!()

130 ：名無しさん＠編集中 ：2019/02/10(日) 21:56:54.41 ID:dLysR4Z60.net

AVCのデコードの重さはCore2Duo世代の年寄りにとっては当たり前の話みたいなもんだったけど
今の若い人には逆に新鮮なんだな

当時はSD画質でも体感負荷が倍くらいあったけど
今はマルチコアの並列化がこなれてきてるのかMPEG2で50%負荷→AVCで70%負荷程度しか変わらんのな

JPEG2000もそろそろパッと読み込まれるようになってもええんやで、と思ってググったら
FLIFとかいうロスレス規格も出てきてたんだなhttps://gigazine.net/news/20160308-flif/
完全に浦島太郎状態だわ

131 ：名無しさん＠編集中 ：2019/02/10(日) 22:11:41.46 ID:FlhgQQsYa.net

普及する見込みのないコーデック覚えても意味ないから知らなくていいよ

132 ：名無しさん＠編集中 ：2019/02/10(日) 22:21:26.62 ID:fr2Lb9Px0.net

J2Kは回路コストが高すぎるとかで普及しなかったらしいけどAV1はどうなんだろう

133 ：名無しさん＠編集中 ：2019/02/10(日) 22:30:34.47 ID:rS1Ref0Y0.net

テレビ局のエンコーダーでお馴染みのソシオネクスト君がやってはいるんだけどね。
https://www.socionext.com/jp/pr/sn_pr20180606_01j.pdf

134 ：名無しさん＠編集中 ：2019/02/10(日) 22:40:09.22 ID:v/4sZexS0.net

動画の帯域問題はプロバイダやサーバー事業者（サービス提供者）にとっては死活問題だから
YouTube（Google）とNetflixとPrime（amazon）とHuluが主導してる時点で意地でも普及させてくると思う

135 ：名無しさん＠編集中 ：2019/02/10(日) 22:59:30.12 ID:42DuUQLQ0.net

Ubuntu創業者Mark Shuttleworth自らキターーーッ
https://code.videolan.org/videolan/dav1d/merge_requests/577/commits

136 ：名無しさん＠編集中 ：2019/02/10(日) 23:31:02.97 ID:42DuUQLQ0.net

Mark Shuttleworthこっちにも来てたw
https://github.com/OpenVisualCloud/SVT-AV1/pull/38
インストール、アップデートがめちゃらくになる

137 ：名無しさん＠編集中 ：2019/02/11(月) 05:29:56.58 ID:xK0vAipo0.net

大御所が来るとワクワクするなぁ

138 ：名無しさん＠編集中 ：2019/02/11(月) 12:18:12.82 ID:SadaeFgt0.net

>>130
DVD見るためにセレロン300AをOCしていた思い出・・・

139 ：名無しさん＠編集中 ：2019/02/11(月) 14:37:09.21 ID:xK0vAipo0.net

再エンコードとかなかった頃のニコニコ動画で再生負荷高くて再生できないなんてことがクソスペックであったからなぁ
逆に再生負荷あげられまくれるからベンチマークなんてのあったし

140 ：名無しさん＠編集中 ：2019/02/11(月) 14:49:32.71 ID:rdXGmVRF0.net

YouTubeの720p/AV1はそこそこ普通に見られるのにニコニコ動画のHTML5プレーヤーは止まりまくるの草