UDP mode using IMAQdx on Axis 240 IP camera

[PeterGross]

Hello folks

I'm writing a video grab/overlay/AVI file system using LabView

I am sucessfully getting frames from my IP camera using IMAQdx -  using IMAQdx open camera, configure grab and grab.  I then put overlays onto the frames using IMAQ overlay text, then assemble the frames back into an AVI using IMAQ AVI Write Frame.

This works - but the frame rates I'm getting are consistently lower than the 30 fps the camera spits out.  Sometimes the frames seem to arrive late and I'm seeing variation in the number of frames per second that arrive.  I'm thinking using UDP instead of TCP/IP will help.

The camera does support UDP.  Unicast RTP over UDP to be exact, which is avaialble on a different port#.

My question is this;

When I use IMAQdx open camera, that vi finds and opens a channel to the camera.  However, I think it's opening a channel over TCP/IP. Not sure . .

Is there a way to 'tell' IMAQdx open camera to open an RTP over UDP stream, instead of using it's default behavior which seems to be TCP/IP?.  With the AXIS ip camera, UDP brodcasts are assigned to port 514. Is there any way to configure this in IMAQdx?

Suggestions welcome

Cheers

Peter

[BlueCheese]

Hi Peter,

Sorry, IMAQdx only supports MJPEG over HTTP currently---there is no support for the RTP protocol.

However, what does your code look like? There is really no efficiency difference between RTP and HTTP in a unicast situation (aside from any differences in the camera implementation, but for the Axis I don't believe there to be any). In fact often the HTTP solution can be more efficient on the PC because the TCP stream can be reconstructed in the kernel and given to the application in much larger chunks than the individual packets of UDP.

My assumption would be that it is your code that is causing the framerate to be lower. If you just run a simple Grab example, what frame rate do you see? My hunch would be that your code is getting the "Next" frame and so sometimes you end up skipping frames if your overlay/AVI stuff takes too long. You could try changing it to acquire by buffer number instead and then you can use IMAQdx's buffer list to absorb variations in your processing rate.

Eric

[PeterGross]

Thanks Eric, I appreciate your input.

I am currently setting my frame acquisition loop to use 'wait until next ms multiple' set to 20 fps, with IMAQdx Grab set to non synchronous operation (i.e don't wait for a new frame).  That seems to acquire at the correct speed, but I do notice that at unpredictable times a few frames don't seem to get transmitted.  Running at 30 fps is problematic.

Do you have an example of acquiring by buffer number?  I think I undersand what you mean, but I'm not clear on what you mean by the IMAQdx buffer list.

I am doing 4 text overlays on different parts of the video screen, so I'm using four instances of the overlay text vi in a row to do that.  Do you think all of this overlay stuff may be bogging things down?

Best Regards

Peter