Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU): Jetson AGX Orin
• DeepStream Version: GStreamer 1.20.3 | DeepStreamSDK 7.1.0
• JetPack Version (valid for Jetson only): 6.1 (Ubuntu 22.04 LTS, CUDA 12.6)
• TensorRT Version: 10.3.0
• 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):
gst-launch-1.0 zedsrc stream-type=4 camera-id=0
! zeddemux name=demux
demux.src_left ! queue
! videoconvert
! nvvideoconvert
! ‘video/x-raw(memory:NVMM),format=NV12’
! fakesink async=false
demux.src_aux ! videoconvert
! ‘video/x-raw,format=GRAY16_LE’
! fakesink
“Requirement details” (new‑feature vs. bug clarification)
Field | Answer |
---|---|
Problem type | Bug (not a new feature). Goal is simply to feed the left RGB image as an NV12/NVMM surface into nvstreammux , identical to any V4L2 camera, while continuing to pull 16‑bit depth on the host through the auxiliary pad. |
Affected modules | zedsrc , zeddemux , nvvideoconvert → nvstreammux on JetPack 6.x |
Expected behaviour | Pipeline should behave the same way it did on JetPack 5.1.2 (CUDA 11.4) where the exact same graph works for hours without errors. |
Actual behaviour | CUDA illegal memory access within nvbufsurftransform_copy.cpp when the upstream buffer originates from ZED’s CUDA context. Crash reproducible with a single camera and no inference. |
Functional description (what we need fixed) | Safe inter‑op between ZED SDK’s GPU buffers and DeepStream’s NVBufSurface allocator on Jetson Orin under CUDA 12.4. Ideally nvstreammux (or upstream nvvideoconvert ) should accept the surface or provide an allocator API so zedsrc can write directly into NVMM without an intermediate copy. |
Key excerpts from the sanitizer log (full trace attached): cuda_traceback
========= Program hit cudaErrorIllegalAddress (700)
nvbufsurftransform_copy.cpp:341 => Failed in mem copy
cudaMemcpy2DAsync ← first fault inside nvvideoconvert thread
...
cudaCreateTextureObject(...) at /builds/sl/ZEDKit/lib/src/sl_core/utils/util.cu:482
gst_zedsrc_fill → sl::Camera::grab → StereoDispGpuSL
What we already tried
Attempt | Result |
---|---|
Single camera only | Fails the same way (so it’s not multi‑cam contention). |
Force video/x-raw,format=NV12 without NVMM |
No crash, but DeepStream cannot consume system‑memory buffers. |
Set GST_CUDA_DEVICE_ID=0 , CUDA_VISIBLE_DEVICES=0 |
No change. |
Added sync=0 / async-handling=true on queues |
No change. |
Rebuilt ZED SDK 4.1.2 sample with CUDA 12.4 | Same error, so seems not for latest SDK version. |
Talked with ZED support | Redirection to here |
Going straight zeddemux → streammux | Internal stream data error from zedsrc |
Avoiding videoconvert, zeddemux → nvvideoconvert → streammux | Internal stream data error from zedsrc |
Changed resolution and batch size | No change. |
Hypothesis
- Two different CUDA contexts appear in the back‑trace (ZED SDK vs. GStreamer/DeepStream).
- The NVMM buffer hosting the RGB left image is likely copied (
cudaMemcpy2DAsync
) insidenvbufsurftransform_copy.cpp
after the CPU pad push. When the allocator comes from zedsrc the surface may be missing proper pitch/stride alignment for NV12 on Orin (64‑byte requirement?). - Immediately afterwards the ZED SDK creates/destroys a texture object on the same stream, and the device raises the same illegal address on
cudaCreateTextureObject
, hinting that the earlier overrun corrupted global memory.
Questions to the community / NVIDIA team
- Is the memory layout produced by
zedsrc
compatible withnvvideoconvert
➔nvstreammux
on JetPack 6.x?
a. Are there known alignment or pitch constraints for NV12(NVMM) on Orin that third‑party sources must satisfy? - Can the DeepStream allocator be forced upstream? (so that
zedsrc
writes directly into an NVBUF surface coming fromnvstreammux
and eliminates the copy). - Recommended way to inter‑operate ZED SDK and DeepStream streammux in JetPack 6.x?