This should be feasible entirely within dc1394, without meddling in
video1394. I support keeping backward compatibility with the current
dc1394_capture_dma() interface - for ease of porting legacy code.
One thing I would like to see: whatever changes we make to the DMA
capture infrastructure, it would be good to move gradually to a
situation where we can one day cleanly separate the DMA buffer
managment and video1394 interface from the low-level camera control
and register access.
At the moment for example it is not possible to change the frame rate
or the image size in Format 7 without releasing the camera,
re-allocating DMA buffers and doing camera set-up all over again. And
some calls like dc1394_set_format7_image_size() are instant-segfault
booby traps after DMA capture set-up.
When I last experimented with this (admittely some time ago), I could
not allocate a general mmap buffer and resize frames within it
dynamically without causing video1394 to choke. The current buffer
allocation and video1394 ioctl() calls are intimately tied to the
image size and pixel coding: it would be good to have a more loosely
David Moore wrote:
> I proposed to Damien a couple weeks ago that we add a new interface for
> capture that would look something like:
> dc1394capture_buf_t *
> dc1394_capture_dequeue(dc1394camera_t *);
> dc1394_capture_enqueue(dc1394camera_t *, dc1394capture_buf_t *);
> This way, an application could "dequeue" several frames at a time, and
> then "enqueue" them when finished. The only rule would be that you
> could not dequeue more frames than the dma buffer holds and you must
> enqueue them back in the same order your dequeued them.
> dc1394_capture_buf_t would be a newly-defined structure that would hold
> the address to the frame buffer as well as any other ancillary
> information such as its size, width, height, timestamp, etc.
> One nice property of this API is that it is more general than the
> current capture interface, allowing us to reimplement
> dc1394_capture_dma(), etc. as wrappers around these new functions. That
> way we get backwards compatibility without having to maintain two code
> paths separately.
> I haven't had time to implement any of this yet, but it would be nice to
> get it in before 2.0. I would be happy to help out if someone wanted to
> take a shot at implementing this.
> On Fri, 2006-08-25 at 10:45 +0200, Mikael Olenfalk wrote:
>>Is it possible to get more fine grained access to the DMA ring buffer
>>used in DMA capture mode (video1394)? I would like to get a pointer to
>>every frame in the buffer and lock frames individually in the ring
>>After a dc1394_capture_dma(camera, 1, policy) call I would like to get a
>>pointer to the last/oldest/any frame and lock it (i.e. the video1394
>>will not overwrite that particular frame, but instead just jump to the
>>next one, should that particular frame not be released in time before
>>the video1394 driver gets back to that frame after filling the rest of
>>the ring buffer), that way we can implement a no-copy application and
>>still ensure that extensive and time-consuming processing will never be
>>interrupted by the driver overwriting the image we currently are
>>In normal circumstances the image processing is always fast enough to
>>process frames a lot faster than the camera can deliver and fill the
>>ring buffer; but as we are moving into an embedded environment we want
>>to keep the DMA ring buffer as small as possible (just a couple of
>>With kind regards,
>>Tobii Technology AB
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.