在Quicly项目初期，我们发现一个问题：当用户拖动观看区域时，对应的图块会出现消失现象。经过调查，我们发现问题在于播放器在拖动过程中重新启动了，而非图块本身的问题。这揭示了流媒体播放不能简单地像普通网页元素那样处理。
Quicly项目由Gabriel Natter和我共同启动，设定了一个实际边界：贡献编码器无需进行任何改变，数据继续通过SRT传输。Quicly负责将每路视频转换为适合浏览器播放的格式，并通过Media over QUIC协议发布出去。最终，观看者能够通过一个iframe界面，自由调整不同视角的大小、位置，甚至切换播放状态。
公开的无账号演示版本采用了四路同步视频数据，任何人均可无需编码器或账号尝试交互功能。2026年7月31日，我们测量了实时SRT到MoQ的路径，得到的683毫秒延迟数据来自控制状态下实时输入测试。
部署路径保持简洁，从编码器到浏览器，包括SRT传输、Quicly处理、Cloudflare的中继服务。Quicly负责媒体准备、发布、检查准备状态、用户会话控制和可嵌入的多视角界面。Cloudflare则提供从编码器到用户浏览器的中继服务。
我们重新设计了播放器生命周期，确保每个会话在播放期间保持稳定，即使视觉布局发生改变。这也使得多视角观看体验更加流畅稳定。
为了测量延迟，我们在每个视频帧中嵌入发送方的时间戳，并在浏览器播放器旁边显示当前时间。测试结果显示，经过Cloudflare中继的六次测试，平均延迟为683毫秒，误差范围在20毫秒以内。
另外，我们注意到在广播连接到首次媒体展示过程中，准备时间从5.1秒大幅缩短至0.6秒。该测试强调了使用实际编码器和网络进行真实延迟测量的重要性。
在多视角支持上，Quicly也进行了一些优化。比如，通过明确标识支持的媒体格式，检测浏览器实际能力，避免了因格式不支持导致的黑屏问题。当检测到播放问题时，Quicly会自动重新建立播放器，而不会影响其他视频流。
通过与Cloudflare的紧密合作，Quicly获得了可靠的互联网分发路径，实现了从编码器到浏览器的无缝连接。隔离的MoQ中继和过期、可撤销的发布订阅凭证使得Quicly能够轻松从开放评估过渡到受控部署。
最终，Quicly将直播贡献流转换成用户可控的多视角界面，能够直接嵌入网页中一个iframe中。它不仅管理了媒体准备、按角度发布、检测、恢复和诊断等功能，还为浏览器提供直接控制无须服务器渲染合成的视频流。
团队可以通过无账号演示版本快速评估交互性，也可通过自己的编码器和网络进一步验证直播路径。