Выделенный сервер под видео и стриминг

Задачи здесь две, и упираются они в разное железо. Отдача готового видео ограничена каналом и диском: процессор почти не работает. Транскодирование ограничено процессором: один поток 1080p в x264 на пресете veryfast съедает несколько ядер. Считайте их отдельно и при росте разносите на разные машины.

Канал считают по формуле «битрейт × одновременные зрители» плюс 20% запаса на пики.
Транскодирование программное: E5-2680v4 с 28 потоками тянет несколько потоков 1080p одновременно, точное число даёт только тест.
30 ТБ трафика на Dedicated Start US — это примерно 11 000 часов просмотра при битрейте 6 Мбит/с.
Сегменты HLS пишутся и читаются мелкими файлами: NVMe убирает задержки, которых не видно на тесте линейного чтения.
Архив держат отдельно от рабочих дисков: дополнительный HDD 1 ТБ — $15/мес, выгрузка в хранилище — $10/мес.

Сколько канала нужно под зрителей

Качество и битрейт	100 Мбит/с (Start DE)	500 Мбит/с (Start FR)	1 Гбит/с (Pro и выше)
720p, 3 Мбит/с	около 25 зрителей	около 130	около 260
1080p, 6 Мбит/с	около 13	около 65	около 130
4K, 20 Мбит/с	около 4	около 20	около 40

Цифры уже учитывают 20% запаса: без него первый же всплеск зрителей превращается в буферизацию у всех сразу. Канал unmetered снимает вопрос объёма, но ширина порта остаётся жёстким потолком — разбор в статье про канал сервера и лимиты трафика. Гигабитный unmetered есть на тарифах Pro и Enterprise, включая площадку в США: конфигурации собраны на странице выделенных серверов в США.

Транскодирование: измерьте, а не угадывайте

Число потоков, которое вытянет процессор, зависит от пресета, разрешения и содержимого кадра. Единственный честный способ — прогнать кодирование в никуда и посмотреть коэффициент скорости.

# Debian/Ubuntu
apt-get install -y ffmpeg
# RHEL/AlmaLinux/Rocky (репозиторий RPM Fusion)
dnf install -y ffmpeg

# кодируем в /dev/null: нужен показатель speed=
ffmpeg -i source.mp4 -c:v libx264 -preset veryfast -b:v 6M \
       -c:a aac -b:a 128k -f null /dev/null 2>&1 | tail -3

Значение speed= больше 1x означает, что поток кодируется быстрее реального времени. Запас нужен двукратный: на speed=2x один процессор тянет примерно два таких потока, дальше начинаются дропы кадров. Как считать это при выборе тарифа — в статье про выбор процессора для сервера.

Нарезка HLS и отдача

Для вещания на браузеры стандарт де-факто — HLS: поток режется на сегменты по 2–6 секунд, плейлист обновляется, отдаёт всё обычный nginx.

# три качества в одном проходе, сегменты по 4 секунды
ffmpeg -re -i rtmp://127.0.0.1/live/stream \
  -filter_complex "[0:v]split=3[v1][v2][v3];[v2]scale=-2:720[v2o];[v3]scale=-2:480[v3o]" \
  -map "[v1]" -c:v:0 libx264 -b:v:0 6M \
  -map "[v2o]" -c:v:1 libx264 -b:v:1 3M \
  -map "[v3o]" -c:v:2 libx264 -b:v:2 1200k \
  -preset veryfast -g 96 -sc_threshold 0 \
  -f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments \
  -master_pl_name master.m3u8 /var/www/hls/v%v/index.m3u8 \
  > /var/log/ffmpeg-hls.log 2>&1 &

# проверяем, что сегменты реально появляются и старые удаляются
watch -n 2 'ls -1 /var/www/hls/v0 | wc -l'

Каталог сегментов удобно держать на tmpfs: живой поток всё равно перезаписывается, а диск освобождается от тысяч мелких записей. Для записей на хранение разница между типами накопителей разобрана в статье про NVMe, SATA SSD и HDD в сервере.

Хранение архива

Рабочие диски и архив держат раздельно. Тарифы Pro дают 2×1 TB NVMe в RAID1, Enterprise US — 4×1 TB NVMe в RAID10; под архив добавляют HDD 1 ТБ за $15/мес или выгружают записи во внешнее хранилище за $10/мес. Что выбрать по деньгам и скорости отдачи, помогает решить сравнение в статье про облачные хранилища S3.

Локация решает не меньше железа: чем дальше зритель, тем дольше стартует плейлист и тем чаще срабатывает буферизация на пиках. Методика замеров описана в статье про выбор локации сервера.

Лимит 30 ТБ на Dedicated Start US выглядит большим ровно до первого удачного эфира: при 6 Мбит/с его выбирают примерно 11 000 часов просмотра, то есть сотня зрителей за месяц регулярных трансляций. Считайте объём заранее и берите unmetered, если аудитория растёт. Вторая ловушка — запускать транскодирование на том же сервере, что и отдачу, без ограничения ресурсов: ffmpeg займёт все ядра, nginx начнёт отдавать сегменты с задержкой, и зрители увидят буферизацию там, где канал свободен. Ограничивайте кодировщик через systemctl set-property ffmpeg.service CPUQuota=60% и проверяйте результат не по «выглядит нормально», а по логам плеера: рост числа столлов при стабильном битрейте означает, что упёрлись в процессор.

Коротко

Отдачу ограничивает канал, транскодирование — процессор; считайте их отдельно.
Ширину канала берут как битрейт × зрителей плюс 20%; гигабитный unmetered держит около 130 зрителей в 1080p.
Число потоков транскодирования измеряют через ffmpeg с -f null и показатель speed, запас двукратный.
Сегменты HLS удобнее держать на tmpfs, архив — на отдельном HDD за $15/мес или во внешнем хранилище за $10/мес.
30 ТБ на Start US — примерно 11 000 часов просмотра в 1080p; при росте аудитории нужен unmetered.

Выделенный сервер под видео и стриминг: железо и канал