Michael Niedermayer (2018-03-25): > 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
The reason some functions are avpriv instead of public is quite simple: it was considered too much effort to keep them stable enough to make them public. For these cases, we have the ff_ prefix, it works perfectly. But for some reason, somebody decided to make several separate libraries for this single project. Hence the avpriv prefix, which is exported but not public, with functions that are supposed to be... we don't know how stable. There is an implicit policy that shared lav* must all have the same version, but nothing ensures that technically. The whole mess stems from a huge core flaw: having separate libraries. It does not bring any benefit (at least, any benefit that could not be achieved otherwise without the drawbacks) and makes everything more complicated. So could we please stop beating around the bush and possibly address the actual issue? Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
