[vlc-devel] Re: Do we have a MPEG expert in VLC?

[Gildas Bazin]

On Wednesday 10 December 2003 03:12, R. Bernstein wrote:
> Gildas Bazin writes:
>  > I just tried the above sample and the problem doesn't come from VLC but 
from 
>  > the file itself. There are invalid SCR (system clock reference) 
timestamps 
>  > happening randomly (?) in the stream. VLC relies on this information to 
>  > read the stream at the right pace (contrary to other players like xine/
>  > mplayer which don't use this info and synchronise everything on the 
audio 
>  > output clock).
> 
> I think this warrants a closer investigation. No, the problems are not
> random - they occur every place that a subtitle is to appear.
> 
> Given that the example of a couple years back *purports* to be a
> standard SVCD with subtitles and is probably the most advertised link
> for testing SVCD subtitles, it's hard to believe that if there where
> invalid SCR timetamps happening randomly, this is the first player for
> which this has been noticed. I've created a new SVCD with subtitles of
> my own, with the recent versions of software and get the same kinds of
> drop-outs before a subtitle (with vlc only).
> 
> And I've tried this exmple on a couple of hardware DVD/VCD/MP3 players
> - they don't suffer the dropout problem. One of the hardware players
> tried doesn't handle the SVCD subtitles, but plays the rest fine.
> 

As I already told you, VLC does rely on the SCR information to be correct. 
This is so because VLC was first designed as a network player and thus does 
all the synchronisation on the system clock embedded in the stream instead 
of synchronising on the audio output clock and reading the data faster/
slower according to this.

Now it is most probable that 99.99% of the other players out there (hardware 
or software) don't use this information (SCR) at all and thus won't be 
affected by such malformed streams.

Just in case you don't see why SCRs are important, let me explain you the 2 
main useages for them.

1 - When a player doesn't have any control over the pace at which it is 
reading the data (network input or real time encoding like a PVR) then it 
must make sure it won't read too quickly or it will underrun or too slowly 
or it will overrun. That means that it needs to synchronise on the clock 
used by the sender of the data... which is... the SCR. So bascially it uses 
the SCR to adjust the playing rate of the video/audio.
And without valid SCRs this can't be done.

2 - SCRs are also used by "dumb" streamers that don't need to know what type 
of data is contained inside an MPEG file to stream the file and send the 
chunks of data at the right time (indicated by the SCRs).

Now the only solution I see to this problem is to change the synchronisation 
method when we are dealing with streams on which we have control over the 
reading pace. There are plans to do this in VLC and development on this 
will likely start after 0.7.0 is released.

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>