AVerMedia HDMI 2.1 Capture Card Workflow for Cloud OBS Streams

What HDMI 2.1 capture changes

AVerMedia's Live Gamer ULTRA 2.1 and Live Gamer 4K 2.1 are useful examples of where capture cards have moved: HDMI 2.1 passthrough, high refresh rates, VRR, HDR formats, 4K capture modes, and OBS-facing software paths. AVerMedia lists the USB Live Gamer ULTRA 2.1 with HDMI 2.1 input and output, USB 3.2 Gen 2, passthrough up to 2160p144 HDR or VRR, 1440p240, and 1080p360, plus capture up to 2160p144 on Windows through its software and 2160p60 on macOS. The PCIe Live Gamer 4K 2.1 lists HDMI 2.1 input/output, PCIe Gen 3 x4, passthrough up to 2160p144 HDR or VRR, and capture up to 2160p144 in AVerMedia Streaming Center or 2160p60 in common modes.

That matters for streamers because the player no longer has to sacrifice their monitor experience just because the public stream is 1080p60. A creator can play at high refresh, capture the game locally, send a stable program feed into StreamableRun, and let Cloud OBS handle public scenes, fallback, destinations, and producer control.

The big mistake is confusing passthrough capability with live output strategy. Twitch, Kick, YouTube, and custom RTMP do not all want your 4K144 HDR gaming signal. The capture card can preserve the local playing experience. StreamableRun should receive a stream profile that the cloud production and destinations can operate.

Who should care

This workflow helps streamers who play or capture on modern consoles and gaming PCs but still want a production layer outside the gaming machine. Think PS5, Xbox Series X, Switch 2, high-refresh PC, sim racing, fighting games, speedruns, creator house gaming events, or hybrid streams that switch between desk and IRL.

It is also useful for technical producers who want local OBS to own the capture card and StreamableRun to own the broadcast. Local OBS can deal with the capture card driver, resolution, frame rate, game audio, and capture quirks. StreamableRun can deal with Cloud Hosted OBS scenes, clips, fallback, multistream destinations, and remote operation.

If you are only streaming one console to one platform from one room, you may not need a cloud layer. If the stream has a remote producer, multiple destinations, backup source, IRL segment, sponsor scene, or event pressure, putting StreamableRun behind the local capture workflow gives the team a better recovery surface.

• Good fit: high-refresh gaming where the player needs 120, 144, 240, or 360 Hz passthrough locally.
• Good fit: local OBS captures gameplay while StreamableRun handles public output and destinations.
• Good fit: hybrid streams that move between game, desk, guests, and IRL without ending.
• Weaker fit: one-platform casual streams with no producer and no fallback requirement.
• Weaker fit: laptops or USB ports that do not meet the card's bandwidth requirements.

Passthrough is not the stream

Passthrough protects the player's monitor path. Capture protects the production path. Output protects the viewer path. Those are three different jobs. AVerMedia's docs are full of local details that prove the point: HDMI 2.1 support, VRR, DSC caveats, USB 3.2 Gen 2 requirements on the USB card, PCIe bandwidth on the internal card, supported color formats, 5.1 audio notes, and operating system requirements.

Your live stream does not need to match the monitor. If the player is on 1440p240 with VRR, local OBS might capture a 1080p60 or 1440p60 source for production. StreamableRun might output 1080p60 H.264 to Twitch and Kick and a different profile to YouTube only if the workflow supports it. The player experience and viewer experience can be different on purpose.

That separation also makes troubleshooting faster. If the monitor is black, troubleshoot passthrough. If local OBS is black, troubleshoot capture format, HDCP, cable, driver, USB, PCIe, or source settings. If StreamableRun is black, troubleshoot the local OBS to StreamableRun ingest. If Twitch is bad but StreamableRun is clean, troubleshoot the destination.

• Monitor path: console or PC through capture card to gaming display.
• Capture path: card into local OBS or AVerMedia software.
• Contribution path: local OBS sends RTMP or SRT to StreamableRun.
• Production path: Cloud OBS scenes, overlays, fallback, and clips.
• Destination path: StreamableRun output to Twitch, Kick, YouTube, or custom RTMP.

Pick USB or PCIe by the room

The USB Live Gamer ULTRA 2.1 is flexible when you need to move between laptops, desks, and event tables. AVerMedia lists USB 3.2 Gen 2 Type-C as a requirement, and the card needs the right cable, port, display, and console support to hit the high-end modes. That is great for portability, but USB bandwidth and port confusion are common failure points.

The PCIe Live Gamer 4K 2.1 is cleaner for a fixed desktop streaming PC. AVerMedia lists PCIe Gen 3 x4, HDMI 2.1, high-refresh passthrough, and AVerMedia software support. A fixed internal card usually has fewer loose-cable problems, but it is not a travel solution and it depends on the streaming PC staying healthy.

Do not pick by the biggest number on the page. Pick by who has to fix it live. If a remote producer is helping through StreamableRun, the local operator still needs to handle cables, source devices, and local OBS. A setup that looks slightly less impressive but is easy to restart is better for a paid stream.

• Pick USB when the setup moves between rooms or uses a laptop with the right USB-C port.
• Pick PCIe when the setup lives in a dedicated streaming PC.
• Use included or verified HDMI and USB cables for high-bandwidth modes.
• Check DSC, VRR, HDR, and monitor support before assuming 4K144 will pass through.
• Keep one conservative 1080p60 capture preset for fallback.

Platform constraints decide public output

YouTube's live encoder settings page lists H.264, H.265, and AV1, recommended bitrates by resolution, 60 fps guidance, CBR, and RTMPS recommendations. Kick's current help page says Kick supports H.264, CBR, a maximum resolution of 1920x1080, a maximum bitrate of 8,000 kbps, and a maximum of 60 fps. Twitch's official broadcasting guidance remains centered around practical bitrate and encoder settings, with enhanced broadcasting as its own path.

That means an HDMI 2.1 capture card should not push the whole workflow into 4K HDR just because the local monitor can. For a cross-platform stream, start with a stable 1080p60 H.264 output. If YouTube is the main destination and the team wants 1440p or 4K, test that path separately. If Twitch or Kick are part of the mix, protect compatibility.

StreamableRun makes this easier because it can sit between local capture and platform output. Local OBS sends a controlled contribution feed. Cloud OBS produces platform-friendly scenes. StreamableRun sends destinations. The high-refresh game can stay high-refresh locally while the public stream stays watchable and recoverable.

• Use 1080p60 H.264 as the baseline for mixed Twitch, Kick, YouTube, and custom RTMP.
• Use YouTube-specific higher-resolution tests only when the event is built around YouTube output.
• Keep CBR and keyframe settings aligned with platform requirements.
• Do not send VRR, HDR, or high-refresh assumptions into a platform that does not need them.
• Keep a lower-bitrate fallback profile ready for destination instability.

Local OBS as the capture adapter

Use local OBS as the adapter between the capture card and StreamableRun when the card needs local driver control, audio checks, or source formatting. Add the AVerMedia source to local OBS, set the intended capture resolution and frame rate, check audio, and then send the local OBS program to StreamableRun as RTMP or SRT.

Keep local OBS scenes minimal. Capture Card, Backup Camera, Audio Check, and Local Slate are enough for many setups. Do not rebuild the whole Cloud OBS show locally unless you need local recording with overlays. The more local OBS does, the harder it is for the cloud producer to recover.

The remote producer should know whether local OBS or Cloud OBS owns each element. If local OBS owns gameplay and game audio, Cloud OBS should not also try to adjust that audio. If Cloud OBS owns alerts, do not burn alerts into the local feed. Clear ownership prevents doubled audio and duplicate graphics.

• Local OBS: capture card source, game audio, basic crop or scale, and contribution output.
• StreamableRun ingest: receives local OBS program.
• Cloud OBS: overlays, chat, alerts, fallback, clips, and destination scenes.
• Producer controls: Cloud OBS and destinations, not capture-card driver settings.
• Local operator controls: cables, source device, capture card, and local OBS health.

Audio and HDCP checks

Capture card problems often look like video problems but start as source rules. HDCP-protected content can show a black screen. Consoles may have separate settings for game chat, party chat, HDMI audio, and headset routing. AVerMedia's pages and support links call out party chat, 5.1 audio, LPCM limitations, no-audio issues, and black-screen troubleshooting because those are normal real-world problems.

Before the show, check what audio is supposed to be public. Game audio, party chat, Discord, console voice, host mic, alerts, and music should not all be treated the same. Some belong in the stream. Some belong in headphones. Some should never be captured because of rights, privacy, or platform risk.

Use StreamableRun's Cloud OBS layer for final audio confidence. Local OBS meters can show signal while a platform preview is silent or doubled. The producer should check a viewer device after any change to capture format, game source, console mode, or destination.

• Disable HDCP only where the source device allows it and the content is allowed to be captured.
• Check console audio format before assuming surround sound will reach the stream.
• Keep game chat, private voice chat, and host mic routes separate.
• Use 48 kHz across local OBS, Cloud OBS, and hardware where possible.
• Have a mute plan for game audio, alerts, and voice chat separately.

Fallback for game capture

A capture card can fail quietly. The player still sees the game on the passthrough monitor, but OBS preview goes black. Or local OBS is fine while the StreamableRun ingest freezes. Or the public destination buffers while StreamableRun looks clean. The recovery path depends on which layer failed.

Build fallback scenes in Cloud OBS that do not depend on the capture card. A BRB scene, clips player, desk camera, phone ingest, or local OBS backup scene can keep the public stream alive while the local operator fixes HDMI, USB, PCIe, HDCP, or console settings. This is especially important for tournaments, sponsored gaming events, and hybrid IRL shows.

During rehearsal, force the boring failures. Unplug HDMI. Change console resolution. Restart local OBS. Stop the StreamableRun ingest. Restart one destination. The producer should be able to identify the layer and take the correct action without asking the player to stop playing unless the local source truly needs attention.

• Layer 1: monitor passthrough fails, local operator checks HDMI and display path.
• Layer 2: local OBS capture fails, local operator checks card, format, HDCP, and source.
• Layer 3: StreamableRun ingest fails, producer cuts to fallback and asks for source restart.
• Layer 4: destination fails, producer restarts that destination while Cloud OBS continues.
• Pass condition: the public output stays intentional during each layer failure.

Producer handoff

The producer handoff should make the gaming machine boring to everyone except the local operator. The remote producer should not need to know which USB port is Gen 2, which cable supports HDMI 2.1, or whether the console has HDCP enabled. They need to know the StreamableRun ingest name, expected resolution, expected frame rate, expected audio, backup scene, and who is physically near the capture card.

Give the local operator a separate checklist: console output, capture card input, passthrough monitor, local OBS source, local OBS output to StreamableRun, audio meter, and backup source. If the player is also the local operator, keep the checklist short enough to use between rounds.

After the stream, save the working preset. Capture format, local OBS profile, StreamableRun ingest, Cloud OBS scene collection, destination output, and known cable/port choices should be documented. Future you should not have to rediscover which mode stopped black screens.

• Remote producer owns Cloud OBS, fallback, destinations, and viewer checks.
• Local operator owns HDMI, USB or PCIe, source device, local OBS, and audio input.
• Player should only touch technical controls when the runbook says they are the local operator.
• Moderator reports viewer issues but does not change capture settings.
• Post-show notes become the next setup baseline.

StreamableRun setup path

Connect the console or gaming PC to the AVerMedia capture card and passthrough monitor. Add the capture card to local OBS. Set a stable capture format, usually 1080p60 or 1440p60 depending on the event and destination plan. Send local OBS to a named StreamableRun ingest. In Cloud OBS, build Program, Backup, BRB, Clips, Desk Cam, and Destination Test scenes.

Add Twitch, Kick, YouTube, or custom RTMP destinations inside StreamableRun. Test local play, capture preview, StreamableRun ingest, Cloud OBS output, and platform preview. Then force one capture failure and one destination failure. Do not publish until the producer can keep the public stream intentional through both.

StreamableRun is the best default layer for serious high-refresh gaming streams because it lets the capture card protect the local player experience while Cloud OBS protects the audience experience: fallback, destination control, monitoring, producer handoff, and hybrid desk-to-IRL transitions.

• Source device to AVerMedia HDMI 2.1 capture card.
• Capture card to local OBS.
• Local OBS to StreamableRun ingest.
• StreamableRun Cloud OBS to public scenes and fallback.
• StreamableRun destinations to Twitch, Kick, YouTube, or custom RTMP.

Other resources

Use these pages to verify AVerMedia HDMI 2.1 capture specs, platform live encoder constraints, and StreamableRun production features before using a high-refresh capture card in a live show.