红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

优酷安卓短视频秒播优化

  • 2020-05-16
  • 本文字数:2518 字

    阅读完需:约 8 分钟

优酷安卓短视频秒播优化

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

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


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

二、现状与目标

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

三、困难和挑战

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


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


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


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


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


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

四、行业做法

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


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


平台时长(s)分辨率码率(mbps)大小(mb)
优酷18720p2.455.6
抖音15540p1.111.8
快手20720p2.075.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 的压缩效率更高,传输码率更低,视频画质也更清晰。


作者 | 阿里文娱高级开发工程师 乐想


2020-05-16 11:583078

评论

发布
暂无评论
发现更多内容

架构师培训第一周学习总结

跳蚤

食堂就餐卡系统设计

永不言弃

架构

第十一周课后练习

晴空万里

架构师训练营第一周作业-命题作业

阿德儿

架构师训练营第一周作业-学习总结

阿德儿

[架构师训练营] 食堂就餐卡系统设计

Fango

架构师训练营 4 期

北极科考:我们为什么要在北极呆上一年?

脑极体

物联网基础知识整理及实战

garlic

物联网

知识改变命运,你相信这句话吗?

熊斌

成长 演讲 教育

甲方日常 78

句子

工作 随笔杂谈 日常

架构师训练营第六周课后作业

万有引力

架构师第一周总结

永不言弃

[架构师训练营] 第一周学习总结

Fango

架构师训练营 4 期

LeetCode题解:264. 丑数 II,暴力法,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

分析了2020年3万多条的微博热搜,我看到了什么

CoderW

Python 程序人生 爬虫 后端 微博热搜

系统安全高可用总结

Mars

架构师训练营第 11 周课后练习

菜青虫

Week11总结

lggl

指令重排序、内存屏障很难?看完这篇你就懂了!

Java鱼仔

Java 程序员 面试 JMM 指令重排序

第九周-学习总结

Mr_No爱学习

系统高可用原因分析&方案

Mars

架构师训练营 1 期:大作业(一)

piercebn

架构师训练营第 1 期

第六周学习心得

cc

SAML和OAuth2这两种SSO协议的区别

程序那些事

权限系统 OAuth2 程序那些事 SAML SSO

Spring 源码学习 12:registerBeanPostProcessors

程序员小航

Java spring 源码

架構師訓練營 大作業二

ilake

第六周命题作业

cc

食堂就餐卡系统设计

跳蚤

第一周架构方法-周总结

潘涛

架构师训练营第 11 周学习总结

菜青虫

编程常用的加密方式

皮蛋

加密 加解密 加密技术

优酷安卓短视频秒播优化_文化 & 方法_阿里巴巴文娱技术_InfoQ精选文章