MPlayer-G2-dev

Download

mplayer-g2-dev@mplayerhq.hu

January 2006

1 discussions

the awakening, license changes and so on...
by Arpi 02 May '07

02 May '07

Hi, 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 :) 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. WHY NOT GPL? GPL is just too limited for the purpose of g2 core. Even Michael and Alex agreed on irc. We need some license which allows at least linking to plugins and UIs under different (even closed source) license. Why? Think of a 3rd party company developing codecs (like 3ivx, On2 etc) they want to make their codecs available for linux (and other unix) platforms natively (no DLL hack), but they cannot open the source, or they can but they dont want to put it under GPL. The second reason is commercial users, ie settopbox makers etc. I was contacted by several companies in the past, with very different targets of use. It ranges from driving 16000x4000 pixel giant displays (using industrial 16-head vga cards), to driving 3-d hologram projectors, or to be used in advertisement display kiosks in 24/7 for months without a reboot/restart. They all need very stable linux-based player core. And they all need less restrictive (than gpl) license. Since these applications are far from as-is use, they usually need custom plugins, uis, and they are willing to sponsor us to do that. (note to Rich and friends: sponsoring not only means money, it may mean added code/patches, hardware to developers, new server and so on) 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. 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: VO: the x11_helper stuff needs to be designed better, Beastd and Faust3 promised some help me, and Koth too in the past. 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. 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 :) OSD: i've made some drafts and code, have to check it again. DEMUX: should be ok, except that i want to implement framer API, to handle raw formats like mp3 or mpeg-ps. 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 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 :) 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. i expect big flames about this, but please keep it short :) A'rpi / MPlayer, Astral & ESP-team -- MPlayer's new image: happiness & peace & cosmetics & vmiklos

17 38