[FFmpeg-devel] maintainer duties

[Diego Biurrun]

On Sat, Apr 11, 2009 at 01:49:31PM +0200, Michael Niedermayer wrote:
> On Sat, Apr 11, 2009 at 01:14:29PM +0200, Diego Biurrun wrote:
> > On Sat, Apr 11, 2009 at 05:48:07AM +0200, Michael Niedermayer wrote:
> > > On Sat, Apr 11, 2009 at 03:42:04AM +0200, Diego Biurrun wrote:
> > > > 
> > > > I have already pointed the functions out:
> > > > 
> > > > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-March/065629.html
> > > 
> > > but this is what i meant, its either things that have alraedy been fixed
> > > or things that are non trivial to fix.
> > > you said above
> > > "Did any of them require considerable amounts of work?  I don't think so."
> > > 
> > > Whats left from this list needs considerable amounts of work
> > > 
> > > lets see whats in that list:
> > > 
> > > > Michael:
> > > > libavformat/asfdec.c:364: warning: AVPaletteControl is deprecated
> > > > libavformat/avidec.c:491: warning: AVPaletteControl is deprecated
> > > 
> > > we first need to decide how to put the palette info into the bitstream, also
> > > fixing these 2 will require all decoders that support palettes from avi/asf
> > > to be fixed at the same time as well.
> > 
> > If this has not been decided, why is the function deprecated?  There
> > should be a proper replacement first...
> 
> It has been decided to put the palette in the AVPackets
> how to do this is a question per decoder and per demuxer, some may have a
> natural way to pass the palette, some might even say in a spec how to do it
> (though i guess that would be the exception if it applies to any at all)
> the rest could just have a 'P'<len> vs. 'D' prefixed to packets
> 
> Besides AVPaletteControl in broken, it is not thread safe and does not work
> in threaded players (ffplay being an example)
> The deprecation of it just makes it nicely vissible that the code is broken
> not deprecating it will just hide the bugs

I am not disagreeing with the deprecation at all.  I am just saying that
the way we handle deprecated functions could (and IMO should) be
improved.

> > > > Remaining deprecated functions are AVPaletteControl and ff_realloc_static,
> > > > the latter is only used once even...
> > > 
> > > its used just once but to fix this each use of init_vlc() has to be changed
> > > and in some cases in non trivial ways
> > > I fixed some of these init_vlc cases, i did not fix all.
> > > I was hoping the respective maintainers of the files would help ...

What's missing now that Carl Eugen applied his patch?

> > Why did you not request the maintainers to fix their code?
> 
> IIRC, i did

I don't remember.  A more concerted effort could be in order.  I have
already made a list of deprecated function use.

> > > So next time you accuse me (and i am sure you will because it seems to be
> > > poplar and the more polite i awnser the more people do)
> > > maybe you should read and understand the code over which it is first.
> > 
> > What I want you to do is give proper attention to these matters and not
> > leave them half-done.  When a function is deprecated, whomever creates
> > the replacement should fix up the deprecated uses or coordinate efforts
> > to get those uses replaced by maintainers or kindred spirits.
> 
> iam pestering mike since years to fix AVPaletteControl in his decoders

Well, turn up the heat a bit maybe ;)

> > Note that I managed to do it for rand() and friends, _t POSIX namespace
> > pollution and a few more things, so it's not like I do not put effort
> > into these issues.
> 
> _t an rand() where easy search and replaces, whats left needs more effort

The point is not how much or little work it is, but that it really does
get done.

We only have two deprecated functions left, ff_realloc_static and
AVPaletteControl.  There has to be a way to coordinate an effort to get
rid of them.  If our hearts stay pure we shall stamp out deprecated
functions in our lifetime.

Diego