[PD] Fading between 4 videos - performance issues

[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.

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 at iem.at [mailto:pd-list-bounces at iem.at] 
> On Behalf Of Christian Klippel
> Sent: terça-feira, 13 de Dezembro de 2005 17:57
> To: pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>