> 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... If we are speaking of devices like camera for phone/tabs, then this will have significant impact on the power consumption. > 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. I think it depends on hardware's behavior on how it behaves without any buffers queued. Some hardwares do notify the overflow state (interrupting for each frame recieved) if there was no buffer queued. This will ensure even the last frame is DQUEUEd. Considering the scenario like preview/capture @ 30fps, if there is one frame loss too, it is acceptable. But that doesnt hold good for high-speed image capture. Regards, Subash On Tue, Mar 15, 2011 at 8:51 AM, Pawel Osciak <pawel@xxxxxxxxxx> wrote: > 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
