直播平台的高并发架构设计3.3-播放器端

这是播放端的实现框图，中间少画了一个地方。这就是个传统的播放器框图，没有体现出我们的核心的技术点，数据从网络接收进来之后，经过RTMP的Demux之后，我们是有一个模块的，这个模块会去判断当前视频是否需要被丢弃，这个原则也和我们接收缓存有关系，我们缓存配的是两秒，如果超过两秒，或者超过某一个其他的阈值的话，我们会开启丢弃的模式。

这个丢弃有多种策略，有的是直接丢掉帧，有的是快进。如果做过播放器就会知道，传统的视频追赶一般都是在视频解码之后来做追赶。解码就意味着会耗CPU，尤其是现在如果我想播720的视频，光是解码就基本上勉强实时的话，根本就没有什么追赶的余地了。

所以我们在算法上做了一些优化，我们拿到这个视频的时候会先去判断它是不是一个可以丢的，如果它是可以丢的，在解码之前我们就丢，但是这样丢会出问题，因为解码器会内部不连续，一旦解码器内部不连续了，它可能会产生黑屏，所以我们即使要丢，也是在解码器里边做了一些定制化的开发，还是把要丢的视频传进去，让它自己来丢，它不去解，这样就能达到更快速的把这个视频丢掉，赶上现在的实际主播的进度。

这样的话，如果我们网络状况很好，不担心以后抖动的话，我们能做到从推流到观看是2秒的延迟，但是一般我们都控制在4秒，就是为了防止抖动产生。

刚才说的是丢的这种逻辑，如果想快进，类似斗鱼那种，在一点进去之后，开始画面是很快过去的，但是没有音频，我们现在在做有音频的方式，视频在快进，音频也在快进，这样的话声音会变调，因为采样率变了。以前在做端的经验的时候，也做过这种变速不变调的算法，很多开源的，改改其实效果都能不错，这种算法只要做好逆向优化，放进来之后，音频也能保证不变调。

日志收集，可能日志收集不是所有的开发者都愿意接受的，但是有的开发者是逼着我们要我们做，因为他们需要这个数据来定位问题，就像我刚才说的，经常有人会问，是不是又卡了，这个问题被问多了之后，大家都希望知道为什么卡，端上的日志不收集上来是没有办法定位出这个问题的。我们现在有日志收集的策略在用户同意的情况下，会定期可能几百条打成一个ZIP包发上来，这个数据是我们和用户共享的。

播放器其实我们也趟过坑，最开始我们基于VLC做，因为最开始我们做媒体云是做点播的业务，VLC是个挺好的架构，但是用VLC做追赶这个逻辑就能把人坑死，特别难改。因为它里头一层一层耦合的很重，即使到最后改完了，声音也有卡的情况。后来还是用更简单的框架，自己来写上层的所有控制。所以在移动端的直播场景和点播场景还是有很大区别的，这也就是为什么最近突然又出现了很多在视频语音业务上的门槛。

这页我刚才已经陆陆续续都提到了，就是我们如何来定位问题，如何满足播放器的兼容，还有追赶的各种体验，发包的时候，我们会注意APP的大小。因为我们是一个采集和播放都是由我们提供的端到端的方案，有很多库是可以复用的，如果都用我们的话，我们可以把其中一些库做合并，最大程度节省我们提供的压缩包的大小。