這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助

使用須知

2017年下半年，微信6.5.21版本支持線上音視頻功能。開發者可以通過兩個音視頻組件 和 實現實時地線上直播、視頻通話、語音通話等功能。

上述功能需要用到兩個小程式媒體組件中的兩個： live-pusher 與 live-player 。下文簡單介紹兩這個組件的基礎知識。僅可以帶你入門，如果是高手請繞行。

註冊小程式

註冊小程式請單擊 微信公眾平臺 ，完成註冊後，在小程式管理頁面的【開發】>【基本配置】中記錄下小程式 AppID 供後面使用。

註意： 必須以非個人主體類型進行註冊，否則無法開通 和 這兩個標簽。

開通標簽使用許可權

live-pusher 和 live-player 是小程式內部用於支持音視頻上行能力的功能標簽

出於政策和合規的考慮，微信暫時沒有放開所有小程式對 live-pusher 和 live-player 標簽的支持：

• 目前支持這兩個標簽的類目如下表格所示（只有非個人主體才有以下類目）：

• 符合類目要求的小程式，需要在小程式管理後臺的【開發】>【介面設置】中自助開通推拉流標簽的使用許可權

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Vni239TU-1586502758626)(/Users/mxj/百度雲同步盤/學習筆記/前端全棧/微信小程式/img/image-20200409073506475.png)]

說明：如果以上設置都正確，但小程式依然不能正常工作，可能是微信內部的緩存沒更新，請刪除小程式並重啟微信後，再進行嘗試。

live-player

live-player是小程式內部用於支持音視頻下行（播放）能力的功能標簽。

版本支持

• 微信 App iOS 最低版本要求：6.5.21 。
• 微信 App Android 最低版本要求：6.5.19。
• 小程式基礎庫最低版本要求：1.7.0。

可以通過 wx.getSystemInfo 可以獲取當前基礎庫版本信息。

屬性定義

示例代碼

<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> 

超低時延

的 RTC 模式支持500ms以內的超低時延鏈路，可以應用在視頻通話和遠程遙控等場景中，要使用超低時延播放，需要註意如下幾點： （1）推流端如果是微信小程式，請使用 的 RTC 模式。 （2）推流端如果是 iOS 或者 Android SDK，請使用 setVideoQuality 的 MAIN_PUBLISHER 模式。 （3）推流端如果是 Windows，請不要使用 OBS，延時太高，可以使用我們的 Windows SDK。 （4） 的 min-cache 和 max-cache 請不要自行設置，使用預設值。 （5）播放地址請使用超低延時播放地址，也就是帶了防盜鏈簽名的rtmp://地址，如下：

屬性詳解

src 用於音視頻下行的播放 URL，支持 RTMP 協議（URL 以rtmp://打頭）和 FLV 協議（URL 以http://打頭且以.flv結尾）

說明：

標簽是不支持 HLS（m3u8）協議的，因為 已經支持 HLS（m3u8）播放協議了。但直播觀看不推薦使用 HLS（m3u8）協議，延遲要比 RTMP 和 FLV 協議高一個數量級。

mode live 模式主要用於直播類場景，例如賽事直播、線上教育、遠程培訓等等。該模式下，小程式內部的模塊會優先保證觀看體驗的流暢，通過調整 min-cache 和 max-cache 屬性，您可以調節觀眾（播放）端所感受到的時間延遲的大小，文檔下麵會詳細介紹這兩個參數。

RTC 則主要用於雙向視頻通話或多人視頻通話場景，例如金融開會、線上客服、車險定損、培訓會議等等。在此模式下，對 min-cache 和 max-cache 的設置不會起作用，因為小程式內部會自動將延遲控制在一個很低的水平（500ms左右）。

min-cache 和 max-cache

這兩個參數分別用於指定觀看端的最小緩衝時間和最大緩衝時間。所謂緩衝時間，是指播放器為了緩解網路波動對觀看流暢度的影響而引入的一個“蓄水池”，當來自網路的數據包出現卡頓甚至停滯的時候，“蓄水池”里的緊急用水可以讓播放器還能堅持一小段時間，只要在這個短暫的時間內網速恢復正常，播放器就可以源源不斷地渲染出流暢而平滑的視頻畫面。

“蓄水池”里的水越多，抗網路波動的能力就越強，但代價就是觀眾端的延遲就越大，所以要在不同的場景下，使用不同的配置來達到體驗上的平衡：

• 碼率比較低（1Mbps左右，畫面以人物為主）的直播流，min-cache = 1，max-cache = 3 較合適。
• 碼率比較高（2Mbps - 3Mbps的高清游戲畫面為主）的直播流，min-cache = 3，max-cache = 5 較合適。

RTC 模式下這兩個參數是無效的。

background-mute 微信切到後臺以後是否繼續播放聲音，用於避免鎖屏對於當前小程式正在播放的視頻內容的影響。

debug 調試音視頻相關功能，如果沒有很好的工具會是一個噩夢，所以小程式為 live-pusher 標簽支持了 debug 模式，開始 debug 模式之後，原本用於渲染視頻畫面的視窗上，會顯示一個半透明的 log 視窗，用於展示各項音視頻指標和事件，降低您調試相關功能的難度，具體使用方法我們在 FAQ 中有詳細說明。

對象操作

wx.createLivePlayerContext() 通過 wx.createLivePlayerContext() 可以將 標簽和 javascript 對象關聯起來，之後即可操作該對象。

play 開始播放，如果 的 autoplay 屬性設置為 false（預設值），那麼就可以使用 play 來手動啟動播放。

stop 停止播放。

pause 暫停播放，停留在最後畫面。

resume 繼續播放，與 pause 成對使用。

mute 設置靜音。

requestFullScreen 進入全屏幕。

exitFullScreen 退出全屏幕。

代碼實例

var player = wx.createLivePlayerContext('pusher');
player.requestFullScreen({
    success: function(){
            console.log('enter full screen mode success!')
        }
        fail: function(){
            console.log('enter full screen mode failed!')
        }
        complete: function(){
            console.log('enter full screen mode complete!')
        }
});

內部事件

通過live-player標簽的 bindstatechange 屬性可以綁定一個事件處理函數，該函數可以監聽推流模塊的內部事件和異常通知。

關鍵事件

更多詳細狀態碼請查看官方文檔

說明：

播放 HTTP:// 打頭的 FLV 協議地址時，如果觀眾遇到播放中直播流斷開的情況，小程式是不會拋出 PLAY_EVT_PLAY_END 事件的，這是因為 FLV 協議中沒有定義停止事件，所以只能通過監聽 PLAY_ERR_NET_DISCONNECT 來替代之。

警告事件

內部警告並非不可恢復的錯誤，小程式內部的音視頻 SDK 會啟動相應的恢復措施，警告的目的主要用於提示開發者或者最終用戶，例如：

代碼實例

Page({
    onPlay: function(ret) {
        if(ret.detail.code == 2004) {
                console.log('視頻播放開始',ret);
        }
    },

    /**
     * 生命周期函數--監聽頁面載入
     */
    onLoad: function (options) {
    //...
    }
})

網路狀態數據

小窗特性說明

live-player 小窗支持以下三種觸發模式（在組件上設置 picture-in-picture-mode 屬性）：

1. push 模式，即從當前頁跳轉至下一頁時出現小窗（頁面棧push）
2. pop 模式，即離開當頁面時觸發（頁面棧pop）
3. 以上兩種路由行為均觸發小窗

此外，小窗還支持以下特性：

• 小窗容器尺寸會根據原組件尺寸自動判斷
• 點擊小窗，用戶會被導航回小窗對應的播放器頁面
• 小窗出現後，用戶可點擊小窗右上角的關閉按鈕或調用 context.exitPictureInPicture() 介面關閉小窗

特別說明

1. 組件是由客戶端創建的原生組件，它的層級是最高的，不能通過z-index控制層級。可以使用 和 覆蓋在上面。

2. 請勿在 ，，， 中使用 組件。

3. live-player 預設寬度300px、高度225px，可通過wxss設置寬高。

4. 開發者工具上暫不支持。

5. css 動畫對 live-pusher 組件無效。

常見問題

開發和運行環境要求

• 微信 App iOS 最低版本要求：6.5.21。
• 微信 App Android 最低版本要求：6.5.19。
• 小程式基礎庫最低版本要求：1.7.0。
• 由於微信開發者工具不支持原生組件（即 和 標簽），需要在真機上進行運行體驗。

調試時為什麼要開啟調試模式？

開啟調試可以跳過把這些功能變數名稱加入小程式白名單的工作，否則可能會遇到登錄失敗，通話無法連接的問題。

live-pusher

屬性定義

示例代碼

<view id='video-box'>  
    <live-pusher
          id="pusher"
          mode="RTC"
          url="{{pusher.push_url}}" 
          autopush='true'
          bindstatechange="onPush">
    </live-pusher>  
 </view> 

屬性詳解

• url 用於音視頻上行的推流 URL，以rtmp://協議首碼打頭，騰訊雲推流 URL 的獲取方法見 快速獲取 URL 文檔。

  說明：

  小程式內部使用的 RTMP 協議是支持 UDP 加速的版本，在同樣網路條件下，UDP 版本的 RTMP 會比開源版本的有更好的上行速度和抗抖動能力。

• mode SD、HD 和 FHD 主要用於直播類場景，例如賽事直播、線上教育、遠程培訓等等。SD、HD 和 FHD 分別對應三種預設的清晰度。該模式下，小程式會更加註重清晰度和觀看的流暢性，不會過分強調低延遲，也不會為了延遲犧牲畫質和流暢性。

  RTC 則主要用於雙向視頻通話或多人視頻通話場景，例如金融開會、線上客服、車險定損、培訓會議等。該模式下，小程式會更加註重降低點到點的時延，也會優先保證聲音的質量，在必要的時候會對畫面清晰度和畫面的流暢性進行一定的縮水。

• orientation 和 aspect 橫屏（horizontal）模式還是豎屏（vertical）模式，預設是豎屏模式，即 home 鍵朝下。這時，小程式推出的畫面的寬高比是3：4或者9：16這兩種豎屏寬高比的畫面，也就是寬 < 高。如果改成橫屏模式，小程式推出的畫面寬高比即變為4：3或者16：9這種橫屏寬高比的畫面，也就是寬 > 高。

  具體的寬高比是有 aspect 決定的 ，預設是9：16， 也可以支持3：4。 這是在 orientation 的屬性值為 vertical 的情況下。如果 orientation 的屬性值為 horizontal，那麼3：4的效果等價於4：3，9：16的效果等價於16：9。

• min-bitrate 和 max-bitrate 這裡首先要科普一個概念 —— 視頻碼率，指視頻編碼器每秒鐘輸出的視頻數據的多少。在視頻解析度確定的情況下，視頻碼率越高，即每秒鐘輸出的數據越多，相應的畫質也就越好。

  所以 min-bitrate 和 max-bitrate 這兩個屬性，分別用於決定輸出畫面的最低清晰度和最高清晰度。這兩個數值並非越大越好，因為用戶的網路上行不是無限好的。但也不是越小越好，因為實際應用場景中，清晰與否是用戶衡量產品體驗的一個重要指標。具體的數值設定我們會在**“參數設置”**部分詳細介紹。

  小程式內部會自動處理好解析度和碼率的關係，例如2Mbps的碼率，小程式會選擇720p的解析度進行匹配，而300kbps的碼率下，小程式則會選擇較低的解析度來提高編碼效率。所以您只需要關註 min-bitrate 和 max-bitrate 這一對參數就可以掌控畫質了。

• waiting-image 和 waiting-image-hash 出於用戶隱私的考慮，在微信切到後臺以後，小程式希望停止攝像頭的畫面採集。但是對於另一端的用戶而言，畫面會變成黑屏或者凍屏（停留在最後一幀），這種體驗是非常差的。為瞭解決這個問題，我們引入了 waiting-image 屬性，您可以設置一張有 “稍候” 含義的圖片（waiting-image 是該圖片的 URL，waiting-image-hash 則是該圖片對應的 md5 校驗值）。當微信切到後臺以後，小程式會使用該圖片作為攝像頭畫面的替代，以極低的流量占用維持視頻流3分鐘時間。

• debug 調試音視頻相關功能，如果沒有很好的工具會是一個噩夢，所以小程式為 live-pusher 標簽支持了 debug 模式，開始 debug 模式之後，原本用於渲染視頻畫面的視窗上，會顯示一個半透明的 log 視窗，用於展示各項音視頻指標和事件，降低您調試相關功能的難度，具體使用方法我們在 FAQ 中有詳細說明。

參數設置

如果不是對帶寬特別沒有信心的應用場景，audio-quality 選項請不要選擇 low，其音質和延遲感都要會比 high 模式差很多。

對象操作

• wx.createLivePusherContext() 通過 wx.createLivePusherContext() 可以將 標簽和 javascript 對象關聯起來，之後即可操作該對象。
• start 開始推流，如果 的 autopush 屬性設置為 false（預設值），那麼就可以使用 start 來手動開始推流。
• stop 停止推流。
• pause 暫停推流。
• resume 恢復推流，請與 pause 操作配對使用。
• switchCamera 切換前後攝像頭。
• snapshot 推流截圖，截圖大小跟組件的大小一致。截圖成功圖片的臨時路徑為ret.tempImagePath。

代碼實例

var pusher = wx.createLivePusherContext('pusher');
pusher.start({
    success: function(ret){
            console.log('start push success!')
        }
        fail: function(){
            console.log('start push failed!')
        }
        complete: function(){
            console.log('start push complete!')
        }
});

內部事件

通過 標簽的 bindstatechange 屬性可以綁定一個事件處理函數，該函數可以監聽推流模塊的內部事件和異常通知。

常規事件

嚴重錯誤

警告事件

內部警告並非不可恢復的錯誤，小程式內部的音視頻 SDK 會啟動相應的恢復措施，警告的目的主要用於提示開發者或者最終用戶，例如：

• PUSH_WARNING_NET_BUSY 上行網速不給力，建議提示用戶改善當前的網路環境，例如讓用戶離家裡的路由器近一點，或者切到 Wi-Fi 環境下再使用。
• PUSH_WARNING_SERVER_DISCONNECT 請求被後臺拒絕了，出現這個問題一般是由於 URL 里的 txSecret 計算錯了，或者是 URL 被其他人占用了（跟播放不同，一個推流 URL 同時只能有一個用戶使用）。
• PUSH_WARNING_HANDUP_STOP 當用戶單擊小程式右上角的圓圈或者返回按鈕時，微信會將小程式掛起，此時 會拋出5000這個事件。

代碼實例

Page({
    onPush: function(ret) {
        if(ret.detail.code == 1002) {
                console.log('推流成功了',ret);
        }
    },

    /**
     * 生命周期函數--監聽頁面載入
     */
    onLoad: function (options) {
    //...
    }
})

本文轉載於：

https://juejin.cn/post/6986428160824836132

如果對您有所幫助，歡迎您點個關註，我會定時更新技術文檔，大家一起討論學習，一起進步。