TI 通用嵌入式處理器技術支持

摘要

全彩LED 顯示墻異步控制卡以成本低，集中管理等特點，逐漸成為全彩LED 顯示墻控制卡的主流。AM335x 具有豐富的硬件外設，基于 Linux 的軟件方案，包含GPU Composition模塊能提供完整的多圖層疊加縮放等功能，十分適合全彩 LED 顯示墻的異步控制卡應用。本文將從硬件和軟件兩個方面介紹基于AM335x 提供的相應解決方案。

1 全彩LED 顯示墻控制卡簡介

全彩 LE D顯示顯控制卡根據(jù)控制方式，可以分顯兩大顯：同步控制卡和異步控制卡。

1.1 同步控制卡

全彩LED 同步顯示墻主要由PC，同步控制卡和LED 顯示模塊組三部分組成，其連接方式如下：



圖 1 同步控制模塊圖

同步控制卡將DVI 信號轉成LED 顯示模組所需要的視頻信號格式，而且用以太網(wǎng)的方式傳輸給LED 顯示模組。同步控制卡本身不做視頻解碼等處理，僅做格式轉換。因此，一般采用FPGA 實現(xiàn)該功能。

1.2 異步控制卡

全彩LED 異步顯示墻由異步控制卡和LED 顯示模組組成，其連接方式如下：



圖 2 異步控制卡模塊圖

由上圖，異步控制卡主要由兩個大的部分組成：

視頻處理模塊。

在此模塊中，SOC 從網(wǎng)口得到視頻流以及UI 的素材，進行視頻解碼和UI 繪制，最后通過LCD 接口傳送給FPGA。

視頻信號轉換模塊。

在此模塊中，F(xiàn)PGA 將視頻信號轉換成LED 顯示模組所需的信號，并通過網(wǎng)口輸出，該功能和同步控制卡的功能一樣。

對比兩種方案，可見異步控制卡具體有成本低，便于集中管理的特點。

2 異步控制卡系統(tǒng)分析

下面從硬件和軟件兩個方面分析其主芯片的系統(tǒng)需求。

2.1 硬件部分

從硬件上看，視頻處理模塊部分主要由最小系統(tǒng)和外圍模塊兩大部分組成。

最小系統(tǒng)

最小系統(tǒng)由主芯片，電源系統(tǒng)，DDR 和存儲四部分組成。

不同級別的全彩屏對SOC 的處理能力有不同要求，具體的要求在軟件部分有說明。

外圍模塊

音頻接口，LCD 接口。即LED 顯示墻的基本需求。

網(wǎng)絡接口。百兆甚至千兆網(wǎng)口可以有效保證顯示內容更新的高效性。

USB 接口。便于系統(tǒng)升級，以及擴展基于USB 各種外設。

SD 卡/TF 卡支持。便于系統(tǒng)升級以及內容的本地更新。

此外，異步卡一般和LED 顯示墻一起放置于室外，所以需要可工作在寬溫度范圍的工業(yè)級芯片。

2.2 軟件部分

軟件部分主要由操作系統(tǒng)和應用軟件兩大部分組成。

2.2.1 操作系統(tǒng)

在異步控制卡行業(yè)中，主流系統(tǒng)選擇了Linux。

應用軟件

應用軟件主要包含三個部分：

多媒體部分。

用于對音視頻碼流的解碼。

全彩屏主要分為高端和中低端兩個檔次：

高端，視頻分辨率以及顯示分辨率要求在720p 分辨率以上。

中低端，視頻分辨率以及顯示分辨率在640x480 以內。

由于LED 墻一般顯示物理面積大，而且亮度高，所以對視頻流的幀率要求較高，要求在每秒25 幀以上。因此，對于高端產(chǎn)品，一般需帶有視頻硬解碼模塊的主芯片，其價格一般較高；對于低端產(chǎn)品，使用軟解碼可實現(xiàn)，所以需要運算性能較強的主芯片，成本優(yōu)勢較好。

UI 部分。

用于顯示字幕，圖片等，并處理UI 元素和視頻層的疊加。疊加部分。由于涉及到透明度，尺寸變換等，運算需求也很大，所以需要主芯片具有相關的硬件加速模塊。

遠程控制部分。

該部分主要實現(xiàn)上位機對各控制卡的遠程控制，內容更新等功能。該部分一般通過網(wǎng)絡應用層實現(xiàn)，各控制廠家有自己的協(xié)議。

3 AM335x 的解決方案

AM335x 是TI 新近推出的基于ARM Cortex-A8 的SOC，外設豐富，主要針對工業(yè)應用領域。針對異步控制卡應用，TI 也提供了基于Linux 的解決方案。下面將從硬件和軟件兩方面分別介紹該方案。

3.1 硬件方案

AM335x 具有一個強勁的核心Cortex-A8，該核的運算能力可達2.0DMIPS/MHz, 而且AM335x的主頻可到1GHz，即運算總的能力可達2000 DMIPS，可流暢解碼640x480 的MPEG4 視頻流，而且有足夠的運算余量繪制各種UI。

此外，AM335x 還有一個3D 圖形加速核，SGX530，可支持OpenGL ES2.0。TI 在OpenGL ES2.0 之上提供了相應的軟件方案，將SGX530 用于視頻幀的尺寸縮放以及實現(xiàn)對UI 層和視頻層的透明疊加的加速，后面軟件部分會詳細介紹該方案。

同時，AM335x 具有豐富的外設，如下圖所示：
?

圖 3 AM335x 異步控制卡硬件模塊圖

由上圖可見AM335x 可完全涵蓋所有異步控制卡的外設需求，不需要其他擴展。因此，總體成本具有很強競爭力。

TI 的開發(fā)板GP EVM（可查閱參考文檔 [1] ）都可以很便利的進行LED 應用的評估和開發(fā)，下文中的軟件方案是以GP EVM 為平臺進行開發(fā)的。

3.2 軟件方案

軟件方案主要分為操作系統(tǒng)和應用軟件兩大塊，具體介紹如下。

3.2.1 操作系統(tǒng)

如前所述，Linux 是異步控制卡的主流操作系統(tǒng)，因此，本方案也選擇了Linux 作為平臺。AM335x EZSDK 提供了Linux 的完整開發(fā)包，包括板級支持包，交叉編譯器，文件系統(tǒng)等，可查閱參考文檔 [2] 。

3.2.2 軟件模塊

UI

在基于Linux 的異步控制卡平臺上，QT 以免費，開源，開發(fā)資料全以及在嵌入式系統(tǒng)上運行效率高等特點，已經(jīng)成為異步控制卡廠商開發(fā)UI 主要的平臺。在EZSDK 中已包含對QT4 的移植，可查閱參考文檔[3]。QT 在開源網(wǎng)站上也有很豐富的資源，可查閱參考文檔 [4] 。

多媒體

在EZSDK 中提供Gstreamer+ffmpeg的多媒體解決方案，可查閱參考文檔[5] 和參考Gstreamer文檔（參考文檔[6]）。在多媒體中，由于格式比較多，各種編碼的復雜度以及編碼質量差異較大是一個難點。而在LED 顯示墻的應用場景中，多媒體碼流可接受轉碼方式，所以可指定碼流的格式。這里，推薦的多媒體格式MP4（MPEG4+AAC），其中MPEG4 選擇simple profile，對此種碼流，若分辨率為640x480，AM335x 可流暢解碼每秒25 幀以上。

顯示后端

AM335x 只有一個功能簡單的LCD 控制器，該控制器只支持RGB 格式，其在Linux 中的驅動為framebuffer，可查閱參考文檔 [7] 。相應的上述兩個模塊的顯示后端也以framebuffer 為基礎：

Gstreamer的后端顯示插件采用fbdevsink。由于視頻解碼后的格式為YUV 格式，而AM335x 自帶的LCD 控制器只支持RGB 格式，因此此處可使用Gstreamer的插件ffmpegcolourspace進行色度空間的轉換

QT 默認以framebuffer 為顯示后端。

Framebuffer 會接收來自QT 和Gstreamer的圖像幀數(shù)據(jù)，然后進行OSD 的疊加和縮放等操作，數(shù)據(jù)流如下圖所示：

圖 4 默認軟件方案數(shù)據(jù)流程圖

軟件復雜度分析

在圖4 中，深色模塊為運算較密集模塊，具體分析如下：

Gstreamer的解碼和ffmpegcolourspace（CSC plugin）兩個模塊。

ARM 雖然有較強的運算能力，但對于較大分辨率的視頻解碼，視頻解碼的宏塊運算等需較大運算量。另外，色度空間涉及浮點運算，而且為逐點運算，所以運算量需求也不小。

以640x480 分辨率的MP4(MPEG4 simple profile+AAC) 為例，若幀率為30fps 時，ARM 核的loading 在91%左右，其中ffmpegcolourspace模塊約占運算量的50%。

Framebuffer 模塊。

在該模塊中的 OSD 疊加指的是 UI 圖層和視頻圖層之間的疊加，而且是包含帶透明度的疊加，而圖層的縮放是指對原圖等比例的縮放，因而需對每一幀數(shù)據(jù)的每個像素點進行浮點乘加運算，參考ffmpegcolourspace的運算量，該部分運算量也應較大。

可見，ARM 核無法獨自勝任系統(tǒng)所需的全部運算。

3.2.4 基于GPU 的優(yōu)化方案 – GPU Composition

GPU Composition 軟件模塊，調用 SGX530 模塊進行色彩空間轉換，OSD 疊加，圖層縮放功能，分擔A8 的運算負載使其專注于QT，視頻解碼等應用，下面將具體介紹。

GPU Composition 模塊的編譯和安裝

在TI Wiki 上有明確說明，可查閱參考文檔[8]。

GPU Composition 設計分析

A. 各功能模塊

圖 5 GPU Composition 軟件模塊圖

SGX530 實現(xiàn)的功能模塊標記為深色，具體功能如下：

a. gpuvsink該模塊設計為Gstreamer視頻顯示后端插件，將視頻解碼器解出的YUV 數(shù)據(jù)幀，傳送給SGX530 模塊。按照標準的Gstreamer視頻顯示后端插件設計，可采用標準的顯示后端接口編程。對于視頻輸入的尺寸，要求其寬（width）為4 個像素點的倍數(shù)。其輸出視頻幀數(shù)據(jù)這里可稱為Video Plane。

b. linuxfbofs

該模塊設計為QT 架構中的顯示后端，將QT 的幀數(shù)據(jù)發(fā)送到SGX530 模塊中處理。linuxfbofs和framebuffer 有同樣的接口，對于QT 應用開發(fā)是透明的。其輸出界面幀數(shù)據(jù)為Graphics Plane。

GPU Composition

該模塊基于Open GL ES 2.0 接口設計，對輸入的Video plane 和Graphics Plane 進行色彩空間轉換，圖層縮放，OSD 疊加等操作，將最終的幀數(shù)據(jù)推送到Framebuffer 中顯示。

B. 模塊間的數(shù)據(jù)流

模塊間的數(shù)據(jù)以Plane 的形式傳遞，具體介紹如下：

a. Plane格式

Video Plane 可支持YUV422，NV12，I420 和 YUV420 格式幀數(shù)據(jù)。

Graphics Plane 可支持RGB565，RGB888 和ARGB8888 幀數(shù)據(jù)。

GPU Composition 接收這些格式的幀數(shù)據(jù)，并將其轉換為RGB 格式，進行圖層縮放，OSD 疊加等操作。

b. Plane 的內存分配

SGX530 輸入內存（Buffer），只支持物理地址連續(xù)的Buffer。因此，在gpuvsink和linuxfbofs中，使用cmem（具體可查閱參考文檔[9]）據(jù)此要求分配內存Pool 來存儲幀數(shù)據(jù)，需在Linux 啟動時通過命令行參數(shù)”mem=”配置預留給Kernel 的內存，而剩下的內存即是給cmem所準備，用于分配物理連續(xù)的內存。

其大小的計算公式如下：

Pool size for Graphics Plane = width * height * Bytes Per Pixel

Pool size for Video Plane = video frame width * height * 2 (Bytes Per Pixel) * 8 (buffers)

對于一個Video Plane 可能需要多個Buffer，其具體個數(shù)定義在

gpu-compositing/gpuvsink/src/gst_render_bridge.h

#define PROP_DEF_QUEUE_SIZE 8

c. Pool傳遞

Graphics Plane 和Video Plane 以指針的形式將Pool 傳遞給GPU Composition。

C. 模塊間的控制流

a. 配置信息數(shù)據(jù)結構

對于Graphics Plane，通過命名管道“"/opt/gpu-compositing/named_pipes/video_cfg_and_data_plane_X"”其配置信息在下面數(shù)據(jù)結構中

關于此配置信息中，比較重要的有如下幾點：

對于 QT 而言，對入的對對參數(shù)來自 Linux 的 FB 對對，即對 LCD 屏的對示分辨率。

關于透明度（Alpha），Video plane 在底部，因此，Graphics Plane 決定 Video Plane的可對度。Alpha 可分對：全局Alpha，整個Plane 使用同一的一個Alpha 對；以像素點（Pixel）對對位的Alpha, 即像素的數(shù)據(jù)格式對ARGB8888，可以在局部對置Alpha。

可以通對對置對出的對構體out_g對對對出Plane 的對放。

對于Video Plane, 配置信息如下：

此配置結構體中的輸入信息，會通過Gstreamer的標準接口，通過前級的Gstreamer Plugin 進行配置。如前所述，輸入視頻幀的寬（width）的像素點數(shù)，需為4 的倍數(shù)；對于輸出信息，和Graphics Plane 一樣，可以通過配置輸出數(shù)據(jù)結構out，實現(xiàn)縮放功能。

b. 命名管道（ named pipe）配置信息

上述配置信息，通過存放于文件系統(tǒng)中的命名管道，傳遞到GPU Composition 模塊。

對于linuxfbofs，命名管道文件為/opt/gpu-compositing/named_pipes/gfx_cfg_plane_X。

對于gpuvsink，命名管道文件為/opt/gpu-compositing/named_pipes/video_cfg_and_data_plane_X

4 方案實驗

筆者基于GPU Composition 方案，在AM335x? EVM 板上，開發(fā)了Gstreamer和QT 應用程序，以驗證整個異步LED 顯示墻方案的性能。

4.1 代碼及編譯

代碼分成兩個應用：

Gstreamer部分，可在參考文檔[10]下載，為一個視頻播放器，可循環(huán)播放MP4 視頻

QT 部分，可以在參考文檔 [11]下載，包括一個時鐘和滾動字幕。

可以根據(jù)參考文檔[8]進行編譯。

4.2 代碼運行

在AM335x EVM(AM3358 主頻為720MHz)上，運行命令行如下：



這里播放的視頻流為mp4 格式，其包含有分辨率為640x480 的MPEG4 simple profile 碼流以及AAC 音頻流。

運行效果圖如下：

圖 6 示例運行效果圖

可以從截圖中看到，OSD 層和視頻層的透明度疊加很清楚。

4.3 性能分析

關于GPU Composition 方案的性能提高，可以參考下面兩個截圖。

圖7 中，沒有使用GPU Composition 方案，CPU 除了要做解碼，也需要做色彩空間轉換，其CPU 占用率達到91%。

圖8 中，使用了GPU 分擔了視頻疊加，色彩空間轉換等運算，在整個系統(tǒng)的總運算量明顯大于僅僅Gstreamer播放視頻的情況下，ARM 核的CPU 占用率僅僅只有58%，仍給應用程序留下運行的空間。

更多的示例可查閱參考文獻[8]。

圖 7 單Cortex-A8 軟解視頻流的系統(tǒng)負載

圖 8 GPU Composition 方案視頻播放的系統(tǒng)負載

5 總結

本文主要介紹了基于AM335x 的全彩LED 顯示墻異步控制卡方案，重點介紹了基于GPU 的軟件解決方案，在實現(xiàn)LED 顯示墻所需的視頻層和OSD 層疊加，縮放等功能的基礎上，仍給客戶定制的應用程序提供了足夠的開發(fā)空間。希望該方案能加速客戶進行異步控制卡的開發(fā)。