きょうのつぶやき@digitune.bsky.socialぐはっ、通勤時、立っている胸の高さくらいからミニタブを落としてしまい、液晶がバキバキに…(涙。可搬性重視でカバー付けていなかったことが裏目に出た。しょうがないからまた何か物色するか… (08:32 bskyから・詳細)
割れちゃったミニタブはMediaTek Helio G99/FHD+/8MB/256GBストレージという仕様で1.7万円という激安さが良かったけど、しばらく使ってきてスペック的にこだわりたい部分も見えてきたのでちょっと吟味しよう。 (08:49 bskyから・詳細)
きょうのつぶやき@digitune.bsky.socialとりあえずいったんscript停止。時間が出来たらdebugします。 (00:12 bskyから・詳細)
ワロタ。
https://x.com/onisci/status/1764926729079157147?s=20 (08:42 bskyから・詳細)
なんとなく直った気がするので再開。 (19:52 bskyから・詳細)
きょうのつぶやき@digitune.bsky.social
RP https://x.com/CHICAUMINO/status/1764983651278983394?s=20 (08:58 bskyから・詳細)
うぅむ、リポストの略称であるところのRP、見た目がいわゆるR.I.P.なRIPと似ててちょっと居心地が悪いんだよな。今後もRTを使い続けようかしら… (09:27 bskyから・詳細)
RT https://x.com/AkatsukiKatoh/status/1763042944242823584?s=20 (21:51 bskyから・詳細)
おっと、Blueskyのポストを他のSNSへ送るスクリプト、同じ内容を何度も送っちゃってるな。もしかしてFacebookのトラブルのせいか？ (22:19 bskyから・詳細)
きょうのつぶやき@digitune.bsky.socialその後、帯域足りない印象は元素材由来な気がしてきたので元の30へ戻す。 (13:19 bskyから・詳細)
きょうのつぶやき@digitune.bsky.socialいろいろな60iの素材を見ていると、テレシネソースでも必ず2-3プルダウンされてるわけではなくて24p→30p→60iと変換されているもの(つまりフィールド単位で見ると1122334444になっている)もあるんですね。知らない方が良かったかもしれない事実w。 (10:00 bskyから・詳細)
きょうのつぶやき@digitune.bsky.socialSVT-AV1、lp=4:pin=1で使うプロセッサを4つに絞っていてもload averageは常に8を超えてるんだよな。どこまでもCPUをしゃぶり尽くしてやろうという強い意志を感じる(汗。%CPUはだいたい400%以下に収まっているのでoptionは効いてる感じ。 (09:44 bskyから・詳細)
きょうのつぶやき@digitune.bsky.socialffmpegの新しい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から・詳細)