On 12/13/05, Nuno Godinho eu@nunogodinho.com wrote:
Hi,
This is a P4 at 3.2GHz with 1Gb of RAM and an ATI 9600 video card. Not the best in the world but I would say its acceptable for my intents.
Hum... so, from what you say... what I want to do is indeed performance intensive. But how can this be if in Adobe Premiere I can run much more videos simultaneously and still apply some filters on the fly?
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
I thought the idea of turning off the invisible videos was quite reasonable. But somehow pd takes over 1 second to react and turn one video on or off.
That should be a reasonable solution and I haven't seen the same thing happen here with turning the gemhead on and off. I do have a problem where the first time I turn on rendering with a DirectShow or Quicktime object the output is like one frame every few seconds. Turning rendering off and back on makes everything run at full speed. Maybe try your DV clips as Quicktime rather than AVI?
I could use a slightly slower framerate... But this would only be a temporary solution.
I only have the FireGL here, but I might try an Nvidia card to see if anything changes.
Thanks, Nuno
hi all,
Am Dienstag 13 Dezember 2005 18:22 schrieb chris clepper: [...snip...]
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
the real bottleneck here isnt the cpu, nor the gfx card, but the bus, either agp, pci, whatever. for a dual g5 it just sucks to handle only 4 clips, as well as for any other modern machine.
open gl isnt meant for doing video stuff, thats it. you cant expect your machine to pump excessive amounts of data through the bus to the card just because that particular card's open-gl is fast. it wouldnt be a big problem to project the same video onto many objects with little effort, since it would be uploaded only once. but having three videos means 3 times the data is flowing through the bus.
you could also use plain framebuffer cards, either rgb or yuv, and the net result would be the same. many high end video editing solutions a few year agos had their own scsi bus on the video card, to bypass all that and thus allowing for many streams "at once on the fly"
im pretty sure that it would be more performant to do the raw mixing on the host cpu and the use the result to feed gem...... even more when doing that with optimized mmx/sse/altivec code. the gfx card may be theortical able to that as well, probably more complex arrangements as well, but it comes to an halt when it comes to transfer the seperate streams to the card ....
maybe a way would be to implement the decompression onto the gfx card itself, so that the compressed streams can go directly to the card, either mpeg, mjpeg, or whatever.
greets,
chris
Hi,
I see. What you say makes sense.
There's a peculiar behaviour though: I have a [ctlin] followed by a [number] on top of everything. Even when I get down to one or two videos, the [ctlin] still has a delay and when I move a fade in my MIDI interface it takes it one or more seconds to reflect the changes. So everything is totally slowed down, even with one video. Isn't it strange? Incresing the number of videos makes it worse, of course.
You suggest implementing the decompression on the gfx but not only I wouldn't know how to do it (not even where to start!), I don't intend to go to such low level to implement something which seems so simple.
Actually I am not making any good use of texturing since I just want to overlay fullscreen films, so I'd say OpenGL is not really needed, right? No 2D or 3D here at all. But I guess that while using GEM there is no way around it, right?
What alternatives do I have to GEM that could bypass this problem (win32)?
I've tried VJ applications like Arkaos that are stunning fast at running multiple videos at the same time without any skipped frame and projecting them on 2D and 3D cubes and such, everything rotating on-the-fly. So it must be possible! Unfortunately, although what I intend to do is quite simple, Arkaos and its siblings are too limited for it.
Thanks, Nuno
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Christian Klippel Sent: terça-feira, 13 de Dezembro de 2005 17:57 To: pd-list@iem.at Subject: Re: [PD] Fading between 4 videos - performance issues
hi all,
Am Dienstag 13 Dezember 2005 18:22 schrieb chris clepper: [...snip...]
Premiere is probably not texturing the video using OpenGL,
but rather
using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3
1080i60 ones.
At least 6 DV clips are possible as well.
the real bottleneck here isnt the cpu, nor the gfx card, but the bus, either agp, pci, whatever. for a dual g5 it just sucks to handle only 4 clips, as well as for any other modern machine.
open gl isnt meant for doing video stuff, thats it. you cant expect your machine to pump excessive amounts of data through the bus to the card just because that particular card's open-gl is fast. it wouldnt be a big problem to project the same video onto many objects with little effort, since it would be uploaded only once. but having three videos means 3 times the data is flowing through the bus.
you could also use plain framebuffer cards, either rgb or yuv, and the net result would be the same. many high end video editing solutions a few year agos had their own scsi bus on the video card, to bypass all that and thus allowing for many streams "at once on the fly"
im pretty sure that it would be more performant to do the raw mixing on the host cpu and the use the result to feed gem...... even more when doing that with optimized mmx/sse/altivec code. the gfx card may be theortical able to that as well, probably more complex arrangements as well, but it comes to an halt when it comes to transfer the seperate streams to the card ....
maybe a way would be to implement the decompression onto the gfx card itself, so that the compressed streams can go directly to the card, either mpeg, mjpeg, or whatever.
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
I'm using Gem version 0.90. It compiled without problems (mandriva linux). When I try to place a gemwin object in pd, pd crashes. pd: line 1: 31796 Segmentation fault It tried versions 0.38-4 and 0.39.2 of pd with similar results. I never had this problem with other pd objects though. Did anyone have the same problem or has any ideas what I could do to fix it? Maybe I'm missing something obvious.
Thanks, thomas
hello,
Try:
gdb pd -lib Gem
and then load the patch.
When you get the segault you should see this in the terminal:
(gdb)
then do a "bt" and send us the result.
b.
On Tue, December 13, 2005 1:53 pm, Thomas Hoernlein said:
Hi,
I'm using Gem version 0.90. It compiled without problems (mandriva linux). When I try to place a gemwin object in pd, pd crashes. pd: line 1: 31796 Segmentation fault It tried versions 0.38-4 and 0.39.2 of pd with similar results. I never had this problem with other pd objects though. Did anyone have the same problem or has any ideas what I could do to fix it? Maybe I'm missing something obvious.
Thanks, thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
B. Bogart wrote:
hello,
Try:
gdb pd -lib Gem
and then load the patch.
When you get the segault you should see this in the terminal:
(gdb)
then do a "bt" and send us the result.
b.
On Tue, December 13, 2005 1:53 pm, Thomas Hoernlein said:
Hi,
I'm using Gem version 0.90. It compiled without problems (mandriva linux). When I try to place a gemwin object in pd, pd crashes. pd: line 1: 31796 Segmentation fault It tried versions 0.38-4 and 0.39.2 of pd with similar results. I never had this problem with other pd objects though. Did anyone have the same problem or has any ideas what I could do to fix it? Maybe I'm missing something obvious.
Thanks, thomas
Hello,
the debugger shows the following results:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208138304 (LWP 3805)] 0x42500150 in glClearColor () from /usr/X11R6/lib/libGL.so.1
(gdb) bt #0 0x42500150 in glClearColor () from /usr/X11R6/lib/libGL.so.1 #1 0x081629c0 in ?? () #2 0x081629c0 in ?? () #3 0xbfffd608 in ?? () #4 0x080550a3 in canvas_getcurrent () at g_canvas.c:142 #5 0x00000000 in ?? () #6 0x08164020 in ?? () #7 0xb7f67e40 in ?? () from /usr/local/lib/pd/extra/Gem.pd_linux #8 0xbfffd638 in ?? () #9 0xb7f67e40 in ?? () from /usr/local/lib/pd/extra/Gem.pd_linux #10 0x41a00000 in ?? () #11 0x081629c0 in ?? () #12 0xbfffd638 in ?? () #13 0xb7e6efd9 in gemwin::gemwin () from /usr/local/lib/pd/extra/Gem.pd_linux #14 0xb7e6efd9 in gemwin::gemwin () from /usr/local/lib/pd/extra/Gem.pd_linux #15 0xb7e6f062 in _classgemwin () from /usr/local/lib/pd/extra/Gem.pd_linux #16 0x0809efa3 in pd_typedmess (x=0x12740, s=0x0, argc=0, argv=0x10) at m_class.c:732
seems to be a flaw with my libGL. Any ideas?
Thanks, Thomas
Am 13.12.2005 um 19:21 schrieb Nuno Godinho:
Hi,
I see. What you say makes sense.
There's a peculiar behaviour though: I have a [ctlin] followed by a
[number] on top of everything. Even when I get down to one or two videos,
the [ctlin] still has a delay and when I move a fade in my MIDI interface it
takes it one or more seconds to reflect the changes. So everything is
totally slowed down, even with one video. Isn't it strange? Incresing the number
of videos makes it worse, of course.
had the same phenomenon with midi controls and a heavy gem patch
recently. i solved the situation with a workaround: two instances of
pd on the same machine, one receiving the MIDI data from the faders
and redirecting it to netsend localhost. the second instance of pd
was running the gem patch, controlled by the netreceive data. this
was on os x though.
max
On 12/13/05, Nuno Godinho eu@nunogodinho.com wrote:
You suggest implementing the decompression on the gfx but not only I wouldn't know how to do it (not even where to start!), I don't intend to go to such low level to implement something which seems so simple.
Actually I am not making any good use of texturing since I just want to overlay fullscreen films, so I'd say OpenGL is not really needed, right? No 2D or 3D here at all. But I guess that while using GEM there is no way around it, right?
GEM only has an OpenGL rendering path.
What alternatives do I have to GEM that could bypass this problem (win32)?
I've tried VJ applications like Arkaos that are stunning fast at running multiple videos at the same time without any skipped frame and projecting them on 2D and 3D cubes and such, everything rotating on-the-fly. So it must be possible! Unfortunately, although what I intend to do is quite simple, Arkaos and its siblings are too limited for it.
Arkaos might be using DirectX for rendering?
Texturing performance should be better, and I am looking into it, but there is a lot of Windows crap I have to take care of first.
On 12/13/05, Christian Klippel ck@mamalala.de wrote:
hi all,
Am Dienstag 13 Dezember 2005 18:22 schrieb chris clepper: [...snip...]
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
the real bottleneck here isnt the cpu, nor the gfx card, but the bus, either agp, pci, whatever. for a dual g5 it just sucks to handle only 4 clips, as well as for any other modern machine.
Except the half-dozen lines of Apple specific GL code we use in GEM that turns on full DMA uploads of YUV textures makes HD possible on that platform. On the Windows side I haven't found the critical DMA path for NV or ATI. It is possible for the hardware to do, but if the functionality isn't exposed then it's lost.
open gl isnt meant for doing video stuff, thats it. you cant expect your machine to pump excessive amounts of data through the bus to the card just because that particular card's open-gl is fast. it wouldnt be a big problem to project the same video onto many objects with little effort, since it would be uploaded only once. but having three videos means 3 times the data is flowing through the bus.
Again, GL/AGP/PCIe is just fine for handling large video streams as long as that functionality is available.
im pretty sure that it would be more performant to do the raw mixing on the host cpu and the use the result to feed gem...... even more when doing that with optimized mmx/sse/altivec code. the gfx card may be theortical able to that as well, probably more complex arrangements as well, but it comes to an halt when it comes to transfer the seperate streams to the card ....
Spreading the work equally between CPU and GPU is the fastest path.
One of the recent projects here had 16 640x480 textures of which about 6 to 8 played at 30 fps at once and all of the mixing, color treatment and transparency was done on the GPU. The Altivec code I wrote to do the same is pretty good, but at a certain level you just run out of CPU cycles. In this case the decompression of the video clips and recording of the incoming live camera video took up the CPU resources. Turning off DMA texture uploads increased the CPU load almost 60%, so that is of course critical to have.
maybe a way would be to implement the decompression onto the gfx card itself, so that the compressed streams can go directly to the card, either mpeg, mjpeg, or whatever.
That would be great to have, but again we run into the fact that even though the cards may already do this, there is not a way to really access the feature in GEM. For example, the GPU hardware MPEG-2 decoder is used by a number of DVD applications, but the path provided does not allow for the decoded frames to be used in an OpenGL context. ATI has a new system coming that may allow that though.
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi there,
I tried to use Quicktime instead of DV. The 4 clips are like 10x bigger and the problem remains unchanged.
I also tried to add some [change] objects wondering if I wasn't unecessarily stressing some objects forcing repeated calculations but still everything is slow as a rowing boat.
I even removed 2 clip leaving only 2, and still everything was slow. I even tried with only one clip and noticed that, although the clips was running smoothly [ctlin] had a significant delay and after I moved the fader would only reflect the changes after almost one second. Weird, isn't it?
Since I received that email from Chris Klippel suggesting I am overloading the buffers, I think I will give pix_mix another try. I guess the mix in pix_mix is done before the buffers, right?
Thanks, Nuno
-----Original Message----- From: cgclepper@gmail.com [mailto:cgclepper@gmail.com] On Behalf Of chris clepper Sent: terça-feira, 13 de Dezembro de 2005 17:22 To: Nuno Godinho Cc: PD list Subject: Re: [PD] Fading between 4 videos - performance issues
On 12/13/05, Nuno Godinho eu@nunogodinho.com wrote:
Hi,
This is a P4 at 3.2GHz with 1Gb of RAM and an ATI 9600
video card. Not
the best in the world but I would say its acceptable for my intents.
Hum... so, from what you say... what I want to do is indeed performance intensive. But how can this be if in Adobe
Premiere I can
run much more videos simultaneously and still apply some
filters on the fly?
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
I thought the idea of turning off the invisible videos was
quite reasonable.
But somehow pd takes over 1 second to react and turn one
video on or off.
That should be a reasonable solution and I haven't seen the same thing happen here with turning the gemhead on and off.
I do have a problem where the first time I turn on rendering with a DirectShow or Quicktime object the output is like one frame every few seconds. Turning rendering off and back on makes everything run at full speed. Maybe try your DV clips as Quicktime rather than AVI?I could use a slightly slower framerate... But this would only be a temporary solution.
I only have the FireGL here, but I might try an Nvidia card to see if anything changes.
Thanks, Nuno
hi again,
Am Dienstag 13 Dezember 2005 19:32 schrieb Nuno Godinho: [...snip...]
I even removed 2 clip leaving only 2, and still everything was slow. I even tried with only one clip and noticed that, although the clips was running smoothly [ctlin] had a significant delay and after I moved the fader would only reflect the changes after almost one second. Weird, isn't it?
oho, now that puts it in a different light.
it seems that you have a more fundamental problem there. are you sure you have the correct drivers installed, and active? is there anything else running in the background? maybe some conflicts with some other driver, or some old remains of earlier drivers? windows is prone for this kind of "bugs" .....
i mean, hey, i could play around with at least one stream even on my old pentium II/600 .....
how is the driver situation on windows? is open-gl always active and accelerated as soon as the vendor's drivers are installed? or do the, by default, only use active-x and refer to software-gl then? (similar to linux)
greets,
chris
Hi Chris,
how is the driver situation on windows? is open-gl always active and accelerated as soon as the vendor's drivers are installed? or do the, by default, only use active-x and refer to software-gl then? (similar to linux)
I don't know how to check this. I have no idea if opengl is always active or not. But I'm curious now. Do you know how I can check this?
Bye, Nuno
hiya,
On Dec 13, 2005, at 1:32 PM, Nuno Godinho wrote:
I even removed 2 clip leaving only 2, and still everything was
slow. I even tried with only one clip and noticed that, although the clips was
running smoothly [ctlin] had a significant delay and after I moved the
fader would only reflect the changes after almost one second. Weird, isn't it?
...at this point, if it can't even play one clip, I think we can
assume that you have something hooked up "incorrectly"...I just went
back to the post where you had the patches, and I can say that
there's any number of problems I can see, all having to do with order
of operations!
...this is usually a big gotcha: you can't just connect multiple
outputs from one object to many other objects and expect it to behave
in any understandable manner: what you need to do is add [trigger]
objects to get a better flow of messages...
...to start in "vela.pd", you should get rid of one of the
numberboxes, then put a [t f f f f] afterward, because as it is, that
[ctlin] number could go in any order to the four subpatches...
...then go thru your subpatches and wherever you see multiple
connections from one object, insert a trigger: a particularly bad
spot is in the [pd calculaligadodesligado] subpatch, where you have a
numberbox going to both inlets of [+]...who knows what'll be the
result...the following will give you more what you want:
[number] | [t b f] | | [+ ]
...the same idea goes for multiple connections from [inlet], but
[loadbang] in general is ok (but could make for some unexpected
initial behavior)...
...also, inserting numberboxes is good for debugging, but can slow
down the whole thing, so you might want to make them optional...
...try this, and then we might get less weirdness ;-)
james
Thank you so much James,
Your tips were most useful. I am still not used to PD logic so I still make this kind of silly errors.
Bye, Nuno
-----Original Message----- From: james tittle [mailto:tigital@mac.com] Sent: terça-feira, 13 de Dezembro de 2005 19:53 To: Nuno Godinho Cc: PD List Subject: Re: [PD] Fading between 4 videos - performance issues
hiya,
On Dec 13, 2005, at 1:32 PM, Nuno Godinho wrote:
I even removed 2 clip leaving only 2, and still everything
was slow. I
even tried with only one clip and noticed that, although
the clips was
running smoothly [ctlin] had a significant delay and after
I moved the
fader would only reflect the changes after almost one
second. Weird,
isn't it?
...at this point, if it can't even play one clip, I think we can assume that you have something hooked up "incorrectly"...I just went back to the post where you had the patches, and I can say that there's any number of problems I can see, all having to do with order of operations!
...this is usually a big gotcha: you can't just connect multiple outputs from one object to many other objects and expect it to behave in any understandable manner: what you need to do is add [trigger] objects to get a better flow of messages...
...to start in "vela.pd", you should get rid of one of the numberboxes, then put a [t f f f f] afterward, because as it is, that [ctlin] number could go in any order to the four subpatches...
...then go thru your subpatches and wherever you see multiple connections from one object, insert a trigger: a particularly bad spot is in the [pd calculaligadodesligado] subpatch, where you have a numberbox going to both inlets of [+]...who knows what'll be the result...the following will give you more what you want:
[number] | [t b f] | | [+ ]
...the same idea goes for multiple connections from [inlet], but [loadbang] in general is ok (but could make for some unexpected initial behavior)...
...also, inserting numberboxes is good for debugging, but can slow down the whole thing, so you might want to make them optional...
...try this, and then we might get less weirdness ;-)
james
Hi there,
Meanwhile I managed to vastly improve the performance by abandoning tweaking with the alpha of each video and going back to pix_mix again. The trick was to turn off "gemhead" and also "auto" on pix_film whenever one of the films is totally invisible. This way I never get more than 2 videos simultaneously.
I still get some delays but I'd say nothing tragic.
Thanks for all your help guys.
Bye, Nuno
-----Original Message----- From: cgclepper@gmail.com [mailto:cgclepper@gmail.com] On Behalf Of chris clepper Sent: terça-feira, 13 de Dezembro de 2005 17:22 To: Nuno Godinho Cc: PD list Subject: Re: [PD] Fading between 4 videos - performance issues
On 12/13/05, Nuno Godinho eu@nunogodinho.com wrote:
Hi,
This is a P4 at 3.2GHz with 1Gb of RAM and an ATI 9600
video card. Not
the best in the world but I would say its acceptable for my intents.
Hum... so, from what you say... what I want to do is indeed performance intensive. But how can this be if in Adobe
Premiere I can
run much more videos simultaneously and still apply some
filters on the fly?
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
I thought the idea of turning off the invisible videos was
quite reasonable.
But somehow pd takes over 1 second to react and turn one
video on or off.
That should be a reasonable solution and I haven't seen the same thing happen here with turning the gemhead on and off.
I do have a problem where the first time I turn on rendering with a DirectShow or Quicktime object the output is like one frame every few seconds. Turning rendering off and back on makes everything run at full speed. Maybe try your DV clips as Quicktime rather than AVI?I could use a slightly slower framerate... But this would only be a temporary solution.
I only have the FireGL here, but I might try an Nvidia card to see if anything changes.
Thanks, Nuno
On 12/20/05, Nuno Godinho eu@nunogodinho.com wrote:
Hi there,
Meanwhile I managed to vastly improve the performance by abandoning tweaking with the alpha of each video and going back to pix_mix again. The trick was to turn off "gemhead" and also "auto" on pix_film whenever one of the films is totally invisible. This way I never get more than 2 videos simultaneously.
That's interesting since disabling the gemhead also effectively turns off the 'auto' message as well. Maybe there is a problem with the way the film playback is tasked using the external API (avi or qt). Can you send the patches of both the pix_mix and alpha blend versions?
cgc
I still get some delays but I'd say nothing tragic.
Thanks for all your help guys.
Bye, Nuno
-----Original Message----- From: cgclepper@gmail.com [mailto:cgclepper@gmail.com] On Behalf Of chris clepper Sent: terça-feira, 13 de Dezembro de 2005 17:22 To: Nuno Godinho Cc: PD list Subject: Re: [PD] Fading between 4 videos - performance issues
On 12/13/05, Nuno Godinho eu@nunogodinho.com wrote:
Hi,
This is a P4 at 3.2GHz with 1Gb of RAM and an ATI 9600
video card. Not
the best in the world but I would say its acceptable for my intents.
Hum... so, from what you say... what I want to do is indeed performance intensive. But how can this be if in Adobe
Premiere I can
run much more videos simultaneously and still apply some
filters on the fly?
Premiere is probably not texturing the video using OpenGL, but rather using simple accelerated overlays.
How do you intend to improve things? What alternativs do I have? Does it run smoothly in Mac? Is this a PC-only issue?
I easily get 4 720p24 clips on a dual G5 and at least 3 1080i60 ones. At least 6 DV clips are possible as well.
I thought the idea of turning off the invisible videos was
quite reasonable.
But somehow pd takes over 1 second to react and turn one
video on or off.
That should be a reasonable solution and I haven't seen the same thing happen here with turning the gemhead on and off. I do have a problem where the first time I turn on rendering with a DirectShow or Quicktime object the output is like one frame every few seconds. Turning rendering off and back on makes everything run at full speed. Maybe try your DV clips as Quicktime rather than AVI?
I could use a slightly slower framerate... But this would only be a temporary solution.
I only have the FireGL here, but I might try an Nvidia card to see if anything changes.
Thanks, Nuno
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
chris clepper -
chris clepper -
Christian Klippel -
james tittle -
Max Neupert -
Nuno Godinho -
Thomas Hoernlein