Menu
▾
▴
libvisual-devel
|
From: salsaman <sal...@xs...> - 2005-02-25 13:04:30
|
lib...@li... wrote: >Send Libvisual-devel mailing list submissions to > lib...@li... > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/libvisual-devel >or, via email, send a message with subject or body 'help' to > lib...@li... > >You can reach the person managing the list at > lib...@li... > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Libvisual-devel digest..." > > >Today's Topics: > > 1. Introduction/tutorial (=3D?utf-8?Q?Jon_=3DC3=3D98yvind_Kjellman?=3D= ) > >--__--__-- > >Message: 1 >To: > "lib...@li..." <lib...@li...urcef= orge.net> >Date: Thu, 24 Feb 2005 22:28:50 +0100 >From: "=3D?utf-8?Q?Jon_=3DC3=3D98yvind_Kjellman?=3D" <jo...@so...= t> >Subject: [Libvisual-devel] Introduction/tutorial >Reply-To: lib...@li... > >Hello, I'm looking for a general plugin library to use in a multimedia =20 >system for a car. From what I've read about libvisual I do the drawing s= o =20 >my app, which mainly uses OpenGL for graphics and xine-lib for audio, =20 >could use this library for plugins, right? However, how do I get started= ? =20 >I found the API reference (worth gold,) but I haven't found a =20 >startingpoint. Does there exist a simple tutorial, a HOWTO or a tiny =20 >(0-100 lines) example? I'm looking into the examples now, but I had to =20 >grab them from CVS. IMHO they should be included with the library. At th= e =20 >moment ./configure --enable-examples && make doesn't seem to produce any= =20 >executables. > >Best, >Jon =C3=98yvind Kjellman > > > >--__--__-- > >_______________________________________________ >Libvisual-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libvisual-devel > > >End of Libvisual-devel Digest > > > =20 > Hi Jon, you might want to look at my libvis.c, which is a wrapper to init/deinit=20 and create a single frame of video: http://cvs.sourceforge.net/viewcvs.py/lives/lives-plugins/livido-plugins/= libvis.c Regards, Gabriel. |
|
From: <jo...@so...> - 2005-03-01 03:21:54
|
Thanks, alsa input works ok now, although still upside down (I only noticed it on the G-Force text.) What am I doing wrong? In my project I want the option to choose random plug-ins. I started hacking some nasty code to switch plug-in, but noticed visual_bin_switch_actor_by_name(). How does this work? Will it create a new actor? ... destroy the old? ... preserve rundepth (8bit -> 24bit) set during visual_actor_video_negotiate()? Not entirely on the topic of libvisual, but in my project I'm rendering the plug-in in the background with some other tings in front of it. However when I tried with the OpenGL based plug-ins it is a royal mess. It displays, but there are lots of strange artifacts. I'm pretty sure it's due to me messing up OpenGL buffers and attributes the plug-in uses and it messing it up for me. The question is (besides any good ideas on how to do this in a working fassion): are OpenGL plug-ins allowed everything (by convention) or do they adhere to some rules which may make my life simpler? Are there anyone working on a xine-lib input plug-in? >> If you're interested, when I get it to work properly I could create a >> short tutorial. However it would need to be reviewed as there probably >> would be some mistakes. > > I am very interested in this, I want to work up our state of docs, I > also want to startup a wiki as a source of information and the such. I've started writing on a small tutorial and I'll 'bomb' the example with relevant comments. I'll post it for review when it's done. > I understand that you're working on some car multimedia project ? do > you have urls regarding this, I am very interested about all this! :) No urls at the moment. It isn't release worthy yet. But it'll be open-sourced and I'll post something here when I unleash it on the net (shouldn't be many weeks.) best, Jon Øyvind |
|
From: Dennis S. <sy...@yo...> - 2005-03-01 12:37:12
|
On Tue, 2005-03-01 at 04:29 +0100, Jon =C3=98yvind Kjellman wrote:
> Thanks, alsa input works ok now, although still upside down (I only =20
> noticed it on the G-Force text.) What am I doing wrong?
I am not sure, but I see Vitaly using the following within lvdisplay
it's glx driver:
glMatrixMode(GL_PROJECTION);
glPixelZoom(1.0f, -1.0f);
glRasterPos2f(-1.0f, 1.0f);
glDrawPixels(....
Regarding lvdisplay, it's our in development displaying framework :)
> In my project I want the option to choose random plug-ins. I started =20
> hacking some nasty code to switch plug-in, but noticed =20
> visual_bin_switch_actor_by_name(). How does this work? Will it create a=
=20
> new actor? ... destroy the old? ... preserve rundepth (8bit -> 24bit) s=
et =20
> during visual_actor_video_negotiate()?
When using a bin, you should use it 'managed', it supports fading=20
between plugins, however there are some serious problems with it.
The whole VisBin will be replaced within this devel cycle to make
place for VisPipeline, we will still have a VisBin but that would
serve as an abstract facade to the VisPipeline stuff.
I think it's wiser to deal with the actor yourself for now, and sit
in there till the new code is there, if you decide otherwise,
check the xmms and bmp plugin out. Also the 'morph' example
(which is outdated[tm]), might proof some basic information. It it
doesn't work out, ask again :)
> Not entirely on the topic of libvisual, but in my project I'm rendering=
=20
> the plug-in in the background with some other tings in front of it. =20
> However when I tried with the OpenGL based plug-ins it is a royal mess.=
It =20
> displays, but there are lots of strange artifacts. I'm pretty sure it's=
=20
> due to me messing up OpenGL buffers and attributes the plug-in uses and=
it =20
> messing it up for me. The question is (besides any good ideas on how to=
do =20
> this in a working fassion): are OpenGL plug-ins allowed everything (by =
=20
> convention) or do they adhere to some rules which may make my life simp=
ler?
I am pretty sure this is possible, we had a discussion on this
before. AND we want to support blit overlaying in GL, however=20
honestly, I am not GL master, I think Vitaly has to jump in here
and help you, so, Vitaly, or any other openGL know it all, help him
out! :)
> Are there anyone working on a xine-lib input plug-in?
Nope, and this would be GREATLY appreciated, also native xine support ;)
so they can use lv to render libvisual :)
> > I am very interested in this, I want to work up our state of docs, I
> > also want to startup a wiki as a source of information and the such.
>=20
> I've started writing on a small tutorial and I'll 'bomb' the example wi=
th =20
> relevant comments. I'll post it for review when it's done.
Sounds superb, in what format are you writing the tutorial ? I would
love a docbook, if this is not too hard :) (anything other
would be cool of course)
> > I understand that you're working on some car multimedia project ? do
> > you have urls regarding this, I am very interested about all this! :)
>=20
> No urls at the moment. It isn't release worthy yet. But it'll be =20
> open-sourced and I'll post something here when I unleash it on the net =
=20
> (shouldn't be many weeks.)
Ok keep us updated, this is super!
Cheers,
Dennis
|
|
From: <jo...@so...> - 2005-02-25 22:44:48
|
Thanks, but I didn't really get very far with that. I still don't understand what overall design is, or how it works. I'm trying to get the examples to compile but it won't link. visual_bin_destroy and visual_video_free is missing. I grabbed the examples from CVS, but I'm compiling against 0.2.0 and make ignores the examples (configure --enable-examples && make). I've tried pure CVS too, but autoconf/configure chockes. Thus I have one feature request: make an introduction text of some sort!! Just cover the basic, simple example, linker options, a few caveats and the usual stuff. So that programmers like myself who stumble over this seemingly great library can get cracking in an hour. I would have written it myself, had I known how to use the library. Best, Jon Øyvind Kjellman On Fri, 25 Feb 2005 14:13:17 +0100, salsaman <sal...@xs...> wrote: > Hi Jon, > you might want to look at my libvis.c, which is a wrapper to init/deinit > and create a single frame of video: > > http://cvs.sourceforge.net/viewcvs.py/lives/lives-plugins/livido-plugins/libvis.c > > Regards, > Gabriel. |
|
From: <jo...@so...> - 2005-02-25 22:55:19
|
Hep, got the examples to work (at least it compiles) by commenting out those two. Shouldn't be a problem in the example. Jon Øyvind Kjellman On Fri, 25 Feb 2005 23:52:07 +0100, Jon Øyvind Kjellman <jo...@so...> wrote: > Thanks, but I didn't really get very far with that. I still don't > understand what overall design is, or how it works. > > I'm trying to get the examples to compile but it won't link. > visual_bin_destroy and visual_video_free is missing. I grabbed the > examples from CVS, but I'm compiling against 0.2.0 and make ignores the > examples (configure --enable-examples && make). > > I've tried pure CVS too, but autoconf/configure chockes. Thus I have one > feature request: make an introduction text of some sort!! Just cover the > basic, simple example, linker options, a few caveats and the usual > stuff. So that programmers like myself who stumble over this seemingly > great library can get cracking in an hour. I would have written it > myself, had I known how to use the library. > > Best, > Jon Øyvind Kjellman > > On Fri, 25 Feb 2005 14:13:17 +0100, salsaman <sal...@xs...> wrote: > >> Hi Jon, >> you might want to look at my libvis.c, which is a wrapper to >> init/deinit and create a single frame of video: >> >> http://cvs.sourceforge.net/viewcvs.py/lives/lives-plugins/livido-plugins/libvis.c >> >> Regards, >> Gabriel. > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libvisual-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libvisual-devel |
|
From: Duilio J. P. <dp...@fc...> - 2005-02-26 15:28:35
|
Is true, the examples are really out of date, but that's because they are not included on the distro, and libvisual is under heavy development, so API changes occur very often. visual_bin_destroy() was deprecated when libvisual moves to his new object-model. Now almost every datatype is whithin an object, so destruction is made on a generic fashion through visual_object_destroy (). To compile a program which's is using libvisual, just pass the result of `pkg-config libvisual --cflags` to you compiler, and for to link against libvisual, pass the result of `pkg-config libvisual --libs` to the linker. And you are right, we need a tutorial and probably a FAQ too! Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2005-02-26 16:23:13
|
Moin, I think we should start up a documentation and information strategy. We're getting lack of information complaints more often recently. Some people manage very well, but these often have extraordinary experience with programming and the concepts of topic. So for them an API reference is anough. I think we have to do the following: 1. Explain the API reference with more information, and include a start page within that explains the basic setup. 2. Create docbooks that are written in tutorial style, for application development, and plugin development. 3. Start up an online WIKI (using mediawiki software) so we can share thoughts, documents, howtos, and todos over there. (When one will come I plan to only allow edits for people who subscribe, since wiki vandalism is completely cool nowadays) On the object_destroy, it's true but it's best to exclusively always use: visual_object_unref (VISUAL_OBJECT (object)); Only use _destroy if you REALLY know what you're doing :) Cheers, Dennis On Sat, 2005-02-26 at 12:20 -0500, Duilio J. Protti wrote: > Is true, the examples are really out of date, but that's because they > are not included on the distro, and libvisual is under heavy > development, so API changes occur very often. > > visual_bin_destroy() was deprecated when libvisual moves to his new > object-model. Now almost every datatype is whithin an object, so > destruction is made on a generic fashion through visual_object_destroy > (). > > To compile a program which's is using libvisual, just pass the result of > `pkg-config libvisual --cflags` to you compiler, and for to link against > libvisual, pass the result of `pkg-config libvisual --libs` to the > linker. > > And you are right, we need a tutorial and probably a FAQ too! > > > Bye, > Duilio. |
|
From: <jo...@so...> - 2005-02-27 01:39:25
|
Thanks for the advice, I created a small test program that runs, though I
have some issues:
1. The program displays, but doesn't react to the music using alsa input.
mplayer plug-in fails with:
> libvisual ERROR: ./example: inp_mplayer_init(): \
> Could not open file '/home/jon/.mplayer/mplayer-af_export': No such file
> or directory
I'm unable to test with others. The examples from CVS failed similarly
1. When a plug-in is 8-bit, is it always palette based or can it be gray
scale. How do I determine?
2. Take a look at display(), are my assumptions about color representation
good? Does plug-in's use alpha channel?
3. Why doesn't visual_actor_new("foobar") return NULL if "foobar" doesn't
exist?
4. Looking at the source. Why does the for-loop printing input names work
(commented out), but the one printing actor names SIGSEGV?
A last observation. There exists a function visual_video_new_with_buffer()
which will create a VisVideo object and allocate a buffer. However I have
found no way to re-size the VisVideo object which will also re-size the
buffer. I have to do this with visual_video_allocate_buffer() (btw. the
docs doesn't mention that this _reallocates_ under certain circumstances.)
Personally, IMHO, I find it a bit inconsistent, the object does keep track
of whether or not it's in charge of buffer resizing and could very well
perform the re-size within visual_video_set_dimension().
Just my $0.02.
If you're interested, when I get it to work properly I could create a
short tutorial. However it would need to be reviewed as there probably
would be some mistakes.
Best,
Jon Øyvind Kjellman
Don't know if the list allows attachments so here's the code:
makefile:
=========
CC = gcc
CFLAGS = -g -std=c99
LIBS = -L/usr/X11R6/lib -lpthread -lm -ldl -lvisual -lglut
example: example.c
$(CC) $(CFLAGS) $(LIBS) -o $@ $<
clean:
rm example
example.c:
==========
#include <GL/glut.h>
#include <GL/gl.h>
#include <libvisual/libvisual.h>
#include <string.h>
#include <stdlib.h>
VisInput* input = NULL;
VisActor* actor = NULL;
VisVideo* video = NULL;
VisBin* bin = NULL;
VisVideoDepth depth = VISUAL_VIDEO_DEPTH_ERROR;
GLuint window = 0, width = 640, height = 480;
int use_gl = 0;
/* Standard glut keyboard function.
* Kills the program on any keypress. */
void key_func(unsigned char k, int x, int y)
{
glutDestroyWindow(window);
exit(0);
}
/* Standard glut resize function. */
void resize(int w, int h)
{
width = w;
height = h;
glViewport(0, 0, width, height);
if(visual_video_set_dimension(video, width, height) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to resize video.");
if(!use_gl)
/* visual_video_set_dimension doesn't resize the buffer so ... */
if(visual_video_allocate_buffer(video) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to resize buffer.");
/* This lets actor know about the format change. */
if(visual_actor_video_negotiate(actor, 0, FALSE, FALSE) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "actor/video negotiation failed.");
}
/* Standard glut display function. */
void display()
{
glClear(GL_COLOR_BUFFER_BIT);
/* This renders. */
visual_bin_run(bin);
if(!use_gl) {
/* We have to render video's buffer. */
GLenum format = GL_R3_G3_B2; /* Reasonable safety against reads
outside of the buffer. */
switch(visual_video_bpp_from_depth(depth)) {
case 4:
format = GL_RGBA;
break;
case 3:
format = GL_RGB;
break;
case 2:
format = GL_RGBA4;
break;
/* case 1: defaults */
}
glDrawPixels(width, height, format, GL_UNSIGNED_BYTE,
(void*)video->pixels);
}
glutSwapBuffers();
glutPostRedisplay();
}
int main(int argc, char** argv)
{
/* GLUT initialization */
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE);
glutInitWindowPosition(100, 100);
glutInitWindowSize(width, height);
window = glutCreateWindow("LibVisual example");
glutDisplayFunc(display);
glutReshapeFunc(resize);
glutKeyboardFunc(key_func);
/* We init libvisual after glut since some plug-ins need
* OpenGL during initialization.
*/
if(visual_init(&argc, &argv) < 0)
visual_log(VISUAL_LOG_ERROR, "Couldn't initialize Libvisual.");
char* input_name = NULL;
char* actor_name = NULL;
for(int i = 1; i < argc; ++i) {
if(strcmp(argv[i], "--actor") == 0 && i+1 < argc)
actor_name = argv[++i];
else if(strcmp(argv[i], "--input") == 0 && i+1 < argc)
input_name = argv[++i];
else if(strcmp(argv[i], "--help") == 0) {
printf("LibVisual example.\n");
printf("Use --actor and --input flags to specify\nplug-in and source
from list below.\n");
printf("\nAvaiable inputs:\n");
VisListEntry* i;
for(i = visual_input_get_list()->head; i; i = i->next)
printf("%s\n", ((VisPluginRef*)i->data)->info->name);
printf("\nAvaiable actors:\n");
/* for(i = visual_actor_get_list()->head; i; i = i->next)
printf("%s\n", ((VisActor*)i->data)->plugin->info->plugname);*/
for(char* name = visual_actor_get_next_by_name_nogl(NULL); name;
name = visual_actor_get_next_by_name_nogl(name))
printf("%s\n", name);
for(char* name = visual_actor_get_next_by_name_gl(NULL); name;
name = visual_actor_get_next_by_name_gl(name))
printf("%s (OpenGL)\n", name);
return 0;
}
}
if(!actor_name) actor_name = "oinksie"; /* Default actor */
if(!input_name) input_name = "alsa"; /* Default input */
if((input = visual_input_new(input_name)) == NULL)
visual_log(VISUAL_LOG_ERROR, "No input loaded.");
/* initializes input plug-in */
if(visual_input_realize(input) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to realize input.");
if((actor = visual_actor_new(actor_name)) == NULL)
visual_log(VISUAL_LOG_ERROR, "No actor loaded.");
/* initializes actor plug-in */
if(visual_actor_realize(actor) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to realize actor.");
depth = visual_actor_get_supported_depth(actor);
if(depth == VISUAL_VIDEO_DEPTH_NONE || depth == VISUAL_VIDEO_DEPTH_ERROR)
visual_log(VISUAL_LOG_ERROR, "Received fubar depthflag.");
if(!(depth & VISUAL_VIDEO_DEPTH_GL)) {
if(depth & VISUAL_VIDEO_DEPTH_32BIT)
depth &= VISUAL_VIDEO_DEPTH_32BIT;
else if(depth & VISUAL_VIDEO_DEPTH_24BIT)
depth &= VISUAL_VIDEO_DEPTH_24BIT;
else if(depth & VISUAL_VIDEO_DEPTH_16BIT)
depth &= VISUAL_VIDEO_DEPTH_16BIT;
else if(depth & VISUAL_VIDEO_DEPTH_8BIT)
depth &= VISUAL_VIDEO_DEPTH_8BIT;
visual_log(VISUAL_LOG_INFO, "Using %d bit framebuffer.",
visual_video_bpp_from_depth(depth) * 8);
} else {
depth &= VISUAL_VIDEO_DEPTH_GL;
use_gl = 1;
visual_log(VISUAL_LOG_INFO, "Using OpenGL plug-in.");
}
if(!use_gl) {
/* Plugin isn't OpenGL */
video = visual_video_new_with_buffer(width, height, depth);
} else {
video = visual_video_new();
if(visual_video_set_depth(video, depth) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to set depth on video.");
}
if(visual_actor_set_video(actor, video) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "Unable to set video for actor.");
/* This lets actor know about the format of video. */
if(visual_actor_video_negotiate(actor, 0, FALSE, FALSE) != VISUAL_OK)
visual_log(VISUAL_LOG_ERROR, "actor/video negotiation failed.");
/* Associate input with actor. */
bin = visual_bin_new();
visual_bin_connect(bin, actor, input);
visual_bin_realize(bin);
glEnable(GL_TEXTURE_2D);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
if(use_gl)
glFrustum(-0.5, 0.5, -0.5, 0.5, 0.1, 10000);
else
glOrtho(-1, 1, -1, 1, 0.1, 1);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
/* Enters the main (Free)GLUT processing loop. */
glutMainLoop();
return 0;
}
|
|
From: Dennis S. <sy...@yo...> - 2005-02-28 21:10:19
|
On Sun, 2005-02-27 at 02:46 +0100, Jon =C3=98yvind Kjellman wrote:
> Thanks for the advice, I created a small test program that runs, though=
I =20
> have some issues:
>=20
> 1. The program displays, but doesn't react to the music using alsa inpu=
t. =20
> mplayer plug-in fails with:
> > libvisual ERROR: ./example: inp_mplayer_init(): \
> > Could not open file '/home/jon/.mplayer/mplayer-af_export': No such f=
ile =20
> > or directory
You have to open the alsa capture gain, using alsamixer (this is=20
incredibly lame, I agree). (it works perfectly with alsa here) (your=20
example that is)
> I'm unable to test with others. The examples from CVS failed similarly
> 1. When a plug-in is 8-bit, is it always palette based or can it be gra=
y =20
> scale. How do I determine?
It's palette based, period :) You retrieve the palette from a VisActor=20
using VisPalette *visual_actor_get_palette (VisActor *actor).
> 2. Take a look at display(), are my assumptions about color representat=
ion =20
> good? Does plug-in's use alpha channel?
The framework uses alpha channels for overlaying and such, but plugins=20
themself (are right now) not actively using alpha channels.
I think the color ordering seems right, tho I am not sure how it would=20
hold on other endianess systems. Tho you draw the frame upside down :)
(Just pointing out)
> 3. Why doesn't visual_actor_new("foobar") return NULL if "foobar" doesn=
't =20
> exist?
It's returns a plugin less VisActor. VisActor is just a facade for the
underlaying VisActorPlugin stuff, and it helps you with video=20
negotiation. You can check for a plugin it's existance by doing:
int visual_actor_valid_by_name (const char *name)
> 4. Looking at the source. Why does the for-loop printing input names wo=
rk =20
> (commented out), but the one printing actor names SIGSEGV?
for(i =3D visual_actor_get_list()->head; i; i =3D i->next)
printf("%s\n", ((VisPluginRef*)i->data)->info->plugname);
Use that, just like with the input_get_list, it's a filtered
list from the global plugin registry (VisPluginRefs) list.
> A last observation. There exists a function visual_video_new_with_buffe=
r() =20
> which will create a VisVideo object and allocate a buffer. However I ha=
ve =20
> found no way to re-size the VisVideo object which will also re-size the=
=20
> buffer. I have to do this with visual_video_allocate_buffer() (btw. the=
=20
> docs doesn't mention that this _reallocates_ under certain circumstance=
s.) =20
> Personally, IMHO, I find it a bit inconsistent, the object does keep tr=
ack =20
> of whether or not it's in charge of buffer resizing and could very well=
=20
> perform the re-size within visual_video_set_dimension().
After a resize, you can safely to visual_video_allocate_buffer, this=20
will free, the old one if it was allocated internally, by
new_with_buffer for example, and after that reallocate a new buffer.
If you manage your own allocated buffer, don't use this function but=20
manage your allocating yourself.
> If you're interested, when I get it to work properly I could create a =20
> short tutorial. However it would need to be reviewed as there probably =
=20
> would be some mistakes.
I am very interested in this, I want to work up our state of docs, I=20
also want to startup a wiki as a source of information and the such.
I understand that you're working on some car multimedia project ? do=20
you have urls regarding this, I am very interested about all this! :)
> Best,
> Jon =C3=98yvind Kjellman
Cheers,
Dennis
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X