[gst-devel] RTP Client sussystem design.

[Ramón García]

One posible solution is that the RTP element loads a
special plugin for the decoding. That is, it loads a
normal gstreamer plugin that provides an factory that
provides GstRtpDecoder objects instead of GstElement
objects.

I have been looking for information in other
implementations solve the problem.

In Windows XP, the approach is exactly the same as the
original proposed here, that is a general rtp parsers
produces packets of specific type, and then a codec
specific parser does the rest.

In Java Media Framework (reportedly very well
designed) they used the modular approach suggested in
this message in JMF 1.0, but they switched to element
separation with JMF 2.0. Perhaps there are non-obvious
problems that are solved with element separation, or
perhaps they find element separation more elegant.

Ramon




 --- Ronald Bultje <rbultje at ronald.bitfreak.net>
escribió: > Hey,
> 
> Great work, both of you!
> 
> On Thu, 2003-09-04 at 14:29, Angel Carpintero wrote:
> >  v4lsrc ! mpeg4encode ! rtp-mpeg4enc ! rtp-parse !
> rtp-control ! udpsink
> 
> *yikes*. Don't create an element explosion! I
> understand how convenient
> it is to put each function in a separate element
> (...), but that's
> really no use for application programmers. There
> must be a clear and
> good reason to make something a separate element
> instead of putting its
> functions in another existing element. Example:
> 
> "udpsrc/rtpparse are separate because the is a
> network data transport
> protocol and the other is a network packet protocol.
> Also, they can be
> used independent of each other. Theoretically, one
> could use filesrc
> instead of udpsrc and it might still work."
> 
> I also see why rtp_mpeg4enc must be separated from
> rtpparse: the
> packeting differs per media type, so each media type
> needs a separate
> piece of code for parsing, and it sucks to do that
> in one element.
> 
> *However*, since the one is no use of the other, I'd
> - again - want to
> propose to make rtp_mpeg4enc an element inherited
> from rtpparse. That's
> much more convenient for programmers using these
> elements. Think about
> it: there is no way in which rtp_mpeg4enc could ever
> become useful
> without rtpparse. Similarly, rtpcontrol/udpcontrol
> will never be used
> without rtpparse. Key issue: keep it simple. I know
> this'll be harder to
> code, but it'll be easier to understand and it'll be
> easier to create
> client apps, and that's also worth quite a lot.
> 
> Autoplugging can still be done automatically here.
> Make *one* typefind
> functions for rtp (in rtpparse), and make it return
> a GstCaps that
> matches one specific payload type. Also, make sure
> that each of the
> elements inherited from rtpparse has the appropriate
> GstCaps with that
> specific payload type. Then, spider will
> automatically select the
> element from the registry with that GstCaps when the
> typefind function
> has returned the appropriate type of the RTP packet
> (the child element
> of rtpparse with that specific media type), and
> it'll work. Of course,
> this means that instead of 'udpsrc ! rtpparse !
> spider ! osssink',
> you'll do 'udpsrc ! spider ! osssink', but I
> consider that an advantage,
> not a disadvantage.
> 
> Lastly, the name rtpparse is confusing (does it
> 'de'parse or
> 'en'parse?); please use 'rtpenc' and 'rtpdec' or so.
> Also, think of a
> mimetype for RTP data (I suggest 'application/x-rtp'
> above, I don't know
> what you guys prefer?). And please don't use hyphens
> and underscores in
> element names.
> 
> Again, thanks for the work!
> 
> Ronald
> 
> -- 
> Ronald Bultje <rbultje at ronald.bitfreak.net>
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel 

___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es