TextTracks - Not cleaning up upon detachment

[michaelcunningham19]

What version of Hls.js are you using?

0.12.4

What browser and OS are you using?

Chrome 73 on macOS

Test stream:

https://hls-js.netlify.com/demo/?src=https%3A%2F%2Fwowzaec2demo.streamlock.net%2Fvod-multitrack%2F_definst_%2Fsmil%3AElephantsDream%2Felephantsdream2.smil%2Fplaylist.m3u&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsImVuYWJsZVdvcmtlciI6dHJ1ZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xLCJ3aWRldmluZUxpY2Vuc2VVcmwiOiIifQ==

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page
• The issue occurs in the latest client on https://hls-js-latest.netlify.com/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Open the test stream permalink above. Once playback begins, enable one of the subtitles tracks
2. In the browser console, run hls.destroy()
3. Observe the video element's TextTrackList is still populated with tracks and cues, see below screenshot.
4. Switch to test stream to 'CNN special report, with CC``
5. Observe text tracks from the previous playback session still exist and are selectable.

Expected behavior

I would expect that as part of the detaching phase, the TextTrackList would also be cleaned up / reset. At least having hls.js clean up what it created, to the best of its ability.

Actual behavior

It's left as-is, leaving tracks (which is expected, no way to remove them) and their cues in place. This can cause odd behaviour with switching between content.

Console output

See screenshot:

[OrenMe]

unfortunately there's no removeTextTrack in the HTMLVideoElement spec, so removing any text track created with addTextTrack is not possible.
See whatwg/html#1921 and whatwg/html#2881 for more details.

[hvgotcodes]

What's the recommendation here? Recreate video element for every play back?

[OrenMe]

Currently yes.

[OrenMe]

@michaelcunningham19 as this is web platform limitation I suggest we close this.

[itsjamie]

@OrenMe could hls.js clean up the cues?

[itsjamie]

Actually, with Chrome on Windows using 0.12.4 I can't reproduce this issue anymore. Looking into this...

[itsjamie]

So, these are the text tracks from a previous play. The timeline-controller will clean up the cues between media detachment. See the clearCurrentCues util being used. However, VTT cues like the ones from Angel-One sample are not cleaned up on media detachment.

[jimmywarting]

what if instead of adding a track programmatically with video.addTextTrack() we add a <track> element to the <video> element? the src could be a blob url? or left out?

then we can remove the <track> element to clear the track list, would that be possible?

[robwalch]

@jimmywarting That may work well in some or even most browsers, but it is not a good path forward for hls.js. We should maintain a policy of not modifying DOM tree structure in this project. Manipulating HTMLMediaElement.textTracks TextTrackList via HTMLMediaElement TextTrackElement children is very likely inconsistent across browsers especially on older platforms. For one, we can't use track src with segmented captions. We would need to wait for an event that surfaces the TextTrack instance in a TextTrackList before we could append cues to it after manipulating the media element children. And what if that doesn't happen in some browsers? Can we be sure the CC menu controls will reflect those changes? Will the mode (disabled, hidden, showing) of these tracks default to a value we do not want them to?

Give it a try https://jsfiddle.net/tgwvey8d/4/ sort of works in Chrome but if I chose a CC from the menu, the menu or toggle then disappears. Not in Safari, but for me track 1 defaults to on without any mode setting on tracks (Safari does some weird stuff automatically based on system-level preferences that can be toggled in the touch bar or system settings).

You can disable hls.js's textTrack manipulation via renderTextTracksNatively and then use NON_NATIVE_TEXT_TRACKS_FOUND and CUES_PARSED to add tracks and cues as is best for your application.

If you'd like to continue the conversation or suggest/contribute a change, please create a new issue as this one is closed. The demo currently suffers from this issue in some respects and does not demonstrate the suggested workaround of replacing the video element when necessary, so I would happily accept a new issue that points that out specifically.

[jimmywarting]

You can disable hls.js's textTrack manipulation via renderTextTracksNatively and then use NON_NATIVE_TEXT_TRACKS_FOUND and CUES_PARSED to add tracks and cues as is best for your application.

Nah, i like the native tracks. it haven bother me yet that they still exist.

I know the spec lacks the remove functionality. I just wanted to suggest a possible workaround if it even was possible/feasible.
Guess we have to wait 3 more years until someone else to quote "pick up the torch" on finishing the spec/standard