HyperHDR: prepare for building & buying components, step 5: Device for hosting HyperHDR

 Guide for building your own ambient system:


Which platform: macOS, Windows or Raspberry to choose?

Well, that's depends. Currently Windows 10 version (v15) is considered stable and recommended on equal condition as Linux packages for x86/RaspberryPi. For Apple's macOS there is new release built for x64 platform but it works with M1 also. For native M1 Apple SOC we must wait for the official support from the QT libraries although you can try you skills with unofficial guides for compiling the libraries from the sources.

Windows PC has typically much, much higher CPU power than Raspberry Pi and some grabbers lack support for Linux. On the other hand the hardware of Raspberry Pi could drive some types of led strips directly (SPI interface). For Windows PC or macOS HyperSerialWLED or HyperSerialEsp8266 are recommended as drivers for the LED strip.

And for Raspberry Pi: which model to choose? If your grabber supports only MJPEG then Pi Zero is too weak to handle it. Pi Zero probably would support YUYV encoding (YUV/NV12/I420).

Some high quality devices like Ezcap 269 requires USB 3.0 to enable all of available options because USB 2.0 bandwidth is not sufficient.
So Raspberry Pi 4, PC, mac is recommended in that case.

Even Raspberry Pi 3 is enough for most tasks. Contrary to the latest at time of writing Hyperion 2.0.0-alpha.8 the HyperHDR takes advantages of all CPU cores.

A sample benchmark's result to compare them:

Hyperion.NG, YUV, Rpi 3, single core
640x480 15fps => delay 25ms, 40% CPU, 15FPS
1280x720 10fps => delay 70ms, 70% CPU, 10FPS
1920x1080 2fps => delay 170ms, 40% CPU, 2FPS

Hyperion.NG, MJPEG, Rpi 3, single core
640x480 30fps => delay 84ms, 100% CPU!!!, 12FPS
1024x768 30fps => delay 208ms, 100% CPU!!!, 5FPS
1920x1080 30fps => delay 542ms, 100% CPU!!!, 2FPS

HyperHDR, YUV, Rpi 3, multithreaded
640x480 15fps => delay 8ms, 10/5/0/0% CPUS, 15FPS
1280x720 10fps => delay 22ms, 20/10/0/0% CPUS, 10FPS
1920x1080 2fps => delay 57ms, 5/2/0/0% CPUS, 2FPS

HyperHDR, MJPEG, Rpi 3, multithreaded
640x480 30fps => delay 10ms, 25/5/0/0% CPUS, 30FPS
1024x768 30fps => delay 19ms, 50/10/10/0% CPUS, 30FPS
1920x1080 30fps => delay 50ms, 60/50/30/0% CPUS, 30FPS

HyperHDR, YUV, Rpi 4, multithreaded
640x480 => delay 7ms
1280x720 => delay 11ms
1920x1080 => delay 30ms

 

Comments

Unknown said…
Hallo kannst du mir mal verraten wo die fertige .bin Datei ist? Wollte dein HyperSerialWLED gerne an meinem ESP ausprobieren. Grüße
awawa said…
Sorry, only English please ;)
merc_cooper said…
Hi, can you please explain how to configure LUT? I see there is an option to import 3dl but it doesn't update the old .3d file
awawa said…
Currently there is no option to overlay one LUT table generated by the page by the new one imported from 3dl. You must choose one.
Dawid said…
where i get the .bin for Wemos D1 mini? thanks a lot!
awawa said…
Hi
In the "Releases" tab on the github project's homepage.
Harry said…
Is there a way to install HyperHDR on an existing Libreelec/Raspi4?
awawa said…
Do you have an USB grabber because without it it's pointless?
DEB packages won't work for sure.
Never try it personally but probably there is a way... a bit tricky and you have to have some knowledge about Linux: on Libreelec download HyperHDR-15.0.0.0-Linux-armv7l.tar.gz, extract it, try to run hyperhdr. If it works then if you want to have HDR tone mapping you must also extract manually share\hyperhdr\lut\lut_lin_tables.tar.xz (lut_lin_tables.3d) to the same folder or the folder where hyperhdr's configuration is stored (usually hidden .hyperhdr in user's home directory). Check logs if hyperhdr finds it.
tedvoorend said…
Hi, I have currently hyperion.NG installed on my raspberry pi 4 and using software capture (610x LEDs HD107s). Do you think HyperHRD will have better performance in software capture? Currently I have a software capture about 40 fps (didn't tested my delay yet).
awawa said…
For software capturing it probably doesn't make much difference when x11 grabber is considered for Rpi. Hardware capturing with USB grabber is different story.