webcodec、websocket 和 webtransport

hi! 我和我的 s/o 每天都在使用 neko,我们非常喜欢它。它非常棒,我非常感谢所做的所有工作。 我从家庭网络中的一台机器上托管了 neko(这样我就可以利用 igpu)。围绕 webrtc 的所有东西(ICE/TURN)都有 bug,我经常不得不重启 neko 服务器才能让一切正常运行。我还必须添加一个特殊的防火墙规则,以便正确路由 UDP 到 Docker 容器,这样我就可以根据网络设置来使用它。 我看到计划添加更多流媒体后端。我看到 #508 是对 websocket 的最初尝试,我想尝试使用你在那个线程中提供的反馈来完成此任务。我也是 webtransport 的忠实粉丝,自第一个草稿发布以来就一直在与之玩耍,并且希望为 neko 实现此功能,因为它是标准化的,实现的,并且非常适合使用案例。 我的实现使用 webcodecs 而不是 fmp4/mse,因为延迟要好得多。即使调整 mse 为 20ms 后,webcodec 仍然感觉更好。webcodec 还有一个优势,就是支持 vp8 和 h264。 完整免责声明 - 每一行代码都是由 LLM 生成或编辑的。当然,这个问题是手写的,我还手动审查并迭代了所有三个 PR 的每一行代码。尽管如此,我还没有花时间来完善注释,并与现有代码的约定相匹配。 我用三个 PR 叠加在一起,以将功能分离,以便希望更容易查看、合并和逐步修复。 1. https://GitHub.com/tuxpainter/neko/pull/1 改变了媒体订阅路径,这使得流媒体后端不再是 webrtc 特定的,并且暴露了来自 gstreamer 的定时信息。 2. https://GitHub.com/tuxpainter/neko/pull/2 websocket 和 webcodec 支持。我们通过 websocket 发送字节,并在 vue 客户端中处理。访问 http://localhost:3001/?media=webcodecs-ws 以使用 websocket 版本。 我已经在本地测试了 vp8,看起来似乎正常运行。我还使用传统的 websocket 创建了鼠标/键盘控制 API,以完全消除对 webrtc 的依赖。我使用现有的 gstreamer 流程,我们应该正确支持 vp8 和 h264(我仍然需要测试 h264) 3. https://GitHub.com/tuxpainter/neko/pull/3 webtransport 支持。这是一个大的 PR。webtransport 通过 http3/quic 运行,而 quic 需要 TLS 1.3,因此它需要提供服务器的 TLS 证书。 webtransport 提供了一个主要优势,即集成了 流 API,这意味着使用它,我们可以获得"免费"的反压力处理,而 websocket 后端中并不存在。 我继续使用基于 websocket 的鼠标/键盘控制 API,但未来可能值得使用 webtransport 来控制鼠标,因为 webtransport 支持不可靠的传输模式。