[FFmpeg-devel] [PATCH] avutil/frame: Move new field to the end of AVFrame

James Almer jamrial at gmail.com
Thu Jun 30 04:44:55 CEST 2016


On 6/29/2016 9:47 PM, James Almer wrote:
> On 6/29/2016 9:16 PM, Carl Eugen Hoyos wrote:
>> Hendrik Leppkes <h.leppkes <at> gmail.com> writes:
>>
>>> Plenty previous releases moved fields that were marked as "no direct
>>> access", usually because libav added a new field above the
>>> ffmpeg-exclusive ones (like AVFrame.channels, which is a common
>>> candidate), and we didn't do such a song and dance to accomodate
>>> everyone.
>>
>>> I asked this in other threads before - why this time?
>>
>> I thought the difference is that for all other fields 
>> we offered accessors that the API users could use to 
>> access the fields.
>>
>> Carl Eugen
> 
> They have accessors. All the private fields in AVFrame have accessors.
> The issue is that at least three projects weren't using them, and things
> broke for them as soon as the private fields moved.
> 
> This patch here attempts to break our ABI to accommodate the fact said
> projects weren't using the accessors, when the real solution for distros
> is to rebuild said packages targeting 3.1 and for those projects to use
> the accessors.
> 
> One of them (Kodi) already fixed their code[1], for that matter.
> 
> [1] https://github.com/xbmc/xbmc/pull/10043

For the record, if it really comes to it (distros not wanting to recompile
or update the broken downstream packages, or more packages found misusing
this api thus making adoption of 3.1 a PITA) I'm willing to concede and let
this patch break the 3.1 ABI just so applications built against 3.0 can work
with 3.1.1 libraries without the need to be recompiled.
3.1 is young and currently unused by distros, and 3.1.1 will already be
incompatible with it because of the AVFilterContext breakage. And since we
will after all bump all major versions with ffmpeg 3.2/4.0, the current
position of this field will not matter anymore.

But I'd very much prefer if we could for once not have to break our own code
just so downstream projects can postpone (or never bother) fixing theirs.


More information about the ffmpeg-devel mailing list