[vlc-devel] [vlc-commits] commit: stream_filter/httplive.c: HTTP Live Streaming (Jean-Paul Saman )
david.glaude at gmail.com
Thu Oct 14 18:21:42 CEST 2010
Le 14 octobre 2010 08:50, Rémi Denis-Courmont <remi at remlab.net> a écrit :
> My point is that you might not see the download speed improving. Of course
> you can see the download speed degrading.
As far as I remember, the "Apple HTTP streaming" RFC does not describe how
to write a smart client... a most it give hint.
But this whole thread seems to be about the benefit or not of one streaming
mecanisme against another... not really about VLC.
It is up to VLC implementation to decide that the bandwidth above should be
attempted if the last chunck download went so fast that there is a potential
for downloading the next one in due time. It is a tradeoff between the
enhanced quality one can gain and the risk of having a buffer underflow and
It might be interesting to have algorithm where the user can decide on where
he put the cursor... (how much risk he is willing to take for a better
The same thing for the start of the video, some user may want a fast start
with the low bitrate, while other prefer to wait a bit for a preroll and see
the video from the start at a good quality.
My point is that there should be an option to let the end-user specified:
* The maximum speed that VLC should try (because I know my internet link
speed or because VLC is not the only internet application I use or because I
pay my bandwidth usage)
* A fixed nearest bandwidth to select (because I want to download or
transcode the content and I want a fixed quality... even if it go slower
than real time)
Right here and right now, we have a first implementation in VLC and it is
already an archievement.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel