After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673898 - [avidemux] Regression: some DIB videos play upside down
[avidemux] Regression: some DIB videos play upside down
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Windows
: Normal minor
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-04-11 11:07 UTC by Petteri Aimonen
Modified: 2012-07-24 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Petteri Aimonen 2012-04-11 11:07:44 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
Comment 1 Vincent Penquerc'h 2012-06-07 15:05:20 UTC
#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)).
Comment 2 Petteri Aimonen 2012-06-07 15:32:25 UTC
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.
Comment 3 Mark Nauwelaerts 2012-07-24 13:51:44 UTC
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
Comment 4 Vincent Penquerc'h 2012-07-24 13:57:06 UTC
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).
Comment 5 Mark Nauwelaerts 2012-07-24 14:03:51 UTC
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).
Comment 6 Vincent Penquerc'h 2012-07-24 14:07:35 UTC
I should have said "wrong in practice" due to some programs apparently misusing 0 as reported by comment 2.