On Sun, Jul 20, 2014 at 10:43:30PM +0200, Andreas Cadhalpun wrote: > On 12.06.2014 08:42, Christophe Gisquet wrote: > >Hi, > > > >2014-06-11 21:29 GMT+02:00 Michael Niedermayer <michae...@gmx.at>: > >>-#define FF_INPUT_BUFFER_PADDING_SIZE 16 > >>+#define FF_INPUT_BUFFER_PADDING_SIZE 32 > > > >So, following the discussion on how API users may be affected by this > >change, does that need an API bump? > > One effect of this change is that now mplayer2 fails to build, because it > uses this check: > #if MP_INPUT_BUFFER_PADDING_SIZE < FF_INPUT_BUFFER_PADDING_SIZE > #error MP_INPUT_BUFFER_PADDING_SIZE is too small! > #endif > > MP_INPUT_BUFFER_PADDING_SIZE is defined as 16. Increasing that to 32 allows > building mplayer2 again.
That is probably needlessly conservative. For MPlayer we decided matching FFmpeg exactly is silly and set it to 64 instead. > So I think an API bump wouldn't have been a bad idea. As the person who added this: I intentionally accepted the maintenance burden of this, it is exactly there because I expected it might change at any time. The real problem in this case, is that it's not really an API change. It seems the padding requirement has been 32 since some time (always?), it just was never "documented". Bumping API for this change would be equivalent to bumping it for a bug fix. Which is a horribly bad thing since it means everyone using the old API will _necessarily_ be using a buggy version. The only real option would have been to change everything to only require those 16 bytes padding we claimed to require, at least for the old versions. Which I'm afraid we won't find anyone willing to do (and to be honest I'd consider a bit of waste of resources). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
