HTML5視頻直播及H5直播掃盲

章來源：http://geek.csdn.net/news/detail/95188

分享內容簡介： 
目前視頻直播，尤其是移動端的視頻直播已經火到不行了，基本上各大互聯網公司都有了自己的直播產品，所以對於直播的一些基本知識和主要技術點也要有所了解，本次分享就向大家介紹一下其中的奧秘。

內容大體框架: 
1. 怎樣利用 HTML5 來播放直播視頻 
2. 怎樣錄制直播視頻 
3. 怎樣實時上傳直播視頻 
4. 直播中的用戶交互

分享人介紹：

呂鳴 目前在騰訊SNG擔任手Q的web前端開發工作 
博客：http://www.nihaoshijie.com.cn/

---

下面是本期分享內容整理

---

Hello, 大家好，我是呂鳴，目前是在騰訊 SNG 的即通應用部負責手Q的興趣部落 Web 前端開發工作。

針對目前比較火的視頻直播，我做了一些研究和探索，同時我們的項目將會用到直播為此打下技術基礎，下面就向大家分享一下直播的整個流程和一些技術點。

一、移動視頻直播發展

大家首先來看下面這張圖:

可以看到，直播從 PC 到一直發展到移動端，越來越多的直播類 App 上線，同時移動直播進入了前所未有的爆發階段，但是對於大多數移動直播來說，還是要以 Native 客戶端實現為主，但是 HTML5 在移動直播端也承載着不可替代的作用，例如 HTML5 有着傳播快，易發布的優勢，同時最為關鍵的時 HTML5 同樣可以播放直播視頻。

大家可以看下面這張大概的實現圖

完整的直播可以分為以下幾塊：

1. 視頻錄制端：一般是電腦上的音視頻輸入設備或者手機端的攝像頭或者麥克風，目前以移動端的手機視頻為主。
2. 視頻播放端：可以是電腦上的播放器，手機端的 Native 播放器，還有就是 HTML5 的 video 標簽等，目前還是已手機端的 Native 播放器為主。
3. 視頻服務器端：一般是一台 nginx 服務器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務。

大家可以看下大致的結構圖：

二、HTML5 錄制視頻：

對於HTML5視頻錄制，可以使用強大的 webRTC （Web Real-Time Communication）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，缺點是只在 PC 的 Chrome 上支持較好，移動端支持不太理想。

使用 webRTC 錄制視頻基本流程是：

1. 調用 window.navigator.webkitGetUserMedia() 獲取用戶的PC攝像頭視頻數據。
2. 將獲取到視頻流數據轉換成 window.webkitRTCPeerConnection (一種視頻流數據格式)。
3. 利用 webscoket 將視頻流數據傳輸到服務端

由於許多方法都要加上瀏覽器前綴，所以很多移動端的瀏覽器還不支持 webRTC，所以真正的視頻錄制還是要靠客戶端（iOS,Android）來實現,效果會好一些。

三、HTML5 播放直播視頻：

對於視頻播放，可以使用 HLS(HTTP Live Streaming)協議播放直播流，iOS和 Android 都天然支持這種協議，配置簡單，直接使用 video 標簽即可。

下面是簡單的代碼使用 video 播放直播視頻：

1.什么是 HLS 協議:

簡單講就是把整個流分成一個個小的，基於 HTTP 的文件來下載，每次只下載一些，前面提到了用於 HTML5 播放直播視頻時引入的一個 .m3u8 的文件，這個文件就是基於 HLS 協議，存放視頻流元數據的文件。

每一個 .m3u8 文件，分別對應若干個 ts 文件，這些 ts 文件才是真正存放視頻的數據，m3u8 文件只是存放了一些 ts 文件的配置信息和相關路徑，當視頻播放時，.m3u8 是動態改變的，video 標簽會解析這個文件，並找到對應的 ts 文件來播放，所以一般為了加快速度，.m3u8 放在 Web 服務器上，ts 文件放在 CDN 上。

.m3u8 文件，其實就是以 UTF-8 編碼的 m3u 文件，這個文件本身不能播放，只是存放了播放信息的文本文件。

打開之后就是這個樣子：

下面這個是 ts 文件，就是存放視頻的文件：

2.HLS 的請求流程：

1. HTTP 請求 m3u8 的 url。
2. 服務端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，一般一次給出5段數據的 url。
3. 客戶端解析 m3u8 的播放列表，再按序請求每一段的 url，獲取 ts 數據流。

大概是這個流程：

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

但是 HTML5 直播視頻卻有一些不可替代的優勢:

1. 傳播性好，利於分享等操作。
2. 可以動態發布，有利於實時迭代產品需求並迅速上線。
3. 不用安裝 App，直接打開瀏覽器即可。

四、iOS 采集（錄制）音視頻數據OS

關於音視頻采集錄制，首先明確下面幾個概念：

• 視頻編碼：所謂視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式文件的方式，我們使用的 iPhone 錄制的視頻，必須要經過編碼，上傳，解碼，才能真正的在用戶端的播放器里播放。
• 編解碼標准：視頻流傳輸中最為重要的編解碼標准有國際電聯的 H.261、H.263、H.264，其中 HLS 協議支持 H.264 格式的編碼。
• 音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標准進行編碼，上傳，解碼，同時在播放器里播放，當然音頻也有許多編碼標准，例如 PCM 編碼，WMA 編碼，AAC 編碼等等，這里我們 HLS 協議支持的音頻編碼方式是 AAC 編碼。

利用 iOS 上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：

1. 音視頻的采集，iOS 中，利用 AVCaptureSession 和 AVCaptureDevice 可以采集到原始的音視頻數據流。
2. 對視頻進行 H264 編碼，對音頻進行 AAC 編碼，在 iOS 中分別有已經封裝好的編碼庫來實現對音視頻的編碼。
3. 對編碼后的音、視頻數據進行組裝封包；
4. 建立 RTMP 連接並上推到服務端。

下面是具體的采集音視頻數據的流程：

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 才行，大概需要以下幾個步驟：

1. 安裝一台 nginx 服務器。
2. 安裝 nginx 的 RTMP 擴展，目前使用比較多的是 https://github.com/arut/nginx-rtmp-module
3. 配置 nginx 的 conf 文件
4. 重啟 nginx，將 RTMP 的推流地址寫為 rtmp://ip:1935/hls/mystream， 其中 hls_path 表示生成的 .m3u8 和 ts 文件所存放的地址，hls_fragment 表示切片時長，mysteam 表示一個實例，即將來要生成的文件名可以先自己隨便設置一個。

更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/

下面是 nginx 的配置文件

五、直播中的用戶交互：

對於直播中的用戶交互大致可以分為：

1. 送禮物
2. 發表評論或者彈幕

對於送禮物，在 HTML5 端可以利用 DOM 和 CSS3 實現送禮物邏輯和一些特殊的禮物動畫，實現技術難點不大。

對於彈幕來說，要稍微復雜一些，可能需要關注以下幾點：

1. 彈幕實時性，可以利用 webscoket 來實時發送和接收新的彈幕並渲染出來。
2. 對於不支持 webscoket 的瀏覽器來說，只能降級為長輪詢或者前端定時器發送請求來獲取實時彈幕。
3. 彈幕渲染時的動畫和碰撞檢測(即彈幕不重疊)等等

六、總結

目前較為成熟的直播產品，大致都是以 Server 端和 HTML5 和 Native(android,ios)搭配實現直播：

基本是下圖這個套路：

所以 HTML5 在整個直播中，還是有着重要的地位的！

Demo 分享

最后，根據本次分享的內容，我這邊實現了一個 iOS 端錄制，推流，NGINX 接收流，同時分發的 HLS 直播流的一整套 Demo，感興趣的同學可以看下面這個鏈接:

https://github.com/lvming6816077/LMVideoTest

好了，本次分享先到這里了，謝謝大家~

互動問答環節

Q1: Demo 包含 iOS 端的 RTMP 播放不？

答：Demo 里面沒有 RTMP 的播放，Demo 主要是提供錄制，推流的。

Q2: 對於 HTML5 HLS 播放 卡頓問題，前端與 server 端，有什么配置上的優化嗎？

答：server 端要做好分片策略，同時要將 ts 文件放在 CDN 上，前端這邊可以盡量做到 DNS 緩存等，由於HTML5是使用的 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 播放和還有 HTML5 的 video 標簽播放, iOS 端有沒有考慮過整個用原生的 OC 或者 Swift 實現?

答：關於播放端，其實真正體驗好的還是要用 native 來實現的，而且 native 實現可以用 RTMP 來播放直播，延遲會好很多，HTML5 來播直播主要是考慮到易傳播性好。

Q8: 在用戶非常多的情況下，或者網絡慢的情況下，有什么策略可以保證質量？

答：可以提供不同的視頻碼率來供用戶選擇，例如網速差的可以選擇較為低清晰度的碼率，網絡好的用戶可以選擇更加清晰的碼率，同時做好視頻播放端的容錯和異常處理等等。

Q9: 請問直播這塊的測試中關注的幾個指標是什么，有什么比較好的測試方法呢？

答：主要就是： 
1. 首次打開的白屏時間 
2. 直播中的卡頓和緩沖 
3. 直播的延時

Q10: 您提供的 Demo 為什么不是 HTML5 的呢 iOS 推流和 nginx 服務器都有，能不能提供一個前面第二張葉子美女直播那個頁面的 Demo？

答：這個 Demo 你下載下拉運行的話，根據配置就可直接自己實現一個利用 HTML5 直播的頁面，很簡單，就像使用 video 標簽一樣，其他的樣式你可以自己定制的。

Q11: HLS 的延時有沒有比較好的方法解決？

答：HLS 確實是會有延遲，相對比較優的策略是調整好分片策略，在保證性能的情況下，和延遲達到平衡。

Q12: 如果加入視頻電話功能，上面的結構需要作什么改變？視頻電話的目的大概是：直播可以選擇某一觀眾或者多個觀眾視頻對話

答：視頻電話，也就是說作為視頻錄制端的同時也作為視頻播放端，所以實現實時電話簡單就是：我在直播的同時觀看別人的直播視頻，別人在直播的同時觀看我的直播視頻，可以這樣理解，上面的結構復制一份對調即可。

Q13: 如何實現濾鏡功能？

答：一般是在視頻錄制之后，在轉碼前給視頻數據增加濾鏡功能，在 iOS 里可以使用一些濾鏡庫等等實現濾鏡功能

Q14: 在 App 端如果不利用 HTML5 能實現直播嗎？

答：可以啊，app 有更加豐富的播放接口，和開源播放器可以實現直播的。

Q15: 既然 HLS 有較高的延遲 為什么蘋果推薦的的方式卻是 HLS？

答：並不是說蘋果主要推薦使用 HLS，對於 HTML5 來說目前只有這一種比較好的方式來播放直播視頻，所以還是很期待蘋果能對延遲問題做一些改進的。

Q16: 同濾鏡問題，音頻變聲是如何實現的？

答：同樣是可以在對音頻轉碼前操作。

Q17: 如果針對網絡較差的觀看用戶，是需要直播推流到服務器后做多份不同分辨率的拷貝，以適應不同網絡的用戶觀看？如果是這樣的話，對延遲會不會影響很大？ 畢竟編解碼也是需要時間的.

答：這個其實本身就應該做的，對於網絡差的用戶，完全可以提供給他們較低碼率的直播流來減少卡頓問題，延遲問題的話還是要根據具體使用哪種協議來定。

Q18: 推流目前大部分都是第三方在做，難度點在哪？然后目前業內比較成熟的主要哪些？

答：難點主要是服務器端的性能壓力和分發直播流的效率，業界都已經有了較成熟的方案，例如騰訊雲的直播。

點此查看 Dev Club 往期分享匯總

---

騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合並功能幫助開發同學把每天上報的數千條Crash 根據根因合並分類，每日日報會列出影響用戶數最多的崩潰，精准定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布后快速的了解應用的質量情況，適配最新的 iOS、Android 官方操作系統。

 

下面是H5相關掃盲方面的知識：

 

文章來源：https://www.nihaoshijie.com.cn/index.php/archives/615

視頻直播這么火，再不學就out了。

為了緊跟潮流，本文將向大家介紹一下視頻直播中的基本流程和主要的技術點，包括但不限於前端技術。

1 H5到底能不能做視頻直播？

當然可以， H5火了這么久，涵蓋了各個方面的技術。

對於視頻錄制，可以使用強大的webRTC（Web Real-Time Communication）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，缺點是只在PC的chrome上支持較好，移動端支持不太理想。

對於視頻播放，可以使用HLS(HTTP Live Streaming)協議播放直播流，ios和android都天然支持這種協議，配置簡單，直接使用video標簽即可。

webRTC兼容性：

video標簽播放hls協議視頻：

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

2 到底什么是HLS協議？

當簡單講就是把整個流分成一個個小的基於HTTP的文件來下載，每次只下載一些，前面提到了用於H5播放直播視頻時引入的一個.m3u8的文件，這個文件就是基於HLS協議，存放視頻流元數據的文件。

每一個.m3u8文件，分別對應若干個ts文件，這些ts文件才是真正存放視頻的數據，m3u8文件只是存放了一些ts文件的配置信息和相關路徑，當視頻播放時，.m3u8是動態改變的，video標簽會解析這個文件，並找到對應的ts文件來播放，所以一般為了加快速度，.m3u8放在web服務器上，ts文件放在cdn上。

.m3u8文件，其實就是以UTF-8編碼的m3u文件，這個文件本身不能播放，只是存放了播放信息的文本文件：

​#EXTM3U                     m3u文件頭
#EXT-X-MEDIA-SEQUENCE       第一個TS分片的序列號
#EXT-X-TARGETDURATION       每個分片TS的最大的時長
#EXT-X-ALLOW-CACHE          是否允許cache
#EXT-X-ENDLIST              m3u8文件結束符
#EXTINF                     指定每個媒體段(ts)的持續時間（秒），僅對其后面的URI有效
mystream-12.ts

ts文件：

HLS的請求流程是：
1 http請求m3u8的url
2 服務端返回一個m3u8的播放列表，這個播放列表是實時跟新的，一般一次給出3段數據的url
3 客戶端解析m3u8的播放列表，再按序請求每一段的url，獲取ts數據流

簡單流程：

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

4 視頻直播的整個流程是什么？

當視頻直播可大致分為：

1 視頻錄制端：一般是電腦上的音視頻輸入設備或者手機端的攝像頭或者麥克風，目前已移動端的手機視頻為主。

2 視頻播放端：可以是電腦上的播放器，手機端的native播放器，還有就是h5的video標簽等，目前還是已手機端的native播放器為主。

3 視頻服務器端：一般是一台nginx服務器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務。

簡單流程：

 

 

5 怎樣進行音視頻采集？

當首先明確幾個概念：

視頻編碼：所謂視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式文件的方式，我們使用的iphone錄制的視頻，必須要經過編碼，上傳，解碼，才能真正的在用戶端的播放器里播放。

編解碼標准：視頻流傳輸中最為重要的編解碼標准有國際電聯的H.261、H.263、H.264，其中HLS協議支持H.264格式的編碼。
音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標准進行編碼，上傳，解碼，同時在播放器里播放，當然音頻也有許多編碼標准，例如PCM編碼，WMA編碼，AAC編碼等等，這里我們HLS協議支持的音頻編碼方式是AAC編碼。

下面將利用ios上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：

 

1 音視頻的采集，ios中，利用AVCaptureSession和AVCaptureDevice可以采集到原始的音視頻數據流。
2 對視頻進行H264編碼，對音頻進行AAC編碼，在ios中分別有已經封裝好的編碼庫來實現對音視頻的編碼。
3 對編碼后的音、視頻數據進行組裝封包；
4 建立RTMP連接並上推到服務端。

 

ps：由於編碼庫大多使用c語言編寫，需要自己使用時編譯，對於ios，可以使用已經編譯好的編碼庫。

x264編碼：https://github.com/kewlbear/x264-ios

faac編碼：https://github.com/fflydev/faac-ios-build

ffmpeg編碼：https://github.com/kewlbear/FFmpeg-iOS-build-script

關於如果想給視頻增加一些特殊效果，例如增加濾鏡等，一般在編碼前給使用濾鏡庫，但是這樣也會造成一些耗時，導致上傳視頻數據有一定延時。

簡單流程：

6 前面提到的ffmpeg是什么？

和之前的x264一樣，ffmpeg其實也是一套編碼庫，類似的還有Xvid，Xvid是基於MPEG4協議的編解碼器，x264是基於H.264協議的編碼器，ffmpeg集合了各種音頻，視頻編解碼協議，通過設置參數可以完成基於MPEG4,H.264等協議的編解碼，demo這里使用的是x264編碼庫。

7 什么是RTMP？

Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視頻直播協議，現在屬於 Adobe。和HLS一樣都可以應用於視頻直播，區別是RTMP基於flash無法在ios的瀏覽器里播放，但是實時性比HLS要好。所以一般使用這種協議來上傳視頻流，也就是視頻流推送到服務器。

這里列舉一下hls和rtmp對比：

8 推流

簡所謂推流，就是將我們已經編碼好的音視頻數據發往視頻流服務器中，一般常用的是使用rtmp推流，可以使用第三方庫librtmp-iOS進行推流，librtmp封裝了一些核心的api供使用者調用，如果覺得麻煩，可以使用現成的ios視頻推流sdk，也是基於rtmp的，https://github.com/runner365/LiveVideoCoreSDK

9 推流服務器搭建

簡簡單的推流服務器搭建，由於我們上傳的視頻流都是基於rtmp協議的，所以服務器也必須要支持rtmp才行，大概需要以下幾個步驟：

1 安裝一台nginx服務器。

2 安裝nginx的rtmp擴展，目前使用比較多的是https://github.com/arut/nginx-rtmp-module

3 配置nginx的conf文件：

rtmp {  
  
    server {  
  
        listen 1935;  #監聽的端口
  
        chunk_size 4000;  
        
         
        application hls {  #rtmp推流請求路徑
            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表示切片時長，mysteam表示一個實例，即將來要生成的文件名可以先自己隨便設置一個。更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/

根據以上步驟基本上已經實現了一個支持rtmp的視頻服務器了。

10 在html5頁面進行播放直播視頻？

簡單來說，直接使用video標簽即可播放hls協議的直播視頻：

<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標簽增加webkit-playsinline屬性，這個屬性是為了讓video視頻在ios的uiwebview里面可以不全屏播放，默認ios會全屏播放視頻，需要給uiwebview設置allowsInlineMediaPlayback＝YES。業界比較成熟的videojs，可以根據不同平台選擇不同的策略，例如ios使用video標簽，pc使用flash等。

11 坑點總結

簡根據以上步驟，筆者寫了一個demo，從實現ios視頻錄制，采集，上傳，nginx服務器下發直播流，h5頁面播放直播視頻者一整套流程，總結出以下幾點比較坑的地方：

1 在使用AVCaptureSession進行采集視頻時，需要實現AVCaptureVideoDataOutputSampleBufferDelegate協議，同時在- (void)captureOutput:(AVCaptureOutput *)captureOutput didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer fromConnection:(AVCaptureConnection *)connection捕獲到視頻流，要注意的是didOutputSampleBuffer這個方法不是didDropSampleBuffer方法，后者只會觸發一次，當時開始寫的是didDropSampleBuffer方法，差了半天才發現方法調用錯了。

2 在使用rtmp推流時，rmtp地址要以rtmp://開頭，ip地址要寫實際ip地址，不要寫成localhost，同時要加上端口號，因為手機端上傳時是無法識別localhost的。

這里后續會補充上一些坑點，有的需要貼代碼，這里先列這么多。

12 業界支持

目前，騰訊雲，百度雲，阿里雲都已經有了基於視頻直播的解決方案，從視頻錄制到視頻播放，推流，都有一系列的sdk可以使用，缺點就是需要收費，如果可以的話，自己實現一套也並不是難事哈。

 

demo地址：https://github.com/lvming6816077/LMVideoTest/

 

 

 

更多直播相關知識：http://lib.csdn.net/base/liveplay