Re: buggy v4l apps (was: VIDIOCSYNC and bad data)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Tuukka Toivonen <tuukkat@xxxxxxxxxx> writes:

> >That is a very bad.  You have double-buffering implemented, but
> >instead of letting the applications control it via CAPTURE + SYNC
> >ioctls you hide it.
> 
> If the cost is 396 kilobytes of wasted memory, I'll rather let the driver
> control double buffering itself than the applications.

It isn't wasted.  It is used by the application for buffering.  xawtv
usually passes around pointers to the mmap()ed buffers, trying to
avoid copying data.  Having multiple buffers usually helps improving
the performance of the applications.  For bttv I've raised the default
number of buffers from 2 to 4 for exactly that reason (can be
overritten by insmod option gbuffers).

> >What does trigger a frame capture within your driver?  CAPTURE ioctl?
> 
> Either VIDIOCSYNC or read(), whichever comes first. After that I'll keep
> the camera streaming constantly until close(). (not exactly good if
> application captures a frame only rarely, but I'll implement later
> a timeout that disables streaming if nobody is capturing frames).

If you use MCAPTURE + SYNC you don't have to implement those hacks
like timeouts.  You just let the camera stream while you have empty
buffers queued by the application via MCAPTURE.  If the application
doesn't want more frames you can just stop and don't waste USB
bandwith to capture frames for /dev/null ...

> >It should work that way.  But I suspect it doesn't, otherwise the
> >"internal double buffering" wouldn't work as described ...
> 
> Correct, but it would be easy to start streaming at VIDIOCMCAPTURE instead
> of VIDIOCSYNC, but I don't see much point in that... so I haven't bothered.

See above.

> >  I guess xawtv works, but prints plenty of
> >"waiting for a free buffer" messages.  That indicates xawtv would
> >perform better with more buffers.
> 
> No, not at all. Works fine at full frame rate (15 fps) right now.
> No dropped frames. With a single mmap buffer.

Is that still true if xawtv does some CPU-bound processing of the
frames?  Writing mjpeg-compressed avi file for example?

  Gerd

-- 
sigfault




[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux