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 704292 - qtdemux: does not know WRAW fourcc
qtdemux: does not know WRAW fourcc
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal blocker
: 1.1.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-15 20:53 UTC by nils+bugzilla.gnome.org
Modified: 2013-07-19 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description nils+bugzilla.gnome.org 2013-07-15 20:53:07 UTC
A file from PLOS does not play with GStreamer 0.10.36 on Debian: <http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3266246/bin/pone.0030293.s007.mov>

See also bug report for the Open Access Media Converter:
<https://github.com/erlehmann/open-access-media-importer/issues/69#issuecomment-18698554>
Comment 1 Olivier Crête 2013-07-15 21:14:41 UTC
This WRAW fourcc is unknown even to Google, more info needed.
Comment 2 nils+bugzilla.gnome.org 2013-07-15 22:04:17 UTC
ffplay shows yellow blobs on red background and gives the following information:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3266246/bin/pone.0030293.s007.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2008-02-19 17:44:16
  Duration: 00:01:11.42, start: 0.000000, bitrate: 103 kb/s
    Stream #0.0(eng): Video: rawvideo, pal8, 44x42, 103 kb/s, PAR 21:22 DAR 1:1, 7 fps, 7 tbr, 1000k tbn, 1000k tbc
    Metadata:
      creation_time   : 2008-02-19 17:44:16
[avsink @ 0xb2800940] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 0xb2800d60] w:44 h:42 fmt:pal8 -> w:44 h:42 fmt:yuv420p flags:0x4
Comment 3 Olivier Crête 2013-07-16 02:01:05 UTC
How certain are you that what ffmpeg is displaying is correct ? mplayer built against the same libffmpeg as ffplay seems to reject it also.
Comment 4 Sebastian Dröge (slomo) 2013-07-16 08:20:28 UTC
Doesn't mplayer use its own demuxers? I can confirm that avplay plays it properly here but mplayer (using the same libav) doesn't.
Comment 5 Sebastian Dröge (slomo) 2013-07-16 08:38:12 UTC
libavformat/isom.c:    { AV_CODEC_ID_RAWVIDEO, MKTAG('W', 'R', 'A', 'W') },

They handle it exactly like raw video. However this seems to have only ~5 bit per pixel and I can't find where exactly they map this to a real raw video format.
Comment 6 Wim Taymans 2013-07-16 15:22:45 UTC
(In reply to comment #5)
> libavformat/isom.c:    { AV_CODEC_ID_RAWVIDEO, MKTAG('W', 'R', 'A', 'W') },
> 
> They handle it exactly like raw video. However this seems to have only ~5 bit
> per pixel and I can't find where exactly they map this to a real raw video
> format.

qtdemux doesn't place the palette as the second plane in the output buffer. The size of the buffer is 44*42 (=1848) + 4*256 = 2872 (but we only get 1848)
Comment 7 Wim Taymans 2013-07-17 07:59:08 UTC
This plays it. I'm unsure that we use the right palette.

commit 6b82c89562a0985150a966b55b78d558865e8973
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Jul 17 09:56:01 2013 +0200

    qtdemux: add support for WRAW
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=704292

commit f698483bb332e7892aec9f261cc1cc47c6a29069
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Jul 17 09:54:58 2013 +0200

    qtdemux: palette is appended to buffers, not in caps
    
    Fix the palette handling, in 1.0 we append the palette to the buffer instead of
    placing it on the caps.
    
    See also https://bugzilla.gnome.org/show_bug.cgi?id=704292
Comment 8 Tim-Philipp Müller 2013-07-19 13:40:33 UTC
This is fixed now, I think (although I wonder if the palette change doesn't break other things, gst-libav still has code that takes the palette from the caps...):

 commit 4c97701650696352ce9b0db3e90f34c90ff9baef
 Author: Wim Taymans <wim.taymans@collabora.co.uk>
 Date:   Wed Jul 17 15:10:00 2013 +0200

    qtdemux: extract the palette from stsd
    
    Sometimes a palette is inside the stsd, extract it instead of always using
    the default one
Comment 9 Wim Taymans 2013-07-19 13:44:40 UTC
(In reply to comment #8)
> This is fixed now, I think (although I wonder if the palette change doesn't
> break other things, gst-libav still has code that takes the palette from the
> caps...):

It does indeed but that code path is for encoded data with a palette, not for raw video.
Comment 10 Wim Taymans 2013-07-19 13:46:02 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > This is fixed now, I think (although I wonder if the palette change doesn't
> > break other things, gst-libav still has code that takes the palette from the
> > caps...):
> 
> It does indeed but that code path is for encoded data with a palette, not for
> raw video.

ah, but what if qtdemux produces encoded data with a palette.. I guess it only needs to add the palette to the buffer on raw formats and otherwise store it in caps.
Comment 11 Wim Taymans 2013-07-19 15:16:23 UTC
This should do, kindof like how avi does it but the other way around:

commit 61a8937ced18b6644fc1a0fde4b0ee23459d9606
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Fri Jul 19 17:12:37 2013 +0200

    qtdemux: for non-raw video, move palette in caps
    
    We only need to append the palette to raw video buffers, non-raw video has the
    palette in the caps still.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=704292