[FFmpeg-devel] Supporting container formats with PTS gaps (Ogg)
Mon Feb 2 15:58:15 CET 2009
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
>> Timestamp interpolation should only be done when required, not by
> 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
mans at mansr.com
More information about the ffmpeg-devel