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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(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.

> 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 ;)



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

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