How the Veo watermark is positioned in video
Video does not get the same treatment as images. There is no catalogue of official frame sizes to look the layout up in, so the mark is located by projecting a small set of known reference layouts onto whatever frame size arrives, then checking which one is actually there.
Why video needs a different approach
For images, dimensions identify the generation tier and the tier gives you the layout exactly. That works because Gemini emits a discrete set of image sizes and those sizes are known.
Video arrives in a much wider range of shapes. Clips get exported at different resolutions, downloaded through different paths, transcoded by whatever handled them along the way, and cropped to portrait for one platform or square for another. Treating frame size as a reliable key to a lookup table would fail constantly.
So the video detector works the other way round. It holds a small number of reference layouts, defined at one canonical frame size, and projects them onto the frame it has. Projection produces candidates. Evidence decides between them.
The reference layouts
The canonical frame is 1920 by 1080. Two layouts are defined there:
| Layout | Logo size | Margin | Mark position |
|---|---|---|---|
| 1080p standard | 72 px | 108 px | 1740, 900 |
| 1080p inset | 72 px | 144 px | 1704, 864 |
Same logo, two different insets. As with images, the mark is anchored to the bottom right corner, so the position follows from the frame size and the margin:
x = width − marginRight − logoSize
y = height − marginBottom − logoSize
Projecting onto another frame size
Unlike the image marks, the video mark does scale with the frame. A clip at half the reference height carries a mark at roughly half the reference size, at roughly half the inset. So each reference layout is scaled by the ratio between the frame and the reference, and the results are rounded to whole pixels and clamped so the mark cannot be smaller than 24 pixels or larger than the frame.
Take 1280 by 720, the most common non-reference size. The scale factor is 720 divided by 1080, which is two thirds. Applied to both reference layouts:
| Projected from | Logo size | Margin | Mark position |
|---|---|---|---|
| 1080p inset | 48 px | 96 px | 1136, 576 |
| 1080p standard | 48 px | 72 px | 1160, 600 |
Both layouts are recorded explicitly for this size rather than only being derived, which does two things. It confirms the projected geometry against clips that were actually measured, and it pins the order the candidates are tried in. At 720p the inset layout is searched first, because that is the one that turns up more often.
Portrait exports follow the same arithmetic from the short edge. A 720 by 1280 clip carries a 48 pixel mark at a 96 pixel margin, which puts it at 576, 1136. That is the inset layout, mirrored into portrait.
Candidates that fall off the frame
Projection can produce a position that does not fit. A very wide or very short frame, scaled from a reference that assumed 16:9, can put the predicted mark partly outside the picture. Every candidate is bounds checked before it goes any further:
x ≥ 0 and y ≥ 0 and x + size ≤ width and y + size ≤ height
Candidates that fail are dropped rather than clamped into the frame, because a mark that has been slid sideways to fit is no longer at a position the encoder would have used. If every candidate fails, the clip is reported as having no recognisable mark.
Duplicates are also removed. Two reference layouts can project onto the same pixels at some frame sizes, and there is no sense in evaluating the same region twice under two names.
Confirming against the frames
Candidates are a shortlist, not an answer. Each one is checked against actual frame content: the region is sampled, the removal is tried, and the result is scored against the pixels around it.
For calibration, a clip that genuinely carries the mark scores around 0.87 at the correct position. A clip whose mark has already been removed peaks around 0.3 at every candidate position, which is the level of correlation you get from ordinary picture content that happens to be roughly logo shaped. The gap between those two numbers is what makes a confident decision possible.
That second number matters as much as the first. A detector tuned only against clips that do have a watermark will happily find one in clips that do not. Validating against an already-clean clip is what keeps the tool from re-encoding a video for no reason and reporting success.
Strength changes over the clip
One more thing separates video from images. In a still, the mark is applied at one strength and that is the end of it. In video the strength varies frame to frame, most obviously when a clip fades in from black or out to it.
During a fade, the composited mark fades with the picture. Treating those frames as full strength subtracts more than was ever added, and the visible result is a dark blob sitting in the corner for the first second of the clip. The fix is to estimate the strength per frame rather than once for the clip.
The awkward part is that a frame where the mark is genuinely faint and a frame where the mark is absent look similar to a naive test, and so does a frame where a bright branch or a pale rock happens to sit under the mark region. Getting this right means tracking the strength across the clip rather than judging each frame in isolation, so that a frame during a fade is understood as part of a fade.
The other video mark
Everything above concerns the sparkle, which is composited and therefore invertible. Veo output also appears with a text mark, and NotebookLM exports carry a wordmark that works on entirely different principles: opaque rather than blended, and not drawn on every frame. That one is covered in the NotebookLM wordmark is a different problem.