Re: V4L2_DEC_CMD_STOP and last_buffer_dequeued

[Nicolas Dufresne <nicolas.dufresne@gmail.com>]

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