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

Видеоплатформа – это программно-инфраструктурная система для полного жизненного цикла видео (приема, хранения, обработки, публикации, доставки, защиты, воспроизведения видео и анализа).

В простом виде сайт может разместить MP4-файл на сервере и открыть его через HTML-элемент <video>. Для нескольких небольших роликов этого иногда достаточно. Но такой подход плохо масштабируется, когда появляются:

• большие каталоги видео;
• пользователи с разной скоростью интернета и разными устройствами;
• прямые трансляции на большую аудиторию;
• субтитры и несколько аудиодорожек;
• платные видеоматериалы (или закрытый контент);
• требования к защите и отказоустойчивости трансляций.

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

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

Для видео по запросу типовой путь выглядит следующим образом:

• сначала загрузка;
• затем хранение исходника;
• анализ контента;
• транскодирование;
• подготовка HLS/MPEG-DASH;
• установка защитных мер;
• отправка на исходный сервер (origin);
• раздача по CDN (через Edge-узлы по всему миру);
• показ через видеоплеер;
• сбор статистики и аналитика.

У прямой трансляции начало цепочки отличается:

• захват камеры/энкодер;
• прием входного потока;
• транскодирование в реальном времени;
• подготовка выходного потока (HLS/DASH);
• отправка на узлы CDN;
• показ через видеоплеер.

На практике отдельные этапы могут выполняться одним сервисом или несколькими независимыми системами. Видеоплатформа объединяет эти компоненты в одну управляемую систему, и далее разберем какой она должны быть.

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

Поэтому один CDN или видеохостинг не является полноценной видеоплатформой, а наличие хранилища даже с видеоплеером не решает задачу потокового видео.

Типичная видеоплатформа – это RuTube, YouTube, Vimeo, онлайн-кинотеатр, образовательный видеосервис или корпоративный видеохостинг. Такие платформы состоят из двух больших частей: control plane (управление видео, пользователями, правами, метаданными) и media plane (загрузка, обработка и доставка самого видеопотока).

Архитектура видеоплатформы включает следующие компоненты:

1. Клиентские приложения. Web, iOS/Android, Smart TV и иногда приставки. В клиенте находится видеоплеер, который умеет работать с HLS/DASH, адаптивным битрейтом (Adaptive Bitrate Streaming), субтитрами, DRM, рекламой и аналитикой просмотра. Само видео обычно не идет через backend API, и клиент получает URL и скачивает сегменты напрямую через CDN.
2. API Gateway и бэкенд (backend). Серверная часть платформы (пользователи, авторизация, профили, каталоги, комментарии, плейлисты, лайки, подписки, история просмотров, платежи и т. д.). Шлюз выполняет маршрутизацию, ограничение скорости (rate limiting) и иногда аутентификацию. За ним могут находиться отдельные сервисы.
3. Загрузка видео. Отвечает за прием исходного видео. Пользователь запрашивает сессию загрузки; backend выдает временный URL; после чего файл обычно загружается напрямую в Object Storage, а не проходит через API-сервер, так как исходный файл может весить десятки гигабайт.
4. Media Processing Pipeline. После загрузки создается событие вроде VideoUploaded. Далее запускается асинхронный pipeline обработки. Видео проверяется, извлекаются метаданные, создаются thumbnails, распознается аудио, генерируются субтитры и другие операции.
5. Транскодинг. Исходное видео преобразуется в несколько вариантов качества, например 360p / 480p / 720p / 1080p / 4K. Могут использоваться кодеки H.264/AVC, H.265/HEVC, VP9 или AV1. Это довольно тяжелая вычислительная задача, поэтому обычно существует отдельный пул рабочих CPU/GPU, который можно автоматически масштабировать.
6. Упаковка (Packaging). Полученные видеофайлы режутся на небольшие сегменты, например по 2-6 секунд. Создается HLS (.m3u8) или MPEG-DASH (.mpd), чтобы работал адаптивный битрейт (плеер будет динамически переключаться между 1080p, 720p и 480p в зависимости от скорости соединения).
7. Объектное хранилище. В нем хранятся исходники, транскодированные версии, HLS/DASH-сегменты, thumbnails, субтитры и превью. Обычно это S3-совместимое распределенное хранилище, как PC-Storage. Видео не имеет смысла хранить непосредственно в реляционной БД.
8. Один из самых важных компонентов, ведь CDN кеширует видеосегменты на edge-серверах близко к пользователю, причем при cache hit до основного хранилища запрос вообще не доходит. Для большой платформы основная доля сетевого трафика приходится именно на CDN.
9. Служба воспроизведения. Когда пользователь нажимает Play, бэкенд проверяет права доступа: доступно ли видео, куплена ли подписка, разрешено ли оно в данной стране, есть ли родительские ограничения и т. п. После этого сервис выдает URL, часто с короткоживущей подписью. Для защищенного контента дополнительно можно подключить DRM.
10. Метаданные/каталог БД. Здесь находится информация о видео: video_id, название, автор, описание, длительность, статус обработки, конфиденциальность (privacy), категории, ссылки на thumbnails. Для транзакционных данных часто подходит PostgreSQL; для огромных нагрузок отдельные части могут переехать в другие решения.
11. Поиск и рекомендации. Поиск обычно вынесен отдельно и использует OpenSearch или собственный индекс. Рекомендательная система получает историю просмотров, клики, время просмотра, лайки и другие сигналы и строит кандидатов и рейтинг. На крупной платформе это целая ML-инфраструктура.
12. События и аналитика. Клиент постоянно отправляет события: video_impression, плей, пауза, поиск, буферизация, 25% просмотров, video_complete, ad_impression. Поток может идти через Kafka/PubSub, потоковую обработку, озеро данных. Эти данные нужны для статистики, рекомендаций, A/B-тестов, рекламы и мониторинга QoE (качества восприятия пользователем).

Проследим путь конкретного видео от момента загрузки.

Загрузка готового файла

Для видео по запросу VoD исходной точкой обычно является готовый файл. Это может быть MP4, MOV, MKV или другой поддерживаемый медиаконтейнер, который может загрузаться:

• через веб-интерфейс;
• через REST API;
• через S3 API;
• с удаленного сервера;
• из монтажной системы;
• из корпоративного хранилища;
• из другой медиаплатформы.

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

Прием прямой трансляции

У прямого эфира нет готового файла в момент начала трансляции. Камера, аппаратный кодер или программа вроде OBS создает непрерывный видеопоток и отправляет его в платформу. На входном участке могут использоваться, например:

• RTMP;
• SRT;
• RTSP;
• WebRTC;
• специализированные вещательные протоколы.

Важно не смешивать входные и выходные протоколы. Пример работы прямой трансляции ниже.

Какую роль играют основные протоколы

RTMP или SRT здесь используются для надежной доставки одного исходного сигнала до платформы, а HLS или DASH для массовой передачи зрителям. Это не жесткое правило, и конкретная роль протокола зависит от системы, но такое разделение помогает не путать технологии, которые решают разные задачи.

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

Перед обработкой необходимо определить технические характеристики файла: контейнер, видео- и аудиокодеки, разрешение, битрейт, частоту кадров, длительность и наличие дополнительных дорожек. Эту стадию можно назвать «проверкой», так как платформа считывает:

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

Для такого анализа часто используют ffprobe из состава FFmpeg:

ffprobe -v error -show_format -show_streams input.mp4

Конкретный инструмент не принципиален: это может быть собственный анализатор, FFmpeg или специализированная библиотека. Важно, чтобы дальнейший конвейер получил нормализованное описание исходника до запуска ресурсоемкого транскодирования.

На этом же этапе платформа должна выявить поврежденный контейнер, отсутствующую дорожку, неподдерживаемый кодек, некорректные timestamps и другие ошибки, из-за которых обработка или воспроизведение завершатся сбоем. Ранний отказ дешевле, чем несколько минут работы CPU/GPU с заведомо непригодным файлом.

Результат анализа сохраняется в базе метаданных, а в очередь обработки передается событие или задание, например, VideoUploaded или MediaReadyForProcessing. Дальнейшие операции выполняются асинхронно и не блокируют API-запрос пользователя.

Где хранятся исходник и метаданные

Исходник и сведения о нем обычно хранятся раздельно. Сам тяжелый файл размещается в объектном или файловом хранилище, а название, продолжительность, владелец, права доступа, состояние обработки и другие сведения – в базе данных видеоплатформы. Например:

ID видео:  78325
Название: interview-01
Продолжительность: 46:18
Разрешение: 3840×2160
Видеокодек: H.265
Статус: готово
Ключ объекта: masters/2026/08/78325.mov

Все это позволит искать и управлять видео без постоянного чтения самого файла.

Почему исходник лучше не удалять сразу

Оригинальный файл – это наиболее качественная версия контента, именно из него в дальнейшем можно заново подготовить видео:

• в другом разрешении;
• с другим кодеком;
• для нового типа устройств;
• с новой лестницей битрейтов;
• для другого стандарта потоковой передачи.

Если исходник удалить, повторное кодирование придется выполнять из уже сжатой версии. Каждая новая перекодировка с потерями может снижать качество, поэтому в крупных медиасистемах обычно различают:

1. Исходник – первоначальный файл максимально доступного качества.
2. Промежуточная мастер-копия – подготовленная высококачественная версия, если она предусмотрена рабочим процессом.
3. Версии для просмотра – файлы и потоки, предназначенные для конечного пользователя.

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

Транскодирование и адаптивный битрейт: зачем они нужны

Транскодирование – это преобразование исходного видео (или видеопотока) в один или несколько вариантов с другими параметрами. Могут меняться:

• кодек;
• разрешение;
• битрейт;
• частота кадров;
• параметры звука;
• контейнер.

Например, исходный файл: 3840×2160, H.265, 25 Мбит/с. Его можно преобразован в:

• 1920×1080 — 6 Мбит/с
• 1280×720 — 3 Мбит/с
• 854×480 — 1,5 Мбит/с
• 640×360 — 800 Кбит/с

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

При выборе параметров учитывают:

• видеокодек;
• тип изображения;
• частоту кадров;
• целевые устройства;
• ожидаемое качество;
• доступную полосу сети;
• возможности аппаратного декодирования.

Набор вариантов одного видео с разными битрейтами называют лестницей битрейтов. А возможность переключения между этими версиями для обеспечения плавного воспроизведения называется адаптивный битрейт.

Как работает адаптивное качество видео

Адаптивная потоковая передача позволяет менять качество прямо во время просмотра. Предположим, плееру доступны варианты 360p, 480p, 720p, 1080p. Когда соединение быстрое и буфер заполнен, плеер может выбрать 1080p, а если сеть замедлилась, следующая часть видео уже подгрузится в 720p или 480p. После улучшения соединения качество снова может увеличиться.

Алгоритм выбора может учитывать:

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

Цель такого алгоритма – поддерживать максимально возможное качество без остановок воспроизведения.

Почему для адаптивного видео важны ключевые кадры

Создать четыре файла разного разрешения недостаточно. Их временная структура должна быть согласована. Сжатое видео состоит из разных типов кадров. Ключевой кадр, или I-frame/IDR, содержит самостоятельное изображение и может служить безопасной точкой начала декодирования.

Последовательность между ключевыми кадрами называют группой кадров (Group of Pictures, GOP). Условно:

При подготовке нескольких вариантов качества ключевые кадры и границы сегментов желательно размещать в одних и тех же временных точках, что дает плееру возможность перейти, например, с 1080p на 720p на границе сегмента без нарушения временной линии.

Для HLS лучше, чтобы медиасегменты начинались с IDR-кадра, а варианты одного материала имели согласованные границы сегментов. Это напрямую влияет на стабильность адаптивного воспроизведения.

Почему потоковое видео делится на части

Большой MP4-файл можно передавать постепенно, но для современной адаптивной доставки видео обычно разбивается на короткие медиасегменты. Например, segment001.m4s / segment002.m4s / segment003.m4s / segment004.m4s и т. д. Отдельный файл описывает:

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

Этот файл называют манифестом, или файлом описания потока.

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

Еще пара слов о подготовке потоковой выдачи

Транскодирование создает видео нужного качества. Подготовка потоковой выдачи берет созданные аудио- и видеопотоки и формирует:

• сегменты;
• HLS-плейлисты;
• MPEG-DASH MPD;
• связи между вариантами качества;
• дополнительные дорожки;
• сведения для защиты контента.

Некоторые программные продукты выполняют оба действия одним модулем. В других архитектурах перекодирование и формирование потоковой структуры разделены. Так что наличие функции транскодирования еще не означает наличие полноценного контура HLS/DASH.

HLS или MPEG-DASH

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

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640×360
360/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1500000,RESOLUTION=854×480
480/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280×720
720/index.m3u8

Плеер выбирает подходящий список, а внутри него находятся ссылки на отдельные медиасегменты. HLS работает поверх HTTP, поэтому его можно обслуживать обычными веб-серверами и сетями доставки контента. Он используется и для готового видео, и для прямых трансляций.

MPEG-DASH также предназначен для адаптивной потоковой доставки через HTTP. Вместо M3U8 используется файл MPD (Media Presentation Description), в нем описываются периоды, варианты изображения, битрейты, разрешения, аудиодорожки, сегменты и временная шкала.

На уровне общей логики HLS и MPEG-DASH похожи, но форматы манифеста, требования клиентов, поддержка устройств и механизмы защиты различаются.

HLS или MPEG-DASH: что выбрать

Делить рынок по принципу «HLS для Apple, DASH для всех остальных» слишком грубо. Выбор зависит от устройств, плеера, DRM, существующей инфраструктуры и требований проекта.

MPEG-TS, fMP4 и CMAF: что находится внутри сегмента

HLS и MPEG-DASH описывают способ организации и доставки потока, но сами медиаданные еще должны быть упакованы в подходящую форму.

В HLS исторически широко применялись сегменты MPEG Transport Stream:

segment01.ts
segment02.ts
segment03.ts

В современных системах также используется фрагментированный MP4 – fMP4:

init.mp4
segment01.m4s
segment02.m4s
segment03.m4s

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

CMAF (Common Media Application Format) же задает общую модель медиасегментов на основе ISO Base Media File Format. Практическая ценность CMAF в том, что при совместимой архитектуре HLS и MPEG-DASH могут использовать одни и те же медиасегменты, различаясь главным образом файлами описания потока. Его использование уменьшит необходимость хранить две полностью независимые копии каждого сегмента.

CMAF, HLS и MPEG-DASH не взаимозаменяют друг друга:

• HLS и MPEG-DASH описывают доставку;
• CMAF описывает формат медиапредставления;
• H.264/H.265/AV1 определяют кодирование изображения.

Аудиодорожки и субтитры тоже входят в архитектуру

Видеоплатформа работает не только с изображением. Один материал может содержать оригинальную дорожку, разные переводы (на русский и английский, например), тифлокомментарий, субтитры, комментарии и т. д.

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

Для HLS также предусмотрены отдельные аудиоварианты и субтитры; для субтитров в соответствующем профиле используется WebVTT.

Для OTT-сервисов с несколькими языками правильная организация аудиодорожек может значительно влиять и на архитектуру, и на объем хранения.

Еще пара слов о видеоплеере

Видеоплеер – это не только интерфейс с кнопками, но и инструмент, который при потоковой передаче должен: получить адрес HLS или MPEG-DASH; загрузить манифест; определить доступные варианты качества; начать загрузку сегментов; накопить данные в буфере; запустить декодирование; оценить состояние соединения; при необходимости поменять качество; переключать аудио и субтитры; отправлять статистику просмотра. Подробнее о нем мы рассказали в этой статье.

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

После подготовки контента должен существовать источник, откуда сеть доставки получает сегменты и манифесты. Его обычно называют origin. По-русски удобнее говорить исходный или основной узел. Это не обязательно один физический сервер. В крупных системах источником может быть объектное хранилище или несколько серверов или даже специализированная система отдачи видео.

Сеть доставки обращается к этому слою, если нужного объекта еще нет в ее кэше.

Как CDN доставляет видео

CDN (сеть доставки контента) принимает запросы зрителей через распределенную инфраструктуру и по возможности отдает уже сохраненную копию медиасегмента. Подробнее о CDN вы можете прочитать в наших материалах:

• CDN – что это, как работает и кому нужна
• Как рассчитать расходы на хранилище и CDN для вашего проекта
• Мульти-CDN: раздача контента по всему миру без точек отказа

Суть в следующем: если десять тысяч зрителей обращаются непосредственно к origin, ему приходится самостоятельно обслуживать весь трафик, а вот при использовании CDN популярные сегменты кэшируются на распределенных узлах (Edge), что снижает нагрузку на исходный узел.

Конкретный Edge определяется архитектурой провайдера, сетевой маршрутизацией, доступностью, загрузкой и другими факторами. Например, в нашей платформе PC-Media подключено несколько CDN-провайдеров и балансировщик нагрузки, чтобы в случае выхода из строя одного из узлов, весь трафик перенаправлялся на другой, а не простаивал.

Cache hit и cache miss в CDN

Если нужный медиасегмент уже хранится на узле CDN, происходит попадание в кэш (cache hit). Если копии нет, возникает промах кэша (cache miss), и CDN обращается к исходному узлу.

Долю запросов, которые обслуживаются из кэша, называют коэффициентом попадания в кэш. Он зависит от:

• времени хранения объекта в кэше;
• структуры URL;
• параметров запроса;
• HTTP-заголовков;
• популярности видео;
• географии аудитории;
• правил CDN;
• частоты изменения контента.

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

Чем кэширование прямой трансляции отличается от VoD

У готового видео набор сегментов известен заранее. После публикации объект вида «movie/720p/segment-0812.m4s» обычно больше не меняется. Его можно эффективно сохранять в кэше.

В прямом эфире система непрерывно создает новые сегменты:

• в 12:00:00 появляется segment-100;
• в 12:00:06 – segment-101;
• в 12:00:12 – segment-102.

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

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

Почему исходный узел не всегда стоит открывать зрителям

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

• обойти токенизацию CDN;
• получить прямую ссылку;
• создать неконтролируемую нагрузку на источник;
• обойти часть правил географического доступа;
• увеличить исходящий трафик с хранилища.

Поэтому для защищенного контента исходный контур обычно ограничивают так, чтобы обращаться к нему могли только доверенные сервисы или сеть доставки. Либо подключают дополнительную защиту, но о ней дальше.

Почему видео может остановиться, даже если CDN работает

Проблема воспроизведения не обязательно находится в CDN. Причиной может быть любой участок цепочки, включая следующие проблемы:

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

Поэтому мониторинг только серверов или CDN дает неполную картину.

Для готового видео все операции можно выполнить заранее. Прямая трансляция должна обрабатываться одновременно с поступлением сигнала. Типовой путь:

1. Камера/OBS/энкодер.
2. RTMP или SRT + резервируемый прием.
3. Транскодирование в реальном времени.
4. HLS/DASH.
5. Отправка на Origin и далее на CDN.
6. Показ на плеере.

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

Поэтому live-системы предъявляют более жесткие требования к задержке, стабильности источника, резервированию, производительности кодировщиков, работе CDN и мониторингу.

Откуда появляется задержка прямой трансляции

Задержка между реальным событием и изображением на экране складывается из нескольких участков.

Во-первых, суммарная end-to-end latency, которая включает время захвата, кодирования, передачи до платформы, обработки, сегментации, доставки через CDN, заполнения буфера и декодирования на устройстве.

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

Сама архитектура зависит от сценария: для телеканала допустима одна задержка, для спортивного события требования могут быть жестче. Для видеозвонка или удаленного взаимодействия обычно нужны технологии реального времени, например WebRTC, а не классическая схема обычного HLS.

Как прямая трансляция превращается в запись

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

Данный сценарий применяется и для вебинаров, и для телеканалов, спортивных мероприятий, эфиров и т. д.

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

Какие показатели характеризуют качество просмотра

Для видео полезно отдельно оценивать качество восприятия пользователем (QoE, Quality of Experience). К числу распространенных технических показателей относятся:

1. Время до начала воспроизведения, то есть сколько прошло между нажатием Play и первым показанным кадром.
2. Повторная буферизация – сколько раз и как долго просмотр останавливался из-за недостатка данных в буфере.
3. Ошибки запуска – какой процент попыток просмотра завершился до начала воспроизведения.
4. Средний фактический битрейт – в каком качестве пользователь в действительности смотрел большую часть видео.
5. Переключения качества – как часто плеер переходил между вариантами потока.
6. Время просмотра – сколько времени пользователь фактически воспроизводил контент.

Критические ошибки плеера

Например:

• недоступный сегмент;
• несовместимый кодек;
• ошибка DRM;
• потеря сетевого соединения;
• неверный манифест.

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

Защита видео состоит из нескольких независимых слоев.

Авторизация пользователя

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

Временные и подписанные ссылки

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

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

DRM

DRM – это система управления цифровыми правами, она применяется для защищенной доставки коммерческого контента. Видео шифруется, а устройство зрителя должно получить разрешение на его расшифровку.

В браузерных системах для этого применяется, в частности, Encrypted Media Extensions (EME). Этот программный интерфейс связывает веб-плеер с механизмом расшифровки защищенного контента.

Упрощенно представлено на схеме ниже.

DRM не заменяет авторизацию пользователя, а временная ссылка не заменяет DRM. Эти механизмы защищают разные участки системы, но оба метода представлены в PC-Media.

Для понимания масштабирования полезно разделить систему на два логических контура:

1. Медиаконтур – здесь передаются тяжелые файлы и потоки
2. Контур управления – здесь проходят относительно небольшие служебные запросы, такие как авторизация, метаданные, API, команды публикации, настройки плеера и подобные.

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

Зачем видеоплатформе очередь заданий

Обработка видео редко состоит из одного действия. После загрузка исходника может запустить технический анализ, создание кадров для превью, транскодирование, формирование HLS, подготовку субтитров и т. д.

Если одновременно поступили тысячи файлов, выполнять все задачи сразу нельзя, для этого в крупных системах используется очередь обработки, которая позволяет:

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

Это типовой архитектурный принцип, конкретная реализация очереди зависит от продукта.

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

• резервные источники live-сигнала;
• несколько кодировщиков;
• повторный запуск неудачных задач;
• репликацию хранилища;
• несколько исходных узлов;
• балансировку нагрузки;
• несколько CDN;
• проверку доступности потоков;
• автоматическое переключение;
• независимый мониторинг;
• резервное копирование метаданных.

Не каждый проект требует всех перечисленных механизмов. Для внутреннего архива из нескольких десятков роликов мульти-CDN будет избыточен, а вот для крупной спортивной трансляции сбой одного участка может затронуть десятки тысяч зрителей, поэтому цена отказоустойчивости совершенно иная.

Пример, что происходит с .mov после загрузки

Теперь соберем весь путь в один сценарий. Предположим, пользователь загружает видеофайл .mov со следующими характеристиками:

• 3840×2160;
• 265;
• 25 кадров/с;
• одна аудиодорожка;
• продолжительность 40 минут.

Шаг 1. Файл попадает в хранилище

Платформа сохраняет оригинал и присваивает ему внутренний идентификатор.

Шаг 2. Выполняется технический анализ

Система определяет кодек, разрешение, звук, частоту кадров и длительность.

Шаг 3. Создаются варианты качества

Например, 1080p, 720p, 480p. Конкретные битрейты рассчитываются под кодек и тип контента. Важно помнить, что выше качество сделать нельзя.

Шаг 4. Выравниваются ключевые кадры

Точки, в которых будут начинаться сегменты разных вариантов, синхронизируются.

Шаг 5. Формируется потоковая структура

Создаются медиасегменты, HLS M3U8, при необходимости MPEG-DASH MPD, аудиодорожки или дополнительные данные.

Шаг 6. Настраивается доступ

Публичному видео может быть достаточно обычного доступа через CDN. Для закрытого могут добавляться авторизация, подписанные URL, DRM, географические ограничения.

Шаг 7. Зритель нажимает Play

Плеер получает манифест.

Шаг 8. Плеер выбирает качество

Допустим, сначала загружается 720p.

Шаг 9. Сегменты поступают через CDN

Если конкретный сегмент уже есть в кэше, исходный узел не участвует в этом запросе.

Шаг 10. Интернет-соединение пользователя ухудшается

Плеер видит, что следующие сегменты загружаются слишком долго, и переходит на 480p.

Шаг 11. Система собирает телеметрию

Фиксируются предусмотренные платформой сведения о просмотре и технических событиях. Именно эта последовательность отличает полноценную видеосистему от простого размещения MP4-файла на веб-сервере.

Полноценная инфраструктура нужна не всегда. Если компания публикует десять небольших публичных роликов и ей не нужны прямые трансляции, DRM, транскодирование в несколько качеств или сложной аналитики, то вам хватит: объектное хранилище, CDN и стандартный HTML5-плеер.

Можно самостоятельно подготовить MP4 или HLS и разместить их в S3, что будет проще и дешевле в сопровождении. А вот полноценная видеоплатформа будет полезнее, если нужно автоматизировать загрузку контента, транскодирование, автоматизация прямых трансляций, запись и публикация эфиров, а также работать с огромным каталогом медиаконтента.

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

Советы что нужно проверить

1. Храните мастер-копию, если ее нельзя легко получить заново. Особенно это важно для оригинального медиаконтента.
2. Определяйте лестницу качества под контент и не копируйте универсальный набор битрейтов без тестирования.
3. Синхронизируйте ключевые кадры между вариантами, это важно для корректного адаптивного переключения.
4. Разделяйте прием сигнала и доставку зрителю – протокол, подходящий для студийного источника, не обязательно нужен конечному пользователю.
5. Не смешивайте хранилище и каталог медиаданных.
6. Планируйте аудиодорожки и субтитры заранее.
7. Настраивайте кэш отдельно для разных типов объектов (манифест и неизменяемый медиасегмент выполняют разные функции).
8. Тестируйте реальные устройства, ведь проверки только в Chrome на рабочем компьютере недостаточно.
9. Измеряйте качество со стороны зрителя, успешный HTTP-ответ еще не значит успешный просмотр.
10. Для критичных трансляций проектируйте резервирование до эфира.

PC-Media от PlatformCraft можно рассматривать как пример модульной реализации функций, описанных выше.

Наша медиаплатформа объединяет хранение контента, VoD, прямые трансляции, CDN, транскодирование, запись видеопотоков, Playout, HTML5-плеер, защиту и монетизацию, а также поддерживает интеграцию через S3 API, REST API и sFTP.

Для транскодирования PlatformCraft указывает подготовку синхронизированных по времени потоков с разными размерами кадра и битрейтами. Есть совместимость с RTMP, RTSP, HLS, MPEG-DASH, WebRTC и SRT. Брендированный плеер поддерживает HLS, MPEG-DASH, WebRTC и MSE.

Для доставки контента мы используем сеть из более чем 5000 CDN-узлов и балансировщик нагрузки. Хранение в PC-Media распределено между тремя дата-центрами в России, что обеспечивает SLA 99,99%. Вы можете протестировать нашу видеоплатформу совершенно бесплатно.

Что такое видеоплатформа?

Видеоплатформа – система для приема, хранения, обработки, доставки и воспроизведения видео. Она может включать транскодирование, HLS/MPEG-DASH, CDN, плеер, live, защиту и аналитику.

Чем видеоплатформа отличается от видеохостинга?

Видеохостинг обычно ориентирован на загрузку, хранение и публикацию роликов. Видеоплатформа может дополнительно предоставлять инфраструктурные функции: прямой эфир, транскодирование, CDN, API, запись потоков, Playout, DRM и интеграции.

Что происходит с видео после загрузки?

Обычно файл сохраняется, анализируются его технические характеристики, затем при необходимости создаются несколько вариантов качества. После этого материал подготавливается к HLS или MPEG-DASH, публикуется и доставляется пользователям через исходный контур и CDN.

Зачем транскодировать видео?

Чтобы подготовить варианты, совместимые с нужными устройствами и условиями сети. Один исходный файл можно преобразовать в несколько разрешений и битрейтов для адаптивного воспроизведения.

Что такое лестница битрейтов?

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

Зачем синхронизировать ключевые кадры?

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

Чем кодек отличается от контейнера?

Кодек определяет способ сжатия аудио или видео: например, H.264 или H.265. Контейнер объединяет медиапотоки и служебные данные в файл: например, MP4 или MKV.

HLS – это кодек?

Нет. HLS – это технология потоковой доставки. Внутри HLS может передаваться видео, закодированное, например, H.264 или H.265.

Чем HLS отличается от MPEG-DASH?

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

Что такое CMAF?

CMAF – это формат медиапредставления, позволяющий в определенных архитектурах использовать общие фрагментированные MP4-сегменты для разных систем потоковой доставки, включая HLS и MPEG-DASH.

Зачем видео делить на сегменты?

Сегменты позволяют начать воспроизведение до получения всего ролика, переключать качество во время просмотра и эффективно кэшировать медиаданные в CDN.

Зачем видеоплатформе CDN?

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

Может ли S3 заменить видеоплатформу?

Нет, но для простого сценария S3 может быть достаточно как хранилища. Если видео подготовлено заранее, его можно разместить в S3 и отдавать через CDN. Транскодирование, live, DRM и аналитика потребуют дополнительных компонентов.

Почему видео буферизуется даже при использовании CDN?

Причина может находиться в исходнике, транскодировании, лестнице битрейтов, сегментации, CDN, интернет-соединении зрителя, поддержке кодека или алгоритме плеера. CDN устраняет только часть возможных узких мест.

Что лучше для прямой трансляции: RTMP, SRT, HLS или WebRTC?

Они решают разные задачи. RTMP и SRT часто используются для доставки входного сигнала в видеоплатформу, HLS лучше для масштабируемой передачи зрителям, а WebRTC для интерактивных сценариев, где особенно важна низкая задержка.

Когда полноценная видеоплатформа не нужна?

Если проект публикует небольшое количество готовых публичных роликов и не требует live, DRM, автоматического транскодирования и сложной аналитики, может быть достаточно объектного хранилища, CDN и обычного видеоплеера.