exporting techName and loadTech

[mattosborn]

Exporting techName and loadTech. The use case is to allow videojs-contrib-ads to snapshot and restore the current loaded tech.

Switching tech would be better done by video.js transparently based on the source object passed to .src(), but the player does not retain source type information for later retrieval, only the source url, and modifying that would be a breaking change.

In videojs-contrib-ads, the tech needs to be snapshotted and restored when the ad relies on a different tech to the content video, as the videojs player does not check for compatibility when passing a string to .src()
https://github.com/guardian/videojs-contrib-ads/commit/e7c14b34781742dc6a7ed41234ea1e7f9fa18c9e

[heff]

Check out #1234 for a recent discussion around this, and why I'd like to avoid exporting techName.

I think being able to retrieve the current source type makes a lot of sense. We wouldn't change how src() works because it's an HTML5-defined method, but we could make an additional method for retrieving that info, like currentType to get the type or currentSource to get the source object that includes both. I think currentType would be the easiest to justify, if you'd be interested in making a pull request to add that.

[mattosborn]

Ye I agree with you that techName shouldn't really be exported. This was a lazy fix!

Where would the source type information come from? We can't infer it, so the only correct source is passed in during the .src({object}) call. If we store it during this call what happens in the subsequent .src("string") call? And what happens when .src("string") is called directly?

[heff]

That's true, if someone uses .src("string") we just couldn't know the type. We've discussed inferring the type from the URL, and we may try to do that in some cases, but it's a brittle solution that I don't love.

So then currently, if we just stored the type included in a source object, if someone uses .src("string") we would have to empty the previously stored type value, but then .src({object}) calls .src("string") internally, which would then empty its own stored type.

What we could do is make .src({object}) the final step of the src function. So if you call .src("string") it creates a source object with an empty string for the type and calls src(sourceObject), which then does the techCall.

That wouldn't change the API options, but we would probably then emphasize (in docs/examples) using source objects instead of source strings. Using a source string in any case blocks video.js's ability to switch techs, so we really should be emphasizing that anyway, even though it's different from how the video element. The video element doesn't support multiple technologies.

How does that sound?

[mattosborn]

Ye sounds good. I'll try to put in a pull request later today or early next week.

[heff]

Nice, thanks.