Hi Hans, On 02/26/2011 02:56 PM, Hans Verkuil wrote: > On Saturday, February 26, 2011 14:39:54 Sylwester Nawrocki wrote: >> On 02/26/2011 02:03 PM, Guennadi Liakhovetski wrote: >>> On Sat, 26 Feb 2011, Hans Verkuil wrote: >>> >>>> On Friday, February 25, 2011 18:08:07 Guennadi Liakhovetski wrote: >>>> >>>> <snip> >>>> >>>>>>> configure the sensor to react on an external trigger provided by the flash >>>>>>> controller is needed, and that could be a control on the flash sub-device. >>>>>>> What we would probably miss is a way to issue a STREAMON with a number of >>>>>>> frames to capture. A new ioctl is probably needed there. Maybe that would be >>>>>>> an opportunity to create a new stream-control ioctl that could replace >>>>>>> STREAMON and STREAMOFF in the long term (we could extend the subdev s_stream >>>>>>> operation, and easily map STREAMON and STREAMOFF to the new ioctl in >>>>>>> video_ioctl2 internally). >>>>>> >>>>>> How would this be different from queueing n frames (in total; count >>>>>> dequeueing, too) and issuing streamon? --- Except that when the last frame >>>>>> is processed the pipeline could be stopped already before issuing STREAMOFF. >>>>>> That does indeed have some benefits. Something else? >>>>> >>>>> Well, you usually see in your host driver, that the videobuffer queue is >>>>> empty (no more free buffers are available), so, you stop streaming >>>>> immediately too. >>>> >>>> This probably assumes that the host driver knows that this is a special queue? >>>> Because in general drivers will simply keep capturing in the last buffer and not >>>> release it to userspace until a new buffer is queued. >>> >>> Yes, I know about this spec requirement, but I also know, that not all >>> drivers do that and not everyone is happy about that requirement:) >> >> Right, similarly a v4l2 output device is not releasing the last buffer >> to userland and keeps sending its content until a new buffer is queued to the driver. >> But in case of capture device the requirement is a pain, since it only causes >> draining the power source, when from a user view the video capture is stopped. >> Also it limits a minimum number of buffers that could be used in preview pipeline. > > No, we can't change this. We can of course add some setting that will explicitly > request different behavior. > > The reason this is done this way comes from the traditional TV/webcam viewing apps. > If for some reason the app can't keep up with the capture rate, then frames should > just be dropped silently. All apps assume this behavior. In a normal user environment > this scenario is perfectly normal (e.g. you use a webcam app, then do a CPU > intensive make run). All right, I have nothing against extra flags, e.g. in REQBUFS to define a specific behavior. Perhaps I didn't express myself straight. I was thinking only about stopping the capture/DMA engine when there is no more empty buffers. And releasing the last buffer rather than keeping it in the driver. Then when subsequent buffer is queued by the app the driver would restart the capture engine. Streaming as seen from user space is not stopped. This just corresponds to a frame dropping mode, discarding just happens earlier in the H/W pipeline. It's no different from the app POV than endlessly overwriting memory with new frames. BTW, in STREAMON ioctl documentation we have following requirement: "... Accordingly the output hardware is disabled, no video signal is produced until VIDIOC_STREAMON has been called. *The ioctl will succeed only when at least one output buffer is in the incoming queue*." It has been discussed that memory-to-memory interface should be an exception from the at least one buffer requirement on an output queue for STREAMON to succeed. However I see no good way to implement it in videobuf2. Now there is a relevant check in vb2_streamon. There were opinions that the above restriction causes more harm than good. I'm not sure if we should keep it. I'm working on mem-to-mem interface DocBook documentation and it would be nice to have this clarified. Regards, Sylwester -- 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
