[gst-devel] Re: [Farsight-devel] cvs-commit; sdpbin is back, maybe
Kai Vehmanen
kvehmanen at eca.cx
Fri Nov 18 16:06:02 CET 2005
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!
More information about the gstreamer-devel
mailing list