Edge-вычисления в прямом эфире: как уменьшить задержку, сэкономить и масштабироваться без проблем

Почему Фора Софт написала это руководство по edge-стримингу

Фора Софт занимается продуктами для видеостриминга с 2005 года. Мы создавали решения WebRTC поверх edge, такие как Alve Live — платформа для прямого эфира в индустрии развлечений, обучающие платформы на LL-HLS — BrainCert и Scholarly, а также гибридные системы SFU+CDN для онлайн-обучения, например Career Point. Наши команды LiveKit и Twilio используют edge-развёртывания для клиентов более чем в 40 странах.

Это руководство — то, чего нам самим не хватало, когда мы впервые спорили: «развернуть LiveKit на edge самим» или «достаточно ли Cloudflare Stream». Внутри — четыре актуальные архитектуры 2026 года, цены у вендоров, которые мы согласовываем каждый день, реальные цифры сквозной задержки, которые измеряем сами, и тихие сценарии сбоев, способные незаметно сжечь бюджет на стриминг.

Рынок live-стриминга в 2026 году — и почему edge стал базовым требованием

Мировой рынок live-стриминга в 2026 году оценён в 157,4 млрд долларов, к 2035 году ожидается рост до 1,025 трлн (CAGR 22,8%). Около 46% капитальных затрат платформ идёт на развитие инфраструктуры и снижение задержки. Примерно половину глобального роста обеспечивает регион Азиатско-Тихоокеанского региона — поэтому любая серьёзная платформа обязана обеспечивать субсекундную задержку для зрителей из APAC через локальные POP’ы.

Из одного региона такой опыт не выдать. Round-trip между Франкфуртом и Сиднеем в хорошей сети — уже 260–320 мс, и весь бюджет задержки WebRTC уходит только на сетевую часть. Для LL-HTTP Live Streaming (LL- HLS) единственный централизованный origin не справится с фан-аутом на 10 000+ одновременных зрителей без edge-слоя CDN. Edge — это не опция оптимизации, а базовая планка.

Экономика усиливает этот сдвиг. Egress стал главной статьёй расходов в облачном счёте стримингового оператора. По нашим аудитам, CDN-egress в среднем составляет 30–50% всех затрат на эксплуатацию стриминга. Платформа, транслирующая двухчасовое мероприятие для миллиона одновременных зрителей, может потратить на egress 9–13,5 млн ₽. Перенос транскодирования и кэширования на edge обычно позволяет сэкономить 60–85% этих средств.

Четыре уровня задержки, определяющие выбор архитектуры

Любое архитектурное решение ниже по цепочке вытекает из одного вопроса: какая сквозная задержка «от камеры до экрана» нужна вашему продукту? К 2026 году индустрия утвердилась на четырёх уровнях.

Большинству приложений, которые мы разрабатываем, нужно одновременно два или три уровня. Спортивному приложению — интерактивный (комментаторские микрофоны, реакции на ставки в ходе матча), околореальный (основной поток) и VOD (повторы). Обучающей платформе — интерактивный (репетиторство), стандартное вещание (лекции для тысяч слушателей) и VOD (библиотека курсов). Одна архитектура редко покрывает всё; гибридная — всегда справляется.

Четыре архитектуры стриминга на edge, которые стоит знать

За каждым live-стриминговым продуктом 2026 года стоят, по сути, четыре архитектуры. Большинство продакшен-систем используют их комбинацию.

1. Централизованный origin + CDN (легаси)

Один-два origin-сервера кодируют и упаковывают видео, CDN (Akamai, Fastly, CloudFront) кэширует сегменты на edge. От камеры до экрана — 20–40 секунд. Самый простой способ, и для отдельных вещательных сценариев пока подходит, но для прямых трансляций всё чаще становится неприемлемым. Используйте только в тех случаях, когда задержка не важна.

2. Edge CDN с LL- HLS / CMAF (современное вещание)

Origin или региональный пакетировщик выдаёт CMAF-чанки длиной 200 мс–1 с. Edge-POP’ы кэшируют и раздают LL- HLS или LL-DASH напрямую. Cloudflare Stream, Bunny Stream, Mux, AWS IVS работают по такому же принципу. От камеры до экрана — 2–5 секунд. Это стандарт 2026 года для любых мероприятий, где не требуется интерактивность с задержкой менее секунды.

3. Edge SFU для WebRTC (интерактив)

SFU (Selective Forwarding Units) развёрнуты в десятках региональных POP’ов. Издатели отправляют поток на ближайший SFU; зрители подключаются к ближайшему SFU; SFU’ы соединены между собой в mesh-сеть для передачи трафика между регионами. Задержка от камеры до экрана — 150–400 мс. LiveKit Cloud, Twilio Video, Daily.co, 100ms, Agora SD-RTN, Vonage. Это единственный разумный выбор для интерактивных продуктов.

4. Гибрид SFU → CDN (масштабируемый интерактив)

Небольшая группа активных участников (5–500) подключена к edge- SFU. Собранный SFU-поток упаковывается в LL- HLS и через CDN доставляется миллионам зрителей. Именно так масштабируются Twitch, приложения в стиле Clubhouse и платформы для прямых продаж — когда экономика чистого SFU становится невыгодной. К концу второго года к этому шаблону приходит любой серьёзный стриминговый сервис.

Ландшафт вендоров и цены 2026 года

Публичные цены обновляются раз в квартал; ниже — цифры, которые мы подтвердили в апреле 2026 года, пообщавшись напрямую с каждым вендором. На больших объёмах всегда запрашивайте индивидуальное коммерческое предложение.

Edge WebRTC SFU

Edge HLS / DASH CDN

Бессерверные вычисления на границе сети для обработки стриминговой логики

На них живёт обвязка, которая реально нужна стриминговому продукту: подпись токенов для DRM, аутентификация, фан-аут чата, WebSocket-комнаты, сбор аналитики в реальном времени, гео-маршрутизация.

Cloudflare Workers (около 22 ₽ за миллион запросов, холодный старт — 5 мс) — наш основной выбор: низкая задержка при старте критически важна для задач, где важно уложиться в лимит задержки WebRTC. Fastly Compute@Edge (около 37 ₽ за миллион запросов, холодный старт — 10 мс) лучше подходит, если рядом со стримингом нужны WASM или кастомный VCL. AWS Lambda@Edge мощнее, но холодные старты в 50–200 мс могут полностью «съесть» допустимый бюджет задержки — используйте его только для асинхронных задач (аналитика, подготовка ресурсов). Vercel Edge и Deno Deploy — отличный вариант, если вы хотите приоритет JavaScript в разработке.

Куда реально уходят миллисекунды — разбор задержки

Понять, где накапливается задержка, — самый быстрый способ определить, что оптимизировать. Для типичного интерактивного WebRTC-звонка между Берлином и Сан-Паулу (RTT ~220 мс) бюджет распределяется примерно так:

Захват с камеры и локальное кодирование: 20–40 мс. Аплинк от клиента до SFU: 40–80 мс. Обработка на SFU (выборочная пересылка, без транскода): 2–5 мс. Mesh между SFU разных регионов: 80–160 мс. Даунлинк от SFU до зрителя: 40–80 мс. Декодирование и вывод на экран у зрителя: 20–40 мс. Итого: 200–400 мс от камеры до экрана.

Если на SFU добавить транскодирование (например, симулякаст в один поток для зрителей с узким каналом), задержка увеличится ещё на 150–300 мс. Если добавить упаковку из WebRTC в HLS — ещё на 1–3 секунды. Каждый дополнительный слой увеличивает задержку. Чтобы удерживать сквозную задержку ниже 400 мс для глобальной аудитории, остаётся только один способ: использовать чистый пайплайн WebRTC через географически близкие SFU.

ИИ-инференс на edge для стриминга (2026)

Edge-узлы вычислений сегодня обычно оснащаются GPU- или NPU-ускорителями. Cloudflare Workers AI, Fastly AI, edge-зоны AWS Inferentia, POP’ы с поддержкой NVIDIA Holoscan делают реальное время работы ИИ для стриминга доступным по бюджету. Шаблоны, которые мы чаще всего запускаем в продакшене:

Субтитры и перевод в реальном времени. Аудио обрабатывается внутри SFU, передаётся в локальную модель распознавания речи в этом POP’е (Deepgram Nova-3, Whisper.cpp или Cloudflare Workers AI whisper), переводится и выводится как текстовый трек. Дополнительная задержка — 200–500 мс; стоимость — около 0,5 ₽ за минуту на каждый язык.

Модерация контента на ингесте. Классификаторы NSFW / CSAM проверяют входящие кадры на edge до того, как поток попадёт к зрителям. Это снижает юридические риски и обходится недорого, потому что каждый кадр анализируется только один раз.

Размытие фона / виртуальная камера / автокадрирование. Сегментация работает бесплатно на устройстве издателя; перекадрирование и композиция могут выполняться на SFU, если нужен единый визуальный стиль для всех клиентов.

Рекомендации и аналитика вовлечённости в реальном времени. Это уже продуктовые сценарии с использованием ИИ — от персональной ленты до прогнозирования удержания.

Матрица решений: какая архитектура подойдёт вашей нагрузке

Сколько реально стоит edge-стриминг на 100 тыс. зрительских минут в месяц

Ниже — реалистичное сравнение цен на 2026 год для платформы, которая обеспечивает 100 000 одновременных зрительских минут в месяц (например, 500 зрителей × 200 минут × 1 мероприятие). Цифры — итоговая сумма от поставщика при одинаковом контенте и качестве.

Гибридный стек стабильно в 5–10 раз дешевле чистого AWS IVS при том же качестве пользовательского опыта. Инженерные затраты — около 1,1–1,8 млн ₽ на первоначальную интеграцию и настройку наблюдаемости — окупаются уже в первый полноценный месяц.

Когда edge действительно окупается (а когда нет)

У edge-архитектур есть реальные эксплуатационные издержки: отладка мультирегиональных сценариев сложнее, наблюдаемость требует продуманного дизайна, отдельные вендоры создают зависимость. Не переходите на edge, если можно обойтись без него.

Идите на edge, если всё ниже про вас

Аудитория охватывает более трёх континентов. Продукт требует интерактивности или задержки менее 5 секунд. Ежемесячный трафик на выходе превышает 375 тыс. ₽. В продукте реализованы live-чат, реакции или взаимодействие зрителей со сценой. Вы готовы потратить 8–12 недель работы senior-инженеров и от 1,1 млн ₽ на стартовую инфраструктуру.

Не ходите на edge, если хотя бы одно из этого — про вас

Аудитория одного региона (только США, только ЕС). Продукт — в основном VOD (это естественно решается edge-кэшированием на любом CDN). Одновременных зрителей меньше ~500. Аудитория использует только Safari, где нет WebTransport. Бюджет ограничен, в команде меньше трёх инженеров. В таких случаях начните с Mux или Cloudflare Stream и переходите на другую платформу, когда это станет необходимо из-за роста.

Мини-кейс: как мы сократили время запуска потока вдвое для глобальной фитнес-платформы

Клиент — фитнес-стриминговый сервис с живыми классами в США, Европе и Азиатско-Тихоокеанском регионе. Среднее время запуска потока — 6,8 секунды, 14% зрителей уходят до появления первого кадра. Архитектура: один origin-сервер в US-Востоке и глобальный CDN на LL-HLS. Пробовали использовать мощные origin-серверы, но это дало лишь незначительное улучшение.

Мы заменили её гибридной схемой: инструкторы транслируют поток на ближайший SFU в LiveKit Cloud (edge), а выходной поток SFU кодируется Cloudflare Stream в ближайшем POP. Зрители получают видео по протоколу LL-HTTP Live Streaming с ближайшего edge Cloudflare. Cloudflare Workers подписывают токены и обрабатывают рассылку сообщений чата в рамках стрима. Все изменения реализовали за 6 инженерных недель.

Результаты на 90-дневном горизонте: время запуска потока снизилось до 2,9 с по глобальному P95 (2,3 с в США, 3,1 с в ЕС, 3,8 с в APAC). Отток до первого кадра упал до 5,1%. Месячный счёт за CDN-egress сократился на 41% — транскодирование на edge уменьшило общий объём передаваемых данных. Доля пользователей, дошедших до конца занятия, выросла на 12 процентных пунктов.

Шаблон воспроизводимый. Мы используем его на Career Point, Scholarly и других мультиконтинентальных стриминговых продуктах.

Чек-лист внедрения: как запустить edge-пайплайн стриминга

Сначала выберите топологию пайплайна

Сопоставьте каждому типу участника (издатель, со-ведущий, пассивный зритель) свой протокол передачи. По умолчанию: издатели и со-ведущие используют WebRTC SFU, пассивные зрители — LL-HTTP через CDN при ~500+ одновременных подключениях.

Заложите ICE и STUN/TURN с учётом реальных условий на edge

Поднимайте TURN-серверы в тех же регионах, где находятся SFU. Учитывайте, что 8–15% сессий потребуют использования TURN-релеев (из-за симметричного NAT или корпоративных фаерволов). Используйте Cloudflare TURN, Xirsys или собственный coturn, размещённый рядом с узлами LiveKit.

Запускайте полную наблюдаемость с первого дня

P50/Р95/Р99 сквозной задержки по регионам. Доля успешных подключений, частота ребуферизации, время до первого кадра. Количество вызовов edge-воркеров и бюджет ошибок. Заведите всё это в Grafana или Datadog с тегами по POP’ам. Это решает классическую проблему: «в три часа ночи в APAC что-то тормозит».

Прогоняйте сквозные тесты с трёх континентов

Запустите синтетических агентов как минимум в США, ЕС и APAC, которые будут круглосуточно тестировать рабочий пайплайн. Настройте оповещения о дрейфе задержек в каждом регионе. Сети меняются — ваш пайплайн должен замечать это раньше пользователей.

Закладывайте плавный переход между несколькими CDN

Даже крупные CDN могут падать. Подключите второй CDN как резерв (например, Bunny рядом с Cloudflare или наоборот) с переключением через DNS по регионам или через манифест. Это добавит около 5% сложности в настройку, но полностью устранит риск при сбое одного CDN.

Наблюдаемость и SLO: control plane, который нужно построить для edge-стриминга

Edge-стриминг ломается так, как однорегиональная платформа никогда не ломалась: конкретный POP начинает маршрутизировать неправильно, один оператор связи в Джакарте даёт сбой, в Сан-Паулу холодный кэш замедляет время до первого кадра. Без детальной телеметрии вы узнаёте об этих сбоях из соцсетей. А с правильным стеком наблюдаемости — ловите их за минуты и подставляете нужного вендора CDN до того, как уйдёт 1% зрителей.

Четыре SLO, которые должна определить любая edge-стриминговая платформа

P95 времени старта потока. От момента, когда зритель нажал «воспроизвести», до момента, когда декодирован первый кадр. Цель: менее 3 с для VOD, менее 5 с для live WebRTC, менее 8 с для LL-HLS. P95 сквозной задержки. От пикселя на камере автора до пикселя на экране зрителя. Цель: менее 400 мс для WebRTC, менее 4 с для LL-HLS. Доля ребуферизации. Время ребуферизации, делённое на общее время воспроизведения. Цель: менее 1%. Доля успешных подключений. Количество сессий, дошедших до первого кадра, делённое на общее число попыток подключения. Цель: более 97% по P95, алертить, если в каком-либо регионе показатель упадёт ниже 95%.

Метрический пайплайн, который контролирует edge-расходы

Снимайте метрики как с edge-воркеров, так и с клиентского SDK (со стороны плеера). К каждому событию добавляйте теги: POP, регион, провайдер, ASN, класс устройства, идентификатор CDN. Агрегируйте данные в ClickHouse или Datadog с интервалом в 10 секунд. Настройте дашборды по стоимости в разрезе CDN, чтобы финансовый отдел видел изменения в объёме исходящего трафика почти в реальном времени. Один из наших аудитов у финтех-клиента выявил потерю 600 тыс. ₽ в месяц из-за неправильно настроенного тегирования на одном APAC-POP’е — проблему обнаружила система наблюдаемости, выделив «горячую точку».

Безопасность и DRM на edge: неочевидные риски

Edge снижает экспозицию origin’а, но добавляет четыре новые поверхности атаки: утечку подписанных URL, повтор токенов между POP’ами, уязвимость в цепочке поставок воркер-кода и DDoS-атаки на лицензионный эндпоинт DRM. Премиум-стриминговые платформы, игнорирующие эти риски, теряют контент в пиратстве уже через полгода.

Короткоживущие подписанные URL с энтропией на сессию

URL манифестов и сегментов должны истекать не позднее чем через 5 минут и привязываться к session ID зрителя, его IP-диапазону и отпечатку устройства. Cloudflare Stream, AWS IVS и Mux реализуют это с помощью HMAC-подписанных токенов для каждого запроса. Ключи подписи меняйте раз в квартал, храните в KMS, но ни в коем случае — в бандлах воркеров.

Widevine и FairPlay на уровне POP’а

Widevine L1 (с поддержкой железа) и FairPlay обмениваются ключами через лицензионные серверы, проксируемые CDN. Запускайте лицензионные прокси на edge (Cloudflare Workers или Fastly Compute), чтобы задержка получения лицензии по всему миру оставалась ниже 100 мс. Центральные лицензионные серверы становятся мишенью DDoS-атак в тот же день, когда пиратская ссылка начинает распространяться массово.

Криминалистические водяные знаки для премиум-контента

Невидимые водяные знаки в стиле A/B, встраиваемые на edge-транскодировании, показывают, с какого именно аккаунта был слил поток. NAGRA, Friend MTS и Verimatrix интегрируются с Cloudflare Stream, AWS Elemental и Mux. Накладные расходы — 5–8% CPU на транскодировании; эффект — заметное снижение пиратских стримов уже через несколько недель для спорта и премиум-OTT.

Защита от ботов и скраперов на эндпоинтах манифеста

Headless Chrome и инструменты вроде yt-dlp активно запрашивают URL манифестов с IP-адресов из облачных диапазонов. Cloudflare Bot Management, AWS WAF и Fastly Next-Gen WAF блокируют их по отпечаткам и ограничивают по частоте запросов, не затрагивая обычных пользователей. В 2026 году обязательно включайте правила на основе отпечатков TLS (JA4) — они перехватывают более 80% скриптовых клиентов, которых проверка по строке User-Agent пропускает.

Шесть ловушек, превращающих edge-проекты в финансовую катастрофу

1. Считать edge магией

Edge всё равно берёт деньги за транскодирование, хранение, ИИ-вывод и передачу данных — просто по чуть-чуть. Учитывайте расходы на каждый этап.

2. Привязка к одному CDN

Перейти с Cloudflare Stream на AWS IVS — значит переписать ингест, токены, DRM и аналитику. Если масштабирование уже в планах, с самого начала абстрагируйтесь от поставщика через собственный пакетировщик.

3. Холодный старт Lambda@Edge на интерактивных путях

Холодные старты длительностью 50–200 мс легко превышают субсекундный лимит задержки. На интерактивных путях используйте Cloudflare Workers или Fastly Compute.

4. Безграничное логирование на edge

Каждый console.log в edge-воркере попадает в платную систему сбора логов. Один из наших аудитов показал, что команда тратит на приём логов больше, чем на сам стриминг. Используйте агрессивную выборку.

5. DRM-ключи прямо в edge-воркерах

Edge-воркеры разворачивают код по всему миру. Внутри них используются только подписанные токены с ограниченным сроком действия. Мастер-ключи хранятся в центральном KMS.

6. Забыть про Safari

WebTransport и аппаратное декодирование AV1 в Safari в 2026 году по-прежнему не поддерживаются полностью. Всегда предусматривайте фолбэк на H.264 и стандартный WebRTC поверх WebSocket для пользователей Safari.

Тренды 2026 года, которые меняют подход к edge-стримингу

WebTransport + Media over QUIC. Chrome, Edge и Firefox в 2024–2025 годах выпустили WebTransport уровня продакшена. Задержка как у WebRTC, но с более простой логикой работы. Ожидать внедрения в реальных проектах можно в 2026–2027 годах.

Аппаратное декодирование AV1 на смартфонах. Около 15–20% смартфонов уже поддерживают аппаратное декодирование AV1. YouTube транслирует 75% видео в формате AV1. Для edge-устройств AV1 обеспечивает экономию полосы пропускания на 30–50% по сравнению с H.265 при одинаковом субъективном качестве — это огромная экономия на egress.

On-device super-resolution. Клиенты увеличивают разрешение с 540p до 1080p прямо на GPU телефона. Издатели могут передавать потоки с меньшим битрейтом, а edge-POP’ам не нужно так сильно транскодировать видео.

Программируемый стриминг. ffmpeg-на-edge (Cloudflare Workers AI, Fastly Compute с WASM) позволяет запускать пользовательские фильтры, водяные знаки и real-time брендинг без централизованной транскодинг-фермы.

ИИ-копроцессоры в POP’ах. Cloudflare, Fastly и AWS развёртывают edge-зоны с ускорением на GPU. Реальный перевод, модерация и повышение чёткости изображений теперь — стандартные услуги по строке тарифа, а не отдельные проекты.

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

P95 сквозной задержки по регионам (цель <400 мс для WebRTC, <4 с для LL-HTTP Live Streaming, <15 с для классического HLS). Доля успешных подключений (>97% по P95). Время старта потока (<3 с по P95). Доля ребуферизации (<1% времени воспроизведения). Egress на зрительскую минуту (отслеживайте по каждому CDN, алертите на дрейф). Доля ошибок edge-воркеров (<0,1% вызовов). Доля успешного ICE по регионам (>90%). Если какой-то показатель отклоняется больше чем на 10%, это сигнал о проблеме с инфраструктурой в конкретном регионе.

FAQ

Что такое edge-вычисления в контексте live-стриминга?

Это значит, что часть стримингового пайплайна — кодирование, упаковка, кэширование, ИИ-инференс, аутентификация — выполняется на серверах, расположенных близко к пользователям (десятки или сотни региональных POP’ов), а не в одном origin-регионе. Цель — снизить задержку ответа и разгрузить origin-сервер.

Насколько edge действительно снижает задержку по сравнению с централизованным origin’ом?

Для интерактивной WebRTC-нагрузки — задержка падает с 600–1200 мс при однорегиональном развертывании до 150–400 мс на edge SFU. Для LL-HTTP Live Streaming — с 10–30 секунд в классическом HLS до 2–5 секунд в edge LL-HLS. Сокращение в 4–10 раз — вот разница между «лагает» и «прямо сейчас».

Edge-стриминг дороже или дешевле центрального origin’а?

На масштабе обычно дешевле. Edge-CDN обрабатывают исходящий трафик (egress) локально — часто бесплатно, транскодирование и кэширование на POP’ах сокращают общий объём передаваемых данных на 30–60%, а значит, не нужно сильно завышать мощности центрального региона. В небольших однорегиональных приложениях edge-решение может стоить чуть больше из-за фиксированных минимальных тарифов. При нагрузке от 100 тыс. зрительских минут ожидается сокращение общих расходов на 40–70%.

Нужно ли запускать SFU на edge самостоятельно или достаточно управляемого сервиса?

Для 95% продуктов начинайте с управляемого сервиса (LiveKit Cloud, Daily.co, Twilio, 100ms). Самостоятельный хостинг окупается, когда вы стабильно используете больше 50 000 минут передачи в месяц в одном регионе или когда вам нужны гарантии резидентности данных, которые поставщик не может обеспечить. Даже в этом случае мы советуем стартовать с управляемого сервиса и заранее планировать переход на open-source; open-source SFU LiveKit делает такой переход реальным.

Подойдёт ли AWS Lambda@Edge для сигналлинга WebRTC?

Только для путей, где задержка не критична. Холодные старты Lambda@Edge на 50–200 мс убивают любой сквозной таргет с субсекундной задержкой. Для сигналлинга и токен-путей, попадающих в real-time-бюджет, используйте Cloudflare Workers (5 мс) или Fastly Compute@Edge (10 мс).

Когда edge для стриминга НЕ нужен?

Когда аудитория находится в одном регионе, продукт в основном VOD, одновременных зрителей меньше ~500, аудитория использует только Safari или у вас нет инженерной команды для поддержки распределённого пайплайна — в таких случаях простой однорегиональный деплой на Mux или Cloudflare Stream будет дешевле и надёжнее.

Как думать про мульти-CDN-резервирование на edge?

Любой CDN может выйти из строя. Используйте основной (например, Cloudflare Stream) и резервный (Bunny Stream или Mux) с переключением через DNS по регионам или через манифест. Это добавит 5–10% накладных расходов в настройку, но практически полностью устранит риск сбоя одного CDN.

AV1 на edge правда экономит полосу?

Да, на 30–50% эффективнее, чем H.265, и примерно на 50% — чем H.264 при сопоставимом субъективном качестве. Подвох в том, что в Safari до сих пор нет аппаратного декодирования AV1, поэтому приходится поддерживать фолбэк на H.264 или H.265. Доля смартфонов с аппаратным декодированием AV1 выросла с 9,76% (2024) до 15–20% (2026).

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

Готовы сократить задержку и расходы на CDN с помощью edge-архитектуры стриминга?

Edge-вычисления в live-стриминге больше не премиальная опция. В 2026 году это стандарт для любого продукта с аудиторией на нескольких континентах или требованием задержки менее 5 секунд. Архитектурные решения хорошо изучены, цены у поставщиков прозрачны, а гибридный подход — edge SFU для интерактивности и edge CDN для масштабирования — покрывает подавляющее большинство сценариев по цене, значительно ниже, чем у легаси-решений AWS IVS.

Если вам нужен разбор текущего пайплайна — что оставить, что заменить, где поставить первый POP — наша команда проектирует edge-архитектуры стриминга с 2005 года и эксплуатирует их в более чем 40 странах прямо сейчас.