1. iPad video footage capture and editing workflow: Part 2

    At last, some movement on the iPad capture workflow, the results of which you can see in the new video of Food Run above. It’s not yet perfect, but it’s 90% of the way there. Details after the break.

    This is the second part of this series, looking at iPad video capture options for developers. For part one, go here.

    One of the options I used to employ for iOS video capture in the pre-iPad, pre-Retina days was running the game in the iPhone Simulator (part of the iOS SDK), and using desktop capture software to grab the frames. This worked very well, but with today’s high resolution devices (iPhone Retina at 960x640 and iPad at 1024x768), my ageing 2008 iMac cannot run both the game and capture at the same time without dropping frames.

    Option 1 - Hardware Upgrade

    The most obvious option here is a hardware upgrade. Whilst I’m sure I’ll have to do this at some point in the near future, I’m waiting out for the next generation of Mac refreshes, at the very earliest. Judging by previous performance and the number of months since the last hardware updates, we should be due in the first quarter of 2012, or thereabouts.

    Option 2 - Native Capture

    The next option would be video capture from the device itself. The solution of choice in this department would be the Blackmagic Design Intensity range, but a similar problem exists. In their current forms, the Intensity solution requires a PCI Express slot, USB 3.0 connection or Thunderbolt connection, none of which my iMac has.

    Option 3 - Port to Mac

    But then suddenly an obvious thought sprung to mind. I have already ported my iOS engine to Mac to produce WordCrasher for the Mac App Store, so why don’t I just port Food Run? In theory, it should run much faster than on the simulator, and perhaps fast enough to run desktop video capture in the usual manner.

    The port took about half a day, it being a rather sloppy workable version rather than a polished end-user grade app. However, upon capture I found I was skipping frames, leaving a less than smooth result.

    This won’t be an option for everyone. Some might be using a pre-rolled engine without Mac or PC support. But in my case, the option was entirely viable and low cost.

    Smoothing the Framerate

    The answer to the frame skipping problem was to change the Food Run code to render at 30 frames per second instead of 60, just for the purposes of capture. After all, the output video will be 30fps, so why not run and capture Food Run at that rate? This worked well, and the result is the video at the top of this article.

    Further Refinements

    That brings us up to date, to my current solution with which I’m 90% happy. The colours are accurate, the sharpness is great and the motion is fairly smooth. Why the qualification of that last statement? Well, by running at 30 frames per second, I’m still throwing half the frames away. Games which run at 60 frames per second have a lovely polished smooth look to them, and I’m not doing Food Run full justice by leaving half the frames behind.

    There are two possibilities to bring the smoothness of 60fps to the video capture workflow.

    1. Get the Mac hardware upgrade, capture at 60fps. Although the end result YouTube video will still be 30fps, I will be able to frame blend the 60fps capture in my video editing suite down to 30fps,which should in theory preserve some, but not all of the smoothness of a true 60fps video.
    2. Do the frame blending in the Food Run Mac application itself. Render a single frame 30 times a second, but compose that frame from two frames taken 1/60th of a second apart, by rendering one of them to an intermediate buffer in OpenGL. This may initially seem just as costly performance wise as a 60fps capture, but the time savings are two-fold. Firstly, I will save time by running vertical syncs at 30fps, meaning less dead time waiting for the sync. Secondly, doing the actual capture at 30fps instead of 60fps should be a large saving.

    Given my feelings about the timing of a Mac upgrade, I’ll probably attempt the second option first, but to achieve that I’ll have to build intermediate pixel buffer support into my engine first. Which shouldn’t take long at all.

    To be continued…