On Wed 22 May 2013 12:17:36 Philipp Zabel wrote: > On mem2mem decoders with a hardware bitstream ringbuffer, to drain the > buffer at the end of the stream, remaining frames might need to be decoded > without additional input buffers being provided, and after calling streamoff > on the v4l2 output queue. This also allows a driver to copy input buffers > into their bitstream ringbuffer and immediately mark them as done to be > dequeued. > > The motivation for this patch is hardware assisted h.264 reordering support > in the coda driver. For high profile streams, the coda can hold back > out-of-order frames, causing a few mem2mem device runs in the beginning, that > don't produce any decompressed buffer at the v4l2 capture side. At the same > time, the last few frames can be decoded from the bitstream with mem2mem device > runs that don't need a new input buffer at the v4l2 output side. A streamoff > on the v4l2 output side can be used to put the decoder into the ringbuffer > draining end-of-stream mode. This is just a pointer to a related issue: how to signal to the application that the end-of-stream has been reached: http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg60916.html How does the coda driver handle eos signalling? Regards, Hans -- 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
