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

[Ross Finlayson]

At 04:55 PM 4/10/02, you wrote:
>It is probably better with a dependency than importing the entire
>tree to the mplayer tree, or even worse reimplementing everything
>from scratch. If other people do and want to maintain a rtp protocol
>implementation why not let them do that and then use their code?
>
>Of course it should be possible to disable rtp support with some
>option to 'configure' so you wont have to download some new library
>to compile mplayer if you don't want rtp support.

Yes.  It was always my intention that the use of the "LIVE.COM Streaming 
Media" libraries be optional.  So, if people don't want it, they don't have 
to use it.

BTW, these libraries are already being used for many other applications, e.g.
         - "liveCaster" <http://www.live.com/liveCaster/> for MP3 streaming
         - a MP3/RTP plugin for "Winamp" 
<http://www.live.com/multikit/winamp-plugin.html>
         - "openRTSP", a RTSP client <http://www.live.com/openRTSP/>
         - within security cameras, for MPEG video streaming
so it wouldn't really make much sense to try to reimplement this code, in 
C, just for "mplayer".  (Instead, there's just a single C++ file, present 
in the patch, that acts as a stub to interface between the existing 
"mplayer" code (C) and the "LIVE.COM Streaming Media" code (C++).)


>"lots of systems lack or have broken c++ compiler and/or libs"
>
>Actually I don't think so. Which systems are you talking about?
>Anyway don't we require gcc anyway? And a pretty new version of gcc
>too if I am not mistaken. Then it shouldn't be a problem. I am quite
>sure that this rtp implementation works perfectly fine with g++.

Yes, the code is built and tested primarily with g++ on FreeBSD (and Linux) 
systems.  (It can also be built on Windoze using MS Visual C++, or Borland.)

It turns out that C++'s class inheritance mechanism (using virtual 
functions) is extremely useful for building media streaming code like 
this.  After looking at the "mplayer" code, I also think that some of its 
data structures (e.g., "stream_t" and "demuxer_t") would have benefitted, 
had they been implemented as C++ classes instead of C structs.  (This is 
not intended to be a slight against the "mplayer" code; the decision to 
write it purely in C was a perfectly reasonable one at the time.)

         Ross.