What RTMP actually is
RTMP is the pipe. That’s genuinely most of what you need to know about it.
It’s a protocol from the Flash era that refuses to die, because it does its one job well: it takes an already-encoded video and audio stream and pushes it, over a single persistent TCP connection, to a server waiting for it. Every platform you’ve heard of accepts it. It has become the universal socket for “here is my show, please distribute it.”
Two things go into that socket:
- An ingest URL. The address of the server. YouTube’s primary is
rtmp://a.rtmp.youtube.com/live2. Most platforms also publish a backup ingest on a different host, worth noting if you ever need to fail over mid-event. - A stream key. A long random string that says which broadcast this is, and proves you’re allowed to publish to it.
You’ll also see RTMPS, the same protocol wrapped in TLS on port 443. Prefer it where offered. Plain RTMP on port 1935 tends to be blocked on corporate and hotel networks, which is exactly where you least want to be debugging.
RTMP is only the delivery leg. YouTube transcodes what you send into the ladder of qualities viewers actually watch, and distributes that. You are not streaming to your audience. You stream to YouTube, once, and YouTube handles the rest.
Where the YouTube stream key comes from
In YouTube Studio, go to Create → Go live. You land in Live Control Room, and the Stream tab shows the key and ingest URL together.
There are two flavours, and the difference bites people:
- The default “Stream now” key is persistent. Same string every time, so you save it once and forget it. Convenient, and riskier, because it stays valid until you reset it.
- Scheduled events can carry their own key, tied to that event. Copying last month’s key into this month’s event is a classic ten-minutes-before-air failure. You go live successfully, to a broadcast nobody is watching.
Some practical care with the key:
- It is a password. Anyone holding it can broadcast to your channel. Treat a leak as an incident: YouTube lets you reset the key, which instantly invalidates the old one.
- Never share your screen while the key is on it. This happens constantly. Set the stream up before the guests arrive. Blur is not a plan.
- Check the account. If you manage several channels, confirm the key came from the one you meant. There is no “move this broadcast” afterwards.
Check too that your channel is enabled for streaming at all. YouTube requires phone verification and imposes a waiting period the first time, historically around 24 hours. Discovering that on the day is a bad day.
Bitrate and resolution at 1080p30
For a talking-head show, interview or panel, 1080p at 30fps is the right target: sharp enough that text on a shared screen is readable, cheap enough that most home connections carry it comfortably. Reasonable numbers to plan around:
- Video: roughly 4,000 to 6,000 kbps for 1080p30 in H.264. YouTube’s published range is wide; the middle of it suits conversation content.
- Audio: 128 kbps AAC, stereo, 48 kHz. Don’t economise here. Audio is what people leave over.
- Keyframe interval: 2 seconds. Platforms segment on keyframes, so a long interval means slower start-up and messier quality switching.
The number that matters more than any of those is your upload headroom. Test your actual upload speed, not your download, which is the one your provider advertises, and plan to use no more than half to two-thirds of it. A 6 Mbps stream on a 7 Mbps upload will look fine for eleven minutes and then fall apart the moment something else on the network wakes up.
Frame rate is a real trade too. At a fixed bitrate, 60fps buys smoothness and spends detail. Right for gameplay, wrong for faces. Take the sharper 30.
Why you don’t need OBS or a capture card
Capture cards exist to get signal into your computer from a device that isn’t your computer: a camera with HDMI out, a console, a switcher. If your show is people on webcams talking to each other, there is no such signal. Nothing to capture.
Desktop encoders like OBS composite arbitrary sources and encode them locally. They are excellent, and they cost you three things:
- Your CPU. The machine hosting the conversation also encodes the stream, on the same thermal budget, while you talk.
- Your upload. Every destination is a separate outbound stream from your desk.
- A second operator, in practice. Driving scenes while interviewing someone is a skill, and not the one you were hired for.
A browser studio moves compositing and encoding off your machine. You arrange the layout in a tab; the composition and the RTMP push happen elsewhere; your laptop’s only job is your own camera and microphone. For a small talking-head show, that is strictly the better arrangement. The moment you need a hardware switcher, a hardware camera, or precise scene automation, go and get OBS. It is the right tool for that job and always will be.
Streaming to more than one place at once
Simulcasting to YouTube, LinkedIn and your own site is a reasonable thing to want, and the cost depends entirely on where the copies are made.
From your machine: each destination is a separate RTMP connection out of your building. Three at 5 Mbps is 15 Mbps of sustained upload, plus the call. Most home connections cannot do that, and the failure mode is all three degrading together.
In the cloud: you send one stream and the copies are made somewhere with a large pipe, so your upload cost stays flat however many destinations you add. This is what a browser studio does by construction, because the composed program is already being encoded away from your desk.
Two things either way. Each platform is a separate chat, so decide up front which one you’ll actually watch. And per-destination limits apply individually, so one platform capping you at 720p doesn’t drag the others down, and won’t follow them up either.
The ten minutes before you go live
Run this every time. It is boring, which is the point.
- Confirm the key belongs to today’s broadcast, not last month’s.
- Check the stream health indicator once you connect. Green, and stable for a minute, before you say a word.
- Set title, description, thumbnail, category and visibility now. Editing them live is possible and distracting.
- Decide latency and DVR settings. Lower latency makes chat feel natural; normal latency is more robust on shaky connections.
- Run an upload test and confirm the headroom you planned for.
- Get everyone plugged in and on ethernet where possible. Battery power throttles CPUs.
- Close everything else. Tabs, sync clients, notifications, anything that might pop a dialog over a shared screen.
- Check every guest’s camera and microphone in a green room, not on air.
- Turn on your recording, separately from the stream. A stream is a performance; the file is the asset.
- Have a plan for “the stream died.” Usually: reconnect, post the new link in chat. Knowing it in advance turns a disaster into thirty awkward seconds.
Doing it from one tab
Going live with FluentStage is a dialog rather than a setup. Paste a stream key, or add any RTMP host, and hit the button. Several destinations at once are toggles in that same dialog: YouTube, other RTMP hosts, an iframe embed on your own site, and a hosted public watch page. All of them are fanned out from one composed program at 1080p30, so adding a destination costs you no upload bandwidth.
What’s on stage is a real composition, not a shared screen of a call: seven layouts you can switch mid-show with nothing restarting, five overlay types at nine positions, a ticker, your background, accent colour and logo. Program edits reach the stream in about a second, so changing the layout is a production decision rather than a reason to stop. Guests join from a link, in a browser, with no account.
Recording during a broadcast is a separate toggle in the same dialog, ticked on purpose. The recording side captures every participant at 1080p on their own machine, which is a different and better file than a copy of your stream.
To put the show on your own domain as well as on YouTube, read embedding a live player on your site next.