Search code examples
androidiosavplayerhttp-live-streamingexoplayer

Live Streaming Performance with HLS - What does it mean to increase the live window for a stream?

I'm currently trying to improve live streaming performance/re-buffering issues by 'increasing the live window', to avoid being too close to the live edge of the stream; however I don't really understand what increasing the live window means, or where I would even do that (I'm guessing there's something in the manifest file?). I understand what HLS is and how it works (for the most part), but I'm apparently missing a valuable piece of information here.

I've been doing research and have come across the following live window suggestions:

If one wanted to prevent them, the only way to do this might be to manually set the live buffer's edge back in time a few seconds.

  • android - in the exoplayer hls docs -> Creating High Quality HLS Content (last heading / bottom of page):

Provide a long live window. One minute or more is great

Great! Yes, these suggestions make sense. Being too close to the live edge isn't necessarily the best idea .. especially for those with poor network connection; but now, how do we go about this?

I appreciate your help, comments ..etc!

Solution

  • Live streaming performance can mean different things depending on your goals:

    • If your goal is to minimise any chance of buffering or pauses in playback due to delays in donwloading the video then buffering more of the stream before starting playback will help with this.
    • If your goal is to reduce the latency, e.g. so that a Live sports event is a close to real time as possible, then you will typically want to start playback asap.

    Helpfully, you will often find customers and clients will want both if asked. Some of the latest low latency approaches, building on the CMAF protocol, help towards this but ultimately, buffering vs latency will generally always be a trade off.

    Focusing, on the first one then I think your understanding above and in your comment is correct - essentially providing a bigger set of segments in the manifest will allow the player choose to buffer more before starting playback.

    As an example, modifying the manifests from the link you note above, this manifest provides the player information to allow it request up to 3 segments:

    #EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:10.0,
fileSequence1.ts
#EXTINF:10.0,
fileSequence2.ts
#EXTINF:10.0,
fileSequence3.ts

    While this one provides info on 6 segments:

    #EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:4
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:10.0,
fileSequence1.ts
#EXTINF:10.0,
fileSequence2.ts
#EXTINF:10.0,
fileSequence3.ts
#EXTINF:10.0,
fileSequence4.ts
#EXTINF:10.0,
fileSequence5.ts
#EXTINF:10.0,
fileSequence6.ts

    Note the player could simply start playback earlier, after one or two segments for example, if it detects or knows somehow that it has a good quality connection for the stream.

    It's also worth noting that the term 'Live Window' could have multiple meanings in different contexts.

    Clearly a key interpretation, as above, is the amount of time that the server maintains the availability of a given segment to allow clients download it. As the live manifest is modified and the older segments drop out, how long they are kept or how many you keep, is the most obvious 'window'.

    It can also be useful to know how long the 'window' is that the server will respect requests for a given segment after it drops to of the manifest. This is obviously key for race conditions, but can also be important for 'CatchUp' or 'Start Over' type services depending on how they are implemented.