Digitune [memo]

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

きょうのつぶやき@digitune

ははは。相変わらず仲の良いことで。 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から・詳細)

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

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

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

このコメントはかなり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から・詳細)

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

で、元ソースが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から・詳細)

適当に録画した映画ソース、アニメソースの冒頭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から・詳細)

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

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

きょうのつぶやき@digitune

jq超便利なので他のdata形式でも似たツールが欲しいと思うことは良くあるのだが、同じ事を考えている人がいた。参考になる＞jq みたいなツール　https://qiita.com/manabuishiirb/items/aea10785a2daf5832c92 (07:49 Twitter Web Appから・詳細)

きょうのつぶやき@digitune

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

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

きょうのつぶやき@digitune

コｗクｗヨｗｗｗ。最高か。 https://twitter.com/impress_watch/status/1376812853018075137 (18:24 TweetDeckから・詳細)

偶然3年前に読んだこの話を再び読み、その完成度の高さに関心するもまた胸がきゅーっとなってしまった。辛い＞蛇の山（四季賞2018春 四季大賞）/窪田 航 蛇の山（四季賞2018春 四季大賞） http://www.moae.jp/comic/hebinoyama/1 (18:30 Twitter Web Appから・詳細)

こちらの作者の窪田航さんって「天気の子」のコミカライズを担当されているのか。知らなかった。 (18:31 Twitter Web Appから・詳細)

きょうのつぶやき@digitune

素晴らしいMV。続きが気になる＞Myuk – 魔法 (Official Video) / Waboku × A-1 Pictures “BATEN KAITOS” https://youtu.be/56jGziUc1UY (00:01 Talon (Plus)から・詳細)

お、録画録画… https://twitter.com/NHK_PR/status/1376411551511498754 (15:07 Twitter Web Appから・詳細)

ちょっちテスト。
今日はとても暖かいなぁ。 (16:11 Talon (Plus)から・詳細)

きょうのつぶやき@digitune

今のリモートワーク環境的にマウスがちょっと使いづらいので生まれて初めてケンジントンのトラックボールを買ってみた。まだ慣れないけど新鮮な操作感だ＞オービットトラックボールウィズスクロールリング Kensington - https://www.kensington.com/ja-jp/p/%E8%A3%BD%E5%93%81/%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%AB/%E3%83%88%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%BC%E3%83%AB/%E3%82%AA%E3%83%BC%E3%83%93%E3%83%83%E3%83%88%E3%83%88%E3%83%A9%E3%83%83%E3%82%AF%E3%83%9C%E3%83%BC%E3%83%AB%E3%82%A6%E3%82%A3%E3%82%BA%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%83%AA%E3%83%B3%E3%82%B0/ (00:36 Talon (Plus)から・詳細)

明日は天気が悪そうなので、今日はあゆみさんと近所のお花見散歩へ行きました。あまり人の来ない道を野の花を愛でながら歩くだけ。写真はホトケノザにカラスノエンドウ。いっぱい写真撮れて楽しかった。 https://twitter.com/digitune/status/1375837781109342209/photo/1 (00:51 Talon (Plus)から・詳細)

この花の名前知らなかったけれど、ツルニチニチソウ、と言うのか。Google PhotoにGoogle Lensが組み込みになってまたとても便利になりましたね。 https://twitter.com/digitune/status/1375838352956612611/photo/1 (00:53 Talon (Plus)から・詳細)

ソメイヨシノも好きだけど、ハナカイドウやレンギョウ、しだれ桜にユキヤナギ、モクレンと言った他の春の花もとても好きだ。 (00:55 Talon (Plus)から・詳細)

新サーバ上のmemoを見ていたらfootnoteが壊れていることに気がついた。軽くググると、なるほど、hugoが使うMarkdown parserが0.6.0で変更になっていることが原因っぽい＞Hugo v0.60 から既定の M… https://twitter.com/i/web/status/1375977204715200512 (10:05 Twitter Web Appから・詳細)

とりあえず一旦従来のblackfridayに戻したけれど、Markdown parserとしての実力は新しいgoldmarkの方が高いようなので、脚注の記載法を一括して修正するかなぁ。 (10:05 Twitter Web Appから・詳細)

過去contentsのfootnoteの記法もperlで一気に変換してgoldmarkのまま使えるようにしました＞inline footnoteを通常の書き方に変更する https://memo.digitune.org/2021/convert_footnote/ (15:22 Twitter Web Appから・詳細)

ちなみにperlで書いたのは一番最近書いたのがperlだったので一番良く覚えていたから、というだけ(汗。ここのところはpythonを使うことが多かったんだけど、この手のsh scriptに毛が生えたレベルの事をしたいだけならperlの方が個人的には気楽かなー。 (15:22 Twitter Web Appから・詳細)

あとgoldmarkによるfootnoteだとlist系のpageでは脚注表示されないんですね。これは設定でなんとかなるのだろうか… (15:28 Twitter Web Appから・詳細)

これまで使っていた古いHugoのMarkdown parser “blackfriday” ではinline footnoteが使えたので、これまでtdiaryから変換されたMarkdown contentsはすべてinlineで書かれていたんですが、新しいHugoで使われているgoldmarkではinline記法はサポートされていない、とのことで、通常の書き方へ変換するperl scriptを書きました。詳しくはこのへんなどを参照、かな。

使い方は書くまでもない気がしますが、標準入力や引数に変換したいmarkdownを入れると変換された結果が標準出力に出てくる、という感じです。

実際使ってみて気づきましたが、脚注内にlinkがあると尻切れトンボになってしまいますね(どちらも同じ[]を使っているため)。あと追加された脚注の直後にtabやspaceでindentされたpre sectionがあると、(改行を1つ挟んでいても)そちらも脚注内の記述と判定されてしまいますね。ちと安直な解決法が思いつかなかったので今回は該当箇所をすべて人力で修正してしまいました(^^;。メンゴ。

#!/usr/bin/env perl

my $count = 1;
my $output = 1;
my @footnote;

while (<>) {
    if (/\^\[/) {
        while (/\^\[/) {
            ($footnote[$count]) = (/\^\[([^\]]+)]/);
            $_ =~ s/\Q^[$footnote[$count]/[^$count/;
            $count = $count + 1;
        }
        print ;
    } elsif (/^$/) {
        print ;
        if ($output < $count) {
            while ($output < $count) {
                printf "[^%s]: %s\n", $output, $footnote[$output];
                $output = $output + 1;
            }
            print "\n";
        }
    } else {
        print ;
    }
}