Отладка изохронных передач UVC-камеры: полоса, alternate settings и потерянные кадры

USB Video Class-устройств полно: "веб-камеры, промышленные камеры, камеры для микроскопов, модули embedded-зрения и тестовые стенды. Когда UVC-камера ломается, видимый симптом обычно простой: нет видео, низкая частота кадров, потерянные кадры или приложение камеры, работающее на одном разрешении, но падающее на другом." USB-доказательства сложнее. UVC-камеры часто зависят от дескрипторов, класс-управляющей negotiation, alternate interface settings, полосы конечных точек и поведения изохронных передач. Общий отчёт «камера не работает» редко содержит достаточно информации.

UVC — больше, чем перечисление

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

Изучите:

• video control interface
• video streaming interface
• format descriptors
• frame descriptors
• опции frame interval
• управления probe и commit
• выбранный alternate setting
• endpoint descriptors изохронных точек
• размеры пакетов и статус передачи

Если камера работает на 640x480, но падает на 1080p, данные дескрипторов и полосы могут объяснить почему.

Alternate settings важны

Многие UVC-устройства используют alternate interface settings для выставления разных уровней полосы. Хост выбирает alternate setting до начала стриминга. Если выбранный setting не совпадает с согласованным форматом или полосой, стриминг может падать или терять кадры.

Вопросы к захвату:

• какой alternate setting был выбран?
• какой max packet size был заявлен у конечной точки?
• какой формат и frame interval были подтверждены?
• начались ли изохронные передачи?
• появились ли ошибки передач сразу?
• откатился ли хост на меньший setting?

Это доказательства, которые нужны инженеру прошивок до смены frame descriptors или конфигурации конечных точек.

Изохронные передачи приоритизируют тайминг

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

Частые причины:

• недостаточная полоса шины
• проблемы топологии концентратора
• конкурирующие USB-устройства
• неправильный alternate setting
• голодание буфера прошивки
• лимиты хост-контроллера
• проблемы кабеля или сигнала

Захват должен показать, были ли пакеты запланированы, пришли ли данные, и были ли статусные ошибки.

Не отлаживайте UVC только по приложению

Приложения камеры часто прячут USB-negotiation. Они могут молча выбрать меньшее разрешение, откатиться на MJPEG, ретраить frame intervals или маскировать ошибки передач. Для команд прошивок и вендоров устройств этого мало.

Хороший UVC-поддерживающий захват записывает:

• запрошенный формат
• запрошенный размер кадра
• запрошенный frame interval
• результат probe/commit
• выбранный alternate setting
• статус передач
• наблюдаемый поток полезной нагрузки

Это позволяет командам объяснить, почему один хост или разрешение работает, а другое — нет.

Место Bus Scope

Bus Scope создан для USB-доказательств. Для UVC-кейсов он должен помочь связать дескрипторы, управляющие запросы, выбор конечной точки и таймлайн передач. Ему не нужно быть видео-просмотрщиком, чтобы быть полезным. Цель — не показать картинку; цель — объяснить поведение шины.

Для запросов вроде «UVC camera no video», «USB camera isochronous transfer failed», «webcam dropped frames USB capture» ответ должен начинаться с дескрипторов, alternate settings, полосы и статуса передач.