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

[Baptiste Coudurier]

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 low_delay is 0, pts AND dts shall differ for I and P frames, and
have a delay of 1 (if I understood well). Low delay to 0 does not imply
B frames.

quoting ISO 13818-1:

"For I- and P-pictures in non-low_delay sequences and in the case when
there is no decoding discontinuity between
access units (AUs) k and k', the presentation time tpn(k) shall be equal
to the decoding time tdn(k') of the next transmitted
I- or P-picture (refer to 2.7.5). If there is a decoding discontinuity,
or the stream ends, the difference between tpn(k) and
tdn(k) shall be the same as if the original stream had continued without
a discontinuity and without ending."

When low_delay is 1 you shall have PTS == DTS, then no dts are needed.

"For audio presentation units (PUs), video PUs in low_delay sequences,
and B-pictures, the presentation time tpn(k) shall
be equal to the decoding time tdn(k)."

> [...]
> 
>> 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?

Current code complains, I think it should.
Setting first dts, like michael suggested once, should be mandatory, to
correctly and simply deal with codecs delay.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312