Re: [xine-devel] [PATCH] Fix PTS tagging: large (negative) PTS values are a result of turning it off to early

[Reinhard N. <rn...@gm...>]

Hi,

James Courtier-Dutton schrieb:
> Reinhard Nissl wrote:
>> Hi,
>>
>> James Courtier-Dutton schrieb:
>>
>>> What exactly is the problem you are solving?
>>> There was a design decision to ensure that this sort of "fix" was not
>>> needed.
>>>
>>> The demuxer should do any PTS discontinuity correction. If the PTS
>> Yes, the demuxer shall discard all stored pts values at
>> discontinuity. But there is no way to tell ffmpeg to discard the
>> pts values of frames it has internally queued for picture
>> reordering. Therefore, when avcodec_decode_frame() returns a
>> frame, it may still provide an pts value prior to the discontinuity.
>>
> Hold on, why is the demuxer storing pts values? Which demuxer is this?

I'm sorry James. I've made a typo. For the above paragraph read
decoder, not demuxer.

> What codecs are involved. The PTS value is attached to a particular
> frame and the PTS value should stay attached to that frame even when
> they are re-ordered. The demuxer is supposed to correct the PTS values
> so that the decoder does not see any discontinuity. This scheme has
> worked fine for years, why are you changing it?

I do not see such behavior in the code. When the demuxer detects
a discontinuity, it informs the core which then informs the
decoder. The decoder discards any internally stored pts values at
that time (see mpeg2_discontinuity). Any currently stored frames
are drawn using 0 as pts value then until new buffers arrive with
new PTS values after the discontinuity, get passed through the
decoder and appear at draw().

Discarding pts values is not that easy when using ffmpeg as there
is no api to reset the internally stored pts values. ffmpeg's
h264 decoder may store 16 or even more frames for picture reordering.

PTS tagging works very well. The only mistake I made was that I
disabled untagging to early so that a tagged PTS slipped through
to draw() and caused a clock error. This could happen for the
following picture sequence in decoding order (negative numbers
indicate tagged pts values), when tagging was turned off at the
first B (+2) frame:

	I-1 P-4 B+2 B+3

This sequence leaves the decoder in display order like that:

	I-1 B+2 B+3 P-4

I had disabled untagging when seeing B+2, but then P-4 slipped
though and caused the clock error.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rn...@gm...