Posts by Awawa

Oh, guys..come on. Make some things straight. You almost had HDR LUT correction in hyperion ng: https://github.com/hyperion-project/hyperion.ng/pull/928

Overall beside waiting for almost infinity time from my position in the queue, there was no room for implement it at that stage because of lack of the permanence on different fronts for example MJPEG on Rpi: https://github.com/hyperion-project/hyperion.ng/issues/962

And I wanted to have it working at least for myself soon...maybe too much rush.

Regarding a "copy": I'm stick to the MIT license, hope it works both way. Windows port supporting USB grabber was first introduced in HyperHDR almost half year ago..a copy? The WWW interface of Hyperion NG is great, I can admit it. Usual user cant see it but beneath it's flexible and offers very powerful options including WWW wizards. I like the automation builds and I use them as a start point to improve them even further.

But some things beneath, including the video processing must be break from the past at least in my view so I created a fork for that doesn't mess with Hyperion NG itself because as I see backward compatibility is a value there so let it be. For me: screen captures are killed by the DRM or hardware video acceleration so removed them, better performance is a must and some other things al least in my view like flexible LUT correction including HDR, stable high performance LED driver as separate projects for high quality movie content because even WLED on Wifi is not always a solution. The user is always winning because he can choose solution depended on his needs and setup.
Best regards and hope you have a great weekend

Soon my friend as it needs more testing along side with a lot more new features and improvements I wouldnt recommend to control WS2812b/SK6812 with Rpi but it is your choice and it works in most cases.

BTW it seems that the Windows Media Foundation grabber worked and is working contrary to some unproven claims

@Puck I'm not providing support anymore here so Github or PM please. CEC is not needed for USB grabbers and all system captures are removed because it's a dead end in DRM era. Like analog stuff, for example UTV007. I'm focus on high capable grabbers. Most of important things are already merged as written in the release info. A lot of work in progress (things from feedback), mainly for Win10 and new shining features for SK6812 RGBW.

don't want to abuse of hospitality here

@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

And to end that story for now: here's the hardware debug log from WLED nodemcu v2 amica:
100hz / 250 leds / wireless / Windows 10 hosting

As you can see it's much better, the only problem is the Wifi connection itself as can be expected.

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.

@snikcers I like that solution, probably some kind of the old trick
https://www.electrobob.com/ws2812-level-translator/
The only downside is that we have to remember to address that one or two "dead" led?

Let's puts some tech stuff on WS2812b / SK6812 with connection with current Arduino sketch that is distributed along side Hyperion
Using smoothing with continues output and down side limit removed.
Saleae logic analyzer, just to see frames not to analyze their content.
250 leds.

Lets try with 15Hz:

let's say it's OK, around 13Hz, but it's below default limit for smoothing for 2.0.0.8 and previous version.

now 25Hz:

not good, probably we hit the wall around 21Hz, still below minimum limit.

now 50Hz:

obviously we captured some out of sync moment, a little below 20Hz

now 100Hz

around 21Hz we met before.

1)
Probably increasing serial port speed would bring little benefits as these popular AT processors are just too slow to handle both high speed serial port and LED library. WLED seems to be a better solution despite problems with Wifi stability and possible little lag due to wireless communication.
But the best solution I will probably choose is using ESP8266 as high speed controller: USB serial port could go as high as 2Mb and the CPU is 10x faster than Arduino based on popular Atmel.

2)
Using smoothing in that case is just delaying the output, no interpolation...

Future versions and other participant will take care of that refactoring stuff for sure v4l2 driver was cleaned already by myself from dead code that was never used in Hyperion.

No, no ...that was for purpose, they have so many similarities and there's no need to rewrite all the WWW grabber configuration panel Maybe QTC is a bit misleading as I intended to use QT Camera class but then I found Media foundation

Quote from Paulchen-Panther

You should also update your Windows version:

Oh, that's the it support not the developer talk anymore
You're perfectly right but unfortunately it didn't help for my old backup laptop... it's still working, sir:

And seriously because I cant duplicate the problem in my environment I cant help in your case. You can locate that problematic line: it's simply call to MFCreateDeviceSource function without any magic. Maybe it's related to device drivers and insufficient memory to initialize as the error suggest. Maybe on the Windows forum you will receive some help. And as I said would welcome feedback if you got some clue.

Quote from Paulchen-Panther

:LOL:

You perfectly know the developer talk You use it yourself, it's not complaint.
I'm the only one to develop and test that module so I cant guarantee it will work for everyone, for every configuration and hardware at this stage.
And to continue developer talk: it's working for me

PS: installed from official release
PS2: would welcome PR if you could find the problem on your system.

Wow You came too far: that's version is build by github automation so everyone has the same release based on the same sources Probably the problem is your system: you can locate that line in sources and analise it yourself.
Earier I spoke about new version along much more features amongs them is usb-hid support for Windows. Will be available for everyone after test and after github reset my limit.

OK, but didnt upload anything new because I'm run out of free storage credits on Github Ezcap 269 and old analog UTV007 works for me, the same laptop camera, one Logitech camera had some problems with encoding but didn't throw that error. Wonder why the library was load after the MFC throw error.

OK, you used custom sketch. Default speed for all kind hardware Adalight adapters is 115200. And even with that sometimes there are troubles with Rpi UART configuration. Well, all is ahead of me

And my current config for 55" is 98 leds :unsure:

I think it's possible and will start to implement it immediately for WS2801 as SK6812 will arrive next month.

One disturbing thing: even with highspeed serial port at 2 000 000 baud for 200 leds he've got only 100hz practically...
And solutions with ambilight using 115 200 baud default USB serial port for Arduino? Maybe people can't notice it or they have less leds in the projects...

There is a latency for Wifi communication. It's insufficient for many projects and that's not what I fought for every millisecond with HyperHDR to comply with that But the device I mentioned Olimex ESP32 can communicate also over ethernet and run WLED (in alpha/beta... whatever stage). Tensy >= 3.2 has highspeed serial port.

OK, is this would work with USB->Serial communication and Adalight protocol on ESP8266 https://github.com/sticilface/Adalight-ESP8266? 2000000 baud should be enough. Only change for RGBW and rework a little for sk6812.

Quote from pclin

I'm waiting for the HD108 RGBW with my 268 LED SK6812 RGBW, I'm very satisfied.

Regards pclin

How do you communicate with sk6812? I seriously consider them but 3-wire leds are problematic using directly from Rpi. The problem is not only LED count but also refresh rate. Old solution for analog era could be not enough. Even on the lowest FPS for grabber and 60leds/meter I could be forced to abandon smoothing. I was thinking to forward data from Rpi to Arduino(USB) or ESP8266 but the serial port is bottleneck for the first and latency could be a problem for second. Or to experiment with Olimex ESP32 or Tensy?

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.