Embed a live show on your own site

Two ways to get a player onto a page

There are two shapes, and the choice is about how much of the page you want to own.

An iframe is a rectangle of someone else’s HTML dropped into your own. You paste a few lines, control everything around it, and the player becomes a component in a page you designed. The right answer when the live video is part of something: a product launch page, a course module, a landing page with a signup form under it.

A hosted watch page is a complete public page someone else serves: player, title, cover image, share metadata, the lot. You get a link you can post anywhere. This is the right answer when you need somewhere to send people now and have no interest in building a page for it, which describes most first broadcasts, honestly.

The sensible pattern is both: the embed lives on the page you care about, and the hosted page is what you paste into an email or a social post.

A few things to get right on the iframe side, because they’re what people trip over:

• Wrap it in an aspect-ratio container. A fixed-height iframe will be wrong on every phone. aspect-ratio: 16 / 9 on the wrapper, width: 100%; height: 100% on the iframe, done.
• Check the embed permissions. The player needs allowfullscreen, and the serving side must not send X-Frame-Options: DENY or a restrictive frame-ancestors. Otherwise your page shows a blank box and the reason is buried in the console.
• Expect muted autoplay, or no autoplay. Every browser blocks autoplay with sound. A player that starts muted with an obvious unmute control beats one that refuses to start.
• Don’t lazy-load the player. People arrive expecting video. Make it the first thing that exists.

Why HLS, and what its few seconds buy you

Live video on the open web is mostly delivered with HLS, and understanding why makes the latency conversation much less annoying.

HLS chops the stream into short files, segments of a few seconds each, and publishes a small text manifest listing them. The player fetches the manifest, fetches segments, and plays them back to back, refreshing the manifest as new ones appear. That’s it. It is ordinary HTTP file delivery, so it rides on ordinary CDNs, works through corporate proxies, survives flaky mobile connections, and needs no special server holding a connection open per viewer.

The cost is latency. The player must wait for a segment to exist, download it, and keep a buffer of a segment or two so a hiccup doesn’t stall playback. That’s the familiar few-seconds delay, typically four to ten seconds behind the room, depending on segment length and how conservative the player is.

What you get in exchange:

• Scale that’s essentially free. Segments are static files. A CDN serving a hundred thousand people the same file is a solved problem.
• Adaptive quality. The player switches quality rungs between segments, so someone on a train drops a rung instead of dropping out.
• Robustness. The buffer absorbs jitter. A viewer with a two-second network stumble sees nothing at all.

Sub-second delivery does exist. That’s WebRTC, what the studio itself runs on. But it’s a far more expensive way to reach a large, passive audience, and it gives up the buffer that keeps bad connections watching.

Delay only matters when the audience can answer back. For a show with a chat, a handful of seconds is invisible; you just read the questions a beat later.

If your format genuinely depends on tight back-and-forth, as live auctions, betting and competitive gaming do, go and find sub-second delivery. For a broadcast, a webinar, a launch, or an interview, the buffer is doing you a favour.

What “unlimited viewers” does and doesn’t mean

A real claim, and a narrow one.

What it means: because segments are static files on a CDN, there is no per-connection cost that grows with the audience, and so no technical reason to sell tiers by concurrent viewer count. Ten people and ten thousand are the same operation. Nobody is locked out at the door for arriving late.

What it does not mean:

• Interactive features scale differently. Chat, polls, Q&A and reactions are per-connection, stateful and genuinely expensive. A player that scales freely doesn’t imply a chat that does.
• Your page still has to survive the traffic. The video comes from a CDN; the HTML around it comes from wherever you host. A launch that goes well can take out the page before it troubles the player.
• Your upload is unchanged. You send one stream regardless, which also means your own connection is still a single point of failure at the source.
• Attention isn’t distribution. An embed that can serve any number of people does not produce any number of people. That part is still your job.

The case for your own domain

Putting the player on a platform is easier. Putting it on your own site is worth the extra hour, for reasons that compound.

The page is an asset you keep. A URL on your domain accrues links, rankings and history. Add VideoObject structured data with the start time and, later, the replay, and search engines can render it properly. A platform page accrues all of that for the platform.

You see who came. Your analytics, your attribution, your email capture in the sidebar. On someone else’s page you get whatever aggregate they choose to show you.

No algorithmic middleman. Nothing sits between your announcement and your audience deciding whether this is the week your content gets shown.

The context is yours. Pricing under the player. A signup form. Related sessions. Your navigation. A platform page will only ever show their navigation, and a recommendation strip pointing away from you at the end.

The pragmatic play is both: stream to the platform for reach, and embed the same show on your own page for the audience you’re actually building. Same broadcast, so doing both costs nothing extra.

Planning the launch page

Build one page with one URL, and change what it contains over time. Do not build three pages.

Before. Cover image, a one-line description, and a start time with an explicit time zone: “15:00 UTC”, not “3pm”. Add a calendar link and an email capture, because the single most effective thing you can do for attendance is send a reminder an hour before. A countdown where the player will be makes the page feel alive rather than pending.

During. The player replaces the cover, same spot, same URL. Anyone who bookmarked it a week ago is now watching, with no redirect and no “click here to join.” Keep chat or Q&A immediately next to it, not below the fold.

After. The replay lives in exactly that spot. This is the step everyone skips, and it is where most of the total views come from. The majority of an audience for anything that isn’t breaking news arrives after the fact. Say it’s a recording, keep the description, add chapters or a transcript if you have them, and leave the URL alone forever.

Get your Open Graph tags right while you’re there: title, description, share image. Every announcement is rendered by someone else’s unfurl, and a broken preview costs more clicks than the copy wins back.

How it works here

FluentStage embeds are the same broadcast you send to YouTube, delivered as HLS from a CDN, in an iframe you paste onto your own page. No viewer cap, no separate embedding tier. The embed is one of the destinations in the Go Live dialog, alongside RTMP hosts and a hosted public watch page, so you can pick any combination of the three for the same show.

Scheduling gives you the launch page ingredients without building them: a cover image and a public page that exists before you go live, so there’s somewhere to send people while you’re still promoting it. When you go live, the player is already running on the page they bookmarked.

The show itself is a composed program rather than a screenshare of a call: layouts, overlays, a ticker, your background, accent colour and logo. Live edits reach viewers in about a second. For a registration-and-replay format, webinars covers that shape; for the streaming side, see streaming from your browser.