Hi, On Mon, Mar 14, 2011 at 03:49, Subash Patel <subashrp@xxxxxxxxx> wrote: > VIDIOC_STREAMON expects buffers to be queued before hardware part of > image/video pipe is enabled. From my experience of V4L2 user space, I > have always QBUFfed before invoking the STREAMON. Below is the API > specification which also speaks something same: > Not exactly. It says that the API requires buffers to be queued for output devices. It does not require any buffers to be queued for input devices. Sylwester is right here. This feature of not having to queue input buffers before STREAMON introduces problems to driver implementations and I am personally not a big fan of it either. But I'm seeing some additional problems here. Suppose we forced QBUF to be done before STREAMON. This would work, but what happens next? What should happen when we want to DQBUF the last buffer? If the device couldn't start without any buffers queued, can it continue streaming with all of them dequeued? I would guess not. So we'd either have to deny DQBUF of the last buffer (which for me personally is almost unacceptable) or have the last DQBUF automatically cause a STREAMOFF. So, for the latter, should applications, after they get all the data they wanted, be made to always have one more buffer queued as a "throwaway" buffer? This is probably the only reasonable solution here, but the applications would have to keep count of their queued buffers and be aware of this. Also, there might still be situations where being able to STREAMON without buffers queued would be beneficial. For example, enabling the device might be a slow/expensive operation and we might prefer to keep it running even if we don't want any data at the moment. Even for faster devices, being able to keep them on and periodically take a snapshot would be faster without having to call STREAMON anyway... -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
