Severe stuttering on RPi3B (platform capture) with 2.0.14 - despite low CPU usage and no errors

[fragande]

• I confirm that this is an issue rather than a question.

Bug report

As topic states. With 2.0.14 I get severe playback stuttering with all source material. Some times there are also very short white flashes of all LEDs during the stuttering. I'm using platform capture on a RPi3B running LibreELEC 9.2.8. CPU usage is only about 20-25% when this occurs. Debug log for Hyperion shows no errors and the only thing in the Kodi debug log is dropped frames.

I've tried lowering capture frequency to 5 and picture decimation to 10 with no change. These settings do not seem to affect the severity of the stuttering much, if at all. Stopping the Hyperion service results in smooth playback again.

I feel like this is some hardware not keeping up, but unsure what to try next. Going to try a new fresh install of LibreELEC.

The LEDs are WS2812B's connected to an Arduino Nano running Adalight sketch.

Steps to reproduce

Play any video using platform capture on a RPi3B with Hyperion enabled.

What is expected?

Smooth playback.

What is actually happening?

Very severe stuttering and dropped frames.

System

Hyperion Server:

• Build: (HEAD detached at 2.0.14) (LordGrey-c9a1c88/b109703-1669566414)
• Build time: Nov 27 2022 18:16:02
• Git Remote: https://github.com/hyperion-project/hyperion.ng
• Version: 2.0.14
• UI Lang: auto (BrowserLang: sv-SE)
• UI Access: expert
• Avail Screen Cap.: dispmanx,framebuffer,qt
• Avail Video Cap.: v4l2
• Avail Services: boblight,cec,effectengine,forwarder,flatbuffer,protobuffer,mDNS,SSDP,borderdetection
• Config path: /storage/hyperion
• Database: read/write

Hyperion Server OS:

• Distribution: LibreELEC (community): devel-20211211200017-2282c38
• Architecture: arm
• CPU Model: ARMv7 Processor rev 4 (v7l)
• CPU Type: Raspberry Pi 3 Model B Rev 1.2
• CPU Revision: 2a02082
• CPU Hardware: BCM2835
• Kernel: linux (4.19.127 (WS: 32))
• Root/Admin: true
• Qt Version: 5.7.1
• Python Version: 3.5.3
• Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

[Lord-Grey]

Did it work well before 2.0.14 and which version was it? Did you change anything else?

[fragande]

I was running your beta.2 2.0.14 from this thread. I had some issues with rogue white flashes, which is why I updated (+ stable branch), but didn't notice any stuttering of this kind.

Reverting to that version there are some dropped frames here and there in the Kodi log, but nothing of this magnitude. I have not changed anything else, no.

Disabling almost all non-essential addons improved the situation somewhat, so maybe it's some hardware bottleneck despite resource usage being low? It's seems like the severity increases with source material quality.

[fragande]

Have system requirements increased with 2.0.14? A fresh OS install improved things a little more, as did a higher SoC overclock and forced turbo. Still not sure what the bottleneck is though as CPU usage is still around 20%.

Is platform capture done in software (CPU) or is it hardware accelerated? Would adding a HDMI USB grabber improve the situation?

[Lord-Grey]

In general, there was not changed anything significantly for the related DispmanX grabber or other processing steps in 2.0.14.
The processing (downscaling, cropping) is very much done in software, as DispmanX just provides the screen via shared memory.

Nevertheless, as Kodi reports dropped frames, it might explain the stuttering effect.
if there are screens skipped during processing, you will not see a continuous sequence of updates and might experience "stuttering".
Might be good understanding the reason for dropped frames first.

[fragande]

This seems to be resolved by manually setting the final capture resolution (i.e. after decimation) by exporting, editing and importing JSON for some reason (found a hint about it in this thread).

Quoting my post from that thread:

Tried the trick of editing the exported JSON with very good results, but leaving me a bit confused.

Using 1920x1080 with 8 picture decimation gave me about 40 dropped frames in a 30s 50Mbps test clip, while using an edited JSON with 240x135 and no decimation (1) resulted in 0 dropped frames and butter smooth playback. The latter also seemed to incur less system load, even if both are low.

Shouldn't these two result in the same capture resolution?

If I'm not misunderstanding how this setting works, 1920/8 x 1080/8 should be same same as 230x135, no? If so, something seems to be up with the decimation.

EDIT:

Sorry, I misunderstood the playback stats. It's not actually dropped frames; it's missed vblank updates, if that makes a difference.