Yes. Wowza Streaming Engine documents a workflow for publishing a video-on-demand file as live content and repeating it, but that does not by itself configure delivery to YouTube.
Treat the job as two separate parts: make Wowza repeat the source, then confirm that the output path and ingest protocol work with your YouTube Live setup. The exact direct configuration depends on your Engine version and protocol; do not assume one set of steps applies to every installation.
Short answer: Wowza can publish and repeat VOD
Wowza’s documented method uses the ServerListenerStreamDemoPublisher server listener to publish a VOD file as a live stream. Its repeat controls can keep a file or playlist cycling until you stop it, or republish after a configured duration. That answers the source-playback question: the file can be made to repeat at the Wowza end.
The word “live” here describes how the source is published, not when the video was recorded. If you are showing a devotional programme, a study session, a local bulletin or a product demonstration, be clear in the stream’s presentation that viewers are watching prerecorded material. Check that you have the rights to use its video and audio, and ensure the title and description set accurate expectations.
A live source is only one part of a broadcast. You also need a YouTube event and a compatible delivery path from Wowza to YouTube. The available Wowza instructions explain the VOD publishing and repeat workflow; they do not establish one universal, version-independent configuration for sending every Wowza Engine output directly to YouTube. Start with Wowza’s documented VOD publishing steps, then verify your own destination path before scheduling viewers.
Do not confuse this with looping a video in the YouTube player. Viewer-side looping repeats playback for that viewer; it does not restart the incoming source of a live broadcast. You need to configure repetition where the VOD is published. If you are instead building a 24/7 music channel from audio files, the Kannada songs stream guide provides a different source-workflow example.
How playlistRepeat and publishRepeat differ
The two settings describe different repetition behaviour. playlistRepeat=true tells the listener to repeat the source file or playlist. publishRepeat=true tells it to publish again once the configured publishDuration has elapsed; that duration must be greater than zero. When using this latter mode, publishPauseTime sets the delay before republishing.
| Setting | What it repeats | Additional configuration | Practical use |
|---|---|---|---|
playlistRepeat |
The file or playlist content | Set the property to true |
Keep the same source cycling as one continuing presentation |
publishRepeat |
The publishing cycle after it reaches its duration | Set publishDuration to a value greater than zero; optionally use publishPauseTime for the delay |
End one publishing cycle and start another, with a configured pause if needed |
These are not interchangeable with YouTube’s ingest protocol. Wowza’s repeat controls determine what its publisher does with the source; YouTube’s ingest requirements determine how a feed is accepted at the destination. Enabling one repeat property does not prove that the configured output can be ingested by YouTube.
Choose based on the behaviour you actually want. For a playlist that should play through its items and begin again, repeat the playlist. For a publishing cycle that should finish and restart after a defined duration, use the publish-repeat mode and set its required duration. Test the transition, including audio, before leaving it unattended; do not infer from a successful first playback that the repeat boundary behaves as intended.
Build a playlist with M3U8
For more than one asset, Wowza’s example uses a plain-text .m3u8 file in the installation content directory. Put one stream name on each line, then set srcStream to the playlist reference, for example m3u8:filelist.m3u8. The listener documentation also lists MP4 and MP3 as supported source types in this setup.
The example includes random=false and timeBetweenItems to control ordering and the gap between items. Use a predictable order if the programme has a sequence, such as an introduction followed by talks or songs. A gap may be useful between items, but it will be audible and visible to viewers, so review it as part of the programme rather than assuming it is harmless.
Check the actual filenames, stream names and file locations carefully. A path or spelling error can make the source fail before YouTube is involved, while an individual damaged file can interrupt playback part-way through a playlist. First test the playlist as a Wowza stream. Confirm that each item appears in the intended order, that the transition is acceptable and that the final item leads back to the first as expected.
If your project uses a single long video rather than a set of files, the playlist step may not be needed. In either case, keep a known-good source ready for a controlled test before you connect the output to a public event. For a visual channel such as an ambience stream, the Northern Lights ambience walkthrough is a useful reference for thinking about a continuous prerecorded presentation, though it does not replace the Wowza-specific configuration.
Configure the YouTube Live destination separately
A YouTube broadcast is an event associated with a live stream that carries the audio and video feed. You create or select that event in YouTube Studio’s Live Control Room, then obtain the stream key and ingest details for the sending encoder or compatible output path. Google’s YouTube Live API guide explains the event and stream relationship; the exact Studio steps can change, so check the current interface when you set up the broadcast.
The practical question is what Wowza can send from your particular installation and how that output reaches the ingest endpoint. Your path may involve a compatible output configuration or an encoder or relay between Wowza and YouTube. The source material reviewed for this article does not establish a single direct Wowza-to-YouTube configuration that works across all Engine versions. Confirm the Engine version, available protocols and destination support against the documentation for your installation before building the workflow around direct delivery.
YouTube supports more than one live ingest route, and requirements for one route should not be transferred to another. In particular, Google’s HLS documentation describes specific requirements for HLS delivery, including HTTPS uploads, a rolling media playlist with no more than five outstanding segments, TS segments lasting one to four seconds, and muxed audio and video in a single encoded stream. Those are HLS-specific requirements, not settings for Wowza’s playlistRepeat property. If you use another YouTube-supported ingest protocol, check that protocol’s current instructions instead.
YouTube notes that HLS has higher latency than RTMP because HLS sends segments rather than a continuous stream. That may matter if viewers need to follow events in near real time, but a prerecorded loop with no audience interaction may have different priorities. Decide what latency your use case can tolerate, then choose a supported ingest path and configure the sender accordingly. You can read the current YouTube HLS ingest requirements before selecting that route.
Check Engine version and YouTube ingest requirements
Before configuring anything, record the exact Wowza Streaming Engine version you run and identify the output protocol it supports for your planned path. Compare that with YouTube’s current ingest choices. The reviewed sources do not show that every Engine version has the same direct YouTube setup, so an instruction written for another version or a relay arrangement may not fit yours.
Do not treat “Wowza can publish a file as live” as equivalent to “this Wowza instance can send the required format directly to YouTube”. The first statement concerns VOD publishing and repetition. The second concerns transport, media encoding and destination compatibility. If you cannot confirm a compatible direct path, plan to test a suitable encoder or relay rather than repeatedly changing loop settings that do not address the ingest problem.
If you choose HLS, check each HLS condition against the outgoing feed: secure HTTPS upload, playlist behaviour, segment type and duration, and the required media arrangement. Do not copy those HLS conditions into an RTMP configuration as if they applied there. Similarly, do not assume a feed accepted by Wowza’s local playback test will satisfy YouTube’s ingest rules. The receiving platform is a separate check.
Also confirm that the YouTube channel is allowed to go live before you invest time in the pipeline. YouTube’s live-streaming eligibility page says the channel must be verified and have no live-streaming restrictions in the previous 90 days; it also states that the streamer must be at least 16 years old. Check the current official page and your account access, since eligibility and account status are not changed by a successful Wowza configuration.
This is a good point to decide who will operate the system. Self-hosted Engine gives you control over the source workflow, but you are responsible for the compatible output path and for diagnosing it. Wowza Video is a separate managed product with a file-streaming loop workflow; Wowza’s developer documentation warns that its continuous-loop transcoder continues running and accruing charges until manually stopped. That may suit someone who wants a managed workflow, but check the vendor’s current documentation and terms before relying on it.
For a small channel in India, compare the whole operating arrangement, not just whether the source repeats: protocol compatibility, expected latency, who monitors the hand-off, and what happens if a relay or local connection fails. A cloud-versus-home-server comparison can help frame the operational trade-offs for an always-on channel. If your main concern is keeping a long-running stream stable, the OBS audio drift checklist is also relevant to the separate problem of audio staying in sync over time.
Test the complete path before relying on it
Test in stages so a failure points to the right component. First, use Wowza to publish the source and verify that the file or playlist plays and repeats as intended. Check the order, pauses, picture, audio and repeat boundary. Wowza’s instructions require a server restart for the relevant configuration changes, so do not assume a setting has taken effect until you have restarted as required and observed the stream.
Next, set up an unlisted or otherwise controlled YouTube broadcast if your account and workflow permit, and connect the actual output path you plan to use. Confirm that YouTube receives both audio and video and that the broadcast remains healthy while the source reaches its repeat point. If an encoder or relay is part of the setup, test it in the same role it will have in production; a local preview is not an end-to-end test.
Observe at least one full cycle of the source arrangement, whether that is a single file or the complete playlist. Look for a frozen image, silent transition, missing first item after the loop, unexpected pause, or a publishing restart that YouTube treats differently from uninterrupted content. The aim is not to claim a guarantee; it is to discover where your specific version and path behave differently from your expectation before you announce the channel.
Plan for failures as well as a clean run. Know where you will see an ingest error, how to stop the source, and who can restart or repair the chain. If the channel has to stay available overnight, decide what happens when the source is unavailable or the delivery connection drops. Wowza’s repeat configuration addresses source repetition; it does not remove the need to monitor the destination and respond to a broken path.
A managed workflow can remove some day-to-day operating work, but it does not remove the need to validate the YouTube destination or understand the recurring runtime implications. If your issue is specifically that your own computer must remain switched on to send a prepared video continuously, StreamNeo removes that computer-dependent part by letting you upload the video and configure the YouTube stream for cloud operation; you still need to check that the channel and content are ready.
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
Does Wowza Streaming Engine loop a prerecorded file as a live stream?
Yes. Wowza documents a ServerListenerStreamDemoPublisher workflow for publishing VOD as live content, with playlistRepeat available to repeat a file or playlist. You must still configure and verify the separate path that delivers the feed to YouTube.
Is publishRepeat the same as playlistRepeat?
No. playlistRepeat repeats the source content, while publishRepeat republishes after a configured publishDuration has elapsed. For the latter, the duration must be greater than zero, and publishPauseTime can set the delay before republishing.
Can I use YouTube HLS requirements to configure Wowza’s loop?
No. HLS requirements describe how a feed is ingested over HLS; Wowza’s repeat properties describe what happens to a source file or playlist. Check the requirements for the actual protocol you send to YouTube, and do not apply HLS-specific conditions to another ingest route.
Does looping a video on YouTube make a live source repeat?
No. YouTube player looping repeats playback for a viewer, not the incoming source of a live broadcast. Configure the repeat behaviour at the publishing source, then separately confirm that YouTube receives the resulting feed.