[vlc-devel] Re: vlc and trickplay

[Dermot McGahon]

On Wed, 2005-09-14 at 20:09 +0200, Thomas Wentzel wrote:
> Hi all
> 
> This however seems to be a dead end. When streaming I get a warning 
> saying that the rate can't be altered. When using file:// instead of 
> udp:// as --sout the rate is changed, but there is no visible change to 
> the output file :(.

The file input can be rate controlled because VLC can read faster from
disk. The udp input can't because VLC can't read faster from the
network. If VLC is also the server it would be possible for the client
to send a message to the server asking it to only send I frames or to
send the data 12 times faster, but for a 4Mb/s stream the server would
either have to (i) be able to distinguish I frames on the fly and only
send those - as there are no B/P frames the rate of the stream will
increase to 8-10Mb/s probably, (ii) the content would have to have been
pre-parsed to store out I frames. Depending on the period of I frames in
the source material, there would be limits to how many different speeds
would be possible, (iii) Sending all the data 12 times faster would mean
sending 300 frames per second which is 48Mb/s.

There are probably other ways to do this, but they are the ones I know
about. So, sending 12 seconds worth of data over the network in 1 second
so that it can be displayed on the client at 12x speed is a huge waste
of network resources. Pre-parsing the content so that the server knows
how to send a stream that will render at 12x the original takes time
while installing the content and uses disk space. Options on playback
speed are limited using any of these approaches - if anybody has good
ideas about how to get fine-grained trickplay speeds for MPEG-2 please
let me know. Sending only I-frames on the fly is probably the best
option but there needs to be support for that in the server and there
isn't in the vlc server at the moment.


> Another thing: I came across a thread on this list from nov. 20 2004 
> titled, "Kasenna pause and trickplay patch".
> Allthough the patch is really for vlc as a client it is still kind of 
> interesting. Can anybody tell me why this patch didn't make it into vlc?
> Judging from the feed back to the intial mail it seemed as if the patch 
> was generally considered sound.

Because I didn't finish it. I've been working on other things. I keep
saying that I will get around to finishing it but so far it hasn't
happened.

The communication between the client and server is fairly
straightforward - it uses the Scale parameter in the RTSP PLAY command.

I have a VOD server that understands the Scale parameter and starts
streaming only I-frames. 

More work is needed on the vlc client to discard buffers at this point
and to deal with the discontinuities in the PTS/DTSs. The last time I
looked at this I managed to get smooth playback of fast forward/backward
12x video but at the expense of A/V sync.



Dermot.
--

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html