B/S架構嵌入式視頻監(jiān)控系統(tǒng)客戶端設計

吳金策，杜勁松

（1.中國科學院研究生院，北京 100049;2.中國科學院沈陽自動化研究所，遼寧沈陽 110016）

B/S架構嵌入式視頻監(jiān)控系統(tǒng)客戶端設計

吳金策1，2，杜勁松2

（1.中國科學院研究生院，北京 100049;2.中國科學院沈陽自動化研究所，遼寧沈陽 110016）

主要闡述基于B/S架構的嵌入式網絡視頻監(jiān)控客戶端的設計與實現(xiàn)，重點介紹了按RTP協(xié)議封裝的H.264視頻數(shù)據接收過程中緩沖機制的實現(xiàn)以及基于FFmpeg和SDL的視頻解碼與顯示。對B/S結構中ActiveX控件在視頻監(jiān)控客戶端中的應用也做了一些介紹。實驗結果表明，該客戶端能夠通過瀏覽器對監(jiān)控現(xiàn)場進行監(jiān)控，且具有使用方便等特點，適合用于遠程監(jiān)控。

B/S;RTP;緩沖區(qū);FFmpeg;SDL;ActiveX

隨著計算機技術、網絡技術、視頻壓縮編碼技術等關鍵技術的飛速發(fā)展，特別是寬帶網絡的迅速普及，網絡視頻的實時傳輸成為網絡應用的熱點之一。目前，視頻傳輸技術正迅速被應用于視頻會議、IP可視電話、Internet遠程教育、醫(yī)療監(jiān)控等領域。

嵌入式系統(tǒng)是以應用為中心，軟硬件可裁減的專用計算機系統(tǒng)。它主要由嵌入式微處理器、相關支撐硬件、嵌入式操作系統(tǒng)及應用軟件等組成。傳統(tǒng)的視頻監(jiān)控系統(tǒng)是應用現(xiàn)有的計算機技術，系統(tǒng)龐大，軟硬件資源得不到充分利用而嵌入技術的應用能使監(jiān)控系統(tǒng)小型化，更能集中各種所需功能［1］。與PC的視頻監(jiān)控系統(tǒng)相比，嵌入式監(jiān)控系統(tǒng)具有成本低、耗電少、實時性好、易于升級與擴展等優(yōu)點，具有良好的應用前景，在視頻監(jiān)控中也得到了快速的發(fā)展。

B/S（Browser/Server）體系結構利用網絡瀏覽器，結合腳本語言和ActiveX技術，實現(xiàn)了許多以前專用軟件才可以完成的復雜功能。這種方式節(jié)約了開發(fā)成本，在服務器端系統(tǒng)安裝和維護便可解決，是一種全新的軟件體系結構［2］。本文主要探討一種B/S架構的嵌入式視頻監(jiān)控系統(tǒng)，著重介紹客戶端中為RTP數(shù)據丟包亂序問題而設計的緩沖機制以及FFmpeg解碼、SDL顯示等關鍵技術。

1 系統(tǒng)總體架構

整個網絡視頻監(jiān)控系統(tǒng)主要用于遠程監(jiān)控，利用現(xiàn)有的IP網絡，滿足授權用戶遠程觀看監(jiān)控現(xiàn)場視頻畫面的需求。系統(tǒng)由監(jiān)控點前端設備、傳輸網絡和客戶端播放控制終端等部分組成。

圖1是整個監(jiān)控系統(tǒng)結構圖，在此系統(tǒng)結構中，服務器由Web服務器和視頻服務器兩部分組成。通過Web服務器，客戶端獲得包含視頻播放控件的Web頁面作為操作界面。視頻服務器則負責從攝像頭采集視頻圖像數(shù)據，對圖像進行編碼、壓縮及發(fā)送。嵌入在客戶端瀏覽器中的視頻播放控件負責接收、解碼和播放視頻圖像。在此結構中，視頻圖像數(shù)據在服務器和客戶端之間不再通過HTTP協(xié)議進行發(fā)送，而是采用適合流媒體數(shù)據傳送的RTP/RTCP協(xié)議，這樣的方式減小了數(shù)據傳輸?shù)臅r延，也減輕了Web服務器的負擔。

整個系統(tǒng)工作流程如下:

1）服務器上電啟動后，自動啟動Web服務器和視頻服務器程序。

2）用戶通過Web瀏覽器請求監(jiān)控頁面，Web服務器模塊接收到請求后，首先通過CGI程序驗證用戶身份。對合法用戶的請求，返回包含視頻播放ActiveX控件的Web頁面給瀏覽器。

圖1 視頻監(jiān)控系統(tǒng)結構圖

3）用戶在客戶端的播放控件中選擇開始監(jiān)控，命令被發(fā)送到視頻服務器模塊的監(jiān)聽端口。視頻服務器模塊啟動視頻采集，對采集到的圖像進行壓縮編碼，通過RTP協(xié)議將圖像發(fā)送到客戶端的指定端口。

4）客戶端播放控件模塊接收服務器傳過來的RTP數(shù)據包，進行解碼并顯示。

2 客戶端設計

客戶端主要是結構圖中視頻播放ActiveX控件部分。控件分為RTP數(shù)據包接收、FFmpeg解碼及SDL庫顯示三部分。

2.1 圖像接收緩沖機制實現(xiàn)

為了保證傳輸?shù)膶崟r性，視頻流媒體的實時傳輸在傳輸層都采用UDP協(xié)議，而放棄了有差錯檢驗和錯誤重傳機制的TCP協(xié)議［3］。雖然在應用層可以采用RTP/RTCP協(xié)議提供一定的保證，但在傳輸層上丟包亂序的情況仍然無法避免，所以應用程序必須采用必要的策略對丟包和亂序數(shù)據進行處理。如果對亂序數(shù)據直接交給下游的解碼器處理，解碼后圖像嚴重失真［4］。為解決這個問題，在數(shù)據遞交給解碼器之前緩沖一定數(shù)量的數(shù)據包，完成對數(shù)據包重新排序，以達到平滑播放的效果。

視頻傳輸模塊按照RTP協(xié)議打包并發(fā)送到客戶端。由于一個H.264編碼器輸出單元NALU可能較大，封裝成RTP數(shù)據包時，如果數(shù)據包長度超過了網絡中的最大傳輸單元（MTU），就會被拆分成多個分片進行傳輸［5］。RTP協(xié)議下層使用UDP協(xié)議，而UDP協(xié)議是不保證傳輸質量的，如果被拆分的包中某個分片由于網絡擁塞而出現(xiàn)了丟失，接收方便無法重組UDP數(shù)據報，從而導致整個RTP包被丟棄。因此，需要將RTP包的長度控制在網絡的MTU允許的范圍以內。MTU通常為1 500 byte，除去RTP數(shù)據報和UDP數(shù)據報首部，NALU最好控制在1 400 byte左右。這樣，當需要發(fā)送的NALU大小超過了1 400 byte時，先將這幀圖像數(shù)據切割成若干段，然后按照協(xié)議RFC3984，將每一段封裝成一個RTP數(shù)據包進行發(fā)送，一幀圖像就被分成多個RTP包進行傳輸。

為了使接收端在接收到RTP包后能夠重組，必須知道哪些RTP包中的數(shù)據屬于同一個NALU。這可以通過設置RTP協(xié)議中的時間戳字段來實現(xiàn)，將同一個NALU的所有RTP包的時間戳設為一致，不同NALU的時間戳設為不同。此外，由于RTP包到達接收端的順序有可能與發(fā)送的順序不同，還需要在RTP數(shù)據包中利用序號字段來對發(fā)送的順序進行標識。圖2為RTP協(xié)議頭部示意圖［6］。

圖2 RTP頭部示意圖

其中重要字段有:

1）標志（M）:1 byte，用來允許在比特流中標記重要的事件，在本文組包過程表示一個NALU拆分最后的RTP包。

2）負載類型（PT）:7 byte，定義了負載的格式。

3）序列號（sequence number）:16 byte，每發(fā)送一個RTP數(shù)據包，序列號加1，接收端可以據此檢測丟包和重建包序列。

4）時間戳（timestamp）:32 byte，時間戳反映了RTP數(shù)據包中第一個字節(jié)的采樣時間，可以用作區(qū)分不同NALU的依據。

2.1.1 圖像緩沖實現(xiàn)

圖像緩沖采用兩級策略，一級為RTP數(shù)據包緩沖，二級為NALU組合。接收到的數(shù)據先經一級緩沖隊列按時間戳和序列號進行重排序，其輸出結果送入下級進行NALU組合，輸出為完整的NALU，然后送給解碼單元。NALU組合流程圖如圖3所示。緩沖區(qū)工作原理圖如圖4所示。

RTP頭部中時間戳字段表示圖像采樣時間，由同一NALU拆分得到的RTP包時間戳相同，因而可以用來區(qū)分不同NALU。序列號字段表示RTP包發(fā)送順序，每發(fā)送一個包，序列號值增加1。依靠RTP頭部中的時間戳和序列號字段，可以判斷接收的RTP包是否屬于同一個NALU，并對其排序。

由于緩沖過程需要頻繁插入與修改，而鏈表結構實現(xiàn)這些操作較為簡單高效，采用鏈表來緩存數(shù)據包并排序。為避免緩沖過程中內存的頻繁分配和釋放，最開始便對工作鏈表進行初始化，為每個鏈表分配了一定數(shù)量的節(jié)點，其中設置了1個空閑鏈表和4個組幀鏈表，輸出鏈表在解碼完成后設置結構體中相應域成為空閑鏈表，循環(huán)交替，任一時刻都有4個不同時間戳對應鏈表進行緩沖。

鏈表的元素定義為一個rtp_packet結構體，其定義如下:

每接收到一個RTP包，首先判斷其是否屬于正在工作的4個NALU鏈表，具體可以分為以下3種情形:

1）時間戳小于當前正在工作的幾個鏈表時間戳最小值，則該包已經超時，可以將其丟棄，開始接收下一個RTP包。

2）時間戳等于正在工作的某個鏈表對應時間戳，則遍歷對應鏈表，從中取一個節(jié)點修改各字段值并將該節(jié)點插入到該鏈表中。若沒有空閑節(jié)點，則為其分配一個，保存該RTP包信息并將其接入到鏈表。

3）時間戳晚于當前正在工作鏈表的時間戳，說明是新的一個NALU到達。輸出時間戳最小對應鏈表，將該包信息保存到空閑鏈表。

2.1.2 圖像緩沖丟包策略

在解碼中為了防止誤差擴散，發(fā)送端編碼器會間隔一定的幀數(shù)發(fā)送關鍵幀（IDR），以控制編碼和解碼流程。IDR幀的作用是立刻刷新參考幀列表（DPB），重新編碼一個新的序列，使錯誤不致傳播［7］。對于IDR幀來說，在IDR幀之后的所有幀都不能引用任何IDR幀之前的幀的內容。從隨機存取的視頻流中，永遠可以從一個IDR播放，因為在它之后沒有任何幀引用之前的幀。但是，不能在一個沒有IDR的視頻中從任意點開始播放，因為后面的幀總是會引用前面的幀。

上一級緩沖以接收到的RTP數(shù)據包為單位，其輸出為同一時間戳的數(shù)據包，需要下一級緩沖進行重組，將拆分的數(shù)據包重新組合成完整的NALU，然后把NALU給解碼器處理。在一個視頻序列中，假設某幀F(xiàn)rame［i］不正確，這時如果對此幀解碼，就會錯誤解碼。如果Frame［i］為參考幀，解碼器在解碼Frame［i+1］的時候就會以Frame［i－1］作為參考幀解碼。顯然，這種錯誤解碼會導致圖像質量下降，嚴重影響視頻效果。所以，在緩沖區(qū)要根據幀類型制定合理的丟包策略。

在經過一級RTP緩沖后，有部分數(shù)據包還未到達，其輸出數(shù)據還有可能不完整，接收到數(shù)據包后應該判斷序列號是否連續(xù)，即是否存在丟包。如果存在丟包，則丟棄該包，直接檢測到下一個IDR出現(xiàn)。一個IDR由三部分組成，包括SPS序列參數(shù)集、PPS圖像參數(shù)集、I幀圖像，可以通過對NALU頭部特定字段進行檢查來判別。

下面是丟包組幀策略實現(xiàn)過程:

1）對接收數(shù)據包類型進行判斷，檢查是否為SPS序列參數(shù)集、PPS圖像參數(shù)集、I幀圖像。

2）開始組包，通過判斷RTP包頭部類型，結束標志，以及序列號是否連續(xù)進行組包。若檢測到序列號不連續(xù)即丟包現(xiàn)象，則停止組包，直到接收到下一個關鍵幀再重新開始接收并組包，然后傳遞給下級解碼單元。

2.2 圖像解碼顯示

圖像解碼流程如圖5所示。

圖5 解碼流程圖

FFmpeg是一個集錄制、轉換、音/視頻編解碼功能為一體的完整的開源免費解決方案。FFmpeg的開發(fā)是基于Linux操作系統(tǒng)，但可以在大多數(shù)操作系統(tǒng)中編譯和運行。它采用了主程序+核心庫的編程模式，核心庫隱藏了其內部各種的具體格式的實現(xiàn)，對外提供了統(tǒng)一的調用方法［8］。解碼時FFmpeg主要調用 av_register_all（），avcodec_alloc_frame（），avcodec_find_decoder（）等函數(shù)來完成。解碼時主要涉及 FFmpeg下的avcodec庫、swscale庫，其中第一個庫是一個包含了所有FFmpeg音視頻解碼器的各種函數(shù)，第二個庫是格式轉化庫，利用該庫可把YUV420格式轉化成計算機上顯示所需的RGB格式。

SDL（Simple Directmedia Layer）是一個自由的跨平臺的多媒體開發(fā)包，具有簡單易用、高性能和跨平臺的優(yōu)點，被廣泛應用于各種操作系統(tǒng)中［9］。視頻顯示主要是通過對overlay數(shù)據結構賦值來完成顯示。FFmpeg解碼輸出為YUV420格式的數(shù)據，為避免YUV到RGB格式的轉換，可以直接利用overlay顯示。視頻顯示程序主要包括SDL初始化、創(chuàng)建display_surface、創(chuàng)建overlay、鎖定overlay、處理視頻圖像數(shù)據、解鎖 overlay、顯示圖像、關閉退出。

2.3 ActiveX控件及其在Web中的實現(xiàn)

ActiveX是一組使用COM（組件對象模型）來實現(xiàn)功能不同的軟件部件在網絡環(huán)境中進行交互的技術［10］。在Internet應用開發(fā)中，ActiveX必須在Visual Basic，Internet Explorer等獨立執(zhí)行軟件中運行。

為提高軟件升級和維護的方便性，將客戶端接收緩沖、解碼、顯示部分封裝在ActiveX中，這樣同時也減輕客戶端操作的負擔。用HTML生成加載ActiveX控件主頁，并將它放到ARM平臺上基于Linux的Boa Web服務器中，用戶訪問ARM平臺上的嵌入式服務器Boa時，會將ActiveX從視頻服務器下載并安裝，視頻服務器同ActiveX實現(xiàn)通信，完成視頻監(jiān)控功能。另外為了通過Boa來實現(xiàn)客戶端與服務器的動態(tài)交互，還需要編寫CGI腳本。

在Web頁面中使用ActiveX控件還需要對它進行一些封裝，將視頻、解碼、接收顯示過程所需的動態(tài)鏈接庫及其他文件轉變?yōu)?.cab格式的文件，*.cab格式文件可以存儲多個壓縮文件以便在Web頁面中加載。將生成的ActiveX控件嵌入HTML網頁中，客戶端在訪問時可以自動下載安裝，客戶端通過瀏覽器便可以實時顯示和操作?？蛻舳诵Ч麍D如圖6所示。

圖6 客戶端效果圖（截圖）

3 小結

本文主要介紹一種B/S模式嵌入式視頻監(jiān)控系統(tǒng)客戶端的實現(xiàn)，系統(tǒng)編碼采用H.264格式，壓縮比高，減少了帶寬占用。針對網絡視頻數(shù)據抖動現(xiàn)象，設計了一種緩沖機制，很好地解決了丟包亂序問題。最后，介紹了視頻客戶端ActiveX的制作，并將其嵌入到網頁中，只需瀏覽器便可以實現(xiàn)遠程監(jiān)控。隨著網絡技術的發(fā)展，基于B/S的嵌入式視頻監(jiān)必將有廣闊的市場空間和良好的發(fā)展前景。

:

［1］林德彬，趙慧民，譚恒良.基于ARM嵌入式局域網視頻監(jiān)控系統(tǒng)的設計與實現(xiàn)［J］.電視技術，2006，30（9）:88－89.

［2］張友生，陳松喬.C/S與B/S混合軟件體系結構模型［J］.計算機工程與應用，2002，38（23）:139－140.

［3］張巖峰，王翠，榮趙.視頻會議中的同步緩沖設計［J］.計算機科學，2008，35（4）:82－84.

［4］齊俊杰，胡潔，麻信洛.流媒體技術入門與提高［M］.北京:國防工業(yè)出版社，2009.

［5］陳斌.H.264保真度擴展研究與無線視頻監(jiān)控系統(tǒng)的實現(xiàn)［D］.上海:上海交通大學，2007.

［6］CASNER S，F(xiàn)REDERICK R，JACOBSON V.RFC3550，RTP［D］.Columbia:USA Columbia University，2003.

［7］畢厚杰.新一代視頻壓縮編碼標準——H.264/AVC［M］.北京:人民郵電出版社，2006.

［8］唐玲娜.H.264視頻解碼優(yōu)化及DSP實現(xiàn)［D］.成都:電子科技大學，2009.

［9］鄭捷航.基于ARM的網絡視頻監(jiān)控系統(tǒng)設計［D］.武漢:武漢理工大學，2010.

［10］夏驚濤.基于ActiveX控件的視頻監(jiān)控系統(tǒng)客戶端編程［J］.廣播與電視技術，2006，33（1）:85－88.

Design of Client for Embedded Video Monitoring System Based on B/S Structure

WU Jince1，2，DU Jinsong2

（1.Graduate School of the Chinese Academy of Sciences，Beijing 100049，China;
2.Shenyang Institute of Automation，Chinese Academy of Sciences，Shenyang 110016，China）

The design of the client for an embedded video monitoring system based on B/S structure is mainly introduced.It emphasizes on the implementation of the buffer mechanism when receiving H.264 data with RTP protocol.The method used in the video decoding and displaying process using FFmpeg and SDL are also elaborated.In the end，the application method of ActiveX component in video monitoring is introduced.The experimental result shows that the client can achieve the monitoring on remote place，and it is easy to use.

B/S;RTP;Buffer;FFmpeg;SDL;ActiveX

【本文獻信息】吳金策，杜勁松.B/S架構嵌入式視頻監(jiān)控系統(tǒng)客戶端設計［J］.電視技術，2013，37（3）.

TP393

A

吳金策（1988— ），碩士生，主研測量與控制，嵌入式系統(tǒng);

杜勁松（1969— ），碩士生導師，主研計算機測量與控制、自動化系統(tǒng)集成等，是中國自動化學會遙控、遙感、遙測委員會成員，中國機電一體化技術應用協(xié)會常務理事。

責任編輯:任健男

2012－09－28