-
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
Feature/current source #2678
Feature/current source #2678
Conversation
Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED Commit: 4dc3e77 (Please note that this is a fully automated comment.) |
Addresses #2443 |
@heff Any status updates? |
Unfortunately, I don't think we'll get it in a 5.2 release but I'll definitely take a look at it next. |
Looks like this needs to be rebased against master :) |
…ource objects—when using `<source>` or `src()`. This is needed for source retrival for two use cases: - preroll - resolution switch (kind of) Currently there is no way of accessing the source object for any DRM specified content. Plugin access only has API methods to `currentSrc` and `currentType`. This will allow for `currentSource` and `currentSources` to return unverified source object(s). # Conflicts: # src/js/player.js # test/unit/player.js
…urce, have the current sources be set to null. When the `currentSources()` are called after `src('http://example.com')`, expect the `currentSources()` to only return the newly set source. This way sources, via `<source>` or `src([...])` list, should never be out of sync when redefining a single source. Updating tests to specify behavior changes. Remove autoplay from fixtures to bypass `loadTech()` ramifications. # Conflicts: # src/js/player.js # test/unit/player.js
4dc3e77
to
5248d86
Compare
* @method currentSource | ||
*/ | ||
currentSource() { | ||
return this.cache_.source || { src: this.currentSrc() }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this.currentSrc()
returns undefined should this method return {}
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds fine to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial thought is to throw away all the code for currentSrc()
since now is very duplicative and loses information such as type. Though this is a breaking change and there is probably a big hole in my logic.
Atm, currentSrc()
returns a string
or undefined
…
I think it makes sense to translate that across those methods.
currentSrc() === undefined
currentSource() === undefined
currentSources() === undefined
vs.
currentSrc() === undefined
currentSource() === { src: undefined } or {}
currentSources() === [{ src: undefined }] or []
So I would recommend undefined
or {}
and []
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I lean toward all three methods returning undefined
if there is no source.
My second preference would be {}
or []
for the two new ones, but I feel like in that case, it would make more sense for currentSrc
to return ''
instead of undefined
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, undefined
would be not backwards compatible but also would break away from what the video element does for currentSrc
:
document.createElement('video').currentSrc
// ""
As for the others, returning an empty object and empty array would make it consistent. Though, would be a bit annoying to check for whether it's empty or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! I thought currentSrc
returned undefined
. In that case, I vote for currentSource
to return undefined
and currentSources
to return []
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having currentSource
return undefined
seems inconsistent to me. Both from it's internal type signature but also between the 3 methods.
currentSrc
always returns a string and currentSources
always returns an array, why should currentSource
be different?
@gesinger, does |
@gkatsev any update? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gesinger do you have any changes that we should apply to this PR and merge?
@gkatsev only thing I might consider is the check for no currentSrc from https://github.com/videojs/video.js/compare/master...gesinger:feature/current-source-obj?expand=1#diff-3b0266ff1c037b289ec624ab25b0272eR2092 |
On second thought, I think it is fine either way. |
…Source` to return `{}` when `src` is `''`. NOTE: these tests only pass because they are hitting the `cache_`. - Fix tests - Add method to `TechFaker`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gesinger @gkatsev @misteroneill Update per initial conversation, minor to change again.
(First time trying this review tool)
I don't know how to properly test src
changes as there isn't any other tests that validate sources. It looks like I needed to update TechFaker
for non-empty <source>
tags with unspecified tech?, but in either case I don't think it properly tests the methods—only the cache_
?
* @return {Object[]} The current source objects | ||
* @method currentSources | ||
*/ | ||
currentSources() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated to return []
when src is ''
const sources = []; | ||
|
||
// assume `{}` or `{ src }` | ||
if (Object.keys(source).length !== 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seemed like a fine isEmpty
check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. I don't know if it's merged yet, but I introduced utils/obj
in a PR recently. An isEmpty
could be useful there. If not, this is fine, I think.
* @return {Object} The current source object | ||
* @method currentSource | ||
*/ | ||
currentSource() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated to return {}
when src is ''
I looked for an On Thu, Sep 22, 2016 at 5:16 PM, misteroneill notifications@github.com
|
sources.push(source); | ||
} | ||
|
||
return this.cache_.sources || sources; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we do the work of setting up the sources
variable if we're just going to return this.cache_.sources
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know off the top of your head that sources
will never get called because this.cache_
will always be present?
I most likely implemented this to follow suit of the original implementation—thinking that there will be a difference between <source>
and src
, but since the PR been open for some time I have no idea anymore.
I can investigate further if unknown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is a big concern. It's fine to leave as is and we can always profile and increase performance in the future.
source.src = src; | ||
} | ||
|
||
return this.cache_.source || source; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same question here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just tried it out locally. Works great.
Original PR: #2479