Many years ago, I created this guide to 'extreme' compression using x264 - attaining compact, high-quality files through the use of the most heavily optimised configuration, without regard to processing time or to the amount of human attention required.
In the years since, technology and expectations have advanced and rendered much of this guide obsolete. HTML5 video, then a new technology, has become widely established. Where once almost all video was downloaded, it is now as likely to be streamed. Most importantly, device profiles matter a lot more, as viewing video on comparatively low-powered devices such as tablets and phones has become just as important as viewing on PCs and laptops.
As I write this new introduction, h265 is poised to take over from h264 - a codec substantially more advanced. I hae decided against updating this guide to modern technologies and conventions, as this would be a near-total rewrite. Certain portions of it, however, still hold value, and so nor am I going to take it down entirely. Insead I am archiving it into IPFS, to serve as both a reference and as a historical view into the video technology of the 2000's.
Please bear this in mind when using anything you read below: Much of it is written with old technology in mind, and no longer conforms to current best practices. These instructions are aimed at creating the most compact possible file for download, and push the playback device to a limit that many portables are unable to play back. Nothing below should be followed blindly, but only taken as a suggestion.
- Codebird, 2017, with regard to Codebird, 2007.
This is a guide to video compression, so I won't cover audio preparation in detail. There are a few points to bear in mind, though.
If you have a lot of additive analog noise, you might want to try using the noise removal filter in Audacity. It works wonders on that type of noise. Not only will your audio sound cleaner, it'll compress better too! Quite honestly, I have no idea how this works - I'm quite knowledgeable on signal processing, but this filter is a mystery to me. Some sort of mathematical magic. I do not question the magic filter, but you can often trust in it to achieve a seemingly impossible removal of background hiss.
Make sure to get the right number of channels - which is not always the number of channels in your source! It is very common to find 'stereo' audio that contains only two identical tracks, taken from a mono source. These usually occur because a previous format in the chain (DVB or DVD, for example) does not support mono audio at all, or because the mono section was embedded within a larger stereo program (eg, a piece of historical video used within a modern documentery), or because a broadcaster wishes to maintain a single consistent standard across all programs. Likewise, it is also common to find 5.1 audio which is really stereo with additional silent tracks. These excessive tracks just waste resources, so if you have determined that your audio falls into these situations it may be a good idea to downmix appropriately. You may also wish to downmix 5.1 to stereo if you intend for it to be viewed primarily on mobile devices (Which only have two earphones) or if the video simply doesn't have anything happening which would benefit from 5.1. In the latter case, even mono may be a good idea - no-one cares about stereo if all you have on screen is a single person talking. You can tell stereo from mono using an X/Y plot, or via the simpler method of listening using headphones. Even the untrained ear can recognize stereo with headphones.
When it comes to codec, you have a few options. The classic MP3 is now quite dated - there are many modern codecs which outperform it easily - and it doesn't support 5.1 at all. Its sole advantage is universal support, but if you're encoding for small size you'll need something more advanced. Choice of audio is dictated by your target playback device or software and legal issues. Vorbis is a good choice for everything except HTML5 video (more on which shortly). It is free in every sense, supported by the Android operating system natively and provides good performance at any bitrate, even the very low sub-64kbit, and handles an arbitrary number of channels. In theory, anyway: Not all players handle 5.1 Vorbis correctly. The alternative options are AAC or AC3, both of which are equally capable, but more likely to run into patent or legal issues.
If you are encoding for an HTML5 video tag though, your foremost concern is browser support for the codec - it isn't practical to ask people to install a codec or switch browser to view your website. As is the case with video, HTML5 audio is currently in a state of conflict as various organizations battle it out over patents - each party determined to make sure their own technology comes out on top. For this reason, Internet Explorer and Safari do not support Vorbis and are unlikely to do so in the foreseeable future: It is a chief competitor to the codecs owned by their respective companies. This limits you to only two options if you are encoding video for HTML5 in those browsers: AAC, and the old fallback MP3. Conversely, though, neither of these is supported by Firefox: Both are covered by patents which cannot be licensed in a way consistent with the open-source development model. The end result of this mess is the same as with video: In order for your HTML5 video tag to work on all browsers, you must supply at least two files: One using h264 and aac audio for use by Internet Explorer and Safari, and one using VP8/webm with Vorbis audio for use by Firefox and most other browsers. The only browser able to handle both AAC and Vorbis is Chrome, but even that lacks support for h264 video.Muxing, metadata and publishing
Your video is done! But not yet ready to go out. Before distribution, it must be properly packed into the right container. Compared to what you've done so far, this is easy, but there are a few rules to remember.
If you're encoding this as a video to use with the HTML5 video tag, then you'll probably be stuck with the .mp4 container - it's about the only one Internet Explorer supports. Although if you're planning to use these settings for HTML5 video, please recall that these extreme settings are not within any h264 profile and you should expect viewers on portable devices to have problems.
AVI is, essentially, obsolete. It's a wonderful format to work with during production, but its age shows for actually releasing anything. No subtitle support, multichannel audio only via a horrible hack, no metadata and a severe problem with losing audio sync when carrying any form of VBR audio. It is growing increasingly rare, and should never be used when releasing a file. The most popular container for downloadable video distribution at the time of writing is the MKV or Matroska container. It supports all of those things AVI doesn't, along with some more esoteric but powerful abilities like pixel aspect ratio and variable frame rate. OGM enjoyed a brief popularity (And may still be found floating around in anime releases of the appropriate period), but has been displaced by MKV. In most cases, you want this.
As you are reading a guide to x264, I'm going to assume you have already considered patent implications. I won't go into the topic any further than to remind you. While it would be fantastic to be able to use a less encumbered codec, there simply isn't any yet that can be a match - it has taken many years and some of the best experts in the field to get the x264 encoder to where it is today, and neither Theora nor VP8 can yet come close to that level of polish. VP8 is, I have heard from experts greater than myself, just as capable as h264 in specification - its disadvantage comes from the lack of encoders so mature as those available for h264.
The settings in this document are not for portable devices - they pay no regard to h264 profiles, and can take a substantial amount of memory and processing power just to decode. I've done a few tests: A WDTV Live box handles even the most demanding video I threw at it well, but tablets and mobile phones running Android tended to have some issues with hardware decoding rejecting the video outright and software struggling to keep up leading to sync issues. I've not tested any iDevices, as I own none.
Subtitles should now be included in the MKV itself. The old practice of separate sub files is another relic of the days when AVI ruled, but a practice that should be phased out - the files are easily misplaced and just create a management headache. As subtitles in text format use essentially negligible space, there is no reason not to include them. Additional language audio tracks and commentaries are large enough that keeping them separate is justified. Subtitles are not.
Finally, remember the meta-tags. Title, artist/studio, release year, copyright, album, source. Anything you can include, do so. It makes things much easier for those who have to later keep track of thousands of files. Your file is likely at some point to go wandering around the internet alone, with only these tags to describe it, so they do matter.