SRT協(xié)議是基于UDT的傳輸協(xié)議，保留了UDT的核心思想和機(jī)制，抗丟包能力強(qiáng)，適用于復(fù)雜的網(wǎng)絡(luò)。在LiveVideoStack線上分享中，新浪音視頻架構(gòu)師 施維對(duì)SRT協(xié)議的原理、優(yōu)缺點(diǎn)特性以及在流媒體中的應(yīng)用進(jìn)行了詳細(xì)解析。
文 / 施維整理 / LiveVideoStack視頻回放 https://www2./v2/render/playback?mode=playback&token=a1564111ef934005b4b1acf2105128e3
1. 為什么選擇SRT？
毋庸置疑，現(xiàn)今存量最大的直播協(xié)議是RTMP，但隨著新技術(shù)的不斷發(fā)展與使用場(chǎng)景的不斷拓展，繼續(xù)使用RTMP會(huì)令人感到有些力不從心。RTMP協(xié)議的缺陷主要有以下四個(gè)方面：RTMP協(xié)議缺陷
首先，RTMP協(xié)議太老，且最后一次更新是在2012年；同時(shí)HEVC/H.265/AV1等視頻格式都沒(méi)有官方定義，以至于需要國(guó)內(nèi)CDN廠商自行定義。RTMP連接過(guò)程較長(zhǎng)，由于RTMP基于TCP（TCP存在三次握手），除此之外，其本身又存在c0/s0到c2/s2的三次握手，再加上connection，createstream，play/publish，總地來(lái)說(shuō)RTMP完成一次建連需要進(jìn)行9次會(huì)話，用于PC端勉強(qiáng)能夠接受，對(duì)于移動(dòng)端網(wǎng)絡(luò)質(zhì)量的要求則很高。RTMP的擁塞控制完全依賴傳輸層，即完全依賴于TCP傳輸層的擁塞控制算法來(lái)進(jìn)行擁塞管理，幾乎沒(méi)有什么優(yōu)化；RTMP本身基于TCP傳輸，無(wú)法提供帶寬自適應(yīng)的算法。在此背景下，眾多廠商開(kāi)始著手提供一些新的直播協(xié)議供行業(yè)參考。如QUIC、SRT等。本次我們將重點(diǎn)講述SRT的特點(diǎn)與應(yīng)用。
SRT協(xié)議的特點(diǎn)
Haivision聯(lián)手Wowza在UDT的基礎(chǔ)上針對(duì)音視頻實(shí)時(shí)性提出了SRT協(xié)議。SRT是基于UDT的協(xié)議（UDT協(xié)議是基于UDP的傳輸協(xié)議，在IETF已經(jīng)提交了4個(gè)版本），具有非常良好的丟包重傳機(jī)制，丟包重傳的控制消息非常豐富，同時(shí)支持ACK、ACKACK、NACK。我們都知道音視頻對(duì)于時(shí)間這一點(diǎn)非常在意，而SRT基于時(shí)間的報(bào)文發(fā)送，使其具有良好的防止流量突發(fā)的能力。SRT對(duì)上層提供了豐富的擁塞控制統(tǒng)計(jì)信息，包括RTT、丟包率、inflight、send/receive bitrate等。利用這些豐富的信息，我們可以實(shí)現(xiàn)帶寬預(yù)測(cè)，并根據(jù)帶寬的變化在編碼層去做自適應(yīng)動(dòng)態(tài)編碼與擁塞控制。
2. SRT協(xié)議原理分析
2.1 SRT基本思想
上圖可以涵蓋SRT的基本思想：對(duì)比編碼后的視音頻碼流（左側(cè)綠色折線“Source”）與經(jīng)過(guò)公網(wǎng)傳輸后的碼流（紅色折線“NetworkTransmission”），可以看到編碼后的源視音頻碼流具有固定的幀間隔與一定特性的可變比特率，但經(jīng)過(guò)公網(wǎng)傳輸后的碼流，其幀間隔變得不固定且碼率特性也被完全改變，解碼這樣的信號(hào)是一項(xiàng)十分艱巨的挑戰(zhàn)，甚至根本無(wú)法解碼。而如果使用加入糾錯(cuò)的SRT協(xié)議進(jìn)行公共互聯(lián)網(wǎng)傳輸，盡管編碼后的視音頻碼流經(jīng)過(guò)公網(wǎng)傳輸幀間隔變得不固定，但由于SRT協(xié)議封裝中包含精準(zhǔn)的時(shí)間戳，解碼接收端可以通過(guò)該時(shí)間戳重現(xiàn)固定的幀間隔。更重要的是，通過(guò)規(guī)定延時(shí)量，同時(shí)劃定了send buffer（發(fā)送端緩沖區(qū)）與receive buffer（接收端緩沖區(qū)），來(lái)自接收端的反饋信號(hào)（可以理解為后向糾錯(cuò)）通過(guò)一系列的設(shè)置、糾錯(cuò)、流量控制，使編碼后的視音頻碼流擁有與原碼流幾乎一樣的碼率特性。Encoder編碼器處理完成的數(shù)據(jù)會(huì)被輸入send buffer，send buffer會(huì)對(duì)數(shù)據(jù)進(jìn)行時(shí)間校驗(yàn)，也就是按照一定的時(shí)間順序編碼并通過(guò)internet發(fā)送至receivebuffer，receive buffer按照?qǐng)?bào)文上的時(shí)間戳一點(diǎn)點(diǎn)處理，確保生成的數(shù)據(jù)與源碼流基本一致。整個(gè)SRT協(xié)議的思想基于編碼，具有抗丟包、抗擁塞、抗抖動(dòng)等特性。
2.2 SRT報(bào)文基礎(chǔ)
交互過(guò)程
SRT的報(bào)文基礎(chǔ)也就是其交互過(guò)程依次為以上五個(gè)步驟：握手（Handshake）、重要信息（Capability）、媒體（Media）、控制信息（Control）與關(guān)閉（Shutdown）。與RTMP的九次握手不同，SRT的建連過(guò)程僅需兩個(gè)RTT。也就是Handshake Request與Capability Announce。Caller與Listener之間的進(jìn)行的Handshake Request是一個(gè)簡(jiǎn)化版的握手，用以提高效率；握手之后Caller與Listener間進(jìn)行重要信息的交換，整個(gè)SRT的第一項(xiàng)關(guān)鍵步驟就是Caller與Listener在這里交換了延時(shí)量與緩沖區(qū)的大??；隨后Caller與Listener之間開(kāi)始媒體數(shù)據(jù)的傳輸，同時(shí)也傳輸了為恢復(fù)幀間隔而封裝的精準(zhǔn)時(shí)間戳；SRT的第二項(xiàng)關(guān)鍵步驟是Listener向Caller同步控制信息，用以對(duì)抗公網(wǎng)中的抖動(dòng)、丟包等一系列突發(fā)狀況；最后，待至媒體數(shù)據(jù)傳輸完畢之后關(guān)閉傳輸。
數(shù)據(jù)報(bào)文
SRT的報(bào)文格式較為簡(jiǎn)單，分為數(shù)據(jù)報(bào)文與控制報(bào)文。上圖展示了數(shù)據(jù)報(bào)文的數(shù)據(jù)結(jié)構(gòu)，觀察結(jié)構(gòu)我們可以發(fā)現(xiàn)上方兩層為UDP部分，而在這之下是UDT部分。如果初始化為0，則認(rèn)為其是數(shù)據(jù)報(bào)文。FF表示報(bào)文的序列， 0b10是分片的第一個(gè)報(bào)文，0b00是分片的中間報(bào)文，0b01是分片的最后一個(gè)報(bào)文，0b11表示單個(gè)報(bào)文并沒(méi)有分片。KK表示是否加密，R表示是否屬于重傳報(bào)文，Timestamp表示時(shí)間戳，Destination Socket ID是SRT自定義的一個(gè)socket id。由該數(shù)據(jù)結(jié)構(gòu)我們可以看出：SRT的數(shù)據(jù)報(bào)文擁有精準(zhǔn)的32位時(shí)間戳，package sequence number絕對(duì)夠用，且結(jié)構(gòu)非常簡(jiǎn)單。下圖展示的則是控制報(bào)文的數(shù)據(jù)結(jié)構(gòu)，右側(cè)表格展示了控制報(bào)文的常規(guī)類型，其中值得重點(diǎn)關(guān)注的有ACK、NACK、ACKACK等。
控制報(bào)文
2.3 SRT丟包重傳
2.3.1 Send/Receive Buffer
SRT在接收和發(fā)送端都有receive buffer與send buffer，send Buffer嚴(yán)格按照時(shí)間戳間隔來(lái)發(fā)送，定時(shí)器默認(rèn)10毫秒。
2.3.2 ACK
丟包重傳最常見(jiàn)的便是ACK機(jī)制。以上圖為例，假設(shè)發(fā)送端緩沖區(qū)發(fā)送五個(gè)數(shù)據(jù)包：1、2、3、4、5給接收端緩沖區(qū)，接收端緩沖區(qū)成功接收到這些數(shù)據(jù)包之后會(huì)向發(fā)送端緩沖區(qū)發(fā)送ACK——肯定應(yīng)答已表示數(shù)據(jù)包被成功接收，發(fā)送端接收到ACK——肯定應(yīng)答之后回收空間，刪除1、2、3、4、5這五個(gè)數(shù)據(jù)包并準(zhǔn)備發(fā)送數(shù)據(jù)包6。send buffer完全按照時(shí)間戳間隔處理數(shù)據(jù)，在確定的間隔(與ACKs,ACKACKs 和 Round Trip Time相關(guān))，接收方發(fā)送ACK給發(fā)送方，使得發(fā)送方把收到ack的packet從sender buffer中移除，其在buffer中的空間點(diǎn)將被回收。接收端的receivebuffer中存在Latency Window也就是延遲窗口，其作用為按照時(shí)間戳一點(diǎn)點(diǎn)上送數(shù)據(jù)。并嚴(yán)格按照時(shí)間戳檢測(cè)，檢測(cè)周期默認(rèn)為10毫秒。
2.3.3 ACK/ACKACK/RTT
接收端在收到數(shù)據(jù)包后會(huì)向發(fā)送端反饋表示成功接收的ACK，例如上圖左側(cè)，接收端在收到第十一個(gè)數(shù)據(jù)包后向發(fā)送端反饋ACK(11)，而發(fā)送端在收到來(lái)自接收端的ACK(11)之后會(huì)向?qū)Χ嗽侔l(fā)送一個(gè)ACKACK用以表示收到ACK(11)。這一過(guò)程最大的意義在于可讓接收端計(jì)算出RTT，ACK發(fā)送的時(shí)間與對(duì)應(yīng)ACKACK收到的時(shí)間之差就是RTT——Round Trip Time(RTT)是時(shí)間的度量，表示報(bào)文一個(gè)來(lái)回的耗時(shí)。SRT不能測(cè)量單方向的耗時(shí)，所以只能用RTT/2來(lái)表示單方向耗時(shí)。一個(gè)ACK(從接收方)會(huì)觸發(fā)ACKACK(從發(fā)送方)的發(fā)送，幾乎不帶其他延時(shí)。RTT可評(píng)估當(dāng)前網(wǎng)絡(luò)質(zhì)量，RTT高表示整個(gè)網(wǎng)絡(luò)的延遲很大，RTT低則說(shuō)明網(wǎng)絡(luò)延遲較低。RTT由接收端計(jì)算而出，計(jì)算得出的RTT會(huì)通過(guò)ACK發(fā)送至發(fā)送端，發(fā)送端就可獲知當(dāng)前網(wǎng)絡(luò)的質(zhì)量如何。帶寬情況是不斷變化的，因此RTT也是一個(gè)隨網(wǎng)絡(luò)環(huán)境不斷變化的實(shí)時(shí)動(dòng)態(tài)值。
2.3.4 ACK信息
ACK報(bào)文包含了豐富的關(guān)鍵信息。其中Last Acknowledge Packet Sequence Number表示當(dāng)前收到第幾個(gè)包，RTT信息便于發(fā)送端評(píng)估網(wǎng)絡(luò)的質(zhì)量，RTT的變化表示網(wǎng)絡(luò)變化情況。Available Buffer Size表示接收端緩存可用率，SRT是可以用作文件傳輸?shù)模珹vailable Buffer Size對(duì)文件傳輸?shù)膿砣刂品浅Ｓ杏?。?dāng)文件傳輸過(guò)快時(shí)接收端的內(nèi)存緩存無(wú)法成功接收，此時(shí)發(fā)送端除了考慮網(wǎng)絡(luò)還需要考慮接收端的性能與緩存是否有足夠的空間與能力在短時(shí)間內(nèi)接收龐大的文件。Packets Receiving Rate表示每秒鐘的收包率，這里統(tǒng)計(jì)的是包的個(gè)數(shù)；而ReceivingRate表示接收包的比特率。總而言之，接收端以10毫秒為周期向發(fā)送端發(fā)送ACK，其中包括網(wǎng)絡(luò)RTT信息、接收端緩存信息、接收端比特率等關(guān)鍵數(shù)據(jù)，其中以上三個(gè)數(shù)據(jù)至關(guān)重要，直接反映出發(fā)送端到接收端之間的網(wǎng)絡(luò)環(huán)境狀態(tài)。
2.3.5 NACK
常規(guī)情況下QUIC或TCP僅提供ACK方式，也就是接收端向發(fā)送端反饋哪些包成功接收；而WebRTC的RTP或RTCP常用選擇NACK，也就是接收端向發(fā)送端反饋哪些包沒(méi)有成功接收。NACK回傳的是接收端沒(méi)收到的數(shù)據(jù)包的列表。SRT同時(shí)支持ACK與NACK，這樣設(shè)定的原因在我看來(lái)是帶寬搶占的強(qiáng)勢(shì)。例如，接收端向發(fā)送端發(fā)送ACK表示該數(shù)據(jù)包已經(jīng)成功接收，不排除該ACK報(bào)文本身丟失，導(dǎo)致發(fā)送端以為數(shù)據(jù)報(bào)文丟失而要超時(shí)重發(fā)，實(shí)際接收端對(duì)該數(shù)據(jù)包已經(jīng)成功接收了。還有一種情況是：NACK的周期性發(fā)送可能會(huì)造成發(fā)送端多發(fā)報(bào)文，例如發(fā)送端成功發(fā)送5號(hào)與6號(hào)數(shù)據(jù)包，卻一直未收到來(lái)自接收端的ACK消息，當(dāng)達(dá)到重發(fā)的時(shí)間時(shí)發(fā)送端再次發(fā)送5號(hào)與6號(hào)數(shù)據(jù)包，在此之后發(fā)送端收到了來(lái)自接收端的NACK消息，表示接收端未成功接收5號(hào)數(shù)據(jù)包與6號(hào)數(shù)據(jù)包；于是發(fā)送端第三次發(fā)送5號(hào)數(shù)據(jù)包與6號(hào)數(shù)據(jù)包。一個(gè)周期下來(lái)，發(fā)送端發(fā)了兩次數(shù)據(jù)包。從協(xié)議原理角度分析，我們發(fā)現(xiàn) SRT在丟包過(guò)程中對(duì)帶寬的消耗比QUIC與其他協(xié)議要高。 一旦出現(xiàn)丟包，SRT的重傳要多于其他協(xié)議，SRT以此來(lái)?yè)屨紟拸亩_(dá)到音視頻的同步效果。
2.4 SRT基于時(shí)間發(fā)送
按時(shí)間發(fā)送是一個(gè)標(biāo)準(zhǔn)的音視頻傳輸特性。我們知道編碼器發(fā)送是以編碼器的速度向外發(fā)送數(shù)據(jù)，但有時(shí)編碼器會(huì)太樂(lè)觀，完全按照編碼輸出向外發(fā)送會(huì)導(dǎo)致輸出超過(guò)預(yù)期過(guò)高的比特率。在這種情況下SRT Packet就不會(huì)足夠快地輸出，因?yàn)镾RT會(huì)最終被過(guò)低的錯(cuò)誤配置影響到。
2.5 可配置比特率
SRT中包含三個(gè)配置選項(xiàng)：INPUTBW表示編碼器輸入帶寬，MAXBW表示最大帶寬，以及OVERHEAD(%)表示過(guò)載率，配置原則如上圖所示：如果不配置INPUTBW與OVERHEAD(%)而僅配置MAXBW，則當(dāng)前編碼器輸出的比特率是也就是MAXBW；如果不配置MAXBW與INPUTBW而僅配置OVERHEAD(%)，則當(dāng)前編碼器輸出的比特率是(1080+)/100，默認(rèn)為25%；第三種情況是不配置MAXBW而配置OVERHEAD(%)與INPUTBW，最大輸出比特率便為(100+)/100。SRT最大的特點(diǎn)便是可配置。在有配置的情況下按照配置來(lái)做，在無(wú)配置的情況下按實(shí)際測(cè)量的比特率來(lái)做。常規(guī)情況下我們不選擇進(jìn)行配置，尤其是針對(duì)互聯(lián)網(wǎng)而言，因?yàn)閱我慌渲脽o(wú)法保證能夠在不同時(shí)段應(yīng)對(duì)不同境況的網(wǎng)絡(luò)。通常我們選擇使用實(shí)際測(cè)量出的編碼比特率計(jì)算：*(1080+)/100。
2.6 SRT簡(jiǎn)單擁塞控制——簡(jiǎn)單，太簡(jiǎn)單
接下來(lái)我們討論一下SRT的流控。我們知道在丟包重傳機(jī)制下，如果報(bào)文在網(wǎng)絡(luò)傳輸中丟失，則發(fā)送端會(huì)重新發(fā)送。例如在某網(wǎng)絡(luò)環(huán)境下發(fā)送端與接收端之間的帶寬僅有1M，現(xiàn)在由于背景流量與噪聲等影響，原來(lái)1M的帶寬減少100k變成了900k，此時(shí)就會(huì)出現(xiàn)10%的丟包；發(fā)送端未收到來(lái)自接收端的ACK或者收到NACK認(rèn)為出現(xiàn)丟包，于是嘗試重傳這10%的數(shù)據(jù)；但實(shí)際上發(fā)送端與接收端之間的帶寬就剩下900k了，而加上丟包重傳的發(fā)送量是1.1M，帶寬變窄發(fā)送的流量不降反增，就會(huì)導(dǎo)致網(wǎng)絡(luò)情況越來(lái)越糟糕，最后造成網(wǎng)絡(luò)擁塞卡頓頻繁，最后網(wǎng)絡(luò)崩潰。SRT單純地丟包重傳不能解決網(wǎng)絡(luò)擁塞的問(wèn)題，出現(xiàn)網(wǎng)絡(luò)擁塞的最好解決方案是限流，降低帶寬流量壓力。
SRT的擁塞控制過(guò)于簡(jiǎn)單，僅在congctrl.cpp中實(shí)現(xiàn)。其包括以下幾個(gè)變量：M_iFlowWindowSize表示接收方的緩存大小，m_dCWndSize等于1秒內(nèi)發(fā)送的bytes數(shù)據(jù) / (RTT + 10)，sendbufer表示發(fā)送方未發(fā)送buffer大小。其中這里的1秒內(nèi)發(fā)送的bytes數(shù)據(jù)，具體是指一個(gè)RTT內(nèi)發(fā)送的數(shù)據(jù)。總結(jié)算法如下：m_iFlowWindowSize用以衡量接收方緩存是否耗盡，同時(shí)監(jiān)測(cè)發(fā)送方每RTT發(fā)送數(shù)據(jù)size是否大于發(fā)送buffer大小。接收方緩存一般在傳輸文件時(shí)起作用。在我看來(lái)，SRT在擁塞控制方面做得還遠(yuǎn)遠(yuǎn)不夠。
2.7 SRT協(xié)議總結(jié)
SRT在快速連接方面有明顯優(yōu)勢(shì)，兩次握手成功即可建連；SRT的丟包重傳策略出色，ACK、ACKACK、NACK等提供了豐富的控制消息，還有RTT、Receive比特率等。但是同時(shí)我們經(jīng)過(guò)測(cè)試也發(fā)現(xiàn)SRT在丟包時(shí)，發(fā)送數(shù)據(jù)的帶寬占用率還是有些大，丟包率越高發(fā)送帶寬占用越大。SRT按照時(shí)間發(fā)送音視頻數(shù)據(jù)，根據(jù)實(shí)際的編碼比特率來(lái)發(fā)送音視頻數(shù)據(jù)；但SRT的擁塞控制過(guò)于簡(jiǎn)單，只針對(duì)接收方緩存是否有能力接收與編碼比特率是否發(fā)送過(guò)快。
3. SRT在SRS4.0中的方案用
3.1 SRT在SRS4.0中的方案應(yīng)用
3.1.1 最后一公里——SRT推流
我們推薦從編碼器到推流至邊緣節(jié)點(diǎn)的部分使用SRT。其目的主要有兩個(gè)：提高源流質(zhì)量與基于SRT自適應(yīng)比特率編碼，發(fā)送端和接收端配合從而解決最后一公里的推流問(wèn)題。是自己對(duì)srt的理解。SRS支持 SRT的接收端推流，邊緣SRS在接收到來(lái)自推流端的SRT推流之后會(huì)將其轉(zhuǎn)為RTMP并分發(fā)給中央節(jié)點(diǎn)，而后所有的邊緣節(jié)點(diǎn)都可以進(jìn)行RTMP拉流。
3.1.2 SRT地址格式
作為一個(gè)傳輸協(xié)議，SRT的一個(gè)弊端在于給出一個(gè)未定義的地址，我們不清楚這究竟是推流地址還是拉流地址，那么如何進(jìn)行匹配？
為方便SRT編碼器推流，SRS4.0支持編碼器的簡(jiǎn)單配置。如服務(wù)器IP、服務(wù)器Port以及streamid。根據(jù)SRT的官方文檔，SRT通過(guò)StreamID進(jìn)行標(biāo)識(shí)，簡(jiǎn)配地址格式如上圖所示，帶有vhost虛擬主機(jī)配置的地址格式如下圖所示，其中m=publish/request表示推/拉流地址。顯而易見(jiàn)的是，對(duì)比RTMP，SRT地址的可讀性并不好，地址長(zhǎng)而冗雜。
3.1.3 SRT各種網(wǎng)絡(luò)情況下的測(cè)試
測(cè)試各種網(wǎng)絡(luò)情況下的SRT我們不難發(fā)現(xiàn)，丟包率增加導(dǎo)致帶寬消耗增加，網(wǎng)絡(luò)狀況不良或發(fā)生擁塞時(shí)，發(fā)送端會(huì)發(fā)送更多的數(shù)據(jù)，這便會(huì)導(dǎo)致網(wǎng)絡(luò)狀況愈發(fā)惡化，丟包率變得更高，并以此惡性循環(huán)；除此之外，RTT增加也會(huì)導(dǎo)致延時(shí)增加，一樣會(huì)導(dǎo)致丟包率增加，帶寬消耗更大。這里我們提出的解決方案是預(yù)測(cè)網(wǎng)絡(luò)帶寬——通過(guò)當(dāng)前的send bitrate、RTT、inflight等數(shù)據(jù)預(yù)測(cè)網(wǎng)絡(luò)帶寬；同時(shí)動(dòng)態(tài)調(diào)整編碼比特率，根據(jù)預(yù)測(cè)的帶寬動(dòng)態(tài)調(diào)整編碼比特率1來(lái)適應(yīng)實(shí)時(shí)的帶寬，避免發(fā)生擁塞并提高視頻流暢度。
3.1.4 GCC算法自適應(yīng)編碼架構(gòu)
上圖展示的就是谷歌擁塞控制算法GCC的架構(gòu)圖。如圖所示：發(fā)送端將報(bào)文發(fā)給接收端，接收端由幾個(gè)部分組成，其中計(jì)算接收?qǐng)?bào)文Delay，也就是計(jì)算基于D(i,j) = (Rj-Sj) - (Ri-Si) 的變化的導(dǎo)數(shù)，得到m(ti)。除此之外，接收端設(shè)置的卡曼濾波算法會(huì)計(jì)算出一個(gè)門限值，通過(guò)該卡曼濾波的計(jì)算與比對(duì)，決定是增加碼率還是降低碼率，最終得出下一次網(wǎng)絡(luò)帶寬的預(yù)估值（Ar），并將數(shù)據(jù)返回給發(fā)送方。
3.2 自適應(yīng)碼率的SRT推流
3.2.1基于SRT自適應(yīng)碼率編碼
基于SRT自適應(yīng)碼率編碼的關(guān)鍵參數(shù)如上圖左側(cè)所示：rtt_min表示1s內(nèi)的RTT最小值，send_bitrate_max表示1s內(nèi)最大的發(fā)送bitrate，常規(guī)情況我們大概200～300毫秒統(tǒng)計(jì)一次；inflight表示已經(jīng)發(fā)送出去但還未接收到ACK的報(bào)文的個(gè)數(shù)，這種情況可能意味著報(bào)文還在傳輸鏈路的途中；BDP(bandwidth-delay product) BDP = send_bitrate_max*rtt_min表示一個(gè)RTT內(nèi)發(fā)送的最大字節(jié)數(shù)。如果BDP大于（1.2 x inflight）表示網(wǎng)絡(luò)狀況良好，可以增加編碼碼率；如果BDP小于（0.8 x inflight）則意味著網(wǎng)絡(luò)狀況不佳需要減少編碼碼率，其他情況則維持現(xiàn)有編碼碼率不變。這樣便能較為有效地避免網(wǎng)絡(luò)擁塞的情況發(fā)生。
3.2.2 基于SRT自適應(yīng)碼率編碼——實(shí)例
我們以測(cè)試實(shí)例來(lái)驗(yàn)證效果：通過(guò)Internet推流，來(lái)自于美國(guó)的SRT編碼器的數(shù)據(jù)推至杭州的節(jié)點(diǎn)，建立SRS4.0。該測(cè)試開(kāi)源地址如圖中所示，使用FFmpeg配置編碼碼率為1000kbps，傳輸過(guò)程中根據(jù)實(shí)際出口帶寬動(dòng)態(tài)調(diào)整編碼碼率。由上圖右側(cè)圖線1我們可以看到自適應(yīng)碼率最高可達(dá)到1400kbps，有良好的自適應(yīng)效果；實(shí)際測(cè)試感受來(lái)看，視頻播放平滑無(wú)明顯卡頓，即便偶爾出現(xiàn)帶寬抖動(dòng)也能夠迅速恢復(fù)。
4. SRT與QUIC
接下來(lái)我們對(duì)比SRT與QUIC，總結(jié)二者特點(diǎn)。
4.1 SRT1.4的優(yōu)缺點(diǎn)
SRT1.4的優(yōu)缺點(diǎn)可以簡(jiǎn)單概括為以下內(nèi)容：SRT的優(yōu)點(diǎn)在于基于音視頻按照時(shí)間戳進(jìn)行收發(fā)，可有效保證音視頻，同時(shí)ACK/ACKACK/NACK多種丟包糾正機(jī)制可有效降低延時(shí)與丟包率。SRT對(duì)上層提供豐富的傳輸層數(shù)據(jù)信息如RTT、lost packet rate、receive rate等。當(dāng)然，SRT的缺點(diǎn)也不容忽視，如SRT的擁塞控制過(guò)于簡(jiǎn)單，需要在傳輸層合入BBR算法，原生SRT不支持連接遷移等?；谝陨咸攸c(diǎn)，我認(rèn)為SRT更加適合編碼器到最近節(jié)點(diǎn)的傳輸，也就是通過(guò)SRT探測(cè)出的RTT等相關(guān)信息實(shí)現(xiàn)自適應(yīng)碼率編碼；除此之外，SRT也適合網(wǎng)絡(luò)節(jié)點(diǎn)固定、網(wǎng)絡(luò)情況固定的環(huán)境，合理配置lantency、send/recv buffer、ohead rate等SRT參數(shù)可達(dá)到事半功倍的效果。
4.2 QUIC的優(yōu)缺點(diǎn)
QUIC的優(yōu)點(diǎn)是連接快，同時(shí)具有可插拔的擁塞控制，包括CUBIC、BBR；另外在丟包重傳方面，QUIC擁有更多的ACK block，最大可達(dá)256個(gè)，并且對(duì)于RTT的計(jì)算更加準(zhǔn)確（QUIC中存在獨(dú)立的Packet number，包括重傳包在內(nèi)的Packet number也都不相同，非常有利于RTT的精確計(jì)算）；最后還有QUIC支持連接遷移。當(dāng)然，QUIC同樣存在缺點(diǎn)：第一，報(bào)文頭大在發(fā)送報(bào)文中所占比例較高。第二，丟包重傳只有ACK原生；第三，QUIC不支持丟包，一旦出現(xiàn)丟包，若沒(méi)有在timeout前恢復(fù)就會(huì)斷開(kāi)連接?；谝陨蟽?yōu)缺點(diǎn)，我認(rèn)為QUIC更適合運(yùn)用在網(wǎng)絡(luò)丟包率較高的環(huán)境，因?yàn)镼UIC具有0RTT快速連接能力、丟包重傳中ACK回復(fù)的block較大并且在擁塞控制方面表現(xiàn)非常優(yōu)秀。除此之外QUIC也適合用于長(zhǎng)距離傳輸當(dāng)中，因?yàn)榫W(wǎng)絡(luò)傳輸RTT較高，QUIC在連接斷開(kāi)后重連是0RTT，傳輸數(shù)據(jù)更加高效。
4.3mediago服務(wù)：rtmp over quic
Mediago具有支持QUIC協(xié)議來(lái)傳輸RTMP直播流的特性，如RTMP over TCP推拉流、RTMP over QUIC推拉流以及對(duì)FLV的支持。服務(wù)器之間則支持基于TCP服務(wù)器間RTMP回源與基于QUIC服務(wù)器間RTMP回源，上圖中有測(cè)試鏈接，感興趣的朋友可以自己嘗試一下。
服務(wù)推薦
|
