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
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