[MPlayer-dev-eng] A RTP streaming patch for "mplayer"

[Ross Finlayson]

At 02:01 PM 4/10/02, Arpi wrote:
> > Also, the old RTP code didn't implement RTCP, which is a required part of
> > the spec, and is important for membership and packet loss reporting.
>
>membership?

By "membership", I mean "group membership in a multicast session".  I.e., 
if "mplayer" (with the patch) is used to listen to a multicast RTP session, 
then the RTCP implementation (built into the LIVE.COM libraries) will 
automatically send out periodic RTCP "Reception Reports".  The sender (or 
any other monitor listening on the same multicast group) can then use this 
to estimate the number of multicast receivers.  (These RTCP reports also 
contain packet loss statistics, so they're useful even with unicast sessions.)

> > >- do NOT remove the old RTP code (maybe put into #ifdfe and make it 
> optiona
> > l)
> >
> > As I noted above, the old code is very limited, and the new RTP code does
> > everything that the old code does, but a lot more.
>
>yes, but the old code
[snip]
>- works with dvbsteram, dunno if your code works too

It should (with a very minor change that I plan to make in the next 
release).  The existing RTP code implements only static payload type 33 
(MPEG-2 Transport Streams).  My code will be able to handle this, with no 
problem.

>- doesn't need .sdp files (i still don't know what are them)

SDP is defined in RFC 2327.  (This is currently being revised within the 
IETF; the latest version of the SDP specification can be found at 
<http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-07.txt>)

For example, a SDP file for a RTP MPEG audio/video session (with separate 
elementary streams) might look like:
         v=0
         o=- 49451 3 IN IP4 127.0.0.1
         s=Test MPEG Audio+Video session
         i=Parameters for the session streamed by "testMPEGAudioVideoStreamer"
         t=0 0
         a=tool:testMPEGAudioVideoStreamer
         a=type:broadcast
         m=audio 6666 RTP/AVP 14
         c=IN IP4 239.255.42.42/127
         m=video 8888 RTP/AVP 32
         c=IN IP4 239.255.42.42/127

The important lines (in this case) are the "m=" and "c=" lines.  These say 
that:
         - the audio stream is received on multicast address 239.255.42.42,
                 port 6666, and using the static RTP payload format 14
                 (which means an MPEG-1 or 2 audio elementary stream
                  (as defined in RFC 2250))
         - the video stream is received on multicast address 239.255.42.42,
                 port 8888, and using the static RTP payload format 32
                 (which means an MPEG-1 or 2 video elementary stream
                  (as defined in RFC 2250))
This is just a simple example of a SDP file.  For other types of session 
(especially MPEG-4 sessions), it will be somewhat more complicated.

>but url

Unfortunately a "rtp://" URL doesn't let you specify all of the information 
that you will need (in general) to describe a RTP session.  It lets you 
specify an IP address and port, but only for a single RTP stream, and the 
RTP payload format code has to be implicit.  So, a "rtp://" URL works for 
things like MP3 RTP streams (which assumes payload type 14), or, in your 
case, MPEG-2 Transport RTP streams (which assumes payload type 33) - but 
not for more general RTP sessions.

>- doesn't conflict with yoru code, so i can't see the reason of removal,
>   i can only accept _disabling_ it (#ifdefs) when your lib is used, but it
>   should work even if you left it enabled...

OK, I'll arrange to do this next time I release the patch.  In the future, 
though, you should reconsider whether you want to keep the existing code, 
as it's quite limited.

         Ross.