Closed PavelGP closed 7 years ago
It looks like the first failure is that ExoPlayer doesn't find the track in the moov atom, which is part of the initialization chunk. The problem could be with the content (i.e. the initialization chunk failing the declare the track or declaring it incorrectly), or an issue with ExoPlayer (i.e. the extractor failing to handle the way in which the track is declared). It's likely the 416 issue occurs only as a knock-on effect of the first failure.
We don't need full access to the content to investigate, but we do need you to provide the problematic initialization chunk. You can either attach it to this issue, or email it to dev.exoplayer@gmail.com.
Thank you, please follow the link to find initialization chunk: https://drive.google.com/file/d/0B1Agf5-0EdOXN3ZDbUVWTUdNTmc/view?usp=sharing
The initialization chunk is invalid. Specifically, the stsd
box is empty. It should contain an XMLSubtitleSampleEntry() (i.e. an stpp
box) for the text track. Please take a look at "ISO 14496-12 Amendment 2: Carriage of timed text and other visual overlays", which describes what should be present.
Thank you very much, but didn't understand why web players play this stream without fail and show subtitles.
Whether non-compliant media plays successfully often comes down to exactly how the player is implemented. In this case the reason ExoPlayer is looking in the stsd
box in to determine the type of the track. The track type is also defined in the DASH manifest (codecs="stpp"
), and so it's likely that the web players you mention get the track type from the manifest and don't bother looking in the stsd
box for it. Doing this would make sense if you were building a DASH only player. However for regular FMP4 playbacks there is no DASH manifest. Looking in the stsd
box is the only way to go in that case. Since ExoPlayer supports regular FMP4 playbacks (and FMP4 in SmoothStreaming / HLS) in addition to DASH, and since we don't want to maintain multiple code paths, we look in the stsd
box in all cases.