A continuous YouTube programme from Wowza starts with choosing the right source method: a single looping VOD file or a scheduled playlist of several items. They are separate Engine configurations, and neither removes the need to connect the resulting output to a YouTube Live destination and test it before relying on it unattended.
For one file, Wowza documents ServerListenerStreamDemoPublisher, which repeats a VOD until the listener is terminated. For multiple items or timed scheduling, use Stream Publisher with an application-specific SMIL file. The exact controls for sending that output to YouTube can differ by Engine version, so verify the workflow against the documentation for the version you run.
Choose one file or a multi-item playlist
Start by deciding what the channel must play, not by opening Engine Manager. If the whole programme is one long video that should repeat from the beginning, the server listener is the narrower, simpler tool. If the schedule contains distinct clips, needs offsets or playback lengths, or has scheduled start times, Stream Publisher is the appropriate documented mechanism.
| Decision | Single repeating VOD | Scheduled multi-item playlist |
|---|---|---|
| Wowza method | ServerListenerStreamDemoPublisher |
Stream Publisher with SMIL |
| Use it when | One file should repeat until stopped | Several sources need ordering, timing or individual lengths |
| Loop control | The listener repeats the VOD until terminated | Set repeat="true" for the playlist |
| Main caution | This is a static server-listener setup, not a playlist scheduler | SMIL is specific to the application and should be edited as text |
The distinction matters when a channel grows. A bhajan station might begin with one uninterrupted programme recording, then later need separate morning and evening segments. The single-file publisher does not become a scheduler merely because the file contains many songs; to control separate items in Engine, build a Stream Publisher schedule.
Also distinguish the Wowza playlist from a YouTube playlist. Here, Wowza produces an outbound live stream from a file or schedule. YouTube receives that live output at a stream destination; it is not being asked to play a playlist of uploaded videos. If your actual requirement is simply to play YouTube videos in sequence, read the explanation of whether a YouTube playlist can play continuously before configuring an encoder.
Check that the video and audio sources are available to the Engine application and that you know where its stream storage is. Plan a short test using representative material before you build a long schedule. For format and mixed-resolution considerations, the notes on streaming videos with different resolutions in one YouTube Live playlist can help identify source issues before they become a live troubleshooting problem.
Loop one VOD with StreamDemoPublisher
Wowza’s documented single-file route uses the ServerListenerStreamDemoPublisher server listener. It publishes a VOD file as a live stream and loops it until the listener is terminated. This is suitable when there is one file to repeat; it does not provide the multi-item scheduling controls described in the Stream Publisher section.
Wowza describes setup through Engine Manager or by editing Server.xml. The Wowza guide to publishing a video file as a live stream is the reference for the configuration in your release. Follow the sequence in that guide rather than assuming that a control, file path, or interface label shown for another Engine version will match yours.
Before enabling the listener, place the VOD where the application and server listener can access it, and confirm the file path in the configuration. Use a short, known-good test file first if you are learning the procedure. A wrong path or an unsupported source can make the publishing step fail even though the listener itself is configured.
The loop behaviour is tied to the listener: it continues repeating until you terminate it. That is useful for a stable, single-programme channel, but it has a trade-off. Changing from one programme to another is not equivalent to changing an item in a scheduler; you must manage the server-listener configuration and its lifecycle deliberately. Do not treat this listener as a queue that automatically advances through separate files.
The configuration is also static in comparison with a scheduled playlist. If you need clips to play in an intentional order, with different start offsets or capped lengths, use Stream Publisher instead. For a broader operational perspective on what happens when a source ends, see what happens when a YouTube 24/7 stream’s source playlist ends. That article concerns the source’s continuity; the Engine method still needs to be configured correctly.
Configure the YouTube Live target
Once Engine is producing the stream, YouTube needs a destination stream URL and its associated stream key. Create or select the live stream in YouTube Live Control Room, then put the destination details into the Wowza output or publishing configuration appropriate to your installed Engine version. YouTube’s encoder setup instructions describe the general flow, but they do not establish one universal Engine Manager click path for every release.
Treat the stream key as a credential. YouTube says it functions like a password and address for the stream. Keep it out of screenshots, public notes, and shared configuration examples. If you believe it has been exposed, reset it in Live Control Room and replace it wherever the encoder output is configured. YouTube explains stream settings and key management in its live stream settings guidance.
Where the installed Engine output workflow supports it, prefer RTMPS. YouTube recommends RTMPS, which carries RTMP over TLS/SSL. The exact RTMPS controls and support depend on the Wowza deployment and version, so confirm the current Wowza documentation for that release and use the URL exposed by YouTube’s stream settings. Do not assume a setting exists just because it is visible in a guide for another version.
Keep the Engine source configuration and the YouTube destination configuration conceptually separate. A healthy local source does not prove that YouTube is receiving the output, and a valid YouTube key does not prove the source is being produced. Record which application, source method and destination are paired so that later changes do not accidentally send a test playlist to the live channel.
Create a Stream Publisher playlist
For a multi-item programme, configure Stream Publisher in the Engine application that will publish it. Its schedule is expressed in an application-specific SMIL file in that application’s Stream Storage directory. The property streamPublisherSmilFile identifies the file. Each application that loads its own schedule needs its own SMIL file, so avoid assuming that a file in one application’s storage will automatically serve another.
Follow the current Wowza Stream Publisher scheduling guide for the application properties and supported SMIL structure. Wowza notes that scheduler SMIL includes additional tags that the SMIL editor in Engine Manager cannot recognise. Create or edit the scheduler file with a text editor rather than relying on that editor to preserve all of the required tags.
A playlist definition has two practical jobs: identify the stream sources and place them in the playlist sequence. Make each source reference match the actual stream or VOD available to the application. Keep names consistent and inspect the final file as plain text before starting the schedule. A misspelt source name can resemble a YouTube problem later, while the fault is actually upstream in the playlist.
The scheduler uses attributes that affect how each item plays. For a live source, Wowza’s documentation uses start="-2"; for an on-demand source, use start="0" or a positive offset. length="-1" means play to the end, while a positive length in seconds caps playback. These values are scheduler semantics: do not copy them blindly without checking whether the item is live or on-demand and whether you intend to truncate it.
To have the whole schedule repeat, set repeat="true". With repeat="false", the stream shuts down after the playlist ends. That is an important operational difference: a schedule that appears to play correctly once may still stop after its last item if repeat is not enabled. Check the final attribute in the actual SMIL file, not only in your planning notes.
The scheduled attribute controls playlist start time. Wowza’s examples may include historical sample dates, which should not be copied as current live start times. If a specified begin time is already in the past, playlists load in order and can immediately replace the preceding playlist. For an always-on channel, review all scheduled times and their ordering against the clock and time zone you intend to use before starting the application.
Set up the application-specific SMIL file
Keep the playlist file in the Stream Storage directory for the application that will run it, and set streamPublisherSmilFile to identify that file. The application boundary is easy to miss when a server hosts several channels: each schedule belongs to the application that loads it. A file in a similarly named directory is not enough evidence that the intended application will read it.
Use a text editor that will not silently remove or rewrite scheduler tags. After editing, review the file for the source names, item order, start and length values, schedule timing and repeat setting. Then compare the file with Wowza’s current Stream Publisher examples and documentation for the installed release. A valid-looking XML file can still have the wrong operational meaning if, for example, an item is assigned a live-source start value when it is actually a VOD.
Make changes in a controlled way. Preserve a copy of the last known working SMIL file before altering a schedule, and change one aspect at a time. If a new item fails, you can then tell whether the issue is its source reference, timing or playlist structure. This is especially useful where the channel needs to return to a known-good loop quickly.
Do not use a YouTube playlist as a substitute for the Engine SMIL file. YouTube’s destination receives a live feed; Stream Publisher’s SMIL controls what Wowza emits into that feed. The distinction is similar to separating a programme rundown from a broadcast destination: one determines what is played, and the other determines where the output goes.
Match the output settings and source material
Before testing the destination, check that the outbound encoder settings fit YouTube’s current guidance. YouTube’s encoder settings page provides bitrate recommendations by codec, resolution and frame rate; use the row for the actual output you have configured rather than choosing a value from a different format. Recommendations are not a guarantee that a particular network path or source will behave well.
YouTube recommends a two-second keyframe interval and says not to exceed four seconds, constant bitrate encoding, and AAC or MP3 audio for RTMP/RTMPS. Review the current YouTube encoder settings guidance when choosing the output profile. If the installed Wowza workflow exposes different controls, confirm their meaning in the documentation for that Engine version rather than inferring from another encoder’s terminology.
The video source matters as much as the output profile. Test with the sort of motion and audio the real channel will use: a still devotional image may conceal issues that appear in a moving news clip, and silence may conceal an audio-routing fault. Check that transitions between playlist items do not create unwanted gaps, unexpected silence or abrupt changes in level. For channels mixing source sizes, the guide to different resolutions in one live playlist is relevant before you commit a long schedule.
Think about network capacity at the actual publishing point. The upstream connection needs to sustain the chosen outbound bitrate, with room for normal variation. If a locally running publisher is exposed to home broadband fluctuations, assess the connection at the site where Wowza sends the stream. The article on checking whether YouTube dropped frames are network or encoder related offers a useful diagnostic distinction if the test shows instability.
Test playback and the YouTube destination
Do not move directly from configuration to unattended operation. Start with a short end-to-end test: verify that Wowza starts the intended source or schedule, that the output reaches the selected YouTube stream, and that Live Control Room reports a healthy incoming signal. Watch and listen to the actual viewer playback, not only the Engine status. A publisher can be active while the destination receives the wrong programme or has a picture or audio problem.
For the VOD path, let the test cross the end of the file and confirm that playback begins again as expected. For the multi-item path, observe the transition from one item to the next and, if practicable, the point where the final item returns to the beginning of the schedule. This directly tests the two different loop mechanisms: listener repetition for one VOD, and the playlist’s repeat="true" behaviour for Stream Publisher.
Check the destination stream health while the test runs. YouTube advises testing with representative audio and motion and monitoring stream health during the event. If you see dropped frames, missing audio or an unexpected stop, isolate the fault: verify the source and SMIL behaviour, inspect the Engine output, then check destination details and network conditions. Avoid changing several variables at once, because that makes the result harder to interpret.
Only after a test has passed should you leave the configuration running without supervision. Decide who can access the stream key, where the current SMIL and listener configuration are kept, and what the operator should check after a restart or source change. If the stream key changes, update the Wowza destination; if the schedule changes, re-test item transitions. For a simpler route that removes the need to keep a local computer running and manually recover a dropped broadcast, StreamNeo can take an uploaded video and run it as a YouTube live stream while monitoring and restarting it if it drops; it is YouTube-only, so it is not a replacement for Engine when you need Wowza-specific multi-item scheduling controls.
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 StreamDemoPublisher schedule several videos?
No. ServerListenerStreamDemoPublisher is the documented route for publishing and repeating a VOD file until the listener is terminated. For a schedule of multiple items, configure Stream Publisher with an application-specific SMIL file.
Where should the Stream Publisher SMIL file go?
Wowza’s documented arrangement places it in the Stream Storage directory for the application that uses the schedule, with streamPublisherSmilFile identifying it. Each application loading a schedule needs its own file. Edit the scheduler SMIL with a text editor because Engine Manager’s SMIL editor cannot recognise all of its extra tags.
Will the same Wowza steps work in every Engine version?
Do not assume so. The overall flow is to produce an outbound stream and configure a YouTube destination using its URL and key, but the Engine controls and available RTMPS support can vary. Check the Wowza documentation for your installed release and YouTube’s current encoder guidance before relying on the configuration.
How do I know the setup is ready to leave unattended?
Run an end-to-end test first and confirm the intended source, loop or playlist transitions, picture and audio in YouTube playback, and stream health in Live Control Room. Then keep the key private and re-test after material changes to the playlist, source or destination settings. No configuration removes the need to monitor the channel’s actual health.