wm4 nfxjfg at googlemail.com
Sat Jun 14 12:06:37 CEST 2014

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

> On Fri, Jun 13, 2014 at 01:58:29PM +0200, wm4 wrote:
> > On Fri, 13 Jun 2014 13:47:41 +0200
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > > 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.
> What do you want me to consider? That can be done safely currently if
> you ensure there is a 0-filled page after the mmaped range (tricky but
> possible). Requiring av_malloc would make this impossible.

No, if you mmap the whole file and then pass a pointer to the packet
within the file, then you can't just pad without copying. (I once
considered doing a mmapped demuxer, but this is one of the reason this
won't work.)

> Similar issues with OpenGL: You can request an arbitrary sized buffer
> from OpenGL and then tell it to e.g. place framebuffer data in it.
> You can easily ensure 0 padding (it might cost you a bit performance,
> but usually significantly less than doing a full copy of the frame
> into a buffer allocated via av_malloc).
> > > 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.
> For developers using FFmpeg yes. For us probably not. For normal users:
> not sure.

Keep in mind that making it simple for developers also has advantages
for the users of the developed software.

More information about the ffmpeg-devel mailing list