最優視訊監控軟體開發的實作方法

    在開發視訊監控系統應用軟體時，大家往往把關注的焦點集中于數字音/視訊的編解碼的實作上，而忽略了視訊監控系統應用軟體的整體架構。當然視訊監控的核心也是在于音視訊編解碼上，佰銳的Anychat SDK 主要就是在音視訊領域這塊，長期研究音視訊即時通訊，對于音視訊處理子產品（采集、編解碼）、流媒體管理子產品（丢包重傳、抖動平滑、動态緩沖）、流媒體播放子產品（多路混音、音視訊同步）以及P2P網絡子產品（NAT穿透、UPnP支援）等多個子子產品，封裝了底層的硬體操作（音視訊采集、播放）、封裝了流媒體處理（編解碼、網絡傳輸）等非常專業和複雜的技術，為上層應用提供簡單的API控制接口，可以在極短的開發周期，以及極少的人力資源投入下為客戶的現有平台增加音視訊即時通訊、多方會議的功能。AnyChat SDK可以讓企業越過複雜的底層技術實作，而把主要精力投入項目的業務邏輯處理上，加快項目開發進展，進而為企業赢得市場先機。

    視訊監控系統中，一個優秀的音/視訊編解碼算法固然很重要，但其中是整個視訊監控系統應用軟體的一個重要組成部分。視訊監控系統應用程式還涉及到如何搞笑地輸入/輸出數字音/視訊資料，這些資料又如何與音/視訊編解碼算法協調、配合，以及視訊監控系統應用軟體各個子產品之間如何協調工作。本文主要闡述軟體開發方法，說明階層化軟體開發方法優越性。

傳統的軟體開發方法

    傳統的軟體開發方法是一種線性的程式流程，首先以功能子產品對整個程式進行子產品化，然後選擇ASM或C語言，從零開始編寫各個子子產品，最後編寫一個主循環，将這些子子產品線性地順序循環執行。

     傳統的軟體開發方法的優點是：整個程式的控制流、資料流完全由程式設計者掌握，程式直覺、易了解。但其缺點是：各個子子產品之間緊密耦合，修改某一子子產品，将可能影響整個程式，也即其代碼的重複使用率不高，導緻相似系統之間程式的移植性差；由于程式順序、循環執行，在算法對資料進行處理前，需要花大量時間來等待輸入/輸出資料就緒，導緻CPU的使用率低，同樣，簡單的順序、循環執行，隻能管理和排程單一任務，不能實作多任務的管理和排程。

倡導的DSP軟體開發方法

    為了加速DSP軟體開發，一套完善的、規範的、标準化的DSP軟體開發方法稱之為DSP軟體技術。它是以DSP/BIOS實時多任務作業系統為核心，以階層化結構為基礎的一種軟體開發方法，其優點是

       軟體結構階層化：各層之間均采用标準的API，修改某一層不會影響其它層，提高了代碼的重複使用率，改善和提高相似系統之間的程式移植性；

    應用層；

    裝置驅動層；

    硬體裝置層；

    以DSP/BIOS實時多任務核心為主要，使CPU得使用率最大化；

    DSP/BIOS負責程式的管理和排程；

    DSP/BIOS可對程式的控制流、資料流及程式執行效率進行實時分析。

    缺點是：整個程式的控制流、資料流由DSP/BIOS來管理，程式将不再直覺和易了解。豪宅DSP/BIOS提供了實時分析子產品，可全程實時分析控制流、資料流及程式執行效率。

階層化的裝置驅動程式模型

    一個裝置驅動程式開發包，為裝置驅動程式設計一個階層化的模型，稱為IOM模型，IOM模型将裝置驅動程式分為2層，上層為與硬體無關的層稱為類裝置驅動程式，負責管理裝置執行個體、同步和I/Q請求串行化等操作。與硬體五官的下層稱為迷你裝置驅動程式，負責對實際的裝置進行初始化或必要的控制操作。

類裝置驅動程式

    類裝置驅動程式是裝置驅動程式的上層抽象，時期與特定裝置無關，DDK為每一類的類裝置驅動程式定義了一組标準的API函數，應用程式均隻能通過此組API函數來調用裝置驅動程式，進而使應用程式與裝置驅動程式分離。

   DDK定義了3大類的類驅動程式：SIO、PIP和GIO。

   SIO:流I/O接口，由SIO和DIO組成，PIO負責緩沖器管理、信号同步以及底層迷你驅動程式接口。

   GIO：通用I/O，允許進行塊讀塊寫，裝置驅動程式開發者可以用其來實作新的、專用的類裝置驅動程式。

   DDK中已完整地實作了SIO和PIP類裝置驅動程式，使用SIO和PIP類裝置驅動程式的裝置驅動程式開發者無需再編寫任何類裝置驅動程式代碼。而對于使用GIO類裝置驅動程式的裝置驅動程式開發者來說，DDK已為GIO實作了一組基本的API函數，是以開發者隻需通過宏定義來調用此組API函數，實作自己專用的類裝置驅動程式。

迷你裝置驅動程式

   迷你裝置驅動程式時裝置驅動程式的底層抽象，與特定裝置有關，對硬體裝置進行實際操作，DDK為迷你裝置驅動程式規定一組标準的API函數，類裝置驅動程式通過這些标準化了的API函數來調用迷你裝置驅動程式，而對裝置驅動程式開發者來說，隻需為特定的函數體。在此組API函數的特定的函數體中，使用者則可以通過調用CLS/BSL庫來對裝置的具體硬體進行初始化和相關的控制操作。

為什麼要用IOM裝置驅動程式模型

   IOM裝置驅動程式模型是階層化了的裝置驅動程式，階層化設計通過使層之間的接口标準化，并且隻有相鄰層之間才可互相調用，來有效地将上層應用程式與下層具體的硬體裝置的操作細節分離。是以，當更換其中的某些硬體外設時，通常隻需修改底層的迷你驅動程式，而上層應用程式的修改則可最小化，進而提高上層應用程式的通用性、可重複使用性和可移植性。

IOM模型的裝置驅動程式中包含什麼

   在程式裝置是用來完成資料輸入/輸出的、完整的資料鍊路，有時單個外設并不一定稱為裝置，如：音頻輸入/輸出裝置。它是由DSP片商McBSP+IIC+DMA+中斷+片外Codec等片上/片外外設器件構成。在這樣一個資料鍊路中，單獨的一個片上/片外外設并不能完成資料真正的輸入/輸出，不能稱為裝置。那麼裝置室如何來完成相應的資料輸入/輸出？

     首先，需要對構成裝置的各外設進行初始化，設定它們的工作方式，這些外設才能正确操作。另外，外設的某些功能需要外設操作過程中動态調節，如：A/D轉換器的采樣率可能需要應用程式動态地調整；UART器件的波特率可能需要應用程式動态地調整；外設所對應的中斷、DMA/EDMA通道等也可能要由應用程式根據需要動态來修改。是以裝置驅動程式必定有裝置初始化函數、和某些相關的設定函數。

  其次，需要對其進行讀/寫操作，即完成外設最基本的輸入/輸出功能。應用程式一般是成批地處理資料，而外設往往一個接一個地輸入/輸出資料，二者之間需要緩沖器來進行緩存，裝置驅動程式的輸入/輸出函數完成外設的時間讀/寫操作，将資料存入/讀出緩沖器，應用程式則在緩沖器可用時，進行相應的處理。由此可見，緩沖器是在應用程式與裝置驅動程式之間來回切換的，不同的應用所需的緩沖器的大小不同，而且為了避免資料的覆寫，可能需要用多個緩沖器來進行切換。緩沖器的大小、緩沖器的個數、緩沖器由驅動程式管理還是由應用程式管理可根據應用的需要靈活安排。外設的讀/寫操作并非随時可以進行，必須滿足一定條件，此條件一般用于作為中斷信号或标志信号，另外，為了提升輸入/輸出的效率，往往需要用DMA/EDMA配合工作，驅動程式往往會中斷、DMA/EDMA相關聯。

  最後，驅動程式輸入/輸出的資料必須由應用程式來處理，應用程式隻有在資料就緒時，才能對緩沖器進行讀/寫操作，就存在驅動程式與應用程式同步的問題，同步一般有二種方式，一種是“阻塞”，另一種帶回調函數的非“阻塞”。二種不同的同步方式，實際對應“阻塞”方式時，選用軟體中斷型線程。

 結語

  采用IOM模型來開發底層裝置驅動程式，要比傳統的軟體開發更複雜，整個程式的控制流和資料流更不直覺和不易了解，但掌握這樣的軟體開發方法，那麼在下一個項目中已開發完的程式的繼承性和可移植性将得到充分發揮，在我們今後的軟體開發中，将起到事半功倍的作用。如今市場競争越來越激烈，如何在有限的時間内完成項目，滿足客戶的需求成為企業決策者所需要面對的現實。Anychat可以為您節約開發時間，縮短項目開發周期；節省開發費用，減少人力資源投入；平台自主開發，提升企業綜合競争力；産品跨平台，應用領域廣闊；API接口豐富，友善與第三方業務內建；專業技術支援，性能穩定可靠。

本文轉自 fanxiaojun 51CTO部落格，原文連結：http://blog.51cto.com/2343338/498613，如需轉載請自行聯系原作者