QUIC Transport architecture for GStreamer

[Samuel Hurst]

Hi Sanchayan,

On 17/02/2023 04:21, Sanchayan Maity wrote:
> Hello,
> 
> Won't comment on the architecture bits, will leave that to the more
> experienced folks than me.
> 
> Have posted a MR for a quicsrc/sink to gst-plugins-rs which might interest
> you.
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1036
> 
> It is pretty basic right now but will be happy to work on improvements to
> perhaps enable some of the below use cases.

Thanks for pointing your work out, I'll try and take a look.

> On 23-02-16 14:55:49, Samuel Hurst via gstreamer-devel wrote:
>> However, in the case where you need to send and receive on the same QUIC
>> transport connection, this model seems to conceptually break down, as the
>> quicsrc and quicsink elements wouldn't be able to share the QUIC transport
>> connection, which doesn't make sense for a bidirectional media session such
>> as a video call:
>>
>> +--------+  +---------+        +----------+ +--------+
>> | udpsrc +-->         |        |          +-> dynudp |
>> +--------+  |         +->      |          | |  sink  |
>>             | quicsrc |  ... --> quicsink | +--------+
>> +--------+  |         +->      |          | +--------+
>> | dynudp <--+         |      -->          <-+ udpsrc |
>> |  sink  |  |         |        |          | +--------+
>> +--------+  +---------+        +----------+
> 
> Was wondering if something like the socket property on udpsink/src or agent on
> nicesrc/sink could work here.

I had considered just sharing sockets between the udp elements, but I 
can imagine this just gets messy when you have both listening to the 
same socket - which of the quicsrc and quicsink is supposed to handle 
that specific packet?

>> In addition, any bidirectional streams would need sink pads on the quicsrc
>> element to pass messages back, which sounds quite messy to me.
> 
> Hmm not sure about this with the above approach.

Yes, that's what puts me off going down this route. My intention is to 
try and keep an eye on the output of the MoQWG [1], which may involve 
having to use bidirectional streams at some point in the future, and it 
doesn't make sense precluding such use cases this early on.

Best regards,
-Sam

[1]: https://datatracker.ietf.org/group/moq/about/