androidx / media

Jetpack Media3 support libraries for media use cases, including ExoPlayer, an extensible media player for Android
https://developer.android.com/media/media3
Apache License 2.0
1.71k stars 411 forks source link

How to filter VTT text tracks in AndroidX Media 1.4.0? #1782

Open jpgpuyo opened 1 month ago

jpgpuyo commented 1 month ago

Hello,

I have detected a different behaviour between AndroidX Media 1.3.0 and AndroidX Media 1.4.0. I would like to filter VTT text tracks.

Below I show a sample code to explain this question.

In AndroidX media 1.3.0, I'm doing it in the following way:

override fun onTracksChanged(tracks: Tracks) {
...
tracks.groups.filter{ 
    it.type == C.TRACK_TYPE_TEXT && 
    it.mediaTrackGroup.getFormat(0).sampleMimeType == "text/vtt" }
...
}

Now, in version AndroidX Media 1.4.0, I have to do the following:

override fun onTracksChanged(tracks: Tracks) {
...
tracks.groups.filter{ 
    it.type == C.TRACK_TYPE_TEXT && 
    it.mediaTrackGroup.getFormat(0).sampleMimeType == "application/x-media3-cues"  &&
     it.mediaTrackGroup.getFormat(0).codecs == "text/vtt"
}
...
}

In this particular case, we are not using the Exoplayer subtitles view, we are using our custom view, so I need to retrieve VTT tracks. I have checked release notes but I am not sure where this change is explained.

Is it the expected behaviour or this should be reported as a new bug? Which is the right way to filter VTT text tracks?

Thanks!

icbaker commented 1 month ago

Is it the expected behaviour or this should be reported as a new bug?

The change in MIME type is expected - because from 1.4.0 onwards the bytes written into the SampleQueue for a WebVTT subtitle track are no longer WebVTT UTF-8 text, but instead a media3-specific serialization of the subtitle data - hence the change in MIME type (because the parsing logic for these bytes also needs to change).


In this particular case, we are not using the Exoplayer subtitles view, we are using our custom view, so I need to retrieve VTT tracks. I have checked release notes but I am not sure where this change is explained.

Could you elaborate on this part a bit more - are you parsing the WebVTT data yourself (so you want to consume the UTF-8 text data directly), or are you consuming Cue objects from Player.Listener.onCues or similar? If you are consuming the Cue objects, could you add some more detail on why you care about the 'original' subtitle format (since the Cue object is format-agnostic)? This will help me understand the best way to help you.

jpgpuyo commented 1 month ago

@icbaker The use case is to display subtitles from live TV channels, a feature that is already live in production. When a live channel supports subtitles, users can enable or disable them.

In this scenario, the Android native layer hosts an Android Web View for the UI, while ExoPlayer is used in the native layer for performance reasons. We are not using ExoPlayer's built-in subtitles view; instead, we are rendering subtitles in a non-native layer.

To manage this, we use onCuesChanged to render the subtitles in the non-native layer. Additionally, onTracksChanged helps us determine if the live channel supports subtitles, allowing us to update the non-native layer's UI. If a live channel supports subtitles and the user has enabled them, the non-native layer will display the subtitles accordingly.