[MPlayer-dev-eng] A RTP streaming patch for "mplayer"
finlayson at live.com
Wed Apr 10 22:29:05 CEST 2002
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
>- 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).
More information about the MPlayer-dev-eng