隨著網路架構的變遷、媒體技術發展、音影片場景迭代，基於流媒體的技術也是推陳出新。WebRTC漸漸的成為了音影片互動場景的主流，而微信在6.5.21版本透過小程式開放了實時音影片能力，開發者們可以使用元件 < live-pusher > 實現基於 RTMP 的直播推流（錄製），用於實時音視訊通話上行，使用元件 < live-player > 實現基於 RTMP 的直播拉流（播放）。可以看出，微信小程式的音影片是基於 RTMP 協議的，但是微信小程式的音影片只是提供了終端上的能力，並沒有實現媒體伺服器，騰訊給出了2個方案，1是使用騰訊雲的快直播服務，2是開發者自己實現一套媒體閘道器服務。方案1，需要完全使用騰訊雲的服務，很顯然不太適合我們這樣的開發者；於是留給我們的之後方案2了。

## 一．什麼是RTMP，什麼是RTC

**1.RTMP**

RTMP是Real Time Messaging Protocol實時訊息傳輸協議，是Adobe公司為Flash播放器和伺服器之間開發的音影片資料傳輸的開放協議，一般傳輸flv或f4v格式的媒體流。RTMP是工作在TCP之上的協議，預設使用埠1935，能夠保持長連線，併為使用者提供低延時通訊。RTMP是目前低延時直播應用最普遍的協議，幾乎是全部編碼器標準輸出協議，是PC機開啟瀏覽器就能播放（通常瀏覽器預設有Flash），也是全部CDN支援的最好的直播分發協議。

RTMP是基於TCP協議的，且通常只佔用TCP一個通道來傳輸資料和指令，能保證了影片的傳輸質量。RTMP包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。RTMPT封裝在HTTP請求之上，可穿透防火牆；RTMPS類似RTMPT，增加了TLS/SSL的安全功能；RTMPE在RTMP的基礎上增加了加密功能。

因為RTMP是基於TCP之上的，所以也存在三次握手的要求，另外RTMP還增加了C0/S0到C2/S2的三次握手。所以播放一個RTMP協議的流媒體需要經過：握手，建立連線，建立流，播放。

RTMP也有不可忽視的缺點，首先，RTMP協議太老，HEVC/H.265/AV1等影片格式都沒有官方定義，另外就如剛剛所說，RTMP連線過程較長，存在TCP三次握手和本身的C0/S0到C2/S2的三次握手，再加上connection，createstream，play/publish，總地來說RTMP完成一次建連需要進行9次會話。而且RTMP的擁塞控制完全依賴傳輸層TCP的擁塞控制演算法來進行擁塞管理，無法提供頻寬自適應的演算法。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/b2f1bf6b573341a5ab5e6bb083502e47.jpeg#pic_center)

**2.WebRTC**

WebRTC是Web Real-Time Communication網頁實時通訊，是一個支援網頁瀏覽器進行實時語音對話或影片對話的技術而無需任何外掛。由谷歌2010年以6820萬美元收購Global IP Solutions公司而獲得，如今WebRTC已經不僅僅侷限於PC的網頁瀏覽器，Android，iOS平臺上很多應用都已經採用了這樣技術。

WebRTC使用是RTP分裝碼流，跟影片監控，IPTV，會議電視一樣都是RTP承載媒體流，只不過WebRTC信令遵守ICE框架，走自定義信令，IPTV領域走RTSP信令，影片監控走GB28181或者onvif信令，會議電視走h323或SIP協議。另外，WebRTC的碼流採用SRTP進行加密，且WebRTC優先使用VP9、VP8、H.264、AV1，暫不支援H.265。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/f87c1a49da294007abd573b617397ff8.jpeg#pic_center)

## 二．WebRTC如何跟小程式互通

**1.如何互通大概分三步走：**

A.微信小程式端使用 RTMP 協議，接入邊緣媒體閘道器，即 Xcx閘道器；

B.Xcx閘道器支援 RTMP 協議接入和輸出，完成微信小程式間的媒體轉發；

C.同時Xcx閘道器將 RTMP 協議轉換成 RTP 協議，轉發給anyRTC的WebRTC伺服器，完成與Native、標準 WebRTC 終端的互聯互通。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/e490e2ca88f044bf9cbf7b53b745c56d.jpeg#pic_center)

anyRTC的Xcx閘道器的主要工作就是對RTMP和WebRTC的音影片格式進行轉換。一般RTMP的影片是H264編碼，音訊是AAC編碼；WebRTC的影片是H264編碼，音訊是Opus編碼。所以我們可以看出，影片只需要轉換封裝格式，而音訊則需要進行轉碼工作。

**2.影片格式轉換**

anyRTC的Xcx閘道器收到影片幀之後，將幀進行RTP 封裝 H.264。

WebRTC 選擇了使用 RFC3984 的 Non-Interleaved 封裝方案對H.264 進行封裝。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/fb4aeb9721e64c50bba34317923b159c.jpeg#pic_center)
**Single NAL Unit Packet**

Single NAL Unit Packet 是 RTP 最基本的打包方式，其中，
forbidden_bit：禁止位，初始為0，當網路發現 NAL 單元有位元錯誤時可設定該位元為 1，以便接收方糾錯或丟掉該單元。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/e8a29002ad9c430e95e40b91f6dcc255.jpeg#pic_center)

nal_reference_bit：nal 重要性指示，標誌該 NAL 單元的重要性，值越大，越重要，解碼器在解碼處理不過來的時候，可以丟掉重要性為 0 的 NALU。Type：NAL 單元中的 RBSP 資料結構的型別，其中 0 未指，1-19 在 H.264 協議中有定義，20-23 為 264 協議指定的保留位，24-29 在 RFC3984 中進行了指定。Type 後面的資料為 RBSP 的資料，需要注意的是：編碼器的每個 slice 或者每幀頭一般會有由0x000001 或者 0x00000001 作為起始頭，在 RTP 封裝中需要去掉。此外在 H.264 裸碼流資料後面可能還會帶有 padding 的資料由 RTP 頭的 padding 位決定。

**STAP-A**

STAP-A 的作用是可以把多個 nal 單元封裝在一個 RTP 包裡面進行傳輸，需要注意：-A 的格式都是不允許跨幀的，也就是 nal 單元的時間戳必須是相同的。常見的場景是 sps 和 pps 兩個小包被合併封裝。
![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3d47a33acdfc4bcf9a98176e9f500a13.jpeg#pic_center)
RTP 頭後面僅跟著 STAP-A 的頭，由 F、NRI 和 Type 組合而成，佔一個位元組，這裡的 Type 為 24。後面兩個位元組為第一個 nalu 單元的長度，後面跟第一個 nalu 資料同 Single NAL Unit 的封裝一致，第一個資料結束後，跟著第二個 nalu 的長度，佔 2 個位元組，依次類推。

**FU-A**

FU-A 的作用是把一個原始大的 nalu 切成多個資料包進行傳輸，主要使用場景在 slice 比較大的情況下。FU-A 比較特殊，有 FU-A 起始包、FU-A 包（如果只切兩個包可能沒有）和 FU-A 結束包組成。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/47ebecb6d4a9491fa42807a31b1e0f4a.jpeg#pic_center)

FU indicator 佔一個位元組，由 F、NRI 和 Type 組合而成，這裡的 Type 為28。FU header 佔一個位元組：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/42a42186e61044ada7be324cb928aae4.jpeg#pic_center)

S： 佔1位如果是1表示當前這個包是 FU-A 的起始包E： 佔1位如果是1表示當前這個包是 FU-A 的結束包R： 佔1位，保留位，為0Type： 實際包含 nalu 的型別。

**音訊轉碼**

在Xcx閘道器中，我們採用了獨立的音訊轉碼執行緒組，減輕邏輯處理執行緒的壓力的目的。每個轉碼任務將被分配到固定的音訊轉碼執行緒，執行緒根據任務數量進行負載均衡。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/0dbfabca3bf54d59b7976933f6ccbf91.jpeg#pic_center)

## 三．總結

與小程式的互通相對來說還是比較容易實現，開發者可以選擇anyRTC的小程式服務，避免過多的踩坑；也可以嘗試自己實現一套服務來滿足自身的業務訴求。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/e84a3e5612924fe7b8d2a3b7584ceb15.jpeg#pic_center)

技術分享| anyRTC音影片與微信小程式互通實踐

相關文章