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

[Fredrik Kuivinen]

On Wed, Apr 10, 2002 at 07:30:46PM -0400, D Richard Felker III wrote:
> On Thu, Apr 11, 2002 at 01:18:36AM +0200, Fredrik Kuivinen wrote:
> > On Wed, Apr 10, 2002 at 11:01:49PM +0200, Arpi wrote:
> > > > >- 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
> > 
> > Why is this a problem? IMHO code reuse is a good thing. If there are
> > libraries with suitable licenses we should IMHO use them instead of
> > rewriting the same functionality or duplicating the code in the
> > mplayer tree.
> 
> code reuse is good if the code is good, and if it's clean. however,
> requiring the user to install extra libs before compiling mplayer is
> not good, it's just a pain. there's a difference in code reuse and
> external dependencies.
> 

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.

> > > - doesn't need c++ compiler
> > > - gpl and "shipped" with mplayer
> > 
> > According to http://live.sourceforge.net/ the LIVE.COM Streaming
> > Media libraries are under LGPL so it shouldn't be a problem. (I
> > assume the patch is under GPL.)
> 
> you didn't address the c++ issue, which is both technically (lots of
> systems lack or have broken c++ compiler and/or libs) and
> aesthetically nasty.

No I didn't address the C++ issue. As you brought it up I can make
few comments though.

"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++.

"aesthetically nasty"

I can agree with you that mixing two different languages in the same
project is a bit ugly but I think it is worth it anyway.

If you think C++ is ugly or that it is something wrong with it in
general then I don't have much to say...

> it's good that they're lgpl though -- perhaps
> some code from them could be ripped to make a nice c implementation.
>

A "nice" C implementation which will probably contain a few more bugs
than the C++ implementation... + We will end up with x extra kloc to
maintain. Really nice...

When the live.com guys fixes bugs and adds new nice features that we
want in mplayer too we will either have to port everything back to
our C implementation or end up with a lot of bugs.

IMHO it is just stupid to not use the available implementations of
things like this.

(Btw. Maybe there is a opensource C implementation of the rtp
      protocol somewhere. I don't know. Would be a shame to throw
      away this patch though.)

/ Fredrik