协同制作领域的思考和实践

2016-07-22

千禧彩票官方平台副总裁骆萧萧

原文摘自:2016年5月千禧彩票官方平台免费注册国际电视技术研讨会ITTC现场演讲



在2016年5月11日千禧彩票官方平台免费注册国际电视技术研讨会ITTC现场,中科千禧彩票官方平台公司骆萧萧副总裁分享了千禧彩票官方平台在协同制作领域方面的思考和实践。


在全媒体融合生产的大背景之下,节目生产制作与以往相比发生了很大的改变,也对于系统建设带来了很多新的挑战和要求。传统的从2000年开始大量应用的基于数据共享、高低码率文件配合的网络协同制作模式,我们姑且称之为1.0模式,为适应当前全媒体融合生产的特点,千禧彩票官方平台公司提出了协同制作2.0的概念。在此我们将讨论协同制作2.0中的关键技术,并举出几个例子,与大家分享这方面典型的方案。


媒体融合努力的最终目的是把观众留下或者占据更多的观众收视时间。根据15年艾瑞提供的电视收视习惯调研报告,观众观看视频内容的时间是在变长,只是收视终端或者设备发生了改变。通过电视收看的以电视剧和综艺节目为主,互联网电视是电影、电视剧,平板电脑上电影、电视剧、综艺节目为多,手机上观看的主要是视频类的新闻资讯。


不管是在哪个渠道,综艺和新闻这两个节目的收视率都非常高,这两项也是电视台在内容生产过程中可以重点发力的方向。在全媒体融合生产的环境下,针对综艺类和新闻类的节目生产,最核心的问题是实现跨互联网的随时异地协作。与协同制作1.0时代节目生产主要局限在台内生产网的情况不同,当前对于协作的要求是实现跨生产网、办公网、互联网以及外场站点甚至前期设备之间的紧密配合。为此有几个重点的技术问题需要解决:一是跨大地域范围的高效数据传递,很重要的就是视音频,它是大体量的数据,如何能把媒体数据在全国甚至全球范围之内进行高速的传输。二是对于不同编辑格式的使用,这是受网络环境的限制,服务器内、机架间的传输带宽差别很大,扩展到公网上传输能力的差距就更大,如何选用合适的素材格式适配相应的网络传输环境,这也是重要的问题。三是如何实现随时随处的制作,现阶段我们可以做到真正意义上的随时随处,在世界各地任何时间都要有对内容进行生产加工的能力。四是引申出来的问题,因为我们做的是视频节目,肯定会生成故事板,大范围协同生产过程中的交互和管理,包括同构的故事板和异构的故事板之间交互的问题,这些都是协同制作2.0需要解决的核心。


怎么解决这个问题确实需要一系列的技术手段对它进行应对,在这次报告里主要是从五个方面跟大家做一个讨论和分享。


首先是存储架构选择的问题。说到存储架构,我们先从私有云存储讲起。在当前技术发展阶段我们的建议是台内私有云构建存储架构的时候应该选用类似一体化存储的技术路线,它的基本概念,底层物理设备实际是非常简单的PC服务器加上硬盘,对外提供的整个存储空间是由上层软件进行定义的,我们通过一体化存储上面的存储管理软件可以形成对上层应用透明的大的存储池,而这个存储池也可以再做逻辑的区隔,分成不同的逻辑空间,互相之间是完全隔离的,分到不同的业务系统里面去用。


为什么要用这样的架构,我们会利用到存储一体化存储提供的一个非常好的特性,我们叫做数据瞬移或者零秒拷贝的特性。假设台里有不同的制作网,每个制作网有自己的逻辑存储区,当采集新素材的时候会在文件系统里生成一个新的文件记录,同时会占用一定的数据块。当我需要把这个文件共享给其他制作系统继续编辑的时候,在一体化存储里这种数据拷贝的动作是逻辑拷贝,实际数据没有搬移,拷贝的速度是零秒,这样就完成了制作域里高码率视频文件的瞬间迁移,可以瞬间从一个系统逻辑复制到不同的系统,完成共享使用。


一体化存储的体系里,文件的使用,包括文件的删除是自动加锁的。假设一个文件被逻辑复制到三个系统中,只占用一份数据空间,当在某个系统删除此文件时只会删掉文件指针,不用担心实体文件被删掉,只有当我们把所有系统中此文件的指针都删掉时,这个文件数据才真正没有了。


基于一体化存储做不同的编辑系统素材共享的时候,可以带来非常多的方便。比如说集中收录,我们可以建集中收录系统,把系统收录下来的所有内容分到不同的制作网里,空间不多占,拷贝时间零秒,所有的编辑站里都可以看到这些内容。不同编辑的工作站或者非编软件对于媒体文件的命名,包括目录存放规则是有差异的,在传统的情况下就要进行数据真正的复制,匹配这些差异。现在也可以通过瞬间移动来完成对应,因为有了文件的匹配,使得工程文件直接交互,不需要实体文件的拷贝成为可能。


在协同制作2.0体系下公有云存储如何用也是需要考虑的问题。我们的建议是可以分成三个区,低码率及图片区、故事板及字幕文件区、高码率缓存区。


公有云上放低码率文件和图片文件,有两种来源,第一类是基于台内上载的数据同步到公有云,数据可以更好的支撑架构在公有云上的编辑应用,就近读取访问。第二类是很多摄像机,包括摄像机可以挂一个3G、4G传输盒,进行画面拍摄的同时就可以把拍下来的画面压成一路代理码率的数据,直接传到目录云上,上了云以后基于公有云的数据就可以进行后续的编辑、加工和制作。


公有云里会存储故事板文件,包括编辑过程中生成的字幕文件,通过数据同步服务回到台内存储里,实现台内外制作结果的继承。


还有一部分是高码率缓存区。在很多外场制作的场景,外场设备本身有高码率的采集功能,或者是信号采集,或者是介质导入。高码率的数据也希望通过公网快速传回到台内进行后续制作。高码率在公有云上长期存储不太划算,编辑处理效率比较低,但我们可以考虑在公有云上开出一个暂存区,利用公有云存储体系内的网络传输加速功能,数据经过公有云存储跳一下,再跳到私有云存储之内,整个回传效率会比点对点直接把数据打回台内快。在这里我们利用公有云起到了传输加速的作用,但在实际使用过程中也需要具体问题具体分析。如果是跨大地域的数据传输,通常通过公有云存储的加速效果比较好,如果是在相对小的地域之内,公有云存储的边缘节点就不在附近,上去再下来速度也未必快,应该根据实际情况选择传输方案。


第二个重点要讨论的内容是流媒体技术相关的应用。流媒体发展会给内容生产过程中的协同带来很大的变化,发布域很清楚了,主要讨论生产域的变化。摄像机拍摄的画面可以基于流,一般是RTP的流,实时上传或者回传,回传可以直接回传到台内制作,上传可以上传到公有云,对于实时在云存储上收录下来的拍摄流画面,马上就可以开始进行后续的编辑处理。


基于流媒体技术也可以实现公有云素材的直接编辑,通过HLS的协议,不需要把数据下载到本地就能开始编辑加工,也是加速制作的手段。


还有一个比较重要的特性是故事板的远程预览或者远程审片,基于流传输协议或者是SDI over IP等协议,我们可以把故事板编辑过程中相对高质量的画面通过流的方式,从后台运算节点传到前台编辑站点,可以极大的提升在制作过程中的体验。包括我们审片也可以直接基于故事板渲染播出,流输出,审片就可以看到了,不再需要进行打包耗时的操作,这些变化都会大幅度提高效率。


第三个重点讨论内容是协同制作的过程中远程在线的编辑。远程外场的编辑有几种实现方式,远程桌面的方式、后台集群渲染的方式、基于本地渲染能力的方式和基于移动端(手机/Pad)编辑的方式。


基于远程桌面的渲染,前两年做私有云里内部云编辑会用的更多,主要的应用场景是在办公网和生产网之间的打通。目前的传输带宽基于远程桌面虚拟化的方案可能不太适用于在公网上进行编辑,但在生产网和办公网之间实现协同编辑是比较好的成熟方案。具体来看还可分成三种模型。第一种是最传统最典型的虚拟化非编,虚拟机远程桌面访问,整个运算的处理全部在后台,前台只是界面展现。第二种方案里我们把非编的运算渲染和界面剥离,前台运行界面程序,故事板运算在后台服务器上进行,后台把故事板输出的画面通过流媒体传输通道打到前端界面上。第三种是在虚拟化非编的基础上增加了一个回显程序,可以接到后台非编故事板输出的浅压缩画面,在显示器或者是通过板卡SDI上监视器进行回放,给制作人员提供了更高质的监看方案。


由于我们实现了渲染和界面的剥离,基于这个技术的进一步发展,现在我们做出了基于后台渲染模式的BS编辑。编辑界面不是运行在PC机上的CS程序,而是H5的页面,只负责人机交互的工作,后面的数据渲染仍然是通过后台服务器完成的。它最大的好处是不管你编多少层的视频,包括可以编高码率和低码率,最终输出的画面只是一个流,网络带宽占用非常稳定,而且整个的特技处理、字幕处理能力和大非编是一样的。它可以使得BS编辑形成非常强大的生产能力。


还有一类场景是需要本地渲染的,一方面有些本地要导入和制作的素材,同时也要和公有云里代理码率的素材进行配合,这个编辑过程中会形成混编的模式。千禧彩票官方平台的快编软件就是为了满足这类要求而设计的,它可以读本地的存储,也可以读在线的HTTP访问代理码率数据,利用本地的处理能力来完成相应的编辑、运算和特技叠加的功能。


还有一个比较重要的辅助工具就是手机版的剪辑助手,手机操作屏幕有限,能提供的功能相对简单,定位就是快速剪辑,素材标记,记场记的功能,最终的产出可以和台内的系统做有效的对接,形成前端快速打点,后端继承,后续深度制作的协同工作模式。


第四个重点内容是码率自适应技术。与以往基于高低码率套片的方案类似,但现在的数据复杂度越来越高了,而且这些数据有的是高低码率同时生成的,有的高码率在摄像机里存,低码率通过流传过来,匹配的难度会提升。常见的手段包括基于数据库ID的匹配,基于文件名和目录名的匹配以及基于内容分析的视频/音频指纹的匹配。在不同码率混编的情况下,有一种可能是中码率和低码率直接编辑、发布,有些发到微博微信的素材画面质量要求不那么高的情况下,我们可以用这样的码率直接编。包括我们要提取画面的时候,比如提取一个图片,配文字,可以低码率操作,高码率提取图片和文字配在一起,发一个全媒体稿件。


第五个重点内容是故事板的转换和处理。故事板结构的转换和继承在协同制作过程中也是很重要的因素。现在我们讲协同制作不是讲一家的产品,一家的非编协同制作,而是会有各家的非编产品都可以在一个大的资源池里完成制作工作。各家数据存储的结构和工程文件都不一样,我们需要通过规则转换引擎对它完成数据重新目录组织,一体化存储零秒拷贝的优势就可以在这里体现出来。


最后看三个比较典型的协同制作的方案。协同制作2.0的方案有很多种,第一个方案是应对台内采集台外编辑的方案。台内同时生成高低码率文件,把对应的元数据通到公有云上之后,在公有云上可以通过BS编辑,在线直接编也好,手机直接访问编也好,对它进行粗加工,粗加工的结果会生成故事板文件,通过同步服务,同步回台内编辑的过程中,因为这里有一个同ID的对应,可以快速实现高低码率的套片,在台内进行后续的制作。


第二个方案是针对有大量数据在外场现场拍摄的场景设计的,低码率数据在拍摄或采集时直接传送到公有云之上,再同步回到台内。在公网上基于低码率数据进行剪辑创建生成故事板,和存储介质一起回台内之后可以在上载导入的时候实现基于故事板的重采集。此时就会存在高低码率对应的问题,根据实际情况有不同的对应方案,在台内形成高码率的结构。高码率文件的回传除了介质带回之外还可能通过公有云直接传输,通过故事板传输服务,把编辑故事板中使用到的高码率文件通过公网和云加速的方式传输回台内进行后续的编辑。


第三个方案可以看做前两个方案的合集,可以实现台内台外对等协同编辑,既有内网采集编辑,又有外网采集编辑,两边还都有本地高码率存储。内外网系统通过云上的协作平台,完成基于代理码率的制作和针对高码率的内外网同步传输功能。


云计算的发展,流媒体的发展,实现跨网互联的协同制作是大势所趋,存储位置的变化,网络访问条件的变化,不同码率素材带来的复杂度会大于以往,我们的解决之道就是和大家一起在实践中前进,在实践中不断地完善协同制作2.0的解决方案。

相关