Video transcoding for OTT: the real ladder and codec defaults

When a file finishes uploading, the platform creates a transcoding job and places it in the queue. The queue processes jobs in order with a set level of parallelism, so a batch of fifty uploads on launch day is worked through steadily rather than all at once. The monitoring dashboard shows each job as waiting, active, completed or failed, and the job record keeps the outcome so you can check a title weeks later.

The transcoding settings hold the ladder. By default a job produces 720p, 480p and 360p renditions; you can select additional renditions up to 1440p. Each rendition is a separate encode at a resolution and bitrate chosen for that size. A source that is only 720p does not gain anything from a 1080p rendition, so the ladder should be chosen per catalog with the source quality in mind rather than set as high as the menu allows.

Every rendition is encoded in H.264 unless a different codec is selected for the job. H.265, AV1 and VP9 are available on request; when one is selected, the job also produces an H.264 version so a device that cannot decode the newer codec still plays. The alternative codecs produce smaller files at similar quality on the devices that support them, which matters for bandwidth on a television-heavy audience but adds encoding time.

The job takes the audio from the source and encodes one AAC track that every rendition shares. There is no multi-track audio in one stream, so a title available in two languages is published as two titles, each with its own audio, and tagged with its audio language in the catalog. Subtitles are handled separately as caption files on the video subtitles page and do not pass through the transcoding job.

The renditions are segmented and written as HLS media playlists, and a master playlist lists them with their bandwidth and resolution so the player can choose. This package is what the delivery layer serves. Because the master playlist is generated by the job, adding or removing a rendition later means re-running the job for that title rather than editing a file by hand.

A source with a broken container, an unsupported pixel format or a truncated upload will fail in the queue rather than produce a silent bad output. The dashboard shows the failed job and the record keeps the error. Re-uploading a corrected file creates a new job. Because failure is explicit, a launch checklist can include a pass through the dashboard to confirm every title on the schedule reached completed status.

Renditions can be selected up to 1440p and no higher. Flicknexs does not produce ultra-high-definition renditions or high dynamic range output, and this page does not claim otherwise. For the large majority of catalogs and audiences, a well-built ladder ending at 1080p or 1440p delivers the quality viewers perceive; sources above that are encoded at 1440p or below.

H.265, AV1 and VP9 are selectable per job on request rather than switched on for the whole catalog by default. Each produces an H.264 fallback automatically, which means more encoding time and more storage for those titles. Use them where the device breakdown shows a clear win; for a phone-heavy audience on a modest ladder, H.264 alone is usually the right call.

Each job produces a single AAC audio track. Multiple audio languages in one stream are not offered; a dubbed version is published as its own title with its audio language tagged in the catalog, and the multi-language video page explains how that catalog metadata works. We support subtitles in several languages per title, separately from the audio.

The transcoding job does not produce thumbnail sprite sheets for scrubbing previews in the player timeline. Poster and thumbnail images are uploaded per title in the admin. If timeline previews are a requirement for your product, treat it as an enterprise scoping conversation rather than a setting, because it is not in the platform code today.

Changing the ladder applies to new jobs. Existing titles keep the renditions they were built with until their job is re-run, which consumes queue time and replaces the stored package. Plan ladder decisions before the catalog upload, and treat a later change as a project with a schedule, especially for large libraries where the queue will take days to work through.