[vlc] ff / rew

[j.zorko at att.net]

Hello, all ...

VLC streams VOBs well, but it's ff / rew support is a bit lacking.  Chief among this is that, while 
one VLC is streaming to another (unicast or multicast), if the "server" VLC seeks to a new position 
in the stream, sometimes it takes several seconds for the "client" VLC to react to this.  In addition, 
if the "server" VLC plays the stream faster or slower than normal, the "client" VLC just stops.  Both 
of these things are killers for the project we're working on, but there doesn't seem to be anything 
better than VLC (on Linux) for streaming VOBs, so I would like to help make VLC better in these 
areas.

Addressing fast-forward and rewind first, I see an issue with p_input->stream.control.i_rate being 
used to control the current play speed.  For a fast-forward or rewind implementation to be 
anything remotely intuitive, the video has to react to the fast-forward and rewind actions, even if 
that video is being streamed from another VLC instance (which our implementation would likely 
do).  Currently, the remote VLC just hangs if the source VLC plays the stream faster or slower.  
What should happen, I think, is one of two things: a.) only I-frames are streamed from the server 
VLC to the client, and the PTS / DTS of each I-frame is modified so that the client VLC decodes and 
displays it as soon as possible, or b.) the server VLC should seek progressively forward / backward 
in the file, in small (but possibly scaling with the length of time ff / rew is active) increments, then 
play a bit, then seek forward / backward more, play a bit, etc.  However, a seek on the server VLC 
often doesn't manifest itself on the client VLC for several seconds (sometimes it's quick, 
sometimes not), so this would have to be addressed.

VLC developers -- have you thought about fast-forward / rewind functionality, especially with 
regards to a client VLC getting a stream from a server VLC when this happens?  I would love some 
pointers as to which option you're thinking, and an idea of how the code would be changed to 
facilitate it.  This is normally accomplished with RTSP and the RTSP PLAY scale header, but neither 
VLC nor VLS support this.

Anyone have any thoughts on this?

Regards,

John

--
Falling You - exploring the beauty 
of voice and sound
http://www.mp3.com/fallingyou








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