[FFmpeg-devel] [PATCH] avcodec: add AVCODEC_REQUIRED_INPUT_BUFFER_PADDING_SIZE, split FF_INPUT_BUFFER_PADDING_SIZE

wm4 nfxjfg at googlemail.com
Sat Jun 14 12:11:34 CEST 2014


On Fri, 13 Jun 2014 17:11:09 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Fri, Jun 13, 2014 at 03:08:11PM +0200, wm4 wrote:
> > > no reply here ?
> > > you are more interrested in the complaint than the solution ?
> > 
> > No, I'm rejecting the very concept of the solution.
> > 
> > I don't think it's a good idea to make these weird corner cases explicit
> > (such as the possibility that the packet buffer might be passed as
> > AVFrame to libavfilter). Rather, it's better to pretend this corner
> > case doesn't exist by making the amount of required padding always the
> > same.  Make it explicit that the user has to pad with 0, instead of
> > writing something weird about what bits must be set when using mpeg, and
> > that nobody really understands in its full consequences. This just
> > leads to users guessing wrong.
> 
> I don't fully understand this.
> This sounds to me like your complaint is with the documentation, and
> only the documentation.

Just because it's documented it doesn't make a reasonable API.
Requiring alignment (beyond C requirements) and padding (past the
buffer bounds you pass to the library) is a very surprising thing, and
it will probably easily make users do the wrong thing.

You and me are experienced in using the FFmpeg API. We know that input
buffers have such requirements and are used to that fact. But for
inexperienced/new users, it's a minefield full of traps, and they
trigger only "sometimes" (security issues with broken files, here we
come!).

> We can easily write "allocate all data with av_malloc_padded to easily
> get correct behaviour" (assuming I have not missed any corner-cases
> it would break).
> However that is not the same as _requiring_ everyone to do that,
> and we should allow people to use less restrictive solutions for
> the cases where it is needed.

Sure, I even suggested that. But the least restrictive API would be
just accepting any input, and only access the buffer passed by the user
within the bounds.


More information about the ffmpeg-devel mailing list