On 30-May-01 Gerd Knorr wrote:
>> >From a practial point of view though a high performance bttv application
>> (unless there ever is V4L async IO read) is going to want to use the
>> mmap interface, and so maybe read trade-offs should be selected in favor
>> of fuctionality/ease of use rather than performance - i.e. dma to bounce
>> buffer and provide non-blocking read and partial read if useful.
>
> I agree. If you care about performance, you likely need multiple
> buffers and the mmap() interface anyway. And partial reads are useful
> for scripting: "cat /dev/video0 > frame.raw".
>
> Should we to separate frames then? With EOF maybe?
No; just return the last buffer short, e.g. if an image is 100.000 bytes,
and you read in chunks of 60.000, the first read returns 60.000 bytes, and
the second read 40.000. A 3rd read would start at the second image and
return 60,000 bytes again, etc.
>> One problem is that as things stand for some drivers read() is the only
>> supported interface so needs to be as efficient as possible.
>
> Do such drivers exist? Is partial read a issue for them? If they
> use kernel buffers anyway for some reason (decompress video data from
> usb for example), copy_to_user in many small instead of one big chunk
> is no big deal.
My Philips webcam driver (you may have heard of it recently), supports
mmap() AND both blocking and non-blocking read() AND allows partial reads.
Now the difference between this driver and a BTTV card is that it needs
memory buffers to put the full image in, so this memory is ´wasted´ anyway.
Is it really a problem to allocate space for one buffer to DMA to in case a
tool uses only read()?
Another difference is that the cam sends a constant stream of images, in
contrast to the CPiA based cams that you have to ´kick´ each time a frame
is requested; this could cause relative long latencies, and thus low
throughput with such cams.
- Nemosoft
-----------------------------------------------------------------------------
Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000
URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight <<
