media icon indicating copy to clipboard operation
media copied to clipboard
verified publisher icon androidx

Not able to play specific video quality

Open ShantanuPb opened this issue 2 months ago • 2 comments

Version

Media3 main branch

More version details

🐞 ExoPlayer Media3 Bug Report: HLS Adaptive Switch Fails, Only Low Bitrate Renders Library Version

ExoPlayer/Media3 Version: All version

Issue on all devices.

Media and Content

Manifest URI: https://d3h6zjaqbnx4yp.cloudfront.net/isuued_file/176224657492867316486/176224657492867316486_7316486.m3u8

Media Type: HLS (Muxed Audio/Video, AVC/AAC)

Manifest Snippet:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=693880,AVERAGE-BANDWIDTH=510411,RESOLUTION=426x240,FRAME-RATE=25.000,CODECS="avc1.4D4015,mp4a.40.2"
index_1.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1164088,AVERAGE-BANDWIDTH=840375,RESOLUTION=640x360,FRAME-RATE=25.000,CODECS="avc1.4D401E,mp4a.40.2"
index_2.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1477588,AVERAGE-BANDWIDTH=1060375,RESOLUTION=852x480,FRAME-RATE=25.000,CODECS="avc1.4D401E,mp4a.40.2"
index_3.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2798468,AVERAGE-BANDWIDTH=2010763,RESOLUTION=1280x720,FRAME-RATE=25.000,CODECS="avc1.64001F,mp4a.40.2"
index_4.m3u8

📝 Description of Issue Steps to Reproduce Initialize ExoPlayer using a DefaultTrackSelector and the provided Master Manifest URI.

Set playWhenReady = true (default "Auto" adaptive start).

What I Expected to Happen The player should successfully start playback by selecting an appropriate adaptive track (likely 360p or 480p) and render video and audio without issues.

What Actually Happened The player immediately fails to render the first frame:

Initial Playback Failure: When the player starts on the default "Auto" setting, the screen remains black and there is no audio. The player reports isPlaying=true before onRenderedFirstFrame is hit, indicating a silent stall in the rendering pipeline.

Only 240p Works: The only way to achieve playback is by manually applying a TrackSelectionOverride to force the selection of the lowest quality, 240p track (avc1.4D4015).

Manual Switch Failure: If playback starts successfully at 240p, any subsequent attempt to switch quality (e.g., to 360p, 480p, or 720p) via a TrackSelectionOverride results in the same black screen and silent failure.

🔑 Crucial Debugging Information This issue appears to be a flaw in the ExoPlayer HLS adaptive switching logic or its interaction with the Android MediaCodec for this specific manifest structure:

Decoder Capable: All higher-bitrate tracks (e.g., 720p, index_4.m3u8) play perfectly fine when their individual child manifest URLs are passed to the player as a standalone stream. This rules out content corruption or a fundamental device decoder limitation.

No Exceptions in Logcat: The failure is silent. No E/ logs are produced with ExoPlaybackException, DecoderInitializationException, or HttpDataSourceException during the initial start-up failure or the manual switch failure. The only related log is onAudioTrackReleased, indicating a pipeline breakdown.

Online Players Work: The video plays successfully across all qualities on web-based players (e.g., Shaka Player demo), confirming the media is compliant.

Devices that reproduce the issue

All Devices

Devices that do not reproduce the issue

None

Reproducible in the demo app?

Yes

Reproduction steps

Just play the url in exoplayer

Expected result

The media plays successfully

Actual result

Not able to play except on 240p

Media

https://d3h6zjaqbnx4yp.cloudfront.net/isuued_file/176224657492867316486/176224657492867316486_7316486.m3u8

Bug Report

  • [ ] You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

ShantanuPb avatar Dec 02 '25 12:12 ShantanuPb

@ShantanuPb

Thanks for providing all the necessary information and sample media. The issue stems from that your HLS Manifests break the RFC 8216 spec for HLS.

The "working" 240p track has different X-PROGRAM-DATE-TIME mappings of date and time to media timestamps than the other three tracks. The other three tracks each start with a EXT-X-DISCONTINUITY not found in the 240p track.

According to https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-18#section-6.2.4, "If any Media Playlist in a Multivariant Playlist contains an EXT-X-PROGRAM-DATE-TIME tag, then all Media Playlists in that Multivariant Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent mappings of date and time to media timestamps."

ExoPlayer aligns the startime of playback to the first stream in the manifest, the 240p track, and then finds issue when starting to play the other streams as they "start" way earlier. The reason why no frames are rendered is because ExoPlayer is trying to play content at a time "after" the three non-working streams have finished.

Snippet from 240p Manifest

#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-MEDIA-SEQUENCE:135277
#EXT-X-DISCONTINUITY-SEQUENCE:172
#EXT-X-ALLOW-CACHE:NO
#EXT-X-PROGRAM-DATE-TIME:2025-11-04T07:30:15.996Z
#EXTINF:8.000,
index_1_135277.ts

Snippet from 360p Manifest

#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:8
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-MEDIA-SEQUENCE:135276
#EXT-X-DISCONTINUITY-SEQUENCE:172
#EXT-X-PROGRAM-DATE-TIME:2025-11-04T06:02:04.985Z
#EXTINF:2.200,
index_2_135276.ts
#EXT-X-DISCONTINUITY
#EXT-X-ALLOW-CACHE:NO
#EXT-X-PROGRAM-DATE-TIME:2025-11-04T07:30:16.520Z
#EXTINF:8.000,
index_2_135277.ts

Hopefully if you fix your manifests then everything should play as expected.

microkatz avatar Dec 05 '25 14:12 microkatz

Hi @microkatz

The problem that you've identified is correct but to resolve the manifest will be a huge problem for us as it is harvested through AWS and we need to hassle with AWS for the same, but at the same time all the other player on other platforms like shaka player for web and Avplayer for iOS are able to play this url fine. So is there any thing we can do on our end to parse this faulty manifest.

ShantanuPb avatar Dec 12 '25 10:12 ShantanuPb

@ShantanuPb

I think the easiest path at the moment is to get the manifest fixed. Any workaround would be very specific and apply only to this content. You would add your custom logic for this by producing a custom HlsPlaylistParser and/or an HlsPlaylistTracker.

One workaround that may be of interest is using TrackSelectionParameters.Builder.setMinVideoSize to "disable" the 240p track. That makes one of the other three streams the primary timestamp setter and causes the three non-240p streams to play as expected. I tried afterwards to force select the 240p stream but it didn't play correctly as the 240p stream is based on a different start time than the others.

Hopefully you are able to fix your manifest or the TrackSelectionParameter suggestion is helpful to you!

microkatz avatar Dec 16 '25 13:12 microkatz