Why cleaning a video means re-encoding it
A still image can often be edited and saved without loss. Video cannot, and the reason is structural rather than a limitation of any particular tool. Understanding it tells you what to expect from the output and how to avoid making it worse than it needs to be.
There are no pixels in the file
It is tempting to picture a video file as a stack of images. It is not. A compressed video stores almost nothing that resembles a pixel.
What it stores is a description of how to reconstruct each frame. Occasionally that description is self-contained: a keyframe, which encodes a whole picture much as a JPEG does. Most frames are not keyframes. They are described in terms of other frames, as a set of instructions saying which blocks moved where, plus a correction for what moving them failed to capture.
Even within a keyframe, the data is not spatial. Blocks are transformed into frequency coefficients, quantised, and entropy coded. The number stored for a given block describes how much of a particular pattern it contains, not what colour sits at any coordinate.
So there is no pixel in the file to edit. To change what a frame looks like, you have to reconstruct the frame, change it, and describe it again.
And frames depend on each other
Suppose you could edit one frame's data in place. You still could not stop there, because the frames after it are described relative to it.
A frame that says "this block is the same as the block over there in the previous frame, shifted four pixels left" inherits whatever that block became. Change the earlier frame and every later frame referencing it changes too, in ways the encoder never intended. Corrections computed against the original content are now being applied to different content, and the error compounds along the chain until the next keyframe resets it.
Some codecs also use bidirectional frames, which reference both a past and a future frame, so the dependency graph is not even a straight line.
This is why patching a watermark out of a compressed bitstream is not a matter of finding the right bytes. The corner you want to change does not exist as a location in the file, and the region it occupies is referenced by frames that come after it.
What actually happens
The only workable route is the full round trip, which is what the video tool does:
- Demux. Separate the video and audio streams from the container.
- Decode. Reconstruct each frame into actual pixels.
- Detect. Locate the mark and estimate its strength for that frame.
- Clean. Invert the blend over the mark region, or rebuild the strip for an opaque mark.
- Encode. Compress the modified frame again.
- Mux. Write the new video stream back into an MP4 alongside the original audio.
Step five is where quality is lost. Everything else is either lossless or confined to the mark region.
This is also why a clip takes roughly its own running time to process. Every frame is decoded, examined, edited and encoded on your own machine, and the tab has to stay open while it works. A ten second clip at 24 frames per second is 240 full round trips.
Generation loss, and why it is not catastrophic here
Encoding already-encoded video is generation loss. The second encoder sees the first encoder's artefacts as if they were picture detail and spends bits preserving them, while introducing its own.
The reason this is tolerable in practice is that the loss is front-loaded. The first compression, from raw frames to H.264, is where most of the information goes. A second pass at a generous bitrate costs far less than the first one did. Chaining ten of them would be visibly bad; doing one is not.
Measured on Veo footage through the browser encoder, a single clean pass lands around 42 dB PSNR against the source, which is a difference you have to look for. The measurements behind that number are in measuring what a browser re-encode costs you.
What is kept
Several things pass through the process untouched, by design.
- The audio track. Audio is copied across rather than re-encoded. There is no reason to touch it and every reason not to, since re-encoding audio is pure loss for no benefit.
- Resolution and frame rate. Both are carried over from the source. The output is not upscaled, downscaled or retimed.
- Every pixel outside the mark region. Only the corner is edited. The rest of the frame is handed to the encoder exactly as it was decoded, and any difference in it comes from the encode alone.
The bitrate is chosen to keep that encode light. The default is generous for the clips Gemini produces, and it rises to three times the source rate when the source is heavier than a third of the default, so a high-bitrate input is not quietly re-encoded below its own quality. A cap keeps long clips from ballooning.
Getting the best result
Three things are worth doing, and all of them are about what you feed in rather than what the tool does with it.
Use the original download. A clip that has already been through a platform's transcoder has lost detail and, more importantly for detection, has had the mark itself re-compressed. The removal divides by a small number near the centre of the mark, which amplifies exactly the kind of error that re-compression introduces.
Clean before editing, not after. If a clip is going into a longer edit, clean the source first. Cleaning the finished export means the mark has survived another encode, and it means re-encoding the entire edit rather than the one clip that needed it. Cuts and fades also complicate detection, because a fade changes the mark's strength frame by frame.
Do not run it twice. A cleaned clip has no mark left to find. Passing it through again is a second generation of loss in exchange for nothing, and the tool will tell you it found nothing rather than producing a file.