Видео стало неотъемлемой частью нашей жизни: мы смотрим его на смартфонах, ноутбуках и всё чаще — на телевизорах. Несмотря на то, что видеосервисы традиционно ориентировались на мобильные устройства, за длинным контентом пользователи идут именно на большие экраны, и это подтверждается ростом времени просмотра. Сегодня среднее дневное время смотрения VK Видео на Smart TV достигает 216 минут.

И тут начинается самое интересное: телевизоры — это особый мир со своими капризами и законами. Официальные спецификации обещают поддержку HLS, DASH, 4K, 60 FPS. На практике поддержка функций зависит не столько от новизны модели, сколько от того, как это реализовано у конкретного производителя. В одних устройствах всё работает корректно, в других — частично или вовсе не запускается. Новая модель при этом не всегда гарантирует лучшее воспроизведение видео.

Меня зовут Игорь Горяйнов, я программист в команде веб-технологий Единой видеоплатформы VK. Ниже расскажу, как команда прошла путь от нативных плееров к собственному веб-решению для ТВ, какие задачи пришлось решать и что это дало пользователям.

Снаружи просто, внутри — лабиринт

Когда мы только выпустили приложение VK Видео для телевизоров, логика казалась простой: у каждого производителя есть свой SDK, свой нативный плеер — зачем изобретать велосипед? Samsung предлагает Tizen с его возможностями, LG — webOS, который «работает из коробки». Казалось, что остаётся только подключиться к API и наслаждаться результатом.

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

Вот только реальность оказалась куда интереснее. Например:

• На Samsung с Tizen встречались «отскоки» при воспроизведении HLS — сегмент повторялся или видео прыгало назад. Особенно это проявлялось на моделях 2019–2021 годов. Пользователи жаловались, что видео «заикается», хотя с сетью всё было в порядке

• На LG с WebOS при воспроизведении в высоких разрешениях мог появиться знаменитый эффект «пол-экрана зелёного цвета». Проблема возникала эпизодически и зависела от конкретной модели, года выпуска и даже версии прошивки

• У нового вендора TVIP обнаружился баг: при перемотке плеер не запускал видео с выбранной точки, а упрямо возвращал пользователя в начало. Оказалось, что их реализация state-машины неправильно обрабатывала переход из состояния паузы в воспроизведение

Все эти истории объединяло одно: воспроизводимость была непредсказуемой. В спецификации написано «поддерживает», а на деле конкретная модель могла вести себя как угодно. Инженерно это выглядело как бесконечная борьба с чёрным ящиком: мы отдаём поток, а что плеер сделает дальше — загадка. Более того, каждое обновление прошивки телевизора могло как решить старые проблемы, так и добавить новые. Пользователи не понимали, почему вчера всё работало, а сегодня не запускается. А мы не могли дать внятного объяснения, потому что логика работы нативного плеера была скрыта от нас.

Исторически видеостриминг внутри VK в основном строится на DASH. Этот протокол даёт более гибкое управление качеством и лучше подходит для масштабирования, чем HLS. Проблема была в том, что большинство нативных ТВ-плееров с DASH работали плохо или не работали вовсе. Так у команды Единой видеоплатформы возникла идея уйти от нативных решений и сделать собственный веб-плеер для Smart TV.

Важно отметить, что собственный веб-плеер у нас на тот момент уже был, и он успел зарекомендовать себя на мобильных и десктопных версиях. Благодаря этому решению мы сильно ускорили выход обновлений, упростили поддержку и обеспечили единый UX вне зависимости от платформы. 

Для нас раскатка собственного веб-плеера на Smart TV означала:

• Полный контроль над логикой воспроизведения. Вместо того чтобы надеяться на корректную работу стороннего плеера, мы получили возможность сами управлять всеми аспектами процесса — от инициализации и обработки ошибок до взаимодействия с сетью. Теперь можно задавать, когда начинать загрузку файлов потока, в какой момент переключаться на более низкое разрешение и как оптимально распределять сетевые ресурсы для стабильного воспроизведения

• Прозрачную диагностику. Когда что-то идёт не так, мы можем собирать детальные логи, анализировать метрики производительности и быстро локализовать проблему. Больше не нужно гадать, на каком этапе и почему плеер завис 

• Независимость от ограничений конкретных SDK. Каждый производитель накладывает свои ограничения: где-то не поддерживается определённый кодек, где-то урезана функциональность DRM, где-то просто странно реализован API. Веб-плеер позволил нам обойти эти искусственные ограничения

Вместо чёрного ящика появился белый и прозрачный: всё, что внутри, написано командой Единого Видео VK и полностью понятно.

Как мы создавали собственный веб-плеер 

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

Примечание. ZombieBox — это JavaScript-фреймворк для разработки приложений SmartTV и STB, созданный командой Interfaced. Изначально он задумывался как кросс-платформенное решение, позволяющее писать один код для разных вендоров. Разрабатывается одно приложение, а работает оно на Samsung Tizen, LG webOS, VIDAA, TVIP и других платформах.

В нашем случае ZombieBox частично решал проблему: можно было держать общую кодовую базу и абстрагироваться от специфики платформ. Но по сути он всё равно оставался надстройкой над теми самыми капризными плеерами. Поэтому для DASH и новых функций он не подходил.

Ключевым этапом перехода стал наш отказ от ZombieBox и использование ядра веб-плеера Единого видео, о котором говорили выше. Мы обновили только один слой ядра, UI оставили прежним, тем самым добились кросс-платформенности. Нам удалось упростить поддержку и ускорить внедрение изменений для всех платформ — Smart TV, десктопа, мобильных устройств — и получать одинаковое качество без зависимости от конкретной среды.

Мы решили раскатывать собственный веб-плеер и поставили несколько целей:

1. Сократить Time to Market для новых функций. С нативными плеерами каждая новая фича требовала времени на погружение в документацию, тестирование, а часто и кодинг. Свой плеер позволил нам внедрять новые возможности единообразно для всех устройств

2. Не ухудшить базовые метрики качества. Любые эксперименты с плеером не должны были негативно сказаться на ключевых показателях: времени до первого кадра (TTFF), частоте зависаний, проценте успешных воспроизведений. Пользователи не должны были заметить переход на новую технологию 

3. Сократить время на разбор инцидентов. Когда пользователь жалуется на проблемы с воспроизведением, команде поддержки и разработчикам нужны инструменты для быстрой диагностики. Веб-плеер должен был предоставить детальную телеметрию

4. Наконец-то нормально поддержать DASH. Это была стратегическая цель — получить все преимущества протокола DASH для пользователей Smart TV: более гибкую адаптацию качества, лучшее использование полосы пропускания, расширенные возможности для монетизации 

Переход на новый плеер не мог происходить одномоментно — слишком много рисков для пользователей и бизнеса. Мы выбрали эволюционный подход:

1. Разделение репозиториев. Ещё до внедрения веб‑плеера мы отделили репозиторий плеера от основной кодовой базы продукта, чтобы не приходилось синхронизировать релизные циклы двух команд — продуктовой и плеерной. Уже внутри этого отдельного репозитория нативная и веб-версии сосуществовали в одной кодовой базе, их функциональностью можно было управлять через фича‑тогглы

2. A/B-тестирование. Новый плеер сначала запускался только для небольшой доли пользователей — около 5%. Это позволяло в реальных условиях сравнивать производительность двух решений и выявлять проблемы до массового внедрения. Постепенно доля тестовой группы увеличивалась: 10, 25, 50%

3. Выравнивание метрик. На каждом этапе мы тщательно сравнивали ключевые показатели между контрольной и тестовой группами. Если веб‑плеер показывал результаты хуже нативного даже на статистически незначимую величину, мы останавливали раскатку и занимались оптимизацией. А в случаях, когда улучшить показатели было невозможно, временно оставляли часть устройств работать на нативном плеере.

Адаптация веб-плеера для Smart TV: что изменилось

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

Ключевой момент: базовая архитектура осталась той же — мы используем MediaSource Extension, DASH-протокол, модульную структуру с ABR-алгоритмом (Adaptive Bitrate) и менеджером буфера. Но для Smart TV пришлось добавить адаптационный слой, который учитывает ограничения железа и особенности платформ.

Главный вызов при адаптации — жёсткие ограничения по памяти. В ТВ доступно на порядок меньше оперативки, чем на смартфоне или ПК, и никакой Web API не даст доступа к низкоуровневым ресурсам — тут приходится экономить на всём. Наши действия: 

1. Минимизировали создание объектов, пересмотрев алгоритмы буферизации, устранили проблему каскадного заполнения памяти при загрузке сегментов 

2. Для gap detection отказались от массивов в пользу быстрого математического расчёта

3. Для ABR внедрили кеширование: вместо сотен новых объектов используем постоянные 

4. Очистку буфера после загрузки сегментов оптимизировали: вместо множественных вызовов выполняется один. К событийному потоку применили throttle: теперь не более 5 событий в секунду, чтобы избежать перегрузок и спайков

Для работы с кодеками мы ввели blacklist: многие устройства официально заявляют о поддержке VP9, H.265, но по факту их не воспроизводят. Этот список формируется исходя из жалоб пользователей и накопленной статистики, и на него легко накладывать исправления. Fallback на MP4 работает везде, так что пользователь всегда видит видео вне зависимости от устройства.

Также для каждой платформы мы сформировали список ограничений по FPS. Ниже приведу пример для телевизора на ОС Tizen. В списке видим линейку телевизоров, конкретные модели в ней, а ещё ограничения, связанные с FPS, в зависимости от конкретного разрешения видео. Эти ограничения мы зашили на уровне кода платформы.

"25TV_PREMIUM3": {
  models: [
    "S90F",
    "S90FD",
    "S95F",
    "S95FD",
    "LS03F",
    "MR95F",
    "QN90F",
    "QN90FD",
    "QN95F",
    "QN99F",
  ],
  fps: [
    [FULL_HD, 120],
    [ULTRA_HD, 60],
  ]
}

Опираясь на свой опыт тестирования и информацию от наших пользователей, реализовали внешний механизм управления ограничениями. Сам конфиг — JSON-структура следующего вида:

"vidaa": {
   "temporaryDisabled": Array<Version>,
   "minVersion": Version
   "5.5": {
        "DASH_SEP": {
          "max": Resolution
        }
   }
}

В примере — часть конфига для платформы VIDAA. Поле temporaryDisabled позволяет оперативно отключать плеер на конкретной версии ОС, когда это необходимо. minVersion служит минимальной версией, на которой может работать новый плеер. Далее для каждой версии платформы (в примере 5.5) мы описываем ограничения у разных форматов видео.

Затем уже в коде приложения этот внешний конфиг обрабатывается классом Restrictions. Он выделяет из общего конфига часть, касающуюся текущего устройства, и предоставляет небольшое количество методов для работы с ограничениями.

Первые результаты

Спустя год разработки и тестирования мы развернули веб-плеер на 100% залогиненных пользователей VK Видео на Smart TV. Результаты превзошли ожидания:

• длительность зависаний снизилась на 10%

• количество фатальных ошибок сократилось на 60%

• длинные столлы (больше 30 секунд) стали встречаться в два раза реже

• случаев, когда пользователь закрывал плеер на зависании, стало меньше на 30%

Преимущество веб‑плеера в том, что именно мы управляем логикой работы с манифестами и можем быстро адаптировать их под особенности конкретных устройств. Вот как мы следим за качеством — мониторинг устроен многоуровнево: 

• Метрики. Регулярно смотрим на время до первого кадра (first frame), длительность буферизаций (stall duration), процент пользователей, столкнувшихся со столлами, и ошибки воспроизведения

• Дашборды. У VK есть единая система для видео, куда стекаются все ключевые показатели. Мы можем отслеживать, как меняются метрики по регионам, какие модели телевизоров показывают худшие результаты и так далее

• Поддержка. Так узнаём о многих проблемах: пользователи пишут, что «на LG вчера всё зависло», и мы начинаем расследование. Часто проблемы специфичны для модели. Например, у LG webOS 2.0 (2016) есть баг: если отправить в буфер сегмент > 5 МБ, браузер падает. Мы добавили проверку: на webOS 2.0 разбиваем сегменты на части по 4 МБ

• Внутренние репорты. Иногда быстрее всех о багах сообщают коллеги внутри компании: присылают скриншоты в чатах, жалуются, когда на домашнем ТВ что-то «не играет». Дальше эти баги обрабатываются: QA-инженеры пытаются их воспроизвести, уточняют модель телевизора и условия, и только после этого задача попадает в разработку

Что дальше

Сегодня проект в разгаре внедрения: команда интегрирует веб-плеер и активно отлавливает баги. Но результаты уже есть:

• сократилось число критичных ошибок, и это напрямую коррелирует с улучшением пользовательского опыта в сотнях тысяч просмотров ежедневно

• диагностика неисправностей стала прозрачнее и быстрее

• заложена основа для новых функций, которые раньше были невозможны

В ближайших планах — раскатить плеер на неавторизованных пользователей, доработать поддержку DASH и ускоренное воспроизведение. 

Переход на веб-плеер для Smart TV стал стратегическим шагом для VK Видео. Теперь мы сами задаём правила работы с сетью, кодеками и ограничениями конкретных моделей, а не подстраиваемся под них. Для пользователей это улучшает опыт просмотра: видео запускается быстрее и воспроизводится стабильнее, как и должно. А для разработчиков открывает новый стек задач, где каждое решение требует инженерной смекалки. Телевизоры останутся особым миром, но теперь у нас есть свой инструмент, чтобы уверенно развиваться в нём.