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