VMAF 93, scene by scene

The quality target: VMAF 93

Most compression is specified the wrong way round — pick a bitrate, accept whatever quality falls out. We do the opposite: we set a quality target and let the encoder find the smallest file that meets it.

The target is VMAF 93. VMAF (Video Multi-Method Assessment Fusion) is the perceptual quality metric developed by Netflix and USC; it scores 0–100 by modelling what human vision actually notices rather than counting pixel differences the way PSNR does. It is the industry standard for answering "will a person see the difference?" — and at 93 the answer is no: the stream is perceptually indistinguishable from the source at normal viewing conditions.

Targeting quality rather than bitrate is what makes the output size honest. The file is not "a bit smaller"; it is as small as it can be while still being indistinguishable.

Per-scene, not per-file

Here is where most pipelines stop and ours does not. A single encoding setting applied to a whole video is always wrong somewhere, because different scenes are not equally hard to compress. A static shot of a model against a plain wall needs a fraction of the bits of a fast pan across a patterned fabric. Encode the whole file at one setting and you either waste bits on the easy scenes or break quality on the hard ones.

Quinn encodes with variable resolution and bitrate across scenes within the same video, with each scene independently pushed to the smallest configuration that still hits VMAF 93. The result is that for any given video, the output is the minimum possible size at that quality bar — measured scene by scene, not averaged across the file.

This is the difference between a good compression setting and an optimal one, and across a library of short-form fashion video it is where the large reductions actually come from.

Delivery: faststart, over Cloudflare

A small file still starts slowly if it is packaged badly. Every Quinn video is written with faststart — the MP4 moov atom (the index the player needs before it can decode anything) is moved to the front of the file. Without it, a player must fetch to the end of the file before the first frame appears. With it, playback can begin as soon as the first bytes arrive.

Files are then served over Cloudflare's CDN, so the bytes come from an edge near the shopper, and below-fold video is lazy-loaded so nothing is fetched for a widget the visitor never scrolls to.

Why we use a single stream, not adaptive bitrate

Most video-commerce providers offer multi-stream adaptive bitrate (ABR) delivery, usually HLS or DASH, and treat it as a feature. We deliberately do not, and the reason is the specific shape of this use case.

Empirically, a shopper on a storefront watches 3–4 reels on average before moving on. That is a very different workload from a 40-minute film, and ABR is designed for the film.

1. ABR costs you time-to-first-byte

Before an adaptive player can request a single frame of video it must fetch and parse manifests — typically a master playlist and then a variant playlist. That is two sequential round-trips before the video even starts loading. With a single stream there is no manifest layer at all: the player requests the file and begins. On a short clip that a shopper may watch for four seconds, startup latency is the experience.

2. Quality oscillation is worse than consistent quality

ABR typically begins at a conservative quality and steps up once it has measured the connection. That means the opening moments — the only moments many shoppers see — are the worst-looking ones, followed by a visible jump. Quality-of-experience research consistently finds that viewers penalise switching heavily, and prefer a stable stream to one that fluctuates even when the fluctuating one has a higher average bitrate.

Over 3–4 short reels, adaptation never gets the runway it needs to pay off, and the viewer just sees the artefacts of it adapting. So we serve one stream, already small enough to start instantly, at a quality that does not need to change.

To be clear about the trade-off: ABR is the right architecture for long-form video, live streaming, and very wide network variability. It is the wrong architecture for a stack of short reels on a product page. We optimised for the case we are actually in.

Why this decides whether store video is worth it

• Largest Contentful Paint. A heavy video near the top of a page can become the LCP element and drag the metric — a ranking and conversion factor, not just a number in a report.
• Mobile data. Most storefront traffic is mobile, often on imperfect connections, where file size is the entire difference between playing and spinning.
• Shopify's own speed score. App performance shows up in your store speed report, and performance is part of what Shopify assesses for the Built for Shopify badge.
• Bandwidth at scale. Every byte saved is saved on every single view.

Verify all of it yourself

Every claim here is falsifiable. Install on the free plan and:

1. Compare transfer sizes. DevTools → Network → filter to media, then compare bytes transferred against the source file you uploaded.
2. Check the request waterfall. You will see the video requested directly, with no .m3u8 or .mpd manifest fetches ahead of it — that is the single-stream architecture, visible.
3. Run PageSpeed Insights before and after. Compare LCP, total blocking time and page weight with and without the widget.
4. Check Online Store → Themes → Store speed for the effect on your own storefront.
5. Look at the video on a phone. Put source and served stream side by side and examine the hard cases — fine fabric weave, hair, dark scenes, smooth gradients like skin or sky.

Why we built it in-house

Most shoppable-video apps are a widget layer on top of somebody else's transcoding service. That is a reasonable way to ship a product, but it caps how far compression can be pushed and puts quality tuning outside the vendor's control — you cannot set a per-scene VMAF target on an API you do not own.

We built the encoder because compression is the binding constraint in this category: it determines how much video a store can put on a page before speed costs more than the video earns. Owning it means the ratio keeps improving, and that quality can be tuned for the content that actually matters here — garments, skin, texture and motion.

The other half of store speed is the widget itself: how our Svelte components stay under 10 KB →

Questions