[Ffmpeg-devel] Possible bug in reading PTS/DTS
Mon Apr 23 16:48:43 CEST 2007
M?ns Rullg?rd wrote:
> 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
Then output_example and ffmpeg are broken, because they both produce
MPEG1 with PTS!=DTS even when no B-frames.
Michael, however, seems to disagree.
> and the B-frames will have
> DTS = PTS, like this:
This is one of the clearest explanations I have seen so far. Top is PTS,
right? Bottom is DTS, line 2 is sequence in stream order (input to
codec), line 3 is sequence in presentation order (output from codec).
Correct? One sees clearly the codec delay, and why a 'fake' DTS is
needed on the first packet, and how things work whatever the GOP
structure (if one decodes the whole GOP sequentially, that is; grokking
the minimal sequence of decoding to reach a particular frame is still
completely nonobvious to me)
But I have just tried to adapt that graph to encoding, and no cigar
there. Could you...?
>> 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?
T +32  2 790 29 41
F +32  2 790 29 02
E mailto:mbardiaux at mediaxim.be
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
More information about the ffmpeg-devel