Depuração de transferências isochronous em câmera UVC: bandwidth, alternate settings e frames perdidos

Dispositivos USB Video Class estão em toda parte: "webcams, câmeras industriais, câmeras de microscópio, módulos de visão embarcada e bancadas de teste. Quando uma câmera UVC falha, o sintoma visível costuma ser simples: nada de vídeo, frame rate baixo, frames perdidos ou um app de câmera que funciona em uma resolução e falha em outra." A evidência USB é menos simples. Câmeras UVC geralmente dependem de descritores, negociação específica de classe, alternate interface settings, bandwidth de endpoint e comportamento de transferência isochronous. Um relatório genérico de "câmera não funciona" raramente traz informação suficiente.

UVC é mais do que enumeração

Um dispositivo UVC pode enumerar corretamente e mesmo assim falhar no streaming. A enumeração só prova que o host leu os descritores e selecionou uma configuração. O streaming de vídeo exige negociação adicional e tráfego de endpoint.

Inspecione:

• video control interface
• video streaming interface
• format descriptors
• frame descriptors
• opções de frame interval
• probe e commit controls
• alternate setting selecionado
• descritores de endpoint isochronous
• packet sizes e status das transferências

Se uma câmera funciona em 640x480, mas falha em 1080p, a evidência de descritor e bandwidth pode explicar o motivo.

Alternate settings importam

Muitos dispositivos UVC usam alternate interface settings para expor diferentes níveis de bandwidth. O host seleciona um alternate setting antes de começar o streaming. Se o alternate setting selecionado não casa com o formato ou bandwidth negociado, o streaming pode falhar ou perder frames.

Perguntas para responder na captura:

• qual alternate setting foi selecionado?
• qual max packet size do endpoint foi anunciado?
• qual formato e frame interval foram confirmados?
• as transferências isochronous começaram?
• erros de transferência apareceram imediatamente?
• o host caiu para um alternate setting mais baixo?

Essa é a evidência que o engenheiro de firmware precisa antes de mexer nos frame descriptors ou na configuração do endpoint.

Transferências isochronous priorizam temporização

Transferências isochronous são projetadas para dados sensíveis a tempo. Elas reservam bandwidth, mas não retentam como bulk. Isso é apropriado para vídeo, mas significa que dados descartados podem aparecer como corrupção de frame ou dado de imagem faltando, em vez de retransmissão limpa.

Causas comuns:

• bandwidth de barramento insuficiente
• problemas de topologia de hub
• dispositivos USB competindo
• alternate setting errado
• starvation de buffer no firmware
• limites do host controller
• problemas de cabo ou qualidade de sinal

A captura deve mostrar se os pacotes foram agendados, se os dados chegaram e se houve erros de status.

Não depure UVC só pela aplicação

Apps de câmera geralmente escondem a negociação USB. Eles podem escolher silenciosamente uma resolução menor, regredir para MJPEG, retentar frame intervals ou mascarar erros de transferência. Para firmware e fornecedores de dispositivo, isso não basta.

Uma boa captura de suporte UVC registra:

• formato requisitado
• tamanho de frame requisitado
• frame interval requisitado
• resultado de probe/commit
• alternate setting selecionado
• status das transferências
• fluxo de payload observado

Isso permite que as equipes expliquem por que um host ou resolução funciona e outro não.

Onde o Bus Scope entra

O Bus Scope foi feito para evidência USB. Para casos de UVC, ele ajuda a conectar descritores, control requests, seleção de endpoint e linha do tempo das transferências. Ele não precisa ser um visualizador de câmera para ser útil. O objetivo não é mostrar a imagem; é explicar o comportamento do barramento.

Para buscas como "UVC camera no video", "USB camera isochronous transfer failed" ou "webcam dropped frames USB capture", a resposta deve começar pelos descritores, alternate settings, bandwidth e status das transferências.