On Monday 28 February 2011 11:40:31 Hans Verkuil wrote:
> On Monday, February 28, 2011 11:28:58 Laurent Pinchart wrote:
> > On Saturday 26 February 2011 14:56:18 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]

> > > > >>> 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).
> > 
> > Why couldn't drivers drop frames silently without a capture buffer ? If
> > the hardware can be paused, the driver could just do that when the last
> > buffer is given back to userspace, and resume the hardware when the next
> > buffer is queued.
> 
> It was my understanding that the streaming would stop if no capture buffers
> are available, requiring a VIDIOC_STREAMON to get it started again. Of
> course, there is nothing wrong with stopping the hardware and restarting
> it again when a new buffer becomes available if that can be done
> efficiently enough. Just as long as userspace doesn't notice.
> 
> Note that there are some problems with this anyway: often restarting DMA
> requires resyncing to the video stream, which may lead to lost frames.

You'll loose frames when you get a buffer underrun anyway :-)

> Also, the framecounter in struct v4l2_buffer will probably have failed to
> count the lost frames.
> 
> In my opinion trying this might cause more problems than it solves.

Whether drivers will hold on the last buffer and keep filling it again and 
again until a new buffer is available, or stop the stream and resume it 
transparently when a new buffer is queued, should probably be left as a choice 
to the drivers. I'm in favour of the second option, but I understand that it 
might be difficult to implement for some hardware. The spec should at least 
not preclude it when efficient hardware support is available.

> > > I agree that you might want different behavior in an embedded
> > > environment, but that should be requested explicitly.
> > > 
> > > > In still capture mode (single shot) we might want to use only one
> > > > buffer so adhering to the requirement would not allow this, would
> > > > it?
> > > 
> > > That's one of the problems with still capture mode, yes.
> > > 
> > > I have not yet seen a proposal for this that I really like. Most are
> > > too specific to this use-case (snapshot) and I'd like to see something
> > > more general.
> > 
> > I don't think snapshot capture is *that* special. I don't expect most
> > embedded SoCs to implement snapshot capture in hardware. What usually
> > happens is that the hardware provides some support (like two independent
> > video streams for instance, or the ability to capture a given number of
> > frames) and the scheduling is performed in userspace. Good quality
> > snapshot capture requires complex algorithms and involves several
> > hardware pieces (ISP, flash controller, lens controller, ...), so it
> > can't be implemented in the kernel.
> 
> I agree.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to