I would like to announce that I’ve just published an implementation of RTP-over-QUIC as a set of GStreamer plugins. This comprises a set of plugins that enable QUIC transport using ngtcp2 as a backend and expose the QUIC stream interface through GStreamer pads, and a further set of plugins that use the QUIC transport plugins to carry RTP-over-QUIC.
The elements support sending RTP frames on one or multiple logical QUIC streams. The default is for all packets belonging to a given RTP session to be sent on the same QUIC stream. However, it is also possible to start a new QUIC stream for each media frame carried in the RTP session, or even to start a new stream at each media access boundary (e.g. Group of Pictures, GOP) if the pipeline encoder supports it.
Would the RTP-over-QUIC elements work on top of any kind of QUIC transport elements, or does it require close interaction with the QUIC implementation?
Yes, I was aware of the other elements but they didn’t really satisfy my use case, and I wanted to build something that I could freely experiment with.
My RTP-over-QUIC implementation currently requires close interaction with my quic transport elements, as I wanted the ability to more easily experiment with QUIC stream mapping, however in the future I suppose they could be made more generic.
I’m not sure how feasible this is, but something @Sanchayan and I have been talking about with the Rust plugin is that it would be nice to see if we can abstract out some of the interactions (queries/events for stream creation/closing, meta for buffer->stream/datagram mapping, etc.) and generalise so that the RoQ and QUIC transport implementations are fairly independent.
That goal seems less likely for MoQ (unless we can really generalise the QUIC API), since that needs at least one bidi stream.