Repository navigation
Proposal (3.3): add 3gp, mpeg and m4v to video containers #8107
Description
Summary
Add 3gp, mpeg and m4v to the containers enum in
static/schemas/source/core/requirements/video-asset-requirements.json.
Problem
containers lists the video file types a seller accepts. Today it allows
only mp4, webm, mov, avi and mkv. Several ad platforms accept
containers outside this list: TikTok's video upload spec accepts 3gp and
mpeg, and Pinterest's accepts m4v.
A seller representing those platforms can't describe what it accepts in
valid AdCP. It has to either drop the values, understating what it accepts,
or send values that fail validation.
Proposal
- "enum": ["mp4", "webm", "mov", "avi", "mkv"]
+ "enum": ["mp4", "webm", "mov", "avi", "mkv", "3gp", "mpeg", "m4v"]3gp: 3GPP container (.3gp)mpeg: MPEG program stream (.mpeg,.mpg)m4v: MPEG-4 video (.m4v)
Compatibility
The change only widens the list, but a receiver validating against 3.2
would reject the new values, so it isn't wire compatible within 3.2. This
targets 3.3 rather than a 3.2.x patch.
Activity
bokelley commentedon Oct 9, 2026
Triage
Classification: Feature request
Bucket(s): spec / protocol
Status: clarify
Milestone: 3.3.0 (#10)
What the experts said:
3gpandm4vare unambiguous and sound;mpegis the blocker — the sibling VAST schema already usesmpeg_tsas the identifier for transport streams, sompegneeds to pick a lane before the token can ship.m4vhas a live Apple ecosystem CTV/OTT use case;3gphas no meaningful programmatic footprint in 2026 and should be held unless a live platform still requires it;mpegdoesn't align with OpenRTB/VAST naming conventions —ts(MPEG Transport Stream) would serve real SSAI/broadcast sellers better.My take:
m4vis clear and ready to ship in 3.3.mpegis independently flagged by both experts as ambiguous, and the existingmpeg_tstoken in the VAST schema makes naming alignment a real concern.3gp's relevance in 2026 programmatic is disputed.Three questions before the PR scope is locked:
mpegmean MPEG-1/2 program stream (.mpg,video/mpeg) or MPEG-2 transport stream (video/mp2t)? If it's the latter, the sibling VAST schema usesmpeg_ts— please align the token.3gpstill required on any live programmatic platforms in 2026, or ismp4a sufficient stand-in? If you can name a platform, that resolves the hold.containersenum to an open pattern (matching the VAST schema's^[a-z0-9][a-z0-9._+-]*$)? That would be a one-time fix that avoids a minor bump the next time a new container needs expression.Triaged by Claude Code. Session: https://claude.ai/code/session_01XMecS7rbLKAJa7gende8Dv
Generated by Claude Code
andybevan-scope3 commentedon Oct 9, 2026
mpegmeans the MPEG-1/2 program stream (.mpeg/.mpg,video/mpeg), not transport stream.3gp(andmpeg) today, so it's needed for a live platform.andybevan-scope3 commentedon Oct 9, 2026
3b. The same applies to the canonical
video_hostedformat'sparams.containers(formats/canonical/video_hosted.json), which is narrower still:mp4,webm,mov(plusmxfonmain). Whatever we decide here, adding the values or moving to an open pattern, should apply to both lists.Related: is there a reason these are two separate lists? They describe the same thing (accepted video containers) but have already drifted apart. A single shared definition, like the hoisted enums in
enums/from #3174, would keep them in step.Should the canonical
params.containerslist be covered by this issue, or would you like a separate issue for it?bokelley commentedon Oct 31, 2026
Proposed to ship in 3.3 by consent: three additive enum values. Objections by Fri 2026-11-06.