DASH Player stalled with TTML subtitles #2517
Description
Version
Media3 main branch
More version details
Reproducible with release 1.6.1 and main
Devices that reproduce the issue
Android TV 12
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Yes
Reproduction steps
The DASH player is completely stalled when this scenario happens:
This DASH stream is 8 minutes long, and contains TTML subtitles:
http://35.238.68.160/subtitles/Manifest.mpd
At minute 3:24, there are no more subtitles available in the content, and from that point all subtitle fMP4 fragments contain a TTML XML without nodes. This is legitimate, and usually works as expected.
For reference, this is how an empty TTML looks like:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tt xml:lang="" xmlns="http://www.w3.org/ns/ttml" xmlns:tt="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling"><head><styling><style xml:id="s0" tts:backgroundColor="transparent" tts:color="rgba(255,255,255,255)" tts:fontSize="0.80c" tts:fontFamily="proportionalSansSerif" tts:textAlign="center" tts:displayAlign="center"/></styling><layout><region xml:id="r0" tts:origin="2.84% 74.00%" tts:extent="94.32% 26%"/></layout></head><body><div/></body></tt>
This is the interesting part:
If during the playout, before the subtitles are empty, a subtitle fragment/s request/s are replied with an HTTP error (e.g. 404, 403, 500) for few times (it seems >=4 times are required), and even if eventually they are replied with 200 OK, the playout will keep playing after that point but eventually stall when subtitles get empty.
To reproduce it, I prepared a valid content available with Apache server, where the apache2 logs are monitored with a script.
- Each time the manifest file is requested, a single subtitle fragment at minute 2:12 is renamed, so it will not be available and the client will get HTTP error 404 when requesting it
- After 4 requests for that subtitle fragment, the file is renamed back to its original name, and is again available.
The timeline looks like that:
- Playout starts at 0:00. When manifest file request, subtitle fragment file at minute 2:12 is renamed.
- Player plays and buffers ahead video/audio/subtitles. When it tries to load ahead the subtitle fragment at 2:12, it will get 4 times HTTP error 404, and the fifth retry will be successful (as the subtitle fragment file is renamed back to its original name)
- Player continues to play past minute 2:12 with subtitles, as expected.
- At minute 3:24, immediately when there are no more subtitles available, player is stalled forever.
The result:
When playing this content from the start and selecting the subtitles, the player will be stalled at 3:24, although it is 8 minutes long.
This is 100% reproducible with the demo app.
You can try it with this link: http://35.238.68.160/subtitles/Manifest.mpd
The service which is renaming the subtitle fragment is always running.
Here are logs generated with 1.6.1 and with main:
log.media3-main.log
log.media3-1.6.1.log
Expected result
Player is playing until the end of the content at minute 8:00.
Actual result
Player stalls at 3:24.
The player is stuck in BUFFERING.
06-07 18:43:01.594 4299 4299 D EventLogger: rendererReady [eventTime=205.59, mediaPos=203.72, window=0, period=0, rendererIndex=2, text, false]
06-07 18:43:01.597 4299 4299 D EventLogger: state [eventTime=205.59, mediaPos=203.73, window=0, period=0, BUFFERING]
06-07 18:43:01.610 4299 4299 D EventLogger: isPlaying [eventTime=205.61, mediaPos=203.73, window=0, period=0, false]
Media
The monitored stream is under this link:
http://35.238.68.160/subtitles/Manifest.mpd
For reference, there is another exact copy of the content which is not monitored by the script.
All fragment are always available, and the player plays until the expected end of the content at 8 minutes:
http://35.238.68.160/subtitles.clean/Manifest.mpd
Bug Report
- You will email the zip file produced by
adb bugreportto android-media-github@google.com after filing this issue.