-
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
Progress bar #1253
Progress bar #1253
Conversation
Awesome, thanks for the PR! I believe this work would address #1073 as well. It's going to be a few days before someone can dig into this one for review, but in the meantime would you mind taking a look at the tests? Looks like there are quite a few failing at the moment. |
Tests has been fixed (I didn't know that there is a separate Tech for tests). #1073 — looks like related to stale cache, the easiest fix is to get a time directly from player. The more difficult but correct fix would take a bit of effort to trace why is cache getting stale after seeking. I can take a look if you want. Also I think I haven't made a big enough emphasis on changes in this pull-request. Besides technical fixes to Take a look — and try to seek back-and-forward and play different parts of the video (if you won't seek back-and-forward then almost nothing changes). |
Also we can turn the UI-change for progress-bar into config setting 😄 |
}; | ||
|
||
// remove unloaded buffered ranges | ||
for (var i=0; i < (children.length - buffered.length); i++) { |
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.
children
here is a live NodeList, so children.length
is going to change as you remove elements from it, and not work as this expects. e.g. with 4 children and 2 buffered
Great stuff, thanks! I've been wanting to update the load progress to actually use the multiple time ranges for a long time now. This is a nice implementation of that. Using
That is true. Have you seen any other players handle that issue? I wonder if users care too much about that, and if they do I'd be interested if there's other UI changes that we could make so the loading is visible without changing how the play progress bar works. We should open another issue for that part, but in the mean time if you can remove the play progress bar changes (moving them to a plugin), we should be able to accept this. Thanks again! |
@@ -309,6 +309,10 @@ vjs.Flash.prototype.buffered = function(){ | |||
return vjs.createTimeRange(0, this.el_.vjs_getProperty('buffered')); | |||
}; | |||
|
|||
vjs.Flash.prototype.played = function(){ | |||
return vjs.createTimeRange(0, this.el_.vjs_getProperty('currentTime')); | |||
}; |
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.
This is a decent fallback. Long term I don't think it would be too hard to store the played ranges manually. It would be similar to the manual progress events we fire for flash.
@heff @mmcc I've removed multiple play-progress regions, but have decided to try another strategy to display information about buffered regions prior to current time — adding a bit of opacity to play-progress control. You can try out the result. @heff I've fixed the issue with children.length I can squash the commits if you wish 😉 |
@heff and I just discussed the play progress stuff offline, and while it's definitely an improvement, we agree that it's probably not a great fit for core. We can always show people how to bump down the opacity in docs / guides, or even extract that out to a plugin. Ultimately, we can revisit the play progress styling later, but for now let's try to keep this PR simple and focus on the loading progress aspect. You're welcome to squash your commits, but that happens automatically during our acceptance process, so it's not a big deal either way. |
Gotcha. Removed opacity. Therefore on UI side only multiple buffer-regions are left. |
Awesome, thanks so much. We don't want to surprise folks too much in a minor version update :) |
@mmcc Is there anything else I can do to help to move this pull-request along? |
Honestly, if we could split the |
This reverts commit 6d8bf98.
Sure, I've reverted |
This is great work, thanks! Sorry it's taken a bit to get through this. I ran into an issue where percentify was throwing an error in IE8 because it was returning NaN when time and duration were both zero. I'll send over an update in a second for you to check out. |
@@ -117,7 +117,9 @@ vjs.Slider.prototype.update = function(){ | |||
} | |||
|
|||
// Set the new bar width | |||
bar.el().style.width = vjs.round(barProgress * 100, 2) + '%'; | |||
if (bar) { |
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 wondering, why was this check needed?
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 I remember correctly, it was needed to implement play-progress regions based on player.played instead of current time. But since it was dropped from this pull-request, then this condition can safely be removed.
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.
Ok well, it doesn't hurt for now. Check out the pull request I made against your branch and let me know if it works for you. Then we can get this merged in.
Updated my pull request so that the progress bar now encapsulates all the individual time ranges. Just having broken up time ranges made the bar look a little broken. Now it's a little more subtle. |
@brainopia Thanks for your help on this! Just merged it in and it'll go out with the next minor release. Would you still be interested in putting together something for the played property? If you're on IRC check out the #videojs channel. |
Hello, I've done a few things in this pull-request.
player.buffered
now returns a true timerange with all regions. I'm going to make a video.js plugin which will pick a fastest mirror based on tracking buffered information.Previous approach to
player.buffered
leads to a following situation. If you seek to the later part of the video and then to the earlier one thenplayer.buffered
would return result for the former region and therefore no progress could be tracked until both regions would merge.Change load-progress-bar to display correct information about all buffered regions.
Our users would complain that we display incorrect buffered information. When seeking back and forward across video. Also there is a bug in Opera http://www.sitepoint.com/essential-audio-and-video-events-for-html5/ which can lead to preloading the region with the small part at the end of the video which would be displayed in previous approach as a fully buffered video.
Support for
player.played
(with multiple regions).Change play-progress-bar to display
player.played
regions (otherwise information of buffered regions in earlier parts of the video won't be visible).