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

[Michael Niedermayer]

On Tue, Feb 01, 2011 at 08:52:43PM +0000, M?ns Rullg?rd wrote:
> 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?

because someone made a file with a broken muxer
and its also possible that a file becomes damaged


> 
> >> 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.

yes, exactly because muxing mpeg is so simple that noone could fail to write
a fully compliant muxer.

.[..]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110201/bd096ecc/attachment.pgp>