Subtitles from single source Dash live stream not showing up

[islor]

Issue description

I'm trying to play a dash live stream video on the demo app. It has video, multi audio and multi subtitles. The problem I'm facing is getting the subtitles to show up.

As I understand, the subtitles should come up on its own (or is there anything I should do for it to show up in the subtitle view?). I've tried side loading subtitles and have no issues with that.

I suspect the problem might be due to the way the contents are packaged. The subtitles are TTML packaged into CMFT format, would there be an issue with this? I've seen other streams delivering subtitles in mp4 and it seems to play well on the demo app.

Reproduction steps

Insert source url and Widevine license url into demo app. Make sure contents are packaged in cmfa, cmfv, cmft.

Link to test content

I can't share the live url because it is company property and we don't have a test url.

Version of ExoPlayer being used

2.8.1

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

NA

A full bug report captured from the device

There's no bug report captured, but the stream data being captured shows that the subtitles are being delivered, however not shown. But here's a screenshot of the captured data.

[tonihei]

Just checking: To display the subtitles you need to select the text track. If there is no default or forced track, you'd need to specify your selection constrains specifically. Please have look at DefaultTrackSelector and its parameters. In particular you may want to set preferredTextLanguage (and/or selectUndeterminedTextLanguage).

If you try to play the stream in our demo app (or attach our event logger with player.setAnalyticsListener(new EventLogger())), you'll see the list of available text tracks and which one is selected.

[islor]

Hi tonihei, thank you for the response. I've actually already set the preferred language with:

new DefaultTrackSelector.ParametersBuilder()
              .setPreferredTextLanguage("chi")
              .build();

and the log you mentioned is showing that the correct track is selected:

Would the issue be due to the CMFT package?

[tonihei]

Well, given that the text track is selected, I'd assume there is no issue reading the data from your media. Would it be possible to share some media where this problem occurs to dev.exoplayer@gmail.com with "Issue #4472" in the subject?

[ojw28]

I saw a similar case once where the packager wasn't correctly setting the sample flags in the container. If you want to check this, try attaching a debugger to the point where output.sampleMetadata gets called in FragmentedMp4Extractor, and check what the value of sampleFlags is there. If it's always 0 then your content probably has the same issue. Note: FragmentedMp4Extractor instances are probably outputting audio and video samples too. You need to be looking at just the text one. You can also try OR-ing in C.BUFFER_FLAG_KEY_FRAME to see if that "fixes" the issue.

[islor]

@tonihei I'm trying to get a sample stream, but most likely will be difficult to get one.

@ojw28 at your suggestion, I've added a log to check if I'll get to see the flag for text samples
Log.w("TRACKMP4", track.format.sampleMimeType +" "+ sampleFlags);
From what I saw, only video and audio samples are going through. It doesn't seem like the texts are going through here.

[tonihei]

The issue might also be a duplicate of #4083. We are planning to push a fix for that soon.

[ojw28]

You might like to see if the content plays using the very latest dev-v2 branch (i.e. with 2c00be1, which is the workaround Toni mentions above). Note that if the content does now work, it is a content problem (and you should fix it), even though we now work around it in the player.

[islor]

Hi all, many thanks for the update and the workaround. I just managed to test the stream with it. Subtitles seem to be showing up fine now. From what I understand in the other thread, the issue is to do with track_id not being set correctly.

Do you foresee other issues coming up if my team decide to continue using this workaround rather than changing the stream?

[tonihei]

That depends on whether track_ids in other boxes of the stream also don't match and our code assumes they do. We added workarounds for two places where this might happen now, so you should be fine unless there is another case we don't know about yet.

[tonihei]

Closing because it seems to be solved.

[ojw28]

Do you foresee other issues coming up if my team decide to continue using this workaround rather than changing the stream?

You may run into similar issues when using other players. If not now, perhaps in the future if a player you rely on receives an update that means it starts looking at the track id. ExoPlayer used to ignore track id, and later started looking at track id when we added support for playback of muxed FMP4 non-DASH playbacks. So if you'd been using ExoPlayer then, you would have experienced your content break as a result of a technically correct player update.

So I'd suggest you get your content fixed. Or at least make sure any newly transcoded or re-transcoded content that you're generating does not have the issue.