廣播電臺(tái)推流技術(shù)及網(wǎng)絡(luò)直播應(yīng)用探討

鄧貴川

（重慶市武隆區(qū)融媒體中心，重慶 408500）

0 引 言

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展進(jìn)步，互聯(lián)網(wǎng)視頻直播受到了更多的關(guān)注，為積極推進(jìn)廣播電臺(tái)發(fā)展轉(zhuǎn)型進(jìn)程，要積極整合流媒體應(yīng)用模式，利用實(shí)時(shí)性直播的方式為廣播電臺(tái)提高市場(chǎng)核心競(jìng)爭(zhēng)力提供保障。

1 流媒體概述

對(duì)于廣播電臺(tái)發(fā)展轉(zhuǎn)型工作而言，要想實(shí)現(xiàn)多元化發(fā)展，就要積極推進(jìn)廣播電臺(tái)視頻化發(fā)展進(jìn)程，從產(chǎn)生視頻化需求的角度出發(fā)，實(shí)現(xiàn)網(wǎng)絡(luò)和電視融合后的視頻直播，配合媒體技術(shù)處理方案更好地實(shí)現(xiàn)完全意義上的廣播視頻化，借助網(wǎng)絡(luò)PC 端、移動(dòng)端等應(yīng)用模式更好地滿足可視化管理應(yīng)用需求。

1.1 內(nèi) 涵

流媒體也被稱為流式媒體，指商家利用視頻傳送服務(wù)器將節(jié)目當(dāng)成數(shù)據(jù)包予以發(fā)送，直接傳輸?shù)綄?duì)應(yīng)網(wǎng)絡(luò)體系中，用戶在借助解壓設(shè)備進(jìn)行數(shù)據(jù)解壓后，節(jié)目就能像發(fā)送時(shí)的狀態(tài)一樣予以呈現(xiàn)。在流媒體應(yīng)用后，人們?cè)诰W(wǎng)上聊天就能直接采取語(yǔ)音輸入的方式，配置攝像頭就能完成視頻交流。在流媒體傳輸信息的過(guò)程中，基于A/V 和3D 等多媒體文件，借助特殊壓縮方式完成壓縮包的處理，配合視頻服務(wù)器實(shí)現(xiàn)實(shí)時(shí)性、連續(xù)性數(shù)據(jù)傳送處理[1]。

1.2 方 式

順序流式傳輸指按照順序完成下載，在下載文件的同時(shí)用戶就能利用在線媒體完成觀看，并且在固定時(shí)間內(nèi)用戶能完成已經(jīng)下載部分的觀看。順序流式傳輸處理環(huán)節(jié)中，能結(jié)合用戶連接的速度完成調(diào)整工作。順序流式文件是基于標(biāo)準(zhǔn)超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）服務(wù)器完成處理，整體管理效果較好，且其實(shí)際應(yīng)用質(zhì)量和播放效果與防火墻無(wú)關(guān)[2]。

實(shí)時(shí)流式傳輸主要包括實(shí)時(shí)流式傳輸特定服務(wù)器和特殊網(wǎng)絡(luò)協(xié)議，按照相應(yīng)的實(shí)時(shí)性協(xié)議，配合服務(wù)器應(yīng)用要求，就能更好地滿足數(shù)據(jù)信息的匯總處理。

2 廣播電臺(tái)推流技術(shù)內(nèi)容及實(shí)現(xiàn)過(guò)程

基于廣播電臺(tái)轉(zhuǎn)型發(fā)展要求，在廣播電臺(tái)推流技術(shù)應(yīng)用控制的環(huán)節(jié)中，要按照技術(shù)要求和規(guī)范落實(shí)具體工作環(huán)節(jié)，維持相應(yīng)處理控制環(huán)節(jié)的科學(xué)性，更好地配合程序應(yīng)用要求，符合廣播電臺(tái)檢索以及服務(wù)的具體標(biāo)準(zhǔn)。

2.1 廣播電臺(tái)推流技術(shù)內(nèi)容

（1）智能流技術(shù)能完成自動(dòng)檢測(cè)網(wǎng)絡(luò)狀態(tài)等工作，將音頻視頻屬性調(diào)整到最佳狀態(tài)后，確保用戶收到的是和網(wǎng)絡(luò)速度相匹配的媒體流，更好地服務(wù)用戶獲取用戶體驗(yàn)[3]。

（2）分流技術(shù)，發(fā)送端服務(wù)器將媒體流直接分布在多個(gè)接收服務(wù)器中，客戶端能建立就近訪問(wèn)的處理模式，獲取高質(zhì)量媒體流，并且減少帶寬的使用率。在推流的過(guò)程中，將直播內(nèi)容直接推送到廣播電視臺(tái)對(duì)應(yīng)服務(wù)器（如圖1 所示）。廣播電視臺(tái)推流處理環(huán)節(jié)中，支持?jǐn)?shù)據(jù)包的緩存處理，配合內(nèi)容分發(fā)網(wǎng)絡(luò)技術(shù)就能更好地實(shí)現(xiàn)用戶請(qǐng)求的合理性發(fā)布，提高有效的響應(yīng)速度并減少骨干網(wǎng)絡(luò)壓力。

圖1 視頻傳輸播放過(guò)程

（3）流媒體技術(shù)還包括內(nèi)容分發(fā)網(wǎng)絡(luò)技術(shù)，構(gòu)架在IP 網(wǎng)絡(luò)上建立內(nèi)容疊加網(wǎng)，利用主動(dòng)內(nèi)容管理、全局負(fù)載平衡以及內(nèi)容緩存處理等環(huán)節(jié)，將用戶請(qǐng)求的流媒體內(nèi)容直接發(fā)布到距離用戶較近的網(wǎng)絡(luò)邊緣，在體用響應(yīng)速度的同時(shí)，更好地降低骨干網(wǎng)絡(luò)的運(yùn)行壓力，維持可控化應(yīng)用效能，保證網(wǎng)絡(luò)控制協(xié)議基礎(chǔ)上數(shù)據(jù)傳輸?shù)目煽匦訹4]。

2.2 廣播電臺(tái)推流技術(shù)實(shí)現(xiàn)過(guò)程

在廣播電臺(tái)推流技術(shù)應(yīng)用處理控制環(huán)節(jié)中，配合流媒體應(yīng)用管理標(biāo)準(zhǔn)，打造完整的應(yīng)用體系，滿足技術(shù)實(shí)現(xiàn)的具體要求，實(shí)現(xiàn)多元數(shù)據(jù)并行管理的目標(biāo)。

2.2.1 直播中的流媒體協(xié)議

第一，實(shí)時(shí)消息傳送協(xié)議（Real-Time Messaging Protocol，RTMP）。RTMP 是實(shí)時(shí)性消息傳輸協(xié)議，協(xié)議在應(yīng)用過(guò)程中基于傳輸控制協(xié)議 （Transmission Control Protocol，TCP）完成相應(yīng)的數(shù)據(jù)處理，本質(zhì)上是設(shè)計(jì)用來(lái)完成實(shí)時(shí)性數(shù)據(jù)通信傳輸?shù)木W(wǎng)絡(luò)協(xié)議，應(yīng)用在Flash/Air 平臺(tái)等，能支持RTMP 協(xié)議流媒體以及交互服務(wù)器應(yīng)用要求的落實(shí)，建構(gòu)完整的音頻、視頻以及數(shù)據(jù)通信體系[5]。另外，協(xié)議還支持操作消息格式（Action Message Format，AMF）數(shù)據(jù)的管理和控制，完成FLV（Flash Video）視頻以及音頻數(shù)據(jù)的協(xié)同管理，利用多元連接模式保證多路網(wǎng)絡(luò)流工作順利展開(kāi)，按照固定大小的包實(shí)現(xiàn)可控化傳輸管理目標(biāo)。

第二， 基于HTTP 的流媒體協(xié)議（HTTP Live Streaming）。HLS 是Apple 動(dòng)態(tài)碼率自適應(yīng)技術(shù)，應(yīng)用在PC 端或者是Apple 終端進(jìn)行音頻視頻服務(wù)處理。在實(shí)際應(yīng)用模式中，具備m3u（8）索引文件、TS 媒體分片文件以及key 加密串文件。其基礎(chǔ)層級(jí)結(jié)構(gòu)如圖2 所示。

圖2 HLS 層級(jí)結(jié)構(gòu)示意圖

2.2.2 直播模塊處理技術(shù)

第一，視頻錄制端。利用電腦上音頻輸入設(shè)備或者是手機(jī)端的攝像頭、麥克風(fēng)等，目前移動(dòng)終端以手機(jī)視頻為主。采取的是HS 視頻錄制技術(shù)[6]。

第二，視頻播放端。利用電腦上的播放器以及手機(jī)端Native 播放器等，建立相應(yīng)的視頻播放處理模式，主要采取的是HLS 協(xié)議、RTMP 協(xié)議以及ffmpeg，針對(duì)移動(dòng)端視頻予以解碼處理。

第三，視頻服務(wù)器端。利用nginx 服務(wù)器，能在接收視頻錄制端提供視頻源的同時(shí)，為視頻播放端提供流服務(wù)。主要的技術(shù)手段是nginx rtmp-module 或者是simple-rtmp-server，完成流服務(wù)器相關(guān)工作[7]。

2.2.3 視頻直播系統(tǒng)處理技術(shù)

視頻直播系統(tǒng)處理系統(tǒng)主要?jiǎng)澐譃槊襟w模塊、服務(wù)模塊、管理模塊以及Open Source 模塊，如圖3所示。

圖3 系統(tǒng)組成

（1）媒體模塊主要包括音頻視頻采集單元、信息預(yù)處理單元、編碼單元、傳輸單元、解碼單元以及渲染單元等。

服務(wù)模塊包括禮物系統(tǒng)、聊天室、即時(shí)通信技術(shù)、支付系統(tǒng)、運(yùn)營(yíng)系統(tǒng)、任務(wù)系統(tǒng)、安全系統(tǒng)、統(tǒng)計(jì)系統(tǒng)等，能結(jié)合直播服務(wù)要求選取適當(dāng)?shù)奶幚砟Ｊ?，更好地維持直播系統(tǒng)運(yùn)行控制的科學(xué)性。

管理模塊包括前端管理和后臺(tái)管理。前端管理涉及客戶端設(shè)計(jì)維護(hù)等內(nèi)容。后臺(tái)管理涉及數(shù)據(jù)庫(kù)和控制模塊。

與此同時(shí)，結(jié)合實(shí)際應(yīng)用要求，從用戶生產(chǎn)內(nèi)容（User Created Content，UCC）、專業(yè)生產(chǎn)內(nèi)容（Professionally Produced Content，PPC）以及職業(yè)生產(chǎn)內(nèi)容（Occupationally Generated Content，OGC）中選取適當(dāng)?shù)闹辈ツＪ?，有效依?jù)直播控制要求完成相應(yīng)工作，更好地滿足廣播電臺(tái)流媒體網(wǎng)絡(luò)直播的應(yīng)用要求。

3 廣播電臺(tái)流媒體網(wǎng)絡(luò)直播應(yīng)用

在廣播電臺(tái)流媒體應(yīng)用體系中，為更好地搭建完整的網(wǎng)絡(luò)平臺(tái)推流模式，要結(jié)合電臺(tái)節(jié)目的實(shí)際情況，建立一個(gè)基于流媒體傳輸協(xié)議格式的推流地址，將主地址、掛載點(diǎn)以及串流碼作為核心，打造可控化應(yīng)用模式，從而維持網(wǎng)絡(luò)直播應(yīng)用管理的實(shí)效性。本文以HN 電視臺(tái)音樂(lè)頻道實(shí)時(shí)消息傳輸協(xié)議RTMP 流媒體傳輸推送蜻蜓平臺(tái)為例。

3.1 確認(rèn)網(wǎng)絡(luò)直播

在傳統(tǒng)廣播電臺(tái)開(kāi)展流媒體網(wǎng)路直播工作中，為更好地滿足后續(xù)工作管理控制的基本需求，要結(jié)合實(shí)際應(yīng)用環(huán)境落實(shí)規(guī)范化流程，保證相應(yīng)工作都能順利開(kāi)展和落實(shí)。在網(wǎng)絡(luò)直播工作開(kāi)始前要確認(rèn)電臺(tái)是否已經(jīng)完成播出授權(quán)，目前較為常見(jiàn)的方式包括合作處理模式和自建模式。

（1）合作處理模式。以電臺(tái)身份與一些較大的平臺(tái)完成合作洽談工作，基于網(wǎng)站服務(wù)器較為穩(wěn)定的優(yōu)勢(shì)，能支持較大寬帶范圍內(nèi)聽(tīng)眾訪問(wèn)，在簽署授權(quán)合同的基礎(chǔ)上，平臺(tái)會(huì)提供對(duì)應(yīng)的直播服務(wù)器支持。值得一提的是，在合作模式中電臺(tái)要下載對(duì)應(yīng)的直播軟件，并且利用網(wǎng)站方提供的直播參數(shù)，在登錄直播服務(wù)器后，結(jié)合相應(yīng)的實(shí)時(shí)性處理要求落實(shí)具體工作。與此同時(shí)，直播要借助直播服務(wù)器完成中轉(zhuǎn)工作。合作處理模式還可以聯(lián)動(dòng)廣播電臺(tái)網(wǎng)絡(luò)公司，在提供直播服務(wù)器架設(shè)的基礎(chǔ)上，廣播電臺(tái)要自行完成接入處理工作，配合廣播電臺(tái)日常播出計(jì)劃，更好地建立完整的信息傳遞和共享模式。

（2）自建處理模式。廣播電臺(tái)要自行購(gòu)買(mǎi)相應(yīng)的服務(wù)器設(shè)備，在服務(wù)器上安裝流媒體直播服務(wù)軟件，在完成服務(wù)器托管工作的同時(shí)，結(jié)合實(shí)際廣播應(yīng)用服務(wù)要求落實(shí)相應(yīng)工作計(jì)劃，借助直播軟件連接直播服務(wù)器完成相應(yīng)直播工作。值得一提的是，寬帶要自行購(gòu)買(mǎi)，或者與電信公司形成合作關(guān)系。自建處理機(jī)制對(duì)成本要求較高，具備相應(yīng)實(shí)力的電臺(tái)選擇這種方式。

無(wú)論是何種模式，都要基于實(shí)際使用要求和規(guī)范落實(shí)具體工作，以確保流媒體直播業(yè)務(wù)順利開(kāi)展和落實(shí)。

3.2 應(yīng)用基礎(chǔ)架構(gòu)

在滿足流媒體網(wǎng)絡(luò)直播應(yīng)用控制標(biāo)準(zhǔn)的基礎(chǔ)上，按照基礎(chǔ)流程完成相應(yīng)工作。

（1）設(shè)置推流服務(wù)器IP 地址（server IP），設(shè)定為starfish.hz.aliyun.008.qingting.fm。

（2）設(shè)置掛載點(diǎn)，/HNleguangbo[8]。

依據(jù)應(yīng)用要求建立基礎(chǔ)框架結(jié)構(gòu)，在此基礎(chǔ)上配合流媒體處理技術(shù)完成相應(yīng)工作。

3.3 配置處理

在完成基礎(chǔ)傳輸推送處理環(huán)節(jié)后，要將相應(yīng)的掛載點(diǎn)直接配置在音頻編碼器具體參數(shù)中，從而更好地完成電臺(tái)節(jié)目到平臺(tái)的推流直播。為保證推送處理的科學(xué)性，要優(yōu)選適配的推流音頻。目前，多數(shù)地區(qū)采取的都是電腦處理模式或者是專業(yè)硬件設(shè)施，專業(yè)化電臺(tái)音頻編碼器也逐漸受到了更多的關(guān)注，因?yàn)?5%以上的互聯(lián)網(wǎng)廣播聽(tīng)眾其實(shí)際使用的收聽(tīng)終端一般都是移動(dòng)網(wǎng)絡(luò)，所以專業(yè)編碼器編碼端就要滿足編碼格式的基礎(chǔ)要求，無(wú)論是碼流還是協(xié)議都要更好地服務(wù)于移動(dòng)終端，從而確保相應(yīng)的處理方式更加科學(xué)合理。在音頻編碼器處理環(huán)節(jié)中，主要是利用硬編碼和軟編碼。其中，硬編碼利用嵌入式多媒體處理器，就能打造更加安全可靠的信息交互平臺(tái)，借助不同編碼方式在設(shè)備選型環(huán)節(jié)優(yōu)選適配設(shè)備。

本文案例中HN 廣播電視臺(tái)增設(shè)的音樂(lè)廣播推流內(nèi)容為更好地提高質(zhì)量效果，選取國(guó)內(nèi)3 家廠家生產(chǎn)的編碼器，并對(duì)其進(jìn)行了階段性測(cè)試，依據(jù)測(cè)試結(jié)果完成選型工作。從設(shè)備穩(wěn)定性、模擬輸入選擇、音頻編碼效果、編碼碼率等進(jìn)行分析，并著重對(duì)比了推流地址路數(shù)、網(wǎng)絡(luò)延遲性以及音頻顯示是否直觀等信息數(shù)據(jù)。實(shí)驗(yàn)結(jié)果顯示，設(shè)備的延時(shí)大概都集中在6 s左右，手機(jī)延時(shí)約為30 s。應(yīng)用獨(dú)立音頻硬編碼器能更好地滿足要求，維持較好的可靠性、安全性和性價(jià)比。相關(guān)配置如表1 所示。

表1 設(shè)備編碼相關(guān)配置

4 結(jié) 論

廣播電臺(tái)推流技術(shù)的應(yīng)用具有重要的研究意義，能更好地維持網(wǎng)絡(luò)直播運(yùn)行管理的科學(xué)性，配合綜合業(yè)務(wù)管控處理工序，打造完整的應(yīng)用實(shí)踐運(yùn)行控制模式，提高流媒體的綜合價(jià)值，為廣播電臺(tái)的可持續(xù)發(fā)展奠定堅(jiān)實(shí)基礎(chǔ)。