-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ParserException for DASH Subtitles (WebVTT in MP4 container) #7985
Comments
The dash stream defines text tracks in |
Seems like I'm wrong and this worked before 2.12. Thanks @icbaker for letting me know. :) |
Yep - i can repro that the stream you provided works on 2.11.8 and plays on 2.12 but without functioning subtitles (and with stack traces in logcat similar to the ones you posted). I'll dig further in and work out what's changed here to cause the regression - thanks for the report! |
Looks like this is related to 74a9d8f. Specifically removing this:
And instead delegating to ExoPlayer/library/common/src/main/java/com/google/android/exoplayer2/util/MimeTypes.java Lines 341 to 342 in 8a0d52b
In the context of The problem is that ExoPlayer/library/core/src/main/java/com/google/android/exoplayer2/text/SubtitleDecoderFactory.java Lines 101 to 102 in 8a0d52b
This means I'll send a change to |
This was broken by 74a9d8f because DashManifestParser switched to setting Format.sampleMimeType to text/vtt while SubtitleDecoderFactory was still expecting application/x-mp4-vtt. This change teaches SubtitleDecoderFactory to check both Format.containerMimeType and Format.sampleMimeType. I'll investigate a follow-up change to remove MimeTypes.APPLICATION_MP4VTT completely (it's currently still used in AtomParsers). Issue: #7985 PiperOrigin-RevId: 334771672
We stopped using using this MIME type in 74a9d8f This broke subtitle decoding in some cases (Issue: #7985), which I fixed in 7b8895d. After some discussion we've decided SubtitleDecoderFactory shouldn't depend on Format.containerMimeType (since the samples have already been extracted by this point, so the container shouldn't matter). So this change fixes DashManifestParser to use MimeTypes.APPLICATION_MP4VTT (and reverts the no-longer-needed SubtitleDecoderFactory change). PiperOrigin-RevId: 336668450
This was broken by 74a9d8f because DashManifestParser switched to setting Format.sampleMimeType to text/vtt while SubtitleDecoderFactory was still expecting application/x-mp4-vtt. This change teaches SubtitleDecoderFactory to check both Format.containerMimeType and Format.sampleMimeType. I'll investigate a follow-up change to remove MimeTypes.APPLICATION_MP4VTT completely (it's currently still used in AtomParsers). Issue: #7985 PiperOrigin-RevId: 334771672
We stopped using using this MIME type in 74a9d8f This broke subtitle decoding in some cases (Issue: #7985), which I fixed in 7b8895d. After some discussion we've decided SubtitleDecoderFactory shouldn't depend on Format.containerMimeType (since the samples have already been extracted by this point, so the container shouldn't matter). So this change fixes DashManifestParser to use MimeTypes.APPLICATION_MP4VTT (and reverts the no-longer-needed SubtitleDecoderFactory change). PiperOrigin-RevId: 336668450
[REQUIRED] Issue description
This stream worked fine in 2.11.8
https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd
On ExoPlayer 2.12.0 I get this:
[REQUIRED] Reproduction steps
Stream https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd
and select any of the subtitle tracks.
[REQUIRED] Link to test content
https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd
[REQUIRED] A full bug report captured from the device
bugreport-sdk_gphone_x86-QSR1.191030.002-2020-09-24-22-36-21.zip
[REQUIRED] Version of ExoPlayer being used
2.12.0
[REQUIRED] Device(s) and version(s) of Android being used
Android 10 on Pixel 3a emulator
The text was updated successfully, but these errors were encountered: