视音频监控

关键词： 视听 视音频 节目 系统

视音频监控（精选八篇）

视音频监控 篇1

该系统针对当前我国互联网视听节目传播形态复杂、技术形式多变、节目数量庞大、内容良莠不齐的情况, 在统筹考虑网站地域、网站类型、节目类别、传播影响力、数据采集方式、搜索速度、覆盖范围、系统效率与扩展性等不同监管技术需求的基础上, 建立了互联网视听节目监管技术系统基本框架, 并解决了Web2.0海量信息环境下, 对上百万家网站进行视听节目快速采集、智能分类判别、热点检测跟踪等一系列技术难点, 自主研制了面向互联网视听节目的垂直搜索引擎、内容智能辅助识别、舆情分析、监管效果验证、海量数据优化等技术。

系统采用主动搜索方式, 由境内广泛搜索、境内重点搜索等三个搜索集群以及文本分析、视音频分析、节目下载、数据库、通信等机架式服务器组成, 共包含网站监控、热点信息等43个功能模块共计142个功能项。

系统通过协议、链接特征匹配、JavaScript模拟等多种手段自动增量采集包含视听节目的网页;通过特征解析、地址嗅探等方法完成重点节目的下载;采用正则表达式实现非格式化节目元信息的抽取和格式化存储, 并通过文本关键字、视频摘要、台标识别等手段辅助节目内容智能识别、归类;同时通过热点节目统计、直播端口集成等技术实现舆情分析, 提高对热点事件和突发事件的反应速度。

该系统于2007年8月开始建设, 2008年初正式运行至今, 软硬件运行稳定, 搜索范围超过200万家网站, 平均搜索周期小于48小时, 累计搜索、存储目标网站上各类视听节目信息近2亿条。初步改变了过去互联网视听节目监管工作全部依赖人工查找时效性差、分析力弱、覆盖面窄的缺点, 创新了监管技术手段, 填补了我国互联网视听节目监管技术手段的空白, 为地方广电部门建立互联网视听节目监管系统起到了示范作用, 为维护国家信息安全和文化安全提供了有力支撑。

视音频监控 篇2

【关键词】视频剪辑；后期特效；微电影

一、课程现状

数字视音频技术应用，这门课程主要学习数字视音频剪辑软件Premiere和影视特效合成软件After Effects，要求学生能熟练地操作这两个软件，以掌握视频、音频素材的剪辑处理技术和后期特效合成技术及其应用技巧为目标。

以往本课程教学先讲Premiere软件的使用，加以一些案例让学生练习，比如电子相册的制作，通过这个项目，让学生掌握从视频采集、剪辑、添加特效、添加音频、合成输出一系列视频编辑流程。然后再学习After Effects软件的使用，通过制作栏目片头，让学生掌握影视后期特效合成的各种基本操作和使用技巧，并了解栏目片头的包装技巧和流程。

二、改革目标

本课题旨在通过对《数字视音频技术应用》这门课程的改革激发学生的学习兴趣，在案例项目教授与实践的过程中深入Premiere与After Effects的学习，促进学生的想象力、创造力、统筹能力、表达能力、写作能力、沟通协作能力、审美等综合能力的提高。进而，在成功实施课程教学的基础上，总结经验，并与其他高职院校相关专业分享成果，对本课程的改革与发展起到一定的推广作用。

三、具体改革内容

本课题的具体改革内容以及研究的基本思路主要从以下几点展开：

第一，调整学习内容，从原先以学习Premiere和After Effects等软件的功能应用为主要教学内容，改变为以微电影的主题创作项目引领为主，软件学习为辅的课程体系，使学生对剧本写作、镜头运用、后期特效等方面都有一定程度的了解。

第二，《数字视音频技术应用》本门课程学时的调整，从96学时延长至132学时，对比原本多出的课时，相应地增加分镜头脚本、摄影摄像等内容的学习，旨在加强学生的专业基础学习，为本课程的艺术创作能力及思维拓展培养打下基础。

第三，课程项目创作范围、主题及要求按照浙江省大学生多媒体作品设计大赛DV组的标准来展开，以赛促学也是本课程改革的重要手段之一，通过本课程作业的创作，一来可以检验学生学习的成绩，二来可以为第二年参加省多媒体大赛选拨优秀的学生。

四、实施方案

第一，组织本课程主讲教师进行专业调研，邀请宁波微电影协会行业专家一起讨论分析专业面向岗位、课程设置体系等，完成《数字视音频技术应用》课程标准的制定，包括课程目标、课时安排、教学内容、评价方式等。

第二，具体教学实施，主讲教师对二年级的多媒体专业学生以及大三工作室学生实施微电影创作教学和比赛辅导。

第三，竞赛辅助提高，组织学生参加一年一度的浙江省大学生多媒体作品设计大赛，时间大约在每年的5月～9月。

第四，课程总结及成果展示，包括学生优秀作品展示、课程网站建设、课程资源整合等。建设数字视音频技术应用的课程网站，要求完善教学资料、整理素材资源、展示优秀作品、注重交流互动等。

五、实施方法

第一，教学实施

以项目化、任务化模式进行，按照微电影创作流程安排课时：主题确定、剧本创作、分镜头脚本制作、拍摄、剪辑、后期。

第二，调查研究

① 通过访谈与座谈的方式对数字视音频技术应用课程在国内高校开展实施的进展进行调查研究，如深圳职业技术学院、北京信息职业技术学院等示范院校较早开展本类课程教学的现状、教学实施、课堂效率、成果质量等情况。对比自身专业课程的发展，找到差距，找出问题，分析原因，吸取其经验。

② 通过问卷、访谈与座谈的方式调查本校本专业课程改革前后的几届学生对本课程的反馈，分析比较得出课程改革后的优势。

第三，案例分析

对当前国内外优秀短片电影、微电影进行观摩，对当前国内外高校学生优秀作品进行案例分析。在将微电影创作项目化引入本课程之后，对微电影创作各个环节在本课程教学实施过程中侧重点分配。

六、拟解决的关键问题

第一、由于本课程引入微电影创作项目，使得本课程的知识量大大增加，尤其是剧本创作及分镜头脚本制作、拍摄等模块对学生的要求大大提高。

第二、就本课程对微电影本身的创作要求来讲，如何挖掘作品的深度，引导学生对社会的一些现象、热点问题进行深入的思考并表现出来，是一大难点。

七、总结

我们正处在一个“微”时代，微信、微博在很大程度上取代了冗长的博客的网络统治地位，微电影、微小说等也成为独立于电影、小说的媒体，越来越受到大众的喜爱与重视，手机的功能不再只是通讯，而成为人们生活中必不可少的工具，对“微”时代的形成和发展起了催化作用。在这样的背景下，多媒体专业的数字视音频技术应用课程的改革创新势在必行。

首先，这是顺应时代的需要，学生的兴趣所在。原先单纯的软件学习不能够发挥学生各自的优势，对部分学生来说显得枯燥乏味。改变课程的理念，以微电影的主题创作为主要教学内容，能够让每个学生在合作中找到自己所擅长的位置，发现自己的才能，激发他们的学习兴趣。

其次，本课程的改革对综合性、创新性人才的培养有推波助澜的作用。社会对人才的要求越来越高，不仅仅需要专业技术人才，更需要综合性、创新性人才，高职院校的微电影创作集导演、编剧、摄影、表演、音乐、后期剪辑于一身，提高学生的想象力、创造力、统筹能力、表达能力、写作能力、沟通协作能力、审美等综合能力，也能够引发学生对一些社会现象、热点问题、人际关系等方面的思考。

再者，为学生未來的职业发展奠定基础。数字视音频技术应用课程的改革拓宽了学生发展的方向，今后面向的就业岗位有摄影摄像、视频剪辑、后期处理等。学生毕业后可在各类企划公司、教育行业、广告公司、电视台、网络传媒业等企事业单位从事摄影与摄像、影视编辑与制作等相关的工作。

视音频多路信源集成监控系统应用 篇3

关键词：多路信源,集成监控,应用

1 信号流程、系统结构与监测原理

多路信源信号经过视音频采集卡, 转换为计算机可识别的码流信号, 输入计算机内部存储器, 经过程序存储运算, 以固定格式分别输出至显卡和声卡, 再经过接口转换, 视频以DVI/VGA信号输出至显示器, 音频以模拟信号输出至音箱。每路信源对应一个物理采集传输通道, 每个通道对应一个显示窗口, 每个通道都定义一个标识符号。在程序操作指令下, 顺序执行取样与存储、运算, 将输出结果定向在固定的区间中, 并进行实时动态显示。多画面与单画面嵌套, 并可任意在两者之间进行切换, 形成类似“电视墙”和单屏电视的效果。

2 视音频多路信源集成监控系统的基本功能

2.1 图像/图形监视

分区显示的图像及图形化窗口分布由用户自定义编辑。任意一个电视通道的图像可以全屏显示。当视频信号丢失, 或视频幅度低于阀值, 或音频低于-50d B时, 显示图形/图像的边框为红色, 视频显示区显示“无视频信号”字符。

2.2 音频监听

音频监听由声卡输出至音箱。当单击某个视频窗口或音量柱图形时, 该窗口会出现绿色边框, 表示为当前选中窗口, 声卡输出这路伴音用于监听。

3 视音频多路信源集成监控系统的建立

从硬件、软件两个系统进行设计。

3.1 硬件设计、连接及安装

(1) 信源的物理设计。根据接口类型、阻抗匹配、电平大小等物理特性进行电路设计。视音频接口一般采用BNC口。视频采用同轴线缆, 音频采用不平衡。电平要经过均衡调整。 (2) 根据信源数量多少配置信号采集卡, 配置支持多屏显示的显卡。配置计算机及附属设备。 (3) 根据信源设备的类型进行信号分级。 (4) 对信号源进行连接, 并调试。 (5) 对计算机内部及外部设备进行安装。 (6) 连接多路信源的监测线路至计算机。

3.2 软件系统安装及调试

(1) 计算机系统软件的安装。在Windows XP操作系统下, 安装硬件驱动程序, 配置显示器等外设。

(2) 用户监控软件的编写、安装。根据用户要求编写监控应用程序, 包括数据库、子程序等;配置子单元窗口, 包括以下几个方面。 (1) 频道设置:根据信源的来源, 输出的频道, 编写相应的对话框栏目。 (2) 通道配置:根据信源来源、信源类型、频道编号配置通道的编号及类型。 (3) 显示窗口配置:根据多屏窗口控制台生成的选项卡, 对相应的显示器进行操作。在选项卡上添加并设置窗口属性, 将显示窗口投射到相应显示器上。 (4) 时钟配置:根据用户爱好, 选取时钟的显示窗口格式, 并配置其位置及大小。 (5) 用户权限设置:对不同用户设置不同的权限。 (6) 报警配置:对视频、音频信源的监测质量设置报警门限值, 并配置报表、报警生成参数及报警显示方式。 (7) 切换配置:根据对信源监测质量判断, 设置自动、手动“切换台”窗口。 (8) GSM配置:根据用户管理信息, 对已配置用户设置短信报警类型。

所有子系统配置安装完成以后, 整个系统就可以进入调试运行。

4 视音频多路信源集成监控应用实例

图1是一个实际投入应用的系统。

该计算机集成监控系统监测五套广播电视节目, 接入21路信号, 编入2个通道, 选用24路视音频采集卡。主机采用支持多屏显示功能的显卡, 接入主、辅共三台显示器, 主显作为桌面显示用;辅显作为三套电视节目的9路图像 (V) 信号及其伴音 (A) 信号音量显示, 以及对二套立体声调频广播的12路音频信号分别以左 (L) 、右 (R) 声道音量柱图形显示。同时, 声卡输出接音箱, 提供声音监听。

视音频监控 篇4

1 总体设计架构

视频监控技术主要应用于智能家居和工业生产领域, 本设计是基于Android移动平台实现实时的视频监控终端, 如图1所示。研究内容主要包括以下几个方面:在Android平台下实现与视频服务器的交互及读入监控采集的视频数据;对读入的视频数据解复用和解码, 将解码后的数据进行播放以及播放过程中的视音频同步。整个视音频监控系统的设计可以分为4个功能:模块嵌入式系统模块、视频采集模块、网络通信模块和客户端。

本文完成的主要内容是基于Android平台的移动终端的实现。Android客户端设计参照Android的系统架构可以分为本地框架和Java框架两个部分。功能模块可以细分为UI媒体播放库的设计以及视音频同步模块的设计。按照目前Android技术的软件开发架构还可以将应用的具体实现细分为表现层、业务层、访问层、数据层[5]。

2 客户端的设计

2.1 客户端的介绍

按照Google官网的介绍, Android系统架构可以分为应用程序层、应用框架层、系统运行库层和Linux内核层。本应用是基于C/S结构[6]开发的, IP摄像头通过Wi Fi连接网络[7], 手机通过服务器获取节目列表和对平台进行一定的操作, 采集多媒体信息的工作由高清摄像头和传声器阵列完成, 音频信息和视频信息采取TS流进行传输。其中视频采取H.264格式或MPEG-2格式, 音频采取AAC格式。

2.2 客户端的软件设计

客户端的设计可以分为4层结构, 分别为表现层、业务层、访问层和数据层, 采用面向对象特性进行设计。

2.2.1 表现层的设计

表现层即客户端界面的设计, 采取目前比较流行的fragment作为activity的一部分, 它把自己的layout嵌入到activity的layout中。Fragment Manager提供了对activity运行时的fragment的添加、删除和替换的操作, 使UI的设计更具灵活性, 可以随时退回到后一个界面而不用退出程序 (fragment是从Android3.0开始支持) 。

2.2.2 业务层的设计

业务层的设计主要可以分为解码、渲染和同步部分。业务层从功能上负责视音频解码、解复用以及视音频同步, 同时负责视音频回放和网络解析。视音频的回放不特别说明, 由video类和audio类负责, 从业务层的功能划分来看, 必然会涉及到多线程, 线程间的通信采用共享内存机制 (ndk库支持常用的一些Linux库, 包含线程库) 。而通过jni技术可以将ffmpeg的函数直接绑定到Java层使用, 但是为了避免不停地从C++层返回Java层, 浪费运行时间, 业务层采用纯C++的设计, 采用面向对象的封装、多态、继承的特征设计业务层。以上各个模块的关系如图2所示。

2.2.3 访问层的设计

访问层主要负责各个功能模块接口函数的调用, 客户端对服务器响应的处理, 以及客户端向服务器发送的指令。

2.2.4 数据层的设计

数据层主要负责客户端对SQLite数据库的创建和管理, 负责保存应用的各种配置文件。

2.3 客户端的运行流程

客户端的运行流程包含界面的登录、配置文件的设置、流媒体的播放, 如图3所示。

2.3.1 用户数据库配置

服务器与客户端分别采用mysql和SQLite数据库用户信息进行保存和处理。其中, 用户第一次登录需要配置网址、端口号和账户信息。

2.3.2 媒体库的初始化

媒体库的初始化包括初始化视音频解码、同步模块和队列。ffmpeg库在解码前, 先通过TCP/IP网络接收网址, 解析多媒体信息, 同时解复用, 最后将音频信息和视频信息分别独立开来。本文采取RTSP作为网络传输协议, 由ffmpeg为客户端提供网络服务, 需要对ffmpeg进行必要的初始化, 同时解析出多媒体的头文件以做下一步的操作, 其中由于渲染模块采取Android系统库进行渲染后, 需要对surface进行必要的初始化, 可以让解码后的转换的RGB数据传入Buffer后, 直接进行渲染。

2.3.3 解码和同步

解码采取ffmpeg库进行软解码, 同时在实时播放不流畅的时候采取系统库的硬解码。在Android中, 通过jni技术调用ffmpeg的动态库, 而Stagefright框架集成到ffmpeg里面, 调用过程是类似的, 如图4所示。

同步采取外部时钟进行同步, 保持视频和音频的不脱节。以视频举例, 每次视频播放都会计算下一帧播放的延迟, 如果视频PTS (Presentation Time Stamp) 快于外部时钟则加倍这个延迟, 如果慢于外部时钟则立即进行下一帧的播放。大概的视频同步图如图5所示, 其中delay为当前帧的pts-上一帧的pts。

音频同步的原理更为复杂, 因为不期望每次发生偏差的时候都进行同步如图6所示, 这样会使同步音频多于视频包, 每次处理声音样本的时候, 需要使用一个synchronize_audio的函数来正确地收缩或扩展声音样本, 同时需要为函数synchronize_audio设置一个最小连续值来限定需要同步的时刻, 而“失去同步”意味着声音时钟和外部时钟的差异大于阈值。这样会在同步时得到N个失去同步的声音样本, 为了不失去多个同步数量的差值, 需要计算一下失去同步长度的均值, 而失去同步的长度远和近的声音样本对于加权的平均值的重要程度是不同的, 这时会使用一个分数系数C, 这个系数来自于等比级数的加权平均值, 比如:diff_sum=new_diff+ (diff_sum) ×c;avg_diff=diff_sum× (1-c) , 而c=exp (log (0.01/AUDIO_DIFF_AVG_NB) , AUDIO_DIFF_AVG_NB设为20, new_diff=当前的音频显示时间-外部时钟。

2.3.4 播放视频和音频

目前Android采取主流播放器渲染的机制是surfaceflinger框架里面的渲染机制, 直接调用surface则加快了渲染的速度, 相对于Android提供的图片显示的方式要快很多。音频则用Audioflinger框架进行播放, 耗时相对于视频不是影响系统效率的主要因素。

3 性能测试和功能验证

本监控实验基于Android平板PC和手机, 高清摄像头, 以及一个Linux服务器进行验证和性能测试。

在实验过程中需要移植ffmpeg到Android平板, 借用了Google所提供的跨平台编译器将ffmpeg开源源代码编译成动态库使用。在本实验中主要测试软件播放一帧图像所需要的时间, 分别在不使用任何优化的软件和使用基于Neon优化指令集、硬解码、各种渲染方法的情况下播放一帧图像所需要的时间。

3.1 测试环境

服务器:Intel (R) Core (TM) i3-2100 CPU@3.10 GHz, 2 Gbyte内存;Fedora14 (内核2.6.35.14-106, fc14.i686, GCC4.5.1, GLIBC 2.12.90) 。

客户端:Nvidia Tegra2@1 GHz, 1 Gbyte内存, Android4.0.3, 屏幕分辨率1 280×800。

摄像头:像素800万, 捕捉幅面1 280×720, 分辨率1 280×720, 最大帧数30 f/s (帧/秒) , USB2.0。

传声器:敏感度100~10 000 Hz, (-40±3) d B。

3.2 测试设计

测试分别检验功能的正确性和性能的有效性, 检验功能主要利用日志进行排错, 性能利用系统时钟算取差值, 而经过观察和测试, 视频监控最消耗时间的是在视频解码和渲染视频上。

测试时分别在视频解码和视频渲染函数的前后两个点取时间戳。使用系统时钟函数打印出时间差值传入一个文本里面, 然后使用脚本语言计算出时间平均差值。测试结果采用不同的720p监控视频进行计算, 减少计算的误差。在正常情况下的软件解码, 720p视频解码平均消耗70 ms, 而Neon平均能节省一般的时间, 大约为30 ms硬解码, 也大约节省一般的时间, Neon指令集优化和硬解码可以让计算减为原来的1/4左右, 即使720p的视频也可以流畅地进行播放, 而720p的监控视频一般是24~30 f/s。

720p视频的渲染方式和时间如表1所示。

可以看出大致的时间消耗不大, 渲染方式不是决定性能差异的主要因素, 其中的Private C++API是本文采取的渲染方式, 它主要使用了Android的surfaceflinger框架, 其中调用了Android系统运行库。

至于同步, 测试采用两种方法, 一是对比pts和外部时钟的差值, 二是主观测试同步的质量。测试方法:主观测试1 000次说话 (可以通过观察嘴型得知) , 测试结果是98.3%的说话是同步的, 而第一种方法可以使用广播的电影来测试。视频经过同步模块的调整后, 与外部时钟的差值大概在30 ms以内。音频播放比较稳定, 差值大概在10 ms以内。

视频监控实验的截屏的图像如图7所示。

4 小结

目前视频监控系统的研究很少有涉及到高清图像传输时移动终端实时进行播放监控视频的问题, 本文设计并实现了基于Android的高清图像的远程监控终端, 并且在笔者教研室的项目中已经开始应用。

参考文献

[1]王建新, 杨世凤, 史永江, 等.远程监控技术的发展现状和趋势[J].国外电子测量技术, 2005 (4) :9.

[2]周建良.远程监控系统研究与应用[D].成都:西南交通大学, 2004.

[3]夏建明.基于TCP/IP的远程监控系统的研究与实现[D].西安:西安理工大学, 2005.

[4]马化腾:未来半年仍是Android发展黄金期[EB/OL].[2013-02-15].http://tech.sina.com.cn/i/m/2012-10-19/10297719312.shtml.

[5]张弢, 杨理想.Android远程监控终端应用的研究与开发[J].现代电信科技, 2012 (5) :45-47.

[6]李琴, 陈立定, 任志刚.基于Android智能手机远程视频监控系统的设计[J].电视技术, 2012, 36 (7) :134-136.

视音频转码技术初探 篇5

关键词：转码技术,视音频编解码,DirectShow,主动防毒

0 引言

在电视节目的编辑过程中，越来越多的直接利用外来的数字视音频数据，例如通过互联网回传的节目素材、媒体间通过互联网交换的素材、直接利用互联网中的视音频素材、各种非专业的采录设备(包括监控设备、隐蔽拍摄设备甚至新闻目击者利用手机、照相机拍摄的素材)采集的素材，这些素材虽然也都是数字形式的，但是由于来源复杂、格式多样，往往不能得到目前非线性编辑系统的直接支持。因此，为了更有效地利用这些素材，必须完成这些视音频资料的转码。

目前广电设备供应商可以提供的仅仅是现有各种核心业务网络间的转码工具(如编辑网络和媒资网络、播出网络间的转码服务器等)，其支持格式往往是有限的，基本上没有提供用于素材采集的支持多格式的转码工具。

同时，大量利用通过互联网络传输的素材，必然影响到核心业务网络的安全性。即使在互联网和核心业务网络间进行严格的物理隔离，使用U盘等移动存储设备进行拷贝等方式，也难以杜绝病毒，因为目前的一些格式的媒体文件中同样可以传播病毒，例如，利用Real Player漏洞进行传播的“Real蛀虫”病毒、利用微软GDI+漏洞传播的图片病毒等等。另外，如果在媒体文件的尾部附加一些代码，媒体文件仍可正常播放，而且简单地通过检查文件头的方式来确认文件格式也难以发现这些附加代码，而通过杀毒软件查杀病毒则是被动的，不仅要及时升级病毒库，还要寄希望于未感染最新病毒，因此采用主动的防毒手段是最好的选择。转码就是一种较好的主动防毒手段，因为转码过程就是将源文件解码成为视音频流，然后重新编码的过程，这样即使源文件中含有非法的代码，但因为非法代码无法正常解码回放，因此也就不可能被重新编码至新的媒体文件中去，然后通过网闸等物理隔离设备，指定摆渡文件，就基本可以防止病毒的传播。

事实上，可以利用一些流行的第三方免费转码软件，例如格式工厂。格式工厂号称是万能格式转换软件，几乎支持所有格式间的转码，而且不断更新。但在实际的应用中却发现，即使完成了转码工作，但是也难以保证从转码完成到文件传输完成过程中文件的绝对安全，比如这中间可能需要通过U盘等移动存储设备拷贝，或不同计算机之间的拷贝，拷贝过程及其环境是否安全、洁净都难以确保，因此需要将转码和传输在一个过程中完成，这就需将转码过程嵌入到完成素材迁移的过程中去，研究转码技术十分必要。

1 利用第三方的控制台转码软件完成转码

目前，免费开源的转码器有很多，其中比较著名的有ffmpeg.exe和mencoder.exe两款，这两个都是控制台下运行的软件，即需要在DOS环境下通过输入命令的方式运行，互联网上很多转码软件都是利用它们进行转码的，包括格式工厂等软件。ffmpeg.exe和mencoder.exe除了在命令语法上有些区别外，用法基本相同。

ffmpeg本身是Linux下的LGPL开源程序，但可以在Windows平台下进行特定的编译，生成一个可执行文件，即ffmpeg.exe，当然在其官方网站上也可以直接下载得到它，下载网址为：http://www.ffmpeg.org/releases/。虽然它是一个控制台软件，但它的功能相当强大，包括视频文件截屏、屏幕录制、视音频采集以及绝大多数视音频文件格式之间的任意转换等。以电脑中D盘下flv格式文件“天籁.flv”转换成DVD格式为例，其语法如下(ffmpeg.exe在D盘根目录下)：

ffmpeg.exe-i d:天籁.flv-target pal-dvd-ps2000000000-aspect 4∶3 d:天籁1.mpeg

语法参数在这里不做具体说明，互联网上对此的解释很详细。图1为其运行效果。

Mencoder.exe是Mplayer自带的一个编码工具，Mplayer原是Linux下著名的开源播放器，支持几乎所有视频格式的播放，现在有Windows和Mac两个版本，其下载网址为：http://www.mplayerhq.hu/MPlayer/releases/win32/。mencoder.exe的语法为：

mencoder.exe d:天籁.flv-o d:天籁2.mpeg-oac lavc-lavcopts

acodec=ac3:abitrate=96-srate 32000-ovc lavc-lavcopts vcodec=mpeg2video:vbitrate=6000-vf scale=720:576, harddup-ofps 25

运行效果如图2。

在实际程序设计上，我们采用图形化界面来让用户选择要转码传送的文件并启动转码任务，但在转码过程中把DOS运行界面屏蔽掉，使其只在后台运行，并且获取转码进度信息。这也是目前互联网上大多数转码软件所使用的方法，为了更好的支持更多格式的视频文件，我们把ffmpeg.exe和mencoder.exe都集成到了软件里，程序界面如图3所示。

在程序的具体的实现上，我们用CreateProcess (0, cmd.c_str () , &sa, &sa, TRUE, NORMAL_PRIORITY_CLASS, 0, 0, &si, &pi) 这个函数来启动转码任务，其中cmd.c_str () 参数是ffmpeg.exe和mencoder.exe的输入命令，也就是上面所示例的语法命令;&si参数是指向一个STARTUPINFO结构对象，该结构定义了新进程的主窗口将如何显示，其中wShowWindow属性设置为SW_HIDE时，窗口将不显示，也即屏蔽了DOS窗口界面;&pi参数是一个管道对象，用于获取DOS的输出信息，也就是上面图中的文字内容，这样我们就可以获取到转码过程中的相关信息。

因为程序中调用的ffmpeg.exe和mencoder.exe都是第三方可执行软件，除了DOS的输出信息外，我们无法读取其内部运行信息，所以转码进度是一个比较难以处理的问题。从图3中可以看出，ffmpeg的DOS输出信息中没有进度显示，但是它提供了原始视频的时长，也提供了当前已转码视频的时长，通过计算也可以得出进度。而mencoder的DOS输出信息则直接给出了进度显示，但在实际的测试中发现，该进度并不完全准确，当转码完成时，其显示的不是100%，少于和多于该值的情况都出现过，特别是某一些后缀名为mp4的视频文件，其进度显示一直为0，但实际上转码是一直在进行的。另外mencoder的DOS输出信息只有已转码的时长，但没有给出原始视频的时长，所以也无法通过计算得出。

由于进度显示的不确定性, 用它来判断转码任务是否结束就不十分准确了, 这就必须通过对系统进程和目标文件大小的检查来判断任务是否结束。当转码任务正常进行时, 系统中会有ffmpeg.exe或者mencoder.exe两个进程, 目标文件大小是在不断变化的, 当转码结束时进程自动关闭, 目标文件大小不再变化, 当然, 在转码任务启动失败, 或者遇到不能识别的文件格式时, 其进程也会自动退出, 但是这个时候目标文件大小为0或者是不存在。这样的话, 我们可以每隔一个固定时间去查询进程是否存在, 如果不存在则去查询目标文件大小, 如果为0或者不存在则转码失败, 如果大小不为0则转码完成;如果进程存在, 但目标文件大小连续5次没有变化, 我们判定转码失败, 并强制结束该进程, 但这种情况在测试中一直没有出现过, 但为了防止程序陷入死循环只能当作失败处理。具体的系统流程如图4所示。

可以看出，进度的显示和转码任务结束的判断是两个线程来完成的，对于进度显示不准确的情况，可以最后在转码完成时显示100%的进度以示完成，对于大于100%的在转码完成前都做99%来处理。当转码完成后，传输线程会马上启动，将目标文件传送到指定服务器上，这样也大大降低了感染病毒的几率。

所有外来素材必须转码的一个主要原因就是素材的安全问题。在设计过程中，我们曾做过这样一个测试，用文件合并器把一个视频文件和一个EXE的可执行文件合并成一个文件，顺序是视频文件在前，因为程序读文件的时候是先读文件头，里面会有该文件的类型、大小等信息，如果是可执行文件在前，那么合并后的文件就会被认为也是一个可执行文件而不是视频文件，转码软件自然就不能进行转码，播放器也不能播放该文件。当视频文件在前面时，播放器也能正常播放，转码也正常完成了，而且目标文件大小跟单独的视频文件转码后的大小一样，这就说明，转码器在转码过程中，会丢掉了视频文件中的非法部分, 也就是后面的可执行文件部分，这样来看转码后的目标文件是安全的，转码过程的确可以避免一些病毒的传播。

2 基于微软DirectShow的转码技术

Directshow是微软提供的一套针对视音频数据采集和显示的系统架构，其原来是DirectX家族中的一个成员，而目前已经从DirectX中分离出来，成为Windows平台SDK中的一部分了(最新版本包含在Microsoft Platform SDK for Windows Server 2003 R2中，下载地址：http://www.microsoft.com/downloads/details.aspx?displaylang=en&Family ID=484269e2-3b89-47e3-8eb7-1f2be6d7123a)，而且目前国内的非线性编辑产品基本上都是基于DirectShow的。DirectShow架构被用于全方位的多媒体处理，包括采集、编解码、回放、视音频数据的存储等。DirectShow采用4种主要抽象来操作多媒体数据。这些抽象术语为过滤器(filter)、管脚(pin)、媒体样本(mediasample)和媒体类型(mediatypes)。将相应的过滤器(filter)加入到当前的Graph中，就可完成采集、编解码、回放等工作，当然也就可以完成转码工作。下面以两个例子具体描述一下Directshow在转码中的应用。

1.简单的视音频文件转码实例

有一款隐蔽摄像机，其文件格式为AVI，具体的媒体类型, 视频为MJPG (mediatypes:Majortype:Video、subtype:MJPG、Format:MJPG 640X480, 24 bits)，音频为PCM (mediatypes:Majortype:Audio、subtype:PCM、Format:8000 Hertz, 8 Bits, 1 Channels) 。记者完成采访后，可利用格式工厂将其转码为MPEG2格式的MPG文件，引入非线编中后就可直接编辑使用。但当记者携带移动非编及隐蔽摄像机外出采访，试图利用格式工厂将文件转码为WMV格式，并引入移动非编时，移动非编竟不能识别转码后的WMV格式文件，尝试前文所述的ffmpeg转码，移动非编仍不能识别。为此，我们专门设计了一个专用的转码小软件，成功完成转码，并被移动非编识别。其界面如图5所示。

Directshow中提供了一个工具GraphEdit(缺省情况下其安装目录为C:Program FilesMicrosoft Platform SDK for Windows Server 2003 R2/Bin)，可演示完成每个过滤器(filter)的连接和工作情况，如前文所述的MJPEG文件到WMV文件的转换如图6所示。

这是一个最简单的转码实例，只需通过调用

依次将File Source (Async.) 、A V ISplitter、MJPEG Decompressor、ASFWriter四个Filter加入到当前Filter Graph Manager中，并将相应的Pin连接成完整链条即可。这四个Filter中，File Source (Async.) 是打开并读出源文件的Source Filter, AVI Splitter则将AVI文件中的视音频分离，MJPEG Decompressor则将MJPEG格式的视频流解码为无压缩的视频流，ASFWriter则将无压缩的视音频流重新编码、混合、生成WMV格式的文件。

2.DVD素材采集

节目中经常会用到DVD中的素材，而普通的DVD机都是民用设备，只有模拟输出口，因此直接利用DVD机播放的信号进行采集质量会有所下降。利用Windows DVD Maker、格式工厂的工具也可以完成DVD的转码等工作，但是出于前文所述的为了方便将采集过程嵌入到传输过程中的考虑，我们自己设计了一款DVD素材的采集软件，可以完成DVD的播放、直接录制、打点录制的工作，软件界面如图7所示。

DVD的采集比较复杂，在Directshow SDK中有一个DVD播放的实例，直接使用DVDGraphBuilder完成DVD的播放，即调用DvdGraphBuilder的IDvdGraphBuilder接口下的RenderDvdVideoVolume方法，自动枚举Windows系统中的相应的Filter完成DVD播放。其可能的Filter Graph链路如图8。

如图8所示，DVD Navigator (DVD导航器) 将DVD中的视频、音频及子图片分离，视频及子图片交由视频解码Filter (Microsoft DTV-DVD Video Decoder) 完成解码，Line21 CC信息再由Line21 Decoder Filter完成解码后，交由VMR-9在屏幕上显示，而音频交由音频解码Filter(这里是AC3Filter)解码后交由缺省的音频硬件(一般是声卡)播出。因为Filter Graph的建立过程是自动枚举Windows系统中的相应的Filter完成的，所以由于不同的用户系统中安装的Filter不同，其选择的相应Filter也会不同。另外，由于DVD中视频都是按照MPEG2格式压缩的，但音频却可能是AC3、MPEG、LPCM、DTS、SDDS等多种格式，因此需要根据具体的音频格式选择相应的解码Filter(或者不需要解码)。其实，微软提供了一种音频解码Filter，即Microsoft DTV-DVD Audio Decoder，可以解码任何DVD格式的音频，但它只在使用File Source加MPEG-2 Splitter时才能正常使用，而和DVD Navigator配合，则任何格式的音频都没有声音输出。即使在DirectShow SDK中的实例中也一样，但也有例外，就是Microsoft自己的应用程序都可正常使用，其中的奥秘恐怕只有Microsoft知道了。顺便说一下，早期版本的DirectShow不提供MPEG2的解码器，要想播放DVD必须寻找第三方的解码Filter，至今msdn的帮助中还说Microsoft除了解码器外提供DVD的所有播出手段。目前版本的DirectShow提供了用于DVD的视音频解码Filter，但是还是在音频中留下了一点小秘密。

而我们的目的是在完成DVD播放的同时还要完成转码工作，因此不能使用DVDGraphBuilder，只能自己创建Filter Graph。具体的Filter Graph链路如图9。

比较图8、图9就会发现，多出了两个分支器(Smart tee), 多了一个视频解码(Microsoft DTV-DVD Video Decoder)以及MPEG2的重新编码(Microsoft MPEG-2Encoder)和文件写入(File Writer)。Smart tee将视频或音频有一路输入变为两路输出，以便于在录制的同时可以监看画面(监听声音)。实际上Microsoft提供的Smart tee是难担此任的，其Preview Pin的输出质量非常差，音频断断续续还有输出，视频有可能根本没有输出。所以，如果非常看重监看质量，一定要选一个质量好的第三方分支Filter。但无论如何，文件的写入一定要接入分支器的Capture Pin，以保证录制的文件质量。Smart tee之所以放在视频解码器的前面，是因为如果放在后面，Smart tee的输出需要再次改变格式才能和VMR-9连接，而且只有第三方的Filter才能完成。但Smart tee放在解码器前面，就需要每路输出都要解码，增加了系统开销。音频不存在此问题，因此Smart tee放在了音频解码器的后面。但这里使用了Microsoft DTV-DVD Audio Decoder，不是说它在这里可以用，而是想强调最好能够找到一个解码所有DVD中音频格式的Filter，第三方也有这样的解码器，如果找不到，只有枚举已有解码器根据不同格式分别解决，只是必须动态创建解码Filter，编程难度较高而已。

解码完成后，就可以进行MPEG2的重新编码，写入文件就行了。只是需要调用File Writer的IFileSinkFilter接口的SetFileName设置相应的文件名称和媒体格式。

对DVD的操作DVD Navigator中的IDvdControl2接口都提供如播放、停止、暂停、快进、快退、菜单、音频声道的选择、父母锁等等，也可以实现单帧步进。DVD Navigator中的IDvdInfo2接口中的各种方法可以查询到DVD的当前状态、精确到帧的当前时间、当前Title、当前Chapter等相关信息，和IDvdControl2中的一些方法配合，如PlayAtTimeInTitle，就可实现打点录制。

图9是录制情况下的Filter Graph状态，所播放的视音频同时被录制，在未按下录制键时的Filter Graph状态应如图10，按下录制键后，停下Filter Graph，分别将Microsoft DTV-DVD Video Decoder、Microsoft MPEG-2 Encoder和File Writer加入，连接相应的Pin，调用PlayAtTimeInTitle从当前时间重放。停止录制时，分别将Microsoft DTV-DVD Video Decoder、Microsoft MPEG-2 Encoder和File Writer之间的Pin连接断开，并从Filter Graph中将这些Filter删除，恢复播放状态下的Filter Graph。

目前Windows平台下的所有视音频处理几乎都是基于DirectShow技术的，不仅是前文提到的非线性编辑系统，多数媒体播放器和转码工具都是基于DirectShow，除了前文所述的ffmpeg的基于Linux的开放系统是直接编译获得的控制台软件外，其他都是基于DirectShow。例如格式工厂除了部分直接利用了ffmpeg内核外，也大量使用了编解码Filter，完美解码更是将ffmpeg改写成了基于DirectShow的编解码Filter, 因此我们可以利用各种资源建立自己的万能编解码软件，即建立一个动态的通过枚举系统中的所有可用的编解码Filter来完成所需的转码工作，如果系统拥有足够多的编解码Filter，就可成为真正的万能转码工具。

3 结束语

视音频文件自动技审的检测模板解析 篇6

随着电视节目生产环境向全程网络化、文件化逐步转变, 传统对基带信号进行人工技审的方式, 无论从技术手段还是审查效率, 都已完全不能适应新的无带化制播体系。从节目制作端, 经过打包合成、入库、审片、转码、迁移、播出等诸多环节, 在关键节点部署自动技审, 对数字化的压缩视音频内容验证检测, 实现全台网络环境下的技术质量控制保障安全播出, 是技术发展的必然趋势。

智能化自动化技审的实现程度、技审效率和准确性, 依赖于检测模板的设计。结合台内媒体数据链路的流转流程, 以及压缩视音频文件自身的特点, 本文从三个层次解析数字化后的自动技审检测模板, 逻辑结构如图1。

1 文件结构检测

文件结构 (File Structure) 检测包括对文件头的检测和全文件的检测。文件结构检测的特点是不需要进行解码, 检测速度快。

1.文件头的检测是通过对文件最基本部分的解析, 获取该视音频文件的一些公共信息, 可以包括以下内容:StoredWidth、StoredHeight、SampledWidth、SampledHeight、Display Height、Display Width、视频分辨率 (Resolution of the Video) 、视频色度格式 (Chroma Format of the Video) 、视频帧频 (Frame Rate of the Video) 、亮度和色度的采样分辨率 (Bits per Sample for Luma and Chroma) 、视频取样宽高比 (Sample Aspect Ratio of the Video) 、视频显示宽高比 (Display Aspect Ratio of the Video) 、视频平均比特率 (Average Bitrate of the Video) 、视频格式或视频信号类型 (Format or Signal Type in the Video) 、图像扫描类型 (Picture Scanning Type) 、视频隐藏字幕数据 (Closed Caption Data in the Video) 、视频分辨率变化 (Change in Resolution of the Video) 、视频时长 (Duration of the Video) 、格式专用检验 (Format Specific Checks such as the Profile/Level) 。

2.全文件的检测实际是对文件的物理结构进行检测, 虽然也不需要进行解码, 但需要对整个文件进行读取和解析, 因此比文件头检测要费时。以MXF文件为例, 全文件的检测可以包括KLV结构检测、IndexTableMatch索引表匹配度检测等内容。

除了一些公共信息的检测外, 该部分还可以包括一些个性化的元信息检测, 如AFD值。

1) KLV结构检测

MXF文件的所有数据都采用Key-Length-Value (KLV) 进行编码以获得格式的灵活性和可扩展性, KLV编码标准定义在SMPTE 336M中, Key关键字 (唯一标识符) , Length数据长度, Value数据内容。实际上MXF文件就是若干连续KLV数据包的序列。

KLV的检测从一个MXF的头分区包 (HPP, Header Partition Pack) 或是兰德索引表来定位每个分区包的位置, 并从每个分区包的Key开始, 逐级检测相关的KLV结构, 如图2所示。比如HPP中相应检测首部元数据及索引表等的KLV结构, 对于其中的非KLV数据给出错误提示。KLV结构错误是MXF的严重错误。

2) 索引表与编辑单元的对应检测

索引表按时间索引随机存取MXF文件的内容, 如果你需要存取某个时码处的音频或视频, 可通过索引表获得该时码对应的视音频数据在文件中的偏移地址。

检测按照每个索引表记录的位置, 可以准确定位到每个编辑单元并正确解析出其中的视频与音频数据, 索引表记录的帧类型和时间信息等与实际帧数据相符合。SMPTE 377M-2004的索引表19给出了规范描述。

3.元数据逻辑结构检测。元数据的逻辑关联检测是相对更高层次的检测, 在此之前还需要对元数据合法性进行检测, 主要依据SMPTE377M-2004、SMPTE380M-2004等相关标准。

1) 元数据合法性检测

以SMPTE377M-2004的首部元数据为例, 说明合法性检测项的具体内容, 首部元数据的模式结构定义如下:

元数据模式是一个XML Schema文件, 可以用来对记录中的元数据的合法性进行检测。其中Primer Pack的结构如图3所示。

2) 元数据逻辑关联检测

首部元数据 (Header Metadata) 包含了MXF文件最基本的信息。元数据是与视音频数据结合在一起的辅助信息, 它记录了与节目制作相关的信息, 这些信息在节目制作、传送、复制及播出的各个阶段, 始终与视音频数据密切结合。首部元数据是包含在文件头中的元数据, 它使用面向对象的方法进行封装, 方便和有效地描述数据元素之间的关系。元数据分为结构性元数据 (Structural Metadata) 和描述性元数据 (Descriptive Metadata) 两类, 前者必须有, 后者为可选。

结构元数据用于将文件中不同的元素绑定在一起, 需要对文件的基本结构进行定义, 描述了文件中视频、音频、时码等轨道之间的关联关系, 其逻辑关系的正确直接影响到是否可以准确解码该文件。描述性元数据用于提供诸如节目名称、场景描述等特别信息, 其内容不参与视音频数据的解码过程, 正确与否不影响文件播放。SMTPE的标准字典和规范中定义了大量的元数据类型。

结构性元数据依次包含如下几个部分 (描述性元数据也是通过UID构成一个关系图, 详见标准SMPTE 380M-2004) :

⑴Primer Pack[1个];

⑵Preface Set[1个];

⑶Identification Set[>=1个];

⑷Content Storage Set[1个];

⑸Essence Container Data Set[1个];

⑹Material Package Set[1个];

⑺Source Package (Top-level File Package) Set[1个]。

Primer Pack相当于一个查询表, 里面存储了该MXF文件用到的所有元数据的唯一识别符 (UID, Unique Identifier) , 通过这张表, 可以确定是否有不同的元数据使用了相同的UID。由于MXF的元数据之间主要通过UID进行链接、查找和关联, 从而把线性的物理存储关系变成复杂的树状或网状逻辑关系, 所以保证每个元数据只有唯一的UID非常重要。

Preface Set中主要包含操作模式标识Operational Pattern UL, DMS (Descriptive Metadata Schemes) 标识和视音频数据标识。通过Preface Set可以大概知道文件中存储的视音频数据格式 (比如DV还是MPEG) , 并预先判断出文件结构的复杂度 (比如OP1a还是Atom) 。

Identification中包含公司名称、产品名称、版本号、修改时间等信息, 每次修改MXF文件后, 都会加入新的Identification, 用以记录修改的内容。

Content Storage中主要包含了文件中用到的各种Package (Material Package, Source Package等) 的标识和Essence Container Data的标识。

Material Package和Source Package/File Package数据结构相同, 都是Generic Package的实例。从逻辑上来说, 它们都各自包含了三种轨道, 分别是时码轨 (Timecode Track) , 视频轨 (Picture Track) 和音轨 (Sound Track) 。视频轨和音频轨上可能又会有多个视频或音频序列 (Sequence) , 这些序列对应了实际的源素材 (Source Clip) 。

根据以上的描述, 元数据的检测首先要保证各个Set的UID唯一, 再要保证各个Set的逻辑关系正确。

2 编码合法性检测

编码合法性检查主要是指视音频基本流检测。该部分包括视音频基本参数检测和视音频基本流合法性检测。对于基本流的检测, 与采用的具体编码技术相关, 需要相关厂商的支持, 下面以MPEG-2为例进行说明。

1.视音频的基本参数检测

视频检测参数主要有信号标准、编码格式、码率、类/级、帧率、帧组 (GOP) 结构检测、分辨率、长宽比、颜色格式检测和现用格式描述符 (AFD) 。

音频检测参数包括音频格式、声道数量、采样率、量化精度。

此外还有视音频文件长度检测 (实际长度与标称长度比较) 、视音频是否对齐检测等。

2.视频基本流的码流合法性检测

该检测基本等同于传统码流分析设备进行的检测, 通过合法检测的基本流可以保证被解码器正常解码, 不会出现解码器死机、图像破损的情况。

以MPEG为例, 码流合法性检测参数包括编码标准符合性检测、Profile符合性检测 (Main Profile正确性检测、High Profile正确性检测、Profile 422正确性检测、Profile与编码标准符合性检测) 、Level符合性检测 (High Level检测、Main Level检测、Level与编码标准符合性检测) 、图形格式检测 (图像的宽高、图像格式与编码格式符合性检测) 、交织格式检测。

3 视音频内容检测

1.视频内容客观检测如表1所示。

2.音频内容客观检测如表2所示。

4 结束语

视音频监控 篇7

对话嘉宾:

中兴云计算&IT经营部政企业务市场总监........钱敏

Polycom中国大区副总裁、中国区总经理.........李钢

在当前的IT行业, 云无疑是大家关注的焦点, 在视频会议领域也不例外。在“涉云”的热潮之下, 视频会议的发展也深受影响。本期《通信世界周刊》将与各专家从视频会议角度探讨云计算的应用服务。

复杂IT管理的解放

《通信世界周刊》:

云视频会议能为客户带来什么样的价值和影响?与现有视频会议模式相比, 其最大的区别在哪里, 优势何在?

钱敏:

云的技术对于视频会议的影响可分短期、长期两个角度。

从广义云概念出发, 传统的用户自建视频会议系统可看作企业自建的私有云, 从业务形态上, 已具有云管端模式。例如我们率先帮运营商实现的IMS多媒体会议系统则是典型的公有云的形态, 具备了分布式、自动化的特征, 所以云的概念对视频会议而言, 并不是新鲜词, 它本身就是一个云服务。

从狭义云的角度来讲, 通常是指云计算技术——虚拟化、分布式、自动化、SOA、云安全等作为技术在视频会议中的运用。那么云计算技术如何渗透到视频会议中去, 选用哪些技术来解决目前视频会议遇到的问题, 我认为需要围绕用户体验来进行, 不能盲目为了引入而引入。如虚拟桌面技术, 这是个很好的技术, 虽然可以解决长期以来困扰视频通信软终端发展的穿越防火墙、与电脑兼容性的问题, 但仍然需要攻克的是能不能把其延时降到最低。双向的视音频业务对实时性非常敏感。长远来看, 分布式、自动化、SOA的技术应用让用户开会变得像打电话一样方便。

我们的愿景是让大家随时随地享受身临其境的面对面视频业务, 就如云服务所提倡的随取随用理念, 特别是随着移动宽带、移动终端的发展, 人们期望更佳的用户体验。所以众多厂商也纷纷努力, 如采用H.264high profile编解码, 实现IVVR应用等, 在尽可能节省带宽、降低成本的同时, 使视频会议能够更随时随地的召开, 满足人们对人临其境, “幻”想成“真”的追求。

李钢:

云计算正在改变着各个相关行业的未来发展。云视频技术是云计算在视频服务方面的一种具体应用模式, 通过视频服务的“云”技术, 让用户从复杂的终端设备、硬件维护和难以管理的软件中解放出来, 让这一切复杂的东西交由云端的专业人员与专业的服务器去处理。简单来说, 云视频概念就是让现在的各种终端用户在享用视频体验的时候回归到像打开电视一样那么简单。

更广泛的用户参与

《通信世界周刊》:

在您看来, 云视频会议服务 (将) 为视频通信产业带来的最大改变是什么?

钱敏:

云计算的加入, 可以让更多的人能够享受视频会议服务。虽然视频会议多年保持高速增长, 但真正能应用并享受到该服务的仍是少数, 广大的中小企业还未完全进入这个领域, 很多中小企业仍停留于音频会议, 而这其中最大的收益者将是企业用户。例如刚起步企业, 没能力建设自己的视频会议服务系统, 但可以找云服务提供商来实现, 并且随着将来越多厂商来提供视频会议云服务, 将可能出现更多的企业转向并享受视频云服务。

李钢:

网络环境的日益成熟, 人们对于视频会议的要求也在不断提升, 视觉的舒适性、视频服务的功能全面性已经成为用户选购考虑的首要因素。基于云视频解决方案建设的视频会议运营平台, 将为用户提供更优的音视频、内容共享质量, 提供更全面的视频应用功能。

当前, 云视频运营平台需要支持多种接入方式、支持各种视频、音频终端的接入、支持UC融合, 全方位地为企业用户提供随时随地的“面对面”互联互通。

而云视频核心平台的录播功能将支持高清音频、视频、共享内容的录制功能;支持多路的并发高清录制;支持高清会议直播、多种方式的会议点播及回放功能;提供大规模的录制内容存储及FTP定时上传功能, 提供最稳定可靠的、最全面的录播服务。

与此同时, 云视频解决方案还需要与其他合作伙伴的UC解决方案无缝连接, 提供独特的联合解决方案, 实现视频会议及各种办公系统的灵活应用, 从而最大限度地保护企业的已有投资, 提供更灵活全面的视频会议应用模式。

提升用户体验是关键

《通信世界周刊》:

目前关于云视频会议服务, 业界存在部分质疑的声音, 认为在炒作概念, 对于这种观点您怎样看待?要推动云视频会议服务切实落地, 您认为产业链各方应该需要做出什么样的努力?

钱敏:

事实上没有云概念的时候, 产业已经朝着这个方向演变, 当云的概念开始迅速火热后, 大家便用“云”来包装。

视音频监控 篇8

广州广播电视台数字电视移动演播直播车的系统设计应具备功能完备、兼容扩展性强的特点, 并符合国家有关数字电视标准, 按照数字化、网络化、智能化、模块化的设计思路, 满足安全、完善和快捷操作的直播要求。

广州数字电视移动演播直播车项目主要是配置一台可在移动中实现电视直播功能的直播车, 要求有:电视直播演播室功能;视音频切换、录像、放像功能;电视信号移动传输覆盖;通过可靠技术手段和技术方式在市区范围内实现移动过程中同步传输信号;在发生突发事件时能实时将现场信号传输至与电视台连接的各指挥中心。

该车能实现个性化资讯服务、突发事件信息传输、简单要求现场直播等功能。直播车分为车体、视音频系统、车载发射传输系统、接收回传系统等子系统。本文只介绍视音频系统设计和集成。

2 系统设计和集成

本项目要求配置一套3讯道车载演播室视音频系统, 系统以飞行箱的方式安装, 按照数字电视移动演播直播车视音频系统集成项目技术要求进行系统设计和集成。

2.1 视频系统

视频通路主要分为两大部分, 如图1所示, 一部分以视频切换台为中心的主通道, 另一部分是以16×16矩阵为中心的应急通道。摄像机信号、录像机信号、硬盘录像机信号、字幕机信号、外来经延时器或帧同步机信号和同步发生器信号等分别接入视频切换台和数字视频矩阵, 视频切换台的输出信号和视频矩阵的第一路输出信号经帧同步板和加字幕后, 再经视频2选1开关接入数字视频分配放大器, 它输出4路供给外部接口板SDI输出, 一路供给微波发射机主输入, 一路供给视频矩阵IN12输入, 一路供给车载移动发射机编码器输入, 一路供给PGM监视用。

CCU输出、帧同步机输出、录像机输出、硬盘录像机输出、字幕机输出、延时器输出均可由4联4液晶显示器监看。系统还有跳线排作为主通道和应急通道的信号调配和技术监测, 因此在直播和节目录制过程中可方便地跳开故障设备而不影响正常操作。与此同时, 为了增加系统的安全性和可靠度, 预留增加备份视频2选1切换开关、备份同步发生器、备份4联4液晶监视器的功能。

2.1.1 系统信号源

系统信号源设置如下:

1) 视频系统设计配置3讯道, 包括1台便携式演播室摄像机、1台摄录一体机 (配合万向微波系统使用) 、1台室外摄像机 (安装于车顶) 。

选用1台14 bit标清广播级演播室摄像机BVP-E30P, 适配器选用CA-590P, 控制单元选用CCU-590P, 遥控面板选用RCP-750。该摄像机运用ADSP数字处理技术, 画面质量异常出色, CCD单元采用120万像素POWER HAD EX CCD, 灵敏度达到F11, 水平清晰度达到900线, 信噪比达到65 d B, 调制深度超过80%, 拖尾电平达到-145 dB。

万向微波系统的发射单元采用Gigawave产品, 其发射频率范围为2.1~2.5 GHz, 发射功率为100 m W, 信号传输方向为水平全向/垂直半球, 输入视频信号为SDI/CVBS/BARS, 输入音频为模拟, 平衡600Ω, 嵌入音频, 本机测试1.8 kHz, 整机功耗为18 W, 直流电源来源为摄像机电源/外接电源 (如摄像机电源适配器) , 工作电压范围为11~16 V。信道调制方式为COFDM DVB-T 2k (编码正交频分复用) 。

室外摄像机采用Panasonic的AW-E750MC, 总像素大约为795×596。信噪比为65 dB (开启DNR) 。水平清晰度为850线 (开启DTL, 中央区域) 。配备AW-PH650MC室外防雨防尘云台。配备AW-PB504MC功能卡, 用于SDI接口设备的SDI输出卡。

镜头选用广播级内聚焦数字镜头Fujinon A18X7.6BERM-MC, 其变焦倍率为18X。最小物距为0.6 m。配备半伺服控制系统MS-11。

2) 系统设计配置2台帧同步机、1台带延时器、1块帧同步板用作外来信号扩展。

采用Leitch的X75-DPS575-2帧同步机。其具有模数、数模信号转换, 上下、交叉变换和宽高比变换, 模拟视频信号处理, 自动时基校正, 自动检测多格式 (PAL-B, PAL-M, NTSC/SECAM) , SDTV与HDTV自动降噪等功能。

延时器采用波视TB2000D-EB, 其带宽为6.0 MHz, 视频取样频率为13.5 MHz, 取样方式为4∶2∶2。

3) 录、放像系统设计配置1台3通道数字硬盘录像机, 1台单通道数字硬盘录像机, 1台Digital BETACAM格式编辑录像机 (兼容SP, SX, IMX等格式磁带重放) 。

选用Thomson TURBO-1数字硬盘录像机, 其为广播级3通道视频服务器, 配备使用方便的功能软件。其具有一录两放通道, 操作方便灵活。具有SDI视频输入/输出, 模拟或数字音频输入/输出, 独立的模拟音频单元。可以每路录两通道音频输入, 每路放两通道音频输出。

数字BETACAM编辑录像机选用Sony DVW-M2000P。其数字BETACAM记录格式可兼容重放Betacam/Betacam SP/Betacam SX/MPEG IMX磁带。可记录4声道20 bit数字音频信号。

4) 系统设计配置1台数字字幕机, 要求性能可靠, 操作方便, 适合直播需要。本台选用了大洋电视图文创作系统 (数字型) 。

2.1.2 视频切换系统及周边设备

系统设计切换台为16路输入、8路输出、1级M/E的标清切换台, 切换台主机及面板均要求配置双电源。视频切换台输入有CCU1输出信号、万向微波输出经帧同步机输出信号、车顶室外摄像机输出信号、CCU4输出信号、磁带录像机输出信号、主备硬盘录像机输出信号、字幕机输出信号、外接口板输入经延时器和帧同步机输出信号、同步发生器输出信号。视频切换台输出有:PVW MON信号, 2路PGM信号分别送给2个视频2选1开关, 1路SDI输出给字幕机, 2路SDI输出给外接口板, 2路SDI输出给16×16矩阵。

选用Sony MFS-2000作为视频切换器。其主输入为16路, SMPTE292M (HDTV) , SMPTE259-C (SDTV) 。主输出为8路, SMPTE292M (HDTV) , SMPTE259-C (SDTV) 。具有多格式配置。其利用成熟技术处理高清和标清的视频信号。1 M/E控制面板, 19 in机架宽, 12个直切键按钮, 1 M/E配置提供了2个全功能键和2个下游键, 每个全功能键都可以设置为线性键、亮键、色键和模式键, 并且具有边缘调整和遮挡的功能。由于采用了专门的帧存, 在调整键边缘宽度时不会有任何的键下垂, 功能全面的M/E划像包括增强型划像模式, 并且支持快拍和宏调用。拥有M/E和特技的快拍记忆功能。采用先进的宏调用功能, 可以设计一系列的操作, 进行编辑, 然后设置到控制面板的按键上, 用于今后便捷的调用。

系统设计配置一台16×16标清数字视频矩阵, 主机要求配置主备双电源。该视频矩阵用作信号调度、技术监视, 其中一个输出通道用作切换台的应急备份, 此通道输出端应配置带帧存的键控器。视频矩阵输入有CCU1输出信号、万向微波输出经帧同步机输出信号、CCU4输出信号、磁带录像机输出信号、主备硬盘录像机输出信号、字幕机输出信号、外接口板输入经延时器和帧同步机输出的信号、FNL PGM1、FNL PGM2、F.B1信号、同步发生器输出信号。视频矩阵输出有:1路经帧同步板和键控器给视频2选1开关一的应急输入, 1路给预留的波形监视器输入, 1路给视频2选1开关二的应急输入, 1路给磁带录像机输入, 1路给备份硬盘录像机输入, 2路给监视编码器输入, 4路给画面分割器输入, 5路给外接口板输出。

选用LEITCH的P16X16SRO作为数字视频矩阵。其SDI输入数量为16。信号类型为SMPTE 259M, SMPTE344M, SMPTE 292M Signal Formats (HS only) 。主机具备双电源, 选用所配矩阵1路作为应急通道, 在通道上配置了带帧存和单字幕数字下游键设备。

系统设计周边设备 (包括视音频分配、D/A、帧同步板等) 选用品质高、稳定的国际知名品牌, 采用集成度高、可混插的机箱板卡结构。机箱双电源备份, 安装有散热扇, 可充分散热。设备模块化设计、方便检查和维护。

2.1.3 同步系统

同步信号发生器采用Tektronix的SPG300。它为车内的CCU1、CCU4、帧同步机1、室外摄像机控制器、磁带录像机、主硬盘录像机、备硬盘录像机、视频切换器、备硬盘录像机、16×16矩阵、编码器、帧同步板、键控器、预留波形监视器、主备微波设备提供黑场色同步信号作为同步源, 同时为视频切换器和16×16矩阵提供测试信号, 为字幕机提供数字信号作为基准。备份同步机SPG300通过ECO-4220来实现主用同步机SPG300在故障情况下的系统同步。

2.1.4 监视系统

主监/预监采用广播级8.4 in液晶监视器2台, SDI输入。4 in 4联液晶监视器2台, 模拟复合输入, 用于信号源的监看。8.4 in液晶监视器1台, SDI输入, 用于主持人监看。4画面分割器及37 in液晶监视器各1台, 用于车内壁挂监视器。

2.2 时钟系统

采用模块化时钟设计, 各功能采用模块化方式。时钟系统采用GPS授时控制器的方式。工作区有1U双窗6位时钟显示, 正计时显示和倒计时功能。

2.3 通话系统

系统设计导演区配置1台4通道通话主站, 给摄像机等设备配备对应的2/4线转换设备1台, 如图2所示。采用美国Telex的MCE-325作为4通道通话主站, Telex的SSA-324作为2通道2线/4线转换器。

系统设计无线单向发射机1台, 主持人的单向IFB腰包2套。采用Telex的TT-16无线单向发射机。无线IFB只听腰包选用TR-16。

系统设计无线对讲机系统为中继转发器1台, 双工器 (装入中继站) 1套, 无线对讲机4套。无线对讲系统设计要求能够接入通话系统, 无线通信范围半径大于300 m。中继转发器选用Motorola的GR3118。无线对讲机选用Motorola的GP328。系统配置无线对讲机系统收发天线及安装附件。

2.4 音频系统

系统设计设备与视频系统配套, 符合立体声广播级标准要求。音色应符合专业人员的主观评价要求。系统结构类似于视频系统, 同样由1个调音台和1个音频矩阵为中心的设备组成, 如图3所示。采用稳定可靠的模拟系统, 调音台的音源输入可分为3个部分:第1部分为MIC输入, 1路车内MIC信号, 2路车外MIC信号, 预留1路MIC信号, 它们都以提供现场拾音;第2部分为LINE输入, 1路为磁带录像机输出信号, 1路为外接口板输入经延时器输出的信号, 1路为CCU1 MIC输出信号, 由摄像机提供现场音频信号;第3部分为主备硬盘录像机和外接口板输入经帧同步机输出的音频信号。调音台的输出信号也可分为3个部分:第1部分为监听MON信号, 这部分信号被送至2个监听音箱;第2部分为MIX信号, 这部分信号被送至立体声音频2选1开关, 并送至音频分配放大器, 经分配放大器分配后被送至微波、主备硬盘录像机、磁带录像机、DVD和INTERCOM使用;第3部分为AUX信号。音频矩阵的输入为磁带录像机和DVD输出音频信号。

系统设计采用广播级模拟调音台1台, 模拟输入8路以上, 4个立体声输入, 不少于8个输入物理推子, 具有3个辅助输出。调音台应界面简洁, 操作简便。系统配置1台8×8模拟音频矩阵带面板作为备份。监听采用专业有源监听音箱1对及高质量监听耳机1付。现场拾音传声器2个。

模拟调音台选用英国SOUNDCRAFT的FX8, 具有8路模拟输入, 4路立体声输入, 多声道记录的直接输出, 4个AUX输出, 8个输入物理推子等功能。其拥有专利UltraMic传声器放大器。内置广播级的Lexicon莱思康效果器, 双效果, 可编程, 可修改参数。

模拟音频矩阵选用挪威NETWORK的A0808CP。其为8×8模拟音频矩阵, 机身带面板。

2.5 接口系统

系统设计考虑了与其他系统的级联, 包括视频、音频、Tally、通话、同步、时钟和计算机网络接口。转播车外接口盘视频输入为1路数字外来输入、1路BB黑场信号输入。转播车外接口盘除了配置常规接口外, 还包括1个三同轴接口盘 (该接口可内连CCU, 外连电缆盘上的三同轴电缆) 。考虑到今后的发展和灵活的配置, 外接口盘预留足接口。视频有数字和模拟输入接口、数字和模拟输出接口。音频有模拟输入接口、模拟输出接口、传声器输入接口、综合电缆接口。联络有Tally、通话、电话、时钟和网络接口等。

2.6 飞行箱

直播车内所有设备箱体采用国内知名品牌, 550 mm深6RU 19 in标准机柜箱4个, 550 mm深8RU 19 in标准机柜箱8个, 所有箱体配备相对应的带轮滑板车, 可固定于直播车内。

2.7 系统集成

项目由具有丰富的集成经验、并完成过同等规模工程项目的系统集成项目的集成商完成。系统按3讯道设计, 并预留一路数字万向微波的接入通道。系统安装要求合理、可靠, 视音频电缆、视音频连接器、视频跳线、连接头、音频跳线及工程辅料等均采用国际名牌产品。并与车体改装厂合作良好, 施工工艺精良。要求布局科学, 布线合理规范, 线号清晰。

3 总结

广州数字电视移动演播直播车于2009年5月基本完成安装并进行试用。这一全新的模式开创了电视业界移动演播直播的先河, 在每场移动直播的过程中都得到上级领导的极大关注和指导。一年多来, 本台数字电视移动演播直播车圆满完成了一系列全国各省市党政考察代表团移动直播接待任务, 尤其是在广州亚运会、亚残会火炬在中山传递、佛山传递和广州传递等重大节目中发挥了重要作用, 多次受到上级领导的肯定和赞赏。

摘要：广州数字电视移动演播直播车是一种全新概念直播车, 它完成了全国各省市党政考察代表团来广州考察时的实时移动直播, 并在广州亚运会和亚残会火炬在中山传递、佛山传递和广州传递等重大节目中发挥了重要作用。概述了广州广播电视移动演播直播车项目, 重点阐述了车载视音频系统的设计思路和集成方案。