私立东海大学资讯工程学系Word文档下载推荐.docx
- 文档编号:3615998
- 上传时间:2023-05-02
- 格式:DOCX
- 页数:40
- 大小:619.96KB
私立东海大学资讯工程学系Word文档下载推荐.docx
《私立东海大学资讯工程学系Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《私立东海大学资讯工程学系Word文档下载推荐.docx(40页珍藏版)》请在冰点文库上搜索。
圖目錄
表目錄
1、簡介
隨著資訊科技的日新月異,網路的服務不再單純的傳遞檔案及資料,也提供了更多元、便利的應用服務,多媒體應用在影音、動畫、視訊傳輸相關的服務已越見普及,如影音串流即時播放下載影像服務,此種經由網路來播放影音軟體的技術,正逐漸被廣泛應用。
常用的通訊協定TCP、UDP應用於影音串流時,各有優缺點。
TCP雖可保證完整送達,但遇上要求時效性的即時影音時(如視訊電話),重傳過期的封包是無意義的。
UDP的封包只傳送一次,整體傳送速率也較快,故適合要求時效性的影音服務,但由於不會因網路狀況調整速率,當網路壅塞時,不旦會遺失過多封包,也會使網路更加壅塞,影響傳輸畫質。
BasicPartial-ReliableTCP「選擇性保證送達」的機制,將重要的封包重傳以保證送到,當MPEG格式的影音串流傳輸時,並不是所有封包都十分重要,我們如果將關鍵畫面(I-Frame)保證送到,較不重要的則否,如此便可在保持一定畫質下,有效減少傳輸量。
在研究過程中,我們發現BasicPR-TCP存在「連線異常中止問題」。
當BasicPR-TCP連續三個(或以上)Regular封包遺失時,連線會發生異常,造成後續封包的傳輸停頓。
為解決此問題,我們提出了另一個機制CWYPR-TCP(ChenWengYangPartial-ReliableTCP),且可有效解決此問題。
本專題實驗使用網路模擬工具NS2來模擬實際網路環境,並以MyEvalVid多媒體品質評估工具進行封包分析。
實驗一為BasicPR-TCP與UDP於同環境下模擬,證實BasicPR-TCP存在著「連線異常中止問題」。
實驗二為CWYPR-TCP與BasicPR-TCP、UDP作比較,證實CWYPR-TCP能解決「連線異常中止問題」,且比UDP的傳輸品質更好。
實驗三為CWYPR-TCP於各種背景干擾下測試,並分析其效能。
2、相關文獻探討
隨著影音傳輸技術的發展,使得傳輸中的影像品質達到更好的效果,本章節將介紹影音傳輸的相關技術,如影音串流、影音編碼、影音壓縮。
此外,還對網路傳輸協定去作探討,像常見的TCP、UDP,並對PartialRiliable-TCP(PR-TCP)[3]選擇性重傳機制做相關研究。
以下將介紹影音傳輸的相關技術。
2.1影音串流
影音串流是一種經由網路來播放影音檔案的技術,基本概念為「一邊下載一邊播放(Playasreceived)」,不同於傳統收看網路影音資料必須等到下載至用戶設備後才可播放的方法,串流技術讓用戶端只需預先下載到部分影音資料即可開始播放,大量節省了使用者在等待下載的時間,例如網路電話、視訊會議、線上教學、即時線上轉播等都為影音串流的應用。
影音串流的運作應包含五大部份:
VideoProducer、VideoServer、WebServer、Internet與Client,其運作流程如圖2.1所示。
VideoProducer將硬體裝置所拍攝到的影像資料進行影像處理過程,並將所得串流影音資料放至VideoServer,由WebServer將特定的port指定給VideoServer,把影音資料串流送出,且利用UDP通訊協定,透過Internet與Client建立串流傳輸,如此一來,Client只需於遠端連結WebServer,即可播放串流資料觀看即時拍攝之影像。
圖2.1影音串流的運作流程圖
以下介紹影音串流之廣泛應用,Streamingclass應用服務,此應用服務規範在網路資訊服務類型,因此,以下將介紹在網路上主要風行的應用依時效與品質需求概略分為四個不同類別[8],與在每一個類別中都有自己對於延遲的容忍能力之相關QoS參數。
其類型可分為以下:
(1)交談式類別(Conversationalclass)[2]—
適合傳輸語音,主要設計為了具有交談性質的即時性應用程式,如網路電話。
由於以較為人性化的服務為主軸、支援雙向溝通,因此根據人類感官之經驗做歸納。
當使用者在應用這類型的服務時,會對longdelaytime與jitter相當敏感,尤其使用者在delaytime超過300ms時,就難以忍受其通話品質。
(2)串流式類別(Streamingclass)[2]—
適合傳輸聲音及影像。
主要設計為了串流性質的多媒體應用程式,如觀賞線上電影、節目,由於要求持續穩定的資料流,因此所要求的延遲時間限制比交談式類別較不嚴格,但也有限制最大延遲時間,對longdelaytime與jitter也算是相當敏感。
(3)互動式類別(Interactiveclass)[2]—
適合傳輸網頁及讀取資料庫的資料。
主要設計為了某些需要有一定程度的輸出率(throughput)的應用程式,如互動網(InteractiveWeb)。
應用程式,如互動網由於屬於datacommunication的服務,可容忍較長的資料傳送時間,此類訊務對傳送間的延遲較不敏感,但是要求要有低的傳送錯誤率,要求正確的資料傳送,因此幾乎無法忍受資料的遺失。
(4)背景式類別(Backgroundclass)[2]—
適合傳輸沒有急切性需求的資料。
主要設計為了傳統無優先等級之分的資料,如電子郵件。
此類型訊務對資料錯誤率也有嚴格的要求。
表2.1各個類別的QoS品質要求
class
DelaySensitivity
JitterSensitivity
PacketLossSensitivity
Conversational
High
Low
Streaming
Medium
Interactive
Background
No
表2.1z]主要歸納出不同類型的服務對於delaytime、jitter及封包遺失的需求,可以發現串流式類別對longdelaytime與jitter算是相當敏感,但並不保證封包能安全送達。
本專題將在第四章實驗結果分析,會依據串流式類別(Streamingclass)去分析影音串流服務品質其相關因素之評估。
2.2多媒體壓縮技術
由於數位影像娛樂產品的迅速發展,使得多媒體需求量的提升,造成網路及記憶體的頻寬大量不足,為此通常是將多媒體資資料經過壓縮編碼處理,再放到網路上進行傳輸。
因此多媒體壓縮技術也定義了很多不同的標準,其適用及應用範圍也有所不同,如視訊壓縮技術、影像壓縮技術、語音壓縮技術等等,而MPEG為普遍性地應用於視訊壓縮的標準,以下將介紹MPEG。
2.2.1MPEG
MPEG全名MovingPictureExpertsGroup。
本來含意為研究視頻和音頻編碼標準的小組。
現在泛指一系列的視頻編碼標準。
該小組於1988年組成,至今已經制定了MPEG-1、MPEG-2、MPEG-3、MPEG-4等多個標準。
一個視頻序列包含一定數量的圖片通常稱為frame,而連續的videoframe之間有很大的相似度,影像壓縮的目的就是要將相似重複的資訊去除,以減少時域的冗餘,通常會先計算相鄰圖片的差異,再將這些差異做處理。
MPEG採用了複合式多重壓縮設計,是種以區塊為基礎的動態補償方法,以前一畫面至目前畫面內容進行預測,或是由前一畫面其下移畫面至目前畫面內容之內插預測,預測所得的差異值,再利用離散餘弦轉換(DiscreteCosineTransform,DCT)除去空間上的相關性,並配合量化(Quantized)程序略除不重要的資訊,最後經由VLC(VariableLengthCoding)方式編碼後與動態向量複合產生視訊壓縮編碼。
以下為介紹MPEG版本。
(1)MPEG-1:
制定於1992年,主要用途為:
視訊會議、影像電話、電腦遊戲與支援第一代的CD-ROM。
傳輸速率為1.5Mbits/sec,每秒播放30張,且具有CD音質。
編碼速率最高可達4-5Mbits/sec,但隨著速率的提高,其解碼後的圖像品質有所降低。
適用於網路上的視訊傳輸,如隨選視訊系統。
(2)MPEG-2[6]:
此標準制定於1994年,設計目的主要是要加強MPEG-1不足的地方,目標要更高的傳輸率,其所能提供的傳輸率在3-10Mbits/sec間,其解析度可達720x486。
音訊編碼可提供左右中及兩個環繞聲道,及一個加重低音聲道,和多達7個伴音聲道,支援Dolby音效。
提供一個較廣的範圍改變壓縮比,以適應不同畫面品質、儲存容量,及頻寬要求。
由於現在電視解析度限制,MPEG-2所帶來的高清晰度畫面質量在電視上效果並不明顯,但其音訊特性更引人注目。
(3)MPEG-3:
本來的目標是為HDTV提供20-40Mbps視頻壓縮技術。
在標準制定的過程中,委員會很快發現MPEG-2可以取得類似的效果。
隨後,MPEG-3項目停止了。
(4)MPEG-4:
MPEG-4針對特定比率下的視訊、音訊編碼,注重多媒體系統的交互性和靈活性。
主要應用於動態圖像、視訊電話、視訊電子郵件、移動多媒體通信和電子新聞等,其傳輸速率要求較低,在4800-64000bits/sec之間,解析度為176x144。
可以利用很窄的頻寬,通過重建技術壓縮和傳輸數據,從而能以最少的數據獲得最佳的圖像質量。
表單的底部
2.2.2MPEG壓縮原理
MPEGu8jn壓縮方式可以用的兩種編碼技術:
畫面內編碼(Intra-framecoding)與畫面間編碼(Inter-framecoding)為當中的主要架構,以下將介紹這兩種編碼的運作原理。
(1)畫面內編碼(Intra-framecoding)[3]:
MPEG視訊壓縮標準定義將每個畫面分割成8*8像素大小的數個區塊,以區塊做為基本的像素轉換編碼單位,其目的為降低處理程序的延遲及複雜性。
為了降低像素間的相關性,每個區塊個別做離散餘弦轉換(DCT)。
將空間信號轉換成頻率信號,轉換後信號能量大部份集中在少數的低頻係數的上,只有少數部份能量會分布在高頻係數上。
隨後量化程序,能方便及有效地達成資料壓縮的目的。
而離散餘弦轉換和量化處理都需要線性轉換或比例調整。
圖2.2Intra-framecoding流程
(2)畫面間編碼(Inter-framecoding)[3]:
主要分為移動估測(MotionEstimation)和移動補償(MotionCompensation)。
移動估測:
目的在於畫面編碼時,到周圍的參考畫面中尋找與與目前畫面相似的區域,找到之後並記錄此區域移動了多少向量,稱之為移動向量(MotionVector)。
移動補償:
則是反過來利用已知的移動向量和鄰近參考畫面,將正確的影像還原回來,一般是以大區塊作為移動估測與移動補償的基本單位。
圖2.3Inter-framecoding流程
在連續的畫面間,相同的位置周圍的像素值有很高的相關性,畫面間編碼主要在消除時間上像素的相關性,達到降低位元率的目的。
畫面分割成數個大區塊,欲編碼的畫面framen會去前一張或後一張重建的參考畫面framen-1的固定搜尋區域內做區塊比對。
假始能在重建畫面framen-1中找到一個很相似的大區塊,則將大區塊間的移動向量進行編碼,並且將兩個大區塊間的差異值傳送到量化程序處理,若找不到相似的大區塊,則直接送到量化程序處理。
2.3
影音在IP網路中傳輸之技術
影音串流可容忍有限度的封包遺失。
以MPEG為例,MPEG是由一張張的畫面(videoframe)組成,videoframe分為I-frame(Intraframe)、P-frame(Predictedframe)與B-frame(Bidirectionalframe)。
所以videoframe在播放與編碼(傳送)的順序是不一樣的,以下將介紹各種不同的videoframe。
(1)I-frame(Intracodedpictures):
I-frame沒有參考過去其他畫面的資料,所編碼的單獨frame,僅使用本身的資料進行編碼經量化後再經VLC(VariableLengthCoding)編碼,所以在解碼時不需參考其他畫面的資料。
I-frame通常是每個畫面群組的第一張,經過適度地壓縮,以作為隨機訪問的參考點,隨後畫面群組裡的P-frame與B-frame都會參考到它的資料,壓縮率低。
(2)P-frame(Predictivecodedpictures):
P-frame在解碼時,會到參考前面較早被播放的I-frame或P-frame,而參考的位置是以移動估測所產生的移動向量來表示,若找不到最適合的大區塊時,則使用Intra模式編碼。
由於參考前一I-frame或P-frame且以動態補償方式預測編碼,其壓縮效率較高。
(3)B-frame(Bidirectionallypredictedpictures):
B-frame在解碼時,會使用到前面及後面兩個方向參考畫面的資料。
如同P-frame一樣,畫面資訊在參考畫面找不到相似的大區塊時,會使用Intra模式編碼。
參考前後畫面做動態補償預測編碼,其壓縮率最大,本身不再做為其他預測編碼用。
一般來講,MPEG的影像可以被解為以GOP(GroupOfPictures)為單位做編碼的動作,如圖2.4所示,GOP的size為10,一般表示為(10,3),10為前一個I-frame到下一個I-frame的畫面數,3為I-frame到P-frame的畫面數。
而不同的videoframe對品質有不同程度的影響,I-frame是從原影像壓縮之後得來的影像,P-frame則參考前面的P-frame或I-frame來組成自己的畫面,B-frame則透過前後參考P-frame或I-frame的影像來構成自己的畫面,所以videoframe在播放與編碼(傳送)的順序是不一樣的,從圖2.4可以看到播放順序為I、B、B、P、B、B、P、B、B、P,而編碼(傳送)順序其實為I、P、B、B、P、B、B、P、B、B,所以I-frame的到達是相當重要的。
當videoframe送到底層被切成一個個小封包,在傳送時若能讓屬於I-frame的封包全數到達,達成對I-frame的完全解碼,此解碼對往後P-frame、B-frmae的參考相當重要,也可因此提昇整體畫面的品質。
圖2.4EncodingOrderandDisplayOrderofFrames
編碼後的Frame會由傳輸層決定啟用適當的傳送機制,最廣泛的傳送機制為TCP、UDP,前者是保證將資料送達目的地,後者則不保證,以下將介紹TCP與UDP之機制並比較兩者不同之處(參考表2.3)。
2.4TCP介紹
TCP(TransmissionControlProtocol)是用於通訊網路的一種通訊協定,為連接導向(Connection-Oriented),資料傳輸前必須建立傳送端到接收端的連線稱為”交握(Handshake)”程序,並且能確保資料無誤的送達接收端,包含有流量控制(FlowControl)和壅塞控制(CongestionControl)等機制,流量控制為控制傳送端的傳送速度,如Slidingwindow等傳送機制;
壅塞控制為控制網路傳送資料的傳送速度避免讓網路壅塞的情形發生,在壅塞控制中,延伸出不同的版本,如TCP-Tahoe、TCP-Reno與TCP-NewReno等傳送機制,TCP傳送資料時能無誤送達,當封包遺失時會做重傳的動作,也可能造成了傳送時間拉長的困擾,所以不適用於時間性的應用服務上面,比較適用於E-mail、FTP這類需要確保資料正確性的應用服務。
TCP在網路傳輸時,傳送端會依照ACK的Sequencenumber去分辨資料是否送達目的端,如果為連續編號之資料,則繼續做傳送,如果編號不連續,則進入等待時間,若在指定的時間接收到遺漏之ACK編號,則繼續傳送資料,若Timeout尚未收到遺漏之ACK,則傳送端會知道資料已遺失,進行重傳動作。
原始的TCP並沒有考慮到網路壅塞的情形。
因此網路的壅塞而造成了網路在傳送中造成資料嚴重遺失,因而陸續創新TCP壅塞控制機制,從初版的TCP-Tahoe到目前廣泛使用的TCP-Reno,並延伸出新的版本TCP-NewReno、TCP-Vegas等等。
這些版本有包含了慢啟動(SlowStart)、壅塞避免(CongestionAvoidance)和快速重傳(FastRetransmit)與快速回復(FastRecovery)等機制。
TCP不僅成功的連接網路,也提供了可靠性的資料傳輸,現今很多的網路應用程式完全也是由TCP/IP為基礎所發展出來的。
TCP傳輸資料以前會先建立連線,促使提高傳輸資料中的可靠性,此種程序稱為三方交握(Three-WayHandshake),以下為三方交握之流程(如圖2.5):
(1)傳輸端會先傳送一個TCPSYN(Synchronize)封包給接收端,請求連線。
(2)接收端收到傳送端的SYN封包後,會將ACK夾帶著SYN回傳給傳送端。
(3)傳送端確認收到接收端的SYN-ACK封包後,傳回ACK給接收端告知已經
收到SYN。
(4)接收端收到ACK,TCP連線因此就被建立。
圖2.5三方交握程序
2.4.1
流量控制
資料在做傳輸,當接收端接收到資料時,傳送端仍然以固定的速度繼續傳送,此時傳送端不知道接收端所能負荷的資料量有多大,當超過接收端負荷的資料量時便會在接收端的緩衝區(Buffers)溢出,造成資料遺失的情況。
為了要修正遺失的狀況,便發展了流量控制(FlowControl)機制,此機制會控制傳送端的傳送速度,依照接收端所能承受的資料量去改變傳送端本身的傳送速度,避免資料有遺失的情形。
流量控制可視為一組程序,它會告知傳送端必須等待接收端的確認(Acknowledgment:
ACK)之後,方可送出資料。
一般的流量控制有兩種方法:
停止並等候(Stop-and-wait)、管線(Pipeline)。
停止並等候(Stop-and-wait),控制方法是傳送端每發出一個訊框之後,傳送端就必須等待接收端所傳回的確認訊號並接收後,才能繼續送出下一個訊框,如圖2.6所示,這方法之優點在於簡單化,只需檢查與確認每一個訊框後,就可再送出下一個訊框,不需要大量的緩衝;
缺點在於效率差,傳送端必須等待接收端的確認訊號並接收後才可再送出下一個訊框,如有遲到的情形,整體的傳送時間就會花的非常多。
這方法對近距離的資料傳輸會比較好,因為它回應快,但是現在網路都採遠距離方式,回應時間就被拉長,所以不適合被使用。
管線(Pipeline)控制方法是把一個封包序列分成數個相等區段,並將這些區段封包做傳送,第一區段傳送後緊接著送出下一區段封包,因此接收端就會接收到連續的封包序號,假如不是連續的封包序號,接收端就會知道有封包在傳送過程中已遺失,就會傳回ACK告知傳送端哪一個封包未送達,此時的傳送端會進入等待時間,但資料仍然會持續做傳送,等到Timeout時傳送端尚未收到相對的ACK封包,則判定此封包遺失,就會針對其遺失的封包做重傳,而已經收到的封包不用重傳,提高了整體之傳送效率,其中區段,可視為滑動視窗(Slidingwindow),其控制方法,在傳送端和接收端各規劃出一個緩衝大小,控制方法是將傳送端發出訊框後,還沒收到確認訊號之前,亦能繼續傳送多個訊框,也就是說,傳送端可連續發送多個訊框,並用一個ACK來表示已收到多個資料訊框,如圖2.7所示。
每個訊框都會有各自的編號,在傳送端發送數個訊框,且會依照接收端發送的確認訊號做訊框的移動調整,如圖2.8所示。
圖2.6FlowControlstop-and-wait
圖2.7FlowControlslidingwindow
圖2.8Slidingwindow的變化
2.4.2壅塞控制
此機制大部分的TCP是以視窗模式為基準的傳輸協定,它藉由調整視窗的大小來做流量控制並以壅塞視窗(Congestionwindow,CWND)做速度的控制,而非直接以傳送的速率來做控制,且大部分的TCP會針對封包的遺失或逾時來判斷是否壅塞並啟動此壅塞控制機制之程序。
表2.2列出一些有關TCP之RFC文件。
表2.2有關TCP之RFC文件列表
RFC
Topic
896
FordAerospaceandCommunicationsCorporationCongestionControlinIP/TCPInternetworks
2001
TCPSlowStart,CongestionAvoidance,FastRetransmit
2018
TCPSelectiveAcknowledgmentOptions
2582
TheNewRenoModificationtoTCP'
sFastRecoveryAlgorithm
2884
PerformanceEvaluationofExplicitCongestionNotification(ECN)
inIPNetworks
2914
CongestionControlPrinciples
3782
4340
DatagramCongestionControlProtocol(DCCP)
5595
TheDatagramCongestionControlProtocol(DCCP)ServiceCodes
TCP-Tahoe主要有三個機制去控制壅塞視窗:
慢啟動(SlowStart)、快速重傳
(FastRetransmit)、壅塞避免(CongestionAvoidance),其傳送程序,首先CWND會被設為1,進入SlowStart,當接收端收到一個ACK時,CWND就會加1隨之劇增,當CWND超過ssthreshold(SlowSt
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 私立 东海大学 资讯 工程 学系