Receiver compatibility contract
“AAC audio” is too broad for production acceptance. A useful contract records the exact coding identifier, configuration, sample rate, channel layout and carriage, then proves that every required receiver decodes the same track in sync.
Bitrate can wait. The first question is what the sender emits and what the container, transport and receiver actually signal.
Translate the AAC label into an exact configuration
AAC is MPEG-4 audio carried as an elementary stream; a receiver test must name the AAC configuration and the transport or container carrying it. The encoder output or a captured asset is the right starting point, not a profile name copied from a preset menu. Tool version and raw inspection output remain with the result.
The codecs parameter identifies the coding format and, where defined, profile or level details; the label AAC alone is not a complete receiver-compatibility contract. The exact identifier exposed in the stream or manifest belongs in the record, together with whether the encoder reported it or a player inferred it.
Separate AAC coding from its transport or container
The AAC elementary stream can be carried in different environments. Name whether the test uses an ISO BMFF/MP4 asset, an MPEG transport stream, a streaming manifest or another documented path. A receiver may support the coding format in one carriage and reject it in another, so “the device supports AAC” is not sufficient evidence.
An ISO BMFF playback path depends on a valid initialization segment and track configuration before media segments can be accepted. For that path, inspect the initialization and track signaling together. For a transport stream, retain the program and stream mapping. Do not compare failures across carriages until each has an exact record.
| Layer | Question | Evidence |
|---|---|---|
| Coding | Which AAC configuration is signaled? | Encoder/probe output |
| Carriage | Where is the audio elementary stream packaged? | Container/transport record |
| Receiver | What did this version decode? | Playback capture and logs |
Record profile, sample rate and channel layout
Every parameter should be written as measured, with units. “Stereo” cannot stand in for an assumed channel order, and a sample-rate conversion is not harmless until listening and sync checks say so. With multiple language tracks, each track keeps its language, role and default behavior in the record.
For a real multilingual production, Validate a multilingual audio workflow after the base AAC contract is known. The workflow owner should decide which track is default, which alternatives are selectable and what happens when a track is missing. That decision is separate from the codec definition.
- Capture the source and output values.
- Note any resampling or channel mapping stage.
- Keep track IDs stable through packaging.
- Record silence, clipping and loudness observations separately.
- Use the same timed speech passage for synchronization checks.
Build the receiver compatibility matrix
The matrix should reflect the real product surface: browser and operating-system versions, mobile applications, hardware decoders or editing systems. Each receiver gets the same fixture. Its row records whether it opened the carriage, discovered the audio track, decoded cleanly, selected the intended default and kept synchronization through a seek or reconnect.
A single green cell cannot become a universal statement. The exact combination that passed is the useful result. When one receiver rejects a profile and another accepts it, both outcomes stay visible while the team decides whether to change the sender, offer a fallback or narrow support. A generic “recommended settings” paragraph should not hide that choice.
Track discovered, decoded, audible, correctly mapped and synchronized.
Missing track, decode error, wrong channel mapping, drift or unsupported carriage.
Test decoded audio and synchronization
A useful fixture contains clear speech, a visible sync cue, channel identification and a quiet section. The receiver test includes listening, player or decoder logs and a seek to at least one later timestamp. Live transport adds reconnect and a controlled discontinuity. A non-zero audio bitrate or present track entry does not prove audible, correctly mapped output.
Only after compatibility passes should you Plan audio bitrate after compatibility. Video remains independent: Separate video bitrate decisions. Capacity planning can then Estimate the combined stream rate. None of those calculations should silently rewrite the accepted AAC identity.
Keep the accepted configuration as a reproducible fixture
The smallest lawful asset or stream configuration that reproduces the accepted result becomes the fixture. It includes the encoder settings export, inspection output, container or transport details, receiver versions and expected audible observations, plus a stable checksum and a location QA can retrieve.
To stay audible and diagnosable, the fixture needs spoken channel names, a visible clap or tone marker, a quiet interval and enough duration to expose drift. Expected observations should not imply that one fixture covers all content. Licensed material can be replaced with an approved synthetic asset that preserves the technical track configuration.
The matrix also needs a change trigger. Encoder firmware, packaging rules, browser media frameworks, hardware decoders and application audio routing can alter the result. After those changes, the same fixture runs again; if the sender must move to a different AAC configuration, a new contract replaces a silent edit to old evidence.
One probe or encoder record and one receiver matrix should show the exact AAC identifier, sample rate, channels, carriage, decoded audio, sync result and pass/fail device versions. An encoder, packager or receiver update triggers the same matrix before the supported contract changes.
