Slow Response - TV Image to LED Shift (HyperBian a11, WS2812B, PWM, PiZW and Pi4)

So I first tried this on a PiZeroW, but seeing the slow response (despite plenty of CPU headroom), I tried a Pi4. Same results.

First off, here's what I'm seeing:

tl;dr - how do I reduce the 'lag'?

Details:

HyperBian 2.0.0-alpha.11

Controller Type: ws2812x

GPIO 18

DMA 10 (and I tried 5, no difference)

PWM Channel 0

Hardware LED Count 256

Capture Device Res: 720x480,5 FPS, 4 Size Dec.

Capture Device is this -

LED's: WS2812B (5 wires on each side, 2 power and gnd and then 3 (Red/Grn/Wht) on each end) -

Wiring/Cables:

Barrel Female - PC PSU (temporary but plenty of amps), 5V and GND off 4 Pin Molex

Barrel Male - Positive (MicroUSB +, Start of LED Strip Red, End of Strip Red) - Negative (MicroUSB -, Start of LED String White, End of Strip White)

HDMI Splitter is powered separately (for now) via 5V micro USB, 2A. 4K HDR in, Scale down to 1080 out to Capture Device

Green (Data) from start of LED Strip -> GPIO 18 (Pin 12)

White (GND) from start of LED Strip -> GND (Pin 2)

Not connected: Red from start of LED Strip, Red/Green or White wires from end of LED Strip.

Notes:

1. With the PiZero I use the MicroUSB, with the Pi4 right now because it's USB-C, I'm powering it separately. Same behavior regardless of Pi.

2. Hyperion is running under root (this was needed)

3. Set audio off in config.txt (no difference in response between it being on, or off in my case)

4. At the moment, I'm using the full 5m/300LED strip, but only 256 on the strip (just didn't want to cut it if I have to return them), the remaining LED's don't light up (as expected)

5. No difference in response when I didn't have the tail end of the strip +/- connected to the PSU.

6. Currently running no resistors or caps... seems to be several out there with better response that I'm seeing without doing any of that. As I'm not trying to power the strip off the Pi (it doesn't have the current anyhow).

7. FWIW, the Live Video preview in LED Layout Preview looks terrible, massively desaturated.. is this by 'design'? Clearly it's getting more color detail than it shows here because the strip does set the right (close enough, haven't bothered calibrating yet) colors.

I've seen other videos of people claiming to do this same setup, even in a PiZero and video of their setup looks more responsive.

Could this be a problem with the capture card (or the scaling to it)? Any ideas on how to test if it's the weak link?

So, changing "encoding" to "MJPEG" worked! Great response now! Thank You!

(For others, for reference, changing max_usb_current=1 (and rebooting) didn't change anything)

HOWEVER... CPU utilization jumped up to 38% and I see in the log the FPS is set to the configured 5, but then immediately to 60!

Here's what's in the config json (I had to export, edit the 'encoder' and re-import) for that section

"grabberV4L2": {

"available_devices": "USB Video: USB Video",

"blueSignalThreshold": 0,

"cecDetection": false,

"cropBottom": 0,

"cropLeft": 0,

"cropRight": 0,

"cropTop": 0,

"device": "/dev/video0",

"device_inputs": "0",

"enable": true,

"encoding": "MJPEG",

"flip": "NO_CHANGE",

"fps": 5,

"fpsSoftwareDecimation": 0,

"framerates": "5",

"greenSignalThreshold": 100,

"hardware_brightness": -11,

"hardware_contrast": 148,

"hardware_hue": 0,

"hardware_saturation": 180,

"height": 480,

"input": 0,

"noSignalCounterThreshold": 200,

"redSignalThreshold": 0,

"resolutions": "1",

"sDHOffsetMax": 0.46,

"sDHOffsetMin": 0.4,

"sDVOffsetMax": 0.9,

"sDVOffsetMin": 0.1,

"signalDetection": false,

"sizeDecimation": 4,

"standard": "NONE",

"width": 720

},

and here's what the log shows

2021-11-02T22:28:54.074Z [hyperiond V4L2] (DEBUG) (Grabber.cpp:141:setWidthHeight()) Set new width: 720, height: 480 for capture

2021-11-02T22:28:54.074Z [hyperiond V4L2] (INFO) Set new frames per second to: 5 fps

2021-11-02T22:28:54.075Z [hyperiond V4L2] (INFO) Set image size decimation to 4

2021-11-02T22:28:54.075Z [hyperiond V4L2] (INFO) Set flipmode to NO_CHANGE

2021-11-02T22:28:54.314Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:151:init()) Set device (path) to: USB Video: USB Video (/dev/video0)

2021-11-02T22:28:54.314Z [hyperiond V4L2] (INFO) Set new frames per second to: 60 fps

2021-11-02T22:28:54.314Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:488:init_device()) Set device input to: Camera 1

2021-11-02T22:28:54.316Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:614:init_device()) Set resolution to width=720 height=480

2021-11-02T22:28:54.317Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:631:init_device()) Set framerate to 60 fps

2021-11-02T22:28:54.317Z [hyperiond V4L2] (DEBUG) (V4L2Grabber.cpp:739:init_device()) Pixel format=MJPEG

2021-11-02T22:28:54.326Z [hyperiond V4L2] (INFO) Started

Any idea's on changing the framerate (I suspect this is why the CPU utilization is so high)?

Oh, nevermind, I was able to choose 10 (a bit of a notable delay) but then 20 seems responsive enough and it kept the MPJEG setting (even though it's not there in the web configurator).

CPU is now at 20%, I think I will try moving back to the PiZero.

I suspect "5" wasn't a valid value for this device using MJPEG and that's where the jump to 60 came from.

Zitat

you can also do that (normally) in WebUI but you have to be logged in as expert, in top right of webpage change user from standard to expert.

Oh fantastic. That explains so much. (if the dev is listening, perhaps "settings level" is not a great descriptor of what's behind that link)

Zitat

I'd try to change FPS in video grabber to let's say 30 and resolution - as low as possible.

Not sure at which stage you're recommending this (as the problem has been solved). Initially I was already at 720x480 and 5FPS. Low/High CPU usage (nor Core-Count either) wasn't causing the bottleneck as reported. Once I changed the encoding method, it performed great, even at 60fps (and 40% CPU utilization). The 20fps I'm at now seems to be the sweet spot for responsiveness while keeping the load down, for this capture device.

So ultimately the 'problem' articulated here was directly related to my choice of capture device falling behind due to the encoding method YUYV (default or chosen by some element in Hyperbian) not being as efficient as MJPEG is *for my capture device*. Which is a pretty common one - MACROSILICON - idProduct 2109.

The only thing to try now is reverting back to the Pi Zero W and seeing if it will perform just as well.

Just a post to mark the thread as resolved. Thanks!