В 2026 году платформа VK Видео стала лидером в России по ежедневной и ежемесячной аудитории. За этим результатом стоит не только рост числа авторов и объёма контента. В его основе системное развитие технологий: мы последовательно масштабируем инфраструктуру, совершенствуем пайплайны обработки видео и инвестируем силы в стабильность воспроизведения на всех пользовательских устройствах и при любых условиях сети. Это постоянная инженерная работа, направленная на предсказуемое и стабильное качество сервиса при быстрорастущей нагрузке.
Меня зовут Алексей Шпагин, я руководитель разработки бэкенда видеоплатформы VK. В статье расскажу о технологиях, лежащих в основе VK Видео, и жизненном цикле контента на платформе: от загрузки и обработки до доставки зрителям.
Видеоплатформа VK: взгляд в целом
Видеоплатформа VK — это единая технологическая платформа, реализующая видеохостинг, видеостриминг и облачное хранение видео. Она предоставляет продуктам компании VK (среди них ВКонтакте, VK Клипы, VK Видео, Одноклассники и другие) функции загрузки, обработки, хранения и доставки видеоконтента. Так экспертность и технологическая инфраструктура для работы с видео сосредоточены на единой платформе, а сами продукты могут фокусироваться на своих бизнес‑задачах.
На платформу загружают видеоконтент, и она обрабатывает его, сохраняет и показывает пользователям‑зрителям. Также с её помощью проводятся прямые трансляции.
Упрощённо путь от создателя контента до зрителя выглядит так:
Автор контента загружает файл с видео (upload) — происходит приём бинарных данных.
Платформа преобразует видео (transcoding) — авторы могут загрузить видео в произвольном формате, а платформа преобразует его в унифицированный, чтобы зрители смотрели контент без технических проблем.
Видео сохраняется в хранилище (store).
Зритель смотрит видеоконтент, скачивая его с сервера (download).
Основные операции, необходимые для просмотра — загрузка, обработка, сохранение, — проходят син��ронно. Также видеоплатформа предоставляет дополнительные функции на базе ML, и они реализуются асинхронно. Это автоматическое распознавание речи для субтитров, категоризация контента, поиск дублей и другое. Обработка видео для реализации этих фич идёт параллельно с основным пайплайном транскодирования.
Помимо бэкенда, команда видеоплатформы разрабатывает собственный плеер, который поддерживает все популярные форматы для проигрывания видео. Он поставляется в составе SDK и используется внутри сервисов VK (например, ВКонтакте, VK Видео, в Дзене и Одноклассниках). Есть реализации плеера для всех популярных платформ: Android, Smart TV и Android TV.
В этой статье я хочу подробнее остановиться на последних трёх этапах жизненного цикла контента на нашей платформе: преобразовании, хранении и доставке до пользователей.
Преобразование загруженного видео
У любого видео есть три основных параметра:
разрешение (например, HD, Full HD, Ultra HD 4K);
количество кадров в секунду (например, 24, 30, 60);
длительность.
Есть важное понятие — битрейт. Это количество бит, которые занимает одна секунда видео. В контексте передачи видео по сети битрейт показывает, какая минимальная полоса пропускания канала нужна, чтобы смотреть видео без задержек. Так как видео обычно тяжёлое, то говорят не о битах, а о килобитах или мегабитах в секунду.
У несжатого видео огромный битрейт. Например:
Обозначение | Разрешение | FPS | Битрейт, Мбит/с |
HD | 1 280 × 720 | 30 | 660 |
Full HD | 1 920 × 1 080 | 30 | 1 500 |
Ultra HD 4K | 3 840 × 2 160 | 60 | 12 000 |
Очевидно, что хранить и передавать через интернет такие объёмы данных было бы крайне сложно и нецелесообразно, даже при всех современных технологиях. Поэтому сжатие — важный этап работы с любым видео.
Специфика кодирования видео
Сжатие «в лоб» (например, 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) и другими. Так плеер подстраивается п��д ширину канала пользователя. В авторежиме плеер выбирает то разрешение, которое пролезет в канал, и за счёт этого обеспечивает проигрывание видео без подкачки и подвисаний.
К адаптивному стримингу мы ещё вернёмся далее в статье. А в контексте хранения видео важно, что нам на бэкенде нужно заранее подготовить (нарезать) видео в разном разрешении.
В таблице приведены примеры битрейтов одного и того же видео, нарезанного в различных разрешениях.
Обозначение | Разрешение | H.264, Мбит/с |
Mobile | 256 × 144 | 0,2 |
Lowest | 456 × 240 | 0,4 |
Low | 640 × 360 | 0,8 |
Medium | 853 × 480 | 1,5 |
High | 1 280 × 720 | 3 |
Full HD | 1 920 × 1 080 | 6 |
Quad HD | 2 560 × 1 440 | 9 |
Ultra HD 4K | 3 840 × 2 160 | 18 |
Офтоп: небольшой лайфхак по работе с видео
Мне нередко нужно выполнять манипуляции с видео: извлекать звук, сохранять нужный кадр, переконвертировать или перекодировать файл. Раньше для этого я использовал сложные программы для монтажа — это было больно и избыточно.
Но погрузившись в работу с видео, я нашёл для себя удобное универсальное решение — 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. При потоковой передаче данных он идёт в таком порядке:
Пользователь обращается к сервису и получает манифест.
Клиентское приложение парсит манифест, выбирает оптимальное качество и получает информацию о нужном сегменте.
С этой информацией приложение обращается к серверу за нужным сегментом и получает его, и после этого начинается воспроизведение видео.
Затем по такому же принципу скачиваются второй, третий и 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‑контента.
Замерять и контролировать эффект от этих изменений помогает наша лаборатория качес��ва — в ней мы тестируем наш транскодер видео и плеер на реальных устройствах в разных сетевых условиях. Как устроен этот процесс, показываем в отдельной статье.
Как будут развиваться технологии под капотом видеоплатформы, будем рассказывать и дальше.
