birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

いやーSVT-AV1(ffmpegではlibsvtav1)、すごいじゃじゃ馬だ。rootで起動すると問答無用でSCHED_FIFOの優先度最高に設定する、って話を書いたけど、chrtでSCHED_OTHER、nice値19に落としてもCPUを食べまくり、shのレスポンスが悪くなるほど。 (20:01 bskyから・詳細)

これだけCPUを使い切れる、ってのは逆にすごいことなんだろうね、確かにlibx254と比較すると同等画質で効率倍(ファイルサイズ半分)くらいに圧縮できるのにエンコード時間はむしろ早いくらいだったりする。 (20:03 bskyから・詳細)

libsvtav1の主要なparameterはcrfとpresetだけど、前者が主に画質とファイルサイズの、後者がファイルサイズとエンコード速度のトレードオフになるように動くので非常に調整がしやすい。正確には後者でも画質は変わるし前者でも速度は変わるんでしょうが… (20:05 bskyから・詳細)

あまりにSVT-AV1にCPUを使われすぎて他のprocessの動作に支障が生じるので、-svtav1-paramsオプションでlp=4:pin=1を指定してSVT-AV1が使うCPU coreを制限することに。今使っているRyzen 5 3550Hは4C8Tなので半分ですね。 (20:08 bskyから・詳細)

image 0lp=LogicalProcessorで利用する論理プロセッサ数を指定、pin=1はSVT-AV1が利用するcoreを固定する指定で、これがないと公式Docにあるように結局lpで指定した以上のプロセッサが使われてしまう。 https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md#:~:text=so%20%2Dlp%204,the%20memory%20usage (20:11 bskyから・詳細)

利用する論理プロセッサ数を半分に制約してもエンコード速度が半分になるわけではなく、preset=8を指定していたところをpreset=10にする、くらいで吸収できます。まぁファイルサイズと画質が多少犠牲になりますが… (20:13 bskyから・詳細)

ここのところAV1でいろいろな動画をエンコードしてみているけれど、古いH.264と比べるとbitrateの振れ幅が大きいのが印象的。テレシネソースとかあまり動きのない動画なら1080/60i→60pへの変換で2Mbpsくらいになったりするのに、(続) (20:15 bskyから・詳細)

native 60iな動画だと8~10Mbpsくらいまで膨らむことも。H.264だとそこまで増減しなかったので、アルゴリズムが進化してハマる動画にはハマる、って感じなのかな。ちなみにあまり圧縮の効かない動画の傾向はまだつかめない。意外な動画が全然圧縮できなかったりする。 (20:17 bskyから・詳細)

birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

そういやffmpegのfieldmatchフィルタと組み合わせるdeinterlaceフィルタ、改めてyadifとestdifを比べてみたんだが、やっぱり僕はyadifの方が好き。確かに斜め線の補間はestdifの方がうまい気がするけど、yadifの方が時間軸方向に安定してるのと圧倒的に軽いのが良い。 (00:14 bskyから・詳細)

朝っぱらから気になってSVT-AV1のソースコードを読んでいたんだが、rootで実行すると無条件にSCHED_FIFO、priority=99に設定するようで、param等での抑制も不可能な模様(汗。こっちから直すならソースにパッチ当てちゃうのが早そう。 (08:03 bskyから・詳細)

birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

最新のffmpeg 6.1.1+SVT-AV1 1.8.0を使い始めているんだが、この組み合わせだとnice値を19に設定していてもschedのpriorityが最強の「rt」なっていて他の(time criticalな)プロセスを阻害することがあることが分かった。 (20:19 bskyから・詳細)

で、どうもffmpegは起動後にsched priorityを更新しているようで、起動時にchrtしても効かない。仕方がないので起動後1秒待ってからchrt -o -p 0 ${pid}する、みたいな泥臭い方法で対処することに。うぅむもっとスマートできないものか。 (20:22 bskyから・詳細)

連休中ぜんぜんSNS見てなくて、はて？何してたっけ…と思い出してみたら、ハイキュー!!の劇場版は見たしスプラ3のSide Orderはやったしffmpeg最新版+SVT-AV1と戯れたしと結構充実したお休みじゃった。良き。 (23:59 bskyから・詳細)

birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

入力が60iなソースであると分かっているなら最初のdejudder+fps filterは不要かな。さっき手元のffmpeg containerを最新のffmpeg 6.1.1+SVT-AV1 1.8.0に更新したら余計なwarningが減った。もう少し最適なcrf/presetを追い込んでみよう。 (11:42 bskyから・詳細)

ウチのRyzen 5 3550Hな環境だとlibsvtav1のpreset=6はlibx264のpreset=slowerの半分以下くらいの速度になっちゃうのでさすがに厳しいな。preset=8でだいたい同じくらい、かな(だいたい1/4～1/5倍速くらいのエンコードスピード)。 (11:57 bskyから・詳細)

同じソースをcrf=30固定でpreset=6、8、10でエンコードした結果はそれぞれ46.0MB、48.2MB、51.2MBで、5%ずつくらい小さくなっているけれど、エンコードにかかった時間に見合うか、というと微妙なところ。preset=10だとlibx264のslowerより速いくらいだな… (12:11 bskyから・詳細)

今度はpresetの方を10に固定してcrfを30、32、34と変えてみると、エンコード後のファイルサイズはそれぞれ51.2MB、45.2MB、40.3MBで結構大きくサイズが減る。crf=34でも今テストに使ってるソースだと家のTVで見ても全然劣化を感じない(汗。SVT-AV1優秀だな… (12:24 bskyから・詳細)

ちなみに元の1080/60iのH.264素材は75.9MBくらいあるので、さすがにH.264と比べるとAV1は効率よいですね。Fire TV Cube(3rd gen)だと1080/60pなAV1素材でも全く問題なく再生出来るので本格的に移行したくなってきたゾ… (12:27 bskyから・詳細)

YouTubeで確認してみると、4K/60pなAV1動画もサクサク再生してますね＞Fire TV Cube(3rd gen)。パワフル。 (12:40 bskyから・詳細)

そういや、AndroidがOSレベルでフレームレートマッチング可能になったのはAndroid 12かららしく、Fire TV Cubeの最新Fire OS 7はAndroid 9ベースなのでそちらはまだ未対応なんですね。 (14:08 bskyから・詳細)

とするとFire OS側にある「コンテンツのフレームレートに合わせる」設定はおそらくAmazonの独自実装で、そうであれば自社のPrime Videoアプリしか対応していないのも納得。 (14:10 bskyから・詳細)

ちょっと古いdebign buster上で最新のSVT-AV1&ffmpegをbuildしようとするとcmakeが古いと怒られるので仕方なくsourceからinstallするのだが、cmakeのbuildに一番時間がかかるよ…ぐぬぬ。 (14:17 bskyから・詳細)

birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

この話、単純に -vf “fieldmatch=combmatch=full,yadif=1:-1:1” みたいに組み合わせるだけだと、テレシネソースにおいては1)fieldmatchが30p(1234456788)に変換、2)yadifがそれを2倍にして60pに変換するので、(続) (19:16 bskyから・詳細)

60pにした時のフレーム構成が2-3ではなく2-2-2-4になってしまう。うぅむ。 それにしても巷の情報は60i→24pに戻す、という例ばかりで、元24pのテレシネソースや30p、60iのソースが混在する60iなvideoを情報量最大で変換するなら60pにするのが正解だと思うんだが… (19:21 bskyから・詳細)

それはともかく、上記「24pや30p、60iなソースが混在する60iなvideoをできるだけ綺麗に60pに変換する」という問題をffmpeg filterで解く場合、とりあえず次の設定が正解っぽい。(続) (19:22 bskyから・詳細)

-vf “dejudder,fps=30000/1001,fieldmatch=combmatch=full,decimate=mixed=1,yadif=1:-1:1,fps=60000/1001” ↑こんな感じ。最初のdejudder、fps filterは単にソースを60iに揃えているだけ、 (19:24 bskyから・詳細)

fieldmatchでソースがテレシネ or 30pの場合は綺麗に30pになり60iならinterlace flagが残る、その後のdecimate filterでは30p化出来た時に重複フレームがあれば削除して24p化(30pやinterlace flag付きのフレームはそのまま)、 (19:27 bskyから・詳細)

でその後yadifがinterlace flag付きフレームについてはdeinterlace処理をしつつフレームレートを2倍にして(ここの出力は48pの場合と60pの場合がある)、最後に再びfps filterで60pにする、という感じ。 (19:29 bskyから・詳細)

いちおう手元で軽く検証した限り、テレシネソースはちゃんと2-3プルダウンされた60pになり、60iな動画は単純にフィールド補間されて60pに出来た。今のところ音ズレなども気にならない感じ。これでいけるかな？ (19:31 bskyから・詳細)

birdきょうのつぶやき@digitune.bsky.social

きょうのつぶやき@digitune.bsky.social

Fire TV CubeのCCGTVより明確に良い点の一つはAV1デコーダを搭載しているところで、ちょうど1年前にlibsvtav1のテストをしたとき作ったAV1/60pな動画をKodiでサクサク再生できた。まぁ今はまだウチの環境だとエンコード時間がかかりすぎるので移行は厳しいけど… (10:43 bskyから・詳細)

ところでH.264はインターレースにも対応しているけれど、最近(？)の世代の規格はもう対応していないので、インターレースな動画をエンコードする場合はdeinterlaceして30pもしくは60pにする必要がある。 (10:48 bskyから・詳細)

これまでffmpegで使えるdeinterlaceフィルタではyadifが一番好き、と思っていたけれど、巷のいろいろなdeinterlaceテクの情報から、単にyadifのみを使うよりもfieldmatchフィルタと組み合わせた方が綺麗になることに気づいた。 (10:56 bskyから・詳細)

というのも元が24pのテレシネソースなら全体の3/5のフレームにはそもそも完全な情報が載っており、60p化の際に補間が必要なmixed frameは2/5だけなんですよね。なのでfieldmatchフィルタでmixed frameのみyadifが補間するようにしたらかなり綺麗になった感。 (11:02 bskyから・詳細)

optionとしては基本defaultで -vf “fieldmatch,yadif=1:-1:1” みたいな感じ。次世代のおうちサーバを構築する時は参考にしよう。 (11:04 bskyから・詳細)

そういや激しく今さらなのだが、AV1ならChromeで何もしなくても再生可能なのは地味にありがたい。 (11:05 bskyから・詳細)

fieldmatchフィルタのcombmatchオプションはデフォルトのsc(scene change)よりfullの方が良いかもなー。 (13:43 bskyから・詳細)

First | Prev | 14 | 15 | 16 | 17 | 18 | Next | Last