playbackmethod: [1, 2] Validates as JSON. RMT Sound State Needs One Answer.

A header-bidding adapter ships a video imp with "playbackmethod": [1, 2]. The exchange accepts the request. The DSP bid engine reads sound-on instream inventory. The player starts muted.

Nothing failed at the JSON layer. The failure is a contract mismatch between what the field means in OpenRTB today and what IAB Redefining Media Types (RMT) plans to derive from it tomorrow.

Capability list versus impression fact

On the OpenRTB Video object, playbackmethod is an integer array drawn from AdCOM List: Playback Methods. Values 1 and 5 mean playback starts with sound on by default. Values 2 and 6 mean playback starts with sound off. The spec describes the array as playback methods that may be in use on the placement. If the field is omitted, any method may be used.

That wording fits inventory that supports more than one player behavior across refreshes, sizes, or user settings. Prebid module docs often show playbackmethod: [1, 2] as a template: the unit can autoplay with sound or without, depending on the browser and the page.

RMT's operational layer is different. The RMT walkthrough on RTBlint maps the sound-state attribute directly onto video.playbackmethod, treating 1 and 5 as sound on and 2 and 6 as sound off for this impression. The standard is designed to encode eight binary attributes into bid requests so buyers and sellers stop arguing about whether connected TV meant lean-back sound-on or muted feed video.

A single imp cannot start both sound on and sound off at the same instant. An array that lists both is a honest capability statement for OpenRTB. It is not a single sound-state fact for RMT unless every downstream system agrees on a reduction rule.

The spec already warns about reduction

OpenRTB 2.6 notes that buyers should rely on the first element only of playbackmethod, because the array may become a single integer in a future version. That is guidance, not validation. Nothing in the schema rejects [2, 1] or [1, 2].

So three pipelines can all claim to be spec-aligned:

• Read index 0 only (muted if the array is [2, 1]).
• Treat presence of 1 anywhere as sound-on inventory.
• Ignore the field when plcmt is present and infer sound from placement subtype.

Each choice produces a different RMT sound label on the same bytes. The auction still clears.

The OpenRTB enums reference lists every playback method value, including 8 through 11 added for pause and screensaver treatments in AdCOM 1.0-202607. The video object field guide separates playbackmethod from plcmt and from linearity, which matters because RMT's ad-format attribute also reads plcmt and linearity. Sound state is only one column in the mapping table; it is the one most likely to be populated as a multi-value capability array today.

When the field is empty

Omitting playbackmethod is equally valid OpenRTB. The spec explicitly allows any method when none are specified.

That is convenient for legacy adapters. For RMT, empty means the sound-state attribute has no declared input. Classifiers will impute from plcmt, device type, or publisher defaults. Reporting will still show a sound bucket as if it were measured.

The same pattern showed up during the placement to plcmt migration: valid JSON, missing or copied enums, buyers filtering on the new field while sellers still populated the old one. The placement versus plcmt copied integer post walks a muted autoplay unit that validates while claiming sound-on instream. RMT inherits that stack; it does not replace it.

How you catch it before classification lands

Paste the request into the RTBlint bid request tester. It runs the same validator as the CLI and prints rule ids with JSON paths.

For CI, pin a dated OpenRTB snapshot and fail on semantic errors:

$ rtblint validate --type request --version 2.6-202606 @bid.json

RTBlint today enforces AdCOM enum ranges, mutual exclusions like minduration versus rqddurs, and skip dependencies such as skipmin only when skip is 1. It does not yet reject [1, 2] as contradictory sound states, because OpenRTB does not forbid that shape. You still want the report before RMT turns informal reduction rules into planning and finance labels.

An implementation that lets a model emit or patch OpenRTB bid requests still has to check the object on the wire. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is that check for the request and response. It is independent of IAB Tech Lab and of AAO. It does not replace exchange acceptance tests; it catches malformed enums and semantic contradictions the RPC layer will not surface.

When the imp wins, delivery is still a VAST tag. Paste the ad tag URL into the VAST tag tester to see whether preview and tracking match the sound contract you declared on the imp. If the response is a wrapper chain, the VAST inspector walks each hop until InLine.

Where to go next

Start with the RMT field mapping table and audit what percentage of your video imps populate playbackmethod at all, and with how many entries.

Pair that with common OpenRTB bid request mistakes for the semantic errors exchanges already ignore.

If partners send mixed 2.5 and 2.6 fields, read OpenRTB version mismatch before you trust a classifier built on enums that moved between snapshots.

The short version

playbackmethod: [1, 2] is valid OpenRTB. It is not a single sound-state claim. RMT plans to read one. Decide whether you send one integer, document which index buyers must use, or stop treating the array as a capability menu on imps that need a definite classification.