Сколько зрителей выдержит стриминговый сервер с портом 10 Гбит/с?

Сервер на 10 Гбит/с при безопасной загрузке 80%, то есть 8 Гбит/с, может одновременно обслуживать около 1 000 зрителей потока 1080p с битрейтом 7,8 Мбит/с, 1 700 — при 720p, 470 — в 4K и 62 500 слушателей только аудио. Формула: зрители = полезная пропускная способность ÷ битрейт на зрителя, поэтому выбранный битрейт важнее, чем оборудование.

Коротко: сколько зрителей на 8 Гбит/с

Восемьдесят процентов порта 10 Гбит/с; каждый зритель получает один вариант видеопотока плюс стереозвук AAC 128 кбит/с:

Цифры Apple — это средние битрейты из её спецификации по подготовке HLS-контента. На уровнях H.264 начиная с 540p сохраняется исходная частота кадров, поэтому трансляция с частотой 60 кадр/с остаётся на 60 кадр/с; цифры для HEVC приведены для 30 кадр/с. Цифры YouTube — это то, что он просит отправлять ему энкодеры, а не то, что он отдаёт зрителям: они показывают, что происходит, когда сервер ретранслирует поток энкодера без изменений. Если пропускать поток 1080p60 как есть, с битрейтом 17 Мбит/с, аудитория сокращается более чем вдвое по сравнению с транскодированием в 7,8 Мбит/с.

Сколько зрителей выдержит сервер на 10 Гбит/с?

Зрители = полезная пропускная способность ÷ битрейт на зрителя. Ответ определяют три параметра:

• Полезная пропускная способность. Рассчитывайте примерно на 80% порта. Энкодеры превышают заданный битрейт: спецификация Apple допускает, что измеренный пиковый битрейт прямой трансляции достигает 125% от заявленного, а среднее значение за час — 110% от заявленного среднего. Сверх этого добавляются накладные расходы TCP/IP и HTTP.
• Битрейт на зрителя. Видео плюс аудио. YouTube рекомендует 128 кбит/с для стереозвука; у Apple диапазон для стерео AAC — от 32 до 160 кбит/с.
• Какой вариант потока смотрят зрители. При адаптивном битрейте телефоны и медленные подключения выбирают нижние уровни, поэтому реальное среднее значение ниже верхнего уровня. Расчёт по верхнему уровню — безопасное допущение.

Порт — это лишь половина пути. Каждому зрителю этот битрейт нужен на всём пути до экрана, а в любой сети аплинки за портом сервера общие. Перед крупной трансляцией проверьте реальные маршруты с помощью нашего руководства по тестированию скорости сети.

Пропускная способность для 1 000 зрителей

Умножьте битрейт на зрителя на 1 000: около 17 Гбит/с в 4K, 7,9 Гбит/с при 1080p с видео 7,8 Мбит/с, 4,6 Гбит/с при 720p, 1,2 Гбит/с при качестве класса 480p и 0,13 Гбит/с только для аудио. Тысяча зрителей 1080p загружает один порт 10 Гбит/с до отметки 80%; той же аудитории в 4K нужны три сервера.

Месячный трафик и сколько за него возьмёт CDN

Один зритель, который в течение часа смотрит поток 1 Мбит/с, потребляет 0,45 ГБ трафика: 1 Мбит/с × 3 600 с ÷ 8 бит в байте. Следовательно, месячный трафик = одновременные зрители × Мбит/с на зрителя × часы в день × 30 × 0,45 ГБ. Для 1 000 зрителей потока 7,93 Мбит/с по четыре часа в день: 1 000 × 7,93 × 4 × 30 × 0,45 = 428 000 ГБ, около 428 ТБ.

Цены по прайс-листу на октябрь 2026 г., без налогов и платы за запросы, из расчёта 1 ТБ = 1 000 ГБ. Amazon CloudFront берёт $0,085 за ГБ за первые 10 ТБ в месяц в США и Европе, далее цена по ступеням снижается до $0,04 в диапазоне от 150 до 500 ТБ и до $0,02 — свыше 5 ПБ. bunny.net в сети Standard берёт $0,01 за ГБ в Европе и Северной Америке ($0,03 — в Азии и Океании), а в сети Volume с 10 точками присутствия — $0,005 за ГБ за первые 500 ТБ, $0,004 — до 1 ПБ и $0,002 — до 2 ПБ.

Origin-сервер и edge-узлы в нескольких городах

При собственной доставке работа распределяется между серверами. Один origin-сервер принимает поток от энкодера по SRT или RTMP, транскодирует его в лестницу битрейтов и упаковывает в HLS. Edge-узлы в городах, где находятся ваши зрители, забирают каждый сегмент один раз и отдают его много раз. В документации SRS приведён расчёт: поток 1 Мбит/с для 1 000 зрителей, раздаваемый через edge-узлы NGINX, даёт 1 Гбит/с нагрузки на edge-узлы и лишь 1 Мбит/с на origin-сервер, а десяти edge-узлов по 10 Гбит/с каждый хватает для 100 000 зрителей при таком битрейте.

Наши серверы работают в Амстердаме, Франкфурте, Лондоне, Париже, Цюрихе, Нью-Йорке, Майами, Лос-Анджелесе, Сингапуре и Токио, и у каждого — собственный порт 10 Гбит/с без учёта трафика, поэтому edge-узел стоит одинаково, передаёт ли он 5 ТБ или 2 ПБ в месяц. При загрузке 80% один edge-узел обслуживает около 1 000 зрителей при 7,9 Мбит/с. В приведённом выше примере с 1 000 зрителями по четыре часа в день даже по тарифу сети Volume у bunny.net одна только доставка обходится примерно в $2 140 в месяц, тогда как origin-сервер за $159 и два edge-узла по $55 каждый стоят лишь малую долю этой суммы. Наш обзор цен на 10 Гбит/с без учёта трафика и руководство о том, как тарифицируется канал, объясняют, почему фиксированная плата за порт меняет расчёт.

В некоторых случаях CDN всё же выигрывает:

• Аудитория, рассеянная по всему миру. Одна только сеть Standard у bunny.net насчитывает 119 точек присутствия — против наших десяти городов.
• Непредсказуемые всплески, намного превышающие вашу обычную аудиторию. CDN их поглощает, а ваши собственные edge-узлы упираются в свои порты.
• Некому обслуживать серверы. Edge-узлы — это простые кэши, но кто-то должен устанавливать на них обновления, следить за ними и добавлять новые.

Можно и совмещать оба подхода: собственные edge-узлы — для постоянной аудитории, CDN — для пиковых излишков.

Транскодирование: пресеты x264 и x265 или NVENC

Транскодирование превращает один поток с высоким битрейтом в лестницу битрейтов, которая действительно нужна зрителям. На CPU энкодеры x264 и x265 позволяют выбирать баланс между скоростью и степенью сжатия с помощью пресетов — от самого быстрого к самому медленному: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow и placebo. Заголовочный файл самого x264 предупреждает, что «скорость этих пресетов различается кардинально»: ultrafast быстрее placebo в целых 100 раз. Кодирование прямой трансляции должно успевать за реальным временем на каждой ступени лестницы, поэтому для него используют быстрые пресеты; в собственном примере перекодирования от MediaMTX используется -preset ultrafast. Режим tune zerolatency в x265 идёт ещё дальше: он отключает B-кадры, lookahead и параллельную обработку кадров, чтобы сократить задержку энкодера. Сколько ступеней выдержит 16-ядерный CPU, зависит от пресета, разрешения и частоты кадров, поэтому перед трансляцией проверьте свою лестницу битрейтов на целевом сервере.

GPU переносит эту работу на специализированные энкодеры. У RTX PRO 4000 Blackwell два энкодера NVENC девятого поколения, два декодера NVDEC шестого поколения и 24 ГБ памяти GDDR7 с ECC при энергопотреблении не более 145 Вт. В матрице поддержки NVIDIA указаны кодирование в H.264, HEVC и AV1 и «неограниченное» (Unrestricted) число одновременных сессий, тогда как для GPU, не входящих в квалифицированный список NVIDIA, действует лимит в 8 сессий на систему. В документе NVENC Application Note NVIDIA приводит производительность Blackwell в расчёте на один энкодер при 1080p с настройкой на низкую задержку и постоянным битрейтом:

NVIDIA получила эти значения с Video Codec SDK 13.0 и указывает, что драйвер распределяет сессии между энкодерами чипа, поэтому с двумя NVENC эти цифры примерно удваиваются; это результаты бенчмарков NVIDIA, а не замеры на наших серверах. Лестнице нужна не только верхняя ступень: 720p, 540p, 432p и 234p вместе добавляют около 90% к числу пикселей кадра 1080p, поэтому закладывайте примерно два кодирования 1080p на канал, если считать, что производительность пропорциональна числу пикселей. По такой оценке одна карта выдерживает около пяти каналов с 60 кадр/с на пресете P5 и больше — на более быстрых пресетах.

Owncast, MediaMTX, SRS и nginx-rtmp

Аппаратному кодированию в Owncast нужен прямой доступ к GPU, что, согласно документации, исключено на общем VPS; выделенный GPU-сервер этому условию отвечает. Бакет объектного хранилища должен быть публичным, и в нём всегда хранятся только последние несколько минут трансляции. В документации MediaMTX отмечается, что без перекодирования — а именно так MediaMTX и работает — узким местом почти всегда оказывается пропускная способность между сервером и зрителями. Приведённые ниже примеры конфигурации взяты из документации соответствующих проектов.

В README nginx-rtmp RTMP-приложение превращается в HLS тремя директивами:

rtmp {
    server {
        listen 1935;
        application hls {
            live on;
            hls on;
            hls_path /tmp/hls;
        }
    }
}

MediaMTX по умолчанию отдаёт LL-HLS. Ниже — соответствующие строки из его стандартного mediamtx.yml; в комментариях к ним отмечено, что для корректной работы LL-HLS на устройствах Apple требуется HTTPS:

hls: true
hlsAddress: :8888
hlsVariant: lowLatency
hlsSegmentCount: 7
hlsSegmentDuration: 1s
hlsPartDuration: 200ms

Реплика MediaMTX для чтения в другом городе по запросу забирает с origin-сервера каждый путь (path):

paths:
  "~^(.+)$":
    source: rtsp://dns-of-origin:8554/$G1
    sourceOnDemand: yes

Для стандартного HLS руководство SRS по кластерам использует NGINX в качестве кэширующего edge-узла, который хранит плейлисты 10 секунд, а сегменты — 60 минут. На edge-узле в другом городе направьте proxy_pass на ваш origin-сервер вместо 127.0.0.1:

proxy_cache_path  /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;

server {
    listen       80;
    server_name your.domain.com;

    proxy_cache_valid  404      10s;
    proxy_cache_lock on;
    proxy_cache_lock_age 300s;
    proxy_cache_lock_timeout 300s;
    proxy_cache_min_uses 1;

    location ~ /.+/.*\.(m3u8)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri$args;
        proxy_cache_valid  200 302  10s;
    }
    location ~ /.+/.*\.(ts)$ {
        proxy_pass http://127.0.0.1:8080$request_uri;
        proxy_cache srs_cache;
        proxy_cache_key $scheme$proxy_host$uri;
        proxy_cache_valid  200 302  60m;
    }
}

HLS и LL-HLS вкратце

HLS разбивает поток на короткие медиасегменты, перечисленные в плейлистах, и всё это загружается по обычному HTTP — поэтому такой поток могут отдавать обычные веб-кэши. Спецификация Apple по подготовке контента требует ключевой кадр каждые две секунды, целевую длительность сегмента 6 с и вариант по умолчанию на 2 000 кбит/с; YouTube тоже рекомендует интервал между ключевыми кадрами 2 с и не более 4 с. Как отмечено в конфигурации MediaMTX, плееры обычно буферизуют около трёх сегментов перед началом воспроизведения, поэтому при 6-секундных сегментах зрители заметно отстают от прямого эфира.

Low-Latency HLS добавляет частичные сегменты (в примере Apple — длительностью 200 мс), дельта-обновления плейлистов, блокирующую перезагрузку плейлистов, подсказки предзагрузки (preload hints) и отчёты о вариантах (rendition reports). По словам Apple, это снижает задержку в публичных сетях «до уровня обычного телевизионного вещания». Загвоздка — в цепочке доставки: каждый промежуточный узел должен удерживать блокирующие запросы плейлистов и отвечать на них по мере появления новых частей, а кэш, который хранит плейлисты 10 секунд, как в примере с NGINX выше, сводит весь смысл на нет. Пропускайте стандартный HLS через простые кэши, а LL-HLS на всём пути доставки обслуживайте ПО, которое его реализует, например MediaMTX.

Масштабируемая схема: origin-сервер, edge-узлы и GPU

• Origin-сервер и упаковщик: Ryzen 9 9950X за $159 в месяц с 16 ядрами Zen 5, 128 ГБ DDR5 и двумя NVMe-накопителями по 1,92 ТБ — для приёма потока, упаковки в HLS и работы лестницы битрейтов на CPU, производительность которой вы измерили. Выдаётся примерно за 15 минут в Амстердаме, Франкфурте, Лондоне, Нью-Йорке, Майами, Лос-Анджелесе, Сингапуре и Токио.
• Edge-узлы: Ryzen 5 7600 за $55 в месяц с 6 ядрами, 32 ГБ памяти и двумя NVMe-накопителями по 512 ГБ. Кэш, который не перекодирует видео, упирается в порт, а не в процессор. Этот сервер доступен в восьми из десяти наших городов; в Токио используйте Ryzen 9 9950X, а в Цюрихе — Xeon E-2488 за $95.
• Транскодирование: сервер с RTX PRO 4000 Blackwell за $169 в месяц, который собирается в течение 24 часов в Амстердаме, Франкфурте или Нью-Йорке, — когда у вас несколько каналов, 4K, HEVC или AV1.

В каждый сервер входят порт 10 Гбит/с без учёта трафика и постоянно включённая защита от DDoS, поэтому счёт за edge-узел не меняется вместе с аудиторией. Другие схемы для прямых трансляций и видео по запросу — на нашей странице о стриминге и CDN. Это руководство предполагает, что вы транслируете собственный контент или мероприятия, на трансляцию которых у вас есть права.

Источники

• Выбор настроек энкодера, битрейта и разрешения для трансляций — Справка YouTube
• Спецификация по подготовке HTTP Live Streaming (HLS) для устройств Apple — Apple Developer
• Включение Low-Latency HTTP Live Streaming (HLS) — Apple Developer
• Прайс-лист AWS: Amazon CloudFront — Amazon Web Services, опубликован 3 октября 2026 г.
• Цены на CDN — bunny.net, проверено в октябре 2026 г.
• RTX PRO 4000 Blackwell — NVIDIA; Матрица поддержки кодирования и декодирования видео — NVIDIA Developer
• NVENC Application Note — NVIDIA Video Codec SDK 13.0
• x264.h — VideoLAN x264; Параметры пресетов — документация x265
• owncast/owncast, Аппаратное ускорение кодирования и кодеки, Выбор правильных настроек качества видео и Использование объектного хранилища для экономии трафика — Owncast
• bluenviron/mediamtx, mediamtx.yml, Масштабируемость и Перекодирование — MediaMTX
• Кластер HLS — документация SRS; ossrs/srs — GitHub
• arut/nginx-rtmp-module — GitHub