3.2 軟件方案

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

　　3.2.1 操作系統

　　如前所述，Linux是異步控制卡的主流操作系統，因此，本方案也選擇了Linux作為平臺。AM335x EZSDK提供了Linux的完整開發包，包括板級支持包，交叉編譯器，文件系統等。

　　3.2.2 軟件模塊

　　UI

　　在基于Linux的異步控制卡平臺上，QT以免費，開源，開發資料全以及在嵌入式系統上運行效率高等特 點，已經成為異步控制卡廠商開發UI主要的平臺。在EZSDK中已包含對QT4的移植。 QT在開源網站上也有很豐富的資源。

　　多媒體

　　在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的圖像幀數據，然后進行OSD的疊加和縮放等操作，數據流如下圖所示：

　　圖4 默認軟件方案數據流程圖

　　3.2.3軟件復雜度分析

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

　　Gstreamer的解碼和ffmpegcolourspace（CSC plugin）兩個模塊。ARM雖然有較強的運算能力，但對于較大分辨率的視頻解碼，視頻解碼的宏塊運算等需較大運算量。另外，色度空間涉及浮點運算，而且為逐點運算，所以運算量需求也不小。以640x480分辨率的MP4（MPEG4 simple profile+AAC）為例，若幀率為30fps時，ARM核的loading在91%左右，其中ffmpegcolourspace模塊約占運算量的 50%。

　　Framebuffer模塊。在該模塊中的OSD疊加指的是UI圖層和視頻圖層之間的疊加，而且是包含帶透明度的疊加，而圖層的縮放是指對原圖等比例的縮放，因而需對每一幀數據的每個像素點進行浮點乘加運算，參考ffmpegcolourspace的運算量，該部分運算量也應較大。可見，ARM核無法獨自勝任系統所需的全部運算。

　　3.2.4 基于GPU的優化方案–GPU Composition

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

　　GPU Composition模塊的編譯和安裝。在TI Wiki上有明確說明，可查閱參考文檔［8］。

　　GPU Composition設計分析

　　A.各功能模塊

　　圖5 GPU Composition軟件模塊圖

　　SGX530實現的功能模塊標記為深色，具體功能如下：

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

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

　　GPU Composition

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

　　B. 模塊間的數據流

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

　　a. Plane格式

　　Video Plane可支持YUV422，NV12，I420和YUV420 格式幀數據。

　　Graphics Plane可支持RGB565，RGB888和ARGB8888幀數據。

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

　　b. Plane的內存分配

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

　　其大小的計算公式如下：

　　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，其具體個數定義在

　　gpu-compositing/gpuvsink/src/gst_render_bridge.

　　#define PROP_DEF_QUEUE_SIZE 8

　　c. Pool傳遞

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

　　C. 模塊間的控制流

　　a. 配置信息數據結構

　　對于Graphics Plane，通過命名管道““/opt/gpu-

　　compositing/named_pipes/video_cfg_and_data_plane_X””其配置信息在下面數據結構中

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

　　1、對于QT而言，對入的對對參數來自Linux的FB對對，即對LCD屏的對示分辨率。

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

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

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

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

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

　　上述配置信息，通過存放于文件系統中的命名管道，傳遞到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板上，開發了Gstreamer和QT應用程序，以驗證整個異步LED顯示墻方案的性能。

　　4.1 代碼及編譯

　　代碼分成兩個應用：

　　Gstreamer部分，可在參考文檔［10］下載，為一個視頻播放器，可循環播放MP4視頻

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

　　可以根據參考文檔［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分擔了視頻疊加，色彩空間轉換等運算，在整個系統的總運算量明顯大于僅僅Gstreamer播放視頻的情況下，ARM核的CPU占用率僅僅只有58%，仍給應用程序留下運行的空間。更多的示例可查閱參考文獻［8］。

　　圖7 單Cortex-A8軟解視頻流的系統負載

　　圖8 GPU Composition方案視頻播放的系統負載

　　5 總結

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