Please provide complete information as applicable to your setup.
**• Hardware Platform (Jetson / GPU) NVIDIA GeForce RTX 2080 SUPER/Jetson AGX Xavier
**• DeepStream Version 6.1.1/6.0.1
**• JetPack Version (valid for Jetson only) 5.0.2
**• TensorRT Version 8.0.1/8.4.1
**• NVIDIA GPU Driver Version (valid for GPU only) 525.125.06
**• Issue Type( questions, new requirements, bugs) bugs
**• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing) Add the dewarper plugin to a source bin similar to the create_source_bin() function in deepstream python apps rstp_in_rtsp_out as its final element. Connect the streammux to the source bin as the rtsp_in_rtsp_out example does and add a tracker to the pipeline after the pgie.
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
I have a deepstream application using python bindings that’s based on the rtsp_in_rtsp_out example, modified to use multicast udp sources as input with a tracker added. I have a restreamed OSD to verify the output and I have a buffer probe on the tracker to log detections and tracker info to MQTT. When I add the dewarper element to the end of the source bin, my application still runs, but all tracker IDs dissapear from the restreamed OSD output and in the MQTT messages (that I generate from obj meta from the frame meta), all tracker IDs are 18446744073709551615, which seems like a buffer overflow. Detections are still unique and seem to function properly on the OSD as well, it’s just the tracker IDs that seem to break. Adding the dewarper plugin did also force me to explicitly set the nvbuf-memory-type on either my streammux or my dewarper to match eachother, otherwise I will get the following error: Error: gst-stream-error-quark: memory type configured and i/p buffer mismatch ip_surf 1 muxer 3 (1): gstnvstreammux.c(619): gst_nvstreammux_chain (): /GstPipeline:pipeline0/GstNvStreamMux:Stream-muxer
Currently, the linking of elements in my source bin is as follows:
# Add elements to bin
nbin.add(udpsrc)
nbin.add(rtpjpegdepay)
nbin.add(jpegdec)
nbin.add(nvvidconv)
if dewarp:
nbin.add(dewarper)
# Link the elements
udpsrc.link(rtpjpegdepay)
rtpjpegdepay.link(jpegdec)
jpegdec.link(nvvidconv)
if dewarp:
nvvidconv.link(dewarper)
# Ghost pad
bin_pad = dewarper.get_static_pad("src") if dewarp else nvvidconv.get_static_pad("src")
bin_ghost_pad = Gst.GhostPad.new("src", bin_pad)
nbin.add_pad(bin_ghost_pad)
return nbin
Following this logic, I link the streammux to the source bin as the rtsp_in_rtsp_out example demonstrates
I was thinking it might be related to the nvbuf-memory-type of the low-level tracker library, but my attempts to force that to be similar to the streammux and dewarper either failed or didn’t affect it. When I run the exact same application side by side with the dewarp flag off (removing it from the source bin), my tracker ids are back and the OSD shows them as well. It seems like this user was running into the same issue. Is there a fix for this or is there some form of incompatibility between the dewarper and NvDCF tracker?