[gst-devel] RTP Caps,base payloader and jrtplib
wingo at pobox.com
Tue Nov 8 07:25:38 CET 2005
(Please trim your replies. Thanks. :)
I'm replying for Thomas because he's stressing out a bit now. We're
entering a bit of a crunch time for Flumotion and it's taking a bit of
time, not to mention the biweekly releases leading up to an eventual
GStreamer 0.10.0, the stress involved in producing a stable API, docs
work that everyone wants but no one does, etc. So from our side RTP
isn't getting as much attention as we'd like. That will change in a few
weeks, but sorry if Fluendo folk are a bit preoccupied right now.
On Tue, 2005-11-08 at 15:54 +0100, burgerman at users.sourceforge.net
> > We're not using rtpbin. What RTSP element ? I'm not using a GStreamer
> > RTSP element.
> Maybe you should start using it huh :)
Ignoring the flippant tone :), Thomas started on a python-based path.
Different from what you all are doing; not saying it's better or worse
but he prefers to continue in python at the moment.
> What is not clear is why are these values in the CAPS? why are they
> needed to be in the caps? The client app can retreive them directly
> from the payloader so why in the caps?
You could say the same thing about streamheaders in vorbis... but my ral
answer is this:
> What we have here is a simple case of duplicate functionality.
It's not that terrible :) Functionality should be factored out,
abstracted, etc when we're sure where it should go and what the right
solution is. RTP with GStreamer is in an experimental state right now
though; it's fine to have multiple lines going out to explore the space.
rtpbin is one way to do it. There are others and that's fine too.
Duplicating the 50 lines of basertppayload in rtpbin is worth the
architectural flexibility in the rtp stack.
More information about the gstreamer-devel