何 偉
(中央廣播電視總臺,北京 100040)
在媒體融合時代,只有不斷提升廣播節目質量才能迎合受眾需求、突出媒體競爭優勢,為此需要對廣播節目進行實時監測。監測對象除了節目內容外,還要重點關注音頻質量、節目狀態(有無誤播、停播等)。在這一背景下,將大數據、人工智能等技術應用到廣播節目的監測中,構建智能廣播質量監測系統,保證廣播臺對異地頻率落地節目覆蓋情況、租機運行情況、節目播出情況的動態掌握。從該系統的應用需求來說,調頻廣播信號采集、音頻編碼傳輸、音頻質量評價等均為系統主要功能,這也成為智能廣播質量監測系統設計中需要關注的重點。
本文設計的智能廣播質量監測系統應滿足以下功能:(1) 可基于嵌入式設備,完成對調頻廣播信號的接收編碼,同時還能實時、準確地采集特定頻率的廣播信號;(2) 可通過多條路徑接收音頻,并在實時編碼后經過Internet 將音頻數據傳輸至處理中心;(3)每隔一段時間進行一次傳輸音頻數據的丟包檢測,并在檢測到有丟包現象后立即啟動重傳功能。對于正常接收到的音頻數據,能夠作出音頻質量客觀評價;(4)經過處理后的數據分目錄保存到數據庫中;(5) 在出現插播、停播等特殊情況后能夠進行告警。
本文設計的智能廣播質量監測系統主要由兩部分組成,即遠程廣播音頻采集子系統、數據處理子系統。
遠程廣播音頻采集子系統是由分布在不同地區的廣播音頻采集設備組成,其作用是實現對廣播音頻數據的采集,然后利用網絡將采集到的數據傳遞給數據處理子系統。數據處理子系統位于廣播電臺的機房中,其作用是分析處理前端傳輸的音頻數據。數據處理子系統又包括幾個核心軟件,如Web 服務軟件、數據接收分發軟件、數據存儲軟件等[1]。整個系統的整體框架見圖1。

圖1 系統整體框架
結合上文介紹的系統整體架構,可以發現系統數據處理部分主要包括數據接收分發、音頻質量評價、數據集存儲等幾部分,本文選擇上述幾個模塊重點概述其設計內容與實現方式。本文所述的智能廣播質量監測系統是基于Visual Studio 2017 開發環境,使用C++開發語言,各模塊之間遵循TCP 協議完成數據的傳輸和指令的傳達。
2.1.1 音頻數據處理模塊
該模塊主要包含了音頻數據的接收、丟包分析、重傳和分發4 部分。為保證音頻數據的處理效率,使用了多線程技術;同時考慮到該系統運行中可能會存在網絡不良或信號干擾,因此還設計了網絡數據的重傳機制。如果系統檢測到有數據丟包,則發起重傳的請求。各線程接口及其對應的功能如下:
線程1:ThreadRecvData,數據接收功能;
線程2:ThreadHandleData,接收并處理數據;
線程3:ThreadRequery,發送數據重傳請求;
線程4:ThreadRecvReq,接收重傳數據;
線程5:ThreadDataDistribute,分發數據。
這里以音頻數據的接收處理為例,介紹其功能實現方式:系統正常接收音頻數據后,執行一個初始化程序,然后將音頻數據作解析處理。根據解析結果的類型,按照順序將其存入對應的數據鏈表中。然后調用ProcessData 函數,處理鏈表中的數據,根據處理結果執行一個判斷程序“是否有丟包現象?”如果判斷結果為“否”,則直接跳轉到“數據分發”程序,將數據分發至相應的軟件;如果判斷結果為“是”,則有系統生成并發送一個調整碼率的指令。然后再執行一個判斷程序“丟包是否超出門限?”如果判斷結果為“是”,則跳轉至“數據分發”程序,將數據分發至相應的軟件;如果判斷結果為“否”,則建立用于重傳的數據處理線程ThreadRecvReq。如果重傳正常結束,則進入“數據分發”程序,如果重傳超時,則再次發起重傳,直到重傳正常結束。
2.1.2 命令數據處理模塊
由于系統運行中經常會出現多個命令同時發送的情況,因此為了提高命令傳輸效率,在該模塊的設計中也采取了多線程方式,為每一臺遠程廣播接收設備提供了一條獨立的命令接收線程[2]。根據命令內容或功能的不同,常用的線程有3 種,分別是:
線程1:ThreadListenCmd,設備命令監聽線程;
線程2:ThreadRecvCmd,設備命令接收線程;
線程3:ThreadRevWebServerCmd,Web 服務器命令接收線程。
命令傳輸功能基于Windows Socket 編程實現,執行TCP 協議,命令處理模塊的實現方式為:首先利用線程1 和線程3,在監聽Web 服務器和被監聽設備之間建立聯系,并發送請求。請求通過后,Web 服務器調用命令數據處理函數AnalyWebServerCmd(),生成相應的命令數據。然后使用AES 加密算法,對命令數據進行加密,將其發送至遠程接收設備。設備接收到該命令數據后,先解密,然后根據命令內容作出相應的設置,包括更改設備時間、更改設備頻率、上傳/下載節目表等。整個流程見圖2。

圖2 命令數據處理流程
2.1.3 數據加解密模塊
為提高音頻數據在傳輸過程中的安全性,該系統對所有需要傳輸的數據均采用AES 加密算法進行處理。密鑰長度達到了256 位,共進行9 次加密,保證了音頻數據的隱私安全。在具體的加密方式上,選擇AES 加密算法中的EBC(電子密碼本)模式,其原理是將需要加密的數據劃分為數段,每段的長度與加密秘鑰的長度保持一致,并且每一段均采取相同的密鑰加密,這樣既可以簡化加密操作難度,同時還有利于計算機并行計算,提高了音頻數據的處理效率[3]。
完成數據加密后,借助于Internet 進行音頻數據的傳輸,在數據處理系統接收數據后,還要執行一個解密步驟,從而利用音頻數據完成對廣播質量的實時監測。在數據解密中,需要調用解密函數InvCipher(),在該函數中需要進行多輪解密,每一輪均需要使用不同的子函數,例如初始輪解密調用AddRoundKey()函數,最終輪解密調用InvSubBytes()函數等。數據加密、解密的具體流程見圖3。

圖3 Aes 加密、解密流程
2.2.1 音頻數據準備模塊
該模塊的主要功能是提供用于質量評價的音頻數據,具體又涵蓋了音頻數據的接收、解碼、讀取等。在該模塊的設計中,使用到的關鍵技術有Socket 數據接收技術、ffmpeg 解碼技術、CMarkup 類解析技術等。首先通過Socket 接收音頻數據,并將數據以.wma 格式進行存儲。對于.wma 格式的音頻數據,應用ffmpeg 解碼技術進行解碼;對于.xml 格式的節目表,則使用CMarkup 類解析。考慮到各類數據的總量較大,為了提高處理效率,在音頻數據準備模塊的設計中采用了雙緩存結構。考慮到節目表可能會存在分時段停播的情況,因此在讀取文件時,如果當前節目段播放完畢,則進行一遍節目表信息輪詢,根據輪詢結果判斷下一個節目時段是否連續。如果判斷為“是”,則直接將下一個節目的相關文件讀入緩存;如果判斷為“否”,則結束程序。
2.2.2 音頻數據預處理模塊
該模塊的主要功能是靜音段判斷、時間對齊、同源判斷、聲壓級歸一化處理等。在完成上述處理后,可以對該段音頻數據的質量作出相應的評價。在本系統的音頻數據預處理模塊設計中,通過設定頻域、時域相關性門限,并對門限值進行判定,以此來確定音頻數據是否滿足同源條件[4]。在實際操作中,通常是先給定一個門限最低值,如果時域、頻域相關性低于門限最低值,則說明兩者不相關,即為非同源數據;反之,相關性高于門限最低值,則判斷為相關,同時提高門限,再次進行判斷。重復上述步驟,可以判斷同源度。同源度越高,則音頻質量越高。音頻數據頻域——時域的匹配搜索流程見圖4。

圖4 音頻頻域——時域匹配搜索流程
2.2.3 音頻質量客觀評價模塊
音頻質量評價是在參數預計算、激勵樣本處理、MOV 值計算等一系列工作的基礎上得到的最終結果[5]。每個處理步驟均有獨立的函數進行支持,例如參數預計算可調用CpeaqMain () 函數、MOV 值計算可調用CMovBlock()函數。這樣就能顯著增強不同處理程序之間的耦合性,從而讓代碼執行效率、音頻質量評價結果精度都得到相應的提升。這里以MOV 值計算為例,其函數執行過程如下:
(1) 計算調制差異mobModDiff();
(2) 計算局部噪聲響度mobNoiseLoud();
(3) 計算噪掩比mobNMR();
(4) 計算檢測概率和聲道超過門限的所需部署mobDetProb();
(5) 計算相對干擾mobRDF();
(6) 計算誤差諧波結構mobEHS()。
將計算得到的評分結果帶入表1,利用客觀評價分數與音頻質量的對應關系,即可得到音頻質量客觀評價結果。

表1 音頻質量客觀評價描述
該模塊可以將接收到的音頻數據存儲到本地服務器,同時自動進行數據備份,防止音頻數據丟失。音頻數據接收也需要使用到Scoket 技術,順利接收后將其以.wma 格式存儲。按照音頻數據的幀信息、設備信息,將其分類存儲到對應的文件中;如果存在數據幀丟失,則記錄丟失數據幀信息。存儲服務器方面,可配置多個SATA 硬盤,其中一部分用于存儲,另一部分用于備份。存儲音頻數據時,首先要調用InitClinent()函數,完成存儲系統的初始化。然后解析接收到的數據,并將解析后的數據存入到相應的鏈表中。然后再調用WriteData()函數,結合接收數據的設備信息,創建目錄,目錄格式為xx.mm.dd(如2022.08.27)。
廣播電視媒體引進智能廣播質量監測系統是順應融媒體時代發展趨勢的一種必然選擇,該系統的應用將會實現從廣播節目的播出、監測、反饋、調整再到優化的閉環管理,對提高節目播出質量、改善用戶的節目收聽體驗有積極幫助。本文設計的智能廣播質量監測系統,除了支持遠程音頻數據采集、音頻數據實時傳輸等功能外,還能通過智能算法實現對廣播音頻質量的客觀評價,根據評價結果為下一步的節目調整與優化提供了參考,在實現廣播智能化方面發揮了重要作用。