素材转码

素材转码（共7篇）

素材转码 篇1

1 转码系统概述

随着网络技术的发展及其对于广播电视技术的影响,全台网络技术已经越来越被各级电视台工程技术人员所接受和掌握,越来越多的电视台结合其自身需要和具体特点,将生产、播出和管理纳入到一个高性能、高智能、高安全的计算机网络中,各频道节目生产流程中的写稿、配音、制作、演播室合成与播出均通过计算机网络完成,实现智能化管理、网络化制作、数字化存储和自动化播出。在此背景下,随着全台网络的发展,在电视台网络环境内部各个不同的部门建立了适合于自身特点和需求的视频节目处理系统。但是,当前由于相关规范的不完整性,造成了各个部门所生成视频素材的视频格式、文件格式的不同,因而在各个部门之间进行视频素材应用过程中需要进行必要的策略设计,来实现视频的相匹配[1,2]。

目前转码策略采用集中式数据转码系统,在系统的构建上相对简单,但由于服务器单机处理能力的瓶颈导致了传统单机处理模式不足以应付目前电视台对于视频转码过程中数据处理量大、数目多的现状,并且随着业务的发展,这一集中型转码处理模式也将难以满足数据处理工作量线性增长的需求。因此,在全台网环境中,对于分布式转码需要进行进一步的研究,提出基于全台网环境的高效转码方案[3]。

2 全台网构建转码分析

在全台网中构建转码系统,其实现的关键是各个业务系统与转码模块之间的数据通信以及对于需要转码的视频素材的存储设计,这些因素将是在全台网环境内构建分布式视频转码系统的关键性问题。

2.1 转码传输总线

在全台网环境中,数据交换核心的任务由企业媒体总线(Enterprise Media Bus,EMB)来实现。企业媒体总线EMB为数据迁移服务的执行体,企业服务总线ESB为数据迁移服务控制体,在基于SOA架构设计下,EMB作为ESB的数据执行器使用,它通过ESB的逻辑调用,实现跨系统间的数据迁移。EMB作为全台网中为各个业务系统提供传输服务的核心,在文件传输过程中,根据传输的需要提供对媒体文件转码、整理、校验、合成、技审等服务。构建用于数据交换的全台互连互通系统,能实现全台的异构网络连通,具备一定的开放性,支持MXF,XML等媒体数据和元数据封装格式。

2.2 数据存储

作为全台网环境中视频素材存储和管理核心,媒体资产管理系统能够对全台网各个子系统提供节目素材的存储和共享工作;其他子系统根据存储策略将节目素材或者节目产品传输到媒体资产管理系统中进行集中存储,并通过媒体资产管理系统对于节目素材进行编目加工处理,而且可以进行归档处理。

通过上述对于全台网中数据交换以及数据存储模式的分析可知,目前所采用的数据交互策略和数据存储策略为全台网中集中构建分布式视频转码系统提供了条件。以EMB为核心建立的高速互连互通平台和集中型节目素材存储管理模式,为建立在全台网内部的公共分布式视频转码系统与其他业务系统之间进行视频素材迁移提供了先决条件。

3 整体设计

在公共分布式转码系统的构建过程中,需要一个适合于全台网中视频应用的视频存储环境对视频转码进行视频素材存储,结合以上对于全台网视频存储的分析,媒体资产管理系统一方面可以保证在节目制作应用中在视频素材的检索、视频存储等方面的应用,可以为公共视频转码系统提供物理存储媒介和检索管理工具;另一方面,作为EMB数据总线上的主要业务系统,其与其他业务系统之间建立了高效的数据通信通道,这也就为公共视频转码系统与其他业务系统建立了数据交换平台。

分布式视频转码系统依托于全台网中媒体资产管理子系统,在制作需求和播出需求的过程中,当用户需要制作视频素材时,系统直接在媒体资产管理系统中检索出相应的视频素材。当检索命中后,制作终端向媒体资产管理系统提交所需要的视频文件信息以及所需要的视频格式,如果原始视频格式符合制作需求,视频直接迁移到制作终端进一步处理;如果视频格式不符合要求,媒体资产管理系统则将视频素材迁移到分布式转码系统内部进行分布式转码操作,并将已经转码完成的视频素材迁移到制作终端。在播出需求条件下,各个业务系统将需要播出的视频素材提交后,直接迁移到分布式转码系统中进行对应于播出格式的视频转码,在视频转码完成后,通过EMB传送到硬盘播出系统的二级存储体等待播出指令。同时,原始视频素材迁移到媒体资产管理系统中进行存储。系统设计结构如图1所示。

4 分布式转码系统的实现

基于以上对于全台网结构的分析,结合实际的用户需要,本设计采用分布式系统Hadoop[4,5,6,7],实现了基于全台网的分布式转码系统,系统结构如图2所示。

对于全台网环境中的节目转码系统的实现,在设计过程中借鉴了传统分布式计算系统的实现方案,在系统的构成上由处理响应端以及分布式处理集群组成。处理响应端主要是接收终端或者是全台网中其他业务子系统所提交的视频转码请求和转码参数,并用来接收迁移的视频素材文件,下发到分布式处理集群进一步操作。在分布式集群中,NameNode角色负责接收处理响应端所接收的用户转码处理请求,并调用与NameNode角色相对应的DataNodes进行节目素材的视频转码存储和存储管理等操作。

系统对于用户转码请求的处理过程在实现步骤上主要包括以下几个方面。

1)视频请求响应

分布式转码系统在全台网环境中,接收到用户通过其他业务系统所发送的节目素材处理请求后,分布式转码系统的处理响应端对于用户提交的请求进行响应,通过数据总线以数据迁移获取节目素材文件,并根据用户提交的转码请求数据建立视频转码处理任务,将数据处理任务加入到分布式转码系统的任务调度队列中。

2)视频切割

在分布式计算过程中,各个分部节点进行单独的视频转码操作,因而都需要单独处理视频文件片段,故在存储视频文件时需要对于节目素材文件进行切割。在视频切割方法上,设计采用时间分割法。在实现上,根据视频时长以及系统中DataNodes数量设定时间标签,之后遍历节目素材文件,依据时间标签截取特定时间标签内的所有帧,并通过FFmpeg实现的程序检验视频切割点的精确位置,进行节目素材块的切割,将单一的节目素材视频文件切割为多个节目素材块进行分布式处理。

3)分布式转码

在转码的实现上,系统采用分布式处理框架Hadoop。在分布式处理调度过程中,NameNode分发已经切割的节目素材块,并向组群中各个DataNodes角色分配任务;DataNodes角色负责实际转码任务的执行,转码任务、存储任务以及寻址任务等操作。在DataNodes节点进行节目素材块转码处理中,为了节省在文件传输过程中对于带宽的需求,在处理模式上尽量把计算任务分配在数据块所在节点的DataNodes中,以流的方式打开,在节目素材文件流中,通过程序控制将需要转码处理的视频流从文件流中提取,同时获取视频格式信息,应用FFmpeg取得视频解码锁需要的视频解码器对于视频进行帧解码;之后根据用户提交的任务信息通过FFmpeg取得转码目标格式的视频编码器,对于视频进行逐帧的视频编码,实现对于节目素材块的编码处理过程。

4)素材整合和素材迁移

分布式转码完成后,NameNode获取各个DataNodes节目素材块的存储地址,通过FFmpeg对于各个节目素材块根据原始视频顺序进行视频整合,并向处理响应端返回整合后的节目素材文件地址。处理响应端直接调取视频文件所在位置,获取视频文件,并根据用户提交的请求,将视频素材文件迁移到对应的业务终端或者是业务系统中,进行下一步应用。分布式转码处理流程图如图3所示。

5 总结

通过本项目的设计,在全台网环境内建立一个公共的视频素材转码业务系统,借助于全台网数据总线的高速率数据传输优势,并结合媒体资产管理系统对于视频素材的高效便捷的存储、管理手段,可以有效地解决传统单机视频转码所带来的效率低下、相对成本较高等问题,提高视频素材的处理能力,实现全台网技术与云计算技术的优势共享,促进广电电视播出技术的进一步发展。

参考文献

[1]李卓,孙滨.郑州电视台高清网站点建设与媒资交互结构设计[J].河南科技,2012(1):55-56.

[2]樊俊,孙亚清.电视台全台网建设实践与探讨[J].电视技术,2011,35(10):39-42.

[3]岳永胜,王朝坤,刘璋,等.基于云架构的视频转码技术研究[C]//2011年全国高性能计算学术年会(HPC China2011)论文集.北京:中国软件行业协会数学软件分会,2011:1-10.

[4]杨帆,沈奇威.分布式系统Hadoop平台的视频转码[J].计算机系统应用,2011,20(11):80-85.

[5]谢桂兰,罗省贤.基于Hadoop MapReduce模型的应用研究[J].微型机与应用,2010,29(8):4-7.

[6]崔杰,李陶深,兰红星,等.基于Hadoop的海量数据存储平台设计与开发[J].计算机研究与发展,2012,49(S1):12-18.

[7]张浩,孙淑霞.Hadoop云计算平台在视频转码上的应用[J].电脑与电信,2011(12):36-37.

视频转码研究综述 篇2

关键词：转码原理,转码体系结构,转码技术,转码算法

1 引言

在通用的多媒体访问中, 终端的数据处理能力和显示能力不同, 接入网的带宽、误码率和丢包率等信道特性不同, 用户的感兴趣内容不同, 因此, 传输的数据需要动态地适应用户环境的变化。转码正是解决这一问题的重要技术之一。转码还可用于在压缩视频流中增加公司标识、水印以及抗误码特性, 数字视频快进、回放等模式的支持和视频点播等方面。

2 视频转码含义

从狭义上讲, 视频转码是指将视频数据从一种格式转换为另一种格式, 格式包括编码标准、码率、帧率和空间分辨率等。视频转码既包括按相同的视频编码标准压缩的码流间转换 (以下简称“同构视频转码”) , 也包括按不同视频编码标准压缩的码流间相互转换 (以下简称“异构视频转码”) 。视频转换编码, 简称转码, 是指视频从一种格式到另一种格式的转换, 其中格式是由码率、帧率、空间分辨率及编码语法所表征。

从广义上讲, 所有对视频流的操作都可被视为视频转码, 例如在视频流中嵌入图标、水印信息以及加入差错抑制特征的数据等。视频转码近年得到了广泛的重视, 在IEEE等权威期刊和国际会议上已有较多的文献。

视频转码实现了编码、存储和传输、解码的分离, 使得压缩后固定格式的多媒体数据能够被灵活地传输和访问, 其主要目的就是使得异质网络之间、不同的接入设备之间以及不同视频数据格式之间能够互相兼容。

3 视频转码原理

最直接的视频转码方案就是将一个视频解码器与一个视频编码器进行直接的级联。视频解码器首先将输入视频流完全解码至空域 (像素域) , 然后利用视频编码器将解码后的图像根据分辨率、码率、编码标准等要求进行重新编码。直接级联的转码具有非常高的计算复杂度, 而且解码与编码的级联通常会给图像质量带来额外的失真。因此, 转码研究需要考虑包括计算复杂度、存储复杂度、视频质量和转码灵活性等多种因素影响下的最佳折中。与一般的视频编码不同的是, 原始的视频码流中己包含了第一次编码时的信息, 这些信息往往反映了原始视频序列的部分统计特性, 如:纹理状况、运动趋势、场景变换等等。视频转码在解码的过程中可以得到这些信息, 并可利用这些信息来加速和优化编码过程。目前的视频编码框架均是通过对直接级联转码结构上进行部分简化和模块合并建立起来的。

4 视频转码的体系结构

4.1 空域转码

空域结构的转码器 (sDTA) 在编码端和解码端各有一个环路, 使得两者能独立地、无漂移误差地工作。它支持不同码率、帧率、分辨率以及标准间的转换。这种结构的转码器也存在缺点, 就是运算复杂, 不支持实时性业务。因此, 在实际的应用中可根据实际需要去处某些模块以达到提高运算效率的目的。

4.2 频域转码

考虑到DCT/DICT是线性运算, 因此空域转码模型可以等价地用一种结构更简单的频域转码模型来代替。与空域转码模型类似, 当视频序列的分辨率不需改变时, 频域转码模型也可作进一步的简化。在频域转码结构中, 变换和反变换被省略。相应地, 运动补偿在频域中进行, 并只需要比空域更少的运算量。

频域转码结构减少了运算复杂度, 但仍然存在一些问题。尽管从理论上DCT/DCT是线性可逆的运算, 但由于系数精度和截断的影响, 产生了非线性的因素, 同样, 在亚像素运动补偿插值中, 也会出现非线性的操作。这使得频域转码不可避免地会受到“漂移误差” (drift eorr) 的影响。

4.3 混合转码

空域转码结构具有较好的转码性能, 并不受漂移的影响;频域转码结构可以有效地减少运算量。混合转码框架基于此, 利用两种结构的组合, 可以有效地达到速度和质量的折中。

5 视频转码技术

5.1 模式选择

视频转码中的宏块模式选择主要处理以下两类问题:转码前视频标准里定义的一些宏块模式是转码后的标准里没有定义的;在降低分辨率的转码中, 使转码前的多个宏块在转码后就成为了一个宏块。

5.2 重量化

在视频转码中, 重量化通常在频域转码结构中用于降低码流比特率, 进行比较粗糙的码率改变。重量化是进行码率控制的一种重要手段。

5.3 码率控制

视频编码中码率控制的关键问题在于如何在给定的应用环境限制 (如信道带宽、时延等) 下, 通过确定量化参数来达到最佳的图像质量。和模式选择、运动估计一样, 码率控制的方案并不影响编码器与解码器之间的匹配。

6 视频转码主要算法

6.1 同类视频转码

同类视频转码指把同一种编码标准的视频数据流从适合某一传输环境的压缩形式转换成适合于另一传输环境的压缩形式。转码器中主要有四大模块, 即编码模块、解码模块、图像尺寸变换模块以及码率控制模块。主要有空间分辨率转码、码率转码以及运动矢量重用等算法。

6.2 不同类视频转码

为提供不同视频压缩编码标准间的互操作性, 需要将视频压缩码流从某一种压缩标准转码成为另一种视频压缩标准的码流, 称为不同类视频转码。这种转码可以为不同条件的网络间提供透明的连接, 一般用于具有相似压缩算法的标准间的转换。不同类视频转码器的设计思想是在充分分析不同标准间异同的基础上, 采用类似于同类码流间视频转码的结构和算法来设计、研究视频转码的基本结构。

7 视频转码应用展望

视频转码技术对压缩的视频码流进行端到端的处理, 使得转码后的压缩码流更能适应传输信道带宽以及接收端的要求。视频转码技术能够灵活地支持多种媒体格式, 并且具有较高运算能力、低成本和灵活等的特点, 它已成为数字多媒体服务发展的一项重要技术。

视频转码技术在未来几年还将是数字媒体网络网关的关键技术和应用热点。首先, 不同类型的转码都可能满足特定的要求, 动态地确定一个优化的转码策略是一个有待解决的优化问题。它需要根据视频转码的特点和率失真理论联合优化比特分配和缓冲区控制问题, 以在转码质量、有效性、可靠性及安全性等方面取得最佳平衡。其次, 视频转码质量的客观评价研究较少, 特别是如何将人眼的主观评价及不同的约束条件融入客观评价过程值得研究。

随着各种新的视频编码标准的制定、计算机软硬件技术和网络技术的发展, 要有效地解决同一框架内部和不同框架之间的视频转码问题, 就需要从转码基础理论出发, 建立一种通用的视频转码框架。在这一方面, 视频转码在理论研究和应用技术方面仍有许多工作要做。

参考文献

[1]杜辉.数字媒体视频转码技术研究[J].新闻界, 2008, 5 (10) .

[2]S.-F.Chang, A.Eleftheriadis.Error accumulation of repetitive image coding[J].IEEE International Symposium on Circuits and System, 1994, 11 (3) :201-204.

[3]Ishfaq Amad, Xiaohui Wei, YuSun.VidcoTranseoding:An Over-viewof Various Teehques and ResearehIssues[J].IEEE Transac-tions on multimedi, 2005, 7 (5) :793-804.

基于云计算框架的视频转码系统 篇3

在通常的视频服务访问中,播放终端的数据处理能力和显示能力不同,网络的带宽、丢包率等信道特性不同,因此视频的编码需要根据这些客观条件进行相应的转换,从而保证用户的正常观看,视频转码正是解决这一问题的关键技术。常见的视频转码方案分为硬件转码和软件转码两大类。前者主要应用于对转码延时敏感、稳定性要求高、输出格式相对固定的场景中,如视频直播流的转码,一般采用专用的ASIC芯片或FPGA可编程器件,输入输出格式和参数很难改变,每台设备通常能够支持4～8路直播流的转换。后者主要应用在对转码延时和稳定性要求不那么高、输入输出格式复杂的场景中,如基于视频文件的转码或者非广播级质量要求的直播流转码。从目前视频服务的主要应用而言,由于点播类(VOD)的应用比重较大,因此软件转码方案是业界的主要选择。

从软件转码器所依赖的计算平台来看,视频转码软件的实现从最初单纯简单依靠单个CPU的通用计算能力,发展到利用CPU的多功能指令集(如MMX、3D Now、SSE等)。但在经历了CPU核心的计算能力快速提高的阶段后,单个核心的计算能力已经接近瓶颈,而人们对视频质量的需求却与日俱增,从最早的VCD(分辨率352×288,码率约1.5Mbps),到标清DVD(分辨率720×576,码率约4.5Mbps),再到高清蓝光(分辨率1920×1080,码率约25Mbps),使得相应的转码复杂度也大大增加。随着多核计算机和并行计算思想的普及,视频转码的并行化成为大势所趋。

利用多线程技术,视频转码可以充分发挥多核CPU的并行处理性能,实现图像组级的、帧级的、片级的或宏块级的并行策略[1,2,3,4],但这种方法依旧受制于单机的CPU数量或转码算法本身的并发能力,使得并发率上升较为有限。采用分布式计算机集群,以单个转码任务为最小粒度的并发调度机制,可以增加系统整体的吞吐量,也不受制于转码算法,但是无法提升单个转码任务的转码速度。本文利用云计算的“Map-Reduce”计算框架,将单个转码任务并发至多个计算节点,每个计算节点同时对同一个视频文件的不同部分分别进行转码,分段转码完成后系统再将转码后的视频文件合并,完成单个转码任务。该系统的并发能力不会受限于单个计算节点的物理条件和转码算法,具备较大的并发能力提升空间,可以显著提升单个转码任务的速度。

1系统架构

“Map-Reduce”[5]是一种适用于TB规模以上数据量的并行运算框架,“Map”(映射)是一个将大任务拆分成多个独立的小任务,并使它们可以平行地映射到多个节点的过程,“Reduce”(化简)是将节点独立的小任务完成并将其合并的过程。在本文提出的转码系统由以下几部分组成:存储系统、任务调度、码流预处理、码流后处理、码流分割、码流合并、转码节点。其中,“码流预处理”和“码流分割”实现了将大段视频码流拆分成多个独立的小段视频码流的过程,称为“映射器”(Mapper);“转码节点”、“码流合并”、“码流后处理”实现了小段视频码流转码、合并和复用的过程,称为“化简器”(Reducer)。系统整体架构如图1所示。

存储系统主要是用于存储用户通过视频接收接口提交的待转码视频,以及转码系统成功转码后的视频,用户可通过内容发送接口获取视频和相关信息。

任务调度是转码系统的核心,它负责管理系统内的所有计算资源,当它发现有新的转码任务到达时,它首先根据该任务的优先级以及当前系统的可用资源,分配适当的计算资源依次去完成码流预处理、码流分割、转码、码流合并、码流后处理这几个步骤。

码流预处理需要对用户提交的待转码视频进行分析,解析文件容器,按照用户定制的转码需求进行码流解复用,实现视音频码流分离。

码流分割按照任务调度模块的指示,将指定的视频码流(由于音频转码的复杂度远远低于视频,因此音频码流不做分割,直接转码)分割成段(打出入点标记,不生成实际的物理文件),分割时需要考虑转码后合并码流的图像连续性,避免产生跳帧或重帧等现象。

转码节点根据任务调度模块的指令,读取特定的分割后的视频码流段(或完整的音频码流),根据用户设置的转码参数完成转码过程。转码节点上需要安装编解码库,编解码库以插件的形式的部署,使得每个转码节点支持的码流格式具有可扩展性。

码流合并是码流分割的逆操作,其主要目的是将转码后的视频码流段重新组合到一起,形成完整的视频码流,保持原始的码流先后顺序。

码流后处理对转码合并后的视频码流以及转码后的音频码流按照用户指定的文件格式进行复用,生成成品文件。

2任务调度

当任务请求到达后,任务分析根据任务的属性将任务分为“非紧急任务”与“紧急任务”。非紧急任务带有可量化的优先级标记,进入任务队列后依据优先级进行排队,在任务队列中的任务优先级会随着在队列中的时间的增长而提高,这样可以防止“饿死”的问题出现,即某个较低优先级的任务由于一直排在较高优先级任务后面而一直无法得到转码服务。

紧急任务具有非常高的优先级,可以绕过一般的任务队列,直接请求计算资源以完成转码。在可用计算资源不足的情况下,可以通过调度将其他正在进行的非紧急转码任务暂停,腾出足够的计算资源服务于该紧急转码任务,保证紧急转码任务在较低的时间内完成。

转码系统内的所有计算节点都要向任务调度模块以心跳信号的形式汇报自身状况,包括当前负载、任务优先级、任务执行进度。资源调度一方面通过节点监控传达的信息,得到集群的负载分布,再根据节点计算能力库中存储的信息,得到实时的集群可用计算资源分布情况;另一方面根据任务情况(紧急任务和非紧急任务队列),调配可用的计算资源。当新任务的优先级特别高时,任务调度模块可以暂停集群中优先级较低的转码任务,将更多的计算资源集中起来服务紧急的转码任务。最终,形成一系列的控制命令发给节点控制模块。

节点控制执行由资源调度模块发来的节点控制命令,使计算节点执行、暂停或恢复某个特定任务,包括码流预处理、码流分割、转码、码流合并和码流后处理,控制命令除了执行、暂停和恢复基本操作外,还指定了任务的输入和输出,以及相关的参数设置。

节点监控接受从所有计算节点发来的心跳信号,心跳信号包含节点当前负载、当前执行的任务优先级和进度或结果,将这些信息汇总后形成集群负载分布报告,提供给资源调度模块。一旦转码节点因为软件或硬件故障导致心跳信号中断,或转码失败,任务调度模块及时回收该转码子任务并重新调度,直至所有转码子任务成功结束。

3视频拆分

视频码流中的图像组GOP(Group Of Pictures)是由一系列连续的图像组成的,每段视频码流包含了若干个连续的图像组。每个图像组至少有一个I帧,并且I帧处于图像组的开头。I帧可以独立解码而无需依赖其他帧,因此一般说来,一个图像组内出现的错误最多延续至下一个I帧。在视频文件分割的过程中,图像组级别的粒度比较适中,相比单帧的粒度而言,有更好的解码独立性;相比一整段完整的视频粒度,有更好的转码并发性。

因此,在视频文件拆分的过程中,需要对码流的图像组结构进行判断,分别针对Open GOP和Close GOP的情况采取不同的分割策略,即Open GOP时需要对每一段分割码流片断的前部增加一个GOP的冗余,保证解码器能够解出这个片断中的所有帧。同时在进行分割时还要记录下分割策略的选择情况,供合并程序参考使用。视频文件分割的流程如图3所示。

如果拆分点后的第一个GOP 是Close GOP,就不用考虑其他策略,即在拆分点将视频分为前后两段,不会使其中一段视频无法解码。反之,如果拆分点后的第一个GOP 是Open GOP,就需要使后一段视频前多加一个GOP。

另外,视频拆分中还有一点需要注意的是,对于解码器而言,每次对一段视频进行解码时,都要先寻找该段视频中的序列头信息。然而,通常一整段视频可能仅在开始处包含一个序列头,也可能在每个GOP 前都附带有相同的序列头,这要视码流而定。这时,若碰到前一种情况,则需要在拆分之后的每一段子视频前都添加上序列头,以保证解码器的正常运行。如果碰到后一种情况,那么就在拆分时将每个序列头都视为GOP 结构的一部分进行整体分割。

4实验结果

4.1实验环境

为了测量本文提出的转码系统的性能,我们将其部署在一个计算机集群上。该集群采用千兆以太网进行互联,以满足集群节点间大量的IO访问(读取待转码文件、生成临时文件和最终视频文件)。每个集群节点的基础硬件配置为:双4核CPU,主频2.8GHz,6M缓存,8GB内存,存储服务器的硬盘容量为2TB,其他计算节点的硬盘容量为137GB。在软件配置方面,部署Windows 2003 64bit操作系统,使用ffmpeg(版本为0.8)来完成码流的预处理、合并和后处理,使用x264(版本为0.116.2057)完成单段视频的转码。码流分割、任务调度程序以及每个节点上的心跳服务程序用Visual Studio 2008开发。存储服务器、调度服务器、码流预处理及分割服务器、码流合并及后处理服务器各占用1台物理机,转码节点共有5台物理机,整个集群有9个节点。图4为实验环境图。

4.2单个视频实验

我们先将一段时长约20分钟、码率为50Mbps的高清1080i的MPEG-2测试视频转为10Mbps的H.264,考察在不同计算节点数量的条件下系统的转码速率。

如图5所示,当转码节点只有1个时,转码任务未被拆分并分散至该集群上,只能单纯依靠在单个节点上的多线程并发,由于输入源视频的码率很高,转码的复杂度大,单个节点的计算能力有限,转码时间远远超过视频时长(在图中用红色水平虚线表示)。随着转码节点的增加,转码任务被拆分,转码所需时间大幅度降低,当转码节点数达到4个时,转码所需时间已经低于视频时长,意味着实现了高清视频的超实时转码。

当然,由于视频的拆分、合并都会带来一定的开销,使得转码速度的提升和转码节点数量的增加不会呈线性关系,但总的说来,这个基于云计算框架的转码系统极大拓展了转码速度的提升空间,而且,单个节点能力的提升(转码算法改进、CPU核心数增加)并不制约系统整体的性能提升。

4.3多个视频实验

我们再将一批总计约50小时(75个文件,约1.1TB)、码率为50Mbps的高清1080i的MPEG-2测试视频转为10Mbps的H.264。如果将这一批视频转码当做一个单独的任务来看待,那么衡量系统完成该任务的速度可以用“吞吐量”这个指标来考察,当系统架构和核心算法未改变的情况下,系统和外部的吞吐量越大,总体处理时间越短。而如果将每一个视频文件的转码都当做是一个单独的转码任务来看待,我们可以用“超时率”这个指标来考察系统的性能,其定义为:超时率 = 视频时长 ÷ 转码时长 – 1。当1个小时的视频用1个小时转完,其超时率为0,即实时转码;超时率为负意味着实现了超实时转码。我们通过调节任务并发数量(即一个视频文件用多少个转码节点进行转码)来观察该转码系统的性能能力的变化情况,结果如表1所示。

从中,我们可以看到,随着并发数的增加,系统对外的吞吐能力略有下降,是因为拆分、合并等操作引入了额外的开销,但是单个文件的转码速度得到了提升,由单个节点的严重滞后到4个或5个节点并发时的超实时速度。并行化计算势必带来额外的开销,从而引起成本的上升,但是它也缩短了单个任务的执行时间,对于需要尽可能缩短单个转码任务执行时长的应用场景(如最新热点新闻的发布),采用集群并行化是一个比较廉价可行的解决方案。

5结语

在视频服务日趋丰富的今天,视频服务提供商对视频转码的需求越来越大,而高清化的视频使得转码的复杂度也随之提高。当单个计算节点的转码能力达到瓶颈后,本文提出了一个基于云计算框架的视频转码系统,利用计算机集群的并发能力,将单个转码任务拆分后并发执行,从而进一步显著提升了转码速度。

目前,该系统已应用于我司高清最新热点点播节目的生产发布,显著提高了高清点播节目的上线速度。

参考文献

[1]蒋兴昌,周军,罗传飞.H.264并行编码算法的研究[J].电视技术,2008,32(2):33-35.

[2]魏妃妃,梁久祯,柴志雷.基于X264多线程并行编码研究[J].电视技术,2011,35(19):7-10.

[3]宋阳,章晓燕.基于片上多核的H.264编码的并行加速性研究[J].计算机时代,2011(4).

[4]冯飞龙,陈耀武.基于H.264实时编码的多核并行算法[J].计算机工程,2010(24).

视频实时转码方法的研究与比较 篇4

(1) PC客户端和手机客户端的硬件性能是不一样的。手机客户端CPU性能普遍较弱, 大部分手机客户端CPU无法胜任高清视频的解码任务。使用这些设备进行高清解码时, 会出现视频丢帧、卡顿现象, 并且增加设备功耗, 减少待机时间。

(2) 由于手机屏幕较小, 提供高清码流并没有太大意义, 并不能提升客户体验, 只会增加数据流量带宽, 增加不必要的成本。因此, 通过转码降低业务带宽能够带来明显的经济效益。

1 基于GPU单元的转码

GPU (Graphics Processing Unit) 实时转码利用图形处理单元内部强大的硬件并行处理单元来执行转码中的部分运算。GPU原本被设计成用来执行图形处理, 提供GUI接口, 并非针对编解码处理。但是GPU拥有强大的并行通用计算能力, 这些计算能力能够执行视频编码中的大部分运算, 加速转码处理。使用GPU进行实时转码时, 由于视频解码这部分计算量不大, 仍然使用CPU进行软件处理。视频编码部分可以将计算量最大的步骤如运动估计、模式选择放在GPU上来加速实现, 而运算量较小的的步骤如量化与反量化、VLD、VLC以及DCT和i DCT等均放在CPU上用软件来实现。通过GPU硬件加速和CPU软件运算, 可以有效的实现视频实时转码, 目前Intel和Nvida的GPU均提供SDK开发接口, 可以在这些图形芯片上轻松地实现多路视频实时转码。

2 基于专用转码芯片的设计

这类转码方案的原理是使用专用转码芯片, 利用芯片的硬件功能直接实现转码, 不需要软件参与运算。例如Fujiso的MB86M01芯片能够实现一路H264高清转两路H264低清码流, 可以应用在大多数视频实时转码的场合。

MB86M01的转码过程如下所述:H264视频流进入芯片后解码得到原始码流, 然后经过两路编码, 生成两路视频流输出。整个过程由硬件完成, 无需软件进行处理。该方案比较简单。但是缺点是转码密度不高, 一颗芯片只能实现两路转码。如果一个服务器集成20路芯片, 也只能实现40路的转码, 不适合大规模的转码应用。并且该方案有另外一个缺点:灵活性不高, 很多转码参数不能设置, 输入视频流格式固定, 一些特殊场景下无法应用。

3 基于视频处理CPU的设计

现在有一种专门针对视频处理的CPU, 这种转码方法比较灵活, CPU内部集成了通用CPU和硬件视频处理单元。下面以TI的TMS320DM8168视频/成像数字信号处理器为例, 来介绍这类转码方案的实现。

该芯片内部集成一个ARM Cortex-A8内核, 一个DSP内核和一个视频处理硬件辅助单元。Cortex-A8内核给予了该方案足够的灵活性, 通过对A8内核进行编程, 可以直接实现大多数的实时视频流协议。处理器内部的视频处理硬件辅助单元功能强大, 能够实现视频的捕捉、视频的编解码运算和视频输出的硬件处理。处理器内部的DSP能够实现一些高级的视频处理功能, 如人脸识别、叠加水印等等功能, 结合CPU的三个功能单元, 既能够实现高强度的多路视频实时转码, 又能够灵活地实现智能识别和叠加水印等高级视频处理功能。

4 三种实时转码技术的比较

上述三种实时转码技术各有优缺点, 针对这三种技术, 我们对转码的主要特性进行综合比较, 比较结果如下表1所示:

通过上表我们可以发现, GPU转码方法功耗比较高, 转码能力强, 转码质量一般, 但是由于x86构架大量应用于服务器以及PC机, 只要对现有的系统进行软件升级, 就可以快速地实现视频实时转码;专用硬件芯片的方法转码效果好, 功耗低, 但是并行处理能力低, 可以用于一些专用转码终端的开发。视频处理CPU转码方法具有转码能力强, 功耗低, 性价比高的特点, 可以大量用于一些转码工作量比较大的通用转码设备, 如转码服务器的开发。

5 结语

本文对GPU转码、专用芯片转码、视频处理CPU三种实时视频转码技术进行了分析和比较。三种转码技术各有自己的特点和长处, 灵活应用这几种实时视频转码技术, 可以满足各种不同应用场合的视频实时转码需求。

摘要：为了满足不同应用场合下视频实时转码的需求, 分析和比较了几种不同的基于硬件加速的视频实时转码方法, 并通过实际测试统计了不同转码方法的性能。结果表明:采用GPU单元的转码方法适用于现有服务器的技术升级;采用专用转码芯片的方法适用于专用转码终端的开发;采用视频处理CPU的转码方法适用于通用多路转码服务器的开发。这对于选择合适的视频实时转码方式, 以最少的资源实现预期的转码效果具有参考指导意义。

关键词：视频,实时,转码

参考文献

[1]黄兴.基于GPU的视频转码技术研究[J].电视技术, 2012, 36 (1) .

离线转码器图像质量主观评价方法 篇5

1视频质量主观评价方法

长期以来, 无论是模拟视频还是数字压缩编码视频, 人们都是采用主观评价方法来评估视频图像质量, 国际和国内都有成熟的技术和标准。通常, 视频质量主观评价就是选择一批非专家类型的受测者 (15人以上) , 让他们在一个特定受控环境中, 连续观看一系列测试序列10至30分钟, 然后采用不同方法让他们对视频序列的质量进行评分 (表1为视频主观评价得分标准) , 最后求得平均意见分 (Mean Opinion Score, MOS) , 并对所得数据进行分析。测试环境中的受控因素包括:观看距离、观测环境、测试序列的选择、序列的显示时间间隔等。根据不同的测试环境、测试目的, 有下列几种视频主观质量评价方法:DSIS、DSCQS、SSM、SSCQE。所有这些主观评价方法都有其优点和局限性, 目前还没有一种通用性强的主观评价方法, 在实际应用中, 往往依靠研究者自身的判断去选择适合实际情况的主观评价方法。

2改造的主观视频评价方法

2.1测试目的

首先, 本测试旨在从两套转码方案中选出转码质量更优秀的 (高质量低码率) 转码方案。其次, 通过改变一些重要参数, 在胜出的转码方案中选择更适宜 (质量和效率之间寻找一个平衡) 的转码参数。最后, 与OTT视频进行比较, 得出视频效果不低于OTT视频质量的转码参数。

2.2测试环境的搭建

(1) 准备两台相同型号65寸高清电视机, 并将电视并排放置, 间隔距离小于20cm。受测人员在电视前分左右两列坐好, 人眼距离电视1.5~5m, 测试期间受测人员左右交换位置, 也可以任意走动观看视频。

(2) 选择两台相同型号的机顶盒 (硬件配置及视频播放器相同) , 分别与两台电视机连接, 播放相同质量的高清电视直播节目, 根据受测人员的反馈, 调整电视或机顶盒的视频输出参数 (电视机视频模式、对比度、亮度、色温) , 至两台电视机输出视频质量主观对比结论相同。

(3) 将拷贝有测试视频的两个U盘分别连接测试机顶盒, 使用机顶盒的视频播放功能进行播放对比。用一个遥控器对两个机顶盒进行操作, 方便确保两个视频播放进度同步。

2.3测试方法

(1) 受测人员10人以上, 视频播放人员一人。

(2) 组织者依据测试目的, 准备好待测视频及测试顺序。

(3) 向受测人员发放测试表格, 表格如表1所示。受测人员在每轮对比中选择视频质量优秀的那个。

2.4视频准备

(1) 选择一部亮度明暗适中、色彩丰富的电影作为视频源, 这样能全面有效地验证转码质量的优劣, 避免因光线或颜色过于单一造成的局限性。

(2) 针对多屏视频业务, 分别用不同的编码方案将给定视频源转成视频带宽为3.5Mb/s、2.5Mb/s、1.5Mb/s、0.8Mb/s的视频。通过调整视频分辨率、CBR/VBR、one/two pass、质量等级 (某一编码方案中参数) , 生成20分钟左右的视频段, 其他非常用参数如GOP长度、B帧、P帧、视频级型等默认采用方案提供商的建议, 还有一些参数如帧率、长宽比则采用“跟随源”的方式。

(3) 选择电视猫中乐视片源作为OTT业务对比视频, 其清晰度分别为乐视超清、乐视高清、乐视标清, 其中乐视超清为最高清晰度。

3测试结果

3.1转码方案对比

经过统计, 去掉无效数据, 转码甲方案优于乙方案。

(1) 在四种视频码率的对比中, 转码甲方案的视频清晰度均高于乙方案。

(2) 转码速度。在采用同一视频源和相近转码参数进行比较时, 甲方案转码速度能达到15.7X (较长时间运行时能稳定达到20X) 。若想进一步提高质量, 则要降低速度, 那么把转码速度降低到9.5X。B方案转码效率为0.9X左右, 采用较高的服务器硬件配置, 其转码效率不超过2X。

3.2甲方案转码的最优参数

通过改变甲方案中的转码质量等级、one/two pass、小码率CBR/VBR、1080P/720P中一项参数, 进行对比发现:

其他参数固定, 当视频码率为3.5Mb/s, 视频分辨率为720P时质量好于1080P;只改变one/two pass, 差别不明显;视频码率为0.8Mb/s时, CBR质量好于VBR质量。

3.3与OTT视频比较结果

与OTT视频比较结果如表2所示。

3.4转码主要参数

结合运营商片源及网络条件现状, 建议转码后的视频片源基本参数如表3所示。

4结语

在测试中发现, 当一些前提条件成立时, 有些实际测试结果并不完全符合理论结果, 如小码率视频时VBR质量低于CBR视频质量, 当视频带宽为3.2Mb/s时, one pass和two pass之间差别并不明显。当然这不能完全排除测试过程产品的误差。值得注意的是, 在选择编码方案和确定编码参数时, 一方面要具体结合转码器及终端芯片给出最优的转码方案;另一方面, 要结合运营商自身实际情况, 平衡质量和效率。由于时间、环境等原因, 本次测试有些地方不够严谨, 样本源不够丰富 (应尽量准备不同类型的视频如电影、电视剧、童话片、风光纪录片、体育赛事等) , 不同类型的视频可采用不同的转码参数配置。OTT对比源单一, 可以对比爱奇异、搜狐视频等客户端。

参考文献

[1]王新岱, 杨付正.视频质量的主客观评估方法研究[J].电视技术, 2003 (8) :81.

[2]国家广播电影电视总局广播科学研究院电视研究所.GY/T 134-1998数字电视图像质量主观评价方法[S].北京:国家广播电影电视总局标准化规划研究所, 1999.

素材转码 篇6

网络视频已成为人们生活中不可或缺的一部分。截止到2012 年, 美国有将近90% 的人通过网络获取高清视频［1］, 如何保证各种移动终端得到不同的服务质量, 提供可靠的服务面临严峻的挑战。

视频转码就是从一种视频码流到另外一种码流的转换, 目的是把输入的压缩流转换成符合接收端要求的压缩流。随着视频数据量的急剧增长, 传统的视频转码系统存在存储能力不足、存储能力和处理能力不可扩展的缺点。近年来, 研究人员提出多种基于Hadoop的视频转码系统［2 － 5］, 用来提高转码效率。文献[2]在集群机器配置完全一样的情况下, 把视频分别按时间、机器数目和视频相关性分段, 进行了3 组对比实验; 文献[3]提出了一个面向移动设备的云转码系统, 引入了视频资源预测与缓冲区置换的算法; 文献[4]利用开源软件Vmoox设计了一个面向智能手机的转码系统, 而文献[5]根据视频切片大小、不同的机器节点数和Hadoop本身的block大小进行对比实验。

针对现有视频转码系统大多没有考虑到根据机器处理能力分配转码任务量这一问题, 提出一种新的任务调度算法。输入视频被分成段, 根据视频段的复杂度和机器的处理能力进行映射, 类似“能者多劳”机制, 从而减少并行转码时间。

1 Hadoop转码系统

1. 1 Hadoop介绍

Hadoop是一个开源的云计算框架, 如图1 所示, 是一个适合处理海量数据的并行编程系统, 可以根据输入数据分布信息自动创建几个并行子任务, 并将子任务调度到合适的集群节点上并行执行, 所以此模型能够很好地适用于多个视频文件进行转码。Hadoop使用Map/Reduce作为编程模型, Map/ Reduce通过将大型分布式计算分解为一系列对数据键值对的操作实现并行处理。HDFS是Hadoop主要的分布式存储系统, 它和现有的分布式文件系统有许多相似之处。HDFS的设计目标是: 支持大的数据文件, 这些文件以顺序读为主, 以文件读的高吞吐量为目标, 并且与Map/Reduce框架紧密结合。

1. 2 视频转码

视频技术和视频压缩标准的不断发展以及视频节目在不同应用环境的需要, 促使了视频转码研究的出现和不断发展。转码的主要目的就是使得异质网络之间、不同的接入设备之间以及不同视频数据格式之间能够互相兼容。视频转码主要有以下几种类型: 码率转换 ( Bitrate reduction) 、空间分辨率转换 ( Spatial reduction) 、时间分辨率转换 ( Temporal reso- lution reduction) 和语法转换等［6］。

视频转码的过程是: 对原始视频进行解码、重新调整和视频编码。在网络视频应用中, 网络带宽随着时间波动。视频转码的主要用途是使视频适应于网络带宽, 类似于可伸缩视频编码 ( scalable video coding) ［7］。视频压缩的标准格式有多种, 如MPEG- 1、MPEG-2、H. 263、MPEG-4 和H. 264 等。

1. 3 云转码方案

首先提出一种基于hadoop的视频转码框架, 如图2 所示。视频由mkvtoolnix软件进行切片, 通过MapReduce中的map函数封装ffmpeg转码功能, 当大量视频转码任务提交到集群时, 系统把任务分配到集群节点上, 利用集群系统的计算能力和已有视频转码开源软件实现多视频同时转码。

视频转码分为离线预转码和在线转码, 系统处理一个普通的用户的视频请求可分为以下几个步骤:

① 视频请求: 用户从远端向Web Server发送获取视频的请求, 包括视频名称与用户设备规格;

② 设定参数: Web Server根据用户设备参数及所要求的分辨率, 向Streaming Server请求视频资源;

③ Streaming server检查Prestore video data中是否有与用户请求相匹配的数据;

④ 若存在, Streaming Server从Prestore video da- ta中取出视频数据;

⑤ 将视频块返回给用户;

⑥ 否则向NameNode发出转码任务的命令, NameNode调度集群进行分布式转码; 分布式转码完成后, NameNode向Streaming Server返回转码完成后的视频文件所在位置Transcoded video data;

⑦ Streaming Server从Transcoded video data中读取视频文件;

⑧ 将视频块返回给用户同⑤。

2 关键技术

2. 1 问题模型

此处要考虑的是如何快速地把复杂度不等的子任务调度到多个处理能力不一致的处理节点上。文献[8]比较了11 种调度算法的执行效率, 发现Min- min效率最高。但是Max-Min算法与其相比, 资源负载性能上要好的多。Max-Min算法把所有节点的完成时间进行平均化, 从而减少了转码时间, 提高转码效率。

首先把资源的动态分发问题建立数学模型[9]:

假设:有n个具有不同复杂度的视频段, J= ( 1, 2, 3, . . . n) , C = ( c1, c2, . . . cn) , m个不同处理能力的计算节点, P = ( p1, p2, . . . pm) , 若转码时间与视频块的复杂度成正比, 与机器处理能力成反比, 则视频块i分发到机器j上的转码时间为 ( 只考虑转码时间, 其余负载均忽略) :

视频块分发完之后, 机器j上获得的视频块的集合设为sj, 集合sj的完成时间为:

设L = { s1, s2, . . . , sm} , A ( i) : J - > L , 意味着把所有视频块映射到处理机器上, 目标是找到最优的调度算法最小化全部完成时间。因此可以找到完成时间相对较长的机器, 然后将其最小化, 整个转码过程的效率才会提高。即:

2. 2 模型参数评估

2. 2. 1 节点转码能力评估算法

影响机器转码性能的因素有很多: 比如处理器、 内存、网络和磁盘读写速度等。参照PageRank算法来综合评估机器的转码性能。首先设定配置方式:

2 种不同网络状况和ffmpeg的2 种版本, 这样总共有4 种配置方案, 再用基准程序测试各个模块的数据, 然后使用PageRank算法进行数据分析［10］。

① 运行基准程序生成原始数据矩阵D, D ( i, j) 代表第i项配置方式下第j项的测试输出值;

② 对初始数据进行抽象, 将原始数据矩阵看作由列向量组成, 即D ( d1, d2, . . . d7) , 每列表示每个测试项在各种配置中的输出数据序列;

③ 计算邻接矩阵A, A ( u，v) = correlation ( du, dv) , u = 1, 2, 3, 4, v =1, 2, . . . 7;

④ 使用PageRank对各测试项计算出PageRank得分。得分高的测试项表明该项较多地反映了大多数测试项的变化特征, 得分较低的项说明该项具有较多跟其他测试项不同的数据变化特征。根据被参考机器的转码性能, 来计算出其他机器的转码能力。

2. 2. 2 视频块复杂度

视频复杂度的评价方法有很多: 如视频编码、视频大小、TM ( the spatial detail metric) 和SD ( the tem- poral motion metric) 等, 选择视频大小作为评估视频复杂度的唯一标准。

2. 3 动态规划法

假设2. 1 节中的问题为NP问题, 要想解决此问题, 首先要对数学模型进行分析。本文是想找到一个算法, 快速得把n个视频块分发到m台处理能力不同的机器上, 并且m台机器要在一定的时间误差内完成转码。类似背包问题 ( Knapsack problem) , 从一堆物品中挑选出几个, 在不超过总重量的前提下, 使总价最高。背包问题是一种组合优化的NP完全问题。

对于背包问题, 已有的求解方法可分为精确算法 ( 如枚举法、动态规划法、分支定界法、图论法和指数级方法) 和近似算法 ( 如贪心算法、蚂蚁算法和遗传算法等) 。其中动态规划法是解决多阶段决策过程最优化的一种数学方法。通过把原问题分解为相对简单的子问题的方式求解复杂问题的方法。动态规划方法所耗时间往往远少于朴素解法。动态规划背后的基本思想非常简单。若要解一个给定问题, 需要解其不同部分 ( 即子问题) , 再合并子问题的解以得出原问题的解。

2. 4 Min-MM算法

本文提出一种Min-MM算法, 此算法结合虚拟背包问题和Max-Min算法的思想。首先将平均转码时间作为分布式转码时间的下限, 计算每台机器所能接收的总复杂度, 然后选取视频块分发到机器上。

2. 4. 1 设定平均转码时间

根据2. 2 节可计算, n个视频块的总的复杂度为:

m台机器的总的处理能力为:

则理想状态下n个视频块分发到m台机器后, 平均转码时间为:

则机器j在faverage时间内可以完成的视频块复杂度为:

2. 4. 2 虚拟背包过程

将n个视频块根据复杂度从高到低的顺序进行排序, m台机器根据处理能力从强到弱的顺序进行排序。如图3 所示, 由处理能力强的机器首先选择视频块, 若vj*+ ci< vj, vj*+ ci+ ci +1> vj, 则计算vj*+ ci+ ci +2的值, 若vj*+ ci+ ci +2vj, ( vj*为目前已选择的视频块的复杂度) 则停止选择; 否则继续计算vj*+ ci+ ci +3, 直到vj*+ ci+ ci +l, 若vj*+ ci+ ci +lvj, 则停止选择, 否则将vj*+ ci赋予机器j。被选择过的块标记为1, 没被选择的块标记为0。第2 台机器从所有标记为0 的视频块中选择, 遵循上述规律。

2. 4. 3 Max-Min算法

当所有的机器都进行选择之后, 可能会有些剩余的视频块, 并且部分机器所选择的视频总复杂度没有达到vj ( 图3 机器1 中的空白处) , 此时再根据Max-Min算法将剩余视频块分发到机器上。

3 实验与分析

3. 1 实验设计

实验环境: Hadoop集群: 17 台服务器, 型号分别为DELL R620、R610 和R520 等, 其中一台机器作为NameNode, 并安装Mkvtoolnix软件, 负责切片; 其他16 台作为DataNodes, 并安装ffmpeg负责转码任务。

首先, 使用云转码系统进行转码, 验证其所能支持的视频格式、转码时间, 其次是使用Min-MM算法前后的对比。

( 1) 视频输入格式为mp4、mkv、mov、rm和ts; 视频输出格式为mp4、mov、mkv和ts。

(2) 测试总的转码时间

转码参数如表2所示。

①改变视频大小:0.5 G、1 G、2 G、4 G、8 G、16 G;

②改变集群的机器数目:1、2、4、8、16;

③ 不同的切片大小: 16 M、32 M、64 M。

⑶ 当集群有4 台计算节点, 视频分段大小不一样, 其余条件都一致的情况下, 使用Min-MM算法前后转码时间的对比。

3. 2 结果分析

针对上节提出的3 种实验方案, 得到以下实验结果, 并对其进行评价分析。

① 提出的基于hadoop的转码系统支持mp4、 mkv、mov和ts等格式之间的互相转码, 并且由实验可以看出, mp4 和mkv转码过程时间相对较慢, mov和ts则相对较快, 这跟视频本身的构成有密切的联系;

② 切片大小为32 M时, 不同大小视频在1 到16 台处理节点的集群中的转码时间, 如图4 所示。从图中可以看出8 G, 16 G的大视频块的转码加速效果比512 M到4 G的更明显。4 台处理节点, 切片大小为16 M、32 M和64 M时的转码时间对比, 如图5 所示。从图中可以看出: 当视频大小为0. 5 ~ 2 G时, 切片大小为32 M转码时间最小; 4 ~16 G时, 切片大小为64 M时, 转码时间最少;

③ 可以看出使用Min-MM算法之后的转码时间明显小于使用之前, 如图6 所示。

4 结束语

在Hadoop的视频转码框架基础上提出了一种新的任务调度算法Min-MM。云视频转码框架使用的是Hadoop云平台、mkvtoolnix切片工具和ffmpeg转码工具, 结合任务调度算法, 来提高转码效率, 改善转码系统的性能。任务调度算法Min-MM针对各个DataNode处理能力不一致的问题进行数学建模, 首先对视频块复杂度和机器的处理能力进行评估, 然后利用虚拟背包问题和Max-Min算法将n个复杂度不同的视频块分发到m台不同处理能力的机器上, 使总的转码时间平均化。

实验结果验证了云转码系统能够对大视频数据进行快速转码, 及视频切片大小对转码总时间的影响。Min-MM算法在节点处理能力不一致的情况下, 最大化地缩短了整个系统的转码时间。

参考文献

[1]ZHANG Hao, SUN Shu-xia.Application of Hadoop in Video Transcoding Based on Cloud Computing[J].Computer&Telecommunication, 2011 (12) :36-37.

[2]ADRIANA G, HARI K, BORKO F.A Study of Transcoding on Cloud Environments for Video Content Delivery[C]∥Proceedings of the 2010 ACM Multimedia Workshop on Mobile Cloud Media Computing.Italy:Firenze, 2010:13-18.

[3]LI zhen-hua, HU ANG Yan, LIU Gang.Cloud Transcoder:Bridging the Format and Resolution Gap between Internet Videos and Mobile Devices[C]∥Proceedings of the 22nd International Workshop on Network and Operating System Support for Digital Audio and Video, Canada:Toronto, 2012, :33-38.

[4]SHEFER L D, MARCHESE F T.A System for Real-Time Transcoding and Delivery of Video to Smartphones:Information Visualisation (IV) [C]∥2010 14th International Conference.London, 2010:494-499.

[5]KIM M, CUI Y, HAN S, et al.Towards Efficient Design and Implementation of a Hadoop-based Distributed Video Transcoding System in Cloud Computing Environment[J].International Journal of Multimedia and Ubiquitous Engineering, 2013, 8 (2) :213-224.

[6]尚书林, 杜清秀, 卢汉清.视频转码技术研究现状与进展[J].自动化学报, 2007, 33 (12) :1233-1241.

[7]余圣发, 陈曾平, 庄钊文.针对网络视频应用的视频转码技术综述[J].通信学报, 2007, 28 (1) :111-118.

[8]BRAUN T.A Comparison of Eleven Static Heuristics for Mapping a class of Independent Tasks onto Heterogeneous Distributed Computing Systems[J].Journal of Parallel and Distributed Computing, 2001, 61 (7) :810-837.

[9]LAO Feng, ZHANG Xing-gong, Guo Zong-ming.Parallelizing Video Transcoding Using Map-Reduce-based Cloud Computing:Circuits and Systems (ISCAS) , 2012 IEEE International Symposium on[C].Seoul, 2012:2905-2908.

素材转码 篇7

Hadoop是并行编程系统,适合于处理大规模数据,可根据输入的数据分布信息,自动创建并行子任务形成一个集合,使子任务在合适的集群节点上并行执行的一个开源云计算框架。Hadoop系统的核心模块就是MapReduce,该模块极大地方便了程序员在不会分布式并行编程的情况下,将自己的程序运行在分布式系统上。程序员要做的仅仅是按照MapReduce编程规范定义好map(映射)函数、reduce(规约)函数,而不需要关心节点和任务的失效及任务之间的数据等问题,就能完成分布式数据处理问题。在本文中通过基于云计算平台的MapReduce开发框架,将转码任务并发到多个计算节点,每个计算节点在同一时间对同一个视频文件的不同部分各自进行转码,系统再将分段转码结束后的视频文件整合成单个视频,即完成单个转码任务。

1 基于云计算平台的视频转码系统

1.1 系统设计原理

本系统设计是本着以提升转码任务的速度为原则,因为单个计算节点的物理条件和转码算法不会影响并发能力,使得转码任务的速度具备较大的提升空间。基于Hadoop云计算平台的视频转码系统可以满足大批量、多用户视频转码对资源的需求。本系统使用音视频转换软件来实现视频转码,将转码功能用MapReduce中map函数封装起来。当集群出现大量视频转码任务时,系统会利用集群计算能力和视频转码软件在集群节点上自动随机分配任务,实现多视频同时在线转码。码率转换、空间分辨率转换、时间分辨率转换、语法转换、容错视频转码等的工作全交给已有的转码软件来实现。

在本系统设计中,使用Java脚本提供的Runtime类函数调用转码功能代码。此方法的优点是:只要打包后最终的结果是可执行文件,无论视频处理功能是由什么语言编译的,都可以被MapReduce框架调用。Java虚拟机的运行时环境可以通过Runtime类函数获取,Runtime类函数调用可执行文件只要一个取代调用进程的内容的函数Exec。Exec函数的参数是要被调用的可执行文件RuntimeExecExec的命令行,该命令行的值取决于视频处理功能的具体实现。的命令行,该命令行的值取决于视频处理功能的具体实现。

1.2 系统架构实现

系统整体架构采用Google提出的适用于大规模数据量的并行运算软件架构“Map-Reduce”,主要思想是使用一个映射(Map)函数使用他的拆分功能,将一个将一个大任务拆分成若干个独立互不干扰的多个小任务,同时将这些小任务映射到多个相应节点的算法,或使用一个化简(Reduce)函数实现一个逆操作(多个相互独立任务合并成一个任务)。本系统是由存储系统、任务调度、码流预处理、码流后处理、码流分割、码流合并、转码节点等部分组成。映射器承载了将大视频码流拆分成多个小段视频码流的过程,包括码流预处理和码流分割。化简器承载了将小段视频码流转码、合并和复用的过程,包括转码节点、码流合并和码流后处理。

存储用户提交的待转码视频通过视频接收接口到达存储系统,用户可通过视频接收接口获取转码系统成功转码后的视频和相关信息。转码系统的核心是任务调度,主要是管理系统内的需要进行计算的所有资源,如遇到新的转码任务到达时任务中心时,本系统会自动根据优先级以及当前系统的空闲资源进行分配,然后分配适当的计算资源按顺序去完成码流预处理、码流分割、转码、码流合并、码流后处理等步骤。

码流预处理对用户提交的转码视频分析、容器解析,流解复用进行自定义转码需求,使视频和音频流分离。码流分割任务调度模块按照指示,指定的视频流被划分成段,分割时需要连续的流图像避免跳帧或重帧现象。任务调度模块的指令分配转码节点,读取分割后的视频码流段,根据用户设置的转码参数完成转码过程。码流后处理对转码合并后的视频码流以及转码后的音频码流按照用户指定的文件格式进行复用,生成成品文件。

1.3 视频拆分算法

一系列连续的图像组成Group Of Pictures(视频码流中的图像组)。在MPEG编码中,图片组即I帧和I帧之间的帧排列。每个图像组至少有一个I帧,并且I帧处于图像组的开头。I帧无需依赖其他帧可以独立解码,若干个连续的图像组组成了一段视频码流。视频分割的过程中图像组级别粒子大小适中,相比单一帧的粒子而言,图像组解码的独立性更好;相比完整视频有更好的转码并发性。

所以,判断码流图像组的结构在视频文件拆分的过程中得以体现,需要视Open-Gop和Colse-Gop的不同情况分别采取不同的分割策略。例如要保证解码器能够解出这个视频文件中的所有帧,Open-Gop就必须在每一段分割码流片断的前面增加一个图像组的冗余。同时在进行分割时还要将分割策略的选择情况记录下来,供编制合并程序时参考使用。

在拆分后,如果拆分点后的第一个GOP是Open-Gop,需要多加一个GOP在后一段视频前。相反,如果拆分点后的第一个GOP是Colse-Gop,就不可能会出现无法解码视频的情况,因为视频通常被拆分点划分成为两段,拆分过程中还要注意解码器一段视频进行每一次解码时,都要查找对应视频中的序列头信息。视码流的不同会出现每个GOP前都附带有相同的序列头,也可能仅仅只开始处包含序列头。这时,如果出现前者状态,那么就在拆分时整体分割每个序列头。如果出现后者状态,则序列头添加在拆分之后的每一段子视频前面。

2 视频转码系统实验实施

为检测本系统的效果,我们将总时长为60小时的85个高清1080i测试视频(码率为50Mbps)进行实验。当系统架构和核心算法在固定的情况下,如果将这批的视频转码作为单独的任务,可以用“吞吐量”来考验衡量系统完成该任务的速度,任务处理时间越短表示系统和外部的吞吐量越大。同理,如果将每一个视频的转码作为单独的任务,则系统的性能可以使用“超时率”来进行评测,其公式为:超时率=1视频时长÷转码时长。从这个公式可以看出如果想实时转码就是要使超时率为0,也就是说用1个小时转完1个小时的视频。当超时率为正表示超实时转码。该转码系统的性能能力的变化通过调节任务并发数量来控制,实验结果如表1所示。

从实验结果中,我们可以看到,随着并发吞吐数量的增加,外部吞吐能能力略有下降,因为视频文件拆分、合并等操作引发了额外的系统开销,但单个文件转码速度已有显著提高,由单个节点的速度严重滞后提升到4、5个节点并发实时速度。当然,并行计算会带来额外的开销,从而导致上升成本,但它缩短了单个任务执行时间,需要缩短单个转码任务执行时间,采用计算机集群并行化是可行的首选方案。

3 结束语