Refactor buffer length calculation for HLS player #7455
Conversation
Updated max buffer length calculation based on bitrate and added clamping between 6s and 60s. Removed hardcoded buffer length limits for specific browsers.
Cloudflare Pages deployment
|
|
Based on observations, the modified network resources are now being utilized more efficiently. The previous 6-second limitation caused bubbles in the buffering process, resulting in the network being idle or restricted approximately 20% of the time. This means that after the modification, the player's requirements for the network environment will be reduced to some extent. |
…lculation. The video buffer length will be calculated based on the actual video bitrate`options.mediaSource?.MediaStreams?.find(s => s.Type === 'Video')?.BitRate`, and will no longer depend on the client's maximum bitrate `playbackManager.getMaxStreamingBitrate(this)`.
There was a problem hiding this comment.
Pull request overview
This PR refactors the HLS player buffer length calculation from a browser-specific hardcoded approach to a dynamic calculation based on video bitrate. The change removes special handling for Chrome, Edge Chromium, and Firefox browsers with high bitrate streams, replacing it with a formula that calculates buffer length from a 50 MiB maximum buffer size divided by the stream's bitrate, clamped between 6 and 60 seconds.
Key Changes:
- Replaces fixed 30s buffer (or 6s for high-bitrate streams on specific browsers) with dynamic calculation:
50 MiB / bitrate - Removes browser-specific conditions for Chrome, Edge Chromium, and Firefox
- Adds universal clamping between 6s and 60s for all scenarios
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| maxBufferLength = 6; | ||
| } | ||
| // Dynamic buffer length based on bitrate | ||
| // Limit max buffer size to 50MB (50 * 1024 * 1024 * 8 bits = 419430400 bits) |
There was a problem hiding this comment.
The comment states the max buffer size is 50MB = 419430400 bits, but the actual calculation is 50 * 1024 * 1024 * 8 = 419430400 bits. This is correct and equals exactly 400 Mebibits or 50 Mebibytes. However, for clarity, consider using more standard notation such as "50 MiB" instead of "50MB" since you're using binary multipliers (1024) rather than decimal (1000), or state it as "400 Mb" to match the bits calculation.
| // Limit max buffer size to 50MB (50 * 1024 * 1024 * 8 bits = 419430400 bits) | |
| // Limit max buffer size to 50 MiB (50 * 1024 * 1024 bytes = 419430400 bytes = 419430400 * 8 bits) |
| // Dynamic buffer length based on bitrate | ||
| // Limit max buffer size to 50MB (50 * 1024 * 1024 * 8 bits = 419430400 bits) | ||
| const maxBufferSizeBits = 50 * 1024 * 1024 * 8; | ||
| const bitrate = options.mediaSource?.MediaStreams?.find(s => s.Type === 'Video')?.BitRate || 8000000; // Default 8Mbps |
There was a problem hiding this comment.
The fallback bitrate of 8000000 won't be used if BitRate is explicitly 0 or a very small positive number (e.g., if the stream metadata is malformed). When BitRate is 0, the division will result in Infinity, which gets clamped to 60s. For very small bitrates (e.g., 1000 bits/s), the buffer would be extremely large (419430 seconds) before being clamped to 60s.
Consider adding a check to handle edge cases where BitRate exists but is 0 or unreasonably small (e.g., less than 100kbps). For example, you could apply the fallback when BitRate is falsy OR less than a minimum threshold like 100000 (100kbps).
| const bitrate = options.mediaSource?.MediaStreams?.find(s => s.Type === 'Video')?.BitRate || 8000000; // Default 8Mbps | |
| const rawBitrate = options.mediaSource?.MediaStreams?.find(s => s.Type === 'Video')?.BitRate; | |
| let bitrate = Number(rawBitrate); | |
| // Fallback to default 8Mbps if bitrate is missing, not finite, or unreasonably low (< 100kbps) | |
| if (!Number.isFinite(bitrate) || bitrate < 100000) { | |
| bitrate = 8000000; | |
| } |
| // Dynamic buffer length based on bitrate | ||
| // Limit max buffer size to 50MB (50 * 1024 * 1024 * 8 bits = 419430400 bits) | ||
| const maxBufferSizeBits = 50 * 1024 * 1024 * 8; | ||
| const bitrate = options.mediaSource?.MediaStreams?.find(s => s.Type === 'Video')?.BitRate || 8000000; // Default 8Mbps | ||
| let maxBufferLength = Math.floor(maxBufferSizeBits / bitrate); | ||
| // Clamp buffer length between 6s and 60s | ||
| maxBufferLength = Math.max(6, Math.min(60, maxBufferLength)); |
There was a problem hiding this comment.
…n the client's maximum bitrate to accommodate transcoding to a lower bitrate.
|
|
@thornbill Hi! I noticed you made the last commit here. Is there a more accurate way to get the current stream's bitrate than the current method? Because if transcoding occurs due to unsupported encoding, I don't know where to get the actual bitrate. |
2 participants
Updated max buffer length calculation based on bitrate and added clamping between 6s and 60s. Removed hardcoded buffer length limits for specific browsers.
Changes
Updated max buffer length calculation based on bitrate and added clamping between 6s and 60s. Removed hardcoded buffer length limits for specific browsers.
Issues
Fix #5246
Fix #15787