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

[Baptiste Coudurier]

Hi,

Michael Niedermayer wrote:
> 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 ...)

AVFMT_NO_TS_GEN

if (s->flags & AVFMT_NO_TS_GEN)
    return 0;

in compute_pkt_fields. You might want to move the pkt flags code up and
pkt->duration up too also.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org