結論
ffmpeg -i test4.ts -c:v h264_omx -y -b:v 4M test4omx4Pi4.mp4
でPiのomxplayerの？ハードウェアエンコード h264_omxを使った高速ts→mp4変換ができた。オプションとして-b:v 4M を指定すると高画質になる。
経緯
ffmpegでrecfsusbのTV画像をパイプしてhttpなりで配信できないか？を調べてたら、ラズパイのffmpegでハードウェアエンコードできる感じの記事。
recfsusb2n が認識しているdeviceは /dev/bus/usb/001/004 だったから
それを v4l2-ctl コマンドに食わせると
$ v4l2-ctl -d /dev/bus/usb/001/004
デバイスの認識はダメみたいけど、ffmpegのエンコードには別に関係ないか。
これ。h264_omx オプションでラズパイの omxplayerで？ハードウェアエンコード？できるっぽい。
ts録画して…
こうか？
$ ffmpeg -i test4.ts -c:v h264_omx -y test4omx.mp4
なんかエラーだな…
変換前がコレで
変換後がこう。変換自体はできてる！
tsがmp4に（すごい速度で）変換できた。HandBrakeCLIより速い？高解像度化のオプションないか調べる。
-b:vオプションで高解像度化できる！
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 1000k test4omx2.mp4
だいぶマシになった！
HD映像（ハイビジョン？）の時は -b:vに4m を指定せよとある。
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 4M test4omx3.mp4
こりゃ素晴らしい。
サイズは15MB→4MBだから約4分の1になる。
母艦fedoraのHandBrakeCLIで同じこと（ts→mp4）してみよう。手元でいつもやってるやつだ。
$ HandBrakeCLI -i test4.ts -o test4omx4HBCLI.mp4 -Z "Apple 1080p30 Surround"
体感だとffmpeg（omxハードウェアエンコード）に比べて倍の時間かかってる気がする。
さすがにHandBrakeは画質キレイ？いや、そんな違わんでしょ。
これでサイズもffmpeg（h264_omxエンコード）のほうが小さい！
てことは、ffmpeg（h264_omxエンコード）を使えば
・ラズパイの筐体で（電力消費が極小）
・HandBrakeCLIよりも速く
・エンコード後サイズも小さく
できる！素晴らしすぎる。
てことは、普段はVPNサーバにしてて、GPUを持て余してるラズパイ4でも同じことffmpeg（h264_omxエンコード）できるのか！？
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 4M test4omx4Pi4.mp4
できちゃった！画質もバッチリ。
上がffmpeg。下はHandBrakeCLI。見た目違い分からんくらいキレイ。これで日々撮り溜めたニュース.tsのエンコードが倍速になる。
試しに昨日のニュース.ts（286MB）をエンコードさせてみる。
ちょっとエラー吐くが無視。
実測の1.4倍で変換できてる！？らしい。こりゃ捗る。
わずか2分で286MBのエンコードが終了！
画質ばっちり。サイズも元の半分近くに圧縮された。
これで一括変換できるわ。
変換開始。一気に温度上がった。
70度超えはちょっと厳しいか。
ちなみに同じh264_omxエンコードでも、V4L2M2Mエンコードは動かんかった。
あとはtsに乗ってくる犬Hの副音声が邪魔。どうやって除去するか調べる。
