Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My Canon 60D creates .MOV files when recording video and I've found out that the .MOV container has an H264 video stream and a PCM audio stream.

I've used ffmpeg and GSpot to look at some of my videos, and I see what seem to be pretty high bitrates (22,000kbps for 640x480, 45,000 for 1920x1080).

I'd like to reduce the size of the files, but keep the quality quite high. I've played around with the simplest thing I could think of, reducing the bit rate and that does what I'd expect: cut the bitrate in half and the file size is about half. But I'm wondering if there's a way to determine a "good" target bitrate, or if there's any point in trying to do variable bitrate.

share|improve this question

1 Answer 1

up vote 13 down vote accepted

But I'm wondering if there's a way to determine a "good" target bitrate …

A good target bit rate is the bit rate that either:

  • is supported by the network you're streaming the material from (e.g. a 3G network, home WiFi, etc.), which is pretty easy to calculate
  • looks good to you, which is a very subjective measure

22 Mbit/s or 45 Mbit/s are indeed quite high for the average user, and especially for already compressed video like h.264. You could definitely go ahead and reduce the bit rate to a "sane" value, always with regards to how much storage capacity you can afford and how much quality you want to lose.

You could also resize 1080p video to 720p if you don't really need the size or don't have the processing capability to edit it.

… or if there's any point in trying to do variable bitrate

The point of constant bit rate is to adapt to a streaming media scenario where there's a bottleneck that limits the maximum bit rate of the transmitted video. In today's multimedia world, this doesn't necessarily make sense anymore.

When you squeeze a video into a constant amount of bits per second, you basically tell an encoder to always use the same amount of bits to encode the same time frame. Is that the best approach? As you may have guessed by now, it's not. Quoting the CRF Guide from Handbrake (I will come back to this later):

The eye perceives more detail in still objects than when they're in motion. Because of this, a video compressor can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still. Subjectively, the video will seem to have higher quality.

So, it does make sense to use variable bit rate whenever you can. It will make the video look better, even at the same file size of a constant bit rate video.

Even more so, most encoders – the most famous one being x264 – often perform very bad when you tell them to use a constant bit rate. It's better to give them a bit more "freedom" in the sense of how many bits they want to spend on a frame. After all, that's the job of the encoder, and not you. And that's called "constant quality".


Enough of that – what does that mean in practice? If you use FFmpeg to encode videos, then you're already using a good enough tool. If you now also have x264 installed, and use the latest version of both, then you're using one of the best encoders that's currently available for free. Instead of encoding with a fixed bit rate, let x264 choose how much it wants to spend. Do this by using the Constant Rate Factor option.

In a very simple case this means setting a value between 17 and 23. I choose MP4 as output container instead of MOV because there are better tools for remultiplexing available:

ffmpeg -i input.mov -c:v libx264 -crf 22 output.mp4

The lower the value, the better the quality, and the larger the output. Vice versa, the higher, the lower the quality. At the same time, you will of course reduce the average bit rate needed. Check the x264 encoding guide for more info about ffmpeg.

Your task is now to find a CRF value that:

  • reduces the overall bit rate to the point you can afford
  • doesn't reduce the quality too much, so that the video still looks good

Yes, this involves a lot of encoding and trial-and-error, but this is daily business when you're tuning and encoding video.

Oh, and if you don't like the command line, Handbrake is a free, cross-platform tool that does exactly the same. It even has a CRF slider:

enter image description here

share|improve this answer
    
Regarding the moving object detail, isn't it regularly overdone in video compression, or do I simply remember the bad examples? Like noticeable increase in detail once the camera stops panning, etc. –  Daniel Beck Jan 30 '12 at 12:54
    
This is actually pretty common, known as "stabilizing" issues. For example, when you see the blockiness disappearing. This is typical for a low-bitrate scenario where the change of the motion difference is too fast for the rate control to adapt. I would assume that a two-pass encoding could help here, but probably not much. I don't know if it's possible to entirely get rid of these kinds of artifacts. –  slhck Jan 30 '12 at 13:13
    
I've used Handbrake in the past, converting DV avis from a videocam to DivX and mp4, but I was finding it easier to work with a command line when trying to figure out my options for going from .mov to h264 mp4s. Is there an equivalent to -crf when you're creating DivXs? (or should that be another question?) –  Ward Jan 30 '12 at 20:40
    
@Ward You can use -qscale. For mpeg* the scale is linear ranging from 1-31 (31 being the worst quality), and doubling the value will result in about half the bitrate. A value of 2 can be considered roughly visually lossless. 3-5 is usually a good balance, but of course quality is subjective and you will just need to try it. –  LordNeckbeard Jan 31 '12 at 3:43
    
Nice! Some questions. (1) what does a number followed by "p" mean in "1080p video to 720p"? (2) x264 uses a variable bitrate, but why the option in ffmpeg is called Constant Rate Factor? Thanks! –  Tim Jun 3 '12 at 19:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.