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