[gst-devel] rtp - mux or not to mux?

[Kai Vehmanen]

Hi,

On Wed, 2 Nov 2005 burger at speedy.org wrote:

>> 1) rtpdemux -> 1:N demux element (like oggdemux for example)
> Yes this approach is the one that comes to mind first. It is simple and
> robust, but with big SDP caps lists, it can get pretty big too. I don't
> dislike this method and I think it would work fine.

yes, gst already has >5 codecs which can be used with RTP (and more to 
come), and in the common case they would all be utilized when making calls 
(you want to offer everything you have to make sure some common codecs are 
found). Hmm, but as long as the unsused elements are not consuming CPU
resources, I think it's ok...

>> 2) rtp-switcher -> 1:1 element that can decode and depacketize multiple codecs
> This can also be accomplished in many ways, but it is more complicated
> but I don't know if it is necessarily more elegant. One way of doing is
> to have an element that contains the SDP info needed to map dynamic
> payload types to their respective element, as well as the capability to
> know what element (depayloader/decoder) it needs for that payload. Then
> it can read the payload type on each RTP packet, figure out if it
> changed. If it has changed, then it can modify the pipeline accordingly
> on the fly. I don't know of any good examples for this, but I don't see
> why it wouldn't be possible.

Yes, the more I think about it, a mix of (1) and (2) seems like the
best place to start.

RobT proposed that the demux could signal which pt is active, and
the mux (at the end of the decoders) would catch the signal and handle
only packets from the active pt. This is a nice optimization to the (1)
approach. I also found gststreamselector.c (from plugins-base), which
is a good example of N:1 switching.

MiskaX proposed similar idea to yours: just check what the incoming
PT is and reconfigure the rest of the elements as needed. The downside
is that (I think) you need to stop the pipeline while you reestablish
the links (and possibly create new elements). For example Farsight's
current plugin interface doesn't really allow this, as the plugin
doesn't have a pointer to the parent pipeline.

Oh well, I guess the only way to really find out what works is to
implement at least one of the options.

> Indeed currently the jitter buffer is in the depayloader, meaning each
> codec would have a different one. I'm sure workarounds can be
> accomplished for this, such as having the depayloader push out all the
> buffers before dying. I think we can worry about this after something
> is actually done, don't think it's enough to warrant changes in design
> for this.

Sure, this sounds like a reasonable plan.

--
  under work: Sofia-SIP at http://sofia-sip.sf.net