三大流媒體協議
① 流媒體用的是什麼協議
流媒體的傳輸協議
大家在觀看網上電影或者電視時，一般都會注意到這些文件的連接都不是用http或者ftp開頭，而是一些rtsp或者mms開頭的東西，為什麼是這樣呢？實際上，這些和http和ftp一樣，都是數據在網路上傳輸的協議，只是它們是專門用來傳輸流式媒體的協議而已。下面，讓我們來看一下現在使用的主要的流媒體協議：1. RTSP（Real Time Streaming Protocol），實時流媒體協議，它是由RealNetworks和Netscape共同提出的，現在用於RealNetworks的Real Media產品中；
2. PNM（Progressive Networks Audio），這也是Real專用的實時傳輸協議，它一般採用UDP協議，並佔用7070埠，但當你的伺服器在防火牆內且7070埠被擋，且你的伺服器把SmartingNetwork設為真時，則採用http協議，並佔用默認的80埠；
3. MMS（Microsoft Media Server protocol），這是微軟的流媒體伺服器協議，MMS 是連接 Windows Media 單播服務的默認方法。
介紹了主要的三個，可能您還會問，Apple的QuickTime使用哪種協議呢？在多數情況下，QuickTime使用http協議，但實際上它也由標準的流媒體傳輸協議，這就是標准RTSP協議，而Real公司使用的RTSP是自己經過開發的。
在流媒體傳輸中，標準的協議就是RTP（Real time Transport Protocol，實時傳輸協議）、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議)、RTSP（Real Time Streaming Protocol，實時流媒體協議）和RSVP（Resource Reserve Protocol, 資源預訂協議），廠商們的產品都是在這些協議的基礎上進行研究與開發，限於篇幅，在這里我們就不再深入討論了。
② 視頻直播軟體開發中常用的流媒體傳輸協議有哪些
視頻直播軟體系統開發，常用的流媒體傳輸協議有RTMP,RTSP,HLS,HTTP-FLV
RTMP:(可用於推流端和拉流端) Real Time Messaging Protocol 實時消息傳輸協議，RTMP協議中，視頻必須是H264編碼，音頻必須是AAC或MP3編碼，且多以flv格式封包。因為RTMP協議傳輸的基本是FLV格式的流文件，必須使用flash播放器才能播放.
RTSP:(用於推流端) Real-Time Stream Protocol，RTSP 實時效果非常好，適合視頻聊天、視頻監控等方向
HLS(用於拉流端) Http Live Streaming，由Apple公司定義的基於HTTP的流媒體實時傳輸協議。傳輸內容包括兩部分：1.M3U8描述文件，2.TS媒體文件。TS媒體文件中的視頻必須是H264編碼，音頻必須是AAC或MP3編碼。數據通過HTTP協議傳輸。目前video.js庫支持該格式文件的播放
HTTP-FLV(用於拉流端) 本協議就是http+flv,將音視頻數據封裝成FLV格式,然後通過http協議傳輸到客戶端,這個協議大大方便了瀏覽器客戶端播放直播視頻流.目前flv.js庫支持該格式的文件播放
③ 流媒體一般需要遵循哪些協議有沒有誰做過RTSP實時播放的流媒體客戶端
一般有RTSP,RTP/RTCP,RSVP等協議，物盟視訊在流媒體方面做的很成熟了，他們有免費的客戶端下載，專可以下下來試試，支持RTSP實時屬播放，具體協議參考：http://www.douban.com/note/273475058/
④ 什麼是流媒體播放協議
流媒體技術基礎-流媒體傳輸協議
作者/來源：未知
實時傳輸協議RTP與RTCP
RTP（Real-timeTransportProtocol）是用於Internet上針對多媒體數據流的一種傳輸協議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。RTP通常使用UDP來傳送數據，但RTP也可以在TCP或ATM等其他協議之上工作。當應用程序開始一個RTP會話時將使用兩個埠：一個給RTP，一個給RTCP。RTP本身並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP演算法並不作為一個獨立的網路層來實現，而是作為應用程序代碼的一部分。實時傳輸控制協議RTCP。RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，伺服器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。
6.2.1 RTP數據傳輸協議
RTP提供端對端網路傳輸功能，適合通過組播和點播傳送實時數據，如視頻、音頻和模擬數據。RTP沒有涉及資源預訂和質量保證等實時服務，RTCP擴充數據傳輸以允許監控數據傳送，提供最小的控制和識別功能。RTP與RTCP設計成獨立傳輸和網路層。
2.1.1 RTP固定頭
RTP 頭格式如下：
-----------------------------------------------------------------------------------------------
|V=2|P|X| CC |M| PT | 系列號 |
-----------------------------------------------------------------------------------------------
| 時標 |
-----------------------------------------------------------------------------------------------
| 同步源標識(SSRC) |
-----------------------------------------------------------------------------------------------
| 作用標識 (CSRC) |
| .... |
-----------------------------------------------------------------------------------------------
開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。
2.1.2 復用 RTP 連接
為使協議有效運行，復用點數目應減至最小。RTP中，復用由定義RTP連接的目的傳輸地址（網路地址與埠號）提供。例如，對音頻和視頻單獨編碼的遠程會議，每個媒介被攜帶在單獨RTP連接中，具有各自的目的傳輸地址。目標不在將音頻和視頻放在單一RTP連接中，而根據SSRC段載荷類型進行多路分解。使用同一SSRC ，而具有不同載荷類型的交叉包將帶來幾個問題：
如一種載荷類型在連接期間切換，沒有辦法識別新值將替換那一個舊值。
SSRC定義成用於標識單個計時和系列號空間。如媒體時鍾速率不同，而要求不同系列號空間以說明那種載荷類型有丟包，交叉復用載荷類型將需要不同計時空間。
RTCP發送和接收報告可能僅描述每個SSRC的計時和系列號空間，而不攜帶載荷類型段。
RTP混合器不能將不兼容媒體流合並成一個流。
在一個RTP連接中攜帶多個媒介阻止幾件事：使用不同網路路徑或網路資源分配；接受媒介子集。
對每種媒介使用不同SSRC，但以相同RTP連接發送可避免前三個問題，但不能避免後兩個問題。
2.1.3 對RTP頭特定設置的修改
可以認為，現用RTP數據包頭對RTP支持的所有應用類共同需要的功能集是完整的。然而，為維持ALF設計原則，頭可通過改變或增加設置來裁剪，並仍允許設置無關監控和記錄工具起作用。標記位與載荷類型段攜帶特定設置信息，但由於很多應用需要它們，否則要容納它們，就要增加另外32位字，故允許分配在固定頭中。包含這些段的八進制可通過設置重新定義以適應不同要求，如採用更多或更少標記位。如有標記位，既然設置無關監控器能觀察包丟失模式和標記位間關系，我們就可以定位八進制中最重要的位。
其它特殊載荷格式（視頻編碼）所要求的信息應該攜帶在包的載荷部分。可出現在頭，總是在載荷部分開始處，或在數據模式的保留值中指出。如特殊應用類需要獨立載荷格式的附加功能，應用運行的設置應該定義附加固定段跟隨在現存固定頭SSRC之後。這些應用將能迅速而直接訪問附加段，同時，與監控器和記錄器無關設置仍能通過僅解釋開始12個八進制處理RTP包。如證實附加功能是所有設置共同需要的，新版本RTP應該對固定頭作出明確改變
6.2.2 RTP控制協議-- RTCP
RTCP協議將控制包周期發送給所有連接者，應用與數據包相同的分布機制。低層協議提供數據與控制包的復用，如使用單獨的UDP埠號。RTCP執行下列四大功能：
主要是提供數據發布的質量反饋。是作為RTP傳輸協議的一部分，與其他傳輸協議的流和阻塞控制有關。反饋對自適應編碼控制直接起作用，但IP組播經驗表明，從發送者收到反饋對診斷發送錯誤是致關重要的。給所有參加者發送接收反饋報告允許問題觀察者估計那些問題是局部的，還是全局的。諸如IP組播等發布機制使網路服務提供商類團體可能接收反饋信息，充當第三方監控者來診斷網路問題。反饋功能由RTCP發送者和接收者報告執行。
RTCP帶有稱作規范名字（CNAME）的RTP源持久傳輸層標識。如發現沖突，或程序重新啟動，既然SSRC標識可改變，接收者需要CNAME跟蹤參加者。接收者也需要CNAME 與相關RTP連接中給定的幾個數據流聯系
前兩種功能要求所有參加者發送RTCP包，因此，為了RTP擴展到大規模數量，速率必須受到控制。讓每個參加者給其它參加者發送控制包，就大獨立觀察參加者數量。該數量用語計算包發送的速率。
第四個可選功能是傳送最小連接控制信息，如參加者辨識。最可能用在\"鬆散控制\"連接，那裡參加者自由進入或離開，沒有成員控制或參數協調，RTCP充當通往所有參加者的方便通道，但不必支持應用的所有控制通訊要求。高級連接控制協議超出本書范圍。
在IP組播場合應用RTP時，前3個功能是必須的，推薦用於所有情形。RTP應用設計人員必須避免使用僅在單播模式下工作的機制，那將導致無法擴展規模。
6.2.2.1 RTCP 包格式
下面定義幾個攜帶不同控制信息的RTCP包類型：
SR：
發送報告，當前活動發送者發送、接收統計。
RR：
接收報告，非活動發送者接收統計。
SDES：
源描述項，包括CNAME。
BYE：
表示結束。
APP：
應用特定函數。
類似於RTP數據包，每個RTCP包以固定部分開始，緊接著的是可變長結構元素，但以一個32位邊界結束。包含安排要求和固定部分中長度段，使RTCP包可堆疊。不需要插入任何分隔符將多哥RTCP包連接起來形成一個RTCP組合包，以低層協議用單一包發送出去。由於需要低層協議提供提供整體長度來決定組合包的結尾，在組合包中沒有單個RTCP包顯式計數。
組合包中每個RTCP包可獨立處理，不需要根據包組合順序。但未了執行協議功能，強加如下約束：
接收統計（在SR或RR中）應該經常發送，只要帶寬允許，因此每個周期發送的組合RTCP 包應包含報告包。
新接收者需要接收CNAME，並盡快識別源，開始聯系媒介進行同步，因此每個包應該包含SDES CNAME。
出現在組合包前面的是包類型數量，其增長應該受到限制，以提高常數位數量，提高成功確認RTCP包對錯誤地址RTP數據包或其他無關包的概率。
因此，所有RTCP包至少必須以兩個包組合形式發送，推薦格式如下：
加密前綴（Encryption prefix）：
僅當組合包被加密，才加上一個32位隨機數用於每個組合包發送。
SR或RR：
組合包中第一個RTCP包必須總為一個報告包，方便頭的確認。即使沒有數據發送，也沒有接收到數據，也要發送一個空RR，那怕組合包中RTCP包為BYE。
附加RR：
如報告統計源數目超過31，在初始報告包後應該有附加RR 包。
SDES：
包含CNAME 項的SDES包必須包含在每個組合RTCP包中。如應用要求，其他源描述項可選，但受到帶寬限制。
BYE或APP：
其它RTCP包類型可以任意順序排列，除了BYE應作為最後一個包發送，包類型出現可不止一次。
建議轉換器或混合器從多個源組合單個RTCP包。如組合包整體長度超過網路路徑最大傳輸單元，可分成多個較短組合包用低層協議以單個包形式發送。注意，每個組合包必須以SR或RR包開始。附加RTCP包類型可在Internet Assigned Numbers Authority (IANA)處注冊。
6.2.2.2 RTCP傳輸間隔
RTP設計成允許應用自動擴展，連接數可從幾個到上千個。例如，音頻會議中，數據流量是內在限制的，因為同一時刻只有一兩個人說話；對組播，給定連接數據率仍是常數，獨立於連接數，但控制流量不是內在限制的。如每個參加者以固定速率發送接收報告，控制流量將隨參加者數量線性增長，因此，速率必須按比例下降。
一旦確認地址有效，如後來標記成未活動，地址的狀態應仍保留，地址應繼續計入共享RTCP帶寬地址的總數中，時間要保證能掃描典型網路分區，建議為30分鍾。注意，這仍大於RTCP報告間隔最大值的五倍。
這個規范定義了除必需的CNAME外的幾個源描述項，如NAME（人名）和EMAIL（電子郵件地址）。它也為定義新特定應用RTCP包類型的途徑。給附加信息分配控制帶寬應引起注意，因為它將降低接收報告和CNAME發送的速率而損害協議的性能。建議分配給單個參加者用於攜帶附加信息的RTCP帶寬不要超過20%。而且並沒有有意讓所有SDES項包含在每個應用中。
6.2.2.3 發送者與接收者報告
RTP接收者使用RTCP報告包提供接收質量反饋，報告包根據接收者是否是發送者而採用兩種格式中的一種。除包類型代碼外，發送者報告與接收者報告間唯一的差別是發送者報告包含一個20個位元組發送者信息段。如某地址在發出最後或前一個報告間隔期間發送數據包，就發布SR；否則，就發出RR；SR和RR都可沒有或包括多個接收報告塊。發布報告不是為列在CSRC列表上的起作用的源，每個接收報告塊提供從特殊源接收數據的統計。既然最大可有31個接收報告塊嵌入在SR 或 RR包中，
丟失包累計數差別給出間隔期間丟掉的數量，而所收到擴展的最後一個系列號的差別給出間隔期間希望發送的包數量，兩者之比等於經過間隔期間包丟失百分比。如兩報告連續，比值應該等於丟失段部分；否則，就不等。每秒包丟失綠可通過NTP時標差除以丟失部分得到。
從發送者信息，第三方監控器可計算載荷平均數據速率與沒收到數據間隔的平均包速率，兩者比值給出平均載荷大小。如假設包丟失與包大小無關，那麼特殊接收者收到的包數量給出此接收者收到的表觀流量。
6.2.2.4 SDES: 源描述RTCP包
SDES 包為三層結構，由頭與數據塊組成，數據塊可以沒有，也可有多個，組成項描述塊所表明的源。項描述如下：
版本（V）、填充（P）、長度：
如SR包中所描述。
包類型（PT）：
8位，包含常數202，識別RTCP SDES包。
源計數（SC）：
5位，包含在SDES包中的SSRC/CSRC塊數量，零值有效，但沒有意義。
源描述項內容如下：
CNAME: 規范終端標識SDES項
CNAME標識屬性如下：
如發生沖突或重啟程序，由於隨機分配的SSRC標識可能發生變化，需要CNAME項提供從SSRC標識到仍為常量的源標識的綁定。
象SSRC標識，CNAME標識在RTP連接的所有參加者中應是唯一的。
為了提供一套相關RTP連接中某個參加者所採用的跨多媒體工具間的綁定，CNAME應固定為那個參加者。
為方便第三方監控，CNAME應適合程序或人員定位源。
NAME：用戶名稱SDES項
這是用於描述源的真正的名稱，如\"John Doe, Bit Recycler, Megacorp\"，可是用戶想要的任意形式。對諸如會議應用，這種名稱也許是參加者列表顯示最適宜的形式，它將是除CNAME外發送最頻繁的項目。設置可建立這樣的優先順序別。NAME值至少在連接期間仍希望保持為常數。它不該成為連接的所有參加者中唯一依賴。
EMAIL：電子郵件地址SDES項
郵件地址格式由RFC822規定，如\"[email protected]\"。連接期間，電子郵件仍希望保持為常數。
PHONE：電話號碼SDES項
電話號碼應帶有加號，代替國際接入代碼，如\"+1 908 555 1212\"即為美國電話號碼。
LOC：用戶地理位置SDES項
根據應用，此項具有不同程度的細節。對會議應用，字元串如\"Murray Hill, New Jersey\"就足夠了。然而，對活動標記系統，字元串如\"Room 2A244, AT&T BL MH\"也許就適用。細節留給實施或用戶，但格式和內容可用設置指示。在連接期間，除移動主機外，LOC值期望仍保留為常數。
TOOL：應用或工具名稱SDES項
是一個字元串，表示產生流的應用的名稱與版本，如\"videotool 1.2\"。這部分信息對調試很有用，類似於郵件或郵件系統版本SMTP頭。TOOL值在連接期間仍保持常數。
NOTE: 通知/狀態SDES項
該項的推薦語法如下所述，但這些或其它語法可在設置中顯式定義。NOTE 項旨在描述源當前狀態的過渡信息，如\"on the phone, can´t talk\"，或在講座期間用於傳送談話的題目。它應該只用於攜帶例外信息，而不應包含在全部參加者中，因為這將降低接收報告和CNAME發送的速度，因此損害協議的性能。特殊情況下，它不應作為用戶設置文件的項目，也不是自動產生。
當其為活動時，由於NOTE項對顯示很重要，其它非CNAME項（如NAME）傳輸速率將會降低，結果使NOTE項佔用RTCP部分帶寬。若過渡信息不活躍，NOTE項繼續以同樣的速度重復發送幾次，但以一個串長為零的字元串通知接收者。然而，如對小倍數的重復或約20-30 RTCP間隔也沒有接收到，接收者也應該考慮NOTE項是不活躍的。
PRIV: 專用擴展SDES項
該項用於定義實驗或應用特定的SDES擴展，它包括由長字元串對組成的前綴，後跟填充該項其他部分和攜帶所需信息的字元串值。前綴長度段為8位。前綴字元串是定義PRIV項人員選擇的名稱，唯一對應應用接收到的其它PRIV項。應用實現者可選擇使用應用名稱，如有必要，外加附加子類型標識。另外，推薦其它人根據其代表的實體選擇名稱，然後，在實體內部協調名稱的使用。
注意，前綴消耗了總長為255個八進制項的一些空間，因此，前綴應盡可能的短。這個設備和受到約束的RTCP帶寬不應過載，其目的不在於滿足所有應用的全部控制通訊要求。SDES PRIV前綴沒在IANA處注冊。如證實某些形式的PRIV項具有通用性， IANA應給它分配一個正式的SDES項類型，這樣就不再需要前綴。這簡化了應用，並提高了傳輸的效率。
6.2.2.5 BYE：斷開RTCP包
如混合器接收到一個BYE包，混合器轉發BYE包，而不改變SSRC/CSRC 標識。如混合器關閉，它也應該發出一個BYE包，列出它所處理的所有源，而不只是自己的SSRC標識。作為可選項，BYE包可包括一個8位八進制計數，後跟很多八進制文本，表示離開原因，如：\"camera malfunction\"或\"RTP loop detected\"。字元串具有同樣的編碼，如在SDES 中所描述的。如字元串填充包至下32位邊界，字元串就不以空結尾；否則，BYE包以空八進制填充。
6.2.2.6 APP：定義應用的RTCP包
APP包用於開發新應用和新特徵的實驗，不要求注冊包類型值。帶有不可識別名稱的APP包應被忽略掉。測試後，如確定應用廣泛，推薦重新定義每個APP包，而不用向IANA注冊子類型和名稱段。
實時流協議RTSP
實時流協議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該協議定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或RTP完成數據傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTP傳送的是多媒體數據。HTTP請求由客戶機發出，伺服器作出響應；使用RTSP時，客戶機和伺服器都可以發出請求，即RTSP可以是雙向的。
6.3 RTSP協議
實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻，的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中數據。該協議目的在於控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑，並為選擇基於RTP上發送機制提供方法。
6.3.1 簡介
6.3.1.1 目的
實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制流交叉是可能的，通常它本身並不發送連續流。換言之，RTSP充當多媒體伺服器的網路遠程式控制制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對伺服器的可靠傳輸連接以發出RTSP 請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。實時流協議在語法和操作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。協議支持的操作如下：
從媒體伺服器上檢索媒體：
用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體的的組播地址和埠。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
媒體伺服器邀請進入會議：
媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模式在分布式教育應用上很有用，會議中幾方可輪流按遠程式控制制按鈕。
將媒體加到現成講座中：
如伺服器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP請求可由代理、通道與緩存處理。
6.3.1.2 協議特點
RTSP 特性如下：
可擴展性：
新方法和參數很容易加入RTSP。
易解析：
RTSP可由標准 HTTP或MIME解吸器解析。
安全：
RTSP使用網頁安全機制。
獨立於傳輸：
RTSP可使用不可靠數據報協議（UDP）、可靠數據報協議（RDP），如要實現應用級可靠，可使用可靠流協議。
多伺服器支持：
每個流可放在不同伺服器上，用戶端自動同不同伺服器建立幾個並發控制連接，媒體同步在傳輸層執行。
記錄設備控制：
協議可控制記錄和回放設備。
流控與會議開始分離：
僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323
可用來邀請伺服器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯
演示描述中立：
協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包含一個RTSP URI。
代理與防火牆友好：
協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流打開一個\"缺口\"。
HTTP友好：
此處，RTSP明智的採用HTTP觀念，使現在結構都可重用。結構包括Internet 內容選擇平台（PICS）。由於在大多數情況下控制連續媒體需要伺服器狀態， RTSP不僅僅向HTTP 添加方法。
適當的伺服器控制：
如用戶啟動一個流，他必須也可以停止一個流。
傳輸協調；
實際處理連續媒體流前，用戶 可協調傳輸方法。
性能協調：
如基本特徵無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的用戶界面。
6.3.1.3擴展RTSP
由於不是所有媒體伺服器有著相同的功能，媒體伺服器有必要支持不同請求集。RTSP 可以如下三種方式擴展，這里以改變大小排序：
以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
加入新方法。如信息接收者不理解請求，返回501錯誤代碼（還未實現），發送者不應再次嘗試這種方法。用戶可使用OPTIONS方法查詢伺服器支持的方法。伺服器使用公共響應頭列出支持的方法。
定義新版本協議，允許改變所有部分。（除了協議版本號位置）
6.3.1.4操作模式
每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體伺服器上。
為了說明，假設演示描述描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參數外，網路目標地址和埠也需要決定。下面區分幾種操作模式：
單播：
以用戶選擇的埠號將媒體發送到RTSP請求源。
組播，伺服器選擇地址：
媒體伺服器選擇組播地址和埠，這是現場直播或准點播常用的方式。
組播，用戶選擇地址：
如伺服器加入正在進行的組播會議，組播地址、埠和密匙由會議描述給出。
6.3.1.5 RTSP狀態
RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數據流通過UDP。因此，即使媒體伺服器沒有收到請求，數據也會繼續發送。在連接生命期，單個媒體流可通過不同TCP連接順序發出請求來控制。所以，伺服器需要維持能聯系流與RTSP請求的連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義伺服器流資源的分配與應用上起著重要的作用：
SETUP：
讓伺服器給流分配資源，啟動RTSP連接。
PLAY與RECORD：
啟動SETUP 分配流的數據傳輸。
PAUSE：
臨時停止流，而不釋放伺服器資源。
TEARDOWN：
釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，伺服器連
接產生連接標識。
6.3.1.6 與其他協議關系
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目前的協議規范目的在於允許在網頁伺服器與實現RTSP媒體伺服器之間存在不同傳遞點。例如，演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 伺服器與用戶不全依靠HTTP。
但是，RTSP與HTTP 的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議，用戶發出請求，伺服器作出響應。RTSP中，媒體用戶和伺服器都可發出請求，且其請求都是無狀態的；在請求確認後很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好處，即安全和代理。要求非常接近，在緩存、代理和授權上採用HTTP功能是有價值的。
當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格式可表示包含幾個媒體流的演示的靜態與臨時屬性。
6.3.2 協議參數
6.3.3 RTSP 信息
RTSP是基於文本的協議，採用ISO 10646 字元集，使用UTF-8編碼方案。行以CRLF中斷，但接收者本身可將CR和LF解釋成行終止符。基於文本的協議使以自描述方式增加可選參數更容易。由於參數的數量和命令的頻率出現較低，處理效率沒引起注意。如仔細研究，文本協議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現研究原型。
10646字元集避免敏感字元集切換，但對應用來說不可見。RTCP也採用這種編碼方案。帶有重要意義位的ISO 8859-1字元表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議攜帶。
請求包括方法、方法作用於其上的對象和進一步描述方法的參數。方法也可設計為在伺服器端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度有如下因素決定：
不管實體頭段是否出現在信息中，不包括信息體的的響應信息總以頭段後第一和空行結束。
如出現內容長度頭段，其值以位元組計，表示信息體長度。如未出現頭段，其值為零。
伺服器關閉連接。
注意：RTSP目前並不支持HTTP/1.1\"塊\"傳輸編碼，需要有內容長度頭。假如返回適度演示描述長度，即使動態產生，使塊傳輸編碼沒有必要，伺服器也應該能決定其長度。如有實體，即使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
從用戶到伺服器端的請求信息在第一行內包括源採用的方法、源標識和所用協議版本。RTSP定義了附加狀態代碼，而沒有定義任何HTTP代碼。
6.3.4 實體
如不受請求方法或響應狀態編碼限制，請求和響應信息可傳輸實體，實體由實體頭文件和試題體組成，有些響應僅包括實體頭。在此，根據誰發送實體、誰接收實體，發送者和接收者可分別指用戶和伺服器。
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽略，而讓代理轉發。
6.3.5 連接
RTSP請求可以幾種不同方式傳送：
1、持久傳輸連接，用於多個請求/響應傳輸。
2、每個請求/響應傳輸一個連接。
3、無連接模式。
傳輸連接類型由RTSP URI來定義。對 \"rtsp\" 方案，需要持續連接；而\"rtspu\"方案，調用RTSP 請求發送，而不用建立連接。
不象HTTP，RTSP允許媒體伺服器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否則媒體伺服器沒有可靠途徑到達用戶，這也是請求通過防火牆從媒體伺服器傳到用戶的唯一途徑。
6.3.6 方法定義
方法記號表示資源上執行的方法，它區分大小寫。新方法可在將來定義，但不能以$開頭。
某些防火牆設計與其
⑤ 實現流媒體傳輸的主要協議有哪些各自的功能和任務是什麼
基於Windows Media技術的流媒體系統的設計與實現
摘要：本文在簡介流媒體技術及其中的Windows Media技術的基礎上，結合實際簡述了Windows Media伺服器的安裝、ASF文件的製作以及「點播單播發布點」、「廣播單播發布點」、「多播廣播站」的創建方法，從實踐角度闡述了在網路中實現流媒體服務的技術和方法。
關鍵詞：Windows Media 流媒體 網路視頻
Windows Media-based streaming media technology, Design and Implementation
Abstract: This article profiles in streaming media technology in its Windows Media technology on the basis of the actual combined on a Windows Media server installation, ASF, as well as the proction of documents "on-demand unicast release point," "Broadcast Unicast release point," "Multicast broadcast stations," the creation of methods, and through links to web pages, etc. They may be related to the test, from the perspective of the practice described in the network to achieve streaming media services technologies and methods.
Key words: Windows Media streaming video network
1. 流媒體技術概述
流媒體簡單地說就是應用流式傳輸技術在Internet/Intranet上傳輸的連續時基媒體，如：音頻、視頻或多媒體文件。流式媒體在播放前並不下載整個文件，只將開始部分內容存入內存，流式媒體的數據流隨時傳送隨時播放，只是在開始時有一些延遲。流媒體實現的關鍵技術就是流式傳輸。流式傳輸主要指通過網路傳送媒體（如視頻、音頻）的技術總稱。其特定含義為通過Internet將影視節目傳送到PC機。流媒體技術是包含了採集、編碼、傳輸、儲存、解碼等多項技術的綜合技術。
2. Windows Media技術簡介
2.1 特點
Microsoft公司推出的Windows Media技術具有方便性、先進性、集成性、低費用等特點，而且其製作、發布和播放軟體與Windows NT/2000/9x集成在一起，不需要額外購買。Microsoft的流視頻解決方案在Microsoft視窗平台上是免費的，製作端與播放器的視音頻質量都上佳，而且易於使用。
2.2 Windows Media播放方式
Windows Media播放方式包括單播、多播、點播與廣播。它們的含義如下表所示：
單播：是客戶端與伺服器之間的點到點連接。在客戶端媒體伺服器之間建立一個單獨的數據通道，1台伺服器送出的每個數據包只能傳送給1個客戶機。
多播：是通過啟用多播的網路傳遞內容流，網路中的所有客戶端共享同一流。由多播技術構建的網路，允許路由器一次將數據包復制到多個通道上。採用多播方式，媒體伺服器只需要發送一個信息包，所有發出請求的客戶端即可同時收到連續的數據流而無延時。多播不會復制數據包的多個拷貝傳輸到網路上，也不會將數據包發送給不需要它的那些客戶，保證了網路上多媒體應用佔用網路的最小帶寬，是理想的播放方式。
點播：是客戶端與伺服器之間的主動的連接。用戶通過選擇內容項目來初始化客戶端連接。用戶可以開始、停止、後退、快進或暫停流。點播連接提供了對流的最大控制，但這種方式由於每個客戶端各自連接伺服器，卻會迅速用完網路帶寬。
廣播：指的是用戶被動接收流。在廣播過程中，客戶端接收流，但不能控制流。例如，用戶不能暫停、快進或後退該流。廣播方式中數據包的單獨一個拷貝將發送給網路上的所有用戶，而不管用戶是否需要。此種傳輸方式會非常浪費網路帶寬。
2.3 Windows Media視頻技術組成
Windows Media視頻伺服器系統包括以下幾個部分：Windows Media伺服器組件、Windows Media工具、Windows Media Player。
2.4 Windows Media編碼器
Windows Media編碼器用於轉換實時和存儲的視頻和音頻內容為ASF流，然後通過Windows Media伺服器在網路中傳送。
2.5 Windows Media Player
Windows Media客戶端軟體稱為Windows Media Player，由Windows Media伺服器接收並播放流內容。Windows Media服務使用Windows Media Player以播放包含視頻、音頻、圖像、URL和腳本內容的ASF流。Windows Media Player 9系列是最新版本。
2.6 Microsoft高級流格式ASF簡介
Microsoft公司的Windows Media的核心是ASF（Advanced Stream Format）。 Microsoft將ASF定義為「同步媒體的統一容器文件格式」。ASF是一種數據格式，音頻、視頻、圖像以及控制命令腳本等多媒體信息通過這種格式，以網路數據包的形式傳輸，實現流式多媒體內容發布。
3. Windows Media校園流媒體系統的設計
3.1 網路結構設計
Windows Media流媒體系統包括伺服器端和用戶端兩部分。伺服器端包括Windows Media伺服器、製作計算機。Windows Media伺服器用於存儲和發布流媒體信息。製作計算機安裝視頻採集卡、音效卡及攝像機，用於製作流媒體文件。用戶端安裝Windows Media Player軟體。數據傳輸依託校園網。
3.2 軟硬體要求
3.2.1伺服器
伺服器硬體配置一般是PIII400以上CPU，內存在128~512M左右。操作系統Windows 2000 Server及Windows Media服務組件。
3.2.2製作計算機
製作計算機硬體配置一般是PIII400以上CPU，內存在128~512M，需要音效卡、視頻採集卡以及VCD或錄像機。軟體為Windows 98或Windows 2000 Professional，安裝Windows Media編輯工具。
4. Windows Media校園流媒體系統的實現
4.1 ASF文件的製作
筆者在微機上安裝了Broadway視頻採集卡，並通過錄像機採集了兩段AVI格式的錄像，分別命名為LX1.AVI和LX2.AVI。通過Windows 2000 Server自帶的編碼器Windows Media Encoder可以很容易地將兩個AVI文件轉換為ASF文件：LX1. ASF、 LX2. ASF。在F盤上建立文件夾ASF，將兩個ASF文件存入（為表述方便，文中所用文件名、路徑、計算機名稱、IP等，皆為筆者實際實驗過程所用，讀者可根據自己實際環境確定這些內容）。也可用Windows Media編碼器9系列存為WMV格式文件，但要求客戶端播放器必須為7.0以上版本
4.2 使用「快速啟動向導」創建「點播單播發布點」
在F盤上建立文件夾「asx」並設為共享，以便在後續操作中放置「.asx」通知文件。
在 Windows Media 管理器菜單框中單擊「單播發布點」，出現「單播發布點」頁。確保選擇了「使用向導創建新的點播單播發布點」復選框，單擊「點播」，然後單擊「新建」， 出現「配置和發布單播點播流快速啟動向導」。
在「選擇一個發布點」屏幕中，選擇「創建一個發布點」。在「創建一個新的發布點」屏幕中，在「別名」框中鍵入別名為「asf」。在「路徑」框中，鍵入「F:\asf\」。在"查找目標 .asf 文件"屏幕，輸入「F:\asf\lx1.asf」。在「選擇發布方法」屏，選擇「MMS協議」和「創建一個.asx文件」，然後選擇 「下一步」。在「准備發布」屏幕中，選擇 「完成」。
將「lx1.asx」通知文件保存到「F:\asx\」裡面。在「發布完成」屏幕中，單擊「測試 URL」、「測試 .asx」可以在 Windows Media Player 中傳遞點播單播發布點的流式化內容「lx1.asf」。
⑥ 什麼是流媒體目前主流的流媒體技術有哪三種
流媒體(Streaming Media)指在數據網路上按時間先後次序傳輸和播放的連續音/視頻數據流。以前人專們在網路屬上觀看電影或收聽音樂時，必須先將整個影音文件下載並存儲在本地計算機上，然後才可以觀看。與傳統的播放方式不同，流媒體在播放前並不下載整個文件，只將部分內容緩存，使流媒體數據流邊傳送邊播放，這樣就節省了下載等待時間和存儲空間。流媒體數據流具有三個特點：連續性(Continuous) 、實時性(Real - time) 、時序性，即其數據流具有嚴格的前後時序關系。
目前市場上主流的流媒體技術有三種,分別是RealNetworks公司的RealMedia、Microsoft的Windows Media和Apple公司的QuickTime。
⑦ 流媒體協議RTMP、RTSP與HLS有什麼不同
1.HLS(HTTPLiveStreaming)：Apple的動態碼率自適應技術。主要用於PC和Apple終端的音視頻服務。
2.http為計算機網路中進行數據交換而建立的規則，網路中一個微機用戶和一個大型主機的操作員進行通信。
3.流媒體協議是用來描述進程之間信息交換數據時的規則術語。
⑧ 流媒體系統包括哪三部分目前三大主流媒體格式以及協議是什麼
流媒體系統組成：
編碼器：
它由一台普通計算機、一塊microvision 高清視頻採集卡和流媒體編碼軟體組成。Microvision流媒體採集卡負責將音視頻信息源輸入計算機，供編碼軟體處理;編碼軟體負責將流媒體 採集卡傳送過來的數字音視頻信號壓縮成流媒體格式。如果做直播，它還負責實時地將壓縮好的流媒體信號上傳給流媒體伺服器
伺服器：
由流媒體軟體系統的伺服器部分和一台硬體伺服器組成。這部分負責管理、存儲、分發編碼器傳上來的流媒體節目。
終端播放器，也叫解碼器:
這部分由流媒體系統的播放軟體和一台普通PC組成，用它來播放用戶想要收看的流媒體伺服器上的視頻節目。
目前主流的流媒體技術有三種，分別是RealNetworks公司的RealSystem、Microsoft公司的WindowsMediaTechnology和Apple公司的QuickTime。
1.Apple公司的QuickTime
QuickTime是一個非常老牌的媒體技術集成，是數字媒體領域事實上的工業標准。之所以說集成這個詞是因為QuickTime實際上是一個開放式的架構，包含了各
種各樣的流式或者非流式的媒體技術。QuickTime是最早的視頻工業標准，1999年發布的QuickTime4.0版本開始支持真正的流式播放。由於QuickTime本身也存在
著平台的便利(MacOS)，因此也擁有不少的用戶。QuickTime在視頻壓縮上採用的是SorensonVideo技術，音頻部分則採用QDesignMusic技術。QuickTime最大的
特點是其本身所具有的包容性，使得它是一個完整的多媒體平台，因此基於QuickTime可以使用多種媒體技術來共同製作媒體內容。同時，它在交互性方面是三者
之中最好的。例如，在一個QuickTime文件中可同時包含midi、動畫gif、flash和smil等格式的文件，配合QuickTime的WiredSprites互動格式，可設計出各種
互動界面和動畫。QuickTime流媒體技術實現基礎是需要3個軟體的支持，QuickTime播放器、QuickTime編輯製作、QuickTimeStreaming伺服器。
2.RealNetworks公司的RealMedia
RealMedia發展的時間比較長，因此具有很多先進的設計，例如，ScalableVideoTechnology可伸縮視頻技術可以根據用戶電腦速度和連接質量而自動調整媒
體的播放質素。Two—passEncoding兩次編碼技術可通過對媒體內容進行預掃描，再根據掃描的結果來編碼從而提高編碼質量。特別是SureStream自適應流技術，
可通過一個編碼流提供自動適合不同帶寬用戶的流播放。RealMedia音頻部分採用的是RealAudio，該編碼在低帶寬環境下的傳輸性能非常突出。RealMedia通過基
於smil並結合自己的RealPix和RealText技術來達到一定的交互能力和媒體控制能力。Real流媒體技術需要3個軟體的支持，RealPlayer播放器、RealProcer
編輯製作、RealServer伺服器。
3.Microsoft公司的WindowsMedia
WindowsMedia是三家之中最後進入這個市場的，但憑借其操作系統的便利很快便取得了較大的市場份額。WindowsMediaVideo採用的是mpeg-4視頻壓縮技術，
音頻方面採用的是WindowsMediaAudio技術。WindowsMedia的關鍵核心是MMS協議和ASF數據格式，MMS用於網路傳輸控制，ASF則用於媒體內容和編碼方案的打包。
目前WindowsMedia在交互能力方面是三者之中最弱的，自己的ASF格式交互能力不強，除了通過IE支持smil之外就沒有什麼其他的交互能力了。WindowsMedia流
媒體技術的實現需要3個軟體的支持，WindowsMedia播放器、WindowsMedia工具和WindowsMedia伺服器。總的來說，如果使用Windows伺服器平台，
WindowsMedia的費用最少。雖然在現階段其功能並不是最好，用戶也不是最多。
Windows Media系統
傳輸協議: mms(Multi-Media Stream多媒體流)完全封閉
常用流媒體文件格式:asf, wmv, wma
組織文件格式:wsx
Real Media系統
編碼標准:主要支持Real
傳輸協議:rtsp(有限開放)
常用流媒體文件格式: rm, ra
組織文件格式:smi, smil
Flash Media系統
傳輸協議:rtmp
常用流媒體文件格式:flv, f4v
組織文件格式:swf, smil
Quick Time系統(不展開)
⑨ 流媒體用的是什麼協議
流媒體的傳輸協議 . RTSP（Real Time Streaming Protocol），實時流媒體協議，它是由RealNetworks和Netscape共同提出的，現在用於RealNetworks的Real Media產品中； 2. PNM（Progressive Networks Audio），這也是Real專用的實時傳輸協議，它一般採用UDP協議，並佔用7070埠，但當你的伺服器在防火牆內且7070埠被擋，且你的伺服器把SmartingNetwork設為真時，則採用http協議，並佔用默認的80埠； 3. MMS（Microsoft Media Server protocol），這是微軟的流媒體伺服器協議，MMS 是連接 Windows Media 單播服務的默認方法。 介紹了主要的三個，可能您還會問，Apple的QuickTime使用哪種協議呢？在多數情況下，QuickTime使用http協議，但實際上它也由標準的流媒體傳輸協議，這就是標准RTSP協議，而Real公司使用的RTSP是自己經過開發的。 在流媒體傳輸中，標準的協議就是RTP（Real time Transport Protocol，實時傳輸協議）、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議)、RTSP（Real Time Streaming Protocol，實時流媒體協議）和RSVP（Resource Reserve Protocol, 資源預訂協議），廠商們的產品都是在這些協議的基礎上進行研究與開發，限於篇幅，在這里我們就不再深入討論了。