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