本文來自安徽廣播電視臺 直播技術工程師 張博力在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三個單詞的縮寫，分別代表了安全，可靠和傳輸。安全是指它可以對傳輸內容進行加密?？煽渴侵杆軐褂袚p網絡中的丟包和抖動，傳輸就是針對點對點的傳輸。

SRT于2017年開源，其發展勢頭一直不錯。上圖是一個來自Broadcast IP Transformation Report的傳輸協議使用調查，盡管這個調查是全球范圍內沒有細分領域的調查，但是我們可以看到SRT是處在第一梯隊的。

SRT是一個開源協議，它在github有一個非?；钴S的社區。從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直播，電視臺以前的直播形式都是以衛星和光纖為主，特點是價格昂貴，但是非?？煽俊ｋS著現在網絡條件越來越好，也有5G網絡做為支撐，我們使用SRT來作為主路傳輸，備路為衛星和其他協議來實現直播，另外還使用SRT構建了一個回傳鏈路，方便節目的制作。

這是5G直播的設備示意圖。這里需要說的是由于SRT的開源特性，它在工作中使用起來是非常方便的，和其他的單位或公司對接也相當便捷。因為他不會區分品牌、軟件/硬件編碼器等等。比如我們安徽廣播電視臺的這次5G直播，使用了三個品牌的SRT的設備。

3.2 鏈路安全冗余量

第一次在大型的直播中使用SRT鏈路我們內心也是很忐忑的，衛星和光纖我們可以通過一些指標去判斷鏈路是否安全可靠，但SRT鏈路并沒有相應的指標。我們通過一些學習和測試，提出了安全冗余量(Secure-Margin)的概念，可以用來衡量SRT鏈路的安全可靠程度。

3.2.1 延時量

在此之前還是要聊一聊延時量，從而引入鏈路安全冗余量的概念。咱們之前說過延時量實際上決定了緩存區的大小，而且雙方都需要知曉延時量。

延時量是在接收端產生的，但是發送端也需要知曉。舉個不恰當的例子，隔壁老王對你說：“兄弟，江湖救急，禮拜五24:00之前我需要一筆錢?！蹦敲茨憔椭懒?#xff0c;他需要這筆錢的時限是在禮拜五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%?？梢钥吹皆赗TT乘數為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技術將其傳輸至轉播車。

換項區也是非常精彩的，選手出水后能夠以非?？斓乃俣葘⒂狙b換成自行車服，然后騎上自行車進行下一項賽事，整個過程一氣呵成，行云流水，是超級鐵三賽事的亮點之一。所以這個區的信號采集也是非常重要的，我們使用了SRT技術與轉播車聯通。

4.3 感想

良好的技術基礎像一粒種子，除了完成既定任務之外，它還會帶給你一些意想不到的驚喜。比如這次我們同步進行短視頻的制作，在節目直播的時候實時短視頻就已經發布出去，同時炒熱了整個直播活動，形成了一個線上線下的互動。

這些都得益于我們能夠把所有信號都匯聚到一起，以前想實現這樣的信號匯聚是非常困難的，所以良好的技術基礎是非常重要的。

5

總結

最后來做一個總結：

• 電視直播其實是要求低延時、高質量、高可靠的視音頻傳輸。

• SRT通過ARQ糾錯和基于時間戳的數據包傳送(TSBPD)，實現了點對點的實時視音頻傳送，并保證了低延時和高質量。

• SRT協議的數據包結構分析和應用，這一點也是非常重要的。

• 我們嘗試提出SRT協議安全冗余量(Secure-Margin)的概念，可以依此判斷一個SRT鏈路安全可靠的程度。

• 另外還需要學會調整延時量Latency，保證安全冗余量的同時滿足不同的直播場景對延遲的需求，不同直播場景有不同的設置策略，

• 當然在遠程制作中SRT也有著豐富的應用前景。

SRT學習資料鏈接：

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

編解碼的新挑戰與新機會

人生總會面對諸多選擇，若要實現超高清的畫面，全景或沉浸式的視頻體驗，就需要對編碼效率、時延和畫質提出更高的要求，因此，編碼器的選擇也變得尤為重要。本次LiveVideoStackCon 2020 北京站我們也將邀請講師討論編解碼方面的挑戰與機遇，點擊【閱讀原文】可了解更多講師及話題信息。

---

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多講師及話題信息

總結

以上是生活随笔為你收集整理的SRT协议在电视直播中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。