If you export your ScreenFlows using the “Web” presets or the built in Apple H.264 codec, you’ll be interested to hear of a way to reduce your data rates while maintaining the quality of your H.264 movies by installing a free x264 codec.
x264Encoder is an encoding engine that produces video in the H.264/AVC standard. It is free, and developed by Takashi Mochizuki. Takashi-san was kind enough to make his x264Encoder compatible with ScreenFlow. When asked why he developed the codec, Takashi explained:
“I am just an amateur, free software programmer, and I like [the] open source policy. I also like [the] QuickTime world, and want to make QuickTime more useful. I think my component may help someone easily use the x264 library in QuickTime savvy applications.”
To use the x264Encoder with ScreenFlow, you simply download it and place the component in your /Library/QuickTime folder. Takashi has created a few simple instructional videos on his YouTube channel if you run into any trouble. When you restart ScreenFlow you will see x264Encoder as an available codec in the Export customization options.
One of our fabulous and knowledgeable users, Craig Reed, a video producer for the Berklee College of Music online school, tested the two codecs side by side and was kind enough to report his results:
“The example movie I was using for the tests was output at 960×600 at 30 fps, and involved video action zooming, and callout zooming on a detailed interface. This is a better test than just moving the mouse around on a static screen because all the screen pixels are moving/updating simultaneously at various points of the recording. Simply moving the mouse around and dropping down menu lists is not very demanding on the codec. So we went with a worst-case scenario.”
Here are the settings Craig used:
Apple H.264 settings:
ScreenFlow Export Preset = Web – High (Multi-pass), selected to Customize with:
Video Settings Panel:
Compression Type = Apple’s default H.264 encoder
Frame Rate = Current (ScreenFlow captures at 30 fps)
Key Frames = Every 300 (the general rule is to force a key frame every 10 seconds. If you set this for every 1 second, or 30 frames apart, you may see noticeable pulsing in the quality.)
Frame Reordering = Checked
Encoding = Multi-pass
Data Rate = Restrict to 200 kbps
Then Craig output the same movie with the x264Encoder codec using similar video settings:
x264 settings:
ScreenFlow Export Preset = Web – High (Multi-pass), selected to Customize with:
Video Settings Panel:
Compression Type = x264Encoder
Frame Rate = Current
Key Frames = Every 300
Frame Reordering = Checked
Encoding = Multi-pass
Data Rate = Restrict to 200 kbps
x264Encoder Options Panel (Values Tab) The only changes to the defaults were:
Faster First Pass = Disabled
b_Frame_strategy = Optimal
Refs = 5
Max B = 8
Craig found the exports from x264Encoder look noticeably better than those using Apple’s H.264 encoder.
“This is about all the control you have over the Apple H.264 codec, as it does not support different AVC levels or B-Frames. The quality difference was extremely apparent.”
As for why he chose the settings he did, Craig explains, “In the x264Encoder-specific options, I disabled Faster First Pass in order to get the most reliable information possible during the analysis pass. Upon comparison of encoding with this set to either Disabled or Turbo2, there is little difference in the encode time, so I suggest disabling it for the best quality.
“I also read that for animations and screen movies, (where there is less difference in the image from one frame to the next, as compared to camera videos), Reference Frames should be set to the higher of the 3-5 range, and increasing the number of B-Frames to between 5 and 8 is better than the default value of 1 or 2.”
To show the difference in quality, I created my own 23-second example movie, and exported two versions using Craig’s settings. (The only difference was that these were exported at 480×300 to fit this blog).
As you can see, the one output with H.264 (top) clearly starts breaking up during the screen zoom, and on certain movements. Whereas the x264Encoder movie maintains a crisper image throughout all the movements. Craig contends he had to raise the data rate of the Apple H.264 codec to 800 kbps to achieve the same quality results as the 200 kbps with the x264Encoder. When I did this with the 23-second movie above, the size of the movie went from 856 KB to over 2.5Mb!
Craig summarizes, “These are the settings we now use on all of our screen movies. The one variable being that if the specific ScreenFlow project requires a larger final output resolution or has more activity on screen than can be accommodated cleanly at a video data rate of 200 kbps, we will increase that 100 kbps at a time until we get a good result. Setting the data rate to Automatic invariably creates a good movie, but with a needlessly high data rate that is overkill. Since our audience is on the web internationally, with a wide range of connection bandwidths, we need to maintain as high a quality as possible with the lowest bandwidth necessary.”
If you want more information on the settings, Craig makes some recommendations, “If you wish to geek out on the all the possible settings in x264Encoder and their meanings, you can review a couple resources. Here is a laundry list of all the parameters and their options with suggestions; and this gives meaningful explanations about the use of some of the important available options, including the difference between B-, P-, and I-Frames. Even though it is written about the command line interface for x264, the information is still relevant and readable.”
So try it out, and let me know what you think!
Thanks to Takashi for his wonderful work and to Craig for taking the time to test the codecs and write out his results and recommendations.
(Takashi has also recently developed a wrapper component with libavcodec and libx264. For more information on this and the x264 development team go to http://www.videolan.org/developers/x264.html)
ADDENDUM: It’s come to my attention since writing this post that not all devices support this encoding profile. For example, x.264-encoded videos will not play on an iPhone, while H.264-encoded files work fine. So it always pays to test your final video file’s playback on your target devices.