[gst-devel] gst rtp's future

[Zeeshan Ali]

Hello guys,
   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
element. 

Problems:
  (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
      nets :)
  (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. 

Possible Solutions:
   (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
      elements(mp3parse,mpegparse,mp1/2videparse etc)
      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.

=====
ZEESHAN ALI

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com