IRL Stream Day-of-Show Producer Packet

The short answer

A day-of-show producer packet is the one page that tells a remote producer how to run the IRL stream when things are moving fast. It should include source names, scene buttons, destination state, fallback rules, privacy rules, chat signals, streamer contact, and the first recovery steps for common failures.

StreamableRun makes the packet practical because Cloud Hosted OBS, mobile ingests, fallback scenes, multiple destinations, and producer controls live in one workflow. The packet does not have to explain a pile of unrelated tools. It tells the producer what to do inside the operating surface.

The packet should be short enough to use while live. If it takes ten minutes to read, it is documentation, not a show packet. The producer needs a fast map: what is connected, what should be public, what to cut to, who to tell, and when to stop trying to fix something in public.

Put the stream goal at the top

The first line should say what kind of show this is. Walking tour, sponsored event, travel day, fan meetup, sports sideline, marathon stream, mobile-to-desk hybrid, or remote guest stream. That one line changes the producer's judgment. A sponsored event needs cleaner brand safety. A travel day needs stronger privacy cuts. A marathon needs fatigue and battery checks.

Do not write marketing copy. Write the operating goal. Keep Twitch and Kick live during the route. Protect the destination output if the phone drops. Avoid showing exact hotel location. Keep guest audio clean. Preserve VOD for editors. That is useful.

StreamableRun is the best default for this because the producer can turn the goal into actions: choose scenes, switch fallback, monitor ingests, adjust destinations, and coordinate with moderators from the cloud workflow.

• Show type: what kind of IRL stream this is.
• Primary promise: what viewers should get even if the field source has trouble.
• Hard limits: locations, people, sponsors, or audio that must not go public.
• Success condition: what must still be true at the end of the stream.

List every source by real name

Source names matter during stress. Do not write phone, backup, OBS, and camera if nobody knows which is which. Write main iPhone Moblin, backup Android IRL Pro, fixed booth OBS, LiveU backpack, guest Discord capture, or local OBS desktop. Match the names to StreamableRun ingests and Cloud OBS sources.

Include the expected state for each source. Main phone should be live before intro. Backup phone should be ready but muted. Fixed booth camera should be on scene two. Guest source should stay hidden until producer confirms audio. That prevents accidental cuts.

If a source has special behavior, write it down. External mic only works after reconnect. Backup phone has lower bitrate. Guest source has two-second delay. LiveU audio is embedded. Local OBS source should never receive platform keys. These notes prevent dumb mistakes when the producer is tired.

• Main source name and app or device.
• Backup source name and when to use it.
• Fixed source name and safe scene.
• Guest or collab sources and delay notes.
• Audio source notes.
• Sources that should never go public.

Map scenes to actions

The packet should not only list scene names. It should say when to use them. Main live for normal camera. BRB for short field pauses. Clips fallback for signal loss. Privacy for IDs, addresses, staff, or unsafe moments. Holding for pre-show and travel gaps. Audio check for return from reconnect. Sponsor-safe for brand segments.

OBS remote control exists for a reason: scenes and sources can be controlled through WebSocket in modern OBS, and OBS recommends protecting WebSocket with authentication. In StreamableRun, remote production should be even more intentional. The producer should know exactly which controls are theirs and which changes require a streamer or owner decision.

Make the scene action names visible in the packet. During a drop, the producer should think cut to clips fallback, not wonder whether Scene 7 or Scene 9 is the right one.

• Main live: normal camera and program audio.
• Holding: pre-show, travel delay, or setup time.
• Privacy: instant cut for sensitive info or safety.
• Clips fallback: signal loss or streamer unavailable.
• Audio check: source returned, but mic needs confirmation.
• Sponsor-safe: reduced chat and approved overlays only.

Write destination checks in platform language

Destination notes should be specific. Twitch main channel, Kick main channel, YouTube scheduled live, custom RTMP partner feed. Include title, category, latency mode, expected output resolution, and whether the destination should start at pre-show or at the main segment.

Use current platform constraints. YouTube's live encoder guidance lists RTMP/RTMPS, H.264, H.265, AV1, bitrate ranges, and testing with audio and movement. Kick's May 2026 help guide lists OBS setup, stream URL and key, CBR settings, title/category, and current maximums such as 1080p, 60 fps, and 8,000 kbps. Twitch broadcast and health guidance still matters for bitrate stability and viewer buffering. The producer packet should not invent settings from memory.

Put the check order in the packet: Cloud OBS output healthy, destination connected, public page visible, audio heard, title/category correct, chat visible, fallback tested. That order catches most day-of-show mistakes.

Add the failure ladder

A producer packet needs a failure ladder because live problems are emotional. If the main source drops, the producer should not debate the perfect fix. They should cut to fallback, check source state, message the streamer, wait for stable return, then cut back. If audio disappears, check meters and public playback before blaming the platform. If one destination fails, keep the others alive while fixing the broken one.

Write the first action for each failure. First action beats long explanation. Source drop: cut to fallback. Private info: cut to privacy. No audio: switch to audio check or hold. Wrong destination metadata: keep scene stable and fix destination. Chat harassment: hide public chat overlay and alert mods.

StreamableRun is strongest when the producer uses it as an operating layer. The failure ladder turns the cloud controls into muscle memory.

• Source drop: fallback first, source debug second.
• Private info: privacy first, explanation second.
• No audio: check meters, source, scene, then public playback.
• One destination down: keep other destinations live and fix only the failed output.
• Browser source frozen: hide or refresh after cutting to a safe scene.
• Streamer unreachable: hold or fallback until contact returns.

Include chat signal rules

Chat can help production, but only if the producer knows which messages matter. Put a short signal ladder in the packet. Safety and privacy reports matter first. Then audio/video issues. Then destination issues. Then paid moments. Then normal feedback.

Twitch developer docs describe chatbots, EventSub, moderation actions, and rate limits. Kick's chat API docs cover sending and deleting messages with scoped permissions. YouTube live chat tools and moderation docs give creators ways to handle live chat. Those tools are useful, but the packet should translate them into human workflow.

Moderators should know how to reach the producer privately. The streamer should not be the router for every chat report. If chat spots a real problem, the production mod sends one clean signal to the producer, not ten public messages to the streamer.

• Safety or privacy report: producer acts immediately.
• Audio or video report: producer verifies with meters and public playback.
• Destination report: producer checks platform-specific output.
• Paid moment issue: mod queue owner checks fulfillment.
• Normal spam: chat moderators handle it without producer involvement.

Make streamer contact boring

The packet should say exactly how to reach the streamer. Voice channel, phone call, Discord, text, or mod relay. It should also say what messages are allowed while the streamer is live. Audio gone. Cut to privacy. Hold position. Camera too low. Backup active. These are production signals, not essays.

If the streamer is walking, driving, performing, talking to guests, or handling venue staff, they cannot read long instructions. The producer should send short commands and then act in Cloud OBS where possible.

Also include a no-contact rule. If the streamer is unreachable and the source is broken, stay on fallback or holding. Do not keep the broken camera public because the producer is waiting for permission that may not arrive.

• Primary contact path.
• Backup contact path.
• Short production phrases.
• Who can interrupt the streamer.
• What to do if the streamer does not answer.
• When to stop trying and hold the show.

Keep the packet to one page

The producer packet is not the whole knowledge base. Link the full runbooks elsewhere. The day-of-show version should fit on one page or one pinned note. If the producer has to search, the packet failed.

Use headings, not paragraphs. Put source names, scene actions, destination checks, failure ladder, chat signals, and contacts in the same order every time. Repetition helps when the producer handles multiple shows.

After the stream, update the packet from what actually happened. Remove stale sources. Rename confusing scenes. Add the failure you did not expect. The goal is not perfect documentation. It is a better next stream.

• One goal line.
• One source table.
• One scene action table.
• One destination checklist.
• One failure ladder.
• One chat signal ladder.
• One contact section.

Other resources

These StreamableRun guides cover the deeper runbooks that can sit behind the one-page producer packet.