分享到: 分享到QQ  分享到Twitter

作者: BigLoser    访问次数: 993 创建时间: 2020-05-17 16:45:18 更新时间: 2024-03-29 17:19:11

一、背景介绍,短视频关注秒播

 

近几年,短视频一直处于流量的风口,各大平台纷纷涉足。不同的业务形态对技术有不同的述求,传统长视频关注的是减少播放中的卡顿,降低用户 seek 的耗时;直播关注的是如何保证实时性;而短视频关注的是秒播。

为什么短视频关注的是秒播?一是因为短视频通常只有十几秒,一是短视频的消费带有很大的探索性和随机性。如果用户花几秒钟等待十几秒的视频,很有可能起播后还不是用户喜欢看的,这个代价对用户来说太大了,久而久之,就是用户流失的时候。

 

二、现状与目标

 

短视频播放相关的核心技术指标有两个:缓存命中率和秒播率。通常情况,缓存命中率越高,响应的秒播率也就越高。短视频秒播专项优化项目启动时,关于缓存命中率和秒播率,结合现状,目标为缓存命中率提升 40%,200 毫秒秒播率提升 150%,400 毫秒秒播率提升 25%。

 

三、困难和挑战

 

首先,我们是短视频分发消费场,属于上层业务,底层播放器链路和预加载模块对我们都是黑盒的,无法直接在底层从根本去优化;

其次,短视频分发消费场,用户诉求是随机的,当用户滑到不感兴趣的视频时,会立即滑走,以便快速探索下一个视频。这会造成用户停留时间很短(通常不到 1 秒),大大挤压了预加载下一个视频的时间,造成滑出来的视频大概率在线起播,如果恰逢网络不稳定,很容易造成起播慢;

再次,优酷的长视频和短视频共用一个播放器。长视频场景下,更关注的是起播之后的流畅度。故播放器为了保证起播之后的流畅度,有如下播放优先策略。

1)播放前,由于不确定本地缓存的视频流是否足够起播,所以开始播放时,为了防止预加载任务抢网络带宽,此时会暂停所有的预加载任务,以优先保证起播。起播之后,在当前播放视频缓存的视频流达到配置的水位,才恢复被暂停调的预加载任务;

2)配置的时间阈值(300 毫秒)内无法起播,则会等待缓存的视频流加载到指定水位(指定时长或者指定大小),才会开始起播。

播放器以上两点播放优先策略,放到在短视频场,就不适用了,甚至是矛盾的,这无形中大大增加了短视频秒播优化的难度。

 

四、行业做法

 

在开始优化之前,很有必要花些时间对行业做法深入调查一番。主要集中在两个方面,一个是货,即视频源;一个是预加载策略。

如下表所示,从数据上可以看出,优酷和快手两家的货大同小异,而抖音在视频编码上支持 H.265。

 

平台 时长 (s) 分辨率 码率 (mbps) 大小 (mb)
优酷 18 720p 2.45 5.6
抖音 15 540p 1.11 1.8
快手 20 720p 2.07 5.0

 

五、优化策略

 

视频起播耗时,主要有两个方面,一个是播放器准备耗时,一个是从网络加载视频流耗时。所以优化原则简单粗暴,就是在播放前,想尽一切办法,准备好播放器和将视频流加载到本地。

 

  1. 下拉刷新优化

feed 视频列表请求成功后,扣留列表中最后一个视频到内存中,然后预加载其视频流;下拉刷新时,将上次扣留到内存中的视频放在下拉刷新列表的第一个位置,同时扣留下拉刷新列表的最后一个视频,如此往复,保证下拉刷新播放的视频是本地起播。

feed 场景下,向下滑动出来的视频都是算法推荐,没有传统列表的分页概念。所以 feed 场景下,用户通常是一直向下滑动以获取新的推荐内容,用户没有下拉刷新的心智,故此优化项在此业务场景下收益甚微。

  1. 按需预加载视频流

现有预加载模块,如果业务方不设置预加载 buffer 大小,则统一为 400k,通过线上开关控制。优化后,业务方动态计算预加载 buffer 大小,计算原则就是预加载 3 秒的视频流。如果在视频播放时,3 秒视频流全部加载到本地,则既能保证起播,又能保证起播后的顺畅。

此项优化,收效同样甚微,按需预加载,只在一定程度上避免造成预加载任务阻塞,并没有从根本上提高预加载效率。

  1. 闲时任务

在视频播放超过 5 秒或者重复播放时,认为当前播放的视频流已全部加载完成,此时网络是空闲的,利用此网络空闲的时间,串行预加载后面的视频。

小视频业务大盘数据统计用户平均每个视频的消费时长为 6 秒,加上 1/3 的播放为重复播放,所以此优化项对于缓存命中率有较大提升。

  1. 预加载时机提前

利用滑动切换视频时,在滑动松手到滑动停止这段时间(300 毫秒),在保证滑动帧率的前提下,开启子线程预加载后面的视频,利用这 300 毫秒,预加载后面的视频流,保证本地起播。相比原先预加载时机是在滑动停止,当前视频起播后才预加载后面的视频,假设视频起播时间为 500 毫秒,则相比优化前,预加载时机提前了至少 800 毫秒,这是非常可观的提升。最后测试下来,也是此优化项对于缓存命中率的提升是最为明显的。

至此,关于缓存命中率的优化已经收尾,上线后大盘数据也验证了优化的效果,缓存命中率提升了 38%。

  1. 双播放器

上述的四项优化,都是业务层在有限的时间和空间里抠细节,在预加载策略上做文章,经过一系列优化手段,缓存命中率达成目标。

虽然缓存命中率完成目标了,但是核心的技术指标秒播率并没有完成,距离目标还有一定差距。这时候我们只能硬着头皮,想平时不敢想,做平时不敢做的,开始实施双播放器方案,空间换时间。双播放器方案原理比较简单,就是在当前视频起播之后,预准备下一个视频的播放器,两个播放器循环使用。

下一个视频的播放器一旦准备好,加上视频流已加载到本地,则起播非常快,几乎是视频直出的效果。但由于播放器准备更耗时,用户滑到下一个视频时,并不能百分百保证此视频的播放器已准备好。双播放器方案上线后,效果显著,200 毫秒秒播率提升 178%,400200 毫秒秒播率提升 29%。

 

至此,缓存命中率和秒播率圆满完成任务。

 

注解

1)秒播:1 秒内完成播放,后来常用于泛指起播速度;

2)秒播率:指定时间内起播的次数占全部播放次数的比例,比如 200 毫秒秒播率指的就是 200 毫秒内起播的次数占全部播放次数的比例;

3)缓存命中率:开始播放时,本地有播放视频的视频流,哪怕本地缓存的视频流只有一个字节,也认为是缓存命中,缓存命中率指的就是缓存命中的播放次数占全部播放次数的比例;

4)编码格式:又称视频编码规范,视频压缩格式。通常原始视频非常大,不方便存储和传输,所以需要将原始视频进行压缩。视频编码格式很多,这里不累述,优酷场主要的视频编码格式有 H.264 和 H.265,H.264 和 H.265 的详细区别这里也不累述,总的来说就是,H.265 的压缩效率更高,传输码率更低,视频画质也更清晰。

 

编者按:优酷的1080P和4K分辨率,国内最清晰了。

季度最有价值文章

月度最有价值文章

帖子投票

名称 是否有价值
kideny
BigLoser

投票统计

是否原创: 0 %

0 % Complete (success)

是否有价值: 100 %

100% Complete

是否有素质: 100 %

100% Complete (warning)

是否合法: 100 %

100% Complete

   群组工具

   外部链接