[MPlayer-users] two cents: why dvdnav is needed (why mplayer will die from this)

[Clemens Wächter]

On 03 Mar 2003 03:08:18 -0600
Daniel Hauck <daniel at yacg.com> wrote:

> [Automatic answer: RTFM (read DOCS, FAQ), also read
> DOCS/bugreports.html] I've been watching this list for a bit and I am
> observing why mplayer will die the way so many other decent projects
> do.

Yeah I'm wathing for quite a while, too.

> 
> Quite a few years ago, before Windows was the only way to do things
> and all the best games were in DOS, I knew this one guy who once told
> me,"...I'll never use Windows!  It's just a fancy menu system and who
> needs that?"  DOS is dead along with just about every program which
> was exclusive to it.

Sure it did. But that was not only because DOS had its limitations. You
know things are much more complicated than simply "It dies out because
it hasn't got some fancy featured which the users want". Surely that
may be a reason. But its not the only one, in the case of DOS vs.
Windows
it wasn't mainly for the gui because you know DOS performed much better
than Windows. In my experience it was even more stable.

You see the behaviour of the userbase is often more complex than quantum
physics. And I can tell that because I'm studying it ;-) It even has
some
things in common.

> I posed a question about enhancing the abilities of the "gmplayer" and
> I received similar responses the gentleman I reference below.  Such
> responses as "code it yourself" "it's too trivial" and "it's not
> needed[enough]"  
>
> [...] 
> 
> "Code it yourself" isn't always an option.  
>
> [...]

I experienced this reacion of users very often. But thats not the whole
story. You will have to see both sides to understand the whole thing.
While I am not a contributor, not to mplayer nor to any other project
(will do that when I find more free time), I have already written some
small programs for my own use. That doesn't make a experienced writer
out of me, but I can see why the authors react the way they do.

You see the problem is that adding features is often very hard even if
the featured itself seem easy to add. Mplayer is a player that doesn't 
aim at being a good dvd player. It plays them very well for me, too, but
thats not really its main goal. 

It is the fastest player and plays all kinds of media. This requires a
certain structure of the whole thing which was more or less carefully
planned. And I bet you that Arpi didn't really foresee what was to
become of mplayer. 

Mplayer has its own way of doing things and this way reflects its
internal strucutre. To add dvd menus you need to react to certain events
and to use the dvdnav library you also need a certain way to do this. So
including dvdnav would mean to adapt many parts of mplayer which do not
even belong to dvd reading. So if you force libdvdnav into mplayer you
end up either writing an ugly patch or doing a complete structure
overhaul. 

Developers often want (with good reason) to do the clean way, the
structure overhaul. I don't know if you read Arpis mail where he decided
to redo mplayer in a cleaner way (that is to create a new player, in the
distant future). So its planned but for the moment its hard to do it.

You see I also want it but I understand the developers why they don't
want to do it right now. They are usually busy people who dedicate a lot
of time to developing mplayer and to include libdvdnav would mean to
dedicate a lot of time to only that feature while there are many other
things to do. Thats why I decided not to push them. 

So if they tell you to do it yourself, this means the following 
(pick the appropriate for the situation and the individual author)
a) This has been discussed but no one is willing to do it.
b) There are more important things that can't/shouldn't wait
c) It requires mayor changes that aren't easily done
d) There are too few people who want to do this to do it in a reasonable
   time
e) Those who are only leeching could really do their part, too
f) I dont care because I don't need it. And there is a limit for things
   I do for others
g) This seriously affects stability. To get it stable again will be
   difficult
h) I don't have the knowledge and/or testing material

> 
> We're not all Henry Ford.  We want cars of many colors and styles --
> that's why there are so many of them.  The "engineer-friendly" style
> isn't the only and certainly isn't the best approach to a project that
> virtually demands that a graphics-delivering application utilize
> common graphical interface standards and uses.  The "engineer-elite"
> mentality here doesn't serve to help this project grow, but hinders it
> by limiting the user and interest base.  

The interest in mplayer isn't quite small. And your argument isn't
valid.
Just do "man mplayer" and then thing about the features and who uses it
and which of them are engineer-friendly. And then thing again about what
you wrote. Mplayer isn't quite a program that can only be used to serve
few flours and tastes.

> While the true owners of the project are the actual coders and the
> users are mere leeches, the input of users should be respected without
> grudge or malice as soon enough another project (probably commercial)
> will answer the call of the end user thereby proving that open source
> doesn't serve the community at large [read "main-stream"] and remains
> the tool of the "elite hobbyist" and never taken seriously.

Well mplayer is taken seriously. 
And it is free software which implies some things:
a) You are free to use it
b) You are _free_ _not_ to use it
c) You are free to change it according to the license
d) The authors are free to do whith it what they like to
e) They are also free to consider wheter or wheter not a certain
   addition is made. Believe me they think carefully about it.

If you realize that you get a different point of view to the whole thing.
And a different respect of the authors.

Regads,
Clemens