[MPlayer-G2-dev] the awakening, license changes and so on...

[Attila Kinali]

Moin,

Is it just me or is there something burning ?

On Sat, Jul 24, 2004 at 03:41:16PM +0200, Arpi wrote:
> I'LL BE BACK:
> Some of you already know from irc, i'm planning to continue work
> ok mplayer g2 core from september. I left g2 because of the license
> conflict: i don't like gpl, especially for the g2 core, and no, i
> did not change my option, but the license :)

It would be great to have you back, but spelling out conditions at the
beginning isnt IMHO the right thing. It sounds like we could not do
anything w/o, so please be carefull on how you write these things.

BTW: did you chose this time by purpose ? Knowing that Rich is currently
away ?
I know that when he comes back and reads these mails that the whole
situation will explode. (you both like flaming too much)

> NEW LICENSE:
> So i plan to change g2 core license to lgpl.
> So no dual licensing, no commercial licensing and such mess.
> LGPL should be better for a (set of) library(es) anyway, and
> it let commercial users to link it with their optionally
> closedsource UIs, drivers etc.
> We won't get money directly (opposed to original dual licensing plan),
> but as iive said, nobody wants money, so it should not be problem. :)
> Although it can be expected that some commercial users (think of
> settopbox, divx player etc makers) will sponsor some of you to do
> custom development for them. I'm personally not interested much in
> these, but i was asked by several companies in the past year
> (including some quite big ones), so i know there is such interest.

I think everyone who works on a videoplayer for some while knows that
there is a huge comercial interest in having a cheap to use codebase.
The thing that matters here is on how we handle this. What do we want to
achive ? Yes, world domination is one plan, but we should think more
about tomorrow. Currently i see one big problem: the lack of manpower.
Somebody needs to write the code, and the amount of people working
actively on MPlayer was shrinking for months. The high time of 0.50
where even the devels could barely keep up with the evolution of MPlayer
are long over. So we first should think about why and how the
development slowed down before we can think about comercial usage of our
code.
Then what do you want to achive with comercial use of MPlayer ?
Just getting sponsoring (ie money, hardware, being paid for working on
the code etc) ? Getting "professional" programmers working on MPlayer ?
The fame of being the comercialy most used player ?
I'm pretty sure that you are not after the money or after hardware.
I also dont think that you are after the fame. And getting
"professional" programmers working on OSS isnt always something
you want. So what is it ?

 
> LICENSE CHANGE:
> the code released in g2 peview47 is mostly under gpl. it means
> we need to change license, with the agreement of authors. so,
> if you are author of some code in g2, and you disagree with the
> lgpl, tell us asap, so we can replace your code.
> note, that most of the code in g2 core is written by me, or being
> copied/inherited from g1.
> about plugins/filters: i want the basic ones (like swscaler,
> crop/expand, libavcodec, vo_x11 etc) be lgpl too, so they can
> be included in core. The rest (like Rich's filters) may be external
> gpl plugins, unless their authors accepts lgpl.

Be care full with licencese changes of code comming from g1.
There are so many peoples code in it, that is nearly impossible
to change it's license w/o either ignoring some copyrights or
a rewrite.
I dont know about the other parts of MPlayer, but the x11 code is so
full of different patches that i dont even know how many people worked
on it. 

> MY PLANS:
> the first goal is to stabilize/finalize all core APIs. most of them
> are OK already, maybe needs some fixes or reviews, and documentation.
> in details:

>From Rich's flaming and from iive's comments i know that there are still
some issues in the APIs, a few that are not easy to solve.

> VO: the x11_helper stuff needs to be designed better, Beastd and Faust3
>     promised some help me, and Koth too in the past.

Dont count on me here. Not that i'm oposed to your plans, but i wont
have much time until early October anyways. And after that i will be
quite busy with my last year at the university. But i'm sure that
beastd will do a much better job than i could have done
(i'm just too lazy to do much stuff and a poor programmer anyways)

>     the driver api (buffer allocation, display etc) stuff is ok imho.
>     also we should check how to handle "coupled drivers", like
>     x11+vidix, x11+mga, fbdev+tdfx, vesa+vidix etc.
>     either the parent driver can handle it, or the vf_vo wrapper can.
>     both has advs and disadvs.

Those are things which need to be spelled out clearly before work is
done.

> AO: the g1's libao2 should be ok, with changes to use module_t and
>     do not use globals.
> AF: it is not done yet at all, i have some plans but need time to
>     implement. anyway AF layer can wait, it is not so important.
> VF: i plan to use my code from pre47, and don't wait for Rich's
>     vaporware. and as Rich will probably refuse LGPL anyway,
>     it should not be a problem :)

I thought his api design was basicaly finished and only the actual
handling code needed to be done. And know, i dont think it is no
problem. The vf layer is the one that glues the most important parts
together and the design of the other apis in the video chain depends on
it. Not to mention that it will the thing that sets our future limits.

> OSD: i've made some drafts and code, have to check it again.

i'd like to hear about them. I thought quite a lot about how osd coudl
be done, but all i came up with lacked on the side of actualy drawing
the osd (i know very little about vf/vo).

> DEMUX: should be ok, except that i want to implement framer API,
>      to handle raw formats like mp3 or mpeg-ps.

Afaik Rich mentioned here a problem with handling pts, that it is not
always right, dunno what he exactly meant.

> VD: should be ok, except the changes required for framer api
> AD: depends on AF
> CONFIG: layers 0,1 are (almost) ready, layer 2 should be implemented

The config stuff is actualy i think is the only one ready for
production.

> So, as you already could see, i don't count with Iive's and Rich's work
> on vo and vf layers. If they have complete, implemented solutions,
> i'll check, but i wont wait for them forever and keep reading the
> utopistic drafts with mixing multiple video streams etc.
> I guess they should work on g3 instead :)

But you should count on their work. They are one of the very few people
who know a lot about video coding and work on OSS.

> The goal for g2 is still the same: make it usable as soon as possible.
> In short: no new from-scratch overcomplicated apis, and try to keep
> some backward compatibility with g1, so plugins can be ported easily.
> Think g2 is a cleaned up, extended g1, and not a new player/editor with
> ultimate features.

IMHO there need to be a big rewirte, not just a clean up. A clean up can
also be done on g1. But the main problem with g1 is it's complexity. I
dont know anyone who knows more then 50% of the code. The first thing
you should start with is to think about handling this code complexity.
Also the whole design should be documented from the beginning in
latex/xml/whatever. (this was actualy one of the reasons why i started
the mplayer-g2-book)
I also strongly suggest the usage of something like doxygen. It really
helps to navigate trough undocumented parts of the code.

Then g1's code has a lot of design limitations, i dont think you can get
around them w/o completely redesigning and reimplementing from scratch.

IMHO best would be to start with Rich's idea of a small proper designed
core that offers the basic functionality and then extend it until you
have what you needed and build everything else around it. 
Ie exactly like g1 started, just with a proper design behind
it and with the lessons learned.


> 
> i expect big flames about this, but please keep it short :)

Sorry, couldnt keep it short, this topic is way to important to be
discussed in short mails. And as you might see from my not so clear
writing stile i am not fully decided yet on what would be best.
(beside of the usual sleep deprivation)

Actualy for me it resolves around two questions:
What do you want to achive?
and 
How do you want to do it ?

Especialy the first one needs IMHO a clear answer.
Please also note that neither iive, Alex nor Diego have replied to your mail

				Attila Kinali