我用 WorkBuddy + DeepSeek把电视直播塞进了家里的极空间 Z4

一、先说个背景

人到中年，家里那点玩意儿基本就那几样——NAS、路由器、一堆充电头，说是"老登三宝"也不算冤。我这三样一样不少，NAS 里囤着几 T 从来没看完的片子，路由器刷了个梅林，基础设置完成后，就再没进去过了。

要说不想把家里这些设备玩明白，那是假的。可真要动手，第一关就卡住了：攻略。

张大妈上那些教程，图文并茂，动辄三千字，还得分清楚哪个是"必须做"哪个是"看情况"。看完一遍，脑子是热的，手是凉的。等你坐下来照着做，第一行命令就报错，然后你就得去翻楼中楼，翻到第三页，发现楼主两年前就弃坑了。

所以这些年我的状态一直是：东西齐全，想法很多，一个没落地。

转折点是这半年桌面 agent 越来越火。我一开始也是抱着看热闹的心态，后来慢慢觉得——攻略看不懂没关系啊，我可以让它替我去翻、去试、去报错、去改。我不需要先学会，我只需要把现象描述清楚。

这个念头一起，就压不住了。

于是就有了这一整天的折腾。二、我家的观影需求，其实就两处：

客厅

一台电视，接 Apple TV 4K 三代。电视本身是台老机器，能看，但智能系统早就卡得不成样子，所以真正干活的是 ATV。上面装了 APTV，看直播用。

看着挺美好，实际痛点一大堆：

1.遥控器三只。电视一只、机顶盒一只、ATV 一只。我妈来我家看电视，我得先给她讲十分钟哪个遥控器开哪个。

2.换台要切换信号源。想看央视，得先切到机顶盒的 HDMI；想看流媒体，得切回 ATV。切来切去，每次都点错。

3.机顶盒那套 UI 一言难尽。遥控器反应慢半拍，菜单三层起步，找个回看能点到我怀疑人生。

4.最要命的是，机顶盒只服务一台电视。卧室想看得再买一台，还得再交一份钱。

主卧

一台投影，爱普生 EF-10，1080p、1000 流明、无 HDR。画质放现在不算好，但架不住躺在床上看球是真的舒服。旁边插着一台闲置很久的斐讯 T1 盒子，本来是我当年折腾剩下来的。

痛点更直接：

1.卧室网线断在墙里了，机顶盒搬过来白搭。

2.T1 里啥也没有，装过几个直播软件，不是广告满天飞，就是跑两天就失效，老早就弃用了。

3.想在床上看个球，最后还是得掏出手机投屏，投一半来个消息，画面跟着弹窗。

于是就有了那个念头

既然客厅有一台 Apple TV，卧室有一台闲置的安卓盒子，那能不能把运营商那台机顶盒彻底 ban 掉，让它只负责"授权"，画面交给这两台设备？

说白了就是把运营商的电视信号，变成局域网里的一个网址。谁想看电视，谁用自己设备上的播放器去连。技术上这叫"组播转单播"，技术也是很成熟的了，但是我一直没弄，因为懒。但是现在，有人帮你干，你还怕啥，对吧？

三、盘家底，定方案

极空间 Z4，x86 芯片，双网口，二十四小时开着；

华硕 AX86U，主路由，全家网络都挂在它下面；

Apple TV 4K 三代，客厅主力播放设备，朋友忽悠的产物；

斐讯 T1，卧室闲置盒子，理财产品，不忍回忆；

爱普生 EF-10，卧室投影，跟随我5年的老家伙了，舍不得淘汰。

方案其实就那么几个：

一，换一台带 IPTV 功能的路由。 华硕其实有这功能，但它有个硬件限制——开了 IPTV 之后组播路由会被强制关掉，等于此路不通。

二，买台能跑 OpenWrt 的软路由，专职做转播。 这也是我当时问 DS得到的建议，于是我下单了一台 GL.iNet 的 GL-MG1300，双网口、小巧、便宜。

三，直接用那台已经开着的NAS。

当时的我，毫不犹豫选了路二。

理由都不好意思说：我是真的懒。想那么多，要死多少脑细胞，就听蓝色大肥鱼的算了。

——这台 GL-MG1300 就是我这次交的第一笔学费。它最后基本没派上用场，白花了钱。具体怎么白花的，后面说。

四、第一步就走错了

GL-MG1300 到手，一 个WAN口 一 个LAN口，OpenWrt 22.03.4，mipsel 芯片。

做法是把 WAN 从网络配置里摘出来，单独建一座桥 br-iptv，配一个假地址专门用来发"我要看这个台"的请求（IGMP），然后在桥上跑一个叫 udpxy 的老牌程序，它负责把组播转成 http 地址。

第一次跑通的时候还挺激动——PotPlayer 里输入地址，画面出来了。

标清频道 9 Mbps，看着挺正常。我心里想，这不就成了吗。

然后麻烦就开始了。

看个十几分钟，画面一卡，转圈，两三秒回来。有时候直接半分钟。频率还不固定，有时候五分钟一次，有时候一分钟两次。

日志一看：udpxy: write_data: writev: Invalid argument。writev 返回 EINVAL，意思是它手里拿着一个长度为 0 的缓冲区，没东西可写。而 udpxy 的处理方式是——直接把客户端踢掉。更气人的是连锁反应。被踢的是唯一那个客户端时，udpxy 顺手把组播订阅也停了。上游一断，播放器只能干等超时重连。所以我每隔几分钟看到的那几十秒黑屏，大部分不是信号断了，是它在重连。

五、我先后四次以为找到了原因

这部分是我最想写下来的，因为它特别典型——每一次"有改善"，都把我往错的方向推了一步。

第一次，我怀疑缓冲太小。 把 udpxy 的 -B 加大，顺手把内核的 net.core.rmem_max 也放开——系统默认只给 208 KB，程序申请 2 MB 会被砍回来，等于白设。改完丢包率从 2.2% 降到 0.12%，肉眼可见地好了点。

断流照旧。

第二次，我怀疑那台小路由器扛不住。 把它固件里自带的几个后台服务全停了：多 WAN 健康检查 kmwan（它会把这个啥也没接的 WAN 当成断网，隔一会儿重试一次）、联发科硬件 NAT mtk-hwnat-post（把桥接组播的流转交给加速单元，表项一过期流就断，内核还不吭声）、流量统计 tertf。

这次有点效果，TCP 连接被重置的频率明显降了。但那个 writev 报错，一次没少。

第三次，我想绕一层。 用 socat 把客户端连接改成走本机回环，让 udpxy 只面对一个"不会抖"的对端。结果报错从踢真实客户端变成了踢中转进程，Broken pipe 换了个马甲。

第四次，我决定换掉它。 查了 msd_lite，它对上游瞬断是等不是断，理论上正对症。可惜 OpenWrt 官方源和 ImmortalWrt 的 mipsel 仓库里都没有现成包，自己编译的成本比换思路还高。

到这儿我算是认了：udpxy 这个 2018 年的版本，遇到任何停顿就主动断连，这是设计问题，参数调不掉。

顺带说一句，那台 GL-MG1300 在这里也把自己的短板暴露完了：mipsel 架构、单核性能弱、固件里塞了一堆用不上的私货服务。它不是不能干活，是这个活它干不利索。

钱是花了，教训是：不要因为自己的懒惰就把拍板的事情全交给AI。

六、换个脑子：为什么不用 NAS

真正让我转弯的，是一个特别朴素的问题——

家里那台 Z4，x86 芯片、八核、内存富余、二十四小时开机，我为什么非要在一台 mipsel 的小盒子上抠性能？

想通这一点，后面的事就顺了。

我决定不用现成软件了，让 AI 现写一个。核心逻辑就一个：

宁可让客户端等，也绝不断开连接。

上游断多久就等多久，不报错、不关连接。

客户端慢了就丢最旧的数据，连接保持。

多个客户端共用一个组播订阅，不重复请求。

百来行 Python，workbuddy帮我写了，也不用装任何第三方库。实测 4K 频道 25 Mbps 满速转发，单核占用不到 15%。

七、换到 NAS 上，又踩了四个坑

坑一：绿屏

第一版打开就是一片绿，进度条卡在 0%。

一开始我以为是源不对，或者地址填错了。后来把原始数据抓下来看，才发现是封装的问题——

运营商发过来的不是裸的 TS 流，而是 RTP 封装。​ 每个 UDP 包恒定 1328 字节，拆开来是 12 字节 RTP 头 + 1316 字节，而 1316 正好是 7 个 188 字节的标准 TS 包。

打个比方：画面数据是货，运营商每发一包，外面都套了个快递盒，盒盖上贴着 12 个字节的运单——包序号、时间戳之类的信息。

而我干的事，是把货和箱子连运单一起，原样卸给了播放器。播放器不认识那张运单，它每读 1316 字节的货，就得先啃 12 个字节的乱码，啃完还按原来的节奏往下对——就像一本书每页里都被插进半行不相干的字，翻两页你就找不到行在哪儿了。​

所以绿屏不是没收到数据，是收到了、但拼不回画面。进度条卡在 0%，说的就是这件事。

 改法：开箱，只给货。​

具体做法是把前面那 12 个字节剥掉。但剥之前得先验证自己没剥错——真正的 TS 数据开头一定有个固定标记 0x47，剥完对上了才放行；对不上，说明这层壳压根不是我以为的那种，那就原样交出去，别自作聪明。

改完，绿屏没了。

坑二：花屏

画面正了，但时不时冒出一块块马赛克。

技术上第一步要查的是“包序号的连续性”。正常一路流里，同一个视频通道的包是挨着编号往上走的；中间跳号，就说明有包丢了，或者混进了不属于这一路的数据。

我做了个前后对比。修好之后那一段，采样里的视频包有一万四千五百多个，编号只跳了9次；出问题的时候，同样长度的采样里视频包只有七千三百多个，跳变却有1640次。

包数只有一半，跳变多了一百多倍。这已经不是“偶尔抖一下”的程度了，是有一大批包根本不来自当前这一路视频。

查下来是Linux的一个默认设置：IP_MULTICAST_ALL。它默认为1，意思是组播套接字不只收自己加入的那个组，而是把本机上所有已加入组的数据都收进来。

打个比方：你家这栋楼的快递全送到同一个收发室，而收发室的规矩是“凡是送到这儿的，一律收下”。​你只订了一份报纸，结果隔壁订的杂志、楼下订的零食，全堆你桌上了。

更麻烦的是，所有频道用的都是同一个端口。在系统看来“门牌号一样”，连最基本的区分都没有——你在看央视一套，别的台的包照样往你这儿塞。

这些本不属于这路流的数据混进来，解码器拼画面的时候自然对不上，表现出来就是一块块马赛克。

解决只要改一行：把那个“一律收下”的开关关掉，让它只收自己订的那一份。​

改完这一行，花屏消失。

坑四：4K 卡，高清不卡

这个坑最有迷惑性——同一套程序、同一个网络，凭什么只有 4K 不行？

技术上查的是“套接字实际拿到了多少接收缓冲”。​ 我在程序里申请了 8 MB，但查出来并不是这么回事：系统给的上限 net.core.rmem_max 只有 212992 字节，所以套接字实际只拿到 425984 字节——连申请的零头都不到。

打个比方：你跟物业申请一个能放八箱货的货架，物业表示“这栋楼每户最多给一格”，最后就给了你一个格子。你以为自己有个大货架，等快递一多才发现，格子满了，新到的件装不进去，就被扔了。​

而这个格子能顶多久，取决于来货有多快：标清 9 Mbps，三百多毫秒才填满；4K 是 25 Mbps，一百四十毫秒就见底。同样是抖一下，标清的格子还有富余，4K 已经满了开始退货。​ 这就是为什么偏偏 4K 卡。

解决是把上限放开到 32 MB，套接字这才真拿到了 8 MB——标清能撑七秒，4K 也有两秒七。

四个坑填完，指标全绿。

该好了吧？

没有。

八、真相是一根网线

那时候的状态是：TS 对齐完美（31920 个包同步字一个不缺）、连续性计数器只有重复包没有跳包、客户端以恒定 26.97 Mbps 拉流、内核 UDP 丢包增量为 0。

画面还是每秒顿一下。

那天下午我真的是折腾的累了，一度想放弃了。

但我最终还是做了一个无比正确的决定——把运营商那台机顶盒打开，播同一个频道，摆旁边做对照。

机顶盒一点都不花。

同一路信号，同一时刻，它啥事没有，我这边不卡成PPT。那问题百分之百在我这一侧，而且在一个一直没看过的地方。

顺着查极空间的网卡计数器：

rx_crc_errors = 36694
rx_dropped    = 每秒 +1

那根网线，每秒在物理层损坏一个数据包。

机顶盒为什么看不出来？机顶盒用的不是一根网线...

换了一根成品网线，顺手换了个光猫端口。再看：

RTP 序列号缺口：30000 个包，0 次

我在软件里找了五个小时，答案在一根网线上，这根网线不是成品网线，是我自己压的...

这一段我建议所有折腾网络的都吸取教训：当所有指标都正常、但体验就是不对的时候，先去找一个"正常"的设备做对照。 别在一个死胡同里铆劲钻了。

九、APTV 三个开关，治好了看球的拖影

流畅之后又发现新问题：看球的时候，球员身后拖着影子。

这次学乖了，先看数据。解析 SPS 出来是这样的：编码 H.264 High profile，frame_mbs_only_flag = 0——隔行，标准 1080i50。

这种信号是把一幅画分两场画的，上半场和下半场。播放器要是不去做合并，快速运动的地方就会留残影。

打个比方：就像翻页动画，本来一张纸要叠两层才算一帧，你只翻了一层就往下走，快速动作自然糊。​

解法是三个开关，分别在两个地方，缺一不可。

APTV 里有两个。一个叫反交错，负责把两场合成完整一幅，消掉运动边缘的梳齿；另一个叫帧率翻倍，把每个场当成一帧输出，25 帧变 50 帧，快动作明显更顺。

第三个在 Apple TV 系统里，叫匹配帧率，让 50Hz 的信号按 50Hz 输出，不硬转成 60。

只开第一个，拖影没了但快动作还有点顿；三个都开，才是看球该有的样子。

顺带说卧室那台斐讯 T1。S912 的芯片，原厂固件锁语言、渲染层老。Kodi 装了插件，设置页始终空白；Perfect Player 一进设置就白屏；Televizo 官方只给拆分包，基础包里连原生库都没有。最后用 VSTV，装上就能用。 VSTV，顶！

十、现在什么状况

以前是什么样？每 1 到 5 分钟就断一次，4K 忽高忽低、偶尔掉到 1.7 Mbps，内核 UDP 丢包一直在涨，家里还差点额外多养着一台小路由器。

现在？看直播再也没中断过，4K 稳在 25 到 27 Mbps 之间几乎不动，内核 UDP 丢包 0，客户端队列丢包 0，那台小路由器...退又不好意思退，留下看下次折腾哪里能用吧。

当一切尘埃落定之后，我坐下来开始好好看电视，我忽然发现：

现在这台 Apple TV，是真的把电信那台机顶盒按在地上摩擦的。​

换台是秒切的，界面是 ATV 的简洁界面，让人一眼舒服；一台设备看两个房间，机顶盒已经被我仍柜子里去了；4K 频道满速，看球的时候，那叫一个丝滑。最重要的是我妈来我家，现在只需要一个遥控器。

硬件顶才是真的顶。

十一、写在最后：AI 真正帮我做到的，是把“想”变成“做了”

这件事做完，我最大的感触在于门槛真的降了，与技术无关。

以前我看到“组播转单播”这五个字，第一反应是关掉页面。不是学不会，是预估学习成本太高：要翻攻略、要排雷、要处理一堆别人环境里没有的意外。中年人最缺的就是这种整块的、不被打断的时间。

而这次，我做的事情其实很“业余”。我不会抓包，我只会说“画面卡了，你帮我看看为什么”；我不懂 RTP 封装，我只知道“绿屏了”。

我做的判断只有一件：当它说是网络问题、我觉得不像的时候，我说，咱对比这看看机顶盒卡不卡。​

剩下的事，是它一次一次跑命令、贴数据、改代码。几十轮下来，一个原本我不会碰的事情，就这么磕磕绊绊的落地了。

所以如果你也有一件“想做但一想到过程就头疼”的事——我建议你试一次。​ 不用先学会，先开口就行。

附：实操攻略

前提是三条：极空间 Z4 双网口机型、光猫有独立 IPTV 口、NAS 能开 SSH。下面所有地址都用占位符，替换成你自己的。

第一步，接线。​ 光猫的 IPTV 口接极空间网口二，路由器LAN口接极空间网口一（我接的路由器2.5G网口）。

第二步，配双网口。​ 极空间后台进「双网口设置」，模式选独立（解绑 Bond）​。

给网口二配静态地址，比如 10.0.0.3/24，网关和 DNS 空着。配完确认一下：ip -br addr show enp3s0 应该显示 UP 10.0.0.3/24，ip -br addr show enp4s0 应该显示 192.168 段的地址。

第三步，开 SSH。​ 后台「远程协助/SSH」打开，然后点“应用并重启 SSH 服务”，默认端口 10000。

第四步，放三个文件。​ 主程序 iptv-relay.py 拷到 /usr/local/bin/，服务文件 iptv-relay.service 拷到 /etc/systemd/system/，内核参数 99-iptv-relay.conf 拷到 /etc/sysctl.d/。

第五步，调内核和网卡。​ 先 sudo sysctl -p /etc/sysctl.d/99-iptv-relay.conf 放开缓冲上限；再 sudo ethtool -G enp3s0 rx 4096 tx 4096，把网卡硬件队列从默认 256 提到 4096。

第二行一定要写进服务的 ExecStartPre，否则重启就回到 256，4K 又开始卡。

第六步，启动服务。​ 执行 sudo systemctl daemon-reload，再 sudo systemctl enable --now iptv-relay。配置里写了 Restart=always，崩了三秒自己爬起来。

第四步到第六步都可以让workbuddy帮你生成。

第七步，看状态页。​ 浏览器打开 http://你的NAS地址:4022/status，正常会看到一行频道信息，下面跟着每个客户端的时长、累计流量、实时速率和 drops 计数，比如 6167.5 秒、6617.1MB、9.00Mbps、drops=0。 谁在拉、拉了多久、多少速率、有没有丢包，一眼全在。

想看单频道能不能出流，用 curl -m 6 -o /dev/null -w '%{size_download}' http://你的NAS地址:4022/udp/组播地址:8231。标清大概 6 MB，4K 约 18 MB。

第八步，播放器。​ APTV（Apple TV）或 VSTV（安卓盒子）里新建订阅，地址填 http://你的NAS地址:4022/iptv.m3u。APTV 里记得把反交错、帧率翻倍打开，系统里把匹配帧率打开。

最后是三条关键提醒。只在内网用，不要开外网端口转发，否则你家里怕是以后就不用看直播了（也不是不行）；NAS 系统升级可能清掉 /usr/local/bin 和 /etc/systemd/system 下的文件，照第四到六步重装。

还有一句：如果你只想看不想折腾，那就别折腾。运营商那台机顶盒虽然难用，但它真的很稳。这套方案的意义在于，你家已经有一台二十四小时开着的设备，它能顺手把这件事干了，而且干得比机顶盒好。

作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～