-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot addTextTracks after switching off of the HTML tech #2367
Comments
What should we do with the available text tracks? Delete them or recreate them? I guess this does end up falling in with #2369 |
Maybe when we unload a tech we should record all the values of the existing tracks, so they can be added back as native or custom tracks when the next tech is loaded? That would seem to at least match how the video element works. Tracks don't disappear on a source change. You could add all the tracks first before adding a source. |
It kind of is doing so. I guess it needs to do it differently. The issue here is that we're literally grabbing the text track list element from the previous tech and trying to use it in the next tech which doesn't work if you're going from html to flash. |
Yeah, sounds like we need to record the values (all attributes and cues), not keep the tracks themselves around. |
Do we want to preserve the in-band metadata tracks? |
Ultimately I don't think we should. If the user didn't add them then they wouldn't know to remove them when changing the source. |
So, I just realized what we're doing here isn't what we actually want to do. |
And this actually would apply to the text tracks themselves, too. |
Yeah, I wondering if we were going to need to go that direction. It sounds ok to me, but I defer to your judgement.
You're saying we would always need to use our emulated tracks? Why's that? |
tl;dr: it depends on how disruptive we want to be to users while still using as much native functionality as possible. Not saying we always want emulated tracks, but it depends on how far down we want to go. Text track objects have some the |
Wow yeah, there's a lot to consider... Ideally the tracks would work as if you were just using the video element, including when switching sources. With the new details it feels like that'd be a lot to build. Our emulated tracks would need to be able to plug into a native track and proxy everything, or emulate everything, and translate between the two when switching sources to maintain the listeners. Tracks from source handlers might make this a little more complicated, since it's not the user adding the track. It seems possible I'm not sure how far we should try to take it. Part of me wants to say screw it, and just clear all tracks when changing sources, but that would cause issues with advertising and other concatenation workflows. |
I'm about 90% done with copying the tracks between techs. |
@gkatsev is this issue covered now with the related PRs merged? |
I believe this is fixed now. |
@dmlap want to confirm or close? |
Steps to Reproduce
An error will be thrown because the flash tech will attempt to use the native text track list created by the HTML tech.
The text was updated successfully, but these errors were encountered: