FFprobe can tell you whether a local media source opens and what audio and video streams it contains. It cannot confirm that YouTube will accept your broadcast: to check RTMP connectivity, publish a separate test live stream to the event’s current URL and key, then verify receipt in Live Control Room.
That distinction saves time when a stream will not start. A successful local probe narrows the problem to the publisher or path to YouTube; a failed probe points first to the source. Neither result, on its own, proves that a live event is ready for viewers.
What FFprobe can check in a local input
FFprobe is a media-inspection tool included with FFmpeg. Point it at a file or supported capture input to see whether it can open the source and report its streams and format details. For a local file, this is a useful starting command:
ffprobe -hide_banner -v error -show_format -show_streams input.mp4
Replace input.mp4 with the path to your actual file. The output can show whether the file contains a video stream, an audio stream, or both, and report properties such as codec, dimensions, frame rate, sample rate and channel layout. This helps answer practical questions before you configure a publisher: is the intended clip readable, is there audio to send, and does the file have the picture and sound you expect?
That is the boundary of the check. FFprobe does not log in to YouTube, validate your stream key, test the whole route through a firewall or proxy, confirm a TLS connection, or show whether YouTube is processing your feed. A successful probe means that this local inspection worked. It does not mean your encoder has connected to the ingest service or that a viewer can watch the event.
Do not treat a TCP port check or an RTMP handshake as the last step either. Those can offer clues about a network or protocol failure, but a socket connection alone does not demonstrate that YouTube accepted a valid publish or received a healthy audio-video feed. The practical test is a real publish to the intended event, followed by confirmation in YouTube’s preview and stream-health display.
If you are working with a rotating set of clips rather than one file, first make sure your playback setup can handle the sources you plan to use. The guide to looping Kannada educational videos on YouTube Live covers the separate job of arranging files into a continuing broadcast; it does not replace checking a local input and then testing ingest.
Inspect expected audio and video streams
Run the probe on the same source you intend to send, not a convenient sample that happens to be nearby. Read the stream list and compare it with the content you expect. A video channel may need both picture and sound; a silent ambience station may intentionally use a different combination. The important question is whether the expected tracks are present and usable for your planned stream.
Check the codec and video dimensions against what your encoder can decode and what you intend to send. Note the reported frame-rate information, but remember that media can report rates in different ways and a file’s nominal rate is not a guarantee of smooth motion after encoding. For audio, check sample rate and channel layout as well as whether the stream exists. If a devotional recording is expected to be stereo but the file has no audio stream, that is a source issue to resolve before investigating YouTube.
A compact output can be easier to review when you are checking a file repeatedly:
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,width,height,avg_frame_rate -of default=noprint_wrappers=1 input.mp4
You can inspect audio separately by selecting a:0 and requesting properties such as codec_name, sample_rate and channel_layout. These are examples of FFprobe’s reporting options, not a recommendation that every stream use one fixed codec, resolution or rate. Choose encoding settings for your source, intended quality and current YouTube guidance.
If FFprobe reports an error opening the file, check the path, file permissions, container and whether the file is damaged. If the file opens but an expected stream is missing, choose a different source or repair the input workflow. Do not respond to a missing audio track by changing the YouTube URL: the URL cannot add audio that is absent upstream.
A capture device is different from a file. Device names and input syntax depend on the operating system and on the FFmpeg build installed there. Do not assume the file command above will work unchanged for a camera, capture card or microphone. Use the input syntax supported by your platform and verify that FFprobe can see the device before moving on to a live test.
Use the event’s current YouTube URL and key
For the publish test, open the intended scheduled or test stream in YouTube Studio’s Live Control Room. Copy the server URL and stream key shown for that event into the encoder you will use. YouTube’s encoder setup guidance explains the setup flow. Avoid reusing a URL or key copied from an old stream, an unrelated event or an article: the values shown for the current configuration are the ones to use.
Treat the key as a password. Do not put it in a public troubleshooting post, ticket, screen recording or command example. A command typed directly into a shell can also be recorded in shell history or process listings, depending on the environment. Prefer an encoder interface or a suitably protected method for supplying credentials, and redact the key from logs before sharing them. If you think the key has been exposed, use Live Control Room to reset it and update the publisher configuration.
Confirm that the configured protocol matches the endpoint YouTube supplies. YouTube offers RTMPS, which it describes as RTMP over a TLS/SSL connection, and documents the relevant setup and troubleshooting on its RTMPS help page. Do not assume that changing rtmp to rtmps in a URL is enough: the client must support the protocol and the server address must be the matching endpoint.
For a rough map of the pieces involved, an RTMP publishing address commonly includes a host, application path and stream key. FFmpeg’s protocol documentation describes the RTMP URL form and protocol options. YouTube’s current event configuration is authoritative for the actual URL and protocol to publish to; do not substitute a fixed address from a generic example.
Run a test live stream
Choose a private or unlisted test event where that suits your channel and YouTube’s available controls. Use a short, representative source: moving picture and the sort of audio you actually plan to broadcast. A still test pattern may prove that an encoder can generate and send video, but it will not exercise your camera, microphone, capture card, production scene or original media file. Select the test input to match the failure you are investigating.
For a file-based test, a generic FFmpeg command can illustrate the shape of a publish:
ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv 'rtmp://HOST/APP/STREAM_KEY'
This is a pattern, not a tested command for your particular operating system, FFmpeg build, codecs, source or current YouTube endpoint. Replace the placeholder URL with the event’s exact URL and key, and confirm that your FFmpeg build supports the required input, codecs and protocol. Avoid leaving a real key in shell history or output that you intend to share. The -re option reads a file at its recorded rate, which is useful for a file-based test rather than sending it as fast as the machine can process it.
You can also generate a test pattern with an FFmpeg lavfi input when the installed build has the needed filters. That can isolate encoder-and-ingest behaviour from a suspect media file, but it cannot tell you whether the real camera or soundtrack works. Conversely, testing with the actual source exercises more of the intended chain but makes it harder to isolate a failure if the source itself is faulty.
YouTube recommends setting up ahead of the event and checking the preview before starting. Its streaming tips also advise testing representative motion and audio, and leaving upload headroom. Use an actual outbound upload check rather than assuming that a strong download result means the uplink can carry a broadcast. YouTube recommends roughly 20% headroom above total stream bitrate; account for the combined bitrate of primary and backup encoders if you use both.
A short test is useful only if it resembles the production route. If production will use a different computer, network, encoder profile or source, a test on a laptop over another connection has limited value. Run the test with the machine and network you plan to use where practical, and note any changes made during diagnosis so you can return to the intended configuration.
Confirm preview and health in Live Control Room
After starting the publisher, wait for the event preview to appear in Live Control Room. Check that YouTube shows incoming video and that the image moves as expected. Listen for the intended audio in the preview where available; a picture alone is not proof that a music or speech channel’s sound is present. Check the stream-health status and any messages rather than treating the encoder’s “connected” message as final success.
YouTube’s own guidance is to preview before going live. A preview confirms that YouTube is receiving enough of a feed to render there, but you should still inspect the event and, when appropriate, its viewer-facing watch page. A feed may reach preview while audio, visual quality or stability still needs attention. Confirm the details that matter to your audience: the right picture, intelligible or intentional sound, and a stable health indication during a representative test.
Do not make the test more public than it needs to be. Set the event’s visibility deliberately, tell anyone helping with the check which event to watch, and avoid publishing a credential or leaving a test event live by accident. Before your real broadcast, confirm that you are configuring the correct scheduled event and that the test has not replaced or disrupted the production stream.
For a 24/7 station, one successful preview is a useful checkpoint, not a guarantee that every later hour will be trouble-free. Source changes, network conditions and a long-running playback process can introduce separate problems. If the underlying question is whether viewers are seeing delay or a stalled picture, the guide to live stream lag versus buffering helps distinguish symptoms after the stream reaches YouTube.
Separate input, encoding, URL/key and network issues
Use the sequence of observations to narrow the fault rather than changing several things at once. The table describes what each result suggests and what to check next; it is not a claim that one symptom identifies a single cause.
| What you observe | What it establishes | Next check |
|---|---|---|
| FFprobe cannot open the source | The local inspection did not succeed | Check the path, permissions, file health or platform-specific capture input |
| FFprobe opens it, but expected audio or video is absent | The inspected input does not contain the expected track | Select or repair the source before testing ingest |
| FFprobe succeeds, but the publisher cannot connect | The source can be inspected; YouTube receipt remains unconfirmed | Check event URL, protocol, key, client support and outbound network policy |
| RTMPS reports an SSL error | The secure connection attempt failed | Verify the RTMPS endpoint and client support; YouTube advises trying port 443 where appropriate |
| The publisher reports connected, but there is no preview | A client-side connection message is not proof of a rendered YouTube feed | Check event selection, stream health, encoder output and the current URL/key |
| Preview appears but quality is unstable | YouTube is receiving a feed, but quality needs attention | Check upload capacity, aggregate bitrate, source and encoder health |
If the publisher cannot connect, copy the URL and key again from the intended event and verify the scheme and protocol. An invalid key, an endpoint mismatch, a client without RTMPS support, a firewall or proxy rule, and a weak outbound path can produce overlapping symptoms. Change one variable at a time and retry so the result tells you something. YouTube’s streaming error guidance is a useful reference for messages and next checks.
For an RTMPS SSL error, first make sure both the configured protocol and endpoint are the secure RTMPS ones from Live Control Room. YouTube advises trying port 443 when addressing this error. A timeout is less specific: it can arise from a wrong URL or lack of client support as well as a network path problem. Do not infer the cause from the timeout alone.
If a preview appears but degrades, compare the total outgoing bitrate with the upload capacity available at the publishing location, leaving the headroom YouTube recommends. When primary and backup encoders are both sending, consider their combined outgoing load. Download speed is not a substitute for outbound capacity. Review the encoder’s output and source quality as well as Live Control Room health messages; a local file that probes correctly can still be encoded poorly or sent inconsistently.
If the source itself is the weak link, fix that before rebuilding the network configuration. If the ingest connection is the weak link, retain the known-good local input while checking URL, key, protocol and network in sequence. For readers choosing a publishing workflow for a longer-running file stream, the comparison of OBS and IRL Pro for pre-recorded streams may help frame which software path they need to test; whichever tool you use, the ingest confirmation still belongs in Live Control Room.
Once you can see the intended media and sound in preview with acceptable stream health, you have evidence that the tested route worked at that time. Keep a note of the source, encoder settings and event used, but store credentials separately and securely. Repeat the test after material changes to the publisher, source, network or event configuration rather than assuming an earlier probe or handshake covers the changed setup.
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 FFprobe test whether YouTube RTMP is reachable?
Not by inspecting a local file. FFprobe can report whether it opens the input and what media streams and properties are present; a separate publish test is needed to check YouTube ingest. Confirm receipt in Live Control Room rather than treating local output as proof of connectivity.
If FFprobe succeeds, why will my YouTube stream not start?
The local source may be readable while the event URL, stream key, protocol, encoder support or outbound network is wrong. Check the current values in the intended Live Control Room event, keep the key private, and use the publisher’s error together with YouTube’s stream-health information to narrow the cause.
Does a connected message or RTMP handshake prove the stream is healthy?
No. It is useful evidence about part of the connection attempt, but it does not establish that YouTube is rendering the expected picture and sound or that the event is stable. Look for the preview and health status, then verify the viewer-facing event if needed.
What should I use for a test live stream?
Use a short source that represents the production setup you need to validate, including motion and audio when those matter. A generated test pattern can isolate encoding and ingest, while the real file or capture setup checks more of the full chain. In either case, publish to a test event with its current URL and key, then confirm the result in Live Control Room.