srt是什么文件(srt文件怎么编辑)

srt是什么文件(srt文件怎么编辑)作者 | Vitaly Suturikhin翻译 | 徐鋆低广播延迟已经成为任何关于建设源端站和CDN的招标和竞争中的必要特性。以前这种标准只适用于体育广播,但现在运营商要求每个领域的广播设备供应商提供低延迟,比如:广播新闻、音乐会、表演、

作者 | Vitaly Suturikhin

翻译 | 徐鋆

低广播延迟已经成为任何关于建设源端站和CDN的招标和竞争中的必要特性。以前这种标准只适用于体育广播,但现在运营商要求每个领域的广播设备供应商提供低延迟,比如:广播新闻、音乐会、表演、采访、谈话节目、辩论、电子竞技等等。

什么是低延迟?

一般来说,延迟是指某一特定视频帧被设备(摄像机、播放机、编码器等)捕获的时间与该帧在终端用户显示器上播放的时间之间的时间差。

什么是低延迟视频流?

低延迟不应降低信号传输的质量,这意味着在编码和复用时使用最小的缓冲,同时在任何设备的屏幕上需要保持流畅和清晰的画面。另一个先决条件是保证传输:所有丢失的数据包都应该被恢复,以及在开放网络上的传输不应该引起任何问题。

越来越多的服务正在迁移到云端,以节省租用的场地、电力和硬件成本。这增加了对高RTT(Round Trip Time, 往返时间)下低延迟的要求。在播放高清和超清视频时,传输高比特率的情况尤其如此。比如如果云服务器位于美国,而内容消费者在欧洲的情况。

在这篇文章中,我们将分析目前市场上在低延迟广播方面提供的方案。

UDP

在现代电视广播中被广泛使用并与 “低延迟 “一词相关的第一项技术可能是通过UDP的MPEG TS流内容进行的组播。通常情况下,这种格式适合封闭的无负载网络,在这种情况下,丢包率是最小的。例如,从编码器到源端站调制器的广播(通常在同一个服务器机架内),或通过带有放大器和中继器的专用铜线或光纤线路的IPTV广播。

这种技术被普遍使用,并表现出良好的延迟特性。市场上的公司使用以太网实现的与编码、数据传输和解码相关的延迟,在每秒25帧的情况下不超过80ms。在更高的帧率下,这一延迟特性甚至更低。

图1. UDP广播延迟测量

图1上半部分显示了来自SDI采集卡的信号,下半部分展示经过编码、多路复用、广播、接收和解码阶段的信号。如图所示,第二个信号晚一帧到达(在这种情况下,因为信号是25fps,1帧是40毫秒)。在Confederations Cup 2017和FIFA World Cup 2018上使用了类似的解决方案,只有一个调制器、一个分布式DVB-C网络和一个作为终端设备的电视加入到架构链中,最终总延迟为220-240毫秒。

如果信号通过一个外部网络怎么办?有各种问题需要克服:干扰、整形、流量阻塞通道、硬件错误、电缆损坏和软件层面的问题。在这种情况下,不仅需要低延迟,还需要对丢失的数据包进行重传。

在UDP的情况下,带有冗余的前向纠错技术FEC(有额外的测试流量或开销)做得很好。同时,对网络吞吐率的要求随之增加,因此,延迟和冗余也会增加,这取决于预期丢失数据包的百分比。由于FEC能恢复的数据包的百分比总是有限的,而且在开放网络的传输过程中可能有很大的变化。因此,为了在长距离上可靠地传输大量数据,有必要在其中增加较多的多余流量。

TCP

接下来让我们看看基于TCP协议的技术(可靠交付)。如果收到的数据包的校验和不符合预期值(在TCP数据包头中设置),那么这个数据包就会被重新发送。而如果客户端和服务器端不支持选择性确认(SACK)规范,那么整个TCP数据包链(从丢失的数据包到最后一个以较低速率接收的数据包)就会被重新发送。

以前,当涉及到直播的低延迟时,通常会避免使用TCP协议,因为错误检查、数据包重发、三次握手、”慢启动 “和防止信道拥塞(TCP慢启动和拥塞避免阶段),延迟会增加。同时,即使信道很宽,传输开始前的延迟也可能达到RTT的五倍,而吞吐量的增加对延迟的影响非常小。

另外,使用TCP广播的应用程序对协议本身没有任何控制(它的超时、重新广播的窗口大小),因为TCP传输是作为一个单一的连续流实现的,在错误发生之前,应用程序可能会无限期地 “冻结”。而且高层协议没有灵活配置TCP,以尽量减少广播问题的能力。

同时,有些协议即使在开放的网络和长距离的情况下也能通过UDP有效工作。

下面让我们来考虑和比较各种协议的实现。在基于TCP的协议和数据传输格式中,将会涉及RTMP、HLS和CMAF,而在基于UDP的协议和数据传输格式中,将会涉及WebRTC和SRT。

RTMP

RTMP是Macromedia公司的专有协议(现在归Adobe公司所有),在基于Flash的应用程序流行时非常流行。它有几个品种,支持TLS/SSL加密,甚至还有基于UDP的变种,即RTFMP(实时媒体流协议,用于点对点连接)。RTMP将数据流分割成片段,其大小可以动态变化。在通道内,与音频和视频有关的数据包可以交错和复用。

图2. RTMP广播实现用例

RTMP会构建几个虚拟通道,在这些通道上传输音频、视频、元数据等。大多数CDN不再支持RTMP作为向终端客户分配流量的协议。然而,Nginx有自己的RTMP模块,支持普通的RTMP协议,它运行在TCP之上,使用默认的1935端口。Nginx可以作为一个RTMP服务器,分发它从RTMP流媒体接收的内容。另外,RTMP仍然是向CDN交付流量的流行协议,但在未来,流量将使用其他协议进行传输。

目前,Flash技术已经过时,且不受支持:浏览器或是减少对它的支持,或是完全禁止使用。RTMP不支持HTML5,在浏览器中也难以使用(播放需要通过Adobe Flash插件)。为了绕过防火墙,他们使用RTMPT(封装到HTTP请求中,并使用标准的80/443而不是1935端口),但这大大影响了延迟和冗余(根据各种估计,RTT和整体延迟增加30%)。尽管如此,RTMP仍然很流行,例如,在YouTube上的广播或在社交媒体上(Facebook的RTMPS)。

RTMP的主要缺点是缺乏对HEVC/VP9/AV1编码器的支持,以及只允许两个音轨的限制。此外,RTMP在数据包头中不包含时间戳。RTMP只包含根据帧率计算的标签,因此解码器并不确切知道何时解码这个流。这就需要一个接收组件均匀地生成用于解码的样本,因此缓冲区必须按数据包抖动的大小来增加。

RTMP的另一个问题是重新发送丢失的TCP数据包,这在前文已经描述过。为了保持较低的回传流量,确认收到(ACK)并不直接到发件端。只有在收到数据包链后,才会向广播方发送ACKs或NACKs的确认信息。

根据各种估计,使用RTMP进行广播,通过完整的编码路径(RTMP编码器→RTMP服务器→RTMP客户端)的延迟至少是两秒。

CMAF

CMAF(Common Media Application Format,通用媒体应用格式)是由苹果和微软邀请MPEG开发的协议,用于在HTTP上进行自适应广播(具有根据整个网络带宽速率变化而变化的自适应比特率)。通常情况下,苹果公司的HTTP直播(HLS)使用MPEG TS流,而MPEG DASH使用片段式的MP4。2017年7月,CMAF标准被发布。在CMAF中,片段式的MP4片段(ISOBMFF)通过HTTP传输,同一内容有两个不同的播放列表,用于特定的播放器:iOS(HLS)或Android/Microsoft(MPEG DASH)。

默认情况下,CMAF(像HLS和MPEG DASH)不是为低延迟广播设计的。但行业对低延迟的和兴趣在不断增加,所以一些厂商提供了标准的扩展,例如低延迟CMAF。这种扩展假定广播方和接收方都支持两种方法:

  1. 分块编码:将片段分成子片段(带有moof mdat mp4框的小片段,最终构成适合播放的整个片段),并在整个片段拼合之前发送。
  2. 分块传输编码:使用HTTP 1.1发送子片段到CDN(源):每4秒只发送1次整个片段的HTTP POST请求(每秒25帧),此后在同一会话中可以发送100个小片段(每个片段有一帧)。播放器也可以尝试下载不完整的片段,而CDN则使用分块传输编码提供完成的部分,然后保持连接,直到新的片段被添加到正在下载的片段中。一旦整个片段在CDN一侧形成,向播放器传输的片段就会完成。

图3. 标准的分块CMAF

如果要在配置文件之间切换,则需要缓冲(至少2秒)。鉴于这一点以及有可能的分发问题,该标准的开发者声称延迟小于3秒。同时,诸如通过CDN与成千上万的同时客户端进行扩展、加密(连同通用加密支持)、HEVC和WebVTT(字幕)支持、保证交付和与不同播放器(苹果/微软)的兼容性等重要特征都得到了保留。在缺点方面,人们可能会注意到播放器方面强制性的LL CMAF支持(支持碎片化的片段和内部缓冲区的高级操作)。然而,在不兼容的情况下,播放器仍然可以使用CMAF规范内的内容,具有HLS或DASH的标准延迟。

LL-HLS

2019年6月,苹果发布了低延迟HLS的规范。

它由以下部分组成:

  1. 生成部分片段(片段式的MP4或TS),最小持续时间为200毫秒,甚至在由这些部分组成的整个片段完成之前就可以使用。过时的部分片段会定期从播放列表中删除;
  2. 服务器端可以使用HTTP/2推送模式,将更新的播放列表与新的片段一起发送。然而,在2020年1月的最后一次规范修订中,这一建议被排除;
  3. 服务器的责任是保留请求(阻塞),直到包含新片段的播放列表版本可用。阻断播放列表的重新加载消除了轮询;
  4. 不发送完整的播放列表,而是发送播放列表的增量(默认的播放列表被保存,然后只在出现时发送增量,而不是发送完整的播放列表);
  5. 服务器宣布即将出现的新的部分片段(预加载提示);
  6. 关于播放列表的信息在相邻的配置文件中被同时加载,以加快切换。

图4. LL HLS的运行原理

在CDN和播放器完全支持该规范的情况下,预计延迟时间小于3秒。HLS由于其出色的可扩展性、加密和自适应比特率支持跨平台功能以及向后兼容,非常广泛地用于开放网络的广播,如果播放器不支持LL HLS,这一点很有用。

WebRTC

WebRTC(网络实时通信)是由谷歌在2011年开发的一个开源协议。它被用于Google Hangout、Slack、BigClueButton和YouTube Live。WebRTC是一套标准、协议和JavaScript编程接口,并且使用DTLS-SRTP在点对点连接中实现了端到端的加密。此外,该技术不使用第三方插件或软件,可以在不损失质量和延迟的情况下通过防火墙(例如,在浏览器的视频会议期间)。在播放视频时,通常使用基于UDP的WebRTC实现。

该协议的工作原理如下:一台主机向要连接的对等客户发送一个连接请求。在对等客户之间的连接建立之前,它们通过第三方信号服务器相互通信。然后,每个对等客户都向STUN服务器询问 “我是谁?” (如何从外面找到我?)。

同时,有公共的谷歌STUN服务器(例如stun.l.google.com:19302)。STUN服务器提供一个IP和端口的列表,通过这个列表可以到达当前的主机。ICE候选者是由这个列表形成的。第二个客户也进行相同的操作。ICE候选者通过信号服务器进行交换,正是在这个阶段建立了点对点的连接,即形成了一个点对点的网络。

如果不能建立直接连接,那么一个所谓的TURN服务器就充当中继/代理服务器,它也被列入ICE候选名单。

SCTP(应用数据)和SRTP(音频和视频数据)协议负责多路复用、发送、拥塞控制和可靠交付。对于“握手”交换和进一步的流量加密,使用了DTLS。

图5. WebRTC协议栈

使用Opus和VP8作为编解码器。最大支持的分辨率为720p,30fps,比特率最高到2Mbps。

WebRTC技术在安全方面的一个缺点是,即使在NAT后面和使用Tor网络或代理服务器时,也要定义一个真实的IP。由于连接结构的原因,WebRTC不适合大量同时观看的对等客户(难以扩展),而且目前CDN也很少支持它。最后,WebRTC在编码质量和最大传输数据量方面不如其他协议。

WebRTC在Safari中不可用,在Bowser和Edge中部分不可用。谷歌声称其延迟不到一秒。同时,该协议不仅可用于视频会议,也可用于文件传输等应用。

SRT

SRT(Secure Reliable Transport,安全可靠传输)是由Haivision在2012年开发的一个协议。该协议在UDT(基于UDP的数据传输协议)和ARQ数据包恢复技术的基础上运行。它支持AES-128和AES-256加密。除了监听(服务器)模式,它还支持呼叫(客户端)和会合(当双方启动连接时)模式,这使得连接可以通过防火墙和NAT建立。SRT的“握手”过程是在现有的安全策略中进行的,因此允许外部连接,而不需要在防火墙中打开永久的外部端口。

SRT在每个数据包内都包含时间戳,这就允许以与流编码速率相等的速度播放,而不需要大量的缓冲,同时使抖动(不断变化的数据包到达率)和传入的比特率保持一致。与TCP中一个数据包的丢失可能会导致重新发送整个数据包链不同,从丢失的数据包开始,SRT通过其编号识别一个特定的数据包,并只重新发送这个数据包。这对延迟和冗余有积极作用。

重发的数据包比标准广播的优先级更高。与标准的UDT不同,SRT完全重新设计了重发数据包的架构,一旦数据包丢失,就立即做出反应。这项技术是选择性重复/拒绝ARQ的一个变种。值得注意的是,一个特定的丢失的数据包可能只被重新发送固定的次数。当数据包上的时间超过总时延的125%时,发送方会跳过该数据包。SRT支持FEC,用户自己决定使用这两种技术中的哪一种(或同时使用两种),以平衡最低延迟和最高传输可靠性。

图6. SRT在开放网络上的运行原理

SRT中的数据传输可以是双向的:两点都可以同时发送数据,也可以同时作为监听和发起连接的一方。当双方都需要建立连接时,可以使用会合模式。该协议有一个内部复用机制,允许将一个会话的几个流复用到使用一个UDP端口的一个连接中。SRT也适用于快速文件传输,这个应用在UDT中首次引入。

SRT有一个网络拥堵控制机制。每隔10毫秒,发送方就会收到关于RTT及其变化的最新数据、可用的缓冲区大小、数据包接收率和当前链接的大致大小。SRT对连续发送的两个数据包之间的最小延时有限制。如果它们不能及时送达,就会从队列中删除。

开发者声称,在封闭网络中短距离传输中设置缓冲区为最小,使用SRT可能实现的最小延迟是120毫秒。建议稳定广播的总延迟是3-4个RTT。此外,SRT在长距离(几千公里)和高比特率(10Mbps及以上)的传输方面比其竞争对手RTMP处理得更好。

图7. SRT广播延迟测试

在上面的例子中,实验室测量的SRT广播的延迟在25fps的条件下是3帧。也就是40ms*3=120ms。由此我们可以得出结论,在UDP广播中可以达到的0.1秒的超低延迟,在SRT广播中也是可以实现的。SRT的可扩展性与HLS或DASH/CMAF不在同一水平上,但SRT得到CDN和转发者(restreamer)的大力支持,也支持通过媒体服务器以监听模式直接广播给终端客户。

2017年,Haivision披露了SRT库的源代码,并创建了SRT联盟,该联盟包括350多个成员。

总结

作为总结,下表展示了各个协议的对比:

  1. 不支持由CDN向终端用户传输。支持内容流向最后一英里,例如,流向CDN或restreamer。
  2. 在浏览器中不支持
  3. Safari中不支持

目前,所有开源的、文档全面的东西都在迅速流行起来。可以认为,像WebRTC和SRT这样的格式在各自的应用范围内有一个长远的未来。在最低延迟方面,这些协议已经超过了HTTP上的自适应广播,同时保持可靠的传输,具有低冗余度,并支持加密(SRT的AES和WebRTC的DTLS/SRTP)。

另外,最近SRT的“小兄弟”(根据协议的产生时间,而不是在功能和能力方面)RIST协议,正在获得普及,但这是另一个话题了。同时,RTMP正在积极地被新的竞争者挤出市场,而且由于浏览器缺乏原生支持,它难以很快被广泛使用。

原文标题 | Low Latency Streaming Protocols SRT, WebRTC, LL-HLS, UDP, TCP, RTMP Explained

原文链接 | https://ottverse.com/low-latency-streaming-srt-webrtc-ll-hls-udp-tcp-rtmp/0

本文转自公众号:

媒矿工厂 第一时间发布最新最有料的媒体技术资讯。倡导极客、创客精神,促进学术界、工业界以及开源社区共享信息、交流干货、发掘价值。 710篇原创内容公众号


扫描图中二维码或点击阅读原文

了解大会更多信息

发布者:网大大,转转请注明出处:http://www.lihongliang.net/11138

(0)
上一篇 2022年3月28日 下午4:05
下一篇 2022年3月28日 下午4:05

相关推荐

发表回复

您的电子邮箱地址不会被公开。

联系我们

助理1:15733171701
助理2:18231176262

在线咨询: QQ交谈

在线咨询: QQ交谈

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信