Summary

  • RFC 9924 expresses APV decoder capability as a profile, level and band for each profile.
  • The three fields bound coding features, picture workload and coded data rate; decoding, robust resource use and production acceptance need separate evidence.

At an illustrative finishing desk, an ingest sheet says the receiving system supports a demanding APV profile. An 8K tiled asset enters the queue. Its header parses, yet the decoder's declared level and band for that profile do not cover the picture workload and coded rate. The job stops before a colorist sees a frame.

A second asset reaches an image, but carries metadata the decoder does not recognize. That metadata must not be processed. A third decodes within its declared tuple and still fails the facility's visual review. None of these is a reported product test or incident. Together they expose the problem hidden inside the phrase “codec supported”: it compresses several decisions that belong to different evidence layers.

RFC 9924, Advanced Professional Video, was published in February 2026 as an Informational Independent Stream document. The RFC information record expressly says it is not an IETF product and does not represent IETF consensus. Publication records a specification; it does not certify the implementation, market or production value of any named system.

APV is designed for professional recording and post-production where low delay, high throughput and repeated decode-and-re-encode work matter. It is intra-frame-only. The specification describes tiling for parallel work, coded rates reaching a few gigabits per second for 2K, 4K and 8K material, chroma forms from 4:0:0 to 4:4:4:4, alpha, HDR and user-defined metadata. Its syntax reaches bit depths from 10 through 16, but the currently defined profiles support 10- and 12-bit use. Syntax reach is not a currently defined 16-bit capability claim.

The profile is the first boundary. It selects a subset of algorithmic features and the limits that every conforming decoder for that profile must implement. That makes a profile a decode-obligation family. It does not make the profile name a processor speed, a memory amount, a maximum frame rate or a facility acceptance mark.

Level supplies a different boundary. It constrains luma sample rate and tile geometry: the amount and arrangement of picture work that must be handled. Band then chooses the maximum coded data rate inside that level. A stream can therefore use a recognized profile and still sit outside the workload or rate envelope the receiver declares.

The capability statement is consequently a tuple, and it is per profile. RFC 9924 allows an implementation to support a different level for each profile. “The decoder supports a high profile” cannot be promoted into “the decoder supports the highest workload across every profile.” Procurement tables that place one APV check mark at product level discard the structure the specification took care to preserve.

RFC 9924 also declines to create individually selectable decoder options. The reason is interoperability: every optional switch multiplies the combinations an encoder may emit and a decoder may face. The absence of options does not make all decoders identical; it keeps variation at explicit profile, level and band boundaries where it can be declared and tested.

The reserved identifiers reveal how exact that contract is. A decoder must not assume that an intervening reserved profile_idc represents intermediate profile capabilities. Profiles are feature sets, not points on one safe numeric staircase. For reserved level_idc and band_idc values between specified values, however, the decoder must infer intermediate capabilities. Those fields describe ordered resource envelopes. The numbers may look similar; their semantics are intentionally different.

This is Minimum Initial Specification in operational form. The shared obligation is narrow but precise: implement the declared syntax family and bounded workload tuple; follow the reserved-value rules; avoid a private menu of decoder options that the sender cannot reliably predict. Local engineering may innovate around that contract, but cannot erase it with a generic “supported” label.

Running code creates the next receipt. The current OpenAPV repository and its bitstream tests, the Android 16 APV feature material, the FFmpeg 8.0 release page and the cited FFmpeg encoder commit are concrete implementation evidence. Their availability does not establish complete RFC conformance, device coverage, throughput, perceptual quality, security or production adoption.

Conformance itself still needs layers. First ask whether the bitstream obeys the syntax. Then ask whether its tuple sits inside the decoder's declared capability for that profile. Then observe whether this decoder build parses and reconstructs it. Separately bound time, memory and failure behavior. Compare the output with an appropriate reference and method. Finally let the production owner accept or reject the result under the workflow's own visual, metadata and operational requirements.

Security makes those separations compulsory. Predictable header bits and padding mean a transport should not combine APV with a cipher or mode vulnerable to known-plaintext attacks; APV does not supply confidentiality. A malicious or non-compliant payload must not cause a memory overrun or excessive resource use, and implementations need integer-overflow checks. A decoder that eventually rejects a frame but first exhausts memory has not demonstrated robust failure.

The input surface extends in both directions. A hostile stream can reach an encoder through a transcoding gateway, so encoder-side parsing cannot be dismissed merely because encoder failures are expected to be rarer. A decoder must not process an unrecognized metadata type, because incorrect interpretation can leave it in an unknown state. The statement that APV-carried content is not intended to be executable is not a malformed-media safety guarantee.

At the evidence freeze, the RFC 9924 errata search was reachable. Its result is document-maintenance metadata, not a decoder certificate. The same discipline applies to “perceptually lossless”: it states a design purpose, not the result of a disclosed comparison on a named asset, display and observer process.

Heng Lu's Running-Code Primacy moves authority from the product badge to the exact parser, decoder, encoder and gateway behavior that ran. Minimum Initial Specification explains why the shared tuple must remain explicit while later implementation choices stay local. Reality Layers prevents RFC publication, syntax validity, declared capability, bounded execution, decoded output, perceived quality and production acceptance from being merged into one symbolic state.

The useful receipt therefore names the stream tuple and the decoder's tuple for that profile. It records picture dimensions, frame rate, tiles, chroma, alpha, bit depth and coded rate; decoder build and configuration; parser and decode outcome; peak resources; metadata handling; reference method; output identity; and the production decision. “APV supported” can remain a discovery hint. It cannot be the contract.

Sources