[FFmpeg-devel] [RFC] WC3 decoder without AVPaletteControl
Wed Apr 15 23:12:04 CEST 2009
On Wed, Apr 15, 2009 at 01:22:10PM -0700, Baptiste Coudurier wrote:
> > > I understand the problem with race condition is because the demuxer
> > > actually updates AVCodecContext palette directly, but IMHO that can be
> > > fixed by letting application dealing with palette change.
> > So your solution is just to remove the only way to pass the palette that is
> > there?
> Absolutely not.
> > Sorry, I really don't see the point of continuing discussion if you only provide
> > solutions that are so much simpler because they don't even half-work and in
> > some other cases because you are free to choose whichever way is more convenient
> > for them problem but exclude each other (e.g. "compressed" vs. uncompressed
> > palette data).
> I don't agree with you. I propose alternatives but you just don't want
> to consider them. It's not what I call try to find compromises nor consensus.
Because to me they look flawed front to end and are not even yet finished enough
to be code.
> There are some way to avoid av_grow_packet. I proposed alternatives. Now
> please let's try to find a compromise.
I asked I think now three or 4 times for alternatives to av_grow_packet that
allows assembling a single packet from different locations in a file.
I quoted one piece of code that could make good use of it and I doubt it
will be the only one.
I also suggest a way to do av_append_packet without av_grow_packet, but nobody
> IMHO it's not fair nor justified to ignore Ronald's and my comments.
Given above I can't see you doing any better, and I have been writing actual
code to solve a problem that has been ignored for months (years?), has already
the maintainers ok and was ignored for days.
> > It's just another bikeshed like that and I'm really tired of the
> > endless discussions it causes with in the end nobody doing any fix whatsoever,
> > just like in the DV demuxer case.
> Well IMHO adding another demuxer is poluting allcodecs/makefiles
> and is not needed.
I sent _two_ different solutions, It still did not get anywhere.
> > > Well, your patch assumes that libavcodec is used unfortunately,
> > No.
> Yes it does.
No it doesn't. Shall we go on like that some longer or are you going to
start to explain your ideas in a way that makes it possible for others to follow?
> > > and that libs are updated at the same time too.
> > As would any change removing AVPaletteControl
> Well I proposed an alternative which would not remove AVPaletteControl.
I can't see how it should work without changing applications though.
I admit I have not considered how mixing lav* versions would work with it.
> As a side note, I don't think av_grow_packet, av_append_packet belongs to
> public API, nor av_shrink_packet but it's too late.
The decision was that libav* should only use public functions from other libav*,
in that case there is no choice.
More information about the ffmpeg-devel