Технологии в основе VK Видео: от загрузки файла до кадра на экране зрителя

В 2026 году платформа VK Видео стала ^[1] лидером в России по ежедневной и ежемесячной аудитории. За этим результатом стоит не только рост числа авторов и объёма контента. В его основе системное развитие технологий: мы последовательно масштабируем инфраструктуру, совершенствуем пайплайны обработки видео и инвестируем силы в стабильность воспроизведения на всех пользовательских устройствах и при любых условиях сети. Это постоянная инженерная работа, направленная на предсказуемое и стабильное качество сервиса при быстрорастущей нагрузке. 

Меня зовут Алексей Шпагин, я руководитель разработки бэкенда видеоплатформы VK. В статье расскажу о технологиях, лежащих в основе VK Видео, и жизненном цикле контента на платформе: от загрузки и обработки до доставки зрителям.

Видеоплатформа VK: взгляд в целом

Видеоплатформа VK — это единая технологическая платформа, реализующая видеохостинг, видеостриминг и облачное хранение видео. Она предоставляет продуктам компании VK (среди них ВКонтакте, VK Клипы, VK Видео, Одноклассники и другие) функции загрузки, обработки, хранения и доставки видеоконтента. Так экспертность и технологическая инфраструктура для работы с видео сосредоточены на единой платформе, а сами продукты могут фокусироваться на своих бизнес‑задачах.

На платформу загружают видеоконтент, и она обрабатывает его, сохраняет и показывает пользователям‑зрителям. Также с её помощью проводятся прямые трансляции.

Упрощённо путь от создателя контента до зрителя выглядит так:

1. Автор контента загружает файл с видео (upload) — происходит приём бинарных данных.

2. Платформа преобразует видео (transcoding) — авторы могут загрузить видео в произвольном формате, а платформа преобразует его в унифицированный, чтобы зрители смотрели контент без технических проблем.

3. Видео сохраняется в хранилище (store).

4. Зритель смотрит видеоконтент, скачивая его с сервера (download).

Основные операции, необходимые для просмотра — загрузка, обработка, сохранение, — проходят синхронно. Также видеоплатформа предоставляет дополнительные функции на базе ML, и они реализуются асинхронно. Это автоматическое распознавание речи для субтитров, категоризация контента, поиск дублей и другое. Обработка видео для реализации этих фич идёт параллельно с основным пайплайном транскодирования.

Помимо бэкенда, команда видеоплатформы разрабатывает собственный плеер, который поддерживает все популярные форматы для проигрывания видео. Он поставляется в составе SDK и используется внутри сервисов VK (например, ВКонтакте, VK Видео, в Дзене и Одноклассниках). Есть реализации плеера для всех популярных платформ: Android, Smart TV и Android TV. 

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

Преобразование загруженного видео

У любого видео есть три основных параметра: 

• разрешение (например, HD, Full HD, Ultra HD 4K);

• количество кадров в секунду (например, 24, 30, 60);

• длительность.

Есть важное понятие — битрейт. Это количество бит, которые занимает одна секунда видео. В контексте передачи видео по сети битрейт показывает, какая минимальная полоса пропускания канала нужна, чтобы смотреть видео без задержек. Так как видео обычно тяжёлое, то говорят не о битах, а о килобитах или мегабитах в секунду.

У несжатого видео огромный битрейт. Например:

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

Специфика кодирования видео

Сжатие «в лоб» (например, gzip) неэффективно для видео и обычно не позволяет существенно уменьшить его размеры. Но это не значит, что видео нельзя сжать. 

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

Чтобы эффективно сжать видео, видеоряд разделяется на Intra‑frame (ключевые кадры, или I‑кадры) и Inter‑frame (промежуточные кадры). При этом:

• ключевой кадр кодируется целиком, как фотография, и не зависит от других кадров

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

Промежуточные кадры бывают нескольких типов:

• P‑кадры (predicted picture) — берут информацию только из предыдущего кадра.

• B‑кадры (bidirectionally predicted pictures) — кадры, которые берут информацию из двух ближайших I‑ или P‑кадров. 

Работает это так:

• Первый кадр — ключевой и кодируется полностью.

• Второй — дельта‑кадр типа P, который ссылается на предыдущий ключевой кадр и кодирует только изменения (например, смещение точек).

• Далее — дельта‑кадр типа В, который ссылается на два соседних.

Все кадры компонуются в GoP (Group of Pictures). Пример структуры GoP:

Причём каждый новый GoP начинается с ключевого кадра, а величина GoP не фиксирована — её можно настроить. 

Разделение видеоряда на ключевые и промежуточные кадры, а также формирование GoP реализуют видеокодеки. Это алгоритмы и программы для кодирования (сжатия) и декодирования (распаковки) видео. 

Кодеки, которые мы используем

В видеоплатформе VK мы используем три основных видеокодека:

• H.264;

• VP9;

• AV1.

Современные кодеки (например, AV1) сжимаю�� видео лучше, чем широко распространённые классические (как H.264), но потребляют для этого значительно больше ресурсов CPU. 

Поэтому мы не можем кодировать все загружаемые к нам видео тремя кодеками сразу — на это уйдёт слишком много ресурсов. Мы вынуждены выбирать, и упрощённо алгоритм для выбора кодека выглядит так: 

• все новые видео, загружаемые на платформу, мы по умолчанию кодируем в H.264;

• если это ролик в VK Клипах, то мы кодируем его в VP9;

• если это контент популярного автора (с большим количеством просмотров на предыдущих видео), то кодируем его «тяжёлым» кодеком AV1.

При этом совместно с видеокодеком H.264 мы используем аудиокодек AAC (Advanced Audio Codec), а с VP9 и AV1 — аудиокодек OPUS.

Хранение контента

Для хранения закодированных кадров используются специальные форматы файлов. Помимо непосредственно видео и аудио, они хранят метаинформацию о количестве GoP, их структуре, аудио‑ и видеодорожках и других параметрах. Такие форматы называются медиаконтейнерами. Различных медиаконтейнеров довольно много, мы используем два:

• MP4 с кодеком H.264;

• WebM с кодеками VP9 и AV1.

Примечание. Важно понимать, что контейнер и кодек — разные сущности. 

В VK Видео и в подобных видеосервисах одно и то же видео может проигрываться с разным разрешением, например HD (720p), Full HD (1080p) и другими. Так плеер подстраивается под ширину канала пользователя. В авторежиме плеер выбирает то разрешение, которое пролезет в канал, и за счёт этого обеспечивает проигрывание видео без подкачки и подвисаний.

К адаптивному стримингу мы ещё вернёмся далее в статье. А в контексте хранения видео важно, что нам на бэкенде нужно заранее подготовить (нарезать) видео в разном разрешении.

В таблице приведены примеры битрейтов одного и того же видео, нарезанного в различных разрешениях.

Офтоп: небольшой лайфхак по работе с видео

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

Но погрузившись в работу с видео, я нашёл для себя удобное универсальное решение — FFmpeg (Fast Forward Moving Picture Experts Group). Это open‑source набор библиотек и утилит для работы с видео, которые позволяют легко решать многие задачи. Например, используя FFmpeg, можно:

• конвертировать файл из формата QuickTime в формат MP4 (ffmpeg -i record.mov record.mp4);

• извлечь из видео звук (ffmpeg -i video.mp4 -b:a 192K -vn music.mp3);

• сохранить условный (например, третий) кадр из видео в PNG (ffmpeg -i record.mov -frames:v 3 %04d.png);

• закодировать видео с заданным разрешением, FPS и битрейтом (ffmpeg -i record.mov -vcodec libx264 -b 100k -vf "fps=10,scale=640:480" -an out_bad.mp4).

Раздача видео зрителям

Теперь перейдём к этапу раздачи видео. Для начала вспомним некоторые сетевые протоколы и рассмотрим, как именно видеоконтент доставляется до пользователей через интернет.

С точки зрения транспортных протоколов у нас есть два на выбор:

• TCP — Transmission Control Protocol.

• UDP — User Datagram Protocol.

Между ними есть существенные отличия. Так, TCP:

• требует установки и поддержания соединения;

• гарантирует доставку и последовательность данных;

• контролирует поток и перегрузку сети.

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

С другой стороны, UDP:

• не гарантирует доставку данных;

• не гарантирует последовательность;

• не контролирует поток и возможные заторы;

• работает быстро.

Н�� уровне приложений для доставки видеоконтента используется протокол HTTP:

• HTTP/1.1, который базируется на TCP;

• HTTP/3 на базе протокола QUIC, который, в свою очередь, базируется на UDP.

Получение видео по HTTP

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

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

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

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

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:34

#EXTINF:33.033033,
video/4000000/segment-0.ts
#EXTINF:33.533534,
video/4000000/segment-1.ts
#EXTINF:24.941608,
video/4000000/segment-2.ts
#EXTINF:28.611945,
video/4000000/segment-3.ts
#EXT-X-ENDLIST

Работа с сегментами изменяет алгоритм получения видео по HTTP. При потоковой передаче данных он идёт в таком порядке:

1. Пользователь обращается к сервису и получает манифест.

2. Клиентское приложение парсит манифест, выбирает оптимальное качество и получает информацию о нужном сегменте.

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

4. Затем по такому же принципу скачиваются второй, третий и n‑сегменты до конца просмотра.

Мы для потоковой передачи видео используем два протокола: 

• HLS (HTTP Live Streaming);

• DASH (Dynamic Adaptive Streaming over HTTP).

Одно из отличий в работе протоколов — подход к манифестам.

Так, у HLS есть мастер‑манифест (или плейлист), в котором содержатся ссылки на манифесты конкретного качества (например, 240р, 720р).

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

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

Адаптивный стриминг

Далее рассмотрим, как работает адаптивный стриминг. 

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

На графике ниже — пример адаптации плеера к качеству канала пользователя:

• оценили качество сети, скачали сегмент в качестве 480р, начали воспроизведение;

• во время просмотра видео зафиксировали, что интернет стал лучше, скачали сегмент 720р;

• затем интернет стал ещё лучше — качаем сегмент 1080р;

• некоторое время видео играло в 1080p, но затем интернет стал хуже, и плеер принял решение играть 720p и так далее.

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

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

CDN (Content Delivery Network)

Один из ключевых инструментов в контексте раздачи видео зрителям для нашей видеоплатформы — это CDN (Content Delivery Network), географически распределённая сетевая инфраструктура для быстрой и надёжной доставки контента пользователям.

Наша CDN состоит из origin‑серверов в Москве и Московской области, а также более 160 геораспределённых площадок (кеш‑серверов) по всей России. Принцип работы с CDN довольно простой:

• пользователь обращается за нужным контентом на региональный кеш‑сервер;

• если контент доступен на площадке — скачивает видео из кеша;

• если нужного контента нет на региональном кеш‑сервере — скачивает его с origin‑сервера.

У нас особый подход к использованию балансеров. 

Классический механизм подразумевает, что пользователь идёт к load balancer, который по набору критериев определяет, к какому серверу на площадке лучше обратиться, и направляет пользователя на него. 

Но мы применяем другой механизм: сразу выдаём ссылки на конкретный сервер на площадке, минуя балансер. При этом в качестве бэкапа выдаётся ссылка на центральный ЦОД (на случай, если нужный кеш‑сервер недоступен).

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

Заключение

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

Сейчас мы работаем над:

• оптимизацией битрейта при сохранении визуального качества картинки;

• ускорением нарезки, сокращением потребления CPU при кодировании видео;

• оптимизацией хранения нарезанных качеств видео;

• улучшением качества звука, в частности, для UGC‑контента.

Замерять и контролировать эффект от этих изменений помогает наша лаборатория качества ^[2] — в ней мы тестируем наш транскодер видео и плеер на реальных устройствах в разных сетевых условиях. Как устроен этот процесс, показываем в отдельной статье ^[3].

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