Video transcoding API
A video transcoding API converts video from one encoding to others through code. You send a source file or URL, and the service decodes it and re-encodes it into new codecs, resolutions, bitrates or containers, usually as a bitrate ladder for adaptive streaming and sometimes as MP4 downloads. Uploads from phones, cameras and editing tools arrive in every format; transcoding makes them compact and playable on every device. The API runs the encoder fleet, queues and retries, and reports results by webhook.
How does a video transcoding API work?
A job starts when your app submits a source: a direct upload or a URL the service can pull. The service probes the file first, reading its container, codec, resolution, frame rate, audio layout and color details, and rejects anything it cannot decode. It then decodes the frames and re-encodes them for each output.
For streaming, the outputs form a bitrate ladder of resolution and bitrate pairs, all with aligned keyframes so the player can switch between them cleanly. Long files are often split into chunks that encode in parallel across many machines and are then joined, which is why a cloud transcoder can finish a long file far sooner than one server would. The outputs are packaged as HLS or DASH segments or written as MP4. When the job finishes or fails, the API sends a webhook, so your app does not poll a status endpoint.
Transcoding API vs. running FFmpeg yourself
FFmpeg is the open-source engine under a large share of video tooling, and a few lines of it can produce a good ladder. Running it yourself means owning everything around those lines: servers or containers sized for upload spikes, a queue, retries when a job dies halfway, handling of odd inputs, packaging, storage layout, and a way to tell the app a video is ready.
A transcoding API keeps the encoding knowledge and removes the operations. You trade direct control over every flag for a maintained pipeline that scales with demand and reports through events. FFmpeg in-house tends to suit low, predictable volume with engineers who already know it, or highly custom outputs. Variable volume from user uploads is where self-run queues back up, because capacity is fixed and uploads are not.
What source files can a video transcoding API handle?
A transcoding API has to accept whatever users and editors produce. Common containers include MP4 and MOV from phones and cameras, MKV and WebM from screen recorders and browsers, and MXF from broadcast workflows. Inside them sit codecs from H.264 and HEVC to ProRes and other editing formats, with audio in AAC, Opus, PCM or surround layouts.
The awkward cases are usually details, not formats. Phone video often has a variable frame rate, which has to become a constant one for clean segments. Rotation is often stored as a metadata flag rather than in the pixels, so a transcoder that ignores it outputs sideways video. Older broadcast footage may be interlaced and need deinterlacing. HDR sources carry color metadata, such as HDR10 or HLG, that must be kept or mapped correctly, or the picture looks washed out. Audio can be missing, out of sync or in a channel layout players do not expect. A good API probes each file, handles these cases, and sends a clear error by webhook for files it cannot process.
How is a transcoding API priced?
Transcoding APIs bill per minute of video, but the minute they count differs. Some bill per source minute: one charge per minute uploaded, however many renditions come out. Others bill per output rendition, often weighted by resolution and frame rate, so a ladder of six rungs bills six times and a 4K rung bills more than a 360p one. AWS MediaConvert, for example, bills each output rendition separately. The same library can produce very different bills depending on which unit applies.
Codec and quality tier usually change the rate, since AV1 and high-motion presets use more compute. Transcoding is also only the first line. Each rendition becomes stored minutes or gigabytes, and each view becomes delivered minutes or gigabytes, so the ladder decided at transcode time shapes the storage and delivery lines for as long as the video lives.
How does the FastPix transcoding API work?
Transcoding on FastPix runs inside the On-Demand API rather than as a separate job service. You create an asset from a direct upload or a URL in S3, GCS, Azure Blob or any HTTPS location, and whole libraries move in bulk from other video platforms or S3 with the FastPix Migration Tool. FastPix profiles the source and builds a per-title ladder, with H.264 and HEVC (H.265) output as standard and AV1 available on request. Standard, Pro and Premium quality tiers go up to 4K with HDR10, Dolby Vision and HLG, and quality is measured with VMAF. Packaging is just-in-time CMAF for HLS and DASH, so playback can begin before every rendition has finished encoding. You can cap the maximum resolution at 720p, 1080p, 2K or 4K.
Webhooks fire on upload, encode and ready, signed with HMAC SHA-256. In-Video AI runs in parallel with the encode, not as a second job, and returns transcripts, chapters and moderation flags in one timestamped JSON. Thumbnails and posters render at any frame, size and format, as JPG, PNG or WebP, with fit modes including intellicrop, under the video's access policy. GIF previews, storyboard sprite sheets with a WebVTT track, clips and watermarks come from the same asset.
Encoding is counted once per source minute, whatever the ladder size, and Standard encoding is free at every resolution up to 4K. Pro and Premium tiers bill per source minute at their own rates. The renditions are then stored per rendition-minute and streamed per minute watched, which is why the resolution cap and the per-title ladder shape the bill. The free plan covers 10 videos, with no card.
