門禁對講系統中音視頻起重要作用 目前，現在的許多小區家家戶戶都安裝有門禁對講系統，那么音視頻同步問題是門禁可視對講中的重點需要解決的問題之一，因此可以看出音視頻同步問題關系到門禁對講的使用情況。

    一、引言
    目前，成熟的智能家居系統的室外機、門禁可視對講和門禁控制幾乎全部采用模擬信號，安裝時需要架設專用網絡，布線復雜，不可擴展，靈活性差，傳輸距離短，投資大，維護成本高。隨著市場需求的增長、消費者消費觀念的提高以及模擬系統沉重的工程維護代價，結合以太網技術的全數字室外機和門禁產品成為研發的熱點。但是在諸多因素影響下，當前的數字門禁產品不成熟、不穩定、價格高昂，特別是門禁對講中的音視頻同步問題，一直以來都是數字可視對講的短板。

    二、音視頻同步問題概述
    音視頻同步問題是可視對講中的重點需要解決的問題之一，也是一直以來被模擬門禁產品廠商攻擊的一個弱點，因為模擬可視對講產品都采用專線傳輸，不存在這個問題。解決同步問題的方法有很多種，其中時間戳是最成熟最完美也是最復雜的解決辦法，可以解決任何多媒體領域的音視頻同步問題；其原理是選擇一個參考時間，在生成數據流時依據參考時間上的時間給每個數據塊都打上時間戳；在播放時，讀取數據塊上的時間戳，同時參考當前時鐘上的時間來安排播放，讓快于這個參考時間的包等待，丟棄慢于這個參考時間的包。在基于時間戳的同步機制中，僅僅對不同步的數據進行處理是不完備的，還需要反饋機制，如基于Windows平臺的DirectShow就提供這樣一個反饋機制，它的質量控制（QualityControl）可以將播放的狀態反饋給源，讓源端加快或者放慢數據流的速度。
    在多媒體文件采集，播放及對同步的要求都非常嚴格，如果從多媒體文件中分離出音視頻數據的數據不同步，音視頻的時間差則會越來越大，這是無法忍受的，所以在多媒體文件中，不但要求有同步機制，還要求有反饋機制。

    三、數字可視對講中的音視頻同步方案
    在數字可視對講中，可以考慮的音視頻同步方案有兩種：一是發送端解決；二是接收端解決。
    發送端解決方法比較簡單，具體措施是在發送端先將一段時間內采集到音視頻數據打包。比如采集到一幀視頻圖像，將這幀圖像與采集這幀視頻的時間內采集到的視頻數據打成一個包，接收端接收到這個包之后解包分別播放就可以了。發送端解決的控制方法比較簡單，但是在高清要求清晰度比較高的情況下就不是很理想，清晰度高，意味著每個音視頻包數據量就大，能保證同步，卻難以保證連續。我們在同一個線程中按照先后順序發送PCM音頻和H.264視頻，測試結果表明這種方法確實存在連續問題。
    接收端解決方案繞不開的問題是時間戳，接收端根據接收到的音視頻數據的時間戳安排播放。時間戳需要一個參考時間，而采集過程中視頻的時間是不定的，數字攝像頭采集圖像的幀率是一個平均值，不宜用來做參考時間，所以只能用音頻時間作為參考時間。

    四、聲卡編程和聲卡驅動的時間機制
    門禁可視對講中音頻是雙向的。門禁可視對講方案中，音頻的采用PCM（PulseCodeModulation——脈碼調制錄音）采集，在網絡中傳送的也是原始數據，之所以沒有對音頻數據進行編碼處理是基于以下原因：一是S3C6410沒有提供對音頻的硬編解碼，如果使用軟件實現編解碼，在有限的系統資源條件下難以實現；二是音頻數據量較小：采用8000采樣率和量化位數為8位的電話語音標準，一秒的音頻數據是8K字節，只相當于視頻1幀數據的兩倍，這對普遍擁有百兆網卡的局域網來說，數據量很小。實驗的結果表明，這種簡單的處理方式被證明是有效的。
    Linux操作系統下音頻接口有/dev/dsp,/dev/audio,/dev/Mixer三種。前兩種的屬性基本相同，DSP是數字信號處理器（DigitalSignalProcessor）的簡稱，是用于數字采樣（sampling）和數字錄音（recording）的設備文件，它對于Linux下的音頻編程來講非常重要。向該設備寫數據即意味著激活聲卡上的D/A轉換器進行放音，而向該設備讀數據則意味著激活聲卡上的A/D轉換器進行錄音。目前許多聲卡都提供有多個數字采樣設備。/dev/audio屬性與dsp類似，但更多的用于sun的工作站中，為兼容性考慮，應用中一般使用/dev/dsp作為音頻接口。mixer為混音器，也是聲卡設備中相當重要的一部分，它的作用是將多個信號組合或者疊加到一起，但對應用程序來說，這些都無需考慮，但可以通過這個接口調節聲卡播放時聲音的大小等參數。

    五、基于音頻時間機制的音視頻同步解決方案
    與文件形式的多媒體不同的是，可視對講中音視頻流的源端是永遠同步的。所以一種簡單的解決方案是發送端啟用獨立的音頻和視頻線程，進行音視頻采集，采集后只管往外發送數據，接收端接到數據就分別解碼播放，從表面看，這種采用無同步機制多線程解決方案是可行的，但是忽略了一個問題，即音頻數據包和視頻數據包的大小。包的大小會影響網絡傳輸的速度。這種差別在網絡條件好的情況下顯示不出來，一旦遇到網絡擁塞或者其他情況就會變得很明顯。
    根據對音頻采集和處理的敘述，我們知道，音頻的采集是有時間機制的。比如采樣率是8000，采樣位數是8，我們就可以算出采8K字節的數據所用的時間是1s，這樣音頻就可以按照自己的速度播放；而攝像頭每秒采集的幀數是相對固定的。
    接收端接收到音頻數據，直接交給聲卡播放，當前播放的音頻包的時間戳時間傳送給視頻線程；接收到視頻幀，則將其時間戳時間與當前播放的音頻時間戳進行比較，若未達到參考時間，則解碼播放；若達到參考時間，則說明該視頻幀滯后，丟棄該視頻幀，接收下一個視頻幀，循環往復，直到線程接收到結束命令停止；以上述音頻采樣率和采樣位數為例，視頻參考時間的計算方法為（以C語言格式的？號表達式表示）：
    音頻時間戳時間+1/30>視頻時間戳時間，丟棄：播放；
    在編程實現時，采集端和播放端的音頻和視頻可采用獨立的線程，并利用Qt的信號槽機制實現音視頻線程時間戳的傳遞。

    六、方案測試
    以上結果表明，這種音視頻同步解決方案可以實現數字門禁可視對講的音視頻同