Beiträge von Awawa

    Check with lsusb if it's macrosilicone for sure.
    I'm not a fan of these grabbers but they have relatively low lag about 100ms

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    I dont have that type of grabber..maybe mjpeg could improve latency, but yuyv is preferred for quality and low CPU usage.

    Did anyone test this new type of leds with Hyperion? On paper there are perfect and because it's a new model there is a chance that Chinese didn't manage to make counterfeit clones of them (like APA102 where almost every APA102 sold on AliExpresses is in fact worse SK9822).

    Thanks, thats better :)



    Code
    2020-11-04T18:47:14.062Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:1027:process_image()) Video FPS: 60.02, av. delay: 7ms, good: 3599, bad: 2 (60.00,15)
    2020-11-04T18:47:18.056Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:238:setInputImage()) Priority 200 is now inactive
    2020-11-04T18:47:19.122Z [hyperiond HYPERION] (DEBUG) (PriorityMuxer.cpp:238:setInputImage()) Priority 200 is now active
    2020-11-04T18:48:14.063Z [hyperiond V4L2:/DEV/VIDEO0] (DEBUG) (V4L2Grabber.cpp:1027:process_image()) Video FPS: 57.93, av. delay: 7ms, good: 3476, bad: 0 (60.00,15)


    OK, there was drop for about 120 frames, if they were arrange in sequence it's about 2 seconds.
    If there is no errors in dmesg (voltage dropping, usb device connecting/disconnecting) then it's only guessing because Hyperion didnt receive any errors from v4l2 driver or even corrupted MJPEG frames.
    Maybe it's something with Rpi USB or video buffer in the kernel.
    Try to reduce the framerate to see if something would change.

    You are not the only person affected by these symptom. Hyperion.ng is also affected. I disabled CEC and all system grabbers in latest build anyway.
    1) eliminate hardware problem checking for errors in dmesg (not the boot stuff but after hyperhdr is started)
    2) it's seems that it lost signal for about 1 second, it's too bad that you cut off that log...

    Code
    2020-09-19T21:21:01.370Z... Register new input 'System/GRABBER' with priority 250 as inactive
    2020-09-19T21:21:01.387Z ....Register new input 'System/V4L' with priority 253 as inactive
    2020-09-19T21:21:01.500Z ... Priority 250 is now active


    250 < 253

    @NeeeeB as I can see now the setSignalThreshold for signal detection is hardcoded in Hyperion.NG as 50...frames not seconds or miliseconds.
    So with Hyperion.NG and 7-8FPS (800x600 MJPEG) the limit is reached after ~5-6seconds and with HyperHDR with 30FPS after <2seconds or with 60FPS below 1second.
    Obviously it wont work with the movies when set like that but I moved it to the configuration... it was almost finished in Hyperion.NG but this option was hardcoded for some reason. Already committed to github, download installers in a few hour as they are being built.



    Windows grabbers settings for Ezcap mistery explained:


    Code
    2020-10-30T21:34:38.770Z [hyperiond V4L2:QTC:EZCAP U3 CAPTURE] (DEBUG) (QTCGrabber.cpp:883:QTCGrabber::init_device()) Brightness: min=0, max=255, default=128
    2020-10-30T21:34:38.773Z [hyperiond V4L2:QTC:EZCAP U3 CAPTURE] (DEBUG) (QTCGrabber.cpp:907:QTCGrabber::init_device()) Contrast: min=0, max=255, default=32


    Contrast is set to 32 as default.
    This is different from Linux where contrast default is set to 128 and it looks better.
    Which was intended by the manufacturer?

    @Puck Glad it works as intended :)


    OK, version 11.2.0.9 is building right now. SD images could be delayed as I have some problems with Raspbian mirrors in our country.


    Summarizing


    1) Support for USB grabbers Windows 10.
    Really like it and I wanted it from the start but I was not familiar enough with the Hyperion.NG project to even think about it...but time's has changed and here it goes. Seems it work very stable and fast at least for the video grabbing.


    It could be useful if we want to reduce setup by remove Raspberry Pi (or we don't have any) as host for grabber and put instance of HyperHDR on Windows PC as forwarded.
    It should also works for the grabbers that aren't supported under Linux.


    2) Remote control for HDR tone mapping
    I was hoping it could be easier to code it...well, it seems it also works ;)


    3) HARDWARE brightness & contrast control
    For the grabbers that support them of course. I dint plan it, but it's longer story....
    There is some strange about behaving of Ezcap under the Linux and Windows.


    Compare these screens, the only difference is frames per seconds:
    30FPS:
    HDR tone mappping on:
    HDR tone mappping off:


    60FPS:
    HDR tone mappping on:
    HDR tone mappping off:


    There is difference in the brightness...unfortunately LUT table is calibrated for the brighter 30FPS.


    Under Windows 10 is even worse:

    Image is even darker.


    So here it goes the control of brightness & contrast to set them and make the look stable :)
    Here the brightness is set to 136 (128 is default for ezcap, contrast is unchanged)


    60FPS:


    HDR tone mappping on:
    HDR tone mappping off:


    If you got any question private message is the fastest way to communicate.

    Debugging on Windows is a harder thing than doing it on Linux. At least for me now. There is no permanent log beside temporary one in webui. And heavy crashes arent log anyway as I tried to redirect them to file. There is a chance that they will apear in "Windows Event Viewer". So far python39.dll is giving me sometimes trouble and it could be related to effects plugin.