面向内容监管的广播电视节目编目系统

吴波

国家新闻出版广电总局监测数据处理中心

摘要：随着广播电视频道的日益增加，现行人工监听监看方式已无法适应大量节目内容监管的需求。本文提出了面向内容监管的广播电视节目编目系统的设计和实现方案。该系统整合了广电监管平台现有监测系统的音视频资源，利用模板库智能识别音视频中的节目，应用了开源的技术框架，采用了C/S和B/S混合架构为内容监管用户提供不同的使用视图，具备可扩展性。该系统已应用于总局多项内容监管工作中，提高了内容监管的工作效率。关键词：广播电视内容监管；编目系统；特征提取；分布式计算

1 引言

随着广播电视的快速发展，广播电视频道日益增加，截至2014年12月，国家新闻出版广电总局（以下简称总局）已批准开办电视频道1190个，广播频道1095个[1]。针对各频道播出内容，总局相继出台了管理办法[2]。明确总局提出的各项规定是否落到实处，给广播电视内容监管工作带来了很大挑战。总局监管大楼建成后，搭建于监管大楼的监管平台可采集到来自卫星、无线、有线等监测系统近千套频道的数据[3]，现行的人工监听监看的工作方式已无法适应大量节目内容监管的要求，因此迫切需要构建搭建于监管平台之上、可智能处理音视频的技术系统。针对广播电视播出内容的自动监测系统在近年得到了广泛的研究。文献[4]提出了融合多种技术手段的广告监测的方案；文献[5]针对广告及特定内容的多媒体特征，构建了视频检索系统；文献[6]论述了可自动化完成多路播出节目监测的系统；文献[7]介绍了基于电视自动编目的广告监管自动化系统的设计与实现。然而，现有的成果多针对几十个频道的播出内容进行监测，未能验证在上百个频道监测规模下的有效性；另外与现有的成果不同的是，我们需要综合考虑现有监管平台的技术特点以及内容监管的流程，开发出满足不同用户使用需求、扩展性强的系统。本文设计和实现了面向内容监管的广播电视节目编目系统。本文首先分析了系统需求，随后给出系统的设计方案、部署方案、应用情况，最后得出结论。

2 需求分析

参与内容监管的人员为位于监管大楼的节目编目人员和审核人员、位于全国各地的直属台研判人员，其工作流程如图1所示：

图1：系统工作流程

图1中的工作流程是：1.系统从现有的监测系统同步音视频文件；2.系统自动识别节目，将识别结果提交给编目人员，未识别的节目以空档表示；3.编目人员标记空档，生成完整的节目单；4.审核人员将研判任务分配给不同的直属台；5.直属台研判人员查看任务，筛选节目单的节目；6.研判人员对播出节目进行研判，上报研判结果；7.审核人员审核、汇总各直属台上报的研判结果，生成最终的报表。系统设计需考虑以下原则：

· 系统可长时间稳定运行；

· 系统需要利用成熟、先进的音视频智能处理技术；

· 系统具备强的可扩展性，以适应新的内容监管要求；

· 系统需充分利用监管平台现有的有线、无线、卫星等监测资源；

· 出于成本和安全的考虑，系统需尽可能采用开源的技术框架；

· 系统需为不同用户提供不同的界面，以提高其工作效率。

3 系统设计

基于需求，系统功能结构如图2所示：

图2：系统功能结构

系统分为：1.数据采集存储：包括数据库和存储。数据库记录音视频文件的信息、编目信息、任务信息等。存储保存各监测系统同步的音视频文件，以及模板文件、特征文件等。2.数据分析处理：集成了多项音视频处理技术，提供计算服务。3.表示层：为编目、研判、审核人员提供使用视图，通过界面完成业务处理。下面分别给出这三层功能的详细设计。3.1 数据采集存储的设计

图3：数据采集的存储设计

采集存储设计如图3所示，工作流程是：1.各监测系统的监测前端录制音视频文件；2.监测前端向系统的磁盘阵列写入文件；3.监测前端写入文件完成后，向接口数据库写入录像文件的信息；4.接口数据库以触发器的方式将信息同步到系统的数据库中。设计时考虑的因素有：

· 音视频文件信息保存在接口数据库中后，其它监测系统也可以通过接口数据库访问到存储的文件，实现资源共享。

· 为保证监管业务，每个频道需要至少有两个前端可以向存储回传文件。为此，我们在直属台和监管大楼分别搭建卫星监测前端，互为备份；其余三个系统在全国部署有监测前端，当一个前端存在问题时，可以将文件同步的任务切换到另一个前端。

· 为使各监测系统访问隔离，我们在接口数据库为各监测系统建立单独的表空间，并在磁盘阵列建立不同的文件夹，监测系统只对分配的表空间和文件夹有读写权限。

· 现有监测系统同一频道在不同监测前端的命名和编号方式不同，为此，我们在数据库依据总局批复频道[1]建立标准频道表，并建立其和各监测系统频道的对应关系，保证系统可识别从不同前端回传的同一套频道的节目。

· 磁带库用于定时备份一段时间内的文件。为便于其快速定位需要备份的文件，存储的目录结构设为“监测系统分配文件夹名\年月\日\频道ID\文件名”，这样磁带库就可以依据目录的日期备份该日期下的所有频道的文件。

· 各监测系统中，卫星前端同步的文件数量最多，占全部文件的50%，格式为mp4封装的H.264编码格式；其它监测系统的前端制造厂商不同，回传文件的格式也不同。为在统一格式的前提下，降低转码的工作量，系统仅转码有线模拟、有线数字、开路调频监测系统回传的文件，格式和卫星前端回传的文件相同。

3.2 数据分析处理设计系统通过模版库和音视频特征快速定位相似的节目[7]。该技术有较好的鲁棒性，适合大量的音视频内容检索[4; 7]。系统的模板库包括保存在存储中的模板音视频文件、模板特征文件、以及保存在数据库中的模板名称、属性、模板在存储中的位置、最新匹配时间、是否参与匹配等信息。系统处理包含三个流程：流程A：1.音视频文件同步到系统；2.转码文件；3.提取文件的音视频特征；4.判断该频道全天的音视频特征是否都已经提取完，如果否，则结束；如果是，则进入下一步；5.将全天音视频的特征与模板库的模板特征进行比对，识别节目；6.记录模板最新被匹配的时间，生成带空档的节目单。流程B：1.编目人员对空档进行标注，生成人工识别的节目信息，标记该节目是否生成模板，如果是，则执行下一步；2.依据节目信息的开始时间、结束时间，在存储中定位相应的音视频文件，提取这段时间的音视频特征；3.判断该特征是否在模板库中已经存在，如果存在，则结束；否则，继续下一步处理；4.截取该段音视频，将截取的文件和提取的音视频特征同时入模板库；5.如果为视频，则另外截取该段视频的缩略图，用于预览。流程C：1.定时启动，检查模板库中所有模板最新被匹配的时间，如果该模板最新被匹配的时间较久，则将该模板标记为离线，不再参与流程A.5中的匹配。基于系统的流程，我们设计了以下的计算引擎：

· 转码引擎：完成流程A.2；

· 文件特征提取引擎：完成流程A.3；

· 模板匹配引擎：完成流程A.4-A.6；

· 模板特征提取引擎：完成流程B.2；

· 模板去重引擎：完成流程B.3；

· 音视频截取引擎：完成流程B.4；

· 缩略图截取引擎：完成流程B.5。

流程C在数据库中利用Job定时完成，不再另设计算引擎。为避免单点故障，系统不设专门的节点调度其它计算节点，而是在数据库里建立任务表，记录流程每步的处理状态，计算节点从任务表获取当前待处理的任务，任务处理完成时，更新任务表；此外，不同计算节点处理不同频道的文件，防止节点间的任务冲突。数据分析处理的类结构如图4所示。

图4：数据分析处理主要的类结构

图中的数据引擎、计算引擎、任务调度的功能分别为：

· 数据引擎：从任务表获取待处理的任务，并可更新任务表的任务状态。

· 计算引擎：执行任务，向任务调度反馈当前状态。其中，转码、缩略图截取、音视频截取调用了FFmpeg[8]开源库实现，模板、文件特征提取采用了加速稳健特征算法[9]，模板匹配、模板去重采用了局部敏感的Hash算法搜索特征[10]。后两个算法单独封装，和系统的数据访问、调度隔离，这样就可以随时升级音视频处理算法，而不会影响系统其它部分。

· 任务调度：调度数据引擎和计算引擎。具体工作流程是：

1.系统启动后，依据配置文件，创建多个任务调度对象；2.每个任务调度对象依据配置文件生成特定类型的计算引擎和数据引擎，并读取要处理的频道，调用数据引擎重置任务表对应的任务状态；3.主线程中，系统轮流调用任务调度对象的更新任务列表的函数，该函数利用数据引擎将待处理的任务读入到内存的一个链表结构（List）中。4.每个任务调度对象会创建一个线程，线程从List取任务，调用计算引擎处理任务；5.计算引擎处理完任务时，通知任务调度对象任务处理状态；6.任务调度对象调用数据引擎更新任务表的状态。这里，

· 数据分析处理需要大量的I/O操作，通过创建多个任务调度对象多线程工作，可以充分利用计算节点的CPU资源，提高处理速度；

· 计算引擎、数据引擎具体实现方式和任务调度相隔离，这样引擎可以随时添加、删除、升级而不会对系统其它部分产生影响；

· 通过任务调度工作步骤2，每个计算节点只需部署同一套程序，通过修改配置文件就可以使计算节点具备特定的功能；

· 计算节点上会配置守护进程，计算节点音视频处理进程完成一定量的工作后，会自动停止运行，释放占用内存，防止可能发生的内存泄露引起的系统不稳定；守护进程监测到其停止运行后，会重新启动该进程，使系统能继续工作。

3.3 表现层的设计依据不同用户需求，表现层采用C/S和B/S混合架构。3.3.1 编目界面的设计编目界面实现的功能包括：用户通过选择频道和日期，可以查看、修改编目结果；提供图片墙，用户可以查看前后帧的图片；用户可以通过快捷键可以快速浏览视频关键帧和音频波形。后两个功能需要大量的音视频读取和处理的操作，采用B/S框架难以满足快速编目的要求，因此系统采用C/S框架设计，包括：

· 编目客户端：采用MFC开发，以适应用户windows操作系统使用习惯；分别利用FFmpeg、SDL（Simple DirectMedia Layer）[11]开源库生成图片墙、提供音视频预览；采用TCP Socket和编目服务端交互编目信息。

· 编目服务端：处理编目客户端的请求，读取和更新数据库。

3.3.2 研判和审核人员界面的设计为适应内容监管任务不断变化的需求，界面基于B/S架构设计，这样就可以随时根据需求，调整页面的设计而不需要逐个远程升级客户端；此外B/S架构可提供更加丰富的统计分析与报表的展现方式，并可降低开发成本。为提高响应速度，界面采用了富客户端[12]的技术，充分利用本地机器的处理能力处理数据，减少浏览器和服务器的交互。系统结构如图5所示。

图5：表现层B/S设计

其中，

· 客户端：采用基于Flex的富客户端技术进行页面展现，提供研判、审核、统计分析、节目点播等功能，并通过异步方式和web服务通信。

· 通信：采用HTTP协议，以二进制AMF格式进行通信。相比其它异步通信协议，AMF格式可减少数据传输量，提高系统响应速度[13]；

· 负载均衡：采用权重轮询算法[14]对多个web服务进行调度。该算法可以确保高性能的服务器得到更多的利用率，避免低性能服务器负载过重。

· Web服务：和客户端通信部分采用BlazeDS开源组件，以处理AMF格式的数据；业务处理采用J2EE Spring开源架构，可屏蔽底层实现细节，降低模块间的耦合，简化开发；web容器采用tomcat开源容器，可方便部署。

4 系统软硬件部署

系统的部署结构如图6所示。

图6：系统部署

由于计算节点、存储、数据库有大量的数据交互，因此服务器均部署在监管大楼同一个局域网中，并采用千兆的交换机互联；编目终端、中心审核终端位于监管大楼办公室，通过100Mbps交换机连接服务端；各个直属台通过浏览器远程访问位于中心的web服务，由于直属台只需要点播且当前音视频文件的码率均低于1000kbps，因此直属台和中心的45Mbps的带宽可以满足访问的需求。此外，服务器端安装开源的Linux操作系统，其部署的应用基于Linux开发，减少系统的建设成本；数据库、存储均采用多个服务器进行负载均衡，服务器之间分别利用40Gbps的Infiniband、万兆交换机进行数据交换，以满足大数据量读写的需要。

5 系统应用情况

自2014年试运行以来，系统承担了总局多项监管工作，其处理的频道由最初的39个省级卫视频道扩展到目前的34个购物频道、116个付费频道、56个省级和中央卫视频道、654个地市级地面频道，并先后对全国电视频道的广告、购物短片、公益节目、新闻联播转播等播出情况进行了排查。从2015年1月至3月底，系统平均每月生成编目结果924929条，上报研判结果32950条。采用传统方法，人工需要对1天24小时的节目进行监听监看，轮询全国地市级及以上的播出机构的广播电视频道需要半年多的时间，而采用本系统，可以将时间缩短在1个月之内，对于重要频道可辅助人员在24小时内完成研判报表的汇总上报，提高了内容监管的工作效率。

6 结论

随着广播电视的快速发展，传统的人工监听监看方式难以满足内容监管的需要。基于现有的监管平台，本文设计和实现了广播电视节目编目系统。系统整合了来自不同监测系统音视频文件，实现文件统一、规范的存储；系统可以灵活部署，并可方便的升级数据引擎、计算引擎、音视频处理算法，而不会影响系统的其它部分；系统采用了C/S和B/S的混合架构，满足不同用户的使用需求；系统利用了FFmpeg、Spring、BlazeDS、Flex、SDL、tomcat等开源框架和应用，其服务端部署在Linux操作系统上，可节省实施的费用。系统试运行期间已成功应用于全国的广播电视频道的内容监管任务中，提高了监管的力度和范围。参考文献

[1]国家新闻出版广电总局. 广播电视播出机构及频道频率名录. http://www.sarft.gov.cn/articles/2015/01/13/20150112165534640950.html, 2015.

[2]国家新闻出版广电总局. 管理动态. http://www.sarft.gov.cn/catalogs/gldt/index.html.

[3]董燕, 杨若黎. 广电统一监管平台技术框架研究[J]. 广播与电视技术, 2014, 41(z1): 126-128.

[4]姚正忠, 姜洪臣, 姚舜. 广播电视广告智能监测系统的设计与实现[J]. 广播与电视技术, 2012, (01): 124-128.

[5]杨婧. 基于内容比对的视频检索技术在广播电视安全播出中的应用研究[J]. 有线电视技术, 2014, (02): 87-91.

[6]贺敬华. 广播电视内容自动综合监测系统的总体设计[J]. 广播与电视技术, 2011, (12): 134-137.

[7]王婧. 基于电视自动编目技术的广告监管自动化系统[C]. 中国新闻技术工作者联合会第六次会员代表大会、2014年学术年会暨第七届《王选新闻科学技术奖》和优秀论文奖颁奖大会, 2014: 8.

[8]FFMPEG multimedia system[EB/OL]. http://www.ffmpeg.org.

[9]Bay H, Ess A, Tuytelaars T, et al. Speeded-Up Robust Features (SURF)[J]. Computer Vision and Image Understanding, 2008, 110(3): 346-359.

[10]Kulis B, Grauman K. Kernelized locality-sensitive hashing for scalable image search[C]. Computer Vision, 2009 IEEE 12th International Conference on, 2009: 2130-2137.

[11]Simple DirectMedia Layer[EB/OL]. http://www.libsdl.org.

[12]Fraternali P, Rossi G, Sanchez-Figueroa F. Rich Internet Applications[J]. Internet Computing, IEEE, 2010, 14(3): 9-12.

[13]吴波. Flex异步通信方式的比较[J]. 广播与电视技术, 2012, (02): 133-138.

[14]Xueyan T, Chanson S T. Optimizing static job scheduling in a network of heterogeneous computers[C]. Parallel Processing, 2000. Proceedings. 2000 International Conference on, 2000: 373-382.

编辑：中国新闻技术工作者联合会