开篇废话

家里的电视节目已经膨胀到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天才传到美国，传回来速度还不错，然后实际上应该跑到硬盘速度上限了。

2026 年 7 月 30 日更新：后来我又开始折腾数据放送了。

前面虽然已经把视频压小了，但是后来发现有些台的数据放送还是能占掉不少空间。一开始当然想直接用 --remove-typed 全删掉算了，结果丢进 web-bml 就只剩下一直“数据取得中”，看来运气再好也不能指望缺了一半的数据还能跑起来（

所以最后还是搞了个比较折中的 --smart-remove-typed，大概就是启动需要的东西一直留着，其他数据每 14.5 分钟留 1 分钟，剩下的删掉。至少目前拿 web-bml 测了下已经能正常打开，文件有的能再小 30%～40%，当然也有些台几乎是 0%，差距还挺大的。

tsreplace -i input.m2ts -o output.m2ts --smart-remove-typed

当然几百个文件不可能手动一个个跑，于是又顺手让 Codex 写了个 tsreplace-trim-directory。大概就是先生成 .processing，用 TSDuck 检查完再替换原文件，空间不够、文件还在录或者检查失败就不动原文件；省不到 10M 的也懒得替换了。处理结果扔进 TSV，下次再跑会自动跳过已经搞完的，失败的继续重试。

另外红白歌会这种数据放送可能以后还有点纪念价值，所以顺手做了节目名保护，不会给它 trim 掉。总之又抠出来了一点硬盘空间，完整代码还是放在我的 tsreplace fork 里了。

KonomiTV 魔改

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

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

总结

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

完