On Fri, 4 Sep 2015 19:42:18 -0300 James Almer <jamr...@gmail.com> wrote:
> On 9/4/2015 7:06 PM, Hendrik Leppkes wrote: > > On Fri, Sep 4, 2015 at 11:43 PM, James Almer <jamr...@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.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel