那些千奇百怪的视频直播延时测试方法,论正确姿势是什么?

说到视频直播延时测试,我们就不得不先探讨一下产生延时的几个环节:

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的缓冲:

vlc

ffmpeg一方面会有一个比较长时间的视频分析过程,还有内部的缓冲流程,具体参数为:-fflags nobuffer -analyzeduration 1000000,具体详细参数说明在博客《ffmpeg ffplay播放延时大问题:播放延时参数设置》中;

正确姿势

正确的延时测试我们有几个方面的要求:

  • 统一的计时器
  • 精确到毫秒
  • 同步的源时间和播放时间快照

基于这种考虑,我们在做延时测试时的做法是,在PC上开启一个精确到毫秒的计时器,再通过摄像机/手机/桌面编码推流将直播流推送到服务器,再同时开启一个播放器(在本机或者另外的PC/手机播放器),再通过屏幕截屏或者手机拍照的方式,将源视频和播放视频都包括在一张照片内,再进行时间差值的计算,这也就做到了非常准确的延时统计了!

EasyDSS

EasyDarwin

获取更多信息

邮件:support@easydarwin.org

WEB:www.EasyDarwin.org

Copyright © EasyDarwin.org 2012-2017

EasyDarwin

原文地址:https://www.cnblogs.com/babosa/p/9217789.html