《多媒体网路》PPT课件.ppt
《《多媒体网路》PPT课件.ppt》由会员分享,可在线阅读,更多相关《《多媒体网路》PPT课件.ppt(109页珍藏版)》请在三一办公上搜索。
1、第六章多媒體網路(Multimedia Networking),簡介,隨著網路的快速發展,我們在網路上使用多媒體資料的機會越來越多,同時多媒體網路也漸漸受到重視,所以就有許多因應多媒體網路的協定產生了。,簡介,本章節的目的:在多媒體網路中的服務所需要的條件在現今best-effort的網路如何達到最佳的效果瞭解現在有哪一些協定是使用在多媒體網路中的例如:RTSPRTPH.323SIP,本章節所要介紹的是:多媒體網路中的應用程式streaming stored audio and videoRTSPinteractive real-time appsInternet phone exampleR
2、TPH.323 and SIPbeyond best effortscheduling and policingintegrated services(Insserv)differentiated services(Disserv),網路中的多媒體,在網路中的多媒體有以下幾個特徵:對於延遲(delay)較敏感可以容忍資料遺失(loss tolerant)資料具有連續性(continuous data),網路中的多媒體(2),多媒體應用程式的分類串流儲存式(streaming stored)的audio和video先從網路下載多媒體檔案,再播放串流即時式(streaming live)的audi
3、o和video直接透過網路播放多媒體檔案即時交談式(real-time interactive)video可依照我們的需求播放多媒體檔案,網路中的多媒體(3),串流儲存式(streaming stored)的audio和video由使用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送使用者可控制多媒體檔案的播放延遲:從使用者要求到播放開始的時間大約會有1秒到10秒之間,網路中的多媒體(4),單向即時(unidirectional real-time)模式因為real-time所以直接由網路傳送播放也因為是即時播放,所以使用者不能控制多媒體播放,只能聽和看例如:線上TV,線上廣播,網路
4、中的多媒體(5),交談式即時(Interactive real-time)模式因為real-time所以直接由網路傳送播放但是因為為交談式所以所傳送的資料並不像單向模式那麼簡單,所以所造成的延遲會增加Video:150 msec可接受範圍Audio:150 msec為良好,400可接受範圍Jitter在同一個多媒體串流中的封包的延遲變化程度,網路中的多媒體(6),在我們現在所使用的Internet是使用best effort傳送,所以對於傳送多媒體資料會有很大的影響,例如:沒有辦法對於delay或是delay variation提供保證目前往處理封包大都是:每一個封包的地位平等FIFO所以我們
5、必須將所要處理的封包做分類,如何應用現在的網路傳送多媒體,使用UDP來傳送在接收端使用暫存器和控制播放的速度已減少jitter將封包加上時間標籤以利播放將不重要的封包丟掉,如何使現在的網路更適合傳送多媒體,我們必須改變網路所使用的協定可以讓我們所使用的應用程式可以預先保留端對端的頻寬所使用的協定必須要可以保留頻寬例如:RSVP必須改變router上scheduling policies來實現保留頻寬我們必須需要更複雜的軟體來實現在使用者和router上面,Streaming Stored&Audio&Video,Streaming stored mediaAudio和vedio檔案儲存在伺服器
6、裡由使用者發出要求存取Audio和vedio檔案會在請求後10秒後送出與伺服器端的交談行為是允許的這裡指的是我們可以將多媒體檔案依照我們需求作動作(暫停、倒轉、前進),Streaming Stored&Audio&Video,Media player移除jitter解壓縮多媒體檔案錯誤更正圖形化介面讓我們更好控制多媒體播放可以讓我們將播放程式嵌入到瀏覽器中例如:Microsoft media player、Quick time、Real time player,網頁伺服器的多媒體串流(1),瀏覽器透過HTTP要求多媒體資料伺服器透過HTTP回應瀏覽器瀏覽器會去呼叫media player來播放
7、多媒體資料缺點:Media player必須透過瀏覽器和伺服器溝通,網頁伺服器的多媒體串流(2),瀏覽器和伺服器一樣透過HTTP溝通瀏覽器只會收到meta file,並且呼叫media playerMedia player會透過TCP和伺服器建立連線,並使用HTTP交換訊息且開始播放檔案缺點:雖然不需透過瀏覽器接收多媒體資料,但是透過HTTP不能讓我們使用快轉、倒轉、暫停等功能也許我們可以試試使用UDP來傳送,多媒體串流伺服器,透過網頁伺服器達成多媒體需求的溝通Media player再與多媒體串流伺服器利用UDP溝通,取代了TCP的使用,即時串流協定(Real Time Streaming
8、Protocol:RTSP),RFC:2326用戶端與伺服器模式的應用層協定提供使用者一些控制多媒體功能,例如:快轉、倒轉、暫停等使用HTTP協定傳送多媒體資料,但是HTTP本身無法儲存連續性的多媒體資料,即時串流協定(Real Time Streaming Protocol:RTSP)(續),RTSP的缺點無法定義要如何對多媒體資料加封無法限制多媒體資料透過什麼協定傳送無法定義media player如何暫存資料現實網路當中我們大多使用RTSP來當作傳送控制訊號(control message)的協定,out of band control,RTSP的控制信息和多媒體資料使用不同的port號
9、,所以我們稱為out-of-band多媒體資料的資料結構並不是定義在RTSP,所以我們認為是in-band如果RTSP的信息和傳送多媒體資料的port有重複的話,我們稱為interleaved,RTSP的運作程序,Meta file的範例,Twister,RTSP session,每一個RTSP都有一個session的識別號,每一個識別號由伺服器選定用戶端使用SETUP發出請求,然後伺服器會回應一個識別號給用戶端用戶端會一直使用這一個識別號直到這一個session結束為止,RTSP交換訊息範例,Transport:rtp/udp;compression;port=3056;mode=PLAY
10、S:RTSP/1.0 200 1 OK Session 4231 Session:4231 Range:npt=0-Session:4231 Range:npt=37 Session:4231 S:200 3 OK,Real-time interactive applications,我們大多所使用的交談式應用有:PC對PC的電話PC對家用電話DialpadNet2phone視訊會議Web cams接著我們將詳細介紹PC對PC的網路電話,Internet phone over best-effort(1),之前提過在現今網路會有packet delay、loss 和 jitterInterne
11、t phone的例子在通話時才會產生封包Bit rate為64kbps通話時每20 msec會產生160 bytes的chunkChunkheader加封後利用UDP傳送因為有可能資料流失,所以接收端必須有判斷的機制,Internet phone(2),Packet loss使用UDP加封封包Datagram可能會超出router queue的TCP可以減少loss但是會增加delay端對端的延遲端對端的延遲在400 msec以內我們可以接受Delay jitter必須要在20 msec內移除jitter的方法sequence numberstimestampsdelaying playout
12、,Internet phone(3):fixed playout delay,這裡是使用固定的delay time q,而每一個trunk會被mark上一個time stamp所以再接收端會在time=t+q時播放如果超出這歌時間就會丟棄這個資料所以在這裡不需要sequence numberq在這裡是一個trade off較大的q,較少的封包被丟棄較小的q,有較好的交談性,Internet phone(4):fixed playout delay,First playout schedule:begins at p Second playout schedule:begins at p,Rec
13、overy from packet loss(1),Loss:是因為資料遺失或是超過播放的時間限制forward error correction(FEC)每n個chunk為一個group,並加入一個額外的XOR chunk所以總共會送出n+1個trunk,並會增加頻寬的1/n可以從n+1 chunks中更正一個chunk接收所有chunks的延遲必須要固定Trade offn增加,頻寬、loss rate和播放延遲亦會增加,Recovery from packet loss(2),2nd FEC scheme下一個封包會夾帶一個跟前一個一樣但quality較差的封包,萬一前一個封包掉了,後一
14、個可以補回來,Recovery from packet loss(3),Interleaving將一個封包在細分成數個小單位,然後前後交叉傳送以降低loss的機會,Real-Time Protocol(RTP),RFC:1889和前面的RTSP所不同的是RTP為了封包攜帶audio和video有定義封包的結構RTP封包提供了封包攜帶的資料格式識別封包序號編號時間標記RTP通常在終端系統使用RTP使用UDP來加封封包,RTP runs on top of UDP,RTP和UDP共同組成了傳送層應用成的程式透過RTP和UDP溝通因為RTP是為了額外提供:埠號,IP位址錯誤更正資料格式識別封包序號編
15、號時間標記,RTP and QoS,RTP並沒有提供適時的資料傳送和任何麼品質服務保證RTP對於封包的加封只會在終端系統看的出來因為如此在傳統的routing機制中沒有辦法對於RTP所傳送的封包最任何特別的服務所以為了提供應用程式有品質服務保證,在網路之中必須使用類似RSVP這樣可以預先保留頻寬的機制來提供所需要的品質保證,RTP Header,Payload Type(7 bits):提供了128種可能的encoding的方法Payload type 0:PCM mu-law,64 KbpsPayload type 3,GSM,13 KbpsPayload type 7,LPC,2.4 Kb
16、psPayload type 26,Motion JPEGPayload type 31.H.261Payload type 33,MPEG2 videoSequence Number(16 bits):用來偵測封包的遺失LOSS,RTP Header,Timestamp field(32 bytes):用來反映出第一個資料封包的採樣和用來移除jitterSynchronization Source identifier(SSRC):32 bits,當作是一個資料源頭的識別號,這一個識別好是亂數決定的,Real-Time Control Protocol(RTCP),和RTP會同時發生作用每一
17、個RTP的session會用RTCP溝通,讓應用程式獲得有用的資訊並且會統計有多少個封包被傳送、多少封包遺失、jitter變化有了這一些資訊應用程式可以用來調整效能例如:loss rate增大時,RTCP-Continued,每一個RTP session都會有一個multicast address,而所有屬於這一個session的RTP和RTCP都會使用這一個addressRTP和RTCP的封包是由不同的埠號來區分RTCP會有三種report packetsReceiver report packetsSender report packetsSource description packet
18、s,RTCP-report packets,Receiver report packets紀錄封包遺失的片段、遺失的sequence number、平均的inter-arrival jitterSender report packetsRTP串流的SSRC、現在的時間、現在所傳送的封包個數和現在所傳送的byte數Source description packets傳送者的e-mail、傳送者的名字、RTP串流所相關的SSRC,這一個封包提供了SSRC和使用者(機器)之間的對應,串流的同步,RTCP可以用來同步在同一個RTP session裡的多媒體串流例如:視訊會議裡包含影像和聲音在RTP封包
19、裡的時間標記是依附video或audio的取樣率決定的,而不是real-time的接收端會使用sender report packet的資訊來做同步,RTCP Bandwidth Scaling,RTCP約佔整個session的頻寬的5%例如:傳送的速率為2Mbps,則RTCP約為100kbps如果每一個接收端都傳送RTCP給所有其他的接收端,這樣RTCP的traffic會很大RTCP佔的100kbps會在分為接收端75kbps(75%)和傳送端的25kbps(25%),H.323,H.323亦是為了在網路上傳送多媒體資料所產生的一個協定,較有名的應用程式為:Microsoft Net mee
20、ting接著我們將簡單介紹H.323這一個協定OverviewH.323 terminalH.323 encodingGatekeeperGatewayAudio codecsVideo codecs,Overview(1),目標:可以達到即時的通訊由ITU所建議使用應用的範圍單獨的機器(例如:網路電話)在PC上的應用點對點或是多點的視訊會議,Overview(2),在H.323裡面定義了端點的機器如何撥接一個呼叫(call)端點的機器如何交換共同的audio/video解碼Audio和video如何加封來透過網路傳送Audio和video如何同步端點的機器如何和他的gatekeeper溝通網
21、路電話和一般PSTN/ISDN的電話如何溝通,Overview(3),Telephone callsVideo callsConferencesWhiteboards所有的機器必須支援H.323,Overview(4),H.323,SS7,Inband,H.323的端點機器必須支援,G.711 ITU 所制訂的語音壓縮標準RTP 將多媒體加封的協定H.245 在端點機器之間用來傳送控制訊號的“Out-of-band”控制協定Q.931 用來建立撥接的signaling協定RAS(Registration/Admission/Status)通道協定 用來和gatekeeper溝通的協定,H.32
22、3 Terminal,H.323的編碼(encoding),AudioH.323的終端機器必須支援G.711,用來傳送壓縮的與語音,voice rate=56/64 kbpsOptional:G.722,G.728,G.729Video對於H.323的終端機器是optional終端機器必須支援QCIF H.261(176x144 像素)H.261 option:CIF,4CIF,16CIFH.261是用來和使用多重64kbps的頻道溝通,Generating audio packet stream in H.323,AudioSource,Encoding:e.g.,G.711,RTP pac
23、ketencapsulation,UDP socket,Internet orGatekeeper,H.245 Control Channel,一個H.323串流可能會包含多個不同種類的多媒體資料每一個H.323 session都會有一個H.245的控制頻道H.245控制頻道是一個reliable(TCP)的控制頻道主要任務開啟或關閉一個多媒體頻道相容性的交換在開始傳送資料前,會先交換編碼的演算法,Information flows,Gatekeeper(1),在這裡gatekeeper是optional,提供位址轉換成IP位址頻寬的管理因為billing的方便,H.323的calls可能會由
24、gatekeeper管理RAS是用來terminal-gatekeeper之間溝通的協定,Gatekeeper(2),H.323的設備必須要跟他那個區域的gatekeeper做註冊的動作如果gatekeeper存在的話,每一個終端設備要撥接一個call的前要先經過gatekeeper同意如果獲得同意,終端設備會傳送e-mail給gatekeeper,裡面包含了要轉換成IP位址的資訊,Gateway,IP區域和PSTN(or ISDN)的橋樑終端設備使用H.245和Q.931和gateway溝通,H.323 terminals,Gatekeeper,Router,Internet,LAN=“Zo
25、ne”,RAS,Gateway,PSTN,Audio codecs,MOS(Mean Opinion Score),Video codecs,H.261(p x 64 kbit/s)ISDN上傳送VideoResolutions:QCIF,CIFH.263(64 kbit/s)低速率的溝通Resolutions:SQCIF,QCIF,CIF,4CIF,16CIF,QoS in IP networks,現在的網路並沒有提供QoS的機制,所以IETF有些團體就在制訂一些可以提供QoS機制的protocol目前正在制訂的有RSVP,Differentiated Services和Integrated
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 多媒体网路 多媒体 网路 PPT 课件
链接地址:https://www.31ppt.com/p-5489005.html