For a 24/7 bhajan channel, FFmpeg can loop a media file into a MediaMTX path, and MediaMTX can forward that feed to YouTube over RTMPS. The documented commands are starting examples, not proof that an arbitrary file will play correctly or loop without a visible or audible break.
The work is in checking the file, choosing a publishing path, confirming YouTube receives both tracks, and deciding how you will monitor and record the channel. Use a representative test before relying on the setup overnight.
Plan the FFmpeg and MediaMTX architecture
The basic chain is: a local file goes into FFmpeg; FFmpeg publishes it to a named MediaMTX path; MediaMTX forwards that path to YouTube's current ingest address. MediaMTX is a media server and proxy, not an encoder in this arrangement. The documented examples use -c copy, which passes the source streams through rather than converting them. If the source is not compatible with your intended output, you need to prepare a suitable file or choose an encoding workflow; do not expect MediaMTX to fix its codecs.
This layout separates the file reader from the YouTube connection. It can be useful when you want a stable local publishing point, or when MediaMTX is already part of your setup. It also creates another process and connection to monitor. For a single pre-encoded file, direct FFmpeg publishing to YouTube may be simpler; adding MediaMTX is not automatically more reliable. The official MediaMTX introduction describes its role, while the FFmpeg publishing guide gives the documented publishing examples.
Before choosing, ask what you need the relay to do. If your only requirement is to send one file to YouTube, direct publishing removes a hop. If you specifically need the MediaMTX path for other readers, forwarding, or a workflow you already operate, the relay gives you that structure. Neither arrangement removes the need for process supervision, network monitoring, or a local recording if you need a replay.
A bhajan channel may use one long recording, a prepared compilation, or a sequence of files assembled into a single programme. These are different source workflows. The MediaMTX example below loops one input file, so it does not by itself create a playlist that transitions between several recordings. Prepare the programme in a way you can inspect before putting it on air. For a wider channel-planning comparison, see how to start a Hindi music livestream without keeping a computer on.
Check the bhajan file’s audio and video
Start with a source you have the rights to broadcast. Technical checks cannot determine whether a particular recording, performance, composition or image is authorised for your use. Then inspect the actual file you intend to publish: it must contain an audio stream and a video stream. YouTube requires both for the forwarding method in MediaMTX's guide; a video-only feed can be silently rejected.
Do not assume that an MP4 extension means the contained streams meet YouTube's current recommendations. Inspect the codecs, dimensions, frame rate, audio sample rate, channel layout and whether audio remains present from beginning to end. FFprobe, which is distributed with FFmpeg, can show stream details. For example, ffprobe -hide_banner -i bhajan.mp4 is an inspection command, not a compatibility certificate. Look at its output and compare it with YouTube's current encoder settings.
YouTube lists H.264, H.265/HEVC and AV1 video, and AAC or MP3 audio in its current RTMP/RTMPS guidance. It recommends constant bitrate encoding, a two-second keyframe interval and says not to exceed four seconds. Its advanced stereo recommendations include 44.1 kHz and 128 Kbps audio. Treat these as guidance for configuring an encoder, not as evidence that every file using one of those formats will pass every channel-specific check. If you use -c copy, these settings are not changed by FFmpeg during publishing.
A devotional visual may be largely static, such as a temple image or lyric card, but the feed still needs a valid video track. An audio-only source with a still image added in a separate process is a different workflow from looping a file that already contains both tracks. Check the encoded output you will actually send, not just the source material. During a private or unlisted test, confirm that the YouTube Live Control Room preview shows video and that audio can be heard.
Bitrate is a practical bandwidth decision as well as a setting. Match it to the available upload connection and the chosen resolution and frame rate; YouTube publishes ranges by codec and format. If your connection cannot sustain the stream with room for ordinary variation, lowering the output demands or using a more suitable connection is safer than hoping the short test reflects an entire night. For further background on frame timing, see this FFmpeg keyframe-frequency troubleshooting guide.
Loop and publish the file to MediaMTX
The MediaMTX FFmpeg page's RTSP example for a file source is:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f rtsp rtsp://localhost:8554/mystream
Here, -re paces file reading in real time, -stream_loop -1 requests an infinite loop, -i names the input, and -c copy passes through the existing audio and video streams. The RTSP URL publishes to the MediaMTX instance at localhost on the documented port and path mystream. Replace the filename and address to fit your arrangement; if FFmpeg and MediaMTX run on different machines, localhost will not identify the other machine.
This is a documented example, not a command tested against your bhajan recording. The file may use unsupported or unsuitable streams, have no audio, or behave differently at the loop boundary. Test it with the actual input and read FFmpeg's output for connection errors, missing streams and timestamps. Listen and watch across the point where playback returns to the start. A command requesting repetition does not guarantee a seamless loop: that depends on how the media was made and where its audio and video end.
Keep the path name consistent with the one you configure in MediaMTX. In the example, the published path is mystream; a later forwarding configuration must refer to that same path. Use a different path if you have a reason to separate sources, but record the mapping in your runbook so a restart does not leave you guessing which feed is being sent to YouTube.
If the source needs transcoding, do not simply change -c copy to a guessed collection of encoder settings and assume the result is right. Establish the target video and audio formats, bitrate, keyframe interval and frame rate using YouTube's current guidance, then test the resulting output. A representative motion pattern and audio level matter; a static preview alone will not tell you whether movement or sound is behaving as intended.
Choose the documented RTSP or RTMP publishing path
MediaMTX recommends RTSP for publishing from FFmpeg, and its guide also documents an RTMP alternative. The alternative example is:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
This uses the FLV muxer and the RTMP publishing address shown by MediaMTX. The examples are alternatives for reaching a MediaMTX path; they are not a test result showing that one is better for every file or network. Start with RTSP unless your setup calls for RTMP or you have a specific reason to use the documented alternative. In either case, confirm that MediaMTX reports the path as available and that the expected audio and video are present.
There are two separate protocol decisions here. FFmpeg publishes to MediaMTX using RTSP or RTMP; MediaMTX then forwards onward to YouTube. For the onward connection, use RTMPS where available, as YouTube recommends encrypted delivery. Do not confuse the local publishing URL in the examples with YouTube's ingest URL. Keeping those stages distinct makes troubleshooting more straightforward: first test the source-to-MediaMTX leg, then the MediaMTX-to-YouTube leg.
Configure MediaMTX forwarding to YouTube
Open YouTube Live Control Room for the channel and obtain the current stream URL and key there. MediaMTX's forwarding guide illustrates a path that sends its incoming feed to an RTMPS destination, with the key separated from the URL by #. It cautions that the example URL may change, so do not copy a historical address from a tutorial and assume it remains current. YouTube's RTMPS guidance explains the encrypted connection.
The documented configuration shape is:
paths:
mypath:
forward:
- dest: rtmps://CURRENT_YOUTUBE_INGEST_URL#STREAM_KEY
This is illustrative: replace the placeholder with the current ingest address and the private key from Live Control Room, and make sure the path name matches the one FFmpeg publishes to. Follow the configuration syntax for your installed MediaMTX version and validate it before restarting. The example mypath is not automatically the same as the FFmpeg example's mystream; either name can work if the publishing and forwarding path names agree.
Treat the stream key as a password. Do not put it in a public repository, screenshot, tutorial, shared chat or a configuration file accessible to people who do not need it. Restrict access to the machine and its configuration, and avoid pasting full command lines or logs into public support requests if they expose the key. If you believe it has been disclosed, reset it in Live Control Room and update the forwarding configuration. YouTube's live settings help covers stream settings and key management.
Make the first connection a controlled test, not the start of an unattended night. Open Live Control Room, check its preview and stream health, and allow enough time to detect a bad source, a missing track or an ingest problem. Set visibility and schedule according to your channel plan. The same screen is where you should confirm current stream settings rather than relying on a saved URL from an old setup.
Confirm both tracks reach the live stream
The crucial check is not merely that FFmpeg connected or that MediaMTX accepted a publisher. Confirm end to end that YouTube receives both a moving or static video track and audible audio. MediaMTX's forwarding guide says YouTube requires both and warns that video-only streams are silently rejected. An input can contain audio locally while a later step drops it, so verify the preview and listen at the YouTube end.
Use a representative section of the bhajan programme. Listen for clipping, silence, unexpected gaps and an abrupt boundary when the file loops. Watch for black frames, a frozen picture or an unintended change in aspect ratio. If the source has lyrics or devotional artwork, check that the material is legible at the output resolution and not cropped by the selected framing. A short test can reveal configuration errors but cannot establish that a pipeline will remain healthy all day.
Review YouTube's stream-health messages alongside the preview. If the picture is present but audio is absent, inspect the file's streams first, then the FFmpeg command and the MediaMTX path. If the preview never becomes healthy, check the current ingest URL, stream key, path mapping, firewall or network route, and the output logs. Change one cause at a time where possible so you know which correction mattered.
For a channel that runs continuously, write down a small preflight record: source filename and version, expected audio and video streams, publishing protocol and path, current destination setup location, test result, and who can restart the process. Do not include the secret key in a document that is shared broadly. A repeatable checklist helps when the person who built the first setup is not the one checking it the next morning.
Monitor and recover the pipeline
A loop flag is not an operations plan. FFmpeg can stop because of a file error, process exit, host restart or network problem; MediaMTX forwarding can lose its destination; and YouTube can report an ingest issue. Decide who or what will notice a failure, how the processes will be restarted, and how you will confirm the stream is healthy again. Automatic restart behaviour, where used, should be tested deliberately rather than assumed from a successful first launch.
Monitor the local processes and the YouTube preview or health status. Check audio and picture, not just whether a process exists. If the channel matters while you sleep, arrange an alert or a human check that can detect a failed stream, and keep a concise recovery procedure: verify the source, restore the publishing process, confirm the MediaMTX path, check the YouTube preview, and verify sound. See how to run FFmpeg as a background service on Linux for a related process-management discussion; service supervision still needs testing and monitoring.
Plan a separate local recording if you need a dependable archive. YouTube says streams under 12 hours can be automatically archived, while a stream exceeding 12 hours may not be captured at all. Its archive guidance is explicit that a long live broadcast is not a guarantee of a complete replay. YouTube also warns that DVR rewind can be limited or unavailable on very long streams, so do not promise viewers they can rewind an entire day.
If you record locally, check that the file is growing and can be opened, and decide how much storage to retain before the disk fills. Test your archive procedure and failover before depending on it. YouTube's livestreaming tips recommend checking recording integrity and monitoring audio and video quality. For operators who would rather avoid maintaining a computer and relay process themselves, StreamNeo removes the specific burden of keeping that local publishing pipeline running by turning an uploaded file into a YouTube live stream that continues with your computer off.
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 use the MediaMTX FFmpeg command with any bhajan MP4?
No. The command is a documented example using real-time pacing, looping and stream copy, not a compatibility test for arbitrary files. Inspect the actual audio and video streams, test the command, and confirm both tracks appear in YouTube's preview.
Should I publish to MediaMTX over RTSP or RTMP?
MediaMTX recommends RTSP and documents RTMP as an alternative. Use the path that fits your setup, then verify the publisher reaches the matching MediaMTX path; the onward connection to YouTube is a separate decision, for which RTMPS is recommended.
Will YouTube keep a full-day replay of my channel?
Do not rely on it. YouTube says a stream longer than 12 hours may not be captured, and DVR rewind can also be limited or unavailable for very long streams. Make and check a local recording if retaining the programme matters.
Does looping one file guarantee a continuous, seamless channel?
No. The loop option requests repeated playback, but a clean boundary depends on the source file, and no command guarantees uninterrupted operation. Test the boundary, monitor the processes and stream health, and plan how you will detect and recover from a failure.