文章來(lái)源：http://geek.csdn.net/news/detail/95188
分享內(nèi)容簡(jiǎn)介：
目前視頻直播，尤其是移動(dòng)端的視頻直播已經(jīng)火到不行了，基本上各大互聯(lián)網(wǎng)公司都有了自己的直播產(chǎn)品，所以對(duì)于直播的一些基本知識(shí)和主要技術(shù)點(diǎn)也要有所了解，本次分享就向大家介紹一下其中的奧秘。
內(nèi)容大體框架:
1. 怎樣利用 HTML5 來(lái)播放直播視頻
2. 怎樣錄制直播視頻
3. 怎樣實(shí)時(shí)上傳直播視頻
4. 直播中的用戶交互
分享人介紹：
呂鳴 目前在騰訊SNG擔(dān)任手Q的web前端開發(fā)工作
博客：http://www.nihaoshijie.com.cn/
下面是本期分享內(nèi)容整理
Hello, 大家好，我是呂鳴，目前是在騰訊 SNG 的即通應(yīng)用部負(fù)責(zé)手Q的興趣部落 Web 前端開發(fā)工作。
針對(duì)目前比較火的視頻直播，我做了一些研究和探索，同時(shí)我們的項(xiàng)目將會(huì)用到直播為此打下技術(shù)基礎(chǔ)，下面就向大家分享一下直播的整個(gè)流程和一些技術(shù)點(diǎn)。
大家首先來(lái)看下面這張圖:
可以看到，直播從 PC 到一直發(fā)展到移動(dòng)端，越來(lái)越多的直播類 App 上線，同時(shí)移動(dòng)直播進(jìn)入了前所未有的爆發(fā)階段，但是對(duì)于大多數(shù)移動(dòng)直播來(lái)說(shuō)，還是要以 Native 客戶端實(shí)現(xiàn)為主，但是 html5 在移動(dòng)直播端也承載著不可替代的作用，例如 Html5 有著傳播快，易發(fā)布的優(yōu)勢(shì)，同時(shí)最為關(guān)鍵的時(shí) HTML5 同樣可以播放直播視頻。
大家可以看下面這張大概的實(shí)現(xiàn)圖
完整的直播可以分為以下幾塊：
video 標(biāo)簽等，目前還是已手機(jī)端的 Native 播放器為主。大家可以看下大致的結(jié)構(gòu)圖：
對(duì)于HTML5視頻錄制，可以使用強(qiáng)大的 webRTC （Web Real-Time Communication）是一個(gè)支持網(wǎng)頁(yè)瀏覽器進(jìn)行實(shí)時(shí)語(yǔ)音對(duì)話或視頻對(duì)話的技術(shù)，缺點(diǎn)是只在 PC 的 Chrome 上支持較好，移動(dòng)端支持不太理想。
使用 webRTC 錄制視頻基本流程是：
window.navigator.webkitGetUserMedia() 獲取用戶的PC攝像頭視頻數(shù)據(jù)。window.webkitRTCPeerConnection (一種視頻流數(shù)據(jù)格式)。由于許多方法都要加上瀏覽器前綴，所以很多移動(dòng)端的瀏覽器還不支持 webRTC，所以真正的視頻錄制還是要靠客戶端（iOS,Android）來(lái)實(shí)現(xiàn),效果會(huì)好一些。
對(duì)于視頻播放，可以使用 HLS(HTTP Live Streaming)協(xié)議播放直播流，ios和 android 都天然支持這種協(xié)議，配置簡(jiǎn)單，直接使用 video 標(biāo)簽即可。
下面是簡(jiǎn)單的代碼使用 video 播放直播視頻：
簡(jiǎn)單講就是把整個(gè)流分成一個(gè)個(gè)小的，基于 HTTP 的文件來(lái)下載，每次只下載一些，前面提到了用于 HTML5 播放直播視頻時(shí)引入的一個(gè) .m3u8 的文件，這個(gè)文件就是基于 HLS 協(xié)議，存放視頻流元數(shù)據(jù)的文件。
每一個(gè) .m3u8 文件，分別對(duì)應(yīng)若干個(gè) ts 文件，這些 ts 文件才是真正存放視頻的數(shù)據(jù)，m3u8 文件只是存放了一些 ts 文件的配置信息和相關(guān)路徑，當(dāng)視頻播放時(shí)，.m3u8 是動(dòng)態(tài)改變的，video 標(biāo)簽會(huì)解析這個(gè)文件，并找到對(duì)應(yīng)的 ts 文件來(lái)播放，所以一般為了加快速度，.m3u8 放在 Web 服務(wù)器上，ts 文件放在 CDN 上。
.m3u8 文件，其實(shí)就是以 UTF-8 編碼的 m3u 文件，這個(gè)文件本身不能播放，只是存放了播放信息的文本文件。
打開之后就是這個(gè)樣子：
下面這個(gè)是 ts 文件，就是存放視頻的文件：
大概是這個(gè)流程：
我們知道 hls 協(xié)議是將直播流分成一段一段的小段視頻去下載播放的，所以假設(shè)列表里面的包含5個(gè) ts 文件，每個(gè) TS 文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。因?yàn)楫?dāng)你看到這些視頻時(shí)，主播已經(jīng)將視頻錄制好上傳上去了，所以時(shí)這樣產(chǎn)生的延遲。當(dāng)然可以縮短列表的長(zhǎng)度和單個(gè) ts 文件的大小來(lái)降低延遲，極致來(lái)說(shuō)可以縮減列表長(zhǎng)度為1，并且 ts 的時(shí)長(zhǎng)為1s，但是這樣會(huì)造成請(qǐng)求次數(shù)增加，增大服務(wù)器壓力，當(dāng)網(wǎng)速慢時(shí)回造成更多的緩沖，所以蘋果官方推薦的 ts 時(shí)長(zhǎng)時(shí)10s，所以這樣就會(huì)大改有30s的延遲。所以服務(wù)器接收流，轉(zhuǎn)碼，保存，切塊，再分發(fā)給客戶端，這里就延時(shí)的根本原因。
更多關(guān)于延遲的問(wèn)題可以參考蘋果官方地址：
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
但是 HTML5 直播視頻卻有一些不可替代的優(yōu)勢(shì):
關(guān)于音視頻采集錄制，首先明確下面幾個(gè)概念：
利用 iOS 上的攝像頭，進(jìn)行音視頻的數(shù)據(jù)采集，主要分為以下幾個(gè)步驟：
下面是具體的采集音視頻數(shù)據(jù)的流程：
Real Time Messaging Protocol（簡(jiǎn)稱 RTMP）是 Macromedia 開發(fā)的一套視頻直播協(xié)議，現(xiàn)在屬于 Adobe。和 HLS 一樣都可以應(yīng)用于視頻直播，區(qū)別是 RTMP 基于 flash 無(wú)法在 iOS 的瀏覽器里播放，但是實(shí)時(shí)性比 HLS 要好。所以一般使用這種協(xié)議來(lái)上傳視頻流，也就是視頻流推送到服務(wù)器。
下面是 HLS 和 RTMP 的對(duì)比：
所謂推流，就是將我們已經(jīng)編碼好的音視頻數(shù)據(jù)發(fā)往視頻流服務(wù)器中，在 iOS 代碼里面一般常用的是使用 RTMP 推流，可以使用第三方庫(kù) librtmp-iOS 進(jìn)行推流，librtmp 封裝了一些核心的 API 供使用者調(diào)用。例如推流 API 等等，配置服務(wù)器地址，即可將轉(zhuǎn)碼后的視頻流推往服務(wù)器。
那么如何搭建一個(gè)推流服務(wù)器呢？
簡(jiǎn)單的推流服務(wù)器搭建，由于我們上傳的視頻流都是基于 RTMP 協(xié)議的，所以服務(wù)器也必須要支持 RTMP 才行，大概需要以下幾個(gè)步驟：
更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/
下面是 nginx 的配置文件
對(duì)于直播中的用戶交互大致可以分為：
對(duì)于送禮物，在 HTML5 端可以利用 DOM 和 CSS3 實(shí)現(xiàn)送禮物邏輯和一些特殊的禮物動(dòng)畫，實(shí)現(xiàn)技術(shù)難點(diǎn)不大。
對(duì)于彈幕來(lái)說(shuō)，要稍微復(fù)雜一些，可能需要關(guān)注以下幾點(diǎn)：
目前較為成熟的直播產(chǎn)品，大致都是以 Server 端和 HTML5 和 Native(android,ios)搭配實(shí)現(xiàn)直播：
基本是下圖這個(gè)套路：
所以 HTML5 在整個(gè)直播中，還是有著重要的地位的！
最后，根據(jù)本次分享的內(nèi)容，我這邊實(shí)現(xiàn)了一個(gè) iOS 端錄制，推流，NGINX 接收流，同時(shí)分發(fā)的 HLS 直播流的一整套 Demo，感興趣的同學(xué)可以看下面這個(gè)鏈接:
https://github.com/lvming6816077/LMVideoTest
好了，本次分享先到這里了，謝謝大家~
Q1: Demo 包含 iOS 端的 RTMP 播放不？
答：Demo 里面沒(méi)有 RTMP 的播放，Demo 主要是提供錄制，推流的。
Q2: 對(duì)于 HTML5 HLS 播放 卡頓問(wèn)題，前端與 server 端，有什么配置上的優(yōu)化嗎？
答：server 端要做好分片策略，同時(shí)要將 ts 文件放在 CDN 上，前端這邊可以盡量做到 DNS 緩存等，由于HTML5是使用的 video 標(biāo)簽，所以要修改 video 的播放優(yōu)化，還是不那么容易。
Q3: 在手機(jī)推流時(shí)的碼率是根據(jù)怎樣的策略做選擇的？不同機(jī)型和網(wǎng)絡(luò)下如何保持流暢？
答：可以提供不同的視頻碼率來(lái)供用戶選擇，例如網(wǎng)速差的可以選擇較為低清晰度的碼率，網(wǎng)絡(luò)好的用戶可以選擇更加清晰的碼率，同時(shí)做好視頻播放端的容錯(cuò)和異常處理等等。
Q4: RTMP 比起 HTTP 他的優(yōu)勢(shì)主要是幾種在哪里？
答：RTMP 是基于 TCP 的保持的是長(zhǎng)連接，而 HTTP 是一次性的，每次都要三次握手，所以對(duì)于直播來(lái)說(shuō)還是 RTMP 好一些
Q5: 據(jù)我所知 nginx rtmp-module 好像性能不是很高…..為什么會(huì)采用這個(gè)來(lái)作為后端服務(wù)？
答：這里只是 Demo 用了這個(gè) nginx rtmp-module，其實(shí)也可已選擇 SRS(simple-rtmp-server)都是可以的哈
Q6: 移動(dòng)端這邊怎么進(jìn)行編碼轉(zhuǎn)碼？用 ffmpeg 編譯時(shí)很麻煩
答：關(guān)于 iOS 這邊，其實(shí)不用關(guān)心轉(zhuǎn)碼問(wèn)題，因?yàn)橐呀?jīng)有了很多開源的庫(kù)提供給我們了例如：
x264 編碼：https://github.com/kewlbear/x264-ios
faac 編碼：https://github.com/fflydev/faac-ios-build
Q7: 您介紹的都是 Native 播放和還有 HTML5 的 video 標(biāo)簽播放, iOS 端有沒(méi)有考慮過(guò)整個(gè)用原生的 OC 或者 Swift 實(shí)現(xiàn)?
答：關(guān)于播放端，其實(shí)真正體驗(yàn)好的還是要用 native 來(lái)實(shí)現(xiàn)的，而且 native 實(shí)現(xiàn)可以用 RTMP 來(lái)播放直播，延遲會(huì)好很多，HTML5 來(lái)播直播主要是考慮到易傳播性好。
Q8: 在用戶非常多的情況下，或者網(wǎng)絡(luò)慢的情況下，有什么策略可以保證質(zhì)量？
答：可以提供不同的視頻碼率來(lái)供用戶選擇，例如網(wǎng)速差的可以選擇較為低清晰度的碼率，網(wǎng)絡(luò)好的用戶可以選擇更加清晰的碼率，同時(shí)做好視頻播放端的容錯(cuò)和異常處理等等。
Q9: 請(qǐng)問(wèn)直播這塊的測(cè)試中關(guān)注的幾個(gè)指標(biāo)是什么，有什么比較好的測(cè)試方法呢？
答：主要就是：
1. 首次打開的白屏?xí)r間
2. 直播中的卡頓和緩沖
3. 直播的延時(shí)
Q10: 您提供的 Demo 為什么不是 HTML5 的呢 iOS 推流和 nginx 服務(wù)器都有，能不能提供一個(gè)前面第二張葉子美女直播那個(gè)頁(yè)面的 Demo？
答：這個(gè) Demo 你下載下拉運(yùn)行的話，根據(jù)配置就可直接自己實(shí)現(xiàn)一個(gè)利用 HTML5 直播的頁(yè)面，很簡(jiǎn)單，就像使用 video 標(biāo)簽一樣，其他的樣式你可以自己定制的。
Q11: HLS 的延時(shí)有沒(méi)有比較好的方法解決？
答：HLS 確實(shí)是會(huì)有延遲，相對(duì)比較優(yōu)的策略是調(diào)整好分片策略，在保證性能的情況下，和延遲達(dá)到平衡。
Q12: 如果加入視頻電話功能，上面的結(jié)構(gòu)需要作什么改變？視頻電話的目的大概是：直播可以選擇某一觀眾或者多個(gè)觀眾視頻對(duì)話
答：視頻電話，也就是說(shuō)作為視頻錄制端的同時(shí)也作為視頻播放端，所以實(shí)現(xiàn)實(shí)時(shí)電話簡(jiǎn)單就是：我在直播的同時(shí)觀看別人的直播視頻，別人在直播的同時(shí)觀看我的直播視頻，可以這樣理解，上面的結(jié)構(gòu)復(fù)制一份對(duì)調(diào)即可。
Q13: 如何實(shí)現(xiàn)濾鏡功能？
答：一般是在視頻錄制之后，在轉(zhuǎn)碼前給視頻數(shù)據(jù)增加濾鏡功能，在 iOS 里可以使用一些濾鏡庫(kù)等等實(shí)現(xiàn)濾鏡功能
Q14: 在 App 端如果不利用 HTML5 能實(shí)現(xiàn)直播嗎？
答：可以啊，app 有更加豐富的播放接口，和開源播放器可以實(shí)現(xiàn)直播的。
Q15: 既然 HLS 有較高的延遲 為什么蘋果推薦的的方式卻是 HLS？
答：并不是說(shuō)蘋果主要推薦使用 HLS，對(duì)于 HTML5 來(lái)說(shuō)目前只有這一種比較好的方式來(lái)播放直播視頻，所以還是很期待蘋果能對(duì)延遲問(wèn)題做一些改進(jìn)的。
Q16: 同濾鏡問(wèn)題，音頻變聲是如何實(shí)現(xiàn)的？
答：同樣是可以在對(duì)音頻轉(zhuǎn)碼前操作。
Q17: 如果針對(duì)網(wǎng)絡(luò)較差的觀看用戶，是需要直播推流到服務(wù)器后做多份不同分辨率的拷貝，以適應(yīng)不同網(wǎng)絡(luò)的用戶觀看？如果是這樣的話，對(duì)延遲會(huì)不會(huì)影響很大？ 畢竟編解碼也是需要時(shí)間的.
答：這個(gè)其實(shí)本身就應(yīng)該做的，對(duì)于網(wǎng)絡(luò)差的用戶，完全可以提供給他們較低碼率的直播流來(lái)減少卡頓問(wèn)題，延遲問(wèn)題的話還是要根據(jù)具體使用哪種協(xié)議來(lái)定。
Q18: 推流目前大部分都是第三方在做，難度點(diǎn)在哪？然后目前業(yè)內(nèi)比較成熟的主要哪些？
答：難點(diǎn)主要是服務(wù)器端的性能壓力和分發(fā)直播流的效率，業(yè)界都已經(jīng)有了較成熟的方案，例如騰訊云的直播。
騰訊 Bugly是一款專為移動(dòng)開發(fā)者打造的質(zhì)量監(jiān)控工具，幫助開發(fā)者快速，便捷的定位線上應(yīng)用崩潰的情況以及解決方案。智能合并功能幫助開發(fā)同學(xué)把每天上報(bào)的數(shù)千條Crash 根據(jù)根因合并分類，每日日?qǐng)?bào)會(huì)列出影響用戶數(shù)最多的崩潰，精準(zhǔn)定位功能幫助開發(fā)同學(xué)定位到出問(wèn)題的代碼行，實(shí)時(shí)上報(bào)可以在發(fā)布后快速的了解應(yīng)用的質(zhì)量情況，適配最新的 iOS、Android 官方操作系統(tǒng)。
下面是H5相關(guān)掃盲方面的知識(shí)：
文章來(lái)源：https://www.nihaoshijie.com.cn/index.php/archives/615
視頻直播這么火，再不學(xué)就out了。
為了緊跟潮流，本文將向大家介紹一下視頻直播中的基本流程和主要的技術(shù)點(diǎn)，包括但不限于前端技術(shù)。
當(dāng)然可以， H5火了這么久，涵蓋了各個(gè)方面的技術(shù)。
對(duì)于視頻錄制，可以使用強(qiáng)大的webRTC（Web Real-Time Communication）是一個(gè)支持網(wǎng)頁(yè)瀏覽器進(jìn)行實(shí)時(shí)語(yǔ)音對(duì)話或視頻對(duì)話的技術(shù)，缺點(diǎn)是只在PC的chrome上支持較好，移動(dòng)端支持不太理想。
對(duì)于視頻播放，可以使用HLS(HTTP Live Streaming)協(xié)議播放直播流，ios和android都天然支持這種協(xié)議，配置簡(jiǎn)單，直接使用video標(biāo)簽即可。
webRTC兼容性：
video標(biāo)簽播放hls協(xié)議視頻：
<video controls autoplay> <source src="http://10.66.69.77:8080/hls/mystream.m3u8" type="application/vnd.apple.mpegurl" /> <p class="warning">Your browser does not support HTML5 video.</p> </video>
當(dāng)簡(jiǎn)單講就是把整個(gè)流分成一個(gè)個(gè)小的基于HTTP的文件來(lái)下載，每次只下載一些，前面提到了用于H5播放直播視頻時(shí)引入的一個(gè).m3u8的文件，這個(gè)文件就是基于HLS協(xié)議，存放視頻流元數(shù)據(jù)的文件。
每一個(gè).m3u8文件，分別對(duì)應(yīng)若干個(gè)ts文件，這些ts文件才是真正存放視頻的數(shù)據(jù)，m3u8文件只是存放了一些ts文件的配置信息和相關(guān)路徑，當(dāng)視頻播放時(shí)，.m3u8是動(dòng)態(tài)改變的，video標(biāo)簽會(huì)解析這個(gè)文件，并找到對(duì)應(yīng)的ts文件來(lái)播放，所以一般為了加快速度，.m3u8放在web服務(wù)器上，ts文件放在cdn上。
.m3u8文件，其實(shí)就是以UTF-8編碼的m3u文件，這個(gè)文件本身不能播放，只是存放了播放信息的文本文件：
?#EXTM3U m3u文件頭#EXT-X-MEDIA-SEQUENCE 第一個(gè)TS分片的序列號(hào)#EXT-X-TARGETDURATION 每個(gè)分片TS的最大的時(shí)長(zhǎng)#EXT-X-ALLOW-CACHE 是否允許cache#EXT-X-ENDLIST m3u8文件結(jié)束符#EXTINF 指定每個(gè)媒體段(ts)的持續(xù)時(shí)間（秒），僅對(duì)其后面的URI有效mystream-12.ts
ts文件：
HLS的請(qǐng)求流程是：
1 http請(qǐng)求m3u8的url
2 服務(wù)端返回一個(gè)m3u8的播放列表，這個(gè)播放列表是實(shí)時(shí)跟新的，一般一次給出3段數(shù)據(jù)的url
3 客戶端解析m3u8的播放列表，再按序請(qǐng)求每一段的url，獲取ts數(shù)據(jù)流
簡(jiǎn)單流程：
當(dāng)我們知道hls協(xié)議是將直播流分成一段一段的小段視頻去下載播放的，所以假設(shè)列表里面的包含5個(gè)TS文件，每個(gè)TS文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。因?yàn)楫?dāng)你看到這些視頻時(shí)，主播已經(jīng)將視頻錄制好上傳上去了，所以時(shí)這樣產(chǎn)生的延遲。當(dāng)然可以縮短列表的長(zhǎng)度和單個(gè)TS文件的大小來(lái)降低延遲，極致來(lái)說(shuō)可以縮減列表長(zhǎng)度為1，并且TS的時(shí)長(zhǎng)為1s，但是這樣會(huì)造成請(qǐng)求次數(shù)增加，增大服務(wù)器壓力，當(dāng)網(wǎng)速慢時(shí)回造成更多的緩沖，所以蘋果官方推薦的ts時(shí)長(zhǎng)時(shí)10s，所以這樣就會(huì)大改有30s的延遲。參考資料：https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
當(dāng)視頻直播可大致分為：
1 視頻錄制端：一般是電腦上的音視頻輸入設(shè)備或者手機(jī)端的攝像頭或者麥克風(fēng)，目前已移動(dòng)端的手機(jī)視頻為主。
2 視頻播放端：可以是電腦上的播放器，手機(jī)端的native播放器，還有就是h5的video標(biāo)簽等，目前還是已手機(jī)端的native播放器為主。
3 視頻服務(wù)器端：一般是一臺(tái)nginx服務(wù)器，用來(lái)接受視頻錄制端提供的視頻源，同時(shí)提供給視頻播放端流服務(wù)。
簡(jiǎn)單流程：
當(dāng)首先明確幾個(gè)概念：
視頻編碼：所謂視頻編碼就是指通過(guò)特定的壓縮技術(shù)，將某個(gè)視頻格式的文件轉(zhuǎn)換成另一種視頻格式文件的方式，我們使用的iphone錄制的視頻，必須要經(jīng)過(guò)編碼，上傳，解碼，才能真正的在用戶端的播放器里播放。
編解碼標(biāo)準(zhǔn)：視頻流傳輸中最為重要的編解碼標(biāo)準(zhǔn)有國(guó)際電聯(lián)的H.261、H.263、H.264，其中HLS協(xié)議支持H.264格式的編碼。
音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標(biāo)準(zhǔn)進(jìn)行編碼，上傳，解碼，同時(shí)在播放器里播放，當(dāng)然音頻也有許多編碼標(biāo)準(zhǔn)，例如PCM編碼，WMA編碼，AAC編碼等等，這里我們HLS協(xié)議支持的音頻編碼方式是AAC編碼。
下面將利用ios上的攝像頭，進(jìn)行音視頻的數(shù)據(jù)采集，主要分為以下幾個(gè)步驟：
1 音視頻的采集，ios中，利用AVCaptureSession和AVCaptureDevice可以采集到原始的音視頻數(shù)據(jù)流。
2 對(duì)視頻進(jìn)行H264編碼，對(duì)音頻進(jìn)行AAC編碼，在ios中分別有已經(jīng)封裝好的編碼庫(kù)來(lái)實(shí)現(xiàn)對(duì)音視頻的編碼。
3 對(duì)編碼后的音、視頻數(shù)據(jù)進(jìn)行組裝封包；
4 建立RTMP連接并上推到服務(wù)端。
ps：由于編碼庫(kù)大多使用C語(yǔ)言編寫，需要自己使用時(shí)編譯，對(duì)于ios，可以使用已經(jīng)編譯好的編碼庫(kù)。
x264編碼：https://github.com/kewlbear/x264-ios
faac編碼：https://github.com/fflydev/faac-ios-build
ffmpeg編碼：https://github.com/kewlbear/FFmpeg-iOS-build-script
關(guān)于如果想給視頻增加一些特殊效果，例如增加濾鏡等，一般在編碼前給使用濾鏡庫(kù)，但是這樣也會(huì)造成一些耗時(shí)，導(dǎo)致上傳視頻數(shù)據(jù)有一定延時(shí)。
簡(jiǎn)單流程：
和之前的x264一樣，ffmpeg其實(shí)也是一套編碼庫(kù)，類似的還有Xvid，Xvid是基于MPEG4協(xié)議的編解碼器，x264是基于H.264協(xié)議的編碼器，ffmpeg集合了各種音頻，視頻編解碼協(xié)議，通過(guò)設(shè)置參數(shù)可以完成基于MPEG4,H.264等協(xié)議的編解碼，demo這里使用的是x264編碼庫(kù)。
Real Time Messaging Protocol（簡(jiǎn)稱 RTMP）是 Macromedia 開發(fā)的一套視頻直播協(xié)議，現(xiàn)在屬于 Adobe。和HLS一樣都可以應(yīng)用于視頻直播，區(qū)別是RTMP基于flash無(wú)法在ios的瀏覽器里播放，但是實(shí)時(shí)性比HLS要好。所以一般使用這種協(xié)議來(lái)上傳視頻流，也就是視頻流推送到服務(wù)器。
這里列舉一下hls和rtmp對(duì)比：
簡(jiǎn)所謂推流，就是將我們已經(jīng)編碼好的音視頻數(shù)據(jù)發(fā)往視頻流服務(wù)器中，一般常用的是使用rtmp推流，可以使用第三方庫(kù)librtmp-iOS進(jìn)行推流，librtmp封裝了一些核心的api供使用者調(diào)用，如果覺(jué)得麻煩，可以使用現(xiàn)成的ios視頻推流sdk，也是基于rtmp的，https://github.com/runner365/LiveVideoCoreSDK
簡(jiǎn)簡(jiǎn)單的推流服務(wù)器搭建，由于我們上傳的視頻流都是基于rtmp協(xié)議的，所以服務(wù)器也必須要支持rtmp才行，大概需要以下幾個(gè)步驟：
1 安裝一臺(tái)nginx服務(wù)器。
2 安裝nginx的rtmp擴(kuò)展，目前使用比較多的是https://github.com/arut/nginx-rtmp-module
3 配置nginx的conf文件：
rtmp { server { listen 1935; #監(jiān)聽的端口 chunk_size 4000; application hls { #rtmp推流請(qǐng)求路徑 live on; hls on; hls_path /usr/local/var/www/hls; hls_fragment 5s; } } }4 重啟nginx，將rtmp的推流地址寫為rtmp://ip:1935/hls/mystream，其中hls_path表示生成的.m3u8和ts文件所存放的地址，hls_fragment表示切片時(shí)長(zhǎng)，mysteam表示一個(gè)實(shí)例，即將來(lái)要生成的文件名可以先自己隨便設(shè)置一個(gè)。更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/
根據(jù)以上步驟基本上已經(jīng)實(shí)現(xiàn)了一個(gè)支持rtmp的視頻服務(wù)器了。
簡(jiǎn)單來(lái)說(shuō)，直接使用video標(biāo)簽即可播放hls協(xié)議的直播視頻：
<video autoplay webkit-playsinline> <source src="http://10.66.69.77:8080/hls/mystream.m3u8" type="application/vnd.apple.mpegurl" /> <p class="warning">Your browser does not support HTML5 video.</p> </video>
需要注意的是，給video標(biāo)簽增加webkit-playsinline屬性，這個(gè)屬性是為了讓video視頻在ios的uiwebview里面可以不全屏播放，默認(rèn)ios會(huì)全屏播放視頻，需要給uiwebview設(shè)置allowsInlineMediaPlayback＝Y(jié)ES。業(yè)界比較成熟的videojs，可以根據(jù)不同平臺(tái)選擇不同的策略，例如ios使用video標(biāo)簽，pc使用flash等。
簡(jiǎn)根據(jù)以上步驟，筆者寫了一個(gè)demo，從實(shí)現(xiàn)ios視頻錄制，采集，上傳，nginx服務(wù)器下發(fā)直播流，h5頁(yè)面播放直播視頻者一整套流程，總結(jié)出以下幾點(diǎn)比較坑的地方：
1 在使用AVCaptureSession進(jìn)行采集視頻時(shí)，需要實(shí)現(xiàn)AVCaptureVideoDataOutputSampleBufferDelegate協(xié)議，同時(shí)在- (void)captureOutput:(AVCaptureOutput *)captureOutput didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer fromConnection:(AVCaptureConnection *)connection捕獲到視頻流，要注意的是didOutputSampleBuffer這個(gè)方法不是didDropSampleBuffer方法，后者只會(huì)觸發(fā)一次，當(dāng)時(shí)開始寫的是didDropSampleBuffer方法，差了半天才發(fā)現(xiàn)方法調(diào)用錯(cuò)了。
2 在使用rtmp推流時(shí)，rmtp地址要以rtmp://開頭，ip地址要寫實(shí)際ip地址，不要寫成localhost，同時(shí)要加上端口號(hào)，因?yàn)槭謾C(jī)端上傳時(shí)是無(wú)法識(shí)別localhost的。
這里后續(xù)會(huì)補(bǔ)充上一些坑點(diǎn)，有的需要貼代碼，這里先列這么多。
目前，騰訊云，百度云，阿里云都已經(jīng)有了基于視頻直播的解決方案，從視頻錄制到視頻播放，推流，都有一系列的sdk可以使用，缺點(diǎn)就是需要收費(fèi)，如果可以的話，自己實(shí)現(xiàn)一套也并不是難事哈。
demo地址：https://github.com/lvming6816077/LMVideoTest/
更多直播相關(guān)知識(shí)：http://lib.csdn.net/base/liveplay
聯(lián)系客服
