Video transcoding for OTT: the real ladder and codec defaults
Video transcoding for OTT on Flicknexs: default 720p, 480p and 360p H.264 ladder selectable up to 1440p, AAC audio and a monitored job queue on every plan.
Flicknexs transcodes each uploaded video into an adaptive-bitrate HLS ladder, H.264 by default with H.265, AV1 and VP9 selectable per job on request, through a queue with a monitoring dashboard and a job record for every file.
Trusted by industry leaders
50+ OTT platforms powered by Flicknexs
Quick answer: Video transcoding for OTT converts one uploaded file into a ladder of renditions at different resolutions and bitrates, packaged so a player can switch between them as the connection changes. Flicknexs transcodes every upload to a default 720p, 480p and 360p H.264 ladder with AAC audio, lets you select renditions up to 1440p, and runs jobs through a monitored queue.
Flicknexs provides video transcoding as part of its white-label OTT platform. Flicknexs transcodes each uploaded video into an adaptive-bitrate HLS ladder, H.264 by default with H.265, AV1 and VP9 selectable per job on request, through a queue with a monitoring dashboard and a job record for every file.
Why video transcoding for OTT decides both quality and cost
A file that plays fine on your editing workstation is the wrong file for a viewer on a train. Transcoding is the step that turns one source into several renditions the player can choose between, so a phone on a weak connection drops to a smaller version instead of stalling and a television on fiber stays sharp. Get the ladder wrong in one direction and viewers buffer; get it wrong in the other and you pay to deliver pixels nobody can see. Every operator makes this choice, whether they know it or not, because a default ladder is still a choice.
Flicknexs makes the choice visible. Each upload goes into a job queue and comes out as an HLS package with a master playlist listing the renditions. The default ladder is 720p, 480p and 360p in H.264 with a single AAC audio track, which suits the majority of catalogs and most of the audience on phones. The ladder is selectable up to 1440p when the source and the audience justify it. H.265, AV1 and VP9 can be selected per job on request, with an automatic H.264 fallback so no device is left without a playable rendition. Every job is recorded, and a monitoring dashboard shows the queue.
The engine behind almost all streaming transcoding is documented publicly. The FFmpeg documentation describes the encoders, the rate-control modes and the HLS muxer options that determine how a rendition is built, and the HLS specification published by the IETF as RFC 8216 defines the playlist and segment structure the output must follow. Reading the FFmpeg guide on H.264 encoding before choosing a ladder will save you from two common mistakes: encoding a higher resolution than the source contains, and using a bitrate that makes a small rendition look worse than the one above it.
What Flicknexs transcoding produces from each upload
Every row is in the platform code. The rows marked on request are selectable per job and fall back to H.264 automatically.
Default ladder
Three renditions at 720p, 480p and 360p are produced for every upload unless changed.
Selectable ladder
Renditions can be selected up to 1440p when the source and audience justify the bandwidth.
H.264 standard
Every rendition is encoded in H.264 by default, the codec every device app plays.
H.265, AV1, VP9
Selectable per job on request, with automatic H.264 fallback for devices that cannot decode them.
AAC audio
A single AAC audio track is produced per title, taken from the source file.
HLS packaging
Output is adaptive-bitrate HLS with a master playlist listing every rendition.
Job queue
Uploads enter a queue with a monitoring dashboard showing waiting, active and failed jobs.
Job record
Each job is stored in a table with its status, renditions and timing for later review.
Source: Flicknexs platform documentation and architecture specification, 2026-09-03.
How video transcoding for OTT works on Flicknexs
From the moment an upload finishes to the moment a title is playable, here is what happens and what the admin controls.
The upload becomes a job in the queue
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 ladder defines which renditions are produced
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.
H.264 is the standard codec, with alternatives per job
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.
Audio is a single AAC track
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.
Output is packaged as HLS with a master playlist
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.
Failures are visible and retryable
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.
How to set up transcoding in the Flicknexs admin
Five steps that start with your source files, because the ladder should never exceed what the sources contain.
- 1
Audit the resolution and bitrate of your sources
Before choosing a ladder, check what your masters actually are. A catalog of 1080p masters and a catalog of 720p screen recordings need different ladders. Write down the typical source resolution, frame rate and bitrate per content type. This ten-minute audit prevents the most common waste, which is encoding renditions larger than the source.
- 2
Choose the ladder per content type
Open the transcoding settings. Keep the default 720p, 480p and 360p for talking-head, lecture and news content. Add 1080p when masters are 1080p and the audience includes televisions, and consider 1440p only for fine-detail content with high-quality masters. Each added rendition adds storage and, on large screens, bandwidth, so note the tradeoff in your launch document.
- 3
Decide whether to request an alternative codec
If your device breakdown shows a large share of televisions and modern phones, ask for H.265, AV1 or VP9 to be selected on the jobs for your heaviest titles. The H.264 fallback is produced automatically, so older devices keep playing. Test one title first and compare the rendition sizes in the job record against the H.264 version before committing the whole catalog.
- 4
Upload a test batch and watch the dashboard
Upload five representative files and open the queue monitoring dashboard. Confirm each job moves from waiting to active to completed, note the time taken, and open the job record to read the rendition sizes. Play each title on web, on a phone and on a television app, throttling the connection once to watch the player step down the ladder.
- 5
Schedule the catalog upload around the queue
Plan large uploads in batches so the queue works through them before your launch date, using the time per job from the test batch to size each batch. Keep the dashboard open during the upload window and re-upload any failed source the same day. Record the final rendition sizes; they are the input to the bandwidth forecast on the video CDN page.
Limits and tradeoffs of Flicknexs transcoding
What ships standard, what is on request and what is not offered, stated plainly.
The ladder tops out at 1440p
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.
Alternative codecs are on request, not the default
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.
One audio track per title
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.
No thumbnail sprite generation
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.
Re-running a ladder change means re-transcoding
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.
A kids education service choosing its ladder
A worked example for a kids education service with a large library of short animated lessons and a smaller set of live-action science episodes.
The service holds three thousand animated lessons averaging eight minutes, produced at 1080p, and two hundred live-action science episodes at 1080p with a lot of fine detail. The device breakdown from a pilot shows tablets and phones dominate on weekday afternoons and televisions dominate on weekends. The team audits the sources, then keeps the default 720p, 480p and 360p ladder for the animated lessons because flat animation compresses well and the tablet audience never lands above 720p, and adds a 1080p rendition to the science episodes for the weekend television sessions.
Before uploading the catalog, the team runs a test batch of ten lessons and five science episodes through the queue, reading the time per job and the rendition sizes from the job records. The animated lessons come out small; the science episodes are several times larger at 1080p. They ask for H.265 to be selected on the science episodes on request, confirm that the H.264 fallback is produced, and compare sizes: the television sessions will use meaningfully less bandwidth on the devices that support the newer codec, which is most of the weekend audience.
The catalog upload is scheduled in batches of three hundred files over two weeks, with someone watching the monitoring dashboard each morning and re-uploading the handful of files that fail on a broken container. Every rendition size is recorded in a spreadsheet that feeds the delivery forecast on the video CDN page. Subtitles in two languages are added afterward as caption files per lesson through the video subtitles page, which does not touch the transcoding queue, so the caption work runs in parallel with the encoding.
Pre-launch checklist for transcoding
Ten checks to run after the test batch and before the full catalog upload.
- Source resolution, frame rate and bitrate are documented per content type, and no ladder rendition exceeds its source resolution.
- The ladder is chosen per catalog with the device breakdown in mind, and the reason for each added rendition is written down.
- A test batch of representative files has completed in the queue, and the time per job is recorded for scheduling.
- Rendition sizes from the job records are in the spreadsheet that feeds the bandwidth forecast on the video CDN page.
- Each test title plays on web, on a phone and on a television app, and steps down the ladder on a throttled connection.
- If an alternative codec was requested, one title has been compared against its H.264 fallback for size and playback on older devices.
- Audio levels on the single AAC track are consistent across titles, because the job takes audio from the source as delivered.
- Titles with more than one audio language are planned as separate titles with the audio language tagged in the catalog.
- The catalog upload is scheduled in batches with someone assigned to watch the dashboard and re-upload failed sources daily.
- Poster and thumbnail images are prepared per title, since the transcoding job does not generate timeline preview sprites.
How transcoding interacts with the device apps and monetization
The ladder you build is what every app plays and what every subscription and purchase costs you to deliver.
Every device app plays the same HLS package. The web player and the Android, iOS, Android TV and Fire TV apps read the master playlist and choose a rendition; the add-on Roku, Samsung, LG and Apple TV apps do the same when built. Television apps on fixed connections will sit on the highest rendition you offer, which is why adding 1080p or 1440p changes bandwidth far more for a television audience than for phones. When an alternative codec is selected on request, the automatic H.264 fallback is what older televisions and browsers play, so no app is excluded. The video CDN page turns rendition sizes into a delivery forecast, and the video subtitles page covers caption files that sit beside the package.
On the revenue side, pay-per-view prices on Flicknexs can be set per quality, which ties the ladder directly to the video paywall page: a title sold at a higher price for its 1080p rendition needs that rendition in the ladder, and a title sold at one price for every quality can use a leaner ladder. Subscription plans are priced flat, so the cost of serving each subscriber depends on which rendition their devices land on. Reading the device breakdown on the video analytics page before setting the ladder is the cheapest way to keep the delivery line proportional to the revenue each plan brings in.
Which plan includes transcoding
Standard layers
Transcoding is part of every plan. The default 720p, 480p and 360p H.264 ladder, the selectable ladder up to 1440p, AAC audio, HLS packaging, the job queue with its monitoring dashboard and the job record are all in the platform code and available from day one. H.265, AV1 and VP9 are selectable per job on request on any plan. What changes between plans is the storage that holds the renditions and the bandwidth that delivers them. F1 Standard is the web-only plan, with 300 GB of storage and 20 TB of bandwidth yearly; see our pricing page for current plan and pricing details. F1 Standard includes 300 GB of storage and 20 TB of bandwidth yearly for website streaming; see our pricing page for current plan and pricing details.
Pricing & billing
F2 Super includes 300 GB of storage and 20 TB of bandwidth yearly, and adds native Android and iOS mobile apps; see our pricing page for current plan and pricing details. F3 Premium includes 1 TB of storage and 10 TB of bandwidth monthly, and adds Android TV and Fire TV apps; see our pricing page for current plan and pricing details. F4 Enterprise includes 2 TB of storage and 20 TB of bandwidth monthly and adds dedicated support to everything in F3; Samsung, LG, Roku and Apple TV apps are add-ons on any plan. See our pricing page for current plan and pricing details. A larger ladder consumes more of the storage figure per title, so the plan choice and the ladder choice belong in the same conversation.
Annual savings
Yearly billing on F1 to F4 costs less per month than monthly billing; see our pricing page for current plan and pricing details. Plans are flat fees and Flicknexs takes no commission on your revenue; payment-gateway fees are between you and your gateway. See our pricing page for current plan and pricing details. There is no per-minute or per-job transcoding fee on any plan.
Conclusion: what to do next
Already on Flicknexs
If you already run on Flicknexs, open the job record for three of your most-watched titles and read the rendition sizes, then open the device breakdown in analytics. If televisions are a large share and you are on the default ladder, test a 1080p rendition on one title. If phones dominate and you added high renditions, consider whether they earn their storage. Either way, confirm every scheduled title shows completed in the dashboard.
Choosing a platform
If you are choosing a platform, ask each vendor for its default ladder, its maximum rendition, its default codec and what happens on a device that cannot decode an alternative codec. Ask whether transcoding is metered separately from the plan. Ask to see the job queue. A vendor whose answers are a marketing grid rather than numbers is asking you to trust a default you have not seen; the numbers on this page are the ones in the Flicknexs code.
Before a rights call
Read the companion pages before uploading the catalog. The video CDN page turns your rendition sizes into a bandwidth forecast against the allowance in each plan. The video subtitles page explains how caption files in several languages attach to a title without touching the transcoding job. The multi-language video page covers how dubbed versions are published as separate titles with tagged audio.
Frequently Asked Questions
Everything you need to know about transcoding on Flicknexs.
Yes. Transcoding to the default H.264 ladder, the selectable ladder up to 1440p, AAC audio, HLS packaging and the monitored job queue are in the platform code on every plan, and there is no per-minute or per-job fee. What differs between plans is storage and bandwidth, according to our pricing page.
The default ladder is 720p, 480p and 360p. Additional renditions can be selected up to 1440p when the source contains that detail and the audience watches on large screens. Flicknexs does not produce renditions above 1440p and does not produce high dynamic range output; this page claims only what the transcoding service builds.
H.264 is the standard video codec for every rendition and AAC is the audio codec. H.265, AV1 and VP9 can be selected per job on request; when one is chosen, an H.264 version is produced automatically so devices that cannot decode the newer codec still play the title without any change in the app.
It depends on source length, resolution, the ladder and whether an alternative codec was requested, so run a test batch and read the time per job from the dashboard rather than relying on a generic figure. Jobs run through a queue with set parallelism, which is why large catalog uploads should be scheduled in batches.
Yes. The queue monitoring dashboard shows failed jobs and the job record keeps the error, typically a broken container, an unsupported pixel format or a truncated upload. Re-uploading a corrected source creates a new job. Because failures are explicit, a launch checklist can confirm every title reached completed status.
Add it when your masters are 1080p and the device breakdown shows a meaningful television audience, because televisions land on the highest rendition offered. For phone-heavy audiences or 720p sources it adds storage and bandwidth without a visible gain. Test on one title and compare rendition sizes in the job record first.
No. Each job produces a single AAC audio track. A dubbed or alternate-language version is published as its own title with its audio language tagged in the catalog, which the multi-language video page explains. We support subtitles in several languages per title separately from audio.
No. The job does not produce thumbnail sprite sheets for scrubbing previews. Poster and thumbnail images are uploaded per title in the admin. If timeline preview thumbnails are a requirement for your product, raise it as an enterprise scoping conversation rather than expecting a setting.
The new ladder applies to new jobs. Existing titles keep their renditions until their job is re-run, which uses queue time and replaces the stored package. For a large library that is a scheduled project, so decide the ladder before the catalog upload and treat later changes deliberately.
On devices that decode them, yes, because H.265, AV1 and VP9 produce smaller files at similar quality. Devices that cannot decode them receive the automatic H.264 fallback at the usual size. The gain therefore depends on your device breakdown, which is why Flicknexs makes these codecs selectable per job on request.
Live streams are packaged as HLS in near real time for the same player and delivery layer, but they do not pass through the upload job queue that builds on-demand renditions. The ladder settings and codec choices on this page describe uploaded titles; rehearse a live event separately to confirm its quality.
Open the job record for a completed title; it lists the renditions produced with their sizes and timing. Multiply the size of the rendition most viewers land on by expected watch-hours, split by device, and compare with the allowance sentence for each plan as described on the video CDN page.