When an encoder cannot publish through SRS, start by identifying the exact publisher, destination and SRS instance involved, then collect the log lines for one timed reproduction. Those details help you locate the stage that failed; they do not, by themselves, prove that SRS, YouTube, OBS or FFmpeg is at fault.
There is no universal SRS error list that maps every message to one fix. Version, deployment and configuration affect the evidence you see, so treat the checks below as a way to narrow the cause rather than as a guarantee that a particular message means the same thing everywhere.
Identify the publisher and SRS endpoint
Before changing settings, write down which application is publishing and where it is trying to connect. “YouTube is offline” is not enough to identify the failing leg. Your publisher may be sending to SRS, while SRS may be responsible for a separate downstream delivery path; or the publisher may be sending to a YouTube ingest endpoint directly. Confirm the actual route from the encoder’s configured destination.
Record the publisher name and version, operating system or container, protocol, destination host and port, application name, stream name, SRS version and deployment method. Note which configuration file the running SRS process uses. Add the time zone and timestamp for one controlled attempt. If a stream key appears in a configuration screen or logs, do not include it in notes that will be shared publicly.
SRS documentation describes a general media-server flow that receives or relays streams, with clients such as FFmpeg and OBS. Its getting-started example uses rtmp://localhost/live/livestream; that is an example, not a universal address. Substitute the host reachable from your publisher and the app/stream values expected by your SRS configuration. See the SRS introduction and getting-started guide for their respective versions.
Check that the target belongs to the process you think it does. A hostname may resolve differently inside a container than on the host machine. A loopback address such as localhost refers to the publisher’s own environment, not automatically to another server. If you run SRS on a separate machine, confirm that the publisher can reach that machine and the configured listener port.
Also distinguish “publisher cannot connect to SRS” from “SRS accepted the publisher but the stream is not visible at the intended destination”. Those are different observations and need different evidence. If you are building a local publishing workflow, the guide to adding background music to a nonstop stream from a VPS may help with the broader publisher setup, but it cannot substitute for checking the live target in your own configuration.
Collect the relevant SRS logs
Find the log sink for the SRS process that received the attempt. Do not assume every installation writes to the same file. The official SRS 7 getting-started material shows tail -n 30 -f ./objs/srs.log, but that example belongs to a particular documented workflow. Your package, container, service manager, working directory or configuration may send output elsewhere. Check the instructions for your installed release and inspect the running process or deployment settings before relying on a path.
Once you have found the log output, reproduce one publish attempt and capture a small window before, during and after it. Save the publisher’s own error text and its timestamp too. A server-side line without a client-side counterpart may be ambiguous; a client-side timeout without server output may mean the attempt did not reach that SRS process, or that you are looking at the wrong log sink.
Follow the sequence, not just the first line containing “error”. Useful context may include a client address, a connection or handshake, application and virtual host, publisher identification, stream name, metadata, packet arrival and disconnect information. The labels and exact message text vary by release. The archived SRS 4 log guide illustrates session-correlated traces, but do not expect its historical wording to match a current installation.
If the logs expose a session or client identifier, use it to narrow the captured interval. Otherwise, correlate with the timestamp, client address and stream name, allowing for clock differences between machines. Preserve the original lines before filtering or copying excerpts. When asking for help, redact credentials and stream keys, and include the SRS release and deployment context so another person can interpret the evidence accurately.
SRS also documents an HTTP API for status queries and names Prometheus export and session-level traceable logs as observability options. Use those surfaces if they are already enabled and appropriate to your deployment; they complement rather than replace the logs for a specific failed attempt. Their availability and setup should be checked against your installed release.
Check connection and publish details
Read the evidence in order from the publisher’s attempt. First ask whether a connection reached the expected SRS listener. If no corresponding session appears, verify the destination host, port, routing, firewall and listener configuration. Check name resolution from the publisher’s environment, not only from your laptop. A successful connection to a different machine or service does not establish that the intended SRS instance received the publish.
If a session appears, compare the requested application and stream name with what your configuration and downstream viewer expect. In an example such as rtmp://localhost/live/livestream, live is the application path and livestream is the stream name. A typo or unexpected path can produce a situation where a connection was made but the expected stream is absent. Match those fields at both ends rather than inferring them from a familiar URL shape.
Next, look for a configured publish authorization hook. If on_publish is enabled, SRS may ask an HTTP callback to approve the publisher. The SRS callback documentation says a successful response requires HTTP 200 and an error value of zero; a non-200 response or nonzero error value causes disconnection. The detailed page is for SRS 5, so verify the relevant configuration and behaviour against your deployed release. Inspect the callback request, the policy decision and the response actually returned, rather than concluding from the publisher’s generic disconnect message. See the SRS HTTP Callback documentation.
A callback can fail for reasons beyond an intentional denial. SRS may be unable to reach the endpoint, the callback may time out, or the application may return a response that does not match the expected format. Check both sides of that request if you operate the callback service. Avoid turning off authorization as a first test on a public stream; if you need to isolate it, use a controlled environment and restore the intended policy.
If the connection is present but packet arrival stalls, inspect the configured publish timeout and the observed timing. SRS 6 special-control documentation lists defaults of 20000 ms for the first-packet timeout and 5000 ms for the normal packet timeout. Those are configuration values, not a diagnosis. Compare the relevant timestamps and your actual configuration before considering any change; increasing a timeout without evidence can hide a stalled publisher rather than fix it. The SRS 6 special-control page is the primary reference for that release’s documented values.
| Evidence to compare | What it can help locate | What it does not prove |
|---|---|---|
| Publisher reports a connection failure; no matching SRS session is found | Wrong destination, reachability, listener or log sink | That SRS rejected a valid publish request |
| SRS session appears, followed by a callback decision and disconnect | Authorization or callback response path | That all disconnects are callback failures |
| Session appears but expected packets do not arrive promptly | Publisher output, stalled input or configured timeout | That raising the timeout is the right fix |
| SRS shows a publisher and stream, but viewing fails later | Playback path, protocol or downstream configuration | That publishing itself failed |
Compare encoder output with SRS ingest
When a session reaches SRS, compare what the encoder was asked to send with what SRS reports receiving. Begin with the publisher’s selected protocol and target, then check whether it reports a successful connection, begins sending media and remains connected. On the SRS side, look for the corresponding publisher and stream, metadata and incoming packet progression. The aim is to establish the last confirmed stage, not to translate one generic status into a complete diagnosis.
For FFmpeg, retain the command line with credentials removed and include the relevant output around the attempt. Check that the input opens, the chosen output URL has the intended app/stream, and the process continues sending rather than exiting or waiting on an input. For OBS, record the selected service or custom server, stream key handling without exposing the key, and the time its status changes. These clients expose different evidence, so do not assume that an OBS failure message and an FFmpeg exit have the same cause.
Compare timestamps carefully. A publisher can report that it connected before the first media packet reaches SRS. If SRS logs show a connection followed by a wait or timeout, the connection and the media flow are separate questions. Check whether the input itself is advancing, whether the encoder is producing output, and whether the SRS session records packets. Only investigate packet timing settings when the trace supports a delayed or missing-packet interpretation.
If you are troubleshooting audio or video inside the produced stream rather than the publish handshake, keep that separate from an SRS acceptance failure. For example, FFmpeg dropping Hindi audio in a 24/7 YouTube class stream concerns output content and encoding behaviour; an SRS log that never shows a publisher requires a different first set of checks. This distinction prevents you from changing codecs when the request never reached the ingest process.
Separate SRS errors from YouTube ingest errors
Write down each hand-off in the actual route. If the encoder publishes to SRS, the first publish decision is between that encoder and SRS. A later SRS-to-YouTube relay, if present in your design, is another leg with its own target and evidence. If the encoder publishes directly to YouTube, an SRS log may not describe that attempt at all. Confirm the configured destination before attributing a failure to YouTube or SRS.
A successful SRS publisher session establishes that SRS accepted a publishing connection and received whatever the trace shows. It does not establish that YouTube received a valid stream, that a downstream relay is configured correctly, or that a YouTube live event is healthy. Conversely, a message from YouTube does not show that SRS rejected the upstream publisher. Use the log from the component that made the failing connection and identify the endpoint it contacted.
For a route involving both systems, collect evidence at the boundary: SRS session and output status on one side, and the downstream client’s connection result on the other. Keep the two timestamps and destinations distinct. If SRS is receiving media but its downstream leg fails, investigate that leg’s URL, credentials and protocol configuration. If SRS never receives the publisher, start upstream instead. Do not apply a remedy from one side to the other just because both failures interrupt the same live programme.
For YouTube-side settings and ingest requirements, consult current official YouTube Help or developer documentation for the workflow you are using. The research available for this article establishes SRS publisher-to-server behaviour, not a single canonical SRS-to-YouTube configuration. That boundary matters: this guide is about evidence collection for SRS publish failures, not a promise that every YouTube ingest issue is visible in SRS logs.
Test a change and capture the result
Make one evidence-led change at a time. If the target path is wrong, correct only that path and reproduce. If a callback rejects the request, fix or test the callback decision in a controlled way. If packet timing is the concern, compare the configured values and observed intervals before changing a timeout. Changing the target, authorization policy and encoder settings together may produce a working stream, but it leaves you without a useful explanation of what was wrong.
Use the same publisher, input, destination and reproduction window when practical. Capture the client output and matching SRS lines again. Compare whether the connection reaches the expected listener, whether SRS identifies the expected application and stream, whether the callback decision succeeds if enabled, and whether packets arrive. Then check visibility through the protocol and path configured for your setup. A viewer-side problem after successful publishing should be recorded as a separate stage.
Keep a short change record with the previous value, the new value, the reason for changing it and the observed result. If a change makes no difference, restore it before testing another hypothesis unless there is a specific reason to retain it. This makes it easier to identify accidental regressions and to hand the issue to someone else without losing the evidence.
For a channel that depends on a file looping continuously, the operational question may be whether you need to keep a publisher running on your own computer. StreamNeo removes that particular need by letting you upload a video and provide the YouTube stream key for a cloud-run broadcast; it does not replace SRS log diagnosis where SRS is part of your route, and it is YouTube-only. If your choice is between a local machine and a managed loop, the playlist restart options for YouTube streaming are relevant to that separate operational decision.
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
Where do SRS publish logs usually appear?
It depends on the release and deployment. SRS 7’s getting-started guide shows ./objs/srs.log, but a package, container or service may direct output elsewhere. Check the active configuration, process working directory and deployment logs rather than assuming that example path applies to your installation.
Does an SRS disconnect message mean YouTube rejected the stream?
No. First establish whether the publisher was sending to SRS or directly to YouTube, and which component logged the disconnect. A successful SRS session and a later downstream failure are distinct from a publisher that never reached SRS.
Should I increase the publish timeout to stop a failure?
Only consider a timeout change if the trace indicates missing or delayed packets and you have checked the configured values. SRS 6 documents defaults, but configuration can differ and the values do not explain every failure. Capture a before-and-after reproduction so you can tell whether the change addressed the observed stage.
Is there one SRS error message list with a fix for every publish failure?
This guide does not provide a universal catalogue, and log text can vary by version and deployment. Use the session sequence, client output, callback evidence and endpoint details to locate the failing stage, then consult documentation for the release you run.