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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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