[Bug Report] Problem with handling AVI files in non-flipped row order

[Videogamer555]

In AVI raw (uncompressed) RGB video files (as with BMP image files) the height specified in the BitmapInfoHeader structure (the "strf" header of the AVI file) is actually a signed integer, but VLC treats it incorrectly as an unsigned integer. Correctly handling an AVI file requires the following handling of the height field stored in the strf header. Positive values of the height field in the strf header, indicate that the bottom row of the image is stored first. Negative values of the height field indicate that the top row of the image is stored first. The actual height of the image is the absolute value of this field (abs(480)==480 and also abs(-480)==480).

Here's where the bug comes in. Because VLC treats this field as unsigned, it thinks that negative height field values are actually HUGE positive values (literally thinking that the image is a few BILLION pixels in height). As a result, it can't play the video.

This bug prevents VLC player from playing any AVI files that have the image data stored as uncompressed RGB pixels or raw indexed color (color palette RGB) images, when it is stored in top row first order. In other words, if the AVI file contains image data in a format also officially supported in BMP still images, VLC player won't play it if it stores the pixels of the frames in the top row first order. Even though the default order for BMP and AVI files is bottom row first, most image formats use top row first order, and as a result video converters like FFMPEG (in order to simplify their own code without having to flip the image vertically to support AVI's default row order) tend to output raw RGB (and indexed color) AVI files with the frames pixels in top row first order, and simply set the strf header's height field to the negative of the actual frame height to make it a top row first AVI file. As a result, this prevents VLC from playing back raw RGB (and indexed color) AVI files output by FFMPEG (and probably other converters as well).

Please fix this bug.


Note:
This bug doesn't occur when playing raw YUV AVI files. From what I have seen, the reason that this bug doesn't show when playing raw YUV AVI files, is that raw YUV AVI files are always stored top row first, but (unlike in raw RGB AVI files) the value stored in the height field is always positive, so VLC player has no problem playing these raw YUV AVI files.

[Lotesdelere]

You should create a new ticket on the VLC Trac with your above report and the link to this thread:
https://code.videolan.org/videolan/vlc/-/issues