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

[Robert Swain]

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?

Rob