SRT协议在电视直播中的应用

本文来自安徽广播电视台 直播技术工程师 张博力在LiveVideoStackCon 2020 线上峰会的演讲，详细介绍了SRT协议在信号传输、远程制作等方面的应用，以及实际工作中遇到的相关技术问题。

文 / 张博力

整理 / LiveVideoStack

非常高兴能和大家在首届音视频线上峰会上和大家进行分享和讨论。我是来自安徽广播电视台的张博力。本次分享的主题是SRT协议在电视直播中的应用。

首先我会介绍一下行业背景，也就是今天讨论的SRT应用到底是在一个什么样的行业之中进行的。

第二，我会和大家分享一下SRT协议的流程、原理，其中将会重点介绍的是SRT数据包结构以及怎么运用数据包结构的知识来排除链路故障。

第三，我会分析一下安徽广播电视台首次5G直播中SRT协议的应用，并尝试提出SRT链路安全冗余量(Secure-Margin)的概念，接着讨论如何调整参数来实现足够的安全冗余量，以及不同直播场景下的调整策略。

第四，我会和大家简单介绍一下电视节目远程制作中SRT技术的应用。

1

行业背景

广电行业可以说是一个比较传统的行业，按照传统的划分，一般只要拥有五项功能，就可以称为是一个类似电视台的机构或组织。这5项功能是信号的采集、编辑、节目的播出、素材的存储以及最后节目的传输。以上只是电视台技术领域的基础划分，并没有涵盖电视台下游的分发端。

如果按照更现代一些或者说更宏观一些的划分，广电领域的工作流程可以分为三项。第一项叫节目的制作(Contribution)，第二项是节目的分发(Distribution)，最后就是面向客户的交付(Delivery)。本次分享的内容主要与前两项相关，也就是在节目的制作和分发领域中，应该怎么样使用SRT技术。另外随着广电领域的扩大化，泛广电领域的工作流程也是类似的。

SRT在泛广电领域内的应用较早，大概在2015/2016年就已经开始。在很多技术区域，我们已经在使用SRT技术。首先从拍摄机位的信号来说，传输到直播车或演播中心，都可以使用SRT。另外制作好的节目传输到电视台，以前都是使用卫星或者光纤之类比较昂贵的传输方式，现在也可以通过公共互联网使用SRT技术来实现。在电视台播出之后传给各个分发商，这些分发商包括传统的有线网、上星站、无线覆盖或者直接对接CDN。对于CDN或者直播平台，我们之前是使用RTMP，但现在也有一些流媒体服务器的解决方案使用SRT作为上传推流的方式。

2

SRT协议

2.1 SRT协议简介

实话实说，我第一次接触到SRT协议时的反应是：这不是我们之前看剧的时候下载的字幕格式srt吗？其实不是的。

SRT是Secure、Reliable、Transport三个单词的缩写，分别代表了安全，可靠和传输。安全是指它可以对传输内容进行加密。可靠是指它能对抗有损网络中的丢包和抖动，传输就是针对点对点的传输。

SRT于2017年开源，其发展势头一直不错。上图是一个来自Broadcast IP Transformation Report的传输协议使用调查，尽管这个调查是全球范围内没有细分领域的调查，但是我们可以看到SRT是处在第一梯队的。

SRT是一个开源协议，它在github有一个非常活跃的社区。从2017年到2020年的Issues和Pull Requests的数据可以看出这个社区有多活跃。

我们大概从2018年开始接触SRT，也经过了很长时间的学习，有一些觉得不错的学习资料想和大家分享一下。

图左是SRT的技术综述（89页），它更像一个规范，这是学习SRT的朋友都绕不过去的一本书。第二本图书是SRT联盟推出的部署指南，这本书更针对实际使用者，告诉我们怎么应用SRT，怎么部署，怎么穿越防火墙，怎么调整，出错了怎么办等等，这也是一本大概四五十页，内容非常详细的指南。当然咱们可以通过github去学习。SRT在今年三月份提交了一个RFC的草案，第二个网址是草案的全部内容，内容是对最新版SRT非常详尽的概述，此外Haivison和SRT联盟官网也有非常多的资料和白皮书可供下载。当然，学习SRT最主要的是实践，无论是从应用还是开发的角度，实践都是最好的学习方式。

我们尝试总结一下SRT到底是一个什么样的协议。

当然SRT在不断的发展，它的野心也是很大的，SRT现在开发了许多新功能，包括传输大文件、小的对话数据等等。但是SRT的“传统优势领域“还是实时的视音频传输，SRT本质上是一个点对点的传输协议（单播而不是组播）。SRT的亮点在于能够克服有损网络中的抖动和丢包。SRT目前还是专注于节目的制作和分发，而不是交付。最后两个也是SRT独有的特点，SRT拥有一个强制的延时量，并且这个延时量是固定不变的，但是这个延时在网络搭建之前可以由用户进行调整，另外SRT可以对内容进行加密。

SRT是如何实现这些功能的呢：

• 首先，SRT协议以UDP协议为基础，传统观念认为UDP协议不可靠，但实际它的效率很高，具备稳定、可重复并具有连续吞吐量的数据包投递机制。
• 第二，SRT采用握手机制建立连接。这个握手机制非常高效，只需使用两个往返就可以完成握手、信息交互、参数交互。
• 第三，SRT使用了改进后的ARQ自动重发请求技术，也逐步开始支持FEC前向纠错。
• 第四，封装协议中带有精准的时间戳。
• 最后SRT通过设定延时量，统一规定了发送端和接收端缓冲区的大小。实际上延时量也决定了缓冲区可以使用的大小。

2.2 UDP协议

在有损网络中不用SRT协议，使用裸露的UDP协议行不行呢？这是一个编码后的TS流信号（VBR），固定帧间隔40毫秒，经过了有损网络传输之后，码流特性改变，帧间隔也变得不固定。实际上，这样的信号是几乎无法解码出来的。

2.3 SRT协议

上图是SRT协议的效果图，可以看到SRT在解码端重新恢复了原有的码率特性和帧间隔。如图所示，SRT有一个发送端缓冲区、接收端缓冲区，在发送信号的同时会有一些控制信息或者说反馈信息来实现ARQ纠错，并且SRT包头中有精确的时间戳。

另外在发送端接收端之间有一个强制的固定延时量。这个延时实际上是在接收端缓冲区产生的，所有数据放到接收端缓冲区，必须要等待一个延时量才会被送给解码器，这是SRT的一个重要的特点。

2.4 ARQ机制原理

这是关于一个自动重发请求的简图。数据包如果被正确接收，会返回一个肯定应答ACK给发送端，如果没有被正确接收，会返回一个否定应答NAK，发送端接收到NAK后会重发相应数据包。

值得注意的一点是有的传输协议虽然也是使用ARQ机制，但是它可能只使用ACK或者NAK，而SRT既是用ACK也使用NAK。

2.5 ARQ和FEC的对比

上图是ARQ机制和FEC机制的对比。

l假设发生了数据包丢失，我们不做纠错和控制，那丢包就是无法挽回的了。

l但如果使用FEC机制，那么接收端就会通过一定的算法来恢复，当然FEC对于丢包的恢复有一定的上限，并且占用一定的额外带宽。

l如果是ARQ机制，就会返回一个重发请求，发送端接收到请求之后便会重发该数据包。

2.6 SRT协议流程图

经常使用SRT的朋友一定对SRT中常用的“呼叫监听”模式很熟悉。一方是呼叫方(Caller)，另一方是监听方(Listener)，双方在连接成功之后，这两个角色便失效了，双方又恢复到发送端和接收端的角色。

如图所示，SRT在第一次握手往返时只是简单地交换一下cookie。第二个往返就会交换很多参数，比如版本、加密方式、双向延时量、StreamID等参数。开始传输之后，数据包首部就带有时间戳，另外还会交换很多控制数据，例如ACK、NCK、ACKACK（针对肯定应答的肯定应答）、Keepalive，Shutdown。

通过这个简略的流程图，我们可以知道SRT是如何工作的，另外我们也可以看到数据包结构的雏形，首先它有一个传输有效数据的信息数据包，当然还有控制数据包，例如握手、ACK、NAK、ACKACK、Keepalive和Shutdown包。

2.7 SRT协议数据包

SRT中有四个比较重要的数据包类型，咱们从数据包结构来学习SRT协议有助于在实际工作中检测链路状态，或者是进行故障排除。

2.7.1 SRT协议数据包结构

首先SRT的首部是紧跟在UDP首部之后的，SRT首部第一个标志位为0代表该数据包是信息数据包。

数据包序列号字段：每发送一个数据包，数据包序列号的字段便会加1。序列号起始数值是随机生成，并不是从零开始计数。

报文序号字段：从零开始独立计数，在Live模式中用处不大。前面的四个标志位分别有其含义，具体如图所示。

时间戳字段：以连接建立时间(StartTime)为基准的相对时间戳（精确到微秒）。

2.7.2 握手包

上图简略展示了SRT握手包的结构，它省略了加密扩展模块和配置扩展模块。

第一行标志位为1表示控制数据包，控制类型为0表示握手包。

版本字段：SRT的握手分为两个版本：HSv4和HSv5。SRT1.3版本之后都是HSv5，之前都是HSv4，并且HSv5向前兼容HSv4。

加密标志位EncrFld：表示了加密的类型。

扩展标志位ExtFld：表示了有哪些扩展模块。

数据包序列号初始值字段：该初始值是随机生成的，这样握手的时候，双方就知道从哪里开始计数。

MTU字段：最大数据包长度。

FC字段：滑动窗口的大小。

握手类型字段：在连接成功的时候意义不大，但是在连接失败的时候会给出错误码，告诉我们为什么失败，图左下角是错误码对照表。

同步cookie字段：由listener的主机、端口和当前时间生成，精度1分钟。

握手请求和握手响应拓展模块是比较重要的扩展模块，其字段含义如下：

SRT版本：可以是1.3、1.4或者更老的版本。

SRT标志位：8个标志位实现了SRT的不同模式和功能。

发送方向延时和接收方向延时：SRT协议1.3版本实现了双向传输功能，双向传输可以分别设定不同方向的延时量。对于常规的单向传输，假设A向B发送数据，该方向的延时量Latency应该是A的发送方向延时(PeerLatency)和B的接收方向延时(RecLatency)的最大值，该延时量在握手阶段就已由双方协商确定。

2.7.3 ACK包

ACK数据包最初是为了返回肯定应答，但SRT中添加了许多链路信息和对链路的预测。这里控制类型为2便表示ACK包。

附加信息字段：包含有单独的ACK序列号，用于让ACK包和ACKACK包一一对应，从而计算出RTT（链路往返时延）。

最近一个已接收数据包的序列号 1：如该字段为6，便表示前5个包都已收到。

RTT估值字段：SRT会估算RTT。

RTT变化量：SRT会对一段RTT进行统计，估算出RTT估值的变化量，这个变化量也显示了RTT的波动程度，一个良好链路的RTT一般相对稳定。

接收端的可用缓冲数据：接收端缓冲区中可用的数据越大越好。

ACK数据包还会对链路带宽和接收端的下行带宽进行估算。

ACK里的链路数据非常丰富，对于使用者和开发者来说都是非常好的。使用者可以通过此获得很多有用的信息，开发者可以依此做一些拥塞控制。

2.7.4 NAK包

控制类型为3代表NAK数据包。NAK包中的丢失列表有两种信息：单个丢包序列号和连续丢包序列号，如果是连续丢包，就需要列出起始序列号和截至序列号。

值得注意的一点是，SRT协议中的NAK都是发两次的，一般情况是在丢包时就发送NAK，但是还会定期重发NAK队列，这样做主要是为了防止在反向传输中NAK包丢包的概率。

2.7.5 实际运用

以上说了那么多枯燥的数据包结构知识，主要是为了能在实际工作中运用。下面我们使用一个视频来说明怎样判断一个链路的故障。当出现链路没联通的情况，我们可以使用Wireshark进行抓包分析。当发现里面全是握手包之后，说明握手没有成功，但另外一个方面也说明了IP和端口号设置是正确的。

在握手中出了问题，我们首先要找到第一个握手包。在SRT中所有的第一个握手包，出于兼容性问题的考虑都是HSv4版本的握手包。在找到第一个握手包之后，由于是两次往返，所以需要往下数第四个握手包，可以看到错误类型是1002，1002表示对端拒绝。当然这个错误码给的是比较含糊的，我们还要继续分析。

在第二个监听方发给呼叫方的握手包里面看到了要求。可以看到这里它的加密标志位是02，02表示AES-128，即要求对方以AES-128方式来加密。

接下来我们在下一个握手包里看有没有响应，也就是看握手包里有没有加密的扩展模块。扩展标志位是01，01表示只有响应扩展模块，没有加密扩展模块，也没有配置扩展模块。

这里其实就破案了，Listener要求加密，但Caller并没有以加密的形式做响应。之后我们要做的Caller以AES-128的模式进行加密，并且需要知道对方的密码。以上是一个非常简单的例子，演示了了我们在实际工作中怎样运用数据包结构的知识进行故障分析。

3

SRT在5G直播中的运用

3.1 安徽省首次5G直播

接下来我们来看看SRT在5G直播中的应用。去年年初安徽广播电视台完成了安徽省首次5G直播，电视台以前的直播形式都是以卫星和光纤为主，特点是价格昂贵，但是非常可靠。随着现在网络条件越来越好，也有5G网络做为支撑，我们使用SRT来作为主路传输，备路为卫星和其他协议来实现直播，另外还使用SRT构建了一个回传链路，方便节目的制作。

这是5G直播的设备示意图。这里需要说的是由于SRT的开源特性，它在工作中使用起来是非常方便的，和其他的单位或公司对接也相当便捷。因为他不会区分品牌、软件/硬件编码器等等。比如我们安徽广播电视台的这次5G直播，使用了三个品牌的SRT的设备。

3.2 链路安全冗余量

第一次在大型的直播中使用SRT链路我们内心也是很忐忑的，卫星和光纤我们可以通过一些指标去判断链路是否安全可靠，但SRT链路并没有相应的指标。我们通过一些学习和测试，提出了安全冗余量(Secure-Margin)的概念，可以用来衡量SRT链路的安全可靠程度。

3.2.1 延时量

在此之前还是要聊一聊延时量，从而引入链路安全冗余量的概念。咱们之前说过延时量实际上决定了缓存区的大小，而且双方都需要知晓延时量。

延时量是在接收端产生的，但是发送端也需要知晓。举个不恰当的例子，隔壁老王对你说：“兄弟，江湖救急，礼拜五24:00之前我需要一笔钱。”那么你就知道了，他需要这笔钱的时限是在礼拜五24:00之前（相当于双方都知晓了延时量）。如果你恰巧在礼拜五24:00的时候才刚刚凑到了钱，那么你已经知道，即使现在你把钱送给老王也来不及了（因为送钱也需要RTT/2的时间）。那么你会怎么做呢，就是默默的把钱收好不给隔壁老王了：）

这种情况在SRT里面有一个对应机制叫做：过迟丢弃TLPD(Too Late Packet Drop)，指在发送端会主动丢弃一些数据包。双方都知道延时量，发送方知道即使数据包发过去也过期了，就直接将其丢弃。本质原因是：我们是在进行实时视音频传输，而不是传文件。

另外双方都知晓延时量还有一个用处。比如说我是老王，我在礼拜五24:00之前还没有收到钱，那么我也明白即使24:00之后你再给我钱也没有用了。但是做人留一线，日后好相见：）那么我会给你回个信息，告诉你钱已经凑够了不用担心了（实际上没凑够）。

对应到SRT协议，接收端会在估算到这个包已经来不及重传的情况下，返回一个肯定应答ACK给发送端，而不是否定应答NAK。

3.2.2 缓冲区状态图

上图是缓冲区状态图，包括了发送端缓冲区和接收端缓冲区。延时量就像窗口一样在向前滑动。随着延时量窗口的滑动，发送端过期的包就会被丢弃，就也是刚刚所说的过迟丢弃TLPD。另外随着窗口的滑动，接收端滑出窗口的包就会被送给解码器。

接收端接收到第6号包之后会返回一个ACK，发送端接收到ACK之后会将2-6号数据包都从缓冲区踢走。这张图是一个非常好的链路状态，发送端缓冲区里面只有很少的数据，说明数据发出去之后经过了很短的时间就收到了肯定应答，链路状况良好。另外接收端缓冲区里面充满了数据，也说明链路状态很好。

这张图是不太理想的链路状态。如图在收到第4号包的时候，接收端便意识到3号包没有收到，并返回了一个NAK。比较幸运的是3号包还在发送端窗口的边沿，还没有被丢弃，这时候重传或许还来得及。但是这个时候。链路已经处在出错边缘的状态，这不是一个好的链路状态。

同时可以看到发送端缓冲区里充满了数据，说明这些数据都没有收到肯定应答，而接收端缓冲区里又几乎没有什么数据。

我再来解释一下为什么说接收端缓冲区里面的数据要越多越好。例如，有一位叫解码器的朋友去吃自助餐，他的胃口时大时小，是动态码率VBR。同时网络带宽有波动，上菜时快时慢。那么接收端缓冲区里的数据（餐盘里的食物）当然是越多越好，如果数据很少的话，很可能没有办法应对相应的波动。

3.2.3 发送端链路状态图

至此我们尝试总结出安全冗余量(Secure-Margin)的概念。首先我们看一下发端缓冲区冗余量(SendBuffer-Margin)，图中橙红色的线是延时量Latency，同时也是缓冲区的最大值。如果发送缓冲区用量超过这个值就表示链路可能出错。

这是我们5G直播中的链路状态截图，在前一段时间链路状态还是不错的，后半段发生了一些波动，但是距离链路出错还有一些距离，这一段距离就是发送端缓冲区冗余量。图下方是发送端缓冲区冗余量的公式，实际工作中我们更多是依靠链路状态图来做监测。

3.2.4 接收端链路状态图

下面咱们来看接收缓冲区冗余量(ReceiveBuffer-Margin)，接收端缓冲区比较好的状态应该是缓冲区用量沿着Latency这条黑色的线波动，说明咱们家里的存粮很多。图中可以看到某些时间点缓冲区数据被消耗很多，但还是有余量的，这些余量就是接收端缓冲区冗余量。

图下方是接收端缓冲区冗余量的公式，接收端缓冲区的冗余量和发送端缓冲区的冗余量是相互影响的，两者我们都需要参考，并且选择一个比较差的作为链路的安全冗余量，这样就可以判断出我们链路是否安全以及安全程度，也就是距离链路出错还有多少距离。

在了解如何判断SRT链路是否安全后，咱们还要学会怎么把它调整到安全的状态。架设SRT链路之前，首先要通过相应工具获知网络带宽、丢包率和RTT。

3.3 Lantency

在知道RTT之后就可以根据链路参数计算出Latency。Latency是SRT协议的核心参数，具体计算参见图片，图中的“RTT乘数”实际上代表链路可以完成多少次重传。

通过图中的公式就可以得到延时量的建议值，但我们建议还是要进行长时间的测试，观看链路的安全冗余量以及状态图来找出一个最终合适的延时量。当然，也需要根据直播的场景对延时的敏感度，也就是直播场景的需求做具体的判断。

3.3.1 SRT链路丢弃的数据包和RTT乘数的关系

上图能帮助我们更好的了解SRT链路丢弃的数据包和RTT乘数的关系。两条链路初始丢包率分别是4%和8%。可以看到在RTT乘数为1的时候没有恢复的数据非常多，实际上链路的丢包率越高就需要越大的RTT乘数。

这主要是针对RTT没有波动的链路来设计的一个RTT乘数，如果链路有波动，实际的RTT会更复杂。在考虑链路波动的情况下，应该以波动上限进行参数计算，实际工作中我们架设的SRT链路都是经过了很多轮的测试和调整的。

3.3.2 延时量总结

我们针对SRT的延时量进行了一些总结：

在链路其他参数固定的情况下，提高延时量，安全冗余量会随之增大，当然我们也需要关注直播场景对延时的敏感程度。

延时量可以在编码器和解码器上分别设置，若数值不一样以较高的数值为准，这也就意味着仅在某一端把延时量参数降低是无法生效的。

延时量参数并不是传输链路的端到端延时，估算端到端延时还需要考虑编码延时、解码延时以及RTT。

体育比赛这类直播需要很低的端到端延时，因为观众一定不希望从邻居的欢呼声或者朋友圈得知进球，这种情况需要我们非常仔细的权衡延时量和安全冗余量，从而找到一个折衷的参数。以这次5G直播为例，在保证充足安全冗余量的情况下，端到端延时只有0.5s左右，远小于卫星链路的延时。

3.4 带宽开销

前面说了SRT的很多优点，但其实没有一种协议是完美无缺的。某种程度上来说，SRT是用带宽来换取对丢包和抖动的恢复能力，那么就会有一些额外的带宽开销，带宽开销(BW Overhead)参数就是用来设置这部分额外开销。

带宽开销是一个百分比参数，计算基数为TS流比特率，默认值为25%，实际可设置为5%-50%，这部分额外带宽被用作重传数据包、传输反向控制数据。据SRT大联盟测算每丢失一个数据包都会在消耗400b的反向传输带宽。

3.4.1 带宽开销示意图

这张图可以帮我们更好地理解带宽开销的功用。链路崩溃时，我们需要使用缓冲区的数据，当链路恢复后，就需要利用带宽开销来弥补对于缓冲区数据的消耗，弥补的过程被称为突发期(BurstTime)。经过突发期之后，链路又恢复了正常传输。需要注意的是图中A和B的面积是相等的，这会导出一个关于带宽开销的公式（下文会给出）。

链路可用带宽=流比特率*(1 带宽开销)。但实际上，SRT联盟还是建议留一些余量，其建议的链路可用带宽=流比特率*(1 带宽开销)*1.33。假设使用HEVC方式编码超高清视频，TS流比特率为40Mbps，带宽开销为25%，链路可用带宽应高于建议值为66.5Mbps。

可能会有人觉得这个带宽还是很大，但对于需要使用SRT协议的传输工作来说，这个带宽还是可以接受的，因为并不是要求手机端具备这个带宽，更多还是在节目制作和节目传输中使用的带宽（BtoB）。

区域A和区域B的面积必须相等，因此SRT链路能够容忍的网络中断时间为延时量*带宽开销。实际上综艺晚会或者政府会议这类对延时并不敏感的直播工作，就可以考虑充分利用延时量和带宽开销这两个参数来大幅度增强链路的可靠性。假设我们在这种情况下设置延时为8000ms，带宽开销为50%，那么网络中断低于四秒钟都不会影响SRT链路的正常工作，这一特性甚至是卫星和光纤链路都不具备的。

3.5 MTU最大传输单元

有时候我们在5G直播中MTU也会出现问题。正常来说MTU默认值是1500，考虑VLAN包头可设置为1496。一般情况MTU最小值：188*7 20 8 16=1360。但在5G直播中与中兴工程师对接时遇到的问题是，5G核心网的MTU要求为1320，MTU设置不一致会发生问题。我们的解决方法是级联了一台路由器，当然也可以在编/解码器端设置，SRT实际在握手阶段就已经同步MTU信息了。

总结一下，这一节我们提出了SRT链路安全冗余量(Secure-Margin)的概念，并介绍了在不同应用场景下如何调整延时量参数和带宽开销参数。

4

远程制作

4.1 远程制作介绍

远程制作现在在广电领域很火，那到底什么是远程制作呢？我们传统领域的节目制作，所有的摄像师、现场人员、导播、切换设备都需要迁移至现场，这样会导致人力资源和资金的浪费。

远程制作的机位和切换中心可以通过广域网甚至光纤来连接，第一可以节省一部分费用，第二可以节省人力资源，第三同样的工作人员可以完成多场制作，提升了效率，而且可以完成以前完不成的任务。

4.2 远程制作实例

接下来看一个超级铁人三项的视频，这个赛事在中国大陆的首次直播是由安徽广播电视台承担的，该赛事全程是226公里，所以我们以SRT技术为基础完成了远程制作。

这些短视频的是在现场实时剪辑的，正是得益于远程制作的模式，我们可以把所有的信号汇集在一起，才有可能完成这些短视频的实时剪辑。首先SRT传输的信号进入慢动作系统，得到高光时刻的粗剪后，立刻就送到了短视频制作团队-ASVS团队，之后会制作出一个短视频的集锦，在赛事进行的过程中就已经发布了出去。

这次直播给我们带来的体验是，如果使用对的技术或者说有一个好的技术基础，会给你带来许多意想不到的效果。

接下来具体介绍一下这个超级铁人三项赛事。全程226公里，赛道涉及山地、公路和公开水域。如果采用传统的转播方式可能需要两到三台转播车，信号无法汇集到一起，还需要海量的人员和设备。

而实际上我们只采用一台转播车和两个信号汇聚点，实现了13个机位。我们把转播车和媒体中心放在一起，另外设置了换项区和入水点的信号中转点，使用SRT技术把所有信号汇总至转播车，并设置统一的固定延时量(Latency)。

上图是入水点的工作图。我们设置了很多机位，包括水上机位、空中机位、移动跟拍机位和固定机位，由该信号汇聚点统一收集这些机位，并利用SRT技术将其传输至转播车。

换项区也是非常精彩的，选手出水后能够以非常快的速度将泳装换成自行车服，然后骑上自行车进行下一项赛事，整个过程一气呵成，行云流水，是超级铁三赛事的亮点之一。所以这个区的信号采集也是非常重要的，我们使用了SRT技术与转播车联通。

4.3 感想

良好的技术基础像一粒种子，除了完成既定任务之外，它还会带给你一些意想不到的惊喜。比如这次我们同步进行短视频的制作，在节目直播的时候实时短视频就已经发布出去，同时炒热了整个直播活动，形成了一个线上线下的互动。

这些都得益于我们能够把所有信号都汇聚到一起，以前想实现这样的信号汇聚是非常困难的，所以良好的技术基础是非常重要的。

5

总结

最后来做一个总结：

• 电视直播其实是要求低延时、高质量、高可靠的视音频传输。
• SRT通过ARQ纠错和基于时间戳的数据包传送(TSBPD)，实现了点对点的实时视音频传送，并保证了低延时和高质量。
• SRT协议的数据包结构分析和应用，这一点也是非常重要的。
• 我们尝试提出SRT协议安全冗余量(Secure-Margin)的概念，可以依此判断一个SRT链路安全可靠的程度。
• 另外还需要学会调整延时量Latency，保证安全冗余量的同时满足不同的直播场景对延迟的需求，不同直播场景有不同的设置策略，
• 当然在远程制作中SRT也有着丰富的应用前景。

SRT学习资料链接：

https://pan.baidu.com/s/13elUntfkeQ0qj66UabJt1g 提取码：vvrw

编解码的新挑战与新机会

人生总会面对诸多选择，若要实现超高清的画面，全景或沉浸式的视频体验，就需要对编码效率、时延和画质提出更高的要求，因此，编码器的选择也变得尤为重要。