きょうのつぶやき@digitune

きょうのつぶやき@digitune

なんとなくH.265なmp4にする以上必ずdeinterlaceしないといかんと思い込んでいたけれど、考えてみるinterlaceのままtranscodeする、という選択肢もあるじゃないか…と思って試してみた。 (19:31 Twitter Web Appから・詳細)

file sizeは一例としてdeinterlaceしたものが元fileの14%にまで縮むのに対し18%と多少大きくはなってしまうが許容範囲。ただ、idet filterで見る限りinterlaceは維持されているように見えるもの… https://twitter.com/i/web/status/1379018730361909252 (19:31 Twitter Web Appから・詳細)

元のm2tsではスムーズに再生出来るのに、同fileをinterlaceのままmp4/H.265に変換したものだとブレブレになる。何でだろ？ (19:31 Twitter Web Appから・詳細)

こちらのpageのコメント欄を見る限り、デコーダー側の問題のように見える。なるほど、H.265でインターレースは上手く再生出来ないのか…＞rigayaの日記兼メモ帳 https://rigaya34589.blog.fc2.com/blog-entry-1105.html (19:31 Twitter Web Appから・詳細)

ここはもうH.264に戻るべきなのか？＜え。 (19:31 Twitter Web Appから・詳細)

ふぅむ、H.264 interlacedで実験してみたが、圧縮率は28%でちょうどH.265の倍というのは予想の範囲内として、H.264でもインターレースな動画はAndroid Kodiだとちゃんと再生出来ない感じ…(H.265と同じくブレブレになる)。 (20:10 Twitter Web Appから・詳細)

するってーとやはりdeinterlaceはやった方が良い、ということになりますな。いろいろ興味深い。 (20:10 Twitter Web Appから・詳細)

昨日からyadifでなくbwdifを試してみているので後で結果を確認しよう。 (20:16 Twitter Web Appから・詳細)

ちなみにファンが全開運転しないよう低速化したCPUだとlibx265は1/4倍速くらいのエンコ速度だが、libx264だとほぼ実時間だった。はやー。 (20:18 Twitter Web Appから・詳細)

ffmpegのdeinterlace filter、majorなyadifとbwdifを比べてみたが、ウチの環境(Android Kodi+LG CX)だとyadifの方がすっきりしていて綺麗に見える。ジャギーも特に気にならない。… https://twitter.com/i/web/status/1379049524518289423 (21:33 Twitter Web Appから・詳細)