Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU) T4 GPU
• DeepStream Version 5.0.1
• JetPack Version (valid for Jetson only)
• TensorRT Version 7.1.3.4-1+cuda10.2
• NVIDIA GPU Driver Version (valid for GPU only) 450.119.03
• Issue Type( questions, new requirements, bugs) bug
• 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)
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
I am decoding an H.264 stream from the Panasonic XV-X1534L Network Camera. When I use nvv4l2decoder the element starts sending duplicated buffers after a few seconds. The software encoder works correctly with the same stream. I figured the bug is highly specific to that stream because other H.264 streams work correctly as well as the H.265 stream from the same camera.
Here is my camera configuration:
This is the pipeline that produces the issue:
gst-launch-1.0 \
rtspsrc location="rtspt://<user>:<pass>@192.168.0.202/Src/MediaInput/stream_1" ! \
rtph264depay ! \
nvv4l2decoder ! \
nvvideoconvert ! \
"video/x-raw(memory:NVMM)" ! \
mux.sink_0 nvstreammux name=mux batch-size=1 width=640 height=480 ! \
nvdsosd display-clock=1 ! \
nvvideoconvert ! \
xvimagesink sync=false async=true
This pipeline works correctly with the same stream configuration:
gst-launch-1.0 \
rtspsrc location="rtspt://<user>:<pass>@192.168.0.202/Src/MediaInput/stream_1" ! \
rtph264depay ! \
avdec_h264 ! \
nvvideoconvert ! \
"video/x-raw(memory:NVMM)" ! \
mux.sink_0 nvstreammux name=mux batch-size=1 width=640 height=480 ! \
nvdsosd display-clock=1 ! \
nvvideoconvert ! \
xvimagesink sync=false async=true
Sometimes the stream will freeze completely like the following video:
2022-02-23 10-03-15.mkv (443.4 KB)
Note that the nvdsosd timer continues but the camera timer is stuck.
Other times the stream will repeat the last couple of frames:
2022-02-23 11-05-28.mkv (1.7 MB)
Switching to a software encoder is not an option for us because the CPU usage is too high.
The same stream works correctly with a similar setup on Nano, TX2, and Xavier.