IMAQ AVI2 Write Frame Memory Leak

[MoviJOHN]

This is a bug report.  Writing large images 2160 x 1080 to AVI file without compression CODECs causes the memory usage to go up up up, until LabVIEW basically exceeds the 8GB memory limit, and stops processing frames.

[Andy-C]

Hi John,

Thanks for the info! I played around some with the example you attached but could not replicate the behavior. Can you walk me through exactly how you are producing the leak? It would also be helpful to know the versions of the software you are working with (LabVIEW, VAS, Windows, etc).

Cheers,

Andy C.

Applications Engineering

National Instruments 

[BlueCheese · Accepted solution]

Hi John,

I replicated this and filed CAR 428325 for it. On first glance it looks to only be an issue when the color format of the AVI doesn't match the format of the input images you are writing. In your case you were passing U8 images in but the AVI video is writing YUV (Color) images. If you switch the IMAQ Create VI to create RGB32 images instead, the leak goes away. Switching the AVI format to Y800 (Uncompressed monochrome) instead of changing the input side shows no leak either.

If you actually do want the mismatch of monochrome image processing and color AVI format, you could work around this issue by putting a Cast VI in your code to convert the U8 image to RGB32 prior to writing it to the AVI.

Eric

[MoviJOHN]

Hi Andy.

LabVIEW Version 12.0.1f3 32-Bit

Windows 7 Profession 64-Bit

VDM Version is the latest with 2013

I see another post has come in, so I'll see what has been found.  Thanks.

Make sure to set your write path to something valid, otherwise you won't see the memory use go up, since it won't be actually writing the images to file.  We have tested this code on multiple systems here, all with the same result.

The MJPEG codec does not have the leak.  64-Bit LabVIEW runs longer, but still leaks using the uncompressed codecs.