Виділені сервери для відеострімінгу та транскодування

Виділені сервери для потокового передавання та транскодування

Інфраструктура потокового відео має два окремі завдання: підготовка відеофайлів до відтворення та доставка цих файлів глядачам. Транскодування перетворює вхідні дані, такі як завантажене відео 4K H.264, RTMP-прямий ефір або потік із камери, на кілька роздільних здатностей і бітрейтів. Доставка передає HLS-плейлисти, маніфести MPEG-DASH, MP4-файли, мініатюри та сегменти глядачам через HTTP.

Виділений сервер цінний, оскільки відеонавантаження безперервно споживають ресурси. Одне погано оптимізоване програмне транскодування 4K у 1080p може використовувати кілька ядер CPU протягом усього часу виконання. Завантажений прямий канал може створювати нові HLS-сегменти кожні дві-шість секунд, тоді як сотні глядачів формують стабільний вихідний трафік. Bare-metal сервери забезпечують зарезервований час CPU, пряму продуктивність NVMe, передбачувану мережеву пропускну здатність і відсутність конкуренції за ресурси з боку інших віртуальних машин.

Типові потокові навантаження

• Відео на вимогу: завантаження користувачів кодуються у версії 1080p, 720p, 480p та варіанти, оптимізовані для мобільних пристроїв, для відтворення HLS або DASH.
• Прямі трансляції: вхідний потік RTMP, SRT або WebRTC пакується та транскодується в адаптивні HLS-потоки.
• Трансляції ігор, подій та навчання: регулярні прямі канали потребують стабільного приймання потоку, моніторингу, запису та сховища для повторного відтворення.
• Системи IP-камер: програмне забезпечення NVR може записувати RTSP-потоки, створювати попередні перегляди з низькою роздільною здатністю та зберігати записи протягом визначеного періоду.
• Медіаплатформи: самостійно розміщені відеопортали, навчальні бібліотеки, контент із платним доступом і внутрішні комунікаційні платформи потребують контрольованого сховища та правил доступу.

VPS порівняно з виділеним сервером

VPS достатньо для невеликої відеобібліотеки, одного прямого каналу з низьким трафіком, середовища розробки або легкого ремультиплексування. Почніть із VPS, якщо платформа переважно виконує пряму доставку файлів, зберігає менше 500 GB медіафайлів, має передбачуваний низький трафік і запускає не більше одного-двох нечастих програмних кодувань 1080p. Наприклад, VPS із 4 vCPU, 16 GB RAM і 240 GB NVMe може запускати Nginx, невеликий HLS-каталог і фонові завдання FFmpeg, якщо швидкість кодування обмежена.

Переходьте на виділене обладнання, коли транскодування є постійним, глядачів багато, важлива затримка прямого ефіру або платформа обробляє критично важливий для бізнесу контент. Виділені сервери особливо доречні для більш ніж трьох одночасних програмних транскодувань 1080p, кодування 4K, запису з кількох камер, понад 5 TB щомісячного вихідного трафіку або навантажень, які не можуть терпіти CPU-steal time. Вони також кращі для поштових сповіщень, баз даних, моніторингу та потокових сервісів, які мають співіснувати без конкуренції за обмежені ресурси віртуального CPU.

Кодування на GPU може суттєво збільшити щільність потоків, але воно змінює якість результату та операційну архітектуру. Апаратні кодувальники NVIDIA NVENC, Intel Quick Sync Video та AMD ефективні для ABR-ступенів прямих трансляцій і доставки великих обсягів контенту. Кодування на CPU за допомогою x264 або x265 зазвичай забезпечує кращу ефективність стиснення за заданого бітрейту, особливо для архівного відео на вимогу. Перевірте репрезентативні вихідні файли, перш ніж обирати кодек або апаратний кодувальник.

Планування потужностей: транскодування, сховище та пропускна здатність

Не визначайте параметри потокового сервера лише за кількістю глядачів. Вимоги до CPU та GPU насамперед залежать від кількості одночасних завдань транскодування, роздільної здатності джерела, кодека, частоти кадрів, цільового набору варіантів і пресету кодування. Вимоги до мережі залежать від глядачів і вибраних бітрейтів. Глядач HLS у 1080p, який дивиться варіант із бітрейтом 5 Mbps, використовує близько 2,25 GB за годину без урахування накладних витрат протоколу. Сто глядачів із бітрейтом 5 Mbps потребують приблизно 500 Mbps стабільної вихідної пропускної здатності.

Розрахунки сховища повинні включати вихідні файли, закодовані версії, HLS-сегменти, мініатюри, журнали та робочу область для FFmpeg. Одногодинне джерело 1080p із бітрейтом 8 Mbps займає близько 3,6 GB. Пакет адаптивного бітрейту з версіями 1080p, 720p і 480p може використовувати аналогічний або більший загальний обсяг сховища залежно від бітрейтів і кодеків. Залишайте щонайменше 20% ємності NVMe вільною, щоб тимчасові файли, метадані файлової системи та записи бази даних не сповільнювалися.

Для до двох одночасних програмних транскодувань 1080p може підійти VPS із 4 vCPU / 16 GB / 240 GB NVMe; для трьох-восьми завдань використовуйте виділений сервер із 8 ядрами / 32 GB / 480 GB NVMe, а для більших черг — 16 виділених ядер або сервер, обладнаний GPU.

Ці показники передбачають вхідні дані H.264 1080p і достатньо збалансовані пресети FFmpeg. HEVC, AV1, 4K, 60 fps, шумозаглушення, субтитри та кілька вихідних версій можуть різко збільшити час CPU. Для конвеєрів із підтримкою GPU перевірте обмеження сеансів GPU-кодувальника, доступну VRAM, підтримку кодеків і виміряну якість за цільового бітрейту.

Швидкий вибір

Шукаєте сервер, який просто працює?

Valebyte VPS — NVMe, підтримка 24/7, запуск за 60 секунд.

Тарифи VPS

Рекомендована архітектура сервера

Операційна система та базові сервіси

Використовуйте актуальний дистрибутив Linux із довгостроковою підтримкою, наприклад Debian 12 або Ubuntu 24.04 LTS. Розділіть потоковий стек на сервіси: Nginx обробляє HTTP-доставку, FFmpeg виконує кодування, система черг керує завданнями, PostgreSQL або MariaDB зберігає метадані, а моніторинг відстежує стан сервісів. Docker Compose підходить для невеликої інсталяції; служби systemd або Kubernetes можуть бути доречними для більших команд із налагодженим операційним досвідом.

Розміщуйте публічну HTTP-доставку за Nginx. Обмежте прямий доступ до кінцевих точок завантаження, використовуйте TLS-сертифікати та вимагайте підписані URL або автентифіковані сесії для приватного контенту. Для приймання прямих потоків відкривайте лише необхідні порти RTMP, SRT або WebRTC та обмежуйте облікові дані видавців. Не робіть адміністративні панелі або монтування сховищ загальнодоступними.

Пакування HLS і DASH

HLS має широку сумісність із браузерами, смарт-телевізорами та мобільними пристроями. Використовуйте короткі сегменти для скорочення часу запуску й відновлення, але не робіть сегменти надмірно короткими, оскільки створення сегментів додає навантаження на файлову систему та HTTP. Для більшості стандартних розгортань HLS практичними початковими значеннями є шестисекундні сегменти та плейлист, що містить від шести до десяти сегментів. HLS із низькою затримкою потребує іншого підходу до налаштування, зокрема часткових сегментів, сумісних плеєрів, більшої кількості HTTP-запитів і ретельного тестування продуктивності origin-сервера.

Для відео на вимогу кодуйте набір бітрейтів замість передачі одного надто великого файлу. Практичний набір H.264 може включати 1080p із 4,5–6 Mbps, 720p із 2,5–3,5 Mbps і 480p із 1–1,5 Mbps. Фактичні значення залежать від контенту: спорт, ігри та сцени з активним рухом потребують вищого бітрейту, ніж слайди, лекції чи відео з людиною в кадрі.

Покрокові рекомендації з розгортання

1. Підготуйте виділений сервер

Створіть адміністратора без root-доступу, встановіть оновлення та увімкніть брандмауер перед розгортанням застосунків. Використовуйте SSH-ключі, вимкніть автентифікацію за паролем після перевірки доступу за ключем і дозвольте лише порти, потрібні для SSH, HTTPS і вибраних протоколів приймання потоку.

sudo apt update && sudo apt -y upgrade && sudo apt install -y nginx ffmpeg ufw

2. Перевірте сховище та шляхи монтування

Використовуйте сховище NVMe для активних завантажень, HLS-сегментів, робочого простору транскодування та баз даних. Створіть окремі каталоги для вихідних завантажень, тимчасової роботи, опублікованих медіафайлів і резервних копій. Не зберігайте єдину копію завантажень клієнтів у тій самій файловій системі, що й тимчасові файли кодування.

sudo mkdir -p /srv/media/{uploads,work,hls,vod} && sudo chown -R www-data:www-data /srv/media

3. Створіть HLS-пакет з адаптивним бітрейтом

Перевірте репрезентативний вихідний файл перед автоматизацією завдань. Наведена нижче команда створює версії H.264 1080p, 720p і 480p з аудіо AAC та головним HLS-плейлистом. Використовуйте чергу завдань, щоб сервер не запускав більше кодувань, ніж дозволяє його бюджет CPU.

ffmpeg -i input.mp4 -filter_complex "[0:v]split=3[v1][v2][v3];[v1]scale=-2:1080[v1o];[v2]scale=-2:720[v2o];[v3]scale=-2:480[v3o]" -map "[v1o]" -map 0:a -c:v:0 libx264 -b:v:0 5500k -maxrate:v:0 6000k -bufsize:v:0 8250k -c:a aac -b:a 128k -map "[v2o]" -map 0:a -c:v:1 libx264 -b:v:1 3000k -maxrate:v:1 3300k -bufsize:v:1 4500k -c:a aac -b:a 128k -map "[v3o]" -map 0:a -c:v:2 libx264 -b:v:2 1200k -maxrate:v:2 1320k -bufsize:v:2 1800k -c:a aac -b:a 96k -f hls -hls_time 6 -hls_playlist_type vod -master_pl_name master.m3u8 -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" /srv/media/vod/stream_%v.m3u8

4. Налаштуйте Nginx для ефективної доставки

Встановіть правильні MIME-типи, дозвольте byte-range запити для доставки MP4 і задайте заголовки кешування, що відповідають контенту. Незмінні завершені сегменти можна кешувати довше, ніж плейлисти прямих трансляцій. Зберігайте коротке кешування плейлистів прямих трансляцій, щоб плеєри отримували актуальні посилання на сегменти.

sudo nginx -t && sudo systemctl reload nginx

5. Додайте HTTPS і контроль доступу

Використовуйте TLS для сторінок плеєра, API та медіакінцевих точок. Для приватних бібліотек створюйте короткострокові підписані URL у своєму застосунку замість відкриття передбачуваних шляхів до медіафайлів. Обмежуйте частоту запитів до кінцевих точок входу та завантаження, але уникайте надто агресивних обмежень на доставку сегментів, оскільки звичайний плеєр запитує багато малих файлів.

sudo certbot --nginx -d stream.example.com

6. Відстежуйте фактичне вузьке місце

Контролюйте навантаження CPU, пам'ять кожного процесу, затримку диска, вільний простір файлової системи, пропускну здатність мережі, HTTP-помилки та коди завершення FFmpeg. Середнє навантаження, близьке до кількості фізичних ядер CPU під час активного кодування, не є автоматично проблемою, але зростання черг кодування, високе очікування I/O, пропущені кадри прямої трансляції або буферизація в плеєрі є ознаками недостатньої потужності.

sudo apt install -y sysstat bmon && iostat -xz 1

Оптимізація продуктивності

• Використовуйте чергу з обмеженнями паралельності: зарезервуйте одне або два ядра CPU для Nginx, бази даних та операційної системи. Сервер із 8 ядрами зазвичай не повинен одночасно запускати вісім вимогливих завдань x264.
• Оберіть розумні пресети FFmpeg: повільніші пресети x264 покращують стиснення, але споживають більше CPU. Для прямого відео з критичною затримкою почніть із -preset veryfast або -preset faster; оцініть якість на реальному відеоматеріалі.
• Використовуйте CRF для цільової якості архівів: кодування CRF корисне для збереження джерел або підготовки VOD, тоді як обмежений бітрейт або налаштування, подібні до CBR, є передбачуванішими для прямих трансляцій.
• Зберігайте активні сегменти на NVMe: часті невеликі записи HLS погано підходять для повільних мережевих файлових систем або перевантажених SATA-дисків.
• Розділяйте origin і доставку в масштабі: коли вихідний трафік стає найбільшою витратою або вузьким місцем, зосередьте origin-сервер на прийманні та транскодуванні, використовуючи CDN або додаткові кеш-вузли для публічної доставки.
• Обережно використовуйте апаратне кодування: NVENC або Quick Sync можуть кодувати більше одночасних потоків на ват, але вимірюйте якість результату та переконайтеся, що вибраний GPU підтримує потрібні можливості H.264, HEVC, AV1, 10-bit або HDR.
• Оптимізуйте вирівнювання ключових кадрів: узгодьте розмір GOP із тривалістю сегмента. За 30 fps і шестисекундних сегментів почніть із GOP у 180 кадрів, щоб межі HLS-сегментів було легше розташовувати за ключовими кадрами.

Швидкий вибір

Шукаєте сервер, який просто працює?

Valebyte VPS — NVMe, підтримка 24/7, запуск за 60 секунд.

Тарифи VPS

Поширені помилки, яких слід уникати

• Купівля заради сховища з ігноруванням вихідного трафіку: сервер може мати достатньо дискового простору для тисяч відео, але вичерпати щомісячний трафік після популярної трансляції.
• Запуск необмеженої кількості процесів FFmpeg: це спричиняє насичення CPU, тиск на пам'ять, високе очікування дискового I/O, затримку генерації сегментів і буферизацію в плеєрі.
• Використання одного бітрейту для кожного глядача: відео лише з високим бітрейтом виключає користувачів мобільних пристроїв і слабких мереж; адаптивні набори бітрейтів зменшують буферизацію.
• Зберігання завантажень, робочих файлів і резервних копій разом: заповнений диск може зупинити активні транскодування та порушити операційні припущення. Використовуйте квоти, політики зберігання та резервні копії поза сервером.
• Надання незахищених шляхів до медіафайлів: приватний контент потребує автентифікації, авторизації та URL або токенів із терміном дії.
• Відмова від моніторингу: перевіряйте сповіщення про ємність диска, невдалі завдання, високі втрати пакетів, високу температуру CPU за наявності та невдале поновлення TLS.
• Припущення, що кожен кодек відтворюється всюди: перевірте цільові браузери, смарт-телевізори, мобільні застосунки та вбудовані плеєри перед розгортанням HEVC або AV1 як єдиного варіанту.

Вибір сервера Valebyte

Тарифні плани Valebyte VPS є розумною відправною точкою для невеликого HLS-сайту, тестового конвеєра або одного каналу з низьким обсягом трафіку. Оберіть виділений сервер Valebyte для постійного кодування на CPU, високих вимог до трафіку, чутливих медіабібліотек, багатоканальної прямої доставки або виробничої системи, де важливі передбачувані ресурси. Відштовхуйтеся від виміряної довжини черги, зростання сховища та вихідних Mbps, а не обирайте обладнання лише за розміром оригінальних відеофайлів.