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