MediaMTX多RTSP流MP4 fallback配置：环境变量未初始化问题求助

核心问题原因 #

runOnInit 是在MediaMTX完成端口、路径等核心配置初始化之前触发的，因此此时$RTSP_PORT和$MTX_PATH这类环境变量还未被赋值，导致FFmpeg命令执行失败。

解决方案：改用runOnReady指令 #

runOnReady 会在MediaMTX完全启动（所有端口监听、路径配置加载完成）后触发，此时所有环境变量已正确初始化，能直接用于生成RTSP推送地址。

修改后的配置示例 #

fallbackpath:
    # 替换runOnInit为runOnReady，确保环境变量可用
    runOnReady: ffmpeg -re -stream_loop -1 -i "/path/to/fallback/video.mp4" -c:v copy -an -f rtsp "rtsp://127.0.0.1:$RTSP_PORT/$MTX_PATH"
    # 开启自动重启，确保fallback流意外中断后自动恢复
    runOnReadyRestart: yes
paths:
    stream1:
        source: rtsp://example.com/stream1
        fallback: fallbackpath
    stream2:
        source: rtsp://example.com/stream2
        fallback: fallbackpath
    # 其他主流配置...

关键注意事项 #

• FFmpeg命令稳定性：先手动执行一遍FFmpeg命令，确认视频文件路径正确、编码格式兼容，能成功推流到MediaMTX，避免因命令本身错误导致MediaMTX终止。
• 进程生命周期管理：runOnReadyRestart: yes会在FFmpeg进程退出时自动重启它，无需额外加&或nohup，MediaMTX会自动维护fallback流的持续运行。
• 日志排查：如果仍有问题，查看MediaMTX的启动日志，里面会包含FFmpeg命令的执行细节和错误信息，能快速定位问题点。

为什么runOnDemand不适用？ #

runOnDemand是当有客户端请求fallbackpath路径时才触发命令，但你的需求是启动时就预加载fallback流，确保主流中断时能无缝切换，因此runOnReady才是正确选择——它会在MediaMTX启动后立即启动fallback流，随时等待主流切换。

内容的提问来源于stack exchange，提问作者Jeremy Leys