28 replies to this topic

[begemot]

My problem is in copying a lot of memory in textures. I need execute operation of updating for 36 images with rate 25 times per second. If I have images 300x200 size I takes about 60 ms for copying and display. But if my pictures reach 700x500 size it takes just 150 ms (I tested with 16bpp format). I think to resize my images before copying, but I don't know how to do it. can ipp libs do it? Is it realy?

[begemot]

Also YUV->RGB conversion was discussed. Can you help me in this? Can I get frames from my video files in YUV format or I must do any convertions between getting frame and copying steps?

[Nik02]

have you profiled your application? Do you have actual knowledge of where your performance bottleneck is?

[begemot]

the function CopyMemory costs 52%

[Nik02]

The YUV to RGB conversion can be done in pixel shader, by using the conversion formula found here: http://en.wikipedia.org/wiki/YUV

Because of the simple logic, GPU can perform this operation very fast per pixel.

Some hardware is capable of using YUV format textures directly; they will perform the conversion to RGB automatically.

Whether or not you have YUV data available to begin with, depends entirely on your video codec of choice.

[Nik02]

the function CopyMemory costs 52%

What about Marshal.Copy?

[begemot]

I use line per line CopyMemory from kernel32.dll because I don't understand how copy data from IntPtr to IntPtr by Marshal.Copy. It seems to me, It works a little bit faster then primary unsafe code.

[Nik02]

When you get a video frame from your codec, can you specify a destination address for the decompressed frame? You could decompress directly to a locked surface buffer, if this was the case.

[begemot]

Thank you very much