直播和点播技术分析
專注網頁播放器的網站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 |
轉載于:https://www.cnblogs.com/as3lib/p/5212041.html
總結
- 上一篇: 你能想象吗?几年后数据科学家纷纷下岗再就
- 下一篇: Chrome——我的Chrome插件