Broadcasting GMSL camera data through Ethernet

Hi,

I’m working on an application to get the gmsl camera data from ddpx and send it to a logger throuth Ethernet. I’ve looked into the sample of saving data from GMSL camera, but have some difficulties on figure out how could I broadcast them through Ethernet?

I’ve also looked into inter process communication samples but it seems that the camera data need to be encoded somehow. Or, should I use gstreamer to encode and broadcast them on DDPX?

It would be nice if someone could have some suggestions.

Best regards,

Zijian

Hi zijian.han,

Usually the data recording was through external storage, may I know why need to through Ethernet?
Is it related with throughput?

You could refer to “Throughput Recording” part DriveWorks doc for your topic first, this may help you to get some hint how to handle external storage for DriveWorks.

Dear zijian.han,

I think you probably reviewed the EGLstream part.
https://docs.nvidia.com/drive/active/5.1.0.2L/nvvib_docs/index.html#page/DRIVE_OS_Linux_SDK_Development_Guide%2FGraphics%2Fgraphics_guide.html%23
I guess you should use EGLstream for an application case you mentioned. Thanks.

@kayccc,

Hi, actually our logger hardware will be connected to ddpx, as camera data is quite a lot, we are planning on sending them through 10Gb Ethernet port to the logger.

I noticed that in Driveworks api there are two kind of stream: Image stream and image GL stream. May I ask what’s the difference of these two?

Dear zijian.han,

Based on your response, I guessed what you wanted.
Is the data flow in order as shown in the figure below? Thanks.

Hi SteveNV,

Yes exactly. Actually the logger is the storages for the camera data, it will be data triggered and automatically save all the coming data through ehternet. I actually see there is a tool app provided in Driveworks called camera server daemon, that could broadcast the camera frames, using socket tcp communication. But I don’t have the sample code of how it is implemented. I tried to open a client socket to connect to it but the server seems to have some handshake message to trigger the message sending. In the Driveworks sample sample_camera_slave, it could receive the frames but it’s only high-level api, that doesn’t show how the tcp communication is implemented.

Dear zijian.han,

If the logger is one of storage, are you using it as a storage device like a NAS?
If yes, all sensor data can be saved directly to the NAS with DriveWorks record tool.
I think if you do the following, you can reduce unnecessary work. Thanks.
1 -> 4(o)
1 -> 2 -> 3 -> 4(x)

Dear Steve,

Thanks so much for the reply. I’m aware of the logging tool, but can you explain a bit on what do you mean by:
1 -> 4(o)
1 -> 2 -> 3 -> 4(x)
?

Thanks a lot.

Hi,

In the guidance I only see that using the logging tool the data can be saved through USB, which is 1 -> 2, how can I config it so it can be send through 1 -> 4?

Dear zijian.han,

Please add storage path in the rig file like below and refer to the following link for this topic.

{
    "rig": {
        "properties": {
                <b>"storage_path": "/home/nvidia/mnt"</b>
        },
        "sensors": [

https://devtalk.nvidia.com/default/topic/1058556/general/-q-recorder-tool-cannot-read-storage_path-/

And only requirement that it is:

  1. An ext4 formatted drive that shows up in /proc/mounts.
  2. Begins w/ “/dev/sdX”

Hi Steve,

Thanks for the answer. As I mentioned above, the logger is intented to be connected to ddpx via Ethernet, not usb. I guess it cannot be mounted in nvidia/mnt. It will not go through USB. I would probably need to program my own code for UDP socket programming to handle the image broadcasting, I guess?

Dear zijian.han,

Some customers are using NAS system for loggers via DriveAGX ethernet port(1 -> 4) with the above setting.
I think the choice seems to be a matter of your decision, but please consider NAS system for the logger as well. Thanks.