EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

As many have noted, QuickTime video recording is not available in the 64-bit version of X-Plane.  This is not a bug; we will not be ‘porting’ QuickTime to 64 bits.

What we are going to do is:

  • Maintain QuickTime capture in every place we have always had it: 32-bit Mac and 32-bit Windows.
  • Someday we will transition from QuickTime to “something else” that will run on every platform, 32 and 64 bits.  At that point we will drop QuickTime and have one universal capture solution.  I don’t know what release this will be but it won’t be in 10.20.

My preference is for something that captures a fairly common and widespread format; photo-JPEG-compressed AVI is a candidate; remember the goal of video capture in X-Plane is not to make the best finished movies but to get the movies out with low overhead, for high-fps capture.  That’s why we do QuickTime-JPEG and not MP4/H264, for example.  Really good output formats like H264 require very long encode times to get their high quality high ratio compression.  On the fly our goal with capture is just to get the frames out to disk for later processing.

Why No 64-Bit QuickTime?

The rest of this is just for programming nerds, feel free to let your eyes glaze over.

The problem is that QuickTime has two APIs:

  • A 32-bit C API available on Mac and Windows (original “QuickTime”) – this is the original C API that dates back to Mac OS 8 or earlier.
  • A 32/64-bit Objective C API (“QTKit”) available only on Mac (e.g. the only platform with ObjC).

We currently ship with that first API, hence no Linux support, and no 64-bit support – the API just isn’t available in those flavors.

I believe the work of porting to the new ObjC QTKit API would be about the same as implementing any other library-based capture solution, but it would only get us one OS in 64-bit.  So when we do spend time to extend video capture, we’ll do it in way that works everywhere.

We’re not going to hold up 64-bit going final (10.20 final) for this; I think that there are more important features to move forward with: 64-bit, better rendering settings for autogen, DSF recuts, scenery tools.  We’ll get to next-gen video capture, but we’re not going to try to jam it into this release.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

30 comments on “The Future of QuickTime & X-Plane (or lack thereof)”

  1. Would it be possible to have some sort of function where you could fly a flight, record the flight path and control inputs, then send that to some high quality encoder? In other words, the encoding would not be in real time, sacrificing speed for quality, but you’ve still flown the flight in real time. I feel like this sort of option would be preferable for devs who want to make high quality, flashy videos of their aircraft and scenery. Then again, I’m not a dev, so maybe I’m wrong?

    1. I thought Austin had already coded that, but I don’t remember if or how he set it up. He mentioned a while back having QT record during replay play back ‘lock’ to the target framerate for “offline” recording.

        1. Yes ! Excellent for linux. I miss this function in my linux system (I do have a dual boot with W7, but I confess I never boot on windows).

      2. I actually thought that the replay mode was invented for just this purpose: I always make QT movies from replay mode, I thought in that way I sort of ‘baked in’ the framerates I had while flying…
        (usually I fly with low settings and record in higher settings from the saved replay)

        I thought everybody did it this way…

  3. Why not leave the video capture stuff to VLC or Fraps? This is what most people usually use to capture video for their airplane porn movies.

    1. We have direct access to the video driver _as_ the frame is being drawn, so we can down-size and pre-process the outgoing frame entirely on the card and then haul it back to system memory asynchronously.

      It may be that some video recording technologies can do this but in my experience they usually have to either capture full size max res or in some other way cause framerate to tank. By comparison, QT recording is relatively painless – that’s not due to QT (which runs on a thread, and we just pick a codec that’s light weight), it’s because of how we get the frames out of the video card carefully.

      1. To my knowledge QT is very unfriendly to resources (and strangely enough any Apple developed software on Windows, don’t know if its on purpose or if I just got unlucky with ANY I tried over the years).
        ANY other direction seems like the right direction right now.

  4. Is the absence of sound in recorded videos a limitation of QuickTime or is this a general technical limitation. In other words: is there hope that with another video recording method there would be sound in the recorded video as well?

    1. The sound issue is due to the difficulty of getting sound out of OpenAL – on v10 we use OAL everywhere which cuts the problem from 3 APIs to two, but it’s still code that must be developed on every platform.

  5. Hey, Don’t forget sound recording this next time around, or at least some kind of mechanisim to sync the framerate of the output video to real time. Last time I tried to combine sound with video, the video playback/recording rate was all messed up (kept changing thoughout the video, and it was impossible to synch up with the audio!). But otherwise, it should be exciting whatever you manage to put together!

    1. I’d like to do sound someday but we’ll do silent video first if possible — audio capture on most machines is cheap, but FRAPS/full screen capture can slow fps, hence the motivation to do it in-sim.

      1. Without sound many will turn to third party solutions, so why even bother? Even SnapzPro can’t keep up on my system — it freezes a few frames at regular intervals. Glad to read you intend to keep it lean though…

  6. I would like to have a $opensource_video_codec (OGG Theora, WebM, …) support rather than dreaded Quicktime…

    1. WebM is _not_ the kind of codec we are looking at! These codecs are all “finished” codecs for distribution, like H264 and MPEG, designed to maximize compression. They usually have long encode times.

      We need a “capture” codec that can compress frames rapidly even if they don’t get much smaller, just to get them down to disk.

      But we could use an open-source container like MKV or something.

  7. Greetings! You should consider using FFMPEG library for encoding. It provides many codecs for output (though you only need to pick one that would work for realtime encoding – for example MPEG-2), and can write plenty of container formats (again, just compile it with support for one common format like AVI).

    In my own experience, MPEG-2 is pretty fast (assuming data can be written to disk efficiently), and I believe FFMPEG might have hardware acceleration support under some platforms. Though not entirely sure.

    FFMPEG is open-source, and available under all X-Plane platforms, and both 32 and 64 bit versions.

    (FFMPEG library is just a collection of codecs, a very simple interface to using them, and a collection of output formats).

  8. Just wanted to say that I wholeheartedly support the removal/replacement of QT. In my experience, it generally isn’t a nice software to have installed on a Windows machine.

  9. Why not capture and save to a RAW format? Then we users can convert it to more suitable format to e.g. h.264 with either your future tool or third party tool? By capturing in the RAW format will get very good video quality with low CPU/GPU resource.

    I know that files will be huge, but it will go quickly and reduce the CPU/GPU resource. When the RAW movie is converted to more suitable format, we can throw away that huge RAW file.

  11. X-Plane 9.70/10.11
    MacPro3,1 /Snow Leopard 10.6.5
    Quad-Core Intel Xeon 2.8 GHz x 2
    6 GB Ram/Bus 1.6 GHz
    NVIDIA GeForce 8800 GT 512mb

    In my experience 3rd party vid apps for mac eat cpu ( iShowU HD etc.) Re.QT.v9 never quite locked @30fps 1280×720 v10 seems to lock around 20fps in both cases mostly the footage needs converting before going into FCP.That said QT is very convenient and the OS finder has no problem quick viewing the apple photo codec files( if you change this codec please make sure it plays nice with quick view!) .Do you propose settings like fps and size for the new system?Also not sure if the “offline recording” happens but in some cases ive been recording a “slide show” but the vid comes back relatively smooth so maybe it does something!

Comments are closed.