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

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

既存のfilter chainからfmdifに代えて安定感は爆上がりしたけど、まだ時々気になるartifactは考えてみるとfield matchを頑張りすぎることに原因があるような気がする。 (23:49 bskyから・詳細)

fmdifの場合field match出来なくても単にdeinterlaceになるだけなので(品質は多少落ちるとはいえ)、頑張りすぎるのはむしろ有害なのか。そんなわけでcombpelをoriginalのfieldmatch filterデフォルトの80に戻す。 (23:52 bskyから・詳細)

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

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

うぅむ、今のAndroid版Kodi 20.5(Nexus)にはAV1再生にbugがあるようで、特に60FPSフルに書き換えが起きるbitrateが高いシーンを再生しようとすると絵のみがフリーズして音だけ流れる、という状態となることがある。 (14:14 bskyから・詳細)

Updateが止まっているAndroid版VLCでも同様で、Windows版VLCでは問題なく再生できたところをみるとおそらく最近ffmpegのAV1 decoderで修正された問題なんじゃないかと思うのでそろそろリリースはずのKodi 21(Omega)では直ることを期待… (14:17 bskyから・詳細)

image 0これまでのTVシリーズとリズ~までは見てるから、誓いのフィナーレとアンサンブル・コンテストを見れば追いつけるのか。メモメモ📝。 https://x.com/eupho_tkj/status/1775360672727183628?t=KR_BA3tXroNdobNNCB1F4A&s=09 (16:58 bskyから・詳細)

image 1RT https://x.com/yellmovie_2024/status/1774391194350473694?t=GB5WCqod5NjK6DhhQkADxA&s=09 (17:29 bskyから・詳細)

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

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

昔は最速放送が多い、局ロゴが目立たない、などの理由からTOKYO MX好きだったんだけど、我が家も4Kテレビにして以来マルチ編成による帯域不足(による画質低下)がいよいよ我慢できなくなったので最近は全然見なくなってしまった。せめて他の地上波と同程度の画質ならば… (00:17 bskyから・詳細)

さまざまなソースを60i→60p変換しているといろいろ発見がある。エンドロールが鬼門なのは24pの背景の上に30pの字幕を重ねたりしていることがあるせいで、こういうのを24p側に合わせてfield matchしてしまうと字幕がガクガクしてしまう。 (11:14 bskyから・詳細)

仕方が無いのでこういったソースの時は素直にdeinterlacerに任せたいところなんだけど、櫛検出による切り替えだとどうしても完璧には切り替えられないんですよね。まぁまぁ我慢出来る塩梅で切り替わるようにparameter tuningするしかない。うーむ。 (11:16 bskyから・詳細)

fmdifのdefault値、cthresh=10、combpel=100は今のところその「まぁまぁ我慢できる塩梅」って感じ。ちょいdeinterlacerに落ちちゃう場面が多すぎる嫌いはあるが… (11:19 bskyから・詳細)

昨日ちょっとfmdifを最適化して、current frameに櫛が無ければほぼframe copyだけで進むようになったせいか結構encode時間縮んでいる気がするな。案外filterにも無視出来ないくらいはCPU使ってた、ってことか… (14:43 bskyから・詳細)

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

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

image 0fieldmatch+decimate+yadifというfilter chainのparameter tuningを行うことで安定して高品質な結果を得る方法に限界を感じて、自前でvisual filterを書いてしまった。 https://github.com/gitune/vf_fmdif (19:45 bskyから・詳細)

fmdif=field match deinterlace filterの意ですが、yadifをベースにfieldmatchの櫛検出+field match処理を前段に組み込んだもの。櫛の生じないマッチしたfieldが見つかればyadifの処理の代わりにそちらを使います。 (19:47 bskyから・詳細)

自前で作った、とはいえ自分の書いたコードはほとんどなくて、ほぼyadifとfieldmatchのキメラです。ホントはfieldmatchはマッチしたfieldを探すのに櫛検出とは別の方法を使っていますが(多分そっちの方が軽い)、そちらはよく分からなかったので櫛検出のみを拝借。 (19:50 bskyから・詳細)

通常のyadifと比べると櫛検出のためにfield毎に2 frame作るのでちょっと重くなっているはずですが、後段のAV1 encodeに比べれば誤差レベルかな… (19:52 bskyから・詳細)

この週末の自由になる時間を全て使ったので制作時間は5~6時間、ってところか。そこまで家事に影響するほどでなくて良かった。 (19:54 bskyから・詳細)

そんなわけで最新のfilter chainはこんな感じ↓。 -vf “fps=30000/1001,fmdif=1:-1:1” めっちゃ短くなった(汗。 (19:56 bskyから・詳細)

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

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

それなりに中身分かったんだが、思いのほかheuristic全開でワロタ。ffmpegって俺みたいな趣味でちまちま楽しんでる人が作ってる、って感じだな。それはともかく何となくロジックは分かったものの良い修正案が思いつかん(汗。 (10:14 bskyから・詳細)

で少し方針変換して、直近の対応としてはfield matchが難しい場面ではさっさと諦めてdeinterlacerに任せる方向でtuningしてみることにした。そのうち60i→60p専用のfield match deinterlacer(仮)作りたいな。 (10:18 bskyから・詳細)

“fps=30000/1001,fieldmatch=combmatch=full:cthresh=10:combpel=100,decimate=dupthresh=5.0:mixed=1,yadif=1:-1:1,fps=60000/1001” 最新のfilter chain (10:25 bskyから・詳細)

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

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

相変わらずffmpegのfilter chainのtuningを続けていてまぁほぼ満足のいく結果が得られているんだが、やはりsimpleにdeinterlacerを通すのに比べると安定性が落ちるのが気になっている。 (16:01 bskyから・詳細)

これまでの試行錯誤から60i→60p変換については、

  • まずfield単位でfieldmatch filter的な前後fieldとのmatchingを行い、マッチするものがあればそれを使って補間する
  • マッチするものがない場合のみ隙間を適当に補間する とすると良さげ。 (16:05 bskyから・詳細)

ただ既存のdeinterlacerにはそういう動きのものはない感じなんですよね…既存のfilterを組み合わせて作ってみようかなぁ。 (16:09 bskyから・詳細)

エンドロールが鬼門でしばしばガクガクになってしまうのだが、何が起きているのかを調べてみるとどうもfieldmatchでのmatchingが上手くいっていない感じ。前後のfield同士の差分が小さすぎて正しい方とmatch出来てない、って感じかなぁ。 (19:15 bskyから・詳細)

decimateに比べると複雑なのでちょっと腰が引けていたのだがfieldmatch filterのソースを読んでみようか… (19:19 bskyから・詳細)

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

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

朝からわんだふるぷりきゅあのED曲がイヤーワーム状態なんだが何故…。謎。 (08:12 bskyから・詳細)

そういえば、まれにlibopusがchannel mapに失敗してencode中に異常終了することがあったので、-ac 2 オプションを追加して2ch stereoへ強制down mixすることにした。ソースもほぼステレオ音声しかないので無問題。 (08:40 bskyから・詳細)

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

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

昨晩少し前に買った漫画を読もうかなと開いてみて、今の予備の眼鏡だととても読みにくいことに気がついてやめた。メインの眼鏡が戻ってきたら読もう。 (16:38 bskyから・詳細)

image 0なぬ?!全巻買ってはいるもののここのところずっと読めてなくて、読んでる娘から「語り合いたいからはよ読め~」と圧力をかけられてたんだよね(汗。早く読まないと終わってしまう… https://twitter.com/comic_natalie/status/1772167315448377757?t=TXoHJtv11R11VCPVF0zhOg&s=19 (18:38 bskyから・詳細)

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

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

fps=30000/1001,fieldmatch=combmatch=full:cthresh=10:blocky=64:combpel=320,decimate=dupthresh=5.0:mixed=1,yadif=1:-1:1,fps=60000/1001 最新のfilter chain。 (16:51 bskyから・詳細)

まずfpsフィルタでframe dropを補い、次のfieldmatchフィルタでソースが30p/24pの場合のインターレース解除、その後decimateフィルタで24pの場合の重複frameを削除し、yadifで残った60i部分を60p化し再びfpsフィルタで60pにCRF化して終了。 (16:57 bskyから・詳細)

decimate(patch付き)のdupthreshを増やしたのが最新の差分だけど、ソースのノイズが多い場合に重複フレーム判定にミスることがあり現物合わせでギリギリまで増やした。まぁ24pソース優先なのでもっと派手に増やしても良かったかもだけど60i部分も気になるからね… (17:02 bskyから・詳細)

これでほぼアーティファクトが気にならない程度にはうまくエンコード出来ているけれど、文字がたくさん表示されるシーンとか空間周波数の高いシーンはやっぱりfieldmatchがミスしがちですね。インターレースの櫛と高さ1ドットの横線は区別つかんからなぁ…(汗。 (17:05 bskyから・詳細)

image 0それにしてもdecimateのpatchはとても上手く機能している感。どうしてdefaultでそうなっていないのか不思議なレベルだ。 https://github.com/gitune/decimate-patch (17:08 bskyから・詳細)

First | Prev | 11 | 12 | 13 | 14 | 15 | Next | Last