2026-06-02

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

Отладка ошибок \"неизвестной записи\" RTP/NDPI в захватах RTSP путем сопоставления динамических типов полезной нагрузки RTP обратно в строки SDP rtpmap и fmtp. Охватывает метаданные H.264, H.265, AAC, ONVIF, идентификаторы полезной нагрузки и ошибки депакетизатора\".

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

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

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

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

Найдите ответ RTSP DESCRIBE.
Скопируйте SDP.
Найдите каждую медиа-строку m= и ее номера полезной нагрузки.
Для каждой динамической полезной нагрузки (96–127) найдите соответствующую строку a=rtpmap:<id>.
Проверьте строку a=fmtp:<id> на наличие параметров кодека.
Сравните байт типа полезной нагрузки пакета 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 должен помочь определить тип дорожки, сопоставление полезных данных, а также определить, являются ли неизвестные полезные данные видео, аудио, метаданными или личными данными.

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

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

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

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

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

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

Воспроизводимая проверка темы «Как исправить ошибки 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 после нового подключения сама по себе не является ошибкой; не объединяйте пакеты старой и новой сессии. Оставшуюся неопределённость формулируйте как непроверенный порт, трек, интервал времени или условие декодера, а не как общий «сбой камеры».

Прямой ответ и граница приемки

Краткий ответ по теме «Как исправить ошибки RTP / NDPI Неизвестная запись»: Отладка ошибок "неизвестной записи" RTP/NDPI в захватах RTSP путем сопоставления динамических типов полезной нагрузки RTP обратно в строки SDP rtpmap и fmtp. Охватывает метаданные H.264, H.265, AAC, ONVIF, идентификаторы полезной нагрузки и ошибки депакетизатора". Считайте это проверяемым результатом, а не обещанием для любого входа, устройства, проекта или окружения. Полный результат фиксирует исходное состояние, точное действие, видимый выход и условие, подтверждающее завершение задачи в RTSP Inspector.

Порядок работы от доказательств

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

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

Закрывайте «Как исправить ошибки RTP / NDPI Неизвестная запись» только когда сохраненный, экспортированный или повторно открытый результат соответствует наблюдению. Временный отклик интерфейса полезен, но долговечное доказательство сильнее. Запишите оставшиеся ограничения.

Контрольная точка 2: Отладка ошибок "неизвестной записи" RTP/NDPI в захватах RTSP путем сопоставления динамич

Для «Отладка ошибок "неизвестной записи" RTP/NDPI в захватах RTSP путем сопоставления динамических типов полезной нагрузки RTP обратно в строки SDP rtpma» отделите решение продукта от границы системы, оборудования, исходного файла, прав или процесса. Установите, какой слой дал доказательство, прежде чем назначать причину. Так соседний симптом не станет якобы доказанной первопричиной.

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

Закрывайте «Быстрый ответ: проверьте SDP, прежде чем обвинять NDPI или камеру.» только когда сохраненный, экспортированный или повторно открытый результат соответствует наблюдению. Временный отклик интерфейса полезен, но долговечное доказательство сильнее. Запишите оставшиеся ограничения.

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

Для «Статические и динамические типы полезной нагрузки» отделите решение продукта от границы системы, оборудования, исходного файла, прав или процесса. Установите, какой слой дал доказательство, прежде чем назначать причину. Так соседний симптом не станет якобы доказанной первопричиной.

Контрольная точка 5: SDP rtpmap is required for dynamic payloads

Закрывайте «SDP rtpmap is required for dynamic payloads» только когда сохраненный, экспортированный или повторно открытый результат соответствует наблюдению. Временный отклик интерфейса полезен, но долговечное доказательство сильнее. Запишите оставшиеся ограничения.

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

Для «Тип полезной нагрузки меняется между сеансами» отделите решение продукта от границы системы, оборудования, исходного файла, прав или процесса. Установите, какой слой дал доказательство, прежде чем назначать причину. Так соседний симптом не станет якобы доказанной первопричиной.

Контрольная точка 7: H.264 and H.265 confusion

Закрывайте «H.264 and H.265 confusion» только когда сохраненный, экспортированный или повторно открытый результат соответствует наблюдению. Временный отклик интерфейса полезен, но долговечное доказательство сильнее. Запишите оставшиеся ограничения.

Контрольная точка 8: AAC and MPEG4-GENERIC

Для «AAC and MPEG4-GENERIC» отделите решение продукта от границы системы, оборудования, исходного файла, прав или процесса. Установите, какой слой дал доказательство, прежде чем назначать причину. Так соседний симптом не станет якобы доказанной первопричиной.

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

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

Контрольная точка 10: Контрольный список отладки

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

Матрица приемки

Точка	Сохраняемое доказательство	Критерий успеха
Как исправить ошибки RTP / NDPI Неизвестная запись	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат
Отладка ошибок "неизвестной записи" RTP/NDPI в захватах RTSP путем сопоставления динамических типов полезной нагрузки	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат
Быстрый ответ: проверьте SDP, прежде чем обвинять NDPI или камеру.	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат
Статические и динамические типы полезной нагрузки	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат
SDP rtpmap is required for dynamic payloads	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат
Тип полезной нагрузки меняется между сеансами	Исходное состояние, одно действие и результат	Второй оператор воспроизводит заявленный результат

Изоляция, восстановление и передача

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

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

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

Вопросы и ответы

Как надежнее всего начать?

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

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

Сохраните идентификатор входа, версию, платформу, настройки, точное действие, первый неожиданный переход и конечный выход. Закройте и повторно откройте проект, сеанс, отчет или экспорт.

Когда повторять процедуру?

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

Когда результат готов к передаче?

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

Связанные руководства

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