you can use 3rd party software to capture the screen and create said video file, but that has nothing to do with the replay feature, unless you are replaying a previously recorded flight.
Directly capturing inside flightgear, is possible and is something that OSG supports out of the box - there are number of ffmpeg related osg examples, but it's nothing that is currently integrated
However, this might become much easier thanks to the compositor work done by Fernando, which is all about rendering into a buffer and passing that to a different rendering pass, to build the equivalent of a so called "pipeline" - such a pipeline could also just copy the frame buffer and pass it onto another handler, to save to disk, or stream the window contents to another process.
As a matter of fact, ThomasS created a streaming feature for the Canvas system which takes the canvas texture and streams it to a browser, this is used by Torsten's Phi front-end to display canvas textures at runtime - the same approach would work for full-screen textures:
http://wiki.flightgear.org/Read_canvas_image_by_HTTPIf/when compositor ends up with Canvas support again, it would be pretty straightforward to make this kind of setup feasible again.
And we've seen a handful other valid use-cases, too:
http://wiki.flightgear.org/Howto:Using_ ... Box_ServerSpeaking in general, it would make sense for the instant replay/flight recorder subsystem to become a standalone thing, living in its own thread/process - also to get rid of lag, and so that custom settings can be used that don't add workload to the main loop.
Technical details about the differences between the replay file (format) and an actual video, to be found below:
Replay ConversionHooray wrote:HelldiverSquadron wrote in Mon Apr 21, 2014 7:54 pm:Seemed like a binary trait. I opened it in Notepad ++, but it was just rubbish. I don't mean that it is a video format, but rather could I import it into, say, Blender, and then export it as something else? It's way too optimistic, I know. Thanks, all!
again, the format is basically seralized FlightGear properties, please see $FG_ROOT/Docs/flightrecorder.README - these are all just "numbers", the format is determined by FlightGear, and these numbers do not mean ANYTHING outside FlightGear, and even inside FlightGear it's really just the flight recorder subsystem that is able to open/process those files, read in the numbers and map them to the corresponding FlightGear properties - which in turn allows things to be animated/replayed over time JUST VIA FlightGear.
There's really no need to continue this discussion at all - all the responses given so far were rather exact, detailed and 100% correct. There's no reasonable way to visually "replay" those files outside FlightGear, short of rewriting FlightGear itself, or extending another flight simulator to partially re-interpret certain values. Unless that is something that you are interested, willing and capable to do, I'd just leave it at that.
What FlightGear is writing to those files is not actual "visual" stuff at all, it's just "gibberish" in the sense of properties that are only meaningful to FlightGear itself, and its features, most properties are in fact aircraft specific. Imagine those files to be containers for binary FlightGear properties, i.e. things like altitude, longitude, latitude - but also engine settings, flap settings, gear status etc.
So there's really just numbers stored there, nothing visual that would make sense to visually re-interpret outside a flight simulator environment like FlightGear.
To actually replay even just a single aircraft specific animation in FlightGear, you would have to write a python script that 1) loads the aircraft, 2) looks up the 3D objects, 3) maps the properties to animations - and completely ignore anything related to scenery, because it's typically just aircraft specific stuff that is recorded.
Please just believe us, and consider spending more time reading and understanding what you're told, instead of re-asking redundant questions, thank you !