Object passed to Player.src is not made available to techs

[imbcmdth]

I am in the midst of creating a tech that requires video-specific data in order to function. The natural place for this is in the object passed into the src function.

Unfortunately, that object is not made available to the underlying tech.

One proposal is to add a second argument to the tech's src function with the object. This would be a backward-compatible way to provide extended information to the tech.

I would be interested to hear what the community thinks about such a change. @heff @dmlap @gkatsev

[dmlap]

Just to make this a bit more concrete, @imbcmdth is trying to pass along the license URL associated with an EME-protected source. The spec leaves the method for acquiring a license server URL unspecified as far as we can tell. We were originally hoping something like this would work:

player.src({ 
  src: 'https://example.com/protected.mpd', 
  type: 'appplication/dash+xml', 
  licenseUrl: 'https://example.com/license'
});

but the tech never gets a handle to the original source object.

A somewhat awkward alternative would be to make the license URL a tech-level option that would have to be reset each time a new video was loaded:

// alternatively, this could be moved into options()
player.tech.licenseUrl = 'https://example.com/license-0'; 
player.src({ 
  src: 'https://example.com/protected-0.mpd', 
  type: 'appplication/dash+xml'
});

// load another video with a new license URL
player.tech.licenseUrl = 'https://example.com/license-1';
player.src({ 
  src: 'https://example.com/protected-1.mpd', 
  type: 'appplication/dash+xml'
});

[heff]

If this is for the dash tech, we should switch it to using the source handlers interface.
https://github.com/videojs/video.js/blob/master/src/js/tech/tech.js#L338

In that model the whole source object gets passed through to the tech & source handler.

video.js/src/js/player.js

Line 1514 in f03a919

// The setSource tech method was added with source handlers

So you could pass anything else with it.

[imbcmdth]

@heff, thanks! That looks like a great solution.

There was one more thing that I wanted to check with you. Right now, in the Dash.js tech I pass the manifest url back in response to a currentSrc call on a tech instead of the blob URL. This was to fix an error I saw with another plugin that was simulating inline ad playback. The player can't resume playback of a blob url.

Talking with David, we couldn't decide whether or not we should always act as the video element does for media source extension videos - always return a blob url - or act like the video element does for playable types - return the url of the hls/dash manifest that started the whole process off.

It makes sense to me that we should make playback from a source using MSE as transparent to the user as possible and that would mean (IMO) returning the resource that actually caused us to use an MSE-enabled tech and not the blob url.

[eXon]

@imbcmdth If you have any tech-specific option, you can use options.lowercasetechname.licenseUrl.

To understand how the options are passed to the tech, you can take a look at the code (this is VJS5):

var techOptions = assign({
      'source': source,
      'playerId': this.id(),
      'techId': `${this.id()}_${techName}_api`,
      'textTracks': this.textTracks_,
      'autoplay': this.options_.autoplay,
      'preload': this.options_.preload,
      'loop': this.options_.loop,
      'muted': this.options_.muted
    }, this.options_[techName.toLowerCase()]);

[heff]

@imbcmdth Yeah interesting, good question. With the video tag you also specifically set the src as the blob, while at the player level the user isn't passing in a blob url. It seems to be that you get out what you pass in. Or at least I can't think of any other case where you set videoEl.src to one thing and videoEl.currentSrc becomes something different.

All of the MSE work is abstracted from the player user in the same way Safari abstracts HLS playback. I'm assuming Safari returns the HLS manifest as the currentSrc. If we were to allow a user to pass a blob url to the player, or if the player passed a blob url to the tech, that might be a different story.

So yeah, returning the manifest URL makes the most sense to me.

[heff]

Also, that might require an update to the source handler interface to allow overriding currentSrc.

[imbcmdth]

@heff Actually, it just seems like it would require this change to the base tech that is overridden: #2232

The Flash tech already does this so it was just my luck that Html5 didn't. With this change, the source handler for Dash.js works exactly as the full tech did.

[heff]

Good stuff. I made a comment on #2232. Let's close this one and continue the conversation there.