КАК УСТРОЕНО ВСЁ - приложение J

Как работает видеозвонок: от нажатия кнопки до картинки на экране

Захват, кодирование, UDP, буферизация и эхоподавление - полная цепочка за те секунды, пока устанавливается соединение

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

📸 Шаг первый: захват

Камера делает снимки с частотой 30 кадров в секунду. Каждый кадр в разрешении 720p - это 1280×720 пикселей, три байта на пиксель - около 2,8 мегабайта несжатых данных. Тридцать таких кадров в секунду - около 84 мегабайт в секунду только для видео. Передавать такой поток по сети невозможно: среднее домашнее подключение даёт 10-50 Мбит/с на отдачу, и большая часть нужна для других задач.

Параллельно микрофон оцифровывает звук: 48 000 измерений в секунду, 16 бит на измерение - около 96 килобайт в секунду несжатого аудио. Это терпимо само по себе, но тоже требует сжатия.

Оба потока - видео и аудио - немедленно передаются кодеку.

🗜️ Шаг второй: кодирование

Видео сжимается кодеком - чаще всего H.264 или VP8/VP9 для видеозвонков, реже AV1 (он эффективнее, но требует больше вычислений). Кодек применяет межкадровое сжатие: хранит полный ключевой кадр раз в секунду, а остальные кадры - только изменения относительно предыдущего. Неподвижный фон, который занимает 80% кадра, передаётся лишь однажды.

В результате видеопоток для звонка занимает 500-2000 кбит/с вместо 84 мегабайт в секунду - сжатие в сотни раз. Аудио кодируется специальным кодеком Opus: он разработан именно для голосовой связи в реальном времени и даёт отличное качество при 32-64 кбит/с с задержкой кодирования около 20 миллисекунд.

💡 Почему видео «пикселизируется» при плохом соединении: Кодек постоянно отслеживает доступную полосу и адаптирует степень сжатия. Когда канал сужается - кодек выбрасывает больше деталей, снижает разрешение или уменьшает частоту ключевых кадров. Именно поэтому изображение сначала становится размытым и «мыльным», а потом рассыпается на крупные блоки: кодек пытается уложиться в доступный битрейт любой ценой.

📦 Шаг третий: упаковка в пакеты и передача

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

Поверх UDP работает протокол RTP (Real-time Transport Protocol). Он добавляет к каждому пакету метку времени и порядковый номер. Получатель по этим данным понимает, в каком порядке собирать пакеты и какие потерялись.

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

🔄 Шаг четвёртый: сервер посередине

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

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

📌 WebRTC - открытый стандарт для звонков в браузере: Большинство видеозвонков прямо из браузера (Google Meet, Jitsi, многие другие) построены на WebRTC - открытом стандарте, встроенном в Chrome, Firefox и Safari. WebRTC берёт на себя всё: захват камеры и микрофона, кодирование, установку соединения через NAT, шифрование. Разработчику достаточно написать несколько строк JavaScript, чтобы получить полноценный видеозвонок. Именно благодаря WebRTC видеосвязь из браузера без установки плагинов стала возможной.

🔊 Шаг пятый: приём и воспроизведение

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

Для этого существует буфер джиттера: небольшой запас пакетов, который приложение накапливает перед воспроизведением - обычно 50-150 миллисекунд. Пакеты раскладываются по порядку и воспроизводятся равномерно. Если пакет потерялся совсем - декодер интерполирует: восстанавливает недостающий кадр или звук на основе соседних. Короткие потери при этом практически незаметны.

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

⏱️ Сколько времени занимает вся цепочка

Этап Задержка
Захват кадра камерой ~33 мс (при 30 кадр/с)
Кодирование видео 10-50 мс
Передача по сети (в пределах страны) 10-40 мс
Буфер джиттера 50-150 мс
Декодирование видео 5-20 мс
Отображение на экране 1-16 мс
Итого (типично) 100-300 мс
Задержка до 150 мс воспринимается как нормальный разговор. При 150-300 мс - заметны паузы, люди начинают перебивать друг друга. Свыше 400 мс - разговор становится некомфортным, как в старых международных звонках через спутник.

🔗 Всё вместе

Видеозвонок - это весь цикл «Как устроено всё» в действии за одну секунду. Камера - периферия из статьи 1.6. Кодирование - процессор и GPU из статей 1.3 и 1.6. UDP и RTP - сетевой стек из статей 3.3 и 3.5. NAT и маршрутизация - из статьи 3.4. Буфер в памяти - из статьи 1.4. Декодирование и вывод на экран - из приложений C и D. И всё это переключается и управляется операционной системой из раздела 2.

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


ANY.BY

Нужна помощь с техникой? Привозите - диагностика при заказе ремонта бесплатна. Контакты и запись.

Посмотреть, чем платят за гладкий звук в звонке Интерактив: одни и те же пакеты и три размера запаса - от нуля до такого, при котором дырок не остаётся. Открыть демо →