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

[Måns Rullgård]

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.  The
only requirement is that DTS > PCR/SCR.  IIRC something chokes if
DTS(stream1) < DTS(stream2).

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