[FFmpeg-devel] [PATCH 01/54] avformat: Add internal flags for AV(In|Out)putFormat

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Wed Jun 16 13:45:08 EEST 2021


Diederick C. Niehorster:
> On Wed, Jun 16, 2021 at 11:33 AM Andreas Rheinhardt
> <andreas.rheinhardt at 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


More information about the ffmpeg-devel mailing list