Am Donnerstag, den 16.04.2015, 10:23 +0200 schrieb Kamil Debski: [...] > > > But, in general, in what kind of scenario would the driver want to > > > call this function, as opposed to vb2 clearing this flag by itself on > > > STREAMOFF? > > > > There is VIDIOC_DECODER_CMD / V4L2_DEC_CMD_START. > > I'd expect this timeline for decoder draining and restart: > > > > - userspace calls VIDIOC_DECODER_CMD, cmd=V4L2_DEC_CMD_STOP > > after queueing the last output buffer to be decoded > > - the driver processes remaining output buffers into capture buffers > > and sets the V4L2_BUF_FLAG_LAST set on the last capture Buffet > > I would like to confirm that it will work with MFC. Am I right that the > below will work? Did you take that into account? I see no reason why it wouldn't. The only difference is that userspace has to be able to handle the empty frame. > So in MFC's case the V4L2_BUF_FLAG_LAST will be set on the one buffer after > the last one and the bytesused of that buffer would be set to 0. > > The problem of MFC is that it will signal that the last frame was decoded > after it was decoded. To particularize: > - a frame is decoded, an irq is sent by MFC - we have a new decoded picture > - next an irq is sent with an internal MFC flag that the buffer is empty > (last picture was already decoded) Doesn't MFC userspace currently stop on the empty frame? That empty frame will still be dequeued as before, the only difference is the added V4L2_BUF_FLAG_LAST on it, and that subsequent calls to DQBUF would return -EPIPE. regards Philipp -- 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
