USB video capture devices unable to use full resolution

Start by reproducing the 720x480 failure with qv4l2, ffplay/ffmpeg, or gst-launch-1.0 on the listed uvcvideo and cx231xx devices, then compare behavior at reduced resolutions. Inspect the driver paths associated with the lost-frame, buffer-allocation, and URB errors. Done means full-resolution capture works without choppy output, missing frames, or cx231xx errors.

I am encountering an issue that prevents the Raspberry Pi 4 from capturing full resolution NTSC video (720x480) using a variety of low cost USB video capture devices. The devices work as expected with Ubuntu Linux running on a Mac laptop.

The issue impacts USB video capture devices that use both the cx231xx and uvcvideo drivers but it presents slightly differently (details below).

I am using a Pi 4 running Raspbian Buster, full system details are at the bottom. Could this possibly be some kind of issue / limitation with the Pi’s USB hardware? Is there anything I can to do resolve it? Thank you for looking into it.

Issue description using uvcvideo driver devices:
(534d:0021 “AV TO USB2.0” - sold as easyday DC60 on Amazon)

Attempting to preview or record at 720x480 resolution yields an extremely choppy stream, as if only a small number of the frames are actually making it through once a second or so.

This problem is reproduced using every software package attempted:

qv4l2
ffplay/ffmpeg ($ ffplay -f v4l2 -i /dev/video0)
gst-launch-1.0

Turning on the debug options for gst-launch-1.0 presents a long stream of “lost frame detected” and “failed to allocate buffer” which you can see here:
Reducing the resolution of the capture to 320x240 makes the video record/play normally (I can share example output if helpful to see). The gst-launch-1.0 debug output is reduced to just three lines for a clip of the same length as above.

The device works as expected and runs at full resolution on an Ubuntu 18.04.3 ($ uname -r output reads 5.0.0-23-generic)

Issue description using cx231xx driver devices:
(1f4d:0102 “G-Tek Electronics Group” - the August VGB100 on Amazon)

No output at all is seen in the same software options - qv4l2, ffmpeg/ffplay, gst-launch-1.0 when using at 720x480. $ cat /dev/video0 shows no characters at all in the terminal.

Turning on the isoc_debug parameter on the cx231xx driver module reveals dmseg errors that look like similar to this one in a continuous stream:

[94211.419521] cx231xx #0 print_err_status :URB packet 3, status -18 [Unknown].

The gst-launch debug log is very short and indicates some kind of problem with the v4l buffer: https://pastebin.com/N2TWgqxP

Reducing the screen resolution sufficiently (e.g. to 300x200) causes video to appear in all of the software packages (and characters in the terminal for cat /dev/video0). The kernel error messages stop as well.

This device also functions entirely normally on the same Ubuntu setup as above.

I have also tried other similar cx231xx devices and had the same result of no output (I but returned these ones before I figured out how to try the reduced screen resolution):

• Hauppauge USB 2Live (2040:c200 Hauppauge)
• Diamond VC500 USB 2.0 (also shows up the same identifier as the August device: 1f4d:0102 G-Tek Electronics Group)

Thanks much for your attention, would love to be able to get this working.

Some final notes:
I’ve tried each of the devices in all four USB ports (every 2.0 and 3.0)
There are no other USB devices plugged into the Pi at the same time - since I am accessing it over VNC
I am using rsync to grab the video to my main PC for review - I know that screen streaming over VNC can cause video to be choppy so this is not a cause here

System details

Raspberry Pi 4 - 4GB ram

$cat /etc/rpi-issue
Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5

$vcgencmd version
Sep 24 2019 17:34:30 
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

$uname -a
Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux