Audio delivery contract
Choose the audio codec from the listener backward
An audio codec compresses sound for transport or storage and reconstructs it for listening. The useful question is not “Which codec is best?” It is “Which codec, channel layout, sample rate, bitrate, and container can every required handoff decode—and what evidence will prove speech, music, sync, and fallback still work?”
The short answer
For conventional HLS delivery, stereo AAC-family audio is a practical compatibility baseline when the target player contract accepts it. For interactive WebRTC, Opus is the normal starting point; WebRTC endpoints are required to implement Opus as well as PCMA and PCMU. G.711 remains useful at a telephony boundary, but its narrowband heritage and bandwidth cost make it a poor default for a music programme. Multichannel AAC, AC-3, E-AC-3, or another premium format belongs in a device-, player-, rights-, and licensing-specific plan—not in a universal preset.
In Callaba, start by proving the received audio. Preserve it when every downstream requirement already matches. Use Callaba live video transcoding or a controlled Restream job only when the output contract requires a codec, sample-rate, channel, or packaging change. A successful transport session does not prove that a listener can hear the correct programme.
The moving marker represents an acceptance test crossing the chain; it is not a live level meter or Callaba status signal. It stops when reduced motion is preferred.
Codec, bitrate, sample rate, channels, and transport are different decisions
Codec
AAC, Opus, G.711, AC-3, and E-AC-3 describe ways to encode audio. A codec name alone does not specify channels, bitrate, profile, framing, or the container that carries it.
Bitrate
Bitrate is the data budget. It affects compression pressure but does not identify the codec. Compare like with like: programme type, channels, codec mode, and listening conditions.
Sample rate and layout
A receiver can support the codec yet fail because it expects 48 kHz stereo and receives a different rate or an unexpected 5.1 mapping. Track order and language identity matter too.
Container and transport
RTP/WebRTC, MPEG-TS over SRT, fragmented MP4 in HLS, and an MP4 file impose different signaling and playback constraints. “The encoder supports Opus” is not proof that a particular HLS player or destination accepts Opus in the form you send.
A decision matrix for the first interoperability test
| Workflow | Useful first candidate | Why | What must pass |
|---|---|---|---|
| HLS to browsers and consumer devices | Stereo AAC-family rendition accepted by the target profile | Apple's current HLS device guidance requires a stereo AAC-family option and publishes initial bitrate guidance for it. | Every supported OS/player cohort, playlist signaling, language/default selection, level, and ABR audio continuity. |
| WebRTC call or interactive room | Opus | Opus was designed for interactive speech and music; WebRTC endpoints must implement it. | Offer/answer result, packetization time, loss behavior, echo processing, browser cohorts, recording or restream handoff. |
| Legacy voice or telephony bridge | PCMA or PCMU only where the peer contract requires G.711 | It provides a well-understood interoperability floor for voice systems. | Exact companding variant, clock rate, RTP payload mapping, narrowband quality expectation, and downstream conversion. |
| Premium surround delivery | Receiver-approved multichannel format plus a deliberate stereo fallback | Device and output-path support vary; a codec logo on one component does not prove the chain. | Channel order, metadata, decoder and HDMI/output behavior, fallback selection, licensing, and audible downmix. |
| Editing or preservation master | A lossless or lightly compressed production format chosen by the post-production contract | A small delivery encode is a poor master for repeated editing and re-encoding. | Bit depth, sample rate, channel labels, timecode/sync, storage, interchange, and a derived delivery encode. |
Build the Callaba workflow in this order
- Write one destination contract. Record the accepted codec and profile, bitrate range, sample rate, channel count and order, track or language rules, container, transport, and loudness requirement. Copy current requirements from the receiving platform or device; do not reuse a social-platform preset for an IPTV headend or a browser call.
- Prove the source before processing it. Listen locally, identify each required channel, and inspect the actual media. A useful probe for an authorized file or endpoint is:
Keep the report with the acceptance evidence. It describes the stream; it does not prove that speech is intelligible or channels are correctly labeled.Command
ffprobe -v error -select_streams a -show_streams -of json INPUT - Prefer preservation when the contracts match. If the input codec, layout, sample rate, and packaging are accepted downstream, avoid a needless decode/encode generation. Still validate the output because mapping or muxing can fail without a codec change.
- Transcode for a named mismatch. Follow the Restreaming guide and change only the fields required by the receiver. Name the job for both source and destination so an operator can identify the ownership boundary. Benchmark the complete video-and-audio profile on the deployment class that will carry production.
- Verify both the processed output and the real listener. Confirm an increasing output bitrate, then listen in the destination's own preview or the intended Callaba Web Player. Test the main language, alternate tracks, silent passages, music, speech, left/right identity, and lip sync.
- Run long enough to reveal clock and lifecycle faults. A 30-second clip will not expose hour-scale drift, a reconnect that swaps tracks, or token expiry during playback. Rehearse source loss, restart, and restoration one boundary at a time.
Use published bitrate numbers as test inputs, not promises
RFC 6716 says Opus supports a very wide range of rates and modes. For 20 ms frames, it identifies approximate “sweet spots” such as 28–40 kbit/s for fullband speech and 64–128 kbit/s for fullband stereo music. The same RFC explains the packetization trade-off: longer frames reduce packet overhead but increase latency and make each lost packet cover more audio. Those figures describe the codec, not a guarantee for your microphone, noise, network, processing, or listener.
Apple's HLS authoring guidance currently presents 32–160 kbit/s as an initial range for stereo AAC-family delivery and explicitly tells authors to evaluate suggested rates against their content and encoding workflow. Start inside the receiver's allowed contract, compare representative speech and music, and choose the lowest rate that passes the listening and failure tests. Do not save a few kilobits by making the programme tiring or unintelligible.
Across an HLS adaptive ladder, audio deserves consistency. RFC 8216 recommends the same encoded audio bitstream across variants for broad compatibility, because rendition switching can otherwise create audible glitches. When separate audio renditions are required, verify timestamps, group signaling, defaults, language labels, and switches independently of video quality changes.
Acceptance evidence for audio is partly human
Identity
The expected programme, language, channel order, and default track are present. Stereo is not silently duplicated mono, and a surround layout is not reordered.
Audibility
Speech remains intelligible, music is not pumping or metallic, silence stays clean, and loud/quiet transitions do not clip. Review on representative headphones, speakers, and device outputs.
Timing
Lip sync is acceptable at start, after an ABR switch, after reconnect, and late in a long session. Record the observation time against synchronized system clocks.
Compatibility
The exact browser, app, decoder, or destination cohort starts without a hidden transcode and recovers after an allowed interruption.
Capacity
The complete transcode profile runs with representative video motion and source count. CPU or accelerator headroom is measured under load, not inferred from an idle test.
Fallback
A stereo fallback, replacement source, or known working preset is documented and rehearsed. The operator knows what quality or channel capability will be lost.
Troubleshoot the first boundary that changes the evidence
- Transport is connected, but there is no sound
- Check the source selection and stream inventory first. Then compare codec, container, programme number, track mapping, and the receiver's accepted contract. Do not increase bitrate to fix a missing track.
- Sound exists, but the wrong language or channel plays
- Inspect default and language signaling, channel order, and player selection. Keep track identity stable through transcoding and packaging.
- Audio drifts during a long event
- Compare source clock behavior, timestamps before and after processing, frame drops, and restarts. Capture evidence at input and output so the transport, transcoder, and player are not treated as one box.
- One browser or device fails
- Compare that cohort's codec and container support with the manifest or file that actually arrived. A codec supported in WebRTC is not automatically supported in every HLS or MP4 combination.
- Audio breaks during quality switches
- Verify aligned timestamps, compatible audio across variants, rendition-group signaling, and continuity at the segment boundary. Inspect the playlist before tuning the player's buffer.
Primary technical references
- RFC 6716: Definition of the Opus Audio Codec — bitrate, bandwidth, channels, frame duration, delay, and complexity trade-offs.
- RFC 7874: WebRTC Audio Codec and Processing Requirements — mandatory Opus, PCMA, and PCMU interoperability baseline.
- RFC 8216: HTTP Live Streaming — audio renditions, codec signaling, playlists, and variant-stream consistency.
- Apple HLS authoring specification — current device-focused audio requirements, initial bitrate guidance, formats, and delivery rules.
Product first, automation after one profile passes
Use Callaba live video transcoding when a destination needs a different media contract, or Callaba Video on Demand when the job is file-based playback. First create and listen to one representative path in the product UI. Once its input, output, fallback, and evidence are recorded, reproduce the known object with the Restreams API. The API can repeat a contract; it cannot decide whether the right language is audible.
For adjacent concepts, use the audio bitrate guide, the broad codec guide, and the transcoding workflow.
Prove one real output before standardizing the preset
Launch Callaba, ingest representative speech and music, preserve the source where possible, and make one receiver-required change at a time. Save the probe, listening notes, long-session result, and recovery result as the profile's acceptance record.
