Исправление ошибки RTP в основном потоке: диагностика потери пакетов, зависаний камеры и макроблоков в RTSP

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

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

О чем говорят пробелы в последовательности RTP

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

Практические вопросы:

• сколько пакетов пропало?
• потеря случилась один раз или неоднократно?
• это произошло рядом с ключевыми кадрами?
• отчеты об отправителях RTCP продолжались?
• сеанс управления RTSP остался жив?
• сбой декодера случился после разрыва?

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

Почему H.264 и H.265 чувствительны к потерям

Сжатое видео не представляет собой список независимых изображений. Интеркадры зависят от опорных кадров. Небольшая потеря пакета может повредить больше, чем непосредственный пакет. Потоки H.264 и H.265 также могут полагаться на наборы параметров, такие как SPS и PPS, а H.265 добавляет VPS. Если они отсутствуют, запаздывают или повреждены, нижестоящее программное обеспечение может отклонить поток, даже если толерантный просмотрщик, похоже, восстановится.

Общие симптомы включают в себя:

• макроблоки или блочные артефакты
• зависание с последующим внезапным догоном
• Ошибки декодера стиля «отсутствующая ссылка»
• поток запускается, но ни один кадр не становится готовым к декодированию
• повторяющееся повреждение после сцен с большим количеством движения

Этих симптомов самих по себе недостаточно. Доказательства RTP и кодеков делают их действенными.

Не путайте джиттер с потерями

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

На предмет дрожания проверьте ход временной метки и время прибытия. На предмет потери проверьте пробелы в последовательности. На наличие ошибок прошивки камеры проверьте согласованность полезных данных и структуру NAL. Полевой отчет, в котором говорится только о том, что поток прерывистый, не сообщает сетевому инженеру, инженеру встроенного ПО или поставщику VMS, что нужно изменить.

В лучшем отчете говорится:

• Разрыв последовательности RTP от N до N+M
• скачок временной метки наблюдался в той же точке
• Сеанс RTSP остался установленным
• тип полезной нагрузки остался стабильным
• Срез H.264 был неполным
• следующий кадр IDR восстановил готовность декодера

Это гораздо более сильный артефакт поддержки.

UDP и TCP рассказывают разные истории

RTSP обычно передает RTP через UDP или через TCP с чередованием. UDP напрямую выявляет потерю пакетов. TCP может заставить исчезнуть заблокированные пути UDP, но это может привести к задержке и не докажет работоспособность предполагаемого пути развертывания.

Для диагностики сравните оба режима:

• UDP дает сбой из-за пробелов в последовательности: проверьте потери сети, коммутаторы, Wi-Fi, брандмауэр, NAT или поведение отправки камеры.
• UDP не получает RTP: проверьте согласованные порты и политику брандмауэра.
• TCP работает, но UDP не работает: подозрение на сетевой путь, а не на кодек.
• в обоих режимах отображаются неверные полезные данные: подозрительный кодер камеры, профиль потока или встроенное ПО.

Выбор транспорта – это свидетельство, а не просто флажок игрока.

Как инспектор RTSP формулирует проблему

Инспектор RTSP фокусируется на доказательствах протокола, а не на воспроизведении. Он фиксирует наблюдения RTSP, RTP, RTCP и кодеков, поэтому обращение в службу поддержки можно воспроизвести и объяснить. Это имеет значение, когда один и тот же поток ведет себя по-разному в VLC, FFmpeg, NVR, облачной службе приема и аналитическом конвейере.

Цель не состоит в том, чтобы утверждать, что каждый поток можно исправить локально. Цель – выявить владельца неисправности:

• сетевой путь
• конфигурация камеры
• пакетизация прошивки
• поддержка нисходящего декодера
• граница неподдерживаемого кодека
• ожидаемое несоответствие развертывания UDP/TCP

Потеря RTP — это не просто симптом видео. Это измеримое протокольное событие. Как только он будет измерен, разговор об устранении неполадок станет намного короче.