[Icecast-dev] why HLS/DASH are problematic in an Icecast context

[Eric Richardson]

On Mon, Feb 23, 2015 at 6:35 AM, Daniel James <daniel.james at sourcefabric.org
> wrote:

>
> So if I've got this right, after I join a HLS live stream to listen or
> watch, do I only start buffering that low bitrate content after the
> player detects that there is a bandwidth problem?
>

Correct, the client has the ability to switch variants (up or down) based
on its judgement of the available bandwidth. The master playlist includes
average bandwidth information for each variant.


> Ah, so after the decision is made to switch, the low bitrate buffer
> fills up quicker than the high bitrate buffer is emptying, is that correct?


An HLS stream isn't a stream. It's a series of segment files presented in a
playlist (not the master playlist referenced above... in this case a
per-variant playlist). For a live broadcast, that playlist is a moving
window... New segments get added to the end, old segments fall off the
back. Each segment is an individual download that the client makes, which
it then plays in sequence to get the media stream. If my client is playing
segment A, it needs to be able working on downloading segments B and C to
make sure it has content ready to play when its turn comes up. It's doing
all of that regardless of whether you switch variants or are just listening
to a single variant.

In a situation with multiple variants, you're just making the promise that
the same segment index in any variant will have the same content, and
therefore that the client can jump to a new variant if it wants to.

Variants are really just sort of icing on the cake from our perspective.
The fundamental win for mobile is using short-lived connections that can
get set up, quickly download their segment(s), and then can be torn down.

ER
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/icecast-dev/attachments/20150223/b628f719/attachment.htm