UVC-Kamera-Isochronous-Transfer-Debugging: Bandbreite, Alternate-Settings und gedroppte Frames

USB-Video-Class-Devices sind überall: "Webcams, Industriekameras, Mikroskopkameras, Embedded-Vision-Module und Test-Fixtures. Wenn eine UVC-Kamera scheitert, ist das sichtbare Symptom meist einfach: kein Video, niedrige Frame-Rate, gedroppte Frames oder eine Kamera-App, die bei einer Auflösung läuft, bei einer anderen aber scheitert." Die USB-Evidence ist weniger einfach. UVC-Kameras hängen oft von Deskriptoren, klassenspezifischer Verhandlung, Alternate-Interface-Settings, Endpoint-Bandbreite und Isochronous-Transfer-Verhalten ab. Ein generischer "camera not working"-Report enthält selten genug Information.

UVC ist mehr als Enumeration

Ein UVC-Device kann korrekt enumerieren und trotzdem scheitern zu streamen. Enumeration beweist nur, dass der Host Deskriptoren gelesen und eine Konfiguration gewählt hat. Video-Streaming erfordert zusätzliche Verhandlung und Endpoint-Traffic.

Prüfen Sie:

• Video-Control-Interface
• Video-Streaming-Interface
• Format-Deskriptoren
• Frame-Deskriptoren
• Frame-Intervall-Optionen
• Probe- und Commit-Controls
• gewähltes Alternate Setting
• Isochronous-Endpoint-Deskriptoren
• Paketgrößen und Transfer-Status

Läuft eine Kamera mit 640x480, aber scheitert mit 1080p, kann die Deskriptor- und Bandbreiten-Evidence erklären, warum.

Alternate-Settings zählen

Viele UVC-Devices nutzen Alternate-Interface-Settings, um unterschiedliche Bandbreiten-Level zu exponieren. Der Host wählt ein Alternate-Setting vor dem Streaming. Passt das gewählte Setting nicht zum verhandelten Format oder zur Bandbreite, kann Streaming scheitern oder Frames droppen.

Capture-Fragen:

• welches Alternate-Setting wurde gewählt?
• welche Endpoint-Max-Packet-Size wurde beworben?
• welches Format und Frame-Intervall wurden committed?
• haben Isochronous-Transfers begonnen?
• sind Transfer-Fehler sofort aufgetreten?
• ist der Host auf ein niedrigeres Setting zurückgefallen?

Das ist die Evidence, die ein Firmware-Engineer braucht, bevor er Frame-Deskriptoren oder Endpoint-Konfiguration ändert.

Isochronous-Transfers priorisieren Timing

Isochronous-Transfers sind für zeitkritische Daten gedacht. Sie reservieren Bandbreite, retrien aber nicht wie Bulk-Transfers. Das ist passend für Video, aber es bedeutet, dass gedroppte Daten als Frame-Korruption oder fehlende Bilddaten erscheinen statt als saubere Retransmission.

Häufige Ursachen:

• unzureichende Bus-Bandbreite
• Hub-Topologie-Probleme
• konkurrierende USB-Devices
• falsches Alternate-Setting
• Firmware-Buffer-Starvation
• Host-Controller-Limits
• Kabel- oder Signal-Quality-Probleme

Der Capture sollte zeigen, ob Pakete geschedult waren, ob Daten ankamen und ob Status-Fehler auftraten.

UVC nicht nur aus der App debuggen

Kamera-Apps verstecken oft die USB-Verhandlung. Sie können stillschweigend eine niedrigere Auflösung wählen, auf MJPEG zurückfallen, Frame-Intervalle retryen oder Transfer-Fehler maskieren. Für Firmware- und Device-Vendors reicht das nicht.

Ein guter UVC-Support-Capture zeichnet auf:

• angefragtes Format
• angefragte Frame-Größe
• angefragtes Frame-Intervall
• Probe/Commit-Ergebnis
• gewähltes Alternate-Setting
• Transfer-Status
• beobachteter Payload-Flow

So können Teams erklären, warum ein Host oder eine Auflösung läuft, ein anderer aber scheitert.

Wo Bus Scope passt

Bus Scope ist für USB-Evidence gebaut. Für UVC-Fälle hilft es, Deskriptoren, Control-Requests, Endpoint-Auswahl und Transfer-Timeline zu verbinden. Es muss kein Kamera-Viewer sein, um nützlich zu sein. Das Ziel ist nicht, das Bild zu zeigen; das Ziel ist, das Bus-Verhalten zu erklären.

Für Suchen wie "UVC camera no video", "USB camera isochronous transfer failed" oder "webcam dropped frames USB capture" sollte die Antwort mit Deskriptoren, Alternate-Settings, Bandbreite und Transfer-Status beginnen.