From arpi at thot.banki.hu Sat Jul 24 15:41:16 2004 From: arpi at thot.banki.hu (Arpi) Date: Sat, 24 Jul 2004 15:41:16 +0200 (CEST) Subject: [MPlayer-G2-dev] the awakening, license changes and so on... Message-ID: <20040724134116.D24C238AEF@mail.mplayerhq.hu> 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 From FabianFranz at gmx.de Sat Jul 24 16:11:42 2004 From: FabianFranz at gmx.de (Fabian Franz) Date: Sat, 24 Jul 2004 16:11:42 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: <200407241611.42043.FabianFranz@gmx.de> Hi, that are great news! As far as code is from me you I accept license as LGPL, which was exactly made for libraries like those btw. :-). I don't know about the parts I only ported to g2. I guess we have to ask the original authors from g1. cu Fabian PS: As soon as its all finished, you should do a media announcement. From arpi at thot.banki.hu Sat Jul 24 16:28:08 2004 From: arpi at thot.banki.hu (Arpi) Date: Sat, 24 Jul 2004 16:28:08 +0200 (CEST) Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <200407241611.42043.FabianFranz@gmx.de> Message-ID: <20040724142808.6FE9138A1B@mail.mplayerhq.hu> Hi, > that are great news! > > As far as code is from me you I accept license as LGPL, which was exactly made > for libraries like those btw. :-). thanks > I don't know about the parts I only ported to g2. I guess we have to ask the > original authors from g1. > > cu > > Fabian > > PS: As soon as its all finished, you should do a media announcement. no, i wont. i left that job for Gabucino :) (yes, i prefer the old PR team :)) A'rpi / MPlayer, Astral & ESP-team -- MPlayer's new image: happiness & peace & cosmetics & vmiklos From joey at nicewarrior.org Sat Jul 24 20:43:17 2004 From: joey at nicewarrior.org (Joey Parrish) Date: Sat, 24 Jul 2004 13:43:17 -0500 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: <20040724184317.GB2875@nicewarrior.org> On Sat, Jul 24, 2004 at 03:41:16PM +0200, Arpi wrote: > 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. I would love to work on G2. I've been avoiding it due to lack stable APIs for certain things. All my (decent) code I'll port and happily declare LGPL. (The stuff I wrote that sucks, I'll rewrite. :) I'd also really enjoy porting VOs and a filter or two. > 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. So, should I wait a bit before I start hacking vo drivers? > 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 :) Or we could have his filter layer as a GPL plugin to the current one. Maybe some day we'll have vf_rich? :) > OSD: i've made some drafts and code, have to check it again. I don't know what OSD drafts are like, but I'd like to suggest that osd modes be user-defined with a formatting string like printf or strftime. We can put default config entries for the modes as they are now in G1. > 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. We already have the ultimate player (relatively). :) --Joey -- "The Hell Law says that Hell is reserved exclusively for them that believe in it. Further, the lowest Rung in Hell is reserved for them that believe in it on the supposition that they'll go there if they don't." HBT; The Gospel According to Fred, 3:1 From saschasommer at freenet.de Sun Jul 25 17:44:10 2004 From: saschasommer at freenet.de (Sascha Sommer) Date: Sun, 25 Jul 2004 17:44:10 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: <200407251744.10336.saschasommer@freenet.de> On Saturday 24 July 2004 15:41, Arpi wrote: > 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 :) > Good to hear that you are back. > 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. > I accept the license chance to LGPL for G2 code written by me. Not much anyway. timer-win.c isn't written by me, though. Maybe we should simply replace it with the code currently in G1. > 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. Dunno maybe it is the easiest way to add support for it in the vf_vo wrapper as described in http://mplayerhq.hu/pipermail/mplayer-g2-dev/2003-December/000567.html Sascha From eclipse7 at gmx.net Sun Jul 25 17:52:19 2004 From: eclipse7 at gmx.net (Alexander Strasser) Date: Sun, 25 Jul 2004 17:52:19 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724184317.GB2875@nicewarrior.org> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> <20040724184317.GB2875@nicewarrior.org> Message-ID: <20040725155219.GA2225@Beastland> Hi Joey, On Sat, Jul 24, 2004 at 01:43:17PM -0500, Joey Parrish wrote: > > 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. > > So, should I wait a bit before I start hacking vo drivers? > I would say better wait a little. Faust3 and me are reconsidering the vo design ( for vos with window handling ) ATM. We will post something about it to this list next time. But porting vos not connected to window handling stuff should be no problem though. Alex (beastd) From Reimar.Doeffinger at stud.uni-karlsruhe.de Sun Jul 25 22:49:29 2004 From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-15?Q?Reimar_D=F6ffinger?=) Date: Sun, 25 Jul 2004 22:49:29 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: <41041CD9.3020708@stud.uni-karlsruhe.de> Hi, > 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. I agree with lgpl, too. So you can include an OpenGL vo in that list ;-) > VO: the x11_helper stuff needs to be designed better, Beastd and Faust3 > promised some help me, and Koth too in the past. Yes, it would also be nice if the vo could demand some features from the window, like that it supports OpenGL. That's no problem on standard PC hardware, as there all (if any) Visuals support OpenGL, but could cause troubles for SGI, SPARC or something (I have to admit that I don't know for sure). Greetings, Reimar D?ffinger From arpi at thot.banki.hu Sun Jul 25 23:03:12 2004 From: arpi at thot.banki.hu (Arpi) Date: Sun, 25 Jul 2004 23:03:12 +0200 (CEST) Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <41041CD9.3020708@stud.uni-karlsruhe.de> Message-ID: <20040725210312.3B72E37C35@mail.mplayerhq.hu> Hi, > > 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. > > I agree with lgpl, too. So you can include an OpenGL vo in that list ;-) thanks > > VO: the x11_helper stuff needs to be designed better, Beastd and Faust3 > > promised some help me, and Koth too in the past. > > Yes, it would also be nice if the vo could demand some features from the > window, like that it supports OpenGL. That's no problem on standard PC > hardware, as there all (if any) Visuals support OpenGL, but could cause > troubles for SGI, SPARC or something (I have to admit that I don't know > for sure). hmm. also, it would be great, if the opengl driver could be split to platform independent part (using gl* functions only) which could work as sub-driver of vo_x11 or vo_win32? or is it a bad idea? :) A'rpi / MPlayer, Astral & ESP-team -- MPlayer's new image: happiness & peace & cosmetics & vmiklos From Reimar.Doeffinger at stud.uni-karlsruhe.de Sun Jul 25 23:16:15 2004 From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-15?Q?Reimar_D=F6ffinger?=) Date: Sun, 25 Jul 2004 23:16:15 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040725210312.3B72E37C35@mail.mplayerhq.hu> References: <20040725210312.3B72E37C35@mail.mplayerhq.hu> Message-ID: <4104231F.7090100@stud.uni-karlsruhe.de> Hi, > hmm. also, it would be great, if the opengl driver could be split > to platform independent part (using gl* functions only) which could > work as sub-driver of vo_x11 or vo_win32? or is it a bad idea? :) I guess it could and should be done. But I fear it won't be trivial to decide which parts are platform independent and which aren't (especially the data structures, e.g. vo->priv would need a platform independent part vo->priv->gl or something like that...). I'll have a closer look once the framework is a bit nearer to finished, hard to decide much before ;-) Greetings, Reimar D?ffinger From jiri.svoboda at seznam.cz Sun Jul 25 23:28:30 2004 From: jiri.svoboda at seznam.cz (Jiri Svoboda) Date: Sun, 25 Jul 2004 23:28:30 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: Hi, > 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. I do not have any code in g2, but if anybody wants to port/use vo directb from g1 I agree with LGPL... JS From nsabbi at tiscali.it Mon Jul 26 08:35:24 2004 From: nsabbi at tiscali.it (Nico Sabbi) Date: Mon, 26 Jul 2004 08:35:24 +0200 Subject: [MPlayer-G2-dev] the awakening, license changes and so on... In-Reply-To: <20040724134116.D24C238AEF@mail.mplayerhq.hu> References: <20040724134116.D24C238AEF@mail.mplayerhq.hu> Message-ID: <1090823724.3083.9.camel@retexp> Il sab, 2004-07-24 alle 15:41, Arpi ha scritto: > Hi, > > I'LL BE BACK: this is great news! > 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. [snip] > 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 > as far as I'm concerned you can include without problems all the code in demux_ts that is not in g2's demux_mpeg: table parsing, program association, support for fancy ac3, mpeg4 and next stuff (I haven't committed some code I have here at home to handle h264 and televideo yet). You didn't mention the stream layer; currently the dvb code is mostly my stuff, but dvb_tune.c was taken from dvbstream (released as gpl by Dave Chapman) so if Dave doesn't agree to permit me to change the license I will rewrite it from scratch as lgpl. > 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 Nico From mitya at school.ioffe.ru Wed Jul 28 18:07:21 2004 From: mitya at school.ioffe.ru (Dmitry Baryshkov) Date: Wed, 28 Jul 2004 20:07:21 +0400 Subject: [MPlayer-G2-dev] Stream layer split proposition. Message-ID: <20040728160721.GA6751@macaca> Hello, Here comes my recent idea: to split current stream layer to two layers: physical stream and logical stream. Here is what I mean: In most of cases, input streams are very simple: file over something (over filesystem, over ftp, over some other network protocol, etc). But even DVD streams are much worse: DVD stream can exist over raw-device (read with bunch of ioct's for decoding), over any fd (simple reading & seeking) and over bunch-of-VOBs-and-IFOs. All these are _physical_ streams. But, from player's POV, DVD can be seen as (at least) two different _logical_ streams: simple per-title reading (as in current MPlayer & G2) and as those fancy navigation menus, events, etc. Another example: VCD, CD-DA and other non-plain CD's can exist as normal CD/CD-R/etc or as .cue+.bin, as .cue+bunch-of-tracks (maybe it's the same. I'm not sure). Or as some metadata(track offsets, sector sizes, etc) and raw byte stream (fd). So here (again) is the proposition: to split stream code to two independant layers with caching between them. (I mean, only physical stream must be cached. Logical stream should be directly feeded to the demuxers.) I can't propose any API (yet), but I think, that they can be as simple as static metadata (i.e. file name, size, etc. for file-based phys.streams, cuesheet for cd-based, etc). I can see only two problems with this approach: 1) device-based DVD phys stream must be intellectual to determine if a block is encrypted or not without the help from logical stream layer (it should duplicate/incorporate some part of current libdvdread) 2) again DVD, but now bunch-of-VOBS problem. to provide VOBs as unificated DVD stream, we should incorporate some type of 'mkisofs -dvd-video ...' into phys stream. There is another solution for this -- use stream-of-VOBs-and-IFOs as a basic DVD stream and convert all other DVD streams to this, but I don't know if it's better or worse. -- With best wishes Dmitry Baryshkov