文 / 葉峰峰
整理 / LiveVideoStack
大家好，我是葉峰峰，來自映客直播，從事實時音視訊的開發工作大概有七八年時間了，在加入映客後，也參與了映客實時互動直播的開發過程。本次分享主要介紹映客互動直播開發過程中遇到的一些問題，以及對直播場景下互動直播的一些優化。
一、互動直播發展簡介
1、CDN直播
CDN直播指的是單個主播使用RTMP協定進行推流的直播形式。主播端推流使用的是基于TCP的RTMP協定，直接推流到我們的CDN源站，觀衆端通過CDN的邊緣節點進行拉流和播放，整條鍊路都是使用的TCP，是以技術是比較成熟的。雖然這種形式便于我們的業務推廣，但同時也存在着直播形式單一、缺少互動話題的缺點。為了解決CDN直播缺乏觀衆和主播間互動的問題，進而引入了互動直播。
2、互動直播
互動直播一般是指主播和主播之間通過RTP來進行推拉流的方式，它的形式比較多樣、話題點也非常豐富。與觀衆互動的方式除了評論區互動外，還可以通過音頻、視訊連麥的方式使觀衆加入到直播過程中與主播面對面進行交流。但是，互動直播的缺點是對傳輸時延比較敏感，并且整個直播系統的實作比較複雜。在CDN直播裡面，隻需要将流推到CDN源站就可以了，而互動直播既不僅要把我們的流推到連麥伺服器，還要解決主播與主播之間拉流進行互動播放的問題。
3、主播PK介紹及CDN vs 互動
接下來，我們重點看一下互動直播中比較特殊的一個場景即主播PK場景。連麥場景中的所有觀衆都屬于目前某個主播的觀衆，輔麥沒有自己的觀衆，而直播PK場景與之不同。在PK開始之前，兩邊的主播都有各自的觀衆，是以在播放端就需要針對PK場景進行一些特殊的優化。雖然我們的互動直播已經加入了觀衆與主播之間通過音頻、視訊進行溝通的管道，但并沒有形成一個非常有效的協作，不能很直接的引起觀衆對平台做貢獻的行為，如送禮物等。是以，在PK發起的過程中，觀衆可以通過送禮物來影響PK的整個 過程。我們可以看到上圖右側所展示的主播1v1PK場景中，每個主播會顯示有一個血條，當觀衆送禮時血條則會增長，結束時哪方觀衆送的禮物多就會勝利。這樣一來，就能讓觀衆更多地參與到直播的過程中，而且是通過送禮物的方式。如果大家最近觀看過映客直播，就會看到我們最近在開展PK排位賽的業務。PK排位賽業務指的是在PK的過程中，當有人第一個給主播送禮，就會在兩個主播中間展示一個首殺的動畫特效，使得使用者獲得一種不一樣的參與感。而且在PK結束時，會在勝利一方的觀衆裡選出對本場勝利貢獻最多的觀衆稱之為MVP，同樣會是在兩個主播中間的位置展現一個三秒的動畫特效。目前來講，PK業務是我們整個互動直播中最有價值的一個業務場景。
介紹完CDN直播和互動直播後，接下來把它們進行一個對比。從主播端來看，在業務形式上，CDN直播一般是單個主播的，而互動直播是多個主播的。在傳輸協定上，CDN直播主播端是使用基于TCP的RTMP協定來推流的，而互動直播一般是使用基于UDP的RTP協定來推流的。由于互動直播是基于UDP的，是以我們還需要考慮應用層的丢包重傳問題。在實作複雜度上，CDN直播是相對較低的，而互動直播實作複雜度相對較高。從觀衆端來看，都是使用HTTP-FLV/RTMP來進行拉流播放，且都是基于TCP的。但是，CDN直播隻有一路流，而互動直播考慮到直播場景的卡頓率或者一些名額的體驗優化，我們目前使用的是主播多流的方式。多個主播之間可能使用的是不同CDN分發的多流，互動直播在觀衆端還會考慮一些多流間同步的操作。
4、直播系統架構拓撲
下面簡單介紹一下CDN直播和互動直播的架構拓撲。對于CDN直播，它是直接通過RTMP協定推流到CDN源站，CDN源站包含邊緣節點，在觀衆拉流時，從邊緣節點請求拉流，然後進行播放。在設計互動直播系統的時候，考慮到不可能在觀衆端自己搭建CDN，是以觀衆端同樣是使用我們的CDN進行轉發、分發的。我們在打造互動直播系統過程中，更多的是進行主播端系統的搭建和開發，包括參與互動的主播之間的音視訊實時推拉流、連麥伺服器，主播之間資料的中轉和轉發，以MCU伺服器。對于多流，MCU伺服器負責把RTP流轉成RTMP流并推到CDN源站，實作主播的RTP和CDN節點之間的解耦合，這樣從MCU伺服器出來的流就是一個标準的RTMP流，也便于不同使用者、主播調用不同的CDN來分發資料。與此同時，MCU也會進行合流，合流的部分主要應用于錄像和稽核系統。
二、映客互動直播SDK及體驗優化
1、什麼是直播需要的互動SDK？
什麼是直播需要的互動SDK？其實直播裡的互動是屬于VOIP實時通話領域的一種特殊應用，接下來會介紹它的一些特點。如上圖左邊部分所示，這是在我們做互動直播SDK之前的一個CDN推流的SDK。它包含了一個PushManager接口層，下面有AudioStream和VideoStream這兩部分，AudioStream裡面有音頻的采集、前處理、編碼，VideoStream同樣有視訊的采集、前處理和編碼，最後，音頻和視訊資料會送到LibRTMP來直接推到我們的CDN源站。這是一個CDN直播的基本架構，對于互動直播的實作，首先想到的是通過WebRTC。但是，經過對WebRTC的分析發現，其實我們并不能完全地照搬WebRTC來實作我們的互動直播的業務。主要原因如下：第一，WebRTC是一個面向通話的解決方案。它采集的音頻是8K或16K的，因為人在通話過程中信号的頻率是不超過4KHz的，而互動直播裡我們要解決的是主播唱歌等一些音樂場景，是以必須要求是高采樣率的，我們用的是48K的采樣率。第二， WebRTC裡音頻編碼用的是iLBC和Opus，這兩個是低碼率的實時音視訊的音頻編碼器，而在互動直播裡一般都是用AAC-LC的編碼方式，用LC是為了相容性更好。第三，為了延時更低，WebRTC是10~32Kbps的低碼率音頻編碼，視訊編碼采用的是VP8和VP9，而我們音視訊直播裡要用到64~128Kbps的高碼率的音頻編碼，VP8和VP9也不适合在我們的CDN上廣泛傳播，我們使用的是H.264這種比較通用的視訊編碼。第四，從視訊參數上來講，WebRTC一般是VGA、800Kpbs的分辨率格式的，而我們視訊直播裡一般都是576P、1.2Mbps的高碼率視訊編碼格式。第五，最重要的，在傳輸方式上，WebRTC使用P2P方式來進行媒體中轉，它隻是解決端到端的問題，而對于互動直播來說，主播的資料是非常重要的資料，并不僅僅解決主播端的音視訊互通問題，我們還要把主播的資料推送到連麥伺服器、CDN，且要保證到達我們的觀衆端，是以在連麥系統上我們采用的是Relay的方式，很好地避免了P2P跨營運商，跨地域的問題。
2、互動SDK和直播SDK結構
雖然WebRTC并不能完全滿足我們的互動直播場景，但我們能參考WebRTC的是什麼呢？因為我們已經有了音頻采集、音頻編碼、視訊采集、視訊編碼，這些都是可以複用的，是以在建構互動直播SDK的過程中，我們需要實作的是一個實時連麥庫。通過參考WebRTC，我們的實時連麥庫如上圖左邊所示，在發送端，有一個RTP Packer把編碼器輸出的AAC和H264資料進行拆幀，拆為RTP包并進行封裝，送FEC子產品進行前向備援後再通過發送子產品發送出去。連麥伺服器資料被對端的主播拉流下來并進行播放時，他會先進到NACK和GCC子產品，在底下的傳輸子產品如果出現丢包，NACK子產品會進行丢包重傳，FEC子產品前向備援以後，在解碼時可以通過備援資料恢複出丢包資料。接下來，RTP包送到NetEQ子產品和VCM子產品，音頻送到NetEQ子產品，視訊送到VCM子產品。NetEQ會對AAC進行解碼，解碼後會嘗試進行一些錯誤恢複，如果出現丢包會進行一些等待。VCM子產品把RTP包組成video frame，當它接收到完整資料以後就回到上層進行音視訊的播放。如上圖右邊所示，在互動直播SDK中，左邊是我們的推流子產品，最下面變成了LibRTMP和連麥庫，我們進行連麥操縱時，編碼資料會送到連麥庫推到連麥伺服器。那麼在連麥過程中，如何去播放另一個主播的資料呢？這裡就會用我們的連麥庫把另一主播的資料下載下傳下來，實時拉流後采用ijkPlayer進行播放。另外，我們的連麥流也會以私有協定的方式送到RTP Player裡來播放，觀衆會使用RTP Player直接拉CDN的FLV流來進行播放。這樣一來，整個SDK就可以實作CDN的推流、CDN的拉流、連麥推流、連麥拉流的過程。
3、如何提升使用者體驗？
我們在建構了推流和連麥SDK後，又做了哪些使用者體驗和優化呢？在這裡會分兩部分來介紹，一個是主播推流端的優化，一個是觀衆端的優化。對于主播推流端，主要解決的是弱網的傳輸問題，在傳輸上可能發生UDP丢包，是以我們要解決丢包的問題，抗丢包主要包括碼率自适應和4G通道備援技術，還有就是在主播推流之前要選最優的推流網絡。另外，在推流端還有移動端的性能開銷問題，我會介紹一下我們的前處理優化和硬編解優化。對于觀衆端，我會介紹一下秒開相關的技術，以及多流的相關優化，再就是既然我們可以用UDP來加速主播端，那麼在觀衆端也是可以通過UDP來優化下行的，在QUIC我們也做了一些嘗試。
4、主播端體驗優化
a) 傳輸，性能
主播端體驗優化包括四個部分如下：
第一部分是動态政策。主播端在傳輸的過程中，采用了更嚴苛的碼率自适應政策。由于WebRTC是面向實時音視訊通話的，可能對丢包、花屏不是特别地關心，是以在WebRTC裡，丢包率2%以下是允許碼率上升的，丢包率2%~10%是保持着一種狀态，隻有丢包率大于10%時才會進行碼率的下調。但是在互動直播裡，我們必須做到出現丢包就下調碼率，來保證直播不花屏、不卡頓。此外，我們的碼率自适應有一個快降慢升的邏輯，并不是實時地随着網絡去變化，因為網絡是非常複雜的，如果我們的碼率上調太快，則會導緻網絡出現一個很不穩定的狀态。快降慢升的方式就是當出現丢包的時候，馬上下調碼率，并且隻有當保持了5秒以上的穩定狀态後，才允許碼率上調。此外，還有一個Hybrid的ARQ子產品，這個子產品指的是針對不同的網絡要使用不同的政策。在低延時的網絡中，可能丢包後使用ARQ是最高效的，而高延時的情況下，就要加上FEC了。雖然FEC會增加發送端的網絡開銷，但是它是一種更加實時性、高效的方式。在用到FEC過程中，我們會依賴不同的使用者網絡來調整我們的備援政策，以此達到一個比較好的傳輸效果。最後，我們的連麥伺服器是允許實時切換的，如果連麥伺服器在連麥過程中出現了問題，我們可以切到其他的連麥伺服器上，整個過程會卡一下，但不會影響業務的正常進行。
第二部分是多徑備援。當主播端在用WiFi進行推流時，就可以嘗試使用我們的4G路徑進行補償。因為互動推流是推到連麥伺服器上的，如果使用者使用WiFi時出現了丢包，一方面，可以使用我們的ARQ和FEC來解決，另一方面，如果使用者給了我們4G權限，我們就會建立另外一條4G通道來進行資料傳輸形成一個4G的路徑補償，當然這個資料傳輸是有限制的，大約最高不超過WiFi路徑20%的流量。另外，4G路徑也隻是對一些高價值的資料進行傳輸，高價值資料指的是已經在WiFi路徑上出現丢包的資料。如果出現了丢包，我們會在WiFi和4G路徑上同時進行這個包的傳輸，來保證丢包可以更高效的恢複出來。引入了4G補償的多徑備援方式以後，整體的觀看卡頓率降低了1%。
第三部分是基礎網絡的建設。我們在全國有5個BGP機房，兩條海外專線，我們的服務端是有保障的。另外，我們的主播端也是有保障的，因為主播既是我們的使用者，也是我們的合作人，主播也會提供有保障的網絡。最後，在前面有提到過開播前的網絡優選，當主播在發起直播的過程中，他會調參數或給直播間起名字，在這個過程中我們就能探測他的網絡，然後從所有的節點裡面選出一個比較好的節點來完成主播推流網絡的優選。
第四部分是性能優化。在直播過程中經常遇到的一個問題就是裝置發熱，發熱會導緻系統降頻，以及對攝像頭的采集掉幀嚴重。在性能優化這塊，我們又做了哪些工作呢？首先，就是我們的美顔和特效是可配置的，類似于白名單的機制。我們的美顔在一些性能比較差的機器上是可以選擇不開的，特效在不同的機型都有不同的展示。其次，除了個别機型不能支援音視訊硬編解外，我們的機房都實作了音視訊的硬編解。再者，在部分機型上，禮物的動畫特效展示的效果是不一樣的。最後，在連麥裡邊，我們把對網絡的Ping、DNS解析等操作進行封裝，進行一個異步的IO網絡庫優化，這樣能節約一部分網絡操作的開銷。
b) 傳輸優化結果展示
上圖是傳輸優化結果的展示，左邊的部分展示的是我們使用一個推流Demo，做了一個Echo模式的推拉流，延遲基本在有一百多毫秒。經過我們的優化，我們能保證主播與主播之間的延遲在150毫秒延遲左右，主播端與觀衆端延遲基本在兩到三秒。基于重傳自适應政策與4G補償政策，我們可以保障在50毫秒20%丢包率的情況下流暢直播。
5、觀衆端體驗優化
a) 秒開、多流、傳輸
觀衆端體驗優化分為秒開、多流和傳輸三部分。
第一部分是秒開。秒開是直播裡非常重要的一個概念，指的是從進入直播間到裝置出現畫面的時間，對于秒開優化分為以下幾個方面：在服務端上，第一，在CDN上支援關鍵幀GOP緩存。使用者播放某個直播間的資料時，是從關鍵幀開始播放的，基本上現在所有的CDN都支援這樣的一個特性。第二，我們自己有一個優選服務，使用者從不同的CDN拉流時，我們會進行一個優選服務。但并不是逐個房間進行優選，而是支援批量加載和服務端的結果緩存，這樣能瞬間将批量的流一次性加載下來，合并以後進行後續探測來獲得優選的效果。目前，優選主要是用戶端對大廳資料的批量加載，然後送到優選伺服器，擷取下行拉流節點後，就進行一個快速的PING探測，探測以後在我們使用者播放的時候，就直接從固定的機器上拉流就可以了。
b) 多流
第二部分是多流。在前面的介紹中，我們知道PK場景和連麥場景的差别，連麥場景中輔麥加入時，對于主麥來說，它是不需要停流的，隻是需要把它的流合并到主流中。而PK場景是A主播的流中斷，B主播的流也中斷，我們采用的是多人多流的方式來進行直播。另外，為了低延時，我們的實時流隻能是使用多流的方式。再就是，觀衆端也使用CDN多流來減少PK場景的卡頓率。
c) 多流同步、H.264 SEI
第三部分是多流同步。大家可能都知道，一條流裡音頻、視訊的同步是依賴于音頻流和視訊流使用的是同一個機器，因為這樣它們就有同樣的時間軸，隻需要采集各自的時間，然後進行偏移量的移植，基本上就可以實作音視訊同步。但是多流之間要如何實作同步播放呢？另外，在我們的直播系統中，存在一個資料由不同協定分發的問題，并且還要保證時間資訊能和資料一同傳到觀衆端。為了解決這個問題，我們使用H.264 SEI自定義幀的方式來進行多流同步。我們通過在H264資料裡加入自定義資料，連麥伺服器、CDN都會保留這份資料到觀衆端，在觀衆端兩條流拉下來後，依賴于這樣一個流同步的資料來進行多流之間的同步。主播在開播之前，需要從NTP時間伺服器來進行對時，對時以後，我們認為多個主播之間有一條時間軸和我們的NTP伺服器是同步的，多個流之間就依賴于這個時間軸來進行同步。H.264裡的SEI資料是一個留給使用者擴充的資料，尤其SEI裡類型33的Unregistered SEI，就是我們可以自己擴充的。幀格式如上圖所示，這個幀前面有一個4位元組的70碼，還有一個1位元組的幀類型的碼，接下來就是SEI類型碼，後邊是一個BUFFERLENGTH的長度，它是一個動态的公式。在這個PayLoad之後，是一個16位元組的UUID，類似于消息類型的格式，每一種應用都會定義自己的UUID來校驗不同的消息類型，後面就是自定義的消息，最後有個2位元組的尾部。PayLoadSize是動态的，每增加255位元組，則多一個位元組的BufferLength來表示這個BufferLength，這樣是為了避免資料幀裡邊的資料和提示碼會進行競争，也是SEI的标準規範的一個方式。再往下面看，我們在流A的I幀前面加了SEI同步資訊，在流B的I幀前面也加了SEI資訊，兩個流就算在CDN分發上有時間差，播放端依賴于這兩個流裡的SEI同步資訊，也能實作兩條流在播放端同步。
d) 傳輸優化
第三部分是傳輸優化。觀衆端在最開始的時候，是通過CDN源站的CDN邊緣節點來實作播放的。但是，有一些特殊的業務可能是主播帶着大家一起玩遊戲，主播把大家的遊戲畫面投上去，此時需要參與的使用者能實時地接收到主播的協同指令，這樣就要求遊戲的這邊拉RTP流，但是它隻是單向的拉流，不會向主播端推流，因為遊戲過程中，主播是不需要關注其他人的畫面的。此外，我們也有在考慮QUIC的建設，依賴于QUIC節點來優化用戶端在弱網環境下的流暢率。
e) QUIC的介紹
接下來介紹一下我們在QUIC方面的工作，QUIC是基于UDP的，是Google提供的一個開源項目，內建在Chrome中。由于HTTP網頁在弱網環境下的加載是比較低效的，當出現阻塞或卡頓時，後面的資料都不能進行有效的傳輸。為了提高頁面上的響應速度，Google就開發了基于UDP的QUIC，QUIC能提供和TCP+TLS+HTTP/2一樣的功能，并且QUIC是基于UDP的有保障的傳輸，它在内部做了重傳機制。此外，YouTube用到QUIC後減少了緩沖， QQ空間在使用了QUIC以後也提高了網頁的加載速度，映客直播在使用QUIC後也是能夠減少弱網卡頓，并優化弱網秒開和降低卡頓率的。
f) QUIC在直播中的應用
QUIC在映客直播裡的應用包括主播端的RTMP or QUIC和播放端的HTTP or QUIC。在這裡主要用到它的兩個特性，一個是減少了連接配接時間，優化秒開，一個是改進了丢包算法，優化了弱網卡頓。其中我們所做的工作包括：第一，移植QUIC。QUIC并不是一個協定的形式，它是內建在Chrome中的，是以我們需要把它移植到安卓平台、IOS平台。通過用戶端移植QUIC，讓内部RTMP支援QUIC，播放器也支援QUIC，我們服務端支援QUIC，可能稍微好一點，由于QUIC Go這樣的項目比較容易內建，推流和拉流CDN也支援QUIC。在500Kbps和1%丢包的情況下，主播端使用QUIC和TCP同時進行RTMP推流。觀看對比就發現使用QUIC推流，播放基本上是比較流暢的，而使用TCP推流的播放則是非常卡頓的。
三、監控與營運支撐
1、為什麼要做直播追蹤和營運相關系統？
在這部分，我會介紹一些營運相關的内容。在開發過程中遇到大量的問題時，不能完全依賴開發去定位問題，這時直播流程追蹤系統和大資料分析系統都是非常重要的。直播流程追蹤系統可以把直播過程中的關鍵事件進行彙報，在追蹤系統上進行逐個排列，出現問題時隻要對主播的UUID進行輸入，就能定位到出現問題的點，這樣一來，能讓我們非常容易定位開播失敗的原因，而且能把我們的工作量轉移出去。在我們進行傳輸的優化時，要依賴于大資料系統，包括要上新的特性去做A/B測試都要依賴于大資料分析系統。
2、如何做到直播品質每一秒都可追蹤？
接下來，通過一個例子來介紹我們如何做到直播品質每一秒都可以追蹤。有一天我們發現在APP上有個熱門流播放卡頓，我們希望能定位它到底是因為手機性能還是網絡引起的問題。我們分為四步來定位這個問題，第一步是收集主播資訊，第二步是捕捉卡頓點，第三步是對推流鍊路系統進行資料分析，第四步是進行問題定位。我們會先把主播當時的采集幀率、推流ID、機型系統等資料進行收集。然後抓到主播的卡頓點後，就要去定位它的時間點，這裡用到了就是剛才提到的流裡面的SEI資訊，通過SEI資訊可以換算出卡頓出現的精确時間，這樣有助于在大資料系統裡定位問題。如上圖所示，我們定位到問題發生在11點03分的某一秒，通過檢視推流埋點資料發現主播端的采集幀率隻有6幀，出現一個很明顯的采集幀率下降，但隻看這部分是不夠的，還可能是其他系統的問題。
與此同時，我們去檢視轉推服務，發現并沒有出現丢包的情況，使用者的網絡還是非常好的。于是，我們就推測是主播手機性能下降引起的問題，通過回看資料發現，在有觀衆送禮的時候，禮物特效展示時出現了明顯的性能采集幀率的下降。最後的定位的總結就是，主播使用iPhon6S加上IOS11.4長時間開播後出現了手機發熱，導緻性能下降，進而導緻采集幀率下降。我們的解決辦法就是針對iPhone6S比較老的機型，我們會對它的一些美顔特效會進行降級、參數調整，讓它開銷不是那麼大。
四、總結及展望
最後這部分就是對我們未來工作的一個思考。首先，我們會推動H.265繼續的向前發展，我們已經支援了H.265的CDN直播、RTMP直播、短視訊制作，目前正在考慮支援H265的互動直播，目前H.265隻在IOS上面硬編做得比較好，既能兼顧效率、性能，也能比較好的用起來，這裡可能還存在一些适配的工作量。其次，在QUIC方向上，我們的QUIC源站已經上線了，使用QUIC可以優化秒開和卡頓率。目前，在做的就是QUIC下行邊緣節點的建設，因為這就相當于是要去做觀衆端不同點的建設，還要考慮什麼樣的觀衆端适合從我們的QUIC節點來拉流。另外，就是我們的新業務拓展，包括一些交友類、K歌類的業務，我們認為技術是服務于業務的，新的業務拓展代表新的技術挑戰。在交友類的APP中，我們考慮音視訊通話之間用WebRTC的P2P方式來進行傳輸，而我們通過在K歌的調研發現可以采用在WebRTC加RMTP的方式來做端上合流、推流，以此來開展一些新的業務，當然這都是我們的一些嘗試。最後，我們認為更好的基礎網絡是新業務推廣的基石，到了5G時代，直播形式會更加豐富，會有更多的更精彩的節目展現給大家。
————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/86522002「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。