GNOME Bugzilla – Bug 673898
[avidemux] Regression: some DIB videos play upside down
Last modified: 2012-07-24 14:07:35 UTC
Regression caused by this commit: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=c6b9f5b25ab435669816a07049b0e5a8f01e09ca This file plays upside down in gstreamer, while it plays fine in VLC, mplayer and Windows Media Player. The file is generated by LabView. (400MB, sorry that I don't have any smaller example): http://koti.kapsi.fi/jpa/stuff/other/HDbunny_raw_no_marks.avi Considering that the original commit was just to fix a warning, perhaps it could be reverted or the check could be made more robust. Currently it is checking only strh, while strf could give more detailed information. VLC seems to rely mostly on information in strh: http://repo.or.cz/w/vlc.git/blob/HEAD:/modules/demux/avi/avi.c#l477
#define GST_RIFF_rgb GST_MAKE_FOURCC (0x00,0x00,0x00,0x00) So this patch will consider that identifier as compressed, whereas it would not with the original code. I don't understand why this patch would avoid a warning either, and reverting it locally does not warn (GCC 4.6.3 (ish)).
I think it avoids a warning from GStreamer, more specifically this one: GST_WARNING ("Buffer is smaller than reported Width x Height x Depth"); I.e. apparently there are both compressed and uncompressed streams out there with fourcc = 0. Compressed streams are (with any luck) ignored by the other checks.
Makes sense to revert the original one if everything worked before (give or take some extra GStreamer warning caused by the additional checks). Since it worked before, the caps must have been created correctly. Since the caps should be correct anyway (or more problems arise), use the fourcc for the caps to determine (un)compressedness. So following commits should sort this out: commit 15ddde6ef606f4c001c9632446eeb47e2838787f Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Jul 24 15:36:54 2012 +0200 Revert "avidemux: Don't consider 0 fcc_handler as uncompressed." This reverts commit c6b9f5b25ab435669816a07049b0e5a8f01e09ca. fourcc GST_RIFF_rgb = 0 still leads to raw uncompressed rgb caps. See also https://bugzilla.gnome.org/show_bug.cgi?id=673898 commit adac94e23432ac7448ca3c1247eb9bff22b20b9e Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Tue Jul 24 15:38:24 2012 +0200 avidemux: use same fourcc to determine caps in determining uncompressed-ness Fixes https://bugzilla.gnome.org/show_bug.cgi?id=673898
Maybe it might make sense to, just for the "0" case, compare size with uncompressed size, and select between compressed and umcompressed using this check. It would remove a safety check, but since for "0" this safety check happens to be wrong, it would both remove the warnings and do the right thing (unless the writing program messed up).
The safety size check seems advisable in all cases (whether or not 0), but one might consider a different level of debug message (depending on the fourcc or so). On the other hand, how is the safety check "wrong" in the 0 case? Also, the '0 case' is a bit relative, since it depends on where the fourcc is taken from, which has been slightly tweaked in this case (relying that the one used for caps is ok or things will go seriously wrong anyway).
I should have said "wrong in practice" due to some programs apparently misusing 0 as reported by comment 2.