WebTransport, WebCodecs, and WASM

[David P]

The following idea might be infeasible for the reimplementation work needed, and the likely poor performance, but I wonder...now that WebTransport joins WebCodecs and WASM in being supported on all major browsers, a great developer experience would be for WebRTC to be reimplemented using those standards as default implementations in the browser installs. Then if one wanted to change, say, noise suppression, one would override just the default WASM module with one's own (affecting just one's own page).

I expect it would have poor performance due to shuffling data between WASM modules...but is that so?

[Philipp Hancke]

Am Do., 30. Apr. 2026 um 01:53 Uhr schrieb David P <davidsw...@gmail.com>:

The following idea might be infeasible for the reimplementation work needed, and the likely poor performance, but I wonder...now that WebTransport joins WebCodecs and WASM in being supported on all major browsers, a great developer experience would be for WebRTC to be reimplemented using those standards as default implementations in the browser installs.

 

Well, the question is who is going to do the work and who is going to fund it.

In particular when there has not been enough promising signs for this working going back as far as https://webrtchacks.com/webassembly-experiments/

You may want to look at RtpTransport and surely you heard how MoQ solves everything.

Then if one wanted to change, say, noise suppression, one would override just the default WASM module with one's own (affecting just one's own page).

I expect it would have poor performance due to shuffling data between WASM modules...but is that so?

The amount of time spent on making sure WebRTC does not copy unnecessarily was huge.

Noise supression is unrelated to WebRTC though, current approaches seem to converge on audio worklets?

 

--

This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/CAE23trtUfQsUK2A9e5TZZ%3DRef6qex0p9zmecRw5HH6vdfCCY4Q%40mail.gmail.com.

[guest271314]

I think you are looking for Media Over QUIC https://github.com/moq-dev/moq. A whole buncha work has already been done. 

Just because it had not been done, yet, and somebody over in Google world said it could be done, I went ahead and implemented a TLS+QUIC+WebTransport server state machine written in Zig compiled to WASM using Direct Sockets UDPSocket https://github.com/guest271314/webtransport/tree/wasm. That's a WebTransport **server** _in the browswer_

I also transpiled that WASM code to JavaScript using wasm2js and wasm2lang https://github.com/guest271314/webtransport/tree/js. A JavaScript runtime agnostic WebTransport server implementation that can be run using Node.js, Deno, Bun, and txiki.js https://github.com/guest271314/webtransport/tree/runtime-agnostic.

WebTransport is non-trivial. Technically, you can use WebRTC Data Channel to establish a communication channel with an IWA window from ab arbitrary window/tab, then pipe that data to UDPSocket or TCPSocket for raw socket communication, and in theory run your own public server from a browser tab; do P2P stuff; etc. https://github.com/guest271314/sockets.

Depending on the application, WebSocketStream might be sufficient. It's easy to look at both WebRTC and QUIC and WebTransport being over-engineered, and not really needed for all applications.