To make a YouTube Live loop of museum exhibit videos with FFmpeg, configure YouTube as the destination and use FFmpeg’s -stream_loop -1 input option to repeat a file continuously. The command below is an example, not a validated recipe: test it with your files, your installed FFmpeg build and a private or unlisted event before broadcasting publicly.
The reliable order is to confirm rights, check the media, create the YouTube stream, test the encode and watch its health. A video playing on a gallery screen does not by itself establish that every image, soundtrack or recording can be streamed online.
Check rights before you assemble the loop
Start with the contents of the actual files, not just the title of the exhibition or the museum’s ownership of a physical object. A video may combine footage, still images, artwork reproductions, narration, music and third-party material, each with separate permissions or restrictions. Confirm which components may be livestreamed and whether the permission covers YouTube, the intended territories, the broadcast period and any replay or archive that may remain available afterwards.
YouTube’s live streaming terms place responsibility on the provider to have the necessary rights for live content on Google services, including relevant music licensing rights. This is a platform requirement, not a conclusion about the rights in a particular collection or jurisdiction. If a licence is unclear about online transmission, territory or archived replay, ask the rights holder or the museum’s usual rights adviser before scheduling the event.
Keep a record that staff can use later: identify the file or sequence, the rights holder, permitted uses and any end date or territory limit. Include ambient music or audio captured in a gallery; it may be less obvious than a soundtrack deliberately added during editing. If one clip has narrower permission than the rest, remove it or build a separate, clearly bounded loop rather than assuming the whole exhibition has the same terms.
Prepare the files and playlist
Make a working copy of the approved media and note the order in which clips should appear. Preserve original files separately so that a test encode or conversion cannot overwrite a master. Give the working copies clear names, and keep them in a stable folder that the account running FFmpeg can read for the duration of the stream. If staff use a shared workstation, make sure a routine cleanup or update will not move or rename those files; the practical issue is similar to the one described in this guide to keeping media files available after a Windows update.
For a first test, use one representative file. Check that it opens, has the expected duration, shows the correct image orientation and aspect ratio, and plays the expected audio. Inspect the beginning and end as well as a section in the middle. A file that plays in a desktop media player may still have a format, timestamp or stream detail that behaves differently in an FFmpeg encode, so playback alone is not proof that the live output will be correct.
If the exhibit uses multiple files, decide whether the transition should be a simple cut or a designed transition. Separate clips may differ in frame size, frame rate, audio layout, colour or duration. The single-file loop shown below does not define a playlist, guarantee gapless joins or create transitions. Test whichever concat or playlist method you choose against the actual files, then watch the joins and listen for gaps, clipped narration or changes in loudness. Do not discover a bad join after the public event starts.
Keep the test set small enough to inspect carefully, but representative of the final material. Include the longest or most unusual clip, and any file with a different audio track or image shape. If the files need conversion, make a new output and compare it with the source before using it; conversion can change framing, colour or sound. For a related example of how playlist boundaries can affect a live video, see removing black screens between playlist videos.
Create a YouTube Live stream
Check that the channel is able to livestream before building the final workflow. YouTube says a channel must be verified and must not have live-streaming restrictions in the preceding 90 days. It also says first-time activation can take up to 24 hours, so do not leave eligibility checks until the exhibition’s scheduled start. Follow the current YouTube live-streaming eligibility guidance for the channel you will use.
In YouTube Studio’s Live Control Room, create or select an encoder-based stream and choose the appropriate visibility and schedule. The stream destination and key shown for that stream are what the encoder needs. YouTube describes the stream key as equivalent to a password and address for the feed. Keep it out of public scripts, screenshots, shared documents and support messages. If it is exposed, reset it in YouTube Studio rather than assuming it is harmless because the stream has not started.
Use a test event or an unlisted/private configuration for rehearsal, and confirm that the selected event is the one receiving the encoder feed. YouTube’s encoder setup guidance explains how to connect an encoder with the stream URL and key. Copy the current values from Live Control Room; do not rely on a URL copied from an old event or an example found elsewhere. The exact destination and protocol can depend on the stream configuration shown by YouTube.
If several staff members need access, agree who is permitted to retrieve or reset the key and how it is stored. Avoid embedding a real key in a command that will be saved in a public repository, screen recording or shared terminal transcript. Treat rehearsal credentials with the same care as the final ones, and replace them if anyone outside the intended team has seen them.
Use FFmpeg to repeat an input
FFmpeg documents -stream_loop as an input option: -1 requests infinite repetition, while 0 means no looping. Because it applies to an input, place it before the -i for the file it should repeat. The following shell snippet illustrates the shape of a one-file encoder command:
ffmpeg -re -stream_loop -1 -i exhibit.mp4 \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-c:a aac -f flv "<YouTube ingest URL>/<STREAM_KEY>"
This is a configuration example, not a tested command or a guarantee that every FFmpeg build, file or YouTube event will accept it unchanged. Its purpose is to show where the input loop option sits relative to the input. Substitute the destination and key from the selected YouTube stream, keep the key private, and check each option against the media, available encoders, operating system and current stream settings. FFmpeg’s documentation for loop options defines the input-loop behaviour; it does not validate this complete example against your files.
The -re option reads input at its native rate rather than sending a file as quickly as possible. That is useful to understand for a live feed, but it does not fix an incompatible file or an unstable network. The codec, pixel format, container, audio mapping and destination all need to make sense together. A build without the requested encoder, for example, will not behave as though the encoder were installed. Check your own build and read its error output instead of removing options at random.
For multiple files, do not assume that adding another filename or repeating this command will produce a seamless playlist. Playlist demuxing and concat methods have their own constraints, and files may need matching stream characteristics or deliberate filtering. Choose a workflow, run it for the complete intended sequence and inspect the transitions. If a managed continuous broadcast is more important than operating a local FFmpeg process, weigh that operational requirement separately; a local workstation still needs power, a stable connection and someone able to respond if the process stops.
Check encoding settings and command syntax
The command’s example video and audio encoders are starting points only. YouTube’s live encoder settings describe supported codecs and recommend constant bitrate encoding, a keyframe interval of two seconds and no more than four seconds. The page also recommends RTMPS for secure ingestion and gives different considerations for SDR and HDR. Match the chosen output to the source and the selected YouTube stream configuration rather than treating the highest available quality as automatically better.
For ordinary SDR, YouTube’s settings guidance specifies Rec. 709 colour space and 8-bit depth; HDR has different requirements. Do not apply SDR assumptions to an HDR exhibit master without checking how the media was produced and what the encoder path supports. A wrong colour or transfer setup can make a stream look different from the approved display copy. If you change scaling, frame rate or colour handling, compare the encoded test with the source on a suitable display.
Choose a quality that the available upload connection can sustain. The connection is shared with other activity in many museums, and a nominally suitable bitrate does not help if the uplink fluctuates or is saturated by other traffic. YouTube recommends testing and selecting quality based on the connection. Start with a conservative configuration that produces a stable preview, then assess whether a higher setting is justified. The OBS settings guide for 24/7 YouTube streaming in India discusses the same practical tension between output quality and the upload connection; its specific software context differs from FFmpeg.
Read FFmpeg’s output carefully during the test. Errors about an unknown option, missing encoder, unsupported input or failed connection each point to a different issue. Confirm the installed version and build options, check that paths and quoting are valid in your shell, and verify that the input is the intended file. Test any revised command with the same media and event type you plan to use publicly. A command that starts is not sufficient evidence that audio is mapped correctly, the feed remains stable or YouTube is receiving the intended quality.
Test privately and inspect stream health
Run a rehearsal with the planned input and output settings before the public event. In Live Control Room, wait for the preview and check that the image, sound and event destination are correct. YouTube recommends testing the stream, inspecting the preview and monitoring stream health and audio/video quality. Look for messages in the control room and compare what YouTube receives with what FFmpeg reports locally. A clean local terminal does not prove that viewers receive a clean stream.
Watch enough of the loop to confirm that the repeat occurs as intended. For a single file, check the end-to-start boundary and ensure the opening does not freeze or produce unexpected silence. For a sequence, inspect every transition at least once. Check spoken material for cut-off words, the sound level between clips, aspect ratio, crop and colour. If an event will run for a long period, a short rehearsal cannot prove that every later hour will be trouble-free, but it can catch basic compatibility and setup errors before viewers encounter them.
Also confirm access with the intended visibility setting. An unlisted test can be checked by colleagues who have its link, while a private event is limited to authorised accounts. Verify the chosen behaviour in the current YouTube interface and do not treat a successful internal preview as proof that the public event’s scheduling, permissions or viewer access are correct. If you are making a local recording during the test, check that the recording itself can be played back; YouTube’s live tips also advise checking local archive integrity where a local archive is used.
When the rehearsal is complete, note the working command, FFmpeg build, file versions and any settings that were changed, but redact the key and destination credentials before sharing notes. This makes a later rerun less dependent on one staff member’s memory while avoiding a credential leak. Repeat the test after a meaningful change to the input, encoder build, destination, network path or output settings.
Launch and monitor the public stream
Before switching the event to public, use a short checklist: rights confirmed for the broadcast and replay; correct media selected; playlist joins checked; current stream URL and key loaded securely; event title, visibility and schedule checked; rehearsal preview and health inspected; and a named person available to monitor the start. If the programme is time-sensitive, check the event’s viewer-facing page from a separate account or device as well as in Live Control Room.
For a continuous stream, decide in advance who is responsible for watching it and what they should do if the feed drops. A local FFmpeg process depends on the machine staying awake, the media remaining accessible, the network maintaining its upload and the process continuing to run. A server or cloud machine changes where the process runs, but it does not remove the need to test the connection, protect the key and monitor the actual YouTube feed. Compare those operating arrangements with your institution’s IT approval, access controls, staff cover and budget rather than assuming one is universally preferable.
If you need an always-on loop but do not want a staff computer left running, StreamNeo can remove that specific operational burden: it turns an uploaded video into a YouTube live stream, so the computer does not have to remain on for the broadcast. It is YouTube-only, so it is not a fit if the same feed must be sent to another platform; confirm that a file-based workflow suits the exhibit before choosing it.
When the stream is public, keep Live Control Room open or assign a colleague to check it at agreed intervals. Respond to health warnings by checking the relevant layer: source playback and disk access, FFmpeg messages, network upload, stream destination and YouTube’s received preview. Avoid changing several settings at once during an active broadcast, because that makes it harder to identify the cause and may interrupt the feed. If a change is needed, note what changed and verify the result in the control room.
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
How do I loop a video on YouTube Live with FFmpeg?
Use FFmpeg’s -stream_loop -1 input option before the relevant -i input, then send the encoded output to the stream destination and key shown in YouTube Studio. Treat any sample command as an example and test with your own file, installed build and a private or unlisted event before going public.
Can I loop several museum videos with the same command?
The example covers repeating one input, not building a multi-file playlist or guaranteeing gapless transitions. Choose and test a playlist or concat method with your files, checking clip order, joins, sound continuity and image framing before the public stream.
Why does the stream look or sound different from the source file?
The encoder settings, colour handling, scaling, audio mapping and source compatibility can all affect the output. Inspect the YouTube preview and health messages during a test, compare them with the source and adjust one setting at a time; check YouTube’s current encoder guidance for the selected stream.
Is gallery display permission enough for a livestream?
Not necessarily. Confirm permission for the video’s components, including images, footage, narration and music, and check the permitted platform, territory, duration and replay rights with the relevant rights holder. YouTube’s terms make the provider responsible for necessary rights, but this article cannot determine the rights status of a particular collection.