Exoplayer: Multiple audio tracks are not displayed for selection for some of HLS multi audio assets

Created on 5 Mar 2019  路  7Comments  路  Source: google/ExoPlayer

Content description

Since ExoPlayer ver r.2.9.4, for some HLS assets, multiple audio tracks are not seen.
The issue is tested on the demo project (with ExoPlayer r2.9.3 and r.2.9.4).

Expected result: the list of available audio tracks has two audio tracks for the asset I mentioned below.

Actual result: there is only one audio track for the asset.

How to reproduce:

  • copy/paste the link to the manifest to media.exolist;
  • play the asset;
  • tap to audio button;
  • count the number of available audio tracks.

Additional info:

  • In the demo @ContentType int type = Util.inferContentType(uri, overrideExtension); method returns C.TYPE_SS for the asset, but it is HLS. I hardcoded the type as C.TYPE_HLS specifically.
  • In my repo public void onTracksChanged(TrackGroupArray trackGroups, TrackSelectionArray trackSelections) callback I obtain mappedTrackInfo:
    MappingTrackSelector.MappedTrackInfo mappedTrackInfo = trackSelector.getCurrentMappedTrackInfo();
    that is different for the versions I mentioned in the ticket.

Link to test content

The HLS asset that contains the following audio tracks:

  • English
  • German

The link to HLS manifest file is here.

Version of ExoPlayer being used

The issue is reproducible from ExoPlayer r2.9.4 and higher.

Device(s) and version(s) of Android being used

Pixel XL + Android 7.1
Nexus 5 + Android 5.1.1
Xiaomi A1 + Android 9

bug

Most helpful comment

This will be fixed in 2.10 because we reverted the change that introduced the issue.

All 7 comments

Yes, this is indeed an issue. We'll take a look.

https://github.com/google/ExoPlayer/commit/93f4a19f07939bb3cdf606f69142f8de527735f7?diff=unified#diff-f7126640f9a9b7a13981cd10d12aadeaR363

This might be the culprit. There is no url added to audio list if isMediaTagMuxed returns true.

That's the change that introduced this issue, yes. However that change was also fixing something else. The correct way to resolve this is probably to have ExoPlayer's HlsMasterPlaylist more directly represent what the playlist file contains, and move the logic for interpreting it (e.g. whether a media tag is muxed) into HlsMediaPeriod.

A short explanation to external readers:

The issue here is that the playlist parser is marking audio some EXT-X-MEDIA tags as multiplexed because they match one of the audio-only variants. Audio-only variants are discarded during preparation when there are also non-audio-only variants in the playlist. Audio-only among non-audio-only variants are discarded because ExoPlayer does not support disabling tracks (video in this case) as a means of adapting.

This will be fixed in 2.10 because we reverted the change that introduced the issue.

@ojw28 : do you happen to know when will the 2.10 release be

1 to 2 weeks from now.

Was this page helpful?
0 / 5 - 0 ratings