“YouTube playlist” can mean videos already arranged in a YouTube playlist, or your own media files sent as a continuous YouTube Live broadcast. This guide covers the second workflow: keep files you own or are authorised to rebroadcast on a Hetzner server, then use FFmpeg to send them to YouTube Live.
A YouTube watch-page playlist URL is not established here as a supported FFmpeg input or as a rights-cleared source. If you want to play an existing playlist in the YouTube player, use its player controls; if you want a live channel, prepare accessible source files and follow YouTube’s current ingest instructions.
Which kind of playlist do you mean?
First decide where the playlist lives and what you want viewers to see. A playlist on YouTube is a sequence of videos viewers watch through YouTube’s player. A stream made from files on a server is a live broadcast: FFmpeg reads local media and sends an encoded signal to YouTube Live. They may contain similar material, but they are different workflows and are not interchangeable.
This distinction matters for both technical and rights reasons. A watch-page URL is a page for playback in YouTube, not a documented FFmpeg source in the official material referenced here. The fact that a video can be played in a browser does not establish that you can download it, extract it, or rebroadcast it. Use original files you own or have permission to stream, and check the rights for music, performances, images and any other included material.
The steps below assume you want one live broadcast built from a sequence of files. You will need a server that can keep the process running, media that FFmpeg can read, a YouTube Live setup with an ingest endpoint and stream key, and a way to supervise the process. For the separate player workflow, keep the playlist in YouTube and use its loop controls rather than treating it as a server-side live source.
Loop a playlist in the YouTube player
If the aim is simply to repeat a playlist that already exists on YouTube, open it in YouTube and use the player’s playlist controls. That plays the videos as YouTube playback, not as a new live broadcast from your channel. The channel’s viewers would need to visit or embed the playlist experience rather than tune into a live event created by FFmpeg.
This is the simpler route when you do not need a live stream. It does not require a Hetzner server or a continuously running encoder. It also does not solve the separate goal of creating a 24/7 live channel with your own scheduled material. Do not assume a player playlist can be passed to FFmpeg just because it has a URL; the workflow here makes no such claim.
If you need a live channel, plan the source as a set of files under your control. For a church or devotional stream with recordings, the advice in streaming a recorded worship set without silence between videos is relevant to preparing transitions, while the source and delivery method in this guide remain server-side FFmpeg and YouTube Live.
The Hetzner-to-YouTube Live workflow
At a high level, the path is: prepare permitted media, make it available to the server, form an ordered input sequence for FFmpeg, select an ingest method in YouTube Live, and run the encoder at real-time speed. Then check both the process and YouTube’s live status. A process that has started is not proof that viewers are receiving a valid stream.
Before building the command, confirm the media’s video and audio properties and the format expected by the current YouTube Live setup. Confirm that the installed FFmpeg build has the required demuxers and encoders. There is no single command guaranteed to work for every file, FFmpeg build, and ingest configuration, so validate the pieces together rather than copying an untested recipe.
YouTube’s live streaming setup guidance describes creating a live stream and obtaining its connection details. Follow the current Studio screen for the stream endpoint, key and protocol options. Treat the key like a password: keep it out of public scripts, screenshots and shared logs, and rotate it if it is exposed.
The end-to-end path includes several possible failure points: a missing or unreadable file, an incompatible stream format, a terminated FFmpeg process, a network interruption, or an ingest setting mismatch. If a camera rather than recorded files is your source, the concerns differ; see how an RTSP camera can be put online safely for that distinct source workflow.
Keep the media files available
Put the media files somewhere the server can read reliably. They may be stored on the server’s disk or on accessible storage mounted or transferred for the job. Check that paths are stable, filenames are unambiguous, and the account running FFmpeg can read every item. If files are moved or renamed after you make a playlist, entries may stop resolving even though the playlist text itself has not changed.
A local file list is useful when the order matters. Keep one entry per input, use the exact path, and check for accidental blank lines or extra spaces. FFmpeg’s concat demuxer supports a text file describing a sequence of inputs; consult the FFmpeg concat demuxer documentation for its syntax and compatibility notes. Inputs need to be suitable for concatenation, or you may need to convert them to a consistent format first.
Do not treat “same extension” as proof that files have matching streams. Two MP4 files can differ in codecs, frame dimensions, frame rate, time base, audio layout or other properties. A sequence that works for one pair may fail or behave differently with another. Inspect representative files and test transitions before committing to a long run; if there is a gap or audio discontinuity, correct the source set rather than hoping the live encoder will repair it.
Plan storage as well as bandwidth. A long playlist needs enough accessible space for the files, and any update process should not remove or lock a file while FFmpeg is reading it. For a persistent channel, keep a separate copy of the playlist definition and a record of the intended order so you can reconstruct it after maintenance. The practical lesson in keeping a 24/7 Gurbani stream going during a VPS update applies here: plan for maintenance and recovery, not only the first successful start.
Sequence files with FFmpeg
FFmpeg offers several ways to read a sequence, but the right choice depends on how the files are encoded and how you want repetition to work. The concat demuxer reads a list as a combined input when stream parameters allow it. A different approach may be needed if files need re-encoding or if transitions require specific handling. The official FFmpeg formats documentation describes demuxers and muxers; it does not replace testing with your actual inputs.
For a continuous broadcast, the input sequence and the live output need separate attention. The input side determines which file follows which and whether playback reaches the end of the list. The output side determines encoding, audio/video layout, pacing and packaging for YouTube. A playlist definition by itself does not make the output real-time, and a stream that plays too quickly is not a continuous live broadcast. Configure pacing and looping deliberately for the installed FFmpeg version and chosen input method.
Do not paste a generic command into production without adapting it. You must substitute real paths, select codecs and settings compatible with the source and destination, and use the endpoint details from YouTube Studio. Keep credentials out of shell history and logs where possible. Review FFmpeg’s output for file-open errors, timestamp warnings, encoder failures and reconnect behaviour. A quiet terminal is not the same as a healthy broadcast.
The official documentation reviewed for this workflow explains relevant formats and options but does not provide a complete, tested command for looping a concat playlist into YouTube Live. Test a short sequence first, including the transition from the final item back to the first if repetition is intended. Confirm whether audio remains continuous and whether timestamps behave as expected. Only then use the same validated settings for a longer session, with a recovery plan if the process exits.
If you need random rather than fixed order, that is another playlist policy and requires its own input handling. The practical differences are covered in streaming videos in random order to YouTube with FFmpeg. Do not add randomisation to a fixed devotional or announcement schedule unless that is actually what viewers should receive.
Choose the ingest route and verify the stream
Use the protocol and endpoint offered for the stream in YouTube Studio. RTMP and HLS are not merely alternate labels for the same output. YouTube says in its HLS setup guidance that HLS has higher latency because it sends video segments rather than a continuous stream like RTMP. Choose based on YouTube’s current requirements, the format and protocol supported by your encoder, and the latency your use case can accept.
If you choose HLS ingest, pay close attention to YouTube’s specified segment and transport requirements. Its guidance calls for Transport Stream segments, segment duration between one and four seconds, no byte range, HTTPS POST or PUT, and a rolling playlist with no more than five outstanding segments. It also says encryption beyond HTTPS is unsupported in that guidance. These are requirements for YouTube HLS ingest, not universal settings for every HLS output. FFmpeg’s HLS muxer can create playlists and segments, but using that muxer alone does not prove YouTube will accept the resulting stream.
After starting FFmpeg, check its logs, server resource use, outgoing traffic and YouTube’s live status. Confirm the video and audio are actually present, the picture is stable, and playback continues across file boundaries. If Studio reports an error, compare the selected protocol and format with the current setup instructions before changing several encoder settings at once. Change one relevant variable, then retest.
A cloud server is not the whole reliability plan. Hetzner says Cloud bandwidth is not guaranteed and that users can expect about 300–500 Mbit/s; that is an expectation, not a per-server minimum or a promise of uninterrupted delivery. Its Cloud service agreement describes commercially reasonable efforts towards 99.9% monthly availability for an individual Cloud Server, with exclusions including customer software or configuration failures and some external network interruptions. That is not an end-to-end live stream uptime promise.
Estimate outgoing data from the encoded bitrate before selecting a server. A rough planning calculation for decimal GB is bitrate in megabits per second × 0.45 × 24 × 30; this is arithmetic for a continuous month, not a Hetzner usage statistic. Allow for protocol overhead, reconnects and the actual billing period, then check the current included traffic and overage terms for your region and server type. Hetzner’s Cloud billing FAQ says outgoing traffic is billed and overage is charged in blocks of 100 MB; the usage notifications at 75% and 100% are informational and do not stop traffic.
Compare server choices on included outgoing traffic, region, public IP cost, and whether CPU resources are shared or dedicated. Also consider whether you will encode on the server or send already encoded material, since encoding adds a different resource demand from simply reading and relaying files. Hetzner’s Cloud overview describes its virtual server offering; check current plan details directly because pricing and allowances can change. A provider’s connection expectation cannot replace monitoring your own stream and traffic.
Supervision, recovery and operating choice
A continuous stream needs a way to notice and respond when the encoder stops. Use an operating-system service manager or another supervision arrangement to start the process after a restart and restart it after an unexpected exit. Configure restart behaviour thoughtfully: repeated failures should be visible, not hidden by an endless cycle that keeps failing for the same bad path or rejected format.
Keep a simple operational record: the command or service configuration, input list, FFmpeg version, YouTube protocol choice, and where the logs can be checked. Do not include the stream key in a document that may be shared. Before a server update, confirm how the process will be stopped and started, and check the broadcast again afterwards. Restart automation helps with process exits; it cannot fix a missing source file, an expired or replaced key, insufficient egress allowance, or an ingest setting change.
You can run this workflow yourself if you are comfortable maintaining a Linux server, watching logs and testing FFmpeg changes. If the persistent process and recovery work are the part you do not want to manage, StreamNeo removes that specific burden: you upload a video, provide your YouTube stream key, and the broadcast can continue without your computer left on, with monitoring and automatic restarts if it drops. It is YouTube-only, so it is not a substitute for a server workflow when you need to control FFmpeg on Hetzner or target 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 give FFmpeg a YouTube playlist URL?
This guide does not establish a YouTube watch-page playlist URL as a supported FFmpeg input, nor does it establish permission to rebroadcast the videos. For a live stream, use files you own or are authorised to use and make them accessible to FFmpeg. Use YouTube’s player when you mean to loop a playlist within YouTube.
Does a Hetzner server make the stream continuous by itself?
No. It can host the files and run the process, but FFmpeg, the server, network path and YouTube ingest all need to work. Supervision can restart a process after some failures, but you still need to inspect logs and confirm YouTube reports a healthy incoming stream.
Should I use RTMP or HLS?
Follow the current protocol and endpoint shown in YouTube Studio and choose an output your encoder can provide. YouTube’s guidance says HLS has higher latency than RTMP because it sends segments; HLS also has specific ingest requirements that must be met. Do not select HLS just because FFmpeg has an HLS muxer.
How much Hetzner traffic should I plan for?
Estimate monthly data from the encoded bitrate, then check the included outgoing traffic and current overage terms for the exact server type and region. The simple monthly formula in this guide is a planning estimate, not a billing quote. Leave room for overhead and reconnects, and remember that usage warnings do not cap traffic.