Как создать платформу для видеостриминга: дерево решений основателя (2026)

Почему Фора Софт превратила квест «построй стриминговую платформу» в плейбук

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

Эта статья превращает квест в реальный плейбук. Мы разрабатываем платформы для видео- и аудиостриминга с 2005 года, с 100% рейтингом успеха на Upwork. Доказательства — в проде: Sprii (ведущая европейская платформа для лайв-шопинга, продаж на €365 млн+, 3 000+ брендов), Vodeo (iOS-приложение для стриминга со 100 000+ одновременных зрителей), BrainCert (WebRTC-LMS на тысячи одновременных учеников), TransLinguist (контракт с NHS-UK, 30 000+ переводчиков и 75+ языков) и Worldcast Live (HD-стриминг концертов для крупных мероприятий).

Ниже — дерево решений основателя, которое мы сами хотели бы иметь, когда начинали. Каждая глава — это выбор, который вам придётся сделать. Сделаете правильно — платформа запустится, вырастет и окупится. Сделаете неправильно — пополните список потерь.

Глава 1. Какой видеопродукт вы вообще строите?

Три категории закрывают 95% стриминговых продуктов, которые мы выпустили. Выберете не ту — и архитектура окажется неправильной.

Лайв «один ко многим». Концерты, киберспорт, лайв-шопинг, спорт, конференции. Один ведущий, тысячи или миллионы зрителей. Допустимая задержка: 2–8 с (LL-HLS, MoQ). Схема масштабирования: edge CDN.

Лайв «многие ко многим». Видеоконференции, телемедицина, виртуальные классы, суды, лайв-коммерция с интерактивом. Требуется задержка ниже 500 мс (WebRTC). Схема масштабирования: кластеры SFU.

VOD с социальными функциями. Формат YouTube. Видео, загружаемое пользователями, комментарии, рекомендации, монетизация. Допустимая задержка: часы (HLS). Схема масштабирования: хранилище + CDN + ML.

Глава 2. Выберите протокол реального времени

Не тот протокол — не тот продукт. В 2026 году выбирать, по сути, приходится из четырёх вариантов.

Подробнее по этой теме мы писали в гайде о том, как масштабировать видеостриминг в реальном времени до 1 миллиона зрителей. Отдельно про MoQ — в нашем разборе архитектуры приложений на MoQ.

Глава 3. SFU или MCU (или P2P)?

Для многостороннего видео в реальном времени есть три архитектуры.

P2P (peer-to-peer). До 4 участников. Каждый пир отправляет видео каждому другому пиру. Серверных расходов нет — но пропускная способность и нагрузка на CPU на устройстве пользователя резко растут, как только участников становится больше 4.

SFU (Selective Forwarding Unit). Комфортно 5–50 участников; 100+ — при использовании simulcast и грамотной оркестрации. Сервер форвардит закодированные потоки — никакого транскодинга. Это дефолт 2026 года практически для любого многостороннего видеопродукта. LiveKit, MediaSoup, Janus, Pion, Jitsi.

MCU (Multipoint Control Unit). Сервер транскодирует все потоки в единую композицию. Полезно для старых клиентов или зрителей с узким каналом, но стоимость вычислений на сессию в 5–10 раз выше, чем у SFU. В 2026 году — нишевая история.

Глава 4. Ловушка стоимости, в которую попадает большинство основателей

CDN-эгресс — главный сюрприз по затратам для основателей, впервые делающих видеопродукт. CloudFront, Akamai и Fastly берут 3–7 ₽ за ГБ; один зритель, который час смотрит поток 1080p на 5 Мбит/с, потребляет ~2,25 ГБ — это 8–17 ₽ за зритель-час только за эгресс.

Три приёма резко сокращают эти расходы.

1. Перейдите на H.265 или AV1. Экономия битрейта 30–50% при том же воспринимаемом качестве по сравнению с H.264. Счёт за CDN падает пропорционально.

2. Используйте бюджетных CDN-провайдеров. Bunny, Gcore и Cloudflare на 30–70% дешевле AWS CloudFront по «голому» эгрессу. CDN второго эшелона с гео-фолбэком часто работает лучше «брендовых» CDN первого эшелона при доле их стоимости.

3. По-настоящему адаптивный битрейт. Многие MVP запускаются с верхней ступенью битрейтной лесенки в качестве дефолта. Настройте лесенку так, чтобы по умолчанию 60% зрителей отдавалось 720p, а выше — только при подтверждённой пропускной способности.

Глава 5. Где запускать SFU и кодировщики?

В 2026 году жизнеспособны три модели хостинга.

Bare metal в Hetzner. Самый экономный дефолт для SFU, обслуживающих 100+ одновременных комнат. Машины серий AX и EX стоят 3 750–15 000 ₽/мес и тянут по 50–200 одновременных SFU-сессий каждая. Типовое горизонтальное масштабирование — 10 000+ одновременных зрителей на 5–15 машинах.

Управляемое облако (AWS, GCP, DigitalOcean). Проще в эксплуатации, в 3–5 раз дороже. Берите это, если у вас минимальные ресурсы SRE или вы масштабируетесь вверх-вниз быстрее, чем Hetzner успевает подстраиваться.

Управляемые видеоплатформы (Agora, 100ms, LiveKit Cloud). Самый быстрый путь к MVP. Поминутный тариф обычно сравнивается по цене с self-hosted на отметке ~10 000 ежемесячно активных пользователей; выше — self-hosted выигрывает в 5–10 раз.

Глава 6. Как платформа будет зарабатывать?

Доминируют пять моделей монетизации. Большинство успешных платформ комбинируют две-три.

Подписка (SVOD). Модель Netflix. Высокая пожизненная ценность клиента, предсказуемая выручка. Тяжело раскачать без сильного контента или комьюнити.

Оплата за просмотр (TVOD). Концерты, спорт, премиальные события. Выручка идёт всплесками. Worldcast Live — хороший пример TVOD в масштабе.

Реклама (AVOD). YouTube, Twitch. Меньшая выручка с одного зрителя, но неограниченный охват. Требует приличного масштаба, чтобы это имело значение (> 100 000 MAU).

Лайв-коммерция. Sprii запускает это в масштабе: стримеры продают прямо во время прямых эфиров, платформа берёт процент. Самая высокая юнит-экономика среди стриминговых продуктов 2026 года.

B2B / SaaS. White-label-стриминг для корпоративных клиентов. Тариф за место или за поток. Самая высокая валовая маржа, самый длинный цикл продаж.

Глава 7. Модерация решает всё

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

Три слоя, которые мы всегда строим.

1. AI-скрининг в реальном времени — на видео, аудио и чате, на наготу, оружие, язык вражды и PII. Лёгкие ONNX-модели прямо на краевом узле SFU.

2. Дашборд оператора с поставкой на паузу, киком, баном и репортом в один клик. Аудит-логи по каждому действию. SLA на время реакции по критическим репортам (целевой показатель — менее 5 минут).

3. Пользовательские репорты проще, чем встроенная камера в приложении. Главный враг — трение: если, чтобы пожаловаться на стрим, нужно сделать больше трёх тапов, никто этого делать не будет.

Глава 8. Ловушка MVP

Лайв-стриминговый MVP на 100–500 зрителей с чатом и базовой монетизацией собирается за 8–12 недель с правильной командой. Каждая дополнительная функция удваивает сроки. Три правила, которые пережили столкновение с реальностью на наших последних 20 проектах.

1. Не стройте v2 непроверенного продукта. Мультистриминг на YouTube и Twitch на четвёртой неделе — признак того, что вы решаете задачу, которой у вас ещё нет.

2. Берите скучную инфраструктуру. Postgres, Redis, S3-совместимое хранилище, SFU, исходники которого вы можете прочитать. Скучное масштабируется, модное — нет.

3. Откладывайте транскодинг-пайплайны. Адаптивные битрейтные лесенки, AV1, HDR, режим сверхнизкой задержки — всё это реальные проблемы в масштабе, и все они откладываются на v2. MVP запускается в одном разрешении, одном битрейте и одном кодеке.

Глава 9. Референсный стек 2026, который мы постоянно деплоим

Когда у нас полная архитектурная свобода, стек, к которому мы сходимся для новых лайв-видеопродуктов в 2026 году, выглядит так.

Слой реального времени. LiveKit или MediaSoup в качестве SFU; Janus или Pion, если у команды предпочтения по Go. WebRTC — для задержки ниже 500 мс; LL-HLS или MoQ — для масштабируемой схемы «один ко многим».

Бэкенд. Node.js или Go для API; Postgres — основные данные; Redis — эфемерное состояние и rate limiting; ClickHouse или BigQuery — аналитика.

Фронтенд. React или React Native (мобайл); SDK от LiveKit или Mediasoup-client; Tailwind для стилей; Tanstack Query для состояния.

Хостинг. Bare metal в Hetzner — для SFU и кодировщиков; AWS или GCP — для управляемых сервисов (RDS, S3, IAM); Cloudflare или Bunny — для CDN.

AI / ML. ONNX-рантайм — для моделей модерации; OpenAI или Anthropic — для транскрибации, суммаризации, обогащения модерации; Whisper — для ASR на собственных мощностях.

Мини-кейс: от идеи до платформы на 100 000 зрителей за 14 недель

Ситуация. Основатель пришёл к нам с идеей стриминга концертов: артисты выходят в эфир, зрители платят за каждое шоу, платформа берёт долю. Кода нет, прототип во Figma и сроки, привязанные к туру артиста, который начинался через 4 месяца.

План. 14 недель. Недели 1–2: фиксируем архитектуру, выбираем LiveKit + Hetzner + Bunny CDN, делаем регистрацию и тикетинг. Недели 3–6: live-ingest, LL-HLS-плейбэк, пейволл, базовая модерация. Недели 7–10: чат, платежи, чаевые, мобильное приложение. Недели 11–13: нагрузочное тестирование на 50 000, затем 100 000 одновременных зрителей. Неделя 14: продакшен-запуск с открывающим концертом артиста.

Результат. Платформа запустилась вовремя. Пик открывающего шоу — 47 000 одновременных зрителей; система выдержала. Затраты уложились ниже бюджета — ≈ 3 ₽ за зритель-час. Через 2 месяца основатель добавил ещё двух артистов, а на 4-й месяц — B2B-тариф под white-label.

Пять ловушек, которые мы постоянно видим в первых стриминговых продуктах

1. Шок от стоимости CDN-эгресса. Основатели прогнозируют выручку, но не пропускную способность. Каждая 1 000 зритель-часов 1080p — это ≈ 7 500 ₽ эгресса на AWS и ≈ 2 250 ₽ на Bunny.

2. Неправильный протокол под задачу. Строить телемедицину на HLS — гарантия раздражённых пациентов. Строить лайв-шопинг на WebRTC при большом зрительском масштабе — гарантия неконтролируемых счетов за хостинг.

3. Откладывание модерации до кризиса. Планируйте модерацию на первой неделе, а не на шестом месяце. Дашборд оператора, AI-скрининг и пользовательские репорты должны уезжать в прод вместе с MVP.

4. Чат раньше стабильного видео. Масштабирование чата — отдельный зверь: Redis, fan-out, присутствие. Не лезьте в эту битву, пока видео ещё нестабильно.

5. Нанимать одиночек на слой реального времени. WebRTC и SFU — это крутая кривая обучения. Один сеньор с опытом запуска в проде стоит троих миддлов, которые «по ходу разберутся».

Фреймворк решений: выберите стартовый стек за пять вопросов

В1. Какая у вас допустимая задержка? < 500 мс — WebRTC. 1–5 с — LL-HLS или MoQ. > 10 с — HLS / DASH.

В2. Сколько активных говорящих участников в сессии одновременно? 1 — «один ко многим» (LL-HLS). 2–100 — SFU. 100+ — SFU + simulcast + грамотная оркестрация.

В3. На сколько хватит денег? < 6 месяцев — управляемая видеоплатформа (Agora, 100ms). 6–18 месяцев — гибрид: managed на v1, миграция на self-hosted для v2. > 18 месяцев — self-hosted с первого дня.

В4. Какая модель монетизации? Подписка / TVOD — сначала тикетинг и пейволл. AVOD — рекламный SDK и зрительский масштаб. Лайв-коммерция — интеграция корзины, платежи, чаевые.

В5. Строить в одиночку или с партнёром? Соло-основателям — в паре с опытным агентством на слой реального времени. Профинансированный стартап — сеньор-инженер плюс агентство под пиковую нагрузку. Энтерпрайз — полноценная внутренняя команда.

KPI, которые надо отслеживать после запуска

KPI качества. Время старта потока (цель < 3 с); доля ребуферизации (цель < 0,5%); видеобитрейт по P50 (отслеживайте, с какой ступени реально отдаёт зритель); оценка MOS по аудио в многосторонних звонках (цель > 3,8).

Бизнес-KPI. Стоимость зритель-часа (цель < 3,7 ₽ в масштабе); ARPU; конверсия из бесплатных в платные; посещаемость лайв-шоу против повторов; дневные и месячные активные пользователи.

KPI надёжности. Доступность каждого сервиса (цель > 99,9%); загрузка CPU SFU-пода на пике (ниже 70%); cache hit ratio CDN (> 90%); время реакции на инцидент по P50 (< 15 минут от алерта до триажа).

Когда НЕ стоит делать платформу видеостриминга на заказ

Три сценария, в которых мы советуем основателям ехать на чужой инфраструктуре.

Вам не нужен реальный масштаб времени. Если ваш продукт работает на YouTube-эмбедах или Vimeo — запускайтесь там. Проверьте спрос. Стройте инфраструктуру, когда из такой схемы вырастете.

Вы контентный бизнес, а не технологический. Vimeo OTT, Mux и Daily.co отлично подходят для медиакомпаний, чьё преимущество — контент, а не плеер.

У команды нулевой опыт в реальном времени. Видео в реальном времени — отдельная специализация. Трёхмесячная задержка с запуском не того, что нужно, обычно стоит дороже, чем стоимость работ агентства.

Как бенчмаркать платформу перед запуском

Маркетинговые демо лгут за счёт подбора сцен. Соберите нагрузочный стенд, который бьёт по системе в 5 раз сильнее вашего прогноза на пике, и гоняйте его час. Замерьте четыре вещи.

Одновременная ёмкость. Где ломается SFU? Где ломается CDN? Где ломается база данных?

Среднее время старта потока в масштабе. Время холодного старта взлетает, когда 1 000 зрителей одновременно нажимают «play». Замеряйте P50, P95, P99.

Восстановление после хаоса. Убейте узел. Внесите 5% потерь пакетов. Отбросьте 30% зрителей и пересоедините их. Система восстанавливается или захлёбывается?

FAQ

Сколько времени занимает создание платформы видеостриминга с нуля?

Лайв-стриминговый MVP на 100–500 зрителей с чатом и базовой монетизацией собирается за 8–12 недель — при наличии правильной команды. Полнофункциональная платформа, обслуживающая 10 000+ одновременных зрителей, мультитенантные функции и полноценную модерацию, требует 14–26 недель. Worldcast Live и Vodeo были выпущены именно в диапазоне 14–26 недель.

Сколько стоит разработка платформы видеостриминга на заказ?

MVP обходится в 4,5–13 млн ₽ с сфокусированной командой. Масштабированный v1 с мобильными приложениями, монетизацией, модерацией и аналитикой — обычно 15–45 млн ₽. Полнофункциональные платформы под 100 000+ одновременных зрителей и сложную монетизацию выходят в 37–112 млн ₽. Эксплуатационные расходы — в диапазоне 1,5–3 ₽ за зритель-час при self-hosted-связке Hetzner + бюджетный CDN. С Agent Engineering мы регулярно работаем по нижней границе этих диапазонов.

Использовать управляемую платформу вроде Agora или строить собственный SFU?

Управляемые платформы (Agora, 100ms, LiveKit Cloud) — самый быстрый путь к MVP, и по цене они сравниваются с self-hosted примерно на 10 000 ежемесячно активных пользователей. Выше этой отметки self-hosted на Hetzner с LiveKit, MediaSoup или Janus обычно выигрывает по TCO в 5–10 раз. Гибридный путь — managed на v1, миграция на self-hosted для v2 — то, что мы рекомендуем чаще всего.

WebRTC или HLS — что выбрать?

WebRTC — для любого продукта, где зрителям нужна задержка ниже 500 мс: конференции, телемедицина, лайв-коммерция с интерактивом. LL-HLS или MoQ — для лайв-стриминга «один ко многим» на больших аудиториях (спорт, киберспорт, концерты). HLS или DASH — для VOD и классического вещания. Несоответствие — самая частая ошибка основателей.

Как удержать затраты на CDN под контролем?

Три приёма: перейдите на H.265 или AV1 ради 30–50% экономии битрейта; используйте бюджетных CDN-провайдеров (Bunny, Gcore, Cloudflare) вместо AWS CloudFront; настройте адаптивную битрейтную лесенку так, чтобы по умолчанию большинство зрителей отдавалось с 720p и поднималось выше только при подтверждённой пропускной способности. Вместе это обычно срезает расходы на CDN на 40–70%.

Нужна ли модерация контента с первого дня?

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

В чём разница между SFU и MCU?

SFU форвардит закодированные потоки без транскодинга; стоимость растёт линейно с числом участников и драматически ниже, чем у MCU. MCU транскодирует все потоки в единую композицию — полезно для зрителей с узким каналом или для устаревших клиентов, но в 5–10 раз дороже на сессию. SFU — дефолт практически для любого многостороннего видеопродукта в 2026 году.

Можно ли в одиночку построить платформу видеостриминга, не будучи технарём?

Реалистично — нет, не кастомную. У слоя реального времени крутая кривая обучения и беспощадные условия в проде. Не-технарям лучше всего либо (а) стартовать на управляемой платформе вроде Mux или Daily.co, либо (б) брать в партнёры агентство, которое уже запустило несколько стриминговых продуктов. Мы работали с не-технарями 50+ раз — схема хорошо обкатана.

Что почитать дальше

Готовы сыграть основателя по-настоящему?

Текстовая квест-игра была весёлым способом почувствовать дерево решений при создании стриминговой платформы. Главы выше — её настоящая версия. Если правильно выбрать протокол, тип SFU, политику модерации, модель затрат и партнёра — дальше всё превращается в 14-недельный спринт разработки с готовым продуктом на выходе.

Если вам нужна проверка на здравый смысл по выбранному пути — или 14-недельный план запуска MVP — мы сделаем эту работу вместе с вами. Двадцать лет мультимедийной инженерии, 100% рейтинг успеха на Upwork, Agent Engineering для ускоренной доставки. Приносите идею — мы принесём архитектуру.

Бонус: какая команда реально нужна, чтобы выпустить стриминговый MVP

Сфокусированный MVP на 8–12 недель тянет небольшая команда:

1. Сеньор-бэкендер с опытом работы с WebRTC или LL-HLS — это ключевой найм, от которого зависит всё.

2. Фронтенд- или мобильный инженер, который уже выпускал видеопродукты.

3. QA-инженер с реальным стендом из устройств (с шейпингом сети и симуляцией потерь пакетов).

4. Продакт-менеджер на полставки или основатель, который отвечает на вопросы по компромиссам менее чем за 24 часа.

5. DevOps-инженер на полставки — для SFU-кластера и наблюдаемости.