[abga]

I'm trying to get Kodi 18.x working with the OMX acceleration and experiencing video & audio (analogue out & HDMI) stuttering on both Pi Zero and Pi 2B. MMAL is working fine, apart from the constant audio slowdown&speed-up and the horribly laggy GUI.
The video playback for all video content, locally -> even with 540p/720p H264 video files that should play fine without HW acceleration, Youtube, PVR - TV Channels, is starting fine for a few seconds (3-5), then the video&audio stutters, it recovers a little, and then it stutters again and it keeps like that, never recovering.
LibreELEC 9 seems to recover after a few seconds (10-15), but it starts again if another video/TV channel is played. The CPU doesn't seem to be loaded at all, the GUI is fast-responsive and the debug log is not really helpful.
I choose the HDMI out on both my Kodi compilation and LibreELEC 9 and experienced the same video stuttering. Was doing this on a simple monitor without speakers, just wanted to check if the analogue out is causing it, negative.
In the log there are constant warnings during the stuttering:

Code:

WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer
WARNING: Previous line repeats x times.

x being proportional with the level of stuttering

Mentioned this (hidden) in another thread - post #14 - Extra section - also attached a debug log:
https://forum.kodi.tv/showthread.php?tid...pid2817448
Debug log:
https://pastebin.com/PhrSZsxr
Followed what @asavah  suggested, used only the FFmpeg configuration&compilation that @popcornmix  (newclock5) / LibreELEC is doing, without any improvements.
Finally, considered to raise this as a standalone topic, as there might be some bugs/issues that need attention, maybe some explanations.

First, being unaware that FFmpeg is heavily patched for the Raspberry target in Kodi 18.x (newclock5 / LibreELEC), I just took the 4.0.3-Leia-RC5.tar.gz and optimized it for the Raspberry platforms, by making use of the default configure switches (which are different from the ones used in FFmpeg-3.1.9-Krypton-17.4):

Code:

# for the decoding:
--enable-omx --enable-omx-rpi --enable-decoder=h264_mmal --enable-decoder=mpeg2_mmal
# for the encoding:
--enable-encoder=h264_omx

https://www.linuxquestions.org/questions...ost5956641

Then, I tried the official FFmpeg release  https://ffmpeg.org/releases/ffmpeg-4.1.tar.bz2 , again, by using the default OMX/MMAL optimization switches.

Finally, by inspecting the patchwork that has been done in the newclock5 &  LibreELEC git repos, I replicated the compilation found in LibreELEC (considered the patches updated):
https://www.linuxquestions.org/questions...ost5958276

None of these FFmpeg builds have resolved the issue with the OMX acceleration.

There are some other things I tried, some learned here in the forum, without any positive results:
- disabled de-interlacing
- loaded the latest kernel&firmware provided by Raspberry (extracted from the latest Raspbian image) and used audio_pwm_mode=0 in /boot/config.txt
- set the CPU frequency on maximum -> changed the cpu freq. scale governor on performance (I'm usually keeping it on ondemand)
- overclocked the core&GPU&RAM on the Pi Zero:
Inspiration:
https://github.com/RetroPie/RetroPie-Set...erclocking

Code:

arm_freq=1000
gpu_freq=500
core_freq=500
sdram_freq=500
sdram_schmoo=0x02000020
over_voltage=6
sdram_over_voltage=2

- tried to play with the cache, inspired by this thread:
https://forum.kodi.tv/showthread.php?tid...pid2823612

I looked at the OMX Player code:
https://github.com/xbmc/xbmc/commits/mas.../omxplayer
and noticed there were some changes. Wondering if I could revert some of them - use the perfectly working OMX Player code from Kodi 17.x.

I'm under the impression that there's a bottleneck / buffering issue and I don't know where, as the debug log is not helpful. Is it the OMX Player code, Kodi code, FFmpeg code (why is a RC release used)?


Any help/hints appreciated.

[popcornmix]

I'm finding this post a bit confusing as it seems to be a combination of problems with your own custom build, plus issues with LibreELEC.
Might be best to focus on the issues with LibreELEC first, and then when you are happy with it's behaviour then try to replicate them in your own build.

Also focus on the Pi2 issues. Pi0 is really pretty underpowered in comparison and you should expect lagginess when doing more than basic use cases.

So firstly, with Pi2 and LibreELEC do you have issues when playing files (i.e. directly attached to storage on Pi, or played using NFS/SMB from local network,
rather than live TV or internet streams) with default settings?

[abga]

Thanks for your reply!
I used LibreELEC as a reference, more as a proof and I'm not sure I can focus on it too much. It's a wonderful distro providing the necessary stuff for Kodi to run, but literally a nightmare when it comes to customization - code change/ recompilation. Besides, I'm Linux savvy, that's why I'm using Slackware, have no experience with these newer Debian/Ubuntu developments that transformed into something else. Not sure what is confusing you and I'm ready to provide more details if necessary. OMX Player is stuttering while playing any kind of video content I try, locally, youtube, TV Channels, on both my build and LibreELEC and on both Pi0 and Pi2B.  MMAL does OK (GUI is horribly slow under Pi Zero).
The only difference between my build and LibreELEC, is that LibreELEC recovers from the stuttering after a few seconds, on both Pi Zero and Pi2B, whereas my build doesn't. There might be some core Kodi code changes (optimizations) in LibreELEC 9 that I didn't investigate yet (in their git repo).

I'll focus on the Pi2B, but I'm not planning to use it for long term Kodi stuff for my basic needs, it's a waste, and your statement about the Pi0 being pretty underpowered is very confusing, especially because it comes from you (same GPU as Pi2B).  As mentioned in my OP, the CPU on the Pi Zero, while the stuttering is manifesting, is not under heavy load at all. Additionally, the not so efficient MMAL acceleration is OK (apart from the sound speed-up slowdown on TV Channels - through pvr.hts) but the GUI is very slow.

I can also state that my build of Kodi 17.4 is performing better - GUI & playback is snappier/faster compared to LibreELEC 8.2.5.

[popcornmix]

I'll focus on the Pi2B, but I'm not planning to use it for long term Kodi stuff for my basic needs, it's a waste, and your statement about the Pi0 being pretty underpowered is very confusing, especially because it comes from you (same GPU as Pi2B).

The GPU is the same but there is a huge difference in arm performance (the Pi2 is six times faster than the Pi1, and a Pi0 is basically a Pi1 processor with a modest overclock).
The difference in arm performance is most obvious in gui navigation, but it can also affect the maximum bitrate of files that can be played smoothly
(the arm has to move data from the network/sdcard/usb through file system apis, kodi buffers and to the gpu which adds up on a Pi1).

I can also state that my build of Kodi 17.4 is performing better - GUI & playback is snappier/faster compared to LibreELEC 8.5.

That's generally a fact of life. Newer versions of software add more features which tend to increase cpu and ram requirements.
Unless the devs are running low end devices (they generally aren't) they don't tend to spot this.
Occasionally there are commits focusing on performance but these tend to be pretty rare compared to new features.
The skin is probably the main contributor to kodi being slower with newer releases. A lighter skin like confluence may help.

[popcornmix]

This sequence in log:

Code:

07:01:55.101 T:2712683488   DEBUG: CVideoPlayer::OMXDoProcessing Resume 0.33,0.92 (A:01 V:01) EOF:0 FULL:0 T:0.20
07:01:59.347 T:2712683488   DEBUG: CVideoPlayer::OMXDoProcessing Pause 1.40,0.07 (A:01 V:10) EOF:0 FULL:0 T:0.40
07:01:59.965 T:2712683488   DEBUG: CVideoPlayer::OMXDoProcessing Resume 1.97,0.43 (A:01 V:01) EOF:0 FULL:0 T:0.40
07:02:00.208 T:2712683488   DEBUG: CVideoPlayer::OMXDoProcessing Pause 1.92,0.07 (A:01 V:10) EOF:0 FULL:0 T:0.80

shows the gpu is not being fed data fast enough (the V:10 says video_fifo_low=1 video_fifo_high=0) so we are repeatedly pausing and unpausing the stream.

You are playing a file from a PVR backend which adds a lot more places the problem could be occurring into the mix.
A log file from a Pi2, with a file played locally (e.g. from sdcard or directly attached USB stick) would be useful to rule out the rest of the system.

[abga]

On your previous explanations, you seem to have missed two key points from my first post:
- under the MMAL acceleration (core VideoPlayer) the playback is smooth and the CPU usage pretty high (80-90%) on the Pi Zero. AFAIK MMAL is far more inefficient than OMX and it still works well.
- the CPU usage on Pi Zero (also on Pi2B) is low while using the OMX and experiencing the stuttering, at ~30%. The remaining processing capacity is there, but nobody seems to use it. Under Kodi 17.x, while playing through OMX, the CPU on Pi Zero stays at ~50-60%
I believe there's a regression in Kodi 18.x and still not sure where. And, while goofing around now with these tests and debug logs, I noticed LibreELEC uses the newclock5 source for their Raspberry builds and not the official Kodi 18.x source, which means Kodi 18.x is not ready for Raspberry Pi and I just wasted a lot of time trying & documenting it

Code:

Starting Kodi (18.0 Git:newclock5_18.0-Leia). Platform: Linux ARM 32-bit

If the official Kodi 18.x releases are not yet ready for the Raspberry Pi platform, then this should be better announced somewhere.

I ran some tests on Rpi 2B and Rpi Zero, with clean LibreELEC 9 (Kodi 18.0) installs this time, using the OMX acceleration (MMAL disabled) and no de-interlacing, audio set on analogue out (again, using HDMI instead makes no difference). In my previous tests on Rpi 2B I might have used some messed up MPEG file, got some slight hiccups that I took as stuttering.

Tests details and order:
1. local 1080p H264 test file playback
2. youtube playback
3. pvr.hts (TVHeadend) - 720p (Euronews Europe) playback
4. pvr.hts (TVHeadend) - 1080p (BBC Europe HD) playback

Results and debug logs (edited the logs to remove the private info - IP addresses, MPEG2 keys, etc.):

- LibreELEC 9 on Raspberry Pi2B
Logfile:
https://paste.kodi.tv/ajisimugov.kodi
Test results:
1. OK
2. OK
3. Not OK - stuttering and recovering
4. Not OK - stuttering and recovering

I also did a debug log where I enabled the component-speciffic logging (enabled all), but the log was huge - over 100MB!  I just took a snippet where the stuttering was apparent while playing BBC Europe HD over pvr.hts - Tvheadend:
https://paste.kodi.tv/zesahubipi.kodi
I couldn't do this on the Pi Zero - it would kill it.

- LibreELEC 9 on Raspberry Pi Zero
https://paste.kodi.tv/yabadoxojo.kodi
Test results:
1. OK
2. OK
3. Not OK - stuttering and recovering
4. Not OK - stuttering and recovering

- Kodi 18.1 - own compilation, using the official Kodi 18.1 release on Slackware ARM - running on Raspberry Pi Zero
https://paste.kodi.tv/ewicufucud.kodi
Test results:
1. Not OK - stuttering and not recovering (had only a 720p H264 test file available)
2. Not OK - stuttering and not recovering
3. Not OK - stuttering and not recovering
4. Not OK - stuttering and not recovering

Details about Kodi 18.1 - own compilation:
- Kodi compilation details:
https://www.linuxquestions.org/questions...ost5957433
- FFmpeg compilation details:
https://www.linuxquestions.org/questions...ost5958276

[abga]

In my first post I mentioned that I'm experiencing the video&audio stuttering on both Raspberry Pi Zero and Pi 2B. That might have caused a slight confusion, because I forgot to mention that I used the same native armv6 SDCard (Linux+Kodi) on both boards.
As advised, I focused on the more powerful Raspberry Pi2B and spent some time going through the tests and creating a debug log with my own compilation.
- Kodi 18.1 - https://github.com/xbmc/xbmc/archive/18.1-Leia.tar.gz - own compilation on Slackware ARM (armv6) - running on Raspberry Pi 2B
- it's armv6 code and no NEON SIMD code was created (it was a native armv6 compilation), thus, the Pi2B is not 6 time faster than the Pi Zero, but more like 4 times (4 cores)
- /boot/config.txt contains audio_pwm_mode=0 , disabled de-interlacing and used the HDMI out for the sound.

Debug log:
https://paste.kodi.tv/ufavohoceb.kodi
Test results:
1. Not OK - stuttering and not recovering (had only a 720p H264 test file available)
2. Not OK - stuttering and not recovering
3. Not OK - stuttering and not recovering
4. Not OK - stuttering and not recovering

The CPU usage was very low while experiencing the stuttering (20-28%) and the GUI snappy (the same as with the Pi Zero)
- htop screenshot:
https://www12.zippyshare.com/v/awmpbeET/file.html

I guess the theory with the insufficient CPU power on the Pi Zero, which is my actual Kodi target, is failing. Since I used the same FFmpeg compilation like the LibreELEC 9 build and my Kodi+FFmpeg build doesn't recover form the stuttering, I'd rule out FFmpeg for now and focus on Kodi instead. I'm tempted to substitute the OMXPlayer code in 18.1 and take the one from 17.4, but I'm afraid I'll break something and also not sure if OMXPlayer itself is buggy or Kodi(internal code) doesn't provide the OMXPlayer with enough data (stream) to be able to play continuously.
I wish I could do more, but I'm limited in my coding experience and without knowing the Kodi internal architecture, it'll take me a lot of time&effort to check where the suspected bottleneck might occur.

[abga]

I took a look over the latest (1-2 years) commits in the /xbmc/cores/ source directory, trying to find&revert something that might have caused the reported OMXPlayer faulty behavior. There were plenty of changes between 17.x and 18.x and, again, without understanding too much of the internals, I failed to identify anything and I'm still open to speculation.
Meanwhile I stumbled upon some useful documentation:
https://codedocs.xyz/AlwinEsch/kodi/clas...nager.html
Which states:

WaitForBuffer()
int CRenderManager::WaitForBuffer     (     volatile std::atomic_bool &      bStop,
        int      timeout = 100
    )        

If player uses buffering it has to wait for a buffer before it calls AddVideoPicture and AddOverlay. It waits for max 50 ms before it returns -1 in case no buffer is available. Player may call this in a loop and decides by itself when it wants to drop a frame.

This is related to the log record (flooding the debug log):

Code:

WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

Also found this older, but interesting, solution for the Amlogic HW Render:
https://forum.libreelec.tv/thread/10934-...#post72837
Wondering if something similar could cause the bottleneck, and if a simple increase in buffers / buffer size somewhere in the code would help.

I'm open for any code change suggestions, I could build Kodi and test these. Well, compared to Kodi 17.x, compiling Kodi 18.x takes ages, but I might be able to do a compilation every now and then.

[abga]

Right!

https://github.com/xbmc/xbmc/commit/f097...26d58d1ef1
drop omxplayerRechi committed May 7, 2019
Bye Bye (efficient) video decoding support for Raspberry Pi...
VideoPlayer + MMAL acceleration does work on Pi2Bs and above, but it's not really efficient. I believe I'll move away from using the Raspberry Pi (& other available ARM SBCs) as they are really crappy these days - ( unreliable performance output - thermal throttling) and pretty expensive too (incl. the required accessories) compared to these cheap (~$100) x86 quad-core atom powered miniPCs that come with everything out of the box. It was an interesting experience for sure.
Many thanks to the Kodi team for supporting the Rpi and The Raspberry folks for constantly breaking the firmware & kernel

[JagoUK]

Thought i'd just add to this conversation as i'm having the same issues.
In Kodi 17 I had no issues with TVHeadend and playing HD and SD channels.
In Kodi 18 I had stuttering on HD channels unless I turned OMX on and MMAL off. But I get macroblocking every 10 seconds
In Kodi 19 I now have stuttering again because OMX has been removed. MMAL still needs to be off.

I can play native Blu-Ray MKV's (No transcoding or recompression) absolutely fine on 17/18/19

I can still revert back to 17 for perfect playback but obviously it's a very old version.

I can use 17/18/19 as a receiver on PI2/3 and playback on a laptop or xbox one. The playback is fine and stutter/macrobocking free.

So i'd say the issue is somewhere between TVHeadend and Playback causing too much CPU usage?
The PI3 is less prone to the dropped frames causing macroblocking.

[popcornmix]

In Kodi 19 I now have stuttering again because OMX has been removed. MMAL still needs to be off.

Do you still get the stuttering if you disable deinterlace?
If you switch deinterlace to bob?

[JagoUK]

In Kodi 19 I now have stuttering again because OMX has been removed. MMAL still needs to be off.

Do you still get the stuttering if you disable deinterlace?
If you switch deinterlace to bob? 

Sorry I didn't get chance to test this.
Using an old TVHeadend client appears to have fixed my problems.
999.5.0.1 that came with 8.2.5

[Milhouse]

999.5.0.1 that came with 8.2.5

999.5.0.1 doesn't come with 8.2.5 this is from one of my test builds and is only used by my test builds - if you revert to 8.2.5 then you revert to whatever add-on you have installed from the LE repo.

[the_bo]

In Kodi 19 I now have stuttering again because OMX has been removed. MMAL still needs to be off.

Do you still get the stuttering if you disable deinterlace?
If you switch deinterlace to bob?  

Sorry I didn't get chance to test this.
Using an old TVHeadend client appears to have fixed my problems.
999.5.0.1 that came with 8.2.5 

Which tvheadened version is it?

Click on the about tab

Thanks