第六章多媒体网路(MultimediaNetworking).ppt

多媒體網路 (Multimedia Networking) 簡介 隨著網路的快速發展，我們在網路上使用多媒體資料的機會越來越多，同時多媒體網路也漸漸受到重視，所以就有許多因應多媒體網路的協定產生了。 網路中的多媒體 在網路中的多媒體有以下幾個特徵： 對於延遲（delay）較敏感 可以容忍資料遺失（loss tolerant） 資料具有連續性（continuous data） 網路中的多媒體（2） 多媒體應用程式的分類 串流儲存式（streaming stored）的audio和video 先從網路下載多媒體檔案，再播放 串流即時式（streaming live）的audio和video 直接透過網路播放多媒體檔案 即時交談式（real-time interactive）video 可依照我們的需求播放多媒體檔案 網路中的多媒體（3） 串流儲存式（streaming stored）的audio和video 由使用者端去要求播放事先儲存在伺服器端的多媒體檔案並透過網路傳送 使用者可控制多媒體檔案的播放 延遲：從使用者要求到播放開始的時間大約會有1秒到10秒之間 網路中的多媒體（4） 單向即時（unidirectional real-time）模式 因為real-time所以直接由網路傳送播放 也因為是即時播放，所以使用者不能控制多媒體播放，只能聽和看 例如：線上TV，線上廣播 網路中的多媒體（5） 交談式即時（Interactive real-time）模式 因為real-time所以直接由網路傳送播放 但是因為為交談式所以所傳送的資料並不像單向模式那麼簡單，所以所造成的延遲會增加 Video： 150 msec可接受範圍 Audio： 150 msec為良好，400可接受範圍 Jitter 在同一個多媒體串流中的封包的延遲變化程度 網路中的多媒體（6） 在我們現在所使用的Internet是使用best effort傳送，所以對於傳送多媒體資料會有很大的影響，例如：沒有辦法對於delay或是delay variation提供保證 目前往處理封包大都是： 每一個封包的地位平等 FIFO 所以我們必須將所要處理的封包做分類 如何應用現在的網路傳送多媒體 使用UDP來傳送 在接收端使用暫存器和控制播放的速度已減少jitter 將封包加上時間標籤以利播放 將不重要的封包丟掉 如何使現在的網路更適合傳送多媒體 我們必須改變網路所使用的協定可以讓我們所使用的應用程式可以預先保留端對端的頻寬 所使用的協定必須要可以保留頻寬 例如：RSVP 必須改變router上scheduling policies來實現保留頻寬 我們必須需要更複雜的軟體來實現在使用者和router上面 Streaming Stored Audio Video Streaming stored media Audio和vedio檔案儲存在伺服器裡 由使用者發出要求存取 Audio和vedio檔案會在請求後10秒後送出 與伺服器端的交談行為是允許的 這裡指的是我們可以將多媒體檔案依照我們需求作動作（暫停、倒轉、前進） Streaming Stored Audio Video Media player 移除jitter 解壓縮多媒體檔案 錯誤更正 圖形化介面讓我們更好控制多媒體播放 可以讓我們將播放程式嵌入到瀏覽器中 例如：Microsoft media player、Quick time、Real time player… 網頁伺服器的多媒體串流（1） 瀏覽器透過HTTP要求多媒體資料 伺服器透過HTTP回應瀏覽器 瀏覽器會去呼叫media player來播放多媒體資料 缺點： Media player必須透過瀏覽器和伺服器溝通 網頁伺服器的多媒體串流（2） 瀏覽器和伺服器一樣透過HTTP溝通 瀏覽器只會收到meta file，並且呼叫media player Media player會透過TCP和伺服器建立連線，並使用HTTP交換訊息且開始播放檔案 缺點： 雖然不需透過瀏覽器接收多媒體資料，但是透過HTTP不能讓我們使用快轉、倒轉、暫停等功能 也許我們可以試試使用UDP來傳送 多媒體串流伺服器 透過網頁伺服器達成多媒體需求的溝通 Media player再與多媒體串流伺服器利用UDP溝通，取代了TCP的使用 即時串流協定（Real Time Streaming Protocol: RTSP） RFC：2326 用戶端與伺服器模式的應用層協定 提供使用者一些控制多媒體功能，例如：快轉、倒轉、暫停等… 使用HTTP協定傳送多媒體資料，但是HTTP本身無法儲存連續性的多媒體資料 即時串流協定（Real Time Streaming Protocol: RTSP）（續） RTS