沈阳电视台网络环境下编播业务流程设计及实践

沈阳电视台通过媒体资产管理系统的建设，对全台网络

进行整合，实现了一个制、编、播、存一体化的电视台网络

系统。本文介绍了网络编播业务流程设计及在实践过程中遇

到的问题。

全台网流程媒体资产管理

沈阳电视台网络系统2006年11月1日全面投入使用，通

过一年多的运行，充分体现出数字化网络化的优势，在网络

环境下形成新的编播业务流程逐渐成熟，社会效益与经济效

益得到提高。

一设计原则

编播业务流程是电视台编排节目播出的规范，涉及的操作

有节目提交、节目审看、节目单编排等。每个电视台都会根据

自己的实际情况制定出符合自身特点的编播业务流程，有的台

采用频道制，节目单的编排由频道负责；有的台是总编室负责

制，由总编室负责全台节目的编排。但无论采用哪种方式，都

一定会对由谁提交节目、何时提交节目、由谁负责审看、节目

何时交给播出部、节目单怎样编排、由谁审批等做出具体的规

定。在原有板块化的模式下，整个流程都是围绕播出带进行运

转，但在网络环境下则是围绕节目文件的迁移进行运转。录像

带传递与文件迁移具有非常异样的属性，所以网络环境下设计

编播业务流程，既要继承原有流程中的必要功能，又要适应新

的网络特点。因此在设计上应把握以下三个原则。

1. 连通性

就是说业务流程应在网络环境下贯通。如果编辑后的节

目必须下载到录像带上，才能交给媒资编目保存，而且媒资

编目保存的节目又必须下载到录像带上，才能交给播出部进

点，连通性差。

2. 安全性

连通性强的网络能够提高工作效率，但必须是在保证电

一个功能环节结束后都要设计安全检测，以便及时发现问题，

解决问题。

3. 灵活性

考虑到全台网的复杂性及业务的多样性，网络环境下编

播业务流程应该有一定的灵活性。要考虑局部出现故障如何

应对，或网络中断时如何保证编播的问题。

二编播业务的核心——节目播出单的

制作

节目播出单的编排与制作，是电视台编播业务流程的核

心，或者说电视台编播业务是围绕节目播出单进行的。沈阳电

视台实行的是总编室负责制，由总编室频道编辑负责全台五个

频道节目播出单的编排。在网络化之前，总编室频道编辑在办

公网上编排制作节目播出单，然后打印，由主任、台长审批，

之后再交给播出部，由播出部值班员依照节目单在播出系统上

再次进行编制。这样的流程，不仅重复劳动，容易出差错，而

且也不符合连通性原则。所以我们在网络整合时，将节目单的

编制设计在媒资系统上，并将媒资浏览查询软件嵌入节目单制

作软件。这样在同一个工作站上，既可以编制节目单，又可以

浏览查询媒资系统的播出节目素材，并且可以将播出节目素材

与节目单进行绑定，再向播出系统发送。

这样一来，总编室编制的节目单就与原先在办公网上编

制的节目单有了本质的区别。此节目单就是播出系统要执行

的节目单，所以必须具备如下要求：

幕键、台标键、首重播提示等。

2. 制作方便

如果仍采用每天逐条录入节目要素的方法，总编室频道

编辑将不堪重负。所以必须采取措施，提高制作效率。我们

采用的方法有：

●从模板或从某个节目单拷贝制作新节目单。如制作某

频道周一节目单，可从同频道上周一的节目单进行拷贝。但

拷贝时，系统自动对一般节目的ID进行刷新，自动设置当日

为播出日期，自动设置播出素材保留日期为一天；

●自动添加播出日期后缀。有些节目名称后可加日期后

缀，例如：一频道2007年3月1日播出一条广告，名称为“一

频道广告（3）070301”，而在以3月1日节目单拷贝制作3月

8日节目单时，系统会自动将节目名称修改为“一频道广告（3）

070308”，有了日期后缀，为播出系统检验素材了提供方便；

●首播、重播节目的设定及自动绑定。电视台节目播出

过程中，一定会有一些重播节目，重播可能是当日，也可能

是隔日、可能是同频道，也可能是在其他频道。如果不将首

播、重播节目作出一定的关联，播出系统会多次要求加载该

条节目素材。对此我们在节目播出单制作要素中增加首重播

提示字段，对首播节目分配节目ID，重播节目不分配节目ID。

我们可用手工的方法，把重播节目与首播节目的ID进行绑

定。但对一些时间固定、频道也固定的首、重播节目，只要

设定参数，系统会自动将重播节目与首播节目绑定；

●播出素材库节目的处理。有些节目长期播出，其素材

也长期保留在播出服务器上，如果每天都对其加载进行手工

操作也很麻烦。我们采用的办法是将该节目设为“宣传片”，

在拷贝制作节目播出单时，对设定为“宣传片”节目的ID不

进行刷新。这样就保证了在节目单拷贝时就完成节目素材的

加载，从而简化了制作过程。

总之，采取了以上等措施，减少了不少手工操作，可以

让我们把主要精力集中到节目内容编排及调整上。目前，在

正常情况下，总编室频道编辑每天编排节目单比较繁忙的操

作就是修改电视剧中的广告插播点。

3. 安全可靠

必须保证节目播出单制作、发送的安全可靠。首先，硬

件、软件要有备份；第二要有检测。我们设计在媒资编单系

节目单制作、初审、终审、节目单修改等不同的权限，提供

给编辑、科长、主任等承担不同职责的人员使用，并相应建

立岗位责任制和必要的规章制度。

总编室节目播出单编制及发送流程如图1所示。

三设计五种播出素材准备方式，形成

五类业务流程

在新的节目播出单制作系统设计时，我们增加了一个字

段要素——“素材准备方式”。可有五项选择：录像带上载、

转码、广告、直播、播出素材库。基于这五种准备方式，可

形成五个类型的业务流程。

1. 录像带上载

在制作节目播出单时，会向设为该准备方式的节目分配

新的节目ID，当节目单发送给播出系统后，会在播出系统形

成“待上载列表”，该列表可按频道、播出日期进行检索。播

出部值班员根据该列表上载播出节目，但该节目的名称、长

度、播出时间、素材删除日期、播出期间可否键入字幕等要

素，均已在节目单制作时设定，值班员只是用录像带上载，上

载后审看素材内容、长度是否与播出单一致即可。目前沈阳

电视台对电影、天气预报、专题一类的节目采用此类流程。

2. 转码

采用转码方式的节目，必须是在非编网上制作、提交给

媒资系统的播出版节目，当然也包括媒资编目保存在近线磁

带库后又回迁到在线磁盘阵列的节目。对这类节目，我们设

计为首先可在媒资网上进行审看，并在审看过程中可以标记

一些信息，如是否合格、广告插播点等。其次通过嵌入在总

自动将节目素材写入到一个播出缓存之中，写完后系统会自动校验，无问题则向播出系统发送消息，播出系统会启动转码程序，将节目素材转码迁移到播出系统，转码结束后也设有自动校验及向媒资系统反馈消息的程序。开始我们在播出系统还设计了转码后值班员审看环节，但经过一定时期的实践，特别是增加了自动校验之后，转码没有出现过问题，就将此环节撤销了。目前沈阳电视台对电视剧、节目导视、重点节目宣传、综合栏目等节目采用此类流程。

3. 广告

在节目播出单上准备方式设为“广告”的节目，实际上是个逻辑段包。在节目单向播出系统发送的同时，也向广告串编管理系统发送广告段包的信息，主要是播出日期，段包数量、长度等。沈阳电视台广告串编管理系统是一个集客户管理、合同管理、财务管理、编播管理、统计管理为一体的网络系统，它是将原有硬盘播出系统与广告管理系统结合而成，与沈阳电视台现有播出系统采用相同类别的播出服务器，可作为备播系统，目前该系统由广告管理部门使用。当签订广告协议后，有关人员将协议输入广告管理系统，系统会自动形成每日广告串联单。但该广告串联单中的广告段包必须与总编室节目播出单设定的广告段包在数量上一致，才能导入到广告串编工作站上，在广告串编工作站上对无素材的广告提示需上载素材，也可进行必要的填补或调整。之后，由广告管理人员向播出发送，实际发送的只是播出服务器上没有的几条广告，又不需转码，所以速度很快。发送结束后，发送者必须通过检测软件检验发送是否成功。从这个流程可以看出，总编室对广告类节目的播出，只是进行宏观控制，只规定每天广告段播出的次数，每段的时间，至于广告段里具体的内容，则由广告部门决定。广告部门如要更改播出次数，增减每段长度，必须经一定审批程序，经总编室修改节目播出单方可实施。

4. 直播

电视台的许多节目是采用直播方式的。节目播出单对此类节目的准备方式设为“直播”。但总编室制作的节目单中不包含“直播信号源”要素。所以节目单发送给播出系统之后，对直播方式的节目，会在播出系统作出提示，让播出值班员在直播前正确选择外接信号源。另外需注意，有些直播节目是采用延迟播出，实际是边上载边播出，制作节目播出单时

服务器上，可采用制作“宣传片”的方法。但要明确，并不是在节目播出单上将准备方式设为“播出素材库”，节目素材就一定存在于播出服务器上了，而是第一次必须采用录像带上载或转码方式将节目素材上载到播出服务器上，设置较长的素材保留时间，然后再使用该节目ID 时，系统会自动将准备方式切换到“播出素材库”，不需人为设置。如果素材被播出系统删除，即便设为播出素材库也不能正常播出。采用“播出前检测”的方法，可判断节目素材是否存在于播出服务器上。

通过上述五类流程的介绍，可以看出在网络环境下沈阳电视台编播业务流程是具有一定的灵活性的。其总体流程可用图2表示。

四 实践中发现的问题及应对措施

沈阳电视台网络环境下编播业务流程是在实践中不断完善、逐渐成熟的，在实践过程中出现过不少这样那样的问题，现归纳几点供大家借鉴。

1. 节目播出单制作、发送方面的问题

沈阳电视台媒资系统与播出系统分别由两个公司承建的，所以制定接口协议是必需的。我们规定节目单采用XML 标准格式文件向播出系统发送，也规定了缓存方式、字节定义等。但忽视了两家公司节目单制作内在的一些东西，如字段阈值范围。新系统启用不久，经常出现节目单发送失败现象，经我们查找，确定是由于总编室编单中采用了XML 文件的非法

不再发生。最近出现过一次较为奇怪的现象，某个频道编辑

制作节目单时，将一些播出节目素材的删除日期设为2100年

12月31日，节目单发送到播出系统之后，凡是检索该节目素

材的上载工作站全都处于瘫痪状态，所有值班员账户都不能

登陆。沈阳电视台有关技术人员直接对数据库进行操作，将

这些素材的删除日期改为2008年12月31日之后，系统才恢

复正常。这一类似“千年虫”的问题说明严格规定阈值范围

是很重要的。

2. 播出节目素材迁移转码方面的问题

播出节目素材通过文件迁移方式向播出系统发送，是网

络环境下业务流程具有的一个突出特点，也是一个容易出现

问题的加载方式。在使用网络上传节目初期，我们发现媒资

系统提交给播出系统的节目在转码之后，有时会出现“空壳”

现象，即转码后有节目名称，但内容编码全是0。为克服此问

题，我们为系统增加了自动校验功能，在媒资系统将播出节

目写入播出缓存之后，首先自动进行校验，校验成功后再向

播出系统发消息，令其开始迁移转码，如果校验失败，媒资

系统会自动重新进行写入缓存的操作。同时，播出系统转码

之后也进行自动校验，如有问题则向媒资系统发送操作失败

的消息，节目素材不入数据库。此项改革后，播出转码的此

类故障再未发生。

对文件转码、迁移类的节目加载过程，我们采用的一个

原则是，谁发送节目，就由谁检测是否发送成功。转码节目

由总编室频道编辑发送，在节目单上设有转码检测功能，也

就是说节目单发送后，一段时间后，转码节目成功后，会在

该节目记录前标记“√”，如失败会标记“？”。广告节目是

由广告部门有关人员负责发送的，所以由该责任人负责检测。

有一次，广告部门某频道串编人员把日期记错了，把后日的

广告加载给播出系统，而没把第二日的广告进行加载，结果

第二天清晨，播出部值班员加载播出单时，发现一个频道的

广告素材全是空的。此时虽经紧急处置没出现问题，但我们

也察觉到在流程上有不安全的因素存在。所以我们协调承建

公司在播出系统上安装自动报警软件，在播出前一日晚上对

广告加载进行自动检测，如有问题将自动报警。

3. 节目制作网络化提交、审看方面的问题

节目制作后，采用网上提交播出的方式，是实施新业务

是提交了，但总编室在媒资系统找不到。解决这些问题的办

法，一是制定操作规范、二是加强人员培训。对此沈阳电视

台制定出《综合非编制作网节目制作、审查、交版及播出业

务流程相关技术性操作规范》，该规范对非编节目制作——制

片人审看——主任审看——总编室审看——总编室编单调用

——播出值班员核对播出等环节，都做出了具体规范。例如，

在非编制作环节，规范节目名称的建立、素材采集视音频幅

度、音频输出的设置等。在主任审看环节，规范审看时间期

限及审看重点等。沈阳电视台先后举办了四期培训班，对所

有编辑记者进行普遍培训。而在具体栏目实行网络提交时，对

该栏目的制作人员再次进行重点培训。另外，实施过程中要

采取循序渐进的方式，成熟一个，实行一个，不能一蹴而就。

对网络提交节目的审看，首先要求节目负责人在制作网

打包合成播出版后进行一次审看，合格才能向媒资进行迁移。

然后总编室专职审片人员在媒资网设置的专用审看工作站上，

对节目进行播出前审看，可标注审看意见及信息。这里请注

意，审看工作站一定要对高码流的播出素材进行审看，一定

要有音频电平显示。

4. 媒资系统在线、近线迁移方面的问题

通过媒资进行网络整合后，在沈阳电视台非编制作网制

作的节目，打包合成后，可以将播出版上传给媒资系统（合

成的制作版或原素材也可以提交媒资保存），播出版在媒资系

统既可以编目保存，也可以用于播出，但媒资在线盘阵存储

容量有限，所以对节目提交的时间必须作出规定，根据沈阳

电视台的实际情况，总编室规定节目网络提交应在节目播出

前2~5天内完成。

但有些提前制作完成节目，必须要保留的，可以迁移保留

在近线存储上，播出时再回迁，例如电视剧等节目。我们采用

的流程是：将每部电视剧剪辑成标准播出版，提交媒资编目保

存。播出前回迁、再次审看，然后由频道编辑将其与节目单绑

定，发送到播出。由于数量很大，每天要播出30集左右，所

以保证电视剧播出节目素材在媒资系统正常迁入迁出是一项重

要工作。在实践中，我们多次遇到迁移方面的问题，有硬件故

障，也有软件方面缺陷，操作流程不当也有影响。我们的经验

是，必须合理安排任务，均衡数据流磁带机的操作。电视剧回

迁提前3~4天，尽量与批量编目保存任务错开时间操作。同时

加强系统的技术监管，发现问题及时解决。