Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Jun 13 17:05:17 CEST 2014

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.
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.

More information about the ffmpeg-devel mailing list