本文關(guān)鍵詞：流媒體，由筆耕文化傳播整理發(fā)布。

一些關(guān)于流媒體的基本概念

目錄 [hide]

ASF是（Advanced Streaming Format 高級串流格式）的縮寫，是 Microsoft 為 Windows 98 所開發(fā)的串流多媒體文件格式。ASF是微軟公司W(wǎng)indows Media的核心。這是一種包含音頻、視頻、圖像以及控制命令腳本的數(shù)據(jù)格式。這個(gè)詞匯當(dāng)前可和 WMA 及 WMV 互換使用。
ASF是一個(gè)開放標(biāo)準(zhǔn)，它能依靠多種協(xié)議在多種網(wǎng)絡(luò)環(huán)境下支持?jǐn)?shù)據(jù)的傳送。同JPG、MPG文件一樣，ASF文件也是一種文件類型，但它是專為在IP網(wǎng)上傳送有同步關(guān)系的多媒體數(shù)據(jù)而設(shè)計(jì)的，所以ASF格式的信息特別適合在IP網(wǎng)上傳輸。ASF文件的內(nèi)容既可以是我們熟悉的普通文件，也可以是一個(gè)由編碼設(shè)備實(shí)時(shí)生成的連續(xù)的數(shù)據(jù)流，所以ASF既可以傳送人們事先錄制好的節(jié)目，也可以傳送實(shí)時(shí)產(chǎn)生的節(jié)目。
ASF用于排列、組織、同步多媒體數(shù)據(jù)以利于通過網(wǎng)絡(luò)傳輸。ASF是一種數(shù)據(jù)格式，它也可用于指定實(shí)況演示。ASF最適于通過網(wǎng)絡(luò)發(fā)送多媒體流，也同樣適于在本地播放。任何壓縮/解壓縮運(yùn)算法則（編解碼器）都可用來編碼ASF流。
Windows Media Service的核心是ASF。ASF是一種數(shù)據(jù)格式，音頻、視頻、圖像以及控制命令腳本等多媒體信息通過這種格式，以網(wǎng)絡(luò)數(shù)據(jù)包的形式傳輸，實(shí)現(xiàn)流式多媒體內(nèi)容發(fā)布。其中，在網(wǎng)絡(luò)上傳輸?shù)膬?nèi)容就稱為ASF Stream。ASF支持任意的壓縮/解壓縮編碼方式，并可以使用任何一種底層網(wǎng)絡(luò)傳輸協(xié)議，具有很大的靈活性。
Microsoft Media player是能播放幾乎所有多媒體文件的播放器，支持ASF在Internet網(wǎng)上的流文件格式，可以一邊下載一邊實(shí)時(shí)播放，無需下載完再聽。
ASF流文件的數(shù)據(jù)速率可以在28.8Kbps到3Mbps之間變化。用戶可以根據(jù)自己應(yīng)用環(huán)境和網(wǎng)絡(luò)條件選擇一個(gè)合適的速率，實(shí)現(xiàn)VOD點(diǎn)播和直播。

FLV 是FLASH VIDEO的簡稱，F(xiàn)LV流媒體格式是隨著Flash MX的推出發(fā)展而來的視頻格式。由于它形成的文件極小、加載速度極快，使得網(wǎng)絡(luò)觀看視頻文件成為可能，它的出現(xiàn)有效地解決了視頻文件導(dǎo)入Flash后，使導(dǎo)出的SWF文件體積龐大，不能在網(wǎng)絡(luò)上很好的使用等缺點(diǎn)。
FLV是被眾多新一代視頻分享網(wǎng)站所采用，是目前增長最快、最為廣泛的視頻傳播格式。是在sorenson公司的壓縮算法的基礎(chǔ)上開發(fā)出來的。FLV格式不僅可以輕松的導(dǎo)入Flash中，速度極快，并且能起到保護(hù)版權(quán)的作用，并且可以不通過本地的微軟或者REAL播放器播放視頻。

H.264，同時(shí)也是MPEG-4第十部分，是由ITU-T視頻編碼專家組（VCEG）和ISO/IEC動(dòng)態(tài)圖像專家組（MPEG）聯(lián)合組成的聯(lián)合視頻組（JVT，Joint Video Team）提出的高度壓縮數(shù)字視頻編解碼器標(biāo)準(zhǔn)。H.264是ITU-T以H.26x系列為名稱命名的標(biāo)準(zhǔn)之一，同時(shí)AVC是ISO/IEC MPEG一方的稱呼。這個(gè)標(biāo)準(zhǔn)通常被稱之為H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）而明確的說明它兩方面的開發(fā)者。該標(biāo)準(zhǔn)最早來自于ITU-T的稱之為H.26L的項(xiàng)目的開發(fā)。H.26L這個(gè)名稱雖然不太常見，但是一直被使用著。該標(biāo)準(zhǔn)第一版的最終草案于2003年5月完成。
H.264是國際標(biāo)準(zhǔn)化組織（ISO）和國際電信聯(lián)盟（ITU）共同提出的繼MPEG4之后的新一代數(shù)字視頻壓縮格式，它既保留了以往壓縮技術(shù)的優(yōu)點(diǎn)和精華又具有其他壓縮技術(shù)無法比擬的許多優(yōu)點(diǎn)。
1．低碼率（Low Bit Rate）：和MPEG2和MPEG4 ASP等壓縮技術(shù)相比，在同等圖像質(zhì)量下，采用H.264技術(shù)壓縮后的數(shù)據(jù)量只有MPEG2的1/8，MPEG4的1/3。
顯然，H.264壓縮技術(shù)的采用將大大節(jié)省用戶的下載時(shí)間和數(shù)據(jù)流量收費(fèi)。
2．高質(zhì)量的圖象：H.264能提供連續(xù)、流暢的高質(zhì)量圖象（DVD質(zhì)量）。
3．容錯(cuò)能力強(qiáng)：H.264提供了解決在不穩(wěn)定網(wǎng)絡(luò)環(huán)境下容易發(fā)生的丟包等錯(cuò)誤的必要工具。
4．網(wǎng)絡(luò)適應(yīng)性強(qiáng)：H.264提供了網(wǎng)絡(luò)抽象層（Network Abstraction Layer），使得H.264的文件能容易地在不同網(wǎng)絡(luò)上傳輸（例如互聯(lián)網(wǎng)，CDMA，GPRS，WCDMA，CDMA2000等）。
H.264最大的優(yōu)勢是具有很高的數(shù)據(jù)壓縮比率，在同等圖像質(zhì)量的條件下，H.264的壓縮比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。舉個(gè)例子，原始文件的大小如果為88GB，采用MPEG-2壓縮標(biāo)準(zhǔn)壓縮后變成3.5GB，壓縮比為25∶1，而采用H.264壓縮標(biāo)準(zhǔn)壓縮后變?yōu)?79MB，從88GB到879MB，H.264的壓縮比達(dá)到驚人的102∶1。低碼率（Low Bit Rate）對H.264的高的壓縮比起到了重要的作用，和MPEG-2和MPEG-4 ASP等壓縮技術(shù)相比，H.264壓縮技術(shù)將大大節(jié)省用戶的下載時(shí)間和數(shù)據(jù)流量收費(fèi)。尤其值得一提的是，H.264在具有高壓縮比的同時(shí)還擁有高質(zhì)量流暢的圖像，正因?yàn)槿绱�，�?jīng)過H.264壓縮的視頻數(shù)據(jù)，在網(wǎng)絡(luò)傳輸過程中所需要的帶寬更少，也更加經(jīng)濟(jì)。

x264是一個(gè)開源的H.264視頻編碼函數(shù)庫。是最好的有損視頻編碼器。
x264始于2003年，從當(dāng)開源社區(qū)的MPEG4-ASP編碼器Xvid小有所成時(shí)開始的，經(jīng)過幾年的開發(fā)，特別是Dark Shikari加入開發(fā)后，x264逐漸成為了最好的視頻編碼器。

FFM and FFM2 are formats used by ffserver. They allow storing a wide variety of video and audio streams and encoding options, and can store a moving time segment of an infinite movie or a whole movie.
FFM is version specific, and there is limited compatibility of FFM files generated by one version of ffmpeg/ffserver and another version of ffmpeg/ffserver. It may work but it is not guaranteed to work.
FFM2 is extensible while maintaining compatibility and should work between differing versions of tools. FFM2 is the default.

AVI英文全稱為Audio Video Interleaved，即音頻視頻交錯(cuò)格式。是將語音和影像同步組合在一起的文件格式。它對視頻文件采用了一種有損壓縮方式，但壓縮比較高，因此盡管畫面質(zhì)量不是太好，但其應(yīng)用范圍仍然非常廣泛。AVI支持256色和RLE壓縮。AVI信息主要應(yīng)用在多媒體光盤上，用來保存電視、電影等各種影像信息。
它于1992年被Microsoft公司推出，隨Windows3.1一起被人們所認(rèn)識和熟知。所謂“音頻視頻交錯(cuò)”，就是可以將視頻和音頻交織在一起進(jìn)行同步播放。這種視頻格式的優(yōu)點(diǎn)是可以跨多個(gè)平臺使用，其缺點(diǎn)是體積過于龐大，而且更加糟糕的是壓縮標(biāo)準(zhǔn)不統(tǒng)一，最普遍的現(xiàn)象就是高版本W(wǎng)indows媒體播放器播放不了采用早期編碼編輯的AⅥ格式視頻，而低版本W(wǎng)indows媒體播放器又播放不了采用最新編碼編輯的AⅥ格式視頻，所以我們在進(jìn)行一些AⅥ格式的視頻播放時(shí)常會出現(xiàn)由于視頻編碼問題而造成的視頻不能播放或即使能夠播放，但存在不能調(diào)節(jié)播放進(jìn)度和播放時(shí)只有聲音沒有圖像等一些莫名其妙的問題，如果用戶在進(jìn)行AⅥ格式的視頻播放時(shí)遇到了這些問題，可以通過下載相應(yīng)的解碼器來解決。是目前視頻文件的主流。這種格式的文件隨處可見，比如一些游戲、教育軟件的片頭，多媒體光盤中，都會有不少的AVI。

RTSP（Real Time Streaming Protocol），實(shí)時(shí)流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議，由哥倫比亞大學(xué)、網(wǎng)景和RealNetworks公司提交的IETF RFC標(biāo)準(zhǔn)。該協(xié)議定義了一對多應(yīng)用程序如何有效地通過IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。RTSP在體系結(jié)構(gòu)上位于RTP和RTCP之上，它使用TCP或RTP完成數(shù)據(jù)傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTSP傳送的是多媒體數(shù)據(jù)。HTTP請求由客戶機(jī)發(fā)出，服務(wù)器作出響應(yīng)；使用RTSP時(shí)，客戶機(jī)和服務(wù)器都可以發(fā)出請求，即RTSP可以是雙向的。
RTSP是用來控制聲音或影像的多媒體串流協(xié)議，并允許同時(shí)多個(gè)串流需求控制，傳輸時(shí)所用的網(wǎng)絡(luò)通訊協(xié)定并不在其定義的范圍內(nèi)，服務(wù)器端可以自行選擇使用TCP或UDP來傳送串流內(nèi)容，它的語法和運(yùn)作跟HTTP 1.1類似，但并不特別強(qiáng)調(diào)時(shí)間同步，所以比較能容忍網(wǎng)絡(luò)延遲。而前面提到的允許同時(shí)多個(gè)串流需求控制（Multicast），除了可以降低服務(wù)器端的網(wǎng)絡(luò)用量，更進(jìn)而支持多方視訊會議（Video Conference）。因?yàn)榕cHTTP1.1的運(yùn)作方式相似，所以代理服務(wù)器〈Proxy〉的快取功能〈Cache〉也同樣適用于RTSP，并因RTSP具有重新導(dǎo)向功能，可視實(shí)際負(fù)載情況來轉(zhuǎn)換提供服務(wù)的服務(wù)器，以避免過大的負(fù)載集中于同一服務(wù)器而造成延遲。
該協(xié)議用于C/S模型，是一個(gè)基于文本的協(xié)議，用于在客戶端和服務(wù)器端建立和協(xié)商實(shí)時(shí)流會話。
實(shí)時(shí)流協(xié)議（RTSP）是應(yīng)用級協(xié)議，控制實(shí)時(shí)數(shù)據(jù)的發(fā)送。RTSP提供了一個(gè)可擴(kuò)展框架，，使實(shí)時(shí)數(shù)據(jù)，如音頻與視頻的受控點(diǎn)播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中數(shù)據(jù)。該協(xié)議目的在于控制多個(gè)數(shù)據(jù)發(fā)送連接，為選擇發(fā)送通道，如UDP、組播UDP與TCP，提供途徑，并為選擇基于RTP上發(fā)送機(jī)制提供方法。
實(shí)時(shí)流協(xié)議（RTSP）建立并控制一個(gè)或幾個(gè)時(shí)間同步的連續(xù)流媒體。盡管連續(xù)媒體流與控制流交換是可能的，通常它本身并不發(fā)送連續(xù)流。換言之，RTSP充當(dāng)多媒體服務(wù)器的網(wǎng)絡(luò)遠(yuǎn)程控制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關(guān)閉多個(gè)對服務(wù)器的可傳輸連接以發(fā)出RTSP請求。此外，可使用無連接傳輸協(xié)議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依賴用于攜帶連續(xù)媒體的傳輸機(jī)制。

RTP（Real-time Transport Protocol，實(shí)時(shí)傳輸協(xié)議）是一個(gè)網(wǎng)絡(luò)傳輸協(xié)議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的，后在RFC3550中進(jìn)行更新。
國際電信聯(lián)盟ITU-T也發(fā)布了自己的RTP文檔，作為H.225.0，但是后來當(dāng)IETF發(fā)布了關(guān)于它的穩(wěn)定的標(biāo)準(zhǔn)RFC后就被取消了。它作為因特網(wǎng)標(biāo)準(zhǔn)在RFC 3550（該文檔的舊版本是RFC 1889）有詳細(xì)說明。RFC 3551（STD 65，舊版本是RFC 1890）詳細(xì)描述了使用最小控制的音頻和視頻會議。
RTP協(xié)議詳細(xì)說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。它一開始被設(shè)計(jì)為一個(gè)多播協(xié)議，但后來被用在很多單播應(yīng)用中。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTSP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是建立在用戶數(shù)據(jù)報(bào)協(xié)議上的。
實(shí)時(shí)傳輸協(xié)議（RTP）為數(shù)據(jù)提供了具有實(shí)時(shí)特征的端對端傳送服務(wù)，如在組播或單播網(wǎng)絡(luò)服務(wù)下的交互式視頻音頻或模擬數(shù)據(jù)。應(yīng)用程序通常在 UDP 上運(yùn)行 RTP 以便使用其多路結(jié)點(diǎn)和校驗(yàn)服務(wù)；這兩種協(xié)議都提供了傳輸層協(xié)議的功能。但是 RTP 可以與其它適合的底層網(wǎng)絡(luò)或傳輸協(xié)議一起使用。如果底層網(wǎng)絡(luò)提供組播方式，那么 RTP 可以使用該組播表傳輸數(shù)據(jù)到多個(gè)目的地。
RTP 本身并沒有提供按時(shí)發(fā)送機(jī)制或其它服務(wù)質(zhì)量（QoS）保證，它依賴于低層服務(wù)去實(shí)現(xiàn)這一過程。 RTP 并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡(luò)的可靠性。 RTP 實(shí)行有序傳送， RTP 中的序列號允許接收方重組發(fā)送方的包序列，同時(shí)序列號也能用于決定適當(dāng)?shù)陌恢�，例如：在視頻解碼中，就不需要順序解碼。
RTP 由兩個(gè)緊密鏈接部分組成：
RTP  傳送具有實(shí)時(shí)屬性的數(shù)據(jù)；

Microsoft Media Server (MMS), a Microsoft proprietary network-streaming protocol, serves to transfer unicast data in Windows Media Services (previously called NetShow Services). MMS can be transported via UDP or TCP. The MMS default port is UDP/TCP 1755.
Microsoft deprecated MMS in favor of RTSP (TCP/UDP port 554) in 2003 with the release of the Windows Media Services 9 Series, but continued to support the MMS for some time in the interest of backwards compatibility. Support for the protocol was finally dropped in Windows Media Services 2008.
As of 2012 Microsoft still recommends[1] using “mms://” as a “protocol rollover URL”. As part of protocol rollover a Windows Media Player version 9, 10, or 11 client opening an “mms://” URL will attempt to connect first with RTSP over UDP and if that fails it will attempt RTSP over TCP. After an RTSP attempt fails, Windows Media Player versions 9 & 10 will attempt MMS over UDP, then MMS over TCP. If using Windows Media Player 11 and an RTSP attempt fails, or if using a previous version of Windows Media Player and MMS fails, a modified version of a HTTP over TCP connection will be attempted. This modified version is referred to by some third parties as MMSH, and by Microsoft as MS-WMSP (Windows Media HTTP Streaming Protocol). The URI scheme “mms://” has also been proposed to be used for the unrelated Multimedia Messaging Service (MMS) protocol.
For several years developers of the SDP Multimedia download-tool reverse-engineered the MMS protocol and published unofficial documentation for it. However, Microsoft finally released the protocol specification in February 2008.

MMS is a proprietary digital media streaming protocol developed by Microsoft.
It is supported in Windows Media Player and Microsoft® Windows® Media Server v4.0 or later. MMSH is MMS over HTTP.

ref:
ref:
ref:
ref:
ref:?fromId=403562
ref:%E4%BD%BF%E7%94%A8%E4%BB%8B%E7%BB%8D
ref:
ref:#What-is-FFM_002c-FFM2
ref:
ref:#sub7572724

posted on

  本文關(guān)鍵詞：流媒體，由筆耕文化傳播整理發(fā)布。