Need to get the 'fd' of EGL OutputStream of libargus producer

In our application, we would like to get the ‘fd’ of EGL OutputStream of the libargus producer.

With libargus, the EGL outputStream is created by producer (by calling libargus API, ICaptureSession::createOutputStream()). We would like to get its ‘fd’ (e.g, by calling eglGetStreamFileDescriptorKHR()), and send this ‘fd’ to another consumer process via unix domain socket. So that the consumer can recover the same EGL stream by calling eglCreateStreamFromFileDescriptorKHR() with the ‘fd’ sent by the producer, and the acquire frames from this EGLStream.

However, when tying to get the ‘fd’ of the EGL outputstream, eglGetStreamFileDescriptorKHR() returns EGL_NO_FILE_DESCRIPTOR_KHR and generates an error “EGL_BAD_STATE_KHR”. Also we can confirm the EGL stream state is ‘STREAM_STATE_CREATED_KHR’.

According to KHR official document, it is most likely that the ‘fd’ of the EGL outputstream of libargus producer has already been obtained by calling eglGetStreamFileDescriptorKHR() inside the libargus implementation , and this will cause the eglGetStreamFileDescriptorKHR() call in our application fail to obtain the fd.

Is it possible for the application to obtain the fd of the EGL outputstream of libargus producer? E.g, adding new libargus API to export this ‘fd’ to libargus client application?

This method is not tested and verified. May not work properly. There is a user working on a similar use-case. Please refer to
Cross eglstream copy CUeglFrame failed

From Jetpack 4.6, we have NvBuffer APIs for sharing buffers between process. It is also based on unix domain socket. We are working on a sample demonstrating this use-case. Will share it when it is ready.

CUEglFrame based method can share the same argus camera among multiple processes.
But this method uses explicit memory copy to get the raw image data, which is not efficient when compared to zero-copy method.

An efficient zero-copy method is preferred as the amount of camera data is huge (e.g, 1080P@30fps and there are multiple cameras).

Look forward to your new NvBuffer APIs.

Jetpack 4.6 ? When will it be ok?a few months laster?or one year or two?

For passing NvBuffer through the APIs are ready on Jetpack 4.6(r32.6.1). You can check nvbuf_utils.h and give it a try.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.