[FFmpeg-devel] [PATCH] avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32

[wm4]

On Wed, 23 Jul 2014 19:34:50 +0200
Reimar Döffinger <Reimar.Doeffinger at 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 <michaelni at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel