Return currentSource_.src instead of blob-urls in html5 tech

[imbcmdth]

The Flash tech already does this and it makes sense to return the URL of the resource instead of a blob-url if the SourceHandler uses MSE.

[heff]

Awesome.

I was worried we'd have a problem switching to other source handlers an not clearing out the previous currentSource_, but it looks like we always set currentSrc_, so the else wouldn't only be hit when no source has been set.

This does create a difference from the video element we might want to think about. The video element's currentSrc does't return the source that's "next". When you set videoEl.src = 'something' and don't call load(), videoEl.currrentSrc won't return something, whereas I think this new code will.
http://jsbin.com/jupuwituri/2/edit?js,console,output

It's weird, but I think that's the whole reason currentSrc exists instead of just relying on src. See any easy ways to make that work the same?

[imbcmdth]

Gary and I came up with an interesting test: http://jsbin.com/sepajuyada/4/edit

Seems like the currentSrc property is always set even without calling load but is done so asynchronously when the "resource selection algorithm" is executed.

[heff]

Interesting, good find. I always assumed it waited for load(), but clearly not.

I remembered the other reason currentSrc exists, which is that you can set the source via the src attribute or the source child elements. vidEl.src should always return the src attribute value, which will be an empty string if the source was set with children. At the tech level we always set the source with the src property not children, so that's not really a problem for us.

So we could either assume we have more info than the video element in this case and return the set source as currentSrc immediately, or try to mimic the asynchronous side of it so it matches exactly with how the video element works, returning the previous source for any synchronous calls to currentSrc. Any other thoughts?

I added on to the jsbin to test some things. You can comment out the source child block to see how that works a little differently.
http://jsbin.com/wulomalopu/1/edit?js,console,output

Some other notes...

When you set an empty string as a source, you'll see there's some differences there. The src attribute will return the absolute URL of the page, while currentSrc will return an empty string in Firefox and Safari, or the previous source URL in Chrome. Go figure.

It looks like the loadstart event should fire before currentSrc is updated, but the browsers are either ignoring that or setting it in parallel before the listener gets to it.

[imbcmdth]

I tried to capture the asynchronous behavior that you mentioned in a test and made some changes to media to emulate that behavior. I think I may have gone too far with the way I handle src when it is an empty string. It's probably best to just allow currentSrc_ to be set to an empty string as well since that seems to be the majority behavior.

[heff]

Very nice. If you use this.setTimeout it will automatically kill the timeout when the tech is disposed. Just to clean up.

Adding async always makes me worried about edge cases we're not thinking of... I can't think of anything specific though so we could pull this in and see how it goes. @videojs/core-committers any final opinions on this (setting currentSrc asynchronously or not)?

[dmlap]

If this matches <video> behavior better, I think it's the way to go. +1 to this.setTimeout.

[dmlap]

Two small comments but otherwise LGTM

[gkatsev]

you should bind this method instead of using the tech variable.

[gkatsev]

Minor comment, otherwise, LGTM.

[gkatsev]

LGTM

[gkatsev]

Closed via 20b46b9