Bill Dirks wrote:
> Gerd Knorr wrote:
> > So IMHO it would be useful to either:
> > - require driver do support *both* non-blocking I/O and
> > partial read()s
> > or
> > - allow drivers to support only blocking, full-frame read()s.
>
> I think I remember now why I didn't want to force partial read()
> support:
>
> 1. A device may not be able to capture in the format required by the
> application, so the driver is converting when it is copying to the user
> buffer. A partial read() may not end at a boundary compatible with the
> conversion routine, e.g. at a partial pixel. That can be worked around
> by having another buffer to hold the converted data, and then doing the
> partial read()s from that buffer.
Basically the same issue as with bttv: You need a extra temporary buffer,
making capture less efficient. I like ben's argument: make the read()
capture easy to use (and partial reads do help here). People who care
about performance can use mmap() with multiple buffers and all bells and
whistles.
> 2. There is no guaranteed way for the read()ing thread to know where the
> frame boundaries are from the read() call alone, especially if the data
> is compressed by a variable length compression.
A single read() call should never ever return data from more than one
frame. The last of multiple partial reads will just return the
remaining bytes of the current frame.
Gerd
--
Gerd Knorr <[EMAIL PROTECTED]> -- SuSE Labs, Au�enstelle Berlin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
