C2PA soft binding and watermarks: what a trim or re-encode does
The C2PA 2.3 spec defines soft binding for invisible watermarks. Sume's trim has exact re-encode and keyframe copy modes; here is what to verify after each.
A trim can change the bytes of a file, and a watermark or manifest can depend on those bytes. C2PA 2.3 includes a soft_binding_assertion, and its spec page defines an invisible watermark as imperceptible information that can identify the asset or reference a manifest. What a given trim leaves intact is something to test on your own files, not assume.
Two trim modes on Sume
The Sume video trim docs describe precision. The default exact is a frame-accurate re-encode with libx264 and yuv420p. keyframe is a stream copy where the cut may start a GOP early, so you re-base against actual_start_seconds. Both return a new MP4 artifact; the source is untouched.
| Mode | Method | Output |
|---|---|---|
| exact (default) | Re-encode, libx264, yuv420p | New MP4, frame-accurate |
| keyframe | Stream copy | New MP4, may start a GOP early |
What the docs do not say
Neither the trim page nor the C2PA pages I read says whether a given watermark survives either mode. A stream copy keeps the compressed frames, a re-encode makes new ones. That is general video behavior, not a claim from a vendor page, so treat it as a hypothesis to test.
A test you can run
Take one clip with the marker you care about. Trim it once with exact and once with keyframe. Run your detector or manifest reader on both outputs and on the source, and write down the result per mode.
Each trim is $0.02 per job, so the test costs four cents. The result tells you which mode to use before a launch.
- Keep the source artifact; trim never changes it.
- Check
actual_start_secondson keyframe outputs. - Record the mode you used with the job id.
Sources
Related posts
More in Developers
- Can polling Sume job status hit the rate limit? Read budget math
Reads and writes have separate Sume budgets. Worked numbers for polling every accepted job per plan, plus a delay function that reads ratelimit headers.
- Cancel an image job: it only works before generation starts
POST /v1/jobs/{id}/cancel succeeds only while a Sume job has not started generating. Here is the 409 you get otherwise, and what is billed after a cancel.
- Cancel a completed job: 409 job_not_cancelable vs already started
Sume returns 409 job_not_cancelable when you cancel a finished job, and job_generation_already_started mid-run. How to tell them apart and handle each.
- Cancel a queued Seedance 2.5 job: it works only before it starts
POST /v1/jobs/{id}/cancel stops a queued seedance-2.5 job; once generation has started you get 409 job_generation_already_started and it still bills.
Written by Sume