iMX6/etnaviv: video playback - problem with some h264 encoded files

eTrax · February 1, 2021 at 10:39 PM

Hi there,

I tried the LibreELEC nightly builds for iMX6 for some days in parallel to an older OpenELEC 7.0 setup on a Cubox-i2eXw.

As this platform is a little bit outdated I was pleased to see that there might be a future release of LibreELEC with gpu support/hw acceleration.

As far as I understood, the kms/gbm/dri/mesa configuration is only in a basic state: h264 decoding with hw acceleration should work, all other formats might have some issues or will not play...

And that's exactly what I have experienced. MPEG1/MPEG2 and AVI-containers with DivX/Xvid-encoded video data will not show a picture, only sound is present for some files. I guess, to get this working, some work has to be done (as for the other platforms already was done in the last weeks), and based on the labels I have seen in the kodi and ffmpeg project, this seems to be addressed to some time later (Kodi 20).

But I still have a problem with some of h264 encoded files. Some will play with sound and picture, some will play sound, but there is only flickering (switching between black picture and the kodi gui) instead of video picture. The file which does not play, is the first one, h264 packaged in a matroska container. (Occupied - Die Besatzung - S01E01 - April.mkv)

The second one plays well, again h264, but packaged as MP4. (ARTE Concert - Pop & Rock-Rage Against the Machine - Live at Finsbury Park-1127769147.mp4)

I could also paste another example of a working h264/matroska file if needed.

For the first look I would expect something like a problem during init of the buffers (udmabuf/dma_heap) at kodi startup. And selection of a good suiting resolution and refresh rate looks a little bit weird, too. Source has 25fps, best suiting target resolution is using 60fps?

Maybe somebody could give me a hint, where to start investigations and how to fix this issue after having a look to the logs:

kodi.log

dmesg

modetest

eTrax · February 21, 2021 at 6:18 PM

Short update: The two hacks by lrusak solved problem with the missing video picture.

Also some other formats (i.e. MPEG2/DVDvob) now show a picture.

Playback gets unstable (offset between audio and video), seeking could be activated (at lower factors 2x-4x), but when returning to normal playback, kodi seems to get stuck.

Also when trying to change audio tracks (foreign languages), kodi seems to get stuck.

CPU load is also still higher compared to old OE7, although using DRMPRIME (HW): OE: both cores <= 10%, LE9.8: both cores 35-50%.

I will collect and prepare additional data during the week.

**chewitt** · February 22, 2021 at 6:52 AM Official Post

"take note that CODA driver (imx6) is missing the read-back of parsed SPS (I think Philipp never reversed that) and as a side effect, it cannot implement the SOURCE_CHANGE event used to sync after a seek. You'll notice that seeking works reliably on CODA with GStreamer, but that's only made possible as we do hold some workaround implemented by Pengutronix folks (used on Zodiac in-flight systems)"

^ This is from one of the Collabora engineers who maintains GStreamer. So lack of seeking is known but needs some non-trivial changes in the drivers to enable it. Half the fun with iMX6 is all the documentation and BSP code is under an oppressive NDA, so despite being one of the best-documented SoCs available you have to reverse-engineer everything under clean-room conditions.