Виділений сервер під відео та стримінг
Задачі тут дві, і впираються вони в різне залізо. Віддача готового відео обмежена каналом і диском: процесор майже не працює. Транскодування обмежене процесором: один потік 1080p у x264 на пресеті veryfast з'їдає кілька ядер. Рахуйте їх окремо і при зростанні розносьте на різні машини.
- Канал рахують за формулою «бітрейт × одночасні глядачі» плюс 20% запасу на піки.
- Транскодування програмне: E5-2680v4 з 28 потоками тягне кілька потоків 1080p одночасно, точне число дає лише тест.
- 30 ТБ трафіку на Dedicated Start US — це приблизно 11 000 годин перегляду за бітрейту 6 Мбіт/с.
- Сегменти HLS пишуться і читаються дрібними файлами: NVMe прибирає затримки, яких не видно на тесті лінійного читання.
- Архів тримають окремо від робочих дисків: додатковий жорсткий диск 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 і жорсткі диски в сервері.
Зберігання архіву
Робочі диски й архів тримають окремо. Тарифи Pro дають 2×1 TB NVMe у RAID1, Enterprise US — 4×1 TB NVMe у RAID10; під архів додають жорсткий диск 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, архів — на окремому жорсткому диску за $15/міс або в зовнішньому сховищі за $10/міс.
- 30 ТБ на Start US — приблизно 11 000 годин перегляду в 1080p; за зростання аудиторії потрібен unmetered.