Hi,
I just upgraded from L4T 32.3.1 to L4T 32.4.3 (Jetpack 4.4) and a GStreamer pipeline that used to work on 32.3.1 no longer works on 32.4.3. I believe this has something to do with the nvv4l2decoder
filter.
The pipeline in question is
GST_DEBUG=3 gst-launch-1.0 -e rtspsrc location="rtsp://192.168.0.103:554/av0_0" is-live=true protocols=tcp ! rtph264depay ! h264parse ! nvv4l2decoder ! video/x-raw\(memory:NVMM\) ! nvvidconv ! video/x-raw\(memory:NVMM\),width=256,height=144 ! nvvidconv ! video/x-raw,format=GRAY8 ! multifilesink location="/tmp/%d.y"
When running on L4T 32.3.1 this pipeline works and I get a series of files being generated. However when running the same pipeline on L4T 32.4.3 no files are generated and it seems to not respond to the EOS event when stopping the pipeline using ctrl-c on the console.
The output when running the pipeline on 32.4.3 is
$ GST_DEBUG=3 gst-launch-1.0 -e rtspsrc location="rtsp://192.168.0.103:554/av0_0" is-live=true protocols=tcp ! rtph264depay ! h264parse ! nvv4l2decoder ! video/x-raw\(memory:NVMM\) ! nvvidconv ! video/x-raw\(memory:NVMM\),width=256,height=144 ! nvvidconv ! video/x-raw,format=GRAY8 ! multifilesink location="/tmp/%d.y"
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE
0:00:00.109288642 9922 0x55ae811ec0 WARN v4l2 gstv4l2object.c:4435:gst_v4l2_object_probe_caps:<nvv4l2decoder0:src> Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Unknown error -1
0:00:00.109362134 9922 0x55ae811ec0 WARN v4l2 gstv4l2object.c:2372:gst_v4l2_object_add_interlace_mode:0x55ae803710 Failed to determine interlace mode
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.0.103:554/av0_0
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
0:00:02.150779553 9922 0x7f7403a1e0 FIXME basesink gstbasesink.c:3145:gst_base_sink_default_event:<multifilesink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
(gst-launch-1.0:9922): GStreamer-CRITICAL **: 17:00:29.932: gst_mini_object_unref: assertion 'mini_object != NULL' failed
It will stay like this âforeverâ.
If I kill the pipeline using ctrl-c, I get the following
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline
Waiting for EOS...
It will also stay like this âforeverâ unless I issue another ctrl-c whereupon I get the following
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Interrupt while waiting for EOS - stopping pipeline...
Execution ended after 0:00:13.640278834
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
0:00:13.949095411 9922 0x55ae815800 WARN rtspsrc gstrtspsrc.c:5200:gst_rtspsrc_loop_interleaved:<rtspsrc0> warning: The server closed the connection.
^C
If I substitute the nvv4l2decoder
filter with avdec_h264
then the pipeline works perfectly.
GST_DEBUG=3 gst-launch-1.0 -e rtspsrc location="rtsp://192.168.0.103:554/av0_0" is-live=true protocols=tcp ! rtph264depay ! h264parse ! avdec_h264 ! video/x-raw ! nvvidconv ! video/x-raw\(memory:NVMM\),width=256,height=144 ! nvvidconv ! video/x-raw,format=GRAY8 ! multifilesink location="/tmp/%d.y"
Interestingly this only seems to cause a problem if the pipeline is streaming from an RTSP source. If I substitute the RTSP source with a file then nvv4l2decoder
appears to operate properly.
Can anyone offer me any assistance or guidance about why I am seeing this behaviour only on the latest Jetpack release? Any help would be greatly appreciated.
Regards
Ben