On Mon, 10 Oct 2005 18:17:30 +0300 (EEST)
Kai Vehmanen <kvehmanen@...> wrote:
> Hello,
Hey dude,
>
> some weeks ago, I wrote a skeleton version of a SDP A/V plugin for
> Farsight. I didn't commit it to the CVS, but you can see the diff at:
>
>
http://sofia-sip.sourceforge.net/misc/patch-fs-sdpav-plugin-skel-20051010.txt
>
> The main idea was to have "Local SDP" (description of what codecs the
> plugin instance is prepared to receive, codec params, which
> ports/addresses, etc) and "Remote SDP" (where to send media to, and
with
> which codecs, etc) properties and a new "update" signal to force
> reconfiguration of the plugin (after client app has modified the SDP
> properties).
>
> But, but, there are some problems with the design:
> - how to map connect(), state_change() etc FS protocol API
> methods to SIP call states (RFC3261, RFC3264)
The farsight plugin architecture wasent' really designed with SIP states
in mind. The idea was having generic a/v session states. I guess this
would correspond pretty we;; with SIP states, since it is a session
manager, but I don't know the details of SIP. If they both correspond
well together, we can simply change the core.
> - who owns the bin created by the FS plugin, how to update it
> during a sessions (especially: who can change the parent
> pipeline state?), do you need to always stop the pipeline
> before changing FS protocol plugin properties...?
If i remember correctly the core owns the bin. In theory you can change
the parent pipeline state from anywhere you want as long as you have
access to the bin. Now it comes down to a design decision, do we really
want to allow any protocol to mess with the pipeline state? Or keep
that to the core only?
> We discussed this on #farsight last week (02-04.10.), and RobT
> proposed the idea of moving SDP handling to a custom gstbin. sdpbin
> could be used by Farsight's sdpav (or some other) plugin, or directly
> by a client.
I am still not too sure about which option is best, but I think that
having it as a farsight plugin, or a gstreamer element would both work.
The disadvantage of using a gstreamer bin is that it will create the
actual stuff inside of it thus adding an extra level of encapsulation.
The problem with using a farsight plugin is that is does not completly
correspond with the core architecture. Nonetheless I can imagine a
dynamic sdpbin element doing a good job. If you want to take this path I
support it.
>
> sdpbin public interface
> ------------------------
>
> - a custom gstbin like
> gst-plugins-base-cvs/gst/playback/gstdecodebin.c
> - "Local SDP" and "Remote SDP" properties
> - perhaps a separate "Capabilities SDP" that describes
> the bin capabilities as SDP (without reserving any resources
> such as network sockets, codecs, etc --> purely based on
> information gathered from gst registry (Andre M. has already
> gst-0.9
> code for this in Tapioca)
Good.
>
> sdpbin components
> -----------------
>
> Simple ER'ish breakdown of sdpbin:
>
> 1:sdpbin <-> N:rtpbin
> 1:rtpbin <-> 1:recvpipe
> 1:rtpbin <-> 1:sendpipe
> 1:recvpipe <-> 1:pt-switch
> 1:pt-switch <-> N:{depayloader+decoder}
What is this pt-switch exactly? Are you referring to a muxer?
> 1:sendpipe <-> N:{encoder+payloader}
>
> The sdpbin would have X on-demand pads, on src+sink for each media.
>
> sdpbin details
> --------------
>
> The {local,remote} SDP properties cover one or more media (common case
> would be audio+video). There would be one rtpbin for each media, and
> each
> medium would have a send and receive chain of elements. The client
> would
> provide the SDPs, and connect the bin to its audio, video etc device
> elements (xvimagesink, alsasink, alsasrc, etc).
>
> Let's take an example SDP (check http://www.faqs.org/rfcs/rfc2327.html
> if
> you aren't familiar with SDP syntax):
>
> --cut--
> [local-SDP]
> v=0
> c=IN IP4 host1.foo.com
> m=audio 49170 RTP/AVP 0 97
> a=rtpmap:0 PCMU/8000
> a=rtpmap:97 iLBC/8000
> m=video 51372 RTP/AVP 31 32
> a=rtpmap:31 H261/90000
> a=rtpmap:32 MPV/90000
>
> [remote-SDP]
> v=0
> c=IN IP4 host2.bar.com
> m=audio 49920 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> m=video 53000 RTP/AVP 32
> a=rtpmap:32 MPV/90000
> --cut--
>
> The sdpbin would need to setup two rtpbins (for one audio, one for
> video),
> set "host2.bar.com" as the destination address for both rtpbins (port
> 49920 for audio, 53000 for video), prepare the send chains to use PCMU
> (audio, G.711) and MPV (video, MPEG1/2) codecs, set up pt-switches for
> audio and video (audio: PTs 0 and 97; video: PTs 31 and 32). And
> that's
> it, the session is setup. The rtpbins would take care of generating
> RTCP
> for audio and video sessions (as they are separate RTP sessions).
>
> Notes on modifying the bin
> --------------------------
>
> When client wants to change the SDP (add/remove media, change codec
> parameters, change the codec used for sending, etc), it would update
> the sdpbin properties.
>
> If the requested change can be done on-the-fly, the requested property
> will be updated as requested. If the change cannot be done without
> pausing/stopping the pipeline, the sdpbin can return an error so that
> the
> client knows it must stop the pipeline, and retry. This is one area
> that
> I'm not so sure about -- set_property() seems to return void, how to
> return the error?
The correct way would be to use the GstFlowReturn that can be returned
from several gst element functions such as the _chain function.
But i dont think it is right to let the client stop the pipeline and
retry, i think this can be done internally without needing to
stop/restart anything. One way of accomplishing that is using muxers. I
prefer the option of having all the elements already in the bin, and
having muxers to switch between codecs. The idea of dynamically
replacing/changing the elements inside the bin is just not right. If
this is to be done, the pipeline should be stopped and restarted, not
because of gstreamer limitations but because it dosen't seem like a
correct design.
> Also, could the bin find out the parent pipeline and
> actually stop it, reconfigure, and start playback again?
Again using muxers would not need any stoping, reconfiguring or playing.
With muxers you simply press a switch and everything is done on the fly
smoothly and cleanly. The muxer would output a different caps that the
rtpbin should be able to catch and switch payload types.
>
> Huh, that was a long post -- comments anyone? :)
Good luck! I am still uncertain as to what is the best option for me as
for my deadline. I might simply use FarsightSIP for now since I need my
stuff working FAST. Then i might join in the fun of the bin.
Laterz
Burger
|