Hands-on with the new Raspberry Pi Zero 2 W. Video delay test and comparison with the first generation model.
Part II of USB video grabbers review (Linux)

Thanks to the nationals banks' printers and global supply chain crisis Raspberry Pi 3 or 4 currently cost around 2-3 times more than their initial price. As I suggested in github HyperHDR's wiki, the choice of Raspberry Pi is not obvious since you can host the app on more powerful Windows10 / macOS device that you already own. But it seems that the situation will change a bit.

Yesterday Raspberry Pi Zero 2 W with $15 tag price was announced. And the market price is really close to it. Today I test that model and compare it to the first generation Raspberry Pi Zero (without wifi, $5 initial price). New model's CPU is upgraded to a quad-core 64-bit ARM Cortex-A53 CPU clocked at 1 GHz. So now it has four faster cores compare to only one slower core in old model. What is also important, new CPU supports 64-bits AARCH systems and you know from v17 release info that 64-bits HyperHDR is faster up to 30% faster over its 32-bits version.







Beware that current 64-bits OS images don't support Raspberry Pi Zero 2 W and it needs tweaking to boot up but it will change in the coming days.

Those users who tried to run the application using an old one core Raspberry Pi Zero know how challenging is to use MJPEG video stream. So let's find it out using v18beta benchmark tool, how the situation has changed with the new model and if 512MB only RAM is causing some issues.

Due to RAM limitation we will focus on the headless systems so the test configuration will be a bit different than described in the previous article: both Rpi running HyperHDR are connected (all wired using LAN adapter) to the second PC host where we run the browser and the benchmark tool remotely. Because we are testing budget solutions I chose cheap MS2109 grabber clone as the reference device. Linux support for MS2109 grabber is limited compared to Windows and max. framerate for uncompressed YUV is only 30FPS.

Very important: grabber's 'quarter of frame' option is a must for the old generation Raspberry Pi and is enabled for all tests. Make sure you are familiar with the previous article that describes new HyperHDR feature: benchmark test available in the development v18beta.

1) Raspberry Pi Zero (first generation, one core, 32-bit armv6 OS)

Let's test the old Rpi first. 640x480x50 MJPEG gives the best result because 60FPS is too much for the device.
old-rpi-640-480-50

Very good result 74ms comparable to the Windows results from the previous article. But remember that the quarter of frame mode is enabled now.
On the other hand:


...it takes all the resources. If you turn 'HDR to SDR tone mapping' on (it's free only for YUV processing, not for MJPEG) or you are using not recommended and resource consuming direct connection from the raspberry pi to the ws281x or sk6812 LED strip (instead of using an external ESP device) then it won't work well. I can guarantee it.

For YUV 640x480x30 due to lower capturing framerate we have a latency between 90-100ms, but much lower CPU usage and we can consider that as a safe and recommended choice for that configuration:


For MJPEG 640x480x30 due to lower capturing framerate and CPU hungry MJPEG decoding we have a latency between 120-130ms:


Overall the situation for the old Raspberry Pi Zero is not as bad as some user claim, but we have to make some compromises. Subjective opinion is one thing, but using a benchmark we can measure the approximate lag of the video processing. The results also do not take into account the LED strip driver: using non-optimal user settings or old Arduino solutions could make the situation worse. Let's see how the new budget Raspberry Pi improves the performance.

2) Raspberry Pi Zero 2 W (latest generation, four cores, 64-bit aarch64 OS)

It was a bit tricky to install 64bit system but it works finally. So let's test it using MS2109 USB2.0 grabber first.

Clipboard01

Very good result for USB2.0 grabber using 640x480x60 MJPEG: 71ms. Better than the old Raspberry result. But for the old model it was almost unusable due to limited resouces. How about Raspberry Pi Zero 2 W?


There is a plenty of room for HDR tone mapping, black border detection and other options. Since YUV modes under Linux are FPS-limited and we do not need to care about resources there is no point in testing them using MS2109 (for 640x480x30 YUV the lag is the same as for the old model 90-100ms). Let's try other grabbers.

Ezcap 321 USB3.0 grabber (Raspberry Pi Zero 2 W, USB2.0)

ezcap321


Even using USB2.0 it's very impressive result: 67ms.



Thanks to offering NV12 encoding support resource usage is even much lower.

AV Access 4KVC00 USB3.0 grabber (Raspberry Pi Zero 2 W, USB2.0)

As you know from the previuos review that grabber doesn't have a scaler (capturing 1080p for 1080p only) and what is worse it uses MJPEG stream for USB2.0, but it offers excelent image quality both for SDR & HDR (with custom LUT table for HDR, better than all my Ezcap models). It's a killer for the old Rpi Zero and let's find out if the new model can handle it. Remember the 'Quarter of frame' mode is still enabled.

av

Not bad, the latency is about:75ms but enabling HDR tone mapping for MJPEG stream gives you about 15% penalty.



Update: Despite the info in the logs AV Access 4KVC00 under Linux ignore 30FPS capturing setting and is using 60FPS. So the results are for 1080p60 MJPEG. Resources usage is modest for 1080p MJPEG video proccessing on Raspberry Pi.

3) Final thoughts

So it looks like we have a small revolution in the budget range. I know there are similar ARM devices for the similar or higher price, but we are talking about the mainstream which is backed by the solid design & quality, users community and dedicated featured & stable OS. For tested capturing resolutions 512MB RAM is not an issue for HyperHDR. The only thing that I really miss is the lack of USB3.0. But that probably could hurt Raspberry Pi 4 position on the market when it returns to the initial price... but if that ever happens in the near future.

But one thing is almost obvious: for most HyperHDR configurations it does not make any sense to purchase a ~$90 Rpi3 when you've got almost the same with $15 Raspberry Pi Zero 2 W. Even if we limited to only one USB2.0 port without a USB hub (the other port we leave for a power supply as it is) then we can use it with a USB grabber and drive the LED strip using SPI bus: APA102/SK9822 directly, WS281x/sk6812 with HyperSPI. Do not forget about a 3.3v to 5v voltage level shifter in any case.

Comments

Us Cornel said…
That test sounds amazing, how can i upgrade to v.17.0.0.0 manuel? (i also want to test the new raspberry zero 2)
awawa said…
If you need to upgrade only HyperHDR to newer version you can use this guide https://github.com/awawa-dev/HyperHDR/discussions/43 Installing new OS aarch64 Raspbian that was used in the review is a bit more complicated.
Us Cornel said…
Okay, thanks. When will aarch64 be made available for all users?
awawa said…
I checked now and I see they released it two days ago: https://downloads.raspberrypi.org/raspios_lite_arm64/images/
HyperHDR could be installed after the boot. Because they switched to Debian Bullseye probably installing new beta v18 dedicated for that system will be needed: installer could be always found in the newest action in https://github.com/awawa-dev/HyperHDR/actions (older are deleted to save space)
Bo Pedersen said…
Is there something I'm missing here?
Given the Zero 2 does in fact support 64 bit instruction sets, i cannot figure out why this:
v17.0.0.0 of SD-card-image-rpi234-aarch64.zip
freezes the Zero 2 and wont boot... in fact I cant even get the arm64 lite you reference above to boot either... just the same frozen splash screen

While I have your attention, are you still of the camp that the sk6812 with a pi & esp32 via HyperSPI will give the most pleasing & balanced experience?
(Im just waiting for my ezcap321 to be WALKED to Canada from China, lol)

Given I've got a couple Pi 2 Zero's, and no pi3's or pi4's until the price comes down from space, in your professional opinion, would there be anything gained going the APA102/SK9822 with their direct SPI interface and considerably higher PWM?
I have on-hand a couple quality ESP32's(dual core ch340's) - should I also incorporate the expressif's into my build?(Ima noob to this, but my PC and 3D printing background is telling me YES! more processing = more better!?!)

One setup is going on my living room LG 65 CX, but the other is going to be kinda the crown jewel of my sons chrismas gift, which is a multi part, complete gaming corner overhaul! ....so, i wanna grab the best possible experience i can outta these Pi 2 Zero's!

Thank you for this AMAZING corner of tech I cant WAIT to envelope and incorporate!
awawa said…
Hi Bo

As it was mentioned in the article the Zero 2 wasn't support directly by Raspbery Pi OS 64 bit version at the time when it was written. And v17 aarach64 SD image is based on that OS version. The are couple possible solution: 1) simply rename or copy bcm2710-rpi-3-b.dtb file to bcm2710-rpi-zero-2.dtb in the SD boot partition (same location on SD card where wpa_supplicant.conf is uploaded) link 2) install current official Raspberry Pi OS aarach64 image and after boot install v18beta HyperHDR aarach64 package for Debian Bullseye from latest github action tab on the project page. Only aarch64 version needs this workaround for new Raspberry Pi Zero 2 W, 32bit HyperHDR v17 image should still work out of box.

I'm a great fan of sk6812 and still HyperSPI offers best performance as en external driver. For my 299 LED sk6812 setup it gives even higher refresh rate than already fast external serial port solution like HyperSerialEsp8266. Just remember that SPI cables should be rather short because of possible interference (around 15cm unshielded ordinary jumper cables are fine in my case). For higher numbers of LED ESP32 is recommended over ESP8266 for HyperSPI, because of larger SPI frame that can handle LED data buffer at once. RGBW shows it strength in the dark scenes, because for low RGB values it can balance the output with some white channel. Other RGB LED strip have tendency to shift the balance towards the green or blue. For HyperSPI serial port ch340 on Esp board is not mandatory as we don't use serial port to transfer the LED data (but you can connect to it to check out the performance data if you want).
awawa said…
One more thing about sk6812: I wasn't fully happy with neutral white version: there was too much yellow for my taste...for example blueish arctic snow on the TV but the LED strip effect was rather similar to sun white. Then I switch to cold white version and that was a very good choice.