Quote:
djrikki wrote:
Hi all, hope you've all had a great christmas day. :)
I have. :)
Quote:
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
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:
Finally as anyone studied SRec, is there source code available? How optimised is SRec anyway?
See
SRec's home page. Note the link to the sourceforge project.
Quote:
HD write speed doesn't appear to be a problem at all as the led hardly flashes - just seems that CPU processes is slow.
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:
Best settings:
AVI - Motion JPEG
Width: 1280 x 720
FPS: 20
Software Scaling - No
That's nice to know. My own experiments failed with anything but the lowest resolutions.
Hans