If you need any help, I already made such a tool (though for BMS) using the exact same principle :). http://www.benchmarksims.org/forum/showthread.php?10677-Beta-Release-GPT-(cockpit-texture-extraction-remote-cockpit-control-shm-mirror).
I recommend spawning a slave thread inside the game process which can handle the data compression and transmission. (I send displays as jpeg frames over network, but ideally you'd want a dedicated video stream.)
If anyone is curious about performance: On my system I cannot measure a performance loss at all anymore with the latest version, though others on other systems have reported as much as 40% fps loss (This can be due to lack of asynchronous texture download support in the gpu drivers, lack of free CPU core for frame encoding or similar issues).
The key is to use double (or triple) buffering (extra textures) in video ram that you download from these copies to system ram (you NEVER lock and download the actual texture that the game is drawing to), and you enqueue the download operation at intelligent times, so that it is performed in the background asynchronously over the course of a whole game render cycle. Then when you have the full frame downloaded to system ram, you encode it using an extra cpu thread so that cpu/gpu cost for the game is absolutely minimal.
This way I can download, encode, and transmit frames 1200x1200 at 50 Hz over TCP, and like I said on my system I cannot consistently even measure any performance loss.