On Wed, Jan 23, 2019 at 2:27 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote: > > On Tue, Jan 22, 2019 at 11:47 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > > On 01/22/19 11:02, Tomasz Figa wrote: [snip] > > >>> + one ``CAPTURE`` buffer, the following cases are defined: > > >>> + > > >>> + * one ``OUTPUT`` buffer generates multiple ``CAPTURE`` buffers: the same > > >>> + ``OUTPUT`` timestamp will be copied to multiple ``CAPTURE`` buffers, > > >>> + > > >>> + * multiple ``OUTPUT`` buffers generate one ``CAPTURE`` buffer: timestamp of > > >>> + the ``OUTPUT`` buffer queued last will be copied, > > >>> + > > >>> + * the decoding order differs from the display order (i.e. the > > >>> + ``CAPTURE`` buffers are out-of-order compared to the ``OUTPUT`` buffers): > > >>> + ``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` timestamps > > >>> + and thus monotonicity of the timestamps cannot be guaranteed. > > > > I think this last point should be rewritten. The timestamp is just a value that > > is copied, there are no monotonicity requirements for m2m devices in general. > > > > Actually I just realized the last point might not even be achievable > for some of the decoders (s5p-mfc, mtk-vcodec), as they don't report > which frame originates from which bitstream buffer and the driver just > picks the most recently consumed OUTPUT buffer to copy the timestamp > from. (s5p-mfc actually "forgets" to set the timestamp in some cases > too...) > > I need to think a bit more about this. Actually I misread the code. Both s5p-mfc and mtk-vcodec seem to correctly match the buffers. Best regards, Tomasz
