To stream a Hindi devotional playlist to YouTube 24/7 with MediaMTX, first publish a media stream to a MediaMTX path with FFmpeg, then configure MediaMTX to forward that path to YouTube. The documented FFmpeg loop repeats one file; rotating a set of bhajans or aarti recordings requires a separate playlist process.
The two stages help you locate faults: check that FFmpeg is publishing to the intended path, then check that MediaMTX forwards a program containing both audio and video to YouTube. The commands below are starting points, not a guarantee that every file will play or that a host and network will remain available continuously.
How the two-stage pipeline works
In the first stage, FFmpeg reads a local media file and publishes it over RTMP to a named path on MediaMTX. In the second, MediaMTX uses a forwarding rule to send the path to YouTube's current RTMPS ingest destination. YouTube receives the stream rather than reaching back to your computer for the original file.
Think of the path as the hand-off between stages. If the path is named mypath, FFmpeg publishes to that path and the MediaMTX configuration forwards that same path. A mismatch — for example, publishing to mystream while forwarding mypath — leaves the second stage with nothing to send.
MediaMTX documents FFmpeg as an RTMP publishing client and says the published stream is available on the path named in the URL. Its FFmpeg publishing example shows a file loop, while its RTMP client documentation describes the publishing side. Its forwarding documentation covers the next hand-off. These are examples to adapt and verify against the versions and configuration you are using, not an end-to-end validation of your machine.
This design is useful when you want control over the media source and the YouTube destination to be separate. It also means there are two processes and two places to diagnose. A stream that reaches MediaMTX has not necessarily reached YouTube, and a forwarding rule cannot fix a source that never produced usable audio and video.
Prepare and check the devotional media file
Start with the actual file or playlist you intend to broadcast. Check that the intended programme has an audio track and a video track. The video could be devotional artwork or a static image, but the outgoing programme still needs a video track. MediaMTX warns that YouTube requires both tracks and silently rejects video-only streams; see MediaMTX's forwarding guidance.
The documented loop command uses an MP4 file and -c copy, which passes through the input streams without re-encoding. That can avoid extra processing when the formats are accepted across the publishing and forwarding path. It does not establish that an arbitrary MP4, audio-only file, codec combination or damaged recording will work. Inspect the source tracks and test the complete route before planning a long broadcast.
A Hindi devotional playlist can mean either one long file or a sequence of separate recordings. The loop command below handles one input file. It does not scan a directory, rotate through tracks, create transitions or manage metadata. If you need a sequence of bhajans and aarti, design a separate playlist source that outputs one continuous audio-and-video programme, and test how it behaves at track boundaries and after a restart.
You should also check the rights for each sound recording, composition, image and video you plan to broadcast. A devotional subject does not by itself establish that a particular recording or artwork is cleared for use. This guide does not make a legal determination; check the terms and permissions relevant to your material before sending it to a public channel.
If the programme uses a still visual with audio, check that the process actually emits video rather than assuming the image file will be included automatically. Likewise, do not infer compatibility from the filename extension. Your test should use the same source, FFmpeg options and forwarding route intended for the live channel.
Loop one file into a MediaMTX path
For a single file that you want to repeat, MediaMTX documents this FFmpeg publishing pattern:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
Replace file.mp4 with the path to your media file and mystream with the path you intend MediaMTX to receive. The documented -stream_loop -1 option repeats the input indefinitely, while -re reads it at its native rate. -f flv selects the publishing format used in the example. Here, localhost assumes FFmpeg and MediaMTX are on the same machine; if they are not, use the appropriate reachable address for the MediaMTX host and check its RTMP listener configuration.
The option -c copy is conditional, not a universal compatibility setting. It avoids re-encoding, but it cannot turn unsupported or unsuitable input tracks into a format accepted by every part of the route. If the copy-based test fails, investigate the input formats and current YouTube encoder guidance before choosing a transcode. The sources used here do not establish a universal bitrate, resolution or transcoding command for every devotional programme.
First verify the publish stage locally. MediaMTX's basic usage documentation shows the general pattern of publishing media into MediaMTX and reading the resulting stream with a client. A local read test can help distinguish “FFmpeg did not publish” from “YouTube did not receive the forward”. It does not replace the YouTube-side preview check.
A single-file loop repeats the same file, including its ending and beginning. Do not assume this creates a seamless musical transition: the result depends on the material and the full media path. Listen across a loop boundary during testing. For several tracks, use a separate playlist process rather than expecting -stream_loop to rotate files.
For a different hardware setup, the Raspberry Pi FFmpeg streaming guide may help you think through the host side. It does not change the MediaMTX path or remove the need to validate your own file and connection.
Configure MediaMTX to forward the path
Once FFmpeg can publish to the intended path, add a forwarding rule for that same path in MediaMTX. The documented configuration has a forward entry containing a destination. The shape is:
paths:
mypath:
forward:
- dest: rtmps://CURRENT_YOUTUBE_INGEST_URL#STREAM_KEY
This is illustrative only. mypath, CURRENT_YOUTUBE_INGEST_URL and STREAM_KEY are placeholders; do not paste them literally. The path key must match the RTMP publishing path, and the destination must use the current details shown in your YouTube live controls. MediaMTX's forwarding documentation shows the destination form and explains that its remembered YouTube ingest endpoint should be checked rather than treated as permanent.
Keep the key private. Do not put it in a screenshot, public configuration repository or a log shared for troubleshooting. If you need to show a configuration to someone else, replace the key with a placeholder first. The # separator in the documented destination syntax joins the ingest URL and key; it is not a reason to expose either value.
After changing the configuration, confirm MediaMTX accepts it and that the forward refers to the path you tested. A forwarding rule is a destination instruction, not a playlist manager or a media repair step. If the source path is absent, has only audio, or stops publishing, the forward cannot manufacture a usable programme.
Use YouTube's current RTMPS destination and key
Obtain the ingest destination and stream key from the channel's current YouTube live-stream controls. Do not copy a URL from an old tutorial or assume that the example on a documentation page remains current. MediaMTX's example itself cautions that the endpoint it showed was what YouTube reported when that documentation was last checked. Your account's live interface is the place to get the values for your broadcast.
Use the rtmps:// destination form shown in MediaMTX's example, and enter the current values exactly as presented by YouTube. Keep the key secret and check it carefully before starting. A mistyped or outdated key can make the second stage fail even when the local MediaMTX path is healthy.
Before relying on the setup, check YouTube's current instructions and eligibility requirements for the channel. Platform settings and requirements can change, and the steps here do not promise approval, eligibility or uninterrupted playback. If you need to rotate a key after it has been exposed, this guide to rotating a YouTube stream key is relevant to the credential-handling part of the work.
Treat the RTMPS destination as a value to verify at setup time, not a constant to hard-code into instructions for future operators. If a broadcast that worked before stops connecting after a configuration change, check the live controls again before rewriting the media pipeline.
Verify that YouTube receives audio and video
Test the outgoing programme in YouTube's live interface before treating it as ready for a long-running channel. Check that YouTube shows the expected video and that audio is actually present. MediaMTX's warning is specific: a video-only stream is silently rejected. A visible image alone is not evidence that the audio track is arriving, and an audio meter alone does not demonstrate that a video track is included.
Use a short controlled test to trace each stage. First, publish the file into MediaMTX and read the path locally. Then enable the forward and check YouTube's preview or test event. If the local read works but YouTube receives no programme, focus on the destination, key and forwarding configuration. If the local read is already wrong, return to the input file, FFmpeg command and path name.
Listen to speech or music at a practical volume and watch for an image that moves or remains stable as intended. Check a track boundary if you use a playlist process, and check the loop boundary if you repeat one file. A test with a different sample cannot prove that the production file will behave the same way.
If the picture is deliberately static, make sure it is still being carried as video through the complete route. If there is no audio, inspect the source and outgoing tracks rather than assuming YouTube will accept a silent visual stream. The required combination is an audio track and a video track; the content of each should match the channel's intended programme.
Plan for continuous operation and diagnose faults
A looping command is not a full 24/7 operations plan. It does not by itself supervise a crashed process, restore a host after a power cut, monitor a network, or guarantee that YouTube will maintain a broadcast. You need to decide who or what notices a stopped process, how it is restarted, and how someone checks the channel after an alert. Test those operational choices rather than treating a terminal that is currently running as proof of overnight reliability.
| Design choice | What the documented pattern gives you | What you still need to check |
|---|---|---|
| Repeat one file | FFmpeg can repeat one input with -stream_loop -1 |
Whether the content is appropriate at the loop boundary and whether the file plays through the full route |
| Rotate a playlist | Not provided by the single-file loop command | A separate source or process, track order, transitions and restart behaviour |
| Copy input streams | The example uses -c copy without re-encoding |
Whether those tracks are accepted by the publishing and forwarding path |
| Forward to YouTube | MediaMTX provides a path-level forwarding pattern | Current RTMPS destination and key, and confirmation that YouTube receives both tracks |
For a locally hosted setup, consider whether the host and network will remain available while you are not present. In India, a local network interruption can be a different problem from an invalid stream key or a source process that has stopped. The network checks for a disconnecting YouTube stream offer another lens on connection diagnosis; use them alongside the logs and checks for this two-stage pipeline.
Make the recovery process understandable to the person who will be on call. Record which process publishes the path, which path is forwarded, where the current key is stored securely and how to tell whether audio and video have reached YouTube. Avoid placing the key in shared notes. Keep a non-secret copy of the configuration structure so you can restore path names without exposing credentials.
If you do not want a computer in your own space to run the source continuously, compare that operational requirement separately from the MediaMTX recipe. StreamNeo removes the specific need to leave your computer running by turning an uploaded video into a YouTube live stream, but it is a different workflow from this FFmpeg-to-MediaMTX configuration and supports YouTube only. The comparison of cloud streaming and an Indian VPS can help frame the host-versus-managed-work question without changing the checks needed for your media rights and channel.
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
Does this FFmpeg command rotate through multiple bhajans?
No. The documented command repeats the single input file named after -i. A set of separate recordings needs a separate playlist source or process that produces one continuous stream; test its ordering, transitions and restart behaviour.
Can I send only audio with a still devotional image?
The outgoing programme must carry both an audio track and a video track. A still image can serve as the visual, but confirm that the publishing process includes it as video and that YouTube receives both tracks in its preview.
Can I use the example YouTube destination from a guide?
Treat the example as a syntax illustration, not as current credentials. Get the RTMPS destination and key from YouTube's live controls when configuring the channel, and keep the key private.
Does -stream_loop -1 make the channel reliably 24/7?
It repeats an input file; it does not supervise FFmpeg, restore a failed host or network, or promise YouTube playback. Plan monitoring and recovery separately, then test the entire route and the recovery process before relying on it.