To start an FFmpeg YouTube stream when a Windows PC boots, first verify the command manually, then save it in a script and create a Task Scheduler task. Choose At startup if it should run as Windows starts, or At log on if it needs a signed-in user session; neither trigger alone proves YouTube is broadcasting to viewers.
Treat the task as one link in a chain: Windows must launch the right command, FFmpeg must reach YouTube, and the stream must be active in the way your Live Control Room workflow requires. Test each link separately before relying on a reboot.
Validate the FFmpeg command before automating it
Do not begin with Task Scheduler. Run the exact FFmpeg command in a normal Command Prompt on the PC that will host the stream. If it fails there, putting it in a startup task will only make the failure less visible.
Check that the executable path is correct, the input exists and can be read, and the output settings use the current YouTube ingest address and stream key. YouTube’s encoder instructions explain where those values are used. Obtain them from the relevant Live Control Room rather than copying an address or key from an old tutorial. Keep the key private: anyone who has it may be able to send a feed to your channel.
A command depends on more than its text. It can rely on the current folder, a mapped drive, a USB camera, a particular Windows account, or environment settings that are present in your interactive session but absent when a scheduled task runs. Test the inputs and output from the same PC, and note which account is signed in.
Watch FFmpeg’s console output during the manual test. Confirm that it opens the input, encodes or copies the media as intended, and reports that it is sending output rather than exiting immediately with an error. The right codecs and options depend on the source and the installed FFmpeg build; there is no single universal command for a file, capture device and desktop source.
FFmpeg documents RTMP-family protocols, including RTMPS, and its protocol guide shows an FLV output example. YouTube also documents RTMPS as a streaming option. Use the protocol and ingest endpoint shown for your stream, and do not assume a sample command’s destination is still appropriate.
A command that runs until you stop it is not necessarily a good unattended command. Check for quoting errors in paths with spaces, expired or incorrect keys, unavailable inputs, and unintended looping behaviour. If you cannot explain what each input and output section does, resolve that before adding automation.
Save the known-good command as a script
Once the command works manually, save it in a batch file, for example C:\YouTubeLive\start-stream.bat. Use a stable folder you control, and save the file with the .bat extension rather than accidentally leaving it as a text file. Put the command on one line unless you know how to continue a Windows batch command across lines.
Prefer explicit paths. For example, call C:\Tools\ffmpeg\bin\ffmpeg.exe and use C:\YouTubeLive\video.mp4 rather than relying on the PATH variable or a relative filename. If the command uses relative paths, set the working directory in Task Scheduler or change to the intended directory in the batch file first. Explicit paths reduce the chance that the command works in your own terminal but fails when launched by a scheduled task.
Add FFmpeg’s -nostdin option for background operation. FFmpeg’s FAQ recommends it when running in the background so the process does not wait for keyboard input it cannot receive from an unattended task. Place options according to FFmpeg’s command-line structure and check the result manually after adding it.
For troubleshooting, redirect output to a log file from the batch file. A basic pattern is "C:\Tools\ffmpeg\bin\ffmpeg.exe" -nostdin [your tested options] >> "C:\YouTubeLive\ffmpeg.log" 2>&1. Replace the bracketed part with your known-good arguments; it is a placeholder, not a working FFmpeg command. Standard output and errors then have somewhere to go when no console is open. Make sure the task account can write to the log folder.
Do not put the stream key in a file that you share, publish, or leave in a broadly accessible folder. A batch file may be readable by other users of the PC, depending on its permissions. If you need to rotate the key, update the script and test it again. For help with a key that changes or stops working, see the Windows stream-key troubleshooting guide; its OBS-specific details may not map exactly to FFmpeg, but the key-handling issue is relevant.
Run the batch file by double-clicking it or invoking it from a Command Prompt before making a task. Confirm it behaves as expected and that the log is written. A script that calls FFmpeg successfully in this test is the input to the next step, not evidence that it will run under every Windows account or that viewers can see a live broadcast.
Create a Windows startup task
Open Task Scheduler from the Start menu and choose Create Task, rather than relying on a shortcut in the Startup folder. A task gives you a defined trigger, action and run context, which you can test on demand. Names such as YouTube FFmpeg stream make it easier to identify the task later; a short description can record the script path and the video source it expects.
On the General tab, choose the Windows account that has access to the script, media and any capture device. Whether the task should run only while that account is signed in depends on whether the job needs its interactive desktop. Do not assume that selecting a different run option fixes missing permissions or makes a camera accessible outside a user session. Test the actual choice on the actual PC.
Select a trigger on the Triggers tab and an action on Actions. The exact labels and available options can vary by Windows version. Start with one trigger and one action, then use Task Scheduler’s Run command to test the task without waiting for a reboot. If the script depends on a particular working directory, fill in Start in on the action; otherwise relative paths may resolve somewhere unexpected.
A task can show that it was started while FFmpeg exits a moment later. Check the task’s last-run information and history, then inspect the FFmpeg log for the result. The log is more useful than a brief command window that appears and disappears, but it still tells you only what the local process reported. You must check YouTube separately.
The account and run context are operational decisions, not universal settings. A file on a local disk may be available to one account but not another. A network share may require credentials or a connection that is not available before sign-in. A camera or desktop-capture source may need an active session. Make a small checklist of required files, devices and network access, then confirm each under the chosen task context.
Choose At startup or At log on
Windows provides separate triggers for system startup and user logon. Microsoft’s schtasks reference describes ONSTART as running when the system starts and also documents ONLOGON as a logon trigger. In Task Scheduler, these correspond to At startup and At log on. They are alternatives with different timing, not two names for the same event.
| Trigger | What causes it to run | When it may fit | What to check |
|---|---|---|---|
| At startup | Windows starts | A noninteractive file-based process that should begin before a user signs in | Can the selected account access the file and network at that point? |
| At log on | A specified user signs in | A source or workflow that needs the user’s session or visible desktop | Will someone sign in after each reboot, and is that the account with access? |
If your source is a video file, a startup trigger may be workable provided the task’s account and access are set correctly. If you capture a desktop, interact with an application, or use a device that is exposed only in an interactive session, a logon trigger may be the more practical choice. A local camera’s availability depends on its drivers and the way the capture command runs, so verify rather than generalise.
Ask what you mean by “when the PC boots”. If you mean as soon as Windows starts, before anyone signs in, choose At startup and test whether the task can open its inputs in that context. If you mean after you sit down and sign in, choose At log on. The latter will not run until the specified user logs in; the former does not guarantee that an interactive video source will be ready.
A related distinction is whether the task should run only when the user is logged on or whether it can run without an interactive session. A background FFmpeg process may not need a visible desktop, but a capture input might. Select the run context according to the source, then reboot and test. If the source is unavailable, changing triggers or permissions without understanding the device’s requirements can obscure the real issue.
For a recorded lesson or devotional video, a local file often makes the input side easier to reason about than a live desktop capture. The workflow still needs a reliable connection and a correctly configured YouTube stream. For planning a file-based channel, this guide to recorded Spanish lessons as an always-on stream offers a related example of how content and continuous playback affect the setup.
Configure the task action
On the Actions tab, select Start a program. Set Program/script to the full path of the batch file, such as C:\YouTubeLive\start-stream.bat. If Task Scheduler does not launch the file as expected, you can instead call cmd.exe and pass the batch file as an argument, for example /c "C:\YouTubeLive\start-stream.bat". Keep the executable and argument fields distinct, and test the chosen form using Run.
Set Start in (optional) to the script’s folder if it relies on relative paths. This field is a folder, not the batch file itself. Better still, make the script’s important file paths explicit so it does not depend on the starting folder. Avoid placing a script or its input in a temporary folder that may be cleaned or moved.
Review the task’s conditions and settings rather than accepting defaults without thought. A condition tied to AC power can prevent a laptop task from running on battery. A stop-after-duration setting can interrupt a long-running stream. A setting to start the task as soon as possible after a scheduled start does not mean that an earlier failed stream has been restored. Only change settings you understand, and record what you changed so you can diagnose later.
Use the Run control to launch the saved task. Check that it can locate FFmpeg, read the source, write logs and reach the network in its configured context. If the task reports an error, compare its account, working directory and paths with the manual run rather than immediately changing unrelated settings. A mapped drive letter, for example, may exist in an interactive session but not for a task running before logon.
The task is a launcher. It does not inspect YouTube’s Live Control Room, decide whether the feed should be public, or guarantee that the process will recover after a power cut, network interruption, input failure or YouTube-side issue. If you need unattended recovery, design and test that requirement separately; do not infer it from a task that starts once at boot.
Confirm FFmpeg reaches YouTube
After starting the task, read the log and check the FFmpeg output for connection and input errors. A process that remains open may be stalled or repeatedly reporting an issue; a process that exits may have encountered an error or reached the end of its input. Interpret the output in context. For example, a file input can finish normally if it is not configured to loop, while a continuous source should ordinarily remain active.
Open YouTube Studio and check the stream in Live Control Room. Look for an incoming preview and the stream-health information YouTube makes available. The relevant server URL and key are account- and stream-specific, so if YouTube does not receive the feed, verify the current values in that room before editing a command based on an old example. Do not paste the key into a public support post or an unredacted log shared with others.
A feed arriving at YouTube is a useful milestone, but it is not the same as viewers seeing a live broadcast. YouTube’s workflow differs between a direct stream and a scheduled event. For a scheduled stream, its encoder instructions describe waiting for the preview and selecting Go live. If the process is meant to run without anyone present, decide in advance how the stream will be activated and verify the current workflow in Live Control Room; the Windows task does not perform that YouTube action merely by opening FFmpeg.
Once you have confirmed the feed, let the stream run through a practical test. Check that video and audio are present, that the selected source remains available, and that the picture is not unexpectedly blank or frozen. For audio problems, see this guide to distorted audio in an always-on YouTube podcast stream. The test should reflect the real input, not just a command prompt that prints a connection message.
If FFmpeg connects but the preview is absent, check the target stream and key, endpoint, encoding options and any errors in the log. If preview appears but the broadcast is not public, check whether the stream is scheduled or otherwise awaiting an action in Studio. Keep these diagnoses separate: one concerns the encoder-to-YouTube feed, the other concerns YouTube’s broadcast state.
Verify the broadcast is live to viewers
Use a separate browser or device to view the channel’s public watch page, not only the account’s Live Control Room. Confirm that the intended title and stream are visible and that playback actually begins. A Studio preview can help you inspect the incoming feed, but it is not conclusive proof that an ordinary viewer can watch the public broadcast.
For a scheduled event, compare the status in Live Control Room with the public page and complete the required activation step when appropriate. If you cannot be present at the start, do not assume that an At startup task can click Go live or publish the scheduled event. Set up a workflow you can operate reliably, or choose a streaming approach that matches your need for human activation.
Test a complete reboot, not just Task Scheduler’s Run button. After Windows restarts, note whether the correct account signs in, whether the task starts, whether FFmpeg reads the expected source, whether YouTube receives a preview, and whether the public page shows the intended broadcast. This sequence makes it easier to identify the point of failure. Repeat the check after changing the trigger, account, source, command or YouTube stream settings.
Keep expectations about recovery modest. Startup automation can remove the need to open a terminal after a normal restart, but it cannot by itself fix a disconnected router, a failed disk, a camera that is not ready, a changed stream key or a broadcast waiting for a human action. If your channel relies on a local Windows PC, consider how you will notice and respond to those failures, especially when no one is in the room overnight.
A stream built around a file rather than a live capture can reduce some device dependencies, but it does not eliminate power, connectivity or platform dependencies. If you are deciding whether a local PC is the right basis for a continuous channel, compare it with this OBS setup guide for a 24/7 stream in India. The tools and instructions differ, but the same practical question applies: what must be running, and how will you know the viewers can see it?
YouTube says streams under 12 hours are automatically archived in its encoder guidance. That archival rule is not a promise of continuous uptime, successful restart or uninterrupted playback. Check YouTube’s current help information for the stream you are planning, and keep a separate record or source file if you need your own copy.
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
Will FFmpeg automatically make a scheduled YouTube stream public?
Not by itself. FFmpeg can send a feed, but YouTube’s scheduled-stream workflow may require you to wait for the preview and select Go live in Live Control Room. Check the state of the specific stream rather than treating a running process as proof that viewers can watch.
Should I choose At startup or At log on?
Choose At startup when Windows should launch the process before a user signs in and the input is available in that run context. Choose At log on when the source or workflow depends on a particular user session. Test the selected account and trigger with the real source.
Why does the task work manually but fail after reboot?
A scheduled task can use a different account, working directory or access context from your interactive Command Prompt. Check explicit paths, permissions, network-share access, device availability and the FFmpeg log. A manual success does not establish that the task’s context has the same resources.
Does a startup task restart FFmpeg if the stream drops?
A task configured to start at boot does not, on its own, prove that FFmpeg will restart after a later failure. Power loss, network issues, input problems and YouTube-side conditions can all interrupt a stream. Test any separate recovery arrangement you plan to rely on, and monitor the actual broadcast.