“Rerun” can mean replaying a recording of Tabletop Simulator as a YouTube Live event, or capturing a game session as it happens. Both workflows send an encoder feed to YouTube, but only the second requires the game to be running during the broadcast.
For a recording replay, prepare the file and check that your installed encoder can repeat it as intended before relying on an unattended stream. For live play, capture the game and any commentary you want viewers to hear. In either case, YouTube’s encoder workflow uses a stream URL and a private stream key.
What “rerun” means for Tabletop Simulator
Tabletop Simulator gameplay can be broadcast from an active session or replayed from an existing recording. Those are different production jobs, even if viewers ultimately see similar footage. Decide which one you mean before opening OBS: it affects the source you configure, whether the game must remain open, and what you need to test.
A live capture shows the session as it unfolds. You can speak over it, respond to chat, or make decisions at the table while viewers watch. It also means the computer has to run Tabletop Simulator and encode the stream at the same time. A prerecorded rerun sends a prepared video file instead; the original game session is not needed while the video plays, but you must verify how your encoder handles repeating the file if the stream needs to continue after it ends.
A rerun is not automatically a recording of an event that YouTube has already hosted. Here, it means making gameplay footage appear in a new live broadcast. That distinction matters if you are planning a scheduled event, explaining to viewers what they will see, or deciding whether to join the stream and talk to them.
Choose a recording replay or live gameplay capture
Use a recording replay when you have suitable footage and want the broadcast to run without an active game session. It can suit a showcase, a rules walkthrough, or a quiet channel where the video itself is the programme. It does not provide live reactions to new moves in the original session, so label and describe the event honestly rather than presenting old footage as a new match.
Choose live capture when the point is current play or interaction. Viewers can follow decisions as they happen, and you can add commentary or acknowledge chat. The trade-off is a more demanding test: if the game, encoder, audio devices and network all share one computer, they can compete for resources or behave differently under load than they do separately.
| Question | Recording replay | Live gameplay capture |
|---|---|---|
| Must a game session run during broadcast? | No, once the file is prepared | Yes |
| Can you react to current play? | Not to the recorded session | Yes, if you choose to interact |
| What is the main source to test? | Video playback and repeat behaviour | Game capture and game performance |
| What matters for unattended playback? | Whether the encoder repeats the file as required | Whether the game and broadcast remain running |
| What should the viewer be told? | That the footage is a replay, where relevant | Whether the session is live and interactive |
If you are replaying one file or rotating several, use an approach that matches the encoder you have actually tested. A guide to using a playlist file for prerecorded streams in OBS may help if your plan involves multiple clips, but it does not remove the need to confirm current controls and transitions on your own installation.
Prepare the video or capture source
For a replay, choose the final video file before creating the event. Watch enough of it to check that it has the intended opening and ending, picture orientation, and audio. If the video is shorter than the time you want to broadcast, decide what should happen when it reaches the end: stop the event, repeat the same file, or move to another prepared item. Do not assume the repeat behaviour from an old tutorial; OBS controls can change, and the research available for this guide does not establish the exact current loop control for every version.
Test repeat behaviour locally in the OBS version you will use. Confirm whether playback restarts, whether audio also restarts cleanly, and whether there is a pause or blank frame between passes. If the control is unclear, consult the current OBS documentation or test the installed version before scheduling an unattended broadcast. Valve’s Steamworks livestreaming documentation discusses streaming existing video files, but it is not a guarantee of a particular current OBS interface or loop setting.
For live capture, launch Tabletop Simulator and open the table or session you intend to show. Arrange windows and overlays before going live, and check that the game is visible in the capture source. You do not need to assume that a separate capture card is required for a same-computer game capture; choose capture hardware only if your production setup calls for it.
Check the game requirements against your computer, but treat them as requirements for running the game, not proof that the machine can also encode a stream smoothly. Steam’s Tabletop Simulator listing specifies minimum platform requirements. OBS also cautions that meeting its system requirements does not by itself guarantee good streaming performance. The practical check is to run both applications together and observe the result.
Set up OBS for the chosen source
Create a scene for the broadcast and add the source that matches your choice: a video file for a replay, or the game display for live capture. Keep the scene understandable. A title card, webcam or extra graphics can be useful, but each additional element creates another thing to inspect before the event. Make sure the important part of the table is not hidden by overlays or cropped from the frame.
For a replay, check the file’s playback and repeat settings in your installed version of OBS. This guide does not prescribe a menu path because the available sources do not establish the exact current controls across versions. Start playback, let it reach its end, and observe what happens before you depend on the setting for a long event. If you use a playlist, test the transition between clips as well as the end of the final item.
For live gameplay, select a capture method that shows the game in your actual layout. Look at the preview while moving or changing the view in Tabletop Simulator. Check for a frozen image, black frame, wrong window, or cursor covering a piece viewers need to see. If you also use a camera, keep it secondary unless it is part of the intended programme.
Set output choices to what your encoder, connection and viewing purpose can support. YouTube’s encoder settings guidance recommends RTMPS, constant bitrate (CBR), and a two-second keyframe interval; it says the keyframe interval should not exceed four seconds. These are platform recommendations, not a reason to choose a resolution or bitrate beyond what your upload can sustain. H.264 is among the supported video codecs in the guidance.
Choose a resolution and bitrate, then check the total stream bitrate against measured upload capacity. YouTube recommends upload bandwidth with 20% capacity beyond the total stream bitrate. That margin matters because a connection that barely matches the encoder setting may leave no room for variation. If the connection is shared or variable, choose a more conservative output and test at the time and place you will broadcast.
Connect OBS to a YouTube Live event
Before planning a first broadcast, check the channel’s current live-streaming eligibility and enable the feature in advance. YouTube says a channel must be verified and have no live-streaming restrictions within the previous 90 days, and streamers must be at least 16. First-time activation may take up to 24 hours, so do not leave enabling the feature until the scheduled start.
In YouTube Studio, create or schedule a live event and choose the encoder workflow. YouTube’s encoder setup instructions explain how to obtain the stream URL and key for the event. Enter those details in OBS’s streaming configuration, following the current interfaces in both products, then keep the event’s Live Control Room open so you can see whether YouTube receives the feed.
Treat the stream key as a credential, not as a public link. YouTube describes it as what lets your encoder send a feed to the channel. Do not put it in a public screenshot, description or chat message. If you believe it has been exposed, use YouTube Studio’s current controls to replace or reset it before the next broadcast.
A scheduled event and an encoder feed are separate parts of the workflow: creating the event does not itself send video, and configuring OBS does not mean the event is already visible to viewers. Follow the prompts shown in Live Control Room to start the event when the preview and checks are ready. If you are comparing a one-off rerun with a channel that rotates files continuously, the workflow and supervision needs may differ; a playlist rotation guide for YouTube Live can offer a related planning reference, though its subject is different.
Preview and check audio
Send a test feed before announcing the stream widely. Check the YouTube preview as well as the OBS preview: one confirms the scene you built, while the other confirms what has reached the event. Look for a stable picture, the right scene, and sensible framing. A local preview alone cannot tell you whether the encoder is connected to the intended event.
Listen to the audio on a separate device if possible. For a replay, confirm that the video’s sound is audible and not unexpectedly duplicated by desktop audio. For live gameplay, decide whether viewers should hear game sounds, your microphone, or both. Speak at the level you expect during the broadcast and listen for clipping, excessive background noise, or a microphone that is missing from the mix.
YouTube’s streaming tips advise setting up the encoder ahead of time, checking the preview, and monitoring audio and video quality. Keep the test long enough to expose an obvious issue, but do not treat one successful preview as proof that a long unattended stream will never fail. If the picture breaks up or audio drops, lower the output demand, inspect the source and connection, then test again.
Test the rerun before sharing it
Run the whole chain in the order you intend to use it: start the source, connect OBS, confirm the Live Control Room preview, and start the event using the interface prompts. For a recording, test through the point where it ends and begins again if repeating is part of the plan. For gameplay capture, play for long enough to see whether the computer stays responsive and whether the capture remains correct while the table changes.
Keep notes on what worked: the scene, output settings, source selection and audio devices. This is more useful than relying on memory when you return to the setup days later. If you change the video file, game window, microphone, network or encoder settings, check the affected parts again rather than assuming the earlier test still applies.
Decide what you will do if the feed stops. Keep the event and stream key details accessible privately, know how to reconnect OBS, and avoid promising viewers that the broadcast will be continuous if you cannot monitor it. A prerecorded file can remove the need to keep a game session active, but it does not by itself settle how the encoder repeats content or recovers from a dropped connection. For a long-running channel, compare the operating and supervision trade-offs with a 24/7 stream cost breakdown; the useful choice depends on who will monitor the broadcast and what failure recovery you need.
When the event ends, stop the broadcast in the relevant interfaces and check the channel’s archive. YouTube says streams under 12 hours are automatically archived; do not assume a longer event will produce a complete archive. If you want the replay available after the live event, check the result rather than relying on the expectation that every duration archives in full.
If you want the broadcast to continue while your own computer is switched off, the practical problem becomes keeping the prepared file and channel running without leaving your desktop in charge. StreamNeo removes that specific need to keep your computer on: you upload a video, provide your YouTube stream key, and it runs the YouTube broadcast with monitoring and automatic restarts. It is YouTube-only, so it is relevant to a file-based rerun rather than a live Tabletop Simulator session that needs your active gameplay.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I replay a Tabletop Simulator recording as a YouTube Live stream?
Yes. Send the recording through an encoder such as OBS to a YouTube Live event, and test the file playback and any repeat behaviour in your installed encoder version. The original game does not need to be running during playback.
Do I need to keep Tabletop Simulator open?
Only if you are capturing live gameplay from the game. A prerecorded replay uses a video file as its source, though the encoder and the process that sends the feed still need to run unless you use a different operating arrangement.
Does the recording automatically loop in OBS?
Do not assume that it does. Verify the repeat control in the OBS version you have installed and test playback through the end of the file before relying on a continuous rerun.
Will YouTube archive the live rerun?
YouTube says streams under 12 hours are automatically archived. For a longer broadcast, do not promise that the full stream will be available as an archive; check YouTube’s current guidance and confirm the result in your channel.