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

[Ross Finlayson]

Arpi,

Thanks for the comments.

>the current RTP implementation is done at the stream layer - so it should
>support ANY file types, as it's just a raw data source, and file format is
>handled at the demuxer layer later.

No, that's only true for some RTP payload formats - those where the RTP 
packet contains *only* codec data, without any special, payload-specific 
header (following the regular RTP header).  It so happens that this is the 
case for MPEG Transport Streams and Program Streams (as defined in RFC 
2250, section 2), which is why the old code just happened to work for this 
type of stream.  However, for most other payload formats, including 
MPEG-1,2 Elementary Streams (RFC 2250, section 3), MPEG-4 (various RFCs), 
H.263+ (RFC 2429), there are special, payload-format-specific headers in 
the RTP packet that the RTP code needs to handle.  My code is designed to 
handle this (it can already handle MPEG-1,2 and H.263+, and will handle 
MPEG-4 shortly), as well as the MPEG Transport Streams and Program Streams 
that the old code handled.

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.

>i've checked your patch. it's interesting, but...
>if you want it to be in the CVS, and so in soon-coming next release, then
>- update the patch for CVS version, 0.60 was long time ago...

Thanks.  I've done this now.  The patch now applies to the "20020410" CVS 
snapshot.

>- do NOT remove the old RTP code (maybe put into #ifdfe and make it optional)

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.

>   i doubt your .sdp thing work with current opensource steraming stuff like
>   mpeg4ip or dvbstream.

Actually, SDP is precisely the IETF-standard way of describing audio/video 
RTP sessions.  Note that pretty much all existing standards-compliant RTP 
players - including QuickTime Player, RealPlayer, and Cisco IP/TV - can 
take ".sdp" files as input.  (Another way of describing RTP sessions is to 
use RTSP (using a "rtsp://" URL).  This will also work in a future version 
of my code.)

>- make your code optional, and add option to the ./configure script, so user
>   should give where the live.com libraries and headers are placed

Yes, I'll try to do this.  Good point.

>- fix that dp->flags hack, it's really a hack, as dp->flags has internal
>   use, it contains stuff like keyframe flags and so on. dp->flags=~0 is more
>   than ugly...

OK, but to fix this, I may need to add my own new field to "demux_packet_t"

>- note that demuxer->priv and stream->priv are for use by stream and demuxer
>   'plugins', so using them is not a hack :)

OK, that's good to hear.

>- instead of detecting by extensin (*.sdp) add a new switch -sdp to set
>   stream type

OK, will do.

>and maybe also sdp:// uri type to cmdline parser.

Unfortunately there's no standard for such a URL, and it wouldn't make much 
sense anyway, because SDP files tend to be quite large (too large to fit on 
a command line).  Instead, it's better to have "mplayer" read a SDP file 
(or, in the future, a "rtsp://" URL).

         Ross Finlayson
         LIVE.COM
         <http://www.live.com/>