[FFmpeg-devel] rough PATCH: reducing the memory copies

Robin Getz rgetz
Fri Jun 29 21:28:47 CEST 2007

On Wed 27 Jun 2007 09:28, Marc Hoffman pondered:
> On 6/27/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > Hi
> >
> > you always push, also the code is buggy it starts capture into the
> very
> > buffer which you return IIRC
> > and adding a function to the public interface is not something we do
> > quickly before the holiday, even less so if its just to avoid 2 lines
> of
> > code in grab.c
> I don't think this code starts to capture into the same buffer you
> return. If the number of frames the v4l driver is 1 then I agree with your
> assessment but it has more than 1.  The way the driver is suppose to work is
> that it rotates through the set of buffers in a circular fashion probably
> ping pong.  So that this can never happen.  

It's not just ping pong - it is all controlled in userspace. It can be 
whatever the application wants it to be.

If you are using the v4l1/2 mmap interface, userspace asks how many frames the 
driver supports, and then tells it to capture/sync to frame n.


Userspace is allowed to call VIDIOCMCAPTURE multiple times (with different 
frame numbers) and thus have multiple outstanding capture requests. A simple 
way do to double-buffering using this feature looks like this:

/* setup everything */
while (whatever) {
   /* process frame 0 while the hardware captures frame 1 */
   /* process frame 1 while the hardware captures frame 0 */

Note that you are not limited to only two frames. The API allows up to 32 
frames, the VIDIOCGMBUF ioctl returns the number of frames the driver 
granted. Thus it is possible to build deeper queues to avoid loosing frames 
on load peaks.

Just because you have 2+ frames, doesn't mean you need to use them. It is up 
to the app.

The number of frames that must be handled is from 1 to 32, normally - most 
versions of frame captures apps that I have seen handle the one frame only 
case differently from 2+ frames (as Marc's patch does).


More information about the ffmpeg-devel mailing list