Well, thing is that there is A13 CVBS driver which might just work on A20, but I'm not sure anyone tested it on A20. U-Boot composite driver can in theory be used by Linux through simplefb mechanism (that framebuffer-lcd-tve0 node you noticed in DT) but it lacks features used by Kodi. Full blown DRM driver is needed for Kodi.
I suggest you try to copy and fix CVBS pipeline related nodes from one of A13 DTs and see if that works.
Cold boots doesn't work if you have ethernet plugged in (freezes before LibreELEC boot splash screen) and NIC leds are behaving weirdly, connecting ethernet once its booted up works fine and most of the time rebooting also works with ethernet still connected.
This is first time I hear for such problem. Unfortunately I don't have board in question so hopefully it will be solved in upstream at one point.
H264 10-bit/Hi10P seems broken using the PRIME render and fails falling back to software rendering. It will load and play the file (sound only) but Kodi menu will still be shown and player controls are shown. Disabling PRIME render solves this issue but also disables any kind of hardware acceleration as expected.
HW doesn't support 10-bit H264 decoding (confirmed by AW). Kodi doesn't do SW rendering. You probably meant SW decoding but if you don't see any image, it isn't used. Currently driver doesn't report 10-bit as unsupported profile, so it tries and fails to decode it. That's why you don't see any image.
cpufreq doesn't seem to work at all, looking at linux-sunxi.org suggests that support is in 5.8 (5.7 is used) so I guess this will arrive once Libreelec switches to 5.8 and if upstream dts contains required formation for cpufreq to work? Looking at the performance in software mode the cores seem to run at a pretty low frequency by default?
I already included all cpufreq related patches from 5.8. However, this functionality is enabled on per-board basis. So, if no one tested it on One Plus board and submitted a patch for it then this feature will not be present in any kernel. cpufreq is one of those things that it's better to be safe than sorry. Patch is probably just one line in dts but as I said, someone must guarantee stability on all devfreq points.
When using HW decoding and HW rendering through DRM planes (default settings) there is not much need for high CPU performance. Actually, if devfreq would work and proper governor would be set (currently it's set to performance due to shared config with other SoCs and they need it for stable SW CEC implementation), frequency would go much lower.
Well, I would expect at least the sound to be fine, if not the picture.
Nope. Audio and video are interdependent. If video doesn't work, audio won't work too.
Probably not but better to have a lot of drops than no image at all. Anyway, this is actually needed functionality because not all socs support all request api ffmpeg codecs (speaking more broadly, not just allwinner but also others, like rockchip).
In theory, H5 has same HW core as H3 but I had problems last time I tried. I need to test it again.
This just means that addons must be updated to python3. Kodi 19 won't support Python2 anymore. So you must bug addon author. There is no way to support python2 anymore...
No help for banned repos/addons whatsoever.
Read OP (hint, wifi doesn't work and it's crap anyway)
mine is 1.1 too. BTW, do samples also fail for you? I imagine it could also be some difference between playing from file or addon.
zillevdr sorry to say, but both samples work good both on old image updated with test update and fresh image on BananaPi M2+. So I can't reproduce your issues.
I just tested your samples and they work fine on OrangePi Plus 2E. I'll do more tests. I have a hunch what the issue might be.
zillevdr as I said, I need sample video to reproduce issue, otherwise I can't help. Additionally, make sure that it works if you disable deinterlacing.
well, no PMIC (important for lower heat) and no gigabit ethernet I wouldn't say nice...
I already explained in one topic (don't remember which) why this emmc hack will never come back. In short, someone must figure out what is really wrong. Secondly, there is no official support for Q+ and that's why I won't introduce hacks for it.
UI is already limited to 1080p (hidden setting, introduced exactly for weaker GPUs), but display can still be at 4K (DRM plane scaling is used). Actual problem here is that decoding and then deinterlacing process produces more frames than renderer is able to display (one frame per vblank - vsync). Naturally, they should be dropped. But this feature is not yet implemented for DRMPRIME direct to plane render method. Same issue you get with progressive, 60 fps video. But as I said, why drop frames if you can enjoy smooth playback with slightly lower resolution which in most cases is same or bigger than video native size.
You can change resolution and refresh rate in display settings 
You can even set refresh rate to be selected automatically depending on video size and fps, but this option is in video player settings. To be honest, 4k resolution is actually useful only for 4k videos. You'll get better (more fluent) playback with lower resolutions which allow higher refresh rates. Anyway, H6 has potential to surpass this but HDMI driver is not there yet.
Did you check issue mentioned in OP? If you're using for example 4K@30Hz display, like I did at first, you'll have such issue.
