AI Video Detector for Sora: Check Video Metadata for C2PA and AI Generator Signatures
Every few weeks someone asks the same question: is this video AI-generated, and can a tool tell me for sure? The honest answer is that a single check can tell you a lot, but only if you know exactly what it is looking at. A video watermark detector reads one layer of evidence, the metadata stored in the file container, and that layer is powerful when it is present and silent when it is not. This article explains what that layer contains, how it is read, where it breaks, and how to build a verdict you can defend, whether you are a PromoPilot user checking a clip, an editor screening user-submitted footage, or a journalist trying to establish where a file came from.
What a Video Watermark Detector Actually Reads
The phrase "watermark" covers several different things, and mixing them up is the first source of bad conclusions. A visible logo burned into the frames is something you can see with your own eyes. An invisible watermark woven into the pixels, such as Google's SynthID, is something only a dedicated decoder can read. A provenance record stored in the file container, such as C2PA Content Credentials or an XMP packet, is something a parser can read in milliseconds. A container-level tool works only on the third category, and it never looks at the frames or the soundtrack. Knowing that boundary tells you exactly what a clean result can and cannot mean.
- WebM and AVI each have limitations on where and how metadata can be stored
- The reliable approach is to cross-check important findings with a second tool, to pair the container result with a frame-level and audio-level check where those are relevant, and to set an internal rule for escalation
- When that layer is present and intact, it gives you strong, specific evidence about origin
- Cross-check important results with a second tool and a frame-level or audio-level check where the stakes justify it
The container is the wrapper around the streams. In an MP4 or MOV file it is organised as a tree of boxes, also called atoms, and each box has a four-character type and a length. Metadata sits in boxes such as udta, meta and uuid. In Matroska (MKV) and WebM it is a hierarchy of elements, and in AVI it is a set of chunks and lists. A detector walks this structure, looks for known signatures and extracts whatever text or binary it finds. That is fast, cheap and works offline, which is why it is a sensible first pass. It is also fragile, because every re-mux, re-encode or platform upload can rewrite the wrapper and throw the metadata away.
Pixel-level signals behave differently. A watermark embedded in the frames is designed to survive re-encoding, cropping and compression, because it lives in the picture data itself. Reading it requires a model or a decoder that was built for that specific scheme, and it says nothing about the container. So a file can carry no metadata at all and still be AI-generated, if its provenance layer was stripped while the pixel mark survived. The reverse is also true: a file can carry a perfect C2PA manifest and still have been edited afterwards. This is why a container check should be read as one piece of evidence rather than a verdict.
C2PA Content Credentials and Manifest Structure
C2PA, the Coalition for Content Provenance and Authenticity, defines a standard for attaching a signed record of an asset's origin and edit history. The record is called a manifest. It is stored as a JUMBF (JPEG Universal Metadata Box Format) structure inside the file, and in video containers it is typically placed in a box that the detector can locate by its identifier. The manifest contains claims, which are statements about the asset, and assertions, which are the individual facts supporting those claims, such as the tool that created the content, the time of creation, or a note that the content was produced by a generative model.
When reading a manifest, look at three things in order. First, the claim generator field, which names the software that produced the record. Second, the assertions list, which tells you what was claimed, including any digital source type that marks the content as synthetic, such as a trained-algorithmic-media designation. Third, the signature block, which binds the claims to a certificate. The signature can be valid, meaning the bytes have not been changed since signing, while the signer is still untrusted, meaning the certificate does not chain to a root you recognise. Those are two different questions. A valid signature from an unknown signer proves the file is intact, not who signed it.
There is a practical rule for interpreting this layer. A manifest that is present, valid and issued by a trusted signer is strong evidence of origin. A manifest that is present but invalid suggests the file was altered after signing, which is itself a finding worth recording. A manifest that is absent proves very little, because absence is the default state for most downloads. Treat the three outcomes differently, and write down which one you saw.
XMP and Generator Name Strings
XMP, the Extensible Metadata Platform, is an XML-based packet that many tools write into files. It can hold descriptive fields, creation history and, increasingly, provenance hints. In video containers the XMP packet is usually located inside a metadata box, and a detector finds it by searching for the XML root element and then parsing the fields inside. The fields that matter most for AI detection include a digital source type property, which can point to a synthetic or algorithmically generated category, and any generator or creator tool string that names a product.
Generator names are where the real detail lives. A detector looks for identifiers associated with generators such as Sora, Runway, Kling and Pika, and their common variants: product names, company names, internal model names and sometimes version strings. Matching is usually case-insensitive substring matching, which means a short identifier can produce false matches inside unrelated words. Good tools restrict matches to the metadata fields where a generator would plausibly write its name, rather than scanning the whole binary blob. When you read a report, check which field produced the match, not only the name that appeared.
False positives are common enough to plan for. Editing software sometimes copies the creation metadata from a source clip into the export, so an edited video can inherit a generator tag from its input. A batch export pipeline can overwrite tags written by an earlier tool. A user may paste a prompt or a description that mentions a generator, and that text ends up in a comment field. None of these prove that the picture was generated by the named tool. They prove that the name appears in the file, which is a different and more modest claim.
A metadata match tells you what the file says about itself. It does not tell you what the camera, the model or the editor actually did. Keep those two statements separate in every report you write.
Detection Methods Compared
There are three broad ways to examine a video's metadata, and each one trades speed against depth. The choice matters because the cheapest method is the one most likely to miss a signature that is present but encoded in an unusual way.
Lightweight header parsing reads only the container structure and searches for known strings. It is fast, runs on a laptop without special libraries, can scan a file in a few seconds, and works offline. Its weakness is that it cannot tell whether a found signature is intact or meaningful. It sees the text, not the cryptography. It is the right tool for triage, when you have a queue of files and need to sort them into those that need a closer look and those that do not.
Full manifest validation goes further. It parses the JUMBF structure properly, reads every assertion, checks the hashes that bind each assertion to the asset, and verifies the signature against a certificate chain. This is slower and needs a dependency that understands the C2PA format, but it answers the questions that matter for evidence: was the file changed after signing, and who signed it. For a legal or editorial decision, this is the level of detail you actually need.
Hybrid approaches run header parsing first and invoke full validation only when a manifest is found. This keeps the average scan quick while giving full scrutiny to the files that matter. The main thing each approach misses is clear. Header parsing misses meaning. Full validation misses files whose manifest was stripped entirely, because there is nothing to validate. Neither method sees pixel-level marks, which is why they belong alongside a frame-level check rather than replacing it.
Signature and Trust Verification
Verifying a signature involves two separate tests that people often blur together. The first is integrity: does the signature match the content it claims to cover? A mismatch means the file has changed since it was signed, whether by a re-encode, a crop, a colour grade or a deliberate edit. The second is trust: does the signing certificate chain back to an authority you accept? A signature can pass the integrity test and still fail the trust test if the certificate is self-signed or issued by an unknown party.
Certificates also have a lifecycle. A certificate can be expired at the time of signing, revoked later because the key was compromised, or simply not yet recognised by your trust list. A careful report distinguishes these cases, because they point to different conclusions. An expired certificate on a file that was signed while the certificate was valid is not automatically suspicious. A revoked certificate is a serious warning. A self-signed certificate means the claim cannot be independently anchored, which is useful information but not proof of fraud.
A practical reporting scale helps. Record one of four states for each manifest: present, meaning the record exists; valid, meaning the integrity check passed; trusted, meaning the signer is on a list you accept; and unverifiable, meaning the record exists but one of the checks could not be completed. Writing the state, rather than a single yes or no, makes it obvious later what was and was not established.
Heuristic and Multi-Signal Scoring
Some tools combine signals into a single confidence score. The idea is reasonable: a manifest, a generator string and a digital source type together are more persuasive than any one of them alone. The problem is that the weighting is a judgement call, and the score can look more precise than it is. A score of 80 means nothing unless you know what evidence produced it and how the weights were chosen.
When you use a scored tool, look at the components rather than the total. A file whose score comes from a generator string alone is weaker than one whose score comes from a valid, trusted manifest that names the same generator. Single-signal verdicts are unreliable for exactly the reasons already discussed: strings can be inherited, manifests can be stripped, and absence is common. A verdict that rests on two or more independent signals, each of which can be checked, is much more defensible.
Borderline results need a rule. If the only evidence is a weak match, write the verdict as inconclusive and list what would resolve it: the original file, the platform's own label, or a pixel-level check with a dedicated tool. Inconclusive is a legitimate and useful finding. It tells the next reviewer where to look instead of pretending the question is settled. Readers who want to check a clip's origin can try a video watermark detector that scans the container and the frames for the visible and embedded markers left by AI generators, though results depend on how the file was re-encoded and should be read as indicators rather than proof.
How to Choose a Video Watermark Detector: Evaluation Criteria
Choosing a detector is less about feature lists and more about whether the tool will hold up when you rely on it. Start with format coverage. A useful checklist includes MP4, MOV, MKV, WebM and AVI, plus the ability to handle fragmented MP4 files, which are common in streaming downloads, and variable-bitrate containers where metadata may sit in unexpected places. Test a tool on a file in each format you actually receive, because support claims and real behaviour often differ.
Pay attention to how the tool behaves on damaged input. A partially downloaded file, a truncated upload or a file with a corrupted index should produce a clear error message, not a silent pass. A tool that returns "no metadata found" for a broken file is misleading, because the metadata may simply be unreadable. Good tools report parsing failures explicitly so you know the scan was incomplete.
Transparency of results is the next criterion. Can you see the raw metadata fields that produced a finding, the manifest contents if one exists, and any parsing errors? Can you export the report in a form that another person can review? For editorial or legal work, a report you cannot inspect or reproduce is of limited value, however confident its headline looks.
Privacy and processing location matter whenever the footage is unreleased or sensitive. Find out whether the file is processed locally or uploaded to a remote server, how long it is retained, and whether it is used for anything beyond the immediate check. A tool that uploads files may be perfectly acceptable for public material and unacceptable under a non-disclosure agreement. Make that decision before you upload, not after.
Finally, ask about accuracy. A responsible vendor can describe the test set it used, the rate of false positives and negatives on that set, and how often the detection rules are updated as generators change their metadata. Be sceptical of any claim of perfect accuracy. The safest way to evaluate a tool is to test it yourself on files whose origin you already know: a camera original, an edited export, a known AI-generated clip and a platform re-upload. The results will show you the tool's behaviour far better than any marketing page.
Step-by-Step Workflow: From Upload to Verdict
A disciplined workflow starts before the scan. Keep the original file unmodified. Compute a cryptographic hash of it, such as SHA-256, and record the hash alongside the file name, the time you received it and the person who supplied it. If the file is later questioned, the hash lets you show that the file you examined is the file you received. Work on a copy for any operation that might change the bytes, and never run a cleanup tool on the only copy you have.
If the source is locked, such as a file you can only view in a streaming player, extract a copy using the platform's legitimate download option where one exists, and record how the copy was obtained. Note that a downloaded copy is a re-encode in most cases, so its metadata may already differ from the original. The more steps a file has passed through, the less its container can tell you about its origin.
Run the scan in a fixed sequence so the results are comparable across files. Identify the container first and confirm that the format matches the extension, because a mislabelled file is a finding in itself. Extract the XMP packet and read its fields. Check for a manifest and, if one is present, validate it. Then match generator identifiers against the fields you have already read, not against the raw binary. Keeping the order constant means two reviewers working on the same file will reach comparable results. Time expectations depend on size and format: small MP4 files with a simple structure scan quickly, while large MKV files with many attachments take longer, and the time spent is dominated by reading the file from disk rather than by the parsing itself.
When you write the result, record the evidence fields that support it. For each finding, note the field, the value and the state of any signature. Then write the conclusion carefully. "No marker found in the container" is a different statement from "confirmed not AI-generated". The first describes what you checked. The second claims something you could not establish. Keeping that distinction in the wording protects both you and the people who will rely on your report.
Common Mistakes and How to Avoid Them
The most frequent error is treating the absence of metadata as proof of authenticity. A clip downloaded from a social platform has almost certainly been re-encoded, and the platform's processing often removes provenance boxes entirely. A screen recording creates a brand-new file with new metadata that says nothing about the original. A file that passed through an editor may have had its manifest stripped without anyone intending harm. In all these cases the empty result is a false negative, and the sensible response is to look for the earliest available copy rather than to conclude the clip is real.
A second mistake is misreading generator strings. A name in an edit history may refer to a tool used at some point in the workflow, not to the tool that produced the footage. A batch export can leave a tag from a previous job on every file it touches, so one clip in a batch may appear to come from a generator that was never involved with that particular shot. Read the field and its context, and ask what the string is recording.
Container-specific quirks cause a third class of errors. MOV and MP4 share a base structure but differ in how some atoms are interpreted, so a parser tuned for one may miss data in the other. MKV can carry attachments, which are separate files embedded in the container, and metadata may sit inside one of them rather than in the main structure. The practical effect is that the same clip can yield different results after remuxing from one container to another, and that difference is not evidence of tampering. When results disagree across formats, check whether the metadata was carried through the conversion before drawing a conclusion.
The last mistake is overreliance on a single vendor or a single check. No single tool sees everything, and each has blind spots in parsing, coverage and rule updates. For example, a clip that reaches a publication decision should require a valid, trusted manifest or a platform label before it is cleared, and a clip with conflicting signals should go to a second reviewer. Writing the policy down in advance means the decision does not depend on who happens to be looking at the screen that day.
Conclusion
A container-level check is a sharp instrument with a narrow field of view. It reads the provenance layer that a file carries about itself: C2PA manifests, XMP fields and generator strings. When it is missing, it gives you only the knowledge that the wrapper is empty, which is common and says little about the picture. The skill lies in keeping those two outcomes distinct and in never letting a clean result stand in for a verified one.
In practice, the best routine combines the layers. Keep the original file and hash it. Run a container scan in a fixed sequence, validate any manifest you find and read its signature state, and match generator names only against the fields where they belong. Write verdicts that say exactly what was established and what was not, and mark inconclusive results as inconclusive. Do that consistently, and your conclusions will hold up under scrutiny, whether the question comes from an editor, a client or a court.