Am Mittwoch, den 22.05.2013, 12:36 +0200 schrieb Hans Verkuil: > 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@vger.kernel.org/msg60916.html
Thank you for the pointer, this is exactly > How does the coda driver handle eos signalling? It does not, yet. The patches I'm currently preparing are still just calling v4l2_event_queue_fh before v4l2_m2m_job_finish from the interrupt handler after the device run signals that there is no more data, but I think this needs to be done with the DQBUF instead. I like the idea of an EOS buffer flag for the capture side. regards Philipp -- 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
