Re: Arpi, if you are still reading the mcf-mplayer

Arpi wrote:
> Hi,
> 
> 
>>>i never liked this kind of modularization...
>>>easy implementation of player should not be a goal for a codec interface...
>>>performance, stability... it should.
>>
>>OK, so it's better to restart a project from scratch when there is a bug 
>>somewhere...
> 
> 
> yes. at least you know every bit of the code, and you can fix every bug,
> you don't have to rely on others.
> 
> actually i don't see the fun of 'here is a lib, call this function and
> you'll get a media player window' kind of programming...
> 
> i like to have control over every bit of the path from the input to the
> output, even over the OS if possible.
> 
> 
>>Also if you look at the BeOS Media Kit, you'll see that their major goal 
>>is performance.
> 
> in c++... yeah :)

I was talking this afternoon about how fast Qt/KDE evolved to be the 
major desktop system on Linux. And you know why ?
* good coders
* KDE relies on Qt to do most of the job
* Qt is in C++ only and fully object oriented

BTW, how many libraries does mplayer use ?

Why do player developpers need to rewrite and AVI, MPEG, etc, demuxer 
everytime they have to play a format ? Why not rely on THE (open) filter 
of the architecture that the guy who created the format will do for you 
? Why recreate a whole data path (reinvent the wheel) when something 
efficient exists ?

- It's not about performance (otherwise you can improve, recode the 
filter in a better way).
- It's not about technical expertise (you're coding a player, not an 
authoring tool).
- It's not to help other coders (otherwise you'd try to imrpove the 
existing tools, instead of creating incompatible code).
- It's not because you can control everything (you can also control 
everything you need in DShow).