1

I have a 2560x1440 camera wired over ethernet, that I cannot get low enough latency to use properly. We're talking ~10 seconds delay with a Quadro P2000, but with my Ryzen 3900X I can get the same quality but < 1 second latency. ffmpeg version 3.4.8-0ubuntu0.2. I'm using a software called Shinobi, and this is the ffmpeg command that gets fired:

/usr/bin/ffmpeg
  -progress pipe:5
  -use_wallclock_as_timestamps 1
  -analyzeduration 1000000
  -probesize 1000000
  -fflags +igndts
  -rtsp_transport tcp
  -hwaccel cuvid
  -c:v hevc_cuvid
  -loglevel warning
  -i rtsp://cam:camcam@192.168.1.111:554/live
  -strict
  -2
  -an
  -c:v hevc_nvenc
  -crf 1
  -movflags +frag_keyframe+empty_moov+default_base_moof
  -metadata title=Shinobi H.265 Stream
  -reset_timestamps 1
  -f hevc pipe:1

I set the preset to lossless and crf to 1 myself. I don't think hls_time and hls_list_size has anything to do with latency, but I also set those.

I tried a bunch of different presets and crf values, such as the llhq and llhp, which definitely helped, but the latency is still about 3-4 seconds. Again, too much.

I basically want as low latency as possible, with the highest quality stream as possible (don't we all?). By using Shinobi's MJPEG preset, I can get < 1 second latency with the same quality.

What options can I try to change up?

EDIT: The codecs of my cameras are Codec: H264 - MPEG-4 AVC (part 10) (h264) and Codec: MPEG-H Part2/HEVC (H.265) (hevc)

MortenMoulder
  • 509

1 Answers1

0

Add the parameter -delay:v 0 to hevc_nvenc's encoder wrapper in ffmpeg as shown below, and retest:

/usr/bin/ffmpeg
  -progress pipe:5
  -use_wallclock_as_timestamps 1
  -analyzeduration 1000000
  -probesize 1000000
  -fflags +igndts
  -rtsp_transport tcp
  -hwaccel cuvid
  -c:v hevc_cuvid
  -loglevel warning
  -i rtsp://cam:camcam@192.168.1.111:554/live
  -strict
  -2
  -an
  -c:v hevc_nvenc
  -delay:v 0 
  -crf 1
  -movflags +frag_keyframe+empty_moov+default_base_moof
  -metadata title=Shinobi H.265 Stream
  -reset_timestamps 1
  -f hevc pipe:1

Documentation:

The latency is propagated by the “delay” parameter (internally referred to as async_depth) passed to FFmpeg for nvenc. The code in FFmpeg’s nvenc.c waits until this number of extra frames have been buffered before emitting any frames and is intended to support parallel and 1:N encoding scenarios.

The assigned default value is INT_MAX which later gets reduced down to the number of NVENC surfaces initialized minus one, which itself has an initial value of 4 when unset/by default.

This can be overriden by setting -delay:v 0 to fix the output latency.

Please refer to this answer on handling extra NVENC options, based on the ffmpeg build version(s) in use. Using the new(er) NVENC API (to date) should present newer options for presets and usability tuning, deprecating older rate control methods.

Dennis Mungai
  • 3,534