SRec

Hi all, hope you've all had a great christmas day. :)

Thanks to the release of the Radeon HD drivers from Acube yesterday, I've been playing around with SRec today, tinkering with settings and what not and think I have it fully-optimised - not great, but okay for showcasing some videos at 720PP (1280x720) on this AmigaOne 500. As long as its not anything intensive like browsing or running some game or other.

I have a general question really, when the Gallium/Mesa is finally released. If someone ports/writes a native screen capturing piece of software that is OpenGL-based does this automatically result in an immediate speed boost? Is there is such a thing is an OpenGL-based screen capturer? If so, bloody looking forward to one. :D

Finally as anyone studied SRec, is there source code available? How optimised is SRec anyway?

HD write speed doesn't appear to be a problem at all as the led hardly flashes - just seems that CPU processes is slow.

Best settings:

AVI - Motion JPEG
Width: 1280 x 720
FPS: 20
Software Scaling - No

Quote:
I have. :)


Quote:
I haven't heard of an OpenGL-based screen recorder. In theory, a big boost should be obtainable if the GPU could be used to accelerate the video encoding. It would still slow down graphics if the application/game being recorded were already maxing out the GPU, but it should still be faster overall.

Quote:
See SRec's home page. Note the link to the sourceforge project.

Quote:

Video encoding is quite CPU intensive.

The other bottleneck is getting the video data off the graphics card in the first place. If you have a look at some GfxBench2D MemCopy results (e.g., the MemCopy results of this one), then you'll notice that copying from VRAM to RAM is slow. ReadPixelArray maxes out at approx. 100 MiB/s. Streaming 32-bit 1280x720 video off the card at 20 fps is approx 70.3 MiB/s, leaving only about 30% of CPU time left to encode the video and write it to disk.

DMA/GART support in the driver should help speed this up, and is something that I do hope to implement at some point.

Quote:

That's nice to know. My own experiments failed with anything but the lowest resolutions.

Hans

@djrikki

If MJPEG is faster than ZMBV or RGB, then I seriously need to look at this again.

The RGB option outputs an uncompressed-AVI, when using this option the HD is being throttled excessively and the system quickly becomes unstable. Additionally you ended up with a 200mb+ file after only two seconds of recording.

I recalled ZMBV crashing my system through to unstability.

The final codec xVid, you end up with smaller files at the price of a huge drop in quality.