TC260 AIGC Label: What China's AI Video Mark Actually Stores in Your File

If your video came out of a Chinese generator — Doubao, Kling, Jimeng, Hailuo, Qwen — there is a good chance it carries a TC260 AIGC label. This is China's AI-generated content marking standard, GB/T 41819-2022, and unlike a prompt or a model name, it is deliberately designed to survive editing and to be traceable. This post is a field-by-field look at what is actually inside one, using real labels pulled out of real generator output.

If you just want to read or strip one, start with the video metadata remover overview or go straight to how to remove AI metadata from a video.

Where the label lives

The label is not loose bytes appended to the file. It sits inside the ISO base media file format box tree that every MP4, MOV and M4V shares, under moov.udta.meta. Inside that meta box there are two parts that work as a pair.

The first is a key table, which registers the name AIGC as an entry and gives it a one-based index. The second is a metadata list, where each item is addressed by that index and holds the actual value. So the chain reads: meta → key table says entry 1 is called AIGC → item 1 holds the label document.

This indirection is why the value bytes are usually unreadable at a glance. The four bytes that look like a type code in each list item are not a four-character code at all — they are the little-endian index of the entry naming it. Entry 1 comes out as 01 00 00 00, which is not printable.

There is a second layout worth knowing about. Some iOS MOV exports hang the meta box directly off moov instead of nesting it under udta, and omit the key table altogether, leaving the label JSON sitting in a bare list item with no name attached. A reader that only looks for the AIGC string will find nothing on those files. Our reader handles both placements, and for the keyless form falls back to matching on the label's own content — which is why an ordinary encoder string sitting in the same box is correctly left alone.

What is actually in the document

Here is a real label, extracted from MiniMax output. It is abridged only in the two signature blocks:

{
  "Label": "1",
  "ContentProducer": "MiniMax",
  "ProduceID": "2b2fb56231746c304be1f5eed8389e37",
  "ReservedCode1": "{\"SecurityData\":{\"Type\":\"TC260PG\",\"Version\":1,\"PubSD\":[...]}",
  "ContentPropagator": "MiniMax",
  "PropagateID": "2b2fb56231746c304be1f5eed8389e37",
  "ReservedCode2": "{\"SecurityData\":{\"Type\":\"TC260PG\",\"Version\":1,\"PubSD\":[...]}"
}

Six fields carry the meaning.

Label is the flag itself. Its value of 1 is what marks this document as an AI-generation label rather than some other piece of metadata — a reminder that the marker is the type tag, not the presence of a particular key name.

ContentProducer is the tool that made the video. Here it reads MiniMax. In Kling output the same field reads kling. This is the field a reader surfaces, because "which model made this" is the question people actually have.

ProduceID is a 32-character identifier for this specific generation, and it looks like an MD5 digest. For Kling it is more descriptive: KLingMuse_b497b8ce-7738-42c5-bcc3-85ead5fb400c, which names the model family and carries a UUID.

ReservedCode1 and ReservedCode2 are the interesting ones. Each holds an escaped JSON document containing SecurityData, marked "Type":"TC260PG" at version 1. Inside is an array of signed data stores, each with a signature algorithm ID, the data that was signed, and the signature itself. In the MiniMax sample there are stores of type LabelMataData — the label metadata — and of type Binding, which binds the signature to the content it describes.

The algorithm ID is 1.2.156.10197.1.501. That is the OID for SM3withSM2, a Chinese national cryptographic standard built on the SM3 hash and the SM2 elliptic curve. So the label is not merely declarative: it is cryptographically signed, using algorithms chosen deliberately rather than by default.

Why it is signed

The signature covers the label metadata and a binding to the content. That is what makes the label tamper-evident. You cannot open the document, change ContentProducer to something else, and write it back — the signature stops verifying, and a conforming checker is supposed to notice.

This is a meaningful design difference from image workflows. When you strip a prompt out of a Midjourney JPEG, you are deleting a record nobody is checking. When you remove a TC260 label, you are removing a signed assertion of provenance, which is exactly the kind of act the signing was designed to make visible to someone else.

Worth being clear about what that means practically: the signature protects the label's integrity, and our cleaner does not forge a replacement signature. It blanks the label bytes in place, which destroys the label outright rather than producing a label that fails verification. That is a different thing, and worth knowing which one you have done.

The propagation chain

The two fields ContentPropagator and PropagateID exist to track what happened to the file after generation, which makes this the most practically interesting part of the format.

In the MiniMax sample both read MiniMax, matching the producer — nothing has been done to the file yet. But labels do travel. A Kling clip in our own test corpus was re-exported through Higgsfield, a third-party service, and the label came out the other side intact, still naming kling as the producer. Third-party export pipelines pass the metadata through rather than stripping it.

Practically this means you cannot assume a file is clean because you did not make it yourself, and you cannot assume re-exporting cleans it. If a label matters to you, check the file you are actually about to publish — not the file you downloaded.

Labels are not always signed

Not every label carries a signature. The Kling sample above has "ReservedCode1": null and "ReservedCode2": null — the signed blocks are simply absent, and the document is just the identifier fields. So "unsigned" is a real state in the wild, and a checker that only looks for the signature will miss those files.

This is why our reader treats the label as a label when either signal is present: the AIGC key name in the key table, or, in the keyless layout, the TC260PG token inside the value itself. The second check is what keeps a plain encoder string in the same metadata list from being mistaken for a label and wrongly deleted.

Reading and removing one

You can see what a file carries before touching it — the producer, the box path, and how many bytes the label occupies — with the video metadata remover. It reads only headers, so a large clip costs about the same to inspect as a small one.

To understand what removal actually does to the bytes, see how to remove AI metadata from a video. And if you are really asking about the visible or pixel-level marking rather than this metadata layer, that is a different question entirely.