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

Allow configuration of backwards buffer #853

Closed
larserikgk opened this issue May 27, 2020 · 4 comments
Closed

Allow configuration of backwards buffer #853

larserikgk opened this issue May 27, 2020 · 4 comments

Comments

@larserikgk
Copy link

larserikgk commented May 27, 2020

Description

This is more a feature request/ question than anything else. Is there any reason why the back buffer which is calculated should not be configurable?

export const safeBackBufferTrimTime = (seekable, currentTime, targetDuration) => {
// 30 seconds before the playhead provides a safe default for trimming.
//
// Choosing a reasonable default is particularly important for high bitrate content and
// VOD videos/live streams with large windows, as the buffer may end up overfilled and
// throw an APPEND_BUFFER_ERR.
let trimTime = currentTime - 30;
if (seekable.length) {
// Some live playlists may have a shorter window of content than the full allowed back
// buffer. For these playlists, don't save content that's no longer within the window.
trimTime = Math.max(trimTime, seekable.start(0));
}
// Don't remove within target duration of the current time to avoid the possibility of
// removing the GOP currently being played, as removing it can cause playback stalls.
const maxTrimTime = currentTime - targetDuration;
return Math.min(maxTrimTime, trimTime);
};

From what I can tell, the back buffer will be 30s backwards in all but the edge cases described in the code above. I assume that the main objective here is to not remove the chunk which is currently being played from the buffer?

I'm having multiple issues with playing high bitrate 4k in videojs, and having configurable back buffer would mitigate some of the issues related to the max buffer size of MSE. Being able to set it the same way we can set GOAL_BUFFER_LENGTH would be helpful. As an example we currently have a video with 10s chunks of ~20MB each. With videojs keeping 30s back buffer and attempting to load 30s of forward buffer we quickly end up overflowing the MSE buffer.

Sources

All sources with a high enough bitrate.

Steps to reproduce

  1. Play a sufficiently high bitrate 4k video with videojs
  2. Observe the "Quota exceeded" error message caused by MSE buffer overflow.

Results

Expected

Flawless playback of high bitrate 4K video.

Error output

"Quota exceeded" error message.

Additional Information

This issue is loosely related to other 4K playback issues:

videojs-http-streaming version

videojs-http-streaming 1.13.3

videojs version

video.js 7.7.6

Browsers

  • Universal

Platforms

  • Universal

Other Plugins

  • N/A

Other JavaScript

  • N/A
@welcome
Copy link

welcome bot commented May 27, 2020

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

@gkatsev
Copy link
Member

gkatsev commented May 27, 2020

This would be a good option to have, thanks for mentioning it. Would you be interested in making a PR for this?

@larserikgk
Copy link
Author

I'll give it a try. Should this new constant be stored in http-streaming/src/config.js like the rest of the configurable but unsafe constants?

@gkatsev
Copy link
Member

gkatsev commented Jun 19, 2020

Fixed via #854 and 8c96e6c. It'll get released with VHS 2.1, which should happen in the next week or two.

@gkatsev gkatsev closed this as completed Jun 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants