Diederick C. Niehorster: > On Wed, Jun 16, 2021 at 11:33 AM Andreas Rheinhardt > <andreas.rheinha...@outlook.com> wrote: >> >> Nicolas George: >>> Andreas Rheinhardt (12021-06-16): >>>> Yes, because one is allowed to use an old libavdevice together with a >>>> new libavformat. >>> >>> Why do we allow that? What is the actual benefit? >>> >> AFAIK: Nothing. And I don't like it. > > It was my expectation that it would only make sense to use a set of > dynamic libraries generated from the same build (and thus revision), > not to mix and match. Is there a cost to no longer allowing (i.e. > documenting) mixing of library versions? Is there a benefit, e.g. in > being able to break (internal) ABI (not an issue i oversee)? > Cost: It might force you to update more libraries, thereby increasing download (or upload if you are the distributor) size. Benefit: Besides fixing the horrible libavformat-libavdevice relationship (we are currently not able to add a public field to AV(In|Out)putFormat unless the ABI is open; we are not able to add new private fields either if they are to be used in libavformat unless we add checks for whether we deal with a device from an old version of libavdevice that doesn't this option; we can not remove private fields unless the ABI is open) it also makes sizeof of all our internal structs usable in all libraries; because all the offsets are fixed, the avpriv functions that are basically getters and setters can be removed immediately. Structures crossing library boundaries were no problem any more (we accidentally broke ABI in 88d80cb97 with this; it wouldn't be a problem at all if we disallowed using libraries from different revisions). We can also modify all avpriv symbols without caring about compatibility with older users.
- Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
