Improve default live quality increase settings to work with live streams playing at ~3 segments live offset.

[cdongieux]

I'm reproducing an issue with all versions of ExoPlayer from 2.13.0 to 2.16.1 where ExoPlayer does not switch to a higher resolution on a Live DASH stream with AVC video tracks.

ExoPlayer starts playing the 896x504 track then never chooses 1280x720 or 1920x1080 even if there is enough network bandwidth.

Here is the list of available video tracks:

MediaCodecVideoRenderer [
     Group:0, adaptive_supported=YES [
       [X] Track:0, id=1209, mimeType=video/avc, bitrate=400000, codecs=avc1.64000d, drm=[widevine,cenc], res=384x216, fps=25.0, supported=YES
       [X] Track:1, id=1211, mimeType=video/avc, bitrate=800000, codecs=avc1.64001e, drm=[widevine,cenc], res=640x360, fps=25.0, supported=YES
       [X] Track:2, id=1212, mimeType=video/avc, bitrate=1600000, codecs=avc1.64001f, drm=[widevine,cenc], res=896x504, fps=25.0, supported=YES
       [X] Track:3, id=1213, mimeType=video/avc, bitrate=3000000, codecs=avc1.64001f, drm=[widevine,cenc], res=1280x720, fps=25.0, supported=YES
       [X] Track:4, id=1214, mimeType=video/avc, bitrate=4800000, codecs=avc1.640028, drm=[widevine,cenc], res=1920x1080, fps=25.0, supported=YES
     ]
]

As stream URL and DRM info are sensitive, I'll provide you by email a sample code hosted on a private GitHub repository to help you reproduce the issue. Please let me know if you need anything else.

[tonihei]

The short answer is that there is not enough buffered data to safely switch up to a higher quality.

The manifest is configured with a suggested presentation delay of 9.6 seconds, which is exactly 3 segments (as one segment duration is 3.2 seconds). So at the point where the player needs to select a newly available segment, it has at most 6.4 seconds (=2 segments) of media buffered. The actual value I observed with my network was between 5 and 6 seconds.

The AdaptiveTrackSelection default configuration has two relevant values for switching up:

• minDurationForQualityIncreaseMs (set to 10 seconds by default)
• bufferedFractionToLiveEdgeForQualityIncrease (set to 0.75 by default) => effective threshold: 0.75 * 9.6 seconds = 7.2 seconds, or slightly less, depending on actual timing

The buffered duration needs to be more than one of these two values for the player to switch up to a higher quality. This never happens (as it is between 5 and 6 seconds), and so the player stays at the lower quality although the bandwidth measurements support switching up. If you change the setting of either value it'll work (for example bufferedFractionToLiveEdgeForQualityIncrease to 0.5 or minDurationForQualityIncreaseMs to 5 seconds).

---

The issue has come up multiple times now for live streams that have a reasonable configuration of playing about 3 segments away from the live edge (e.g. #9643). A live offset of 3 segments is also recommended by default for HLS. So we should ensure our default configuration allows such streams to increase the quality under good conditions.

There are two options to implement this:

• We could change the default of bufferedFractionToLiveEdgeForQualityIncrease to 0.5. This would ensure that live playbacks with a configured live offset of 3 segments get a chance to switch up (because the actual buffered fraction will be between 0.5 and 0.66 under good network conditions).
• We can change the definition of availableDurationUs in AdaptiveTrackSelection.updateSelectedTrack to only include the time that was actually available for buffering before calling this method. So in the example above, this would be 6.4 seconds instead of 9.6 seconds. This would ensure the default parameters work as intended again (0.75 *6.4 seconds = 4.8 seconds < 5-6 seconds of buffered duration).

[cdongieux]

Thanks a lot for your detailed answer!

[tonihei]

Implemented by the commit above.

[luckygoyal-bitmovin]

Hi @tonihei , I encountered same issue and tested the above fix commit. It improves the behaviour but I can still reproduce this for some cases where I have 4 seconds segments and 4 seconds as MPD update period. Below is my observation. Each MPD update contains 4 segments with a new segment added and oldest segment removed every MPD update(4 seconds).

• The available duration is constantly > 12 seconds, so minDurationForQualityIncrease is returned as 10 seconds.
• Buffered duration goes above 10 seconds threshold only when all segments in MPD are downloaded.
• At this point there are no more segments to download. So even if download rate is much higher, and a higher bitrate rendition is selected to downloaded next but the switch up does not occur.
• By the time next MPD update occurs(after approx. 3-4 seconds), one more segment is added and oldest one removed. The available duration remains > 10 seconds but buffered duration reduces < 10 seconds as approx. 3-4 seconds have elapsed since last download and the buffer level has come done to around 8 seconds. As buffer level(approx. 8 seconds) is < minDurationForQualityIncrease (10 seconds), so no switch up occurs. The newly added segment is downloaded for older quality.
• Now buffer duration > 10 seconds after segment download but there is no next segment to download yet. The above sequence repeats with next manifest update e.i when segment becomes available bufferDuration < 10 seconds and when bufferDuration > 10 seconds, next segment is not available yet for download.

[jamesdavidholding]

Hi @tonihei with the above insight provided against this issue still being present for 4 Second segments with a 4 second update period can I ask would you be able to reopen this ticket to handle this permutation also?

Can I also ask in the interim of this issue not being merged and the above 4sec segment issue observed what would recommend for segment update and segment length to not encounter this issue? Do you see an issue with 2Sec segments with a 4second update for example.