A video can carry a watermark in three different places, and only one of them can be removed without touching the picture. The container holds boxes like C2PA provenance, and those come off losslessly — so losslessly that the compressed video bytes are byte-for-byte identical afterwards. The pixels hold anything burned into the frames, and a visible mark can only be re-encoded around, cropped out, or painted over, all of which cost quality. The model holds an invisible signal that no file operation reaches.
The short version of what most people are actually asking: if the mark you can see is still there after you strip the metadata, that is not a bug in the stripper. You removed one layer and looked at another. Everything below is a real run of ffmpeg on this machine, reproducible with the script named further down.
The distinction is the whole answer, so it is worth putting in one table before the details. Each row below is a place a mark can physically be, not a kind of mark.
| Layer | Where it physically is | What removes it | Does the picture change? |
|---|---|---|---|
| Container | A box in the MP4 file, next to the video track | Anything that rewrites the container | No — the compressed video bytes are identical |
| Pixels | Painted into the frames you can see | Crop, cover, or re-encode around it | Yes, everywhere in the frame |
| Model | Not in the file at all | Nothing | Not applicable |
If you only remember one line, remember the third column: the container is the only layer where "removed" means the video is bit-for-bit what it was, minus a box. The same split on the image side →
Sora is the most thoroughly documented case of a video watermark, which is why it is the example here. OpenAI's Sora 2 system card lists its provenance tooling for first-party products in three parts, and it is worth quoting rather than summarising, because the three parts map exactly onto the three layers:
Its announcement pages add two sentences that matter. On the signals: "Every video generated with Sora includes both visible and invisible provenance signals." On the visible one: "Many outputs also carry visible, dynamically moving watermarks which include the name of the creator." A moving mark is the hard case, and the section below measures why.
One fact should be stated plainly rather than left out: both of those OpenAI pages carry the line "As of April 26, 2026, the Sora product is no longer available." So this is not a guide to a service you can sign up for today. It is a guide to files that are already on disk, and to the same three layers in any other generator that marks its output.
C2PA keeps its manifest in a box of its own inside the MP4 container. Amazon's MediaConvert documentation states the placement exactly: "The manifest is embedded in the MP4 file using a standard C2PA UUID box, placed after the FTYP box and before the MOOV box." A container is a list of boxes, and this is one entry in that list — which is why removing it does not involve decoding a single frame.
What is worth knowing is how easily it goes. The command people use to remux a file without re-encoding it does not preserve that box, and it does not say so:
ffmpeg -i input.mp4 -c copy output.mp4
Here is a real run on this machine. The input was a test clip with a C2PA-shaped box injected after ftyp, which is where the format puts it. The box is 153 bytes: a 32-bit size, the type uuid, the 16-byte C2PA identifier, and a small JSON payload.
input 102295 bytes boxes = ftyp free mdat uuid moov
raw "uuid" occurrences = 1 payload marker = 1
after ffmpeg -c copy 102142 bytes boxes = ftyp free mdat moov
raw "uuid" occurrences = 0 payload marker = 0
mdat (the compressed video): 100307 bytes in both, identical = True
Read the last line again, because it is the point. The box is gone, the payload string is gone, and the compressed video data is byte-for-byte the same. Nothing was re-encoded, no quality was lost, and the picture is untouched. That is what it looks like when a mark lives in the container.
Two honest notes on that output. First, the box was dropped by a plain -c copy, without any metadata flag at all — ffmpeg keeps the streams it understands and discards top-level boxes it does not, so this is a side effect rather than a feature you asked for. It cuts both ways: it is the fastest way to shed the metadata, and it is also how provenance disappears from a file somebody meant to keep it on. Second, -map_metadata -1 removes the ordinary tags as well — title, artist, comment — and leaves the same byte-identical video behind, so if you want the tags gone too, that is the flag.
If you would rather not rely on a side effect, the box can be cut out of the container directly. That is what the second half of the script below does: it walks the top-level boxes, removes the one whose type is uuid and whose identifier matches C2PA, and copies every other byte through untouched. The result is the same file size arithmetic — 102,295 to 102,142 bytes, exactly the 153 bytes of the box — with the same identical mdat.
There is one caveat, and it decides whether cutting the box out by hand is safe at all: it depends on where the box sits. In this clip the box is after mdat — ftyp free mdat uuid moov — so deleting it moves no sample and the file still plays. The placement C2PA documents is the other one, after ftyp and before moov, which in a file not written for streaming puts it before mdat. Delete bytes there and every sample shifts while the chunk-offset table inside moov keeps its old numbers: the container still parses and the decoder reads the wrong bytes. Measured on a clip built that way, 0 of 72 frames decode; the same insertion with the offset table corrected decodes 72 of 72. The video metadata page walks through that measurement and what it means for each removal method.
A visible watermark is not stored anywhere. It is the picture. So the question is never "how do I delete it" but "how much am I willing to damage to hide it", and there are exactly three answers: cover it, crop it, or re-encode around it.
ffmpeg has a filter for the cover case, delogo, and it is worth being precise about what it does: it takes a rectangle and interpolates the contents from the pixels surrounding that rectangle. It does not know what was underneath the mark and it does not restore it. Measured on this machine, against a clean render of the same clip with no mark at all:
marked input vs clean PSNR 23.55 dB delogo output vs clean PSNR 33.63 dB delogo + re-encode 102142 -> 93318 bytes
33.63 dB is a better picture than 23.55 dB, which is what delogo is for, but it is nowhere near a restoration — a lossless edit would be the same bytes, and these are not. The mark's rectangle is now an interpolated patch, and the re-encode that the filter requires is paid on every pixel in the frame, not only the ones under the mark.
The crop route is more honest about its cost. Taking the bottom 36 rows off the same clip removed the mark and changed the file from 320x240 to 320x204, at 87,617 bytes. Every frame lost part of its picture and the resolution is no longer what the camera or the generator produced. If the mark sits in a strip you were going to cut anyway, that is a clean trade. If it does not, you have swapped a mark for a worse frame.
Neither of these is available from this site's tool, and it is worth saying so plainly: the cleaner here handles text and still images, not video files. The commands above are ffmpeg's, and the script below is the thing you can run to check your own file.
OpenAI's own wording is "visible, dynamically moving watermarks", and the word moving is the whole difficulty. delogo takes a fixed rectangle, which is the right tool for a station logo that sits in one corner for the entire clip. A mark that travels is only inside any given rectangle for part of the clip.
To measure that rather than assert it, the test uses a clip on a black background with a white mark travelling across it, so the only bright thing in any frame is the mark itself. Then it counts the frames where the mark is still on screen:
nothing burned in 0 / 72 frames mark travelling 72 / 72 frames mark travelling, after delogo 63 / 72 frames
63 of 72. A delogo box placed over where the mark starts covers it while the mark is there and misses it for the rest of the clip — and the nine frames it does handle are exactly the ones where the mark had not moved out yet. This is not a setting that was got wrong. A fixed rectangle cannot follow a moving target, which is the design reason a moving watermark exists.
Following it frame by frame is possible in principle — track the mark, and interpolate a different region in each frame — and that is a video-editing job rather than a command. It also still requires a full re-encode, so it still costs quality across the frame. There is no version of this that returns the original picture.
The script behind every number on this page is one Python file using ffmpeg and the standard library, and it builds its own test clips rather than shipping binaries. Run it and it prints the report quoted above, on your machine:
python dev/video_watermark_test.py
To check a file you already have, the useful question is which layer you are looking at. If you want to know whether there is a C2PA box, look at the container's top-level boxes — a uuid box sitting between ftyp and moov is the provenance record, and it is either there or it is not. If the mark is visible on the frames, you already know which layer that is, and no metadata tool will reach it.
If you would rather not run Python, the browser tool does the same box walk on a file you drop in, with nothing uploaded and no re-encode — it lists what it found, and what it deliberately left alone, before it changes anything.
This page cannot tell you whether a video was generated by any particular model. The detection tooling OpenAI describes is internal, and there is no public checker for a video watermark that we know of. It cannot remove a mark from the pixels of your clip — nothing can, in the sense of restoring the original frames — and it cannot reach an invisible signal that is spread across the picture rather than stored in a field. What it can do is tell you which of the three layers you are looking at, and remove the one that genuinely comes off without cost.
Quotations on this page are from OpenAI's Sora 2 system card and announcement pages and from Amazon's MediaConvert documentation. The command output is a real run on this machine, reproducible with the script named above. The container layer in still images →
Half of it, and only half. OpenAI's Sora 2 material describes two signals on the same file: a visible, dynamically moving watermark on videos downloaded from sora.com or the Sora app, and C2PA metadata on every asset. The metadata is a box in the container and comes off without touching the picture. The visible mark is in the pixels, so nothing removes it without re-encoding the video around it. OpenAI's own pages also state that the Sora product is no longer available as of April 26, 2026, so this is mostly a question about files already on disk.
No, and the two are not close. Metadata is a box in the file's container; a visible watermark is paint on the frames. Removing the box leaves every frame exactly as it was, which is easy to prove: strip the container of a test file and the compressed video bytes are byte-for-byte identical afterwards. Anyone offering to remove a burned-in logo by cleaning metadata is describing a different layer from the one you can see.
Yes, and it does it without being asked. A plain ffmpeg -c copy of a file carrying a top-level uuid box produces an output with the box gone and the compressed video bytes unchanged, because ffmpeg keeps the streams it knows and drops the top-level boxes it does not. One precision on the test behind that sentence: the fixture on this page is a C2PA-shaped box rather than a signed manifest, because signing one needs a certificate we do not hold. The mechanism does not depend on what is inside the box — an unknown top-level box is skipped whole, never parsed — so the same thing happens to a signed one. It is worth knowing in both directions: the fastest way to shed the metadata, and how a provenance record disappears from a file someone meant to preserve.
Because delogo covers a fixed rectangle. It was built for a station logo that sits in one corner for the whole clip, and it repairs that rectangle by interpolating from the pixels around it. A mark that travels is only inside any given rectangle for part of the clip. In a measured test on this machine a travelling mark was still on screen in 63 of 72 frames after a delogo box was placed over its starting position, and the nine frames it did cover were the ones where the mark happened to be there.
It works, and you pay for it in framing. Cropping the bottom strip off a test clip removed the mark and changed the file from 320x240 to 320x204, so every frame lost 36 rows of picture and the resolution no longer matches what the camera or the generator produced. It also requires a re-encode. If the mark is in a corner you were going to crop anyway, it is the cleanest option available; if not, you are trading a mark for a worse frame.
Not by working on the file, because an invisible pixel-domain watermark is spread across the picture rather than stored in a field you can delete. OpenAI describes Sora videos as carrying both visible and invisible provenance signals, and describes its reverse-search tooling as internal. There is no public field to clear and no public checker to confirm the result, so any tool claiming to remove that layer is either describing the container layer or guessing.
Re-encoding changes the pixels, so it can destroy a fragile mark and it certainly destroys the metadata, but it does not remove a mark that is painted into the frames. A re-encode of a clip with a burned-in logo still shows the logo; it just shows it through a second generation of compression. Re-encoding is the price of any pixel-level repair, not a repair by itself, and it costs quality everywhere in the frame rather than only where the mark was.
No — the verb does not change the file. Both words point at the same three layers, and the answer is the same for either: the container layer comes off losslessly, and the pixel layer does not come off without a re-encode. The only real difference is the phrase you type into a search box. So if you are looking for how to delete a watermark from a video, the layer test is still the first thing to run, because it tells you whether your problem is a box in the container or paint on the frames — and those two have nothing in common except the word watermark.
There is no single best one, because the honest answer depends on which layer your mark is in and no tool covers all three. For the container layer, anything that rewrites the container works — including a plain ffmpeg -c copy, which drops a C2PA box while leaving the compressed video byte-identical. For a visible mark, every tool in this category is doing one of three things: interpolating over a fixed rectangle, cropping the edge off, or re-encoding the whole frame. All three change the picture, and all three are defeated by a mark that moves — measured here at 63 of 72 frames still showing the mark after a delogo box was placed over it. This site does not offer a video tool; the cleaner here handles text and still images. What it can do is tell you which layer you are looking at, which is the part that decides whether any tool can help at all.