Gerd Knorr wrote: > > > That reminds me, how should (digital) USB webcams implement > > VIDIOC_ENUMSTD? Should they set std.id = V4L2_STD_UNKNOWN? Should they > > just return -EINVAL? Or should we have have a V4L2_STD_DIGITAL_CAM for > > devices where modulation standards and fixed frame rates don't apply? > > Just returning -EINVAL looks fine to me. What can we really expect from usb cams? Will they appear like tv cards, just dropping 4/5 frames or sth like that? Even when lots of frames are missing they still arrive at some regular interval, a multiple of 33 or 40 ms I suppose. Assuming the wrong frame period, timestamps will suggest a non-integer number of frames missing between any two received frames. A decent app with good a/v sync will handle that and accumulate the error fractions. But when such a stream is recorded all the timestamps may be lost, leaving only the alleged frame rate (probably 30 Hz, being an upper limit) and no way to determine how far apart any two frames or fields really are. What about the v4l2_buffer.sequence field? I always assumed this is the number of transmitted, not read frames. The app can count read frames itself, so the latter would be useless. When a usb cam driver behaves accordingly the sequence number won't match the assumed frame period, greatly confusing apps. Or will v4l2_std_id = V4L2_STD_UNKNOWN change the semantics, considering "transmitted" now those sent over usb, instead of counting the number of frames really taken by the camera? > > And to answer your question, with USB webcams you cannot infer the > > timeperframe from any other fields in the V4L(2) API. > > Ok, then lets keep it. You do know v4l2_captureparm.timeperframe was intended to request a different frame period (frame skipping on the driver side, reducing the bus load) I suppose. Of course the app can request 33 ms and see what the driver is able to sustain, but that's not the primary purpose. The entire struct and ioctl are concerned with optimizing the capture process, which is optional as I understand. Michael
