Skip to content

new TrackSelection not updated in HlsChunkSource #6256

Closed
@stevemayhew

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:

  1. Disable the audio track
  2. Print or observer with a debugger the TrackSelection object reference in HlsChunkSource, it should change to match that in MediaPeriodHolder

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

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions