视频切片并行加速
背景在实际业务中,视频处理,大都时候都挺费时的。例如:以下表格是,某中算法,在不同分辨率、帧率下的,cpu计算耗时体系(不包括:上传、下载的耗时):
分辨率
帧数
处理时长 / 视频时长
720p
30帧
2
720p
60帧
4
1080p
30帧
3
1080p
60帧
6
2k
30帧
3.5
2k
60帧
8
4k
30帧
7
4k
60帧
20
另外,一般情况下,视频越长,所占用的cpu or gpu,也就越久。如此有以下弊端:1、对于用户而言,耗时久,体验非常不好,有可能直接放弃了。2、很容易造成资源负载不均,例如:有些机器比较倒霉,每次分配的都是:长视频(5min以上),有些机器比较luck,分配的大都都是:短视频(30s以内)3、超过1h的视频,单台物理机,基本上不太可能能够处理完毕,姑且不谈cpu,内存都有可能爆满。
视频处理这里面的视频处理,可以是:libx264转码、libx265转码、超分、ai绘画、水印去除、人像增强、去模糊、去躁点等等。
为啥只谈视频切片?切片并行加速,是否支持以下2个场景?
1、文生视频 ...
算法、模型工程化
概念首先,大家先对齐下概念,避免因对概念理解不一致,而带来误解。
算法大学中所学的数据结构课本上说:算法是指解决问题或执行任务的有序步骤集合。当然,如此描述的算法,相当准确。但是,对于实际工程落地而言,还是过于:抽象 +空。这里面描述的算法,是指:算法同学所交付的可执行文件 orso库,例如:视频压缩领域的:264算法,交付的产品:集成到ffmepg中的libx264。例如:如下命令,是使用:libx264算法真正去压缩一个视频的命令,那么:对于实际工程落地而言,所提供的带上libx264的ffmpeg可执行程序,可以简单地理解成:算法
1ffmpeg -i source.mov -s 1280x720 -profile:v high444 -c:v libx264 -preset veryslow -crf 30 -r 30 -g 120 -keyint_min 30 -sc_threshold 40 -bf 3 -b_strategy 2 -refs 5 -c:a libfdk_aac -profile:a aac_low -b:a 128k -movflags faststart ...
从0到1搭建媒体处理体系
背景作为公有云重要组成部分,媒体处理体系,为我们提供了广泛而强大的工具,极大地拓展了数字媒体处理的领域。通过将图片和视频处理移至云端,我们能够享受到更高效、灵活、可扩展的服务,能够方便、快捷、高效地服务个人用户、企业和开发者。
业界调研
公有云
缩写
产品名称
备注
阿里云
MPS
媒体处理
腾讯云
MPS
媒体处理
华为云
MPC
媒体处理
音视频处理
MCP
音视频处理
七牛云
智能多媒体服务
又拍云
云处理
其实,无论叫啥名字,它们的本质做的事情是一样的。其整体流程图如下:
怎么搭建经过抽象,想要搭建一套媒体处理,包括以下模块,如下图所示:
说明:1、上述图展示的是:包括了多少个功能模块,并非调用顺序,各个模块的调用顺序,得根据实际功能来定,会有专门的模块来分析。2、暂时先忽略:图里的颜色,目前并未想清楚:应该用哪些颜色来表示具体含义。
功能云处理的功能,用公式来表达:媒体s = fn (媒体s,参数),有以下特点:1、媒体,只是狭义上的媒体,单纯地指:图片 + 视频 + 音频。2、带上s,证明可以是:多个,也可以是0个 ...
版本核对
背景在实际媒体计算的业务场景中,如何确定计算后的图片 or 音频 or视频符合上线标准?最简单的办法:手动跑图,然后,人眼看,主观判断是否符合上线标准。这种方法,早期可行,也就是:当待核对算法少 +跑图个数少,可行。
核对流程对于用户而言,其整体工作流程如下:
概念定义1、版本核对,以某个版本的算法的跑图结果作为基准,新开发的算法的跑图结果 与 此基准跑图,做差异性检测。如果有差异,则人工介入分析。
其中,两个版本的算法,跑图必须一样 + 算法入参也必须一样,注意:必须2种结果:以其中一个为基准,确定另一个是否满足预期。
2、版本择优:同一个算法,入参图片一样,但是,算法入参不一样,计算出多种结果,然后,主观选择最好的一种上线。注意:2种以上的结果。
3、画质评测:同一个算法、入参图片一样,算出一种结果,通过人眼主观评测,得出当前结果的画质值,注意:可以只有一种结果。
4、自主跑图:自动调用手机 or 电脑 or api,自动跑出一批图片 or 视频出来。
分类按照跑图媒介进行分类:
名称
分类
说明
备 注
安卓跑图
手机客户端跑图
调度安卓机器,触发跑图
i ...
流程决策
背景
媒体处理开放平台
功能定位在互联网时代,将算法、模型的处理能力,封装成一系列计算机易识别的数据接口开放出去,供第三方开发者使用,这种行为就叫做OpenAPI,提供开放API的平台本身就被称为开放平台。
需求梳理如:从0到1搭建媒体处理体系的架构图所示,开放平台包括以下功能:
功能
优先级
功能说明
备注
协议转换
T0
将千变万化的用户协议,转成内部的标准文件处理协议
参数校验
T2
确保入参满足要求
鉴权
T0
确保接入请求都合法,没有所谓的:水平越权 or 垂直越权
计费
T1
统计:调用次数、输入视频时长、使用cpu、gpu的时长等
同步转异步
T0
详见:同步转异步
协议转换业务需求千变万化,很难通过定义一套标准,让所有人都按照固定的方式接入。因此,需要有一个系统去承接:将千变万化的用户个性化报文,转成内部的标准文件处理报文。
网关形态站在用户视角来看:所见即所得,是比较好的用户体验方式。用技术术语来说,就是用户同步等待结果的显示。但是,对于大图片计算,长视频计算,往往也是非常费时的操作,极容易超时,因此,这就产生了2种产品形态:形态1:同步等待结果模式 ...
数据集市
背景当某个app的DAU呈45°上扬,从百万DAU,到千万DAU,甚至过亿DAU,无论是组织架构,还是:经典的db +缓存策略,会变得越来越无法灵活面对纷繁复杂的业务场景。具体表现如下:
专业人做专业事任何一个团队的成员构成比例,既有资深的,也有新人。一般情况下,都是让新人介入实际业务需求,那么,该新人就得在熟悉业务的前提下,也需熟悉目前的:db +缓存策略。那么,可否让新人刚开始只关注于:业务。等业务熟悉以后,再去关注:db + 缓存策略呢?
成本优化过五百万dau以后的业务,功能也是非常多的,此时,db +cache策略一般都还在业务代码中,面对如此境遇,单靠2、3个所谓的架构师,想要在确保当前功能不变的情况下,做到:性能优化 or成本优化,其实,还是有很大的挑战的。
多语言下中间件的困境在很多公司的后端工程领域,都有3种以上的语言(例如:php、java、go),每种中间件都必须提供3种语言的sdk版本,这给中间件带来一定的维护成本,也给业务方的学习成本、升级成本。以redis为例,虽然redis提供了相当丰富的功能,但是,站在业务方的角度上说,它需要关心:redis的key是怎 ...
多云元数据服务
背景如前文所述,想要搭建一套云处理体系,有很多配置需要CRUD,因此,需要一套元数据配置服务,存储 or 读取相关配置,以便做下一步业务逻辑。
功能梳理
功能点
说明
备注
url解析成uri
将文件url解析成cloud、bucket、key,方便在多云环境下,能够正常上传、下载文件
多云下的bucket关联域名
bucket与host关联,提供url解析的元数据信息
域名打标签
任何一个域名,会关联多个标签,方便不同业务场景分发不同的域名
url重签
私有桶的url容易过期,需要一种方式重新对url重签
ak/sk
bucket与ak/sk的关系,也是一对多,也需配置:标签的功能,标记在什么样的情况下,使用哪一组ak/sk
备注:1、一个host只能找到唯一的bucket与之对应。2、ak/sk与标签的关系:一对一3、host与标签的关系:一对多
功能设计注意:并不一定需要单独的http服务,业务量级小的时候,也可是网关的一个模块。
yml设计123456789101112131415161718192 ...
说说报文
概念通信报文,说白了就是一串有规律的、易于理解的数据流,而“有规律”就是用技术规范、协议、标准、接口文档等来描述的。对于我们而言,一般就是接口文档;
为啥需要报文各个计算机设备之间,需要交换数据,数据是通过网络来传送的,而在网络上传送的数据都是基于0或1这样的二进制数据,如果没有对数据进行编码,则这些数据没有人能够理解,属于没有用的数据。而经过一些协议、技术规范、接口文档等规范过的数据(有规律的数据流,也就是通讯报文),才是有用的数据,才能被别人理解。
分类按通讯报文的具体格式分,比较常用的有以下几种:1、定长报文2、ISO8583报文3、分隔符报文4、Xml报文5、Schema报文6、Json报文7、Swift:MT、MX报文8、混合报文9、pb报文10、hession报文
备注:
1、互联网目前用的比较多的报文还是:http + json报文。
视频处理功能集
音视频处理功能音视频meta信息获取指定音频、视频资源的元信息,例如:宽、高、码率、帧率、文件大小、时长
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137{ "streams": [ { "index": 0, "codec_name": "aac", "codec_long_name&quo ...