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

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

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

スプラのフェスで100倍マッチに勝てて嬉しい。特に最近全然塗れないホットブラスターカスタムなんていう参加するだけで味方に不利を強いるようなブキを使ってるだけになおさら(汗。ホッカス楽しいんすよホッカス。 (19:36 bskyから・詳細)

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

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

image 0絵の素晴らしさは言うに及ばず、さらにALT textをしっかり付けてくださっているのが先生らしくて素敵。 RT https://bsky.app/profile/shirahamakamome.bsky.social/post/3klhke6ffm22l (18:39 bskyから・詳細)

というわけでRe-post対応完了。Re-postはそのSNS内固有の操作なので、SNSから出てしまうと単なるlinkになってしまうのはある意味しょうがない。 (19:22 bskyから・詳細)

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

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

image 0さあテスト。 https://www.docs.bsky.app/docs/get-started (19:53 bskyから・詳細)

image 2image 1もう一回だけ。 https://atproto.blue/en/latest/index.html https://formatter.org/python-formatter (20:18 bskyから・詳細)

とりあえずBluesky→Twitterなbridgeを作って動かし始めた。ただこちらは300文字、あちらは144文字なのではみ出た分は有無を言わさずぶった切る適当仕様💦。 (20:34 bskyから・詳細)

そういやBlueskyのRate Limitsについては下記に情報あるんだけど、これを読むとREADはGlobal limitにしか制約されないのだろうか？ちょっと怖いので今は15分毎に実行するようにしてみている。 https://www.docs.bsky.app/docs/advanced-guides/rate-limits (20:35 bskyから・詳細)

image 3Facebookにも流れていくようにしてみたぞ。linkが展開されないのは待ち時間が足りていないのかな…？というわけでまたテスト。 https://youtu.be/zbgCgggOJvA?si=5kaB02rzWfcHeUq6 (23:39 bskyから・詳細)

というわけでBlueskyのAPIのおかげで久々に自分のつぶやきがTwitter/Facebookへ流れていく環境が戻った。後は日々のつぶやきをblogへまとめる部分も復活させないと… (23:45 bskyから・詳細)

image 4テストに使うならこのいよわさんの新曲(?)の方が良かったな。良い曲。 https://youtu.be/7-2PUEl-7a4?si=iSJiTfG7OtmEWfSy (23:51 bskyから・詳細)

First | Prev | 30 | 31 | 32 | 33 | 34 | Next | Last