[Bug 748723] dtlssrtpdec: Merges RTP and RTCP into the same stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748723

--- Comment #5 from Patrik Oldsberg <poldsberg at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #4)
> (In reply to Patrik Oldsberg from comment #2)
> > If I remember correctly, the only reason for the current design was that it
> > made integration with rtpbin a tiny bit more simple when using rtcp mux. If
> > the incoming stream may or may not be using rtcp mux, then you'd have to set
> > up a funnel for rtcp after the dtlssrtpdec bins anyway.
> 
> You would get RTP/RTCP separated here, and then have another dtlssrtpdec
> that outputs RTCP. So you would then link the RTP pad to the RTP part of
> rtpbin, and the two RTCP pads to a funnel and then to the RTCP part of
> rtpbin.
> 
> This way you would only have a single funnel instead of two, and that funnel
> would be at a low-bandwidth stream. Due to having to send all sticky events
> again on stream changes, it's better to have the funnel at a low-bandwidth
> stream.

This is the tradeoff I'm talking about, extra funnels inside the elements vs
having to set up an extra funnel after the elements. The difference is tiny
either way. But I agree that's it's probably worth leaving de decision to the
application.

> > I guess it doesn't really matter that rtpbin has to split up the streams
> > again, since the check is always done anyway? (haven't actually had a look
> > at the code, just assuming that's how it works).
> 
> The splitting in rtpbin is basically to try if it's RTP... and if not relay
> the packet to the RTCP handling instead. So it's additional overhead, but
> not much.
> 
> > So the pro with the current design is that it makes a specific (but quite
> > common) use case a bit more simple to implement for the application, while
> > the con is that we are sacrificing some cycles by passing the buffers
> > through a funnel.
> 
> Not sure how it makes anything more simple as you need another funnel anyway
> if you want to handle RTCP-mux and separate RTCP. The only thing it makes
> easier is if you actually know that you have RTCP-mux and nothing else. If
> you don't, you will have two funnels and quite a bit more overhead, see
> above ;)

It's more simple for the application, since you just plug each dtlssrtpdec into
one rtp/rtcp pad each on rtpbin.

> We'll go ahead then and keep them separated, I'll also provide a patch for
> OpenWebRTC before changing it.

Ok, thanks :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.