1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

HDR Solution

Discussion in 'Hyperion General' started by Vassilli, 21 October 2020.

  1. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    @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.
     
  2. Mo Jo

    Mo Jo New Member

    Messages:
    9
    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? :)
     
  3. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    Fixed now. And check "Hyperion Setup Showcase" subforum ;)
     
    • Like Like x 1
  4. Davy

    Davy New Member

    Messages:
    4

    In the Web UI change the resolution to 800x600 and it will stop the lag
     
  5. Mo Jo

    Mo Jo New Member

    Messages:
    9
    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?
     
  6. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    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).
     
    • Like Like x 1
  7. Mo Jo

    Mo Jo New Member

    Messages:
    9
    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? :)
     
  8. Vassilli

    Vassilli New Member

    Messages:
    8
    Hardware:
    RPi3, +nodeMCU/ESP8266
    @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?
     
  9. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    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.

    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
     
    • Like Like x 1
  10. Vassilli

    Vassilli New Member

    Messages:
    8
    Hardware:
    RPi3, +nodeMCU/ESP8266
    Ah Ok! The splitter that I have switches automatically depending on the input so no action from the user is needed.
     
  11. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    If you set player to output bt2020 there is no need for user interaction either ;) The same effect can be achieved the HA .
     
  12. Mo Jo

    Mo Jo New Member

    Messages:
    9
    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 :)
     
  13. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    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.
     
    Last edited: 8 November 2020
    • Like Like x 1
  14. Mo Jo

    Mo Jo New Member

    Messages:
    9
    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!
     
  15. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    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.
     
    • Like Like x 1
  16. Mo Jo

    Mo Jo New Member

    Messages:
    9
    Ok great sounds good I will go with the Rpi4 and this Splitter. I am really looking forward to making this build and your software work! :) Thanks for all the help, I really appreciate it!
     
  17. Jake Ladley

    Jake Ladley New Member

    Messages:
    5
    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?
     
  18. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    Do you use multiple instances? If so try only one for now to verify it. If not report a problem on github. New version is incoming.
     
  19. snikcers

    snikcers Member

    Messages:
    81
    Hardware:
    RPi1/Zero, RPi2, RPi3, 32/64bit, +PhilipsHue
    Is LED Device activated? upload_2020-11-15_22-2-43.png

    Or did you override the LIVE session of WLED? Then you need to reboot your ESP once. In order to get the updraw again...
     
  20. Awawa

    Awawa Active Member

    Messages:
    228
    Hardware:
    RPi1/Zero, RPi3, +nodeMCU/ESP8266
    @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.

    [​IMG]
    On Linux it from some reason appends .localhost => it's wrong and it can't find it
    [​IMG]
    After set IP to WLED address it works
    [​IMG]
     
    Last edited: 15 November 2020