Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Nicolas Dufresne <nicolas@ndufresne.ca>]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Le samedi 15 octobre 2016 à 08:16 +0800, Wu-Cheng Li (李務誠) a écrit :
> last_buffer_dequeued is only cleared to false when CAPTURE queue is
> STREAMOFF (#1). Queuing a header to OUTPUT queue won't clear
> last_buffer_dequeued of CAPTURE queue. It looks to me that v4l2 core
> needs to intercept CMD_START and clear last_buffer_dequeued. What do
> you think?
> 
> http://lxr.free-electrons.com/source/drivers/media/v4l2-core/videobuf2-core.c#L1951

That sounds reasonable, assuming it does not break drivers.

> >
> >
> > Note that for many a flush is the action of getting rid of the pending
> > images and achieve by using STREAMOFF. While the effect of CMD_STOP is
> > to signal the decoder that no more encoded image will be queued, hence
> > remaining images should be delivered to userspace. They will
> > differentiate as a flush operation vs as drain operation. This is no
> > rocket science of course.
> 
> I see. What I want is drain operation. In Chromium terms, CMD_STOP
> maps to flush and STREAMOFF maps to reset.

Yes, that's the reason I was mentioning. This was a great source of
confusion during a workshop with some Google/Chromium folks.

A question on top of this, what are the use cases for you to drain
without flushing afteward ? Is it really needed ?

regards,
Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]