直播和點播技術分析

專注網頁播放器的網站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