[FFmpeg-devel] Supporting container formats with PTS gaps (Ogg)

[Michael Niedermayer]

On Mon, Feb 02, 2009 at 04:24:48PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Feb 02, 2009 at 03:02:03PM +0000, Robert Swain wrote:
> >> 2009/2/2 M?ns Rullg?rd <mans at mansr.com>:
> >> > Robert Swain <robert.swain at gmail.com> writes:
> >> >> 2009/2/2 M?ns Rullg?rd <mans at mansr.com>:
> >> >>> Robert Swain <robert.swain at gmail.com> writes:
> >> >>>> 2009/2/2 M?ns Rullg?rd <mans at mansr.com>:
> >> >>>>> Peter Ross <pross at xvid.org> writes:
> >> >>>>>> This is adequate for simple playback, but when copying an Ogg file
> >> >>>>>> to another format, things break. For example, the ffmpeg program
> >> >>>>>> tries to calculate the DTS value from the previous PTS (see
> >> >>>>>> output_packet() ffmpeg.c ~1396). There is some other functional
> >> >>>>>> cruft in libavformat that attempts to calculate PTS from DTS
> >> >>>>>> (compute_pkt_fields2() in libavformat/utils.c ~2548).
> >> >>>>>
> >> >>>>> I consider this mess a flaw in the FFmpeg design.  Some formats
> >> >>>>> provide only occasional timestamps, and there is no generic way to
> >> >>>>> find the missing timestamps without (more or less) decoding the
> >> >>>>> elementary streams.  The current approach seems to be vigorous denial
> >> >>>>> of this, and a half-baked attempt at inventing the missing
> >> >>>>> timestamps.  More often than not this fails, resulting in the infamous
> >> >>>>> "non-monotone timestamps" error when stream-copying.
> >> >>>>
> >> >>>> This issue seems to come up quite a lot. What can be done to make the
> >> >>>> system more robust? Is decoding the elementary streams the only way?
> >> >>>> If so, shouldn't this 'brute force' approach at the very least be an
> >> >>>> option?
> >> >>>
> >> >>> Timestamp interpolation should only be done when required, not by
> >> >>> default.
> >> >>
> >> >> That's why I said at the very least be an option, rather than just
> >> >> spitting the "non-monotone timestamps" error. In this situation would
> >> >> it not be considered required?
> >> >
> >> > That depends on the target container.  E.g. MPEG doesn't need all the
> >> > timestamps.
> >> 
> >> If MPEG doesn't need all the time stamps then would it spit that error
> >> in this situation?
> >
> > mpeg does not store all timestamps, that is true, but the mpeg muxer,
> > at least ours needs all timestamps (or at least more than the minimum
> > guranteed from mpeg input). Kinda tricky to conform to the
> > buffer and interleaving requirements of mpeg without knowing the
> > timestamps at all.
> >
> > In the end this can be summarized like
> > * mans dislikes timestamp interpolation
> > * mpeg requires timestamp interpolation
> > * mpeg is not badly designed according to mans
> > * thus it must be someone elses fault, like mine or ffmpegs
> >
> > if someone has a constructive idea iam all ears of course but
> > just not doing the timestamp interpolation isnt going to work out, even
> > if a target container of mpeg-ps/ts could handle it, practically no other
> > container could, so it would not really fix the non monotone issue.
> > (also its a 1 line change to disable the timestamp interpolation if
> >  someone wants it ...)
> >
> > Besides, the non monotone timestamp issue is a bug in one of 4 places
> > 0 ffmpeg.c simply being buggy and creating wrong timestamps where there
> >   where none
> > 1 ffmpeg.c, because ffmpeg should replace invalid timestamps by valid and
> >   guessed ones when remuxing or transcoding
> > 2 The input streams simply containing invalid timestamps (yes, there are
> >   mpeg files with wrong timestamps) the issue here is feeding the
> >   interpolation code with wrong values produces wrong interpolation values
> >   maybe we could handle this better ...
> > 3 Bugs in the interpolation code itself
> >
> > for h.264 its primarely 3. for others its primarely the others
> 
> 4.  MPEG files do not require strict ordering between streams.  

i know that


> The
> only requirement is that DTS > PCR/SCR.

That is an oversimplification


>  IIRC something chokes if
> DTS(stream1) < DTS(stream2).

:/
my guess would be toward something related to first_dts/utils.c & ffmpeg.c

anyway how can i reproduce it?

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090202/ba13ea29/attachment.pgp>