[gst-devel] Re: [Farsight-devel] cvs-commit; sdpbin is back, maybe

[Kai Vehmanen]

Hello all,

On Wed, 16 Nov 2005, Kai Vehmanen wrote:
> Now I had almost given up on the sdpbin design, but decided to still continue 
> a bit. I'll continue this work at least for a while to see how far this goes.

here's the latest news from my gstsdpbin efforts. I now tagged 0.3 of 
gstsdpbin and pushed the patches to the gst-plugins-farsight darcs repo at:

   http://projects.collabora.co.uk/darcs/farsight/gst-plugins-farsight/

Now the test app (test_sdpbin.c) can do:

- runs a full-duplex test with GSM codec and rtpbin
- starts with playing sine-tone (sinesrc) out to the soundcard, but
   when first RTP packet is received, it switches dynamically to RTP
   decoding (using rtpdemux)
- the code actually works, although you need to patch jrtplib to
   not drop your packets (as jrtplib is asymmetric, packets sent
   to localhost will have srcport!=dstport, which causes jrtplib
   to think that incoming packets are from someone else but with
   same SSRC (=collision), and leads it to change to a new sending SSRC
     => RTP over loopback only works by accident, and only for a short while!
- I'm still using hardcoded GSM-codec in all places, there's
   now some code in gst/sdpbin/gstrtpcodecinfo.h (based on tapioca
   code), but it needs to be improved and glued to sdpbin

But although the code now works, there's still a lot to be done. The 
development has been painfully slow. I've spent much time debugging weird 
problems with ghostpads, trying to use REQUEST_PADS, then SOMETIMES_PADS, 
and now ALWAYS_PADS. But now it's starting to feel that sdpbin really is 
doable after all. Question now is: is this a sane middleware layer for 
applications wishing to use gstreamer for VoIP and streaming, or would 
apps prefer to just manage the low-level gst components (codec, 
packetizers, etc) themselves..?

Pros:
- easier for apps (on-the-fly SDP updates, mode changes, etc can
   be all hidden from the sdpbin user)
- sdpbin knows sufficient information about the elements, so
   it can do updates/reconfiguration as necessary (with possibly
   sending reconfig events to application if nothing else can
   be done)
- does not expose any RTP stuff to the application
- uses the well-known gst/gobject interface (compared to something
   like sofsip-cli-gst/src/ssc_media.h)

Cons:
- debugging; I'm constantly managing to get the GstBin internals
   into states that freeze all processing; for example the
   PLAYING->PAUSED->PLAYING trick works fine with rtpdemux and
   its test app, but fails horribly with sdpbin due to some errors
   in udpsrc .. I have no idea whether I'm doing something wrong
   or there's a bug in gst, or some of the elements I have in the bin);
   probably it's just me being dumb, but that doesn't make it any
   less painful ;)
- client still has to do some SDP processing (pass different parts of SDP
   session to different sdpbins -> audio and video information to
   different sdpbins, and later merge these into single audio+video SDP for
   signaling purposes; having these all in the same pipeline is just
   too complex)

I guess those were the main points. I guess great deal of the 
"sdpbin-pain" comes from the weird configurations you get with rtpbin in 
the mix:

udpsrc -> rtprecv \          / rtpsend -> dynudpsink
                   +- rtpbin +
                   ÃÃ^         +- rtpdemux -> depay -+
                   |                               |
 		  |                            decoder
                payloader                          |
                   |                               v
alsasrc ---->  encoder                         alsasink

As these are all in the same pipeline, gst's clock selection algorithm
will traverse to alsasrc for the pipeline clock. The actual data flows 
from "alsasrc => dynudpsink" and "udpsrc => alsasink". Also there's an 
additional pair of udpsrc+dynudpsink for RTCP reception and transmission, 
but I left these out of the diagram.

Of this, sdpbin currently manages everything except alsasrc and alsasink. 
To add to the confusion, rtpdemux doesn't have a sink pad until it sees 
the first RTP packet (rtpdemux creates a new pad for each payload-type 
that is transmitted in the same session, i.e. same socket connection). 
During this bootstrap phase, "rtpdemux -> depay" link does not exist, and 
"depay -> decoder" is replaced by "sinesrc+identity" in the current sdpbin 
test version.

PS gstrtp{bin,demux,recv,send} and gstsdpbin can all be found
    from the gst-plugins-farsight repo...

-- 
  http://www.eca.cx
  Audio software for Linux!