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

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

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

Выделенный сервер ценен, поскольку видеонагрузки непрерывно потребляют ресурсы. Одно плохо оптимизированное программное транскодирование 4K в 1080p может задействовать несколько ядер CPU на протяжении всей работы. Загруженный прямой канал может создавать новые сегменты HLS каждые две-шесть секунд, тогда как сотни зрителей формируют постоянный исходящий трафик. Bare-metal серверы предоставляют зарезервированное процессорное время, прямую производительность 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. Они также предпочтительны для почтовых уведомлений, баз данных, мониторинга и сервисов стриминга, которые должны сосуществовать без конкуренции за ограниченные ресурсы виртуального CPU.

Кодирование на GPU может существенно увеличить плотность потоков, но меняет качество вывода и операционную архитектуру. NVIDIA NVENC, Intel Quick Sync Video и аппаратные кодировщики AMD эффективны для лестниц live 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 широко совместим с браузерами, Smart TV и мобильными устройствами. Используйте короткие сегменты для уменьшения времени запуска и восстановления, но не делайте сегменты неоправданно короткими, поскольку создание сегментов увеличивает нагрузку на файловую систему и 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.
• Предположение, что каждый кодек воспроизводится везде: протестируйте целевые браузеры, Smart TV, мобильные приложения и встроенные плееры перед развертыванием HEVC или AV1 в качестве единственного варианта.

Выбор сервера Valebyte

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