Manifest request frequency on live streams

[karyn]

In live streams, subsequent manifest requests may return the same result. I.e., there is no new segment.

Sometimes this is due variable fragment duration (E.g., even if the average is 10 seconds, we see some 8 second fragments and some 12 second fragments). Other times, it is due to minor slowness ingesting the live stream.

In both these cases, a minor delay on ingest results an extra fragment duration worth buffer depletion. If there are no new segments in the manifest, we may be able to avoid a rebuffer by requesting the manifest again (shortly after the initial request).

As a quick fix we changed the following line:
https://github.com/mangui/flashls/blob/dev/src/org/mangui/hls/loader/LevelLoader.as#L247
to
var _reloadInterval : Number = _levels[level].averageduration /2 ;

While probably not the most efficient solution, this fix reduced the percentage of rebuffered sessions by about 10% (taken from ~10,000 2 hour playbacks over a month).

[mangui]

reload interval was already halved in case playhead is near the edge of the playlist.

https://github.com/mangui/flashls/blob/dev/src/org/mangui/hls/loader/LevelLoader.as#L248-L250

in your case it starts to be pretty aggressive. maybe the condition should be reviewed (divide by 4 instead of 2, or divide by 2 if less than 2 reload interval from edge)

[karyn]

I think the "divide by 2 if less than 2 reload interval from the edge" will work.

Looking through my logs, the following seems common:
I have 3 segments in my manifest, each is ~10 seconds long. Suppose it takes ~6 seconds to download each segment. We play for a bit so that the buffer size is at 25 seconds:

• At time 0: buffer size is 25 seconds
• At time 10: buffer size is 15 seconds; we don't see any new segments in the manifest
• At time 20: buffer size is 5 seconds; we see two new segments in the manifest; request the first one
• At time 25: buffer size is 0 seconds; still downloading last 1/6th of the segment.