[gst-devel] RTP Client sussystem design.

[Ronald Bultje]

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>