Add video metadata and visible watermark removal

docs/cli.md

@@ -125,6 +125,60 @@ The command also supports the audio and video containers listed in
 [supported signals](supported-signals.md). ffmpeg must be available for the
 non-ISOBMFF audio and video path.
 
+## Strip AI metadata from video
+
+The experimental video namespace starts with metadata inspection and removal:
+
+```bash
+remove-ai-watermarks video metadata input.mp4 --check
+remove-ai-watermarks video metadata input.mp4 --remove -o clean.mp4
+```
+
+Supported containers are MP4, MOV, M4V, WebM, and MKV. The operation delegates
+to the same verified metadata scanner and stripper as the generic `metadata`
+command, so detection and removal stay in parity. Video and audio streams are
+not transcoded. For MP4 and MOV, this includes the native TC260 `AIGC` key and
+JSON value stored in `moov.udta.meta.keys/ilst`. The inspector seeks past a
+large `mdat` to find a tail `moov`; removal blanks the key and value in place so
+box sizes and media offsets do not move.
+
+For MKV and WebM, the inspector reads the native TC260
+`Segment.Tags.Tag.SimpleTag` entry. Removal uses ffmpeg stream copying to
+discard container tags and chapters without transcoding the streams.
+
+When `-o` is omitted, the command writes `<source>_clean` with the same
+extension. It never overwrites the source, and it rejects an output with a
+different container extension.
+
+Visible video labels and invisible video watermarks are not handled by this
+command.
+
+## Remove a visible Sora or Veo video mark
+
+```bash
+remove-ai-watermarks video visible input.mp4 -o clean.mp4
+remove-ai-watermarks video visible veo.mp4 --mark veo -o veo_clean.mp4
+```
+
+The experimental command supports the moving Sora mascot and wordmark plus two
+Veo corner variants: the current four-point diamond and the legacy `Veo` text.
+Sora searches the whole frame at multiple scales. Veo searches the
+bottom-right corner using separate synthetic silhouettes for the two variants.
+Both require a spatially recurring candidate across adjacent frames. Matching
+provider provenance may relax the visual score, but metadata alone never
+creates a detection. Clean API exports therefore remain untouched.
+
+The video stream is transcoded and the original audio stream is copied.
+Supported input and output containers are MP4, MOV, M4V, WebM, and MKV; the
+output extension must match the input. The default `cv2` backend is fast but can
+smear structured backgrounds. Select `--backend migan` or `--backend lama` for
+a learned fill, or `--backend auto` to choose the best installed backend.
+
+AI metadata is stripped from the encoded output by default. Use
+`--keep-metadata` to retain mapped container metadata. When no temporally stable
+mark is found, the command writes no output and exits with the no-visible-mark
+status.
+
 ## Remove invisible watermarks
 
 Install the diffusion dependencies first:

docs/index.md

@@ -8,7 +8,7 @@ to run the tool. Use the maintainer references only when changing the code.
 | Page | Use it when |
 | --- | --- |
 | [Installation](installation.md) | You need the CLI, an optional model backend, or a development environment. |
-| [CLI guide](cli.md) | You want a command for one image, a directory, or a specific watermark type. |
+| [CLI guide](cli.md) | You want a command for an image, video metadata or visible marks, a directory, or a specific watermark type. |
 | [Python API](python-api.md) | You want to call the package from Python. |
 | [Supported signals](supported-signals.md) | You need to know which visible marks, metadata formats, and invisible signals are covered. |
 | [Known limitations](known-limitations.md) | You need the quality, device, format, or verification boundaries. |

docs/known-limitations.md

@@ -174,6 +174,40 @@ WebM, Matroska, MP3, WAV, FLAC, OGG, Opus, and AAC container metadata is strippe
 through ffmpeg with stream copying. The operation fails if ffmpeg is absent or
 cannot parse the input.
 
+### Visible video removal supports Sora and Veo and is still experimental
+
+The experimental `video metadata` command and high level video API inspect and
+strip supported AI provenance metadata without transcoding streams.
+
+`video visible` and `remove_video_visible` additionally support the moving
+Sora 2 mascot and wordmark, the current Veo four-point diamond, and the legacy
+`Veo` text. Detection requires a recurring visual candidate across adjacent
+frames. Provider provenance can recover low-contrast runs only after visual
+evidence exists, so metadata alone does not erase a clean API export.
+Historical Sora Turbo exports use a small OpenAI swirl in the corner rather
+than the moving mascot-and-wordmark design; that earlier variant is not
+detected by the `sora` video mark. Other provider video labels and proprietary
+invisible video watermarks are not supported yet.
+
+Visible removal transcodes the video stream and copies audio. Its frame-local
+fill is not a motion-aware video inpainting model. OpenCV can leave a visible
+smear where the mark overlaps a hard edge or structured texture, and the smear
+can vary over time. MI-GAN and LaMa improve individual frames but do not
+guarantee temporal coherence. The Veo diamond uses a shape mask to limit damage
+outside the symbol, but OpenCV may still soften texture inside it. The current
+encoder also emits a constant-frame-rate output at the decoded stream rate, so
+variable-frame-rate preservation is not yet guaranteed.
+
+Native TC260 metadata in MP4/MOV is supported at its normative
+`moov.udta.meta.keys/ilst` placement, including non-faststart files whose
+`moov` follows a large media payload. MKV/WebM is supported at the normative
+`Segment.Tags.Tag.SimpleTag` placement and uses ffmpeg for stream-copy removal.
+The corresponding FLV and AVI native tags are not parsed yet.
+
+The current ISOBMFF stripper reads an MP4, MOV, or M4V container into memory
+before rewriting its metadata boxes. A streaming box copier is required before
+the experimental command is appropriate for very large video files.
+
 ### Metadata transformation is fail safe
 
 `remove_ai_metadata` may copy an undecodable file through unchanged instead of

docs/module-internals.md

@@ -86,6 +86,70 @@ Regression coverage:
 - [`test_api.py`](../tests/test_api.py)
 - [`test_image_io.py`](../tests/test_image_io.py)
 
+[`video.py`](../src/remove_ai_watermarks/video.py) provides the experimental
+video entry point:
+
+- `inspect_video_metadata`
+- `remove_video_metadata`
+- `remove_video_visible`
+
+The video API validates both the supported extension and container signature,
+then delegates all metadata detection and stripping to `metadata.py`. It
+requires a separate same-container output, defaulting to `<source>_clean`, so
+the experimental path does not overwrite an original. The package root exposes
+both functions lazily.
+
+Native MP4/MOV TC260 labels follow TC260-PG-20257A:
+`moov.udta.meta.keys` maps an `AIGC` key to a raw JSON value in `ilst`.
+[`noai/isobmff.py`](../src/remove_ai_watermarks/noai/isobmff.py) walks those
+nested boxes by seeking, so detection reaches a tail `moov` without reading the
+preceding `mdat`. Removal changes the four-byte key to `free` and blanks only
+the validated JSON value with same-length spaces. This preserves every box
+size, `stco`/`co64` offset, and encoded stream byte. A generic `AIGC` key whose
+value has no TC260 field is ignored.
+
+[`noai/ebml.py`](../src/remove_ai_watermarks/noai/ebml.py) provides the
+corresponding bounded Matroska/WebM reader. It seeks over clusters and accepts
+only a `Segment.Tags.Tag.SimpleTag` pairing `TagName=AIGC` with a JSON
+`TagString` carrying a TC260 field. The existing ffmpeg stream-copy path removes
+those container tags without transcoding the encoded streams.
+
+[`video_visible.py`](../src/remove_ai_watermarks/video_visible.py) implements
+the first pixel stages for Sora and Veo. The Sora detector searches a normalized
+frame with a fully synthetic mascot-and-text silhouette at several scales. The
+Veo detector uses separate synthetic silhouettes for the current four-point
+diamond and legacy `Veo` text, with bounded bottom-right searches calibrated
+independently from Sora. A strong relocated-diamond match may bypass the known
+layout anchors, but weak free-corner matches never enter the temporal arbiter.
+This prevents recurring scene details in clean API exports from being promoted
+to a watermark.
+
+Every per-frame result is untrusted. The provider-specific stabilization
+wrappers share one recurrence implementation, while retaining separate visual
+floors and minimum-run policy. Provenance can relax a low-contrast run only
+after recurring visual evidence exists. Sora transition frames follow the
+nearest confirmed moving position only with Sora provenance. A confirmed Veo
+run can cover low-contrast frames at its fixed position. This separation keeps
+clean API exports from being modified merely because metadata names the same
+generator.
+
+Removal runs in a second decode pass. Sora and legacy Veo text use padded box
+masks. The square Veo diamond uses a synthetic shape mask so transparent box
+corners do not erase unrelated pixels. Every mask goes through the shared
+`watermark_registry.fill` backends. ffmpeg encodes the changed video stream and
+copies optional audio. The default OpenCV fill is the speed floor; structured
+backgrounds need MI-GAN or LaMa for better reconstruction. Invisible video
+stages must continue to reuse the image and metadata implementations rather
+than copying their logic.
+
+The inherited ISOBMFF metadata path currently reads the complete container into
+memory; replacing that with a streaming box copier is a prerequisite for large
+video inputs.
+
+Regression coverage:
+
+- [`test_video.py`](../tests/test_video.py)
+
 ## Metadata and provenance
 
 ### C2PA
@@ -110,6 +174,10 @@ Key contracts:
   scan.
 - ISOBMFF containers use
   [`noai/isobmff.py`](../src/remove_ai_watermarks/noai/isobmff.py).
+- Native MP4/MOV TC260 `AIGC` entries are read from
+  `moov.udta.meta.keys/ilst` and blanked without changing box sizes.
+- Native MKV/WebM TC260 `AIGC` entries are read from
+  `Segment.Tags.Tag.SimpleTag` and removed through the ffmpeg stream-copy path.
 - Supported non-ISOBMFF audio and video containers use ffmpeg stream copying.
 - The low-level remover is fail-safe and can copy an undecodable file through
   unchanged.

docs/python-api.md

@@ -128,6 +128,65 @@ path preserves the pixels but drops standard metadata. Treat a nonempty
 undecodable input through unchanged, so its return alone must not be presented
 as proof that metadata was removed.
 
+## Inspect and strip video metadata
+
+The experimental high level video API supports MP4, MOV, M4V, WebM, and MKV:
+
+```python
+import remove_ai_watermarks as raiw
+
+report = raiw.inspect_video_metadata("input.mp4")
+if report.has_ai_metadata:
+    result = raiw.remove_video_metadata("input.mp4")
+    if result.remaining:
+        raise RuntimeError(f"AI metadata remains: {result.remaining}")
+```
+
+`remove_video_metadata` does not transcode video or audio streams. Its default
+output is `input_clean.mp4`, leaving the source untouched. An explicit output
+must use the same container extension as the source.
+
+The returned `VideoMetadataResult` records the source, output, metadata detected
+before removal, and any markers remaining after the verified strip. MP4/MOV
+inspection recognizes the native TC260 `AIGC` entry in
+`moov.udta.meta.keys/ilst`; its removal preserves container size and encoded
+stream bytes. MKV/WebM inspection recognizes the corresponding
+`Segment.Tags.Tag.SimpleTag` representation; its removal requires ffmpeg for a
+stream-copy remux.
+
+## Remove a visible Sora or Veo video mark
+
+```python
+import remove_ai_watermarks as raiw
+
+result = raiw.remove_video_visible(
+    "sora.mp4",
+    "sora_clean.mp4",
+    backend="cv2",
+    strip_metadata=True,
+)
+if result.output is None:
+    print("No temporally stable Sora mark was found")
+
+veo_result = raiw.remove_video_visible(
+    "veo.mp4",
+    "veo_clean.mp4",
+    mark="veo",
+)
+```
+
+`remove_video_visible` scans the complete video before writing output. It
+combines synthetic multi-scale visual matching with temporal consistency, so an
+isolated lookalike in one frame is not enough to authorize inpainting. The
+supported `mark` values are `sora` and `veo`. The Veo detector recognizes the
+current four-point diamond and the legacy `Veo` text with separate synthetic
+silhouettes.
+
+The returned `VideoVisibleResult` records the total, detected, and removed frame
+counts plus any AI metadata that survived the output encode. The function
+returns `output=None` and writes no file when no stable mark is selected. Video
+pixels are transcoded through ffmpeg while the source audio stream is copied.
+
 ## Remove invisible watermarks
 
 ```python

docs/supported-signals.md

@@ -29,6 +29,16 @@ the masked area.
 Marks from other vendors are not detected automatically. Use `erase --region`
 when you can select the affected area yourself.
 
+### Visible video marks
+
+| Key | Mark | Motion | Important limit |
+| --- | --- | --- | --- |
+| `sora` | Sora 2 mascot and wordmark | Moves among frame positions | Requires a temporally recurring visual match; the older Sora Turbo corner swirl is a different unsupported mark. |
+| `veo` | Current four-point diamond and legacy `Veo` text | Fixed bottom-right corner | Uses separate silhouettes and requires a recurring match; learned fill is preferable on structured backgrounds. |
+
+Use `video visible` for this registry. It is separate from the image `visible`
+command because selection is made over a sequence rather than one raster.
+
 ## Fill backends
 
 | Backend | Install | Behavior |
@@ -48,7 +58,9 @@ The inspection and stripping code handles signals in these groups:
 - EXIF and XMP generator fields;
 - IPTC AI disclosure fields;
 - PNG text chunks and embedded generation parameters;
-- China TC260 AIGC labels in supported metadata placements;
+- China TC260 AIGC labels in supported image placements and the normative
+  MP4/MOV `moov.udta.meta.keys/ilst` and MKV/WebM
+  `Segment.Tags.Tag.SimpleTag` placements;
 - xAI and Grok EXIF signature fields;
 - Samsung AI editing markers;
 - Hugging Face job metadata;

docs/watermarking-landscape.md

@@ -38,7 +38,13 @@ pair. On the ISOBMFF path, `blank_ai_exif_tokens` provides the corresponding
 in-place scrub for supported EXIF values, TC260 AIGC blocks, and the xAI pair.
 - **China TC260 AIGC label (caught by `AIGC_MARKERS` / `metadata.aigc_label`, surfaced by `identify` as the `aigc` signal):** China-served generators embed an XMP `<TC260:AIGC>{"Label":"1","ContentProducer":...}` block — China's mandatory AI-content labeling (TC260 namespace `tc260.org.cn/ns/AIGC`).
 
-**Doubao** (ByteDance) uses it (verified on a public issue sample; `ContentProducer` `001191110102MACQD9K64010000`, no C2PA/SynthID/imwatermark — the XMP block is the only signal; GitHub attachment upload did NOT strip it). The same standard is mandatory for Jimeng/Kling/Qwen/Ernie etc., so the one marker covers the whole China-AIGC-labeled ecosystem. `aigc_label` reads **four serializations** through a shared `_parse` helper: the HTML-entity-encoded XMP `TC260:AIGC` block in **either RDF form** — the nested element `<TC260:AIGC>{...}</TC260:AIGC>` (Doubao) or the attribute `TC260:AIGC="{...}"` (**PicWish**, `ContentProducer="picwish"`, verified on compatible samples) — via a container-agnostic raw-byte scan (any JSON object accepted), a raw-JSON PNG `AIGC` tEXt chunk (Doubao also writes the label this way, no namespaced marker at all — confirmed on compatible samples, `ContentProducer="doubao"`), a bare raw-JSON `{"AIGC":{...}}` object embedded in **JPEG EXIF (UserComment)** by some China-served generators, brace-matched from the scan head with `json.JSONDecoder().raw_decode` (no namespaced marker, no PNG chunk — confirmed on compatible samples, `ContentProducer="001191440300708461136T1308L"`), **and** a bare `AIGC{...}` blob (the label glued straight to its JSON, no `"AIGC":` key wrapper) embedded in a **JPEG APP segment near the JFIF header** — confirmed on compatible samples. The two raw-JSON forms are scanned in one loop (`'"AIGC"'` then `AIGC{`) that **falls through on a non-TC260 / undecodable hit instead of returning** — a quoted `"AIGC"` can appear later in an XMP packet while the real label is a bare `AIGC{...}` earlier in the file, so an unconditional early return on the quoted form would shadow the bare form (the exact bug behind the 06-10 misses). All three generic forms (the PNG chunk, the bare `{"AIGC":...}` object, and the bare `AIGC{...}` blob) are gated on at least one TC260 field (`_TC260_FIELDS`) so a generic `AIGC` key cannot false-positive; the namespaced XMP element is unambiguous and needs no gate. `_TC260_FIELDS` covers **two schemas**: the producer-side one (`Label` / `ContentProducer` / `ProduceID` / `ContentPropagator` / `PropagateID`, Doubao and most China gens) and the **service-provider** one (`ServiceProvider` / `ServiceUser`, plus generic `Time` / `ContentId` which are NOT gated on) — **Tencent Cloud's** AIGC variant (`ServiceProvider` = `腾讯云`), embedded in **EXIF `ImageDescription`**, verified on compatible samples. In `identify`, `aigc` fires on the parsed label **or** the `AIGC_MARKERS` byte scan (the latter preserves the laundering-tell case where the JSON payload is truncated).
+**Doubao** (ByteDance) uses it (verified on a public issue sample; `ContentProducer` `001191110102MACQD9K64010000`, no C2PA/SynthID/imwatermark — the XMP block is the only signal; GitHub attachment upload did NOT strip it). The same standard is mandatory for Jimeng/Kling/Qwen/Ernie etc., so the one marker covers the whole China-AIGC-labeled ecosystem. `aigc_label` reads **four image serializations** through a shared `_parse` helper: the HTML-entity-encoded XMP `TC260:AIGC` block in **either RDF form** — the nested element `<TC260:AIGC>{...}</TC260:AIGC>` (Doubao) or the attribute `TC260:AIGC="{...}"` (**PicWish**, `ContentProducer="picwish"`, verified on compatible samples) — via a container-agnostic raw-byte scan (any JSON object accepted), a raw-JSON PNG `AIGC` tEXt chunk (Doubao also writes the label this way, no namespaced marker at all — confirmed on compatible samples, `ContentProducer="doubao"`), a bare raw-JSON `{"AIGC":{...}}` object embedded in **JPEG EXIF (UserComment)** by some China-served generators, brace-matched from the scan head with `json.JSONDecoder().raw_decode` (no namespaced marker, no PNG chunk — confirmed on compatible samples, `ContentProducer="001191440300708461136T1308L"`), **and** a bare `AIGC{...}` blob (the label glued straight to its JSON, no `"AIGC":` key wrapper) embedded in a **JPEG APP segment near the JFIF header** — confirmed on compatible samples. The two raw-JSON forms are scanned in one loop (`'"AIGC"'` then `AIGC{`) that **falls through on a non-TC260 / undecodable hit instead of returning** — a quoted `"AIGC"` can appear later in an XMP packet while the real label is a bare `AIGC{...}` earlier in the file, so an unconditional early return on the quoted form would shadow the bare form (the exact bug behind the 06-10 misses). Native MP4/MOV is a fifth serialization: TC260-PG-20257A stores an `AIGC` key in `moov.udta.meta.keys` and the raw JSON in the matching `ilst` item. The seeking parser reaches a tail `moov` without reading `mdat`; removal replaces the key with `free` and blanks the validated value at the same length so every box size and stream offset stays fixed. All generic forms are gated on at least one TC260 field (`TC260_AIGC_FIELDS`) so a generic `AIGC` key cannot false-positive; the namespaced XMP element is unambiguous and needs no gate. `TC260_AIGC_FIELDS` covers **two schemas**: the producer-side one (`Label` / `ContentProducer` / `ProduceID` / `ContentPropagator` / `PropagateID`, Doubao and most China gens) and the **service-provider** one (`ServiceProvider` / `ServiceUser`, plus generic `Time` / `ContentId` which are NOT gated on) — **Tencent Cloud's** AIGC variant (`ServiceProvider` = `腾讯云`), embedded in **EXIF `ImageDescription`**, verified on compatible samples. In `identify`, `aigc` fires on the parsed label **or** the `AIGC_MARKERS` byte scan (the latter preserves the laundering-tell case where the JSON payload is truncated).
+
+Native MKV/WebM is a sixth serialization. TC260-PG-20257A stores
+`TagName=AIGC` and the raw JSON `TagString` in
+`Segment.Tags.Tag.SimpleTag`. The bounded EBML reader skips cluster payloads;
+the existing ffmpeg stream-copy path removes the tags without transcoding.
+
 - **HuggingFace-hosted job (caught by `metadata.huggingface_job`, surfaced by `identify` as the `hf_job` signal, MEDIUM confidence):** HuggingFace Jobs / Spaces can stamp generated PNGs with an `hf-job-id` tEXt chunk holding the job UUID. It marks the *hosting job*, not a model, so it lifts an Unknown verdict to a tentative AI via `hf_only` but never overrides a hard metadata signal. `_HF_JOB_CAVEAT` states the limit. Removal drops the chunk through the PNG metadata whitelist.
 - **No detectable signal on some downloads:** Recraft exports and some hosted
   FLUX surfaces can arrive without a supported local signal. Midjourney samples
@@ -49,13 +55,18 @@ in-place scrub for supported EXIF values, TC260 AIGC blocks, and the xAI pair.
 - **C2PA 2.4 "Durable Content Credentials" (April 2026; verified against the spec) raise the bar for metadata stripping.** 2.4 defines soft bindings (an invisible watermark or a content fingerprint) plus a server-side manifest repository and a new `c2pa.repository-receipt` assertion. Per the spec: "if a C2PA manifest is removed from an asset, but a copy of that manifest remains in a provenance store elsewhere, the manifest and asset may be matched using available soft bindings." So our local `metadata --remove` deletes the *embedded* manifest, but a fingerprint/watermark soft binding can still re-link the image to its manifest in a repository server-side. Stripping the file is becoming necessary-but-not-sufficient against durable provenance. (Our parsers target the stable embedded-manifest format documented in C2PA 2.1 §11; that format is unchanged in 2.4 -- the new pieces are repository/soft-binding infra, not the on-file box layout, so no parser change is implied.) Spec: https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html We now READ the soft-binding `alg` (`C2PA_SOFT_BINDINGS` / `soft_binding_vendors_in`) to name the forensic-watermark vendor, and locally DECODE the one open scheme, Adobe TrustMark (`trustmark_detector`); the rest (Digimarc/Imatag/Steg.AI/...) stay name-only (proprietary decoders).
 - **Built in the dated batch:** soft-binding vendor detection, IPTC Photo
   Metadata AI-disclosure fields, C2PA detection and stripping for supported
-  ISOBMFF video, and the optional Adobe TrustMark decoder. Visible video-logo
-  removal and proprietary audio-watermark detection remain outside the package.
+  ISOBMFF video, the optional Adobe TrustMark decoder, and temporally stabilized
+  visible Sora and Veo removal. Other visible video logos and proprietary
+  audio-watermark detection remain outside the package.
   Metadata stripping for supported audio containers is a separate implemented
   path.
 
 **Box detection window — now handled (v0.6.8):** detection no longer relies on a fixed first-MB read. `metadata.scan_head(path, size)` reads the first `size` bytes and, for ISOBMFF, appends the payloads of late provenance boxes found by `isobmff.scan_c2pa_region` (a file-seeking top-level box walker that skips past `mdat` by size without reading it), so a C2PA/AIGC/IPTC manifest placed AFTER a large `mdat` in a streaming/non-faststart MP4 is now caught. Every C2PA/marker byte scan (`has_ai_metadata`, `aigc_label`, `iptc_ai_system`, `synthid_source`, `exif_generator` XMP, `get_ai_metadata` soft-binding, and `identify`) goes through `scan_head`; it is behavior-neutral for non-ISOBMFF inputs (exactly `f.read(size)`).
 
+Native TC260 MP4/MOV tags do not live in those top-level provenance boxes.
+`tc260_aigc_payloads` separately seeks through `moov.udta.meta.keys/ilst`, so
+the normative tag is also found when a large `mdat` precedes `moov`.
+
 **Meta-box XMP and EXIF removal are handled in place:** an AI-label XMP packet
 stored as a meta-box `mime` item is blanked by
 `isobmff.blank_ai_xmp_packets`. Supported EXIF items are handled by
@@ -69,6 +80,16 @@ against primary sources before adding jurisdiction-specific claims.
 
 **Google Gemini visible "sparkle" -- tier-dependent, and spec-undocumented by Google.** Google primary sources (the Nano Banana Pro blog and the gemini.google image-generation page, both WebFetch-verified) confirm Gemini images carry BOTH the invisible SynthID (on ALL Google-AI media) AND a visible sparkle, but the visible mark is **tier-gated**: applied for FREE and Google AI **Pro** users, and **REMOVED** for Google AI **Ultra** subscribers, inside **Google AI Studio**, and on **API / dev** output. So a Google-C2PA image with NO visible sparkle is expected (Ultra / API), not evidence it is clean -- this reinforces the `identify` "no visible mark != clean" rule. The ONLY official verifier is the SynthID flow (upload to the Gemini app, ask if it is AI-generated), which reads the INVISIBLE mark; there is **no official visible-sparkle detector**, and Google publishes **no** glyph geometry / size / opacity / color / locale / placement spec. So our capture-based sparkle template is the only source of truth and cannot be validated against a vendor spec -- keep reverse-engineering from real captures (do not expect a published spec).
 
+**Google Veo video marks use two incompatible visible designs.** Public raw
+clips verify the current four-point diamond and the legacy bottom-right `Veo`
+text. The independent
+[VeoWatermarkRemover](https://github.com/allenk/VeoWatermarkRemover) project
+reports the same current-versus-legacy split, multiple output layouts, and the
+need for cross-frame position agreement. Our implementation copies no logo
+pixels or alpha maps from that project: it uses two synthetic silhouettes,
+known-layout searches plus a strong relocated-diamond fallback, and a separate
+temporal arbiter calibrated against raw watermarked clips and clean API exports.
+
 **The faint-visible-mark precision/recall wall is fundamental, not a heuristic artifact.** The visible-watermark-detection literature has moved to LEARNED segmentation / object-detection (WDNet WACV'21 arXiv:2012.07616; SLBR ACM MM'21, open code+weights; the PRCV'18 large-scale detector; Su et al. survey 2025), but three verified findings bound what a learned detector actually buys: (1) a claim that a confidence threshold "cleanly separates" true from false matches even with a learned CNN front-end was **REFUTED** in verification (arXiv:1705.08593) -- the precision/recall wall persists even with learned features. (2) Learned detectors need a LARGE, pattern-diverse labeled dataset trained on synthetic composites (PRCV'18: 60k images / 80 watermark classes; CLWD: 60k / 160 marks), and off-distribution degradation is a documented real axis (models trained on limited-pattern LVW transfer worse; diversity of training patterns drives generalization). (3) Inference is cheap (WDNet ~8 ms at 256x256) -- the cost is the data pipeline, not runtime. Net: a learned detector shifts the frontier but does NOT remove the wall; for a SINGLE mark the cheapest next step is a small patch classifier (real-sparkle vs false-positive) on top of the existing NCC localizer, not a full segmentation model. SLBR is a ready baseline. The current NCC + false-positive gate (core-ring brightness margin + gradient-NCC crispness + white-core saturation) is a sound operating point, and the residual miss is the information-theoretic wall the literature confirms.
 
 **Visible-mark landscape beyond the registry.** Meta stamps a visible "Imagined with AI" mark (bottom-LEFT, a small symbol) on its OWN Meta AI / "Imagine" output; for third-party images it relies on C2PA / IPTC, not a visible mark. Samsung Galaxy AI additionally uses a **four-star icon** variant in a corner alongside the localized text wordmark `samsung_engine` calibrates (only the Italian text variant is covered) -- the icon is a distinct, uncovered variant. Every source agrees visible + metadata marks are trivially removable (crop / screenshot, ~2 s), which is the tool's premise.