Icecast dev - Feb 2015 - why HLS/DASH are problematic in an Icecast context

On Fri, Feb 20, 2015 at 2:51 PM, Ralph Giles <giles at thaumas.net> wrote:

> So the issue here is that with an icecast stream there's no way to
> restart playback on a new tcp session without missing some of the
> content? You'd rather have smooth playback through reconnects even if
it
> adds latence?

It doesn't add latency, though, because the short connections are happening
in the background and are hopefully buffering up content that will be
safely loaded before it becomes time for you to play it.  Because the
content already exists on the server, you're also able to download it in
bursts at connection speed rather than in realtime.

So yes, you're certainly getting additional connection setup overhead, but
in theory it should all happen seamlessly behind the scenes.

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

Hi Eric,
> It doesn't add latency, though, because the short connections are
> happening in the background and are hopefully buffering up content that
> will be safely loaded before it becomes time for you to play it. 
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?
> Because the content already exists on the server, you're also able to
> download it in bursts at connection speed rather than in realtime.
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?

Cheers!

Daniel

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