[FFmpeg-devel] [PATCH] Implement guessed_pts in avcodec_decode_video2.

[Måns Rullgård]

Nicolas George <nicolas.george at normalesup.org> writes:

> Le tridi 13 pluvi?se, an CCXIX, M?ns Rullg?rd a ?crit?:
>> The decoder has nothing to do with detecting or correcting bad
>> timestamps.  The only thing it should do is allow a value to be
>> tracked through the reordering.  If these values are good or bad is
>> for something else to determine and, if desired, attempt to correct.
>
> Agreed. But as far as I understand things, the correction we are talking
> about can only kick in after the decoder has done its job and reordered the
> frames. Which leads to the question: what kind of API do we want: do we want
> avcodec_decode_the_video_and_take_care_of_everything, or do we want
> avcodec_just_decode_the_video?
>
> And when asked that way, the answer seems quite obvious to me: we want both.

Why is something feeding bad timestamps to the decoder in the first place?

>> The problem with the current approach is that perfectly good
>> timestamps (e.g. from mkv files) are misdetected as wrong and "fixed",
>> resulting in the notorious non-monotone timestamps error, among other
>> problems.
>
> Do you have a pointer to sample for this case? I do not think that the
> guessing algorithm we are discussing right now can lead to non-monotone
> timestamps on valid files.

Stream copy on any mkv file with B-frames fails with this error.

>> Any automatic tampering with timestamps should be conservative, only
>> kicking in when things are obviously wrong, such as two frames with
>> the same PTS stored in the container.  We have to assume files are
>> correct by default, and enable aggressive fixups only after being
>> explicitly requested.
>
> I think the algorithm we are discussing in this thread is conservative: it
> only selects one among the actual PTS and DTS: if only one is present, of if
> both are present and valid (and therefore equals), it just outputs them.

There are so many places where timestamps are manipulated ad-hoc that
I've lost track of exactly which part we're talking about here.

I do however get the distinct feeling that this patch is nothing but a
workaround for errors introduced by PTS guessing code in lavf.  In
other words, lavf invents bad timestamps, and this code discards them
again.  That is not how we want it to be.  We should make lavf stop
spitting out made-up numbers at all, and the problem will go away.

-- 
M?ns Rullg?rd
mans at mansr.com