吳金策，杜勁松

（1.中國(guó)科學(xué)院研究生院，北京 100049;2.中國(guó)科學(xué)院沈陽(yáng)自動(dòng)化研究所，遼寧沈陽(yáng) 110016）

B/S架構(gòu)嵌入式視頻監(jiān)控系統(tǒng)客戶(hù)端設(shè)計(jì)

吳金策1，2，杜勁松2

（1.中國(guó)科學(xué)院研究生院，北京 100049;2.中國(guó)科學(xué)院沈陽(yáng)自動(dòng)化研究所，遼寧沈陽(yáng) 110016）

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

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

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

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

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

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

整個(gè)網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)主要用于遠(yuǎn)程監(jiān)控，利用現(xiàn)有的IP網(wǎng)絡(luò)，滿(mǎn)足授權(quán)用戶(hù)遠(yuǎn)程觀(guān)看監(jiān)控現(xiàn)場(chǎng)視頻畫(huà)面的需求。系統(tǒng)由監(jiān)控點(diǎn)前端設(shè)備、傳輸網(wǎng)絡(luò)和客戶(hù)端播放控制終端等部分組成。

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

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

1）服務(wù)器上電啟動(dòng)后，自動(dòng)啟動(dòng)Web服務(wù)器和視頻服務(wù)器程序。

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

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

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

4）客戶(hù)端播放控件模塊接收服務(wù)器傳過(guò)來(lái)的RTP數(shù)據(jù)包，進(jìn)行解碼并顯示。

2 客戶(hù)端設(shè)計(jì)

客戶(hù)端主要是結(jié)構(gòu)圖中視頻播放ActiveX控件部分?？丶譃镽TP數(shù)據(jù)包接收、FFmpeg解碼及SDL庫(kù)顯示三部分。

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

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

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

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

圖2 RTP頭部示意圖

其中重要字段有:

1）標(biāo)志（M）:1 byte，用來(lái)允許在比特流中標(biāo)記重要的事件，在本文組包過(guò)程表示一個(gè)NALU拆分最后的RTP包。

2）負(fù)載類(lèi)型（PT）:7 byte，定義了負(fù)載的格式。

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

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

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

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

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

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

鏈表的元素定義為一個(gè)rtp_packet結(jié)構(gòu)體，其定義如下:

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

1）時(shí)間戳小于當(dāng)前正在工作的幾個(gè)鏈表時(shí)間戳最小值，則該包已經(jīng)超時(shí)，可以將其丟棄，開(kāi)始接收下一個(gè)RTP包。

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

3）時(shí)間戳晚于當(dāng)前正在工作鏈表的時(shí)間戳，說(shuō)明是新的一個(gè)NALU到達(dá)。輸出時(shí)間戳最小對(duì)應(yīng)鏈表，將該包信息保存到空閑鏈表。

2.1.2 圖像緩沖丟包策略

在解碼中為了防止誤差擴(kuò)散，發(fā)送端編碼器會(huì)間隔一定的幀數(shù)發(fā)送關(guān)鍵幀（IDR），以控制編碼和解碼流程。IDR幀的作用是立刻刷新參考幀列表（DPB），重新編碼一個(gè)新的序列，使錯(cuò)誤不致傳播［7］。對(duì)于IDR幀來(lái)說(shuō)，在IDR幀之后的所有幀都不能引用任何IDR幀之前的幀的內(nèi)容。從隨機(jī)存取的視頻流中，永遠(yuǎn)可以從一個(gè)IDR播放，因?yàn)樵谒鬀](méi)有任何幀引用之前的幀。但是，不能在一個(gè)沒(méi)有IDR的視頻中從任意點(diǎn)開(kāi)始播放，因?yàn)楹竺娴膸偸菚?huì)引用前面的幀。

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

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

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

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

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

2.2 圖像解碼顯示

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

圖5 解碼流程圖

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

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

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

ActiveX是一組使用COM（組件對(duì)象模型）來(lái)實(shí)現(xiàn)功能不同的軟件部件在網(wǎng)絡(luò)環(huán)境中進(jìn)行交互的技術(shù)［10］。在Internet應(yīng)用開(kāi)發(fā)中，ActiveX必須在Visual Basic，Internet Explorer等獨(dú)立執(zhí)行軟件中運(yùn)行。

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

在Web頁(yè)面中使用ActiveX控件還需要對(duì)它進(jìn)行一些封裝，將視頻、解碼、接收顯示過(guò)程所需的動(dòng)態(tài)鏈接庫(kù)及其他文件轉(zhuǎn)變?yōu)?.cab格式的文件，*.cab格式文件可以存儲(chǔ)多個(gè)壓縮文件以便在Web頁(yè)面中加載。將生成的ActiveX控件嵌入HTML網(wǎng)頁(yè)中，客戶(hù)端在訪(fǎng)問(wèn)時(shí)可以自動(dòng)下載安裝，客戶(hù)端通過(guò)瀏覽器便可以實(shí)時(shí)顯示和操作。客戶(hù)端效果圖如圖6所示。

圖6 客戶(hù)端效果圖（截圖）

3 小結(jié)

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

:

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

［2］張友生，陳松喬.C/S與B/S混合軟件體系結(jié)構(gòu)模型［J］.計(jì)算機(jī)工程與應(yīng)用，2002，38（23）:139－140.

［3］張巖峰，王翠，榮趙.視頻會(huì)議中的同步緩沖設(shè)計(jì)［J］.計(jì)算機(jī)科學(xué)，2008，35（4）:82－84.

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

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

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

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

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

［9］鄭捷航.基于ARM的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)設(shè)計(jì)［D］.武漢:武漢理工大學(xué)，2010.

［10］夏驚濤.基于ActiveX控件的視頻監(jiān)控系統(tǒng)客戶(hù)端編程［J］.廣播與電視技術(shù)，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

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

TP393

A

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

杜勁松（1969— ），碩士生導(dǎo)師，主研計(jì)算機(jī)測(cè)量與控制、自動(dòng)化系統(tǒng)集成等，是中國(guó)自動(dòng)化學(xué)會(huì)遙控、遙感、遙測(cè)委員會(huì)成員，中國(guó)機(jī)電一體化技術(shù)應(yīng)用協(xié)會(huì)常務(wù)理事。

責(zé)任編輯:任健男

2012－09－28