[FFmpeg-devel] [PATCH 21/35] avdevice: capabilities API details no longer public

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Tue Jun 8 13:46:06 EEST 2021


Diederick C. Niehorster:
> On Tue, Jun 8, 2021 at 1:54 AM Andreas Rheinhardt <
> andreas.rheinhardt at outlook.com> wrote:
> 
>> Diederick Niehorster:
>>> NB: will break build, makes needed corresponding changes to avformat.
>>>
>>
>> Then said changes should be part of this patch. Patches should be
>> logically self-contained and atomic; this is not the same as splitting
>> by file/library.
>>
>> But that is a moot point: James already told you a better way to fix this.
>>
> 
> Made sense. But indeed, James' way of doing it obviates that next patch
> changing avformat.h
> 
> 
>>> --- a/libavdevice/internal.h
>>> +++ b/libavdevice/internal.h
>>
>> We prefer the order libavutil-libavcodec-libavformat (the reverse of
>> linking order).
>>
> 
> fixed.
> 
> 
>>> + * AVOption table used by devices to implement device capabilities API.
>> Should not be used by a user.
>>
>> That last part is superfluous, as (external) users by definition have no
>> business looking into internal.h.
>>
> 
> Ah yes, copy paste.. Fixed.
> 
> 
>>> + */
>>> +extern const AVOption av_device_capabilities[];
>>
>> Don't use this name: av_* is our namespace for public symbols. Our
>> linker script makes sure that all symbols that start with av_* are
>> exported; whether they are in a public header is irrelevant.
>> Not exporting the symbol in the first place also solves the problem of
>> users using it despite it not being part of the API.
>> (I btw don't know whether said linker script is used on Windows.)
>>
> 
> I changed it to a ff_ prefix. Is that correct?

Yes (presuming there are (or will eventually be) users of this in
different translation units).

- Andreas


More information about the ffmpeg-devel mailing list