Yes. You send YouTube one live feed at a resolution, frame rate and bitrate chosen in your encoder; YouTube may transcode that feed into multiple playback formats for viewers. Those are two different stages, and you should not assume every stream will offer the same selectable resolutions.
For a prerecorded gaming rerun, the practical route is to play the video into an encoder and send it as a live broadcast. YouTube documents encoder-based gameplay and screen sharing, but not a special rerun mode. Treat this as an application of its documented live-streaming workflow, then check the actual player rather than promising viewers a particular quality menu.
Choose one incoming stream quality
The resolution setting in your encoder describes the picture you send to YouTube. It is not a switch that exposes a matching list of choices to each viewer. The incoming feed has one selected output size and frame rate, with a bitrate that determines how much video data the encoder sends. YouTube then handles its own processing for playback.
This distinction answers a common question: “Can I stream a prerecorded gaming video on YouTube Live at one resolution and let viewers choose another?” You can send one live feed, and YouTube says it automatically transcodes a live stream into many output formats. A viewer may be offered options suited to their device or connection, but the available choices are not something you set one by one in your encoder.
Do not advertise a fixed set such as 1080p, 720p and lower options as guaranteed for every broadcast. YouTube’s guidance describes multiple output formats without promising an identical ladder for every live stream. The actual options may vary, so inspect the player during your own broadcast if a particular quality choice matters.
For a rerun, the file itself is the source. Playing it through an encoder creates the live feed; it does not make every viewer receive the source file directly, nor does it guarantee that YouTube will present a source-resolution option. Keep the distinction clear when planning, testing and describing the channel.
YouTube’s live encoder settings guidance explains its recommended settings and says that live streams are transcoded into output formats for viewers. Its encoder overview describes encoder use for gameplay and screen sharing. These are useful references when you are deciding how to send a rerun, but neither establishes a guaranteed viewer-side list for every broadcast.
Set the rerun’s resolution, frame rate and bitrate
Start with the footage you actually have, then choose an encoder output that is practical for your upload connection and the machine doing the playback. The source resolution, desired output, frame rate and connection stability all matter. A bigger output setting is not automatically a better result when the source footage is smaller or when the connection cannot sustain the feed.
For example, if your gaming recording was made at a lower resolution, exporting or encoding it at a larger size does not add detail that was absent from the recording. It may increase the amount of work or data involved without improving what viewers can see. Treat this as ordinary video-production judgement, not a promise about how YouTube will process a particular file.
Bitrate is the amount of encoded video data sent over time. Raising it can preserve more visual detail in scenes with fast movement, but it also asks more of the upload connection. If the connection fluctuates, a setting that looks good in a short local test may be unreliable over a long broadcast. YouTube advises choosing a quality that remains reliable for your available internet connection.
For live encoder settings, YouTube recommends constant bitrate (CBR) and a two-second keyframe interval. Use those as starting points when configuring an encoder, and check the current YouTube guidance before a real broadcast in case its instructions have changed. The setting does not replace a connection test: a technically valid configuration can still fail if the upload path is unstable.
Frame rate should reflect the source and the motion you need to preserve. Gaming footage with rapid movement can make frame-rate choices more noticeable than a static scene, but sending a higher frame rate than the source contains does not restore missing frames. Keep the output consistent with the recording and encoder capability, then check for dropped frames or other health warnings during a private or otherwise low-stakes test.
A practical starting sequence is to note the file’s native resolution and frame rate, select an output the computer can encode consistently, and choose bitrate guidance from YouTube for that output. Then test under conditions similar to the eventual broadcast. If you are running a continuous playlist rather than one game recording, the workflow details in setting up a YouTube radio stream with a playlist are relevant to keeping the source sequence organised, though the quality decision remains a separate encoder choice.
Understand YouTube’s viewer-side transcoding
Transcoding means YouTube processes the live feed into playback formats that can be used across different devices and network conditions. You choose the incoming encoder output; YouTube’s processing determines what playback formats are actually available. This is why changing an encoder from one resolution to another does not amount to manually creating a complete viewer menu.
The practical benefit is that viewers do not all need to receive the same data rate or display size. A viewer watching on a phone over a limited connection may need a different playback format from someone watching on a larger screen with a strong connection. YouTube’s transcoding is intended to support those different circumstances, but it does not mean every viewer will see an identical set of choices or that every format will be available immediately.
There are limits to what the public guidance lets you conclude. It establishes that YouTube creates many output formats, not that a specific resolution will appear on every stream, at every point during a broadcast, or for every viewer. Avoid turning the general capability into a guarantee in a stream description, support message or production checklist.
The encoder and the playback menu are also different troubleshooting layers. If your encoder sends a soft or blocky source, YouTube cannot be relied on to recover detail that was not present in the feed. If the incoming signal is healthy but a viewer has limited bandwidth, that does not by itself mean the encoder should be changed. First identify whether the concern is source quality, the feed reaching YouTube, or the viewer’s current playback conditions.
For a non-technical channel operator, that separation keeps decisions manageable. Make the source and outgoing feed dependable first. Let YouTube handle its viewer-side formats, then confirm what the actual player offers. You are responsible for the quality of the feed you send, not for promising a specific menu that YouTube does not guarantee.
What viewers may see on different devices and networks
A viewer’s experience depends on more than the resolution selected in your encoder. Their device, screen, app or browser, connection and the formats currently available for that stream all affect playback. YouTube may make multiple formats available, but the viewer may also leave quality on automatic selection, where the player adjusts to conditions.
That means two people watching the same live rerun can report different picture quality without either report contradicting the settings you chose. One may be watching on a phone with a variable mobile connection; another may be on a television over a stable connection. Their player controls and available choices may differ. Ask what device and connection they are using before concluding that the outgoing encoder setting is wrong.
A larger source can provide more picture detail when the original recording contains it and the viewing conditions support it. It can also demand more from the encoder and connection. A smaller output may be a more dependable choice for an operator whose upload is limited or inconsistent. There is no universal best setting detached from the file, equipment and network.
If your channel primarily serves viewers on mobile connections, a stable feed is more useful than selecting a high output merely because it sounds better. If the recording has crisp text, menus or fast gameplay, check that these remain legible in the actual YouTube player. Viewers watching at a smaller display size may not need the same apparent detail as someone viewing on a large monitor, but you cannot control their device or connection from the encoder.
For a long-running channel, consider reliability alongside picture quality. Continuous playback places the computer, encoder and internet connection under sustained use. The advice in reducing CPU use for a 24/7 YouTube stream can help you think through the load of an always-on setup; it does not change YouTube’s transcoding or guarantee a viewer resolution option. A stable, correctly sized feed is a sensible target.
Build a repeatable test before going public
Use a test broadcast to check the full path, not only the encoder preview. Confirm that the file plays with sound, the encoder is sending the intended resolution and frame rate, and YouTube reports the incoming stream as healthy. YouTube recommends testing under conditions similar to the real broadcast and monitoring stream health indicators. A test made on a different connection or while the computer is idle may not reveal what happens overnight.
Once the stream is running, open the actual YouTube player on more than one device if you can. Look at the quality menu, but treat it as an observation of that broadcast, not a promise about future broadcasts. Check whether playback starts, whether the picture remains stable, and whether audio stays in sync. If a viewer reports that a choice is missing, compare their player and device with your own before changing output settings.
Change one setting at a time when troubleshooting. If you reduce bitrate, for example, keep the other variables steady and see whether the stream-health indicators improve. If you alter resolution and bitrate together, you may not know which change helped or whether a different connection condition was responsible. Keep a short record of the settings that were used and the result, especially before turning a test into a regular schedule.
Do not use the encoder preview as proof of what every viewer receives. The preview usually tells you about the outgoing picture before or during ingest; the viewer’s player reflects YouTube’s processing and their playback conditions. This distinction is especially useful when someone compares a local file that looks sharp with a stream that appears softer on a particular device.
If you want to understand a custom output configuration in more depth, see setting a custom resolution for YouTube Live in OBS. The settings article is a useful companion for the encoder side. It cannot guarantee which formats YouTube will expose to viewers, so always make the final check in the live player.
Plan for the recording as well as the live feed
A rerun channel has two useful outputs to think about: the live broadcast itself and any replay or local copy you want to retain. YouTube says replays appear as channel videos, and its archive guidance gives important caveats. In particular, streams shorter than 12 hours can be automatically archived, while streams exceeding 12 hours may not be captured at all. YouTube also states that 1440p and 2160p streams are automatically archived. Check the current YouTube archive and replay guidance before relying on a platform copy.
The archive rules are separate from the live viewer formats. A higher-resolution stream being automatically archived does not mean that every viewer is offered that resolution during the broadcast. Conversely, the fact that YouTube creates multiple live playback formats does not mean you have a complete replay saved locally. Treat these as different questions in your plan.
For a long-running gaming rerun, keep a local copy of the source and consider how you will preserve a recording if the stream is important to your channel. YouTube recommends maintaining a local backup. Confirm what appears in YouTube Studio after the broadcast rather than assuming a long stream will be retained in full. If your workflow is a folder of videos being played in sequence, streaming a folder of videos to YouTube Live continuously from Linux covers a related source-management problem; it does not replace checking the current archive rules.
A capture card is not needed merely because the file contains gameplay footage already available on your computer. It can be part of some console-to-computer production setups, where gameplay must first be brought into the computer, but it does not create YouTube’s playback variants. Keep equipment decisions tied to the source path you actually use.
If the only goal is to let viewers watch an existing gaming recording, an ordinary on-demand upload may be simpler than presenting it as a live rerun. A live encoder workflow makes sense when the ongoing live channel format matters. Consider that distinction before spending time tuning an always-on feed.
Keep the operating choice grounded in the bottleneck
When picture quality is disappointing, diagnose the point where it changes. Compare the original file, the encoder preview or output, YouTube’s stream-health view and the viewer’s player. If the file is already soft, adjust expectations or replace the source. If the outgoing feed is unstable, review encoder load, bitrate and upload reliability. If the feed is healthy but one viewer sees a different quality, check their playback conditions and available player choices.
This is also where a simple operating method can matter more than changing resolution repeatedly. If maintaining a computer and encoder through the night is the pain point, StreamNeo can take the uploaded video and run it as a YouTube live stream while your own computer is off, removing the need to keep that local playback setup running continuously. It does not change the fact that you choose one incoming feed quality or guarantee a particular viewer-side ladder.
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 viewers choose a resolution different from the one I send?
They may be offered playback formats produced by YouTube’s transcoding, which can differ from the single encoder output you send. YouTube does not guarantee the same quality menu for every broadcast, so check the actual player rather than promising a particular choice.
Will YouTube always show 1080p, 720p and lower options?
No fixed list should be assumed. YouTube says it creates many output formats, but its guidance does not promise an identical ladder for every stream or viewer. Look at the options available on your specific live player.
Does a gaming rerun use a special YouTube mode?
The official material covered here documents encoder streams, including gameplay and screen sharing, but not a special rerun mode. Treat prerecorded playback as an input to the ordinary live encoder workflow and test the broadcast you actually plan to run.
Should I send the highest resolution I can select?
Not automatically. Start with the source footage and choose an output that your encoder and upload connection can sustain reliably. A larger setting cannot add detail missing from a lower-resolution source, and it does not guarantee that viewers will see a matching playback option.