part1. 视频采集与编码 part2. 视频设备到服务器的传输 part3. 服务器分发到客户端的传输 part4. 客户端的播放 其中，这个过程延时消耗最⼤的是part1和part4，也就是编/解码部分，⽽且通常情况下part1延时>part4延时，那么part2和part3如果消耗⽐较⼤的延时，要么是⽹络实在太差，要买就是程序写的不好，⽹络差可以采⽤UDP或者TCP丢帧的⽅式减少长期的延时，那总结来说，如果在part2和part3部分⼀直保持着⾼延时，基本可以确定，是服务器程序问题；抛磨
part1论述，⽬前市⾯上的视频编码多采⽤硬编码，虽然是硬编码，采⽤芯⽚进⾏的视频编码计算，但不得不说，这个还是计算量⼤，时间消耗长，在arm设备中硬编码，以海思芯⽚为例，⼤部分可以控制在200ms以下的时间消耗，在⼿机上，由于⼿机性能的不⼀样，消耗的时间也不⼀样，但经过长期的推流开发经验，⼿机硬编码的时间消耗⼤部分也在300ms左右，当然，这都不⼀定准确，只是个⼈的经验值，实际还是要根据设备来定； part4论述，由于解码⼤部分是在x86机器上，或者在移动⼿机上进⾏解码播放，解码和显⽰的效率就⽐编码⾼多了；
part2 & part3，此部分为⽹络数据转发与传输，时间消耗是⾮常⼩的，具体⽹络传输的延时当然可以⾃⾏搜索获得，基本上在局域⽹延时可以忽略不计；
延时测试中的那些错误⽅法
1、徒⼿读秒
桥壳我们经常在遇到⼀些⽤户关于延时问题的咨询时候，遇到中间有很多的测试⽅法居然是靠掰⼿指读秒来测试的，⽽且有的给出的结论居然精确到了毫秒，这种做法是有很⼤误差的，我们在测试视频的时候发现，实际的1s⽐我们想象中的要长，⽽且有时间感觉要长很多；
2、北京时间对⽐
还有⼀种测试的⽅法，就是测试双⽅各⾃百度上输⼊“北京时间”，然后设备源端对着本地的北京时间，客户端⼀边播放，⼀边对照着⾃⼰本地的“北京时间”算差值，好吧，这也不准哪，北京时间到本地了之后，都是各个电脑⾃⼰开始计时，⽽且北京时间只能精确到秒，也就是说，这个时间会有0~999ms的误差；
3、播放器缓冲
管道内衬这个也是经常会出现的问题，⼤部分的直播测试⽤vlc或者ffmpeg这样的通⽤播放器进⾏延时测试，但是vlc和ffmpeg为了保证视频的平滑流畅播放，经常会在内部缓冲很长⼀段时间，例如vlc默认是1000ms的缓冲：
ffmpeg⼀⽅⾯会有⼀个⽐较长时间的视频分析过程，还有内部的缓冲流程，具体参数为：-fflags nobuffer -analyzeduration 1000000，具体详细参数说明在博客《》中；
正确姿势
正确的延时测试我们有⼏个⽅⾯的要求：油页岩灰渣
新金瓶酶2
统⼀的计时器高空施工
精确到毫秒
同步的源时间和播放时间快照
基于这种考虑，我们在做延时测试时的做法是，在PC上开启⼀个精确到毫秒的计时器，再通过摄像机/⼿机/桌⾯编码推流将直播流推送到服务器，再同时开启⼀个播放器（在本机或者另外的PC/⼿机播放器），再通过屏幕截屏或者⼿机拍照的⽅式，将源视频和播放视频都包括在⼀张照⽚内，再进⾏时间差值的计算，这也就做到了⾮常准确的延时统计了！
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议