YouTube HLS Ingest vs RTMPS Checklist for StreamableRun Cloud OBS

The current answer

For most StreamableRun Cloud OBS streams going to YouTube, RTMPS is still the default output to test first. It is encrypted, familiar to OBS-style workflows, and YouTube's own ingestion comparison says RTMP and RTMPS are suitable for normal, low, or ultra-low latency live streaming. HLS is worth testing when the stream is YouTube-focused and needs higher quality, higher resolution, HEVC, HDR, or another HLS-specific path more than it needs the lowest possible latency.

Google's YouTube Live Streaming API docs were updated on June 1, 2026, and the ingestion comparison is clear: YouTube supports RTMP, RTMPS, HLS, and DASH; HLS and DASH are encrypted, support advanced codecs, and are better suited for 4K or high-resolution streaming, but have higher latency. YouTube's HLS setup page says HLS is for HDR or codecs not supported by RTMP and that the ultra-low-latency option is turned off when HLS is chosen.

The operator move is not to argue about which protocol is cooler. Put the final decision in StreamableRun. Keep the source contribution stable, build the show in Cloud Hosted OBS, and test the YouTube destination privately as RTMPS first, then HLS only if the show has a real reason.

Why this matters now

YouTube's live docs are getting more explicit about the split between low-latency RTMP/RTMPS and higher-quality segment-based HLS or DASH ingestion. That matters because many streamers are now mixing IRL contribution, Cloud OBS, multi-destination output, 4K cameras, HDR cameras, and YouTube-first archives. The right output is not always the same for every destination.

If you are doing a Twitch, Kick, and YouTube multistream from Cloud OBS, a YouTube-only HLS profile might create more trouble than value. If you are doing a YouTube-only event with 4K, HDR, or a camera workflow that benefits from HEVC, HLS may be worth a controlled test. The key word is controlled. Do not change the output protocol during a public stream because a setting looked better in a help doc.

• RTMPS is the starting point for normal YouTube streams that need low latency and simple OBS-style output.
• HLS is the test path for YouTube-focused high-quality, high-resolution, HEVC, or HDR events.
• HLS is not the right choice when ultra-low latency is the main promise.
• Multistreams should use the profile every destination can handle, not the most advanced YouTube-only path.
• Cloud OBS should keep a known-good RTMPS profile saved before HLS experiments start.

RTMPS is the boring default for a reason

YouTube recommends RTMPS as a secure extension to RTMP and says it encrypts live streaming data into and through Google's servers. For most Cloud OBS shows, that is enough: H.264 output, 2-second keyframe interval, CBR, normal resolution, normal latency settings, and a platform preview that appears quickly. It is easy for producers to understand and easy to roll back.

RTMPS is especially attractive for IRL streams where the field side is already the risky part. If Moblin, IRL Pro, LiveU, SRT, SRTLA, a camera app, or a hardware encoder is sending into StreamableRun from unstable conditions, do not add output complexity unless it solves a real problem. Let Cloud OBS stabilize the show and output a normal YouTube stream.

RTMPS also keeps the producer workflow closer to Twitch and Kick profiles. That is useful for teams that run several destinations and need a shared runbook. One output profile per destination is fine, but every extra path needs monitoring and rollback.

• Use RTMPS for normal interactive streams, IRL shows, talk streams, and mixed-destination output.
• Use RTMPS when the team needs low or ultra-low latency more than 4K/HDR output.
• Use RTMPS when producers need a familiar profile they can troubleshoot quickly.
• Use RTMPS when the source route is new and you do not want to change source and destination at once.
• Keep YouTube's stream key and destination details in StreamableRun, not on every field device.

When HLS is worth testing

YouTube's HLS help page says HLS can be used to stream HDR or codecs not supported by RTMP, and its developer docs describe HLS ingestion as a good fit for premium content that requires high quality and high resolution at relatively higher latency. The same docs list media requirements: muxed audio and video in M2TS, H.264 or HEVC video, up to 60 fps, closed GOP, AAC audio, and specific HDR requirements when HDR is used.

That makes HLS useful for a narrower class of streamer productions: YouTube-first concerts, stage shows, long-form events, travel premieres, high-quality camera streams, or anything where the YouTube archive quality matters more than chat feeling instant. It is less attractive for a fast IRL stream where the streamer is reading chat while walking.

Test HLS only after the source, scenes, and fallback are already stable. If the show is still struggling with mobile signal, audio sync, or producer handoff, HLS is the wrong problem to solve first.

• Good HLS test: YouTube-only or YouTube-first show with high-resolution or HDR goals.
• Weak HLS test: Twitch/Kick/YouTube multistream where every platform needs the same output shape.
• Good HLS test: producer has time to check YouTube preview, archive, latency, and viewer devices.
• Weak HLS test: streamer wants live chat responses to feel as fast as possible.
• Good HLS test: the team has a saved RTMPS rollback profile in StreamableRun.

Latency tradeoff

YouTube's latency help page says lower latency means less read-ahead buffer, which can make viewers more likely to feel issues between encoder and player. It describes normal latency as best for non-interactive streams, low latency as a good balance for limited interaction, and ultra-low latency for highly interactive streams, with higher buffering risk. That already tells you why HLS should not be the reflex choice for a chat-heavy stream.

HLS adds another layer to that choice. YouTube's HLS setup page says HLS has higher latency because it sends video segments instead of a continuous stream like RTMP. Google developer docs also describe HLS as segment-based. For a YouTube event where quality matters more than chat timing, that trade can be fine. For a streamer asking chat where to go next while walking, it is probably wrong.

StreamableRun helps separate source latency from platform latency. The field source can use SRT or another ingest route into Cloud OBS. The final output can be RTMPS or HLS depending on the destination. Do not force one latency decision to do every job.

• Interactive IRL stream: RTMPS and a low-latency YouTube setting usually fit better.
• High-quality YouTube event: HLS can be tested if higher latency is acceptable.
• Producer monitoring: use StreamableRun preview plus platform preview, not chat timing alone.
• Fallback behavior: test how long viewers see fallback changes under each YouTube latency mode.
• Viewer devices: check desktop and mobile, because latency and buffering complaints can differ.

Cloud OBS test path

Build the test in StreamableRun like a destination dry run. First, create or duplicate the Cloud OBS profile you normally use. Second, send the normal source into the normal scene. Third, set the YouTube destination to RTMPS and run a private stream. Fourth, save the result: preview behavior, latency, audio sync, fallback, return from fallback, and archive behavior. Only then create an HLS test destination or profile.

For HLS, follow YouTube's requirements instead of guessing. Segment duration between 1 and 4 seconds, TS segment format, rolling playlist limits, HTTPS POST/PUT, supported codecs, and closed GOP requirements all matter for encoder vendors and advanced setups. If your Cloud OBS output UI hides some of those details, that is a sign to test carefully and use the platform preview as the truth.

Do not put the HLS test directly on the public event. Use an unlisted or private test where possible. If the public event needs the same stream key, schedule a rehearsal window with the exact key and destination settings before promotion.

• Baseline RTMPS: private output, normal scenes, fallback, and archive check.
• HLS setup: create a YouTube HLS stream key or preset, then test exact output requirements.
• Fallback drill: switch to fallback, hold it, then return to main while watching YouTube preview.
• Audio drill: verify stereo, sample rate, sync, and silence recovery after reconnect.
• Rollback drill: producer switches back to RTMPS without touching field devices.

Multistream reality

A YouTube-only HLS decision should not leak into Twitch and Kick. Kick's current setup guide centers on H.264, CBR, 1080p output, and a 2-second keyframe interval. Twitch has its own recommendations and Enhanced Broadcasting path. Custom RTMP destinations may be stricter than both. If the stream is going to three places, the shared output has to serve all three or be split intentionally.

In StreamableRun, keep destination ownership clear. One source can feed Cloud OBS. Cloud OBS can send one normal output to Twitch and Kick while a YouTube-specific output is tested separately if the workflow supports it. If the team cannot monitor both output behaviors, do not run both for a paid event.

The production question is not whether HLS is better than RTMPS. It is whether the added YouTube-specific quality is worth the latency and operational cost for this show.

• Do not copy a YouTube HLS profile into Kick or a generic custom RTMP destination.
• Keep destination notes separate: protocol, codec, bitrate, keyframe interval, latency, and rollback.
• Use one shared conservative output when producers are short-staffed.
• Use separate outputs only when the team can monitor and recover each one.
• After the event, compare viewer complaints, archive quality, and producer workload before making HLS standard.

Best default workflow

For most serious streamers, the best default is StreamableRun receiving the field or studio source, Cloud Hosted OBS running the scenes and fallback, and RTMPS sending the YouTube output unless the stream has a specific HLS reason. That keeps the show recoverable and understandable for remote producers.

When HLS is needed, treat it like a production feature. Give it a profile name, source notes, destination notes, test results, and rollback. If it passes, use it for the right YouTube-first show. If it does not, keep the RTMPS profile and move on. The audience never asked for a protocol debate. They asked for a stream that looks good, sounds right, and keeps going.

• Default source path: Moblin, IRL Pro, LiveU, hardware encoder, local OBS, or camera app into StreamableRun.
• Default production path: Cloud OBS scenes, overlays, audio, fallback, and producer control.
• Default YouTube output: RTMPS unless high-resolution, HEVC, HDR, or YouTube-only needs justify HLS.
• Advanced path: HLS only after private testing with a saved RTMPS rollback.
• Producer handoff: one note that says which YouTube protocol is live and why.

Other resources

Use these pages to verify current YouTube ingest protocol behavior, HLS requirements, latency tradeoffs, platform-specific output limits, and StreamableRun production features before changing a Cloud OBS destination.