L4T 32.1 problems switching from omxh264enc to nvv4l2h264enc

We have a TX2-based encoding product and are in the process of upgrading the SDK
from L4T 28.1 to L4T 32.1. In the Accellerated GStreamer User Guide it says that
the omxh264enc GStreamer element is deprecated and that the nvv4l2h264enc should
be used instead.

We have run into two problems using the nvv4l2h264enc encoder so far.

First, we run the pipeline with gst-debug=3 to catch problems. When this is done there are constant warnings from the encoder like this:

0x5591e9d800 WARN          v4l2bufferpool gstv4l2bufferpool.c:1483:gst_v4l2_buffer_pool_dqbuf:<nvv4l2h264enc0:pool:sink> V4L2 provided buffer has bytesused 0 which is too small to include data_offset 0

This happens at both with composite (720x480) and 720p (1280x720) resolutions.

The second problem is that the composite (720x480) encode rate only outputs about 5 frames/second. This happens even if I enable the maxperf-enable=1 option. The hd-720p encode seems ok. If I go back to the omxh264enc encoder both resolutions work fine. Note that the omxh264enc library was patched to enable

oEncodeProp.bSetMaxEncClock = TRUE;

As described here

https://devtalk.nvidia.com/default/topic/1032771/jetson-tx2/no-encoder-perfomance-improvement-before-after-jetson_clocks-sh/post/5255605/#5255605

The decode pipeline we are using for testing for error messages is as follows:

export GST_DEBUG=3
gst-launch-1.0 -v -v v4l2src ! capsfilter 'caps=video/x-raw,width=1280,height=720' \
        ! nvvidconv ! capsfilter 'caps=video/x-raw(memory:NVMM)' \
        ! nvv4l2h264enc insert-sps-pps=true \
        ! capsfilter 'caps=video/x-h264,stream-format=(string)byte-stream' \
        ! h264parse config-interval=5 \
        ! mpegtsmux ! filesink location="capture1.ts"

Any ideas what could be causing these problems?

Thanks,

Cary

You may try to set framerate for your camera. When not specified, it may use a high framerate that may not be suitable for a slower plugin in the pipeline. Is it a very high framerate shown in the ouput ?
Or does a shorter config-interval improve ?

Is there a way to get rid of the warning?

It makes GST_DEBUG=3 worthless.

The discussion continues in https://devtalk.nvidia.com/default/topic/1067192/