整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
備管理健康系統，用于設備維護管理業務和狀態在線集中監測，以達到如下目的。
由于vlc不支持chrome瀏覽器 IE已經不再更新我們需要一種新的技術利用H5進行視頻直播推流。
項目以 海康攝像頭 為例子的RSTP流 可以用vlc軟件 測試視頻流是否正常 rtsp://admin:password@192.168.0.64:554
需要環境 node http-server ws FFmpeg jsmpeg
安裝
npm install http-server -g
在jsmpeg目錄下安裝
npm install ws
node websocket-relay.js password 8081 8082 （password為密碼）
在FFmpeg目錄下
ffmpeg -i "rtsp://admin:12345@192.168.2.10:554" -q 0 -f mpegts -codec:v mpeg1video -s 1366x768 http://127.0.0.1:8081/password （password為密碼）
查看效果打開jsmpeg文件夾里面的view-stream.html頁面。
該功能已經集成在智雨物聯云平臺使用方便簡單，達到快速搭建的效果。
服務名稱：測試環境服務器
IP：[請查看資源分配文檔]
操作系統：CentOS 6.8 x64
nginx下載
下載地址：nginx.org/en/download…
nginx-http-flv-module下載
下載地址：github.com/winshining/…
把nginx-1.16.1.tar.gz和nginx-http-flv-module-1.2.7.tar.gz，上傳到/opt/tools目錄下
創建nginx目錄
# mkdir /usr/local/nginx解壓nginx和nginx-flv
# cd /opt/tools
# tar -zxvf nginx-1.16.1.tar.gz
# tar -zxvf nginx-http-flv-module-1.2.7.tar.gz -C /usr/local/nginx/目錄改名
# cd /usr/local/nginx
# mv nginx-http-flv-module-1.2.7 nginx-http-flv-module安裝nginx所需依賴項
yum -y install gcc-c++
yum -y install pcre pcre-devel
yum -y install zlib zlib-devel
yum -y install openssl openssl-devel安裝nginx
# cd /opt/tools/nginx-1.16.1
# ./configure --prefix=/usr/local/nginx --add-module=/usr/local/nginx/nginx-http-flv-module
# make && make install修改配置文件
# cd /usr/local/nginx
# vi conf/nginx.conf修改為以下內容：
worker_processes 1;
events {
worker_connections 1024;
}
#rtmp配置
rtmp {
out_queue 4096;
out_cork 8;
max_streams 128;
server {
listen 1935;
application live {
live on;
record off;
gop_cache on;
}
}
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80; #nginx的端口，默認是80
server_name localhost;
location / {
root html;
index index.html index.htm;
}
#http-flv的配置
location /live {
flv_live on;
chunked_transfer_encoding on; #支持'Transfer-Encoding: chunked'方式回復
add_header 'Access-Control-Allow-Origin' '*'; #添加額外的HTTP頭
add_header 'Access-Control-Allow-Credentials' 'true'; #添加額外的HTTP頭
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}啟動80、1935端口
# vi /etc/sysconfig/iptables添加以下內容：
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT\
-A INPUT -m state --state NEW -m tcp -p tcp --dport 1935 -j ACCEPT重啟防火墻
# service iptables restart# /usr/local/nginx/sbin/nginx# /usr/local/nginx/sbin/nginx -s reload# /usr/local/nginx/sbin/nginx -s stop# curl http://localhost:80外網訪問地址結果：
C++音視頻學習資料免費獲取方法：關注音視頻開發T哥，點擊「鏈接」即可免費獲取2023年最新C++音視頻開發進階獨家免費學習大禮包！
服務名稱：測試環境服務器
IP：[請查看資源分配文檔]
操作系統：CentOS 6.8 x64
下載地址：www.ffmpeg.org/releases/
yasm
著互聯網行業的火爆發展，云計算行業也緊跟勢頭，進行快速發展階段。作為互聯網巨頭的網易也抓住此次機遇，對外推出了視頻云服務。在此前，網易視頻云（http://vcloud.163.com）服務已經廣泛運用于網易內部產品，比如網易BOBO，網易蜂巢，網易公開課等。4月6日，網易新聞客戶端和糗事百科合作進行的直播也是通過網易視頻云接入并進行直播。目前，網易視頻云服務的點播與直播功能均已上線，視頻云也廣泛應用于遠程醫療，在線教育，秀場直播、企業協作、遠程監控等領域。在此，網易視頻云的技術專家也給大家分享一些大家都關注的視頻技術內容，后期也會陸續分享，感興趣的朋友們也可以多關注網易視頻云官方網站，后期會推出更多的內容分享。
多媒體數據文件
一個完整的多媒體文件是由音頻和視頻兩部分組成的，H264、Xvid等就是視頻編碼格式，MP3、AAC等就是音頻編碼格式，字幕文件只是附加文件。目前大部分的播放器產品對于H.264 + AAC的MP4編碼格式支持最好，但是MP4也有很多的缺點，比如視頻header很大，影響在線視頻網站的初次加載時間。
為了降低頭部體積，需要進行視頻本身的物理分段等等。對MPEG2-TS格式視頻文件進行物理切片，分成一小段，這種方式被Apple公司的HTTP Live Streaming (HLS)技術采用。另外一種是使用Fragmented MP4文件格式，這是一種文件內部的邏輯分割方式，而視頻文件還是完整的，這種技術被Microsoft Smooth Streaming和Adobe HTTP Dynamic Streaming采用。很多在線視頻網站在帶寬耗費的壓力下，主要選擇的是adobe公司提供的FLV或F4V， FLV是流媒體封裝格式，可將其數據看為二進制字節流。總體上看，FLV包括文件頭（File Header）和文件體（File Body）兩部分，其中文件體由一系列的Tag及Tag Size對組成。
流媒體傳輸類型
流媒體在播放前不是完全下載整個文件，而是把開始部分內容存入內存，數據流是隨時傳送隨時播放。
流媒體服務器提供的流式傳輸方式有兩種：順序流式傳輸和實時流式傳輸兩種方式。
順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體。如果使用普通的HTTP服務器，將音視頻數據以從頭至尾方式發送，則為順序流媒體傳輸。實時流式傳輸總是實時傳送，特別適合現場事件。一般來說，如果視頻為現場直播，或使用專用的流媒體服務器，或應用如RTSP等專用實時協議，即為實時流媒體傳輸。實時流式傳輸必須匹配連接帶寬，這意味著圖像質量會因網絡速度降低而變差。
在流式傳輸時，流媒體數據具有實時性，等時性等基本特點，流服務期和客戶終端要保證各種媒體間的同步關系，因此，流媒體傳輸對“最大延時”，“延時抖動”等QoS參數都有嚴格要求。
實時流傳輸既可傳輸實況直播，也可傳輸完整的音視頻文件（專用協議流式）。
順序流媒體不可用于實況直播，僅能傳輸完整的音視頻文件（HTTP漸進式）。
| 區別 | 實時流 | 順序流 |
| 音視頻數據源 | 實時從錄制設備上采集，或（使用專用協議傳輸的）文件 | 可播放的音視頻文件 |
| 服務器類型 | 專用流媒體服務器，如：QuickTime Streaming ServerReal ServerWindows Media ServerFlash Media Server | 普通的HTTP服務器，或FTP服務器 |
| 傳輸協議 | 專用協議RTSP，HLS或RTMP等 | 一般的HTTP協議，與傳輸網頁的協議相同 |
| 跳播 | 可隨機訪問任意片段 | 在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的部分 |
主流的流媒體協議
主流的流媒體協議主要有： RTMP， HLS， RTSP等。
| 區別 | RTMP | HLS | RTSP |
| 全稱 | Real Time Message Protocol | Http Live Stream | Real Time Streaming Protocol |
| 上層協議 | TCP或HTTP | HTTP | RTP，RTCP |
| 軟件模型 | C\S | B\S | C\S |
| 研發主要來自 | Adobe | Apple | Microsoft |
| 針對客戶端 | 支持Flash類產品的瀏覽器支持HTML5的瀏覽器 | 蘋果的Safari瀏覽器支持HTML5的瀏覽器 | 播放器 |
| 視頻格式要求 | FLV， F4V | MP4 | 無 |
| 服務器要求 | 專用Flash服務器Flash Media ServerRed5 | 普通HTTP服務器 | 專用RTSP流媒體服務器 |
| 實況直播要求 | 專用編碼器上傳Flash Media Encoder | 專用編碼器上傳Apple開發工具 | 與服務器相關，自定義上傳 |
| 文件播放要求 | FLV ，F4V文件即可，服務器會自動分解為F4f 數據文件f4x索引文件 | TS數據文件，M3u8索引文件 | 與服務器相關，與播放器相關 |
流媒體協議原理
(一)HTTP漸進式下載原理（僅支持文件播放）
HTTP邊下載邊播放，嚴格意義上講，不是直播協議。他的原理是先下載文件的基本信息，音頻視頻的時間戳，再下載音視頻數據，以播放mp4為例，先下載文件頭，根據文件頭指引下載文件尾，然后再下載文件的音視頻數據。
播放方式：瀏覽器調用系統播放器播放；
使HTML5的Video標簽，瀏覽器支持直接播放。
(二)蘋果支持的HLS原理（實況直播、文件點播）
服務器端有三個組件：
其一：編碼器（media encoder）, 用于將設備輸出的格式轉為H264和AAC，并封裝為MPEG-2傳輸流；
其二：流分段器（stream segmenter）, 用于實況直播，將MPEG-2流分割為多個小片段后輸出；
其三：文件分段器（file segmenter）, 用于文件點播，將文件分隔為多個小片段后輸出；
分發原理
數據經以上三部分處理后為.ts文件（媒體數據）及.m3u8文件（媒體數據索引）存在于服務器之上。 客戶端訪問.m3u8后按索引下載.ts文件進行播放。
下面為某m3u8文件內容：
#EXTM3U
#EXT-X-TARGETDURATION:30
#EXTINF:30,
http://192.169.1.176/sample_100k-1.ts
#EXTINF:30,
http://192.169.1.176/sample_100k-2.ts
#EXTINF:30,
http://192.169.1.176/sample_100k-3.ts
#EXT-X-ENDLIST
根據這個文件，播放器會依次下載sample_100k-1.ts，sample_100k-2.ts，sample_100k-3.ts
HLS的文件點播
1.使用蘋果開發工具“文件分段器”將基于H264和AAC或MP3的MPEG4分段，
生成.ts和.m3u8文件，存儲于普通服務器上。
2.蘋果應用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數據片段來播放。
HLS的實況直播
1.使用蘋果開發工具“流分段器”將基于H264、AAC、MP3的MPEG2傳輸流分段，
可使用其它工具將MPEG4音視頻文件加載到MPEG2傳輸流當中。
生成.ts和.m3u8文件，存儲于普通服務器上。
2.蘋果應用程序或蘋果瀏覽器可以通過訪問.m3u8文件獲取到索引，并下載所需要的數據片段來播放。
(三)Adobe Flash支持的RTMP協議（支持文件播放 和 實況直播）
RTMP(Real Time Messaging Protocol)
是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸 開發的開放協議。
它有四種變種：
1)工作在TCP之上的明文協議，使用端口1935；
2)RTMPS通過TLS/SSL連接；
3)RTMPT封裝在HTTP請求之中，可穿越防火墻；
4)RTMPS類似RTMPT，但使用的是HTTPS連接；
RTMP協議(Real Time Messaging Protocol)是被Flash用于對象,視頻,音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器,這些數據既可以是AMF格式的數據,也可以是FLV中的視/音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的。
必須采用Flash服務器FMS(Flash Media Server) 或 RED5.
FMS的文件點播
1.服務器將F4v 或 Flv文件轉化為RTMP流或HTTP流
2.客戶端獲取RTMP流，提取相應的Flv 或 F4v文件片段進行播放。
FMS的實況直播
1.設備端將數據轉化為F4v片段，通過RTMP流上傳到服務器
2.服務器轉發RTMP流到客戶端
3.客戶端獲取RTMP流，提取數據片段播放。
(四)RTSP協議
該協議用于C/S模型，是一個基于文本的協議，用于在客戶端和服務器端建立和協商實時流會話。
實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在于控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發送機制提供方法。
實時流協議（RTSP）建立并控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流交換是可能的，通常它本身并不發送連續流。換言之，RTSP充當多媒體服務器的網絡遠程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對服務器的可傳輸連接以發出RTSP請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續媒體的傳輸機制。
協議支持的操作如下：
(1）從媒體服務器上檢索媒體：用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用于連續媒體的的組播地址和端口。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
(2）媒體服務器邀請進入會議：媒體服務器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程控制按鈕。
(3）將媒體加到現成講座中：如服務器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
下面區分幾種操作模式。
(1）單播：用戶選擇的端口號將媒體發送到RTSP請求源。
(2）服務器選擇地址多播：媒體服務器選擇多播地址和端口，這是現場直播或準點播常用的方式。
(3）用戶選擇地址多播：如服務器加入正在進行的多播會議，多播地址、端口和密鑰由會議描述給出。
RTSP控制通過單獨協議發送的數據流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體服務器沒有收到請求，數據也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，服務器需要維持能聯系流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義服務器流資源的分配與應用上起著重要的作用：
(1) SETUP：讓服務器給流分配資源，啟動RTSP連接。
(2) PLAY與RECORD：啟動SETUP分配流的數據傳輸。
(3) PAUSE：臨時停止流，而不釋放服務器資源。
(4) TEARDOWN：釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，服務器連接產生連接標識。
RTSP為純粹的傳輸控制協議。
RTSP協議本身不與它負載的媒體數據相關。
RTSP協議需要自定義客戶端向服務器發送RTSP命令。
流媒體服務器的協議棧
在TCP／IP參考模型中，傳輸層通信協議TCP和UDP都不能滿足流媒體傳輸的QoS要求。由于TCP協議采用滑動窗口控制機制，數據傳送隨著流控窗口動態的啟動和關閉，難以滿足流媒體實時和等時的傳送要求。UDP協議的無連接特點能夠提高傳輸速率，雖然可以在某種程度上滿足流媒體的實時性要求，但是由于其本身的不可靠性，也無法滿足流媒體傳輸的需要。
針對傳輸層協議的矛盾，為了實現流媒體在IP上的實時傳送播放，設計流媒體服務器時需要在傳輸層協議（TCP／UDP）和應用層之間增加一個通信控制層。在增加的通信控制層，采用相應的實時傳輸協議，主要有：數據流部分的實時傳輸協議RTP（Real－time Transport Protocol），用于控制部分的實時傳輸控制協議RTCP（Real－time Control Protocol）和實時流化協議RTSP（Real－time Streaming Protocol）。
流媒體服務器的協議棧，如圖1所示。
RTP協議主要是用來傳送實時的流媒體信息，數據報主要包括多媒體數據，以及所攜帶負載的時間戳，順序號等。
RTCP協議的數據報主要包括了接收者收到某個多媒體流的服務質量信息Qos，用于對服務器端的反饋。
RTSP是一種控制協議，包括通信連接前的設定，從服務器送出的多媒體資料的控制。用于控制具有實時性的數據傳輸。它提供對流媒體的類似VCR（Video Cassette Recorder）的控制功能，如播放、暫停、快進、錄制等，也就是RTSP對多媒體服務器實施網絡遠程控制。
流媒體服務器的功能框圖，如圖2所示。
當服務器收到RTSP請求，它首先產生RTSP請求對象。服務器通過RTSP協議的應答信息將請求的內容以流會話（streaming session）的形式描述，內容包括數據流包含多少個流、媒體類型、和編解碼格式。一個流會話由一個或多個數據流組成，如視頻流和音頻流等。實際的數據流通過RTP協議傳遞到客戶端。RTP在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP本身并不能為順序傳送數據包提供可靠的傳送機制，它依靠RTCP一起提供流量控制和擁塞控制服務。在RTP會話期間，各連接者監視下層網絡的性能，并將相關信息放入RTCP包，周期性地傳送RTCP包來通知發送方。發送方也可以用RTCP包提供每次的會話信息，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料。因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，因有效的反饋和最小的開銷使傳輸效率最佳化。
通過流媒體服務器的協議棧的設計，可以明確流媒體服務器是在傳輸層協議（TCP，UDP）上解釋RTP，RTCP，RTSP協議的，所有的客戶連接請求都是以TCP的端口獲得的，流媒體數據也都是打成RTP包，通過UDP端口發出去的，因此，對于TCP，UDP端口事件的調度以及如何把大量的流媒體數據從磁盤空間傳遞到網絡上成為制約流媒體服務器性能的主要因素。
傳統流媒體服務器的處理流程，如圖3所示。
流媒體服務器面對一個單一的客戶，完成的過程如下：
1）在客戶端發出RTSP連接請求后，服務器通過對TCP端口的監聽，讀入請求。
2）解析請求內容，調入相應的流媒體文件。
3）形成RTP包，分發數據流包，獲得RTCP包。
4）數據包發送完畢，關閉連接。
上圖是RTSP直播服務器的系統框圖。
從攝像頭采集實時圖像，送到編碼器進行實時編碼，一般是生成TS格式的數據流，然后數據流輸出到視頻直播服務器。客戶端先發送請求到web服務器，然后再重定向到RTSP視頻服務器，從視頻服務器讀取數據，同時實現播放，暫停等功能。
流媒體的傳輸技術
一、單播：
主機之間“一對一”的通訊模式，網絡中的交換機和路由器對數據只進行轉發不進行復制。如果10個客戶機需要相同的數據，則服務器需要逐一傳送，重復10次相同的工作。但由于其能夠針對每個客戶的及時響應，所以現在的網頁瀏覽全部都是采用IP單播協議。網絡中的路由器和交換機根據其目標地址選擇傳輸路徑，將IP單播數據傳送到其指定的目的地。
單播的優點：
1. 服務器及時響應客戶機的請求
2. 服務器針對每個客戶不通的請求發送不通的數據，容易實現個性化服務。
單播的缺點：
1. 服務器針對每個客戶機發送數據流，服務器流量＝客戶機數量×客戶機流量；在客戶數量大、每個客戶機流量大的流媒體應用中服務器不堪重負。
二、 廣播：
主機之間“一對所有”的通訊模式，網絡對其中每一臺主機發出的信號都進行無條件復制并轉發，所有主機都可以接收到所有信息（不管你是否需要），由于其不用路徑選擇，所以其網絡成本可以很低廉。在數據網絡中也允許廣播的存在，但其被限制在二層交換機的局域網范圍內，禁止廣播數據穿過路由器，防止廣播數據影響大面積的主機。
廣播的優點：
1. 網絡設備簡單，維護簡單，布網成本低廉
2. 由于服務器不用向每個客戶機單獨發送數據，所以服務器流量負載極低。
廣播的缺點：
1.無法針對每個客戶的要求和時間及時提供個性化服務。
2. 網絡允許服務器提供數據的帶寬有限，客戶端的最大帶寬＝服務總帶寬。
3. 廣播禁止在Internet寬帶網上傳輸。
三、組播：
主機之間“一對一組”的通訊模式，也就是加入了同一個組的主機可以接受到此組內的所有數據，網絡中的交換機和路由器只向有需求者復制并轉發其所需數據。主機可以向路由器請求加入或退出某個組，網絡中的路由器和交換機有選擇的復制并傳輸數據，即只將組內數據傳輸給那些加入組的主機。這樣既能一次將數據傳輸給多個有需要（加入組）的主機，又能保證不影響其他不需要（未加入組）的主機的其他通訊。
組播的優點：
1. 需要相同數據流的客戶端加入相同的組共享一條數據流，節省了服務器的負載。具備廣播所具備的優點。
2. 由于組播協議是根據接受者的需要對數據流進行復制轉發，所以服務端的服務總帶寬不受客戶接入端帶寬的限制。
3. 此協議和單播協議一樣允許在Internet寬帶網上傳輸。
組播的缺點：
1．與單播協議相比沒有糾錯機制，發生丟包錯包后難以彌補，但可以通過一定的容錯機制和QOS加以彌補。
2．現行網絡雖然都支持組播的傳輸，但在客戶認證、QOS等方面還需要完善，這些缺點在理論上都有成熟的解決方案，只是需要逐步推廣應用到現存網絡當中。
自適性串流技術
自適性串流（ABS - adaptive bitrate streaming），是一種在電腦網絡使用的一種串流技術。過去的流媒體技術多使用 RTP/RTSP，但現在的技術則大多基于 HTTP，并為更高效在大型分布式HTTP網絡（例如互聯網）分發而設計。
此技術根據實時檢測的用戶的帶寬和CPU使用率，調整視頻流的質量。這需要使用一種可以將單一視頻源輸出為多碼率的編碼器。播放器客戶端依賴可用資源在不同碼率的流之間切換。"結果就是：更少緩存、更快的開始播放、為低端和高端鏈接都提供良好的體驗。
根據當前廣泛使用的實現，更具體來說，自適應串流（ABS）：
使用 HTTP 傳送視頻流；
使用多碼率編碼源內容；
每個單碼率的流被切成小的，幾秒鐘的小切片；
流媒體客戶端首先獲取所有碼率的切片索引信息。一開始，客戶端先請求最低碼率的串流。如果客戶端判斷下載速度比當前碼率的切片串流快，它就去請求下一個更高碼率的串流。隨著播放的進行，如果客戶端發現下載速度比當前碼率的切片串流慢，轉而請求下一個較低碼率的串流。
切片大小和具體實現密切相關，不過一般都在2～10秒之間。每個切片由一個完整的GOP序列組成，一個GOP序列里面有1個或者多個I幀，GOP序列的第一個幀必須是I幀，并且每個切片都能單獨的解碼播放顯示。
與傳統的流媒體技術比較，缺點：需要額外的存儲，更多的編碼代價，復雜的只適應碼率邏輯。
Adaptive streaming overview
Adaptive streaming in action
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
MPEG-DASH 是基于HTTP的自適應串流方案中的唯一國際標準。MPEG-DASH 技術由 MPEG 主導開發：
2010年開始DASH相關工作，2011年1月成為國際標準草案，2011年11月成為國際標準[3]，2012年4月，MPEG-DASH 以ISO/IEC 23009-1:2012 發表。
MPEG-DASH 基于3GPP第9版的 Adptive HTTP streaming（AHS）和 Open IPTV Forum第2版的 HTTP Adaptive Streaming (HAS)。作為與MPEG合作的一部分，3GPP第10版采用了DASH（采用特別的編碼和操作模式），用于無線網絡。
可用的 MPEG-DASH 實現有：
bitmovin GmbH 的開源 DASH 客戶端庫 libdash 和 DASHEncoder
Adobe HDS (HTTP Dynamic Streaming)
Flash Player 和 Flash Media Server 的最新版支持傳統的 RTMP 協議和 HTTP協議。后者和Apple和微軟基于HTTP的方案類似。
基于HTTP的流的優勢是：
不需要防火墻開普通web瀏覽器所需端口以外的任何端口
允許視頻切片在瀏覽器、網關和CDN的緩存，從而顯著降低源服務器的負載。
HDS 的文件格式為 FLV/F4V/MP4，索引文件為 f4m，同時支持直播和時移。
Apple HLS (HTTP Live Streaming)
是一種基于HTTP的媒體流通信協議，在 iPhone 3.0 及更新版中成為標準功能。
2010年10月，所有自適應串流方案都作為產權提供時，Apple 將HLS提交到 IETF，成為正式的 RFC.
HLS 串流使用擴展名為 .m3u8 的文件作為索引，文件切片格式為TS，支持直播和時移。支持的客戶端包括 iPad, iPhone, STB，VLC和其他支持的設備。
Microsoft MSS (Microsoft Smooth Streaming)
Smooth Streaming 是IIS的媒體服務擴展，用于支持基于HTTP的自適應串流。
在2010年11月發布的 IIS Media Services 4.0 中，微軟引入了一項使 Live Smooth Streaming H.264/AAC 視頻動態封裝成 Apple HLS 格式的功能，直接提供給 iOS 設備，而不需要再次編碼。同時支持直播和點播把1080P全高清視頻發送到Silverlight客戶端。
MSS 的文件切片格式為 mp4（fragmented-mp4），索引文件為ism/ismc，同時支持直播和時移。
流行視頻網站的流媒體服務器架構
為了能夠提供各類設備的在線視頻播放需求，對于在線視頻流媒體服務，提出了很多需求，對于早期建立的視頻網站（土豆，優酷，ku6等）都只提供一種視頻流媒體格式（FLV）的支持，我們稱之為單一的流媒體服務架構，如圖：
圖1 ：單一流媒體服務的架構圖
但是，在實際業務運營中遇到了很多問題：
1） 視頻存儲的壓力很大
同一種視頻碼流（h.264）,因為針對不同平臺應用設備（如表2）的播放需求，需要不同的封裝格式，需要將產生大量重復視頻流存儲的壓力，視頻網站的視頻量巨大，多支持一種格式將產生幾百TB級的存儲壓力，從機房到機柜，視頻流同步等環節負載和壓力都是巨大的。
2） 封裝后的視頻格式是否真的被播放
視頻流封裝完成后，同步到各地的中心節點后，是否真的有視頻流請求產生，還是僅僅處于視頻準備狀態，是否會影響中心節點的磁盤占用，緩存節點的命中率不高。
3） 封裝格式的功能性升級，導致老視頻再次封裝
封裝格式的不斷發展，TS流，HTTP live Stream的不斷優化，將導致現有的視頻流不斷需要翻新或重復封裝。 為了解決上述各類問題，視頻網站流媒體服務的研發工程師進行了多格式的流媒體服務架構探索，提供了各類視頻封裝格式的流媒體封裝反向代理接口，該接口能夠通過URL的請求，完成對特定視頻編碼格式（h.264）的封裝。
圖2：多格式的流媒體服務架構：
如圖所示，“流媒體容器封裝服務“成為多格式視頻流服務的核心，對于這個流媒體的封裝服務，通過對h.264的視頻編碼流進行不同格式的封裝，提供了多種視頻流的推送。對于這個服務，我們希望能夠盡快為視頻的cache服務推送視頻流，所以，在硬盤方面，選擇了每分鐘15000轉的SAS硬盤，降低同一視頻流的不同封裝請求的IO延遲等待。
作為最簡單和原始的流媒體解決方案，單一流媒體服務架構唯一顯著的優點在于它僅需要維護一個標準的視頻流文件，而這樣的服務器基礎設施在互聯網中已經普遍存在，其安裝和維護的工作量和復雜性比起多格式流媒體服務架構來說要簡單和容易的多。然而其缺點和不足卻也很多，首先是維護的工作量較大，多份相同視頻文件由于封裝格式不相同，需要同時維護多個實體的碼流文件，大量的占用磁盤的空間，再次，轉碼集群需要針對多種不同的封裝格式，進行多次的視頻轉碼，搶占很多資源，缺乏靈活的控制功能和擴展機制。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
