[vlc-devel] httplive.c: Improvement for Prefetch function?

[David Glaude]

2012/4/30 Łukasz Korbel <korbel85 at gmail.com>:
> 2012/4/30 Frederic YHUEL <fyhuel at viotech.net>:
>> On Sun, Apr 29, 2012 at 2:55 PM, Jean-Paul Saman <jpsaman at videolan.org> wrote:
>>> On Sat, Apr 28, 2012 at 8:17 AM, Frederic YHUEL <fyhuel at viotech.net> wrote:
> "The client SHOULD attempt to load media segments in advance of when
>   they will be required for uninterrupted playback to compensate for
>   temporary variations in latency and throughput"
> Can you tell me Paul where you found information to download 3
> segments before starting playback?
> Maybe I've missed something but if it isn't necessary then Prefetch
> function won't be needed at all. I've tested HLS playback without
> calling Prefetch and it works well for me. I guess its woth checking
> because it will speed up playbacks start by the time of two downloads.

I think it might even be recommended to start with a very low bitrate
alternative, then based on the speed it took upgrade to better quality
(bandwidth). It is a kind of "fast start". The same behaviour is
possible for seeking.
Of course it might be anoying to have quality change/variation, so
there is a tradeoff. I guess it should be an option for the end-user
that would modify the heuristic. Some user might prefer quality over
fast start (or reverse way).

> I'm also interested in making bandwidth adaptation better, although
> massive changes in module might a little bit too much for me.
> Currently I'm think about ways to speed up playbacks start in HLS. Do
> you have any ideas other then related to Prefetch function?

One of the advantage of HLS (and other HTTP download of fragment
oriented protocol) is to never download too much (things that the user
might never watch. In that sens it save money compare to progressive
download (without bandwidth throtling). So from my point of view,
Prefetch should be keept to the minimum (it involve risk or a buffer
underflow).

David Glaude