noggin IIRC the videocore code uses some hardware acceleration so I think you were about right. I'm not really familiar with all the gory details of the closed-source firmware blob and RPi folks will probably correct me if I got some details wrong 
so long,
Hias
The "RPi4" in the filename should give you a hint why it doesn't work on an RPi3
Either use the LE9.2 RPi2 build or the latest RPi2 nightly build (beware: this is experimental LE11 stuff) from https://test.libreelec.tv/ (RPi2 builds will work on RPi3, too).
so long,
Hias
"MMAL advanced" is borderline/too much for 1080i, therefore it's done using bob which needs fewer resources (memory bandwidth especially).
I'm not 100% sure about RPi0-3 but ISTR they had similar issues - except for test streams I don't have any 1080i content here.
RPis don't have a hardware deinterlace block therefore this is being done by software running on the videocore CPU - and that code is the same on all RPis.
so long,
Hias
camelreef thanks a lot for testing and the samples!
I've noticed the glitches on MPEG2 SD material, too, and popcornmix already has an idea what could be causing that - it might be related to software decoding, H264 hardware decoded videos don't seem to have those glitches (at least we haven't noticed them there yet).
So no need for a debug log ATM
IIRC SD content will use the "advanced" deinterlacer, HD will use bob, of the videocore chip - pretty much the same as on RPi2/3 with LE9.2
so long,
Hias
I'm not sure if there's an easy way to do that. Best check through PINN's readme https://github.com/procount/pinn/blob/master/README_PINN.md and the PINN support thread on the RPi forum https://forums.raspberrypi.com/viewtopic.php?t=142574 - if you have questions better post there, I never used PINN myself yet (and IIRC none of the other LE developers did either).
so long,
Hias
Which build did you download? We don't provide official LE10 builds for RPi0-3, only RPi4.
so long,
Hias
FYI: the latest development version of the deinterlace patches are now in LE master, today's RPi4 testbuild (http://test.libreelec.tv/LibreELEC-RPi4…126-8797e08.tar) already includes them. RPi2 testbuild with these patches will follow tomorrow.
so long,
Hias
It sounds like you are searching for PINN or NOOBS https://github.com/procount/pinn
You'll find more info about these on the RPi forums https://forums.raspberrypi.com/
so long,
Hias
run rpi-eeprom-config -e and set these options
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1so long,
Hias
I just noticed 2 more things in the log:
The file is a 50fps video, you may need force_turbo=1 in config.txt for smooth playback.
And you don't seem to have 1920x1080 / 50 Hz in your whitelist so 3840x2160 / 30Hz is chosen - which usually doesn't work well with 50fps files. Add that mode to the whitelist - and better also set kodi gui to 1920x1080/60Hz
so long,
Hias
The logs show you were playing from NFS. Can you test if you have the same issue when playing from a local USB drive?
If yes then a short sample file (1 minute or so) that has the issue would be nice.
20211120-62b201b also includes ffmpeg changes https://github.com/LibreELEC/LibreELEC.tv/pull/5889 and I'm suspecting they could be causing the issue. If that's the case our ffmpeg guru will need a sample to reproduce and analyze the issue.
so long,
Hias
I see similar behaviour (LibreELEC-RPi4.arm-11.0-nightly-20211117-df8716a.tar):
video freezes for a few seconds while audio continues, then suddenly video catches up. When the video has finished playing the last frame is still displayed until I explicitly stop it.
Thanks for the log, I could reproduce the VIDIOC_DQEVENT errors and PR'ed a fix for it https://github.com/LibreELEC/LibreELEC.tv/pull/5888
so long,
Hias
The fix for the kms driver is still missing, so this is expected.
so long,
Hias
Thanks a lot for testing, it's great this is working now - this was a tough puzzle to solve
We'll include the necessary config changes in LE so future LE versions will support the official 7inch display.
so long,
Hias
BTW: also make sure you are using HDMI0 (the one next to the power connector on RPi4) - HDMI1 only supports up to 4kp30.
so long,
Hias
Please post the outputs of "modetest | pastebinit" and "pastekodi"- this will show what modes are available (and a copy of the edid).
Most sinks won't list 4kp50/60 modes at 4:4:4 in the EDID unless you enable "HDMI Deep Color" at the sink - then 4k 4:4:4 is limited to 30fps and only 4:2:0 (which the RPi doesn't support) 50/60fps are listed.
YCbCr 4:4:4 isn't supported in the driver either, the proposed kernel patch would add that along 4:2:2 as well.
IIRC all matrices and BT709/2020 colorspace signalling should be fine now.
so long,
Hias
New day, new try - I noticed I missed one option: https://www.horus.com/~hias/tmp/libr…442-9bbb99c.tar
Please report back if it works. If it doesn't please post your config.txt (Note that IIRC you need to have ignore_lcd=1 in it, and the 7inch dtoverlay after the "include distroconfig.txt").
so long,
Hias
Thanks for testing!
The main problem with the DSI drivers is that the kernel ends up in an endless probe loop if something is wrong (eg a driver missing or not initializing) without telling you what failed - several drivers just silently pass on errors without logging anything so there's no chance of finding out which of the sub-sub-sub components are missing or failing to initialize.
I get the same lockup (endless probe/bind loop) here with the 7inch dtoverlay loaded. I don't have the display, so I'd expect things to fail, but not as badly as they do (unable to complete kernel boot) and tons of meaningless errors on the serial console.
At the moment I'm at a complete loss, I think I have all the required dependencies enabled and no idea what else might be missing.
so long,
Hias
