To send a pre-recorded playlist to YouTube Live with GStreamer, your application must select and open each media item, while a GStreamer pipeline decodes, normalises, encodes and publishes the output. The RTMP sink sends a stream; it does not schedule or advance a playlist.
Start by proving that one short video reaches YouTube’s preview, then add playlist control and test transitions. This separation matters: a working connection for one file does not mean a multi-file channel will advance cleanly or stay coherent overnight.
Keep playlist control outside the RTMP sink
Think of the system as two cooperating parts. The media pipeline turns the current source into a continuous encoded output and sends it to YouTube. Application logic decides which source to play, when it has ended, what to open next, and how to handle errors. The distinction is like a projector and a screening schedule: the projector displays a source, but it does not choose the next film.
GStreamer documents rtmpsink as an element for delivering data to a streaming server over RTMP, and its input is FLV content. That role is at the end of the publishing path. It has no responsibility for choosing a URI, interpreting a playlist, or reacting to a decoded file reaching its end. The GStreamer rtmpsink reference is useful for checking what the element accepts and which plugin provides it.
For a playlist, keep an ordered list of media locations in your own application. When one item finishes, the controller needs to observe the relevant end-of-stream event, select the following item, open it, and arrange for its decoded tracks to feed the normalisation and output stages. The exact design depends on the application and the mix of source files. Do not assume that swapping a filename will preserve timestamps or maintain a gap-free stream.
A robust goal is a stable encoded and muxed output feeding one RTMP connection, with the media source changing behind it. That is a design target, not a guarantee that arbitrary files can be switched seamlessly. Timestamp continuity, encoder behaviour, audio gaps, and YouTube ingest all need testing on the machine and GStreamer build you intend to use.
GStreamer’s multifilesrc reads a sequentially named set of files into buffers. That can suit a numbered sequence, but it is not a general scheduler for unrelated videos with different containers, codecs, dimensions or durations. The multifilesrc documentation describes the source’s role; it should not be read as evidence that it will decode and coordinate a heterogeneous video playlist for you.
If the channel needs calendar scheduling, rotation rules, or recovery after a failed item, implement those decisions at the application level as well. A daily devotional playlist, for example, might contain an opening prayer, a sequence of bhajans and a closing item. The scheduler chooses what comes next; the pipeline is responsible for producing a valid stream from the chosen item. For broader operational planning, see how to loop a YouTube playlist as a 24/7 livestream.
Select and inspect the next media item
Before opening a file, check that it exists, is readable and is the item you expect. A controller can maintain a list of paths or URIs, keep a current position, and record which item is being attempted. It should have an explicit policy for a missing or unreadable file: skip it, retry it, or stop for operator attention. Without such a policy, one bad item can leave the source stalled while the RTMP connection remains open.
Inspect representative files before building the playlist. Record container, video codec, dimensions, frame rate, audio codec, sample rate, and channel layout. You do not need every source to match, but the differences tell you what the decode and conversion stages must handle. A file with no audio track, for example, requires a deliberate decision about whether to send silence or change the output design; a video-only branch cannot by itself supply the audio input expected by a typical muxed programme.
Use a short, rights-cleared clip for the first test. Confirm that GStreamer can discover its streams and decode them on the target host. Then test a second file with different properties, such as a different resolution or audio layout. This catches assumptions that a single-file test cannot reveal. A numbered set of similarly formatted clips may be simpler than a playlist assembled from old recordings, but it still needs end-of-item control if each file must be opened separately.
For an initial prototype, a higher-level GStreamer playback or URI API can be easier to manage than manually rebuilding a command for every file. Your application can listen for bus events and respond to end-of-stream or errors. The GStreamer gst-launch-1.0 guide presents the command-line launcher as a basic pipeline and debugging tool; for playlist transitions and long-running control, use an application built with the GStreamer API rather than treating a shell command as the scheduler.
Keep a small operational record: current file, last successful start, last end-of-stream event, and any error message. Avoid writing a YouTube stream key into logs. This information helps distinguish a bad media item from a failed network connection and makes overnight recovery more deliberate.
Demux and decode each source
A media container can hold one or more encoded streams. A demuxer separates those streams; decoders turn compressed audio and video into raw media that later elements can convert and encode. GStreamer’s uridecodebin or a filesrc followed by decodebin can form the discovery and decode portion of a single-file pipeline. The choice depends on whether your application supplies a URI and how you want to manage dynamic audio and video pads.
A conceptual single-file path branches after decoding. The video branch passes through video conversion and any needed scaling or frame-rate handling, while the audio branch passes through audio conversion and resampling. Both branches then feed suitable encoders, and the encoded outputs are linked to a muxer. This is a map of responsibilities, not a copy-and-run command: actual element names, caps and pad linking depend on the plugins installed and the source streams present.
Dynamic pads deserve attention in an application. A decoder may expose audio and video pads based on the current file, and a file may omit one type. Your code needs to identify the available streams and connect the relevant branch without assuming every item is identical. If you switch to a file with a different stream layout, verify that the controller and pipeline handle the change rather than leaving an old branch attached or waiting forever for a pad that never appears.
Check the installed GStreamer elements before designing around them. A system may have a decoder for one source codec but not an encoder for your intended output. Tools such as gst-inspect-1.0 can help inspect elements and properties, while gst-launch-1.0 can isolate a short test pipeline. Test on the same operating system and runtime package you will use in production; a development machine with extra plugins can conceal a missing dependency.
Do not treat successful decode as proof of a sound playlist transition. The next file may begin with timestamps that do not continue from the previous one, and restarting portions of the graph may also affect encoder state. Determine whether your chosen architecture resets, segments, or otherwise manages time, and validate the resulting stream at the YouTube preview and in a recording. If your schedule misses an item rather than failing at ingest, troubleshooting a YouTube livestream schedule that misses a video addresses the scheduling side of that problem.
Normalise audio and video output
The output should have a consistent profile even when source files differ. Video conversion can handle pixel format changes and may be paired with scaling or frame-rate conversion where required. Audio conversion and resampling can align channel layout and sample rate with the output profile. Normalisation makes downstream encoder and muxer negotiation more predictable; it does not make a poor source look or sound better.
Decide what to do with differing aspect ratios before scaling. For instance, a portrait phone recording inserted between landscape bhajans could be fitted inside a landscape frame with unused space, cropped, or presented with a designed background. Each option changes the picture, so preview the result rather than relying on a conversion element to make an editorial choice for you.
Audio needs the same practical care. One source might be stereo and another mono; one may be much quieter or louder. Conversion can produce a consistent format, but loudness matching is a separate processing decision. Listen to transitions with headphones or speakers, including the first and last moments of each file. A brief silence at a boundary may be acceptable for a scheduled programme, but it may be disruptive in a continuous music or ambience channel.
Set explicit output caps where they help ensure a predictable encoder input. Caps describe negotiated media properties such as dimensions, frame rate, pixel format, sample rate and channel count. The exact values should follow the source material, your desired presentation and YouTube’s current recommendations. Keep the setting consistent across items unless there is a reason to change it, and test any change through the entire mux-and-ingest path.
This is also where you plan the transition policy. If the next item has different dimensions or frame rate, conversion should bring it into the output profile before encoding. However, whether a particular pipeline can keep its encoder running while source pads change is an implementation question. Do not promise a seamless transition until the timing, output and actual ingest have been observed on the target setup.
Encode for a supported YouTube profile
YouTube’s encoder settings guidance lists RTMP and RTMPS ingest and supported video and audio formats. H.264 video with AAC audio is a conservative compatibility starting point when the required GStreamer plugins are available. YouTube also lists other codecs, but the formats allowed by YouTube do not mean that your local installation contains a matching encoder. Check element availability and caps before settling on a profile.
YouTube recommends constant bitrate encoding and a two-second keyframe interval, with the interval not exceeding four seconds. These are output settings to configure and verify in the selected encoder, not properties created by rtmpsink. Encoder element properties vary, so inspect the installed element documentation and confirm what value is actually applied. For the current requirements and recommendations, consult YouTube’s live encoder settings.
Choose resolution, frame rate and bitrate together. The YouTube guide lists 1080p30 H.264 with a 5 Mbps minimum and 14 Mbps recommended bitrate. Those are YouTube’s listed figures, not a promise that a particular internet connection or computer can sustain them. Other resolutions and codecs have their own guidance; consult the current table rather than extrapolating from 1080p30.
Leave upload headroom for normal network variation and other traffic. A bitrate that matches a table can still fail if the available upload is inconsistent, and an encoder’s nominal rate does not prove that packets reach YouTube reliably. Test the actual encoded stream while monitoring YouTube’s stream health. If you want background on matching a machine and connection to a sustained stream, compare it with using a cloud server to stream pre-recorded videos to YouTube continuously.
Mux to FLV and publish through RTMP
After encoding, connect the video and audio encoders to flvmux, then send the muxed FLV output to rtmpsink. GStreamer’s RTMP sink documentation gives a test-video example that illustrates the relationship between a muxed FLV stream and the sink. It is not a full YouTube-ready audio-and-video playlist recipe. In practice, the encoders, caps and linking need to match the plugins on your host and the streams your application supplies.
The RTMP plugin is part of GStreamer Bad Plug-ins, so a minimal installation can lack rtmpsink. Check for it before writing the rest of the publishing logic. Also verify that flvmux and the chosen encoder elements are installed. If a pipeline reports a missing element, resolve the local plugin dependency rather than changing the YouTube key or assuming the ingest service is at fault.
In Live Control Room, create or select the live stream and copy the server URL and stream key shown for that stream. Configure the sink with the current endpoint information supplied there, using RTMPS when your installed stack and the provided endpoint support it. Do not reuse a URL from an old tutorial as if it were universal. YouTube describes the stream key as sensitive credentials; keep it out of screenshots, source control, shared command history and diagnostic logs. If exposed, reset it in Live Control Room and update the application. See YouTube’s encoder setup instructions for the current workflow.
The first proof should use one short file and a test or unlisted event. If there is no preview, check the endpoint, key, protocol, network reachability and Live Control Room stream health. A successful RTMP connection is only one part of the test: verify picture, sound, motion, resolution and continuity. A local pipeline can start without the broadcast being ready to make public, so follow the current preview and go-live controls in Live Control Room.
When application code changes sources, avoid repeatedly tearing down the publishing connection without knowing the effect on the event. Decide how the application handles a source error, a reconnect, or an end-of-stream while the output is live. Test the selected behaviour with a recording, because a preview alone may not reveal every boundary issue. StreamNeo removes the need to keep a personal computer running to send an uploaded file continuously, which can matter when the specific pain is maintaining a home machine through the night.
Test the preview and playlist transitions
A useful test sequence starts simple and adds one variable at a time. First inspect the local pipeline and confirm both encoded branches reach the mux. Then send one short item to YouTube and check the preview and stream health. Only after that should you add a second file, a different source format, and the controller that advances on end-of-stream. This makes faults easier to locate than introducing a scheduler, mixed codecs and a live event at once.
At each boundary, check whether the next picture appears, whether audio continues or restarts as intended, and whether the stream remains healthy. Watch for frozen video, black frames, silence, a sudden resolution change, or a delay before the next item. Save a recording of the test and inspect the boundary afterwards. YouTube says streams under 12 hours are automatically archived; for recurring prerecorded programming, check the current Live Control Room lifecycle and archive behaviour rather than assuming a single connection can run indefinitely.
Test the kinds of variation your real playlist contains: different resolutions, frame rates, audio layouts, durations, and files with no audio. Repeat a transition after changing the order, because a controller can work for one sequence and fail at another. If the source is interrupted or corrupt, confirm that your error policy takes effect and that an operator can tell what the channel is doing.
For scheduled streams, coordinate the application’s start with the preview and go-live workflow, then end the event according to YouTube’s current controls. Do not assume that a process running on your computer means the scheduled broadcast is already live. YouTube’s live streaming workflow guidance explains the control-room steps; check it directly because the interface and available workflow can change.
A command-line pipeline is valuable for isolating one problem, but it is not by itself a production scheduler or recovery plan. If a stream is meant to continue overnight, decide who receives an alert, what happens after a failed item, and how you will know whether YouTube is receiving valid audio and video. A system that merely reconnects without restoring the intended playlist state may be online but showing the wrong item.
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
How do I stream a video file to YouTube Live with GStreamer?
Build a pipeline that reads and decodes the file, normalises its audio and video, encodes both branches, muxes them as FLV, and sends the result to rtmpsink. Use the server URL and stream key shown in Live Control Room, and first test with a short clip. The exact elements and caps depend on the GStreamer plugins installed on your host.
Does rtmpsink loop or advance a playlist?
No. It sends FLV content to an RTMP server; it does not select the next file or schedule playback. Your application must handle source selection and end-of-stream, then ensure that the next item can feed the output pipeline correctly.
Why is there no YouTube preview when the pipeline starts?
Check that the correct current URL and key are configured, the endpoint and protocol match, and your network can reach the ingest service. Confirm that the installed pipeline has working encoders, flvmux and rtmpsink, and inspect Live Control Room’s stream health. A process starting locally does not prove that YouTube is receiving valid audio and video.
How do I keep video playing while switching to the next file?
Have application logic observe the current item ending, select the next URI, and connect its decoded media to the normalisation and encoding path. Test timestamp continuity, encoder behaviour, audio gaps and the resulting YouTube ingest across the file boundary. Do not describe a switch as seamless until it has been verified in your actual setup.