wm4 nfxjfg at googlemail.com
Fri Jun 13 13:58:29 CEST 2014

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

> On 13.06.2014, at 12:41, wm4 <nfxjfg at googlemail.com> wrote:
> > On Fri, 13 Jun 2014 03:32:59 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> >> On Fri, Jun 13, 2014 at 02:49:01AM +0200, wm4 wrote:
> >> 
> >> padding that is required for input to libavcodec
> >> 
> >> FF_INPUT_BUFFER_PADDING_SIZE represents the amount that we pad.
> >> Using this we can pass the output from libavcodec to other libs like
> >> libavfilter in the case where (due to rawvideo) the input has been
> >> passed through
> >> 
> >> I hope above is understandable
> > 
> > Yes, but still confusing. At least it could be a global constant, maybe
> > defined in libavutil/mem.h? Actually, why does not just av_malloc add
> > the padding? It also ensures alignment, so why not. (It will waste some
> > memory, but you do that for alignment too, with every allocation, even
> > strings.)
> > 
> > Declaring that input buffers must be allocated with av_malloc because
> > ffmpeg is so damn "special" is probably easier to understand for API
> > users. For advanced users, enumerating the memory buffer requirements
> > somewhere else might be useful too.
> That has serious implications for zero-copy implementations, which at the 4k resolution level at least are critical.

I'm not sure how you mean this. Maybe the fact that some users will have
to copy the input buffer to get the required padding (and to zero it)?
E.g. consider a demuxer that mmaps the input file, and tries to pass a
pointer to the packet to the decoder.

> However it also means that increasing alignment requirements would mean doing a major version bump of avutil, instead of just e.g. updating the existing avcodec functions that specify the required alignment to an application.

Having to keep track of dozens of padding requirements is worse.

More information about the ffmpeg-devel mailing list