8000 `Uncaught Error: Current Matroska cluster exceeded its maximum allowed length` when muxing both Audio and Video · Issue #56 · Vanilagy/webm-muxer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Uncaught Error: Current Matroska cluster exceeded its maximum allowed length when muxing both Audio and Video #56

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.

Sign up for GitHub

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

Jump to bottom
Closed
marstamm opened this issue Mar 12, 2025 · 3 comments
Closed

Uncaught Error: Current Matroska cluster exceeded its maximum allowed length when muxing both Audio and Video #56

marstamm opened this issue Mar 12, 2025 · 3 comments

Comments

@marstamm
Copy link

Problem

When I want to mux both Audio and Video, I run into Uncaught Error: Current Matroska cluster exceeded its maximum allowed length of 32768 milliseconds. In order to produce a correct WebM file, you must pass in a key frame at least every 32768 milliseconds. even if keyframes are placed correctly at or before the 32768ms mark.

Cause

The writing logic falsely assumes that the first chunk in a Cluster will always be a video frame. This can cause an audio chunk (which are always keyframes) to extend the size of the current Cluster:

webm-muxer/src/muxer.ts

Lines 453 to 457 in 40aa073

// Write all audio chunks with a timestamp smaller than the incoming video chunk
while (this.#audioChunkQueue.length > 0 && this.#audioChunkQueue[0].timestamp <= videoChunk.timestamp) {
let audioChunk = this.#audioChunkQueue.shift();
this.#writeBlock(audioChunk, false);
}

Example:

We have Audio chunks with the timestamps (ms):

  [ 
    0,
    33000 // <-- need to be written in second cluster
  ]

With Video Frames at:

  [ 
    0,
    33001 // <-- will create second cluster
  ]

At the time we encode the second video frame, currentCluster is still the first cluster we created. The Audio chunk is queued. Since we encode all Audio chunks before the Video chunk, we try to add the audio chunk to the wrong cluster.

Proposed fix

Allow creation of new Chunks from queued Audio chunks, even if we also mux video in the same file.
@marstamm marstamm mentioned this issue Mar 12, 2025
Closed
@ZoranRavic
Copy link

That error message shouldn't even exist. See #58

@Vanilagy
Copy link
Owner

Hey @marstamm, thank you for the issue. You're right that audio chunks must also be able to start a new cluster. An upcoming version of this library that I have in the works already has this behavior. But otherwise, @ZoranRavic is right with his point: This error message is not required. Matroska/WebM does just fine with clusters that begin with delta frames. It's just nice when clusters begin with key frames, and I'll keep making it so that they typically do, but when they become too long (>32 seconds), then it should just automatically spill over into a new cluster that can start with a video delta frame. I will implement the fix for #58.

@Vanilagy
Copy link
Owner

@marstamm Try again with the new version 5.1.0. This error is now gone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(muxer): allow clusters to be created from Audio chunks marstamm/webm-muxer
3 participants
@Vanilagy @ZoranRavic @marstamm
0