直播系统保持流畅简析

直播系统流畅保证设计要点浅析

视频播放不流畅，一般有两个原因：
视频播放不均匀。
比如，视频帧原本是40ms一帧，如果我们播放的时候，一会20秒一帧进行播放，一会儿60秒一帧进行播放，那么最后结果必定是会出现卡顿。当然，如果根据视频时间戳，视频帧间隔本来是20-60帧，我们强行按照40-40播放，也会进行卡顿。也就是说，视频播放时，不遵循时间戳，将会导致卡顿发生。
视频有丢帧。
视频出现丢帧后，会导致视频不流畅。如果连续的丢帧太多，会导致出现明显卡顿。如果参考帧丢失，则会影响到之后若干个帧。

视频出现马赛克，一般有两个原因：
视频ES不完整，也就是说，出现了数据丢包。
解码器解码非参考帧时，参考了错误的参考帧。例如一个非参考帧之前的那个参考帧丢失，那么会导致本帧会参考上上个参考帧，从而可能出现马赛克。

事实上，在web网络中，网络情况非常复杂。同时保证视频的实时性和流畅性，是很难的。但是，牺牲实时性来保证流畅，这个是可以做到的。下面，将从3个方面来研究怎么来让视频的播放体验更好。（下面的优化，暂不考虑动态切换码率。）

视频编码发送端的优化。
编码发送端，首先必须保证时间戳的准确性，输入给编码器视频帧的时候，准确告诉其时间戳。时间戳精确度可以达不到27MHz，这个没关系，但准确性要保证。当然，精度需要至少达到毫秒级。
编码器发送数据的目标，是保证所有数据都完整的发送到服务器端。但网络情况的复杂性，可能导致一些时候偶尔无法做到这一点。我们要做到的是，就是让偶然的网络故障不影响网络数据的完整性。因此，我们需要在发送端进行数据缓存。需要建立一个发送缓冲区，编码后的数据，交给发送缓冲区，然后由发送模块全力将发送缓冲区内容发送到服务器。
如果网络出现意外的时间较长，或者网络中断。如果数据不断被提交给发送缓冲区，而发送模块一直未能将发送缓冲区的数据发送到服务器，这样会导致发送缓冲区的数据越来越多。因此我们必须为发送缓冲区设定一个上限。此处需要说的是，如果缓冲区满了之后的丢帧策略：丢帧必须整帧整帧的丢，不能丢半截；优先丢时间戳更早的帧；优先丢非参考帧；如果参考帧被丢，那么到下一个参考帧之前的帧，全部需要丢掉。
网络模块可以失败重连，但重连之后必须继续重连之前的数据发送任务。发送成功的半帧数据，视作发送失败，需要重发。
流媒体服务器端的优化。
流媒体服务器，需要将收到的数据进行分发。数据接收部分，流媒体服务器是被动的，除了实做方式的优化，理论上的可用的改进基本没有。
流媒体服务器的数据分发，是由播放器端主动请求发起的。那么服务器端需要处理的问题是，在播放器端的网络不稳定的情况下，播放器能够随时获取到之前因为网络故障而未能获取到的数据。因此，流媒体服务器端，也需要有缓存的数据。
流媒体服务器端，收到来自于编码端的数据之后，需要能够以帧或者GOP为单位来管理和视频。从而避免缓存了半帧数据，或者发送半帧数据这种事情。播放器端的优化。
播放器端播放数据，需要按照时间戳播放。避免在数据本身正常而因为播放而导致的不均匀。
播放器端，需要加入缓存，避免服务器端的数据不均匀或者偶然的网络故障。
数据播放时，并不需要缓存区被填满之后才开始进行解码播放。比如，我们有20秒的接收缓存。那么我们可以这么做，当缓冲区的数据，不足8秒钟时，我们就可以开始进行播放，但播放时，我们进行略微的减速播放（比如，以时间戳的播放速率的0.9倍速度进行播放）。如果缓冲区的数据超过了12秒钟，那么我们可以加速播放（如正常速率的1.1倍速率）。这样的话，我们的缓存区的数据，基本会维持有10秒钟左右的内容。那么这样的话，我们在媒体数据中断10秒钟之后，依旧可以正常播放，只要媒体数据在10秒钟之内恢复，那么我们依旧可以无缝切换到正常状态。并且，用户开始播放时，我们不会因为缓存而有很大的等待时间，而是立即开始播放。
如果收到数据的速度远超过播放速度，以至于缓冲区不够时，丢帧策略和编码发送端一致。
如果长时间没有收到任何数据，可以播放一些其它内容告知用户网络故障。当数据恢复时，需要从参考帧开始播放，避免第一帧出现马赛克。
直播系统的核心竞争力就是视频的流畅性、清晰度、时延。而其中以流畅性至关重要，特别是在恶劣情况下的流畅性，更加重要。如何去保证视频的流畅性，以上几点是否做到很关键，而这些是否能够方便可靠的实现，也是上传下载协议选择的重要参考标准。