"Pulsing" in image at iframeinterval when using nvv4l2-enc instead of omx-enc

We recently migrated to using the nvv4l2h264enc and nvv4l2h265enc GStreamer encoders from omx, which the documentation describes as deprecated.

However, when recording from a live source using the nvv4l2 encoders, we have noticed that every n-th frame is blurry compared to the preceding and next frame, where n appears to be equal to the iframeinterval that we provide in the GStreamer launch string - the image goes blurry 30/iframeinterval times per second.

gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM),width=4032,height=3040,format=NV12,framerate=30/1' ! nvvidconv ! 'video/x-raw(memory:NVMM),width=3840,height=2160' ! nvv4l2h264enc bitrate=60000000 iframeinterval=30 ! h264parse ! qtmux ! filesink location=/mnt/SSD/test_nvv4l2.mp4 -e

The problem is much more apparent in areas with good lighting where camera noise is less present (i.e. outdoors).

Simply changing to omx resolves the issue. Any suggestions regarding the settings we should be using to obtain an equivalent level of quality with nvv4l2h26Xenc?

Here is an example of what I mean. First the blurry frame, then a subsequent sharper frame. 29 out of 30 frames look like the bottom, sharp, one. One in 30 looks like the blurry one.



It looks like IDR/I frames are not compressed with small quantization value. Please run in VBR

  control-rate        : Set control rate for v4l2 encode
                        flags: readable, writable, changeable only in NULL or READY state
                        Enum "GstV4l2VideoEncRateControlType" Default: 1, "constant_bitrate"
                           (0): variable_bitrate - GST_V4L2_VIDENC_VARIABLE_BITRATE
                           (1): constant_bitrate - GST_V4L2_VIDENC_CONSTANT_BITRATE

And adjust qp-range

  qp-range            : Qunatization range for P, I and B frame,
                         Use string with values of Qunatization Range
                         in MinQpP-MaxQpP:MinQpI-MaxQpI:MinQpB-MaxQpB order, to set the property.
                        flags: readable, writable
                        String. Default: null

If you use r32.3.1, please apply the patch and rebuilt gst-v4l2:
[GSTREAMER]Control-rate property(VBR/CBR) takes no effect

Thanks for the information, Dane. We’ll investigate this solution as soon as time allows.