HESP: 400 мс по HTTP и где он реально нужен

Последняя проверка: 2026-05-21 по черновику IETF draft-theo-hesp-06 HESP – High Efficiency Streaming Protocol (P. Speelmans, Ed., THEO Technologies – опубликован 17 апреля 2024, истёк 19 октября 2024; категория документа: Informational; индивидуальная подача, не WG-документ); публичному сайту HESP Alliance, странице FAQ и списку участников по состоянию на май 2026; пресс-материалам THEO Technologies и Synamedia; страницам Gcore, EZDRM, MainStreaming, SyncWords, NativeWaves и Hoki; а также опубликованным сравнительным white paper THEO Technologies по задержке и пропускной способности против chunked CMAF и LL-HLS.

TL;DR

HESP – High Efficiency Streaming Protocol – это HTTP-протокол адаптивной потоковой доставки, разработанный THEO Technologies. Он разделяет каждый трек на два параллельных потока: Initialization Stream (отдельно адресуемые пакеты с ключевыми кадрами) и Continuation Stream (последовательность CMAF-чанков). Благодаря этому плеер может начать воспроизведение или переключиться между вариантами на ближайшем key-кадре, не дожидаясь границы сегмента. Заявленные показатели: задержка от экрана до экрана ниже секунды – до 400 мс, смена канала менее чем за 100 мс, на 10–20% меньше пропускной способности по сравнению с LL-HLS и chunked CMAF при одинаковом качестве. Технология работает через обычный CDN, уже раздающий HLS и DASH. Компромисс – отсутствие открытости: HESP не является открытым стандартом. Документ IETF представляет собой индивидуальную информационную публикацию с истёкшим сроком действия, технология запатентована, а коммерческое использование плеера требует лицензии от HESP Alliance. По состоянию на май 2026 года HESP занимает узкую, но реальную нишу: интерактивный low-latency live (спортивные ставки, live shopping, аукционы, second-screen iGaming), где задержка в 400 мс важнее независимости от поставщика, а оператор готов работать в связке «один лицензированный плеер + один лицензированный packager».

Почему это важно

2020-е годы принесли четыре серьёзных протокола доставки с задержкой менее секунды по открытому интернету: WebRTC (вместе с WHIP и WHEP), LL-DASH с chunked CMAF, LL-HLS и HESP. Первые три – открытые стандарты с несколькими независимыми реализациями. HESP – нет. Это проприетарный протокол компании THEO, контролируемый HESP Alliance (созданной THEO и Synamedia), задокументированный в просроченном информационном черновике IETF и лицензируемый по моделям с роялти, зависящим от числа зрителей. Эта асимметрия в управлении – главный факт про HESP в 2026 году и причина, по которой он почти не фигурирует в дефолтном дереве выбора протоколов.

При этом HESP – это честная инженерия. Двухпотоковая архитектура решает задачу, с которой открытые стандарты справляются неуклюже: зритель, подключающийся к стриму в произвольный момент, может скачать один Initialization Packet, инициализировать декодер на ключевом кадре и сразу подключиться к Continuation Stream – без ожидания следующего IDR-кадра в сегменте, без повторного запроса манифеста и без DNS-резолва. Это и есть механизм за заявкой «zapping < 100 мс», и он по своей сути быстрее любого плеера на базе HLS или DASH – те всегда требуют полной загрузки манифеста и сегмента с ключевым кадром.

Эта статья – канонический справочник по HESP для инженеров, архитекторов и продактов, которые регулярно сталкиваются с ним в вендорских питчах, RFP от вещателей и более агрессивных стеках iGaming и live-commerce. Мы разберём, что представляет собой HESP на проводе, откуда берутся цифры по задержке и пропускной способности, как устроено лицензирование в 2026 году, какие платформы поддерживают HESP сегодня и в каких случаях выбор HESP оправдан – несмотря на существование открытых альтернатив.

Что такое HESP – одна страница

HESP – это HTTP-протокол адаптивной потоковой доставки, работающий на той же инфраструктуре CDN, что и HLS/DASH, но использующий собственный JSON-манифест и двухпотоковую модель сегментации. Протокол впервые публично представили на NAB 2019 (THEO начала работу в 2018), формально анонсировали через HESP Alliance в 2020 году, подали в IETF как draft-theo-hesp-00 в мае 2021 года и в последний раз обновили как draft-theo-hesp-06 в апреле 2024 года. По состоянию на май 2026 года этот черновик истёк без продления: документ имеет категорию «Informational» (не входит в Standards Track), является индивидуальной подачей (не документ рабочей группы) и в нём прямо указано, что описывается «версия 2 протокола HESP». Более новых документов IETF нет.

Каждый HESP-трек механически разделён на два потока – они закодированы из одного и того же исходного медиа, но адресуются и доставляются отдельно. Initialization Stream представляет собой последовательность независимо запрашиваемых Initialization Packets, каждый из которых является полным CMAF-bootstrap: содержит CMAF-заголовок (ftyp, moov), независимый ключевой кадр и in-band metadata event (emsg-бокс, кастомный URN urn:theo:hesp:2020) с JSON-указателем {"index": N, "offset": N}, сообщающим плееру, с какой позиции начинать чтение Continuation Stream. Continuation Stream – это обычный CMAF-поток в режиме live, разбитый на чанки, адресуемый через HTTP Range-запросы и последовательно потребляемый плеером после загрузки bootstrap-данных из Initialization Packet.

Поведенческий выигрыш – в том, что отличает HESP. Новый зритель, подключающийся к стриму, запрашивает один Initialization Packet по URL init/{initId} (или по специальному токену now – «дай мне самый свежий»), передаёт CMAF-bootstrap в декодер, читает указатель {index, offset} из встроенного emsg и отправляет HTTP Range-запрос к Continuation Stream с этого байтового смещения. С этого момента плеер работает в обычном режиме chunked-HTTP-CMAF – но ему не пришлось ждать ни границы сегмента, ни IDR-кадра в обычном сегменте, потому что сам Initialization Packet и был ключевым кадром.

Тот же механизм обеспечивает мгновенную смену канала: переключение на новый вариант запрашивает новый Initialization Packet, инициализирует декодер на новом key-кадре и подключается к новому Continuation Stream за один round-trip. В черновике HESP (§2.2) это описано как свойство, при котором «the Continuation Stream can start playback immediately after an Initialization Packet, allowing for very fast channel start and switch times».

Транспорт по проводу – обычный HTTP/1.1 или HTTP/2. Никаких требований к QUIC, WebSockets, WebRTC или проприетарному фреймингу. CDN видит обычные запросы по диапазонам к обычным URL, похожим на файлы, и кеширует их так же, как любые другие квазистатические ресурсы. В этом и заключается архитектурная идея: открытая доставка с низкой задержкой, с показателями лучше, чем у LL-HLS, по тем же CDN, за которые вы уже платите.

Нажмите, чтобы увеличить

Откуда берутся числа 400 мс и 100 мс

Два числа, которые часто приводят – 400 мс glass-to-glass и 100 мс zapping – требуют точного разбора: они верны лишь в одной конкретной конфигурации и вводят в заблуждение во всех остальных.

Glass-to-glass задержка. Бюджет задержки на sub-second HESP-пути определяется теми же компонентами, что и в любой low-latency HTTP-доставке: пайплайном энкодера, развёртыванием packager’а, ingest-плечом, CDN-плечом и jitter-буфером плеера. HESP достигает низкой задержки за счёт агрессивного чанкования CMAF в Continuation Stream – профиль «Maximum Gain» (§5.1.1 черновика) помещает один media-образец в один CMAF-чанк, что является минимально возможной единицей и составляет половину задержки при HTTP- доставке на основе чанков. Рассмотрим типичный live-поток с частотой 50 кадров в секунду: один кадр поступает каждые 20 мс; чанк публикуется сразу после кодирования этого кадра; CDN передаёт чанк как один фрагмент с кодировкой chunked-transfer-encoding в HTTP/1.1; плеер обрабатывает его в течение одного сетевого RTT после публикации. Арифметика, по шагам:

• Энкодер: 20 мс на sample при 50 fps. Один sample на чанк.
• Packager forwarding (закрытие чанка + push): 10–30 мс.
• Ingest-плечо (энкодер → packager origin): 5–50 мс в зависимости от географии.
• CDN cache miss → origin → cache fill → ответ edge: 20–80 мс.
• Edge → плеер: 10–100 мс.
• Jitter-буфер плеера: 100–300 мс (конфигурируемо; THEO-плеер в low-latency-профиле по умолчанию использует 150 мс).

Итого на чистом same-region wired-пути: примерно 300–600 мс. THEO в своих interop-демо сообщает 330 мс для чистого same-region пути на профиле Maximum Gain – это источник числа «400 мс» в заголовке. На transatlantic-пути задержка возрастает до 600–900 мс, поскольку каждый transatlantic RTT добавляет около 100 мс. Заявка «400 мс» реальна и достижима, но только в чистой конфигурации Max-Gain, при достаточном размере jitter-буфера и доставке в пределах одного региона.

Задержка смены канала (zapping). Здесь двухпотоковая модель HESP даёт действительно иное значение по сравнению со всеми существующими решениями на рынке. Типовой HLS-плеер, переключающийся с варианта A на вариант B по команде пользователя, должен: (а) запросить манифест нового потока (или найти его в кэше), (б) выбрать сегмент, с которого начать воспроизведение, (в) запросить сегмент с IDR-кадром, (г) инициализировать декодер. Спецификация HLS требует переключения, синхронизированного с ключевым кадром, на границе сегмента; реально измеренная задержка при работе с быстрым CDN составляет 2–6 секунд – в зависимости от длительности сегмента и степени прогрева кэша.

HESP-плеер при аналогичном переключении запрашивает один Initialization Packet (специальный URL init/now возвращает самый свежий), инициализирует декодер по ключевому кадру, читает {index, offset} и выполняет Range-запрос к Continuation Stream нового варианта. По измерениям THEO, такой round-trip на «тёплом» CDN занимает заметно меньше 100 мс: обычно 30–80 мс на получение Init Packet и 20–50 мс на Continuation Range, итого – 50–130 мс. Заявление HESP Alliance о том, что их решение работает «в 20 раз быстрее, чем стандартные решения для низколатентного стриминга», основано именно на этом сравнении и может быть обосновано механически.

Полоса. Третья заявка – на 10–20% меньше полосы, чем у chunked CMAF или LL-HLS при том же визуальном качестве – сложнее. HESP экономит полосу в двух местах. Во-первых, профиль Maximum Gain жёстко эффективен на битовом уровне: он позволяет энкодеру строить длинные inter-frame цепочки (каждый sample ссылается только на непосредственного предшественника) и обходит структурный overhead, который LL-HLS навешивает через «parts» и rendition reports. Во-вторых, HESP-плеер переключает варианты по событиям key-frame из Initialization Stream, а не по границам сегмента – значит, плеер может сразу перейти на более низкий битрейт при падении throughput, не дожидаясь окончания «лишнего» сегмента с высоким битрейтом, как это делает LL-HLS. Тестовые цифры THEO сравнивают 6 Mbps HESP Max-Gain поток с 6,6–7,3 Mbps LL-HLS эквивалентом при сопоставимом качестве. Экономия реальна, но методика «при сопоставимом качестве» зависит от лаборатории; для закупки относитесь к 10–20% как к «правдоподобно в benchmark-тесте, моделируйте 0–15% на свой трафик».

Нажмите, чтобы увеличить

Два профиля – Max Gain и Compatibility

Черновик определяет два профиля, которые может выдавать HESP-encoder/packager, и они по-разному балансируют задержку и совместимость.

Профиль Maximum Gain (§5.1.1) – конфигурация с минимальной задержкой: каждый CMAF-чанк содержит ровно один media-образец, каждый образец ссылается только на своего непосредственного предшественника (отсутствует стандартная структура GOP), а сегменты могут иметь произвольную длину – границы больше не играют роли, каждый чанк маршрутизируется независимо. Название «Max-Gain» отражает выигрыш в пропускной способности по сравнению с потоками, организованными по стандартной GOP-структуре: отсутствие полной GOP-границы внутри типичной длительности сегмента устраняет классический оверхед на IDR, который HLS и DASH требуют для splice-точек. Компромисс: декодеры без HESP-совместимой буферизации не смогут обработать этот поток – выход Max-Gain специфичен для HESP и не воспроизводится в обычных HLS- или DASH-плеерах.

Профиль Compatibility (§5.1.2 в более ранних черновиках, переименован в -06) сохраняет стандартную структуру сегментов CMAF и GOP: сегменты длительностью 1–30 секунд, обычные GOP вида I B...B P B...B P с до 4 B-кадров на GOP – поэтому один и тот же выход packager можно использовать как для HESP, так и для обычного HLS/DASH: на запросы HESP-плеера он возвращает указатели на Initialization Stream emsg, а на запросы обычного плеера – стандартный манифест. Именно этот production-паттерн реально применяют большинство развёртываний HESP: HESP – для live edge (зрители с задержкой менее секунды), HLS – как broadcast tail (покрытие устройств и дешёвый egress для большинства), при этом один пакетный пайплайн обслуживает оба формата.

Для закупок выбор профиля имеет значение. Если вы привязаны к HESP под sub-second и используете HESP-специфичный плеер на каждом устройстве – Max-Gain будет правильным выбором и обеспечит заявленные показатели задержки. Если же вы хотите сохранить HLS как резервный вариант для устройств с ограниченным функционалом (smart TV, старые мобильные приложения, около 30% endpoint-устройств в стриминге в 2026 году, не поддерживающих HESP-плеер) – практичным решением станет Compatibility: вы теряете часть выигрыша по пропускной способности, но сохраняете единый пакетный пайплайн.

Манифест – почему JSON и как он выглядит

HESP не использует ни M3U8, ни MPD. Его манифест – это кастомный JSON-документ с MIME-типом application/vnd.theo.hesp+json, который предлагается зарегистрировать в IANA в разделе §9 черновика. Структура JSON концептуально аналогична DASH: один корневой элемент Manifest, одна или несколько Presentation (аналог Period в DASH), одна или несколько SwitchingSet на Presentation (аналог AdaptationSet), одна или несколько Track на SwitchingSet (аналог Representation). Каждый Track содержит URL-шаблон для Initialization Stream и URL-шаблон для Continuation Stream – оба используют плейсхолдеры {initId} и {segmentId} (например, init/{initId:08d} и content-{segmentId:06d}.mp4).

Минимальный HESP-манифест для одного live-события с двумя видеовариантами и одним аудиовариантом занимает около 80 строк отформатированного JSON – примерно столько же, сколько master-плейлист HLS multi-variant вместе со своими child-плейлистами, и при этом структурно проще эквивалентного DASH MPD. Протокол опирается на относительно статичный манифест: варианты и презентации объявлены заранее, а live edge перемещается по мере поступления данных через chunked-HTTP транспорт Continuation Stream, а не за счёт перезагрузки манифеста. Статичность манифеста – одна из причин, по которой HESP хорошо масштабируется на CDN: манифест кэшируется на всё время трансляции.

Практические следствия. Во-первых, HESP-плеер – это не просто дополнительный парсер, подключённый к HLS- или DASH-плееру: это полноценный новый медиа-движок. Существующие HLS.js, dash.js, Shaka Player и Video.js не поддерживают HESP; в 2026 году единственными плеерами HESP в продакшене остаются коммерческий THEOplayer, open-source референсный HESPlayer, плеер NativeWaves и несколько вендорских встроенных решений (Gcore, MainStreaming). Во-вторых, нативной поддержки HESP в браузерах нет – плеер всегда представляет собой JavaScript-медиа-движок, взаимодействующий с браузером через Media Source Extensions (см. нашу статью про MSE). В Safari на iOS поддержка MSE появилась только в iOS 17.1 (2023); HESP работает только на достаточно новых версиях. На старых версиях iOS Safari поддержка HESP отсутствует полностью.

HESP Alliance, статус IETF и вопрос лицензирования

Здесь позиционирование HESP усложняется – и именно здесь обычно принимается решение о выборе протокола.

THEO Technologies (бельгийский вендор плеера THEOplayer) – разработчик протокола и владелец патентов на используемую в нём технологию. HESP Alliance, основанная в 2020 году при участии Synamedia в качестве одного из двух соучредителей, – организация, отвечающая за лицензирование и сертификацию. Альянс работает по двухуровневой системе: участники уровня Gold не ограничены годовым объёмом выручки, а участники уровня Silver – не более 10 миллионов долларов США в год. Основатели: THEO и Synamedia; публичные участники уровня Silver на май 2026 года: Gcore (с 2022), MainStreaming, EZDRM (с 2024, DRM для HESP), SyncWords (субтитры в прямом эфире), NativeWaves, Hoki. Публичных участников уровня Gold – заметно меньше десяти.

Лицензионная модель – три коммерческие категории. Инициация HESP-потоков (то есть публикация HESP-фида) – бесплатна для всех. Некоммерческое использование HESP – также бесплатное. Коммерческое использование HESP-клиента – платная категория с тремя моделями на выбор лицензиата: по объёму использования (за гигабайт или час стрима), по подписке (за одного платного зрителя в месяц) или по устройству (за каждое сертифицированное HESP-устройство). Alliance называет коммерческие условия «справедливыми, разумными и недискриминационными» (FRAND) и публикует тарифную сетку на странице Royalty Rates; конкретные цифры не раскрываются и согласовываются индивидуально под NDA.

Статус IETF – одновременно самый цитируемый аргумент и главная проблема доверия. Документ IETF существует: draft-theo-hesp-06, апрель 2024, индивидуальная подача, категория Informational. Однако IETF трактует индивидуальные информационные черновики как опубликованный справочный материал, но не как стандарт IETF. В документе явно содержится стандартный текст IETF: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.'" Текущий черновик -06 истёк 19 октября 2024 года и не обновлялся. Ни одна рабочая группа IETF по HESP не рассматривает его, прогресс в сторону RFC не запланирован, а очевидного пути к стандартизации нет – базовая технология запатентована, лицензирование не является RAND-Z (то есть не royalty-free).

Структурное сравнение стоит провести с LL-HLS и LL-DASH. LL-HLS описан в Apple HLS Authoring Specification – живом документе, который Apple обновляет 1–3 раза в год. У него есть несколько независимых реализаций плеера: hls.js, Shaka Player, нативный плеер iOS, Bitmovin Player и, конечно, THEOplayer. LL-DASH закреплён в стандарте ISO/IEC 23009-1 и дополнительных руководствах DASH-IF, также имеющих несколько независимых реализаций. WebRTC-доставка стандартизирована в рамках W3C и серии RFC 8825–8866 от IETF, а её реализации встроены в каждый современный браузер. Все три формата – открытые стандарты с несколькими независимыми реализациями. HESP – это продукт одного вендора (THEO), одна спецификация (просроченный информационный черновик) и одна-две коммерческие реализации плеера. Это не смертельный недостаток – десятилетиями Adobe Flash доминировал на стриминговом рынке при такой же структуре управления, – но для любого закупочного решения, где важны независимость от поставщика и долгосрочная устойчивость дорожной карты на десять лет вперёд, это ключевой фактор.

Поддержка вендорами и карта развёртываний в 2026

Таблица ниже показывает охват HESP по платформам, которые, скорее всего, будут оцениваться стриминговым продуктом в 2026 году. Колонка «поддержка HESP» разбивает возможности на три категории: origin/packager (может ли encode-сторона пайплайна генерировать HESP), CDN (передаёт ли ваш CDN HESP по сети) и player (может ли клиентское устройство декодировать HESP).

Форма карты важнее содержимого отдельных ячеек. Production HESP сегодня – это вертикально интегрированный стек: HESP-совместимый packager (THEO, Synamedia, Gcore, MainStreaming), CDN, корректно передающий HTTP (любой современный), HESP-совместимый плеер (почти всегда THEOplayer). Замените любой из трёх компонентов – и стек рассыпается. Команда, выбирающая HESP, берёт на себя долгосрочную приверженность этой вертикали, включая лицензионные отношения и цикл обновлений плеер-движка, на весь срок эксплуатации развёртывания. Это принципиально иной уровень обязательств, чем, например, выбор Shaka Player вместо любого LL-HLS-совместимого origin.

Рабочий пример – live-стрим спортивных ставок на HESP

Проследим одну конкретную конфигурацию, где коммит на HESP оправдан. Транслируем live-матч по футболу в 1080p50 примерно на 80 000 одновременных зрителей по территории Tier-1 в Европе. Требование продукта – строго sub-second glass-to-glass: стрим используется внутри in-play беттинг-продукта оператора, и зритель должен видеть момент игры за считанные сотни миллисекунд до закрытия рынков ставок. WebRTC оценили и отвергли по цене на 80 000 concurrent: per-viewer SFU-стоимость потребовала бы сетки TURN/SFU из 80–120 серверов по территории. LL-HLS оценили и отвергли по задержке: его пол 3–6 секунд позволяет рынку in-play закрыться до того, как событие появится на экране.

Production-стек: HESP-совместимый origin от Synamedia пакетирует выход live-энкодера (Bitmovin Encoder OTT, лестница 6 Мбит/с + 3 Мбит/с + 1,5 Мбит/с, H.264, 50 кадров в секунду, профиль Max-Gain, один фрейм на CMAF-чанк), CDN от Gcore раздаёт трафик по Европе, THEOplayer Web работает в браузере каждого клиента (или THEOplayer iOS / Android – в мобильных приложениях).

Трассировка по проводу для подключающегося зрителя: плеер грузит HESP-JSON-манифест с https://cdn.example.com/sport-event-42/manifest.hesp.json (один round-trip, 30 мс). Манифест объявляет три видеотрека и один аудио в активной SwitchingSet; плеер выбирает средний 3 Mbps вариант (его bandwidth-estimator начал консервативно). Он запрашивает init/now по URL Initialization Stream 3 Mbps варианта: CDN отдаёт самый свежий Init Packet, 24 KB, в одном HTTP/2-запросе (35 мс RTT + 8 мс transfer). Плеер передаёт CMAF-заголовок в свой media-source декодер, читает emsg-указатель {"index": 4217, "offset": 1283904} и делает HTTP Range-запрос Range: bytes=1283904- против URL Continuation Stream content-004217.mp4. CDN отдаёт Range из тёплого кеша (12 мс). Первый декодированный кадр попадает на экран зрителя примерно через 315 мс после захвата камерой – измерено по миллисекундному таймеру, наложенному на источник.

В ходе игры плеер переключается на вариант со скоростью 6 Мбит/с, когда его оценщик пропускной способности стабилизируется на высоком уровне: само переключение механически идентично подключению – нужно запросить init/now новый вариант, выполнить key-frame для декодера и подключиться к новому Continuation Stream – процесс занимает около 65 мс и не вызывает заметных артефактов для зрителя. 80 000 одновременных подключений по территории формируют агрегированную нагрузку около 290 Гбит/с на уровне 6 Мбит/с, которую Gcore обслуживает по тарифу HESP-CDN. Лицензионный платёж в HESP Alliance рассчитывается по модели оплаты за подписчика: у оператора известен MAU беттинг-продукта, и фиксированная ставка на одного MAU обеспечивает стабильную стоимость на отчётный период.

Тот же контентный путь на LL-HLS дал бы примерно 4 секунды glass-to-glass – 13× HESP – с закрытием in-play рынка через 4 секунды после события на поле: продуктовый провал для этого use-case. Тот же путь на WebRTC дал бы примерно 280 мс glass-to-glass – слегка лучше HESP – но при ~6× стоимости CDN, потому что каждый зритель становится пиром на SFU. HESP-решение одновременно попало и в целевую задержку, и в целевую экономию.

Нажмите, чтобы увеличить

Когда выбирать HESP – фреймворк решения

HESP предполагает определённый набор требований; за его пределами правильным выбором становится один из открытых стандартов. Ниже представлен фреймворк, который мы будем проходить с клиентами в 2026 году.

Выбирайте HESP, когда: (а) бюджет задержки строго меньше секунды, идеально – менее 500 мс; (б) аудитория средняя или большая (5 000 – 1 000 000 одновременных зрителей на стрим – достаточно велика, чтобы стоимость на одного зрителя при использовании WebRTC была невыгодной); (в) вы готовы привязаться к вендорскому стеку (THEO + один HESP-пакер + один HESP-совместимый CDN); (г) требования к поддержке устройств – современные браузеры и мобильные приложения (отсутствуют legacy-устройства, такие как старые Smart TV или set-top box без рабочей поддержки HLS-резервного канала); (д) сценарий использования предполагает высокую скорость переключения каналов – live-беттинг, live shopping, мультикамера в спорте, second-screen iGaming. Лицензионные отношения – часть сделки.

Выбирайте WebRTC / WHIP / WHEP, если: нужна задержка менее секунды, аудитория ограничена (до 5 000 – 10 000 одновременных подключений на стрим), при этом стоимость SFU на стороне каждого зрителя ещё приемлема, а источник трансляции также использует WebRTC.

Выбирайте LL-HLS, когда: задержка составляет 3–6 секунд, аудитория не ограничена, поддержка устройств включает широкий спектр (включая устаревшие smart TV и set-top boxes), или вы отдаёте приоритет открытому стандарту с несколькими независимыми реализациями плеера по сравнению с минимальной задержкой.

Выбирайте LL-DASH / CMAF chunked, если: вы уже используете DASH-нативную цепочку (Bitmovin / Shaka Packager), а требуемая задержка составляет 3–5 секунд.

Выбирайте классический HLS, если задержка не критична, а выбор определяется экономикой egress CDN.

Нажмите, чтобы увеличить

Типичные ошибки – на чём ломается HESP в production

Короткий список типичных провалов при запуске нового HESP-канала или оценке HESP в закупочном цикле. Большинство из них – не баги протокола, а несоответствие того, что даёт HESP, реальным потребностям проекта.

Подводный камень 1: считать HESP drop-in заменой HLS. Это не так. Плеер другой, манифест другой, ключи кеша CDN – другие, интеграция DRM – тоже. Поддержка CENC реализована по §7 черновика, но используется HESP-специфичная семантика ext-X-key-replacement. Команда, планирующая «просто включить HESP» поверх существующего HLS-пайплайна, уже в первом спринте обнаруживает, что ей придётся переписать слой плеера и переподписать контракт с CDN.

Подводный камень 2: выбрать профиль Max-Gain и потерять HLS fallback. Выход Max-Gain – только HESP, его нельзя использовать в браузере как HLS без HESP-плеера. Развёртывание, обещающее «HESP для low-latency и HLS для длинного хвоста», должно использовать Compatibility-профиль, а не Max-Gain. Цель задержки тогда смещается ближе к 600–900 мс, потому что чанки становятся крупнее.

Подводный камень 3: недооценить лицензионные отношения. «Royalty-free для некоммерческого использования» не означает royalty-free для вашего коммерческого стримингового продукта. Коммерческая модель лицензирования существует, а оплата за пользователя в месяц, за гигабайт или за устройство – реальность, которую нужно согласовать и заложить в бюджет до начала разработки. Несколько команд создали PoC HESP на бесплатной основе и столкнулись с условиями масштабирования лицензии только при переходе в production.

Подводный камень 4: принимать IETF-черновик за стандарт. Это не стандарт. draft-theo-hesp-06 – просроченная индивидуальная информационная подача. Относитесь к ней как к вендорскому техническому справочнику, а не как к стабильному контракту на взаимодействие. Если ваша закупка требует «доставку по IETF-стандарту», HESP этому требованию не соответствует; LL-HLS, LL-DASH и WebRTC – соответствуют.

Подводный камень 5: забыть историю MSE в Safari на iOS. HESP требует Media Source Extensions; поддержка MSE в Safari на iPhone появилась только в iOS 17.1 (октябрь 2023). Зрители на iOS 16 и более ранних версиях iPhone вообще не имеют доступа к HESP. Профиль совместимости с HLS-резервным вариантом – единственный реалистичный выход.

Подводный камень 6: сравнивать числа задержки без деталей пути. Демо HESP – 330 мс, демо WebRTC – 280 мс, развёртывание LL-HLS – 3 секунды – все эти значения корректны в своих конфигурациях. Важное число для вашего проекта – это задержка от экрана до экрана (glass-to-glass) на вашем энкодере, вашем CDN, вашем плеере и вашей географии зрителей. Требуйте live A/B-теста против вашего реального стека перед тем, как фиксировать выбор протокола.

Подводный камень 7: путать HESP Alliance с IETF. Alliance – это коммерческий консорциум, который продвигает внедрение технологии, управляет роялти и сертифицирует продукты. IETF – это орган стандартизации, выпускающий RFC. У Alliance нет полномочий по стандартизации, как у IETF. Членство в Alliance не означает, что HESP является стандартом IETF.

Где Фора Софт встраивается

Мы поставляли HESP-осознанные стеки доставки в двух вертикалях, где пересечение задержки и масштаба действительно оправдывало лицензионный коммит: продукт спортивных ставок Tier-2 в Европе, где live in-play рынки закрываются с маржой в доли секунды, а 30 000–80 000 одновременных пользователей на матч делали WebRTC экономически невыгодным; и платформа для прямых трансляций с несколькими камерами в мотоспорте уровня Tier-1, где переключение между камерами за 100 мс – ключевое преимущество продукта. В обоих случаях выбор был осознанным, с чёткой оценкой рисков vendor lock и долгосрочного лицензионного бюджета. За пределами этого пересечения наш стандарт на 2026 год для sub-second задержек – WebRTC для ограниченных аудиторий, а для задач «минимальная задержка при сохранении CDN-экономики на больших масштабах» – LL-HLS. HESP мы не внедряем в проекты, где его монолитное управление становится закупочным риском.

Главное

• HESP – HTTP-протокол доставки с двухпотоковой моделью (Initialization Packets с key-frame + Continuation Stream из chunked CMAF), обеспечивающий задержку glass-to-glass 400 мс и переключение канала менее чем за 100 мс.
• Протокол не является открытым стандартом: документация опубликована в draft-theo-hesp-06 – это истёкшая индивидуальная информационная подача IETF (не входит в Standards Track, не является документом рабочей группы); технология запатентована.
• Коммерческое использование требует лицензии от HESP Alliance: инициация потока – royalty-free, а коммерческое использование плеера – платное по одной из трёх моделей роялти.
• В продакшене HESP необходим вертикальный стек: HESP-упаковщик (THEO / Synamedia / Gcore / MainStreaming) + HESP-плеер (почти всегда THEOplayer) – замена любого компонента нарушает работоспособность стека.
• Заявленные 400 мс достижимы только при профиле Max-Gain, маршруте в пределах одной области и стабильном jitter-буфере; на более реалистичных конфигурациях ожидайте задержку 600–900 мс.
• Выбирайте HESP, если нужна задержка менее секунды, аудитория средняя или большая и вы готовы привязаться к вертикальному решению на базе THEO; в остальных случаях предпочтительны WHEP для малых аудиторий или LL-HLS для неограниченных.
• Safari на iOS требует iOS 17.1+ для работы с MSE; старые версии iOS не поддерживают HESP – необходим fallback на HLS через Compatibility-профиль.

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

• WHEP: HTTP-сигнализация для egress WebRTC – открытая альтернатива с задержкой менее секунды для ограниченных аудиторий.
• LL-HLS подробно: части, подсказки предварительной загрузки, блокирующая перезагрузка, отчёты о версиях – открытая альтернатива с задержкой до пяти секунд на уровне масштабирования.
• Как выбрать delivery-протокол в 2026: дерево решений – полное дерево решений по современным протоколам доставки.

CTA

Поговорить с инженером по стримингу · Посмотреть наши кейсы · Скачать чек-лист оценки HESP (PDF)