I will do some tests using this and I am also working on an alternative where software decoded video can be rendered using direct-to-plane instead of the GLES pipeline, it will not be zero-copy rendering but rendering would bypass gpu, downside is no deinterlace support.
This is due to Kodi using something that is defined in GLES3/gl3.h without including this header. The libmali package is using the latest EGL-Registry and OpenGL-Registry include files, if it works using mesa or Android without GLES3/gl3.h it is probably because they use non-standard include files.
Edit: It looks like gl3.h is included from xbmc/system_gl.h at master · xbmc/xbmc · GitHub, I am guessing this compile issue only happens on non GLES3 targets. GLES3 headers should be installed for RK3288/RK3399 targets (they support GLES 3.1/3.2).
Edit2: I pushed some commits to Commits · Kwiboo/xbmc · GitHub including a fixup that should fix compile issues on RK3328 (it now checks if GLES3 headers exists). Test images including these changes can be found on Index of /test/ (untested).
That would be great.
Deinterlacing is not a problem as all 720i/1080i H264 or mpeg2 uses hardware decoding correctly.
Addons like Netflix and Amazon Prime display everything in 720p/1080p and there are no interlaced content on there.
I tested Netflix on your new build:
CPU usage seem to have gone down, eg using 30-50% CPU on all cores, sometimes with a few spikes when playing 720p Netflix streams with Inputstream h264, software decoded.
But the audio is crackling and 720p h264 Inputstream software decoding still plays in slow motion with stuttering with this lower CPU usage.
I hope your new direct-to-plane software decoding can help so video playback in such a case can be smoother.