Never edit from the card
Cards fail and get reformatted. I copy every card to two drives with checksums before anything else happens, and I only edit from those copies.
Editing and post production
Editing and post production, from card to platform
Editing is the part of audio visual work I do in my own time, in DaVinci Resolve, CapCut and Filmora, with audio clean up in Audacity. This page follows a project from the camera card to the platform: copying media safely, choosing codecs, multicam editing from ATEM ISO (isolated) recordings, colour, dialogue and loudness, captions, delivery and archive. It ends with how I find faults when an export goes wrong.
Workflow
From card to platform, in seven stages
Post production is everything that happens after the recording stops. Editing is the visible part, but most problems start earlier, with media that was copied badly or never organised, and finish later, with a file the platform turns down or a mix nobody can hear. I follow the same seven stages for a ten second clip or a two hour event.
Swipe sideways to see the whole diagram.
Footage moves one way, from ingest to archive. The only loop is review: a watermarked copy goes out, timecoded notes come back to the edit, and colour and audio are finished only after the picture is locked.
- Media
- Deliverables
- Review notes
Organise before cutting
Ten minutes spent naming bins, syncing audio and marking good takes saves hours in the edit. A tidy project is also one I can hand over or reopen a year later.
Lock picture, then finish
Colour and the final mix come after the picture is locked. Grading or mixing a scene that is then cut again is work done twice.
What each stage produces
| Stage | What I do | What comes out |
|---|---|---|
| Ingest | Copy cards and recordings to two drives with checksum verification | Verified copies, a clean card |
| Organise | Bins, names, metadata, synced audio, proxies for heavy files | A project ready to cut |
| Edit | Story first: selects, rough cut, fine cut, then picture lock | A locked timeline |
| Colour | Balance shots, match cameras, then apply one look | A graded timeline |
| Audio | Clean dialogue, balance music, meet the loudness target | A mixed and measured soundtrack |
| Deliver | Export each platform version, captions and thumbnails | Files ready to upload |
| Archive | Keep the master, the project and the source media | A project I can reopen later |
Ingest
Copy twice, check, then organise
The most expensive mistake in post production is losing footage that cannot be shot again. Ingest is where that risk is removed: every card is copied to more than one place and each copy is checked before the card is reused. Then the media is named and filed, so it can be found by anyone, including me a year later.
Swipe sideways to see the whole diagram.
Straight after the shoot, the card in my hand is the only copy of everything. I lock it or keep it apart, and I never open the camera files from it in an editor, because editors can write cache and metadata files to the card.
The Clone tool on the DaVinci Resolve Media page reads the card once and writes bit for bit copies to two destinations at the same time. Dragging files in a file manager copies them too, but nothing then proves the copies are complete.
A checksum is a short fingerprint of a file. Resolve can verify each copy against the source with checksums such as XXHash64. If any file differs, the copy fails and I know before the card is wiped, not months later.
I follow the three two one rule: three copies, on at least two kinds of storage, with one away from the other two. For me that is a working drive, a backup drive and a copy that leaves the building, on a cloud service or a drive kept elsewhere.
Only when all copies are verified do I format the card, in the camera that will use it next. Formatting in the camera, not on a computer, gives the card the file system that camera expects.
Two copies before editing
Every card and recording is on two drives, verified, before I open it in an editor.
Folders mirror the shoot
One folder per camera and card, never renamed after copying, so the files can always be found again.
Metadata at ingest
Camera, scene, take and keywords added in the Media page inspector, which Smart Bins then use to sort clips.
A folder structure that survives handover
2026-10-24 Example project/
01 Media/
A cam/ camera cards, one folder per card: A001, A002
B cam/
ATEM ISO/ the whole ISO folder, kept together with its project file
Audio/ recorder and mixer tracks
02 Graphics/ logos, lower thirds, fonts
03 Music/ licensed tracks, with their licence text
04 Project/ Resolve project exports (.drp) and backups
05 Exports/ review copies (v01, v02) and final masters
06 Captions/ .srt files per languageNames that answer questions
| Thing | How I name it | Why |
|---|---|---|
| Project folder | YYYY-MM-DD Short name | Sorts by date, readable at a glance |
| Card folder | Camera letter and card number, such as A001 | Matches the camera roll name in the metadata |
| Review copy | Short name v03 review.mp4 | Notes always refer to a version |
| Final master | Short name MASTER 1080p25.mov | Resolution and frame rate in the name |
| Platform version | Short name 9x16 Reels.mp4 | The aspect ratio is visible before opening |
Ingest starts at the venue, with checked copies before kit leaves; see my AV (audio visual) event workflows page.
Codecs
Small files to shoot, easy files to edit
Cameras record in formats designed to keep files small. Editors work best with formats designed to decode fast. Knowing the difference explains most slow timelines, and it decides how much storage a shoot needs. A codec is the method of compressing the picture; the container, such as MP4 or MOV, is the wrapper around it. Most camera formats are long GOP (group of pictures); editing formats store every frame whole.
Swipe sideways to see the whole diagram.
Long GOP (group of pictures). Most cameras and phones record H.264 or HEVC (High Efficiency Video Coding). Only some frames are whole pictures (I frames). The rest store just the changes, using frames before them (P) or on both sides (B). Files are small, but jumping to one frame means decoding several others first, which is why scrubbing feels slow.
Intra frame. Editing codecs such as Apple ProRes and Avid DNxHR store every frame as a complete picture. Files are several times larger, but the computer decodes each frame on its own, so the timeline plays and scrubs smoothly even on a modest machine.
Proxy workflow. I keep the originals and make small proxy copies to edit with. The timeline plays the proxies, and the render reads the original files, so the export keeps full quality. Resolve links the two by name, and the Blackmagic Proxy Generator app can make proxies in the background.
The formats I meet, compared
| Format | Type | Where I meet it | Editing feel |
|---|---|---|---|
| H.264 (AVC) | Long GOP, 8 bit in most cameras | Phones, cameras, ATEM ISO recordings, final uploads | Small files, slow to scrub at 4K |
| H.265 (HEVC) | Long GOP, often 10 bit | Newer cameras and phones | Smaller again, the heaviest to decode |
| Apple ProRes | Intra frame family | Masters, proxies, external recorders | Smooth, large files |
| Avid DNxHR | Intra frame family | Windows workflows, broadcast deliveries | Smooth, large files |
| Blackmagic RAW | Raw sensor data, compressed | Blackmagic cinema cameras | Smooth on a good GPU (graphics processing unit), most room to grade |
| AV1 (AOMedia Video 1) | Long GOP, very efficient | Some platform encodes and streams | For delivery, not for editing |
Apple ProRes data rates
| ProRes flavour | 1920 × 1080 at 29.97 | UHD (ultra high definition) 3840 × 2160 at 29.97 | How I use it |
|---|---|---|---|
| 422 Proxy | 45 Mb/s | 182 Mb/s | Proxies |
| 422 LT | 102 Mb/s | 410 Mb/s | Light masters, recordings |
| 422 | 147 Mb/s | 589 Mb/s | Everyday intermediate |
| 422 HQ | 220 Mb/s | 884 Mb/s | Masters for archive |
| 4444 | 330 Mb/s | 1,326 Mb/s | Graphics with transparency |
Target data rates from Apple's ProRes white paper (April 2022), without alpha. Rates scale with frame rate, so 1080p25 is a little lower.
Try it: how much storage will this shoot need?
Pick a recording or editing format, the hours recorded and the number of cameras or ISO streams. The tool works out one copy and three copies, as the three two one rule needs. ProRes rates are Apple's published targets at 29.97 frames per second. Camera rates are typical and vary by model and setting.
- Data rate
- 220 Mb/s per stream
- Per hour, per stream
- 99 GB
- One copy
- 594 GB
- Three copies
- 1.8 TB
594 GB for one copy, 1.8 TB for three. At 220 Mb/s each camera fills about 99 GB an hour. I plan drives at no more than about 80% full, so I would buy at least 2.2 TB across the three copies.
DaVinci Resolve
One application, from first cut to final file
DaVinci Resolve is my main editor. It puts editing, visual effects, colour, audio and delivery in one application, arranged as pages along the bottom of the window. Each page is a separate workspace on the same project, so moving from the edit to the grade does not mean exporting anything. Choose a page to see what it is for.
Swipe sideways to see the whole diagram.
Media. Where footage arrives. I clone cards here with checksums, browse drives, add metadata and keywords, and sync separate audio to video by timecode or by waveform, without rendering new files.
Cut. Built for speed. The upper timeline shows the whole programme and the lower one is zoomed in for trimming. The sync bin shows every camera angle at the playhead, which suits multicam events.
Edit. The traditional timeline, with tracks, titles, transitions, compound clips and multicam. Longer edits happen here.
Fusion. Visual effects and motion graphics built from nodes, such as animated titles, masks and screen replacements.
Color. Grading with a node tree, colour wheels, curves, qualifiers and scopes. The page name keeps the American spelling of the software.
Fairlight. A full audio workstation: dialogue editing, effects, buses, a mixer and loudness metering against a chosen standard.
Deliver. Render presets for each platform, custom settings for masters, and a render queue that runs several exports in one go.
Free or Studio
| Feature | DaVinci Resolve (free) | DaVinci Resolve Studio |
|---|---|---|
| Price | Free | One payment, not a subscription; about £255 in the UK in 2026 (indicative) |
| Export resolution and frame rate | Up to UHD (ultra high definition, 3840 × 2160) at 60 fps | Up to 32K and 120 fps |
| Noise reduction | Not included | Temporal and spatial noise reduction |
| AI (artificial intelligence) tools, the Neural Engine | Mostly Studio only | Magic Mask, Speed Warp, Super Scale and more |
| Hardware accelerated 10 bit HEVC and Blackmagic RAW | Not included | Included |
| HDR (high dynamic range) grading and Dolby Vision | Not included | Included |
| Collaboration | Basic | Full multi user collaboration |
Summarised from published comparisons in 2026. Blackmagic changes the split between versions, so I check the current feature list before buying.
Versions
| Version | Released | What changed for me |
|---|---|---|
| DaVinci Resolve 20 | May 2025 | Over 100 new features, many of them AI assisted |
| DaVinci Resolve 21 | June 2026 | A new Photo page for stills, more AI tools and wider RAW support |
| DaVinci Resolve 21.1 | 2026 | A point release that added an AI assistant integration |
Blackmagic usually announces a major version around the NAB (National Association of Broadcasters) show in April, then runs public betas before the final release. I wait for a point release before moving a live project.
Multicam
Live switching first, a better edit afterwards
When I stream, I switch the cameras live on a Blackmagic ATEM. A live switch is a good first draft, but it always has a late cut or a missed reaction. The ATEM ISO models add ISO (isolated) recording: every camera is saved separately alongside the switch, so the edit can rebuild the show and then improve it.
Swipe sideways to see the whole diagram.
An ATEM ISO model records each camera input as its own clean file while I switch the show live. ISO means isolated: each file is one input, with no cuts, titles or transitions in it.
The ISO files are H.264, and each carries timecode, so every angle lines up with the others. Blackmagic documents four inputs plus the programme on the smaller ISO models, and all eight inputs on the larger ones.
The switcher also saves a DaVinci Resolve project file. Opening it shows the event as a timeline, with every cut and transition I made live, linked back to the ISO files. Titles from the media pool land on their own track rather than being burnt in.
If the cameras are Blackmagic, the ATEM can send them timecode over HDMI (High Definition Multimedia Interface). That lets me relink the timeline to the cameras' Blackmagic RAW files for the grade, instead of the switcher's H.264 copies.
A live switch is never perfect. On the Cut page the sync bin shows every angle at the playhead, and source overwrite replaces a shot while keeping it in sync. I avoid ripple edits here, because they slide picture against sound.
Getting angles in sync
| Source | How I sync it | Watch for |
|---|---|---|
| ATEM ISO files | Already in sync by timecode; open the project file | Keep the ISO folder and the project file together |
| Several cameras, no shared timecode | Sync by audio waveform in the Media page or a multicam clip | Cameras need their own microphones, even poor ones |
| Camera plus a separate audio recorder | Waveform sync, then mute the camera audio | Different sample rates or frame rates cause drift |
| Mixer multitrack recording | Waveform sync against the program audio | Record a clap or tone at the start as a backup |
| Phone footage | Waveform sync after converting to a constant frame rate | Variable frame rate drifts over long clips |
Colour
Correct first, then create a look
Colour work has two halves. Correction makes every shot accurate and consistent: neutral whites, sensible exposure, matched cameras. Grading then gives the whole piece one look. I build it as a node tree, one job per node, and I trust the scopes over my eyes, because a screen in a bright room lies.
Swipe sideways to see the whole diagram.
Cinema cameras record a flat log picture that keeps detail in highlights and shadows. It looks grey on purpose. The first job is to bring it into the output colour space, either with colour management or a conversion LUT (lookup table).
I make whites and blacks neutral first, so no colour cast carries into later nodes. I judge it on the parade scope, where the red, green and blue channels should line up on something neutral.
I set levels against the waveform scope: highlights below clipping, faces at a consistent level and blacks not crushed. Screens lie about brightness, scopes do not.
A gentle curve adds depth. Each node does one job, so I can switch it off to compare, and fix one thing without disturbing the rest.
A qualifier selects skin tones so they stay natural while the rest of the image changes. The vectorscope shows a skin tone line to check against.
A creative look goes last and is shared across every shot, often on a group or timeline node. Matching cameras is done earlier, shot by shot, so the look sits on a consistent base.
The scopes I read
| Scope | What it shows | What I use it for |
|---|---|---|
| Waveform | Brightness of the picture from left to right | Exposure, clipping and crushed blacks |
| Parade | Red, green and blue waveforms side by side | White balance and colour casts |
| Vectorscope | Hue and saturation around a circle | Skin tones, over saturation, matching cameras |
| Histogram | How many pixels sit at each level | A quick check of the overall spread |
Colour space and tags on export
| Delivery | Output colour space and gamma | Why |
|---|---|---|
| Web and social (SDR) | Rec.709, gamma 2.4, tagged Rec.709 | YouTube recommends BT.709 for SDR uploads |
| Viewing in QuickTime on a Mac | Rec.709-A | Matches how macOS displays Rec.709, so the file does not look washed out |
| Broadcast | Rec.709, gamma 2.4, legal range | Broadcast specifications ask for it |
| HDR | Rec.2100 with PQ (perceptual quantiser) or HLG (hybrid log gamma) | Needs an HDR monitor to judge, and Resolve Studio |
SDR means standard dynamic range; HDR means high dynamic range. Exact settings depend on the project's colour management.
Audio post
People forgive soft pictures, not bad sound
Viewers will watch a slightly soft or noisy picture, but they leave when they cannot hear the words. Audio post production is cleaning the dialogue, balancing it with music and effects, and meeting the loudness the platform expects, measured in LUFS (loudness units relative to full scale). The chain below uses EQ (equalisation) and compression. Sound engineering is my hobby, so this is the part of post I enjoy most.
Swipe sideways to see the whole diagram.
I listen to the raw recording on headphones before changing anything: background hiss, mains hum, room echo, and words that jump out much louder than the rest. The order of the chain matters, because each step changes what the next one hears.
I take a sample of room noise from a pause, then reduce it gently. Pushing noise reduction hard makes voices sound watery, so I accept a little background rather than damage the speech. In Audacity this is Noise Reduction, under Noise Removal and Repair.
A high pass filter removes rumble from traffic, air conditioning and handling noise below the voice, typically from around 80 Hz for speech. It cleans the low end without touching the words.
An EQ (equaliser) adds a little clarity or removes boxiness. Small moves of a few decibels are usually enough. Big boosts usually mean the microphone was in the wrong place.
Sibilance control turns down harsh S and T sounds only when they happen, before the compressor makes them worse.
A compressor brings loud and quiet words closer together, so the listener does not reach for the volume. Gentle ratios keep it natural for speech.
I measure the integrated loudness of the whole programme and set it to the target for where it is going, such as −23 LUFS for broadcast or about −14 LUFS for YouTube. Audacity's Loudness Normalization effect does this in LUFS.
Raising the level can push peaks over the limit, so a limiter catches them, typically at −1 dBTP (decibels true peak). Then I measure again to check both numbers.
Fix it at the microphone
No plugin rescues a voice recorded from across a room. A lapel or a close microphone gives post production something to work with.
Keep the raw files
Every process is applied to a copy. If a later step goes wrong, I start again from the original, not from a damaged file.
Music under speech
Music sits well under dialogue, often 15 to 20 dB lower while someone is talking (typical), and comes up in the gaps.
The tools I use for audio
Audacity is free and open source, and I use it for spoken audio that needs repair before it goes into an edit: conversations recorded on a phone, a talk recorded from the room, or a voiceover. I keep the raw file, save the processed version as a new WAV (Waveform Audio File Format) file, and bring that into the editor.
| Audacity effect | Where it is | What I use it for |
|---|---|---|
| Noise Reduction | Noise Removal and Repair | Hiss and steady background noise, sampled from a pause |
| Filter Curve EQ or Graphic EQ | EQ and Filters | High pass filtering and small tone changes |
| Compressor | Volume and Compression | Evening out speech levels |
| Normalize | Volume and Compression | Setting the peak level of a clip |
| Loudness Normalization | Volume and Compression | Setting a whole file to a LUFS target; −23 LUFS is the default |
| Limiter | Volume and Compression | Catching peaks after the level is raised |
Menu names from the Audacity manual. The effect names keep Audacity's American spelling.
When the edit is in DaVinci Resolve, I mix in the Fairlight page instead of round tripping files. Each track has EQ and dynamics, buses group dialogue, music and effects, and the loudness meter measures the programme against a chosen standard while it plays. Fairlight also has dialogue tools, such as voice isolation in the Studio version.
For short social clips I use the audio tools built into CapCut and Filmora, such as noise reduction and voice enhancement, and in Filmora, ducking that lowers music under speech automatically. They are fast, but I check the result on headphones, because automatic processing can pump or sound thin.
Loudness
One number decides how loud it plays
Platforms and broadcasters measure loudness the way people hear it, not by peak level. Each has a target in LUFS. If my mix is louder than the target, it is turned down; on some platforms, if it is quieter, it stays quiet next to everything else. Knowing the target before I mix saves a second export.
Swipe sideways to see the whole diagram.
Momentary and short term loudness move with the programme. The integrated figure settles over the whole piece, and that single number is what platforms and broadcasters compare with their target. True peak is measured separately, against its own limit.
- Momentary
- Short term
- Integrated
- True peak
LUFS
Loudness units relative to full scale. A measure of how loud a programme sounds to people, defined in ITU-R BS.1770. One LU (loudness unit) is the same step as one decibel.
Integrated loudness
The loudness of the whole programme, with silence gated out. This is the single number a target refers to.
True peak
The highest level the signal reaches between samples once it is turned back into sound, in dBTP. A file can read under 0 dB and still clip when played, which is why the limit is −1 dBTP.
Loudness range
LRA (loudness range), in LU: how much the loudness varies through the programme. Speech for phones and laptops works better with a smaller range.
Targets by destination
| Destination | Integrated target | True peak | What happens to other levels |
|---|---|---|---|
| Broadcast in the UK and Europe (EBU R128) | −23 LUFS | −1 dBTP | A delivery specification; programmes outside it can be rejected |
| YouTube | About −14 LUFS | −1 dBTP | Loud uploads turned down; quiet uploads left as they are |
| Spotify (default setting) | −14 LUFS | −1 dBTP, −2 advised | Turned down, or up only while peaks allow |
| Apple Podcasts | About −16 LUFS | −1 dBTP | A recommendation for stereo spoken word |
| Instagram, TikTok, LinkedIn | Not published | −1 dBTP advised | No official target; −14 LUFS is a common working figure |
Broadcast figures from EBU R128. Platform figures come from platform help pages and published measurements, and can change without notice.
Try it: what will the platform do to my mix?
Choose where the video is going, then enter the integrated loudness and true peak a meter gives for the finished mix. The tool shows how far the level needs to move, whether a limiter is needed, and what the platform does if I upload it as it is. Platform behaviour is as published or widely measured in 2026, and can change.
- Target
- −14 LUFS, true peak −1 dBTP
- Level change
- +5 dB
- Peak after the change
- +2 dBTP
- Limiting needed
- About 3 dB
Raise it by 5 dB, with a limiter. YouTube does not turn quiet uploads up, so as it is this mix would play about 5 dB quieter than louder videos next to it. Raising it 5 dB would put peaks at +2 dBTP, so a limiter must take about 3 dB off the peaks to stay under −1 dBTP.
CapCut and Filmora
The right editor for the size of the job
Not every edit needs a full studio application. A thirty second vertical clip with captions is faster in a quick editor, while a two hour event with four cameras needs DaVinci Resolve. I pick the tool by the length of the piece, how much colour and audio work it needs, and where the media is allowed to live.
| Tool | Where it fits | What I watch for |
|---|---|---|
| DaVinci Resolve | Anything longer than a minute, multicam events, colour and proper audio | A learning curve, and it wants a capable GPU (graphics processing unit) |
| CapCut | Short vertical clips, templates, quick auto captions, fast turnaround on a phone or desktop | Owned by ByteDance. Some effects and exports need a paid plan, and the terms give it a licence over content uploaded to its cloud |
| Filmora | Quick edits with effects and AI features on Windows or Mac, without Resolve's complexity | Free exports carry a watermark. Plans are annual or perpetual, and many AI features use credits |
| Audacity | Repairing and levelling spoken audio before it goes into an edit | Edits audio only; I keep the raw file and save a new one |
Checked against the vendors' pricing and help pages in 2026. Plans and features change often, so I read the current terms before using a tool for anyone else's material.
Templates save time
For social clips, a template with my fonts, caption style and end card means each new clip takes minutes. I set it up once and reuse it.
Know where files live
Cloud based editors keep projects and media on their servers. For anything private, I keep the work local, or I read the terms first.
Finish in one place
If a short clip needs real colour or audio work, I move it into Resolve rather than fighting a quick editor's limits.
Captions
Captions make a video work with the sound off
Many people watch with the sound off, and some cannot hear it at all. Captions solve both, and a caption file also gives search engines the words in the video. The two common file formats are SRT (SubRip text) and WebVTT (Web Video Text Tracks). Both are plain text with timecodes, so they can be checked and corrected in any editor.
An SRT caption file
1
00:00:01,000 --> 00:00:03,400
Welcome, and thank you for coming.
2
00:00:03,600 --> 00:00:06,900
Today I will show how the network
carries sound and video between rooms.| Option | How it works | Best for |
|---|---|---|
| Sidecar file (.srt or .vtt) | A separate text file of timed lines, uploaded with the video | YouTube and LinkedIn, where viewers can turn captions on and off, and search engines can read them |
| Burnt in captions | The words are drawn into the picture during export | Social feeds that autoplay without sound; cannot be turned off or corrected later |
| Platform auto captions | The platform transcribes the audio after upload | A starting point; I correct names and technical terms |
| Editor auto captions | CapCut, Filmora and Resolve transcribe in the edit | Fast drafts that I then check line by line |
Caption after picture lock
Every cut after captioning moves the timing. I caption the locked edit, then export the caption file at the same frame rate as the video.
Check names and terms
Automatic transcription struggles with names, acronyms and product names. I read every line, which also catches mistakes in what was said.
Readable lines
Two short lines at most, on screen long enough to read, and kept clear of lower thirds and on screen text.
Delivery
Export once properly, then version for each platform
Every platform compresses what I upload again, so the upload should be clean and close to what the platform expects. I export a master first, then a version for each destination, each with its own shape, captions and thumbnail.
Swipe sideways to see the whole diagram.
I export one high quality master from the locked, graded and mixed timeline: ProRes with uncompressed PCM (pulse code modulation) audio at 48 kHz. Every platform version is made from it, so nothing is compressed twice from an already compressed upload file.
Vertical platforms want 9:16 at 1080 × 1920. A horizontal picture squashed into that shape looks wrong, so I reframe: crop and follow the subject, and keep captions and key text inside the area that the app's buttons do not cover.
LinkedIn plays horizontal 16:9 and vertical 4:5 well in its feed. A 4:5 version takes more of the screen on a phone without needing a full vertical edit.
Each version gets its captions: a sidecar file where the platform supports it, burnt in where the feed autoplays without sound. Each also gets its own thumbnail or cover frame.
The master, the project file and the source media are archived together, so any version can be remade later at full quality without opening old exports.
YouTube upload settings
| YouTube recommends | Setting |
|---|---|
| Container | MP4, with the index at the front of the file (Fast Start) |
| Video codec | H.264, progressive, High Profile, 2 consecutive B frames, closed GOP of half the frame rate, 4:2:0 |
| Frame rate | The same rate as the recording; interlaced footage is deinterlaced first |
| Bitrate, 1080p | 8 Mb/s at 24, 25 or 30 fps; 12 Mb/s at 48, 50 or 60 fps (SDR) |
| Bitrate, 4K | 35 to 45 Mb/s at standard frame rates; 53 to 68 Mb/s at high frame rates (SDR) |
| Audio | AAC (Advanced Audio Coding), low complexity profile, 48 kHz, stereo at 384 kb/s |
| Colour | BT.709 for SDR uploads |
From YouTube's recommended upload encoding settings, checked October 2026.
Try it: export settings for each destination
Choose a destination to see the settings I export with. YouTube figures are from its recommended upload settings. Social platforms publish sizes but few encoding details, so those bitrates are typical working values.
The frame rate always matches the recording. In the UK that is usually 25 or 50 fps.
- Frame size
- 1920 × 1080 (16:9)
- Container and codec
- MP4 with Fast Start; H.264 High Profile, progressive, 4:2:0, closed GOP of half the frame rate
- Video bitrate
- 8 Mb/s at 24 to 30 fps, 12 Mb/s at 48 to 60 fps
- Audio
- AAC, 48 kHz, stereo at 384 kb/s
- Loudness
- About −14 LUFS, true peak −1 dBTP
- Captions
- Sidecar .srt file
Review and archive
Clear versions, and nothing lost afterwards
The last stretch of a project is review, archive and the kit it all runs on. Clear version numbers keep feedback straight. A proper archive means the project can be reopened, changed or turned into new versions years later, which matters more than it seems on delivery day.
Versions, never final
Review copies are numbered v01, v02 and so on. Nothing is called final, because there is always another final. Notes always say which version they refer to.
Notes by timecode
A review link lets viewers leave notes pinned to a timecode, so "the cut at 02:14" means one frame, not a guess.
Watermarked copies
Review copies are smaller, watermarked and marked as drafts, so a draft cannot be mistaken for the release.
What I archive
| Keep | Why | Where |
|---|---|---|
| The master export | Any new version can be made from it | Archive drive and off site |
| The project file (.drp) | Reopens the edit, grade and mix exactly | With the media, and exported separately |
| Source media actually used | Needed to change the edit later | Archive drive and off site |
| Music and asset licences | Proves the right to use them if a claim arrives | In the project folder |
| Caption files | Reused for every new version | In the project folder |
Hardware that keeps the timeline smooth
| Part | What matters for editing | Typical starting point |
|---|---|---|
| GPU | Resolve does most of its work on the graphics card: playback, effects, noise reduction | A recent card with 8 GB or more of video memory |
| Memory (RAM) | Long timelines, Fusion and many layers | 32 GB for 4K work |
| Storage | Media and cache on fast SSD (solid state drive) storage; the system drive kept separate | NVMe (Non-Volatile Memory Express) SSD for media and cache |
| Monitor | A calibrated display for colour decisions | A calibrated sRGB (standard red, green and blue) or Rec.709 monitor, viewed in a dim room |
| Backup | Archive drives, a NAS (network attached storage) or LTO (Linear Tape Open) tape for long term storage | Two copies on site, one off site |
Typical figures for hobby and small studio 4K editing, not vendor minimums.
When it goes wrong
When an edit goes wrong, find the stage that broke it
Post production faults look alike: something is missing, out of sync, the wrong colour or the wrong level. I trace them the way I trace a network fault, following the media from the card to the platform until I find the stage that changed it. Choose a symptom to see where it usually sits and what I check. My general method is on the troubleshooting page.
Swipe sideways to see the whole diagram.
Media offline after moving files. The project stores where each file lives. Renaming a folder, changing a drive letter or moving the project to another computer breaks the links. I relink by pointing Resolve at the top folder, which is why I never rename card folders after ingest.
An ATEM project opens with missing clips. The project file expects the ISO recordings in the folders the switcher created beside it. If only the video files were copied, or the folders renamed, the links break. I copy the whole ISO folder as one item and relink to it if needed.
Audio drifts out of sync on phone footage. Phones and screen recorders often record a variable frame rate, which editors handle badly over long clips. I convert the footage to a constant frame rate before editing, then sync and check the end of the clip as well as the start.
Playback stutters on the timeline. Long GOP files are heavy to decode, and effects add to the load. I generate proxies or optimised media, lower the playback resolution while editing, and render cache for heavy effects. If the GPU cannot decode the codec, proxies are the answer.
The grade looks different on every screen. An uncalibrated screen or a bright room changes what I see while grading. I grade on a calibrated monitor in a dim room, check the scopes rather than my eyes, and look at the export on a phone and a laptop before release.
The upload sounds quieter than other videos. Some platforms turn loud uploads down but never turn quiet ones up. I normalise the mix to the platform target with a true peak limiter, measure it again and export a new version.
The export looks lighter than in Resolve. Players read the colour tags in the file and display them differently. For viewing on a Mac I use the Rec.709-A output tag; for platforms I keep standard Rec.709 tags and check the result in a browser, not just one player.
The render fails part way through. Usually the drive is full, or one clip is damaged. I check free space first, then find the clip at the point of failure, replace or transcode it, and render again. For long renders I render in sections that join without gaps.
Captions run late on the platform. The caption file was made before the last edit, or at a different frame rate from the video. I caption only the locked edit, export the caption file from the same timeline and play it back on the platform before publishing.
My checks before every export
| Before I export | Healthy looks like | If not |
|---|---|---|
| Media | Nothing offline, nothing linked to a card | Relink to the ingest copies |
| Timeline | Plays through at full speed with the final effects | Render cache, then check heavy clips |
| Colour | Scopes legal, cameras matched, output tag set | Fix the node or the colour management, not the export |
| Audio | Integrated loudness on target, true peak under −1 dBTP | Normalise and limit, then measure again |
| Captions | Made from this exact version | Export the caption file again from the final timeline |
| Export | Watched end to end on a second device | Fix it and export again before uploading |
Engagement
How I take a project from footage to finished file
Whether the piece is a two minute clip or a recorded event, I follow the same path. Agree what is needed and where it will be shown, check what was actually recorded, plan the edit, build it with review rounds, deliver every version, then archive the lot.
Swipe sideways to see the whole diagram.
I start with what the video is for and who will watch it, because that decides length, shape and tone. I agree the platforms, the deadline, how many review rounds there will be, and the one person who approves the final cut. Without that last name, reviews never end.
I turn the brief into a deliverables list: each version with its size, length, captions and loudness target, plus any branding rules for fonts, logos and lower thirds. Music needs a licence that covers every platform, so I agree where it comes from before editing to it.
Before editing I audit the media: every card and recording, its codec, frame rate and timecode, and where the clean audio is. I note gaps, such as a missing angle or noisy sound, while there is still time to fix them, and confirm the people on screen agreed to appear.
I plan the structure on paper first, from a transcript where there is one. Project settings are fixed at the start: resolution, frame rate and colour management, because changing them later is painful. Heavy media gets proxies, and titles and captions start from a template.
I cut for story first, share numbered and watermarked review versions, and collect notes against timecode. Once the approver signs off picture lock, I grade and mix. Changes after lock still happen, but each one is agreed, because it can undo work already done.
I export the master, then each platform version with its captions and thumbnail, and watch each one end to end on a second device. After upload I play it back on the platform itself, checking captions, loudness and the first frame, and send a delivery note listing every file.
The master, the project file, the source media used and every licence go into the archive together, on three copies. Software moves on, so I export the project file separately and note the Resolve version, which makes the project easier to reopen when the next version is needed.
Functional requirements
What the edit must deliver.
- Deliver every version on the deliverables list, at the agreed size, length and frame rate.
- Tell the story the brief asks for, within the agreed running time.
- Include accurate captions on every version, as sidecar files or burnt in.
- Use only music, footage and graphics that are licensed for every platform used.
- Keep branding consistent: fonts, colours, logos and lower thirds.
- Leave an archive from which any version can be made again.
Non functional requirements
How well it must be done, with a number wherever one can be agreed.
- Loudness
- On target for each platform, such as about −14 LUFS for YouTube or −23 LUFS for broadcast, with true peak under −1 dBTP.
- Picture
- Graded to Rec.709 for SDR delivery, with no clipped highlights on faces and cameras matched.
- Captions
- Every line checked by a person, timed to the final version, two lines at most on screen (typical).
- Turnaround
- A first cut within an agreed time after the media arrives, such as five working days for a one hour event (typical).
- Reviews
- Two or three review rounds, with notes against timecode on numbered versions (typical).
- Media safety
- Every card on two verified copies before editing, and three copies before archive.
- Archive
- Project, master and source media kept for an agreed period, such as two years (typical).
Numbers marked typical are starting points that I agree for each piece.
Who I talk to
- Whoever asked for the video, and the person who approves it
- The camera, sound and switcher crew who recorded it
- The people on screen, for releases and name spellings
- Whoever publishes it on each platform
- Rights holders for music, graphics and borrowed footage
How I find out
- A short call to agree the purpose, audience, platforms and deadline
- A media audit of every card and recording before editing starts
- A transcript of long talks to plan the structure on paper
- A test export of a short section on each platform before the full delivery
- A review of earlier videos for the same audience, to match style and length
Discovery tools
| Tool or source | What it tells me |
|---|---|
| DaVinci Resolve Media page and Clone | Verified card copies, metadata, and audio synced by timecode or waveform |
| MediaInfo | Codec, frame rate mode, bit depth and timecode of every file |
| Loudness meter in Fairlight or Audacity | Integrated loudness, true peak and loudness range of the mix |
| Scopes on the Color page | Exposure, white balance and skin tones on every camera |
| Automatic transcription in Resolve, CapCut or Filmora | A searchable transcript for planning and captions |
| Review links with timecoded notes | Feedback tied to frames, not memories |
When an edit goes wrong, I follow the media from the card to the platform and find the stage that changed it.
My approach
- Symptom. What exactly is wrong: offline, out of sync, the wrong colour, the wrong level, or rejected? On which version and which player?
- Source. Check the original file. If the fault is in the source, no setting in the edit will fix it.
- Project. Check links, clip attributes, frame rates and colour management in the project.
- Export. Check the render settings and tags against the deliverables list, then export a short section to test.
- Platform. Upload a private test and check it on the platform, on more than one device.
- Record. Note the cause and the fix in the project notes, and add a check to my export list.
Problems I see most
- Media offline after files were moved
- Audio drift on phone footage
- Stuttering 4K HEVC playback
- Lighter colours after export
- Uploads quieter than other videos
- Captions from an older cut
Layer by layer
| Layer | What I check |
|---|---|
| Media | Codec, frame rate mode, timecode and whether the files are complete copies with matching checksums. |
| Project | File links, project settings, clip attributes and colour management. |
| Timeline | Playback load, proxies, render cache and sync between picture and sound. |
| Render | Codec, size, bitrate, colour tags, audio format and loudness against the deliverables list. |
| Platform | How the platform processes, normalises and displays the upload, and its caption handling. |
The fault finder under When it goes wrong covers each problem in detail, and my general method is on the troubleshooting page.
After delivery, a video still needs looking after: corrections, new versions and questions about the files.
Corrections
A misspelt name or a wrong caption is fixed in the project, exported again and replaced on the platform, keeping the same link where the platform allows it.
New versions
Shorter cuts, new aspect ratios or other languages are made from the archived master and project, not from an upload copy.
File questions
The delivery note lists every file, with its size, codec, frame rate and loudness, so questions can be answered without reopening the project.
Platform changes
When a platform changes its sizes or rules, the deliverables template is updated for the next piece.
Rights
Licences and releases are filed with the project, ready if a claim or a takedown request arrives.
Hand over
If someone else takes the project on, the folder structure, project file and notes make the hand over quick.
Editing software, codecs and platforms all change, so I plan for the project outliving the tools it was made with.
- Software versions. Blackmagic releases a major version of DaVinci Resolve each year, with public betas first. I finish a project on the version it started on, and upgrade between projects.
- Project portability. I export the project file and note the Resolve version, so the project can be reopened later even after upgrades.
- Codec choices. Archive masters are ProRes, which editors will read for years. Long GOP upload files are not kept as masters.
- Storage refresh. Archive drives are checked and copied to new media every few years, because drives fail with age (typical).
- Platform specs. I review each platform's recommended settings before a major delivery, because sizes and limits change.
- Skills. New tools such as AI transcription and masking are tried on a copy of a project before they are trusted on live work.
Projects
Where I use it
Editing is part of my audio visual hobby. I do it in my own time, on my own kit, and the same habits I use at work carry over: verified copies, clear versions and a record of what changed.
Editing in DaVinci Resolve
In my own time I edit video in DaVinci Resolve, from ingest and multicam editing to colour, the audio mix on the Fairlight page and delivery.
Quick edits in CapCut and Filmora
Short clips and vertical versions are faster in CapCut and Filmora, with templates and automatic captions that I then check line by line.
Spoken audio in Audacity
I clean and level spoken audio in Audacity: noise reduction, filtering, compression and loudness normalisation, before it goes into the edit.
Recording with ATEM switchers
My video kit is Blackmagic ATEM Mini series switchers and a larger ATEM with SDI (serial digital interface), with PTZ (pan, tilt and zoom) and cinema cameras. What they record is what I edit. More on the live streaming page.
Live sound on an Allen & Heath Qu
Sound engineering is my hobby. I mix live sound on an Allen & Heath Qu series mixer, which is why the audio side of post production gets so much of my attention. More on the live sound page.
Audio visual training
Kramer Academy audio visual (AV) courses: AV Fundamentals and Audio Specialist, which cover the signal, cabling and audio basics that every edit depends on.
Backed by Kramer Academy courses: AV Fundamentals and Audio Specialist. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.