[FFmpeg-devel] [PATCH]Remove probesize32 and max_analyze_duration32 on version bump

wm4 nfxjfg at googlemail.com
Sat Sep 5 01:01:18 CEST 2015


On Fri, 4 Sep 2015 19:42:18 -0300
James Almer <jamrial at gmail.com> wrote:

> On 9/4/2015 7:06 PM, Hendrik Leppkes wrote:
> > On Fri, Sep 4, 2015 at 11:43 PM, James Almer <jamrial at gmail.com> wrote:
> >> On 9/4/2015 6:19 PM, Carl Eugen Hoyos wrote:
> >>> James Almer <jamrial <at> gmail.com> writes:
> >>>>>> Isn't removing these two going to break
> >>>>>> compatibility with libav?
> >>>>>
> >>>>> (ABI or API?)
> >>>>> I don't think so but I absolutely may miss something.
> >>>
> >>>> ABI, you're removing elements from the middle of the
> >>>> struct.
> >>>
> >>> In which situation would that be an issue?
> >>>
> >>> Carl Eugen
> >>
> >> Figured that since direct access is apparently allowed for elements
> >> above ts_id it would be an issue for applications built with libav
> >> that then use ffmpeg's lavf at runtime.
> >>
> >> Disregard this if that's not the case.
> > 
> > We are not really ABI compatible, and its not a goal worth going after.
> 
> Wonder why then is the code littered with duplicate defines and enum
> values (for example fourcc-like values for AVCodecID), setter/getter
> functions for struct elements not available in both projects, functions
> with different signatures and elements in some structs with different
> offsets depending if that incompatible_libav_abi option was requested
> during configure, etc...
> 
> Some files are a mess purely because of compatibility considerations.
> If in the end it's not a concern, then we should grab a broom after
> bumping major versions this weekend.

You know what, it's a perfect time to clean this up. I can remove the
Libav ABI compat hack and reassign the crazy FourCC enums, if such a
patch will get accepted. (We can change them because it's ABI bump
time.)


More information about the ffmpeg-devel mailing list