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

When listing segments needed, stop filtering the current range #1421

Merged
merged 1 commit into from
Apr 3, 2024

Conversation

peaBerberian
Copy link
Collaborator

While debugging an issue, I noticed that for optimization purposes we filtered already-loaded segments' metadata so we only considered those of the currently-needed time range before giving it to both the getNeededSegments function, which lists the segments the RxPlayer needs to download, and the checkForDiscontinuity function, which checks if a discontinuity is imminent.

This is problematic since we added the maxVideoBufferSize option (so a long time ago!), as that option is also exploited in getNeededSegments yet needs to know ALL of the buffered segments so it can estimate the amount of video data currently retained by the browser's video buffer - and not just those in the currently-needed range. So it seems that the maxVideoBufferSize-linked estimate could have been inexact most of the time here.

While debugging an issue, I noticed that for optimization purposes we
filtered already-loaded segments' metadata so we only considered those
of the currently-needed time range before giving it to both the
`getNeededSegments` function, which lists the segments the RxPlayer
needs to download, and the `checkForDiscontinuity` function, which
checks if a discontinuity is imminent.

This is problematic since we added the `maxVideoBufferSize` option (so a
long time ago!), as that option is also exploited in
`getNeededSegments` yet needs to know **ALL** of the buffered segments
so it can estimate the amount of video data currently retained by the
browser's video buffer - and not just those in the currently-needed
range. So it seems that the `maxVideoBufferSize`-linked estimate could
have been inexact most of the time here.
@peaBerberian peaBerberian added the bug This is an RxPlayer issue (unexpected result when comparing to the API) label Apr 3, 2024
@peaBerberian peaBerberian added this to the 4.1.0 milestone Apr 3, 2024
@peaBerberian peaBerberian added the Performance checks Performance tests are run on this issue / PR label Apr 3, 2024
@peaBerberian peaBerberian merged commit 75eb852 into dev Apr 3, 2024
8 checks passed
@peaBerberian peaBerberian deleted the fix/maxVideoBufferSize-optimist branch July 26, 2024 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This is an RxPlayer issue (unexpected result when comparing to the API) Performance checks Performance tests are run on this issue / PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants