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

[Arpi]

Hi,

> > > 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.
> > 
> > g2 is/was my project, i started it from scratch, and later extended
> > by code from g1. so i wonder why should i be very carefull when i came
> > back? maybe i should, if you all do a great work on it since i leave,
> > making it a good application, but the truth is that nobody touched the
> > code since that... this was my main purpose to came back, to finish
> > what i started.
> 
> Juup...No progress whatsover :(

I wont have time before september to actually work on g2 code, i'm just
doing some preparation now...


> > > 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)
> > 
> > i didnt know that he is away, remember i did not read the mailing lists.
> > anyway i dont really care of rich's flames^Kopinion...
> 
> Ok, didnt expect something like this from you anyways.

ok :)

> > - getting g2 api accepted as 'industial standard for linux/unix video/media'
> >   something like oms, and later gstreamer and openquicktime wanted to
> >   reach, with no much success.
> >   we have to make it available for commercial users, otherwise they wont
> >   spend their time developing/porting their codecs, demuxers etc for it.
> > - getting some money/hw/sponsorship to developers who need it to be able
> >   to work on the code fulltime or at least more time.
> 
> Why do you want to get commercial users onto MPlayer ?
> Just for the sponsoring ? 

argh. no, of course.
i just want to "legalize" (bad word for this, but i dont know the right one)
video playback under non-m$ systems. most of the codec/container makers
would port/develop their stuff for non-m$ systems, if they have any
chance, ie. any usable API they can use, like quicktike or dshow on win/mac.
unfortunatelly they don't have any 'standard api' under unix/linux, so they
end up either not supporting unix, or they hack together some useless
standalone player (see realplay, bink player etc).

we currently support most formats through win32 DLLs run by big hacks in
emulators. ok, it's a working (x86-only) workaround, but not a solution.
the soultion would be native codecs.
and dont tell me to rev.eng. every single dll, because it's also not a
solution...

btw i wonder why m$ didnt notice this empty space, ie. the lack of a video
framework uner unix, they could port their dshow/dmo api and let the
companies port their codecs to it. so they could get monopol status over a
free os when it comes to video playback :)

> > > > 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.
> > 
> > i know. but they are also the reasons why g2 is still not finished.
> > i can't agree any more with them making g2 api capable of every
> > extreme cases including mixing from multiple video sources, backward
> > playback and so on. i think it maybe a goal for g3, but not for g2,
> > or g2 will end up vaporware.
> 
> ACK
> 
>  
> > > 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.
> > 
> > sure. but i can get around the most important limitations.
> 
> I trust your word here :)
> 
> > > 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. 
> > 
> > i dont remember rich going for small simple core... he had overcomplicated
> > (hard/impossible to implement) vf ideas.
> 
> He came up with this idea a few months ago, after you left.
> He never spelled it out in a mail but we talked a few times about it
> on irc.

could you summarize it ?
it's new to me...

> > > Ie exactly like g1 started, just with a proper design behind
> > > it and with the lessons learned.
> > 
> > g1 was born as a 1,5 hours hack around libmpeg3.
> > later replaced by dvdshow and then libmpeg2, and after some code
> > coped from xmps/avifile to support divx. the whole shit was a bigugly
> > hack. this is what i try to avoid in g2.
> 
> Juup.
> 
>  
> > > What do you want to achive?
> > working, usable g2
> > 
> > > How do you want to do it ?
> > quickly
> 
> Good.. 
> You can count on my support here.

nice. not that you can do much here :)

> (given that i have the time :( )
> 
> > > Especialy the first one needs IMHO a clear answer.
> > > Please also note that neither iive, Alex nor Diego have replied to your mail
> > so what are the conclusions? they refuse to support me? ok...
> 
> Dont know. I just noticed it and was wondering why.

ah. i though they did not answer by purpose, and you know why :)

> I know that at least Diego and iive are reading this list (alex
> disapears from time to time). Also Michael didnt respond.

i talked with them at irc, few days before sent this mail.
i had to talk to at least Michael, his code is key point of whole g2.


A'rpi / MPlayer, Astral & ESP-team

--
MPlayer's new image: happiness & peace & cosmetics & vmiklos