第二章-IPTV-網(wǎng)絡(luò)部分-流媒體的傳輸與控制協(xié)議-5

1、IPTV-網(wǎng)絡(luò)部分-流媒體傳輸和控制協(xié)議謝衛(wèi)華IPTV流媒體傳輸與控制協(xié)議 流媒體傳輸和控制協(xié)議概述 流媒體基礎(chǔ)網(wǎng)絡(luò)協(xié)議 TCP、UDP(傳輸層) IP協(xié)議(互聯(lián)網(wǎng)層) 流媒體傳輸協(xié)議 RTP、RTCP，RTP為實(shí)時(shí)傳輸協(xié)議，通過UDP協(xié)議傳輸。RTCP為實(shí)時(shí)傳輸控制協(xié)議，可以通過TCP協(xié)議傳輸，也可以通過UDP協(xié)議傳輸，但與RTP采用不同的端口號，加以分離 RTSP，RTSP為實(shí)時(shí)流協(xié)議，也可以說是話路控制協(xié)議，支持如像VCR那樣的操作控制，如暫停、快進(jìn)、快退等。RTSP也通過UDP來傳輸 RSVP，RSVP協(xié)議為資源預(yù)留協(xié)議，屬傳輸層范圍的協(xié)議，對沿路由的路由器提出控制帶寬(預(yù)留)的要求，

2、以保證某些信號帶寬穩(wěn)定的需求IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 舊的互聯(lián)網(wǎng)的特點(diǎn)，數(shù)據(jù)量小，實(shí)時(shí)性低，帶寬低，可靠性差 新的多媒體業(yè)務(wù)流需求必須適應(yīng)多媒體業(yè)務(wù)流傳輸IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 高帶寬和高壓縮率 即使是傳輸壓縮數(shù)據(jù)，對帶寬的要求還是很大的，MPEG-1的帶寬要求是1.5Mbps，MPEG-2則為1.5-40Mbps；為了在更窄的頻帶上傳輸實(shí)時(shí)高清信息，則要求采用更高的視頻壓縮編碼技術(shù)，如MPEG一4或ASF等壓縮方案，H264至少要8Mbps 多媒體數(shù)據(jù)流對帶寬的需求還表現(xiàn)出單向的特性，這是因?yàn)槎嗝襟w應(yīng)用多為非對稱的結(jié)構(gòu)，即往往是從發(fā)送方傳

3、送大量的數(shù)據(jù)流給接收方，而反向的傳輸量則很小IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 低傳輸延遲 對交互的分布式多媒體應(yīng)用而言，比帶寬更加難以處理的是傳輸延遲問題。傳輸延遲的一個(gè)表現(xiàn)形式是端到端延遲(endtoend delay) 多媒體視頻會議的實(shí)踐和ITU的建議將交互式視頻應(yīng)用的端到端延遲限制在150ms以內(nèi) 傳輸延遲的另一個(gè)表現(xiàn)形式是傳輸抖動(jitter)。抖動是傳輸中各個(gè)分組的不同傳送時(shí)間和錯(cuò)序造成的IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 低傳輸延遲 根據(jù)150ms的傳輸延遲限制，整個(gè)傳輸分為4部分 源端點(diǎn)的壓縮和打包延時(shí)。由于視頻源必須處理每秒25-30幀的視

4、頻，那么實(shí)時(shí)壓縮解壓縮的處理能力必須達(dá)到30-40ms以內(nèi)。這是網(wǎng)絡(luò)延時(shí)中較小的一部分。 終端排隊(duì)和等時(shí)延時(shí)。數(shù)據(jù)包排隊(duì)進(jìn)入終端以后，進(jìn)入回放緩沖區(qū)，直到調(diào)度出緩沖區(qū)，這段延時(shí)也是40ms左右 終端的解包和解壓縮延時(shí)。從回放緩沖區(qū)調(diào)度出來的數(shù)據(jù)包經(jīng)過解包和解壓縮，這段耗時(shí)與壓縮和打包延時(shí)相同，為30-40ms 傳輸?shù)亩说蕉搜訒r(shí)。經(jīng)過其他階段的延時(shí)，傳輸?shù)亩说蕉搜訒r(shí)被限制在40ms以內(nèi)IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 低傳輸延遲 端到端延時(shí)包括線路延時(shí)和網(wǎng)絡(luò)中路由器、網(wǎng)關(guān)等邏輯部分的處理與存儲轉(zhuǎn)發(fā)的延時(shí)。前者無法減少。解決端到端延遲的核心環(huán)節(jié)是如何降低路由器等器件的處理與存儲轉(zhuǎn)

5、發(fā)延時(shí) 分組交換在網(wǎng)絡(luò)中間的每個(gè)節(jié)點(diǎn)上都進(jìn)行差錯(cuò)檢驗(yàn)，如果出現(xiàn)差錯(cuò)，則進(jìn)行重傳，因此端到端延時(shí)較大 幀中繼只做差錯(cuò)檢驗(yàn)，如果出現(xiàn)差錯(cuò)，則丟棄信包，而數(shù)據(jù)重傳等恢復(fù)工作交給端點(diǎn)完成，這樣在一般情況下，端到端延時(shí)較小 ATM差 錯(cuò)檢驗(yàn)工作都交給端點(diǎn)去完成，交換節(jié)點(diǎn)的惟一工作就是傳送信包，因此端到端延時(shí)最小IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 支持組播模式 分布式多媒體應(yīng)用系統(tǒng)要求網(wǎng)絡(luò)支持多播的通信模式，這尤其體現(xiàn)在多點(diǎn)視頻會議系統(tǒng)中 由于單播與廣播的局限性，在實(shí)踐中產(chǎn)生組播的概念 多播設(shè)置了一個(gè)多播組，源節(jié)點(diǎn)僅將數(shù)據(jù)同時(shí)傳送至多播組中的節(jié)點(diǎn)，數(shù)據(jù)的拷貝和發(fā)送都由網(wǎng)絡(luò)動態(tài)完成， 最大限

6、度地保證數(shù)據(jù)占用盡可能少的帶寬資源，這正是符合分布式多媒體多點(diǎn)傳輸要求IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 可靠性 傳統(tǒng)的網(wǎng)絡(luò)傳輸目標(biāo)是提供可靠的端到端的通信 通信系統(tǒng)采用校驗(yàn)(如CRC校驗(yàn))及序列編號的方法，進(jìn)行差錯(cuò)檢驗(yàn)；采用反向應(yīng)答、信包重傳的握手協(xié)議進(jìn)行差錯(cuò)恢復(fù) 系統(tǒng)有必要把差錯(cuò)檢驗(yàn)和差錯(cuò)恢復(fù)工作交給上層完成，下層網(wǎng)絡(luò)只需為上層提供反映物理傳 輸特性的服務(wù)IPTV流媒體傳輸與控制協(xié)議 流媒體的網(wǎng)絡(luò)傳輸特征 通道同步 視頻流、音頻流及其他數(shù)據(jù)流從不同的傳輸通路，經(jīng)由不同的路由到達(dá)終端節(jié)點(diǎn)時(shí)，有必要采取一定的機(jī)制實(shí)現(xiàn)異種數(shù)據(jù)流之間的同步問題，這稱為通道同步問 題 不同通道的同步

7、問題可以通過設(shè)置時(shí)間戳與開辟回放緩沖區(qū)來解決，這屬于端 到端的協(xié)調(diào)任務(wù)IPTV流媒體傳輸與控制協(xié)議 多媒體網(wǎng)絡(luò)的服務(wù)質(zhì)量(QoS)問 題 多媒體與網(wǎng)絡(luò)要解決的核心問題 提高服務(wù)質(zhì)量，涉及到網(wǎng)絡(luò)的底層物理傳輸模式、網(wǎng)絡(luò)協(xié)議堆棧的內(nèi)容與結(jié)構(gòu)、網(wǎng)絡(luò)應(yīng)用系統(tǒng)的相關(guān)控制 等多方面的內(nèi)容，單純從一個(gè)方面是不能夠解決這個(gè)問題IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 功能描述 UDP和TCP能夠?qū)碜圆煌瑧?yīng)用程序的數(shù)據(jù)流進(jìn)行復(fù)用，并提供校驗(yàn) 如果在接收的包中檢測到有一個(gè)以上的誤碼，TCPUDP層就丟掉這個(gè)包，這樣上一層(例如RTP)將不會收到這個(gè)損壞的包 TCP重傳所引入的延遲對于具有嚴(yán)格延遲要

8、求的流應(yīng)用來說是不可接受的，因此一般用UDP作為視頻流傳輸協(xié)議IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 功能描述 由于UDP不能保證包的傳輸，所以接收端必須依靠上一層協(xié)議(即RTP)來檢測包的丟失。RTP是一個(gè)因特網(wǎng)標(biāo)準(zhǔn)協(xié)議，用于提供端對端的傳輸功能，以便支持實(shí)時(shí)應(yīng)用 RTCP是為了向RTP話路的參與者提供QoS反饋IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 功能描述 RTCP并不保證QoS或可靠性傳輸，結(jié)合RTP提供以下支持媒體流的功能 時(shí)間戳：RTP提供時(shí)間標(biāo)記，用于不同媒體流之間的同步 序列編號：由于到達(dá)接收端的數(shù)據(jù)包可能是不按次序的(UDP不按次序傳送數(shù)據(jù)包)

9、，RTP用序列編號對接收到的數(shù)據(jù)包進(jìn)行正確的排序 有效載荷類型識別：包含在RTP包中的有效載荷類型由一個(gè)稱為有效載荷類型識別符的RTP包頭域來指示 信源識別：每一個(gè)RTP包的信源由一個(gè)稱為同步信源識別符(SSRC)的R rP包頭域來指示IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 功能描述 RTCP提供的服務(wù) QoS反饋：這是RTCP的首要功能 參與者識別：信源可以由RTP包頭的SSRC域來識別 控制包定標(biāo)：為了給發(fā)送到若干參與者的RTCP控制包定標(biāo) 媒體間同步：RTCP發(fā)信方報(bào)告含有實(shí)時(shí)指示和相應(yīng)的RTP時(shí)間戳 最少話路控制信息：這項(xiàng)可選功能用于傳送話路信息，如參與者的名字IPTV

10、流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 RTP對數(shù)據(jù)傳輸?shù)姆庋b 數(shù)據(jù)類型PT(pay)oad type) 時(shí)間戳(Time Stamp) 序列號(SeqNumber) 標(biāo)志位M(ma rker) 同步源標(biāo)識SSRC(synch ron1 zat1 OnS0Urce)IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 RTCP協(xié)議概述 RTCP協(xié)議將控制包周期性發(fā)送給所有連接者，采用與RTP數(shù)據(jù)包相同的分布機(jī)制，低層協(xié)議提供數(shù)據(jù)包與控制包的復(fù)用，使用單獨(dú)的UDP端口號或使用TCP協(xié)議來傳輸 對于RTP會話或者廣播，通常使用組播地址，屬于這個(gè)會話的所有RTP和RTCP信息包都使用這個(gè)組

11、播地址，通過使用TCP或不同的端口號，可以把RTP信息包和RTCP信息包區(qū)分開來IPTV流媒體傳輸與控制協(xié)議 RTPRTCP協(xié)議族概述 RTCP包格式 RTCP包的類型 SR：發(fā)送報(bào)告，當(dāng)前發(fā)送者的發(fā)送和接收統(tǒng)計(jì) RR：接收報(bào)告，非發(fā)送者發(fā)出的接收統(tǒng)計(jì) SDES：源描述項(xiàng)，包括規(guī)范名字項(xiàng)CNAME BYE：表示結(jié)束 APP：特定應(yīng)用功能 RTCP控制包 每個(gè)RTCP控制包包括一個(gè)固定包頭和可變長的數(shù)據(jù)部分IPTV流媒體傳輸與控制協(xié)議 RTCP的傳輸間隔 RTP設(shè)計(jì)成允許自動擴(kuò)展?fàn)顟B(tài)，連接用戶數(shù)可以從幾個(gè)到上千個(gè)，而對于組播，不管連接者的數(shù)目有多少，數(shù)據(jù)速率是一個(gè)定數(shù) RTCP控制信號流量是應(yīng)該

12、受控的。如每個(gè)參加者都以固定速率發(fā)送接收報(bào)告，則控制信號流量將隨參加者數(shù)目而線性增長，因此速率必須根據(jù)參加者數(shù)目按比例下降，而不是采用固定速率IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議功能 RTSP的一個(gè)主要功能是支持類擬VCR的控制操作，如停止、暫停重新開始、快進(jìn)和快退 RTSP還可以提供選擇傳輸通道(例如，UDP、組播UDP或TCP)的方法以及基于RTP的傳輸機(jī)制 建立和控制在媒體服務(wù)器和客戶機(jī)之間的連續(xù)的音頻視頻媒體流IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議 RTSP交互原理 RTSP為流音頻和視頻提供的服務(wù)與HTTP(超文本傳輸協(xié)議)為文本和圖形所提供的服務(wù)相同 RTSP中，每一個(gè)演

13、示和媒體流都被一個(gè)RTSP URL(通用資源定位器)所識別 RTSP用于從媒體服務(wù)器啟動和直接傳送流媒體數(shù)據(jù)IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議的特點(diǎn) 可擴(kuò)展性 易解析 安全 獨(dú)立于傳輸 多服務(wù)器支持IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議的特點(diǎn) 記錄設(shè)備控制 流控與會議開始分離 適合專業(yè)應(yīng)用 演示描述便捷 代理與防火墻友好 HTTP友好IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議的特點(diǎn) 方便的服務(wù)器控制 傳輸協(xié)調(diào) 性能協(xié)調(diào) 操作模式多樣化 單播： 以用戶選擇的端口號將媒體發(fā)送到RTSP請求源 組播，服務(wù)器選擇地址：媒體服務(wù)器選擇組播地址和端口，這是現(xiàn)場直播或準(zhǔn)點(diǎn)播常用的方式 組播，用戶

14、選擇地址：如服務(wù)器加入正在進(jìn)行的組播會議，組播地址、端口和密匙由會議描述給出IPTV流媒體傳輸與控制協(xié)議 RTSP協(xié)議參數(shù) 版本 RTSP URL 會話標(biāo)識 連接標(biāo)識 SMPTE 時(shí)標(biāo) 正常播放時(shí)間 絕對時(shí)間 可選標(biāo)簽IPTV流媒體傳輸與控制協(xié)議 RSVP協(xié)議 RSVP協(xié)議的作用及要求 針對Internet原有傳輸層協(xié)議不能保障QoS和不支持多點(diǎn)傳輸?shù)娜秉c(diǎn)，RSVP在業(yè)務(wù)流傳送之前，預(yù)約一定的網(wǎng)絡(luò)資源，建立靜態(tài)或動態(tài)的傳輸邏輯通路，保障了每一業(yè)務(wù)流都有足夠的“獨(dú)享”的帶寬，克服了由于網(wǎng)絡(luò)信包過多引起的擁塞、丟失和重傳，提高了網(wǎng)絡(luò)傳輸?shù)腝oS性能IPTV流媒體傳輸與控制協(xié)議 RSVP協(xié)議 RSV

15、P的特征 接收方執(zhí)行資源預(yù)留，是由接收方初始化并執(zhí)行操作的資源預(yù)留協(xié)議 不同的預(yù)留類型，無濾包器的形式、固定濾包器的形式和動態(tài)濾包器的形式 維護(hù)網(wǎng)絡(luò)的“實(shí)時(shí)狀態(tài)” ，在交換節(jié)點(diǎn)設(shè)置“實(shí)時(shí)狀態(tài)”記錄當(dāng)前的系統(tǒng)信息，并將維護(hù)預(yù)留資源的責(zé)任交給終端用戶?！皩?shí)時(shí)狀態(tài)”是指在交換節(jié)點(diǎn)中記錄的系統(tǒng)信息，RSVP應(yīng)自動地維護(hù)它。 協(xié)議過載是指因協(xié)議管理信息過多而引起的網(wǎng)絡(luò)過載現(xiàn)象。RSVP的過載由3個(gè)因素決定：RSVP消息(預(yù)留消息和路徑消息)的數(shù)目、RSVP消息的大小和消息發(fā)出的頻率IPTV流媒體傳輸與控制協(xié)議 RSVP協(xié)議 RSVP操作模型 RSVP資源預(yù)留處理初始化 RSVP中心服務(wù)器查詢本地路由器的路由表獲得路由信息 主機(jī)發(fā)送IGMP消息，加入組播行列 沿路由發(fā)送RSVP預(yù)留資源信息 每個(gè)加入資源預(yù)留的路由器將收到的數(shù)據(jù)包傳送給包分類器，RSVP包分類器決定每個(gè)數(shù)據(jù)包的路由和QoS類別 然后將數(shù)據(jù)包傳送至包調(diào)度器中排隊(duì)IPTV流媒體傳輸與控制協(xié)議 RSVP協(xié)議 RSVP操作模型 RSVP包調(diào)度器給每個(gè)接口對應(yīng)的數(shù)據(jù)鏈路層媒介分配資源，如果數(shù)據(jù)鏈路層媒介自身有QoS的管理能力，則