以iOS為基礎(chǔ)的音視頻監(jiān)控軟件的設(shè)計分析

徐曄

【摘要】? ? iOS是由蘋果公司于2007年公布的移動操作系統(tǒng)，最初是由iPhone使用，后陸續(xù)用于iPad、iPod touch上，其與蘋果的另一款操作系統(tǒng)macOS一樣，都屬于Unix類型的商業(yè)操作系統(tǒng)。為實現(xiàn)在iOS平臺上對某些場景的音視頻在線監(jiān)控，相關(guān)從業(yè)人員開始探究以iOS為基礎(chǔ)的音視頻監(jiān)控軟件的設(shè)計路徑，而無線傳輸系統(tǒng)不但存在網(wǎng)絡(luò)不穩(wěn)定的問題，在音視頻的編碼與解碼方面所用的時間也會不同，這將會造成音視頻在數(shù)據(jù)處理方面的不同步，因此相關(guān)軟件設(shè)計者采用實時傳輸協(xié)議，也就是RTP的形式來傳輸相關(guān)的音視頻數(shù)據(jù)，而在信令控制協(xié)議方面則選擇會話初始化協(xié)議，也就是SIP。文章就以iOS為基礎(chǔ)的音視頻監(jiān)控軟件系統(tǒng)設(shè)計分析、基于實時傳輸協(xié)議的音視頻同步控制、音視頻解碼實現(xiàn)進行設(shè)計分析與探究。

【關(guān)鍵詞】? ? iOS? ? 音視頻監(jiān)控軟件? ? 設(shè)計分析

引言：

隨著科技與信息化技術(shù)的發(fā)展，網(wǎng)絡(luò)監(jiān)控系統(tǒng)先后經(jīng)過模擬、半數(shù)字與數(shù)字三個發(fā)展時代，并且已經(jīng)逐步應(yīng)用于各個行業(yè)。然而各行各業(yè)對現(xiàn)實場景監(jiān)控的需求，除對圖像信息有所要求外，也開始對聲音信息有所需求，比如司法、教育、安防等行業(yè)?；诖?，網(wǎng)絡(luò)監(jiān)控系統(tǒng)已經(jīng)逐步實現(xiàn)從傳統(tǒng)形式視頻監(jiān)控實現(xiàn)向基于移動終端的音視頻監(jiān)控轉(zhuǎn)變，而iOS操作系統(tǒng)內(nèi)置的音視頻處理框架在聲音播放、圖像優(yōu)化與渲染有著較大的優(yōu)勢，可以說以iOS為基礎(chǔ)的音視頻監(jiān)控軟件在音視頻質(zhì)量、內(nèi)存消耗、CPU使用率等方面相較于其他系統(tǒng)都更加優(yōu)秀。

一、以iOS為基礎(chǔ)的音視頻監(jiān)控軟件系統(tǒng)設(shè)計分析

1.1 iOS簡述

iOS是一種應(yīng)用于iPhone、iPad等蘋果產(chǎn)品的手持設(shè)備操作系統(tǒng)，以Darwin為基礎(chǔ)，機構(gòu)從高到低可分為可接觸層、媒體層、核心服務(wù)層、核心操作系統(tǒng)層。核心操作層主要提供硬件與應(yīng)用程序溝通、安全問題處理服務(wù);核心服務(wù)層主要包括核心服務(wù)庫與以核心服務(wù)庫為基礎(chǔ)的相關(guān)高級功能;媒體層提供視頻播放、音頻播放與圖像渲染等功能;可接觸層主要包括屏幕上的加速感應(yīng)、文件或相機存取、圖片網(wǎng)頁顯示、文字輸出與多點觸摸事件處理等。軟件主要用到可接觸層的UIKit框架中Framework、UIGestureRecognizer等功能來實現(xiàn)手勢操作與界面設(shè)計功能;媒體層中AV Fondation可用于音視頻播放以及圖像渲染;核心服務(wù)層主要用到Core Date Framework與CFNetWork Framework的相關(guān)功能，比如Core Date Framework中的網(wǎng)絡(luò)溝通功能，CFNetWork Framework中的MVC管理，即模型Model、視圖View、控制器Controller[1]。

1.2以iOS為基礎(chǔ)的音視頻監(jiān)控軟件系統(tǒng)框架

音視頻監(jiān)控軟件系統(tǒng)主要包括客戶端、服務(wù)端與設(shè)備端三部分，客戶端的作用是提供功能完整、簡單明了的操作界面，能夠使音視頻監(jiān)控軟件的各項功能得以實現(xiàn);服務(wù)端包括流媒體與SIP信令兩個服務(wù)器，流媒體服務(wù)器的作用是根據(jù)用戶的操作來轉(zhuǎn)發(fā)來自設(shè)備端相關(guān)音視頻數(shù)據(jù)，SIP服務(wù)器用于音視頻監(jiān)控軟件系統(tǒng)中各種信令信息的轉(zhuǎn)發(fā)以及傳輸，同時還會負責管理系統(tǒng)中的終端;設(shè)備端作用主要是實現(xiàn)音視頻監(jiān)控軟件的打包發(fā)送功能、壓縮編碼功能與相關(guān)數(shù)據(jù)采集功能。

以iOS為基礎(chǔ)的音視頻監(jiān)控軟件系統(tǒng)設(shè)計采用MVC模式，MVC是現(xiàn)階段應(yīng)用時間最長，且最為成功的一種軟件設(shè)計模式，其對蘋果Cocoa框架結(jié)構(gòu)的定義有著決定性作用。MVC模式能夠?qū)?fù)雜的各個協(xié)作對象組成的大型群組按照一定的形式分為多個有序、獨立、互不干擾的子系統(tǒng)：控制器、視圖、模型。MVC模式最主要的目的為解除視圖與子系統(tǒng)的耦合，讓其能夠獨立變化、各自工作。

通過MVC模式能夠充分實現(xiàn)iOS平臺客戶端，處理各種后臺數(shù)據(jù)，包括接收音視頻相關(guān)所需數(shù)據(jù)、收發(fā)信令與其他各項操作，并且將這些后臺數(shù)據(jù)處理操作與界面操作進行獨立，通過控制其來進行兩方的通信，這對于模塊耦合程度的降低有著一定的促進作用。用戶的所有動作與操作都可應(yīng)用控制其傳輸?shù)胶笈_，讓其進行對應(yīng)的處理，后臺的各項數(shù)據(jù)變化同時也會輸送到控制器，讓其通傳到視圖進而做出變化。由此可將以iOS為基礎(chǔ)的音視頻監(jiān)控軟件分成兩個獨立的模塊進行設(shè)計工作：其一，后臺數(shù)據(jù)處理模塊，其下又包括音視頻數(shù)據(jù)解碼播放、服務(wù)器與客戶端通信兩個小模塊;其二，操作界面設(shè)計模塊，其包括iOS系統(tǒng)手勢操作各項設(shè)計、能夠同時包含多個視頻畫面的顯示界面、設(shè)備信息列表畫面以及登錄界面。后臺數(shù)據(jù)處理主要包括RTPX協(xié)議與FFmpeg，RTPX協(xié)議用于接收音視頻數(shù)據(jù)，將其同步后輸送至FFmpeg，利用解碼器解碼之后進行音視頻播放。無線網(wǎng)絡(luò)有時會不太穩(wěn)定造成網(wǎng)絡(luò)延遲，如此音視頻解碼也會同步延遲，從而導(dǎo)致音視頻的抖動與延遲，若是不經(jīng)過處理，直接通過FFmpeg解碼播放，將會出現(xiàn)馬賽克、視頻跳幀與音頻不同步，為解決這項問題，以iOS為基礎(chǔ)的音視頻監(jiān)控軟件決定使用以RTP為基礎(chǔ)的音視頻同步控制[2]。

二、以RTP為基礎(chǔ)的音視頻同步控制

RTP協(xié)議以傳輸層UDP協(xié)議為基礎(chǔ)進行數(shù)據(jù)傳輸，是一種無連接形式的數(shù)據(jù)純屬，其實時性與穩(wěn)定性能夠最大程度的滿足流媒體數(shù)據(jù)各方面的傳輸要求。按照RTP協(xié)議中的分裝數(shù)據(jù)包中涵蓋的同步源標識、時間戳、序列號、數(shù)據(jù)類型等字段，為數(shù)據(jù)流同步以及數(shù)據(jù)丟失檢測提供全方位的支撐。

2.1媒體內(nèi)同步

無線網(wǎng)絡(luò)在傳輸數(shù)據(jù)信息的過程中出現(xiàn)網(wǎng)絡(luò)不穩(wěn)或者延遲，音視頻解碼過程中發(fā)生延遲等因素都將直接致使音視頻數(shù)據(jù)抖動與延遲，若是不經(jīng)過相關(guān)處理而經(jīng)解碼器直接解碼播放，將會造成一系列問題，因此就音視頻監(jiān)控軟件設(shè)計時可充分利用RTP協(xié)議中的序列號來進行消除，其方法是在獲取RTP包序列號之后，再經(jīng)過全面的比較來實現(xiàn)音視頻數(shù)據(jù)包重新排序，其基本框架圖如下圖1所示

2.2媒體間同步

根據(jù)相關(guān)的音視頻同步標準能夠得出以下結(jié)論：音視頻同步與設(shè)備性能有關(guān)的同時，還與使用人的聽視覺特性有一定關(guān)聯(lián)，當聲音處于超前20ms與落后90ms時，音視頻監(jiān)控軟件系統(tǒng)使用者一般是體會不到視聽質(zhì)量的相關(guān)變化，據(jù)相關(guān)研究顯示，一般對人們沒有影響的聲音超前于圖像范圍為90ms，落后范圍為不超過180ms，當以視頻偏移狀況在此范圍之外時就需要進行及時的同步調(diào)整。此外，人的耳朵對聲音的感知比眼睛對圖像的感知更加靈敏，能夠更快、更準確的感受到其中的變化。因此在進行音視頻同步控制算法時可將音頻的具體播放時間作為參考，得到音頻實時播放時間戳，將其設(shè)為PT-A，而視頻時間戳為PT-V，將音頻播放時間戳與視頻播放時間戳進行比較，用PT-A值減去PT-V值，若其相差在-185ms與90ms之間時，視頻幀將會正常播放，若是其相差在90ms時，則視頻幀存在滯后現(xiàn)象，此視頻幀需丟棄，若是其差值在-185ms之內(nèi)，則該視頻幀存在超前現(xiàn)象，需在下次進行對比之后處理[3]。

三、音視頻解碼實現(xiàn)

音視頻監(jiān)控軟件依托SIP信令向其服務(wù)器傳輸視頻請求，服務(wù)器根據(jù)對應(yīng)的請求向相關(guān)設(shè)備發(fā)送該條請求信息，同時在流媒體服務(wù)器中進行設(shè)備、iOS設(shè)備與媒體服務(wù)器的會話，iOS設(shè)備端在RTP協(xié)議作用下，接收到流媒體服務(wù)器傳輸過來的音視頻流，其流程如下圖2所示。

設(shè)備接收端根據(jù)RPT協(xié)議中的載荷類型字段值來進行視頻數(shù)據(jù)與音頻數(shù)據(jù)的區(qū)分。音頻數(shù)據(jù)的編碼主要通過G.711實現(xiàn)，先通過G.711將音視頻數(shù)據(jù)解碼，然后轉(zhuǎn)化為PCM格式，其后通過iOS系統(tǒng)內(nèi)部的OpenAL.framework框架來播放。視頻數(shù)據(jù)的編碼則通過H.264實現(xiàn)，H.264中包含的NAL單元在依托RTP進行傳輸時，因為受IP網(wǎng)絡(luò)最大傳輸單元限制，需分片處理，因此在音視頻解碼前應(yīng)將已經(jīng)分片的NAL單元進行重組，使之成為完整化NAL單元，對NAL單元進行重組，其流程如下圖3所示。

FFmpeg是一項免費的音視頻流方案，其包括多項庫文件，最常用的包括以下四種：libswscale、libavutil、libavformat與libavcodec。應(yīng)用蘋果終端能夠?qū)崿F(xiàn)FFmpeg的編譯，并將其合理應(yīng)用于iOS系統(tǒng)。在應(yīng)用FFmpeg解碼H.264時，首先需要將解碼器初始化，并實現(xiàn)圖像轉(zhuǎn)換格式的轉(zhuǎn)化，其后將已經(jīng)完成組幀的H.264進行解碼，最后將解碼完成的YHV420P圖像轉(zhuǎn)化為能夠在iOS系統(tǒng)設(shè)備上能夠顯示的UIIm-agg圖像。最后通過iPhone收集進行軟件的測試，再進行相應(yīng)的完善即可[4]。

結(jié)語：綜述，依據(jù)iOS系統(tǒng)優(yōu)越性能與FFmpeg的音頻解碼性能能夠為音視頻監(jiān)控軟件的設(shè)計提供全方位的支撐，從而有效保障以iOS為基礎(chǔ)的音視頻監(jiān)控軟件的完善化設(shè)計，滿足用戶對其的相關(guān)要求。

參? 考? 文? 獻

[1]段學東，何九周.基于敏捷思想的iOS平臺軟件的設(shè)計與實現(xiàn)[J].計算機技術(shù)與發(fā)展，2018，22（9）：53-58.

[2]孟利民，黃成君.網(wǎng)絡(luò)監(jiān)控系統(tǒng)中多媒體同步控制研究與實現(xiàn)[J].電聲技術(shù)，2017，37（1）：85-88.

[3]李校林，劉利權(quán)，張杰.基于RTP的H.264視頻流實時打包傳輸?shù)难芯縖J].計算機工程與科學，2017，24（5）：168-171.

[4]何圓圓，何凱.基于FFmpeg的H.264視頻解碼器的研究與實現(xiàn)[J].電腦知識與技術(shù)，2018，35（8）：8519-8521.