birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

少なくともウチの環境(TV、Player)で見る上では、libx264の-crf 22と21には大きな差があった。21で画質的にはほぼ文句なし。ファイルサイズは大きいけどせめて-preset slowerでできるだけ小さくしよう… (21:03 TweetDeckから・詳細)

ちょっと面白かったのは、TSを直で見るよりもH.264にエンコードしてから見る方が綺麗に見える部分もある点。何のフィルタもかけていないのだが、libx264標準でかかるdeblock処理などが良い具合に働いているのかな。ディテールの喪失もほとんど気にならない。 (21:06 TweetDeckから・詳細)

そういえば今日はVP9も試してみたんだが、それなりにthreads等を調整しても0.1倍速以下のエンコ速度でこれもちょっと実用には厳しいなぁ、という感じだった。圧縮率的にはH.265並ではあったのだけれど。 (21:08 TweetDeckから・詳細)

そういやffmpegの4.4がリリースされたらしいのでちょっと更新点を確認しよう。 (21:08 TweetDeckから・詳細)

AV1の比較的高速なエンコーダ、SVT-AV1が入ったのが大きいよね。実用的な速度で使えるのだろうか… (21:13 TweetDeckから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

H.265ではインターレースのままエンコード出来ないなら、deinterlaceして60FPS(いわゆるBob化。これって何の略なんだろう?)にしてしまうのも手か、と(エンコオタの典型的なルートを辿って^^;) Bob化も試してみることにした。 (11:38 Twitter Web Appから・詳細)

image 0これまでBob化に二の足を踏んでいたのは、Playerとして使っているChromecast with Google TVはスペック上はH.265/60pまでデコード可能な石を積んでいるもののちょっと不安があったこと、単純にフレーム… https://twitter.com/i/web/status/1380711786215661569 (11:38 Twitter Web Appから・詳細)

で実際に試してみたところ、30pも60pもエンコード後ファイルサイズはほとんど変わらないんですね。crfやpresetは同値としたけれど、ビットレート固定なわけではないのでちょっと意外。まぁソースが一緒なら含まれる情報量は変わらない、ということか。 (11:38 Twitter Web Appから・詳細)

ただエンコード時間はちょうど倍になりました。これは痛い。元々libx265 -crf 24 -preset medium(default)でのエンコードはおうちサーバだと実時間の4倍程度かかっていたので、それが8倍になってしまうことに。これはちょっと受け入れがたい。 (11:38 Twitter Web Appから・詳細)

なんとかエンコード時間を短縮する手はないものか…と考えて2つ試してみた。 (11:38 Twitter Web Appから・詳細)

1つめはyadifでdeinterlace+bob化する代わりに、separatefieldsフィルタを使いインターレース動画の各フィールドを機械的に縦解像度半分、フレームレート2倍のフレームとして、それを無理矢理元のアスペクト比で表示する作戦。 (11:38 Twitter Web Appから・詳細)

言ってみれば1フィールドの半分しかない縦解像度を表示側で補完させる、という作戦でしたが、結果的にこれは失敗。エンコ速度は爆速、ファイルサイズも超小さく出来たものの、表示はちらつくし品質は最低でした。既存のdeinterlaceフィルタが良く出来てることを再確認。 (11:38 Twitter Web Appから・詳細)

で次に試してみたのがyadifでbob化した後にmpdecimateフィルタで重複フレームを単純削除し、そこに-vsync vfrを付けてVFR mp4にしてそのまま表示する作戦。無駄なフレームをとことん省略してやろう、という手ですね。 (11:38 Twitter Web Appから・詳細)

そもそもKodiでVFR mp4が正常に表示できるのかからして心配でしたが、結果的には音ズレもなくフツーに表示できました。Kodi優秀。エンコード時間もアニメ・映画ソースのような元々プルダウンされているようなものであればそれ相応に早くなり、狙いは達成できていそう。 (11:38 Twitter Web Appから・詳細)

ファイルサイズも単純にBob化してH.265にしたものよりも小さくなりました。ただ、やはりVFR mp4というのはイレギュラーな動画なのか、大幅におかしくなることはないものの、結構な頻度でカクつきが目立ち、常用するのは厳しそうな品質でした。 (11:38 Twitter Web Appから・詳細)

おそらくフレームレートが不定期に変化するのでTV側の補正が追いつかないことが原因なんじゃないかなぁ。あとmpdecimateフィルタはヒューリスティックに重複フレームを検出するのでフツーに誤検知もありそう。単純Bob化版と見比べるとシーンの長さに違和感があるものもありました。 (11:38 Twitter Web Appから・詳細)

というわけで結局のところ、H.264でインターレース保持、が今のところウチの環境ではエンコード時間、画質的には最適解、という結論に変化はありませんでした。残念。倍以上必要なファイルサイズは妥協するしかないなぁ。 (11:38 Twitter Web Appから・詳細)

昨日から頭痛や関節痛があり、これは超久々に風邪を引いたか?(コロナ禍で外出しなくなり手洗い等を良くするようになって、本当に風邪を引かなくなった。) 熱とかそれ以外の症状はないので、カフェインで頭痛を散らしてしまおうかな…<をい。 (11:42 Twitter Web Appから・詳細)

image 1あ、ちなみにChromecast with Google TVは60FPSなH.265動画も「ほぼ」問題なく再生可能でした。ほぼ、というのはときどきフレーム落ちすることがあったからなんですが、ただ再現性が謎なんですよね。あとフレー… https://twitter.com/i/web/status/1380715244536750083 (11:52 Twitter Web Appから・詳細)

また元が60iのソースだとフレーム落ちを視認できますが、アニメ・映画ソースのようなプルダウンソースだと全く分からないです。なのでPlayerのスペックに関してはほぼ杞憂だったと言えそう。 (11:52 Twitter Web Appから・詳細)

毎クール恒例の1話総チェックの時期だけど、ひげひろはああいう人にはなりたくないという典型のような主人公が個人的にダメだった。Not for me。 (12:08 Twitter Web Appから・詳細)

ダメな方を書くのは僕にしては珍しいけど、それも今期はここまであんまりダメな作品がないからなんだよな。皆1話には力が入っているせいか、どの作品も面白くて次も見たくなる。 (12:08 Twitter Web Appから・詳細)

あ、日テレのアレもNot for meでした。ああいう劇画調の時代物って定常的に作られている印象があるけれど、固定ファンが一定数いる、ってことなのかなぁ… (12:08 Twitter Web Appから・詳細)

ちなみに「スーパーカブ」は泣いた。素晴らしい。これもスタジオ櫂なんですね。前クールのウマ娘2期に続いてこれもとても良いアニメになりそう。 (12:08 Twitter Web Appから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

x265のcrf 24とx264のcrf 22だったらSSIMの数値的にはむしろ後者の方が良いくらいのはずなんだが、実際に見てみると何だかもんにゃりしてるんだよな。この先は加速度的にファイルサイズが大きくなるからあんまりやりたくないんだがとりあえず21にしてみるか…。 (00:02 Talon (Plus)から・詳細)

image 0結局H.265化は諦めて、インターレース保持H.264に戻った話をいつものページに追記しました>結局H.264に…(2021/04/08) https://github.com/gitune/set-chapters-at-silence/wiki/HEVC-H.265-hardware-accelerated-encoding-on-Ryzen-mini-PC (20:02 Twitter Web Appから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

image 0RT @T_SONOYAMA またしても #ジャンププラス で面白い漫画が始まってしまった♪テンポの良さと中盤からの超展開、そしてラストwww
絵柄も含めて好みすぎる!(b Φ▽Φ)/

[第1話]ダンダダン - 龍幸伸 | 少年ジャンプ+ https://shonenjumpplus.com/episode/3269632237310729754 (19:22 Talon (Plus)から・詳細)

昨日H.264でインターレースのままにならなかったのは単に「-flags +ilme+ildct」を付け忘れていたからだった。そちらを付与することでinterlacedなH.264に出来、なるほど、これだと何も考えずにほぼ元の品質を保てるね。 (20:12 Twitter Web Appから・詳細)

image 1deinterlaceしたH.265(-crf 24 -preset medium)だと以前書いたように元tsの14%くらいまで縮むのだが、interlaceのまま同程度の画質でエンコードしたH.264(-crf 22 -pres… https://twitter.com/i/web/status/1379391676473470976 (20:12 Twitter Web Appから・詳細)

ホントはH.265でinterlacedなものが作れればよいのだが、こちらは現状いろいろな理由から望み薄な感じだった。ちなみにH.264なら-preset slowでもH.265の倍くらいのスピードでエンコード出来る。やっぱりかなり軽いね。 (20:12 Twitter Web Appから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

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

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

image 1こちらの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から・詳細)

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

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

そういや24pの映画を今までの何も考えずに29.97pにdeinterした動画、実際に見てみると思ったより全然ジャダーが気にならなかった。ただ思い起こしてみると結構シーンにより違いがあって、たぶんこれテレビ側のデテレシネ処理がうまいことやってくれてる気が。 (00:37 Talon (Plus)から・詳細)

これまでもシーンチェンジ直後だけガタつく、みたいな現象があって、絶妙に処理能力不足でコマ落ちしてるんだと思っていたんだが(Iフレームだけダメ、とか)、どちらかと言えばTV側のデテレシネ処理に失敗していたのかも。23.97pでエンコードしたもので確認しよう。 (00:42 Talon (Plus)から・詳細)

ffmpegでdeinterlace+23.98p化した動画と単にdeinterしただけの29.97pの動画をじっくり見比べてみたのだが、結局後者の方が総合的には見やすい(=綺麗な)動画に見えた。TVの「リアルシネマ(=逆テレシネ処理)」が優秀、ってことかな… (16:01 Twitter Web Appから・詳細)

そんなわけでエンコーダ設定は元のままとしました。うむ。 (16:01 Twitter Web Appから・詳細)

image 0ffmpegによる24p化は、手元で何パターンか試した限りでは
・単純にinterlace解除するよりなぜか画質が落ちる気がする
・逆テレシネ処理にミスってframe dropしている箇所が目に付く
・30p/24p混在だと30p… https://twitter.com/i/web/status/1378605518617411584 (16:09 Twitter Web Appから・詳細)

TVの逆テレシネ処理がミスするシーンチェンジ直後なども比較的FPS安定している、というような良い点もあったんですけどね… (16:09 Twitter Web Appから・詳細)

あ、あと、なぜかウチの環境では29.97pと23.98pでエンコード後ファイルサイズが全然変わらなかった、むしろ23.98pの方が大きくなった、という点も謎でした。ffprobe等で見る限りちゃんとフレームレートは低くなっていたんですが… (20:49 Twitter Web Appから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

image 0ははは。相変わらず仲の良いことで。 https://twitter.com/sokusekimaou/status/1377832009817452552 (00:06 Talon (Plus)から・詳細)

今はtsを単純にdeinterlace(59.94i→29.97p)してH.265に変換しているのだが、先日NHK-BSでのF1特集を見ていて、おそらくPALソースと思われる部分でのジャダーが気になった。 (11:07 Twitter for Androidから・詳細)

テレシネされた番組はまだちゃんと見ていないのだけれど、おそらく同じようにジャダーが気になるんじゃないかなぁ。これ、自分でソース毎に適宜pullupして出力FPSを調整するしかないのだろうか? (11:07 Twitter for Androidから・詳細)

事前にソースをスキャンしてpulldown状態を推定し、自動的に30p or 24p(まぁ25pは考えないことにする^^;)を切り替えるようなことは出来ないかな?軽くググった感じでは見つからなかったが… (11:07 Twitter for Androidから・詳細)

作るか。 (11:07 Twitter for Androidから・詳細)

image 1わら。ちなみに元ネタの番組はとても面白かった記憶。 https://twitter.com/hibikiw/status/1378159936098557954 (11:12 Talon (Plus)から・詳細)

過去にもメディアが使う頭の悪そうな略語は数多あったけど「まん防」は相当なレベル。最初見たときはギョッとしたよ。マンボウさんに謝れ。 (11:24 Talon (Plus)から・詳細)

image 2RT @razokulover: 国会に提出された議案をGitHubで差分形式で見やすくするプロジェクト / “LawHub | 国会に提出された議案をGitHubのような差分形式で可視化します。” https://htn.to/5dNDFUENjQ (11:32 Talon (Plus)から・詳細)

image 3このコメントはかなりhelpful。idet filter使って考えてみるか…>How to tell if a source needs to be detelecined? http://www.reddit.com/r/ffmpeg/comments/d3te9l/comment/f05vo5i (12:21 Talon (Plus)から・詳細)

録画された番組のfield構成をffmpegのidet filterで見ていて初めて知ったのだが(<遅い)、アニメってTV版でも24p(正確には23.97p)なの?言われてみれば当たり前の気もするがこれまで全然知らなかったよ…orz。 (19:58 Twitter Web Appから・詳細)

image 4idet filterの結果の見方を調べていたんだが、おそらくprogressive or interlacedはMulti frame detectionでTFF or BFF frameの数とProgressive frame… https://twitter.com/i/web/status/1378307992492273670 (20:26 Twitter Web Appから・詳細)

image 5で、元ソースが30p(60i)か24pかは、Repeated Fieldsとして検知された繰り返しfieldの数で分かりそう。一般的な2-3プルダウンの場合5 frames/10 fields中Top 1回、Bottom 1回の繰… https://twitter.com/i/web/status/1378307993549168640 (20:26 Twitter Web Appから・詳細)

image 6適当に録画した映画ソース、アニメソースの冒頭18000 frames分(=約10分)を見てみると、映画でNeither: 14134 Top: 1939 Bottom: 1928、アニメでNeither: 13954 Top:… https://twitter.com/i/web/status/1378307994564272133 (20:26 Twitter Web Appから・詳細)

というわけで戦略としてまとめると、
・deinterlaceはとりあえずかける
・冒頭18000 framesをidet filterで調査し、Top/Bottom Repeated Fieldsが1440(=全体の8%)を超える場合は24pと判断
というような感じが良いかな。 (20:26 Twitter Web Appから・詳細)

image 7実際には異なるFPSのソースが混在していたり(30p/60iが混ざるとRepeated Fieldsは減る)、絵的に動きのない場面だったりするとそれもRepeatedとして検知されてしまうなど、結果が上下にぶれる可能性があるため、… https://twitter.com/i/web/status/1378307996665536516 (20:26 Twitter Web Appから・詳細)

ちょっとこれで様子を見てみるか…FPSを変更するほど大きな変化だといきなり全部切り替えるのは怖いので一部の番組でテスト運用してみよう。 (20:26 Twitter Web Appから・詳細)

birdきょうのつぶやき@digitune

きょうのつぶやき@digitune

image 0この挙動の違いが不思議だったのでちょっと調べてみたら、ブラウザのUser-Agentを付けてHTTP GETするとMETAタグによるredirect(to HTTP)になり、付けないとHTTP 301によるredirect(to… https://twitter.com/i/web/status/1377175229898784769 (17:25 Twitter Web Appから・詳細)

image 1参考になる。 https://twitter.com/HikaruYoza/status/1376852237125750786 (17:44 Talon (Plus)から・詳細)

First | Prev | 64 | 65 | 66 | 67 | 68 | Next | Last