00:00
大家好,我是来自腾讯云的李振通,下面由我给大家分享一下腾讯云四立方播放器的技术实现与应用。那今天分享的主要内容分为三块,首先先介绍一下腾讯云视据播放器的一个相关技术背景,然后是咱们业务侧经常应用的相关场景的一个技术实现与方案。那先去讲我们的第一部分。首先,先介绍一下腾讯云是一般播放器相关技术背景。腾讯云事一般播放器基于腾讯视频同款内核打造,完美融合腾讯视频的一个能力,视频的一个兼容性、适配能力以及播放稳定性大幅提升,解决了系统引擎各种播放异常问题。那具备如下几个特点,第一个特点是功能,功能层面覆盖长短视频点播、直播场景,打造业界领先的自适应技术,画质提升以及版权保护等解决方案。那我们倾力打造满足各项业务诉求的一个功能的一个SDK。第二点就是我们的性能稳定可靠,这里经过一级的一个用户的一个验证,对业务关注的起播速度做了深度优化,起波平均速度低至100毫秒。
01:14
我们也具备了卓越的视频容错的一个兼容适配能力,对大量的非常规编码的一个视频做了测试,这些测试这些视频在系统播放器的一个表现,一般表现为黑屏或者音化不同步等异常现象,在我们的四立方播放器上面都能够很稳定的一播放,在平台支撑下支持下我们也支持了安卓。I web以及等平台,那这里左边是我们的一个官网的一个在线文档的一个二维码,里面具备有啊,里面有更加具体的介绍,大家可以扫码观观看。那在追求我们卓越内核的同时,我们非常也非常重视业务的一个接入成本,为了大力降低业务侧这里开发难度以及工作量,我们对主流场景做了相关完整的呃,相关完整的一个完整组件以及解决方案的一个DEMO,这里全全开源,那本身也是一个比较完整的一个模块或者组件,拿来去用,支持自定义修改,那今天会重点介绍这里面包含的一个经典场景的一个超级播放器UI组件,以及我们经常遇到的业务测,经常遇到的短视频场景的沉浸式播放或者非得播放。
02:31
那下面介绍一下精简产品的一个应用方案。那这是一个我们业务侧经常运见的一个经典场景,先是一个小窗播放,然后我们支持与全屏播放的一个切换,那手指在右边竖着滑动可以控制亮度,左滑左边滑动可以控制音量,那支持滑动控制进度等等的一个操作,那我们的抽击播放器UI组件分装的这一类一类的一个基础操作功能,也支持了一个进阶功能的一个分装,比如说弹幕在播放同时,在视频上方有一堆的弹幕飘过,这是一个比较常见的一个,呃。
03:11
一个现象,对,然后我们也支持了动态水印,可以把用户的ID放在在视频上方进行滚动,达到一个比较好的一个安全性的一个呃,一个效果,然后也支持了。呃,视频会员试看,非会员观看多少秒以后,就可以弹出一个会员的一个提示,购买窗等等,然后也支持一个具体播放。那怎么接入使用呢?这里非常的一个简单快速,仅用一个很少量的一个代码就可以接入使用,首先先集成我们的腾讯呃超级播放器UI组件,然后在UI上面加入我们的play view。分装我们的super play model,把我们要播放的URL、封面地址等填入,再调用我们的super playvi的play model进行就可以进行启动播放。那对于进阶场景,比如说前面所说的弹幕,以及说是会员视看动态水印等等,我们也仅仅只需要在super play model里面去配置相关的一个信息,比如说观看多少分钟动态文本的水印以及大小等等。
04:17
就可以很简单的达到我们的一个目的。接下来是我们一些主流场景的一个短期方案的一个应用实现。方案的一个介绍。这也是我们常见的两种场景,一个是沉浸性,沉浸式播放场景,比如类似我们微视抖音这种一次只看到一个视频,上下上下滑动去切换另外一个视频,另外一个就是非得流场景,一个页面可以同时出现几个视频,第一个完整的出现的视频自动播放,这些场景的界面分布,所以说我们业务侧非常重视这里的一个内存性能,一个占用,那为了更加顺滑的一个体验,我们也非常追追求极致的一个起搏速度。
05:00
这是一个快速消耗内容的一个场景,可能一个视频,呃,用户连看都不看就直接划过,那为了降低这里业务带宽的一个流量的一个成本消耗,那也需要对这些场景做一些流控策略,那这里我们常规的一个时间思路就是利用一个列表组件去复运用,在播放第一个视频的时候,对下一个视频进行预播放,已达到滑动,下一个视频就可立立马放,如果这个界面可以看到很多视频,那么我们就可能会起多个。播放器进行播放,那么就会发现这里的内存消耗非常大,而且反复销毁创建播放器也会带来比较多的一个内存芯片。那我们怎么进行优化呢?我们优化思路就是。建议不超过两个播放器实例,并通过服务去管理啊,播放器的复用于使用如图所示,在上层的一个应用逻辑层,也就是说UI和业务这一层,这一层业务侧可以根据自己的业务特性进行设计,那这里可以采用MVC或者MVVM的一个设计模式。我们这里。
06:07
主要关注的是在如何使用我们两个播放器实例进行一个复用,那我们可以在在我们的应用逻辑层下面创建一个服务层。然后创建一个类似线程池的一个管理,我们可以把它命名为play player po manager,那这里我们提供两个接口,第一个接口是update to player主要是运营播放器对复用的管理。那这里的算法怎么去做呢?可以看到我们右右边的这个表格图,假设我们停留在第一个视频,那底下的序列号是二和三的一个视频,这时候我们可以再把一和二的一个ul放进我们的poor player去创建我们的一个。呃,创建我们的播放器,那并且设置auto play force进行预播放,因为我们知道当前要播放的是啊第一个,所以说业务侧就可以通过get player。
07:04
PER2的一个接口,以ul作为key的一个方式去取得要播放的配,然后调用雷进网器播放,当我们往下滑到二的时候,然后这时候我们的就需要从我的播放器池子需要从原先的一和二的一个play的一个变成呃,Ul的一个播放器,变成二和三的一个UR播放器,因为二还在,所以说仅仅需要把原先一的player复原给第二,第三个视频去预播放,然后去第二个视频,这呃一个player去player,那这里我们对着播放器做了一层封装,命名为T。Data player weapon,那之所以有这一层分章,主要是便于业务侧这里的一个统一控制,比如player con,以及一些业务特性的一个行为等等,那如果我们这时候快速滑到了四,这时候二和三的一个池子就会变成四和五,那赋予了原先给二和三的一个播放器对象,这时候我们会带来什么问题呢?会发现我们原先呃塞入的呃二和三呃,Stop加叉话,我们四和五是重新加入的,这里都没有经过个预播放,那这里的起播速度肯定会受到比较大的影响,那接下来我们会看一下我们起播速度如何进一步的一个优化。
08:24
那这是一个简化的一个起播过程的一个流程,从业务的一个获取数据,呃数据开始往,然后作为作为做了我们的个UI展示,接着对应我们的一个一个分面展示,然后我们就开始进行一个UIL以及发飞机一及以及一个播放器一些这个配置,然后就传递到我们播放器环节的播放,那播放器环节就经过了像服务器请求读取视频文件,把读下的文件进行一个解封装解码,然后到达一定的buffer以后,就启动一个播放回调,一个守帧一事件,业务侧收到首帧事件回调以后就进行一个隐藏分辨,那对整个过程进行一个优化,我们把重点进。
09:08
就换到引起呃后时操作的地方,那这里假设业务的一个其他过程都非常理想的一个情况下,我们知道后时操作主要是要关注一个IO的操作,那这里我们会看到第一个引起耗时操作的一个地方,就如图片上面所示的那个第一个位置,那这这时候业务去获取数据,这是一个网络的一个IO相关的一个操作,那这里就需要进行一个提前获取数据,获得一个。做好缓存的一个相关的一个,呃,管理,那第二个地方就是获取视频链这里。那这里有一点关注,如果是用fire ID去播放,因为fire ID仅仅是一个ID样式,它没它不是ul,所以说fire ID传入播放器会有一个换链的一个过程,这是一个呃,比较厚实的一个网络的一个请求,一个过程,那所以说我们就需要提前换好链,那如果这里配置防盗链,这里有外还有一定的一个有效期,那还要做好链接有效期的管理,如果是多码率视频,就不能等到播放器启动的时候再做推流,这个时候如果采用非平滑切换的一个方式,就会引起比较大的一个消耗,所以我们可以事先配置好要指定播放的一个码流。
10:24
那播放器缓存的一个消耗主要是两个地方,第一个地方就是网络。这一个第二另外一个地方就是一个解封这样一个解码的一个操作,那对于网络我们需要重点关注我们视频的一个部署情况,如果是刚上传的一个视频,那西站节点是否预热,是否呃已经ready,可以供业务侧这边,网络侧这边去。去很好的一个访问,那对端测来说,主要是可以通过我们的预下载,或者前面所说的预播放的一个方式,把我们要播放的一个视频先预先下载一部分下来,然后到时候直接调用雷众去就可以进行播放,那对解封装解码的消耗,我们也可以通过我们预播放机制去。
11:08
解决这种一个提前消耗。那前面所说的预下载和预播放这两者有什么区别呢?那预播放机制就是创建一个播放器,并且启动下载和解码环节,首帧解析出来之后暂停播放器,使用步骤就是在stop play之前设置auto playfor,要播放的时候调用一下接口就就好。那播放器的一个。啊,预下载的机制就是不需要创建我们播放器实例,预先下载视频的部分内容,不需要启动解码和解封装环节,使用方法就是调用我们的那个t word playlo manager的预下载接口,启动播放的时候跟正常启动播放器一致,那我们来具体对比一下两种方式的一个核心区别,那前面介绍我们预播放是需要启动我们的播放器实例,以及我们的解码器的一个相关操作,那这里必然带来一定的一个性能性能消耗,所以会占用以及一个内存和CPU一个消耗,但是而我们的预下载不需要启动播放器,不需要解码环节,性能消耗第一。
12:19
这是它比预播放的一个比较好的一个一一个点,但是它的起播速度会比预播放慢个100毫秒左右,因此我们可以根据业务特性采用其中一种或者两种一个都采用的一个结合方式。那我们针对M3U8的一个多码流视频也做了一个针对性的优化,我们多码率M3U8在播放器未播放之前,我们完全不知道这里面的一个是有几个码流,就如图片所示,这这里面有四条码流,这是需要一个网络访问才能知道的,所以我们做了播放和预下载,也指指定好偏好的一个视频分辨率的功能,也就是说在我们起播前指定优先播放的视频分辨率,那播放器会查找小于或等于。
13:09
该偏好分辨率的一个流进行一个起波,起波后就没有必要再通过set bit rate index去切换到需要的一个指定的码流。那这里做了内存和起波速度优化之后再回我回到我们之前所讲的流控,如何进一步精细化,降低流量成本,我们提供了三个阶段。流控功能,第一个就是预播放的一个流控,在我们起播前可以设置最大的缓存大小,这时候我们就可以啊指定它预下载,只下载到多少大小就可以停止。第二个就是预下载阶段,呃,预下载阶段流控跟预播放是类似,也可以控制我们的一个下载页大小。那。这里在相关接口都有呃参数进行一个提供设置,第三个就是播放阶段的一个最大缓存的一个大小,那默认是30秒,那业务可以根据自己一个特性去设置,呃,必要的一个缓存大小的一个缓冲。
14:12
那结合。前面所讲的一部分,我们可以汇总一下总体的一个实现框架,就是如果采用我们预下载和预播放的一个结算方式,也仅仅在我们的服务层去加一个预下载管理模块就可。好,感谢大家一个聆听,谢谢大家。
我来说两句