RTMP pull streaming means that a client connects to an existing RTMP server and reads a stream from it. You do not send a video source in a pull request, and you do not need to create a server when the stream is already available from a provider or another machine.
The practical setup is to obtain the correct read URL, enter it in a compatible player or command-line tool, and confirm that the client can receive both the connection and the media. The most important distinction is direction: pulling reads from a server, while publishing sends a source to a server.
What RTMP Pull Means
RTMP is a multimedia streaming protocol that carries audio and video over a network connection. In a pull workflow, the client starts the connection and asks an RTMP server for a stream that is already available at a particular path.
Think of the server as the place where the stream is being made available, and the client as the reader. A media player, FFmpeg process, monitoring tool or downstream video service can act as the client. The server may be a self-hosted application, a managed video platform or another service that provides an RTMP playback endpoint.
A pull URL might look like this:
rtmp://example.net/live/channel-a
That example is only a pattern, not a working address. example.net identifies the host, live may identify an application or service namespace, and channel-a may identify the stream path or playpath. The actual meaning of each part depends on the server software and its configuration.
The stream must already exist at that path. If nothing is publishing to it, or if the server has no stream with that name, a pull client cannot create useful video by connecting. It can only report that the requested stream is unavailable or that the connection has failed.
This distinction matters for an always-on channel. If you are trying to receive a feed from a remote broadcaster, you need its read address and any read credentials. If you are trying to send your own loop to YouTube, you need a publishing workflow instead. The two URLs may look similar, but they represent opposite directions.
Pull and Publish Are Opposite Workflows
Publishing is the act of sending a source to an RTMP server. The source might be a camera, OBS scene, an FFmpeg file loop or a live encoder. Pulling is the act of reading a stream that a server is already serving.
The direction can be shown simply:
| Workflow | Client action | What must already exist | Typical question |
|---|---|---|---|
| RTMP publish | Sends audio and video to a server | A server endpoint that accepts publishing | Where do I send my source? |
| RTMP pull | Reads audio and video from a server | A live stream at the requested path | Where do I read this stream? |
For publishing, the server administrator normally gives you an ingest address, a stream name or key, and sometimes a username and password. OBS and FFmpeg then push the source towards that endpoint. MediaMTX's FFmpeg publishing example shows this kind of direction with a local server.
For pulling, you need a playback or read address. Do not assume that an ingest URL can also be used as a read URL. Some services use separate hostnames, ports, paths or authentication rules for publishing and playback. Ask the provider for the RTMP read endpoint if it is not clearly documented.
A common mistake is to paste a YouTube ingest URL into a player and expect to watch the stream through RTMP pull. YouTube's stream key and ingest settings are intended for sending a broadcast to YouTube. They are not automatically an RTMP playback address for reading the broadcast elsewhere.
The same machine can perform both roles at different times. For example, an FFmpeg process may publish a file to a local RTMP server, while a second FFmpeg process pulls that stream and saves a copy. The first process is a publisher and the second is a reader. Keeping those roles separate makes errors much easier to diagnose.
Identify the Server, Port and Stream Path
Before opening a client, break the supplied URL into its parts. FFmpeg's protocol documentation describes RTMP URLs using a server address, an optional port and path components such as an application, instance and playpath. The exact arrangement is server-specific, so treat the URL you receive as a complete address rather than rebuilding it from assumptions.
For example:
rtmp://media.example.net:1935/live/news-east
Here is what each visible part tells you:
rtmp://is the plain RTMP scheme.media.example.netis the hostname of the server.:1935is the explicit TCP port. The service may use a different port, or omit it when the client can use its default./live/news-eastis the path supplied by the service. Depending on the server, part of it may be an application name and the remainder may be a stream or playpath.
A URL may also include credentials, query parameters or a different path layout. Do not add a stream key, username, password or slash because another platform uses one. Copy the documented address exactly, then check whether the password contains characters that need special handling.
The hostname tells the client where to connect, but not whether the stream is live. The path selects the stream after the connection reaches the server. A correct hostname with the wrong path can produce a connection that appears to work briefly while still returning no media.
The port is also significant. A network may permit ordinary web traffic while blocking the RTMP port required by the service. If the provider gives an explicit port, retain it in the URL. If the provider does not give one, use the documented endpoint rather than guessing.
Plain RTMP is not encrypted. RTMPS is the TLS-encrypted variant, normally written with an rtmps:// scheme or an equivalent secure endpoint. The MediaMTX OBS documentation discusses encrypted RTMP publishing and certificate configuration. A secure endpoint still needs client and server support, and the client must be able to trust the certificate.
Connect a Client to the Existing Stream
FFmpeg is useful for a repeatable read test because it exposes the input URL and reports connection details in the terminal. For a stream that already exists, the basic shape is:
ffmpeg -i rtmp://example.net/live/channel-a -c copy output.mp4
Replace the example URL with the actual read address. The -i option supplies the input. The -c copy option asks FFmpeg to copy the incoming streams without re-encoding them. This can reduce processing work, but it does not guarantee that every source can be written directly into every output container.
The MediaMTX FFmpeg reading guide documents this pattern for reading a stream. Its example uses a local RTMP path, so the host and path must be changed for your service. A local address such as localhost refers to the same computer where the command is running; it does not refer to a remote provider.
To inspect a stream without immediately saving it, you can use FFmpeg's input handling and watch the terminal output. A successful connection should show that the input has been opened and should identify the media streams or their detected formats. The exact messages vary with the FFmpeg build and source.
If your purpose is to pass the received stream into another workflow, choose the output deliberately. Saving to an MP4 file is useful for a short test, but a long-running relay may need a different output format and a policy for reconnecting when the source disappears. The read command proves that the client can receive the stream; it does not by itself make a reliable 24/7 relay.
You can also use a compatible media player or monitoring application. The same principle applies: enter the read URL as the network source, not as a publishing destination. If the player asks separately for a server address and stream name, use the provider's documented mapping rather than splitting the URL at an arbitrary slash.
For readers working towards a continuous YouTube channel, the separate FFmpeg command for a 24/7 YouTube loop stream covers a publishing-oriented loop. That is useful when your own file is the source, but it is not the same operation as reading an existing RTMP feed.
Run a Read Test Before Building Anything Larger
A read test should answer three questions in order:
- Can the client reach the host and port?
- Does the server accept the request for this path and any credentials?
- Does the client receive usable audio or video?
Start with the exact read URL and a short output target. Do not change several parts at once. If the command fails, you want to know whether the problem was the hostname, port, path, authentication or media format.
A simple test command is:
ffmpeg -i "rtmp://example.net:1935/live/channel-a" -c copy test-output.mp4
Use quotation marks when the URL contains characters that your shell could interpret. For a quick test, stop the command after you have confirmed that media is arriving and that the output can be opened. The file is evidence that the client received data, not proof that the source will remain live overnight.
Watch the diagnostic output rather than relying only on whether a window opens. A connection message followed by an authentication error points to different work than a timeout. An input that opens but reports no usable streams points towards the path, source state, codec or server configuration.
If the source contains more than one media stream, note what FFmpeg detects. You may receive video without audio, audio without video or multiple tracks. That can be expected for the source, but it matters if the next application requires both. The source's codecs also need to be supported by the output container or the receiving application.
Do not use a local read command as proof that a remote endpoint is available unless the local server is actually serving the same path. A local demonstration has its own server, publisher and reader. A remote read test has a provider or administrator responsible for the server and an existing upstream stream.
For an always-on YouTube operation, document the working URL, the client command, the expected media tracks and what should happen after a disconnect. If the source is your own prerecorded material, a managed workflow can remove the need to leave your personal computer running; StreamNeo is designed for uploading a file once and keeping a YouTube broadcast running while its own monitoring handles a dropped connection.
A Local Demonstration Needs a Server and a Publisher
You do not need to create a server to test an existing stream. You only need one when you are constructing a private demonstration or operating the source side yourself.
A local demonstration has three pieces:
- an RTMP server listening on a local address;
- a publisher sending a source to a named path; and
- a reader pulling that path.
MediaMTX documents a local FFmpeg publishing pattern like this:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
The -re option makes FFmpeg read at approximately the source's normal playback rate, while -stream_loop -1 repeats the file. The -f flv option selects the format used in the documented RTMP publishing example. The command assumes that a MediaMTX server is already running and accepting publishing at that address.
A second terminal can then read the path:
ffmpeg -i rtmp://localhost:1935/mystream -c copy output.mp4
This is a controlled test because you own each component. If it fails, check that the server is running, the publisher has not exited, the path is identical in both commands and the port matches the server configuration.
OBS can also act as the publisher. Its custom streaming settings normally require a server URL and, depending on the server, a stream key or path. The exact fields vary. MediaMTX's OBS publishing guide uses its own example conventions, so do not transfer those values to another service without checking that service's instructions.
The local pattern is valuable because it shows the direction clearly: FFmpeg or OBS sends the source into the server, and another client reads it back. It should not be mistaken for a requirement to operate a server before connecting to a stream that someone else already provides.
Troubleshoot URL and Connection Details
Start troubleshooting with the address, not with advanced encoding settings. Confirm that the stream is live at the expected path and that the provider has given you a read endpoint. A publishing address may reject a reader even though it is a valid RTMP URL.
Then check the following points:
- Hostname: confirm spelling and whether the provider supplied a regional or separate playback hostname.
- Port: retain an explicit port. A blocked or incorrect port can cause a timeout before the path is examined.
- Scheme: use
rtmp://for plain RTMP or the provider'srtmps://endpoint for encrypted RTMP. Do not describe plain RTMP as encrypted. - Path: copy the application and stream path exactly, including capitalisation where the server treats names as distinct.
- Credentials: verify whether read authentication is required and whether credentials belong in the URL or in separate client fields.
- Source state: make sure another system is actively publishing to the path if the service does not retain streams when the publisher stops.
- Codec support: confirm that the client and the next output can handle the received audio and video formats.
A connection refusal often means that no service is listening at the address and port, or that a firewall is rejecting the connection. A timeout can indicate routing, firewall or hostname problems. An authentication error points to credentials or permissions. A successful connection with no media commonly points to an incorrect path or a source that is not currently publishing.
If the URL contains a password with reserved characters, use the credential method recommended by the client or provider. Copying a password into a URL can cause characters such as @, ? or # to be interpreted as URL syntax. Avoid exposing complete URLs containing credentials in screenshots, logs or support posts.
When testing from a business, school or office network, try to establish whether outbound RTMP or RTMPS connections are restricted. A test from a different network can separate a local firewall problem from a server or URL problem, but it does not prove that the original network will support an overnight connection.
MediaMTX documents RTMP reading but recommends RTSP for its own FFmpeg reading workflow. Treat that as a MediaMTX-specific recommendation, not a universal ranking of protocols. If the provider only offers RTMP, use its documented RTMP read endpoint and focus on the client and network requirements that apply to your setup.
For an always-on YouTube channel, also separate source failure from publishing failure. If a downstream broadcast stops, first check whether the RTMP pull client is still receiving data. If it is not, investigate the source URL. If it is receiving data but YouTube is offline, investigate the separate publishing connection. Guides such as how to restart a YouTube livestream automatically when FFmpeg stops address the publishing process rather than the read endpoint itself.
Choose the Right Operating Arrangement
The simplest arrangement is to pull an existing stream for monitoring, recording or further processing. You rely on the source owner for the server, path and availability. Your work is to use the correct read URL and keep your client connected.
A self-hosted arrangement gives you control over the server and the stream path. It also gives you responsibility for the server process, network reachability, authentication, certificates and recovery after a failure. The local MediaMTX and FFmpeg examples are suitable for learning the direction of the workflow, but a production setup needs its own operational checks.
A managed video workflow may provide an RTMP pull input, allowing a service to receive an existing source without you running every component yourself. AWS MediaLive's user guide documents RTMP pull input configuration, including source URL arrangements. Check the current vendor documentation for eligibility, supported formats, authentication requirements and terms before choosing such a service.
Compare arrangements using practical questions rather than a claimed universal performance result:
| Question | Existing provider stream | Self-hosted server | Managed pull input |
|---|---|---|---|
| Who supplies the server? | Provider or source owner | You | Managed service |
| Who controls the path? | Provider | You | Service and source configuration |
| Who handles access details? | Provider and client | You | Service, source owner and client |
| What must you operate? | Reader and downstream workflow | Server, publisher and reader | Service configuration and downstream workflow |
| Main failure to isolate | Source availability or read URL | Any of the three local components | Source, service input or downstream output |
If your actual goal is to keep a prerecorded devotional, study or ambience channel running on YouTube, RTMP pull may not be the central workflow. You may need to publish your own file or playlist to YouTube instead. For examples aimed at that use case, see the 24/7 English practice channel setup and check the separate publishing requirements.
The useful habit is to label every connection by direction. Write “source to server” for publishing and “server to client” for pulling. That small note prevents a large class of setup mistakes, especially when a service gives you several URLs with similar names.
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
Do I need to create an RTMP server before pulling a stream?
No. If a provider or another operator already serves the stream, you need its read URL and any required credentials. You only need to run a server for a self-hosted test or for an arrangement where you are responsible for making the stream available.
Is an RTMP pull URL the same as a YouTube stream key?
No. A YouTube stream key is used with an ingest setup to publish a broadcast to YouTube. An RTMP pull URL tells a client where to read an existing stream, and it may use a different host, path and authentication method.
Can FFmpeg pull and save any RTMP stream as MP4?
FFmpeg can read an RTMP URL, and the stream-copy pattern is useful for testing. However, the source codecs and tracks must be suitable for the output container, so a successful network connection does not guarantee that every source can be copied directly into MP4.
Is plain RTMP encrypted?
No. Plain rtmp:// is not encrypted. Use the provider's RTMPS endpoint when secure transport is supported, and confirm that the client trusts the endpoint's certificate.