[MPlayer-dev-eng] A RTP streaming patch for "mplayer"
Arpi
arpi at thot.banki.hu
Wed Apr 10 23:01:49 CEST 2002
Hi,
> 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
thanks, now i understand
> 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?
> >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.
ok
> >- 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
- doesn't need external libs
- doesn't need c++ compiler
- gpl and "shipped" with mplayer
- works with dvbsteram, dunno if your code works too
- doesn't need .sdp files (i still don't know what are them) but url
- 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...
> > 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 use
> r
> > should give where the live.com libraries and headers are placed
>
> Yes, I'll try to do this. Good point.
thanx
> >- 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 mo
> re
> > than ugly...
>
> OK, but to fix this, I may need to add my own new field to "demux_packet_t"
i still can't see what is the sense of this flag=~0 hack you use...
and i can't see why should this be in dp, but if it really has to be there,
then add a new field.
> >- note that demuxer->priv and stream->priv are for use by stream and demuxe
> r
> > '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).
i mean sdp://your_sdp_file.sdp, as an alternative for -sdp your_sdp_file.sdp
so users could make playlist contain such URIs.
A'rpi / Astral & ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-dev-eng
mailing list