Description
Issue description
When playing back adaptive HLS content if you change the playback speed the AdaptiveTrackSelection
should level down to a lower bitrate track to avoid stalls, it does not because the playbackSpeed
update is missed since the HlsChunkSource
that calls this method references a stale TrackSelection
.
The code that handles this is:
@SuppressWarnings("unused")
protected boolean canSelectFormat(
Format format, int trackBitrate, float playbackSpeed, long effectiveBitrate) {
return Math.round(trackBitrate * playbackSpeed) <= effectiveBitrate;
}
Reproduction steps
Playback using any HLS content (I used the Mango Open Source video: https://mango.blender.org, I'll email an S3 bucket with an HLS version of this). Then:
- Disable the audio track
- Print or observer with a debugger the
TrackSelection
object reference inHlsChunkSource
, it should change to match that inMediaPeriodHolder
Triage
This is easy to reproduce by just disabling the audio track. This forces a invalidate (TrackSelector.invalidate()
called). The invalidate creates a new AdaptiveTrackSelection
object, via TrackSelection.Factory.createTrackSelection()
The updated TrackSelection
instance is stored in the MediaPeriodHolder
but not updated in the HlsChunkSource
. This is because of logic to avoid re-creating the SampleStream (a good thing) in HlsSampleStreamWrapper
Link to test content
Mango Open Source - Tears of Steel (I'll send a link)
A full bug report captured from the device
I'll send it, probably useless though, the issue is a logic issue not platform specific.
Version of ExoPlayer being used
dev-v2-r2.10.3 - 1275217
Device(s) and version(s) of Android being used
Evolution IPA-1104HDH-01. SDK 26