![145e6ca9b74d54e46ab472bdba46f119.png](https://i-blog.csdnimg.cn/blog_migrate/3926468c96bb4188655a566bf5dab3a8.jpeg)
文 / Mark Horchler Broadcast Video
译 / John
原文 https://www.haivision.com/blog/broadcast-video/from-srt-to-cmaf-achieving-broadcast-television-latency-over-the-top/
宽带互联网与高效视频压缩(主要是HEVC)相结合,可让 OTT 视频的图像质量媲美高清广播电视。在某些情况下,例如 4K UHD ,OTT服务的图像质量领先于游戏。然而,存在一个传统广播电视比OTT更具优势的领域——这便是低延迟,简单来说就是将图像捕获并传送到屏幕所花费的时间。
广播电视的延迟通常在5-7秒之间,其中包含用于防止直播画面出现不良内容或制作失误而故意留出的冗余延迟。相比之下,OTT服务最多可能需要45秒才能让观众看到实况内容。换句话说,在事件发生几乎一分钟之后才能关注到该事件实况的挫败感对任何一个利用OTT服务观看直播的观众来说都是一件体验糟糕的事情。
![fae336c98c8a8626c80ba9b8f9f91c96.png](https://i-blog.csdnimg.cn/blog_migrate/a58a51ac52c8b87be862e81543cf562f.jpeg)
减少OTT延迟
对于真正的体育迷来说,传统电视仍然是关注赛场实况的最佳方式。通过将OTT延迟降低到有线电视的水平,Netflix的实时OTT解决方案最终能达到与传统广播公司相竞争的效果。
同时,广播公司可以通过提供第二屏幕视频应用来与OTT竞争。使用移动应用程序或混合OTT机顶盒,广电公司可以提供对现场的多视角呈现从而为观众带来更个性化的观看体验,而实现这一切的前提是OTT的延迟需要达到与广播电视相同的水平。
DVB-I
在欧洲, DVB-I 计划旨在通过将OTT延迟降低到广播电视标准来为所有直播设备带来统一的观看体验。DVB-I基于DVB-DASH,其本身基于MPEG-DASH,这是一种行业标准协议,旨在通过HTTP实现OTT内容的 自适应比特率(ABR) 流传输,同样这也是一套支持万维网的数据传输协议。MPEG-DASH广泛用于谷歌Android设备,包括智能电视和手机等终端的流媒体传输。
ABR
另一个主要的ABR协议是 Apple为iOS设备认证的HLS 。ABR的工作原理是将视频流划分为多个分片,时长一般在2-10秒之间。每个分片是以H.264或HEVC编码的一系列视频帧作为 图片组(GOP) 。在编码视频质量的不同级别上,相同视频片段的若干版本被驻留在 CDN 的源服务器上。每隔一段时间,无论分片大小如何,观看设备都将获取可在给定时间内,通过建立在原始服务器和观看设备之间的网络连接顺利完成传输与处理的最高质量版本流媒体文件。
虽然这种方法适用于VOD内容,但它确实为实时视频带来了明显的延迟,因为至少有三个分片需要一次缓冲,例如10秒的分片会带来30秒的延迟。
CMAF
2016年,苹果公司宣布它将支持用于HLS流媒体的.mp4容器格式的分片版本,这也为Apple和微软认可的新的 MPEG 标准铺平了道路——也就是CMAF。由于HLS和MPEG-DASH现在可以共享一个共同的容器.mp4,人们的焦点已转移到如何提升CMAF将ABR段划分为更小分片或块的能力。
使用CMAF的低延迟模式,设备不再需要等待接收整个OTT段,得益于HTTP 1.1的分块传输编码规范,CMAF允许播放器可以立即开始播放该段的较小块并显着降低延迟。例如,如果将10秒的分片切割成10个块(Chunk),那么包括缓冲与播放器在内的总体延迟可以从30秒降低到3秒。
低延迟HLS
进一步推动低延迟流媒体传输技术发展的原因是一个被称为 LHLS 或低延迟HLS的开源社区计划,其采用MediaSource扩展和hls.js Javascript库,通过标准服务器和浏览器客户端使用的HTTP 1.1传输分块视频。
在Apple于2019年6月举办的全球开发者大会(WWDC)上,习惯制定自主标准的Apple公司宣布 低延迟HLS 是一种大幅减少最后一公里延迟的方法。低延迟HLS的目标是通过依靠HTTP 2.0向Apple播放器推送块或分片的能力进一步减少最后一公里的延迟,通过减少播放器与服务器之间的往返检索请求次数来节省时间。
第一公里与最后一公里
虽然低延迟视频流媒体传输的争夺逐渐聚焦于最后一公里的提升也就是内容被传送到屏幕以展现给观众的过程,但低延迟的优势在第一公里开始时便得以展现。在覆盖远程事件时,第一公里的流媒体包括从摄像机捕获内容,通过H.264或HEVC对其进行编码并通过IP网络将其流式传输到生产设施。这一过程也被称为广播贡献,此阶段对于整体端到端延迟的管理来说至关重要。
SRT
HLS、MPEG-DASH和CMAF在第一公里视频流传输中并不占优势,因为它们为直播制作流程引入了太多延迟。相反,广播公司正在转向 SRT (https://en.wikipedia.org/wiki/Secure_Reliable_Transport),一种由Haivision开创的开源流媒体协议。SRT包括一些在第一公里传输中起着至关重要的功能,包括低延迟丢包恢复和内容加密。
![008399cda2e22bb97a0d9163df2152d7.png](https://i-blog.csdnimg.cn/blog_migrate/c8cc1cbc364131296a3ae1dbdae2f142.jpeg)
延迟能有多低?
一旦直播内容制作完成,下一阶段就是将其分发给不同的广播附属机构,版权持有者和OTT服务。一旦将流分发至OTT代码转换器和源服务器,它们就可以依赖分块传输编码和CMAF将流媒体传送到终端设备。 Red Bee Media 有效地 证明了 SRT和CMAF的结合可以为这一流程赋能,他们在3.5秒内实现了端到端的视频流媒体传输。
在今年的拉斯维加斯NAB展会上, Haivision和Epic Labs 演示了基于 SRT Hub 和Microsoft Azure的SRT到CMAF直播解决方案。来自摄像机的SDI视频源文件被送入 Haivision Makito X 视频编码器,从而让编码器压缩视频内容成HEVC,然后使用Haivision的SRT Hub在Microsoft Azure光纤骨干网络上将其从拉斯维加斯流式传输到芝加哥。SRT Hub内部Epic Labs的LightFlow hublet将SRT流转码为CMAF和MPEG-DASH,然后将其发送到CDN以便传送到终端设备。此SRT到CMAF解决方案的总体端到端延迟总计为3秒。
总而言之,SRT与低延迟视频编码器相结合,可将延迟水平降至 55毫秒 或低于2帧。通过确保其在实时视频广播上的效果,制作和发布阶段期间保持尽可能低的延迟,减少延迟累积和最后一公里低延迟技术(如CMAF),可以更有效地降低OTT延迟水平与线性广播电视。