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.
Thank you. Very helpful information and well presented. Kudos to all who contributed to this article.
Has anyone had success with these x.264 files in the flash player? The Adobe Flash player, version 10, does not seem to accept these x.264 encoded files – but it does accept files encoded with Apple’s h.264 encoder.
This is pretty awesome, I might have to switch.
I was pretty amazed myself. In any case, it’s an easy install, which – if after testing you decide it doesn’t improve anything for you – you can always remove (or not use)! It’s a win-win 😉
hi i’m new to mac kind of stuff and I’m wondering how to actually install this, you say to place the component in the /library/quicktime folder but the fact of the matter is that i can’t for the life of me find the damn quicktime folder, please help.
Sorry that no one responded for months but the new ScreenFlow 4 is now using x264 natively. No need to install the Quicktime component version.
I am impressed with the quality of video in the output and will have to test this on some of my videos to see the final export size. Thanks for the Info!
Wow, that’s a pretty big difference in quality! I’m going to download the encoder and tweak the settings as well!
For those of us doing just desktop captures at lower frame rates, the defunct compression app VisualHub from Techspansion used ffmpeg to encode. It had a setting that will give you great output.
The setting was within the Advanced settings area for “Extra FFmpeg Flags”. The preset was titled “Best possible H.264/AVC for animation”
My former process was export from Screenflow in Animation at 1280×800 (my capture size). Then use QuickTime Pro to scale (still using Animation codec) to 960×600. This gives a really clean scale. I would then encode to MP4 via VisualHub (which still works – but you can’t buy anymore)
Using x264 component mentioned here, it’s now possible to control those settings right from within Screenflow – although I’ll have to compare the scaling direct from 1280×800 to 960×600 without doing it via Animation codec.
So here are the settings that VisualHub used. You can match them into the x264 settings in the options area (just under the quality Better, Best, etc)
-refs 5 -mbd 2 -me full -subq 6 -me_range 21 -me_threshold 6 -i_qfactor 0.71428572 -deblockalpha 1 -deblockbeta 1
Man, you can get some really NICE and SMALL screencasts when you’re at 10 fps or lowre and you use these settings. Sometimes, less than a 1 MB/minute!
Thanks ScreenFlow for an awesome app!
Has anyone performed the same comparison between x.264 and Sorenson Squeeze 5 or 6’s Main Concept H.264 codec? I recently turned to Main concept H.264 codec because it is definitely superior to Apple H.264 codec: much sharper images. If it turns out that x.264 and Sorenson Main Concept run neck to neck in quality, then even though I would lose the batch processing advantage offered by Squeeze, the intermediary step of exporting a High Res Animation file from Screenflow and then converting from .mov to .mp4 would be eliminated. I was just about to upgrade from Squeeze 5 to 6. x264 might just save me $249.
If no one has yet done this comparison, I’ll give it a try and report back.
Hi Stan,
I’d be interested in hearing the results of your comparison… please let us know.
I’ve been meaning to investigate this QT Component and this fine article has pushed me off the dime. Thanks.
However, I’ll be taking a different tack. I like to produce one very high quality “master” and then use the latest version of Handbrake which also uses x.264 and now works with non-DVD files. I see several advantages here: 1) Handbrake has very good presets as well as exposing all of the tweaks shown here. Start with a preset and go from there instead of from scratch. 2) Handbrake has a batch mode that is quite good so I’ll be able to create multiple versions of a screencast targeting web, mobile devices, etc. 3)
Unlike Screenflow, which is GPU-oriented for rendering and does not use CPU very much at all, Handbrake takes full advantage of all available processors which on my 8 core system is blazingly fast. You can confirm this by looking at your Activity Monitor while ScreenFlow is rendering and then compare that to Handbrake. Who knows, this may produce a faster overall workflow.
Alternatively or additionally, I can run that master copy through QuickTime X “Save for web” option which generates multiple versions, a reference movie and all necessary HTML 5 code to present the screencast to multiple audiences from the same web page.
I just did a quick test on 4:13 screencast of a CAD package. My original output yesterday directly from ScreenFlow with a quality setting of best and an automatic bit rate setting yielded a file size of 152.2Mb.
I compiled the same screencast using the x264 component using the best quality and a bit rate of 800kbps. File size was 29.5Mb.
And I didn’t see any noticeable difference in quality.
One word: WOW!
I’ve just completed a side by side comparison of x264 vs Apple QT H.264. Here are the results:
Both files are 1024×768 with a duration of 37 minutes and both were output from the same Screenflow project at very high quality settings.
The H.264 video is 263.65 MB at 978.68 kbits/s.
The x.264 video is 265.27 MB at 984.70 kbits/s.
Encode time for both was loooong, overnight. Encode time may not be a good criterion because SF rendering is not related to the CODEC in use. It’s a GPU thing and a significant confounding variable in this kind of analysis.
Since my MO is to create a single, high-quality “master” that gets sliced and diced in other workflows such as the “Save for web” option in QuickTime Player X, Handbrake batch processing, etc., this is the kind of comparison that is most useful to me.
The conclusion that I came to was that the differences, if any, were not significant in this case. The bitrates and video dimensions are the same or very close to that, yet neither the file size nor the playback quality were significantly different from one another. YMMV
Thanks for your comparison, Frank. I’d be interested to see what your settings were for each. And you may be right, this codec may not give you anything you don’t already have with the existing h.264, for your particular situation.
H
owever, what I believe to be the main benefit of x264 is that you can reduce the bit rate and/or frame rate dramatically — which significantly reduces file size — without seeing significant quality differences. For those making videos for the web, this is very important. Though if you’re looking to create a very high quality master, like you said, then this may not be applicable.
Wow. Apple better hire that “amateur” programmer. Imagine how much money apple could save in bandwidth using x264.
Just tried this on a few of my programming screencasts. At 200Kb/s the default Apple encoder is not readable. I then tried x264 and wow. I noticed encoding required more processing time but for the size savings this is definitely worth it.
Thanks for the writeup. And thanks to the programmer.
Just did a short 18 second test video (no audio) exporting with both codecs. The h.264 file came out at 1.6mb with bitrate of 743 while the x264 came to 380kb at total bit rate of 166. What a size difference and the x264 looks clearer! Thank you, thank you, thank you!
You’re welcome!
every thing is ok. availability of commen codec is h264 is fine which can be work for mobile devices also, and anyone can tell me how to control multipasses in h264.
i am using procoder which doing multipasses 100 times which make very slow encoding.
sorry for very bad english.
regards
shameed
This is seriously awesome. I’m doing a screencast that’s several hours long and this is exactly what I needed! Thanks.
correction: x264 encoded videos can play on iphone, ipads and other mobile devices if the appropriate profile is used.
For over 2 years I’ve been using the exact settings in here. I now want to use Handbrake to batch process. It works well but I’d like to be able to use the exact same settings specified here in Handbrake, but the fieldnames don’t match, it’s not that intuitive.
Does anyone have a set of Handbrake settings that match the X264 settings specified here?
Thanks!
Barry