Match the benchmark to the video you ship
An OTT catalog with 4K masters and a short video app with 1-5 mins videos represent different video infrastructure workloads. So, we tested four file shapes that fit different needs for a complete Video API ranking. The benchmark tool is open source, and we’ve called out where another platform beats us.
FastPix is video infrastructure for developers. This page is our numbers, and the tool that produced them.
What actually happens between upload and play
Four things happen to a video, in order. Every number on this page is a stopwatch on one of them.
It goes up
Your file travels from a laptop or a browser to the platform. With big files this is where platforms separate: sending the file in several pieces at once, and picking up again after the wifi drops, is the difference between 70 seconds and 157 on the same half-gigabyte lecture.
It gets encoded
The platform makes several copies of your video at different quality levels, from a small one for a phone on a train to a large one for a TV on fibre. That set of copies is called a ladder. Building a good ladder takes time. Building a cheap one saves time now and costs picture quality on every play afterwards.
It gets distributed
Those copies are pushed out to servers placed near your viewers, so the video does not have to travel from one place to everyone.
It plays
The player picks the rung of the ladder that suits the viewer's connection, and changes rungs as the connection changes. That is what adaptive bitrate means, and it is why a video can go soft for a moment on a train and then recover.
Why the differences matter
Steps 1 and 2 decide how long your team waits after hitting upload. You pay that once.
Steps 3 and 4 decide what your viewer gets, on every play, for as long as the video exists. You pay that forever.
Most benchmarks measure the first pair and ignore the second. A platform can win the clock by building a cheap ladder in step 2, and the bill for that arrives in step 4, where nobody is looking.
2x faster from upload to playable.
Independent benchmark across 5 leading video APIs on a 21-minute, 1080p H.264 source. That length that sits between different use cases, FastPix delivered the asset playback-ready in 83 seconds - the next provider took 142 seconds, and one vendor timed out entirely.
Why 83 seconds instead of 175
A 21-minute video is the shape a course platform or a webinar product handles every working day. Now when we consider 83 seconds versus 175 seconds, think about what an instructor is doing during that gap.
Nothing broke in either case. Only one of them feels like software that works.
The reason it matters more than it sounds: this is not one file. A course team uploads in batches, so a gap of ninety seconds per lecture becomes an afternoon across a semester's content, every term. That is friction and it is avoidable.
Find the workload that matches your product
File size and resolution moved the ranking more than anything else we tested, which is why a single benchmark number is close to useless. Find the row that looks like your library, and jump to that result.
| If you build | Your files look like | Tested with | Fastest to playable |
|---|---|---|---|
| Online learning, training, microlearning | 20 to 60 minute 1080p lectures | 467 MB, 21 min 31 s | FastPix, 82.9s |
| Connected fitness | 20 to 45 minute 1080p classes | Same 467 MB file | FastPix, 82.9s |
| OTT, entertainment, microdrama | 4K masters, watched for years | 167 MB 4K, plus 177 MB | FastPix, 34.5s |
| Short video apps | 1 to 3 minute 1080p clips | 96.6 MB | api.video, 23.6s FastPix 28.2s at 5.7 Mbps |
api.video reaches a faster time to playable on short videos, at an average rendition bitrate of 3.1 Mbps. FastPix clocks 28.2s but on average delivers 5.7 Mbps. The higher bitrate is because we prioritize playback quality over raw publishing speed. Read the SaaS section below for a more detailed takedown to understand what fits you best.
Long 1080p lectures
This is the one workload where the result is not complicated. FastPix was fastest on every measure taken here, and the reasons are worth walking through one at a time.
The file is 467 MB of 1080p, 21 minutes and 31 seconds. That is what course platforms, L&D teams and webinar products ship all day. The headline chart is above. Here is what sits underneath it.
Chunked upload sends the file in parallel parts and picks up again after a dropped connection. That is exactly where half a gigabyte over an office wifi connection starts to matter.
Per-title encoding reads the content of each video and builds a ladder suited to it, rather than running the same recipe over everything. A talking-head lecture and a concert film do not need the same treatment. It is more work per file, and it still finished first here: 21 minutes of 1080p in under eleven seconds.
The harness returned zero for Vimeo on this measure across every run, so we treat it as unmeasured rather than as a result.
If you are testing Gumlet on files this size, watch for readiness timeouts: it failed this workload.
Why a second and a half matters on a lecture
Cold time to first frame is how long a viewer waits between clicking play and seeing a picture, with nothing cached. At 1.81 seconds it registers as the video loading. At 3.46 seconds it registers as your site being slow.
The viewer does not blame the video platform, because they have never heard of it. They blame you.
It compounds in a course, because a learner does not press play once. They open a lesson, skip back to re-hear something, come back after lunch, and check a definition on their phone on the train. The same second and a half arrives every time.
Same file shape, same result
A 30-minute class is the same engineering problem as a 21-minute lecture, so we did not re-run it. Long-form 1080p, uploaded in batches, watched on phones, tablets and the screen in front of the bike. The numbers above apply directly. Three of them land differently for fitness.
Derived, not separately measured: the 467 MB result multiplied by twelve classes. Studios publish in blocks, so the per-file gap is the one that actually lands on a Monday.
A library refreshed every week
Studios record in blocks and publish on a schedule, so the per-file gap multiplies. At 83 seconds to playable a whole week of classes is ready before the titles are written, and the same asset then serves on-demand, as a live class, or on a 24-7 channel with nothing to move between them.
Starts fast on every screen
1.81 seconds to first frame on a cold cache. A member clips in, hits play mid-warm-up and expects the class to be there. A three-second wait is the moment they check their phone instead, and the session starts badly.
Long files are where compression pays
Per-title encoding produced 35 percent smaller files at matched visual quality against open-source baselines. A 45-minute class served ten thousand times is a meaningful share of your delivery bill, and this is the line item it comes off.
4K masters
We lose a chart in this section. It is the most interesting result on the page, so it is worth understanding before the wins: we are fastest to playable here and we deliver eight times the bitrate of one competitor, and we still come second on stability.
A catalogue is ingested once and served for years. Ingest speed is a cost you pay once. Delivered quality is something every viewer gets on every play. Both clocks, in one workload.
Most platforms slow down noticeably once the source is 4K, which is the point of testing at 4K rather than assuming.
+ Scoring detail
Upload score 100, against 79 and 52.
Read the stability chart below before comparing this one against the clock. The two are connected.
+ Scoring detail
Rendition bitrate quality score 100, against 55 and 19. On the separate 177 MB media file: FastPix 29.4s, api.video 49.2s, Gumlet 268.9s, with zero rebuffer events on all three.
Zero rebuffer events on all three platforms, and an overall score of 86 against 79 and 74.
This is where we lose. Under a deliberately squeezed 4G connection we stepped the quality down twice, where the others held steady. They were holding steady at 1.1 and 3.3 Mbps and we were pushing 9.0, so the comparison is less flattering than it looks. If you would rather ship a lower ceiling and never step down, another platform on this page fits that preference better than we do.
What 9.0 Mbps against 1.1 Mbps actually looks like
Bitrate is how much data per second reaches the player. It decides whether the video looks like the file you uploaded.
A 4K master arriving at 1.1 Mbps is worth sitting with for a moment: that is roughly what a DVD carried, and DVDs were 576 lines tall. You paid to store and process a 4K source, and what the viewer received was closer to standard definition with the detail smeared out of it.
At 3.3 Mbps a 4K source is watchable but visibly soft, in the way a slightly-too-compressed stream always is. Skin tones flatten. Anything with fast motion or fine texture, a crowd, rain, a pan across a city, breaks into blocks.
At 9.0 Mbps it holds together. For a catalogue business this is the difference between a subscriber saying your service looks good and a subscriber saying nothing at all, which is the outcome you want.
It is also the number nobody checks in a bake-off, because everyone is looking at the clock instead.
Short 1080p clips
Who wins here depends entirely on which clock your product is on. api.video is ready 4.6 seconds sooner. It also delivers 46 percent less bitrate to the viewer.
Break the 4.6 seconds into stages and it stops being one gap. We upload in 3.3 seconds against their 7.5, and we start for the viewer sooner. The whole difference sits in step 2, where the ladder gets built. api.video publishes sooner and trails us on every measure the viewer feels.
Gumlet posted the lowest number but completed only a few runs, so we do not treat it as a comparable result. api.video is fastest to publish and slowest to start. That is the whole story of this workload in one line, showing why no single metric is ideal for making the decision.
One detail worth noticing: for api.video and Cloudinary the top rung of the ladder equalled the average, meaning no higher quality level was served at any point in the window.
+ Scoring detail
Quality score 92, against 53 and 49. Startup score 100, against 87 and 67.
Average throughput was 29.7 Mbps against 7.3 and 16.0. Steady delivery is what keeps a video from stalling halfway through, and peak speed on its own does not do that.
Which of those two numbers is your problem?
If you're weighing up these two platforms, this is probably the trade you're actually deciding on, so it's worth spelling out. api.video finished the upload 4.6 seconds sooner. That's a wait your own team has, once, whenever someone uploads a clip.
FastPix starts playing half a second sooner. That's a wait your customers have, every single time one of them presses play. Put the demo on your pricing page, get fifty thousand views in a month, and you're paying that half second fifty thousand times. So you're choosing between saving a colleague five seconds and saving every customer half a second. Neither one is wrong. They're just very different sizes of problem.
There's a second difference, and it's about how sharp the video looks. We sent nearly twice as much picture data per second, 5.7 against 3.1. You'll spot it quickly on a product demo: at 3.1 the text inside your app goes fuzzy, and the mouse pointer smears when it moves. At 5.7 it stays sharp enough to read.
The third number is the one most people skip, and it's about how evenly the video arrives. We measured 24 percent variation in delivery speed, against 32 for api.video and 103 for Cloudinary. At 103 percent the speed was swinging wider than its own average from one moment to the next.
That unevenness is what makes a video stall halfway through. The player gets ahead of the download, runs out of video to show, and stops to wait. On a demo that's a bad moment to lose someone, because they had already decided to watch it and to be fair to api.video: if the thing that really slows your team down is getting clips live, they beat us on this file in every run.
The two columns, side by side
| Platform | To playable | Delivered | Cold start | What that combination means |
|---|---|---|---|---|
| api.video | 23.6s | 3.1 Mbps | 1.74s | Ready soonest, lowest bitrate, slowest to start for the viewer |
| FastPix | 28.2s | 5.7 Mbps | 1.29s | 4.6 seconds later, 84 percent more bitrate, fastest usable start |
| Cloudinary | 32.4s | 3.3 Mbps | 1.60s | Slowest to playable here, mid on both viewer measures |
Every workload, every platform
The sections above are ordered by the product shape they serve, which is an editorial choice we are making openly. This table is not ordered by anything. It is what the harness returned, including the rows where we come second, plus the one internal result, marked as internal.
| Workload and metric | FastPix | api.video | Cloudinary | Gumlet | Vimeo |
|---|---|---|---|---|---|
| 167 MB 4K, to playable | 34.5s | 82.2s | 42.6s | timed out | not tested |
| 177 MB media file, to playable | 29.4s | 49.2s | not tested | 268.9s | not tested |
| 467 MB 1080p 21 min, to playable | 82.9s | 175.0s | 142.3s | timed out | 177.5s |
| 96.6 MB 1080p, to playable, 4 runs | 28.2s | 23.6s | 32.4s | 2 of 4 done | 122.8s |
| 96.6 MB 1080p, cold first frame | 1.29s | 1.74s | 1.60s | 1.12s | not reported |
| 96.6 MB 1080p, delivered bitrate | 5.7 Mbps | 3.1 Mbps | 3.3 Mbps | not reported | not reported |
| 96.6 MB 1080p, throughput variation | 24% | 32% | 103% | not reported | not reported |
| 467 MB 1080p, encoding time | 10.7s | 14.3s | 16.5s | timed out | 87.4s |
| 167 MB 4K, peak bitrate | 9.0 Mbps | 1.1 Mbps | 3.3 Mbps | timed out | not tested |
| 167 MB 4K, playback stability | 75 | 100 | 100 | timed out | not tested |
| 1.46 GB master, to playable (internal, not from the public harness) | 2.8x faster | single comparison against the closest API-first platform | |||
How the benchmark runs, and how to run it yourself
The benchmark is open source. It uploads the same file to every platform, times what happens, and writes a report. Run it yourself and check our numbers. What it measures: upload time, encoding time, time to playable, time to first frame (cold and warm), segment throughput, and delivered bitrate. Platforms ship changes, so we re-run this benchmark and update the page.
Same file, same region, same network
Every platform receives an identical source from the same machine, in the same region, over the same connection, inside a single measurement window. Cold measurements are taken before any cache is warm, because a warm cache flatters everybody.
Four file shapes, deliberately
A 4K master, a 177 MB media file, a 21-minute 1080p long-form file and a 1 minute 20 second clip. Shape changed the ranking more than any other variable we tested, which is the reason one workload is never enough to decide anything.
Run it on your own file
Your content matters more than ours does. Clone the harness, point it at the platforms on your shortlist, and run each workload at least three times before you trust any figure, including every figure on this page.
Does more bitrate not mean a bigger bill?
Fair question, and the two claims on this page sound like they are fighting. We say we deliver more bitrate than the others. We also say our encoding makes files 35 percent smaller. Both are true, because they are different numbers.
Compression is quality per bit. Per-title encoding builds the ladder from the content, so a lecture gets a leaner one than a concert film, and the same picture arrives in fewer bits. That is where the 35 percent comes from, and it comes straight off the bill.
Delivered bitrate is the ceiling you allow when the connection is good. A platform capped at 3.1 Mbps has a smaller bill and a softer picture. That is a legitimate choice, and for some catalogues it is the right one. It is a choice, though, not an efficiency. We set the ceiling higher and let per-title encoding pay for it. If you would rather have the lower ceiling, you can cap the ladder, and we will show you where.
FAQ
Common questions about video API performance
What is the best video API for an online course platform?
On a 467 MB 21-minute 1080p lecture, FastPix was fastest to playable at 82.9 seconds. Cloudinary took 142.3, api.video 175.0 and Vimeo 177.5, while Gumlet timed out. FastPix also led upload, encoding and cold start on that same file. Longer 1080p video is the shape where the gap between platforms is widest, so a benchmark run on a short clip will not predict it.
Which video API handles 4K masters best?
On a 167 MB 4K source, FastPix reached playable in 34.5 seconds. Cloudinary took 42.6 and api.video 82.2, with Gumlet timing out. FastPix also delivered a 9.0 Mbps peak rendition where the others delivered 3.3 and 1.1. The tradeoff is stability: we stepped quality down twice under a squeezed mobile connection, where platforms delivering far lower bitrates held steady.
Which video API is fastest for short product videos?
api.video, on time to playable. Across four runs of a 96.6 MB 1080p clip it averaged 23.6 seconds, against 28.2 for FastPix and 32.4 for Cloudinary. FastPix led the viewer-facing measures on the same file: 1.29 seconds to first frame, 5.7 Mbps delivered, and 24 percent throughput variation. Which one matters depends on whether your bottleneck is publishing or playback.
Why does delivered bitrate matter more than time to playable?
Time to playable is a cost you pay once, at upload. Delivered bitrate is what every viewer receives on every play, for as long as the video exists. It also makes the timing comparable: a platform that finishes by building a cheaper ladder will always post a faster time, so the two numbers only mean something read together.