Posts by 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

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).

Maybe it's a hardware related. For Ezcap 269 mjpeg artifacts were very noticeable for me and caused strange effects on some scenes. High resolutions helped but not for 100%.

My bad, I misread your log. Lower resolution has very bad effect for the MJPEG at least that's my experience with Ezcap. That's doesn't apply for YUYV encoding.

I hope it will help. Maybe there is other program on linux to record camera/grabber and test FPS for that situation and exclude/confirm that's a hardware or linux case?
BTW I dont know what's your display but for capturing 640x480 is not optimal for TV and ambilight. 1280x720 has much better aspect both for 1080p and 4k TV.

Thanks, thats better

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.

I mean that I dont see what was after that (next video stats for frames to compare statement from PriorityMuxer that cut off leds vs provided frames)

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...

Quote from jeroen warmerdam

max_usb_current=1

That settings doesn't change anything for Rpi 3

@Zaborejszyn
If it's macrosilicone clone then that grabber supports both yuv&mjpeg. Which format is used by Hyperion (->logs in debug mode)?
Also check CPU usage to eliminate that botttleneck (top).

Base Raspbian Linux system is common for all Rpi. The only difference in the images are preinstalled HyperHDR version.
You can also try to remove that packages of HyperHDR manually and install HyperHDR for Rpi1: https://github.com/awawa-dev/H…1.2.0.8A-Linux-armv6l.deb
...or write again whole image if you'd like: https://github.com/awawa-dev/H…card-image-rpi1-armv6.zip

Frankly I didn't test it with Rpi 2 myself...only 1 and 3,4 in separate packages. Maybe one compiler optimization too far for that plaform.
Try to write SD image for Rpi 1 as it should be safe option. Next if you interested I can tweak build to make it works for Rpi2.

@SiLAnceR Propably nothing if the ip is correct and not blocked
SSH to the Rpi and check with 'ps' if the process hyperiond is running.
If not try to run it in debug mode: /usr/bin/hyperiond -d

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:

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?

Quote from NeeeeB

Many thanks for this New version.
Any chance you thought to make the signal detection time configurable ?

Sorry, but coding remote control for HDR tone mapping took much more of my resources than I planned it I remember about it.

I doubt very much it's a brightness case...check and calibrate the leds. It could take some time to make it look similar to the screen capture from the grabber. If on the screenshot there is no greenish then it shouldn't be on the LED either.

@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.

I think that some of these problems come from the exclusive access to device in Microsoft Media Foundation. So only one instance can use the device. Missing error handling for that situation is another story

I worked with settings imported from much older hyperion release and it was OK...at least before I discovered Hyperion feature to move LED from borders and it ruined them then
I changed some defaults but it isn't crucial thing. Alpha8 settings should work without any problems.

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.