If you run an unattended livestream setup — like a camera pointed at a bird feeder, a security cam, or any 24/7 broadcast — you’ve probably run into one of the most frustrating OBS errors: “You need to set up a broadcast before you can start streaming.” This error is especially maddening for automated setups where nobody is around to click through YouTube’s broadcast dialog every time the stream restarts. Fortunately, there’s a workaround that keeps unattended streams running reliably, even after YouTube automatically ends a broadcast overnight.
Why This Error Happens
The root of the problem lies in how YouTube Live handles broadcasts versus streams. When you connect OBS directly to your YouTube account, YouTube expects you to create and activate a “broadcast” through its dashboard before any incoming stream data will actually go live. For a manually operated channel, this isn’t a big deal — you open YouTube Studio, hit “Go Live,” and OBS takes it from there.
But for automated setups — where a computer reboots nightly and OBS launches from the Startup folder to begin streaming before sunrise and end after sunset — there’s no human present to authorize a new broadcast each day. YouTube ends the previous night’s broadcast automatically, and the next scheduled restart of OBS has nothing to attach itself to. The result: streaming fails silently, or throws the broadcast setup error, even though every other part of the pipeline (the camera, the network, the stream key) is working perfectly.
A Practical Workaround: Headless Firefox Plus FFmpeg
One approach that has worked in practice involves using a headless browser to “wake up” YouTube’s broadcast system before the stream starts, and then handing the actual video feed off to FFmpeg rather than relying on OBS’s built-in YouTube account integration.
The first step is launching a headless instance of Firefox that briefly loads the YouTube Studio live dashboard for your channel:
firefox --headless --no-remote "https://studio.youtube.com/channel/UC/livestreaming"Letting this page load for a few seconds is enough to prompt YouTube to reuse the last broadcast configuration that was set up in YouTube Studio. In testing, this method was confirmed reliable by deliberately ending the stream, waiting several minutes for YouTube to officially close out the broadcast, and then verifying that streaming would not resume without first reloading the Studio page through headless Firefox.
Once that step has “cooked” for a few seconds, FFmpeg can pick up the video source and begin streaming directly to YouTube’s RTMP endpoint:
ffmpeg -re -i "http://192.168.1.13:8081/video.mjpg?q=20&fps=30" -f lavfi -i anullsrc -c:v libx264 -preset veryfast -tune zerolatency -maxrate 2500k -bufsize 5000k -pix_fmt yuv420p -g 24 -r 24 -f flv "rtmp://a.rtmp.youtube.com/live2/<streamkey>"A key detail here is the -f lavfi -i anullsrc flag, which generates a silent, null audio track. YouTube’s live ingest will reject a stream that has no audio component at all, so this is necessary for video-only sources like a static camera feed. If your video source already includes an audio track, this flag can simply be omitted.
Applying This Fix Inside OBS
While the example above uses FFmpeg directly, the same underlying logic should apply within OBS itself. The trick is to avoid signing into your YouTube account through OBS’s built-in integration — which is what triggers the broadcast-dependency error in the first place — and instead configure OBS to stream using only a custom RTMP server URL and your YouTube stream key. This mirrors exactly what FFmpeg does under the hood: it bypasses the broadcast object entirely and pushes raw stream data straight to YouTube’s ingest server.
If pairing this with a headless Firefox call in your task scheduler still doesn’t resolve the issue in OBS specifically, it may be worth considering whether OBS is even necessary for a simple, fixed camera-to-stream pipeline. For single-source setups without overlays, scene switching, or audio mixing, FFmpeg alone — triggered by Task Scheduler or a cron job — can be a lighter, more dependable alternative.
Setting This Up for Reliable Automation
For anyone building this into a fully unattended system, the general sequence looks like this:
- Schedule the headless Firefox command to run a few seconds before your stream is due to start, giving YouTube Studio time to reactivate the last broadcast configuration.
- Immediately follow it with your FFmpeg (or OBS) streaming command, pointed at your RTMP URL and stream key.
- Confirm your camera source is reachable at the expected local network address, since an unreachable feed will cause FFmpeg to fail regardless of the broadcast status.
- Test the full cycle at least once by letting YouTube auto-end the broadcast, then confirming the next scheduled run successfully reconnects.
Final Thoughts
The “You need to set up a broadcast” error is a known pain point for anyone trying to run a fully automated, unattended YouTube livestream, particularly for long-running feeds like wildlife cameras that need to start and stop daily without manual intervention. Bridging the gap with a brief headless Firefox visit to YouTube Studio, followed by an FFmpeg push to YouTube’s RTMP endpoint, offers a dependable fix that has been tested across multiple restart cycles. If you’re currently stuck on this issue, this approach is worth trying before assuming OBS itself is the problem — in many cases, it’s simply the broadcast-account dependency getting in the way of an otherwise solid setup.