video_settings

Video Transcoding

Our encoder pipeline ingests any source format and produces multi-bitrate HLS and DASH renditions with configurable codec, segment length, watermark and thumbnail generation.

Codec support

H.264, HEVC and AV1 for high-resolution content.

ABR output

Fully configurable HLS and DASH packaging tuned per profile.

Profile presets

Reusable video and audio encoding profiles.

Post-processing

Auto thumbnails, watermark text/image, overlays.

How the encoding pipeline works

A source file enters the pipeline as a mezzanine - ProRes, MXF, AVC-Intra or a high-bitrate MP4 - and is probed for resolution, frame rate, colour space, audio layout and existing subtitle tracks. Anything inconsistent is normalised before encoding starts: loudness is aligned to EBU R 128 or ATSC A/85, interlaced sources are deinterlaced, and audio is downmixed or passed through as multichannel depending on the target platform.

The normalised master is then encoded into a bitrate ladder and packaged into segmented HLS and MPEG-DASH output. Using CMAF fragments means the same media segments serve both protocols, so storage and CDN cache footprint stay roughly half of what separate TS and MP4 outputs would cost. Thumbnails, sprite sheets for scrub previews and an optional text or image watermark are produced in the same pass.

Choosing the bitrate ladder

The ladder decides both playback quality and your delivery bill, and the right one depends on the audience. A TV-first service can drop the very low rungs a mobile service needs, because a living-room device is rarely on a 500 kbps connection - but it does need a solid top rung, since a 1080p stream that looks fine on a phone falls apart on a 65-inch panel.

Rungs are kept keyframe-aligned with a fixed GOP so players can switch between them without artefacts, and segment duration is usually 4 to 6 seconds for on-demand. Shorter segments cut startup and switching latency but multiply request count and manifest size, which older Smart TV browsers handle badly. Per-title encoding, where the ladder is adapted to the complexity of each asset, saves bandwidth on simple content such as talk shows and animation.

Profiles, queueing and re-encodes

Encoding settings live in reusable profiles rather than being retyped per asset, so a catalogue stays consistent and a codec or ladder change can be rolled out by re-running a profile instead of editing hundreds of jobs. Jobs run through a queue with retry handling, and the CMS shows the state of each asset as it moves from set-up to uploaded, encoding and ready.

Adding a new codec later - AV1 for bandwidth savings on supported devices, HEVC for 4K and HDR - is a matter of adding an output to the profile. Existing assets can be re-encoded in the background while the current renditions keep serving traffic.

Frequently asked questions

Which codecs and containers do you support?
H.264/AVC for universal device compatibility, HEVC/H.265 for 4K and HDR, and AV1 where the target devices decode it. Output is packaged as HLS and MPEG-DASH, with CMAF fragments shared between both.
Do I need both HLS and DASH?
In practice yes, if you target every living-room platform. Apple devices and several TV browsers require HLS, while DASH is the better fit for PlayReady and Widevine on Tizen, webOS and Android. CMAF packaging keeps the storage cost of shipping both low.
Can you handle 4K and HDR?
Yes - HEVC with HDR10 or HLG, provided the source carries the right metadata. Dolby Vision and Dolby Atmos require licensing agreements with Dolby that the content owner or service operator holds.