I am heavily biased toward WebRTC. Here is my take on it though!
> It's incredibly complex as a specification
What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations.
QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does.
> has limitations and numerous issues that set limits in how scalable it can be
https://phenixrts.com/en-us/ does 500k viewers. I don't think anything about WebRTC makes it unscalable.
-----
IMO the future is WebRTC.
* Diverse users makes the ecosystem rich. WebRTC supports Conferencing, embedded, P2P/NAT Traversal, remote control... Every group of users has the made the ecosystem a little better.
* Client code is minimal. For most users they just need to exchange Session Descriptions and they are done. You then have additional APIs if you need to change behaviors. Other streaming protocols expect you to put lots of code client side. If you want to target lots of platforms that is a pretty big burden.
* Lots of implementations. C, C++, Python, Go, Typescript
* The new thing needs to be substantially better. I don't know what n is, but it isn't enough to just be a little better then WebRTC to replace it.
> It's incredibly complex as a specification
What is complex about it? I can go and read the IETF drafts, webrtcforthecurious.com, https://github.com/adalkiran/webrtc-nuts-and-bolts and multiple implementations.
QUIC/WebTransport seems simple because it doesn't address all the things WebRTC does.
> has limitations and numerous issues that set limits in how scalable it can be
https://phenixrts.com/en-us/ does 500k viewers. I don't think anything about WebRTC makes it unscalable.
-----
IMO the future is WebRTC.
* Diverse users makes the ecosystem rich. WebRTC supports Conferencing, embedded, P2P/NAT Traversal, remote control... Every group of users has the made the ecosystem a little better.
* Client code is minimal. For most users they just need to exchange Session Descriptions and they are done. You then have additional APIs if you need to change behaviors. Other streaming protocols expect you to put lots of code client side. If you want to target lots of platforms that is a pretty big burden.
* Lots of implementations. C, C++, Python, Go, Typescript
* The new thing needs to be substantially better. I don't know what n is, but it isn't enough to just be a little better then WebRTC to replace it.