icbaker
commented
3 years ago I believe the DASH spec includes this requirement for a reason: Imagine if segment N requires subtitle data from segment N-1, and you seek into segment N from segment N-2. The player shouldn't need to download segment N-1 at all, but if you need segment N-1 to correctly show the subtitles for segment N then you're stuck with either:
- Not showing the subtitles (current behaviour)
- Optimistically fetching segment N-1 in case it contains relevant subtitle data (wasteful)
I haven't experimented with bitmovin's player, but I'd be interested if they show the subtitles correctly if you perform the seek operations I describe (rather than just playing back continuously through the subtitles).
You could argue that ExoPlayer should show the subtitles during continuous playback, but not during the seeking case (since it already has segment N-1 downloaded) - but that introduces strange inconsistent behaviour: If you arrive at playback point T continuously the player will render different data than if you arrive at the same point from a seeking operation.
I'm afraid we're unlikely to change ExoPlayer to handle non-spec-compliant media - even if there are other players that seem to support it - especially where it leads to awkward trade-off decisions as in this case. I think the best thing to do is fix the media so that each segment is self-contained.
I'm facing a problem same as the one discussed here https://github.com/google/ExoPlayer/issues/7374. Looking at the https://github.com/google/ExoPlayer/issues/7374#issuecomment-628726695 it seems the problem is that stream is not according to DASH specs. However, same stream is working fine in other players like bitmovin. Meaning that these players are handling this case and displaying subtitles as expected. Can we take care of this corner case in ExoPlayer itself?