Castor 实战：从网页播放器到 DLNA 电视，先发现设备再转码投放
把浏览器标签页完整镜像到电视，当然是最容易想到的办法；但它也把桌面通知、鼠标移动和整个浏览器渲染链路一起带了过去。对于自己有权播放的网页视频或已知媒体流，更干净的路径是：找到真正的媒体请求，在本机统一转码，再把结果交给局域网里的播放设备。
Castor 是一个 MIT 许可的 Go 项目，最新发布版本为 v1.4.3。它面向 DLNA/UPnP 电视：可以发现设备、启动无头 Chrome 观察页面网络流量、尝试触发播放，然后借助 ffmpeg 实时转码并投放。项目也提供实验性的 Chromecast 支持，但 README 明确标注为“已实现、未测试”；本文把 DLNA 当作可验证的主路径。
这里的边界很重要：Castor 不提供片源或内容目录，也不解密、绕过 DRM。它只能处理你提供且有权使用的页面或流地址；受 DRM 保护的服务不能靠它投放。这不是一个规避版权或平台规则的工具，而是一条针对自有内容、公开测试流或获授权服务的本地播放管线。
先理解它省掉了什么
屏幕镜像把浏览器最终绘制的像素实时编码发送。Castor 的路线不同：它在播放器页面中运行无头 Chrome，通过 Chrome DevTools Protocol 观察网络活动，并执行一段短的播放动作链路——点击页面、必要时进入最大的 iframe、再点击一次。找到可播放的流后，ffmpeg 负责把输入整理成目标设备可接收的输出，电视从 Castor 的本地 replay server 拉取媒体。
这解释了它的优势和限制。优势是电视接收的是专门的媒体管线，而不是整个桌面；限制是网站必须允许自动化播放，页面里的媒体请求也必须可被正常提取。登录态、复杂交互、跨域播放器或 DRM，都可能让“打开页面就投放”失败。遇到这类情况，不要把失败归因于电视，先确认浏览器中是否能正常播放，再把 Castor 当作排查链路的一环。
第一步：用扫描确认电视真的在局域网里
原生二进制需要 Chrome 或 Chromium、ffmpeg 和 ffprobe 都在 PATH 中。macOS 可按 README 提供的方式安装：
brew install --cask stupside/tap/castor
不想依赖预编译包时也能从源码构建：
git clone --recurse-submodules https://github.com/stupside/castor.git cd castor make
这里不要替换成看似等价的 go install。项目的 Whisper.cpp 绑定通过本地 replace 引入，并依赖预先构建的静态库；README 明确说明 go install 不适用。源码构建还需要 Go 1.26+ 与 cmake。
安装后先扫描，而不是急着写配置：
castor scan
Castor 面向实现 MediaRenderer:1 配置的 DLNA/UPnP 设备。扫描到设备后，把输出中的名称原样放入当前目录或平台配置目录的 config.yaml：
device: name: "Living Room TV" type: dlna
name 是精确匹配，不是给设备起昵称的字段。最常见的“找不到设备”问题，往往就是手工改写了扫描结果、电视和电脑不在同一 VLAN，或访客网络阻断了设备发现。
第二步：先投放一个已验证的页面
配置完成后，可以将一个你拥有访问权的页面交给播放器模式：
castor cast player https://example.com/watch/some-video
这个命令不是万能 URL 下载器。它会尝试在页面中触发播放并提取可用网络流。因此第一次试验应选择浏览器已经能正常播放、无需额外确认弹窗的内容。若失败，按下面的顺序缩小范围，比反复换命令更有效：
- 先在同一台机器的正常浏览器里确认页面能播放；
- 检查 Chrome/Chromium、
ffmpeg、ffprobe是否真能从终端找到； - 再执行
castor scan，确认配置中的设备名没有变化； - 只在无 DRM、自己有权播放的内容上测试，避免把内容保护误判成网络故障。
如果目标是已有的直接流地址，README 也说明可以将流交给 Castor；但不要从网页源码或网络面板猜测临时签名地址并写进自动化脚本。此类地址通常会过期，也可能带有授权范围。把页面入口或经过授权的稳定 URL 作为团队配置，比复制一次性的媒体请求更可维护。
字幕、缓存与配置：把便利功能留在可控范围
Castor 可以为转码结果烧录自动生成的字幕。项目的默认模型配置指向会自动下载的 ggml-tiny.en，体积约 75 MB；这适合把英文演讲或测试素材快速变成电视上可读的画面，但不应把“有字幕”误解为“有可靠转写”。音质差、多人重叠、专有名词和中英文混说都会影响结果。涉及会议记录、培训材料或合规内容时，自动字幕只能作为观看辅助，正式文稿仍应回到原始录音和人工校对。
也应提前决定哪些状态可以持久化。Docker 示例把 castor-cache 挂到 /root/.cache，目的在于避免每次容器退出后重新下载模型或重建可复用缓存；而 config.yaml 则应由宿主机以只读配置文件的方式管理。不要把账户 cookie、临时播放 URL 或包含业务标题的调试日志混入通用镜像层和共享卷。对多人共用的客厅电视或会议室电视，尤其应把“谁能发起投放”和“哪些主机可发现设备”当成网络权限问题，而非单纯的播放器设置。
一个实用的上线顺序是：先用公共测试页验证扫描和基本投放；再在隔离网络里验证目标格式；最后才接入有登录态的业务页面。每次变更浏览器版本、电视固件、网络隔离策略或容器运行位置后，都重跑一次 castor scan。这样能把设备发现的回归，与页面提取或转码回归分开记录，避免在故障发生时同时修改三个变量。
Docker 的关键不是镜像，而是网络模式
项目提供 Linux-only Docker 镜像，内含 Chrome、ffmpeg 与 ffprobe。在 NAS 或 Linux 主机上可先用它扫描：
docker run --rm --network host ghcr.io/stupside/castor:latest scan
配置文件准备好后再投放：
docker run --rm --network host \ -v "$PWD/config.yaml:/config.yaml" \ -v castor-cache:/root/.cache \ ghcr.io/stupside/castor:latest \ cast player https://example.com/watch/some-video
--network host 不是可有可无的性能参数。README 说明设备发现使用 SSDP 多播，而电视还需要回连 Castor 的 replay server；默认 bridge 网络无法保留这两条局域网路径。这个结论也意味着 Docker Desktop 上的同名参数不能解决 macOS/Windows 的问题：容器仍在 Docker Desktop 的内部 VM 子网，扫描可能为空。此时更可靠的选择是运行原生二进制，或使用真正桥接进局域网的 Linux VM。
把它当作一条可观测的本地管线
Castor 的价值不在于替代所有投屏方式，而在于把“网页播放器 → 网络流 → 转码 → 电视”的中间环节从黑箱变成可定位的组件。扫描失败，优先看 SSDP 与网段；页面无法启动，优先看自动播放、登录和 iframe；有流但电视不播，再看转码输入和设备兼容性。每一步都有不同的所有者和排错方法。
对家庭实验室、会议室演示或个人媒体工作流而言，这种拆分尤其有用：让播放设备只处理媒体，让浏览器只负责发现来源，让本机转码承担格式适配。但在投入自动化前，仍应为内容来源、局域网隔离和日志留存设边界。技术上能把流送到电视，不代表每一个站点、每一种账号权限或每一份内容都应该被自动化处理。把来源授权、设备可见范围和故障记录一起纳入部署清单，最好明确、完整地记录测试时间、目标设备和网络位置，才能让这条本地媒体链路既方便，也不成为家庭或团队网络里难以追溯的例外。
相关链接