程式狂想筆記

一個攻城師奮鬥史

0%

hls影音串流小記

最近看到網頁上的影音,他播放的時候不會全下載
好奇就網頁爬了一下
是用 hls 技術,雖然現在還沒有用到
不過我還滿感一點興趣
就查一些記錄,筆記筆記

切割 hls 檔案
ffmpeg -i low_30.mp3 -c:a aac -b:a 64k -vn -hls_list_size 0 abc.m3u8
ffmpeg -i eq_1.mp4 -vcodec copy -acodec copy ~~-vbsf h264_mp4toannexb~~ -hls_time 10 -hls_list_size 999999999 output.m3u8
-vbsf h264_mp4toannexb 拿掉就可以跑了
雖然不知道甚麼問題,不過解決了

Nginx-rtmp 模块实现流媒体 play、push、pull 功能-Dream come true-51CTO 博客
直播技术实现(一)
直播技术实现(二)
筆記:使用 nginx 搭建一個 HLS(HTTP Live Streaming) & Rtmp 直播服務器 | 奈特的魔法科研

名詞簡單小記

SRS(Simple RTMP Server)

架設 RTMP Server
簡單來說就是直播伺服器

3、将其中一个直播流,视频改用 h264 压缩,音频不变,送至另外一个直播服务流
ffmpeg -i rtmp://server/live/originalStream -c:a copy -c:v libx264 -vpre slow -f flv rtmp://server/live/h264Stream
當出看一直看不到為什麼 rtmp 傳到另一個 rtmp
後來看到直播服務流
就想到應該像 youtube,twitter
讓我想到 obs 應該也是發到 rtmp server 去

rtmp rstp hls(http live streaming)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
1、HTTP協議:
HTTP的視頻協議,主要是在互聯網普及之後。在互聯網上看視頻的需求下形成的。
最初的HTTP視頻協議,沒有任何特別之處,就是通用的HTTP文件漸進式下載。本質就是下載視頻文件,而利用視頻文件本身的特點,就是存在頭部信息,和部分視頻幀數據,就完全可以解碼播放了。顯然這種方式需要將視頻文件的頭部信息放在文件的前面。有些例如faststart工具,就是專門做這個功能的。
但是最為原始的狀態下,視頻無法進行快進或者跳轉播放到文件尚未被下載到的部分。這個時候對HTTP協議提出了range-request的要求。這個目前幾乎所有HTTP的服務器都支持了。range-request,是請求文件的部分數據,指定偏移字節數。在視頻客戶端解析出視頻文件的頭部後,就可以判斷後續視頻相應的幀的位置了。或者根據碼率等信息,計算相應的為位置。

優點:
HTTP Live Streaming 還有一個巨大優勢:自適應碼率流播(adaptive streaming)。效果就是客戶端會根據網絡狀況自動選擇不同碼率的視頻流,條件允許的情況下使用高碼率,網絡繁忙的時候使用低碼率,並且自動在二者間隨意切換。這對移動設備網絡狀況不穩定的情況下保障流暢播放非常有幫助。實現方法是服務器端提供多碼率視頻流,並且在列表文件中註明,播放器根據播放進度和下載速度自動調整。使用起來也非常簡單。
缺點:
實時性相對較差,直播的時候延遲比較高。當然,現在進化出來的flv_over_http或者ts_over_http也可以做到直播延時很低,基本和rtmp協議差不多。

2、RTSP協議:
用於Internet上針對多媒體數據流的一種傳輸協議,是TCP/IP協議體系中的一個應用層協議,RTSP在體系結構上位於RTP和RTCP之上,它使用TCP或UDP完成數據傳輸,該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。
本協議是最早的視頻傳輸協議。其中RTSP協議用於視頻點播的會話控制,例如發起點播請求的SETUP請求,進行具體播放操作的PLAY、PAUSE請求,視頻的跳轉也是通過PLAY請求的參數支持的。

優點:
RTSP協議族的優勢,在於可以控制到視頻幀,因此可以承載實時性很高的應用。這個優點是相對於HTTP方式的最大優點。H.323視頻會議協議,底層一般採用RTSP協議。RTSP協議族的複雜度主要集中在服務器端,因為服務器端需要parse視頻文件,seek到具體的視頻幀,而且可能還需要進行倍速播放(就是老舊的DVD帶的那種2倍速,4倍速播放的功能),倍速播放功能是RTSP協議獨有的,其他視頻協議都無法支持。
缺點:
就是服務器端的複雜度也比較高,實現起來也比較複雜。Ios端不支持該協議。

3、RTMP協議:
RTMP是Real Time Messaging Protocol(實時消息傳輸協議)的首字母縮寫。RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。該協議基於TCP,是一個協議族,包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。RTMP是一種設計用來進行實時數據通信的網絡協議,主要用來在Flash/AIR平台和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通信。支持該協議的軟件包括Adobe Media Server/Aoku Media Server/red5/Wowza等。

優點:

支持直播、點播

缺點:
需要專用的服務器。

三、協議對比
關於三個RTMP,RTSP,HTTP的對比:
1.RTMP是adobe的,RTSP是 android native支持,http協議。
2.RTMP和HTTP有adaptive streaming的技術,RTSP沒有
3.RTSP實時性是最好的,HTTP實時性比較差。
4.ios不支持rtsp,安卓支持。

四、總結
三種協議各有優缺點,rtmp協議應用範圍比較窄,一般客戶端需要用flash接收,rtsp一般常用於監控領域和對實時性要求比較高的場合,http的延伸hls用的比較多,一般用在移動終端觀看,一般一個成熟的流媒體服務系統都需要支持這三種協議,甚至更多的協議,比如udp組播,單播,或者p2p協議等。
Aoku Media Server是可以同時支持這三種流媒體協議的。是國內為數不多的專業流媒體服務系統,提供的免費版可以供用戶進行三種協議的測試對比

簡單來說,hls 是基於 http
但是只有 apple 支援,所以 apple 裝置可以直接用
要瀏覽器支援要用video-dev/hls.js: JavaScript HLS client using Media Source Extension

nginx-rtmp-module

目前感覺就是跟 rtmp 與 rtmp server 串接用
Nginx-rtmp 模块实现流媒体 play、push、pull 功能-Dream come true-51CTO 博客
備份圖

1
2
3
4
Nginx RTMP Module - 架構在Nginx之上, 也算老牌了, 支援RTMP和HLS, 但看code base, 實在也沒啥在更新
Mona server - 支援RTMP, HTTP(非HLS), Web socket等等
Red5 Media Server - 支援RTMP, HLS, WebSocket, RTSP, 好像是要錢
Simpe RTMP Server - 這是由中國的觀止雲這家開源出來的, 講”Simple”其實一點都不Simple, 輕量, 穩定(至少我試直播一晚上都還蠻順利的), 好擴展(支援forward to edge), 可RTMP轉HLS, 因此我最後選擇這個方案

其實今天仔細找了一下,SRS 跟 nginx-rtmp-module 只要選其中一種就可以了
參考來源:[筆記] 中秋連假小實驗 – Le murmure de Julian

裡面寫的很詳細

影片/音樂傳流檔案

mp2t for audio/video
m3u8 for 多媒體列表檔案格式

hls 加密

雖然最近沒有打算做這個相關東西
但是不知道為什麼對 hls 特別有興趣 XD
越記越多,希望哪天有機會用到