[vlc-devel] VLC 0.6.0, MPEG2 video pause / seek questions ...

[j.zorko at att.net]

Hello, all ...

I see the following with VLC 0.6.0 and i'm looking at the code to figure out why it does what it 
does.  The configuration is a VLC 0.6.0 instance acting as a server, serving a VOB over udp/ts, 
and another VLC 0.6.0 instance acting as the client, receiving the stream and playing it.

1. Using any interface (gtk, rc, our own sockets-based interface, whatever), if you seek the 
server VLC to another point in the stream, the client VLC gets confused a little (jumbled video 
for several frames) before recovering and playing the stream from the new point.

2. Using any interface (gtk, rc, our own sockets thingy, etc.), if you pause the server VLC before 
doing the seek (which sets input_thread_t.stream.stream_wait and therefore unpauses the 
stream), the client VLC plays beautifully i.e. no jumbled-up video.

So, i'm trying to figure out what pause really does from the perspective of the server that would 
make the client act so much better.  By the way, i'm also trying to find out how to minimize the 
latency of the pause mechanism when playing back DVD-quality video (it takes a few seconds to 
pause and unpause, this being on a 2.4GHz P4 running RH9).

If anyone is intimate with these areas of the code, could you illuminate me as to how they 
function?  What is the true purposes of input_thread_t.stream.stream_wait?  How does a pause-
and-seek operation differ from a just-seek operation in terms of input_ClockManageControl() 
and its' ilk?  How would one reduce pause / unpause latency?  Any help is greatly appreciated!

Regards,

John

--
Falling You - exploring the beauty 
of voice and sound
http://www.mp3.com/fallingyou
-- 
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>