[MPlayer-dev-eng] c++ version of mplayer.c

[Jan Volf]

Hi,
On 11.2.2005, at 13:30, Reimar Döffinger wrote:
> Hi,
> On Fri, Feb 11, 2005 at 01:18:00PM +0100, Jan Volf wrote:
>> I'm quite disappointed by the discussion here.
>> C++ itself does not help anything but the OO approach would definitely
>> do and the OO approach or some kind of rules that each part of code 
>> has
>> to conform to is what this project completely lacks. Just look in to
>> main function, it is mess. The globals are everywhere even in cases
>> where there is no reason for them (in fact there's no reason for any 
>> of
>> them :). This code is unmanageable. The core of mplayer is written in
>> one function counting several thousands of lines - insane!!!
>
> We are quite aware of that - but the main loop is essential for MPlayer
> working correctly, it can't just be rewritten. G2 would fix it, but
> unfortunately there is not much/nothing going on in that area.
What is the state of G2 development progress?
> Nevertheless there have been some minor improvements, e.g. I moved the
> audio chain initialization and status line code to separate functions
> and a lot of formerly global variables have become at least static (and
> thus "local" to mplayer.c
I'm working on month old cvs snapshot, I think, and there is still 
bunch of globals defined in mplayer.c and made extern in its header 
file and another bunch of globals is defined elsewhere.
>> I know that the C++ is far from being good OO language and makes no
>> sense to rewrite all code in it. You can simply take OO approach and
>> write in pure C but there should be some rules. The first one is that
>> there should be NO globals - it's real pain.
>> Month ago I started to rewrite the main function's code to separate
>> real mplayer's core from user interface and high level code. I'm
>> writing it in pure C just using structures to simulate OO approach. 
>> The
>> purpose is to create player engine for the UI that can be platform/OS
>> dependent. First I thought it would be easy just dividing the main in
>> to several functions to create entry points for my UI. Now I know that
>> I was fool to think this way. Though, I'm continuing the process
>> regardless it will be welcomed here (now I'm very sceptic about it), 
>> If
>> nothing it well help me in my project, otherwise I would have thrown 
>> it
>> in the thrash.
>
> It is very welcome, if it is done in a clean way and with appropriate
> speed that guarantees that no big or even unfixable bugs will be
> introduced. Up to now everybody who tried wanted to do everything at
> once, which IMHO is not acceptable.
I agree, doing everything is too much work and IMO not needed, but we 
have to start somewhere and the best start point is IMO the mplayer.c. 
The only problem I have is that there is lot of non-essential code that 
is difficult to implement clearly (without globals). Since I don't want 
to modify code other than mplayer.c for now (to avoid more problems) I 
have to remove the code just to get the core of mplayer working and  
then reimplement this code again.
The performance penalty is unlikely, I don't intend alter main playback 
loop more than necessary. So we'll see.
> Anyway, I really think Guis should use slave mode and that should be
> extended as needed (though we need more feedback on slave mode to make
> it really useable)...
Though I don't know why do you think this way, as GUI developer I can 
say, that I tried to squeeze as much as possible from slave mode and 
the result is quite usable but as long as the format of output is not 
standardized I could not rely on it. Anyway, it means running the 
mplayer separately from GUI and it is odd.

Regards,
Jan Volf
MPlayer OS X developer