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

Adding a method to get the ratio of video length buffered compared to bufferingGoal #3392

Merged
merged 11 commits into from
May 11, 2021

Conversation

surajkumar-sk
Copy link
Contributor

@surajkumar-sk surajkumar-sk commented May 6, 2021

Description

closes #3389

Screenshots (optional)

Type of change

  • New feature (non-breaking change which adds functionality)

Checklist:

  • I have signed the Google CLA https://cla.developers.google.com
  • My code follows the style guidelines of this project
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • I have verified my change on multiple browsers on different platforms
  • I have run ./build/all.py and the build passes
  • I have run ./build/test.py and all tests pass

ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated
if (bufferedEnd_ >= bufferingGoal_) {
return 100;
} else if (bufferedEnd_ < bufferingGoal_) {
return ((bufferedEnd_/bufferingGoal_)*100);
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@surajkumar-sk surajkumar-sk May 7, 2021

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

ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated Show resolved Hide resolved
ui/controls.js Outdated Show resolved Hide resolved
@surajkumar-sk surajkumar-sk changed the title Adding a method for checking efficiency Adding a method to check if the downloading can keep pace with the video playback May 7, 2021
@surajkumar-sk surajkumar-sk changed the title Adding a method to check if the downloading can keep pace with the video playback Adding a method to check if the downloading is keeping pace with the video playback May 8, 2021
@surajkumar-sk surajkumar-sk changed the title Adding a method to check if the downloading is keeping pace with the video playback Adding a method to get the ratio of video length buffered compared to bufferingGoal May 11, 2021
lib/player.js Outdated
getBufferFullness() {
const bufferedLength_ = this.video_ ?
this.video_.buffered.length : 0;
const bufferedEnd_ =
Copy link
Member

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.

Copy link
Contributor Author

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_);
Copy link
Member

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 Show resolved Hide resolved
lib/player.js Outdated
} else if (bufferedEnd <= this.video_.currentTime) {
return 0;
} else if (bufferedEnd < lengthToBeBuffered) {
return ((bufferedEnd - this.video_.currentTime) / bufferingGoal);
Copy link
Member

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?

Copy link
Contributor Author

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

@surajkumar-sk
Copy link
Contributor Author

@joeyparrish Thank you for being this patient, From next time I'll make sure I avoid any extra conditions, lines, variables, and their names.
It's really embarrising writing the formula wrong after doing competitive programming for years.
This is also a very new experience, I never really cared much about few extra conditions, random laying variables, and their names. Only time and memory mattered. But I was just dealing with few 100 lines, now I realize the importance of every comment, every extra line, and how difficult things can get if the code is not properly structured.
Well as Sheldon once said "Change is the only constant" and I'll change my ways of writing code.
Thank you again.

@joeyparrish
Copy link
Member

Thank you for being this patient

No, thank you for persevering! We appreciate our contributors, and it can take time to learn how we do things.

Well as Sheldon once said "Change is the only constant"

Oh, I beg to differ: https://en.wikipedia.org/wiki/List_of_mathematical_constants 😁

@joeyparrish joeyparrish merged commit 0f00d1c into shaka-project:master May 11, 2021
@surajkumar-sk
Copy link
Contributor Author

@joeyparrish

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?
It's not a hurry but just wanted to know the reason for the delay.
Thank you.

@surajkumar-sk surajkumar-sk deleted the bufferfill branch May 11, 2021 19:54
@joeyparrish
Copy link
Member

The lines in PR #3373 are 412 but the changes are pretty small. Is there a reason for delaying the review?
It's not a hurry but just wanted to know the reason for the delay.

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.

@surajkumar-sk
Copy link
Contributor Author

Ohh. I understand. No problem.

@joeyparrish
Copy link
Member

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.

@surajkumar-sk
Copy link
Contributor Author

surajkumar-sk commented May 11, 2021

I was surprised too seeing the changes being merged without the bot run .
But i did run the linter before pushing changes.

shaka-bot pushed a commit that referenced this pull request May 11, 2021
PR #3392
Issue #3389

Change-Id: I425ccf7036416c185be141a181fabd26aa92e41e
@joeyparrish
Copy link
Member

Just fixed the failing test in 0a62396. Thanks again!

ismena pushed a commit that referenced this pull request May 17, 2021
PR #3392
Issue #3389

Change-Id: I425ccf7036416c185be141a181fabd26aa92e41e
ismena pushed a commit that referenced this pull request May 17, 2021
PR #3392
Issue #3389

Change-Id: I425ccf7036416c185be141a181fabd26aa92e41e
ismena pushed a commit that referenced this pull request May 17, 2021
ismena pushed a commit that referenced this pull request May 17, 2021
PR #3392
Issue #3389

Change-Id: I425ccf7036416c185be141a181fabd26aa92e41e
joeyparrish added a commit that referenced this pull request Jun 16, 2021
This reverts commit 9c0126b.

This should not have been cherry-picked to a release branch.
@github-actions github-actions bot added the status: archived Archived and locked; will not be updated label Jul 25, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose Buffer Fill Percent
2 participants