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.cppafter 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
zedsrccompatible withnvvideoconvert➔nvstreammuxon 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
zedsrcwrites directly into an NVBUF surface coming fromnvstreammuxand eliminates the copy). - Recommended way to inter‑operate ZED SDK and DeepStream streammux in JetPack 6.x?