SDP, H.264 и H.265 в диагностике RTSP: метаданные, определяющие возможность запуска видео

Многие сбои RTSP описываются как «поток камеры не воспроизводится». Эта фраза скрывает самую важную диагностическую границу: "что утверждала камера в SDP и соответствовала ли полезная нагрузка мультимедиа этому утверждению?" SDP часто является первым структурированным свидетельством, доступным в сеансе RTSP. Он объявляет мультимедийные дорожки, типы полезных данных, имена кодеков, тактовую частоту, управляющие URL-адреса и параметры, специфичные для кодека. Если SDP неправильный, неполный или не поддерживается потребителем, поток может выйти из строя до того, как будет декодирован первый кадр.

Что должна доказать СДП

После DESCRIBE клиент должен знать, содержит ли поток видео, какой тип полезной нагрузки соответствует какому кодеку и как следует настроить медиа-трек. Для диагностики камеры проверьте:

• медиа-раздел m=video
• a=control URL-адрес отслеживания
• Тип полезной нагрузки a=rtpmap и имя кодека
• Параметры кодека a=fmtp
• H.264 sprop-parameter-sets, если присутствует
• Сигнализация H.265 VPS/SPS/PPS, если доступна
• ожидается ли заявленная тактовая частота

Если SDP рекламирует H.264, но камера отправляет что-то другое, получатель не поступает неразумно. Если SDP пропускает подтверждение важных параметров и поток никогда не отправляет его внутри полосы, декодеру может не хватить информации для начала.

Наборы параметров H.264 не являются дополнительным доказательством

Декодерам H.264 необходима информация о последовательности и параметрах изображения. При развертывании камер RTSP это свидетельство может появиться в SDP, внутриполосных полезных нагрузках RTP или в том и другом. Проблемы возникают, когда камера предполагает, что приемник уже знает что-то, чего он не знает.

Чистая диагностическая запись отвечает:

• СПС был виден?
• ППС был виден?
• полезные данные включали кадр IDR?
• стрим начался в середине GOP?
• Идентификатор уровня профиля выглядел правдоподобно?
• Соответствует ли режим пакетирования наблюдаемой структуре полезной нагрузки?

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

H.265 добавляет больше границ совместимости

H.265 широко распространен в современных камерах, особенно когда важна пропускная способность, но он менее универсально поддерживается, чем H.264, в старых инструментах и ​​встроенных устройствах. H.265 также предоставляет доказательства VPS в дополнение к SPS и PPS. Развертывание, в котором говорится только о том, что «RTSP работает», все равно может потерпеть неудачу, поскольку фактический профиль кодека или доставка параметров находятся за пределами поддерживаемых потребителем границ.

Для полевых команд полезная статья, заявка или отчет не должны содержать только фразу «перейти на H.264». Должно быть объяснено, почему:

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

Такой уровень ясности предотвращает повторные изменения методом проб и ошибок.

SDP необходимо сравнивать с RTP

СДП - это претензия. RTP является следующим доказательством. Их необходимо сравнить.

Примеры:

• SDP утверждает, что тип полезной нагрузки 96 — это H.264, но RTP поступает с другим типом полезной нагрузки.
• SDP содержит видеодорожку, но после PLAY нет RTP.
• SDP говорит о H.265, но нижестоящий продукт поддерживает только H.264.
• SDP опускает наборы параметров, а RTP никогда не отправляет их перед слайсами.
• RTP поступает, но структура блока NAL не соответствует объявленному кодеку.

Эти случаи требуют разных дальнейших действий. Если не сравнивать SDP и RTP, все они выглядят как один и тот же невнятный провал «нет видео».

Почему инспектор RTSP обнаруживает эти доказательства

RTSP Inspector предназначен для инженеров потокового вещания, поставщиков камер и интеграторов систем видеонаблюдения, которым необходимы воспроизводимые доказательства. Это намеренно не универсальный медиаплеер. Его задача — проверить путь управления RTSP, метаданные SDP, поток RTP/RTCP и готовность H.264/H.265.

Это делает вывод полезным в разговорах со службой поддержки:

• поставщик камеры: исправьте SDP или пакетизацию
• сетевая команда: исправьте путь доставки RTP
• Команда VMS: настройте профиль поддерживаемого кодека
• полевой интегратор: изменить профиль потока или режим транспортировки
• клиент: понять, почему воспроизведение не является доказательством работоспособности протокола

В диагностике RTSP SDP не является шаблонным текстом. Это первый контракт, который предлагает стрим. Если этот контракт будет нарушен, остальная часть конвейера будет гадать.