[gst-devel] RTP Payload Status

[Flavio Oliveira]

Hi,

I am working with the Live.com for multimedia streaming. The libraries
can be used to stream, receive, and process MPEG, H.263+ or JPEG video,
and several audio codecs.

Live.com code includes the following libraries:

- UsageEnvironment and TaskScheduler classes are used for scheduling  
  deferred events
- BasicUsageEnvironment defines subclasses of the UsageEnvironment
  classes, for use in simple, console applications.
- GroupSocket encapsulate network interfaces and sockets.
- LiveMedia defines a class hierarchy for a variety of streaming media
  types.

RoadMap:

- "LiveMedia" must run over JRTPLib (Lib used in Farsight RTP Plugin).
  I am sure that it is possible, but to get it we are removing some
  dependences with the Live.com libraries.
- Creates the LiveMedia Plugin
- Add some features in Farsight RTP Plugin to run LiveMedia over RTP
  properly

LiveMedia supports:

- AC3 audio RTP data
- AMR audio, using RFC 3267
- H.261 video, using RFC 2032
- H.263-1998 video, using RFC 2429
- MP3, using RFC 3119
- MPEG-1 and MPEG-2 audio, using RFC 2250
- MPEG-4 video, using RFC 2250
- LATM-multiplexed MPEG-4 audio, using RFC 3016
- motion-JPEG video, using RFC 2435

Flavio

> > I'm currently in favour of a lib like libjrtp that sends and receives
> > the RTCP reports transparently.
> > 
> > As for the formatting of the RTP packets there are different
> > possiblities going from using separate elements to a tightly integrated
> > solution in the encoders/decoders.
> > 
> > Some considerations:
> > 
> >  - handling of marker bit (use a buffer flag?) I have seen events too
> >    to signal packet boundaries.
> >  - some RTP payloads need to be generated/parsed in the
> >    encoders/decoders (mp3..)  
> >  - RTCP messages to influence encoding (quality, retransmission, ...)
> >    do we use events to signal the encoders? do we adjust the encoding
> >    for all clients or per client?
> >  - RTP retransmission, different options again, integrated in the
> >    encoder or keep a buffer in the sink for all clients.
> > 
> > I think the farsight plugins are the most promising at this point, they
> > use a good and complete library and do both encoding/decoding. 
> > 
> > I would go for a simple rtpsink plugin first where the rtp encoding is
> > done in separate elements then see where we can go from there. 
> > 
> > Any RTSP/SDP/.. should not be done by the rtp sink but by a separate
> > element or the application. We eventually need the element to provide
> > the rtsp:// uri handler to make it work in totem. The element would
> > setup the rtpsrc and configure it using the session properties. Just
> > some very rough thoughts.
> > 
> > Ideas, comments?
> > 
> > Wim
> > 
> >