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

[Trent Piepho]

On Wed, 27 Jun 2007, Marc Hoffman wrote:
> On 6/27/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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.  Correct me if you think this not
> true or this is only how Blackfin video4linux works.

What you are supposed to do is not re-queue the frame back to the driver
until you are done with it.

It's true that v4l usually has a queue of at least 2 frames, but it's not a
requirement.  From the v4l1 API "The number of frames supported is device
dependent and may only be one." I don't think v4l2 is any different in this
regard.

But that's not the real problem.

On some hardware, it's not possible for the CPU and the capture device to
have access to the same memory at the same time.  If you look at the kernel
DMA mapping api, there are functions for putting a dma mapping into "cpu
mode" or "bus mode" and warning about the necessity of using them.

Once you queue a frame back into v4l, with QBUF (v4l2) or MCAPTURE (v4l1),
you are not allowed to access it anymore.  With some hardware you will be
able to keep using the frame up to the point where it reaches the head of
the queue and it written over, but that's not always the case.  And even
when it does work, it's not safe.  Capture is a real time process, once you
queue the frame back to v4l, it _will_ be over-written after X
milliseconds.  If your program is still using the frame, there is no way
you can guarantee that you will be done with the frame in less than X ms.