Smoothing, fps, and the narrow throat of my configuration

[Konnor378]

Hi. My configuration consists of a remote server with hyperhdr and a wemos d1 mini device on wled firmware. The connection to wled is via flat_buffers protocol. I don't know what fps I should use in antialiasing and in wled so that there are no sudden color changes, because I sometimes notice that colors change drastically. Most of the time everything is smooth, but sometimes the colors change abruptly and kind of intermittently, which distracts from the view. My TV has 177 diodes and a 5A 20A power supply. The router is connected to the hyperhdr server by wire, and the distance from the router to my TV is about 5 meters. You'd think the wifi would just be underpowered, but the router is set up on a dedicated channel that no one uses but me and the signal is pretty good, so I think the bottleneck is the fps of my controller. I didn't find anything clear in my internet search

[awawa-dev]

Hi

The connection to wled is via flat_buffers protocol.

I dont understand that part: wled supports flatbuffers?

Most of the time everything is smooth, but sometimes the colors change abruptly and kind of intermittently, which distracts from the view.

Wifi drivers were never optimal choice for HyperHDR: https://github.com/awawa-dev/HyperHDR/wiki/Quick-start#performance-pro-tips

[awawa-dev]

Your Wi-Fi is probably overloaded: each frame buffer frame is about width * height * 3 bytes and is then encapsulated into TCP packets, so the sender will have to re-send them if any of the packets are lost. But this is just a diagnosis without any detailed information about the transmission or reception of packets. For synchronization between Windows and another computer I recommend using HyperHDR with a DX11 grabber and a UDP server, which allows you to get rid of the flatbuffer and only the colors for the LEDs are sent, not the entire video images: https://github.com/awawa-dev/HyperHDR/wiki/Quick-start#synchronization-between-different-hyperhdr-devices

[Konnor378]

I actually thought my WiFi might be congested so I changed the WiFi channel to one that none of my neighbors use so there would be no interference, plus all my devices are connected via 5GHz except for this wireless controller which is connected to the standard 2.4GHz WiFi.

Okay, I see that hyperhdr is not suitable for my ambilight setup, plus hyperion allows you to change the protocol for wled to ddp or raw, and the raw protocol seems to speed up the colors. I will try using the default hyperion.ng again but I am having a hard time giving up hyperhdr. In that case, is it possible to customize the color display in hyperion the same way hyperhdr does by default or is the change too big and I need to edit the config to do it? It's just that the LEDs in hyperion were too dim, harsh and dark enough for me. I really liked the color settings in hyperhdr.

[awawa-dev]

Sorry to hear that. Technically (images via flatbuffer, communication with wled via UDP protocol) it is no different from hyperion. My comments regarding wifi communication and that it is not recommended are based on practical ambilight results and user reports. WLED is great but we do not send LED effects once in a while, the communication is continuous and is subject to interference. If you add flatbuffers to this, it is a recipe for full wifi saturation. The fact that it is 5th or 6th generation wifi has little significance in terms of interference. Many webos users have learned this by hosting a flatbuffer source on TV and HyperHDR on RPI and additionally WLED, which is why they usually choose a different solution nowadays: native hosting + HyperSerialPico.

[Konnor378]

I'm also sorry to hear that wled is very bad in terms of ambilight. I hope that with the development of the wled project at least the data rate will increase a bit. In that case I will limit fps to 30 and slightly increase latency to avoid color mismatch with the picture. The picture will not be as smooth as expected, but the colors will be more accurate. Thanks for the information, in my next similar project I will take into account such nuances and make everything through rpi + external capture card.