本次培訓主要內容為iOS_SDK使用詳解,在此不對iOS_SDK使用進行過多贅述.以下是非iOS_SDK使用的的一些技術收獲.
保證直播流暢度主要是從保證推流端推流流暢來看.
什麼會影響推流端的流暢度影響呢?除了硬件設備以及相應的參數設置最主要的也就是網絡,即弱網.
如何檢測當前網絡是弱網?
慢啟動:
慢啟動是一種TCP擁塞控制機制.慢啟動算法的基本思想是當TCP開始在一個網絡中傳輸數據或發現數據丟失並開始重發時,首先慢慢的對網路實際容量進行試探,避免由於發送了過量的數據而導致阻塞。主機發送了一個報文後就要停下來等待應答,每收到一個應答,擁塞窗口就增加一段長度,直至等於設定的阈值。 (百度的)
通過慢啟動我們就可以得知當前環境是否是弱網環境,在明確當前網絡環境是弱網環境後,就可以做一些相應的處理.
弱網丟幀策略
弱網丟幀策略即時候當在弱網環境下,推流端會自動丟失視頻幀,將丟失處理後的視頻推流出去,值得注意的是這裡的丟幀不會是隨意丟幀,而是通過有規律的選擇性丟幀,目的是為了保證丟幀後的視頻依舊有一定的連續性.這樣就對推流端在弱網環境下的推流狀態進行了流暢性的優化.
弱網動態碼率調節
弱網動態碼率調節是指在弱網環境下,推流端會自動調節碼率,例:在初始設置碼率為500+時,並且開啟碼率動態調節,推流端會在網絡環境不好的時候動態降低碼率,比如降到200+.這樣會減少視頻流所占用的帶寬,從而對流暢性進行優化.
在一個完整的直播過程中會存在多種延時,主要是編碼解碼延時,網絡延時,以及延時積累.
編碼解碼延時
編碼解碼存在兩種方式,分別是軟編軟解,硬編硬解,在次其中硬編硬解可以很好的釋放cpu的使用率,從而降低編碼解碼這方面的延時.正式如此,在iPhone設備上使用硬編硬解,在安卓設備上也會有編碼解碼方式的選擇.
網絡延時
針對於網絡延時首先是采用rtmp協議,該協議的低延時是解決網絡延時的一大助力,其次是線路的調度,liveNet中的智能調度,智能路由,智能QoS可以使推流端獲得到最優的推流路線,從而減少不必要的延時.
播放端的動態追幀解決延時積累
延時的積累是有網絡抖動,網絡丟包,網絡延時的延時和,隨著直播時間的延續,延時的積累值也會很大,如果不對其進行處理,也會產生極大的延時,因此在播放端實現了動態追幀,動態追幀的實現原理是,在播放端設置一個視頻buffer,當buffer存滿時,播放端會自動清除buffer總的視頻信息,添加最新的視頻信息,這樣就保證了播放端的延時不會隨著時間的延續黑積累.
連麥是直播場景中不可或缺的功能,極大的增加了直播的互動性,因此也需要保證連麥時的實時性.
低延時
連麥的一大需求就是低延時,那麼如何實現低延時呢?在傳統的單人直播中采用TCP協議是因為,tcp了以保證數據的可靠性,但是伴隨其的缺點就是增大了延時,因此在連麥中,並沒有采用tcp協議,而是udp協議.雖然udp存在著丟包的風險,但是卻帶來了體驗良好的低延時性.
合流方案
按照常規的方式可以采用服務器合流的方式,但是會有其弊端,因此還有就是推流端合流.
服務器端合流
正如其名,在服務器上合流,但是帶來的弊端就是延遲大,服務器壓力大,成本大,因此在七牛的合流實現上沒有有采用服務器合流,而是采用推流端合流.
推流端合流
客戶端合流即,在連麥過程中其中的一個連麥設備負責將自己的流以及其他路流進行合流編碼並退出,這樣可以減輕服務器的壓力,也適當的減少了延時,但是這也會造成合流端耗電快,發熱嚴重的後果.
補充:回聲消除
在連麥過程中會存在一種現象就是,播放出的流會再次錄入麥克風,因此在連麥時,連麥SDK會進行回聲消除處理,即,在輸出時會記錄相應數據,當麥克風錄入時,會對這部分數據進行抵消,因此也就消除了回聲.