[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