本文來自安徽廣播電視台 直播技術工程師 張博力在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
編解碼的新挑戰與新機會
人生總會面對諸多選擇，若要實作超高清的畫面，全景或沉浸式的視訊體驗，就需要對編碼效率、時延和畫質提出更高的要求，是以，編碼器的選擇也變得尤為重要。