【腾讯Bugly干货分享】H5 视频直播那些事
為什么80%的碼農都做不了架構師？>>> ??
本文來自于騰訊bugly開發者社區，非經作者同意，請勿轉載，原文地址：http://dev.qq.com/topic/57a42ee6503dfcb22007ede8
Dev Club 是一個交流移動開發技術，結交朋友，擴展人脈的社群，成員都是經過審核的移動開發工程師。每周都會舉行嘉賓分享，話題討論等活動。
本期，我們邀請了騰訊SNG Web前端開發工程師——呂鳴，為大家分享**《H5 視頻直播那些事》**。
如何加入 Dev Club？
移動端開發經驗 >= 2 年，微信掃描下方群管理微信二維碼，備注姓名-公司(或產品) 申請加入。
分享內容簡介： 目前視頻直播，尤其是移動端的視頻直播已經火到不行了，基本上各大互聯網公司都有了自己的直播產品，所以對于直播的一些基本知識和主要技術點也要有所了解，本次分享就向大家介紹一下其中的奧秘。
內容大體框架:
分享人介紹：
呂鳴 目前在騰訊SNG擔任手Q的web前端開發工作 博客：http://www.nihaoshijie.com.cn/
下面是本期分享內容整理
Hello, 大家好，我是呂鳴，目前是在騰訊 SNG 的即通應用部負責手Q的興趣部落 Web 前端開發工作。
針對目前比較火的視頻直播，我做了一些研究和探索，同時我們的項目將會用到直播為此打下技術基礎，下面就向大家分享一下直播的整個流程和一些技術點。
一、移動視頻直播發展
大家首先來看下面這張圖:
可以看到，直播從 PC 到一直發展到移動端，越來越多的直播類 App 上線，同時移動直播進入了前所未有的爆發階段，但是對于大多數移動直播來說，還是要以 Native 客戶端實現為主，但是 H5 在移動直播端也承載著不可替代的作用，例如 H5 有著傳播快，易發布的優勢，同時最為關鍵的時 H5 同樣可以播放直播視頻。
大家可以看下面這張大概的實現圖
完整的直播可以分為以下幾塊：
大家可以看下大致的結構圖：
二、H5 錄制視頻：
對于H5視頻錄制，可以使用強大的 webRTC （Web Real-Time Communication）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，缺點是只在 PC 的 Chrome 上支持較好，移動端支持不太理想。
使用 webRTC 錄制視頻基本流程是：
由于許多方法都要加上瀏覽器前綴，所以很多移動端的瀏覽器還不支持 webRTC，所以真正的視頻錄制還是要靠客戶端（iOS,Android）來實現,效果會好一些。
三、H5 播放直播視頻：
對于視頻播放，可以使用 HLS(HTTP Live Streaming)協議播放直播流，iOS和 Android 都天然支持這種協議，配置簡單，直接使用 video 標簽即可。
下面是簡單的代碼使用 video 播放直播視頻：
1.什么是 HLS 協議:
簡單講就是把整個流分成一個個小的，基于 HTTP 的文件來下載，每次只下載一些，前面提到了用于 H5 播放直播視頻時引入的一個 .m3u8 的文件，這個文件就是基于 HLS 協議，存放視頻流元數據的文件。
每一個 .m3u8 文件，分別對應若干個 ts 文件，這些 ts 文件才是真正存放視頻的數據，m3u8 文件只是存放了一些 ts 文件的配置信息和相關路徑，當視頻播放時，.m3u8 是動態改變的，video 標簽會解析這個文件，并找到對應的 ts 文件來播放，所以一般為了加快速度，.m3u8 放在 Web 服務器上，ts 文件放在 CDN 上。
.m3u8 文件，其實就是以 UTF-8 編碼的 m3u 文件，這個文件本身不能播放，只是存放了播放信息的文本文件。
打開之后就是這個樣子：
下面這個是 ts 文件，就是存放視頻的文件：
2.HLS 的請求流程：
大概是這個流程：
3.HLS 直播延時:
我們知道 hls 協議是將直播流分成一段一段的小段視頻去下載播放的，所以假設列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內容，那么整體的延遲就是25秒。因為當你看到這些視頻時，主播已經將視頻錄制好上傳上去了，所以時這樣產生的延遲。當然可以縮短列表的長度和單個 ts 文件的大小來降低延遲，極致來說可以縮減列表長度為1，并且 ts 的時長為1s，但是這樣會造成請求次數增加，增大服務器壓力，當網速慢時回造成更多的緩沖，所以蘋果官方推薦的 ts 時長時10s，所以這樣就會大改有30s的延遲。所以服務器接收流，轉碼，保存，切塊，再分發給客戶端，這里就延時的根本原因。
更多關于延遲的問題可以參考蘋果官方地址： https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
但是 H5 直播視頻卻有一些不可替代的優勢:
四、iOS 采集（錄制）音視頻數據OS
關于音視頻采集錄制，首先明確下面幾個概念：
- 視頻編碼：所謂視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式文件的方式，我們使用的 iPhone 錄制的視頻，必須要經過編碼，上傳，解碼，才能真正的在用戶端的播放器里播放。
- 編解碼標準：視頻流傳輸中最為重要的編解碼標準有國際電聯的 H.261、H.263、H.264，其中 HLS 協議支持 H.264 格式的編碼。
- 音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標準進行編碼，上傳，解碼，同時在播放器里播放，當然音頻也有許多編碼標準，例如 PCM 編碼，WMA 編碼，AAC 編碼等等，這里我們 HLS 協議支持的音頻編碼方式是 AAC 編碼。
利用 iOS 上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：
下面是具體的采集音視頻數據的流程：
1.關于 RTMP：
Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視頻直播協議，現在屬于 Adobe。和 HLS 一樣都可以應用于視頻直播，區別是 RTMP 基于 flash 無法在 iOS 的瀏覽器里播放，但是實時性比 HLS 要好。所以一般使用這種協議來上傳視頻流，也就是視頻流推送到服務器。
下面是 HLS 和 RTMP 的對比：
2.推流
所謂推流，就是將我們已經編碼好的音視頻數據發往視頻流服務器中，在 iOS 代碼里面一般常用的是使用 RTMP 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 API 供使用者調用。例如推流 API 等等，配置服務器地址，即可將轉碼后的視頻流推往服務器。
那么如何搭建一個推流服務器呢？
簡單的推流服務器搭建，由于我們上傳的視頻流都是基于 RTMP 協議的，所以服務器也必須要支持 RTMP 才行，大概需要以下幾個步驟：
更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/
下面是 nginx 的配置文件
五、直播中的用戶交互：
對于直播中的用戶交互大致可以分為：
對于送禮物，在 H5 端可以利用 DOM 和 CSS3 實現送禮物邏輯和一些特殊的禮物動畫，實現技術難點不大。
對于彈幕來說，要稍微復雜一些，可能需要關注以下幾點：
六、總結
目前較為成熟的直播產品，大致都是以 Server 端和 H5 和 Native(android,ios)搭配實現直播：
基本是下圖這個套路：
所以 H5 在整個直播中，還是有著重要的地位的！
Demo 分享
最后，根據本次分享的內容，我這邊實現了一個 iOS 端錄制，推流，NGINX 接收流，同時分發的 HLS 直播流的一整套 Demo，感興趣的同學可以看下面這個鏈接:
https://github.com/lvming6816077/LMVideoTest
好了，本次分享先到這里了，謝謝大家~
互動問答環節
Q1: Demo 包含 iOS 端的 RTMP 播放不？
答：Demo 里面沒有 RTMP 的播放，Demo 主要是提供錄制，推流的。
Q2: 對于 H5 HLS 播放 卡頓問題，前端與 server 端，有什么配置上的優化嗎？
答：server 端要做好分片策略，同時要將 ts 文件放在 CDN 上，前端這邊可以盡量做到 DNS 緩存等，由于H5是使用的 video 標簽，所以要修改 video 的播放優化，還是不那么容易。
Q3: 在手機推流時的碼率是根據怎樣的策略做選擇的？不同機型和網絡下如何保持流暢？
答：可以提供不同的視頻碼率來供用戶選擇，例如網速差的可以選擇較為低清晰度的碼率，網絡好的用戶可以選擇更加清晰的碼率，同時做好視頻播放端的容錯和異常處理等等。
Q4: RTMP 比起 HTTP 他的優勢主要是幾種在哪里？
答：RTMP 是基于 TCP 的保持的是長連接，而 HTTP 是一次性的，每次都要三次握手，所以對于直播來說還是 RTMP 好一些
Q5: 據我所知 nginx rtmp-module 好像性能不是很高.....為什么會采用這個來作為后端服務？
答：這里只是 Demo 用了這個 nginx rtmp-module，其實也可已選擇 SRS(simple-rtmp-server)都是可以的哈
Q6: 移動端這邊怎么進行編碼轉碼？用 ffmpeg 編譯時很麻煩
答：關于 iOS 這邊，其實不用關心轉碼問題，因為已經有了很多開源的庫提供給我們了例如： x264 編碼：https://github.com/kewlbear/x264-ios faac 編碼：https://github.com/fflydev/faac-ios-build
Q7: 您介紹的都是 Native 播放和還有 H5 的 video 標簽播放, iOS 端有沒有考慮過整個用原生的 OC 或者 Swift 實現?
答：關于播放端，其實真正體驗好的還是要用 native 來實現的，而且 native 實現可以用 RTMP 來播放直播，延遲會好很多，H5 來播直播主要是考慮到易傳播性好。
Q8: 在用戶非常多的情況下，或者網絡慢的情況下，有什么策略可以保證質量？
答：可以提供不同的視頻碼率來供用戶選擇，例如網速差的可以選擇較為低清晰度的碼率，網絡好的用戶可以選擇更加清晰的碼率，同時做好視頻播放端的容錯和異常處理等等。
Q9: 請問直播這塊的測試中關注的幾個指標是什么，有什么比較好的測試方法呢？
答：主要就是：
Q10: 您提供的 Demo 為什么不是 H5 的呢 iOS 推流和 nginx 服務器都有，能不能提供一個前面第二張葉子美女直播那個頁面的 Demo？
答：這個 Demo 你下載下拉運行的話，根據配置就可直接自己實現一個利用 H5 直播的頁面，很簡單，就像使用 video 標簽一樣，其他的樣式你可以自己定制的。
Q11: HLS 的延時有沒有比較好的方法解決？
答：HLS 確實是會有延遲，相對比較優的策略是調整好分片策略，在保證性能的情況下，和延遲達到平衡。
Q12: 如果加入視頻電話功能，上面的結構需要作什么改變？視頻電話的目的大概是：直播可以選擇某一觀眾或者多個觀眾視頻對話
答：視頻電話，也就是說作為視頻錄制端的同時也作為視頻播放端，所以實現實時電話簡單就是：我在直播的同時觀看別人的直播視頻，別人在直播的同時觀看我的直播視頻，可以這樣理解，上面的結構復制一份對調即可。
Q13: 如何實現濾鏡功能？
答：一般是在視頻錄制之后，在轉碼前給視頻數據增加濾鏡功能，在 iOS 里可以使用一些濾鏡庫等等實現濾鏡功能
Q14: 在 App 端如果不利用 H5 能實現直播嗎？
答：可以啊，app 有更加豐富的播放接口，和開源播放器可以實現直播的。
Q15: 既然 HLS 有較高的延遲 為什么蘋果推薦的的方式卻是 HLS？
答：并不是說蘋果主要推薦使用 HLS，對于 H5 來說目前只有這一種比較好的方式來播放直播視頻，所以還是很期待蘋果能對延遲問題做一些改進的。
Q16: 同濾鏡問題，音頻變聲是如何實現的？
答：同樣是可以在對音頻轉碼前操作。
Q17: 如果針對網絡較差的觀看用戶，是需要直播推流到服務器后做多份不同分辨率的拷貝，以適應不同網絡的用戶觀看？如果是這樣的話，對延遲會不會影響很大？ 畢竟編解碼也是需要時間的.
答：這個其實本身就應該做的，對于網絡差的用戶，完全可以提供給他們較低碼率的直播流來減少卡頓問題，延遲問題的話還是要根據具體使用哪種協議來定。
Q18: 推流目前大部分都是第三方在做，難度點在哪？然后目前業內比較成熟的主要哪些？
答：難點主要是服務器端的性能壓力和分發直播流的效率，業界都已經有了較成熟的方案，例如騰訊云的直播。
點此查看 Dev Club 往期分享匯總
更多精彩內容歡迎關注bugly的微信公眾賬號：
騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合并功能幫助開發同學把每天上報的數千條 Crash 根據根因合并分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布后快速的了解應用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！
轉載于:https://my.oschina.net/bugly/blog/731823
總結
以上是生活随笔為你收集整理的【腾讯Bugly干货分享】H5 视频直播那些事的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Servlet开发(二)
- 下一篇： 常用的系统储存过程