[FFmpeg-devel] [PATCH v4 3/7] cmdutils: use new iteration APIs

wm4 nfxjfg at googlemail.com
Sun Mar 25 17:48:43 EEST 2018


On Sun, 25 Mar 2018 16:41:12 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> 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.  

Yes, libavdevice is flawed. It's a "separate" library, but uses a lot
of internal libavformat functionality, against all API and ABI rules.
This can't be fixed with a more fancy component registration scheme.

> If this is true, in general, then we can improve designs by removing 
> avpriv_* functions ...

Not necessarily. avpriv_ functions exist in the first place to avoid
worse things. Like making things public that shouldn't be public.

> 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 is 100% offtopic bikeshedding. Please don't make this discussion
harder than it is.


More information about the ffmpeg-devel mailing list