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

[Andy Sheen]

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:
>>>>>> 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?
> 

Although not directly relevant to PTS gaps in ogg files, I have entered 
a bug in roundup (issue 807) concerning non monotone timestamps.
In my case, I am forced to demux, re-encode and then remux (ironically, 
all done via ffmpeg) when all I want to do is single command line to 
re-encode audio to the same file.

It appears there could be a wider implication of getting this fixed...