V4L2_DEC_CMD_STOP and last_buffer_dequeued

V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Wu-Cheng Li (李務誠)]

Hi,
I'm trying to use V4L2_DEC_CMD_STOP to implement flush. First the
userspace sent V4L2_DEC_CMD_STOP to initiate the flush. The driver set
V4L2_BUF_FLAG_LAST on the last CAPTURE buffer. I thought implementing
V4L2_DEC_CMD_START in the driver was enough to start the decoder. But
last_buffer_dequeued had been set to true in v4l2 core. I couldn't
clear last_buffer_dequeued without calling STREAMOFF from the
userspace. If I need to call STREAMOFF/STREAMON after
V4L2_DEC_CMD_STOP, it looks like V4L2_DEC_CMD_START is not useful. Did
I miss anything?

Regards,
Wu-Cheng

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Nicolas Dufresne]

Le mercredi 12 octobre 2016 à 23:33 +0800, Wu-Cheng Li (李務誠) a écrit :
> I'm trying to use V4L2_DEC_CMD_STOP to implement flush. First the
> userspace sent V4L2_DEC_CMD_STOP to initiate the flush. The driver
> set
> V4L2_BUF_FLAG_LAST on the last CAPTURE buffer. I thought implementing
> V4L2_DEC_CMD_START in the driver was enough to start the decoder. But
> last_buffer_dequeued had been set to true in v4l2 core. I couldn't
> clear last_buffer_dequeued without calling STREAMOFF from the
> userspace. If I need to call STREAMOFF/STREAMON after
> V4L2_DEC_CMD_STOP, it looks like V4L2_DEC_CMD_START is not useful.
> Did
> I miss anything?

It's likely what the driver do is slightly off what the spec say. All
user space code so far seems to only drain at EOS. As the next buffer
is a new stream, it make sense to completely reset the encoder. We'd
need to review that, but using CMD_START should work if you queue a
header first.

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.

regards,
Nicolas

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Wu-Cheng Li (李務誠)]

On Sat, Oct 15, 2016 at 2:20 AM, Nicolas Dufresne
<nicolas.dufresne@gmail.com> wrote:
>
> Le mercredi 12 octobre 2016 à 23:33 +0800, Wu-Cheng Li (李務誠) a écrit :
> > I'm trying to use V4L2_DEC_CMD_STOP to implement flush. First the
> > userspace sent V4L2_DEC_CMD_STOP to initiate the flush. The driver
> > set
> > V4L2_BUF_FLAG_LAST on the last CAPTURE buffer. I thought implementing
> > V4L2_DEC_CMD_START in the driver was enough to start the decoder. But
> > last_buffer_dequeued had been set to true in v4l2 core. I couldn't
> > clear last_buffer_dequeued without calling STREAMOFF from the
> > userspace. If I need to call STREAMOFF/STREAMON after
> > V4L2_DEC_CMD_STOP, it looks like V4L2_DEC_CMD_START is not useful.
> > Did
> > I miss anything?
>
> It's likely what the driver do is slightly off what the spec say. All
> user space code so far seems to only drain at EOS. As the next buffer
> is a new stream, it make sense to completely reset the encoder. We'd
> need to review that, but using CMD_START should work if you queue a
> header first.

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
>
>
> 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.
>
>
> regards,
> Nicolas

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Nicolas Dufresne]

[-- 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 --]

Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Wu-Cheng Li (李務誠)]

We found videobuf2-core.h has a function
vb2_clear_last_buffer_dequeued to clear last_buffer_dequeued. We call
vb2_clear_last_buffer_dequeued in the driver when it gets CMD_START.
Everything works now.

On Mon, Oct 17, 2016 at 9:46 PM, Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
> 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?
We found
>>
>> 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