Re: [xine-devel] removing some metronom calls from the demuxers.

[Miguel F. <mi...@ce...>]

Hi James,

On Fri, 2002-10-18 at 03:28, James Courtier-Dutton wrote:
> Currently, the metronom detects a discontinuity in 
> "metronom_handle_video_discontinuity()". It then sets the 
> in_discontinuity flag, and forces all the metronom_got_video_frame(), 
> and metronom_got_audio_frame() to ignore PTS values for 30 video frames. 
> The metronom then just uses predictions during this period to set VPTS 
> values.

You are right.

I would just add that discontinuities are really detected at demux
level, they are just "handled" in metronom. The call to that function
means that all buffers so far were using old PTS values, and everything
past this point (waiting in fifo) will have a new "reference"
(vpts_offset).

The choice of 30 video frames is somewhat arbitrary and probably too
conservative. The main use of that is to workaround the problem you
reported of frame reordering. after api settle down we should try
Thibaut's and Michael's metronom optimizations.


> Now, it is impossible to predict VPTS values for SPU (DVD subtitle 
> packs) because SPUs are not evenly spaced, so I had to add a guessing 
> mechanism to decide whether to use the new offset value, or the previous 
> offset value to convert PTS -> VPTS.


The point is that we don't have to predict VPTS values for SPU. We know
exactly what value they are, it's just a matter of using the right
vpts_offset. If we are outside the discontinuity there's no doubt, but
if in_discontinuity is set we are _past_ the discontinuity point and the
new reference is already known: next_vpts_offset.


> Conceptually, "discontinuity" is an instantaneous event, and should not 
> be carried over 30 frames.

100% agreed.

> The reason for carrying it over 30 frames is 
> so we can sort of ignore the problem until we are fairly sure there are 
> no fifo entries from the time before the discontinuity.

No, that's wrong. there is _never_ any single fifo entry from the time
before the discontinuity. This is the very first definition of a FIFO!
first in, first out. data in, data out. discontinuity in, discontinuity
out... :)

What might get wrong is the pts being held by the decoder for some
reason (like frame reordering).

> Ok, that is my understanding of how xine-lib currently works, please 
> help me correct my vision.


well, and you help me to understand if there is any reason why the
obvious solution to the spu pts problem can't be used! ;)

regards,

Miguel