Digitune [memo]

きょうのつぶやき@digitune

COCOAバグ放置の件の報告書、とりあえず概要だけ読みました。ぱっと見の印象としては、これはまず作り手にプロダクトへの愛も矜持もない形の開発なんだな、ということ、そしてさらにプロセスもグダグダだったのね、ということ。 (10:30 Twitter Web Appから・詳細)

個人的にもう長いことソフトウェア開発に携わってきているけれど、ソフトウェアプロダクト開発プロジェクトは、テストを含めたプロセスがちゃんと構築されているか、または作り手に強い愛or信念・矜持がないと、すぐに酷い品質になってしまう。 (10:30 Twitter Web Appから・詳細)

最近は自動テスト・回帰テストのためのツールも非常に充実しているしテストファーストな考え方もかなり常識化しているので、前者で品質を担保するためにかかるコストも上手くやればそこまで大きくならないはずなんだが、なんとなくそれ以前の問題だったように見える。 (10:30 Twitter Web Appから・詳細)

プロジェクト立ち上げ期などは逆に、プロセスはまだ未整備だったとしても作り手に強い意志があるので、いわゆる「隅々まで目端を利かせる」ことで高品質を担保できる。ただもちろんこのやり方には持続性はないのでできるだけ早くプロセスベースに移行する必要がある。 (10:30 Twitter Web Appから・詳細)

COCOAで言えば開発体制が変わった頃合いがプロセス確立の良いタイミングだったように思うが、その後テスト環境が整備されるまでに4ヶ月以上かかっているあたり、客観的にもひどく杜撰なプロジェクト運営に見えるなぁ。 (10:30 Twitter Web Appから・詳細)

しかしまぁ内容的にはちょっと間の抜けたものだったとしても、ちゃんと報告書を出してくれるのはさすがお役所でありがたい。報告書にUIフォント使うのはどうかと思うけどね…＜結局言いたかったのはそれか。 (10:30 Twitter Web Appから・詳細)

録り溜めた深夜アニメを見ていて、TOKYO MXやBS11のような新興の(?)、しかし以前からアニメに熱心なTV局の番組のCMと比べて、TBSやテレ朝といった地上波キー局の番組のCMのヤバさが気になるのは俺だけ？ (10:36 Twitter Web Appから・詳細)

前者はアニメBDやスマホゲーなど、曲がりなりにもアニメファンに刺さりそうなCMを打っているのに対し、後者はなんだかとんでもない会社のとんでもない製品のCMがときどき流れてくるような気が。地上波CMどうなっちゃってるの？(全然見てないので分からない) (10:36 Twitter Web Appから・詳細)

ほぼ新番組の1話を見終わり、これは見ないだろうというものの整理が終わったので、毎週撮ってるアニメ・ドラマって何本あるのかな…と調べたら54本もあった(@@;。撮ってるだけで見ていないものも多いけれど、それにしても多すぎる気が… (10:45 Twitter Web Appから・詳細)

Chromecast with Google TVのリモコン、さらさらな手触りで必要最小限のボタンと使い心地は悪くないんだが、いかんせん滑りやすくてよく取り落としてしまう。リモコンはもう少し滑りにくい表面処理の方が良いと思うよ。 (11:17 Twitter Web Appから・詳細)

きょうのつぶやき@digitune

御意。もう一つ付け加えるならドビュッシー！ https://twitter.com/hito_horobe/status/1381603202685005824 (13:54 Talon (Plus)から・詳細)

金曜にこれまでにないほど酷くなってもう5日も経つ片頭痛ですが(昨日病院で診断してもらいました)、病院でもらった痛み止めが恐ろしい効き目で改めて驚き。所詮一時的なものではあるもののとてもありがたい。 (13:58 Talon (Plus)から・詳細)

きょうのつぶやき@digitune

RT @t_trace Visual Studio Code用の小説言語エクステンションを更新しました。
マーケットプレイスの準備ができるまでは、Githubにビルドしたパッケージも置いておきます。
https://github.com/ttrace/vscode-language-japanese-novel https://twitter.com/t_trace/status/1381074463840604163/photo/1 (13:06 Talon (Plus)から・詳細)

いい… https://twitter.com/genkiniikitaisu/status/1381233375525007362 (22:11 Talon (Plus)から・詳細)

きょうのつぶやき@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から・詳細)

きょうのつぶやき@digitune

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

これまで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から・詳細)

あ、ちなみに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から・詳細)

きょうのつぶやき@digitune

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

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

きょうのつぶやき@digitune

今のスマホが今年の終わりくらいで丸3年になるので、そのくらいの時期にGalaxy S21 Ultraあたりを狙おうか。 (18:26 Talon (Plus)から・詳細)

きょうのつぶやき@digitune

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

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

きょうのつぶやき@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から・詳細)

きょうのつぶやき@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から・詳細)

ffmpegによる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から・詳細)