Нужно забрать RTSP с IP-камеры и отдать в YouTube Live. Удобная схема: небольшой VPS (у меня в том числе на Hetzner / Oracle Cloud) + ffmpeg + cron, который поднимает процесс, если он упал.
Скрипт ретрансляции
Создайте файл, например /opt/cam2yt.sh, и подставьте свой RTSP URL и ключ трансляции из YouTube Studio (Live → Настройки потока):
#!/bin/bash
SERVICE="ffmpeg"
RTSP_URL="rtsp://192.168.0.119:554/video.pro1"
YOUTUBE_URL="rtmp://a.rtmp.youtube.com/live2"
YOUTUBE_KEY="xxxx-xxxx-xxxx-xxxx"
COMMAND="sudo ffmpeg -f lavfi -i anullsrc -rtsp_transport tcp -i ${RTSP_URL} \
-tune zerolatency -vcodec libx264 -t 12:00:00 -pix_fmt + \
-c:v copy -c:a aac -strict experimental \
-f flv ${YOUTUBE_URL}/${YOUTUBE_KEY}"
if sudo /usr/bin/pgrep "$SERVICE" > /dev/null; then
echo "${SERVICE} is already running."
else
echo "${SERVICE} is NOT running! Starting now..."
$COMMAND
fi
Права на запуск:
chmod 775 /opt/cam2yt.sh
Cron и звук
Если звук с камеры не нужен — оставляйте anullsrc (тишина в аудиодорожке; YouTube часто требует audio track). Если звук нужен — уберите -f lavfi -i anullsrc и возьмите аудио из RTSP (параметры зависят от камеры).
Добавьте в crontab проверку каждую минуту (путь к скрипту — свой):
* * * * * /opt/cam2yt.sh >> /var/log/cam2yt.log 2>&1
Нагрузка и сеть
При -c:v copy (без перекодирования видео) нагрузка на CPU обычно низкая: ffmpeg в основном принимает RTSP и пушит FLV/RTMP. Имеет смысл, если кодек камеры совместим с тем, что ждёт YouTube. Если нет — придётся кодировать (libx264 и т.п.), и CPU/VRAM вырастут.
Камера и VPS должны видеть друг друга по сети (белый IP, VPN, port forwarding или камера в той же сети, что и хост). Ключ YouTube не светите в публичных репозиториях: при утечке сбросьте stream key в Studio.
VPS для подобных задач: Hetzner Cloud (реферальная ссылка) или любой VPS с нормальным исходящим каналом.