1. 程式人生 > >基於Hi3516A的H265 IPC LIVE555 開發基本原理

基於Hi3516A的H265 IPC LIVE555 開發基本原理

1 系統工作原理

系統以Hi3516A開發平臺(由高解析度1080 p的AR0330攝像頭模組和帶千兆乙太網功能的Hi3516A控制器模組組成硬體平臺,並在硬體平臺上燒寫了U-Boot、Linux核心和載入了相關 驅動)作為基礎,在該平臺上開發應用程式。

首先,程序A獲取來自AR0330攝像頭模組的YUV原始視訊影象,並使用H265壓縮編碼演算法進行壓縮編碼獲 得H265格式碼流,該過程通過使用海思提供的媒體處理平臺(MPP)實現;

其次,程序B負責響應網路客戶端的請求,將程序A的輸出碼流通過千兆乙太網接 口實時地傳送出去,該過程通過對LIVE555開原始碼(該程式碼原本只支援檔案傳送功能,而不支援記憶體實時資料傳送功能)二次開發實現;

此外,程序A與進 程B之間的資料交換使用共享記憶體程序通訊方式,節約了CPU資源和時間成本。

2 功能實現

2.1 視訊捕捉與編碼

選擇在 Hi3516A開發平臺上開發體現了在視訊捕捉和編碼過程中的很多優勢。

Hi3516A是專用於HD IP攝像機的多媒體晶片,具有高效能Cortex-A7處理器和內部整合的硬體H265視訊標準編碼器;此外,海思提供的MPP對應用軟體遮蔽了芯 片相關的複雜的底層處理,提供給應用程式方便的介面,這樣不僅大大縮短了開發週期,還降低了開發難度。對於應用程式開發者,只需要使用MPP所提供的介面 實現特定功能,滿足應用。

MPP主要由視訊輸入(VI)、視訊處理(VPSS)、視訊編碼(VENC)、視訊解碼(VDEC)、視訊輸出(VO)、視訊偵測分析(VDA)、 區域管理(REGION)等模組組成。本系統用到VI、VPSS、VENC和REGION模組完成視訊採集、處理、資訊疊加和壓縮編碼工作,最終得到目標 碼流。

首先,呼叫系統控制模組的媒體處理平臺程式設計介面(MPI)完成硬體和MPP初始化,它實現的重要功能是分配視訊快取池;

其次,呼叫VI模組的MPI建立視訊輸入裝置和視訊物理通道並設定引數;

然後,呼叫VPSS模組的MPI建立組和通道,並設定組和通道引數,輸出期望解析度的視訊資料;

最後,呼叫REGION模組的MPI,在原始影象上疊加使用者資訊,並呼叫VENC模組的MPI對YUV原始影象進行H265壓縮編碼,得到 H265格式碼流。

完成以上工作後,建立一個執行緒不斷從編碼通道獲取實時H265碼流。整個過程都通過呼叫各模組的MPI實現,難度較低。

2.2 H265實時碼流傳輸

本系統中,H265實時流媒體資料的傳輸在LIVE555 C++開源專案的基礎上實現。Live555 是一個為流媒體提供解決方案的跨平臺的C++開源專案,它實現了對標準流媒體傳輸協議如RTP/RTCP、RTSP、SIP等的支援。Live555實現 了對多種音視訊編碼格式的音視訊資料的流化、接收和處理等支援,包括MPEG、H.263+、DV、JPEG視訊和多種音訊編碼。同時由於良好的設 計,Live555非常容易擴充套件對其他格式的支援。目前,Live555已經被用於多款播放器的流媒體播放功能的實現,如VLC(VideoLan)、 MPlayer。

LIVE555預設只支援傳送音視訊檔案,而不支援從媒體裝置獲取的實時碼流。需要修改LIVE555原始碼以實現H265碼流實時傳送功能。

一 種方法是通過有名管道(FIFO)實現,這種方法不需要修改LIVE555原始碼,只需在視訊捕捉與編碼源程序中建立一個FIFO,並不斷把實時H265 碼流寫入FIFO中即可。LIVE555伺服器端用傳送音視訊檔案的方式獲取FIFO中資料,完成實時直播。這種方法容易實現,使用較多,但是當視 頻碼流率較大時監控端的延時較大,並存在卡頓、馬賽克等現象,效果較差。

另一種方法是通過修改LIVE555原始碼,從實現RTSP服務的相關基類派生出 H265碼流直播的類,重寫類的成員方法來實現。該方法通過共享記憶體程序通訊方式實現與視訊捕捉和編碼程序的碼流互動。這種方法的實現比較複雜,但在資料 處理過程中比第一種方式少了多次資料寫入和拷貝工作,從而監控端能夠以較大碼流率實時、流暢地播放高清視訊影象。

LIVE555主要通過任務排程機制和 RTSP服務機制兩個部分實現流媒體伺服器功能。其中任務排程機制主要通過TaskScheduler類庫實現,它完成網路套接字任務、延時任務和 觸發事件三種任務的迴圈排程,從而構成了系統執行框架。而RTSP服務機制通過工程的liveMedia目錄下的類庫實現,通過把RTSP協議加入到執行 框架中,實現了流媒體伺服器。下面具體分析RTSP服務機制的實現過程。

首先,建立RTSPServer,監聽客戶端的連線請求,響應客戶 端請求建立連線後,建立RTSPClientSession,RTSP協議就是在RTSPClientSession中實現的。

然後是RTSP協議的實現 過程,客戶端向伺服器端傳送RTSP描述命令(DESCRIBE),伺服器查詢到對應的ServerMediaSession(對應某個媒體裝置或某種格 式檔案),並生成會話描述協議(SDP)資訊進行迴應;

接著,客戶端傳送RTSP建立命令(SETUP),伺服器端建立RTP/RTCP套接字,並建立特 定的Source和Sink,為資料的獲取、封包和傳送做準備;

完成以上步驟後,客戶端傳送播放命令(PLAY),伺服器端響應請求,迴圈呼叫 Source物件的成員方法獲取資料並通過Sink物件的成員方法進行封包和傳送,實現流媒體伺服器的功能;在播放過程中,客戶端可以傳送終止命令 (TERADOWN)結束流媒體會話。

從RTSP協議實現過程可知,為了支援H265實時流媒體資料傳輸,需要實現使用者自定義類 ServerMediaSubssion、Source和Sink。自定義的類可以繼承H265VideoFileServer MediaSubsession、H265VideoRTPSink和H265VideoStreamFramer中能共用的方法,重寫H265實時流媒 體處理特有的方法。具體實現方法是新增H265LiveVideoServerMediaSubssion:public H265VideoFileServerMediaSubsession類,並重寫createNewStreamSource成員方法。該成員方法的關 鍵段程式碼段如下:

estBitrate=1000;
H265FramedLiveSource*liveSource=H265FramedLiveSource::createNew(envir);
if(liveSource==NULL){return NULL;}
return H265VideoStreamFramer::createNew(envir,liveSource);

該 程式碼段的主要工作是把ByteStreamFileSource替換為使用者自定義的H265FramedLiveSource,用於獲取高清攝像頭上的實 時視訊資料。H265FramedLiveSource的成員方法H265FramedLiveSource::doGetNextFrame就實現了從 H265編碼輸出端獲取H265格式視訊資料並送到H265VideoRTPSink端的過程。

其中,程序之間資料交換採用共享記憶體方式,用有名訊號量實現程序對共享記憶體的同步訪問。該成員方法的關鍵程式碼段如下:

static int niHaveReadSize=0;
if(Framed_dosent==true){
	if(0==niHaveReadSize)sem_wait(semr);
	fFrameSize=(Framed_datasize->niHaveReadSize->fMaxSize)fMaxSize:Framed_datasize-niHaveReadSize;
	memcpy(fTo,shm_add+niHaveReadSize,fFrameSize);
	niHaveReadSize+=fFrameSize;
	if(niHaveReadSize==Framed_datasize){
		sem_post(semw);
		niHaveReadSize=0;
	}
}
這樣,當伺服器端收到客戶端PLAY命令時,不斷呼叫H265FramedLiveSource::doGetNextFrame讀取H265格式視訊資料,封包和傳送出去,實現H265碼流實時傳輸功能。

在主函式中,只需在建立ServerMediaSession時加入H265LiveVideoServerMediaSubssion,並向RTSPServer中註冊該ServerMediaSession即可。

3 結果分析

H265碼流實時傳輸的程式通過海思平臺的交叉編譯工具鏈編譯,生成可執行檔案,並在海思Hi3516A開發平臺下執行,完成伺服器搭建工作。

客 戶端通過安裝Windows系統下的VLC播放器實現。開啟VLC播放器,在“開啟網路串流”選項中輸入 rtsp://192.168.1.116:8554/H265LiveVideo,點選播放,就可以看到來自高清攝像頭的視訊影象,並長期穩定工作。與 常用的FIFO方式作效果對比,當碼流率較大時,視訊影象延遲更短,視訊畫面更加完整和流暢。

實際上Darwin確實在架構以及效能方面較live555略勝一籌,但是LIVE555 是更為廉價和快捷的開發方式。