Ralph, would rust-av's matroska project cover this?

Deian is also looking at wasmboxing nestegg.

(In reply to Bobby Holley (:bholley) from comment #3)

Deian is also looking at wasmboxing nestegg.

nestegg's API isn't suitable for a post-MSE world, so while there's some value in wasmboxing the existing library, that's not really where we want to end up.

(In reply to Matthew Gregan [:kinetik] from comment #4)

(In reply to Bobby Holley (:bholley) from comment #3)

Deian is also looking at wasmboxing nestegg.

nestegg's API isn't suitable for a post-MSE world, so while there's some value in wasmboxing the existing library, that's not really where we want to end up.

Wasmboxing it will probably only take a day or so, so unless we have near-term plans for the Rust rewrite, it's still likely worth doing.

:erahm that looks like a good place to start, since it's following the draft RFC. I notice the readme disclaims support for VP8/9 so some work to support those (and possibly the webm doctype) is probably necessary.

I would much prefer if we moved to libwebm first.

(In reply to Matthew Gregan [:kinetik] from comment #4)

nestegg's API isn't suitable for a post-MSE world, so while there's some value in wasmboxing the existing library, that's not really where we want to end up.

Out of curiosity why isn't it suitable?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #8)

Out of curiosity why isn't it suitable?

It expects the data to be a contiguous stream representing a complete valid WebM file and the API presents the result at a fairly high level, so handling chunks split at arbitrary offsets as you might see from MSE is awkward. To deal with that, we made the parser partially resumable (with special end-of-stream handling) during track demuxing. We also used a second WebM parser (WebMBufferedParser, only handles a small subset of WebM) for building the timestamp<->byte offset mapping for chunks appended via an MSE SourceBuffer since nestegg 's design wasn't easily adapted for that task.