Change captions setup logic to work with tech like dash.js

jronallo commented 7 years ago

[x] Issue does not already exist
[ ] Issue observed on https://plyr.io

This is an enhancement request.

Expected behaviour

I expect the captions control to be able to turn on/off text tracks regardless of how they're added to the video TextTrackList. So for dash.js where a text track from within an Media Presentation Description manifest is included, these captions should still be able to be controlled with the Plyr captions control.

Actual behaviour

The control has no effect. Plyr currently does not know that a TextTrack has been added dynamically so the control does not display. Even if the control is forced to be displayed toggling it has no effect since the captions aren't registered properly with Plyr. Note that the captions display by default, but the user has no way to turn them off.

Steps to reproduce

You can see this behavior here: http://codepen.io/jronallo/pen/VmOrNZ

Enhancement Request

_setupCaptions does not work when a tech like dash.js is used with HTML5 video and there are captions included in the Media Presentation Description document. It seems as if Dash.js handles creating a TextTrack through the JavaScript API without creating a element. (When hls.js supports EXT-X-MEDIA WebVTT these changes ought to help with the HLS case as well.)

Currenty the function in Plyr only looks for elements so it has no way of knowing that there has been a text track added since there is no track element present. There is not even an explicit source URL in some cases as Dash.js manages updating the track in cases where the text track is segmented.

I'm proposing that in order for Plyr to work better with any HTML5 tech that changes be made to how captions get set up. Instead of checking for a track element, it could check the video element for the presence of a TextTrack in the TextTrackList of the video element. If native captions are supported then those would be used instead of using the shim (which could probably be improved). In this way the text tracks could be found even in cases where there is not a track element already. It would require external tech like dash.js to either setup Plyr after it is set up or trigger a reinitialize method. If a native captions are not present, but a track element is included or the player.source() is used to set up the video sources including tracks that then become track elements, then Plyr could use the shim.

In order to get Plyr to work for me with dash.js I've currently had to create some extra API methods to control showing and toggling captions in my own plugin. By making the change where Plyr recognizes that a text track already exists even without a track element, it would mean that Plyr could manage all text tracks appropriately regardless of how the text track is added to the video.

I can try to dig into this further and potentially submit a pull request for consideration, but I wanted to check if you'd accept a change like this? If not a change like this, is there another approach that you would prefer for how to allow Plyr to work with dash.js and other libraries that add TextTracks without adding a track element? Another option I could explore is how vtt.js might be able to provide a more robust handling of captions than the current shim.

Thoughts on how to meet this use case of external tech like dash.js managing captions?

Relevant links

sampotts commented 7 years ago

Thanks for the very comprehensive bug/feature request. I'll take a look through once I get done with the current workload of features. 👍

sampotts commented 6 years ago

Can you try v3 to see if this is still an issue? Sorry I know it's been ages 👍

friday commented 6 years ago

Still not working, although the reason specified is now fixed for v3. I updated the example to v3, jsbin (better for console output) no debugging and waited for the TEXT_TRACKS_ADDED- event to initialize Plyr.

http://jsbin.com/sorociboju/1/edit?js,console,output

The menu is now generated, but switching doesn't work. Like #971. Seems to be working pretty poorly even without Plyr though. At least in Chrome.

friday commented 6 years ago

Closing in favor of #994 (has more relevant info and a working reference implementation)

sampotts / plyr