Как исправить ошибки RTP / NDPI Неизвестная запись

Сеанс RTSP может выглядеть работоспособным до тех пор, пока анализатор мультимедиа не попытается понять пакеты RTP. DESCRIBE возвращает SDP. SETUP завершается успешно. «ИГРАТЬ» удалось. Приходят RTP-пакеты. Затем приложение или классификатор пакетов сообщает: «неизвестная запись», «неизвестная полезная нагрузка RTP», «неизвестный NDPI», «неподдерживаемый тип полезной нагрузки», «депакетизатор не найден», «неверное сопоставление кодека», «нет декодера для типа полезной нагрузки 96» или «поток содержит неизвестную дорожку».

Эти ошибки обычно означают, что байты присутствуют, но анализатор не может сопоставить тип полезной нагрузки RTP с определением кодека и дорожки из SDP. В RTSP тип полезной нагрузки «96» не является автоматически H.264. Это локальный динамический идентификатор сеанса. Вам нужно прочитать СДП.

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

Если в захвате указано «неизвестная запись» / «RTP» / «NDPI», начните здесь:

1. Найдите ответ RTSP DESCRIBE.
2. Скопируйте SDP.
3. Найдите каждую медиа-строку m= и ее номера полезной нагрузки.
4. Для каждой динамической полезной нагрузки (96–127) найдите соответствующую строку a=rtpmap:<id>.
5. Проверьте строку a=fmtp:<id> на наличие параметров кодека.
6. Сравните байт типа полезной нагрузки пакета RTP с этим сопоставлением SDP.

Если в пакетах RTP используется тип полезной нагрузки «96», а SDP говорит «a=rtpmap:96 H265/90000», анализатор, ожидающий H.264, сообщит ерунду. Если SDP имеет a=rtpmap:96 vnd.onvif.metadata/90000, неизвестная полезная нагрузка вообще не является видео; это метаданные ONVIF, и воспроизведение не должно прерываться.

Вот почему общей метки DPI, такой как «NDPI неизвестно», недостаточно. Механизмы DPI видят байты пакетов. Они не всегда имеют контекст плоскости управления RTSP, необходимый для интерпретации локальных для сеанса динамических идентификаторов полезной нагрузки. Для RTSP плоскость управления и медиаплоскость должны читаться вместе.

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

Статические и динамические типы полезной нагрузки

Некоторые типы полезных данных RTP являются статическими. Другие динамичны. Типы динамических полезных данных обычно находятся в диапазоне 96–127 и должны отображаться с помощью SDP.

Пример:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

SDP rtpmap is required for dynamic payloads

For dynamic payload types, SDP should include a=rtpmap:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

Если в SDP отсутствует rtpmap, клиент может не знать, какой депакетизатор использовать. Некоторые камеры выдают неполный SDP. Некоторые ретрансляторы или прокси изменяют SDP. Некоторые клиенты анализируют только общие дорожки и игнорируют дорожки метаданных.

Общие результаты:

• Полезная нагрузка видео поступает, но не декодируется.
• Звуковая дорожка игнорируется.
• Отслеживание метаданных ONVIF вызывает неизвестные ошибки полезной нагрузки.
• H.265 ошибочно принимают за H.264.
• Неправильная тактовая частота AAC или количество каналов.

Тип полезной нагрузки меняется между сеансами

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

Например:

Session A: payload 96 = H264
Session B: payload 96 = H265
Session C: payload 97 = H264, payload 96 = metadata

H.264 and H.265 confusion

Symptoms:

AAC and MPEG4-GENERIC

Relevant SDP:

a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=...

Тип полезной нагрузки, тактовая частота, каналы и параметры fmtp — все имеет значение.

Отслеживание метаданных и расширения поставщиков

Метаданные ONVIF, наложения аналитики, отслеживание частных событий и полезные данные, зависящие от поставщика, могут отображаться в SDP. Медиаплеер может не знать, что с ними делать.

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

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

Контрольный список отладки

Используйте этот процесс:

1. Захватите SDP, возвращенный DESCRIBE.
2. Перечислите все медиа-разделы m=.
3. Перечислите все типы динамических полезных данных.
4. Сопоставьте идентификаторы полезной нагрузки с помощью a=rtpmap.
5. Проверьте a=fmtp на предмет конфигурации кодека.
6. Сравните значения типа полезной нагрузки пакета RTP с SDP.
7. Проверьте, изменяются ли идентификаторы полезной нагрузки между сеансами.
8. Разделяйте видео, аудио, метаданные и частные треки.
9. Убедитесь, что у клиента есть депакетизатор для каждого требуемого кодека.
10. Игнорируйте неподдерживаемые дополнительные треки, только если приложение может сделать это безопасно.

Окончательный диагноз

Несоответствие типов динамических полезных данных RTP происходит, когда клиент не может сопоставить входящие пакеты RTP с правильным кодеком или дорожкой. Исправление состоит в том, чтобы рассматривать SDP как источник полномочий для сеанса: анализировать rtpmap, анализировать fmtp, привязывать идентификаторы полезной нагрузки для каждого сеанса и отличать необходимые дорожки мультимедиа от необязательных метаданных.

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

<!-- rtsp-localized-evidence-foundation-v1:start -->

Воспроизводимая проверка темы «Как исправить ошибки RTP / NDPI Неизвестная запись»

Краткий ответ: чёрный экран или одиночный код не доказывает источник сбоя. Надёжная диагностика связывает запрос и ответ RTSP, согласованный Transport, действующую Session, а затем номера последовательности RTP, временные метки и данные RTCP. Для «Как исправить ошибки RTP / NDPI Неизвестная запись» начните с уровня, ближайшего к симптому, но сохраняйте единую временную шкалу, чтобы не смешать управление, сеть и декодирование.

До изменения камеры, межсетевого экрана или VMS создайте небольшой базовый тест. Запишите RTSP URL без пароля, время, путь, запрошенный Transport, ответ сервера и момент первого медиапакета. Проверяйте UDP и TCP interleaved отдельно, если устройство поддерживает оба режима. Не меняйте одновременно путь, учётные данные и транспорт: иначе успешная вторая попытка не покажет решающую переменную.

Уровень	Сохраняемое доказательство	Вопрос
RTSP	метод, статус, заголовки, CSeq и Session	Сервер принял именно эту операцию?
SDP	control, payload type, clock rate и codec	Описана ожидаемая дорожка?
Transport	client_port, server_port или interleaved	Обе стороны используют один канал?
RTP	SSRC, sequence, timestamp и marker	Медиаданные идут в объяснимом порядке?
RTCP	sender report, CNAME и BYE	Часы, идентичность и конец прослеживаются?
Decoder	SPS/PPS/VPS и packetization mode	Полученный payload позволяет инициализацию?

Разделяйте «медиа не пришло» и «медиа пришло, но не декодируется». Отсутствие RTP после успешных SETUP и PLAY ведёт к проверке UDP, NAT, firewall и ответа Transport. Пробелы последовательности доказывают потерю или перестановку. Непрерывный RTP без изображения переводит расследование к payload type, clock rate, границам кадра и параметрам H.264 или H.265. Эта граница полезнее общего сообщения проигрывателя.

Как написать цитируемый ответ?

Используйте три предложения: последняя успешная операция, первое отсутствующее доказательство и следующий разделяющий тест. Пример: «DESCRIBE, SETUP и PLAY успешны; RTP не приходит на объявленные порты клиента; проверка TCP interleaved отделит блокировку UDP от неверного медиапути». Не обвиняйте камеру или сеть без ответа либо пакета, подтверждающего границу.

Что делает случай воспроизводимым?

Сохраните OPTIONS, DESCRIBE, SETUP и PLAY, SDP, ответ Transport и очищенный Session. Для RTP запишите SSRC, первый и последний sequence, clock rate, число пробелов и длительность. Результат VLC или другой VMS используйте как дифференциальный тест, а не как доказательство правильной реализации всех правил успешным клиентом.

Когда проверять сервер или клиент?

Проверяйте сервер при отказе метода, несуществующем control URL, несовместимом Transport или необъяснимой смене SSRC или часов. Проверяйте клиент при повторном старом nonce, потере Session, запросе UDP без открытых портов или трактовке каждого конца NAL как конца access unit. Для промежуточной неисправности каждому выводу нужны пакет и время.

Как проверить отчёт?

Повторите тест с нового соединения и сравните временные шкалы до первого отличия. Удалите пароли и полные Authorization. Свяжите выводы с CSeq, sequence или timestamp. Используйте связанный справочник RTSP, а RTSP Inspector — для локальной проверки RTSP-потока и сбора доказательств без загрузки видео в публичный сервис.

Добавьте явный критерий приёмки. На том же URL и с теми же учётными данными управляющие запросы должны завершиться ожидаемыми статусами, RTP — непрерывно идти по выбранному Transport, а после нужных параметров кодека должен восстановиться реальный кадр. Смена Session или SSRC после нового подключения сама по себе не является ошибкой; не объединяйте пакеты старой и новой сессии. Оставшуюся неопределённость формулируйте как непроверенный порт, трек, интервал времени или условие декодера, а не как общий «сбой камеры».

<!-- rtsp-localized-evidence-foundation-v1:end --><!-- rtsp-localized-layer-verdicts-v1:start -->

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

Для «Как исправить ошибки RTP / NDPI Неизвестная запись» сначала запишите наблюдение, затем интерпретацию. Наблюдение другой инженер может найти в захвате: статус RTSP с CSeq, значение SDP, ответ Transport, пробел последовательности, смена SSRC или разница RTP timestamp и RTCP sender report. «Сервер медленный» или «кодек несовместим» остаётся гипотезой, пока конкретное доказательство не объяснит результат лучше альтернатив.

Разделите путь на границы. Сначала открывается TCP, затем принимается OPTIONS или DESCRIBE. SDP описывает рабочую дорожку, control URL, payload type и clock rate. SETUP требует совместимого Transport, PLAY — действующей Session. После этого проверяются приход RTP, порядок, время и готовность декодера. Остановитесь на первой границе без доказательства успеха.

В сравнении сохраняйте источник и интервал. UDP и TCP interleaved проверяйте с одним путём и учётными данными. Main stream и sub stream — одним клиентом и транспортом. При сравнении VLC с VMS запишите реальные методы, заголовки и URL. Разница control URL, Authorization, Session или keepalive иногда объясняет результат лучше названия программы.

Матрица исключения

Начните с двух гипотез. При отсутствии медиа UDP может блокироваться или сервер может отправлять на другие порты. TCP interleaved проверяет первую; сравнение предложения и ответа Transport, IP и портов — вторую. При повреждённом изображении RTP sequence отделяет потери от неполной инициализации, а SPS/PPS/VPS перед первым frame проверяет параметры codec.

Для гипотезы запишите подтверждающее и опровергающее доказательство. Утверждение, которое нельзя опровергнуть пакетом, слишком широко. «NAT удаляет UDP» опровергается RTP на порту клиента. «Нет параметров H.264» опровергается действительными SPS и PPS перед IDR. Отчёт становится приоритетным выводом, а не списком вариантов.

Не смешивать время

RTSP CSeq упорядочивает транзакции, RTP sequence — пакеты, RTP timestamp — время выборки, capture clock — приход в точку наблюдения. Это разные часы. Неравномерный приход не доказывает drift; скачок timestamp без sequence не доказывает потерю. RTCP sender report связывает часы RTP аудио и видео с общей опорой.

Пакет приёмки

Закройте случай, когда исправление повторяется в новом соединении с одним документированным изменением. Укажите входы, последнюю успешную границу, первое отсутствующее доказательство, изменение, результат и открытые тесты. Приложите короткий transcript или статистику. Скройте секреты, но сохраните CSeq, очищенную Session, SSRC и интервал.

Устранение неполадок RTSP помогает повторить порядок, а отчёты RTSP Inspector передают доказанную границу команде камеры, сети или VMS.

<!-- rtsp-localized-layer-verdicts-v1:end -->