视频生产环境下的音视频解决方案

随着剪辑、云导播、音视频生产在线协作的兴起, 生产环境下的音视频处理越发为人所关注。音视频处理在生产环境下,对 控制精准性 有着更高的要求。从服务端到客户端,精准的时间控制、画面控制都是生产环境音视频和分发环境下音视频处理的重要区别。服务端与客户端的协同上,容易产生微小的差异。

文 / 姜雨晴

整理 / LiveVideoStack

视频回放:

https://www.livevideostack.cn/video/online-jyq/

大家好,我叫姜雨晴,是MediaTrack音视频研发负责人,之前就职于熊猫直播,一直从事前端的播放器,后来有幸去了字节跳动,最近在参与和熊猫直播的创业项目。这个项目主要是关于生产环境下的解决方案,我们不再做传统2C的视频分发解决方案,而是针对于视频的创作者的协同和合作进行一个解决方案,这和传统2C的观看端有很多不一样的地方。

视频生产环境下的音视频解决方案

本次内容主要分为四个部分:一是架构;二是工作流;三是一致性;四是扩展性。

视频生产环境下的音视频解决方案

首先,了解一下我们的产品,在网页端和小程序端会有修改和批注的功能,也就是我们最早上线这版的功能。如果要做一个生产环境下的解决方案,我个人比较倾向于先了解生产环境下,用户如何去使用这款产品。

视频生产环境下的音视频解决方案

因为我个人比较喜欢使用一些剪辑软件去剪辑一些片子。这张图是我个人剪辑时的状态,首先需要精确到帧的控制,而且每一段的时间戳都非常准确,要清楚哪一段插进的内容,如要清楚知道图中字幕的位置等要精确到哪一个像素。尤其在网络的视频分发过程中,并不能保证这样的一致性。平时在观看时是不需要保证到帧的,这就给我们的服务带来了很大的挑战。

视频生产环境下的音视频解决方案

我们现在最核心的两个业务是:媒体转码和视频标注和截图。首先,媒体转码是网络分发,我们所看到的东西不可能用源流,因为源流可能特别大,有可能在网页或小程序端解码不了,这就涉及到转码,所以转码流和源流是否保持一致就成了很大的问题。其次,视频标注和截图也会在一致性上产生差异。

1

架构

这张图是我们现在的MediaTrack整个的架构,整个命名方式延续了熊猫的命名方式,所有的项目都采用英雄联盟的英雄为项目名称。现在最主要的两个项目是:一是对用户可见的Web端的Sona和小程序的Neeko,它们的背后是第二层长连接Riven和API的Kayn这两个部分,也就是和前端进行交互的这层,它们的灵活性会比较高,并根据产品的需求加接口。

最后这部分是微服务集群,重点是音视频服务Ahri,对于系统内的其他服务而言,Ahri只是音视频服务,与其他的微服务没有任何区别。

视频生产环境下的音视频解决方案

Ahri是所有媒体相关操作的微服务集合,包括媒体转码、文件格式矫正、媒体信息的获取、截图、音频waveform抽样、标注点绘制、图片处理等一系列工作。Ahri对外仅是个普通的微服务。对内是微服务组,这也是它命名的原因。Ahri是一个九尾妖狐,它可以将能量存储在火球中并释放出去,它的九条尾巴就像对内的微服务一样,都是它不可或缺的部分。

视频生产环境下的音视频解决方案

这张图展示了Ahri的架构,Ahri对外的服务就是Ahri网关,并没有自己实际的操作,它所有的操作都是向内部的微服务创建任务并汇总这些任务,但转码还是采用云厂商的转码。

2

工作流

视频生产环境下的音视频解决方案

我们两个比较重要的工作流:一是调用工作流,Ahri先要知道需要做什么再进行工作,利用Magic number判断文件类型。因为我们的系统允许用户传任何文件,这样会把文件的扩展名改掉,或者前端无法判断它是否是一个音视频文件。这时Ahri会再进行判断,如果是一个视频文件会通知其他服务矫正它,并进入真正的媒体处理的流程。

媒体处理流程也会做一个矫正,实际并不想同一个文件处理多次。当多个用户上传同一个文件时,需要做hash。当事件任务完成或者状态更新时,就进行广播消息。

视频生产环境下的音视频解决方案

如果没有媒体信息、获取媒体信息矫正。截图标记会遇到一些坑点:一是时间戳找齐;二是画图标记找齐。

3

一致性

视频生产环境下的音视频解决方案

时间一致性,传统上,现在可以看到的视频片段如图所示,首先是格式上的时间零点,然后是音频首帧时间点、视频首帧时间点,最后是标注点。

视频生产环境下的音视频解决方案

图中上部分是服务器的原片,因为用户比较专业,大部分上传的片子都是如图所示,也就是音频时间原点和视频时间原点几乎是一致的,甚至有些在上面打了时间码。

但我们现在所用的转码服务经常会把转码流变成图中下部分,也就是它们起始时间并不一致。所以在找一帧画面时是需要基准点的,一般基准点是视频图像的首帧,也就是start time,然后标记时间戳是以视频时间的start time基准点去找。

视频生产环境下的音视频解决方案

我以前是做网页播放器出身,网页播放器会对start time进行处理。因为依据图中的转码流处理,如果start time是4秒钟,首屏时间就要等4秒之久,所以一般会计算一个Base-Time,也就是把音频和视频的start time小的值作为基准时间点,作为时间零点,之后的每一帧都会减去这个时间点。像这种时间点的控制就会造成真正的start time其实并不是首帧的PTS,这时MSE Buffer就需要再一次找齐时间点。

这其中会有一个坑点,现在的时间点在浏览器上有可能会被清除掉,因为浏览器有一个机制是播放一定时间时会把前面的缓存清除,以节省内存空间,但这时候的start time点就不准了。所以在取视频的时间点时要保证是第一个片段塞进MSR Buffer。

视频生产环境下的音视频解决方案

根据图中所展示的处理,目的是加速起播时间,其次是尽量保留展现数据

视频生产环境下的音视频解决方案

因为小程序播放器是小程序的底层,它的起始时间点是视频的首帧,这是利用用户打好时间戳的视频,根据视频的转码流和源流PTS对出来的,小程序的基准时间点为0。

视频生产环境下的音视频解决方案

小程序以视频为基准播放,无需特殊处理。小程序另外一个坑是小程序为了保证它的消化不会过大,会保持timeupdate为250ms,需要精确到帧,必须自制定时器。但需要注意,定时器过多,会导致程序崩溃,建议做全局定时器。

视频生产环境下的音视频解决方案

这部分是关于画面的定位,这比时间上的一致性效果要好得多,图中展示的是一个特殊情况,图中圆点是基准点,内部方形是实际画面,外部是播放框。以实际画面为准,将它的宽和高定一个百分比作为标记点。即使这个视频被处理了,也可以根据相对标点找到实际位置。

4

拓展性

视频生产环境下的音视频解决方案

这部分介绍我们系统的扩展性,图中是Ahri整个架构图,首先Ahri会创建workflow并下发任务,这些任务可能会在Ahri自己的服务上进行,也可能在云厂商服务上进行。如果云厂商质量达不到我们的精度,需要做自己的服务时,可以直接在workflow这一层做迁移,如果需要加比如第三方转码时,可以横向扩展我们的workflow。

视频生产环境下的音视频解决方案

LiveVideoStackCon 2020  北京

2020年10月31日-11月1日

点击 【阅读原文】 了解更多详细信息

原文 

http://mp.weixin.qq.com/s?__biz=MzU1NTEzOTM5Mw==&mid=2247498260&idx=1&sn=bd3d798ebc2c5d4a15c7172267b18fb6

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 视频生产环境下的音视频解决方案

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址