APP下载

融媒体环境下电视台数字播控系统设计与实现

2021-12-09柳雨

微型电脑应用 2021年11期
关键词:控系统服务器模块

柳雨

(西安培华学院 新闻中心, 陕西 西安 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 总结

本文设计了电视台播控系统的云平台架构,并以实用性为基准,从产品功能出发对节目播出前、中、后过程中涉及的调度、播出控制、质量监测都进行了详细设计。但在设备选型择优、管理机制方面还有所欠缺,另外系统未真正投入运营,在系统功能扩展以及性能指标方面还需进一步优化。

猜你喜欢

控系统服务器模块
28通道收发处理模块设计
“选修3—3”模块的复习备考
关于DALI灯控系统的问答精选
联调联试中列控系统兼容性问题探讨
通信控制服务器(CCS)维护终端的设计与实现
PowerTCP Server Tool
得形忘意的服务器标准
计算机网络安全服务器入侵与防御
一种新型列控系统方案探讨
简析GSM-R在CTCS-3列控系统中的作用和故障判断处理