Low latency catch up

[aescarcha]

Checking the buffer level and target live delay, if it's behind the playback rate will be increased by 5% by default, configurable from 0% to 20%

Fixes #2600

[davemevans]

This implies that only video content will ever be sped up?

Whilst some audio content will be particularly sensitive to playback rate, it should be up to the content provider to determine whether or not to apply speed up to a particular stream type (and the appropriate rate if any).

The usual example of low latency is hearing your neighbours celebrating a goal through the wall. This applies equally to sports audio services.

[aescarcha]

Good catch, I added that check in a first approach, I think it can be removed now

[davemevans]

Worth noting that, whilst this solves the request in #2600, if a device does not support playbackRate to anything other than 1.0 (ie actually playing faster), the player will remain in catch up state forever.

[aescarcha]

@bbcrddave how can we check if a device supports changing playbackRate ? Will it throw an exception? AFAIK it's compatible with every browser

[davemevans]

Sure, every browser will let you set and get playbackRate and most will play back at or around the rate that you specify. Some devices, unfortunately, will fail to play back at the rate set, and won't throw an exception.

There's not much you can do but the comment wasn't against merging this PR as is, it was simply to point out that changing the playback rate may need to be supplemented with some other catch up mode (eg seek) for some devices.

[aescarcha]

Changed the approach in 7c9cba3, now we won't check buffer, but getCurrentLiveLatency, this way the event fires less often and won't be affected by track changes.