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

[Eric Richardson]

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