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

On Fri, Feb 20, 2015 at 10:25 AM, Daniel James <
daniel.james at sourcefabric.org> wrote:
> Hi Thomas,
> > Let's start with HLS:
> > - It's not a standard. It's current status is that it's an
*expired*
> > draft[1].
>
> Does that suggest a lack of interest in an open standard?

I'm actually not sure how it is expired... The most recent HLS draft was
published in October and is valid through April:

https://tools.ietf.org/html/draft-pantos-http-live-streaming-14

As someone who has been implementing both a server and client around HLS,
it's actually been a little more active of a document than I would wish.

Thomas has some valid questions around implementability for Icecast, but I
wanted to take a second to provide a little context for why I as a
broadcaster like HLS.

I work for Southern California Public Radio, the largest NPR affiliate in
the Los Angeles market. We're a small-to-medium online streamer, peaking at
roughly 3k concurrent on an average day, but we think that's going to grow
rapidly over the next few years and that Internet listening on mobile
devices is the future.

For us, the short-lived connections in an HLS session seem to map more
cleanly onto how people use their devices. We want them to start listening
at home (WIFI) and keep listening as they hop in the car (maybe bouncing
from 3G to LTE) and then arrive at the office (another WIFI network).
That's 3-4 IP addresses over the course of a listening session. Because we
don't have to keep one connection alive, HLS handles that on today's
network routing realities (at least in theory... The implementation doesn't
create a 100% perfect experience today).

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

On 02/20/2015 04:05 PM, Eric Richardson wrote:
> On Fri, Feb 20, 2015 at 10:25 AM, Daniel James
> <daniel.james at sourcefabric.org <mailto:daniel.james at
sourcefabric.org>>
> wrote:
>
>     Hi Thomas,
>     > Let's start with HLS:
>     > - It's not a standard. It's current status is that
it's an *expired*
>     > draft[1].
>
>     Does that suggest a lack of interest in an open standard? 
>
>
> I'm actually not sure how it is expired... The most recent HLS draft
> was published in October and is valid through April:
>
> https://tools.ietf.org/html/draft-pantos-http-live-streaming-14
Thanks, I just followed the links that got me the previous -13 document
and that had expired.

>
> As someone who has been implementing both a server and client around
> HLS, it's actually been a little more active of a document than I
> would wish.
>
> Thomas has some valid questions around implementability for Icecast,
> but I wanted to take a second to provide a little context for why I as
> a broadcaster like HLS.
>
> I work for Southern California Public Radio, the largest NPR affiliate
> in the Los Angeles market. We're a small-to-medium online streamer,
> peaking at roughly 3k concurrent on an average day, but we think
> that's going to grow rapidly over the next few years and that Internet
> listening on mobile devices is the future. 
>
> For us, the short-lived connections in an HLS session seem to map more
> cleanly onto how people use their devices. We want them to start
> listening at home (WIFI) and keep listening as they hop in the car
> (maybe bouncing from 3G to LTE) and then arrive at the office (another
> WIFI network). That's 3-4 IP addresses over the course of a listening
> session. Because we don't have to keep one connection alive, HLS
> handles that on today's network routing realities (at least in
> theory... The implementation doesn't create a 100% perfect experience
> today).
That indeed is an aspect that I didn't think of. Thanks for pointing
that out!
I'm wondering though, what sort of caching does that need client side so
that it won't run dry? With the anecdotal network handover latencies
(including elevator black out) that I have here this would need to be
almost on the order of minutes.

Cheers

Thomas

On Fri, Feb 20, 2015 at 11:12 AM, "Thomas B. R?cker" <thomas at
ruecker.fi>
wrote:
>
> That indeed is an aspect that I didn't think of. Thanks for pointing
> that out!
> I'm wondering though, what sort of caching does that need client side
so
> that it won't run dry? With the anecdotal network handover latencies
> (including elevator black out) that I have here this would need to be
> almost on the order of minutes.
>
And there's where the rubber meets the road... HLS spec says that a client
should start playing at least three segments from the end of the playlist
file, and Apple recommends segments of at least 10 seconds, so by default
you'll buffer around 30 seconds.

But that's not proving to be enough, and we're currently deep in the
weeds
on figuring out exactly why[0].

I tend to think the sweet spot for buffer in most cases is probably around
a minute.

ER

[0] We're making a big play against another aspect of HLS, which is that
playlists can include an arbitrary moving window of segments with
associated datetime information. We're using that to provide a four-hour
window of "rewind" to allow listeners to jump back to the start of the
show
regardless of when they connect, etc. We've been getting some user feedback
about poor stream reliability, though, and I suspect that the lengthy
playlist we're sending may be as much or more of a contributor than our
buffered seconds is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast-dev/attachments/20150220/7945af53/attachment.htm

On 2015-02-20 8:05 AM, Eric Richardson wrote:
> Because we don't have to keep one connection alive, HLS handles that on
> today's network routing realities
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?

 -r

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