Posts by Awawa

I guess what cause it under certain circumstance. Will try to fix it in the next release along a lot of other stuff.

ERROR_INSUFFICIENT_BUFFER first time I meet this. This is first step of device initialization before all the configuration stuff.

Frame's size mismatch for YUV (where framesize is constant) indicates problem with v4l2 driver caused mostly by hardware (grabber, usb bus, voltage jumps et). It can happens on the start of video process capturing during initialization but not after. Upgrading to Hyperion.NG may or not help. Check dmesg.

Yes, there are also other optimization in later version...skipping unnecessary video buffer resizing, removing coping pixel by pixel, implementing LUT YUV->RGB decoding etc. You're referring to this more recent results (HDR tone mapping is disabled for comparing because Hyperion.NG doesn't have it, it need benchmark
I dont update it for Rpi Zero, maybe some other user with Rpi0/1 can copy-paste log with benchmarks or you can test the fork yourself and check logs.

For me the main problem with Hyperion.NG on every Rpi is that it can run only on single thread, when the CPU reach 100% (of 400% available for RPi 2/3/4, more in FAQ on git) then every module of Hyperion choke for resources: grabber, image to led, web panel et. So it's not only grabber performance take damage...to be fair the same situation could meet HyperHDR if you run it on single core CPU like Rpi1 without limiting FPS (grabber: skipping frames option). On multi core CPU it will take advantage of the platform. So the answer for your question: yes, it definitely worth to spend that additional 25e

Maybe if the grabber supports YUV encoding then there is a possibility that Rpi 0/1 could be enough.

If you set player to output bt2020 there is no need for user interaction either The same effect can be achieved the HA .

Config is and was only one. There is a switch (on web remote panel and in the grabber properties and in hyperion-remote) to choose hdr/sdr at once. Or to automatize process with home-assistant and for example Denon amplifier to detect content. Or to make player to output always HDR/BT2020 stream (SDR is upconverted and that is a very nice option if the TV support HDR) as I do.

Quote from Mo Jo

Thanks! I will go your route but I will use this grabber and a Raspberry Pi Zero W. That should work without any major latency increases, right?

It's a single core CPU so don't expect fireworks but MJPEG and YUYV decoding is still faster than in the mainstream. It's a very old benchmark before few signification optimization from next versions but you can see what to expect on single core for MJPEG that is most problematic for decoding: SDR & HDR 1080p/4k capable setup with Hyperion-NG for Media Center

Did you replace /libsrc/hyperion/schema/schema-smoothing.json in the latest Hyperion.NG sources with that code and recompiled them?

I also use smoothing that's why it was disturbing for me because that commit broke it down It's not only inability to save settings in editor, some strange things in the signal processing starts to happen beneath and it shows up in the logs. I hope that linear mode works as before but there was a lot of changes.

PC media player in my setup really doesn't matter. It works for any player that outputs HDR or BT2020 or even old SDR (for faster multithreading processing without tone mapping) content that is captured by the grabber and processed on Rpi (or also on Windows in the latest build).

Quote from Mo Jo

Wait that looks awesome! I would really like to take a look at your full build but sadly I am not allowed to view your profile and therefore your threads. Can you link it here if you posted your setup somewhere else before?

Fixed now. And check "Hyperion Setup Showcase" subforum

New mode for smoothing was added in one of the latest commits. I've got some mixed feelings about it but it's always an option that somebody may need.

Yeah, I also found&corrected it too but dont have time to make pull request. The bug is caused because new scheme for smoothing doesn't care about old config and after start some things starts to break down (for example you cant save settings for smoothing in the web panel).
"required" property is missing for the new fields. Work around is to delete old config.
BTW what is the difference between "updateFrequency" and new "outputRate" for old linear smoothing?

Working one example /libsrc/hyperion/schema/schema-smoothing.json :

{
    "type" : "object",
    "title" : "edt_conf_smooth_heading_title",
    "properties" :
    {
        "enable" :
        {
            "type" : "boolean",
            "title" : "edt_conf_general_enable_title",
            "default" : true,
            "propertyOrder" : 1
        },
        "type" :
        {
            "type" : "string",
            "title" : "edt_conf_smooth_type_title",
            "enum" : ["linear", "decay"],
            "default" : "linear",
            "options" : {
                "enum_titles" : ["edt_conf_enum_linear", "edt_conf_enum_decay"]
            },
            "required" : true,
            "propertyOrder" : 2
        },
        "time_ms" :
        {
            "type" : "integer",
            "title" : "edt_conf_smooth_time_ms_title",
            "minimum" : 25,
            "maximum": 5000,
            "default" : 150,
            "append" : "edt_append_ms",
            "propertyOrder" : 3
        },
        "updateFrequency" :
        {
            "type" : "number",
            "title" : "edt_conf_smooth_updateFrequency_title",
            "minimum" : 1.0,
            "maximum" : 2000.0,
            "default" : 120,
            "append" : "edt_append_hz",
            "propertyOrder" : 4
        },
        "interpolationRate" :
        {
            "type" : "number",
            "title" : "edt_conf_smooth_interpolationRate_title",
            "minimum" : 1.0,
            "maximum": 1000.0,
            "default" : 120,
            "append" : "edt_append_hz",
            "required" : true,
            "propertyOrder" : 5
        },
        "outputRate" :
        {
            "type" : "number",
            "title" : "edt_conf_smooth_outputRate_title",
            "minimum" : 1.0,
            "maximum": 1000.0,
            "default" : 120,
            "append" : "edt_append_hz",
            "required" : true,
            "propertyOrder" : 6
        },
        "decay" :
        {
            "type" : "number",
            "title" : "edt_conf_smooth_decay_title",
            "default" : 1.0,
            "minimum" : 1.0,
            "maximum": 20.0,
            "required" : true,
            "propertyOrder" : 7
        },
        "dithering" :
        {
            "type" : "boolean",
            "title" : "edt_conf_smooth_dithering_title",
            "default" : true,
            "required" : true,
            "propertyOrder" : 8
        },
        "updateDelay" :
        {
            "type" : "integer",
            "title" : "edt_conf_smooth_updateDelay_title",
            "minimum" : 0,
            "maximum": 2048,
            "default" : 0,
            "append" : "edt_append_ms",
            "propertyOrder" : 9
        },
        "continuousOutput" :
        {
            "type" : "boolean",
            "title" : "edt_conf_smooth_continuousOutput_title",
            "default" : true,
            "propertyOrder" : 10
        }
    },
    "additionalProperties" : false
}

@Jake Ladley I dont want to hijack the thread so short answers for your question: Windows build is only an option included lately, for me and some users as an alternative. The fork was started and optimized for Rpi and using multithreading to enable tone mapping processing. I'm using ezcap 269 but had some feedback that it work for many modern HDMI grabbers for example MacroSilicon MS2109 clones.

And back to the subject: dont give up on the grabber before you can exclude software or some settings. Even cheap MS2109 has a lag only about ~100ms.

Received feedback from the manufacturer from China. HD108 can be ordered but the price is ~50$ per meter :eek:

@Davy For lag testing on HDR content here you have one:

and grabber is set to much higher resolution then in samples from this post without any decimation. And yes, resolution does matter for the quality.

@pclin I saw some users on other forum waiting for them from January, no one can order them

And for the bandwidth:
For 55" Oled TV I need ~4m of LEDs.
Communication frame size: ~ LEDs * 4 bytes

For 30 led/meter:
4 * 30 * 4 * 8 +headers => ~3900 bits
30FPS * 3 smoothing = 90 => 351kHz at ideal condition

For 30 leds/meter 180 FPS => 700kHz

For 48 leds/meter 90FPS: 6200 * 90 => 560kHz
For 48 leds/meter 180FPS => 1.1MHz

For 60 leds/meter 90FPS: 7680 * 90 => 700kHz
For 60 leds/meter 180FPS => 1.4MHZ

But we are not living in the perfect environment. Some video frames could arrive late, there is overhead on internal communication and we need higher bandwidth than that minimum. I think that it's safe to assume 1.5 * that minimum. Almost all of one channels LEDs are unsuitable for most scenarios for me.

I think that I'll order that HD107..or maybe someone has a link to genuine, not counterfeit, not cloned Taiwanese APA102 as an alternative?

Why sk6812? One channel instead of two and very low bandwidth. I my case bandwidth is very important for high FPS grabber and smoothing at least 3xFPS. And account LED per meter. Must to calculate the frames size but I propably need more MHz than 800KHZ.

Yeah, for sure it seems to be better option than other LEDS. Of course HD108 would be better for Rpi. I'm afraid about their reliability. My WS2801 works without any issues for years and I've read many reports about problems with other type of leds, mainly APA102 clones. I've just found direct seller from the manufacturer of HD107S and they have cheap 48led per meter, that's what I was looking for.

"HD107S 2020-RGB /HD107S 3535-RGB /HD107S 5050-RGB on the market already.
The HD107S 5050-RGBW and HD107S led with 16 bits will on market In October2019"

something gone wrong....

Compatible with APA102 protocol, speed of 40MHz and PWM = 26kHz looks really impressive. At least on the paper...
There's also other model HD108 but unfortunately not accessible for sale on Ali.
Rpi 3.3V fits HD108 logic levels and it's 16bits per color.

If anyone has trustworthy seller to recommend I could buy it on 11.11 and test it myself (my 2801 needs refresh after three years). This time I'll build a frame because my TV is a little too far from wall and colors of adjacent leds are mixed up.