开篇废话

家里的电视节目已经膨胀到3T了，不得不想点办法压缩下了。

于是稍微研究了下，然后使用了 tsreplace

正文

由于我们录制的是 m2ts 格式的电视节目，里面实际上除了视频和音频以外还有很多奇怪的数据在里面，但是 ffmpeg 不能正确处理这层容器，如果直接扔进 ffmpeg 转的话，我们会丢失节目信息以及数据放送等区域，最重要的是 KonomiTV 将会无法正确解析节目，因此我们需要使用 tsreplace 来进行正确转码：

https://github.com/rigaya/tsreplace

当然 readme 也说了，也和我大概意思就是：

总之就是文件里面视频部分使用 mpeg2 转 hevc 来节省空间，20Mbps 的码率弄成 hevc 大概 3-5Mbps 最后的效果是，比如50分钟的节目，从 5G 压到了 1G 左右

好了介绍完了，好像也没啥说的。

我用了 readme 推荐的命令，使用 cpu 软解：

tsreplace.exe -i <入力tsファイル> -o <出力tsファイル> -e ffmpeg.exe -y -f mpegts -i - -copyts -start_at_zero -vf yadif -an -c:v libx265 -preset medium -crf 23 -g 90 -f mpegts -

当然是最后是跑在朋友的超算集群里了， 当然批量转码部分你问下 gpt 能给你生成114种办法，这里就懒得贴了，因人而异。
大概 900 个视频（平均30分钟），一天左右压制完了。

最后就是从文件传输的时间最长了，总共3T大概花了快2天才传到美国，传回来速度还不错，然后实际上应该跑到硬盘速度上限了。

KonomiTV 魔改

当然配合使用的话，我的 HonomiTV 又要改逻辑了，当然是由 Claude Code 代劳的，但是大概思路还是要明朗才能改：

首先就是重新分析增加逻辑，文件名不变，时长几乎不变，然后只是文件大小变了，则不重新生成文件（之前的逻辑是会新增而不是修改），然后我嫌速度太慢了增加了个 files_only 参数，这样只检测文件编码信息而不重新生成缩略图/关键帧等耗时重复的操作，然后是调整之前自动检测软链接（Symlink）的逻辑，因为我目前是用软链接来目视文件是否转码的 = =，但是 KonomiTV 之前的逻辑是会帮你自动解析后以实际文件路径入库，最后安排了被动判定，如果文件大小差异 20% 则触发被动扫描，以及重命名缩略图（目前缩略图实际上是以文件哈希来命名的，文件变了哈希也不对了。）

总结

很难想象没有 AI 的时代这点破功能要改多久（

完