I built a transparent-video workflow for sites—what would make the embed trustworthy?

One angle I haven't seen mentioned: for me trust is less about the codec and more about the vendor. If I embed a hosted video on a client's homepage, my real question is what happens when the service pivots, gets acquired, or shuts down. A self-host export plus a clear line in the terms that my assets keep working if I cancel would do more for my trust than any compatibility table. Hosted-by-default is great for testing; production embeds need an exit plan.

Trust for me comes down to one boring thing: determinism. If the hosted URL keeps serving the exact same asset bytes and dimensions when I swap the source clip upstream, I would ship it; if it silently re-encodes, I would not. The self-host export mentioned above is the real unlock here — a single download-this-exact-embed-as-a-zip button turns AlphaPublish from a dependency into a safety net, which is what makes trying it cheap enough for client work.

We run a Next.js marketing site in seven languages and have looked at transparent motion a few times. The blocker is always payload -- a transparent WebM is easily 600-800 KB for a three-second loop, and above the fold that competes directly with LCP.

What I'd need before embedding: explicit dimensions in the embed code so lazy-loading doesn't cause layout shift (CLS). Responsive sources so mobile doesn't load the 1080p file. And the exit story -- if I self-host the output, do I also get the poster-frame generator and the codec-switching logic, or just the raw file? Rebuilding the embed layer is the real lock-in.

We're at DA 3 with four visits a month, so we can't justify testing things that might hurt Core Web Vitals. But one-step transparent embed removes enough friction that it's worth watching.

The thing that would make me trust it is proof it handles the Safari split. Transparent video on the web still means two files: WebM VP9 with alpha for Chrome/Firefox/Edge, and HEVC with alpha (.mov/.mp4, hvc1) for Safari and iOS. If the embed serves the right one automatically and I can see it tested on real iPhones, that removes the biggest worry.

After that, in order:

1. A fallback poster image (or a PNG/WebP sequence) when the video can't autoplay, like Low Power Mode on iOS or data saver.
2. Sensible defaults: autoplay, muted, playsinline, loop, and lazy loading below the fold.
3. File-size numbers per clip, plus a clear line on how edges look (halos around hair or soft shadows are where alpha usually breaks).
4. Stable URLs that don't change when I swap the source clip, and a self-host export so I'm not locked in if the service goes down.

If you publish a small compatibility table (browser, codec served, tested yes/no), I'd feel fine shipping it.

Have designers identified one production concern that would actually stop them from using the hosted embed—browser reliability, replacement URLs, performance, or something else?

Really solid approach — I'm juggling something similar myself (building Xstream4K on the side), what's been the hardest part for you so far?