Platform capability
RTMP ingest for DynTube live streaming
Your encoder speaks RTMP. Browsers do not. This page documents the path between them: create a live stream, copy the Server URL and stream key exactly as your Dashboard shows them, publish from a compatible encoder, and let viewers watch over HLS in your own player.
RTMP in, HLS out
RTMP in
HLS out
Key stays private
The path
RTMP goes in, HLS comes out
Two different protocols do two different jobs, and confusing them is the most common reason a first broadcast appears to “work” but nobody can watch it.
RTMP is a contribution protocol. It is what encoding software and hardware use to publish a live feed to a receiving server, and it expects a server address plus a key that proves the sender is allowed to publish. It was never designed for a browser audience.
HLS is a delivery format. It breaks the incoming feed into segments a normal player can request over HTTP, which is what makes a live stream watchable on a phone, a laptop or a television without a plugin. DynTube sits between the two: your encoder publishes over RTMP, and viewers are given HLS playback.
Everything else on this page follows that split — you configure one side in your encoder, and you hand out the other side from the Dashboard.
Before you broadcast
What you need, and how the stream gets created
Ingest details are generated for a stream that exists. There is nothing to paste into an encoder until you have created one.
- 01
A live-capable account and the permission to manage streams
- 02
A compatible RTMP encoder on the machine doing the broadcasting
- 03
A new stream: name it, choose an ingest region, set its options
- 04
A region chosen for the encoder, not for the audience
- 05
Saved — now the stream has its own Connect details
Encoder setup
Configuring your encoder from the Connect tab
The Connect tab shows exactly two values, and the whole job is transferring both of them into your encoder without altering either one.
- Server URLRead-only, with a copy action
- The Connect tab presents the Server URL as a read-only field with a copy button next to it. Use the copy button. In your encoder this is the custom RTMP server address — in OBS, the “Custom…” service with the server field filled from this value.
- Stream keyMasked, revealable, with a copy action
- The stream key is masked by default. You can reveal it when you need to see it, and there is a copy action so you never have to. Paste it into your encoder’s stream key field exactly as displayed, including anything that follows it.
- In OBS, leave “Use Authentication” offOBS Custom service
- When you set OBS to the “Custom…” service and fill its Server and Stream Key fields from the Connect tab, leave OBS’s “Use Authentication” checkbox unticked — the credential is already carried inside the pair you copied. This is guidance for OBS specifically. On another encoder, fill in its own custom-RTMP server and key fields as that encoder documents them, and do not invent a separate username and password that the Connect tab never gave you.
- Copy exactly — do not assemble the address yourselfWhy this matters more than it sounds
- DynTube has more than one ingest shape. A stream on the New engine publishes to a fixed application on the server and its displayed key carries a trailing authentication segment; an older legacy stream instead addresses its own application on the server and shows a plain key. The two are not interchangeable, and a hand-built address will pair the wrong halves together. Copying both displayed values as-is is the only reliable method.
Encoder checklist
- Service set to a custom RTMP destination
- Server pasted from the Connect tab
- Stream key pasted from the Connect tab
- In OBS: “Use Authentication” left unticked
- On another encoder: its own custom-RTMP fields, no invented credentials
- Nothing retyped, nothing trimmed
During the broadcast
Starting, watching the state, and ending the stream
Publishing is what makes a stream live. The Dashboard reflects that state rather than causing it.
- 01
Start the encoder
- 02
Confirm the state in the Dashboard
- 03
Read the two tiles for two different things
- 04
End it from either side
The audience side
How viewers watch, and what happens afterwards
Viewer delivery is HLS, and the URLs for it come from the Dashboard. Recording is a separate, optional choice made per stream.
Your player
The Dashboard gives you a player URL for the stream, so the live broadcast is watched in the same player surface as the rest of your library rather than on someone else’s site.
HLS delivery
Embed on your own page
An embed snippet is provided so the stream can sit inside your own page. You copy it from the stream’s embed tab; there is nothing to write yourself.
Copy from the Dashboard
Direct URL
A direct URL is available for cases where you need to hand out a link rather than embed a player — an email, a chat message, a calendar invitation.
Share as a link
Recording is opt-in
Streams are not recorded automatically. Recording is a per-stream option, it is plan-gated, and when you enable it you select the eligible project the recording is stored in.
Per-stream, plan-gated
RTMP is not a viewing protocol
The ingest address exists for your encoder only. Viewers are never given an RTMP URL, and there is no RTMP playback path for an audience.
Ingest ≠ playback
Check the audience path yourself
Live status confirms the ingest side only. Once it shows live, open one of the Dashboard-provided URLs — the player or the direct URL — separately from your encoder machine and confirm the stream actually plays there before you send the link out.
Test it separately
Keeping it working, keeping it yours
Security and troubleshooting
Almost every failed first broadcast is one of four things, and almost every security question about RTMP comes back to a single value.
The stream key is a publishing credential
Anyone holding the key can broadcast to your channel. That is the whole security model of RTMP ingest, and it is why the Dashboard masks the key, requires a deliberate action to reveal it, and prints the warning next to the field. Keep it out of shared documents, screenshots, support tickets and screen shares, and give it only to the person or machine that is actually broadcasting.
When the encoder will not connect, check these in order
- Verify the exact pair. Compare the Server URL and stream key in your encoder against the Connect tab for this stream. Look for a leading or trailing space, a line break introduced by pasting, a truncated key, or a server and key taken from two different streams.
- Confirm the ingest region is reachable from the broadcasting machine. The encoder has to be able to reach the region you selected when you created the stream, so a restrictive corporate network or firewall can be one cause of a connection that never establishes.
- Confirm the encoder has actually started its output. A configured encoder is not a publishing encoder — check that streaming is running, not just that the settings were saved.
- Read the Dashboard status. Live status means the backend has observed your publisher; it is not a statement that every aspect of the ingest is definitively fine. If the encoder claims to be sending and the Dashboard does not show the stream as live, look between the two rather than at your player or embed.
When viewers cannot watch but the stream is live
If the Dashboard shows the stream as live, the backend has observed your publisher, so the next thing to examine is the audience side: check that viewers were given a playback URL or embed from the Dashboard rather than the ingest address, and that the page you embedded on is the page they are actually opening. A zero viewer count on a live stream is not itself a fault.
Questions
RTMP ingest questions
Which encoder should I use?
Any compatible encoder that lets you enter a custom RTMP server and stream key will do, which includes widely used software such as OBS. DynTube supplies the two values; your encoder supplies the feed. We do not claim compatibility with every encoder or capture device in existence, so if yours cannot accept a custom RTMP destination it is not a fit.
Can I build the ingest URL myself from my account details?
No — copy both values from the stream’s Connect tab instead. DynTube has more than one ingest shape: a stream on the New engine and an older legacy stream address the server differently and present their keys differently, so a hand-assembled address risks pairing the wrong halves. The Connect tab always shows the correct pair for the stream you are looking at.
Do I need to turn on authentication in my encoder?
In OBS, no — when you use the Custom service with the Server URL and stream key copied from the Connect tab, leave OBS’s “Use Authentication” checkbox unticked, because the credential is carried inside that pair. For any other encoder, follow its own custom-RTMP server and key fields as that encoder documents them, and do not invent a separate username and password: the Connect tab does not issue one.
What bitrate, resolution or keyframe interval should I use?
That is an encoder-side decision and depends on your source material and your available upload bandwidth, so we do not prescribe values here. Configure your encoder to what your connection can sustain and run a test broadcast before an announced event.
When does the stream show as live?
Publishing from your encoder is what makes the backend record the stream as live, and live status means the backend has observed your publisher. The stream detail page refreshes its live state and viewer count while it is open, so use the status there to confirm. We do not promise a specific propagation time, which is another reason to test before you announce. The viewer count is a separate reading: it reports the audience, so zero on a genuinely live stream is normal.
How do I end a broadcast?
Stopping your encoder closes the publisher session. A stream on the New engine can also be ended from the Dashboard with its authorised End Stream control, which disconnects the active publisher.
Can viewers watch over RTMP?
No. Viewer delivery is HLS, through the player, embed or direct URL the Dashboard provides. The RTMP address is only ever for your encoder.
Is my stream recorded automatically?
No. Recording is opt-in per stream and plan-gated, and when you enable it you choose the eligible project the recording is stored in. A stream with recording switched off leaves nothing behind when it ends.
What happens if someone else gets my stream key?
They can publish to your channel, which is why the key is masked in the Dashboard and carries a keep-it-private warning. Treat it as a credential: limit who holds it, keep it out of shared documents and screenshots, and contact support if you believe it has been exposed.
Run a test broadcast before you announce anything
Create a stream, copy the pair from its Connect tab, publish from your encoder, confirm the live status in the Dashboard and open a Dashboard-provided playback URL to check the audience path. Repeat those verified steps for future broadcasts.