xOTTTransport streams and audio level control
Set up UDP/HTTP TS inputs, broadcast metadata and measured audio correction without confusing HLS and direct UDP paths.
On this page
Receive the right programme on the right host
A multicast input is received on the processing host and interface, not the operator’s browser. Choose the server with access to that network and select its receiving interface. Multi-programme inputs may require an explicit MPEG-TS program ID. Continuous HTTP TS is a transport input even when its URL uses HTTPS.
Example only — replace with your network
udp://239.20.0.10:5000
https://source.example.com/live/channel.tsUDP output metadata
Enable UDP in additional outputs and set the destination group/port, outgoing interface and relevant transport metadata. Detect service metadata from input fills blank service ID, name and provider when those values are detected. It does not assume the output PIDs or network IDs equal the input; remuxing can change them.
- Use explicit service IDs and planned output PIDs for headend integration.
- Service name/provider in the output should identify the intended channel.
- Confirm TTL, packet pacing, bitrate and receiver compatibility on the actual network.
- A source can carry no useful service name; detection cannot invent correct metadata.
Two audio-processing paths
| Scope | Pipeline | Tradeoff |
|---|---|---|
| UDP output only | Input → dedicated UDP processing → UDP destination; HLS remains independent | Suitable for a headend-specific correction without changing HLS. |
| HLS and processed outputs (shared audio) | Clear manual UDP/HTTP TS → shared audio processing → HLS → derived outputs | One corrected audio signal for HLS and derived outputs, but UDP inherits HLS buffering delay. |
These are deliberate output-scope choices, not an accidental universal extra hop. Check the UDP source mode and effective scope. A dedicated headend-only channel and a separate HLS channel can be useful when you need independent latency and audio policies.
Configure audio deliberately
- Probe the intended input programme and identify every audio track, language, layout and codec.
- Choose Fixed gain + peak limiter for a known offset, or Live loudness normalization for dynamic correction. Copy audio applies no correction.
- Choose one audio track or preserve/process supported multiple tracks. Do not assume correcting the first track fixes the Spanish and English tracks equally.
- If receiver loudness differs for surround audio, assess Stereo downmix before audio processing. This removes surround information; it is not just a volume slider.
- Set a deliberate target/true-peak policy, start one test channel and measure input and output over representative content.
- Listen and measure on the actual receiver/QAM path before replacing production feeds.
Measure and compare
Use Monitoring → Transport & Audio and its audio measurement controls. Check measurement source, track, age and failures. Compare equivalent content windows; two channels playing different scenes cannot prove programme-wide loudness equivalence from one short sample. Network cutouts and timestamp defects need transport diagnosis, not just more gain.
Additional HTTP TS, DASH, SRT and RTMP
Configure each output only when needed. HTTP TS is a continuous client connection, not a segment playlist. DASH/HLS can expose compatible alternate renditions; UDP/HTTP TS/SRT use a primary video and compatible audio; RTMP is a primary A/V push. Verify URLs from the output details rather than constructing undocumented endpoint paths.
UDP ingress and egress contribute to host/interface network traffic where measured. An emitted multicast destination is not an authenticated viewer session, and multicast receiver count cannot be inferred from output bitrate.