How an RTMP live stream moves from encoder to viewer

An RTMP setup has two distinct paths. Your encoder sends one live contribution to DynTube using private ingest details. DynTube then prepares the viewer-facing stream for HLS playback. The ingest key authorises the broadcaster connection; it is not a viewer password.

What you need before opening OBS

Prepare these items first.

1. A DynTube account and plan where live streaming is enabled.
2. A live-stream record created in the current Dashboard.
3. The ingest server URL and stream key exactly as the authenticated stream details show them.
4. A stable upload connection with headroom above the total video and audio bitrate you intend to send.
5. A short test scene that contains no confidential customer or event material.

The route from OBS to the viewer

OBS or compatible encoder
  → private RTMP ingest
  → DynTube processing
  → HLS viewer playback

That separation explains two common surprises. First, a successful encoder connection does not by itself prove that the viewer page is ready. Second, changing viewer access rules does not replace the ingest credential. Test both sides.

The ingest pair: server URL and stream key

Every stream carries two values that belong together: an ingest server URL and a stream key. The pair is issued per stream and is visible only to an authenticated operator of that account. Treat them as one credential: a key from another stream will not work against this URL, and neither value is a viewer link. The RTMP live-streaming overview page carries the product boundary.

Copy the server URL and stream key exactly. Current-system stream keys can include an auth suffix after a question mark: it is part of the key value, not a query string to remove. Keep both values in a password manager or another access-controlled operational record during setup. Do not paste them into chat, tickets, public documents or analytics fields.

If the stream details show a deprecation notice, it is a legacy stream. Its server URL can end in the stream’s own application name, and its key does not use the current-system auth suffix. Use exactly the values shown for that record, and create new events on the current stream system.

Where the step-by-step setup lives

The indexed DynTube documentation guide to live streaming with OBS owns the current Dashboard and OBS procedure. Follow it for the exact connection tab, copy controls and OBS fields rather than relying on a duplicated checklist here.

Two details explain many connection failures: paste the complete stream key, including any current-system auth suffix, and leave the OBS authentication option off. The stream key carries the authorisation; DynTube does not issue a separate username or password for this connection.

OBS documents the server URL and stream key as separate connection information. A missing character, an extra space, or a key paired with the wrong stream is enough to prevent a connection.

Run a private end-to-end test

Test before announcing the event.

1. Start with a private test scene in OBS.
2. Start streaming and confirm OBS remains connected.
3. Reload the stream page and confirm its status reads live — a page still showing a scheduled state does not refresh itself.
4. Open the intended viewer experience in a separate browser context.
5. Confirm video and audio playback through the HLS viewer path.
6. Test the real device and network combinations that matter for the audience.
7. Stop the encoder and confirm the stream reaches the expected ended or idle state.

An encoder’s green status proves only its local view of the connection. The viewer test proves the delivery path users will actually experience.

Troubleshooting by symptom

Do not repeatedly retry with random encoder settings. Change one verified variable at a time and record the result.

Ingest security

The stream key must never appear in a public page, screenshot, recording or support post. If it appears in a public capture or recording, treat it as exposed and ask an authorised operator to rotate or replace it before the event.

Plain RTMP contribution is not encrypted in transit. Stream from a network you control, avoid unknown or shared network paths where practical, and replace the key if its handling or transport path becomes untrusted. Use an RTMPS scheme only when the authenticated stream details explicitly show it; the current DynTube Dashboard presents its own ingest as RTMP.

Event-day checklist

• Reconfirm the intended stream and its private ingest pair.
• Use a wired or otherwise qualified connection where practical.
• Close software that competes for upload bandwidth or encoder resources.
• Start a private pre-roll test early enough to correct a failure.
• Monitor both encoder health and viewer playback.
• Keep a fallback scene and an operator communication channel ready.
• Decide recording and replay behaviour separately: live-stream recording is opt-in and plan-gated, not automatic, and uses its own destination and replay lifecycle.
• Stop the encoder deliberately after the event and verify the final stream state.

Frequently asked questions

Is the RTMP stream key the same as viewer access?

No. The key authenticates the encoder’s ingest connection. Viewer authorisation is a separate server-side decision.

Does an OBS connection mean the live page is working?

No. Verify the HLS viewer path in a separate browser and on representative devices.

Should I publish my stream key so another presenter can connect?

No. Share it only through an access-controlled operational channel. Replace it if it becomes public.

Does DynTube record every live stream automatically?

No. Recording is an explicit, plan-dependent stream option, and it has its own destination and replay lifecycle.

Verification boundary

External encoder documentation explains how OBS accepts connection details. Your DynTube stream record remains the authority for the available ingest scheme, plan options and stream behaviour.