流媒體傳輸協(xié)議及音視頻編解碼技術(shù)

1、1.1 音視頻編解碼技術(shù)1.1.1 MPEG4MPEG全稱是Moving Pictures Experts Group，它是“動(dòng)態(tài)圖象專家組”的英文縮寫，該專家組成立于1988年，致力于運(yùn)動(dòng)圖像及其伴音的壓縮編碼標(biāo)準(zhǔn)化工作，原先他們打算開發(fā)MPEG1、MPEG2、MPEG3和MPEG4四個(gè)版本，以適用于不同帶寬和數(shù)字影像質(zhì)量的要求。 目前，MPEG1技術(shù)被廣泛的應(yīng)用于VCD，而MPEG2標(biāo)準(zhǔn)則用于廣播電視和DVD等。MPEG3最初是為HDTV開發(fā)的編碼和壓縮標(biāo)準(zhǔn)，但由于MPEG2的出色性能表現(xiàn)， MPEG3只能是死于襁褓了。MPEG4于1999年初正式成為國(guó)際標(biāo)準(zhǔn)。它是一個(gè)適用于低傳輸速率應(yīng)用

2、的方案。與MPEG1和MPEG2相比，MPEG4更加注重多媒體系統(tǒng)的交互性和靈活性MPEG1、MPEG2技術(shù)當(dāng)初制定時(shí)，它們定位的標(biāo)準(zhǔn)均為高層媒體表示與結(jié)構(gòu)，但隨著計(jì)算機(jī)軟件及網(wǎng)絡(luò)技術(shù)的快速發(fā)展，MPEG1、MPEG2技術(shù)的弊端就顯示出來(lái)了：交互性及靈活性較低，壓縮的多媒體文件體積過(guò)于龐大，難以實(shí)現(xiàn)網(wǎng)絡(luò)的實(shí)時(shí)傳播。而MPEG4技術(shù)的標(biāo)準(zhǔn)是對(duì)運(yùn)動(dòng)圖像中的內(nèi)容進(jìn)行編碼，其具體的編碼對(duì)象就是圖像中的音頻和視頻，術(shù)語(yǔ)稱為“AV對(duì)象”，而連續(xù)的AV對(duì)象組合在一起又可以形成AV場(chǎng)景。因此，MPEG4標(biāo)準(zhǔn)就是圍繞著AV對(duì)象的編碼、存儲(chǔ)、傳輸和組合而制定的，高效率地編碼、組織、存儲(chǔ)、傳輸AV對(duì)象是MPEG4標(biāo)

3、準(zhǔn)的基本內(nèi)容。在視頻編碼方面，MPEG4支持對(duì)自然和合成的視覺對(duì)象的編碼。（合成的視覺對(duì)象包括2D、3D動(dòng)畫和人面部表情動(dòng)畫等）。在音頻編碼上，MPEG4可以在一組編碼工具支持下，對(duì)語(yǔ)音、音樂(lè)等自然聲音對(duì)象和具有回響、空間方位感的合成聲音對(duì)象進(jìn)行音頻編碼。 由于MPEG4只處理圖像幀與幀之間有差異的元素，而舍棄相同的元素，因此大大減少了合成多媒體文件的體積。應(yīng)用MPEG4技術(shù)的影音文件最顯著特點(diǎn)就是壓縮率高且成像清晰，一般來(lái)說(shuō)，一小時(shí)的影像可以被壓縮為350M左右的數(shù)據(jù)，而一部高清晰度的DVD電影, 可以壓縮成兩張甚至一張650M CD光碟來(lái)存儲(chǔ)。對(duì)廣大的“平民”計(jì)算機(jī)用戶來(lái)說(shuō)， 這就意味著,

4、 您不需要購(gòu)置 DVD-ROM就可以欣賞近似DVD質(zhì)量的高品質(zhì)影像。而且采用MPEG4編碼技術(shù)的影片，對(duì)機(jī)器硬件配置的要求非常之低，300MHZ 以上CPU，64M的內(nèi)存和一個(gè) 8M顯存的顯卡就可以流暢的播放。在播放軟件方面，它要求也非常寬松，你只需要安裝一個(gè) 500K左右的 MPEG4 編碼驅(qū)動(dòng)后，用 WINDOWS 自帶的媒體播放器就可以流暢的播放了AV對(duì)象（AVO，Audio Visual Object）是MPEG-4為支持基于內(nèi)容編碼而提出的重要概念。對(duì)象是指在一個(gè)場(chǎng)景中能夠訪問(wèn)和操縱的實(shí)體，對(duì)象的劃分可根據(jù)其獨(dú)特的紋理、運(yùn)動(dòng)、形狀、模型和高層語(yǔ)義為依據(jù)。在MPEG-4中所見的音視頻已

5、不再是過(guò)去MPEG-1、MPEG-2中圖像幀的概念，而是一個(gè)個(gè)視聽場(chǎng)景（AV場(chǎng)景），這些不同的AV場(chǎng)景由不同的AV對(duì)象組成。AV對(duì)象是聽覺、視覺、或者視聽內(nèi)容的表示單元，其基本單位是原始AV對(duì)象，它可以是自然的或合成的聲音、圖像。原始AV對(duì)象具有高效編碼、高效存儲(chǔ)與傳輸以及可交互性的特性，它又可進(jìn)一步組成復(fù)合AV對(duì)象。因此MPEG-4標(biāo)準(zhǔn)的基本內(nèi)容就是對(duì)AV對(duì)象進(jìn)行高效編碼、組織、存儲(chǔ)與傳輸。AV對(duì)象的提出，使多媒體通信具有高度交互及高效編碼的能力，AV對(duì)象編碼就是MPEG-4的核心編碼技術(shù)。 MPEG-4不僅可提供高壓縮率，同時(shí)也可實(shí)現(xiàn)更好的多媒體內(nèi)容互動(dòng)性及全方位的存取性，它采用開放的編碼

6、系統(tǒng)，可隨時(shí)加入新的編碼算法模塊，同時(shí)也可根據(jù)不同應(yīng)用需求現(xiàn)場(chǎng)配置解碼器，以支持多種多媒體應(yīng)用1.1.2 H264 H.264是由ITU-T的VCEG（視頻編碼專家組）和ISO/IEC的MPEG（活動(dòng)圖像編碼專家組）聯(lián)合組建的聯(lián)合視頻組（JVT：joint video team）提出的一個(gè)新的數(shù)字視頻編碼標(biāo)準(zhǔn)，它既是ITU-T的H.264，又是ISO/IEC的MPEG-4的第10 部分。 而國(guó)內(nèi)業(yè)界通常所說(shuō)的MPEG-4是MPEG-4的第2部分。H.264標(biāo)準(zhǔn)從1998年1月份開始草案征集，到2003年7月，整套H.264 （ISO/IEC 14496-10）規(guī)范定稿。2005年1月，MPEG

7、組織正式發(fā)布了H.264驗(yàn)證報(bào)告，從各個(gè)方面論證了H.264的可用性以及各種工具集的效果，從標(biāo)準(zhǔn)的角度，印證H.264的成熟性。從標(biāo)準(zhǔn)制定到頒布，H.264一直是ITU、MPEG、DVD、DVB、3GPP等工業(yè)化組織共同推進(jìn)的視頻編碼國(guó)際標(biāo)準(zhǔn)，可以想見，在眾多行業(yè)巨擘的推動(dòng)下，H.264技術(shù)的應(yīng)用將迅速進(jìn)入到視頻服務(wù)、媒體制作發(fā)行、固定及移動(dòng)運(yùn)營(yíng)網(wǎng)絡(luò)、平臺(tái)開發(fā)、設(shè)備終端制造、芯片開發(fā)等多個(gè)領(lǐng)域。 H.264使圖像壓縮技術(shù)上升到了一個(gè)更高的階段，能夠在較低帶寬上提供高質(zhì)量的圖像傳輸，該優(yōu)點(diǎn)非常適合國(guó)內(nèi)運(yùn)營(yíng)商用戶量大、接入網(wǎng)/骨干網(wǎng)帶寬相對(duì)有限的狀況。在同等的畫質(zhì)下，H.264比上一代編碼標(biāo)準(zhǔn)MP

8、EG2平均節(jié)約64的傳輸碼流，而比MPEG4 ASP要平均節(jié)約39的傳輸碼流。全球很多IPTV業(yè)務(wù)運(yùn)營(yíng)商都將H.264作為編解碼格式的標(biāo)準(zhǔn)，包括比利時(shí)電信，荷蘭KPN，泰國(guó)ADC電信，中國(guó)電信等等。根據(jù)中國(guó)電信上海研究院的實(shí)際測(cè)試結(jié)果表明：國(guó)內(nèi)普遍采用的MPEG-4編碼技術(shù)在3Mbps的帶寬下尚達(dá)不到標(biāo)清的圖像質(zhì)量，而H.264編碼技術(shù)可以在2M帶寬下提供要求的圖像效果。因而運(yùn)營(yíng)商希望引入更先進(jìn)的H.264編碼技術(shù)，在有限的帶寬資源下進(jìn)一步提高圖像質(zhì)量。 1.2 流媒體網(wǎng)絡(luò)傳輸協(xié)議流媒體技術(shù)采用一系列的網(wǎng)絡(luò)協(xié)議，包括：1. 實(shí)時(shí)傳輸協(xié)議RTP(Real-time Transport proto

9、col)2. 實(shí)時(shí)傳輸控制協(xié)議RTCP(Real-time Transport Control protocol)3. 實(shí)時(shí)流協(xié)議RTSP(Real Time Streaming protocol)4. 資源預(yù)留協(xié)議RSVP(Resource Reserve Protocol)。1.2.1 RTPRTP是一種提供端對(duì)端傳輸服務(wù)的實(shí)時(shí)傳輸協(xié)議，用來(lái)支持在單目標(biāo)廣播和多目標(biāo)廣播網(wǎng)絡(luò)服務(wù)中傳輸實(shí)時(shí)數(shù)據(jù)，而實(shí)時(shí)數(shù)據(jù)的傳輸則由RTCP協(xié)議來(lái)監(jiān)視和控制。RTP定義在RFC 1889中。信息包的結(jié)構(gòu)包含廣泛用于多媒體的若干個(gè)域，包括聲音點(diǎn)播(audio-on-demand)、影視點(diǎn)播(video on de

10、mand)、因特網(wǎng)電話(Internet telephony)和電視會(huì)議(videoconferencing)。RTP的規(guī)格沒(méi)有對(duì)聲音和電視的壓縮格式制定標(biāo)準(zhǔn)，它可以被用來(lái)傳輸普通格式的文件。例如，WAV或者GSM(Global System for Mobile communications)格式的聲音、MPEG-1和MPEG-2的電視，也可以用來(lái)傳輸專有格式存儲(chǔ)的聲音和電視文件。使用RTP協(xié)議的應(yīng)用程序運(yùn)行在RTP之上，而執(zhí)行RTP的程序運(yùn)行在UDP的上層，目的是為了使用UDP的端口號(hào)和檢查和。如下圖所示，RTP可以看成是傳輸層的子層。由多媒體應(yīng)用程序生成的聲音和電視數(shù)據(jù)塊被封裝在RTP信

11、息包中，每個(gè)RTP信息包被封裝在UDP消息段中，然后再封裝在IP數(shù)據(jù)包中。TCP/IP模型應(yīng)用層(application)傳輸層RTPUDPIP數(shù)據(jù)鏈路層(data link)物理層(physical)RTP是傳輸層上的協(xié)議從應(yīng)用開發(fā)人員的角度來(lái)看，可把RTP執(zhí)行程序看成是應(yīng)用程序的一部分，因?yàn)殚_發(fā)人員必需把RTP集成到應(yīng)用程序中。在發(fā)送端，開發(fā)人員必需把執(zhí)行RTP協(xié)議的程序?qū)懭氲絼?chuàng)建RTP信息包的應(yīng)用程序中，然后應(yīng)用程序把RTP信息包發(fā)送到UDP的套接接口(socket interface)，如下圖所示；同樣，在接收端，RTP信息包通過(guò)UDP套接接口輸入到應(yīng)用程序，因此開發(fā)人員必需把執(zhí)行RT

12、P協(xié)議的程序?qū)懭氲綇腞TP信息包中抽出媒體數(shù)據(jù)的應(yīng)用程序。TCP/IP模型應(yīng)用層(application)RTP套接接口UDPIP數(shù)據(jù)鏈路層(data link)物理層(physical)RTP和UDP之間的接口RTP本身不提供任何機(jī)制來(lái)確保把數(shù)據(jù)及時(shí)遞送到接收端或者確保其他的服務(wù)質(zhì)量，它也不擔(dān)保在遞送過(guò)程中不丟失信息包或者防止信息包的次序不被打亂。的確，RTP的封裝只是在系統(tǒng)端才能看到，中間的路由器并不區(qū)分那個(gè)IP數(shù)據(jù)報(bào)是運(yùn)載RTP信息包的。RTP允許給每個(gè)媒體源分配一個(gè)單獨(dú)的RTP信息包流，例如，攝像機(jī)或者麥克風(fēng)。例如，有兩個(gè)團(tuán)體參與的電視會(huì)議，這就可能打開4個(gè)信息包流：兩臺(tái)攝像機(jī)傳送電視

13、流和兩個(gè)麥克風(fēng)傳送聲音流。然而，許多流行的編碼技術(shù)，包括MPEG-1和MPEG-2在編碼過(guò)程中都把聲音和電視圖像捆綁在一起以形成單一的數(shù)據(jù)流，一個(gè)方向就生成一個(gè)RTP信息包流。RTP信息包沒(méi)有被限制只可應(yīng)用于單目標(biāo)廣播，它們也可以在一對(duì)多(one-to-many)的多目標(biāo)廣播樹或者在多對(duì)多(many-to-many)的多目標(biāo)廣播樹上傳送。例如，多對(duì)多的多目標(biāo)廣播，在這種應(yīng)用場(chǎng)合下，所有發(fā)送端通常都把他們的RTP信息包流發(fā)送到具有相同多目標(biāo)廣播地址的多目標(biāo)廣播樹上。RTP標(biāo)題由4個(gè)信息包標(biāo)題域和其他域組成：有效載荷類型(payload type)域，順序號(hào)(sequence number)域，時(shí)

14、間戳(timestamp)域和同步源標(biāo)識(shí)符(Synchronization Source Identifier)域等。RTP信息包的標(biāo)題域的結(jié)構(gòu)如下圖所示：Payload Type(有效載荷類型)Sequence Number(順序號(hào))Timestamp(時(shí)間戳)Synchronization Source Identifier(同步源標(biāo)識(shí)符)Miscellaneous Fields(其他)1. 有效載荷類型RTP信息包中的有效載荷域(Payload Type Field)的長(zhǎng)度為7位，因此RTP可支持128種不同的有效載荷類型。對(duì)于聲音流，這個(gè)域用來(lái)指示聲音使用的編碼類型，例如PCM、自適應(yīng)

15、增量調(diào)制或線性預(yù)測(cè)編碼等等。如果發(fā)送端在會(huì)話或者廣播的中途決定改變編碼方法，發(fā)送端可通過(guò)這個(gè)域來(lái)通知接收端。 2. 順序號(hào)順序號(hào)(Sequence Number Field)域的長(zhǎng)度為16位。每發(fā)送一個(gè)RTP信息包順序號(hào)就加1，接收端可以用它來(lái)檢查信息包是否有丟失以及按順序號(hào)處理信息包。例如，接收端的應(yīng)用程序接收到一個(gè)RTP信息包流，這個(gè)RTP信息包在順序號(hào)86和89之間有一個(gè)間隔，接收端就知道信息包87和88已經(jīng)丟失，并且采取措施來(lái)處理丟失的數(shù)據(jù)。（初始是隨機(jī)的）3. 時(shí)間戳?xí)r間戳(Timestamp)域的長(zhǎng)度為32字節(jié)。它反映RTP數(shù)據(jù)信息包中第一個(gè)字節(jié)的采樣時(shí)刻(時(shí)間)。接收端可以利用這

16、個(gè)時(shí)間戳來(lái)去除由網(wǎng)絡(luò)引起的信息包的抖動(dòng)，并且在接收端為播放提供同步功能。（由該時(shí)間恢復(fù)出原始時(shí)鐘信息，要處理分布式終端的時(shí)鐘漂移）4. 同步源標(biāo)識(shí)符 同步源標(biāo)識(shí)符(Synchronization Source Identifier，SSRC)域的長(zhǎng)度為32位。它用來(lái)標(biāo)識(shí)RTP信息包流的起源，在RTP會(huì)話或者期間的每個(gè)信息包流都有一個(gè)清楚的SSRC。SSRC不是發(fā)送端的IP地址，而是在新的信息包流開始時(shí)源端隨機(jī)分配的一個(gè)號(hào)碼。（用于媒體間同步）1.2.2 RTCP實(shí)時(shí)傳輸控制協(xié)議(Real-time Control Protocol，RTCP)也定義在1996年提出的RFC 1889中。多媒體網(wǎng)

17、絡(luò)應(yīng)用把RTCP和RTP一起使用，尤其是在多目標(biāo)廣播中更具吸引力。當(dāng)從一個(gè)或者多個(gè)發(fā)送端向多個(gè)接收端廣播聲音或者電視時(shí)，也就是在RTP會(huì)話期間，每個(gè)參與者周期性地向所有其他參與者發(fā)送RTCP控制信息包，如圖所示。RTCP用來(lái)監(jiān)視服務(wù)質(zhì)量和傳送有關(guān)與會(huì)者的信息。對(duì)于RTP會(huì)話或者廣播，通常使用單個(gè)多目標(biāo)廣播地址，屬于這個(gè)會(huì)話的所有RTP和RTCP信息包都使用這個(gè)多目標(biāo)廣播地址，通過(guò)使用不同的端口號(hào)可把RTP信息包和RTCP信息包區(qū)分開來(lái)。每個(gè)參與者周期性地發(fā)送RTCP控制信息包RTCP的主要功能是為應(yīng)用程序提供會(huì)話質(zhì)量或者廣播性能質(zhì)量的信息。每個(gè)RTCP信息包不封裝聲音數(shù)據(jù)或者電視數(shù)據(jù)，而是封裝

18、發(fā)送端和/或者接收端的統(tǒng)計(jì)報(bào)表。這些信息包括發(fā)送的信息包數(shù)目、丟失的信息包數(shù)目和信息包的抖動(dòng)等情況，這些反饋信息對(duì)發(fā)送端、接收端或者網(wǎng)絡(luò)管理員都是很有用的。RTCP規(guī)格沒(méi)有指定應(yīng)用程序應(yīng)該使用這個(gè)反饋信息做什么，這完全取決于應(yīng)用程序開發(fā)人員。例如，發(fā)送端可以根據(jù)反饋信息來(lái)修改傳輸速率，接收端可以根據(jù)反饋信息判斷問(wèn)題是本地的、區(qū)域性的還是全球性的，網(wǎng)絡(luò)管理員也可以使用RTCP信息包中的信息來(lái)評(píng)估網(wǎng)絡(luò)用于多目標(biāo)廣播的性能。1.2.3 RTSP實(shí)時(shí)流放協(xié)議(Real-Time Streaming Protocol，RTSP)是一個(gè)剛開始開發(fā)的協(xié)議，它的設(shè)想描述在RFC 2326文件中。RTSP是應(yīng)用

19、級(jí)的實(shí)時(shí)流放協(xié)議，它主要目標(biāo)是為單目標(biāo)廣播和多目標(biāo)廣播上的流式多媒體應(yīng)用提供牢靠的播放性能，以及支持不同廠家提供的客戶機(jī)和服務(wù)機(jī)之間的協(xié)同工作能力。在RTSP中，每個(gè)演示（Presentation）及其所對(duì)應(yīng)的媒體流都由一個(gè)RTSP URL標(biāo)識(shí)。整個(gè)演示及媒體特性都在一個(gè)演示描述（Presentation description）文件中定義，該文件可能包括媒體編碼方式、語(yǔ)言、RTSP URLs、目標(biāo)地址、端口及其它參數(shù)。用戶在向服務(wù)器請(qǐng)求某個(gè)連續(xù)媒體流的服務(wù)之前，必須首先從服務(wù)器獲得該媒體流的演示描述（Presentation description）文件以得到必需的參數(shù)，演示描述文件的獲取可

20、采用HTTP、email或其他方法。RTSP中的所有的操作都是通過(guò)服務(wù)器和客戶方的消息應(yīng)答來(lái)完成的，其消息包括請(qǐng)求（Request）和響應(yīng)（Response）兩種，RTSP正是通過(guò)服務(wù)器和客戶端的消息應(yīng)答來(lái)完成媒體流的創(chuàng)建、初始化（SETUP）、VCR(盒式錄像機(jī)VideoCassetteRecorder)控制（PLAY、PAUSE）以及拆線（TEARDOWN）等操作的。 在基于Client/Server結(jié)構(gòu)的分布式視頻點(diǎn)播系統(tǒng)中，RTSP協(xié)議的操作過(guò)程如圖： 客戶機(jī)在向視頻服務(wù)器請(qǐng)求視頻服務(wù)之前，首先通過(guò)HTTP協(xié)議從Web服務(wù)器獲取所請(qǐng)求視頻服務(wù)的演示描述（Presentation des

21、cription）文件，利用該文件提供的信息定位視頻服務(wù)地址（包括視頻服務(wù)器地址和端口號(hào)）及視頻服務(wù)的編碼方式等信息。然后客戶機(jī)根據(jù)上述信息向視頻服務(wù)器請(qǐng)求視頻服務(wù)(SETUP)。視頻服務(wù)初始化完畢，視頻服務(wù)器為該客戶建立一個(gè)新的視頻服務(wù)流，客戶端與服務(wù)器運(yùn)行實(shí)時(shí)流控制協(xié)議RTSP，以對(duì)該流進(jìn)行各種VCR控制信號(hào)的交換，如播放（PLAY）、停止（PAUSE）、快進(jìn)、快退等。當(dāng)服務(wù)完畢，客戶端提出拆線（TEARDOWN）請(qǐng)求，釋放資源。例子：l 頻道切換的RTSP信息06/07/12 03:02:07:750 Debuger Connect Succeed, Port=10010, Connec

22、ted!06/07/12 03:02:08:390 RTSP: MEDIA_CLOSE cmd recv!06/07/12 03:02:08:390 *(Clinet => Server)* COMMAND*TEARDOWN rtsp:/01/008/unicast/device172016058101/ch06070814324870782148.sdp?userid=26770602&clientt。（斷開視頻服務(wù)器的相關(guān)信息）。06/07/12 03:02:09:484 The transpot type is <TCP>06/07/12

23、03:02:09:593 *(Clinet => Server)*COMMAND*DESCRIBE rtsp:/00:1554/008/unicast/ch06070814315964857960.sdp?userid=26770602&clienttype=1&mediai。（用戶發(fā)出頻道請(qǐng)求時(shí)，Agent的相關(guān)信息）06/07/12 03:02:10:812 RTSP response isn't 200 but other 302! （重定向）06/07/12 03:02:10:812 RTSP: MEDIA_CLOSE cmd re

24、cv!06/07/12 03:02:10:812 *(Clinet => Server)*COMMAND*TEARDOWN rtsp:/00:1554/008/unicast/ch06070814315964857960.sdp?userid=26770602&clienttype=1&mediaid=ch06。（ 與Agent斷開的相關(guān)信息 ）。06/07/12 03:02:10:812 The transpot type is <TCP>06/07/12 03:02:10:812 *(Clinet => Server)*COM

25、MAND*DESCRIBE rtsp:/01/008/unicast/device172016058101/ch06070814315964857960.sdp?userid=26770602&clientt。（由Agent指定的流媒體服務(wù)器信息）。06/07/12 03:02:10:812 *(Server => Clinet)*RESPONSE*RTSP/1.0 200 OKServer: ZMSS/V1.20.033E (Build/2006.06.12; Platform/Linux; Release/ZMSS; )（流媒體的版本信息）。Conten

26、t-Base: rtsp:/01/008/unicast/device172016058101/ch06070814315964857960.sdp/。06/07/12 03:02:10:812 *(Clinet => Server)*COMMAND*SETUP rtsp:/01/008/unicast/device172016058101/ch06070814315964857960.sdp/trackID=2 RTSP/1.0。06/07/12 03:02:10:812 *(Server => Clinet)*RESPONSE*RTS

27、P/1.0 200 OK。06/07/12 03:02:10:812 *(Clinet => Server)*COMMAND*PLAY rtsp:/01/008/unicast/device172016058101/ch06070814315964857960.sdp?userid=26770602&clientt。06/07/12 03:02:10:921 *(Server => Clinet)*RESPONSE*RTSP/1.0 200 OK。RTP-Info: url=rtsp:/01/008/unicast/device1

28、72016058101/ch06070814315964857960.sdp/trackID=206/07/12 03:02:10:140 RTSP: *<Server => Client>*COMMAND*SET_PARAMETER rtsp:/01/008/unicast/device172016058101/ch06070814315964857960.sdp RTSP/1.0 CSeq: 1 x-SpeedupPlay: NOl 點(diǎn)播節(jié)目播放的RTSP信息06/07/12 04:58:12:921 Debuger Connect Succeed,

29、 Port=10010, Connected!06/07/12 04:58:18:593 The transpot type is <TCP>06/07/12 04:58:18:593 *(Clinet => Server)*COMMAND*DESCRIBE rtsp:/00:1554/008/vod/00000000020000000415.mpg?userid=26770602&clienttype=1&mediaid=0000000003020000000017&paytype=0&time=20060712125

30、824+08&life=3600&usersessionid=120695&vcdnid。06/07/12 04:58:19:468 RTSP response isn't 200 but other 302!（重定向）06/07/12 04:58:19:468 RTSP: MEDIA_CLOSE cmd recv!06/07/12 04:58:19:468 *(Clinet => Server)*COMMAND*TEARDOWN rtsp:/00:1554/008/vod/00000000020000000415.mpg?user

31、id=26770602&clienttype=1&mediaid=0。06/07/12 04:58:19:468 *(Clinet => Server)*COMMAND*DESCRIBE rtsp:/01/008/vod/00000000020000000415.mpg?userid=26770602&clienttype=1&mediaid=0000000。06/07/12 04:58:20:796 *(Server => Clinet)*RESPONSE*RTSP/1.0 200 OKServer: ZMSS/V1.20.0

32、33E (Build/2006.06.12; Platform/Linux; Release/ZMSS; )Content-Base: rtsp:/01/008/vod/00000000020000000415.mpg/。06/07/12 04:58:20:796 *(Clinet => Server)*COMMAND*SETUP rtsp:/01/008/vod/00000000020000000415.mpg/trackID=1 RTSP/1.0。06/07/12 04:58:20:796 *(Server => Clinet)*RE

33、SPONSE*RTSP/1.0 200 OKServer: ZMSS/V1.20.033E (Build/2006.06.12; Platform/Linux; Release/ZMSS; )。06/07/12 04:58:20:796 *(Clinet => Server)*COMMAND*PLAY rtsp:/01/008/vod/00000000020000000415.mpg?userid=26770602&clienttype=1&mediaid=0000000。06/07/12 04:58:20:796 *(Server => Cl

34、inet)*RESPONSE*RTSP/1.0 200 OK。RTP-Info: url=rtsp:/01/008/vod/00000000020000000415.mpg/trackID=1;seq=0;rtptime=006/07/12 04:58:20:453 RTSP: *<Server => Client>*COMMAND*SET_PARAMETER rtsp:/01/008/vod/00000000020000000415.mpg RTSP/1.0CSeq: 1x-SpeedupPlay:NO1.2.4 RSVPRSVP

35、協(xié)議是一種可以提供音頻、視頻、數(shù)據(jù)等混合服務(wù)的互聯(lián)網(wǎng)絡(luò)綜合服務(wù)（IIS Internet Integrated service ) RSVP97,RFC1633。通過(guò)它，主機(jī)端可以向網(wǎng)絡(luò)申請(qǐng)?zhí)囟ǖ腝oS，為特定的應(yīng)用程序提供有保障的數(shù)據(jù)流服務(wù)。同時(shí)RSVP在數(shù)據(jù)流經(jīng)過(guò)的各個(gè)路由器節(jié)點(diǎn)上對(duì)資源進(jìn)行預(yù)留，并維持該狀態(tài)直到應(yīng)用程序釋放這些資源。RSVP對(duì)資源的申請(qǐng)是單向的，所以RSVP在申請(qǐng)資源的過(guò)程中發(fā)送端和接受端是邏輯上完全不同的兩個(gè)部分。（雖然發(fā)送端和接受端可以運(yùn)行在同一個(gè)進(jìn)程下）。RSVP工作在IPv4或IPv6上，處于 OSI七層協(xié)議中的傳送層，但是，RSVP并不處理傳送層的數(shù)據(jù)，從本質(zhì)上看，RSVP更象是網(wǎng)絡(luò)控制協(xié)議，如ICMP（Internet Control Message Protocol），IGMP（Internet Group Management Protocol）或是路由協(xié)議。和路由協(xié)議及管理協(xié)議的實(shí)現(xiàn)相同，RSVP的實(shí)現(xiàn)通常在后臺(tái)執(zhí)行，而不是出現(xiàn)在數(shù)據(jù)傳送的路