基于嵌入式Linux的圖像監(jiān)控系統(tǒng)

安徽財經(jīng)大學（東校區(qū)） 盧 騫 曹海濤

基于嵌入式Linux的圖像監(jiān)控系統(tǒng)

安徽財經(jīng)大學（東校區(qū)） 盧 騫 曹海濤

在Linux環(huán)境下實現(xiàn)圖像監(jiān)控，服務器使用多生產(chǎn)者多消費者模型，同步了采集端的圖片傳輸與客戶端的圖片獲取操作，保證了數(shù)據(jù)傳輸?shù)恼_性、有序性、與完整性。使用動態(tài)多緩沖機制解決了，消費者消費速度過慢而引起的數(shù)據(jù)丟失問題。多播技術提高了網(wǎng)絡數(shù)據(jù)傳輸速率，明顯改善畫面的卡頓現(xiàn)象。

生產(chǎn)者-消費者；動態(tài)緩沖區(qū)；多播；數(shù)據(jù)采集；同步；互斥

在本次項目中通過使用攝像頭做為采集端，裝有l(wèi)inux系統(tǒng)的pc做為服務端，另有客戶端軟件，以供用戶實時觀察布設采集端區(qū)域的畫面。

在本項目中采集端與客戶端的關系，為一對多，即多個客戶端可以同時獲取同一采集端采集到的畫面信息。兩者具有明顯的生產(chǎn)者與消費者的關系。

關系較為復雜，可以逐步分解后，利用生產(chǎn)者消費者模型，進行建模。

1.每個采集端代表一個進程，可以將多個生產(chǎn)者的情況，分解為只有一個采集端的，最后在匯總求得多個采集端與多個客戶端之間的對應關系，并用代碼實現(xiàn)其功能

2.一個采集端與多個客戶端，即為一個生產(chǎn)者多個消費者模型。將采集端采集到的每一幀畫面壓縮后，通過網(wǎng)絡傳輸至服務端，并將此幀畫面通過“多播”的形式，發(fā)送給每個請求該采集端的客戶。此過程可能會出現(xiàn)播放不流暢、丟幀等問題。主要原因在于，生產(chǎn)者提供幀信息的速度大于消費者消費幀信息的速度，使得生產(chǎn)者的幀信息發(fā)生數(shù)據(jù)丟失。同時，多個消費者均需要獲取同一幀信息，導致了消費者平均等待時間較長、畫面播放不流暢。

問題解決方案：

1.通過增設動態(tài)緩沖區(qū)，使得生產(chǎn)者不會因消費速度過慢導致數(shù)據(jù)丟失。

2.通過使用多播技術提高數(shù)據(jù)傳輸速率，解決畫面卡頓問題。

生產(chǎn)者消費者介紹：

生產(chǎn)者-消費者模型是現(xiàn)代操作系統(tǒng)中典型的進程同步互斥問題，大量的多線（進）程通信系統(tǒng)應用都可以抽象為該系統(tǒng)的不同形式根據(jù)生產(chǎn)者、消費者以及緩沖區(qū)的數(shù)量，此問題可以分為8類［1］：

（1）單個生產(chǎn)者、單個消費者、單個緩沖區(qū)

（2）單個生產(chǎn)者、單個消費者、多個緩沖區(qū)

（3）單個生產(chǎn)者、多個消費者、單個緩沖區(qū)

（4）單個生產(chǎn)者、多個消費者、多個緩沖區(qū)

（5）多個生產(chǎn)者、單個消費者、單個緩沖區(qū)

（6）多個生產(chǎn)者、單個消費者、多個緩沖區(qū)

（7）多個生產(chǎn)者、多個消費者、單個緩沖區(qū)

（8）多個生產(chǎn)者、多個消費者、多個緩沖區(qū)

生產(chǎn)者消費者模型的選?。?/p>

本次項目選擇多生產(chǎn)者—多消費者模型，并建立動態(tài)多緩沖機制。為解決服務端中生產(chǎn)者數(shù)據(jù)丟失問題，可在內(nèi)存中動態(tài)開辟緩沖區(qū)，并將緩沖數(shù)據(jù)的節(jié)點按序鏈接形成鏈表，并提供首尾指針分別供消費者和生產(chǎn)者使用。在服務端的一個線程中創(chuàng)建節(jié)點接收采集端發(fā)送的幀信息，接收完成后將此節(jié)點鏈接至鏈表尾部。在另一個線程中不斷的讀取鏈表首部的節(jié)點，將節(jié)點從鏈表首部取下，將head指針指向下一待消費的節(jié)點。并取出節(jié)點中的幀信息以多播的方式發(fā)送給多播組成員。在生產(chǎn)者、消費者線程中，對鏈表以及鏈表首尾指針的操作作為臨界資源，必須互斥訪問，以避免任何情況的競爭條件。

struct ｛/* data shared by producers and consumers */

struct DATA_NODE *head；

struct DATA_NODE *tail；

Sem_t mutex， nstored； /* semaphores， not pointers */

｝ shared；

void *produce（void *）， *consume（void *）；

數(shù)據(jù)傳輸方式介紹：

網(wǎng)絡中的數(shù)據(jù)傳輸方式分為單播、廣播和多播。單播設計為發(fā)送信息至某一指定主機，廣播將數(shù)據(jù)包發(fā)送給同一網(wǎng)絡中的所有主機，而多播實現(xiàn)了把數(shù)據(jù)包發(fā)送給分散在各個子網(wǎng)的多播組成員

單播是一種點對點的傳輸方式，在向多個目標發(fā)送同一信息時，要將信息拷貝多次后分別發(fā)送至目標。單播的方式避免了發(fā)送數(shù)據(jù)給不需要的主機，但拷貝每份信息并經(jīng)過網(wǎng)絡傳輸，占用了很高的帶寬和資源，效率極低。

廣播能夠傳送一個單獨的數(shù)據(jù)流到整個子網(wǎng)，路由器和接線器傳播廣播。廣播方式對主機資源開銷不比單播大，但對網(wǎng)絡資源占用極大，并可能引起廣播風暴使得網(wǎng)絡癱瘓。廣播傳播的消息只能在子網(wǎng)范圍內(nèi)，不能跨越子網(wǎng)傳輸。

多播是一種傳播信息到多個組成員的方法。組成員接收數(shù)據(jù)包，其它成員過濾掉硬件層的多播信息。多播組成員通常比全部接受者的數(shù)量少的多，動態(tài)的多播接受者組可以迅速的建立和解散。

傳輸方式的選?。?/p>

本次項目中需要將一個采集端采集到的信息，發(fā)送給每一個選擇該采集端的客戶。單播方式占用服務端內(nèi)存資源，增加網(wǎng)絡負擔，效率較低，會出現(xiàn)畫面卡頓的現(xiàn)象。實際使用中客戶端分散在各個子網(wǎng)中，廣播方式限制較大，并會占用大量網(wǎng)絡資源，存在廣播風暴的風險。多播可較好的解決此問題，多播可以將同一數(shù)據(jù)流發(fā)送給多播組內(nèi)的每個成員，對主機資源占用較少，減輕了網(wǎng)絡負擔，并且沒有網(wǎng)絡位置的限制。在編程實現(xiàn)中，根據(jù)客戶端的選擇將客戶端ip分入不同的多播組，采集到的圖片幀通過多播方式發(fā)送給多播組成員。

結論：

生產(chǎn)者消費者模型使用廣泛，在實際應用中，要根據(jù)具體的應用需求，選擇合適的生消模型以系統(tǒng)中的同步問題。動態(tài)多緩沖機制可將效率較低的同步操作，轉(zhuǎn)化為具有整體同步效果的異步操作，大大增加了實際通信效率。在網(wǎng)絡編程中，發(fā)送相同數(shù)據(jù)包至多個目標主機，優(yōu)先考慮多播技術。多播對主機資源占用較少，減輕了網(wǎng)絡負擔，并且沒有網(wǎng)絡位置的限制。

［1］李曉宇.操作系統(tǒng)中并發(fā)進程的生產(chǎn)者-消費者問題的研究［J］.許昌學院學報，32（2）：52-56.

項目來源：本文系安徽財經(jīng)大學大學生科研創(chuàng)新基金項目研究成果，項目編號：XSKY1609ZD；安徽財經(jīng)大學大學生創(chuàng)新創(chuàng)業(yè)計劃項目研究成果，項目編號：201510378531。