珍稀干货！阿里 Web 音视频开发趟坑指南( 二 ) _Web

小tips:
打开chrome的媒体调试页面 chrome://media-internals 可以看到媒体播放相关的所有debug信息和error信息非常有用。其中就会有一条关于音频处理的提示：
当然这条显示的具体原因是自动切掉重叠overlap导致的。其实gap/overlap本质是一样的。怎么办？当然是播放器自己主动把洞填上。具体做法是插帧。目前主要是插静音帧，或者复制前一帧。静音帧会带来毛刺音，复制帧会导致拖音。我们目前的优化方案是判断附近的音频数据量，数据量大时说明此处声音丰富(其实不算靠谱，姑且这么处理，因为没有更好的判断方式)，如果插静音帧会毛刺很明显，所以此时用复制帧，反之插静音帧。
那些年我们趟过的坑
1、不同版本表现差异容忍度不同
1） Chrome 35分水岭。chrome35之前要求关键帧之后的第一帧dts不允许跟关键帧dts相同，否则抛错。
2）低延迟的模式。把转封装出来的FMP4中的视频轨duration(tkhd box) 设置成0xffffffff 时会让chrome认为这是直播流，会开启低延迟模式，所谓低延迟模式就是会极大的减少帧缓存，基本上视频帧立马解码立马播放减少每个分片的起播延迟。但是呢在CPU负载过高的情况下（解不过来）会造成视频频繁卡顿（网络无关的）。
2、不同浏览器表现有差异
1) timeupdate事件。W3C的标准是不能超过250ms触发一次。windows下360等浏览器会达到500ms左右。
2) safari对每一帧duration平顺度更敏感。safari需要对每一视频帧的duration标准化处理，例如TS下要处理成3600 。
3) 对洞的容忍度不同。chrome遇到buffer中有0.08的间隔以内会自动跳过去。像IE edge等浏览器不行会卡住，所以播放器一定要有跳洞逻辑。比如判断当前卡在洞的边界，要主动跳过去（seek）。
3、内存限制
通过MSE push给video的视频数据会在内部维护一个buffer，这个尺寸是有限制的。
1） chrome系列约100M
2） IE系列约30M
超过的话就会导致抛出 QuotaExceededError。所以需要处理好buffer的尺寸以及及时清除不用的buffer 。比如已经播放过的，正常浏览器会自己清除，但是不那么的及时。
优化
简单说一下卡顿相关的优化。

多级Buffer控制
ABR 自适应码率算法
基于WebRTC的P2P

1、多级buffer
为什么要有多级的buffer？因为video本身的解码buffer有大小限制，而且buffer过长会导致长时间解码，会导致CPU一直占用高。所以我们搞了两级buffer一级就是video的buffer另外一级是内存中的，只负责下载，二级很长。可以消除网络抖动带来的卡顿影响。
2、ABR自适应码率的算法
这个主要是来预测用户本身的带宽范围，然后选用不同码率的视频流来无缝切换播放。当然还有一些策略算法，比如根据用户现在buffer的水位，或者检测到用户频繁超时，来采用不同的策略。
3、基于WebRTC的P2P ‍‍
因为P2P是基于UDP的传输，可以突破一些带宽限制或网络拥塞而导致的卡顿问题。不过P2P不一定靠谱所以还是要辅以普通的HTTP传输相结合。我们一般是利用P2P加indexDB 来变相延长视频的缓冲区。因为P2P带宽成本便宜，我们利用P2P做了一个非常长又很便宜的buffer 。这样的话网络再波动也不会导致卡顿了。

【珍稀干货！阿里 Web 音视频开发趟坑指南】