Match the benchmark to the video you ship
A 4K master and a 90-second demo are different engineering problems, and the platform that wins one often loses the other. So instead of publishing a single ranking, we tested four file shapes and sorted the results by what you build. Everything here came out of an open-source harness you can point at your own files, and we have said where another platform beats us.
A 21-minute lecture, live in 83 seconds
This is the chart that matters most to us, so it goes first. The file is 467 MB of 1080p, 21 minutes and 31 seconds long, which is the shape a course platform or a webinar product handles every working day.
Why 83 seconds instead of 175
Think about what an instructor is doing during that gap. At 83 seconds they upload, write the description, and the lesson is already live when they hit save. At 175 seconds they have finished the description, refreshed twice, and started wondering whether the upload failed. Nothing broke in either case, but 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.
Want to check this? The benchmark harness is open source. Clone it, point it at your own lecture and your own shortlist of platforms, and you will get the same report we did.
Get it on GitHubFind the workload that matches your product
File size and resolution move 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 the 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, 1080p, 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 a 177 MB media file | FastPix, 34.5s and 29.4s |
| SaaS product video | 1 to 3 minute 1080p clips | 96.6 MB, 1080p, 1 min 20 s, four runs | api.video, 23.6s at 3.1 Mbps FastPix 28.2s at 5.7 Mbps |
| Broadcast and archive migration | Gigabyte masters, in bulk | 1.46 GB internal verification | FastPix, 2.8x faster |
api.video delivers a faster time to first frame on short videos, but at an average rendition bitrate of 3.1 Mbps. FastPix averages 5.7 Mbps, prioritizing playback quality over raw startup speed. The right tradeoff depends on how much viewer experience you're willing to give up for speed, and startup time is only one measure.
What a benchmark can and cannot tell you
Benchmarks are easy to misuse, and vendor-run benchmarks especially so. Your content, your regions and your traffic pattern all change the answer, so nobody can promise you these numbers on your own files. What a well-run benchmark can do is answer four questions, and every chart below answers one of them.
How long does the file take to get in?
That is upload time. It scales with file size, so a result on a short clip tells you very little about a 4K master.
How long until it is playable?
Upload plus processing, which decides whether your user waits after they hit publish.
How fast does playback start?
Cold time to first frame. Of everything on this page, it is the measure tied most closely to viewers leaving before the video begins.
What quality actually arrives?
Delivered bitrate, and this one is not optional. A platform that produces a smaller output finishes sooner, so time to playable only means something when you read it next to the bitrate that reached the viewer. On this page the two always appear together.
Long 1080p lectures
Verdict: FastPix was fastest on every measure taken on this workload. The file is 467 MB of 1080p, 21 minutes and 31 seconds, which 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 resumes after a dropped connection, which is exactly where half a gigabyte over an office wifi connection starts to matter.
Per-title encoding analyses the content and builds an encoding ladder for that specific video, and it still finished first here: 21 minutes of 1080p in under eleven seconds.
This is the number a learner feels. They click lesson four, and either it starts or they watch a spinner. 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 and two others in the same set.
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, when nothing is cached. At 1.81 seconds it registers as the video loading. At 3.46 seconds it registers as your site being slow, and 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
Verdict: a 30-minute class is the same engineering problem as a 21-minute lecture. Long-form 1080p, uploaded in batches, watched on phones, tablets and the screen in front of the bike. The numbers above apply directly, and three of them land differently for fitness.
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
Verdict: fastest to playable, and eight times the peak bitrate of one competitor. One stability cost. A catalogue is ingested once and served for years, so ingest speed is a cost you pay once and delivered quality is something every viewer gets on every play.
Upload score 100, against 79 and 52. Most platforms slow down noticeably once the source is 4K, which is the point of testing at 4K rather than assuming.
Rendition bitrate quality score 100, against 55 and 19. Read the box below before comparing this chart with the one beside it.
Zero rebuffer events on all three platforms, and an overall score of 86 against 79 and 74.
only second-place score, and the weighting explains it. Stability is 40% rebuffer count, 35% rebuffer ratio, 25% ABR quality drops. We took full marks on both rebuffer measures, so the whole gap is quality drops: on throttled 4G we stepped down twice from 9.0 Mbps while the others sat still at 1.1 and 3.3. A ladder capped at 3.3 has nothing to drop from.
What 9.0 Mbps against 1.1 Mbps actually looks like
Bitrate is how much data per second reaches the player, and 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, and 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
Verdict: api.video is ready 4.6 seconds sooner, and delivers 46 percent less bitrate to the viewer. Both of those came out of the same four runs, and neither one is the whole answer, so this section puts them next to each other and lets you decide which one your product actually cares about.
Break the 4.6 seconds into stages and it stops being one gap. We upload in 3.3 against their 7.5 and start for the viewer in 1.02 against their 1.74. The whole difference is processing, 24.0 against 14.8, where the encoding ladder gets built. api.video publishes sooner and trails us on every measure the viewer feels.
Startup score of 100, against 87 and 67. At 1.02 seconds we lead outright, on the one metric that repeats every play, for every viewer, for the life of the clip. Gumlet came closest at 1.12, but only completed two of four runs. api.video, fastest to publish, is slowest to start at 1.74.
Quality score 92, against 53 and 49. One detail worth noticing: for api.video and Cloudinary the peak rendition equalled the average, meaning no higher quality level was served at any point in the window.
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?
The 4.6 seconds api.video saves happens once, to somebody on your team, while they are already at their desk waiting for an upload. The half-second we save on startup happens to every viewer, on every play, for as long as the clip exists. If your product embeds a demo video on a pricing page seen fifty thousand times a month, one of those numbers is a rounding error and the other is not.
Bitrate lands the same way. At 3.1 Mbps a 1080p clip goes soft exactly where a product demo cannot afford to: the text in your UI blurs, and a cursor moving across a dashboard smears. At 5.7 Mbps the interface in your own demo stays legible. That is the actual stake, not a number on a spec sheet.
And one honest note in api.video's favour: if your bottleneck really is publishing latency, if a marketer uploads and needs the clip embedded in the next few minutes, they are measurably quicker on this file and you should weigh that properly.
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 start |
| Cloudinary | 32.4s | 3.3 Mbps | 1.60s | Slowest to playable here, mid on both viewer measures |
Gigabyte masters, in bulk
Verdict: 2.8 times faster at a gigabyte, and the gap widens as files grow. That came from a 1.46 GB internal verification against the closest API-first platform. Pipeline parallelism is the reason, and it compounds with size.
Moving a library
Batch migration runs on the same path as a single upload, so moving a catalogue is a queue rather than a project. The per-file gap is what decides whether that queue drains over a weekend or over a quarter, and the answer changes what the migration costs you in engineering time.
Finishing at all
One platform in this set timed out on the 4K master, on the 96.6 MB clip and on the 467 MB long-form file. At archive scale, a failure rate matters more than a few seconds of latency, because every failure is a file somebody has to find and re-queue by hand.
What you keep afterwards
35 percent smaller files at matched visual quality, measured against open-source H.264, HEVC and AV1 baselines. Applied across an archive that is a permanent reduction in what you pay to store and to serve, not a one-off saving at migration time.
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.
| 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 completed | 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 |
| 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 |
| 96.6 MB 1080p, processing time | 10.7s | 10.6s | 2.3s | 59.2s | 105.1s |
How the benchmark runs, and how to run it yourself
The harness is open source, and we would rather you checked than took our word for it. It uploads the same source file to each platform, then measures upload, processing, time to playable, cold and warm time to first frame, segment throughput and delivered bitrate, and writes a report.
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.
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, processing 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 against 42.6 for Cloudinary and 82.2 for api.video, 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 every viewer-facing measure 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, when the file is uploaded. 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 producing a lower-quality output will always post a faster time, so the two numbers only mean something read together.