<div dir="ltr">On Fri, Feb 20, 2015 at 11:12 AM, "Thomas B. Rücker" <span dir="ltr"><<a href="mailto:thomas@ruecker.fi" target="_blank">thomas@ruecker.fi</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>That indeed is an aspect that I didn't think of. Thanks for pointing<br>
that out!<br>
I'm wondering though, what sort of caching does that need client side so<br>
that it won't run dry? With the anecdotal network handover latencies<br>
(including elevator black out) that I have here this would need to be<br>
almost on the order of minutes.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>But that's not proving to be enough, and we're currently deep in the weeds on figuring out exactly why[0].</div><div><br></div><div>I tend to think the sweet spot for buffer in most cases is probably around a minute.</div><div><br></div><div>ER</div><div><br></div><div>[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.</div></div></div></div>