1267492 - webm demuxer in rust

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Ralph Giles (:rillian)]

We'd like to implement a new webm demuxer in rust to replace nestegg.

There are been some issues adapting nestegg to support the MediaSource Extensions API. With that experience we expect to be able to design a new demuxer library that better meets our needs.

Comment 1

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Mass change P2 -> P3

Comment 2

[Eric Rahm [:erahm]]

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

Comment 3

[Bobby Holley (:bholley)]

Deian is also looking at wasmboxing nestegg.

Comment 4

[Matthew Gregan [:kinetik]]

(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.

Comment 5

[Bobby Holley (:bholley)]

(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.

Comment 6

[Ralph Giles (:rillian)]

: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.

Comment 7

[Jean-Yves Avenard [:jya]]

I would much prefer if we moved to libwebm first.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 9

[Matthew Gregan [:kinetik]]

(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.