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

[Arpi]

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