音頻流媒體數(shù)據(jù)監(jiān)控平臺(tái)建設(shè)

范曉梅

摘要：本文討論了一種音頻流媒體數(shù)據(jù)監(jiān)控平臺(tái)的實(shí)現(xiàn)方案，提出包括數(shù)據(jù)解析與解碼、音頻數(shù)據(jù)分析和報(bào)警處理等三大流程環(huán)節(jié)的解決辦法。

Abstract： This paper discusses the implementation scheme of an audio streaming media data monitoring platform， and puts forward solutions of three major process links including data analysis and decoding， audio data analysis and alarm processing.

關(guān)鍵詞：音頻流媒體；HLS；RTMP；數(shù)據(jù)監(jiān)控

Key words： audio streaming media；HLS；RTMP；data monitoring

中圖分類號(hào)：TP277 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1006-4311（2017）35-0212-02

0 引言

包頭廣播電視總臺(tái)下屬新聞綜合、交通、蒙語、汽車音樂、文藝等5個(gè)廣播頻率，擁有《包頭新聞》、《新聞天天聽》，《你好，Driver》、《歡樂聯(lián)通2+1》、《天天美食》、《老橡樹音樂之旅》等一批品牌欄目。在“精品立臺(tái)、人才興臺(tái)、經(jīng)營(yíng)富臺(tái)、創(chuàng)新強(qiáng)臺(tái)”的戰(zhàn)略思想指導(dǎo)下，朝著功能多元化、裝備數(shù)字化、經(jīng)營(yíng)集約化、管理精細(xì)化、隊(duì)伍精兵化的目標(biāo)邁進(jìn)。技術(shù)上，包頭電臺(tái)嘗試進(jìn)行互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)技術(shù)與廣播技術(shù)的深度融合，踐行媒體融合的探索，發(fā)展互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)廣播等網(wǎng)絡(luò)新媒體。

網(wǎng)絡(luò)新媒體的音頻品質(zhì)直接影響用戶體驗(yàn)。由于網(wǎng)絡(luò)傳輸鏈路具有一定的復(fù)雜性，網(wǎng)絡(luò)音頻流的品質(zhì)問題繁雜，例如節(jié)目聲音的忽大忽小、爆音、網(wǎng)絡(luò)流斷線等，造成用戶體驗(yàn)較差。在當(dāng)今信息大爆炸的背景下，即便再優(yōu)秀的節(jié)目，如果用戶體驗(yàn)差，也不會(huì)吸引用戶。按照全臺(tái)網(wǎng)白皮書2.0要求，結(jié)合運(yùn)營(yíng)實(shí)際，建設(shè)一套音頻流媒體數(shù)據(jù)監(jiān)控平臺(tái)勢(shì)在必行。

1 系統(tǒng)分析

音頻流媒體傳輸系統(tǒng)結(jié)構(gòu)如圖1所示。系統(tǒng)的輸入信號(hào)包括無線廣播音頻信號(hào)和互聯(lián)網(wǎng)廣播信號(hào)組成，經(jīng)過編碼器進(jìn)行編碼，采用RTMP協(xié)議，將數(shù)據(jù)流推送至Wowza流媒體服務(wù)器上。由于IOS操作系統(tǒng)的移動(dòng)客戶端（iPhone、iPad等設(shè)備）和Android操作系統(tǒng)的移動(dòng)客戶端分別支持HLS和RTMP協(xié)議，因此，流媒體服務(wù)器需要將數(shù)據(jù)信號(hào)進(jìn)行解包和組包，封裝為HLS和RTMP兩種格式網(wǎng)絡(luò)數(shù)據(jù)流，發(fā)布在互聯(lián)網(wǎng)上。

2 系統(tǒng)實(shí)現(xiàn)

音頻流媒體數(shù)據(jù)監(jiān)控平臺(tái)包括解析與解碼處理系統(tǒng)、音頻數(shù)據(jù)分析系統(tǒng)、報(bào)警處理系統(tǒng)三大部分，如圖2所示。其監(jiān)控的數(shù)據(jù)源由上圖中監(jiān)測(cè)面A的傳統(tǒng)節(jié)目信號(hào)數(shù)據(jù)流、監(jiān)測(cè)面B的HLS節(jié)目數(shù)據(jù)流和RTMP節(jié)目數(shù)據(jù)流組成，實(shí)現(xiàn)了節(jié)目?jī)?nèi)容從數(shù)據(jù)編碼、發(fā)布接收整個(gè)過程監(jiān)控。

解析與解碼系統(tǒng)的HLS/RTMP協(xié)議解析器，輸入監(jiān)控?cái)?shù)據(jù)流，輸出壓縮的音頻數(shù)據(jù)幀。通過內(nèi)存交換和解碼器，輸出線性的音頻數(shù)據(jù)，作為音頻數(shù)據(jù)分析系統(tǒng)的輸入信號(hào)。

HLS協(xié)議封裝的數(shù)據(jù)包括一個(gè)m3u（8）索引文件和對(duì)應(yīng)的多個(gè)媒體片文件。系統(tǒng)通過索引文件找到相應(yīng)的媒體片文件，利用HTTP網(wǎng)絡(luò)協(xié)議逐一取得每幀的流數(shù)據(jù)。 RTMP協(xié)議是基于TCP協(xié)議進(jìn)行封裝的上層協(xié)議，采用默認(rèn)端口1935，服務(wù)器和客戶之間首先通過1536字節(jié)的數(shù)據(jù)包進(jìn)行握手后，然后發(fā)送內(nèi)容數(shù)據(jù)，內(nèi)容數(shù)據(jù)包括固定長(zhǎng)度的包頭和一個(gè)最長(zhǎng)為128字節(jié)的包體組成，解析內(nèi)容數(shù)據(jù)包，逐一取得每幀的流數(shù)據(jù)。

解碼模塊基于FFMPEG解碼平臺(tái)提供的API進(jìn)行開發(fā)，首先注冊(cè)所有音視頻壓縮格式，為解碼分配內(nèi)存空間，從HLS/RTMP解析器中獲得壓縮數(shù)據(jù)幀，并判斷數(shù)據(jù)格式類型，調(diào)用相應(yīng)的解碼器，輸出線性的PCM數(shù)據(jù)幀。

多套節(jié)目數(shù)據(jù)的解析和解碼過程，系統(tǒng)在讀取數(shù)據(jù)時(shí)，由于網(wǎng)絡(luò)環(huán)境、服務(wù)器性能波動(dòng)等因素，會(huì)不定時(shí)出現(xiàn)阻塞狀態(tài)，因此，多套節(jié)目數(shù)據(jù)流如果放在一個(gè)主線程中處理，將影響檢測(cè)數(shù)據(jù)的真實(shí)性。解析和解碼系統(tǒng)采用多線程編程，防止數(shù)據(jù)流之間的相互影響。

在音頻數(shù)據(jù)分析系統(tǒng)中，設(shè)定檢測(cè)信號(hào)的報(bào)警閾值和持續(xù)時(shí)間（設(shè)置為10秒），并記錄故障開始時(shí)間和故障恢復(fù)時(shí)間，并將報(bào)警信息輸出到報(bào)警處理系統(tǒng)進(jìn)行處理。其中電平檢測(cè)主要監(jiān)控節(jié)目的音量的大小范圍，報(bào)警閾值包括最低電平（-40db）、最高電平（-3db）。相位檢測(cè)主要是監(jiān)控左右聲道的相關(guān)系數(shù)，并進(jìn)行歸一化處理，報(bào)警閾值設(shè)置為-1～-0.6和1～0.6，當(dāng)相關(guān)系數(shù)落在報(bào)警閾值范圍內(nèi)，且持續(xù)一定時(shí)間后，就自動(dòng)生成報(bào)警信息。斷線檢測(cè)主要是監(jiān)控網(wǎng)絡(luò)數(shù)據(jù)流的網(wǎng)絡(luò)延時(shí)和超時(shí)時(shí)間。系統(tǒng)參數(shù)的設(shè)置需要根據(jù)電臺(tái)的網(wǎng)絡(luò)環(huán)境，服務(wù)器存儲(chǔ)、CPU等資源有關(guān)。如果閾值參數(shù)設(shè)置太嚴(yán)格，數(shù)據(jù)流稍微有一點(diǎn)偏差，系統(tǒng)就會(huì)報(bào)警，導(dǎo)致管理人員疲于應(yīng)付，但閾值參數(shù)設(shè)置太寬松，就達(dá)不到自動(dòng)監(jiān)控的目的，因此在設(shè)置時(shí)，需要多次試驗(yàn)，反復(fù)修改，達(dá)到理想的閾值參數(shù)。

報(bào)警處理系統(tǒng)中，報(bào)警信息根據(jù)不同的緊急程度，對(duì)應(yīng)不同級(jí)別的管理人員。例如：斷線報(bào)警信息定義為最重要級(jí)別、電平過低等定義為中等級(jí)別、相位反相定義為最低級(jí)別。報(bào)警管理人員分為技術(shù)管理人員、節(jié)目管理人員等兩大類，技術(shù)管理人員主要負(fù)責(zé)網(wǎng)絡(luò)傳輸?shù)燃夹g(shù)基礎(chǔ)通路的維護(hù)，節(jié)目管理人員負(fù)責(zé)節(jié)目電平、相位等節(jié)目?jī)?nèi)容質(zhì)量監(jiān)控。系統(tǒng)根據(jù)系統(tǒng)設(shè)置報(bào)警管理人員的聯(lián)系電話、郵箱等基本信息，通過短信、電話和郵件，將報(bào)警信息發(fā)送到不同的管理者。當(dāng)故障長(zhǎng)時(shí)間未得到解決時(shí)，可以定義重復(fù)發(fā)送報(bào)警信息的頻率。

短信模塊通過短信平臺(tái)的服務(wù)接口的API函數(shù)，將報(bào)警信息通過短信平臺(tái)發(fā)送給相應(yīng)的管理者。短信平臺(tái)可以自行建設(shè)，也可以租用電信服務(wù)商的短息平臺(tái)。郵件處理模塊主要負(fù)責(zé)將報(bào)警信息發(fā)送給有關(guān)的管理者，系統(tǒng)按照SMTP協(xié)議要求，封裝的類庫SmtpClient，對(duì)外提供郵件發(fā)送接口API，其中發(fā)件人的郵箱地址、郵箱密碼和管理者的郵箱地址，設(shè)置在系統(tǒng)數(shù)據(jù)庫中。

3 結(jié)束語

綜上所述，音頻流媒體數(shù)據(jù)監(jiān)控平臺(tái)不但要涉及到HLS/RTMP協(xié)議的解析、音頻數(shù)據(jù)的解碼、節(jié)目電平和左右聲道相關(guān)系數(shù)計(jì)算、短信平臺(tái)接口和SMTP郵箱控制等各個(gè)流程環(huán)節(jié)，而且還需要考慮電臺(tái)網(wǎng)絡(luò)環(huán)境、服務(wù)器存儲(chǔ)、CPU等設(shè)備的性能，進(jìn)行最佳的監(jiān)控參數(shù)調(diào)整，是一個(gè)復(fù)雜的工程。

結(jié)合全臺(tái)網(wǎng)白皮書2.0，下一步可在此基礎(chǔ)上進(jìn)行播控網(wǎng)、核心生產(chǎn)網(wǎng)、綜合業(yè)務(wù)網(wǎng)、融媒內(nèi)容平臺(tái)在內(nèi)的全域數(shù)據(jù)監(jiān)控平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)。

參考文獻(xiàn)：

[1]國(guó)家廣播電影電視總局科技司，廣播電臺(tái)融合媒體平臺(tái)建設(shè)技術(shù)白皮書[EB/OL].http：//www.sarft.gov.cn/art/2016/3/29/art_36_30400.html 2016-02-05.

[2]李煜等譯.多媒體數(shù)字壓縮原理與標(biāo)準(zhǔn).[M]北京：電子工業(yè)出版社，2000：296.

[3]潘志庚譯.多媒體技術(shù)：計(jì)算、通信與應(yīng)用[M].北京：清華大學(xué)出版社，2000：480.endprint