RTSP подключается, но не показывает видео: что нужно проверить, прежде чем винить игрока

Один из наиболее распространенных билетов поддержки камеры звучит просто: "URL-адрес RTSP подключается, аутентификация проходит успешно, но программа просмотра не показывает видео. Естественный инстинкт — попробовать другого игрока. Это может быть полезно, но не отвечает на инженерный вопрос: произошел ли сбой потока при управлении RTSP, согласовании SDP, доставке RTP или готовности кодека?" Для интеграторов систем видеонаблюдения, инженеров VMS и производителей камер это различие имеет значение. Игрок может скрыть потерю пакетов, повторно использовать старое состояние декодера или автоматически повторить режимы транспортировки. В диагностическом отчете должно быть указано, какая часть потока оказалась здоровой, а какая нет.

Отделите успех контроля от успеха в СМИ

RTSP — это протокол управления. Успешная последовательность операций «ОПИСАНИЕ», «НАСТРОЙКА» и «ВОСПРОИЗВЕДЕНИЕ» доказывает, что камера приняла сеанс. Это не доказывает, что пакеты RTP поступили. Это также не доказывает, что полезная нагрузка на самом деле является H.264 или H.265 в той форме, которую рекламирует SDP.

Полезные записи первого прохода:

• коды состояния RTSP для «ОПЦИИ», «ОПИСАНИЕ», «НАСТРОЙКА» и «ВОСПРОИЗВЕДЕНИЕ».
• содержит ли тело SDP раздел видеомедиа
• тип полезной нагрузки, согласованный для видеодорожки
• прибывают ли пакеты RTP после PLAY
• перемещаются ли метка времени и порядковые номера RTP вперед
• содержит ли первая полезная нагрузка видео данные о параметрах кодека

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

Почему СДП является первой границей доказательств

SDP сообщает клиенту, что, по утверждению камеры, она отправит. Для H.264 инженеры ищут значения rtpmap и fmtp, такие как режим пакетирования, идентификатор уровня профиля и наборы параметров sprop. Для H.265 SDP может передавать информацию VPS, SPS и PPS по-разному, и многие потребители имеют более строгие ограничения поддержки.

Когда SDP говорит H.264, но медиа-байты не содержат ожидаемой структуры блока NAL, сбой не является общей «проблемой проигрывателя». Это несоответствие между рекламируемыми метаданными и реальной полезной нагрузкой. Когда SDP пропускает наборы параметров и поток RTP никогда не отправляет их внутри полосы, декодер может ждать вечно.

Вот почему рабочий процесс проверки RTSP должен хранить SDP рядом с медиа-доказательствами, а не прятать его в журналах игроков.

Прибытия RTP недостаточно

Даже когда пакеты RTP приходят, видео все равно может выйти из строя. Кадры H.264 и H.265 часто зависят от более ранних пакетов. Отсутствующий пакет может сделать следующий фрагмент недекодируемым. Доставка не по порядку может выглядеть как коррупция. Полезная нагрузка, которая начинается в середине GOP, может быть не готова к декодированию до тех пор, пока не появится следующий ключевой кадр и набор параметров.

Минимальные доказательства, которые необходимо собрать:

• Непрерывность последовательности RTP
• временная метка прогресса
• поведение бита маркера
• согласованность типа полезной нагрузки
• Категории единиц NAL H.264 или H.265
• SPS, PPS и видимость H.265 VPS
• готовность первого ключевого кадра

Это объясняет, почему фразы «VLC воспроизводит это» и «наш аналитический конвейер отвергает это» могут быть правдой. Некоторые зрители выздоравливают агрессивно. Инженерные системы часто нуждаются в подтвержденных стандартами доказательствах.

TCP против UDP — диагностический выбор

Переключение транспорта RTSP с UDP на TCP — распространенный шаг по устранению неполадок, но его не следует рассматривать как панацею. Чередование TCP позволяет избежать блокировки портов UDP и уменьшить потерю пакетов, вызванную сетевой политикой. Он также может скрыть, работает ли предполагаемый путь UDP развертывания.

В хорошем полевом отчете фиксируются обе попытки:

• RTSP через TCP с чередованием: медиа-файлы доходят?
• Одноадресная рассылка RTP через UDP: пакеты поступают на согласованные порты?
• RTCP: показывает ли обратная связь отправителя время и количество пакетов?

Если TCP работает, а UDP не работает, ответ, вероятно, не в поддержке кодеков. Скорее всего, это сетевой путь, брандмауэр, NAT или распределение портов. Если оба транспорта доставляют RTP, но декодирование по-прежнему не удается, проверьте структуру кодека.

Где подходит инспектор RTSP

RTSP Inspector создан именно для этой границы. Он не пытается стать видеоплеером или NVR. Он собирает данные о сеансе RTSP, SDP, потоке RTP/RTCP и готовности H.264/H.265, чтобы инженер мог объяснить, почему «подключенное» не стало «пригодным к использованию видео».

Полезный вывод — это не скриншот черного окна проигрывателя. Это повторяемый ответ:

• RTSP-управление выполнено успешно
• SDP объявил этот кодек и тип полезной нагрузки
• RTP пришел или не пришел
• последовательность пакетов была непрерывной или нарушена
• Свидетельство параметра кодека присутствовало или отсутствовало
• следующее действие принадлежит сети, конфигурации камеры, прошивке или потребителю потока.

В этом разница между просмотром потока и его диагностикой.