Отсутствует H.264 SPS/PPS в потоках RTSP: почему VLC работает, но FFmpeg или аналитика не работают

Разочаровывающая картина сбоя RTSP знакома инженерам камер: "VLC воспроизводит поток, но FFmpeg, VMS, аналитический конвейер или облачная служба приема данных выходят из строя из-за ошибок декодера. Ветка поддержки часто превращается в дискуссию о том, какой инструмент «правильный». Лучше задаться вопросом, обеспечивает ли поток достаточное количество доказательств параметров H.264 для нового декодера." H.264 требует наборов параметров последовательности и наборов параметров изображения. Инженеры обычно называют их СПС и ППС. Они описывают, как следует декодировать битовый поток: "профиль, уровень, размеры, эталонное поведение и структуру изображения. Без них декодер может видеть данные фрагмента, но у него все еще не будет действительного контекста для преобразования их в кадры."

Где могут появиться СПС и ППС

При развертывании RTSP доказательства SPS/PPS могут появляться более чем в одном месте:

• SDP sprop-наборы параметров
• внутриполосные полезные данные RTP перед слайсами
• повторяется перед ключевыми кадрами
• кэшировано терпимым игроком из более ранней сессии
• доставлено только после ожидания следующего IDR

Это объясняет проблему «работает в одном просмотрщике». Игрок может повторно использовать состояние, ждать дольше, восстанавливаться после отсутствующих ссылок или применять сокрытие ошибок. Служба строгого приема может начинаться с пустого декодера и отклонять поток до тех пор, пока не поступят SPS/PPS и пригодный для использования ключевой кадр.

Что на самом деле означает ошибка

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

Диагностические вопросы:

• SDP включал sprop-parameter-sets?
• были ли замечены SPS и PPS в полезной нагрузке RTP?
• они прибыли до первого куска?
• появился ли кадр IDR после установки параметров?
• потеря пакета удалила пакет набора параметров?
• стрим начался в середине GOP?
• соответствовал ли тип полезной нагрузки SDP?

Как только на эти вопросы будут даны ответы, следующее действие станет более ясным.

Почему запуск трансляции в середине GOP опасен

Многие камеры начинают отправку с текущей позиции кодера при подключении клиента RTSP. Если клиент присоединяется к середине GOP, он может получать промежуточные кадры перед ключевым кадром. Если поток также не может регулярно повторять SPS/PPS, декодер может подождать или выйти из строя до следующей подходящей границы.

Для программного обеспечения для мониторинга это может выглядеть так:

• черный экран в течение нескольких секунд
• первый кадр появляется только после движения или интервала ключевых кадров
• конвейер аналитики отказывается от потока
• рестример запускается, но нижестоящие клиенты терпят неудачу
• периодическое восстановление после переподключения

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

СДП — это претензия; RTP — доказательство

Некоторые системы камер рекламируют SPS/PPS в SDP. Другие ожидают, что декодер будет ждать внутриполосных блоков NAL. Некоторые делают и то, и другое. Некоторые не делают ни того, ни другого правильно. В диагностическом отчете необходимо сравнить заявку с полезной нагрузкой.

Полезные доказательства включают в себя:

• Наборы параметров base64 в SDP
• Типы блоков H.264 NAL, наблюдаемые в RTP
• индекс первого пакета SPS/PPS
• индекс первого пакета IDR
• потеря пакетов до готовности ключевого кадра
• статус готовности декодера

Это гораздо сильнее, чем «попробовать другого игрока». Он сообщает поставщику, следует ли изменить SDP, настройки кодировщика или поведение пакетирования.

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

RTSP Inspector предназначен для проверки структуры RTSP, SDP, RTP/RTCP и кодеков, не притворяясь, что воспроизведение является диагностикой. В случае отсутствия случаев SPS/PPS продукт должен помочь инженерам показать:

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

Это своего рода доказательства, которые разрешают аргумент «VLC работает». Работа VLC — полезная информация. Это не доказательство того, что поток чист для каждого потребителя.

Если ваш поисковый запрос «RTSP работает в VLC, но FFmpeg не работает», проверьте SPS/PPS, ключевые кадры, потерю пакетов и SDP, прежде чем обвинять нижестоящую систему.