MX Player在线播放优化

原创
2023/07/10 17:59
阅读数 129
AI总结

所有在线内容播放,都面临一些共同的问题:启播慢,seek慢,码率切换慢。而随着互联网的发展,用户对这些方面的要求越来越高,对慢的容忍度越来越差,如何解决这些问题,就成了MXPlayer 在线业务初期优化的重点。

本次分享将分为四个部分:第一部分介绍MXPlayer 如何解决起播慢,seek慢;第二部分介绍如何解决码率切换慢的问题;第三部分介绍缓存面临的问题,以及缓存是如何为前两部分服务的;最后一个部分介绍在复杂业务下,多播放器实例是如何管理的,通过以上几个部分为大家介绍MXPlayer 对在线内容播放优化的经验。

文/赵琳琳

整理/LiveVideoStack

大家好,我是赵琳琳,来自MX Player。我的分享主题是:MX Player在线播放优化。

首先简单介绍一下业务背景:MX Player起初是一款比较纯粹的本地播放器,其体积小,但功能强大,在全球各个地区都有不少的活跃用户。随着时间推移,公司在产品策略上也进行升级,引入了在线化的内容如影视剧、短视频、直播等。

虽然全球都有MX Player的用户,但其中主要用户来自于印度地区。印度地区的用户比较有特色,第一是语言(有十几种主流语言);第二是网络(4G网络占多数,家庭有线宽带较少);第三是设备(偏低端机型,存储空间小)。

随着在线内容的引入,也出现了一些问题。例如启播慢、seek慢、码率切换慢、缓存命中率低、代码复杂度高等。

今天的分享内容主要围绕以上的问题展开,首先介绍秒开、快速seek是如何实现的;之后是平滑码率切换的技术细节;然后是缓存面临的挑战;最后是多播放器事例是如何管理的。

-01-

秒开

第一部分,秒开。如何让用户尽可能快地看到视频内容,是所有在线播放面临的难题。有数据表明,等待时间越长,用户流失越严重。

根据统计,热度视频平均启播时长在2.5秒左右。

经过进一步的分析,发现其中绝大多数时间用于下载数据。

那么如何减少用户的等待时间呢?我们分析了几个优化方向,首先解码占用时间是较少的,优化空间有限;启播缓冲区大概需要2秒等待时间,我们认为这个时间已经很短了,所以不选择减小以优化;最终我们经过分析对比选择了预加载方案。

预加载的流程是:首先服务端根据一些策略判定哪些视频需要预加载,并且把信息告诉客户端。客户端收到请求后,会启动预加载程序。预加载程序会在视频没有播放的情况下启动预加载,把需要加载的视频头2秒放到缓存内。

策略上线后,热度视频的平均启播时长由2.5秒降到1.8秒。如果预加载的缓存命中,启播时长可以达到0.5秒,收益非常可观。

那么如何决策哪些视频需要预加载?服务端会根据视频的标签(新剧/推广/热度)等进行打分,最终做出决策并告知客户端,启动预加载程序。

-02-

快速seek

接下来介绍快速seek。和启播一样,等待时间越长,用户流失越严重。

我们先看一下优化之前的seek过程。假设用户要seek到A点,播放器首先会进入暂停状态,并缓冲接下来6秒的数据,完成之后开始播放。

经过分析,发现用户seek平均等待时间是3.4秒

那如何减少seek时间呢?

前文有提到预加载方案,是否适用于seek呢?答案是No,因为并不知道用户要seek到什么位置,除非缓存整个视频,显然这是不合适的。

另外一个方案是减小缓冲区,例如从6秒调整到4秒或更短。但这种方法比较简单粗暴,无法预知其是否有负面的用户体验影响,所以这个方案也被否定。

那么如何解决呢?经过分析和观察,我们发现当播放器当前的下载速度大于播放速度,不论缓冲区有多少数据,播放都是流畅的。

根据以上结论,我们得出一个快速seek方案:用户seek到A点,播放器暂停并缓冲1秒,得出当前下载速度D和常量播放速度P,如果D>=P,则直接开始播放;如果D<P,就会执行缓冲6秒数据再开始播放。

策略上线后,数据统计分析显示平均等待时长由原先的3.4秒降为2.5秒。

-03-

平滑码率切换

接下来讲平滑码率切换,首先看一下优化前的流程。

箭头所指为当前播放器进度,蓝色为已缓冲内容。如果开始切换,播放器会暂停,并丢弃当前的缓冲区,接着缓冲对应码率的6秒数据,再开始播放。

经过数据统计,码率切换平均等待时间为2.8秒。

如何减小切换等待时间呢?同样的,减小缓冲区的方案比较简单粗暴,直接pass。

可以注意到,图中红色的丢弃缓冲区,原本是可以正常播放的,只是因为用户需要切换码率,所以丢弃。那么是否可以重用该缓冲区呢?答案是肯定的。

如图是优化后的平滑码率切换方案:当播放器进行码率切换时,并不会进入暂停,而是继续播放当前码率上已经缓冲好的数据,并开辟一个新的缓冲区来缓冲对应码流的6秒数据,同时当旧缓冲区数据播放完,进行缓冲区切换。

业务上线后经数据统计,优化后的码率切换平均等待时间由原来的2.8秒降为0.4秒。

-04-

缓存面临的挑战

接下来介绍缓存面临的挑战以及对应的解决方法。

前述提到MX Player在线用户主要分布在印度,他们的设备偏低端,内存空间普遍都非常小。在业务上线之初,我们给缓存空间定了一个上限为2G。上线后,后台收到了大量的用户反馈,说App占用空间过大。经过我们的讨论和决策,把缓存下调到500M,这带来了一个直接的问题:命中率降低。

如图是优化前的缓存布局,在容量不变的情况下,分片越小,个数越多,命中率就会越高。

基于上述结论,我们得出一个方案:两段缓存

我们把一个完整的分片拆为头尾两部分,头部优先级高,尾部优先级低,并放入缓存空间。当空间满了之后,会先清理掉所有尾部数据。

这是优化后的缓存布局。左图为装满6个分为头尾的分片数据,当用户继续使用一段时间后,缓存空间布局就会变成右图的样子,只留下了各个分片的头部数据。

这时如果播放器需要播放内容,到缓冲区查找数据,就会发现右图的命中率一定是比左图布局要高的。

这时回顾一下预加载和快速seek:预加载方案是缓存视频头2秒,和两段缓存中的头部分片数据是吻合的。在快速seek中,如果在1秒缓冲内可以命中缓存的头部数据,并且下载速度大于播放速度,就可以直接启播。

两段缓存方案在后台默默地为其他功能进行支持,这些方案是相辅相成的关系。

-05-

多播放器如何管理

接下来介绍多播放器如何管理。

随着业务发展,播放场景也越来越多。这些播放场景之间并不是彼此孤立的,如PIP播放和音乐播放就是互斥关系。当PIP正在播放,用户需要切换音乐播放,就需要暂停PIP,反之亦然。

另外,feed流播放需要和PIP播放以及音乐播放共存。因为feed流播放是无声和自动播放,我们并不希望这种播放打扰用户行为。

随着在线业务高速发展,随之而来的是一系列问题。

经过讨论决定,我们选择重构部分代码以解决问题,同时定下几条重构原则:

第一,业务代码彼此独立:业务之间无需互相知道;增加新业务无需修改其他业务;启动播放无需判断是否有其他播放。

第二,环境变化自我感知:当App失去声音焦点,自动暂停;程序进入后台,播放器按需暂停;进入音乐播放后,自动暂停PIP。

基于以上原则,我们重构了代码,结构如图所示。Player代表底层播放器,并抽象出来PlayerContext的概念。每一个Player必须和Context进行attach,才能播放。Context有一个属性为ready,只有在ready情况下,才能够让播放器启动,否则会暂停。

Context有几个具体的实例,首先是Activity,它是一个安卓标准组件,只有在unReceived的时候才是ready状态;Fragment和Activity类似,只有unReceived才是ready状态;Screen在锁屏时为非ready状态,其他时候都为ready;Global永远都是ready状态。

Activity和Fragment主要用于详情页播放和feed流播放;Screen用于PIP播放;Global用于后台播放。

Player和PlayerContext之间不直接交互,而是通过PlayerManager进行管理。它会监听和维护所有PlayerContext的状态,并根据其状态改变来控制播放器的生命周期变化。同时,Manager会维护Player和Context之间的映射关系。

经过这样的结构重构,我们的业务代码基本实现了解耦,新增业务不需要改动已有业务,并且样本代码不需要出现在具体业务中,PlayerManager可以感知并通知Player进行操作。

以上就是我的全部分享,谢谢大家!


▲扫描图中二维码或点击“阅读原文”

查看更多LiveVideoStackCon 2023上海站精彩话题

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
AI总结
返回顶部
顶部