srt是什么文件（srt文件怎么编辑）

　　作者VitalySuturikhin
　　翻译徐鋆
　　低广播延迟已经成为任何关于建设源端站和CDN的招标和竞争中的必要特性。以前这种标准只适用于体育广播，但现在运营商要求每个领域的广播设备供应商提供低延迟，比如：广播新闻、音乐会、表演、采访、谈话节目、辩论、电子竞技等等。
　　什么是低延迟？
　　一般来说，延迟是指某一特定视频帧被设备（摄像机、播放机、编码器等）捕获的时间与该帧在终端用户显示器上播放的时间之间的时间差。
　　什么是低延迟视频流？
　　低延迟不应降低信号传输的质量，这意味着在编码和复用时使用最小的缓冲，同时在任何设备的屏幕上需要保持流畅和清晰的画面。另一个先决条件是保证传输：所有丢失的数据包都应该被恢复，以及在开放网络上的传输不应该引起任何问题。
　　越来越多的服务正在迁移到云端，以节省租用的场地、电力和硬件成本。这增加了对高RTT（RoundTripTime，往返时间）下低延迟的要求。在播放高清和超清视频时，传输高比特率的情况尤其如此。比如如果云服务器位于美国，而内容消费者在欧洲的情况。
　　在这篇文章中，我们将分析目前市场上在低延迟广播方面提供的方案。
　　UDP
　　在现代电视广播中被广泛使用并与低延迟一词相关的第一项技术可能是通过UDP的MPEGTS流内容进行的组播。通常情况下，这种格式适合封闭的无负载网络，在这种情况下，丢包率是最小的。例如，从编码器到源端站调制器的广播（通常在同一个服务器机架内），或通过带有放大器和中继器的专用铜线或光纤线路的IPTV广播。
　　这种技术被普遍使用，并表现出良好的延迟特性。市场上的公司使用以太网实现的与编码、数据传输和解码相关的延迟，在每秒25帧的情况下不超过80ms。在更高的帧率下，这一延迟特性甚至更低。
　　图1。UDP广播延迟测量
　　图1上半部分显示了来自SDI采集卡的信号，下半部分展示经过编码、多路复用、广播、接收和解码阶段的信号。如图所示，第二个信号晚一帧到达（在这种情况下，因为信号是25fps，1帧是40毫秒）。在ConfederationsCup2017和FIFAWorldCup2018上使用了类似的解决方案，只有一个调制器、一个分布式DVBC网络和一个作为终端设备的电视加入到架构链中，最终总延迟为220240毫秒。
　　如果信号通过一个外部网络怎么办？有各种问题需要克服：干扰、整形、流量阻塞通道、硬件错误、电缆损坏和软件层面的问题。在这种情况下，不仅需要低延迟，还需要对丢失的数据包进行重传。
　　在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的应用程序流行时非常流行。它有几个品种，支持TLSSSL加密，甚至还有基于UDP的变种，即RTFMP（实时媒体流协议，用于点对点连接）。RTMP将数据流分割成片段，其大小可以动态变化。在通道内，与音频和视频有关的数据包可以交错和复用。
　　图2。RTMP广播实现用例
　　RTMP会构建几个虚拟通道，在这些通道上传输音频、视频、元数据等。大多数CDN不再支持RTMP作为向终端客户分配流量的协议。然而，Nginx有自己的RTMP模块，支持普通的RTMP协议，它运行在TCP之上，使用默认的1935端口。Nginx可以作为一个RTMP服务器，分发它从RTMP流媒体接收的内容。另外，RTMP仍然是向CDN交付流量的流行协议，但在未来，流量将使用其他协议进行传输。
　　目前，Flash技术已经过时，且不受支持：浏览器或是减少对它的支持，或是完全禁止使用。RTMP不支持HTML5，在浏览器中也难以使用（播放需要通过AdobeFlash插件）。为了绕过防火墙，他们使用RTMPT（封装到HTTP请求中，并使用标准的80443而不是1935端口），但这大大影响了延迟和冗余（根据各种估计，RTT和整体延迟增加30）。尽管如此，RTMP仍然很流行，例如，在YouTube上的广播或在社交媒体上（Facebook的RTMPS）。
　　RTMP的主要缺点是缺乏对HEVCVP9AV1编码器的支持，以及只允许两个音轨的限制。此外，RTMP在数据包头中不包含时间戳。RTMP只包含根据帧率计算的标签，因此解码器并不确切知道何时解码这个流。这就需要一个接收组件均匀地生成用于解码的样本，因此缓冲区必须按数据包抖动的大小来增加。
　　RTMP的另一个问题是重新发送丢失的TCP数据包，这在前文已经描述过。为了保持较低的回传流量，确认收到（ACK）并不直接到发件端。只有在收到数据包链后，才会向广播方发送ACKs或NACKs的确认信息。
　　根据各种估计，使用RTMP进行广播，通过完整的编码路径（RTMP编码器RTMP服务器RTMP客户端）的延迟至少是两秒。
　　CMAF
　　CMAF（CommonMediaApplicationFormat，通用媒体应用格式）是由苹果和微软邀请MPEG开发的协议，用于在HTTP上进行自适应广播（具有根据整个网络带宽速率变化而变化的自适应比特率）。通常情况下，苹果公司的HTTP直播（HLS）使用MPEGTS流，而MPEGDASH使用片段式的MP4。2017年7月，CMAF标准被发布。在CMAF中，片段式的MP4片段（ISOBMFF）通过HTTP传输，同一内容有两个不同的播放列表，用于特定的播放器：iOS（HLS）或AndroidMicrosoft（MPEGDASH）。
　　默认情况下，CMAF（像HLS和MPEGDASH）不是为低延迟广播设计的。但行业对低延迟的和兴趣在不断增加，所以一些厂商提供了标准的扩展，例如低延迟CMAF。这种扩展假定广播方和接收方都支持两种方法：
　　分块编码：将片段分成子片段（带有moofmdatmp4框的小片段，最终构成适合播放的整个片段），并在整个片段拼合之前发送。分块传输编码：使用HTTP1。1发送子片段到CDN（源）：每4秒只发送1次整个片段的HTTPPOST请求（每秒25帧），此后在同一会话中可以发送100个小片段（每个片段有一帧）。播放器也可以尝试下载不完整的片段，而CDN则使用分块传输编码提供完成的部分，然后保持连接，直到新的片段被添加到正在下载的片段中。一旦整个片段在CDN一侧形成，向播放器传输的片段就会完成。
　　图3。标准的分块CMAF
　　如果要在配置文件之间切换，则需要缓冲（至少2秒）。鉴于这一点以及有可能的分发问题，该标准的开发者声称延迟小于3秒。同时，诸如通过CDN与成千上万的同时客户端进行扩展、加密（连同通用加密支持）、HEVC和WebVTT（字幕）支持、保证交付和与不同播放器（苹果微软）的兼容性等重要特征都得到了保留。在缺点方面，人们可能会注意到播放器方面强制性的LLCMAF支持（支持碎片化的片段和内部缓冲区的高级操作）。然而，在不兼容的情况下，播放器仍然可以使用CMAF规范内的内容，具有HLS或DASH的标准延迟。
　　LLHLS
　　2019年6月，苹果发布了低延迟HLS的规范。
　　它由以下部分组成：
　　生成部分片段（片段式的MP4或TS），最小持续时间为200毫秒，甚至在由这些部分组成的整个片段完成之前就可以使用。过时的部分片段会定期从播放列表中删除；服务器端可以使用HTTP2推送模式，将更新的播放列表与新的片段一起发送。然而，在2020年1月的最后一次规范修订中，这一建议被排除；服务器的责任是保留请求（阻塞），直到包含新片段的播放列表版本可用。阻断播放列表的重新加载消除了轮询；不发送完整的播放列表，而是发送播放列表的增量（默认的播放列表被保存，然后只在出现时发送增量，而不是发送完整的播放列表）；服务器宣布即将出现的新的部分片段（预加载提示）；关于播放列表的信息在相邻的配置文件中被同时加载，以加快切换。
　　图4。LLHLS的运行原理
　　在CDN和播放器完全支持该规范的情况下，预计延迟时间小于3秒。HLS由于其出色的可扩展性、加密和自适应比特率支持跨平台功能以及向后兼容，非常广泛地用于开放网络的广播，如果播放器不支持LLHLS，这一点很有用。
　　WebRTC
　　WebRTC（网络实时通信）是由谷歌在2011年开发的一个开源协议。它被用于GoogleHangout、Slack、BigClueButton和YouTubeLive。WebRTC是一套标准、协议和JavaScript编程接口，并且使用DTLSSRTP在点对点连接中实现了端到端的加密。此外，该技术不使用第三方插件或软件，可以在不损失质量和延迟的情况下通过防火墙（例如，在浏览器的视频会议期间）。在播放视频时，通常使用基于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（SecureReliableTransport，安全可靠传输）是由Haivision在2012年开发的一个协议。该协议在UDT（基于UDP的数据传输协议）和ARQ数据包恢复技术的基础上运行。它支持AES128和AES256加密。除了监听（服务器）模式，它还支持呼叫（客户端）和会合（当双方启动连接时）模式，这使得连接可以通过防火墙和NAT建立。SRT的握手过程是在现有的安全策略中进行的，因此允许外部连接，而不需要在防火墙中打开永久的外部端口。
　　SRT在每个数据包内都包含时间戳，这就允许以与流编码速率相等的速度播放，而不需要大量的缓冲，同时使抖动（不断变化的数据包到达率）和传入的比特率保持一致。与TCP中一个数据包的丢失可能会导致重新发送整个数据包链不同，从丢失的数据包开始，SRT通过其编号识别一个特定的数据包，并只重新发送这个数据包。这对延迟和冗余有积极作用。
　　重发的数据包比标准广播的优先级更高。与标准的UDT不同，SRT完全重新设计了重发数据包的架构，一旦数据包丢失，就立即做出反应。这项技术是选择性重复拒绝ARQ的一个变种。值得注意的是，一个特定的丢失的数据包可能只被重新发送固定的次数。当数据包上的时间超过总时延的125时，发送方会跳过该数据包。SRT支持FEC，用户自己决定使用这两种技术中的哪一种（或同时使用两种），以平衡最低延迟和最高传输可靠性。
　　图6。SRT在开放网络上的运行原理
　　SRT中的数据传输可以是双向的：两点都可以同时发送数据，也可以同时作为监听和发起连接的一方。当双方都需要建立连接时，可以使用会合模式。该协议有一个内部复用机制，允许将一个会话的几个流复用到使用一个UDP端口的一个连接中。SRT也适用于快速文件传输，这个应用在UDT中首次引入。
　　SRT有一个网络拥堵控制机制。每隔10毫秒，发送方就会收到关于RTT及其变化的最新数据、可用的缓冲区大小、数据包接收率和当前链接的大致大小。SRT对连续发送的两个数据包之间的最小延时有限制。如果它们不能及时送达，就会从队列中删除。
　　开发者声称，在封闭网络中短距离传输中设置缓冲区为最小，使用SRT可能实现的最小延迟是120毫秒。建议稳定广播的总延迟是34个RTT。此外，SRT在长距离（几千公里）和高比特率（10Mbps及以上）的传输方面比其竞争对手RTMP处理得更好。
　　图7。SRT广播延迟测试
　　在上面的例子中，实验室测量的SRT广播的延迟在25fps的条件下是3帧。也就是40ms3120ms。由此我们可以得出结论，在UDP广播中可以达到的0。1秒的超低延迟，在SRT广播中也是可以实现的。SRT的可扩展性与HLS或DASHCMAF不在同一水平上，但SRT得到CDN和转发者（restreamer）的大力支持，也支持通过媒体服务器以监听模式直接广播给终端客户。
　　2017年，Haivision披露了SRT库的源代码，并创建了SRT联盟，该联盟包括350多个成员。
　　总结
　　作为总结，下表展示了各个协议的对比：
　　不支持由CDN向终端用户传输。支持内容流向最后一英里，例如，流向CDN或restreamer。在浏览器中不支持Safari中不支持
　　目前，所有开源的、文档全面的东西都在迅速流行起来。可以认为，像WebRTC和SRT这样的格式在各自的应用范围内有一个长远的未来。在最低延迟方面，这些协议已经超过了HTTP上的自适应广播，同时保持可靠的传输，具有低冗余度，并支持加密（SRT的AES和WebRTC的DTLSSRTP）。
　　另外，最近SRT的小兄弟（根据协议的产生时间，而不是在功能和能力方面）RIST协议，正在获得普及，但这是另一个话题了。同时，RTMP正在积极地被新的竞争者挤出市场，而且由于浏览器缺乏原生支持，它难以很快被广泛使用。
　　原文标题LowLatencyStreamingProtocolsSRT，WebRTC，LLHLS，UDP，TCP，RTMPExplained
　　原文链接https：ottverse。comlowlatencystreamingsrtwebrtcllhlsudptcprtmp0
　　本文转自公众号：
　　媒矿工厂第一时间发布最新最有料的媒体技术资讯。倡导极客、创客精神，促进学术界、工业界以及开源社区共享信息、交流干货、发掘价值。710篇原创内容公众号
　　扫描图中二维码或点击阅读原文
　　了解大会更多信息