編者按： 攝像頭是物聯(lián)網(wǎng)世界的眼睛，擁有體積小且節(jié)能的特征，而視頻監(jiān)控一直是跟音視頻緊密結(jié)合的領(lǐng)域，同時(shí)成本控制要求嚴(yán)苛。傳統(tǒng)的視頻監(jiān)控解決方案陳舊且復(fù)雜，不能滿足靈活訪問(wèn)控制的要求，在視頻大時(shí)代的背景下，如何才能適應(yīng)日益增長(zhǎng)的需求呢？攝像頭雖小，但對(duì)音視頻秒開(kāi)、低延遲的要求卻一點(diǎn)都不低；隨著 RTC 的日漸普及，大家對(duì)其了解逐漸深入，會(huì)發(fā)現(xiàn)并不是只有 WebRTC 才擁有這個(gè)特性。本次分享將回顧視頻大時(shí)代的發(fā)展脈絡(luò)，介紹 P2P 網(wǎng)絡(luò)架構(gòu)的協(xié)議擴(kuò)展，并結(jié)合 RTC 理論，探索在 IoT 視頻監(jiān)控領(lǐng)域上的應(yīng)用落地實(shí)踐。

文 / 張鵬

整理 / LiveVideoStack

大家好，我是張鵬，我來(lái)分享一下，對(duì)等網(wǎng)絡(luò)在物聯(lián)網(wǎng)上的應(yīng)用，已經(jīng)成功應(yīng)用到消費(fèi)級(jí)家用攝像頭、智能門(mén)鈴 / 門(mén)鎖等產(chǎn)品。這次分享主要有 3 個(gè)部分，介紹、高效傳輸、總結(jié)，將重點(diǎn)分享我們結(jié)合對(duì)等網(wǎng)絡(luò)如何在物聯(lián)網(wǎng)上做到極致體驗(yàn)的。

1、Introduction

在此之前，先介紹一些概念。

首先就是一個(gè)網(wǎng)絡(luò)拓?fù)?，其?shí) P2P 算是音視頻領(lǐng)域的一個(gè)老朋友了，兩年前我在 LiveVideoStackCon 分享過(guò)一次，但當(dāng)時(shí) P2P 主要是是用來(lái)節(jié)省帶寬，放在現(xiàn)在的環(huán)境里依然適用，幫助企業(yè)降本增效。那 P2P 是什么呢？現(xiàn)在流行的 Web3，它的底層網(wǎng)絡(luò)就是 P2P，所以 P2P 的應(yīng)用場(chǎng)景不僅僅是節(jié)省帶寬那么簡(jiǎn)單，還有很多場(chǎng)景是可以發(fā)揮。我今天分享的就是 P2P 在 IoT 場(chǎng)景的應(yīng)用。

再說(shuō)物聯(lián)網(wǎng)，這個(gè)概念已經(jīng)提出好多年了，但大家對(duì)物聯(lián)網(wǎng)的規(guī)模可能還不太了解。舉個(gè)例子對(duì)比一下，微信已經(jīng)有十億的用戶了，但物聯(lián)網(wǎng)的規(guī)模是上百億的，這里面的增長(zhǎng)性是很好的，到處都充滿機(jī)會(huì)。而騰訊又是專注于連接的一家公司，之前是連接人與人、人與服務(wù)，連接線上和線下，現(xiàn)在我們把這個(gè)連接擴(kuò)展到連接人與物、設(shè)備與設(shè)備，把這個(gè)連接做得更徹底。

IoT 行業(yè)很大，今天分享的主要是在 IoT Video 行業(yè)，跟 LiveVideoStackCon 音視頻技術(shù)大會(huì)的主題也非常相關(guān)。上圖都是一些攝像頭設(shè)備，大家對(duì)攝像頭應(yīng)該不陌生，可能已經(jīng)買(mǎi)了一些攝像頭在家里做監(jiān)控。攝像頭是整個(gè)物聯(lián)網(wǎng)世界的眼睛，它非常重要，現(xiàn)在有些新興的行業(yè)，比如做機(jī)器人的，已經(jīng)把音視頻作為基礎(chǔ)，在此之上做智能化。別小看這些攝像頭，它的要求絲毫不亞于常規(guī)直播，如智慧門(mén)鈴、智慧門(mén)鎖這些，都要求延遲要在 1 秒以內(nèi)且要絲滑流暢，但這些設(shè)備和我們手機(jī)相比，無(wú)論是算力還是網(wǎng)絡(luò)都差遠(yuǎn)了，而且對(duì)里面能安裝的軟件要求非?？量蹋际呛艿讓拥慕尤敕绞?。在這基礎(chǔ)上，還要做到低成本、低延遲、秒出圖，挑戰(zhàn)是非常大的。

2、Effective Communication

接下來(lái)分享一下，我們是在 IoT 上如何做到音視頻的極致體驗(yàn)優(yōu)化的。

首先是 P2P，之所以選擇 P2P，考慮的依然是隱私和成本，因?yàn)?IoT 非常注重隱私，同時(shí)客戶的成本訴求也很強(qiáng)烈，P2P 打洞成功率越高，就越能節(jié)省成本，而 RFC 中的 NAT 劃分、ICE 的打洞方式相對(duì)比較古老，在國(guó)內(nèi)的打洞成功率并不高。而騰訊的 P2P 依托 QQ、旋風(fēng)下載、QQ 影音、騰訊視頻、微信等積累，能把打洞成功做到大于 80% 的水平，像端口預(yù)測(cè)、生日攻擊這些技術(shù)，應(yīng)有盡有，打洞握手耗時(shí)僅 200ms。

P2P 打洞是一個(gè)很好的 P2P 入門(mén)技術(shù)，它很有技巧性，你了解了以后會(huì)猛然發(fā)現(xiàn)，網(wǎng)絡(luò)原來(lái)還可以這樣玩。比如 TCP 打洞，學(xué)過(guò)計(jì)算機(jī)網(wǎng)絡(luò)的同學(xué)可能知道，有一種 TCP 四次握手機(jī)制，兩邊同時(shí)去發(fā) SYN 主動(dòng)連接。在工作的幾年里，我始終沒(méi)見(jiàn)到哪兒會(huì)用到這種握手，甚至網(wǎng)絡(luò)上都要搜不到相關(guān)資料了。后來(lái)才發(fā)現(xiàn)，原來(lái)是在 TCP 打洞時(shí)會(huì)用到這種技術(shù)，兩方都是直接連對(duì)方，心中一陣暗暗稱奇。

打洞之后，就是傳輸了，節(jié)點(diǎn)可以相互去直連傳輸通信，但如果不受控制的傳輸，是萬(wàn)萬(wàn)不行的，所以必須要有傳輸速率控制，流量控制等。早期 P2P 為什么它的名聲比較差，一方面它傳輸?shù)膬?nèi)容侵犯了版權(quán)，另一方面是它無(wú)情地?fù)屨剂藥捹Y源，把網(wǎng)絡(luò)搞得很擁擠，給運(yùn)營(yíng)商治理網(wǎng)絡(luò)造成了很大的困擾，運(yùn)營(yíng)商索性就把它封殺了。P2P 之前是這樣一個(gè)狀態(tài)，但這是不對(duì)的，打洞成功后，一定不能瘋狂地發(fā)數(shù)據(jù)，干這種傻事，而是要和所有其他傳輸協(xié)議一樣，友好、公平地一起利用好網(wǎng)絡(luò)。

我們自主研發(fā)的傳輸協(xié)議 ETC，則是將 Pacing 和 Burst 相結(jié)合，因?yàn)樗鼈儐为?dú)來(lái)講都有各自的優(yōu)缺點(diǎn)，ETC 則是綜合這兩者的優(yōu)點(diǎn)，抑制它們彼此的缺點(diǎn)，最終得到了一個(gè)能最大程度利用帶寬，延遲低，反應(yīng)快，友好、公平的效果。如右圖所示，在 100M 的鏈路空間內(nèi)，1 個(gè)流的時(shí)候要利用到 100M，2 個(gè)流的時(shí)候每個(gè) 50M，5 個(gè)流時(shí)每個(gè) 20M，利用率很高。反應(yīng)靈敏，帶寬調(diào)整收斂速度快，相比慢啟動(dòng)而言能一下子利用到 100M，2 個(gè)流的時(shí)候，一下子各自帶寬調(diào)整到 50M，很公平。因?yàn)榫W(wǎng)絡(luò)是實(shí)時(shí)變化的，這一刻可能 5 個(gè)流，每個(gè) 20M，下一刻可能就是剩下 4 道流每條 25M，這種就是要能做到立刻感知，也就是不停地探測(cè)、調(diào)整，傳輸協(xié)議最好的辦法就是不停地向上探測(cè)一下有沒(méi)有可用帶寬，超過(guò)了就向下調(diào)整一下，以打水漂的方式來(lái)回探測(cè)，而且在穩(wěn)定態(tài)這個(gè)打水飄探測(cè)的幅度越小越好，這塊 ETC 做得相當(dāng)不錯(cuò)。

有了 P2P 和傳輸之后，接下來(lái)要解決低延遲、秒出圖的需求。這里有個(gè)前輩 WebRTC，它也有 P2P 和傳輸，又和音視頻結(jié)合，很值得借鑒。

這里想先和大家探討下，WebRTC 是怎么做到低延遲的？我之前聽(tīng)到最多的一句回答，就是使用了 UDP，但 UDP 和低延遲還差了十萬(wàn)八千里。也有常見(jiàn)回答說(shuō)因?yàn)槭褂昧?P2P，兩個(gè)節(jié)點(diǎn)直連或許會(huì)更好一點(diǎn)，比如在同一個(gè)內(nèi)網(wǎng)下，但也有時(shí)候可能還沒(méi)經(jīng)過(guò)公網(wǎng)轉(zhuǎn)發(fā)時(shí)效果好。

如果對(duì) WebRTC 了解更深刻一點(diǎn)，可能會(huì)回答說(shuō)，因?yàn)槭褂昧?RTP/RTCP，或者是因?yàn)?WebRTC 有內(nèi)置 TCC 傳輸控制，這是比較好一點(diǎn)的答案了。

如果再對(duì) WebRTC 更了解一點(diǎn)的話，會(huì)回答說(shuō)是因?yàn)?WebRTC 有非常優(yōu)秀的 jitter buffer 管理，這已經(jīng)接近標(biāo)準(zhǔn)答案了，但大家對(duì) jitter buffer 可能還是只知概念，不知具體怎么管理的，覺(jué)得 jitter buffer 是不是播放器的緩沖區(qū)少了就把它給拉長(zhǎng)慢放，緩沖區(qū)多了就快進(jìn)一些，跳幀追幀，然后是不是就實(shí)現(xiàn)低延遲了？那是不是把 jitter buffer 策略挪到 TCP 上實(shí)現(xiàn)，TCP 上也能實(shí)現(xiàn)低延遲了呢？帶著這些疑問(wèn)，我們繼續(xù)向下深究。

我們整個(gè)行業(yè)，把低延遲的大部分精力放在兩個(gè)方向上，第一個(gè)是編解碼，如何能更快地編碼出幀來(lái)發(fā)送給對(duì)方；第二個(gè)就是去搞傳輸協(xié)議，認(rèn)為低延遲和傳輸協(xié)議很相關(guān)。其實(shí)我們前面做的直連、P2P、傳輸協(xié)議都已經(jīng)很優(yōu)秀了，但距離低延遲依然有一定差距，為什么呢？編解碼是有一定作用，可是現(xiàn)在編碼性能已經(jīng)很高，基本都是硬件加速，編碼出一幀只需要幾毫秒小幾十毫秒，對(duì) 1 秒 2 秒的延遲占比很小，它并不構(gòu)成延遲的主要成因。

要探討這個(gè)問(wèn)題，就要老生常談延遲到底發(fā)生在什么地方。如圖所示，延遲可能發(fā)生在編碼、采集、前處理、端到端延時(shí)、解碼、后處理等，這里像編碼、采集、前處理、后處理都是硬件控制的，對(duì)延遲不苛刻到百毫米以內(nèi)的話，編解碼和網(wǎng)絡(luò)時(shí)延的占比對(duì)延遲的影響微乎其微，基本就是 10 毫秒量級(jí)。距離的影響也不大，雖然深圳到北京肯定要比上海到北京要慢，但基本上也都是 30 毫秒一個(gè) RTT，差不太多。那這里面是什么造成了延遲，我們能控制的又是什么呢？一個(gè)是 GOP 的長(zhǎng)度，另一個(gè)就是大家經(jīng)常忽略的全鏈路的緩沖時(shí)長(zhǎng)，這個(gè)才是重點(diǎn)，最值得關(guān)注。

從 GOP 入手降低延遲，比較典型的就是 HLS 和 LL-HLS。直接降低 GOP 長(zhǎng)度，把 TS 切片從 10s 降低到 2s。但這有一點(diǎn)問(wèn)題，GOP 短了，會(huì)影響壓縮效率，所以 GOP 肯定還是大于 2s，那還是有平均 1s 的延遲解決不了。

從緩沖區(qū)入手降低延遲，經(jīng)常的做法就是如果播放器緩沖區(qū)變長(zhǎng)，那就快進(jìn)，兩年前我和一個(gè)同事還聊到，標(biāo)準(zhǔn)直播能不能做到低延遲的程度，當(dāng)時(shí)的結(jié)論是可以，配合播放器，播放器如果有緩沖，就去快進(jìn)，就能實(shí)現(xiàn)低延遲，但很少有播放器做這個(gè)策略，我們的視立方有做，大家可以試用一下，其實(shí)絕大部分情況下也都能滿足。但做了這個(gè)之后，有些場(chǎng)景下的延遲效果依然不盡人意，為什么呢？因?yàn)楹雎粤税l(fā)送側(cè)的發(fā)送緩沖區(qū)！

如果把 WebRTC 的 jitter buffer 放到 TCP 上去實(shí)現(xiàn)的話，TCP 依然做不到低延遲。因?yàn)?TCP 發(fā)送端有一個(gè)內(nèi)核里的發(fā)送緩沖區(qū)，當(dāng)網(wǎng)絡(luò)變差時(shí)，發(fā)送緩沖區(qū)會(huì)先填滿，應(yīng)用層卻控制不了，因?yàn)樵趦?nèi)核里面。此時(shí)，應(yīng)用層還不知道發(fā)送緩沖區(qū)已經(jīng)擁堵了，之后發(fā)送緩沖區(qū)會(huì)被填滿，無(wú)法寫(xiě)進(jìn)，這時(shí)應(yīng)用層的才能感知到，網(wǎng)絡(luò)擁堵了，要開(kāi)始應(yīng)對(duì)了，但這時(shí)已經(jīng)晚了。TCP 就是這種，感受網(wǎng)絡(luò)的變化太晚了，而且應(yīng)用層對(duì)發(fā)送緩沖區(qū)內(nèi)的數(shù)據(jù)無(wú)能為力。

可以看到，產(chǎn)生延遲的另一個(gè)重要原因是在發(fā)送端的緩沖區(qū)，這是播放器快進(jìn)追幀策略鞭長(zhǎng)莫及的。再對(duì)比一下 RTP 和 RTCP 的是如何解決這個(gè)問(wèn)題的，RTP 和 RTCP 配合 WebRTC 的傳輸從根本上而言是讓傳輸和音視頻的特性緊密的結(jié)合起來(lái)，來(lái)實(shí)現(xiàn)的低延遲。當(dāng)對(duì)端發(fā)現(xiàn)網(wǎng)絡(luò)卡的時(shí)候，它會(huì)通過(guò) RTCP 立即告訴發(fā)送端，網(wǎng)絡(luò)差了，數(shù)據(jù)少發(fā)些，因?yàn)檫@時(shí)網(wǎng)絡(luò)資源變得緊缺了，然而少發(fā)哪些數(shù)據(jù)也是有講究的，不是說(shuō)把這 1s 的后半秒全都丟了，而是均勻地去丟才好，先把均勻地丟 B 幀，再是均勻地丟 P 幀，它需要發(fā)送端配合做一些決策，或者更直接地降低碼率，讓數(shù)據(jù)依然能均勻地發(fā)送到對(duì)端。

總結(jié)一下就是，全鏈路緩沖區(qū)管理防積壓，網(wǎng)絡(luò)不足時(shí)主動(dòng)減，減有降碼率和降幀率兩種方法，我們?cè)谧鑫锫?lián)網(wǎng)時(shí)，端到端各項(xiàng)參數(shù)都由我們控制，比如幀率 40fps，網(wǎng)絡(luò)變差了，我們可以讓發(fā)送端直接變成 20fps。其他場(chǎng)景下，直播可以利用 SVC 編碼，不斷地能把 B 幀 P 幀優(yōu)先丟掉，均勻地去丟幀，也能把幀率降下來(lái)。關(guān)鍵還要及時(shí)反饋，像 RTCP 一旦網(wǎng)絡(luò)變差，可以馬上傳送給接受端，TCP 的弱點(diǎn)就在不能馬上反饋給發(fā)送端，RTCP 就可以根據(jù)視頻幀級(jí)別的去反饋，jitter buffer 機(jī)制的核心就在這里。

現(xiàn)在知道了低延遲是怎么做的了，那如何擴(kuò)展到非 WebRTC 場(chǎng)景呢？這里面有幾個(gè)難點(diǎn)。第一個(gè)在于發(fā)送緩沖區(qū)有多少數(shù)據(jù)未發(fā)送，其實(shí)發(fā)送端絲毫不知情，但這里面可能積壓有數(shù)秒的數(shù)據(jù)了，造成的延遲已經(jīng)很高了。第二個(gè)難點(diǎn)是播放端要有一個(gè)及時(shí)反饋的通道，這個(gè)通道大部分直播方案是沒(méi)有的，唯一的解法，好像只有通過(guò)將音視頻的特性和傳輸協(xié)議相結(jié)合的 RTP。RTP/RTCP 將網(wǎng)絡(luò)傳輸與音視頻特性相結(jié)合的思路是好的，但很多傳輸協(xié)議卻又是分層的，設(shè)計(jì)時(shí)并不替音視頻應(yīng)用特性考慮。這里也借此糾正一個(gè)誤區(qū)，前段時(shí)間遇到個(gè)說(shuō)法 RTMP/HTTP-Flv 等這些都是傳輸層的，其實(shí)并不是，他們都是應(yīng)用層的，比如 RMTP 就感知不到 TCP 的緩沖區(qū)積壓了多少。

以上 2 個(gè)難點(diǎn)不好解決，但也并非毫無(wú)辦法，主要思路便是通過(guò)應(yīng)用層接管緩沖區(qū)管理?？梢栽趹?yīng)用層建立自己的幀級(jí)別的隊(duì)列，接收端收到一個(gè)幀就要向發(fā)送端反饋一個(gè) Ack，此 Ack 非傳輸層的 Ack，而是應(yīng)用層自己的，這樣就能越過(guò)傳輸層，令發(fā)送端能感知到發(fā)送緩沖區(qū)里的幀數(shù)據(jù)是否已經(jīng)傳輸過(guò)去。

更具體一點(diǎn)，首先把發(fā)送緩沖區(qū)設(shè)置足夠小，接收緩沖區(qū)一有數(shù)據(jù)就馬上讀出來(lái)。然后，作為直播應(yīng)用層協(xié)議的 HTTP GET 請(qǐng)求，是沒(méi)有及時(shí)反饋通道的；但變成 POST 請(qǐng)求，POST 請(qǐng)求帶請(qǐng)求體的，就可以讓 POST 請(qǐng)求每解析完一幀，就在請(qǐng)求體中寫(xiě)一行在什么時(shí)間點(diǎn)收到了一幀，幀的 pts 是多少，播放器的 buffer 多少，這樣就建立起了一個(gè)反饋通道。這個(gè)反饋通道完全是應(yīng)用層的，可以告訴服務(wù)器（發(fā)送端)，讓服務(wù)器及時(shí)調(diào)整。最后，因?yàn)榘l(fā)送端并沒(méi)有把很多數(shù)據(jù)寫(xiě)給發(fā)送緩沖區(qū)，相當(dāng)于應(yīng)用層接管了待發(fā)送數(shù)據(jù)的管理權(quán)，所以當(dāng)網(wǎng)絡(luò)變差，發(fā)送端就可以根據(jù) POST 請(qǐng)求的反饋去降幀率 / 碼率，這樣就能夠?qū)崿F(xiàn)低延遲了。

回顧一下直播興起的歷程，其實(shí)直播的興起離不開(kāi) HTTP。整個(gè)音視頻里有很多協(xié)議，這無(wú)形中增加了大家進(jìn)入音視頻行業(yè)的門(mén)檻，而 Web 能發(fā)展如此迅速，就是因?yàn)樗挥幸粋€(gè)大家都耳熟能詳?shù)?HTTP 協(xié)議。直播興起的時(shí)候，恰逢 HTTP-FLv、HLS 和 DASH 的出現(xiàn)，他們有很明顯的特征，就是都是 HTTP 的，因此能很方便的被接入到互聯(lián)網(wǎng)的任何一個(gè)角落，比如瀏覽器，使用 HTTP 發(fā)送請(qǐng)求，就非常 easy，但如果你讓瀏覽器 RTMP 去拉一個(gè)直播流就會(huì)非常麻煩。像 IoT 這個(gè)行業(yè)，它的協(xié)議簇也非常繁雜，但我們覺(jué)得如果要把 IoT Video 進(jìn)一步擴(kuò)展到互聯(lián)網(wǎng)每個(gè)角落，都統(tǒng)一收斂到一個(gè) HTTP 的話，在 HTTP 上又能實(shí)現(xiàn)低延遲、低成本、好效果，那無(wú)疑是能讓很多人更快進(jìn)入這個(gè)領(lǐng)域。

所以我們整個(gè)架構(gòu)是這樣的，底層利用了 IP/IPv6、ICMP、UDP，再做了一層 P2P，在之上的傳輸層，實(shí)現(xiàn)了高效可靠傳輸，再上面實(shí)現(xiàn)了應(yīng)用層協(xié)議 HTTP，支撐各種各樣的應(yīng)用場(chǎng)景。這樣的架構(gòu)最大的好處，就是分層清晰，對(duì)開(kāi)發(fā)者很友好，大家都懂 HTTP，但如果是 WebRTC 這么復(fù)雜的東西，想必大家會(huì)感到很頭痛。

這樣我們做音視頻攝像頭的場(chǎng)景支持起來(lái)就非常的簡(jiǎn)單，比如攝像頭是簡(jiǎn)單的 HTTP 直播源服務(wù)器，手機(jī)便是 HTTP 直播客戶端，可以向服務(wù)器發(fā)起請(qǐng)求。不僅適用于 1v1 還適用于 1v 多，多人觀看攝像頭搭配 P2P 的方式。在效果上，使用前文講的低延遲之道，延遲也能做到很低。實(shí)現(xiàn)低延遲并不一定非要直接采用 WebRTC，更好的方式是把 WebRTC 的理念思想，給學(xué)習(xí)過(guò)來(lái)，應(yīng)用到我們所需的場(chǎng)景中，把它的復(fù)雜度降低，才能促進(jìn)產(chǎn)業(yè)的繁榮。

與 WebRTC 相比，WebRTC 的 P2P 是標(biāo)準(zhǔn)的 ICE，在國(guó)內(nèi)的環(huán)境里成功率沒(méi)那么高，成本高，WebRTC 也更復(fù)雜、更耗 CPU，在 IoT 去集成它是很難的，IoT 本來(lái)可用的存儲(chǔ)空間都已經(jīng)非常小，把 WebRTC 弄進(jìn)去更難，所以它行不通。我們這個(gè)則是輕量級(jí)的，打洞成功率又高，又通過(guò)全鏈路緩沖區(qū)管控實(shí)現(xiàn)了很低的延遲，接入也非常簡(jiǎn)單，只要懂 HTTP 協(xié)議，就可以輕松地理解使用。

3、Summary

最后總結(jié)一下。首先是低延遲之道，這張圖可以幫大家回答低延遲的關(guān)鍵步驟，除了很快的編解碼，還有經(jīng)常被忽視的、更重要的全鏈路緩沖區(qū)管理。第一步是起播的低延遲，因?yàn)槲覀兪亲?IoT 的，一開(kāi)始就是 I 幀，沒(méi)有 GOP 的影響，但是如果做直播內(nèi)容分發(fā)，就有 GOP 影響了。起播低延遲處理最好的，應(yīng)該是騰訊云的快直播 WebRTC，它的起播處理，非常有技巧性，這里因?yàn)闀r(shí)間原因就不再具體分享了，有興趣的話可以了解一下騰訊云快直播 WebRTC 產(chǎn)品。第二步就是傳輸協(xié)議的加持，傳輸協(xié)議的延遲，雖然不會(huì)影響很大，但還是很重要的，如果你用 TCP 也能做低延遲，但和 WebRTC 的低延遲相比還是差一些。第三步是播放端的反饋通道，要想辦法建立一個(gè)通道能及時(shí)反饋，播放器每收一幀，就把收幀時(shí)長(zhǎng)反饋過(guò)去。第四步就是延遲保持，服務(wù)器和播放器中的緩沖就應(yīng)該盡量小，大了播放器快進(jìn)追幀，服務(wù)器則通過(guò)均勻丟幀降幀率或者降碼率來(lái)適配。

我們?cè)?IoT 上還做了很多其他的工作。IoT 的使用場(chǎng)景都是智能硬件，有很多系統(tǒng)，比如 FreeRTOS、展銳 RTOS。我們適配了很多設(shè)備，這些設(shè)備可以按照統(tǒng)一的協(xié)議和安卓 iOS 互通。還能與小程序互動(dòng)，直接在微信小程序上看家中攝像頭的直播。和微信小程序打通后，還帶來(lái)了其他收益，比如說(shuō)，能夠把家中攝像頭很容易的分享給其他人，可以利用微信小程序的登錄、分享等諸多功能運(yùn)營(yíng)私域流量。

對(duì)比一下其他的 IoT Video 接入方式，如 RTMP 或者 H5+WebRTC，我們的優(yōu)勢(shì)在于，出圖時(shí)間快，延遲低，程序大小可以滿足 IoT 設(shè)備的要求，還是熟悉的 HTTP 協(xié)議，接入起來(lái)非常簡(jiǎn)單，網(wǎng)絡(luò)直連率也比 WebRTC 要高，更加隱私同時(shí)節(jié)省成本。

以上就是我這次分享的關(guān)于 P2P 在 IoT 領(lǐng)域上的應(yīng)用。P2P 之前是在內(nèi)容分發(fā)上幫助降本增效節(jié)省成本，做到了跨端，安卓 /iOS/ 小程序都支持，延遲、秒開(kāi)質(zhì)量效果都很好，現(xiàn)在我們又成功地把這些功能特性拓展到物聯(lián)網(wǎng) IoT 領(lǐng)域，這套產(chǎn)品對(duì)用戶網(wǎng)絡(luò)和客戶開(kāi)發(fā)者都很友好。最后，我們致力于將 P2P 和音視頻技術(shù)拓展到更多領(lǐng)域，希望大家共勉，謝謝！