Broadcaster
A broadcaster whose news and sports archive is subject to authenticity obligations under emerging platform or regulatory requirements
Verifiable provenance credentials for VOD assets
Audiences, partners and regulators cannot tell whether a clip was altered between the newsroom and the screen, and that gap is becoming a liability as synthetic media grows. This POC attaches C2PA Content Credentials to VOD assets during transcoding and verifies them at playback, so provenance is part of the asset rather than an assertion alongside it.

A VOD asset passes through multiple hands before it reaches a viewer: ingest, transcoding, packaging, CDN, player. At any point it can be altered, and nothing in a standard streaming pipeline records that a change happened. The viewer, the rights holder and the regulator all have to trust that what they receive is what was originally submitted.
That trust is increasingly difficult to maintain. Synthetic media makes convincing alteration cheap, and regulatory pressure on content authenticity is hardening. Yet most platforms have no mechanism to detect tampering, let alone surface it to viewers in real time. Adding provenance after the fact requires re-processing the entire archive; doing nothing means the gap widens with every asset ingested.
This is relevant if you are:
A broadcaster whose news and sports archive is subject to authenticity obligations under emerging platform or regulatory requirements
A rights holder distributing licensed clips to third-party platforms who needs to demonstrate chain of custody from ingest to playback
A sports organisation whose match footage is syndicated widely and needs a verifiable record of what left the production environment
Source footage is ingested and passed through our in-house transcoder, which generates a manifest describing the encoding and packaging steps taken. The manifest follows the C2PA specification and is produced during the encode, not in a post-processing pass.
The manifest is cryptographically signed and embedded directly into the packaged asset - MP4, CMAF segments for DASH, or HLS - so the credential travels with the content rather than in a sidecar. These are the same formats as unsigned delivery, so distribution infrastructure is unchanged.
The reference player reads the embedded manifest on load. An authenticity badge in the player UI tells the viewer who signed the content, when, and which tools were used.
If a segment has been altered after signing, the player highlights the affected portion of the progress bar, making tampered sections visible without interrupting playback.
Integration with an existing pipeline requires no workflow restructuring: signing happens inside the encoder, and verification happens inside the player.
Most content authenticity approaches treat provenance as an out-of-band assertion - a database entry or sidecar file that must be looked up separately. This POC embeds the credential inside the asset itself, at the moment of encoding, so the chain of custody is preserved even when the asset moves across platforms, CDNs or storage systems that have no knowledge of the signing service. Verification is also in-player rather than in a separate tool, which means it can surface to the viewer rather than existing only for compliance teams.
C2PA Content Authentication has graduated: the signing and verification work has moved into the BBM product line. The demo on this page runs against pre-signed assets and shows both the authenticity badge and tamper-detection behaviour in the reference player.
Verification depends on the player: one that cannot read a C2PA manifest will play the asset normally but will never surface the provenance badge. The transcoder integration currently covers MP4 and CMAF-based DASH/HLS packaging and no other containers, and tamper detection operates at segment granularity, so an alteration contained inside a single segment may go unflagged. Signing an existing archive means re-transcoding it, because assets already in distribution cannot be credentialled retroactively. Key management and certificate infrastructure sit outside this POC entirely: a production deployment needs a defined PKI or an integration with an existing signing authority.
The next step is a pilot against a customer pipeline: ingest real source material, sign it through our transcoder, and validate the end-to-end chain against the customer's delivery infrastructure.
Tell us what your current pipeline looks like and we will walk you through what adding C2PA signing at the transcoder and verification at the player would involve.