Hi there!
Our Platform Info:
• Hardware Platform: Jetson Orin
• DeepStream Version: 6.3
• JetPack Version 5.1.2 (r35.4.1)
• TensorRT Version: 8.5.2.2+cuda11.4.315
Our original image capture pipeline is as follows:
nvv4l2camerasrc → appsink → callback
In callback, we use deepstream api to transfer GstSample to cv::cuda::GpuMat which works fine.
GstSample → NvBufSurface → NvBufSurfaceMapEglImage, cuGraphicsEGLRegisterImage, cuGraphicsResourceGetMappedEglFrame → elg_frame_.frame.pPitch → cv::cuda::GpuMat
Now we want to share NvBufSurface between processes without copying image data to CPU.
Refer to /usr/src/jetson_multimedia_api/samples/13_argus_multi_camera.
Process producer:
nvv4l2camerasrc → appsink → callback
In callback:
GstSample → NvBufSurface → NvBufSurfaceGetMapParams → unix socket send buf_par.fd and buf_par
Process consumer:
recevice buf_par.fd and buf_par → NvBufSurfaceImport → NvBufSurface → NvBufSurfaceMapEglImage … to construct cv::cuda::GpuMat.
NvBufSurfaceMapEglImage returns -1 so that we can’t continue.
Please help us to solve the problem.
Thanks.
please refer to IPC sample /opt/nvidia/deepstream/deepstream/sources/apps/sample_apps/deepstream-ipc-test in DeeepStream 7.0 SDK for Jetson. it already support rtsp and local file source. you can modify it to support camera.
Thanks for your reply.
Zero-Copy and sharing data is our ultimate goal.
Upgrading jetpack is not first choice in our scenario.
And deepstream-ipc-test in DeeepStream 7.0 still copy data from src to dst.
The method from sample 13_argus_multi_camera meets our requirements by sharing NvBufSurface between processes.
We have tested the method works fine if we construct data on CPU,
the consumer process can get the same data from producer process by sharing NvBufSurface.
However, as mentioned above,
we capture image data to Jetson hardware memory in producer process
share NvBufSurface to consumer process
NvBufSurfaceMapEglImage so that we can use CUDA in consumer process, however, NvBufSurfaceMapEglImage returns -1.
Please help to confirm whether it is correct in theory, if not, how to fix it in DeeepStream 6.3.