I did not consider .mkv containers. My goal was:
– Low time to develop video output.
– Low complexity (e.g. not bring in a ton of other libraries).

After a brief search of other libraries out there, I came to the conclusion that a simple AVI MJPEG recording (using libjpeg) was the best option. Users can transcode to virtually anything later.

If you mean “variable framerate”, how do you encode separate per-frame _durations_ into an AVI file? I see framerate fields in the AVI header and the ‘strh’ header, but nothing in the per-frame data or the index.

My comment was based on memory alone – something I should never do online, but apparently tend to do quite often. The experience I have with video encoding is already over a decade in the past, so my memory can easily fail me. And after a quick refresher on the subject, it seems my earlier comment was indeed wrong; AVI really does not support VFR, I was thinking MPEG instead 🙁

If you know of a spec that indicates that this is possible, please send me a link. (If it’s an _extension_ to .avi we’d have to investigate whether it has wide support.)

Of course, in theory I believe you *could* hack around this limitation by having some insanely high frame rate for the video stream and providing empty chunks for the frames you’re “skipping”. But yeah… probably not the best way to spend developer time 😀

Have you considered using Matroska-containers? It is under a free license, players are available on virtually every platform (Windows 10 even supposedly has native support for the format baked in). And it supports VFR-streams 🙂

Hi Markku,

I’m going to nitpick your nitpick! Do you mean “variable FRAMERATE” or “variable BITRATE”? The two are hugely different.

If you mean “variable framerate”, how do you encode separate per-frame _durations_ into an AVI file? I see framerate fields in the AVI header and the ‘strh’ header, but nothing in the per-frame data or the index. If you know of a spec that indicates that this is possible, please send me a link. (If it’s an _extension_ to .avi we’d have to investigate whether it has wide support.)

Real-time encoding of variable _framerate_ video is quite trivial _if_ your container format supports it – that’s what QuickTime did – it’s simply a matter of writing out different frame times on the meta-data of each frame.

Writing out variable _bitrate_ video is not very hard either – both our old and new implementation do this. Here are some things that are tricky:

– Fixed bitrate video when the codec isn’t “naturally” fixed bit-rate (like DV). This means dynamically adjusting the compression ratios to hit target bit rates dynamically and possibly re-compressing frames.
– Variable bitrate audio.

These are tricky because the ‘natural’ (and simple) assumption of audio and video is that audio is a fixed bytes-per-sample and video has variably sized frames (in bytes) over a fixed time period. These are also the assumptions of .avi.

What do you believe the default input device will be? I believe it will be a built-in microphone if you have one. 🙂

Just feel the irresistible urge to nitpick here… AVI is “only” a container format that can have pretty much anything inside – including video track(s) encoded using a multitude of variable frame rate capable codecs. I admit that your point is valid, though; realtime *encoding* of a variable frame rate video is extremely hard.

I forgot the licensing costs of h264. Thanks for the response!

I don’t quite see the issue, it records the INPUT to the default (because we passed NULL) device.
This input can easily be recorded to a vector and then to disk as a .wav (or more sophisticated) sound file (this is explained with sample code in the link I provided), which can then be packed with the video stream in an AVI container.

On the other hand I completely agree that video recording is not what should be most expected from a flight simulator…

This assumes that for each OS we can find a reliable way to (1) identify the underlying audio device that OpenAL is playing to and (2) then capture from it. Some audio hardware may have no facility to do this, and some hardware may have no -reliable- way to do this. The loop-back extension fixes this by routing audio directly off of OpenAL.

Maybe I did read too fast, but I was triggered by the following sentence in the link of your link:

http://kcat.strangesoft.net/openal-extensions/SOFT_loopback.txt

“This extension allows an application to read back OpenAL’s rendered audio
instead of having it output to an audio device on the system. Unextended
OpenAL will output audio to an audio device, with no mechanism to allow an
application to divert the audio somewhere else.”

But to me it is only needed to capture the sound that is played by the speakers and there is no need to divert the audiostream to a file.

Thank you i know it s been in sim from time, i asked because some time i saw that can t reply the total leght of flight, and i do not investigate to much.

About a car moving is realy crazy to save the position of every car, but as sugestion maybe manange traffic in general if the system and code allow it. something like traffic on / traffic stop. Nobody want cars in same position, but will be very fine to see cars not stoped all to take photos of your landing as in the “end of world” 🙂 .Thank you.