[FFmpeg-user] Too much delay/latency in h.264 to MJpeg conversion

[Moritz Barsnick]

On Tue, Jul 25, 2017 at 17:22:29 -0700, Ed Ostertag wrote:
> The command works but the MJpeg images are delayed by over 5 seconds.
> Using local GBit network for the input and loopback for the output so 
> net is not the problem.
> Is there any way to reduce the delay to under 0.5 seconds?

I don't really know much about the latency stuff, but:

> ffmpeg -loglevel debug -fpsprobesize 100 -skip_frame nokey -an  -i 
> rtsp://user:pwd--@192.168.0.105:554?buffer-size=1024/videoSub -r 1 -c:v 
> mjpeg -f mjpeg -tune zerolatency -fpsprobesize 100 -s 640x480 -bufsize 0 
> -an "tcp://127.0.0.1:13845?listen&buffer-size=1024" 
> 2>>..\..\ffbatlogs\ffbatlog_Cellar_2017_07_25_13_44_03_930.txt

How does it behave if you use a non-network input? (E.g. "-f lavfi -i
testsrc=r=1:s=640x352")

How does it behave if you use a non-network output? (E.g.
"tmpdir/%04d.jpg").

It might help to understand which side introduces the latency.

> I have an FFmpeg command that creates a stream of jpeg images at 1fps 
> from an h.264 input stream at 20fps. (Key frames only)

Is the input stream "key frames only", or are you demuxing only the key
frames using "-skip_frame nokey"? (I assume the latter, otherwise the
status line would report dropped frames.) Instead of using that option,
which I didn't know until now, perhaps you could try the "select" filter
and see if that changes anything.

  -vf "select='eq(pict_type,I)'"

> [udp @ 0000000000d38aa0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)

I'm not sure whether it matters that your build has no pthread support.

Just guessing,
Moritz