В 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‑контента.
Замерять и контролировать эффект от этих изменений помогает наша лаборатория качества — в ней мы тестируем наш транскодер видео и плеер на реальных устройствах в разных сетевых условиях. Как устроен этот процесс, показываем в отдельной статье.
Как будут развиваться технологии под капотом видеоплатформы, будем рассказывать и дальше.
Комментарии (64)
lexxsu
24.02.2026 07:42Не думали над аппаратными решениями, на FPGA или заказать на аутсорс полностью свое ядро ?
Понятно что 2й вариант стоит бесконечное количество денег, а еще и знающих команд нет, но на FPGA можно обкатать на будущее и энергии это будет потреблять гораздо меньше и быстрее работать.
adshpagin Автор
24.02.2026 07:42Да, думаем про FPGA и ASIC. Пока в стадии изучения рынка, что вообще есть и что реально закупить.
Нам очень важно удобство эксплуатации и расширяемость. Что-то очень кастомное, скорее всего, не сможем затащить и поддерживать потом.
lexxsu
24.02.2026 07:42Поддерживать сможете, оно на базовом уровне мало отличается от того же ffmpeg. А вот затащить, как вариант, объединиться с кем то ещё, тема реализуема, хоть и с трудом.
adshpagin Автор
24.02.2026 07:42Я скорее про трудности поддержки и обслуживания нестандартного железа.
Плюс есть шанс получить вендерлок, если заложиться на какую-то конкретную модель FPGA/ASIC.
lexxsu
24.02.2026 07:42Возможно, в теории китайцы могут сделать у себя, а тут заложить как какой-нибудь грант от государства. В Европах тоже не всё сами делают,.
nekipelov
24.02.2026 07:42Не рассказали самое интересное. Как именно у вас выполняется перекодирование видео? Это делается на CPU/GPU/ASIC? Какое железо и какое ПО для этого используется?
adshpagin Автор
24.02.2026 07:42Сейчас мы транскодим и на x86 CPU и на GPU Nvidia. Про ASIC думаем, но пока только присматриваемся, подробнее про ASIC написал в ответе на комментарий выше.
Кодирование на CPU удобно с точки зрения масштабируемости в облаке, поэтому на него приходится существенная доля транскодинга.
Транскодер у нас самописный, основаный на библиотеках ffmpeg'а.
yarovikov
24.02.2026 07:42В 2026 году платформа VK Видео стала лидером в России по ежедневной и ежемесячной аудитории. За этим результатом стоит не только рост числа авторов и объёма контента. В его основе системное развитие технологий
Так и запишем, а не отсутствие конкуренции и то, что авторам некуда идти по большому счету.
Вообще, конечно, удивительно, что у меня ютуб через впн работает в разы быстрее и стабильнее, чем вк без оного. А про алгоритмы предложки, толком не работающий плеер в сафари и пр приколы даже писать не хочется
JediPhilosopher
24.02.2026 07:42Мне тут на Хабре недавно попадалась статья про кодеки видео у разных платформ. Там автор писал об огромном прогрессе за последние 10 лет, все крупные видеоплатформы изобретают свои проприетарные закрытые кодеки. И они уже ушли далеко вперед от открытых и публично доступных, разница в объеме одного и того же файла буквально в разы уже.
И YouTube и китайцы тут впереди планеты всей.
Поэтому они могут обеспечить гораздо лучшее качество при той же толщине канала до пользователя и намного меньшую задержку начала воспроизведения. Просто потому, что youtube надо передать в полтора-два раза меньше данных на своем проприетарном кодеке, чтобы начать играть то же видео, чем условному рутьюбу или вк видео, которые используют устаревшие но открытые решения.
lexxsu
24.02.2026 07:42Нет никаких проприетарных кодеков (уже нет). Даже Гугл один не потянет сегодня сделать такое.
К сведению, сейчас заканчивается стандартизации последнего из классических (без применения нейронных сетей), одну из основных ролей там как раз играет Гугл, но также и Apple, Netflix, Intel и много других. Я имею ввиду AVM/AV2, так там сложность только декодера повысилась в несколько раз, а энкодера более десяти (на порядок сложнее) и при этом битрейт снизили "всего лишь" на 25%.
ganzmavag
24.02.2026 07:42Странно, в том тексте даже не один и не два проприетарных кодека упомянуты: https://habr.com/ru/articles/965452/
lexxsu
24.02.2026 07:42Не совсем корректно написано.
В статье под кодеками понимается конкретная имплементация/реализация энкодера. Стандарт в котором они работают одинаков, однако вопрос как реализовано предсказание и процесс кодирования, и они различны для каждой из компаний. Но в итоге, любое устройство, соответствующее стандарту может воспроизводить это видео. Т.е. это не проприетарный кодек, а свой путь реализации одного и того же стандарта.
adshpagin Автор
24.02.2026 07:42Именно так, в статье Дмитрия Сергеевича Ватолина говорится про собственные реализации стандартов.
Разработать свой кодек в значении свой стандарт задачка не из простых.
Стоит учесть, что в современных пользовательских устройствах есть аппаратные декодеры для H.264, VP9, AV1, которые удешевляют декодирование в терминах CPU и потребления батарейки.
Новый стандарт без поддержки со стороны производителей девайсов будет существенно проигрывать существующим стандартам, так как его софтверная реализация будет потреблять заметное количество CPU и батарейки.
lexxsu
24.02.2026 07:42Это скорее из серии бесполезных работ. Но сейчас все идёт к применению AI который рисует кадр, вот этого добра вскоре появится много и их уже можно будет отнести к собственным кодекам, которые никому не нужны.
sanek184
24.02.2026 07:42Сделайте возможность выбора кодека при воспроизведении на h264. А то смысл от h264 если в браузере подается av1/vp9 и на старых видеокартах он аппаратно не декодируется
ChilliWil
24.02.2026 07:42Разница в объеме файла есть, но она достигается за счет многопроходного кодирования. Вк чтобы не жечь цпу скорее всего жмет в один проход с консервативными настройками, отсюда и больший размер или мыло на том же битрейте
ganzmavag
24.02.2026 07:42Многопроходное не влияет на это, оно нужно только если задача строго вписаться в конкретный размер файла, например для записи CD так делали. Эффективность кодирования от этого не меняется, меняется только распределение битрейта по видео.
ChilliWil
24.02.2026 07:42Импортозамещение с турбонаддувом) Когда тебе отключают гравитацию волей-неволей научишься летать
Главное чтобы сервера не расплавились от такого "системного развития"
Arty_Fact
24.02.2026 07:42В 2026 году платформа VK Видео стала лидером в России по ежедневной и ежемесячной аудитории.
Поздравляем
За этим результатом стоит не только рост числа авторов и объёма контента. В его основе системное развитие технологий: мы последовательно масштабируем инфраструктуру, совершенствуем пайплайны обработки видео и инвестируем силы в стабильность воспроизведения на всех пользовательских устройствах и при любых условиях сети.
Ага, ВК стал настолько развитым, его инфраструктура стала такой замечательной, что его сервера не деградируют. Поэтому все авторы и пошли к ним.
/s
Neusser
24.02.2026 07:42Так вот она, та самая миллионная статья!
Lord_of_Rings
24.02.2026 07:4216 февраля ID первалил за 1М. Я решил посмотреть куда же делся миллионик - он был в черновиках у @Nomad_77, а сегодня под ним публикуется ВК...
techevangelist
24.02.2026 07:42Теория заговора, не иначе. На самом деле, если бы было что-то незаконное, модераторы уже должны был отреагировать
Lord_of_Rings
24.02.2026 07:42Habr продал этот ID блогу ВК - тут все описано https://habr.com/ru/articles/990586/comments/#comment_29589932
dimaaannn
24.02.2026 07:42Они даже номер поста умудрились импортозаместить в свою пользу )
Заходите на лучшую и стабильную платформу!
Lord_of_Rings
24.02.2026 07:42Habr продал этот ID блогу ВК - тут все описано https://habr.com/ru/articles/990586/comments/#comment_29589932
techevangelist
24.02.2026 07:42Ну тоже не криминал ведь. Красивая коммерческая история, если так. почему нет? Могу только поаплодировать пиарщикам, которые смогли себе позволить урвать айдишник.
m-rv
24.02.2026 07:42Меня зовут Алексей Шпагин, я руководитель разработки бэкенда видеоплатформы VK
Скажите пожалуйста, а если бы к вам на улице подошел человек и сказал: "меня зовут ХХХХХ ХХХХХХХ и я бью женщин" или "меня зовут ХХХХХ ХХХХХХХ и я отбираю деньги у детей", вы бы не подумали что... ну как бы всем понятно что такие люди существуют, но вот так открыто и беззастенчиво в этом признаваться - это какой-то верх наглости?
Refridgerator
24.02.2026 07:42Давайте честно - ВК Видео таки обходит РуТуб на 2 порядка по всем параметрам. И ещё более честно - околопиратского контента там ну прямо слишком много, чтобы списывать его на случайности. Кто-то целенаправленно его туда заливает в промышленных масштабах. Начиная от "Прибытия поезда" братьев Люмьер и заканчивая буржуйскими сериалами в стадии показа. Ну и опция скачать, чтобы после посмотреть оффлайн - ну реально огонь.
event1
24.02.2026 07:42Во-первых, это каперство, а не пиратство. Во-вторых, нетфликс богатый, от них не убудет.
zartarn
24.02.2026 07:42Мониторил немного это дело в последнее время. В отличии от рутуба в вк достаточно стабильно выпиливаются сериалы и фильмы. Их конечно периодически перезаливают, снова снова и снова, в т.ч. в зеркальном виде, Но все равно, вчера работал сегодня уже видео удалено.
RichardMerlock
24.02.2026 07:42И Главное, этот контент кто-то бессовестно смотрит и крадёт его в свои воспоминания, если успевает уловить суть.
ChilliWil
24.02.2026 07:42Cтатья вроде про высокие технологии, а по факту базовый ликбез про H.264 и HLS. Рассказали про FFmpeg так будто это какое то откровение 2026 года) А где самое мясо? Как они раскидывают задачи транскодинга на кластеры? Юзают ли аппаратные энкодеры типа NVENC или Quicksync, или молотят всt на CPU, обогревая дата-центры? Про архитектуру балансировщиков тоже как-то вскользь. Хотелось бы хардкора, а не статьи из Википедии
Grand_piano
24.02.2026 07:42Тут, вы не поверите, всё не так прозрачно, как вам кажется, NVENC & QuickSync могут сильно связать руки при подборе профилей кодирования + кодируют они БЕЗУСЛОВНО очень быстро, но не очень качественно, оставляя артефакты, это уже прям нужно дотошное сравнение, но там они есть. Но, например 144 будет вполне чем не кодируй.
adshpagin Автор
24.02.2026 07:42Да, с NVENC есть ряд сложностей, отчасти поэтому мы продолжаем много кодировать на CPU, не пытаемся полностью перейти на GPU или специализированное железо.
profotocor
24.02.2026 07:42Я недели две назад трем ИИшникам про FFmpeg рассказал - для них это как откровение было! Народ "базы" не знает! У многих как оказалось компьютеров нет - всё в телефоне (ИИ в чатботах), игры на плойке, музыка в умной колонке, видео на смарт ТВ. При этом на работу устраиваются как опытный пользователь ПК!!!
axe_chita
24.02.2026 07:42ВК Видео наверное самый худший из всех отечественных видеохостингов. Постоянные микрофризы с разрывом аудиодорожки, плеер с упорством маньяка пытается задрать битрейт причем это происходит при жестко выставленном пониженном качестве. И это сто процентов происходит при остановке воспроизведения и его включения. Регулярно зависающая реклама-зомби, которая висит на "осталось 5 секунд". Причем самое смешное в том, что даже остальные видеохостинги под крылом ВК (Вквидеолайф, дзен, видео.маил.ру) работают гораздо более адекватно. Так что, ВКВидео надо работать, работать и ещё раз работать над своим развитием и исправлением ошибок.
Astus
24.02.2026 07:42Мне на днях, буквально вчера или позавчера, ваш замечательный VK Видео радостно посредине просмотра написал "видео не загружается, понизьте качество", жаль сразу не заскриншотил. А я и так смотрел в 720p, потому как выше - одни сплошные проблемы.
Падение качества вплоть до 144p при обычной перемотке стрелочками вперёд-назад или мышью по прогресс-бару - так и не починили. Зависание и пропажу звука после рекламы в клиенте на iOS - тоже. Случайный сброс видео на начало в любой момент - также всё ещё в наличии. Качество в 1080p хуже чем у треклятого YT в 720p - на месте.
Тот, за счёт "деградации" которого, вы "стали лидером" - такого себе не позволял, ни разу ничего из перечисленного.
ArtyomOchkin
24.02.2026 07:42Да-да. И такое бывает даже во время трансляций, например, когда смотрел Формулу 1, иногда на ровном месте прерывалось. И это при хорошей скорости домашнего интернета, 5 ГГц WiFi, 300+ Mbit/s.
Neusser
24.02.2026 07:42при хорошей скорости домашнего интернета, 5 ГГц WiFi, 300+ Mbit/s.
Это именно что "домашний" интернет. От рутера до приемника. А если от провайдера до рутера 5Мбит/с, то от ваших 300 никакой пользы.
Dim2010
24.02.2026 07:42Нет вы посмотрите! Мы хвастаемся! Смотреть невозможно постоянные глюки! Интерфейс ЭТО НАДОЖЕ БЫЛО придумать, так расположить подписки! От большой любви к пользователям.
А уж что сотворили с банами. ВООООООТ Все нормальные люди которые пользовались ЮТУБ Твичем. знают, что если автор канала забанил, какого-то пользователя, то что?? Правильно ВЕСЬ МИР ЗАНЕТ пользователь переходит в режим МУТЕ и все довольны и пользователь продолжает смотреть канал.
А ТУТ ОХ ТУТ,.... Банится КАНАЛ от пользователя то есть ДЛЯ ПОЛЬЗОВАТЕЛЯ УДАЛЯЕТСЯ КАНАЛ и он его никогда больше не УВИДИТ , не НАЙДЕТ, и не получит доступа!
То есть такой пользователь будет видит что КАНАЛ ИСПАРИЛСЯ! А ОН ЕСТЬ!!!!!!!!! ПРОСТО в ВК такая КЛАСНАЯ система! КАКОЙ УЖАС и если просто как на ютубе автор не сошелся во мнении со зрителем, то тут... Получите все и по полной.
А техподдержки НЕТ ВООБЩЕ. У меня в контакте открывается мессенджер, а сообщения не отправляются! Горит красный восклицательный знак! И ВСЁ НЕТУ ДРУГИХ способов решить проблему! А ЗАЧЕМ? Мы же монополисты!
Grand_piano
24.02.2026 07:42Хммм, ну хвастаетесь понятно, а вот технологический стэк вообще не раскрыт.
Как миниму хотелось бы информации - а сколько файловых транскодеров установлено в платформе для подготовки контента? Разделяете ли вы видео и аудио дороги? Ну и соответственно следующий вопрос, а как собираетесь поддерживать мультиязычность если в будущем понадобиться? Какие аудио-кодеки сейчас используете? Игрались ли каким-либо образом с GOP длинной, к каким выводам для себя пришли? Что с субтитрированием, планируете ли? Рассматривали или уже рассматриваете каки-либо стандарты для дальнейшего использования. Ну и на сладкое:
А кодированием применяли на 264, VP9 двухпроходное, ну я надеюсь, а что с возможностью использования ИИ после первого прохода и подготовки AI сценария кодирования уже по готовому алгоритмичному сценарию? NetFlix таким баловался и у них очень неплохо получалось. Ну и конечно же - а как распределяете ферму траскодеров? По каким принципам (пофайлово или кто-то научился резать чанками)? Используется ли какие-либо системы для моделирования workflow систем транскодирования?Не всё, я замолкаю, а то уже сам начал хвастаться ))))
Grand_piano
24.02.2026 07:42АААА забыл - как боретесь с интерлейсингом???? Какие фильтры применяете, как боретесь с ошибками полей и т.д. Там прям целые труды можно писать.
denismartyanov
24.02.2026 07:42Зачем вам двухпроходное кодирование, когда crf существует уже давным-давно? Исключая конечно случаи, когда вам нужно попасть в конкретный размер, но онлайн стриминги это вряд ли тот случай.
Да и деинтерлейса я бы никак не ожидал от стриминга (ну может разве что как опцию при просмотре).
Впрочем про более подробные технические детали энкодинга и правда было бы интересно почитать.
altervision
24.02.2026 07:42Ожидание: "Мы используем следующие методы накрутки количества просмотров на наших видео и вот такие пути по натягиванию KPI совой на глобус, а ещё вот столько платим блоггерам, чтобы хоть кто-то у нас что-то публиковал"
Реальность: интересная техническая статейка, спасибки, ещё и пост-миллионник. Когнитивный диссонанс какой-то получается ...
rot97
24.02.2026 07:42Про кодеки, используемые в видеосервисах, недавно была статья https://habr.com/ru/articles/965452/
Grand_piano
24.02.2026 07:42Да, да, вот уж где хотелось всё руками помацать и прогнать пару сотен тестов + привлёчь фокус-группу для слепого тестирования.
mydigitalhabb
24.02.2026 07:42Когда в плеере VkVideo на LG Webos появится регулировка скорости, как на Ютубе ?
Невозможно же смотреть на x1 практически весь контент, хочется переключатели ускорения.
iBolitt
24.02.2026 07:42а я еще жду появление функционала изменения скорости у отмотанных трансляций.
Кстати изменение скорости у обычных видео есть в приложении вк видео для андроид тв и apple tv. На lg пока нету.
nihil-pro
24.02.2026 07:42Ясно, а когда сделаете чтобы видео не перезагружалось само, прямо во время просмотра?
iBolitt
24.02.2026 07:42Интересная статья. Хотелось бы похожую статью, но про стриминг и получение записи стрима. Почему у вас приходиться ждать получения записи. Одно дело, когда мы загружаем видео в вк видео, где у видео могут быть разные кодеки, разрешения, контейнеры. И их нужно перевести в h264 кодек для вк. А другое дело стримы, которые и так уже подаются в нужном h264 кодеке. То есть уже в готовом видео. Почему их просто после окончания стрима не показать.
Да, тут еще проводится ужимание битрейта, создание превьюшек для для показа при перемотки. Но это все же не полностью перекодировать в другой кодек. Да и делать это можно уже фоном. То есть пока происходит ужимание битрейта показывать оригинал сразу. А потом по мере готовности уже заменять оригинал на ужатый вариант.
ArtyomOchkin
24.02.2026 07:42О, миллионная статья (https://habr.com/ru/companies/vk/articles/1000000) :).
Но само по себе ВК видео то ещё кривое легаси, регулярные прерывания видео, иногда фризы. Это я ещё молчу про ваши другие видеоплееры вроде того, что в Мой мир@mail.ru, этот сервис вообще в начале 10х застрял.
Мало того, что в ВК видео реклама зависает, так даже при хорошем интернете видео вылетают с ошибкой загрузки.
Так что лучше всего продолжить использовать YouTube, на Андроид - с Byebyedpi, на Windows - с zapret/NoDPI/GoodbyeDPI.
Timofeuz
24.02.2026 07:42У меня с завидным постоянством падают вкладки вк видео, если их открыто штук 10 в FF.
GeorgeTudosi
24.02.2026 07:42Я довольно много работаю с Н264, в том числе в условиях необходимости жёсткой оптимизации по битрейту. Поскольку пайплайн один для своих проектов и для соцсетей, гайки закручиваются на всех видео одинаково. Подозреваю, что моё «сырое» видео окажется меньше того, что сделает из него транскодер ВК, при более высоком визуальном качестве.
Отсюда первый вопрос: а можно ли как-то заливать к вам файлы, минуя этап транскодирования? Мне не сложно подготовить все нужные разрешения, всё автоматизировано. Или, может быть, вы хотя бы проверяете, не получился ли ваш оптимизированный результат больше оригинала?
Чтобы не быть голословным, вот цифры по совсем свежему проекту: видео 3840×2160@25p, битрейт архивного файла 17.5 Mbps. Это ниже того, что вы предлагаете для отдачи в плеер через веб. А мой файл не только не имеет визуально заметных артефактов (проверял на самых разных экранах), но и пригоден для дальнейшей работы, в том числе с кеингом, который вообще очень чувствителен к дефектам.
То, что высовывается на веб, жмётся агрессивно. Артефакты уже видны, но при этом равномерны по площади кадра и времени, и поэтому не так сильно раздражают. Просто чуть хуже качество без явных провалов. И та же запись идёт уже с битрейтом 2.6 Mbps — меньше 720p из вашей таблицы, а у меня, на минуточку, 2160p.
Конкретные цифры, конечно, зависят от сложности и динамики изображения. Голливудское кино я так не пожму. Но подозреваю, что результат всё равно окажется заметно лучше вашего.
Расскажу об особенностях. Я не транскодирую видео, а всегда собираю из исходников, чтобы исключить потерю качества по дороге. Одно только это, по моим субъективным ощущениям, экономит 10–25% битрейта при одинаковом визуальном качестве. Более того, ранее испорченное видео уже не починить, сколько битрейта ни выдели, поэтому собранное из исходников всегда будет выглядеть лучше транскодированного.
Добиваюсь я этого кодированием с постоянным качеством, а не задавая битрейт. Плюсы: один проход, гарантированный и настраиваемый уровень артефактов. Минусы: непредсказуемый размер файла, выбросы битрейта на ключевых кадрах и сложных сценах.
Что можно улучшить, но у меня пока не дошли руки: кодировать с постоянным качеством, как сейчас, но жёстко ограничить битрейт внутри скользящего окна заданной длительности. Тогда качество пострадает минимально (будет рост артефактов на ключевых кадрах и сложных сценах), но не будет потенциальных проблем на тонком / нестабильном канале и на слабых устройствах.
Всё это наверняка можно упаковать в заклинание ffmpeg — мне не нужно, пользуюсь другим софтом, но возможности инструмента примерно представляю.
Если захотите пообщаться, пишите в личку.
Starina_js
24.02.2026 07:42Чуть хотелось бы больше узнать про защиту видео (DRM) и вставку рекламы в поток)
GeorgeTudosi
24.02.2026 07:42Эффективность защиты видео стремится к нулю, если это видео показывается на каком-нибудь экране. Воткните карту захвата в разрыв HDMI домашнего компа, разверните видео на весь экран, и привет.
Впрочем, буду рад ошибаться, и если уже есть эффективные способы защиты, прошу меня просветить.
Ну и, конечно, чуть сложнее технически и с потерей качества — съёмка на камеру с экрана. С этим вообще непонятно, что в принципе можно сделать. По этой же причине любая «защита от скриншотов» в приложениях — фикция.
Бороться с этими проблемами можно будет только когда начнём видеосигнал прямо в мозг засовывать, без этих нелепых оптических приборов на передней стороне головы.
abbasov-alexander
Мне казалось, что ffmpeg лет как 20 является стандартом для работы с видео. Помню как до появления ютуба мы его активно использовали на аутсорсовых проектах.
Про форматы сжатия было интересно, спасибо.