[gst-devel] gst rtp's future
zak147 at yahoo.com
Sun Feb 17 11:45:04 CET 2002
It wasnt before starting my work on gst's rtp
plugins that i came to know of its
importance for other people. The work on the two rtp
elements(rtpsend & rtprecv) seems complete but isnt
mainly because of the rtpsend's dependence on its peer
(1) rtpsend must know about the type of data being
transfered, as the mtu(max. transfer unit)
depends on this. So the peer element should set
caps on its src pad.
(2) the peer element must timestamp the data, if not
the rtpsend will push GBs of data on the net in
a sec. Good for checking the speed of fastest
(3) One other issue is mp3. My knowledge about this
is from an online doc, some discussion with wtay
& omega & -launch experience, so plz tell me if
i am wrong anywhere. The mp3 algorithm does some
backward refencing & we are using udp, so a
reference to some data that got lost would cause
it to do really ugly things.
(1)wtay have been thinking of having a bin named
rtp, that'll contain mp32rtp/rtp2mp3 sort of
elements besides rtpsend/recv. rfc2250 is an
expample of these sort of elements AFAIK.
(2)My idea was to hack the alread existing parse
to accomplish this. mpegparse, mp1videoparse &
gsm already does that AFAIK. mp2videoparse had
been removed calling it useless, but it was
really really important for current rtpsend to
stream mpeg 2 video. Too bad, plugins get
removed before getting advice on -devel list.
So we are really in need of suggestions & advices.
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
More information about the gstreamer-devel