I'm not sure why you say "it is not." We have a working MoQ demo running already on https://quic.video that includes a Rust-based relay server and a TypeScript player. The BBB demo video is being ingested using a Rust-based CLI tool I wrote called moq-pub which takes fragmented MP4 input from ffmpeg and sends it to a MoQ relay.
You can also "go live" from your own browser if you'd like to test the latency and quality that way, too.
[1]: https://www.ietf.org/archive/id/draft-michel-quic-fec-01.htm...
> I'm not sure why you say "it is not."
Pardon my ignorance it looked like it isn’t replacing WebRTC entirely yet, but glad I was wrong, I never tried anything QUIC for media related, would love to try the MoQ tool you did, and like the fact it’s rust based too as the one I did was written in rust. I will give it a test for sure, it’s been two years and I wasn’t following any updates so hopefully there’s an improvement compared what it was back then.
> takes fragmented MP4 input from ffmpeg and sends it to a MoQ relay.
Just a quick question, is ffmpeg a “requirement” per se for that CLI tool? As I remember I had to ditch ffmpeg in favor of gstreamer since the former one was eating up a lot of resources compared to Gstreamer, and it was crucial issue since the server was basically an SBC on a flying drone.
(1) https://tamim.io/professional_projects/nerds-heavy-lift-dron...
Separately, I've been working on a wrapper library for moq-rs that I've been calling 'libmoq'. The intent there is to provide a C FFI that non-Rust code can link against. The first integration target for libmoq is ffmpeg. (I have a few bugs to work out before I clean up and shout about that code, but it does mostly work already.)
I gave a presentation about some of this work last week at Demuxed, but the VoDs probably won't be available on YouTube until Decemberish.
Also, I understand the gstreamer project has better support for Rust so I'll be looking at that soon, too.
I stumbled upon a MoQ video by kixelated a couple months ago and have been meaning to give the above a try, but haven't gotten around to it yet so not sure if it will do the trick.
Eventually https://www.youtube.com/@Demuxed will have the edited VoDs for Demuxed 2023 available for free. Usually those go up around December-ish.
I also posted my slides on LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7124766...
I could see how WebRTC out of the box would perform poorly. It wants to NACK + delay to give a good 'conferencing experience'.
I bet with FlexFEC [0] and playout-delay [1] you would get the behavior you were looking for. The sender would have to be custom, but the receivers (browsers) should just work! If you are interested in giving it a shot again would love to help :)
[0] https://datatracker.ietf.org/doc/html/rfc8627
[1] https://webrtc.googlesource.com/src/+/main/docs/native-code/...
> I bet with FlexFEC [0]
The previous draft (1) of this was my basis when I did the FEC sender. I didn’t manage to have it streamed 4K into the browser though, my client was OBS with gstreamer as it was far more performant than a browser in my tests, have you/any demo you did that I can try to stream it into the browser? That would be really major improvement! And appreciate the help, O would definitely give it another shot!
(1) https://datatracker.ietf.org/doc/html/draft-ietf-payload-fle...
If you prefer discord there also is a dedicated space for ‘real-time broadcasting’ https://discord.gg/DV4ufzvJ4T
To be fair, video calling is an incredibly important use case and I'm glad it can be done in the browser. I just hope that WebRTC really can someday be replaced by composing multiple APIs that are much smaller in scope and more flexible to allow for use cases other than essentially Zoom and Stadia.
Yeah, Google bought GlobalIPSound, dumps the source code to w3c as a standard.