A Raspberry Pi can play a prerecorded course on repeat and send its output to YouTube Live, but whether a particular Pi, file and internet connection can keep doing so continuously has to be tested. Treat this as a component-based setup, not a promise of uninterrupted 24/7 service.
This guide uses YouTube as its example destination. Before you prepare the Pi, confirm that you have permission to rebroadcast the course and decide who should be able to watch it; a university network or another platform may require a different ingest and access-control setup.
Confirm rights and choose the destination
Start with the recording, not the encoder. A course may include lectures, slides, music, student questions, guest material or other contributions whose use is governed by university policy or permissions. Check with the university, lecturer or recording owner whether this specific video and its audio may be rebroadcast, and whether the intended audience and duration are permitted. No general platform setting can answer that question for your recording.
Next decide where the stream should be available. YouTube offers public, unlisted and private visibility choices, but each has different consequences for access: an unlisted stream is reachable by people who have its link, while private access is more restricted and can require viewers to sign in with invited accounts. Review YouTube’s current live-streaming setup and visibility guidance before choosing. If the material must remain inside a university network, ask its IT team about the supported delivery method, authentication and firewall requirements instead of assuming a YouTube stream is suitable.
Also consider what a continuous replay means for learners. A live stream is not automatically an interactive class, a learning-management-system recording or an access-controlled course room. If learners need chapters, captions, course enrolment checks or a way to revisit particular lessons, plan those separately and explain the schedule and format to viewers. A simple repeating broadcast may suit revision or a public lecture loop; it may not suit a course that depends on discussion or assessment.
For a broader checklist of recording suitability, use this review of recorded classes for a 24/7 stream. It helps surface material and presentation issues before you invest time in configuring a device.
Check YouTube eligibility and ingest needs
For the YouTube example, check that live streaming is enabled on the channel before building the rest of the setup. YouTube’s current help guidance says a channel needs to be verified and must not have had a live-streaming restriction in the preceding 90 days. The channel also remains responsible for following the platform’s Community Guidelines and Terms of Service. See YouTube’s official live-streaming setup instructions for the current eligibility steps and any changes.
An encoder sends video and audio to YouTube using a stream key and ingest address. Keep the key private: anyone who obtains it may be able to send a broadcast to the channel’s stream. Use the current encoder setup in YouTube Studio to obtain the details, and do not paste a key into a public script, shared screenshot or course notes. If you expose it, replace it in the platform before restarting.
YouTube’s encoder guidance recommends RTMPS and lists H.264, H.265 and AV1 video codecs. It recommends constant bitrate (CBR) and a two-second keyframe interval, not exceeding four seconds. For H.264, the page lists recommended bitrates of 8 Mbps for 720p30, 14 Mbps for 1080p30 and 42 Mbps for 4K30. These are platform encoder settings, not a guarantee that your connection can sustain them or that your Pi can produce them. Check YouTube’s live encoder settings and match the intended resolution and frame rate to what the complete setup can actually deliver.
Use a wired network connection if practical, then test the upload line at the location and time the stream will run. A speed test is only a snapshot; household traffic, Wi-Fi conditions, router restarts and ISP interruptions can change available capacity. Leave room beyond the selected video bitrate for normal variation and other network traffic. If the line cannot sustain the chosen setting in a long test, reduce the output requirement or choose a different location or delivery method rather than relying on a brief successful preview.
Prepare the Raspberry Pi and course files
A headless Pi can run without a monitor and keyboard after initial setup, but it still needs boot storage, suitable power and a working network connection. Raspberry Pi’s getting-started documentation recommends at least 8 GB of boot storage for Raspberry Pi OS Lite and a 32 GB recommended minimum for desktop editions. Those are operating-system boot-storage recommendations; they do not tell you how much space your course recording needs.
Match the power supply to the exact model rather than buying one on the assumption that all Pi boards draw the same amount. Raspberry Pi’s current getting-started guidance specifies a 27 W USB-C supply for Raspberry Pi 5, and 15 W USB-C for Raspberry Pi 4 Model B and Raspberry Pi 400. Peripherals can affect power demand, and a removable cable can introduce voltage loss. Follow the documentation for your board and use a sound cable and supply; do not treat a successful short boot as proof that the device will remain stable under sustained work.
Copy the course file to local storage where possible, then verify it plays from that storage before configuring the live output. Confirm duration, audio, aspect ratio, resolution and whether any opening or ending material creates a long blank or silent section. Retain an untouched source copy elsewhere. A microSD card used for the operating system is not automatically an appropriate place for a large course archive or the only copy of important material.
Raspberry Pi OS includes VLC, and Raspberry Pi documents hardware-accelerated playback in its OS. That makes local playback a reasonable path to test, not proof that a particular Pi can decode your file and encode or relay it to YouTube without interruption. If your file is already in an appropriate format, first see whether the chosen pipeline can pass it through without re-encoding. Re-encoding adds work and heat, and may change picture or sound; if the file requires conversion, test that exact conversion on the target device.
If the Pi will sit unattended, place it where it can shed heat and where its power and network connections are not easily disturbed. Avoid enclosing it in a cupboard or covering its vents. Check that the router, outlet and any power backup arrangements are as dependable as the broadcast requires. A Pi running in a comfortable room on a stable wired connection is a different test case from one behind a television, on congested Wi-Fi or exposed to heat.
Configure playback and looping
First establish a reliable local loop. In VLC, test the file from beginning to end and enable repeat using the playback controls or a launch configuration that suits your OS version. Watch and listen across the transition from the final frame back to the start. Confirm that the video does not pause for a long interval, that audio does not jump unexpectedly, and that the player does not display controls or desktop notifications in the captured output.
FFmpeg documents -stream_loop -1 as an option to loop an input indefinitely. It can be useful when constructing a playback pipeline, but the option alone does not define a complete YouTube encoder command: input format, audio handling, video codec, bitrate, keyframes, RTMPS address and stream key all have to be configured appropriately. Consult the FFmpeg option documentation for the version installed on your system, and test a short output before using a live key.
A practical first experiment is to play the file while observing CPU load, temperature and dropped frames, then try the intended output settings. If the Pi struggles, distinguish decoding from encoding: a file that plays smoothly on screen may still be too demanding to encode live. A prepared file that can be passed through may reduce processing, but compatibility with the destination and your pipeline must be verified. Do not select a resolution because it sounds preferable; use one the device and network sustain during a long run.
Decide whether you need the course to start again automatically after a reboot. A player can be configured to launch at startup, but a process starting is not the same as a healthy broadcast: it might fail to find the file, lose network access or open in the wrong display mode. Keep the launch procedure understandable enough that another person can recover it, and record where the source file, logs and settings are kept without recording the private stream key in a shared document.
Connect the encoder to YouTube Live
Create or schedule the live stream in YouTube Studio, then select the encoder workflow and copy the currently displayed ingest details to the Pi’s configuration. YouTube may present a stream key and an ingest server; keep these together as private credentials. Use RTMPS where the selected software and setup support it, as YouTube recommends it in its encoder guidance.
Set the encoder’s video format, resolution, frame rate, bitrate control and keyframe interval according to YouTube’s current guidance and what the Pi has passed in testing. For example, if the course is being sent as H.264 at 720p30, YouTube lists 8 Mbps as a recommended bitrate. That does not mean every Pi can encode that output or every internet plan can upload it continuously. A lower output can be more sensible if it is sufficient for lecture slides and the tested system handles it more consistently.
Check audio as carefully as video. Select an audio codec supported by the destination and encoder; YouTube lists AAC or MP3 in its recommendations. Listen to the stream preview with headphones, including at a lesson transition, and check that speech is intelligible, levels are not clipped and the audio remains in sync. For classes with captions, confirm they remain readable at the chosen resolution and are available in the way viewers need; burning captions into the video and providing platform captions are different approaches.
Before going public, use a private test stream or another controlled check if the channel’s workflow permits it. Verify the preview in YouTube Studio, playback on a separate device and the selected visibility setting. If the content is intended for a restricted audience, make sure the intended viewers can reach it and that unintended viewers cannot. A stream key controls contribution to the broadcast; it is not, by itself, a viewer access policy.
If managing a Pi, home upload connection and restart behaviour becomes the main burden, a hosted approach changes which device must remain on. StreamNeo describes uploading a prerecorded video and running its YouTube broadcast without keeping your own computer on; it may remove the need to leave the Pi at home, but you should check current service terms and whether the workflow fits your access requirements. The recorded lecture stream setup guide covers the YouTube-side planning in more detail.
Run a sustained end-to-end test
A short preview confirms only that the pieces can connect at that moment. Before relying on the setup, test the actual Pi, exact course file, output format, destination, network, power arrangement and physical location together for an extended period that reflects your intended use. There is no official documentation here certifying a particular Raspberry Pi and file combination for uninterrupted 24/7 service.
During the test, check the stream from a second device and note when you observe buffering, dropped frames, audio drift, black frames or unexpected pauses. Also inspect the Pi’s load and temperature, encoder messages, storage availability and network behaviour. A one-time check at the start will not show whether a router reconnect, device update or overheating condition appears later. Use a simple log with time and symptom so you can distinguish a repeated failure from an isolated interruption.
Test recovery deliberately while the stream is not serving viewers who depend on it. Reboot the Pi and confirm the player and encoder start in the intended order, the correct file opens, and YouTube receives a healthy feed. In a controlled trial, briefly interrupt the network and observe whether the encoder retries, whether the platform ends the live session, and what action is needed to restore it. Then check playback from the viewer side after recovery. Automatic process restart can address a crashed application, but cannot guarantee that the network, stream session or file playback has recovered correctly.
Write down a recovery procedure in plain language: where to see whether the Pi is on, which status to check in YouTube Studio, how to restart the software safely, and who can intervene if you are away. Plan updates and maintenance rather than allowing a reboot prompt or software change to appear during a teaching period. If a test fails, change one component at a time—file, resolution, cooling, power or network—so you know which adjustment helped, then repeat the longer test.
A Raspberry Pi route can make sense when you want local control, already have compatible equipment, can provide reliable power and upload, and are comfortable checking logs and handling recovery. A cloud or managed stream may be preferable when you cannot leave home equipment on, your household upload is variable, or nobody can respond to a failure. Compare those trade-offs with streaming a playlist from a cloud server in Mumbai and the Lightsail VPS approach for recorded services; neither removes the need to check rights, destination access or current terms.
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
Can I stream a recorded course from a Raspberry Pi without a monitor?
Yes, a Pi can be prepared as a headless host and controlled remotely after setup. You still need to verify that playback and the encoder start correctly after a reboot, and that you can inspect the live feed and logs without a local display.
Should I encode the video on the Pi?
Only if the specific Pi can sustain the chosen encoding settings with the actual course file in a long test. Start by checking whether a compatible file can be passed through without re-encoding; if conversion is needed, test that workload, temperature and network output before depending on it.
Do YouTube settings apply to a university private network?
No. The codec, ingest and stream-key examples here are for YouTube Live, and a private university network may use a different receiver, authentication method or firewall policy. Ask the university IT team for its approved path and access-control requirements.
Does a successful test guarantee the stream will stay live all day?
No. A test provides evidence about the components and conditions you tested, not a guarantee against later power, network, software or platform interruptions. Keep a recovery plan and repeat the test after material changes to the file, encoder, device or connection.