Does video watermark repair preserve transparency in a WebM?

First verify the input, then measure the actual output

On 3 November 2026 we made a two-second VP9 WebM at 480 × 270 pixels and 24 source frames per second. It has 48 source frames, transparent surrounding space, an opaque green patch, a partly transparent green patch, a moving gold circle, and an opaque lower strip with DEMO and a frame counter. There is no audio by design. A white-flattened control uses the same artwork; an unmarked reference is generated separately from the owned recipe, not recovered by the remover.

The marked source measured 29,370 bytes. With the explicit libvpx-vp9 decoder, its first frame contained 65,294 fully transparent pixels, 13,231 partly transparent pixels and 51,075 opaque pixels. These sum to 129,600, or 480 × 270. The partly transparent patch at X 350, Y 80 had alpha 129. Our independent browser file probe then loaded the same local file, drew its ready first frame to a fresh canvas and obtained the same alpha counts and probe value. White and purple display backings showed through the surrounding space and the partly transparent patch.

That input check mattered. The default decode path in this installed FFmpeg build produced a fully opaque RGBA frame from the exact same transparent-source bytes. Explicit libvpx-vp9 exposed the alpha; merely asking for RGBA output did not. The white-flattened control, 28,510 bytes, stayed opaque under both paths. Those are input-decoding observations, not repaired results or a claim about every decoder version.

We selected the marked source in the unchanged production video tool. After its default preview appeared, we entered Zone 1 X 178, Y 184, width 94 and height 34, active from zero to two source seconds; Zone 2 stayed disabled. The final box covered DEMO on the opaque lower strip, away from the green patches. We changed the fields in X, Y, width, height order and then exported and downloaded. These settings and that preview sequence describe this run, not a universal preset.

The saved WebM measured 29,801 bytes. Its first decoded frame had 58,375 fully transparent pixels, 18,839 partly transparent pixels and 52,386 opaque pixels. At the same X 350, Y 80 probe, alpha was now 248. A separate browser probe of the downloaded file agreed on that alpha value and those counts. At saved playback time one second, the visible source counter read FRAME 026; the matching source frame still had a see-through patch, but the output probe was fully opaque at alpha 255.

DEMO was absent in the inspected output frames. However, there were also two black rectangular areas near the top of the saved image, outside the final lower-strip repair box. The moving circle left an extra visible trail in the later sample. We kept these defects in the comparison. We did not isolate their cause or change the tool to manufacture a cleaner result. The earlier preview positions are part of the recorded workflow, so this run must not be presented as an isolated codec experiment.

The source, control, reference and downloaded result passed complete decoding. The output's two inspected samples retained 480 × 270 dimensions. Its decoded audio stream contained 74,880 mono samples at 48,000 per second, or 1.56 seconds, all zero. That is a silent recorded stream, not recovered sound. The browser played the saved file to its 1.939-second end. Do not describe this as an exact two-second timing copy or as preservation of an original soundtrack.

Download the actual marked source, opaque-white control, generated unmarked reference and retained browser-export failure. The input measurements and hashes, output readings and rectangle, and browser input probe / output probe distinguish generation, decoding and actual browser editing. The alpha counts concern inspected frames, not an all-frame success rate.