Digitune [memo]

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

いろいろな60iの素材を見ていると、テレシネソースでも必ず2-3プルダウンされてるわけではなくて24p→30p→60iと変換されているもの(つまりフィールド単位で見ると1122334444になっている)もあるんですね。知らない方が良かったかもしれない事実w。 (10:00 bskyから・詳細)

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

SVT-AV1、lp=4:pin=1で使うプロセッサを4つに絞っていてもload averageは常に8を超えてるんだよな。どこまでもCPUをしゃぶり尽くしてやろうという強い意志を感じる(汗。%CPUはだいたい400%以下に収まっているのでoptionは効いてる感じ。 (09:44 bskyから・詳細)

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

ffmpegの新しいencoding設定がようやく固まってきた感。今回はこれまでのH.264+AACという出力からAV1+OPUSへと世代交代させることが目的なのでそれをゴールとして同等以上の結果を目指した。 (11:29 bskyから・詳細)

順番は逆になってしまうけれど最終段のencoder設定から見ると、libsvtav1のoptionは「-crf 30 -preset 9 -svtav1-params “lp=4:pin=1”」、libopusは「-b:a 128k」だけ指定してます。 (11:32 bskyから・詳細)

libsvtav1のcrfは28～34くらいの間で比較してみたけれど、30を超える値だとやはり全体的な画質劣化(画面が濁る感じ)が気になり、逆に30未満の方はそこまでメリットを感じなかったのでとりあえず30で。presetはCPUをlimitした状態でギリギリ我慢できる処理時間から。 (11:35 bskyから・詳細)

H.264と違いAV1はinterlace出力できないのでそこをどう解くかが今回の設定の肝ですが、以前書いたようにfilter chainはfieldmatch+decimate+yadif+fpsが基本。具体的な設定としては(続) (11:39 bskyから・詳細)

-vf “fieldmatch=combmatch=full:cthresh=10,decimate=dupthresh=3.0:mixed=1,yadif=1:-1:1,fps=60000/1001” こんな感じ。 (11:41 bskyから・詳細)

fieldmatchは60i/30p/24pソース混在の60iが対象なのでcombmatch=fullで、cthreshをdefaultの9から1つだけ上げて10としています。9のままだとテレシネソースでもstill interlaced表示が出ることが多々あり10でほぼ消えました。 (11:45 bskyから・詳細)

decimateはテレシネソースやそれ以外が混在しているのでmixed=1は必須で、その場合に重要となるdupthreshはdefaultの1.1だと明らかに小さすぎる(テレシネソースでもほとんど重複判定されない)ので現物合わせで3.0に。これでほぼ綺麗にdetelecineできました。 (11:47 bskyから・詳細)

なお-loglevel debugをつけてdecimateの挙動を確認したりソースを読んだりしている中でひとつ気になる挙動があったので、下記のような小さいpatchを作って当てています。これでほぼ完璧にdetelecineできるようになった。 https://github.com/gitune/decimate-patch (11:50 bskyから・詳細)

上記のような設定で画質としては同等以上になった(特にテレシネソースではdeinterlaceではなくdetelecineしているので画質は向上している)と思うんだけど、出力file size…というかbitrateはほぼ半減しています。 (11:54 bskyから・詳細)

実際使ってみて、やはりAV1はH.265/HEVCとだいたい同じくらいの効率に思えますね。オープンであるが故の取り回しの良さ(Chromeで再生できる)とか、今だとSVT-AV1がある分、AV1の方が使いやすいかな、って感じか。libx265も悪くないけどね… (11:58 bskyから・詳細)

そういや1080/60pなAV1+OPUSな動画、MediaTek Helio G99なミニタブでもほぼ問題なく再生できるんですね。このチップ、AV1のハードウェアデコーダは積んでなかったはずなので再生の方はそんなに重くはない、ってことか。 (12:00 bskyから・詳細)

この時期の群発地震というとどうしても13年前のことを思い出してしまうな。 (12:19 bskyから・詳細)

そういやSVT-AV1をCPU core固定で使っていると、半分とはいえそのcoreを占有して動くので(realtimeじゃなく時分割スケジューリングにしてるのに！niceも19なのに！ｗ)、他のprocessの影響をほとんど受けないのが面白い。エンコード時間の均一性が高い。 (12:40 bskyから・詳細)

CGアニメのガールズバンドもの、というともはや定番化したジャンルな気もするけれど、この作品はリミテッドアニメに寄せるのではなくCGアニメとしての良さを追求しているように見えてちょっと気になってる。 https://www.youtube.com/watch?v=fONC92G3nNE (13:08 bskyから・詳細)

このアニメ、9か月も前から↓のようなMVをずっと上げつづけてて、実はすごく力の入った作品なのかもしれない。 https://youtu.be/dDwN4MgcIlU?si=yiWOICwztGIrJX2q (13:24 bskyから・詳細)

crf 30だとやっぱりちょっとbitrate足りてないかなぁ。28にしてみる。 (16:12 bskyから・詳細)

あと、fieldmatchが画面に文字がたくさん表示されているような時に櫛を誤判定してstill interlacedと言っていたので、blocky=64:combpel=320を追加してみた。櫛状態判定ブロックの縦サイズを4倍にして閾値も4倍に。はてさて。 (18:28 bskyから・詳細)

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

なんですと！気になる… https://www.itmedia.co.jp/news/articles/2402/29/news104.html (09:31 bskyから・詳細)

きょうのつぶやき@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から・詳細)

lp=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から・詳細)

きょうのつぶやき@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から・詳細)

きょうのつぶやき@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から・詳細)

きょうのつぶやき@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から・詳細)

きょうのつぶやき@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から・詳細)

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

フリーレンは毎週リアタイしてとても楽しんでいるのだが、こういう「毎週放送日が楽しみで仕方が無い」作品のあるクールはとても幸せだ。 (18:05 bskyから・詳細)