We will require a qualification task as well that must be completed by about the 19th of April at the latest, you can find all the details here. Good luck!

My brother got married.

FFmpeg finally has channel layout support for AAC and Vorbis. I’ve published my work-in-progress HE AAC v1 (Spectral Band Replication) code in FFmpeg’s Summer of Code repository (though it has nothing to do with Google SoC).

A collaboration focused on open source software between two universities in Umeå, Sweden and Vaasa, Finland called OpenKvarken held a seminar about VoIP and related technologies. I did two talks there titled: An Open Standard IPTV Implementation in MythTV and Improving FFmpeg for High Definition Video Conferencing.

The latter refers to ffmpeg-mt – multi-threaded decoding for macroblock-based codecs as developed by Alexander Strange. OpenKvarken should be funding the merge of this code into FFmpeg trunk.

I should be getting a new job with Collabora working to improve the quality of open source multimedia on the whole. It’s a very exciting venture for me and it may lead to more regular blog posts.

Theora was obsolete when it was published and its authors (Monty from Xiph) agreed with this. The encoder implementations are crap, though getting better and, the most annoying noise for me coming from the outside world is that Theora is as good as or better than H.264. Theora is NOT as good as or better than H.264! Specification-wise, Theora cannot compete with H.264. Implementation-wise, in terms of FOSS, Theora (current or Thusnelda) does not compete with x264. There are no non-FOSS Theora implementations and x264 is one of the best H.264 encoders in the world and has few rivals.

I’m all for digital media that is free (in all senses) to create, distribute and consume. I don’t think Theora is the answer.

When specifying the -b <bit rate in bits per second> option to ffmpeg, one is requesting that the video encoder target the specified bit rate as an average over the entire video stream. If you have some audio or video file, playing it back takes some amount of time i.e. it has a duration. The file also has a size in bytes. The overall average bit rate is simply the number of bits per second averaged over the duration of the entire file. So:

overall average bit rate = file size in bytes * bits per byte / duration in seconds

It should be noted that the file may contain, for example, an audio stream and a video stream. So in fact we observe something more like:

overall average bit rate = average audio bit rate + average video bit rate + average overhead bit rate = file size in bytes * bits per byte / duration in seconds

The audio and video bit rates being constituents of the overall average should be clear, but what is this overhead? Metadata tags (like the artist, album and title of a music file) could contribute to this, but they are a fixed size regardless of the duration of the file.

The rest of the overhead, beyond metadata and header information about the streams within the file, consists of various information that is part of the container format the file is using. These are things to note where one section of data begins, the time at which it should be displayed/presented to the user and other bits and pieces of information. This normally does not contribute a large amount to the overall average bit rate, but it’s worth being aware of to avoid confusion later.

Bit rate need not be the overall average however. The term bit rate simply refers to an amount of data with a corresponding duration for transmission/playback or so.

So, now we know how the bit rate and file size (if producing a file) are related, but where does quality come into the equations? There are two main ways to affect the quality of, for example, a video that one wishes to encode.

Most video encoders have a plethora of options that affect this thing called ‘quality’. Quality is subjective and that makes it difficult to quantify. The options that are supposed to improve quality, usually make the encoding process slower. This leads to a speed/quality trade off. That is, you have to consider the relation between two questions:

• How long am I willing to wait to encode this file?
• How good do I need the quality to be?

Normally the answer to the second question is “as good as it can be” within the constraints of the answer to the first question. More simply, people want the best quality from whatever amount of encoding time they deem reasonable for their job.

The other way that one can affect the perceived quality of the resulting video is to affect the bit rate used to encode it. If you try to encode 1080p video at 200 kilobits per second, it will look awful no matter what encoder and options you use. If you try to encode 1080p video at 200 megabits per second, it will probably look good no matter what encoder and options you use.

How should one approach making the decisions about what encoding options to use? Normally bit rate/file size are the most major consideration, whether streaming with an upper bound on the bandwidth available when transmitting the stream or creating a file that needs to fit on a 700MB CD. This will impose your first constraint, unless you have some terabytes of storage and don’t really care about the size too much.

After that you need to consider how long you’re willing to wait to encode something as this will impact on the options you use with your encoder of choice to obtain the best quality within your more major constraints. If the quality is not good enough within your constraints, you may need more powerful hardware or to re-evaluate the available bandwidth/storage space.

Finally we come to the -sameq option in ffmpeg. There are a number of different ways to control how the bits are allocated throughout the video. Normally one wants to observe constant quality throughout a video stream. If some frames are good and some bad, it is actually more noticeable and annoying than if all frames do not look quite as good but are consistent.

Some frames are more difficult to compress than others and so need more bits to maintain that consistent level of perceived quality. Conversely, some are easier to compress and so need less bits.

If one conducts two passes when encoding a video stream, this benefits the encoder because it already has a log of the relative complexity of each frame so it can better predict how to allocate the bits.

Traditionally, if conducting only one pass with a variable bit rate, the encoder has to try to guess based on whatever information it can from frames that have already been encoded. There are some ideas around to try to improve the bit allocation when doing one pass but I won’t discuss those here.

MPEG, and other, video codecs use a method called quantisation. This topic is also a bit too complex to discuss here. The quantiser values used in MPEG-1/-2/-4 ASP are 1, 2, …, 31 and for H.264 they are 1, 2, …, 51. Quantisers are how the encoder controls the allocation of bits to frames and parts of frames. The method of quantisation used in H.264 is different to the older codecs.

Confused? Don’t be. A frame compressed using a high quantiser will use less bits and have lower perceived quality than a frame compressed using a low quantiser. One can encode using a constant quantiser in ffmpeg by using the -qscale <quantiser> option. For MPEG-4 ASP (-vcodec mpeg4) using a value somewhere in the region of 3-5 for -qscale should produce good quality. For H.264 (-vcodec libx264) a value somewhere around the late teens to mid 20s should suffice.

So what does the -sameq option do? It uses the quantisers used in the source video stream to encode the output video stream. If converting from MPEG-4 ASP (e.g. Xvid or DivX) to H.264 (e.g. x264) this will inflate the file size considerably because of the different way these formats conduct quantisation.

Regardless, I would pretty much never recommend the use of -sameq. It does not mean “encode at the same quality as the source file”, nor does it mean “encode resulting in a file of similar size to the source file”. It just means “encode using the same quantisers” and the resulting video size and quality will likely be very unpredictable.

The conclusion: use -b with one or two passes. Or, if you’re using libx264 and you’re more concerned about quality than file size/bit rate and only want to do one pass, try -crf which uses an intelligent way of maintaining constant quality while using only one pass.