To stream several pre-recorded videos in sequence from Hetzner to YouTube Live, run a playback process on the server that feeds one encoder, then send that encoder’s output to the ingest URL and stream key shown in YouTube Studio. The playlist decides what plays next; YouTube receives a live audiovisual feed, not a set of files to arrange for you.
This is an architecture and operating workflow, not a tested command or a guarantee of uninterrupted playback. Your exact setup depends on the files, the encoder, the server’s network rules and how you monitor the process. Test the transitions and a representative broadcast before relying on it overnight.
The continuous-feed architecture
Think of the system as three connected jobs. First, media files are stored on the Hetzner machine, or made available to its playback process. Second, a playlist or other playback layer reads those files in the order you choose and produces a continuous audio-and-video output. Third, an encoder sends that output to the YouTube Live ingest endpoint using the stream URL and key created in YouTube Studio.
The distinction between playback and encoding matters. A playlist controls sequence, repeat behaviour and transitions. An encoder controls the outgoing format and connection. A failure in either layer can interrupt the live feed: for example, playback may stop when it reaches an unsupported file, while an encoder may lose its connection even though the playlist is still advancing. You need to observe both sides rather than treating “the stream” as one indivisible process.
Hetzner’s role in this design is to host the files and the playback and encoding workload. This can be useful when you do not want a computer at home or at a shop to stay switched on. It also means you are responsible for selecting a suitable server, allowing the outgoing connection and operating the software. For a broader way to think about monthly hosting and operating costs, see how to estimate the monthly cost of a 24/7 YouTube stream.
The encoder initiates a connection to YouTube, so this workflow does not inherently require you to expose a public inbound streaming port. Hetzner documents that its Cloud Firewalls block inbound traffic when no rules are configured while allowing outbound traffic; if you create restrictive custom outbound rules, make sure they allow the connection to the ingest endpoint you selected. Check the Hetzner Cloud Firewalls overview and your own firewall configuration rather than assuming every server has the same rules.
Choose files and set the intended order
Before configuring a playlist, make an inventory of the videos. Record each filename, intended position, duration, video dimensions and frame rate, video and audio codecs, and whether it has an audio track. A simple numbered naming scheme or a separate playlist file can make the sequence easier to inspect. Do not rely on an operating system’s default alphabetical ordering if filenames such as 1, 10 and 2 might sort differently from the intended order.
Decide what should happen at the end of the list. A finite event may stop after the last item; a channel that should continue may repeat the sequence. Also decide whether transitions should be hard cuts or include a planned pause, slate or fade. These are editorial choices as well as technical ones. A black frame or moment of silence between videos may be acceptable for a local notice loop, while a devotional music channel may need more careful attention to audio gaps.
The files should be available to the playback process in a location it can read, with enough room for the selected content and any working files. Check that names and paths are stable, permissions allow the process to read them, and the list does not point to a file that has been moved or renamed. If you upload a new version, verify that the playlist points to the correct copy before going live.
YouTube does not arrange your source files into a sequence. The server-side playback layer must do that work. If the archive is an interview or a collection of episodes, the practical editorial concerns are similar to those in streaming an Indian interview podcast archive continuously: put the material in a deliberate order, check each item and consider what a viewer encounters when they join mid-stream.
Build a playback process that advances through the list
The playback layer needs to open each file, present its audio and video to the encoder and move to the next item without ending the overall output. The implementation might use a media player with playlist support or a media-processing workflow, but there is no universal command that can be assumed to work for every collection. Containers, codecs, frame rates, dimensions, timestamp behaviour and audio layouts differ. A command that accepts one set of files may fail, drift or create a poor transition with another.
For consistent output, decide whether the sources can be passed through as they are or whether the playback or encoding workflow needs to normalise them. Re-encoding can make the outgoing feed more uniform, but it uses processing capacity and introduces another place to configure. Passing compatible source streams through may reduce work, but it does not solve mismatched formats or transition behaviour by itself. Inspect the actual media and test with representative files rather than deciding from filename extensions alone.
Pay particular attention to the boundary between clips. Test the end of one file and the start of the next for frozen frames, black intervals, unexpected silence, audio jumps, incorrect aspect ratio and changes in loudness. If files have different frame rates or audio sample layouts, check whether the chosen playback method handles them as intended. If a clip has no audio, confirm whether that is a deliberate part of the programme rather than an accidental gap.
Keep the playback and encoder roles clear in your operating notes. If the playlist stops, the encoder may still be connected while sending a stalled or empty picture. If the encoder exits, playback may continue locally but YouTube will not receive it. A useful test therefore checks the playback output as well as YouTube’s preview, and records what action an operator should take for each type of failure.
Do not treat a long run as proof that every future transition will be clean. Test every file if the collection is small, or at minimum test representative files and the transitions most likely to differ. Replace a source file only after checking that the new version behaves correctly in the same workflow.
Connect the encoder to YouTube Live
In YouTube Studio, create or schedule a live stream and open its Live Control Room. YouTube’s encoder setup instructions explain how to retrieve the stream URL and key for an encoder. Use the endpoint shown for that event rather than guessing an ingest address or copying one from an old configuration without checking it.
YouTube recommends RTMPS, the encrypted form of RTMP. Its encoder settings guidance lists supported video and audio codecs and recommends settings such as constant bitrate encoding and a two-second keyframe interval, which should not exceed four seconds. The appropriate video bitrate depends on codec, resolution and frame rate. As a reference point, YouTube’s guide recommends 10 Mbps for H.264 at 1080p and 30 frames per second; that is guidance for this stated combination, not a promise that it fits every source or network.
Match the encoder output to the material and the documented guidance. If the source is lower resolution, producing a larger output does not add detail. If the source varies between clips, determine whether the playback workflow can deliver a consistent output format. Watch the stream health indicators in Live Control Room and adjust only after checking the actual output and network conditions.
If an encoder reports an SSL problem, check that the URL uses rtmps rather than rtmp. YouTube’s RTMPS help page also notes that specifying port 443 can resolve some SSL errors. Follow the endpoint details displayed in Live Control Room and the encoder’s own configuration requirements; do not change ports blindly when the existing connection is working.
Protect the stream key
Treat the stream key like a password. YouTube uses it to associate an encoder’s outgoing feed with your live stream, so anyone who obtains it may be able to send content to that destination. Store it only where the encoder needs it. Do not put it in a public code repository, a support screenshot, a shared document with broad access or a log that other people can read.
If you keep configuration files on the server, restrict access to the account and processes that need them. Be careful when sharing terminal output: command history, error messages or screenshots may include sensitive configuration. If more than one person operates the channel, agree how the key will be shared and who can rotate it. Avoid leaving a copied key in a temporary note after setup.
If you believe the key has been exposed, reset or replace it using the controls in Live Control Room and update the encoder configuration. A changed key can prevent an encoder still using the old one from connecting, so coordinate the change with the person responsible for the broadcast. For a channel that depends on a stable long-running feed, see what happens if a YouTube livestream key changes.
Check the server, network and operating trade-offs
A Hetzner server is not automatically the right choice just because the files are pre-recorded. Compare the operational requirements before choosing a configuration: whether its processing capacity is sufficient for the selected playback and encoding method, whether its location and included traffic suit the feed, and whether you can monitor and recover the software when it stops. These are decision points, not a ranking of particular server types.
Outgoing traffic grows with the encoder’s bitrate and the duration it sends. Estimate from the actual output settings and the hours you expect to broadcast, then compare that with the allowance for the server product and location you intend to use. Hetzner’s traffic documentation describes how allowances vary. It lists 20 TB of included traffic for CX, CPX and CAX Cloud Servers in EU locations, but the cited documentation was last changed in 2024; check the current product and location details before budgeting. Do not count YouTube viewer playback as traffic served from your Hetzner machine: the server’s relevant transfer here is the encoder’s outgoing feed.
There is also an operational trade-off between doing everything yourself and using a workflow that removes server administration. Running playback and encoding on your own machine gives you control over software and files, but you must keep it powered, connected and monitored. A cloud-hosted playback option can remove the need to keep your own computer on, but it does not replace checking that your source files, channel and stream are ready. StreamNeo is relevant when the specific pain is keeping a personal computer running for a file-based YouTube broadcast: it turns an uploaded video into a YouTube stream, so the computer can be off. It is YouTube-only, and you should still check the content and live event yourself.
Whatever approach you choose, write down how you will notice a failure and what you will do next. An unattended process that has no useful alert or recovery plan can leave a channel with a stopped or degraded feed until somebody checks it. Do not assume a particular server configuration or process manager guarantees continuous playback. Your test should include the monitoring path you actually plan to use.
Test in Live Control Room and operate deliberately
Before scheduling a long broadcast, run a test with representative files and the intended playlist order. Check the transition from one video to another, the image framing, audio levels and whether playback reaches the end-of-list behaviour you selected. Confirm that the encoder connects to the expected event, and watch the preview in Live Control Room before treating the output as ready for viewers.
YouTube advises checking the preview and stream health in Live Control Room. Watch for warnings about the incoming feed and look at both audio and picture rather than assuming that a connected encoder means the programme is sound. Also open the event’s watch page, where appropriate, to confirm that the public-facing page is the one you intend to use. A private or unlisted test can help you validate the workflow without treating it as a public launch.
A useful handover note can be short: where the playlist is kept, how to identify the current file, where to check YouTube health, who can access the key, and what to do if playback or ingest stops. If a clip is replaced, repeat the relevant transition test. If the server’s outbound rules or encoder settings change, test the connection again before the next scheduled run.
When the broadcast should end, stop the encoder’s outgoing content and end the event in Live Control Room as appropriate for its configuration. YouTube says streams under 12 hours are automatically archived; do not assume the same archive behaviour for longer streams. The end-of-stream process is worth testing too, especially if you need the resulting live archive to appear on the channel.
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 send several files directly to YouTube and let it play them in order?
No. YouTube receives a live encoder feed; your playback or playlist process must read the files and produce the sequence. The encoder then sends that combined output to the URL and key in Live Control Room.
Is there one FFmpeg command that works for every playlist?
No universal command can be assumed to handle every combination of codecs, containers, timestamps, frame rates and audio tracks. Check the files and the chosen workflow, then test representative clips and transitions before relying on it for a long broadcast.
Do I need to open an inbound port on the Hetzner server?
The encoder normally initiates an outbound connection to YouTube’s ingest endpoint, so an inbound streaming port is not inherently required for this workflow. If you have custom outbound firewall rules, check that they permit the connection to the selected endpoint.
Will the live broadcast be archived automatically?
YouTube says streams under 12 hours are automatically archived. For longer broadcasts, do not rely on that rule; check YouTube’s current guidance and your event configuration, and confirm the archive after a test.