[vlc-devel] [vlc-commits] commit: stream_filter/httplive.c: HTTP Live Streaming (Jean-Paul Saman )

[David Glaude]

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
an interuption.

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
quality).

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.

David Glaude
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20101014/cd847ea8/attachment.html>