那些千奇百怪的视频直播延时测试方法，论正确姿势是什么？
说到视频直播延时测试，我们就不得不先探讨一下产生延时的几个环节：
part1. 视频采集与编码
part2. 视频设备到服务器的传输
part3. 服务器分发到客户端的传输
part4. 客户端的播放
其中，这个过程延时消耗最大的是part1和part4，也就是编/解码部分，而且通常情况下part1延时>part4延时，那么part2和part3如果消耗比较大的延时，要么是网络实在太差，要买就是程序写的不好，网络差可以采用UDP或者TCP丢帧的方式减少长期的延时，那总结来说，如果在part2和part3部分一直保持着高延时，基本可以确定，是服务器程序问题；
part1论述，目前市面上的视频编码多采用硬编码，虽然是硬编码，采用芯片进行的视频编码计算，但不得不说，这个还是计算量大，时间消耗长，在arm设备中硬编码，以海思芯片为例，大部分可以控制在200ms以下的时间消耗，在手机上，由于手机性能的不一样，消耗的时间也不一样，但经过长期的推流开发经验，手机硬编码的时间消耗大部分也在300ms左右，当然，这都不一定准确，只是个人的经验值，实际还是要根据设备来定；
part4论述，由于解码大部分是在x86机器上，或者在移动手机上进行解码播放，解码和显示的效率就比编码高多了；
part2 & part3，此部分为网络数据转发与传输，时间消耗是非常小的，具体网络传输的延时当然可以自行搜索获得，基本上在局域网延时可以忽略不计；
延时测试中的那些错误方法
- 徒手读秒
我们经常在遇到一些用户关于延时问题的咨询时候，遇到中间有很多的测试方法居然是靠掰手指读秒来测试的，而且有的给出的结论居然精确到了毫秒，这种做法是有很大误差的，我们在测试视频的时候发现，实际的1s比我们想象中的要长，而且有时间感觉要长很多；
- 北京时间对比
还有一种测试的方法，就是测试双方各自百度上输入“北京时间”，然后设备源端对着本地的北京时间，客户端一边播放，一边对照着自己本地的“北京时间”算差值，好吧，这也不准哪，北京时间到本地了之后，都是各个电脑自己开始计时，而且北京时间只能精确到秒，也就是说，这个时间会有0~999ms的误差；
- 播放器缓冲
这个也是经常会出现的问题，大部分的直播测试用vlc或者ffmpeg这样的通用播放器进行延时测试，但是vlc和ffmpeg为了保证视频的平滑流畅播放，经常会在内部缓冲很长一段时间，例如vlc默认是1000ms的缓冲：
ffmpeg一方面会有一个比较长时间的视频分析过程，还有内部的缓冲流程，具体参数为：-fflags nobuffer -analyzeduration 1000000，具体详细参数说明在博客《ffmpeg ffplay播放延时大问题：播放延时参数设置》中；
正确姿势
正确的延时测试我们有几个方面的要求：
- 统一的计时器
- 精确到毫秒
- 同步的源时间和播放时间快照
基于这种考虑，我们在做延时测试时的做法是，在PC上开启一个精确到毫秒的计时器，再通过摄像机/手机/桌面编码推流将直播流推送到服务器，再同时开启一个播放器（在本机或者另外的PC/手机播放器），再通过屏幕截屏或者手机拍照的方式，将源视频和播放视频都包括在一张照片内，再进行时间差值的计算，这也就做到了非常准确的延时统计了！
获取更多信息
Copyright © EasyDarwin.org 2012-2017
