<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 嵌入式系統 > 設計應用 > 視頻壓縮技術(shù)的系統考慮

視頻壓縮技術(shù)的系統考慮

作者: 時(shí)間:2012-12-01 來(lái)源:網(wǎng)絡(luò ) 收藏

解碼技術(shù)(/AVC與VC-1)代表著(zhù)第三代。為具體應用選擇正確的編解碼器并優(yōu)化其實(shí)時(shí)實(shí)施仍然是一項巨大的挑戰,最佳的設計必須權衡壓縮效率及可用的計算能力。本文探討了壓縮能力與復雜性之間的權衡,并討論市場(chǎng)中可能會(huì )影響主流視頻編解碼器未來(lái)的實(shí)時(shí)實(shí)施與主要趨勢。

數字視頻產(chǎn)品需求近些年出現猛增。主流應用包括視頻通信、安全監控與工業(yè)自動(dòng)化,而最熱門(mén)的要算娛樂(lè )應用,如 DVD、HDTV、衛星電視、高清 (HD) 機頂盒、因特網(wǎng)視頻流、數碼相機與 HD 攝像機、視頻光盤(pán)庫 (video jukebox)、高端顯示器(LCD、等離子顯示器、DLP)以及個(gè)人攝像機等。眾多精彩的新應用目前也處于設計或前期部署中,例如針對家庭與手持設備及地面/衛星標準(DVB-T、DVB-H、DMB)的高清 DVD(藍光/HD-DVD)和數字視頻廣播、高清視頻電話(huà)、數碼相機以及 IP 機頂盒。由于手持終端計算能力的提高以及電池技術(shù)與高速無(wú)線(xiàn)連接的發(fā)展,最終產(chǎn)品的移動(dòng)性與集成性也在不斷提高。

頻壓縮是所有令人振奮的、新型視頻產(chǎn)品的重要動(dòng)力。壓縮-解壓(編解碼)算法可以實(shí)現數字視頻的存儲與傳輸。典型的編解碼器要么采用行業(yè)標準,如 MPEG2、MPEG4、/AVCAVS,要么采用專(zhuān)有算法,如 On2、Real Video、Nancy與Windows Media Video (WMV) 等。WMV 是個(gè)例外——它最初是微軟公司的專(zhuān)有算法,而現在則以 VC-1 的新名稱(chēng)在業(yè)界實(shí)現了標準化。編解碼技術(shù)在過(guò)去十年中不斷改進(jìn)。最新的編解碼技術(shù)(/AVC 與 VC-1)代表著(zhù)第三代。這兩種編解碼技術(shù)利用如可編程 DSPASIC 等低成本 IC 的處理能力,都能夠達到極高的壓縮比。不過(guò),為具體應用選擇正確的編解碼器并優(yōu)化其實(shí)時(shí)處理仍然是一項巨大的挑戰。最佳的設計必須權衡壓縮效率及可用的計算能力。此外,如何在計算能力有限的情況下獲得最佳壓縮效率也是一門(mén)大學(xué)問(wèn)。

在本文中,我們首先概述視頻編碼的主要概念,同時(shí)介紹傳統壓縮標準。然后我們重點(diǎn)介紹其中包括 H.264/AVC、WMV9/VC-1與AVS 等在內的最新編解碼技術(shù)的功能,此外,還將深入探討壓縮能力與復雜性之間的權衡。最后,討論市場(chǎng)中可能會(huì )影響主流視頻編解碼器未來(lái)的實(shí)時(shí)處理與主要趨勢。

2. 視頻壓縮挑戰

數字視頻的主要挑戰在于原始或未壓縮的視頻需要存儲或傳輸大量數據。例如,標準清晰度的 NTSC 視頻的數字化一般是每秒 30 幀速率,采用 4:2:2 YcrCb 及 720(480,其要求超過(guò) 165Mbps 的數據速率。保存 90 分鐘的視頻需要 110GB 空間,或者說(shuō)超過(guò)標準 DVD-R 存儲容量的 25 倍。即使是視頻流應用中常用的低分辨率視頻(如:CIF:352x288 4:2:0、30 幀/秒)也需要超過(guò) 36.5Mbps 的數據速率,這是ADSL 或 3G 無(wú)線(xiàn)等寬帶網(wǎng)絡(luò )速度的許多倍。目前的寬帶網(wǎng)可提供 1~10Mbps 的持續傳輸能力。顯然數字視頻的存儲或傳輸需要采用壓縮技術(shù)。

視頻壓縮的目的是對數字視頻進(jìn)行編碼——在保持視頻質(zhì)量的同時(shí)占用盡可能少的空間。編解碼技術(shù)理論依據為信息理論的數學(xué)原理。不過(guò),開(kāi)發(fā)實(shí)用的編解碼技術(shù)需要藝術(shù)性的精心考慮。

3. 壓縮權衡

在選擇數字視頻系統的編解碼技術(shù)時(shí)需要考慮諸多因素。主要因素包括應用的視頻質(zhì)量要求、傳輸通道或存儲介質(zhì)所處的環(huán)境(速度、時(shí)延、錯誤特征)以及源內容的格式。同樣重要的還有預期分辨率、目標比特率、色彩深度、每秒幀數以及內容和顯示是逐行掃描還是隔行掃描。壓縮通常需要在應用的視頻質(zhì)量要求與其他需求之間做出取舍。首先,用途是存儲還是單播、多播、雙向通信或廣播?對于存儲應用,到底有多少可用的存儲容量以及存儲時(shí)間需要多久?對于存儲之外的應用,最高比特率是多少?對于雙向視頻通信,時(shí)延容差或容許的端到端系統延遲是多少?如果不是雙向通信,內容需要在脫機狀態(tài)提前完成編碼還是需要實(shí)時(shí)編碼?網(wǎng)絡(luò )或存儲介質(zhì)的容錯能力如何?根據基本目標應用,不同壓縮標準以不同方式處理這些問(wèn)題的權衡。

另一方面是需要權衡編解碼實(shí)時(shí)處理的成本。如 H.264/AVC 或 WMV9/VC-1等能夠實(shí)現較高壓縮比的新算法需要更高的處理能力,這會(huì )影響編解碼器件的成本、系統功耗以及系統內存。

4. 標準化機構

在視頻編解碼技術(shù)定義方面有兩大標準機構。國際電信聯(lián)盟 (ITU) 致力于電信應用,已經(jīng)開(kāi)發(fā)了用于低比特率視頻電話(huà)的 H.26x 標準,其中包括 H.261、H.262、H.263 與 H.264;國際標準化組織 (ISO) 主要針對消費類(lèi)應用,已經(jīng)針對運動(dòng)圖像壓縮定義了 MPEG 標準。MPEG 標準包括 MPEG1、MPEG2MPEG4。圖 1 說(shuō)明了視頻編碼標準的發(fā)展歷程。

MPEG 與 ISO 根據基本目標應用往往做出稍有不同的取舍。有時(shí)它們也會(huì )開(kāi)展合作,如:聯(lián)合視頻小組 (JVT),該小組定義了 H.264 編解碼技術(shù),這種技術(shù)在 MPEG 系列中又被稱(chēng)為 MPEG4-Part 10 或 MPEG4 高級視頻編解碼 (AVC)。我們在本文中將這種聯(lián)合標準稱(chēng)為 H.264/AVC。同樣,H.262 對應 MPEG2,而 H.263 基本規范類(lèi) (Baseline Profile) 技術(shù)在原理方面與 MPEG4 簡(jiǎn)單類(lèi) (Simple Profile) 編解碼技術(shù)存在較多重復。

標準對編解碼技術(shù)的普及至關(guān)重要。出于規模經(jīng)濟原因,用戶(hù)根據可承受的標準尋找相應產(chǎn)品。由于能夠保障廠(chǎng)商之間的互操作性,業(yè)界樂(lè )意在標準方面進(jìn)行投資。而由于自己的內容可以獲得較長(cháng)的生命周期及廣泛的需求,內容提供商也對標準青睞有加。盡管幾乎所有視頻標準都是針對少數特定應用的,但是在能夠適用的情況下,它們在其他應用中也能發(fā)揮優(yōu)勢。

圖1:ITU 與 MPEG 標準的發(fā)展歷程 [10]

為了實(shí)現更好的壓縮及獲得新的市場(chǎng)機遇,ITUMPEG 一直在不斷發(fā)展壓縮技術(shù)和開(kāi)發(fā)新標準。中國最近開(kāi)發(fā)了一種稱(chēng)為 AVS 的國家視頻編碼標準,我們在后面也會(huì )做一介紹。目前正在開(kāi)發(fā)的標準包括 ITU/MPEG 聯(lián)合可擴展視頻編碼 (Joint Scalable Video Coding)(對 H264/ AVC 的修訂)和MPEG 多視角視頻編碼 (Multi-view Video Coding)。另外,為了滿(mǎn)足新的應用需求,現有標準也在不斷發(fā)展。例如,H.264 最近定義了一種稱(chēng)為高精度拓展 (Fidelity Range Extensions) 的新模式,以滿(mǎn)足新的市場(chǎng)需求,如專(zhuān)業(yè)數字編輯、HD-DVD 與無(wú)損編碼等。

除了 ITU 與 ISO 開(kāi)發(fā)的行業(yè)標準以外,還出現了幾種專(zhuān)用于因特網(wǎng)流媒體應用、廣受歡迎的專(zhuān)有解決方案,其中包括 Real Networks Real Video (RV10)、Microsoft Windows Media Video 9 (WMV9) 系列、ON2 VP6 以及 Nancy。由于這些格式在內容中得到了廣泛應用,因此專(zhuān)有編解碼技術(shù)可以成為業(yè)界標準。2003 年 9 月,微軟公司向電影與電視工程師學(xué)會(huì ) (SMPTE) 提議在該機構的支持下實(shí)現 WMV9 位流與語(yǔ)法的標準化。該提議得到了采納,現在 WMV9 已經(jīng)被 SMPTE 作為 VC-1 實(shí)現標準化。

5. 視頻編碼原理

我們感興趣的所有視頻標準都采用基于模塊的處理方式。每個(gè)宏模塊一般包含 4 個(gè) 8(8 的光度塊和 2 個(gè) 8(8 的色度塊(4:2:0 色度格式)。視頻編碼基于運動(dòng)補償預測(MC) 原理錯誤!未找到引用源。,變換與量化及熵編碼。圖 2 說(shuō)明的是一種典型的、基于運動(dòng)補償的視頻編解碼技術(shù)。在運動(dòng)補償中,通過(guò)預測與最新編碼的("參考")視頻幀處于同一區域的視頻幀中各宏模塊的像素來(lái)實(shí)現壓縮。例如,背景區域通常在各幀之間保持不變,因此不需要在每個(gè)幀中重新傳輸。運動(dòng)估計 (ME) 是確定當前幀——即與它最相似的參考幀的 16(16 區域中每個(gè) MB 的過(guò)程。ME 通常是視頻壓縮中最消耗性能的功能。有關(guān)當前幀中各模塊最相似區域相對位置的信息("運動(dòng)矢量")被發(fā)送至解碼器。

MC 之后的殘差部分分為 8(8 的模塊,各模塊綜合利用變換編碼、量化編碼與可變長(cháng)度編碼技術(shù)進(jìn)行編碼。變換編碼(如:離散余弦變換或 )利用殘差信號中的空間冗余。量化編碼可以消除感知冗余 (perceptual redundancy) 并且降低編碼殘差信號所需要的數據量??勺冮L(cháng)度編碼利用殘差系數的統計性質(zhì)。通過(guò) MC 進(jìn)行的冗余消除過(guò)程在解碼器中以相反過(guò)程進(jìn)行,來(lái)自參考幀的預測數據與編碼后的殘差數據結合在一起產(chǎn)生對原始視頻幀的再現 。


上一頁(yè) 1 2 3 4 5 下一頁(yè)

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>