These captured screens share typical HDR problem. New fix using LUT tables is on the way on github for testing. Or you can use the old trick with v4l2-ctl but the color reproduction is worse than new one.
Effects or fixed colors within Hyperion dont use grabber but they dont use settings in the imageprocessor either. So it says only that your leds are working correctly (as hardware) but it doesn't say anything about image processing settings for them. Check settings below to reduce brightness.
1 v4l2-ctl is a part of v4l-utils package that you can install on your system
2 too bright LEDs could be caused by LED configuration in Hyperion (or by the LED hardware themself) and could be not related to the grabber
3 check & verify the live view capture from Hyperion (for ex link )
OK, I understand that and I repeated many times on this forum that we can't fix HDR from SDR result because some information are lost. As I review fast-hdr there is some math behind these results and they are way better than manipulating with saturation/brightness/contrast (doesn't work with HDR10+ and Dolby Vision either, don't know if there is any windows player that can handle DV) even if it's more resource hungry solution. So there is a tone mapping no doubt but rather "HDR" (broken by the grabber/matrix/splitter/scaller) to SDR - I thought that was clear.https://hyperion-project.org/members/andrew_xxx.3327/
@Andrew_xXx you have alternative in the first post and I mentioned it: HDFury diva or x4 for $$$, other software alternatives are always workaround: that one produces very good result in the real time on Rpi3 and it's first attempt to implement it in Hyperion. You don't have to enable it, it's only an option that you can have or not. Beside if you could read it first before writing I would appreciate it:
I hope that I didn't break anythink 
https://github.com/hyperion-project/hyperion.ng/pull/928
Hey, awesome!
Is this not possible to add it to hyperion directly? With the a toggle in the WebUI?
https://github.com/awawa-dev/hyperion.ng.githttps://www.mydealz.de/deals/h…-2-in-1-konverter-1630056
edit: not sure if it is a switch or splitter
It's only a switcher not splitter: one of two outputs -> 1 monitor or 1 output -> one of two monitors
Thanks! I will try but I'm not promising anything, because that part of WWW interface code is a little bit of magic for me (as QT & C++ that I've forgotten ... too many years developing in c# )
Summary of HyperHDR fork changes:
- Overall performance without tone mapping for USB grabbers improved x10 (MJPEG) and x3 (YUV) over Hyperion 2.0.0.8A thanks to optimization & using of multi-threading
- Direct support for USB grabbers under Windows 10 using Microsoft Media Foundation (really fast & of course multi-threaded)
- Build for newer Raspbian Buster. It's a complete migration from older Raspbian Stretch.
- Option for hyperion-remote, JSON API and web GUI remote to turn on/off HDR tone mapping
- MJPEG & YUV HDR LUT tone mapping
- Hardware brightness&contrast control for USB grabbers (both Windows and Linux)
- Ready to write SD images of HyperHDR
- New option to choose video encoding format (for multi format grabbers for ex. Ezcap 269, MS2109 clones).
- Add configurable Signal Threshold Counter option for signal detection
- Option for luminescence & saturation for hyperion-remote
- New advanced LED mean color algorithm in image->LED mapping
- New weighted advanced LED mean color algorithm in image->LED mapping
- Improved backlight algorithm to minimize leds flickering on the dark scenes (smoothing with continues output is still recommended)
- Add old style color calibration
- Fix for SK9822 leds on SPI (aka fake APA102)
- Required libglvnd library dependency included for tar container.
- Improved YUV decoding using LUT tables for speed up
- Windows installer contains default LUT table
- Installers for DEB & RPM now include LUT table
Results (live HDR)
Testing lag:
[MEDIA=streamable]wyspuy[/MEDIA]
[MEDIA=streamable]nunadx[/MEDIA]
I have managed to apply 3D LUT filter for HDR content from other project and it looks really nice. Good news is that it can be done in real time.
More to come soon (with sources for Hyperion-NG) in separated thread because is rather not related to 4k grabbers/splitters.
SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center
Results (HDR video)
Before and after on some HDR/BT2020 content that was broken by the ezcap 269 video grabber:
Results (benchmark)
Keep in mind that the delay is only for the grabber image processing.
Image to LEDS, effects, black border detection, portal handling etc. take additional resources (if something left).
Live testing: do not compare lag by comparing TV vs WWW Hyperion video live preview (as others factors come in play) but TV vs LEDS.
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
Fork installation
Ezcap 269 works on USB 2.0 with MJPEG encoding.
The penalty of MJPEG are jpg artifacts that can be visible on LED especially on dark scenes. Even if the movie is stopped but the grabber is still working there is a little noise. YUY2 is better and withgout these artifacts. Higher resolution can help quality of MJPEG stream. If you try to use MJPEG with current Hyperion.ng release you will be limited by resources to few FPS and lag may appear. You can reduce lag (and quality) with size decimation or you can try multithreaded fork:
https://github.com/awawa-dev/HyperHDR
Installation from package
Before proceeding make sure that you have working Hyperion.NG setup because basic&common configuration isn't part of that topic. Then uninstall it before installing my fork.
1 Connect Ezcap 269 to USB 2.0 (MJPEG) or USB 3.0 (YUY2) port of Rpi3/Rpi4.
2 Install Hyperion from my fork.
3 Generate LUT table from the LUT generator page (link in the grabber configuration page) and upload it to the Hyperion configuration folder.
Typically /home/pi/.hyperion/.....
That file (lut_lin_tables.3d) is also needed for YUV grabbers - internal table can be generated by Hyperion in this case if missing but without support for HDR.
4 Restart service or RPi. Then enable HDR tone mapping in the grabber properties. If your are using MJPEG encoding then for better performance try Border mode (mainly for leds) or the full screen to preview result.
5 Check result in the live feed (upper right corner) and debug log (System->Log). Without that unfortunately I cant help if something goes wrong.
Installation on SD card
Rpi 1 / Zero
SD-card-image-rpi1-armv6.zip
Rpi 2 / 3 / 4
SD-card-image-rpi234-armv7.zip
Just write img file on SD card like Hyperbian:
https://docs.hyperion-project.org/en/user/HyperBian.html
LUT table file is included!
Default host changed from Hyperbian to hyperhdr so search www panel on:
http://hyperhdr:8090/
COPY HYPERION CONFIGURATION FOLDER FROM ReadOnly BACKUP TO ReadWrite TEMPORARY FOLDER
RaspberryPi configuration: move from ReadOnly backup folder to Hyperion configuration folder
SSH to raspbian and create a script in user folder:
hyperion.sh (make it executable, write-access need to be switched on, run it from /etc/rc.local)
#!/bin/bash
FILE=/tmp/.hyperion/me
if [ -f "$FILE" ]; then
echo "config exists"
else
/bin/cp -avr /home/pi/hyperion/. /tmp/.hyperion/
fiMake symlink /home/pi/.hyperion/ to /tmp/.hyperion/ first and create file /home/pi/hyperion/me
MadVR configuration
This results in:
- automatic hardcoded black bar removal (not necessarily but then we don't need to do it with hyperion and the movie is always stretch to the full screen when MpcHC player is notified by MadVR)
- automatic resolution switching
- and mostly important: output SDR into BT2020 color space (there is an option enabled only for nvidia).
- and same important HDR passthrough
For Ezcap set that in Nvidia driver panel: RGB, 8bit, full range and of course enable HDR in Windows.
Corelec:
Preparation
I strongly suggest to install Raspbian with read only mode for a sake of SD card. It also enables switching to write mode if needed.
The solution is described in the following link but make attention to comments because I had some troubles with /tmp folder and fixing that is a crucial thing (there are some folders hardlinked to /tmp and need to be re-created). Otherwise /tmp remains read-only folder after each reboot.
https://medium.com/swlh/make-y…spbian-buster-c558694de79
Always verify output format on TV because there is possibility that you can have "almost" very nice output for HDR movie & Hyperion but in fact the content can be transcoded by software/graphic card to SDR output on the fly (these is the least desirable option, because it causes TV picture degradation).
I want to share my configuration for HDR & SDR content and HyperionNG/RaspberryPi3. I made a very long way from utv007 & Rpi3 for SDR years ago. Well, SDR is not a problem but HDR is another story. This solution applies to 1080/4k PC movie player configuration only. Any nonstandard gaming FPS (freesync,gsync et) is not a concern: hardware for that solution doesn't exists yet beside almost analog one: the external capture camera.
On the market there are only two budget products that can handle it: HDFury x4 (1080 only but it's not so critical for Hyperion usage) and HDFury Diva. You can save yourself money and abandon testing other Chinese matrix/scallers/grabbers that suppose to do the same: they can't at least for now. HDR images that they outputs have bleak colors and are almost useless for our Ambilight experience. Ezcap I use is no better than them....but it allows one hack to make HDR working almost perfectly.
So you can buy one of HDFury devices or go for compromises: results are almost as good but not quite. And there is a need to output movie always in BT2020 color space (the solution I chose) or to switch configuration manually between HDR/SDR content (otherwise this would results in totally over-saturated colors).
Used hardware:
Rpi3->Rpi4, WS2801, ezcap 269, PC mediaplayer (mpc hc, latest madVR, oldie but a goldie myHTPC as frontend) with Flirc for remote control, nvidia gfx, HDR enabled TV/projector.
The scheme is on the picture below:
USB 2.0 is fully sufficient for Ezcap 269 in terms of speed (thanks to MJPEG compression) and power consumption (well, according to measures it's 0mA so it's probably powered by HDMI line).
USB bus usage for 1080/30 mode is very low even for USB 2.0
Some information about Ezcap 269:
If the Ezcap is connected to USB2.0 it will report only MJPEG encoding:
But when we connect it to USB3.0 YUV encoding is also available:
There are some significant differences between that grabber and solutions based on analog (or HDMI->analog) UTV007: picture quality and you don't have to set crop for a frame or manually calibrate colors (beside the trick for HDR).
Sorry for any spelling mistakes: English is not my primary.
The camera is a tempting option but it's prone to interference/changes. Before ezcap 269 I considered it. For gaming and higher / exotic FPS I think camera it's still better solution. Even Diva is limited to only 60fsp. The side effect of copy protection on hardware level and difficult access to restricted documentation made that hell even for Chinese engineers. It's almost unbelievably that after so many years only HDFury acquired that technology for "budget" level devices.
But for my movie player that grabber became almost perfect solution. I had some trouble with win10/madvr configuration that would work with SDR and HDR on one side and ezcap & hyperion on the other. Maybe I describe my final configuration in the other thread in future.
Some things to clarify about ezcap and HDR.
1) even if top command says that overall CPU usage with v4l2 hyperion capturing video format 640x480 decimation 1 is about 120% (out of 400%) it simply says that single main threat of the Hyperion is running out of resource. Press 1 to see core usage. Stats are for Rpi3. With my path CPU usage is 80% and it's acceptable for me: no more lags TV vs LEDS. But there is no more space left for additional filters.
2) we can chose FPS...but for ezcap 269 minimum FPS is 30 - this is the driver/hardware minimum limit. You can set lower FPS but it will be override. So you can't save some resources using that settings.
3) there are some programs that try to fix incorrect color space. I saw some proof of concept in fastled project but I don't now if it works and I think it's only for few hundred points (whole image it's few hundred thousands pixels at least).
4) and most important: you can't fix SDR into HDR again - some information are lost. Simply we don't have meta-data that are transmitted via HDMI to the TV. It's a job for the hardware grabber or matrix to analyze them and currently only few devices from HDFury can do it. In that metadata there are some important information about current frame (for ex. chroma/saturation range is dynamic and can be set in that metadata). We can better or worse try to guess current color gradient by analyzing whole frame and then correct it. It's totally unrealistic in realtime on Rpi. Kodi uses regular graphic card shaders to try to correct them. Color correction that we can apply to ezcap is one of best on the market and fastest and least resource hungry for sure.
Further saturation is only possible by algorithm in hyperion NG and it requires YUV format (fast and simple) or more complicated matrix operation for RGB. Current release converts MJPEG directly into RGB and there is no CPU resource left even for that with higher resolution on Rpi3.
I noticed that sometimes v4l2-ctl --set-ctrl looses it's settings. For ex. it display that saturation is 255 but it isn't (captured screen tells different) and it need to be reapplied. I've attached that script to the cron.