Linux + FFmpeg / Windows + OBS 双方案
含：自动重连、开机自启、断线恢复、推流参数建议、故障排查与开播清单
适用场景：冥想疗愈｜白噪音｜治愈陪伴｜风景循环｜Study / Relax / Sleep 24/7 直播
| 提示 | 阅读建议：如果你只想要一套最稳、最低折腾的方案，直接看第 5 章 Linux + FFmpeg 主方案；如果你更习惯图形界面，再看第 7 章 Windows + OBS 方案。 |
一、先看懂：什么叫“无人值守直播间”
真正的 24/7 无人值守，不是把远程桌面一直挂着、每天手动点“开始直播”，而是把直播做成一条可自动恢复的推流链路：素材上传到云服务器，推流程序长期运行，异常退出后自动拉起，服务器重启后自动恢复。
图 1 直播链路总览示意图
在 YouTube 官方的直播体系里，云服务器这套做法属于使用 encoder（编码器）直播：你需要在 Live Control Room 里创建直播，拿到 Stream URL 和 Stream Key，然后让 FFmpeg 或 OBS 把音视频持续推送到 YouTube。YouTube 官方说明，第一次启用直播功能可能需要最多 24 小时；启用直播还要求频道已验证，且过去 90 天内没有直播限制。
| 提示 | 一句话结论：如果你的直播内容是单视频循环、静态图加背景音乐、白噪音或冥想陪伴，Linux + FFmpeg 几乎总是比“云电脑 + 手动点 OBS”更稳、更省钱。 |
二、两种常见方案怎么选
| 方案 | 适合场景 | 推荐配置 | 结论 |
| Linux + FFmpeg | 单个或多个 MP4 循环；静态图 + 音乐；24/7 常开频道 | 2–4 vCPU / 2–4 GB / Ubuntu | 最推荐，稳定、便宜、好守护 |
| Windows + OBS | 多场景切换、字幕条、Logo、浏览器源 | 4 vCPU / 8 GB 起 / Windows | 上手直观，但资源占用更高 |
| 云电脑手动开播 | 偶尔直播、临时测试 | 任意 | 不适合无人值守 |
图 2 推荐部署拓扑与方案选择逻辑
● ● ●
三、开播前准备：账号、服务器、素材，一项都不能少
1. YouTube 账号条件
按照 YouTube 官方说明，要启用直播，你需要先验证频道，过去 90 天内没有直播限制；首次启用直播能力时，可能需要等待最多 24 小时。
- 进入 YouTube Studio，点击“创建” → “开始直播（Go Live）”。
- 如果是首次开播，先启用直播功能，并确认频道状态正常。
- 建议第一次把直播可见性设置为“不公开（Unlisted）”，先测试 30–120 分钟，再正式公开。
2. 云服务器建议配置
| 直播类型 | CPU / 内存 | 系统 | 备注 |
| 静态图 + 音乐 | 2 vCPU / 2–4 GB | Linux | 最省资源，适合冥想/白噪音/陪伴直播 |
| 单个 1080p 视频循环 | 2–4 vCPU / 4 GB | Linux | 常见风景、路景、治愈频道主流选项 |
| 多场景导播、浏览器源 | 4 vCPU / 8 GB 起 | Windows | 更适合 OBS 图形化制作 |
3. 素材准备建议
- 一种最省事的方式：准备一个较长的 live.mp4，直接无限循环。
- 如果画面变化不需要太多，准备一张 1920×1080 的海报图，加一条 bgm.mp3，即可做成 24/7 音乐或陪伴直播。
- 文件名尽量简短、全英文或数字，避免中文空格路径带来脚本错误。
| 提示 | 版权风险别忽视：长时间直播最怕的不是程序崩，而是版权问题。即使系统不立刻拦截，后续也可能触发版权匹配、内容替换或收益问题。长期频道尽量使用你拥有授权的音乐和素材。 |
四、YouTube 端怎么创建直播并拿到推流信息
在 YouTube Live Control Room 中，真正需要填到 FFmpeg 或 OBS 里的，核心只有两项：Stream URL（或 Server URL）和 Stream Key。官方说明也明确写了：如果编码器里有 YouTube 预设就直接选；没有的话，就把 YouTube 提供的 Stream URL 填到 encoder 的 server/RTMP server 字段，把 Stream Key 填到对应的密钥字段。
图 3 Stream URL 与 Stream Key 对应关系
操作顺序
- 进入 YouTube Studio → 右上角“创建” → “开始直播（Go Live）”。
- 点击“Stream（串流）”标签页；如果是第一次，先创建一个 stream。
- 在“Stream settings”区域复制 Stream URL / Server URL。
- 在同一区域复制 Stream Key。
- 把这两项分别填到 FFmpeg 或 OBS 的推流配置中。
- 如果你使用的是预约直播，在 Live Control Room 里看到预览画面出现后，再点击“Go live”。
| 提示 | 关于回放归档：YouTube 官方说明：12 小时以内的直播会自动归档。做 24/7 连续直播时，不要把自动归档当成唯一备份手段；重要内容建议自己留原始素材或本地录制。 |
官方推荐的几个关键参数
| 参数项 | 官方建议 |
| 协议 | RTMP / RTMPS |
| 视频编码 | H.264 / H.265（HEVC）/ AV1 |
| 帧率 | 最高 60 fps |
| 关键帧频率 | 推荐 2 秒，不要超过 4 秒 |
| 音频编码 | AAC 或 MP3 |
| 码率模式 | CBR |
| 立体声音频采样率 | 44.1 KHz |
| 立体声音频码率 | 128 Kbps |
| 提示 | 安全建议：YouTube 官方提供了 RTMPS 说明页，并建议优先使用 RTMPS，因为它是在 TLS/SSL 之上的加密传输。能用 RTMPS，就不要用明文 RTMP。 |
● ● ●
五、Linux + FFmpeg 主方案：从 0 到可长期运行
下面以 Ubuntu / Debian 系统为例演示。你只要会通过 SSH 连到服务器，就能把这套方案搭起来。相比云电脑长期挂着，FFmpeg 的脚本化方案更适合无人值守和自动恢复。
1. 连接服务器并安装 FFmpeg
| sudo apt update && sudo apt upgrade -y sudo apt install -y ffmpeg ffmpeg -version |
2. 建议目录结构
| 路径 | 用途 |
| /opt/ytlive/media | 存放 MP4 / JPG / MP3 素材 |
| /opt/ytlive/bin | 存放启动脚本 |
| /etc/systemd/system/ytlive.service | 存放 systemd 守护服务文件 |
| sudo mkdir -p /opt/ytlive/media sudo mkdir -p /opt/ytlive/bin |
3. 先把素材传上去
- 如果你走“单视频循环”路线，把主文件命名为 /opt/ytlive/media/live.mp4。
- 如果你走“海报图 + 背景音乐”路线，准备 /opt/ytlive/media/poster.jpg 和 /opt/ytlive/media/bgm.mp3。
| 提示 | 为什么推荐英文文件名：路径中包含中文、空格、括号时，Shell 转义更容易出错。为了减少你后期排错时间，素材文件和目录名尽量统一用英文小写。 |
4. 方案 A：一个 MP4 无限循环推流
| #!/usr/bin/env bash STREAM_URL=”这里替换为 YouTube 的 Stream URL” STREAM_KEY=”这里替换为你的 Stream Key” ffmpeg -re -stream_loop -1 -i /opt/ytlive/media/live.mp4 \ -c:v libx264 \ -preset veryfast \ -pix_fmt yuv420p \ -r 30 \ -g 60 \ -c:a aac \ -b:a 128k \ -ar 44100 \ -b:v 6000k \ -maxrate 6000k \ -bufsize 12000k \ -f flv “${STREAM_URL}/${STREAM_KEY}” |
这里最关键的两项是：-stream_loop -1 表示无限循环输入文件；-re 表示按实时速度读取素材，而不是一口气把文件“灌”出去。这两个参数非常适合把本地文件伪装成持续直播信号。
5. 方案 B：一张海报图 + 一条背景音乐推流
| #!/usr/bin/env bash STREAM_URL=”这里替换为 YouTube 的 Stream URL” STREAM_KEY=”这里替换为你的 Stream Key” ffmpeg -re \ -loop 1 -framerate 30 -i /opt/ytlive/media/poster.jpg \ -stream_loop -1 -i /opt/ytlive/media/bgm.mp3 \ -vf “scale=1920:1080,format=yuv420p” \ -c:v libx264 \ -preset veryfast \ -tune stillimage \ -pix_fmt yuv420p \ -r 30 \ -g 60 \ -c:a aac \ -b:a 128k \ -ar 44100 \ -b:v 4500k \ -maxrate 4500k \ -bufsize 9000k \ -f flv “${STREAM_URL}/${STREAM_KEY}” |
这套脚本适合冥想、白噪音、陪伴、睡眠、治愈音乐等低动态直播。画面不复杂时，不必盲目堆高码率，先把稳定性跑通，再慢慢加画质。
六、让直播真正“无人值守”：systemd 自动重启与开机自启
只要 FFmpeg 还靠你手工 SSH 进去执行，它就不算真正的无人值守。Linux 服务器上最稳的方式，是交给 systemd 管理：进程退出后自动拉起；服务器重启后自动恢复。
1. 创建服务文件
| sudo nano /etc/systemd/system/ytlive.service |
| [Unit] Description=YouTube 24×7 Live Stream After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/ytlive ExecStart=/opt/ytlive/bin/start_mp4.sh Restart=always RestartSec=5 [Install] WantedBy=multi-user.target |
2. 让服务生效
| sudo systemctl daemon-reload sudo systemctl enable ytlive sudo systemctl start ytlive sudo systemctl status ytlive |
3. 实时查看日志
| sudo journalctl -u ytlive -f |
| 提示 | 为什么 Restart=always 很重要：24/7 直播最常见的失败并不是配置永远错，而是偶发断线、编码器异常退出或网络波动。systemd 能在这些“小概率事件”发生后自动把流重新推起来。 |
4. 我建议你这样压测
- 先把 YouTube 直播设为不公开，连续跑 1–2 小时。
- 手工执行一次 sudo systemctl restart ytlive，看直播是否能恢复。
- 重启服务器一次，看系统起来后服务是否自动推流。
- 观察 journalctl 日志是否存在连续报错、文件路径错误或权限错误。
5. 24/7 直播的实操参数建议
| 场景 | 分辨率 / 帧率 | 视频码率 | 建议 |
| 静态图 + 音乐 | 720p30 | 3.5–4.5 Mbps | 最稳，最省资源 |
| 风景或路景循环 | 1080p30 | 4.5–6 Mbps | 推荐起步档位 |
| 动态变化较多的视频 | 1080p30 | 6–8 Mbps | 先确认线路稳定再上调 |
| 复杂导播/快速运动 | 1080p60 | 8–12 Mbps | 更适合硬件编码或 OBS |
| 提示 | 一个很实用的原则：24/7 直播首先追求的是“不断”，其次才是“极致画质”。你宁可用 5 Mbps 稳定跑 30 天，也不要用 12 Mbps 跑一晚就断。 |
● ● ●
七、Windows + OBS 方案：更直观，但更吃资源
如果你更习惯可视化操作，或者你需要多个场景、字幕条、Logo、倒计时、浏览器源，那么 Windows 云服务器 + OBS 会更符合使用习惯。它的核心逻辑与 FFmpeg 相同：拿到 Stream URL 和 Stream Key，推给 YouTube。区别在于 OBS 用的是图形化设置。
1. 推荐使用情形
- 你要做多场景切换、片头片尾、滚动字幕、计时器、浏览器源。
- 你习惯看着画面搭建直播，而不是写脚本。
- 你需要更像“导播台”的操作感。
2. OBS 中最常用的场景搭法
- Media Source：导入 MP4，并勾选循环。
- Image + Audio Input：静态图 + 背景音乐。
- Text（GDI+）/ 浏览器源：叠加标题、文案、时间、Logo。
3. 推荐设置（起步值）
| 设置页 | 字段 | 建议值 |
| Stream | Service | YouTube RTMPS（有预设就直接选） |
| Output | Rate Control / Bitrate | CBR / 4500–6000 Kbps 起步 |
| Output | Keyframe Interval | 2 |
| Video | Base / Output Resolution | 1920×1080 或 1280×720 |
4. OBS 官方排障里很值得开的几个选项
- Advanced → Network → Enable network optimizations
- Advanced → Network → Enable TCP pacing（Windows 可用）
- Bind to IP 设为 Default
- 连接不稳时可以试试 IPv4 Only
- 如果实在无法解决拥塞，可开启动态码率调整，但它只是缓解，不是根治
| 提示 | 掉帧的根因判断：OBS 官方排障文档明确指出：如果出现 dropped frames 或间歇性断流，通常是你的机器到推流服务器之间的网络问题，而不是 OBS 本身。最先该做的是降码率、换线路、换机房，而不是怀疑“软件坏了”。 |
八、常见故障与对应处理办法
| 故障现象 | 高概率原因 | 处理建议 |
| YouTube 有预览，但观众端没开播 | 你创建的是预约直播，还没在控制室点击 Go live | 等预览出现后，进入 Live Control Room 手动点 Go live |
| 直播频繁掉帧或断流 | 网络波动、码率过高、线路质量差 | 先降码率，再换机房或线路；Windows + OBS 可开网络优化和 TCP pacing |
| 有画面没声音 | 素材无音轨、音频参数不对、音频文件损坏 | 用 ffprobe 检查源文件；确认 AAC / 44.1KHz / 单一音频流 |
| 黑屏或直接报错 | 素材路径写错、文件没上传、脚本权限不足 | ls 检查文件路径，确认脚本 chmod +x，查看 journalctl |
| 服务器重启后没自动恢复 | 没有启用 systemd 或服务文件有误 | systemctl enable ytlive；检查 ExecStart 路径 |
| Live Control Room 报音视频参数错误 | 分辨率、码率、采样率与建议不匹配 | 对照 YouTube 官方 encoder settings 与 error messages 提示修正 |
| 直播被替换成占位图或被切断 | 版权匹配、第三方内容被识别 | 立即停播相关内容，改用自有授权素材 |
九、开播前的最终检查清单
| 检查项 | 是否完成 |
| 频道已验证，且过去 90 天无直播限制 | □ |
| 首次启用直播已等待生效 | □ |
| 已在 Live Control Room 创建 stream | □ |
| 已复制并核对 Stream URL 与 Stream Key | □ |
| 云服务器已安装 FFmpeg 或 OBS | □ |
| 素材文件已上传到正确目录 | □ |
| 已进行至少 30–120 分钟的不公开压测 | □ |
| 已配置自动重启 / 开机自启 | □ |
| 已确认音频、分辨率、码率参数正常 | □ |
| 已确认素材授权或版权风险可控 | □ |
| 提示 | 最稳成品推荐：如果你现在就想把频道跑起来，我建议直接使用：Linux + FFmpeg + systemd，内容做成“静态海报图 + 背景音乐”或“单个长 MP4 循环”，先用 720p30 / 4 Mbps 或 1080p30 / 5–6 Mbps 起步。跑稳定后，再逐步升级到更复杂的 OBS 场景。 |
十、附录：本文依据的官方资料（截至 2026-03-17）
- YouTube Help｜Create a YouTube live stream with an encoder
- YouTube Help｜Choose live encoder settings, bitrates, and resolutions
- YouTube Help｜Encrypt your stream using RTMPS
- YouTube Help｜Get started with live streaming
- YouTube Help｜Live streaming error messages
- FFmpeg Documentation｜ffmpeg（-stream_loop / -re）
- OBS Knowledge Base｜Stream Connection Troubleshooting
文中插图为示意图，目的是帮助理解部署结构与操作顺序，并非 YouTube 或 OBS 官方界面截图。
实操时，如果你看到平台提示的“建议码率”“采样率错误”“关键帧错误”等告警，以 Live Control Room 当前提示和官方文档为准。
Linux + FFmpeg / Windows + OBS 双方案
含：自动重连、开机自启、断线恢复、推流参数建议、故障排查与开播清单
适用场景：冥想疗愈｜白噪音｜治愈陪伴｜风景循环｜Study / Relax / Sleep 24/7 直播
| 提示 | 阅读建议：如果你只想要一套最稳、最低折腾的方案，直接看第 5 章 Linux + FFmpeg 主方案；如果你更习惯图形界面，再看第 7 章 Windows + OBS 方案。 |
一、先看懂：什么叫“无人值守直播间”
真正的 24/7 无人值守，不是把远程桌面一直挂着、每天手动点“开始直播”，而是把直播做成一条可自动恢复的推流链路：素材上传到云服务器，推流程序长期运行，异常退出后自动拉起，服务器重启后自动恢复。
图 1 直播链路总览示意图
在 YouTube 官方的直播体系里，云服务器这套做法属于使用 encoder（编码器）直播：你需要在 Live Control Room 里创建直播，拿到 Stream URL 和 Stream Key，然后让 FFmpeg 或 OBS 把音视频持续推送到 YouTube。YouTube 官方说明，第一次启用直播功能可能需要最多 24 小时；启用直播还要求频道已验证，且过去 90 天内没有直播限制。
| 提示 | 一句话结论：如果你的直播内容是单视频循环、静态图加背景音乐、白噪音或冥想陪伴，Linux + FFmpeg 几乎总是比“云电脑 + 手动点 OBS”更稳、更省钱。 |
二、两种常见方案怎么选
| 方案 | 适合场景 | 推荐配置 | 结论 |
| Linux + FFmpeg | 单个或多个 MP4 循环；静态图 + 音乐；24/7 常开频道 | 2–4 vCPU / 2–4 GB / Ubuntu | 最推荐，稳定、便宜、好守护 |
| Windows + OBS | 多场景切换、字幕条、Logo、浏览器源 | 4 vCPU / 8 GB 起 / Windows | 上手直观，但资源占用更高 |
| 云电脑手动开播 | 偶尔直播、临时测试 | 任意 | 不适合无人值守 |
图 2 推荐部署拓扑与方案选择逻辑
● ● ●
三、开播前准备：账号、服务器、素材，一项都不能少
1. YouTube 账号条件
按照 YouTube 官方说明，要启用直播，你需要先验证频道，过去 90 天内没有直播限制；首次启用直播能力时，可能需要等待最多 24 小时。
- 进入 YouTube Studio，点击“创建” → “开始直播（Go Live）”。
- 如果是首次开播，先启用直播功能，并确认频道状态正常。
- 建议第一次把直播可见性设置为“不公开（Unlisted）”，先测试 30–120 分钟，再正式公开。
2. 云服务器建议配置
| 直播类型 | CPU / 内存 | 系统 | 备注 |
| 静态图 + 音乐 | 2 vCPU / 2–4 GB | Linux | 最省资源，适合冥想/白噪音/陪伴直播 |
| 单个 1080p 视频循环 | 2–4 vCPU / 4 GB | Linux | 常见风景、路景、治愈频道主流选项 |
| 多场景导播、浏览器源 | 4 vCPU / 8 GB 起 | Windows | 更适合 OBS 图形化制作 |
3. 素材准备建议
- 一种最省事的方式：准备一个较长的 live.mp4，直接无限循环。
- 如果画面变化不需要太多，准备一张 1920×1080 的海报图，加一条 bgm.mp3，即可做成 24/7 音乐或陪伴直播。
- 文件名尽量简短、全英文或数字，避免中文空格路径带来脚本错误。
| 提示 | 版权风险别忽视：长时间直播最怕的不是程序崩，而是版权问题。即使系统不立刻拦截，后续也可能触发版权匹配、内容替换或收益问题。长期频道尽量使用你拥有授权的音乐和素材。 |
四、YouTube 端怎么创建直播并拿到推流信息
在 YouTube Live Control Room 中，真正需要填到 FFmpeg 或 OBS 里的，核心只有两项：Stream URL（或 Server URL）和 Stream Key。官方说明也明确写了：如果编码器里有 YouTube 预设就直接选；没有的话，就把 YouTube 提供的 Stream URL 填到 encoder 的 server/RTMP server 字段，把 Stream Key 填到对应的密钥字段。
图 3 Stream URL 与 Stream Key 对应关系
操作顺序
- 进入 YouTube Studio → 右上角“创建” → “开始直播（Go Live）”。
- 点击“Stream（串流）”标签页；如果是第一次，先创建一个 stream。
- 在“Stream settings”区域复制 Stream URL / Server URL。
- 在同一区域复制 Stream Key。
- 把这两项分别填到 FFmpeg 或 OBS 的推流配置中。
- 如果你使用的是预约直播，在 Live Control Room 里看到预览画面出现后，再点击“Go live”。
| 提示 | 关于回放归档：YouTube 官方说明：12 小时以内的直播会自动归档。做 24/7 连续直播时，不要把自动归档当成唯一备份手段；重要内容建议自己留原始素材或本地录制。 |
官方推荐的几个关键参数
| 参数项 | 官方建议 |
| 协议 | RTMP / RTMPS |
| 视频编码 | H.264 / H.265（HEVC）/ AV1 |
| 帧率 | 最高 60 fps |
| 关键帧频率 | 推荐 2 秒，不要超过 4 秒 |
| 音频编码 | AAC 或 MP3 |
| 码率模式 | CBR |
| 立体声音频采样率 | 44.1 KHz |
| 立体声音频码率 | 128 Kbps |
| 提示 | 安全建议：YouTube 官方提供了 RTMPS 说明页，并建议优先使用 RTMPS，因为它是在 TLS/SSL 之上的加密传输。能用 RTMPS，就不要用明文 RTMP。 |
● ● ●
五、Linux + FFmpeg 主方案：从 0 到可长期运行
下面以 Ubuntu / Debian 系统为例演示。你只要会通过 SSH 连到服务器，就能把这套方案搭起来。相比云电脑长期挂着，FFmpeg 的脚本化方案更适合无人值守和自动恢复。
1. 连接服务器并安装 FFmpeg
| sudo apt update && sudo apt upgrade -y sudo apt install -y ffmpeg ffmpeg -version |
2. 建议目录结构
| 路径 | 用途 |
| /opt/ytlive/media | 存放 MP4 / JPG / MP3 素材 |
| /opt/ytlive/bin | 存放启动脚本 |
| /etc/systemd/system/ytlive.service | 存放 systemd 守护服务文件 |
| sudo mkdir -p /opt/ytlive/media sudo mkdir -p /opt/ytlive/bin |
3. 先把素材传上去
- 如果你走“单视频循环”路线，把主文件命名为 /opt/ytlive/media/live.mp4。
- 如果你走“海报图 + 背景音乐”路线，准备 /opt/ytlive/media/poster.jpg 和 /opt/ytlive/media/bgm.mp3。
| 提示 | 为什么推荐英文文件名：路径中包含中文、空格、括号时，Shell 转义更容易出错。为了减少你后期排错时间，素材文件和目录名尽量统一用英文小写。 |
4. 方案 A：一个 MP4 无限循环推流
| #!/usr/bin/env bash STREAM_URL=”这里替换为 YouTube 的 Stream URL” STREAM_KEY=”这里替换为你的 Stream Key” ffmpeg -re -stream_loop -1 -i /opt/ytlive/media/live.mp4 \ -c:v libx264 \ -preset veryfast \ -pix_fmt yuv420p \ -r 30 \ -g 60 \ -c:a aac \ -b:a 128k \ -ar 44100 \ -b:v 6000k \ -maxrate 6000k \ -bufsize 12000k \ -f flv “${STREAM_URL}/${STREAM_KEY}” |
这里最关键的两项是：-stream_loop -1 表示无限循环输入文件；-re 表示按实时速度读取素材，而不是一口气把文件“灌”出去。这两个参数非常适合把本地文件伪装成持续直播信号。
5. 方案 B：一张海报图 + 一条背景音乐推流
| #!/usr/bin/env bash STREAM_URL=”这里替换为 YouTube 的 Stream URL” STREAM_KEY=”这里替换为你的 Stream Key” ffmpeg -re \ -loop 1 -framerate 30 -i /opt/ytlive/media/poster.jpg \ -stream_loop -1 -i /opt/ytlive/media/bgm.mp3 \ -vf “scale=1920:1080,format=yuv420p” \ -c:v libx264 \ -preset veryfast \ -tune stillimage \ -pix_fmt yuv420p \ -r 30 \ -g 60 \ -c:a aac \ -b:a 128k \ -ar 44100 \ -b:v 4500k \ -maxrate 4500k \ -bufsize 9000k \ -f flv “${STREAM_URL}/${STREAM_KEY}” |
这套脚本适合冥想、白噪音、陪伴、睡眠、治愈音乐等低动态直播。画面不复杂时，不必盲目堆高码率，先把稳定性跑通，再慢慢加画质。
六、让直播真正“无人值守”：systemd 自动重启与开机自启
只要 FFmpeg 还靠你手工 SSH 进去执行，它就不算真正的无人值守。Linux 服务器上最稳的方式，是交给 systemd 管理：进程退出后自动拉起；服务器重启后自动恢复。
1. 创建服务文件
| sudo nano /etc/systemd/system/ytlive.service |
| [Unit] Description=YouTube 24×7 Live Stream After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/ytlive ExecStart=/opt/ytlive/bin/start_mp4.sh Restart=always RestartSec=5 [Install] WantedBy=multi-user.target |
2. 让服务生效
| sudo systemctl daemon-reload sudo systemctl enable ytlive sudo systemctl start ytlive sudo systemctl status ytlive |
3. 实时查看日志
| sudo journalctl -u ytlive -f |
| 提示 | 为什么 Restart=always 很重要：24/7 直播最常见的失败并不是配置永远错，而是偶发断线、编码器异常退出或网络波动。systemd 能在这些“小概率事件”发生后自动把流重新推起来。 |
4. 我建议你这样压测
- 先把 YouTube 直播设为不公开，连续跑 1–2 小时。
- 手工执行一次 sudo systemctl restart ytlive，看直播是否能恢复。
- 重启服务器一次，看系统起来后服务是否自动推流。
- 观察 journalctl 日志是否存在连续报错、文件路径错误或权限错误。
5. 24/7 直播的实操参数建议
| 场景 | 分辨率 / 帧率 | 视频码率 | 建议 |
| 静态图 + 音乐 | 720p30 | 3.5–4.5 Mbps | 最稳，最省资源 |
| 风景或路景循环 | 1080p30 | 4.5–6 Mbps | 推荐起步档位 |
| 动态变化较多的视频 | 1080p30 | 6–8 Mbps | 先确认线路稳定再上调 |
| 复杂导播/快速运动 | 1080p60 | 8–12 Mbps | 更适合硬件编码或 OBS |
| 提示 | 一个很实用的原则：24/7 直播首先追求的是“不断”，其次才是“极致画质”。你宁可用 5 Mbps 稳定跑 30 天，也不要用 12 Mbps 跑一晚就断。 |
● ● ●
七、Windows + OBS 方案：更直观，但更吃资源
如果你更习惯可视化操作，或者你需要多个场景、字幕条、Logo、倒计时、浏览器源，那么 Windows 云服务器 + OBS 会更符合使用习惯。它的核心逻辑与 FFmpeg 相同：拿到 Stream URL 和 Stream Key，推给 YouTube。区别在于 OBS 用的是图形化设置。
1. 推荐使用情形
- 你要做多场景切换、片头片尾、滚动字幕、计时器、浏览器源。
- 你习惯看着画面搭建直播，而不是写脚本。
- 你需要更像“导播台”的操作感。
2. OBS 中最常用的场景搭法
- Media Source：导入 MP4，并勾选循环。
- Image + Audio Input：静态图 + 背景音乐。
- Text（GDI+）/ 浏览器源：叠加标题、文案、时间、Logo。
3. 推荐设置（起步值）
| 设置页 | 字段 | 建议值 |
| Stream | Service | YouTube RTMPS（有预设就直接选） |
| Output | Rate Control / Bitrate | CBR / 4500–6000 Kbps 起步 |
| Output | Keyframe Interval | 2 |
| Video | Base / Output Resolution | 1920×1080 或 1280×720 |
4. OBS 官方排障里很值得开的几个选项
- Advanced → Network → Enable network optimizations
- Advanced → Network → Enable TCP pacing（Windows 可用）
- Bind to IP 设为 Default
- 连接不稳时可以试试 IPv4 Only
- 如果实在无法解决拥塞，可开启动态码率调整，但它只是缓解，不是根治
| 提示 | 掉帧的根因判断：OBS 官方排障文档明确指出：如果出现 dropped frames 或间歇性断流，通常是你的机器到推流服务器之间的网络问题，而不是 OBS 本身。最先该做的是降码率、换线路、换机房，而不是怀疑“软件坏了”。 |
八、常见故障与对应处理办法
| 故障现象 | 高概率原因 | 处理建议 |
| YouTube 有预览，但观众端没开播 | 你创建的是预约直播，还没在控制室点击 Go live | 等预览出现后，进入 Live Control Room 手动点 Go live |
| 直播频繁掉帧或断流 | 网络波动、码率过高、线路质量差 | 先降码率，再换机房或线路；Windows + OBS 可开网络优化和 TCP pacing |
| 有画面没声音 | 素材无音轨、音频参数不对、音频文件损坏 | 用 ffprobe 检查源文件；确认 AAC / 44.1KHz / 单一音频流 |
| 黑屏或直接报错 | 素材路径写错、文件没上传、脚本权限不足 | ls 检查文件路径，确认脚本 chmod +x，查看 journalctl |
| 服务器重启后没自动恢复 | 没有启用 systemd 或服务文件有误 | systemctl enable ytlive；检查 ExecStart 路径 |
| Live Control Room 报音视频参数错误 | 分辨率、码率、采样率与建议不匹配 | 对照 YouTube 官方 encoder settings 与 error messages 提示修正 |
| 直播被替换成占位图或被切断 | 版权匹配、第三方内容被识别 | 立即停播相关内容，改用自有授权素材 |
九、开播前的最终检查清单
| 检查项 | 是否完成 |
| 频道已验证，且过去 90 天无直播限制 | □ |
| 首次启用直播已等待生效 | □ |
| 已在 Live Control Room 创建 stream | □ |
| 已复制并核对 Stream URL 与 Stream Key | □ |
| 云服务器已安装 FFmpeg 或 OBS | □ |
| 素材文件已上传到正确目录 | □ |
| 已进行至少 30–120 分钟的不公开压测 | □ |
| 已配置自动重启 / 开机自启 | □ |
| 已确认音频、分辨率、码率参数正常 | □ |
| 已确认素材授权或版权风险可控 | □ |
| 提示 | 最稳成品推荐：如果你现在就想把频道跑起来，我建议直接使用：Linux + FFmpeg + systemd，内容做成“静态海报图 + 背景音乐”或“单个长 MP4 循环”，先用 720p30 / 4 Mbps 或 1080p30 / 5–6 Mbps 起步。跑稳定后，再逐步升级到更复杂的 OBS 场景。 |
十、附录：本文依据的官方资料（截至 2026-03-17）
- YouTube Help｜Create a YouTube live stream with an encoder
- YouTube Help｜Choose live encoder settings, bitrates, and resolutions
- YouTube Help｜Encrypt your stream using RTMPS
- YouTube Help｜Get started with live streaming
- YouTube Help｜Live streaming error messages
- FFmpeg Documentation｜ffmpeg（-stream_loop / -re）
- OBS Knowledge Base｜Stream Connection Troubleshooting
文中插图为示意图，目的是帮助理解部署结构与操作顺序，并非 YouTube 或 OBS 官方界面截图。
实操时，如果你看到平台提示的“建议码率”“采样率错误”“关键帧错误”等告警，以 Live Control Room 当前提示和官方文档为准。
