HDR Solution

    @Jake Ladley I dont want to hijack the thread so short answers for your question: Windows build is only an option included lately, for me and some users as an alternative. The fork was started and optimized for Rpi and using multithreading to enable tone mapping processing. I'm using ezcap 269 but had some feedback that it work for many modern HDMI grabbers for example MacroSilicon MS2109 clones.


    And back to the subject: dont give up on the grabber before you can exclude software or some settings. Even cheap MS2109 has a lag only about ~100ms.

    Quote from Awawa

    @Davy For lag testing on HDR content here you have one:
    [MEDIA=streamable]wyspuy[/MEDIA]
    and grabber is set to much higher resolution then in samples from this post without any decimation. And yes, resolution does matter for the quality.


    Wait that looks awesome! I would really like to take a look at your full build but sadly I am not allowed to view your profile and therefore your threads. Can you link it here if you posted your setup somewhere else before? :)

    Quote from Mo Jo

    Wait that looks awesome! I would really like to take a look at your full build but sadly I am not allowed to view your profile and therefore your threads. Can you link it here if you posted your setup somewhere else before? :)

    Fixed now. And check "Hyperion Setup Showcase" subforum ;)

    Quote from Jake Ladley

    This looks great!
    What USB grabber do I need to buy? So this is including HDR?
    I looked at your thread, and I don't want to use a windows build. I am running everything on a raspberry pi and have my xbox running through a HDMI splitter/down scaler.
    The solution works that @Vassilli recommended with the second Xolorspace splitter as this strips the HDR content, but i am currently converting HDMI to RGB then into a RGB usb capture card but the quality is really low.
    I bought a USB grabber today, and tried it but there is a lag between the video and LEDs, so I am sending this back.


    I just need a good USB HDMI grabber, and maybe i can skip buying the second Xolorspace splitter if your software supports HDR?



    In the Web UI change the resolution to 800x600 and it will stop the lag

    Quote from Awawa

    Fixed now. And check "Hyperion Setup Showcase" subforum ;)


    Thanks! :)
    But your build is only if you use a PC right? I am looking for a solution for my 4k HDR 60HZ TV with only a RPI, Splitter, HDMI Grabber etc. Do you know anything which I could copy?

    PC media player in my setup really doesn't matter. It works for any player that outputs HDR or BT2020 or even old SDR (for faster multithreading processing without tone mapping) content that is captured by the grabber and processed on Rpi (or also on Windows in the latest build).

    Quote from Awawa

    PC media player in my setup really doesn't matter. It works for any player that outputs HDR or BT2020 or even old SDR (for faster multithreading processing without tone mapping) content that is captured by the grabber and processed on Rpi (or also on Windows in the latest build).


    Thanks! :) I will go your route but I will use this grabber and a Raspberry Pi Zero W. That should work without any major latency increases, right? :)

    @Awawa when I checked your post in the past I understood that to change from SDR to HDR you had two different configs. Is it right or it automatically changes depending on the input?

    Config is and was only one. There is a switch (on web remote panel and in the grabber properties and in hyperion-remote) to choose hdr/sdr at once. Or to automatize process with home-assistant and for example Denon amplifier to detect content. Or to make player to output always HDR/BT2020 stream (SDR is upconverted and that is a very nice option if the TV support HDR) as I do.


    Quote from Mo Jo

    Thanks! :) I will go your route but I will use this grabber and a Raspberry Pi Zero W. That should work without any major latency increases, right? :)


    It's a single core CPU so don't expect fireworks but MJPEG and YUYV decoding is still faster than in the mainstream. It's a very old benchmark before few signification optimization from next versions but you can see what to expect on single core for MJPEG that is most problematic for decoding: SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center

    Ah Ok! The splitter that I have switches automatically depending on the input so no action from the user is needed.

    Quote from Awawa

    It's a single core CPU so don't expect fireworks but MJPEG and YUYV decoding is still faster than in the mainstream. It's a very old benchmark before few signification optimization from next versions but you can see what to expect on single core for MJPEG that is most problematic for decoding: SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center


    Thanks for your fast answer! :)


    So with your older version this benchmark was created with I'd have to expect around 80ms of latency with a Pi Zero if using 800x600 and 10fps, right?
    This might have decreased a little bit since you've done a lot of work on your software since then. Comparing these results to your RPI 3 benchmarks using 30 fps and 1024x768 you get 208ms with single core but with your enabled multi core and HyperHDR instead of Hyperion only 19 ms and full 30fps.


    So in conclusion, by using a Pi 3 instead of a Zero I get enabled multi core, can use a higher resolution (1024x768 instead of 800x600), get higher fps (30 instead of 10) and the latency is only a quarter?


    Then I have one last question, do you think these improvements are worth the 25€ price difference because I have no idea how to interpret these better results.
    Only the much faster latency is something I can get my mind around. At least in games the difference between 20ms and 80ms is really noticable. If it's the same here I think it's already worth it. But I also saw someone using only using 480 x 360 with the Pi Zero and the final colour results seemed to be fine too.


    Thanks so much in adance and for all your help!
    Best regards :)

    Yes, there are also other optimization in later version...skipping unnecessary video buffer resizing, removing coping pixel by pixel, implementing LUT YUV->RGB decoding etc. You're referring to this more recent results (HDR tone mapping is disabled for comparing because Hyperion.NG doesn't have it, it need :( benchmark
    I dont update it for Rpi Zero, maybe some other user with Rpi0/1 can copy-paste log with benchmarks or you can test the fork yourself and check logs.


    For me the main problem with Hyperion.NG on every Rpi is that it can run only on single thread, when the CPU reach 100% (of 400% available for RPi 2/3/4, more in FAQ on git) then every module of Hyperion choke for resources: grabber, image to led, web panel et. So it's not only grabber performance take damage...to be fair the same situation could meet HyperHDR if you run it on single core CPU like Rpi1 without limiting FPS (grabber: skipping frames option). On multi core CPU it will take advantage of the platform. So the answer for your question: yes, it definitely worth to spend that additional 25e ;)


    Maybe if the grabber supports YUV encoding then there is a possibility that Rpi 0/1 could be enough.

    Thanks again for your fast answer! :)


    You convinced me that the investion is worth it!


    I just saw that a Pi 4 is only 3€ more expensive. Is your software working even better when using a Pi 4 instead of the Pi 3 because it has much higher cpu performance and 1 GB more RAM? Or are they any compatibility problems?


    Thanks in advance!

    Yes, I'm using personally Rpi4 after upgrade from Rpi3. No compatibility problems except Dispmanx is probably broken for Rpi4 in hyperion if you need it: https://github.com/hyperion-project/hyperion.ng/issues/954 I dont use it so I cant confirm.


    Two things make difference:
    1) USB 3.0 that is required for some grabbesr for better quality modes (YUV)
    2) not only higher CPU frequency but also much better RAM timings as you can see in my benchmark: the higher resolution the bigger gap between Rpi3 and Rpi4
    Ram:
    400 Pi 1/Pi 2,
    450 Pi 3/Pi Zero
    500 Pi 3A+/3B+
    3200 Pi 4B.

    Quote from Awawa

    @Jake Ladley I dont want to hijack the thread so short answers for your question: Windows build is only an option included lately, for me and some users as an alternative. The fork was started and optimized for Rpi and using multithreading to enable tone mapping processing. I'm using ezcap 269 but had some feedback that it work for many modern HDMI grabbers for example MacroSilicon MS2109 clones.


    And back to the subject: dont give up on the grabber before you can exclude software or some settings. Even cheap MS2109 has a lag only about ~100ms.


    Hey Awawa,
    I have installed your version of Hyperion on my Pi now, and the USB grabber picture looks great with HDR enabled!
    However, my problem now is that the Pi now won't talk to/control the WLED over wifi. All the settings are the same as the last build, including IP, port etc but now it doesn't work at all which I am confused about.
    Any suggestions?

    @snikcers please, github or PM ;)
    Check logs because probably you've got there answer, as can be seen on video tutorial wled.local is properly recognized in Windows 10.



    On Linux it from some reason appends .localhost => it's wrong and it can't find it

    After set IP to WLED address it works

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login