Re: [xine-devel] win32 port ... help please

[<bar...@t-...>]

Hi Matthew,

On 5 Jan 2002, M Grooms wrote:

>      I was hoping to get some help with a question I have. I started
> porting xine to win32 and am now stuck in the mud. I think I have all
> the input/demux/decode plugins compiling and working but I am having
> some problems with the timing. I am more than a little fuzzy on how
> xine handles pts and syncs threads during output.

the basic idea in xine is that metronom provides a master clock (like all
timing values in units of 1/90000s) and video_out / audio_out, running in
their own threads, sync their output to it. video_out does this by
queueing the frames it receives from the decoder which stores them until
it's time to display a certain frame. To do that, in video_out_loop it
looks at the master clock from metronom quite frequently and compares it's
value to the time stamps on the frames in it's queue.

(ok, this was a very very simply description, don't hesitate to ask if you
have more specific questions about it).

BTW: have you seen that there is a schematic of the xine engine in

xine-lib/doc/hackersguide/architecture.eps

[...]

ok, now a few comments about the log you got:

> video_out: got image 9338840. vpts for picture is 33600 (pts was 81360)

ok, here the video_decoder has delivered a frame to video_out and
video_out has gotten a timestamp of 33600 for it (roughly 1/3 sec after
start)

> video_out: delivery diff : -244050

now, this is bad. video_out asked metronom about the master clock, and
metronom returned master_clock==277650. Therefore, the frame video_out
has received is 244050/90000 sec too late.

> video_out: frame rejected, 140 frames to skip

consequently, video_out doesn't add this frame to it's queue (it's too
late already, so it will never be displayed) and tells the decoder to
hurry up (skip 140 frames, if possible).


[...]

from what I see in the logs to come, the master clock seems to run
extremely fast (or your computer is extremely slow ;)), so the
video_decoder never catches up (look at the increasing number of frames to
skip). So, I'd suspect there's a problem with the master clock, perhaps
you should check the unixscr_* functions in metronom.c - perhaps you're
just returning master clock values in u/msec instead of 1/90000 or
something like that.

Keep up the good work,

   Guenter

--
time is a funny concept