整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
圖網站的踩坑筆記，vue開發項目中通過api接口獲取到了m3u8格式的音頻，但是有的瀏覽器默認不支持，所以需要借助輔助手段來實現，下面介紹詳細方法。
什么是m3u8？
m3u8是m3u的一種，是utf-8格式的，Apple 為了提高流播效率開發的技術，特點是將流媒體切分為若干 TS 片段（比如每10秒一段），然后通過一個擴展的 m3u 列表文件將這些 TS 片段集中起來供客戶端播放器接收。可以做多碼率的適配，根據網絡帶寬，客戶端會自動選擇一個適合自己碼率的文件進行播放，保證視頻流的流暢。
html5的video標簽實現對HLS(m3u8格式)的支持方法
<script src="https://cdn.jsdelivr.net/hls.js/latest/hls.min.js"></script>
<video id="video"></video>
<script>
if(Hls.isSupported()) {
var video = document.getElementById('video');
var hls = new Hls();
hls.loadSource('http://www.streambox.fr/playlists/test_001/stream.m3u8');
hls.attachMedia(video);
hls.on(Hls.Events.MANIFEST_PARSED,function() {
video.play();
});
}
</script>來源：http://www.qietu.com/hml5-video-m3u8-hls-min-js/
們經常看視頻，有一種視頻格式叫做m3u8，這種采用流式傳輸文件，這樣可以根據網絡情況，動態的傳遞視頻，分片傳輸，有效的應對各種復雜的網絡環境。而這種技術起叫做 HLS。
HLS英文全稱叫做 HTTP Live Streaming 是 Apple 的動態碼率自適應技術。
主要是用于 PC和 Apple 終端的音視頻服務。包括一個 m3u8 的索引文件，TS 媒體分片和 key 加密串文件。
常用的流媒體協議主要有 HTTP 漸進下載和基于 RTSP/RTP 的實時流媒體協議，這兩種基本是完全不同的東西，目前比較方便又好用的是用 http 漸進下載的辦法。
在這個中蘋果公司的 HTTP Live Streaming是這個方面的代表。它最初是蘋果公司針對蘋果手機，蘋果平板電腦等移動設備而開發的流，現在見到在桌面也有很多應用，HTML5 是直接支持這個。
HLS就是屬于流媒體的一種，那么什么是流媒體？流媒體就是將數據，比如音頻，視頻，多媒體等內容，傳輸到各種終端解碼播放。比如各種手機 App，電視點播，電腦應用，網頁，ipad 應用等等。
直接含義就是邊傳邊播，不用等到把視頻全部下載完成播放。最常見的直接感受就是直播了，觀眾和主播可以實時互動。
RTP是一種基于包的傳輸協議，它用來傳輸實時數據。在網絡上傳輸數據包的延遲和誤差是不可避免的，對此RTP包頭包含時間戳、丟失保護、載荷標識、源標識和安全性信息。這些信息用于在應用層實現數據包丟失恢復、擁塞控制等。
RTP通常運行于UDP的上層，以利用UDP的復用和求和校驗功能。RTP是在兩個主機之間提供基于連接的、穩定的數據流，而UDP是在網絡上提供一種非連接數據報服務。如圖是采用了UDP/IP包封裝的RTP包
Real-time Transport Protocol)是用于Internet上針對多媒體數據流的一種傳輸層協議。RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用于流媒體系統（配合RTCP協議），視頻會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。RTP協議和RTP控制協議RTCP一起使用，而且它是建立在UDP協議上的。
RTP 本身并沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網絡的可靠性。 RTP 實行有序傳送， RTP 中的序列號允許接收方重組發送方的包序列，同時序列號也能用于決定適當的包位置，例如：在視頻解碼中，就不需要順序解碼。
RTP 由兩個緊密鏈接部分組成： RTP ― 傳送具有實時屬性的數據；RTP 控制協議（RTCP） ― 監控服務質量并傳送正在進行的會話參與者的相關信息。
實時傳輸控制協議（Real-time Transport Control Protocol或RTP Control Protocol或簡寫RTCP）是實時傳輸協議（RTP）的一個姐妹協議。RTCP為RTP媒體流提供信道外（out-of-band）控制。RTCP本身并不傳輸數據，但和RTP一起協作將多媒體數據打包和發送。RTCP定期在流多媒體會話參加者之間傳輸控制數據。RTCP的主要功能是為RTP所提供的服務質量（Quality of Service）提供反饋。
RTCP收集相關媒體連接的統計信息，例如：傳輸字節數，傳輸分組數，丟失分組數，jitter，單向和雙向網絡延遲等等。網絡應用程序可以利用RTCP所提供的信息試圖提高服務質量，比如限制信息流量或改用壓縮比較小的編解碼器。RTCP本身不提供數據加密或身份認證。SRTCP可以用于此類用途。
安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，并最早由IETF于2004年3月作為RFC3711發布。
由于實時傳輸協議和可以被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有著緊密的聯系，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。
在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即使使用了安全實時傳輸協議或安全實時傳輸控制協議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協議時，必須要用到其消息認證特性。
是由Real Networks和Netscape共同提出的。該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中的數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、多播UDP與TCP提供途徑，并為選擇基于RTP上發送機制提供方法。
RTSP（Real Time Streaming Protocol）是用來控制聲音或影像的多媒體串流協議，并允許同時多個串流需求控制，傳輸時所用的網絡通訊協定并不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但并不特別強調時間同步，所以比較能容忍網絡延遲。而前面提到的允許同時多個串流需求控制（Multicast），除了可以降低服務器端的網絡用量，更進而支持多方視訊會議（Video Conference）。 因為與HTTP1.1的運作方式相似，所以代理服務器《Proxy》的快取功能《Cache》也同樣適用于RTSP，并因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中于同一服務器而造成延遲。
RTP不象http和ftp可完整的下載整個影視文件，它是以固定的數據率在網絡上發送數據，客戶端也是按照這種速度觀看影視文件，當影視畫面播放過后，就不可以再重復播放，除非重新向服務器端要求數據。
RTSP與RTP最大的區別在于：RTSP是一種雙向實時數據傳輸協議，它允許客戶端向服務器端發送請求，如回放、快進、倒退等操作。當然，RTSP可基于RTP來傳送數據，還可以選擇TCP、UDP、組播UDP等通道來發送數據，具有很好的擴展性。它時一種類似與http協議的網絡應用層協議。目前碰到的一個應用：服務器端實時采集、編碼并發送兩路視頻，客戶端接收并顯示兩路視頻。由于客戶端不必對視頻數據做任何回放、倒退等操作，可直接采用UDP+RTP+組播實現。
相關視頻推薦
如何設計一個RTMP-RTSP-WebRTC流媒體播放器|流媒體服務器架構分析|推流-轉發-拉流模塊開發|如何進階掌握流媒體服務器_嗶哩嗶哩_bilibili
音視頻面試必問-RTSP/RTMP推流的各種坑分析_嗶哩嗶哩_bilibili
【免費】FFmpeg/WebRTC/RTMP/NDK/Android音視頻流媒體高級開發-學習視頻教程-騰訊課堂
需要更多ffmpeg/webrtc..音視頻流媒體開發學習資料加群812855908領取
RTSP和HTTP所提供的的服務相同，知識RTSP是以音視頻流的形式，HTTP以文本和圖形的形式。
不同之處主要表現在兩個地：
1，RTSP兼容的視頻服務器必須維持會話狀態，以將RTSP請求和流關聯起來
2，從本質上來說HTTP是一個不對稱協議(客戶端發出請求，服務器響應)，但在RTSP協議中客戶端和服務器都可以發出請求
會話描述協議（SDP:Session Description Protocol）為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。
會話目錄用于協助多媒體會議的通告，并為會話參與者傳送相關設置信息。SDP 即用于將這種信息傳輸到接收端。SDP 完全是一種會話描述格式 ― 它不屬于傳輸協議 ― 它只使用不同的適當的傳輸協議，包括會話通知協議（SAP）、會話初始協議（SIP）、實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議（HTTP）。
SDP 的設計宗旨是通用性，它可以應用于大范圍的網絡環境和應用程序，而不僅僅局限于組播會話目錄，但 SDP 不支持會話內容或媒體編碼的協商。
在因特網組播骨干網（Mbone）中，會話目錄工具被用于通告多媒體會議，并為參與者傳送會議地址和參與者所需的會議特定工具信息，這由 SDP 完成。SDP 連接好會話后，傳送足夠的信息給會話參與者。SDP 信息發送利用了會話通知協議（SAP），它周期性地組播通知數據包到已知組播地址和端口處。這些信息是 UDP 數據包，其中包含 SAP 協議頭和文本有效載荷（text payload）。這里文本有效載荷指的是 SDP 會話描述。此外信息也可以通過電子郵件或 WWW （World Wide Web） 進行發送。
SDP 文本信息包括：
會話名稱和意圖；
會話持續時間；
構成會話的媒體；
有關接收媒體的信息（地址等）。
協議結構
SDP 信息是文本信息，采用 UTF-8 編 碼中的 ISO 10646 字符集。SDP 會話描述如下：（標注 * 符號的表示可選字段）：
v = （協議版本）
o = （所有者/創建者和會話標識符）
s = （會話名稱）
i = * （會話信息）
u = * （URI 描述）
e = * （Email 地址）
p = * （電話號碼）
c = * （連接信息 ― 如果包含在所有媒體中，則不需要該字段）
b = * （帶寬信息）
一個或更多時間描述（如下所示）：
z = * （時間區域調整）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
0個或多個媒體描述（如下所示）
時間描述
t = （會話活動時間）
r = * （0或多次重復次數）
媒體描述
m = （媒體名稱和傳輸地址）
i = * （媒體標題）
c = * （連接信息 — 如果包含在會話層則該字段可選）
b = * （帶寬信息）
k = * （加密密鑰）
a = * （0 個或多個會話屬性行）
RTMP(Real Time Messaging Protocol)實時消息傳送協議是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。
它有三種變種：
1)工作在TCP之上的明文協議，使用端口1935；
2)RTMPT封裝在HTTP請求之中，可穿越防火墻；
3)RTMPS類似RTMPT，但使用的是HTTPS連接；
RTMP協議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸.這個協議建立在TCP協議或者輪詢HTTP協議之上.
RTMP協議就像一個用來裝數據包的容器,這些數據既可以是AMF格式的數據,也可以是FLV中的視/音頻數據.一個單一的連接可以通過不同的通道傳輸多路網絡流.這些通道中的包都是按照固定大小的包傳輸的.
MMS (Microsoft Media Server Protocol)，中文“微軟媒體服務器協議”，用來訪問并流式接收 Windows Media 服務器中 .asf 文件的一種協議。MMS 協議用于訪問 Windows Media 發布點上的單播內容。MMS 是連接 Windows Media 單播服務的默認方法。若觀眾在 Windows Media Player 中鍵入一個 URL 以連接內容，而不是通過超級鏈接訪問內容，則他們必須使用MMS 協議引用該流。MMS的預設埠（端口）是1755
當使用 MMS 協議連接到發布點時，使用協議翻轉以獲得最佳連接。“協議翻轉”始于試圖通過 MMSU 連接客戶端。 MMSU 是 MMS 協議結合 UDP 數據傳送。如果 MMSU 連接不成功，則服務器試圖使用 MMST。MMST 是 MMS 協議結合 TCP 數據傳送。
如果連接到編入索引的 .asf 文件，想要快進、后退、暫停、開始和停止流，則必須使用 MMS。不能用 UNC 路徑快進或后退。若您從獨立的 Windows Media Player 連接到發布點，則必須指定單播內容的 URL。若內容在主發布點點播發布，則 URL 由服務器名和 .asf 文件名組成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服務器名，sample.asf 是您想要使之轉化為流的 .asf 文件名。
若您有實時內容要通過廣播單播發布，則該 URL 由服務器名和發布點別名組成。例如：mms://windows_media_server/LiveEvents。這里 windows_media_server 是 Windows Media 服務器名，而 LiveEvents 是發布點名
HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現的基于HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用在iOS系統，為iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不同在于，它的分段非常小。
相對于常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不同在于，直播客戶端獲取到的，并不是一個完整的數據流。HLS協議在服務器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因為服務器端總是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。由此可見，基本上可以認為，HLS是以點播的技術方式來實現直播。由于數據通過HTTP協議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高于普通的流媒體直播協議。
根據以上的了解要實現HTTP Live Streaming直播，需要研究并實現以下技術關鍵點
最近打算直播上http-flv，之前用的是rtmp和hls。為什么使用http-flv,它有什么優缺點？
怎么讓流媒體服務器支持flv直播？
一、市場上哪家直播使用了http-flv:
通過抓包分析: 優酷的pc網頁直播使用了http-flv。
斗魚、熊貓tv、虎牙pc網頁上的也使用了http-flv。
二、http-flv、rtmp和hls直播的優缺點:
A、三者的延遲性：
http-flv：低延遲，內容延遲可以做到2-5秒。
Rtmp：低延遲，內容延遲可以做到2-5秒。
Hls:：延遲較高。
B、三者的易用性:
rtmp和http-flv：播放端安裝率高。只要瀏覽器支持FlashPlayer就能非常簡易的播放。
hls：最大的優點：HTML5可以直接打開播放；這個意味著可以把一個直播鏈接通過微信
等轉發分享，不需要安裝任何獨立的APP，有瀏覽器即可。
C、rtmp和http-flv比較：
(1) 穿墻：很多防火墻會墻掉RTMP，但是不會墻HTTP，因此HTTP FLV出現奇怪問題的概率很小。
(2) 調度：RTMP也有個302，可惜是播放器as中支持的，HTTP FLV流就支持302方便CDN糾正DNS的錯誤。
(3) 容錯：SRS的HTTP FLV回源時可以回多個，和RTMP一樣，可以支持多級熱備。
(4) 簡單：FLV是最簡單的流媒體封裝，HTTP是最廣泛的協議，這兩個組合在一起維護性更高，比RTMP簡單多了。
三、http-flv技術實現:
HTTP協議中有個約定：content-length字段，http的body部分的長度
服務器回復http請求的時候如果有這個字段，客戶端就接收這個長度的數據然后就認為數據傳輸完成了，
如果服務器回復http請求中沒有這個字段，客戶端就一直接收數據，直到服務器跟客戶端的socket連接斷開。
http-flv直播就是利用第二個原理，服務器回復客戶端請求的時候不加content-length字段，在回復了http
內容之后，緊接著發送flv數據，客戶端就一直接收數據了。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
