Skip to content
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

Closed
bhjortsberg opened this issue Sep 24, 2020 · 4 comments
Closed

ParserException for DASH Subtitles (WebVTT in MP4 container) #7985

bhjortsberg opened this issue Sep 24, 2020 · 4 comments
Assignees
Labels

Comments

@bhjortsberg
Copy link

bhjortsberg commented Sep 24, 2020

[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:

2020-09-24 22:22:52.987 6762-7202/com.mtdeer.exostreamr E/TextRenderer: Subtitle decoding failed. streamFormat=Format(2, null, application/mp4, text/vtt, wvtt, 736, en, [-1, -1, -1.0], [-1, -1])
      com.google.android.exoplayer2.text.SubtitleDecoderException: com.google.android.exoplayer2.ParserException: Expected WEBVTT. Got �����vtte
        at com.google.android.exoplayer2.text.webvtt.WebvttDecoder.decode(WebvttDecoder.java:63)
        at com.google.android.exoplayer2.text.SimpleSubtitleDecoder.decode(SimpleSubtitleDecoder.java:73)
        at com.google.android.exoplayer2.text.SimpleSubtitleDecoder.decode(SimpleSubtitleDecoder.java:27)
        at com.google.android.exoplayer2.decoder.SimpleDecoder.decode(SimpleDecoder.java:234)
        at com.google.android.exoplayer2.decoder.SimpleDecoder.run(SimpleDecoder.java:198)
        at com.google.android.exoplayer2.decoder.SimpleDecoder.access$000(SimpleDecoder.java:29)
        at com.google.android.exoplayer2.decoder.SimpleDecoder$1.run(SimpleDecoder.java:72)
     Caused by: com.google.android.exoplayer2.ParserException: Expected WEBVTT. Got �����vtte
        at com.google.android.exoplayer2.text.webvtt.WebvttParserUtil.validateWebvttHeaderLine(WebvttParserUtil.java:45)
        at com.google.android.exoplayer2.text.webvtt.WebvttDecoder.decode(WebvttDecoder.java:61)
        at com.google.android.exoplayer2.text.SimpleSubtitleDecoder.decode(SimpleSubtitleDecoder.java:73) 
        at com.google.android.exoplayer2.text.SimpleSubtitleDecoder.decode(SimpleSubtitleDecoder.java:27) 
        at com.google.android.exoplayer2.decoder.SimpleDecoder.decode(SimpleDecoder.java:234) 
        at com.google.android.exoplayer2.decoder.SimpleDecoder.run(SimpleDecoder.java:198) 
        at com.google.android.exoplayer2.decoder.SimpleDecoder.access$000(SimpleDecoder.java:29) 
        at com.google.android.exoplayer2.decoder.SimpleDecoder$1.run(SimpleDecoder.java:72) 

[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

@bhjortsberg bhjortsberg changed the title ParserException for Subtitles ParserException for DASH Subtitles Sep 24, 2020
@marcbaechinger
Copy link
Contributor

The dash stream defines text tracks in application/mp4 and the stack trace suggests that the WebvttParserUtil reads a binary file while expecting a text file. ExoPlayer supports separate text tracks for text mime types as documented in the developer guide.

@marcbaechinger marcbaechinger self-assigned this Sep 24, 2020
@marcbaechinger marcbaechinger changed the title ParserException for DASH Subtitles Support DASH Subtitles in application/mp4 container Sep 24, 2020
@marcbaechinger
Copy link
Contributor

Seems like I'm wrong and this worked before 2.12. Thanks @icbaker for letting me know. :)

@icbaker
Copy link
Collaborator

icbaker commented Sep 25, 2020

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!

@icbaker
Copy link
Collaborator

icbaker commented Sep 28, 2020

Looks like this is related to 74a9d8f.

Specifically removing this:

} else if (codecs.startsWith("wvtt")) {	
  return MimeTypes.APPLICATION_MP4VTT;	  // "application/x-mp4-vtt"
}

And instead delegating to MimeTypes.getMediaMimeType which translates 'wvtt' to 'text/vtt':

} else if (codec.startsWith("wvtt")) {
return MimeTypes.TEXT_VTT;

In the context of DashManifestParser that change makes sense - the method is called getSampleMimeType, and the samples are WebVTT.

The problem is that SubtitleDecoderFactory wasn't updated at the same time, and it expects to see application/x-mp4-vtt and uses that to decide to create a Mp4WebvttDecoder (which is the class that knows how to pull WebVTT data out of an MP4 container):

case MimeTypes.APPLICATION_MP4VTT:
return new Mp4WebvttDecoder();

This means SubtitleDecoderFactory creates a WebvttDecoder which expects the input data to be a simple text file starting WEBVTT on the first line - which explains the error you're seeing, and why Marc concluded this was a binary file being read by something expecting plaintext (since that's exactly what's happening).

I'll send a change to SubtitleDecoderFactory to consider Format.containerMimeType as well: if container == "application/mp4" && sample == "text/vtt" then we should use Mp4WebvttDecoder.

@icbaker icbaker changed the title Support DASH Subtitles in application/mp4 container ParserException for DASH Subtitles (WebVTT in MP4 container) Sep 28, 2020
kim-vde pushed a commit that referenced this issue Oct 6, 2020
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
kim-vde pushed a commit that referenced this issue Oct 13, 2020
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
@icbaker icbaker closed this as completed Oct 16, 2020
ojw28 pushed a commit that referenced this issue Oct 21, 2020
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
ojw28 pushed a commit that referenced this issue Oct 21, 2020
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
@google google locked and limited conversation to collaborators Dec 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants