Proxy Editing
Proxy editing is the practice of doing the editing work against small, easy-to-decode stand-in copies of your footage, and then applying the finished edit back to the original camera files for the final render. The proxies are lower-resolution, lower-bitrate transcodes — commonly half or quarter frame size in an intra-frame codec such as ProRes 422 Proxy or DNxHR LB — that carry exactly the same duration, frame rate and timecode as the originals, so a cut point lands on the same frame in both. Nothing in the finished video comes from the proxy; it exists only so that scrubbing, playback and previewing are fast. Because an edit is recorded as timed decisions rather than as pixels, substituting the originals for the proxies at the end is free, and the export is the full quality the camera recorded.
The Bottleneck Is Decoding, Not Disk
Most explanations of proxies start with file size, and that is the wrong place to start. The reason a 4K clip stutters when you drag the playhead is not that it is large. It is that the format it was recorded in was designed to be played once, forwards, and you are asking it to be read backwards, at random, forty times a minute.
Cameras and phones record long-GOP H.264 or HEVC. Most frames in that stream are not pictures at all — they are descriptions of how this frame differs from other frames. A complete, self-contained keyframe appears only every 12 to 60 frames, typically once every one or two seconds. To show you the frame at 07:12.400 the decoder has to find the keyframe before it and reconstruct every frame in between. Drag the playhead a second to the left and it does the whole run again. This is why scrubbing, the single most common thing an editor does, is the pathological case for the format.
Recent camera codecs make it worse in a specific, measurable way. Consumer GPUs generally have fixed-function hardware decoders for 8-bit 4:2:0 H.264 and HEVC, which is what streaming services deliver. A mirrorless camera shooting 10-bit 4:2:2 HEVC produces something those decoders will not touch, so playback falls back to software decode spread across CPU cores. Nothing about the machine is slow; the fast path simply is not there.
A proxy fixes this by changing the codec, not just the size. Proxies are intra-frame: every frame is compressed independently and decodes with no dependency on any other frame, so any frame in the file is one decode away from being on screen. Apple's ProRes family is built on exactly this property — each frame stored independently, giving random access at the cost of bitrate. That trade is the entire point.
What a Proxy Actually Is
A proxy is a transcode with four properties that must hold, and one that is negotiable.
- Identical duration and frame count. A proxy one frame short of the original is worse than no proxy: every cut after the discrepancy lands late, and the error is invisible until the conform.
- Identical frame rate. Not 29.97 against 30, not 23.976 against 24. A 0.1% rate mismatch is about 3.6 seconds of drift per hour — small enough to pass a spot check, large enough to ruin a sync.
- Identical timecode start. The conform matches decisions to media by time. If the proxy starts at 00:00:00:00 and the camera file starts at 14:22:07:11, every decision is offset by fourteen hours.
- A discoverable relationship to the original — matching filename stem, or a mapping the software stores. This is the part desktop editors expose as "attach proxies" and "relink".
- Negotiable: the picture itself. Resolution, bit depth, chroma and bitrate are all free to degrade, because none of them survive into the export.
The usual sizes are half or quarter frame size. Against a UHD 3840×2160 original, half is 1920×1080 (a quarter of the pixels) and quarter is 960×540 — 1/16 the pixels, which is where most people settle because it is still sharp enough to judge framing and read on-screen text. Final Cut Pro offers proxy resolutions down to 12.5%; Premiere's ingest presets generate around 1024×540 or 1280×720; Resolve exposes a resolution setting on the same command that generates its optimized media.
The codecs are the offline-grade members of the professional intra-frame families. ProRes 422 Proxy is 10-bit 4:2:2 at roughly 45 Mbit/s at 1920×1080 29.97 — against about 147 Mbit/s for ProRes 422 and about 220 Mbit/s for ProRes 422 HQ at the same frame, which tells you exactly how much picture is being thrown away. DNxHR LB ("low bandwidth") is Avid's equivalent, 8-bit 4:2:2, and the member of that family explicitly intended for offline work. All-intra H.264 shows up where broad compatibility matters more than decode speed.
The Conform: Why the Swap Is Free
Substituting the originals back in works for one reason: an edit is not made of pixels. It is a list of timed decisions — this range of that source, starting here in the program — held in an edit decision list. A decision list contains no resolution anywhere in it. Point the same list at media that is four times larger and the cuts land on the same frames, because a frame is identified by time, not by how many pixels are in it.
This is the direct descendant of tape-era offline/online post. An offline edit made the creative decisions cheaply against low-quality dubs; an online session rebuilt those decisions once, at full quality, from the camera masters; the only thing that travelled between them was the list. Non-linear editing collapsed both stages onto one machine, but the economics never changed, so the split survives as a toggle rather than as two rooms.
The one class of decision that does not survive automatically is anything denominated in pixels. A crop stored as "start at x=240" against a 960×540 proxy is four times too small when conformed to 3840×2160. Same for a blur radius, a text size, a motion path, a censoring box. Systems that handle this correctly store geometry as a fraction of the frame — 0 to 1, or a percentage — so the conform is a pure multiply. When someone tells you their titles moved after switching proxies off, this is what happened.
Colour is the other honest caveat. Judging a grade on an 8-bit, heavily compressed, chroma-subsampled proxy is not the same as judging it on the original. Banding you cannot see in the proxy can be present in the master, and shadow detail you think you have crushed may still be there. Serious grading happens after the conform, for the same reason it used to happen in the online suite.
A Scenario Where It Shows
You shoot a 40-minute talking-head piece on a mirrorless camera in UHD, 10-bit 4:2:2 HEVC at around 150 Mbit/s. That is roughly 45 GB of file for forty minutes. On a laptop the timeline plays at maybe half speed and every scrub lands a second or two after you let go of the mouse — which means every decision about where a cut goes is made from a still frame you had to wait for, and you stop making fine ones.
You generate quarter-size proxies. The picture is 960×540 now, obviously softer in the viewer, and the proxy set is a few gigabytes. Playback is real-time, scrubbing is instant, and you cut the whole piece in an afternoon — including the fiddly bits you would have skipped, because trying a cut two frames earlier now costs nothing.
Then you export, and the video is 540p and soft. Nothing is wrong with your project; you exported with proxies still enabled. The timeline looks byte-identical either way, so this failure is completely silent right up to the moment you watch the file back — which is why every proxy tutorial ends with the same sentence, and why every editor has done it at least once anyway.
Common Misconceptions
"Proxies are always smaller files."
Usually, not always. ProRes 422 Proxy at UHD can be larger on disk than the H.264 file a mirrorless camera produced, because an intra-frame codec deliberately spends bitrate to buy independence between frames. The saving being purchased is decode cost and random access, not gigabytes. If you judge a proxy format by file size you will pick the wrong one.
"Editing on proxies lowers the quality of the export."
It cannot, if the conform happens — the proxy is thrown away and the render reads the original. A soft export means proxies were still switched on when you exported. This is a workflow mistake with a very specific fix, not a property of proxy editing.
"Proxies are for people with slow computers."
Decode cost is a property of the codec, not the machine. A workstation still software-decodes 10-bit 4:2:2 HEVC because the hardware path for it generally does not exist. And the cost scales with simultaneous streams: a four-angle multicam decodes four of those at once, every frame. Faster hardware moves the wall; it does not remove it.
"Proxy media and optimized media are the same thing."
Optimized media is a full-resolution transcode into an edit-friendly intra codec: same detail, cheaper decode, much bigger files. A proxy also shrinks the frame. The terms blur because Resolve's "Generate Optimized Media" has a resolution setting that produces either, but the distinction matters when the job is critical focus or fine detail — that is optimized media's job, not a proxy's.
"Lowering the viewer's playback resolution does the same job."
Only partly, and it depends on the source. For RAW formats, decoding at half resolution is a genuine shortcut, because debayering fewer photosites is real work avoided. For long-GOP H.264 and HEVC the decoder still has to reconstruct full frames before anything is scaled down, so you save on display and barely anything on decode — which is exactly the cost you were trying to avoid.
"A proxy can be trimmed or re-timed to save space."
Never. Duration, frame count, frame rate and timecode start must match the original exactly. A proxy that begins two seconds in, or runs at 30 instead of 29.97, produces an edit that drifts progressively further from where you put it — and the drift is invisible on the timeline you were watching.
"Proxy editing is a legacy workaround that better codecs will kill."
Camera resolution and bit depth have risen faster than decode throughput for two decades, and delivery codecs keep getting harder to decode randomly, because they are optimised for the opposite job. The offline/online split predates the phrase "proxy editing" by fifty years and has outlived every generation of hardware that was supposed to make it unnecessary.
Why a Cloud AI Editor Has No Other Option
Proxy editing is a convenience on a desktop. For an agentic editor running in the cloud it is structural — remove it and the product does not work at all. Four reasons, and they compound.
The agent iterates, and iteration is the whole workflow
A human editor renders a preview occasionally. A conversational edit is many passes: the agent makes a change, renders, judges it, revises. If every one of those previews were rendered from a UHD master, each turn would cost minutes of compute and the conversation would stop being a conversation.
The preview has to travel over consumer internet
A desktop editor's preview goes to a monitor two feet away. A browser editor's preview goes down a domestic connection. Rendering at source resolution would produce something that cannot be delivered in the time a person is willing to wait, no matter how fast the render was.
The agent looks at frames, and frames from a proxy are enough
An agent that inspects its own output is checking framing, caption collisions, where a zoom landed, whether a cut fell mid-word. Every one of those judgements survives a downscale intact. Handing it full-resolution frames would cost far more and answer the same questions.
The user's quality must not be a casualty of the agent's speed
The other half of the contract, and the one worth checking in any AI editor you are evaluating: does the export come from the file you uploaded, or from the thing the tool was previewing? Those are different products. Ask before you upload something you care about.
How This Works in Valmera
Valmera runs the proxy workflow, and does not ask you to run it. On upload the original is stored untouched, indexed once — word-level transcript, silences, shot boundaries, labeled frame tiles the agent reads — and a proxy is derived from it server-side.
- Every preview renders from the proxy. That is what makes a turn cheap enough to be part of a conversation and small enough to reach a browser.
- The final export renders from your original file at source quality, as an H.264 MP4. It never upscales — the export is your source's resolution, and the proxy never raises or lowers it.
- The edit is a decision list in float seconds, with no resolution in it, which is what makes the substitution free rather than a re-render of intent.
- Geometry is normalized, not pixel-addressed. Aim points, crop rectangles, text positions and censoring regions are read and written as fractions of the frame, so a zoom the agent aimed on a proxy frame lands on the same part of the picture in a 4K export. This is the failure mode described above, designed out rather than remembered.
- There is no toggle to forget. The proxy is never the thing that gets exported, so the classic silent proxy failure — shipping the offline — is not reachable from the interface.
The honest limits. Because none of this is exposed, none of it is adjustable: there is no proxy codec or resolution setting, no way to download the proxy, and no attach/relink step. Valmera's decision list is its own JSON, readable through the agent's get_edl tool, with no .edl, AAF or FCPXML export — so Valmera is not an offline stage that conforms into Premiere or Resolve, and the deliverable is a rendered MP4 rather than a cut list. Uploads are capped at 14 GB or 3 hours per video, which is a different scale of problem from the 500 GB of camera cards a desktop proxy workflow exists to handle. And because previews are proxies, critical focus and fine grading judgements are better made on the export than in the preview player.
Related Terms
Other entries in the Valmera video editing glossary that touch this one:
- Edit decision list (EDL) — The resolution-agnostic document that makes swapping proxies for originals a no-op.
- Color grading — The decisions most likely to be judged wrong on a proxy, because the proxy is a compressed, often 8-bit copy.
- Auto-reframe — Crop geometry that has to be stored as a fraction of the frame, or it lands four times too small at conform.
- Aspect ratio — Frame shape survives the conform; frame size does not, which is why one is expressed in ratios and the other in pixels.
- Shot detection — Analysis that runs on the proxy and returns timestamps, which are valid against the original unchanged.
- Burned-in captions vs subtitles — Burned text is rasterised at export resolution, not at preview resolution.
- Transcription and ASR — The audio path, where proxying buys nothing — speech recognition decodes sound, not picture.
Frequently Asked Questions
Edit Fast, Export From the Original
Previews render from a proxy so the conversation stays quick. The final file is rendered from your upload at source quality. 50 free credits, no card.
Start free →