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

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



On Tue, 5 Aug 2003, Gerd Knorr wrote:

>> If the cost is 396 kilobytes of wasted memory, I'll rather let the driver
>> control double buffering itself than the applications.
>avoid copying data.  Having multiple buffers usually helps improving
>the performance of the applications.  For bttv I've raised the default

The point is that if the driver does the n-way buffering, why should
applications have even more buffers? I see little point in most cases, but
you are right, sometimes it helps (like with SMP system with two or more
compression threads...as in streamer). However, almost all programs don't
utilize several CPUs so it's better to save the 396 KiB at the moment.

In the future, I *am* planning to expose directly the multiple internal
buffers to userspace applications via mmap. However, this needs common
userspace conversion libraries, so it won't happen until xawtv supports
Gstreamer (or some other format conversion library) =)

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

Haven't tried that... but I have used -noscale -noxv options (which makes
xawtv slow) on relatively slow CPU (P2 366 MHz) and as long as the CPU
usage is less than 100%, I don't see any problems (i.e. no lost frames,
which are reported by the driver to the kernel logs).




[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