On Sat, Oct 15, 2016 at 2:20 AM, Nicolas Dufresne <nicolas.dufresne@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
