This WRAW fourcc is unknown even to Google, more info needed.

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

How certain are you that what ffmpeg is displaying is correct ? mplayer built against the same libffmpeg as ffplay seems to reject it also.

Doesn't mplayer use its own demuxers? I can confirm that avplay plays it properly here but mplayer (using the same libav) doesn't.

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.

(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)

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

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

(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.

(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.

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