融媒體環境下電視臺數字播控系統設計與實現

柳雨

(西安培華學院 新聞中心, 陜西 西安 710125)

0 引言

近年來隨著互聯網的發展,新興媒體對傳統電視臺造成了極大的沖擊，作為傳統媒體代表的電視臺如果繼續固守原有模式則有可能陷入資源匱乏、渠道縮減、觀眾流失的困境。如何利于信息技術與新媒介進行融合勢在必行。因此，本文基于新舊媒體融合的大環境，利用高新技術設計播控系統，力求提升播出質量、提高新聞時效性，最終達到增長電視臺切實經濟效益的目的。

1 融媒體概述

1.1 整體理念

融媒體其實從實質上來說不是一種媒體，屬于一種將傳統媒體與新興媒體融合運作的理念。但并不是簡單的合并，而是各種資源、渠道、內容、利益、管理多方面的深入融合。各種角色利用環境中的所有媒介在事件的發生與發展階段以各自的方式實現信息傳播，包括信息描述、觀點發表。

1.2 SWOT對比分析

為了更好地優化電視臺的發展策略，利用SWOT矩陣分析法將傳統電視臺與新興媒體進行對比分析。

(1) 優勢：電視臺隸屬事業單位或國企，屬于官方媒體，有更多的資源以及優惠政策，且在觀眾心中具有比較強的權威性以及公信力，不存在不良信息。

(2) 劣勢：電視臺由于審查等因素流程耗時長，在時效性相對于新興媒體來說要弱一些，且不易搜索，在追溯性上不及新興媒體。另外，傳播方式屬于一對多，新媒體屬于多對多，在互動性與傳播速率上處于劣勢[1]。

(3) 機會：互聯網時代也給電視臺的發展帶來了新的契機，加上信息來源廣、具有采訪權，發展動態新聞具有良好前景。

(4) 威脅：隨著運營方式的改變，新興媒體在節目制作、分發、播出過程中身兼數職，在設備以及人員投入上都更輕便。傳統電視很容易陷入來源減少、渠道縮減、適應性差流失觀眾的危險境況。

2 融媒體環境下電視臺困境

2.1 現狀與困境

隨著互聯網的發展，傳統電視的觀眾漸漸流失，大部分電視臺的體制太過僵化，執行力較弱，而且節目缺乏創新性，不管是節目定位還是模塊設計都基本一致，選題重復無新意，觀眾很容易厭倦。正是由于這些原因近年來收視率迅速下降，加上廣告發展不利，經濟效益嚴重下降。其實并不是事件內容有所不同，而是傳播平臺的理念、機制與受眾大為不同。主要體現在以下3個方面。

(1) 電視臺的播放內容缺少針對性，新媒體是根據面向對象的需求來決定投放內容。

(2) 電視臺的受眾對象多為中老年人，新媒體則更多以年輕人為關注點。

(3) 電視臺節目的傳播媒介是電視，而新媒體利用的是各類移動終端、App，更為高效。

2.2 應對策略

通過傳統電視臺與新興媒體的SWOT分析可以看出，既有內部因素也有外部影響，發展的動力離不開新興技術，但同時內部機制也需要優化改革。如何制定符合自身特色的深度融合策略成為勢必要解決的問題。首先，必須用內容打動觀眾，無論什么技術，沒有內容都是空談。其次，是要體現出傳統方式與新興媒介的配合，打造融媒體中心，實現統籌規劃。

3 電視臺數字播控系統需求分析

3.1 總體分析

電視臺播控系統首要以安全播出為前提，各個環節都要有備用方案或者緊急預案，確保播出全程沒有崩潰點，在核心環節需要額外加強監控，實現預警功能。充分利用信息技術保障播出質量、播出效率，規范整體流程，實現采、編、制、播一體化、智能化。

3.2 功能需求

電視臺數字播控系統從播前、播中、播后的業務流程中可以劃分為以下3大功能模塊：總控模塊、播控模塊、監控模塊。總控模塊負責整體調度;播控模塊負責節目播出過程中的編單、審查、上載、播出控制等；監控模塊負責各個環節的狀態以及整體流程監測[2]。

3.3 設計原則

系統設計過程中需遵循以下4個設計原則。

(1) 安全性：設計過程中需要綜合考慮軟硬件各類影響原因，確保系統穩定運行無崩潰環節。

(2) 實用性：一切準備面向應用，從帶寬、存儲、設備、軟件多個方面進行量化落地，確保系統從管理到運行簡便、清晰、實用。

(3) 擴展性：系統設計需要考慮頻道增加或其他需求新增時的可擴展性，不能影響正常使用。

(4) 易維護：電視臺播控系統屬于7×24持續運行的系統，為了不間斷的播出效果，必須確保系統投入運行之后容易維護，出現問題快速解決。

4 電視臺數字播控系統詳細設計

4.1 總體架構

4.1.1 云平臺

電視臺數字播控系統在網絡結構上除了傳統的制作播控系統之外，還需與臺內私有云、媒體專屬云互聯互通，相互融合，網絡結構如圖1所示。

圖1 云平臺架構

4.1.2 系統結構

系統結構上可分為資源層、服務層、應用層，逐層向上提供技術支撐，總體結構圖如圖2所示。

圖2 系統結構圖

(1) 資源層：底層基礎支持包括服務器、數據庫、存儲、網絡等。

(2) 服務層：供應用調用的時鐘、消息、節目單等服務以及WebService消息接口、Ftp文件接口等。

(3) 應用層：實際的播出控制、內容管理、審看、播出等應用功能以及監控。

4.2 帶寬設計

電視臺數字播控系統帶寬主要包括2個方面：上載帶寬、遷移帶寬。其中，上載通道需要進行數據實時讀取與寫入，取265 Mbyte/s。遷移帶寬按服務器10倍速計算，取220 Mbyte/s。夜間時長減少，取177 Mbyte/s，制作網遷移包括文件審核等取398 Mbyte/s，由此計算加上冗余量，存儲的讀寫帶寬至少為1 Gbyte/s。

4.3 功能模塊劃分

根據電視臺數字播控系統的需求分析以及功能架構，需要包括基礎平臺、總體調度、傳輸、存儲、播出、監控保障等，主要功能是實現安全高質量的播出[3]。在功能模塊上劃分為三大子系統和十大模塊，總體結構如圖3所示。

圖3 功能結構圖

4.3.1 總控系統

總控系統包括調度模塊和同步模塊。調度模塊，利用MirandaNV8144調度矩陣對輸入的嵌入音頻的高清視頻信號進行轉換，可根據信號數量實現靈活調度。支持標準網絡協議，通過以太網實現權限控制。同步模塊，利用TektronixSPG8000同步信號發生器、ECO8000信號倒換器實現信號同步，與此同時，要具有延時功能以便于調整。另外，時鐘作為播出系統中的時間標準，利用GPS接收機、高穩時鐘、時碼倒換器實現并制定主備策略。通過時碼分配器傳送至播控系統。

4.3.2 播控系統

播控系統包括播出控制模塊、節目單編單模塊、素材上載模塊。播出控制模塊，以節目單為依據調控視頻服務器、字幕機的輸出。并在遇到緊急情況的時候實現播控調整，確保節目播出的安全性。采用主備策略通過內部協議進行切換。節目單編單模塊，編制節目單屬于播控系統中的日常工作，根據節目時間進行精準計算完成播出順序安排，其中包括節目的串編以及廣告串編，需確保不產生沖突。素材上載模塊，素材上載模塊主要是將磁帶庫存儲的內容上傳到服務區供總控系統調度。在上傳之前要確保已經過審查后形成上傳任務信息，屬于播放前的準備工作[4]。

4.3.3 監控系統

監控系統包括MD5校驗模塊、文件審核模塊、日志管理模塊、硬件設備監測模塊、軟件功能監測模塊。MD5校驗模塊：播出素材在上傳到播控系統后需進行MD5碼校驗以判斷傳輸準確性，如果不一致則反饋錯誤代碼要求重新傳送。文件審核模塊：文件審核模塊包括自動審核及人工審核，自動審核是利用切片集群形式對音頻視頻文件進行技術審核，主要包括計時以及遷移，確保高清在3倍速、標清在10倍速之上。對于自動審核不通過的文件再由專業人員進行人工審核。日志管理模塊：日志管理模塊主要是實現素材增刪改查、審核結果、播出過程、節目代碼操作等多種動作記錄日志信息，以便于后續分析統計，支持定期歸檔。硬件設備監測模塊：通過SNMP、TCP等接口協議采集設備信息，包括數據庫資源、存儲設備，查看設備狀態是否達到提前設定的告警條件，達到即發出預警。軟件功能監測模塊：根據軟件的運行狀態以及異常日志監控軟件的各個關鍵環節，對于可能導致服務異常、系統崩潰的異常數據及時預警。

4.4 數據庫設計

4.4.1 數據存儲方案

數字播控系統中硬盤服務器的數據在制作節目之后存入節目存儲區，上傳審批之后轉入磁帶庫，最終根據節目表順序調出上載至硬盤服務器。在主備存儲區保留3天，在硬盤服務器保留一周，長久保留的原始數據存在磁帶庫中。其中，涉及的服務器參數如下。

(1) 數據庫服務器：Intel Xeon E5-2620 67核，內存16G，硬盤300G，千兆網卡。

(2) 存儲服務器：HP Storage-Works P2000，雙控制器，緩存2G，SAS硬盤12塊。

(3) 視頻/接口服務器等：Omneon710016臺，單臺有效容量6 Tbyte，帶寬90 Mbyte/s。

4.4.2 核心數據庫表設計

核心數據庫表設計如下。

(1) 節目信息表：主要包括節目單日期、頻道、時段、序號、名稱、類型、定時、插播類型、磁帶號、播出時間等[5]。

(2) 素材上載表：主要包括素材名稱、長度幀、UNC、文件名、申請人、創建時間、首播時間、欄目名稱、狀態、描述、優先級、備注等。

(3) 存儲信息表：主要包括文件編號、區域編號、存儲設備、文件名稱、狀態、創建人員、創建時間、來源、類型、保留天數、卷標、MD5等。

(4) 播出狀態表：主要包括唯一標識、審核位置、鎖定狀態、鎖定次數、節目代碼、AFD、類型、組合段、創建人、審核狀態等。

(5) 工作時間表：主要包括工作人員、排序、開始日期、結束日期等。

4.5 應急預案

電視臺播出系統必須具備應急處理能力，結合實際情況制定應急預案，避免播出故障。首先要確保技術手段可靠；其次要制定合理的管控機制；最后還需要各部門互相配合。總的來說安全播出是設備、人員、管理3方面協同的過程。應急處理流程如圖4所示。

圖4 應急處理流程

5 系統測試

5.1 功能測試

為驗證本文設計系統的功能，在國內某地方電視臺進行了實地部署，并進行了播出模擬測試，根據系統功能模塊劃分對核心功能制定測試用戶，驗證結果滿足預期，如表1所示。

表1 系統功能測試結果表

5.2 性能測試

為驗證本文設計系統的功能，將部署的系統持續運行240小時，系統運行穩定，視頻解碼正常、無丟幀拖尾現象、系統頁面響應速度在3 s以內，滿足性能要求[6]。

6 總結

本文設計了電視臺播控系統的云平臺架構，并以實用性為基準，從產品功能出發對節目播出前、中、后過程中涉及的調度、播出控制、質量監測都進行了詳細設計。但在設備選型擇優、管理機制方面還有所欠缺，另外系統未真正投入運營，在系統功能擴展以及性能指標方面還需進一步優化。