[PD] Fading between 4 videos - performance issues

[chris clepper]

On 12/13/05, Christian Klippel <ck at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>