Christophe Massiot massiot at
Mon Jul 8 01:54:05 CEST 2002

At 16:47 +0100 30/06/2002, Andrew Flintham wrote :

>I don't like this approach; it feels like an inelegant hack, but I wasn't
>sure where my "subtitler" module should fit in vlc's architecture. It isn't
>really a video output module, nor is it really a decoder module, and I don't
>know where else to put it.

There is no better way to do it in the current structure. Input-II is 
very tied to the file structure and everything depends on that one 
stream. Nothing has been done to support reading several files at 
once, reconstituting the same stream.

>b) how should I get the "current time" of the DVD?
>I've been using a similar method as input_OffsetToTime does, working on the
>basis that "i_seconds = i_offset / 50 / p_input->stream.i_mux_rate", but this
>doesn't give me the right times. This can be easily demonstrated by playing a
>DVD and comparing elapsed time according to vlc with elapsed time according to
>a stopwatch, or comparing times at which chapters start against a physical DVD

Here we bump against two major issues. First VLC is written to relate 
to offset positions in bytes, not in time. We only have an 
approximative idea of the current time, and this information isn't 
used anywhere except for displaying. We calculate the current time 
with the mux_rate (number of bytes per second) * offset. This assumes 
the mux_rate is constant in all the file, which is generally wrong.

Second, I haven't been able to understand how to parse the mux_rate 
field of the MPEG Pack header. Maybe it's just me, but when I 
followed the MPEG spec I got erroneous values. I've had to multiply 
the value by 3/2, but this is a huge *hack* (see 
mpeg_system.c:input_ParsePS for info).

The solution for DVDs would be to use the timing information from the 
.ifo files. We have similar solutions for AVI and MPEG PS & TS files. 
I was planning on implementing this time-centric view in input-III 
(which I started earlier this year), but I haven't had time to work 
on it since then (which is why I have kept very silent on this 

I'm slightly overwhelmed by work, and I am becoming the bottleneck in 
two areas : audio output and input. As there are more and more 
volunteers to help VLC, I think I will have to write less code, 
delegate more, and focus on writing implementation documentation, and 
helping other coders.

Sam has agreed to take the lead on the audio output III which I 
haven't been able to start for weeks. I will now settle down on 
making propositions for the new input, and ask for volunteers to code 
Christophe Massiot.

This is the vlc-devel mailing-list, see
To unsubscribe, please read
If you are in trouble, please contact <postmaster at>

More information about the vlc-devel mailing list