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

Michel Bardiaux mbardiaux
Mon Apr 23 12:20:17 CEST 2007


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; 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.

> 
> Anyway, even if DTS == PTS the problem will be only delayed (it will 
> appear as soon as timestamp will cross the 33bit boundary).

Indeed. For me it will happen every day, because we do 24/7 TV captures 
from TV, and we want 'real' timestamps, ie the UTC of the frame 
converted (when MPEG1) to the 90KHz scale.

> 
>> That said, given a file with timestamps crossing the 33-bits boundary, I 
>> dont think the solution should be to reproduce internally the deficiency 
>> of the container.
> Ok, I see your point. This is why I asked :)
> Just to see if I got you right: are you saying that user applications 
> should not care about st->pts_wrap_bits?

No, that the user application should not *have to* care about it. But I 
think that's what you meant.

> If this is the case, then the error is likely in libavformat/utils.c
> 
> Let's see what Michael says...

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/




More information about the ffmpeg-devel mailing list