RE: [xine-devel] Use of the SCR which is contained in every mpeg2 stream.

[James Courtier-D. <Ja...@su...>]

When skipping about the navdvd menus, there are lots of clock
discontinuities.
As the SCR values are delivered much more often than the PTS values,
resyncing would work better.(Xine would sense a discontinuity much quicker).
At the moment, audio can get quite out of sync with video on the menus.
If you wait long enough, xine recovers, but quicker recovery would be nicer.
Also, seeking would work better, because audio and video would sync up
immediately after a seek change, instead of the small delay as it currently
does, until it sees a PTS value.

Cheers
James



> -----Original Message-----
> From: guenter [mailto:gu...@di...]On Behalf Of Guenter Bartsch
> Sent: 27 October 2001 16:39
> To: James Courtier-Dutton
> Cc: xine-dev
> Subject: Re: [xine-devel] Use of the SCR which is contained in every
> mpeg2 stream.
>
>
> Hi,
>
> On Sat, 27 Oct 2001, James Courtier-Dutton wrote:
>
> > It transpires that they use the SCR to correct the system clock, and
> > not the PTS values as we do. After doing some tests, I found that
> > every packet in the stream has a SCR set. Whereas, not all packets
> > have the PTS set. The mpeg2 standards also say one should use the SCR
> > values to synchronise the system clock. It would seem to me that using
> > the SCR would give us a much better sync system than using the PTS
> > values.
>
> Is there any problem with a/v sync in xine at the moment ?!
>
> As I read the mpeg drafts (I don't have the actual docs) SCR info should
> be used to sync the SCR while PTS are used to sync audio and video. As I
> don't see any problems with both in current versions of xine I don't see
> why we should change anything?
>
> Cheers,
>
>    Guenter
>
> --
> time is a funny concept
>