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

James Almer jamrial at gmail.com
Thu Jun 30 16:18:39 CEST 2016

On 6/30/2016 5:28 AM, Michael Niedermayer wrote:
> On Wed, Jun 29, 2016 at 11:44:55PM -0300, James Almer wrote:
>> 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
> mlt too breaks with 3.1
> https://trac.ffmpeg.org/ticket/5676

Yes, breaking our ABI of course will fix all these applications misusing the
avframe API. The point is, they shouldn't have ever accessed those fields
directly and we shouldn't have to break our ABI just so they can keep their
api usage broken.

Distros should recompile all these packages when upgrading ffmpeg, and those
packages should start accessing fields as their doxy clearly states to avoid
this kind of problems in the future.
It annoys me that the burden of fixing people's bad code is expected to be on

More information about the ffmpeg-devel mailing list