Getting it out the door
The export dialog is where a week of work either survives or does not. Its defaults were chosen by somebody who did not know what you were making.
Know the destination before you open the dialog
Every question in an export dialog has a different right answer depending on where the file is going. A broadcast deliverable, a file emailed to a client, and a vertical clip for a phone feed have almost nothing in common except the timeline they came from.
So decide first: what plays it, what are the limits, and does anything re-encode it after you.
Every platform re-encodes what you give it
Your upload is a suggestion. The service decodes it, re-encodes it at its own settings, often at several bitrates for adaptive streaming, normalises the loudness, and generates its own thumbnail unless you supply one.
Two consequences follow, and they point the same way.
Upload higher quality than the platform delivers. Giving it a file at exactly the bitrate it streams means it re-encodes an already compressed picture, and the second generation is visibly worse. Give it more than it needs and let its encoder do the reduction from clean source.
Master to the platform's loudness target so its normaliser has the least to do. Going louder than the target just means being turned down, with your dynamics already squashed for nothing.
Settings that work almost everywhere
| Setting | Value | Why |
|---|---|---|
| Container | MP4 | Plays on everything |
| Video codec | H.264, high profile | Universal support, fast encode |
| Quality | CRF 20, or 10 to 16 Mbps at 1080p | Clean source for the platform encoder |
| Frame rate | Match the source | Conversion causes judder |
| Audio codec | AAC, 192 kbps, 48 kHz | Transparent for speech and music beds |
| Loudness | -16 LUFS integrated, -1 dBTP | Safe across web platforms |
| Faststart | On | Playback starts before the download finishes |
When there is a hard size limit
Size is bitrate times duration and nothing else. If the ceiling is 8 MB for sixty seconds you have about 1 Mbps, and no encoder setting changes the arithmetic.
Your moves, in order of how much they cost you: shorten the piece, drop to 720p, use two pass encoding so the bits land where they matter, and denoise the source so the encoder is not spending bits describing randomness.
720p at 1 Mbps looks considerably better than 1080p at 1 Mbps. Resolution is the first thing to give up, not the last.
Hardware encoding, and when not to use it
Your graphics card can encode many times faster than your processor and slightly worse at the same bitrate. For a draft, a screen recording, or a two hour meeting capture, that trade is obviously worth it. For a final file where quality per byte matters, use software encoding and go and do something else while it runs.
What to keep when it is finished
Three things, and the smallest one is the most important.
The project file. It is tiny and it is irreplaceable. Losing it while keeping the footage means doing the work again.
The source media, in the folder structure the project expects. Move it and the project goes offline. Keep media and project together and move the whole folder as one thing.
One high quality flat export, with no platform specific cropping or loudness applied. That is your archive master. In five years the platform version will be gone and the original camera files may not open in current software, and the flat master will still play.
Before you publish
- Watch the exported file, not the timeline. They are not the same thing and this is the last chance to catch a render error.
- Check the first five seconds hard. That is where people leave.
- Check the last two seconds for a stray frame of black or a clipped word.
- Scan for gaps, which export as black or silence.
- Listen on a phone speaker at half volume.
- Read every title on a phone.
- Confirm the loudness reading against your target.
- Choose the thumbnail yourself.
- Spell check the captions and the names.