廣播電臺推流技術及網絡直播應用探討

2023-08-04 00:47:46鄧貴川

通信電源技術 2023年8期

鄧貴川

（重慶市武隆區融媒體中心，重慶 408500）

0 引言

隨著互聯網技術的不斷發展進步，互聯網視頻直播受到了更多的關注，為積極推進廣播電臺發展轉型進程，要積極整合流媒體應用模式，利用實時性直播的方式為廣播電臺提高市場核心競爭力提供保障。

1 流媒體概述

對于廣播電臺發展轉型工作而言，要想實現多元化發展，就要積極推進廣播電臺視頻化發展進程，從產生視頻化需求的角度出發，實現網絡和電視融合后的視頻直播，配合媒體技術處理方案更好地實現完全意義上的廣播視頻化，借助網絡PC 端、移動端等應用模式更好地滿足可視化管理應用需求。

1.1 內涵

流媒體也被稱為流式媒體，指商家利用視頻傳送服務器將節目當成數據包予以發送，直接傳輸到對應網絡體系中，用戶在借助解壓設備進行數據解壓后，節目就能像發送時的狀態一樣予以呈現。在流媒體應用后，人們在網上聊天就能直接采取語音輸入的方式，配置攝像頭就能完成視頻交流。在流媒體傳輸信息的過程中，基于A/V 和3D 等多媒體文件，借助特殊壓縮方式完成壓縮包的處理，配合視頻服務器實現實時性、連續性數據傳送處理[1]。

1.2 方式

順序流式傳輸指按照順序完成下載，在下載文件的同時用戶就能利用在線媒體完成觀看，并且在固定時間內用戶能完成已經下載部分的觀看。順序流式傳輸處理環節中，能結合用戶連接的速度完成調整工作。順序流式文件是基于標準超文本傳輸協議（Hyper Text Transfer Protocol，HTTP）服務器完成處理，整體管理效果較好，且其實際應用質量和播放效果與防火墻無關[2]。

實時流式傳輸主要包括實時流式傳輸特定服務器和特殊網絡協議，按照相應的實時性協議，配合服務器應用要求，就能更好地滿足數據信息的匯總處理。

2 廣播電臺推流技術內容及實現過程

基于廣播電臺轉型發展要求，在廣播電臺推流技術應用控制的環節中，要按照技術要求和規范落實具體工作環節，維持相應處理控制環節的科學性，更好地配合程序應用要求，符合廣播電臺檢索以及服務的具體標準。

2.1 廣播電臺推流技術內容

（1）智能流技術能完成自動檢測網絡狀態等工作，將音頻視頻屬性調整到最佳狀態后，確保用戶收到的是和網絡速度相匹配的媒體流，更好地服務用戶獲取用戶體驗[3]。

（2）分流技術，發送端服務器將媒體流直接分布在多個接收服務器中，客戶端能建立就近訪問的處理模式，獲取高質量媒體流，并且減少帶寬的使用率。在推流的過程中，將直播內容直接推送到廣播電視臺對應服務器（如圖1 所示）。廣播電視臺推流處理環節中，支持數據包的緩存處理，配合內容分發網絡技術就能更好地實現用戶請求的合理性發布，提高有效的響應速度并減少骨干網絡壓力。

圖1 視頻傳輸播放過程

（3）流媒體技術還包括內容分發網絡技術，構架在IP 網絡上建立內容疊加網，利用主動內容管理、全局負載平衡以及內容緩存處理等環節，將用戶請求的流媒體內容直接發布到距離用戶較近的網絡邊緣，在體用響應速度的同時，更好地降低骨干網絡的運行壓力，維持可控化應用效能，保證網絡控制協議基礎上數據傳輸的可控性[4]。

2.2 廣播電臺推流技術實現過程

在廣播電臺推流技術應用處理控制環節中，配合流媒體應用管理標準，打造完整的應用體系，滿足技術實現的具體要求，實現多元數據并行管理的目標。

2.2.1 直播中的流媒體協議

第一，實時消息傳送協議（Real-Time Messaging Protocol，RTMP）。RTMP 是實時性消息傳輸協議，協議在應用過程中基于傳輸控制協議（Transmission Control Protocol，TCP）完成相應的數據處理，本質上是設計用來完成實時性數據通信傳輸的網絡協議，應用在Flash/Air 平臺等，能支持RTMP 協議流媒體以及交互服務器應用要求的落實，建構完整的音頻、視頻以及數據通信體系[5]。另外，協議還支持操作消息格式（Action Message Format，AMF）數據的管理和控制，完成FLV（Flash Video）視頻以及音頻數據的協同管理，利用多元連接模式保證多路網絡流工作順利展開，按照固定大小的包實現可控化傳輸管理目標。

第二，基于HTTP 的流媒體協議（HTTP Live Streaming）。HLS 是Apple 動態碼率自適應技術，應用在PC 端或者是Apple 終端進行音頻視頻服務處理。在實際應用模式中，具備m3u（8）索引文件、TS 媒體分片文件以及key 加密串文件。其基礎層級結構如圖2 所示。

圖2 HLS 層級結構示意圖

2.2.2 直播模塊處理技術

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

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

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

2.2.3 視頻直播系統處理技術

視頻直播系統處理系統主要劃分為媒體模塊、服務模塊、管理模塊以及Open Source 模塊，如圖3所示。

圖3 系統組成

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

服務模塊包括禮物系統、聊天室、即時通信技術、支付系統、運營系統、任務系統、安全系統、統計系統等，能結合直播服務要求選取適當的處理模式，更好地維持直播系統運行控制的科學性。

管理模塊包括前端管理和后臺管理。前端管理涉及客戶端設計維護等內容。后臺管理涉及數據庫和控制模塊。

與此同時，結合實際應用要求，從用戶生產內容（User Created Content，UCC）、專業生產內容（Professionally Produced Content，PPC）以及職業生產內容（Occupationally Generated Content，OGC）中選取適當的直播模式，有效依據直播控制要求完成相應工作，更好地滿足廣播電臺流媒體網絡直播的應用要求。

3 廣播電臺流媒體網絡直播應用

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

3.1 確認網絡直播

在傳統廣播電臺開展流媒體網路直播工作中，為更好地滿足后續工作管理控制的基本需求，要結合實際應用環境落實規范化流程，保證相應工作都能順利開展和落實。在網絡直播工作開始前要確認電臺是否已經完成播出授權，目前較為常見的方式包括合作處理模式和自建模式。

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

（2）自建處理模式。廣播電臺要自行購買相應的服務器設備，在服務器上安裝流媒體直播服務軟件，在完成服務器托管工作的同時，結合實際廣播應用服務要求落實相應工作計劃，借助直播軟件連接直播服務器完成相應直播工作。值得一提的是，寬帶要自行購買，或者與電信公司形成合作關系。自建處理機制對成本要求較高，具備相應實力的電臺選擇這種方式。

無論是何種模式，都要基于實際使用要求和規范落實具體工作，以確保流媒體直播業務順利開展和落實。

3.2 應用基礎架構

在滿足流媒體網絡直播應用控制標準的基礎上，按照基礎流程完成相應工作。

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

（2）設置掛載點，/HNleguangbo[8]。

依據應用要求建立基礎框架結構，在此基礎上配合流媒體處理技術完成相應工作。

3.3 配置處理

在完成基礎傳輸推送處理環節后，要將相應的掛載點直接配置在音頻編碼器具體參數中，從而更好地完成電臺節目到平臺的推流直播。為保證推送處理的科學性，要優選適配的推流音頻。目前，多數地區采取的都是電腦處理模式或者是專業硬件設施，專業化電臺音頻編碼器也逐漸受到了更多的關注，因為95%以上的互聯網廣播聽眾其實際使用的收聽終端一般都是移動網絡，所以專業編碼器編碼端就要滿足編碼格式的基礎要求，無論是碼流還是協議都要更好地服務于移動終端，從而確保相應的處理方式更加科學合理。在音頻編碼器處理環節中，主要是利用硬編碼和軟編碼。其中，硬編碼利用嵌入式多媒體處理器，就能打造更加安全可靠的信息交互平臺，借助不同編碼方式在設備選型環節優選適配設備。

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