On Sun, 25 Mar 2018 16:41:12 +0200 Michael Niedermayer <mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel