<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è) > 消費電子 > 設計應用 > 基于 KeyStone DSP 的多核視頻處理技術(shù)

基于 KeyStone DSP 的多核視頻處理技術(shù)

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

通信基礎局端網(wǎng)絡(luò )面臨的挑戰在于,如何才能夠將所有的內容交付給所有所需用戶(hù),同時(shí)又能維持硬件資源的高利用率和高效性。為了進(jìn)一步闡述這一挑戰,不妨考慮一下這個(gè)事實(shí),單個(gè) 1080i60 通道要求的負載與 164 個(gè)幀速率為 15 fps(假定負載與分辨率和幀數量之間呈線(xiàn)性關(guān)系)的 1/4 公用中分辨率格式 (QCIF)的通道相同。因此,支持單個(gè) 1080i60 通道的硬件也應該能夠以同等的高效性和高利用率支持 164 個(gè) QCIF 通道。但是,以如此數量級實(shí)現的可擴展性是一大挑戰。


為了符合高可擴展性要求,必須采用可編程的硬件解決方案。部分應用要求器具有極高比特率的信號輸入與輸出,因此,器的解決方案必須擁有可支持足夠外部接口的理想外設。這種處理器必須具備足夠的處理能力,可處理實(shí)時(shí)的高清高質(zhì)量,同時(shí)還需配備足夠的本機資源,如快速存儲器、內部總線(xiàn)和 DMA 支持等,以使處理器的處理能力獲得高效利用。

單內核 具有高度的靈活,能夠高效執行各種算法。 不僅能夠處理話(huà)音、音頻、,還可以執行其他功能。但是,由于單內核 的計算能力不足,因而不能自由地處理任何分辨率的實(shí)時(shí)視頻,而只能處理 SQCIF、QCIF 以及公用中分辨率格式 (CIF) 等較低分辨率的視頻;而且,單內核 DSP 的功耗也使其無(wú)法應用在高密度視頻處理系統中。

新型的多內核 DSP 具備非常高的處理能力,且其每次運行的功耗也比單內核 DSP 低。為了確定多內核處理器對于通信基礎局端而言是否能夠成為有效的硬件解決方案,需要對其接口、處理性能、存儲器要求以及多內核合作與同步機制針對各種不同的使用案例進(jìn)行符合性驗證。

2.1 外部 I/O 接口
典型轉碼應用的比特流是以 IP 數據包形式進(jìn)行打包。轉碼應用所需的帶寬與分辨率以及用戶(hù)所需網(wǎng)絡(luò )的可用帶寬相關(guān)。以下針對單通道消費類(lèi)質(zhì)量 H.264 編碼視頻流作為分辨率函數時(shí)列出的公用帶寬要求:
• HD 分辨率,720p 或 1080i - 6 至 10 Mbps
• D1 分辨率,720×480,30 幀/秒 (fps),或 720×576,25 幀/秒 – 1 至 3 Mbps
• CIF 分辨率,352×288,30 幀/秒 – 300 至 768 Kbps
• QCIF 分辨率,176×144,15 幀/秒 – 64 至 256 Kbps

轉碼應用所需的總外部接口是輸入媒體流與輸出媒體流所需帶寬的總和。為了支持多個(gè) HD 分辨率通道或大量較低分辨率通道,至少需要一個(gè)串行千兆位介質(zhì)獨立接口 (SGMII)。

非轉碼視頻應用涉及從 YUV(或同等)域對原始視頻媒體流進(jìn)行編碼或解碼。原始視頻流具有較高的比特率,且通常通過(guò) PCI、PCI Express 或串行快速輸入/輸出 (SRIO) 等高比特率的快速多通道總線(xiàn)直接從處理器輸入或輸出信號。
以下列出了使用 8 位像素數據和 4:2:0 或 4:1:1 配色方案傳輸 YUV 域中單通道原始視頻流所需的帶寬:
• 1080i60 - 745.496 Mbps
• 720p60 - 663.552 Mbps
• D1(30fps NTSC 或 25 fps PAL)- 124.415 Mbps
• CIF(30 fps)- 36.49536 Mbps
• QCIF(15 fps)- 4.56192 Mbps

因此,可對 4 個(gè) 1080i60 H.264 通道進(jìn)行解碼的處理器要求能夠支持超過(guò) 4 Gbps 速率的總線(xiàn),從而可假定總線(xiàn)的利用率為 60%。


2.2 處理性能
在可編程處理器的 H.264 通道上進(jìn)行視頻處理所需的處理性能取決于眾多參數,其中包括分辨率、比特率、影像質(zhì)量以及視頻剪輯內容等。本章不僅將討論影響周期消耗的因素,而且還將給出普通應用實(shí)例平均周期消耗的經(jīng)驗法則。

與其他視頻標準一樣,H.264 僅定義解碼器算法。對于既定編碼媒體流而言,所有的解碼器都可生成相同的 YUV 視頻域數據。

因此,解碼器不決定影像質(zhì)量,而由編碼器決定。不過(guò),編碼器質(zhì)量能影響解碼器的周期消耗。

熵解碼器的周期消耗取決于熵解碼器的類(lèi)型和比特率。H.264 MP/HP 為熵解碼器定義了兩種無(wú)損算法,即上下文環(huán)境自適應二進(jìn)制算術(shù)編碼 (CABAC) 和上下文環(huán)境自適應可變長(cháng)度編碼 (CAVLC)。CABAC 能提供更高的壓縮比,因此,比特數相同時(shí)影像質(zhì)量會(huì )更佳,但相比 CAVLC 在每個(gè)媒體流比特上約多消耗 25% 的周期。用于解碼 CABAC 或者 CAVLC 媒體流所需的周期量是比特數的一個(gè)非線(xiàn)性單調函數。

所有其他解碼器功能的處理負載均是分辨率的函數。更高分辨率需要更多的周期,幾乎與宏模塊的總數量呈線(xiàn)性關(guān)系。視頻流內容、編碼器算法與工具能在一定程度上影響解碼器的周期消耗。附錄 A – 解碼器性能依賴(lài)性 (Decoder Performance Dependency) 列舉了可能會(huì )影響解碼器周期消耗的編碼器算法和工具。

在可編程器件上實(shí)施既定比特率的編碼器需要在質(zhì)量與處理負載之間進(jìn)行權衡。附錄 B – 運動(dòng)估算與比特率控制 分析了可能影響編碼器質(zhì)量并消耗大量周期的兩種編碼器算法。

對于典型的運動(dòng)消費類(lèi)電子設備的高質(zhì)量視頻流而言,以下列表給出的經(jīng)驗法則,可用以判斷常見(jiàn)使用案例中 H.264 編碼器消耗的周期數。
• QCIF 分辨率、15 fps、128 Kbps - 每通道 2,700 萬(wàn)個(gè)周期
• CIF 分辨率、30 fps、300 Kbps – 每通道 2 億個(gè)周期
• D1 分辨率、NTSC 或 PAL、2 Mbps –每通道 6.6 億個(gè)周期
• 720p 分辨率、30 fps、6 Mbps – 每通道 18.5 億個(gè)周期
• 1080i60、每秒 60 場(chǎng)、9 Mbps – 每通道 34.5 億個(gè)周期

與此類(lèi)似,H.264 解碼器消耗的周期數為:
• QCIF 分辨率、15 fps、128IKbps – 每通道 1400 萬(wàn)個(gè)周期
• CIF 分辨率、30 fps、300 Kbps – 每通道 7050 萬(wàn)個(gè)周期
• D1 分辨率、NTSC 或 PAL、2 Mbps –每通道 2.92 億個(gè)周期
• 720p 分辨率、30 fps、6 Mbps – 每通道 7.8 億個(gè)周期
• 1080i60、每秒 60 場(chǎng)、9 Mbps –每通道 16.6 億個(gè)周期

轉碼應用(包括完整的解碼器和編碼器)消耗的周期數是編碼器和解碼器所消耗的總和,在需要的情況下也會(huì )加上擴展的消耗。



2.3 存儲器的考慮事項
在成本與存儲器要求之間進(jìn)行權衡折中是任何硬件設計都需要考慮的重要因素。在分析多核視頻處理解決方案的存儲器要求時(shí),需要明確以下幾個(gè)問(wèn)題:
• 需要多大存儲量的存儲器,以及存儲器的類(lèi)型(專(zhuān)有還是共享)是什么?
• 存儲器的速度是否足夠支持流量需求?
• 接入總線(xiàn)的速度是否足以支持流量需求?
• 存儲器架構是否能夠以最少的多核性能損失支持多核接入?
• 存儲器架構是否能以最小的數據沖突支持處理器數據流的輸入與輸出?
• 支持存儲器接入(諸如 DMA 通道、DMA 控制器、預取機制和快速智能高速緩沖架構 )的現有硬件有哪些?所需存儲器的存儲量取決于應用。以下三個(gè)應用實(shí)例介紹了三種不同的存儲器要求:
- 無(wú)線(xiàn)傳輸速率:在單幀運動(dòng)估算參考 (single-motion estimation reference frame) 中以極低的延遲從 QCIF H.264BP 轉換至 QCIF H.264BP 需要足夠的存儲容量才能存儲 5 個(gè)幀。每幀需要 38016 個(gè)字節,那么一個(gè)通道(包括輸入和輸出媒體流的存儲)所需存儲器的存儲量為每通道不足 256KB。同時(shí)處理 200 個(gè)通道則需 50MB 的數據存儲。
- 多通道解碼器應用實(shí)例:對于 H264 HP 1080p 解碼器,如果兩個(gè)連續的 P 幀和 I 幀之間的 B 幀數目等于或少于 5,那么我們只需要足夠存儲 7~8 個(gè)幀的存儲空間,因而單個(gè)通道(包含存儲輸入和輸出媒體流)所需的存儲量應少于每通道 25MB。同時(shí)處理 5 個(gè)通道需要 125MB 的數據存儲器。

- 包含實(shí)時(shí)電視廣播的高質(zhì)量視頻流示例:應 FCC 的要求在系統中有 7 秒的延遲時(shí),對實(shí)時(shí)電視節目采用 H.264HP 720P60 編碼需要每個(gè)通道存儲 600MB。并行處理兩個(gè)通道需要 1.2GB 的數據存儲量。

為了最大限度地提高視頻處理系統的低成本優(yōu)勢,數據必須駐留在外部存儲器中,其大小需要根據系統存儲器最差的應用狀態(tài)來(lái)選擇。與此同時(shí),處理過(guò)的數據必須存放在內部存儲器中才能支持處理器的高吞吐量。優(yōu)化的系統會(huì )使用乒乓機制將數據從外部存儲器移至內部存儲器,而將數據從內存移至外部存儲器的同時(shí)還要處理來(lái)自?xún)炔看鎯ζ鞯臄祿?。典型的處理器具有一個(gè)可配置為高速緩存或 RAM 的小型 L1 存儲器,用于每個(gè)內核(可配置為高速緩存或 RAM)的較大型專(zhuān)用 L2 存儲器,以及處理器中每個(gè)內核都能夠存取的共享 L2 存儲器均可使用。為加強乒乓機制,需要用多個(gè)相互獨立的 DMA 通道從外部存儲器中讀寫(xiě)數據。

附錄C 外部存儲器帶寬-為支持乒乓機制用于上述三個(gè)應用實(shí)例,估算了將數據從外部存儲器移至內部存儲器所需的帶寬。外部存儲器的有效帶寬必須大于 3.5Gbps。



評論


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