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

[Michael Niedermayer]

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

iam interrested in non h264 timestamp interpolation bug reports ...
the only ive seen so far turned out being either broken files or
bugs of the 0th kind above.

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

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- 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/c9b36943/attachment.pgp>