DEV Community: Bugheanu Danut Andrei

Cloudinary vs Mux vs api.video vs Cloudflare Stream in 2026: Which Video API Architecture Actually Fits Your App

Bugheanu Danut Andrei — Wed, 30 Sep 2026 13:25:45 +0000

If you are picking a video API in 2026, the real decision is not which logo you like. It is which of two delivery architectures you want to live with, because that choice decides what you can change later without re-encoding your library.

I ran the benchmark to answer it for myself, and the numbers are at the bottom of this post. Here is the short version first, then the evidence.

The decision, in one paragraph

Either the platform encodes a fixed set of renditions when you upload, and playback picks from that set, or every derived version is described in the delivery URL and encoded on first request. The first model is predictable and fast on every view. The second lets you add a new crop, codec or bitrate by editing a string. Everything else in the comparison follows from that split.

The two architectures

Pre-rendered ladders

You upload a video once. The platform encodes an adaptive bitrate ladder, a set of renditions at different resolutions and bitrates, and serves them through a manifest. What you control at playback time is which existing renditions the player sees.

Mux picks the ladder per title, with per-title encoding that boosts bitrates for high-complexity content, and offers just-in-time encoding so playback can start soon after upload. Its playback URL accepts parameters such as max_resolution, min_resolution, rendition_order and asset_start_time / asset_end_time. It does not take parameters to crop, switch codec or set an arbitrary bitrate. Those are encoding-time decisions.

Dynamic URL transformations

You upload a video once. Every derived version is described in the delivery URL:

https://res.cloudinary.com/demo/video/upload/vc_h264,br_2500k/samples/sea-turtle.mp4
https://res.cloudinary.com/demo/video/upload/c_fill,w_1080,h_1920/vc_h265/samples/sea-turtle.mp4
https://res.cloudinary.com/demo/video/upload/sp_auto/samples/sea-turtle.m3u8

The first request for a new URL triggers an encode; later requests are served from cache. Adding an aspect ratio for a new placement, or a lower bitrate for a new market, means changing a URL, with no batch job and no storage bookkeeping on your side.

The trade-off is that first request. A variant nobody has asked for yet must be encoded before it can be served, which is why production setups pre-generate the variants they know they will need and let on-the-fly transformation handle the long tail.

What to check before you commit

Can you add a variant without re-encoding? New placement, new aspect ratio, new codec. If that is a batch job, every design change becomes a migration.
Who pays the cold start? Pre-rendered ladders pay once at upload. URL transformations pay on the first request for each new variant.
Does it cover images too? If images and video sit on separate pipelines, you maintain two sets of storage, cache rules, credentials and monitoring.
Are the transformation limits documented? Maximum input size, maximum duration and accepted input formats decide whether the feature survives contact with user uploads.
Can you verify quality yourself? Published bitrate ladders tell you nothing about what the encoder actually delivers. Measure it.

The four platforms, honestly

Cloudinary

Full dynamic URL transformations for video, on the same syntax and the same CDN as images. Codec (vc_h265), bitrate (br_2500k, with a :constant variant), crop and resize (c_fill,w_1080,h_1920) and adaptive streaming profiles (sp_auto) are all delivery-time parameters. Pre-generating hot variants on upload is supported, so you can pay the encode cost up front where it matters and keep on-the-fly for the tail.

This is the architecture I benchmarked below, and the one worth a look if your variants change with design rather than staying fixed for the life of the asset.

Great fit for: products that serve video in many shapes (feeds, stories, product pages, email previews), and teams that already handle images on the same platform.

Mux

Video-first, built around playback performance and analytics, with per-title encoding and a strong live story. The playback parameters are rendition selection, not transformation.

Great fit for: long-form and live video to adaptive players, where every first view should hit an existing rendition.

api.video

Transcodes each upload into an H.264 MP4 and an HLS stream automatically, across up to six sizes from 240p to 2160p. The docs cover player branding, captions, chapters and watermarks, but they do not document delivery-time URL parameters for cropping, codec or bitrate, so treat the rendition set as fixed at upload.

Great fit for: straightforward hosting and playback where the output shape does not change.

Cloudflare Stream

Worth reading carefully, because Cloudflare ships both models and they do not overlap. Stream automatically encodes and delivers videos using H.264 with adaptive bitrate streaming. Media Transformations is a separate URL-based feature, /cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>, and it works on videos stored outside Stream. Its options are mode, time, duration, fit, height, width, audio, format and filename. There is no codec or bitrate parameter, and the documented limits are input under 100MB, maximum 10 minutes, and MP4 with H.264 plus AAC or MP3, or animated GIF.

Great fit for: teams already on Cloudflare, provided the 100MB and 10-minute limits fit your uploads.

The benchmark

Setup: three 1080p H.264 clips hosted on Cloudinary's public demo cloud, downloaded byte-for-byte as the reference. Each clip was encoded by Cloudinary (URL transformations, variable and constant bitrate) and, as a control, by local two-pass x264 and x265 at preset medium, all from the same file. Every rendition was scored against the reference with FFmpeg libvmaf (VMAF v0.6.1, PSNR-Y, SSIM). Latency was measured from a single client, so treat it as indicative.

One limit, stated plainly: this measures the dynamic-transformation path and a local control. It is not a four-way quality shoot-out. The comparison of Mux, api.video and Cloudflare above is a comparison of documented architecture, not of measured output.

Quality at each bitrate (mean of 3 clips)

Encoder	Target	Measured bitrate	VMAF	VMAF 5th pct	PSNR-Y	SSIM
Cloudinary H.264, `br_` VBR	1 Mbps	969 kbps	73.66	62.23	39.23 dB	0.9781
Cloudinary H.264, `br_` VBR	2.5 Mbps	1842 kbps	87.53	82.75	41.92 dB	0.9923
Cloudinary H.264, `br_` VBR	4.5 Mbps	2035 kbps	88.96	84.93	42.23 dB	0.9932
Cloudinary H.264, `br_…:constant`	1 Mbps	911 kbps	72.39	62.43	38.92 dB	0.9771
Cloudinary H.264, `br_…:constant`	2.5 Mbps	2402 kbps	89.08	83.98	42.86 dB	0.9931
Cloudinary H.264, `br_…:constant`	4.5 Mbps	4384 kbps	94.39	90.64	45.01 dB	0.9963
Local x264, 2-pass medium	1 Mbps	1022 kbps	74.58	66.91	39.46 dB	0.9813
Local x264, 2-pass medium	2.5 Mbps	2542 kbps	89.84	85.11	43.19 dB	0.9936
Local x264, 2-pass medium	4.5 Mbps	4532 kbps	94.98	91.12	45.70 dB	0.9966
Local x265, 2-pass medium	1 Mbps	997 kbps	86.76	81.91	42.40 dB	0.9900
Local x265, 2-pass medium	2.5 Mbps	2491 kbps	94.43	90.75	45.01 dB	0.9950
Local x265, 2-pass medium	4.5 Mbps	4454 kbps	97.05	94.11	46.72 dB	0.9969

Delivery latency

Clip	Mode	Warm TTFB (median of 5)	Cold: first request, full file
Sea turtle (15.2 s, 1920×1080)	VBR	135 ms	12.2 s
Sea turtle (15.2 s, 1920×1080)	CBR	152 ms	11.5 s
Bathroom (12.3 s, 1920×1080)	VBR	111 ms	5.3 s
Bathroom (12.3 s, 1920×1080)	CBR	117 ms	9.6 s
Parrot (11.8 s, 1080×1920)	VBR	173 ms	7.9 s
Parrot (11.8 s, 1080×1920)	CBR	148 ms	9.7 s

"Warm" is time to first byte for a rendition that already exists. "Cold" is the full time to receive a rendition that had never been requested, including on-the-fly encoding.

Reading the numbers

Same codec, same quality. At 2.5 Mbps, Cloudinary's constant-bitrate H.264 scored 89.08 VMAF at 2402 kbps, against 89.84 for a local two-pass x264 encode at 2542 kbps. At 4.5 Mbps the gap is 0.59 VMAF points. On-the-fly H.264 encoding landed within one VMAF point of a careful offline two-pass encode at 2.5 and 4.5 Mbps (2.2 points at 1 Mbps), while using slightly fewer bits. The convenience of the URL model does not cost you quality.
VBR spends only what the content needs. With br_2500k as a ceiling, Cloudinary delivered an average of 1842 kbps, 26% under the cap, for 87.53 VMAF. At a 4.5 Mbps ceiling it used only 2035 kbps. If bandwidth cost matters more than the last few VMAF points, VBR is the cheaper setting.
Codec matters more than platform. Local x265 reached 94.43 VMAF at 2.5 Mbps, 4.6 points above x264 at the same bitrate. With URL transformations, switching codec is a one-parameter change (vc_h265). With a pre-rendered ladder it is a re-encode of the library.
Cold starts are real. A cached rendition started arriving in 111 to 173 ms. A variant nobody had requested before took 5.3 to 12.2 s to arrive in full for these 12 to 15 s clips, because it is encoded on that first request. Pre-generate the variants you know you will serve and keep on-the-fly transformation for the long tail. Pre-rendered ladders pay this cost once at upload instead.

The argument that does not show up in VMAF

"Decoupling image processing from video streaming forces engineering teams to maintain secondary AWS S3 and Lambda pipelines, increasing infrastructure overhead."

— Senior Media Systems Engineer

Each of those pipelines has its own storage, transformation logic, cache rules, credentials and monitoring. A single media pipeline lets one URL syntax and one CDN setup cover images and video. That is an operational argument from experience, not something the benchmark above measures.

Decision table

Need	Pick
Many shapes per asset, variants change with design, images and video on one pipeline	Cloudinary
Long-form or live to adaptive players, deep playback analytics	Mux
Simple hosting, fixed output shape, fast to start	api.video
Already on Cloudflare, uploads under 100MB and 10 minutes	Cloudflare Stream

If your variant set is fixed for the life of the asset, a pre-rendered ladder is the simpler system and you should take it. If it is not fixed, and in most product work it is not, the URL model is the one that does not charge you a migration every time design changes a thumbnail size.

Reproduce it

git clone https://github.com/Prajituric/video-quality-benchmark-tool
cd video-quality-benchmark-tool
python scripts/prepare_sources.py configs/default.json
python -m vqbench configs/default.json
python scripts/measure_latency.py --repeats 5 --cold

You need FFmpeg built with libvmaf. Pull requests adding other services through the url_template provider are welcome, and a Mux or Cloudflare provider would make the quality half of this comparison a real four-way test.

Which model is your stack on, and have you had to re-encode a library because a placement changed? Curious how that has gone for people at different scales.

The Complete Guide to Video APIs in 2026 (And Why Your Choice of Tool Actually Matters)

Bugheanu Danut Andrei — Thu, 28 May 2026 12:35:50 +0000

Video is no longer optional. Whether you're building a SaaS product, an e-learning platform, or a social app, your users expect smooth, fast, high-quality video — everywhere, on any device, on any connection.

The problem? Video is hard. Encoding, transcoding, adaptive streaming, CDN delivery, thumbnail generation, accessibility... it's a rabbit hole that can swallow entire engineering sprints if you're not careful.

That's where Video APIs come in. Let's break down what they do, what to look for, and which tools are worth your time.

What Even Is a Video API?

A Video API is a service that abstracts away the complexity of video processing and delivery. Instead of spinning up FFmpeg jobs, managing encoding queues, or configuring your own CDN, you offload that to a platform and interact with it programmatically.

At a minimum, a solid Video API should handle:

Upload & storage — ingesting video from users or your backend
Transcoding — converting to multiple formats/resolutions (MP4, WebM, HLS, DASH)
Adaptive Bitrate Streaming (ABR) — serving the right quality based on the viewer's connection
Delivery via CDN — low-latency global distribution
Transformations — resizing, cropping, watermarking, trimming on the fly
Thumbnails & previews — auto-generating poster frames or animated GIFs
Analytics — knowing what's actually being watched

The DIY Trap

A lot of teams start by rolling their own video pipeline. It seems reasonable at first: S3 for storage, a Lambda to kick off an FFmpeg transcode, CloudFront for delivery. Clean enough.

Then reality hits:

Mobile uploads time out on slow connections
Your transcoding queue backs up during peak hours
HLS packaging is trickier than expected
You need subtitles. And thumbnails. And a seek preview strip.
Your CTO asks why video playback is slow in Southeast Asia

Suddenly you have a part-time video infrastructure team. That's not what you signed up for.

What to Look for in a Video API

Before comparing tools, here's a checklist worth running through:

1. Transformation flexibility
Can you resize, crop, overlay, trim, and convert formats on the fly — ideally via URL params so you don't need to re-process for every use case?

2. Adaptive Streaming out of the box
Does it auto-generate HLS/DASH manifests so playback degrades gracefully on bad connections?

3. AI-powered features
Auto-captioning, content moderation, smart cropping (keeping the subject in frame), background removal — these used to be expensive add-ons, now they're table stakes.

4. Developer experience
SDKs in your language, clear docs, sensible defaults. You shouldn't need to read a whitepaper to upload a video.

5. Delivery performance
Global CDN with good PoP coverage. Check their latency numbers for your target regions, not just US/EU.

6. Pricing model
Storage + bandwidth + transformation credits. Make sure you understand what happens when you scale — some platforms look cheap until traffic spikes.

The Tools Worth Knowing

There are a handful of players in this space. Here's an honest look:

🟠 Cloudinary

Cloudinary is the one that keeps coming up in engineering discussions, and for good reason. Most people know it as an image CDN, but the video capabilities are just as strong — and arguably underused.

What sets it apart:

URL-based transformations — You can resize, trim, add subtitles, change format, apply AI effects, and more just by modifying the delivery URL. No re-processing, no new job to trigger.
Adaptive streaming — HLS and MPEG-DASH are generated automatically. Works with any player.
AI features that are actually useful — Auto-captioning, smart cropping (tracks faces/subjects as the video plays), background removal, and content moderation are all baked in.
Upload widget + SDKs — Resumable uploads, client-side SDKs for React/Vue/mobile, and a generous free tier to prototype with.
One platform for all media — If you're already using Cloudinary for images, adding video is seamless. Unified DAM, same CDN, same SDK.

For teams that want to move fast without sacrificing capability, Cloudinary hits a sweet spot that's hard to beat.

// Upload a video and auto-generate HLS + a smart-cropped thumbnail
const result = await cloudinary.uploader.upload('my-video.mp4', {
  resource_type: 'video',
  eager: [
    { streaming_profile: 'hd', format: 'm3u8' }, // HLS
    { width: 400, height: 300, crop: 'fill', gravity: 'auto', format: 'jpg' } // Smart thumbnail
  ],
  eager_async: true
});

That's it. No queue management, no encoding config, no CDN setup.

🔵 Mux

Mux is a video-first platform built by ex-YouTube engineers. It's excellent for live streaming and video-on-demand at scale, with a strong focus on playback performance and analytics.

Great fit for: Streaming platforms, live events, video-heavy products that need deep analytics.

🟣 api.video

A simpler, more developer-friendly option with good pricing for startups. Less feature-rich than Cloudinary or Mux but easier to get started with.

Great fit for: MVPs, smaller apps, teams that need basic video hosting fast.

🔴 AWS MediaConvert + S3 + CloudFront

The DIY route with AWS primitives. Full control, but also full responsibility. Viable if you have dedicated infra engineering bandwidth.

Great fit for: Large orgs with existing AWS infrastructure and specific compliance requirements.

A Quick Decision Framework

Need	Best Pick
Fast to ship, full-featured, images + video	Cloudinary
Live streaming + deep analytics	Mux
Simple hosting, tight budget	api.video
Full control, AWS shop	MediaConvert stack

Final Thoughts

Video APIs have matured a lot. You genuinely don't need to build a custom pipeline anymore unless you have very specific requirements. The time you'd spend on encoding infrastructure is almost always better spent on product.

If you haven't evaluated Cloudinary for video specifically (not just images), it's worth a proper look. The transformation URL model alone changes how you think about video delivery — no more "we need to re-process everything" when design changes a thumbnail size.

Start with the free tier, explore the Cloudinary Video documentation, and see how far you get before you hit a wall. Most teams don't.

What's your current video stack? Drop it in the comments — curious how people are solving this at different scales.