Repository navigation
[buffer-controller]: Error encountered while trying to append to the video SourceBuffer #4506
Description
Activity
+1 with the same issue here. Console log is almost the same - no reason to post the duplicate here.
The only addition is comment about this part of the config:{ maxBufferSize: 320 * 1000 * 1000, }
If you set
maxBufferSizemore than 180mb (approx) you get this error. Looks like there is some additional restrictions which do not allow appending to buffer longer than that.Also it does not look like the stream matters.
@dylanjha
Thank you for your reply, because of some privacy issues, I am not comfortable to upload the video of the client's problem.My guesses of the possibilities.
- When the .TS stream clip was transmitted under UDP protocol, there was a frame drop during the network transmission, resulting in a parsing error.
- when playing a VOD file, the VOD itself some frames have problems leading to playback errors.
- added a commit that references this issue
on Jul 11, 2022 Experiencing this issue on the latest build when scrubbing using Wowza nDVR.
Hi @invalidtask,
Please file a new issue with a sample stream and steps to the reproduce. And, be sure to indicate the version of the build in your bug report.
- added a commit that references this issue
on Dec 9, 2022 hls-demo.js:2422 The video playback was aborted due to a corruption problem or because the video used features your browser did not support - PIPELINE_ERROR_DECODE: Failed to send audio packet for decoding: {timestamp=4766788333 duration=21333 size=171 is_key_frame=1 encrypted=0}
Sounds like the issue is related to the content, not the buffer size. Cannot reproduce or further triage without a sample stream that can be used to reproduce the issue.
Same error here. If ever this could help:
- The same stream plays properly in Firefox and Chromium on a laptop running linux, but crashes in Firefox and Chrome on an Android phone (Pixel 5) after a very first second or so. It also plays well on another Android phone (Samsung) in Chrome. The same hls.js and server instance in all the tests, all in a local network.
- Error message from Firefox (Pixel 5):
[warn] > [buffer-operation-queue]: Unhandled exception executing the current operation [hls.light.min.js:1:222717] [error] > [buffer-controller]: Error encountered while trying to append to the audio SourceBuffer DOMException: An attempt was made to use an object that is not, or is no longer, usable- Error message from Chrome (Pixel 5):
[warn] > [buffer-operation-queue]: Unhandled exception executing the current operation [error] > [buffer-controller]: Error encountered while trying to append to the audio SourceBuffer DOMException: Failed to execute 'appendBuffer' on 'SourceBuffer': The HTMLMediaElement.error attribute is not null.- The behavior is the same for the both browsers on that device except for the ending. Firefox displays a fancy message "video can't be played because the file is corrupt" on a grayish background, while playback in Chrome just dumbly hangs.
- The stream is produced with a homemade implementation on yet another android phone (a relatively old Huawei) using its native android codecs (H.264 and AAC). Other streams coming from the same device lead to the same error. However, tons of other streams produced with the same app on other Android phones play smoothly in different mobile and desktop browsers with the rest being the same.
- All this is completely repeatable and reproducible from one stream to another when the same devices are used.
Hi @lnstadrum,
What happens when attempting to reproduce the issue against dev with #5731 here: https://bugfix-fix-media-source-clos.hls-js-4zn.pages.dev/demo/
Do you have a sample you could share?
Can you please share the Android and Chrome versions you used to reproduce the issue on Pixel 5?
Are there error messages preceding the one(s) that you shared? This error message would only be displayed after the media element is in an error state and/or video/MediaSource has been detached and is no longer usable. So it is likely that a decode error occurred before this error, which doesn't tell us much. The branch above should handle these kind of issues better so that the player does not try to access or append media after the MediaSource has been closed because of another error.
An attempt was made to use an object that is not, or is no longer, usable[warn] > [buffer-operation-queue]: Unhandled exception executing the current operation [hls.light.min.js:1:222717] [error] > [buffer-controller]: Error encountered while trying to append to the audio SourceBuffer DOMException: An attempt was made to use an object that is not, or is no longer, usableI had a similar issue, but my problem was the buffer size itself. Looks like the browser has some limitations on memory allocated for a single tab, so the player can't use more than that. If the buffer is too big, there are just not enough memory for it.
I've been playing with different streams - the lower the quality of the stream, the longer buffer length can be achieved (in seconds).
Hi @write2art,
I had a similar issue, but my problem was the buffer size itself. Looks like the browser has some limitations on memory allocated for a single tab, so the player can't use more than that. If the buffer is too big, there are just not enough memory for it.
If that was the case we should be seeing
QuotaExceededErrorDom exception on append, or an OOM error on the page.The full logs originally submitted follow a PIPELINE_ERROR_DECODE which suggests invalid media was appended putting the HTMLMediaElement and the browser MediaSource into an error state. A
SourceBuffer DOMExceptioncould also occur is the MediaSource was closed improperly or something tried to use it after closing it, rather than resetting the MediaSource.Please file new issues with full logs and steps to reproduce so that we can see if your particular path to getting a
SourceBuffer DOMExceptionis avoidable.In my condition, I'm trying to play video in chromium runtime of VSCode (for theme personalization, DON'T LAUGH AT ME):
And finally I found that it seems that the errors disappeared after I removed the audio from the video file.
FYI. https://superuser.com/questions/268985/remove-audio-from-video-file-with-ffmpeg
Closing as a sample has not been provided and addition comments reproducing the same error but for different reasons should be filed as new issues.
- added a commit that references this issue
on Sep 25, 2026
What version of Hls.js are you using?
1.1.4-0.canary.8150
What browser (including version) are you using?
Chrome Version 93.0.4577.82 (Official Build) (x86_64)
What OS (including version) are you using?
MAC OS (and other)
Test stream
No response
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
2.Waiting to play to 01:19:26
Expected behaviour
Handling exceptions
What actually happened?
Console reports error, player stuck
Console output
Chrome media internals output