|
10 | 10 |
|
11 | 11 |
|
12 | 12 |
|
13 | | - |
14 | 13 | ### 成本优化 |
15 | 14 |
|
16 | 15 | #### 预下载控制 |
| 16 | + |
17 | 17 | - 不限速 |
18 | 18 | - 非高峰时段,预下载N秒 |
19 | 19 | - 高峰时段,预下载M秒 |
|
29 | 29 | 对解码能力进行评估,来通过机型打分控制是否使用H265以及是用360p还是480p。 |
30 | 30 | 但是H265全部切换成本较高,牵扯到转码成本以及存储成本,所以可以只对热点的视频去进行编码,这样少量的视频就可以带来可观的效果。 |
31 | 31 |
|
| 32 | +#### 防盗链 |
| 33 | + |
| 34 | + |
| 35 | +会有一个防盗链的请求,通过 HTTP 拿到真实的播放 URL 才可以下载数据。 |
| 36 | + |
| 37 | +但是在手机上执行 HTTP 请求非常耗时,这里走私有长连接通道做这个事情。 |
| 38 | + |
| 39 | +#### PCDN |
| 40 | + |
| 41 | +有关CDN相关可参考[CDN及PCDN](https://github.com/CharonChui/AndroidNote/blob/master/VideoDevelopment/CDN%E5%8F%8APCDN.md) |
| 42 | + |
32 | 43 | ### 秒开 |
33 | 44 |
|
34 | | -能立即起播,不会产生缓冲 |
| 45 | +能立即起播,不会产生缓冲。秒开很简单,预加载数据就行。不够快就预解封装、解码,还不够快就再加上预渲染。但是秒开又是最难的。 |
35 | 46 | 播放器初始化->业务逻辑->DNS解析->CDN下载数据->解码->渲染播放 |
36 | 47 |
|
| 48 | +“在所有环节中,短视频列表播放的体验非常重要。例如抖音,你会发现起播非常快,循环播放也很流畅。这是怎么做到的呢?这就是通过列表预加载技术实现的。常规的预加载是通过多个播放器来实现的,播放当前视频的时候去预加载下一个视频,这个方案的缺点是实现逻辑非常复杂,同时也消耗更多性能。所以,阿里云独创了列表播放器,通过简单的接口调用就可以实现列表的预加载播放。它有几个特点,首先是能够做到防卡顿的缓存策略,通过对缓存的管理,可以灵活控制卡顿期间的预缓存策略,同时优化缓冲的淘汰策略。第二是对滑动的流畅性针对性优化,保证每个视频停止的耗时在16毫秒以内。第三是采用了基于内存的预加载缓存技术,循环播放和秒开直接从内存读取数据,无需额外的文件操作。第四非常关键,是提供简单的接口,可以非常快速的实现短视频播放功能 |
| 49 | + |
| 50 | + |
| 51 | + |
| 52 | +#### 预加载 |
| 53 | + |
| 54 | +预加载能减少首次缓冲时间,但是预加载不能和当前播放的视频抢下载带宽,需要达到一个合适的阈值再开始下载。 |
| 55 | + |
| 56 | +优先保证封面图等信息完成后再根据云控的当前缓冲的时长等信息来控制是否要启动预加载 |
| 57 | + |
| 58 | +提升视频加载速度的常见手段就是预加载 ,即在用户播放之前,预先下载好一部分数据,这样在视频开播的时候就不需要等待网络请求。这里面有两个挑战,一个是预加载需要下载多少数据才算够呢?下载多了,浪费带宽;下载少了,不够拿来开播,也就无法满足快开的要求。拿 MP4来说,要解码出首帧,首先需要解析完 moov (可以理解为 header),而 moov的大小则和视频的长度相关。所以需要针对不同的视频计算出不同的预加载大小。第二个是即便视频数据已经预先下载完毕,但在开播前播放器的创建,外壳 view的布局,内核中的 MP4 解封装、解码、渲染仍然会导致有数百毫秒级别的耗时,在全屏沉浸式的场景中仍然能被用户感知到加载过程。 |
| 59 | +为了实现极致的快开体验,我们实现了多实例的播放器,在预加载的基础上更极致地缩减开播耗时,实现了直出的开播体验。一般情况下,卡顿和视频清晰度是互斥的,清晰度越高,视频码率越高,用户越容易遇到缓冲卡顿。为了一个指标牺牲另一个指标是不被接受的。我们的视频内容在下发前会在云端预先转码成多档清晰度,并在端的播放器实现了一套在播放过程中基于用户的网络类型、平均网速、视频时长等指标动态升级或降级清晰度的策略,保证了绝大多数用户都能观看到匹配自己网络条件、最高清晰度的视频,在提升整体视频质量的同时守住了卡顿率。 |
| 60 | + |
| 61 | +- 预加载时机提前 |
| 62 | + |
| 63 | + 利用滑动切换视频时,在滑动松手到滑动停止这段时间(300 毫秒),在保证滑动帧率的前提下,开启子线程预加载后面的视频,利用这 300 毫秒,预加载后面的视频流,保证本地起播。相比原先预加载时机是在滑动停止,当前视频起播后才预加载后面的视频,假设视频起播时间为 500 毫秒,则相比优化前,预加载时机提前了至少 800 毫秒,这是非常可观的提升。最后测试下来,也是此优化项对于缓存命中率的提升是最为明显的。 |
| 64 | + |
| 65 | +- 多播放器 |
| 66 | + |
| 67 | + 空间换时间。双播放器方案原理比较简单,就是在当前视频起播之后,预准备下一个视频的播放器,两个播放器循环使用。下一个视频的播放器一旦准备好,加上视频流已加载到本地,则起播非常快,几乎是视频直出的效果。但由于播放器准备更耗时,用户滑到下一个视频时,并不能百分百保证此视频的播放器已准备好。 |
| 68 | + |
37 | 69 | #### MOOV后置 |
38 | 70 |
|
39 | 71 | 很多手机为了偷懒,录制完视频后才知道视频信息,所以把moov放到末尾。对于moov放到视频最后的情况下,就要多一次seek,当从头开始解析的时候如果发现未找到moov信息,需要将其seek到尾部再去寻找,这样会导致起播慢。 |
|
55 | 87 |
|
56 | 88 | DNS解析加快,通常,DNS解析,意味着要把一个域名为xxx.com解析成ip过程,平时请求网页,网络差,就会打开网页半天。 |
57 | 89 |
|
58 | | -#### 防盗链 |
59 | 90 |
|
60 | 91 |
|
61 | | -会有一个防盗链的请求,通过 HTTP 拿到真实的播放 URL 才可以下载数据。 |
| 92 | +### 监控 |
| 93 | + |
| 94 | +监控上报,肯定是不可缺少的,这是一个成熟的项目必备的要素。 |
| 95 | + |
| 96 | +1. 问题定位,老板跟用户反馈说我这个视频播不了,要有一套成熟的问题定位的方式; |
| 97 | + 传统的捞Log方式大家都有,但是这种方式效率太低,需要等用户上线之后才能捞到Log,Log捞到之后还得花时间去分析。我们做法的是在关键问题上做一些插装,把每一类错误和每一个具体的子错误都能定义出来,这样一看错误码就知道播放错误是由什么原因导致的。还可以把每次播放视频的链路所有关键流水上报到统计系统里来,每一次播放都是一组流水,每一条流水里面就包含了例如首次缓冲发生的Seek,或下载的链接是多少,下载的时间是多少,有了这些流水之后,用户反馈播放失败,我首先可以用流水看发生了什么错误?错误在哪一步?每一步信息是什么?几秒钟就可以定位到问题。 |
| 98 | + |
| 99 | +有了这个数据上报之后,还可以做一些报表。比如说可以做错误码的报表,有了报表之后就可以跟进哪个错误是在TOP的,负责人是谁,原因是什么,都可以看到。 |
| 100 | + |
| 101 | +我们也有自己实时的曲线,可以看到各项数据的情况。在告警方面,基于成功率和失败率的统计,进行实时告警。 |
| 102 | + |
| 103 | + |
| 104 | + |
| 105 | + |
| 106 | + |
| 107 | + |
| 108 | + |
| 109 | + |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | + |
| 114 | + |
| 115 | + |
| 116 | + |
| 117 | + |
| 118 | + |
| 119 | + |
| 120 | + |
| 121 | + |
| 122 | + |
| 123 | + |
62 | 124 |
|
63 | | -但是在手机上执行 HTTP 请求非常耗时,这里走私有长连接通道做这个事情。 |
64 | 125 |
|
65 | | -#### 预加载 |
66 | 126 |
|
67 | | -预加载能减少首次缓冲时间,但是预加载不能和当前播放的视频抢下载带宽,需要达到一个合适的阈值再开始下载。 |
68 | 127 |
|
69 | | -优先保证封面图等信息完成后再根据云控的当前缓冲的时长等信息来控制是否要启动预加载 |
70 | 128 |
|
71 | | -#### PCDN |
72 | 129 |
|
73 | | -有关CDN相关可参考[CDN及PCDN](https://github.com/CharonChui/AndroidNote/blob/master/VideoDevelopment/CDN%E5%8F%8APCDN.md) |
74 | 130 |
|
75 | 131 | --- |
76 | 132 |
|
|
0 commit comments