<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è) > 嵌入式系統 > 設計應用 > 視頻播放設備的設計需符合娛樂(lè )類(lèi)規范

視頻播放設備的設計需符合娛樂(lè )類(lèi)規范

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

在不遠的將來(lái),現代家庭的客廳都將配備具有IPTV功能的數字電視、高清電視(HDTV)機頂盒和高清光盤(pán)機。移動(dòng)中也將越來(lái)越多地增加媒體回放功能。很快,所有都將能專(zhuān)業(yè)制作的內容。

支持的下一代家庭與便攜者在考慮他們以后的SOC架構時(shí)必須清楚什么對此類(lèi)設備消費者來(lái)說(shuō)才是最重要的?,F在有很多IP供應商提供可集成進(jìn)SOC的處理器內核或硬件模塊。在評估這些內核和模塊時(shí),師必須清楚市場(chǎng)在支持各種視頻標準方面的發(fā)展動(dòng)向。

多種不同的視頻標準

盡管H.264已成為未來(lái)系統與設備的全球性?xún)?yōu)秀視頻編碼標準,但仍有越來(lái)越多的標準在被人們采用。例如,下一代視頻光盤(pán)和DTV標準要求采用Windows Media Video 9或SMPTE VC-1編碼;有些IPTV系統采用MPEG-4及類(lèi)似編碼;很多系統出于兼容目的仍要求采用MPEG-2編解碼;實(shí)時(shí)雙向視頻會(huì )議系統仍廣泛采用H.263標準;中國的國家廣播則主要采用AVS編碼標準。

不同類(lèi)型的設備對編解碼性能的要求也不盡相同。例如,機頂盒只需解碼高質(zhì)量的視頻信號,而視頻會(huì )議設備則必須同時(shí)進(jìn)行實(shí)時(shí)的視頻編解碼。電池供電的設備要求低功耗,而裝備有移動(dòng)天線(xiàn)的設備則需要特別強的比特流糾錯能力。

由于許多編碼標準又根據采用的編碼技術(shù)對哪些應用和設備有益而細分為不同的,這就讓視頻處理世界變得更加復雜。通常,適用于雙向通信類(lèi)的要求具備實(shí)時(shí)編碼能力但只需進(jìn)行低復雜度的糾錯,而用于專(zhuān)業(yè)視頻編碼的則要求更高壓縮率和更低解碼成本。表1所示為主要壓縮標準的實(shí)時(shí)應用類(lèi)規范和娛樂(lè )應用類(lèi)規范。

對于將來(lái)的視頻設備甚至移動(dòng)設備,能解碼H.264主規范(Main Profile)之類(lèi)的娛樂(lè )視頻規范是很重要的。例如,手持式設備中的全功能DVB-H解碼器必須同時(shí)支持H.264基本規范(Baseline)和主規范(Main Profile)。終端用戶(hù)產(chǎn)品要在市場(chǎng)中取得成功,必須支持恰當的解碼規范。

早期RCA Lyra便攜式媒體播放機的購買(mǎi)者就曾因為發(fā)現它無(wú)法播放任何帶B幀編碼的視頻而大感失望。B幀雖然提高了壓縮率,但要實(shí)現實(shí)時(shí)編碼則很困難,因此只有部分娛樂(lè )類(lèi)規范使用它。Lyra播放機的這一缺點(diǎn)導致用戶(hù)從因特網(wǎng)上下載的大部分視頻都無(wú)法觀(guān)看。這種功能上的不足在競爭日益激烈的消費品市場(chǎng)迅速導致了一個(gè)視頻播放機產(chǎn)品線(xiàn)的消亡。Lyra的失敗為Archos公司的產(chǎn)品 stellar的成功讓出了道路。

要處理多樣化的編碼標準和規范,需要多格式的可編程視頻處理器。消費者對娛樂(lè )和通信的要求刺激了芯片制造商采用既能處理娛樂(lè )類(lèi)規范也能處理實(shí)時(shí)類(lèi)規范的可編程視頻處理器。一般認為硬連線(xiàn)的視頻模塊面積更小,但當同時(shí)需要多種模塊以滿(mǎn)足多種標準時(shí),整個(gè)視頻功能模塊的面積就可能比采用處理器實(shí)現時(shí)占用的面積大得多。而且硬連線(xiàn)的視頻模塊在應付這些不斷發(fā)展的視頻標準中的各種變化時(shí)也不夠靈活。因此,現在絕大部分芯片設計師都只會(huì )考慮采用可編程視頻處理器。

表1:實(shí)現壓縮標準中不同部分的各個(gè)規范。
表1:實(shí)現壓縮標準中不同部分的各個(gè)規范。

關(guān)鍵是能高效地處理各種標準

然而,僅僅因為一個(gè)處理器能夠編程并不意味它就能高效地處理每一種標準。通用嵌入式CPU若用于處理視頻流則顯得配置不足,僅解碼一段低質(zhì)量的視頻就不得不以極高的主頻運行。因此,這種方案對便攜式設備而言能效比太低。相反,專(zhuān)用視頻處理器中集成有專(zhuān)用指令集,可以利用SIMD(單指令多數據)技術(shù)進(jìn)行像素數據的并行處理或利用特殊指令進(jìn)行視頻數據的串行處理(例如熵解碼、運動(dòng)向量預測等)。在設計Diamond 388VDO標準視頻引擎時(shí),Tensilica公司在標準32-bit RISC指令集之外還增加了很多視頻專(zhuān)用的指令集以?xún)?yōu)化引擎的視頻處理能力。

要實(shí)現用于H.264 主規范的處理器尤其困難。H.264主規范采用了比特流無(wú)損熵編碼中基于上下文的自適應二進(jìn)制算術(shù)編碼(CABAC)方法。要從CABAC比特流中解碼每個(gè)二進(jìn)制元素(稱(chēng)為bin)需要依賴(lài)于前一bin的完全解碼結果,每個(gè)bin都對解碼器的狀態(tài)有很大影響。有兩種嵌入式處理器能?chē)栏裼密浖?shí)現實(shí)時(shí)CABAC解碼:菲利普半導體(NXP)的Trimedia和Tensilic Diamond 388VDO。全軟件CABAC解碼這種方法經(jīng)證實(shí)有一大優(yōu)點(diǎn),那就是在高比特率工作情況下能夠達到最高效的性能。

Tensilica能夠使用指令集擴展實(shí)現全軟件的熵解碼,因而能創(chuàng )建出可處理復雜比特流的低時(shí)鐘速率、高能效視頻處理器。例如,Tensilica能以?xún)H162 MHz的時(shí)鐘速率實(shí)現對一個(gè)5 Mbps比特流的所有D1 Main profile解碼。

與此類(lèi)似,H.264 Main profile支持B幀和交織式視頻內容,而這兩項功能會(huì )給經(jīng)驗不足的視頻處理器和編解碼器開(kāi)發(fā)人員帶來(lái)很大困難。解決視頻編解碼器難題最簡(jiǎn)單的方法就是增大DRAM存儲器帶寬。這種方法在高端PC機上沒(méi)有問(wèn)題,但用在嵌入式系統中就不現實(shí)了。由于受功耗和成本限制,嵌入式系統無(wú)法承受這樣的DRAM帶寬浪費。

圖1所示為T(mén)ensilica Diamond388VDO標準視頻引擎的框圖。其中包含兩個(gè)Tensilica Xtensa可配置處理器和一個(gè)DMA控制器,可最大限度發(fā)揮視頻壓縮解壓算法固有的并行性。Diamond 388VDO內核中的流處理器和像素處理器共同分擔視頻壓縮任務(wù),DMA控制器則負責在處理器內核內外和兩個(gè)處理器之間傳送壓縮前后的圖象。Diamond 388VDO視頻引擎中的每個(gè)處理器都有自己的指令集和數據RAM。

圖1:Tensilica的 Diamond388VDO視頻引擎框圖。
圖1:Tensilica的 Diamond388VDO視頻引擎框圖。

Diamond視頻引擎內核中的這兩個(gè)處理器都采用了Tensilica的可配置Xtensa處理器架構。流處理器通過(guò)增加額外指令集來(lái)完成比特流解析和熵編碼。這些新指令中一部分基于Tensilica的FLIX(可變長(cháng)度指令擴展),并采用每條指令執行兩次獨立操作的VLIW指令格式。像素處理器中也增加了可同時(shí)操作多個(gè)像素的SIMD(單指令多數據)指令。

流處理器和像素處理器中添加的指令使Diamond視頻引擎能夠在時(shí)鐘速率低于200MHz時(shí)以標準顯示分辨率(SD或D1)和30幀/秒的速度編碼MPEG-4 ASP(Advanced Simple Profile)比特流或解碼H.264/AVC MP(Main Profile)、MPEG-4 ASP、MPEG-2 MP、和VC-1/WMV 9 MP視頻比特流。低時(shí)鐘速率通常意味著(zhù)低功耗,該引擎之所以選擇200-MHz的時(shí)鐘速率是因為該引擎可以采用普通的低成本130nm IC加工工藝制造。

圖2所示為Diamond視頻引擎在解碼H.264/AVC視頻數據流時(shí)內部的任務(wù)分配情況。流處理器用于完成比特流解析(包括分離網(wǎng)絡(luò )抽象層、圖象層和片層)和熵解碼。像素處理器則用于完成反向量化、反向變換編碼、幀內預測、運動(dòng)補償和圖像解塊處理。流處理器也可輔助像素處理器進(jìn)行運動(dòng)補償。

圖2:Diamond 388VDO視頻引擎在進(jìn)行H.264/AVC解碼時(shí)的內部任務(wù)分配情況。
圖2:Diamond 388VDO視頻引擎在進(jìn)行H.264/AVC解碼時(shí)的內部任務(wù)分配情況。

需要注意的是,在一塊處理器上運行所有這些解碼任務(wù)其實(shí)是可能的,但這需要高得多的時(shí)鐘速率,而時(shí)鐘速率高意味著(zhù)需要采用更加昂貴的工藝技術(shù)。為了盡可能減小電池供電的便攜式視頻產(chǎn)品的功耗,Diamond 388VDO視頻引擎即使在解碼標準分辨率的視頻時(shí)都保持很低的時(shí)鐘速率,從而最大限度減小了功耗。

所有視頻解碼任務(wù)都應在處理器外完成

在評估不同的視頻處理器性能時(shí),很重要的一點(diǎn)就是檢查并確保系統主CPU的處理器內核無(wú)需承擔任何視頻解碼任務(wù),包括所有比特流解析任務(wù)。傳統視頻處理器,例如Hantro出產(chǎn)的處理器,只將運動(dòng)估計之類(lèi)的像素處理功能挪至主CPU外完成,而給系統控制器留下了運算量很大的一部分任務(wù)。這些開(kāi)銷(xiāo)可能要求SOC設計師采用更加龐大也更耗電的系統控制器,這在便攜式設備的設計中是需要付出昂貴代價(jià)的。

研究一下業(yè)界領(lǐng)先的家用和手持嵌入式視頻設備,我們會(huì )發(fā)現最好的視頻處理器是那些以高比特率和低內存帶寬處理娛樂(lè )類(lèi)數據的處理器。只有深刻理解各種視頻規范,并清楚哪些規范需要利用下一代設備來(lái)實(shí)現,SOC架構師們才能正確評估不同IP廠(chǎng)商提供的產(chǎn)品。



評論


相關(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>