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

[Michel Bardiaux]

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:
> 
> 0123456
> IPBBPBBP
>  IBBPBBP
>  0231564

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

Greetings,
-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/