Subtitles

[bbert]

I open a discussion topic to review subtitles management in dash.js.
I have some issues or open questions I would like to share before considering modifying dash.js:

1. Is there any reason to distinguish between different subtitles types ('text', 'fragmentedText', 'embeddedText') in public API?
   I am thinking of providing only 'text' type in public API and eventually provided additional property in track information to signal if the text track is either embedded or fragmented.

2. In case of embedded tracks, those tracks informations are not available when using MediaPlayer.getTracksFor() but only in the TEXT_TRACKS_ADDED event.

3. The tracks information returned by MediaPlayer.getTracksFor() are different than the tracks information provided in event TEXT_TRACKS_ADDED

4. For embedded text tracks, AFAIK they are signaled in the manifest using <Accessiblity schemeIdUri="rn:scte:dash:cc:cea-...">
   If they are declared in manifest, we should be able to return the tracks information using MediaPlayer.getTracksFor() once manifest has been loaded.

5. In case we have 2 text tracks of same language/role but with different codecs in the manifest, should we provide all tracks to the application, or do we should filter the tracks (for example keep by default 1st supported codec)

Please feel free to comment, give your opinion or add any other point/issue to consider.

[dsilhavy]

1. I think using one type would be more intuitive. The application has to take care of the choosing the right format though. For instance if there are two english tracks (one sideloaded, one fragmented) we should provide the required information as part of the track
2. Should be added
3. Because of missing embedded tracks and the reason you mentioned n 5) ?
4. Correct, at least for CEA-608 and 708, see IOP 6.4.3
5. I prefer to keep all the tracks to provide maximum flexibility to the app. In my opinion it is not reasonable that a player decides on what to filter (despite unsupported tracks).

[mikedo]

(1) Just text. Although an interesting test case, having multiple concurrent formats (ISOBMFF, sidecar text, etc) would be rather unusual in practice.

(4) There is some industry divergence here that needs attention. See ATSC IOP.

(5) This is a more general question in the case of video and audio as well.

(6) Audio and Text track selection should be done with user preference settings in the app as is done in consumer products today. For US regulatory requirements in this area of what needs to be supported for text see CTA CEB35. Audio has the additional preference requirements for accessibility (audio description, etc). (IMSC1) text has the additional preference of "forced".