Two 30-second walkthrough clips, same resolution, same footage quality, can land at 8 MB and 80 MB out of the same encoder. The gap is not the camera or the content. It is three settings in the ffmpeg/libx264 invocation, all documented in FFmpeg's own H.264 encoding guide.
We build CasaNova Labs, an AI studio for real estate photo and video editing, and every video the product renders goes through this same re-encode step before it reaches a listing page. Here is what actually drives the size, straight from the docs.
CRF, not bitrate, is the setting that controls quality
FFmpeg's guide recommends Constant Rate Factor as "the recommended rate control mode for most uses" when you care about consistent quality over a guaranteed file size. The scale runs 0 to 51 for 8-bit video: 0 is lossless, 23 is the default, 51 is the worst quality possible. The docs describe "a subjectively sane range" of 17 to 28, with 17 and 18 as "visually lossless or nearly so."
The part that explains the 8 MB against 80 MB swing directly: "the range is exponential, so increasing the CRF value +6 results in roughly half the bitrate / file size, while -6 leads to roughly twice the bitrate." Applied to the documented sane range, moving from CRF 18 to CRF 28, a 10-point difference, works out to roughly a threefold difference in bitrate for identical footage, using that same exponential relationship. That is before touching resolution, frame rate or anything else.
Why not just target a fixed file size instead
CRF mode is the documented default recommendation, but the guide is upfront about what it gives up to get there: "you can't tell it to get a specific filesize or not go over a specific size or bitrate, which means that this method is not recommended for encoding videos for streaming" in the sense of guaranteeing a bitrate cap. For a walkthrough clip served once from a listing page rather than adaptively streamed, that tradeoff runs the other way: a consistent visual quality at whatever size the footage needs is the more useful property than hitting an arbitrary size target and letting quality float.
That tradeoff is also where the cost sits, because bytes served and encoder minutes are both billed. We broke down what that adds up to per listing in our breakdown of virtual staging costs.
The preset trades encoding time for file size, not quality
A preset is, per the docs, "a collection of options that will provide a certain encoding speed to compression ratio." At a fixed CRF, a slower preset produces a smaller file for the same visual quality, because the encoder spends more time finding a more efficient way to represent the same picture. The documented list, fastest to slowest:
ultrafast, superfast, veryfast, faster, fast, medium (default), slow, slower, veryslow, placebo
placebo is explicitly called out as "not useful" in the docs' own FAQ. The stated rule of thumb: "use the slowest preset that you have patience for." A worked example from the guide, targeting good quality with better compression:
ffmpeg -i input -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv
-c:a copy there stream-copies the audio track instead of re-encoding it. There is no reason to spend CPU re-compressing audio that is not being touched.
faststart is one flag, and it decides whether playback waits for the whole file
-movflags +faststart moves part of an MP4's metadata to the front of the file. FFmpeg's guide is direct about why it matters for the web specifically: it "will allow the video to begin playing before it is completely downloaded by the viewer," and it is not required for a platform like YouTube because "they can begin re-encoding before uploads complete" on their end. That distinction matters if a video is being served directly rather than re-processed by a hosting platform.
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4
Putting the numbers together
None of ultrafast/CRF 18, slow/CRF 23, or veryslow/CRF 28 will look dramatically different at a glance on a 30-second walkthrough. But per FFmpeg's own exponential CRF relationship, the gap between the low and high end of the sane range alone is close to threefold, before preset compounds it further and before faststart decides whether that file streams cleanly or stalls on the first frame. That is the trade CasaNova Labs tunes on the server side for every video the platform renders, so a walkthrough clip lands at a size a listing page can actually serve, instead of whatever preset and CRF a default ffmpeg invocation happened to pick.
If you are building the generation side of a video pipeline yourself, these three settings are most of what a 30-second clip's file size comes down to. CasaNova Labs is where we apply them to real estate listings specifically.
