微信小程序直播怎么開發，本篇教程帶你了解小程序直播開發中的秘密。
大家有沒有發現，小程序直播的方式在我們身邊的會議、客戶服務、約會中應用得越來越多……看到這些，不少開發者就着急了：怎樣才能開發出例如小程序直播、小程序在線語音客服、小程序視頻會議等等服務？
其實，這些玩得很6的小程序直播，都少不了它的支持——
2017年下半年，微信6.5.21版本支持在線音視頻功能。開發者可以通過兩個音視頻組件 <live-pusher>和 <live-player>實現實時地在線直播、視頻通話、語音通話等功能。
本期小程序課，微信開發哥將詳細為大家介紹一下音視頻組件在線直播和視頻通話這兩個應用場景。
在線直播該怎么做？
1、在線直播的應用場景有哪些？
在游戲直播、遠程授課、以及企業內部的培訓分享等場景中，都可能會用到在線直播功能，直播的應用場景可以遍及各行各業。
比如微信電競是一款游戲直播產品，以小程序為產品呈現方式。
比如在醫療行業，專家醫師往往需要全國各地飛進行學術交流和培訓，出差本身耽誤了醫生大量時間，在線遠程授課能大大減少這里的時間耗用。
小程序中的 <live-pusher> 和 <live-player> 兩個組件 ，都有一個叫做live ( <live-pusher> 中對應 mode 屬性為 SD, HD, FHD)的模式，專門為在線直播而設計，通過小程序的音視頻接口的live 模式，可以實現上述應用場景。
2、在線直播的內部原理是什么？
主播端使用 <live-pusher> ，它在微信小程序的內部是一個推流引擎，它負責對手機攝像頭和麥克風的數據進行采集和編碼，並通過 url 參數指定的 rtmp 推流地址上傳到雲端。
雲端的作用類似信號放大器，它負責將來自主播端的一路音視頻流數據進行放大，將數據實時並且無差異的負責並擴散到全國各地，從而解決主播和觀眾端之間距離太遠（比如，跨地區和跨運營商）的問題。
觀眾端使用 <live-player> 進行播放，它在小程序的內部是一個在線播放器，負責從雲端實時拉取音視頻數據並進行解碼和渲染。由於雲端的放大效應，每一個觀眾都能在離自己比較近的雲服務器上拉取到實時且流暢的音視頻流。
3、我怎么用小程序實現在線直播？
step1：開通一個雲直播服務（比如 騰訊雲 ），或者自己搭建一個rtmp服務器（例如 nginx-rtmp 服務）。
step2：生成推流 url ,推流地址一般以 “rtmp://” 打頭，比如 rtmp://8888.livepush.myqcloud.com/live/8888_test 就是一個典型 rtmp 推流 Url。
step3：為你的小程序增加一個 <live-pusher> 標簽，並將 url 參數指定為你在 step2 中生成的推流 url。
- 同時， <live-pusher> 的 mode 參數可以指定為 HD 或者 FHD，這是在線直播場景中比較推薦的畫質。
- 同時，你還可以通過 <live-pusher> 的 beauty 和 whiteness 等參數設定美顏和美白等級。
step4：生成推流 url 和播放地址，推流一般都是 rtmp:// 打頭的 url，而播放地址則有兩種選擇，分別是 “rtmp://” 開頭的 rtmp 播放協議，“http://” 打頭和“.flv”結尾的的 http-flv 播放協議，推薦使用后者，因為這種播放地址各個雲廠商都優化的比較好。
step5：為你的小程序增加一個 <live-player> 標簽 ，並將 src 參數指定為你在 step4 中生成的播放 url。同時， <live-player> 的 mode 參數請指定為 live， orientation 和 object-fit 屬性可以用於調整畫面布局， min-cache 和 max-cache 則可以用於控制觀眾跟主播之間的延時大小，推薦的設置是 min-cache = 2， max-cache = 5。
關於在線直播，你會有這樣的疑問
1、時延太高是怎么回事？
在線直播的延時跟播放協議和播放器參數有很大的關系， <live-player> 的 min-cache 和 max-cache 用於控制播放器端的最小時延和最大時延。其中，這里所說的“最小”和“最大”是根據觀眾端當時的網絡情況而定的，如果網絡情況比較好，那么播放器的時延就會趨向於 min-cache，而如果網絡情況比較差，那么播放器的時延就會趨向於 max-cache。
另外，rtmp 協議 和 http-flv 協議的播放地址延時一般比較低，而 hls(m3u8)協議的延時則相對較高。
2、主播網絡不好怎么辦？
在一場直播過程中，如果觀眾端的網絡不好，那么觀看體驗僅僅影響到當前觀眾；如果主播的網絡不好，那么所有觀眾的觀看體驗都會很糟糕。因此主播的上行網絡質量很重要，如果主播的上行網絡質量不理想，比如時好時壞，或者上行小水管，不足以支持基本的直播需求，有兩種辦法可以解決問題:
一種辦法是設置 <live-pusher> 的 min-bitrate 參數，比如 400kbps, 這樣一來，當主播網絡不給力的時候， <live-pusher> 就會給主播的編碼器發送降低畫質的命令，通過降低編碼器吐出的數據量來給主播的網絡減負。但這種辦法產生的副作用也非常明顯，就是主播的畫質會變差。
另一種方法則是借助 <live-pusher> 的 NET_BUSY 通知進行 UI 上的告警提示， <live-pusher> 在主播上行網速不給力時會通過 onPushEvent 通知拋出 PUSH_WARNING_NET_BUSY(1101) 事件，這個時候你可以提示主播通過靠近路由器或者切換 4G 的方法來改善當前的網絡質量。
3、HLS(m3u8)協議為什么播放不了？
微信小程序在最早期的版本中就集成了 <video> 標簽，該標簽即可播放 HLS（m3u8）協議的播放地址，但是此種播放協議的時延一般都在 20 秒以上，所以如果對時延要求較高，則推薦使用 <live-player> 標簽播放 http-flv 協議的直播地址。
視頻通話，你也能開發
1、小程序 + 視頻通話有什么優勢？
我們可以發現目前保險行業會通過現場定損的方式處理車險理賠，這種方式需要派定損員驅車前往事發地點進行損傷判定，每次的出車成本非常高。
如果要采用遠程電話解決，保險公司無法簡單通過語音溝通確認損傷程度，而且照片采集很難規避定車騙保的可能，所以**實時的視頻通話**可以解決這種問題。
小程序中 <live-pusher> 和 <live-player> 兩個組件 ，都有一個叫做 RTC 的模式，通過這種模式，可以在小程序實現實時視頻通話。
2、視頻通話的內部原理是什么？
<live-pusher> 和 <live-player> 兩個組件的 RTC 模式，主要是實現端到端能夠以很低的時延傳輸音視頻數據。
這樣一來，視頻通話的雙方 A 和 B 就可以各自拉通一路方向相反的音視頻鏈路，從而實現 A 和 B 之間的雙向低延時的音視頻數據傳輸。與此同時，RTC 模式還會開啟內置的 AEC (回聲抑制)，避免通話的雙方會因為本地麥克風對播放器的聲音進行二次采集而引起的回聲問題。
3、我怎么用小程序實現視頻通話？
step1：開通一個雲直播服務（比如 騰訊雲 ），或者自己搭建一個rtmp服務器（例如 nginx-rtmp 服務）。
step2：生成兩對 rtmp 推拉流 url ：一對是用於 A 端推流的 push_url_a 和 用於播放 A 端視頻的 play_url_a；另一對是用於 B 端推流的 push_url_b 和 用於播放 B 端視頻的 play_url_b；
step3：A端添加一個 <live-pusher> 標簽，指定 mode 為 RTC，並將 url 輸定設定為 push_url_a。
step4：A端添加一個 <live-player> 標簽，指定 mode 為 RTC，並將 src 輸定設定為 play_url_b。
step5：B端添加一個 <live-pusher> 標簽，指定 mode 為 RTC，並將 url 輸定設定為 push_url_b。
step6：B端添加一個 <live-player> 標簽，指定 mode 為 RTC，並將 src 輸定設定為 play_url_a。
關於視頻通話，你會有這樣的疑問
1、通話時延太高了怎么辦？
小程序的 RTC 模式解決了雙向或者多人實時音視頻通話在終端所需要的各項技術組件，但是通話線路本身可能也會引入很高的延時，所以要確保視頻通話的 A 和 B 雙方所使用的 rtmp 線路要有很低的時延。
如果是自己搭建rtmp服務器（例如 nginx-rtmp 服務），請檢查 nginx-rtmp 的服務端參數設置，確保不要在服務器端引入太多音視頻數據緩存。
如果是使用騰訊雲的超低延時線路，那么要注意給 RTC 模式下的 <live-player> 傳遞帶防盜鏈簽名的播放 url。
| 對比項目 | 示例 | 時延 |
| 普通直播URL | rtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc | >2s |
| 超低延時 URL | rtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc?bizid=bizid&txTime=5FD4431C&txSerect=20e6d865f462dff61ada209d53c71cf9 | < 500ms |
2、感覺畫面很卡應該如何處理？
小程序的 RTC 模式主要用於視頻通話，由於這類場景以交流為重，所以小程序會有限保證聲音的流暢，相應的，視頻數據的發送會被放在第二優先級上。因此，如果網絡有波動，小程序會舍棄尚未發送出去的視頻數據，優先保障音頻數據的發送。
所以如果在 RTC 模式下，建議不要給 <live-pusher> 設置太高的畫質，也就是不要將 min-bitrate 和 max-bitrate 設置的太大，一般而言，推薦 min-bitrate 設置為 300kbps， max-bitrate 設置為 800kbps，即可滿足常規視頻通話的需求。