I have noticed that MPlayer blindly regards anything in the 'extradata' for a video stream as being a palette, that it tacks onto a "fake" BITMAPINFOHEADER in libmpdemux/demux_lavf.c, and which is used later on as palette side data in libmpcodecs/vd_ffmpeg.c.
In my patch of libavformat/matroskadec.c, the palette will be used as side data as well, in matroska_deliver_packet(). Unfortunately, MPlayer will win this "palette side data fight". Now, the easiest solution to make MPlayer use the correct palette for V_QUICKTIME video inside Matroska (and the one I've been using in my patch) is to put the palette in 'extradata', rather than trying to make the MPlayer developers change their idea about what 'extradata' might contain. Look at the V_MS/VFW/FOURCC section in matroskadec.c, it uses 'extradata_offset' to point at the part of the private data (i.e. the BITMAPINFOHEADER) where the palette is located (40). Unfortunately, this can't be applied to V_QUICKTIME, first and foremost because many times the private data (i.e. the contents of the 'stsd' atom) for QuickTime video doesn't contain a palette, but uses the default Macintosh palette, so you'll have to create 'extradata' outside of the private data, which I've also done in my patch. If I *don't* do this, MPlayer will use the whole private data (the contents of the 'stsd' atom, which 'extradata' normally contains in the case of QuickTime video) as the palette, which of course won't work. I'm just trying to explain the reasons behind the changes I've made to matroskadec.c. I hope there is *someone* who understands what I'm talking about. Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
