libvisual-devel — libvisual mailinglist for developers

Re: [Libvisual-devel] Re: G-Force

[Dennis S. <sy...@yo...>]

On Wed, 2004-09-15 at 01:13 -0300, Duilio Javier Protti wrote:
> I have tested the distro package and it builds and get installed
> right. The only remaining thing is to add the "white spaces" files.

So how are we going to work around this, rename "Foo Bar" to "Foo_Bar" ?



Someone else on the list, that knows if auto* really doesn't handle
whitespaceness ?

If we're going to rename them to "Foo_Bar" I think it might be wise to
add a 'name="Foo Bar" at the top in the files. So we can later on use
this in the G-Force VM.

Thanks a lot,
Dennis

Re: [Libvisual-devel] libvisual - DESTDIR variable support

[Burkhard P. <pl...@ip...>]

> Please try to make a binary package and send results.

Sorry, you need a .spec file first, maybe I can make one when
I'm really bored (to much other stuff to do).

But the DESTDIR thing works now, this is the installation
footprint:

./usr
./usr/lib
./usr/lib/libvisual.so.0.0.0
./usr/lib/libvisual.so.0
./usr/lib/libvisual.so
./usr/lib/libvisual.la
./usr/lib/pkgconfig
./usr/lib/pkgconfig/libvisual.pc
./usr/include
./usr/include/libvisual
./usr/include/libvisual/lvconfig.h
./usr/include/libvisual/libvisual.h
./usr/include/libvisual/lv_actor.h
./usr/include/libvisual/lv_audio.h
./usr/include/libvisual/lv_bin.h
./usr/include/libvisual/lv_common.h
./usr/include/libvisual/lv_fft.h
./usr/include/libvisual/lv_input.h
./usr/include/libvisual/lv_event.h
./usr/include/libvisual/lv_keysym.h
./usr/include/libvisual/lv_list.h
./usr/include/libvisual/lv_log.h
./usr/include/libvisual/lv_palette.h
./usr/include/libvisual/lv_plugin.h
./usr/include/libvisual/lv_video.h
./usr/include/libvisual/lv_libvisual.h
./usr/include/libvisual/lv_songinfo.h
./usr/include/libvisual/lv_morph.h
./usr/include/libvisual/lv_bmp.h
./usr/include/libvisual/lv_param.h
./usr/include/libvisual/lv_mem.h
./usr/include/libvisual/lv_endianess.h
./usr/include/libvisual/lv_cpu.h
./usr/include/libvisual/lv_color.h
./usr/include/libvisual/lv_time.h

BTW: I called configure without commandline args.
Is it a good idea to force /usr instead of /usr/local?
Libvisual would be the only package I know, which installs
into /usr by default.

Cheers

Burkhard

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

[Libvisual-devel] Re: G-Force

[Duilio J. P. <dp...@fc...>]

> Duilio,
> 
> What needs to happen before we can release G-Force at this point ?
> 
> I'd like this to be release ready asap :) So it might be handy
> to generate a list, so we can work it out ;)
> 
> Cheers,
> Dennis

I have tested the distro package and it builds and get installed
right. The only remaining thing is to add the "white spaces" files.


Bye,
Duilio.

[Libvisual-devel] Re: xmms roadmap + VisCPU API

[Duilio J. P. <dp...@fc...>]

> When you incorporated my comments, I will add it to the roadmap!
>
> > 0.1.6
> >         There is no time!
> > 0.1.7
> >         Let the user choose the input plugin
> >         Let the user choose the morph he want, if any.
> >         Let the user choose the actor plugins he want to play
> 
> Maybe an idea to support 'random morph plugin' option as well.

Sounds good.

> > 0.1.8
> >         Let the user set the verboness of within libvisual.
> >         See if we must save setting through Serialize on VisParam.
> I doubt if the xmms plugin itself needs serialization through libvisual.

I'm agree with you.

> > 0.1.9
> >         Wait for VisFont subsystem.
> > 0.1.10
> >         Try to use VisFont subsystem.
> >         Show song info on the video area on play and things like that.
> This will be handled in libvisual itself! through an API ;)
> (so every client can use it directly)

Oh, good.

In regard of VisCPU module, there is an idea about the API?

Bye,
Duilio.

[Libvisual-devel] libvisual - DESTDIR variable support

[Duilio J. P. <dp...@fc...>]

I have added support for DESTDIR variable on the
install-exec-local target. Please try to make a 
binary package and send results.

Thanks to Burkhard Plaum.


Regards,
Duilio.

Re: [Libvisual-devel] Corona, visual plugin

[Dennis S. <sy...@yo...>]

Jeko, great!, It's coming your way !

On Tue, 2004-09-14 at 22:17 +0200, Jean-Christophe Hoelt wrote:
> Hey Dennis!
> Please send me that code, I'll see what I can do.
> Regards,
> -- Jeko

Re: [Libvisual-devel] Corona, visual plugin

[Jean-Christophe H. <je...@io...>]

Hey Dennis!
Please send me that code, I'll see what I can do.
Regards,
-- Jeko

Dennis Smit wrote:

>Heya guys, I've got the WMP source code of:
>
>http://users.ox.ac.uk/~linc1040/corona/
>
>Laying around. It's portable for sure. But it needs
>some work. Anyone interested or is this getting postponed till
>I'm in a crack mood ? :)
>
>Cheers,
>Dennis
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
>Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
>Camcorder. More prizes in the weekly Lunch Hour Challenge.
>Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m
>_______________________________________________
>Libvisual-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libvisual-devel
>  
>

Re: [Libvisual-devel] Re: Libvisual

[Dennis S. <sy...@yo...>]

On Tue, 2004-09-14 at 14:12 +0200, Burkhard Plaum wrote:
> > When an app notifies libvisual that it ONLY supports 16 bit and lower
> > libvisual will transform 24 and 32 bits surfaces to 16 bit internally.
> 
> So it seems that apps still need to know a lot about the
> display properties. For xine, mplayer and such, this would be
> no problem, but if someone wants just to write a quick and dirty
> visualisation app (like gmerlin-visualizer)?

Well, how can an app take the best depth, without knowing it ?. You can
FORCE a plugin in a certain depth, it will get depth transformed within
libvisual. But, when possible it's adviced to try atleast take the right
depth. This reduces overhead.

> > Like SDL did kinda ?
> 
> Probably, but as I said, I don't really like (i.e. know) SDL.
> glut and gtkglarea are also exmaples, where apps can pass the
> required OpenGL properties.

Ok :) We will look at that for sure.

> > I rather have the burdon on libvisual, because that way we don't force
> > anything. An example is video editing. There is a program LiVES
> > (lives.sf.net) If I'm not wrong that is used for VJ productions. Since
> > ehm, this weekend it also supports libvisual, but it's not drawn
> > in realtime because of al the video stuff. Basicly we want to take
> > as much as possible out of the plugins.
> 
> Keeping plugins simple is good.
> The problem is that for lemuria, time == frame_count.
> Many effect mechanisms (e.g. the animated texture on most
> foreground objects) rely on a constant and known framerate.

What about a system that tells libvisual,
'I'd REALLY like THIS framerate' and then libvisual implements
an easy to use framerate limiter. I think this would be better
because you don't FORCE it, this can be better regarding
flexibility in some areas. Keep in mind that we don't just
write libvisual for playback apps. Some guys are doing VJ software
combined with realtime video software with it.

> If you do completely synchronous rendering (i.e. render one picture
> each 512 samples), you must render 44100/512 = 86 fps for lemuria.
> I don't think, that a "standard" consumer PC is able to do this,
> when full antialiasing is enabled :-)

Most plugins don't obtain this framerate, it's not a problem that
not each sample a picture is generated.

> In addition, OpenGL (i.e. GLXSwapBuffers) can be synched to
> the vertical frequency of the monitor, and for the high-speed
> scenes in lemuria, this is strongly recommended.
> Being in sync with both the music and the monitor is impossible.
> 
> In addition, the animation speed would change, if one switches to
> a track with a different samplerate. For spectrum analyzers, this
> doesn't matter but for lemuria it does!

As said, we can use a FPS limiter provided by libvisual, or wouldn't
that be sufficient ?

> I meditated a lot about this when writing lemuria. The only possible
> solution was to render in a separate thread using the
> most recent audio samples and limit the framerate using a
> software timer (to ca. 30 fps in my case). On weak hardware,
> the animation speed becomes slower, but it's always independent
> from the audio signal.

The audio core gets redone eventually, so don't rely too much on this
'512' thing.

> Whether the plugins or libvisual handles this is a matter of taste,
> but completely synchronous rendering is not possible.

What is needed, in facilities, within libvisual to make it possible ?
(as you can guess by now, I only use threads when it's absolutely
needed, no way around it). Ofcourse as a plugin writer, it's your
choice. But I'd rather make some facilities in libvisual to work
it out threadlessly, than using threads.


> The problem is the install-exec-local target. There is an
> explicit reference to $(prefix)/include/libvisual, which isn't
> changed by the DESTDIR mechanism. Maybe using $(includedir) would
> help.
Duilio can you take a look at this ?


Burkhard Thanks a lot for your input, I'm sure we can find the
technical right solution, discussion is good it makes us think :)

Cheers,
Dennis

[Libvisual-devel] G-Force

[Dennis S. <sy...@yo...>]

Duilio,

What needs to happen before we can release G-Force at this point ?

I'd like this to be release ready asap :) So it might be handy
to generate a list, so we can work it out ;)

Cheers,
Dennis

[Libvisual-devel] Corona, visual plugin

[Dennis S. <sy...@yo...>]

Heya guys, I've got the WMP source code of:

http://users.ox.ac.uk/~linc1040/corona/

Laying around. It's portable for sure. But it needs
some work. Anyone interested or is this getting postponed till
I'm in a crack mood ? :)

Cheers,
Dennis

[Libvisual-devel] Random link.

[Dennis S. <sy...@yo...>]

I just have the feeling that this might interest
some people here:

http://acg.media.mit.edu/people/golan/aves/index.html

Also:
http://users.ox.ac.uk/~linc1040/synesth/screenshots.shtml

We might be able to actually port that plugin.

Cheers,
Dennis

(ps. We need a porting squad)

Re: [Libvisual-devel] Re: Still a compile problem with 0.1.6

[Dennis S. <sy...@yo...>]

On Mon, 2004-09-13 at 23:04 +0100, salsaman wrote:
> lv_analyser and gdk_pixbuf run, but produce no moving images.
lv_analyzer in CVS is fixed. gdk_pixbuf needs a property telling
the image location. It's for image showing. We will add plugin flags
soon, and also have a flag for specialized plugins so you can check
against this.


> I will try goom if somebody tells me how to.

Install goom2k4. (make sure it's in the right prefix)

reinstall libvisual-plugins, that is './configure ; make ; make install'
check if configure sees goom2k4.

> Mixing 2 actors should be possible but sometimes causes problems with 
> two plugins sharing the same input; with alsa I get a hardware busy error.
> In this case, is it possible that libvisual could simply return a NULL 
> for the input ? Maybe that is what happens already.

Also, will look in the behavior when I try the LiVES devel version :)
It's just easier to answer with real code.

> Almost there now :-)

This is just rockon! seriously, we should meet in Amsterdam and talk
about this stuff :)

Cheers,
Dennis

Re: [Libvisual-devel] Another problem

[Dennis S. <sy...@yo...>]

This is very likely in Libvisual. I'll try out your 
devel version of LiVES this evening and also fix this.

On Mon, 2004-09-13 at 21:46 +0100, salsaman wrote:
> libvisual CRITICAL: no progname: visual_mem_free [(lv_mem.c,46)]: 
> assertion `ptr != NULL' failed
> libvisual CRITICAL: no progname: visual_mem_free [(lv_mem.c,46)]: 
> assertion `ptr != NULL' failed

[Libvisual-devel] Re: Libvisual

[Burkhard P. <pl...@ip...>]

Hi,

> We want to make an API that supports extra capabilities depending on
> the display target being used (plugable).

That sounds good.

> When an app notifies libvisual that it ONLY supports 16 bit and lower
> libvisual will transform 24 and 32 bits surfaces to 16 bit internally.

So it seems that apps still need to know a lot about the
display properties. For xine, mplayer and such, this would be
no problem, but if someone wants just to write a quick and dirty
visualisation app (like gmerlin-visualizer)?

> Like SDL did kinda ?

Probably, but as I said, I don't really like (i.e. know) SDL.
glut and gtkglarea are also exmaples, where apps can pass the
required OpenGL properties.

> I rather have the burdon on libvisual, because that way we don't force
> anything. An example is video editing. There is a program LiVES
> (lives.sf.net) If I'm not wrong that is used for VJ productions. Since
> ehm, this weekend it also supports libvisual, but it's not drawn
> in realtime because of al the video stuff. Basicly we want to take
> as much as possible out of the plugins.

Keeping plugins simple is good.
The problem is that for lemuria, time == frame_count.
Many effect mechanisms (e.g. the animated texture on most
foreground objects) rely on a constant and known framerate.

If you do completely synchronous rendering (i.e. render one picture
each 512 samples), you must render 44100/512 = 86 fps for lemuria.
I don't think, that a "standard" consumer PC is able to do this,
when full antialiasing is enabled :-)

In addition, OpenGL (i.e. GLXSwapBuffers) can be synched to
the vertical frequency of the monitor, and for the high-speed
scenes in lemuria, this is strongly recommended.
Being in sync with both the music and the monitor is impossible.

In addition, the animation speed would change, if one switches to
a track with a different samplerate. For spectrum analyzers, this
doesn't matter but for lemuria it does!

I meditated a lot about this when writing lemuria. The only possible
solution was to render in a separate thread using the
most recent audio samples and limit the framerate using a
software timer (to ca. 30 fps in my case). On weak hardware,
the animation speed becomes slower, but it's always independent
from the audio signal.

Whether the plugins or libvisual handles this is a matter of taste,
but completely synchronous rendering is not possible.

On the other hand, if I use goom for making textures, I also
use synchronous rendering (pass audio samples and get a picture).
For goom2k4, I no longer use the xmms plugin but the
goom library.

>>If libvisual handles all this, the best would be to start an own
>>thread for each plugin. In addition, each plugin should have it's
>>own Display* connection to completely avoid X11/multithread
>>related crashes.
> 
> Keep in mind, that we really don't want to just depend on X11, it should
> work everywhere, framebuffer, gstreamer, xine, whatever you'd like.

I know, I was only talking about the X11 case (the most interesting
for me).

> Well, since a libvisual pipeline is a synchronous stream I don't
> see the reason for threading.

I do (see above) :-)

>>One small thing: make DESTDIR=<some_dir> does not work.
>>It's needed when you want to make rpms.
> 
> How do I solve that, Duilio is doing most of the auto* stuff :)

The problem is the install-exec-local target. There is an
explicit reference to $(prefix)/include/libvisual, which isn't
changed by the DESTDIR mechanism. Maybe using $(includedir) would
help.

Cheers

Burkhard

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

[Libvisual-devel] libvisual GL detection update

[Duilio J. P. <dp...@fc...>]

Now configure checks not only for GL headers, but also
try to link against GL library, and if it fails, it 
shows a warning and disables the GL support on Libvisual.

Probably it needs more work, please report results.

Bye,
Duilio.

Re: [Libvisual-devel] Re: Still a compile problem with 0.1.6

[salsaman <sal...@xs...>]

Duilio Javier Protti wrote:

>You have /usr/X11R6/lib entry on your /etc/ld.so.conf?
>If not, please add it and then run 'ldconfig /usr/X11R6/lib'
>and then try to build.
>
>Please tell us about the results.
>
>
>Bye,
>Duilio.
>
Yes I do have it in /etc/ld.so.conf
ldconfig -v gives:
        libGLU.so.1 -> libGLU.so.1.3.501


Despite the CRITICAL warnings from the other email, I am now able to run 
the following plugins (0.1.6) directly in LiVES:

bumpscope
infinite
jess
oinksie
plasma
lv_scope

lv_analyser and gdk_pixbuf run, but produce no moving images.

I will try goom if somebody tells me how to.

Mixing 2 actors should be possible but sometimes causes problems with 
two plugins sharing the same input; with alsa I get a hardware busy error.
In this case, is it possible that libvisual could simply return a NULL 
for the input ? Maybe that is what happens already.



Almost there now :-)

Salsaman.

[Libvisual-devel] Re: Still a compile problem with 0.1.6

[Duilio J. P. <dp...@fc...>]

You have /usr/X11R6/lib entry on your /etc/ld.so.conf?
If not, please add it and then run 'ldconfig /usr/X11R6/lib'
and then try to build.

Please tell us about the results.


Bye,
Duilio.

> gcc -shared  .libs/madspin.o  
> -L/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin 
> -L/usr/lib -lGL -lGLU /usr/lib/libvisual.so -lm -ldl  -Wl,-soname 
> -Wl,actor_madspin.so -o .libs/actor_madspin.so
> /usr/bin/ld: cannot find -lGLU
> collect2: ld returned 1 exit status
> make[3]: *** [actor_madspin.la] Error 1
> make[3]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins'
> make: *** [install-recursive] Error 1
> [root@ruby libvisual-plugins-0.1.6]# locate libGLU
> /usr/X11R6/lib/libGLU.so.1.3.501
> /usr/X11R6/lib/libGLU.la
> /usr/X11R6/lib/libGLU.so
> /usr/X11R6/lib/libGLU.so.1
>
> ...
>
> Salsaman.

[Libvisual-devel] Another problem

[salsaman <sal...@xs...>]

OK, again with 0.1.6:

in the wrapper, init gets called, followed by process. The first time
visual_actor_run is called, I get the following:

libvisual CRITICAL: no progname: visual_mem_free [(lv_mem.c,46)]: 
assertion `ptr != NULL' failed
libvisual CRITICAL: no progname: visual_mem_free [(lv_mem.c,46)]: 
assertion `ptr != NULL' failed

The screen buffer is NULL the first time the function is called, it is 
then set to the host buffer, out[0]->pixel_data which is non-NULL (I 
have checked).

So it looks like the call to visual_actor_run is trying to free the old 
screenbuffer before setting a new one, and complaining. This should not 
be a CRITICAL error, the buffer should simply not be freed.

I'm 99% sure this is a libvisual error, I could be wrong though.

Salsaman.

Re: [Libvisual-devel] Still a compile problem with 0.1.6

[Dennis S. <sy...@yo...>]

On Mon, 2004-09-13 at 21:05 +0100, salsaman wrote:
> gcc -shared  .libs/madspin.o  
> -L/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin 
> -L/usr/lib -lGL -lGLU /usr/lib/libvisual.so -lm -ldl  -Wl,-soname 
> -Wl,actor_madspin.so -o .libs/actor_madspin.so
> /usr/bin/ld: cannot find -lGLU
> collect2: ld returned 1 exit status
> make[3]: *** [actor_madspin.la] Error 1
> make[3]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin'
> make[2]: *** [install-recursive] Error 1
> make[2]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory 
> `/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins'
> make: *** [install-recursive] Error 1
> [root@ruby libvisual-plugins-0.1.6]# locate libGLU
> /usr/X11R6/lib/libGLU.so.1.3.501
> /usr/X11R6/lib/libGLU.la
> /usr/X11R6/lib/libGLU.so
> /usr/X11R6/lib/libGLU.so.1
> 
> 
> But still, I can't use these GL plugins with LiVES anyway.
> 
> Ah that reminds me, how do I get a list of only the non-gl plugins ?
> 
> 
> 
> Salsaman.


Depends what you want, by name or a VisList of references. By name:

visual_actor_get_next_by_name_nogl (...

http://libvisual.sourceforge.net/libvisual-api-docs/group__VisActor.html#ga4

[Libvisual-devel] Still a compile problem with 0.1.6

[salsaman <sal...@xs...>]

gcc -shared  .libs/madspin.o  
-L/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin 
-L/usr/lib -lGL -lGLU /usr/lib/libvisual.so -lm -ldl  -Wl,-soname 
-Wl,actor_madspin.so -o .libs/actor_madspin.so
/usr/bin/ld: cannot find -lGLU
collect2: ld returned 1 exit status
make[3]: *** [actor_madspin.la] Error 1
make[3]: Leaving directory 
`/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor/madspin'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory 
`/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins/actor'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory 
`/usr/local/pubsoft/libvisual-plugins-0.1.6/plugins'
make: *** [install-recursive] Error 1
[root@ruby libvisual-plugins-0.1.6]# locate libGLU
/usr/X11R6/lib/libGLU.so.1.3.501
/usr/X11R6/lib/libGLU.la
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGLU.so.1


But still, I can't use these GL plugins with LiVES anyway.

Ah that reminds me, how do I get a list of only the non-gl plugins ?



Salsaman.

Re: [Libvisual-devel] amaroK 1.1-beta2 released

[Dennis S. <sy...@yo...>]

Congrats you guys, keep up the good work, and advertise for libvisual! 
*grin*.

Cheers,
Dennis


On Mon, 2004-09-13 at 11:51 +0200, Mark Kretschmann wrote:
> The amaroK team announces version 1.1-beta2 of the amaroK audio player

[Libvisual-devel] amaroK 1.1-beta2 released

[Mark K. <ma...@we...>]

The amaroK team announces version 1.1-beta2 of the amaroK audio player

This release not only fixes many bugs from the previous beta version, but
also introduces some stunning new features. We invite our users to test the
program thoroughly, as this will likely be the last beta release before
1.1-final.


New in this version:

* Crossfading support for GStreamer
* Custom Smart Playlists
* Animated systray icon with progress display
* Support for the Media Application Server (MAS)
* Color scheming for player window
* K3B integration for direct CD burning
* Cool-Streams, a collection of recommended radio streams
* Cutting edge SQLite-3 database
* Third category for Collection filtering
* Support for LibVisual 0.1.6
* Rating system for music

Please refer to the ChangeLog for a detailed list of changes.


The amaroK team
---------------

WWW : http://amarok.kde.org
IRC : irc.freenode.net #amarok
MAIL: ama...@li...

[Libvisual-devel] New jack input plugin and fixed the analyzer

[Dennis S. <sy...@yo...>]

Heya, for those who are interested:

We now have a rock solid jack input plugin (jack is really good btw,
everyone else should stop trying to do an sound server like thing).

And I, after >6< months. FINALLLLLY

Fixed the analyzer.

Lots to come btw, we are just beginning.

Cheers,
Dennis

Re: [Libvisual-devel] Did it !

[Dennis S. <sy...@yo...>]

Are you using CVS ?

We were checking a bit too much in the transformer.

It should be fixed in 0.1.6, would be nice if you
could verify tho :)

Cheers,
Dennis

> > Jackdaw is giving the following error:
> >
> > libvisual CRITICAL: no progname: 
> > visual_video_depth_transform_to_buffer [(lv_video.c,977)]:
> > assertion `pal != NULL && pal->ncolors == 256' failed
> 
> 
> Getting the same message for Jess, too. This is very strange as I forced 
> the palette to 24 bit.

[Libvisual-devel] Some quick test results

[salsaman <sal...@xs...>]

libinfinite, video buffer size 640x480, resize by LiVES to full screen 
(1024x768) ouptut, SDL playback.

fps ~=33.

Machine: 2.4 GHz single P4, 512Mb

Not too bad, it's roughly comparable to loading frames from disk.


Output slows down a lot though when mixing in realtime.
The same clip mixed with a 600x400 video clip, luma overlay and the fps 
drops to about 8.
For mixing, a smaller output size (e.g. 320x240) can be used.
libvisual 320x240 mixed with video clip 600x400, screen size 1024x768, 
fps ~=13.

Will continue testing...

Salsaman.