On Wed, 23 Jul 2014 19:34:50 +0200 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> 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". I'm not sure how you expect people to use the API correctly if it's managed this chaotically. And yes, implicit buffer padding required by all API _is_ part of the API, an extremely important one, even. You know, in a low level language like C it's an absolutely heresy to write past buffer boundaries (even if it's in a "controlled" way), and being unclear about how large the padding is, is just FUCKING BULLSHIT. > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
