Перейти к основному содержимому

Протокол RTP: передача аудио и видео в реальном времени

В этом тексте мы разберём протокол RTP (Real-time Transport Protocol) как основу передачи аудио‑ и видеоданных в реальном времени по сети. Материал ориентирован на самостоятельное изучение: каждое ключевое понятие сопровождается пояснением и примерами.

RTP

1. Назначение протокола RTP​

RTP (Real-time Transport Protocol) — это сетевой протокол, предназначенный для передачи медиа в реальном времени: аудио (речь, музыка) и видео (камера, экран, трансляции) по IP‑сетям.

Важно сразу понять его роль:

  • RTP не устанавливает соединение между участниками.
  • RTP не гарантирует доставку пакетов (не занимается повторной передачей потерянных данных).
  • Основная задача RTP — правильно упорядочить и синхронизировать медиаданные (кадры видео, аудиосэмплы) на приёмной стороне.

То есть, RTP — это «транспортный формат» для медиа в реальном времени, который опирается на другие протоколы более низкого уровня (обычно UDP) для доставки пакетов.

Пример ситуации использования RTP​

Представьте видеозвонок:

  • Ваше устройство захватывает звук с микрофона и картинку с камеры.
  • Эти данные кодируются (сжимаются) в определённый формат — например, видео в H.264, звук в Opus.
  • Затем закодированные медиафрагменты «упаковываются» в RTP‑пакеты и отправляются по сети.
  • На другой стороне устройство получает RTP‑пакеты, раскладывает их по времени и порядку, декодирует и воспроизводит.

Если несколько пакетов придут не по порядку или какой‑то пакет потеряется, именно механизмы RTP помогают приёмнику понять, что произошло, и максимально корректно воспроизвести поток.

2. Общая структура RTP-пакета​

Каждый RTP‑пакет состоит из двух основных частей:

  1. Заголовок (header) — служебная информация, которая помогает приёмнику правильно обработать данные.
  2. Полезная нагрузка (payload) — собственно фрагмент аудио или видео, закодированный соответствующим кодеком.

Заголовок имеет фиксированную структуру. Ключевые поля заголовка:

  • номер последовательности (sequence number);
  • метка времени (timestamp);
  • идентификатор источника SSRC (synchronization source);
  • тип полезной нагрузки (payload type).

Далее разберём эти поля по отдельности.

3. Номер последовательности: восстановление порядка пакетов​

Номер последовательности (sequence number) — это целое число, которое увеличивается на 1 для каждого нового RTP‑пакета в потоке.

Зачем нужен номер последовательности​

Сеть IP не гарантирует, что пакеты:

  • придут в том же порядке, в каком были отправлены;
  • не потеряются по пути.

Поэтому приёмник не может просто «верить» порядку прихода. Он использует номер последовательности, чтобы:

  1. Восстановить исходный порядок пакетов.
  2. Обнаружить потери (например, если после пакета с номером 100 сразу пришёл пакет с номером 102, значит 101 потерян).
  3. Корректно буферизовать поток, особенно когда задержки в сети различаются (джиттер).

Пример​

Отправитель посылает пакеты с номерами: 1, 2, 3, 4, 5.

Из‑за особенностей сети приёмник получает: 2, 1, 4, 5.

По номерам последовательности приёмник понимает:

  • нужно переставить пакеты в порядке 1, 2, 4, 5;
  • пакет 3 отсутствует — его не удастся восстановить через RTP (повторной передачи RTP не делает), но декодер может, например, показать последний корректный кадр ещё раз или частично восстановить картинку.

4. Метка времени: синхронизация воспроизведения​

Метка времени (timestamp) — это значение, которое указывает, когда (в какой момент времени) данные этого пакета должны быть воспроизведены.

Важно понимать:

  • Метка времени не обязательно совпадает с реальным временем (часы/дата).
  • Это, как правило, счётчик «тактов» с определённой частотой, зависящей от типа медиа.

Зачем нужна метка времени​

  1. Поддержание равномерного воспроизведения
    Приёмник с помощью меток времени понимает, в каком темпе «крутить» аудиопоток и видеопоток:
    • для аудио — чтобы не ускорять и не замедлять речь;
    • для видео — чтобы показать кадры с нужной частотой (например, 25 или 30 кадров в секунду).
  2. Синхронизация аудио и видео
    Если у нас есть и звук, и изображение, метки времени помогают воспроизводить их согласованно — чтобы движения губ совпадали с речью.

Мини‑пример​

  • Видеопоток: частота кадров 25 кадров в секунду.
  • Допустим, в RTP метки времени для видео увеличиваются на 3600 единиц на каждый кадр (частота таймстампа 90000 Гц / 25 кадров).
  • Тогда:
    • первый кадр может иметь timestamp = 0,
    • второй кадр — 3600,
    • третий — 7200 и т.д.

Приёмник, видя такие метки, понимает, что пакеты с timestamp = 7200 нужно воспроизвести позже, чем пакеты с timestamp = 3600, и выдерживает соответствующий интервал между кадрами.

5. Идентификатор источника SSRC: различение потоков​

SSRC (Synchronization Source) — это числовой идентификатор источника медиа внутри RTP‑сессии.

Для чего нужен SSRC​

В одной и той же сетевой сессии (например, в групповом видеозвонке) может передаваться несколько потоков:

  • несколько видеопотоков от разных участников;
  • несколько аудиопотоков;
  • разные медиапотоки от одного устройства (например, основное видео и превью, или основной звук и дополнительный канал).

SSRC позволяет:

  1. Различать источники — понимать, какой пакет от какого отправителя.
  2. Объединять пакеты одного потока, даже если номера портов или IP‑адреса могут быть общими для нескольких потоков.
  3. Поддерживать синхронизацию аудио и видео от одного и того же источника (когда это требуется).

Пример​

В конференции участвуют три человека: A, B и C. Каждый передаёт по одному видеопотоку.

  • Поток A — SSRC = 0x11AA22BB
  • Поток B — SSRC = 0x33CC44DD
  • Поток C — SSRC = 0x55EE66FF

Приёмник, анализируя поле SSRC в заголовке RTP, точно знает, к какому участнику относится каждый пакет, даже если все они приходят на один и тот же сервер и один и тот же порт.

6. Тип полезной нагрузки: какой кодек внутри​

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

Что такое «полезная нагрузка»​

Полезная нагрузка (payload) — это часть пакета, в которой находятся данные, подлежащие доставке:

  • для аудио: закодированные аудиосэмплы (например, в формате Opus, G.711 и т.п.),
  • для видео: закодированные видеоблоки/фреймы (например, H.264, H.265 и др.).

Зачем нужен тип полезной нагрузки​

Приёмнику необходимо:

  1. Понимать, каким декодером обрабатывать содержимое пакета.
  2. Правильно интерпретировать структуру данных внутри payload (разделение на фреймы, блоки и т.д.).

Например, тип полезной нагрузки может указывать:

  • аудио Opus,
  • аудио G.711,
  • видео H.264,
  • видео VP8 и т.д.

При анализе RTP‑потока, например в Wireshark, по полю payload type сразу видно, какой кодек используется.

7. Связка RTP и RTCP: контроль качества передачи​

RTP редко используется в одиночку. Он почти всегда работает в паре с протоколом RTCP (Real-time Transport Control Protocol).

Что делает RTCP​

RTCP — это служебный протокол контроля, который:

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

Чаще всего RTCP‑пакеты передаются по тем же адресам, что и RTP, но по соседним портам.

Типичная информация в RTCP​

RTCP может содержать:

  • уровень потерь пакетов — сколько пакетов не дошло до получателя;
  • задержки (latency) — оценка времени, которое проходит от отправки до получения;
  • джиттер (jitter) — разброс задержек (насколько сильно варьируется время прихода пакетов);
  • сведения об источниках (SSRC) и участниках сессии.

Зачем всё это нужно​

  1. Мониторинг качества
    Системы могут автоматически отслеживать, что поток начал «сыпаться», растёт задержка или увеличиваются потери.
  2. Адаптация параметров передачи
    Некоторые системы (например, видеоконференции) на основе данных RTCP:
    • снижают битрейт видео при плохом канале;
    • уменьшают разрешение или фреймрейт;
    • изменяют стратегию кодирования, чтобы компенсировать потери.
  3. Диагностика проблем
    Администратор, анализируя RTCP‑отчёты, может понять, где возникают проблемы: на стороне отправителя, в канале или у получателя.

8. RTP «под капотом»: где он используется на практике​

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

Примеры технологий, использующих RTP​

  • RTSP (Real-Time Streaming Protocol)
    Используется, например, для доступа к потокам IP‑камер. RTSP занимается «сигнализацией» (команды типа PLAY, PAUSE, SETUP), а сами медиаданные передаются по RTP.
  • WebRTC
    Технология для обмена аудио‑ и видеоданными в реальном времени (браузер‑к‑браузеру или через серверы). Внутри WebRTC для передачи медиа тоже используется RTP, адаптированный к защищённым каналам (SRTP).
  • SRT (Secure Reliable Transport)
    Хотя SRT сам по себе обеспечивает надёжный транспорт по нестабильным сетям, он также часто инкапсулирует внутри себя медиаданные, которые концептуально организованы аналогично RTP‑трафику.

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

9. Анализ RTP-потоков в Wireshark​

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

Что можно сделать в Wireshark​

  1. Поймать и отфильтровать RTP‑пакеты
    Wireshark умеет автоматически распознавать RTP‑трафик и показывать для него:
    • номера последовательности;
    • метки времени;
    • SSRC;
    • тип полезной нагрузки.
  2. Оценить качество передачи
    По последовательности номеров и времени прихода пакетов можно увидеть:
    • наличие потерь пакетов;
    • перестановки пакетов;
    • задержки и джиттер.
  3. Проанализировать использующиеся кодеки
    Видя типы полезной нагрузки, можно определить:
    • какой видео‑ и аудиокодек использует устройство или приложение;
    • соответствуют ли параметры ожиданиям (например, H.264 вместо ожидаемого H.265).

Пример практического применения​

При отладке IP‑камеры:

  • Вы запускаете Wireshark на машине, принимающей RTSP‑поток.
  • Фильтруете RTP‑пакеты.
  • Проверяете:
    • нет ли больших потерь по sequence number;
    • нормально ли растут timestamp;
    • совпадает ли SSRC с ожидаемым источником;
    • какой payload type используется (действительно ли это H.264).

Это помогает понять, проблема в камере, в сети или в принимающем приложении.

10. Итог: роль RTP в системах передачи медиа​

Подведём итог ключевым моментам:

  1. RTP — это протокол транспортировки медиа в реальном времени, ориентированный на аудио и видео.
  2. Он не устанавливает соединение и не гарантирует доставку, а занимается:
    • нумерацией пакетов (sequence number);
    • синхронизацией по времени (timestamp);
    • идентификацией источников (SSRC);
    • описанием типа медиа (payload type).
  3. RTCP дополняет RTP, передавая служебную информацию о качестве соединения: потери, задержки, джиттер.
  4. В современных системах RTP чаще всего используется внутри более высокоуровневых протоколов (RTSP, WebRTC, SRT и др.) и редко настраивается непосредственно пользователем.
  5. Анализ RTP‑трафика возможен с помощью инструментов вроде Wireshark, что важно для диагностики и отладки медиа‑систем.

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