Depuración de transferencias isócronas en cámaras UVC: ancho de banda, alternate settings y frames perdidos

Los dispositivos USB Video Class están en todas partes: "webcams, cámaras industriales, cámaras de microscopio, módulos de visión embebida y fixtures de test. Cuando falla una cámara UVC, el síntoma visible suele ser simple: sin vídeo, frame rate bajo, frames perdidos o una app de cámara que va a una resolución pero falla a otra." La evidencia USB es menos simple. Las cámaras UVC suelen depender de descriptores, negociación class-specific, alternate settings de interfaz, ancho de banda del endpoint y comportamiento de transferencias isócronas. Un reporte genérico de "la cámara no va" rara vez trae bastante información.

UVC es más que enumeración

Un dispositivo UVC puede enumerar bien y aun así no streamear. La enumeración solo prueba que el host leyó los descriptores y eligió una configuración. El streaming de vídeo requiere negociación adicional y tráfico de endpoint.

Inspecciona:

• Video control interface.
• Video streaming interface.
• Format descriptors.
• Frame descriptors.
• Opciones de frame interval.
• Probe y commit controls.
• Alternate setting seleccionado.
• Endpoint descriptors isócronos.
• Tamaños de paquete y estado de transferencia.

Si una cámara va a 640x480 pero falla a 1080p, la evidencia de descriptor y ancho de banda puede explicar por qué.

Los alternate settings importan

Muchos dispositivos UVC usan alternate settings de interfaz para exponer distintos niveles de ancho de banda. El host selecciona un alternate setting antes de streamear. Si el alternate setting elegido no encaja con el formato o ancho de banda negociado, el streaming puede fallar o perder frames.

Preguntas para la captura:

• ¿Qué alternate setting se seleccionó?
• ¿Qué max packet size de endpoint se anunció?
• ¿Qué formato y frame interval se cometieron?
• ¿Las transferencias isócronas arrancaron?
• ¿Aparecieron errores de transferencia inmediatamente?
• ¿Cayó el host a un alternate setting inferior?

Esta es la evidencia que necesita un ingeniero de firmware antes de cambiar frame descriptors o configuración de endpoint.

Las transferencias isócronas priorizan el timing

Las transferencias isócronas están pensadas para datos sensibles al tiempo. Reservan ancho de banda, pero no reintentan como las bulk transfers. Es lo apropiado para vídeo, pero significa que los datos perdidos aparecen como frame corrupto o datos de imagen ausentes en lugar de una retransmisión limpia.

Causas habituales:

• Ancho de banda del bus insuficiente.
• Problemas de topología de hubs.
• Otros dispositivos USB compitiendo.
• Alternate setting incorrecto.
• Buffer starvation en firmware.
• Límites del host controller.
• Problemas de cable o calidad de señal.

La captura debería enseñar si los paquetes se planificaron, si llegaron los datos y si hubo errores de status.

No depures UVC solo desde la aplicación

Las apps de cámara suelen esconder la negociación USB. Pueden bajar silenciosamente la resolución, caer a MJPEG, reintentar frame intervals o enmascarar errores de transferencia. Para firmware y fabricantes de dispositivo, eso no basta.

Una buena captura de soporte UVC registra:

• Formato pedido.
• Tamaño de frame pedido.
• Frame interval pedido.
• Resultado del probe/commit.
• Alternate setting elegido.
• Estado de la transferencia.
• Flujo de payload observado.

Eso permite explicar por qué un host o resolución va mientras otro falla.

Dónde encaja Bus Scope

Bus Scope está pensado para evidencia USB. Para casos UVC, debería ayudar a conectar descriptores, peticiones de control, selección de endpoint y línea de tiempo de transferencia. No necesita ser un visor de cámara para ser útil. El objetivo no es enseñar la imagen, es explicar el comportamiento del bus.

Para búsquedas como "UVC camera no video", "USB camera isochronous transfer failed" o "webcam dropped frames USB capture", la respuesta debería empezar por descriptores, alternate settings, ancho de banda y estado de transferencia.