The Lion, Mountain Lion & Mavericks versions of iShowU HD / HD Pro and iShowU Classic contain a significant number of changes to previous versions. This section outlines the differences in functionality between previous versions of OS X (10.5, 10.6) and OS X Lion (10.7) and later.
- Video Codecs - Lions new capture system exposes only three codecs. They are JPEG, H.264 and ProRes. The modified interface in HD lets you choose from these three settings. All existing presets automatically migrate over to one of these three codecs. iShowU v1 doesn't have the option to record using ProRes 422, if you require this please upgrade to iShowU HD or iShowU HD Pro.
- Audio Codecs - Lions new capture system provides PCM and AAC compression. iShowU HD and v1 lets you choose from three preset AAC modes, and one PCM mode. The three AAC modes represent low, medium and high quality compressed audio output. PCM lets you save the audio uncompressed, and provides the highest quality at the expense of large file size.
- Low CPU mode - It was not possible to migrate the Low CPU mode implementation over to Lion. As a result, it is no longer present in the Lion build of the software, and the UI has been updated to reflect this.
- Recovery Mode - Due to the way the capture system works in Lion, we have had to disable recovery mode. While there is technically a way to checkpoint media so that something is written to disk, experiments have shown that the checkpointing process significantly degrades capture performance for a few seconds and also messes up the timing of video (and these experiments were performed on a reasonably fast 4-Core i7 machine). This then results in a video that appears to lag every 60s (we checkpoint every 60s) and that also more often than not lags and then speeds up at the same time. As with the ‘Show Mouse’ option, if the underlying capture system improves, we may include this feature in the Lion build of iShowU HD in the future.
As mentioned above, there are only three codecs available in Lion. Here is our recommendation for their usage:
– This is a "fast" encoder. It will provide the most fluid capture and use the least CPU resource. This is at the expense of using considerable disk space. JPEG is an excellent choice if a) you're machine can't keep up with H.264 (see note below), or b) you want to minimize CPU usage during recording. The only downside to JPEG is the size of the files it creates, and that it often requires recompression into H.264 after recording is complete.
– This provides the best compression, providing a recording that takes up the least disk space. However, it is considerably more CPU intensive, which might result in lower frame rates or a jerky capture. If this is the case, switch to using JPEG.
- Used as a professional intermediate format for editing. Typically if you know what ProRes is, then you know if you need it or not. If you’re not sure - just choose JPEG with a quality of about 80%.
*Note that in all cases (regardless of codec), the Lion capture system provides frames to iShowU HD only if something changes on the screen. That means if you record (for example) a static desktop scene you’d be getting roughly 4 frames per second (from things like the clock in the menu bar updating, etc).
If you want to force the movie to have a fixed number of frames per second (e.g: you’re going to import into FCP for example), then you can do one of two things. Either:
- Disable the ‘variable frame duration’ option. If this option is disabled, iShowU HD will automatically reencode the movie at the end of recording. This will force the movie to have fixed frame durations.
- After the recording is finished and thumbnailing is complete, right click the movie and choose ‘Reencode (fix frame durations)’. This is exactly the same process, and can be performed on any recording made after installing build 1256 on 18th Sept 2011.
In Lion, the audio recording subsystem is also different. In order to get video and audio to synchronize correctly, we had to make use of the new Lion API for both audio and video. The downside to this is that the ability to customize the audio output is no longer an option when running Lion.
If you notice that the CPU usage of iShowU HD is higher in Lion than in previous OS X versions, you’re not going crazy. It is higher. In tests performed at SWB, we observed at least a twofold increased of CPU usage for similar capture parameters. Note that here we are talking about capture. The process of getting frames of video to compress. We are not considering video codec compression differences. Simply capture in isolation.
Fans of death
In some cases, particularly with Core2Duo machines, we observed that capture + compression would cause fans to come on much sooner than with our faster OpenGL capture tech that we had under 10.6.8. Unfortunately, there's little we can do about this. Sorry. The capture + compression engine under Lion is built by Apple - and there's nothing we can do (other than submit bug reports - which we've already done) to effect a change. I wish the situation was different (believe me - I really didn't want to use it but didn't have a choice - Apple disabled the previous method of capture entirely).
What's the impact?
Aside from additional noise (see above note), "it depends." A case where you might notice it is if you were very close to 100% CPU performing recordings on Snow Leopard. In the switch to Lion, more CPU is taken up during capture of frames, meaning less is available for compression of those frames. You would notice it the most while compressing H.264. If you see stuttering or jerky captures using H.264 when using Lion, switch to JPEG and encode the movie into H.264 as a post processing step (you can do that in QTX or via Stomp).
“Show Mouse" always on
Under Lion, there is no way to turn off the mouse in a capture. This is a limitation of the Apple provided capture system in MacOS 10.7.x Lion only. If you're using MacOS 10.8 Mountain Lion, this feature has been reintroduced.
Important 10.7 and 10.7.1 note
The .0 and .1 releases of Lion have some very severe performance problems when capturing from a secondary display. If you're still using either 10.7.0 or 10.7.1 the workaround is to capture using the primary display. This is the display that has the Dock on it (unless you've a vertical dual screen setup - in which case open System Preferences and check to see which display has the thin menu bar at the top of it... that's your 'main' display). This issue is resolved with 10.7.2.