Hi, Benjamin Zores wrote: > Although knowing Freevo for quite a while, I've just subscribed to > this list a few days ago. Let me introduce ... I'm MPlayer > developer and team leader from GeeXboX distribution. After having > reached our 1.0 goal, we're now facing towards a complete rework of > our GUI and after several months of studies and start-stop > development of various solutions I've decided for our project to > completely re-use Freevo code.
That's great. I also know GeeXboX for some time and looked at screenshots and the feature list for time to time. But I never tried it. > What I'd like to do for GeeXboX 2.0 release is to have a complete > inclusion of Freevo 2.0 in our distribution. Even if I can only > wishes so, I'd like to propose your team some kind of partnership, > being some official Freevo LiveCD or distribution, whatever you may > call the result ;-) How does such an idea sounds to you guys ? That sounds great. Two good things can come out of this for Freevo: first of all, we will hve a LiveCD and second, I hope you can also contribute code. :) So yes, I really like that idea. > Currently I'm trying to integrate Freevo 1.6 to our distribution to > be a first step made. As for now, GeeXboX does only works in > console mode (i.e. no X server, though it may change) and I'd like > to know if some of you already had a try to a non X based Freevo > (i.e. framebuffer for Freevo, vesa or vidix output for mplayer/xine) > and what potential problems we may encounter. Freevo 1.6 works without X. I had it running (ok, I had 1.5.x running before moving to SVN) and it works at least for Matrox G400 framebuffer. > As for Freevo2, this is of course our goal to be reached (once > released) and we'll try to help you finalize/test it the best way we > can, but currently i'm not even managing to have a try at it under > my regular distro. In the same way, I can help you pushing some > MPlayer patches/features upstream to help with Freevo2 development. As written by Jason: we need two patches in mplayer: the first one (the important one) is to draw on top of mplayer. And we don't want to use bmovl because it is way to slow. All communication is done using a pipe and you can't do animations on top of mplayer. So Jason from a patch that is not in mplayer yet. The other patch is that we want to output mplayer to a buffer so we can show the video in a small video. > I'm currently facing the following error, which you may help me deals with: > > [EMAIL PROTECTED]:~/freevo2$ ./bin/freevo > WARNING __init__(1072): TV_RECORD_DIR not set > Please set TV_RECORD_DIR to the directory, where recordings > should be stored or remove the tv plugin. Autoset variable > to /home/ben. > ERROR __init__(1072): Crash! > Traceback (most recent call last): > File "./bin/freevo", line 270, in ? > gui.displays.create() > File "/home/ben/freevo2/lib/python2.4/site-packages/freevo/ui/gui/dis > nit__.py", line 62, in get > display = Display(size, True) > File "/home/ben/freevo2/lib/python2.4/site-packages/freevo/ui/gui/dis > ib2.py", line 50, in __init__ > Imlib2Canvas.__init__(self, size) > File "/home/ben/freevo2/lib/python2.4/site-packages/kaa/mevas/display > anvas.py", line 49, in __init__ > self._window = display.X11Window(size = size, title = title) > AttributeError: 'module' object has no attribute 'X11Window' That is 2.0, not 1.6. The 1.6 release doesn't use kaa at all. And it looks like you want to output an an X11 window with X11 support in kaa.display. > Another point about Freevo internals. If I understood correctly, > Freevo 1.x only makes use of Pygame (and so SDL) and it's up to us > to make SDL support any VO we'd like. Right > Freevo 2.x seems to only uses Evas to trigger this, which also will > dependant on how it has been compiled to be started under several VO > drivers. Or is X absolutely mandatory? Please tell me if I'm > missing something obvious here ;-) Evas has several backends, including framebuffer. Jason wrote an evas wrapper (kaa.evas) and we use kaa.display to get a window to draw to. With window we also mean DirectFB windows and the framebuffer screen. And evas can also output to a memory buffer so you could use evas on top of mplayer or xine. Or you can render into a mpeg file and play the gui. But this are also current ideas. Right now, Freevo 2.0 uses kaa.mevas. It is similar to kaa.evas (evas wrapper) / kaa.candy (high level api) but slower. We render to imlib2 images and display them on X11, framebuffer or to a pygame window. But once Jason is done with kaa.candy, I will remove mevas. At that point we also want to draw on top of mplayer. BTW, since you are a mplayer developer: do you think it will ever be possible to change at least some parts of the filter chain during runtime? It would be nice to turn on/off deinterlacing while playing. If you have any questions, use this list or you can also find us at #freevo on irc.gnu.org. I hope for a good partnership, Dischi -- Quitters never win, and winners never quit, but those who never quit AND never win are idiots.
pgpTMS88Miox8.pgp
Description: PGP signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Freevo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-devel
