Video.js v10 и Streaming Processor Framework

Кратко

Бесплатный open-source медиа-плеер Video.js – впервые выпущенный в 2010 году, сегодня обслуживающий десятки миллиардов просмотров видео в месяц – 10 марта 2026 года опубликовал бету десятой мажорной версии. Это полное переписывание с нуля, объединяющее четыре ранее независимых веб-плеера (сам Video.js, Plyr, Vidstack и Media Chrome) в один модульный фреймворк с first-class поддержкой React, TypeScript и Tailwind. Дефолтный бандл стал на 88% меньше, чем в восьмой версии; плеер теперь собирается из маленьких функциональных кусочков, которые попадают в бандл только при импорте; и новый параллельный проект под названием Streaming Processor Framework (сокращённо SPF) заменяет монолитный стриминговый движок набором кирпичиков, из которых вы собираете движок под конкретную задачу – «простой HLS»-движок, собранный из SPF, в gzip весит около 12 килобайт против 156 килобайт у hls.js. Эта статья объясняет, чем Video.js v10 на самом деле является, как устроен SPF, как новый плеер сравнивается с восьмой версией и с hls.js / Shaka / dash.js, когда его уже можно ставить в прод, а когда стоит дождаться general availability (команда целится в середину 2026 года), и какие практические вопросы по миграции нужно ответить, прежде чем переходить через границу версии. К статье приложен одностраничный чек-лист оценки, который ваша команда может взять на планировочную встречу и выйти с понятным «да» или «нет».

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

Если ваш продукт отдаёт HTML5-плеер в браузер – лендинг, OTT-каталог, podcast-сайт, образовательную платформу, smart-TV приложение, инструмент видеообзоров, – выбор плеер-библиотеки определяет три вещи, с которыми вы живёте годами: килобайты, которые каждый зритель скачивает до первого кадра, размер команды, которая поддерживает интеграцию, и скорость, с которой вы выкатываете новые фичи, которые просит дизайн. До марта 2026 года эти три числа для половины рынка, выбравшей Video.js, были неприятно высокими: большой бандл, API середины 2010-х, дефолтная тема, которую никто не хотел оставлять. Десятая версия меняет все три сразу, а SPF меняет четвёртое – сколько байт стоит ваш стриминговый движок. Будь вы продакт-менеджер, который взвешивает «мигрировать сейчас или ждать GA», фронтенд-инженер, который сравнивает Video.js v10 с React-нативными альтернативами вроде Vidstack или Media Chrome, или стриминговый инженер, который выясняет, может ли SPF заменить hls.js в плеерах, которые вы сейчас отгружаете, – эта статья даёт вам структурную картину, цифры и фреймворк решения, который можно унести на планировочную встречу. Предварительные знания по стримингу не требуются; каждый термин объясняется там, где впервые появляется.

Что такое Video.js v10 в одном абзаце

Video.js v10 – это полное переписывание open-source библиотеки медиа-плеера, которая поставлялась под именем video.js с 2010 года, переосмысленной как модульный фреймворк вместо монолитного объекта-плеера. Легаси-плеер – каждая версия с 1.x по 8.x – был построен вокруг единственного конструктора videojs(element), который возвращал объект Player, содержащий все возможные функции библиотеки, от кнопки play через меню субтитров до движка adaptive bitrate streaming. В десятой версии плеер вместо этого собирается из трёх независимых частей: store состояния (на паттерне store-slices из Zustand), media-компонента (собственно элемент <video> или один из его специализированных собратьев – компонент с источником YouTube или background-video компонент) и UI, построенного из unstyled-примитивов в стиле Radix и Base UI (Video.js Project, Video.js v10 Beta: Hello, World (again), 10 марта 2026). Плеер инстанцируется вызовом createPlayer({ features: [...] }), и вы включаете в бандл только те фичи, которые приложение реально использует – если вы не импортируете фичу audio, в бандл не попадает код volume и mute. Дефолтный видеобандл в gzip на 88% меньше, чем эквивалент из восьмой версии (25 килобайт против 75). Бета вышла 10 марта 2026 года; команда целится в general availability к середине 2026 года, с условием паритета функций с легаси-кодовыми базами Plyr, Vidstack, Media Chrome и Video.js v8 как порогом GA.

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

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

Почему этот рерайт вообще случился

Video.js был построен шестнадцать лет назад, чтобы помочь вебу перейти с Adobe Flash на новый HTML5-элемент <video> – работа, с которой он справился настолько хорошо, что к концу 2010-х стал дефолтным open-source плеером на заметной доле веба. На нём построен основной продукт Brightcove, на нём же стартовала каждая попытка OTT-пилота у кабельных провайдеров, и длинный хвост маленьких видеосайтов выбрал его, потому что больше нечего было ставить в прод. Цена, которую кодовая база заплатила за раннее распространение, – публичный API отражает JavaScript начала 2010-х: глобальный конструктор videojs(), прототипное наследование для каждого компонента, jQuery-стайл DOM-хелперы и модель расширения «форкни плеер и переопредели метод», которая не пережила появление бандлеров, tree-shaking и React-нативной композиции (Heffernan, S., Video.js v10 Beta: Hello, World (again), 10 марта 2026). Экосистема сторонних плагинов закрепила паттерн – как только тысячи плагинов начали полагаться на то, что они могут расширять прототип Player, команда уже не могла рефакторить, не сломав всех.

Технические последствия – дефолтный бандл, который только рос, никогда не уменьшался. Даже после того, как команда в 2018 году вынесла adaptive bitrate streaming в опциональный плагин videojs-http-streaming и разрешила импортировать video.js/core, чтобы его выкинуть, большинство установок продолжали тянуть полный бандл – частично по привычке, частично потому что дефолтный <script>-теговый сетап подтягивал именно полный файл. К середине 2020-х дефолтный v8 с adaptive bitrate весил около 700 килобайт в minified-форме и чуть больше 200 килобайт в gzip, против HTML5-элемента <video>, который не стоит ничего. Вот этот разрыв десятая версия и была построена закрыть.

Политический контекст тоже важен. Параллельно с Video.js росли три других open-source плеера – Plyr Сэма Поттса, ориентированный на визуальный дизайн; Vidstack, строящий React-первые примитивы; и Media Chrome от Mux, ориентированный на HTML web components. К 2025 году четыре проекта делили мейнтейнеров (Mux нанимает нескольких мейнтейнеров через все четыре кодовые базы), делили спонсоров (Mux спонсирует Video.js и построил Media Chrome внутри себя) и общую читательскую фрустрацию: одни и те же инженерные решения переоткрывались четыре раза с чуть разными API. Рерайт v10 объединил их. По собственному подсчёту проекта объединённое сотрудничество приносит под одну крышу 75 000 GitHub-звёзд и десятки миллиардов просмотров видео в месяц (Video.js Project, Video.js v10 Beta, 10 марта 2026). Четыре легаси-проекта продолжают релизиться – Plyr 4, Vidstack stable, Media Chrome – но их следующая глава живёт внутри репозитория videojs/v10.

Новая архитектура простым языком

Работающий Video.js v10 – это маленький граф из трёх независимых частей, склеенных вместе контекстом Player.Provider – новым публичным лицом библиотеки, заменяющим легаси-объект Player. Части называются State, Media и UI, и причина, по которой они живут в отдельных файлах, – что их можно использовать по отдельности.

State – это маленький реактивный store на паттерне store-slices из Zustand, который хранит всё, на что должно реагировать остальное: на паузе ли медиа, где сейчас курсор воспроизведения, какой буфер заполнен, включены ли субтитры, какая громкость, какой текущий ABR-вариант. Возможности добавляются в store передачей массива features в createPlayer() – например, features: [features.playback] подключает только слайс play / pause, features: videoFeatures подключает полный видеослайс (audio, captions, time, ABR-сигналы, error handling), а features: backgroundVideoFeatures подключает минимальный autoplay-loop без кода audio (Video.js Project, Concepts: Overview, доступ 2026-05-25). Если фичи нет в массиве – её кода нет в бандле. Это структурная причина, по которой React-«hello world» из анонсного поста весит меньше пяти килобайт в gzip.

Media – это компонент, который реально отрисовывает байты. Это может быть обычный <Video src="…">, оборачивающий HTML5-элемент <video>, <Audio> для аудио-only, <BackgroundVideo> для muted-autoplay видео на лендинге, или format-specific компонент (HLS, DASH) либо service-specific компонент (YouTube, Vimeo, Mux), которые команда планирует поставлять в той же архитектуре (Video.js Project, Concepts: Overview, доступ 2026-05-25). Media-компонент выставляет state-store одинаковый API независимо от того, какой источник он оборачивает – остальной плеер не должен знать, разговаривает он с нативным HLS, с инстансом hls.js или с SPF-собранным движком.

UI – это набор unstyled-примитивов, каждый из которых выдаёт ровно один HTML-элемент и выставляет каждое визуальное свойство как реальный CSS-класс под вашим контролем. Легаси-thumb таймлайна в v8 был псевдо-элементом на вложенном child, который вы стилизовали через переопределение font-size для размеров. В v10 thumb таймлайна – это <TimeSlider.Thumb className="slider-thumb">, и вы задаёте width: 0.75rem; height: 0.75rem; напрямую. Паттерн заимствован у shadcn/ui и Radix – UI-примитивы намеренно verbose, потому что verbosity и есть то, что даёт полный контроль над разметкой и CSS без сопротивления плеера (Video.js Project, Video.js v10 Beta, 10 марта 2026).

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

Preset – это уже собранная комбинация трёх. Бета поставляется с тремя пресетами – videoFeatures для обычного видео на сайте, audioFeatures для подкаст-стайл аудио и backgroundVideoFeatures для muted hero-видео на лендинге – и команда планирует добавлять новые по мере обратной связи. Вы берёте ближайший к вашему плееру пресет, ставите его и кастомизируете дальше.

Паттерн композиции означает, что плеер v10 может оказаться где угодно на спектре от «пяти-килобайтного hello world» до «полнофункционального стриминг-плеера с ABR, DRM, рекламой и аналитикой». Пять-килобайтный случай – это React-фрагмент из анонсного поста:

import { createPlayer, features } from '@videojs/react';
import { Video } from '@videojs/react/video';

const Player = createPlayer({ features: [features.playback] });

function App() {
  const store = Player.usePlayer();
  const paused = Player.usePlayer((s) => s.paused);
  return (
    <Player.Provider>
      <Player.Container>
        <Video src="video.mp4" />
        <button onClick={() => (paused ? store.play() : store.pause())}>
          {paused ? 'Play' : 'Pause'}
        </button>
      </Player.Container>
    </Player.Provider>
  );
}

Полнофункциональный случай – это тот же вызов createPlayer с полным набором фич, подключённым streaming-движком и ABR-способным media-компонентом.

Streaming Processor Framework, объяснённый

Streaming Processor Framework – коротко SPF – это отдельный sister-проект к Video.js v10, который делает для streaming-движка то же, что v10 делает для плеера: заменяет монолитную библиотеку набором маленьких компонуемых кусочков, из которых собирается движок под конкретную задачу. Стриминговый движок – это та часть веб-плеера, которая делает работу, которую браузер не сделает сам нативно для adaptive-bitrate форматов: парсит манифест (маленький текстовый индексный файл со списком доступных видеочанков), скачивает сегменты (короткие видеофайлы по 2–6 секунд, на которые ссылается манифест), скармливает эти сегменты в браузерный API Media Source Extensions для декодирования, определяет кодеки и выбрасывает неподдерживаемые рендиции, управляет буфером, гоняет ABR-алгоритм, который выбирает, какое качество скачать следующим, договаривается о ключах дешифрации для контента под DRM и вставляет server-side рекламные slates. В hls.js, Shaka Player, dash.js и легаси-плагине VHS для Video.js весь этот стек поставляется как одна библиотека – обрезать её, не форкая код, нельзя.

SPF переворачивает модель. Движок – это реестр функциональных компонентов, и вы собираете движок, который вы поставляете, перечисляя нужные компоненты. Приложение, которое стримит short-form CMAF без DRM и без рекламы, собирает движок, содержащий CMAF-парсер, segment loader, простое ABR-правило и MSE source-buffer адаптер – и больше ничего. Приложение, которое стримит платный OTT с multi-DRM, добавляет компоненты Widevine, PlayReady и FairPlay. Приложение, которое крутит server-side ad insertion, добавляет парсер маркеров SSAI. Исходное дерево движка в каждом случае одно и то же; разница – в том, какие импорты подтягивает проект (Video.js Project, Video.js v10 Beta, 10 марта 2026).

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

Числа из анонсного поста – это доказательство. SPF-собранный движок для случая «simple HLS» – только CMAF, on-demand, без рекламы, без DRM – в gzip весит 12,1 килобайта (Video.js Project, Video.js v10 Beta, 10 марта 2026). Сравнимая сборка hls.js-light, минимум, который можно поставлять из hls.js после удаления DRM, субтитров, alt-audio, CMCD и interstitials, в gzip весит 103 килобайта. Полный hls.js – 156 килобайт; Shaka – 239 килобайт; dash.js – 294 килобайта. Если посчитать вслух: 12,5 поделить на 156 – это чуть меньше 8 процентов, то есть SPF-собранный движок для simple-HLS примерно в восемь раз меньше стандартной сборки hls.js. Против hls.js-light соотношение – 12 процентов.

У этого есть два предупреждения, которые анонсный пост проговаривает отдельно, и статья их повторяет, потому что они решают, подходит ли SPF под конкретный проект сегодня. Первое: SPF – не drop-in замена hls.js, Shaka или dash.js на advanced-нагрузках. Бета-композиция SPF покрывает simple ABR над CMAF; она пока не покрывает DRM, рекламу и low-latency live. Формулировка самой команды – «immediate goal isn't for SPF to replace the full-featured engines like HLS.js for advanced streaming use cases» – это та строчка, которую инженерная команда должна прочитать вслух прежде, чем закладывать SPF в production-поток под DRM. Второе: v10 работает с устоявшимися движками без модификаций. Сегодня вы можете поставлять v10 с hls.js, Shaka или dash.js как streaming-движком (анонсный пост меряет связку v10 + hls.js в 164 килобайта gzip, на 20 процентов меньше, чем v8 + VHS с 203 килобайтами на той же нагрузке). SPF – это вариант, к которому вы тянетесь, когда use-case достаточно прост, чтобы экономия оправдала компромисс по зрелости.

Как v10 сравнивается с предыдущей версией и с другими веб-плеерами

Команда стриминговых инженеров выбирает плеер примерно по шести осям: размер дефолтного бандла, размер бандла с ABR, framework-история, кастомизация, зрелость экосистемы и видимость roadmap. Таблица ниже сводит числа из анонсного поста и публичные сигналы из roadmap в одну рядом-стоящую картину на май 2026 года.

Две ячейки заслуживают жирного. Video.js v10 с SPF на нагрузке simple-HLS на 81% меньше, чем Video.js v8 с VHS на той же нагрузке – одно это соотношение – причина, по которой greenfield-проект, стартующий в мае 2026 года, должен прогонять оценку относительно v10 ещё до даты GA. И Video.js v10 – единственный из пяти плееров с first-class поддержкой React, TypeScript и Tailwind – каждая другая библиотека либо поставляет враппер, отстающий от основного API, либо оставляет интеграцию с фреймворком на пользователя. Для React-стека это самая большая разница в продуктивности с первого дня.

Ячейка, которая должна вас затормозить, – production-зрелость: beta на 10 марта 2026. Команда целится в general availability к середине 2026 и сказала, что API ещё нестабилен. Правильное чтение этого сигнала зависит от того, greenfield ли это или миграция существующей v8-инсталляции – следующий раздел проговаривает решение вслух.

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

Пример с разбором миграционной арифметики

Нетехнический читатель должен увидеть аргумент про размер бандла с подставленными числами, потому что на нём держится остальная статья. Возьмите маркетинговый лендинг с HLS-видео продукта – одна рендиция, без рекламы, без DRM, субтитры включены, autoplay на muted-скролле. Сегодня страница поставляет Video.js v8 с VHS, включённым по умолчанию: 202,7 килобайта в gzip, что при типичной скорости 3G-загрузки в 200 килобайт в секунду даёт примерно одну секунду чистого времени скачивания до того, как код плеера хотя бы начнёт исполняться. Арифметика вслух:

v8 + VHS gzipped:            202,7 кБ
3G скорость:                 200 кБ/с
Время скачивания:            202,7 / 200 ≈ 1,01 с

Та же страница на Video.js v10 с SPF для simple-CMAF случая: 38,7 килобайт в gzip.

v10 + SPF gzipped:           38,7 кБ
3G скорость:                 200 кБ/с
Время скачивания:            38,7 / 200 ≈ 0,19 с

Страница экономит примерно 820 миллисекунд сетевого времени на каждой холодной загрузке. На маркетинговой странице, где bounce rate растёт на 9% за каждую дополнительную секунду загрузки (Akamai, State of Online Retail Performance, исторические данные – приведены иллюстративно), это число, которое окупает миграцию само. Картина менее драматична для OTT-приложения за авторизацией, где плеер загружается один раз и пользователь смотрит часами – но она всё равно реальна и накапливается на каждом устройстве.

Угол ИИ

Анонсный пост Стива Хеффернана выделяет угол, который остальная плеер-экосистема не обсудила открыто: команда проектировала кодовую базу v10 под понимание ИИ-агентами, а не только людьми. Аргумент в том, что чем больше фронтенд-кода пишется с помощью ИИ, тем больше шанс отгрузить ту плеер-библиотеку, по которой агент может ходить, не задыхаясь от собственного бюджета документации. Три конкретных артефакта v10 поддерживают эту цель (Video.js Project, Video.js v10 Beta, 10 марта 2026):

Файл llms.txt верхнего уровня, дающий любому ИИ-агенту курированную карту документации с низким контекстом – указывающий агенту на нужные страницы без загрузки полного дерева навигации. Отдельный framework-specific llms.txt для React-документации. Markdown-варианты каждой страницы документации, отдаваемые по согласованию контента: если агент стучится с заголовком Accept: text/markdown, сервер возвращает markdown-исходник вместо отрендеренного HTML, экономя агенту стоимость парсинга стилизованной страницы для извлечения текста. И растущий набор agent-таргетированных скиллов, закоммиченных под .claude/ и .zed/ в репозитории (видно в листинге файлов репозитория v10), которые команда использует внутри и планирует опубликовать для внешнего использования агентами.

Угол стоит подсветить, потому что ни одна другая веб-плеер-библиотека не поставила эквивалентные артефакты в 2026 году. Если ваша инженерная организация опирается на ИИ-агентов в UI-работе – а наблюдение Фора Софт по e-learning, OTT и surveillance проектам, отгруженным за последний год, в том, что наклон растёт, – кодовая база v10 – та самая, по которой ваши агенты будут писать корректный код быстрее всего.

Частая ошибка: ставить знак равенства между v10 и SPF

Самая частая путаница в раннем-2026 комментировании – что Video.js v10 и SPF – одно и то же. Это не так. Video.js v10 – это плеер; SPF – стриминговый движок. Вы можете поставлять v10 с hls.js, Shaka, dash.js или легаси-VHS, и вы можете поставлять SPF как streaming-движок внутри других плееров или вообще автономно – два проекта делят когорту мейнтейнеров, но живут в отдельных ветках кода с отдельным релизным циклом. Причина разделить их в голове в том, что градиенты зрелости разные: v10-плеер приближается к general availability по тем функциям, которые покрывал легаси-v8, а SPF-движок на бете явно поскоупен на нагрузки «simple ABR», с DRM, рекламой и low-latency live ещё в roadmap. Команда может сегодня поставить v10 + hls.js в прод и подобрать SPF позже, когда его surface догонит нужды проекта. Команда, которая перепутает два – либо переобещает покрытие SPF, либо недооценит готовность v10. Обе ошибки дорогие.

Где здесь Фора Софт

Мы строили браузерные видео-плееры девятнадцать лет в вертикалях, где Video.js исторически был дефолтным open-source выбором – платформы видеоконференций с воспроизведением записей на платформе, OTT и Internet-TV каталоги, e-learning курсы с timestamped-квизами, телемедицина с разбором консультаций, surveillance-дэшборды с мультистримовыми стенами и AR/VR опыт, которому нужен fallback-плеер плоского видео. Плеер редко самая видимая часть продукта, но он один из самых громких индикаторов инженерного качества в момент, когда пользователь нажимает play. Наша практика в 2026: начинать новый клиентский проект с оценки Video.js v10 + SPF, v10 + hls.js, Shaka Player и нативного iOS / Smart-TV пути относительно конкретной поверхности фич и DRM-требований проекта – аргументы про размер бандла и React-first в этой статье склоняют оценку к v10 для большинства greenfield браузерных деплоев, а аргумент про стоимость миграции склоняет существующие v8-инсталляции к «оставаться через GA, планировать миграцию осознанно».

Ключевые выводы

• Video.js v10 – это полное переписывание с нуля, выпущенное как бета 10 марта 2026 года, с целью на general availability к середине 2026.
• Дефолтный видеобандл – 25,1 кБ в gzip, на 88% меньше, чем 75,2 кБ у Video.js v8.
• Архитектура разделена на три независимые части: State store, Media-компонент, UI-примитивы, склеенные контекстом Provider.
• Streaming Processor Framework (SPF) собирает streaming-движок из функциональных компонентов; simple-HLS композиция – 12,1 кБ в gzip против 155,9 кБ у hls.js.
• v10 поставляет first-class поддержку React, TypeScript и Tailwind – единственный из крупных веб-плееров в 2026, у которого это есть.
• Правильный дефолт для greenfield React-проекта – v10 + SPF или v10 + hls.js; правильный дефолт для существующей v8-инсталляции – оставаться до GA.

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

• hls.js: подробный разбор
• Shaka Player: подробный разбор
• Media Source Extensions (MSE): как устроен каждый веб-плеер изнутри