On Wed, Jan 23, 2019 at 2:27 PM Tomasz Figa <tf...@chromium.org> wrote: > > On Tue, Jan 22, 2019 at 11:47 PM Hans Verkuil <hverk...@xs4all.nl> 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
