{"course":{"slug":"motion-and-audio","title":"Motion, Sound and Music","url":"https://addaly.com/learn/motion-and-audio","level":"intermediate","track":"create"},"lesson":{"slug":"crf-and-bitrate","title":"Quality target or size target","url":"https://addaly.com/learn/motion-and-audio/crf-and-bitrate","position":39,"of":72,"minutes":10,"answer":"CRF asks for a quality and lets the size fall where it may, two-pass asks for a size and distributes the bits.","keyIdea":"CRF asks for a quality and lets the size fall where it may, two-pass asks for a size and distributes the bits; the preset changes how hard the encoder searches rather than the quality it aims at, and a change of about six in CRF roughly halves or doubles the file."},"body":{"format":"markdown","text":"## Two different questions, two different controls\n\n\"How big should this file be?\" and \"how good should this look?\" are different questions, and encoders have separate modes for them. Choosing the wrong mode is the most common cause of a file that is either enormous or unnecessarily ugly.\n\n**Constant quality** (CRF, or constant rate factor). You state a quality target and the encoder spends whatever bits that takes: more on the complicated shots, fewer on the simple ones. The output size is not known in advance.\n\n**Target bitrate** (ABR, VBR, two-pass). You state a size or a rate and the encoder hits it, distributing the bits as well as it can. Quality varies with the content.\n\n**Constant bitrate** (CBR). Every second uses the same number of bits, whatever is happening. Wasteful on easy content, poor on hard content, and required for broadcast transport streams and some live-streaming ingests because the downstream system has a fixed pipe.\n\n## CRF, which is what you usually want\n\n```bash\nffmpeg -i in.mov -c:v libx264 -crf 20 -preset slow -c:a aac -b:a 192k out.mp4\n```\n\nThe scale for x264 and x265 runs 0 to 51, lower being better. The numbers worth knowing:\n\n- **CRF 18**: visually near-transparent for most content. Large files.\n- **CRF 20 to 23**: the practical range for good delivery. 23 is x264's default.\n- **CRF 26 to 28**: visibly soft on detail and motion; acceptable for small previews.\n\n**A change of about 6 in CRF roughly halves or doubles the bitrate.** CRF 26 is about a quarter the size of CRF 20 on the same source. That relationship is the useful one to carry around, because it lets you estimate without trial encodes.\n\n> Figure: What a change in CRF does to the file. Line chart of megabytes, two minutes at 1080p against CRF, lower being better quality: Same source, same preset (18, 52) (20, 40) (23, 28) (26, 20) (29, 14) (32, 10). A change of about six in CRF roughly halves or doubles the size, which lets you estimate without trial encodes. The preset is a separate control: at a fixed CRF it changes how hard the encoder searches for a cheap way to reach that quality, so a slower preset gives a smaller file of the same quality rather than a better one. Numbers do not carry between encoders: x265 at 28 is roughly x264 at 23.\n\nx265 and AV1 use the same scale with different meanings. x265's CRF 28 is approximately x264's CRF 23 in quality, and produces a smaller file. Do not carry a number between encoders.\n\n## The preset is not quality\n\n```bash\n-preset veryslow   # slowest, most efficient\n-preset slow\n-preset medium     # default\n-preset veryfast\n-preset ultrafast  # fastest, least efficient\n```\n\nWith CRF fixed, the preset does not change the target quality: it changes how much **search effort** the encoder spends finding a cheap way to reach it. A slower preset at the same CRF produces a smaller file of the same quality. Going from `medium` to `slow` typically saves 5 to 10 per cent of the size for roughly double the encode time; `veryslow` saves a little more for a lot more time.\n\nThe practical rule: use the slowest preset you can tolerate for anything that will be downloaded many times, and `veryfast` for a preview you are going to look at once.\n\n## When you need a size\n\nTwo-pass, which is what \"fit this into 8MB\" means:\n\n```bash\n# target bitrate = (target size in bits) / duration, minus audio\nffmpeg -y -i in.mov -c:v libx264 -b:v 1400k -pass 1 -an -f mp4 /dev/null\nffmpeg    -i in.mov -c:v libx264 -b:v 1400k -pass 2 -c:a aac -b:a 128k out.mp4\n```\n\nThe first pass analyses the whole file and writes a log of how complex each part is. The second pass uses it to distribute the bits. This is meaningfully better than a single-pass attempt at the same bitrate, because the encoder in pass one does not yet know that a difficult scene is coming.\n\nThe arithmetic: for an 8MB target over 30 seconds, that is 64 megabits over 30 seconds, about 2.1 Mbit/s total. Subtract 128 kbit/s for audio and a few per cent for container overhead, and you have roughly 1.9 Mbit/s for video.\n\n## The one flag people forget\n\n```bash\n-movflags +faststart\n```\n\nAn MP4 contains a `moov` atom holding the index of the whole file. By default ffmpeg writes it at the end, because it does not know the final sizes until it has finished. A browser streaming that file has to download to the end before it can play a single frame.\n\n`+faststart` runs a second pass over the finished file to move the index to the front. Without it, your web video does not start until it has fully downloaded, which people then diagnose as a slow server. It costs a file rewrite and it is not optional for anything served over HTTP.\n\n## Hardware encoders and what they cost\n\n`h264_nvenc`, `h264_qsv`, `h264_videotoolbox` and `h264_vaapi` encode on the GPU or a dedicated block, often ten to twenty times faster than x264.\n\nThey are less efficient. At the same file size, a hardware H.264 encode is noticeably worse than `x264 -preset slow`: the gap is usually described as one to two CRF points, and it is larger on difficult content. The silicon implements a smaller search.\n\nUse them for live streaming, for screen recording, for anything where encode time is the constraint. Use software for anything that will be distributed.\n\n## Choosing the codec\n\n- **H.264**: universal. Every browser, every device, every player. Still the correct default for general delivery.\n- **H.265 / HEVC**: roughly 30 to 50 per cent smaller at the same quality. Patent licensing is complicated and browser support is uneven, which is why it is common in apps and rare on the open web.\n- **VP9**: comparable to HEVC, royalty-free, supported in Chrome, Firefox and Edge, and by Safari in WebM.\n- **AV1**: another 20 to 30 per cent over VP9, royalty-free, and slow to encode. `libaom` is the reference and is very slow; `SVT-AV1` is far faster and is what most people should use now.\n\n## The free path\n\nEverything above is **ffmpeg** and the open-source encoders it wraps: x264, x265, libvpx, SVT-AV1. These are not budget alternatives: x264 is the encoder against which commercial products are benchmarked, and it is what most of the industry ships. **HandBrake** is a free graphical front end for the same encoders if the command line is not for you.\n\n## The limitation\n\nCRF is a quality target only in the sense that the encoder's internal model says so. That model is tuned on typical camera footage, and it misjudges content that is not: screen recordings with large flat areas and sharp text, animation with hard edges, and anything with heavy grain. For those, the CRF that looks right is often three or four points from the usual one, and there is no way to know except to look.\n\nAnd every quality number here (CRF values, \"30 per cent smaller\", the PSNR and VMAF scores behind them) is an average over test material chosen by the people quoting it. On your footage the numbers will differ, sometimes substantially, which is why a thirty-second test encode remains the only honest method."},"check":{"question":"A file encoded at CRF 20 with -preset medium is re-encoded at CRF 20 with -preset veryslow. What should you expect?","options":[{"text":"A noticeably better-looking file of about the same size, because the slower preset spends its extra time improving the picture at the same bitrate.","correct":false,"tempting":"Reads the preset as a quality dial; with CRF fixed, the quality target does not move."},{"text":"An identical file, because CRF fully determines the output and the preset only affects how long the encoder takes to produce it.","correct":false,"tempting":"Overcorrects: the preset genuinely changes the result, just in size rather than in quality."},{"text":"A smaller file of roughly the same quality, taking considerably longer to encode.","correct":true},{"text":"A larger file of better quality, because a slower preset enables more reference frames and a deeper B-frame pyramid, and each additional reference frame the encoder is permitted to use adds to the per-frame header cost across the whole stream.","correct":false,"tempting":"More references cost almost nothing in headers and are used precisely because they reduce the residual, which shrinks the file."}]},"prev":{"slug":"intra-vs-inter-frames","title":"Frames that stand alone, and frames that do not","url":"https://addaly.com/learn/motion-and-audio/intra-vs-inter-frames"},"next":{"slug":"the-gamma-shift","title":"Why your export looks washed out","url":"https://addaly.com/learn/motion-and-audio/the-gamma-shift"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Quality target or size target', in Motion, Sound and Music. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/motion-and-audio/crf-and-bitrate (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Quality target or size target","courseTitle":"Motion, Sound and Music","module":{"index":5,"slug":"codecs-colour-and-delivery","title":"Codecs, colour and delivery"},"answer":null,"keyIdea":"CRF asks for a quality and lets the size fall where it may, two-pass asks for a size and distributes the bits; the preset changes how hard the encoder searches rather than the quality it aims at, and a change of about six in CRF roughly halves or doubles the file.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"line","title":"What a change in CRF does to the file","series":[{"label":"Same source, same preset","points":[[18,52],[20,40],[23,28],[26,20],[29,14],[32,10]]}],"xLabel":"CRF, lower being better quality","yLabel":"megabytes, two minutes at 1080p","caption":"A change of about six in CRF roughly halves or doubles the size, which lets you estimate without trial encodes. The preset is a separate control: at a fixed CRF it changes how hard the encoder searches for a cheap way to reach that quality, so a slower preset gives a smaller file of the same quality rather than a better one. Numbers do not carry between encoders: x265 at 28 is roughly x264 at 23."},"alt":"Figure: What a change in CRF does to the file. Line chart of megabytes, two minutes at 1080p against CRF, lower being better quality: Same source, same preset (18, 52) (20, 40) (23, 28) (26, 20) (29, 14) (32, 10). A change of about six in CRF roughly halves or doubles the size, which lets you estimate without trial encodes. The preset is a separate control: at a fixed CRF it changes how hard the encoder searches for a cheap way to reach that quality, so a slower preset gives a smaller file of the same quality rather than a better one. Numbers do not carry between encoders: x265 at 28 is roughly x264 at 23."}},"blocks":[{"t":"h2","id":"two-different-questions-two-different-controls","runs":[{"text":"Two different questions, two different controls"}]},{"t":"p","runs":[{"text":"“How big should this file be?” and “how good should this look?” are different questions, and encoders have separate modes for them. Choosing the wrong mode is the most common cause of a file that is either enormous or unnecessarily ugly."}]},{"t":"p","runs":[{"text":"Constant quality","b":true},{"text":" (CRF, or constant rate factor). You state a quality target and the encoder spends whatever bits that takes: more on the complicated shots, fewer on the simple ones. The output size is not known in advance."}]},{"t":"p","runs":[{"text":"Target bitrate","b":true},{"text":" (ABR, VBR, two-pass). You state a size or a rate and the encoder hits it, distributing the bits as well as it can. Quality varies with the content."}]},{"t":"p","runs":[{"text":"Constant bitrate","b":true},{"text":" (CBR). Every second uses the same number of bits, whatever is happening. Wasteful on easy content, poor on hard content, and required for broadcast transport streams and some live-streaming ingests because the downstream system has a fixed pipe."}]},{"t":"h2","id":"crf-which-is-what-you-usually-want","runs":[{"text":"CRF, which is what you usually want"}]},{"t":"code","lang":"bash","label":"Bash","text":"ffmpeg -i in.mov -c:v libx264 -crf 20 -preset slow -c:a aac -b:a 192k out.mp4"},{"t":"p","runs":[{"text":"The scale for x264 and x265 runs 0 to 51, lower being better. The numbers worth knowing:"}]},{"t":"ul","items":[[{"text":"CRF 18","b":true},{"text":": visually near-transparent for most content. Large files."}],[{"text":"CRF 20 to 23","b":true},{"text":": the practical range for good delivery. 23 is x264’s default."}],[{"text":"CRF 26 to 28","b":true},{"text":": visibly soft on detail and motion; acceptable for small previews."}]]},{"t":"p","runs":[{"text":"A change of about 6 in CRF roughly halves or doubles the bitrate.","b":true},{"text":" CRF 26 is about a quarter the size of CRF 20 on the same source. That relationship is the useful one to carry around, because it lets you estimate without trial encodes."}]},{"t":"p","runs":[{"text":"x265 and AV1 use the same scale with different meanings. x265’s CRF 28 is approximately x264’s CRF 23 in quality, and produces a smaller file. Do not carry a number between encoders."}]},{"t":"h2","id":"the-preset-is-not-quality","runs":[{"text":"The preset is not quality"}]},{"t":"code","lang":"bash","label":"Bash","text":"-preset veryslow   # slowest, most efficient\n-preset slow\n-preset medium     # default\n-preset veryfast\n-preset ultrafast  # fastest, least efficient"},{"t":"p","runs":[{"text":"With CRF fixed, the preset does not change the target quality: it changes how much "},{"text":"search effort","b":true},{"text":" the encoder spends finding a cheap way to reach it. A slower preset at the same CRF produces a smaller file of the same quality. Going from "},{"text":"medium","code":true},{"text":" to "},{"text":"slow","code":true},{"text":" typically saves 5 to 10 per cent of the size for roughly double the encode time; "},{"text":"veryslow","code":true},{"text":" saves a little more for a lot more time."}]},{"t":"p","runs":[{"text":"The practical rule: use the slowest preset you can tolerate for anything that will be downloaded many times, and "},{"text":"veryfast","code":true},{"text":" for a preview you are going to look at once."}]},{"t":"h2","id":"when-you-need-a-size","runs":[{"text":"When you need a size"}]},{"t":"p","runs":[{"text":"Two-pass, which is what “fit this into 8MB” means:"}]},{"t":"code","lang":"bash","label":"Bash","text":"# target bitrate = (target size in bits) / duration, minus audio\nffmpeg -y -i in.mov -c:v libx264 -b:v 1400k -pass 1 -an -f mp4 /dev/null\nffmpeg    -i in.mov -c:v libx264 -b:v 1400k -pass 2 -c:a aac -b:a 128k out.mp4"},{"t":"p","runs":[{"text":"The first pass analyses the whole file and writes a log of how complex each part is. The second pass uses it to distribute the bits. This is meaningfully better than a single-pass attempt at the same bitrate, because the encoder in pass one does not yet know that a difficult scene is coming."}]},{"t":"p","runs":[{"text":"The arithmetic: for an 8MB target over 30 seconds, that is 64 megabits over 30 seconds, about 2.1 Mbit/s total. Subtract 128 kbit/s for audio and a few per cent for container overhead, and you have roughly 1.9 Mbit/s for video."}]},{"t":"h2","id":"the-one-flag-people-forget","runs":[{"text":"The one flag people forget"}]},{"t":"code","lang":"bash","label":"Bash","text":"-movflags +faststart"},{"t":"p","runs":[{"text":"An MP4 contains a "},{"text":"moov","code":true},{"text":" atom holding the index of the whole file. By default ffmpeg writes it at the end, because it does not know the final sizes until it has finished. A browser streaming that file has to download to the end before it can play a single frame."}]},{"t":"p","runs":[{"text":"+faststart","code":true},{"text":" runs a second pass over the finished file to move the index to the front. Without it, your web video does not start until it has fully downloaded, which people then diagnose as a slow server. It costs a file rewrite and it is not optional for anything served over HTTP."}]},{"t":"h2","id":"hardware-encoders-and-what-they-cost","runs":[{"text":"Hardware encoders and what they cost"}]},{"t":"p","runs":[{"text":"h264_nvenc","code":true},{"text":", "},{"text":"h264_qsv","code":true},{"text":", "},{"text":"h264_videotoolbox","code":true},{"text":" and "},{"text":"h264_vaapi","code":true},{"text":" encode on the GPU or a dedicated block, often ten to twenty times faster than x264."}]},{"t":"p","runs":[{"text":"They are less efficient. At the same file size, a hardware H.264 encode is noticeably worse than "},{"text":"x264 -preset slow","code":true},{"text":": the gap is usually described as one to two CRF points, and it is larger on difficult content. The silicon implements a smaller search."}]},{"t":"p","runs":[{"text":"Use them for live streaming, for screen recording, for anything where encode time is the constraint. Use software for anything that will be distributed."}]},{"t":"h2","id":"choosing-the-codec","runs":[{"text":"Choosing the codec"}]},{"t":"ul","items":[[{"text":"H.264","b":true},{"text":": universal. Every browser, every device, every player. Still the correct default for general delivery."}],[{"text":"H.265 / HEVC","b":true},{"text":": roughly 30 to 50 per cent smaller at the same quality. Patent licensing is complicated and browser support is uneven, which is why it is common in apps and rare on the open web."}],[{"text":"VP9","b":true},{"text":": comparable to HEVC, royalty-free, supported in Chrome, Firefox and Edge, and by Safari in WebM."}],[{"text":"AV1","b":true},{"text":": another 20 to 30 per cent over VP9, royalty-free, and slow to encode. "},{"text":"libaom","code":true},{"text":" is the reference and is very slow; "},{"text":"SVT-AV1","code":true},{"text":" is far faster and is what most people should use now."}]]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"Everything above is "},{"text":"ffmpeg","b":true},{"text":" and the open-source encoders it wraps: x264, x265, libvpx, SVT-AV1. These are not budget alternatives: x264 is the encoder against which commercial products are benchmarked, and it is what most of the industry ships. "},{"text":"HandBrake","b":true},{"text":" is a free graphical front end for the same encoders if the command line is not for you."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"CRF is a quality target only in the sense that the encoder’s internal model says so. That model is tuned on typical camera footage, and it misjudges content that is not: screen recordings with large flat areas and sharp text, animation with hard edges, and anything with heavy grain. For those, the CRF that looks right is often three or four points from the usual one, and there is no way to know except to look."}]},{"t":"p","runs":[{"text":"And every quality number here (CRF values, “30 per cent smaller”, the PSNR and VMAF scores behind them) is an average over test material chosen by the people quoting it. On your footage the numbers will differ, sometimes substantially, which is why a thirty-second test encode remains the only honest method."}]}],"check":{"question":[{"text":"A file encoded at CRF 20 with -preset medium is re-encoded at CRF 20 with -preset veryslow. What should you expect?"}],"options":[{"text":[{"text":"A noticeably better-looking file of about the same size, because the slower preset spends its extra time improving the picture at the same bitrate."}],"correct":false,"tempting":[{"text":"Reads the preset as a quality dial; with CRF fixed, the quality target does not move."}]},{"text":[{"text":"An identical file, because CRF fully determines the output and the preset only affects how long the encoder takes to produce it."}],"correct":false,"tempting":[{"text":"Overcorrects: the preset genuinely changes the result, just in size rather than in quality."}]},{"text":[{"text":"A smaller file of roughly the same quality, taking considerably longer to encode."}],"correct":true,"tempting":null},{"text":[{"text":"A larger file of better quality, because a slower preset enables more reference frames and a deeper B-frame pyramid, and each additional reference frame the encoder is permitted to use adds to the per-frame header cost across the whole stream."}],"correct":false,"tempting":[{"text":"More references cost almost nothing in headers and are used precisely because they reduce the residual, which shrinks the file."}]}],"order":[1,2,3,0],"why":null},"prev":{"slug":"intra-vs-inter-frames","title":"Frames that stand alone, and frames that do not","minutes":10},"next":{"slug":"the-gamma-shift","title":"Why your export looks washed out","minutes":10}}}