A scheduled YouTube livestream playlist needs two things: a YouTube Live event created in Studio, and an FFmpeg process on Ubuntu that sends the video feed to that event. Scheduling the event does not run FFmpeg, and starting FFmpeg does not necessarily make the event public.
For an India-based channel, check the event’s displayed time against the Ubuntu machine’s configured time zone, rehearse the playlist, and be ready to inspect the preview and click Go live when needed. The exact hand-off depends on the event’s settings, so do not treat an unattended encoder launch as proof that viewers can see the stream.
Event scheduling and encoding are separate jobs
YouTube Studio creates the event: its title, privacy, scheduled time, and viewer-facing watch page. The scheduled event can be shared so viewers can visit the page and set reminders. FFmpeg is the encoder: it reads your media and sends a live feed to the stream URL and key associated with the event. Neither job performs the other one.
That distinction matters when you plan an overnight broadcast. You can have a correctly scheduled event while no computer is sending video, because the Ubuntu process has not started or has failed. You can also have FFmpeg sending a feed without the scheduled event becoming public at that moment. YouTube’s documented encoder workflow includes checking the preview and clicking Go live; confirm what your event actually requires rather than assuming the encoder launch publishes it.
There is also a third clock to manage: the Ubuntu host scheduler. A cron job or systemd timer can start a process at a time you choose, but it does not create the YouTube event or change the event’s visibility. The YouTube event schedule and host schedule are separate settings. For a fuller explanation of playlist encoding beyond the scheduled-event workflow, see how to stream a playlist of videos to YouTube using FFmpeg.
YouTube recommends setting up an encoder at least two hours before an event and starting it at least 15 minutes beforehand. Those are preparation recommendations, not a cron rule or a promise that a scheduled feed will go public on its own. Give yourself room to catch a wrong file path, a key mismatch, a silent audio track, or an event-time mistake before viewers arrive.
Prepare the ordered video files
First make a playback plan. Put the clips in the exact order you want viewers to see them, decide whether the set should play once or repeat, and check that each source file opens and has the intended audio. A playlist script is not a media conversion tool: it orders inputs, but does not automatically make unlike files compatible.
FFmpeg’s concat demuxer can read a text file containing one file directive per item. An illustrative script might look like this:
ffconcat version 1.0
file 'opening.mp4'
file 'bhajans/track 01.mp4'
file 'closing.mp4'
The optional ffconcat version 1.0 marker must be the exact first line, with no leading space or byte-order mark, for automatic format recognition. Paths with spaces or special characters require the escaping or quoting used by the concat script format. Keep both the script and the media readable by the Linux account that will run FFmpeg; a file that works in your desktop session may not be accessible to a scheduled service running as another user.
The demuxer joins files in sequence by adjusting their timestamps. For joining without re-encoding, the files need matching streams, codecs, and time bases. A playlist assembled from phone recordings, downloaded clips, and exported slideshows may not meet that condition. A duration that is inaccurate, or a truncated file, can create an audio or video glitch at a transition. If sources differ, normalise them to compatible streams and test rather than assuming -c copy will work.
Keep a small test playlist that includes the types of files you intend to use. Play the output through the intended feed and listen around each join; a clip can look fine in a file player yet produce a discontinuity in the live sequence. For older H.265/HEVC exports that cause compatibility problems, this guide to converting HEVC to H.264 for a YouTube playlist explains the format issue from a related workflow.
The example above shows playlist syntax, not a guaranteed looping command. Looping behaviour and supported flags can depend on your installed FFmpeg build and input format. Check the manual for the version installed on Ubuntu, including ffmpeg -h full, and test the precise command with your actual files before relying on it overnight. Do not infer from a successful one-clip test that a long playlist will loop correctly.
Create the YouTube event first
In YouTube Studio, open Create → Go Live, choose Manage, then select Schedule stream. You can reuse a previous configuration or create a new stream. Set the event title, visibility, date and time, then review the other metadata before saving. YouTube notes that a scheduled stream can be promoted with a shareable URL and viewers can set reminders; that watch page is useful to verify independently of the encoder.
The Studio interface can change, so follow the labels currently shown in your account. Before sharing the event page, confirm the displayed date, time and privacy. YouTube notes that privacy defaults can differ by age group, and you can change the setting. A scheduled event that is private will not serve the same purpose as a public event, even if the encoder later sends a feed.
For India-local planning, read the event’s displayed time carefully and separately inspect the Ubuntu machine’s time zone. Do not assume that the Studio interface or a host scheduler uses IST merely because your channel is in India. If you run FFmpeg under cron or systemd, verify the time zone and actual trigger time on that host. A private or unlisted test event is a sensible way to confirm that the intended job starts when you expect without depending on an audience-facing broadcast.
Write down the event watch-page URL, planned start time as displayed in Studio, the host’s local time zone, and the person responsible for checking preview and going live. These details prevent a common operational gap: the event exists and is shared, but nobody has verified whether the feed is arriving or whether a manual action remains.
Configure FFmpeg for the feed
The basic shape of the job is: read the ordered playlist, encode or pass through compatible media, then publish to YouTube’s ingest destination. YouTube documents RTMP and RTMPS ingest and recommends RTMPS. Its encoder guidance says to use constant bitrate (CBR), use a two-second keyframe interval, and not exceed four seconds. Choose a bitrate for the resolution and frame rate rather than copying a number without context.
YouTube’s current guidance gives H.264 examples of 5–14 Mbps for 1080p30 and 3–8 Mbps for 720p30; these are YouTube recommendations for those formats, not a guarantee that a particular Indian broadband or mobile connection can sustain them. The figures are listed in YouTube’s live encoder settings guidance. Recommendations vary with resolution, frame rate and codec, so check the current table before choosing settings.
An illustrative command structure is shown below. It is not a tested, ready-to-run command for every Ubuntu release, FFmpeg build or media set; replace placeholders only after checking your version’s manual and testing the source and output. Do not put a real stream key in a public script or repository.
ffmpeg [input and playlist options] -i playlist.ffconcat \
[video and audio encoding options] \
-f flv "rtmps://YOUTUBE-INGEST-URL/STREAM-KEY"
The exact output URL format and whether the key belongs in the URL or a separate option depend on how you configure the encoder and the values supplied by YouTube. Use the destination details from the event’s Live Control Room, not a URL copied from an old tutorial. If you encode on a modest Ubuntu computer, re-encoding mixed sources may use more CPU than passing through compatible streams; if you choose stream copy to reduce CPU work, first check the concat compatibility requirements and output settings.
Before a real event, test with audio and movement similar to the planned programme. A static devotional image with a continuous bhajan track has different motion and audio behaviour from a local news loop with video cuts. Check that the feed reaches the expected event preview, that audio is present, and that stream health does not show a problem. There is no India-specific upload figure that can be assumed here: test the actual connection and leave headroom rather than setting the encoder exactly at a speed-test result.
Use the event’s stream URL and key
In the scheduled event’s Live Control Room settings, obtain the stream URL and stream key associated with that stream. YouTube describes the key as a credential-like value that tells the encoder where to send its feed and allows YouTube to accept it. Treat it like a password: do not publish it in a public repository, paste it into a support screenshot, or echo it in logs that others can read.
Use the event’s current values for the FFmpeg output. A key from another stream may direct the feed elsewhere or fail to match the scheduled event. Keep configuration access limited to the account that needs to launch the job. Environment variables or a configuration file with restricted permissions are safer than embedding a real value in an example script, but they still need careful handling: an environment or debug dump can expose secrets too.
When changing or resetting a key, update the host-side configuration and test again before the scheduled time. Keep a record of which event the configuration belongs to without recording the secret itself. If you troubleshoot a failed connection, check for a copied whitespace character, a stale key, or an incorrect ingest destination before changing unrelated encoding settings.
YouTube’s encoder setup instructions explain where the stream URL and key are used. The specific field names can vary across encoder interfaces; in an FFmpeg command, check the current documentation for your build and the ingest format supplied by YouTube rather than assuming an option from another encoder applies directly.
Set privacy and auto-start/stop deliberately
Review the event’s privacy and its auto-start and auto-stop options in Live Control Room. These are not cosmetic preferences: they affect how the event is exposed and what happens around an arriving or departing encoder feed. Do not enable an automatic transition simply because you want an unattended channel. Confirm the behaviour for the scheduled event and account, and retain a human check if the public start needs approval.
Privacy should match the intended audience and rehearsal plan. A private or unlisted test can help you inspect the feed without promoting a public watch page prematurely, but verify the event settings before the real broadcast. If the event is meant to be public at a particular time, check both the scheduled time and visibility in Studio; an encoder connection alone is not a substitute for this review.
The phrase “auto-start” can tempt you into combining several different events in your head: Ubuntu launches FFmpeg, YouTube receives a feed, and the event becomes publicly live. Treat those as distinct states. YouTube’s scheduled encoder guidance calls for preview and a Go live action, so verify whether your configured settings and workflow still require a manual step. Do not rely on a setting label without observing a rehearsal.
Likewise, decide what should happen at the end. A process that exits after one pass, a process that loops, and a YouTube event that stops are separate behaviours. Use a stop plan that matches the programme, and test how your event behaves when FFmpeg exits. If a long-running broadcast disconnects, the recovery decisions differ from initial scheduling; see how to recover a 24/7 Indian music stream after YouTube disconnects.
Schedule the Ubuntu process, not just the event
To run FFmpeg livestreaming on a schedule in Ubuntu, set up the host scheduler only after the command works interactively. A cron entry or systemd timer can start the process, but it does not know whether the YouTube event is correct, whether the preview is healthy, or whether someone must click Go live. Treat host scheduling as process automation, not event management.
Before depending on an unattended run, verify the Ubuntu machine’s configured time zone and test the scheduler at the intended local time. Do not presume that cron interprets a schedule as IST unless the host configuration confirms it. Also inspect the time shown for the event in Studio. The sources do not establish one universal time-zone behaviour for every YouTube account or Ubuntu setup, so a test event is more reliable than an assumption.
Add useful logs for process start, exit and errors, but keep stream-key values out of them. Decide how the job should behave if it fails: whether it should retry, how you will be alerted, and who can stop it. Avoid uncontrolled duplicate FFmpeg processes, which may compete to send feeds or make it unclear which process is active. A clear stop procedure matters as much as a start time.
For a devotional channel run by one person, a manual launch with a preview check can be easier to supervise than a fully unattended schedule. A small business or study channel with a rehearsed sequence may prefer a tested host timer, but still needs a clear plan for the YouTube-side preview and public start. If the repeated maintenance of an Ubuntu host, file paths and overnight process checks is the part that keeps failing, StreamNeo can remove that specific computer-running burden by turning an uploaded video into a YouTube feed without keeping your own computer on.
Check the preview, then go live if required
Start the encoder with enough preparation time to catch problems, then return to Live Control Room and wait for the preview. YouTube advises setting up the encoder well ahead and starting it before the event; the preview gives you a chance to confirm the feed is actually arriving. Check image, audio, transitions, and the stream health indicators before you decide whether to proceed.
For the final check, compare the preview against the watch page you intend viewers to use. Confirm that the event title and visibility are right, then use Go live if the workflow calls for it. Do not tell viewers to refresh an event that has not been made public. YouTube’s guide to creating a live stream with an encoder describes the scheduled encoder process and the preview/start workflow; follow the current instructions shown in your Studio account.
On a real playlist, inspect a transition rather than only the opening frame. Check that the next file appears, the audio does not drop or double, and the incoming video is not stuck. If you are testing from India, use the same connection and machine that will carry the actual stream where practical. A successful run over a different network does not establish that the scheduled host’s upload connection will hold the feed.
If the preview is missing, diagnose in order: is FFmpeg still running, can the host read every referenced file, are the stream URL and key the ones for this event, and does the encoder report output or network errors? Then check bitrate, codec compatibility and upload headroom. Make one change at a time and repeat the rehearsal; changing several settings at once can hide the cause of a problem.
Choose the operating approach that fits
The practical decision is often between stream copy and re-encoding, and between manual and unattended start. Stream copy can reduce encoding work when source files are compatible, but it does not reconcile different codecs or time bases. Re-encoding can make mixed sources more consistent, at the cost of additional processing and the need to choose sensible output settings. Test the whole playlist, not just one clip.
| Choice | When it may fit | What you still need to check |
|---|---|---|
| Stream copy | Inputs already match the concat requirements and output expectations | Codec, streams, time bases, transitions, and actual preview |
| Re-encode | Sources differ and need normalising | Ubuntu CPU capacity, chosen codec/settings, audio and upload stability |
| Manual encoder launch | You want to observe each start and approve the live transition | Someone available to inspect preview and act in Studio |
| Host-scheduled launch | A rehearsed process must start without a person at the keyboard | Time zone, logs, restart and stop plan, key protection, and Studio workflow |
No row removes the need to check the actual event. A well-formed playlist can still fail because a source path is wrong; a correctly started process can still feed the wrong event; and a healthy encoder preview may still await an explicit public start. Choose automation only for the steps you have demonstrated, not for steps you hope happen automatically.
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 starting FFmpeg publish my scheduled YouTube event?
Not necessarily. FFmpeg sends a feed to YouTube, while the scheduled event’s visibility and start workflow are controlled separately. Check Live Control Room preview and click Go live if the event workflow requires it.
Does scheduling a YouTube event start the Ubuntu encoder?
No. Scheduling creates the event and its viewer-facing details; it does not launch a process on your Ubuntu machine. Use a host scheduler or start FFmpeg yourself, then verify the feed reaches the correct event.
Can I use -c copy for every playlist?
No. Stream copy is suitable only when the files meet the concat demuxer’s compatibility requirements, including matching streams, codecs and time bases. Test transitions; otherwise normalise or re-encode the sources and check the resulting load on the host.
How do I know the schedule is using India time?
Check the time shown in YouTube Studio and inspect the Ubuntu host’s configured time zone separately. The event interface and host scheduler are different systems, so verify their behaviour with a test event at the intended local time before relying on an overnight run.