次世代ビデオコーデック総合スレPart3 【HEVC/VP9/AV1/VVC等】
■ このスレッドは過去ログ倉庫に格納されています
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が宣言してから立ててください。 >>66
デュアルレンズiPhone専用で高額レンズのシミュレーションを行うFocosっていうアプリ
この手のアプリでは圧倒的なクオリティで専用ハードを使うLight L16より綺麗 >>65
ロスレスで深度深くしたらRGBのままより圧縮効率落ちる。つまり、ただのzip圧縮と変わらないPNGに負ける
ロスレス最高効率のFLIFは8bit深度のままロスレスYCoCg変換しててこれが正解。HEVCだってYCoCgに対応してるのにやらない所がクソなんですよ >>63
422から420って、色の2が0にロスってるけどw
それロスレスって言っていいのか >>68
なるほどぉー
これは勉強になった
RGBよりdeep色向けな最適化軸が
YCoCgなのかな？
ぐぐって勉強してみよう >>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」。 >>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 >>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限定なら有用かもしれない。
（続く） >>68
（続き）
・じゃあ可逆性を重視して「10bitのYCoCg」を使うぜ！
→でも8bitRGBをエンコするために10bitYCoCgを使っても
圧縮効率の向上はあまり期待できないらしい？
→「8bitのRGB」をそのままエンコードした方が圧縮効率が良いのでは？
→「10bitのYCbCr」も8bitRGBと可逆性があるはずだし、そっちでもいいのでは？
→また、YCoCgは、4:2:2や4:2:0では圧縮効率の向上はあまり期待できないらしい？
→4:4:4限定なら有用かもしれない。
という感じで、現状実用できる範囲ではあまりメリットが無さそうな感じ。 >>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について調べたことをまとめて連投してみたのだけど、
理解が正しいかよくわからんとこもあるので、指摘があればよろしくたのんます。 いいよ。ここでやればいい。興味なければスルーするだけだし。 libvpxアップデート来てるやん
エンコードが速くなったらしい
テストはしてないけど >>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" --auto-alt-ref=0が無効で1が有効だと思っていた。
6ってどういう意味だろう？ >>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; WEBPでPNGをロスレス変換したときのファイルサイズの減少率に感動して
HEVC？HEIF？の可逆にも挑戦してみようかと色々ググってたけど
「8bit/10bit YCbCr色空間内での可逆(RGB24/32ではない)」になるのか…
たぶん8bitYUVでも気付けるような色彩感覚は持ってないだろうけど
音質も耳がいいわけでもないのに最近までロスレス厨だったからちょっと悩ましいな 他人エンコならAAC128でも気にしないけど自分エンコの320とWAVは異様に気になって識別しちゃうみたいな所あるよね。
圧縮形式や圧縮率なんてビットレートで裏返るもの(色空間は裏がえらんが)個人では精神衛生上の問題にしかならないから妥協出来るなら妥協する、妥協しないなら絶対しないでいいと思う。
どうせ情熱無くなれば無難なもの、例えば今ならx265 veryfastなどを何の葛藤もなく選択するだけになるだろうから悩める時に好きなだけ悩んだり調べた方が楽しい。
でもやっぱ色空間は妥協出来んな…プロファイル合っててもモヤモヤする >>85
WebPのロスレス、実はロスレスじゃないという話があるけどどうなんだろう >>87
はてなブログの画像比較すると色数が違ってたけど
2013年末に自分がirfanviewで変換したpng->webp losslessは今比較しても色数同じだったから何かが違うんだろうなー
と思って手持ちのPNGを最新のirfanviewで変換してみたら色数変わったファイルが出てきたわ
たぶん2014年〜2016年の間にlosslessでもlosslessにしない仕様に変えたんだと思う こっちのirfanviewとXnViewではちゃんとロスレスだった 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設定のまま保存されていたようだ windowsの仕業だったのか
Macだとどうなるんだろ なぜに管理者・・と思ったけど
圧縮率の情報をレジストリにでも書き込む仕様なんだろうか？ GIMPでHEIF/HEIC保存できるのを知って>>90の16777216色画像でlossless変換してみたけど
3962905色まで間引きされてたわ
RGB24->YCbCr8bitに変換時の減り方だな
ファイルサイズもWEBPの181kB->12.7kBに対して12MBまで膨れ上がってたし
少なくとも現時点のバージョンでlossless厨の自分がHEIF/HEICのお世話になることはなさそうだ
このスレ見といて本当によかった 詳しい人ありがとうございます
数年ぶりにバッチ作ってPNG->WEBPlosslessに変換しまくってるけど
25%程度とは言え塵も積もればだからやっぱ気持ちいいな それほど大量にPNGを扱っているなら場合によってはBMPにして7zとかzpaqなどのアーカイブに放り込む方が縮むかもしれない
その場合というのは差分ありCGぐらいなんだが…差分が多ければPNGの1/10以下、条件か良ければ1/50以下になることもザラにあるよ。
HEVC等のRGB可逆で圧縮しておいて必要時に画像として出力するなんて方法も考えたことあるけど流石にな… 最新のAcrobat Pro DCでHEIC開けなかったわ
PDFってまだHEIF埋め込める仕様になってないん?(´･ω･`) pngcrushで事足りてるな...
(もっと効率良いPNG再圧縮プログラムもあるけど、デフォルトでメタデータが保持されない物が多いのでpngcrushが安全 MicrosoftのHEIF画像拡張機能を入れてテストしてみようとしたら
「Microsoftアカウントじゃないとインストールさせねえよ？」と言われたでござる。(´・ω・｀) PNG最適化ならzopflipngが今のところ一番縮むはず zopflipngのコマンドラインは残すチャンクを手動指定しないとメタデータを軒並み消される メタデータまで含め非破壊で安全である事と、速度と圧縮効率のバランスの良さでpngcrushの標準(-bruteとか指定しないで普通に使う)は使い勝手が良い HEIF画像拡張機能、なんかインストールできねえなと思ったら
Windows 10 バージョン 17763.0 以降 （October 2018 Update〜）
になっとるやないかい・・・。まだApril 2018なままのうちでは無理か・・・去年さっさといれとけばよかった。 >>98
ECTやpingoのほうが縮むぞ
圧縮速度も何倍も速いしメタデータも残る > 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変換でも色情報間引かれたりしないんだろうか >>103やってみたけどサイズがPNGより膨らむ上にirfanviewでも開けないしよくわかんないっすね…
jpeg2000より圧縮率高かったら置き換えられるかなと思ってたけど厳しそう >>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をロスレス保存することはできない。
という感じだと思う。 ■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付与： 無し ■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として扱えとでも言うのだろうか・・・ 画像系のソフトって色域の管理できてないのが多いからねぇ
というか、そもそも色域管理の術を知らないんじゃないのかとさえ思う 率直な質問だけどHEIXなHEIFって拡張子は.heixになるの？それとも.heif？ 次世代ビデオコーデックのスレで画像コーデックの話何時までやるの？
話題ついでレベルなら全然かまわんと思うけど
ゴリゴリ続けられてもちょっとな 次世代画像コーデックスレが必要になってきた感じですかね HEIFやWEBPみたいに静止画と動画の変換コーデックに同じものが使われる傾向が続くと
将来的には「昔は静止画専用のコーデックがあってさ〜」みたいな話になるんだろうか どんどん続けてOK。俺はどうでもいいかスルーするけど >>109
.heic
HEIF Technical Information - High Efficiency Image File Format
https://nokiatech.github.io/heif/technical.html >>114
heixでも.heicなのか
サンクス 低スペックマシン(Windows10/AMD E1-7010 APU/RAM4.0GB)でYouTubeを720p/AV1設定にして視聴したんだが感動を覚えた。
Dropped Frames 683/5960 11.5%位落ちてるけれどこんな低スペックPCでchromeブラウザのAV1デコーダー凄い軽さだなぁと。 >>118のCPUってcine bench15 マルチコアで70しか出ないのかよ…ちなみに9900Kが2000ちょい
仮にスコア100でフルフレーム出るとすると4コアCPUでも4K画質のソフトウェアデコードギリギリ出来るな。
デコーダの並列度が高ければ。 >>117
実際に落ちまくったのは最初の方やな。その後も落ちてたけど見られないほどひどくはない印象。 シーンによって再生負荷が変動してる気がするんだが
再生負荷が高そうな動画だとどうなるんだろう つか、デコード負荷って結構あるんだね。今まで馬鹿にしてたわ。
2Kから4Kになれば負荷4倍なのは分かりやすいけど最近2Kの30fpsのmpeg2動画とh.264の動画をFireHD10でCPUで再生したらmpeg2こんな軽いんだね...
h.264だと再生ギリだわ。
最新コーデックってのはエンコ側ですげぇ頑張って、デコード側は大した変わらないのかなと盲目的に思ってたわ。 GPU支援とかの機能があったりするのはそういうのが有効な程度には負荷があるってことだしね 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使用率 スマホにAV1/HEVC配信をするのってバッテリー面で大丈夫なのだろうか。 HEVCは新しい比較的SoCだとAndroidでもiOSでもHWデコードできなかったっけ？AV1は負荷がかかるからバッテリー持ち悪そうではある なぁに糞重いゲームとかと比べると屁みたいなもんよ
まあ電気食わないに越したことはないんだけどさ AV1はHWメーカーも入って検討してるんだし、HW実装さえされれば
ユーザ側は少なくともデコードについては特に心配せずに使えるんでないかい。
デコードはユーザーレベルまで普及するだろうけど、エンコードがどうなるかはまだわからんね。 AVCのデコードの重さはCore2Duo世代の年寄りにとっては当たり前の話みたいなもんだったけど
今の若い人には逆に新鮮なんだな
当時はSD画質でも体感負荷が倍くらいあったけど
今はマルチコアの並列化がこなれてきてるのかMPEG2で50%負荷→AVCで70%負荷程度しか変わらんのな
JPEG2000もそろそろパッと読み込まれるようになってもええんやで、と思ってググったら
FLIFとかいうロスレス規格も出てきてたんだなhttps://gigazine.net/news/20160308-flif/
完全に浦島太郎状態だわ 普及する見込みのないコーデック覚えても意味ないから知らなくていいよ J2Kは回路コストが高すぎるとかで普及しなかったらしいけどAV1はどうなんだろう 動画の帯域問題はプロバイダやサーバー事業者（サービス提供者）にとっては死活問題だから
YouTube（Google）とNetflixとPrime（amazon）とHuluが主導してる時点で意地でも普及させてくると思う Mark Shuttleworthこっちにも来てたw
https://github.com/OpenVisualCloud/SVT-AV1/pull/38
インストール、アップデートがめちゃらくになる >>130
DVD見るためにセレロン300AをOCしていた思い出・・・ 再エンコードとかなかった頃のニコニコ動画で再生負荷高くて再生できないなんてことがクソスペックであったからなぁ
逆に再生負荷あげられまくれるからベンチマークなんてのあったし YouTubeの720p/AV1はそこそこ普通に見られるのにニコニコ動画のHTML5プレーヤーは止まりまくるの草 >>138
パソコンでDVD 見たいなら再生支援チップが載ったグラボ買った方が良いよ！な時代やな CPUなに使ってるか書いてなかった
Ryzen 5 2400Gです >>142-143
乙です。
・SVT-AV1、libaom、rav1e、libvpx VP9、x265、x264のVMAFでの比較評価。（重い設定での比較）
・全体的にlibaomが良好、その次にx265とlibvpx VP9。
・SVT-AV1はその次くらいで、rav1eと同等かそれ以上。
ってところかな。そしてやっぱりAV1は重い。 AV1がすごい、HEVC/VVCがすごい以前に2つの参加企業見比べたらAV1がVVC潰しに掛かっているような構図にしか見えない。 同じAV1でもlibaomとSVT-AV1、rav1eでは別物クラスの違いがあるね
libaomは低ビットレートでの改善具合がすごい
ただ、重いんだろうなぁw
問題は、高解像度映像でどの程度の改善があるのか
libaom使って4Kをエンコードした場合に、HEVCより3割以上縮むのならば、4K放送の当面の保存用に考えなくもないが…
（4Kは保存場所がどうしても消費してしまうし、画質落とした4Kを保存するくらいならば2Kでいいだろとすらなってしまうのがイタい） >>145
「参加企業」つってもHEVCの参加企業と言ってるのはライセンスを保持する企業群のことだろうし、
AV1(AOM)の参加企業は「HEVCのライセンスは内容も複雑さもクソ」って企業が集まったってだけでしょ。
別にVVCを潰すなんて意図はないし、VVCでHEVCのクソライセンスの悲劇を繰り返さないためにMC-IFって組織も立ち上げられてる。 VVCがAV1より良い出来で、ライセンスが分かりやすくなったらそっちに鞍替えする企業も出てくるのだろうか VVCはAV1を超えてくるだろうね
単純に後発なのもそうだしAV1はmpegが今まで積み上げてきた特許回避しなきゃならないから
それにライセンスも今回は慎重にいくみたいだし
まあAV1はmpeg帝国に対するけん制みたいな面もあるしあんまcodec戦争とか言われるようなもんじゃないのかもね libaom凄いな
3000kbpsでもうほぼソース画質に近くなるのか
そりゃ動画配信企業はお熱になりますわ >>150
俺も別スレでグラフ出しただけでrigaya氏扱いされたことがあるけど、
匿名掲示板で名乗りもしてないレスに対して「〇〇さん乙です」みたいな人物特定するような書き込みをするのは
結構気色悪い行為だからやめたほうがいいと思うよ。的外れなら尚更。 >>153
その後同じグラフをブログに掲載すんだからバレバレじゃん 氏がこのスレかソース元サイトを見てるって事でしょ。
アンテナ張ってる先は同じなんだからさ。まずここ特定板じゃねえし、特定厨は邪魔だから帰って ネトゲで「お前同じクラスの〇〇だろ！キャラの顔があいつに似てる！」と叫んでる人を見てる気分。 もしかしてグラフ作るのが技術的に物凄く難しくてrigaya氏みたいな人じゃないと出来ないと思ってる？
libreOfficeみたいなフリーのオフィスソフトでも簡単に作れるんだけどな ところで、libaomとはどうやって使うものなの？
あと、これを使ってエンコードしたものをまともに再生しようとした場合に、ハードウェア再生支援の存在しない現状で要求されるハードウェアスペックとはどの程度なのだろうか？
エンコードを時間かけてやってもまともに再生できないようではさすがにつらすぎるし Google Cloud Platformの仮想Windowsでエンコードから再生までやってる。音声と映像のラグが酷いけど。 ffmpegとLAV Filtersでエンコードもデコードもできるんだから1:30くらいの動画を試しに変換してみればいいじゃん
と思って検索掛けてみたらAV1の画像フォーマットもAVIFも策定されてきてるんだな
https://people.xiph.org/~negge/AVIF2018.pdf
前に見つけたFLIFはJPEG2000よりさらに2倍近く読み込み時間が必要だったからwebpの後継として期待したい >>162
FFMpegでエンコードするときの使い方をわかりやすく解説した資料とかないかな？ GUI公開されてるの幾つかあるけど、やっぱ個人で実用的に使うのはまだ先になりそうだねー
設定項目多すぎるよ >>163
基本的なのはffmpegのページに載ってる
現状での再生スペック測る程度なら充分かと
https://trac.ffmpeg.org/wiki/Encode/AV1 ■ このスレッドは過去ログ倉庫に格納されています
