Posts by Awawa

    Sounds acceptable for personal usage, hopefully a more permanent solution will come to HyperionNG soon, meanwhile I can adopt your solution and recompile from src. But first more importantly I need to solve my other issue, do you have any ideas about that?


    Didn't meet that behavior. MPC HC & MadVr changes resolution almost for every movie to fit resolution & FPS and it works. But most of my sources are 1080 HDR and sometimes some old 480 SDR TV series and there is only one PC connected to ezcap / LG C9.

    @rasp, So I assume you modified the cpp as above and recompiled to make it faster, but its not the final solution adopted into HyperionNG?


    Yes, I changed it in /libsrc/grabber/v4l2/V4L2Grabber.cpp only for myself because lower resolutions generated nasty images and higher resolutions caused unacceptable lag. Dont want to commit it to the project because of the issue of decimacion==1 and the live feed. Maybe it should be made in another way but it works stable and fast for me for my configuration.

    I do notice some delay between the colours on TV and the Ledstrip, but this issue might be solved on the master of HyperionNG? (I read a couple of pages back you noticed the same issue).


    Yes I can confirm that. The reason is that part of the code that copies byte by byte, color by color (I know that this is more complicated issue and code should be platform independent) in V4L2Grabber.cpp:



    But even 640x480 and decimation==1 is too much for Rpi3 and causes very big lag.
    This patch below works very fast for 1024x768 and decimation>=2. Decimation == 1 breaks the www live feed (capture works OK) for unknown to me reason, probably memory sharing:

    I'm not sure but I suppose that only Diva and HDfury x4 can handle it but in different ways/configs. This is the best solution as it can detect HDR/SDR source.
    With Ezcap I can force my player to output every movie as a bt2020/HDR so I dont need to switch color format. If you have multiple sources then you need to add HDR capable switch to ezcap (HDR source1/source2/...->switch->Ezcap->TV). Ezcap is a capture card so you dont need another one.

    I posted in this thread about Ezcap 269.
    You can compare how it treat HDR and check if it fits you.
    Original HDR10 in SDR via software conversion that was captured OK as a reference.


    Previous firmware and no tweaks -> bleak colors. This is the problem of 99.99% matrix/capture cards on the market (even Elgato S60+ can capture it as the closed proprietary format only):


    And almost correct image with the newest firmware upgrade for Ezcap 269 + some software tune

    Code
    /usr/bin/v4l2-ctl --set-ctrl contrast=220
    /usr/bin/v4l2-ctl --set-ctrl saturation=255
    /usr/bin/v4l2-ctl --set-ctrl brightness=100
    /usr/bin/v4l2-ctl --set-ctrl hue=2



    Another way to go is HDFury $$$.

    PassThrough works with ezcap 269, no problems with TV 4k60 & HDR or any other resolution/FPS (I had some problems before with VSP01201 and UTV007)
    For capture: HDR colors are degraded but can be somehow fixed on startup with:

    Code
    /usr/bin/v4l2-ctl --set-ctrl contrast=220
    /usr/bin/v4l2-ctl --set-ctrl saturation=255
    /usr/bin/v4l2-ctl --set-ctrl brightness=128
    /usr/bin/v4l2-ctl --set-ctrl hue=16


    I'm happy with it.
    BTW there is update for ezcap 269 that finally can be flashed but there is no changelog or whatever ...this is so chinese.

    I'm sure that if we will treat that output 1080 from 4k HDR with fix for HDR it will cure bleak color in some way but if the input source would be 1080p SDR then it will mess it up. Anyway or other there's no magic fix but to make ezcap to do correct color transformation from bt2020 to bt709 because that's the problem. If your source is always 4k HDR then of course you can hardcode it.

    You could check that topic: https://github.com/hyperion-project/hyperion.ng/issues/497
    Anyway that approach requires some interaction from user to switch on/off the color correction due to fact we don't know anything about the base stream. Well, if that ezcap could somehow forward an information about is hdr stream present...


    I'm pretty sure that pre-buy asking Y&H on Amazon it's perfectly fine: that grabber is advertised as a HDR capable but it's seems it's only half-true.

    My ezcap returned to the case with Rpi3 setup so I cant check it right now. I fight with hyperion_ng's grabber: there's some things to optimize in mjpg decoding even on the single thread but I lost some time due to fact that alfa3 doesn't work at all.
    But I think your solution should work to some extant. I saw similar approach somewhere where they tried to correct bt2020 to bt709 color conversion by the software transformation. There's only one problem: we don't have any information about the base stream before it was captured... was it 4k HDR or simply 1080p SDR or any other format. Without knowing that it's impossible to apply correct filter or don't apply it at all.


    You could try to contact Y&H: it's OEM but the same product and they have better support on the Amazon.

    .net core app would be nice :) I think that Rpi4 is 2xfaster Rpi3 single core at most and there are some unresolved problems with SPI. If grabber's performance will scale 1:1 then the lag will decrease from 1.5sec to 0.7sec at best. And it's for 30FPS only. It's still too high.

    To clarify ;) : full res 1080 capture works with usb2.0 (at least in 30fps, I'm not sure if it skips frames) but it's not real time processing that we need for ambilight on Rpi3. For recording or streaming I think it's fine. On the other hand we don't need fullhd for ambilight but working HDR would be nice. It's strange that even with 640x480 and size decimator 1 (I use at least 2) system generates some lag but CPU is stable at only 33%. This indicates that hyperion_ng's grabber is not capable of using multicores to process frames.

    OK, I found the problem in the hyperion_ng code.
    I know it's rather a developer problem (move post to other forum section if you like) but it breaks things on modern FullHD USB capture devices that are used with USB2.0 host: the delay between stream and capture is totally unacceptable. You are run off the USB bandwidth (or resources) with ezcap 269 and Rpi3.


    That's how current hyperion_ng finds resolution to work with:

    It chose the highest available resolution:1080/30fps and it's too much for usb2.0 and/or Rpi 3 .
    With the brutal hack I changed std:max to std:min (you must also change 0 as a start base min_width/height values) in v4l2grabber.cpp when grabber is searching resolution:

    I noticed that the framerate is hardcoded to 30fps but didn't change it. Now the grabber works flawless without any lag.


    I recommend to change that algorithm a little and move some settings to the configuration.

    1)
    I have tested it on Win10. As I suspected HDR capture doesn't work properly but is should be sufficient for ambiligth.


    2)
    I have excluded USB2.0 and the device as a suspect. I have connected ezcap 269 through USB2.0 hub to PC with Win10 and there was almost no delay after I have disabled caching in VLC.

    For me there is something wrong with hyperion-ng that causes that delay for ex. caching, too high framerate or resolution (PAL/NTSC et. are deprecated for new generation HDMI devices) that we can't change or set, low priority capture process or it can't use all four cores for certain tasks. CPU usage is not even at 50%.on Rpi3.