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 <nico...@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
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

Reply via email to