> a well-defined media transfer protocol will eventually emerge
Until then interacting with a 'WebTransport Media API' involves me running code distributed by the person running the API. With WebRTC I can exchange a Offer/Answer and then have a bi-directional media session. I appreciate that these lower level APIs help companies that need the flexibility. I worry that the complexity will lock out Open Source and smaller companies. Smaller companies are going to have to figure out things took years to solve with WebRTC. Stuff like
* Congestion Control/Error Correction trade-offs and Latency
* Simulcast
* Re-negotation
* Rollbacks
* Capability Negotation
I was always a big fan of ORTC. Give flexibility to the power users, but give an even playing field to small players.
> RTP over WebTransport datagrams
I don't feel strongly about QUIC vs S(RTP). WebTransport doesn't force RTP, so it doesn't help unless I control everything. Bridging will get a lot harder. Right now it is nice that Reports/NACKs/etc.. can cross protocols.
Until then interacting with a 'WebTransport Media API' involves me running code distributed by the person running the API. With WebRTC I can exchange a Offer/Answer and then have a bi-directional media session. I appreciate that these lower level APIs help companies that need the flexibility. I worry that the complexity will lock out Open Source and smaller companies. Smaller companies are going to have to figure out things took years to solve with WebRTC. Stuff like
* Congestion Control/Error Correction trade-offs and Latency
* Simulcast
* Re-negotation
* Rollbacks
* Capability Negotation
I was always a big fan of ORTC. Give flexibility to the power users, but give an even playing field to small players.
> RTP over WebTransport datagrams
I don't feel strongly about QUIC vs S(RTP). WebTransport doesn't force RTP, so it doesn't help unless I control everything. Bridging will get a lot harder. Right now it is nice that Reports/NACKs/etc.. can cross protocols.