HDMI VCU編碼工程中GST-VCU-APP部分代碼決議

APP概述

GST_VCU_APP 是基于 GStreamer 庫開發的一個控制軟體, 通過 APP 可實作對 PL 端 IP
核的管理，APP 完成了對 PL 端 IP 核的引數配置，以及控制 vcu 的編解碼，將 vcu 編碼后的
資料打包,用 UDP 協議將打包后的資料發送至以太網，
那么 app 是怎么實作對 IP 核的管理呢？我們按照這個問題展開說明， 從 zcu106 的 PS 與 PL 的結構圖中可知，PS 與 PL 的互動是通過 AXI 總線完成的，

APP是運行在linux系統上的一個軟體，而linux系統又是存放在PS端DDR中的，APU處理器通過CCI讀取存盤在DDR中的指令，DDR就是APU的主存，處理器通過AXI總線向PL端IP核寫入控制信號，
在vivado工程中，為每個IP核設定了對應的地址，而在PS端的設備樹中描述了相應IP核的資訊（包括地址），在加載kernel后，系統根據設備樹來注冊驅動，生成虛擬節點，妙處就在這里，也就是說這里把一個linux系統中的虛擬節點與IP核對應了起來，那么用戶空間就可以通過節點來操作IP核了（這不就是ARM處理器的基本操作嗎，但這里的資料互動是通過AXI協議進行的，更高效節省資源），

軟體整體框架：（參考：ug1250 第31頁，注：工程上的問題，xilinx官網基本上都會有相關檔案或者博客介紹）

VCU_GST_APP是一個通用的、可實作多個功能的應用軟體（既可用于視頻編解碼控制也可用于音頻編解碼，本工程只用到了視頻編碼），下圖為應用軟體庫之間的呼叫關系，

軟體庫的呼叫關系及驅動與硬體設備的管理關系框架


前面說到，系統為每個IP核注冊了對應的虛擬節點，通過media節點可在運行時配置IP核，通過video可實作對IP核的操作，HDMI Rx將接收到的信號分離出視頻與音頻信號（這里沒有用到音頻），再通過VPSS對信號作轉換；frame buffer write將資料寫入PS端DDR（frmbuf Wr怎么知道寫到DDR的哪個地址呢？PS端開始時配置了Frmbuf Wr IP核暫存器，使其按指定模式作業；然后PS端linux系統通過AXI總線下發寫地址給Frmbuf Wr，告知其資料寫入的地方），寫完一幀信號后Frmbuf Wr這個IP核將發出一個中斷信號給PS端處理器，然后VCU硬核從DDR中讀取未經編碼的資料（通過DMA方式讀寫），編碼后再放回DDR,最終PS端將編碼后的資料打包成UDP包發送出去，
在這個程序中，DDR需要開辟記憶體用于存盤PL端傳輸過來的資料，這個開辟記憶體的操作是由V4L2驅動來完成的，V4L2驅動開辟了DMA_BUFFER然后將得到的句柄傳遞給上層Gstremer庫的插件V4L2插件，由V4L2插件將句柄傳遞給gst-omx編碼器插件，編碼器插件再將檔案檔案句柄傳給編碼驅動，由此編碼器驅動即可告知PL端VCU要從哪里讀取資料進行編碼了，（關于什么是插件章節請看3.3 Gstreamer的詳細介紹 ）下圖為共享DMABuffer關系圖，DRM/KMS與顯示有關，(參考：ug1250-zcu106-trd 47頁)
其中V4L2驅動開辟了多個DMABUF，用于乒乓處理，例如開辟了三個buffer，開始時資料存在buffer_1中，VCU從這塊記憶體讀取資料進行編碼，在編碼的程序中，frmbufWr又將資料存進buffer_2中，等VCU編完buffer_1中的資料并打包發送完成，就繼續編碼buffer_2中的資料，同時frmbuf Wr又開始把資料放于buffer_3中……以此回圈往復，

APP框架流程圖

以下程式流程圖是自己從代碼中提取的資訊整理，如有理解錯誤或不當之處，待指出后更正.
Main函式:

讀取configure檔案

創建media設備

帶寬監視

vgst_config_options

使用Gstreamer庫流程

本工程用到的管道

Omxh265enc插件

capsfilter

rtpmp2tpay

mpegtsmux

DMA_BUFFER的開辟

APP中重要的函式

（1）必要的概念：媒體設備框架：https://www.jianshu.com/p/83dcdc679901
將硬體抽象為物體，然后按照一定的順序將他們連接起來，形成管道，
注冊media設備：media_device_register(struct media_device *mdev);
卸載media設備：media_device_unregister(struct media_device *mdev);
media 相關API介紹：
http://www.staroceans.org/myprojects/v4l2-utils/utils/media-ctl/mediactl.h
（2）Vgst_init函式，根據已有的media節點，例化media設備
2.1 struct media_device *media_device_new(const char *devnode);在已有的節點下例化媒體設備，在使用這些設備前必須進行列舉，

2.2.void media_device_unref(struct media_device *media);讓一個例化的設備計數減1，該設備計數達到0時，釋放它
注：每個IP核對應一個設備節點，app通過庫去與對應的IP核互動，

（3）vgst_config_options函式中初始化了Gstreamer庫，根據app_data的ip_param找到設備并對其配置
配置：先讀取攝像頭的視頻格式，獲取到格式后，把這個格式資訊再寫入DRM驅動設備中，（DRM驅動用來處理DMA，記憶體管理，資源鎖以及安全硬體訪問）， 我們這里使用了一路編碼，所以在獲取視頻格式vlib_src_config函式中的case匹配到HDMI1，vcap_hdmi_set_media_ctrl函式中，通過V4L2驅動獲取到視頻格式，

（4）記憶體映射函式void* mmap(void* start,size_t length,int prot,int flags,int fd,off_t offset);
注：記憶體映射，簡而言之就是將用戶空間的一段記憶體區域映射到內核空間，映射成功后，用戶對這段記憶體區域的修改可以直接反映到內核空間，同樣，內核空間對這段區域的修改也直接反映用戶空間，那么對于內核空間<---->用戶空間兩者之間需要大量資料傳輸等操作的話效率是非常高的，mmap系統呼叫使得行程之間通過映射同一個普通檔案實作共享記憶體，普通檔案被映射到行程地址空間后，行程可以像訪問普通記憶體一樣對檔案進行訪問，不必再呼叫read()，write（）等操作，mmap并不分配空間, 只是將檔案映射到呼叫行程的地址空間里（但是會占掉你的 virutal memory）, 然后你就可以用memcpy等操作寫檔案, 而不用write()了，

（5）perf_monitor_init（）函式里初始化了性能監視器（APM），創建了一個執行緒一直讀取AXI總線中VCU的帶寬資料（執行緒中uPerfMon_getCounterValue函式讀取了對應bus總線地址的資料，即為VCU帶寬資料），存放在vcu_apm_counter陣列中；在后面的回呼函式time_cb()中使用，

（6）Time_cb()函式中，計算編解碼器、管道的帶寬，每秒回呼一次，計算結果是否列印取決于組態檔，

（7）parse_config_file（configure檔案路徑）以只讀的方式打開組態檔，判斷檔案里的配置資訊，賦值給app_datasa結構體，（什么時候呼叫app_data結構體）
（8）get_encoder_config ()：將讀取的configure檔案內容用于配置對應的編碼引數

（9）管道的回呼函式在vgst_utils.c檔案中（bus_callback），管道中的元件都在play_ptr結構體中，
bus_callback回呼函式：每個管道都有自己的總線，APP在只需要在總線上創建自己的訊息處理器（這里用gst_bus_add_watch函式創建），當Glib庫的主回圈運行起來之后，將輪詢輪詢這個處理器是否有新的訊息，當訊息被采集到之后，總線呼叫對應的回呼函式來完成任務（這里的回呼函式為bus_callback），
注：
1）bus_callback中先對得到信號進行判斷，判斷是管道中發生錯誤，還是資料流的結束，或是在資料流中找到了元資料，發生流結束信號時，將在總線中查找發出這個信號的元件，
2）g_main_loop_run ()函式啟動了Glib庫的主回圈，當有事件產生時，它將處理相關事件；若沒有事件產生，它就進入了睡眠等待狀態，即阻塞在這個函式中，
3）app_data.playback的值一直為false，所以app的main中do…while回圈并沒有真正回圈起來，故并沒有在回圈中一直創建新的管道，所以管道中的資訊互動關鍵函式還是bus_callback；vcu編碼的引數也不是每傳完一幀資料又重新配置一次引數，而是只配置了一次，當vcu編碼好一幀影像之后產生一個中斷，PS對這個中斷的回應，

（10）vgst_create_pipeline ():創建了各元件并將其連接成管道，其中結構體app中包含了各個元件、網路IP、PORT、設備型別等，對比app_data與app結構體，app_data中除了一些主函式中的必要變數幾乎與app類似，app中特別的地方在于playback陣列，存盤了組成管道的元件，

Gstreamer庫概述

Gstreamer 是一個非常強大而且通用的流媒體應用程式框架，GStreamer 是一個創建流媒體應用程式的框架，其基本設計思想來自于俄勒岡 (Oregon) 研究生學院有關視頻管道的創意, 同時也借鑒了 DirectShow 的設計思想來源于其框架的模塊化: Gstreamer 能夠無縫的合并新的插件，GStreamer 的程式開發框架使得撰寫任意型別的流媒體應用程式成為了可能，在撰寫處理音頻、視頻或者兩者皆有的應用程式時, GStreamer 可以讓你的作業變得簡單，GStreamer并不受限于音頻和視頻處理, 它能夠處理任意型別的資料流，管道設計的方法對于實際應用的濾波器幾乎沒有負荷 , 它甚至可以用來設計出對延時有很高要求的高端音頻應用程式，GStreamer 最 顯 著 的 用 途 是 在 構 建 一 個 播 放 器上 ，GStreamer 已 經 支 持 很 多 格 式 的 文 件 了 , 包 括 : MP3、Ogg/Vorbis、MPEG-1/2、AVI、Quicktime、 mod 等等，從這個角度看,GStreamer 更象是一個播放器，但是它主要的優點卻是在于: 它的可插入組件能夠很方便的接入到任意的管道當中，這個優點使得利用 GStreamer 撰寫一個萬能的可編輯音視頻應用程式成為可能，GStreamer 框架是基于插件的, 有些插件中提供了各種各樣的多媒體數字信號編解碼器,也有些提供了其他的功能，所有的插件都能夠被鏈接到任意的已經定義了的資料流管道中，GStreamer 的管道能夠被 GUI 編輯器編輯, 能夠以 XML 檔案來保存，這樣的設計使得管道程式庫的消耗變得非常少，GStreamer 核心庫函式是一個處理插件、資料流和媒體操作的框架， GStreamer 核心庫 還提供了一個 API, 這個 API 是開放給程式員使用的—當程式員需要使用其他的插件來撰寫他所需要的應用程式的時候可以使用它，