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

[David Glaude]

Le 13 octobre 2010 11:53, Rémi Denis-Courmont <remi at remlab.net> a écrit :

> On Wed, 13 Oct 2010 09:48:16 +0200, Jean-Paul Saman <jpsaman at gmail.com>
> wrote:
> >> - What is the protocol to detect bw_up and bw_down? Was that not too
> >> difficult with VLC arch?
> >
> > It is fairly simple, measure the download speed per segment and base a
> > decision on that.
> > Since the stream_filter initiates the download itself it can also
> > measure how long that takes and
> > calculate the average download speed in terms of bandwidth of the stream.
>
> This assumes that the HTTP server will agree to serve the file at a much
> larger TCP bandwidth than playback bandwidth of the media.
>
I think we are assuming that the HTTP server is tuned or design to serve
Apple HTTP streaming and/or that a CDN is in use for that.
Why would someone try to do Apple HTTP streaming and limit the bandwidth per
connection below the highest bitrate offered?


> Thus there is a risk that even the slightest transient congestion
> might make VLC needless scale down the video.
>
With Apple HTTP streaming you are suppose to have a few chunk of advance
(when the user is not seeking in every direction) and at least for LIVE
streaming that is what you do.
So you can detect without problem that the download speed is degrading and
adapt.

I don't think there is a magic solution here. Measuring bandwidth is a
> unsolvable problem without specific knowledge of the IP network. In other
> words, the only solution is to let the user decide.
>

I fully agree that the use should have a choice to take a fixed bandwidth
(even if this introduce delay between chuncks).
See my other comment on that topic.

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