大赛即将开始，你准备好了。不久前，这意味着你需要通过天线、有线电视或卫星电视机顶盒调频收看比赛。今天，你可以随时随地打开电视、笔记本或手机上的流媒体应用。这是巨大的便利。
然后，比赛进行中，隔壁邻居的欢呼声穿过墙壁传来，或者你的手机弹出比分提醒，而你屏幕上的事情还没发生。你到底是在看此刻正在发生的事，还是看一分钟前发生的事？”一分钟”毫不夸张。在最近两届超级碗上，延迟测量机构 Phenix 于 2025 年 [1]、Stats Perform 于 2026 年 [2] 的测量显示，流媒体的平均延迟比现场动作滞后 26 到 78 秒不等。
这可不算是真正在”直播”看比赛，对吧？而这背后有具体的原因。
十多年前，作为爱立信的一名解决方案架构师，我曾参与设计并交付一套基于 DVB-S2 的端到端卫星直播到户（DTH）电视系统。如今，流媒体已经是数百万人观看直播体育的方式。这一转变令人瞩目，但它伴随着某些取舍。
问题不在你的路由器
在直播流出现问题时，许多观众会认为问题出在自己这一端。他们看到转圈的加载图标，就怪罪那个自己熟悉、也一直在付费的网络——自己的网络。这种本能，和当年《黑道家族》突然黑屏时许多观众以为有线电视出故障了一样。在最近一项调查中，31% 的 NFL 流媒体观众表示他们为了让体育直播更流畅而升级了网络套餐、Wi-Fi 或路由器，另有 31% 表示考虑过这样做。更好的连接确实能减少卡顿，但对整条分发链路上因编码、封装和缓冲而引入的延迟，帮助不大。
为点播而生
如今的 HTTP 流媒体大多依赖一些非常适合视频点播（VoD）的技术。在点播里，不中断、画质好远比时间点重要。如果电影播放器缓冲了 30 秒视频，没人会注意。而对一场直播比赛来说，同样的缓冲垫就是在现场动作之外再加 30 秒延迟。
视频被切成普通 Web 服务器就能分发的短分片。内容分发网络（CDN）把热门内容缓存到离观众更近的地方，播放器则缓冲视频分片以应对中断，并在带宽下降时调整画质。直播流媒体使用了其中大部分架构，但缓冲带来了取舍：以可靠性为代价，换来额外的延迟。
这几秒钟是怎么累加起来的
直播内容在抵达观众之前要经过两大阶段。首先是网络方，也就是内容提供商，比如 ABC 或 Fox，由它们拍摄并制作这场比赛：摄像机、机位切换、图文、主控，有时还包括有意的播出延迟。随后，网络方通过卫星、光纤或 IP 连接，把信号交给地方电视台、有线电视和卫星运营商以及流媒体服务商。
视系统而定，分发方可能会解码、重新编码、加密或重新封装信号，从而进一步增加延迟。在超级碗 LX 上，Stats Perform 测得无线广播电视比场上动作滞后 19 秒，有线电视为 38 秒，而 Peacock 为 48 秒，其他流媒体服务为 53 至 62 秒。在最近两届超级碗中，网络方自家的服务都是最快的流：2025 年的 Fox 的 Tubi，以及 2026 年的 NBC 的 Peacock。这表明更直接的信号馈送可以避开额外的处理环节，以及随之而来的部分延迟。
第二个阶段。向观众分发才是各种技术真正拉开差距的地方。在我参与的那套 DTH 系统里，这一阶段从信号获取一直延伸到用户家中的机顶盒。频道被编码、复用、加扰，并发送到 22,300 英里高的地球同步卫星，再下行到天线锅，这段旅程尽管距离遥远，却只需约四分之一秒。由于信号以恒定速率到达，机顶盒只需要很小的缓冲区。在那套系统中，这一阶段增加了约 4 到 6 秒，主要来自编码和缓冲。这还不包括更早的制作延迟。对接收同一路信号的观众来说，这部分附加延迟是可预测且一致的。
流媒体的分发阶段有其自身特点。在流媒体平台上，视频被编码成多个码率，封装成通常持续 2 到 6 秒的分片，然后经源站服务器、CDN、观众所在 ISP 和家庭网络发送出去。在传统流媒体中，播放器接收完整分片，并在播放前额外缓冲一部分视频。卫星的分发阶段只增加几秒固定延迟；传统流媒体通常增加得更多，而且其中一部分延迟因观众而异。它取决于网络状况与负载、设备行为以及播放器的响应方式。一次卡顿就可能把观众进一步推离直播进度。在超级碗 LIX 上，Phenix 发现同一个服务中最快与最慢观众之间的差距从 39 秒到 57 秒不等。
谁掌控这条路径
卫星和传统有线运营商基本掌控着自己的分发网络。流媒体服务商通常并不控制整条路径。它们的视频可能经过 CDN 基础设施、与观众 ISP 的互联、ISP 的骨干网和城域网，最后经过一条共享接入网络——比如一个服务数十户家庭的有线节点或光纤分路器。一些 OTT 服务运行自己的 CDN、私有骨干网或部署在 ISP 内部的缓存，但大多数无法控制观众所在的 ISP 网络或共享接入链路。网络是按忙时流量规划的，但一场大型直播赛事仍可能在数百万人同时收看时造成瓶颈。一旦家庭连接快到足以承载这条流，更快的套餐只提高该观众自己的速度上限，而不会提高上游共享链路的容量。播放器的缓冲就是对这种不确定性的保险，而这份保险就是延迟。
CDN 仍然不可或缺，但一个直播分片无法提前缓存到观众附近：它只在数百万人同时请求它之前的几秒钟才被创建出来。而且与点播不同，直播播放器无法下载尚未生产出的视频。要建立更大的缓冲区，它就必须播得离现场动作更远：每一秒的保护，都是另一秒的延迟。
然后是规模问题。一个广播信号无论是一名观众还是上千万观众收看，所需容量都相同。而流媒体需要为每位观众建立一条独立的分发连接，即便 CDN 缓存把同样的分片提供给了许多观众。
如何缩小差距
最直接的解决办法是减少封装和缓冲带来的延迟。分块式 CMAF 配合 LL-HLS 或 LL-DASH，可在完整分片就绪之前就以小片段的形式传输视频，大幅削减分发延迟。代价是缓冲区更薄、卡顿风险更高，这也是包括 YouTube TV 在内的一些服务把低延迟作为可选项提供的原因 [9]。WebRTC 这类实时协议可以做到 1 秒以内，但要扩展到数百万观众则更难、成本更高。
另一个办法是更多地掌控分发：更直接的节目信号馈送、在运营商网络内部署缓存，以及在支持的地方使用组播，让一次传输服务多个观众。
最后，流媒体可以向广播借鉴。下一代无线电视标准 ATSC 3.0 让电视机能把广播信号与互联网连接结合起来，而 5G Broadcast 把广播接收能力带到兼容的手机上 [10]。在这两种方案里，一次传输就能覆盖范围内所有观众，从而消除一个主要的拥塞与可变延迟来源——尽管编码、封装和接收端缓冲仍会增加延迟。这些方式使用的是广播式分发，而非传统的”每位观众一路”的 OTT 流媒体：它们需要频谱、发射机和兼容的接收设备，而这些是 OTT 服务商无法掌控的，因此对拥有自家流媒体服务的广播机构，或与它们合作的 OTT 提供商来说，最具吸引力。
对观众来说，在有低延迟选项时选择低延迟设置，或重启已经落后的流，都能有所帮助。但两者都无法消除服务本身内置的延迟。
那么，流媒体让电视直播变得更好了吗？更易获取、更灵活——是的。更”直播”——还没有。
这一差距反映的是关于可靠性、规模和分发的工程取舍。流媒体是电视直播前进的方向，假以时日，它很可能自己就能弥合其中大部分差距。在那之前，它可以通过减少不必要的处理和缓冲、更多地向广播借鉴而非彻底取代广播，来更接近”直播”。
参考资料：
【1】https://blog.phenixrts.com/phenix-superbowl-latency-study-2025
【2】https://thedesk.net/2026/02/stats-perform-phenix-latency-super-bowl-lx/
作者：Radostin Pachamanov
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/yinshipin/73219.html
