[Ffmpeg-devel] Possible bug in reading PTS/DTS

[Måns Rullgård]

Michel Bardiaux wrote:
> Luca Abeni wrote:
>> Hi Michel,
>>
>> Michel Bardiaux wrote:
>> [...]
>>>> (If the problem really is in the user application, I can prepare and
>>>> send a patch fixing ffmpeg.c and ffserver.c)
>>>>
>>>> Or maybe the problem is in my (mis)understanding of this issue?
>>> I'm not sure the problem is in decoding. I find it rather strange that
>>> the first frame, which is a keyframe, does not have PTS=DTS.
>> I do not know... I see that for containers that store both PTS and DTS,
>> ffmpeg generally generates
>> DTS = PTS - frame period
>> for video (I am not using B frames, to simplify the testing). Is this
>> wrong? If yes, then I think there is something to fix in the encoding /
>> muxing side.
>
> I think so too. My reading of the spec is that in the absence of
> B-frames, the DTS are not even necessary;

The spec allows PTS != DTS only when B-frames are used.  When B-frames
are used, the non-B frames will have DTS < PTS and the B-frames will have
DTS = PTS, like this:

0123456
IPBBPBBP
 IBBPBBP
 0231564

> I'm afraid there is something
> very wrong in the MPEG muxer. But we have 3 different issues here: what
> an 'idal' MPEG should contain as timestamps; how the demuxer should
> react when encoutering the one unavoidable timestamp discontinity in an
> otherwise 'ideal' MPEG; and how to react to all other anomalies.

There is the additional question of what to do when the application passes
invalid timestamps to the muxer.  Complain and/or simply output them to the
file anyway?

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