[FFmpeg-devel] [PATCH] avcodec: increase FF_INPUT_BUFFER_PADDING_SIZE to 32
michaelni at gmx.at
Mon Jul 21 00:48:52 CEST 2014
On Sun, Jul 20, 2014 at 10:43:30PM +0200, Andreas Cadhalpun wrote:
> On 12.06.2014 08:42, Christophe Gisquet wrote:
> >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!
> MP_INPUT_BUFFER_PADDING_SIZE is defined as 16. Increasing that to 32
> allows building mplayer2 again.
> So I think an API bump wouldn't have been a bad idea.
I think a soname bump would cause alot more work for everyone
but lets assume we did bump soname and changed it to 32 after that
what with the old API/ABI ? it needs 32 too in the exact same corner
cases that the new API/ABI needs it. But all apps that are build
against the old AND which use these corner cases are then buggy.
that doesnt sound better to me
IMHO there where just 2 options
either one changes FF_INPUT_BUFFER_PADDING_SIZE to 32 or one doesnt
use more than 16bytes ever. Bumping API is not a fix for this
And iam trying to change functions where easily possible to require
less padding, help there is sure welcome
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel