On Sat, Oct 15, 2016 at 2:20 AM, 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.
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
> 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.
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