直播和點播技術分析

專一網頁播放器的網站http://www.52player.com/

HLS  ts m3u8文件
HTTP
HTTP+RTMAP

HTTP Live Streaming（HLS）

http://www.cnblogs.com/haibindev/archive/2013/01/30/2880764.html

HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基於HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，爲iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不一樣在於，它的分段很是小。要實現HLS點播，重點在於對媒體文件分段，目前有很多開源工具可使用，這裏我就再也不討論，只談HLS直播技術。

相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不一樣在於，直播客戶端獲取到的，並非一個完整的數據流。HLS協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載並播放這些小文件，由於服務器端老是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。因而可知，基本上能夠認爲，HLS是以點播的技術方式來實現直播。因爲數據經過HTTP協議傳輸，因此徹底不用考慮防火牆或者代理的問題，並且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過HLS的這種技術特色，決定了它的延遲通常老是會高於普通的流媒體直播協議。

HLS的協議規範 生成分段的標準TS文件以及m3u8索引文件

P2P播放技術

電腦A 點播一個視頻vedio，服務器記錄下，並查詢電腦A周圍有哪一個電腦也在看這個視頻，發現了電腦B ，這時候讓電腦B做爲CDN爲電腦A提供資源

CDN：內容加速

hls是普通視頻 

 drm是數字版權保護 視頻

 https 是外面弄了個tunnel 

http和https的區別

這個tunnel在一系列握手操做以後創建的  tunnel中傳送的數據會作對稱加密/解密，其中涉及到6個key 並且是短週期，因此安全。 http和https使用的是徹底不一樣的鏈接方式,用的端口也不同,前者是80,後者是443。http的鏈接很簡單,是無狀態的,... HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議 要比http協議安全

HLS與RTMP ,RTSP對比

http://blog.csdn.net/funkri/article/details/10191351

 你說的應該是 HTTP Live Streaming [1] 吧。這個是 Apple 爲了提升流播效率開發的技術，特色是將流媒體切分爲若干 TS 片斷（好比每10秒一段），而後經過一個擴展的 m3u 列表文件將這些 TS 片斷集中起來供客戶端播放器接收。

這樣作相比使用 RTSP 協議的好處在於，一旦切分完成，以後的分發過程徹底不須要額外使用任何專門軟件，普通的網絡服務器便可，大大下降了 CDN 邊緣服務器的配置要求，可使用任何現成的 CDN。分發使用的協議是最多見 HTTP，代理服務器對這個協議的緩存優化至關成熟，而不多有代理服務器對 RTSP 的進行緩存優化。這對播放（軟）實時視頻有至關大的優點，由於這樣分發後，對源服務器的負載壓力小得多。

流媒體協議一共三種：rtmp，rtsp，http live streaming(apple和adobe各一種)
rtmp是adobe的，rtsp android native支持，http live streaming(如下簡稱hls)固然是apple主打，後來adobe也終於開竅支持了。
rtmp和rtsp都要求特殊的服務器，例如rtmp要求FMS/red5, rtsp要求darwin等，hls只要普通的server，其好處一樓說的很清楚了。

RTMP直播應用與延時分析 

http://blog.chinaunix.net/uid-26000296-id-4932817.html

直播應用中，RTMP和HLS基本上能夠覆蓋全部客戶端觀看，
HLS主要是延時比較大，RTMP主要優點在於延時低。

流媒體分發方式比較

http://blog.chinaunix.net/uid-26000296-id-4932822.html

對比如下互聯網上用的流媒體分發方式：
  . HLS：apple的HLS，支持點播和直播。
  . HTTP：即HTTP stream，各家本身定義的http流，應用於國內點播視頻網站。
  . RTMP：直播應用，對實時性有必定要求，以PC爲主。

RTMFP 基於UDP的RTMFP M3U8 VOD.

經過使用RTMFP, 那些依賴直播、實時通訊的應用，好比社區、音視頻聊天和多人遊戲就有能力來發布高質量的通訊解決方案。RTMFP讓終端用戶能夠直接鏈接並通訊，可使用麥克風和攝象頭直接聊天。RTMFP將不支持文件和 文檔共享。此方案提高了目前Flash Player在網絡交互方面的體驗。

RTMFP將減小直播、實時聊天方案的帶寬消耗，例如音視頻聊天和多人遊戲。由於RTMFP的數據在終端用戶之間流動，而不是和服務器，因此此方案很適合於大範圍的部署。RTMFP由於採用了UDP也提高了傳送的速度。UDP是Internet上一種更有效傳送音頻視頻的方法，雖然會有一些丟包，錯包。RTMFP有兩個特性能夠幫助解決一些鏈接錯誤。

快速鏈接恢復：鏈接在乎外狀況下將快速恢復。例如，一個無線鏈接掉線了，一旦重連，他將迅速擁有全部的傳送能力。

IP動態化：一個活動的網絡會話將以PEER來標識，即便他變了一個IP，也能夠保持原來的會話。例如，一個筆記本在一個無線網絡得到了一個新IP地址，他將馬上繼續剛纔的會話。

RTMP和RTMFP之間的不一樣

最基本的確實是他們在網絡上採用的協議。RTMFP是基於UDP的，RTMP是基於TCP的。UDP在傳送直播數據方面比TCP仍是有較多優點的，好比減小延時，對 丟包的容忍，雖然在可靠性上有所損失。不象RTMP, RTMFP支持Flash Player直接發送數據給另外一個，而不通過Server。服務端鏈接將被用來初始化並交互一些客戶端之間的信息，也可用來進行服務端調用或者做爲進入其餘系統的網關。FMS也將用來爲用戶提供地址認證服務和NAT地址轉換服務，避免用戶陷入混亂。

Adobe提供的Cirrus（Stratus）超級節點服務，以幫助獨立的Flash Player節點登陸得到P2P迭代網（overlay）的ID，協助穿透防火牆等。用戶能夠另外構建單獨的Tracker服務幫助篩選節點，或者直接使用RTMFP的group服務，採用組播方式進行數據分享。

 

推流軟件 OBS

DirectX是Windows必備的性能加強程序，可是系統自帶的DirectX的文件並不全，致使XSplit和OBS會出現各類錯誤：好比OBS64位打不開，好比提示缺乏DirectX裏的某個文件等等，因此咱們須要用此工具修復一下便可，他會自動檢測你缺乏的文件並修復。 http://www.xspliter.com/thread-810-1-1.html 怎麼使用？ http://www.anxia.com/jiaocheng/13505.html