To change the resolution or bitrate sent from SRS to YouTube, first confirm that SRS is actively transcoding the video. In a pass-through setup, SRS forwards the encoded video unchanged, so its transcoding output settings cannot alter that video.
When transcoding is active, SRS settings such as vwidth, vheight, vfps and vbitrate describe the output that FFmpeg encodes. Set those values for the stream you intend to send, check their units and then verify the actual output and YouTube stream health. The exact syntax depends on your SRS release, so use its matching documentation rather than pasting an old example into a different version.
Check whether SRS transcodes or passes through
A setting only changes a property if a component in the signal path actually performs that change. SRS can receive an encoded stream and forward it, or use FFmpeg to decode and encode an output stream. Those paths have different consequences: forwarding preserves the input video’s encoded properties, while transcoding creates a new encoded output whose dimensions, frame rate and bitrate can be selected.
Trace the path from source to YouTube before editing a config. Identify the encoder that creates the source stream, the SRS application or stream configuration that receives it, and whether a transcode job launches FFmpeg. A running SRS process alone does not mean that the video is being transcoded. Look for the relevant transcode configuration and evidence that its FFmpeg process is active; confirm against documentation for the release you have deployed.
In a copy or pass-through path, changing vwidth, vheight, vfps or vbitrate does not re-encode the copied stream. Those parameters are output controls for a transcoding workflow, not magic filters applied to every stream that SRS relays. If you need a different encoded size or rate, either change the upstream encoder or configure and operate a real transcoding step.
Pass-through is useful when the source already has the format you want: it avoids an additional video encoding step and the associated processing and quality trade-offs. Transcoding is useful when the source needs a different output, but it requires a working FFmpeg path and enough capacity to encode continuously. SRS documents live transcoding to another RTMP server in its Transcode Deploy documentation; treat it as an explanation of that workflow, not a complete, current YouTube deployment recipe.
This distinction matters for an always-on channel. If you send a 720p source through unchanged, a YouTube setting or SRS output field will not turn that encoded video into a 1080p stream. If you transcode, the new output can have different dimensions and bitrate, but you must confirm it is the output actually forwarded to YouTube. For general connection symptoms, the guide to YouTube Live poor connection despite stable upload speed covers another part of the chain: transport health is related to, but not the same thing as, encoder output settings.
Choose output resolution and frame rate
For an active SRS/FFmpeg transcode, vwidth and vheight specify the output dimensions in the documented SRS parameter mapping, while vfps specifies output frame rate. These settings concern what the transcoder encodes. They do not alter a copied video, and they do not determine every playback format YouTube makes available to viewers.
Start from the material and use case. A devotional still-image loop, a lofi animation, a study timer and a local news programme do not necessarily need the same motion detail or frame rate. If the source is already composed at a particular size and frame rate, keeping those characteristics may be simpler than adding a transcode. If the source is larger than your intended output, a transcode can resize it; if it is smaller, setting larger output dimensions does not restore detail that was never present.
Frame rate affects how much motion information the encoder handles, and resolution affects the number of picture samples in each frame. Raising either can increase encoding and bandwidth demands, though the outcome depends on codec and content. A static artwork loop may be visually acceptable at a lower setting than a rapidly moving news clip. Choose a target that suits the source and the upload connection rather than selecting the largest available numbers by habit.
YouTube says it detects resolution and frame rate by default. Manual resolution selection is available through a custom stream key and manual settings in Live Control Room. Its encoder settings guidance also distinguishes the stream you send from the formats YouTube transcodes for viewers. Sending a given ingest resolution does not mean every viewer receives that exact resolution: playback depends on YouTube’s processing and the viewer’s circumstances.
Keep the output consistent with the incoming material and the YouTube ingest configuration. For example, if your source is a 30 fps recording and your transcode is configured for a 30 fps output, confirm the resulting stream reports that rate; do not assume a control panel’s intended value proves what is going out. If you are using manual resolution settings in Live Control Room, align them with the actual encoded output and check YouTube’s current instructions.
Set SRS video bitrate in the correct units
SRS’s documented vbitrate value is expressed in kilobits per second (kbps). The corresponding FFmpeg bitrate value is expressed in bits per second (bps). The parameter mapping is described in the SRS FFmpeg documentation. Do not copy a number from one field or example into the other without converting units.
The arithmetic is straightforward: one kilobit per second is one thousand bits per second. Thus a target of 10,000 kbps corresponds to 10,000,000 bps. The same rate might appear as 10000 in an SRS field documented in kbps and as 10000000 in an FFmpeg field documented in bps. The actual config syntax and which field to use are release-specific; check the parameter documentation for your installed version before making the change.
This unit distinction is easy to miss because both values represent a rate. A number entered at the wrong scale may yield an output far from what you intended, or a configuration that does not behave as expected. Check both the name of the setting and its unit in the exact context where it appears. Do not infer a unit from a field name alone.
Use YouTube’s recommendations as a reference for the codec and frame rate you are actually sending, not as a universal preset. YouTube lists these H.264 recommendations: 10 Mbps for 1080p at 30 fps, 12 Mbps for 1080p at 60 fps, 6 Mbps for 720p at 60 fps, and 4 Mbps for 240p–720p at 30 fps. Those figures are recommendations on YouTube Help, accessed in October 2026; they are not independent measurements and should not be applied indiscriminately to other codecs or frame rates.
The same page presents AV1/H.265 guidance as a minimum–maximum range rather than the H.264 recommended column. For example, its ranges for 1080p are 3–8 Mbps at 30 fps and 4–10 Mbps at 60 fps. Do not treat those codec-specific ranges as interchangeable with the H.264 recommendations. Check YouTube’s current table for your codec and output format before deciding on a target.
| Output example | YouTube guidance by codec | What to check |
|---|---|---|
| H.264, 1080p at 30 fps | 10 Mbps recommended | Convert to the units expected by the SRS or FFmpeg field in use. |
| H.264, 1080p at 60 fps | 12 Mbps recommended | Confirm the output is actually 60 fps before using this row. |
| H.264, 720p at 60 fps | 6 Mbps recommended | Make sure the upload connection can sustain the stream. |
| H.264, 240p–720p at 30 fps | 4 Mbps recommended | Match the selected resolution and frame rate to the source. |
| AV1/H.265, 1080p at 30 fps | 3–8 Mbps minimum–maximum guidance | This is a range, not the H.264 recommended value. |
| AV1/H.265, 1080p at 60 fps | 4–10 Mbps minimum–maximum guidance | Check YouTube Help for current codec-specific guidance. |
The table is not a promise that a particular bitrate will produce a particular quality or a reliable broadcast. Available upload capacity, competing traffic, content motion, codec and encoding behaviour all matter. Leave room for connection variation rather than setting the stream at the full nominal upload rate. The guide on upload speed for a YouTube podcast live stream can help you think about the connection side separately from the configured encoder rate.
Configure the YouTube ingest stream
Treat configuration as two linked tasks: set the SRS/FFmpeg output when transcoding is active, then tell YouTube how to receive that output. Use the resolution, frame rate, codec and bitrate that the transcoder will produce, not merely the source file’s properties or the values you intended to enter. If you are passing through, use the source encoder’s actual output as the basis instead.
YouTube receives an ingest stream from your encoder and processes it for playback. YouTube’s automatic resolution and frame-rate detection is the default; manual resolution selection uses a custom stream key and the manual settings in Live Control Room, according to its live encoder settings page. Follow the current instructions in your channel’s Live Control Room, since the page and available controls are the authoritative place to check the ingest setup.
The stream key is a credential, not a setting to publish in a tutorial, shell history or shared screenshot. Keep it out of public logs and command history, and use a private configuration method appropriate to your deployment. If you need to review that specific risk, see how to keep the YouTube stream key out of FFmpeg command history. Do not expose a key just to make troubleshooting easier.
YouTube’s recommended bitrate is not the only criterion for a sound ingest. The connection from the encoder to YouTube must carry the chosen output reliably for as long as the channel is live. If upload capacity is marginal, reducing resolution, frame rate or bitrate may be more useful than choosing the largest output and hoping the connection holds. Test using the same network path and equipment that will be used for the live channel.
Apply settings and verify the output
Before changing a running channel, record the existing configuration and identify which process will need a restart or reload. Make one deliberate change at a time, then check logs and process status for errors. SRS configuration syntax can differ across releases, and a parameter mapping from an older wiki is not a substitute for the documentation matching your deployment.
For a transcode, verify that the expected FFmpeg job has started and that its output reaches the RTMP destination configured for the YouTube ingest. Inspect the stream at the receiving side or with a suitable probe so you can confirm actual dimensions, frame rate, codec and bitrate. A configuration file states intent; the outgoing encoded stream is evidence of what was produced. For a pass-through, inspect the incoming and outgoing stream and expect the encoded video properties to remain unchanged.
Then check YouTube Live Control Room for the incoming stream’s status and health. YouTube recommends testing before going live and monitoring stream health during the event. A test should use representative movement and audio: a still screen can conceal problems that only appear when a scene changes, and silent testing will not reveal an audio path issue. Check that the stream stays connected and that the detected output matches your intended ingest settings.
Keep video and audio checks distinct. SRS video parameters do not prove that audio is present or correctly encoded. If your source uses a desktop playback path, the guide to capturing desktop audio in OBS Studio addresses that upstream concern. For a long-running channel, test beyond the moment the stream first appears live; a setting that works at startup still needs to remain stable under the actual ongoing workload.
If an adjustment makes the output worse, restore the known-good configuration rather than layering further speculative changes. Keep a note of the setting, its unit, the SRS version and what the probe or YouTube health display showed. That gives you a useful baseline for the next test and helps distinguish an encoder problem from a connection or destination problem.
Troubleshoot settings that have no effect
If changing vwidth and vheight has no visible effect, first ask whether an FFmpeg transcode is active. In pass-through mode, these parameters do not resize the encoded video. Check the actual output dimensions and trace which component encoded it; if the input and output match, you may be observing precisely what a relay is meant to do.
If resolution changes but bitrate does not, verify that you are changing the output bitrate field used by the active transcode, and confirm the field’s documented units. A target bitrate is not necessarily a guarantee that every second of a variable-rate output will show the same measured rate. Use a reasonable observation window and compare the stream with the configured target without assuming a single instantaneous reading proves failure.
If the output is not reaching YouTube, separate encoding from transport. Confirm that FFmpeg is producing the stream, that SRS is forwarding the intended output, and that the destination and stream key are correct and private. Review SRS and FFmpeg logs for connection, authentication or unsupported-parameter errors, then check YouTube’s Live Control Room status. A successful local encode alone does not establish that YouTube received it.
If the connection reports poor health, do not assume a higher bitrate will improve it. A higher output rate increases what the connection must carry. Test at a lower output setting if capacity is uncertain, and inspect network stability and competing traffic as well as the encoder. Conversely, if the stream is stable but the picture is visibly inadequate, investigate codec, source quality and actual encoded output rather than changing unrelated network settings.
If settings appear to be accepted but have no effect, check whether you edited the configuration file that the running SRS process actually loads, whether the stream uses the application or transcode job you changed, and whether a reload or restart is required. Compare the syntax with documentation for the deployed release. Avoid transplanting an entire old sample: it may demonstrate an idea without matching your version, credentials or YouTube destination requirements.
For an always-on channel, maintaining the computer and encoding process can itself become a source of overnight failures. StreamNeo addresses that specific operating burden by letting you upload a video and run a YouTube broadcast without keeping your own computer switched on; it does not change the need to select the right output or verify YouTube ingest settings. It is YouTube-only, so it is not a fit if your required destination is another platform.
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 change resolution on an SRS pass-through stream?
No. Pass-through forwards the encoded video rather than re-encoding it, so vwidth and vheight do not change that copied video. Change the upstream encoder or introduce an active transcoding step if you need a different encoded resolution.
Is SRS vbitrate entered in kbps or bps?
The documented SRS transcoding parameter uses kbps, while the corresponding FFmpeg value uses bps. Check the documentation for your deployed SRS version and the specific field you are editing; do not treat the numeric values as interchangeable.
Does a 1080p SRS output mean every YouTube viewer sees 1080p?
No. That is the encoded ingest output you send, not a guarantee about each viewer’s playback rendition. YouTube processes live ingest into multiple viewer formats, and playback options can differ.
Should I use YouTube’s recommended bitrate as my exact setting?
Use the current YouTube guidance for the codec, resolution and frame rate you are actually sending, then consider the reliability of your upload connection. Test with representative audio and movement, check the received output and monitor stream health rather than assuming a recommendation guarantees a stable broadcast.