[FFmpeg-devel] [RFC] avpriv cleanup

[Michael Niedermayer]

On Sun, Mar 25, 2018 at 05:07:33PM +0200, wm4 wrote:
> On Sun, 25 Mar 2018 17:00:32 +0200
> Michael Niedermayer <michael at niedermayer.cc> wrote:
> 
> > Hi all
> > 
> > Nicolas wrote an interresting comment about avpriv, and as this better
> > belongs into a new thread, here it is in a new thread
> > 
> > On Sun, Mar 25, 2018 at 03:32:33PM +0200, Nicolas George wrote:
> > > Josh de Kock (2018-03-23):  
> > [...]
> >      
> > > You can observe just that by the fact that you needed to add an avpriv
> > > function to let lavd communicate with lavf. Each time an avpriv function
> > > appears, it shows there is something flawed in the design.  
> > 
> > If this is true, in general, then we can improve designs by removing
> > avpriv_* functions ...
> > 
> > looking at what we have as avprivs, in the tree, i think some of these
> > could be indeed usefull as public APIs. And we need to already keep them
> > compatible as they are exported as avpriv too, so making such changes does
> > indeed in some cases look like a good idea to me
> > 
> > There are some avprivs we have currently though that are quite specific
> > to format intgernals, i dont think that its always a flaw to use avpriv
> > functions thus
> > 
> > but i think we should evaluate each of the currently existing avpriv
> > functions and check if the API wouldnt be usefull to user applications.
> > And if it wouldnt be better to make it properly public
> 

> This might apply to some cases, but in general: just no.

That is what i meant :)


> 
> We make things avpriv_ *because* we don't want them to be public API,
> but the odd multiple-library design forces us to. Not more, not less.
> 

> What is this thread even for? If you want to make certain functions
> public, post specific RFCs or patches. In general, we probably all
> agree that avpriv functions are necessary hacks to deal with the split
> library nonsense.

The thread is for finding out peoples oppinon before anyone spends time
writing patches.
For example it takes time to go over the functions and time to write patches
that turn functions with proper documention into public functions.

If people object to it, no point in anyone doing any of this work

Also there have been people looking for things to work on. If we agree
that looking over avpriv functions for more generally usefull ones 
makes sense then we need to discuss this in some thread for anyone
to be able to see that suggestion.

For a specific function
As a random example, lets take avpriv_set_systematic_pal2()
It provides a palette for 8bit per pixel formats which have a constant
palette. It sounds usefull to have this public to me ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180325/32c22ab0/attachment.sig>