Skip to content
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

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

Closed
imbcmdth opened this issue Jun 1, 2015 · 8 comments
Closed

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

imbcmdth opened this issue Jun 1, 2015 · 8 comments

Comments

@imbcmdth
Copy link
Member

imbcmdth commented Jun 1, 2015

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
Copy link
Member

dmlap commented Jun 1, 2015

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
Copy link
Member

heff commented Jun 1, 2015

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.

// The setSource tech method was added with source handlers

So you could pass anything else with it.

@imbcmdth
Copy link
Member Author

imbcmdth commented Jun 1, 2015

@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
Copy link
Contributor

eXon commented Jun 1, 2015

@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
Copy link
Member

heff commented Jun 1, 2015

@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
Copy link
Member

heff commented Jun 1, 2015

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

@imbcmdth
Copy link
Member Author

imbcmdth commented Jun 3, 2015

@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
Copy link
Member

heff commented Jun 4, 2015

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

@heff heff closed this as completed Jun 4, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants