-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Adding a method to get the ratio of video length buffered compared to bufferingGoal #3392
Conversation
updating my repo
Updating my repo
ui/controls.js
Outdated
if (bufferedEnd_ >= bufferingGoal_) { | ||
return 100; | ||
} else if (bufferedEnd_ < bufferingGoal_) { | ||
return ((bufferedEnd_/bufferingGoal_)*100); |
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 calculation is wrong, because it doesn't account for the starting point. The start of the range should be currentTime, not 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.
@joeyparrish the formula of bufferingGoal_ does account for the starting point. I named the variable wrong, I'll try coming up with a better name. I am bad at it so I am open to suggestions.
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 think the formula is wrong . The fraction should be between buffering goal and the length buffered after the current time . So the formula will be (bufferedEnd_-currentTime)/bufferingGoal
lib/player.js
Outdated
getBufferFullness() { | ||
const bufferedLength_ = this.video_ ? | ||
this.video_.buffered.length : 0; | ||
const bufferedEnd_ = |
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.
Style-wise, we don't end local variables with underscores. That is the convention for private member variables.
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.
lib/player.js
Outdated
} else if (bufferedEnd_ <= this.video_.currentTime) { | ||
return 0; | ||
} else if (bufferedEnd_ < lengthToBeBuffered) { | ||
return ((bufferedEnd_ - this.video_.currentTime) / bufferingGoal_); |
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 calculation looks correct to me now. Thanks!
lib/player.js
Outdated
} else if (bufferedEnd <= this.video_.currentTime) { | ||
return 0; | ||
} else if (bufferedEnd < lengthToBeBuffered) { | ||
return ((bufferedEnd - this.video_.currentTime) / bufferingGoal); |
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.
On further consideration, I think this is not quite right. In the edge case where seekRange.end() limits buffering, this would not approach 1.0, because the buffered amount would never reach bufferingGoal.
I think it should probably be:
return (bufferedEnd - this.video_.currentTime) /
(lengthToBeBuffered - this.video_.currentTime);
Does that make sense?
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.
Yes, it makes complete sense. I used this formula in my previous commit thinking about that edge case but when I rechecked later I couldn't recall the exception case and changed the formula.
Thank you
@joeyparrish Thank you for being this patient, From next time I'll make sure I avoid any extra conditions, lines, variables, and their names. |
No, thank you for persevering! We appreciate our contributors, and it can take time to learn how we do things.
Oh, I beg to differ: https://en.wikipedia.org/wiki/List_of_mathematical_constants 😁 |
😂😂😂 The lines in PR #3373 are 412 but the changes are pretty small. Is there a reason for delaying the review? |
We just haven't gotten to it yet. It's hard to keep up with all PRs, and with everything we juggle as a team (beyond this one project), we're not very consistent. Please accept our apologies. |
Ohh. I understand. No problem. |
Oops! I just realized I forgot to run the build bot before I merged this. We really need to migrate to GitHub Actions and make that fully automated. I've just kicked off a new test run. If the linter or tests fail, we may have to revert the change or quickly fix it in a follow-up change, depending on the severity. |
I was surprised too seeing the changes being merged without the bot run . |
Just fixed the failing test in 0a62396. Thanks again! |
This reverts commit 9c0126b. This should not have been cherry-picked to a release branch.
Description
closes #3389
Screenshots (optional)
Type of change
Checklist:
./build/all.py
and the build passes./build/test.py
and all tests pass