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

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

下記の2か月ほど前にやったdeinterlace filterのVMAF値比較、60iのソースとfilter通した後の60pの出力というformatの違うものを比較していたので正しい結果が出ているのか若干疑問がありました。 https://github.com/gitune/vf_fmdif#vmaf%E5%80%A4%E6%AF%94%E8%BC%83 (09:42 bskyから・詳細)

そこで、60pのソース(native 60pと24pを2-3pulldownしたもの)を用意し、tinterlace filterでそれをinterlace化したものをdeinterlace filterに入力する、というマッチポンプ方式で改めて計測してみました。 (09:42 bskyから・詳細)

コマンドラインはこんな感じ↓。 $ ffmpeg -i INPUT(60p) -filter_complex “[0:v]split=2[0v][1v];[0v]tinterlace=4,yadif=1:-1:1[0vf];[0vf][1v]libvmaf=vmaf_v0.6.1.json:log_path=log.xml:n_threads=8” -an -f null - (09:42 bskyから・詳細)

結果は前回同様yadif,bwdif,fmdif,fmdif2の順に書くと、 | 24p | 94.56 | 96.87 | 96.29 | 97.17 | | 60p | 91.86 | 95.85 | 90.70 | 93.12 | となりました。 (09:42 bskyから・詳細)

24pソースの場合はfieldmatch効果で順当にVMAF値が伸びた半面、native 60pソースではそれぞれ元となったdeinterlace filterに対して悪化する結果となりました。これはfield matchミスによるartifactの発生が原因でしょうね。 (09:42 bskyから・詳細)

上記結果は例によってgithub READMEにもまとめています。 https://github.com/gitune/vf_fmdif#20250126-%E8%BF%BD%E8%A8%98 (09:42 bskyから・詳細)

Snapdragon 8gen3+12GB RAM、165Hz 8.8インチ液晶なLenovo Legion Tabが8万切りで国内登場か。重さ350gは今のmiPad6より150g近く軽いのでちょっと気になる… https://www.lenovo.com/jp/ja/p/tablets/android-tablets/tab-series/lenovo-legion-tab-gen-3/len103g0002?orgRef=https%253A%252F%252Fwww.google.com%252F&srsltid=AfmBOorF_b7Q_R4KlrbsfvlX5LegHL_7OX0y-F_Eek0Y9q88JXbwcVeA (10:03 bskyから・詳細)

ちなみに上記VMAF値は視聴上の体感ともかなりマッチしていて、24pや30pな動画を見ている限りは全く違和感を覚えることはなくなっているものの、native 60pな動画では時々「あれ？」と思うシーンにぶつかることがある。まぁ僕にとってプライオリティは前者なのでそれで正解。 (11:31 bskyから・詳細)

今気づいたけど、bskyのつぶやきダイアログの促しメッセージが「最近どう？」なのに対して、今のXのそれって「考えをポストする…」なんですね。いや、別に考えをポストしたいわけじゃ…(ちなみにFacebookは「その気持ち、シェアしよう」でこれもまた俺とはちょっとズレてる)。 (11:46 bskyから・詳細)

そういやVMAFの中身ってよく知らないな…と思い、単にsplit filterで割っただけの全く同じvideo streamを入力してみたら、min 97.39、max 97.69、平均97.44だった。この辺が上限なのかな。 (12:18 bskyから・詳細)

しかしそう考えると、今回のfmdif2の24pソース時の97.17はほぼ上限、ってことか。優秀。 (12:18 bskyから・詳細)