一、直播知識小科普

1. 一個典型的直播流程：錄制->編碼->網(wǎng)絡(luò)傳輸（推流->服務(wù)器處理->CDN分發(fā)）->解碼->播放
2. IPB：一種常用的視頻壓縮方案，用I幀表示關(guān)鍵幀，B幀表示前向差別幀，P幀表示雙向差別幀
3. GOP (Group of Pictures)：GOP 越長（I幀之間的間隔越大），B 幀所占比例越高，編碼的率失真性能越高。雖然B幀壓縮率高，但解碼時CPU壓力會更大。
4. 音視頻直播質(zhì)量好壞的主要指標(biāo)： 內(nèi)容延時 、 卡頓（流暢度） 、 首幀時長
5. 音視頻直播需要克服的主要問題：網(wǎng)絡(luò)環(huán)境、多人連麥、主輔路、瀏覽器兼容性、CDN支持等
6. MSE (Media Source Extensions)：W3C 標(biāo)準(zhǔn)API，解決 HTML5 的流問題（HTML5 原生僅支持播放 mp4/webm 非流格式，不支持 FLV），允許JavaScript動態(tài)構(gòu)建 <video> 和 <audio>的媒體流?？梢杂肕ediaSource.isTypeSupported() 判斷是否支持某種MINE類型。在ios Safari中不支持。

1. 文件格式/封裝格式/容器格式 ：一種承載視頻的格式，比如flv、avi、mpg、vob、mov、mp4等。而視頻是用什么方式進(jìn)行編解碼的，則與Codec相關(guān)。舉個栗子，MP4格式根據(jù)編解碼的不同，又分為nMP4、fMP4。nMP4是由嵌套的Boxes 組成，fMP4格式則是由一系列的片段組成，因此只有后者不需要加載整個文件進(jìn)行播放。
2. Codec ：多媒體數(shù)字信號編碼解碼器，能夠?qū)σ粢曨l進(jìn)行壓縮（CO）與解壓縮( DEC ) 。CODEC技術(shù)能有效減少數(shù)字存儲占用的空間，在計算機(jī)系統(tǒng)中，使用硬件完成CODEC可以節(jié)省CPU的資源，提高系統(tǒng)的運行效率。
3. 常用視頻編碼 ：MPEG、H264、RealVideo、WMV、QuickTime。。。
4. 常用音頻編碼 ：PCM、WAV、OGG、APE、AAC、MP3、Vorbis、Opus。。。

二、現(xiàn)有方案比較

RTMP協(xié)議

1. 基于TCP
2. adobe壟斷，國內(nèi)支持度高
3. 瀏覽器端依賴Flash進(jìn)行播放
4. 2~5秒的延遲

RTP協(xié)議

1. Real-time Transpo

   rt P

   rotocol，IETF于1996提出的一個標(biāo)準(zhǔn)

2. 基于UDP
3. 實時性強(qiáng)
4. 用于視頻監(jiān)控、視頻會議、IP電話
5. CDN廠商、瀏覽器不支持

HLS 協(xié)議

1. Http Live Streaming，蘋果提出的基于HTTP的流媒體傳輸協(xié)議
2. HTML5直接支持(video)，適合APP直播，PC斷只有Safari、Edge支持
3. 必須是H264+AAC編碼
4. 因為傳輸?shù)氖乔懈詈蟮囊粢曨l片段，導(dǎo)致內(nèi)容延時較大

   

flv.js

1. Bilibli開源，解析flv數(shù)據(jù)，通過MSE封裝成fMP4喂給video標(biāo)簽
2. 編碼為H264+AAC
3. 使用HTTP的流式IO(fetch或stream)或WebSocket協(xié)議流式的傳輸媒體內(nèi)容
4. 2~5秒的延遲，首幀比RTMP更快

WebRTC協(xié)議

1、Google力推，已成為W3C標(biāo)準(zhǔn)

2、現(xiàn)代瀏覽器支持趨勢，X5也支持（微信、QQ）

3、基于UDP，低延遲，弱網(wǎng)抗性強(qiáng)，比flv.js更有優(yōu)勢

4、支持Web上行能力

5、編碼為H264+OPUS

6、提供NAT穿透技術(shù)（ICE）

實際情況下，當(dāng)用戶數(shù)量很大時，對推流設(shè)備的性能要求很高，復(fù)雜的權(quán)限管理也難以實現(xiàn)，采用P2P的架構(gòu)基本不可行。對于個別用戶提供上行流、海量用戶只進(jìn)行拉流的場景，騰訊課堂實現(xiàn)了一種P2S的解決方案。 進(jìn)一步學(xué)習(xí)可閱讀jaychen的系列文章《WebRTC直播技術(shù)》。

三、小程序+直播

技術(shù)方案

1. 基于RTMP，官方說底層使用HTTP/2的一種內(nèi)部傳輸機(jī)制，但又說是基于UDP的，這就搞不懂了。。。
2. live-pusher 和 live-player 沒有限制第三方云服務(wù)
3. 可直接使用騰訊云視頻直播能力，只需配置好推流url、播放url即可

下面是我根據(jù)官網(wǎng)教程搭建的一個音視頻小程序，搭建過程簡單，同一個局域網(wǎng)下直播體驗也很流暢（讀者也可直接搜索 騰訊視頻云 小程序進(jìn)行體驗）：

前端核心代碼還是相當(dāng)簡潔的：

• live-pusher組件：設(shè)置好url推流地址（僅支持 flv, rtmp 格式）等參數(shù)即可，使用bindstatechange獲取播放狀態(tài)變化

  復(fù)制代碼 <view id='video-box'> <live-pusher id="pusher" mode="RTC" url="{{pusher.push_url}}" autopush='true' bindstatechange="onPush"> </live-pusher> </view>

• live-player組件：設(shè)置后src音視頻地址（僅支持 flv, rtmp 格式）等參數(shù)即可，使用bindstatechange獲取播放狀態(tài)變化

  <view id='video-box'> <live-player wx:for="{{player}}" id="player_{{index}}" mode="RTC" object-fit="fillCrop" src="{{item.playUrl}}" autoplay='true' bindstatechange="onPlay"> </live-player> </view>

能否和WebRTC同時使用?

對于騰訊課堂的應(yīng)用場景，老師上課推流采用的是RTMP協(xié)議，考慮到WebRTC目前只能用于PC端拉流，那么在移動端能否讓用戶可以直接通過小程序來觀看直播課呢？我覺得在技術(shù)層面可行的，接入小程序直播對于擴(kuò)大平臺影響力、社交圈分享、提高收費轉(zhuǎn)化都會產(chǎn)生很大的幫助。難點在于復(fù)雜的權(quán)限控制、多路音視頻流、多人連麥等問題，比如權(quán)限控制只能單獨放到房間控制邏輯中完成，而音視頻流本身缺乏這種校驗；主輔路的切換還需要添加單獨的信令控制，同時在小程序中加入相應(yīng)的判斷邏輯。