[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl
Thu Apr 16 15:33:48 CEST 2009
On Wed, Apr 15, 2009 at 04:35:04PM -0700, Baptiste Coudurier wrote:
> On Thu, Apr 16, 2009 at 01:08:41AM +0200, Michael Niedermayer wrote:
> > On Wed, Apr 15, 2009 at 03:39:50PM -0700, Baptiste Coudurier wrote:
> > > On Wed, Apr 15, 2009 at 11:55:48PM +0200, Michael Niedermayer wrote:
> > >
> > > If the third is not ok for anybody then fine.
> > >
> > > I find the second reasonable and should satisfy everybody IMHO.
> > > Palette is passed through AVPacket and it avoids parsing in pkt->data,
> > > though it grows a bit AVPacket struct. It's not like we are afraid of
> > > growing structs usually ;)
> > you really arent reading what others write
> > let me repeat
> > formats store several compressed palette chunks that update the previous
> > these need merging at the demuxer and parsing at the decoder no matter if
> > they are in data or palette_data
> Yes, but storing this merged palette in pkt->palette_data instead of
> pkt->data appears simpler to Ronald and me.
> I'll repeat what I just said:
> if pkt->palette_data then extract_palette in decoder
that first requires demuxers to extract the palette of the stored
packets and muxers to merge palette&data back
Theres no advantage of this, and i must admit i nearly lost any interrest
in fixing palettes, this discussion is so idiotic
The whole issue exists since years, and when finally 2 people start working
on fixing it you block all work with this discussion about where to store the
We have an existing API and that puts all of the packet in pkt->data, generic
muxers & demuxers expect this, your suggestion would require a change of this
API and IMO not to the better.
> if pkt->data then damn is there a palette in here ? How do I know ?
same as how mpeg knows that theres a quant table or how it knows if its
a b frame or p frame. Its written in pkt->data
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel