overlay filter odd stuttering depending on order of input

[jnvsor]

Overlaying v4l2 onto x11grab causes a large drop in framerate for x11grab in certain input order

ffmpeg \
-f x11grab -framerate 30 -s hd1080 -i :0.0 \
-f v4l2 -framerate 30 -i /dev/video0 \
-filter_complex '[0][1]overlay=x=300:y=300[cap]' \
-map '[cap]' \
-c:v libx264 -pix_fmt yuv444p -preset ultrafast -qp 0 \
-threads 2 -y out.avi
# frame=  225 fps= 18 q=-1.0 Lsize=   36782kB time=00:00:12.56 bitrate=23977.3kbits/s dup=0 drop=74

Switching the input order (And the filter inputs to keep the same output)

ffmpeg \
-f v4l2 -framerate 30 -i /dev/video0 \
-f x11grab -framerate 30 -s hd1080 -i :0.0 \
-filter_complex '[1][0]overlay=x=300:y=300[cap]' \
-map '[cap]' \
-c:v libx264 -pix_fmt yuv444p -preset ultrafast -qp 0 \
-threads 2 -y out.avi
# frame=  208 fps= 30 q=-1.0 Lsize=   25993kB time=00:00:06.93 bitrate=30711.3kbits/s

The frame by frame of this video is also far smoother. Where the previous video had 4/5 frames duplicated in a row, this never exceeds 1.

Recording to separate output tracks is still smooth, but the cause isn't a bottleneck in the filter. Splitting the x11grab input and overlaying that retains a high framerate.

[Carl Eugen Hoyos]

Is this only reproducible using an external library (libx264) or also with a native encoder?

Is this a duplicate of ticket #3192?

To make this a valid ticket, please provide the bad command line together with the complete, uncut console output.

[jnvsor]

Yes, looks like it's a duplicate - I'll add my experience to that ticket if I have anything new

[llogan]

Closing as duplicate of ticket #3192.