Enhanced RTMP Checklist for HEVC, AV1, HDR, and Cloud OBS Outputs

What Enhanced RTMP changes

Enhanced RTMP matters because it modernizes an ingest path streamers already know. The Veovera Enhanced RTMP v2 spec describes updates to legacy RTMP and FLV that add support for newer media codecs, HDR capability, and related metadata while trying not to break established clients. Veovera's own intro says the work adds guidelines for AV1, VP9, HEVC, and HDR color metadata, with input from groups including YouTube, Twitch, Adobe, OBS, FFmpeg, VideoLAN, and Intel.

That is real progress, but it does not mean every Cloud OBS output should switch away from H.264 today. Protocol support, encoder support, platform support, viewer support, clips, VODs, monitoring, and fallback all have to line up. OBS added AV1 and HEVC streaming over Enhanced RTMP in OBS 29.1, with YouTube called out as the enabled beta destination at that time. YouTube's current encoder guidance lists H.264, HEVC, and AV1 for RTMP/RTMPS streaming, while Kick's current help still centers on H.264 settings.

The practical answer is to use Enhanced RTMP as a tested destination option, not as a personality. For most Twitch, Kick, YouTube, and custom RTMP multistreams, StreamableRun should keep a conservative H.264 output unless the show has a clear reason to run a newer codec path and a private rehearsal proves it.

Do not treat codec support as destination support

The common mistake is seeing HEVC or AV1 in one tool and acting like the whole stream now supports it. A Cloud OBS instance can encode something. A protocol can carry it. A platform can accept it. A viewer can play it. A clips tool can handle it. Those are separate gates. If one fails, the stream can look fine in your local preview and still be wrong for the audience.

YouTube is the platform where this is most interesting for streamers because its docs list H.264, H.265, and AV1 for RTMP/RTMPS, plus bitrate ranges by ingestion codec. It also recommends RTMPS for encrypted transport and notes that HDR over RTMP(S) should use H.265, while AV1 is not supported for HDR. Kick's current help, by contrast, describes H.264 encoder settings and bitrate guidance up to 8,000 kbps. Twitch has its own broadcast guidance and Enhanced Broadcasting path. A custom RTMP endpoint might accept only the oldest H.264 assumptions.

If you are sending to multiple platforms, the least flexible destination usually decides the shared output. You can still run a YouTube-specific destination separately from StreamableRun, but do not let it break the Twitch or Kick output.

• Codec support means the encoder can produce the stream. It does not prove the destination accepts it.
• Protocol support means the container or ingest path can carry it. It does not prove clips, VODs, or viewers behave.
• Platform support can be codec-specific, latency-specific, resolution-specific, or HDR-specific.
• Multistream support means every destination in the set must survive the output profile.
• Producer support means the team can monitor, fallback, and roll back without guessing.

When HEVC is worth testing

HEVC is worth testing when the show is high resolution, YouTube-focused, HDR-focused, or bandwidth constrained in a way that H.264 cannot solve cleanly. YouTube's current guidance gives lower recommended bitrate ranges for AV1 and H.265 than H.264 at the same resolution and lists H.265 for HDR over RTMP(S). That can matter for a 1440p or 4K event, a polished camera feed, or a creator who cares about YouTube VOD quality.

For IRL and mobile contribution, be careful. A better final codec does not fix a bad field source. If the camera is coming from a phone in weak signal, SRT/SRTLA contribution quality, source bitrate, battery, and Cloud OBS fallback may matter more than HEVC output. The newer codec should be tested at the output layer after the contribution path is stable.

In StreamableRun, the practical test is to keep the source route the same and change only one destination output privately. If YouTube HEVC works, the producer should still have the H.264 output profile saved. If clips, monitoring, latency, or HDR look wrong, rollback should be boring.

• Test HEVC for YouTube-specific quality, HDR, or higher-resolution events.
• Keep H.264 as the fallback for mixed Twitch, Kick, YouTube, and custom RTMP outputs.
• Do not test HEVC and a new source at the same time. Change one variable.
• Check clips, VOD, DVR, preview, and mobile playback after the private test.
• Have the producer confirm rollback from Cloud OBS before the public event.

When AV1 is worth testing

AV1 is attractive because modern hardware encoders can make it practical, and YouTube lists AV1 as a live ingestion codec for RTMP/RTMPS. But AV1 should be treated as a planned output choice, not a default for every streamer. The more destinations you add, the less likely AV1 is the shared answer. The more fragile the source is, the more you need operational recovery before codec experiments.

Test AV1 when the stream is YouTube-focused, the Cloud OBS instance has hardware support you can verify, and the team has time to compare it against a known H.264 or HEVC profile. Look at encoder load, dropped frames, start time, preview behavior, chat-reported playback issues, archive behavior, and whether the producer can read failure state quickly.

Do not use AV1 because it feels current. Use it because a private test showed a real improvement for the specific show. If the show is a crowded-venue IRL stream with shaky source bitrate, H.264 from a stable Cloud OBS profile may be the more professional answer.

• Good AV1 test: YouTube-only or YouTube-first stream, supported encoder, private rehearsal, clear rollback.
• Weak AV1 test: last-minute multistream, unknown GPU, unknown viewer devices, no platform preview time.
• Measure startup, audio sync, encoder headroom, destination acceptance, and archive behavior.
• Keep a normal H.264 profile ready for paid events and mixed destinations.
• Tell producers which profile is experimental so nobody promotes it by accident.

HDR needs its own plan

HDR is not just a brighter checkbox. YouTube's encoder docs say HDR video codec is H.265, AV1 is not supported for HDR, bit depth is 10-bit for HDR, and color space is Rec. 709 for SDR. YouTube's HDR page adds requirements like HEVC, 10-bit color, BT.2020 primaries, PQ or HLG transfer, and HLS output requirements for hardware encoders. That is a lot of surface area for a live show.

Before you use HDR in Cloud OBS, answer three questions. Does the source really produce clean HDR? Does Cloud OBS preserve the intended color settings through the scene collection, browser sources, and output? Does the destination and viewer path show it correctly? If any answer is vague, run SDR for the public show and keep HDR as a private test.

HDR mistakes are ugly because they can look washed out, too dark, or inconsistent. A producer watching one monitor may not see what mobile viewers see. Use normal viewer devices during rehearsal, not only the production preview.

• Keep SDR as the default unless the event has a real HDR reason.
• Verify source color, Cloud OBS canvas, encoder profile, destination mode, and viewer devices.
• Do not mix random SDR overlays into HDR scenes without checking how they look after output.
• Use a private YouTube test if the HDR route is YouTube-specific.
• Rollback to SDR if the producer cannot explain how to confirm the HDR path.

StreamableRun output test matrix

A useful Enhanced RTMP test in StreamableRun changes one thing at a time. Keep the same field source, same Cloud OBS scenes, same audio layout, same overlays, and same private destination. First run the known H.264 profile. Then test HEVC or AV1. Then test HDR if that is part of the plan. Each test should include start, stop, reconnect, fallback, return from fallback, destination preview, and archive check.

Use a table in the producer notes. Profile name, codec, bitrate, resolution, keyframe interval, destination, latency mode, expected use, pass or fail, rollback profile. Without that table, the team will eventually forget which profile was the good one.

The most important row is fallback. When the source drops, Cloud OBS should switch to a scene that the destination accepts under the same output profile. If the fallback scene uses media, browser sources, or clips, test it with the new codec too. Do not assume only the main camera matters.

• Baseline: H.264 profile to private destination, with fallback and return tested.
• HEVC test: same route, changed output codec, platform preview and archive checked.
• AV1 test: same route, changed output codec, encoder headroom and startup watched.
• HDR test: same route plus color verification on normal viewer devices.
• Rollback: producer can switch back to the known profile without touching source devices.

Best default for serious streamers

For most serious IRL and remote-production streamers, the best default is still conservative contribution into StreamableRun and platform-safe output from Cloud OBS. That might sound less exciting than a codec upgrade, but it is what keeps the show recoverable. The streamer can use Moblin, IRL Pro, a hardware encoder, Atomos gear, local OBS, or another source. StreamableRun can turn that into a controlled broadcast with scenes, fallback, destinations, and producer monitoring.

Enhanced RTMP belongs in the toolkit when the platform and show justify it. It should not become the shared output for a mixed-destination show until every destination, monitoring path, and fallback scene has passed. A mature workflow is not the one with the newest codec. It is the one the producer can operate under pressure.

• Default mixed-destination output: H.264, CBR, platform-safe resolution, tested keyframe interval.
• Advanced YouTube output: HEVC or AV1 only after private tests prove the path.
• HDR output: only when source, Cloud OBS, destination, and viewer path are confirmed.
• Field source: choose the reliable ingest first, then experiment at the output layer.
• Producer control: every experimental profile needs a rollback and a visible pass/fail note.

Other resources

Use these pages to verify current Enhanced RTMP behavior, OBS support, YouTube codec settings, platform constraints, and StreamableRun production features before changing a public output profile.